U ovoj lekciji obrađivaćemo:
U literaturi iz oblasti softverskog inženjerstva opisani su mnogi modeli procesa izrade softvera. Neki predstavljaju recepte za sprovođenje procesa razvoja softvera, dok drugi predstavljaju opis načina na koji se razvoj softvera realizuje.
Kada grupa opiše proces projektovanja koji primenjuje, opis postaje zajedničko shvatanje aktivnosti, resursa i ograničenja uključenih u razvoj softvera. Modelovanje procesa pomaže razvojnom timu da pronađe nedoslednosti, redundanse i izostavljene elemente u samom procesu ili njegovim delovima. Uočavanjem i otklanjanjem tih nedostataka, proces postaje efektivniji i usmereniji na gradnju finalnog proizvoda.
Model treba da odražava ciljeve razvoja:
Nakon izrade modela, projektni tim ocenjuje aktivnosti sa aspekta njihove usklađenosti sa postavljenim ciljevima. Svaki proces treba da bude modelovan prema posebnoj situaciji u kojoj će se primenjivati. Svaki model procesa razvoja softvera kao ulaz koristi specifikaciju zahteva, a kao izlaz isporučeni proizvod. Tokom niza godina razvoja softverskog inženjerstva, predloženi su mnogi takvi modeli.
Modeli opisuje procese translacije i prelaza, od sistemskog koncepta do specifikacije zahteva, preko dizajniranja do kodiranja. Dobar model će pomoći u minimiziranju problema vezanih za svaku translaciju.
Takodje, veoma je teško pratiti i upravljati kompletnim projektom, kada nije primenjen prikladan model razvoja. Modeli omogućavaju povećanje produktivnosti i primenu uobičajenih tehnika razvoja, jezika i veština.
U ovom modelu faze su kaskadno prikazane. Jedna faza razvoja treba da se u potpunosti okonča pre nego što počne sledeća. Zbog toga, tek kada su svi zahtevi naručioca iskazani, analizirani sa aspekta potpunosti i doslednosti, dokumentovani u dokumentu koji sadrži tehničke zahteve, razvojni tim može da nastavi sa svojim aktivnostima. Model vodopada predstavlja pogled na vrlo visokom nivou apstrakcije na proces razvoja, pri čemu se projektnom timu sugeriše redosled očekivanih događaja.
Slika 1. Model vodopada
Model vodopada se koristio za propisivanje aktivnosti u procesu razvoja softvera u različitim kontekstima. Opisan je u sklopu standarda Defence Standard 2167-A, i dugi niz godina bio je osnova ugovora za razvoj i isporuku softvera u Ministarstvu odbrane SAD (U.S. Department of Defence). Uz svaku aktivnost u sklopu procesa definisana su prateća dostignuća (engl. milestone) i elementi primopredaje (engl. deliverables) tako da rukovodioci projekata mogu koristiti model za merenje stepena kompletiranja projekta. Npr. „testiranje delova i celina" u modelu vodopada završava se dostignućem „moduli koda koji su napisani, testirani i integrisani", dok je element primopredaje predstavljen primerkom testiranog koda. Nakon toga, kod se predaje inženjerima koji testiraju sistem, gde se on prvo zaokružuje sa ostalim komponentama sistema (hardver ili softver), a zatim testira u sklopu celine.
Iako je model vodopada jedan od najstarijih modela i u primeni je već nekoliko decenija i dalje veliki broj kompanija koristi ovaj model razvoja. Prema rezultatima jednog istraživanja procenjuje se da oko 35% kompanija koristi model vodopada [1].
Prednosti modela vodopada su:
Najveća mana modela vodopada je što ne odražava stvarni način na koji se kod razvija, jer se softver obično razvija kroz veliki broj iteracija. Nestandardne tehnike razvoja softvera postoje zbog različitih problema iz realnog sveta koji opisuju. Softver se često koristi za rešavanje problema koji nikada ranije nije bio rešen ili čije rešenje mora da se unapredi da bi odražavalo promene nastale u poslovnom ili radnom okruženju. Ni razvojni tim ni korisnici ne znaju sve ključne faktore koji utiču na željeni ishod, tako da će značajno vreme u fazi analize zahteva biti potrošeno na shvatanje elemenata i procesa na koje sistem i njegov softver utiču, kao i odnosa koje sistem uspostavlja sa radnim okruženjem.
Stvarni proces razvoja softvera može da izgleda kao na slici 2. Učesnici u razvoju se prebacuju sa jedne aktivnosti na drugu i vraćaju unazad, u pokušajima da upoznaju i reše problem.
Slika 2. Realni proces razvoja softvera
Proces razvoja softvera, kroz uključenje potprocesa koji doprinose boljem razumevanju, pomaže u procesu kontrolisanja nedostataka. Izrada prototipova je jedan takav potproces. Prototip predstavlja delimično razvijen proizvod koji omogućava naručiocima i projektantima da ispitaju neke aspekte predloženog sistema i odluče da li je on pogodan ili potreban u sklopu gotovog proizvoda.
Npr. projektni tim može da izgradi sistem koji implementira jedan deo ključnih zahteva, u cilju provere njihove doslednosti, izvodljivosti i praktične vrednosti. Ako se utvrdi odstupanje, zahtevi se revidiraju i time izbegavaju mnogo skuplje revizije u kasnijim fazama razvoja.
Na slici 3 je prikazan model vodopada sa prototipom.
Slika 3. Model vodopada sa prototipom
Izrada prototipova u fazi projektovanja pomaže i projektnom timu da oceni alternativne strategije projektovanja i odluči koja je najbolja za određeni projekat. Projektanti mogu da dizajniraju zahteve na potpuno različite načine, da bi videli koji od njih poseduje najbolje osobine.
Npr. mreža može da se u jednom prototipu projektuje u topologiji prstena, a u drugom u topologiji zvezde, pri čemu se ocenjuju performanse u cilju utvrđivanja koja je topologija primerenija za postizanje postavljenih ciljeva u datim ograničenjima.
Izrada prototipa vrši se i iz drugih razloga. Često se korisnički interfejs gradi i testira u formi prototipa, sa ciljem da korisnici shvate izgled novog sistema, a projektanti steknu bolji utisak o tome kakvu interakciju sa sistemom korisnici žele. Osnovne poteškoće u zahtevima se uočavaju i ispravljamo znatno pre nego što se one zvanično validiraju u fazi testiranja sistema.
Generalno posmatrano, postoje dve vrste prototipa:
Na ovom mestu ćemo još jednom podvući razliku izmedju ova dva bliska pojma.
Validacija obezbeđuje potpunost implementacije zahteva u sklopu sistema, tako da se svaka funkcija sistema može propratiti i povezati sa određenim zahtevom definisanim u specifikaciji zahteva. Testiranjem sistema zahtevi se verifikuju.
Verifikacija osigurava ispravan rad svake funkcije. Verifikacija proverava kvalitet implementacije. U sklopu validacije se proverava da li je razvoj rezultirao sistemom usklađenim sa specifikacijom. Izrada prototipa je korisna za verifikaciju i validaciju, ali te aktivnosti mogu da se vrše i u drugim fazama procesa razvoja softvera.
Reference
1. Neill, C.J. and Laplante, P.A., Requirements engineering: the state of the practice, 2003.
2. S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice Hall, 2001,