CASE proizvodi

Softverski inenjering

Softverski inenjering

1. SOFTVERSKI INENJERING

1.1 UvodSavremeni nain poslovanja i mogunosti hardvera diktiraju krajnjim korisnicima raunarskih sistema sve sloenije informacione zahtjeve. Da bi se udovoljilo ovim sloenim potrebama, neophodno je realizovati odgovarajue programske proizvode koji treba da ispune meusobno konfliktne zahtjeve. Programski proizvod treba da zadovolji:

Odgovarajuu sveobuhvatnost, aktuelnost i funkcionalnost s obzirom na domen primjene Visoku pouzdanost u radu Dovoljno brz odziv na informacioni zahtjev korisnika Jednostavnost korienja Jednostavnost odravanja i Brzu realizaciju u odnosu na trenutak identifikacije informacionih zahtjeva.

Programski proizvodi su vremenom zaostajali za mogunou hardverskih ureaja i aktuelnih potreba korisnika, to je dovelo do fenomena poznatog pod nazivom "softverska kriza". Krajem 70-tih godina vie od 80% softver budeta se troilo na odravanje softvera. Drugim rijeima, ako bi se softver projektovao da bude bez greaka i da bude fleksibilniji, bili bismo u mogunosti da sauvamo ogromne sume sredstava. Ovo je jedan aspekt softverskih kriza. Ali, trokovi ukljueni u odravanje softvera nisu jedino vano pitanje; drugo pitanje je kredibilitet. Dugo vremena su ljudi bili sumljiavi prema mainama koje su preuzele njihov rad. Upotreba kompjutera, koji su preuzimali zadatke vezane za procesiranje podataka, bila je, takoe, nepopularna. Greke pouzrokovanie pogrenim kompjuterskim programima, u kalkulacijama (npr. bankovnim) su stvarale lo publicitet u stvaranju pozitivne slike o kompjuterima. Dodatna okolnost je to to se kompjuteri koriste pri praenju izvoenja kritinih procesa, kao to su procesi u hemijskoj industriji, rafinerijama ulja, vojnim ustanovama i jedinicama bolnike intenzivne njege, i ona je od esencijalne vanosti za uvjeravanje javnosti u pouzdanost rada preduzetog od strane kompjutera.

Evidentna su dva pritiska na industriju proizvodnje softvera, koja ne pridonose unapreenju kvaliteta softvera: Ljudi sa jeftinim kompjuterima zahtijevaju (trae) softver koji je proizveden to je mogue jeftinije Sve vie je ljudi koji imaju pristup kompjuterima koji im omoguavaju pisanje softvera. Rad ovih ljudi ne podlijee kontroli kvaliteta, i oni mogu pustiti na trite programe koji su nepouzdani, loe dizajnirani i siromano napisani.

Glavne aspekte softverskih kriza su sljedei:

1. Postoji masovna potreba za softverom2. Postoji ponuda softvera niskog kvaliteta, od nepoznatih prodavaa po niskoj cijeni3. esto su i neki od softvera proizvedeni u priznatim kompanijama sumljivog kvaliteta i fleksibilnosti4. Javnost ima malo povjerenja i u kvalitet softvera i u kvalitet raunara

Vremenom su identifikovani sljedei uzroci kriza softvera:1. Ad hoc projektovanje informacionih sistema bez primjene odgovarajue metodologije2. Nepostojanje softverskih alata koji podravaju projektovanje informacionih sistema ili automatizuju postupke projektovanja3. Nepostojanje odgovarajuih softverskih alata za razvoj aplikacija informacionih sistema4. Rokovi i oekivani trokovi netani5. Produktivnost nije dobro definisana6. Nema podataka iz faze razvoja7. Slaba komunikacija korisnika i razvoja8. Tekoa odravanja itd.Mnogi uzroci SW krize lee u mitovima koji su nastali u ranoj istoriji razvoja softvera zbog: Nedostatka informacija KonfuzijeOvi mitovi se mogu podijeliti na menadment, korisnike i praktiarske mitove. Menadmet mitoviMit: Zato neto mijenjati kada to dobro radiRealnost: Aplikativni domen je isti ali se moe promijeniti kvalitet i produktivnost Korisniki mitoviMit: Opti ciljevi dovoljniRealnost: Gornji mit je uzrok mnogih kasnijih greaka Mitovi praktiaraMit: Ne postoji bilo koja metoda za analizu, dizajn, testiranje koja radi i praktiar odmah sjeda za raunarRealnost: Postoje metode

Za razbijanje mitova, rjeavanje SW krize i prepoznavanje problema i njihovih uzroka razvijena je jedna nova disciplina koja se naziva Softverski inenjering (Software Engineering - SE).

SE je disciplina ili paradigma koja kombinuje razumljive metode u svim fazama razvoja softvera, bolje alate za automatizaciju tih metoda, snanije blokove u izgradnji i implementaciji SW, bolje tehnike za osiguranje kvaliteta koristei koordinaciju, kontrolu i menadment.

Ove metode obuhvataju: Planiranje projekta Analizu sistemskih i SW zatjeva Dizajn Kodiranje Testiranje Odravanje

U razvoju SW-a, SE metode predstavljaju strukturni pristup i proizvodnju visokokvalitetnog softvera u odnosu na efektivne trokove. Prve metode (70-godina) su bile metode strukturne analize koje su pokuavale da identfikuju bazne funkcionalne komponente sistema, a i danas se upotrebljavaju. OO metode se pojavljuju 80 i 90 godina sa razliitim pristupima koje su na kraju unificirane oko UML (Unified Modelig Language).

1.2 SW procesi i modeli

SW proces je skup aktivnosti za produkciju softvera. SW procesi su kompleksni kao i ostali intelektualni i kreativni procesi i zato su ogranieni. Ogranienost se ogleda u tome da nema idealnih procesa i mnoge organizacije razvijaju vlastiti pristup razvoja SW.

Premda postoji mnogo razliitih SW procesa, neke fundamentalne aktivnosti su zajednike u svim procesima:

1. Specifikacija SW-a2. Dizajn i implementacija3. Validacija (ono to je naruilac elio)4. Evaluacija (izmjene za naruioca)

Model SW procesa je apstraktna reprezentacija SW procesa, tj. ovaj model je pojednostavljena deskripcija SW procesa kaja prezentuje pogled na proces i daje samo parcijalne informacije o procesu.

Ova metodologija polazi od injenice da ivotni vijek (ciklus) svakog programskog proizvoda prolazi kroz iste faze.

Prije izrade softvera, "sistem" u kome e on biti smjeten mora biti shvaen. Da bi se ovo ispunilo, neophodno je Odrediti: sveobuhvatni cilj sistema uloge hardvera, softvera i osoblja setove podataka Identifikovati: procedure i druge sistemske elementeObezbijediti da radni zadaci budu: izabrani, analizirani, specificirani, potvreni i nadgledaniOvo su aktivnosti na kojima se zasniva sistem inenjering.

Model SW procesa je pojednostavljena deskripcija SW procesa koja prezentuje jedan pogled na proces. Modeli procesa mogu ukljuivati aktivnosti koje su dio SW procesa, SW produkte, pravila i ljude ukljuene u SE.

Npr. modeli procesa se mogu mogu produkovati na osnovu toka posla, toka podataka i na osnovu uloga i akcija i to su :

1. Workflow model (Model toka posla) Pokazuje sekvencu aktivnosti u procesu za vrijeme ulaza, izlaza i njihove zavisnosti. Aktivnosti u modelu reprezentuju ljudske akcije.2. Dataflow (Tok podataka) ili model aktivnosti Reprezentuje proces kao set aktivnosti od kojih svaka izvodi neku transformaciju podataka. Ovaj model pokazuje kako se ulaz u proces, kao to je specifikacija transformie u izlaz. Aktivnosti ovdje mogu reprezent transformacije izvedene od strane ljudi ili raunara.3. Role/Action (Uloga/Akcija) Reprezentuje uloge za ljude ukljuene u SW proces i aktivnosti za koje su odgovorni.

Veina modela procesa je bazirana na jednom od tri generalna modela ili paradigme razvoja SW:

1. Waterfall model (Model vodopada) uzima naprijed navedene akcije i reprezentuje ih kao separatne faze procesa, kao to su zahtjevi, specifikacije, dizajn, implementacija, testiranje itd. Nakon svake kompletno zavrene definisane faze prelazi se na novu fazu.2. Iterativni razvoj ispreplie aktivnosti specifikacije, razvoja i validacije. Inicijalni sistem se brzo razvija iz vrlo apstraktnih specifikacija. Zatim se prilagoava sa korisnikim ulazom kako bi produkovao sistem koji zadovoljava korisnikove potrebe. Tada sistem moe biti isporuenl, a alternativno moe biti reimplementiran upotrebom vie strukturnih pristupa kako bi se produkovao vie robusan sistem pogodan za odravenje.3. Component-Based Software Engeneering (CBSE) podrazumijeva da neki dijelovi sistema ve postoje. Proces razvoja sistema se fokusira na integraciji ovih dijelova, nego na razvoju iz poetka.

1.3 Modeli ivotnog ciklusa softveraImajui djelimine detalje softverskog razvoja, moemo identifikovati pet osnovnih faza u softver inenjeringu. Ove faze su ilustrovane na Sl. 4.1.

Slika 1.1 Faze ivotnog ciklusa softvera Neizbjeno, tokom vremena, sisteme treba razvijati i modernizovati, a odravanje softvera esto vodi ka specifikaciji novog poboljanja sistema. Moemo, stoga, zakljuiti da proces razvoja softvera postaje ciklus, poznat kao ivotni ciklus softvera koji se moe predstaviti razliitim modelima.

Definicija potreba (zahtjeva)Definicija potreba je vaan dokument za softver inenjering. Definisani zahtjevi moi e biti izlaz faze sistem analize u ivotnom ciklusu softvera. To ukljuuje opisivanje zahtjeva novog sistema, posebno opisanih kao funkcionalni i nefunkcionalni zahtjevi. Postoji razlika izmeu aktuelnih zadataka koji su bili izvreni novim sistemom (funkcionalni zahtjevi), i ponaanja i vremena u kojem e se ovi zadaci izvriti (nefunkcionalni zahtjevi). Kada je definisani zahtjev kompletiran, softver inenjer moe da pone zadatak dizajniranja softvera koji e biti implementovan.

Specifikacija potreba (zahtjeva)Specifikacija potreba je tehniki dokument u kojem softver inenjer predstavlja, na formalan nain, detalje sistema koji bi bio implementiran. To zahtijeva detaljnu analizu tipova podataka i struktura korienih u implementaciji i specifikaciji funkcija i procedura. Glavna karakteristika dobro specificiranog zahtjeva jeste da je jasan, taan i koncizan.

Dizajn softveraKada je softverski dokument specificiran i kompletan, softver inenjeru je omoguen prelazak u fazu dizajna. Pristupi softverskom dizajnu su uestalo bazirani na top-down metodu, koji omoguuje uspjenu dekompoziciju problema, ralanjivanjem u seriju potproblema. Ovo ponavljanje se vri uspjeno, dok svaki potproblem ne bude lake rijeen.

Implementacija softveraOd faze dizajna u ciklusu razvoja softvera, prelazimo u implementaciju, poto je softver pripremljen za upotrebu u sistemu. U ovoj fazi e biti donesene vane odluke. Odluka o izboru implementacionog sredstva je jedna od najvanijih za projekat. Implementacija softvera (SW) obuhvata odluku izmeu mogunosti implementacije novog sistema koristei postojee aplikacione pakete ili podesan specijalizovani softver kao alternativu pisanju programa u jeziku visokog nivoa. Ovo je sporno pitanje koje ponekad zanemaruju projektanti softvera uopteno, i softver inenjeri djelimino. Postoji jo niz veoma vanih pitanja. Pitanja programske prenosivosti i mogunosti odravanja su naroito vana, sve dok su prenosivost programa i jednostavno odrivi kd manje skupi za dugorono korienje. Posebno se treba nadati da e metodiki dizajnirani programi, koji koriste tehnike softver inenjeringa, biti dobro napisani, znatno laki za odravanje i relativno bez greaka.

Odravanje softveraKrajem 70-tih godina kompanije su potroile na odravanje i ispravljanje prethodno napisanih programa gotovo 80% svog ukupnog budeta za razvoj softvera. Ako je softver bolje projektovan i zbog toga laki za odravanje, dugorono bismo utedjeli.

Ostala pitanjaU traenoj definiciji identifikujemo funkcionalne i nefunkcionalne zahtjeve koji su vani u definisanju zahtjeva za novi sistem. Suvie je jednostavno koncentrisati se na funkcionalne zahtjeve za vrijeme implementacione faze softver inenjering projekta, jer pitanje: Da li e softver zaista raditi posao ili ne? - upravlja inicijalnim uspjehom projekta.Meutim, dugoronije, kvalitet softvera vjerovatno e biti prosuen od strane njegovog korisnika, vie prema nefunkcionalnim nego prema funkcionalnim karakteristikama. Stoga, brzina, jednostavnost upotrebe i kvalitet korisnikog interfejsa postaju vana sporna pitanja.

1.3.1 Preskriptivni modelPreskriptivni (propisani) modeli su dugo godina upotrebljavani da bi uveli red u SW. Svaki od ovih konvencionalnih modela sugerie razliit tok procesa ali svi slijede generiki set aktivnosti (komunikacije, planiranje, modeliranje, konstrukcija i isporuka sa povratnom spregom).

1.3.2 Model vodopadaOvaj pristup namee potrebu za detaljnim planiranjem svih aktivnosti prije poetka projekta preko razliitih elaborata i studija. Malo mjesta ostaje za kasnije improvizacije i podeavanja.Striktno pridravanje propisanog redosljeda faza, podfaza i aktivnosti, gdje izlazi jedne faze predstavljaju ulaze u sljedeu fazu dao je ovom nainu projektovanja softvera naziv vodopad kao asocijaciju na vodopade kojima lii tok informacija koje se kreu od jedne ka drugoj fazi projekta.

Propisane faze ovog projekta su sljedee:Sistem inenjerska analizaPrikupljanje i analiza zahtjevaDizajniranje sistemaKodiranjeTestiranje Odravanje sistema

U sluaju da je potrebno izvriti neke promjene vrlo teko je vratiti se na neki od prethodnih koraka to ovaj pristup ini prilino formalnim. Velika je orjentisanost na planiranje koje se izvri unaprijed ime se smanjuje potreba za stalnim planiranjem u toku realizacije. Ovaj model najkorisniji je kada su zahtjevi naruioca softvera strogi i do detalja unaprijed poznati. Danas se dosta koristi, a njegova primjena se preporuuje kod projekata koji imaju visoko rizine komponente kao to je medicina, ili javna bezbjednost.Dobre strane modela vodopada pristupa su: izlaz je unaprijed definisan, striktna kontrola moe dobro da radi i sa tehnikim i slabo potkovanim i neiskusnim osobljem, radi dobro kada su zahtjevi za kvalitetom visoki. Nedostaci su: faze nisu dobro povezane, potrebna je velika koliina dokumentacije, zasniva se na dokumentaciji, promjene se teko realizuju itd.

Model vodopada sugerie linearnu progresiju baznih aktivnosti. Meutim, prihvatljiv je samo onda kada su zahtjevi dobro definisani i stabilni.

Slika 1.2 Model vodopada

1.3.3 Inkrementalni i RAD modeli

Ovi modeli proizvode SW kao seriju inkremenata verzija. RAD (Rapid Application Development) modeli su dizajnirani za brzi razvoj aplikacija.

Inkrementalni model ili model ogranienog vremena zahtijeva formiranje relativno manjih potprojekata s niim stepenom meusobne integracije, koji se u velikoj mjeri razvijaju nezavisno, prema metodologiji ivotnog ciklusa. Potprojekti mogu biti fazno pomjereni u vremenu.

Primjenom pogodnog modela metodologije ivotnog ciklusa i prototipskog pristupa ispunjavaju se sljedei zahtjevi: Skraenje ukupnog vremena razvoja programskog proizvoda (poveanje produktivnosti) Nizak nivo rizika od neuspjeha pri razvoju programskog proizvoda

1.3.3.1 I-I model (Inkrementalno iterativni model)

Inkrementalni modeli proizvode softver kao seriju inkremenata (verzija). Inkrementalni model ili model ogranienog vremena zahtijeva formiranje manjih potprojekata s niim stepenom meusobne integracije, koji se u velikoj mjeri razvijaju nezavisno, prema metodologiji ivotnog ciklusa. Potprojekti mogu biti fazno pomjereni u vremenu. Ovaj model u osnovi posjeduje model vodopada poto svaki inkrement posjeduje pojedinano primijenjen model vodopada. Potpuno se razvija inicijalni podskup softvera, a zatim u sukcesivnim koracima, kao nadogradnja, razvijaju se novije i sloenije verzije. Svaki inkrement je kvalitetan ali zadovoljava samo podskup korisnikih zahtjeva. Inkrementi predstavljaju male dodatke kojima se upotpunjuju funkcije softvera.

Slika 1.3 Inkrementalni modelPrednosti inkrementalnog modela su:

Obezbjeuje se transparentan razvoj proizvoda, sa stalno vidljuvim rezultatima,Uvijek raspoloiv i funkcionalno upotrbeljiv proizvod koji zadovoljava odreeni podskup korisnikih zahtjeva,Lako razumijevanje i testiranje novorazvijenih inkremenata proizvoda jer oni samo dodaju nove funkcionalnosti postojeem upotrebljavanom softveru i na taj nain premoavanje traumatskih efekata uvoenja kompletno novog proizvoda odjednom,Postojanje povratne sprege i permanentne mogunosti ugradnje bogatog korisnikog iskustva u redefinisani proizvod na manje skup nain, putem novih inkremenata odnosno novih funkcionalnosti proizvoda,Umanjeni rizik od neuspjeha razvoja cjeline, jer se problemi uglavnom uoavaju u pojedinim inkrementima,Skromniji obim kapitalnih ulaganja u razvoj proizvoda i bri povrat investicija,Manji broj angaovanih osoba u procesu razvoja.Nedostaci inkrementalnog modela su:Dekompozicija proizvoda na inkremente, da bi se oni mogli integrisati, nije trivijalan zadatak, kao ni sam proces integracije, a da se pri tome ne ugrozi kvalitet ve postojeeg proizvodaSpecifikacija detaljnih korisnikih zahtjeva se kod svakog inkrementa izrauje neposredno prije nego to se on razvija,Integracija moe uvijek donijeti neoekivane probleme i potrebe za reorganizacijom, koja moe imati posljedice po efikasnost i odravanje,Korisnici imaju stalni elju da mijenjaju svoje zahtjeve.

1.3.3.2 RAD (Rapid Aplication Development) model

Osnovni principi za upotrebu RAD modela jesu jednostavnost struktuiranih formi ulaza i izlaza, to doputa mono sredstvo za definiciju ekrana (forms) i izlaznih izvjetaja (reports).Skrivene mane programskog proizvoda i prethodno neidentifikovani korisniki zahtjevi esto se otkrivaju tek u fazi uvoenja aplikacija u upotrebu, to je jako kasno. U cilju izbjegavanja negativnih efekata pojavili su se prototipski pristup i evolutivni, zvjezdasti i inkrementalni model.Alati koji su ukljueni u RAD su:Generatori aplikacija,Interfejs generatori (ulazne i izlazne forme)Kancelarijske aplikacije (Excel, Word itd.RAD karakterie razvoj u malim timovima koji su integrisani sa korisnicima. Komunikacija unutar tima i sa korisnicima obavlja se u neformalnom obliku. Ovaj model podrazumijeva inkrementalni razvoj sa veoma kratkim vremenskim ciklusima od 60 do 90 dana.

Slika 1.4 RAD (Rapid Application Development) modelPrednosti ovog modela su:Poveana brzina razvoja primjenom metoda prototipskog razvoja,Umanjena funkcionalnost za korisnika u umanjena kompleksnost,Vei naglasak na jednostavnost i upotrebljivost dizajna korisnikog interfejsaNedostaci su:Skromnije karakteristike proizvoda u ranijim ciklusima,Ubrzanje procesa razvoja dovodi do gubitka pregleda nad cjelinom sistema,Brzina moe postati sama sebi svrha pa se izrauju privremena i priruna rjeenja,Veliki projekti pri razvoju ovim modelom zahtijevaju dosta resursa da bi se kreirao odgovarajui broj RAD timova,Teka i problematina gradnja komponenti sistema ukoliko se sistem ne moe razloiti na module,RAD nije odgovarajui model ukoliko je tehniki rizik razvoja visok.

Tehnike etvrte generacije (4GT)RAD sr uglavnom implementira sa 4GT i CASE alatima. 4GT koje imaju slijedee karakteristike:: Specifikacija na visokom nivou Alati automatski generiu izvorni kod Podrane su od alata jezika etvrte generacije

Ogranienja: Poslovne aplikacije Za mala i srednja preduzea vrijeme za produkciju softvera se znatno smanjuje Za velike sisteme smanjuje se samo vrijeme kodiranja

Sl. 4GT

Dobre osobine 4GT metodologije ivotnog ciklusa jesu: Integrisanost informacionog sistema Dobra dokumentovanost Praktino istovremeni zavretak svih podsistema informacionog sistema Pojednostavljeno odravanje aplikacija informacionog sistema (zbog dobre dokumentovanosti) Mali rizik od neuspjeha

Nedostaci 4GT metodologije ivotnog ciklusa jesu: Krajnji korisnik nije dovoljno ukljuen u proces razvoja programskih proizvoda Vremenski interval od poetka projekta do primjenljivih rezultata je dosta dug esta je potreba da se precizni, metodoloki kompleksni projektantski koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva Ulaganje znatnih finansijskih sredstava odjednom

CASE alati

Nepostojanje softverskih alata koji podravaju projektovanje i razvoj aplikacija informacionih sistema ili automatizuju postupke projektovanja, kao i kompleksnost zadataka i tehnika koje se u metodologiji ivotnog ciklusa primjenjuju, predstavljaju motiv za pojavu CASE proizvoda. CASE (Computer Aided Software Engineering) predstavlja "raunarom podrano softversko inenjerstvo" ili "razvoj programskih proizvoda uz pomo raunara". CASE proizvod je bilo koji programski proizvod namijenjen za podrku ili automatizaciju makar jednog zadatka u okviru ivotnog ciklusa drugog programskog proizvoda ili je namijenjen za kompletnu podrku projektovanju i realizaciji drugog programskog proizvoda.Osnovni ciljevi primjene CASE proizvoda jesu: Obezbjeenje zadovoljavajueg kvaliteta projekta i projektne dokumentacije Obezbjeenje zadovoljavajueg kvaliteta samog programskog proizvoda Poveanje produktivnosti projektanata i programera Skraenje vremena projektovanja i realizacije programskog proizvoda Obezbjeenje jednostavnog i jeftinog odravanja programskog proizvoda

CASE proizvod treba da obezbijedi to vii stepen automatizacije prilikom izvoenja sljedeih zadataka: Voenje dokumentacije Izrada dijagrama i matrica Konceptualno i implementaciono projektovanje eme baze podataka Projektovanje programskih specifikacija aplikacija Generisanje programskog koda Sprovoenje izmjena Integracija parcijalnih rezultata projektovanja u jedinstvenu cjelinu Kontrola konzistentnosti, kompletnosti i kvaliteta projekta, itd.

Ovi proizvodi rade sa jedinstvenom bazom podataka rjenikom podataka, koji sadri podatke o svim elementima definisanim u okviru jednog ili vie projekata. Svi pojedinani alati jednog CASE proizvoda koriste i smjetaju podatke u isti rjenik (Sl. 5.1).

Sl. Rjenik podataka

CASE proizvodi se klasifikuju na razne naine. Prema fazama ivotnog ciklusa koje CASE proizvod pokriva, moemo izvriti klasifikaciju na: Projektantske CASE proizvode Podravaju prve tri faze ivotnog ciklusa Programerske CASE proizvode Podravaju druge tri faze ivotnog ciklusa Integrisane CASE proizvode Podravaju sve faze ivotnog ciklusa

Projektantski CASE proizvodiSavremeni CASE proizvod treba da sadri "inteligentne" alate, kao i alate koji u sebe ukljuuju elemente ekspertnog znanja. Tako projektant potuje formalna pravila upotrebe odgovarajue tehnike koja je podrana datim alatom, a dobiva i tehniku pomo u radu. S druge strane, alat prua projektantu odgovarajua projektantska rjeenja ili je u stanju da analizira, vrednuje i ocjenjuje rjeenja koja je sainio sam projektant.

Programerski CASE proizvodiPri razvoju informacionih sistema programerskim CASE proizvodima podrazumijevaju se generatori koda koji mogu: Na osnovu opisa implementacione eme baze podataka izgenerisati DDL (Data Definition Language) opis eme baze podataka za konkretan sistem za upravljanje bazama podataka i Na osnovu programskih specifikacija izgenerisati 4GL programe aplikacija informacionog sistema

Alati iz okruenja 4GL, kao i CASE proizvodi, oslonjeni su na jedinstven rjenik podataka. Tei se integraciji ovih alata sa CASE proizvodima u korienju zajednikog rjenika podataka, ime bi se obezbijedilo jedinstveno razvojno okruenje.

1.3.4 Evolutivni modeli (Model prototipa i Spiralnim model)

1.3.4.1 Model prototipa

Poslovanje u jednom realnom sistemu je veoma sloeno. Stalna je tenja poveanje efikasnosti, koje se ogleda u: Poveanju obima i kompleksnosti informacionih zahtjeva korisnika Skraenju traenog vremena potrebnog za realizaciju korisnikih zahtjeva putem programskog proizvoda

Prototipski pristup polazi od pretpostavke da tehnika snimanja i intervjua, kao i ostali klasini postupci, nisu dovoljni za precizno utvrivanje informacionih zahtjeva korisnika. Osnovna ideja je pravljenje provizornih rjeenja, tzv. prototipova. Putem prototipova korisnici i razvojni tim intenzivno sarauju u svim fazama ivotnog ciklusa. Mogua je brza intervencija na prototipu, tako da se korisnik moe lako uvjeriti u efekte promjene. Tako projektanti testiraju i poboljavaju prototipska rjeenja zajedno sa korisnikom.

Ciljevi primjene prototipskog pristupa treba da budu: Pravovremeno prikupljanje svih relevantnih informacija od korisnika Rano navikavanje korisnika na nain funkcionisanja aplikacija informacionog sistema.Preduslovi za primjenu prototipskog pristupa: Postojanje dobrih projektantskih i programerskih CASE proizvoda koji su integrisani sa okruenjem etvrte generacije Angaovanje iskusnog projektantskog tima Angaovanje grupe korisnika sa iskustvom u korienju informacionih tehnologija iz predmetne oblasti

Saglasno nivou funkcionalnosti, prototipovi se mogu klasifikovati: Nefunkcionani Funkcionalni FormalniPrototipove moemo klasifikovati i kao: Neodbacive Odbacive

Neodbacivi prototipovi se evolutivnim podeavanjem pretvaraju u konana rjeenja aplikacija.Dominantan cilj izrade odbacivog prototipa jeste precizna identifikacija informacionih zahtjeva. Dobiva se primjenom generatora koda, a koristi bazu podataka ija ema ne mora biti blizu konanog rjeenja.

Opte preporuke za primjenu prototipskog pristupa: Prije poetka primjene prototipskog pristupa, definisati precizno standarde za izgled korisnikog interfejsa, projektovanje i programiranje. Standardi treba da budu usaglaeni sa mogunostima odabranog CASE proizvoda. Preporuuje se dekomponovanje cjeline informacionog sistema na manje projekte. Prilikom davanja prototipa aplikacije, korisnika upoznati s injenicom da je u pitanju prototip, a ne konano rjeenje. Po mogunosti, ne praviti vie od tri prototipa jedne aplikacije, kako zbog vremena izrade aplikacije, tako i zbog zamora krajnjih korisnika i projektantskog tima. Radi postizanja to kraeg vremena dolaska do prototipa, treba se orijentisati preteno ka odbacivim prototipovima aplikacija, jer se izrada samog prototipa pojednostavljuje. Korisnik, koristei prototipove, treba da koristi test podatke. U prototip aplikacije ukljuiti, ako je mogue, odgovarajue izvjetaje. Tako korisnik lake sagledava upotrebljivost aplikacije. Prethodna rjeenja informacionih sistema mogu biti dobra podloga u funkciji prototipskog pristupa.

Slika 1.5 Izrada prototipa

Primjena prototipskog pristupa je u praksi pokazala neprimjenljivost ovog pristupa pri razvoju integralnih informacionih sistema.Direktna primjena ovog pristupa je preporuljiva pri razvoju izolovanih podsistema sa niskim stepenom meusobne integracije.Preporuljiva je, takoe, primjena ovog pristupa u kombinaciji s nekim od modela primjene metodologije ivotnog ciklusa.

Izrada prototipa je proces koji omoguava projektantu da kreira model softvera u tri forme: Papirni prototip Radni prototip za neke funkcije Upotreba egzistirajuih programa koji izvode dio funkcijaPrednosti ovog modela su: Poveana brzina i kreativnost u razvoju,Stalno obezbjeenje radne verzije proizvoda, koji slui analizi funkcionalnosti, preformantnosti i adaptibilnosti trokova,Kosrisnik je u svim fazama maksimalno ukljuen i moe mijenjati svoje zahtjeve to unapreuje kvalitet proizvoda.

Nedostaci su:Nemogunost kvalitetne i tane procjene i planiranja resursa,Korisnik uoava radnu verziju softvera ne znajui kako su njegovi dijelovi povezani i ne znajui da aspekti kvaliteta u izgradnji nisu uzeti u obzir,Korisnik vienu radnu verziju smatra konanom i nije spreman ekati dogradnju, ve se smatra prevarenim,Projektanti ine kompropmise u izgradnji da bi se prototipovi stavili to prije u funkciju, pa tako manje kvalitetna rjeenja ostaju u upotrebi,Neophodan je dogovor na startu projekta kojim bi se saglasili projektant i korisnik da prototip slui kao mehanizam definisanja zahtjeva, a sistem se razvija u cilju zadovoljenja kvaliteta i mogunosti odravanja.

1.3.4.2 Spiralni model

Spiralni model se zasniva na ideji "od globalnog ka detaljnom" u vie iteracija primjene faza i koraka metodologije ivotnog ciklusa (Sl. 4.6).

Bri prelazak u narednu fazu treba da obezbijedi bolje osnove za kasnije uspjeno okonanje prethodne faze. Ovaj pristup dolazi do izraaja kada se kombinuje sa prototipskim pristupom. Za utvrivanje informacionih zahtjeva preteno se primjenjuju odbacivi prototipovi. Projekat informacionog sistema se dijeli na niz manjih potprojekata koji pokrivaju pojedinane podsisteme. Radi se nekoliko verzija, tako da je svaka naredna bolje rjeenje dobiveno evolucijom prethodnog.Spiralni model kombinuje mogunosti prototipskog modela i modela vodopada. Nastao je iz modela vodopada i preuzeo osnovne metodologije iz modela vodopada, ali i eliminisao gotovo sve poznate faktore rizika iz njega. Predvien je za velike, skupe i komplikovane projekte. Spiralni model se sastoji iz etiri faze i to: planiranje, razvoj alternativa i analiza rizika, inenjering i procjene korisnika. Ove faze se meusobno smjenjuju jedna za drugom u cilju eliminisanja problema, koji su deavali kod modela vodopada. Ponavljanje faza pomae kod razumijevanja problema povezanih sa odreenom fazom i rjeavanje ovog problema u sljedeem ponavljanju faze, planiranju i razvoju strategija koje e se primjenjivati kroz naredne faze. Faze spiralnog modela su:

Planiranje. U ovoj fazi odreuju se ciljevi, alternative i ogranienja projekta. Definiu se ciljevi i druge specifikacije s ciljem odluivanja koja strategiju primijeniti tokom ivotnog ciklusa projekta.Razvoj alternativa i analiza rizika. Ova faza je najvaniji dio spiralnog modela. Analiziraju se sve mogue i realne alternative, koje mogu pomoi u razvoju isplativog projekta i biraju se strategije koje e biti koriene. Ako postoje rizici zbog bilo kojih nejasnoa u zahtjevima, na osnovu dostupnih podataka trae se mogua alternative s ciljem rjeavanja potencijalnih promjena u zahtjevima.Inenjering. U ovoj fazi sprovodi se razvoja projekta. Proizvod ove faze se provlai kroz sve ostale faze iterativno s ciljem postizanja poboljanja istog.

Procjene korisnika. Zaokruen proizvod se predaje korisnicima s ciljem dobijanja povratnih informacija, komentara i sugestija koji mogu pomoi u identifikovanju i rjeavanju potencijalnih problema u softveru. Ova faza je slina fazi testiranja.

Slika 1.6 Spiralni modelSvakom iteracijom se dobija kompletnija i sloenija verzija softvera, ali se realizuju i znaajno vei trokovi. Prva iteracija bi trebala da bude najvanija, jer u njoj treba ta se identifikuje to je vie mogue faktora rizika, ogranienja i zahtjeva i u narednim iteracijama se koriste sve definisane strategije da se napravi kompletan softver.Prednosti ovog modela su:U kratkom vremenskom intervalu realizuje se funkcionalan proizvod,Svaki ciklus razvoja se zavrava ocjenom rizika, koja predstavlja osnovu daljeg razvoja,Najrealniji model razvoja softvera za velike sisteme, jer omoguuje brzu reakciju na uoeni rizik,Posjeduje ugraenu sistematinost i temeljitost modela vodopada, ali istovremeno i mogunost izvoenja iteracija i prototipskog razvoja.Nedostaci su:Zahtjeva viu uniformnost i konzistetnost u razvoju,Skup model za primjenu na malim projektima jer analiza rizika zahtjeva specifine ekspertize koje su skupe,Probleme stvara neblagovremeno otkrivanje rizika koji multiplikuju probleme,Relativno kratko vrijeme primjene, oskudno iskustvo i veoma uska primjena.

1.3.5 Specijalizovani procesni modeli

1.3.5.1 Model baziran na komponentama Model baziran na komponentama (Component-Based Model) koristi Reuse i Assembly tehnike. Reuse tehnika se bazira na koritenju postojeih modula a Assembly na njihovom komponovanju u cjelinu.Model zasnovan na komponentama je povezan sa spajanjem postojeih softverskih komponenata u vee dijelove softvera. Osnovu ovog procesa ini saznanje da su komponente napisane tako da obezbjeuju funkcionalnosti koje su zajednike za veinu razliitih sistema. Pozajmljujui ideju od hardverskih komponenti, cilj modela zasnovanog na komponentama je da omogui dijelovima (komponentama) softvera da budu zamijenjeni novijim, funkcionalno ekvivalentnim komponentama.

Slika 1.7 Model zasnovan na komponentamaKomponenta se moe definisati kao softverski paket ili modul koji enkapsulira skup srodnih funkcija ili podataka. Svi sistemski procesi su smjeteni u posebne komponente na taj nain da su svi podaci i funkcije unutar svake komponente semantiki srodne.Sa stanovita koordinacije sistem, komponente meusobno komuniciraju preko interfejsa. Kada komponenta slui kao servis ostatku sistema, ona prihvaa interfejs kojim je opisano na koji nain servis moe biti iskorien od strane drugih komponenti. Interfejs se moe posmatrati kao signatura komponente tako da klijent ne treba da zna kako komponenta funkcionie iznutra, odnosno kako je implementirana, da bi je koristio.Kada komponenta treba da koristi drugu komponentu da bi obavljale neku funkciju, ona prihvata zahtjevani interfejs koji propisuje servise koje treba. Vana osobina komponenata je da su zamjenljive tako da komponenta moe biti zamijenjena drugom, ako komponenta nasljednik ispunjava uslove komponente koju mijenja.Reusability je jo jedna veoma bitna karakteristika kvalitetnih komponenata. Softverska komponenta bi trebala biti dizajnirana i implementirana tako da moe biti iskoriena u razliitim programima. Potreban je znaajan napor i svijest da bi se projektovala i programirala softverska komponenta koja ispunjava ovu karakteristiku. Komponenta treba da bude:Potpuno dokumentovanaVie puta testiranaProjektovana sa svijeu da e biti koriena u nepredvidive svrhe.

1.3.5.2 Formalni modeli

Ovi modeli se baziraju na matematikom pristupu razvoja SW-a i njegovoj verifikaciji.Upotreba formalnih metoda motivisana je oekivanjem da primjena odgovarajuih matematikih analiza pouzdanosti i robusnosti dizajna. Meutim, visoka cijena upotrebe formalnih metoda znai da su one obino koriene u razvoju visoko-integrisanih sistema gdje sigurnost igra veoma znaajnu ulogu.Formalne metode mogu biti koriene na nekoliko nivoa:

Nivo 0. Preduzima se formalna specifikacija, a onda se iz nje program razvija neformalno. Ovo je takozvana lagana formalna metoda i ovo je najisplativij pristup za mnoge sluajeve.Nivo 1. Formalni razvoj i formalna verifikacija se koriste da se napravi program na formalniji nain. Ovaj pristup je pogodan za visoko-integrisane sisteme ukljuujui sigurnost.Nivo 2. Dokazivanje teorema. Ovo je najskuplji i najvrjedniji pristup ako je cijena greke izuzetno velika (npr. u projektovanju kljunih dijelova mikroprocesora).

Formalnim metodama moe se opisati sistem koji treba da se razvija ne bilo kojem nivou detaljnosti. Ovaj formalni opis moe se dalje iskoristiti za aktivnosti razvoja. Takoe, moe posluiti da se provjeri da li su zahtjevi kvalitetno i precizno specificirani.

1.3.5.3 Aspektno orijentisani modeli

Aspektno orijentisani modeli se zasnivaju na lokalnom SW karakteristikama koje su modelirane kao komponente (objektno orijentisane klase).

1.3.6 Unificirani procesi bazirani na UML

Unificirani procesi zasnovani na UML (Unified Modeling Language) voeni su sluajevima upotrebe (use case), inkrementalni su i interaktivni.Model unificiranih procesa se sastoj iz faza elaboracije, konstrukcije i tranzicije koje su izdijeljene u seriju vremenskih iteracija. Poetna faza takoe moe da bude podijeljena u iteracije ako se radi o veem projektu. Rezultat svake iteracije je inkrement, koji predstavlja novo izdanje sistema sa dodanim ili poboljanim funkcionalnostima u poreenju sa prethodnim izdanjem. Iako svaka interacija podrazumijeva rad na veini procesnih disciplina (npr. prikupljanje zahtjeva, dizajn, implementacija, testiranje) naglasak se mijenja kako se projekat razvija.

Slika 1.8 Model unificiranih procesaPoetak. U ovoj fazi definiu se opta vizija zahtjeva, inicijalni mode sluajeva upotrebe, inicijalna procjena rizika i plan projekta.Elaboracija. Analizira se domen problema, postavlja arhitektura sistema, razvija se plan projekta i identifikuje rizik.Konstrukcija. Pristupa se detaljnom dizajnu. Razvijaju se komponente i aplikacija testira njihova integracija. Izrauju se korisnika uputstva i prirunici.Tranizicija. Aplikacija se predaje korisnicima na upotrebu, ispravljaju se eventualni problemi. Izrauje se projektna dokumentacija. Vri se obuka korisnika.Drugu dimenziju ovog modela ine procesi:Bisnis modelovanje,Zahtjevi,Analiza i dizajn,ImplementacijaTestiranje iUvoenje.Procesi se odvijaju kroz faze i u svakoj fazi postoji vie ili manje iteracija.Model unificiranih procesa posjeduje prednosti i mane identifikovane kod inkrementalnog modela i spiralnog modela jer podrava iteracije i stalnu analizu rizika.

1.4 Trokovi SE

Jednostavan odgovor ne postoji, jer distribucija trokova kroz razliite aktivnosti zavisi o upotrebljenom procesu i tipu softvera koji je razvijen. Npr. REAL TIME softver uobiajeno zahtijeva ekstenzivniji validaciju i testiranje nego web-bazirani sistemi. Meutim, svaki od razliitih generikih pristupa razvoju softvera ima razliit profil distribucije trokova kroz aktivnosti procesa softvera. Ako se procjenjuje da ukupnui trokovi razvoja jednog kompleksnog sistema jesu 100 jedinica troka, onda sl. 1. ilustruje kako su isti potroeni na razliite aktivnosti procesa. U pristupu vodopada trokovi specifikacije, projektovanja, implementacije i integracije i testiranja su odvojeno mjereni. Sistem integracije i testiranja jesu najskuplje razvojne djelatnosti, to je oko 40% od ukupnih razvojnih trokova, ali za neke kritine sisteme to je vjerovatno najmanje (bar) 50% od trokova razvoja sistema. Ako je sofver razvijen korienjem iterativnog pristupa ne postoji vrsta veza izmeu specifikacije, projektovanja i razvoja. Trokovi specifikacije su redukovani. Specifikacija, projektovanje, implementacija, integracija i testiranje su izvedeni paralelno unutar razvojne aktivnosti. Meutim, potrebna je i dalje jedna nezavisna aktivnost testiranja sistema kada zapoeta implementacije bude zavrena.SE baziran na komponentama je iroko upotrebljavan za samo kratko vriojeme. U ovom pristupu nemamo tanu sliku trokova za razliite razvojne aktivnosti softvera. Meutim, znamo da su trokovi razvoja redukovani u odnosu na trokove integracije i testiranja. Trokovi integracije i testiranja su porasli jer se moramo uvjeriti da koriene komponente rade sa ostalim komponentama kako se oekuje.Trokovi razvoja variraju u zavisnosti od tipa sistema. Za sistema koji se mogu koristiti 10 godina i due, razvojni trokovi e se povisiti faktorom 3 ili 4 (sl. 1.1).

Manji poslovni sistemi imaju znatno krai ivotni vijek i odgovarajue reducirane trokove razvoja.

Sikal 4.1 Distribucija trokova aktivnosti SE

Za softverske proizvode koji su (veinom) prodati za PC-ijeve, profil trokova je vjerovatno razliit. Ovi proizvodi su uglavnom razvijeni korienjem evolutivnog pristupa. Trokovi specifikacije su relativno niski. Meutim, s obzirom da oni nastoje da budu korieni u rangu razliitih konfiguracija, moraju biti iroko testirani. Slika 2 prikazuje profil trokova koji se mogu oekivati za ove proizvode.Trokovi evolucije za generike softverske proizvode je naroito teko procijeniti. Kada je napravljena jedna verzija, poinje se sa izradom nove zbog trita. Sljedea verzija bi se najvjerovatnije predstavila kao jedan nov (ali kompatibilan) proizvod, prije nego modifikovana verzija proizvoda koju je korisnik ve kupio. Zbog toga trokovi evolucije nisu oporezovani, nego su jednostavno razvojni trokovi za sljedeu verziju.

1.5 Kvalitet softvera

Ako bismo upitali softver inenjera ili programera: ta se podrazumijeva pod terminom visokokvalitetni softver?, odgovor bi, vjerovatno, sadravao neto ili sve od sljedeeg:

Softver koji funkcionieDokle god softver sadri greke, sigurno se isplati razmatrati pitanje da li je detalj softvera bez greke, ili - da li on jo uvijek sadri greke koje e prouzrokovati da se proizvede pogrean odgovor, kvar, ili e se SW izvesti na neki nepodesan nain Softver koji se izvodi prema svojoj specifikacijiIako neki softver izgleda kao da je bez greke, on proputa da se izvodi po svojoj specifikaciji. Da li je problem u tome to program radi suvie sporo, ili to program nije dovoljno fleksibilan prema buduim promjenama? Softver koji je dobro ''inenjerisan'' i koji je mogu za odravanjeSoftver koji je dobro napisan treba da bude takav da ga je relativno lako poboljati, ako to situacija zahtijeva. Zbog toga bi softver inenjer koji prosuuje program trebalo da provjeri koliko je jednostavno promijeniti program, ako to bude potrebno.

Ako bismo upitali korisnika softvera: ta je potrebno za stvaranje visokokvalitetnog softvera, koji odgovor bismo dobili? Odgovor bi bio u vezi sa konkretnim korienjem softvera. Korisnik je naviknut da ima proizvode koji rade i razmatrajui pitanja kvaliteta, razmiljao bi o tome da li proizvod izvrava posao koji se od njega oekuje.

Druge osobine koje utiu na kvalitet jesu:

Brzina razvoja:

Proces razvoja softvera je notorno spor. Proizvodnja novog detalja softvera moe, tipino, biti mjerena po principu: ovjek/godina rada. To je veoma skup posao, i svaki novi pristup i dodatne alatke koje mogu ubrzati proces bie atraktivne, iako su ponuene po relativno visokoj cijeni (iziskuju velike trokove). Isporuka u roku:

Izgleda da na cijelu kompjutersku industriju imaju uticaja kompanije koje lansiraju novi proizvod predvienog datuma. esto se deava da se i softver i hardver pojavljuju na tritu nakon predvienog, najavljivanog datuma. Ovo se deava djelimino zbog toga to kompanije uvijek revnosno reklamiraju nove proizvode koje nude atraktivnu alternativu onome to je ponueno od strane njihovih konkurenata, tako da potencijalne muterije mogu znati za nove detalje. Meutim, gotovo ravnopravno relevantna injenica je da veina softverskih razvoja zahtijeva mnogo vie vremena za zavretak nego to je to na poetku bilo predvieno. Ovo moe biti prouzrokovano mnogim problemima.

Oskudan projekt menadment:

Ponekad je projekat neadekvatno planiran i voen, tako da je tokom razvojnog procesa izgubljeno vrijeme na ekanje da se zavri kritina etapa u procesu, prije nego to se moe zapoeti rad na sljedeoj etapi. Razliite menadment strategije mogu pomoi u menadmentu projekta. Neki od ovih pristupa su podrani od strane softver alata projekt menadmenta.

Oskudan dizajn ili inenjering:

Vjerovatno najvei razlog kanjenja u zavravanju softver projekata jeste potreba da se isprave greke u dizajnu ili implementaciji programa. Mnogo ee, problemi u dizajnu se ne pojavljuju do zavrne faze u razvojnom procesu, a zatim je neophodno ponovno pisanje i redizajniranje programa. Zatim, suvie vremena je, esto, potrebno za testiranje programa, jer oni nisu bili napisani tako da vjerno prate dizajn.

Brzo prilagoenje osoblja:

Kompjuterska industrija dugo pati od bre promjene osoblja u poreenju sa drugim industrijama. To je djelimino zbog rapidnog rasta u industriji, to nije uvijek postignuto odgovarajuim porastom u obezbjeivanju visokokvalifikovanih i iskusnih kompjuterskih naunika, softver inenjera, analitiara itd. Takoe, na problem je uticala i injenica da kompjuterizacija namjerava i nastoji da privue mlau radnu snagu, koja je, u svakom sluaju, mobilnija u zapoljavanju. Svaka od ovih kombinacija vjerovatno e dovesti do nekoliko promjena u promjeni osoblja za vrijeme i tokom razvojnog perioda.

Oskudna dokumentacija:

Usko povezan sa prethodnim stavom jeste problem oskudne dokumentacije, proizvedene od strane osoblja tokom razvojnog procesa softvera. Za mnoge osobe koje razvijaju softver, rjeavanje problema i pisanje programa predstavlja interesantan dio posla, ali pisanje rezultata u podesnom obliku dokumenta je mnogo manje atraktivno. Zbog toga dokumentacija formira osnovu buduih modifikacija softvera, a takoe pomae novoj osobi da razvija softver, u sluaju promjene osoblja. Naravno, bolji menadment projekta bi mogao osigurati da programeri i svi ostali ukljueni u razvojni proces softvera proizvode potrebnu dokumentaciju, i to u pravo vrijeme.

Opisana su sporna pitanja koja treba razmotriti u procjenjivanju kvaliteta razvojnog procesa softvera.

Osnovni zakoni vezani za realizaciju kvaliteta:

1. Kvalitet se planira, proizvodi i realizuje, a ne samo "ispituje"2. Kontrola kvaliteta predviena je za stalnu korekciju procesa nastanka kvaliteta

Onaj kome je u interesu istinski kvalitet proizvoda, ne trai krivce, nego greke i njihove uzroke.

Mjerenje kvalitet softvera

Kao to je ve reeno, jedan od glavnih ciljeva softverskog inenjerstva je proizvodnja visoko kvalitetnih sistema, aplikacija i proizvoda unutar vremenskog okvira koji zadovoljava trite. Softverski kvalitet je kompleksan miks faktora koji variraju zavisno od aplikacija i kupaca. Faktori koji afektiraju softverski kvalitet se mogu klasifikovati u dvije glavne grupe: faktori koji mogu biti direktno mjereni (npr. defekti otkriveni prilikom testiranja) i faktori koji se mogu mjeriti samo indirektno (npr. upotrbljivost, pogodnost odravanja). Kvaliteta je odreen sledeim faktorima:

korektnost pogodnost odravanja integritet upotrebljivost portabilnost

Pouzdanost kao jedan od najbitnijih faktora je razmatrana zasebno, u daljem tekstu, jer zasluuje posebnu panju. Takoe nisu razmatrani faktori kao to su: efikasnost, fleksibilnost, testabilnost, ponovna upotreba i interoperatibilnost. Izgradnja visoko pouzdanog softvera zavisi od uea atributa kvaliteta u svakoj fazi ivotnog ciklusa razvoja, naroito u ranim fazama. Korektnost se definie kao stepen kako softver izvodi zahtijevane funkcije. Osnovni kriteriji za za korektnost su: kompletnost konzistencija mogunost ostavljanja traga

Za mjerenje korektnosti najee upotrebljavana je izvedena metrika tj. broj greaka po broju linija koda, gdje se greke definiu kao neusaglaenost sa zahtjevima. Greke se broje u standardnim vremenskim periodima npr. godina dana sa aspekta vrednovanja kvaliteta softvera. Inae se greke broje prije isporuke i poslije isporuke softvera da bi se imao uvid u efikasnost njihovog odstranjivanja.

Integritet softvefra je dobio poseban znaaj u zadnje vrijeme zbog poveanog broja razliitih napada cyber kriminalaca i hakera. Cilj napada su sve tri komponente softvera: prgrami, podaci i dokumenti. Osnovni kriteriji za integritet su:

kontrola pristupa (access control) provjera pristupa (access audit)

Da bi se mjerio integritet softvera moraju se definisati dva dodatna atributa: prijetnje (threat) i sigurnost (security).

Threat-ovi su vjerovatnoa da e se napad specifinog tipa dogoditi unutar zadanog vremena. Ova vjerovatnoa moe biti oekivana ili dobijena iz empirijskih podataka. Integritet podataka podrazumjeva da neautorizovani korisnici ne mogu modifikovati (promjeniti podatak, premjestiti podatak i dodati pogrean podatak) bilo koji podatak bez dozvole vlasnika.

Security je vjerovatnoa odbijanja napada specifinog tipa i dobija se isto kao i vjerovatnoa threat-ova (oekivanje, empirija). Npr. ako je vjerovatnoa da e se napad dogoditi 0.30 i vjerovatnoa da e napad biti odbijen 0.95 integritet sistema je 0.985 i to je prihvatljivo. Ako je vjerovatnoa napada 0.50 a vjerovatnoa odbijanja napada 0.25 integritet od 0.63 je neprihvatljiv.

Kada je u pitanju upotrebljivost softvera treba voditi rauna o lakoi upotrebe u terminima iskustvo, brzina uenja, brzina rada, rad bez kontinuirane pomoi, interakcijski mehanizmi itd. Ako program nije lagan za upotrebu on moe proizvesti nevolje ak i ako su funkcije koje izvidi regularne. Kriteriji za upotrebljivost su: operativnost trening komunikativnost volumen inputa i outputa frekvencija inputa i outputa

Sve ovo bi trebalo kvantifikovati i jedna tako kvantifikovana mjera je efektivnost zadatka koja obuhvata kvantitet kompletiranog zadatka i kvalitet dostignutog cilja i pokazuje lakou upotrebe. Pogodnost odravanja se ogleda u lakoi razumjevanja, poboljanja i korektnosti. Osnovni kriteriji pouzdanosti su:

konzistencija jednostavnost konciznost modularnost samodokumentovanost

Odravanje ukljuuje nekoliko tipova izmjena. Izmjene mogu biti korektivne, adaptivne, preventivne i perfektivne. Pogodnost odravanja nije ograniena samo na kod nego i na specifikaciju, projektnu dokumentaciju i test plan dokumente. Kao i kod upotrbljivosti i ovdje postoje eksterni i interni atributi Kada se identifkuje potreba za izmjenu, brzina implementacije izmjene je kljuna karakteristika pogodnosti odravanja. Mnoga eksterna mjerenja pogodnosti odravanja su izraena preko MTTR (Mean Time To Repair) tj. srednjeg vremena za implementaciju izmjene. Da bi izraunali ovu metriku treba paljivo prikupti sledee informacije o vremenima potrebnim za:

prepoznavaje problema analizu problema administrativno kanjenje sakupljanje alata za odravanje specifikaciju izmjene izmjenu

Za tekstualne produkte itljivost se smatra kljunim aspektom pogodnosti odravanja. Dobro poznata mjera za itljivost je Gunning-ov Fog indeks F:

F = 0.4 * WC / SW + PW3

WC broj rijeiSW broj reenicaPW3 broj rijei od tri i vie slogova

Mjerenje portabilnosti, mogunosti da se apllikacija sa jednog sistema prebaci na drugi, uglavnom zavisi od korisnika. Karakteristike portabilnosti su: modularnost samodokumentovanost mainska nezavisnost softverska nezavisnost

Mjerenja mnogih faktora kvaliteta su subjektivne prirode. Iako su poeljna objektivna mjerenja bolje je mjeriti bilo ta nego nita.

Kada su u pitanju faktori kvaliteta softvera postavlja se pitanje odnosa faktora tj. ako je kvalitet jednog faktora visok koji se stepen kvaliteta oekuje za druge faktore. Te relacije su prikazane u Tabeli 3.

Tabela 3. Relacuje izmeu faktora kvaliteta softvera

korekt.integr.upotr.odr.port.

korektnostyy

integritety

upotrebljivostyyy

odravanjeyyy

portabilnosty

y visoka relacijablank nema relacije ili je aplikaciono zavisna

Pouzdanost softvera

Pouzdanost se definie kao niz atributa koji predstavljaju mogunost softvera da odri svoj nivo performansi pod odreenim uslovima u odreenom periodu vremena i ona je jedan od kljunih faktora kvaliteta softvera.(ISO 9126). Kod softvera ne postoji troenje ili starenje i ogranienja u nepouzdanosti su posledica greaka u zahtjevima, projektovanju i implementaciji.

Podkarakteristike pouzdanosti su zrelost (maturity) tj. svojstvo softvera koje odraava frekvenciju greaka uslijed nedostataka u softveru, otpornost prema grekama (fault tolerance) tj. svojstvo softvera da odri odreeni nivo performansi u sluaju greke i oporavljivost (recoverability) tj. svojstvo softvera da ponovo uspostavi svoj nivo performansi i povrati podatke na koje je direktno uticao u sluaju greke.

Izgradnja visoko pouzdanog softvera zavisi od uea atributa kvaliteta u svakoj fazi ivotnog ciklusa razvoja sa naglaskom na prevenciju greaka, specijalno u ranim fazama. Da bi se ovi atributi mjerili sa ciljem poboljanja kvaliteta i pouzdanosti potrebno je definisati softverske metrike za svaku razvojnu fazu (zahtjevana dokumentacija, kod,planovi testiranja i testiranje).

IEEE 982.1-1988 definie upravljanje pouzdanou softvera kao proces optimizacije softvera kroz tri aktivnosti u kontekstu ogranienja u projektu kao to su resursi, vremena i performanse:

Prevencija greke (error) Detekcija i otklanjanje fault-ova Mjerenje da bi se maksimizirala pouzdanost za prve dvije aktivnosti

Kada su u pitanju greke onda dolazi do zbrke u terminima error, fault, failure koji se upotrebljavaju za istu stvar premda imaju razliito znaenje. U sluaju softvera error je obino programerska greka koja koja rezultira u fault-u. Fault je softverski defekt koji prouzrokuje failure, failure je neprihvatljiva programska operacija u odnosu na programske zahtjeve.

Da bi se mjerila pouzdanost softvera potrebne su odgovarajue softverske metrike U Tabeli 1. date su dobro poznate metrike koje treba da odgovore na tri kompleksna pitanja vezana za zahtjeve, kod i testiranje a u cilju poboljanja pouzdanosti i pronalaenje modula sklonim greka

Svakako da je broj metrika prevelik i da bi ga trebalo redukovati na manji broj jednostavnih i prihvatljivih metrika zavisno od okruenja i aspekta gledanja.Zahtjevi specificiraju funkcionalnost koja mora biti ukljuena u finalni softver i moraju biti struktuirani, kompletni i jasni za komunikaciju izmeu projektanta i korisnika.Dvije bitne metrike za vrednovanje dvosmislenosti termina su broj slabih fraza (npr. adekvatan, odgovarajui, normalan itd.) i broj opcionalnih fraza (npr. moe, smije, opcionalno itd.). Takoe treba izbjegavati i nekompletne termine kao to su treba da bude dodano i treba da bude determinisano. Vanost korektno dokumentovanih zahtjeva je prouzrokovala da se na tritu pojave specijalizovani alati za mjerenje kvaliteta specifikacije zahtjeva npr. ARM (Automated Requirements Measurement). Metrike za pouzdanost dizajna i koda se uglavnom odnose na veliinu produkta izraenu u broju linija koda (LOC-Lines Of Code), kompleksnost koda izraenu preko ciklomatskog broja (McCabe) i modularnost produkta. to je modul kompleksniji vee su potekoe u negovom razumjevanju i vea je vjerovatnoa defekata nego u manje kompleksnim modulima Iako su veliina i kompleksnost korisne metrike esto se koristi i njihova korelacija da bi se dobile dodatne informacije. Za kvalitet objektno orijentisanih struktura koriste se OO metrike.

Kod testnih metrika postoje dva pristupa za vrednovanje puzdanosti. Prvi se odnosi na vrednovanje test plana da se obezbjedi da sistem ima funkcionalnost predvienu specifikacijom zahtjeva. Tabela 1. GQM za poboljanje pouzdanostiGOAL (ciljevi)QUESTIONS(pitanja)METRICS (metrike)

Kakav je kvalitet zahtjeva(dokumenta)?Broj linija tekstaImperativi-komandne rijei i frazeFraze koje slijede imperative (zahtjevi na niem nivou)Direktive-reference na slike, tabele i napomeneSlabe fraze-neizvjesnost i viestruka interpretacijaNekompletnost iskazaOpcije opsne rijei zbog irine znarnja

Poboljanje pouzdanosti softvera i identifikacija zahtjeva i koda koji su potencijalni uzronici greakaKakav je kvalitet dizajna i koda?Veliina koda (KLOC)Kompleksnost koda (McCabe)FP (funkcionalne take)Modularnost (coupling, kohezija)OO Metrike WMC, DIT, NOC, CBO, RFC, LCOMPonovna upoteba koda (reuse(c))

Koliki je broj pronaenih greaka, Vrijeme izmeu greaka, Vrijeme da nastane grekeVrijeme otklanjanja greke, Frekvencija dogaanja greakaPredvianje broja preostalih greaka ?Broj otkrivenih defekataMTBF (Mean Time Between Failure)MTTF (Mean Time To FailureMTTR (Mean time to Repair)RCOF (Rate of Occurence of failures)Vrijeme testiranjaVrijeme upotrebeBroj testnih sluajevaKLOC, McCabe, FP (za razne normalizacije)

Drugi pristup vezan za pouzdanost se sastoji u vrednovanju broja greaka u kodu i ratama njihovog fiksiranja i otklanjanja. Podaci o grekama se dobijaju za vrijeme testiranja i stvarne upotrebe softverskog produkta. Ovi podaci se koriste za izgradnju modela pouzdanosti na osnovu koga se moe izvriti predikcija vremena slijedee greke na osnovu istorijata prethodnih greaka.

4.6 Upravljanje rizikom

Dobar softverski produkt se mora napraviti na vrijeme i u okviru predvienog budeta i kvaliteta, to donosi odeen rizik. Rizik se moe definisati kao neto to ne bismo eljeli da se dogodi. Zbog toga je upravljanje rizikom jedan od glavnih poslova menadera projekta i uzima znaajno vrijeme u planiranju projekta.

Postoje tri kategorije rizika koji se mogu preklapati:

1. Rizik projekta se odnosi na raspored i resurse (npr. nedostatak iskusnih programera).2. Rizik produkta se odnosi na kvalitet i performanse produkta.3. Poslovni rizik, npr. uvoenje novog produkta.

Procesi u upravljanju rizikom ukljuuju: Identifikaciju rizika Planiranje rizika Analizu rizika Monitoring rizika

Identifikacija rizika obuhvata: Tehnoloki rizik Veliinu produkta Personal (veliina i iskustvo) Definiciju procesa Alate Karakteristike korisnika itd.

Tabela 1.1 Rizici, tipovi i opisi

RizikTip rizikaOpis

PersonalProjektNaputanje personala prije zavretka

Izmjene u menadmentuProjektIzmjene u organizaciji i prioritetima

Nedostatak HWProjektPotrebni HW nije isporuen na vrijeme

Promjena zahtjevaProjekt i produktVeliki broj izmjena

Kanjenje specifikacijeProjekt i produktSpecifikacija potrebnih interfejsa nije raspoloiva na vrijeme

Veliina sistemaProjekt i produktVeliina sistema je ispod oekivanja

Alati ispod performansiProduktAlati ne rade onako kako se oekivalo

Promjene u tehnologijiPoslovniTehnologija na kojoj se bazira sistem je prevaziena

Kompetencije produktaPoslovniNapravljen je marketing prije nego to je sistem kompletiran

Planiranje rizika je proces koji odeuje strategije za upravljanje rizikom i postoje glavne kategorije:

Strategija izbjegavanja podrazumijeva smanjenje vjerovatnoa rizika Minimizaciona strategija podrazumijeva da dodir sa rizikom bude minimiziran. Planovi za sluajne dogaaje predviaju spremnost za najgore dogaaje

Analiza rizikaZa vrijeme analize mora se razmotriti svaki identifikovani rizik i napraviti procjena vjerovatnoe i ozbiljnosti rizika. Ove aktivnosti najvie zavise od iskustva menadera i personala. Vjerovatnoa ovih rizika se klasifikuje kao to je prikazano u Tabeli 1.2.

Tabela 1.2 Rizici i njihovi procenti

Vrlo nizak75%

Efekti rizika se mogu svrstati u etiri kategorije: Katastrofalni Ozbiljni Tolerantni Nevani

Monitoring rizika je kontinuiran proces koji ukljuuje vrednovanje svakog identifikovanog rizika i odluuje kada rizik moe biti vie ili maje vjerovatan.

1.7 AGILE razvoj softvera

Agile (brz, hitar, okretan) je koceptualni okvir za razvoj softvera. Postoji mnogo razliitih Agile metoda. Veina od ovih metoda pokuava da minimizira rizik razvojem softvera u kratkim vremenskim intervalima, nazvanim iteracijama, u roku od jedne do etiri nedjelje. Svaka iteracija izgleda kao mini softverski projekt i ukljuuje sve SW zadatke, nivoe funkcionalnosti: planiranje, analizu zahtjeva, dizajn, kodiranje, testiranje, odravanje i dokumentaciju.

Agile metode pretpostavljaju komunikaciju u realnom vremenu izmeu uesnika projekta koji su potrebni za zavretak softvera, i to po mogunosti "licem u lice". Ovi timovi se minimalno sastoje od programera i naruioca (customers ljudi koji definiu produkt, tj. produkt menaderi, poslovni analitiari, stvarni naruioci, interfejs dizajneri itd.).

Agile metode naglaavaju softver koji radi kao primarnu mjeru progresa u razvoju. Kombinovane sa "licem u lice" komunikacijom, ove metode produkuju vrlo malo dokumentacije u odnosu na druge metode i ovo im je jedna od glavnih zamjerki.

Agile metodologije su familija metodologija nastalih na bazi sastanka 17 strunjaka za razvoj softvera u Juti (Utah), 2001. god., koji su se usaglasili i napisali Manifesto for Agile Software development (www.agilemanifesto.org). U Manifestu oni tvrde da su otkrili bolji nain razvoja softvera radei na tome i pomaui drugima da rade isto. Kroz ovaj rad doli su do sljedeih stavki (procjena, vrijednosti):Individuali i interakcije u vezi sa procesima i alatimaSoftver koji radi u vezi sa sadrajnom dokumentacijomKolaboracija naruioca prilikom potpisivanja ugovoraOdgovornost za izmjene tokom sprovoenja plana

Autori daju prednost stavkama na lijevoj strani gornjih iskaza.

Principi Manifesta su sljedei:

Najvei prioritet je zadovoljenje naruioca kroz ranu i kontinuiranu isporuku ispravnog SW i dobrodoli zahtjevi za izmjene, ak i u kasnoj fazi razvoja. Frekventna isporuka SW koji radi za nekoliko nedjelja ili nekoliko mjeseci, sa trendom da se ovo vrijeme skrati. Poslovni ljudi i oni koji razvijaju SW moraju raditi zajedno, i to dnevno, tokom razvoja projekta. Projekt moraju raditi motivirani individuali i njima treba staviti sve resurse na raspolaganje i mora im se vjerovati. Najefikasniji i najefektivniji nain za prenos i razmjenu informacija je komunikacija sa razvojnim timom - licem u lice. SW koji radi je primarna mjera progresa projekta. Agile procesi promoviu ustaljen, sistematski razvoj. Sponzori, projektanti i korisnici su u mogunosti da odravaju konstantan korak beskonano. Konstantna panja posveena tehnikim prednostima i dobar dizajn poboljavaju brzinu (agility). Esencijalna je jednostavnost, a ne umjetnost maksimiziranja koliine posla. Najbolja arhitektura, zahtjevi i dizajn proizilaze od samoorganizovanih timova. U regularnim intervalima timovi razmatraju kako da postanu efektivniji i, prema tome, vre razliita podeavanja i prilagoenja.

1.7.1 Komparacija sa drugim tipovima metodologija

Agile metode se esto kvalifikuju kao kraj spektruma suprotan od planom voenih (plan-driven) i disciplinovanih metodologija. Iz ovoga slijedi da su agile metode neplanske i nediscplinovane. Meutim, veina metoda egzistira na kontinuumu od adaptivnih do prediktivnih metoda i, ako ovako posmatramo, agile metode egzistiraju na adaptivnoj strani kontinuuma.

----Agile-- ----Iterativne -- ----Waterfall------------------------------------------------------------------------------ADAPTIVNE PREDIKTIVNE

Adaptivne metode se baziraju na brzoj adaptaciji za izmjene u projektu. Jedan od problema za adaptivni tim je da opie ta e se dogoditi u budunosti. I odreivanje datuma kada e se ta dogoditi je nejasno i obino adaptivni tim moe egzaktno opisati koji e zadaci biti zavreni idue sedmice, i to samo onda ako postoji mjeseni plan. Na pitanje kakva e situacija biti za est mjeseci, adaptivni timovi mogu samo rei da nemaju plan za to.

Prediktivne metode, za razliku od adaptivnih, baziraju se na detaljnom planiranju budunosti. Prediktivni timovi mogu jasno da odgovore koji su zadaci planirani u toku cjelokupnog trajanja razvoja, ali zato imaju potekoa kada su u pitanju izmjene koje dovode do toga da se u nekim sluajevima veliki dio uraenog posla mora raditi ponovo.

Mnoge Agile metode koriste iterativni razvoj za izgradnju isporuivog SW u kratkim vremenskim periodima, ali se razlikuju od iterativnih metoda u mjerenim vremenskim periodima (radije u sedmicama nego u mjesecima).

Agile razvoj ima malo zajednikog sa modelom vodopada. Model vodopada je najprediktivnija metodologija u svim fazama razvoja (zahtjevi, analiza, dizajn, kodiranje, testiranje, eksploatacija). Ovdje se razvoj mjeri po isporuenim produktima po fazama (specifikacija zahtjeva, dokumentacija za dizajn, testni planovi itd.). Model vodopada ima tipine vremenske periode od nekoliko mjeseci do nekoliko godina za substancijalne integracije do kraja ciklusa. Veliina i potekoe u ovim integracijama, kao i napor uloen u testiranje, jedan su od uzroka za greke u projektu. Na drugoj strani, Agile metode produkuju kompletno razvijene i testirane stavke (mali subset svake) svake nedjelje ili mjeseca. Cilj Agile metodologije je da se dobije grub ali izvodljiv sistem to prije i da se kontinuirano poboljava. Neki Agile timovi upotrebljavaju model vodopada u malom, ponavljajui kompletan ciklus vodopada u svakoj iteraciji, dok npr. timovi za ekstremno programiranje (Extreme Programming - XP) rade na aktivnostima simultano.

Poto Agile timovi uglavnom komuniciraju "licem u lice" i rjee upotrebljavaju dokumentaciju, neki ljudi dolaze u zabludu mijeajui to sa "kaubojskim" programiranjem. Meutim, Agile timovi slijede definisane, vrlo disciplinovane i rigorozne procese, to ih razlikuje od "kaubojskog" programiranja.

Upotreba Agile metodologije je uglavnom bazirana i dobro dokumentovana za manji broj istraivaa (< 10 istraivaa) po zajedniki lociranim timova. Agile timovi se susreu sa nepredvidivim zahtjevima koji se brzo mijenjaju.

Ako se baziramo na analizi rizika, onda je baza Agile metoda: Nizak kriticizam Stariji istraivai Visoko zahtijevane izmjene Mali broj istraivaa Kultura u vezi sa haosom

Na drugoj strani, planom voene metode se baziraju na: Visokom kriticizmu Mlaim istraivaima Malim zahtjevima za izmjenu Malim brojem istraivaa Kulturom koja odbija nove zahtjeve

1.7.2 AGILE metodologije

Agile SW metodologije uljuuju sljedee: Ekstremno programiranje (XP) Scrum (www.controlchaos.com) ASD (Adaptive Software Development) http://www.adaptivesd.com/) Crystal Clear and Other Methodologies (http://alistair.cockburn.us/) DSDM (http://na.dsdm.org/) Feature Driven Development (www.featuredrivendevelopment.com) Lean Software Development (www.poppendieck.com)

Agile metodologije obuhvataju softverske pristupe koji vode ka najbroj isporuci SW i objanjavaju kako: Iterativni i inkrementalni pristup vode ka broj isporuci korisnog softvera. Razlikovati Agile metode i metode koje se baziraju na dobro dokumentovanoj specifikaciji i dizajnu. Razlikovati principe i ogranienja XP programiranja Upotrijebiti prototip za rjeavanje zahtjeva i dizajna nezavisno od specifikacijom baziranog pristupa.

1.7.3 Ekstremno programiranje (Extreme Programming - XP)

XP je najpoznatija i najire upotrebljavana Agile metoda u kojoj su svi korisniki zatjevi prikazani kao scenariji (korisnike prie) koji su implementirani kao serija zadataka. Programeri rade u parovima i razvijaju testove prije pisanja koda. Svi testovi moraju biti uspjeno izvedeni prije nego to se novi kod integrie u sistem. Inkrement sistema koji se razvija veoma se brzo isporuuje, a faze su prikazane na Sl. 1.9.

Korisnikova priaPlan isporukePria razbijena u zadatkeVrednovanje sistemaIsporuka SWRazvoj, integracija i testiranje

Slika 1.9 Inkrement sistema koji se razvija

Principi Agile metoda, kao to je prkazano na gornjoj slici, jesu: Inkrementalni razvoj Puno ukljuenje naruioca kroz sve ivotne faze razvojnog ciklusa SW. Programiranje u paru, to podrazumijeva zajedniko vlasnitvo nad SW. Naruilac je sve vrijeme direktno ukljuen u sve faze razvoja SW. Promjene su podrane kroz regularna izdanja SW, razvoj u smislu testiraj prvo i kontinuiranu integraciju. Odravanje je podrano kroz kontinuirano poboljanje kvaliteta koda i jednostavnost dizajna.

U XP procesu zahtjevi se ne tretiraju kao lista sistemskih funkcija i tu je naruilac dio razvojnog tima i on razmatra scenario sa ostalim lanovima tima. Ekstremno programiranje prati i priznaje osnovne principe agilne metodologije, pri emu taj skup moe proiriti i razviti, zavisno od projekta koji se realizuje. XP je kompleksan pojam koji sadri u sebi etiri sastavna dijela. To su vrijednosti, principi, aktivnosti i praksa ekstremnog programiranja koji nadograuju jedan drugog. XP predstavlja sinergiji ova etiri elementa koja vodi uspostavljanju visokog nivoa kvaliteta krajnjeg proizvoda.

Slika 1.10 Inkrementalni modelVrijednostiVrijednosti XP predstavljaju potovanje i nadogradnju osnovnih vrijednosti agilnog razvoja softvera. U ekstremnom programiranju je od izuzetnog znaaja da one budu poznate i prihvaene u timu. Ove vrijednosti treba istaknuti na vidna mjesta u radnom prostoru sve dok ih tim ne prihvati. Oosnovne vrijednosti u ekstremnom programiranju su: komunikacija, jednostavnost, hrabrost i povratna veza.Komunikacija. Loa komunikacija ne dolazi sluajno. Primjeri loe komunikacije su:-programer ne kae nita o bitnim izmjenama u programu-programer ne postavlja prava pitanja korisniku-manager ne postavlja prava pitanja programeru-programer zaboravlja ili ignborie vanu vijest itd. Mnoge okolnosti tj. veze korisnik-manager-programer utiu na to i XP pokuava da korienjem praktinih mehanizama u radu prevazie probleme u tim vezamai. Jako je vano da se znanje i informacije nesmetano kreu jer bez toga nema znaajnijeg uspjeha.Jednostavnost. XP je posveeno jednostavnosti i njeguje princip je da je bolje dananji posao zavriti to jednostavnije i sa manjim trokovima, pa ga kasnije nadograditi ako treba, nego odmah uraditi na komplikovan i skup nain, troei vie vremena i novca iako se to moda nikada nee trebati.

Hrabrost. Ovo je vrijednost koja podrazumijeva stalnu borbu sa promjenama i rizicima, kako na tritu tako i unutar tima. Ovo je prihvatanje i primjena novih tehnolokih rjeenja, kao i hrabrost da se dio uraenog posla odbaci i pone iznova, ako je potrebno. Ova vrijednost je vezana i za samopouzdanje i pouzdanje u rad tima.Povratna veza. Ovo je etvrta vrijednost u XP. XP programer uvijek mora imati povratnu vezu o stanju svoga posla u svim vremenskim skalama (minuti, sati, dani, nedjelje). Ovo isto se odnosi i na korisnika tj. na kvalitet njegove prie (opis zahtjeva) . Da bi se vidjeli rezultati obe strane trae da se sistem pusti u produkciju to prije i to zahtjeva da programner ivi sa sistemom u produkciji (stalna prisutnost).Ove vrijednosti su u velikoj mjeri povezane i nemaju efekta ako se primjenjuju izolovano jedne od drugih.PrincipiKao i vrijednosti i principi ekstremnog programiranja proizilaze iz manifesta agilne metodologije proirujui i konkretizujui njihovo znaenje u svakom pojedinanom projektu. Vrijednosti nam pruaju osnovne kriterijume po kojima se sagledava uspjenost posla, ali su suvie iroke da bi se na osnovu njih mogli definisati praktini mehanizmi za osiguravanje uspjenosti. Osnovni principi su:Brza povratna sprega. Umjesto da se na odgovor od klijenta eka mjesecima ili godinama, oni informaciju vraaju u roku od nekoliko dana ili nedjelja. Programeri u roku od nekoliko minuta ili sekundi saznaju da li je dizajn dobar i da li program radi, umjesto da na to ekaju danima ili nedjeljama. To pojaava razumijevanje i uenjePretpostavljena jednostavnost. Pretpostavljajui da je svaki problem trivijalno jednostavan u rjeavanju Vrijeme koje se tako utedi, daleko prevazilazi vrijeme koje se izgubi u rijetkim sluajevima kada ova pretpostavka nije tana.Inkrementalne promjene. Svaka velika promjena se razbija u niz minimalnih koraka. Sve vrste promjena treba sprovoditi u malim pomacima inkrementima.Prihvatanje promjena. Najbolja strategija je da se rjeavaju prvo gorui problemi, pa tek onda oni sitniji.Kvalitetan rad. Jedino mogue vrijednosti kvaliteta su odlino i perfektno, nita manje. U suprotnom se ne uiva u poslu, to izaziva pad performansi.

Pored osnovnih principa postoje i sporedni koji pomau u donoenju odluka u specifinim situacijama kao to su male poetne investicije, igra na pobjedu, konkretni eksperimenti, otvorena i potena komunikacija, korienje a ne potiskivanje ljudske intuicije, prihvatanje a ne nametanje odgovornosti, lokalno prilagoavanje ekstremnog programiranja, lagani alati razvoja, potena evaluacija.Svi ovi principi, zajedno sa vrijednostima, ine jezgro ekstremnog programiranja.

Aktivnosti

Aktivnosti su ono to proizilazi iz vrijednosti i principa i vane su za definisanje ponaanja tima u odreenim radnim situacijama i imaju jedino smisla kada odraavaju te vrijednosti i principe, a takoe moraju biti sprovedene na striktno propisan nain pomou obaveznih praktinih mehanizama. Aktivnosti ekstremnog programiranja su sljedee:

Kodiranje. Ovo je oblik komuniciranja i predstavlja preslikavanje ideja u softver. Izvorni kod je osnovni element kompjuterskog programa. Preko njega se materijalizuju ideje, ali i ista i nedvosmislena komunikacija, kako s mainom tako i sa kolegama. On moe izraavati ideje za rjeenje problema, ali i testove, takoe se moe koristiti i za opis algoritama i ukazivati na mogua mjesta daljeg razvoja sistema. Najbolja mjera ispravnosti je kod koji radi.Testiranje. Na osnovu funkcionalnih testova, klijent odreuje pravac daljnjeg rada. Na taj nain se poboljava i komunikacija meu klijentima i programerima.Sluanje. Polazi se od tvrdnje da programeri ne znaju nita o poslovnoj logici, te oni moraju aktivno da sluaju klijenta. Aktivno sluanje se odnosi na ukazivanje klijentu ta je tee, a ta lake izvesti. Iz razgovora s klijentom mora se izvui to vie korisnih informacija, koje e kasnije pomoi u razumijevanju sistema. Potrebna je esta komunikacija s klijentom, kome se postavljaju pitanja i paljivo sluaju odgovori.Dizajn. U ekstremnom programiranju dizajn je evolutivne prirode. On tei jednostavnosti i smanjenju redundantnosti koda. Dijagrami i planovi nisu centralni elementi dizajna, ve je to izvorni kod. Ovo je jo jedna revolucionarna promjena u nainu razmiljanja programera.Ove aktivnosti se moraju sprovoditi na smislen i strukturiran nain. Ne mogu se izvoditi haotino i proizvoljno. Za uspostavljanje planskog i organizovanog izvoenja ovih aktivnosti koriste se obavezne prakse.Obavezna praksa u XPObavezna praksa u ekstremnom programiranju predstavlja skup praktinih mehanizama pomou kojih se sprovode aktivnosti i realizuje razvoj softvera metodom XP. Postoji dvanaest ovih mehanizama koji se sprovode ekstremno disciplinovano. Ova ekstremna posveenost praksi bila je uticala na naziv metode ekstremnog programiranja. Kroz slijedee mehanizme naglaavaju se aktivnosti u smjeru principa i vrijednosti:Programiranje u paru. U XP programeri rade u paru. Dva programera sjede za jednim raunarom radei na istom zadatku.Planiranje igre. Planiranje unaprijed je brzo i grubo. Ne treba se predugo zaustavljati oko plana koji treba dati osnovne smjernice.Razvoj voen testovima. Ne treba pisati ni jednu liniju koda prije nego to se napie test koji taj kod treba da zadovolji. Cilj kodiranja se svodi samo na zadovoljavanje testova. Klijent takoe testira rjeenja i pomou rezultata testa upravlja razvojem.Cjelokupnost tima. U timu bi trebao da se nae i predstavnik klijenata koji bi u timu igrao ulogu strunog savjetodavca. On pie prie korisnika, vri funkcionalno testiranje i razjanjava nejasnoe u hodu.Stalna integracija. Kako se komponenta zavri, sistem se integrie. Mora postojati odgovarajui nain za praenje promjena u kodu koji dozvoljava ponitavanje izmjena, ako je potrebno.Poboljanje dizajna (refaktorisanje). Svaki put kada se unapreuje neka komponenta, to se vri pomou refaktorisanja. Povremeno je potrebno pregledati cio kod i refaktorisati ga kako bi se odrao itljivim.Male verzije. Razvoj se vri u malim iteracijama. To smanjuje cijenu promjena i odbacivanja loih reenja. Svaka nova verzija se daje klijentu na testiranje i korienje to ga ukljuuje u proces razvoja.Kolektivno vlasnitvo koda. Svi su vlasnici svega, poto svi rade sve. Tako se izbjegava posveenost pogrenim idejama i rjeenjima, otpor promjenama i olakava homogenizacija znanja i vjetina u timu.Metafora u sistemu. Olakava komunikaciju i pojaava osjeanje pripadnosti grupi. Tim razvija svoj rjenik i termine za obiljeavanje karakteristika sistema i svega ostalog.Odriv korak. Potrebno je uspostaviti harmonini ritam u radu koji treba biti odriv na duge staze. Treba odrediti jednake intervale trajanja iteracija koji se dobija praenjem dosadanjih aktivnost.

Testiranje u XP-u

Kao to je prije navedeno, jedna od glavnih razlika u iterativnom razvoju i planski baziranom razvoju jeste nain testiranja sistema i iterativni razvoj nema sistemske specifikacije koja moe biti upotrijebljena za eksterno testiranje od strane razvojnog tima.

Da bi se ovo izbjeglo, XP mora posvetiti vie panje procesu testiranja nego ostale Agile metode. Sistemsko testiranje mora smanjiti vjerovatnou da novi inkrementi ne unose greke u postojei SW.

Osnovni elementi testiranja u XP-u su: Test prije razvoja. Inkrementalni test za scenario. Ukljuenje korisnika u testiranje i validaciju. Upotreba automatizovane opreme za testiranje.

1.7.4 Programiranje u paru

Jedna od inovacija u praksi je programiranje u paru, to podrazumijeva da dva programera sjede zajedno i razvijaju isti SW. Ovo ne mora znaiti da uvijek dva ista programera sjede zajedno za istom radnom stanicom. Ideja je da se parovi kreiraju dinamino, tako da veina lanova tima moe komunicirati za vrijeme razvojnog procesa.

Upotreba programiranja u paru ima slijedee prednosti:

Zajedniko vlasnitvo i odgovornost. Lake otklanjanje greaka, jer dvojica pregledaju kod koji su sami napravili. Refaktoriranje (poboljanje) SW-a je mnogo lake, jer se vri veoma esto.

1.7.5 Brzo razvijanje aplikacija (Rapid Application Development - RAD)

Premda su Agile metode popularne u zadnjim godinama, veina poslovnih sistema je razvijena iterativno, koritenjem metodologije brzo razvijenih aplikacija. Ovo proizilazi iz 4GL, koji se upotrebljavaju na podacima intenzivne aplikacije. Oni obuhvataju niz alata koji omoguavaju da podaci mogu biti kreirani, pretraeni i prikazani u odgovarajuoj formi.

Alati koji su ukljueni u RAD jesu: Programiranje baze podataka. Interfejs generatori (ulazne i izlazne forme). Kancelarijske aplikacije (Excel, Word..).

Osnovni principi za upotrebu RAD-a su jednostavnost strukturiranih formi inputa-a i output-a, to doputa mono sredstvo za definiciju ekrana i izlaznih izvjetaja.

Skrivene mane programskog proizvoda i prethodno neidentifikovani korisniki zahtjevi esto se otkrivaju tek u fazi uvoenja aplikacija u upotrebu, to je jako kasno. U cilju izbjegavanja negativnih efekata pojavili su se prototipski pristup i evolutivni, zvjezdasti i inkrementalni model.

Ovaj pristup postaje u punoj mjeri praktino primjenljiv pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE proizvoda koji su integrisani s okruenjem etvrte generacije.

4.7.6 Adaptive Software Development (ASD)

Adaptive Software Development (ASD) se fokusira na razvoj velikih kompleksnih sistema. Ova metoda snano podrava inkrementlni i iterativni razvoj sa stalnim prototipiziranjem. ASD je u osnovi balansiranje na ivici haosa njegov cilj je da obezbijedi okvir koji ograniava projekat da zapadne u haos, ali ne previe, to moe podstai kreativnost.

ASD projekat odvija se kroz tri faze i to pekulisanje, kolaboracija i uenje.

Slika 1.11 ASD fazeFaze su imenovane tako da naglase promjenu uloge u procesu. pekulisanje se koristi umjesto Planiranja, jer se plan posmatra kao neto gdje je nejasnoa slabost i da odstupanje od njega generie greku. Kolaboracija naglaava znaaj timskog rada, jer se radi o razvoju visoko-promjenljivih sistema. Uenje znai potrebu za znanjem i reakciju na greke i injenicu da zahtjevi mogu sutinski da se mijenjaju tokom razvoja. Na sljedeoj slici detaljno je prikazan ASD ciklus razvoja. Faza iniciranja projekta definie stubove projekta i poinje definisanje misije projekta. Jedna od najvanijih stvari kod definisanja misije projekta jeste da se odredi koje informacije su potrebne za voenje projekta. Vani aspekti misije definisani su u tri stvari: Dokument vizije projekta, Tehniki podaci projekta Skica specifikacije proizvoda.U inicijalnoj fazi odreuje se opti raspored aktivnosti kao i raspored aktivnosti prema razvojnim ciklusima. Ciklusi obino traju izmeu etiri i osam nedjelja.

Slika 1.12 ASD(Adaptive Software Development) model

ASD je vie orjentisan ka komponentama nego ka zadacima. Ovo u praksi znai da je vie fokusiran na rezultate i kvalitet nego na zadatke ili procese koritene da se doe do rezultata. ASD to realizuje kroz adaptivne cikluse koji sadre fazu kolaboracije gdje vie komponenti mogu konkurentno da se razvijaju.Osnova za dalje cikluse (petlja uenja) izvedena je iz provjera kvaliteta, koji se fokusiraju na demonstraciji funkcionalnosti softvera razvijenog tokom ciklusa. Vaan faktor u izvoenju provjera je postojanje korisnika kao grupe eksperata. Meutim, poto provjere kvaliteta same po sebi nisu dovoljne (deavaju se na kraju svakog ciklusa), postojanje korisnika je podrano sa JAD (Joint Application Development) sistema.JAD sesija je u sutini radionica gdje se programeri i predstavnici korisnika sastaju da bi diskutovali o eljenim funkcionalnostima proizvoda i da poboljaju komunikaciju. ASD ne propisuje raspored za odravanje JAD sesija ali se skrea panja da su posebno znaajne u ranijim fazama projekta.Zavrna faza u ASD je zavrna Q/A (Kvalitet i sigurnost) faza i izdanje. ASD ne propisuje kako ova faza treba biti voena, ali naglaava sakupljanje nauenih lekcija.Adaptivnu prirodu ASD metode karakterie sljedee: Voenost misijom. Aktivnosti u svakom od ciklusa moraju biti prilagoene misiji projekta. Misija je promjenljiva u toku razvoja projekta. Baziranost na komponentama. Aktivnosti na razvoju ne bi trebale biti okrenute zadacima nego treba da se fokusiraju na razvoj softvera koji radi. Iterativnost. Serijski modeli, kakav je model vodopada, funkcioniu samo u unaprijed razumljivim i dobro definisanim okruenjima. Meutim, veina razvoja je turbulentna i treba da se usmjeri ka ponovnom radu nego na uraditi to na pravi nain iz prvog pokuaja. Vremenska odreenost. Nedoumice u kompleksnim softverskim projektima mogu biti iskorijenjene postavljanjem opipljivih i realnih rokova. Vremenska odreenost podstie uesnike projekta da donose vane odluke u ranim fazama projekta. Tolerantnost na promjene. Promjene su este u razvoju softvera. Meutim, vanije je biti sposoban prihvatiti ih nego kontrolisati. Da bi napravili sistem tolerantan na promjene programeri moraju stalno imati na umu da postoji mogunost promjene onoga to su ve napravili. Voenost rizikom. Razvoj visoko-rizinih dijelova treba da zapone to je ranije mogue.

1.7.7 Dynamic Systems Development Method (DSDM)Od samog poetka DSDM je posta broj jedan okvir za rapidni razvoj aplikacija (RAD). DSDM je neprofitan okvir za RAD razvoj i odrava ga DSDM konzorcijum. Osnovna ideja DSDM je da umjesto odreivanja koliine funkcionalnosti u proizvodu, i prema tome usklaivanja vremena i resursa potrebnih da se dostignu funkcionalnosti, preferira se odreivanje vremena i resursa a onda na osnovu toga odreuje se koliina funkcionalnost.DSDM se sastoji iz pet faza: studija izvodljivosti, biznis studija, iteracija funkcionalnog modela, iteracija dizajna i razvoja i implementacije. Prve dvije faze su sekvencijalne i rade se samo jedan puta. Posljednje tri faze, za vrijeme kojih se radi posao razvoja, su iterativne i inkrementalne. DSDM pristupa iteracijama kao vremenski odreenima. Vremenska odrednica je unaprijed definisan period, i iteracija treba da se zavri unutar predodreenog vremena. Vrijeme predvieno za svaku iteraciju se blagovremeno planira, prema rezultatima koje e iteracija garantovano proizvesti. U DSDM tipino trajanje vremenskih odrednica je od nekoliko dana do nekoliko sedmica.

Slika 1.13 DSDM (Dynamic Software Development Method)Studija izvodljivosti jeste faza u kojoj se procjenjuje primjerenost DSDM datom projektu. Sudei prema vrsti projekta, i to je jo vanije pitanjem ljudi, donosi se odluka da li koristiti DSDM ili ne. Drugim rijeima, studija izvodljivosti je vezana za tehnike mogunosti izvoenja projekta i samim tim rizinost. Pripremaju se dva proizvoda izvjetaj izvodljivosti i nacrt plana razvoja. Opciono, moe se kreirati brzi prototip ako posao ili tehnologija nisu dovoljno poznate, da bi bilo mogue odluiti da li se prelazi u narednu fazu ili ne. Studija izvodljivosti ne bi trebala da traje vie od nekoliko sedmica.Biznis studija je faza u kojoj se analiziraju osnovne karakteristike biznisa i tehnologije. Preporuuje se organizovanje radionica, gdje se skuplja odreen broj eksperata sa strane korisnika da bi razmotrili sve relevantne aspekte sistema, i da bi se sloili oko prioriteta razvoja. Obuhvaeni procesi i grupe korisnika opisani su u dokumentu Definicija poslovnog podruja. Identifikacija obuhvaene grupe korisnika pomae kod ukljuivanja korisnika, tako da kljune osobe u organizaciji korisnika mogu biti prepoznate i ukljuene u ranijim fazama. U ovom dokumentu detaljno su opisani procesi u odgovarajuem formatu (ER dijagrami, biznis modeli itd.).Postoje jo dva izlazna dokumenta faze biznis studije. Jedan je Definicija arhitekture sistema i drugi je Plan nacrta prototipa. Definicija arhitekture je prva skica arhitekture sistema i dozvoljena je njena promjena za vrijeme trajanja DSDM projekta. Prototipski plan bi trebao sadravati strategiju za naredne stepene i plan sastava menadmenta.Faza iteracije funkcionalnog modela je prva iterativna i inkrementalna faza. U svakoj iteraciji planira se sadraj i pristup iteraciji, deava se iteracija i analiziraju se rezultati za narednu iteraciju. Vre se analiza i kodiranje, prave prototipi i steeno iskustvo se koristi za poboljanje analize modela. Prototipi se ne odbacuju potpuno nego se postepeno dovode do kvaliteta koji bi mogao da zadovolji sistem u konanici. Izlaz ove faze jeste Funkcionalni model koji se sastoji od koda prototipa i analize modela. Testiranje je kontinuirano i esencijalni je dio ove faze.Postoje jo etiri izlaza ove faze (u razliitim nivoima faze).Prioritetne funkcije. To je lista funkcija sloena prema prioritetima koja se isporuuje na kraju iteracije.Funkcionalno prototipska revizija dokumenata. Objedinjuje korisnike komentare o trenutnom inkrementu.Nefunkcijski zahtjevi. Nabrojani su prvenstveno zbog toga da bi bili razmatrani u sljedeoj fazi.Analiza rizika za dalji razvoj. Ovo je vaan dokument u ovoj fazi, jer bi u fazi koja slijedi (dizajn i razvoj), eventualne probleme bilo tee uoiti.Faza dizajna i razvoja je faza gdje je sistem u stvari razvija. Izlaz je Testiran sistem koji ispunjava minimum prihvaenih zahtjeva. Dizajn i razvoj su iterativni i dizajn i funkcionalni prototip ocjenjuju korisnici i dalji razvoj zasnovan je na komentarima korisnika.Zavrna faza je faza implementacije. Sistem se prenosi iz razvojne sredine u produkciono okruenje. Obuavaju se korisnici i isporuuje im se sistem. Ako obuka obuhvata veliki broj korisnika i zahtijeva dui vremenski period faza implementacije takoe moe biti iterativna. Pored isporuenog sistem, izlaz faze implementacije takoe ukljuuje Korisniko uputstvo i Izvjetaj revizije projekta. Na osnovu posljednjih zakljuaka i rezultata postavljaju se pravci daljeg razvoja. DSDM definie etiri pravca daljeg razvoja. Ako sistem zadovoljava sve zahtjeve nije potreban dodatni rad. Nasuprot tome, ako postoji znaajna koliina zahtjeva (na primjer, ako nisu otkriveni dok je sistem bio u razvoju), proces moze krenuti ponovo od poetka do kraja. Ako postoje manje kritine funkcionalnosti koje zahtijevaju doradu proces moe otpoeti ponovo od faze iteracije funkcionalnog modela nadalje. I na kraju ako odreena tehnika pitanja nisu mogla biti rijeena zbog vremenskog ogranienja, ona sada mogu biti uraena kroz novu iteraciju, startujui od faze dizajna i razvoja.

1.7.7.1 Uloge i odgovornost

DSDM definie 15 uloga za korisnike i programere. Najznaajnije e biti opisane u daljnjem tekstu.Programeri i senior programeri su jedine programerske uloge. Pojam senior odnosi se na iskustvo u zadacima i programerskim poslovima. Titula senior takoe oznaava liderstvo u timu. Uloga programera pokriva cjelokupno programersko osoblje bilo da se radi o analitiarima, dizajnerima, koderima ili testerima.Tehniki koordinator odreuje arhitekturu sistema i odgovoran je za tehniki kvalitet projekta. Takoer je odgovoran za tehniki kontrolu projekta.Od uloga korisnika najznaajnija je uloga predstavnika korisnika. Njegova dunost je da znanje korisnika prenese na projekat i da informacije o napretku projekta iri ostalim korisnicima. Ovime se osigurava da se dobije adekvatna koliina povratnih informacija od korisnika. Predstavnik korisnika treba da dolazi iz zajednice korisnika koja e koristiti sistem. Ako predstavnik korisnika nije sposoban da se prezentuje sva potrebna gledita korisnika uvodi se dodatna uloga korisnika savjetnika. Korisnik savjetnik moe biti bilo koji korisnik koji prezentuje gledita sa aspekta projekta. Savjetnik npr. moe biti osoba iz IT sektora ili finansijski savjetnik.Vizionar korisnik koji najbolje razumije poslovne ciljeve sistema i projekta. Vizionar je takoe osoba sa inicijalnom ideju razvoja sistema. Zadatak vizionara je da osigura da esencijalni zahtjevi postoje u ranoj fazi projekta i da projekat ide u pravom smjeru sa stanovita tih zahtjeva.Izvrni sponzor je osoba koja pripada organizaciji korisnika i koja ima finansijski autoritet i odgovornost. Izvrni sponzor ima posljednju rije u donoenju odluka.

1.7.8 ScrumPojam scrum potie od strategije u igri ragbi, i oznaava momenat kada se protivniki timovi skupljaju na gomilu i bore za posjed lopte. To nije vezano, osim simboliki, za softverski projekat.Scrum metodologija je razvijena za upravljanje procesom razvoja. To je iskustveni pristup, gdje se primjenjuju ideje teorije industrijskih procesa rezultujui pristupom koji uvodi ideje fleksibilnosti, prilagodljivosti i produktivnosti. Ovaj pristup ne definie posebne tehnike razvoja softvera za fazu implementacije. Scrum se fokusira na to kako lanovi tima trebaju funkcionistai u cilju postizanja fleksibilnosti sistema u konstantno promjenljivom okruenju.Osnovna ideja je da razvoj sistema ukljuuje nekoliko varijabli (npr. zahtjevi, vremenski okvir, resursi i tehnologija) koji su skloni promjenama u toku procesa. Ovo ini proces razvoja nepredvidivim i kompleksnim i zahtijeva fleksibilnost procesa razvoja da bi bilo mogue odgovoriti promjenama. Kao rezultat procesa razvoja dobija se sistem koji je funkcionala i upotrebljiv.Scrum je od pomoi kod poboljanja postojee inenjerske prakse (npr. testiranja) u organizaciji, on pored postojee prakse uvodi uestale aktivnosti menadmenta s ciljem konzistentnog identifikovanja nedostataka i prepreka u procesu razvoja.Scrum proces se odvija u tri faze: pred-igra, razvoj i post-igra.

Slika 1.14 Scrum proces1.7.8.1 ProcesiFaza pred-igre obuhvata dvije podfaze: Planiranje i arhitektura/Dizajn na visokom nivou.Planiranje obuhvata definiciju sistem koji se razvija. Kreira se lista neizvrenih zadataka i ona sadri sve zahtjeve koji su poznati do tog trenutka. Zahtjevi mogu poticati od korisnika, slube prodaje i marketinga, podrke ili osoba koje uestvuju u razvoju softvera. Zahtjevi se rangiraju prema prioritetu i procjenjuje se potrebno vrijeme za njihovu implementaciju. Lista neizvrenih zadataka se konstantno aurira sa novim i detaljnijim stavkama, kao i sa preciznijim odreivanjem i novim rasporedom prioriteta. Planiranje takoer obuhvata i sastav tima koji radi na projektu, alatima i ostalim resursima, procjenu rizika, potrebe obuke i odobrenje menadmenta. Kroz svaku iteraciju Scrum tim ra