Основные уравнения трудозатрат

У табл.2 наведено рівняння базової COCOMO для оцінки праці і термінів розробок поширених, напівнезалежних і вбудованих типів. У табл.3 наведені приклади оцінок, які отримані з цих рівнянь, оцінки продуктивності праці і середньогочисла виконавців, що беруть участь у розробці, за всіма типами програмних розробок наступних стандартних розмірів:

Таблиця1

Таблиця2

Рівняння базової COCOMO для оцінки витрат праці і термінів розробки:

Таблиця3

Оцінки за базовою COCOMO для розробок вироба стандартних розмірів

Головні відмінності типів розробок полягають в наступному:
1. При однаковому розмірі програмних виробів для вбудованого типу розробок оцінки витрат праці значно більше, а продуктивність праці значно менше, ніж для розповсюдженого типу.
2. При збільшенні розміру вироби продуктивність праці знижується більш помітно для вбудованого типу розробки.
3. Залежність оцінки термінів розробки від розмірів програмного продукту приблизно однакова для всіх типів.
4. При однакових термінах розробки на вбудований проект потрібні великі затрати праці.
Дані табл.2 показують, як важливо інженернеру -програмісту вміти розпізнавати різні типи програмної розробки. Наприклад, якщо йому необхідно розробити вбудований виріб середнього розміру (32 KLOC), а оцінка та укомплектування проекту виконавцями здійснена як для поширеного проекту, то відбудеться серйозна недооцінка витрат праці (буде отримана оцінка в 91 PM замість 230 PM).Крім того, таке планування штату проекту призведе до тяжко виправних ситуацій (таке трапилося з багатьма програмними проектами)

Поширений тип характеризується тим, що ПЗ розробляється відносно невеликою групою фахівців в дуже знайомих умовах своєї фірми. Більшість пов'язаних з проектом людей володіють великим досвідом роботи з аналогічними системами в умовах своєї організації і добре розуміють, як і яким чином розроблена система сприятиме досягненню цілей фірми.
Це означає, що більшість учасників проекту можуть з користю брати участь на початкових стадіях розробки, не створюючи при цьому великих накладних витрат на обмін інформацією про сутність проекту та завдання інших учасників. Це також означає, що зі збільшенням розміру проекту втрати виробництва праці, викликані накладними витратами на обмін інформацією, зростають порівняно слабо.
У проекті поширеного типу накладаються відносно менш жорсткі обмеження на відповідність вимогам ПЗ і специфікаціям інтерфейсу. Якщо виникає ситуація, при якій досягнення такої відповідності привело б до великих переробок, то бригада розробників може, як правило, домовитися про зміну специфікацій, що полегшує оновлення ПЗ і адаптацію користувача. Це ще одна причина більш високої продуктивності праці і меншого негативного ефекту масштабу для поширеного проекту.
Іншими характерними рисами програмних проектів поширеного типу є наступні:
• зазвичай стабільні умови розробки проекту з незначною паралельної розробкою ПО, нового технічного забезпечення ня (ТО) і обчислювального процесу;
• мінімальна необхідність нових системних і алгорітміче ських рішень проблем обробки даних;
• відносно мала заохочення за раннє завершення проекту;
• відносно малий розмір.
У дуже небагатьох поширених проектах були розроблені нові засоби ПО розміром більше 50 KLOC (більші вироби часто можуть бути розроблені в умовах існуючого ПО).
Полуспеціалізірованний тип програмної розробки займає про проміжне положення між поширеним і вбудованим типами.Проміжність положення визначається наявністю будь-якого з наступних двох властивостей:
• проміжні значення характеристик проекту;
• зсув характеристик поширеного і вбудованого типів.
Так, по відношенню до ознаки «досвід роботи з аналогічними системами ПЗ» полуспеціалізірованний проект може характеризуватися такими властивостями:
• всі члени бригади мають середній досвід роботи;
• склад бригади вкрай неоднорідний за ступенем досвідченості;
• члени бригади знайомі лише з деякими характеристиками, що розробляється.
Щодо відповідності специфікацій функцій і інтерфейсу типовим прикладом напівнезалежною проекту міг би з'явитися проект розробки системи обробки повідомлень з вельми суворим дотриманням одних правил інтерфейсу (наприклад, що накладаються термінальним ТО або урядовими вимогами) і з досить гнучким - інших правил (наприклад, що відносяться до змісту та формату повідомлень на дисплеї оператора і відомостями про тенденції поширення). Ця часткова гнучкість зв'язку системи з користувачами пояснює походження терміна «полуспеціалізірованний».
На закінчення зазначимо, що розмір полуспеціалізірованного ПО зазвичай не перевершує 300 KLOC.
Вбудований тип відрізняється від інших жорсткими обмеженнями на характеристики ЕОМ і правила використання інтерфейсу. Таке ПЗ повинно працювати при тісному взаємозв'язку ап паратури, програм, посібників і обчислювальних процесів. Прикладами є система резервування авіаквитків і система управління повітряним рухом. Як правило, витрати на зміну частин програмного комплексу настільки високі, що набагато вигідніше залишати характеристики комплексу незмінними. Внаслідок цього слід очікувати стабільності ПО вбудованого типу.
При розробці вбудованого ПЗ, як правило, відсутня можливість домовитися про зменшення змін і виправлень у програмах при модифікації вимог і інтерфейсу. Тому вбудований проект вимагає великих витрат на зміни та виправлення. Він вимагає також більш високих трудозатрат на встановлення відповідності ПЗ своїм специфікаціям (більш високі витрати на перевірки та затвердження) та забезпечення правильності змін (більш високі витрати на управління конфігурацією). Всі ці фактори призводять до зменшення продуктивності праці, а також до збільшення негативного ефекту масштабу для великих проектів.
У порівнянні з поширеним вбудований проект, як пра вило, планується при меншому обсязі інформації про умови його реалізації. Це змушує використовувати малу бригаду аналітиків на ранніх стадіях проекту, в іншому випадку величезні накладні витрати на обмін інформацією погубили б проект на самому початку.
Після завершення проектування виробу кращою стратегією здійснення вбудованого проекту є залучення дуже великої групи програмістів для паралельного виконання детального проектування, кодування і автономного налагодження. В іншому випадку для завершення проекту потрібно було б набагато більше часу, що було б небажано з двох головних причин:
• у виріб довелося б включати більшу кількість змін;
• до моменту поставки виріб застаріло б більшою мірою, (взагалі кажучи, за раннє завершення проекту вбудованого типу заохочують більшою мірою, що часто обумовлюється необхідністю швидкого введення в дію всього комплексу.)
Для вбудованих проектів вказана стратегія призводить до більш високих пікам функції розподілу числа виконавців і до великих затра там праці, ніж у проектах поширеного типу, що реалізуються в такі ж загальні терміни.

Основна модель COCOMO добре підходить для швидкої грубої ранньої оцінки трудовитрат на розробку ПЗ, але точність такої оцінки завжди обмежена через брак параметрів, що враховують відмінності в апаратних обмеженнях, здібностях персоналу і досвід використання сучасних інструментальних засобів і методів, і інших параметрів проекту, які можуть мати істотний вплив на вартість розробки ПЗ.
У проміжній COCOMO використовується 15 параметрів вартості, об'єднаних у чотири групи.
1. Параметри програми:
необхідна надійність ПЗ;
розмір бази даних програми;
складність ПО.
2. Параметри ЕОМ:
обмеження по швидкодії;
обмеження по оперативної пам'яті;
мінливість віртуальної машини;
цикл звернення.
3. Параметри виконавців:
кваліфікація аналітика;
досвід роботи в даній прикладній області;
кваліфікація інженера ПО;
досвід роботи з віртуальною машиною;
досвід роботи з мовою програмування.
4. Параметри проекту:
застосування методів інженерії ПЗ;
використання інструментальних засобів;
графік розробки.
Кожному із зазначених параметрів вартості відповідає коефіцієнт, що характеризує вплив параметра на процес розробки. Дані коефіцієнти використовуються як множників при отриманні з номінальних оцінок СОСОМО уточнених оцінок трудовитрат на розробку. Аналогічно уточнюється і оцінка трудовитрат на супровід ПЗ.
У проміжній СОСОМО оцінювання трудовитрат на розробку починається з визначення номінальних трудовитрат за рівняннями, які мають той же вигляд, що і рівняння базової СОСОМО. Потім отримане значення коригується шляхом множення на коефіцієнти трудовитрат, визначаються відповідно до оцінки ками проекту, за основними параметрами п'ятнадцяти вартості.
Незважаючи на високу ефективність проміжної СОСОМО для більшості випадків оцінки вартості ПЗ основні два її обмеження можуть виявитися істотними, особливо при детальному оцінюванні вартості у великих програмних проектах:
• оцінка розподілу витрат праці по фазах може виявитися неточною;
• застосування для багатокомпонентного ПО може виявитися дуже трудомістким.
Дві головні можливості детальної СОСОМО спрямовані на усунення цих обмежень проміжної СОСОМО:
1. Фазові коефіцієнти трудовитрат. У проміжній СОСОМО розподіл трудовитрат по фазах залежить виключно від розміру програмного продукту. На практиці такі параметри, як необхідна надійність, досвід в прикладної області, діалогова розробка ПЗ, на одних фазах грають значно більшу роль, ніж на інших. У детальної СОСОМО кожному параметру вартості відповідає набір коефіцієнтів. Ці коефіцієнти використовуються при визначенні загальних трудовитрат, необхідних для завершення кожної фази.
2. Трирівнева ієрархія програмного продукту. У проміжній СОСОМО для різних компонентів програми можуть застосовуватися різні рейтинги параметрів вартості. Якщо кілька компонентів згруповані в підсистему с, практично, однаковими рейтін гами параметрів вартості, то покомпонентний обробка буде стомлюючої і необов'язковою. У детальної СОСОМО ця проблема вирішується забезпеченням трирівневої ієрархії програмного продукту, в якій:
• параметри, що змінюються від модуля до модуля, розглядаються на рівні модулів;
• параметри, що змінюються не дуже часто, розглядаються на рівні підсистеми;
• такі параметри, як розмір всього програмного продукту, розглядаються на рівні системи.
Крім того, в детальну СОСОМО включені деякі додаткові можливості, як, наприклад, процедура коригування розподілу термінів розробки по фазах. Для деяких можливостей, таких як оцінка термінів завершення розробки та оцінка розподілу трудозатрат за видами робіт, детальна СОСОМО використовує ті ж методи, що проміжна і базова СОСОМО.