Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие

153 
Продолжение таблицы 6.13 
TEAM 
– 
Сплоченно
сть 
команды 
Сильно 
затрудне-
нное 
взаимо-
действие 
Несколько 
затрудне-
нное 
взаимодей
ствие 
Некоторая 
согласо-
ванность 
Повыше-
нная 
согласо-
ванность 
Высокая 
согласо-
ванность 
Взаимо-
действие 
как 
единого 
целого 
PMAT 
–
Зрелость 
процесса 
Уровень 1 
Уровень 2 
Уровень 2+ 
Уровень 
3 
Уровень 4 
Уровень 5 
EM (Effort Multipliers) — произведение семи коэффициентов 
затрат, каждый из которых лежит в интервале от 1 до 6:
- 
возможности персонала; 
- 
надежность и сложность продукта; 
- 
требуемый уровень повторного использования; 
- 
сложность платформы; 
- 
опытность персонала; 
- 
использование инструментов; 
- 
плотность графика проекта. 
Для времени (в месяцах): 
))
91
,
0
(
2
,
0
28
,
0
(





B
PM
T
TDEV
(24) 
Коэффициент T равен 3,67. PM (Person Months) обозначает 
оценку трудоемкости. 
3.
После того, как разработана архитектура ПО, оценки должны 
выполняться с использованием постархитектурной модели (Post-
Architecture Model).
Формула для трудоемкости (в человеко-месяцах): 





i
i
B
req
EM
Size
K
A
PM
)
(
(25) 

154 
Для времени — та же формула, что и в предыдущей модели (в 
месяцах):
))
91
,
0
(
2
,
0
28
,
0
(





B
PM
T
TDEV
(26) 
Коэффициент K
req
вычисляется как: 
100
й)
требовани
изменения
за
-
из
кода
го
выброшенно
(%
1


req
K
(27) 
100
)
3
,
0
3
,
0
4
,
0
(
100
AT
-
100
код)
ьзуемый
(переиспол
код)
(новый
SU
IM
CM
DM
AA
Size








(29) 
где AT — процент автоматически генерируемого кода; 
AA — фактор трудоемкости перевода компонентов в повторно 
используемые, от 0 до 8; 
DM — процент модифицируемых для переиспользования 
проектных моделей; 
CM — процент модифицируемого для переиспользования кода; 
IM — процент затрат на интеграцию и тестирование повторно 
используемых компонентов; 
SU — фактор понятности переиспользуемого кода, от 10 для 
простого, хорошо структурированного, до 50 для сложного и 
непонятного; равен 0, если CM = DM = 0. 
EM
i
– затратные коэффициенты (в Постархитектурной модели 
их 17):

155 
Таблица 6.14 - Рейтинги и степень влияния регулирующих 
факторов COCOMO II 
Фактор 
Описание 
Рейтинги 
В
ли
ян
и
е 
О
чен
ь 
ни
зкие
 
Ни
зки
е 
Номи
н
альн
ые
 
В
ыс
ок
и
е 
Оче
н
ь 
выс
ок
и
е 
Ч
р
езвы
ч
ай
н
о 
выс
ок
и
е 
Продукт 
RELY – 
Требуемая 
надежность 
программного 
обеспечения 
Учитывает меру 
выполнения
программой 
задуманного действия в 
течение определенного 
времени
0,82 
0,92 1,00 1,10 1,26 
1,54 
DATA – Размер 
базы данных 
Учитывает влияние 
объёма тестовых 
данных на разработку 
продукта. Уровень 
этого параметра 
рассчитывается как 
соотношение байт в 
тестируемой базе 
данных к SLOC в 
программе 
0,90 1,00 1,14 1,28 
1,42

156 
Продолжение таблицы 6.14
RUSE 
– 
Разработка для 
повторного 
использования 
Учитывает 
трудозатраты, 
требуемые 
дополнительно 
для 
написания 
компонентов, 
предназначенных 
для 
повторного 
использования 
в 
данном 
или 
последующих проектах. 
Использует следующие 
оценочные уровни: “в 
проекте”, 
“в 
программе”, “в линейке 
продуктов”, 
“в 
различных 
линейках 
продуктов”. Значение 
параметра накладывает 
ограничения 
на 
следующие параметры: 
RELY и DOCU
0,95 1,00 1,07 1,15 1,24 1,31 
DOCU – Объем 
необходимой 
документации 
Учитывает 
степень 
соответствия 
документации проекта 
его жизненному циклу
0,81 
0,91 1,00 1,11 1,23 
1,52 
CPLX 
– 
Сложность 
продукта 
Включает пять типов 
операций: управления, 
счетные, 
устройство-
зависимые, управления 
данными, 
управления 
пользовательским 
интерфейсом. Уровень 
сложности 
это 
субъективное 
средне-
взвешенное 
значение 
уровней 
типов 
операций 
0,73 
0,87 1,00 1,17 1,34 1,74 2,38 

157 
Продолжение таблицы 6.14 
Платформа 
TIME 
– 
Ограничения по 
быстродействи
ю 
Учитывает временные 
ресурсы, используемые 
ПО, при выполнении 
поставленной задачи
1,00 1,11 1,29 1,63 1,63 
STOR 
– 
Ограничения по 
объему 
хранимых 
данных 
Учитывает 
процент 
использования 
хранилищ данных 
1,00 1,05 1,17 1,46 1,46 
PVOL 
– 
Неустойчивость 
платформы 
Учитывает срок жизни 
платформы (комплекс 
аппаратного 
и 
программного 
обеспечения, который 
требуется для 
функционирования 
разрабатываемого ПО) 
0,87 1,00 1,15 1,30 
1,49 
Персонал 
ACAP 
– 
Квалификация 
аналитиков по 
требованиям 
Учитывает 
анализ, 
способность 
проектировать, 
эффективность 
и 
коммуникативные 
способности 
группы 
специалистов, которые 
разрабатывают 
требования 
и 
спецификации проекта. 
Параметр не должен 
оценивать 
уровень 
квалификации отдельно 
взятого специалиста 
1,42 
1,19 1,00 0,85 0,71 
2,00 
APEX – Опыт 
работы 
в 
прикладной 
области 
Учитывает 
опыт 
коллектива при работе 
над 
приложениями 
определенного типа 
1,22 
1,10 1,00 0,80 0,81 
1,51 

158 
Продолжение таблицы 6.14 
PCAP 
-
Квалификация 
программистов 
(общая) 
Учитывает 
уровень 
программистов 
в 
коллективе. 
При 
выборе значения для 
этого 
параметра 
следует особо обратить 
внимание 
на 
коммуникативные 
и
профессиональные 
способности 
программистов и на 
командную работу в 
целом 
1,34 
1,15 1,00 0,88 0,76 
1,76 
PEXP – Опыт 
разработки для 
платформы 
Учитывает 
умение 
использовать
особенности платформ, 
такие как графический 
интерфейс, 
базы 
данных, 
сетевой 
интерфейс, 
распределенные 
системы 
1,19 
1,09 1,00 0,91 0,85 
1,40 
LTEX – Навыки 
владения 
языками 
и 
инструментарие
м 
Учитывает 
опыт 
программистов (языки, 
среды и инструменты) 
1,20 
1,09 1,00 0,91 0,84 
1,43 
PCON – 
Постоянство 
персонала 
Учитывает 
текучесть 
кадров в коллективе 
1,29 
1,12 1,00 0,90 0,81 
1,59 
Проект 
TOOL – 
Использование 
программных 
инструментов
 
Учитывает 
уровень 
использования 
инструментов 
разработки 
 
1,17
 
1,09
 
1,00
 
0,90
 
0,78
 
 
1,50
 

159 
Продолжение таблицы 6.14 
SITE – 
Распределенная 
разработка 
Учитывает 
территориальную 
удаленность (от офиса 
до международных 
офисов) членов 
команды разработчиков 
и используемые ими 
средства коммуникации 
(от телефона до видео 
конференц-связи) 
1,22 
1,09 1,00 0,93 0,86 0,78 1,56 
SCED – Сжатие 
графика 
проекта 
Учитывает влияние 
временных 
ограничений, 
накладываемых на 
проект и на значение 
трудозатрат
1,43 
1,14 1,00 1,00 1,00 
1,43 
6.8
Модель Путнэма (SLIM) 
Вернемся к линейной формуле определения трудозатрат – как 
уже говорилось, она была признана несостоятельной, но если ранее 
сомнению подвергался только способ исчисления размера ПО, то 
теперь стоит задуматься о ее линейном характере. 
О том, что трудоемкость и, соответственно, стоимость 
программного проекта нелинейно зависит от объема работ, было 
известно еще в 1970-х годах, когда появились первые научные 
публикации, подкрепленные результатами серьезных исследований. 
Вероятно, первой нелинейной моделью, использующей 
эмпирические данные и нашедшей практическое применение при 
оценке стоимости ПО, стала SLIM (Software Life-cycle Model), 
предложенная в 1978 г. Лоуренсом Путнэмом.
SLIM была создана на базе реальных данных, собранных в 
Министерстве обороны США, и ориентирована в первую очередь на 
крупные проекты. Несмотря на возможность калибровки модели на 

160 
основе хронологической информации, что несколько повышает 
качество результатов, она не приобрела широкой популярности, хотя 
существуют организации, успешно использующие ее в проектном 
менеджменте и сегодня. 
Созданная для проектов, объемом больше 70 000 строк кода, 
модель основывается на утверждении, что затраты на разработку ПО 
распределяются согласно кривым Нордена-Рэйли, которые являются 
графиками функции, представляющей распределение рабочей силы 
по времени. Общий вид подобной функции: 


2
2
2
0
1
p
t
t
e
v
v




,
(28) 
где 
v
– полученное значение; 
t
– время; 
0
v
и 
p
t
– параметры, 
определяющие функцию. Для большого значения 
t
, кривая стремится 
к параметру 
0
v
, который называется cost scale factor parameter. 
Функция возрастает наиболее быстро при 
p
t
t

. Основной причиной 
такого поведения модели являлось то, что изначально исследования 
Нордена базировались не на теоретической основе, а на наблюдениях 
за проектами, причем, в основном за проектами не связанными с ПО 
(машиностроение, 
строительство). 
Поэтому 
нет 
научного 
подтверждения тому, что программные проекты требуют такого же 
распределения рабочей силы, наоборот, зачастую количество 
человеко-часов, требуемых проектом, может резко измениться, сделав 
оценку непригодной к использованию. После ряда эмпирических 
наблюдений, Путнэм выразил рабочее уравнение модели в форме:
3
4
3
1
t
E
C
Size



, 
(29) 
где Size – размер кода в LOC, С – технологический фактор; E – общая 
стоимость проекта в человеко-годах; t – ожидаемое время реализации 

161 
проекта. Технологический фактор включает в себя характеристику 
проекта в следующих аспектах: методы управления и понимание 
процесса, качество используемых методов инженерии ПО, уровень 
используемых языков программирования, уровень развития среды, 
навыки и опыт команды разработчиков, сложность приложения. 
Уравнение для E, выглядит как: 
3
0
d
t
D
E


,
(30) 
где 
0
D
– коэффициент, выражающий количество необходимой работы 
(значения от 8 до 12, означает ПО полностью новое, с большим 
количеством связей; значения до 27 – требуется переработка 
существующего кода). Связывая два уравнения, получаем: 
7
9
7
9
7
4
0
S
C
D
E







и 
7
3
7
3
7
1
0












S
E
D
t
d
. 
(31) 
В 1991 году Путнэмом была представлена альтернативная 
реализация модели, выполненная по заказу Quantitative Software 
Management (QSM) Inc. и примененная в комплексе SLIM Estimate 
для оценки стоимости ПО. Полное уравнение в этой реализации 
выглядит как:
(
) (
)
4
1
3
5
12
Schedule
P
SLOC
B
E
=
. 
(32) 
Если на общее время реализации проекта ограничения не 
накладываются, то возможно использование упрощенного уравнения: 
(
)
7
9
4
56
P
SLOC
B
.
E
=
.
(33) 

162 
Здесь 
B
– фактор специальных навыков; 
P – 
табличный фактор 
продуктивности, зависящий от среды применения разрабатываемого 
приложения;
 
Schedule – время разработки по графику (в месяцах). 
Уравнение может быть использовано, если предполагаемые затраты 
больше 20 человеко-месяцев.
6.9
Программные средства для оценки стоимости ПО 
Оценка трудозатрат и стоимости по описанным выше моделям 
является достаточно сложной для ручного подсчета. Для 
автоматизации процесса оценки различными компаниями разработан 
широкий спектр оценочных программ, разброс цен на которые 
колеблется от бесплатного распространения до $20000 за готовую 
лицензию на одно рабочее место. Наиболее популярными 
программами являются: 
- 
Angel (Analogy Software Tool) – программа с возможностью 
оценки будущих проектов по аналогии с прошлыми проектами; 
- 
Construx Estimate – бесплатная программа, основанная на 
моделях Путнэма и COCOMO II, разработанная компанией Construx 
Software Builders (рис. 6.3); 
Рис. 6.3 - Окно Construx Estimate 

163 
- 
COCOMO II – программные реализации модели COCOMO II, 
официальные версии находятся на сайте Южнокалифорнийского 
университета (Http://sunset.usc.edu) и распространяются бесплатно 
(рис. 6.4); 
Рис. 6.4 - Программная реализация модели COCOMO II 

164 
- 
Costar – недорогая полноценная реализация COCOMO II, 
предлагаемая компанией Softstar Systems (рис. 6.5); 
Рис. 6.5 - Программная реализация модели COCOMO II 
 
- 
KnowledgePLAN – программа, разработанная компанией 
Software Productivity Research и отличающаяся высокой интеграцией с 
Microsoft Project; 
- 
Price-S – программа представляет собой пакет программных 
продуктов, предназначенных для оценки проектов; 
- 
SEER – как и Price-S состоит из нескольких взаимосвязанных 
продуктов: SEER-SEM – оценка, планирование и управление, SEER-
SSM – углубленная оценка размеров программных проектов, SEER-
AccuScope – простая оценка размеров; 
- 
SLIM-Estimate и Estimate Express – семейство программных 
продуктов от Quantative Software Management, являющихся мощными 
и полнофункциональными оценочными программами, базирующиеся 
на модели оценки Путнэма. 

165 

жүктеу/скачать 2,75 Mb.

Достарыңызбен бөлісу: