U ovoj lekciji obrađivaćemo:

  • Razlozi za modelovanje procesa izrade softvera
  • Modeli procesa izrade softvera
  • Model vodopada
  • Prototipi

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.

Razlozi za modelovanje procesa

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: 

  • izrada softvera visokog nivoa kvaliteta
  • otkrivanje grešaka u ranim fazama razvoja
  • ostajanje u okvirima budžeta i formulisanih ograničenja vezanih za rokove završetka

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.


Model vodopada

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 i mana modela vodopada

Prednosti modela vodopada su:

  • Jednostavnost. Njegova jednostavnost olakšava pružanje objašnjenja kupcima koji nisu upoznati sa procesom razvoja softvera. Eksplicitno ukazuje na međuproizvode koji su neophodni za započinjanje sledeće faze.
  • Osnova drugih modela. Mnogi drugi, složeniji modeli, predstavljaju na neki način „ulepšani" model vodopada, kroz uključivanje povratnih sprega i dodatnih aktivnosti.

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

Izrada prototipa

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.


Vrste prototipa

Generalno posmatrano, postoje dve vrste prototipa:

  • Throwaway Prototyping. Podrazumeva kreiranje prototipa koji će u dogledno vreme biti odbačen. Nakon preliminarne faze zahteva, konstruiše se jednostavniji radni model sistema radi ilustracije korisniku. Predstavlja izradu radnog modela različitih delova sistema u ranoj fazi razvoja. Može da se uradi veoma brzo. Ovim prototipom testira se i korisnički interfejs.
  • Evolutionary Prototyping (Breadboard prototyping). Predstavlja izgradnju vrlo robusnog prototipa na strukturiran način i njegovo konstantno usavršavanje. Gradi se samo na osnovu onih zahteva koji su dobro razmotreni i prihvaćeni. Podrazumeva dodavanje novih funkcionalnosti i evaluacija kroz različita operativna okruženja.


Validacija i verifikacija

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,

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Model vodopada 1
  • Model vodopada 2
  • Model vodopada 3