Аналіз функціональних точок — стандартний метод вимірювання розміру програмного продукту з точки зору користувачів системи. Метод розроблений (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).
Визначення типу оцінки
Перше, що необхідно зробити, це визначити тип виконуваної оцінки. Метод передбачає оцінки трьох типів:
- Проект розробки. Оцінюється кількість функціональності, яка поставляється користувачам в першому релізі продукту.
- Проект розвитку. В функціональних точках оцінюється проект доопрацювання: додавання, зміна та видалення функціоналу.
- Продукт. Оцінюється обсяг вже існуючого та встановленого продукту.
Визначення області оцінки та межі продукту
Другий крок — це визначення області оцінки та меж продукту. В залежності від типу область оцінки може включати:
- Всі функції, які розробляються (для проекту розробки)
- Всі функції, які можна додавати, змінювати і видаляти (для проектів підтримки)
- Тільки функції, які реально використовуються, або всі функції (при оцінці продукту та / або продуктів).
Третій крок. Межі продукту визначають:
- Що є «зовнішнім» по відношенню до оцінюваного продукту.
- Де розташовується «межа системи», через яку проходять транзакції, передаються чи приймаються продуктом, з точки зору користувача.
- Які дані підтримуються додатками, а які дані — зовнішні.
До логічних даних системи відносяться:
- Внутрішні логічні файли (ILFs) — виділяються користувачем логічно пов'язані групи даних або блоки керуючої інформації, які підтримуються всередині продукту.
- Зовнішні інтерфейсні файли (EIFs) — виділяються користувачем логічно пов'язані групи даних або блоки керуючої інформації, на які посилається продукт, але які підтримуються поза продукту.
Прикладом логічних даних (інформаційних об'єктів) можуть бути: клієнт, рахунок, тарифний план, послуга.
Підрахунок функціональних точок, пов'язаних з даними
Третій крок — підрахунок функціональних точок, пов'язаних з даними. Спочатку визначається складність даних за наступними показниками:
- DET (data element type) — неповторюваних унікальне поле даних, наприклад, Ім'я Клієнта — 1 DET; Адреса Клієнта (індекс, країна, область, район, місто, вулиця, будинок, корпус, квартира) — 9 DET's
- RET (record element type) — логічна група даних, наприклад, адресу, паспорт, телефонний номер.
- 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.
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)
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)
Складність транзакцій | кількість UFP (EI & EQ) | кількість UFP (EO) |
---|---|---|
Low | 3 | 4 |
Average | 4 | 5 |
High | 6 | 7 |
Як приклад, розглянемо оцінку керуючої транзакції (EI) для діалогового вікна, що задає параметри перевірки орфографії в MS Office Outlook (Рисунок 3).
Рисунок 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 параметрів, які визначають системні характеристики продукту:
- Обмін даними (0 — продукт являє собою автономне додаток; 5 — продукт обмінюється даними по більш, ніж одному телекомунікаційному протоколу).
- Розподілена обробка даних (0 — продукт не переміщує дані; 5 — розподілена обробка даних виконується декількома компонентами системи).
- Продуктивність (0 — користувальницькі вимоги по продуктивності не встановлені; 5 — час відгуку сильно обмежена критично для всіх бізнес-операцій, для задоволення вимогам необхідні спеціальні проектні рішення та інструменти аналізу.
- Обмеження по апаратних ресурсів (0 — немає обмежень; 5 — продукт цілком повинен функціонувати на певному процесорі і не може бути розподілений).
- Транзакційне навантаження (0 — транзакцій не багато, без піків; 5 — число транзакцій велике і нерівномірно, потрібні спеціальні рішення та інструменти).
- Інтенсивність взаємодії з користувачем (0 — всі транзакції обробляються в пакетному режимі; 5 — понад 30% транзакцій — інтерактивні).
- Ергономіка (ефективність роботи кінцевих користувачів) (0 — немає спеціальних вимог; 5 — вимоги щодо ефективності дуже жорсткі).
- Інтенсивність зміни даних (ILF) користувачами (0 — не вимагаються; 5 — зміни інтенсивні, жорсткі вимоги по відновленню).
- Складність обробки (0 — обробка мінімальна; 5 — вимоги безпеки, логічна і математична складність, багатопоточність).
- Повторне використання (0 — не вимагається; 5 — продукт розробляється як стандартний багаторазовий компонент).
- Зручність інсталяції (0 — немає вимог; 5 — установка і оновлення ПЗ проводиться автоматично).
- Зручність адміністрування (0 — не вимагається; 5 — система автоматично самовідновлюється).
- Портуємість (0 — продукт має тільки 1 інсталяцію на єдиному процесорі; 5 — система є розподіленою і припускає установку на різні «залізо» і ОС).
- Гнучкість (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.
Примітки
- Garmus, David; Russac, Janet; Edwards, Royce (3 червня 2011). Certified Function Point Specialist Examination Guide (англ.). CRC Press. ISBN .
Посилання
Ця стаття містить перелік , але походження окремих тверджень у ній через практично повну відсутність .(грудень 2012) |
- The Netherlands Software Metrics users Association (NESMA) [Архівовано 9 травня 2012 у Wayback Machine.]
- The Common Software Measurement International Consortium [Архівовано 4 березня 2016 у Wayback Machine.]
- Function Point Analysis in FOLDOC [Архівовано 18 жовтня 2012 у Wayback Machine.]
- An introduction (tutorial) to Function Points Analysis [Архівовано 10 грудня 2012 у Wayback Machine.]
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Nemaye perevirenih versij ciyeyi storinki jmovirno yiyi she ne pereviryali na vidpovidnist pravilam proektu Analiz funkcionalnih tochok standartnij metod vimiryuvannya rozmiru programnogo produktu z tochki zoru koristuvachiv sistemi Metod rozroblenij Alanom Albrehtom Alan Albrecht v seredini 70 h Metod buv vpershe opublikovanij v 1979 roci U 1986 roci bula sformovana Mizhnarodna Asociaciya koristuvachiv Funkcionalnih Tochok International Association of Users of functional points IAUFP yaka opublikuvala kilka revizij metodu Metod priznachenij dlya ocinki na osnovi logichnoyi modeli obsyagu programnogo produktu kilkistyu funkcionalu neobhidnogo zamovnikom i postavlyayetsya rozrobnikom Bezsumnivnoyu perevagoyu metodu ye te sho vimiryuvannya ne zalezhat vid tehnologichnoyi platformi na yakij bude rozroblyatisya produkt i vin zabezpechuye odnakovij pidhid do ocinki vsih proektiv v kompaniyi Zmist 1 Standarti 2 Opis metodu funkcionalnih tochok 3 Viznachennya tipu ocinki 4 Viznachennya oblasti ocinki ta mezhi produktu 5 Pidrahunok funkcionalnih tochok pov yazanih z danimi 6 Pidrahunok funkcionalnih tochok pov yazanih z tranzakciyami 7 Viznachennya sumarnogo kilkosti ne virivnyanih funkcionalnih tochok UFP 8 Viznachennya znachennya faktoru virivnyuvannya FAV 9 Rozrahunok kilkosti virivnyanih funkcionalnih tochok AFP 10 Primitki 11 PosilannyaStandartired Z 2012 roku isnuye p yat viznanih standartiv ISO dlya ocinki rozmiru PZ metodom funkcionalnih tochok COSMIC FFP ISO IEC 19761 2011 Rozrobka programnogo zabezpechennya Funkcionalnij metod vimiryuvannya rozmiru FISMA FSM ISO IEC 29881 2008 Informacijni tehnologiyi programne zabezpechennya ta inzhenerni sistemi FISMA 1 1 funkcionalnij metod vimiryuvannya rozmiriv IFPUG FSM Metod ISO IEC 20926 2009 programne zabezpechennya ta inzhenerni sistemi programne zabezpechennya vimiryuvannya IFPUG funkcionalnij metod vimiryuvannya rozmiriv Ml II Function Point Analysis ISO IEC 20968 2002 Rozrobka programnogo zabezpechennya Ml II Function Point Analysis pidrahunok na praktici manual Nesma FPA Metod ISO IEC 24570 2005 Rozrobka programnogo zabezpechennya Nesma funkciyi rozmiru Metod vimiryuvannya versiyi 2 1 viznachennya i pidrahunku kerivnih principiv dlya zastosuvannya funkcionalnogo analizu Opis metodu funkcionalnih tochokred nbsp Poslidovnist krokiv analizu za dopomogoyu funkcionalnih tochok Pri analizi metodom funkcionalnih tochok treba vikonati nastupnu poslidovnist krokiv Viznachennya tipu ocinki Viznachennya oblasti ocinki ta kordoniv produktu Pidrahunok funkcionalnih tochok pov yazanih z danimi Pidrahunok funkcionalnih tochok pov yazanih z tranzakciyami Viznachennya sumarnoyi kilkosti ne virivnyanih funkcionalnih tochok UFP Viznachennya znachennya faktoru virivnyuvannya FAV Rozrahunok kilkosti virivnyanih funkcionalnih tochok AFP Viznachennya tipu ocinkired Pershe sho neobhidno zrobiti ce viznachiti tip vikonuvanoyi ocinki Metod peredbachaye ocinki troh tipiv Proekt rozrobki Ocinyuyetsya kilkist funkcionalnosti yaka postavlyayetsya koristuvacham v pershomu relizi produktu Proekt rozvitku V funkcionalnih tochkah ocinyuyetsya proekt doopracyuvannya dodavannya zmina ta vidalennya funkcionalu Produkt Ocinyuyetsya obsyag vzhe isnuyuchogo ta vstanovlenogo produktu Viznachennya oblasti ocinki ta mezhi produktured Drugij krok ce viznachennya oblasti ocinki ta mezh produktu V zalezhnosti vid tipu oblast ocinki mozhe vklyuchati Vsi funkciyi yaki rozroblyayutsya dlya proektu rozrobki Vsi funkciyi yaki mozhna dodavati zminyuvati i vidalyati dlya proektiv pidtrimki Tilki funkciyi yaki realno vikoristovuyutsya abo vsi funkciyi pri ocinci produktu ta abo produktiv Tretij krok Mezhi produktu viznachayut Sho ye zovnishnim po vidnoshennyu do ocinyuvanogo produktu De roztashovuyetsya mezha sistemi cherez yaku prohodyat tranzakciyi peredayutsya chi prijmayutsya produktom z tochki zoru koristuvacha Yaki dani pidtrimuyutsya dodatkami a yaki dani zovnishni nbsp Mezhi produktu Do logichnih danih sistemi vidnosyatsya Vnutrishni logichni fajli ILFs vidilyayutsya koristuvachem logichno pov yazani grupi danih abo bloki keruyuchoyi informaciyi yaki pidtrimuyutsya vseredini produktu Zovnishni interfejsni fajli EIFs vidilyayutsya koristuvachem logichno pov yazani grupi danih abo bloki keruyuchoyi informaciyi na yaki posilayetsya produkt ale yaki pidtrimuyutsya poza produktu Prikladom logichnih danih informacijnih ob yektiv mozhut buti kliyent rahunok tarifnij plan posluga Pidrahunok funkcionalnih tochok pov yazanih z danimired Tretij krok pidrahunok funkcionalnih tochok pov yazanih z danimi Spochatku viznachayetsya skladnist danih za nastupnimi pokaznikami DET data element type nepovtoryuvanih unikalne pole danih napriklad Im ya Kliyenta 1 DET Adresa Kliyenta indeks krayina oblast rajon misto vulicya budinok korpus kvartira 9 DET s RET record element type logichna grupa danih napriklad adresu pasport telefonnij nomer Ocinka kilkosti ne virivnyanih funkcionalnih tochok zalezhit vid skladnosti danih yaka viznachayetsya na pidstavi matrici skladnosti Tablicya 1 Tablicya 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 Ocinka danih v ne virivnyanih funkcionalnih tochkah UFP pidrahovuyetsya po riznomu dlya vnutrishnih logichnih fajliv ILFs i dlya zovnishnih interfejsnih fajliv EIFs Tablicya 2 zalezhno vid yih skladnosti Tablicya 2 skladnist danih kilkist UFP ILF kilkist UFP EIF Low 7 5 Average 10 7 High 15 10Pidrahunok funkcionalnih tochok pov yazanih z tranzakciyamired Pidrahunok funkcionalnih tochok pov yazanih z tranzakciyami ce chetvertij krok analizu za metodom funkcionalnih tochok Tranzakciya ce elementarnij nepodilnij zamknutij proces sho predstavlyaye znachennya dlya koristuvacha i perevodit produkt z odnogo konsistentnogo stanu v inshij U metodi rozriznyayut taki tipi tranzakcij Tablicya 3 EI external inputs zovnishni vhidni tranzakciyi elementarna operaciya z obrobki danih abo keruyuchoyi informaciyi sho nadhodyat u sistemu z poza EO external outputs zovnishni vihidni tranzakciyi elementarna operaciya po generaciyi danih abo keruyuchoyi informaciyi yaki vihodyat za mezhi sistemi Pripuskaye pevnu logiku obrobki abo obchislen informaciyi z odnogo abo bilshe ILF EQ external inquiries zovnishni zapiti elementarna operaciya yaka u vidpovid na zovnishnij zapit vityaguye dani abo keruyuchu informaciyu z ILF abo EIF Tablicya 3 Osnovni vidminnosti mizh tipami tranzakcij Legenda O osnovna D dodatkova NA ne zastosovna nbsp Tipi tranzakcij Ocinka skladnosti tranzakciyi gruntuyetsya na nastupnih yiyi harakteristikah FTR file type referenced dozvolyaye pidrahuvati kilkist riznih fajliv informacijnih ob yektiv tipu ILF i abo EIF modifikuyutsya abo zchituyutsya v tranzakciyi DET data element type nepovtoryuvanih unikalne pole danih Prikladi EI pole vvedennya knopka EO pole danih zvitu povidomlennya pro pomilku EQ pole vvedennya dlya poshuku pole vivedennya rezultatu poshuku Dlya ocinki skladnosti tranzakcij sluzhat matrici yaki predstavleni v Tablici 4 ta Tablici 5 Tablicya 4 Matricya skladnosti zovnishnih vhidnih tranzakcij 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 Tablicya 5 Matricya skladnosti zovnishnih vihidnih tranzakcij i zovnishnih zapitiv EO amp EQ Tablicya 5 Matricya skladnosti zovnishnih vihidnih tranzakcij i zovnishnih zapitiv EO amp EQ EO amp 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 Ocinka tranzakcij v ne virivnyanih funkcionalnih tochkah UFP mozhe buti otrimana z matrici Tablicya 6 Tablicya 6 Skladnist tranzakcij v ne virivnyanih funkcionalnih tochkah UFP Skladnist tranzakcij kilkist UFP EI amp EQ kilkist UFP EO Low 3 4 Average 4 5 High 6 7 Yak priklad rozglyanemo ocinku keruyuchoyi tranzakciyi EI dlya dialogovogo vikna sho zadaye parametri perevirki orfografiyi v MS Office Outlook Risunok 3 nbsp Ocinka keruyuchoyi tranzakciyi EI dlya dialogovogo vikna Risunok 3 Dialogove vikno sho upravlyaye perevirkoyu orfografiyi v MS Office Outlook Kozhen Check box ocinyuyetsya yak 1 DET Vipadayuchij spisok 1 DET Kozhna keruyucha knopka povinna rozglyadatisya yak okrema tranzakciya Napriklad yaksho ocinyuvati keruyuchu tranzakciyu po knopci OK to dlya danoyi tranzakciyi mi mayemo 1 FTR i 8 DET Tomu zgidno z matriceyu Tablicya 4 mi mozhemo ociniti skladnist tranzakciyi yak Low I nareshti u vidpovidnist z matriceyu Tablicya 6 dana tranzakciya povinna buti ocinena v 3 ne virivnyanih funkcionalnih tochok UFP Viznachennya sumarnogo kilkosti ne virivnyanih funkcionalnih tochok UFP red Zagalnij obsyag produktu v ne virivnyanih funkcionalnih tochkah UFP viznachayetsya shlyahom pidsumovuvannya po vsih informacijnih ob yektiv ILF EIF i elementarnih operacij tranzakcij EI EO EQ 1 Viznachennya znachennya faktoru virivnyuvannya FAV red Krim funkcionalnih vimog na produkt nakladayutsya zagalnosistemni vimogi sho obmezhuyut rozrobnikiv u vibori rishennya i zbilshuyut skladnist rozrobki Dlya obliku ciyeyi skladnosti zastosovuyetsya faktor virivnyuvannya VAF Znachennya faktoru VAF zalezhit vid 14 parametriv yaki viznachayut sistemni harakteristiki produktu Obmin danimi 0 produkt yavlyaye soboyu avtonomne dodatok 5 produkt obminyuyetsya danimi po bilsh nizh odnomu telekomunikacijnomu protokolu Rozpodilena obrobka danih 0 produkt ne peremishuye dani 5 rozpodilena obrobka danih vikonuyetsya dekilkoma komponentami sistemi Produktivnist 0 koristuvalnicki vimogi po produktivnosti ne vstanovleni 5 chas vidguku silno obmezhena kritichno dlya vsih biznes operacij dlya zadovolennya vimogam neobhidni specialni proektni rishennya ta instrumenti analizu Obmezhennya po aparatnih resursiv 0 nemaye obmezhen 5 produkt cilkom povinen funkcionuvati na pevnomu procesori i ne mozhe buti rozpodilenij Tranzakcijne navantazhennya 0 tranzakcij ne bagato bez pikiv 5 chislo tranzakcij velike i nerivnomirno potribni specialni rishennya ta instrumenti Intensivnist vzayemodiyi z koristuvachem 0 vsi tranzakciyi obroblyayutsya v paketnomu rezhimi 5 ponad 30 tranzakcij interaktivni Ergonomika efektivnist roboti kincevih koristuvachiv 0 nemaye specialnih vimog 5 vimogi shodo efektivnosti duzhe zhorstki Intensivnist zmini danih ILF koristuvachami 0 ne vimagayutsya 5 zmini intensivni zhorstki vimogi po vidnovlennyu Skladnist obrobki 0 obrobka minimalna 5 vimogi bezpeki logichna i matematichna skladnist bagatopotochnist Povtorne vikoristannya 0 ne vimagayetsya 5 produkt rozroblyayetsya yak standartnij bagatorazovij komponent Zruchnist instalyaciyi 0 nemaye vimog 5 ustanovka i onovlennya PZ provoditsya avtomatichno Zruchnist administruvannya 0 ne vimagayetsya 5 sistema avtomatichno samovidnovlyuyetsya Portuyemist 0 produkt maye tilki 1 instalyaciyu na yedinomu procesori 5 sistema ye rozpodilenoyu i pripuskaye ustanovku na rizni zalizo i OS Gnuchkist 0 ne vimagayetsya 5 gnuchka sistema zapitiv i pobudova dovilnih zvitiv model danih zminyuyetsya koristuvachem v interaktivnomu rezhimi Ci 14 sistemnih parametriv degree of influence DI ocinyuyutsya za shkaloyu vid 0 do 5 Rozrahunok sumarnogo efektu 14 sistemnih harakteristik total degree of influence TDI zdijsnyuyetsya prostim pidsumovuvannyam Rozrahunok znachennya faktoru virivnyuvannya zdijsnyuyetsya za formuloyuRozrahunok kilkosti virivnyanih funkcionalnih tochok AFP red Podalsha ocinka v virivnyanih funkcionalnih tochkah zalezhit vid tipu ocinki Pochatkove ocinka kilkosti virivnyanih funkcionalnih tochok dlya programnogo dodatka viznachayetsya za nastupnoyu formuloyu Vona vrahovuye tilki novu funkcionalnist yaka realizuyetsya v produkti Proekt rozrobki produktu ocinyuyetsya v DFP development functional point za formuloyu D F P A D D C F P displaystyle DFP ADD CFP nbsp de CFP conversion functional point funkcionalni tochki pidrahovani dlya dodatkovoyi funkcionalnosti yaka bude potribno pri ustanovci produktu napriklad migraciyi danih Proekt doopracyuvannya i vdoskonalennya produktu ocinyuyetsya v EFP enhancement functional point za formuloyu E F P A D D C H G A C F P D E L displaystyle EFP ADD CHGA CFP DEL nbsp de ADD funkcionalni tochki dlya dodanoyi funkcionalnosti CHGA funkcionalni tochki dlya zminenih funkcij rozrahovani pislya modifikaciyi VAFA velichina faktoru virivnyuvannya rozrahovanogo pislya zavershennya proektu DEL obsyag viluchenoyi funkcionalnosti VAFB velichina faktoru virivnyuvannya rozrahovanogo do pochatku proektu Sumarnij vpliv proceduri virivnyuvannya lezhit v mezhah 35 vidnosno obsyagu rozrahovanogo v UFP Metod analizu funkcionalnih tochok nichogo ne govorit pro trudomistkist rozrobki ocinenogo produktu Pitannya virishuyetsya prosto yaksho kompaniya rozrobnik maye vlasnu statistiku obsyagu vikonanoyi roboti na realizaciyu funkcionalnih tochok Yaksho takoyi statistiki nemaye to dlya ocinki trudomistkosti i terminiv proektu mozhna vikoristovuvati metod COCOMO II Primitkired Garmus David Russac Janet Edwards Royce 3 chervnya 2011 Certified Function Point Specialist Examination Guide angl CRC Press ISBN 9781439856987 Posilannyared Cya stattya mistit perelik dzherel ale pohodzhennya okremih tverdzhen u nij zalishayetsya nezrozumilim cherez praktichno povnu vidsutnist vinosok Bud laska dopomozhit polipshiti cyu stattyu dodajte vinoski z posilannyami na vidpovidni dzherela do tekstu statti gruden 2012 The Netherlands Software Metrics users Association NESMA Arhivovano 9 travnya 2012 u Wayback Machine The Common Software Measurement International Consortium Arhivovano 4 bereznya 2016 u Wayback Machine Function Point Analysis in FOLDOC Arhivovano 18 zhovtnya 2012 u Wayback Machine An introduction tutorial to Function Points Analysis Arhivovano 10 grudnya 2012 u Wayback Machine Otrimano z https uk wikipedia org wiki Analiz funkcionalnih tochok