STRATEGIJA I PLANIRANJE ICT TEHNOLOGIJA modul - Predvianje i analiza

Projekat Projekat predstavlja skup aktivnosti koji su grupisani tako da kao celina doprinose ostvarenju ukupnog cilja. Ono to projekat odvaja od ostalih kategorija jeste da on nije proces koji je u toku, ve je prolazan a dizajniran je tako da njegova realizacija daje neki konaan proizvod. Projekat uvek ima jasno definisan poetak i kraj. Projekat se obino (dodue ne i uvek) pokree na inicijativu korisnika, njegove komponente definie rukovodilac projekta, a realizacija je u nadlenosti projektnog tima koji sastavlja rukovodilac. Neki projekti po prirodi mogu biti eksperimentalni, kada se zahteva razvoj neega to ispunjava potrebe industrije ili zadovoljava strategijske ciljeve, ali se za krajnje rezultate ne moe garantovati zato to do sada nije bilo slinih pokuaja. Projekat ne bi smeo da se bavi neim to je ve dobro poznato, ve neim to bi povealo efikasnost ve poznatog. ta su procesni modeli? Procesni model je vodi u izboru aktivnosti u toku projekta i istovremeno predstavlja ivotni ciklus projekta. Postoje statini modeli i modeli kod kojih nisu primenljive kontrolne take. Takva dva modela su model vodopada i spiralni model. Ovi modeli omoguavaju razliite pristupe u ivotnom ciklusu projekta. Vodopadni model Kod vodopadnog modela ceo projekat se razvija frontalno kroz vie faza. Prelazak iz jedne faze u drugu fazu se vri tek onda kada se pojedina faza zavri i kad se pree kontrolna taka faze.

Posle prve faze, Planiranje razvoja, sistem se analizira u okviru druge faze. Zatim u okviru tree faze vri se projektovanje celog sistema, pa implementacija (kodiranje i testiranje) da bi u okviru poslednje faze sistem doao u stanje odravanja.

Za vreme sistem analize moe doi do promene zahteva korisnika, a samo odlaganje pisanja programa i zakasneli i nedovoljni povratan uticaj korisnika dovode do toga da implementirani softver ne zadovoljava zahteve, pa je potrebno odmah vriti izmene. Ponovno prolaenje kroz sve faze je preskupo. Vodopadni model najbolje se primenjuje kod projekata gde su projektni zadaci jasno definisani i koji se nee bitnije menjati u budunosti. Zato to model ima fiksne take prelaska iz faze u fazu, mogu se lako pratiti rasporedi obaveza i pridodati jasni odgovori i mogunosti. Prototipski-modifikovani vodopadni model Prototipski razvoj softvera se bazira na prototipu koji je razraen na specifikaciji zahteva korisnika. To je rana verzija sistema koja pokazuje sve bitne karakteristike kasnijeg radnog sistema. Neki prototipovi mogu kasnije evoluirati u radni sistem (nadgradivi prototipovi), dok e drugi posluiti samo za preciznu specifikaciju zahteva a zatim biti odbaeni (odbaeni prototipovi, brzi prototipovi). Na bazi rezultata eksperimentisanja sa ovim prototipovima, novi radni sistem e biti projektovan i implementiran. Prednosti i nedostaci: -Ostvaruje se efikasna povratna veza sa korisnicima preko ulaza i izlaza budueg sistema i bre dovodi do rezultata. -Prouzrokuje nerealistina oekivanja korisnika, oekuje se da e i radni sistem biti isto tako brzo razvijen kao i prototip. -Zahtevaju se specifina sredstva za razvoj prototipa, trokovi razvoja ne smeju da preu 10-15% ukupnih trokova projekta

Spiralni model Ovaj model je baziran na najboljim osobinama vodopadnog modela i modela prototipskog razvoja uz dodavanje elementa - analize rizika. Model definie etiri aktivnosti, prisutne u svakom ciklusu a predstavljene kvadrantima. 1. Planiranje - odreivanje ciljeva, alternativa i ogranienja. 2. Analiza rizika - procena alternativa i identifikacija i razreenje moguih rizika. 3. Inenjering - razvoj proizvoda. 4. Ocenjivanje od strane naruioca - vrednovanje rezultata inenjeringa i donoenje odluke o nastavku razvoja.

Ako analiza rizika pokae da u specifikaciji zahteva postoje nepreciznosti, u fazi inenjeringa se mora ii na razvoj prototipa, kako bi se ostvarila to bolja komunikacija razvojnog tima i naruioca, u suprotnom sledi konvencionalni model vodopada. U koliko, posle ove aktivnosti, analiza rezultata inenjeringa pokae da je rizik preveliki projekat se moe i obustaviti.

Nedostaci spiralnog modela lee u prevelikom oslanjanju na ekspertsku ocenu rizika koja dosta zavisi od samih ljudi koju tu ocenu vre i od njihovog znanja i iskustva. Spiralni model je efikasan kada se koristi za brzi razvoj aplikacija vrlo malih projekata. Pored toga model je dao dobre rezultate u internim uslovima, dok realizacija delova sistema preko spoljneg podugovaraa stvara tekoe, jer ugovori moraju precizno da specificiraju ta treba isporuiti pa nema velike fleksibilnosti i usklaivanja meu uesnicima. MSF (Microsoft Solutions Framework) MSF procesni model opisuje opte delove aktivnosti za izgradnju i razvoj reenja za preduzea. Ovaj proces je fleksibilan i moe se prilagoditi razvoju preduzea u razliitim projektima. On je iterativan, fazno bazirani model, sa kontrolnim takama i primenjuje se za razvoj tradicionalnih aplikacija, aplikacija za elektronsko poslovanjem i za razvoj Web aplikacija.

MSF model je kombinacija vodopadnog i spiralnog modela. Faze MSF modela

1. Predvianje 2. Planiranje 3. Razvoj 4. Stabilizacija 5. Distribucija

Svaka od ovih faza zavrava se sa kontrolnim takama. Organizacija projektnih timova Microsoft Solutions Framework procesni model u sebi sadri i MSF tim model za organizaciju projektnog tima. MSF tim model istie vanost jasnih uloga, odgovornosti i postizanje ciljeva pojedinih lanova koji vodi ka uspenosti projekta. Ovaj model takoe poveava odgovornost svakog lana tima. Uloge u MSF tim modelu:

1. Menadment proizvodom 2. Menadment programom 3. Razvoj 4. Testiranje 5. Menadment realizacijom 6. Iskusni korisnik

Uloga menadmenta proizvodnje odgovorna je za upravljanje komunikacijom sa kupcem i da sagleda oekivanja kupca. Za vreme faze dizajniranja, menaderi proizvodnjom sakupljaju zahteve kupca i uveravaju se da li su te informacije neophodne za realizaciju. Menaderi proizvodnje takoe rade na planovima projektne komunikacije kao to su kratki izvetaji kupcima, marketiranju korisnika, demonstracijama proizvoda kao i korienje proizvoda. Uloga menadmenta programom odgovorna je za proces razvoja i za isporuku reenja kupcu sa projektnim ogranienjima. Uloga razvoja odgovorna je za razvijanje odgovarajueg tehnolokog reenja koje je dao menadment programom.

Uloga testiranja odgovorna je za identifikaciju svih kvaliteta proizvoda i dokazivanja da je ponueno reenje odgovarajue. Ova uloga ocenjuje i vrednuje funkcionalni dizajn i odrivost sa stanovita opsega i vizije projekta. Uloga menadmenta realizacijom odgovorna je za realizaciju svih neophodnih operacija za reenje zahteva kupca. Menadment realizacijom ocenjuje infrastrukturnu primenu reenja i sigurnost da moe biti reenje realizovano. Uloga iskusnog korisnika je da analizira neophodne performanse i podrava putanje u rad za korisnika kao i da vri razmatranje da li proizvod odgovara postavljenim zahtevima korisnika. U okviru malog projekta pojedinci u projektnom timu mogu uzeti jednu ili vie uloga. Kombinacija uloga na projektu mogu dovesti do rizika u okviru samog projekta. Mora se strogo voditi rauna o pridodavanju uloga lanovima tima. Na primer nije preporuljivo da pojedinac prisvoji i ulogu menadera programa i ulogu razvoja programa. Dodatni lanovi tima

1. Sponzor projekta 2. Kupac (ili poslovni sponzor) 3. Krajnji korisnik 4. Operativci

Sponzor projekta je jedan ili vie pojedinaca koji iniciraju i odobravaju projekat i rezultat projekta Kupac (ili poslovni sponzor) je jedan ili vie pojedinaca koji oekuju poslovne koristi od reenja Krajnji korisnik je jedan ili vie pojedinaca ili sistem koji su u vezi sa reenjem. Operativci organizacije odgovorne za rad reenja nakon isporuke. Upravljanje kompenzacijama esti razlozi za ne uspevanje projekata su prekoraenje datuma zavretka projekata ili prekoraenje predvienog budeta. Da bi se takve situacije prevazile, neophodno je da se vre pojedine kompenzacije u okviru same realizacije projekta. Projekat u okviru svoje oblasti definie ta treba da se dogodi a ta ne. Efikasno upravljanje opsegom projekta podrazumeva da se uzmu u obzir sledea razmatranja:

identifikacija projektnih ogranienja upravljanje kompenzacijama uspostavljanje kontrole izmena praenje napretka projekta

U procesu identifikacije i upravljanju kompenzacijama nije neophodno da se izvri smanjenje karakteristika reenja, ali sama kompenzacija moe dovesti do smanjenja karakteristika. Upravljanje kompenzacijama omoguava da na jedan strukturni nain izbalansirate sve delove projekta u okviru realizacije, tako da ne moete postii sve maksimalne vae ciljeve u isto vreme.

Kompenzacioni trougao i projektna matrica kompenzacije su alati koje MSF koristi za upravljanje kompenzacijama. Kompenzacioni trougao

Na slici je prikazano da promena bilo koje komponente vodi do odgovarajuih promena koje nisu neophodne da se menjaju. Reenje za dalji razvoj je da se zahtevi kupca korektno izbalansiraju izmeu resursa, datuma primene i karakteristika. Ovaj trougao pomae u objanjenju ogranienja i predstavlja jednu od opcija prilikom kompenzacije.

Projektna matrica kompenzacije Ova matrica je alat koji razvojni tim i kupac mogu koristiti kada donose odluke u vezi kompenzacija. Za razumevanje kako kompenzaciona matrica radi, promenljivi resursi, raspored i karakteristike mogu biti uoeni u sledeoj reenici: Za date fiksne resurse, izaberite raspored deavanja i podesite karakteristike ako je to neophodno.

Korienje iteracija u projektima Prilikom razvoja reenja, projekat prolazi kroz faze razvoja a svaka faza ini da je reenje blie krajnjoj realizaciji. Ovakav nain rada omoguava da se projekat razvija u manjim koracima i da se sledea iteracija bazira na uspehu ili greci prehodnog koraka. Opseg vizije dokumenta, kod, dizajn i planovi se razvijaju na iterativnoj osnovi. Koje dogaaje ukljuuje u iteracije svaki ivotni ciklus projekta?

Kreiranje realizovanih verzija

Kreiranje tekuih dokumenata Kreiranje periodine izrade (nedeljno ili dnevno)

su dogaaji koje ukljuuju iteracije u ivotnom ciklusu projekata. Realizacija verzija Kada korienjem MSF tima za razvoj reenja, izgrauje se, testira i primenjuje glavne funkcionalnosti reenja i onda se dodaje novi set osobina u svakoj novoj realizaciji, zove se strategija realizacija verzija. Plan kreiranja vie verzija Kreiranje planova vie verzija omoguuje timu da donese pravu odluku o tome ta kreirati a ta kasnije kreirati. Takoe na ovaj nain se najbolje iskoriavaju mogunosti rasporeda rada resursa.

Brzi prolaz kroz iteracije Znaajna prednost kreiranja verzija je da je isporuka primenljivih reenja kupcu brza i da raste sa vremenom. Prvo isporuivanje glavne funkcionalnosti Isporuivanje osnovnog reenja je korisnije i efektivnije od razvijanja reenja koje kupac ne moe koristiti nedeljama ili mesecima. Prvo kreiranje visoko rizinih osobina Za vreme detektovanja rizika, tim identifikuje najriskantnije karateristike reenja. Izrada ovih karakteristika se postavljaju tako da se prve odrade da bi se samim tim i izvrilo samo testiranje koncepta rada. Ako se tom prilikom uoi bilo koji problem koji zahteva vee promene u arhitekturi reenja, te izmene se mogu primeniti pre u projektu tako da se smanjuje uticaj promena na vreme izvrenja reenja i na budet. Tekue dokumentacije Izrada dokumentacije u svakoj fazi izrade reenja omoguuje timu da napravi modifikaciju bilo kog dela projekta u toku dizajniranja i razvoja, kada postoje zahtevi za takvom promenom. Odatle proistie da se MSF dokumentacija iterativno razvija. Svakodnevne dogradnje

MSF preporuuje este izrade komponenata reenja za testiranje i pregled. Ovaj pristup omoguava razvijanje koda u daljem razvoju hardverskih i softverskih komponenti. Pravljenjem svakodnevnih izmena, moete biti sigurni da e te postii stabilnost ukupnog reenja i akumulirati test podatke i pre krajnjeg reenja.

modul - Predvianje i analiza Faze u MSF proces modelu

Kao to je u prethodnom asu naglaeno MSF proces model sastoji se od pet faza i to:

Predvianje Planiranje Razvoj Stabilizacija Distribucija

ta predstavlja faza predvianja?

Predvianje moe biti definisano kao definisanje irokog opisa ciljeva i ogranienja projekta. U ovoj fazi indetifikuje se tim kao i zadaci tima. Osim toga vri se usaglaavanje ciljeva projekta izmeu svih kljunih zainteresovanih strana u projektu. Ova faza se zavrava na kontrolnoj taki dokaza opsega vizije projekta.

Proces predvianja

Tokom faze predvianja tim prolazi kroz nekoliko kljunih dogaaja: Sastavljanje tima Stariji menader sastavlja tim u koje ulaze osobe koje svojim znanjem i vetinama mogu da ispune odgovarajue zadatke Definisanje projektne strukture Ovde se definiu standardi za upravljanje projektom u koju spada administrativna struktura Definisanje ciljeva poslova Analizira se poslovni problem i mogunosti na koji se ovaj problem moe reiti. Procenjivanje tekue situacije Ispituje se tekua situacija i analiziraju se razlike izmeu tekue i oekivane situacije. Ova aktivnost je neophodna da bi se uoili problemi i odredili pravci daljeg kretanja projekta. Sagledavanje celokupnog problema i odreivanje opsega projekta Prilikom sagledavanja celokupnog problema neophodno je i odrediti i dugotrajni pravac u komunikaciji radi postizanja poslovnog cilja. Identifikacija opsega projekta definie ta e a ta ne da bude ukljueno u reenje. Definisanje zahteva i korisnikih profila U ovom delu je neophodno da se izvri identifikacija deoniara, identifikacija krajnjih korisnika i sponzora projekta i imati dokumentaciju njihove neophodnosti za reenjem. Ove informacije pomau u izradi vizije i opsega projekta i prilikom kreiranja koncepta reenja. Razvoj koncepta reenja - Formira se osnovni koncept reenja koji e tim uzeti u obzir prilikom rada na reenju. Ovaj koncept se formira na osnovu prihvaenih zahteva Ocena rizika Za vreme svih stanja ivotnog veka proizvoda, vri se procena rizika projekta i kreira se plan smanjenja rizika. Zatvaranje faze predvianja Kada je projekat formalno odobren od svih deoniara i projektnog tima, pristupa se zatvaranje faze predvianja. Svaka faza MSF procesnog modela ima svoje interne kontrolne take i glavne kontrolne take zavretka pojedinih faza.

Interne kontrolne take se pojavljuju sa razliitim aktivnostima u okviru faze. Kontrolne take u okviru predvianja su: Formiranje glavnog tima Podrazumeva biranje kljunih lanova tima kao i njihove uloge u timu. Kreiran opseg projekta Ova kontrolna taka nastaje posle prve verzije opsega projekta, kada je dokument kompletiran i podeljen lanovima tima, kupcima i deoniarima na pregled. Tokom ovog pregleda, dokument je podloan i modifikaciji.

Glavne kontrolne take - se postavljaju na kraju faza i koje pokazuju da se moe prei na sledeu fazu razvoja. Faza predvianja se zavrava sa kontrolnom takom odabranog opsega projekta, gde su se svi inioci sloili.

Rezultati faze predvianja

Posle svakog dogaaja tim daje rezultate. Zajedno sa tim rezultatima, daje se sadraj i pravac delovanja tima kao podsetnik za dalje napredovanje projekata. Koji rezultati se prave za vreme faze predvianja?

1.Opseg projekta Izjave o problemima i ciljevima poslova Pregled postojeih procesa iru definiciju korisnikih zahteva Identifikacija povlaenih korisnika reenja Definicija vizije i opsega projekta Skiciranje koncepta reenja Strategija dizajniranja reenja

2.Strukture projekta Opis svih MSF uloga u timu i lista odgovarajuih lanova Struktura projekta i standardni procesi za tim

3.Procena rizika Preliminarna procena rizika Lista preliminarnih rizika Planiranje za eliminaciju rizika

ta se radi u fazi planiranja?

Za vreme faze planiranja tim definie ta treba razviti i planira kako da doe do reenja. Tim takoe priprema specifikaciju funkcionalnosti, projektuje reenje, priprema radne planove, predvia trokove i vremenski raspored za razliite rezultate.

Faza planiranja obuhvata i analizu zahteva. Ovi zahtevi mogu biti podeljeni u poslovne zahteve, korisnike zahteve, operacione zahteve i sistemske zahteve. Koriste se prilikom projektovanja reenja i osobina i kao ocena valjanosti dizajna.

Posle sakupljanja i analiziranja zahteva, tim vri projektovanje reenja. Kreiraju se korisniki profili za razliite korisnike reenja i njihove uloge i odgovornosti. Zatim se prave serije korisnikih scenarija, tj. specifinih aktivnosti pojedinih tipova korisnika. Posle pravljenja korisnikih scenarija, tim kreira korisnike sluajeve za korisnike scenarije. Korisniki sluajevi specificiraju delove koraka, koje e korisnik uraditi u korisnikom scenariju.

Stanja projektovanja

1. Konceptualno projektovanje - u kojoj vidite problem iz perspektive korisnika i poslovnih zahteva i definie se problem i reenje u oblicima korisnikih scenarija.

2. Logino projektovanje u kome se sagledava reenje iz perspektive projektnog tima i definie reenje kao set usluga.

3. Fiziko projektovanje u kome se sagledava reenje iz perspektive razvoja i definie tehnologije, interfejsi komponenata i servisa reenja.

Funkcionalna specifikacija opisuje osobine i pojavu svake karakteristike reenja. Takoe opisuje arhitekturu i dizajn za sve karateristike. Ona odgovara na pitanje ta e se napraviti?. Tehnika specifikacija odgovara na pitanje Kako e se to napraviti? U sebi ona ukljuuje klase, metode i osobine koje su neophodne da budu kreirane.

Proces projektovanja

Za vreme faze planiranja, timu su dodeljeni kljuni dogaaji:

a) Razvoj i projektovanje reenja gde se vri identifikacija poslovnih zahteva, korisnikih zahteva i tehnologije i koriste ove informacije za projektovanje i predlog aplikacionog modela

b) Kreiranje funkcionalne specifikacije u kojoj se opisuju zahtevi koji moraju biti dati u reenju.

c) Razvijanje projektnih planova ovde se planiraju daogaaji koji e biti delovi glavnog projektnog plana

d) Kreiranje rasporeda projekta kreira se raspored rada na glavnom projektu. Ovaj raspored se takoe sastoji iz kontrolnih taaka za svaku timsku ulogu u projektnom timu.

e) Kreiranje okruenja za razvoj i testiranje formiraju se odvojena okruenja u kojima se vri razvoj i testiranje reenja. Ovo okruenje je nezavisno od okruenja u kojem reenje e biti primenjeno.

f) Zatvaranje faze planiranja kada se izkompletiraju kontrolne take dolazi se do zatvaranja ove faze. Za vreme faze planiranja radi se i odgovarajua dokumentacija.

Kontrolne take faze planiranja

Za vreme faze planiranja tim izvodi vei broj dogaaja. Unutranje kontrolne take su:

1. Kompletiranje tehnolokog vrednovanja - tim procenjuje proizvode i tehnologije koji e se iskoristiti za reenje. Takoe proverava kupevo tekue proizvodno okruenje. Ova provera ukljuuje konfigurisanje servera, mreu, desktop softver i sve relevantne hardvere.

2. Kompletiranje funkcionalne specifikacije na ovoj kontrolnoj taki, funkcionalna specifikacija je kompletirana i prihvaena za pregled kupca i deoniara.

3. Kompletiranje glavnog plana glavni plan je kombinacija planova razliitih uloga u timu. Duina i kompleksnost zavisi od veliine projekta.

4. Raspored kompletiranja glavnog projekta raspored glavnog projekta ukljuu je sve rasporede detaljnih projekata i datuma zavretka projekta.

5. Razvoj i testiranje podeenih okruenja radno okruenje omoguava odgovarajui razvoj i testiranje reenja i onemoguava negativan uticaj na sistem za koje reenje e biti primenjeno.

Rezultati faze planiranja

Rezultati faze planiranja daju osnova za budue kompenzacione odluke:

a) funkcionalna specifikacija b) plan upravljanja rizikom c) plan glavnog projekta i raspored glavnog projekta Faza razvoja

Za vreme faze razvoja, projektni tim formira reenje. U ovaj proces je ukljueno kreiranje koda kao i kreiranje dokumentacionog koda.

Procesi razvoja

1) Poetak razvojnog ciklusa potvrivanje svih dogaaja koji su u prethodnonim fazama ve uraeni.

2) Formiranje prototipa verifikacija koncepta reenja projektovanja u datom okruenju.

3) Razvoj komponenata reenja razvijanje komponenata sutine reenja. 4) Izgraivanje reenja radi se na reenju sve dok tim ne dovede do

reenja u fazi da moe da ga isporui. 5) Zatvaranje razvojne faze kompletiranje svih osobina i isporuka koda i

dokumentacije. Reenje se smatra da je kompletirano i tim je uao u stanje ekanja verifikacije reenja.

Kontrolne take razvojne faze

Tim formira potvrdu koncepta aplikacije i tek onda radi na realizaciji reenja. Unutranje kontrolne take razvojne faze su:

a) Potvrda koncepta aplikacije ovaj test je kljuni element reenja u test okruenju. Tim vodi operacije i korisnike kroz reenje da bi se izvrila validacija njihovih rezultata.

b) Zavretak unutranje izgradnje zato to reenje je razvijeno u delovima, dobra praksa je da delovi reenja se sinhronizuju u toku izrade. Broj i uestalost unutranjih izgradnji zavisi od veliine i kompleksnosti projekta.

Razvojna faza se zavrava sa kontrolnim takama kompletiranja opsega projekta. Od ove kontrolne take, sve karakteristike su kompletirane i proi e kroz jedinicu testiranja. Proizvod je sada spreman za spoljno testiranje i stabilizaciju. Rezultati faze razvoja su:

1) Sors kod i izvrni fajlovi 2) Poetni tekst i podeavanje konfiguracije za razvoj 3) Zavravanje funkcionalne specifikacije 4) Predstavljanje elemenata podrke 5) Specifikacija testa i test sluajevi

Faza stabilizacije

Tokom ove faze tim vri beta testiranje reenja. Koncentrie se na identifikaciju i reavanje problema tako da reenje moe da bude pripremljeno za realizaciju. Stabilizacioni procesi

1) Testiranje reenja Primenjuje se test plan za validaciju reenja. Pilot test je oslonjen na test okruenja. Ukljueni testovi su:

a) Testiranje komponenti b) Testiranje baze podataka c) Testiranje infrastrukture d) Testiranje bezbednosti e) Testiranje integracije f) Korisniko testiranje g) Testiranje performansi, kapaciteta i optereenja h) Testiranje regresije i) Zapisivanje broja greaka

2) Ponaanje pilot reenja Primena reenja i testiranje se vri sa aktuelnim korisnikom i sa realnim korisnikim scenariom.

Praenje testiranja i izvetaji Tokom razvoja, testiranja i stabilizacione faze, stalno se vodi praenje i izvetavanje. Za vreme stabilizacione faze, daje se izvetaj o broju greaka. Jako je bitna dobra komunikacija tokom testiranja meu kljunim lanovima tima i deoniarima. Kontrolne take stabilizacione faze Interne kontrolne take: Konvergencija greaka merenjem broja greaka moe se ustanoviti da li pojava greaka se smanjuje ili ne. U sluaju da dolazi do smanjenja greaka (konvergencije), govori timu da je projekat blizu zavretka. Nula greka Oznaava da u toku stabilizacione faze se dolo do nula greake. Otputanje kandidata Ako u toku stabilizacione faze je bilo poveanja provere reenja, broj greaka u poreenju sa nula grekama identian. Zlatna realizacija U toku stabilizacione faze, vri se kombinacija nula greaka i uspeha kao kriterijum mere. Stabilizaciona faza se zavrava sa kontrolnom takom realizacije spremnosti. Rezultati stabilizacione faze:

Konana realizacija Beleke realizacije Performanse elemenata za podrku Rezultati ,testova i alati za testiranje Sors kod i izvrni fajlovi Projektna dokumentacija Pregled kontrolnih taaka

Faza distribucije

Tokom ove faze vri se transfer projekta za rad i odravanje kao i dobijanje kupeve potvrde o projektu. Tim je u kontaktu sa kupcem i vodi rauna o projektu kao i o svim zahtevima kupca. Faza primene se zavrava sa kontrolnom takom kompletiranje faze distribucije. Procesi distribucije 1. Kompletiranje distribucije i radne procedure Dokumentacija distribucije i

radne procedure prikazuju kako projektni tim namerava da predstavi distribuciju i prelazne dogaaje.

2. Distribucija i stabilizacija Kompletiranje tekue komponente i poloaj faze distribucije

3. Pregled projekta Kompletiranje post projektne poglede sa kupcem i projektnim timom.

Kontrolne take faze distribucije

a) Razvijanje glavnih komponenti U zavisnosti od reenja, glavna tehnologija, moda je neophodna da bude razvijena pre ili istovremeno sa poloajem distribucije. Ako doe do kanjenja, glavne komponente moraju biti pregledane i odobrene za distribuciju sa ostalim delovima reenja koja su bila stabilizirana.

b) Poloaj distribuiranih komponenti Voenje razvoja za svaki poloaj mora potvrditi njihove poloaje koje rade. Ova kontrolna taka moda ne bi bila primenljiva za projekte da ne ukljuuje distribuciju od strane klijenta.

c) Stabilna distribucija Kod ove kontrolne take kupac i tim se slau da je reenje radno zadovoljavajue. Neke osobine mogu se poboljati sa razliitim distribucijama.

d) Kompletirana distribucija Ova kontrolna taka je zavretak faze distribucije. Od ovog vremena razvijeno reenje trebalo bi da omogui oekivane poslovne vrednosti kupca.

Rezultati faze distribucije

1. Rad i podrka informativnom sistemu 1.1. Procedure i procesi 1.2. Osnovno znanje, izvetaji i knjiga logovanja

2. Dokumentacija za sve verzije 3. Plan obuke 4. Projektni zavrni izvetaj

4.1. Krajnje verzije svih projektnih dokumenata 4.2. Kupevi zadovoljavajui podaci 4.3. Definisanje sledeih koraka

modul - Predvianje i analiza

Korienje notifikacije modeliranja

Razlog korienja modela je to to problemi i reenja u toku razvoja softvera su vrlo kompleksni. Ta kompleksnost moe da zavisi i od komunikacije razvojnog tima i tima projektnih deoniara. Modeliranje moe jasno predstaviti sloenost problema i reenja i njihovo razumevanje. Model tekueg stanja i budueg stanja

Zahtevi Sistem koji je bio izmodeliran, diskutovan i analiziran, fokusira se na detalje modela i kroz saglasnost mogu se dostii odgovarajui zahtevi. Problemi i rizici Ponekad postoji neslaganje oko toga ta je stvarni problem ili rizik sistema. Model moe dovesti do toga da strunjak objasni problem ili rizik a da ne mora biti upoznat sa svim detaljima. Nedostatak informacija Kreiranje modela sistema, pomae razvojnom timu laku identifikaciju, koje informacije su nam nepoznate i da se onda usmeravaju aktivnosti na njihovom sakupljanju. Koriste se dve vrste notacije: - UML (jednoobrazni modelski jezik) - ORM (objektna uloga modeliranja) UML

UML je standardni jezik modeliranja, pomou kojeg moete modelirati softver razliite sloenosti. Moe biti korien za:

a) Vizuelizaciju softverskog sistema sa dobro definisanim simbolima. b) Specifikaciju softvera i pomo pri preciznoj izgradnji, ambicioznosti i

kompletnih modela. c) Konstrukciju modela softvera i da direktno komunicira sa razliitim

programskim jezicima. d) Dokumentaciju modela softvera preko izraavanja zahteva sistema za

vreme stanja razvoja i isporuke. Osobine UML-a

Osnovne osobine UML-a su:

a) Jednostavan, proiriv i brzo razvojni jezik

b) Sastoji se od kompleta simbola i pravila za modeliranje sistema. c) Omoguava brzo, jednostavno i dobro dokumentovanje i lako razumevanje

softverskog modela. d) UML je nezavisan od primene jezika i od primene platforme.

UML pogledi Sadre veliki broj grafikih alata koji omoguavaju razumevanje sistema iz razliitih pogleda Tipovi UML pogleda:

a) Korisniki pogled To je pogled koji predstavlja deo sistema sa kojem korisnik je u interakciji. Korisniki pogled je takoe predstavljen i kao pogled korisnikog sluaja.

b) Strukturni pogled Predstavlja statino ili prazno stanje sistema. Inae njegova oznaka je Design View

c) Pogled ponaanja Prikazuje dinamiko ili izmenljivo stanje. d) Pogled primene Daje strukturu logikih elemenata sistema e) Pogled okoline Predstavlja raspodelu fizikih elemenata sistema. Ovaj

pogled specificira funkcionalnost sistema iz perspektive korisnika. On je takoe nazvan i Deployment View

UML dijagrami

Razliiti UML pogledi ukljuuju dijagrame koji omoguavaju vei broj perspektiva reenja koji e biti razvijeni. Bira se koji model e biti najbolje primenjen za uspeno modeliranje sistema. Tipovi UML dijagrama

a) Dijagram klasa opisuje razliite klase i njihove osobine. b) Objektni dijagram opisuje razliite objekte u sistemu i njihove relacije sa

svakom od njih c) Dijagram sluajeva predstavljaja funkcionalnost spoljnih entiteta preko

sistema. d) Dijagram komponenata predstavlja primenjeni pogled sistema e) Dijagram razvoja predstavlja odgovore softverskih komponenti u

takama fizike implementacije sistema. f) Dijagram saradnje je set klasa i poruka poslatih i primenjenih od istih. g) Dijagram sekvenci sekvencioni dijagram opisuje interakciju izmeu

klasa, tj poruke koje se razmenjuju izmeu pojedinih klasa. h) Dijagram stanja dijagram stanja opisuje algoritam razliitih stanja

objekta konstruisan za prihvatanje i reagovanje na razliite spoljne dogaaje.

i) Dijagram aktivnosti je drugi nain za pogled na stanje ali dijagram aktivnosti ukljuuje i sekvencijalne aktivnosti.

ORM (objekta uloga modeliranja) To je metod koji moe biti iskorien za predstavljanje poslovnih pravila i dizajn baze podataka. Ovaj pristup je semantiki pristup modeliranja koji opisuje rei u oblicima objekta i uloge koje e igrati.

Procedura dizajna konceptualne eme ORM-a

ORM procedure dizajna konceptualne eme (CSDP) fokusira se na analizu i dizajn podataka. Ona specificira informacionu strukturu aplikacije, tipove podataka, ogranienja injenica i pravila koja su izvedena iz nekih drugih pravila. CSDP se sastoji iz sledeih dogaaja:

a) Analize spoljnih informacija i transformisanje u elementarne injenice.

b) Primenjivanje osnovnih tipova entiteta u konceptualnom modelu. c) Primenjivanje jedinstvenih ogranienja konceptualnog modela. d) Primenjivanje vremenskih ogranienja konceptualnog modela. e) Dodavanje vrednosti ogranienja, ogranienja poreenja i podtipova

ogranienja konceptualnog modela. f) Dodavanje prstenastog ogranienja konceptualnog modela.

ORM terminologija

1. Instanca dogaaj od interesa u reenju. 2. Populacija je grupa svih kombinovanih instanci datog tipa dogaaja

interesantnih u reenju. U obliku baze podataka, sve vrste u tabeli ine tabelarnu populaciju.

3. Set je bilo koja grupa instanci, ali set nije neophodno da je isto kao i populacija. Set bi mogao da bude populacija ili kombinacija instanci vie od jedne populacije. Sve populacije su set, ali nisu svi set-ovi populacije.

4. injenina instanca je pojedinana zapaanje odnosa izmeu dve ili vie vrednosti podataka.

5. Tip injenice je set injeninih instanci koje dele iste tipove objekata i predikat relacije.

6. Tip objekta je komplet svih instanci datog objekta 7. Predikat je glagolska fraza koju ekspertski korisnici koriste za relaciju

tipova objekta. ORM objekte i uloge

Naziv objektna uloga modeliranja odnosi se na nain korienja objekata i njihova uloga. Objekti su druge vrednosti ili entiteti. Vrednosti su string karakteri ili brojevi. Entiteti su realni objekti i imaju svoje opise. Kreiranje korisnikih scenarija i korienje sluajeva Korienje korisnikog scenarija i sluajeva omoguava da na jednostavan nain se zabelei funkcionalni zahtevi sistema. On opisuje serije dogaaja kada uesnici koriste sistem za kompletiranje procesa. Prilikom razvijanja sistema pomou ovog scenarija bi trebalo predstaviti neophodan set aktivnosti i rezultata sistemskih procesa. Sledei dijagram prikazuje UML dijagram koji predstavlja prethodne izjave o korienju use case-a. U okviru UML dijagrama korisnik je prikazan figurom oveka. Jedan use case je prikazan u obliku elipse i set cases-a je u obliku kutije. Izvoenje use case-a korisnikih sluajeva Da bi se izveli korisniki dijagrami morate biti u mogunosti da identifikujete sledee stvari:

a) Sistem b) Uesnike c) Interakciju izmeu uesnika i sistema d) Granice sistema

a) Identifikacija sistema - Sistem je kolekcija podsistema koji imaju realnu svrhu postojanja. Kada se razvije korisniki sluaj (use case) vi u stvari indetifikujete jedan sistem ili podsistem. Kolekcija (use case) pokazuje relacije meu podsistemima koji ine sistem.

b) Identifikacija uesnika - Uesnik je integralni deo korisnikog sluaja (use case). On je entitet koji je u interakciji sa sistemom koji bi trebalo da bude razvijen za svrhu kompletiranja dogaaja. Uesnik moe biti: 1. Korisnik sistema 2. Entitet kao to je drugi sistem ili baza podataka, koji je izvan sistema

Prilikom definisanja uesnika, mora se odgovoriti na sledea pitanja: Ko koristi sistem? Ko startuje sistem? Ko odrava sistem? Koji drugi sistemi koriste sistem? Ko dobija informacije od sistema? Ko prosleuje informacije sistemu? Deava li se neto automatski u tom trenutku? Ko ili ta inicira dogaaj sa sistemom? Ko ili ta je u interakciji sa sistemom da bi mu pomoglo u odgovoru na

dogaaj? Postoji li bilo koji interfejs izvetaja? Postoji li bilo koji administrativni interfejs? Da li je sistemu neophodno da ima interakciju sa bilo kojim postojeim

sistemima? Da li su bilo koji uesnici definisani u sistemu? Postoji li bilo koji drugi hardver i softverski ureaji koji su u interakciji sa

sistemom i da li bi trebalo da se izmodeliraju za vreme analize? Ako se dogaaj desi u sistemu, da li spoljni entitet je neophodan da bude

informisan o ovom dogaaju?

c) Interakcija izmeu uesnika u sistemu - Posle identifikacije sistema i uesnika, neophodno je opisati interakciju izmeu njih. Za svaku interakciju neophodno je kreirati po jedan use case.

d) Granice sistema - Jedna od najteih stvari u radu je definisanje pravih granica sistema koji bi trebalo razviti. Zato, da bi se ova aktivnost ispravno reila, potrebno je odgovoriti na sledea pitanja:

ta se deava kad use case pridodate svakom uesniku? Ko ili ta je u interakciji sa use case-om sada? ta ako pronaete nove zadatke? Da li e ti zahtevi biti deo sistema? Da li ti zahtevi su neophodni za ovaj sistem? Da li ti zahtevi neto logiki rade u sistemu? Mogu li ovi zahtevi da budu prihvaeni od jednog tekueg uesnika? Da li te zahteve kupac ili korisnik bi oekivali da neto rade u sistemu?

Korisniki scenario

Use case opisuje interakcije visokog nivoa, izmeu uesnika i sistema. Grupisani use case-ovi detaljno opisuje algoritam procesa. Korisniki scenario omoguava dodatne informacije o aktivnostima i fazama dogaaja koji su sadrane u procesu.

Izuzeci su atipini dogaaji ili alternativne fazne aktivnosti koje omoguavaju kompletan opis use case-a.

Pravljenje korisnikih scenarija

Pri pravljenju korisnikih scenarija, neophodno je da odredite sledee aktivnosti:

1) Definisati preduslove za korisniki scenario, specificirati informacije ili uslove koji moraju postojati pre donoenja scenarija koji bi trebalo da bude izvren.

2) Odrediti postuslove, korisniki scenario, koji odreuju rad ili krajnji cilj za vreme aktivnosti.

3) Podeliti aktivnost u pojedine korake. 4) Odrediti izuzetke koji mogu se primeniti za bilo koji korak. Moda bi

trebalo razviti korisniki scenario za ove izuzetke. 5) Odrediti zahtev za ovu pojedinanu korisniku adresu, za praenje i

mogunost praenja. 6) Odrediti izvor za ovaj korisniki scenario za drugu diskusiju i klasifikaciju.

Korisniki scenario tekueg stanja

Korisniki scenario tekueg stanja opisuje kako poslovne aktivnosti se sprovode; dok scenario budueg stanja predstavlja aktivnosti koje bi eleli da budu izvrene. Za oba stanja scenario istie poslovne procese, informacije, korisnika i aktivnosti.

modul Predvianje i analiza Sakupljanje informacija

Enterprajs arhitektura (arhitektura preduzea) je predstavljena preko poslovno dinamikog sistema jedne take u vremenu. Za poslove, grupne informacione tehnologije, koriste se sa ciljem zadovoljenje posla. Za sakupljanje informacija o enterprajz arhitekturi, koriste se etiri opisne kategorije koje slue kao vodilje i slue za klasifikaciju informacija koje se sakupe. Te kategorije su: poslovne, aplikativne, operativne i tehnoloke. Poslovne Poslovne kategorije opisuju kako posao radi, opisuju funkcije i aktivnosti funkcija koje su aktivne u toku poslova. Informacije iz ove kategorije takoe opisuju primarni poslovni cilj. Aplikativne Kategorija aplikacije ukljuuje servise, funkcionalnost i povezuje korisnike razliitih vetina primenom zajednike poslovne objektivnosti. Automatizovani poslovni servisi mogu ukljuiti, kompletne aplikacije, korisnike alate, produktivne alate, komponenata i modula koda koji omoguavaju analizu informacija ili funkcionalne aktivnosti. Operativne Operativne kategorije opisuju ta je organizaciji neophodno da zna da bi poela poslovni proces i operacije. Ova kategorija ukljuuje standardne modele podataka, polise upravljanja podacima i opis informacione eme poslovanja. Tehnoloke Tehnoloka kategorija definie: tehnike servise neophodne za predstavljanje i podrku poslovne misije, ukljuivanjem topologije, razvoj okruenja, aplikacioni programabilni interfejsi (APIs), bezbednost, mrene servise, servis upravljanja bazom podataka (DBMS), tehnike specifikacije, hardver i operativne sisteme. Tehnologija omoguava vezu izmeu aplikacije i informacije Tehnike sakupljanja informacija Postoje sledee tehnike koje se mogu koristiti za sakupljanje informacija:

1. Senenje 2. Intervjuisanje 3. Grupno fokusiranje 4. Pregledi 5. Korisnike instrukcije 6. Simulacija 7. Verzije prilaza

Senenje je tehnika u kojoj se zapaa korisnikovo predstavljanje aktivnosti, u aktuelnom radnom okruenju, i postavljaju se pitanja korisniku koja su vana za aktivnosti. Informacije koje se ovim putem dobijaju su informacije iz prve ruke i u kontekstu problema. Potrebno je sakupiti to vei broj informacija i posticati korisnike za to detaljnijim objanjenjima u vezi aktivnosti. Senenje moe biti aktivno i pasivno. Pasivno senenje je kada posmatrate korisnika i sluate bilo koje objanjenje koje korisnik daje. Aktivno senenje je kada vi postavljate pitanja i korisnik objanjava dogaaje i aktivnosti. Ogranienja sistema senenja se svode na:

1. Nemogunost postavljanje svih neophodnih pitanja za jasno definisanje svake take.

2. Nemogunost da zabeleite sve odgovore ali da bi se to prevazilo moete koristiti i video zapis.

3. Usko fokusiranje na pojedine dogaaje, a samim tim nemoguost dobijanja dobrih rezultata za aktivnosti koje traju, nedeljama, mesecima, godinama.

Intervju je sueljavanje jedan na jedan izmeu lana projektnog tima i korisnika. Kvalitet intervjua naravno da zavisi od vetine osobe koja intervjuie i od one koja se intervjuie. Intervju daje mogunost za postavljanje irokog opsega pitanja o dogaajima koje ne mogu se zapaze putem senenja. Intervju se koristi za sakupljanje informacija o:

1. Procesima aktivnostima koje kratko traju 2. Poslovnim prednostima iz perspektive upravljanja 3. Poslovima ili aktivnostima koje se direktno ne posmatraju, bilo zato to su

automatizovane ili zato to se deavaju u drugom vremenskom intervalu. Grupno fokusiranje je sesija u kojoj je omogueno pojedinano razmatranje dogaaja i povratna sprega. Grupno fokusiranje koristi tehnike grupnog intervjuisanja, kada su vie korisnika direktno ukljueni u proces sakupljanja informacija. Ovaj nain omoguava sakuplanje detaljnih informacija o tome kako se aktivnosti uklapaju u celokupan posao. Pregledi su set pitanja koji su kreirani za sakupljanje informacija. Jedan takav primer je ukljuivanje registracionog formulara u kupevu povratnu spregu. Da bi ste dobili najkorisnije rezultate morate imati izuzetno kompetentne osobe za koje ete kreirati takva pitanja i dati rezultate analiziranja. Informacije koje mogu biti sakupljene koristei ovu metodu su:

Organizaciona struktura, dozvole korienja Optereenje tehnike podrke strukturama i dozvolama Specijalne neophodnosti za relacijom u hardveru i softveru Trening

Korisnike instrukcije korisnik vas vodi po aktivnostima koje treba da se dese. Ovo omoguava da aktivno uestvujete u svakom koraku i procesu sa perspektive korisnika. Simulacija omoguava sakupljanje informacija kreiranjem simulacionog predloenog reenja. U ovom procesu moete sakupiti informacije o najee pritisnutim dirkama na tastaturi, kliktanje mia ili pauziranje koje moe dovesti do toga da korisnik ima potekoa sa aplikacijom. Simulacija moe pomoi u verifikaciji kao i dokument informacijom od korisnika ukljuujui:

Zahtev za kvalitetom Zahtev za vremenom odgovora i ciljevima Integracijom tekue tehnologije i aplikacije

Korisniki interfejs kao to su osobine koje korisnik eli da doda aplikaciji Verifikacije procesa toka rada

Verzije prilaza - omoguava sakupljanje informacija ubacivanjem specijalnih funkcija praenja u aplikaciju. Ovaj nain moe biti izveden u okviru posla ili u laboratorijskim podeavanjima. Verzije prilaza mogu odgovoriti na sledea pitanja:

1. Koliko esto je osobina bila iskoriena 2. Koliko vremena je potrebno da se kompletira aktivnost 3. Koje osobine se najee koriste za izvoenje aktivnosti Strategija sakupljanja informacija Pre sakupljanja informacije neophodno je definisati strategiju na koji nain da se to vri. Ta strategija u sebi podrazumeva identifikaciju korisnika, definisanje pitanja i izbor odgovarajuih tehnika za sakupljanje informacija. Posle definisanja strategije, potrebno je da odgovorite na sledea pitanja:

a) Koje izvore elite da iskoristite za informacije? b) Koje informacije su neophodne da se sakupe? c) Koje tehnike ete koristiti za sakupljanje informacija i koje izvore ete

koristiti za svaku tehniku? d) Kako ete zabeleiti informacije koje sakupite? e) U kom vremenskom okviru ete sakupiti informacije?

Definisanje informacione strategije Postoji vodi kako da definiete informacione strategije:

a) Koristiti mnogostruke tehnike za sakupljanje informacija U sluaju da se koristi samo jedna tehnika sakupljanja informacija, moe se dogoditi da nae informacije budu nekompletne. Kombinacijom razliitih tehnika ovaj nedostatak se moe ukloniti.

b) Indentifikacija najefektnijih tehnika Potrebno je meriti prednosti i mane svake tehnike kada razvijate strategiju sakupljanja informacija.

c) Zapamtiti sve perspektive tipova informacija i izvora informacija Mora se voditi rauna da tehnika sakupljanja informacija mora uzeti u obzir i korisnika kao i perspektivu samog posla. Istraivanje svih moguih izvora informacija u toku sakupljanja.

d) Sakupljanje informacija od grupe korisnika na istim poslovnim procesima Razliite grupe u poslu mogu biti prosleeni na iste procese i da odgovaraju na iste poslovne izazove. Informacije sakupljene od ove grupe mogu pomoi projektnom timu da sagleda poslovni proces sa razne take gledita.

Analiziranje informacija

Proces sakupljanja i analiziranja informacija je iterativan proces. Kada sakupite odreene informacije i izanalizirate, moete shvatiti da su vam potrebne jo neke informacije. Onda pravite nova pitanja koja e vam pomoi za nastavljanje analize poslovanja. Prilikom svake analize neophodno je da izvrite filtraciju najrelevantnijih za va rad. Slee informacije su znaajne za va rad:

Neophodnost bezbednosti Strukturne podrke reenja i njihove karakteristike Planiranje izmena u poslovanju i pogodnost projektnog reenja Predstavljanje korisnikovih oekivanja ili poslovnih potreba Da li postoje aplikacije koje e biti u interakciji sa novim reenjem Kako postojei poslovni procesi utiu na reenje

Kada izvrite sistematizaciju i analizu informacija, moete uoiti koje neophodne informacije vam nedostaju.

modul Predvianje i analiza Faza predvianja

Faza predvianja je prva faza MSF procesnog modela. Za vreme ove faze tim kreira pogled na poslovni problem koji bi trebalo reiti i prikazuje u kojoj su vezi problemi sa poslovima, kupcima i okolinom. Ovo pomae timu da dobije jasnu viziju ta tim mora da ispuni da bi kupci bili zadovoljni.

Svrha faze predvianja

Ova faza ima sledee svrhe: a) Identifikacija cilja i ogranienja projekta b) Odgovor na pitanje izvodljivosti c) Osnovno reenje koje lanovi tima kreiraju kao mogue reenje projekta d) Definisanje opsega projekta, koji pomae pri analizi greaka pri planiranju

sledee faze e) Procenjuje resurse koji su neophodni za razvoj reenja f) Identifikacija i raspored glavnih kontrolnih taaka za projekat

Uloge i odgovornosti lanova tima

Iako projektni tim radi kao jedna jedinica, postie svoj zamiljeni cilj preko radnih grupa. Svaka uloga, pojedine grupe, ima svoje zadatke za sve vreme izvoenja projekta. Uloge tima i odgovornosti:

a) Menadment proizvoda Uloga menadera je da sarauje sa menaderom programa i osigura da se ostvari vizija projekta. Za ostvarivanje ovog cilja menader proizvoda studira i analizira poslovni problem, poslovne zahteve, viziju projekta, poslovne ciljeve i korisnike profite.

b) Menadment programa Uspostavlja ciljeve projektovanja, definie faktore uspeha i mere odreuje koncept reenja i vri podeavanje projektne infrastrukture.

c) Razvoj Razvojni tim omoguuje povratnu spregu tima sa tehnikom primenom razvoja proizvoda i radi na izvodljivosti konceptualnog reenja.

d) Testiranje Tim za testiranje omoguuje povratnu spregu cilja kvaliteta i specifine aktivnosti koji e biti neophodni za postizanje odreenog nivoa kvaliteta. Ovaj tim primenjuje odluke za ciljeve kvaliteta, strategije testiranja i kriterijume prihvatanja, koji e se primeniti prilikom merenja kvaliteta.

e) Menadment realizacije Vri identifikaciju zahteva za razvoj proizvoda; kako e se proizvod razviti, kada e biti razvijen.

f) Iskusni korisnici Tim iskusnih korisnika analizira neophodne performanse i analizira podrku reenja.

Sastavljanje projektnog tima

Jedna od aktivnosti za vreme faze predvianja je i formiranje tima za realizaciju projekta. Prilikom sastavljanja lanova, tima mogu se uzeti u obzir sledee karakteristike koje lanovi tima moraju da ispunjavaju:

1) Znanje Predstavlja informacije pojedinaca koje moraju da poseduju da bi se posao mogao izkompletirati.

2) Vetine Su osobine ili mogunosti koje lanove ini strunim kao to su npr. matematika logika ili sposobnosti animacije.

3) Nivo izvoenja je mogunost izvrenja planiranih rezultata.

U okviru dodatnih razmatranja za svakog pojedinog lana tima mora se uzeti u obzir i sledee:

a) Mogunosti lanova tima b) Cene ili budet projekta c) Bezbednosna dozvola za rad lanova tima

Priprema isporuivosti faze predvianja

Mada postoje interne kontrolne take za vreme faze predvianja, postoje i tri glavne take isporuke. One su:

Dokument vizije/opsega u kojoj su opisani projektni ciljevi i ogranienja. Dokument projektne strukture opisuje procese upravljanja projektom.

Vri se identifikacija voe tima za svaku ulogu u okviru MSF tim modela. Dokument rizika u kome je data kao poetna identifikacija analiza rizika

projekta.

Dodatne isporuke za fazu predvianja

Dodatne isporuke za fazu predvianja moe ukljuiti:

a) Inicijalna lista osobina testiranja

b) Preliminarni zahtevi i korienje case alata

c) Preliminarna arhitektura

d) Grafiki korisniki interfejs (GUI)

Kreiranje vizije dokumenta

Vizija dokumenta je jedno od ciljeva faze predvianja. Ovaj dokument sadri ciljeve i ogranienja poslovnog reenja i predstavlja prvi stepen slaganja izmeu uesnika u projektu. Da bi se formirala vizija projekta, tim vri vie intervjua sa kupcima i deoniarima, analizira na viem nivou sluajeve korienja poslovne aplikacije i indetifikuje ogranienja poslovanja.

Sadraj vizije dokumenta

Vizija dokumenata mora se fokusirati na razumevanju i definisanju problema i u sebi treba da sadri sledee:

1. Informacije o problemu 2. Informacije o viziji 3. Profile korisnika 4. Opseg projekta 5. Koncept reenja 6. Ciljeve projekta

6.1. Poslovne ciljeve 6.2. Ciljevi projektovanja

7. Faktore kritine za uspeh 8. Poetni raspored

Informacije o problemu

Ovo je obino kratko izlaganje u kome se opisuju poslovne nade projekta, i ono je u zavisnosti od tekuih poslovnih aktivnosti. Novi lan tima moe iskoristiti ove informacije da moe lako da se uklopi u postojei projekat.

Informacija vizije projekta

Svrha informacije o viziji projekta je uspostavljanje zajednike vizije i konsenzusa izmeu lanova tima projekta da bi projekat mogao da uspe. Ovaj deo

dokumenta takoe sadri i dogovor o budunosti samog projekta i tima ljudi koji ga radi. Informacija o viziji projekta treba da bude dovoljno kratka da moe da se zapamti, jasna da bi bila razumljiva i dovoljno jaka da bi delovala motiviue. Dobra informacija o viziji ima sledee karakteristike:

1. Specifinost Vizija treba biti specifina i da ukljuuje idealna stanja poslovnog problema tako da je krajnji rezultat uspeh.

2. Merljivost Pod merljivosti se podrazumeva da tim moe definisati uspeh projekta u poreenju sa posebnim ciljevima

3. Izvodljivost Dati potrebne resurse, vremenski okvir i vetine koje lanovi tima treba da poseduju.

4. Relevantnost Vizija projekta treba da je relevantna sa poslovnim problemom. Ako nije relevantna projektni tim bi mogao da otkrije da pokuavaju da ree problem koji ne postoji.

5. Vremenska baziranost Mora biti jasno procenjeno okvirno vreme za zavretak reenja

Korisniki profili

Svako reenje se radi za odreeni broj kupaca. Pre nego to krenete u sakupljanje drugih informacija, vrlo je znaajno da razumete korisnika za koga se razvija reenje. Uzima se jasni opis svakog korisnika, da bi tim mogao da napravi korisnike profile. Korisniki profili identifikuju korisnike tako da tim moe pristupiti oekivanjima, rizicima, ciljevima i ogranienjima projekta.

Informacije koje su neophodne za kreiranje korisnikih profila

1. Ciljevi Krajnji cilj korisnika ukljuuje listu stvari koje korisnik oekuje da moe da radi u interakciji sa proizvodom.

2. Ogranienja Vrlo su vana ogranienja za razumevanje faktora koji mogu da utiu na korisnikovu mogunost korienja reenja, kao to su softver i hardver.

3. Podrka dodeljivanju Korisniki profili takoe sadre informacije o problemima koje korisnici mogu imati sa istim proizvodima. Ove informacije e vam pomoi prilikom planiranja osobina podrke, kada korisnici mogu zahtevati korienje novog proizvoda.

4. Opti korisnici Definie se gde reenje podrava razliite kulturne i lokalne potrebe.

5. Geografske granice Opisuju se korisnike lokacije, ukljuujui geografsku i fiziku lokaciju, broj korisnika na svakom sajtu i irinu opsega i korienje mrenih linkova izmeu sajtova.

6. Protok informacija izmeu korisnika Daje se opis komunikacije koji se deava izmeu korisnika, ukljuujui tipove komunikacije, njihovu vanost i veliinu podataka koja se razmenjuje izmeu razliitih korisnika u zajednicama.

7. Korisnike funkcije Opisuju aktivnosti koje korisnik izvrava kao to je kompletiranje profila kupca i korekcije kupeve narudbe i detalja.

8. Organizacija komunikacije Neke organizacije imaju krutu hijerarhisku strukturu koje su ograniene sa kako, zato i kada pojedinci mogu komunicirati kroz linije hijerarhije. Dokument formira granice hijerahijske organizacije.

9. Polise donoenja odluke Opisuju direktni uticaj efektivne primene predloenog reenja.

10. Dodatni faktori Neophodno je i za svakog korisnika i za svaku lokaciju utvrditi i neke dodatne faktore kao to su: nekompatibilni protokoli, mreni operativni sistemi i mogu uticati na uspeh aplikacije koje su bazirane na geografskom reenju.

Definisanje opsega Jedan od kritinih faktora uspeha projekta je jasno definisan opseg projekta. Opseg projekta definie ta e a ta nee biti ukljueno u projekat i baziran je na projektnoj viziji; a u sebi jo sadri i ogranienja preko resursa, vremena, i drugih limitirajuih faktora. Dok se definie opseg projekta, tim odluuje o ne tako bitnim osobinama reenja, da li da se odmah realizuju ili da se ostave za neka druga reenja projekta. Osobine koje se razmatraju izvan opsega projekta trebalo bi da budu dokumentovane u sledeoj verziji ili u sledeoj projektnoj dokumentaciji. Prilikom definisanja opsega vi definiete oblast u use case-u direktno ubacivanjem poslovnog izazova i mesta poslovanja. Moete jednostavno nacrtati pravougaonik oko relevantnih delova u prethodnim use case crteima i izvesti nove use case dijagrame koji e zatim koristiti projekat.

Kreiranje koncepta reenja Posle identifikacije poslovnog problema i definisanje vizije i opsega, tim kreira koncept reenja koji u glavnom oslikava zahteve projekta. Sledea slika pokazuje jednostavno konceptualno reenje za identifikovani opseg projekta.

Kreiranje poslovne skice Skica po svom nazivu predstavlja samo pogled na koncept ne ulazei u detalje i po svom sadraju nije suvie tehniki orjentisana. Koncept reenja ukljuuje konceptualni model sistemskog softvera i arhitekture hardvera. On je predlog za identifikaciju reenja u okviru opsega. Tim mora razmatrati razliite opcije i da izabere jednu najbolju za jedno reenje. Takoe moe se dati i uzak opseg drugih opcija za nekoliko alternativa. Elementi koncepta reenja

Izabrano najbolje konceptualno reenje mora u sebi sadrati resurse i vremenski okvir primene. Koncept reenja ukljuuje sledee elemente:

a) Faktore uspeha projekta i kriterijum prihvatanja projekta - Ovi kriterijumi ukljuuju listu provere zahteva koja mora biti zadovoljena pre nego to reenje ode u realizaciju.

b) Poetne pristupe za razvoj i isporuku reenja - Ovi pristupi ukljuuju primere scenarija za sajtove i metode primene reenja, broj korisnika koji e koristiti novo reenje i kompletnu listu isporuka projekta tako da e novo reenje biti operativno.

c) Poetni opis funkcionalnosti reenja - Koje e imati poslovni problem. Projektni ciljevi Da bi se projekat uspeno realizovao vrlo je vano da se ispravno identifikuju ciljevi projekta. Ti ciljevi mogu biti kategorizovani kao sledei:

a) Poslovni ciljevi b) Projektni ciljevi

Poslovni ciljevi Poslovni ciljeve predstavlja ono to kupac eli da dobije sa ovim reenjem. On takoe slui za definisanje kriterijuma uspeha reenja. Svrha definisanje poslovnog cilja je jasna artikulacija delova projekta i da se obezbedi reenje koje podrava poslovne zahteve. Projektni ciljevi Projektni ciljevi se fokusiraju na vie atributa reenja a manje na to da li e se ispuniti poslovni ciljevi. Ocena vizije/opsega dokumenta Posle rane verzije vizije/opsega dokumenta, tim pregleda i modifikuje dokument. Faza predvianja se zavrava sa kontrolnom takom ocena. Ova kontrolna taka predstavlja taku u kojoj se projektni tim i kupac slau u pravcu daljeg rada na projektu ukljuujui opseg reenja. Dalji pravac dokumenta je isporuivost projekta koji se uzima u sledeoj fazi.

modul Predvianje i analiza Dokument projektne strukture

Dokument projektne strukture definie pristup organizaciji tima i naina upravljanje projektom. Takoe opisuje administrativnu strukturu, standarde i procese kao i resurse i ogranienja. Pomou ovog dokumenta projektni tim saznaje na koji nain moe uspeno da sarauje. Projektna struktura moe dati pristup svakoj ulozi u MSF timu. Ukoliko oekujete velike izmene u projektu, projektna struktura bi trebalo takoe da opie kako bi tim prihvatio te promene. Komponente Dokument projektne strukture Postoje tri primarne komponente projektne strukture i to:

1) Struktura tima 2) Projektne procene 3) Projektni raspored (prva verzija)

Dokument projektne strukture je alat za dokumentovanje odluke u odnosu na izvrenje i rukovoenje projektom i ukljuuje:

Odgovornosti uloge tima i kupaca Odluke o komunikacijama Logistike odluke Odluke promene menadmenta Ocene progresa projekta

Uloge i odgovornosti prilikom odluivanja Uloge i odgovornosti u projektnoj strukturnoj dokumentaciji je lista imena ljudi koji su ukljueni u projekat i njihove kontakt informacije, kao to su brojevi telefona, e-mail adrese. U dodatku ovog dela daje se opisivanje odluivanja u pogledu odgovornosti razliitih uloga kasnijih faza projekta. Odluke za vreme faze planiranja Za vreme faze planiranja tim mora da donese odluke odgovarajui na sledea pitanja:

Kako e projekat da se razvije? U kreiranju projektnog plana kako e tim da iskoristi svoje znanje i

iskustvo od izmena drugih projekata? Da li e tim imati akcije sastanaka u svom rasporedu tokom projekta? Koliko esto e kupac vriti pregled? Kako e se u budunosti distribuirati razliite verzije reenja? Ko e identifikovati rizik u projektu i definisati nepredviene trokove? Koji alati e se koristiti za razvoj i praenje planova? Da li e tim imati konsultativne sastanke za vreme faze planiranja? Ko e

biti prisutan na tim sastancima? Odluke za vreme faze razvoja Za vreme faze razvoja, tim mora da donese odluke odgovarajui na sledea pitanja:

Sa kojim grupama, organizacijama i spoljnim trgovcima e tim biti u interakciji za vreme projekta?

Ko je odgovoran za kreiranje i upravljanje ugovorima sa treim licima? Koja je uloga i odgovornost svakog tim lidera u razvojnom radu? Ako razliite komponente u reenju su bile razvijene od razliitih timova,

koja je uloga i odgovornost svakog tim lidera u projektu? Da li e komponentni tim biti pridodat pomonim informacijama, korisniku

iskusnog tima i timu za testiranje? Koja je uloga izvrnog osoblja u projektu? Koja je uloga podizvoaa, ako su neophodni u projektu? Ko e izabrati

podizvoaa i ko e pratiti njihov rad? Odluke komuniciranja Odluke komuniciranja projektne strukture dokumenta, specificira komunikacione procese koje e tim voditi tokom projekta, kako meusobno tako i sa kupcima. Tim pravi odluke odgovarajui na sledea pitanja:

Ko treba biti informisan pri odlukama planiranja? Ko e informisati kupce, deoniare i tim pri odlukama planiranja? Koji tipovi sastanaka e biti odravani, gde e biti odravani i ko e biti

odgovoran za svaki tip sastanaka? Ko e praviti dnevni red sastanaka? Ko e pripremiti sastanke?

Ko mora biti informisan o napretku projekta i ko e to da uradi? Odluke ocenjivanja projektnih fajlova Tipini fajl je sastavni deo svakog projeta u organizaciji. Ovaj fajl sadri informacije kao to su ugovori, rasporedi, i planovi. U projektnoj strukturi dokumenta tim odluuje koje informacije e se pothranjivati u projektnim fajlovima. Odluke koje projektni fajl mora da sadri su:

Koje informacije e biti ukljuene u projektne fajlove, kao to su projektna specifikacije, rasporedi, planovi, ugovori?

Ko e kreirati projektni fajl odravanja? Ko moe pristupiti projektnom fajlu? Ko e uvati projektni fajl posle zavretka projekta i koliko dugo?

Logistike odluke Logistike odluke u projektnoj strukturi dokumenta, dokumentuju odluke doneene potujui razvoj reenja. Tim donosi odluke odgovarajui na sledea pitanja: 1. Koja razvojna praksa e se primeniti u razvoju projekta? Neke mogunosti

ukljuuju: 1.1. Metode razvoja kao to su provere specifikacije proizvoda i lista

provere nultih greaka. 1.2. Metode testiranja 1.3. Metode dokumentacije 1.4. Metode marketinga

2. Ko e definisati sadraj specifikacije proizvoda? Ko e koristiti specifikacije proizvoda za vreme projekta?

3. Koji alati e se koristiti za realizaciju reenja? 4. Kako e kriterijum izvrenja proizvodne specifikacije biti utvren? 5. Ko e omoguiti timu auriranje sa novom verzijom? Upravljanje promenama odluka Upravljanje promenama odluka pokriva procese tima koji e slediti prilikom prihvatanja izmena projekta. Odluke su doneene obazirui se na upravljanje izmenama i ukljuuje:

Ko e definisati izmene u projektu? Koji je datum zavretka? Ko e definisati datum zavretka, i kako e biti

definisan? Ko e definisati upravljanje promenama procesa? Ko e predloiti izmene koje e biti identifikovane i praenje? Ko e pratiti

te informacije? Ko e imati uticaj na promene? Kolika odstupanja e biti prihvatljiva pre

glavne promene rasporeda? Procena napredka Procena napredka projektne strukture dokumenata pokriva procese tima koji e se pratiti i vrednovati. Odluke koje se donose trebalo bi da odgovore na sledea pitanja:

Kako e napredak projekta biti procenjen? Koje informacije treba meriti za procenu napredka?

Kako e se informacije o napretku za svaku aktivnost dobijati od lanova tima? Koliko esto e se te informacije prikupljati?

Koliko esto e se grupni raspored aurirati? Koliko esto raspored glavnog projekta e se aurirati?

Ko e identifikovati i pristupiti reavanju problema, svake razlike? Ko e biti ukljuen u razvoj adaptivnih aktivnosti? Ko e preporuiti i

odobriti adaptivne aktivnosti? Analiza rizika Rizik je mogunost gubitka. Gubitak moe biti bilo ta; od gubitka kvaliteta reenja do poveanja trokova, premaivanja krajnjih rokova ili nedovretka projekta. MSF preporuuje da rizik projekta se mora pratiti kontinualno kroz projekat. Proces upravljanja rizikom Bitni aspekt razvoja uspenog reenja je kontrolisanje i presretanje rizika koji je bitan u projektu. Najvei broj pojedinaca spaja koncept rizika sa potencijalnim gubitkom vrednosti, kontrole, funkcionalnosti, kvaliteta ili roka zavretka projekta. Meutim, rizik projekta takoe ukljuuje greke za postizanje maksimalne koristi kao i greke u donoenju odluka, koje mogu da vode do gubitka poslovne mogunosti. Koraci u procesu upravljanju rizikom Definie se est koraka preko kojih, menader rizikom, upravlja i izvrava strategije upravljanja rizikom, dokumentuje ih za budue projekte. Ti koraci su:

Identifikacija rizika Identifikuje se rizik i formira se tim koji zna za potencijalne probleme

Analiza rizika i prioritetnost Prevodi informacije o potencijalnim rizicima u informacije koje tim moe da koristi za donoenje odluka, i odreuje resurse za prioritetno presretanje rizika.

Planiranje rizika i raspored Koriste informacije razvijene u analizi rizika za formulisanje strategije presretanja rizika, planova i akcija. Alociranje vremena za planiranje rizika u projektnom planu.

Praenje rizika i izvetavanje Praenje stanja specifinih rizika i napretka njihovog plana presretanja. Tim, kupci i deoniari se izvetavaju o ovom napretku.

Kontrola rizika Izvravanje plana presretanja rizika i izvetavanje o statusu rizika.

Uenje o riziku Dokument i lekcije za uenje iz projekta tako da tim i organizacija mogu ponovo iskoristiti te informacije.

modul - Dizajniranje Faza planiranja

Za vreme faze planiranja tim definie reenje kao i sledee informacije: ta se razvija, kako se razvija i ko razvija. Ova faza moe poeti ak i za vreme faze predvianja, uvek kad se sakupe dovoljno informacija da bi se izvrila njihova analiza. U toku faze planiranja, tim nastavlja sa radom iz prethodne faze i razrauje detaljnu organizaciju i analizu. Rezultati faze planiranja su arhitektura i dizajn reenja, planovi za realizaciju razvoja, kao i distribuciju reenja. Postoje tri dizajn procesa u fazi planiranja: konceptualni, logiki i fiziki dizajn. Ova tri procesa nisu paralelna. Njihove poetne i krajnje take se meusobno preklapaju i meusobno su zavisni. Logiki dizajn je zavistan od konceptualnog dizajna dok je fiziki dizajn zavistan od logikog dizajna. Bilo koja promena u

konceptualnom dizajnu deluje na logiki dizajn a to neminovno povlai uticaj na fiziki dizajn. Uloge pojedinih dizajna i uloge u timu u fazi planiranja: Tip dizajna Perspektive Svrha Konceptualni Sagledava problem iz perspektive

korisnika i posla Definie problem i reenje u obliku korisnikog scenarija

Logiki Sagledava reenje iz perspektive projektnog tima

Definie reenje logikog seta kooperativnih servisa

Fiziki Sagledava reenje iz perspektive ljudi iz razvoja

Definie servise reenja i tehnologije.

Svaka uloga u timu tokom faze planiranja ima razliite odgovornosti:

Menadment proizvoda Ova uloga je odgovorna za izradu zahteva, analiziranje tekueg poslovnog stanja, optimizaciju konceptualnog reenja i kreiranje konceptualnog dizajna.

Program menadment Ova uloga je odgovorna za opti dizajn sa naglaskom na logikom dizajnu i funkcionalnoj specifikaciji. Takoe kreira projektne planove i vremeski raspored i odgovoran je za kompletiranje faze planiranja.

Razvoj Ova uloga je odgovorna za kreiranje logikog i fizikog dizajna reenja. Tim takoe definie vreme i zahtevani trud za razvoj i stabilizaciju reenja.

Testiranje - Obezbeuje testiranje reenja. Osim toga jo je odgovorna za vrednovanje dizajna, definisanje plana i vremenskog rasporeda za osobine koje treba testirati.

Menadment realizacije Vrednuje dizajn za laku distribuciju, rukovanje i podrku. Ova uloga planira vremenske rasporede distribucije reenja.

Iskusni korisnik Obezbeuje da e korisnici biti u mogunosti korienja proizvoda. Ova uloga je odgovorna za analiziranje korisnikih potreba i kreiranje podrke vrednovanje kompletnog korisnikog dizajna.

Kontrolne take i isporuivost faze planiranja Faza planiranja se zavrava na kontrolnoj taki na kojoj dolazi do slaganja izmeu projektnog tima, kupca i projektnih deoniara, u vezi isporuke i cilja projekta. Konane isporuke na kontrolnoj taki ove faze su:

Funkcionalna specifikacija (bazna linija) Funkcionalna specifikacija predstavlja ta e biti sa projektom, baziranom na ulaznim parametrima tima.

Glavni plan projekta (bazna linija) Glavni plan projekta je skup planova i definisanih aktivnosti koje su predstavljene za svaku od, prethodno definisanih, est uloga tima.

Vremenski raspored glavnog plana (bazna linija) Vremenski raspored je vremenski okvir glavnog plana. Ukljuuje vremenski okvir u kome tim namerava da kompletira njihov rad. Pridodavanjem individualnih vremenskih rasporeda daje se timu sveobuhvatni pogled na vremenski raspored projekta i na prvi pogled definie datum isporuke projekta.

Auriranje dokumenta rizika glavnog projekta Rizik glavnog projekta je bio razvijen jo u fazi predvianja. Meutim tokom faze planiranja mora se vriti auriranje, dokumenata rizika, koji su se eventualno kasnije pojavili u samoj tekuoj fazi a koje nismo mogli predvideti ranije.

Svi ovi dokumenti su tekui dokumenti, neophodni za napredak u samom projektu. Mada se ovi dokumenti mogu modifikovati, bilo koja modifikacija dokumenta, mora se prethodno odobriti od komisije korisnika i deoniara. Funkcionalna specifikacija Funkcionalna specifikacija definie ta e biti razvijeno, kako bi to bilo razvijeno i kada e biti razvijeno. Projektni plan, vremenski raspored, kako e se projekat realizovati, kao i datumi za razliite kontrolne take u projektu su sadrani u funkcionalnoj specifikaciji. Funkcionalna specifikacija je virtualno spremite projekta i kreiran je za vreme faze planiranja u MSF procesnom modelu. Upotrebne injenice su rezultat aktivnosti dizajna koji se javlja za vreme konceptualnog dizajna, logikog dizajna i fizikog dizajna procesa. Ove upotrebne injenice mogu ukljuiti UML modele kao to su dijagrami sluajeva, korisnike scenarije, zahteve kandidata, karakteristike kandidata i razliite informacione module. Ciljevi funkcionalne specifikacije

Utvrivanje zajedniko razumevanje poslovnih i korisnikih zahteva Osobine reenja zavise od poslovnih i korisnikih zahteva koje reenje treba da zadovolji. Finkcionalna specifikacija pomae kupcu i projektnom timu da dostignu zajeniko razumevanje zahteva reenja.

Ralanovanje problema i modulizacija logikog reenja Za uspenost kompleksnih projekata, vano je da tim jasno identifikuje sve delove problema. Takoe, je neophodno da tim ralani reenje na jasne, nedvosmislene delove. Funkcionalna specifikacija pomae timu da pojednostavi reenje u logike delove i dokumente. Takoe pomae da se naprave izmene u ranoj fazi u toku razvoja procesa. To ini reenje manje riskantnim i jeftinijim nego da se izmene vre kasnije.

Omoguavanje strukture za planiranje, vremenski raspored i razvoj reenja Funkcionalna specifikacija omoguava takoe timu da kreira predvianje trokova i budet celog projekta, resursa i zahtevano vreme za realizaciju. Tim za testiranje koristi funkcionalnu specifikaciju za kreiranje test sluajeva i test scenarija u ranoj fazi projekta. Menadment tim realizacije koristi funkcionalnu specifikaciju za razmetanje reenja i podrku razvoja u test okruenju.

Slui kao ugovor izmeu tima i kupca za to ta treba da se isporui U najveem broju organizacija, funkcionalna specifikacija slui kao ugovor izmeu tima i kupca; i predstavlja pisani dokaz ta treba da bude razvijeno i isporueno.

Elementi funcionalne specifikacije Elementi koji su mogui u funkcionalnoj specifikaciji, moraju se dati u posebnim dokumentima a to su: 1) Saet konceptualni dizajn Saet konceptualni dizajn ukljuuje informacije

kao to su pregled reenja i arhitektura reenja. Sledei elementi iz konceptualnog dizajna se koriste u funkcionalnoj specifikaciji:

a) Sluajevi korienja b) Korisniki scenario c) Kontekstni modeli

Ovi elementi mogu postojati u razliitom obliku. Na primer konteksni modeli mogu biti slike sa ekrana, postojee fotokopije korisnikih uputstava ili izvetaja. Sluajevi korienja mogu biti uzeti iz dokumentacione baze

podataka dok konceptualni korisniki interfejs (UI), prototipova, moe biti u elektronskoj formi.

2) Saet logiki dizajn U okviru logikog dizajna ukljuene su informacije kao to su korisnici, objekti i atributi. Elementi iz faze logikog dizajna koji su ukljueni u funkcionalnu specifikaciju su:

a) Aktivnost i modeli niza aktivnosti b) Logiki objekat i modeli servisa c) Korisniki interfejs (UI) redosled ekrana d) Logiki model baze podataka e) Sistemska arhitektura

3) Saeti fiziki dizajn Omoguava saeti fiziki dizajn i ukljuuje informacije koje su kljuni delovi dokumenta, kao to su aplikacija i infrastruktura. Sledei elementi iz fizikog dizajna su ukljueni u funkcionalnu specifikaciju:

a) Paketi komponenata b) Tehnologija distribucije komponenata c) Tehnologija korienja uslova d) Opisi UI ekrana e) Fiziki model baze podataka

Standardi i procesi Ovaj deo ukljuuje informacije o standardima i procesima koje tim koristi kao ogranienje za predstavljanje razliitih aktivnosti za projekat. Takoe ukljuuje detalje o kvalitetu i meraima performansi koji e biti korieni. Proces konceptualnog dizajna Proces konceptualnog dizajna poinje za vreme faze predvianja i nastavlja se u fazi planiranja. Tokom ovog procesa vri se sakupljanje, analiza i prioritetizacija poslova kao i korisnika perspektiva; da bi se kreirala prezentacija reenja na visokom nivou. Prilikom sakuplanja informacija, jako je bitno da tim razume razliku izmeu zahteva od razliitih kategorija:korisnik, sistem, operacija i posao. Da bi ste napravili ispravan i korisni koncept dizajn reenja, neophodno je da koristite metode za razumevanje reenja i komunikaciju reenja sa svim tipovima korisnika. Omoguavanjem ove komunikacije, vi kreirate modele aktivnosti koji e pokrivati opseg reenja. Model ovih aktivnosti i njihovi delovi generiu korisnike sluajeve i korisnike scenarije.

Ciljevi konceptualnog dizajna

Bez konceptualnog dizajna moete kreirati reenje ali sa velikim problemima. Ciljevi kreiranje konceptualnog dizajna ukljuuje:

Razumevanje poslovnog problema koji treba da se rei Razumevanje poslovnog zahteva, zahteva kupca i korisnikog zahteva Opisivanje buduih stanja poslova

U konceptualnom dizajnu projektni tim namerava da razume kontekst problema, zapisuje poslovne aktivnosti i pokuava da shvati njegove granice i relacije. Koraci konceptualnog dizajna Konceptualni dizajn se sastoji iz tri koraka koji se nalaze na baznoj liniji a poto je ovaj dizajn i iterativni proces, koraci se ponavljaju onako kako se zahtevaju. 1. Istraivanje Za vreme ovog koraka, predstavljaju se sledee aktivnosti:

a. Dobijanje odgovora na kljuna pitanja b. Identifikacija kljunih poslovnih procesa i aktivnosti c. Prioritetizacija procesa i aktivnosti

d. Ocena valjanosti, redefinisanje i skica zahteva, korisnikih sluajeva, i korisniki scenarija koji se kreiraju za vreme faze predvianja

2. Analize a. Pregled korisnika i poslovno istraivanje b. Redefinisanje zahteva kandidata c. Dokumentovanje i modeliranje konteksta, radni dijagram, sekvence

aktivnosti i relacije okruenja 3. Optimizacija

a. Optimizacija konceptualnog reenja formiranog za vreme faze predvianja b. Ocena validnosti i testiranje poslovnih procesa

Optimizacije bazne linije se sastoji u pribliavanju baznoj liniji konceptualnog dizajna.

modul - Dizajniranje Konceptualni dizajn Posle sakupljanja detaljnih informacija o poslu, korisnikim zahtevima i poslovnim procesima, tim nastavlja analizirajui korak konceptualnog dizajna. Analizirajui korak konceptualnog dizajna U toku analizirajueg koraka konceptualnog dizajna, sintetizuju se informacije koje ste sakupili za vreme istraivanja i kreiranja detaljnog korisnikog scenarija. Svrha analizirajueg koraka je:

Pregled korisnika, poslovnog procesa i aktivnosti Dokumentovanje konteksnog modela, radnih dijagram, sekvenci

aktivnosti, i poslovne relacije okruenja. Aktivnosti u analizirajuem koraku Analizirajui korak predstavlja sledee aktivnosti:

Sintezu informacija Predefinisanje use case dijagrama Izbor odgovarajue arhitekture aplikacije reenja Kreiranje konceptualnog modela reenja

Sinteza informacija, znai proces prihvatanja sakupljenih informacija i interpretacija rezultata. Sinteza analizirajueg koraka Sledea tabela prikazuje kljune aktivnosti i isporuke analizirajueg koraka Aktivnosti Isporuke Sinteza sakupljenih informacija

Informacioni modeli Relacije izmeu poslovnog procesa,

poslovnog sistema i korisnika Proces radnog toka Sekvence aktivnosti Aurirani korisnikih profila Zahtevi kandidata Detaljni use case Kreiranje korisnikih scenarija Tekui korisniki scenario

Preformulacija zahteva Kada vrite preformulaciju zahteva pridravajte se sledeih kriterijuma:

1. Zahtevi moraju biti dobro definisani. 2. Zahtevi moraju biti saeti 3. Zahtevi moraju biti proverljivi 4. Zahtevi moraju biti organizovani u hijerahiskim relacionim zahtevima. 5. Zahtevi bi trebalo da budu napisani poslovnim jezikom, bez upotrebe

argona Kategorizacija zahteva Kategorizacija zahteva, omoguava da budete uvereni da je tim bio istrajan u otkrivanju kritinih zahteva. Korisniki zahtevi Korisniki zahtevi definie ne funkcionalni aspekt korisnike interakcije sa reenjem. Oni vam pomau da definiete korisniki interfejs i predstavlja oekivanje reenja u obliku pouzdanosti, raspoloivosti i prihvatljivosti. Uspeno reenje zadovoljava i organizacione potrebe za tehnologijom i korisnika oekivanja sa primenom tehnologije.

Sistemski zahtevi Sistemski zahtevi specificiraju male transakcije i njihove faze u sistemu, i pomou projektnog tima definie kako novo reenje da bude u interakciji sa postojeim sistemima. Projektni tim takoe identifikuje kritine zavisnosti sa spoljnim sistemom sa kojim se mora upravljati. Pre razvoja novog reenja, projektni tim mora razumeti tekuu infrastrukturu u organizaciji.

Operativni zahtevi Operativni zahtevi opisuju ta reenje mora isporuiti za maksimiziranje operativnosti sa redukcijom vremena i rizika. Kljuni elementi operativnosti su:

Bezbednost Raspoloivost i pouzdanost Upravljivost Scalabilnost Podrivost

Poslovni zahtevi Poslovni zahtevi opisuju organizacione potrebe i iekivanje reenja. Definie se ta reenje treba da da, poslovne mogunosti ili da se ispune poslovni zahtevi.

Redefinisanje use case dijagrama

Za vreme faze predvianja, projektni tim kreira use case dijagram, specificira sve use case-ove visokog nivoa u organizaciji. Svrha ovog use case dijagrama je lista kljunih use case-ova u sistemu, da definie opseg reenja i postavi osnovu za koncept reenja. Kreiranjem koncepta modela dizajna, neophodno je da redefiniete use case-ove sa opsegom reenja korienjem sakupljanje informacija za vreme istraivakog koraka konceptualnog dizajna. Redefinisanje use case dijagrama, predstavlja sledee aktivnosti:

Kreiranje subordinate use case - va Kreiranje korisnikih scenarija za svaku subordinatu use case-ova Validacija svakog use case - a i korisnikog scenarija na osnovu

originalnog intervijua, nasuprot druge dokumentacije Redefinisanje zahteva sa validacijom use case i informacijom korisnikog

scenarija

Ciklusi aplikacije

Pod predsednik

Prodavci

Kupci

Kontrolor

Pogled proizvoda

Upravljanje proizvodima

Upravljanje zahtevima

Upravljanje ugovorima

Analiza kupaca

Prodajni ciljevi

Prognoza prodaje

Korisnici

Korisnici

Korisnici

Kreiranje podreenih use case-ova Kreiranje podreenih use case-ova, vi dajete kritinu ocenu svakog use case-a u celokupnom use case dijagramu za dati opseg projekta. Onda indetifikujete svaku aktivnost preko use case-a, indetifikujete sve uesnike i relacije izmeu razliitih aktivnosti i uesnika.

Izbor arhitekture aplikacije Kljuni naglasak u konceptualnom dizajnu je konceptualni model reenja. Da bi ste kreirali konceptualni model potrebno je da razumete servise koje reenje mora da omogui.

Korisnici

UI Komponente

UI Komponente procesa

Interfejsi servisa

Upr

avlja

nje

opar

acija

ma

Bezb

edno

st

Kom

unik

acija

Poslovni tok Poslovne komponente Poslovni entiteti

Logike komponente pristupa podacima Agenti servisa

Sloj podataka

Izvor podataka Servisi

Prezentacioni sloj

Poslovni servisni sloj

Dodatni servisni sloj

Servisi u reenju

Servis je definisan kao logika aplikaciona jedinica koja ukljuuje metode implementacije na rad, funkcije ili transformacije. Servisi su udrueni sa akcijama i primenjuje poslovna pravila, manipulacija podacima i omoguuje akcije kao to su dodavanje, pronalaenje, pregled i modifikaciju podataka. Servisima se moe pristupiti preko mree kroz interfejs koji sadri specifikacije interfejsa. Kupcu nije vano kako je servis primenjen; ve mu je vana mogunost predstavljanja zahtevane akcije. Tipovi servisa

Tipini servisi koje reenje omoguava su:

Korisniki servisi Korisniki servisi su logike jedinice aplikacije, koji omoguavaju korisniki interfejs u aplikaciji. On upravlja interakcijom izmeu aplikacije i korisnika.

Poslovni servisi Poslovni servisi su logike jedinice aplikacije koje primenjuju poslovna pravila u ispravnim redosledima. Poslovni servis skriva primenu logikog poslovnog pravila i trasformie podatke od korisnikog servisa drugim poslovnim servisima i servisima podataka.

Servisi podataka Servisi podataka su logike jedinice aplikacije koji omoguavajudetalje najnieg vidljivog nivoa za manipulaciju podacima. Koristite servise podataka za primenu poslovne sheme na smetanju podataka koristei aplikaciju. Servisi podataka su iskorieni za upravljanje svim vrstama podataka, statikih, strukturnih i dinamikih.

Sistemski servisi Sistemski servisi su logike jedinice aplikacije koje omoguavaju funkcionalnost izvan poslovne logike. Zajedniki sistemski servisi ukljuuju:

o Servise bekapa o Servise obrade greaka o Bezbednosne servise o Servise poruka

Arhitektura aplikacije

Takoe je neophodno znati kako su servisi organizovani u aplikaciji. Arhitektura aplikacije se sastoji iz definicija, pravila i relacija oblika strukture aplikacije. Ona pokazuje kako aplikacija je struktuirana ali ne ukljuuje detaljnu primenu. Arhitekture aplikacija ukljuuje:

1. Klijent/server arhitektura 2. Slojevita arhitektura 3. Stateless arhitektura 4. Arhitektura kea 5. Slojevita-klijent-ke-stateless-ke-server arhitektura

Klijent/server arhitektura Klijent/server arhitektura je dvo - slojni pristup, koji je baziran na strategiji zahteva i odgovora. Klijent inicira sesiju sa serverom i kontrolama sesija, server odgovara na zahtev. Prednosti primene ovog tipa arhitekture aplikacije je da moete podeliti procesne zahteve radi ispunjenja aktivnosti izmeu dva ureaja. Meutim jedno od ogranienja ove arhitekture je visoka klijentska zavisnost od servera. Ako veza izmeu klijenta i servera je u kvaru, klijent ne moe da odradi ak ni osnovne aktivnosti. Ova aplikaciona arhitektura ne bi trebalo da se koristi kada se zahteva mogunost uklapanja, kao i za bilo koje reenje koje mora omoguiti veliki broj zahteva.

Slojevita arhitektura Slojevita arhitektura je razvijena na verzijama klijent/server arhitekturi i sastavljena od hijerahijskih slojeva. Razliiti servisi u aplikaciji su jasno pozicionirani u specifinim slojevima na slian nain tako da mogu komunicirati sa drugim servisima jedino ako je sloj susedan. Sloj enkapsulira servise i zatiuje jedan servis od drugog; dok istovremeno omoguava jednostavne interfejse za deobu resursa. Prezentacioni, poslovni, servisi podataka i servisi smetanja podataka su meusobno razliiti slojevi u slojnoj arhitekturi. Prednosti slojevite strukture ukljuuje poboljan sistem uklapanja i visoku bezbednost. Moete takoe balansirati servisima preko raspoloivih resursa i razliitih slojeva. Takoe slojevi omoguavaju primenu bezbednosti sa dobro-definisanim granicama, sa malim negativnim uticajem na komunikaciju izmeu servisa sa sistemom. Meutim ovaj pristup poveava kompleksnost reenja.

Stateless arhitektura Stateless arhitektura je verzija klijent/server ili slojevita arhitektura u kojoj svaki klijentski zahtev sadri sve informacije koje su zahtevane od servera radi razumevanja zahtevnog procesa. Informacije nisu smetene kod klijenta. Prednosti stateless sistema ukljuuje:

Poboljana preglednost Pouzdanost Skalabilnost

Arhitektura kea Keiranje je sledei pristup u kome aplikacija omoguuje odgovore za neke klijentske zahteve bez prosleivanja zahteva drugom ureaju. Primenom ove vrste aplikacione arhitekture, neophodno je da indentifikujete ta moe a ta ne da se keira. Takoe je neophodno definisati nain upravljanja ivotnim vekom elementa u keu. Zato to keiranje izbegava stalni prenos zahteva i odgovora izmeu klijenata i servera, performanse aplikacije i mree su velike. Ova arhitektura omoguava visok stepen uklapanja, preko kreiranja lokalnog smeanja za najee zahteve sredstava, dok u drugom sluaju bie u redu ekanja na pristup. Meutim keiranje smanjuje efikasnost reenja.

Slojevita-klijent-ke-stateless-ke-server arhitektura Ova arhitektura je bazirana na browser-u u vindovs distribuiranom internet aplikacijama (DNA). To je kombinacija slojevite-klijent-server, klijent-ke, i ke-stateless-server pristupima, dodajui proxies kroz siste ako je neophodno. Ova arhitektura omoguava da kreirate visoko fleksibilne i uklapajue aplikacije preko

distribucionih procesiranja i preostalog stateless na serveru. Takoe ova arhitektura je sloeno, upravljivo i fleksibilno reenje.

Optimizacija konceptualnog dizajna

Poslednji korak konceptualnog dizajna je optimizacija. Za vreme optimizacije, vi dizajnirate reenje uzimajui u obzir koncept reenja koji e biti u konanoj aplikaciji.

Optimizacija procesa Prilikom istraivanja i analiziranja tekueg poslovnog procesa, vi definiete koje procese ete ukljuiti u reenje i kako e se ovi procesi iskoristiti. Rukovodioci ili vlasnici procesa, korisnici, i projektni tim moraju raditi zajedno na reenju. Takoe prilikom dizajna morate voditi rauna da scenario eliminie neefikasnost, uska grla i ponavljanje istih informacija. Aktivnosti koje opisuju budua stanja Da bi opisali budui status, tim mora da uradi sledee aktivnosti:

Da ima viziju budunosti Da pobolja postojeu produktivnost Da Razmotri porebe prema eljama Da uravnotei posao sa zahtevima korisnika Da uravnotei sadraj sa tehnikom izvodljivou Redizajniranje tekueg procesa za optimalnom podrkom kljunih

proizvodnih aktivnosti i procesa ukljuujui, poslovne procese koji su redizajnirali i prihvatili eksperti.

Optimiziranje ulaznih procesa Integrisanje procesa kad god je to mogue Eliminisanje neefikasnosti, uskih grla i ponavljanje istih informacija

Redizajniranje procesa iz perspektive korisnika Da bi se indetifikovali zahtevi iz korisnike perspektive, treba imati na umu sledee stavke:

Indentifikovanje neeljenih pojedinih aktivnosti, uskih grla i beznaajnih faza u procesu

Integrisanje pojedinanih funkcionalnih informacionih sistema u konsolidovane iroke procesne sisteme

Odreivanje minimalnog nivoa performanse koje mora biti dostignuta u samom procesu

Pokuaj da se dizajniraju procesi koje bi postigli iste rezultate ali sa manje napora

Smanjivanje praznog hoda sistema zahvaljujui indentifikaciji faza koje bi mogle da se odvijaju istovremeno umesto jedna za drugom.

Poboljanje sistema zahvaljujui snadbevanju korisnika sa svim potrebnim informacijama, kao to su povratne informacije o performansama koja omoguava da se problemi odmagh razree

Ocena redizajniranog procesa

Procena redizajniranog procesa se radi da bi se odredilo da li postoji bilo kakvo nerazumevanje ili nedostatak informacije koje zahtevaju korisnici. Takoe treba potvrditi da nema problema bez obzira na razliita gledita reenja lanova tima. Vri se i procena trokova i korisnosti od tekueg reenja. Mnogi projekti na ovom nivou prestaju da se razvijaju zbog toga to procena pokazuje da nema dobiti od investiranja. Dodatno, potrebno je da se odredi primarna i sekundarna korist.

Ocena konceptualnog dizajna modela

Poto se kreira konceptualni dizajn onda se vri njegova ocena sa uz uee svih korisnika. Valjanost konceptualnog dizajna reenja nasuprot korisnikog sluajeva, korisnikog scenarija, poslovnih zahteva, arhitekture, rizika, moguih resursa i vremena i svih drugih injenica koje su razvijene.

Razlog za ocenu konceptualnog dizajna Scenario ocene valjanosti trebalo bi takoe da ukljui ocenu rezultata prioritetnih aktivnosti. Neophodna ocena konceptualnog dizajna reenja je zato to:

1. Smanjuje rizik 2. Pomae vam da pronaete nestale informacije 3. Pokazuje promenljive poglede i prezentuje reenje, posebno izmeu

poslova i korisnika 4. Verifikuje opseg aktivnosti 5. Pomae pri prioritetizaciji 6. Omoguava baznu liniju za nastavljanje logikog dizajna

Koraci u ocenjivanju konceptualnog dizajna Proces za ocenjivanje, testiranje i redizajniranje moe ukljuiti sledee korake:

1. Redizajn posla 2. Kreiranje seta scenarija za podravanje posla 3. Izbor tehnika za ocenjivanje sistema 4. Crtanje korisnikoh interfejsa 5. Dobijanje korisnike i poslovne povratne sprege 6. Ponavljanje dok korisnici i poslovi su zadovoljni

Tehnike za ocenjivanje konceptualnog dizajna Prolaz Animator vodi korisnike kroz scenario i postavlja pitanja na tom putu sa namerom da odredi da li se korisnici slau sa pojedinim akcijama i dogaajima. Igranje uloga (simulacija) Skup izabranih korisnika rukovode sa vie scenarija kako bi ocenili procese, indetifikovali podruja za moguee ispravke. Aktivnost pomae timu da izvri selekciju jednog od scenarija koji treba da se detaljnije dizajnira. Prototip Obezbeuje detalje procesa, tok procesa, organizacione implikacije i tehnoloke mogunosti. Prototip je efikasan nain za komuniciranje sa zdruenim i sintetizovanim zahtevima korisnika. Moe da se kreira ili u elektronskoj ili u papirnoj varijanti. Prototipovi treba da se pregledaju i procene od strane tima i takoe treba da se omogui menadmentu da donese odluku o dizaknu finalnog procesa.

modul - Dizajniranje Logiki dizajn

Logiki dizajn je definisan kao proces opisivanja reenja u organizacijama, strukture i interakcije delova sa stanovita projektnog tima. Logiki dizajn obrauje sledee:

1. Definie sastavne delove reenja 2. Omoguava infrastrukturi da sadri sve delove reenja zajedno 3. Ilustruje kako je reenje ukomponovano sa korisnicima i drugim

reenjima.

Kada se kreira logiki dizajn tim uzima u obzir sve poslovne, korisnike, sistemske i operativne zahteve i odreuje potrebu za: bezbednou, praenjem, logovanjem, skalabilnosti, upravljanje porukama, obrad greaka, licenciranjem, globalizacijom, arhitekturom aplikacije i integracij sa drugim sistemima. Logiki dizajn moe poeti i pre nego to se zavri konceptualni dizajn. Odluka o poetku logikog dizajna se donosi od sluaja do sluaja i u zavisnosti od projekta i od projektnog tima. Kada projektni tim pree sa konceptualnog na logiki dizajn menja se i perspektiva projekta.