Модель COCOMO II — прогноз трудоёмкости и стоимости
С чего начать, если вы новичок
COCOMO (COnstructive COst MOdel — «конструктивная модель стоимости») отвечает на вопрос заказчика: сколько труда и времени займёт разработка всего продукта или крупного этапа, до того как у вас есть velocity спринтов.
| Что вы уже знаете | Что добавляет COCOMO |
|---|---|
| Story points, часы в Jira | Оценка всего контракта в человеко-месяцах и календарных месяцах |
| «Нам нужно 5 разработчиков» | Связь размера, рисков среды и срока (рост нелинейный) |
| Экспертное «на глаз» | Список факторов, которые удорожают проект |
Человеко-месяц (person-month, PM) — один специалист работает полный месяц (в модели — абстрактная единица труда). Пять человеко-месяцев — один человек пять месяцев или пять человек один месяц или смесь.
KSLOC — тысячи строк исходного кода. Считают поставляемый код без пустых строк и часто без автогенерации — иначе модель даёт бессмысленный результат.
Да: тендер, госконтракт, крупный этап, change request на модуль, сравнение архитектур по трудоёмкости.
Мало смысла: одна мелкая задача в спринте — там точнее points и часы.
Зачем нужна COCOMO, если есть Planning Poker
На совещании вы слышите: «эта фича — 8 story points». Это работает внутри команды, когда все знают прошлые спринты. Когда заказчик спрашивает «сколько человеко-месяцев и миллионов рублей на весь контракт?», points без истории проекта в деньги плохо переводятся — у нового контракта истории ещё нет.
COCOMO II (Constructive Cost Model, версия II) — параметрическая модель: вы подставляете размер продукта и факторы среды, получаете оценку трудоёмкости (person-months), срока и численности команды. Модель разработана Барри Боумом (Barry Boehm) и уточняется сообществом USC Center for Systems and Software Engineering.
Базовые методы оценки (часы, три точки, Function Points) — в статье Оценка трудозатрат. COCOMO II — углубление для главы 1.6 курса «экономика производства ПО».
COCOMO дополняет экспертную оценку: даёт каркас для совещания — какие факторы удорожают проект и насколько. Итоговую цифру всё равно согласуют люди; модель ловит забытые множители («а мы заложили формальную документацию под ГОСТ?»).
От COCOMO I к COCOMO II
COCOMO I (1981) опиралась на строки кода (KLOC) и три типа проекта:
| Тип | Характер | Пример |
|---|---|---|
| Organic | Небольшая команда, знакомая среда, гибкие требования | Внутренний CRUD |
| Semi-detached | Средняя сложность, смешанный опыт | Корпоративный портал |
| Embedded | Жёсткие ограничения, высокая надёжность | АСУ ТП, бортовое ПО |
COCOMO II (конец 1990-х — 2000-е) учитывает:
- ранние стадии, когда размер ещё неизвестен точно (оценка через Function Points или объектные точки);
- современные процессы (прототипирование, reuse, инструменты);
- более детальные множители (17–22 cost drivers вместо 15).
Три режима COCOMO II
Выбор режима зависит от стадии проекта и точности входных данных:
| Режим | Когда применять | Точность (типично) |
|---|---|---|
| Application Composition | Прототип, RAD, много готовых компонентов | Грубая, ±50% |
| Early Design | Архитектура выбрана, требования уточняются | Средняя |
| Post-Architecture | Детальное проектирование, известен состав модулей | Лучшая из трёх |
На экзамене чаще спрашивают Post-Architecture — там полный набор scale factors и effort multipliers.
Базовая формула Post-Architecture — разбор по шагам
Трудоёмкость PM (person-months):
PM = A × Size^E × ∏(EM_i)
Читайте формулу слева направо как рецепт:
| Шаг | Часть | Смысл для новичка |
|---|---|---|
| 1 | Size | «Насколько большое» изделие (KSLOC или пересчёт из Function Points) |
| 2 | Size^E | Большие проекты растут быстрее, чем линейно, если процесс слабый (E > 1) |
| 3 | A | Константа калибровки модели (≈ 2.94 для Post-Architecture) |
| 4 | ∏(EM_i) | Произведение множителей среды: опыт, надёжность, документация… каждый > 1 удорожает |
Произведение EM — перемножить все выбранные коэффициенты. Пример: RELY=1,1 и PCON=1,15 и DOCU=1,2 → 1,1 × 1,15 × 1,2 ≈ 1,52 (труд +52% к базе).
Где:
- Size — размер в KSLOC или пересчитанный из Function Points;
- A — калибровочная константа (для Post-Architecture обычно 2.94);
- E — экспонента масштаба от Scale Factors (SF);
- EM_i — Effort Multipliers (множители трудоёмкости).
Экспонента масштаба E
E = B + 0.01 × Σ(SF_j)
- B ≈ 0.91 (калибровка модели);
- SF_j — пять масштабных факторов (каждый оценивается по шкале, сумма входит в формулу).
Если сумма SF высокая (сложный, незрелый процесс), E > 1 — рост размера нелинейно увеличивает трудоёмкость. Это математическое выражение «большие проекты сложнее пропорционально».
Пять масштабных факторов (Scale Factors)
| Фактор | Смысл | Низкая оценка (лучше) | Высокая (хуже) |
|---|---|---|---|
| PREC | Прецедентность — был ли похожий продукт | Есть аналоги | Полный новатор |
| FLEX | Гибкость процесса и требований | Жёсткий контракт | Можно менять по ходу |
| RESL | Разрешение архитектуры / рисков на старте | Риски закрыты | «Разберёмся в коде» |
| TEAM | Слаженность команды | Одна команда, знакомы | Разрозненные подрядчики |
| PMAT | Зрелость процессов (близко к CMMI) | Формализованные процессы | Хаос |
:::info Шкала оценок В справочниках COCOMO II для SF и EM используют уровни Very Low … Extra High с числовыми рейтингами. На практике берут таблицы из официального описания модели или инструментов вроде USC COCOMO II.81. :::
Effort Multipliers — что удорожает проект
17 множителей в Post-Architecture. На практике команда заполняет таблицу в калькуляторе USC COCOMO II или Excel; ниже — человеческий смысл.
Продукт и платформа
| Код | Фактор | Пример, когда растёт EM |
|---|---|---|
| RELY | Надёжность | Медицина, АСУ ТП, финансы — сбой недопустим |
| DATA | Сложность БД | Много связей, миграции, распределённые транзакции |
| CPLX | Сложность продукта | Тяжёлая бизнес-логика, много состояний |
| RUSE | Повторное использование | < 1, если реально переиспользуете готовые модули |
| DOCU | Документация | ГОСТ, формальные ПМИ, регулятор |
| SITE | Удалённые площадки | Команда в трёх часовых поясах без overlap |
| TOOL | Инструменты | < 1 при зрелом CI/CD, IDE, статанализе |
Персонал — часто сильнее всего бьёт по сроку
| Код | Кто | Пример |
|---|---|---|
| ACAP | Аналитики | Junior пишут ТЗ, переделки на приёмке |
| PCAP | Программисты | Нет опыта в домене или стеке |
| SCAP | Архитектура | Нет ведущего архитектора на интеграциях |
| APEX | Опыт приложения | Первый раз в этой предметной области |
| PLEX | Опыт платформы | Первый проект на Kubernetes / 1С / embedded |
| LTEX | Язык и инструменты | Команда только переходит на Go/Rust |
Проект
| Код | Фактор | Пример |
|---|---|---|
| PCON | Стабильность требований | Заказчик меняет ТЗ каждую неделю |
| TIME | Жёсткость сроков | «Сдать к 1 сентября любой ценой» |
| STOR | Память | Встроенное устройство с лимитом RAM |
| VIRT | Производительность | Жёсткий лимит CPU на борту |
| TURN | Реакция на изменения | Долгое согласование каждого CR |
Каждый множитель > 1 увеличивает PM, < 1 — уменьшает (опыт, reuse, зрелые инструменты).
Связь с квалификацией команды: слабый PCAP и ACAP в модели — то же, что «нам нужна сильная команда» в смете.
Расчёт срока и команды
После PM модель даёт календарную длительность TDEV (Time DEVelopment — месяцы календаря, не человеко-часы):
TDEV = C × PM^F
- C ≈ 3.67, F зависит от суммы SF (для Post-Architecture часто около 0.28 + 0.02 × Σ SF).
Средняя численность команды:
N ≈ PM / TDEV
Интуиция: если работа = 48 человеко-месяцев, а календарь = 12 месяцев, в среднем одновременно занято 48 / 12 = 4 человека. На старте и в конце фазы число другое — формула даёт среднее по проекту.
Закон Брукса (на пальцах): удвоение людей не уменьшает срок вдвое — растёт координация. COCOMO это отражает: при росте PM срок TDEV растёт медленнее, чем труд, но не обращается в ноль.
Пример: PM = 48 чел.-мес., TDEV = 12 мес. → 4 человека в среднем (упрощённо).
Числовой пример (учебный)
Условие: заказная информационная система, оценка 80 KSLOC после проектирования. Команда опытная, но требования нестабильны, надёжность повышенная, документирование формальное (госзаказ).
Упрощённо (не все множители):
| Параметр | Значение |
|---|---|
| Size | 80 KSLOC |
| Σ SF | 12 → E = 0.91 + 0.12 = 1.03 |
| Size^E | 80^1.03 ≈ 93.5 |
| A × Size^E | 2.94 × 93.5 ≈ 275 |
| ∏ EM (условно) | RELY×PCON×DOCU×… ≈ 1.35 |
| PM | 275 × 1.35 ≈ 371 чел.-мес. |
TDEV ≈ 3.67 × 371^0.32 ≈ 28 месяцев календарных.
Стоимость (если средняя полная ставка 250 000 ₽/чел.-мес.):
371 × 250 000 ≈ 92,8 млн ₽ только на разработку — без инфраструктуры, лицензий, накладных компании.
Цифры иллюстративные: без калибровки по вашей организации модель даёт порядок величины. Главный вывод — то, что нестабильные требования и формальная документация заметно двигают EM и SF.
Размер без KLOC — Function Points
На ранних стадиях KLOC неизвестен. COCOMO II допускает:
- Оценить Function Points (FP) по требованиям (см. оценку трудозатрат).
- Перевести FP → SLOC через Language Level (таблица «сколько SLOC на один FP» для Java, C++, Python…).
- Подставить Size в формулу.
Так связаны гл. 1.5 (сложность) и гл. 1.6 (экономика).
Влияние команды и среды — что реально меняет итог
| Фактор из учебника | В COCOMO II | Практический смысл |
|---|---|---|
| Опыт коллектива | PCAP, LTEX, APEX | Новички на embedded могут удвоить PM |
| Технологическая среда | TOOL, PLEX | CI/CD и зрелый стек снижают EM |
| Компьютерная среда | VIRT, STOR | Жёсткие лимиты RAM/CPU на борту |
| Масштаб проекта | Size, SF | «Раздувание» архитектуры без прецедентов |
Инструменты автоматизации
- USC COCOMO II.81 — эталонная реализация (Windows/desktop).
- Таблицы в Excel / Google Sheets — для учебных расчётов.
- Коммерческие ALM иногда включают параметрические модули.
Инструмент не снимает необходимость честно оценить SF и EM: «нажал кнопку — получил красивую цифру» без обсуждения команды — главный источник ошибок.
Ограничения и типичные ошибки
- Мусор на входе — неверный KLOC (считали строки с комментариями и автогенерацией) → PM бессмысленен.
- Игнорирование reuse — не занижать труд через RUSE без реального повторного использования.
- Agile ≠ бесплатно — короткие итерации не отменяют PCON, если заказчик меняет контракт каждую неделю.
- Одна цифра без диапазона — лучше три сценария (опт/база/песс) + параметрическая проверка.
- Калибровка — модель обучена на выборке проектов США 1990–2000-х; для вашей компании нужна своя статистика (velocity, фактические чел.-мес.).
Практический порядок оценки (воркшоп на 2–4 часа)
- Зафиксировать границу — что входит в релиз 1.0 (модули, интеграции, документация).
- Оценить размер — FP по требованиям → SLOC → KSLOC или экспертный KLOC с разбивкой по подсистемам.
- Оценить 5 SF — честно: был ли прецедент, зрелость процессов, слаженность команды (квалификация).
- Пройти 17 EM — отметить «высокие» для вашего контекста (ГОСТ → DOCU, нестабильное ТЗ → PCON).
- Посчитать PM, TDEV, N — в калькуляторе или таблице.
- Перевести в деньги — PM × полная стоимость человеко-месяца (зарплата + налоги + накладные + инфра).
- Дать диапазон — оптимист / база / пессимист (разные EM или ± размер).
COCOMO II и Agile на одном проекте
| Вопрос заказчика | Ответ COCOMO | Ответ Scrum |
|---|---|---|
| Бюджет на год | PM × ставка | Roadmap + velocity |
| Срок первой версии | TDEV | Release plan |
| Эффект усиления команды | PM растёт, TDEV сокращается с убывающей отдачей | Ограничение координации («девять женщин…») |
Два языка на одном проекте: COCOMO — на старте контракта и при крупном change request; story points — внутри спринта. Velocity потом калибрует модель под вашу организацию.
Куда читать дальше
| Тема | Материал |
|---|---|
| Базовые методы оценки | Оценка трудозатрат |
| Зрелость процессов (PMAT) | SDLC, CMMI |
| Модель качества | ISO/IEC 25010 |
| Планирование сроков | PERT и CPM |
| Маршрут курса | О разделе |
См. также
Другие статьи этого же раздела в боковом меню (как на странице «О разделе»). Восемь характеристик качества ПО простым языком: что писать в ТЗ, как проверять на приёмке и почему «без багов» — мало. SCM простым языком: конфигурационные единицы, baseline, контроль изменений и связь с Git, CI/CD и ГОСТ-документацией. Что происходит с заказным ПО после акта приёмки: виды сопровождения, SLA, экономика и типичные ошибки — простым языком. Что такое системы реального времени, чем hard RT отличается от веба, как формулировать требования и тестировать на стенде — для новичка. Испытания, удостоверение качества и сертификация — простым языком: ПМИ, акт приёмки, ФСТЭК и что закладывать в смету. Какие компетенции нужны PM, архитектору, аналитику, разработчику и QA на заказном проекте — и как это влияет на оценку COCOMO.Модель качества ISO/IEC 25010
Управление конфигурацией программных комплексов
Сопровождение программных комплексов
Заказные системы реального времени
Сертификация и приёмка заказных программных продуктов
Квалификация команды для заказной разработки