Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

.pdf
Скачиваний:
115
Добавлен:
14.05.2016
Размер:
14.05 Mб
Скачать

Оценка трудоемкости создания программного обеспечения 451

где X/ - факторы, влияющие на трудоемкость, Ь^ — коэффициен­ ты модели. Линейные модели работают не слишком хорошо, поскольку практика показывает, что соотношения между трудо­ емкостью и размером ПО нелинейны. По мере роста размера ПО возникает экспоненциальный отрицательный эффект масштаба. Нелинейные статистические модели имеют следующий вид:

Трудоемкость = у4*(Размер ПО)^.

где А — комбинация факторов, влияющих на трудоемкость; b — экспоненциальный коэффициент масштаба.

Статистические модели просты для понимания, но имеют следующий недостаток: результаты справедливы в основном только для конкретной ситуации. Другой недостаток — при уве­ личении количества входных параметров количество данных, не­ обходимых для калибровки модели, также возрастает.

Статистическая модель СОСОМОII

Модель СОСОМО^ (Constructive COst Model — конструктив­ ная модель стоимости), разработанная Барри Боэмом, является одной из самых известных и хорошо документированных моде­ лей оценки трудоемкости разработки ПО. Исходная модель СОСОМО основывалась на базе данных по 56 выполненным проектам, а ее различные варианты отражали различия между процессами в различных областях ПО.

Вмодели СОСОМО используется ряд допущений.

Исходный код конечного продукта включает в себя все (кроме комментариев) строки кода.

Начало цикла разработки совпадает с началом разработки продукта, окончание совпадает с окончанием приемочного тестирования, завершающим стадию интеграции и тестиро­ вания (работа и время, затрачиваемые на анализ требова­ ний, оцениваются отдельно как дополнительный процент от оценки разработки в целом).

Виды деятельности включают в себя только непосредствен­ но направленные на выполнение проекта работы, в них не входят обычные вспомогательные виды деятельности, та-

^ Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. — М.: Радио и связь, 1985.

452

Глава 6

кие, как административная поддержка, техническое обеспе­ чение и капитальное оборудование.

Человеко-месяц состоит из 152 ч.

Проект управляется надлежащим образом, в нем использу­ ются стабильные требования.

Проект СОСОМО П (современный вариант модели СОСОМО) был выполнен в Центре по разработке ПО Южно-Калифор­ нийского университета (USC Centre for Software Engineering). Этот проект преследовал следующие цели.

Разработать модель для оценки трудоемкости и сроков соз­ дания ПО для итерационной модели жизненного цикла ПО, которая будет применяться в 1990-х и 2000-х годах.

Создать базу данных по трудоемкости ПО.

Разработать инструментальную поддержку для усовершен­ ствования модели.

Создать количественную аналитическую схему для оценки технологий создания ПО и их экономического эффекта.

Уравнения СОСОМО П для оценки номинальных значений трудоемкости и времени имеют следующий вид.

Трудоемкость (в человеко-месяцах):

/=1

где

E^^B + O.OlxY^SFj.

м

Календарное время:

TDEVNS = С X (PMNS)^

где

F = Z) + 0.2хО.01 X X SFj = D +0.2 х(£ -5);

7=1

EMi — мультипликативные коэффициенты трудоемкости; SFj — экспоненциальные коэффициенты масштаба;

Size — размер ПО, выраженный в тысячах строк исходного кода или количестве функциональных точек без учета поправоч­ ных коэффициентов (UFP), определенном по методике 1FPUG, с последующим преобразованием в количество строк кода.

Оценка трудоемкости создания программного обеспечения 453

Калибровочные переменные А, В, С иВ в модели СОСОМО II версии 2000 г. принимают следующие значения: А = 2.94, В = 0.91, С= 3.67,/) = 0.28.

Коэффициенты ЕМ^ отражают совместное влияние многих параметров. Они позволяют характеризовать и нормировать сре­ ду разработки по параметрам, содержащимся в базе данных про­ ектов модели СОСОМО II (в настоящее время более 160 проек­ тов). Каждый коэффициент в зависимости от установленного значения (очень низкое, низкое, номинальное, высокое, очень высокое) вносит свой вклад в виде множителя с определенным диапазоном значений. Результат учета этих 17 коэффициентов используется при вычислении в уравнении трудоемкости. Состав коэффициентов приведен в табл. 6.8.

 

 

 

Таблица 6.8

 

Мультипликативные коэффициенты трудоемкости

Идентификатор

Описание коэффициента

Диапазон значений

1

RELY

Требуемая надежность

0.82-L26

 

DATA

Размер базы данных

0.90-L28

 

CPLX

Сложность продукта

0.73-L74

 

RUSE

Требуемый уровень повторного

0.95-L24

 

 

использования

 

 

DOCU

Соответствие документации

0.81-L23

 

 

требованиям ЖЦ

 

 

TIME

Ограничение времени выполнения

L00-1.63

 

STOR

Ограничение по объему основной

L00-L46

 

PVOL

памяти

0.87-L30

 

Изменчивость платформы

 

ACAP

Способности аналитика

1.42-0.71

 

PCAP

Способности профаммиста

1.34-0.76

 

APEX

Знание приложений

1.22-0.81

 

PLEX

Знание платформы

1.19-0.85

 

PCON

Преемственность персонала

1.29-0.81

 

LTEX

Знание языка/инструментальных

1.20-0.84

 

 

средств

1.17-0.78

 

TOOL

Использование инструментальных

 

SCED

средств

1.43-1.00 1

 

Требуемые сроки разработки

 

SITE

Рассредоточенность команды

1.22-0.80

 

 

разработчиков

 

454

Глава 6

Показатель экспоненты процесса Е может изменяться в диа­ пазоне от 0.91 до 1.23 и определяется как сочетание следующих параметров.

1. Наличие прецедентов у приложения: степень опытности организации-разработчика в данной области.

2.Гибкость процесса: степень строгости контракта, порядок его выполнения, присущая контракту свобода внесения измене­ ний, виды деятельности в течение всего жизненного цикла и вза­ имодействие между заинтересованными сторонами.

3.Разрешение рисков, присущих архитектуре: степень техни­ ческой осуществимости, продемонстрированной до перехода к полномасштабному внедрению.

4.Сплоченность команды: степень сотрудничества и того, насколько все заинтересованные стороны (заказчики, разработ­ чики, пользователи, ответственные за сопровождение и другие) разделяют общую концепцию.

5.Зрелость процесса: уровень зрелости организации-разра­ ботчика, определяемый в соответствии с моделью СММ.

В табл. 6.9 приведены возможные значения экспоненциаль­ ных коэффициентов масштаба, составляющих в сумме показа­ тель Е. Суммарное влияние этих коэффициентов может оказать­ ся весьма существенным.

Таблица 6.9

Экспоненциальные коэффициенты масштаба модели СОСОМО II

Параметр

Характеристика

Значение

PREC - нали­

Полное отсутствие прецедентов, полностью

6.20

чие прецеден­

непредсказуемый проект

 

тов

Почти полное отсутствие прецедентов, в

4.96

 

значительной степени непредсказуемый

 

 

проект

 

 

Наличие некоторого количества прецеден­

3.72

 

тов

 

 

Общее знакомство с проектом

• 2.48

 

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

1.24

 

Полное знакомство с проектом

0.00

FLEX-гиб-

Точный, строгий процесс разработки

5.07

' кость процесса

Случайные послабления в процессе

4.05

разработки

Некоторые послабления в процессе

3.04

Оценка трудоемкости создания программного обеспечения 455

 

 

Продолжение

Параметр

Характеристика

Значение

 

Большей частью согласованный процесс

2.03

 

Некоторое согласование процесса

1.01

1 RESL - разре­

Заказчик определил только общие цели

0.00

Малое (20%)

7.07

шение рисков

Некоторое (40%)

5.65

в архитектуре

Частое (60%)

4.24

 

В целом (75%)

2.83

 

Почти полное (90%)

1.41

TEAM — спло­

Полное (100%)

0.00

Сильно затрудненное взаимодействие

5.48

ченность ко­

Несколько затрудненное взаимодействие

4.38

манды

Некоторая согласованность

3.29

 

Повышенная согласованность

2.19

 

Высокая согласованность

1.10

 

Взаимодействия как в едином целом

0.00

РМАТ - зре­

Уровень 1 СММ

7.80

лость процес­

Уровень 1+ СММ

6.24

сов

Уровень 2 СММ

4.68

 

Уровень 3 СММ

3.12

 

Уровень 4 СММ

1.56

 

Уровень 5 СММ

0.00

Пример экспоненциального коэффициента масштаба к фициент зрелости процессов (РМАТ— Process Maturity).

Значение коэффициента РМАТ зависит в основном от уровня зрелости процессов в соответствии с моделью СММ. Процедура определения значения РМАТ основана на определении процента соответствия для каждой из 18 основных групп процессов (key process areas — КРА), определенных в СММ. Процент соответ­ ствия вычисляется на основе групп процессов (подробно описа­ но 8 групп из 18).

1])уппа процессов

КРА 1 — Управление требованиями

Требования к системе контролируются и служат основой для разработ­ ки ПО и управления проектом

Планы создания ПО, продукты и виды деятельности согласованы с требованиями к ПО

456

Глава 6

КРА 2 — Планирование проекта

Оценки ПО документируются и используются для планирования и отслеживания проекта

Проектные виды деятельности и обязанности планируются и доку­ ментируются

Участники проекта (группы и индивидуумы) придерживаются своих обязанностей по отношению к проекту

КРА 3 Отслеживание и контроль проекта

Текущие результаты и продуктивность отслеживаются на предмет со­ ответствия планам

В случае существенного отклонения от планов предпринимаются кор­ ректирующие действия

Изменения в обязанностях согласовываются с соответствующими группами и индивидуумами

КРА 4 Управление контрактами

КРА 5 — Обеспечение качества продукта КРА 6 — Управление конфигурацией ПО

Управление конфигурацией планируется

Обеспечивается идентификация, контроль и доступ к выбранным ра­ бочим продуктам

Изменения, вносимые в конкретные рабочие продукты, контролиру­ ются

Участники проекта информируются о состоянии содержания базовых версий ПО

КРА 7 Координация процессов организации

КРА 8 — Стандартизация процессов организации КРА 9 - Обучение КРА 10 — Интегрированное управление созданием ПО

Процессы создания ПО в рамках конкретного проекта являются адап­ тированной версией стандартных процессов, принятых в организации

Проект планируется и управляется в соответствии с установленным в проекте процессом создания ПО

КРА 11 Разработка программного продукта

Задачи разработки продукта четко определены, интегрированы и пос­ ледовательно реализуются

Рабочие продукты согласованы друг с другом

КРА 12 Межгрупповая координация

КРА 13 — Экспертные оценки

Оценка трудоемкости создания программного обеспечения 457

КРА 14 Количественное управление проектом

КРА 15 — Управление качеством продукта КРА 16 — Предотвращение дефектов

КРА 17 — Управление изменениями в технологии

Изменения в технологии планируются

Новые технологии оцениваются на предмет их воздействия на качест­ во и продуктивность

Подходящие новые технологии внедряются в обычную практику орга­ низации

КРА 18 Управление изменениями в процессах

Планируется постоянное совершенствование процессов

В совершенствовании процессов участвует вся организация

Стандартные процессы организации и процессы конкретных проектов постоянно совершенствуются

Значение рейтинга по каждой КРА определяется в соответ­ ствии с табл. 6.10.

 

 

 

Таблица 6.10

 

 

Значения рейтинга КРА

 

1 Характеристика состояния КРА

Вариант ответа

Значения

1

в организации

в таблице рейтингов

КРА, %

Задачи хорошо определены в станда­

Почти всегда

100

ртных процедурах и последовательно

 

 

реализуются (более 90% времени)

 

 

Задачи

реализуются

относительно

Часто

75

часто, однако при определенных зат­

 

 

руднениях не выполняются (от 60 до

 

 

90% времени)

 

Наполовину

 

1 Задачи реализуются от 40 до 60% вре­

50

мени

 

 

 

 

Задачи реализуются не слишком час­

Случайно

25

то (от 10 до 40% времени)

 

 

Задачи

реализуются

редко (менее

Очень редко

1

10% времени)

 

 

 

! Данные процессы вообще не реали­

Не применяется

0

зуются

 

 

 

 

Невозможно сказать ничего опреде­

Неизвестно

0

ленного

относительно данных про­

 

 

цессов

 

 

 

 

458

Глава 6

Оценочный уровень зрелости процессов (EPML) вычисляет­ ся следующим образом:

EPML^Sx(пкрл%А\

1м 100 ) п где значение КРА% определяется по табл. 6.10.

Значения коэффициента РМАТ определяются в соответствии с табл. 6.11.

 

Таблица 6.11

Значения коэффициента РМАТ

 

Оценочный уровень зрелости процессов

Уровень зрелости

Значение

(EPML)

процессов

РМАТ

0'

Уровень 1 СММ

7.8

1

Уровень 1+СММ

6.24

2

Уровень 2 СММ

4.68

3

Уровень 3 СММ

3.12

4

Уровень 4 СММ

1.56

5

Уровень 5 СММ

0

Пример мультипликативного коэффициента трудоемкос коэффициент использования инструментальных средств (TO

Значения коэффициента TOOL вычисляются в соответствии

стабл. 6.12.

Вцелом модель СОСОМО II является хорошим усовершен­ ствованием традиционных и устаревших моделей трудоемкости. Она вполне соответствует принципам итерационной разработки и современным технологиям создания ПО. В частности, СОСОМО II активно используется в технологии Rational Unified Process. Вместе с тем она постоянно развивается, поскольку ее база дан­ ных пополняется сведениями о разнообразных проектах^

^Более подробное описание модели СОСОМО II (на русском языке) приведено в книгах: Орлов С.А. Технологии разработки профаммного обес­ печения. — СПб.: Питер, 2002; Фатрелл Р., Шафер Д,, Шафер Л. Управление программными проектами: достижение оптимального качества при мини­ муме затрат: Пер. с англ. - М.: Вильяме, 2003.

Оценка трудоемкости создания программного обеспечения 459

Таблица 6.12

Значения коэффициента TOOL

Дескрипторы TOOL

Уровни

рейтинга

 

Редакторы кода, отладчики

Очень низкий

Простые CASE-средства с минимальной ин­

Низкий

теграцией

 

1 Средства поддержки основных процессов Номинальный

ЖЦ, средняя степень интеграции

 

Мощные, развитые средства поддержки

Высокий

ЖЦ, средняя степень интеграции

 

Мощные, развитые средства поддержки

Очень высокий

ЖЦ, хорошо интефированные с процессами

 

и методами, повторное использование

 

Значение TOOL

L17

L09

1.00

0.90

0.78

6.4. МЕТОДИКА ОЦЕНКИ ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО НА ОСНОВЕ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (ПО МАТЕРИАЛАМ КОМПАНИИ RATIONAL SOFTWARE)

6 . 4 . 1 - ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ДЕЙСТВУЮЩИХ Л И Ц

Все действующие лица системы делятся на три типа: простые, средние и сложные.

Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API).

Среднее действующее лицо представляет либо внешнюю сис­ тему, взаимодействующую с данной системой посредством про­ токола наподобие TCP/IP, либо личность, пользующуюся тексто­ вым интерфейсом (например, ASCII-терминалом).

Сложное действующее лицо представляет личность, пользую­ щуюся графическим интерфейсом (GUI).

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

460

Глава 6

Весовые коэффициенты действующих лиц

Тип действующего лица

Весовой коэффициент

простое

1

среднее

2

сложное

3

В качестве примера рассмотрим систему регистрации для учебного заведения, описанную в главе 3:

Ъ|пы действующих лиц

 

Действующее лицо

Тип

Студент

Сложное

Профессор

Сложное

Регистратор

Сложное

Расчетная система

Простое

Каталог курсов

Простое

Таким образом, общий весовой показатель равен: ^ = 2*1 + 3*3 = 11.

6.4.2. ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Все варианты использования делятся на три типа: простые, средние и сложные, в зависимости от количества транзакций в потоках событий (основных и альтернативных). В данном случае под транзакцией понимается атомарная последовательность действий, которая выполняется полностью или отменяется.

Подсчитанное количество вариантов использования каждого типа умножается на соответствующий весовой коэффициент, за­ тем вычисляется общий весовой показатель UCP (табл. 6.13).

Другой способ определения сложности вариантов использо­ вания заключается в подсчете количества классов анализа, участ­ вующих в их реализации (табл. 6.14).