Software Quality Assurance (SQA)

SQA incorporează revizia produselor software livrate și activitățile din cadrul ciclului de viață în care au fost produse. Auditarea poate fi realizată pentru a asigura faptul că produsele și procesele sunt realizate conform politicilor și procedurilor de dezvoltare software din cadrul organizației și, de asemenea, conform standardelor industriale.

Conform cu IEEE Standard Glossary of Software Engineering Terminology, SQA este definită ca: * o planificare și un tipar sistematic al acțiunilor care trebuie realizate pentru furnizarea încrederii că un produs se va conforma cerințelor tehnice stabilite * un set de activități proiectate pentru evaluarea procesului prin care produsele sunt dezvoltate

În general, scopul unei organizații este crearea unui SQAP (Software Quality Assurance Plan) care să asigure un nivel de calitate a produsului.

Din standardul IEEE 730-1998, structura unui SQAP conține următoarele secțiuni:

# Scopul documentului (Purpose) # Documente referite # Management # Documentație # Standarde, practici, convenții, metrici # Revizii și audituri # Managementul riscului # Raportarea problemelor și acțiuni de corecție # Utilitare, tehnici și metodologii # Controlul furnizorului # Training # Colectarea înregistrărilor, mentenanța

Exerciții

* Descrieți sumar conțintul unui SQAP pentru proiectul vostru (referiți-vă doar la secțiunile 3-9).

Finalizarea unui proiect

Un proiect poate sa se finalizeze intr-unul din urmatoarele cazuri: * s-a terminat - cazul cel mai fericit * a fost oprit motive de afaceri - exista lucruri mai bune care pot fi facute cu banii respectivi motive tehnice - intre timp exista deja un proiect care este mai eficient sau tehnologia folosita este neadecvata sau nu mai exista cerere motive de timp - timpul alocat proiectului s-a terminat motive de cost - proiectul a devenit prea scump si nu mai exista finantare motive de calitate - stadiul curent arata ca proiectul este facut prost si nu respecta anumite criterii motive politice - proiectul intra in conflict cu politica proprie a unei anumite persoane

Feluri de terminare a unui proiect: * extinctie - proiectul se termina cu succes, esec sau a fost oprit; nu se mai lucreaza la proiectul respectiv * terminare prin aditie - proiectul a avut succes si echipa care se ocupa de software development devine echipa de operatiuni care se ocupa de mentenanta produsului * terminare prin integrare - proiectul se termina cu succes si bunurile si oamenii sunt integrati inapoi in companie unde incepe alt proiect; modul cel mai frecvent * terminare prin infometare - resursele dedicate proiectului pana cand proiectul ajunge intr-un impas, nu se mai lucreaza la el, dar nici nu a fost oprit; sugestia este ca proiectul sa fie oprit cat mai repede si oamenii reasignati

Procesul de terminare # se ia decizia de terminare # se comunica decizia la toti cei interesati # se identifica activitatile finale care trebuie completate # se obtin aprobarile de la clienti si sponsori # se face PPA # se celebreaza inchiderea proiectului # se reasigneaza persoanele # se publica raportul final # se reasigneaza echipamentul # se efectueaza inchiderea administrativa si financiara

Activitati de terminare

O metoda eficienta de a asigura finalizarea completa si coerenta a proiectului este sa se formeze inca de la inceputul proiectului un checklist cu activitati si elemente ce trebuie rezolvate inainte ca proiectul sa poata fi considerat finalizat. Un exemplu de astfel de lista poate sa fie urmatoarea:

* Terminarea proiectului software * Completarea elementelor nefinalizate * Controlul calitatii * Pregatirea pentru predarea sistemului * Sarbatorirea cu echipa * Eliberarea echipei * Folosirea de PPA pentru a deveni un manager mai bun

Acest checklist poate sa evolueze si noi elemente pot fi adaugate la el pe masura ce proiectul avanseaza.

Un alt checklist de lucruri care trebuie urmarite pentru a considera ca proiectul este terminat * revizuirea sistemului impreuna cu help desk * intalnirea cu staff-ul operational care urmeaza sa preia software-ul * revizuirea cerintelor de training pentru staff-ul operational * primirea sign-off-ului de la staff-ul operational * completarea si distribuirea rapoartelor de perfromanta * completarea si distribuirea documentatiei sistemului * completarea audit-urilor de calitate * completarea audit-urilor de vanzare * completarea revizuirii performantei sau oferirea detaliilor despre performanta membrilor proiectului * distribuirea membrilor echipei a chestionarelor legate de performanta project managementului * primirea sign-off-ului de acceptare de la client si acceptarea formala a tuturor livrabilelor proiectului * inchiderea contractelor cu vanzatorii

Aceasta lista nu este neaparat completa, la anumite proiecte ar putea sa contina si alte elemente pe cand la altele ar putea sa contina mai putine, ea este doar un exemplu.

In cazul in care se foloseste un bug tracking sau issue tracking, trebuie ca toate problemele sa fie rezolvate inainte de finalizarea proiectului chiar daca ele nu au fost incluse in specificatii.

In cazul in care nu se poate acest lucru, cei care predau proiectul trebuie sa se asigure ca problemele ramase deschise sunt de prioritate scazuta si nu au un impact major asupra functionalitatii. Nu trebuie sa se lase activitati nerezolvate in seama celui care urmeaza sa preia proiectul.

Exerciții

* Preparati un checklist pentru proiectul vostru. Argumentati! * La terminarea unui proiect, ce se intampla cu lectiile invatate, cum poate beneficia urmatorul lider de proiect de experientele proiectului finalizat?

Post-Performance Analysis (PPA)

Post-Performance Analysis folosește un set de tehnici de evaluare a abordarilor posibile pentru îmbunătățirea unui proiect. În general se stabiliesc un set de standarde asociate proiectului urmând apoi construirea de metode care să conducă la atingerea acestor standarde.

În general, scopul PPA este de a colecta măsurători pentru metricile proiectului și de a defini strategii care vor conduce la obținerea de performanțe superioare. Se recomandă ca aceste măsurători să fie realizate periodic și să fie aplicate rapid (cât timp “amintirile sunt proaspete”). În general, noile lecții învățate se aplică după faze sau milestone-uri majore.

În general, procesul PPA presupune următorii pași: # trimiterea unei invitații echipei pentru a propune o întâlnire PPA, incluzând instrucțiuni de asamblare a tuturor datelor disponibile (date dimensionale - cât, cât de mare, cât de frecvent; lecții învățate; solicitări de schimbare; date referitoare la timp și efort - cost și efort pentru fiecare componentă WBS comparate cu estimările inițiale) # datele sunt colectate individual și permite persoanelor mai analitice să pregătească un răspuns fără a fi deranjate de persoane vocale care ar domina întâlnirea # asamblarea unei echipe pentru întâlnire - întâlnirea trebuie să fie scurtă și focusată; fiecare ar trebui să știe ce și cum s-a întâmplat; scopul nu este de a găsi vinovați ci de a învăța moduri noi în care procesul poate fi îmbunătățit data viitoare # categorizarea datelor și materialelor # arhivarea sau eliminarea datelor și materialelor # publicarea unui sumar PPA care să sumarizeze descoperirile

În general, se folosește un chestionar pentru colectarea informațiilor. De obicei, acesta are conținut diferit între team leaderi și team memberi.

Câteva întrebări de chestionar sunt cele de mai jos:

* Identificați lucrurile care au mers bine în cadrul acestui proiect. * Identificați lucrurile care au mers prost în cadrul acestui proiect. * Ce evenimente neprevăzute au afectat pozitiv sau negativ desfășurarea proiectului? * În cadrul acestui proiect, ce lucruri ați face diferit dacă ar fi repornit? * Descrie un lucru pe care tu l-ai fi putut realiza personal pentru a îmbunătăți calitatea produsului obținut din cadrul acestui proiect. * Ai fost informat despre ceea ce se așteaptă de la tine în cadrul acestui proiect? * Au fost rolurile membrilor echipei definite clar? * (Echipa) a făcut tot ce se putea face pentru a duce la bun sfârșit acest proiect? * Cum s-a comportat echipa în ansamblul său? * Care a fost componenta cea mai satisfăcătoare din cadrul proiectului?

Un exemplu complet de chestionar găsiți aici

Exerciții

* Răspundeți la întrebările de mai sus pentru proiectul vostru.

Licențe software
mps/old/2008-2009/laboratoare/laborator-12.txt · Last modified: 2016/09/28 17:08 (external edit)
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0