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

Цель:рассмотреть оценку трудоёмкости и сроки разработки программного обеспечения

План:

1. Оценка — вероятностное утверждение
2. Негативные последствия «агрессивного» расписания
3. Прагматичный подход. Метод PERT
4. Обзор метода функциональных точек
5. Подсчет функциональных точек, связанных с данными
6. Подсчет функциональных точек, связанных с транзакциями
7. Определение суммарного количества не выровненных функциональных точек (UFP)
8. Расчет количества выровненных функциональных точек (AFP)
9. Основы методики COCOMO II
10. Факторы масштаба
11. Множители трудоемкости
12. Оценка многокомпонентного продукта

1 Оценка — вероятностное утверждение

Стив Макконнелл пишет, что мы от природы склонны верить, что сложные формулы вида всегда обеспечивают более точные результаты, чем простые формулы

Трудоемкость = КоличествоФакторов х СредниеЗатратыНаФактор Однако, далеко не всегда это так. Сложные формулы, как правило, очень чувствительны к точности большого числа параметров (в приведенном примере формул COCOMO II содержится 21 параметр), которые надо задать, чтобы получить требуемые оценки. Первое, что необходимо понимать при оценке проекта, это то, что любая оценка это всегда вероятностное утверждение. Если мы просто скажем, что трудоемкость данного пакета работ составляет М чел.*мес. (рисунок 34), то это будет плохой оценкой потому, что одно единственное число ничего не скажет нам о вероятности того, что на реализацию этого пакета потребуется не более, чем М чел.*мес. Вряд ли мы можем считать себя «предсказамусами», которые точно знают что произойдет в будущем и сколько потребуется затрат на реализацию этого пакета работ.

Рисунок 34. Точечная оценка трудоемкости пакета работ ничего не скажет нам о вероятности того, что на реализацию этого пакета потребуется не более, чем М чел.*мес.

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

- Может ли вводиться несколько номеров?
- Должна ли быть проверка номеров на действительность?
- Простая или сложная проверка?
- Если реализуем простую проверку, то не захочет ли клиент заменить ее на более сложную?
- Должна ли проверка работать для иностранных номеров?
- Можно ли воспользоваться готовым решением?
- Каково должно быть качество реализации? Вероятность ошибки после поставки?
- Сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя).

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

Рисунок 35. Оценка — всегда вероятностная величина

Если M — наиболее вероятное значение, то это не означает что это хорошая оценка, поскольку вероятность того, что фактическая трудоемкость превысит эту оценку, составляет более 50%. Какая оценка может считаться хорошей? Стив Макконнелл утверждает: «Хорошей считается оценка, которая обеспечивает достаточно ясное представление реального состояния проекта и позволяет руководителю проекта принимать хорошие решения относительно того, как управлять проектом для достижения целей».

2 Негативные последствия «агрессивного» расписания

В программостроении уже стало банальностью то, что разработчики без достаточного основания называют слишком оптимистичные сроки. Среди руководителей даже распространено неписаное правило: умножать на 2 оценку трудоемкости, которую сделал программист. Это пессимистичный подход. Реалисты умножают на ? = 3.14 . Действительно, так иногда приходится поступать, если это программист, который только вчера отладил свою первую программу «Hello world!». Но если помочь молодым специалистам научится анализировать задачу, проектировать решение, составлять план работы, эффективно его реализовывать и анализировать полученные результаты, то можно будет не вспоминать, чему равно число ?. Еще один распространенный источник занижения сроков — необоснованные ожидания на применение новых технологий и средств разработки. Эти ожидания, как правило, не оправдываются. Согласно статистике, приведенной Демарко, средняя производительность в программном производстве растет всего лишь на 3–5% в год. Часто «агрессивное» расписание проекта появляется из-за того, что руководство и/или заказчик боятся переоценить проект, полагая, что согласно закону Паркинсона, работы по проекту займут все отведенное для него время. Следствием подобных опасений является, как правило, директивное занижение сроков реализации проекта. Нереалистичность оценок — один из серьезнейших демотивирующих факторов для участников. Недооценка приводит к ошибкам планирования и неэффективному взаимодействию. Например, было запланировано тестирование, а релиз еще не готов. Следствие — простой тестировщиков увеличение трудозатрат. Если расписание излишне агрессивное, то с целью сэкономить время, недостаточно внимания уделяется анализу требований и проектированию. Исправление ошибок, допущенных на этих этапах, приведет к существенным дополнительным затратам. Половина всех ошибок программирования возникают из-за стресса, вызванного излишним давлением фактора сроков. Ошибки исправляются наспех, обходными путями. В результате будет получен большой проблемный код и постоянно растущие затраты на исправление ошибок и внесение изменений. Позднее обнаружение ошибок приводит к тому, что затраты на их исправление увеличиваются в 50–100 раз. Мне пришлось наблюдать проект, который вместо первоначально слишком оптимистично запланированных шести месяцев растянулся на три года. Хотя, если бы он был адекватно оценен, то он мог бы быть реализован за один год. Нереальные сроки, постоянное давление, сверхурочные, авралы приводят к тому, что затраты на проект растут экспоненциально и неограниченно. Если участники проектной команды адекватно мотивированы на выполнение проектных работ с наименьшими затратами, то, на мой взгляд, этого достаточно, чтобы проект был реализован в минимально возможные сроки. О мотивации мы еще будем говорить.

3 Прагматичный подход. Метод PERT

Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат. Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис». Входом для данного метода оценки служит список элементарных пакетов работ. Для инженерного подхода нет необходимости точно знать закон распределения нашей оценки трудоемкости каждого такого элементарного пакета. Диапазон неопределенности достаточно охарактеризовать тремя оценками:

- Mi — наиболее вероятная оценка трудозатрат.
- Oi — минимально возможные трудозатраты на реализацию пакета работ. Ни один риск не реализовался. Быстрее точно не сделаем. Вероятность такого, что мы уложимся в эти затраты, равна 0.
- Pi — пессимистическая оценка трудозатрат. Все риски реализовались.

Оценку средней трудоемкости по каждому элементарному пакету можно определить по формуле:
Ei = (Pi + 4Mi + Oi)/6.
Для расчета среднеквадратичного отклонения используется формула:
CKOi = (Pi - Oi)/6.

Если наши оценки трудоемкости элементарных пакетов работ статистически независимы, а не испорчены, например, необоснованным оптимизмом то, согласно центральной предельной теореме теории вероятностей суммарная трудоемкость проекта может быть рассчитана по формуле: Е = ? Ei
А среднеквадратичное отклонение для оценки суммарной трудоемкости будет составлять:
Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, можно применить формулу:
E95% = E + 2 * СКО.

Это значит, что вероятность того, что проект превысит данную оценку трудоемкости составляет всего 5%. А это уже вполне приемлемая оценка, под которой может расписаться профессиональный менеджер. Список элементарных пакетов работ, который используется при оценке трудоемкости, как правило, берется из нижнего уровня ИСР проекта. Но может быть использован и накопленный опыт аналогичных разработок. Проиллюстрирую данный подход на примере реального проекта. В Ассоциации CBOSS задачей проекта, который нам с коллегами посчастливилось реализовывать, была разработка на основе стандартов J2EE общесистемного ПО для перевода рабочих мест CBOSS на новую трехзвенную архитектуру. Был разработан набор стандартных компонентов и сервисов, из которых как из конструктора можно эффективно и качественно собирать прикладные подсистемы. Высокоуровневая архитектура реализовывала стандартный паттерн MVC (рисунок 36), каждый из компонентов которого имел «точки расширения» для прикладной разработки, которые на рисунке выделены красным светом.

Рисунок 36. Высокоуровневая архитектура J2EE фреймворка для разработки приложений.

Такими точками расширения являлись:

- Пользовательский экран (UI Form), который собирался из готовых визуальных компонентов.
- Обработчики (Action), которые обрабатывали на сервере приложений события от активных визуальных компонентов, входящих в состав экрана.
- Объекты (Business Obj), которые моделировали прикладную область, и к которым обращались обработчики событий.

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

- для одного экрана — от 2 до 20 часов (наиболее вероятно — 4 часа);
- для одного обработчика событий — от 4 до 32 часов (наиболее вероятно — 8 часов);
- для нового бизнес-объекта — от 2 до 8 часов (наиболее вероятно — 3 часа);
- для добавления нового бизнес-метода — от 2 до 26 часов (наиболее вероятно — 6 часов).

Весь проект прикладной разработки измерялся в «попугаях»:

- КUI — количество пользовательских экранов.
- KAct — количество обработчиков событий.
- КBO — количество новых бизнес-объектов.
- KBM — количество новых или модифицируемых бизнес-методов.

Если новое разрабатываемое приложение содержит 20 пользовательских экранов, 60 обработчиков событий, 16 новых бизнес-объекта и 40 новых бизнес-методов, которые необходимо добавить, как в новые, так и в уже существующие бизнес-объекты, тогда, согласно нашей статистике,

ЕUI = (2 + 4*4 + 20) / 6 = 6.7 чел.*час., ЕAct = (4 + 4*8 + 32) / 6 = 11.3 чел.*час., ЕBO = (2 +4*3 + 8) / 6 = 3.7 чел.*час., EBM = (2 + 4*6 + 26) / 6 = 8.7 чел.*час., СКОAct = (32 - 4) / 6 = 4.7 чел.*час CKOBO = (8 - 2) / 6 = 1 чел.*час СКОBM = (26 - 2) / 6 = 4 чел.*час | СКОUI = (20 - 2) / 6 = 3 чел.*час СКОAct = (32 - 4) / 6 = 4.7 чел.*час CKOBO = (8 - 2) / 6 = 1 чел.*час СКОBM = (26 - 2) / 6 = 4 чел.*час

Для средней трудоемкости работ по кодированию в проекте может быть получена следующая оценка:
Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, получим
Е95% = 1220 + 2 *46 ? 1300 чел.*час.
Хотя относительная погрешность в оценке трудоемкости каждой такой элементарной работы составляла десятки процентов, для нашего проекта, в котором было таких «попугаев» было 136, относительная погрешность оценки суммарной трудоемкости, сделанной по методу PERT, составила, приблизительно, лишь 4%.

Даже если у нас очень размытые оценки трудоемкости каждой из элементарных работ, но они независимы, то ошибки мы делаем как в меньшую, так и большую стороны. Поэтому при фактической реализации проекта эти ошибки будут компенсироваться, что позволяет нам оценить общие трудозатраты по проекту существенно точнее, чем трудозатраты на каждую элементарную работу. Но это утверждение будет справедливо только в том случае, если наша ИСР содержит все необходимые работы, которые должны быть выполнены для получения всех продуктов проекта. Полученную оценку трудоемкости кодирования необходимо умножить на четыре, поскольку помним, что кодирование составляет только 25% общих трудозатрат проекта. Поэтому суммарная трудоемкость нашего проекта составит, приблизительно, 5200 чел.*час. Как мы уже говорили ранее, если сотрудник на 100% назначен на проект, это, как правило, не означает, что он все 40 часов в неделю будет тратить на проектные работы. Тратить он будет 60–80% своего рабочего времени. Поэтому, в месяц сотрудник будет работать по проекту, примерно, 165 * 0.8 = 132 чел.*час/мес. Следовательно, трудоемкость проекта в человеко-месяцах составит, приблизительно 5200 / 132 ? 40. Тогда согласно формуле Б.Боэма (Рисунок 15) оптимальная продолжительность проекта составит: T = 2.5 * (40)1/3 = 8.5 месяцев, а средняя численность команды — 5 человек. Помним, что потребление ресурсов в проекте неравномерно (Рисунок 13), поэтому начинать проект должны 1–3 человека, а на стадии реализации начальная численность команды может быть увеличена в несколько раз. Если же собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то нам не остается ничего другого, как использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:

- FPA IFPUG — метод функциональных точек,
- метод COCOMO II, Constructive Cost Model.

4 Обзор метода функциональных точек

Анализ функциональных точек — стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group — IFPUG), которая опубликовала несколько ревизий метода. Метод предназначен для оценки на основе логической модели объема программного продукта количеством функционала, востребованного заказчиком и поставляемого разработчиком. Несомненным достоинством метода является то, что измерения не зависят от технологической платформы, на которой будет разрабатываться продукт, и он обеспечивает единообразный подход к оценке всех проектов в компании. При анализе методом функциональных точек надо выполнить следующую последовательность шагов (рисунок 37):
1. Определение типа оценки.
2. Определение области оценки и границ продукта.
3. Подсчет функциональных точек, связанных с данными.
4. Подсчет функциональных точек, связанных с транзакциями.
5. Определение суммарного количества не выровненных функциональных точек (UFP).
6. Определение значения фактора выравнивания (FAV).
7. Расчет количества выровненных функциональных точек (AFP).

Рисунок 37. Процедура анализа по методу функциональных точек

Определение типа оценки
Первое, что необходимо сделать, это определить тип выполняемой оценки. Метод предусматривает оценки трех типов:

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

Определение области оценки и границ продукта
Второй шаг — это определение области оценки и границ продукта. В зависимости от типа область оценки может включать:

- Все разрабатываемые функции (для проекта разработки)
- Все добавляемые, изменяемые и удаляемые функции (для проектов поддержки)
- Только функции, реально используемые, или все функции (при оценке продукта и/или продуктов).

Третий шаг. Границы продукта (рисунок 38) определяют:

- Что является «внешним» по отношению к оцениваемому продукту.
- Где располагается «граница системы», через которую проходят транзакции передаваемые или принимаемые продуктом, с точки зрения пользователя
- Какие данные поддерживаются приложением, а какие — внешние.

Рисунок 38. Границы продукта в методе функциональных точек

К логическим данным системы относятся:

- Внутренние логические файлы (ILFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, которые поддерживаются внутри продукта.
- Внешние интерфейсные файлы (EIFs) — выделяемые пользователем логически связанные группы данных или блоки управляющей информации, на которые ссылается продукт, но которые поддерживаются вне продукта.

Примером логических данных (информационных объектов) могут служить: клиент, счет, тарифный план, услуга.

5 Подсчет функциональных точек, связанных с данными

Третий шаг — подсчет функциональных точек, связанных с данными. Сначала определяется сложность данных по следующим показателям:

- DET (data element type) — неповторяемое уникальное поле данных, например, Имя Клиента — 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) — 9 DET's
- RET (record element type) — логическая группа данных, например, адрес, паспорт, телефонный номер.

Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности (таблица 7).
Таблица 7 Матрица сложности данных

| 1-19 DET | 20-50 DET | 50+ DET
--- | --- | --- | ---
1 RET | Low | Low | Average
2-5 RET | Low | Average | High
6+ RET | Average | High | High

Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) (таблица 8) в зависимости от их сложности.
Таблица 8
Оценка данных в не выровненных функциональных точках (UFP) для внутренних логических файлов (ILFs) и внешних интерфейсных файлов (EIFs)

Сложность данных | Количество UFP (ILF) | Количество UFP (EIF)
--- | --- | ---
Low | 7 | 5
Average | 10 | 7
High | 15 | 10

Для иллюстрации рассмотрим пример оценки в не выровненных функциональных точках объекта данных «Клиент» (рисунок 39).

Рисунок 39. Пример оценки в не выровненных функциональных точках объекта данных «Клиент».

Объект «Клиент» содержит четыре логических группы данных, которые в совокупности состоят из 15 неповторяемых уникальное полей данных. Согласно матрице (таблица 7), нам следует оценить сложность этого объекта данных, как «Low». Теперь, если оцениваемый объект относится к внутренним логическим файлам, то согласно Таблица 8 его сложность будет 7 не выровненных функциональных точек (UPF). Если же объект является внешним интерфейсным файлом, то его сложность составит 5 UPF.

6 Подсчет функциональных точек, связанных с транзакциями

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

Транзакция— это элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое.
В методе различаются следующие типы транзакций (таблица 9):

- EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне.
- EO (external outputs) — внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF.
- • EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

Таблица 9 Основные отличия между типами транзакций. Легенда: О — основная; Д — дополнительная; NA — не применима.

Функция | Тип транзакции
--- | ---
Изменяет поведение системы | I | O | Q
Изменяет поведение системы |  |  | A
Поддержка одного или более ILF |  |  | A
Представление информации пользователю |  |  |

Оценка сложности транзакции основывается на следующих ее характеристиках:

- FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции.
- DET (data element type) — неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.

Для оценки сложности транзакций служат матрицы, которые представлены в таблица 10 и таблица 11.
Таблица 10 Матрица сложности внешних входных транзакций (EI)

EI | 1-4 DET | 5-15 DET | 16+ DET
--- | --- | --- | ---
0-1 FTR | Low | Low | Average
2 FTR | Low | Average | High
3+ FTR | Average | High | High

Таблица 11
Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ)

EO & EQ | 1-5 DET | 6-19 DET | 20+ DET
--- | --- | --- | ---
0-1 FTR | Low | Low | Average
2-3 FTR | Low | Average | High
4+ FTR | Average | High | High

Оценка транзакций в не выровненных функциональных точках (UFP) может быть получена из матрицы (таблица 12)
Таблица 12
Сложность транзакций в не выровненных функциональных точках (UFP)

Сложность транзакций | Количество UFP (EI & EQ) | Количество UFP (EO)
--- | --- | ---
Low | 3 | 4
Average | 4 | 5
High | 6 | 7

В качестве примера, рассмотрим оценку управляющей транзакции (EI) для диалогового окна, задающего параметры проверки орфографии в MS Office Outlook (рисунок 40).

Рисунок 40. Диалоговое окно, управляющее проверкой орфографии в MS Office Outlook

Каждый "Check box" оценивается, как 1 DET. Выпадающий список — 1 DET. Каждая управляющая кнопка должна рассматриваться как отдельная транзакция. Например, если оценивать управляющую транзакцию по кнопке «OK», то, для данной транзакции мы имеем 1 FTR и 8 DET. Поэтому, согласно матрице (Таблица 10), мы можем оценить сложность транзакции, как Low. И, наконец, в соответствие с матрицей (Таблица 12), данная транзакция должна быть оценена в 3 не выровненных функциональных точек (UFP).

7 Определение суммарного количества не выровненных функциональных точек (UFP)

Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ).

Определение значения фактора выравнивания (FAV)
Помимо функциональных требований на продукт накладываются общесистемные требования, которые ограничивают разработчиков в выборе решения и увеличивают сложность разработки. Для учета этой сложности применяется фактор выравнивания (VAF). Значение фактора VAF зависит от 14 параметров, которые определяют системные характеристики продукта:

- Обмен данными (0 — продукт представляет собой автономное приложение; 5 — продукт обменивается данными по более, чем одному телекоммуникационному протоколу).
- Распределенная обработка данных (0 — продукт не перемещает данные; 5 — распределенная обработка данных выполняется несколькими компонентами системы).
- Производительность (0 — пользовательские требования по производительности не установлены; 5 — время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа.
- Ограничения по аппаратным ресурсам (0 — нет ограничений; 5 — продукт целиком должен функционировать на определенном процессоре и не может быть распределен).
- Транзакционная нагрузка (0 — транзакций не много, без пиков; 5 — число транзакций велико и неравномерно, требуются специальные решения и инструменты).
- Интенсивность взаимодействия с пользователем (0 — все транзакции обрабатываются в пакетном режиме; 5 — более 30% транзакций — интерактивные).
- Эргономика(эффективность работы конечных пользователей) (0 — нет специальных требований; 5 — требования по эффективности очень жесткие).
- Интенсивность изменения данных (ILF) пользователями (0 — не требуются; 5 — изменения интенсивные, жесткие требования по восстановлению).
- Сложность обработки (0 — обработка минимальна; 5 — требования безопасности, логическая и математическая сложность, многопоточность).
- Повторное использование (0 — не требуется; 5 — продукт разрабатывается как стандартный многоразовый компонент).
- Удобство инсталляции (0 — нет требований; 5 — установка и обновление ПО производится автоматически).
- Удобство администрирования (0 — не требуется; 5 — система автоматически самовосстанавливается).
- Портируемость0 — продукт имеет только 1 инсталляцию на единственном процессоре; 5 — система является распределенной и предполагает установку на различные «железо» и ОС).
- Гибкость(0 — не требуется; 5 — гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:
TDI = ? DI
Расчет значения фактора выравнивания производится по формуле
VAF = (TDI *0.01) + 0.65
Например, если, каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) + 0.65 = 1.07

8 Расчет количества выровненных функциональных точек (AFP)

Дальнейшая оценка в выровненных функциональных точках зависит от типа оценки. Начальное оценка количества выровненных функциональных точек для программного приложения определяется по следующей формуле:
AFP = UFP * VAF.
Она учитывает только новую функциональностсть, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле:
DFP = (UFP + CFP) * VAF,
где CFP (conversion functional point) — функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных. Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле:
EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB), где

- ADD — функциональные точки для добавленной функциональности;
- CHGA — функциональные точки для измененных функций, рассчитанные после модификации;
- VAFA — величина фактора выравнивания рассчитанного после завершения проекта;
- DEL — объем удаленной функциональности;
- VAFB — величина фактора выравнивания рассчитанного до начала проекта.

Суммарное влияние процедуры выравнивания лежит в пределах ±35% относительно объема рассчитанного в UFP. Метод анализа функциональных точек ничего не говорит о трудоемкости разработки оцененного продукта. Вопрос решается просто, если компания разработчик имеет собственную статистику трудозатрат на реализацию функциональных точек. Если такой статистики нет, то для оценки трудоемкости и сроков проекта можно использовать метод COCOMO II.

9 Основы методики COCOMO II

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

- SIZE — размер продукта в KSLOC
- EMi — множители трудоемкости
- SFj — факторы масштаба
- n=7 — для предварительной оценки
- n=17 — для детальной оценки

Главной особенностью методики является то, что для того, чтобы оценить трудоемкость, необходимо знать размер программного продукта в тысячах строках исходного кода (KSLOC, Kilo Source Lines Of Code). Размер программного продукта может быть, например, оценен экспертами с применением метода PERT. Если мы провели анализ продукта методом функциональных точек, то его размер может быть рассчитан с использованием собственных статистических данных или с использованием статистики по отрасли (таблица 13).
Таблица 13
Оценка количества строк, необходимых на реализацию одной не выровненной функциональной точки для некоторых распространенных языков программирования.

Язык программирования | Наиболее вероятная | Оптимистичная | Пессимистичная
--- | --- | --- | ---
Assembler | 172 | 86 | 320
C | 148 | 9 | 704
C++ | 60 | 29 | 178
C# | 59 | 51 | 66
J2EE | 61 | 50 | 100
JavaScript | 56 | 44 | 65
PL/SQL | 46 | 14 | 110
Visual Basic | 50 | 14 | 276

10 Факторы масштаба

В методике используются пять факторов масштаба SF;, которые определяются следующими характеристиками проекта:
1. PREC — прецедентность, наличие опыт аналогичных разработок (Very Low — опыт в продукте и платформе отсутствует; Extra High — продукт и платформа полностью знакомы)
2. FLEX — гибкость процесса разработки (Very Low — процесс строго детерминирован; Extra High — определены только общие цели).
3. RESL — архитектура и разрешение рисков (Very Low — риски неизвестны/не проанализированы; Extra High — риски разрешены на 100%)
4. TEAM — сработанность команды (Very Low — формальные взаимодействия; Extra High — полное доверие, взаимозаменяемость и взаимопомощь).
5. PMAT — зрелость процессов (Very Low — CMM Level 1; Extra High — CMM Level 5)

Значение фактора масштаб, в зависимости от оценки его уровня, приведены в таблица 14
Таблица 14
Значение фактора масштаба, в зависимости от оценки его уровня

Фактор масштаба | Оценка уровня фактора
--- | ---
Very Low | Low | Nominal | High | Very High | Extra High
PREC | 6.20 | 4.96 | 3.72 | 2.48 | 1.24 | 0.00
FLEX | 5.07 | 4.05 | 3.04 | 2.03 | 1.01 | 0.00
RESL | 7.07 | 5.65 | 4.24 | 2.83 | 1.41 | 0.00
TEAM | 5.48 | 4.38 | 3.29 | 2.19 | 1.10 | 0.00
PMAT | 7.80 | 6.24 | 4.68 | 3.12 | 1.56 | 0.00

11 Множители трудоемкости

В нашу задачу не входит детальное описание метода COCOMO II, поэтому мы рассмотрим только случай предварительной оценки трудоемкости программного проекта. Для этой оценки необходимо оценить для проекта уровень семи множителей трудоемкости M,-:
1. PERS — квалификация персонала (Extra Low — аналитики и программисты имеют низшую квалификацию, текучесть больше 45%; Extra High — аналитики и программисты имеют высшую квалификацию, текучесть меньше 4%)
2. RCPX — сложность и надежность продукта (Extra Low — продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется; Extra High — продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация требуется в полном объеме)
3. RUSE — разработка для повторного использования (Low — не требуется; Extra High — требуется переиспользование в других продуктах)
4. PDIF — сложность платформы разработки (Extra Low — специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; Extra High — жесткие ограничения по памяти и быстродействию, платформа нестабильна)
5. PREX — опыт персонала (Extra Low — новое приложение, инструменты и платформа; Extra High — приложение, инструменты и платформа хорошо известны)
6. FCIL — оборудование (Extra Low — инструменты простейшие, коммуникации затруднены; Extra High — интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации)
7. SCED — сжатие расписания (Very Low — 75% от номинальной длительности; Very High — 160% от номинальной длительности)

Влияние множителей трудоемкости в зависимости от их уровня определяется их числовыми значениями, которые представлены в матрице, приведенной ниже, (таблица 15).
Таблица 15
Значения множителей трудоемкости, в зависимости от оценки их уровня

| Оценка уровня множителя трудоемкости
--- | ---
Extra Low | Very Low | Low | Nominal | High | Very High | Extra High
PERS | 2.12 | 1.62 | 1.26 | 1.00 | 0.83 | 0.63 | 0.5
RCPX | 0.49 | 0.60 | 0.83 | 1.00 | 1.33 | 1.91 | 2.72
RUSE | n/a | n/a | 0.95 | 1.00 | 1.07 | 1.15 | 1.24
PDIF | n/a | n/a | 0.87 | 1.00 | 1.29 | 1.81 | 2.61
PREX | 1.59 | 1.33 | 1.22 | 1.00 | 0.87 | 0.74 | 0.62
FCIL | 1.43 | 1.30 | 1.10 | 1.0 | 0.87 | 0.73 | 0.62
SCED | n/a | 1.43 | 1.14 | 1.00 | 1.00 | 1.00 | n/a

Из этой таблицы, в частности, следует, если в нашем проекте низкая квалификация аналитиков, то его трудоемкость возрастет примерно в 4 раза по сравнению с проектом, в котором участвуют аналитики экстра-класса. И это не выдумки теоретиков, а отраслевая статистика!

12 Оценка многокомпонентного продукта

Как мы отмечали ранее, для того чтобы адекватно спланировать проект и оценить его трудоемкость, необходимо выполнить предварительное проектирование программного продукта. В результате декомпозиции мы получаем некоторое количество компонентов (N), которые составляют программный продукт. Следует понимать, что суммарная трудоемкость проекта не равна простой сумме трудоемкостей разработки каждого из компонентов:
Простая сумма не учитывает взаимосвязи компонентов и трудозатраты на их интеграцию. Методика COCOMO II определяет следующую последовательность вычисления трудоемкости проекта при многокомпонентной разработке.

- Суммарный размер продукта рассчитывается, как сумма размеров его компонентов:
- Базовая трудоемкость проекта рассчитывается по формуле:
- Затем рассчитывается базовая трудоемкость каждого компонента:
- На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED.
- И, наконец, итоговая трудоемкость проекта определятся по формуле:

Оценка длительности проекта
Длительность проекта в методике COCOMO II рассчитывается по формуле:
где

- С = 3,67; D = 0,28;
- PMNS — трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.

Выводы

Оценка трудоемкости должна быть вероятностным утверждением. Это означает, что для нее существует некоторое распределение вероятности, которое может быть очень широким, если неопределенность высокая, или достаточно узким, если неопределенность низкая. Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат. Если собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то необходимо использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:

- FPA IFPUG — метод функциональных точек,
- метод COCOMO II, Constructive Cost Model.

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