Методи і моделі оцінювання вартості ПЗ можна розділити на дві групи: неалгоритмічні методи і алгоритмічні моделі. До неалгорит-мінних методів належать Price-to-win, оцінка ПЗ Паркінсона, експертна оцінка, оцінка за аналогією. До алгоритмічних моделей, належать SLIM і COCOMO.
Суть неалгоритмічних методів полягає в тому, що при оцінюванні вартості ПО використовуються певні схеми і принципи, а не математичні формули. Нижче проаналізуємо ці методи.
Price-to-win. Метод грунтується на принципі «клієнт, завжди має рацію». Суть методу полягає в тому, то незалежно від передбачуваних реальних витрат на розробку проекту, оцінка вартості ПО коригується відповідно до побажань замовника. Price-to-win фактично є політикою проведення переговорів з клієнтом, тому оцінювання часто застосовується компаніями, що не мають засобів для якісного оцінювання проектів. Застосування методу може мати для розробника певні негативні наслідки: брак ресурсів для виконання проекту, невиконання термінів здачі проекту і як результат — втрата контракту або банкрутство.
Оцінка за Паркінсоном. Метод грунтується на принципі «Обсяг роботи зростає так, як це потрібно, щоб зайняти час, виділений на її виконання». Принцип, пізніше названий «законом», був уперше висловлений С.Н. Паркінсоном і описував природу взаємодії бюрократичної системи в адміністративних інститутах, відображаючи процес неефективного використання ресурсів. У застосуванні до розробки програмних проектів закон Паркінсона використовується у вигляді такої схеми: щоб підвищити продуктивність праці розробника, слід зменшити час, відведений на розробку.
Експертна оцінка. Метод грунтується на принципі експертної оцінки і застосовується в таких проектах, що використовують нові технології, нові процеси або вирішальні інноваційні завдання. До процесу оцінювання залучаються інженери-розробники, які самі оцінюють частину проекту, що займається ними. Після цього скликаються збори, на яких результати окремих оцінок інтегруються в єдину, цілісну систему. Припущення, на яких грунтувалася оцінка окремих експертів, заносяться в протокол і відкрито обговорюються. При опитуванні експертів використовуються Дельфійськая методика або розширена методика, орієнтована на приведення експерті» до консенсусу. У результаті досягається баланс оцінки при інтеграції окремих компонентів у загальну систему. Далі йде чергова стадія компонентного оцінювання, і у межах збільшення кількості ітерацій точність оцінки збільшується.
Оцінка за аналогїєю - будучи різновидом експертної оцінки, часто виділяється в окремий метод. Метод ґрунтується на принципі аналогії, Оцінка аналогічно алгоритмічним моделям використовує емпіричні дані про характеристики завершених проектів. Головна відмінність полягає в тому, що алгоритмічні моделі використовують ці дані непрямим чином, наприклад, для калібрування параметрів моделей, а метод оцінювання ПО за аналогією за допомогою емпіричних даних дає змогу відібрати схожі проекти. Схема оцінки, заснована на вказаному принципі, складається з декількох етапів. На першому етапі здійснюється збір даних за проектом, що розробляється, У рамках життєвою циклу ПО оптимальними формами для цього с аналіз вимог і проектування. На основі експертної оцінки проводиться відбір характеристик ПО за якими порівнюватимуться проекти, Вибір характеристик залежить від типу додатка, середовища розробки і набору відомих параметрів додатка. Наступний етап включає пошук і аналіз проектів «аналогічних» ПО, що розробляються за вибраними характеристиками, Результатом цього етапу є, як правило, декілька проектів, що мають найменші відмінності в числових значеннях характеристик оцінки. Для відбору найбільш близьких проектів, що розробляються, може використовуватися метод вимірювання евклідової відстані в n-мірному просторі. Кожній характеристиці привласнюється значення ваги (множник), що визначає значущість характеристики для проекту, У спрощеному варіанті вага дорівнює одиниці, тобто всі характеристики проекту вважаються рівнозначними ПО за важливістю. Далі проекти і їх відповідні характеристики відображаються в n-мірному просторі, як точки (n дорівнює кількості змінних, для кожної змінної використовується своє вимірювання), після чого обчислюється евклідова відстань між відповідними точками:
де 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). Для цього використовуються такі параметри: тип застосування, що розробляється; максимально можливий час роботи над проектом; бюджет проекту; орієнтовна загальна кількість рядків; індекс продуктивності команди розробників; відсоток повторно використовуваного коду. Формуються таблиці і будуються діаграми, що відображають загальну кількість задіяної робочої сили і її розподіл програмного забезпечення за графіком робіт.
Шаблон робочої книги (workbook) проекту SLIM Estimate підтримує близько 50 різних форматів проведеного оцінювання програмного забезпечення. Створені робочі книги можуть служити шаблонами для оцінювання вартості подальших проектів. За умовчанням, SLIM Estimate оцінює трудовитрати з 50% вірогідністю успішної реалізації проекту. Для зміни цього значення слід, відко-ригувати значення вірогідності за допомогою майстра налаштування вірогідності [12], Результатом оцінки розміру є загальна кількість рядків коду, які може створити команда розробників у певних умовах. Результат оцінки індексу продуктивності є РІ, необхідний для реалізації проекту в заданих умовах. Оцінка непередбачених обставин використовується для генерації плану реалізації із заданою вірогідністю успішного завершення проекту. Ці способи можуть використовуватися як незалежно, так і для уточнення результатів, отриманих у результаті використання майстра швидкої оцінки.
За допомогою функції Edit Historical Projects такі оцінки можуть бути експортовані в SLIM DataManager. Для порівняльного аналізу результатів оцінки можливий імпорт даних з програми SLIM Metrics або іншої робочої книги SLIM Estimate.
Для оцінювання розміру проекту разом зі SLIM Estimate «поставляється» реалізована в Microsoft Excel таблиця, значення з якої можуть бути імпортовані в робочу книгу проекту. У ранніх версіях SLIM Estimate основною одиницею вимірювання був логічний вираз у початковому коді (Logical Source Statement, LSS). Починаючи з версії 5.0, в SLIM Estimate використовуються рядки коду, функціональні і об'єктні точки (безпосередньо, без перетворення в LSS). Найбільш широко використовуваним способом калібрування моделі в SLIM Estimate є використання історичних параметрів налаштування (Historical Tuning Factors). Програмний комплекс SLIM Estimate може експортувати дані звітів у найбільш популярні формати файлів, такі як: Microsoft Word, Microsoft Excel, Enhanced Metafile, Microsoft Project, HTML.
У комплект постачання SLIM Estimate входить база реалізовaних проектів, котрі можна використовувати для калібрування використовуваної моделі - установки значень параметрів вартості для опису характеристик проекту. Найпоширенішим способом калібрування моделі в SLIM Estimate с використання історичних параметрів налаштування (Historical Tuning Factors), У разі його використання значення параметрів вартості для проекту обчислюються програмним комплексом на основі обраних проектів з бази реалізованих проектів.
Модель Путнема надзвичайно чутлива до значення технологічних чинників, тому точне визначення їх значення є дуже важливим для правильного оцінювання на основі SLIM. Перевагою моделі Путнема перед COCOMO 1.1 або COCOMO 2.0 є невелика кількість параметрів, необхідних для оцінки.
Засоби оцінювання вартості розробки ПЗ, засновані на моделі SLIM, не потребують обов'язкового використання історичної бази проектів. Тому вони можуть застосовуватися безпосередньо організацією, що виконує проектування програмного забезпечення. Використовуючи історичну базу даних, потрібна участь фахівця для порівняння реалізованих і описаних проектів з бази з проектом, що знаходиться в розробці. Залучення сторонньої організації при виконанні оцінювання вартості також може бути необхідне внаслідок наявності у неї достатньо великої історичної і деталізованої бази реалізованих проектів.
Costar (SoftStar Systems), Cost Xpert (Marotz), SoftwareCost Calculator (SofiwareCost.com) — засоби, засновані на моделі COCOMO. Допускається використання всіх реалізацій моделі COCOMO, моделей життєвого циклу програмного забезпечення Waterfall і MBASE/RUP, підтримується робота з проектом, складеним з компонентів, для кожного з яких можна виконати роздільне оцінювання.
Costar, дає змогу проводити оцінювання в двох режимах: покроковому (за допомогою майстра оцінювання вартості); інтерактивному (що забезпечує безпосередню вказівку значень параметрів, які впливають на вартість проекту). Для визначення розміру оцінюваного проекту використовуються функціональні точки або рядки коду. Для перекладу значень, указаних у рядках коду, в програмі є конвертатор, що розраховує значення розміру коду у функціональних точок, виходячи з мови програмування, яка використовується для реалізації проекту. Costar підтримує обмеження проекту, заснованого на граничних фінансових витратах і крайньому терміні реалізації проекту.
Для оцінювання витрат, пов'язаних з оплатою праці працівників, існує, два альтернативні підходи: розрахунок витрат для кожного з етапів життєвого циклу програмного забезпечення; розрахунок місячної плати за працю для кожної категорії співробітників.
Для аналізу результатів оцінки Costar створює різні форми звітів, графіків і діаграм. Звіти, представлені у формі таблиць, можуть бути збережені у форматі Microsoft Excel, графіки і діаграми - у форматі растрового зображення BMP.
Для проведення точного оцінювання вартості розробки ПЗ модель СОСОМО потребує детального і різнобічного опису проекту. Цс може утруднити застосування заснованих на її основі засобів на ранньому етапі розробки програмного забезпечення і сприяє збільшенню точності оцінювання на пізніх етапах розробки програмного забезпечення, аналізуючи завершений проект.
Під час використання засобів на основі моделі COCOMO або COCOMO IT чинниками, що впливають на точність оцінювання вартості, є такі: правильний вибір конкретної реалізації моделі COCOMO; точність калібрування - відповідність установок початковим даним. У зв'язку з цим, для застосування засобів використовують персонал, який не мас прямого відношення до процесів проектування і розробки програмного забезпечення. Він формує специфікації проекту і параметри, необхідні для оцінки, які надаються співробітникам, які виконують оцінювання.
Ефективне застосування алгоритмічних моделей оцінювання вартості програмного забезпечення і заснованих на їх основі засобів оцінки віддають перевагу їх сумісному використанню з неалгоритмічними методами оцінювання. Так, алгоритмічні засоби оцінки можуть бути застосовані членами експертних комісій для аналізу проекту і формування власного оцінювання. Завдяки широким можливостям експорту даних і візуалізації, використання автоматизованих засобів оцінки вартості програмного забезпечення дає можливість формувати власні бази характеристик реалізованих проектів, а також створювати звіти, що ілюструють процес розробки проекту, що значно знижує трудовитрати, пов'язані з підготовкою звітності.
Параметри вартості, Параметр вартості (cost driver) - це суб'єктивна величина, яка оцінює різні тимчасові, якісні і ресурсні аспекти розробки програмного забезпечення. Кожен з параметрів може бути відкалібрований. Калібрування параметрів вартості - це коректування значень параметрів, що впливає на значення трудовитрат, а отже, на якийсь час і на вартість, оцінюючи програмний проект. При калібруванні за вказаними нижче сімнадцятьма параметрами вибирається оцінний рівень (дуже високий, високий, вище номінального, номінальний, нижче номінального, низький, дуже низький) параметра. У формулах цей рівень відбивається у вигляді коефіцієнта трудовитрат і, таким чином, на кожній стадії розробки проекту впливає на вартість і тривалість тієї або іншої стадії. Виділяють такі групи параметрів (табл.7.1): продукту (product factors), платформи (platform factors), персоналу (personnel factors) і проекту (project Jactors). У табл. 7.2 подано короткий опис кожного параметра.
Таблиця 7.1
| Продукт | Враховують характеристики того, що розробляється ПЗ (RELY. DATA, CPLX, RUSE, DOCU) |
| Платформа | Враховують характеристики програмно-апаратного комплексу, потрібного для функціонування ПЗ (TIME, STOR, PVOL) |
| Персонал | Враховують рівень знань і злагодженості роботи колективу програмістів (АСАР, РСАР, PCON, APEX, PLEX. LTEX) |
| Проект | Враховують вплив сучасних підходів і технологій, територіальну віддаленість членів колективу розробників і терміни виконання проекту (TOOL, SITE, SCED) |
Таблиця 7.2
| Параметр | Опис |
| RELY (Required Software Reliability) | Враховує ступінь виконання програмою певної дії протягом певного часу |
| DATA (Database Size) | Враховує вплив обсягу тестових даних на розробку продукту. Рівень цього параметра розраховується як співвідношення байт у тестованій базі даних доSLОСу програмі |
| 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) | Враховує термін «життя» платформи (комплекс апаратного і ПЗ, який потрібний для функціонування того, що розробляється ПЗ) |
| АСАР (Analyst Capability) | Враховує аналіз, здатність проектувати, ефективність і комунікативні здібності групи фахівців, які розробляють вимоги і специфікації проекту. Параметр неповинен оцінювати рівень кваліфікації окремо взятого фахівця |
| РСАР (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) | Враховує вплив тимчасових: обмежень, що накладаються на проект і на значення трудовитрат |