U ovoj lekciji obrađivaćemo:
U ranim godinama razvoja softvera naručioci su bili spremni da duže čekaju na završetak razvoja softverskih sistema. Vreme izbacivanja na tržište nije bilo toliko kratko kao danas. Nekada su prolazile godine od trenutka kada su dokumenti sa zahtevima bili pisani do trenutka kada je sistem isporučivan, što je nazivano trajanje ciklusa. Današnja poslovna okruženja više ne tolerišu duga kašnjenja, a naručioci uvek traže nov kvalitet i funkcionalnost. Npr. u 1996. godini, 80% prihoda Hewlett-Packarda dobijeno je od proizvoda uvedenih u prethodne dve godine. Uvek se radi na razvijanju novih modela procesa koji treba da pomognu da se smanji trajanje ciklusa.
Jedan način za smanjenje vremena trajanja ciklusa je upotreba faznog razvoja. Sistem se projektuje tako da može da se isporučuje u delovima, omogućavajući korisnicima da imaju neku funkcionalnost dok je ostatak još u razvoju. Tako postoje dva sistema koja uporedo funkcionišu: produkcioni sistem i razvojni sistem, kao što se vidi na slici 1. Produkcioni sistem je onaj koji trenutno koriste naručilac i korisnik. Razvojni sistem predstavlja sledeću verziju koja se priprema da zameni aktuelni produkcioni sistem. Često se označavaju sistemi zavisno od rednog broja njihove verzije (izdanja): razvojni tim gradi Verziju 1, testira je, a zatim predaje korisnicima kao prvu produkcionu verziju. Zatim, dok korisnici koriste Verziju 1, projektni tim gradi Verziju 2. Projektni tim uvek radi na Verziji n + 1, dok je Verzija n u fazi operativnog korišćenja.
Slika 1. Fazni razvoj
Postoje mnogi načini da projektni tim odluči kako da organizuje razvoj u okviru pojedinih verzija. Dva najpopularnija pristupa su inkrementalni razvoj i iterativni razvoj, što je prikazano na slici. Kod inkrementalnog razvoja sistem, kako je specifikovan u specifikaciji zahteva, podeljen je na podsisteme prema funkcionalnosti. Verzije su definisane na samom početku u vidu jednog malog, funkcionalnog podsistema, a zatim se nove funkcionalnosti uključuju u svaku novu verziju. Inkrementalnim razvojem se sa svakim novim izdanjem sistem dograđuje, sve do potpune funkcionalnosti. Istraživanja pokazuju da se inkremantalni razvoj koristi u 20% kompanija [2]. Iterativni razvoj isporučuje potpun sistem na samom početku, a zatim vrši izmene funkcionalnosti svakog podsistema, u svakoj novoj verziji.
Slika 2. Prikaz inkrementalnog i iterativnog razvoja
Npr. posmatramo programski paket za obradu teksta. Pretpostavimo da paket treba da isporuči tri vrste funkcionalnosti:
Za gradnju sistema pomoću inkrementalnog razvoja, može se u verziji 1 obezbediti samo funkcije za unos teksta, zatim u verziji 2 i unos i organizaciju, a na kraju u verziji 3 unos teksta, organizaciju i formatiranje. Koristeći iterativni razvoj, moguće je obezbediti primitivne oblike sva tri tipa funkcionalnosti već u verziji 1. Npr. moguće je uneti tekst, a zatim vršiti isecanje i umetanje, pri čemu je isecanje i umetanje sporo. U sledećoj iteraciji, tj. verziji 2, postoji ista funkcionalnost, ali poboljšan kvalitet, tako da je isecanje i umetanje lako i brzo. Svaka verzija poboljšava na neki način prethodnu.
Ovakvi oblici faznog razvoja poželjni su iz više razloga:
Boehm (1988) je posmatrao razvoj softvera u svetlu prisutnih rizika, sugerišući da spiralni model može da kombinuje aktivnosti razvoja sa upravljanjem rizicima, radi smanjenja i kontrole rizika [1]. Spiralni model, na neki način je sličan modelu iterativnog razvoja. Započinjući za zahtevima i početnim planom razvoja (uključujući budžet, ograničenja i alternative), ovaj proces ubacuje korak koji vrši procenu rizika i prototipske alternative, pre nego što se proizvede dokument „principi rada", sa ciljem opisivanja funkcionisanja sistema na visokom nivou apstrakcije. Iz tog dokumenta, definiše se i nadgleda skup zahteva da bi se potvrdile kompletnost i doslednost zahteva. Stoga je princip rada proizvod prve iteracije dok su zahtevi glavni proizvod druge iteracije po redu. U trećoj iteraciji razvoj sistema produkuje dizajn, dok četvrta iteracija omogućava testiranje.
U svakoj iteraciji, analiza rizika određuje različite varijante sa aspekta zahteva i ograničenja dok se izradom prototipova verifikuje izvodljivost ili poželjnost, pre izbora odgovarajuće varijante. Nakon identifikacije rizika, rukovodioci projekta moraju da odluče kako da ih eliminišu ili minimiziraju.
Npr. projektanti možda nisu sigurni da li će korisnicima više da se dopada jedan korisnički interfejs ili drugi. Da bi se izbegao rizik izbora interfejsa koji bi onemogućio produktivnu upotrebu novog sistema, projektanti mogu da izrade prototip oba interfejsa i izvrše testove da bi zaključili koji je poželjniji, ili čak da oba interfejsa uključe u projekat kako bi korisnici mogli da, nakon prijavljivanja, odaberu interfejs. Ograničenja kao što su budžet i vreme isporuke pomažu kod izbora strategije upravljanja rizicima.
Spiralni model nije toliko rasprostranjen i procenjuje se da se koristi u 9% kompanija [2].
Slika 3. Spiralni model
Reference