Анализ чувствительности программного проекта
СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.
Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.
Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.
В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.
Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.
Из таблицы следует, что увеличение затрат в 1,3 раза из-за очень высокой сложности продукта уравновешивается их уменьшением вследствие высокой квалификации аналитика и программиста, а также активного использования программных утилит.
Таблица 2.27.Оценка пост-архитектурных факторов затрат
| Фактор | Описание | Оценка | Множитель |
| RELY | Требуемая надежность ПО | Номинал. | |
| DATA | Размер базы данных — 20 Кбайт | Низкая | 0,93 |
| CPLX | Сложность продукта | Очень высок. | 1,3 |
| RUSE | Требуемая повторная используемость | Номинал. | |
| DOCU | Документирование жизненного цикла | Номинал. | |
| TIME | Ограничения времени выполнения (70%) | Высокая | 1,11 |
| STOR | Ограничения оперативной памяти (45 из 64 Кбайт, 70%) | Высокая | 1,06 |
| PVOL | Изменчивость платформы (каждые 6 месяцев) | Номинал. | |
| ACAP | Возможности аналитика (75%) | Высокая | 0,83 |
| PCAP | Возможности программиста (75%) | Высокая | 0,87 |
| AEXP | Опыт работы с приложением (1 год) | Номинал. | |
| PEXP | Опыт работы с платформой (6 месяцев) | Низкая | 1,12 |
| LTEX | Опыт работы с языком и утилитами (1 год) | Номинал. | |
| PCON | Непрерывность персонала ( 1 2% в год) | Номинал. | |
| TOOL | Активное использование программных утилит | Высокая | 0,86 |
| SITE | Мультисетевая разработка (телефоны) | Низкая | 1,1 |
| SCED | Требуемый график разработки | Номинал. | |
| Множитель поправки Мр | 1,088 |
Рассчитаем затраты и стоимость проекта:
ЗАТРАТЫ = AхРАЗМЕРBхМр=2,5(10)1,16х1,088=36x1,088= 39[чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $234 000.
Таковы стартовые условия программного проекта. А теперь обсудим несколько сценариев возможного развития событий.
Сценарий понижения зарплаты
Положим, что заказчик решил сэкономить на зарплате разработчиков. Рычаг — понижение квалификации аналитика и программиста. Соответственно, зарплата сотрудников снижается до $5000. Оценки их возможностей становятся номинальными, а соответствующие множители затрат принимают единичные значения:
EMACAP=EMPCAP=1.
Следствием такого решения является возрастание множителя поправки Мр= 1,507, а также затрат и стоимости:
ЗАТРАТЫ = З6х 1,507 = 54 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х$5000 = $270 000,
Проигрыш_ в_стоимости = $36 000.
Сценарий наращивания памяти
Положим, что разработчик предложил нарастить память — купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт). Это меняет ограничение памяти (используется не 70%, а 47%), после чего фактор STOR снижается до номинального:
EMSTOR=1-> Мр =1,026,
ЗАТРАТЫ = 36x1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000,
Выигрыш_ в_стоимости = $ 12 000.