PROJEKTIRANJE INFORMACIJSKIH SUSTAVA

Sustav je grupa objekata/entiteta vezanih međusobnim odnosima s ciljem ostvarivanja nekog cilja.Granica sustava definira opseg i domašaj sustava. Granice se s vremenom mogu mijenjati, s utvrđene su prirodno ili proizvoljno.Okolina je sve što je izvan granica sustava. Tiče se sustava jer je s njim u vezi, bilo da od sustava prima izlaze ili u sustav šalje ulaze.Ulazi i izlazi su način 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 događaju ili pojavi i sadrži sintaksu (formu) i semantiku (sadržaj)Podatak informacija u strojno obrađenoj formi i naglasak je na specifikaciji sintakseZnanje sadrži pragmatičnu 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 pročišćen, organiziran i obrađen podatak u smislenom kontekstu. Znanje se gradi na temelju novih informacija koje se nadovezuju na postojeće znanje. Isti podaci mogu biti različito interpretirani od strane različitih ljudi u ovisnosti o njihovom znanju

Informacijski sustav je grupa ljudi, procesa, podataka, mreža i tehnologija stvorena da riješi organizacijske probleme ili da stvori nove prilike.Zadaća informacijskog sustava:

- Prikupljanje- Obrada- Pohranjivanje- Distribucija podataka

Vrste informacijskih sustava:- Obrada podataka- Uredski poslovi- Podrška odlučivanju- Ekspertni sustav- Posebna područja

Komponente informacijskog sustava:- Hardware – tehnička oprema- Software – programska oprema- Orgware – organizacijska komponenta- Lifeware – izvršitelj- Netware – komunikacijska infrastruktura- Dateware – podatkovna razina

Projektiranje i izgradnja IS:Bit projektiranja je MODELIRANJE. Pristup ovisi o zatečenom stanju (malo je green field projekata!). Postoji velika interakcija između faza

System Development Life Cycle (SDLC)

- odnosno životni ciklus razvoja sustava sastoji se od četiri sljedeće faze:

1

a) PLANIRANJEOva faza je proces razumijevanja zašto informacijski sustav treba biti izgrađen. Također se u ovoj fazi izgrađuje projektni tim koji će surađivati u izgradnji informacijskog sustava. Ova faza sastoji se od dva koraka planiranja:

1. Inicijacija projekta – kako smanjiti troškove ili povećati prihode2. Upravljanja projektom (Projekt menadžment) – menadžer projekta napravi poslovni plan i uvodi

tehnike koje pomažu projektnom timu kontrolirati projektom kroz cijeli SDLCb) 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 istražuje postojeće sustave, istražuje dozvoljene mogućnosti i razvija koncept za novi sustav. Ova faza sastoji se od tri koraka:

1. Analiza strategije – uključuje analizu postojećih sustava2. Prikupljanje zahtjeva – analiza ovih informacija vodi razvoju novog sustava3. Prijedlog sustava (System proposal) – prezentira se projektnim sponzorima i ostalim ključnim

pojedincima koji odlučuju o tome da li projekt treba nastaviti. Prijedlog sustava opisuje s kojim će se poslovnim zahtjevima susresti novi sustav.

c) DIZAJNU ovoj fazi odlučuje se: kako će sustav funkcionirati u uvjetima hardvera, softvera i mrežne infrastrukture; korisnička sučelja; forme i izvješća koja će se koristiti; programi, baze podataka i datoteke koje će biti potrebne. Faza dizajna ima četiri koraka:

1. Strateški dizajn – hoće li sustav biti razvijan unutar neke tvrtke ili van nje?2. Dizajn arhitekture – opisuje hardver, softver i mrežnu infrastrukturu koja će se koristiti3. Karakteristike baza podataka i datoteka – ovi dokumenti određuju koji podaci i gdje će biti

pohranjeni4. Dizajn programa – definira koji programi trebaju biti napisani što će oni raditid) IMPLEMENTACIJA

U ovoj fazi sustav je već nabavljen ili razvijen. Ova faza obično najdulje traje i najskuplji je dio procesa. Sastoji se od tri koraka:

1. Izgradnja je sustava – sustav je izgrađen i testiran kako bi se uvjerili da djeluje onako kako je dizajniran

2. Instalacija – pripremiti podršku za instalirani sustav3. Plan podrške – uključuje poslije-implementacijsko izvješće (ispitivanje)

Metodologije razvoja sustava

Metodologije su formalizirani pristup razvoju SDLC-a: a) Process-centered metodologija

Kod ove metodologije pažnja je usmjerena na definiranje aktivnosti povezanih sa sustavom. Usredotočena je na predstavljanje sustava kao skupa procesa sa informacijama koje ulaze u procese i koje iz njih izlaze.

b) Data-centered metodologijaOva metodologija pažnju posvećuje definiranju sadržaja podataka u memoriji i kako su oni organizirani. Ova metodologija koristi podatkovni model kao jezgru sustava.

c) Object-oriented metodologijaOva metodologija nastoji balansirati žarište između procesa i podataka. UML (Unified Modeling Language) je opći jezik modeliranja. Koristi se za opisivanje sustava kao skupa objekata koji objedinjuju i procese i podatke.

2

Kategorije metodologija razvoja sustava

Prva kategorija metodologija razvoja sustava: Structured Design

Strukturno dizajnirana metodologija korak po korak približava se SDLC-u pomičući se od jedne faze do druge

a) Waterfall development (vodopadni razvoj)Sa ovom metodologijom analitičari i korisnici idu slijedno od jedne faze do sljedeće.Prednosti su:

- Zahtjevi sustava su određeni prije nego započne programiranje- Promjene zahtjeva su minimalne kako se projekt nastavlja

Nedostaci:- Dizajn mora biti potpuno određen prije nego programiranje počne- Prođe puno vremena od prijedloga sustava u fazi analize do isporuke sustava- Zahtjevi moraju biti jako dobro shvaćeni i samo tada se može koristiti- Zahtjevi moraju biti jako dobro shvaćeni , samo se tada može koristiti ovaj model

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

Jedan projekt podijeljen je u slijed različitih podprojekata.

3

Druga kategorija metodologija razvoja sustava: Rapid Aplication Development (RAD)

RAD-Based metodologija prilagođava SDLC fazu za brže dostavljanje dijelova razvijenog sustava korisniku u ruke. Većina RAD-Based metodologija preporučuje analitičarima korištenje posebnih tehnika i kompjuterskih alata za ubrzanje analize i implementacije, kao što je CASE alat (computer-aided software engineering). Mogući problem sa RAD-Metodologijom je upravljanje korisničkim očekivanjima.

a) Fazni razvoj (Phased development)Ova metodologija razbija cijeli sustav u više serija koje se razvijaju slijedno (sekvencijalno). Tim razdjeljuje zahtjeve u slijed verzija, a zatim najvažnije i osnovne zahtjeve grupira u prvu verziju sustava. Kada je verzija završena, tim započinje rad na novoj.

b) Prototip (Prototyping)Prototyping—based metodologija obavlja analiza, dizajn i implementaciju istovremeno. Sve tri faze obavljaju se ponavljano u krug sve dok se sutav ne izvrši.PROTOTIP je manja verzija sustava sa minimalnom količinom mogućnosti.

PREDNOST: Omogućava komunikaciju korisnika sa sustavom čak i ako on nije spreman za upotrebu.NEDOSTATAK: Odluke o dizajnu često se pokažu lošima

4

c) Throwaway PrototypingOva metoda slična je Prototyping-based metodologiji, a glavna razlika je da se prototip informacijskog sustava završi tijekom druge faze SDLC-a.

Treća kategorija metodologija razvoja sustava: Agile Development

Ova kategorija fokusira se na eliminaciju pretjeranog modeliranja i dokumentiranja, te vremena utrošenogu to. Projekt ističe jednostavne, iterativne aplikacijske razvoje, a najpoznatije metode su: XP (ExtremeProgramming), Srum, Crystal, DSDM (Dynamic System Development Method), Lean Development,FDD (Feature Driven Development).

a) Extreme Programming (XP)Četiri ključne vrijednosti:

- Komuikacija- Jednostavnost- Povratna veza (feedback)- Hrabrost

Ključna načela XP-a:- Neprekidno testiranje- Jednostavno kodiranje- Zatvorena interakcija sa krajnjim korisnikom omogućava izgradnju sustava veoma brzo

Zaključak: - Ako je sustav složen najbolje je odabrati Phased development based metodologiju- Ako vodimo računa o pouzdanosti najbolja je Throwaway Prototyping based metodologija- Za kratkotrajne rasporede biramo RAD – based metodologiju

Sposobnosti projektnog tima i uloge:

5

Projekt mora sadržavati različito sposobne individualce da bi sustav bio uspješan. Analitičar zato mora imati šest glavnih vještina:

1. Tehničnost2. Poslovnost3. Analitičnost4. Moralnost5. Mora biti dobar menadžer6. Mora biti interpersonalan

Kategorije analitičara:1. Poslovni analitičar2. Sistemski analitičar3. Infrastrukturni analitičar4. Analitičar promjenjivog menadžmenta (upravljanja)5. Projektni menadžer

b) Scrum: je iterativni, inkrementirajući proces za razvoj bilo kakvog produkta ili upravljanje bilo kakvim poslom. On proizvodi set upravljačkih funkcionalnosti na kraju svake iteracije. Scrum je agilni proces za upravljanje i kontrolu razvojnog posla. Ima timski pristup, poboljšava komunikaciju i maksimizira kooperaciju, te povećava produktivnost.

Ostali modeli:

a) Evolucijski model Evolucijski model razvoja softvera odgovor je na glavne faktore rizika u dosadašnjim softverskim projektima.  Kako bismo odgovorili na glavne faktore rizika, posebnu pozornost posvećujemo korisničkim zahtjevima, nadogradnji i promjenama zahtjeva, a istovremeno i dosljednom poštivanju rokova.Softver se razvija u ciklusima, gdje svaki ciklus dograđuje funkcionalnost aplikacija. Korisnik u svakom od ciklusa ocjenjuje prihvatljivost rješenja i može postaviti dodatne zahtjeve. Prioritetni i realni zahtjevi se uvijek rješavaju prvi. Evolucijski model razvoja softvera se najčešće koristi kod manjih projekata ili za razvoj nekog podsustava. Omogućava realizaciju sustava sa lošijom specifikacijom zahtjeva.Prednost je u vremenu trajanja (kreće se odmah u posao, tijekom rada se rješavaju problemi).Nedostatak je loša vidljivost prilikom razvoja, jer ovaj model razvoja daje rješenje bez arhitekture.

b) Iterativni model Iterativni pristup podrazumijeva podjelu problema na manje dijelove, faze traju kraće, za svaki dio se prođu sve faze, brže se dolazi do softvera koji korisnik može probati, ali je i lošija dokumentacija.

6

Grubi opis zahtjeva

Specifikacija

Razvoj

Provjera

Prvo rješenje

Međurješenje

Konačno rješenje

RAD I ODRŽAVANJE

Iteracija 1 Iteracija 2 Iteracija 3

Ovaj model kombinira elemente vodopadnog s iterativnim evolucijskim pristupom. Prednost ovog modela je što se tijekom cijelog razvojnog ciklusa vrši stalna provjera.Nedostaci su potreba za ranim definiranjem arhitekture, greške u jednoj iteraciji se propagiraju na druge. Ovaj model onemogućava fleksibilan odnos s naručiteljem.

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 izgrađuje se jedan dio sustava ili povećava njegova funkcionalnost. Predstavlja iterativni pristup razvoju softvera a ujedno i nadograđuje evolucijski model. Na početku svake faze provodi se procjena rizika. Nastoji se identificirati moguće rizike i razriješiti ih prije nastavka (uklanjanjem ili svođenjem na najmanju moguću mjeru). U slučaju da je rizik prevelik, projekt se prekida.Prednosti ovog modela su da kontrolira rizike, omogućava uklapanje u postojeći model razvoja i dobar je za velike i složene projekte.Nedostaci su što zahtijeva veliko stručno znanje prilikom procjene rizika , visoko domensko i upravljačko znanje.Spiralni model je relativno novi model koji se tek treba dokazati u velikim projektima pa je teško odrediti njegove dobre i loše strane. Primjenjuje se u projektima u kojima se očekuju razni problemi s tehnologijom, ljudima, tržištem i okolinom. Pogodan je za izgradnju velikih sustava te u projektima u kojima provođenje analize rizika ne predstavlja preveliki relativni trošak.

d) Komponentalni model Osnovna ideja ovog modela je da se dobro dizajnirane i implementirane objektno orijentirane klase mogu više puta koristiti u različitim aplikacijama i arhitekturama. Razvoj je baziran na komponentama (Component Based Software Development). Komponenta može označavati dio programa koji se može izvršiti na logičkom ili fizičkom nivou, jedno ili više sučelja, jedinstveni identifikatorPrednosti komponentalnog modela razvoja softvera su u uštedi vremena i troškova, brza je demonstracija sustava, povećava se produktivnost.Glavni nedostatak ovog modela razvoja je da nestaju generička znanja.

Opće aktivnosti softver projekta:- Specifikacija: što sistem treba raditi i razvojna ograničenja- Razvoj (dizajn i implementacija): stvara softverski sistem- Provjeravanje: formalni dokaz ispravnosti SW algoritama - Validacija (potvrđivanje): provjeravanje da li je softver ono što kupci žele- Izgradnja: promjena softvera kao odgovor na promjenjive zahtjeve

7

Definiranje zahtjeva

Analiza komponent

i

Modifikacija zahtjeva

Razvoj i integracija

Validacija sustava

Dizajn sustava

Projekt

PROJEKET - Vremenski ograničen skup radnji poduzet radi stvaranja jedinstvenog proizvoda (ili usluge)Operacije su:

- neprekidne - mogu se ponavljati - svrha im je podupiranje i održanje poslovanja, čak i kada se ciljevi promijene

Upravljanje projektom je primjena znanja, vještina, alata i tehnika u projektnim aktivnostima da bi se ispunili projektni zahtjevi.Upravljanje projektom uključuje:

- utvrđivanje zahtjeva,- postavljanje jasnih i ostvarivih ciljeva,- uspostavu ravnoteže između suprotstavljenih zahtjeva na kvalitetu, doseg, vrijeme i trošak,- prilagodbu specifikacija, planova i pristupa interesima i očekivanjima različitim zainteresiranim

stranama (eng. Stakeholders).

Izvori pogrešaka u SW:a) Prikupljanje zahtjeva: 56%b) Modeliranje: 27%c) Programiranje i testiranje: 7%d) Ostali čimbenici: 10%

Kritični faktori uspjeha:- Podrška menadžera- Jasni ciljevi i opseg- Kompletan projektni tim i organizacija- Treniranje i edukacija korisnika- Efektivna komunikacija- Projekt menadžment- Analiza zadataka- Izbor arhitekture- Sudjelovanje korisnika- Promjenjivo upravljanje

Programsko inženjerstvo je inženjerska disciplina koja se bavi praktičnim problemima razvoja velikih programskih sustava.Programska oprema:

- Programska podrška- Dio računalnog sustava koja nema fizičkih dimenzija- Opći pojam za sve vrste programa, programskih jezika, …

Računalna aplikacija:- Namjenski program, programska oprema- Računalno podržano rješenje jednog ili više poslovnih problema ili potreba- Informacijski sustav uobičajeno sadrži jednu ili više računalnih aplikacija

Informacijska tehnologija:

8

# p

ogre

šaka

veličina programa (KLOC ili FP)

programiranje i testiranje

projektiranje (modeliranje)

specifikacija zahtjeva

- Bilo koji oblik tehnologije koju ljudi koriste za upravljanje informacijama- Danas: računalna tehnologija (HW i SW) telekomunikacijskih tehnologija

Informacijsko inženjerstvoMetoda:

- Smišljen i organiziran skup procedura izrade- Sugerira proces obavljanja i način bilježenja- Definira primjenu tehnika i njihovo povezivanje

Tehnika:- “feature“ metode- Definira način izvršenja određenog postupka i dokumentiranja njegovog rezultata- Kaže 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 može koristiti kao kontrolna listaDefinira šest karakteristika kvalitete softvera koje se mogu koristiti u evaluaciji softvera

- Funkcionalnost: jesu li zahtijevane funkcije raspoložive?Funkcionalnost se najviše odnosi na to kako je softver s tehničke strane napravljen, tj. za koju svrhu je započet (prikladnost, preciznost, međudjelovanje, sukladnost, sigurnost).

- Pouzdanost: koliko je softver pouzdan?Pouzdanost govori o tome koliko je softver kvalitetno napravljen i kako se ponaša kada dođe do greške, pouzdanost je jedna od najvažnijih karakteristika softvera (zrelost, tolerancija na greške, sposobnost povratka).

- Prikladnost za uporabu: je li softver jednostavno koristiti?Prikladnost za uporabu govori o kompleksnosti softvera, koliko treba biti stručan da ga se može koristiti (razumljivost, jednostavnost, operativnost).

- Učinkovitost: koliko je softver efikasan?Učinkovitost se odnosi na same performanse softvera (ponašanje u odnosu na vrijeme, ponašanje u odnosu na resurse).

- Prikladnost za održavanje: koliko je jednostavno obavljati izmjene u softveru?Prikladnost za održavanje 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, usklađenost, 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:

- Može biti osnova za ponudu ugovora – dakle mora biti otvorena interpretacija- Može biti osnova za sam ugovor – dakle mora biti definiran do u detalje

Obje izjave mogu se pozvati na zahtjeve.Tipovi zahtjeva I:

9

1. Korisnički zahtjevi – tvrdnje prirodnim jezikom sa dijagramom usluga koje sistem podržava i njegova operativna ograničenja. Piše se za kupce.Mogu opisivati funkcijske i nefunkcijske zahtjeve na način da budu shvatljivi korisnicima koji nemaju veće tehničko znanje. Definirani su korištenjem prirodnog jezika, tabela i dijagrama kako bi ih korisnici razumjeli.

2. Sistemski zahtjevi – strukturirani dokument koji utvrđuje detaljne opise sistemskih funkcija, usluga i operativnih ograničenja. Definiraju što može biti implementirano tako da to može biti dio ugovora između klijenta i izvođača.

Tipovi zahtjeva II:1. Funkcijski zahtjevi – tvrdnje o usluzi koju sustav treba pružati, kako sustav treba reagirati na

određene ulaze i kako se sustav treba ponašati u svakoj situaciji zasebno.Opisuju funkcionalnost ili usluge sustava. Ovise o vrsti softvera, očekivanju 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 različito od strane korisnika i proizvođača.

2. Ne-funkcijski zahtjevi – sadrže ograničenja usluga ili funkcija koje sustava kao vremenska ograničenja, ograničenja na proces razvoja, standarda, …Opisuju svojstva i zahtjeve sustava, kao što su pouzdanost, vrijeme odziva, te zahtjevi memorije. Ne-funkcijski zahtjevi su još kritičniji od funkcijskih, ako oni nisu poznati, sustav je beskoristan.

3. Domenski zahtjevi – koji dolaze od domene aplikacije sustava i odražavaju karakteristične domene

SISTEMSKA ANALIZA I DIZAJNInicijacija projekta

Projekt sponzor je ključna osoba koja identificira poslovne vrijednosti koje će se dobiti korištenjem informacijske tehnologije.Kako započeti projekt?

- Poslovne potrebe trebaju voditi projekt- Projekt sponzor prepoznaje poslovne potrebe za novim sistemima i zahtjeva da se one

implementiraju- Poslovne potrebe određuju sistemske funkcionalnosti (što će raditi)- Poslovne vrijednosti projekta trebaju biti jasne

Sistemski zahtjeviDokument opisuje razloge za pokretanje projekta i očekivane vrijednosti sustavaKljučni elementi projekta:

- Projektni sponzor- Poslovne potrebe- Poslovni zahtjevi- Poslovne vrijednosti- Specijalni problemi i ograničenja

Analiza izvodljivosti

10

Detaljni poslovni slučajevi za projekt:

a) Tehnička izvodljivost (Technical feasibility)Možemo li izgraditi sustav?

- Upoznavanje korisnika i analitičara sa poslovnim područjem.- Upoznavanje sa tehnologijom: Je li sustav prije korišten? Što je novo u njemu?- Veličina projekta: Broj ljudi, vrijeme i mogućnosti.- Kompatibilnost sa postojećim sustavimab) Ekonomska izvodljivost (Economic feasibility)

Trebamo li graditi sustav?- Odrediti troškove i korist- Pridružiti vrijednosti troškovima i koristima- Odrediti protok novca- Odrediti funkciju održivosti:

o Net present value (NPV) – neto sadašnja vrijednost

neto sadašnja vrijednost=∑ PV ( prihodi )−∑ PV (rashodi)Ako je neto sadašnja vrijednost veća 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) – točka pokrića: u toj točki zarada pokriva uloženi novac, tj. zbroj

je jednak nuli. Što je duže vremena potrebno da se izjednači, projekt je riskantniji.Materijalni troškovi (Tangible cost) - uključuje prihod koji sistem omogućava da organizacija skupi, kao povećanje prodajeNematerijalni troškovi (Intangible cost) – su bazirani na intuiciji i vjerovanju radije nego “teškim brojevima“

c) Organizacijska izvodljivost (Organizational feasibility)Ako ga izgradimo hoće li on doći?

- Strateško podudaranje: Kako će se ciljevi projekta podudarati sa poslovnim ciljevima- Vlasnička analiza: Nositelj projekta, organizacijski menadžment, sistemski korisnici

Projekt menadžment

Projekt menadžment je proces planiranja i kontroliranja razvoja sustava u određenom vremenskom okviru sa minimalnim troškovima i pravom funkcionalnošću.Projekt menadžer ima najveću odgovornost za upravljanje stotinama pitanja i pravila koja trebaju biti pažljivo usklađena.Četiri koraka u upravljanju projektom:

- Određivanje veličine projekta- Stvaranje i vođenje poslovnog plana- Projektno osoblje

- Koordinacija projektnim aktivnostima

Određivanje veličine projekta

Projekt menadžment uključuje pravljenje kompromisa. Modificiranje jednog elementa zahtjeva podešavanje drugih.

11

Ocjena projekta:- Proces određuje projektne vrijednosti vremena i pokušaja- Izvor ocjene: metodologija u upotrebi, efekt bivšeg sustava, iskustvo programera

Kreiranje i izrada radnog plana

Identifikacija zadaća: korištenjem standardnih lista zadaćaTop-down pristup: identificira zadatak najvišeg nivoa, rastavlja ga na sve više manjih jedinica, organizira zadatak u analizu radne strukturaLista svih zadataka u analizi radne strukture sa: trajanje zadatka, tekući status zadatka, ovisnost zadataka, miljokaz (podaci).Gantt Chart: položeni stupčasti grafikon, koristan za nadgledanje statusa projekta u bilo koje vrijemePERT Chart: dijagram toka, ilustrira ovisnost zadataka i kritičnu stazu.

Koordinacija projektnim aktivnostima

Klasične pogreške:- Preoptimistični raspored- Greška u nadziranju rasporeda- Greška u ažuriranju rasporeda- Dodavanje ljudi u kasnoj fazi projekta

AS-IS sustav je sadašnji (postojeći) sustav i on može ali i ne mora biti kompjuteriziranTO-BE sustav je novi sustav koji se bazira na ažuriranim zahtjevimaSYSTEM PROPOSAL je cilj isporučen od faze analizeCilj analize je shvatiti zahtjeve novog sustava i razvoj sustava koji ih obilježava ili odlučiti da novi sustav nije potreban.

Determinacijski zahtjeviŠto je zahtjev?

- Tvrdnje što sustav može č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 informacijeb) Ne-funkcijski zahtjevi- Značajke ponašanja koje sustav mora imati: operativnost, djelovanje, sigurnost i kontrola i

politička svojstva

Određivanje zahtjeva:- Sudjelovanje poslovnih korisnika je nužno- Tri tehnike koje pomažu 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 učinkovitost za korisnike

c) Business Process Reengineering (BPR) – značajne promjene; cilj - radikalne promjene i poslovni napredak

Tehničke analize zahtjeva

a) Analiza trajanja (Duration Analysis)- Izračunati vrijeme potrebno za svaki korak procesa- Izračunati vrijeme potrebno za cijeli proces- Usporediti ih jer velika razlika uzrokuje loše razrađen proces- Moguća rješenja:

o Integracija procesa (Process integration) – promijeniti proces tako da ga radi manje ljudi,

svaki sa širim odgovornostimao Paralelizacija (Parallelization) – izmijeniti proces tako da se pojedinačni koraci odvijaju

istovremenoActivity-Based Costing (obračun troškova pojedinih aktivnosti)

- Izračunati troškove za svaki korak procesa- Uzeti u obzir i direktne i indirektne troškove- 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) Tehnološka analiza (Technology Analysis)- Analitičarev popis važnih i zanimljivih tehnologija- Upraviteljev popis važnih i zanimljivih tehnologija- Grupa procjenjuje kako se svako od tih može primijeniti u posao i kako bi posao mogao imati

koristi

Activity Elimination (Eliminacija aktivnost)- Određuje što bi se dogodilo kad bi se neka organizacijska aktivnost eliminirala- Koristi “force-fit“ za testiranje svih mogućnost

Tehnike prikupljanja zahtjevaa) Intervju- Najčešće korištena tehnika- Glavni koraci:

1. Odabir onog koji će vodit intervju: zasniva se na potrebnim informacijama; najbolje imati ljude iz različitih perspektiva (menadžeri, 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 općeniti plan intervjua (lista pitanja), potvrditi područje znanja; postaviti prioritete u slučaju da ne bude dovoljno vremena; pripremiti intervju (raspored, informirati o razlozima intervjuiranja, informirati o području o kojem se raspravlja)

4. Vođenje intervjua: ponašati se profesionalno i bez predrasuda; zapisati (snimiti) sve informacije; biti siguran da razumiješ sve probleme i elemente; odvojiti činjenice od mišljenja; zahvaliti na kraju intervjua; završiti na vrijeme)

5. Pripremanje zabilješki i izvješća sa intervjua (Post-Interview Follow-up): pripremiti zabilješke s intervjua; pripremiti izvješće sa intervjua; imati pregled intervjua i potvrditi izvješće; pregledati propuste i napraviti nova pitanja)

b) Joint Application Development (JAD) – Zajednički aplikacijski razvoj- Strukturna grupa procesa fokusira se na određivanje zahtjeva- Obuhvaća projektni tim, korisnike i menadžment koji rade skupa- Može smanjiti doseg potkradanja i do 50%- Jako korisna tehnika- Članovi JAD-a:

1. Podupiratelj: obučen za JAD tehnike; postavlja dnevni red i vodi procesa2. Pisar(i): bilježe sadržaj JAD sesija3. Korisnici i menadžment za poslovno područje sa proširenim i detaljnim znanjem

c) Upitnici (Ankete)- Skup napisanih pitanja, često poslanih velikom broju ljudi- Mogu biti u papirnatom ili elektronskom obliku- Bira sudionike koristeći primjere iz populacije- Dizajnira pitanja za jasnu i olakšanu analizu- Anketno follow-up izvješćed) Analiza dokumenata (Document Analysis)- Proučavanje postojećih materijala koji opisuju sadašnji sustav- Oblici, izvješća, priručnici opisuju formalni sustav- Korisnikove promijene u postojećim izvješćima ili ne korištenjem postojećih oblika/izvješća

pokazuje da sustav treba modificiratie) Promatranje (Observation)- Gledanje kako proces djeluje- Korisnici/upravitelji često ne pozovu točno ono što rade- Provjera informacija prikupljenih na druge načine- Biti svjestan da se ponašanje 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- Uključenost korisnika- Cijena- Kombinacija tehnika

Planiranje razvoja informacijskog sustava:- Planiranje (zašto raditi IS)

14

Proučiti poslovnu misiju Definirati ustroj informacija Analizirati poslovno područje

- Analiza (tko ga koristi, što radi, kada i gdje) Analiza konkurencije

1. Prijetnja novih konkurenata2. Prijetnja zamjene proizvoda i usluga3. Smanjenje ovlasti korisnika4. Smanjenje ovlasti dobavljača5. Nadmetanje među postojećim konkurentima

Analiza niza vrijednostiOsnovne vrijednosti:1. Logistički ulaz2. Logistički izlaz3. Operacije4. Prodaja i marketing5. UslugePomoćne vrijednosti:1. Zajednička infrastruktura2. Menadžment ljudskih resursa3. Razvoj tehnologije4. nabava

- Dizajn (kako će IS raditi)- Izrada (prema zahtjevima)- Primopredaja (provjera zahtjeva)- Održavanje(dorada IS)

SOFTVERSKI PROCESI

Softverski proces je set aktivnosti koje su nužne za razvoj softverskog sustava:1. Specifikacija 2. Dizajn3. Validacija (potvrđivanje, provjera)4. Razvoj

Model softverskog procesa je apstraktni prikaz procesa. On predstavlja opis procesa iz nekog konkretnog gledišta. Opći modeli za razvoj softvera:

- Waterfall model: razdvaja i određuje faze specifikacije i razvoja. Faze razvoja waterfall modela1. Analiza zahtjeva i definicija2. Sistemski i softverski dizajn3. Implementacija i testiranje jedinica4. Integracija i sistemsko testiranje5. Operacije i održavanjeProblemi waterfall modela:1. Glavna teškoća kod ovog modela je obuhvaća promjene nakon što je proces napravljen. Jedna

faza mora biti završena prije nego se pređe na slijedeću. 2. Nefleksibilno razdjeljivanje projekta na odvojene faze čini teškoće u odgovoru na promjenjive

korisničke zahtjeve

15

3. Ova metoda je jedino primjenjiva kada su zahtjevi dobro shvaćeni i promjene su poprilično ograničene za vrijeme dizajniranja procesa

- Evolucijski razvoj: specifikacija, razvoj i provjera su umetnuti. 1. Istraživački razvoj: cilj je raditi s kupcima i napraviti konačni sustav na inicijalnim

koncepcijskim specifikacijama. Treba se započeti sa dobro poznatim zahtjevima i dodati nove zahtjeve i nove mogućnosti koje su predložene od strane korisnika.

2. Throw-away prototyping: cilj je razumjeti sistemske zahtjeve. Treba započeti sa jedva razumljivim zahtjevima i razjasniti što zapravo treba.

Problemi:1. Nedostatak vidljivosti procesa2. Sustavi su često nedovoljno strukturirani3. Specijalne sposobnosti mogu biti neophodnePrimjenjivost:1. Za male ili srednje velike interaktivne sustave2. Za dijelove većih sustava 3. Za kratkotrajne sustave

- Component-based softverski inženjering: sustav je sastavljen iz postojećih komponenti. Bazira se na planskom ponovnom korištenju gdje se sustav sastavlja od postojećih komponenti ili COTS (Commercial-off-the-shelf) sustava. Faze procesa:1. Analiza komponenti2. Modifikacija zahtjeva3. Dizajn sistema sa ponovnom upotrebom4. Razvoj i integracijaOvaj pristup se sve više upotrebljava kao komponenta standarda u upotrebi. Razvoj ponovnom upotrebom:Zahtjevi sustava uvijek su uključeni u projekt, pa procesne iteracije ,gdje su ranije faze prerađene, su uvijek dio procesa velikog sustava. Iteracija može biti primijenjena na bilo koji opći procesni model. Dva različita pristupa:1. Isporuka dodavanjemRazvoj i isporuka su rastavljeni na dodatke gdje svaki dodatak dostavlja dio traženih funkcionalnosti. Korisnički zahtjevi imaju prioritet i zahtjevi najvećeg prioriteta su uključeni u rane dodatke. Jednom kada je razvoj dodatka počeo, zahtjevi su zaleđeni, a zahtjevi za kasnije dodatke se mogu nastavljati razvijati.Prednosti:

o Korisniku proizvod može biti dostavljen sa pojedinim dodacima, tako da je funkcionalni

sustav dostupan ranijeo Raniji dodaci se ponašaju kao prototip, kako bi se pomoglo iznijeti na vidjelo zahtjeve za

kasnije dodatkeo Manji rizik od neuspjeha cjelokupnog projekta

o Usluge najvećeg prioriteta u sustavu nastojati podvrgnuti najvećem testiranju

2. Spiralni razvojProces se predstavlja kao spirala radije nego niz aktivnosti sa praćenjem 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 izričito utvrđuje i rješava kroz proces. Sektori spiralnog modeliranja su:

o Objektivne postavke - konkretni ciljevi su identificirani za faze

16

o Ocjena rizika i njegovo smanjenje – rizik se utvrđuje i aktivnosti se ispravljaju da bi se

smanjioo Razvoj i validacija (provjera) – razvojni model za sustav se bira što mobe biti bilo koji

opći modelo Planiranje – projekt se pregleda i sljedeća 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 uključen u razvoj i programiranje

Projektne aktivnosti:1. Software specification (specifikacija softvera)

Definira što usluge zahtijevaju i sadržaj sistemskih operacija i razvoj. Projektiranje zahtjeva sustava:

- Studija provedivosti- Otkrivanje zahtjeva i analiza- Specifikacija zahtjeva- Provjeravanje zahtjeva2. Software design and implementation (dizajn softvera i implementacija)

Proces promjene sistemskih specifikacija u izvršni sustav.Dizajn softvera – dizajniranje strukture softvera koji realizira specifikacije.Implementacija – prevodi strukturu u izvrši program.Aktivnost dizajna i implementacije su u bliskoj vezi i mogu biti u međudjelovanju.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 obično pohranjen kao set grafičkih modela. Mogući modeli su: objektni model, sekvencijalni model, oblik izmjenjivog modela, strukturni model, model toka podataka (data-flow).Programiranje i uklanjanje pogrešaka - prebacivanje dizajna u program i micanje greški iz programa. Programiranje je konkretna aktivnost, nema općih programerski procesa. Programeri podvrgavaju neke programe testiranju da bi otkrili propuste u programu i maknuli ih u procesu uklanjanje pogrešaka.

3. Software validation (provjeravanje softvera)Verifikacija i validacija (V&V) namjerava pokazati da sustav potvrđuje svoje specifikacije i odgovara zahtjevima kupcima sustava. Uključuje provjeravanje i pregled procesa i testiranje sustava.Faze testiranja:

- Testiranje komponenti ili jedinica- Testiranje sustava- Testiranje prihvaćanja4. Software evolution (razvoj softvera)Softver je sam po sebi fleksibilan i može se mijenjati. Kako se mijenjaju zahtjevi kako se mijenjaju poslovne okolnosti, softver koji podržava posao također mora uključivati promjene.

17

Rational Unified Process (RUP) – je moderni procesni model izveden iz rada na UML-u i prati proces. Obično se opisuje iz tri perspektive:

- Dinamična perspektiva koja prikazuje faze u vremenu - Statična perspektiva koja pokazuje procese po aktivnostima- Praktična perspektiva koja predlaže dobre postupke

RUP faze razvoja modela:- Početak – predstavlja poslovne uvijete za sustav- Obrada – razvoj i razumijevanje problema domene i arhitekture sustava- Konstrukcija – dizajn sustava, programiranje i testiranje- Promjena – prosljeđuje sustav u operativnu okolinu

Computer-aided software engineering (CASE)CASE je softver za podupiranje softverskog razvoja i razvojnog procesa. Automatizacija aktivnosti:

- Grafički editor za razvoj modela sustava- Podatkovni direktorij za upravljanje dizajnerskim entitetima- Grafički UI konstruktor za konstrukciju korisničkog interface-a- Pronalaženje grešaka za pronalaženje programskih nedostataka- Automatsko prevođenje za proizvodnju nove verzije programa

CASE tehnologija:- Softverski inženjerski zahtjevi kreativnih misli – to nije lako automatizirati- Softverski inženjering je timska aktivnost i, za velike projekte, mnogo se vremena provodi u

timskoj interakciji. CASE tehnologija ovo zapravo ne potiče.CASE klasifikacija:

- Klasifikacija pomaže razumjeti različite tipove CASE alata i njihovih aktivnosti za podupiranje procesa.

- Funkcionalna perspektiva – alati su klasificirani prema njihovoj specifičnoj 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 zadaće kao dizajniranje dosljedne provjere, tekst editor…- Radni stol: podupiranje procesnih faza kao specifikacija i dizajn. Obično uključeno nekoliko

integracijskih alata- Okolina: podupiranje svih bitnih dijelova cijelog softverskog procesa. Obično uključeno nekoliko

integriranih radnih stolova-

SOFTVERSKI ZAHTJEVI

Što je zahtjev?Može imati doseg visoko – razinskih apstraktnih stavki usluge ili sistemskih ograničenja sve do detaljnih matematičkih funkcijskih specifikacija.

Funkcijski i ne-funkcijski zahtjevi:Funkcijski zahtjevi su tvrdnje o uslugama koje sustav treba podržavati, kako sustav treba reagirati pri određenim unosima i kako se sustav treba ponašati u pojedinim situacijama. Opisuju funkcionalnost ili sistemski uslugu. Ovise o tipu softvera, očekivanju korisnika i tipu sustava na kojem će softver biti

18

korišten. Mogu biti visoko – razinske tvrdnje što sustav treba raditi , i trebaju opisivat što sustav treba raditi do u detalje. LIBSYS sustav: library (bibliotekarni) sustav podržava jedan interface naspram niza baza podataka članova od različitih biblioteka. Korisnici mogu tražiti, preuzimati i printati članke za osobne studije.Primjeri zahtjeva:

- Korisnik mora biti u mogućnosti da pretražuje ili sve iz inicijalnog seta baze podataka ili izabrati dio njih.

- Sistem treba podržavati odgovarajuće poglede za korisnika da bi mogao čitati dokumente iz spremišta dokumenata.

- Svaka naredba treba biti alocirana jedinstvenim identifikatorom, što bi korisniku omogućilo da ih kopira u korisničko privremeno područje pohranjivanja.

Problemi sa zahtjevima:- Problem se nameće kada zahtjevi nisu točno precizirani- Višeznačajni zahtjevi mogu biti interpretirani na različite načine od strane korisnika i programera- Razmatrajući termin 'odgovarajući preglednik' možemo reći da on od gledišta korisnika znači

preglednik sa specijalnom svrhom za dokumente različitih tipova, a sa strane programera on omogućava pregled teksta koji pokazuje sadržaj dokumenata.

Ne-funkcijski zahtjevi predstavljaju ograničenja usluga ili funkcija koje sustav nudi kao vremensko ograničenje, ograničenje razvoja procesa, standarda, … Oni definiraju sistemska svojstva i ograničenja kao pouzdanost, vrijeme odgovora i pohranu zahtjeva. Ograničenje mogu biti mogućnosti I/O uređaja, sistemske reprezentacija,… Zahtjevi također mogu biti specificirani koristeći CASE sustav, programski jezik ili razvojne metode. Ne-funkcijski zahtjevi mogu biti još kritičniji od funkcijskih. Ako oni nisu takvi sustav je beskoristan.Ne-funkcijska klasifikacija:

- Produktivni zahtjevi – zahtjevi koji specificiraju kako se dostavljeni proizvod mora ponašati u konkretnim uvjetima, kao izvođenje sustava, pouzdanost, …

- Organizacijski zahtjevi – zahtjevi koji su posljedica organizacijske politike i procedura, kao standardna upotreba procesa, implementacija zahtjeva,…

- Vanjski zahtjevi – zahtjevi koji se nameću od čimbenika koji su van sustava i razvojnog procesa, kao međusobni 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, ograničenja na postojeće zahtjeve ili definiraju specifične proračune. Ako domenski zahtjevi nisu zadovoljeni, sustav neće raditi.Problemi sa zahtjevima:

- Razumijevanje – zahtjevi su iskazani u jeziku domenske aplikacije- Bezuvjetnost – domenki stručnjak razumije područje tako dobro da ne misli o pravljenju

domenskih zahtjeva izričito (jasno).

Tipovi zahtjeva:Korisnički zahtjevi: tvrdnje na prirodnom jeziku sa dijagramima usluge koju sustav podržava i njegova ograničenja. Pisan je za kupca.Oni moraju opisivati funkcijske i ne-funkcijske zahtjeve na način da su oni razumljivi sistemskim korisnicima koji nemaju detaljno tehničko znanje. Korisnički zahtjevi su definirani koristeći prirodni jezik, tabele i dijagrame i razumljivi su svakome korisniku. Problemi sa prirodnim jezikom:

- Nedostatak jasnoće – preciznost je teška bez pravljenja dokumenta teškog za čitanje

19

- Zbunjujući zahtjevi – funkcijski i ne-funkcijski zahtjevi skloni su miješanju- Stapanje zahtjeva – nekoliko različitih zahtjeva može biti izrečeno zajedno

LIBSYS zahtjevi trebaju podržavati sustav financijskog obračuna koji čuva zapise o svim isplatama korisnicima sustava. Problemi ovih zahtjeva su:

- Zahtjevi baze podataka uključuju i konceptualne i detaljne informacije (opis koncepta sustava financijskog obračuna koji treba biti uključen u LIBSYS, te detalje kako menadžer može konfigurirati sustav)

- Mreža zahtjeva miješa tri različite vrste zahtjeva:o Konceptualni funkcijski zahtjevi (potreba za mrežom)

o Ne-funkcijski zahtjevi (mrežne jedinice)

o Ne-funkcijski UI zahtjevi (mrežno prebacivanje)

Vodič za pisanje zahtjeva:- Izumiti standardni format i koristiti ih za sve zahtjeve- Koristiti jezik na konzistentan način- Označiti tekst da bi se identificirale ključne riječi zahtjeva- Izbjegavati korištenje kompjuterskog žargona

Sistemski zahtjevi: strukturiran dokument sa detaljnim opisima sistemskih funkcija , usluga i njegovih ograničenja. Definiraju što treba biti implementirano, pa mogu biti dio ugovora između klijenta i ugovaratelja. Više detaljnih specifikacija o funkcijama sustava, uslugama i ograničenjima. Zahtjevi i dizajn:U principu, zahtjevi trebaju određivati što treba raditi i dizajn treba biti opisan. U praksi, zahtjevi i dizajn su nerazdvojivi:

- Arhitektura sustava može biti dizajnirana prema strukturi zahtjeva- Sustav može biti inter-operabilan sa drugim sustavima da bi se ostvarili zahtjevi dizajna- Korištenje specifičnog dizajna može biti zasnovano na domenskim zahtjevima

Problem sa NL(Natural Language) specifikacijama:- Dvosmislenost – čitač i pisac zahtjeva moraju interpretirati iste riječi na isti način. NL je prirodno

dvosmislen pa je to jako teško- Pre-fleksibilnost – ista stvar može biti rečena na bezbroj različitih načina 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

Tablične specifikacije:- Koristiti dodatke prirodnom jeziku- Obično je korisno kada se definiraju brojne moguće alternative

Sekvencijalni dijagram:- Prikazuju se dijelovi događaja koji zauzimaju mjesto tijekom interakcije korisnika sa sustavom- Čitaju se od vrha do dna akcije

20

Interface specifikacije:- Većina sustava mora surađivati 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 bilješke su djelotvorne tehnike za interface specifikacije

Dokumentacija zahtjeva:- To je službena izjava o tome što je neophodno za programere sustava- Treba uključivati i definiciju korisničkih zahtjeva i specifikaciju sistemskih zahtjeva- To NIJE dizajnerski dokument. Što je više moguće , treba biti uključeno ŠTO sustav treba raditi,

radije nego KAKO to treba raditi.Struktura dokumentacije zahtjeva:

- Predgovor- Uvod- Kazalo- Definicija korisničkih zahtjeva- Arhitektura sustava- Specifikacije sistemskih zahtjeva- Sistemski modeli- Razvoj sistema- Dodatci- Sadržaj

PROCES PROJEKTIRANJA ZAHTJEVA

Ovaj se dio bavi objašnjavanjem 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 uključeni i organizaciji razvoja zahtjeva. Kako god, postoji mnogo općih aktivnosti zajedničkih svim procesima:

- Otkrivanje zahtjeva- Analiza zahtjeva- Provjera valjanosti zahtjeva- Upravljanje zahtjevima

Studija provedivost

Studija provedivosti odlučuje hoće li predloženi sustav biti vrijedan truda. Ova studija provjerava sljedeće:

- Pridonosi li sistem organizacijskim ciljevima- Hoće li sistem moći biti projektiran sa aktualnom tehnologijom i u okvirima budžeta- Hoće li sistem moći biti integriran sa ostalim sistemima koji su u upotrebi

Implementacija:- Zasniva se na informacijskim ocjenama, zbirke informacija i napisanog izvješća- Pitanja za ljude iz organizacije:

o Što ako sustav nije implementiran?

21

o Koji su trenutni problemi s procesom?

o Kako će predloženi sustav pomoći?

o Koji će biti problemi integracije?

o Je li potrebna nova tehnologija? Koje sposobnosti?

o Koji su resursi potrebni za podržavanje predloženog sustava?

Otkrivanje i analiza:- Ponekad se naziva otkrivanje zahtjeva ili pronalazak zahtjeva- Uključuje tehnički rad sa kupcima da bi se našlo nešto o aplikacijskoj domeni, uslugama koje

sustav treba podržavati i sistemska operacijska ograničenja- Mogu biti uključeni krajnji korisnici, menadžeri, projektanti uključeni u održavanje, domenski

eksperti, … Ovo se naziva interesna grupa (stakeholders).

Problemi sa analizom zahtjeva:- Interesna grupa zapravo ne zna što želi- Interesna grupa izriče zahtjeve sa vlastitim izrazima- Različiti članovi utjecajne grupe mogu imati proturječne zahtjeva- Organizacijski i politički faktori mogu imati utjecaj na sistemske zahtjeve- Izmjena zahtjeva tijekom procesa analize. Mogu se pojaviti nove interesne grupe i promijeniti

poslovno okruženje

Aktivnosti procesa:- Otkrivanje zahtjeva- Klasifikacija i organizacija zahtjeva- Prioriteti i dogovaranje- Dokumentacija zahtjeva

Točke gledišta (viewpoints):Točke gledišta su načini strukturiranja zahtjeva da bi predstavili različite perspektive interesne grupe. Interesne grupe mogu biti klasificirane u različita gledišta. Više-perspektivna analiza je važna jer nema jednog ispravnog načina za analiziranje sistemskih zahtjeva. Vrste točki gledišta:

- Interaktivne točke gledišta – ljudi ili sustavi koji su u direktnom međudjelovanju sa sustavom- Indirektne točke gledišta – interesne grupe koje same ne koriste sustav ali imaju utjecaja na

zahtjeve- Domenske točke gledišta – domenske karakteristike i ograničenja koja imaju utjecaj na zahtjeve

Upotreba točki gledišta:- Daje i prima sistemske usluge- Sistem koji međudjeluje direktno sa specificiranim sustavom- Regulacije i standardi- Izvor poslovnih i ne-funkcionalnih zahtjeva- Programeri koji razvijaju i održavaju 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 rješavaju zajedno sa

interesnim grupama

22

Intervju u praksi:- Obično mješavina otvorenog i zatvorenog intervjuiranja- Intervjuiranje je dobro za razumijevanje što interesne grupe rade i kako će one međudjelovati sa

sustavom- Intervju nije dobar za razumijevanje domenskih zahtjeva (ne razumije se specifična domenska

terminologija)Djelotvorni intervju:

- Onaj tko intervjuira mora biti nepristran, sa željom da sluša 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 može biti korišten. Oni trebaju uključivati:

- Opis početne situacije- Opis normalnog tijeka i događaja- Opis što može poći loše- Informaciju i drugim konkurentnim aktivnostima- Opis stanja kada se scenarij završi

Socijalni i organizacijski faktori:- Softverski sustav se koristi u socijalnom i organizacijskom kontekstu. To može utjecati ili čak

dominirati u sistemskim zahtjevima- Socijalni i organizacijski faktori nisu samo jedna točka gledišta, ali imaju utjecaja na sve točke

gledišta- Dobar analitičar mora biti osjetljiv na ove faktore , no oni trenutačno nemaju utjecaja na njihovu

analizu

Etnografija:- Socijalni znanstvenik provodi znatno vrijeme promatrajući i analizirajući kako ljudi zapravo rade- Ljudi ne moraju objašnjavati i opisivati njihov posao- Socijalni i organizacijski faktori mogu biti važni pri promatranju- Etnografske studije pokazuju da je posao obično bogatiji i mnogo kompleksniji nego što je

prikazan na jednostavnom sistemskom modeluUsredotočena etnografija:

- Kombinira etnografiju sa prototipom- Razvoj prototipom rezultira neodgovorenim pitanjima koja se fokusiraju na etnografsku analizu- Problem sa etnografijom je da studije postoje praktično što može imati povijesnu bazu koja više

nije više važna

Provjera zahtjeva:- Ispravnost – da li sistem podržava funkcije koje najbolje podržavaju potrebe kupaca?- Dosljednost – postoji li konflikt među zahtjevima?- Kompletnost – da li su sve nužne funkcije uključene?- 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 održan dok se određeni zahtjevi još formuliraju- I klijent i ugovarač trebaju biti uključeni u pregled- Pregledi mogu biti formalni (sa potpunom dokumentacijom) i neformalni. Dobra komunikacija

između programera, kupca i korisnika može riješiti probleme u vrlo ranoj fazi

Provjera pregleda- povjerljivost – jesu li zahtjevi realistično testirani?- Razumljivost – jesu li zahtjevi dobro shvaćeni?- Sljedivost – jesu li originalni zahtjevi jasno utvrđeni?- Prilagodljivost – može li zahtjev bit izmijenjen bez prevelikog utjecaja na druge zahtjeve?

Menadžment zahtjeva: je proces upravljanja izmjenjivim zahtjevima tijekom procesa projektiranja zahtjeva i razvoja sustava. Zahtjevi su neizbježno nepotpuni i nekonzistentni:

- Novi zahtjevi pojavljuju se tijekom procesa zbog izmijenjenih poslovna potreba i boljeg shvaćanja razvoja sustava

- Različite točke gledišta imaju različite zahtjeve koji su često kontradiktorni

Izmjena zahtjeva:- Prioritetni zahtjevi sa različiti točki gledišta mijenjaju se tijekom razvojnog procesa- Sistemski korisnici mogu specificirati zahtjeva iz poslovne perspektive koji se sukobljavaju sa

zahtjevima krajnjih korisnika - Poslovna i tehnička okolina sustava mijenja se tijekom razvoja

Trajni i izbrisivi zahtjevi:- Trajni zahtjevi: ustaljeni zahtjevi izvode se iz osnovne aktivnosti kupčeve 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 – značenje informacije o odnosu između zahtjeva

Sljedivost se tiče odnosa između zahtjeva, njihovih izvora i sistemskog dizajna Sljedivost izvora – veza od zahtjeva da interesne grupe koja predlaže ove zahtjeve Sljedivost zahtjeva – veza između 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 između tih faza je djelomično automatiziran

24