Модель этапа постархитектуры

 

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

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

ЗАТРАТЫ = А х К_~req х РАЗМЕР ^B х М_р +3ATPATЫ_auto [чел.-мес],

где

q коэффициент К_~req учитывает возможные изменения в требованиях;

q показатель В отражает нелинейную зависимость затрат от размера проекта (размер выражается в KLOC), вычисляется так же, как и в предыдущей модели;

q в размере проекта различают две составляющие — новый код и повторно используемый код;

q множитель поправки М_р зависит от 17 факторов затрат, характеризующих продукт, аппаратуру, персонал и проект.

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

К_~req =l + (BRAK/100),

где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований.

Размер проекта и продукта определяют по выражению

РАЗМЕР = PA3MEP_new + PA3MEP_reuse [KLOC],

где

q PA3MEP_new — размер нового (создаваемого) программного кода;

q PA3MEP_reuse — размер повторно используемого программного кода.

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

PA3MEP_reuse =KASLOC x ((100 - AT) /100) x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM)/100,

где

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

q AT — процент автоматически генерируемого кода;

q DM — процент модифицируемых проектных моделей;

q CM — процент модифицируемого программного кода;

q IM — процент затрат на интеграцию, требуемых для подключения повторно используемого ПО;

q SU — фактор, основанный на стоимости понимания добавляемого ПО; изменяется от 50 (для сложного неструктурированного кода) до 10 (для хорошо написанного объектно-ориентированного кода);

q АА — фактор, который отражает стоимость решения о том, может ли ПО быть повторно используемым; зависит от размера требуемого тестирования и оценивания (величина изменяется от 0 до 8).

Правила выбора этих параметров приведены в руководстве по СОСОМО II.

Для определения множителя поправки М_р основного уравнения используют 17 факторов затрат, которые могут быть разбиты на 4 категории. Перечислим факторы затрат, сгруппировав их по категориям.

Факторы продукта:

1) требуемая надежность ПО — RELY;

2) размер базы данных — DATA;

3) сложность продукта — CPLX;

4) требуемая повторная используемость — RUSE;

5) документирование требований жизненного цикла — DOCU.

Факторы платформы (виртуальной машины):

6) ограничения времени выполнения — TIME;

7) ограничения оперативной памяти — STOR;

8) изменчивость платформы — PVOL.

Факторы персонала:

9) возможности аналитика — АСАР;

10) возможности программиста — РСАР;

11) опыт работы с приложением — АЕХР;

12) опыт работы с платформой — РЕХР;

13) опыт работы с языком и утилитами — LTEX;

14) непрерывность персонала — PCON.

Факторы проекта:

15) использование программных утилит — TOOL;

16) мультисетевая разработка — SITE;

17) требуемый график разработки — SCED.

Для каждого фактора определяется оценка (по 6-балльной шкале). На основе оценки для каждого фактора по таблице Боэма определяется множитель затрат ЕМ_i. Перемножение всех множителей затрат дает множитель поправки пост-архитектурной модели:

.

Значение М_р отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат.

 

ПРИМЕЧАНИЕ

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

 

От оценки затрат легко перейти к стоимости проекта. Переход выполняют по формуле:

СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ,

где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц.

После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо:

Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)^{(0,33+0,2( B -1,01))}] х SCEDPercentage/100 [мес],

где

q В — ранее рассчитанный показатель степени;

q SCEDPercentage — процент увеличения (уменьшения) номинального графика.

Если нужно определить номинальный график, то принимается SCEDPercentage =100 и правый сомножитель в уравнении обращается в единицу. Следует отметить, что СОСОМО II ограничивает диапазон уплотнения/растягивания графика (от 75 до 160%). Причина проста — если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска.

Рассмотрим пример. Положим, что затраты на проект равны 20 человеко-месяцев. Примем, что все масштабные факторы номинальны (имеют значения 3), поэтому, в соответствии с табл. 2.20, показатель степени 5=1,16. Отсюда следует, что номинальная длительность проекта равна

TDEV = 3, Ox (20)^0,36 = 8,8 мес.

Отметим, что зависимость между затратами и количеством разработчиков носит характер, существенно отличающийся от линейного. Очень часто увеличение количества разработчиков приводит к возрастанию затрат. В чем причина? Ответ прост:

q увеличивается время на взаимодействие и обучение сотрудников, согласование совместных решений;

q возрастает время на определение интерфейсов между частями программной системы.

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

СОСОМО II предостерегает от определения потребного количества сотрудников путем деления затрат на длительность проекта. Такой упрощенный подход часто приводит к срыву работ. Реальная картина имеет другой характер. Количество людей, требуемых на этапе планирования и формирования требований, достаточно мало. На этапах проектирования и кодирования потребность в увеличении команды возрастает, после окончания кодирования и тестирования численность необходимых сотрудников достигает минимума.