3.3.1.2 Постархитектурная модель.

3.3.1.2 Постархітектурная модель. Постархітектурная модель включає в себе фактичну розробку і супровід програмного продукту. ПО має розроблятисявідповідно до моделі ЖЦ, яка надає більш точну інформаціюстосовно вхідних даних параметрів вартості, і дозволяєпроводити більш точну оцінку вартості. Модель ЖЦ може бутивалідувати щодо цільового призначення системи, принципівфункціонування та ризику; і встановлена ​​як каркас (framework) програмного продукту. Для установки розмірів використовуються програмні рядки та / або функціональніточки, з модифікаторами багаторазового використання імодульності ПЗ; набір з 17 мультиплікативних параметріввартості; і набір з 5 масштабних коефіцієнтів, що визначаютьекспоненту масштабування проекту, які замінюють поширений,полуспеціалізірованний і вбудований тип проекту для базовоїСОСОМО. Основне рівняння постархітектурной моделі має наступнийвигляд:

де a – константа і її значення дорівнює 2.55 і b розраховує її по формулі:

де W – набір з 5 масштабних коефіцієнтів приведених в таблиці:

W(i)	Очень низкий	Низкий	Номинальный	Высокий	Очень высокий	Высший
Предшественность	4.05	3.24	2.42	1.62	0.81	0.00
Разработка/ Гибкость	6.07	4.86	3.64	2.43	1.21	0.00
Архитектура/ Определение риска	4.22	3.38	2.53	1.69	0.84	0.00
Сплоченность команды	4.94	3.95	2.97	1.98	0.99	0.00
Зрелость процесса	4.54	3.64	2.73	1.82	0.91	0.00

Поправочний коефіцієнт трудовитрат (EAF) розраховується напідставі 17 параметрів вартості які розділені на 4 групи, яквидно з наступних двох таблиць:

Таблица

Параметры	Описание
Продукта	Учитывают характеристики разрабатываемого ПО. (RELY, DATA, CPLX, RUSE, DOCU).
Платформы	Учитывают характеристики программно-аппаратного комплекса, требуемого для функционирования ПО. (TIME, STOR, PVOL).
Персонала	Учитывают уровень знаний и слаженности работы коллектива программистов. (ACAP, PCAP, PCON, APEX, PLEX, LTEX).
Проекта	Учитывают влияние современных подходов и технологий, территориальной удаленности членов коллектива разработчиков и сроки выполнения проекта. (TOOL, SITE, SCED).

Таблица

Параметры	Описание
RELY (Required Software Reliability)	Учитывает меру выполнения программой задуманного действия в течение определенного времени (периода времени).
DATA (Database Size)	Учитывает влияние большого объёма тестовых данных на разработку продукта. Уровень этого параметра рассчитывается как соотношение байт в тестируемой базе данных к SLOC в программе.
CPLX (Product Complexity)	Включает в себя пять типов операций: операции управления, счетные операции, устройство-зависимые операции, операции управления данными, операции управления пользовательским интерфейсом. Уровень сложности это субъективное средне-взвешенное значение уровней типов операций.
RUSE (Developed for Reusability)	Учитывает трудозатраты, требуемые дополнительно для написания компонентов, предназначенных для повторного использования в данном или последующих проектах. Использует следующие оценочные уровни: “в проекте”, “в программе”, “в линейке продуктов”, “в различных линейках продуктов”. Значение параметра накладывает ограничения на следующие параметры: RELY и DOCU.
DOCU (Documentation Match To Life-Cycle Needs )	Учитывает степень соответствия документации проекта жизненному циклу этого самого проекта.
TIME (Execution Time Constraint)	Учитывает временные ресурсы, используемые ПО, при выполнении поставленной задачи.
STOR (Main Storage Constraint)	Учитывает процент использования хранилищ данных.
PVOL (Platform Volatility)	Учитывает срок жизни платформы. Под платформой подразумевается комплекс аппаратного и программного обеспечения, который требуется для работы разрабатываемого ПО.
ACAP (Analyst Capability)	Учитывает анализ, способность проектировать, эффективность и коммуникативные способности группы специалистов, которые работают над выработкой требований и спецификаций к проекту. Данный параметр не должен оценивать уровень квалификации отдельно взятого специалиста.
PCAP (Programmer Capability)	Учитывает скорее уровень программистов в коллективе, чем отдельно взятых программистов. При выборе значения для этого параметра следует особо обратить внимание на коммуникативные и на профессиональные способности коллектива в целом и на командную работу.
PCON (Personnel Continuity)	Учитывает продолжительность работы (текучесть) кадров в коллективе.
APEX (Applications Experience)	Учитывает опыт коллектива при работе над приложениями определенного типа.
PLEX (Platform Experience)	Учитывает умение использовать особенности платформ, такие как графический интерфейс, базы данных, сетевой интерфейс, распределенные системы.
LTEX (Language and Tool Experience)	Учитывает опыт программистов при работе с языками, средами и инструментами для программирования.
TOOL (Use Of Software Tools)	Учитывает уровень использования инструментов разработки.
SITE (Multisite Development)	Учитывает территориальную удаленность (от офиса до международных офисов) членов команды разработчиков и используемые ими средства коммуникации (от телефона до видео конференц-связи).
SCED (Required Development Schedule)	Учитывает влияние временных ограничений, накладываемых на проект и на значение трудозатрат.

І постархітектурная модель, і модель раннього етапурозробки, використовують ту ж саму функціональну форму дляоцінки трудовитрат і календарного часу, який знадобиться длярозробки програмного проекту. Ці формули номінальногографіка (NS) виключають параметр вартості «НеобхіднийГрафік Розробки (SCED)». Трудовитрати в людино-місяцях,PMNS, оцінюються формулою:

где

Кількість календарного часу, TDEVNS, який буде потрібно длярозробки програмного продукту, оцінюється формулою:

де

Значення n дорівнює 16 для коефіцієнтів трудовитрат EMi Постархітектурной моделі, і дорівнює 6 для Моделі раннього проектування, SFj представляє число експоненціальних масштабних коефіцієнтів. Значення A, B, EM1 ..., EM16, SF1 ..., і SF5 для Постархітектурной моделі COCOMO II 2000 отримала шляхом калібрування за фактичними параметрами і значенням трудовитрат 161 проекту, що міститься в даний час в базі даних COCOMO II. Значення C і D для рівняння графіка розробки COCOMO II 2000 отримала шляхом калібрування за фактичним значенням графіків розробки 161 проекту, що міститься в даний час в базі даних COCOMO II. Значення A, B, C, D, SF1 ..., SF5 для Моделі раннього проектування відповідають таким для Постархітектурной моделі. Значення EM1 ..., EM6 для Моделі раннього проектування отримані шляхом комбінації 16 відповідних значень для Постархітектурной моделі. Індекс, NS для PM і TDEV вказує на те, що вони є оцінкою трудовитрат і календарного часу при номінальному графіку розробки. Результати стиснення графіка розробки або розтягування описується додатковим параметром вартості, Необхідний Графік Розробки (Required De ¬ velopment Schedule). Вони також включені в калібрування COCOMO лютого 2000 за 161 проекту. Розмір виражається в тисячах програмних рядків (KSLOC) або в нескорректированной функціональних точках (UFP).Вартість розробки виходить, множачи трудовитрати в людино-місяцях на середню заробітну плату за людино-місяць.Значення A, B, C, D і при калібруванні COCOMO лютого 2000 такі: A = 2.94 B = 0.91 C = 3.67 D = 0.28 Як приклад, давайте оцінимо, скільки трудовитрат і календарного часу буде потрібно для розробки проекту розміром 100 KSLOC. Для стандартного проекту, всі коефіцієнти трудовитрат рівні 1.0. Для Е буде встановлено на 1.15, що означає стандартний великий проект. Оцінений трудовитрат: PMNS = 2.94 (100) 1.15 = 586.61. Продовжуючи приклад, тривалість оцінюється як TDEVNS = 3.67 (586.6) (0.28 +0.2 x (1.15-0.91)) = 3.67 (586.6) 0.328 = 29.7 місяців. Стандартна кількість людей у ​​штаті розробників, необхідного для розробки проекту по номінальному графіком, таке: PMNS / TDEVNS = 586.6 / 29.7 = 19.75 або приблизно 20 осіб. У даному прикладі, для завершення стандартного проекту розміром 100 KSLOC потрібно приблизно тридцять місяців і двадцять чоловік. 3.3.2 Калібрування Постархітектурной моделі 3.3.2.1 Збір даних Збір даних був початий у вересні 1994. Дані надавалися організаціями, які були афільованими членами центру з розробки ПЗ при університеті Південної Каліфорнії, а також бралися з інших джерел. Ці організації представляли комерційні, аерокосмічні та фінансуються урядом центри досліджень і розробки (FFRDC) з сектора розробки ПЗ, причому аерокосмічні підрозділи були найбільш інформативними з точки зору наданих даних. Дані збиралися за допомогою форми, яка містить від 33-х до 59-і питань, в залежності від рівня повторного використання коду в проекті. Зібрані дані були історичними, тобто були отримані з завершених проектів. Дані збиралися за допомогою візитів фахівців, телефонних опитувань, або пересиланням заповнених форм. У якості відправної точки для калібрувальної бази даних деякі з проектів COCOMO 81 і Ada COCOMO були перетворені у вхідні дані COCOMO II. Загальна кількість експериментів, використаних для калібрування, було рівним 83, отриманих від 18 різних компаній і організацій. Цей набір даних створив основу для початкової калібрування. Всі зібрані дані були відзначені загальним ідентифікатором.Джерела даних зберігалися в іншому місці для збереження конфіденційності. Дані зберігалися в заритий приміщенні з доступом тільки для персоналу, який бере участь в дослідженні. Коли дані вносилися в репозитарій, вони перевірялися на повноту і цілісність. Неповні та нецілісність дані були видалені з калібрувального набору. Зібрані дані включали в себе трудовитрати і графіки розробки проектів. Трудовитрати вимірювалися в людино-місяцях.Людино-місяць дорівнює 152 годинам на місяць і включає годинник на розробку та управлінські процедури. Графік розробки вимірювалися в календарних місяцях.Скоригованими KSLOC є тисячі рядків коду, скоригованих з урахуванням повторного використання і помилок. Наступні три гістограми показують частотну характеристику для цих даних. В цілому 83 експерименту варіювалися в розмірах від 2 до 1300 KSLOC, в трудовитратах від 6 до 11 400 людино-місяців і в графіці розробки від 4 до 180 місяців. 3.3.2.2 Калібрування моделі. Всебічний метод калібрування регулює значення всіх параметрів вартості в Постархітектурной моделі. Такий рівень аналізу потребує великих обсягів даних, найчастіше великих, ніж наявні в організації. Кожна модель COCOMO з сімейства COCOMO II матиме приставку з роком, що визначає набір даних, на яких дана модель заснована, наприклад COCOMO II.2000. Статистичний аналіз, який використовується при калібруванні моделі, називається множинним регресійний аналіз (аналіз взаємозв'язку між залежною змінною і кількома впливають на неї змінними). Тим не менш, множинний регресійний аналіз, в результаті якого виводяться значення для bi, може застосовуватися тільки з лінійними моделями: b0 + b1A + b2B + b3C = D. Модель COCOMO в стандартній формі не є лінійною. Це означає, що деякі значення беруться з експоненційної частини моделі. Для вирішення даної проблеми потрібно перетворити нелінійну модель у стандартній формі в лінійну модель. Для цього потрібно три етапи. Перший етап полягає в тому, що потрібно розкласти Рівняння 1 на унікальні коефіцієнти. Кожен коефіцієнт буде відкалібрований.

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

Множинний регресійний аналіз виконується на лінійній моделі в логарифмічному просторі. Похідні коефіцієнти, Bi, регресійного аналізу використовуються для коригування стандартних значень. Перетворення log-log підтверджується аналізом даних, що показує, що інші види перетворень таких як: log-linear, square root-linear і quad root-linear призводять до мінливої ​​дисперсії помилок. Тільки log-log перетворення задовольняє перевірку на незалежність помилок і повторень.Рівняння 3 показує фіксоване значення експоненти, Size1.01, віддалене з подальшого аналізу, оскільки потрібно зрозуміти вплив масштабних коефіцієнтів на дисперсію. З метою калібрування деякі параметри вартості були агреговані в нові параметри вартості через високу кореляції меду ними. Ця висока кореляція вносить числову нестабільність в аналіз даних. Параметри Analyst Capability і Programmer Capability були об'єднані в параметр Personnel Capability (PERS).Параметри Execution Time Constraint і Main Storage Constraint були об'єднані в параметр Resource Constraints (RCON): EM14 і EM15 в Таблиці 3. 3.3.2.3 Результати калібрування трудовитрат У множині регресійному аналізі використовувалися 83 спостереження. З них, 59 були використані для створення основного ряду коефіцієнтів. В якості залежної змінної виступали Людино-Місяці (ЧМ). Незалежними змінними були розмір (скоригований для повторного використання і помилок) і все парметри вартості, описані в таблиці 1. Коефіцієнти, отримані в результаті проведеного аналізу наведені в Таблиці 3. Дані коефіцієнти можуть бути використані в моделі за допомогою рівняння 4. Константа А отримана шляхом зведення е в ступінь B0.

Негативні оцінки коефіцієнтів не підкріплюються рейтингами, для яких збиралися дані. Для того щоб побачити ефектнегативного коефіцієнта, Таблиця 4 приводить рейтинги, стандартні значення, і повністю скориговані значення дляпараметра вартості RUSE. Грунтуючись на визначенніпараметра вартості Required Reusability (RUSE), стандартнізначення моделі показують, що зі збільшенням рейтингу відНизького (L) до Екстра-Високо (XH), обсяги трудовитрат такожзбільшуються. Скориговані значення, отримані з вибірки данихпоказують, що чим більше ПЗ і для більш широко діапазонуповторного використання розробляється, тим менше потрібнотрудовитрат. Як показано на рисунку 5, ромбики протитріугольніков, дане твердження не збігається зі значеннямикоефіцієнтів, визначених експертним шляхом.

Можливе пояснення даного феномена - це щільність розподілу даних, що використовуються для калібрування параметраRUSE, Малюнок 6. В результаті опитування було отримано багато оцінок «Я не знаю» або «Не підходить тут». Це восновному відповідає номінальному рейтингу в моделі. Це послаблює аналіз даних відразу в двох напрямках: слабкадисперсія значень оцінок і можливість неточності значеньданих.

Рисунок 5. RUSE Calibrated Values

Рисунок 6. Frequency of RUSE

Афілійовані користувачі COCOMO II були змушенівикористовувати чисту регресійну модель з нелогічнимитенденціями такими, як трикутники на Малюнку 5 дляпараметра RUSE. Тому був використаний середньо-зваженийпідхід для визначення відомих параметрів вартості і тих, якібули отримані регресійним методом. Використовуючи 10%значень, заснованих на даних і 90% відомих заздалегідь,Таблиця 5 містить відкалібровані значення моделі COCOMO II.Значення константи А встановлено рівним 2,45. Десятивідсотковий ваговий коефіцієнт був обраний післяпорівняльних експериментів з різними ваговимикоефіцієнтами, який показав, що інші значення ваговогокоефіцієнта дають менш точні результати. Це спрямовуєпараметри моделі в напрямку, запропонованому регресійнимкоефіцієнтами, але зберігає принцип, закладений в початковихзначеннях. З ростом обсягів даних, що використовуються длякалібрування, зростає відсоток вагового коефіцієнта, що віддається значенням, визначеним регресією.

Детальний розгляд параметра вартості Process Maturity(PMAT) показало, що підхід, керований даними, заслуговуєдовіри (є правдоподібним). Для визначення вплив параметраPMAT на значення трудозатрат використовувався більшийобсяг даних. Параметр PMAT статистично значимий з великиммасивом даних у порівнянні з невизначеним значенням,наведеним у Таблиці 3 (значення Т менше 1,96). Така відмінність продиктовано тим, що додатковий масив даних маєбільш велику дисперсію результатів параметра PMAT накінцях його рейтингових оцінок. 3.3.2.4 Результати калібрування Графіка розробки COCOMO II дозволяє оцінювати графік розробки (TDEV),Рівняння 5. Калібрується тільки константа для рівнянняграфіка розробки. Відкалібрований константі графікарозробки А присвоюється значення 2,66. Початкове значення було 3,0.