SOMMERVILLE SKRIPTA

Juni 2010.

2

Sadržaj Poglavlje 1 - Overview ............................................................................................................................... 6

Uvod: ......................................................................................................................................................... 6

Definicija: ............................................................................................................................................. 6

FAQs (najcesca pitanja): ............................................................................................................................ 6

Razlika izmedju SI i Computer science? .......................................................................................... 6

Razlika izmedju SI i Sistem inzenjeringa? ....................................................................................... 6

Sta je softverski proces? .................................................................................................................... 7

Sta je model softverskog procesa? .................................................................................................. 7

Koje su cijene SI? ............................................................................................................................... 7

Sta su metode softverskog inznjeringa? ......................................................................................... 8

Sta je CASE (computer aided SI)? ................................................................................................... 9

Koje su osobine dobrog softvera? .................................................................................................... 9

Koji su kljucni izazovi sa kojima se suocava SI? ............................................................................ 9

Profesionalna i eticka odgovornost .......................................................................................................... 9

Poglavlje 2 - Društveno – tehnički sistemi ............................................................................................ 10

2.1 Izlazna svojstva sistema .................................................................................................................... 10

2.2 Sistemski inženjering ......................................................................................................................... 11

2.2.1 Definicija sistemskih zahtjeva ........................................................................................................ 12

2.2.2 Dizajn sistema ................................................................................................................................ 12

2.2.3 Modeliranje sistema ...................................................................................................................... 13

2.2.4 Razvoj podsistema ......................................................................................................................... 14

2.2.5 Integracija sistema ......................................................................................................................... 14

2.2.6 Razvoj sistema ................................................................................................................................ 14

2.2.7 Deaktivacija sistema....................................................................................................................... 15

2.3 Organizacije, ljudi i računarski sistemi .............................................................................................. 15

2.3.1 Organizacioni procesi ..................................................................................................................... 15

2.4 Sistemi naslijeđa ............................................................................................................................... 16

Poglavlje 3 - Kritični sistemi ....................................................................................................................... 17

3.1 Jednostavan sigurnsno kritični sistem .............................................................................................. 18

3.2 Pouzdanost sistema .......................................................................................................................... 18

3

3.3 Pouzdanost i funkcionalnost ............................................................................................................. 20

3.4 Sigurnost iznutra ............................................................................................................................... 21

3.5 Sigurnost izvana ................................................................................................................................ 22

Poglavlje 4 - Softverski procesi ................................................................................................................... 23

4.1 Modeli softverskih procesa ............................................................................................................... 23

4.1.1 Waterfall (vodopad) model ............................................................................................................ 23

4.1.2 Evolutivni razvoj ............................................................................................................................. 24

I Softver inzenjering baziran na komponentama (component-based) ................................................... 24

4.2 Ponavljanje procesa .......................................................................................................................... 25

4.2.1 Inkrementalna dostava .................................................................................................................. 25

4.2.2 Spiralni razvoj ................................................................................................................................. 26

4.3 Aktivnosti procesa ............................................................................................................................. 26

4.3.1 Specifikacija softvera ..................................................................................................................... 26

4.3.2 Softver dizajn i implementacija ...................................................................................................... 27

4.3.3 Validacija softvera .......................................................................................................................... 27

4.3.4 Unapredjenje softvera ................................................................................................................... 28

4.4 Rational Unified Process-RUP ........................................................................................................... 28

4.5 Computer Aided Software Engeneering (CASE) ................................................................................ 29

4.5.1 CASE klasifikacija ............................................................................................................................ 29

Poglavlje 5 – Projekt menadžment ............................................................................................................. 29

Aktivnosti menadžmenta ........................................................................................................................ 30

Planiranje projekta .................................................................................................................................. 30

Projektni plan .......................................................................................................................................... 31

Prekretnice i isporučenice ....................................................................................................................... 31

Rapoređivanje projekta....................................................................................................................... 32

Dijagrami i mreža aktivnosti ................................................................................................................... 32

Upravljanje rizikom ................................................................................................................................. 34

Identifikacija rizika .................................................................................................................................. 34

Analiza rizika ........................................................................................................................................... 35

Planiranje rizika ....................................................................................................................................... 35

Monitoring rizika ..................................................................................................................................... 35

Poglavlje 6 - Softverski zahtjevi ................................................................................................................... 36

6.1 Funkcionalni i nefunkcionalni zahtjevi .............................................................................................. 36

6.1.1 Funkcionalni zahtjevi...................................................................................................................... 37

6.1.2 Nefunkcionalni zathjevi .................................................................................................................. 37

4

6.1.3 Zahtjevi domene ............................................................................................................................ 39

6.2 Korisnički zahtjevi .............................................................................................................................. 39

6.3 Sistemski zahtjevi .............................................................................................................................. 39

6.3.1 Struktuiran jezik specifikacije ......................................................................................................... 40

6.4 Specifikacija interfejsa ...................................................................................................................... 40

6.5. Dokument softverskih zahteva ........................................................................................................ 40

Poglavlje 7 - Proces inžinjeringa zahtjeva ................................................................................................... 42

7.1 Studija izvodljivosti ........................................................................................................................... 43

7.2 Otkrivanje i analiza zahtjeva ............................................................................................................. 43

Otkrivanje zahtjeva ................................................................................................................................. 44

Intervjuisanje .......................................................................................................................................... 44

Scenariji ................................................................................................................................................... 45

Slučajevi upotrebe .................................................................................................................................. 45

Etnografija ............................................................................................................................................... 45

7.3 Validacija zahtjeva ............................................................................................................................. 45

Pregledi zahtjeva ................................................................................................................................. 46

7.4 Menadžment zahtjeva ...................................................................................................................... 46

Trajni i promjenjivi zahtjevi ..................................................................................................................... 46

Planiranje menadžmenta zahtjeva ......................................................................................................... 47

Menadžment promjena zahtjeva ............................................................................................................ 47

Poglavlje 8 - Modeli sistema ..................................................................................................................... 48

8.1 Kontekstualni modeli .................................................................................................................. 48

8.2 Modeli ponašanja ........................................................................................................................ 50

8.2.1 Modeli toka podataka ............................................................................................................... 51

i State machine models ..................................................................................................................... 52

8.3 Modeli podataka .......................................................................................................................... 53

8.4 Modeli objekata ........................................................................................................................... 55

8.4.1 Modeli naslijeđivanja ..................................................................................................................... 56

8.4.2 Agregacija objekata .................................................................................................................. 58

8.4.3 Modeliranje ponašanja objekata ............................................................................................. 59

8.5 Structured methods (SM) ........................................................................................................... 60

Poglavlje 9 – Specifikacija kritičnih sistema ................................................................................................ 62

Rizikom upravljana specifikacija ............................................................................................................. 62

Identifikacija rizika .................................................................................................................................. 63

Analiza i klasifikacija rizika ...................................................................................................................... 63

5

Dekompozicija rizika ............................................................................................................................... 64

Mjere za suzbijanje rizika ........................................................................................................................ 65

Specifikacija o pouzdanosti ..................................................................................................................... 65

Sigurnosna specifikacija .......................................................................................................................... 67

Specifikacija oporavljivosti sistema ........................................................................................................ 69

Metrike za mjerenja oporavljivosti ......................................................................................................... 70

Nefunkcionalni zahtjevi na oporavljivost ................................................................................................ 70

6

Poglavlje 1 - Overview

Uvod: Cilj ovog poglavlja je da se napravi uvod u SI i da napravi temelje razumjevanja ostatka knjige. Razumjevanje sta je SI i zasto je vazan Odgovor na kljucna pitanja o SI Razumjevanje nekih etickih i profesionlnih situacija koje su vazne za SI

Definicija: SI je inzenjerska disciplina ciji je fokus na razvijanju ekonomski-optimalnih visokokvalitetnih softverskih sistema. Si se tice svih aspekata razvolja softvera. Pojam se prvi put javlja 1968 godine na konfrenciji povodim tzv softverske krize. SI usvaja sistematski i organizovani pristup pri rjesavanju problema sto je i najefektivniji nacin razvoja kvalitetnog softvera. Cilj je izabrti najpogodniju metodu pod odredjenim okolnostima, a da ujuedno bude i kreativna. Nekada je kreativnost vaznija od fozmalnog dizajna, primjeri su web aplikacije i graficki dizajn.

FAQs (najcesca pitanja):

Softver po definicji predstavlja sam programski kod sa njemu odgovarajucom dokumentacijom i podacima koji konfigurisu softver kako bi on ispravno radio. Konfiguracijski fajlovi koji se koriste da se program ispravno postavi za rad, sistemsku dokumentaciju koja objasnjava strukturu samog sistema i korisnicku dokumentaciju koja korisnike uvodi u rad na sistemu. Postoje dva tipa softvera :

Genericki proizvodi, samostalni sistemi koji se otvoreno prodaju na trzistu kupcu koji je u mogucnosti da ga sebi priusti. Primjer takvog softvera su baze podataka, text procesori, graficki alati...

Namjenski (customised), sistemi koji se prave tacno po narudzbi kupca i tacno po njegovim zeljama i samo za njega. Primjeri ovakvog softvera su kontrolni sistemi za elektronicke uredjaje, sistemi za podrsku poslovnim procesima, sistem za kontrolu zracnog saobracaja...

Kod generickog softvera reviziju i kontrolu specifikacije radi organizacija koja razvija sam softver dok kod namjenskog to radi klijent. Granica izmedju ova dva tipa softvera postaje sve tanja jer sve vise kompanija zapocinje sa generickim softverom, a onda ga kasumizra po potrebama klijenta.

Razlika izmedju SI i Computer science? CS se bavi teoretskim osnovama i temeljima racunarstva dok se SI bavi proizvodnjom softvera. CS predstavlja temeljna znanja SI-a. U idealnom slucaju SI bi trebao biti potkovan teorijom CS-a sto cesto nije slucaj zato sto se teorije CS-a cesto ne mogu primjeniti na realne i kompleksne probleme koje zahtjeva softversko rjesenje.

Razlika izmedju SI i Sistem inzenjeringa? SI je podgrana sistem inzenjeringa, tj samo je jedan proces koji pokriva sistem inzenjering. Sistem inznjering obuhvata hardverski, softverski i procesni inzenjering. Sistem inznjeri se bave specificiranjem sistema, arhitektur i integracijom ciji je krajnji produkt finalni sistem.

7

Sta je softverski proces? To je skup aktivnosti ciji je cilj razvoj ili evolucija softvera. Postoje 4 fundamentalne procesne aktivnosti:

1. Specifikacija gdje kupac i inzenjer zajedno definisu softver, njegova ogranicenja i funkcionalnosti

2. Razvoj softvera obuhvata dizajn i programiranje 3. Validacija gdje se vrsi provjera da li krajnji produkt ispunjava sve zahtjeve kupca 4. Unaprjedjenje gdje se vrse modifikaciije i prilagodjavanje zahtjevima kupca i trzisnim

zahtjevima

Sta je model softverskog procesa? Predstavlja pojednostavljni prikaz softverskog procesa prikazan iz specificne perspektive. Primjeri modela softvrkog procesa:

- Workflow , sekvenca aktivnosti u procesu zajedno sa ulazima, izlazima i zavisnostima. - Activity model, dataflow predstavlja skup aktivnosti koje nose transformacije nad

podacima - Kako se ulaz transformise u izlaz. Aktivnosti mogu pedstavljati ili transformacije od

strane korisnika ili od strane racunara - Role action model predstvlja uloge i odgovornosti ljudi ukljucenih u softverski proces

1. Vecina softverskih procesnih modela su bazirana na tri generalna modela: 2. Waterfall koristi rezultate prethodnih aktivnosti da bi se zavrsile trenutne. Razvoj se

razdvaja na nivoe(faze) i nakon sto je jedna faza zavrsena prelazi se na sljedeci 3. Iterativni model medjusobno preplice aktivnosti specifikacije, razvoja i validacije.

Inicijalno sistem se brzo razvija iz veoma opcenite specifikacije, onda se vrsi rafiniranje prema korisnickim zahtjevima i nakon toga se sistem moze isporuciti ili se vrsi reimplementacija koristeci strukturirniji pristup da bi se proizveo robusniji softver i laksi za odrzavanje

4. Component based, ova tehnika podrazumijeva da dijelovi sistema vec postoje i proces razvoja se bazira a integraciji tih dijelova, a ne na razvoju tih dijelova iz pocetka

Koje su cijene SI? 60% resursa oduzima razvoj, a 40% testiranje, dok za namjenski softver unaprjedjenje softvera najcesce prevazilazi troskove razvoja.

8

Kod waterfall metode troskovi specifikacije, dizajna, implementacije i integracije se mjere odvojeno. Integracija i testiranje je najskuplji dio razvoja (40%) a u nekim kriticnim sistemima moze dostici i do 50%. U iterativnom pristupu ne postoji jasna granica izmedju speciifikacije, dizajna i razvoja. Troskovi specifikacije su reducirani zato sto se na pocetku razvija opsta specifikacija. Specifikacija, dizajn, implemntacija, integracija i testiranje se izvrsavaju paralelno pa troskovi ne mogu biti jasno odredjeni, mada nakon sto je inicijalna implementacija zavrsena mora se izvrsiti odvojena aktivnost testiranja. Component based u SI-u se koristio kratko vrijeme tako da nisu napravljena istrazivanja o troskovima pojedine aktivnosti. Sigurno je da su cijene razvoja bile manje u odnosu na integraciju i testiranje ciji su se troskovi povecali jer se moralo osigurati da svaka od komponenti radi onako kako specifikacija zahtjeva. Cijene unapredjivanja softvera dramaticno zavise od tipa sistema, tako da troskovi unapredjenja kontrolnih sistema koji se koriste od 10 godina i vise cijenun razvoja prevazilaze za faktor 3 do 4, manji biznis sistemi koji imaju mnogo kraci zivotni vijek imaju reduciran trosak unapredjenja.

Sta su metode softverskog inznjeringa? To je struktuirani pristup razvoja softvera koji ukljucuje modele sistema, standarde pisanja koda (notations), pravila, dizajn i vodjenje cijelog procesa razvoja (guidens).

9

1970ih funkcijsko orjentisane metode, 1908a i 90te unaprijednjeno sa objektno orjentisanom metodom i 1999. ova dva pristupa su integrisana u jedinstvni pristup koji se zove Unified Model Language UML

Sta je CASE (computer aided SI)? Automatizovana podrska aktivnosti nad softverskim procesima. Vrlo cesto se koriste za podrsku metodama SI-a. Pokriva siroki opseg svih vrsta programa koji sluze kao podrska aktivnostima za razvoj softvera kao sto su analiza zahtjeva, modeliranje sistema, debagovanje i testiranje. Sve ove metode su sada povezane CASE tehnologijom. CASE alati takodjer mogu sadrzavati code generator koji generise izvorni kod na osnovu modela uradjenog u ovom alatu.

Koje su osobine dobrog softvera?

Kvalitetan softver bi trebao imati zahtjevane funkcionalnosti i performanse, da bude jednostavan za odrzavanje i koristan. Lagan za odrzavanje, trebo bi biti napisan na takav nacin da se vrlo brzo mogu napraviti izmjene trazene od strane klijenta, a to je jedna od najcescih aktivnosti pri razvoju Dependability – podrazumijeva pouzdanost i sigurnost, to znaci da nece prouzrokovati fizicku ili konomsku stetu u slucaju pada sistema Efikasnost, softver bi trebao veoma brzo reagovati na zahtjeve i da sto bolje iskoristi resurse sistema. Iskoristivost, podrazumijeva da bude koristan onome za koga je namjenjen, to znaci da treba imati odgovarajuci korisnicki interfejs i korisnicku dokumentaciju

Koji su kljucni izazovi sa kojima se suocava SI?

Zavrsiti sve u roku, napraviti pouzdan softver i povezati sve razlicitosti u sistemu. 1) Integracija/raznolikost - Sistem bi morao imati mogucnost da komunicira sa raznolikim

sistemima preko mreze sto podrazumijev integrciju novog softvera sa nekim drugim sistemima napisanim u razlicitim programskim jezicima. Tehnike razvijanja se nalaze pred izazovom da razviju takav softver koji je dovoljno fleksibilan i kooperativan sa ovakvom raznolikoscu

2) Isporuka sistema – tradicionalne tehnike softver inzenjeringa zahtjevaju vrijeme tako da se ove tehnike sistema nalaze pred izazovom da vrijeme isporuke smanje sto je moguce vise za velike kompleksne sisteme, ali bez kompromitovanja kvalitete softvera

3) Povjerenje - posto je softver ukljucen u svakodnevne zivotne aktivnosti vazno je da mozemo imati povjrenje u taj softver. Ovo povjerenje je posebno vazno u udaljenim sistemima (remote) kojima se pristupa kroz web stranice ili web servise. Izazov je da se razvije takva tehnika koja ce osigurati da softver ima povjerenje od strane korisnika.

Profesionalna i eticka odgovornost Softver inzenjering se mora nositi sa socijalnim okvirima kojim ogranicava slobodu. Takodjer nosi eticku i moralnu odgovornost da bi inzenjeri bili postovani kao profesionalci. Njihove mogucnosti i vjestine ih ne bi smjele dovesti u situaciju gubitka reputacije

1) Postovati privatnost zaposlenih ili klijenata na osnovu ugovora koji je potpisan 2) Kompetentnost – softver inzenjeri ne bi trebali svjesno prihatiti posao koji je izvan

njihovih mogucnosti

10

3) Intelektualno vlasnistvo zaposlenih i klijenata – treba obratiti paznju na zakone lokalne vlade na intelektualno vlasnistvo i copyright

4) Zloupotreba racunara – od trivijalnih kao sto su igranje igara na racunaru poslodavca do ekstremnijih zloupotreba kao sto su virusi, bekdori ili bilo kakav drugi maliciozan softver.

Poglavlje 2 - Društveno – tehnički sistemi Ovdje ćemo se fokusirati na sisteme koje uključuju računare i koji imaju neku specifičnu namjenu kao npr. da omoguće komunikaciju, podrže navigaciju, i računaju plate. Stoga, korisna definicija ovih tipova sistema može biti sljedeća : Sistem je kolekcija medjusobno povezanih komponenti koje zajedno rade da bi postigle neki cilj.

Softverski sistemi se dijele u 2 kategorije : - Tehnički računarsko-bazirani sistemi su sistemi koji uključuju hardverske i softverske

komponente ali ne procedure i procese. Primjeri tehničkih sistema uključuju televiziju, mobilne telefone i najpersonalniji računarski softver.

- Društveno-tehnički sistemi uključuju jedan ili više tehničkih sistema ali, presudno, takoĎe uključuju znanje o tome kako se sistemi trebaju koristiti da bi postigli neki širi cilj.

Najbitnije karakteristike društveno-tehničkih sistema su sljedeće : 1) Imaju izlazna svojstva koja su svojstva sistema kao cjelina prije nego što su povezana sa

posebnim dijelovima sistema. Ova izlazna svojsta zavise od komponenti sistema kao i od veza izmeĎu njih. Pošto je ovo kompleksno, izlazna svojstva mogu jedino biti vrednovana kada je sistem montiran.

2) Oni su često nedeterministički. Ovo znači da, kada su predstavljeni sa specifičnim ulazom, e moraju uvjek dati isti izlaz. Ponašanje sistema zavisi od ljudskih operatora, a ljudi se često ne ponašaju na isti način.

3) Stepen u kojem sistem podržava organoizacione ciljeve ne zavisi samo od samog sistema. TakoĎe zavisi od stabilnosti samih ciljeva, odnosa i konflikata izmeĎu organizacionih ciljeva i toga kako ljudi u organizaciji tumače ove ciljeve.

Sistemi su obično hijerarhijski organizovani i uključuju druge sisteme, koji se nazivaju podsistemi. Njihova karakteristika je da mogu raditi kao nezavisni sistemi. Softverski inženjering je ključan za uspješan razvoj kompleksnih, računarsko-baziranih društveno-tehničkih sistema.

2.1 Izlazna svojstva sistema Postoje 2 tipa ovih svojstava :

1) Funkcionalna izlazna svojstva se pojavljuju kada svi dijelovi sistema rade zajedno da bi postigli neki cilj.

2) Nefunkcionalna izlazna svojstva se povezuju sa ponašanjem sistema u svom operativnom okruženju. Primjeri nefunkcionalnih svojstava su pouzdanost, performanse, sigurnost i bezbjednost.

11

Primjeri izlaznih svojstava :

Svojstvo Opis

Obim Obim sistema (ukupni zauzet prostor) varira zavisno od toga kako su komponente ureĎene i povezane.

Pouzdanost Sistemska pouzanost zavisi od pouzdanosti komponenti ali neočekivane interakcije mogu uzrokovati nove tipove neuspjeha i uticati na pozdanost sistema.

Sigurnost Sigurnost sistema (sposobnost da odbija napade) je kompleksno svojstvo. Napadi mogu biti osmišljeni tako da nisu očekivani od strane dizajnera sistema, i tako mogu probiti zaštitu.

Sposobnost na opravku Ovo svojstvo utiče na to koliko je lako popraviti problem na sistemu jednom kada je otkriven. Zavisi od sposobnosti identificiranja problema, pristupa komponentama koje su neispravne i modifikaciji ili zamjeni ovih komponenti.

Upotrebljivost Ovo svojstvo utiče na to koliko je jednostavno koristiti sistem. Zavisi od tehničkih komponenti sistema, operatora i operativnog okruženja.

Postoje 3 povezana uticaja na cjelokupnu pouzdanost sistema : 1) Pouzdanost hardvera. Koja je vjerovatnoća da će hardverska komponenta otkazati i

koliko će biti vremena potrebno da se popravi ta komponenta? 2) Pouzdanost softvera. Kolika je vjerovatnoća da će softverska komponenta dati pogrešan

izlaz? 3) Pouzdanost operatora. Kolika je vjerovatnoća da će operator sistema napraviti grešku?

Slika : Proces sistemskog inženjeringa

2.2 Sistemski inženjering Sistemski inženjering je aktivnost specificiranja, dizajna, implementacije, validacije, razvoja i održavanja društveno-tehničkih sistema. Faze sistemskog inženjeringa su prikazane na prethodnoj slici. Postoje bitne razlike izmeĎu procesa sistemskog inženjeringa i procesa softverskog razvoja :

1) Ograničeni obim dorade u toku razvoja sistema. Jednom kada su neke odluke u sistemskom inženjeringu napravljene, jako je skupa njihova promjena. Jedan razlog zbog čega je softver postao toliko bitan u sistemima je to što dopušta promjene u toku razvoja sistema, u skladu sa novim zahjevima.

12

2) Interdisciplinarno učešće. Mnoge inženjerske discipline mogu biti uključene u sistemski inženjering. Postoji dosta prostora za loše razumjevanje jer različiti inženjeri koriste različitu terminologiju i konvencije.

Primjeri nekih disciplina koje mogu biti povezane sa sistemskim inženjeringom : - softverski inženjering - elektronski inženjering - mehanički inženjering - strukturni inženjering - dizajn korisničkog interfejsa - civilni inženjering - elektronički inženjering - arhitektonski inženjering

2.2.1 Definicija sistemskih zahtjeva Definicije sistemskih zahjeva specificiraju šta sistem treba raditi (funkcije sistema) i suštinska i poželjna svojstva sistema. Kreiranje ovih definicija zahjeva uključuje interakciju sa kupcima sistema i krajnjim korisnicima. Ova faza se obično sastoji od izvoĎenja 3 tipa zahjeva :

1) Apstraktni funkcionalni zahjevi. Osnovne funkcije koje sistem mora obezbjediti su definisane na apstraktnom nivou.

2) Sistemska svojstva. Ovo su nefunkcionalna izlazna sistemska svojstva kao što su dostupnost, performanse i bezbjednost.

3) Karakteristike koje sistem ne smije prikazati. Nekad je važno specificirati šta sistem ne smije raditi.

Bitan dio definisanja zahjeva je uspostavljanje skupa krajnjih ciljeva koje sistem treba ispuniti. Ponekad se javlja tzv. „wicket“ problem. To je problem koji je toliko kompleksan da nije moguće dati definitivnu specifikaciju problema. Prava priroda problema se javlja tek u toku razvoja rješenja. Primjer ovoga je planiranje zemljotresa.

2.2.2 Dizajn sistema

Slika : Proces dizajna sistema

Dizajn sistema (prethodna slika) se brine o tome kako je funkcionalnost sistema obezbjeĎena od strane komponenti sistema. Aktivnosti koje su dio ovog procesa su :

13

1) Podjeljeni zahtjevi. Zahtjevi se analiziraju i organizuju u povezane grupe. Obično postoje nekoliko mogućih opcija podjele, i moguće je predložiti neki broj alternativa u ovom stadijumu procesa.

2) Identifikovati podsisteme. Podsistemi koji individualno ili kolektivno mogu udovoljiti zahjeve, se identifikuju.

3) Dodjeliti zahjeve podsistemima. U globalu, ovo bi trebalo biti jasno ako se podjela zahtjeva koristila u cilju identifikacije podsistema.

4) Navjesti funkcionalnost podsistema. Trebaju se navjesti posebne funkcije koje obezbjeĎuje svaki podsistem. TakoĎe se trebaju identifikovati odnozi izmeĎu podsistema u ovoj fazi.

5) Definisati interfejs podsistema. Definišu se interfejsi koji su obezbjeĎeni i zahtjevani od svakog podsistema.

Slika : Zahjevi i dizajn sistema Kao što se vidi na slici, postoji povratna sprega i ponavljanje od jedne faze do druge u ovom procesu dizajna. Kako raste broj problema i pitanja, često se morate vraćati u prethodne faze. U praksi, procesi zahtjeva i dizajna su bitno povezani. Ograničenja postojećih sistema mogu ograničiti odluke dizajna, a ove odluke mogu biti navedene u zahtjevima. Kako se nastavlja proces dizajna, moguće je otkriti nove probleme sa postojećim zahtjevima a i novi zahtjevi se mogu pojaviti. Sve ovo se može primjetiti preko spirale, na prethodnoj slici. Spiralni proces se odražava na realnost da zahtjevi mogu uticati na odluke dizajna i obrnuto. Kada krenemo od centra, svaki krug spirale može dodati detalj zahjevima i dizajnu. Kod skoro svih sistema, postoji više mogućih rješenja dizajna koji su u skladu sa zahtjevima. Ovaj proces je gotov kada pregled i procjena pokažu da su zahtjevi i dizajn na visokom nivou dovoljno detaljni da dopuste početak sljedeće faze procesa.

2.2.3 Modeliranje sistema

U toku aktivnosti zahtjeva i dizajna, sistemi mogu biti modelirani kao skup komponenti i odnosa meĎu njima. Ovo je obično grafički ilustrovano da bi čitaocu omogućilo pregled organizacije sistema. Arhitektura sistema može biti predstavljena kao blok-dijagram koji pokazuje glavne podsisteme i odnose izmeĎu njih. Jednostavan blok dijagram alarm-sistema :

14

Ovakav dijagram treba biti podržan sa kratkim opisima svakog podsistema.

2.2.4 Razvoj podsistema Tokom razvoja podsistema, implementiraju se podsistemi identifikovani tokom dizajna. Ovo može uključivati drugi proces sistem inženjeringa za individualne podsisteme, ili ako je podsistem softver, softverski proces koji uključuje zahtjeve, dizajn, implementaciju i testiranje. Podsistemi se obično razvijaju paralelno. Kada se javi problem koji prevazilazi granice podsistema, mora se napraviti zahtjev za modifikaciju sistema. Obično su takvi zahtjevi vrlo skupi, kada sistem uključuje hardverski inženjering.

2.2.5 Integracija sistema

Tokom ovog procesa, uzimaju se nezavisno razvijani podsistemi i integrišu se da bi formirali kompletan sistem. Integracija se može izvršiti koristeći “big bang” pristup, kada su svi sistemi integrisani u isto vrijeme. Ipak, inkrementalna integracija, kada se sistemi integrišu jedan po jedan, je bolja, iz 2 razloga :

1) Obično je nemoguće rasporediti razvoj svih podsistema tako da budu završeni u isto vrijeme.

2) Inkrementalna integracija smanjuje troškove lociranja greške. Ako se greška pojavi tokom simultane integracije svih podsistema, ona može biti u bilo kojem podsistemu. Kada se jedan podsistem integriše, greška se nalazi ili u novom podsistemu, ili u interakciji izmeĎu novog i postojećeg podsistema.

Jednom kada se komponente integrišu, sprovodi se obimno testiranje. U nekim slučajevima, integracija sistema zamjenjuje fazu implementacije sistema.

2.2.6 Razvoj sistema

Razvoj sistema, kao i razvoj softvera, je bitno skupo, iz sljedećih razloga : 1) Predložene promjene moraju biti analizirane jako pažljivo sa tehnološke i perspektive

biznisa. 2) Zbog toga što podsistemi nikada nisu potpuno nezavisni, promjene na jednom

podsistemu mogu uticati na ponašanje ili performanse drugog podsistema. 3) Razlozi za originalne odluke dizajna su često neregistrovani. 4) Kako sistemi stare, njihova struktura tipično postaje oštećena promjenama tako da se

troškovi pravljenja dodatnih promjena povećavaju. Sistemi koji imaju kritičnu ulogu u organizaciji se često nazivaju sistemi naslijeĎa – sistemi kod kojih je rizik promjene jako veliki.

15

2.2.7 Deaktivacija sistema Deaktivacija sistema znači uzimanje sistema iz službe nakon kraja njegovog korisnog operativnog vijeka. Za hardverske ureĎaje, ovo može značiti demontažu, recikliranje materijala ili uništavanje toksičnim supstancama. Softver nema problem fizičke deaktivacije, a neki proces može imati svrhu deaktivacije u sistemu. Ako su podaci sistema nakon njegove deaktivacije još uvjek bitni za organizaciju, moguće ih je koristiti u nekom drugom sistemu.

2.3 Organizacije, ljudi i računarski sistemi Ljudski i faktori organizacije koji utiču na dizajn sistema uključuju :

1) Promjene procesa. Da li sistem zahtjeva promjene poslovnih procesa u okruženju? Ako da, trening je potreban.

2) Promjene posla. Da li sistem utiče na promjenu načina na koji korisnici rade? Ako da, ljudi mogu biti protiv uvoĎenja sistema u organizaciju.

3) Promjene organizacije. Da li sistem mijenja političku moć strukture u organizaciji? Npr. ako organizacija zavisi od jako kompleksnog sistema, oni koji znaju kako raditi sa takvim sistemom imaju veliku političku moć.

Ovi ljudski, društveni i organizacioni faktori su često kritični u odreĎivanju da li sistem uspješno obavlja svoj cilj. Nažalost, predviĎanje njihovih efekata je jako teško za inženjere koji imaju manje iskustva u društvenim i kulturnim studijima. Najbolje bi bilo kada bi svo bitno znanje bilo uključeno u specifikaciju sistema. Ovo je u realnosti nemoguće.

2.3.1 Organizacioni procesi

Slika : Nabavka, razvoj i operacioni procesi

Proces razvoja nije jedini proces uključen u sistemski inženjering. On je i interakciji sa sistemskim procesom nabavke i sa procesom korištenja i rada na sistemu. Ovo je prikazano na prethodnoj slici. Proces nabavke je obično uključen unutar organizacije koja će kupiti i koristiti sistem (klijentska organizacija). On se bavi odlukama o najboljem načinu da ta organizacija uzme sistem, kao i o odlukama koji su najbolji nabavljači tog sistema.

16

Slika : Proces sistemske nabavke Prethodna slika pokazuje proces nabavke za postojeće sisteme kao i za sisteme koji tek trebaju biti specijalno dizajnirani. Bitnije tačke u ovom procesu sa dijagrama su sljedeće :

1) Neke komponente koje su spremne za prodaju ne moraju uvijek pratiti direktno zahjeve, osim ako su zahtjevi napisani sa ovim komponentama na umu. Zbog toga, odabir sistema znači da morate naći najveću sličnost izmeĎu ovih komponenti i sistemskih zahjeva.

2) Kada sistem treba biti posebno izraĎen, specifikacija zahtjeva treba djelovati kao osnova ugovora za sistemsku nabavku.

3) Kada preduzetnik treba izgraditi sistem koji je odabran, postoji period pregovora o ugovoru, gdje se može pregovarati o daljim promjenama zahtjeva i diskutovati problemi.

Kompleksni sistemi su obično razvijani od strane drugačije organizacije od one koja se bavi nabavkom sistema. Operacioni procesi su uključeni u korištenje sistema za definisanu svrhu. Glavni cilj ljudskih faktora u sistemu je to da ljudi imaju jedinstvenu sposobnost da odgovore efektivno na neočekivane situacije čak i kad nisu imali direktnog iskustva u tim situacijama. Operatori koriste svoje znanje da prisvoje i poboljšaju procese. Obično, stvarni operacioni procesi su drugačiji od onih definisanih u dizajnu sistema. Ovo znači da dizajneri trebaju dizajnirati operacione procese koji su fleksibilni i prihvatljivi.

2.4 Sistemi naslijeđa Zbog vremena i napora koji su potrebni za razvoj kompleksnog sistema, veliki računarski sistemi su obično dugog vijeka. Nekad je previše rizično ili skupo odbaciti takve sisteme poslije nekoliko godina korištenja. Njihov razvoj se nastavlja kroz njihov vijek sa promjenama da bi se sistem prilagodio novim zahtjevima, novim operativnim platformama, itd. Sistemi naslijeĎa su društveno-tehnički računarsko-bazirani sistemi koji su razvijani u prošlosti, često koristeći staru ili zastarjelu tehnologiju. Oni ne uključuju samo hardver i softver, nego i naslijeĎene procese i procedure – stari načini na koje se stvari rade su teški za promjenu jer se oslanjaju na naslijeĎeni softver. Sistemi naslijeĎa su često kritični sistemi za poslovanje. Oni se održavaju jer je previše rizično da se zamjene. Sljedeća slika pokazuje logičke dijelove sistema naslijeĎa i njihove odnose : (pogledati sliku na str. 58)

1) Sistemski hardver. 2) Softver podrške. 3) Aplikacijski softver. 4) Aplikacijski podaci.

17

5) Poslovni procesi. 6) Poslovna politika i pravila.

Drugačiji pogled na ove komponente se može prikazati preko slojeva. Svaki sloj zavisi od sloja ispod. (pogledati tabelu na str. 59, nejasan zadnji red) U praksi, ova prosta enkapsulacija rijetko radi, i promjene u jednom sloju sistemo mogu zahtijevati promjene sloja i iznad i ispod tog sloja. Razlozi za ovo su sljedeći :

1) Promjena u jednom sloju sistema može donijeti nove objekte, i viši slojevi mogu biti promjenjeni da bi iskoristili te objekte na pravi način.

2) Promjena softvera može usporiti sistem tako da je potreban novi hardver da bi poboljšao performanse sistema.

3) Često je nemoguće sačuvati interfejse hardvera, posebno kada je predložena radikalna promjena na novi tip hardvera.

Poglavlje 3 - Kritični sistemi U nekim sistemima greške mogu rezultirati značajnim ekonomskim gubicima, fizičkom štetom ili čak gubitkom ljudskih života. Takve sisteme zovemo kritičnim sistemima. Postoje tri glavna tipa kritičnih sistema: 1. Sigurnosno kritični sistemi – sistemi čiji kvar može prouzrokovati povrede, gubitke ljudskih života ili ozbiljna oštećenja u okruženju. Primjer: kontrolni sistem za hemijsko postrojenje. 2. Mission critical systems – sistemi čiji kvar može rezultirati nepostizanjem ciljno-usmjerene aktivnosti. Primjer: navigacioni sistem za svemirsku letjelicu. 3. Business critical system – sistemi čiji kvar može uzrokovati velike novčane gubitke. Primjer: sistem za čuvanje podataka o korisnicima banke. Najvažnija emergent (osobina sistema kao cjeline) osobina kritičnih sistema jeste pouzdanost -oslonjivost. Ovim pojmom obuhvaćeni su atributi sistema kao što su: dostupnost, funkcionalnost, sigurnost izvana i sigurnost iznutra. Nekoliko je razloga zašto je pouzdanost najvažnija osobina kritičnih sistema:

1. Korisnici odbijaju koristiti sisteme koji ne ispunjavaju potrebnu funkcionalnost, koji su nesigurni (izvana i iznutra).

2. Kvarovi mogu biti enormno skupi. 3. U nepouzdanim sistemima može doći do gubitka informacija.

U razvoju kritičnih sistema obično se koriste pouzdane i već dobro provjerene tehnike i metode. Skupe tehnike koje nisu troškovno efikasne u nekritičnim sistemima nerijetko se primjenjuju u razvoju kritičnih sistema npr. formalne matematičke metode. Razlog za njihovu primjenu jeste što reduciraju troškove testiranja. Većina kritičnih sistema su socio-tehnički sistemi gdje ljudi nadgledaju i kontrolišu rad kompjuterski baziranih sistema. Pošto su troškovi kvarova u ovakvim sistema skupi, ljudi su tu da se izbore sa neočekivanim situacijama i da obezbjede oporavak sistema kada se desi nešto nepredviĎeno. Greške u kritičnim sistemima se javljaju zbog greške: 1) u hardveru (greška u dizajnu, proizvodnji ili starost komponente) 2) u softveru (greška u specifikaciji, dizajnu ili implementaciji) 3) operatera (najčešći uzrok greške)

18

Ove greške mogu biti povezane (greška u hardveru može uzrokovati grešku operatera koja dalje može prouzročiti grešku u softveru). Prilikom dizajniranja kritičnih sistema važno je primjeniti holistički pristup, a ne odvojeno posmatrati komponente sistema.

3.1 Jednostavan sigurnsno kritični sistem

Slika: Inzulinska pumpa

Dijabetes nastaje kada pankreas ne proizvodi dovoljnu količinu hormona zvanog inzulin. Inzulin razlaže šećer u krvi. Kovnecionalno liječenje uključuje ubrizgavanje inzulina. Dijabetičari mjere nivo šećera u krvi, zatim se na osnovu toga proračunava koja količina inzulina treba biti ubrizgana. Količina inzulina ne zavisi samo od nivo šećera u krvi, već je ona i funkcija vremena kada je posljednji put uzeta doza inzuilina. Softverski kontrolisan sistem za ubrizgavanje inzulina koristi mikro senzor ugraĎen u pacijenta koji mjeri neki parametar krvi koji je proporcionalan nivou šećera. Taj podatak se šalje kontroleru pumpe. Kontroler proračunava nivo šećera i potrebnu količinu inzulina. Nakon toga šalje signal pumpi da ubrizga inzulin. Ovaj sistem ima dva zahtjeva na visokom nivou koja se tiču pouzdanosti(dependability) :

1. Sistem mora biti dostupan da ubrizga inzulin kada je to potrebno. 2. Sistem mora isporučivati korektnu količinu inzulina da neutralizira trenutni nivo šećera.

3.2 Pouzdanost sistema

19

Pouzdanost kompjuterskog sistema je osobina sistema koje se izjednačava sa povjerljivošću . To je stepen povjerenja koje korisnik ima u sistem, tj. da će sistem raditi kako je očekivano i da neće doći do otkaza prilikom normalne upotrebe. Postoje četiri glavne dimenzije pouzdanosti/oslonjivosti:

- Dostupnost - vjerovatnoća da će sistem raditi i pružati neophodne servise u bilo koje vrijeme.

- Funkcionalnost – vjerovatnoća da će sistem tokom zadanog perioda vremena korektno pružati usluge kako to očekuje korisnik.

- Sigurnost iznutra – procjena mogućnosti da sistem nanese štetu ljudima ili svom okruženju.

- Sigurnost izvana – procjena koliko je vjerovatno da se sistem može oduprijeti slučajnim ili namjernim napadima.

Ovo su komplekesne osobine koje se mogu razložiti na nekoliko drugih jednostavnijih osobina. Na primjer sigunost izvana uključuje integritet (osiguravanje da sistemski programi i podaci nisu oštećeni) i povjerljivost(osiguravanje da pristup informacijama imaju smo osobe koje su sutorizovane) . Osim ove četiri glavne dimenzije i druge osobine sistema takoĎer mogu biti razmatrane pod zaglavljem pouzdanosti/oslonjivosti:

- Popravljivost-mogućnost brzog popravka od greške. Popravljivost softvera je poboljšana kada organizacija koristi sistem koji ima pristup izvornom kodu i ima sposobnost da ga mijenja. Nažalost, ovo postaje rijetkost kako se krećemo ka razvoju sistema koristeći third party (već gotov sosftver) komponente, koje su kao takve crne kutije.

- Mogućnost lahkog održavanja- S vremenom tokom korištenja sistema pojavljuju se novi zahtjevi. Veoma je važno održavati korisnost sistema mijenjajući ga da bi se prilagodio tim novim zahtjevima. Softver je pogodan za održavanje ako može biti ekonomično adaptiran da odgovori na nove zahtjeve i ako je mala mogućnost uvoĎenja novih grešaka.

- Izdržljivost- veoma važna osobina za Internet bazirane sisteme, koja je u bliskoj vezi sa dostupnošću. Izdržljivost je sposobnost sistema da nastavi da pruža usluge dok je napadnut ili dok je jedan dio sistema isključen. Za povećanje izdržljivosti važno je identificirati ključne komponente i obezbjediti da su one u stanju pružiti barem minimum usluga koje se očekuju. Postoje tri strategije koje se koriste za poboljšanje izdržljivosti: otpornost na napade, prepoznavanje napada i oporavak od štete nanesene napadom.

- Tolerancija greške-ova osobina se može razmatrati kao dio upotrebljivosti(usability) i odražava granice za koje je sistem dizajniran tako da se korisnički pogrešni unosi izbjegavaju i tolerišu.

Slika: kriva cijena /pouzdanost

20

Već smo naveli četiri glavne osobine kritičnih sistema, meĎutim one nisu primjenljive na sve sisteme. Npr. za inzulinsku pumpu su važne dostupnost, funkcionalnost i sigurnost iznutra. Sigurnost izvana nije bitna jer ovaj sistem ne sadrži nikakve povjerljive informacije, nije umrežen i ne može biti maliciozno napadnut. Dizajneri često moraju praviti balans(kompromis) izmeĎu performansi sistema i njegove pouzdanosti. Genralno, visok nivo pouzdanosti može biti postignut na uštrb performansi sistema. Pouzdan softver uključuje dodatni, često redudantni (udvojeni) kod koji izvodi neophodne provjere da li se sistem nalazi u vanrednom stanju i omogućava oporavak od greške. Time se smanjuju performanse, potreban je veći diskovni prostor za pohranjivanje takvog softvera i troškovi se eksponencijalno povećavaju. Troškovi validacije kritičnih sistema su izuzetno visoki, što je veća zahtjevana pouzdanost to se više troši na testiranje da li je postignut željeni nivo pouzdanosti (slika gore).

3.3 Pouzdanost i funkcionalnost Dostupnost i funkcionalnost(odnosi se na tačnost, preciznost i pravovremenost) sistema su blisko povezane osobine sistema i obje mogu biti izražene kao numerička vjerovatnoća. Ne možemo očekivati da dostupan sistem bude uvijek funkcionalan i obratno. Neki sistemi imaju visoke zahtjeva za dostupnost, a veoma male za funkcionalnost. Priumjer takvog sistema je telefonska centrala. Korisnici očekuju da svaki put kada podignu slušalicu čuju signal slobodnog biranja tako da sistem ima veoma visoke zahtjeve za dostupnost. Ukoliko se zbog greške u sistemu prekine veza postoje mehanizmi koji brzu resetuju sistem i ponovo uspostavljaju vezu, to se obavlja brzo tako da korisnici možda neće ni primjetiti da je došlo do greške. U ovom sistemu dostupnost je mnogo važnija od funkcionalnosti. Funkcionalnost – vjerovatnoća rada bez greške tokom zadatog vremena u datom okruženju za specifične namjene. Funkcionalnost uveliko zavisi od okruženja u kojem se sistem koristi. Npr. ako testiramo funkcionalnost programa za obradu teksta u nekom uredu, uredski radnici su uglavnom nezainteresovani da istražuju šta im sve pruža dati program i koristiće samo osnovne funkcionalnosti. Za njih je program uglavnom funkcionalan i mala je mogućnost pojavljivanje greške. Ako isti program testiramo na univerzitetu, studenti će istraživati njegove granice i vrlo je moguće da će ga koristiti na nepredviĎen način što može uzrokovati greške. Sistem je funkcionalan ako se ponaša u skladu sa specifikacijom. Glavni uzrok nefunkcionalnosti jeste taj što se specifikacija često ne podudara sa očekivanjima korisnika jer se često ostavlja na odgovornost softverskim inženjerima da odlučuju kako se sistem treba ponašati. A kako oni nisu domenski eksperti dešava se da implementiraju ponašanje sistema koje nije u skladu sa očekivanjima korisnika. Dostupnost – vjerovatnoća da će sistem u bilo kojem trenutku vremena biti operativan i sposoban da pruži zahtjevane usluge. Kada diskutujemo o funkcionalnosti dobro je razjasniti pojmove fault, error i failure.

Pojam Opis

System failure (otkaz)

U jednom trenutku vremena sistem prestaje pružati usluge koje korisnik očekuje

System error (greška)

Nepravilno stanje sistema koje vodi do neočekivanog ponašanja sistema

System fault (defekt)

Karakteristika softverskog sistema koja može dovesto do sistemske greške

Ljudska pogreška

Ljudsko ponašanje koje rezultira uvoĎenjem defekata u sistem

21

Postoje tri komplementarna pristupa za poboljšanje funkcionalnosti: - izbjegavanje defekata-korištenjem developerskih tehnika koje minimiziraju vjerovatnoću

uvoĎenja defekata (npr. izbjegavanje korištenja pokazivača ) - detekcija i uklanjanje defekata- koriste se razne tehnike validacije i verifikacije da bi se

defekti detektovali i uklonili prije korištenja sistema - tolerisanje defekata- koriste se tehnike koje obezbjeĎuju da sistemski defekti neće

rezultirati sistemskim greškama ili obezbjeĎuju da sistemske greške neće prouzrokovati sistemski otkaz.

Slika lijevo: ako neki ulaz uzrokuje nepravilan izlaz koji je povezan sa često korištenim dijelom programa tada će otkazi sistema biti česti. MeĎutim ako je povezan sa rijetko korištenim dijelom koda vrlo je malo vjerovatno da će do otkaza i doći. Slika desno: različiti korisnici koriste sistem na različite načine (sjetite se programa za obradu teksta). Za neke će sistem raditi besprijekorno, dok se drugi susretati sa otkazivanjem sistema. Funkcionalnost najviše ovisi o broju ulaza koji uzrokuju pogrešne izlaze tokom normalne upotrebe većine korisnika. Prema Mills-u (1987.) otklanjanaje 60% poznatih grešaka u softveru povećava funkcionalnot za 3%.

3.4 Sigurnost iznutra Ovo je važan zahtjev u sigurnosno-kritičnim (safety-critical) sistemima. Sistem ne smije nikada ugroziti ljude i okruženje čak i u slučaju otkaza. Primjer sigurnosno –kritičnog sistema jeste sistem za kontrolu i nadgledanje avionskog saobraćaja. Sigurnosno-kritični softver možemo podijeliti u dvije kategorije:

1. Primarni, sigurnosno-kritični softver: ovo je softver koji je ugraĎen u sistem kao kontroler. U slučaju otkaza softvera dolazi i do otkaza hardvera, što rezultuje ugrožavanjem ljudskih života i okruženja.

2. Sekundarni, sigurnosno-kritični softver: ovaj softver može indirektno nanijeti štetu. Primjer su CAE i CAD (Compure aided engineering design) sistemi čija pogreška može dovesti do greške u dizajnu koja dalje vodi ugrožavanju ljudskih života i okruženja.

22

Sistemi koji su funkcionalni(korektni, precizni, pravovremeni) nisu nužno i sigurni. Neki od razloga su:

1. Nepotpuna specifikacija koja ne opisuje ponašanje sistema u nekim kritičnim situacijama. Poteškoće sa zahtjevima su ključni uzrok grešaka u sigurnosno-kritičnim sistemima koje su bile prisutne sve do integracije i sitemskog testiranja (Lutz 1993).

2. Neispravnost hardvera može uzrokovati da se sistem ponaša na nepredviĎen način pa se softver može naći u neočekivanom okruženju. Npr. komponente šalju signale izvan ranga koji softver može prihvatiti.

3. Sistemski operatori mogu generisati ulaze koji pojedinačno nisu neispravni, ali kojiu nekim situacijama vode do neispravnosti sistema.

Terminlogija

Pojam Opis

Nesreća Neplanirani dogaĎaj ili sekvenca dogaĎaja koja rezultira gubitkom ljudskih života ili povredama, oštećenjima imovine ili okruženja

Hazard Stanje oje potencijalno može dovesti do nesreće

Šteta Mjera gubitaka uzrokovanih nesrećom

Ozbiljnost hazarda

Procjena najgore moguće štete koja može biti uzrokovana hazardom

Vjerovatnoća hazarda

Vjerovatnoća da će se desiti dogaĎaj koji će dovesti do hazarda

Rizik Mjera vjerovatnoće da će doći do nesreće u sistemu

Sigurnost iznutra se može povećati na tri načna: 1. Izbjegavanjem hazarda 2. Detekcijom i uklanjanjem hazarda 3. Ograničavanjem štete

3.5 Sigurnost izvana

Sigurnost izvana je osobina sistema koja odražava sposobnost da se sistem zaštiti od napada izvana (i slučajnih i namjernih). Ovo je naročito važan zahtjev za Internet bazirane sisteme (da ne pišem bezveze: virusi, neautorizovan pristup sistemu i neautorizovano mjenjanje podataka). Sigurnost izvana je važna zbog toga što ako neko neautorizovano promjeni sistem on više nije ni funkcionalan, ni siguran iznutra ni dostupan. Terminologija

Pojam Opis

Izloženost Potencijalni gubitak ili šteta u kompjuterskom sistemu

Ranjivost Slabost sistema koja može biti iskorištena za nanošenje štete

Napad Iskorištavanje ranjivosti sistema

Prijetnja Prilika za potencijalno nanošenje štete i gubitka

Kontrola Mjera zaštite koja reducira ranjivost sistema

U nekim sistemima sigurnost izvana je najvažnija dimenzija pouzdanosti (vojska). Tri tipa oštećenja koja mogu biti uzrokoana napadom izvana:

1. Otkazivanje usluge 2. Korumpiranost programa ili podataka 3. Objavljivanje povjerljivih podataka

Sigurnost izvana se može povećati na dva načina:

1. Smanjivanjem ranjivosti 2. Detekcijom napada i neutralizacijom

23

Poglavlje 4 - Softverski procesi Softverski proces je niz aktivnosti koji vodi proizvodnji softvera. Softverski procesi su slozeni i oslanjaju se na ljudske odluke. Zbog toga je pokusaj automatiziranja ogranicen. Neke procesne aktivnosti podrzane su Computer Aided Software Engeneering (CASE) alatima. Fundamentalne aktivnosti koje su zajednicke za sve softverske procese su:

1) Softverska specifikacija-funkcionalnost softvera i ogranicenja na operacije softvera moraju biti definisani

2) Dizajn i implementaacija softvera- mora biti proizveden softver koji ce zadovoljavati 3) Validacija softvera- mora se izvrsiti validacija softvera da bismo bili sigurni da softver

izvrsava ono sto korisnik zeli 4) Evolucija softvera- softver mora evoluirati tako da zadovoljava izmijenjene potrebe

korinika Softverski procesi mogu biti poboljsani standardizacijom, gdje su smanjene razlike u procesima unutar organizacije. Ovo vodi do bolje komunikacije i smanjena vremena potrebnog za obucavanje korisnika i cini automatiziranu podrsku softversim procesima ekonomicnijom.

4.1 Modeli softverskih procesa

Model je apstraktna reprezentacija softverskog procesa. Svaki softverski model predstavlja proces iz razlicite perspektive i obezbjedjuje samo djelimicnu informacju o tom procesu. Genericki procesni modeli su:

1) Waterfall (vodopad) model- fundamentalne aktivnosti procesa(specifikacija, razvoj, validacija i evolucja softvera) predstavlja kao odvojene faze procesa kao sto su: specifikacij zahtjeva, dizajn softvera, implementacija, testiranje,...

2) Evolutivni razvoj- ovaj pristup preplice aktivnosti specifikacije, razvoja i validacije. Prvobitni sistem brzo je razvijen iz apstraktne specifikacije. Ovo se onda doradjuje prema uputama korisnika

3) Softver inzenjering baziran na komponentama (component-based)- ovaj pristup baziran je na postojanju velikog broja komponenti koje mogu biti ponovo koristene. Razvoj sistema fokusira se na integraciju tih komonenti

Takodjer postoje i varijacije ovih modela, kao sto je formalni razvoj sistema, gdje je kreiran formalni matematicki model sistema. Ova model se zatim transformira koristenjem matematickih transformacija koje cuvaju njegovu konzistentnost, u izvrsni kod.

4.1.1 Waterfall (vodopad) model

Vodopadni model baziran je na tome da naredna faza ne pocinje dok prethodna nije zavrsena (u praksi, ove faze se preklapaju i obezbjedjuju informacije jedna drugoj). Rezultat svake faze je jedan ili vise dokumenata koji su odobreni. Faze ovog modela su:

4. Definicija i analiza zahtjeva- servisi, ogranicenja i ciljevi sistema su utvrdjeni konsultujuci se sa korisnikom sistema

5. Dizajn sistema i softvera- razdvaja zahtjeve na hardverski i softverski dio. Uspostavlja arhitekturu softvera

24

6. Implementacija i unit testiranje- u ovoj fazi dizajn softvera je predstavljen kao skup programa ili dijelova programa

7. Iintegracija i testiranje sistema- dijelovi programa su integrisani i cijeli sistem je testiran da bi se potvrdila konzistentnost sa zahtjevima korisnika iz specifikacije

8. Koristenje i odrzavanje- sistem je instaliran i u prakticnoj je upotrebi. Odrzavanje podrazumijeva ispravljanje gresaka koje nisu ranije uocene

Prednosti vodopadnog modela su te sto je svaka faza dokumentirana . Veliki problem je nefleksibilno razdvajanje projekta u razlicite faze.

4.1.2 Evolutivni razvoj Baziran je na ideji razvoja inicijalne implementacije, a zatim ilaganju te implementacije komentarima korisnika da bi se istrazili zahtjevi korisnika i kreirala konacna verzija. Postoje dva tipa ovog modela:

1. Istrazivacki razvoj (exploratory development)- gdje je cilj da se radi sa korinikom radi istrazivanja njihovih zahtjeva i dostavljanja konacne verzije

2. Throwaway prototipitanje- cilj je da se razumiju zahtjevi korisnika i unaprijed razvije bolja definicija zahtjeva za sistem

Postoje dva osnovna problema ovog modela: 1. Proces nije vidljiv- menadzeri trebaju redovna izvjesca da bi mjerili progres. Ako je

sistem razvijen brzo, nije efikasnoproizvoditi dokumentaciju koja se odnosi na svaku pojedinu verziju sistema

2. Sistemi su cesto lose struktuirani- konstantne promjene mogu pokvariti strukturu softvera

I Softver inzenjering baziran na komponentama (component-based)

Ovaj pristup bazira se na velikoj bazi komponenti softvera koje je moguce ponovo koristiti i integracijskim okvirima (framework) za ove komponente. Faze specifikaije zahtjeva i validacije su iste u odnosu na druge procese, medjutim medjufaze se ralikuju:

1. Analiza komponenti- traze se komponente koje ce zadovoljiti specifikaciju 2. Modifikacija zahtjeva- zahtjevi su modifivani u odnosu na informacije o komponentama

koje su pronadjene za softver 3. Dizajn sistema sa ponovnim koristenjem- u ovoj fazi framework sistema je dizajniran ili

je postojeci framework iskoristen. Dizajneri uzimaju u obzir komponente kojse se ponovo koriste i organizuju framewor da i njih obuhvate

4. Razvoj i integracija- softver koji ne moze biti eksterno porizveden se razvija, a integrisu se vec gotove(ponovo koristene)komponente

Prednost je smanjenje kolicine softvera koja mora biti razviijena i takodjer brzi razvj softvera. Nedostaci su sto se mora napraviti kompromis u specifikaciji zahtjeva sto moze dovesti do toga da nisu uzeti u obzir svi zahtjevi korisnika, ali takodjer to sto korisnik nema kontrolu nad komponentama koje se moraju koristiti

25

4.2 Ponavljanje procesa Suština iterativnog procesa je da je specifikacija razvijena je u suradnji s softvera. MeĎutim, ovo se sukobljava sa nabavkom modela mnogih organizacija u kojima je kompletna sistem specifikacija dio ugovora sistema. U inkrementalnom pristupu, ne postoji cjelovita sistem specifikacija do konačnog porasta sistema koji je zahtijevan. To zahtijeva novi oblik ugovora, što veliki kupaci kao što su državne ustanove mogu teško prihvatiti.

4.2.1 Inkrementalna dostava

Umjesto da se sistem odjednom isporuči, razvoj i isporuka Je podijeljena u dijelove(inkremente) i sa svakim novim dijelom (inkrementiranjem) isporuči se dio zahtijevane funkcionalnosti. Korisnikovi zahtjevi su prioritizirani i zahtjevi sa najvecim prioritetom su uključeni u ranim koracima. Jednom kada se identificiraju zahtjevi koji će se izvršavati i isporučiti u prvoj inkrementaciji oni se i razvijaju. Ukoliko se tokom razvoja utvrde novi zahtjevi, oni će se odložiti za sljedeću inkremenaciju, jer izmjena zahtjeva u trenutnoj inkrementaciji nije prihvatljiva. Na ovaj način se korisniku vrlo rano dostavljaju funkcionalni dijelovi sistema, sto daje korisnicima mogucnost da eksperimentisu i bolje uvide daljnje zahtjeve za sistem koji ce im se u sljedecim verzijama dostavljati. Sa svakom novom inkrementacijom (koja se integrise sa stanjem do tada) funkcionalnost sistema je poboljsana.

Inkrementalni proces razvoja ima vise prednosti: 1. Klijenti ne moraju cekati na dostavu cijelog sistema. Prva inkrementacija zadovoljava

njihove najkriticnije potrebe tako da ga mogu odmah poceti koristiti 2. Klijetni mogu koristiti prve verzije kao prototipe i steći iskustvo za daljnje inkrementacije 3. Manji je rizik od neuspjeha cjelokupnog projekta 4. Posto se prvo dostavljaju servisi najveceg prioritteta, i daljnje integracije se s njima

integrisu, neizbjezno je da najvazniji dijelovi budu najvise testirani, sto znaci da je malo vjerovatno da ce softver zakazati na najbitnijim dijelovima sistema

MeĎutim i sa inkrementalnom dostavom postoje problemi. Inkrementi bi trbali biti relativno mali i svaki sa nekom funkcionalnosti. Posto se zahtjevi ne definisu detaljno do momenta implementacije, onda je tesko identificirati odredjene dijelove koji se koriste u svim inkrementacijama. Varijanta takvog jednog inkrementalnog pristupa nazvana ekstremno programiranje je razvijena(Beck, 2000).

26

Bazira se na razvoju i dostavi veomamalih inkrementa funkcionalnosti, korisnicke ukljucenosti u proces, konstantno unapredjenje koda i pair programiranje.

4.2.2 Spiralni razvoj

Procesi se predstavljaju kao spirala. Svaka petlja u spirali predstavlja fazu i podijeljena je na 4 sektora: •Postavke cilja - Specifični ciljevi za faze su identifikovani. •Procjena i smanjenje rizika - Rizici se procjenjuju i odredjuju aktivnosti za smanjenje kljucnih rizika •Razvoj i validacija - Razvojni model za sistem se bira i to može biti bilo koji od generičkih modela. •Planiranje - Projekat se pregleda i planira se naredna faza spirale. Glavna razlika izmedju spiralnog modela i i drugog softverskog procesa je eksplicitno prepoznavanje rizika u spiralnom modelu.

4.3 Aktivnosti procesa Četiri bazna procesa specifikacije, razvoja, validacije i unapreĎenja se različito organizuju u različitim procesima. U waterfall modelu, organizovani su u sekvenci. Sve zavisi od tipa softvera, ljudi kako će biti predstvaljeni.

4.3.1 Specifikacija softvera

Specifikacija softvera jeste proces razumijevanja i definisanja koje servise zahtijeva sistem i identificiranje ogranicenja na rad i razvoj sistema. Ovo je kriticna faza obzirom da greske mogu dovesti do kasnijih problema u dizajnu i implementaciji. Četiri su glavne faze u specifikaciji softvera:

1) Studija izvodljivosti – rezultat treba obavijestiti o odluci o nastavku detaljnihjih analiza da li nastaviti, ili ostati pri trenutnom softveru i hardveru

2) Zahtjevi pronalazenja i analize – moze ukljucivati razvoj prototipa 3) Specifikacija zahtjeva – dokument koji definise set zahtjeva ( korisnicki i sistemski

zahtjevi) 4) Validacija zahtjeva – provjera zahtjeva, ovdje se greske otkrivaju

27

4.3.2 Softver dizajn i implementacija

Proces konvertovanja specifikacije sistema u izvršni sistem. Dizajn softver - projektovanje strukture softvera koja ostvaruje ono sto je u specifikaciji; Implementacija softvera -prevod ove strukture u izvršni program; Aktivnosti dizajna i implementacije su tijesno povezani.

Aktivnosti procesa dizajna su sljedeće: - Arhitekturalni dizajn - Abstract specifikacija - Interfejs dizajn - Component dizajn - Dizajn stukture podataka - Algorithm dizajn

Suprotan pristup ovome jesu struktuirane metode za dizajn koje se oslanjaju na graficke modele sistema i u vecini slucajeva kod se automatski generise iz tih metoda. Struktuirane metode ukljucuju dizajn proces model, zabiljeske o dizajnu, formate izvjestaja, pravila i vodic za dizajn. Struktuirane metode mogu podrzati neke ili sve od sljedecih modela sistema: modele sekvenci, modele prelaznih stanja (trigeri), modele protoka podataka.. CASE alati mogu se koristiti za generisanje programskog skeleta iz dizajna. To ukljucuje kod koji ce definisati i implementirati interfejs i programer treba dodati samo neke detalje za svaku komponentu. Obicno, programeri testiraju kod nakon sto ga razviju. To cesto otkriva defekte koji se moraju otkloniti iz programa. Toi se zove debagiranje. Testiranje defekta i debagiranje su razliciti procesi. Testiranje ustanovljava postojanje defekata, a debagiranje njihovo lociranje i ispravljanje.

4.3.3 Validacija softvera Validacija softvera ili validacija i verifikacija ima namjeru da pokaze da se sistem slaze sa specifikacijom i da zadovoljava ocekivanja klijenta koji kupuje taj sistem. Ukljucuje provjeru procesa, testiranje. Testiraju se komponente sistema, integrisani sistem a zatim se sistem testira sa korisnikovim podacima. Faze proces atestiranja su sljedeće:

1) Unit testiranje(komponenti) – individualne komponente se testiraju 2) Sistem testiranje – komponente se integrisu, ovdje se uglavnom pronalaze greske

prilikom interakcije komponenti i problemi sa interfejsom. Takodje testiraju se funkcionalni i nefunkcionalni zahtjevi sistema

3) Prihvatljivo testiranje (acceptance) – finalna faza u procesu testiranja prije nego se sistem prihvati za upotrebu. Ovdje se koriste pravi podaci koji mogu uzrokovati gresku jer se oni ipak razlikuju od testnih – Ovo testiranje se jos naziva alfa testiranje

28

4.3.4 Unapredjenje softvera

Fleksibilnost softverskih sistema jedan je od glavnih razloga zasto se softver inkorporise u kompleksne sisteme. Dok kod hardvera, odluke za izmjenu dizajna mnogo kostaju, kod softvera se one ipak mogu prihvatiti. Historijski gledajuci. Uvijek je postojala razlika izmedju razvoja softvera i njegovog unapredjenja (odrzavanja), iako su troskovi odrzavanja nkead dosta skuplji od samog razvoja. Sada, razlika izmedju ta dva pojma postaje zanemariva. Samo nekolicina danasnjih softvera su novi sistemi, i mnogo je razumnije gledati na razvoj i odrzavanje sistema kao jednu cjelinu.

4.4 Rational Unified Process-RUP

RUP je moderni genericki procesni model. RUP je opisan u 3 perspektive: 1) Dinamicka perspektiva- prikazuje veremenski uslovljene faze modela 2) Staticka perspektiva - prikazuje aktivnosti procesa koje su predodredjene 3) Perspektiva prakse- predlaze dobre prakse koje bi trebale biti koristene u toku procesa

Faze RUP-a su: 1) Pocetak- cilj je uspostavljanje biznis case-a za sistem. Treba identificirati sve eksterne

entitete(ljude i sisteme) i interakcije izmedju sistema i njih 2) Elaboracija- cilj je razumijevanje projekta, uspostaviti framework arhitekture, razviti plan

i identificirati rizike 3) Konstrukcija- dizajn, programiranje i testiranje 4) Prijelaz- premjestanje sistema iz okruzenja u kojem je razvijen u korisnicko okruzenje i

pokretanje sistema u stvarnom okruzenju Perspektiva prakse opisuje dobre prakse u softver inzenjeringu koje su preporucene u razoju sistema. 6 fundamentalnih najboljih praksi je preporuceno:

1) Razviti softver iterativno 2) Upravljati zahtjevima korisnika 3) Koristiti component-based arhitekture 4) Modelirati softver vizuelno 5) Provjeriti kvalitetu softvera 6) Kontrolisati promjene softvera

29

4.5 Computer Aided Software Engeneering (CASE)

CASE se odnosi na softvere koristene za podrsku softverskim procesima kao sto su inzenjering zahtjeva, dizajn, razvoj programa i testiranje. CASE alati stoga ukljucuju dizajn editore, rjecnike podataka, kompajlere, debagere, alate za izgradnju sistema... CASE alati podrzavaju softverske procese automatiziranjem nekih aktivnosti. Napredovanje zahvaljujuci CASE alatima limitirano je sa dva faktora:

1) Softver inzenjering uslovljen je kreativnoscu 2) To je timska aktivnost, CASE alate ne pruzaju puno podrske za timski rad

4.5.1 CASE klasifikacija

CASE alate moze posmatrati iz tri perspektive:

1) Funkcionalna perspektiva- CASE alati lasificirani prema njihovoj specificnoj funkciji 2) Procesna perspektiva- klasificirani prema aktivnostima koj podrzavaju 3) Integraacijska prespektiva- klasificirani prema tome kako su organizirani u intergrisane

jedinice koje pruzaju podrsku za procesne aktivnosti Jedna moguca klasifikacija je prema sirini podrske koju pruza CASE tehnologija:

- Alati- podrzavaju individualne procesne zadatke - Workbenches- podrzavaju fazu procesa ili aktivnost kao sto je dizajn, specifikacija... - Environments (okoline)- podrzavaju cijeli (ili barem veliki dio) softverskog procesa

Poglavlje 5 – Projekt menadžment

Softverski projekt menadžment je veoma važan dio softverskog inžinjeringa. Dobar projekt menadžment ne garantuje da će projekat uspjeti, ali sa lošim projekt menadžmentom projekat nema šanse da uspije, i ako ima sjajan razvojni proces. Softver projekt menadžeri su zaduženi za planiranje projekta, raspodjelu poslova i mnoge druge aktivnosti unutar projekta. Projekt menadžment je esencijalna oblast softver inžinjeringa, jer je softver uglavnom objekat različitih ograničenja – od ograničenja budžeta do vremenskih i ograničenja na rasporeĎivanje poslova unutar projekta. Softver projekt menadžeri rade iste stvari kao projekt menadžeri u drugim inžinjerskim disciplinama. MeĎutim, softver ima neke fundamentalne razlike od ostalih inžinjerskih disciplina:

- Softver je nevidljiv, pa je samim tim puno teže pratiti napredak i promjene u projektu (morate se osloniti na dokumentaciju i razgovore na ravojnim timom), nego kod recimo pravljenja zgrade (gdje je napredak i faza u kojoj se radi očita),

- Nema standardnog procesa razvoja softvera (nema šablona po kojem se softver razvija i razvojni procesi drastično variraju od organizacije do organizacije što još više otežava razvoj),

- Veliki softverski projekti su često projekti kakvi se ranije nisu radili, pa se ne mogu primijeniti neka ranija iskustva.

U ovom poglavlju će se razmotriti 3 aktivnosti unutar projekt menadžmenta: planiranje, rasporeĎivanje projekta i upravljanje rizikom.

30

Aktivnosti menadžmenta

Ne postoji standardni opis radnog mjesta jednog projekt menadžera. On varira od organizacije do organizacije. Uglavnom, projekt menadžeri su u nekom stepenu zaduženi za neke (ili sve) od sljedećih aktivnosti:

- Pisanje prijedloga, - Planiranje i raspodjela projekta, - Finansijske estimacije, - Nadgledanje projekta, - Odabir osoblja za pojedine poslove i njihova evaluacija, - Pisanje i prezentiranje izvještaja

Prva (i možda najvažnija) faza je pisanje prijedloga. Pisanje prijedloga je ustvari apliciranje na konkurs za razvoj nekog sistema. Ovi prijedlozi treba da sadrže ciljeve projekta, ciljeve i glavne karakteristike organizacije i da daju odgovor na pitanje zašto bi baš tu ponudu klijent trebao prihvatiti. Ne postoji šablon za pisanje ovih prijedloga. Iskustvo je presudno u ovom poslu. Planiranje projekta se svodi na odreĎivanje prekretnica (milestones) i „isporučenica“ (deliverables) unutrar projekta. Prekretnica predstavlja završetak jedne podfaze/faze unutar projekta koja rezultuje nekim izlazom, ali se taj izlaz ne isporučuje (demonstrira) klijentu. Npr. prekretnica može biti završetak use-case dijagrama, nakon kojeg tim ima sastanak na kojem se raspodjeljuje posao u daljnjem dizajnu. Isporučenica je takoĎer završetak jedne faze u projektu, ali se on isporučuje (demonstrira) korisniku. U ovu fazu su djelimično uključene i finansijske estimacije (proračun sredstava potrebnih za pojedine faze projekta i za cjelokupan projekat). Nadgledanje projekta je faza koja se kontinuirano obavlja kroz čitavo vrijeme trajanja projekta. Sve organizacije imaju neki formalni način nadgledanja (članovi tima pišu izvještaje i sl), ali dobar projekt menadžer vrši ovo nadgledanje i u razgovoru sa članovima tima. Odabir osoblja je faza u kojom biramo ljude na pojedine pozicije unutar projekta, prema njihovim sposobnostima i sklonostima. Idealno bi bilo da imamo samo iskusne ljude. MeĎutim, to je nemoguće iz sljedećih razloga:

- oni su zauzeti (nemoguće je angažovati ljude izvana, a ljudi unutar firme su na nekom drugom projektu),

- njihovo angažovanje se ne uklapa u cijene projekta (dosta su skuplji od „amatera“), - sama organizacija angažuje neiskusne zaposlenike na projektima da oni uče i stiču

iskustvo. Ipak, poželjno bi bilo za svaki projekat imati bar jednog iskusnog člana tima, jer će se inače ponavljati neke vrlo jednostavne greške, i tako projekat usporavati. Zadnja aktivnost za koju su projekt menadžeri odgovorni je pisanje izvještaja. Na kraju neke faze projekta, treba napisati kratke i koncizne izvještaje koje trebamo biti u stanju prezentovati klijentu. Ako ste projekt menadžer, od vas se očekuje dobra pisana i usmena komunikacija.

Planiranje projekta

Planiranje projekta je jedna od aktivnosti koje najviše utiču na kvalitet projekta, odnosno projekt menadžmenta. Projekt menadžeri moraju predvidjeti sve probleme i poteškoće koje se mogu javiti i ponuditi neka rješenja za njih. Ovo je kontinuiran proces koji se završava kada i sam projekat. Postoji više vrsta projektnih planova: plan kvalietete (opisuje standarde kvalitet

31

koje proizvod mora zadovoljiti), plan validacije (opisuje pristup i resurse koji se koriste za validaciju sistema), konfiguracijski plan, plan održavanja (planira održavanje sistema, nakon njegovog puštanja u produkciju), plan rapodjele osoblja. Projekti plan se mijenja u toku projekta kako više informacija postaje dostupno. Na početku aktivnosti planiranja, definišu se ograničenja koja projekat mora zadovoljavati (budžet, rokovi...). U skladu sa ovim , odreĎuju se parametri projekta: veličina, struktura itd. Zatim se defuniraju inicijalne prekretnicei isporučenice unutar projekta. Proces zatim ulazi u petlju, u kojoj se vrši raspodjela poslova i dodjela aktivnosti svakom poslu i rad počinje. Nakon 2-3 sedmice ponovo se ulazi u petlju (nova iteracija), gdje se sve ovo ponavlja. Ukoliko doĎe do nekog problema, to može uzrokovati i privremenu obustavu projekta, dok se ne naĎe rješenje. Na početku projekta nikada ne treba pretpostaviti da će sve ići kako treba, jer nikada nije tako. „Početno rapoloženje bi trebalo biti pesimistično, a ne optimistično“.

Projektni plan

Projektni plan je dokument u kojem se opisuju resursi dodijeljeni projektu, struktura projekta i raporeĎivanje unutar projekta. U nekim organizacijama projektni plan je jedan i on sadrži sve planove opisane u prethodnom poglavlju. Drugi pristup je da se pravi samo projektni plan za development i da on sadrži reference na pojedine planove koji su zasebni dokumenti. Poglavlja unutar ovog drugog tipa projektnog plana su:

1) uvod – opis ciljeva i ograničenja, 2) organizacija projekta – opis organizacije razvojnog tima, uloga ljudi u timu i sl, 3) analiza rizika – identifikacija rizika i mjera za njihovo suzbijanje. Ovo se detaljnije opisuje

u jednom od kasnijih poglavlja, 4) zahtjevi za hardverskie i softverske resurse – opis hardvera i softvera (OS) na kojem će

se softver izvršavati, 5) struktura projekta – identifikuju se prekretnice i isporučenice unutar projekta, 6) raporeĎivanje posla – opisuje zavisnosti meĎu aktivnostima u razvojnom procesu i

članove tima koji su zaduženi za pojedine aktivnosti, 7) mehanizam izvještavanja i nadgledanje – zna se šta je.

Neke od ovih aktivnosti se mijenjaju često, dok se neke stabilnije. Zato bi bilo dobro dokument organizovati u odvojene sekcije, kako bi se lakše mogla izvršiti promjena pojednih poglavlja (7 sekcija za ovih 7 poglavlja). Naravno, dokument ne mora uvijek sadržavati sva ova poglavlja, a nekada može sadržavati i neka druga poglavlja. Izgled i tačan sadržaj projektnog plana zavisi od vrste projekta i od organizacije.

Prekretnice i isporučenice

Menadžerima su potrebne informacije da bi obavljali svoj posao. S obzirom na to da je sofver nevidljiv proizvod, jedini način da se dobiju informacije o preogresu unutar projekta je pisanje izvještaja. U skladu s tim, u projektnom planu se definišu isporučenice i prekretnice. Prekretnica je završna tačka neke od aktivnosti u procesu razvoja softvera, koja se ne pokazuje klijentu. Ona se može prezentovati menadžmentu, koji je zadužen za budžet unutar naše organizacije i koji nam neće dati pare tek tako. Ove prekretnice bi trebalo biti kratke, koncizne i imati prikladna imena. Primjer lošeg (katastrofalnog) imenovanja prekretnice je „80% kodiranja završeno“. Isporučenica je završna tačka neke od aktivnosti unutar procesa razvoja softvera

32

koja se pokazuje klijentu. Npr. isporučenica može biti završetak faze specifikacije ili dizajna. I prekretnice i isporučenica imaju neki izlazni dokument. Svaka isporučenica je prekretnica, ali svaka prekretnica nije isporučenica. Na slici je dat primjer prekretnica i isporučenica:

Rapoređivanje projekta

RaporeĎivanje projekta je jedan od najtežih zadataka projekt menadžera. Menadžeri u ovoj aktivnosti odreĎuju resurse i vrijeme potrebne za obavljanje odreĎenih aktivnosti unutar razvojnog procesa. RaporeĎivanje je teže ako projekat spada u vrstu projekata koji ranije nisu raĎeni. Kod ovih projekata, vrlo je vjerovatno da će se koristii metode dizajna i jezici za implementaciju koji nisu ranije korišteni, što može donijeti dodatne probleme i zahtijevati dodatno vrijeme i resurse. Dodatni problemi mogu nastati i ako je projekat tehnički napredan (zahtjevan). U ovakvim slučajevima procjene su uglavnom previše optimistične. Aktivnosti treba rapodijeliti optimalno, s obzirom na utrošak novca, vremena i ostalih resursa. Neke aktivnosti se mogu obavljati i paraleno, sve u cilju optimalnog iskorištenja radne snage. Aktivnosti unutar razvojnog procesa po pravilu traju oko sedmicu. Maksimalno trajanje aktivnosti ne bi smjelo biti veće od 8-10 sedmica. Ako se desi da aktivnost traje duže, treba je razbiti na više podaktivnosti. U proračunu vremena trajanja aktivnosti treba imati na umu sve moguće probleme. Član tima može biti bolestan ili dati otkaz, hardver može praviti probleme... Osim vremena, potrebno je predvidjeti i resurse (kao što su ljudi, prostor na disku, mrežna oprema itd) za svaku aktivnost. Sommerille predlaže da se inicijalnom vremenu procijenjenom za trajanje aktivnosti doda 30% za probleme koje se pretpostavlja da bi se mogli desiti i 20% za probleme koje je projekt menadžer previdio, a koji bi se mogli pojaviti. Na slici su dati koraci unutar rasporeĎivanje projekta:

Dijagrami i mreža aktivnosti

Dijagrami i mreža aktivnosti su standaradne grafičke notacije za prikaz raporeĎivanja projekta. Dijagrami aktivnosti prikazuju vrijeme početka i vrijeme završetka aktivnosti, kao i osobu koja je odgovorna za tu aktivnost. Mreže aktivnosti prikazuju zavisnosti izmeĎu aktivnosti, sa datumima

33

početka i završetka svake aktivnosti. Ove grafičke predstave se mogu generisati automatski iz baze podataka projekta, koristeći alate za projekt menadžment. Mreža aktivnosti pokazuje zavisnosti izmeĎu aktivnosti. Zahvaljujući ovome, može se vidjeti koje aktivnosti se mogu izvoditi u paraleli, a koje u tačno definisanim sekvencama. Na slici je dat primjer jedne mreže aktivnosti:

Početni i krajnji datumi aktivnosti su prikazani u zaobljenim pravougaonicima, a aktivnosti u običnim pavougaonicima. Vrijeme početka i kraja aktivnosti može biti prikazano u drugačijem obliku (npr. kao broj, tada je početak projekta 0). Ova vremena početka i završetka aktivnosti su uglavnom vezana za datume prekretnica u projektu. Na projektu je označena i sekvenca aktivnosti koja predstavlja kritični put. To je najkraći mogući put kroz mrežu aktivnosti, od početka do kraja projekta. Aktivnosti koje su na ovom putu ne mogu se produžiti, dok se druge aktivnosti mogu produžiti za neki period (kod njih postoji vremenska razlika). Početne procjene vremena potrebnog za pojedine aktivnosti su neizbježno pogrešne. Kako projekat raste i više informacija postaje dostupno, potrebno je vršiti promjene u procjeni vremena za obavljanje pojedinih aktivnosti. Još jedan način za prikaz aktivnosti i njihovih zavisnosti je Gant dijagram, koji je dat na slici:

34

Dakle, vrijeme je prikazano po x-osi, kao i trajanja aktivnosti. Vidi se koje aktivnosti se mogi izvršavati paralelno, a koje zavise od drugih. Za svaku aktivnost koja nije na kritičnom putu postoje 2 pravougaonika. Desni pravougaonik je maksimalno vrijeme za koje se ova aktivnost može produžiti, a da se ne produži čitav projekat. Još jedna važna stavka u rasporeĎivanju projekta je rasporeĎivanje osoblja. Članovi tima mogu biti bolesni, na odmoru, na službenom putu u vrijeme rada na projektu. Zbog ovih razloga velike firme nerijetko angažuju vanjske stručnjake, koji rade samo jedan (ili nekoliko) zadataka. Angažovanje ovih stručnjaka može biti dodatni problem za prjekt menadžera u rasporeĎivanju projekta.

Upravljanje rizikom

Upravljanje rizikom uključuje predviĎanje rizika vezanih za raporeĎivanje projekta i kvalitet proizvoda i poduzimanje mjera za njihovo suzbijanje (Hall, 1998). Efektivnim rizik menadžmentom mogu se izbjeći mnogi problemi u vezi sa planiranjem pojekta i razvojnim procesom. Ti problemi bi u suprotnom mogli uticati na probijanje rokova, proizvod koji ne zadovoljava standarde o kvaliteti, probijanje budžeta itd. Postoje 3 vrste rizika:

- projektni rizik, rizik vezan za sam projekat, raporeĎivanje projekta i resurse na projektu, - rizikom proizvoda, rizik da proizvod ne zadovolji standarde o kvaliteti ili ne bude uopšte

iskoristiv, - poslovni rizik, rizik vezan za organizaciju koja razvija softver, npr. uvoĎenje nove

tehnologije. Ove 3 vrste rizika se preklapaju. Ako iskusan programer napusti firmu, to može uticati na probijanje roka za razvoj softvera, što je projektni rizik. Zamjena može biti ne tako kvalitetna ili se ne uklapa dobro u tim, pa to može uticati na nastajanje velikog broja grešaka u programiranju, što je rizik proizvoda. TakoĎer, firma se u narednim konkursima ne može više pozivati na iskusnog programera, koji bi možda bio glavni razlog zašto bi dobili neki posao, što je poslovni rizik. Mogući rizici variraju od projekta do projekta, ali postoje i neki univerzalni rizici, koji se pojavljuju skoro kod svakog projekta. Upravljanje rizikom je iterativni proces koji se sastoji od 4 faze:

- identifikacija rizika, identificiraju se rizici i odreĎuje se njihov tip (3 gore opisana tipa), - analiza rizika, odreĎivanje vjerovatnoće pojave rizika i posljedica koje on nosi ako se

pojavi, - planiranje rizika, predlaganje i analiza mjera za otklanjanje identifikovanih rizika, - nadgledanje rizika, promjena plana upravljanja rizikom, kako se projekat razvija i više

inforamcija postaje dostpuno. -

Upravljanje rizikom bi trebala biti posebna sekcija u projektnom planu, ili bi trebao postojati poseban dokument – plan upravljanja rizikom.

Identifikacija rizika Ovo je prva faza upravljanja rizikom. U ovoj fazi se identifikuju rizici koji imaju neku vjerovatnoću pojavljivanja. Rizici za koje postoji gotovo nikakva šansa da se pojave najčešće se odbacuju već u ovoj fazi. Način identifikacije može biti različit, od timskog rada na identifikaciji

35

rizika, do jednostane identifikacije bazirane na iskustvu projekt menadžera. Može se koristiti i lista najčešćih rizika. Lista od 6 vrsta rizika koji se mogu pojaviti:

1) tehnološki rizik, vezan za tehnologije koje se koriste u razvojnom procesu, 2) ljudski rizik, vezan za članove tima i njihove probleme, 3) organizacijski rizik, vezan za organizacijsko razvojno okruženje softvera, 4) rizik alata, vezan za CASE i druge alata koji se koriste u dizajnu ili nekoj 2.fazi razvoja, 5) rizik zahtjeva, vezan za mogućnost loše specifikacije ili promjene zahtjeva od strane

korisnika, 6) estimacijski rizik, vezan za loše procjene ljudskih i drugih resursa koji mogu dovesti do

problema u nekoj fazi projekta.

Analiza rizika U ovoj fazi vrši se analiza i klasifikaciji rizika identifikovanih u prethodnoj fazi. Svakom riziku se dodjeljuje vjerovatnoća njegovog pojavljivanja i ozbiljnost posljedica koje donosi ako se pojavi. Vjerovatnoća se uglavnom izražava u metrikama: veoma mala(<10%), mala (10-25%), srednja (25-50%), velika(50-75%), veoma velika (>75%). Posljedice koje rizik ostavoi ako se pojavi mogu biti: katastrofalne, ozbiljne, tolerantne ili zanemarive. Nakon analize, popunjava se tabela u kojoj se nalaze rizici sa dodijeljenom vjerovatnoćom pojave i ozbiljnošću posljedica. Boehm (Boehm, 1988) u svojoj knjizi preporučuje da treba napraviti listu „top-10“ rizika i samo se njima baviti. MeĎutim, to se ne prihvata kao ispravan pristup, jer broj rizika zavisi od konkretne situacije (organizacijskoh okruženja, vrste softvera koji se razvija i sl).

Planiranje rizika U ovoj fazi se vrši analiza i predviĎanje mjera za suzbijanje rizika. Ni u ovoj, kao ni u prethodnim fazama, ne postoji šablon da se stvar odradi. Sve je bazirano na vlastitim procjenama i iskustvu. Zbog toga su najbolji ljudi za upravljanjem rizikom iskusni projekt menadžeri. Postoje 3 strategije:

- izbjegavanje rizika, u ovoj strategiji pokušavaju se poduzeti sve mjere da se rizik ne ostvari,

- minimiziranje štete nastale rizikom, čini se sve da se šteta ako se rizik pojavi što više umanji,

- strategije „spremni na sve“, opisuju se akcije koje se provode u slučaju da se desi najgore, tj. da se rizik ostvari.

Monitoring rizika Ovo je kontinuirana faza, u kojoj se poreĎenem trenutnog stanja na projektu i predviĎenog stanje identifikuju novi rizici, te provodi njihova faza i planiranje. Jedan od načina (ali svakako ne i jedini, jer nije uvijek moguć) za monitoring rizika je i direktna observacija. Dakle, ovo je faza gdje projekt menadžer kroz prijem više informacija o projektu mijenja plan upravljanja rizikom.

36

Poglavlje 6 - Softverski zahtjevi Zahtjevi za sistem su opisi servisa koje sistem nudi, kao i operativnih ograničenja. Oni odražavaju potrebu korisnika za sistemom koji pomaže u rješavanju nekog problema. Proces nalaženja, analize, dokumentacije i provjeravanja ovih servisa i ograničenja se zove inženjering zahtjeva. Korisnički zahtjevi su izjave, u prirodnom jeziku + dijagrami, o tome koje servise sistem treba da nudi i koja ograničenja treba da ima. Sistemski zahtjevi se detaljno odnose na sistemske funkcije, servise i operativna ograničenja. Dokumenat sistemskih zahtjeva treba biti precizan. Treba definisati tačno šta treba biti implementirano. Ovi zahtjevi se tebaju pisati sa različitim detaljima zbog različitog tipa korisnika koji ih mogu koristiti na različite načine. Sljedeća slika to pokazuje.

Slika : Različiti „čitaoci“ različitih tipova zahtjeva

6.1 Funkcionalni i nefunkcionalni zahtjevi 1) Funkcionalni zahtjevi : Su izjave o servisima koje sistem treba obezbjediti, kako sistem

treba reagovati na odreĎene ulaze i kako se sistem treba ponašati u odreĎenim situacijama. U nekim slučajevima, funkcionalni zahtjevi mogu takoĎer specificirati šta sistem ne treba raditi.

2) Nefunkcionalni zahtjevi : Ovo su ograničenja na servise i funkcije ponuĎene od strane sistema. Uključuju vremenska ograničenja, ograničenja na razvojni proces i standarde. Često se odnose na sistem u cjelini. Obično se ne odnose samo na individualne funkcije i servise sistema.

3) Zahtjevi domene : Zahtjevi vezani za domenu aplikacije sistema koji oslikavaju karakteristike i ograničenja te domene. Mogu biti funkcionalni i nefunkcionalni.

37

6.1.1 Funkcionalni zahtjevi

Opisuju šta sistem treba raditi. Oni zavise od tipa softvera koji se razvija, očekivanih korisnika softvera i generalnog pristupa organizacije pri pisanju zahtjeva. Nepreciznost u pisanju zahtjeva je rezultat različitih problema softverskog inženjeringa. Prirodno je da developer sistema tumači dvosmisleni zahtjev u smjeru pojednostavljenja implementacije. Često to nije ono što klijent želi. U globalu, funkcionalni zahtjevi trebaju biti i potpuni i doslijedni. Potpuni znači da su definisani svi servisi koje klijent želi. Doslijedni znači da zahtjevi ne trebaju imati kontradiktorne definicije.

6.1.2 Nefunkcionalni zathjevi Nefunkcionalni zahtjevi nisu direktno vezani za specifične funkcije koje nudi sistem. Oni se mogu odnositi na izlazna sistemska svojstva kao npr. na pouzdanost, vrijeme odziva i zauzimanje skladišta. Alternativno, mogu odreĎivati i ograničenja sistema kao npr. sposobnost U/I ureĎaja i prikazivanje podataka preko sistemskih interfejsa. Nefunkcionalni zahtjevi su rijetko vezani za specifične osobine sistema. Češće su vezani za izlazna svojstva sistema. Zbog toga, mogu specificirati performanse sistema, sigurnost, dostupnost, i druga izlazna svojstva. Ovo znači da su oni često bitniji od individualnih funkcionalnih zahtjeva. Korisnik sistema može naći način da zaobiĎe neku sistemsku funkciju koja nije potpuno uraĎena po njihovoj potrebi, MeĎutim, ako sistem ne zadovoljava nefunkcionalne zahtjeve, to može značiti da je cio sistem nefunkcionalan.

Slika : Tipovi nefunkcionalnih zahtjeva

Tipovi nefunkcionalnih zahtjeva su : 1) Zahtjevi proizvoda. Oni specificiratju ponašanje proizvoda.

38

2) Organizacioni zahtjevi. Oni su izvedeni iz politika i procedura iz organizacije korisnika i developera.

3) Spoljašnji zahtjevi. Pokrivaju sve zahtjeve izvedene iz spoljašnjih faktora sistema i razvojnog procesa.

Čest problem sa nefunkcionalnim zahtjevima je to da ih je teško provjeriti. Kada god je to moguće, treba pisati nefunkcionalne zahtjeve količinski, kako bi bilo moguće objektivno testiranje. Sljedeća slika pokazuje nekoliko mogućih mjera koje treba koristiti da bi se specificirala svojsta nefunkcionalnih zahtjeva.

Slika : Mjere za specificiranje nefunkcionalnih zahtjeva

U praksi, ipak, često je nemoguće za korisnike da prevedu svoje ciljeve u dovoljno precizne zahtjeve. Npr. kod sposobnosti snadbevanja ne postoje mjere (metrike) koje mogu biti korištene. Zbog toga, dokumenti zahtjeva često uključuju izjave ciljeva uz zahtjeve. Ove izjave mogu biti korisne za programere. Nefunkcionalni zahtjevi često dolaze u konflikt sa drugim funkcionalnim ili nefunkcionalnim zahtjevima. Jako je bitno da se uspješno razlikuju funkcionalni od nefunkcionalnih zahtjeva. Ovo je u praksi često teško. Sa druge strane, ako su pisani potpuno odvojeno, često je teško naći povezanost izmeĎu njih. Nefunkcionalni zahtjevi kao što su sigurnost i bezbjednost (security and safety) su posebno bitni za kritične sisteme.

39

6.1.3 Zahtjevi domene

Su izvedeni iz domene aplikacije sistema prije nego iz specifične potrebe korisnika sistema. Oni obično sadrže specijalnu terminologiju domene. Često je teško za softverske inženjere da povežu ove zahtjeve sa drugim tipovima zahtjeva. Zahtjevi domene su bitni jer oni često odražavaju osnove domene aplikacije. Ako ovi zahtjevi nisu zadovoljeni, može birti nemoguće da sistem radi zadovoljavajuće. Najveći problem ovih zahtjeva je to da su pisan jezikom domene aplikacije, i često je teško za softverske inženjere da ih razumeju.

6.2 Korisnički zahtjevi

Trebaju opisati funkcionalne i nefunkcionalne zahtjeve da bi bili razumljivi za korisnike sistema koji nemaju detaljno tehničko znanje. Trebaju jedino opisati spoljašnje ponašanje sistema i trebaju izbjegavati karakteristike dizajna sistema. Ne trebaju se koristiti softverski žargoni, strukturne ili formalne oznake, ili opisivati zahtjevi kroz opis implementacije sistema. Ovi zahtjevi se trebaju pisati običnim jezikom, sa prostim tabelama i formama kao i dijagramima. Ipak, razni problemi se mogu javiti kada su zahtjevi pisani običnim jezikom :

1) Manjak jasnoće. 2) Zbunjenost zahtjeva. 3) Spajanje zahtjeva. Različiti zahtjevi se mogu izraziti kao jedinstven zahtjev.

Dobra je praksa razdvojiti korisničke zahtjeve od detaljnijih sistemskih zahtjeva u dokumentu zahtjeva. Korisnički zahtjevi koji imaju previše informacija ograničavaju slobodu developera da pruži neka inovativna rješenja korisničkih problema i teški su za razumjevanje. Oni jednostavno trebaju biti fokusirani na glavne objekte. Da bi se izbjeglo nerazumjevanje kada se pišu korisnički zahtjevi, treba se pridržavati sljedećih pravila :

1) Treba izmisliti standardn format i pobrinuti se da sve definicije zahtjeva budu u tom formatu. Ovo omogućava lakšu provjeru zahtjeva i smanjuje propuste.

2) Treba doslijedno koristiti jezik. Treba razlikovati obavezne(shall) i željene(should) zahtjeve.

3) Treba koristiti isticanje teksta (bold, italic ili u boju) da bi se izdvojili bitni dijelovi zahtjeva.

4) Treba izbjegavati računarski žargon, koliko je to moguće.

6.3 Sistemski zahtjevi

Su proširena verzija korisničkih zahtjeva koja se koristi od strane softverskih inženjera kao početna tačka dizajna sistema. Dodaju detalje i objašnjavaju kako korisnički zahtjevi trebaju biti obezbjeĎeni od strane sistema. Idealno, ovi zahtjevi trebaju opisati spoljašnje ponašanje sistema i operativna ograničenja. Ne trebaju se baviti sa tim kako sistem treba biti dizajniran i implementiran. Ipak, u praksi, nemoguće je isključiti sve informacije o dizajnu. Postoji nekoliko razloga za ovo :

1) Možda će se trebati dizajnirati početna arhitektura sistema da bi se pomoglo pravljenje specifikacije zahtjeva.

2) U većini slučajeva, sistemi moraju saraĎivati sa drugim postojećim sistemima.

40

3) Korištenje specifičnih arhitektura da bi se zadovoljili nefunkcionalni zahtjevi može biti potrebno.

Obični jezik se često koristi za pisanje sistemskih zahtjeva, isto kao i korisničkih zahtjeva. Ipak, često može biti zbunjujući, jer su ovi zahtjevi detaljniji od korisničkih.

6.3.1 Struktuiran jezik specifikacije Je način pisanja sistemskih zahtjeva gdje je sloboda pisca ograničena, i svi zahtjevi su pisani na standardni način. Prednost ovog pristupa je da održava većinu izražajnosti i razumljivosti prirodnog jezika ali i osigurava da je neki stepen skladnosti prisutan. Oni ograničavaju terminologiju koja se može koristiti i koriste šablone. Kada se koristi standard za specifikaciju funkcionalnih zahtjeva, sljedeće informacije se trebaju uključiti :

1) Opis funkcije ili entiteta koji je specificiran. 2) Opic ulaza i odakle oni dolaze. 3) Opis izlaza i gdje oni idu. 4) Naznaku onoga što drugi entiteti koriste. 5) Opis akcije koja će biti preduzeta. 6) Ako je funkcionalni pristup korišten, početni uslov koji mora biti zadovoljen prije nego

što se funkcija pozove, i uslov koji treba biti zadovoljen kada se funkcija izvrši. 7) Opis sporednih efekata operacije.

6.4 Specifikacija interfejsa Skoro svi softverski sistemi moraju raditi sa postojećim sistemima koji su već implementirani i instalirani u okruženju. Ako je to slučaj, interfejsi postojećih sistema moraju biti precizno specificirani. Postoje 3 tipa interfejsa koji trebaju biti definisani :

1) Proceduralni interfejsi gdje postojeći programi ili podsistemi nude servise kojima se pristupa preko procedura interfejsa. Ovi interfejsi se nekad zovu API (Application Programming Interfaces).

2) Strukture podataka koje se proslijeĎuju od jednog podsistema do drugog. 3) Prikaz podataka koji su uspostavljeni za postojeći podsistem.

6.5. Dokument softverskih zahteva Poznat kao SRS (Softvare Requirements Specification). To je zvanična izjava o tome šta developeri sistema trebaju implementirati. Treba uključiti i korisničke zahtjeve i detaljnu specifikaciju sistemskih zahtjeva. U nekim slučajevima, ova 2 tipa zahtjeva mogu biti spojena u jedan opis. Ovaj dokumenat može imati različite tipove korisnika. Ovo znači da ovaj dokumenat mora biti kompromis izmeĎu komuniciranja sa klijentima kroz zahtjeve, definisanja zahtjeva kroz precizne detalje za programere i testere, i uključivanja informacija o mogućoj evoluciji sistema. Nivo detalja koji treba koristiti zavisi od tipa sistema koji se razvija i razvojnog procesa koji se koristi. Kada se sistem razvija od strane spoljašnjeg preduzimača, kritične sistemske specifikacije moraju biti vrlo precizne i detaljne. TakoĎe, informacije koje su uključene u SRS trebaju zavisiti i od tipa softvera koji se razvija i pristupa razvoju koji se koristi.

41

Slika : Struktura dokumenta zahtjeva

42

Poglavlje 7 - Proces inžinjeringa zahtjeva Cilj procesa inženjeringa zahtjeva je da kreira i održava dokument sistemskih zahtjeva. Cjelokupan proces uključuje 4 potprocesa visokog nivoa:

- Studija izvodljivosti - Otkrivanje i analiza zahtjeva - PrevoĎenje ovih zahtjeva u neku standardnu formu (specifikacija) - Provjera da li zahtjevi zaista definiraju sistem koji kupac želi (validacija)

Slika 7.1 prikazuje odnose izmeĎu ovih aktivnosti, te dokumente koji nastaju u pojednim fazama procesa inženjeringa zahtjeva. Bitno ja naglasiti da se u svim sistemima zahtjevi mijenjaju iz raloga što osobe uključene u razvoj sistema vremenom počnu bolje razmumijevati sam sistem ili se mijenjaju organizacija koja kupuje sistem, organizacijsko okruženje, hardver ili softver sistema.

Slika 7.1

Na slici 7.2 je Somervillov alternativni pogled na proces inžinjeringa zahtjeva. Proces se sastoji od 3 faze, gdje su pojedine aktvnosti organizirane kao iterativni procesi duž spirale. U početku procesa najviše truda se ulaže u razumijevanje poslova visokog nivoa i nefunkcionalnih zahtjeva, a kasnije u vanjskim dijelovima spirale, najviše truda se ulaže u inženjering sistemskih zahtjeva i modeliranje sistema. Broj iteracija može varirati tako da se iz spirale može izaći nakon otkrivanja nekih ili svih korisničkih zahtjeva.

43

Slika 7.2

7.1 Studija izvodljivosti Za sve sisteme proces inženjerigna zahtjeva počinje sa sudijom izvodljivosti. Ulazi u studiju izvodljivosti su skup preliminarnih poslovnih zahtjeva, kratak opis sitema i načina na koji sitem podržava poslovne procese, a rezultat je izvještaj koji preporučuje da li se isplati nastavljati sa procesom inženjeringa zahtjeva i procesom razvoja. Studija izvodljivosti je kratka studija koja ima za cilj dati odgovore na slijedeća pitanja:

1) Da li sistem doprinosi općim ciljevima organizacije? (ključno pitanje) 2) Da li sistem može biti implementiran korištenjem trenutnih tehnologija i u okviru datog

budžeta i vremenskog rasporeda? 3) Da li se sistem može integrisati sa ostalim sistemima koji se već koriste?

Izrada studije izvodljivosti uključuje procjenu informacija, prikupljanje informacija i izradu izvještaja. U fazi procjene informacija se identificiraju one informacije koje mogu dati odgovore na gore postavljena pitanja. Kada se procijene te informacije onda se konsultiraju izvori informacija, kako bi se dobili odgovori na postavljena pitanja. Izvori informacija mogu biti menadžeri odjela, softverski inžinjeri, tehnološki experti ili krajnji korisnici. Kada se prikupe sve informacije, piše se izvještaj studije izvodljivosti.

7.2 Otkrivanje i analiza zahtjeva U ovoj fazi, softverski inžinjeri rade sa kupcima i krajnjim korisnicima da otkriju domen aplikacije, koje servise sistem treba pružati, koje su zahtijavane performanse sistema, hardverska ograničenja itd. Otkrivanje zahtjeva može biti teško iz nekoliko razloga:

1) Interesna grupa (stakeholders – osoba ili grupe koje su direktno ili indirektno u interakciji sa sistemom) često ne zna šta želi od sistema, osim u najgrubljim crtama, ili ima nerealistične zahtjeve jer nije upoznata za cijenom svojih zahtjeva.

2) Interesna grupa često iskazuje zahtjeve koristeći vlastitu terminologiju i implicitno podrazumijevajući neke aspekte svog posla.

44

3) Različite interesne grupe imaju različite zahtjeve ili ih izražavaju na različit način. Inžinjeri zahtjeva moraju znati pronaći sličnosti i konflikte.

4) Politički faktori mogu utjecati na zahtjeve. Menadžeri mogu zahtijevati neke stvari kako bi povećali svoj utjecaj u organizaciji.

5) Ekonomsko i poslovno okruženje je dinamično i može se mijenjati tokom analize, tako da se važnost pojedinih zahtjeva može mijenjati.

I ovu fazu opisuje spiralni, iterativni model koji se sastoji od sljedećih aktivnosti: 1) Otkrivanje zahtjeva – interakcija sa interesnim grupama kako bi se otkrili njihovi zahtjevi

i domen sistema. 2) Klasifikacija i organizacija zahtjeva – grupisanje povezanih zahtjeva i njihova

organizacija 3) OdreĎivanje prioriteta i odbijanje zahtjeva – odbijanje onih zahtjeva koji su meĎusobno

u konfliktu i postavljanje prioriteta preostalim zahtjevima 4) Dokumentovanje zahtjeva – zahtjevi se dokumentuju i postavljaju kao ulaz u iduću

iteraciju spirale

Otkrivanje zahtjeva Otkrivanje zahtjeva koristi različite tačke gledišta (viewpoints) koje dolaze od strane interesnih grupa, domena sistema ili drugih sistema u interakciji. Svaka tačka gledišta pruža odreĎenu perspektivu na sistem, koja se može preklapati sa ostalim perspektivama. Postoje 3 tipa tačaka gledišta:

1) Tačka gledišta interakcije – predstavlja ljude ili druge sisteme koji su u direktnoj interakciji sa posmatranim sistemom.

2) Tačka gledišta indirektnih korisnika – predstavlja interesne grupe koje ne koriste sistem ali na neki način utječu na zahtjeve.

3) Tačka gledišta domena sistema – predstavlja domenske karakterisitike i ograničenja koja uječu na zahtjeve sistema.

Ove tačke gledišta se mogu i detaljnije podijeliti u zavisnosti od konkretne aplikacije. (Ako nekog interesuje, str 150 u knjizi, odnosno 172 u pdf-u.)

Intervjuisanje Formalni ili neformalni intervjui sa interesnim grupama su dio većine procesa inžinjeringa zahtjeva. Zahtjevi se izvode iz odgovora na pitanja postavljena tokom intervjua. Postoje dva tipa intervjua:

1) Zatvoreni intervjui gdje intersne grupe odgovaraju na predefinisani skup pitanja. 2) Otvoreni intervjui gdje ne postoji unaprijad definisani plan. Inžinjeri zahtjeva istražuju

opseg probelma sa interesnim grupama i tako razvijaju bolje razumijevanje sistema. U praksi su intervjui najčešće mješavina ova dva tipa. Intervjui su dobri za dobivanje generalne slike o potrebnom sistemu, ali je tokom njih teško prikupiti znanje o domenu sistema iz slijedećih razloga:

- Svi stručnjaci iz pojedinog domena koriste terminologiju i žargon koji su specifični za konkretan domen, pa ih inžinjeri zahtjeva mogu pogrešno razumjeti.

- Neka znanja o domenu su prirodna za interesnu grupu, pa ih ona ne može jasno opisati ili smatra da je to nepotrebno posebno naglašavati.

Nekada je pored dokumenata intervjuisanje jedini izvor informacija o sistemskim zahtjevima. MeĎutim, samo intervjuisanje nije dovoljno i mora se koristiti sa ostalim tehnikama otkrivanja zahtjeva.

45

Scenariji Scenariji predstavljaju opise pojednih primjera interakcijskih sesija sa sistemom. Svaki scenario pokriva jednu ili više mogućih interakcija. Scenario počinje grubim prikazom interakcije, a tokom daljeg otkrivanja se dodaju detalji kako bi se upotpunio opis interakcije. U općim crtama, scenario može uključiti slijedeće:

- Opis šta sistem i korisnici očekuju kada scenario počne - Opis normalnog toka dogaĎaja u scenariju - Opis onoga što može poći po zlu i kako se toga riješiti - Informacije o ostalim aktivnostima koje se odvijaju u isto vrijeme - Opis stanja sistema kada se scenario završi

Scenario može biti tekstualni dokument, uz dodatak dijagrama, screen shot-ova itd. Tokom otkrivanja zahtjeva pomoću scenarija, inženjeri zahtjeva rade sa interesnim grupama kako bi identificirali scenarije i otkrili njihove detalje.

Slučajevi upotrebe Slučajevi upotrebe predstavljaju scenario-baziranu tehniku za otkrivanje zahtjeva. Oni su sada postali osnovni element UML notacije za opis objektno-orijentisanih modela sistema. U najjednostavnijoj formi oni opisuju tipove interakcije i učesnike koji su uključeni. Slučajevi upotrebe identificiraju individualne interakcije sa sistemom. TakoĎer se koriste i dijagrami sekvenci kako bi se dodale informacije dijagramu slučajeva upotrebe. Scenariji i slučajevi upotrebe su efektivni za prikupljanje zahtjeva iz tačke gledišta interakcije gdje svaki tip interakcije može biti predtavljen kao jedan use-case. MeĎutim, oni nisu efektivni za otkrivanje ograničenja ili nefunkcionalnih i poslovnih zahtjeva visokog nivoa.

Etnografija Softverski sistemi ne egzistiraju u izolaciji, oni su dio socijalnog i organizacijskog okruženja, pa prema tome zahtjevi softverskog sistema mogu biti izvedeni i iz ovih okruženja. Etnografija je opservacijska tehnika koja se koristi za razumijevanje socijalnih i organizacijskih zahtjeva. Analitičar se uklopi u radno okruženje gdje će se sistem koristiti i svakodnevno posmatra posao i vodi evidenciju o zadacima koji se obavljaju. Etnografija pomaže analitičarima da otkriju implicitne zahtjeve sistema koje korisnici često ne artikulišu jer predstavljaju prirodne stvari za njih. Etnografske studije mogu otkriti detalje o kritičnim procesima koji se ne mogu otkriti drugim tehnikama. Etnografija se može kombinirati sa izradom prototipa kako bi se smanjio broj ciklusa usavršavanja prototipa.

7.3 Validacija zahtjeva

Cilj validacije zahtjeva je da pokaže da zahtjevi uistinu definiraju sistem koji kupac želi. Ova faza je važna jer greške koje postoje u dokumentu zahtjeva mogu voditi do značajnih troškova ako se otkriju u fazi razvoja ili kada se sistem pusti u upotrebu. Tokom validacije se provode sljedeće provjere:

1) Provjera validnosti – ovom provjerom se mogu otkriti dodatne ili drugačije funkcije od onih zahtijevanih. Sistemi imaju različie interesne grupe sa različitim potrebama i svaki skup zahtjeva mora predstavljati kompromis njihovih potreba.

2) Provjera konzistentonosti – zahtjevi sistema ne smiju doći u konflikt niti biti kontradiktorni.

46

3) Provjera kompletnosti – dokument zahtjeva mora opisivati sve funkcionalnosti i ograničenja

4) Provejre realističnosti – koristeći znanja o postojećim tehnologijama mora se provjeriti da li specificirani zahtjevi mogu biti implementirani. TakoĎer se provjerava da raspoloživost budžeta i vremenskih okvira.

5) Mogućnost verifikacije – sistemski zahtjevi moraju biti pisani na način da ih je moguće verificirati, odnosno da je moguće napisati skup testova koji će demonstrirati da je isporučeni sistem u skladu sa specificiranim zahtjevima.

Tehnike za validaciju zahtjeva:

- Pregledi (reviews) zahtjeva – sistematično pregledanje od strane tima pregledača - Izrada prototipa – izrada izvršivog modela sistema i njegovo demonstriranje kupcima i

krajnjim korisnicima - Generiranje testnih slučajeva – testovi mogu otkriti neke probleme u zahtjevima. Ako je

teško ili nemoguće generirati testove, to znači da će i implementacija biti teško izvodiva.

Pregledi zahtjeva

Pregledi zahtjeva mogu biti formalni i neformalni. Neformalni predstavljaju diskusiju o zahtjevima izmeĎu osoba koje razvijaju softver i što je moguće više interesnih grupa. Mnogi problemi se mogu otkriti u razgovoru s interesnim grupama prije samog obavezivanja na formalni pregled. U formalnom pregledu razvojni tim treba provesti klijenta kroz zahtjeve sistema, objašnjavajući svaki zahtjev pojedinačno. Tim za pregledanje provjerava konzistentnost i kompletnost zahtjeva. Pregledači takoĎer mogu provjeravati:

1) Mogućnost verifikacije – Da li je zahtjev moguće testirati? 2) Razumljivost – Da li krajnji korisnici sistema tačno razumiju zahtjeve? 3) Sljedivost – Da li je naveden izvor zahtjeva? 4) Adaptibilnost – Da li je promijeniti pojedinačni zahtjev bez velikih promjena ostalih

zahtjeva?

7.4 Menadžment zahtjeva

Zahtjevi velikih softverskih sistema se stalno mijenjaju. Interesne grupe vremenom stiču bolje razumijevanje sistema, pa se zahtjevi moraju mijenjati kako bi reflektovali promjenu pogleda na problem. Kada se instalira sistem, javljaju se nove potrebe i prioriteti:

1) Veliki sitemi imaju raznoliku zajednicu korisnika koji imaju različite potrebe i prioritete, pa se mora mijenjati balans podrške koji im se pruža.

2) Osobe koje plaćaju sistem i korisnici su rijetko iste osobe. Kupci nameću zahtjeve u skladu sa organizacijskim i budžetnim ograničenjima, pa je ponekad potrebno dodati nove funkcionalnosti za korisnike kako bi sistem postigao svoje ciljeve.

3) Poslovno i tehnološko okruženje sistema se mijenjaju nakon instalacije pa je potrebno uvesti novi hardver, nove interfejse prema drugim sistemima, nova zakonodavstva i regulacije je potrebno implenetirati u sistemu itd.

Menadžment zahtjeva je proces razumijevanja i kontrolisanja promjena nad sistemskim zahtjevima.

Trajni i promjenjivi zahtjevi

Iz evolutivne perspektive, zahtjevi se dijele u dvije klase: 1) Trajni zahtjevi – relativno stabilni zahtjevi koji se izvode iz osnovnih djelatnosti

organizacije i koji su direktno povezani sa domenom sistema.

47

2) Promjenjivi zahtjevi – ovo su zahtjevi koji će se vjerovatno mijenjati tokom procesa razvoja sistema ili nakon što se on pusti u upotrebu

Planiranje menadžmenta zahtjeva

Planiranje je prva i ključna faza u procesu menadžmenta zahtjeva. Za svaki projekat, u fazi planiranja se uspostavlja nivo detaljnosti menadžmenta zahtjeva koji je neophodan. Tokom faze menadžmenta zahtjeva mora se odlučiati o:

1) Identifikacija zahtjeva – svaki zahtjev mora biti jedinstveno identificiran kako bi mogao biti referenciran u drugim zahtjevima

2) Proces menadžmenta promjena – ovo je skup aktivnosti koje procjenjuju utjecaj i cijenu promjena.

3) Politike sljedivosti – ove politike definiraju veze izmeĎu zahtjeva i veze izmeĎu zahtjeva i dizajna sistema koje treba evidentirati

4) Podrška CASE alata – Menadžemt zahtjeva uključuje proceiranje velikog broja informacija, pa je potrebna upotreba CASE alata kao što su specijalizirani sistemai za menadžemnt zahtjeva, spreadsheet-ovi, jednostavne baze podataka idr.

Kada se dese promjene u zahtjevima, mora se pratiti utjecaj ovih promjena na druge zahtjeve i na dizajn sistema. Sljedivost je osobina specifikacije zahtjeva koja reflektuje jednostavnost pronalaženja povezanih zahtjeva. Postoje 3 vrste sljedivosti koje se mogu održavati:

1) Sljedivost izvora – informacija povezuje zahtjeve sa interesnim grupama koji su ih predložili.

2) Sljedivost zahtjeva – informacije koje povezuju zavisne zahtjeve u dokumentu zahtjeva 3) Sljedivost dizajna – informacije koje povezuju zahtjeve sa modulom dizajna gdje se ti

zahtjevi implementiraju. Koriste se za procjenu utjecaja promjena zahtjeva na dizajn i implementaciju sistema.

Informacije o sljedivosti se prikazuju u matricama sljedivosti u kojima se svaki zahtjev upisuje u red i u kolonu matrice. Ako postoji zavisnost izmeĎu dva zahtjeva, ona se upisuje na presjeku reda i kolone. MeĎutim, za veliki broj zahtjeva matrice nisu pogodne pa se koriste baze podataka za voĎenje evidencije o zavisnostima. Menadžment zahtjeva zahtijeva podršku nekog CASE alata. Podrška je potrebna za:

1) Pohranjivanje zahtjeva 2) Menadžment promjena 3) Menadžment praćenja zavisnosti (traceability – sljedivost)

Alati za menadžment zahtjeva mogu biti obični word procesori, spreadsheet-ovi, PC baze podataka, ali i komlikovaniji kao što su DOORS i RequisitePro.

Menadžment promjena zahtjeva

Menadžment promjena zahtjeva se treba primjenjivati na sve promjene nad zahtjevima kako bi se osigurala konzistentnost i kontrola promjena. Postoje 3 osnovna stupnja u procesu menadžmenta promjena:

1. Analiza problema i specifikacija promjena – identificira se problem sa zahtjevima ili se zahtijeva promjena i analizira se da li je validna

2. Analiza promjena i troškova – procjenjuju se efekti promjena korištenjem informacija o sljedivosti i troškovi izvršavanja promjena

3. Implementacija promjena – modificira se dokument zahtjeva i, ako je potrebno, dizajn sistema i implementacija. Dokument zahtjeva treba biti organiziran tako da je moguće izvršiti promjene bez puno potrebe za ponovnim pisanjem i reorganizacijom.

48

Poglavlje 8 - Modeli sistema Korisnički zahtjevi bi trebali biti napisani jezikom razumljivom korisniku, jer moraju biti razumljivi za ljude koji nisu tehnički eksperti. Detaljniji sistemski zahtjevi mogu biti opisani u nešto formalnijoj tehničkoj formi. Jedna od široko korištenih tehnika je da se specifikacija sistema dokumentuje kao skup modela sistema. Ovi modeli su grafičke predstave koje opisuju poslovne procese, probleme koji se rješavaju i sistem koji treba razviti. Pošto se koristi grafička reprezentacija, modeli mogu često biti razumljiviji od netehničkog opisa sistemskih zahtjeva. Oni su takoĎer važan most izmeĎu analize i dizajna procesa. Prilikom analize procesa mogu se koristiti modeli za bolje razumijevanje postojećeg sistema koji se zamjenjuje ili poboljšava ili za specifikaciju novog sistema. Različiti modeli se mogu razviti kako bi se predstavio sistem iz različitih perspektiva. Na primjer:

- eksterna perspektiva, kod koje se modelira kontekst ili okruženje sistema - perspektiva ponašanja, kod koje se modelira ponašanje sistema - strukturalna perspektiva, kod koje se modelira arhitektura sistema ili struktura

podataka koje sistem procesira. Najvažniji aspekt sistemskog modela je da se izostavljaju detalji. Sistemski model je apstrakcija sistema koji se proučava prije nego alternativna reprezentacija tog sistema. Idelano, reprezentacija sistema bi trebala sadržavati sve informacije o entitetima koji se predstavljaju. Apstrakcija dosta pojednostavljuje i uzima u obzir najvažnije karakteristike sistema. Na primjer, kada bi se ova knjiga objavljivala u nastavcima u novinama, predstavljanje bi bilo apstrakcija ključnih detalja iz knjige. Ako bi se knjiga prevela sa engleskog na italijanski to bi bila njena alternativna reprezentacija. Nastojanje prevodioca bi bilo da informacije koje su izvorno napisane na engleskom jeziku prenese u prevedenu verziju. Različiti tipovi sistemskih modela su bazirani na različitim pristupima apstrakcije. "Data-flow" model se bazira na toku podataka i funkcionalnim transformacijama nad tim podacima. On izostavlja detalje o strukturi podataka. Nasuprot ovom modelu, model entiteta i veza meĎu podacima dokumentira strukturu sistemskih podataka, a ne funkcionalnosti. Primjeri tipova sistemskih modela koji se mogu kreirati prilikom procesa analize su:

- "Data-flow" model koji pokazuje kako se podaci procesiraju u različitim dijelovima sistema

- Kompozicijski (agregacijski) model pokazuje kako su entiteti u sistemu sastavljeni od drugih entiteta

- arhitekturalni modeli- pokazuje glavne podsisteme koji sačinjavaju sistem - Klasifikacijski model - klasni dijagram (dijagram nasljeĎivanja) koji pokazuje uobičajene

karakteristike entiteta - stimulus-response model(akcija-reakcija)- Dijagram promjene stanja koji pokazuje kako

sistem reaguje na interne i eksterne dogaĎaje. Kad god je moguće koristi se UML notacija, koja je postala standardni jezik modeliranja za objektno-orijentisano modeliranje. Kada UML nema ogovarajuću notaciju, koristi se jednostavna intuitivna notacija za opis modela.

8.1 Kontekstualni modeli

U ranoj fazi odreĎivanja zahtjeva i analize procesa treba se odlučiti o granicama sistema. Ovo uključuje rad sa korisnicima sistema kako bi se razjasnilo šta je sistem a šta njegovo okruženje. U ovom procesu odluka se mora donijeti što prije kako bi se ograničila cijena sistema i vrijeme potrebno za analizu.

49

U nekim slučajevima, granica izmeĎu sistema i njegovog okruženja je relativno jasna. U drugim slučajevima, postoji više fleksibilnosti, i mi odlučujemo šta čini granicu izmeĎu sistema i njegovog okruženja u toku procesa inženjeringa zahtjeva. Na primjer, kažemo da razvijamo specifikaciju za bibliotečni sistem LIBSYS. Prisjetimo se da je namjena ovog sistema dostavljanje elektronskih verzija vlasničkog (copyrighted) materijala na računare korisnika. Korisnici ove materijale mogu odštamapati. Pri razvoju specifikacije za ovaj sistem potrebno je odlučiti da li su druge baze podataka kao što je katalog biblioteke u okviru granica sistema. Ako jeste tada se može dopustiti pristup sistemu kroz kataloški korisnički interface, ako nije tada korisnici mogu imati neugodno korištenje zbog potrebe za prelazak iz jednog sistema u drugi. Definicija sistemskih granica nije bezvrijedno prosuĎivanje. Sociološki i organizacioni faktori mogu uticati na to da granice sistema odreĎuju netehnički faktori. Na primjer, sistemska granica može biti postavljena tako da proces analize može biti obavljen na jednom mjestu. Može biti odabrana tako da nije potrebna konsultacija sa djelimično "teškim" menadžerom. Može biti postavljena tako da se povećavaju sistemski troškovi i da odjel za razvoj sistema mora biti proširen kako bi se dizajnirao i implementirao sistem. Jednom kada se odluči o granicama sistema dio analize aktivnosti je definisanje konteksta i zavisnosti koje sistem ima u svom okruženju. Normalno, pravljenje jednostavnog arhitekturalnog modela je prvi korak u ovoj aktivnosti. Slika 8.1 je arhitekturalni model koji ilustrira strukturu informacioni sistem koji uključuje "auto-teller" bankovnu mrežu. Arhitekturalni modeli visokog nivoa se obično predstavljaju kao jednostavni blok dijagrami gdje je svaki podsistem predstavljen imenovanim pravougaonikom, a linije indiciraju asocijacije meĎu podsistemima.

Slika 8.1.

Sa slike 8.1 vidimo da je svaki ATM povezan na "account database", "local branch accounting system", "security system" i "maintain system". Sistem je takoĎer povezan na "usage database" koji monitoriše kako se koristi lokalna mreža ATM-ova te na "local branch counter system" koji pruža servise kao što su backup i štampanje. Ovi podsistemi ne moraju zato biti uključeni u sam ATM. Arhitekturalni modeli opisuju okruženje sistema. Oni meĎutim ne pokazuju relacije izmeĎu drugih sistema u okruženju i sistem koji se specificira. Eksterni sistemi mogu proizvoditi podatke za sistem ili konzumirati podatke iz sistema. Oni mogu dijeliti podatke sa sistemom, ili mogu biti povezane direktno kroz mrežu ili mogu biti nepovezani. Oni mogu biti fizički smješteni u različitim ali i istim prostorijama. Sve ove relacije mogu uticati na zahtjeve sistema koji se definira i moraju se uzeti u obzir.

50

Jednostavni arhitekturalni modeli se obično dopunjavaju pomoću drugih modela kao što su procesni modeli koji pokazuju procesne aktivnosti podržane od sistema. Data-Flow modeli mogu takoĎer biti korišteni za prikaz podataka koji se prenose izmeĎu sistema i drugih sistema u njegovom okruženju. Na slici 8.2 ilustruje se procesni model za proces nabavke opreme u organizaciji. Ovo uključuje specificiranje potrebne opreme, pronalaženje i odabir dobavljača, naručivanje opreme, preuzimanje opreme. Dostavu opreme i testiranje iste nakon dostave. Prilikom specifikacije računarske podrške za ovaj proces mora se odlučiti koje od ovih aktivnosti će biti podržane. Druge aktivnosti su van granica sistema. Na slici 8.2 tačkaste linije označavaju aktivnosti koje su u granicama sistema.

Slika 8.2.

8.2 Modeli ponašanja

Koriste se da opišu sveukupno ponašanje sistema. Dva su tipa ovih modela: - data-flow modeli (modeli toka podataka) - kojim se modelira obrada podataka u sistemu - state machine models - kojim se modelira način na koji sistem reaguje na dogaĎaje.

Ovi modeli se mogu koristiti odvojeno ili zajedno, zavisno od tipa sistema koji se razvija. Mnogi poslovni sistemi su prvenstveno voĎeni podacima. Oni su kontrolisani ulaznim podacima sistema sa relativno malo obrada vanjskih podataka. Nasuprot tome, real-time sistemi su često voĎeni dogaĎajima sa minimalnom obradom podataka. State machine model je mnogo efikasniji u predstavljanju ponašanja sistema. Druge klase sistema mogu istovremeno biti voĎene i podacima i dogaĎajima i tada se mogu istraživati oba tipa modela.

51

8.2.1 Modeli toka podataka

Ovi modeli su intuitivan način predstavljanja načina na koji se obraĎuju podaci u sistemu. U analizi, oni se mogu koristiti da modeliraju način obrade podataka u postojećem sistemu. Označavanje korišteno u ovim modelima predstavlja funckionalnu obradu, spremište podataka i kretanje podataka izmeĎu funkcija. Modeli toka podataka se koriste da prikažu kako podaci protiču kroz korake obrade. Na primjer, korak obrade bi mogao biti da se filtriraju dupli zapisi u bazi kupca. Podaci se mijenjaju u svakom koraku prije nego što preĎu na sljedeći nivo. Ovi koraci obrade ili transformacije predstavljaju softverske procese ili funckcije kada se dijagrami toka podataka koriste za dokumentovanje dizajna softvera. U modelu analize, ljudi ili računari mogu provesti obradu.

Slika 8.3. Model toka podataka, koji prikazuje korake uključene u obradu proizvoda (kao što je računarska oprema) u organizaciji je prikazan na slici 8.3.. Na slici 8.2., model prikazuje kako se proizvodi kreću od procesa do procesa, a takoĎer prikazuje i skladišta podataka koja su uključena u ovaj proces. Modeli toka podataka su korisni zbog praćenja i dokumentovanja kako su podaci povezani sa odreĎenim koracima procesa kroz sistem, što olakšava analitičaru da to shvati. Dijagrami toka podataka imaju tu prednost, da za razliku od nekih drugih notacija modeliranja, oni su jednostavni i intuitivni. Obično je moguće objasniti ih potencijalnim korisnicima sistema, koji onda mogu učestvovati u validaciji analize. U suštini, razvoj modela, kao što su modeli toka podataka trebali bi biti top-down proces. U ovom primjeru to bi značilo da treba početi analizom sveukupnog procesa nabavke. Zatim prijeĎite na analizu pod-procesa, kao što su naručivanje. U praksi, analiza nije nikad takva. Modeli nižih nivoa mogu se razviti prvi, a zatim zahvatiti stvaranje više općenitih modela. Modeli toka podataka pokazuju funkcionalne prespektive gdje svaka promjena predstavlja jednu funkciju ili proces. Oni su posebno korisni tokom analize zahtjeva, jer se mogu koristiti da se prikaže end-to-end procesiranje u sistemu. To jeste, oni pokazuju čitav niz akcija koje se održavaju od procesiranja ulaza,do odgovarajućeg izlaza koji je odgovor sistema. Slika 8.4 ilustrira ovo korištenje dijagrama toka podataka. To je dijagram obrade koji predstavlja sistem inzulin pumpe, predstavljenim u poglavlju 3.

52

i State machine models

Modeli stanja mašine opisuju kako sistem odgovara na unutrašnje i spoljašnje dogaĎaje. Modeli stanja mašine pokazuju stanja sistema i dogaĎaje koji uzrokuju tranzicije iz jednog stanja u drugo.Oni ne prikazuju protok podataka unutar sistema.Ovaj tip modela se često koristi za modeliranje real-time sistema.

Model stanja sistema pretpostavlja da se sistem u bilo kojem trenutku nalazi u jednom od mogućih stanja. Kada se desi pobuda, ona moze izazvati prelazak u drugo stanje. UML predstavljanje modela stanja:

Zaobljeni pravougaonici predstavljaju stanja sistema. Oni uključuju kratak opis aktivnosti koja se izvrsava u tom stanju.

Strelice sa nazivom predstavljaju pobude koje izazivaju prelazak iz jednog stanja u drugo.

UML notacija dozvoljava prikaz aktivnosti koja se odvija u stanju('do:'). U detaljnim specifikacijama sistema potrebno je navesti više detalja i o pobudi i o stanjima sistema.

Slika 8.5 Model stanja jednostavne mikrovalne

Ovo je dijagram stanja jednostavne mikrovalne pečnice, koja sadrži dugme za regulisanje snage, dugme za mjerenje vremena i dugme za start sistema. Pretpostavimo da se korištenje pečnice odvija na sljedeći način:

1. Odabrati jačinu (half-power ili full-power) 2. Unijeti vrijeme pečenja 3. Pritisnuti Start i hrana će se peći dok ne istekne zadato vrijeme.

53

Iz sigurnosnih razloga pecnica nece raditi ukoliko su vrata otvorena, a završetak pečenja biće pračen zvučnim signalom. Pečnica ima veoma jednostavan znakovni displej, koji ce prikazivati alarme i upozoravajuće poruke. Sa dijagrama se vidi da sistem reaguje na isti način bez obzira da li je power full ili half. Korisnik nakon sto je odabrao, može promijeniti svoje misljenje i izabrati drugo. Vrijeme je postavljeno i ako su vrata zatvorena, pokretanje sistema je moguće (pritiskom na Start dugme). Problem modela stanja je to sto se broj mogućih stanja brzo uvećava. Kod većih sistema modeliranje strukture je neophodno. Jedan od načina da se ovo postigne je korištenjem UML notacije super stanja, koje vrši enkapsulaciju više odvojenih stanja. Ovo super stanje izgleda kao jedno stanje na high-level modelu, ali se onda proširuje na vise detalja na odvojenim dijagramima. Stanje Operation uključuje nekoliko pod-stanja. Ono pokazuje da Operation počinje sa statusom Check (Provjeri) i onda ako je otkriven bilo kakav problem, alarm se aktivira i operacija se otkazuje. Pečenje angažuje rad mikrovalnog generatora do isteka zadatog vremena. Po završetku čuje se zvučni signal. Ako su vrata otvorena za vrijeme operacije, sistem prelazi u Disable (deaktivirano) stanje, kao što je prikazano na slici 8.5.

8.3 Modeli podataka

Najveći softver sistemi koriste velike baze podataka. U nekim slučajevima, ova baza podataka je neovisna od softver sistema. U ostalim slučajevima, kreirana je da bi se softver razvijao (valjda paralelno). Važan dio modeliranja sistema je definisanje logične forme podataka koje sistem obradjuje (procesira). One se ponekad zovu i semantički data modeli. Najrasprostranjenije korištena tehnika data modelinga je ERA modeling (entity relation attribute) koji pokazuje cjeline (entitete) podataka, njihove odgovarajuće atribute kojima pripadaju i reakcije izmedju ovih entiteta. UML ne uključuje specifičnu notaciju za ovo modeliranje baza podataka, kao sto predstavlja objektno orjentisani razvojni proces i modeli podataka koji koriste objekte i njihove relacije. U ERA modelu, entitete možete predstavljati kao pojednostavljenje klase objekata. Oni nemaju operacije, atribute kao atribute klasa i imenovane veze izmedju klasa, kao relacije.

54

Slika 8.8. je primjer modela podataka, koji je dio bibliotečnog sistema LIBSYS, predstavljenog u prethodnim poglavljima. Ponovni poziv tog LIBSYS sistema je dizajniran da dostavi kopije članaka o autorskim pravima, koji su objavljeni u magazinima i žurnalima i da sakupe isplate za ove članke. Zbog toga, model podataka mora uključiti informaciju o članku, autorska prava ovlaštenih i kupca članka. Slika 8.8. pokazuje da „Article“ ima atribute koji predstavljaju naslov, autore, ime PDF fajla članka i mogućnost isplačivanja kroz članarinu. Ovo je linkovano na izvor (Source) u kojem je članak objavljen i na agenciju autorskih prava za zemlju u kojoj je objavljen. Oboje, Copyright i Source , su povezani na Country. Država u kojoj je izdato pravo je bitna, zato što zakoni variraju od države do države. Dijagram takodje pokazuje da „Byers“ postavlja „Order“ (narudzbu) za „Article“. Kao svakom grafičkom modelu, modelu podataka nedostaju detalji. Trebalo bi imati detaljnije opise entiteta, veza i atributa koji su uključeni u model. Data dictionary je pojednostavljena alfabetska lista imena uključenih u modele sistema. Kao i ime, rječnik bi trebao da uključuje i odgovarajući opis imenovanog entiteta i ako ime sadrzi kompozitni objekat, treba da sadrzi i opis kompozicije. Druge informacije, kao datum kreiranja, kreator i prikazivanje entiteta, takodje mogu biti uključeni, zavisno od tipa modela koji se kreira. Prednosti korištenja rječnika podataka su:

- To je mehanizam za „upravljanje imenima“. Mnogi ljudi su morali da izmisle imena za entitete i veze, prilikom razvoja velikih modela sistema. Ova imena bi se trebala koristiti konzistentno i ne bi se trebala sukobljavati (da ne dodje do dvosmislenosti).

- Softver data dictionary-a može provjeravati da li je ime jedinsteveno, kad je to potrebno i ukazivati na dupliciranje imena.

- Može se koristiti kao skladište za organizovane informacije. Kako se sistem kreira, informacije koje mogu povezivati analizu, dizajn, implementaciju i razvoj se dodaju u data dictionary, tako da su sve informacije o jednom entitetu na jensom mjestu.

55

Ulazi u data dictionary, prikazani na slici 8.9. definišu imena u semantičkom modelu podataka za LIBSYS. Sva imena sistema koja predstavljaju imena entiteta, relacija, atributa ili usluga bi trebali biti u rječniku. Softver je uglavnom korišten da kreira, podržava i „ispituje“ rječnik. Ovaj softver moze biti integrisan sa ostalim alatima, tako da je kreiranje ovog rjecnika djelimicno automatizovano. Kao pimjer, CASE alati koji podržavaju modeliranje sistema, uglavnom uključuju podršku za data dictionary i ubačuju imena u rječnik prvi put kad se koriste u modelu.

8.4 Modeli objekata

Objektno-orijentirani pristup cijelom procesu razvoja softvera se obično koristi, osobito za razvoj interaktivnih sistema. To znači izražavanje zahtjeva sistema koristeći objektni model, projektiranje korištenjem objekata i razvoj sistema u objektno-orijentiranim programskim jezicima kao što su Java i C + +. Modeli objekata koji se razvijaju tokom analize zahtjeva mogu se koristiti za predstavljanje sistema podataka i njihove obrade. U tom pogledu, oni kombiniraju neke koristi od podataka toka i semantičkih modela podataka. Oni su takoĎer korisni za izlaganje kako se entiteti u sistemu mogu klasificirati i sastojati od drugih subjekata. Za neke vrste sistema, modeli objekta su prirodni načini odražavanja stvarnih entiteta koji su izmanipulirani sistemom. To posebno vrijedi kada sistem obraĎuje informacije o opipljivim entitetima, poput automobila, aviona ili knjiga, koji imaju jasno prepoznatljive atribute. Više abstraktni, na višem nivou entiteti, kao što su koncept biblioteke, sistem za voĎenje zdravstvenih kartona ili program za obradu teksta su teži za modeliranje kao klase objekata. Oni ne moraju nužno imati jednostavan interface koji se sastoji od nezavisnih atributa i operacija. Razvijanje modela objekata tokom analize zahtjeva obično pojednostavljuje prelazak na objektno-orijentirani dizajn i programiranje. Dakle, ponekad je korisno dodati modele objekata sa data-flow modelima koji pokazuju end-to-end obrade podataka u sistemu. Klasa objekata je apstrakcija nad skupom objekata koji identificira zajedničke atribute (kao u semantičkom modelu podataka) i servise ili operacije koje su obezbijeĎene od svakog objekta. Objekti su izvršni etiteti s atributima i servisima objektne klase. Objekti su primjerci klase objekata, i mnogi objekti mogu biti kreirani iz klase. Općenito, modeli razvijeni koristeći analizu fokusiraju se na klase objekata i njihovih meĎusobnih odnosa. U objektno-orijentiranoj analizi zahtjeva, trebali bi modelirati entitete iz stvarnog svijeta korištenjem klase objekata. Ne treba uključivati podatke o pojedinim predmetima (primjerke klase) u sistemu. Možete stvoriti različite vrste modele objekta, prikazujući kako su klase objekata povezane meĎusobno, kako su objekati ujedinjeni da formiraju druge objekte, kako objekti komuniciraju s drugim objektima i tako dalje. Svaka od ovih predstavlja jedinstvenu informaciju o sistemu koji je naveden. Analiza procesa za identifikaciju objekata i objektnih klasa je prepoznata kao jedan od najtežih područja objektno-orijentiranog razvoja. Identifikacija objekata je u osnovi ista za analizu i dizajn. Različite metode objektno-orijentirane analize predložene su 1990-ih (Coad i Yourdon, 1990; Rumbaugh, et al., 1991; Jacobsen, et al., 1993; Booch, 1994). Ove metode su imale mnogo toga zajedničkog, a tri od ključnih programera (Booch, Rumbaugh i Jacobsen) su odlučila integrirati svoje pristupe za izradu ujedinjenog metoda (Rumbaugh i al., 1999b). Unified Modeling Language (UML) je postao standard za objektno modeliranje. UML uključuje notacije za različite vrste modela sistema. Već smo vidjeli use-case modele i dijagrame sekvence u ranijim poglavljima i state mashine modele ranije u ovom poglavlju.

56

Klasa objekata u UML, kao što ilustrira primjer na slici 8.10, je predstavljena kao vertikalno postavljen pravougaonik s tri dijela:

1. Ime objekta klase je u gornjem dijelu. 2. Atributi klase su u srednjem dijelu. 3. Operacije povezane sa klasom objekata su u donjem dijelu pravougaonika.

8.4.1 Modeli naslijeđivanja

Objektno-orijentirano modeliranje uključuje identificiranje klasa objekata koji su važni u domeni u kojoj se proučavaju. One su zatim organizirane u taksonomiju. Taksonomija je klasifikacijska shema koja pokazuje kako je klasa objekata povezana s drugim klasama kroz zajedničke atribute i servise. Za prikaz ove taksonomije, klase se organiziraju u hijerarhiju naslijeĎivanja, s najopćenitijim klasama objekata na vrhu hijerarhije. Više specijalizirani objekti nasljeĎuju njihove atribute i usluge. Ovi specijalizirani objekti mogu imati svoje vlastite atribute i usluge. Slika 8.10 ilustrira dio hijerarhije klasa za pojednostavljeni model biblioteke. Ova hijerarhija daje informacije o stavkama u biblioteci. Biblioteka drži različite predmete, kao što su knjige, muzika, snimke filmova, časopise i novine. Na slici 8.10, najopćenitiji predmet je na vrhu stabla i ima skup atributa i servisa koji su zajednički za sve stavke. To su naslijedile klase Published item i Recorded item koje su dodale vlastite attribute koje su tada naslijedili niže stavke. Slika 8.11 je primjer neke druge hijerarhije nasljeĎivanja koje bi mogle biti dio modela biblioteke. U tom slučaju, korisnici biblioteke su prikazani. Postoje dvije klase korisnika: oni koji mogu posuditi knjige i oni koji mogu čitati knjige u biblioteci, bez njihovog uzimanja. U UML notaciji, nasljeĎivanje je prikazano gore 'a ne' dolje ' kao što je to u nekim drugim objektno-orijentiranog notacijama ili u jezicima poput Jave, gdje pod-klase naslijeĎuju od super-klasa. To je strelica (prikazana kao trokut) koja pokazuje iz klase koje nasljeĎuju atribute i servise na super-klasu. Umjesto korištenja termina naslijeĎivanje, UML se odnosi na generalizaciji odnos.

57

Slika 8.10 Dio hijerarhije klasa za biblioteku

Slika 8.11 Hijerarhija klase korisnika

58

MeĎutim, sve dok sve što je u biblioteci mora imati neku vrstu identifikatora ili registracijski broj, iz toga ne slijedi da sve mora imati naslov. Na primjer, biblioteke mogu imati privatne radove umirovljenih političara. Mnogi od tih predmeta, kao što su pisma, ne mogu biti eksplicitno naslovljeni. Ovi dokumenti će biti klasificirani koristeći neke druge klase (nije prikazano ovdje) koji ima drugačiji set atributa. Slika 8.10 i 8.11 pokazuju hijerarhiju naslijeĎivanja klasa gdje svaka klasa objekata nasljeĎuje atribute i operacije od jednog roditelja klase. Višestruki modeli naslijeĎivanja mogu se izgraditi u razredu koji ima nekoliko roditelja. Njegove naslijeĎene osobine i servisi su spona onih naslijeĎenih iz svake super-klase. Slika 8.12 pokazuje primjer modela višestrukog nasljeĎivanja koji može takoĎer biti dio modela biblioteke. Glavni problem s višestrukim nasljeĎivanjem je dizajniranje grafa nasljeĎivanja gdje objekti ne nasljeĎuju nepotrebne atribute. Ostali problemi uključuju poteškoće u reorganizaciji grafa nasljeĎivanja, kad su potrebne promjene i rješavanje sukoba u kojima imena atributa dvije ili više super-klase imaju isti naziv, ali različita značenja. Na nivou modeliranja sistema, takvi sukobi su relativno laki za riješiti ručnim mijenjanjem modela objekata. Oni uzrokuju više problema u objektno-orijentiranom programiranju.

8.4.2 Agregacija objekata

TakoĎe, kao obezbjeĎenje atributa i servisa putem odnosa naslijeĎivanja s drugim objektima, neki objekti su grupacije drugih objekata.

Slika 8.12 Višestruko nasljeĎivanje

59

Slika 8.13 Kurs u kojem su ujedinjeni objekti

To jest, objekt je agregacija niza drugih objekata. Klase koje predstavljaju ove predmete mogu biti modelirane pomoću modela agregacije objekata, kao što je prikazano na slici 8.13. U ovom primjeru, ja sam modelirao stavku biblioteke, koja je studijski paket za kurs na univerzitetu. Ovaj paket uključuje skripte, vježbe, uzorke rješenja, kopije transparencies korištene u predavanjima i videokasete. UML notacija za agregaciju je predstavljanje kompozicije uključujući signal u obliku dijamanta na izvor linka. Dakle, sa slike 8.13 se može čitati „Paket se sastoji od jednog ili više zadataka, OHP paketa slajdova, skripti i videokaseta.

8.4.3 Modeliranje ponašanja objekata

Za model ponašanja objekata, morate pokazati kako su operacije obezbijeĎeneod strane objekata koji ih koriste. U UML, modelirate ponašanja korištenjem scenarija koji su predstavljeni kao UML use-case dijagrami (objašnjeno u poglavlju 7). Jedan od načina da modelirate ponašanje je da koristite UML dijagram sekvenci koji prikazuje slijed radnji koji su uključeni u use-case. Kao i dijagram sekvenci, UML takoĎer uključuje dijagram kolaboracije koji pokazuje slijed poruka koje se razmjenjuju prema objektima. To je slično dijagramu sekvenci tako da ih prikazujem ovdje. Možete vidjeti kako se dijagram sekvenci može koristiti za modeliranje ponašanja na slici 8.14 koji proširuje use-case od LIBSYS sistema u kojem korisnik povlači stavke iz biblioteke u elektronskom obliku. Na primjer, zamislite situaciju u kojoj bi studijski paketi prikazani na slici 8.13 mogli biti održavani elektronski i skinuti na računar studenta.

60

Slika 8.14 Primjer elektronskih stavki

U dijagramu sekvenci, objekti i aktori su poravnati uz vrh dijagrama. Označene strelice indiciraju operacije; sekvenca operacija je od vrha do dna. U ovom scenariju, korisnik pristupa katalogu biblioteke da vidi da li je stavka koja mu je potrebna dostupna elektronskom obliku, ako jeste, korisnik zahtijeva elektronski zahtjev za tu stavku. Zbog autorskog prava, to mora biti licencirano pa postoji transakcija izmeĎu stavke i korisnika u kojem je licenca dogovorena. Stavka koja će biti izdana je tada poslana u objekat mrežnog poslužitelja za kompresiju prije slanja korisniku.

8.5 Structured methods (SM)

Strukturni metod je sistematičan način pravljenja modela postojećeg sistema ili sistema koji se treba izgraditi. Prvi put su razvijeni 1970-e kao podrška analizi softtvera i dizajnu softvera, a evoluirali su 1980-ih i 1990-ih kao podrška objektno-orjentiranom razvoju. Ove objektno-orjentirane metode su se spojile sa predloženim UML-om kao standardni jezik modeliranja i sa Unified Process, a kasnije sa Rational Unified Process, kao pridruženi strukturni metod. Budgen sumira i poredi nekoliko ovih strukturnih metoda. Strukturne metode obezbjeĎuju framework za detaljne sisteme modeliranja kao dio iznošenja zahtjeva i analize zahtjeva. Većina strukturnih metoda ima svoj omiljeni skup modela sistema. One najčešće definišu proces koji se može iskoristiti za izvoĎenje ovih modela kao i skup pravila i uputa koje se primjenjuju na modele. Time se dolazi do standardne dokumentacije za sistem. CASE alati su obično dostupni za podršku metodama. Ovi alati podržavaju editovanje

61

(ureĎivanje) modela i kod kao i generisanje izvještaja, te obezbjeĎuju neke sposobnosti provjere modela. Strukturne metode su uspješno primjenjuju u mnogim velikim projektima. Mogu doprinijeti značajnom smanjenju troškova zato što se koriste standardanom notacijom (načinom obilježavanja) i osigurati pravljenje standardne dizajn dokumentacije. MeĎutim, strukturne metode sadrže i neke nedostatke :

- one ne obezbjeĎuju efektivnu podršku za razumnijevanje ili modeliranje nefunkcionalnih zahtjeva sistema.

- razlikuju se od drugih metoda po tome što obično ne uključuju upute koje će pomoći korisnicima da odluče da li je metoda odgovarajuća za odreĎeni problem. Niti uključuju savjete o tome kako bi se mogli prilagoditi upotrebi u odreĎenoj sredini.

- rezultat svega toga je pretežno previše dokumentacije. Suština zahtjeva sistema može da bude sakrivena u gomili detlaja koje metoda uključuje.

- rezultantni modeli su veoma detaljni, pa ih korisnik često nalazi teškima za razumjeti. Zato ovi korisnici ne mogu da provjere realnost ovih modela.

MeĎutim, u praksi, inžinjeri i dizajneri u svojim zahtjevima se ne ograničavaju predloženim modelom u bilo kojoj pojedinačnoj metodi. Naprimjer, OO metod pretežno ne predlaže da se treba uraditi dijagram toka podataka.Oni mogu direktno doprinijeti identifikaciji objekata (podacima koji teku kroz sistem) i identifikaciji operacija nad ovim objektima (transformacije). CASE alati za analizu i dizajn podržavaju kreiranje, ureĎivanje i analizu grafičkih notacija koje se koriste u strukturnim metodama. Slika 8.15 prikazuje komponente koje mogu da predstavljaju metod za podršku okruženju.

Slika 8.15 Komponente CASE alata za podršku strukturnoj metodi Sveobuhvatni metod podrške alatima, kao što je ilustrovano na slici 8.15, obično uključuje :

- Diagram editors (Editore dijagrama) koji se koriste za kreiranje modela objekata, modela podataka, modela ponašanja, itd. Ovi editori nisu samo alat za crtanje, ali su svjesni tipa entiteta na dijagramu. Oni uzimaju informacije o ovim entitetima i čuvaju ove informacije na centralnom repozitoriju.

- Design analysis and checking tools (Analiza dizajna i alati za provjeru) koji vrše obradu dizajna i javljaju greške i nepravilnosti. Ovo može da bude uključeno sa editovanjem sistema tako da se hvataju greške napravljene od strane korisnika u ranom stadiju procesa.

- Repository query languages koji dozvoljavaju dizajneru da pronaĎe dizajn i shodno tome informacije o dizajnu koje se nalaze na repozitoriju.

62

- Data dictionary (Rječnik) koji sadržava informacije o entitetima korištene u dizajnu sistema.

- Report definition and generation tools (Definisanje izvještaja i generisanje alata) koji uzimaju informacije iz centralne baze i automatski generiše sistemsku dokumentaciju.

- Forms definition tools (Alati za definisanje formi) koji omogućuju specificiranje skrivenih i dokumentiranih formata.

- Import/export facilities (Pogodnosti importa/exporta) koje omgućuju razmjenu informacija izmeĎu centralne baze i razvojnih alatima.

- Code generators (Generatori koda) koji automatski generišu kod ili skeleton koda iz dizajna spremljenog u centralnoj bazi.

Većina sveobuhvatnih CASE alata omgućuju korisnicima da generišu program ili dio programa pomoću informacije obezbijeĎene iz modela sistema. CASE alati često podržavaju različite jezike tako da korisnik može da generiše progreme napisane u C, C++ ili Java-i iz istog modela sistema. Zato što modeli isključuju detalje na niskom nivou, generator koda u dizajn workbench-u pretežno ne može da generiše cjelokupni sistem. Ponekad je potrebno ručno napisati kod ukoliko je potrebno dodati neke detalje gerisanom kodu.

Poglavlje 9 – Specifikacija kritičnih sistema Avion koji je 1993. sletio na aerodrom u Varšavi nije se uspio zaustaviti i na kraju je završio u obližnjoj banci, potom se zapalivši. Istraga je pokazala da je sa specifikacijiom sistema sve bilo u redu, ali iz nekog razloga kompjuterski sistem kočenja nije zaustavio avion 9 sekundi poslije njegovog slijetanja. Naime, sigurnosni sistem u avionu je isključio kočioni sistem dok je avion bio u zraku (jer je kočenje kod aviona u letu izuzetno opasno) i nije prepoznao kada je avion sletio na pistu, pa nije ni uključio kočioni sistem. Ovaj primjer najbolje opisuje važnost specifikacije kritičnih sistema. Greška u specifikaciji ovih sistema može donijeti daleko veće štete i posljedice nego kod ostalih sistema. Pouzdanost sistema u slučaju loše specifikacije neće biti zadovoljavajuća, čak ni ako je razvojni proces sistema bio izuzetno dobar. Iz potrebe pouzdanosti istema proističu 2 vrste zahtjeva:

- funkcionalni: ovakvi zahtjevi mogu definisati način provjere grešaka u sistemu i način njihovog otklanjanja,

- nefunkcionalna ograničenja mogu definisati standarde za sigurnost i pouzdanost ovih sistema.

Ova ograničenja donose sa sobom i mnoga druga ograničenja koja je teško kvalifikovati kao funkcionalna ili nefunkcionalna. Ovo su ograničenja 'ne bi trebalo' tipa, gdje se eksplicitno navodi šta sistem ne bi trebao raditi vezano za pouzdanost i sigurnost (npr. Korisnici ne bi trebali moći mijenjati prava pristupa dokumentima koji oni nisu kreirali). U fazi dizajna ili implementacije, ova ograničenja se najčešće tansformaišu u funkcionalana ili nefunkcionalna. Specifikacija kritičnih sistema se uvijek obavlja u prirodnom jeziku, uz dodatne dijagrame.

Rizikom upravljana specifikacija

Specifikacija kritičnih sistema „dodaje“ specifikaciji nekritičnih sistema stavku za upravljanje rizikom i detaljnu specifikaciju pouzdanosti sistema. Developeri kritičnih sistema koriste rizikom upravljanu specifikaciju. Postoje 2 vrste kritičnih sistema: „safety-critical“ (safety bi se prije

63

prevelo kao pouzdanost), gdje propusti i greške u specifikaciji mogu dovesti do nesreće) i „security-critical“ (sistemi kod kojih nepouzdanost može omogućiti „lakši“ napad na sistem). Postoje 4 faze u pravljenju rizikom upravljane specifikacije:

- identifikacije rizika, gdje se otkrivaju potencijalni rizici, - kategorizacije rizika, gdje se otkriveni rizici razvrstavaju u kategorije, neki se mogu i

odbaciti zbog redudantnosti, zbog toga što se nikada neće pojaviti i sl, - istraživanje korijena rizika, odnosno okolnosti pod kojima bi rizik mogao prerasti u

stvarnost, - predlaganje mjera za otklanjanje/zaštitu od rizika.

Svaka od ovih fza daje svoj izlazni dokument (opis rizika, specifikacija rizika, analiza rizika, prijedlog za otklanjanje rizika).

Identifikacija rizika Cilj identifikacije rizika je da se pronaĎu svi rizici od kojih dolazi opasnost u sistemu. To je prva faza pravljenja rizikom upravljane specifikacije. Ova faza može biti jako teška, posebno kod kompleksnih sistema, jer se većina rizika pojavljuje iz interkacije sistema sa „čudnim“ (ne znam kako bih preveo „rarely“ u ovom kontekstu) okruženjem. Postoje različite klase opasnosti od rizika kod „safety-critical“ sistema: fizički, biologijski, električni, opanost od otkazivanja servisa u sistemu itd. Npr., u sistemu za doziranje pacijenta inzulinom preko pumpe postoje sljedeće opasnosti/rizici koji mogu izazvati nesreće sa tragičnim posljedicama:

- može biti loš kontakt izmeĎu inzulin pumpe i aktuatora (fizička), - baterija se može ispraznisti i tako sistem isključiti (električna), - mogo postojati alergije pacijenta na inzulin pumpu (biologijska), - može doće do premalog/prevelikog doziranja inzulina (greška u servisu sistema)...

Iskusni inžinjeri najčešće rade specifikaciju kritičnih sistema u timu u kojem se nalaze i domenski eksperti, inžinjeri koji su ranije radili sa ovakvim sistemima i imaju iskustva u tome i profesionalni sigurnosni savjetnici. Na ovaj način moguće je specifikaciju dovesti do jednog dovoljno visokog nivoa, jer je optimalni nemoguće postići.

Analiza i klasifikacija rizika

U drugoj fazi pravljanja rizikom-upravljane specifikacije kritičnih sistema vrši se analiza otkrivenih rizika, kojima se dodjeljuje odgovarajuća vjerovatnoća pojave i stepen uticaja na okruženje u kojem sistem radi. Ovo treba da bude baza za odreĎivanje mjera za suzbijanje rizika. Rizici mogu biti kategorisani na 3 načina:

- rizici sa nultom tolerancijom – izuzetno opasni rizici, koji u slučaju da se ispune mogu dovesti do velikih materijalnih šteta, gubitka ljudskih života i sl, i koji se nikako ne bi smjeli dogaĎati u sistemu,

- rizici koji se mogu prihvatiti ako se rijetko ili razumno malo pojavljuju – primjer je pad web stranice na e-commerce sistemu,

64

- rizici koji su prihvatljivi – to su oni rizici kod kojih je cijena otklanjanja štet uzrokovane rizikom manja od cijene prevencije od rizika.

Ove kategorije se sa vremenom mijenjaju. Npr. U 60-70.-im je bilo nedopustivo da neke fabrike izbacuju štetne otrove u atmosferu (to je bio rizik nulte tolerancije). Danas je to sasvim normlano i fabrici je jeftinije da „počisti“ stvari kada se to desi (rijetko se dešava), nego da poduzme skupu proceduru suzbijanja ovog zagaĎenja. Na slici je prikazan trokut koji prikazuje 3 vrste rizika:

Što je veća širina trougla, to je cijena rizika (ukoliko se rizik ispuni) veća. Još dva parametra koja se trebaju dodijeliti svakom riziku su vjerovatnoća pojavljivanja i stepen uticaja na okolinu, odnosno štete koju proizvodi ako se desi. Ovi parametri se često izražavaju „fuzzy“ vrijednostima: ponekad, rijetko, često, osrednje, češće... Zato je dobro u radu sa stručnjacima dodijeliti ovim „fuzzy“ vrijednostima numeričke ekvivalencije, radi jednostavnosti analize rizika.

Dekompozicija rizika Dekompozicija rizika je faza u kojoj se pronalaze „korijeni“, uzroci zbog kojih dolazi do rizika. Tehnike dekompozicije uglavnom su preuzete iz modela razvoja „safety-critical“ sistema. Analiza strukture rizika može biti induktivna ili deduktivna. Induktivna, koja je jednostanija, koristi „top-down“ pristup, gdje se kreće od rizika i traže se dogaĎaji koji mogu prouzrokovati da se rizik ostvari u jednoj hijerarhiji, Za razliku od ove tehnike, deduktivna („bottom-up“ pristup) polazi od grešaka u sistemu (različitih načina ostvarenja rizika) i u hijerarhiji ide do rizika koji su uzrok tog dogaĎaja/greške u sistemu. Postoji više pristupa za samu analizu: formalna logika, drvo grešaka, check-liste... Na slici je dat primjer drveta gešaka za slučaj doziranja inzulina:

65

Dakle, korijen drveta (element na vrhu) je opasnost/rizik koji se može desiti. Zatim nalazimo dogaĎaje koji mogu dovesti do greške/ispunjenja rizika, zatim dogaĎaje koji vode do tih dogaĎaja... i tako sve dok na naĎemo „korijensku“ grešku. Kod ovog pristupa, za svaki rizik pravimo jedno drvo. Ovo je pojednostavljen primjer i u praksi su ova drva mnogo kompleksnija.

Mjere za suzbijanje rizika

Postoje 3 strategije za upravljanje rizikom:

- izbjegavanje rizika (ne bavimo se uopšte ovim pitanjem), - detekcija i otklanjanje štete, - minimiziranje štete nastale ako se rizik ostvari.

Softver inžinjeri obično koriste kombinaciju ova 3 pristupa. Npr., neki netolerantni rizici se mogu preventirati minimizirajući njihove štete i praveći sigurnosni servis koji pravi backup podataka sistema, u slučaju da ipak doĎe do ostvarivanje rizika. U toku razvoja samog sistema može doći do 2 vrste grešaka (primjer sa inzulinom):

- aritemetička greška – lako se može otkriti, nastaje zbog greške u proračunu doze inzulina koju je potrebno dati pacijentu,

- algoritamska greška, teže se otkriva jer ne postoje anomalijske situacije koju mogu biti otkrivene.

Specifikacija o pouzdanosti

Najprije digresija na prevod termina „safety“ i „security“ sa englesog. Mnogi pojmovi sa engleskog nemaju tačan prevod na našem jeziku, pa tako i ova 2 pojma. „Safety“ je prije poudanost nego sigurnost. Npr. „safety“ je vjerovatnoća da će hakeri provaliti šifre korisnika na

66

e-commerce sistemu, dok je „security“ više sigurnost, odnosno odgovara na pitanje da li je ikako moguće da hakeri doznaju ove šifre. Na ispitu bi mogli pisati ove pojmove i na našem i na engleskom. Proces upravljanja rizikom, razmotren u prethodnom poglavlju je evoluirao iz procesa razvoja „safety-critical“ (ovo ne bih prevodio) sistema. U 80-im i 90.-im, kada su se računari počeli puno više koristiti, porastao je i broj ovih „safety-critical“ sistema. Tako je „sigurnosna“ injžinjerska zajednica napravila standarde o specifikaciji i razvoju „safety-critical“ sistema. Jedan takav je IEC 61508. Ovaj standard je prvobitno razvijen isključivo za sisteme kao što je sistem koji zaustavlja voz kada on proĎe kroz crveno svjetlo. MeĎutim, kasnije se počeo mnogo više koristiti. Specifikacija o poudanosti sistema se svakako ne bi trebala razdvajati od opše specifikacije sistema. Na slici je dat model razvoja sistema po IEC 61508 standardu:

Proces pravljanja specifikacije i potvrde o pouzdanosti sistema je dio ukupnog životnog ciklusa razvoja pouzdanog sistema. Na slici je prikazana Redmilova prezentacija ovog životnog ciklusa:

67

Kao što se vidi na slici, ova prezentacija obuhvata sve faze u životnom ciklusu jednog softverskog/informacionog sistema, od specifikacije opsega sistema pa sve do uklanjanja sistema iz upotrebe. U ovom modelu kontrolni sistem kontroliše opremu koja je sastavni dio sistema i koja je povezana sa zahtjevima u pouzdanosti na visokom novou. Ovi zahtjevi o pouzdanosti opreme generišu još 2 vrste zahtjeva:

- funkcionalni zahtjevi o pouzdanosti koji definišu funkcije kojim će sistem omogućiti pouzdanost,

- zahtjevi na poudanost cjelokupnog sistema, kao što su zahtjevi na dostupnost i oporavljivost (mogućnost oporavka nakon pada).

U ranim fazama ovog životnog ciklusa se odreĎuje opseg sistema (oprema koja je u vezi sa sistemom i njeni zahtjevi na pouzdanost), procjenjuju se moguće opasnosti i rizici koji iz njih proizilaze, odreĎuju se zahtjevi na pouzdanost i dodjeljuju pojedinim komponentama unutar sistema (opremi). U paraleli sa razvojem sistema vrši se planiranje upravljanja pouzdanošću. Vrši se procjena i načini za suzbijanje eksternih rizika (koji dolaze od okruženja) i planiranje validacije, korištenja, instalacije i održavanja sistema sa aspekta pouzdanosti. Nakon toga se sistem validira i instalira prema prethodnom planu i uvodi se u upotrebu. Tu ne prestaju zahtjevi za pouzdanošću, jer dosta problema nastaje zbog lošeg održavanja sistema. Čak izbacivanje sistema iz upotrebe treba raditi prema planiranoj proceduri (npr. Ne možemo samo počupati kablove i demontirati opremu prilikom uklanjanja kočionog sistema za avion, jer je taj sistem povezan sa mnogim drugim).

Sigurnosna specifikacija

Sigurnosna specifikacija i specifikacija o pouzdanosti imaju nešto zajedničko. Niti jedna niti druga se ne mogu mjeriti kvantitativno (kvantitativnim paramterima). Mnogi zahtjevi u sigurnosnoj specifikaciji su „ne bi trbealo“ tipa, tj. oni specificiraju neprihvatljive funkcionalnosti, odnosno pojave u sistemu, a ne funkcionalnosti koje bi on trebao obavljati. MeĎutim, postoje i mnoge razlike:

- modeli i standardi pravljanja specifikacije o pouzdanosti su dobro istraženi, dok su takvi modeli za sigurnosnu specifikaciju novi i o njima se jako malo zna,

- sigurnosne prijetnje po mnoge tipove sistema su jako slične za veliki broj sistema (recimo zaraženost virusom ili DoS napad). Ovo ne vrijedi za „safety-critical“ sisteme kod kojih su područje primjene, pa samim tim i sigurnosne prijetnje specifični i variraju od sistema do sistema,

- tehnike i tehnologije za primjenu u poboljšanju sigurnosti sistema su dosta stare, ali da bi se one koristile, potrebno je imati velike tehničko i tehnološko znanje. Npr. može biti dosta komplikovano instalirati i održavati ureĎaje za enkripciju podataka ili autentifikaciju na sistem. Ovdje se često prave sigurnosni propusti,

68

- dominantnost nekih proizvoĎača softvera može učiniti sigurnosne prijetnje na sisteme univerzalnim (sigurnosni propusti softvera koji prave isti ljudi su slični). Ovo ne vrijedi za „safety-critical“ sisteme, jer su oni uglavnom specifični po primjeni i razvojnom procesu.

Pristup analizi sigurnosti kod kompjuterskih sistema je sličan kao i kod fizičkih sistema. Zaštita entiteta koji su kritični mora biti veća od onih nekritičnih. Npr. sigurnost u banci je veća u onim

poslovnicama gdje se nalaze veće količline novca (misli se na fizičku sigurnost, Gama ). Na slici je prikazan jedan primjer procesa sigurnosne specifikacije sistema:

Faze su:

- identifikacija entiteta u sistemu (podataka i programa) i njihove vrijednosti sa aspekta sigurnosti (vrijedniji su oni programi na koje postoji veća mogućnost napada ili čiji pad donosi katastrofalne posljedice),

- analiza prijetnji i dodjeljivanje rizika svakoj od prijetnji (dodjeljujemo prijetnjama mogućnost da se one ostvare),

- dodjela prijetnji/rizika identificiranih u prethodnoj fazi odgovarajućim entitetima u sistemu,

- analiza tehnika i tehnologija za sprječavanje ovih prijetnji. - Sigurnosna specifikacija (spisak prijetnji po sistem, sa opisom entiteta na koje se one

odnose i tehnika/tehnologija koje se mogu koristiti za njihovo suzbijanje). Različiti tipovi sigurnosnih zahtjeva odnose se na različite prijetnje na sistem. Firesmith daje listu od 10 tipova ovih zahtjeva koji se mogu navesti u specifikaciji:

1. Zahtjevi na identifikaciju (da li sistem mora identifikovati korisnika prije interakcije sa njim),

2. Zahtjevi za autentifikaciju (kako se korisnici identificiraju), 3. Zahtjevi za autorizaciju (specificiraju privilegije i prava pristupa za idntifikovane

korisnike), 4. Zahjtjevi za „imunitet“ (kako se sistem treba zaštiti od virusa, crva...), 5. Zahtjevi za integritet (kako se može izbjeći oštećenja podataka), 6. Zahtjevi za detekciju napada (specificiraju kako se može detektovati napad na sistem), 7. Zahtjevi za neporecivost (da korisnik ne može poreći da je bio uključen u neku

transakciju, npr.log tabele u bazi podataka),

69

8. Zahtjevi na privatnost (kako će se održavati privatnost podataka), 9. Zahtjevi za provjeru sistema (provjera da li je narušena sigurnost), 10. Sigurnosni zahtjevi za održavanje sistema.

Ne koriste se uvijek svi ovi zahtjevi. Oni se koriste zavisno od tipa sistema, vrste okruženja u kojem će sistem raditi i vrste očekivanih korisnika sistema.

Specifikacija oporavljivosti sistema

Oporavljivost sistema je pojdam koji se odnosi na sistem u cjelini, a ne njegove pojedine komponente. Zato se i specifikacija oporavljivosti praivi za cjelokupan sistem, a ne njegove dijelove. Razlog je u povezanosti komponenata sistema. Pad jedne komponente često utiče i na druge, pa je nemoguće posmatrati odvojeno pojedine komponente sistema sa ovog aspekta. Postoje 3 dimenzije oporavljivost:

- Hardverska – odnosi se na probleme u sistemu izazvane problemima sa hardverom, - Softverska – odgovar napitanje koliko često će izlaz iz sistea biti pogrešan (jeftinija od

hardverske, jer se problemi u softveru najčešće mogu riješti manjim korekcijama, dok npr. ako smo izabrali skromnu hardversku platformu i stavili kompleksan sistem da se izvršava na njom, izvršavanje može iči dosta sporo. Za rješavanje ovog problema možda će biti potrebna potpuno nova hardverska platforma ili će biti potrebno raditi sistem ponovo od samog početka),

- Operativna – odnosi se na greške koje nastaju zbog pogrešnog rukovanje sistema, pogrešan unos i sl.

Ove 3 vrste grešaka su usko povezane. Hardver može generisati signale koji su izvan dometa očekivanih signala softvera, zbog čega softver počinje da se ponaša neuobičajno, što može uzrokovati da operater u stresnoj situaciji unese neispravne ulazne vrijednosti, što opet dovodi do neuobičajnog ponašanja softvera i tako ukrug. Zahtjevi u speficikaciji oporavljivosti su uglavnom nefunkcionalni, ali iz njih mogu nastati neki funkcionalni zahtjevi ili zahtjevi vezani za dizajn. Ovi zahtjevi su uglavnom izraženi kvantitativno mjerilima koji će biti spomenuti u narednom poglavlju. Primjeri ovih zahtjeva:

- U programu mora postojati provjera ulaznih podataka (provjera nihove pripdanosti skupu predefinisanih vrijednosti),

- Prije inicijalizacije, mora se provjeravati da li je bilo koji blok na bilo kojem disku ostećen,

- ... Nema jednostavnih šablona za izvoĎenje funkcionalnih zahtjeva. U organizaciji koja razvija kritične sisteme obično postoje neka znanja o najčešćim zahtjevima na oporavljivost. Uglavnom se organizacije bave razvojem kritičnih sistema u specifičnoj domeni primjene (npr.sistemi za upravljanje vozom), pa imaju neka unverzalna znanja iz specifikacije oporavljivosti, koja mogu primijeniti na mnoge podvrste ovakvih sistema.

70

Metrike za mjerenja oporavljivosti

Oporavljivost sistema je najprije uvedena kod hardverskih sistema. Za te sisteme, vrlo moguća su mehanička oštećenja ili pregirijavanje hardvera, što dovodi do otkaza sistema. Za hardverske sisteme, glavne metrike za oporavljivost su: MTTF (mean time to failure – vrijeme za koje se očekuje da će sistem raditi korektno, odnosno vrijeme izmeĎu 2 pada sistema), MTTR (mean time to repair – vrijeme potrebno za oporavaka sistema nakon pada). Ove metrike se ne mogu direktno prenjeti na softverske sisteme, jer je kod njih pad uglavnom trenutan i prolazan, a ne stalan (ako se desio pad zbog neispavnog unosa i podaci nisu oštećeni, sistem se može odmah oporaviti i nastaviti rad -> „end now“ i pnovno pokretnje). Glavne metrike za oporavljivost kod softverskih sistema su:

- POFOD (probability on failure on demand – vjerovatnoća da će sistem pasti prilikom nekog zahtjeva koji korisnik uputi na njega),

- ROCOF (rate of failure occurence – učestalost pojave pada sistema), - MITF (mean time to failure – vrijeme izmeĎu 2 pada), - AVAIL (availibility – vjerovatnoća da je sistem dostupan kada mu se pristupa).

Sve ove metrike se mogu (i poželjno je) izraziti nekim brojem. Npr.MITF se može iskazivati kao vremenski period izmeĎu 2 pada sistema ili broj transakcija koje sistem obavi izmeĎu 2 pada ili ... (budite kreativni ).

Nefunkcionalni zahtjevi na oporavljivost

Jako često speciikacije zahtjeva na oporavljivost nije dobro napisana. Nisu dobro identifikovane i analizirane prijetnje, ili metrika koja se koristi za njihovo iskazivanje nije dobra. Npr. broj padova sistema/1000 linija koda nije dobra metrika za iskazivanje bilo koje prijetnje u sistemu. Padovi sistema mogu se podijeliti na: one koje uzrokuju sštećenja podatka, one koje ne uzrokuju oštećenja podataka, prolazne, stalne, one od kojih je moguć oporavak i one od ojih nije moguć oporavak. Koraci u pravljnju specifikacije oporavljivosti su:

- Identifikovanje mogućih tipova podova sistema za svaki podistem unutar sistema, - Analiza ovih prijetnji i njihova klasifikacija, - Za svaku klasu definisanu u prethodnom koraku, napisati jedan ili više zahtjeva

oporavljivosti i metrike kojim se oni iskazuju, - Kada je moguće, identifikovati funkcionalne zahtjeve za oporavljivost koji opisuju

funkcionalnosti sistema koji će smanjiti vjerotnoću nekoog tipa pada sistema.