ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - М. Сидоров

де a і b- точки в просторі; a1... an і b1... bn - координати точок у відповідних площинах.

Проекти, що мають найбільшу схожість, будуть розташовані щонайближче, тобто евклідова відстань у них буде найменшою. Останнім станом с експерт на оцінка проекту, що розробляється, в якій значення, взяті а аналогічного проекту, використовуються як база оцінки.

Моделі оцінювання вартості 173. Модель оцінювання вартості програмного забезпечення - цс одна або декілька функцій, які опи­сують залежність між характеристиками проекту і витратами на його реалізацію. Моделі поділяють за типом використовуваних фу­нкцій на лінійні, мультиплікативні, статичні; за використанням іс­торичних даних на емпіричні та аналітичні. Моделями, що часто реалізуються і є добре документованими, є моделі Путнема (стати­чна, аналітична) і COCOMO (статична, емпірична).

Модель Путнема (SLIM). Найбільш поширена модель аналітич­ної групи. Створена для проектів обсягом понад 70 000 рядків коду, модель ґрунтується на твердженні, що витрати на розробку ПО розподіляються згідно з кривими Нордена-Рейлі, які є графіками функцій, що розподіляє робочу силу за часом. Загальний вигляд подібної функції: де v - набуте значення; t- час, a v0 і tp - параметри, що визначають функцію. Для великого значення t крива прагне до параметра v0 , який називається cost scale factor parameter, функція зростає найшвидше при t = tp Основною причиною такої поведінки моделі було те, що спочатку дослідження Нордена ґрунтувалися не на теоретичній основі, а на спо­стереженнях за проектами, не пов'язаними з ПО (машинобудуван­ня, будівництво). Тому немає наукового підтвердження, що прог­рамні проекти потребують такого ж розподілу робочої сили. Нав­паки, часто кількість людино-годин, потрібних проекту, може різко змінитися, зробивши оцінку непридатною до використання. Після ряду емпіричних спостережень Путнем виразив робоче рівняння моделі у формі:

де Size - розмір коду в LOC; С - технологічний фактор; Е- загаль­на вартість проекту в людино-годинах; t - очікуваний час реалізації проекту.

Технологічний фактор включає в себе характеристику проекту в таких аспектах: методи управління розуміння процесу, якість вико­ристаних методів інженерії ПО, рівень використаних мов програ­мування, рівень розвитку середовища, навички та досвід команди розробників, складність додатків.

Рівняння для загальної вартості Е мас вигляд:

де D0 - коефіцієнт, що виражає кількість необхідної робота (зна­чення від 8 до 12 означає, що ПО повністю нове, з великою кількіс­тю зв'язків; значення до 27 - потрібне перероблення наявного ко­ду)- Зв'язуючи два рівняння, отримаємо таке

і

які показують, що витрати пропорційні розміру коду в степені 9/7 ≈ 1/286. Це досить близько до моделі Б. Боема, де даний чин­ник знаходиться у межах від 1,05 до 1,20 [10].

У 1991 році Путнемом була представлена альтернативна реалі­зація моделі, виконана за замовленням Quantitative Software Management (QSM) Inc. і застосована в комплексі SLIM Estimate для оцінювання вартості ПЗ [14]. Повне рівняння в цій реалізації виг­лядає як: Е = 125 ∙ B(SLOC/P)3 ∙ (1/Schedule4).

Якщо на загальний час реалізації проекту обмеження не накла­даються, то можливе використання спрощеного рівняння

тут В - чинник спеціальних навичок; Р - чинник продуктивності; Schedule - час розробки ПЗ графіку (у місяцях), Рівняння може бу­ти використане, якщо передбачувані витрата понад 20 люднно-місяцїв.

Використання наведених рівнянь потребує знання параметра Р. Для його визначення використовується спеціальна таблиця, що міс­тить значення параметра Р, залежні від середовища застосування, що розробляється.

Модель COCOMO. Сім'ю моделей COCOMO було створено в 1981 році на основі бази даних про проекти консалтингової фірми TRW.

COCOMO є третьою моделлю, орієнтованою на використання в трьох фазах життєвого циклу ПО: базова (Basic) - застосовується на етапі вироблення специфікацій, вимог, розширена (Intermediate) - після визначення вимог до ПО; поглиблена (Advanced) - викорис­товується після закінчення проектування ПЗ. У загальному вигляді рівняння моделей має вигляд:

де Е - витрати праці на проект (у людино-місяцях); S - розмір коду (у KLOC); EAF - чинник уточнення витрат (effort adjustment factor). Параметри a і b залежать від виду застосування, що розробляється, який може бути таким:

- відносно простий проект, робота над яким ведеться однорід­ною командою розробників, вимоги носять рекомендаційний харак­тер, відсутня заздалегідь вироблена вичерпна специфікація (напри­клад, нескладне прикладне програмне забезпечення);

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

- проект, який повинен бути реалізованій! у жорстких рамках заданих вимог (наприклад, програмне забезпечення системи управ­ління польотами),

У базовій моделі чинник EAF береться рівним одиниці. Для виз­начення значення цього чинника в розширеній моделі використо­вується таблиця, що містить ряд параметрів, які визначають вар­тість проекту. Використовуючи поглиблену модель, спочатку ви­конують оцінювання з використанням розширеної моделі на рівні компонента, після чого кожен параметр вартості оцінюється для всіх фаз життєвого циклу ПЗ.

COCOMO II також є сімейством моделей і є розвитком базової (Basic) моделі COCOMO. COCOMO ІІ включає три моделі - ство­рення додатків (Application Composition Model, ACM), ранній етап розробки (Early Design Model, EDM) і пост-архитектурна (Post Architecture Model, PAM).

ACM використовується на ранньому етапі реалізації проекту, для того, щоб оцінити таке: інтерфейс користувача, взаємодія з сис­темою, продуктивність. За початковий розмір береться кількість екранів, звітів і 3GL-компонентів. Якщо припустити, що в проекті буде використано r % об'єктів з раніше створених проектів, кіль­кість нових об'єктних точок у проекті (Object Points, OP) можна розрахувати як:

OP=(object роіnts)*(100-r)/100.

Тоді витрати можна розрахувати за формулою:

E=OP/PROD,

де PROD - табличне значення.

EDM - це високорівнева модель, якій потрібна порівняно неве-лика кількість початкових параметрів. Вона призначена для оціню­вання доцільності використання тих або інших апаратних і програмних засобів у процесі розробки проекту. Для визначення розміру використовується функціональна точка (Unadjusted Function Point). Для її перетворення в LOC використовуються таблиці перетворень, Рівняння моделі раннього етапу розробки мас вигляд:

E=a∙LOC∙EAF,

де а - константа 2,45; EAF визначається так само, як і в оригіналь­ній моделі COCOMO.

Параметри для EDM отримують комбінуванням параметрі» для постархітектурної моделі.

РАМ є найбільш деталізованою моделлю, яка використовується, коли проект повністю готовий до розробки, Для оцінювання вартості ПЗ за допомогою РАМ необхідний пакет опису життєвого циклу проекту, який містить докладну інформацію про чинники вартості і дозволяє провести точніше оцінювання. РАМ використовується на етапі фактичної розробки і підтримки проекту. Для оцінювання роз­мірів можуть використовуватися як рядки коду, так і функціональні точки з модифікаторами, що враховують повторне використання ко­ду. Модель використовує 17 чинників вартості і 5 чинників, що виз­начають масштаб проекту (у моделі COCOMO масштаб визначався параметрами виду додатка). Рівняння РАМ має вигляд

а взято за 2,55, а, де Wi - параметри, що відображають властивості проекту, наприклад, схо­жість з раніше виконаними проектами, ризик вибору архітектури для реалізації, розуміння процесу розробки, спрацьованості команди роз­робників. Значення параметрів є табличними.

7.3. Засоби оцінювання вартості програмного забезпечення

Широко відомі засоби оцінювання ПЗ, засновані на моделях SLIM і СОСОМО.

SLIM Estimate компанії QSM є найбільш часто використовува­ним програмним засобом для оцінювання вартості програмного забезпечення, у якому реалізована модель Путнема. Засіб входить до складу пакету прикладного програмного забезпечення і призна­чений для роботи над проектом ПЗ на початкових стадіях життєво­го циклу. У пакет, окрім засобу оцінки, також входять засоби зби­рання і зберігання даних про реалізовані проекти (SUM DataManager), аналізу цих даних (SLIM Metrics), загального конт­ролю над процесом розробки (SLIM Control). Цей пакет використо­вується для оцінювання вартості, що розробляється програмним забезпеченням у таких організаціях: Alcatel Telecom, AT&T, Athens Group, Australian Department of Defence, BАЕ, Bell South Communications, Hewlett-Packard. IBM Rational Software, Lockheed Martin, Motorola Communications, Nokia, US Air Force Cost Analysis Agency. SLIM Estimate дає змогу виконувати оцінювання вартості розробки програмного забезпечення різними способами: майстер швидкого оцінювання, оцінювання розміру, оцінювання РІ, оціню­вання непередбачених обставин, оцінювання, засноване на історичних чинниках. Першим і найчастіше використовуваним є майстер швидкої оцінки (Quick Estimate Wizard). Для цього використову­ються такі параметри: тип застосування, що розробляється; макси­мально можливий час роботи над проектом; бюджет проекту; орієн­товна загальна кількість рядків; індекс продуктивності команди розробників; відсоток повторно використовуваного коду. Форму­ються таблиці і будуються діаграми, що відображають загальну кількість задіяної робочої сили і її розподіл програмного забезпе­чення за графіком робіт.