Вступ до інженерії програмного забезпечення - Микола Олександрович Сидоров

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

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 році Путнемом була представлена альтернативна реалі­зація моделі, виконана