Ciclul de Viață al unui Produs Software

Ce este un proiect software?

Reuşita unui manager de proiect este condiţionată de finalizarea proiectelor la timp, în bugetul alocat, şi să se asigure că are clienţi fericiţi cu ceea ce s-a livrat. Deşi sună simplu, multe proiecte în lumea reală nu sunt terminate la timp, costă prea mult sau nu satisfac nevoile clienţilor.

“A Guide to the Project Management Body of Knowledge” (ediţia a treia, publicată de Project Management Institute, 2004) - denumit în continuare PMBOK - defineşte un proiect ca fiind “un efort temporar întreprins pentru a crea un produs unic sau un serviciu . “ În continuare vom detalia această definiţie pentru a clarifica ceea ce este un proiect şi ceea ce nu este.

În primul rând, un proiect este temporar. Un proiect poate avea o durată de doar o săptămână sau s-ar putea merge de ani de zile, dar fiecare proiect are o dată de sfârşit. S-ar putea sa nu ştii data când proiectul se va închide, dar ea e acolo, undeva în viitor. Proiecte nu sunt ca şi operaţiunile în curs de desfăşurare, deşi cele două au multe în comun. Operaţiunile în curs de desfăşurare, după cum sugerează şi numele, se duc la infinit, nu se stabileşte o dată de sfârşit. Printre exemple se numără majoritatea activităţilor de contabilitate şi de departamentele de resurse umane. Oamenii care conduc operaţiunile în curs ar putea, de asemenea, gestiona proiecte, de exemplu, un manager al unui departament de resurse umane pentru o organizaţie mare ar putea planifica un târg de recrutare echitabil. Cu toate acestea, proiectele se deosebesc de operaţiunile în curs, având dată de sfârşit ştiută, cum ar fi data târgului de recrutare. Apoi, un proiect este un efort. Resursele, cum ar fi oamenii şi echipamentele, trebuie să lucreze. Străduiala este efectuată de către o echipă sau o organizaţie, şi, prin urmare, proiectele au un sentiment de a fi intenţionate, evenimente planificate. Proiecte de succes nu se realizează spontan; o anumită cantitate de pregătire şi planificare este necesară mai întâi.

În cele din urmă, fiecare proiect creează un produs unic sau un serviciu. Aceasta este livrabil pentru proiect şi motivul pentru care proiectul a fost întreprins. O rafinărie care produce benzină nu produce un produs unic. Ideea, în acest caz, este de a produce o marfă standardizată; de obicei, nimeni nu doreşte să cumpere benzină de la o staţie care este semnificativ diferită de benzina la un altă staţie. Pe de altă parte, avioanele comerciale sunt produse unice. Deşi toate avioanele Boeing 777 ar putea arăta la fel pentru majoritatea dintre noi, fiecare este, de fapt, extrem de personalizat pentru nevoile cumpărătorului său.

Ciclul de viaţă al unui produs software

Ciclul de viaţă al unui produs software este o structură impusă în procesul de dezvoltare al unui produs software. Există mai multe modele de astfel de procese, iar fiecare abordare descrie o varietate de sarcini sau activităţi care au loc în timpul procesului.

Un model de ciclu de viaţă software descrie etapele semnificative sau activităţile unui proiect software de la concepţie până când produsul respectiv este retras. Acesta specifică relaţiile dintre etapele proiectului, inclusiv criteriile de tranziţie, mecanismele de feedback, milestone-uri, liniile de bază, recenzii, şi rezultatele. De obicei, un model de ciclu de viaţă adresează fazele unui proiect software: etapa cerinţelor, proiectarea, implementarea, integrarea, testarea, mentenanţa. O mare parte din motivaţia folosirii unui model de ciclu de viaţă este de a oferi structura pentru a evita problemele de genul “hacker indisciplinat” sau birocrat IT (care este de zece ori mai periculos decât un hacker indisciplinat). Ca întotdeauna, este o chestiune de a alege instrumental potrivit pentru muncă, decât a alege un ciocan şi tratarea tuturor sarcinilor ca fiind cuie.

Modelele de ciclu de viaţă cele mai frecvente sunt:

• Waterfall model. Cel mai puţin flexibil model de ciclu de viaţă. Totuşi este bine adaptat la proiecte care au o arhitectura bine definită şi interfaţa cu utilizatorul şi cerinţele de performanţă stabilite. Modelul cascada funcţionează pentru anumite domenii problemă, în special cele în care cerinţele sunt bine înţelese în avans şi este puţin probabil ca acestea să se schimbe în mod semnificativ pe parcursul dezvoltării. Într-un model strict cascada, după ce fiecare fază este terminată, se trece la următoarea. Review-uri pot fi făcute înainte de a trece la următoarea faza, care permite posibilitatea modificărilor (care poate implica un proces formal de control al schimbării). Review-urile pot fi, de asemenea, utilizate pentru a se asigura că faza este într-adevăr completă; criteriile de faza de finalizare sunt adesea menţionate ca o “poarta” pe care proiectul trebuie să o treacă, pentru a trece la următoarea fază. Cascada descurajează revizitarea şi revizuirea oricărei faze anterioare după ce a fost completată. Această lipsă de flexibilitate într-un model pur cascada a fost o sursă de critică din partea altor modele mai flexibile.

• Spiral Model. Caracteristica cheie a unui model în spirală este gestionarea riscurilor în etape regulate în ciclul de dezvoltare. E potrivit în special pentru sisteme complexe la scară largă. Pentru fiecare parcurgere a spiralei activităţile principale sunt următoare:

-formulează planuri pentru: identificarea obiectivelor de software, selectate pentru a pune în aplicare programul, clarificarea restricţiilor de dezvoltare a proiectului;

-Analiza riscului: o evaluare analitică a programelor selectate; să ia în considerare modul în care se poate identifica şi elimina riscul;

-punerea în aplicare a proiectului: punerea în aplicare a dezvoltării de software şi verificarea;

-evaluare a clientului: evaluarea muncii de dezvoltare, propuneri de amendamente, planuri pentru a formula pasul următor.