PROJEKTIRANJE INFORMACIJSKIH SUSTAVA Sustav je grupa objekata/entiteta vezanih meusobnim odnosima s ciljem ostvarivanja nekog cilja.

Granica sustava definira opseg i domaaj sustava. Granice se s vremenom mogu mijenjati, s utvrene su prirodno ili proizvoljno. Okolina je sve to je izvan granica sustava. Tie se sustava jer je s njim u vezi, bilo da od sustava prima izlaze ili u sustav alje ulaze. Ulazi i izlazi su nain kako sustav uspostavlja veze sa svojom okolinom. - S jedne strane materija, energija i informacije ulaze u sustav iz okoline. - S druge strane izlaze iz sustava u izmijenjenom obliku. Informacija injenica/zapis o dogaaju ili pojavi i sadri sintaksu (formu) i semantiku (sadraj) Podatak informacija u strojno obraenoj formi i naglasak je na specifikaciji sintakse Znanje sadri pragmatinu dimenziju primjene informacija i povezano je s ciljem i svrhom. Veza podatak, informacija znanje: Podatak je sirova injenica koja predstavlja neku istinu iz stvarnog svijeta. Informacija je proien, organiziran i obraen podatak u smislenom kontekstu. Znanje se gradi na temelju novih informacija koje se nadovezuju na postojee znanje. Isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u ovisnosti o njihovom znanju Informacijski sustav je grupa ljudi, procesa, podataka, mrea i tehnologija stvorena da rijei organizacijske probleme ili da stvori nove prilike. Zadaa informacijskog sustava: - Prikupljanje - Obrada - Pohranjivanje - Distribucija podataka Vrste informacijskih sustava: - Obrada podataka - Uredski poslovi - Podrka odluivanju - Ekspertni sustav - Posebna podruja Komponente informacijskog sustava: - Hardware tehnika oprema - Software programska oprema - Orgware organizacijska komponenta - Lifeware izvritelj - Netware komunikacijska infrastruktura - Dateware podatkovna razina Projektiranje i izgradnja IS: Bit projektiranja je MODELIRANJE. Pristup ovisi o zateenom stanju (malo je green field projekata!). Postoji velika interakcija izmeu faza System Development Life Cycle (SDLC) odnosno ivotni ciklus razvoja sustava sastoji se od etiri sljedee faze:

a) PLANIRANJE Ova faza je proces razumijevanja zato informacijski sustav treba biti izgraen. Takoer se u ovoj fazi izgrauje projektni tim koji e suraivati u izgradnji informacijskog sustava. Ova faza sastoji se od dva koraka planiranja: 1. Inicijacija projekta kako smanjiti trokove ili poveati prihode 2. Upravljanja projektom (Projekt menadment) menader projekta napravi poslovni plan i uvodi tehnike koje pomau projektnom timu kontrolirati projektom kroz cijeli SDLC b) ANALIZA Faza analize odgovara na pitanja kao to su: Tko e koristiti sustav? to e sustav raditi? Gdje i kada e se sustav koristiti? Za vrijeme trajanja ove faze projektni tim istrauje postojee sustave, istrauje dozvoljene mogunosti i razvija koncept za novi sustav. Ova faza sastoji se od tri koraka: 1. Analiza strategije ukljuuje analizu postojeih sustava 2. Prikupljanje zahtjeva analiza ovih informacija vodi razvoju novog sustava 3. Prijedlog sustava (System proposal) prezentira se projektnim sponzorima i ostalim kljunim pojedincima koji odluuju o tome da li projekt treba nastaviti. Prijedlog sustava opisuje s kojim e se poslovnim zahtjevima susresti novi sustav. c) DIZAJN U ovoj fazi odluuje se: kako e sustav funkcionirati u uvjetima hardvera, softvera i mrene infrastrukture; korisnika suelja; forme i izvjea koja e se koristiti; programi, baze podataka i datoteke koje e biti potrebne. Faza dizajna ima etiri koraka: 1. Strateki dizajn hoe li sustav biti razvijan unutar neke tvrtke ili van nje? 2. Dizajn arhitekture opisuje hardver, softver i mrenu infrastrukturu koja e se koristiti 3. Karakteristike baza podataka i datoteka ovi dokumenti odreuju koji podaci i gdje e biti pohranjeni 4. Dizajn programa definira koji programi trebaju biti napisani to e oni raditi d) IMPLEMENTACIJA U ovoj fazi sustav je ve nabavljen ili razvijen. Ova faza obino najdulje traje i najskuplji je dio procesa. Sastoji se od tri koraka: 1. Izgradnja je sustava sustav je izgraen i testiran kako bi se uvjerili da djeluje onako kako je dizajniran 2. Instalacija pripremiti podrku za instalirani sustav 3. Plan podrke ukljuuje poslije-implementacijsko izvjee (ispitivanje) Metodologije razvoja sustava Metodologije su formalizirani pristup razvoju SDLC-a: a) Process-centered metodologija Kod ove metodologije panja je usmjerena na definiranje aktivnosti povezanih sa sustavom. Usredotoena je na predstavljanje sustava kao skupa procesa sa informacijama koje ulaze u procese i koje iz njih izlaze. b) Data-centered metodologija Ova metodologija panju posveuje definiranju sadraja podataka u memoriji i kako su oni organizirani. Ova metodologija koristi podatkovni model kao jezgru sustava. c) Object-oriented metodologija Ova metodologija nastoji balansirati arite izmeu procesa i podataka. UML (Unified Modeling Language) je opi jezik modeliranja. Koristi se za opisivanje sustava kao skupa objekata koji objedinjuju i procese i podatke.

Kategorije metodologija razvoja sustava Prva kategorija metodologija razvoja sustava: Structured Design Strukturno dizajnirana metodologija korak po korak pribliava se SDLC-u pomiui se od jedne faze do druge a) Waterfall development (vodopadni razvoj) Sa ovom metodologijom analitiari i korisnici idu slijedno od jedne faze do sljedee. Prednosti su: - Zahtjevi sustava su odreeni prije nego zapone programiranje - Promjene zahtjeva su minimalne kako se projekt nastavlja Nedostaci: - Dizajn mora biti potpuno odreen prije nego programiranje pone - Proe puno vremena od prijedloga sustava u fazi analize do isporuke sustava - Zahtjevi moraju biti jako dobro shvaeni i samo tada se moe koristiti - Zahtjevi moraju biti jako dobro shvaeni , samo se tada moe koristiti ovaj model

b) Paralelni razvoj (Parallel development) Ova metodologija nastoji smanjiti dugi vremenski interval izmeu faze analize i isporuke sustava.

Jedan projekt podijeljen je u slijed razliitih podprojekata.

Druga kategorija metodologija razvoja sustava: Rapid Aplication Development (RAD) RAD-Based metodologija prilagoava SDLC fazu za bre dostavljanje dijelova razvijenog sustava korisniku u ruke. Veina RAD-Based metodologija preporuuje analitiarima koritenje posebnih tehnika i kompjuterskih alata za ubrzanje analize i implementacije, kao to je CASE alat (computer-aided software engineering). Mogui problem sa RAD-Metodologijom je upravljanje korisnikim oekivanjima. a) Fazni razvoj (Phased development) Ova metodologija razbija cijeli sustav u vie serija koje se razvijaju slijedno (sekvencijalno). Tim razdjeljuje zahtjeve u slijed verzija, a zatim najvanije i osnovne zahtjeve grupira u prvu verziju sustava. Kada je verzija zavrena, tim zapoinje rad na novoj.

b) Prototip (Prototyping) Prototypingbased metodologija obavlja analiza, dizajn i implementaciju istovremeno. Sve tri faze obavljaju se ponavljano u krug sve dok se sutav ne izvri. PROTOTIP je manja verzija sustava sa minimalnom koliinom mogunosti.

PREDNOST: Omoguava komunikaciju korisnika sa sustavom ak i ako on nije spreman za upotrebu. NEDOSTATAK: Odluke o dizajnu esto se pokau loima

c) Throwaway Prototyping Ova metoda slina je Prototyping-based metodologiji, a glavna razlika je da se prototip informacijskog sustava zavri tijekom druge faze SDLC-a.

Trea kategorija metodologija razvoja sustava: Agile Development Ova kategorija fokusira se na eliminaciju pretjeranog modeliranja i dokumentiranja, te vremena utroenog u to. Projekt istie jednostavne, iterativne aplikacijske razvoje, a najpoznatije metode su: XP (Extreme Programming), Srum, Crystal, DSDM (Dynamic System Development Method), Lean Development, FDD (Feature Driven Development). a) Extreme Programming (XP) etiri kljune vrijednosti: - Komuikacija - Jednostavnost - Povratna veza (feedback) - Hrabrost Kljuna naela XP-a: - Neprekidno testiranje - Jednostavno kodiranje - Zatvorena interakcija sa krajnjim korisnikom omoguava izgradnju sustava veoma brzo

Zakljuak: - Ako je sustav sloen najbolje je odabrati Phased development based metodologiju - Ako vodimo rauna o pouzdanosti najbolja je Throwaway Prototyping based metodologija - Za kratkotrajne rasporede biramo RAD based metodologiju Sposobnosti projektnog tima i uloge:

Projekt mora sadravati razliito sposobne individualce da bi sustav bio uspjean. Analitiar zato mora imati est glavnih vjetina: 1. Tehninost 2. Poslovnost 3. Analitinost 4. Moralnost 5. Mora biti dobar menader 6. Mora biti interpersonalan Kategorije analitiara: 1. Poslovni analitiar 2. Sistemski analitiar 3. Infrastrukturni analitiar 4. Analitiar promjenjivog menadmenta (upravljanja) 5. Projektni menader b) Scrum: je iterativni, inkrementirajui proces za razvoj bilo kakvog produkta ili upravljanje bilo kakvim poslom. On proizvodi set upravljakih funkcionalnosti na kraju svake iteracije. Scrum je agilni proces za upravljanje i kontrolu razvojnog posla. Ima timski pristup, poboljava komunikaciju i maksimizira kooperaciju, te poveava produktivnost.

Ostali modeli: a) Evolucijski model Prvo rjeenje Evolucijski model razvoja softvera odgovor je na glavne faktore rizika u dosadanjim Specifikacija softverskim projektima. Kako bismo Grubi opis odgovorili na glavne faktore rizika, posebnu Razvoj Meurjeenje zahtjeva pozornost posveujemo korisnikim Provjera zahtjevima, nadogradnji i promjenama zahtjeva, a istovremeno i dosljednom Konano rjeenje potivanju rokova. Softver se razvija u ciklusima, gdje svaki ciklus dograuje funkcionalnost aplikacija. Korisnik u svakom od ciklusa ocjenjuje RAD I ODRAVANJE prihvatljivost rjeenja i moe postaviti dodatne zahtjeve. Prioritetni i realni zahtjevi se uvijek rjeavaju prvi. Evolucijski model razvoja softvera se najee koristi kod manjih projekata ili za razvoj nekog podsustava. Omoguava realizaciju sustava sa loijom specifikacijom zahtjeva. Prednost je u vremenu trajanja (kree se odmah u posao, tijekom rada se rjeavaju problemi). Nedostatak je loa vidljivost prilikom razvoja, jer ovaj model razvoja daje rjeenje bez arhitekture. b) Iterativni model Iterativni pristup podrazumijeva podjelu problema na manje dijelove, faze traju krae, za svaki dio se prou sve faze, bre se dolazi do softvera koji
Iteracija 1 Iteracija 2 Iteracija 3

korisnik moe probati, ali je i loija dokumentacija. Ovaj model kombinira elemente vodopadnog s iterativnim evolucijskim pristupom. Prednost ovog modela je to se tijekom cijelog razvojnog ciklusa vri stalna provjera. Nedostaci su potreba za ranim definiranjem arhitekture, greke u jednoj iteraciji se propagiraju na druge. Ovaj model onemoguava fleksibilan odnos s naruiteljem. c) Spiralni model Karakteristike spiralnog modela razvoja softvera su da razvoj projekta ide po fazama i cilj je smanjiti rizik projekta. Ovaj model ima oblik spirale tj. u jednoj spirali izgrauje se jedan dio sustava ili poveava njegova funkcionalnost. Predstavlja iterativni pristup razvoju softvera a ujedno i nadograuje evolucijski model. Na poetku svake faze provodi se procjena rizika. Nastoji se identificirati mogue rizike i razrijeiti ih prije nastavka (uklanjanjem ili svoenjem na najmanju moguu mjeru). U sluaju da je rizik prevelik, projekt se prekida. Prednosti ovog modela su da kontrolira rizike, omoguava uklapanje u postojei model razvoja i dobar je za velike i sloene projekte. Nedostaci su to zahtijeva veliko struno znanje prilikom procjene rizika , visoko domensko i upravljako znanje. Spiralni model je relativno novi model koji se tek treba dokazati u velikim projektima pa je teko odrediti njegove dobre i loe strane. Primjenjuje se u projektima u kojima se oekuju razni problemi s tehnologijom, ljudima, tritem i okolinom. Pogodan je za izgradnju velikih sustava te u projektima u kojima provoenje analize rizika ne predstavlja preveliki relativni troak.
Analiza d) Komponentalni model Definiranje Modifikacij Dizajn komponent Osnovna ideja ovog modela je da se dobro zahtjeva a zahtjeva sustava i dizajnirane i implementirane objektno orijentirane klase mogu vie puta koristiti u razliitim aplikacijama i arhitekturama. Razvoj i Validacija Razvoj je baziran na komponentama integracija sustava (Component Based Software Development). Komponenta moe oznaavati dio programa koji se moe izvriti na logikom ili fizikom nivou, jedno ili vie suelja, jedinstveni identifikator Prednosti komponentalnog modela razvoja softvera su u utedi vremena i trokova, brza je demonstracija sustava, poveava se produktivnost. Glavni nedostatak ovog modela razvoja je da nestaju generika znanja.

Ope aktivnosti softver projekta: - Specifikacija: to sistem treba raditi i razvojna ogranienja - Razvoj (dizajn i implementacija): stvara softverski sistem - Provjeravanje: formalni dokaz ispravnosti SW algoritama - Validacija (potvrivanje): provjeravanje da li je softver ono to kupci ele

Izgradnja: promjena softvera kao odgovor na promjenjive zahtjeve Projekt

PROJEKET - Vremenski ogranien skup radnji poduzet radi stvaranja jedinstvenog proizvoda (ili usluge) Operacije su: - neprekidne - mogu se ponavljati - svrha im je podupiranje i odranje poslovanja, ak i kada se ciljevi promijene Upravljanje projektom je primjena znanja, vjetina, alata i tehnika u projektnim aktivnostima da bi se ispunili projektni zahtjevi. Upravljanje projektom ukljuuje: - utvrivanje zahtjeva, - postavljanje jasnih i ostvarivih ciljeva, - uspostavu ravnotee izmeu suprotstavljenih zahtjeva na kvalitetu, doseg, vrijeme i troak, - prilagodbu specifikacija, planova i pristupa interesima i oekivanjima razliitim zainteresiranim stranama (eng. Stakeholders). Izvori pogreaka u SW: a) Prikupljanje zahtjeva: 56% b) Modeliranje: 27% c) Programiranje i testiranje: 7% d) Ostali imbenici: 10% Kritini faktori uspjeha: - Podrka menadera - Jasni ciljevi i opseg - Kompletan projektni tim i organizacija - Treniranje i edukacija korisnika - Efektivna komunikacija - Projekt menadment - Analiza zadataka - Izbor arhitekture - Sudjelovanje korisnika - Promjenjivo upravljanje Programsko inenjerstvo je inenjerska disciplina koja se bavi praktinim problemima razvoja velikih programskih sustava. Programska oprema: - Programska podrka - Dio raunalnog sustava koja nema fizikih dimenzija - Opi pojam za sve vrste programa, programskih jezika, Raunalna aplikacija: - Namjenski program, programska oprema - Raunalno podrano rjeenje jednog ili vie poslovnih problema ili potreba - Informacijski sustav uobiajeno sadri jednu ili vie raunalnih aplikacija

Informacijska tehnologija: - Bilo koji oblik tehnologije koju ljudi koriste za upravljanje informacijama - Danas: raunalna tehnologija (HW i SW) telekomunikacijskih tehnologija Informacijsko inenjerstvo Metoda: - Smiljen i organiziran skup procedura izrade - Sugerira proces obavljanja i nain biljeenja - Definira primjenu tehnika i njihovo povezivanje Tehnika: - feature metode - Definira nain izvrenja odreenog postupka i dokumentiranja njegovog rezultata - Kae kako se neka aktivnost provodi Pomagalo: instrument, sredstvo koje se koristi u razvoju IS-a ISO 9126 je standard za procjenu kvalitete softvera, postavlja ciljeve kvalitete za softver i za njegove neposredne proizvode te se moe koristiti kao kontrolna lista Definira est karakteristika kvalitete softvera koje se mogu koristiti u evaluaciji softvera - Funkcionalnost: jesu li zahtijevane funkcije raspoloive? Funkcionalnost se najvie odnosi na to kako je softver s tehnike strane napravljen, tj. za koju svrhu je zapoet (prikladnost, preciznost, meudjelovanje, sukladnost, sigurnost). - Pouzdanost: koliko je softver pouzdan? Pouzdanost govori o tome koliko je softver kvalitetno napravljen i kako se ponaa kada doe do greke, pouzdanost je jedna od najvanijih karakteristika softvera (zrelost, tolerancija na greke, sposobnost povratka). - Prikladnost za uporabu: je li softver jednostavno koristiti? Prikladnost za uporabu govori o kompleksnosti softvera, koliko treba biti struan da ga se moe koristiti (razumljivost, jednostavnost, operativnost). - Uinkovitost: koliko je softver efikasan? Uinkovitost se odnosi na same performanse softvera (ponaanje u odnosu na vrijeme, ponaanje u odnosu na resurse). - Prikladnost za odravanje: koliko je jednostavno obavljati izmjene u softveru? Prikladnost za odravanje govori o jednostavnosti samog softvera kod raznih izmjena (prikladnost za analizu, jednostavnost izmjena, stabilnost, prikladnost za testiranje). - Prenosivost: koliko je jednostavno prebaciti softver u drugu okolinu? Prenosivost se odnosi na sposobnost softvera da se prilagodi bilo kojim okolinama uz jednaku kvalitetu (prilagodljivost, prikladnost za ugradnju, usklaenost, prikladnost za zamjenu). Karakteristike i zahtjevi Karakteristike kvalitete ujedno su i putokazi za definiranje ZAHTJEVA na softver i ostale elemente informacijskog sustava. Mogu imati dvostruku ulogu: - Moe biti osnova za ponudu ugovora dakle mora biti otvorena interpretacija - Moe biti osnova za sam ugovor dakle mora biti definiran do u detalje Obje izjave mogu se pozvati na zahtjeve. Tipovi zahtjeva I:

1. Korisniki zahtjevi tvrdnje prirodnim jezikom sa dijagramom usluga koje sistem podrava i njegova operativna ogranienja. Pie se za kupce. Mogu opisivati funkcijske i nefunkcijske zahtjeve na nain da budu shvatljivi korisnicima koji nemaju vee tehniko znanje. Definirani su koritenjem prirodnog jezika, tabela i dijagrama kako bi ih korisnici razumjeli. 2. Sistemski zahtjevi strukturirani dokument koji utvruje detaljne opise sistemskih funkcija, usluga i operativnih ogranienja. Definiraju to moe biti implementirano tako da to moe biti dio ugovora izmeu klijenta i izvoaa. Tipovi zahtjeva II: 1. Funkcijski zahtjevi tvrdnje o usluzi koju sustav treba pruati, kako sustav treba reagirati na odreene ulaze i kako se sustav treba ponaati u svakoj situaciji zasebno. Opisuju funkcionalnost ili usluge sustava. Ovise o vrsti softvera, oekivanju korisnika i o sustavu na kojem se softver koristi. Funkcijski zahtjevi korisnika mogu biti navodi visokog nivoa o tome to sustav treba raditi, ali oni moraju opisivati usluge sustava do u detalje. Nedostaci: Problemi nastaju ako zahtjev nije precizno iskazan, nejasni zahtjevi se mogu shvatiti razliito od strane korisnika i proizvoaa. 2. Ne-funkcijski zahtjevi sadre ogranienja usluga ili funkcija koje sustava kao vremenska ogranienja, ogranienja na proces razvoja, standarda, Opisuju svojstva i zahtjeve sustava, kao to su pouzdanost, vrijeme odziva, te zahtjevi memorije. Ne-funkcijski zahtjevi su jo kritiniji od funkcijskih, ako oni nisu poznati, sustav je beskoristan. 3. Domenski zahtjevi koji dolaze od domene aplikacije sustava i odraavaju karakteristine domene

SISTEMSKA ANALIZA I DIZAJN Inicijacija projekta Projekt sponzor je kljuna osoba koja identificira poslovne vrijednosti koje e se dobiti koritenjem informacijske tehnologije. Kako zapoeti projekt? - Poslovne potrebe trebaju voditi projekt - Projekt sponzor prepoznaje poslovne potrebe za novim sistemima i zahtjeva da se one implementiraju - Poslovne potrebe odreuju sistemske funkcionalnosti (to e raditi) - Poslovne vrijednosti projekta trebaju biti jasne Sistemski zahtjevi Dokument opisuje razloge za pokretanje projekta i oekivane vrijednosti sustava Kljuni elementi projekta: - Projektni sponzor - Poslovne potrebe - Poslovni zahtjevi - Poslovne vrijednosti - Specijalni problemi i ogranienja Analiza izvodljivosti

10

Detaljni poslovni sluajevi za projekt: a) Tehnika izvodljivost (Technical feasibility) Moemo li izgraditi sustav? - Upoznavanje korisnika i analitiara sa poslovnim podrujem. - Upoznavanje sa tehnologijom: Je li sustav prije koriten? to je novo u njemu? - Veliina projekta: Broj ljudi, vrijeme i mogunosti. - Kompatibilnost sa postojeim sustavima b) Ekonomska izvodljivost (Economic feasibility) Trebamo li graditi sustav? - Odrediti trokove i korist - Pridruiti vrijednosti trokovima i koristima - Odrediti protok novca - Odrediti funkciju odrivosti: o Net present value (NPV) neto sadanja vrijednost ( ) ( ) Ako je neto sadanja vrijednost vea ili jednaka nuli projekt je prihvatljiv, a ako je manja od nule onda je projekt neprihvatljiv. o Return on investment (ROI) povratak od ulaganja o Breakeven point (BEP) toka pokria: u toj toki zarada pokriva uloeni novac, tj. zbroj je jednak nuli. to je due vremena potrebno da se izjednai, projekt je riskantniji. Materijalni trokovi (Tangible cost) - ukljuuje prihod koji sistem omoguava da organizacija skupi, kao poveanje prodaje Nematerijalni trokovi (Intangible cost) su bazirani na intuiciji i vjerovanju radije nego tekim brojevima c) Organizacijska izvodljivost (Organizational feasibility) Ako ga izgradimo hoe li on doi? - Strateko podudaranje: Kako e se ciljevi projekta podudarati sa poslovnim ciljevima - Vlasnika analiza: Nositelj projekta, organizacijski menadment, sistemski korisnici Projekt menadment Projekt menadment je proces planiranja i kontroliranja razvoja sustava u odreenom vremenskom okviru sa minimalnim trokovima i pravom funkcionalnou. Projekt menader ima najveu odgovornost za upravljanje stotinama pitanja i pravila koja trebaju biti paljivo usklaena. etiri koraka u upravljanju projektom: - Odreivanje veliine projekta - Stvaranje i voenje poslovnog plana - Projektno osoblje - Koordinacija projektnim aktivnostima Odreivanje veliine projekta Projekt menadment ukljuuje pravljenje kompromisa. Modificiranje jednog elementa zahtjeva podeavanje drugih.
11

Ocjena projekta: - Proces odreuje projektne vrijednosti vremena i pokuaja - Izvor ocjene: metodologija u upotrebi, efekt biveg sustava, iskustvo programera Kreiranje i izrada radnog plana Identifikacija zadaa: koritenjem standardnih lista zadaa Top-down pristup: identificira zadatak najvieg nivoa, rastavlja ga na sve vie manjih jedinica, organizira zadatak u analizu radne struktura Lista svih zadataka u analizi radne strukture sa: trajanje zadatka, tekui status zadatka, ovisnost zadataka, miljokaz (podaci). Gantt Chart: poloeni stupasti grafikon, koristan za nadgledanje statusa projekta u bilo koje vrijeme PERT Chart: dijagram toka, ilustrira ovisnost zadataka i kritinu stazu. Koordinacija projektnim aktivnostima Klasine pogreke: - Preoptimistini raspored - Greka u nadziranju rasporeda - Greka u auriranju rasporeda - Dodavanje ljudi u kasnoj fazi projekta

AS-IS sustav je sadanji (postojei) sustav i on moe ali i ne mora biti kompjuteriziran TO-BE sustav je novi sustav koji se bazira na auriranim zahtjevima SYSTEM PROPOSAL je cilj isporuen od faze analize Cilj analize je shvatiti zahtjeve novog sustava i razvoj sustava koji ih obiljeava ili odluiti da novi sustav nije potreban. Determinacijski zahtjevi to je zahtjev? - Tvrdnje to sustav moe initi - Tvrdnje o karakteristikama koje sustav ima - Fokusira se na potrebe korisnika za vrijeme faze analize - Zahtjevi se mijenjaju kada projekt prelazi iz analize u dizajn i iz dizajna u implementaciju Tipovi zahtjeva: a) Funkcijski zahtjevi - Sustav mora napredovati - Sustav mora imati informacije b) Ne-funkcijski zahtjevi - Znaajke ponaanja koje sustav mora imati: operativnost, djelovanje, sigurnost i kontrola i politika svojstva Odreivanje zahtjeva: - Sudjelovanje poslovnih korisnika je nuno - Tri tehnike koje pomau korisnicima otkriti njihove potrebe za novim sustavom: a) Business Process Automation (BPA) male promjene; cilj - djelotvornost za korisnike

12

b) Business Process Improvement (BPI) umjerene promjene; cilj - djelotvornost i uinkovitost za korisnike c) Business Process Reengineering (BPR) znaajne promjene; cilj - radikalne promjene i poslovni napredak Tehnike analize zahtjeva Analiza trajanja (Duration Analysis) Izraunati vrijeme potrebno za svaki korak procesa Izraunati vrijeme potrebno za cijeli proces Usporediti ih jer velika razlika uzrokuje loe razraen proces Mogua rjeenja: o Integracija procesa (Process integration) promijeniti proces tako da ga radi manje ljudi, svaki sa irim odgovornostima o Paralelizacija (Parallelization) izmijeniti proces tako da se pojedinani koraci odvijaju istovremeno Activity-Based Costing (obraun trokova pojedinih aktivnosti) - Izraunati trokove za svaki korak procesa - Uzeti u obzir i direktne i indirektne trokove - Odrediti najskuplji korak te fokusirat napore na njega Benchmarking (Sustavno vrednovanje) - Promatrati kako druge organizacije izvode isti poslovni proces - Neformalno sustavno vrednovanje komunicirat s drugima koji imaju isti poslovni proces kao da si korisnik b) Analiza rezultata (Outcome Analysis) - Razmatra eljene rezultate iz perspektive korisnika - Razmatra to bi organizacija mogla dopustiti korisniku da radi c) Tehnoloka analiza (Technology Analysis) Analitiarev popis vanih i zanimljivih tehnologija Upraviteljev popis vanih i zanimljivih tehnologija Grupa procjenjuje kako se svako od tih moe primijeniti u posao i kako bi posao mogao imati koristi a) -

Activity Elimination (Eliminacija aktivnost) - Odreuje to bi se dogodilo kad bi se neka organizacijska aktivnost eliminirala - Koristi force-fit za testiranje svih mogunost Tehnike prikupljanja zahtjeva a) Intervju - Najee koritena tehnika - Glavni koraci: 1. Odabir onog koji e vodit intervju: zasniva se na potrebnim informacijama; najbolje imati ljude iz razliitih perspektiva (menaderi, korisnici, a idealno, svi zainteresirani); imati politiku organizacije na umu 2. Odabir pitanja za intervju: tri tipa pitanja (closed-ended questions, open-ended questions, probing questions)
13

3. Priprema za intervju: pripremiti openiti plan intervjua (lista pitanja), potvrditi podruje znanja; postaviti prioritete u sluaju da ne bude dovoljno vremena; pripremiti intervju (raspored, informirati o razlozima intervjuiranja, informirati o podruju o kojem se raspravlja) 4. Voenje intervjua: ponaati se profesionalno i bez predrasuda; zapisati (snimiti) sve informacije; biti siguran da razumije sve probleme i elemente; odvojiti injenice od miljenja; zahvaliti na kraju intervjua; zavriti na vrijeme) 5. Pripremanje zabiljeki i izvjea sa intervjua (Post-Interview Follow-up): pripremiti zabiljeke s intervjua; pripremiti izvjee sa intervjua; imati pregled intervjua i potvrditi izvjee; pregledati propuste i napraviti nova pitanja) b) Joint Application Development (JAD) Zajedniki aplikacijski razvoj - Strukturna grupa procesa fokusira se na odreivanje zahtjeva - Obuhvaa projektni tim, korisnike i menadment koji rade skupa - Moe smanjiti doseg potkradanja i do 50% - Jako korisna tehnika - lanovi JAD-a: 1. Podupiratelj: obuen za JAD tehnike; postavlja dnevni red i vodi procesa 2. Pisar(i): biljee sadraj JAD sesija 3. Korisnici i menadment za poslovno podruje sa proirenim i detaljnim znanjem c) Upitnici (Ankete) - Skup napisanih pitanja, esto poslanih velikom broju ljudi - Mogu biti u papirnatom ili elektronskom obliku - Bira sudionike koristei primjere iz populacije - Dizajnira pitanja za jasnu i olakanu analizu - Anketno follow-up izvjee d) Analiza dokumenata (Document Analysis) - Prouavanje postojeih materijala koji opisuju sadanji sustav - Oblici, izvjea, prirunici opisuju formalni sustav - Korisnikove promijene u postojeim izvjeima ili ne koritenjem postojeih oblika/izvjea pokazuje da sustav treba modificirati e) Promatranje (Observation) - Gledanje kako proces djeluje - Korisnici/upravitelji esto ne pozovu tono ono to rade - Provjera informacija prikupljenih na druge naine - Biti svjestan da se ponaanje ljudi mijenja kad ih netko promatra - Biti neupadljiv - Raspoznati slabe i mirne periode Izabir adekvatne tehnike prikupljanja zahtjeva: - Tip informacije - Dubina informacije - irina informacije - Integracija informacija - Ukljuenost korisnika - Cijena - Kombinacija tehnika Planiranje razvoja informacijskog sustava: - Planiranje (zato raditi IS)

14

Prouiti poslovnu misiju Definirati ustroj informacija Analizirati poslovno podruje Analiza (tko ga koristi, to radi, kada i gdje) Analiza konkurencije 1. Prijetnja novih konkurenata 2. Prijetnja zamjene proizvoda i usluga 3. Smanjenje ovlasti korisnika 4. Smanjenje ovlasti dobavljaa 5. Nadmetanje meu postojeim konkurentima Analiza niza vrijednosti Osnovne vrijednosti: 1. Logistiki ulaz 2. Logistiki izlaz 3. Operacije 4. Prodaja i marketing 5. Usluge Pomone vrijednosti: 1. Zajednika infrastruktura 2. Menadment ljudskih resursa 3. Razvoj tehnologije 4. nabava Dizajn (kako e IS raditi) Izrada (prema zahtjevima) Primopredaja (provjera zahtjeva) Odravanje(dorada IS) SOFTVERSKI PROCESI

Softverski proces je set aktivnosti koje su nune za razvoj softverskog sustava: 1. Specifikacija 2. Dizajn 3. Validacija (potvrivanje, provjera) 4. Razvoj Model softverskog procesa je apstraktni prikaz procesa. On predstavlja opis procesa iz nekog konkretnog gledita. Opi modeli za razvoj softvera: - Waterfall model: razdvaja i odreuje faze specifikacije i razvoja. Faze razvoja waterfall modela 1. Analiza zahtjeva i definicija 2. Sistemski i softverski dizajn 3. Implementacija i testiranje jedinica 4. Integracija i sistemsko testiranje 5. Operacije i odravanje Problemi waterfall modela: 1. Glavna tekoa kod ovog modela je obuhvaa promjene nakon to je proces napravljen. Jedna faza mora biti zavrena prije nego se pree na slijedeu. 2. Nefleksibilno razdjeljivanje projekta na odvojene faze ini tekoe u odgovoru na promjenjive korisnike zahtjeve
15

3. Ova metoda je jedino primjenjiva kada su zahtjevi dobro shvaeni i promjene su poprilino ograniene za vrijeme dizajniranja procesa Evolucijski razvoj: specifikacija, razvoj i provjera su umetnuti. 1. Istraivaki razvoj: cilj je raditi s kupcima i napraviti konani sustav na inicijalnim koncepcijskim specifikacijama. Treba se zapoeti sa dobro poznatim zahtjevima i dodati nove zahtjeve i nove mogunosti koje su predloene od strane korisnika. 2. Throw-away prototyping: cilj je razumjeti sistemske zahtjeve. Treba zapoeti sa jedva razumljivim zahtjevima i razjasniti to zapravo treba. Problemi: 1. Nedostatak vidljivosti procesa 2. Sustavi su esto nedovoljno strukturirani 3. Specijalne sposobnosti mogu biti neophodne Primjenjivost: 1. Za male ili srednje velike interaktivne sustave 2. Za dijelove veih sustava 3. Za kratkotrajne sustave Component-based softverski inenjering: sustav je sastavljen iz postojeih komponenti. Bazira se na planskom ponovnom koritenju gdje se sustav sastavlja od postojeih komponenti ili COTS (Commercial-off-the-shelf) sustava. Faze procesa: 1. Analiza komponenti 2. Modifikacija zahtjeva 3. Dizajn sistema sa ponovnom upotrebom 4. Razvoj i integracija Ovaj pristup se sve vie upotrebljava kao komponenta standarda u upotrebi. Razvoj ponovnom upotrebom: Zahtjevi sustava uvijek su ukljueni u projekt, pa procesne iteracije ,gdje su ranije faze preraene, su uvijek dio procesa velikog sustava. Iteracija moe biti primijenjena na bilo koji opi procesni model. Dva razliita pristupa: 1. Isporuka dodavanjem Razvoj i isporuka su rastavljeni na dodatke gdje svaki dodatak dostavlja dio traenih funkcionalnosti. Korisniki zahtjevi imaju prioritet i zahtjevi najveeg prioriteta su ukljueni u rane dodatke. Jednom kada je razvoj dodatka poeo, zahtjevi su zaleeni, a zahtjevi za kasnije dodatke se mogu nastavljati razvijati. Prednosti: o Korisniku proizvod moe biti dostavljen sa pojedinim dodacima, tako da je funkcionalni sustav dostupan ranije o Raniji dodaci se ponaaju kao prototip, kako bi se pomoglo iznijeti na vidjelo zahtjeve za kasnije dodatke o Manji rizik od neuspjeha cjelokupnog projekta o Usluge najveeg prioriteta u sustavu nastojati podvrgnuti najveem testiranju 2. Spiralni razvoj Proces se predstavlja kao spirala radije nego niz aktivnosti sa praenjem unatrag. Pojedina petlja u spirali predstavlja fazu u procesu. Nema fiksnih faza kao specifikacija ili dizajn petlje u spirali se biraju ovisno o zahtjevima. Rizik se izriito utvruje i rjeava kroz proces. Sektori spiralnog modeliranja su: o Objektivne postavke - konkretni ciljevi su identificirani za faze

16

o Ocjena rizika i njegovo smanjenje rizik se utvruje i aktivnosti se ispravljaju da bi se smanjio o Razvoj i validacija (provjera) razvojni model za sustav se bira to mobe biti bilo koji opi model o Planiranje projekt se pregleda i sljedea faza je spirale je planiranje Extreme programming Pristup za razvoj baziran na razvoju i dostavi jako malih funkcionalnih dodataka. Radi na razvoju konstantnog koda, a korisnik je ukljuen u razvoj i programiranje

Projektne aktivnosti: 1. Software specification (specifikacija softvera) Definira to usluge zahtijevaju i sadraj sistemskih operacija i razvoj. Projektiranje zahtjeva sustava: - Studija provedivosti - Otkrivanje zahtjeva i analiza - Specifikacija zahtjeva - Provjeravanje zahtjeva 2. Software design and implementation (dizajn softvera i implementacija) Proces promjene sistemskih specifikacija u izvrni sustav. Dizajn softvera dizajniranje strukture softvera koji realizira specifikacije. Implementacija prevodi strukturu u izvri program. Aktivnost dizajna i implementacije su u bliskoj vezi i mogu biti u meudjelovanju. Dizajniranje aktivnosti procesa: o Dizajn arhitekture o Apstraktne specifikacije o Dizajn interface-a o Dizajn komponenti o Dizajn strukture podataka o Dizajn algoritma Strukturne metode - planski pristup razvoju dizajna sustava. Dizajn je obino pohranjen kao set grafikih modela. Mogui modeli su: objektni model, sekvencijalni model, oblik izmjenjivog modela, strukturni model, model toka podataka (data-flow). Programiranje i uklanjanje pogreaka - prebacivanje dizajna u program i micanje greki iz programa. Programiranje je konkretna aktivnost, nema opih programerski procesa. Programeri podvrgavaju neke programe testiranju da bi otkrili propuste u programu i maknuli ih u procesu uklanjanje pogreaka. 3. Software validation (provjeravanje softvera) Verifikacija i validacija (V&V) namjerava pokazati da sustav potvruje svoje specifikacije i odgovara zahtjevima kupcima sustava. Ukljuuje provjeravanje i pregled procesa i testiranje sustava. Faze testiranja: - Testiranje komponenti ili jedinica - Testiranje sustava - Testiranje prihvaanja 4. Software evolution (razvoj softvera) Softver je sam po sebi fleksibilan i moe se mijenjati. Kako se mijenjaju zahtjevi kako se mijenjaju poslovne okolnosti, softver koji podrava posao takoer mora ukljuivati promjene.

17

Rational Unified Process (RUP) je moderni procesni model izveden iz rada na UML-u i prati proces. Obino se opisuje iz tri perspektive: - Dinamina perspektiva koja prikazuje faze u vremenu - Statina perspektiva koja pokazuje procese po aktivnostima - Praktina perspektiva koja predlae dobre postupke RUP faze razvoja modela: - Poetak predstavlja poslovne uvijete za sustav - Obrada razvoj i razumijevanje problema domene i arhitekture sustava - Konstrukcija dizajn sustava, programiranje i testiranje - Promjena prosljeuje sustav u operativnu okolinu Computer-aided software engineering (CASE) CASE je softver za podupiranje softverskog razvoja i razvojnog procesa. Automatizacija aktivnosti: - Grafiki editor za razvoj modela sustava - Podatkovni direktorij za upravljanje dizajnerskim entitetima - Grafiki UI konstruktor za konstrukciju korisnikog interface-a - Pronalaenje greaka za pronalaenje programskih nedostataka - Automatsko prevoenje za proizvodnju nove verzije programa CASE tehnologija: - Softverski inenjerski zahtjevi kreativnih misli to nije lako automatizirati - Softverski inenjering je timska aktivnost i, za velike projekte, mnogo se vremena provodi u timskoj interakciji. CASE tehnologija ovo zapravo ne potie. CASE klasifikacija: - Klasifikacija pomae razumjeti razliite tipove CASE alata i njihovih aktivnosti za podupiranje procesa. - Funkcionalna perspektiva alati su klasificirani prema njihovoj specifinoj funkciji - Procesna perspektiva - alati su klasificirani prema njihovoj procesnoj aktivnosti koju podupiru - Integracijska perspektiva - alati su klasificirani prema njihovoj organizaciji u integrirane jedinice CASE integracija: - Alati:podupiranje individualne procesne zadae kao dizajniranje dosljedne provjere, tekst editor - Radni stol: podupiranje procesnih faza kao specifikacija i dizajn. Obino ukljueno nekoliko integracijskih alata - Okolina: podupiranje svih bitnih dijelova cijelog softverskog procesa. Obino ukljueno nekoliko integriranih radnih stolova SOFTVERSKI ZAHTJEVI to je zahtjev? Moe imati doseg visoko razinskih apstraktnih stavki usluge ili sistemskih ogranienja sve do detaljnih matematikih funkcijskih specifikacija. Funkcijski i ne-funkcijski zahtjevi: Funkcijski zahtjevi su tvrdnje o uslugama koje sustav treba podravati, kako sustav treba reagirati pri odreenim unosima i kako se sustav treba ponaati u pojedinim situacijama. Opisuju funkcionalnost ili sistemski uslugu. Ovise o tipu softvera, oekivanju korisnika i tipu sustava na kojem e softver biti

18

koriten. Mogu biti visoko razinske tvrdnje to sustav treba raditi , i trebaju opisivat to sustav treba raditi do u detalje. LIBSYS sustav: library (bibliotekarni) sustav podrava jedan interface naspram niza baza podataka lanova od razliitih biblioteka. Korisnici mogu traiti, preuzimati i printati lanke za osobne studije. Primjeri zahtjeva: - Korisnik mora biti u mogunosti da pretrauje ili sve iz inicijalnog seta baze podataka ili izabrati dio njih. - Sistem treba podravati odgovarajue poglede za korisnika da bi mogao itati dokumente iz spremita dokumenata. - Svaka naredba treba biti alocirana jedinstvenim identifikatorom, to bi korisniku omoguilo da ih kopira u korisniko privremeno podruje pohranjivanja. Problemi sa zahtjevima: - Problem se namee kada zahtjevi nisu tono precizirani - Vieznaajni zahtjevi mogu biti interpretirani na razliite naine od strane korisnika i programera - Razmatrajui termin 'odgovarajui preglednik' moemo rei da on od gledita korisnika znai preglednik sa specijalnom svrhom za dokumente razliitih tipova, a sa strane programera on omoguava pregled teksta koji pokazuje sadraj dokumenata. Ne-funkcijski zahtjevi predstavljaju ogranienja usluga ili funkcija koje sustav nudi kao vremensko ogranienje, ogranienje razvoja procesa, standarda, Oni definiraju sistemska svojstva i ogranienja kao pouzdanost, vrijeme odgovora i pohranu zahtjeva. Ogranienje mogu biti mogunosti I/O ureaja, sistemske reprezentacija, Zahtjevi takoer mogu biti specificirani koristei CASE sustav, programski jezik ili razvojne metode. Ne-funkcijski zahtjevi mogu biti jo kritiniji od funkcijskih. Ako oni nisu takvi sustav je beskoristan. Ne-funkcijska klasifikacija: - Produktivni zahtjevi zahtjevi koji specificiraju kako se dostavljeni proizvod mora ponaati u konkretnim uvjetima, kao izvoenje sustava, pouzdanost, - Organizacijski zahtjevi zahtjevi koji su posljedica organizacijske politike i procedura, kao standardna upotreba procesa, implementacija zahtjeva, - Vanjski zahtjevi zahtjevi koji se nameu od imbenika koji su van sustava i razvojnog procesa, kao meusobni zahtjevi, zakonodavni zahtjevi, Domenski zahtjevi: zahtjevi koji dolaze aplikacijske domene sustava i ima utjecaja na karakteristike domene. Opisuju karakteristike sustava i elemente koji utjecaju na domenu. Domenski zahtjevi su novi funkcijski zahtjevi, ogranienja na postojee zahtjeve ili definiraju specifine proraune. Ako domenski zahtjevi nisu zadovoljeni, sustav nee raditi. Problemi sa zahtjevima: - Razumijevanje zahtjevi su iskazani u jeziku domenske aplikacije - Bezuvjetnost domenki strunjak razumije podruje tako dobro da ne misli o pravljenju domenskih zahtjeva izriito (jasno). Tipovi zahtjeva: Korisniki zahtjevi: tvrdnje na prirodnom jeziku sa dijagramima usluge koju sustav podrava i njegova ogranienja. Pisan je za kupca. Oni moraju opisivati funkcijske i ne-funkcijske zahtjeve na nain da su oni razumljivi sistemskim korisnicima koji nemaju detaljno tehniko znanje. Korisniki zahtjevi su definirani koristei prirodni jezik, tabele i dijagrame i razumljivi su svakome korisniku. Problemi sa prirodnim jezikom: - Nedostatak jasnoe preciznost je teka bez pravljenja dokumenta tekog za itanje

19

- Zbunjujui zahtjevi funkcijski i ne-funkcijski zahtjevi skloni su mijeanju - Stapanje zahtjeva nekoliko razliitih zahtjeva moe biti izreeno zajedno LIBSYS zahtjevi trebaju podravati sustav financijskog obrauna koji uva zapise o svim isplatama korisnicima sustava. Problemi ovih zahtjeva su: - Zahtjevi baze podataka ukljuuju i konceptualne i detaljne informacije (opis koncepta sustava financijskog obrauna koji treba biti ukljuen u LIBSYS, te detalje kako menader moe konfigurirati sustav) - Mrea zahtjeva mijea tri razliite vrste zahtjeva: o Konceptualni funkcijski zahtjevi (potreba za mreom) o Ne-funkcijski zahtjevi (mrene jedinice) o Ne-funkcijski UI zahtjevi (mreno prebacivanje) Vodi za pisanje zahtjeva: - Izumiti standardni format i koristiti ih za sve zahtjeve - Koristiti jezik na konzistentan nain - Oznaiti tekst da bi se identificirale kljune rijei zahtjeva - Izbjegavati koritenje kompjuterskog argona Sistemski zahtjevi: strukturiran dokument sa detaljnim opisima sistemskih funkcija , usluga i njegovih ogranienja. Definiraju to treba biti implementirano, pa mogu biti dio ugovora izmeu klijenta i ugovaratelja. Vie detaljnih specifikacija o funkcijama sustava, uslugama i ogranienjima. Zahtjevi i dizajn: U principu, zahtjevi trebaju odreivati to treba raditi i dizajn treba biti opisan. U praksi, zahtjevi i dizajn su nerazdvojivi: - Arhitektura sustava moe biti dizajnirana prema strukturi zahtjeva - Sustav moe biti inter-operabilan sa drugim sustavima da bi se ostvarili zahtjevi dizajna - Koritenje specifinog dizajna moe biti zasnovano na domenskim zahtjevima Problem sa NL(Natural Language) specifikacijama: - Dvosmislenost ita i pisac zahtjeva moraju interpretirati iste rijei na isti nain. NL je prirodno dvosmislen pa je to jako teko - Pre-fleksibilnost ista stvar moe biti reena na bezbroj razliitih naina pri specifikaciji - Nedostatak modularnosti NL strukture su neadekvatne za strukture sistemskih zahtjeva Form-based specifikacije: - Opis funkcija ili entiteta - Opis unosa i odakle odlaze - Opis izlaza i gdje idu - Naznaka zahtjeva drugih entiteta - Uvjeti prije i uvjeti poslije (ako je prikladno) - Dodatni efekti (ako postoje) funkcije Tabline specifikacije: - Koristiti dodatke prirodnom jeziku - Obino je korisno kada se definiraju brojne mogue alternative Sekvencijalni dijagram: - Prikazuju se dijelovi dogaaja koji zauzimaju mjesto tijekom interakcije korisnika sa sustavom - itaju se od vrha do dna akcije

20

Interface specifikacije: - Veina sustava mora suraivati s drugim sustavima i operativni interface mora biti specificiran kao dio zahtjeva - Tri tipa interface-a: proceduralni interface, struktura podataka koji su promijenjeni, prikazivanje podataka - Formalne biljeke su djelotvorne tehnike za interface specifikacije Dokumentacija zahtjeva: - To je slubena izjava o tome to je neophodno za programere sustava - Treba ukljuivati i definiciju korisnikih zahtjeva i specifikaciju sistemskih zahtjeva - To NIJE dizajnerski dokument. to je vie mogue , treba biti ukljueno TO sustav treba raditi, radije nego KAKO to treba raditi. Struktura dokumentacije zahtjeva: - Predgovor - Uvod - Kazalo - Definicija korisnikih zahtjeva - Arhitektura sustava - Specifikacije sistemskih zahtjeva - Sistemski modeli - Razvoj sistema - Dodatci - Sadraj PROCES PROJEKTIRANJA ZAHTJEVA Ovaj se dio bavi objanjavanjem principa aktivnosti projektiranja zahtjeva i njihovih veza. Predstavlja tehnike otkrivanja i analize zahtjeva, te opisuje provjeru valjanosti zahtjeva i ulogu koju igraju pregledi zahtjeva. Ovaj proces dosta ovisi o aplikacijskoj domeni, ljudima koji su ukljueni i organizaciji razvoja zahtjeva. Kako god, postoji mnogo opih aktivnosti zajednikih svim procesima: - Otkrivanje zahtjeva - Analiza zahtjeva - Provjera valjanosti zahtjeva - Upravljanje zahtjevima Studija provedivost Studija provedivosti odluuje hoe li predloeni sustav biti vrijedan truda. Ova studija provjerava sljedee: - Pridonosi li sistem organizacijskim ciljevima - Hoe li sistem moi biti projektiran sa aktualnom tehnologijom i u okvirima budeta - Hoe li sistem moi biti integriran sa ostalim sistemima koji su u upotrebi Implementacija: - Zasniva se na informacijskim ocjenama, zbirke informacija i napisanog izvjea - Pitanja za ljude iz organizacije: o to ako sustav nije implementiran?

21

o o o o o

Koji su trenutni problemi s procesom? Kako e predloeni sustav pomoi? Koji e biti problemi integracije? Je li potrebna nova tehnologija? Koje sposobnosti? Koji su resursi potrebni za podravanje predloenog sustava?

Otkrivanje i analiza: - Ponekad se naziva otkrivanje zahtjeva ili pronalazak zahtjeva - Ukljuuje tehniki rad sa kupcima da bi se nalo neto o aplikacijskoj domeni, uslugama koje sustav treba podravati i sistemska operacijska ogranienja - Mogu biti ukljueni krajnji korisnici, menaderi, projektanti ukljueni u odravanje, domenski eksperti, Ovo se naziva interesna grupa (stakeholders). Problemi sa analizom zahtjeva: - Interesna grupa zapravo ne zna to eli - Interesna grupa izrie zahtjeve sa vlastitim izrazima - Razliiti lanovi utjecajne grupe mogu imati proturjene zahtjeva - Organizacijski i politiki faktori mogu imati utjecaj na sistemske zahtjeve - Izmjena zahtjeva tijekom procesa analize. Mogu se pojaviti nove interesne grupe i promijeniti poslovno okruenje Aktivnosti procesa: - Otkrivanje zahtjeva - Klasifikacija i organizacija zahtjeva - Prioriteti i dogovaranje - Dokumentacija zahtjeva Toke gledita (viewpoints): Toke gledita su naini strukturiranja zahtjeva da bi predstavili razliite perspektive interesne grupe. Interesne grupe mogu biti klasificirane u razliita gledita. Vie-perspektivna analiza je vana jer nema jednog ispravnog naina za analiziranje sistemskih zahtjeva. Vrste toki gledita: - Interaktivne toke gledita ljudi ili sustavi koji su u direktnom meudjelovanju sa sustavom - Indirektne toke gledita interesne grupe koje same ne koriste sustav ali imaju utjecaja na zahtjeve - Domenske toke gledita domenske karakteristike i ogranienja koja imaju utjecaj na zahtjeve Upotreba toki gledita: - Daje i prima sistemske usluge - Sistem koji meudjeluje direktno sa specificiranim sustavom - Regulacije i standardi - Izvor poslovnih i ne-funkcionalnih zahtjeva - Programeri koji razvijaju i odravaju sustav Intervjuiranje: U formalnom i neformalnom intervjuiranju , RE timovi postavljaju pitanja interesnoj grupi o sistemu koji koriste i sistemu koji e razvijati. Postoje dva tipa intervjuiranja: - Zatvoreni intervju gdje je predefinirani set pitanja i odgovora - Otvoreni intervju gdje nema predefiniranog programa rada i problemi se rjeavaju zajedno sa interesnim grupama

22

Intervju u praksi: - Obino mjeavina otvorenog i zatvorenog intervjuiranja - Intervjuiranje je dobro za razumijevanje to interesne grupe rade i kako e one meudjelovati sa sustavom - Intervju nije dobar za razumijevanje domenskih zahtjeva (ne razumije se specifina domenska terminologija) Djelotvorni intervju: - Onaj tko intervjuira mora biti nepristran, sa eljom da slua interesnu grupu i ne treba imati prethodne ideje o zahtjevima - Onome koga ispituju trebaju postavljati pitanja ili ponude Scenariji: Scenarij je pravi primjer kako sustav moe biti koriten. Oni trebaju ukljuivati: - Opis poetne situacije - Opis normalnog tijeka i dogaaja - Opis to moe poi loe - Informaciju i drugim konkurentnim aktivnostima - Opis stanja kada se scenarij zavri Socijalni i organizacijski faktori: - Softverski sustav se koristi u socijalnom i organizacijskom kontekstu. To moe utjecati ili ak dominirati u sistemskim zahtjevima - Socijalni i organizacijski faktori nisu samo jedna toka gledita, ali imaju utjecaja na sve toke gledita - Dobar analitiar mora biti osjetljiv na ove faktore , no oni trenutano nemaju utjecaja na njihovu analizu Etnografija: - Socijalni znanstvenik provodi znatno vrijeme promatrajui i analizirajui kako ljudi zapravo rade - Ljudi ne moraju objanjavati i opisivati njihov posao - Socijalni i organizacijski faktori mogu biti vani pri promatranju - Etnografske studije pokazuju da je posao obino bogatiji i mnogo kompleksniji nego to je prikazan na jednostavnom sistemskom modelu Usredotoena etnografija: - Kombinira etnografiju sa prototipom - Razvoj prototipom rezultira neodgovorenim pitanjima koja se fokusiraju na etnografsku analizu - Problem sa etnografijom je da studije postoje praktino to moe imati povijesnu bazu koja vie nije vie vana Provjera zahtjeva: - Ispravnost da li sistem podrava funkcije koje najbolje podravaju potrebe kupaca? - Dosljednost postoji li konflikt meu zahtjevima? - Kompletnost da li su sve nune funkcije ukljuene? - Realnost da li je za zahtjeve koji se implementiraju dostupni novac i tehnologija? - Provjerljivi mogu li se zahtjevi provjeriti? Tehnike provjere valjanosti zahtjeva:

23

Pregled zahtjeva Prototip Testiranje

Pregled zahtjeva: - Ispavan pregled treba biti odran dok se odreeni zahtjevi jo formuliraju - I klijent i ugovara trebaju biti ukljueni u pregled - Pregledi mogu biti formalni (sa potpunom dokumentacijom) i neformalni. Dobra komunikacija izmeu programera, kupca i korisnika moe rijeiti probleme u vrlo ranoj fazi Provjera pregleda - povjerljivost jesu li zahtjevi realistino testirani? - Razumljivost jesu li zahtjevi dobro shvaeni? - Sljedivost jesu li originalni zahtjevi jasno utvreni? - Prilagodljivost moe li zahtjev bit izmijenjen bez prevelikog utjecaja na druge zahtjeve? Menadment zahtjeva: je proces upravljanja izmjenjivim zahtjevima tijekom procesa projektiranja zahtjeva i razvoja sustava. Zahtjevi su neizbjeno nepotpuni i nekonzistentni: - Novi zahtjevi pojavljuju se tijekom procesa zbog izmijenjenih poslovna potreba i boljeg shvaanja razvoja sustava - Razliite toke gledita imaju razliite zahtjeve koji su esto kontradiktorni Izmjena zahtjeva: - Prioritetni zahtjevi sa razliiti toki gledita mijenjaju se tijekom razvojnog procesa - Sistemski korisnici mogu specificirati zahtjeva iz poslovne perspektive koji se sukobljavaju sa zahtjevima krajnjih korisnika - Poslovna i tehnika okolina sustava mijenja se tijekom razvoja Trajni i izbrisivi zahtjevi: - Trajni zahtjevi: ustaljeni zahtjevi izvode se iz osnovne aktivnosti kupeve organizacije - Izbrisivi zahtjevi: su zahtjevi koji se mijenjaju tijekom razvoja ili kada je sustav ve u upotrebi Tijekom procesa planiranja zahtjeva, treba se imati plan: - Identifikacija zahtjeva kako su zahtjevi individualno identificirani - Promjenjiv proces upravljanja proces slijedi promjene pri analizi ili promjene zahtjva - Politika sljedivosti znaenje informacije o odnosu izmeu zahtjeva Sljedivost se tie odnosa izmeu zahtjeva, njihovih izvora i sistemskog dizajna Sljedivost izvora veza od zahtjeva da interesne grupe koja predlae ove zahtjeve Sljedivost zahtjeva veza izmeu ovisnih zahtjeva Sljedivost dizajna veza od zahtjeva do dizajna - Potpora CASE alata potpora alata je neophodna za pomo pri upravljanju izmjenom zahtjeva: Pohrana zahtjeva zahtjevi trebaju biti pouzdan Upravljanje promjenama upravljanje procesom promjena je proces rada ije faze mogu biti definirane i izmjena informacije izmeu tih faza je djelomino automatiziran

24