Анализ чувствительности программного проекта

СОСОМО 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.

Наши рекомендации