Dezvoltare bazată pe funcții

Dezvoltarea bazată pe caracteristici este o metodologie agilă , concepută de Jeff De Luca și Peter Coad , care propune o analiză robustă și o fază de proiectare integrată cu un model de dezvoltare agil.

După cum sugerează și numele, este o formă de dezvoltare ghidată de funcționalitățile necesare și necesare ale programului. Sunt disponibile mai multe instrumente de asistență gratuite, unele chiar open source , bazându-se strict pe utilizarea UML și, bineînțeles, pe versiunea colorată a UML proiectată de autori. Mai mult, există o comunitate foarte activă care se ocupă de această metodologie și de instrumentele utile pentru automatizarea utilizării acesteia, dezvoltându-le și comparându-le.

Este poate cel mai bun compromis și cea mai bună soluție agilă posibilă, dar este mult mai puțin cunoscut decât Programarea extremă , chiar dacă este indicat în Manifestul Agil . Serguei Khramtchenko face o comparație directă (vezi Bibliografia) din care reiese în mod surprinzător că dezvoltarea funcțională a caracteristicilor este chiar mai flexibilă decât programarea extremă, chiar dacă prima are o fază de proiectare clasică pe care aceasta din urmă o elimină tocmai pentru a câștiga flexibilitate.

Istorie

FDD a fost inventat de Jeff De Luca în 1997, care a propus un set de cinci procese care implică dezvoltarea completă bazată pe caracteristici. Acest model a fost puternic bazat pe ideile lui Peter Coad și completat de experiența personală. Prima formă structurată a FDD a fost prezentată în cartea Java Modeling in Color with UML de Coad însuși, Eric Lefebvre și Jeff De Luca în 1999; mai târziu, o versiune mai generală a fost publicată în Stephen Palmer și Mac Felsing's A Practical Guide to Feature-Driven Development . Mai multe informații istorice pot fi găsite pe site-ul personal al lui Jeff De Luca.

Etapele dezvoltării

Proiectul este împărțit în cinci faze, numite procese:

elaborează un model general
- criterii de intrare : după ce au ales experții problemei, programatorii șefi și arhitectul șef;
- activitate : managerul de proiect trebuie să instruiască echipa de modelare; echipa de modelare trebuie să ofere o imagine de ansamblu asupra domeniului problemei, să pregătească documentele funcționale și, împărțit în grupuri mici, să dezvolte modelul; arhitectul șef trebuie să rafineze modelul general de obiecte împreună cu echipa de modelare și să scrie note modelului împreună cu programatorii șefi;
- verificare : echipa de modelare trebuie să efectueze o evaluare internă și externă cu referire la experții în afaceri și viitorii utilizatori;
- criterii de ieșire : după definirea modelului obiect, dispunând astfel diagramele claselor, metodele și atributele claselor, succesiunea claselor (dacă există), notele la model;
construiți o listă de caracteristici
- criterii de intrare : după ce au ales experții problemei, programatorul șef și arhitecții șefi;
- activități : managerul de proiect trebuie să formeze echipa listei de caracteristici care trebuie să includă programatorii șefi ai echipei de modelare; echipa cu lista de caracteristici trebuie să definească lista de caracteristici în termeni de acțiune-rezultat-obiect;
- verificare : echipa listei de funcții trebuie să efectueze o evaluare internă și externă cu referire la experții în afaceri și la viitorii utilizatori;
- criterii de ieșire : după definirea listei de funcții având astfel disponibilă lista zonelor obiect, lista activităților de afaceri pentru fiecare zonă obiect, lista funcțiilor care satisfac toate punctele fiecărei liste de activități;
plan pentru funcționalitate
- criterii de intrare : procesul de construire a unei liste de caracteristici a fost finalizat ;
- activitate : managerul de proiect trebuie să instruiască echipa de proiectare care include programatori șefi și manageri de dezvoltare; echipa de proiectare trebuie să definească secvența de dezvoltare, să atribuie activități de afaceri liderilor programatori și să aloce clase dezvoltatorilor;
- verificare : echipa de proiectare trebuie să efectueze o auto-verificare a muncii efectuate;
- criterii de ieșire : după definirea unui plan de dezvoltare, care include activitățile de afaceri cu datele de finalizare și programatorii șefi desemnați, data de finalizare a subiectelor (derivate din cele ale activităților de afaceri), lista claselor cu dezvoltatorii săi;
design pentru funcționalitate
- criterii de intrare : procesul de planificare prin funcționalitate a fost finalizat;
- activitate : fiecare programator șef formează echipa de funcționalitate; fiecare expert în probleme definește modul de abordare și rezolvare a problemei; echipa de caracteristici își studiază documentele privind cerințele de caracteristică; echipa de proiectare dezvoltă diagramele secvențiale; programatorul șef rafinează modelul obiectului pentru a defini dacă se scrie sau se modifică clase, metode, atribute; echipa de caracteristici scrie clasele și antetele metodelor;
- verificare : echipa de funcționalități inspectează proiectul în toate aspectele sale funcționale și temporale;
- criterii de ieșire : au definit un pachet complet de proiectare care include un document explicativ al întregului proiect cu specificațiile la care se face referire (dacă există referințe), diagramele secvențiale, alternativele de proiectare (dacă există), modelul complet al obiectelor de clase, metode și atribute, antetele claselor și metodelor, o listă de lucruri cu un calendar de termene limită pentru fiecare activitate și fiecare membru al echipei;
dezvoltați pentru funcționalitate
- criterii de intrare : procesul de planificare prin funcționalitate a fost finalizat și proiectul a fost inspectat cu succes în toate aspectele sale funcționale și temporale;
- Sarcini : Echipa de caracteristici implementează clase și metode, inspectează codul și efectuează teste unitare; programatorul șef decide (după testele unitare) împreună cu echipa de funcționalități care clase pot fi promovate ca fiind utile pentru construirea proiectului în ceea ce privește funcționalitățile necesare;
- Verificare : Programatorul șef supraveghează faptul că inspecția codului și satisfacția testelor unitare sunt efectiv completate de echipa de funcționalitate în toate punctele;
- criterii de ieșire : obținerea de clase și metode care au fost inspectate și testate cu succes, promovate în cele din urmă la integrarea în proiect (evident pentru a acoperi toate funcționalitățile așteptate).

În practică, iterația poate fi redusă la un ciclu simplu format doar din ultimii doi pași: definiți o listă de caracteristici / dezvoltați prin funcționalitate . Procesul critic este primul, care este de a dezvolta un model general , și aceasta este ceea ce trebuie să ofere documentația UML . Aceste diagrame trebuie să fie configurate în așa fel încât să se obțină o fragmentare (o granularitate) de sus în jos, pentru a putea fi dezvoltate funcționalități care pot fi produse în iterații scurte. Aceste funcționalități trebuie apoi reunite într-un singur pachet la sfârșitul fiecărei iterații.

Fiecare iterație constă din șase etape:

Pachet Kickoff Meeting (fiecare detaliu al caracteristicilor incluse este clarificat);
Proiectare (sunt definite clasele / metodele / documentația necesare);
Revizuirea proiectării (toți actorii de dezvoltare revizuiesc proiectul propus);
Dezvoltare (codul așteptat este implementat cu testele unitare relative);
Reuniunea de revizuire a codului (revizuirea codului este efectuată de toți programatorii);
Release meeting (funcțiile implementate sunt „promovate” la procesul de integrare).

Procesul de dezvoltare

Colectarea cerințelor și specificațiilor utilizatorilor are loc implicând clientul și în timpul dezvoltării proiectului și nu numai într-o fază inițială. Inițial veți obține o listă de caracteristici necesare, care vor deveni baza cronologiei proiectului și una sau mai multe diagrame UML care definesc domeniul problemei. Bazându-se pe această bază, clientul și dezvoltatorii vor lucra împreună la cerințe în iterații scurte care se întind pe fragmente de afaceri.

Așteptați-vă să dureze 6 luni de dezvoltare pentru a finaliza procesele modelate în 2 săptămâni de întâlniri preliminare cu clienții.

Dezvoltarea bazată pe funcții nu necesită în mod explicit scrierea documentației, dar obligă utilizarea diagramelor UML. Aceasta este pentru a avea o bază de decizie stabilă pe tot parcursul procesului de dezvoltare, doar în al doilea rând va fi util să scrieți documentație formală, dacă este necesar.

În timpul proiectului există multe documente care trebuie să fie disponibile pentru diferiții actori, astfel încât cea mai bună soluție este organizarea unui site web intern care conține toate informațiile despre proiect: lista dezvoltatorilor și a experților problemei, modelul UML cu comentarii, forumuri de discuții, convenții de scriere a codului, listă de instrumente și biblioteci utilizate, rapoarte de teste unitare, starea proiectului, cronologie, inclusiv planificarea viitoare, etc ...

În timpul dezvoltării, organizat în iterații scurte, se formează o structură ierarhică cu cifre la jumătatea distanței dintre managerul de proiect și dezvoltatori: programatorii șefi. Acestea sunt în fruntea fiecărei iterații unice, care, prin urmare, poate fi numeroasă și poate continua în paralel, alegând și echipa (compusă din 3-5 persoane) care se va ocupa de ele.

Experiența programatorilor șefi și fragmentarea muncii în iterații sunt mecanismele de control și reglare ale dezvoltării bazate pe caracteristici. La începutul fiecărei iterații, sunt organizate întâlniri de proiectare pentru a permite membrilor echipei să compare și să obțină documentația de cod.

Redactarea codului implică utilizarea riguroasă a unui standard comun de scriere și utilizarea testelor unitare, care pot fi organizate la discreția programatorilor șefi.

Având în vedere numeroasele întâlniri ținute înainte de a începe să scrie codul, această activitate devine ceva mecanic, de fapt Feature Driven Development descurajează utilizarea practicilor precum Refactoring , încurajând în același timp partajarea codului produsului (în special a documentației aferente) între diferiți programatori. .

Pentru revizuirea codului, mergem dincolo de programarea Pair, deoarece partajarea în cadrul echipei de iterație permite o verificare mult mai largă. În orice caz, tocmai pentru a permite cea mai bună revizuire posibilă a codului, echipele de dezvoltare trebuie să fie puține la număr și iterațiile trebuie să fie scurte, între 1 și 3 săptămâni.

Lansarea versiunilor este prevăzută pentru sfârșitul fiecărei iterații, rareori mai multe iterații, dar acest lucru permite implicarea mult mai puțin a clientului decât celelalte metodologii ușoare. Și permite, de asemenea, să nu livreze unele versiuni intermediare atunci când condițiile înconjurătoare nu o fac posibilă, de exemplu în cazul software-ului medical încorporat.

Urmărirea stării proiectului este o sarcină simplificată de Feature Driven Development, deoarece aveți lista de caracteristici de implementat chiar de la început și fiecare iterație are greutăți bine definite pentru fiecare pas:

întâlnire de planificare a iterației - prezentare de domeniu (1%),
faza de proiectare (40%),
ședință de revizuire a proiectării - inspecție (3%),
faza de codificare (45%),
întâlnire de revizuire a codului - inspecție (10%),
promovează pentru a construi moment (1%).

Pornind de la aceste date, Jeff De Luca afirmă că modificările de până la 10% din cerințe pe parcursul derulării proiectului nu afectează în așa fel încât să afecteze termenul scontat.

Instrumente de asistență

Deși întreaga structură organizațională și fiecare proces de dezvoltare bazată pe caracteristici pot fi realizate manual, există mai multe instrumente pentru a sprijini această metodologie. În special, puteți găsi instrumente gratuite, și chiar open source, prin comunitatea FDD. Cu toate acestea, credem că este mai util să ne oprim asupra obiectelor și activităților, comparativ cu individul, diferite instrumente care le susțin.

Culori UML

UML colorat este un UML standard cu clase împărțite în patru categorii identificate prin patru culori diferite:

galben (indică un rol, acoperit de o persoană sau organizație, cum ar fi diferitele tipuri de utilizatori ai unui serviciu);
albastru (indică o descriere a modelului-catalog, de exemplu tipul obiectului dintr-o bază de date, dar nu și obiectul unic);
verde (indică un loc sau un obiect, de exemplu obiectul unic al bazei de date de mai sus);
roz (indică Times, un moment sau un interval asociat unui proces, de exemplu o acțiune asupra unui obiect de bază de date).

Clasele și interfețele auxiliare rămân standard și nu sunt colorate.

Raport de progres

Un raport de progres este definit și reprezentat cu un model unic de dezvoltare bazată pe caracteristici, diagramele de parcare . Fiecare spațiu de parcare reprezintă un set de caracteristici, iar citirea sa este destul de simplă și imediată.

Fundal verde: caracteristici finalizate;
Fundal albastru: dezvoltare în curs;
Fundal roșu: dezvoltare întârziată în ceea ce privește programarea așteptată;
Fundal alb: dezvoltarea nu a început încă;
Litere în partea dreaptă sus: inițiale ale persoanei responsabile de bloc, adică a programatorului principal;
Numărul dintre paranteze: numărul de funcții care aparțin blocului;
Procent: procentaj de funcții finalizate;
Luna în jos: termen limită pentru dezvoltarea blocului de funcții.

Raportul de progres în sine are un nivel mai ridicat de detaliu într-un tabel cu cronologia pentru fiecare caracteristică. Repere ale fiecărui pas al iterației sunt prevăzute în timp ce culorile indică pur și simplu: verde (totul conform planului), roșu (dezvoltarea funcționalității rămâne în urma programării așteptate).

Bibliografie

Serguei Khramtchenko, Comparing eXtreme Programming and Feature Driven Development in academic and regolamented Environments - Harvard University, CSCIE-275: Software Architecture and Engineering - 2004.

Elemente conexe