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

⇐ ПредыдущаяСтр 6 из 6

СОСОМО 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. Оценки их возможностей становятся номинальными, а соответствующие множители затрат принимают единичные значения:

EM_ACAP=EM_PCAP=1.

Следствием такого решения является возрастание множителя поправки М_р= 1, 507, а также затрат и стоимости:

ЗАТРАТЫ = З6х 1, 507 = 54 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х$5000 = $270 000,

Проигрыш_ в_стоимости = $36 000.

Сценарий наращивания памяти

Положим, что разработчик предложил нарастить память —

купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт).

Это меняет ограничение памяти (используется не 70%, а 47%), после чего фактор STOR снижается до номинального:

EM_STOR=1-> М_р =1, 026,

ЗАТРАТЫ = 36x1, 026 = 37 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000,

Выигрыш_ в_стоимости = $ 12 000.

Сценарий использования нового микропроцессора

Положим, что заказчик предложил использовать новый, более дешевый МП (дешевле на $1000).

Опыт работы с его языком и утилитами понижается от номинального до очень низкого и EM_LTEX ⁼ 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, 58^{1/1, 16} = 8, 872 [KLOC].

Другие решения:

q уменьшить требуемую надежность с номинальной до низкой. Это сокращает стоимость проекта на 12% (EM_RELY изменяется с 1 до 0, 88). Такое решение приведет к увеличению затрат и трудностей при применении и сопровождении;

q повысить требования к квалификации аналитиков и программистов (с высоких до очень высоких). При этом стоимость проекта уменьшается на 15-19%. Благодаря программисту стоимость может уменьшиться на (1 - 0, 74/0, 87) х 100% = 15%. Благодаря аналитику стоимость может понизиться на (1 - 0, 67/0, 83) х 100% = 19%. Основная трудность — поиск специалистов такого класса (готовых работать за те же деньги);

q повысить требования к опыту работы с приложением (с номинальных до очень высоких) или требования к опыту работы с платформой (с низких до высоких). Повышение опыта работы с приложением сокращает стоимость проекта на (1- 0, 81) х 100% = 19%; повышение опыта работы с платформой сокращает стоимость проекта на (1 - 0, 88/1, 12) х 100% = 21, 4%. Основная трудность — поиск экспертов (специалистов такого класса);

q повысить уровень мультисетевой разработки с низкого до высокого. При этом стоимость проекта уменьшается на (1 - 0, 92/1, 1) х 100% = 16, 4%;

q ослабить требования к режиму работы в реальном времени. Предположим, что 70%-ное ограничение по времени выполнения связано с желанием заказчика обеспечить обработку одного сообщения за 2 мс. Если же заказчик согласится на увеличение среднего времени обработки с 2 до 3 мс, то ограничение по времени станет равно (2 мс/3 мс) х 70% = 47%, в результате чего фактор TIME уменьшится с высокого до номинального, что приведет к экономии затрат на (1- 1/1, 11) х 100%= 10%;

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

Какое же решение следует выбрать? Наиболее целесообразное решение — исключение отдельных функций продукта. Вторым (по предпочтительности) решением является повышение уровня мультисетевой разработки (все равно это придется сделать в ближайшее время). В качестве третьего решения можно рассматривать ослабление требований к режиму работы в реальном времени. Принятие же других решений зависит от наличия необходимых специалистов или средств разработки. Впрочем, окончательное решение должно выбираться в процессе переговоров с заказчиком, когда учитываются все соображения.

Выводы.

1. Факторы затрат оказывают существенное влияние на выходные параметры программного проекта.

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

3. Модель СОСОМО II обеспечивает перевод качественного обоснования решения менеджера на количественные рельсы, тем самым повышая объективность принимаемого решения.

Контрольные вопросы

1. Что такое мера?

2. Что такое метрика?

3. Что такое выполнение оценки программного проекта?

4. Что такое анализ риска?

5. Что такое трассировка и контроль?

6. Охарактеризуйте содержание Work Breakdown Structure.

7. Охарактеризуйте рекомендуемое правило распределения затрат проекта.

8. Какие размерно-ориентированные метрики вы знаете?

9. Для чего используют размерно-ориентированные метрики?

10. Определите достоинства и недостатки размерно-ориентированных метрик.

11. Что такое функциональный указатель?

12. От каких информационных характеристик зависит функциональный указатель?

13. Как вычисляется количество функциональных указателей?

14. Что такое коэффициенты регулировки сложности в метрике количества функциональных указателей?

15. Определите достоинства и недостатки функционально-ориентированных метрик.

16. Можно ли перейти от FP-оценок к LOC-оценкам?

17. Охарактеризуйте шаги оценки проекта на основе LOC- и FP-метрик. Чем отличается наиболее точный подход от наименее точного?

18. Что такое конструктивная модель стоимости? Для чего она применяется?

19. Чем отличается версия СОСОМО 81 от версии СОСОМО II?

20. В чем состоит назначение модели композиции? На каких оценках она базируется?

21. В чем состоит назначение модели раннего этапа проектирования?

22. Охарактеризуйте основное уравнение модели раннего этапа проектирования.

23. Охарактеризуйте масштабные факторы модели СОСОМО II.

24. Как оцениваются масштабные факторы?

25. В чем состоит назначение модели этапа пост-архитектуры СОСОМО II?

26. Чем отличается основное уравнение модели этапа пост-архитектуры от аналогичного уравнения модели раннего этапа проектирования?

27. Что такое факторы затрат модели этапа пост-архитектуры и как они вычисляются?

28. Как определяется длительность разработки в модели СОСОМО II?

29. Что такое анализ чувствительности программного проекта?

30. Как применить модель СОСОМО II к анализу чувствительности?

⇐ Предыдущая 1 2 3 4 56