Анализ чувствительности программного проекта
СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.
Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.
Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.
В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.
Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.
Из таблицы следует, что увеличение затрат в 1,3 раза из-за очень высокой сложности продукта уравновешивается их уменьшением вследствие высокой квалификации аналитика и программиста, а также активного использования программных утилит.
Таблица 2.27. Оценка пост-архитектурных факторов затрат
Фактор
|
Описание
|
Оценка
|
Множитель
|
RELY
|
Требуемая надежность ПО
|
Номинал.
|
1
|
DATA
|
Размер базы данных — 20 Кбайт
|
Низкая
|
0,93
|
CPLX
|
Сложность продукта
|
Очень высок.
|
1,3
|
RUSE
|
Требуемая повторная используемость
|
Номинал.
|
1
|
DOCU
|
Документирование жизненного цикла
|
Номинал.
|
1
|
TIME
|
Ограничения времени выполнения (70%)
|
Высокая
|
1,11
|
STOR
|
Ограничения оперативной памяти (45 из 64 Кбайт, 70%)
|
Высокая
|
1,06
|
PVOL
|
Изменчивость платформы (каждые 6 месяцев)
|
Номинал.
|
1
|
ACAP
|
Возможности аналитика (75%)
|
Высокая
|
0,83
|
PCAP
|
Возможности программиста (75%)
|
Высокая
|
0,87
|
AEXP
|
Опыт работы с приложением (1 год)
|
Номинал.
|
1
|
PEXP
|
Опыт работы с платформой (6 месяцев)
|
Низкая
|
1,12
|
LTEX
|
Опыт работы с языком и утилитами (1 год)
|
Номинал.
|
1
|
PCON
|
Непрерывность персонала ( 1 2% в год)
|
Номинал.
|
1
|
TOOL
|
Активное использование программных утилит
|
Высокая
|
0,86
|
SITE
|
Мультисетевая разработка (телефоны)
|
Низкая
|
1,1
|
SCED
|
Требуемый график разработки
|
Номинал.
|
1
|
Множитель поправки Мр
|
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.
Сценарий использования нового микропроцессора
Положим, что заказчик предложил использовать новый, более дешевый МП (дешевле на $1000). К чему это приведет? Опыт работы с его языком и утилитами понижается от номинального до очень низкого и EMLTEX = 1,22, а разработанные для него утилиты (компиляторы, ассемблеры и отладчики) примитивны и ненадежны (в результате фактор TOOL понижается от высокого до очень низкого и EMТООL= 1,24):
Мр = (1,088 / 0,86) х 1,22 x 1,24 = 1,914,
ЗАТРАТЫ = 36х1,914 = 69[чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $414000,
Проигрыш_в_стоимости = $180000.
Сценарий уменьшения средств на завершение проекта
Положим, что к разработке принят сценарий с наращиванием памяти:
ЗАТРАТЫ = 36 х 1,026 = 37 [чел.-мес],
СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000.
Кроме того, предположим, что завершился этап анализа требований, на который было израсходовано $22 000 (10% от бюджета). После этого на завершение проекта осталось $200 000.
Допустим, что в этот момент «коварный» заказчик сообщает об отсутствии у него достаточных денежных средств и о предоставлении на завершение разработки только $170 000 (15%-ное уменьшение оплаты).
Для решения этой проблемы надо установить возможные изменения факторов затрат, позволяющие уменьшить оценку затрат на 15%.
Первое решение: уменьшение размера продукта (за счет исключения некоторых функций). Нам надо определить размер минимизированного продукта. Будем исходить из того, что затраты должны уменьшиться с 37 до 31,45 чел.-мес. Решим уравнение:
2,5 (НовыйРазмер)1,16= 31,45 [чел.-мес].
Очевидно, что
(НовыйРазмер)1,16 = 12,58,
(НовыйРазмер)1,16 = 12,581/1,16 = 8,872 [KLOC].
Другие решения:
уменьшить требуемую надежность с номинальной до низкой. Это сокращает стоимость проекта на 12% (EMRELY изменяется с 1 до 0,88). Такое решение приведет к увеличению затрат и трудностей при применении и сопровождении;
повысить требования к квалификации аналитиков и программистов (с высоких до очень высоких). При этом стоимость проекта уменьшается на 15-19%. Благодаря программисту стоимость может уменьшиться на (1 - 0,74/0,87) х 100% = 15%. Благодаря аналитику стоимость может понизиться на (1 - 0,67/0,83) х 100% = 19%. Основная трудность — поиск специалистов такого класса (готовых работать за те же деньги);
повысить требования к опыту работы с приложением (с номинальных до очень высоких) или требования к опыту работы с платформой (с низких до высоких). Повышение опыта работы с приложением сокращает стоимость проекта на (1- 0,81) х 100% = 19%; повышение опыта работы с платформой сокращает стоимость проекта на (1 - 0,88/1,12) х 100% = 21,4%. Основная трудность — поиск экспертов (специалистов такого класса);
повысить уровень мультисетевой разработки с низкого до высокого. При этом стоимость проекта уменьшается на (1 - 0,92/1,1) х 100% = 16,4%;
ослабить требования к режиму работы в реальном времени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс) х 70% = 47%, в результате чего фактор TIME уменьшится с высокого до номинального, что приведет к экономии затрат на (1- 1/1,11) х 100%= 10%;
учет других факторов затрат не имеет смысла. Некоторые факторы (размер базы данных, ограничения оперативной памяти, требуемый график разработки) уже имеют минимальные значения, для других трудно ожидать быстрого улучшения (использование программных утилит, опыт работы с языком и утилитами), третьи имеют оптимальные значения (требуемая повторная используемость, документирование требований жизненного цикла). На некоторые разработчик почти не может повлиять (сложность продукта, изменчивость платформы). Наконец, житейские неожиданности едва ли позволят улучшить принятое значение фактора «непрерывность персонала».
Какое же решение следует выбрать? Наиболее целесообразное решение — исключение отдельных функций продукта. Вторым (по предпочтительности) решением является повышение уровня мультисетевой разработки (все равно это придется сделать в ближайшее время). В качестве третьего решения можно рассматривать ослабление требований к режиму работы в реальном времени. Принятие же других решений зависит от наличия необходимых специалистов или средств разработки. Впрочем, окончательное решение должно выбираться в процессе переговоров с заказчиком, когда учитываются все соображения.
Выводы.
1. Факторы затрат оказывают существенное влияние на выходные параметры программного проекта.
2. Модель СОСОМО II предлагает широкий спектр факторов затрат, учитывающих большинство реальных ситуаций в «жизни» программного проекта.
3. Модель СОСОМО II обеспечивает перевод качественного обоснования решения менеджера на количественные рельсы, тем самым повышая объективность принимаемого решения.
|
