3.

Metodologii de dezvoltare a produselor software

3.1 Introducere
În dezvoltarea produselor software, există mai multe metodologii pe care dezvoltatorii le pot folosi
pentru conceperea, planificarea, producerea și testarea software-ului. Metodologiile de dezvoltare
software sunt abordări structurate ale unui proiect de dezvoltare software. Metodologiile eficiente
combină adesea pași bine definiți cu o filozofie de design sau proces.
Un proces de dezvoltare al unui produs de tip software este un proces de împărțire a activității de
dezvoltare a software-ului în pași sau subprocese mai mici, paralele sau secvențiale pentru a
îmbunătăți designul și/sau managementul produsului. Acest process mai este cunoscut și sub
denumirea de “Ciclu de viață al dezvoltării software” (SDLC – Software Development Life Cycle).
Majoritatea proceselor moderne de dezvoltare pot fi descrise vag ca fiind agile. Alte metodologii
include: metodologia cascadă, prototiparea, dezvoltarea iterativă și incrementală, dezvoltarea în
spirală, dezvoltarea rapidă a aplicațiilor și programarea extremă (extreme programming).
Un „model” al ciclului de viață este uneori considerat un termen mai general pentru o categorie de
metodologii, iar un „proces” de dezvoltare software un termen mai specific pentru a se referi la un
proces specific ales de o anumită organizație. De exemplu, există multe procese specifice de
dezvoltare pentru produsele software care se potrivesc modelului ciclului de viață în spirală.
Domeniul este adesea considerat un subset al ciclului de viață al dezvoltării sistemelor.
Metodologia de dezvoltare a produselor software (cunoscută și ca SDM) a apărut în anii 1960.
Potrivit lui Elliott (2004), ciclul de viață al dezvoltării sistemelor (SDLC) poate fi considerat a fi
cel mai vechi cadru metodologic formalizat pentru construirea de sisteme informaționale. Ideea
principală a acestui ciclu de viață a fost „de a urmări dezvoltarea sistemelor informaționale într-un
mod deliberat, structurat și metodic, necesitând fiecare etapă a ciclului de viață – de la începutul
ideii și până la livrarea sistemului final – să fie efectuată în mod rigid și secvenţial”. Ținta
principală a acestui cadru metodologic în anii 1960 a fost „dezvoltarea sistemelor de afaceri
funcționale la scară largă într-o epocă a conglomeratelor de afaceri la scară largă.
Cele mai importante evoluții care au marcat dezvoltarea acestui domeniu includ:
Anii 1970
• Programarea structurată (Structured programming) – începând cu anul 1969
• Metodologia de dezvoltare a sistemului Cap Gemini SDM (SDM – System Development
Methodology) – propusă de către firma Pandata
Anii 1980
• Metoda de analiză și proiectare a sistemelor structurate (SSADM - Structured systems
analysis and design method)
• Analiza cerințelor de informații/Metodologia sistemelor soft

1
Anii 1990
• Programarea orientată pe obiecte (OOP - Object-oriented programming OOP) – deși a fost
dezvoltată la începutul anilor 1960, abordarea a fost adoptată și a devenit dominantă doar
la mijlocul anilor 1990
• Dezvoltarea rapidă a aplicațiilor (RAD – Rapid application development) – începând cu
anul 1991
• Metoda de dezvoltare a sistemelor dinamice (DSDM - Dynamic systems development
method) - începând cu anul 1994
• Metodologia Scrum - începând cu anul 1995
• Team software process - începând cu anul 1998
• Rational Unified Process (RUP) - întreținută de firma IBM începând cu anul 1998
• Programare extremă (Extreme programming) – începând cu anul 1999
Anii 2000
• Manifesto for Agile Software Development – începând cu anul 2001
• Agile Unified process (AUP) – menținut din anul 2005 de către inginerul software Scott
Ambler
• Disciplined agile delivery (DAD) - considerat a fi potrivit pentru a înlocui AUP
După anul 2010
• Scaled Agile Framework (SAFe)
• Large-Scale Scrum (LeSS)
• DevOps
Trebuie menținut că începând cu DSDM în 1994, toate metodologiile de pe lista de mai sus, cu
excepția RUP, au fost metodologii agile - cu toate acestea, multe organizații, în special guvernele,
încă folosesc procese pre-agile (adesea procese de tip cascadă sau similare). Procesul de dezvoltare
al produsului software și calitatea produsului software sunt strâns legate între ele, lucru care poate
fi observant în practică din ce în ce mai des. Printre aceste metodologii de dezvoltare a produselor
software, a luat naștere și un alt proces de dezvoltare a produselor software de tip “open source”.
În cele ce urmează vom analiza cele mai esențiale aspecte ale principalelor metodologii de
dezvoltare utilizate la momentul actual.

3.2 Metodologia cascadă (Waterfall)

Metodologia cascadă este o abordare liniară de management de proiect, în care cerințele părților
interesate și ale clienților sunt adunate la începutul proiectului, iar apoi este creat un plan de proiect
secvenţial pentru a se adapta acestor cerințe. Modelul de cascadă este numit astfel deoarece fiecare
fază a proiectului se încadrează în următoarea, urmând constant în jos ca o cascadă.
Este o metodologie amănunțită, structurată și una care există de mult timp, pentru că funcționează.
Unele dintre industriile care folosesc în mod regulat modelul cascadă includ construcții, IT și

2
dezvoltarea de software. De exemplu, ciclul de viață al dezvoltării software în cascadă, sau SDLC
în cascadă, este utilizat pe scară largă pentru a gestiona proiecte de inginerie software.
Diagramele Gantt sunt instrumentul preferat pentru managerii de proiect care lucrează în metoda
cascadă. Utilizarea unei diagrame Gantt vă permite să mapați subsarcinile, dependențele și fiecare
fază a proiectului pe măsură ce acesta se deplasează prin ciclul de viață al cascadei. Un exemplu
de diagrama Gantt poate fi observant in figura de mai jos.

Un lucru care distinge metodologia cascadă de alte modele SDLC (cum ar fi Agile) este faptul că
fazele sunt efectuate secvenţial. Cu alte cuvinte, echipa de proiect trebuie să finalizeze fiecare fază
într-o anumită ordine. Diagrama de mai jos ilustreaza modul de desfasurare a unui proiect care
urmeaza metodologia de dezvoltare cascadă.

3
Metodologia cascadă a fost una dintre primele modele SDLC stabilite. Metodologia datează din
1970, atunci când Dr. Winston W. Royce a descris-o în cartea sa „Managing the Development of
Large Software Systems”. În lucrarea sa originală, Royce a specificat următoarele faze ale
metodologiei
• Stabilirea cerințelor de sistem
• Stabilirea cerințelor software
• Analiza
• Proiectarea programului
• Scrierea codului (Coding)
• Testare
• Operațiuni
Faza de cerințe de sistem și software implică colectarea și documentarea cerințelor care definesc
produsul. Acest proces implică de obicei părți interesate, cum ar fi clienții și managerii de proiect.
Faza de analiză presupune pași precum analiza cerințelor pentru identificarea riscurilor și
documentarea strategiilor.
Faza de proiectare se concentrează pe proiectarea arhitecturii, a logicii de afaceri și a conceptelor
pentru software. Faza de proiectare este urmată de faza de scriere a codului care implică scrierea
codului sursă pentru software pe baza designului planificat.
Faza de testare se referă la testarea software-ului pentru a se asigura că acesta corespunde
așteptărilor. Ultima fază, operațiunile, implică implementarea aplicației, precum și planificarea
suportului și întreținerea.
Avantajele metodologiei
Waterfall oferă un cadru sistematic și previzibil care ajută la reconcilierea așteptărilor, la
îmbunătățirea planificării, la creșterea eficienței și la asigurarea controlului calității. În plus,
documentația cascadă oferă o intrare pentru persoanele din afara proiectului pentru a construi
software-ul fără a fi nevoiți să se bazeze pe creatorii acestuia, ceea ce este util dacă trebuie să
aduceți asistență externă sau să implementați modificări echipei de proiect.
Dezavantajele metodologiei
Limitările structurale ale metodologiei cascadei pot introduce unele probleme pentru proiectele cu
multe incertitudini. De exemplu, fluxul liniar al metodologiei necesită ca fiecare fază să fie
finalizată înainte de a trece la următoarea, ceea ce înseamnă că metodologia nu acceptă revizuirea
și rafinarea datelor bazate pe informații noi care pot apărea mai târziu în ciclul de viață al
proiectului. Un exemplu specific al acestei limitări este concentrarea metodologiei pe definirea
tuturor cerințelor la începutul proiectului. La urma urmei, este posibil ca părțile interesate să nu
știe totul despre proiect de la început sau își pot schimba opinia mai târziu despre ceea ce ar trebui
să facă de fapt produsul sau ce segment de clienți încearcă să deservească.

4
Pe de altă parte, un proiect cu cerințe bine definite și stabile poate beneficia de cascadă deoarece
asigură stabilirea și documentarea cerințelor cât mai curând posibil.
Un alt dezavantaj al metodologiei cascadă poate fi implementarea cu întârziere a software-ului
propriu-zis, ceea ce poate duce la un produs care nu se corelează cu așteptările părților interesate.
De exemplu, dacă dezvoltatorii au înțeles greșit ideea clientului cu privire la o caracteristică
specifică din cauza cerințelor prost definite, produsul final nu se va comporta conform așteptărilor.
Testarea tardivă poate duce, de asemenea, la găsirea unor probleme sistemice prea târziu în
dezvoltarea proiectului, când este mai dificil să corectați designul.

3.3 Metodologiile agile

„Dezvoltare agilă de software” se referă la un grup de cadre de dezvoltare software bazate pe
dezvoltare iterativă, în care cerințele și soluțiile evoluează prin colaborare între echipe
interfuncționale care se organizează într-un mod autonom. Termenul a fost inventat în anul 2001,
atunci când a fost formulat “Agile manifesto for software development”.
Dezvoltarea agilă de software folosește dezvoltarea iterativă ca bază, dar susține un punct de
vedere mai ușor și mai centrat pe oameni decât abordările tradiționale. Procesele agile
încorporează în mod fundamental iterația și feedback-ul continuu pe care îl oferă pentru a rafina
și a livra succesiv un sistem software.
Echipele care folosesc metodologii de dezvoltare agile urmăresc minimizarea riscurile (cum ar fi
erorile, depășirile de costuri și cerințele în schimbare) atunci când adaugă noi funcționalități. În
toate metodele agile, echipele dezvoltă software-ul în iterații care conțin mini-incremente ale noii
funcționalități.
Principiul de baza al metodologiilor agile poate fi observat in figura de mai jos.

5
Metodologiile care urmează principiile dezvoltării agile includ:
• Metoda de dezvoltare a sistemelor dinamice (Dynamic systems development method -
DSDM)
• Metoda Kanban
• Metodologia Scrum
• Metodologia Crystal
• Atern
• Abordarea “Lean software development”
Avantajele metodologiilor agile
Avantajul principal al dezvoltării agile de software este că permite ca software-ul să fie lansat în
iterații. Versiunile iterative îmbunătățesc eficiența, permițând echipelor să găsească și să repare
defectele și să alinieze așteptările de la început. De asemenea, permit utilizatorilor să realizeze
beneficiile software mai devreme, cu îmbunătățiri progresive frecvente.
Dezavantajele metodologiilor agile
Metodele de dezvoltare agile se bazează pe comunicarea în timp real, astfel încât utilizatorii noi
deseori le lipsește documentația de care au nevoie pentru a fi la curent. Acestea necesită un
angajament enorm de timp din partea utilizatorilor și necesită multă muncă, deoarece dezvoltatorii
trebuie să finalizeze pe deplin fiecare caracteristică în fiecare iterație pentru aprobarea
utilizatorului.
Alte dezavantaje ale metodologiilor agile includ: implementarea rigidă a metodologiilor agile,
tranziția concentrării de la practici mai bune de dezvoltare a software-ului la preocupări privind
certificarea, utilizarea greșită a principiilor și practiciilor agile, un sentiment de micromanagement
din partea scrum maste-ului, obiective de timp nerealiste pentru sprinturi și așteptări nerealiste ale
6
standup-urilor zilnice. Și mai îngrijorător, discuțiile recente privind eficacitatea dezvoltării agile
s-au concentrat pe efectele pe termen lung ale implementarii si utilizarii metodologiilor agile
asupra bunăstării dezvoltatorilor, evidențiind astfel riscul de „agile burnout”, o stare de burnout
specifică dezvoltatoriilor care lucrează cu metodologii agile.
Metodologia Scrum
Conform celui de-al 14-lea Raport privind starea Agile, metodologia Scrum este cea mai populară
metodologie agilă de dezvoltare folosită pentru a dezvolta produse și sisteme complexe. Termenul
Scrum provine de la jocul de rugby. La fel ca într-o echipă de rugby, echipele Scrum lucrează
împreună ca una singură. Ei învață prin experiențe, se autoorganizează, reflectă asupra succeselor
și pierderilor lor pentru a se îmbunătăți continuu. Scrum crește semnificativ productivitatea și
reduce timpul de lansare pe piață în comparație cu procesele tradiționale „în cascadă”.
Agile este o mentalitate și un set de principii bazate pe manifestul Agile, există multe metodologii
diferite pentru a implementa filozofia Agile. Scrum este un cadru de proces care implementează
principii agile. Scrum este unul dintre cele mai populare cadre Agile utilizate în managementul
proiectelor. Este împărțit în 3 componente principale ale: Rolurilor (Roles), Artefactelor (Artifacts)
și Casetelor de timp (Time boxes).
Principalele elemente ale metodologiei Scrum sunt prezentate în figura de mai jos

7
3.4 Metodologia DevOps
DevOps nu este doar o metodologie de dezvoltare, ci și un set de practici care susțin o cultură
organizațională. Implementarea DevOps se concentrează pe schimbarea organizațională care
îmbunătățește colaborarea între departamentele responsabile pentru diferite segmente ale ciclului
de viață al dezvoltării, cum ar fi dezvoltarea, asigurarea calității și operațiunile.
Denumirea DevOps vine de la combinarea termeniilor „dezvoltare” și „operațiuni”, termini care
reprezinta cele două departamente care funcționează în mod normal independent unul de celălalt
in cadrul unei firme. Ca metodologie, DevOps se concentrează pe stabilirea colaborării între aceste
echipe împărțite în mod tradițional pe parcursul ciclului de viață al dezvoltării software.
Combinarea practicilor lor poate duce la o eficiență îmbunătățită, o dezvoltare mai rapidă a
software-ului și o calitate mai bună a produsului.
Cel mai adesea, DevOps este caracterizat de următoarele principii cheie: proprietate comună,
automatizarea fluxului de lucru și feedback rapid. Schema de principiu a metodologiei DevOps
poate fi observată in figura de mai jos

DevOps se concentrează pe îmbunătățirea timpului de lansare pe piață, scăderea ratei de eșec a

noilor versiuni, scurtarea timpului de livrare între remedieri și minimizarea întreruperilor,
maximizând în același timp fiabilitatea. Pentru a realiza acest lucru, organizațiile DevOps își
propun să automatizeze implementarea continuă pentru a se asigura că totul se întâmplă fără
probleme și în mod fiabil. Companiile care folosesc metode DevOps beneficiază de reducerea
semnificativă a timpului de lansare pe piață și de îmbunătățirea satisfacției clienților, a calității
produselor și a productivității și eficienței angajaților.
Ce este CI/CD? Integrarea continuă și livrarea continuă
Livrarea rapidă a software-ului este esențială pentru rularea eficientă a aplicațiilor în cloud.
Integrarea continuă (CI) se referă la fuzionarea frecventă a unui nou software, utilizându-se o
singură linie de cod. Livrarea continuă se referă la producția de software împachetat în afara
codului în cicluri frecvente. De asemenea, implementarea continuă se referă la implementarea de
software împachetat pentru o platformă runtime în cicluri periodice. Apariția CI/CD a modificat
8
drastic procesul tradițional de dezvoltare a aplicaţiilor. Procesul bazat pe CI/CD implică DevOps
- schimbarea paradigmei, care aduce dezvoltatorii, inginerii QA și managerii de operațiuni laolaltă,
pe o singură platformă.
Dar este posibil ca procesul de dezvoltare a aplicațiilor pe baza CI/CD să fie îmbunătățit și mai
mult? Cea mai modernă abordare este să utilizați containerizarea, pentru un plus de flexibilitate și
beneficii.
Integrarea continuă (CI):
Cel mai important pas pentru funcționarea continuă a software-ului este integrarea continuă (CI).
CI este o practică de dezvoltare, în care dezvoltatorii își confirmă modificările de cod (de obicei,
mici și incrementale) într-un repository sursă centralizat, care declanșează un set de generări și
testări automate. Acest repository le permite dezvoltatorilor să capteze erorile de codare din timp
și automat, înainte de a fi transferate în producție. Procesul de integrare continuă implică, de obicei,
o serie de pași, de la confirmarea codului până la efectuarea automată a unei analize
continue/statice de bază, captarea dependențelor și, în final, generarea software-ului și efectuarea
unor teste de bază înainte de generarea versiunii finale. Sistemele de gestionare a codurilor sursă,
cum ar fi Github, Gitlab etc., oferă integrarea webhookurilor, la care se pot abona instrumente CI
precum Jenkins pentru a începe să ruleze versiuni și teste automate după fiecare încărcare a
codului.
Livrarea continuă (CD):
Livrarea continuă începe acolo unde se termină povestea noastră despre integrarea continuă. CD
automatizează trimiterea aplicațiilor către mediile de infrastructură din cloud. Majoritatea
echipelor lucrează cu mai multe medii de dezvoltare și de testare, altele decât serverul de producție
principal. Livrarea continuă va asigura un mod automatizat de propagare a modificărilor de cod
testate în toate mediile cloud.
Avantajele metodologiei DevOps
Adoptarea DevOps pentru a susține întregul ciclu de viață al dezvoltării software-ului - cu accent
pe flexibilitate și eficiență, indiferent de funcție, oferă o serie de beneficii:
• Creșterea vitezei: cu un model DevOps flexibil, tehnologia este optimizată în funcție de
necesitățile curente ale ciclului de viață. În multe cazuri, DevOps utilizează cele mai
recente tehnologii machine learning și inteligenţa artificială pentru a obține viteză. De fapt,
un termen recent inventat, AIOps, se referă la utilizarea AI în operațiunile IT. DevOps pune
accentul și pe automatizare și integrarea/livrarea continuă, scutind personalul de o serie de
activități manuale, pentru a se concentra asupra inovării. În ceea ce privește dezvoltarea,
inginerii pot să își atingă obiectivele privind codarea mai rapid sau să colaboreze mai
eficient. Pe partea de operațiuni, administratorii de sistem pot utiliza frameworkuri de
automatizare pentru a aloca și actualiza cu ușurință noi aplicații și infrastructuri.
• Calitate: datorită creșterii vitezei, DevOps deschide noi posibilități de creștere a calității și
fiabilității. Acest lucru începe, în ceea ce privește dezvoltarea, cu o colaborare mai rapidă
și instrumente mai bune pentru rezolvarea și integrarea problemelor. În ceea ce privește

9
 operațiunile, actualizările mai mici și mai frecvente permit o mai mare stabilitate, ceea ce
îmbunătățește calitatea generală a experienței utilizatorilor.
• Securitate: utilizarea DevOps oferă mai multe niveluri pentru îmbunătățirea securității
generale. Din motive practice, DevOps include uneori integrarea echipelor de securitate.
Astfel, se creează un model denumit DevSecOps, care se ocupă și de securitate, în afară de
dezvoltare și operațiuni. Pentru a detalia mai mult, viteza DevSecOps permite corecții,
audituri și analize rapide, cu ajutorul inteligenței artificiale, conformității automate și
gestionării automate a resurselor.
• Scalabilitate: Resursele flexibile, automatizarea și capacitatea de a susține ciclul complet
de dezvoltare a software-ului înseamnă că infrastructura este pregătită pentru a susține
scalarea după necesități. Deoarece scalarea atinge numeroase elemente, susținerea unei
viziuni holistice asupra tehnologiei ajută la scalarea eficientă, gestionând totul, de la
gestionarea resurselor până la implementarea corecțiilor.
Dezavantajele metodologiei
• Unii clienți nu doresc actualizări continue ale sistemelor lor.
• Unele industrii au reglementări care necesită teste extinse înainte ca un proiect să poată
trece la faza de operațiuni.
• Dacă diferite departamente utilizează medii diferite, problemele nedetectate pot intra în
producție.
• Unele atribute de calitate necesită interacțiune umană, ceea ce încetinește sistemul de
livrare.

10
Bibliografie
https://en.wikipedia.org/wiki/Software_development_process
https://www.synopsys.com/blogs/software-security/top-4-software-development-methodologies/
https://www.indeed.com/career-advice/career-development/software-development-
methodologies
https://builtin.com/software-engineering-perspectives/waterfall-methodology
https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/
https://www.scrum.org/resources/blog/whats-difference-between-agile-scrum
https://www.forbes.com/sites/cognitiveworld/2019/08/23/the-end-of-agile/
https://medium.com/agileinsider/agile-is-dead-mckinsey-just-killed-it-547df8c6c9df
https://ronjeffries.com/articles/018-01ff/abandon-1/
https://www.wrike.com/agile-guide/faq/what-is-agile-burnout/
https://www.knowledgehut.com/blog/agile/how-to-eliminate-burnout-and-make-agile-teams-
more-productive
https://en.wikipedia.org/wiki/DevOps
https://www.oracle.com/ro/devops/what-is-devops/

11