Аналіз функціональних точок

Аналіз функціональних точок — стандартний метод вимірювання розміру програмного продукту з точки зору користувачів системи. Метод розроблений Аланом Альбрехтом (Alan Albrecht) в середині 70-х. Метод був вперше опублікований в 1979 році. У 1986 році була сформована Міжнародна Асоціація користувачів Функціональних Точок (International Association of Users of functional points  — IAUFP), яка опублікувала кілька ревізій методу.

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

Стандарти

З 2012 року існує п'ять визнаних стандартів ISO для оцінки розміру ПЗ методом функціональних точок:

  • COSMIC-FFP: ISO / IEC 19761:2011 Розробка програмного забезпечення. Функціональний метод вимірювання розміру.
  • FISMA FSM: ISO / IEC 29881:2008 Інформаційні технології — програмне забезпечення та інженерні системи — FISMA 1,1 функціональний метод вимірювання розмірів.
  • IFPUG FSM Метод: ISO / IEC 20926:2009 програмне забезпечення та інженерні системи — програмне забезпечення вимірювання — IFPUG функціональний метод вимірювання розмірів
  • Ml II Function Point Analysis: ISO / IEC 20968:2002 Розробка програмного забезпечення — Ml II Function Point Analysis — підрахунок на практиці(мануал).
  • Nesma FPA Метод: ISO / IEC 24570:2005 Розробка програмного забезпечення — Nesma функції розміру. Метод вимірювання версії 2.1 — визначення і підрахунку керівних принципів для застосування функціонального аналізу.

Опис методу функціональних точок

Послідовність кроків аналізу за допомогою функціональних точок

При аналізі методом функціональних точок треба виконати наступну послідовність кроків:

  • Визначення типу оцінки.
  • Визначення області оцінки та кордонів продукту.
  • Підрахунок функціональних точок, пов'язаних з даними.
  • Підрахунок функціональних точок, пов'язаних з транзакціями.
  • Визначення сумарної кількості не вирівняних функціональних точок (UFP).
  • Визначення значення фактору вирівнювання (FAV).
  • Розрахунок кількості вирівняних функціональних точок (AFP).

Визначення типу оцінки

Перше, що необхідно зробити, це визначити тип виконуваної оцінки. Метод передбачає оцінки трьох типів:

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

Визначення області оцінки та межі продукту

Другий крок — це визначення області оцінки та меж продукту. В залежності від типу область оцінки може включати:

  • Всі функції, які розробляються (для проекту розробки)
  • Всі функції, які можна додавати, змінювати і видаляти (для проектів підтримки)
  • Тільки функції, які реально використовуються, або всі функції (при оцінці продукту та / або продуктів).

Третій крок. Межі продукту визначають:

  • Що є «зовнішнім» по відношенню до оцінюваного продукту.
  • Де розташовується «межа системи», через яку проходять транзакції, передаються чи приймаються продуктом, з точки зору користувача.
  • Які дані підтримуються додатками, а які дані — зовнішні.
Межі продукту

До логічних даних системи відносяться:

  • Внутрішні логічні файли (ILFs) — виділяються користувачем логічно пов'язані групи даних або блоки керуючої інформації, які підтримуються всередині продукту.
  • Зовнішні інтерфейсні файли (EIFs) — виділяються користувачем логічно пов'язані групи даних або блоки керуючої інформації, на які посилається продукт, але які підтримуються поза продукту.

Прикладом логічних даних (інформаційних об'єктів) можуть бути: клієнт, рахунок, тарифний план, послуга.

Підрахунок функціональних точок, пов'язаних з даними

Третій крок — підрахунок функціональних точок, пов'язаних з даними. Спочатку визначається складність даних за наступними показниками:

  • DET (data element type) — неповторюваних унікальне поле даних, наприклад, Ім'я Клієнта — 1 DET; Адреса Клієнта (індекс, країна, область, район, місто, вулиця, будинок, корпус, квартира) — 9 DET's
  • RET (record element type) — логічна група даних, наприклад, адресу, паспорт, телефонний номер.

Оцінка кількості не вирівняних функціональних точок, залежить від складності даних, яка визначається на підставі матриці складності (Таблиця 1).

Таблиця 1
1-19 DET 20-50 DET 50+ DET
1 RET Low Low Average
2-5 RET Low Average High
6+ RET Average High High

Оцінка даних в не вирівняних функціональних точках (UFP) підраховується по-різному для внутрішніх логічних файлів (ILFs) і для зовнішніх інтерфейсних файлів (EIFs) (Таблиця 2) залежно від їх складності.

Таблиця 2
складність даних кількість UFP (ILF) кількість UFP (EIF)
Low 7 5
Average 10 7
High 15 10

Підрахунок функціональних точок, пов'язаних з транзакціями

Підрахунок функціональних точок, пов'язаних з транзакціями — це четвертий крок аналізу за методом функціональних точок.

Транзакція — це елементарний неподільний замкнутий процес, що представляє значення для користувача і переводить продукт з одного консистентного стану в інший.

У методі розрізняють такі типи транзакцій (Таблиця 3):

  • EI (external inputs) — зовнішні вхідні транзакції, елементарна операція з обробки даних або керуючої інформації, що надходять у систему з поза.
  • EO (external outputs) — зовнішні вихідні транзакції, елементарна операція по генерації даних або керуючої інформації, які виходять за межі системи. Припускає певну логіку обробки або обчислень інформації з одного або більше ILF.
  • EQ (external inquiries) — зовнішні запити, елементарна операція, яка у відповідь на зовнішній запит витягує дані або керуючу інформацію з ILF або EIF.

Таблиця 3. Основні відмінності між типами транзакцій. Легенда: О — основна; Д — додаткова; NA — не застосовна.

Типи транзакцій

Оцінка складності транзакції ґрунтується на наступних її характеристиках:

  • FTR (file type referenced) — дозволяє підрахувати кількість різних файлів (інформаційних об'єктів) типу ILF і / або EIF модифікуються або зчитуються в транзакції.
  • DET (data element type) — неповторюваних унікальне поле даних. Приклади. EI: поле введення, кнопка. EO: поле даних звіту, повідомлення про помилку. EQ: поле введення для пошуку, поле виведення результату пошуку.

Для оцінки складності транзакцій служать матриці, які представлені в Таблиці 4 та Таблиці 5.

Таблиця 4. Матриця складності зовнішніх вхідних транзакцій (EI)
EI 1-4 DET 5-15 DET 16+ DET
0-1 FTR Low Low Average
2 FTR Low Average High
3+ FTR Average High High

Таблиця 5. Матриця складності зовнішніх вихідних транзакцій і зовнішніх запитів (EO & EQ)

Таблиця 5. Матриця складності зовнішніх вихідних транзакцій і зовнішніх запитів (EO & EQ)
EO & EQ 1-5 DET 6-19 DET 20+ DET
0-1 FTR Low Low Average
2-3 FTR Low Average High
4+ FTR Average High High

Оцінка транзакцій в не вирівняних функціональних точках (UFP) може бути отримана з матриці (Таблиця 6)

Таблиця 6. Складність транзакцій в не вирівняних функціональних точках (UFP)
Складність транзакцій кількість UFP (EI & EQ) кількість UFP (EO)
Low 3 4
Average 4 5
High 6 7

Як приклад, розглянемо оцінку керуючої транзакції (EI) для діалогового вікна, що задає параметри перевірки орфографії в MS Office Outlook (Рисунок 3).

Оцінка керуючої транзакції (EI) для діалогового вікна

Рисунок 3. Діалогове вікно, що управляє перевіркою орфографії в MS Office Outlook

Кожен «Check box» оцінюється, як 1 DET. Випадаючий список — 1 DET. Кожна керуюча кнопка повинна розглядатися як окрема транзакція. Наприклад, якщо оцінювати керуючу транзакцію по кнопці «OK», то, для даної транзакції ми маємо 1 FTR і 8 DET. Тому, згідно з матрицею (Таблиця 4), ми можемо оцінити складність транзакції, як Low. І, нарешті, у відповідність з матрицею (Таблиця 6), дана транзакція повинна бути оцінена в 3 не вирівняних функціональних точок (UFP).

Визначення сумарного кількості не вирівняних функціональних точок (UFP)

Загальний обсяг продукту в не вирівняних функціональних точках (UFP) визначається шляхом підсумовування по всіх інформаційних об'єктів (ILF, EIF) і елементарних операцій (транзакцій EI, EO, EQ).[1]

Визначення значення фактору вирівнювання (FAV)

Крім функціональних вимог на продукт накладаються загальносистемні вимоги, що обмежують розробників у виборі рішення і збільшують складність розробки. Для обліку цієї складності застосовується фактор вирівнювання (VAF). Значення фактору VAF залежить від 14 параметрів, які визначають системні характеристики продукту:

  1. Обмін даними (0 — продукт являє собою автономне додаток; 5 — продукт обмінюється даними по більш, ніж одному телекомунікаційному протоколу).
  2. Розподілена обробка даних (0 — продукт не переміщує дані; 5 — розподілена обробка даних виконується декількома компонентами системи).
  3. Продуктивність (0 — користувальницькі вимоги по продуктивності не встановлені; 5 — час відгуку сильно обмежена критично для всіх бізнес-операцій, для задоволення вимогам необхідні спеціальні проектні рішення та інструменти аналізу.
  4. Обмеження по апаратних ресурсів (0 — немає обмежень; 5 — продукт цілком повинен функціонувати на певному процесорі і не може бути розподілений).
  5. Транзакційне навантаження (0 — транзакцій не багато, без піків; 5 — число транзакцій велике і нерівномірно, потрібні спеціальні рішення та інструменти).
  6. Інтенсивність взаємодії з користувачем (0 — всі транзакції обробляються в пакетному режимі; 5 — понад 30% транзакцій — інтерактивні).
  7. Ергономіка (ефективність роботи кінцевих користувачів) (0 — немає спеціальних вимог; 5 — вимоги щодо ефективності дуже жорсткі).
  8. Інтенсивність зміни даних (ILF) користувачами (0 — не вимагаються; 5 — зміни інтенсивні, жорсткі вимоги по відновленню).
  9. Складність обробки (0 — обробка мінімальна; 5 — вимоги безпеки, логічна і математична складність, багатопоточність).
  10. Повторне використання (0 — не вимагається; 5 — продукт розробляється як стандартний багаторазовий компонент).
  11. Зручність інсталяції (0 — немає вимог; 5 — установка і оновлення ПЗ проводиться автоматично).
  12. Зручність адміністрування (0 — не вимагається; 5 — система автоматично самовідновлюється).
  13. Портуємість (0 — продукт має тільки 1 інсталяцію на єдиному процесорі; 5 — система є розподіленою і припускає установку на різні «залізо» і ОС).
  14. Гнучкість (0 — не вимагається; 5 — гнучка система запитів і побудова довільних звітів, модель даних змінюється користувачем в інтерактивному режимі).

Ці 14 системних параметрів (degree of influence, DI) оцінюються за шкалою від 0 до 5. Розрахунок сумарного ефекту 14 системних характеристик (total degree of influence, TDI) здійснюється простим підсумовуванням:

Розрахунок значення фактору вирівнювання здійснюється за формулою

Розрахунок кількості вирівняних функціональних точок (AFP)

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

Вона враховує тільки нову функціональність, яка реалізується в продукті. Проект розробки продукту оцінюється в DFP (development functional point) за формулою:

де CFP (conversion functional point) — функціональні точки, підраховані для додаткової функціональності, яка буде потрібно при установці продукту, наприклад, міграції даних.

Проект доопрацювання і вдосконалення продукту оцінюється в EFP (enhancement functional point) за формулою:

де

  • ADD — функціональні точки для доданої функціональності;
  • CHGA — функціональні точки для змінених функцій, розраховані після модифікації;
  • VAFA — величина фактору вирівнювання розрахованого після завершення проекту;
  • DEL — обсяг вилученої функціональності;
  • VAFB — величина фактору вирівнювання розрахованого до початку проекту.

Сумарний вплив процедури вирівнювання лежить в межах ± 35% відносно обсягу розрахованого в UFP.

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

Примітки

  1. Garmus, David; Russac, Janet; Edwards, Royce (3 червня 2011). Certified Function Point Specialist Examination Guide (англ.). CRC Press. ISBN 9781439856987.

Посилання

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.