Шрифт:
Интервал:
Закладка:
Методика аналізу FP грунтується на концепції розмежування взаємодії. Суть її полягає в тому, що програма розділяється на класи компонентів ПЗ формату і типу логічних операцій. В основі цього поділу лежить припущення, що область взаємодії програми розділяється на внутрішню - взаємодія компонентів додатка, і зовнішню - взаємодія з іншими застосуваннями.
Відповідно до прийнятого стандарту використовуються п'ять класів компонентів, на яких грунтується аналіз:
- внутрішній логічний файл (Internal Logical File - ILF) — група логічно пов'язаних даних, меж додатка, що знаходяться всередині, і підтримуваних введенням ззовні;
- зовнішній інтерфейсний файл (External Interface File - EIF) -група логічно пов'язаних даних, меж додатка, що знаходяться ззовні, і що є внутрішнім логічним файлом для іншого застосування;
- зовнішнє введення (External Input - EI) - транзакція, в разі виконання якої дані перетинають межу додатка ззовні. Це можуть бути як дані, що отримуються від іншого застосування, так і дані, що вводяться в програму користувачем. Отримувані дані можуть бути командами управління або статичними даними. В останньому випадку може виникнути необхідність відновити внутрішній логічний файл;
- зовнішній вивід (External Output - ЕО) - транзакція, при виконанні якої дані перетинають межу додатка зсередини. З ILF і EIF створюються файли виведення або повідомлення і відправляються іншому застосуванню. Виведення також містить похідні дані, що отримуються з ILF;
- зовнішній запит (External Inquiry -EQ) - транзакція, в разі виконання якої відбувається одночасне введення і виведення. У результаті інформація вертається з одного або більше ILF і EIF, Виведення не містить похідних даних, a ILF не оновлюється.
Класи компонентів оцінюються ПО за складністю і належать до категорії високого, середнього або низького рівня складності. Для транзакцій (ЕІ, ЕО, EQ) рівень визначається ПО за кількістю файлів, на які посилається транзакція (File Types Referenced — FTR) і кількості типів елементів даних (Data Element Types - DET). Для ILF і EIF мають значення типи елементів записів (Record Element Types - RET) і DET. Типи елементів записів - цс підгрупа елементів даних у ILF або EIF. Типи елементів даних - це унікальне, не рекурсивне поле підмножини ILF або EIF. Рівні складності і відповідні ним значення FTR і DET описані в FPCPM.
Наприклад, для ЕI з кількістю FTR від трьох і більше, і DЕТ(від 5 до 15) рівень складності визначається як високий. Далі компоненти розподіляються ПЗ за «ваговими категоріями» залежно від рівня їх складності. Наприклад, ILF середньої складності має значення 10, a EQ високої складності - значення 6. Після цього, робиться розрахунок нескоригованих функціональних точок (Unadjusted Function Point - UFP) ПЗ у відповідній формулі [1]:
,
де Nij- i Wij - кількість екземплярів класу і складності j і ного вагоме значення відповідно. Результат розрахунку може бути скоригований за допомогою чинника регулювання вартості (Value Adjustment Factor - VAF). Під час розрахунку VAF враховуються чотирнадцять загальних характеристик системи (General System Characteristic -GSC), які оцінюють загальну функціональність застосування, що розробляється. Ці характеристики відображають можливість повторного використання коду, продуктивність, можливість розподіленої обробки та інші властивості додатка. Кожній GSC привласнюється значення від 0 до 5. Після того, як враховані всі чотирнадцяті, загальних характеристик системи, розраховується чинник регулювання вартості ПО за формулою [4]
,
де Cj-ступінь виливу i-ї GSC. Останньою розраховується кількість повних функціональних точок: FP-UAF* VAF,
Існують додатки, під час оцінювання яких використання стандартних функціональних точок не ефективне. Ці застосування такі: управління процесом у реальному часі, математичні обчислення, симуляція, системні застосування, інженерні застосування, вбудовані системи. Перераховані застосування відрізняються високою інтенсивністю обчислень, часто заснованих на алгоритмах підвищеної складності. Для вирішення завдань розрахунку розміру вказаних застосувань у 1986 році організацією Software Productivity Research (SPR) була розроблена методика аналізу характерних точок ПЗ (feature points). Суть її полягає в тому, що оцінюється кількість алгоритмів у програмі і частково модифікується ступінь значущості (weighting values) для розрахунку FP. Ця методика вважається експериментальною.
7.2. Методи і моделі оцінювання вартості програмного забезпечення
Методи і моделі оцінювання вартості ПЗ можна розділити на дві групи: неалгоритмічні методи і алгоритмічні моделі. До неалгорит-мінних методів належать Price-to-win, оцінка ПЗ Паркінсона, експертна оцінка, оцінка за аналогією. До алгоритмічних моделей, належать SLIM і COCOMO.
Суть неалгоритмічних методів полягає в тому, що при оцінюванні вартості ПО використовуються певні схеми і принципи, а не математичні формули. Нижче проаналізуємо ці методи.
Price-to-win. Метод грунтується на принципі «клієнт, завжди має рацію». Суть методу полягає в тому, то незалежно від передбачуваних реальних витрат на розробку проекту, оцінка вартості ПО коригується відповідно до побажань замовника. Price-to-win фактично є політикою проведення переговорів з клієнтом, тому оцінювання часто застосовується компаніями, що не мають засобів для якісного оцінювання проектів. Застосування методу може мати для розробника певні негативні наслідки: брак ресурсів для виконання проекту, невиконання термінів здачі проекту і як результат — втрата контракту або банкрутство.
Оцінка за Паркінсоном. Метод грунтується на принципі «Обсяг роботи зростає так, як це потрібно, щоб зайняти час, виділений на її виконання». Принцип, пізніше названий «законом», був уперше висловлений С.Н. Паркінсоном і описував природу взаємодії бюрократичної системи в адміністративних інститутах, відображаючи процес неефективного використання ресурсів. У застосуванні до розробки програмних проектів закон Паркінсона використовується у вигляді такої схеми: щоб підвищити продуктивність праці розробника, слід зменшити час, відведений на розробку.
Експертна оцінка. Метод грунтується на принципі експертної оцінки і застосовується в таких проектах, що використовують нові технології, нові процеси або вирішальні інноваційні завдання. До процесу оцінювання залучаються інженери-розробники, які самі оцінюють частину проекту, що займається ними. Після цього скликаються збори, на яких результати окремих оцінок інтегруються в єдину, цілісну систему. Припущення, на яких грунтувалася оцінка окремих експертів, заносяться в протокол і відкрито обговорюються. При опитуванні експертів використовуються Дельфійськая методика або розширена методика, орієнтована на приведення експерті» до консенсусу. У результаті досягається баланс оцінки при інтеграції окремих компонентів у загальну систему. Далі йде чергова стадія компонентного оцінювання, і у межах збільшення кількості ітерацій точність оцінки збільшується.
Оцінка за аналогїєю - будучи різновидом експертної оцінки, часто виділяється в окремий метод. Метод ґрунтується на принципі аналогії, Оцінка аналогічно алгоритмічним моделям використовує емпіричні дані про характеристики завершених проектів. Головна відмінність полягає в тому, що алгоритмічні моделі використовують ці дані непрямим чином, наприклад, для калібрування параметрів моделей, а метод оцінювання ПО за аналогією за допомогою емпіричних даних дає змогу відібрати схожі проекти. Схема оцінки, заснована на вказаному принципі, складається з декількох етапів. На першому етапі здійснюється збір даних за проектом, що розробляється, У рамках життєвою циклу ПО оптимальними формами для цього с аналіз вимог і проектування. На основі експертної оцінки проводиться відбір характеристик ПО за якими порівнюватимуться проекти, Вибір характеристик залежить від типу додатка, середовища розробки і набору відомих параметрів додатка. Наступний етап включає пошук і аналіз проектів «аналогічних» ПО, що розробляються за вибраними характеристиками, Результатом цього етапу є, як правило, декілька проектів, що мають найменші відмінності в числових значеннях характеристик оцінки. Для відбору найбільш близьких проектів, що розробляються, може використовуватися метод вимірювання евклідової відстані в n-мірному просторі. Кожній характеристиці привласнюється значення ваги (множник), що визначає значущість характеристики для проекту, У спрощеному варіанті вага дорівнює одиниці, тобто всі характеристики проекту вважаються рівнозначними ПО за важливістю. Далі проекти і їх відповідні характеристики відображаються в n-мірному просторі, як точки (n дорівнює кількості змінних, для кожної змінної використовується своє вимірювання), після чого обчислюється евклідова відстань між відповідними точками:
- C# для профессионалов. Том II - Симон Робинсон - Программирование
- Microsoft Visual C++ и MFC. Программирование для Windows 95 и Windows NT. Часть 2 - Александр Фролов - Программирование
- Как спроектировать современный сайт - Чои Вин - Программирование
- Каждому проекту своя методология - Алистэр Коуберн - Программирование
- Сделай видеоигру один и не свихнись - Слава Грис - Программирование / Руководства
- Графические интерфейсы пользователя Java - Тимур Сергеевич Машнин - Программирование
- Настольная книга тимлида разработки ПО - Виктор Большаков - Программирование
- Краткое введение в программирование на Bash - Гарольд Родригес - Программирование
- Программирование игр и головоломок - Жак Арсак - Программирование
- C# 4.0: полное руководство - Герберт Шилдт - Программирование