Dezvoltare bazată pe caracteristici

Dezvoltarea bazată pe caracteristici ( FDD , dezvoltarea bazată pe caracteristici ) este o metodologie de dezvoltare software iterativă , una dintre metodologiile de dezvoltare agile . FDD este o încercare de a combina cele mai recunoscute metodologii din industria de dezvoltare software, luând ca bază funcționalitatea (caracteristicile) software-ului în curs de dezvoltare care este important pentru client. Scopul principal al acestei metodologii este de a dezvolta un software real, funcțional, într-o manieră sistematică, în timp util.

Istorie

FDD a fost propus inițial de Jeff De Luca pentru un  proiect de dezvoltare software de 15 luni și 50 de persoane pentru o mare bancă din Singapore în 1997. De Luca a evidențiat un set de cinci procese, care acoperă atât dezvoltarea unui model comun, cât și menținerea unei liste, planificarea, proiectarea și implementarea elementelor de funcționalitate (funcționalitate în limba engleză ).  

Prima descriere a FDD a apărut în 1999 în capitolul 6 din Java Modeling in Color with UML [1] . În cartea A Practical Guide to Feature-Driven Development [2] (2002), descrierea FDD a fost generalizată și, în special, eliberată de legarea la un limbaj de programare specific.

Prezentare generală

FDD include cinci activități de bază:

  1. dezvoltarea unui model comun;
  2. compilarea unei liste de funcții necesare sistemului;
  3. planificarea lucrărilor pentru fiecare funcție;
  4. proiectarea funcției;
  5. implementarea funcției.


Primele două procese se referă la începutul proiectului. Ultimele trei sunt efectuate pentru fiecare funcție. Dezvoltatorii din FDD sunt împărțiți în „maeștri de clasă” și „programatori șefi”. Principalii programatori îi implică pe proprietarii claselor implicate să lucreze la următoarea proprietate. Lucrarea la proiect implică versiuni frecvente și este împărțită în iterații, fiecare dintre acestea implicând implementarea unui anumit set de funcții.

Dezvoltare generală a modelului

Dezvoltarea începe cu o analiză end-to-end la nivel înalt a lărgimii gamei de sarcini de rezolvat și a contextului sistemului. În plus, pentru fiecare zonă modelată, se efectuează o analiză mai detaliată de la capăt la capăt. Descrierile transversale sunt compilate în grupuri mici și prezentate pentru discuții ulterioare și evaluare inter pares. Unul dintre modelele propuse sau combinația lor devine un model pentru o anumită zonă. Modelele fiecărei domenii de activitate sunt combinate într-un model final comun, care se modifică pe parcursul activității.

Compilarea unei liste de caracteristici (funcții)

Informațiile colectate în construirea modelului general sunt utilizate pentru a compila o listă de caracteristici. Acest lucru se realizează prin împărțirea zonelor ( domeniul ing.  ) în sub-domeni (domenii, domeniile ing . ) din punct de vedere al funcționalității. Fiecare subdomeniu separat corespunde unui proces de afaceri , ai cărui pași devin o listă de funcții (proprietăți). În acest caz, funcțiile sunt mici bucăți de funcții înțelese de utilizator reprezentate ca „<acțiune> <rezultat> <obiect>”, cum ar fi „verificarea parolei utilizatorului”. Dezvoltarea fiecărei caracteristici nu trebuie să dureze mai mult de 2 săptămâni, altfel sarcina trebuie împărțită în mai multe subsarcini, fiecare dintre acestea putând fi finalizată în perioada stabilită de două săptămâni.  

Plan pentru proprietăți (funcții)

După alcătuirea unei liste cu principalele caracteristici, este timpul să întocmești un plan de dezvoltare software. Proprietatea clasei este împărțită între programatorii principali prin aranjarea și organizarea proprietăților (sau seturi de proprietăți) în clase.

Design caracteristică

Pentru fiecare proprietate este creat un pachet de design. Programatorul principal alocă un grup mic de proprietăți pentru dezvoltare în decurs de două săptămâni. Împreună cu dezvoltatorii clasei corespunzătoare, programatorul principal creează diagrame de secvență detaliate pentru fiecare proprietate, rafinând modelul general. În plus, sunt scrise „spații” ale claselor și metodelor și are loc o revizuire critică a designului.

Implementarea funcției

După o revizuire de succes a designului, această funcționalitate vizibilă de client este implementată într-o stare de pregătire. Codul programului este scris pentru fiecare clasă. După testarea unitară a fiecărui bloc și verificarea codului, funcția finalizată este inclusă în proiectul principal ( build în limba engleză  ).

Etape

Deoarece funcțiile sunt mici, dezvoltarea lor este o sarcină relativ ușoară. Pentru a monitoriza un proiect de dezvoltare software și pentru a oferi date exacte despre dezvoltarea proiectului, este necesar să se înregistreze dezvoltarea fiecărei caracteristici (funcție). FDD identifică șase etape consecutive pentru fiecare caracteristică (proprietate). Primele trei sunt complet finalizate în procesul de proiectare, ultimele trei - în procesul de implementare. Pentru comoditatea monitorizării performanței muncii în fiecare etapă, este afișat procentul de pregătire (finalizare). Tabelul de mai jos prezintă pașii principali. O caracteristică încă în dezvoltare este finalizată în proporție de 44% (Analiza zonei 1% + Design 40% + Revizuire design 3% = 44%)

Tabelul 1. Repere
Analiza zonei Proiecta Revizuirea planului Codul Revizuire a Codului Includerea în asamblare
unu % 40% 3% 45% zece % unu %

Cele mai bune practici

FDD este construit în jurul unui set de bune practici (un set de bune practici) recunoscute de industrie și derivate din ingineria software . Aceste practici sunt construite din punct de vedere al funcționalității care este importantă pentru client. Mai jos este o scurtă descriere a fiecărei metode:


Vezi și

Metodologia de dezvoltare agilă

Note

Literatură

Link -uri