UNIVERZITET U NOVOM SADU
TEHNIČKI FAKULTET „MIHAJLO PUPIN“ ZRENJANIN
- Seminarski rad –
MODELI ŽIVOTNOG CIKLUSA RAZVOJA SOFTVERA
Mentor:
Student:
Prof. dr Biljana Radulović
Ristić Zvonko br. dosijea: 5/10-02
ZRENJANIN, 2012.
Sadržaj 1. 2.
3. 4.
Uvod ....................................................................................... Životni ciklus softvera ........................................................... 2.1. Modeli životnog ciklusa softvera .......................................... 2.1.1. Model vodopada .................................................................... 2.1.2. Spiralni model ....................................................................... 2.1.3. Iterativno – inkrementalni model ..........................................
3 5 7 8 9 11 Zaključak ............................................................................... 14 Literatura ............................................................................... 15
2
1. Uvod
Razvoj informatike i njenih tehnologija je doveo do toga da su kompijuteri i programi uopšte postali deo svakodnevice za većinu ljudi. To se posebno odnosi na poslovnu sferu. U tom smislu pojavljuje se veliki broj metoda u oblasti softverskog inženjerstva, koje su namenjene za rešavanje problema razvoja softvera. Sam razvoj softvera je složen proces, koji se sastoji iz više faza: zahtev za odreĎenim softverski m poizvodom,
specifikacija i projektovanje, implementacija,
testiranje (testiranje se obično radi paralelno sa razvojem procesa), pisanje dokumentacije (proizvod ne može biti donet na tržište bez upustva).
Koliko je važan značaj kontrole kvaliteta u ovoj oblasti potvrĎuju rezultati istraživanja nekoliko eminentnih američkih istraživačkih organizacija: više od dve trećine američkih softverskih projekata nikad ne uĎe u upotrebu. Razlozi su sledeći: ili se projekat ne završi u roku i budžetu, ili se ispostavi da to nije ono što je klijent hteo, ili je kvalitet samog izlaza ispod očekivanja (loše performanse, visoki troškovi održavanja i nadogradnje i sl.). Kvalitet samog softvera može da se gleda kroz dve dimenzije: efektivnost i efikasnost. Efektivnost se odnosi na to da li softver pruža traženu funkcionalnost (da li radi ono što je klijentu potrebno). Efikasnost, sa druge strane, podrazumeva da se funkcionalnost pruža na kvalitetan način (softver radi brzo, pouzdano – nema greške, lak je za održavanje, nadogradnju i sl.).
U praksi, osiguravanje efektivnosti se vrši već u procesu sakupljanja korisničkih zahteva i opisa problema. Pribegava se izradi prototipova programa i prezentovanja krajnjim korisnicima da bi se odmah uočili neki nedostaci u funkcionalnosti ili u samom zahtevu. Još
jedan od praktičnih postupaka za povećavanje efikasnosti je i tzv. “iterativni” razvoj softvera. Ceo razvoj se deli u nekoliko iteracija, a izlaz iz svake iteracije je program koji ima samo deo funkcionalnosti koji se odmah pušta u rad. Tako se, krajem svake iteracije, dodaje funkcionalnost sve dok se ne dobije gotova celina sa kompletnom funkcionalnošću – ceo
program. Prednost ovakvog pristupa je u tome što se nedostaci u korisničkim zahtevima uočavaju i otklanjaju brzo i de taljno. Efikasnost softvera je nešto što se prvenstveno postiže uvoĎenjem u praksi dokazanih postupaka pri projektovanju, implementaciji i testiranju softvera. Cilj je da se dobije softver koji je brz, pouzdan i lak za održavanje i nadogradnju. Korišćenj e uzora (pattern) u
projektovanju softvera značajno doprinosi njegovoj robusnosti tako da su održavanje i nadogradnja relativno jednostavni. Sa druge strane, brzina i pouzdanost mogu da se potvrde i obezbede jedino detaljnim testiranjem. Testiranje predstavlja
najčešće zanemarivanu aktivnost u razvoju softvera. Ako se pogleda Larmanova metoda razvoja softvara može da se uočiti da pored opisa korisničkog zahteva, analize, projektovanja i implementacije, sadrži i testiranje kao fazu. Znači prema Larmanu, testiranje se vrši posle implementacije (posle pisanja koda). Predstavnici pravca “ekstremnog programiranja” imaju drugačiji pristup: oni predlažu pisanje testova pre pisanja koda (write text before you write code). U praksi se stvari odvijaju drugačije: testiranje se vrši retko najčešće zbog vremenskih rokova, testiranje se vrši neorganizovano i ponekad se skroz 3
izostavlja. Posledice su očigledne – dobija se softver loših performansi i pun grešaka, a gubi se novac i vreme za njegovu ispravku. Ipak, najveći gubitak je upravo u poverenju klijenata i njihovom zadovoljstvu.
Korišćenjem alata za testiranje i stvaranje “dobrih” navika kod programera da pišu jedinične (unit) testove, stvara se put za prevazilaženje problema ove vrste. Moguće je praviti jeftiniji , a u isto vreme i brz i pouzdan softver. Dodatno vreme koje je utrošeno na testiranje će svakako biti vraćeno zbog smanjenog vremena potrebnog da se otklone greške ili povećaju performanse. Najvažnije je, svakako, to da će klijenti biti zadovoljniji, i da će se troškovi izrade softvera verovatno smanjiti jer je uvek jeftinije grešku ispraviti dok program još nije pušten u rad. Glavni ciljevi ovog rada su:
• Dati kratak pregled modela, metoda i aktivnosti životnog ciklusa softvera; • Dati pregled .NET platforme; • Dati pregled Test Complite alata za testiranje softvera; • Izvršiti razvoj .NET aplikacije, korišćenjem Larmanove metode za razvoj softvera; • Izvršiti testiranje softvera primenom Test Complite alata za testiranje softvera. Dodatni cilj je:
• UvoĎenje čitaoca u oblast razvoja i testiranja softvera.
4
2.
Životni ciklus softvera
Da bi se razumeo način izrade dobrog softvera, procenjivanje rizika kao i mogućnosti koje softver unosi u naš svakodnevni život, neophodno je čvrsto teorijsko i praktično razumevanje softverskog inženjerstva. Izrada dobrog softvera predstavlja “umetnost” koja se ogleda u razumevanju načina apstrahovanja i modelovanja suštinskih elemenata problema, a zatim korišćenju takvih apstrakcija za projektovanje rešenja. Dobra softver -inženjerska praksa teži da obezbedi softver koji će dati pozitivan doprinos načinu na koji živimo, jer je u današnje vreme rad softvera prisutan u svim aspektima našeg života. Da bi se razumelo kako se softversko inženjerstvo uklapa u svet računarske na uke treba objasniti da se računarstvo usredsreĎuje na računare i programske jezike, a softversko inženjerstvo iste koristi kao alate u projektovanju i primeni rešenja nekog problema. Umesto da istražuje dizajn hardvera, softver inženjer se usredsreĎuje na računar kao sredstvo za rešavanje problema. Svaki haker može da napiše programski kod koji nešto radi, ali su potrebni umeće i znanje profesionalnog softverskog inženjera da bi se proizveo stabilan i razumljiv kod koji se lako održava i koji efikasno i efektivno radi ono zbog čega je napravljen. Suština softverskog inženjerstva je u projektovanju i razvoju visoko kvalitetnog softvera.
Softversko inženjerstvo je stvaralački postupan proces, koji okuplja veliki broj ljudi na poslovima izrade različitih vrsta proizvoda. Prilikom pružanja usluga ili izrade proizvoda uvek se sledi niz koraka kako bi se izvršio neki skup zadataka. Zadaci se obično izvršavaju u istom redosledu. UreĎeni skup zadataka smatra se procesom: nizom koraka koji obuhvataju aktivnosti, ogr aničenja i resurse, a rezultiraju željenim ostvarenjem. Proces izrade nekog proizvoda se ponekad naziva životni ciklus. Zbog toga se nekada softverski razvojni proces naziva i životni ciklus softvera jer opisuje “život” softverskog proizvoda od formulisanja, preko implementacije do isporuke, upotrebe, operativnog
korišćenja i održavanja. Procesi su važni jer omogućavaju strukturisanje i konzistentno predstavljanje skupa aktivnosti. Proces razvoja softvera može biti fleksibilan u pogledu korišćenja alata i tehnika, koji pojedincima više odgovaraju. Proces pomaže da se održi nivo konzistentnosti i kvaliteta proizvoda ili usluga koje različiti ljudi realizuju. Proces je složeniji pojam od postupka. Postupak je umeren način kombinovanja alata i tehnika u cilju izrade proizvoda (softvera). Proces predstavlja skup postupaka, organizovanih
tako da rezultujući proizvod zadovolji unapred postavljeni skup ciljeva i standarda. Na primer, proces može da zahteva da proverimo delove projekta pre početka procesa kodiran ja. Provera može da se izvede neformalnim pregledom ili formalnom inspekcijom, od kojih je svaki postupak za sebe, ali im je isti cilj.
Postojanje procesa omogućuje učenje na iskustvima ranije razvijenih projekata, dokumentovanje izrade softvera visokog kvaliteta i praćenje procesa razvoja softvera. Razvoj softvera obično obuhvata sledeće faze: 1. definisanje korisničkih zahteva, 2. projektovanje, 3. implementacija, 5
4. testiranje, 5. isporuka,
6. održavanje. Svaka faza predstavlja proces koji se može opisati skupom aktivnosti pri čemu svaka aktivnost uključuje ograničenja, izlaze i resurse. Na primer, u fazi prikupljanja zahteva, kao početni ulaz koriste se iskazi, koje formuliše korisnik na neki od mogućih načina. Izlaz iz ove faze je skup zahteva. Postoje ograničenja, kao što su budžet i vremenski rok za izradu dokumenta o zahtevima, standardi vezani za tipove uključenih zahteva i notacija za njihovo iskazivanje.
6
2.1.
Modeli životnog ciklusa softvera
Svaki proces može da se opiše na različite načine, pomoću teksta, slika ili njihovom kombinacijom. Istraživači u oblasti softverskog inženjeringa predlažu različite forme takvih opisa, odnosno modele životnog ciklusa softvera sa ciljem da se utvrdi način na koji organizovane aktivnosti unutar procesa može da dovede do efikasnijeg razvoja softverskog sistema.
Slika 1
Na slici 1. prikazan je model razvoja procesa. Kao što se vidi sa slike na ulazu je specifikacija zahteva, u modelu razvoja procesa vrši se projektovanje i testiranje aplikacije, na kraju se isporučuje gotov proizvod. Razlozi za modelovanje procesa:
•
Kada grupa opiše primenjivani proces projektovanja, opis postaje zajedničko shvatanje aktivnosti, resursa i ograničenja uključenih u razvoj softvera. • Modelovanje pomaže u nalaženju nedoslednosti, viškova i izostavljenih elemenata u samom procesu, što poboljšava efikasnost procesa. • Model treba da odražava ciljeve razvoja. Nakon izrade modela projektni tim ocenjuje aktivnosti sa aspekta njihove usklaĎenosti sa postavljenim ciljevima. • Svaki proces mora biti napravljen prema situaciji u kojoj će se primenjivati. Modelovanje procesa pomaže da projektni tim utvrdi mesta na kojima su potrebna prilagoĎavanja. U domenu softverskog inženjerstva opisani su mnogi modeli procesa. Izrada modela procesa i razmatranje njegovih potprocesa pomažu projektnom timu da shvati jaz izmeĎu postavljenog zahteva projekta i mogućeg rešenja. Model treba da odražava ciljeve razvoja, kao što je izrada softvera visokog nivoa kvaliteta, otkrivanje grešaka u ranim fazama razvoja i ostajanje u okvirima budžeta i formulisanih ograničenja vezanih za rokove realizacije. Tokom niza godina predloženi su mnogi takvi modeli. Modeli procesa razvoja softvera koji su obraĎeni u ovom radu: • • •
Kaskadni model (model vodopada) Fazni razvoj (inkrementalni i iterativni) Spiralni model
7
2.1.1. Model vodopada Model vodopada ili kaskadni model (Royce, 1970.) predstavlja veoma visok nivo apstrakcije
razvojnog procesa čije su faze kaskadno prikazane. Iako ima puno nedostataka, on služi kao osnova za druge, efikasnije modele životnog ciklusa. U modelu vodopada, projekat napreduje kroz ureĎenu seriju koraka od inicijalnog koncepta softvera do testiranja sistema. Projekat se preispituje na kraju svake faze, da bi se odredilo da li je spreman za prelazak u sledeću fazu. Za svaku aktivnost procesa definišu se kritične tačke i meĎuproizvodi, što olakšava praćenje stepena gotovosti projekta. Ukoliko projekat nije spreman za prelazak u sledeću fazu, ostaje u trenutnoj fazi dok ne bude spreman. Model vodopada je baziran na dokumentima (document driven), glavni radni proizvodi koji se prenose iz faze u fazu.
što znači da su dokumenti
Slika 2. Model vodopada razvojnog procesa Na slici je prikazan redosled faza u projektovanju kod modela vodopad. Model vodopad ostvaruje dobre rezultate za proizvodne cikluse u kojima su stabilne definicije proizvoda i kada se radi sa dobro poznatim tehničkim metodologijama. U takvim slučajevima, model vodopada pomaže da se naĎu greške u ranim fazama projekta. On pruža stabilnost zahteva,
koju programeri žele. Ukoliko je detaljno definisana verzija za održavanje postojećeg proizvoda, na osnovu nje možemo lako prebaciti postojeći proizvod na novu platformu. Model vodopada može da bude pravi izvor za brz razvoj. Ovaj model smanjuje opterećenje planiranjem pošto se celo planiranje radi unapred. Ne pruža opipljive rezultate u formi softvera do kraja životnog ciklusa, ali neko ko je upoznat sa ovim modelom, može da iz dokumentacije koja se generiše da dobije smislene indikacije napretka kroz životni ciklus.
Prednosti modela:
•
Jednostavnost koja olakšava pružanje objašnjena kupcima. Kroz hronološki pregled
•
svih faza projektovanja. Dobijanje pune funkcionalnosti sistema. 8
•
Eksplicitno ukazivanje na meĎuproizvode koji su neophodni za započinjanje sledeće faze.
•
Pogodan za slučaj kada je neophodno odjednom zameniti stari sistem.
Nedostaci modela:
• Ne podržava povratne sprege, koje zbog grešaka i nepreciznosti zahteva postoje u stvarnosti.
• Sistem je obično prevelik da se uradi u jednoj iteraciji. • Nije pogodan kod znatnih izmena zahteva. 2.1.2. Spiralni model Spiralni model je definisao Barry Boehm člankom “ A Spiral Model of Softvere Development and Enhancement ” 1986. godine. Spiralni model posmatra razvoj softvera u svetlu prisutnih rizika tako što kombinuje aktivnosti razvoja sa upravljanjem rizicima.
Spiralni model je model životnog ciklusa softvera koji je orijentisan na rizik, I koji razbija softverski projekat u mini projekte. Svaki mini projekat obraĎuje jedan ili više glavnih rizika dok svi rizici nisu obraĎeni. Koncept rizika je široko definisan u ovom kontekstu, i može da se odnosi na loše protumačene korisničke zahteve, lošu arhitekturu, potencijalne probleme sa performansama, probleme u osnovnoj tehnologiji, itd. Osnovna ideja iza dijagrama spiralnog modela je da se počne malim koracima u sredini ispituju se rizici, napravi se plan za obradu rizika, i onda se posveti pristupu za sledeću iteraciju. Po spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije (slika 3.)
Slika 3. Faze razvoja softvera u spiralnom modelu
U svakoj iteraciji, radi se analiza rizika koja identifikuje rizike i odreĎuje različite varijante sa aspekta zahteva i ograničenja za njihovo minimiziranje. Zatim se izradom prototipova verifikuju izvodl jivost i pogodnost varijanti pre nego što se odabere odgovarajuća.
9
Slika 3. Spiralni razvoj procesa Posmatranjem spirale, svakom iteracijom se progresivno razvijaju kompletnije i potpunije verzije softvera. Tokom prvog ciklusa kretanja spiralom, prikupljaju se zahtevi i planira projekat razvoja, da bi se izvršila analiza rizika inicijalnih zahteva. Ukoliko analiza rizika indicira neizvesnost u zahtevima, tada se može upotrebiti prototipski razvoj da bi se zahtevi detaljnije spoznali. U iste svrhe, mogu se koristiti simulacija ili druge vrste modela.
Nakon što se donese odluka o daljem razvoju, obavlja se inžinjering u sv akom ciklusu spirale i to odabranim modelom razvoja softvera (model vodopada i/ili model prototipskog razvoja). Broj aktivnosti u inženjeringu raste, ukoliko se ciklusi udaljuju od centra spirale. Istovremeno, aktivnosti su složenije i uvek sa mnogo manje apstrakcije.
Po završetku inžinjerskog posla razvoja, korisnik isti ocenjuje i daje sugestije za promenu softverskog proizvoda. Sledeća faza planiranja novog ciklusa razvoja i analize rizika je zasnovana na korisničkom ulazu. Svaki ciklus razvoja na spirali, zahteva analizu rizika i donošenje odluke “nastaviti” ili “ne nastaviti” sa daljim razvojem. Ukoliko je rizik isuviše velik i ulaganja nesrazmerno visoka u odnosu na efekte koji se očekuju, terminira se dalji rad i zadržava u upotrebi proizvod nastao u prethodnom ciklusu ili prethodnim ciklusima. Svaki novozapočeti ciklus spirale donosi kompletniji proizvod, ali i značajnije i više troškove. Tipična raspodela vremena, za koja ipak treba reći da variraju od ciklusa do ciklusa, je: - planiranje i projektovanje 20%, - procena rizika 5%, - realizacija (sa testiranjem) 40%, - revizija 15% i - ocenjivanje 20%.
10
Ovo je trenutno najrealniji pristup u razvoju softvera za velike sisteme. Model omogućuje brzu reakciju na uočene rizike, a primenom prototipskog razvoja pruža mehanizam za njihovo smanjenje. Tako se primenom ovog modela rizici mogu smanjiti pre nego što izazovu veće probleme i velik e troškove. Model podržava sistematski pristup preuzet iz modela vodopada uz mogućnost izvoĎenja iteracija. Prednosti modela: - Fleksibilnosti za upravljanje softverskim inženjeringom, - Procena rizika se može izvesti u svakom trenutku i nivou apstrakcije, - Model prilagoĎava svaku kombinaciju različitih pristupa u razvoju softvera. Nedostaci modela: -
Odsustvo veze prema postojećim ovaj način razvoja softvera,
standardima, odnosno nepostojanje standarda za
-
Model zahteva više uniformnosti i konzistentnosti u razvoju, Velike probleme stvara situacija kada se na vreme ili uopšte ne otkriju rizici, Konačno, model je relativno nov i nije bio široko primenjivan.
Stoga, biće potrebno još dosta vremena da se sa više sigurnosti i verovatnoće priĎe njegovoj ozbiljnijoj primeni.
2.1.3. Iterativno – inkrementalni model
Koncept razvoja sistema pomoću iteracije je poznat kao iterativno ikrementalni razvoj (IID, Iterative and Incremental Development), iako se često koristi termin “iterativni razvoj”. Fazni razvoj je način projektovanja softvera koji omogućava isporučivanje sistema u delovima, tako da je korisnicima na raspolaganju jedan deo funkcija, dok je ostatak funkcija
još u razvoju.
Slika 4. Fazni razvoj razvojnog procesa
11
uporedo funkcionišu: produkcioni i razvojni sistem. Produkcioni sistem je onaj koji trenutno koristi naručilac i korisnik.
Na slici vidimo da postoje dva sistema koji
Razvojni sistem predstavlja sledeću verziju koja se priprema da zameni postojeći produkcioni sistem. Sistemi se obično nazivaju prem a rednom broju njihove verzije. Tako, projektni tim uvek radi na verziji n+1, dok je verzija n u fazi operativnog korišćenja. Inkrementalni razvoj
Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definišu kao funkcionalni podsistemi, tako da se
svakoj novoj verziji priključuju nove funkcije. Sistem se nadograĎuje do potpune funkcionalnosti. Na slici 5. je dat ilustrativan primer inkrementalnog razvoja. Svaki blok koji je dodat
predstavlja jedan podsistem koji je završen.
Slika 5. Inkrementalni i iterativni razvoj Pogodnosti inkrementalnog razvoja
Operativni podskup funkcija po zahtevima korisnika može biti vrlo brzo isporučen. Projektni tim može da ima relativno mali broj ljudi.
Progres na projektu je vidljiv (nije samo u okviru dokumenta).
Mogućnost odziva od strane korisnika kroz ceo ciklus razvoja vodi ka stabilnijim
meĎurezultatima i sistemu uopšte.
12
Iterativan razvoj
Iterativan razvoj takoĎe podrazumeva podelu sistem a na podsisteme prema funkcijama, ali se potpun sistem isporučuje u svim verzijama, s tim što se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledeća verzija unapreĎuje prethodnu. Pogodnosti iterativnog razvoja
Obuka može da počne sa prvom verzijom, što je dobro, jer praćenje izvršavanja nekih funkcija može da sugeriše poboljšanja u kasnim verzijama. Na tržište može da se izaĎe vrlo rano, ako se radi o funkcionalnostima koje nikada ranije nisu bile nuĎene. Česte verzije omogućavaju brzo otklanjanje nepredviĎenih problema. Projektni tim može da se usredsredi na različite oblasti usavršavanja u različitim verzijama (na pr. k orisnički interfejs, performanse sistema itd.).
13
3.
Zaključak
životnog ciklusa softvera. Vrlo je bitno da se izabere prava metoda za razvoj softvera (da aplikacija bude dobro projektovana), da se poštuju standardi u pisanju koda (code standards ). Potrebna je bliska saradnja izmeĎu test i razvojnog tima (radi U ovom radu su prikazani medeli
protoka informacija). Za samu aplikaciju je bitno da je relativno laka za upotrebu, da se lako nadograĎuje (upgrade).
Proces testiranja softvera je neophodan u vremenu kada raste potražnja za brzim i efikasnim softverskim rešenjima sa niskom cenom.
14
4. Literatura [1] http://www.scribd.com/svetozar_mirkovic/d/36958977/10-Model-vodopada [2] Butcher, M., Munro, H. i Kratschmer, T., Improving software testing via ODC:Three case studies, IBM SYSTMS JOURFAL, 2002. [3] http://www.scribd.com/doc/41991915/T-2-1-Zivotni-Ciklus-Softvera [4] http://www.standardi.yubc.net/index.php?option=com_docman&task=doc_view&gid=27&Item
id=26 [5] http://sr.wikipedia.org/sr/informacioni_sistemi
15
