Материал: Инфрам

328 модель этапа пост-архитектуры.
Для описания моделей СОСОМО II требуется информация о размере программного продукта. Возможно использование LOC-оценок, объ- ектных указателей, функциональных указателей.
7.4.3. Модель композиции приложения
Модель композиции используется на ранней стадии конструирова- ния ПО, когда: рассматривается макетирование пользовательских интерфейсов; обсуждается взаимодействие ПО и компьютерной системы; оценивается производительность; определяется степень зрелости технологии.
Модель композиции приложения ориентирована на применение объ- ектных указателей. Объектный указатель – средство косвенного изме- рения ПО, для его расчета определяется количество экранов (как эле- ментов пользовательского интерфейса), отчетов и компонентов, требуе- мых для построения приложения. Как показано в табл. 7.14, каждый объектный экземпляр (экран, отчет) относят к одному из трех уровней сложности. Здесь места подстановки измеренных и вычисленных значе- ний отмечены прямоугольниками (прямоугольник играет роль метки- заполнителя). В свою очередь, сложность является функцией от пара- метров клиентских и серверных таблиц данных (см. табл. 7.15 и 7.16), которые требуются для генерации экрана и отчета, а также от количест- ва представлений и секций, входящих в экран или отчет.
Таблица 7.14
Типы объектных экземпляров
Тип объекта
Количество Вес
Итого
Простой Средний
Сложный
Экран
0 х1 х2 х3
= 0
Отчет
0 х2 х5 х8
= 0 3GL компонент
0 х10
= 0
Объектные указа- тели
= 0
Таблица 7.15
Параметры уровня сложности для объектного экземпляра экран
Экраны
Количество серверных (срв) и клиентских (клт) таблиц данных
Количество представлений
Всего < 4
(< 2 срв, <3клт)
Всего < 8
(2-3 срв, 3-5 клт)
Всего > 8
(>3срв, >5клт)
<3
Простой
Простой
Средний

329 3-7
Простой
Средний
Сложный
>8
Средний
Сложный
Сложный
Таблица 7.16
Параметры уровня сложности для объектного экземпляра отчет
Отчеты
Количество серверных (срв) и клиентских (клт) таблиц
данных
Количество представлений
Всего < 4
(< 2 срв, < 3 клт)
Всего < 8
(2-3 срв, 3-5 клт)
Всего > 8
(>3срв, > 5 клт)
0 или 1
Простой
Простой
Средний
2 или 3
Простой
Средний
Сложный
>4
Средний
Сложный
Сложный
После определения сложности количество экранов, отчетов и ком- понентов взвешивается в соответствии с табл. 7.14. Количество объект- ных указателей определяется перемножением исходного числа объект- ных экземпляров на весовые коэффициенты и последующим суммиро- ванием промежуточных результатов.
Для учета реальных условий разработки вычисляется процент по- вторного использования программных компонентов %REUSE и опреде- ляется количество новых объектных указателей NOP:
NOP = (Объектные указатели) х [(100 - %REUSE) /100].
Для оценки затрат, основанной на величине NOP, надо знать ско- рость разработки продукта PROD. Эту скорость определяют по табл.
7.17, учитывающей уровень опытности разработчиков и зрелость среды разработки.
Проектные затраты оцениваются по формуле
ЗАТРАТЫ = NOP /PROD [чел.-мес], где PROD — производительность разработки, выраженная в терми- нах объектных указателей.
Таблица 7.17
Зависимость скорости разработки от возможностей разработчика
и среды разработки
Опытность / возможности
разработчика
Зрелость / возможности
среды разработки
PROD
Очень низкая
Очень низкая
4
Низкая
Низкая
7
Номинальная
Номинальная
13
Высокая
Высокая
25
Очень высокая
Очень высокая
50

330
В более развитых моделях дополнительно учитывается множество масштабных факторов, формирователей затрат, процедур поправок.
7.4.4. Модель раннего этапа проектирования
Модель раннего этапа проектирования используется в период, когда стабилизируются требования и определяется базисная программная ар- хитектура.
Основное уравнение этой модели имеет следующий вид [19]:
ЗАТРАТЫ = А х РАЗМЕР
в х М
е
+ ЗАТРАТЫ
аuto
[чел.-мес], где масштабный коэффициент А = 2,5; показатель В отражает нелинейную зависимость затрат от размера проекта (размер системы РАЗМЕР выражается в тысячах LOC); множитель поправки М
e зависит от 7 формирователей затрат, харак- теризующих продукт, процесс и персонал; слагаемое 3ATPATЫ
auto отражает затраты на автоматически генери- руемый программный код.
Значение показателя степени В изменяется в диапазоне 1,01... 1,26, зависит от пяти масштабных факторов W
i
и вычисляется по формуле
5 1
01
,
0 01
,
1
i
i
W
B
.
Общая характеристика масштабных факторов приведена в табл. 7.18, а табл. 7.19 позволяет определить оценки этих факторов. Оценки при- нимают 6 значений: от очень низкой (5) до сверхвысокой (0).
Таблица 7.18
Характеристика масштабных факторов
Масштабный фактор (Wi)
Пояснение
Предсказуемость PREC
Отражает предыдущий опыт организации в реализации проектов этого типа. Очень низкий означает отсутствие опыта. Сверхвысокий озна- чает, что организация полностью знакома с этой прикладной областью
Гибкость разработки FLEX
Разрешение архитектуры
/риска RESL
Связность группы TEAM
Отражает степень гибкости процесса разработ- ки. Очень низкий означает, что используется заданный процесс. Сверхвысокий означает, что клиент установил только общие цели
Отражает степень выполняемого анализа риска.
Очень низкий означает малый анализ. Сверхвы- сокий означает полный и сквозной анализ риска
Отражает, насколько хорошо разработчики группы знают друг друга и насколько удачно они совместно работают. Очень низкий означа- ет очень трудные взаимодействия. Сверхвысо- кий, означает интегрированную группу, без проблем взаимодействия

331
Зрелость процесса РМАТ
Означает зрелость процесса в организации. Вы- числение этого фактора может выполняться по вопроснику СММ
В качестве иллюстрации рассмотрим компанию, которая берет про- ект в малознакомой проблемной области. Положим, что заказчик не определил используемый процесс разработки и не допускает выделения времени на всесторонний анализ риска. Для реализации этой программ- ной системы нужно создать новую группу разработчиков. Компания имеет возможности, соответствующие 2-му уровню зрелости согласно модели СММ. Возможны следующие значения масштабных факторов: предсказуемость. Это новый проект для компании – значение Низ- кий (4); гибкость разработки. Заказчик требует некоторого согласования – значение Очень высокий (1); разрешение архитектуры/риска. Не выполняется анализ риска, как следствие, малое разрешение риска – значение Очень низкий (5); связность группы. Новая группа, нет информации – значение Номи- нальный (3); зрелость процесса. Имеет место некоторое управление процессом – значение Номинальный (3).
Сумма этих значений равна 16, поэтому конечное значение степени
В = 1,17. Вернемся к обсуждению основного уравнения модели раннего этапа проектирования. Множитель поправки М
e зависит от набора фор- мирователей затрат, перечисленных в табл. 7.20. Для каждого формиро- вателя затрат определяется оценка (по 6-балльной шкале), где 1 соот- ветствует очень низкому значению, а 6 – сверхвысокому значению. На основе оценки для каждого формирователя по таблице Боэма определя- ется множитель затрат EM
i.
.Перемножение всех множителей затрат формирует множитель поправки:
7 1
i
i
e
EM
М
Слагаемое 3ATPATЫ
auto используется, если некоторый процент про- граммного кода генерируется автоматически. Поскольку производи- тельность такой работы значительно выше, чем при ручной разработке кода, требуемые затраты вычисляются отдельно, по следующей форму- ле:
ЗАТРАТЫ
аuto
= (КALOC x (AT /100)) / ATPROD, где KALOC – количество строк автоматически генерируемого кода
(в тысячах строк);
AT – процент автоматически генерируемого кода (от всего кода сис- темы);
ATPROD – производительность автоматической генерации кода.
Сомножитель AT в этой формуле позволяет учесть затраты на орга- низацию взаимодействия автоматически генерируемого кода с остав-

332 шейся частью системы. Далее затраты на автоматическую генерацию добавляются к затратам, вычисленным для кода, разработанного вруч- ную.
Таблица 7.19
Оценки масштабных факторов
Масштабный
фактор (Wi)
Очень низкий 5 Низкий 4
Номинальный 3
PRЕС
Полностью не- предсказуемый проект
Главным образом, в значительной степени непред- сказуемый
Отчасти непредсказуемый
FLEX
Точный, строгий процесс разработ- ки
Редкое расслабле- ние в работе
Некоторое расслаб- ление в работе
RESL
Малое разрешение риска (20%)
Некоторое (40%) Частое (60%)
TEAM
Очень трудное взаимодействие
Достаточно труд- ное взаимодейст- вие
Среднее взаимодействие
PREC
Полностью не- предсказуемый проект
В значительной степени непред- сказуемый
Отчасти непредска- зуемый
РМАТ
Взвешенное среднее значение от количества ответов «Yes» на вопросник СММ Maturity
Продолжение таблицы 19
Масштабный
фактор (Wi)
Высокий 2
Очень высокий 1 Сверхвысокий 0
PRЕС
Большей частью знакомый
В значительной степени знакомый
Полностью знако- мый
FLEX
Большей частью согласованный процесс
Некоторое согласование процесса
Заказчик определил только общие цели
RESL
Большей частью
(75%)
Почти всегда
(90%)
Полное (100%)
TEAM
Главным обра- зом кооператив- ность
Высокая коопера- тивность
Безукоризненное взаимодействие
PREC
Большей частью знакомый
В значительной степени знакомый
Полностью знако- мый
РМАТ
Взвешенное среднее значение от количества ответов
«Yes» на вопросник СММ Maturity

333
Таблица 7.20
Набор формирователя затрат, определяющих значение
М
3>

334
DM – процент модифицируемых проектных моделей;
CM – процент модифицируемого программного кода;
IM – процент затрат на интеграцию, требуемых для подключения повторно используемого ПО;
SU – фактор, основанный на стоимости понимания добавляемого
ПО; изменяется от 50 (для сложного неструктурированного кода) до 10
(для хорошо написанного объектно-ориентированного кода);
АА – фактор, который отражает стоимость решения о том, может ли
ПО быть повторно используемым; зависит от размера требуемого тес- тирования и оценивания (величина изменяется от 0 до 8).
Правила выбора этих параметров приведены в руководстве по СО-
СОМО II.
Для определения множителя поправки М
р
основного уравнения ис- пользуют 17 факторов затрат, которые могут быть разбиты на 4 катего- рии. Перечислим факторы затрат, сгруппировав их по категориям.
Факторы продукта:
1) требуемая надежность ПО – RELY;
2) размер базы данных – DATA;
3) сложность продукта – CPLX;
4) требуемая повторная используемость – RUSE;
5) документирование требований жизненного цикла – DOCU.
Факторы платформы (виртуальной машины):
6) ограничения времени выполнения – TIME;
7) ограничения оперативной памяти – STOR;
8) изменчивость платформы – PVOL.
Факторы персонала:
9) возможности аналитика – АСАР;
10) возможности программиста – РСАР;
11) опыт работы с приложением – АЕХР;
12) опыт работы с платформой – РЕХР;
13) опыт работы с языком и утилитами – LTEX;
14) непрерывность персонала – PCON.
Факторы проекта:
15) использование программных утилит – TOOL;
16) мультисетевая разработка – SITE;
17) требуемый график разработки – SCED.
Для каждого фактора определяется оценка (по 6-балльной шкале).
На основе оценки для каждого фактора по таблице Боэма определяется множитель затрат ЕМ
i
. Перемножение всех множителей затрат дает множитель поправки пост-архитектурной модели:
17 1
i
i
p
EM
M
Значение М
р
отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат.

335
От оценки затрат легко перейти к стоимости проекта. Переход вы- полняют по формуле:
СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ, где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц.
После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки ка- лендарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо:
Длительность выполнения проекта
(TDEV) = [3,0 х (ЗАТРАТЫ)
(0,33+0,2(B-1,01))
] х SCEDPercentage/100
[мес], где В – ранее рассчитанный показатель степени;
SCEDPercentage – процент увеличения (уменьшения) номинального графика.
Если нужно определить номинальный график, то принимается
SCEDPercentage = 100 и правый сомножитель в уравнении обращается в единицу. Следует отметить, что СОСОМО II ограничивает диапазон уплотнения/растягивания графика (от 75 до 160%). Причина проста – если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска.
Отметим, что зависимость между затратами и количеством разра- ботчиков носит характер, существенно отличающийся от линейного.
Очень часто увеличение количества разработчиков приводит к возрас- танию затрат. В чем причина? Ответ прост: увеличивается время на взаимодействие и обучение сотрудников, согласование совместных решений; возрастает время на определение интерфейсов между частями про- граммной системы.
Удвоение разработчиков не приводит к двукратному сокращению длительности проекта. Модель СОСОМО II явно утверждает, что дли- тельность проекта является функцией требуемых затрат, прямой зави- симости от количества сотрудников нет. Другими словами, она устраня- ет миф нерадивых менеджеров в том, что добавление людей поможет ликвидировать отставание в проекте.
СОСОМО II предостерегает от определения потребного количества сотрудников путем деления затрат на длительность проекта. Такой уп- рощенный подход часто приводит к срыву работ. Реальная картина име- ет другой характер. Количество людей, требуемых на этапе планирова- ния и формирования требований, достаточно мало. На этапах проекти- рования и кодирования потребность в увеличении команды возрастает, после окончания кодирования и тестирования численность необходи- мых сотрудников достигает минимума.

336
7.5. Оценка компромиссной стоимости программной системы
7.5.1. Принципы определения стоимости заказчиком
Как правило, заказчик и исполнитель проекта имеют различное мне- ние о принципах определения стоимости заказанного программного продукта, что вполне объяснимо. В статье [6] дается интересный подход к оценке стоимости сложной информационно-технической системы, который можно использовать для определения компромиссной стоимо- сти ПС.
Стоимость программного продукта, с точки зрения заказчика зави- сит от выгод приобретения ПО, оцениваемых с помощью таких понятий как: полнота функционального наполнения программной системы; уровень отражения специфики работы пользователя; степень настраиваемости ПС в ходе эксплуатации; гарантированный объем предоставляемых услуг, связанных с вне- дрением и эксплуатацией, в том числе услуг по пуске-наладке, обу- чению, сопровождению, настройке на особенности конкретного пользователя; наличие качественной пользовательской документации; удобство пользовательского интерфейса.
Стоимость программного продукта, с точки зрения Исполнителя оп- ределяется иными составляющими, основная часть которых перечисле- на ниже: суммарные затраты разработчиков на изготовление и тестирова- ние опытного образца; финансовая политика разработчика (накладные расходы, прием- лемая норма прибыли и т. д.); маркетинговая политика (широкий сбыт, занятие ниши на рынке, сохранение имиджа фирмы); уникальность ПС, определяющая уникальные характеристики, в том числе стоимость, причем эти специфические характеристики учиты- ваются как заказчиками, так и исполнителями ПС; долгосрочность взаимодействия исполнителя с заказчиком при со- провождении ПС; уникальность разработки каждой ПС; сложность прогностического определения стоимости разработок, поскольку методики определения затрат на разработку крупных про- граммно-технических решений используют большое число факто- ров, определяемых после того, как более 80% проектирования (20–
25% объема всех работ выполнено [18]).
Если ПС – уникальный, создаваемый под заказ продукт, то отсутст- вие аналогов затрудняет определение цены, как методом аналогии, так и методом экспертных оценок. Ценой ПС является компромисс между стоимостью заказчика – ценой, которую готов платить заказчик за обла- дание ПС и стоимостью исполнителя – ценой, за которую исполнитель