Rational Unified Process în testarea de software

Metodologia RUP (Rational Unified Process) folosește abordarea orientată pe obiecte în proiectarea sa și utilizarea notației UML (Unified Modeling Language) este proiectată și documentată pentru a ilustra procesele în acțiune. Folosește tehnici și practici dovedite pe plan comercial.

Este un proces considerat greoi și aplicabil de preferință echipelor mari de dezvoltare și proiectelor mari, dar faptul că este extensiv personalizabil îi permite să fie adaptat la proiecte de orice anvergură.

Specifice

Pentru managementul proiectelor, modelul RUP(Rational Unified Process) oferă o soluție disciplinată, cum ar fi sarcinile și responsabilitățile descrise în cadrul unei organizații de dezvoltare de software.

RUP (Rational Unified Process) este, în sine, un produs software. Este modular și automatizat, iar întreaga sa metodologie este susținută de mai multe instrumente de dezvoltare integrate și vândute de IBM prin intermediul „Rational Suites.”

Metodele de concurență în domeniul ingineriei software includ „camere curate” (considerate grele) și agile (ușoare), cum ar fi Extreme Programming (XP-Extreme Programming), Scrum, FDD și altele.

Există anumite linii directoare și șabloane care sunt definite, pentru membrii personalului unui ciclu de producție, de RUP: o parte a clientului și o evaluare a progresului proiectului de către conducerea acestuia. Aceasta îi ajută pe dezvoltatori să rămână concentrați asupra proiectului.

Exigențe de management

Documentarea corespunzătoare este esențială pentru orice proiect de mare anvergură; rețineți că RUP descrie cum să se documenteze funcționalitatea, limitările sistemului, restricțiile de proiectare și cerințele de afaceri.

Cazurile de utilizare și scenariile sunt exemple de artefacte de proces dependente, care au fost considerate mult mai eficiente în capturarea cerințelor funcționale.

Utilizarea unei arhitecturi bazate pe componente

Arhitectura bazată pe componente creează un sistem care poate fi ușor extensibil, promovând reutilizarea și software-ul o înțelegere intuitivă. O componentă se referă, de obicei, la un obiect în programarea orientată pe obiecte.

RUP oferă un mod sistematic de a construi acest tip de sistem, concentrându-se pe producerea unei arhitecturi executabile în primele etape ale proiectului, adică înainte de a angaja resurse pe scară largă.

Componentele la care se face referire aici sunt, în general, incluse în infrastructurile deja existente la fața locului. Aceste infrastructuri includ CORBA, precum și Component Object Model (COM).

Utilizarea modelelor software vizuale în modelul RUP

Prin abstractizarea programării codului și reprezentarea acestuia cu ajutorul blocurilor grafice, RUP poate fi o modalitate eficientă de a obține o imagine de ansamblu a unei soluții.

Utilizarea modelelor vizuale poate permite, de asemenea, persoanelor cu un profil mai puțin tehnic (ca și clienții) să înțeleagă mai bine o anumită problemă și, astfel, să se implice mai mult în proiect ca întreg.

Limbajul de modelare UML a devenit un standard al industriei pentru reprezentarea proiectelor și este utilizat pe scară largă de RUP!

Cunoașteți mai multe: Citiți detalii exclusive despre Testarea Agile

Controlați calitatea software-ului

Nu asigură calitatea software-ului este cel mai frecvent eșec în toate proiectele de sisteme informatice. De obicei, se gândește la calitatea software-ului după finalizarea proiectelor sau calitatea este responsabilitatea unei alte echipe de dezvoltare a echipei.

Management și control al schimbării software

În toate proiectele software, existența schimbării este inevitabilă. RUP definește metode de control și monitorizare a schimbărilor. Deoarece o mică schimbare poate afecta aplicațiile în moduri total imprevizibile, controlul schimbărilor este esențial pentru succesul unui proiect.

RUP (Rational Unified Process)definește, de asemenea, domeniile de lucru și de securitate, ceea ce garantează unui programator că schimbările din alt sistem nu vor afecta sistemul dumneavoastră.

Faze ale metodologiei RUP

Până acum aceste linii directoare sunt generale, pentru a fi respectate să parcurgă toată viața unui ciclu de proiect. Fazele (vezi figura de mai jos) indică accentul dat în proiect la un moment dat. Pentru a surprinde dimensiunea temporală a unui proiect, RUP împarte proiectul în patru faze diferite:

Inițiere sau Proiectare: accent pe domeniul de aplicare al sistemului;

Pregătire: accent pe arhitectură;

Construcție: accent pe dezvoltare;

Tranziție: accent pe aplicație.

RUP se bazează, de asemenea, pe cei 4 Ps:

• Oameni
• Design
• Produs
• Proces
• Proces

Pietrele sunt compuse din iterații. Iterațiile sunt ferestre de timp; iterațiile au definit termenul așa cum fazele sunt obiective.

Toate fazele generează artefacte. Acestea vor fi utilizate în faza următoare și documentează proiectul și permite o mai bună urmărire.

Faza de proiectare

Faza de proiectare sau de inițiere conține fluxurile de lucru necesare pentru acordul părților interesate – stakeholderi – cu obiectivele, arhitectura și planificarea proiectului. Dacă acești actori au cunoștințe bune, nu va fi necesară o analiză. În caz contrar, este necesară o analiză mai elaborată.

În această etapă, cerințele esențiale ale sistemului sunt transformate în cazuri de utilizare. Obiectivul nu este de a le închide pe toate, ci doar pe cele care sunt necesare pentru a contura opinia.

Etapa este de obicei scurtă și este folosită pentru a defini dacă este fezabil să se continue proiectul și să se definească riscurile și costul ultimului. Se poate realiza un prototip pentru a fi aprobat de client. Așa cum citează RUP, idealul este de a efectua iterații, care trebuie să fie bine definite în ceea ce privește cantitatea și obiectivele lor.

Faza de elaborare

Pregătirea va fi pentru proiectarea sistemului, ca o completare a studiului și/sau a documentării cazurilor de utilizare, în fața arhitecturii sistemului, pentru a revizui modelul de afaceri pentru proiect și pentru a începe versiunea manualului de utilizare. Trebuie să se accepte: Descrierea produsului (creștere + integrare) este stabilă; planul de proiect este fiabil? Costurile sunt eligibile?

Faza de construcție

În faza de construcție, începe dezvoltarea fizică a software-ului, coduri de producție, teste alfa. Testele beta au fost efectuate la începutul fazei de tranziție.

Trebuie să acceptați testele, procesele stabile și de testare, iar codul sistemului este „baseline”.

Faza de tranziție

În această fază este livrarea („deployment”) de software, care realizează planul de implementare și livrare, monitorizarea și calitatea software-ului. Produsele (versiuni, versiuni) urmează să fie livrate și să plaseze satisfacția clientului. În această etapă are loc și instruirea utilizatorilor.

Discipline ale metodologiei RUP (Rational Unified Process)

Disciplina de modelare a afacerii

Organizațiile sunt din ce în ce mai dependente de sistemele informatice, astfel încât este imperativ ca inginerii de sisteme informatice să cunoască modul în care aplicațiile sunt integrate în dezvoltarea organizației. Companiile investesc în IT, care înțelege avantajul competitiv al valorii adăugate de tehnologie.

Obiectivul modelării afacerii este de a stabili mai întâi o mai bună înțelegere și comunicare între ingineria afacerilor și ingineria software.

Înțelegerea afacerii înseamnă că inginerii de software trebuie să înțeleagă structura și dinamica companiei țintă (clientul), problemele actuale cu care se confruntă organizația și potențialele metode și strategii de remediere.

Un alt aspect important care nu trebuie subminat este că părțile relevante, cum ar fi dezvoltatorii, precum și clienții și, de asemenea, utilizatorii finali, trebuie să aibă o înțelegere clară despre organizație, iar o caracteristică importantă a acestei înțelegeri este că ea trebuie să fie comună tuturor părților implicate.

Modelarea afacerii explică modul în care se descrie viziunea unei organizații în care va fi implementat sistemul și cum se utilizează această viziune ca bază pentru a descrie procesele, funcțiile și responsabilitățile.

Exigențe de curs

Acest curs explică modul în care se obțin cereri de la părțile interesate („părțile interesate”) și se transformă într-un set de cerințe ca produsele să funcționeze în cadrul sistemului care urmează să fie construit și să furnizeze cerințele detaliate pentru ceea ce este necesar pentru sistem.

Analiza și proiectarea disciplinei („proiectare”)

Scopul analizei și proiectării este de a arăta cum se va realiza sistemul. Obiectivul este de a construi un sistem care:

Execută într-un mediu de execuție specific, sarcinile și funcțiile specificate în descrierile cazurilor de utilizare

Să satisfacă toate nevoile

Este ușor de întreținut atunci când nu există schimbări în cerințele funcționale, rezultatele proiectului într-un model de analiză și proiectare are opțional un model de analiză.

Modelul de proiectare este utilizat ca o versiune conceptuală a codului sursă, afișând doar strictul necesar. Acest lucru permite utilizatorului oricărei inspecții să constate stilul în care a fost redat codul sursă.

Modelul de proiectare este redat în așa fel încât să conțină diferite diviziuni de proiectare. Aceste diviziuni sunt stocate în cadrul unor subsisteme definite.

Care subsistem are o interfață distinctă care este proiectată cu precizie. Acesta conține, de asemenea, descrieri ale modului în care obiectele din aceste clase colaborează pentru a realiza proiectarea cazurilor de utilizare.

Disciplina Implementare

Efectele aplicației sunt:

• Cu referire la subsistemele stratificate organizate pentru o aplicație, se configurează codul de organizare.
• Se realizează diferitele clase sau diviziuni de componente. Aceste componente includ

1. Fișiere sursă
2. Fișiere executabile și
3. fișiere binare

• Componentele dezvoltate ca unități sunt testate

Încorporează rezultatele produse de către executanții individuali (sau echipe), într-un sistem executabil. Sistemele sunt realizate prin intermediul componentelor aplicației.

Procesul urmărește să îndeplinească o funcție importantă, care este aceea de a defini procedura exactă care urmează să fie utilizată, pentru a reutiliza componentele care sunt fie; deja existente, fie au fost proaspăt introduse.

Acest lucru permite o posibilitate de întreținere a sistemului hassle și o îmbunătățire substanțială a șanselor de utilizare a componentelor.

Proba de disciplină

Scopurile probei de disciplină sunt:

• Verificarea interacțiunii dintre obiecte
• Verificarea integrării corecte a tuturor componentelor software
• Verificarea faptului că toate cerințele au fost executate corect
• Identificarea și asigurarea că defectele sunt rezolvate înainte de implementarea software
• Asigurarea că toate defectele sunt corectate, revizuite și închise

Concluzie

În cazul în care există defecte în proiect, corectarea lor poate presupune costuri inutile din cauza faptului că defectele nu sunt scoase la iveală în timp util.

Dacă proiectul, totuși, este testat în întregime, acest lucru ar fi benefic, deoarece orice defecte care s-ar putea strecura în proiecte pot fi identificate și constatate cât mai devreme.

Acesta va avea, la rândul său, o reducere masivă a costurilor implicate de corectarea defectelor. Aceasta este abordarea iterativă propusă de Rational Unified Process.

Pentru ca testarea să dea roade și să aibă cele mai bune rezultate posibile, testele trebuie să fie efectuate pe patru parametri de calitate și, de asemenea, trebuie să existe standarde stabilite care trebuie îndeplinite pentru ca proiectul să fie considerat că a trecut testul.

.