1. Планирование проекта

План разработки (Software Project Management Plan – SPMP) – это проигрывание будущих работ и инструмент для определения роли каждого участника. Он увязывает отдельные части разработки вместе, служит точкой отсчета для изменений и помогает понять, когда цель проекта достигнута, и проект может быть закончен. Этот план строится на основании структуры разбиения и оценок трудозатрат на исполнения выявленных блоков работы.

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

Рис. 15. Дорожная карта для планирования проекта

Получив начальные требования, например, в форме запроса на разработку предложений (Request For Proposal – RFP), исполнитель проводит переговоры с заказчиком, результатом чего являются уже обговоренные начальные требования, подлежащие реализации в проекте и достаточные для разработки структуры разбиения работ. На следующем шаге эти требования уточняются и разносятся по подсистемам будущего продукта. Таким образом, на выходе этого шага появляется структура разбиения работ, которая служит основой для дальнейшего планирования. По структуре разбиения работ и количеству требований, подлежащих реализации в каждом компоненте будущего продукта оценивается объем кода, подлежащий разработке в тысячах строк программного текста KLOC или в их ассемблерном эквиваленте KAELOC. Затем, исходя из полученных оценок и трудоемкости разработки тысячи строк кода (с поправками на сложность, опыт исполнителей и другие факторы), полученной из исторической базы данных исполнителя, оцениваются необходимые трудозатраты в человеко-месяцах и для некоторых проектов – необходимые дополнительные ресурсы по машинному времени. На основании этих данных строится ожидаемый график исполнения работ, учитывающих полученные оценки трудозатрат и взаимосвязи между компонентами в структуре разбиения работ. Заключительным шагом является принятие решения о том, устраивает ли полученный график работ как заказчика, так и исполнителя, и если это не так, то происходит возват к одному из предыдущих шагов для внесения необходимых поправок.

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

2. Модель cocomo для оценки трудозатрат в проекте

Для оценки трудозатрат в программном проекте предложен ряд моделей, наиболее известной из которых является модель издержки затрат COCOMO – COnstructive COst MOdel, предложенная Боэмом. В своем базовом варианте эта модель различает всего три типа программных проектов:

• Органический (organic): маленькая команда с опытом и нежесткими требованиями

• Полуразделенный (semi-detached): средний размер команды, смешанные опыт и требования

• Встроенный (embedded): много жестких требований, что особенно характерно для встроенных применений

Модель COCOMO предлагает следующие три формулы для расчета важнейших плановых показателей:

Где коэффициенты a_b, b_b, c_b и d_b разные для разных типов проектов и определены усреднением по очень большой выборке конкретных программных проектов, выполненных в разное время разными разработчиками:

Табл. 6. Коэффициенты базовой модели COCOMO

Тип проекта	ab	bb	cb	db
Органический	2,4	1,05	2,5	0,38
Полуразделенный	3,0	1,12	2,5	0,35
Встроенный	4,6	1,20	2,5	0,32

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

В начале 2000-х готов была предложена более развитая модель COCOMO II, учитывающая значительно большее число характеристик программного проекта и в силу этого дающая более точные оценки. На базе этой модели в университете Южной Калифорнии (США) разработан инструмент COCOMO II для свободного использования, доступный по ссылке http://csse.usc.edu/tools/COCOMOII.php .

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

Новой группой входных данных для оценки трудоемкости, по сравнению с базовой моделью COCOMO, являются так называемые масштабируемые показатели программного обеспечения, подлежащего разработке. В так называемой промежуточной модели (intermediate model) COCOMO II их значения выбираются по 6-ти бальной шкале: очень низкий, низкий, номинальный, высокий, очень высокий и сверхвысокий. В виде числовых множителей эти значения входят в общую формулу для трудоемкости как сомножители поправочного коэффициента EAF (effort adjustment factor), который изменяется в диапазоне от 0,9 до 1,4:

где коэффициенты a_i и b_i те же, что и a_b и b_b, в базовой модели, за исключением органического: a_i = 3,2 и встроенного: a_i = 2,8 проектов. Формулы для оценки срока разработки и числа разработчиков и соответствующие коэффициенты c_i и d_i в промежуточной модели те же, что и c_b и d_b в базовой модели. Значения новых 15 показателей, влияющих на стоимость разработки, приведены в Табл. 7.

Табл. 7. Стоимостные атрибуты разработки в модели COCOMO II

Название атрибута	очень низкий	низкий	номи-нальный	высокий	очень высокий	сверх-высокий
Атрибуты продукта – Product attributes
Требуемая надежность ПО – Required software reliability	0,75	0,88	1,00	1,15	1,40
Размер базы данных приложения – Size of application database		0,94	1,00	1,08	1,16
Сложность продукта – Complexity of the product	0,70	0,85	1,00	1,15	1,30	1,65
Атрибуты команды разработчиков – Personnel attributes
Способности аналитика – Analyst capability	1,46	1,19	1,00	0,86	0,71
Способности программиста – Software engineer capability	1,42	1,17	1,00	0,86	0,70
Опыт разработки приложений – Applications experience	1,29	1,13	1,00	0,91	0,82
Опыт работы на данном языке программирования – Programming language experience	1,14	1,07	1,00	0,95
Опыт работы с витруальной машиной – Virtual machine experience	1,21	1,10	1,00	0,90
Атрибуты платформы – Hardware attributes
Ограничения времени исполнения – Run-time performance constraints			1,00	1,11	1,30	1,66
Ограничения по размеру памяти – Memory constraints			1,00	1,06	1,21	1,56
Изменчивость среды виртуальной машины – Volatility of the virtual machine environment		0,87	1,00	1,15	1,30
Требуемое время оборачива-емости – Required turnabout time		0,87	1,00	1,07	1,15
Атрибуты проекта – Project attributes
Использование программных инструментальных средств – Use of software tools	1,24	1,10	1,00	0,91	0,83
Применение методов технологии программирования – Application of software engineering methods	1,24	1,10	1,00	0,91	0,82
Выдерживание требуемого графика разработки – Required development schedule	1,23	1,08	1,00	1,04	1,10

В значении «Номинальный» все эти коэффициенты равны 1 и отклоняются в ту или иную сторону для понижающих или повышающих оценок.

В так называемой продвинутой модели (advanced model), используемой в инструменте COCOMO II, дополнительно учитываются следующие показатели:

• Атрибуты продукта – Product attributes

• Разработка повторно используемого кода – Developed for reusability;

• Документация отвечает потребностям жизненного цикла – Documentation match to life cycle needs;

• Атрибуты команды разработчиков – Personnel attributes

• Опыт совместной работы данного коллектива – Personnel continuity;

• Опыт работы с данной платформой – Platform experience;

• Атрибуты проекта – Project attributes

• Ведение разработки на нескольких площадках – Multi-site development.

Эта модель также оценивает распределение трудозатрат по фазам проекта. На Рис. 16 приведен расчет для проекта на 100 KLOC, из которых 30 KLOC использованы повторно, причем 5 KLOC подверглись модификации.

Software Development (Elaboration and Construction) – Разработка ПО ( фазы уточнения ТЗ и создания продукта) Effort = 481.1 Person-months Schedule = 28.2 Months Cost = $1202750 Total Equivalent Size = 103080 SLOC Acquisition Phase Distribution Phase Effort (Person-Months) Sched-ule (Months) Ave-rage Staff Cost (Dollars) Inception 28.1 3.5 8.2 $72165 Elaboration 115.5 10.6 10.9 $288660 Construction 365.6 17.6 20.8 $914090 Transition 57.7 3.5 16.4 $144330

Acquisition – получение продукта с нуля Inception – начальная фаза, запуск проекта Elaboration – уточнение и проработка ТЗ Construction – собственно создание продукта Transition – переход продукта к заказчику Software Effort Distribution for RUP/MBASE (Person-Months) Phase/Activity Incep-tion Elabora-tion Construc-tion Transi-tion Management 4.0 13.9 36.6 8.1 Environment/CM 2.1 9.2 18.3 2.9 Requirements 11.0 20.8 29.3 2.3 Design 5.5 41.6 58.5 2.3 Implementation 2.3 15.0 124.3 11.0 Assessment 2.3 11.5 87.8 13.8 Deployment 0.9 3.5 11.0 17.3

Рис. 16. Пример расчета трудоемкости по модели COCOMO II

Модель также строит график потребности проекта в разработчиках, пример такого графика для того же проекта приведен на Рис. 17.

Рис. 17. Пример потребности проекта в разработчиках в модели COCOMO II

В продвинутой модели COCOMO II, кроме того, наряду с показателями стоимости, учитываются еще и показатели масштаба ПО (Software Scale Drivers), значения которых также задаются по 6-ти бальной шкале, и к которым относятся:

• Наличие опыта аналогичных разработок – Precedentness;

• Гибкость самой разработки – Development flexibility;

• Возможность принимать решения по архитектуре и рискам – Architectural/risk resolution;

• Сплоченность команды разработчиков – Team cohesion;

• Уровень зрелости процесса разработки – Process maturity.

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