6.3 Основы методики COCOMO II кратко

Привет, Вы узнаете о том , что такое методики cocomo ii, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое методики cocomo ii, cocomo , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

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

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

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

где

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

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

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

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

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

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

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

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

Таблица 14. Об этом говорит сайт https://intellect.icu . Значение фактора масштаба, в зависимости от оценки его уровня

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

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

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

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

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

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

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

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

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

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

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

1. Суммарный размер продукта рассчитывается, как сумма размеров его компонентов:

   

2. Базовая трудоемкость проекта рассчитывается по формуле:

   

3. Затем рассчитывается базовая трудоемкость каждого компонента:

   

4. На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED.

   

5. И, наконец, итоговая трудоемкость проекта определятся по формуле:

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

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

где

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

Выводы

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

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

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

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

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

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