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

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

Таблиця1

Розмір ПЗ	Стандартне значення KLOC
Малий	2
Проміжний	8
Середній	32
Великий	128
Очень большой	512

Таблиця2

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

Тип розробки	Витрати труда	Термін розробки
Поширений	PM=2,4хKLOC1,05	СР=2,5хPM0,38
Напівспеціалізований	PM=3,0хKLOC1,12	СР=2,5хPM0,35
Вбудований	PM=3,6хKLOC1,20	СР=2,5хPM0,32

Таблиця3

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

Характеристика	Тип розробки	Оцінка для розмірів
		малого, 2 KLOC	проміжного, 8 KLOC	середнього 32 KLOC	великого, 128 KLOC	дуже великого, 512 KLOC
Витрати праці, PM	Поширений Напівспеціалізований Вбудований	5,0 6,5 8,3	21,3 31,0 44,0	91 146 230	392 687 1216	3250 6420
Продуктивність праці, LOC/PM	Поширений Напівспеціалізований Вбудований	400 308 241	376 258 182	352 219 139	327 186 105	158 80
Терміни розробки, міс.	Поширений Напівспеціалізований Вбудований	4,6 4,8 4,9	8,0 8,3 8,4	14 14 14	24 24 24	42 41
Среднє число виконань, P	Поширений Напівспеціалізований Вбудований	1,1 1,4 1,7	2,7 3,7 4,2	6,5 10,0 16,0	16 29 51	77 157

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

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

3.3. COCOMO II.

Основні цілі, які привели до розробки моделі COCOMO II: • Розробити модель оцінки вартості та графіка розробки ПЗ, побудовану на досвіді використання ЖЦ ПО 1990-их і 2000-их років. • Розробити підтримку бази даних ПЗ та інструментів для постійного удосконалення моделі. • Забезпечити наявність кількісної аналітичної середовища і набору інструментальних засобів і методів для оцінки впливу вдосконалених технологій розробки ПЗ на вартість і графік розробки. Модель COCOMO II використовує три різні метрики для оцінки розміру проекту: Об'єктні Точки (OP), нескорректированной Функціональні Точки (UFP), і Програмні Рядки коду (SLOC).Нескорректированной Функціональні Точки увазі використання стандартизованого [IFPUG 1994] підходу до оцінки розміру, що включає лінійну комбінацію вводів, висновків, файлів, інтерфейсів, і запитів, але без використання 14 характеристик ПЗ, таких як розподілені функції, продуктивність, і багаторазове використання. Замість цього, COCOMO II враховує ці фактори за допомогою стандартного набору параметрів вартості. У COCOMO II, логічний вихідний оператор вибраний як стандартна програмна рядок. Визначення програмної рядка є скрутним через концептуальних відмінностей у способі підрахунку виконуваних операторів та оголошень у різних мовах. Мета полягає в тому, щоб виміряти кількість інтелектуальної праці, необхідної для розробки програми, але труднощі виникають при спробі визначити загальні заходи для різних мов. Щоб мінімізувати ці проблеми, для визначення міри програмної рядка використовується перелік визначень Інституту Інженерії програмного забезпечення (SEI) для логічного вихідного оператора. Інститут Інженерії програмного забезпечення (SEI) розробив цей перелік як частина системи переліків визначень, форм звітів і додаткових форм. Деякі зміни були внесені до визначення програмних рядків, яке відступає від стандартного визначення. Ці зміни усувають категорії ПЗ, які є маленькими джерелами трудовитрат. Не включені у визначення - комерційні коробкові програмні продукти (COTS); ПЗ, що надається урядом (GFS), бібліотеки мовної підтримки та операційні системи, або інші комерційні бібліотеки. Код, згенерований за допомогою генератора вихідного тексту не включається, хоча виміри будуть взяті «с» і «без» згенерованого коду для можливості аналізу. Сектор приватного програмування не потребує моделі COCOMO II. Такі програми зазвичай розробляються протягом декількох годин або днів, так що простий оцінки на основі діяльності взагалі буде цілком достатньо. Модель COCOMO II для сектора створення додатків, звана Моделлю Створення Додатків (Application Composition Model), заснована на об'єктних точках. Об'єктні точки - метрика, яка включає в себе підрахунок екранів, повідомлень і модулів мови третього покоління, створених у додатку, кожен з яких оцінюється відповідно до трьома рівнями (простий, середній, складний) коефіцієнта складності. Це пропорційно з рівнем інформації взагалі відомої про продукт на етапі створення програми протягом стадії планування, і з відповідним рівнем точності, необхідних для виконання оцінки (такі програми зазвичай розробляються невеликою групою протягом декількох тижнів або місяців).

Рівні коефіцієнта складності об'єктних точок для екранів.

Кількість	Кількість таблиць даних
	<4	<8	8+
<3	простий	простий	середній
3-7	простий	середній	складний
8+	середній	складний	складний

Уровни коэффициента сложности объектных точек для отчетов.

Количество	Количество таблиц данных
	<4	<8	8+
<3	простой	простой	средний
3-7	простой	средний	сложный
8+	средний	сложный	сложный

Вагові коефіцієнти об'єктних точок.

Тип об’єкта	Простий	Середній	Складний
Екран	1	2	3
Зввіт	2	5	8
Модуль мови 3 покоління	-	-	10

Зважені значення підсумовуються для отримання загальної кількості об'єктних точок. Тоді ж враховується і повторне використання коду. Вважаючи, що r% об'єктів будуть повторновикористані від попередніх проектів, кількість нових об'єктних точок (NOP) буде наступним:

Рівень продуктивності (PROD) визначається з наступноїтаблиці: Середні рівні продуктивності на основі досвідченості і здібностей розробника

Опытность и способности разработчика	Очень низкий	Низкий	Номинальный	Высокий	Очень высокий
PROD	4	7	13	25	50

Таким чином, трудовитрати можуть бути розраховані за такоюформулою:

Найбільш ранні стадії ЖЦ або спіральні цикли зазвичай мають на увазі стадію прототипування, використовуючи можливості моделі створення додатків. Вона також підтримує інші види прототипування, що зустрічаються пізніше в ЖЦ такі як трудовитрати, необхідні для вирішення потенційних задач підвищеної важливості таких як інтерфейси, програмне / системну взаємодію, продуктивність і рівень зрілості технології. 3.3.1.1 Модель раннього проектування. Модель раннього проектування включає в себе дослідження альтернативних програмних / системних архітектур та принципів функціонування. На цьому етапі розробки неможливо дати точну оцінку вартості. Відповідна можливість COCOMO II увазі використання функціональних точок і набору з 7 параметрів вартості (наприклад, використання двох параметрів вартості для Здібностей Персоналу (Personnel Capability) та досвідчений персонал (Personnel Experience) замість 6 параметрів вартості постархітектурной моделі, що охоплюють різні аспекти здібностей персоналу, цілісності команди , і досвідченості). Такий рівень деталізації відповідає загальній кількості доступної інформації і загальному рівню точності оцінки, необхідної на цьому етапі розробки. Число функціональних точок перетворюється на число програмних рядків за допомогою такої таблиці: Рівні мов програмування і граничні значення кількості програмних рядків на одну функціональну точку.

Язык	Уровень	Мин.	Средн.	Макс.
Машинный язык	0.10	-	640	-
Ассемблер	1.00	237	320	416
C	2.50	60	128	170
RPGII	5.50	40	58	85
C++	6.00	40	55	140
Visual C++	9.50	-	34	-
PowerBuilder	20.00	-	16	-
Excel	57.00	-	5.5	-

Основне рівняння моделі раннього проектування має наступний вигляд:

,

де  а - це константа з попередньо встановленим значенням2.45. Поправочний коефіцієнт трудовитрат (EAF) розраховується напідставі 7 параметрів вартості наведених у таблиці:

Параметр стоимости	Описание	Соответствующие параметры стоимости постархитектурной модели
RCPX	Надежность и сложность продукта	RELY, DATA, CPLX, DOCU
RUSE	Требуемый уровень повторного использования кода	RUSE
PDIF	Сложность платформы	TIME, STOR, PVOL
PERS	Способности персонала	ACAP, PCAP, PCON
PREX	Опытность персонала	AEXP, PEXP, LTEX
FCIL	Средства	TOOL, SITE
SCED	Требуемы График Разработки	SCED