Модель COCOMO II - оцінка трудозатрат на розробку програмного забезпечення

Базова формула

Constructive Cost Model (COCOMO II) – це одна з найпопулярніших алгоритмічних моделей для оцінювання трудомісткості розробки ПЗ, що була запропонована Баррі Боемом. Параметри та рівняння, які використовуються в моделі, отримані на основі статистистичних даних за метриками (розмір коду KLOC (тисячі рядків коду), трудомісткість, Effort (людино-місяцях) вже реалізованих програмних проєктів. Згідно, існує три моделі COCOMO: У COCOMO II зусилля виражаються в людино-місяцях (PM).
Вхідними даними є розмір розробки програмного забезпечення Size (KLOC, UFP) , константа A, показник степеня E та низка значень, які називаються множниками зусиль (EM). Кількість множників зусиль залежить від моделі.

\( PM = A \times (Size)^E \times \prod_{i=1}^{n} EM_i \)

де:

  • PM — трудомісткість у людино-місяцях
  • Size — розмір розробки (KSLOC або UFP)
  • A — константа калібрування (типово 2.94)
  • E — показник масштабування
  • EMi — множники зусиль
Показник масштабування (E)

E = B + 0.01 × ∑ SFj

де:

  • B = 0.91
  • SFj — п’ять факторів: Precedentedness, Development Flexibility, Architecture / Risk Resolution, Team Cohesion, Process Maturity, Personnel Factors
Множники зусиль (EM)
    У моделі COCOMO II використовується 17 множників:
  • Product Factors: Required Software Reliability (RELY), Data Base Size (DATA), Product Complexity (CPLX), Developed for Reusability (RUSE), Documentation Match to Life-Cycle Needs (DOCU)
  • Platform Factors: Execution Time Constraint (TIME), Main Storage Constraint (STOR), Platform Volatility (PVOL)
  • Personnel Factors: Analyst Capability (ACAP), Programmer Capability (PCAP), Personnel Continuity (PCON), Applications Experience (APEX), Platform Experience (PLEX), Language and Tool Experience (LTEX)
  • Project Factors: Use of Software Tools (TOOL), Multisite Development (SITE), Required Development Schedule (SCED)
Кількість рядків вихідного коду (Size)

Можливе визначення через KLOC, UFP.

Thousands of Lines Of Code (KLOC) Визначення кількості рядків коду є складним через концептуальні відмінності, пов'язані з обліком виконуваних операторів та оголошень даних різними мовами. Метою є вимірювання обсягу інтелектуальної роботи, вкладеної в розробку програми, але труднощі виникають під час спроби визначити узгодженя показників різними мовами. Інститут програмної інженерії (SEI) розробив контрольний список як частину системи контрольних списків визначень, форм звітів та додаткових форм для підтримки визначень вимірювань [Park 1992, Goethert et al. 1992].
KSLOC (Thousands of Source Lines of Code) розраховується за чіткими логічними правилами, де враховується лише той код, який безпосередньо створює логіку роботи програми.
Що ОБОВ'ЯЗКОВО враховується: Логічні рядки коду (вирази, функції, умови на JS/TS, Python, PHP, C# тощо).Рядки коду, які ви написали вручну. Що КАТЕГОРИЧНО ігнорується: Порожні рядки та переноси.Коментарі розробників.Автоматично згенерований код (наприклад, файли збірки dist/, build/).Бібліотеки та фреймворки з node_modules/.
Як враховувати HTML/CSS/Конфігурації: Варіант 1: Не рахувати взагалі (рахувати лише JS/РНР логіку).Варіант 2 (За стандартом COCOMO II): Рахувати окремо через коефіцієнт еквівалентності (наприклад, 4-5 рядків HTML дорівнюють 1 логічному рядку коду).

Unadjusted Function Points (UFP) Підхід до визначення Size на основі функціональних точок базується на функціональності програми та наборі окремих факторів проекту [Behrens 1983; Kunkler 1985; IFPUG 1994]. Функціональні точки є корисними інструментом, оскільки він базується на інформації, доступній на ранніх етапах життєвого циклу проекту.
Функціональні точки вимірюють програмний проект шляхом кількісної оцінки функціональності обробки інформації, пов'язаної з основними зовнішніми даними або типами вхідних, вихідних даних або файлів керування. Слід визначити п'ять типів функцій користувача:

    Дані (Data Functions)
  • ILF (Internal Logical Files): Внутрішні логічні файли. Групи логічно пов'язаних даних, які підтримуються та зберігаються всередині системи (наприклад, таблиці бази даних).
  • EIF (External Interface Files): Зовнішні інтерфейсні файли. Групи даних, які система лише використовує для читання, але які зберігаються та оновлюються в інших системах.
    Транзакції (Transactional Functions)
  • EI (External Inputs): Зовнішні вхідні потоки. Процеси, що вводять дані в систему для зміни внутрішніх файлів (ILF) або керування системою (наприклад, форми створення/редагування).
  • EO (External Outputs): Зовнішні вихідні потоки. Процеси, що виводять дані за межі системи, які містять додаткову математичну обробку чи розрахунки (наприклад, складні звіти, графіки).
  • EQ (External Inquiry): Зовнішні запити. Процеси отримання даних із системи без будь-яких математичних перетворень чи модифікації даних (наприклад, простий пошук, вивід списку).

Для кожного знайденого компонента визначається рівень складності (Low, Average, High) на основі двох параметрів:Для ILF / EIF: рахуються DET (Data Element Types - унікальні поля даних) та RET (Record Element Types - підгрупи даних). Для EI / EO / EQ: рахуються DET (унікальні поля на формі/в запиті) та FTR (File Types Referenced - кількість файлів ILF/EIF, які зчитує чи змінює ця транзакція). За стандартними матрицями IFPUG комбінація цих параметрів дає рівень складності.

Далі зважується кількість типів функцій на кожному рівні складності, використовуючи певну схему (вагові коефіцієнти відображають відносні зусилля, необхідні для реалізації функції).

Нескориговані функціональні точки необхідно конвертувати у вихідні рядки коду мовою реалізації (Ada, C, C++, Pascal тощо).

СУЧАСНІ ПІДХОДИ ДО ВАРТІСНОЇ ОЦІНКИ ПРОГРАМНИХ ПРОДУКТІВ. Л.І. Лозовська, В.В. Дудник. ISSN 2074-5362. Європейський вектор економічного розвитку. 2014. № 2 (17) What are the best practices and tools for software development cost estimation in IT consulting https://www.linkedin.com/advice/0/what-best-practices-tools-software-development-cost. АНАЛІЗ СУЧАСНОГО СТАНУ МЕТОДІВ ОЦІНЮВАННЯ ТРУДОМІСТКОСТІ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. DOI. Т. А. Фаріонова, канд. техн. наук, доцент; О. С. Орєхов, аспірант. https://doi.org/10.15589/znp2024.1(494).15 COCOMO II Model Definition Manual. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC

septima | Jun 2026