Лекции по управлению программными проектами

2009 г.

Лекции по управлению программными проектами

Основы метопики COCOMO II

Методика COCOMO позволяет оценить трудоемкость и время разработки программного продукта. Впервые была опубликована Бари Боэмом [3] в 1981 году в виде результат анализа 63 проектов компании «TRW Aerospace». В 1997 методика была усовершенствована и получила название COCOMO II. Калибровка параметров производилась по 161 проекту разработки. В модели используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.

Различаются две стадии оценки проекта: предварительная оценка на начальной фазе и детальная оценка после проработки архитектуры.

Формула оценки трудоемкости проекта в чел.*мес. имеет вид:

где

SIZE — размер продукта в KSLOC
EM_i — множители трудоемкости
SF_j — факторы масштаба
n=7 — для предварительной оценки
n=17 — для детальной оценки

Главной особенностью методики является то, что для того, чтобы оценить трудоемкость, необходимо знать размер программного продукта в тысячах строках исходного кода (KSLOC, Kilo Source Lines Of Code). Размер программного продукта может быть, например, оценен экспертами с применением метода PERT.

Если мы провели анализ продукта методом функциональных точек, то его размер может быть рассчитан с использованием собственных статистических данных или с использованием статистики по отрасли [5] (Таблица 13).

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

Язык программирования Оценка количества строк

Наиболее вероятная Оптимистичная Пессимистичная

Assembler 172 86 320

C 148 9 704

C++ 60 29 178

C# 59 51 66

J2EE 61 50 100

JavaScript 56 44 65

PL/SQL 46 14 110

Visual Basic 50 14 276

Факторы масштаба

В методике используются пять факторов масштаба SF_;, которые определяются следующими характеристиками проекта:

PREC — прецедентность, наличие опыт аналогичных разработок (Very Low — опыт в продукте и платформе отсутствует; Extra High — продукт и платформа полностью знакомы)
FLEX — гибкость процесса разработки (Very Low — процесс строго детерминирован; Extra High — определены только общие цели).
RESL — архитектура и разрешение рисков (Very Low — риски неизвестны/не проанализированы; Extra High — риски разрешены на 100%)
TEAM — сработанность команды (Very Low — формальные взаимодействия; Extra High — полное доверие, взаимозаменяемость и взаимопомощь).
PMAT — зрелость процессов (Very Low — CMM Level 1; Extra High — CMM Level 5)

Значение фактора масштаб, в зависимости от оценки его уровня, приведены в Таблица 14

Таблица 14. Значение фактора масштаба, в зависимости от оценки его уровня

Фактор масштаба Оценка уровня фактора

Very Low Low Nominal High Very High Extra High

PREC 6.20 4.96 3.72 2.48 1.24 0.00

FLEX 5.07 4.05 3.04 2.03 1.01 0.00

RESL 7.07 5.65 4.24 2.83 1.41 0.00

TEAM 5.48 4.38 3.29 2.19 1.10 0.00

PMAT 7.80 6.24 4.68 3.12 1.56 0.00

Множители трудоемкости

В нашу задачу не входит детальное описание метода COCOMO II, поэтому мы рассмотрим только случай предварительной оценки трудоемкости программного проекта. Для этой оценки необходимо оценить для проекта уровень семи множителей трудоемкости M,-:

PERS — квалификация персонала (Extra Low — аналитики и программисты имеют низшую квалификацию, текучесть больше 45%; Extra High — аналитики и программисты имеют высшую квалификацию, текучесть меньше 4%)
RCPX — сложность и надежность продукта (Extra Low — продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется; Extra High — продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация требуется в полном объеме)
RUSE — разработка для повторного использования (Low — не требуется; Extra High — требуется переиспользование в других продуктах)
PDIF — сложность платформы разработки (Extra Low — специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; Extra High — жесткие ограничения по памяти и быстродействию, платформа нестабильна)
PREX — опыт персонала (Extra Low — новое приложение, инструменты и платформа; Extra High — приложение, инструменты и платформа хорошо известны)
FCIL — оборудование (Extra Low — инструменты простейшие, коммуникации затруднены; Extra High — интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации)
SCED — сжатие расписания (Very Low — 75% от номинальной длительности; Very High — 160% от номинальной длительности)

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

Таблица 15. Значения множителей трудоемкости, в зависимости от оценки их уровня

Оценка уровня множителя трудоемкости

Extra Low Very Low Low Nominal High Very High Extra High

PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.5

RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72

RUSE n/a n/a 0.95 1.00 1.07 1.15 1.24

PDIF n/a n/a 0.87 1.00 1.29 1.81 2.61

PREX 1.59 1.33 1.22 1.00 0.87 0.74 0.62

FCIL 1.43 1.30 1.10 1.0 0.87 0.73 0.62

SCED n/a 1.43 1.14 1.00 1.00 1.00 n/a

Из этой таблицы, в частности, следует, если в нашем проекте низкая квалификация аналитиков, то его трудоемкость возрастет примерно в 4 раза по сравнению с проектом, в котором участвуют аналитики экстра-класса. И это не выдумки теоретиков, а отраслевая статистика!

Оценка многокомпонентного продукта

Как мы отмечали ранее (см. Лекция 4. Планирование проекта), для того чтобы адекватно спланировать проект и оценить его трудоемкость, необходимо выполнить предварительное проектирование программного продукта. В результате декомпозиции мы получаем некоторое количество компонентов (N), которые составляют программный продукт.

Следует понимать, что суммарная трудоемкость проекта не равна простой сумме трудоемкостей разработки каждого из компонентов:

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

Методика COCOMO II определяет следующую последовательность вычисления трудоемкости проекта при многокомпонентной разработке.

Суммарный размер продукта рассчитывается, как сумма размеров его компонентов:
Базовая трудоемкость проекта рассчитывается по формуле:
Затем рассчитывается базовая трудоемкость каждого компонента:
На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED.
И, наконец, итоговая трудоемкость проекта определятся по формуле:

Оценка длительности проекта

Длительность проекта в методике COCOMO II рассчитывается по формуле:

где

С = 3,67; D = 0,28;
PM_NS — трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.

Выводы

Оценка трудоемкости должна быть вероятностным утверждением. Это означает, что для нее существует некоторое распределение вероятности, которое может быть очень широким, если неопределенность высокая, или достаточно узким, если неопределенность низкая.

Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат.

Если собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то необходимо использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:

FPA IFPUG — метод функциональных точек,
метод COCOMO II, Constructive Cost Model.

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

Дополнительная литература и источники

С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.
Function Point Counting Practices Manual, Release 4.2, IFPUG, 2004.
Barry Boehm. «Software engineering economics». Englewood Cliffs, NJ:Prentice-Hall, 1981
Barry Boehm, et al. «Software cost estimation with COCOMO II». Englewood Cliffs, NJ:Prentice-Hall, 2000.
«Function Point Programming Languages Table», Quantitative Software Management, Inc., 2005.

Назад Содержание Вперёд