Материал: DO178 Учебное пособие_в183

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

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

В начале 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

В значении «Номинальный» все эти коэффициенты равны 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 подверглись модификации.

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

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

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

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

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

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

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

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

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

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

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

Модель SLIM (Software LIfe Management – управление жизненным циклом программного продукта) для получения оценок предложил Путнэм (Lawrence H. Putnam) еще в конце 1970-х годов [20]. Эта модель строится на основании исторической БД по выполненным в данной организации проектам и поэтому полнее учитывает ее специфику. Впоследствии модель SLIM несколько раз уточнялась на основании данных от практических разработок и в современном виде определяется следующим образом.

Вводится главное уравнение для программного продукта, связывающее трудоемкость и срок разработки с производительностью, размером продукта и некоторым масштабирующим множителем B, зависящим от этого размера:

Очевидным преобразованием из этого уравнения можно получить выражение для производительности через размер кода, трудоемкость, срок и множитель B:

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

Подставляя в эти уравнения значения Размер_кода_i, Срок_i и Трудоемкость_i из исторической базы данных уже выполненных n проектов, получаем значения множителя B в n точках Размер_кода_i (1≤i≤n), по которым его можно аппроксимировать для нового n+1 проекта. Одновременно получаем и значение производительности, после чего по уже известным значениям B и Производительность получаем уравнение, связывающее оценки значений Срок и Трудоемкость для нового проекта.

Рис. 18. Экспоненциальная зависимость между сроком и трудоемкостью

По данным от наблюдений за более чем 7000 проектов, выполненных Путнэмом к 2006 г., эта зависимость обратно экспоненциальная: трудоемкость экспоненциально убывает при увеличении срока разработки и, наоборот, возрастает при уменьшении этого срока (Рис. 18), что хорошо согласуется с предложенной им моделью SLIM.

4. Разработка спецификации требований

Спецификация требований (Requirements Specification – RS) обычно является первой плановой поставкой вместе с уточненным планом разработки; в ней исходные требования, в том или ином виде содержащиеся уже в SOW или ТЗ, выражены в достаточно объективной и точной форме, допускающей их реализуемость и тестируемость. Поскольку на основании этой спецификации уточняются трудозатраты на разработку и соответственно, уточняется (изменяется) план, то оба эти документа подлежат обязательному утверждению заказчиком.

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