U ovom ćemo postu proći kroz različite metodologije razvoja softvera, zajedno s njihovim prednostima i nedostacima i kada koristiti svaki model.
Iterativni model životnog ciklusa ne pokušava započeti s potpunom specifikacijom zahtjeva. Umjesto toga, razvoj započinje specificiranjem i implementacijom samo dijela softvera, koji se potom može pregledati kako bi se utvrdili daljnji zahtjevi. Zatim se taj postupak ponavlja, stvarajući novu verziju softvera za svaki ciklus modela.
Razmotrimo iterativni model životnog ciklusa koji se sastoji od ponavljanja sljedeće četiri faze u nizu:
Faza zahtjeva, u kojem se prikupljaju i analiziraju zahtjevi za softverom. Iteracija bi na kraju trebala rezultirati fazom zahtjeva koja daje potpunu i konačnu specifikaciju zahtjeva.
Faza dizajna, u kojem je dizajnirano softversko rješenje koje udovoljava zahtjevima. Ovo može biti novi dizajn ili produžetak ranijeg dizajna.
Faza provedbe i ispitivanja, kada je softver kodiran, integriran i testiran.
Faza pregleda, u kojem se procjenjuje softver, pregledavaju se trenutni zahtjevi i predlažu promjene i dopune zahtjeva.
Za svaki ciklus modela mora se donijeti odluka hoće li se softver proizveden u tom ciklusu odbaciti ili zadržati kao početna točka za sljedeći ciklus (ponekad se naziva i inkrementalno izrađivanje prototipa.
Na kraju će se doći do točke u kojoj su zahtjevi ispunjeni i softver se može isporučiti, ili postaje nemoguće poboljšati softver prema potrebi i treba započeti novi početak.
Iterativni model životnog ciklusa može se usporediti s proizvodnjom softvera uzastopnom aproksimacijom. Povlačeći analogiju s matematičkim metodama koje koriste uzastopnu aproksimaciju kako bi došle do konačnog rješenja, korist takvih metoda ovisi o tome koliko se brzo konvergiraju u rješenje.
Ključ uspješne upotrebe iterativnog životnog ciklusa softvera je stroga provjera valjanosti zahtjeva i provjera (uključujući testiranje) svake verzije softvera u odnosu na te zahtjeve unutar svakog ciklusa modela.
Inkrementalni model izrade metoda je razvoja softvera gdje se model dizajnira, implementira i postupno testira (svaki put se dodaje malo više) dok proizvod ne završi. Uključuje i razvoj i održavanje. Proizvod se definira kao gotov kada zadovoljava sve njegove zahtjeve. Ovaj model kombinira elemente modela vodopada s iterativnom filozofijom izrade prototipa.
Proizvod se razlaže na niz komponenata, od kojih je svaka dizajnirana i izrađena zasebno (nazvane građevine). Svaka komponenta isporučuje se klijentu kada je dovršena. To omogućuje djelomičnu upotrebu proizvoda i izbjegava dugo vrijeme razvoja. To također stvara velike početne izdatke za kapital s izbjegavanim kasnijim dugim čekanjem. Ovaj model razvoja također pomaže ublažiti traumatični učinak uvođenja potpuno novog sustava odjednom.
Postoje neki problemi s ovim modelom. Jedno je da svaka nova gradnja mora biti integrirana s prethodnim verzijama i bilo kojim postojećim sustavima. Ni zadaća razgradnje proizvoda na građevine nije trivijalna. Ako je premalo izrada i svaka izrada degenerira, to se pretvara u model Build-And-Fix. Međutim, ako ima previše gradnji, malo je dodanih korisnosti od svake gradnje.
Agilan model kombinacija je iterativnog i inkrementalnog modela rastavljanjem proizvoda na komponente gdje se u svakom ciklusu ili iteraciji isporučuje radni model komponente.
Model proizvodi tekuća izdanja (iterativna), svaki put dodajući male promjene u prethodnu verziju (iterativna). Tijekom svake iteracije, dok se proizvod izrađuje, također se ispituje kako bi se osiguralo da se na kraju iteracije proizvod može isporučiti.
Model Agile naglašava suradnju jer kupci, programeri i testeri rade zajedno tijekom cijelog projekta.
Prednost Agile modela je što brzo donosi radni proizvod i smatra se vrlo realnim pristupom razvoju.
Nedostatak ovog modela je taj što, budući da u velikoj mjeri ovisi o interakciji s kupcem, projekt može krenuti pogrešnim putem ako kupcu nisu jasni zahtjevi ili smjer u kojem želi ići.
V model je poboljšana verzija klasičnog modela vodopada pri čemu se provjerava svaka razina životnog ciklusa razvoja prije prelaska na sljedeću razinu. Ovim modelom testiranje softvera izričito započinje na samom početku, tj. Čim se napišu zahtjevi.
Ovdje pod testiranjem podrazumijevamo provjeru pomoću pregleda i inspekcija, tj. Statičko ispitivanje. To pomaže u prepoznavanju pogrešaka vrlo rano u životnom ciklusu i minimalizira potencijalne buduće nedostatke koji se pojavljuju u kodu kasnije u životnom ciklusu.
Svaka razina životnog ciklusa razvoja ima odgovarajući plan ispitivanja. tj. kako se radi na svakoj fazi, razvija se plan ispitivanja radi pripreme za ispitivanje proizvoda te faze. Razvojem planova ispitivanja možemo definirati i očekivane rezultate ispitivanja proizvoda za tu razinu, kao i definirati ulazne i izlazne kriterije za svaku razinu.
Poput Vodopada, svaka faza započinje tek nakon završetka prethodne. Ovaj je model koristan kada nema nepoznatih zahtjeva, jer je još uvijek teško vratiti se i unijeti promjene.
Model slapa najstarija je i najjednostavnija od strukturiranih SDLC metodologija. Postoje stroge faze i svaku fazu treba prvo dovršiti prije odlaska na sljedeću fazu. Nema povratka.
Svaka se faza oslanja na informacije iz prethodne faze i ima svoj vlastiti projektni plan.
Vodopad je jednostavan za razumijevanje i jednostavan za upravljanje. Međutim, obično je sklona kašnjenjima jer svaku fazu treba pregledati i potpuno odjaviti prije nego što sljedeća faza može započeti.
Također, budući da ima malo mjesta za revizije nakon što je faza završena, problemi se ne mogu riješiti dok ne dođete do faze održavanja.
Ovaj model najbolje funkcionira kada su poznati svi zahtjevi i nije potrebna fleksibilnost, a projekt ima fiksnu vremensku liniju.