Сценарий уменьшения средств на завершение проекта

Положим, что к разработке принят сценарий с наращиванием памяти:

ЗАТРАТЫ = 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 к анализу чувствительности?

ГЛАВА 3. Классические методы анализа

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

Структурный анализ

Структурный анализ — один из формализованных методов анализа требований к ПО. Автор этого метода — Том Де Марко (1979) [27]. В этом методе программное изделие рассматривается как преобразователь информационного потока данных. Основной элемент структурного анализа — диаграмма потоков данных.

Диаграммы потоков данных

Диаграмма потоков данных ПДД — графическое средство для изображения информационного потока и преобразований, которым подвергаются данные при движении от входа к выходу системы. Элементы диаграммы имеют вид, показанный на рис. 3.1. Диаграмма может использоваться для представления программного изделия на любом уровне абстракции.

Пример системы взаимосвязанных диаграмм показан на рис. 3.2.

Диаграмма высшего (нулевого) уровня представляет систему как единый овал со стрелкой, ее называют основной или контекстной моделью. Контекстная модель используется для указания внешних связей программного изделия. Для детализации (уточнения системы) вводится диаграмма 1-го уровня. Каждый из преобразователей этой диаграммы — подфункция общей системы. Таким образом, речь идет о замене преобразователя F на целую систему преобразователей.

Дальнейшее уточнение (например, преобразователя F3) приводит к диаграмме 2-го уровня. Говорят, что ПДД1 разбивается на диаграммы 2-го уровня.

Рис. 3.2.Система взаимосвязанных диаграмм потоков данных

ПРИМЕЧАНИЕ

Важно сохранить непрерывность информационного потока и его согласованность. Это значит, что входы и выходы у каждого преобразователя на любом уровне должны оставаться прежними. В диаграмме отсутствуют точные указания на последовательность обработки. Точные указания откладываются до этапа проектирования.

Диаграмма потоков данных — это абстракция, граф. Для связи графа с проблемной областью (превращения в граф-модель) надо задать интерпретацию ее компонентов — дуг и вершин.