UVOD U PROGRAMSKO INENJERSTVOSoftver ukljuuje sam program, ali i svu dokumentaciju i potrebne konfiguracijske datoteke. Razlikujemo dvije vrste softvera: generiki (igrice, office) i kastomiziran (custom-made radi se tono prema narudbi). Razlika izmeu njih se sve vie smanjuje - napravi se generiki softver koji se prilagodi potrebama naruitelja. Programsko inenjerstvo je inenjerska disciplina koja se bavi sa svim aspektima razvoja softvera (od specifikacija pa sve do odravanja). Programski inenjeri bi trebali koristiti sistematian i organiziran pristup najede najuinkovitiji nain za proizvodnju visoko kvalitetnog softvera. Razlika izmeu programskog inenjerstva i raunarstva (kao znanosti) Raunarstvo se bavi teorijama i metodama, dok se programsko inenjerstvo bavi praktinim problemima koji se javljaju pri izradi softvera. Razlika izmeu programskog inenjerstva i sistemskog inenjerstva Sistemsko inenjerstvo se bavi razvojem i uspostavom raunalnih sustava. Sistemsko inenjerstvo ima vie grana, a jedna od njih je programsko inenjerstvo. Softver proces je niz aktivnosti koje se provode da bi se proizveo softver. Koriste se etiri osnovne aktivnosti: Specifikacija klijent i inenjer definiraju mogudnosti i ogranienja softvera. Razvoj softver se dizajnira i programira Validacija provjerava se da li softver ispunjava zahtjeve klijenta Evolucija softver se prilagoava novim zahtjevima klijenta i trita Model softver procesa pojednostavljeni prikaz procesa koji predstavlja jedan od pogleda na sam proces. Moe ukljuivati aktivnost, uloge zaposlenika. Neki od modela su: Workflow model predstavlja niz aktivnosti procesa ukljuujudi ulaz, izlaz i meuovisnosti. Dataflow model predstavlja proces kao set aktivnosti koje mijenjaju podatke (kako se neki ulazni podatak koristi za raunanje izlaza). Role/action model predstavlja uloge zaposlenika i aktivnosti za koje su odgovorni. esto se koriste paradigme: Waterfall aktivnosti se podijele u razliite faze. Kada se faza jedanput zavri vie se ne vrada na nju. Najvie novca na integraciju i testiranje. Iterativni razvoj Razvije se prototip koji se pokazuje klijentu. Program se dalje iterativno razvija uz stalno konzultiranje s klijentom. Istodobno se rade i specifikacija, programiranje, dizajniranje. Najvie novca na iterativni razvoj. Razvoj temeljen na komponentama softver se izrauje od ved gotovih komponenti. Najvie novca na integraciju i testiranje. Na evoluciju softver se troi i do etiri puta vie sredstava nego na sam razvoj. Metode programskog inenjerstva je strukturiran pristup razvoju softvera iji je cilj proizvodnja kvalitetnog i ekonominog softvera.

1

CASE (Computer- Aided Software Engineering) pokriva iroku paletu razliitih programa koji se koriste kao pomod pri razliitim aktivnostima (modeliranju, debugiranju..). Atributi dobrog softvera: Odrivost (Maintainability) softver mora biti napisan tako da moe lako evolvirati Pouzdanost (Dependability) ukljuuje sigurnost. Pouzdan softver ne bi smio uzrokovati fiziku ili ekonomsku tetu u sluaju greke. Uinkovitost (Efficiency) Lagan za koritenje (Acceptability, Usability) Izazovi programskog inenjerstva: Heterogenost koriste se razliiti tipovi mrea, razliiti operacijski sustavi, programi napisani u razliitim programskim jezicima Isporuka softvera mora biti to bra, uinkovitija Povjerenje da korisnici vjeruju sustavu

SOCIJALNO TEHNIKI SUSTAVI (Socio-Technical Systems)Socijalno tehniki sustavi su sustavi koji ukljuuju softver, hardver i ljude. Sustav je svrsishodni skup meusobno povezanih komponenti koje rade zajedno radi ostvarivanja cilja. Softver sustavi se dijele na dvije kategorije: Tehniki sustavi temeljeni na raunalima (Technical computer based systems) su sustavi koji ukljuuju softver i hardver, ali ne i procese i procedure (sustav ne zna za to se koristi). To su npr. televizija, mobiteli, vedina programa (word) Socijalno tehniki sustavi bitno da sustav ukljuuje znanje o tome kako se koristi. Takvi sustavi imaju tono definirane procese, ukljuuju operatere kao bitne dijelove sustava, ponaaju se prema odreenim pravilima.

Vane karakteristike socijalno-tehnikih sustava Emergent properties svojstva sustava kao cjeline koja ovise i o komponentama sustava, kao i o njihovom meuodnosu. Mogu se procjenjivati tek kada se sustav u potpunosti sastavi. Nedeterministiki za neki ulaz ne daju uvijek isti izlaz (ponaanje sustava ovisi o operateru). Sloeni odnosi s organizacijskim ciljevima - razina do koje sustav podrava ciljeve organizacije ne ovisi samo o sustavu, ved i o stabilnosti tih ciljeva, kako lanovi organizacije interpretiraju te ciljeve

Karakteristika svih sustava je da su svojstva i ponaanje komponenti isprepleteni. Sustavi su obino hijerarhijski organizirani i esto sadre druge sustave (podsustave). Podsustavi su nezavisni i mogu samostalno funkcionirati.

2

Emergent system properties Funkcionalna svojstva javljaju se kada svi dijelovi sustava rade zajedno da bi ostvarili neki cilj. Nefunkcionalna svojstva odnose se na ponaanje sustava prilikom rada. To su npr. performanse, sigurnost, pouzdanost i esto su jako bitna jer ukoliko nisu zadovoljena sustav moe biti neprikladan za koritenje.

Pouzdanost je svojstvo koje se mora uvijek promatrati na razini sustava, a ne na razini pojedinih komponenti. Komponente su esto meuovisne, pa se greke jedne komponente esto propagiraju na cijeli sustav. Tri stvari utjeu na pouzdanost sustava: pouzdanost hardvera, softvera i operatora. Neki emergent properties: pouzdanost, sigurnost, jednostavnost odravanja, lakoda koritenja Sistemsko inenjerstvo ukljuuje aktivnosti kao to su specifikacija zahtjeva, dizajna, implementacija, validacija, instalacija i odravanje socijalno tehnikih sustava. Sistem inenjeri se brinu o softveru, hardveru, ali i o interakciji korisnika i sustava.proces sistemskog inenjeringa

Definicija sistemskih zahtjeva ukljuuje specifikaciju funkcionalnosti sustava, esencijalna i poeljna svojstva. Nuna je suradnja s klijentima. Razlikujemo tri tipa zahtjeva: Apstraktni funkcionalni zahtjevi osnovne funkcije koje sustav treba pruiti se definiraju na apstraktnoj razini Svojstva sustava ukljuuju emergent propertieskao to su dostupnost, sigurnost, performanse. Ponaanja/svojstva koja sustav ne smije imati. Vano je da se odredi set zahtjeva koje sustav mora ispuniti. Dizajn sustava kako de sustav sastavljen od odreenih komponenti pruiti traenu funkcionalnost. Aktivnosti dizajna sustava su: Podjela zahtjeva zahtjevi se analiziraju i dijele u povezane grupe Identifikacija pod sustava identificiraju se pod sustavi najede se grupe zahtjeva poveu s odreenim podsustavima Dodjeljivanje zahtjeva podsustavima Odreivanje funkcionalnosti podsustava pri emu se odreuje i meuodnos izmeu pojedinih podsustava Definiranje potrebnih suelja podsustava. Jednom kada se usuglasi oko tih suelja razvoj podsustava se moe odvijati paralelno.

3

Modeliranje sustavaSustav se moe modelirati kao niz komponenti pri emu se istiu odnosi izmeu tih komponenti. Arhitektura sustava se moe prikazati kao blok dijagram koji prikazuje glavne podsustave i veze meu njima. Podsustavi se prikazuju kao kvadrati, dok se veze prikazuju kao strelice. Sustav se prikazuje kao niz meuovisnih podsustava. Svaki podsustav se prikazuje na slian nain sve dok se sustav ne rastavi na funkcionalne komponente.

Razvoj podsustavaPrilikom razvoja podsustav esto se poinje potpuno novi proces programskog inenjerstva. Ponekad se podsustavi razvijaju iz poetka, dok se neke komponente kupuju. Podsustavi se esto razvijaju paralelno i ponekad se javljaju problemi koji se proteu na vie podsustava, tada se moraju raditi modifikacije specifikacije, dizajna

Integracija sustavaTijekom integracije sustava nezavisno razvijeni podsustavi se spajaju u sustav. Mogu se spojiti sve podsustavi odjednom ili se sustavi integriraju jedan po jedan (zbog toga to je mala vjerojatnost da de svi podsustavi biti gotovi u isto vrijeme, smanjiva se vrijeme pronalaenja pogreki). Nakon integracije svih komponenti obavlja se iscrpno testiranje.

Evolucija sustavaSustav se esto mijenja da bi se otklonile pogreke ili da se zadovolje novi zahtjevi. Moe dodi i do mijenjanja strukture organizacije, hardvera. Evolucija sustava je skupa zbog toga to: Predloene izmjene moraju biti pomno analizirane s poslovne i tehnike strane Podsustavi gotovo nikad nisu potpuno nezavisni pa promjene jednog podsustava esto utjeu na druge podsustave. esto razlozi zato su neke stvari tako napravljene na poetku nisu dokumentirani S starodu struktura sustava se iskvari to povedava cijenu promjena Sustavi koji su evolvirali esto ovise o prastarom hardveru i softveru. Ako takvi sustavi imaju kljunu ulogu u organizaciji nazivaju se legacy systems.

Povlaenje sustava iz radaZa hardver sustava to znai rastavljanje i eventualnu reciklau, dok kod softver to moe znaiti pretvaranje korisnih podataka u format koriten na nekom drugom sustavu.

Organizacije, ljudi i kompjuterski sustaviSocijalno-tehniki sustavi su sustavi iji je cilj ispunjenje nekog organizacijskog cilja. Ugraeni su u samu organizaciju i moraju se ponaati prema pravilima te organizacije. Ljudski i organizacijski faktori su: Promjena procesa da li sustav uvodi promjene u radni proces, ako su promjene velike moda de trebati dodatno obrazovanje radnika, otputanje radnika. To sve moe stvoriti otpor prema sustavu. Promjena posla da li sustav previe mijenja nain na koji ljudi rade Promjena organizacije Mijenja li sustav strukturu organizacije Svi organizacijski faktori bi trebali biti ukljueni u specifikaciju sustava. 4

Organizacijski procesiRazvoj nije jedini dio sistem inenjeringa. Tu spadaju jo i nabava i sam rad sustava. Nabava je obino ukljuena kod organizacije koja de kupiti i koristiti sustav. Tada organizacija mora odrediti najbolji nain za nabavu sustava. Veliki sustavi se esto sastoje od generikih i posebno razvijenih komponenti. Uvijek se radi detaljna analiza trita, te se odluuje da li je ekonominije idi u naruivanje ved gotovog softvera (nakon toga sustav se prilagoava i odabire se dobavlja) ili de se softver razvijati iz poetka. Operacijski procesi trebaju biti fleksibilni i prilagodljivi (esto se dogaaju nepredvidljive situacije).

Legacy sustaviLegacy sustavi su socijalno tehniki sustavi razvijeni prije nekog vremena (10, 20 god) koji esto koriste zastarjele tehnologije. Ti sustavi se ne sastoje samo od hardvera i softvera ved i od zastarjelih procesa i procedura. Promjene jednog dijela tog sustava esto uzrokuju kaskadne promjene kroz cijeli sustav. Takvi sustavi su esto kritini za rad organizacije i odravaju se jer ih je prerizino zamijeniti. Komponente: hardver, pomodni softver, aplikacijski softver, podaci, poslovni procesi, poslovna pravila.

KRITINI SUSTAVIKritini sustavi su sustavi kod ije greke dolazi do znatnih ekonomskih gubitaka, fizike tete ili gubitka ivota. Razlikujemo tri glavna tipa takvih sustava: Sigurnosno kritini sustavi su sustavi ija greka moe izazvati ozljedu, gubitak ivota ili oneidenje okolia Ciljno kritini (Mission) sustavi ija greka moe rezultirati neuspjehom nekog cilja Poslovno kritini sustavi su sustavi ija je greka jako skupa (banke) Najvanije emergent svojstvo kritinih sustava je dependability (ukljuuje sigurnost, pouzdanost, dostupnost). To je zbog toga to korisnici esto odbijaju koristiti sustave koji su nepouzdani, nesigurni; cijena greke sustava moe biti ogromna; nepouzdani sustavi mogu uzrokovati gubitak informacija. Zbog toga se prilikom razvoja moraju koristiti iskuane i pouzdane metode, a ne nove metode koje se moda ine bolje ali ije se slabosti ne poznaju. Cijena verifikacije i validacije je esto vie od 50% ukupne cijene. Vedina kritinih sustava su socijalno tehniki sustavi kod kojih ljudi nadziru rad kompjuterskih sustava (jer ljudi mogu reagirati na nepredvidive situacije). Greke kod kritinih sustava se mogu dogoditi zbog greke hardvera, softvera ili zbog operatera. Moraju se uzeti u obzir slabosti svih dijelova kao i slabosti sustava kao cjeline.

5

Dependability se sastoji od: Dostupnost da sustav ispuni zahtjev kad se to od njega zatrai Pouzdanost da ispuni zahtjev kako je specificirano; da informacije imaju dovoljno detalja, da se informacija isporui kada je potrebna Sigurnost da sustav funkcionira bez katastrofalnih greaka, da je zatiden od upada. Ukljuuje i osiguranje da se podaci ne otete. Jednostavnost popravka, odravanja, tolerancija na greke To svojstvo pokazuje koliko korisnici vjeruju sustavu. Dizajneri moraju esto raditi kompromise izmeu performansi i dependability-a.

Dostupnost i pouzdanostPouzdanost sustava je vjerojatnost da de sustav pruiti usluge onako kako su specificirane (problem jer korisnik moe oekivati ponaanje koje nije specificirano). Dostupnost sustava je vjerojatnost da de sustav pruiti uslugu kada je korisnik zatrai. Problem s ovim definicijama je to ne uzimaju u obzir teinu greke ili posljedice nedostupnosti. Npr. kod telefonskog sustava vanija je dostupnost nego pouzdanost. Mogu se jo definirati i: Pouzdanost vjerojatnost da de sustav raditi bez greke u nekom okoliu, tijekom nekog vremena. Dostupnost vjerojatnost da de sustav u nekom trenutku raditi i modi pruiti traenu uslugu. Uz pouzdanost se veu termini: pad sustava (system failure ), greka (fault i error). Za povedanje pouzdanosti sustava koriste se pristupi: Izbjegavanje greaka koriste se razvojne tehnike koje smanjuju vjerojatnost pojave greaka Detekcija i popravljanje pogreki koristi se validacija i verifikacija da se poveda vjerojatnost detekcije pogreki tako da se mogu ispraviti prije nego to sustav krene u uporabu. Tolerancija na pogreke tehnike koje osiguravaju da pogreke ne dovode do vedih greaka u radu ili ruenja sustava. Korisnici socijalno tehnolokih sustava se esto prilagode sustavu na nain da pronau nain kojim izbjegavaju greke.

SafetySustavi kod kojih je sigurnost kritina u niti kojem sluaju ne smiju ozlijediti ljude ili otetiti imovinu. Ugrauje se dodatna kontrola koja moe biti hardverska ili softverska. Ovakav tip softvera se dijeli na dvije kategorije: Primarni sigurnosno kritini sustavi softver koji ugraen kao kontrolor sustava. Nefunkcioniranje takvog softver moe dovesti do kvara hardvera. Sekundarno sigurnosno kritini sustavi (safety critical systems) softver koji indirektno moe izazvati povredu ili otedenje. Ako je softver pouzdan ne mora znaiti i da je siguran. Zbog toga to npr. specifikacija moe biti nedoreena i ne opisuje kako de sustav reagirati u kritinim situacijama; greke u hardveru mogu uzrokovati da se sustav ponaa na nepredvidiv nain; operatori mogu unijeti unose koji nisu netoni sami za sebe, ali u odreenim situacijama mogu dovesti do greke u sustavu. Opasnosti se mogu izbjegavati, detektirati i otkloniti ili ukoliko se ved dogode nastoji se da teta bude to manja. 6

SecuritySigurnost je svojstvo sustava koje odraava sposobnost sustava da se zatiti od vanjskih napada. Jako je vana u vojnim, bankarskim sustavima. Napad moe uzrokovati probleme kao to su: uskradivanje usluge, promjene podataka, otkrivanje povjerljivih informacija. Sigurnost sustava se moe osigurati: Izbjegavanjem slabosti sustav se npr. ne prikljuuje na Internet Otkrivanje i neutraliziranje napada npr. koritenjem antivirusnih sustava

SOFTVERSKI PROCESISoftver proces je niz aktivnosti koje omogudavaju razvoj softvera. Te aktivnosti mogu ukljuivati razvoj novog softvera, ali i modifikaciju ved postojedeg. Aktivnosti zajednike za sve softverske procese su: Specifikacija definira se funkcionalnost i ogranienje softvera Dizajn i implementacija proizvodnja softvera Validacija provjerava se da li softver radi ono to klijent eli Evolucija softver se mijenja zbog toga to se mijenjaju potrebe klijenta

Modeli softverskih procesaSoftver proces model je apstraktna reprezentacija softver procesa i predstavlja proces iz neke perspektive. Najedi modeli su: Waterfall, model vodopada aktivnosti se podijele u razliite faze. Kada se faza jedanput zavri vie se ne vrada na nju. Najvie novca na integraciju i testiranje. Iterativni razvoj Razvije se prototip koji se pokazuje klijentu. Program se dalje iterativno razvija uz stalno konzultiranje s klijentom. Istodobno se rade i specifikacija, programiranje, dizajniranje. Najvie novca na iterativni razvoj. Razvoj temeljen na komponentama softver se izrauje od ved gotovih komponenti. Najvie novca na integraciju i testiranje. Ovi modeli se meusobno ne iskljuuju i esto se koriste istodobno, naroito kod razvoja velikih sustava. Postoje razliite varijante ovih generikih procesa od kojih je najvaniji formalni razvoj sustava kod kojeg se kreira matematiki model sustava kojeg se zatim, koristedi matematike transformacije, pretvara u izvrni kod. Najpoznatiji takav proces je CleanRoom (IBM).

7

Model vodopadaSastoji se od slijededih aktivnosti: Definicija i analiza zahtjeva u suradnji s korisnicima detaljno se odreuju funkcionalnosti i ogranienja softvera (specifikacija) Dizajn softver i sustava obavlja se podjela zahtjeva, odredi se opdenita arhitektura sustava Implementacija i testiranje komponente sustava se povezuju i testiraju kao cjelina. Nakon testiranja obavlja se isporuka klijentu Rad i odravanje obino je ovo najdui dio procesa. Sustav se instalira kod klijenta. Ispravljaju se greke koje nisu otkrivene u fazi testiranja. Evolucija softvera Rezultat svake faze su odobreni dokumenti. Slijededa faza ne bi smjela poeti sve dok se prethodna ne zavri. U stvarnosti faze se ispreplidu, pa se ovaj proces odvija u vie iteracija. Nikad se ne radi prevelik broj iteracija (skupe su) ved se u jednom trenutku odlui da se ide dalje, a nerijeeni problemi se ignoriraju ili zaobilaze trikovima. Svi problemi de se poslije morati ispraviti u fazi evolucije. Prednosti su to se dokumentacija izrauje u svakoj fazi i da se podudara s drugim procesnim modelima. Glavni problem je nefleksibilna podjela procesa u razliite faze. Teko je ukomponirati nove korisnikove zahtjeve. Ovaj model bi se samo trebao koristiti kada su zahtjevi dobro specificirani i kada postoji mala vjerojatnost da de se mijenjati tijekom razvoja sustava.

Evolucijski (iterativni) razvojKod ovog modela razvije se prototip koji se pokae korisniku i taj prototip se kroz vie iteracija (sve u suradnji s korisnikom)pretvara u gotov proizvod. Specifikacija, razvoj i iteracija se ispreplidu. Razlikujemo dva tipa: Exploratory development cilj je raditi s klijentom (pri emu se detaljno pregledavaju zahtjevi). Razvoj poinje s dijelovima sustava koji su razumljivi. Sustav se razvija dodavanjem novih mogudnosti koje predlae klijent. Throwaway prototyping cilj iterativnog razvoja je razumijevanje korisnikovih potreba. Izrauje se prototip pomodu kojeg se eksperimentira sa zahtjevima koji nisu dovoljno razumljivi.

8

Ovakav model se koristi kod razvoja malih i srednjih sustava i esto je uinkovitiji od modela vodopada (to se tie realiziranja korisnikovih elja). Prednost je i to to se specifikacija razvija inkrementalno. Nedostatci su: Ako se sustav brzo razvija neekonomino je proizvoditi dokumentaciju koja odraava stanje svake verzije Sustav je esto loe strukturiran stalna promjena iskvari strukturu samog sustava Za vede sustave preporua se koristiti kombinacija ovog modela i modela vodopada. Npr. dijelovi zahtjeva koji su dobro razumljivi (specificirani) se razvijaju koristedi model vodopada, dok se dijelovi kao npr. suelje razvijaju koristedi npr. Exploratory development.

Razvoj temeljen na komponentamaesto se neke komponente jednostavnim modifikacijama mogu koristiti u vie projekata. To je naroito znaajno kod brzog evolucijskog razvoja. Kod ovog modela razlikujemo slijedede faze: Specifikacija zahtjeva Analiza komponenti trae se komponente pomodu kojih se mogu implementirati zahtjevi Modifikacija zahtjeva zahtjevi se mijenjaju u skladu s pronaenim komponentama. Ukoliko se zahtjevi ne mogu mijenjati tada se trae druge komponente (ili se modificiraju). Dizajn sustava koritenjem komponenti dizajnira se framework sustava (ili se koristi ved gotov) pri emu se u obzir uzimaju odabrane komponente. Razvija se nove komponente ukoliko nema ved gotovih. Razvoj i integracija Koritenjem ved gotovih komponenti smanjuju se cijena, rizici i vrijeme razvoja. Mana je to je mijenjanje originalnih zahtjeva gotovo neizbjeno.

Iteracija procesaSoftver se mora mijenjati u skladu s mijenjanjem potreba klijenata. Razlikujemo dva procesa iteracije: Inkrementalna isporuka specifikacija, dizajn i implementacija se razbijaju u niz inkremenata koji se zatim razvijaju. Specifikacija se razvija paralelno sa softverom. To je esto u konfliktu s mnogim organizacijama gdje je puna specifikacija dio ugovora. Korisnici okvirno definiraju zahtjeve i njihovu vanost. Zatim se odredi broj inkremenata s time da svaki inkrement ispuni neki od zahtjeva (najvaniji zahtjevi se ispunjavaju najprije). Prije razvoja svakog inkrementa u detalje se razrade njegovi zahtjevi (ukoliko za vrijeme razvoja stignu izmjene za taj inkrement one se ne prihvadaju ). Nakon razvoja inkrement se integrira u sustav. Zatim se obavlja isporuka i klijent testira softver. Ovakav nain ima brojne prednosti: klijent ne treba ekati do kraja razvoja da dobije neku funkcionalnost softvera, klijent pomodu inkrementa treba stedi dojam o sustavu i na taj nain prilagoditi zahtjeve, malen rizik neuspjeha projekta, bududi da se najprije ispune najvaniji zahtjevi, 9

oni se najvie i testiraju. Postoje i problemi kod ovakvog razvoja: inkrementi moraju biti relativno maleni (do 20000 linija koda) pa ponekad zna biti teko odrediti koji zahtjevi idu u koji inkrement; teko je odrediti koje osnovne funkcionalnosti su potrebne za sve inkremente (specifikacija nije do kraja razraena). Spiralni razvoj Razvoj sustava ide spiralno prema vani od prototipa pa sve do gotovog sustava. Svaka petlja spirale predstavlja jednu fazu procesa (prva petlja izvedivost, druga definicija zahtjeva) i podijeljena je u etiri sektora: Postavljanje ciljeva definiraju se ciljevi, ogranienja, rizici za ovu fazu projekta Procjena rizika i naini njihovog smanjivanja za svaki rizik izvodi se detaljna analiza, poduzimaju se odreeni koraci koji smanjuju rizik. Razvoj i validacija u skladu s rizicima se izabire razvojni model (ako je problem suelje evolucijski, ako je problem sigurnost onda razvoj na temelju formalnih transformacija) Planiranje projekt se pregledava i donose se odluke da li se ide na slijededu petlju spirale Glavna razlika spiralnog modela i ostalih modela je u velikom posvedivanju panje rizicima.

Procesne aktivnostietiri osnovne procesne aktivnosti: specifikacija, razvoj, validacija i evolucija. Te aktivnosti su poredane ovisno o tome koji se procesni model koristi. Specifikacija softvera Specifikacija sadri zahtjeve pomodu kojih se definira tono to sve korisniku treba, koja su ogranienja sustava Ovo je kritian dio jer bilo koje greke u ovom dijelu se propagiraju na cijeli sustav. Zahtjevi se predstavljaju u dvije razine: krajnji korisnici dobivaju manje detaljne zahtjeve, dok programeri moraju dobiti potpuno specificiran zahtjev. Sam proces specifikacije se dijeli na etiri dijela: Studija izvedivosti procjenjuje se da li se korisnikove potrebe mogu zadovoljiti koristedi dostupne tehnologije, hode li traeni sustav biti ekonomian i moe li se razviti koristedi dostupan budet. Na osnovu ove studije se odluuje da li de se nastaviti s daljnjom analizom. Analiza i opisivanje zahtjeva odreuju se zahtjevi sustava kroz prouavanje ved postojedih sustava, razgovora s klijentima U ovu fazu moe biti ukljuen i razvoj prototipova koji de pomodi korisniku da razumije sustav. Specifikacija zahtjeva na osnovu skupljenih informacije pie se lista zahtjeva. Razlikujemo dva tipa zahtjeva: korisnikove zahtjeve apstraktne informacije o zahtjevima, sistemski zahtjevi detaljniji opis funkcionalnosti koje trebaju biti omogudene. Validacija zahtjeva provjerava se da li su zahtjevi konzistentni, proturjeni, realni, potpuni Dizajn i implementacija Ovo je faza u kojoj se na osnovu specifikacije izrauje sam sustav. Uvijek ukljuuje programiranje i dizajn, a kod evolucijskog modela i doraivanje specifikacije. Softver dizajn je opis strukture, podataka, suelja izmeu razliitih komponenti, algoritama Dizajn se najede pie u nizu iteracija. Sam proces dizajna moe ukljuivati i razvoj nekoliko modela sustava na razliitim nivoima apstrakcije.

10

Procesne aktivnosti dizajna su esto isprepletene, a razlikujemo slijedede procese: Dizajn arhitekture Odreuju se podsustavi i njihov odnos Apstraktna specifikacija za svaki podsustav radi se apstraktna specifikacija usluga i odreuju se njegova ogranienja Dizajn suelja za svaki podsustav se odreuje suelje s drugim podsustavima. Dizajn komponenti odreuju se komponente, njihove uloge i suelja Dizajn struktura podataka odreuju se strukture podataka koje de se koristiti Dizajn algoritama U praksi se esto neke aktivnosti odgaaju. Ukoliko se koriste agilne metode rezultat dizajna nede biti dokument, ved kod (dokument se pie jedino kod dizajna arhitekture). Ako se koriste strukturirane metode tada se kao rezultat dizajna dobivaju grafiki modeli iz kojih se generira kod. Nakon razvoja programi se testiraju. Testiranje je proces otkrivanja pogreki, dok se proces ispravljanja pogreki u programu naziva debuggiranje. Validacija Validacija je provjeravanje da li sustav radi prema specifikaciji. Razlikujemo vie faza: Testiranje komponenti provjerava se da li pojedine komponente ispravno rade. Svaka komponenta se testira nezavisno. Testiranje sustava Komponente se integriraju u sustav. Ovaj dio je namijenjen otkrivanju greki koje nastaju uslijed nepredvidivog meudjelovanja komponenti, potvrivanju funkcionalnih i nefunkcionalnih zahtjeva, testiranju emergent svojstava Testiranje prihvatljivosti ovo je posljednja faza testiranja prije nego to se sustav prihvati za stvarni rad. Ako se koristi inkrementalni razvoj svaki inkrement bi se trebao testirati kako se razvija. Kod ekstremnog programiranja testovi se razrauju zajedno sa zahtjevima, prije samog razvoja. Testiranje prihvatljivosti se esto naziva alfa testiranje koje traje sve dok se klijent ne sloi da je sustav prihvatljiva implementacija zahtjeva. Kod generikog softvera postoji i faza beta testiranja kod kojeg se sustav isporui vedem broju potencijalnih klijenata koji zatim prijavljuju greke razvojnom timu. Rational unified process (RUP) RUP se razvio iz rada s UML-om i opisuje se iz 3 perspektive: Dinamika perspektiva koja pokazuje faze modela kroz vrijeme Statika perspektiva koja pokazuje procesne aktivnosti Praktina perspektiva koja predlae dobre naine rada RUP je model u fazama koji razlikuje etiri faze u softver procesu. Te faze su vie povezne s poslovnim sustavom. To su: Poinjanje radi se poslovna analiza sustava. Identificiraju se svi vanjski entiteti (ljudi, sustavi) koji de komunicirati sa sustavom. Radi se procjena koliki de utjecaj sustav imati na posao. Objanjavanje cilj je: razviti razumijevanje problema, odreivanje arhitekture, razvoj projektnog plana i identifikacija rizika. Konstrukcija ova faza se bavi dizajnom, programiranjem i testiranjem. Dijelovi sustava se razvijaju paralelno. Tranzicija stavljanje sustava u stvarni rad. 11

Statika perspektiva RUP-a se fokusira na aktivnosti koje se dogaaju tijekom razvoja (nazivaju se workflows). Prednost koritenja statikih i dinamikih pogleda je u tome to faze razvojnog procesa nisu povezane sa specifinim radnim tokovima. Zbog toga, u teoriji svi radni tokovi mogu biti aktivni u svim fazama projekta, ali u praksi se na poetku projekta vie vremena ulae u poslovno modeliranje, a u kasnijim fazama na testiranje. RUP preporueni naini rada: Iterativan razvoj softvera razvoj inkremenata se temelji na potrebama klijenta. Najvaniji prioriteti se moraju ispuniti to prije. Upravljanje zahtjevima tono navoenje korisnikovih zahtjeva. Sve izmjene se detaljno dokumentiraju. Analizira se utjecaj izmjena na sustav prije njihovog prihvadanja. Koristi se arhitektura temeljena na komponentama Vizualno modeliranje softvera Verificiranje kvalitete softvera Kontrola promjena softvera RUP nije praktian za sve razvojne procese, ali predstavlja novu generaciju generikih procesa. Najvanije novosti su razdvajanje faza i radnih tokova, te prihvadanje da je stavljanje sustava u stvarni rad sastavni dio razvoja. Faze su dinamine i imaju ciljeve. Radni tokovi su statini i to su tehnike aktivnosti koje nisu povezane s pojedinom fazom, ali se mogu koristiti tijekom razvoja da bi se ostvarili ciljevi svake faze.

CASE (Case Aided Software Engineering)CASE je naziv za softver koji se koristi kao pomod (automatiziraju odreene procesne aktivnosti) kod softverskih procesa (specifikacija, dizajn, razvoj). U tu skupinu spadaju dizajn editori, kompajleri Aktivnosti koje mogu biti automatizirane koristedi CASE alate su: Razvoj grafikih modela sustava kao dio specifikacije ili softver dizajna Razumijevanje dizajna koristedi podatkovni rjenik koji sadri informacije o entitetima i odnosima Generiranje korisnikog suelja iz opisa kojeg korisnik kreira interaktivno Debugiranje Automatsko prevoenje programa napisanih u starijim jezicima u neke novije jezike CASE tehnologije danas postoje za gotovo sve rutinske aktivnosti koje se javljaju u procesu razvoja softvera to je dovelo do znaajnih poboljanja u kvaliteti i produktivnosti (do 40%). Glavno ogranienje CASE-a je u tome to je programsko inenjerstvo kreativan proces, a umjetna inteligencija jo uvijek nije na tom nivou. Programsko inenjerstvo je timska aktivnost gdje inenjeri dosta vremena provode komunicirajudi s drugim lanovima tima.

12

Klasifikacija CASE alata Klasifikacija CASE alata pomae razumjeti tipovi CASE alata i njihovu ulogu u razliitim aktivnostima. Razlikujemo tri perspektive: Funkcionalna perspektiva (za planiranje, editiranje, upravljanje promjenama, prototipove, obradu jezika, testiranje, analizu, dokumentaciju) Procesna perspektiva prema procesnoj aktivnosti koju podravaju Integracijska perspektiva dijele se prema tome kako su organizirani u integrirane jedinice koje pruaju podrku za jednu ili vie procesnih aktivnosti Postoji i podjela na: Alate daju podrku za individualne procesne zadatke Radni stolovi (workbenches) daju podrku za procesne faze ili aktivnosti (specifikacija, dizajn). Sastoje se od niza alata Okoli podravaju znaajan dio softver procesa. Sastoje se od nekoliko radnih stolova

UPRAVLJANJE PROJEKTOMDobro upravljanje projektom je bitno jer smanjuje vjerojatnost kanjenja, prekoraenja dostupnih sredstava, nezadovoljavanja zahtjeva Upravitelj projekta je zaduen za planiranje razvoja, potivanje rokova, zahtjeva. Upravljanje softverskim projektima je drugaije od upravljanja drugim inenjerskim projektima jer je softver apstraktan (napredak se ne moe vidjeti, ved se pouzda u dokumentaciju), ne postoje standardni procesi jer je programsko inenjerstvo relativno mlada disciplina, veliki programi se esto razlikuju od prethodnih, tehnologija se brzo mijenja pa znanje zastarijeva Aktivnosti vezane za upravljanje projektom Ne postoji standardan set aktivnosti koje vrijede u svim organizacijama ili na svim projektima, ali u velikoj vedini sluajeva postoje slijedede aktivnosti: pisanje prijedloga (prikazuju se ciljevi projekta i naini njihovog izvravanja, odredi okvirna cijena), planiranje i izrada rasporeda (identificiraju se aktivnosti, kontrolne toke, razrada plana kojeg bi se razvojni tim trebao pridravati), predvianje cijene projekta (procjenjuju se resursi potrebni za zavretak projekta), nadgledanje napretka projekta i usporedba stvarnog i predvienog napretka i trokova, izabiranje osoblja, pisanje izvjetaja i prezentiranje. Planiranje projekta Uinkovito planiranje projekta ovisi o temeljitom planiranju napretka projekta. Upravitelji moraju predviati mogude probleme i predvidjeti nain njihovog rjeavanja. Na poetku se radi projektni plan kojeg bi se trebalo pridravati (mijenja se ukoliko se pojave bolje informacije). Prilikom izrade plana upravitelj procjenjuje ogranienja (datum isporuke, dostupna sredstva) i na osnovu tih procjena izrauje projektne parametre (struktura projekta, veliina). Zatim se definiraju kontrolne toke i nakon toga se izrauje raspored aktivnosti (esto se uzima pesimistian pristup). Nakon nekog vremena radi se pregled napretka i odstupanje od plana (plan se esto mijenja jer je teko sve predvidjeti).

13

Projektni plan Plan sadri informacije o dostupnim resursima, projektne aktivnosti, raspored rada Svaki plan bi trebao imati slijedede dijelove: Uvod (ukratko se objanjavaju ciljevi projekta i odreuju ogranienja budet, vrijeme...), organizacija (nain na koji je razvojni tim organiziran, koje su njihove uloge), analiza rizika (koji su rizici, kako de utjecati na projekt, kolika je vjerojatnost njihovog pojavljivanja), hardverski i softverski zahtjevi, podjela projekta na aktivnosti (odreivanje kontrolnih toaka), raspored (ovisnosti izmeu aktivnosti, koliko je vremena potrebno za odreenu aktivnost), odreivanje mehanizama za nadzor i obavjedivanje. Projektni plan se esto pregledava i revidira za vrijeme trajanja projekta (naroito raspored esto se mijenja). Kontrolne toke i isporuke Kod planiranja projekta utvruje se niz kontrolnih toki (prepoznatljiv zavretak neke aktivnosti) nakon kojih se daje izvjetaj koji se zatim predstavlja upravi. Isporuke klijentu (deliverable) se najede rade nakon zavretka neke velike projektne faze (npr. specifikacije ili dizajna). Da bi se utvrdile kontrolne toke projekt se treba razbiti na osnovne aktivnosti. Npr. kod izrade zahtjeva to mogu biti studija izvedivosti, analiza zahtjeva, razvoj prototipa, studija dizajna, specifikacija zahtjeva. Izrada projektnog rasporeda Upravitelj mora predvidjeti vrijeme i resurse potrebne za zavretak pojedinih aktivnosti. esto se neke aktivnosti mogu paralelno izvoditi, no tada je nuno dobro koordiniranje i organizacija posla. Jako je bitno sprijeiti kanjenje projekta jer neka kritina aktivnost nije zavrena. Prilikom izrade rasporeda uvijek se uzima pesimistina procjena (naroito ako se takav tip sustava po prvi put radi). Grafovi i mree aktivnosti se koriste kao grafiki prikazi koji ilustriraju projektni raspored. Grafovi sa stupcima (bar chart) prikazuju tko je odgovoran za pojedinu aktivnost i kada de ta aktivnost poeti i zavriti. Mree aktivnosti pokazuju meuovisnosti pojedinih aktivnosti, pa se na temelju njih moe odrediti koje se aktivnosti mogu paralelno, a koje se moraju sekvencijalno izvravati. Aktivnosti se prikazuju kao kvadrati, a kontrolne toke kao kvadrati s oblim kutovima. Minimalno vrijeme zavretka projekta se moe procijeniti uzimajudi u obzir najdue putove u grafu. Kritian put je niz ovisnih aktivnosti koje odreuju vrijeme potrebno da se projekt zavri (ako jedna od tih aktivnosti zapne cijeli projekt zapinje).

Upravljanje rizicimaUpravljanje rizicima ukljuuje predvianje rizika koji bi mogli utjecati na raspored projekta ili na kvalitetu softvera i ta predvianja se dokumentiraju u projektnom planu zajedno s analizom posljedica ukoliko se rizik dogodi. Razlikujemo tri kategorije rizika: projektni rizici (utjeu na raspored ili resurse npr. gubitak iskusnog lana tima), rizici vezani za proizvod (utjeu na kvalitetu ili performanse softvera, npr. kupljena komponenta se ne ponaa kako treba), poslovni rizici (rizici koji utjeu na organizaciju koja razvija softver).

14

Upravljanje rizicima se dijeli na vie faza: Identifikacija rizika- postoji vie tipova rizika. Mogu biti vezani za tehnologiju, ljude, organizaciju, alate, zahtjeve, procjene. Analiza rizika vjerojatnost pojavljivanja (u postotcima) i posljedice rizika (katastrofalno, ozbiljno, podnoljivo) se analiziraju. Pri tome se uglavnom oslanja na iskustvo. Planiranje to de se poduzeti ako se rizik ipak pojavi. Razlikujemo tri strategije a to su: o izbjegavanje (smanjuje se vjerojatnost pojavljivanja rizika) o minimizacija (smanjuje se posljedica rizika, npr. kod rizika vezano za ljude se napravi ede preklapanje posla tako da vie ljudi zna o stvarima koje se rade) o pripremanje za najgore i pravljenje strategija za noenje s rizikom Nadzor rizika redovito se procjenjuju identificirani rizici i odluuje se da li se promijenila njegova vjerojatnost ili utjecaj na sustav.

ZAHTJEVIZahtjevi sustava su opis usluga/funkcionalnosti koje sustav prua kao i njegova operacijska ogranienja. Zahtjevi odraavaju potrebe klijenta. Sam proces pronalaenja, analiziranja, dokumentiranja i provjeravanja funkcionalnosti i ogranienja se naziva inenjering zahtjeva (requirements engineering). Razlikujemo dvije vrste zahtjeva: Korisniki zahtjevi izjave napisane normalnim, govornim jezikom koje opisuju koje usluge sustav nudi i ogranienja pod kojima mora funkcionirati. Sistemski zahtjevi detaljno odreuju funkcionalnosti, usluge i ogranienja sustava. Dokument u kojem su opisani ti zahtjevi mora biti precizan i mora tono odreivati to de biti implementirano.

Funkcionalni i nefunkcionalni zahtjeviFunkcionalni zahtjevi su tvrdnje o uslugama koje sustav treba omoguditi, kako treba reagirati na odreene ulaze i kako se treba ponaati u odreenim situacijama. U nekim sluajevima se odreuje i to sustav ne smije raditi. Ovise o tipu sustava, korisnicima sustava, pristupu organizacije. Moraju biti napisani jasno, potpuno (definiraju se sve usluge koje trebaju korisniku) i konzistentno. Nefunkcionalni zahtjevi ogranienja na funkcionalnosti sustava (ukljuuju vremenska ogranienja, ogranienja na razvojni proces). esto se odnose na sustav kao cjelinu, na emergent properties kao to su pouzdanost, sigurnost, performanse; mogu definirati ogranienja na sustav kao npr. sposobnosti I/O ureaja i esto su vanije od pojedinih funkcionalnih zahtjeva. Neki nefunkcionalni zahtjevi ograniavaju i proces koji se koristi kod razvoja (specificiraju se standardi kvalitete). Tipovi nefunkcionalnih zahtjeva su: Zahtjevi proizvoda odreuju kako de se proizvod ponaati (koliko je sustav brz, koliko je memorije potrebno, pouzdanost) Organizacijski zahtjevi izvode se iz naina rada klijentove i programerove organizacije. Npr. koji de se procesni standardi koristiti, koji programski jezik, metoda dizajna Vanjski zahtjevi svi zahtjevi koji proizlaze iz faktora van sustava. Npr. kako sustav komunicira s drugim sustavima, da sustav funkcionira u skladu sa zakonom, etiki zahtjevi est problem je da su nefunkcionalni zahtjevi teki za verificiranje. Pa se, kad god je to mogude, nastoje kvantitativno izraziti. 15

Zahtjevi domene (Domain requirements) zahtjevi koji proizlaze iz domene iz koje sustav dolazi mogu biti funkcionalni i nefunkcionalni. To su specijalizirani zahtjevi koji izlaze iz poslovnog okruenja u kojem sustav funkcionira, koristi se struna terminologija koju programski inenjeri moda ne razumiju.

Korisniki zahtjeviKorisniki zahtjevi bi trebali opisivati funkcionalne i nefunkcionalne zahtjeve na nain da su lako razumljivi korisnicima sustava bez potrebe za tehnikim znanjem. Trebaju samo specificirati vanjsko ponaanje sustava. Koriste se jednostavni izrazi, tablice, dijagrami. Postoje problemi jer takvo izraavanje moe dovesti do nedovoljne jasnode, mijeanja zahtjeva (funkcionalni, nefunkcionalni zahtjevi, ciljevi sustava moda nisu jasno podijeljeni). Preporuljivo je da je koritenje standardnih formata.

Zahtjevi sustavaZahtjevi sustava su proirena verzija korisnikih zahtjeva i slue kao polazna toka za dizajniranje sustava. Objanjavaju kako de sustav ispuniti korisnike zahtjeve. Idealno zahtjevi sustava bi trebali opisivati vanjsko ponaanje i ogranienja sustava i ne bi se trebali baviti dizajnom ili implementacijom sustava. Ali u praksi je jako teko potpuno iskljuiti sve informacije o dizajnu: esto se mora dizajnirati prototip arhitekture koji slui kao pomod kod strukturiranja zahtjeva; sustav mora komunicirati s drugim sustavima to namede neka ogranienja kod dizajna. Kod opisa se koristi normalni jezik to ponekad moe unijeti nejednoznanosti, pa se esto koriste grafiki modeli, matematike specifikacije, strukturirani normalni jezik Ukoliko se za opisivanje koristi strukturirani normalni jezik tada se svi zahtjevi piu na standardni nain zadrava se razumljivost normalnog jezika ali se i osigurava konzistentnost. Ako se koristi standardna forma za odreivanje funkcionalnih zahtjeva tada slijedede informacije moraju biti ukljuene: opis funkcije/entiteta koji se opisuje, opis ulaza i odakle dolaze, opis izlaza i gdje se prosljeuju, indikacija drugih entiteta koji se koriste, opis akcija koje se poduzimaju; ako se koristi funkcionalni opis tada se naznai koje svojstvo je istinito prije nego to se funkcija pozove i koje svojstvo je istinito nakon to se pozove; nuspojave (ako postoje).

Specifikacija sueljaGotovo svi sustavi moraju komunicirati s postojedim sustavima. Te specifikacije se moraju definirati to ranije. Razlikujemo tri tipa suelja koja se moraju definirati: Proceduralna suelja postojedi programi nude usluge kojima se moe pristupiti koristedi procedure suelja (API) Strukture podataka koje se prenose iz jednog sustava u drugi. Najbolje je koristiti grafike modele Reprezentacije podataka

Dokument sa specifikacijom zahtjevima (Software requirements document)SRS (specifikacija) je slubeni dokument koji opisuje to de sve razvojni tim implementirati i trebao bi ukljuivati i korisnikove zahtjeve u detaljnu specifikaciju zahtjeva sustava (ponekad se mogu i spojiti). Specifikacija moe biti pisana za velik broj tipova korisnika to znai da mora postojati kompromis izmeu objanjavanja zahtjeva korisnicima, preciznog definiranja zahtjeva. Ako se koristi evolucijski pristup mnogi dijelovi de se izbaciti. Fokus de biti na definiranju korisnikih zahtjeva (na visokom nivou) i nefunkcionalnih zahtjeva. Tada programeri i dizajneri moraju sami odluivati kako zadovoljiti korisnikove potrebe. Ako je softver dio vedeg inenjerskog sustava tada se 16

zahtjevi moraju detaljno objasniti. Agilne metode tvrde da se zahtjevi mijenjaju tako brzo da je dokument zastario im je napisan. Ekstremne metode predlau da se zahtjevi inkrementalno skupljaju i zapisuju na kartice. Tipian izgled dokumenta: Uvod svrha, doseg projekta, rjenik, Generalni opis perspektiva, funkcije, karakteristike korisnika, ogranienja, pretpostavke i ovisnosti Specifini zahtjevi pokrivaju funkcionalna i nefunkcionalna svojstva i zahtjeve suelja Dodaci Indeksi

PROCESI IZRADE ZAHTJEVA (Requirements Engineering Processes)Cilj je stvaranje i odravanje dokumenta sa zahtjevima. Ovaj proces se sastoji od etiri pod procesa: studije izvedivosti, otkrivanje i analiza zahtjeva, pisanje specifikacije i validacija.

Studija izvedivostiSvi novi sustavi bi trebali poeti sa studijom izvedivosti, a ona se temelji na poslovnim zahtjevima, okvirnom opisu sustava i njen rezultat je izvjetaj koji preporua da li se treba nastaviti s razvojem. Studija izvedivosti govori da li sustav pridonosi ciljevima organizacije, moe li se sustav implementirati koristedi trenutnu konfiguraciju, dana sredstva i vremenska ogranienja. Ako se nastavlja s pisanjem studije izvedivosti daljnje aktivnosti su: procjena i sakupljanje informacija te pisanje izvjetaja. U izvjetaju se mogu predloiti i promjene budeta, rasporeda

Otkrivanje i analiza zahtjeva (Requirements elicitation and analysis)U ovoj aktivnosti razgovara se klijentima da se dobiju informacije o okruenju aplikacije, koje usluge sustav treba omoguditi, kakve performanse sustav treba imati, hardverska ogranienja Sakupljanje zahtjeva je teko jer: klijenti esto ne znaju to ele, imaju nerealne zahtjeve, izraavaju zahtjeve strunim frazama, razliiti tipovi klijenata mogu imati razliite (ak i kontradiktorne) zahtjeve. Procesne aktivnosti su: otkrivanje zahtjeva, klasifikacija i organizacija zahtjeva, Zahtjevi se prvo otkrivaju, zatim se klasificiraju i odreuju prioriteti. esto se javljaju konflikti u zahtjevima koji se pregovaranjem moraju rijeiti. Na kraju se izrauje dokumentacija. Taj postupak se esto ponavlja vie puta. Otkrivanje zahtjeva je proces sakupljanja informacija (od klijenata, slinih sustava, dokumentacije, poslovnog okruenja) iz kojih se poslije izvode korisniki i sistemski zahtjevi. Svaki izvor informacija predstavlja jednu perspektivu na sustav. Te perspektive (viewpoint) se mogu klasificirati i razlikujemo tri osnovna tipa: direktni (perspektiva osoba/sustava koji direktno komuniciraju sa sustavom) koji pruaju znanje o svojstvima i sueljima sustava; indirektni (perspektiva osoba/sustava koji ne koriste sustav) koji pruaju informacije o organizacijskim zahtjevima i ogranienjima; domain (okolina utjee na zahtjeve).

17

Postoje i specifinije perspektive: pruatelji ili primatelji usluga sustava; sustavi koji se direktno povezuju sa specificiranim sustavom; standardi koji se primjenjuju na sustav; nefunkcionalni zahtjevi, perspektiva osoblja koja razvija (moda imaju iskustva u radu sa slinim sustavima), upravlja i odrava sustav (najvjerojatnije de oni dati zahtjeve koji de olakati odravanje) Za bilo koji vedi sustav postoji velik broj perspektiva i esto ih je korisno hijerarhijski organizirati. Razgovori Razlikujemo dva tipa razgovora: razgovori s predefiniranim pitanjima i slobodniji razgovori; u praksi je to esto kombinacija tih dvaju. Razgovori su dobri jer na taj nain razvojni tim dobiva ire razumijevanje o radu klijenata, njihovom odnosu prema sustavu i problemima s trenutnim nainom rada. Postoji problemi jer klijenti esto koriste argon karakteristian za posao koji obavljaju, esto imaju zahtjeve koje im je teko dobro objasniti ili neke koje smatraju trivijalnima pa ih niti ne navode, ponekad ne ele otkrivati organizacijske probleme koje bi mogli utjecati na zahtjeve Scenariji Scenariji su opisi neke interakcije klijenta sa sustavom i bitan su dio agilnih metoda. Svaki scenarij poinje s okvirnim opisom interakcije koji se s vremenom dopunjuje. Scenarij moe ukljuivati opise: to sustav i klijent oekuju kada scenarij pone, normalnog toka dogaaja, svega to moe podi po zlu i kako se to ispravlja, stanja sustava kada se scenarij zavri. Obino se napie tekst kojem se dodaju dijagrami. Primjeri koritenja (use case) Primjer koritenja je tehnika bazirana na scenarijima koja je sastavni je dio UML notacije. Za opis se koriste stilizirani likovi klijent i imenovane elipse kao klase interakcije. Primjer koritenja identificira interakciju sa sustavom i mogu se dokumentirati s tekstom ili mogu biti povezani s UML modelima. Skup primjera koritenja predstavlja sve mogude interakcije u zahtjevima. Primjeri koritenja i scenariji su uinkoviti naini opisivanja zahtjeva s perspektive stvarnog korisnika sustava (interactor viewpoint).

EtnografijaEtnografija je promatraka tehnika koja se moe koristiti za bolje razumijevanje drutvenih i organizacijskih potreba. Promatra se radni okoli sustava i biljee se informacije o stvarnim zadacima koje klijenti obavljaju. Klijentima je teko precizno artikulirati detalje njihovog posla, a socijalni i organizacijski faktori koji utjeu na posao su esto oiti samo nepristranom promatrau. Etnografija je naroito uinkovita u otkrivanju sljededih tipova zahtjeva: Zahtjeva koji se izvode iz naina na koji ljudi zapravo rade, a ne iz naina na koje bi trebali raditi Zahtjeva koji se izvode iz suradnje i svijesti o aktivnostima drugih ljudi Ovaj nain je izrazito pogodan za otkrivanje zahtjeva krajnjih korisnika, ali nije prikladan za otkrivanje organizacijskih ili domain zahtjeva.

18

Validacija zahtjevaValidacija zahtjeva se bavi s time da dokae da zahtjevi stvarno definiraju sustav koji klijent eli i jako je bitna jer greke koje se ne otkriju u ovom dijelu mogu biti jako skupe kada se otkriju za vrijeme dizajna ili razvoja. Rade se sljedede provjere: Provjera validacije da li navedeni zahtjev stvarno zadovoljava korisnikove potrebe. Napisani zahtjevi su najede kompromisi izmeu zahtjeva vedeg broja korisnika. Provjera konzistentnosti provjerava se da li su zahtjevi kontradiktorni Provjera potpunosti dokument mora sadravati sve zahtjeve koji definiraju svu funkcionalnost i sva ogranienja. Provjerava se da li su zahtjevi realni u okvirima postojedih tehnologija, budeta Provjerava se da li se zahtjevi mogu potvrditi Postoji vie tehnika koje se mogu koristiti: pregledavanje zahtjeva cijeli tim sistematski analizira zahtjeve; izrada prototipa; generiranje testnih sluajeva- zahtjevi se moraju modi testirati.

Pregledavanje zahtjevaPregledavanje zahtjeva je proces koji ukljuuje i lanove razvojnog tima i klijente u kojem oni zajedno pregledavaju zahtjeve. Provjerava se da li su zahtjevi konzistentni, potpuni, da li ih je mogude potvrditi, da li su razumljivi korisnicima, da li je podrijetlo zahtjeva mogude pronadi (traceability), da li je zahtjev prilagodljiv (ako se promjeni hode li to uzrokovati promjene na cijelom sustavu).

Upravljanje zahtjevimaZahtjevi se esto mijenjaju (kako korisnik vie shvada problem, nakon instalacije, promjenom organizacije). Veliki sustavi imaju veliku korisniku bazu iji korisnici esto imaju proturjene zahtjeve, pa je krajnji rezultat esto kompromis; ljudi koji pladaju sustav i korisnici su rijetko iste osobe (pa se nakon instaliranja javljaju nove potrebe); poslovni i tehniki okoli sustava se mijenja nakon instalacije i te promjene se moraju reflektirati na sustavu. Upravljanje zahtjevima je proces razumijevanja i kontroliranja promjena zahtjeva sustava. Preporua se pradenje nezavisnih zahtjeva i povezivanje ovisnih zahtjeva tako da se lake moe odrediti utjecaj promjene na sustav. Trajni i nestalni zahtjevi (enduring and volatile) Trajni zahtjevi su relativno stabilni zahtjevi koji se izvode iz sredinje aktivnosti sustava i koje se direktno odnose na poslovno okruenje sustava. Nestalni zahtjevi su zahtjevi koji de se najvjerojatnije mijenjati tijekom razvoja ili nakon to se sustav stavi u stvarni rad. Planiranje upravljanja zahtjevima Tijekom faze upravljanja zahtjevima mora se odluiti o: Identifikaciji zahtjeva svaki zahtjev se mora jedinstveno identificirati Procesu izmjena zahtjeva set aktivnosti koje procjenjuju utjecaj i cijenu promjena Nainu pradenja zahtjeva definiraju odnose izmeu zahtjeva, zahtjeva i dizajna sustava. Razlikujemo tri tipa pradenja: o pradenje izvora (zahtjev se povee s klijentom koji ga je predloio), o pradenje povezanih zahtjeva, o pradenje dizajna (zahtjevi se povezuju s modulima koji ih implementiraju). esto se za to koriste matrice. Podrci za CASE alate. Postoje alati za spremanje zahtjeva, upravljanje izmjenama i pradenje. 19

Upravljanje promjenama zahtjeva Prednosti koritenja formalnih procesa za upravljanje promjenama zahtjeva su: prema svim promjenama se ponaa isto, promjene na dokumentu se rade na kontroliran nain. Razlikujemo tri faze: analiza problema i promjena specifikacije identificira se problem sa zahtjevima i radi se provjera ispravnosti te promjene; analiza promjene i cijene promatra se koliko promjena utjee na sustav i koliko se mijenja cijena; implementacija promjene modificira se dokument sa zahtjevima i prema potrebi dizajn i implementacija.

SISTEMSKI MODELISistemski modeli se koriste kod pisanja specifikacije i to su grafiki modeli koji opisuju poslovne procese, problem koji je potrebno rijeiti, i sustav koji se razvija. Modeli se razvijaju s razliitih perspektiva: Iz vani (okoline sustava) modelira se kontekst ili okoli sustava Ponaanja - modelira se ponaanje sustava Strukturalno modelira se arhitektura sustava ili struktura podataka Ti modeli su apstrakcija sustava. Razlikujemo tipove modela: Model toka podataka kako se podaci obrauju u razliitim fazama sustava Kompozicijski model kako se entiteti sustava sastoje od drugih entiteta Arhitekturni modeli pokazuju podsustave od kojih se sastoji sustav Klasifikacijski modeli koriste se dijagrami nasljeivanja koji pokazuju kako entiteti imaju zajednike karakteristike Model akcije-reakcije ili model prijelaza stanja kako sustav reagira na podraaje Kontekstni modeli Kod kontekstnih modela se odreuju granice sustava to lei van sustava kojeg rjeavamo. Definira se kontekst u kojem se sustav nalazi i ovisnosti koje taj sustav ima o okoliu. Arhitekturni modeli opisuju okoli sustava, ali ne prikazuju odnose izmeu drugih sustava i sustava koji se specificira. Zbog toga se ti modeli esto nadopunjuju s npr. procesnim modelima koji pokazuju aktivnosti koje sustav podrava. Modeli koji opisuju ponaanje sustava (Behavioral models) Ovakvi modeli se koriste za opisivanje opdeg ponaanja sustava. Razlikujemo dva tipa: modeli toka podataka (data flow models) (koji prikazuju kako sustav obrauje podatke) pogodni za modeliranje poslovnih sustava koje primarno pokredu podatci, modeli stanja sustava (kako sustav reagira na dogaaje) (state machine model) pogodni za prikazivanje sustava za rad u realnom vremenu koje vedinom pokredu dogaaji.

20

Modeli toka podatak (data flow models) Ovi modeli prikazuju kako sustav obrauje podatke i prikazuju se pomodu: zaobljenih pravokutnika (obrada), pravokutnika (pohrana podataka), strelice (prijenos podataka izmeu funkcija). Jednostavni su za shvadanje i pokazuju funkcionalnu perspektivu gdje svaka transformacija prikazuje funkciju procesa.

Modeli stanja sustava (state machine models)Pokazuju stanja sustava i dogaaje koji uzrokuju prijelaz iz stanja u stanje. esto se koristi za modeliranje sustava za rad u realnom vremenu. Zaobljeni pravokutnici prikazuju stanja u kojima se navodi kratak opis to sustav radi u tom stanju. Imenovane strelice prikazuju dogaaj koji uzrokuje prijelaz sustava iz jednog stanja u drugo. Problem s ovim tipom modela je to broj stanja jako brzo pone rasti, ali tada se koriste super stanja koja sadre vie stanja.

Podatkovni modeli (data models)Semantiki podatkovni modeli definiraju logiki oblik podatka koje obrauje sustav. Najpoznatija tehnika je ERA (Entity-Relation-Attribute) koja prikazuje podatkovne entitete, njima pridruene atribute i odnose izmeu tih entiteta. Nuno je uz model drati i detaljan opis atributa i entiteta npr. koristedi rjenik podataka (data dictionary) lista imena kojima se pridruuje opis.

Objektni modeli (objektni modeli)Objektni modeli koji se razviju za vrijeme analize zahtjeva se mogu koristiti za predstavljanje i sistemskih podataka i njihove obrade, klasificiranje entiteta. Praktini su ako se koristi objektno orijentirano programiranje jer olakavaju prijelaz s izrade zahtjeva na programiranje, ali problem je to nisu intuitivno razumljivi krajnjim korisnicima softvera. Entitet iz stvarnog svijeta se modelira koristedi klase. Kod UML dijagrama ime modela se pie na vrhu, u sredinu idu atributi, a na dno metode vezane za objekt. Modeli nasljeivanja (Inheritance models) Taksonomija klasifikacijska shema koja pokazuje kako je klasa povezana s drugim klasama preko zajednikih atributa i metoda. Za prikaz taksonomije se koristi dijagram kod kojeg su klase organizirane prema hijerarhiji nasljeivanja s najopdenitijim klasama na vrhu. Dizajniranje hijerarhije klasa nije jednostavno jer je potrebno detaljno poznavanje problema. Object aggregation Objekti se esto sastoje od drugih objekata. Kod UML dijagrama to se prikazuje pomodu romba na poetku veze. Modeliranje ponaanja objekta Za modeliranje ponaanja objekata nune su metode tog objekta. esto se koriste UML dijagrami aktivnosti koji prikazuju jedan primjer koritenja (use-case). Objekti i korisnici su poredani na vrhu dijagrama. Imenovane strelice predstavljaju operacije. Slijed akcija ide od vrha prema dnu.

21

Strukturirane metodeStrukturirana metoda je sistematian nain izrade modela sustava i pruaju okruenje za detaljno modeliranje sustava kao dijela opisivanja i analize zahtjeva. Vedina takvih modela ima preferirani skup modela sustava i obino definiraju proces koji se moe koristiti da bi se dolo do tih modela. Osiguravaju koritenje standardnih oznaka i izradu standardiziranih dokumenata. Neke slabosti ovih metoda su: ne pruaju uinkovitu podrku za razumijevanje i modeliranje nefunkcionalnih zahtjeva, ne koriste neke smjernice koje mogu pomodi korisniku da izabere metodu za odreeni problem, proizvode previe dokumentacije, dokumentacija je detaljna pa je esto teko razumljiva. U praksi se ne ograniava samo na jednu metodu i esto se koriste CASE alati npr.: editori dijagrama (kreiranje objektnih modela, podatkovnih modela alati svjesni nacrtanih entiteta), alati za provjeru dizajna (pregledavaju dizajn i dojavljuju greke), podatkovni rjenici, alati za definiranje formi, generatori koda

22