Unified Process ( în engleză unified process ) este o metodologie pentru construirea proceselor de dezvoltare software care permite echipei de dezvoltare să transforme cerințele clienților într-un produs viabil. În funcție de cerințele și resursele disponibile, procesul de dezvoltare poate fi adaptat prin includerea sau excluderea anumitor activități ale proiectului. Un exemplu de metodologie de dezvoltare bazată pe Procesul Unificat este Procesul Rațional Unificat ( RUP ), care conține o serie de activități nedescrise într-un cadru mai general, dar de valoare pentru un anumit tip de proiect [1] .
Procesul unificat folosește intens limbajul de modelare unificată ( UML ). La baza UML se află un model care permite unei echipe de dezvoltare să înțeleagă într-un mod simplificat varietatea de procese complexe necesare dezvoltării software-ului. Diverse modele utilizate în Procesul Unificat vă permit să vizualizați sistemul, să descrieți structura și comportamentul acestuia, să documentați deciziile luate în timpul procesului de dezvoltare [1] .
Originile cadrului se află în munca angajatului Ericsson Ivar Jakobson , publicată la sfârșitul anilor 1960. Jacobson și colegii săi au modelat sisteme uriașe de telecomunicații folosind straturi de „blocuri” (ceea ce mai târziu a devenit cunoscut sub numele de „componente”): straturile inferioare au servit drept bază pentru subsistemele din straturile superioare. Echipa a construit blocurile de jos analizând cazurile de trafic care s-ar fi putut întâmpla utilizatorilor sistemului . Aceste „incidente” au devenit prototipul cazurilor de utilizare , care mai târziu au devenit parte a UML [2] . Lucrarea lui Jacobson a oferit, de asemenea, un impuls pentru diagramele utilizate în UML , inclusiv diagramele de activitate și secvențe .
În 1987, Jacobson și-a fondat propria companie, Objectory AB și a petrecut câțiva ani alături de parteneri, dezvoltând un proiect și un produs numit Objectory . În 1995, Jacobson a publicat cartea Object-Oriented Software Engineering , care descrie un proces de dezvoltare condus de cerințele clienților, care sunt traduse în produsul final prin cazuri de utilizare. Lansarea cărții a coincis cu prima publicație online a nucleului Procesului unificat .
În 1995, Objectory AB a fost preluată de Rational Corporation . Cu ajutorul unui număr mult mai mare de colegi, Jacobson începe să extindă procesul Objectory cu instrumente de management de proiect și dezvoltare. Împreună cu Gradi Booch și James Rumbaugh , care lucraseră anterior la Rational , Jacobson a devenit membru al grupului de „trei prieteni” [3] [4] , care a condus munca de creare a unui proces numit Procesul de obiectie rațională ( POR ), precum și distribuirea Procesului unificat , care a devenit baza pentru Limbajul de modelare unificat .
În timp ce lucra la ROP și UML , Rational Corporation a continuat să fuzioneze și să achiziționeze companii implicate în crearea de instrumente pentru dezvoltarea software. Aceste instrumente au oferit capacitatea de a gestiona cerințele ("RequisitePro"), testarea generală ("SQA"), testarea performanței, managementul configurației și managementul schimbărilor. În 1998, Rational schimbă numele produsului în RUP , al cărui nucleu conceptual rămâne Procesul Unificat .
Procesul unificat se bazează pe cazuri de utilizare care descriu unul sau mai mulți actori care interacționează cu sistemul și produc rezultate care sunt de valoare pentru participanții la proces. Cazurile de utilizare sunt principala forță motrice care guvernează întregul proces de dezvoltare, de la colectarea și discutarea cerințelor și terminând cu analiză, proiectare și implementare. Scenariile de utilizare sunt descrise într-un limbaj simplu și ușor de înțeles, astfel încât să fie ușor de înțeles pentru un cititor extern.
Conform Procesului Unificat , arhitectura este organizarea fundamentală a întregului sistem în centrul procesului de dezvoltare . Poate include elemente statice și dinamice, interacțiunea acestora și vă permite să rezolvați problemele de performanță a produsului, extensibilitate, posibilitatea de reutilizare a elementelor, ajuta la depășirea limitărilor economice și tehnice. Echipa de proiectare începe să lucreze la descrierea arhitecturii cât mai devreme posibil și o extinde și o îmbunătățește continuu în timpul dezvoltării. Arhitectura este considerată un aspect important al Procesului Unificat din mai multe motive, printre care cheie se numără capacitatea de a vedea imaginea de ansamblu, aplicarea corectă a eforturilor dezvoltatorilor, facilitarea oportunităților de reutilizare a componentelor, evoluția sistemului, selectarea corectă a cazurilor de utilizare.
Al treilea principiu fundamental al Procesului Unificat este utilizarea unei abordări iterative și incrementale . Iterațiile sunt proiecte în miniatură care vă permit să rulați o versiune mai nouă a sistemului. Rezultatul unei iterații, modificările aduse sistemului, se numește increment. În special, abordarea iterativă vă permite să îmbunătățiți în mod constant arhitectura sistemului, să gestionați schimbările constante ale cerințelor și să ajustați în mod flexibil planul întregului proiect. Angajamentul față de principiul integrării continue vă permite să identificați posibilele probleme într-un stadiu incipient. În plus, iterativitatea ajută la minimizarea riscurilor asociate cu limitările tehnice, arhitectura și cerințele în schimbare [5] .
Fiecare ciclu de dezvoltare, conform Procesului Unificat , constă din patru faze, reprezentând intervalul de timp dintre etapele importante ale proiectului, permițând managerilor să ia decizii importante cu privire la continuarea procesului de dezvoltare, domeniul de activitate, bugetul și programul.
Faza inițială ( ing. Inception ) vă permite să conturați limitele sistemului, să determinați arhitectura propusă, să identificați riscurile critice și să luați decizii cu privire la începerea proiectului, în funcție de estimările estimate ale costului, efortului, programului și produsului acestuia. calitate. Asociat cu această fază este o etapă importantă a proiectului numită Life Cycle Goals.
Faza de pregătire ( Elaborare engleză ) a fost creată pentru a rezolva următoarele sarcini: clarificarea majorității cerințelor funcționale; transformarea arhitecturii dorite într-un prototip funcțional axat pe arhitectură; eliminarea riscurilor critice; luarea unei decizii finale cu privire la începerea proiectului și realizarea unui plan suficient de detaliat. Această fază se încheie cu o piatră de hotar numită „Arhitectura ciclului de viață”.
Faza de construcție implică dezvoltarea iterativă a unui sistem care poate interacționa cu succes cu utilizatorii într-un mediu beta . Prezența unui sistem mai mult sau mai puțin funcțional marchează atingerea cu succes a jalonului corespunzător.
Transferul ( ing. Tranziția ) a unui sistem complet funcțional către utilizatori este faza finală a ciclului de dezvoltare. O piatră de hotar pentru aceasta este lansarea produsului [6] .
În cadrul Procesului unificat , în fiecare fază de dezvoltare, există cinci tipuri de fluxuri de lucru: cerințe, analiză, proiectare, implementare și testare.
Fiecare proces este un set de activități realizate de diferiți membri ai echipei de proiect. De exemplu, scopul proceselor de colectare a cerințelor este de a crea un model de cazuri de utilizare care vă permite să identificați principalele cerințe funcționale pentru sistem. Procesele de analiză și modelul corespunzător permit dezvoltatorilor să structureze cerințele funcționale; Procesul de proiectare descrie implementarea fizică a cazurilor de utilizare și este o abstractizare pentru următorul model. Procesul și modelul de implementare descriu modul în care elementele de proiectare se referă la componentele software, inclusiv codul sursă, bibliotecile dinamice etc. Ultimul dintre modele, care descrie testarea, explică ce teste de sistem și teste unitare și cum ar trebui să efectueze echipa de dezvoltare [7] .
Fiecare dintre fazele descrise în Procesul Unificat constă din iterații , care sunt sub-proiecte în miniatură de durată limitată. De regulă, fiecare iterație include toate cele cinci elemente ale fluxului de lucru într-o măsură sau alta. Rezultatul unei iterații este o creștere , o versiune care conține îmbunătățiri față de versiunea anterioară a produsului.
În timpul iterației, echipa de dezvoltare parcurge următorii pași:
În cadrul procesului unificat , un artefact este orice informație care joacă un rol important în procesul de dezvoltare. Artefactele utilizate de ingineri includ modele, prototipuri, rezultate ale testelor etc. Artefactele managerului sunt planul de proiect, cazurile de afaceri etc. O componentă importantă a Procesului Unificat este că sistemul nu este considerat gata de utilizare până când toate artefactele relevante sunt incomplet.
Un executor este un rol pe care un angajat individual îl poate juca într-un proiect. Diferența dintre un actor și un actor (din cazuri de utilizare) este că acesta din urmă privește sistemul din „exterior”, în timp ce actorul privește din „interior”. Artiștii creează artefacte, fie singuri, fie în grupuri sau echipe. Este important să ne amintim că aceeași persoană poate juca mai multe roluri într-un proiect: de exemplu, un analist poate identifica și cazuri de utilizare și le poate descrie.
Fiecare dintre varietățile fluxului de lucru include mai multe activități - sarcini la care lucrează executanții pentru a obține artefacte [9] .
Procesul unificat stă la baza unui număr de metodologii de dezvoltare software, inclusiv [10] :
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|