Tehnica de Estimare Function Points pe scurt

Publicata pentru prima oara in 1979 de catre Allan Albrecht, tehnica de estimare bazata pe Function Points (cunoscuta si ca FPA – Function Point Analysis) este folosita pentru evaluarea complexitatii functionalitatilor unei aplicatii software si a aparut la acea vreme ca o incercare de a gestiona dificultatea estimarii unei aplicatii software bazata pe numararea liniilor de cod. Din 1986, cand s-a infiintat Grupul International al Utilizatorilor de FP (IFPUG), metoda a fost rafinata si publicata in mai multe versiuni ale “Function Point Counting Practices Manual”.  Aceasta tehnica de estimare are la baza descompunerea aplicatiei folosind cerintele/specificatiile utilizator in entitati logice si tranzactii.

Extrem de importanta este stabilirea ariei de cuprindere a ceea ce urmeaza a fi estimat. Acest lucru ajuta la scoaterea la suprafata a eventualelor “zone gri” din punctul de vedere al ariei de cuprindere a proiectului. Indiferent cand se face aceasta estimare, este inca o ocazie pentru a lamuri ce este in si out of scope-ul proiectului, o parte din eventualele conflicte si negocieri mutandu-se in aceasta faza.
Odata stabilita aria de cuprindere, procesul de estimare se poate sparge in 2 pasi:

1. Identificarea, clasificarea si estimarea complexitatii entitatilor logice care fac parte din aplicatie, a entitatilor cu care aplicatia interactioneaza si a tranzactiilor dintre aceste entitati;
2. Estimarea complexitatii globale a sistemului;

In urma primului pas se obtine un numar de Function Points Neajustat (UFP – Unadjusted Function Points) care va fi ajustat pentru a obtine numarul final de Function Points (FP)  cu un factor (VAF – Value Adjustment Factor) obtinut din al doilea pas, factor bazat pe analiza complexitatii generale a sistemului.

Pentru acoperirea primului pas se descompune aplicatia si “mediul extern apropiat” al aplicatiei in componente care se pot clasifica in 5 categorii:

• Entitati Logice Interne (ILF – Internal Logical File) – Un modul al aplicatiei, o baza de date care se va proiecta si dezvolta in cadrul aplicatiei etc
• Entitati Logice Externe (EIF – External Interface File) – o aplicatie externa sau un modul extern cu care aplicatia noastra interactioneaza (trimite sau primeste date)
• Intrari Externe (EI – External Input) – reprezinta un proces prin care sunt aduse date in aplicatia noastra din exterior. Aceste date pot veni dintr-un “data input screen” sau dintr-o alta aplicatie si pot fi folosite pentru a alimenta entitati logice interne (ITL). Ele pot fi informatii de control interne aplicatiei, transparente utilizatorilor, sau informatii cu valoare pentru utilizatori.
• Iesiri Externe (EO – External Output) – reprezinta un proces prin care date interne prelucrate sunt livrate catre exteriorul aplicatiei.  In plus un EO poate actualiza un ILF (o entitate logica interna aplicatiei). Aceste date pot fi livrate ca rapoarte sau fisiere. Termenul de “date prelucrate” se refera la date care sunt obtinute prin aplicarea unor algortimi sau combinarea unor date existente déjà in ILF-urile interne aplicatiei.
• Cereri Externe (EQ – External Query) – reprezinta un proces care are ca rezultat extragerea  datelor din ILF-uri si EIF-uri. O cerere externa nu modifica nici un FTR si nu contine date prelucrate.

Apoi, pentru fiecare dintre componentele identificate si clasificate se evalueaza complexitatea, numarandu-se DET-urile si FTR-urile, respectiv DET-urile si RET-urile dupa cum urmeaza:

RET (Record Element Type) – Reprezinta un grup de date in cadrul unui ILF sau EIF.
Ex: Numele si adresa clientului, Identificatorele credit cardurilor si numerele cardurilor. In general RET-urile sunt parte a unei baze de date sau parte a unui fisier de resurse.  Se numara tipurile de RET-uri si nu cate inregsitrari vor aparea in baza de date pentru RET-ul respectiv.
DET (Data Element Type) – Reprezinta o informatie dinamica care este citita dintr-o entitate logica sau continuta de un FTR.
Ex: Mesaje de eroare, Mesaje de confirmare, Valori citite dintr-un ILF etc
FTR (File Type Referenced) – Reprezinta o entitate logica referita de o tranzactie. Poate fi o entitate logica interna (ILF) sau o entitate logica externa (EIF)
In functie de numarul de DET-uri, RET-uri si FTR-uri identificate pentru fiecare componenta se estimeaza un anumit nivel al complexitatii (Low, Medium sau High) si se aloca un anumit numar de FP-uri.

Pentru EI-uri:

Pentru EO-uri:

Pentru EQ-uri:

Pentru ILF-uri:

Pentru EIF-uri:

Suma FP-urilor astfel rezultate pentru componentele identificate va reprezenta UFP (Unadjusted Function Points).

Pasul al doilea al acestei tehnici de estimare este reprezentat de ajustarea numarului de UFP-uri obtinute mai sus cu o valoare care ia in calcul evaluarea complexitatii generale a sistemului in functie de 14 caracteristici (GSC – Global System Characteristics) pe o scala de la 0 la 5 (5 – complexitate maxima). Pentru calificarea acestor caracteristci, Manualul de practici de FP publicat de IFPUG furnizeaza un ghid destul de clar si cuprinzator, asadar calificarea caracteristicilor e un “exercitiu” fara batai de cap.
Cele 14 caracteristici generale care se puncteaza le putem privi si ca un checklist care trebuie avut in vedere atunci cand vorbim de complexitatea unei aplicatii software: daca din cauza lipsei unor cerinte clare la unele din cele 14 caracteristici nu putem raspunde, atunci acea zona devine automat o zona de risc. Aceste caracteristici acopera urmatoarele zone:
1      Comunicatii la nivel de date
2      Procesarea distribuita a datelor
3      Performanta
4      Folosirea configuratiei de sistem
5      Frecventa tranzactiilor
6      Online data entry
7      Cerinte user-friendly
8      Update-uri online
9      Complexitatea procesarii
10    Reutilizarea codului
11    Usurinta instalarii
12    Usurinta in operare
13    Site-uri multiple
14    Faciliteaza schimbarile
Factorul de ajustare (VAF) va fi egal cu 0.65 + (ΣCi)/100, Unde Ci – reprezinta calificativul fiecarei caracteristici generale de sistem, si deci poate varia intre 0.65 (daca toate caracteristicile primesc calificativul 0) si 1.35 (daca toata caracteristicile primesc calificativul 5). Numarul final de FP-uri va fie egal cu VAF * UFP.

Dincolo de procesul descris mai sus, am extras din propria experienta un Top 5 al celor mai bune practici in folosirea FPA:

1. Membrii echipei care participa la procesul de estimare vor trebui sa coboare la acelasi nivel de detaliu.
2. Mai mult, nivelul de detaliu folosit in descompunerea pe componente trebuie pastrat pentru proiectele din aceeasi categorie pentru a avea consistenta si date istorice relevante.
3. Valoarea unui FP (de exemplu in mandays) se poate obtine in termeni de range de valori numai dupa rularea tehnicii de mai multe ori pe proiecte similare respectand primele 2 bune practici de mai sus.
4. Conteaza foarte mult si ce tip de proiect este dpdv software (dezvoltare, enhancement  sau maintenance)  iar FPA detaliaza acest lucru in  “Function Point Counting Practices Manual”
5. Calificarea celor 14 Caracteristici Generale ale Sistemului este un foarte bun exercitiu de grup de “normare” a echipei si de obtinere a “buyin”-ului.

De ce ati folosi aceasta tehnica? Care sunt dificultatile cu care va puteti confrunta? Despre raspunsurile la aceste intrebari si in general despre beneficiile si provocarile folosirii acestei tehnici de estimare vom vorbi, insa intr-un alt articol…