Тема 23. Оценка трудоемкости и сроков разработки ПО

План лекции

1. Оценка трудоемкости

2. Метод функциональных точек

3. Методика COCOMO II

Оценка трудоемкости

Проектная деятельность в силу своей уникальности и неопределенности весьма сложно поддается точному нормированию.

В [2] приведен довольно типичный пример из программистской практики. Попробуем оценить трудоемкость добавления поля ввода телефонного номера клиента к уже существующей форме. Менеджер, наблюдающий работу программистов только со стороны, скажет, что эта работа потребует не больше 15 минут рабочего времени. Человек, умудренный программистским опытом, скажет, что эта работа может занять от 2 до 200 часов, и чтобы дать более точную оценку ему надо получить ответы на ряд вопросов:

1. Может ли вводиться несколько номеров?

2. Должна ли быть проверка номеров на действительность?

3. Простая или сложная проверка? Если реализуем простую проверку, то не захочет ли клиент заменить ее на более сложную?

4. Должна ли проверка работать для иностранных номеров?

5. Можно ли воспользоваться готовым решением?

6. Каково должно быть качество реализации? Вероятность ошибки после поставки?

7. Сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя).

Называя такую «размытую» оценку опытный программист резервирует все риски разработки, связанные с перечисленными неопределенностями данного требования, которые он вынужден принимать на себя, не имея в данный момент необходимой уточняющей информации. Для получения более-менее достоверной информации желательно использовать собственный опыт по выполнению проектов или опыт коллег, полученный в схожих проектах. Если есть ориентировочная статистика, то можно получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта.

На практике себя хорошо зарекомендовал метод PERT-анализа (Program Evaluation Review Technique). Метод PERT ориентирован на анализ таких проектов, для которых продолжительность выполнения всех или некоторых работ не удается определить точно. В таких проектах многие работы не имеют аналогов. В результате возникает неопределенность в сроках выполнения проекта в целом. Метод PERT-анализа был разработан сотрудниками Военно-морского флота США в 1957 году для обеспечения создания ракетного комплекса «Поларис». Его разработали корпорация Lockheed Air Craft, консалтинговая компания Booz, Allen & Hamilton и особое проектное бюро ВМС США. На его разработку, по заявлениям фирмы, ушло 15 лет, таким образом, начало работ относилось к 1943 г. Благодаря PERT, проект, который состоял из 60 тыс. операций и объединял около 3800 основных подрядчиков, удалось закончить на два года раньше запланированного срока. Его успешное завершение способствовало тому, что вскоре данный метод стал повсеместно применяться для планирования проектов в вооруженных силах США. Применяя PERT-анализ, они попытались сымитировать график выполнения работ по созданию ракеты путем построения логической сети взаимозависимых последовательных событий. На начальной стадии PERT-представление было сфокусировано на контроле временных характеристик графика и прогнозировании вероятности успешного завершения программы. Но прежде чем PERT-представление было окончательно принято руководителями программ в промышленности, Военно-воздушные силы США внесли дополнение в методику, добавив к логической сети функцию ресурсной оценки. Таким образом, в 1962 году появилась PERT/Cost-методика (PERT-анализ с целью стоимостного прогнозирования), в то время как первоначально PERT-анализ был известен под названием PERT/Time (PERT-анализ для определения времени реализации проекта).

Идеи, сходные с идеями, положенными в основу системы PERT, были еще в 30-х годах предложены в советском капитальном строительстве (на строительстве Магнитогорского металлургического комбината), но в то время они не получили распространения и для них не были произведены необходимые математические разработки. Однако это не означает, что в нашей стране идеи метода никого не интересовали. Благодаря усилиям С.П. Никанорова, в 60-е годы Министерство обороны в лице подведомственных институтов активно занялось разработками в этой области.

Для того, чтобы использовать метод PERT, для каждой работы i, время выполнения которой является случайной величиной, необходимо определить следующие три оценки:

- оптимистическое время a_i – время выполнения работы i в благоприятных условиях;

- наиболее вероятное время m_i – время выполнения работы i в нормальных условиях;

- пессимистическое время b_i – время выполнения работы i в неблагоприятных условиях.

Учитывая, что время выполнения работы хорошо описывается бета- распределением, вреднее или ожидаемое время t_i выполнения работы i может быть определено по формуле: t_i = (a_i + 4 m_i + b_i)/6.

Если время выполнения работы i известно точно и равно d_i, то t_i = a_i = m_i = = b_i = d_i.

Располагая указанными выше тремя оценками времени выполнения работы, можно также рассчитать среднеквадратичное отклонение: s_i = (b_i - a_i)/6.

Пусть Т – время, необходимое для выполнения проекта. Если в проекте есть работы с неопределенным временем выполнения, то время является случайной величиной. Математическое ожидание (ожидаемое значение) времени выполнения проекта M (Т) равно сумме ожидаемых значений времени выполнения работ, лежащих на критическом пути. Для определения критического пути проекта может быть использован метод CPM. На этом этапе анализа проекта время выполнения работы полагается равным ожидаемому времени t_i.

Вариация (дисперсия) общего времени, требуемого для завершения проекта, в предположении о независимости времен выполнения работ равна сумме вариаций работ критического пути. Если же две или более работы взаимозависимы, то указанная сумма дает приближенное представление о вариации времени завершения проекта.

Распределение времени Т завершения проекта является асимптотически нормальным со средним M (Т) и дисперсией s ² (Т). С учетом этого можно рассчитать вероятность завершения проекта в установленный срок Т₀. Для определения вероятности того, что Т ≤ Т₀, следует использовать таблицу распределения величины z = (Т₀ - M (Т))/ s (Т), которая имеет стандартное нормальное распределение.

Список элементарных пакетов работ, который используется при оценке трудоемкости, как правило, берется из нижнего уровня ИСР проекта. Но может быть использован и накопленный опыт аналогичных разработок. Если воспользоваться методом PERT нельзя в силу отсутствия экспертных оценок продолжительности работ, можно использовать формальные методики. Наиболее известными являются:

- FPA IFPUG – метод функциональных точек;

- метод COCOMO II, Constructive Cost Model.

 

Метод функциональных точек

Анализ функциональных точек – стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70- х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG), которая опубликовала несколько ревизий метода. Метод предназначен для оценки на основе логической модели объема программного продукта количеством функционала, востребованного заказчиком и поставляемого разработчиком.

Определение числа функциональных точек является методом оценки размера ПО, не зависящим от технологии и языка программирования. В основу метода положена оценка функциональности разрабатываемой системы. Функциональность определяется на основе выявления и подсчета функциональных типов – групп взаимосвязанных данных, используемых системой, а также элементарных процессов, связанных с вводом и выводом данных.

 

Рисунок 23.1. Функциональные типы.

 

К функциональным типам относятся (рис. 23.1):

1) Внутренний логический файл (ILF, Internal Logical File) – именованная совокупность данных, поддерживаемая изнутри приложения.

2) Внешний интерфейсный файл (EIF, External Interface File) – именованная совокупность данных, передаваемых другому приложению или получаемых из него.

3) Входной элемент приложения (EI, External Input) – элементарный процесс, связанный с обработкой входной информации – документа или экранной формы.

4) Выходной элемент приложения (EO, External Output) – элементарный процесс, связанный с обработкой выходной информации – отчета, документа или экранной формы.

5) Внешний запрос (EQ, External Query) – элементарный процесс, со стоящий из комбинации запрос/ответ, не связанный с вычислением или обновлением ILF.

Для каждого функционального типа определяется сложность (например, по количеству атрибутов объектов), затем подсчитывается количество функциональных точек по всем типам и вводится поправка на сложность системы. На реализацию проекта размером в одну функциональную точку требуется один день, и они всегда заканчиваются успешно. Таковы небольшие утилиты для временных нужд.

Объем в 10 ФТ – это типичный объем небольших приложений и дополнений, вносимых в готовые системы. Здесь требуется до одного месяца работ, которые также заканчиваются успешно.

Объем в 100 ФТ близок к пределу возможностей программиста-одиночки. Проект доводится до конца в срок до 6 месяцев при успешности в 85 % случаев.

Объем проекта в 1000 ФТ характерен для большинства сегодняшних коммерческих настольных и клиент-серверных приложений. Заметную долю общего объема работ начинает занимать документирование. Для реализации проекта нужна группа примерно из 10 человек, включая программистов, постановщиков, специалистов по тестированию, и около одного года работы. Проваливается 15 % проектов при работе группы и 65 % попыток программистов- одиночек. В 20 % случаев не удается уложиться в сроки, в 25 % проектов отмечается перерасход средств.

Для проекта в 10 000 ФТ требуется около 100 разработчиков. Работы длятся от 1,5 до 5 лет, при этом запланированные сроки чаще всего не выдерживаются. Важнейшую роль начинает играть технология тестирования. До 50 % проектов заканчиваются неудачей.

Объем в 100 000 ФТ на сегодня близок к пределу возможностей создания информационных систем. Это объем современных ОС, таких как Microsoft Windows и крупнейших военных систем. На их создание уходит 5–8 лет. Над проектом трудятся сотни разработчиков, иногда из разных стран. В законченных системах остается много ошибок. До 65 % проектов завершаются неудач- но.

Несомненным достоинством метода является то, что измерения не зависят от технологической платформы, на которой будет разрабатываться продукт, и он обеспечивает единообразный подход к оценке всех проектов в компании.

Методика COCOMO II

Методика COCOMO позволяет оценить трудоемкость и время разработки программного продукта. Впервые была опубликована Бари Боэмом в 1981 году в виде результат анализа 63 проектов компании «TRW Aerospace». В 1997 методика была усовершенствована и получила название COCOMO II. Калибровка параметров производилась по 161 проекту разработки. В модели используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.

Наиболее известным методом оценки трудоемкости и времени проекта, основанным на большом количестве данных из проведенных ранее проектов, является конструктивная модель стоимости версии II (Constructive Cost Model II, СОСОМОII).

Эта модель основана на опыте реализации многих программных проектов. Она создана путем сбора данных о большом количестве проектов и анализа этой информации.

Достоинства модели:

- эта модель имеет хорошую техническую документацию, общедоступна, существуют коммерческие программные средства ее поддержки;

- модель популярна и ценится среди широкого круга пользователей;

- она прошла достаточно долгий путь развития со времени первого появления в 1981 году, была усовершенствована для разработки ПО на языке Ada, последняя версия модели опубликована в 1995 году.

Модель СОСОМО охватывает три уровня:

- уровень предварительного прототипирования. Для определения необходимых затрат осуществляется оценка размера системы на основе объектных точек прототипа;

- уровень предварительного проектирования. Этот уровень предусматривает окончание работы над системными требованиями и, возможно, над начальным проектом архитектуры программы. Оценка затрат на этом уровне основана на функциональных точках, которые затем пересчитываются в количество строк кода программ;

- постархитектурный уровень. После разработки архитектуры системы существует реальная возможность достаточно точно оценить размер программы.

Алгоритмические модели стоимости применяются для сравнения различных инвестиций в целях снижения стоимости проекта.

Стоимость проекта складывается из трех компонентов:

- стоимость целевых аппаратных средств, на которых будет функционировать разрабатываемая система;

- стоимость платформы (вычислительная техника плюс программное обеспечение), используемой для разработки системы;

- стоимость затрат на разработку системы.

Стоимость программного продукта (SC) вычисляется следующим образом:

SC = оценка затрат * RELY * TIME * STOR * TOOL * ЕХР * $15000,

где показатели TIME и STORE - соответствующие множители, влияющие на формирование стоимости, учитывают ограниченность времени исполнения и объема памяти; показатель TOOL - доступность средств поддержки системы разработки, таких, как кроссплатформенные компиляторы и т.п.; показатель LTEX - и опыт команды разработчиков. Для всех проектных характеристик множитель RELY (показатель надежности) равен 1.39 Стоимость затрат на один человеко-месяц составляет $15000.

Менеджеры проектов должны определить длительность выполнения проекта (т.е. составить временной график работ) и время начала найма персонала для непосредственной работы.

Распределяя прогнозируемые затраты на реализацию проекта, не можем точно знать, сколько человек необходимо включить в команду разработчиков. Часто набор программистов происходит по принципу от меньшего к большему с последующим постепенным уменьшением их численности.