Metodologije razvoja softvera – uvod u Waterfall i Agile
SDLC (životni ciklus razvoja softvera, ili u originalu Software Development Life Cycle) predstavlja proces koji se primenjuje tokom razvoja softverskih aplikacija i uključuje niz planiranih aktivnosti i faza. On omogućava timovima i organizacijama da sistematično upravljaju svim aspektima razvoja i dokumentuju ih, što pomaže u smanjenju rizika i optimizaciji resursa.
Ovaj proces se može značajno razlikovati s obzirom na odabranu metodologiju razvoja, a samim tim se u njemu menja i mesto i uloga testiranja.
Zato ćemo u ovom tekstu objasniti dva osnovna modela razvoja softvera – Waterfall i Agile, a u sledećem pobliže analizirati kakvu funkciju i značaj u njima ima proces testiranja.
A ako o ovim temama želiš da saznaš više, na pravom si mestu. Pročitaj više o tome kako te SixCube University može pripremiti za karijeru u IT
industriji.
SDLC u Waterfall metodologiji
Waterfall metodologija predstavlja tradicionalni model koji je dugo bio dominantan u softverskoj industriji. Naziv „Waterfall“, ili „vodopad”, potiče od sekvencijalnog toka faza projekta koje „teku“ jedna u drugu, poput vode koja pada niz stepenice vodopada.
Ovaj model je linearan i zahteva završetak jedne faze pre nego što se pređe na sledeću. Konkretna terminologija i struktura ovih faza može donekle da varira na različitim projektima, ali njihov najčešći redosled izgleda ovako:
Analiza zahteva – Definisanje jasnih i detaljnih zahteva pre početka razvoja.
Dizajn – Planiranje arhitekture softvera i dizajniranje rešenja na osnovu definisanih zahteva.
Razvoj – Kodiranje i konfiguracija softverskih komponenti prema tehničkim specifikacijama.
Testiranje – Verifikacija softvera koja treba da osigura ispunjavanje postavljenih zahteve.
Deployment – Implementacija i aktivacija softvera u produkcijskom okruženju (jednostavnije rečeno, „puštanje u rad“)
Održavanje – Pružanje podrške i ažuriranja softvera nakon njegovog puštanja u rad.
Da ponovimo, ovaj model zahteva da se jedna faza u potpunosti završi pre nego što se započne sledeća. Kao kod vodopada, gde se voda ne
vraća na „gore“, tako je i u Waterfall modelu razvoja softvera „povratak“ iz kasnije faze u prethodnu vrlo kompleksan ili čak neizvodljiv.
Izvor: business.adobe.com
Prednosti Waterfall modela
Ono što ide u prilog Waterfall modelu je jednostavnost, predvidljivost, lakoća razumevanja faza i njihove primene. Model omogućava lako planiranje i raspodelu resursa zahvaljujući jasno definisanim fazama i očekivanjima za svaku fazu. Ovo olakšava upravljanje projektom, jer se zahtevi i obim rada ne menjaju.
Waterfall je posebno efikasan u projektima sa precizno definisanim i dobro razumljivim zahtevima za koje se ne očekuje da će biti modifikovani, što omogućava timovima da se u potpunosti fokusiraju na ispunjavanje tih zahteva.
Mane Waterfall modela
Ipak, problem sa Waterfall modelom je što se on mnogo teže prilagođava projektima koji treba da budu fleksibilni i u kojima se očekuje da se zahtevi menjaju tokom razvoja, ali i nakon puštanja u rad.
Waterfall se vrlo teško adaptira na takvu vrstu promena. Ukoliko dođe do revizije zahteva ili do otkrivanja grešaka u kasnijim fazama, povratak na prethodne faze može biti veoma skup i vremenski zahtevan. Ovo može dovesti do značajnih kašnjenja i povećanja troškova.
Precizna identifikacija grešaka i njihovih uzroka, a zatim rekonfiguracija, redizajniranje i ponovno kodiranje, mogu potrošiti mnogo vremena i resursa, naročito ukoliko su naknadno primećene greške i odstupanja značajna.
Takođe, unošenje neophodnih promena, posebno u kompleksnim sistemima, mogu izazvati lančane reakcije novih neočekivanih promena i grešaka s obzirom na međuzavisnost određenih komponenti softvera od drugih. Sve u svemu, „vraćanje“ na prethodne faze u ovom modelu može biti vrlo neugodan, skup i naporan posao.
Na kraju, ovaj model ne podstiče stalnu interakciju sa krajnjim korisnicima, kao ni analizu i implementaciju povratne informacije dobijene od njih, što može rezultirati softverskom aplikacijom koja prosto ne odgovara korisničkim potrebama.
SDLC u Agile metodologiji
Rame uz rame sa Waterfall-om, početkom 2000-tih godina, na značaju počinje da dobija i Agile metodologija, koja je danas široko prihvaćena u IT industriji. Ovo, naravno, nisu jedine dve metodologije, ali su vrlo pogodni primeri za objašnjavanje nekih važnih razlika u mogućim pristupima testiranju.
Agile metodologija je pristup razvoju softvera koji se odvija u kratkim, ponavljajućim ciklusima, pri čemu se u svakom ovom ciklusu prolazi kroz praktično sve faze kroz koje prolazi jedan Waterfall projekat.
Kako joj samo ime kaže, ona podrazumeva agilnost prilikom procesa razvoja, ali i mnogo više od toga. U Agile modelu, prioritet su funkcionalan softver, česte nadogradnje i mogućnost da se odgovori na promene zahteva, pre nego jasno utvrđen plan i gomilanje dokumentacije. Među glavnim principima ove metodologije su jednostavnost, timski rad, fokus na korisnika, samoorganizacija i održivi razvoj.
Agile vs Waterfall – objašnjenje kroz analogiju
Možda najbolji način da se objasni razlika između dva osnovna pristupa razvoju softvera jeste uz pomoć analogije, baš onako kako je i autoru teksta to svojevremeno objašnjeno kada se mučio da ove nepoznate izraze smesti u smislen koordinatni sistem.
Analogija ide ovako: zamisli da je tvoj tim dobio zadatak da napravi automobil. Po Waterfall-u, to bi značilo da tim razvija jednu po jednu komponentu, od početka do kraja. Dakle, ako tim kreće od točka, postoji detaljan plan kako se pravi čitav točak, tim se drži tog plana, sve dok čitav točak nije gotov. Zatim se pravi drugi točak, pa treći, pa onda vrata, sedišta itd. (naravno, ovaj primer je samo ilustrativne prirode jer se srećom automobili ne dizajniraju počevši od točkova i sedišta). Prelazak na sledeću fazu – testiranje – se dešava tek kad je čitav proizvod završen.
U Agile metodologiji, ovaj automobil neće biti pravljen deo po deo po istom principu, nego će odmah biti napravljen čitav, ali u minijaturnoj, primitivnoj verziji, koju zatim treba nadograđivati i poboljšavati do finalnog proizvoda. U analogiji sa automobilom to bi značilo, na primer, da je tim u prvom ciklusu napravio skejtbord koji ide na baterije, koji će se nakon svakog sledećeg ciklusa sve više približavati izgledu i funkcionalnosti zamišljenog automobila.
Agile projekti, kao što smo spomenuli, prolaze kroz manje-više iste faze kao i Waterfall projekti, samo što se „hod“ od prve do poslednje faze dešava neuporedivo brže i odvija u ponavljajućim ciklusima – „sprintovima“, koji najčešće traju od 2 do 4 nedelje. Takođe, pre prelaska na naredni sprint, Agile podrazumeva i fazu revizije svega urađenog u prethodnom ciklusu.
Dakle, posmatrajući samo npr. prvi sprint i samo faze testiranja i razvoja, testiranje dolazi posle razvoja, i po tome se Agile ne razlikuje bitno od Waterfall modela. Ali zato razvoj (kao i analiza i dizajn) u drugom sprintu dolazi nakon testiranja u prvom, što iako je formalno „povratak“ u prethodnu fazu, suštinski je napredak u razvoju projekta. Svaki sprint pruža priliku za unapređenje proizvoda i integraciju povratnih informacija od korisnika, što vodi ka boljem i prilagođenijem softverskom rešenju.
Izvor: asana.com
Prednosti Agile metodologije
Danas, Agile metodologija mnogo više odgovara načinu na koji funkcioniše softverska industrija. U našoj analogiji, naručiocima i klijentima mnogo više znači da vide „skejtbord“ nego „točak“, da ga testiraju, isprobaju i daju povratnu informaciju koja će usmeriti projekat dalje.
U dinamičnoj eri koja stavlja veliki akcenat na inovacije, podrazumeva se da će softver biti fleksibilan i prilagodljiv s obzirom na evoluirajuće potrebe korisnika i tržišta. Agile omogućava brzo otkrivanje grešaka, nepoklapanja sa očekivanjima korisnika i drugih problema u radu, kao i brzo ispravljanje svih ovih nedostataka.
U Agile metodologiji, ne čeka se da svi akteri budu besprekorno zadovoljni da bi softver bio pušten u produkciju, jer se podrazumeva da će konstantan rad na njemu biti nastavljen, a povratne informacije koje dolaze direktno od korisnika, pozitivne i negativne, mogu samo pomoći da svaka sledeća verzija bude još bolja.
Mane Agile metodologije
Da bi uopšte funkcionisao, svaki Agile projekat zahteva intenzivnu i konstantnu komunikaciju, kako u samom timu, tako i eksterno sa klijentima. Dalje, zbog fleksibilnosti ovog pristupa, poseban izazov je napraviti dobar plan (naročito finansijski) koji će uspešno proceniti troškove, resurse i vremenske okvire, ali i u isto vreme ostaviti dovoljno slobode za revizije i adaptacije.
Generalno, većina nedostataka Agile metodologiji predstavljaju naličje njegovih prednosti. Na primer, jedan važan benefit rada po Agile modelu je manje rigorozan stav po pitanju vođenja dokumentacije. Ova se prednost lako može preokrenuti u manu, jer nedovoljna dokumentacija može dovesti do problema u komunikaciji i prenosu znanja, posebno kada novi članovi tima preuzimaju odgovornosti ili kada projekat postane složeniji i zahteva detaljnije razumevanje prethodnih faza razvoja.
Gde je QA u svemu tome?
Ipak, danas je Agile široko prihvaćen upravo zato što nudi optimalnu prilagodljivost za dinamičan razvoj softvera. Agile efikasno reaguje na tržišne promene, podstiče inovacije i kontinuirano unapređuje softverske proizvode, tako se usklađujući sa brzim i promenljivim ritmom savremenog sveta. U svemu tome jednu od ključnih uloga igra pozicija testiranja u ovom procesu.
Zato ćemo se u sledećem tekstu fokusirati na QA, pokušati detaljno da objasnimo njegovo mesto i doprinos u obe ove metodologije i analizirati prednosti i mane oba pristupa u kontekstu testiranja.
Ako želiš da naučiš više o SDLC, različitim metodologijama i specifičnoj ulozi testiranja u svakoj od njih, ali i mnogo mnogo više od toga, naš QA kurs bi mogao biti pravi izbor za tebe.