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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

Аналіз функціональних точок — стандартний метод вимірювання розміру програмного продукту з точки зору користувачів системи. Метод розроблений Аланом Альбрехтом (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 — визначення і підрахунку керівних принципів для застосування функціонального аналізу.

Вступ[ред.ред. код]

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

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

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

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

Схемаmistermishka.png

Визначення типу оцінки[ред.ред. код]

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

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

Визначення області оцінки та границі продукту[ред.ред. код]

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

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

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

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

Рисунок2mistermishka.png

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

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

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

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

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

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

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

Tabl1mistermishka.png

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

Tabl2mistermishka.png

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

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

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

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

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

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

Tabl3misterMishka.png

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

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

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

Таблиця 4. Матриця складності зовнішніх вхідних транзакцій (EI)

Tabl4mistermishka.png

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

Tabl5mistermishka.png

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

Таблиця 6. Складність транзакцій в не вирівняних функціональних точках (UFP)

Tabl6mistermishka.png

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

Risunok3mistermishka.png

Рисунок 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).

Визначення значення фактору вирівнювання (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.

Джерела[ред.ред. код]