145
Тип: проект среднего диапазона
882
,
0
375
,
0
472
,
0
уппы
ыйРазмерГр
Максимальн
ьныеПункты
Функционал
сяцы
ЧеловекоМе
(12)
Тип: настольная система
810
,
0
591
,
0
157
,
0
уппы
ыйРазмерГр
Максимальн
ьныеПункты
Функционал
сяцы
ЧеловекоМе
(13)
Тип: языки третьего поколения
697
,
0
488
,
0
425
,
0
уппы
ыйРазмерГр
Максимальн
ьныеПункты
Функционал
сяцы
ЧеловекоМе
(14)
Тип: языки четвертого поколения
784
,
0
472
,
0
317
,
0
уппы
ыйРазмерГр
Максимальн
ьныеПункты
Функционал
сяцы
ЧеловекоМе
(15)
Тип: доработка существующих проектов
758
,
0
338
,
0
669
,
0
уппы
ыйРазмерГр
Максимальн
ьныеПункты
Функционал
сяцы
ЧеловекоМе
(16)
Тип: новая разработка
866
,
0
385
,
0
520
,
0
уппы
ыйРазмерГр
Максимальн
ьныеПункты
Функционал
сяцы
ЧеловекоМе
(17)
Интересная особенность
метода ISBSG состоит в том, что
формулы для объема работ зависят от максимального размера
группы, а команды меньшего размера уменьшают общий объем. С
точки зрения оценки это создает неопределенность. С
точки же
146
зрения управления проектом эти изменения могут заставить
использовать группу меньшего размера вместо большей.
Методики подсчета функциональных пунктов могут быть
успешно применены для:
-
определения трудоемкости и стоимости планируемых проектов
разработки программного обеспечения;
-
проведения
сравнительного
анализа
качества
и
производительности
разработки
разнотипных
проектов,
или
однотипных проектов, при выполнении которых использовались
различные технологии,
-
проведения анализа плановой и реальной оценки сложности и
величины разработанного программного обеспечения и трудоемкости
выполнения проекта, получения стандартной метрики сравнения
программных продуктов.
Несмотря на преимущества методов оценки по функциональным
пунктам они имеют ряд недостатков, существенно ограничивающих
возможности применения. Ниже перечислены основные из них:
-
для работы по
методу функциональных пунктов требуются
высококвалифицированные сертифицированные специалисты;
-
расчет
количества
функциональных
пунктов
требует
значительного времени на сбор данных о
системе и получение
полного понимания требований к системе;
-
при применении метода на ранних этапах разработки
многократно понижается точность оценки;
-
метод «интуитивно» не понятен, так как оперирует многими
понятиями,
неиспользуемыми
в
современном
объектно-
ориентированном подходе.
Существуют приложения, в
оценке которых использование
стандартных функциональных пунктов не эффективно:
-
управление процессом в реальном времени;
-
математические вычисления;
147
-
симуляция;
-
системные приложения;
-
инженерные приложения;
-
встроенные системы.
Перечисленные
приложения
отличаются
высокой
интенсивностью вычислений, часто основанных на алгоритмах
повышенной сложности. Для решения задач расчёта размера
указанных приложений в 1986 году
организацией Software
Productivity Research (SPR) была разработана методика анализа
характеристических пунктов ПО (feature points). Сущность ее состоит
в том, что оценивается количество алгоритмов в
программе и
незначительно модифицируется степень значимости для расчёта
функциональных
пунктов.
Эта
методика
считается
экспериментальной.
6.7
Методы COCOMO и COCOMO II
Пожалуй, самой популярной моделью для оценки стоимости
разработки ПО, которая де-факто стала стандартом, является
COCOMO (COnstructive COst MOdel). Она была представлена в 1981
г. Барри Боэмом, известным ученым, внесшим огромный вклад в
развитие научных подходов к управлению программными проектами
– им разработаны спиральная модель проектирования ПО и Wideband
Delphi, кроме того, когда-то именно он предсказал, что в будущем
стоимость ПО превысит стоимость оборудования.
COCOMO создана на основе
анализа статистических данных 63
проектов различных типов. Фактически под общим названием
скрываются три уровня детализации: базовый, промежуточный и
подробный. Также предусмотрено три режима использования модели
в зависимости от размеров команды и проекта (табл. 6.10).