PROJEKTIRANJE INFORMACIJSKIH SUSTAVA Sustav je grupa objekata/entiteta objekata/entiteta vezanih meĎusobnim odnosima odnosima s ciljem ostvarivanja 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 sintakse Znanje 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 . I sti podaci mogu biti različito interpretirani od strane različitih ljudi u ovisnosti o njihovom znanju Informacijski sustav je grupa ljudi, procesa, organizacijske probleme ili da stvori nove prilike. prili ke.
podataka, mreža i tehnologija stvorena da riješi
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 – tehnička oprema - Software – programska oprema - Orgware – organizacijska komponenta - Lifeware – izvršitelj – 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) PLANIRANJE
Ova faza je proces razumijevanja zašto informacijski sustav treba biti izgraĎen. TakoĎer se u ovoj fazi adnji informacijskog sustava. Ova faza sastoji se od dva izgraĎuje projektni tim koji će suraĎivati u izgr adnji koraka planiranja: 1. Inicijacija projekta – kako – kako smanjiti troškove ili povećati prihode 2. Upravljanja projektom (Projekt menadžment) – menadžer – menadžer projekta
napravi poslovni plan i uvodi tehnike koje pomažu 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 istražuje postojeće sustave, istražuje dozvoljene mogućnosti mogućnosti i razvija koncept za novi sustav. Ova faza sastoji se od tri koraka: 1. Analiza strategije – uključuje – uključuje analizu postojećih susta va 2. Prikupljanje zahtjeva – analiza ovih informacija vodi razvoju novog sustava 3. Prijedlog sustava (System proposal) – prezentira – prezentira se projektnim sponzorima i ostalim ključnim pojedincima koji odlučuju odlučuju o tome da li projekt treba nastaviti. Prijedlog sustava opisuje s kojim će se poslovnim zahtjevima susresti novi sustav. c) DIZAJN ovoj fazi odlučuje se : kako će sustav funkcionirati
U u uvjetima hardvera, softvera i mrežne infrastrukture; korisnička sučelja; forme i izvješća koja će se koristiti; programi, baze pod ataka i datoteke koje će biti potrebne. Faza dizajna ima četiri koraka: 1. Strateški dizajn – hoće – hoće li sustav biti razvijan unutar neke tvrtke ili van nje? 2. Dizajn arhitekture – opisuje – opisuje hardver, softver i mrežnu infrastrukturu koja će se koristiti 3. Karakteristike baza podataka i datoteka – ovi dokumenti odreĎuju koji podaci i gdje će biti pohranjeni 4. Dizajn programa – definira – definira koji programi trebaju biti napisani što će oni raditi d) IMPLEMENTACIJA U ovoj fazi sustav je već nabavljen ili razvijen. Ova faza obično najd ulje 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 pripremiti podršku za instalirani sustav 3. Plan podrške – uključuje – 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 metodologija
Ova metodologija pažnju posvećuje definiranju sadržaja podataka u memoriji i kako su oni organizi rani. Ova metodologija koristi podatkovni model kao jezgru sustava. c) Object-oriented metodologija
Ova metodologija nastoji balansirati žarište izmeĎu procesa i podataka. UML (Unified Modeling Language) je opći jezik modeliranja. Koristi se za opisivanje sus tava 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 druge a) Waterfall development (vodopadni razvoj)
pomičući se od jedne faze do
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 Prototyping
Ova 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
dokumentiranja, te vremena utrošenog u to. Projekt ističe jednostavne, iterativne aplikacijske razvoje, a najpoznatije metode su: XP (Extreme Ova kategorija fokusira se na eliminaciju pretjeranog modeliranja i
Programming), 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čnost 2. Poslovnost 3. Analitičnost 4. Moralnost 5. Mora biti dobar menadžer 6. Mora biti interpersonalan
Kategorije analitičara: 1. Poslovni analitičar 2. Sistemski analitičar 3. Infrastrukturni analitičar 4. 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
Prvo rješenje Specifikacija Grubi opis zahtjeva
Razvoj
Međurješenje
Provjera
zahtjevima, nadogradnji i promjenama zahtjeva, a istovremeno i dosljednom
Konačno rješenje
poštivanju rokova. Softver se razvija u ciklusima, gdje svaki
ciklus dograĎuje funkcionalnost aplikacija. Korisnik u svakom od ciklusa ocjenjuje
RAD I ODRŽAVANJE
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
Iteracija 1
Iteracija 2
Iteracija 3
na manje dijelove, faze traju kraće, za svaki dio se proĎu sve faze, brže se dolazi do softvera koji
6
korisnik može probati, ali je i lošija dokumentacija. 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
Definiranje zahtjeva
Analiza komponent i
orijentirane klase mogu više puta koristiti u različitim aplikacijama i arhitekturama. Razvoj je baziran na komponentama (Component Based Software Development).
Modifikacij a zahtjeva
Dizajn sustava
Razvoj i integracija
Validacija sustava
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 identifikator Prednosti komponentalnog modela razvoja softvera su u uštedi vremena i troškova, brza je demonstracija sustava, povećava se pr oduktivnost. 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 7
-
Izgradnja: promjena softvera kao odgovor na promjenjive zahtjeve Projekt
PROJEKET - Vremenski ograničen skup radnji podu zet 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 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 aplikacij a: - Namjenski program, programska oprema - Računalno podržano rješenje je dnog ili više poslovnih problema ili potreba - Informacijski sustav uobičajeno sadrži jednu ili više računalnih aplikacija
velikih
8
Informacijska tehnologija: - Bilo koji oblik tehnologije koju ljudi koriste za upravljanje informacijama - Danas: računalna tehnologija (HW i SW) telekomunikacijskih tehnologija Informacijsko inženjerstvo Metoda: - 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 lista Definira š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, sukladno st, 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 naj važ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 t estiranje). - 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 shva tljivi 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 opera tivnih 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 odreĎene ulaze i k ako se sustav treba ponašati u svakoj situaciji z asebno.
treba reagirati na
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 fun kcijskih, 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 DIZAJN Inicijacija 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 zahtjevi
Dokument opisuje razloge za pokretanje projekta i očekivane vrijednosti sustava Ključ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 sus tav prije korišten? Što je novo u njemu? - Veličina projekta: Broj ljudi, vrijeme i mogućnosti. - Kompatibilnost sa postojećim sustavima b) 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
∑() ∑() 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 prodaje Nematerijalni 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ća Top-down pristup: identificira zadatak najvišeg nivoa, rastavlja ga na sve više manjih jedinica, organizira zadatak u analizu radne struktura
Lista 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
vrijeme
PERT 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 kompjuteriziran TO-BE sustav je novi sustav koji se bazira na ažuriranim zahtjevima SYSTEM PROPOSAL je cilj isporučen od faze analize
Cilj 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 informacije b) 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 ot kriti 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 odgovornostima Paralelizacija (Parallelization) – izmijeniti proces tako da se pojedin ačni koraci odvijaju istovremeno Activity-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 o
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 koristi
u posao i kako bi posao mogao imati
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 zahtjeva a) 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 znanja; postaviti prioritete u slučaju da
plan intervjua (lista pitanja), potvrditi područje 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 procesa 2. Pisar(i): bilježe sadržaj JAD sesija 3. 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šće d) 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 modificirati e) 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 konkurenata 2. Prijetnja zamjene proizvoda i usluga 3. Smanjenje ovlasti korisnika 4. Smanjenje ovlasti dobavljača 5. Nadmetanje meĎu postojećim konkurentima Analiza niza vrijednosti Osnovne vrijednosti: 1. Logistički ulaz 2. Logistički izlaz 3. Operacije 4. Prodaja i marketing 5. Usluge
Pomoćne vrijednosti: 1. Zajednička infrastruktura 2. Menadžment ljudskih resursa 3. Razvoj tehnologije 4. 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. Dizajn 3. 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 modela 1. Analiza zahtjeva i definicija 2. Sistemski i softverski dizajn 3. Implementacija i testiranje jedinica 4. Integracija i sistemsko testiranje 5. Operacije i održavanje Problemi 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 procesa 2. Sustavi su često nedovoljno strukturira ni 3. Specijalne sposobnosti mogu biti neophodne Primjenjivost: 1. Za male ili srednje velike interaktivne sustave 2. 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 C OTS (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 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 dodavanjem
Razvoj 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 ranije
o
Raniji dodaci se ponašaju kao prototip, kako bi se pomoglo iznijeti na vidjelo zahtjeve za
o
kasnije dodatke Manji rizik od neuspjeha cjelokupnog projekta
o
Usluge najvećeg prioriteta u sustavu nastojati podvrgnuti najvećem testiranju
2. Spiralni razvoj
Proces 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 smanjio Razvoj i validacija (provjera) – razvojni model za sustav se bira što
o
opći model Planiranje – projekt se pregleda i sljedeća faza je spirale je planiranje
o
-
ispravljaju da bi se mobe biti bilo koji
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 zahtjeva 2. Software design and implementation (dizajn softvera i i mplementacija)
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 programer ski 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ćanja 4. 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ženjer ski 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 d izajn. 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 podatak a č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 domenskih zahtjeva izričito (jasno) .
da ne misli o pravljenju
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 k onzistentan 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 b iti 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 z asnovano 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 n eophodno 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 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
treba raditi,
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 ko ji 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? Koji će biti problemi integracije?
o
Je li potrebna nova tehnologija? Koje sposobnosti?
o
Koji su resursi potrebni za podržavanje predloženog sustava?
o
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 interesn a 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 modelu
Usredotoč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 tije kom 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 – u pravljanje procesom promjena je proces rada čije faze mogu biti definirane i izmjena informacije izmeĎu tih faza je djelomično automatiziran
-
24
