STRATEGIJA I PLANIRANJE ICT TEHNOLOGIJA modul - Predviđanje 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 konačan proizvod. Projekat uvek ima jasno definisan početak i kraj. Projekat se obično (doduše ne i uvek) pokreće na inicijativu korisnika, njegove komponente definiše rukovodilac projekta, a realizacija je u nadležnosti projektnog tima koji sastavlja rukovodilac. Neki projekti po prirodi mogu biti „eksperimentalni“, kada se zahteva razvoj nečega što ispunjava potrebe industrije ili zadovoljava strategijske ciljeve, ali se za krajnje rezultate ne može garantovati zato što do sada nije bilo sličnih pokušaja. Projekat ne bi smeo da se bavi nečim što je već dobro poznato, već nečim što bi povećalo efikasnost već poznatog. Šta su procesni modeli? Procesni model je vodič u izboru aktivnosti u toku projekta i istovremeno predstavlja životni ciklus projekta. Postoje statični modeli i modeli kod kojih nisu primenljive kontrolne tačke. Takva dva modela su model vodopada i spiralni model. Ovi modeli omogućavaju različite pristupe u životnom ciklusu projekta. Vodopadni model Kod vodopadnog modela ceo projekat se razvija frontalno kroz više faza. Prelazak iz jedne faze u drugu fazu se vrši tek onda kada se pojedina faza završi i kad se pređe kontrolna tačka faze.

Posle prve faze, Planiranje razvoja, sistem se analizira u okviru druge faze. Zatim u okviru treće faze vrši se projektovanje celog sistema, pa implementacija (kodiranje i testiranje) da bi u okviru poslednje faze sistem došao u stanje održavanja.

Za vreme sistem analize može doći 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 vršiti izmene. Ponovno prolaženje kroz sve faze je preskupo. Vodopadni model najbolje se primenjuje kod projekata gde su projektni zadaci jasno definisani i koji se neće bitnije menjati u budućnosti. Zato što model ima fiksne tačke prelaska iz faze u fazu, mogu se lako pratiti rasporedi obaveza i pridodati jasni odgovori i mogućnosti. Prototipski-modifikovani vodopadni model Prototipski razvoj softvera se bazira na prototipu koji je razrađen 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 poslužiti samo za preciznu specifikaciju zahteva a zatim biti odbačeni (“odbačeni 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 budućeg sistema i brže dovodi do rezultata. -Prouzrokuje nerealistična očekivanja korisnika, očekuje se da će i radni sistem biti isto tako brzo razvijen kao i prototip. -Zahtevaju se specifična sredstva za razvoj prototipa, troškovi razvoja ne smeju da pređu 10-15% ukupnih troškova projekta

Spiralni model Ovaj model je baziran na najboljim osobinama vodopadnog modela i modela prototipskog razvoja uz dodavanje elementa - analize rizika. Model definiše četiri aktivnosti, prisutne u svakom ciklusu a predstavljene kvadrantima. 1. Planiranje - određivanje ciljeva, alternativa i ograničenja. 2. Analiza rizika - procena alternativa i identifikacija i razrešenje mogućih rizika. 3. Inženjering - razvoj proizvoda. 4. Ocenjivanje od strane naručioca - vrednovanje rezultata inženjeringa i donošenje odluke o nastavku razvoja.

Ako analiza rizika pokaže da u specifikaciji zahteva postoje nepreciznosti, u fazi inženjeringa se mora ići na razvoj prototipa, kako bi se ostvarila što bolja komunikacija razvojnog tima i naručioca, u suprotnom sledi konvencionalni model vodopada. U koliko, posle ove aktivnosti, analiza rezultata inženjeringa pokaže da je rizik preveliki projekat se može i obustaviti.

Nedostaci spiralnog modela leže u prevelikom oslanjanju na ekspertsku ocenu rizika koja dosta zavisi od samih ljudi koju tu ocenu vrše 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 podugovarača stvara teškoće, jer ugovori moraju precizno da specificiraju šta treba isporučiti pa nema velike fleksibilnosti i usklađivanja među učesnicima. MSF (Microsoft Solutions Framework) MSF procesni model opisuje opšte delove aktivnosti za izgradnju i razvoj rešenja za preduzeća. Ovaj proces je fleksibilan i može se prilagoditi razvoju preduzeća u različitim projektima. On je iterativan, fazno bazirani model, sa kontrolnim tačkama 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. Predviđanje 2. Planiranje 3. Razvoj 4. Stabilizacija 5. Distribucija

Svaka od ovih faza završava se sa kontrolnim tačkama. Organizacija projektnih timova Microsoft Solutions Framework – procesni model u sebi sadrži i MSF tim model za organizaciju projektnog tima. MSF tim model ističe važnost jasnih uloga, odgovornosti i postizanje ciljeva pojedinih članova koji vodi ka uspešnosti projekta. Ovaj model takođe povećava odgovornost svakog člana tima. Uloge u MSF tim modelu:

1. Menadžment proizvodom 2. Menadžment programom 3. Razvoj 4. Testiranje 5. Menadžment realizacijom 6. Iskusni korisnik

Uloga menadžmenta proizvodnje – odgovorna je za upravljanje komunikacijom sa kupcem i da sagleda očekivanja kupca. Za vreme faze dizajniranja, menadžeri proizvodnjom sakupljaju zahteve kupca i uveravaju se da li su te informacije neophodne za realizaciju. Menadžeri proizvodnje takođe rade na planovima projektne komunikacije kao što su kratki izveštaji kupcima, marketiranju korisnika, demonstracijama proizvoda kao i korišćenje proizvoda. Uloga menadžmenta programom – odgovorna je za proces razvoja i za isporuku rešenja kupcu sa projektnim ograničenjima. Uloga razvoja – odgovorna je za razvijanje odgovarajućeg tehnološkog rešenja koje je dao menadžment programom.

Uloga testiranja – odgovorna je za identifikaciju svih kvaliteta proizvoda i dokazivanja da je ponuđeno rešenje odgovarajuće. Ova uloga ocenjuje i vrednuje funkcionalni dizajn i održivost sa stanovišta opsega i vizije projekta. Uloga menadžmenta realizacijom – odgovorna je za realizaciju svih neophodnih operacija za rešenje zahteva kupca. Menadžment realizacijom ocenjuje infrastrukturnu primenu rešenja i sigurnost da može biti rešenje realizovano. Uloga iskusnog korisnika –je da analizira neophodne performanse i podržava puštanje u rad za korisnika kao i da vrši razmatranje da li proizvod odgovara postavljenim zahtevima korisnika. U okviru malog projekta pojedinci u projektnom timu mogu uzeti jednu ili više uloga. Kombinacija uloga na projektu mogu dovesti do rizika u okviru samog projekta. Mora se strogo voditi računa o pridodavanju uloga članovima tima. Na primer nije preporučljivo da pojedinac prisvoji i ulogu menadžera 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 više pojedinaca koji iniciraju i odobravaju projekat i rezultat projekta Kupac (ili poslovni sponzor) – je jedan ili više pojedinaca koji očekuju poslovne koristi od rešenja Krajnji korisnik – je jedan ili više pojedinaca ili sistem koji su u vezi sa rešenjem. Operativci – organizacije odgovorne za rad rešenja nakon isporuke. Upravljanje kompenzacijama Česti razlozi za ne uspevanje projekata su prekoračenje datuma završetka projekata ili prekoračenje predviđenog budžeta. Da bi se takve situacije prevazišle, neophodno je da se vrše pojedine kompenzacije u okviru same realizacije projekta. Projekat u okviru svoje oblasti definiše šta treba da se dogodi a šta ne. Efikasno upravljanje opsegom projekta podrazumeva da se uzmu u obzir sledeća razmatranja:

• identifikacija projektnih ograničenja • upravljanje kompenzacijama • uspostavljanje kontrole izmena • praćenje napretka projekta

U procesu identifikacije i upravljanju kompenzacijama nije neophodno da se izvrši smanjenje karakteristika rešenja, ali sama kompenzacija može dovesti do smanjenja karakteristika. Upravljanje kompenzacijama omogućava da na jedan strukturni način izbalansirate sve delove projekta u okviru realizacije, tako da ne možete postići sve maksimalne vaše 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 odgovarajućih promena koje nisu neophodne da se menjaju. Rešenje za dalji razvoj je da se zahtevi kupca korektno izbalansiraju između resursa, datuma primene i karakteristika. Ovaj trougao pomaže u objašnjenju ograničenja 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 uočeni u sledećoj rečenici: Za date fiksne resurse, izaberite raspored dešavanja i podesite karakteristike ako je to neophodno.

Korišćenje iteracija u projektima Prilikom razvoja rešenja, projekat prolazi kroz faze razvoja a svaka faza čini da je rešenje bliže krajnjoj realizaciji. Ovakav način rada omogućava da se projekat razvija u manjim koracima i da se sledeća iteracija bazira na uspehu ili grešci prehodnog koraka. Opseg vizije dokumenta, kod, dizajn i planovi se razvijaju na iterativnoj osnovi. Koje događaje uključuje u iteracije svaki životni ciklus projekta?

• Kreiranje realizovanih verzija

• Kreiranje tekućih dokumenata • Kreiranje periodične izrade (nedeljno ili dnevno)

su događaji koje uključuju iteracije u životnom ciklusu projekata. Realizacija verzija Kada korišćenjem MSF tima za razvoj rešenja, izgrađuje se, testira i primenjuje glavne funkcionalnosti rešenja i onda se dodaje novi set osobina u svakoj novoj realizaciji, zove se strategija realizacija verzija. Plan kreiranja više verzija Kreiranje planova više verzija omogućuje timu da donese pravu odluku o tome šta kreirati a šta kasnije kreirati. Takođe na ovaj način se najbolje iskorišćavaju mogućnosti rasporeda rada resursa.

Brzi prolaz kroz iteracije Značajna prednost kreiranja verzija je da je isporuka primenljivih rešenja kupcu brza i da raste sa vremenom. Prvo isporučivanje glavne funkcionalnosti Isporučivanje osnovnog rešenja je korisnije i efektivnije od razvijanja rešenja koje kupac ne može koristiti nedeljama ili mesecima. Prvo kreiranje visoko rizičnih osobina Za vreme detektovanja rizika, tim identifikuje najriskantnije karateristike rešenja. Izrada ovih karakteristika se postavljaju tako da se prve odrade da bi se samim tim i izvršilo samo testiranje koncepta rada. Ako se tom prilikom uoči bilo koji problem koji zahteva veće promene u arhitekturi rešenja, te izmene se mogu primeniti pre u projektu tako da se smanjuje uticaj promena na vreme izvršenja rešenja i na budžet. Tekuće dokumentacije Izrada dokumentacije u svakoj fazi izrade rešenja omogućuje timu da napravi modifikaciju bilo kog dela projekta u toku dizajniranja i razvoja, kada postoje zahtevi za takvom promenom. Odatle proističe da se MSF dokumentacija iterativno razvija. Svakodnevne dogradnje

MSF preporučuje česte izrade komponenata rešenja za testiranje i pregled. Ovaj pristup omogućava razvijanje koda u daljem razvoju hardverskih i softverskih komponenti. Pravljenjem svakodnevnih izmena, možete biti sigurni da će te postići stabilnost ukupnog rešenja i akumulirati test podatke i pre krajnjeg rešenja.

modul - Predviđanje i analiza Faze u MSF proces modelu

Kao što je u prethodnom času naglašeno MSF proces model sastoji se od pet faza i to:

• Predviđanje • Planiranje • Razvoj • Stabilizacija • Distribucija

Šta predstavlja faza predviđanja?

Predviđanje može biti definisano kao definisanje širokog opisa ciljeva i ograničenja projekta. U ovoj fazi indetifikuje se tim kao i zadaci tima. Osim toga vrši se usaglašavanje ciljeva projekta između svih ključnih zainteresovanih strana u projektu. Ova faza se završava na kontrolnoj tački dokaza opsega vizije projekta.

Proces predviđanja

Tokom faze predviđanja tim prolazi kroz nekoliko ključnih događaja: Sastavljanje tima Stariji menadžer sastavlja tim u koje ulaze osobe koje svojim znanjem i veštinama mogu da ispune odgovarajuće zadatke Definisanje projektne strukture – Ovde se definišu standardi za upravljanje projektom u koju spada administrativna struktura Definisanje ciljeva poslova – Analizira se poslovni problem i mogućnosti na koji se ovaj problem može rešiti. Procenjivanje tekuće situacije – Ispituje se tekuća situacija i analiziraju se razlike između tekuće i očekivane situacije. Ova aktivnost je neophodna da bi se uočili problemi i odredili pravci daljeg kretanja projekta. Sagledavanje celokupnog problema i određivanje opsega projekta – Prilikom sagledavanja celokupnog problema neophodno je i odrediti i dugotrajni pravac u komunikaciji radi postizanja poslovnog cilja. Identifikacija opsega projekta definiše šta će a šta ne da bude uključeno u rešenje. Definisanje zahteva i korisničkih profila – U ovom delu je neophodno da se izvrši identifikacija deoničara, identifikacija krajnjih korisnika i sponzora projekta i imati dokumentaciju njihove neophodnosti za rešenjem. Ove informacije pomažu u izradi vizije i opsega projekta i prilikom kreiranja koncepta rešenja. Razvoj koncepta rešenja - Formira se osnovni koncept rešenja koji će tim uzeti u obzir prilikom rada na rešenju. Ovaj koncept se formira na osnovu prihvaćenih zahteva Ocena rizika – Za vreme svih stanja životnog veka proizvoda, vrši se procena rizika projekta i kreira se plan smanjenja rizika. Zatvaranje faze predviđanja – Kada je projekat formalno odobren od svih deoničara i projektnog tima, pristupa se zatvaranje faze predviđanja. Svaka faza MSF procesnog modela ima svoje interne kontrolne tačke i glavne kontrolne tačke završetka pojedinih faza.

Interne kontrolne tačke se pojavljuju sa različitim aktivnostima u okviru faze. Kontrolne tačke u okviru predviđanja su: Formiranje glavnog tima – Podrazumeva biranje ključnih članova tima kao i njihove uloge u timu. Kreiran opseg projekta – Ova kontrolna tačka nastaje posle prve verzije opsega projekta, kada je dokument kompletiran i podeljen članovima tima, kupcima i deoničarima na pregled. Tokom ovog pregleda, dokument je podložan i modifikaciji.

Glavne kontrolne tačke - se postavljaju na kraju faza i koje pokazuju da se može preći na sledeću fazu razvoja. Faza predviđanja se završava sa kontrolnom tačkom odabranog opsega projekta, gde su se svi činioci složili.

Rezultati faze predviđanja

Posle svakog događaja tim daje rezultate. Zajedno sa tim rezultatima, daje se sadržaj i pravac delovanja tima kao podsetnik za dalje napredovanje projekata. Koji rezultati se prave za vreme faze predviđanja?

1.Opseg projekta • Izjave o problemima i ciljevima poslova • Pregled postojećih procesa • Širu definiciju korisničkih zahteva • Identifikacija povlašćenih korisnika rešenja • Definicija vizije i opsega projekta • Skiciranje koncepta rešenja • Strategija dizajniranja rešenja

2.Strukture projekta • Opis svih MSF uloga u timu i lista odgovarajućih č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 definiše šta treba razviti i planira kako da dođe do rešenja. Tim takođe priprema specifikaciju funkcionalnosti, projektuje rešenje, priprema radne planove, predviđa troškove i vremenski raspored za različite rezultate.

Faza planiranja obuhvata i analizu zahteva. Ovi zahtevi mogu biti podeljeni u poslovne zahteve, korisničke zahteve, operacione zahteve i sistemske zahteve. Koriste se prilikom projektovanja rešenja i osobina i kao ocena valjanosti dizajna.

Posle sakupljanja i analiziranja zahteva, tim vrši projektovanje rešenja. Kreiraju se korisnički profili za različite korisnike rešenja i njihove uloge i odgovornosti. Zatim se prave serije korisničkih scenarija, tj. specifičnih aktivnosti pojedinih tipova korisnika. Posle pravljenja korisničkih scenarija, tim kreira korisničke slučajeve za korisničke scenarije. Korisnički slučajevi specificiraju delove koraka, koje će korisnik uraditi u korisničkom scenariju.

Stanja projektovanja

1. Konceptualno projektovanje - u kojoj vidite problem iz perspektive korisnika i poslovnih zahteva i definiše se problem i rešenje u oblicima korisničkih scenarija.

2. Logično projektovanje – u kome se sagledava rešenje iz perspektive projektnog tima i definiše rešenje kao set usluga.

3. Fizičko projektovanje – u kome se sagledava rešenje iz perspektive razvoja i definiše tehnologije, interfejsi komponenata i servisa rešenja.

Funkcionalna specifikacija opisuje osobine i pojavu svake karakteristike rešenja. Takođe opisuje arhitekturu i dizajn za sve karateristike. Ona odgovara na pitanje „Šta će se napraviti?“. Tehnička specifikacija odgovara na pitanje „Kako će se to napraviti?“ U sebi ona uključuje klase, metode i osobine koje su neophodne da budu kreirane.

Proces projektovanja

Za vreme faze planiranja, timu su dodeljeni ključni događaji:

a) Razvoj i projektovanje rešenja – gde se vrši identifikacija poslovnih zahteva, korisničkih 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 rešenju.

c) Razvijanje projektnih planova – ovde se planiraju daogađaji koji će biti delovi glavnog projektnog plana

d) Kreiranje rasporeda projekta – kreira se raspored rada na glavnom projektu. Ovaj raspored se takođe sastoji iz kontrolnih tačaka za svaku timsku ulogu u projektnom timu.

e) Kreiranje okruženja za razvoj i testiranje – formiraju se odvojena okruženja u kojima se vrši razvoj i testiranje rešenja. Ovo okruženje je nezavisno od okruženja u kojem rešenje će biti primenjeno.

f) Zatvaranje faze planiranja – kada se izkompletiraju kontrolne tačke dolazi se do zatvaranja ove faze. Za vreme faze planiranja radi se i odgovarajuća dokumentacija.

Kontrolne tačke faze planiranja

Za vreme faze planiranja tim izvodi veći broj događaja. Unutrašnje kontrolne tačke su:

1. Kompletiranje tehnološkog vrednovanja - tim procenjuje proizvode i tehnologije koji će se iskoristiti za rešenje. Takođe proverava kupčevo tekuće proizvodno okruženje. Ova provera uključuje konfigurisanje servera, mrežu, desktop softver i sve relevantne hardvere.

2. Kompletiranje funkcionalne specifikacije – na ovoj kontrolnoj tački, funkcionalna specifikacija je kompletirana i prihvaćena za pregled kupca i deoničara.

3. Kompletiranje glavnog plana – glavni plan je kombinacija planova različitih uloga u timu. Dužina i kompleksnost zavisi od veličine projekta.

4. Raspored kompletiranja glavnog projekta – raspored glavnog projekta uključu je sve rasporede detaljnih projekata i datuma završetka projekta.

5. Razvoj i testiranje podešenih okruženja – radno okruženje omogućava odgovarajući razvoj i testiranje rešenja i onemogućava negativan uticaj na sistem za koje rešenje će biti primenjeno.

Rezultati faze planiranja

Rezultati faze planiranja daju osnova za buduće 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 rešenje. U ovaj proces je uključeno kreiranje koda kao i kreiranje dokumentacionog koda.

Procesi razvoja

1) Početak razvojnog ciklusa – potvrđivanje svih događaja koji su u prethodnonim fazama već urađeni.

2) Formiranje prototipa – verifikacija koncepta rešenja projektovanja u datom okruženju.

3) Razvoj komponenata rešenja – razvijanje komponenata suštine rešenja. 4) Izgrađivanje rešenja – radi se na rešenju sve dok tim ne dovede do

rešenja u fazi da može da ga isporuči. 5) Zatvaranje razvojne faze – kompletiranje svih osobina i isporuka koda i

dokumentacije. Rešenje se smatra da je kompletirano i tim je ušao u stanje čekanja verifikacije rešenja.

Kontrolne tačke razvojne faze

Tim formira potvrdu koncepta aplikacije i tek onda radi na realizaciji rešenja. Unutrašnje kontrolne tačke razvojne faze su:

a) Potvrda koncepta aplikacije – ovaj test je ključni element rešenja u test okruženju. Tim vodi operacije i korisnike kroz rešenje da bi se izvršila validacija njihovih rezultata.

b) Završetak unutrašnje izgradnje – zato što rešenje je razvijeno u delovima, dobra praksa je da delovi rešenja se sinhronizuju u toku izrade. Broj i učestalost unutrašnjih izgradnji zavisi od veličine i kompleksnosti projekta.

Razvojna faza se završava sa kontrolnim tačkama kompletiranja opsega projekta. Od ove kontrolne tačke, sve karakteristike su kompletirane i proći će kroz jedinicu testiranja. Proizvod je sada spreman za spoljno testiranje i stabilizaciju. Rezultati faze razvoja su:

1) Sors kod i izvršni fajlovi 2) Početni tekst i podešavanje konfiguracije za razvoj 3) Završavanje funkcionalne specifikacije 4) Predstavljanje elemenata podrške 5) Specifikacija testa i test slučajevi

Faza stabilizacije

Tokom ove faze tim vrši beta testiranje rešenja. Koncentriše se na identifikaciju i rešavanje problema tako da rešenje može da bude pripremljeno za realizaciju. Stabilizacioni procesi

1) Testiranje rešenja – Primenjuje se test plan za validaciju rešenja. Pilot test je oslonjen na test okruženja. Uključeni testovi su:

a) Testiranje komponenti b) Testiranje baze podataka c) Testiranje infrastrukture d) Testiranje bezbednosti e) Testiranje integracije f) Korisničko testiranje g) Testiranje performansi, kapaciteta i opterećenja h) Testiranje regresije i) Zapisivanje broja grešaka

2) Ponašanje pilot rešenja – Primena rešenja i testiranje se vrši sa aktuelnim korisnikom i sa realnim korisničkim scenariom.

Praćenje testiranja i izveštaji Tokom razvoja, testiranja i stabilizacione faze, stalno se vodi praćenje i izveštavanje. Za vreme stabilizacione faze, daje se izveštaj o broju grešaka. Jako je bitna dobra komunikacija tokom testiranja među ključnim članovima tima i deoničarima. Kontrolne tačke stabilizacione faze Interne kontrolne tačke: Konvergencija grešaka – merenjem broja grešaka može se ustanoviti da li pojava grešaka se smanjuje ili ne. U slučaju da dolazi do smanjenja grešaka (konvergencije), govori timu da je projekat blizu završetka. Nula greška – Označava da u toku stabilizacione faze se došlo do nula grešake. Otpuštanje kandidata – Ako u toku stabilizacione faze je bilo povećanja provere rešenja, broj grešaka u poređenju sa nula greškama identičan. Zlatna realizacija – U toku stabilizacione faze, vrši se kombinacija nula grešaka i uspeha kao kriterijum mere. Stabilizaciona faza se završava sa kontrolnom tačkom realizacije spremnosti. Rezultati stabilizacione faze:

• Konačna realizacija • Beleške realizacije • Performanse elemenata za podršku • Rezultati ,testova i alati za testiranje • Sors kod i izvršni fajlovi • Projektna dokumentacija • Pregled kontrolnih tačaka

Faza distribucije

Tokom ove faze vrši se transfer projekta za rad i održavanje kao i dobijanje kupčeve potvrde o projektu. Tim je u kontaktu sa kupcem i vodi računa o projektu kao i o svim zahtevima kupca. Faza primene se završava sa kontrolnom tačkom 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 događaje.

2. Distribucija i stabilizacija – Kompletiranje tekuće komponente i položaj faze distribucije

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

Kontrolne tačke faze distribucije

a) Razvijanje glavnih komponenti – U zavisnosti od rešenja, glavna tehnologija, možda je neophodna da bude razvijena pre ili istovremeno sa položajem distribucije. Ako dođe do kašnjenja, glavne komponente moraju biti pregledane i odobrene za distribuciju sa ostalim delovima rešenja koja su bila stabilizirana.

b) Položaj distribuiranih komponenti – Vođenje razvoja za svaki položaj mora potvrditi njihove položaje koje rade. Ova kontrolna tačka možda ne bi bila primenljiva za projekte da ne uključuje distribuciju od strane klijenta.

c) Stabilna distribucija – Kod ove kontrolne tačke kupac i tim se slažu da je rešenje radno zadovoljavajuće. Neke osobine mogu se poboljšati sa različitim distribucijama.

d) Kompletirana distribucija – Ova kontrolna tačka je završetak faze distribucije. Od ovog vremena razvijeno rešenje trebalo bi da omogući očekivane poslovne vrednosti kupca.

Rezultati faze distribucije

1. Rad i podrška informativnom sistemu 1.1. Procedure i procesi 1.2. Osnovno znanje, izveštaji i knjiga logovanja

2. Dokumentacija za sve verzije 3. Plan obuke 4. Projektni završni izveštaj

4.1. Krajnje verzije svih projektnih dokumenata 4.2. Kupčevi zadovoljavajući podaci 4.3. Definisanje sledećih koraka

modul - Predviđanje i analiza

Korišćenje notifikacije modeliranja

Razlog korišćenja modela je to što problemi i rešenja u toku razvoja softvera su vrlo kompleksni. Ta kompleksnost može da zavisi i od komunikacije razvojnog tima i tima projektnih deoničara. Modeliranje može jasno predstaviti složenost problema i rešenja i njihovo razumevanje. Model tekućeg stanja i budućeg stanja

Zahtevi – Sistem koji je bio izmodeliran, diskutovan i analiziran, fokusira se na detalje modela i kroz saglasnost mogu se dostići odgovarajući zahtevi. Problemi i rizici – Ponekad postoji neslaganje oko toga šta je stvarni problem ili rizik sistema. Model može dovesti do toga da stručnjak objasni problem ili rizik a da ne mora biti upoznat sa svim detaljima. Nedostatak informacija – Kreiranje modela sistema, pomaže razvojnom timu lakšu 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, pomoću kojeg možete modelirati softver različite složenosti. Može biti korišćen 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 različitim

programskim jezicima. d) Dokumentaciju modela softvera preko izražavanja zahteva sistema za

vreme stanja razvoja i isporuke. Osobine UML-a

Osnovne osobine UML-a su:

a) Jednostavan, proširiv i brzo razvojni jezik

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

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

UML pogledi – Sadrže veliki broj grafičkih alata koji omogućavaju razumevanje sistema iz različitih pogleda Tipovi UML pogleda:

a) Korisnički pogled – To je pogled koji predstavlja deo sistema sa kojem korisnik je u interakciji. Korisnički pogled je takođe predstavljen i kao pogled korisničkog slučaja.

b) Strukturni pogled – Predstavlja statično ili prazno stanje sistema. Inače njegova oznaka je Design View

c) Pogled ponašanja – Prikazuje dinamičko ili izmenljivo stanje. d) Pogled primene – Daje strukturu logičkih elemenata sistema e) Pogled okoline – Predstavlja raspodelu fizičkih elemenata sistema. Ovaj

pogled specificira funkcionalnost sistema iz perspektive korisnika. On je takođe nazvan i Deployment View

UML dijagrami

Različiti UML pogledi uključuju dijagrame koji omogućavaju veći broj perspektiva rešenja koji će biti razvijeni. Bira se koji model će biti najbolje primenjen za uspešno modeliranje sistema. Tipovi UML dijagrama

a) Dijagram klasa – opisuje različite klase i njihove osobine. b) Objektni dijagram – opisuje različite objekte u sistemu i njihove relacije sa

svakom od njih c) Dijagram slučajeva – predstavljaja funkcionalnost spoljnih entiteta preko

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

tačkama fizičke implementacije sistema. f) Dijagram saradnje – je set klasa i poruka poslatih i primenjenih od istih. g) Dijagram sekvenci – sekvencioni dijagram opisuje interakciju između

klasa, tj poruke koje se razmenjuju između pojedinih klasa. h) Dijagram stanja – dijagram stanja opisuje algoritam različitih stanja

objekta konstruisan za prihvatanje i reagovanje na različite spoljne događaje.

i) Dijagram aktivnosti – je drugi način za pogled na stanje ali dijagram aktivnosti uključuje i sekvencijalne aktivnosti.

ORM (objekta uloga modeliranja) To je metod koji može biti iskorišćen za predstavljanje poslovnih pravila i dizajn baze podataka. Ovaj pristup je semantički pristup modeliranja koji opisuje reči 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, ograničenja činjenica i pravila koja su izvedena iz nekih drugih pravila. CSDP se sastoji iz sledećih događaja:

a) Analize spoljnih informacija i transformisanje u elementarne činjenice.

b) Primenjivanje osnovnih tipova entiteta u konceptualnom modelu. c) Primenjivanje jedinstvenih ograničenja konceptualnog modela. d) Primenjivanje vremenskih ograničenja konceptualnog modela. e) Dodavanje vrednosti ograničenja, ograničenja poređenja i podtipova

ograničenja konceptualnog modela. f) Dodavanje prstenastog ograničenja konceptualnog modela.

ORM terminologija

1. Instanca – događaj od interesa u rešenju. 2. Populacija – je grupa svih kombinovanih instanci datog tipa događaja

interesantnih u rešenju. 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 više od jedne populacije. Sve populacije su set, ali nisu svi set-ovi populacije.

4. Činjenična instanca – je pojedinačna zapažanje odnosa između dve ili više vrednosti podataka.

5. Tip činjenice – je set činjeničnih 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 način korišćenja 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 korisničkih scenarija i korišćenje slučajeva Korišćenje korisničkog scenarija i slučajeva omogućava da na jednostavan način se zabeleži funkcionalni zahtevi sistema. On opisuje serije događaja kada učesnici koriste sistem za kompletiranje procesa. Prilikom razvijanja sistema pomoću ovog scenarija bi trebalo predstaviti neophodan set aktivnosti i rezultata sistemskih procesa. Sledeći dijagram prikazuje UML dijagram koji predstavlja prethodne izjave o korišćenju 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. Izvođenje use case-a korisničkih slučajeva Da bi se izveli korisnički dijagrami morate biti u mogućnosti da identifikujete sledeće stvari:

a) Sistem b) Učesnike c) Interakciju između učesnika i sistema d) Granice sistema

a) Identifikacija sistema - Sistem je kolekcija podsistema koji imaju realnu svrhu postojanja. Kada se razvije korisnički slučaj (use case) vi u stvari indetifikujete jedan sistem ili podsistem. Kolekcija (use case) pokazuje relacije među podsistemima koji čine sistem.

b) Identifikacija učesnika - Učesnik je integralni deo korisničkog slučaja (use case). On je entitet koji je u interakciji sa sistemom koji bi trebalo da bude razvijen za svrhu kompletiranja događaja. Učesnik može biti: 1. Korisnik sistema 2. Entitet kao što je drugi sistem ili baza podataka, koji je izvan sistema

Prilikom definisanja učesnika, mora se odgovoriti na sledeća pitanja: • Ko koristi sistem? • Ko startuje sistem? • Ko održava sistem? • Koji drugi sistemi koriste sistem? • Ko dobija informacije od sistema? • Ko prosleđuje informacije sistemu? • Dešava li se nešto automatski u tom trenutku? • Ko ili šta inicira događaj sa sistemom? • Ko ili šta je u interakciji sa sistemom da bi mu pomoglo u odgovoru na

događaj? • Postoji li bilo koji interfejs izveštaja? • Postoji li bilo koji administrativni interfejs? • Da li je sistemu neophodno da ima interakciju sa bilo kojim postojećim

sistemima? • Da li su bilo koji učesnici definisani u sistemu? • Postoji li bilo koji drugi hardver i softverski uređaji koji su u interakciji sa

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

informisan o ovom događaju?

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

d) Granice sistema - Jedna od najtežih stvari u radu je definisanje pravih granica sistema koji bi trebalo razviti. Zato, da bi se ova aktivnost ispravno rešila, potrebno je odgovoriti na sledeća pitanja:

• Šta se dešava kad use case pridodate svakom učesniku? • Ko ili šta je u interakciji sa use case-om sada? • Šta ako pronađete nove zadatke? Da li će ti zahtevi biti deo sistema? • Da li ti zahtevi su neophodni za ovaj sistem? • Da li ti zahtevi nešto logički rade u sistemu? • Mogu li ovi zahtevi da budu prihvaćeni od jednog tekućeg učesnika? • Da li te zahteve kupac ili korisnik bi očekivali da nešto rade u sistemu?

Korisnički scenario

Use case opisuje interakcije visokog nivoa, između učesnika i sistema. Grupisani use case-ovi detaljno opisuje algoritam procesa. Korisnički scenario omogućava dodatne informacije o aktivnostima i fazama događaja koji su sadržane u procesu.

Izuzeci – su atipični događaji ili alternativne fazne aktivnosti koje omogućavaju kompletan opis use case-a.

Pravljenje korisničkih scenarija

Pri pravljenju korisničkih scenarija, neophodno je da odredite sledeće aktivnosti:

1) Definisati preduslove za korisnički scenario, specificirati informacije ili uslove koji moraju postojati pre donošenja scenarija koji bi trebalo da bude izvršen.

2) Odrediti postuslove, korisnički scenario, koji određuju rad ili krajnji cilj za vreme aktivnosti.

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

trebalo razviti korisnički scenario za ove izuzetke. 5) Odrediti zahtev za ovu pojedinačnu korisničku adresu, za praćenje i

mogućnost praćenja. 6) Odrediti izvor za ovaj korisnički scenario za drugu diskusiju i klasifikaciju.

Korisnički scenario tekućeg stanja

Korisnički scenario tekućeg stanja opisuje kako poslovne aktivnosti se sprovode; dok scenario budućeg stanja predstavlja aktivnosti koje bi želeli da budu izvršene. Za oba stanja scenario ističe poslovne procese, informacije, korisnika i aktivnosti.

modul – Predviđanje i analiza Sakupljanje informacija

Enterprajs arhitektura (arhitektura preduzeća) je predstavljena preko poslovno – dinamičkog sistema jedne tačke 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 služe kao vodilje i služe za klasifikaciju informacija koje se sakupe. Te kategorije su: poslovne, aplikativne, operativne i tehnološke. Poslovne – Poslovne kategorije opisuju kako posao radi, opisuju funkcije i aktivnosti funkcija koje su aktivne u toku poslova. Informacije iz ove kategorije takođe opisuju primarni poslovni cilj. Aplikativne – Kategorija aplikacije uključuje servise, funkcionalnost i povezuje korisnike različitih veština primenom zajedničke poslovne objektivnosti. Automatizovani poslovni servisi mogu uključiti, kompletne aplikacije, korisničke alate, produktivne alate, komponenata i modula koda koji omogućavaju analizu informacija ili funkcionalne aktivnosti. Operativne – Operativne kategorije opisuju šta je organizaciji neophodno da zna da bi počela poslovni proces i operacije. Ova kategorija uključuje standardne modele podataka, polise upravljanja podacima i opis informacione šeme poslovanja. Tehnološke – Tehnološka kategorija definiše: tehničke servise neophodne za predstavljanje i podršku poslovne misije, uključivanjem topologije, razvoj okruženja, aplikacioni programabilni interfejsi (APIs), bezbednost, mrežne servise, servis upravljanja bazom podataka (DBMS), tehničke specifikacije, hardver i operativne sisteme. Tehnologija omogućava vezu između aplikacije i informacije Tehnike sakupljanja informacija Postoje sledeće tehnike koje se mogu koristiti za sakupljanje informacija:

1. Senčenje 2. Intervjuisanje 3. Grupno fokusiranje 4. Pregledi 5. Korisničke instrukcije 6. Simulacija 7. Verzije prilaza

Senčenje – je tehnika u kojoj se zapaža korisnikovo predstavljanje aktivnosti, u aktuelnom radnom okruženju, i postavljaju se pitanja korisniku koja su važna za aktivnosti. Informacije koje se ovim putem dobijaju su informacije iz prve ruke i u kontekstu problema. Potrebno je sakupiti što veći broj informacija i posticati korisnike za što detaljnijim objašnjenjima u vezi aktivnosti. Senčenje može biti aktivno i pasivno. Pasivno senčenje je kada posmatrate korisnika i slušate bilo koje objašnjenje koje korisnik daje. Aktivno senčenje je kada vi postavljate pitanja i korisnik objašnjava događaje i aktivnosti. Ograničenja sistema senčenja se svode na:

1. Nemogućnost postavljanje svih neophodnih pitanja za jasno definisanje svake tačke.

2. Nemogućnost da zabeležite sve odgovore ali da bi se to prevazišlo možete koristiti i video zapis.

3. Usko fokusiranje na pojedine događaje, a samim tim nemogućost dobijanja dobrih rezultata za aktivnosti koje traju, nedeljama, mesecima, godinama.

Intervju – je sučeljavanje jedan na jedan između člana projektnog tima i korisnika. Kvalitet intervjua naravno da zavisi od veštine osobe koja intervjuiše i od one koja se intervjuiše. Intervju daje mogućnost za postavljanje širokog opsega pitanja o događajima koje ne mogu se zapaze putem senčenja. 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 dešavaju u drugom vremenskom intervalu. Grupno fokusiranje – je sesija u kojoj je omogućeno pojedinačno razmatranje događaja i povratna sprega. Grupno fokusiranje koristi tehnike grupnog intervjuisanja, kada su više korisnika direktno uključeni u proces sakupljanja informacija. Ovaj način omogućava 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 uključivanje registracionog formulara u kupčevu 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 koristeći ovu metodu su:

• Organizaciona struktura, dozvole korišćenja • Opterećenje tehničke podrške strukturama i dozvolama • Specijalne neophodnosti za relacijom u hardveru i softveru • Trening

Korisničke instrukcije – korisnik vas vodi po aktivnostima koje treba da se dese. Ovo omogućava da aktivno učestvujete u svakom koraku i procesu sa perspektive korisnika. Simulacija – omogućava sakupljanje informacija kreiranjem simulacionog predloženog rešenja. U ovom procesu možete sakupiti informacije o najčešće pritisnutim dirkama na tastaturi, kliktanje miša ili pauziranje koje može dovesti do toga da korisnik ima poteškoća sa aplikacijom. Simulacija može pomoći u verifikaciji kao i dokument informacijom od korisnika uključujući:

• Zahtev za kvalitetom • Zahtev za vremenom odgovora i ciljevima • Integracijom tekuće tehnologije i aplikacije

• Korisnički interfejs kao što su osobine koje korisnik želi da doda aplikaciji • Verifikacije procesa toka rada

Verzije prilaza - omogućava sakupljanje informacija ubacivanjem specijalnih funkcija praćenja u aplikaciju. Ovaj način može biti izveden u okviru posla ili u laboratorijskim podešavanjima. Verzije prilaza mogu odgovoriti na sledeća pitanja:

1. Koliko često je osobina bila iskorišćena 2. Koliko vremena je potrebno da se kompletira aktivnost 3. Koje osobine se najčešće koriste za izvođenje aktivnosti Strategija sakupljanja informacija Pre sakupljanja informacije neophodno je definisati strategiju na koji način da se to vrši. Ta strategija u sebi podrazumeva identifikaciju korisnika, definisanje pitanja i izbor odgovarajućih tehnika za sakupljanje informacija. Posle definisanja strategije, potrebno je da odgovorite na sledeća 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 zabeležiti informacije koje sakupite? e) U kom vremenskom okviru ćete sakupiti informacije?

Definisanje informacione strategije Postoji vodič kako da definišete informacione strategije:

a) Koristiti mnogostruke tehnike za sakupljanje informacija – U slučaju da se koristi samo jedna tehnika sakupljanja informacija, može se dogoditi da naše informacije budu nekompletne. Kombinacijom različitih tehnika ovaj nedostatak se može 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 računa da tehnika sakupljanja informacija mora uzeti u obzir i korisnika kao i perspektivu samog posla. Istraživanje svih mogućih izvora informacija u toku sakupljanja.

d) Sakupljanje informacija od grupe korisnika na istim poslovnim procesima – Različite grupe u poslu mogu biti prosleđeni na iste procese i da odgovaraju na iste poslovne izazove. Informacije sakupljene od ove grupe mogu pomoći projektnom timu da sagleda poslovni proces sa razne tačke gledišta.

Analiziranje informacija

Proces sakupljanja i analiziranja informacija je iterativan proces. Kada sakupite određene informacije i izanalizirate, možete shvatiti da su vam potrebne još neke informacije. Onda pravite nova pitanja koja će vam pomoći za nastavljanje analize poslovanja. Prilikom svake analize neophodno je da izvršite filtraciju najrelevantnijih za vaš rad. Sleće informacije su značajne za vaš rad:

• Neophodnost bezbednosti • Strukturne podrške rešenja i njihove karakteristike • Planiranje izmena u poslovanju i pogodnost projektnog rešenja • Predstavljanje korisnikovih očekivanja ili poslovnih potreba • Da li postoje aplikacije koje će biti u interakciji sa novim rešenjem • Kako postojeći poslovni procesi utiču na rešenje

Kada izvršite sistematizaciju i analizu informacija, možete uočiti koje neophodne informacije vam nedostaju.

modul – Predviđanje i analiza Faza predviđanja

Faza predviđanja je prva faza MSF procesnog modela. Za vreme ove faze tim kreira pogled na poslovni problem koji bi trebalo rešiti i prikazuje u kojoj su vezi problemi sa poslovima, kupcima i okolinom. Ovo pomaže timu da dobije jasnu viziju šta tim mora da ispuni da bi kupci bili zadovoljni.

Svrha faze predviđanja

Ova faza ima sledeće svrhe: a) Identifikacija cilja i ograničenja projekta b) Odgovor na pitanje izvodljivosti c) Osnovno rešenje koje članovi tima kreiraju kao moguće rešenje projekta d) Definisanje opsega projekta, koji pomaže pri analizi grešaka pri planiranju

sledeće faze e) Procenjuje resurse koji su neophodni za razvoj rešenja f) Identifikacija i raspored glavnih kontrolnih tačaka za projekat

Uloge i odgovornosti članova tima

Iako projektni tim radi kao jedna jedinica, postiže svoj zamišljeni cilj preko radnih grupa. Svaka uloga, pojedine grupe, ima svoje zadatke za sve vreme izvođenja projekta. Uloge tima i odgovornosti:

a) Menadžment proizvoda – Uloga menadžera je da sarađuje sa menadžerom programa i osigura da se ostvari vizija projekta. Za ostvarivanje ovog cilja menadžer proizvoda studira i analizira poslovni problem, poslovne zahteve, viziju projekta, poslovne ciljeve i korisničke profite.

b) Menadžment programa – Uspostavlja ciljeve projektovanja, definiše faktore uspeha i mere određuje koncept rešenja i vrši podešavanje projektne infrastrukture.

c) Razvoj – Razvojni tim omogućuje povratnu spregu tima sa tehničkom primenom razvoja proizvoda i radi na izvodljivosti konceptualnog rešenja.

d) Testiranje – Tim za testiranje omogućuje povratnu spregu cilja kvaliteta i specifične aktivnosti koji će biti neophodni za postizanje određenog nivoa kvaliteta. Ovaj tim primenjuje odluke za ciljeve kvaliteta, strategije testiranja i kriterijume prihvatanja, koji će se primeniti prilikom merenja kvaliteta.

e) Menadžment realizacije – Vrši 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 podršku rešenja.

Sastavljanje projektnog tima

Jedna od aktivnosti za vreme faze predviđanja je i formiranje tima za realizaciju projekta. Prilikom sastavljanja članova, tima mogu se uzeti u obzir sledeće karakteristike koje članovi tima moraju da ispunjavaju:

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

2) Veštine – Su osobine ili mogućnosti koje članove čini stručnim kao što su npr. matematička logika ili sposobnosti animacije.

3) Nivo izvođenja – je mogućnost izvršenja planiranih rezultata.

U okviru dodatnih razmatranja za svakog pojedinog člana tima mora se uzeti u obzir i sledeće:

a) Mogućnosti članova tima b) Cene ili budžet projekta c) Bezbednosna dozvola za rad članova tima

Priprema isporučivosti faze predviđanja

Mada postoje interne kontrolne tačke za vreme faze predviđanja, postoje i tri glavne tačke isporuke. One su:

• Dokument vizije/opsega – u kojoj su opisani projektni ciljevi i ograničenja. • Dokument projektne strukture – opisuje procese upravljanja projektom.

Vrši se identifikacija vođe tima za svaku ulogu u okviru MSF tim modela. • Dokument rizika – u kome je data kao početna identifikacija analiza rizika

projekta.

Dodatne isporuke za fazu predviđanja

Dodatne isporuke za fazu predviđanja može uključiti:

a) Inicijalna lista osobina testiranja

b) Preliminarni zahtevi i korišćenje case alata

c) Preliminarna arhitektura

d) Grafički korisnički interfejs (GUI)

Kreiranje vizije dokumenta

Vizija dokumenta je jedno od ciljeva faze predviđanja. Ovaj dokument sadrži ciljeve i ograničenja poslovnog rešenja i predstavlja prvi stepen slaganja između učesnika u projektu. Da bi se formirala vizija projekta, tim vrši više intervjua sa kupcima i deoničarima, analizira na višem nivou slučajeve korišćenja poslovne aplikacije i indetifikuje ograničenja poslovanja.

Sadržaj vizije dokumenta

Vizija dokumenata mora se fokusirati na razumevanju i definisanju problema i u sebi treba da sadrži sledeće:

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

6.1. Poslovne ciljeve 6.2. Ciljevi projektovanja

7. Faktore kritične za uspeh 8. Početni raspored

Informacije o problemu

Ovo je obično kratko izlaganje u kome se opisuju poslovne nade projekta, i ono je u zavisnosti od tekućih poslovnih aktivnosti. Novi član tima može iskoristiti ove informacije da može lako da se uklopi u postojeći projekat.

Informacija vizije projekta

Svrha informacije o viziji projekta je uspostavljanje zajedničke vizije i konsenzusa između članova tima projekta da bi projekat mogao da uspe. Ovaj deo

dokumenta takođe sadrži i dogovor o budućnosti samog projekta i tima ljudi koji ga radi. Informacija o viziji projekta treba da bude dovoljno kratka da može da se zapamti, jasna da bi bila razumljiva i dovoljno jaka da bi delovala motivišuće. Dobra informacija o viziji ima sledeće karakteristike:

1. Specifičnost – Vizija treba biti specifična i da uključuje idealna stanja poslovnog problema tako da je krajnji rezultat uspeh.

2. Merljivost – Pod merljivosti se podrazumeva da tim može definisati uspeh projekta u poređenju sa posebnim ciljevima

3. Izvodljivost – Dati potrebne resurse, vremenski okvir i veštine 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 pokušavaju da reše problem koji ne postoji.

5. Vremenska baziranost – Mora biti jasno procenjeno okvirno vreme za završetak rešenja

Korisnički profili

Svako rešenje se radi za određeni broj kupaca. Pre nego što krenete u sakupljanje drugih informacija, vrlo je značajno da razumete korisnika za koga se razvija rešenje. Uzima se jasni opis svakog korisnika, da bi tim mogao da napravi korisničke profile. Korisnički profili identifikuju korisnike tako da tim može pristupiti očekivanjima, rizicima, ciljevima i ograničenjima projekta.

Informacije koje su neophodne za kreiranje korisničkih profila

1. Ciljevi – Krajnji cilj korisnika uključuje listu stvari koje korisnik očekuje da može da radi u interakciji sa proizvodom.

2. Ograničenja – Vrlo su važna ograničenja za razumevanje faktora koji mogu da utiču na korisnikovu mogućnost korišćenja rešenja, kao što su softver i hardver.

3. Podrška dodeljivanju – Korisnički profili takođe sadrže informacije o problemima koje korisnici mogu imati sa istim proizvodima. Ove informacije će vam pomoći prilikom planiranja osobina podrške, kada korisnici mogu zahtevati korišćenje novog proizvoda.

4. Opšti korisnici – Definiše se gde rešenje podržava različite kulturne i lokalne potrebe.

5. Geografske granice – Opisuju se korisničke lokacije, uključujući geografsku i fizičku lokaciju, broj korisnika na svakom sajtu i širinu opsega i korišćenje mrežnih linkova između sajtova.

6. Protok informacija između korisnika – Daje se opis komunikacije koji se dešava između korisnika, uključujući tipove komunikacije, njihovu važnost i veličinu podataka koja se razmenjuje između različitih korisnika u zajednicama.

7. Korisničke funkcije – Opisuju aktivnosti koje korisnik izvršava kao što je kompletiranje profila kupca i korekcije kupčeve narudžbe i detalja.

8. Organizacija komunikacije – Neke organizacije imaju krutu hijerarhisku strukturu koje su ograničene sa kako, zašto i kada pojedinci mogu komunicirati kroz linije hijerarhije. Dokument formira granice hijerahijske organizacije.

9. Polise donošenja odluke – Opisuju direktni uticaj efektivne primene predloženog rešenja.

10. Dodatni faktori – Neophodno je i za svakog korisnika i za svaku lokaciju utvrditi i neke dodatne faktore kao što su: nekompatibilni protokoli, mrežni operativni sistemi i mogu uticati na uspeh aplikacije koje su bazirane na geografskom rešenju.

Definisanje opsega Jedan od kritičnih faktora uspeha projekta je jasno definisan opseg projekta. Opseg projekta definiše šta će a šta neće biti uključeno u projekat i baziran je na projektnoj viziji; a u sebi još sadrži i ograničenja preko resursa, vremena, i drugih limitirajućih faktora. Dok se definiše opseg projekta, tim odlučuje o ne tako bitnim osobinama rešenja, da li da se odmah realizuju ili da se ostave za neka druga rešenja projekta. Osobine koje se razmatraju izvan opsega projekta trebalo bi da budu dokumentovane u sledećoj verziji ili u sledećoj projektnoj dokumentaciji. Prilikom definisanja opsega vi definišete oblast u use case-u direktno ubacivanjem poslovnog izazova i mesta poslovanja. Možete jednostavno nacrtati pravougaonik oko relevantnih delova u prethodnim use case crtežima i izvesti nove use case dijagrame koji će zatim koristiti projekat.

Kreiranje koncepta rešenja Posle identifikacije poslovnog problema i definisanje vizije i opsega, tim kreira koncept rešenja koji u glavnom oslikava zahteve projekta. Sledeća slika pokazuje jednostavno konceptualno rešenje za identifikovani opseg projekta.

Kreiranje poslovne skice Skica po svom nazivu predstavlja samo pogled na koncept ne ulazeći u detalje i po svom sadržaju nije suviše tehnički orjentisana. Koncept rešenja uključuje konceptualni model sistemskog softvera i arhitekture hardvera. On je predlog za identifikaciju rešenja u okviru opsega. Tim mora razmatrati različite opcije i da izabere jednu najbolju za jedno rešenje. Takođe može se dati i uzak opseg drugih opcija za nekoliko alternativa. Elementi koncepta rešenja

Izabrano najbolje konceptualno rešenje mora u sebi sadržati resurse i vremenski okvir primene. Koncept rešenja uključuje sledeće elemente:

a) Faktore uspeha projekta i kriterijum prihvatanja projekta - Ovi kriterijumi uključuju listu provere zahteva koja mora biti zadovoljena pre nego što rešenje ode u realizaciju.

b) Početne pristupe za razvoj i isporuku rešenja - Ovi pristupi uključuju primere scenarija za sajtove i metode primene rešenja, broj korisnika koji će koristiti novo rešenje i kompletnu listu isporuka projekta tako da će novo rešenje biti operativno.

c) Početni opis funkcionalnosti rešenja - Koje će imati poslovni problem. Projektni ciljevi Da bi se projekat uspešno realizovao vrlo je važno da se ispravno identifikuju ciljevi projekta. Ti ciljevi mogu biti kategorizovani kao sledeći:

a) Poslovni ciljevi b) Projektni ciljevi

Poslovni ciljevi Poslovni ciljeve predstavlja ono što kupac želi da dobije sa ovim rešenjem. On takođe služi za definisanje kriterijuma uspeha rešenja. Svrha definisanje poslovnog cilja je jasna artikulacija delova projekta i da se obezbedi rešenje koje podržava poslovne zahteve. Projektni ciljevi Projektni ciljevi se fokusiraju na više atributa rešenja 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 predviđanja se završava sa kontrolnom tačkom ocena. Ova kontrolna tačka predstavlja tačku u kojoj se projektni tim i kupac slažu u pravcu daljeg rada na projektu uključujući opseg rešenja. Dalji pravac dokumenta je isporučivost projekta koji se uzima u sledećoj fazi.

modul – Predviđanje i analiza Dokument projektne strukture

Dokument projektne strukture definiše pristup organizaciji tima i načina upravljanje projektom. Takođe opisuje administrativnu strukturu, standarde i procese kao i resurse i ograničenja. Pomoću ovog dokumenta projektni tim saznaje na koji način može uspešno da sarađuje. Projektna struktura može dati pristup svakoj ulozi u MSF timu. Ukoliko očekujete velike izmene u projektu, projektna struktura bi trebalo takođe da opiše 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 izvršenje i rukovođenje projektom i uključuje:

• Odgovornosti uloge tima i kupaca • Odluke o komunikacijama • Logističke odluke • Odluke promene menadžmenta • Ocene progresa projekta

Uloge i odgovornosti prilikom odlučivanja Uloge i odgovornosti u projektnoj strukturnoj dokumentaciji je lista imena ljudi koji su uključeni u projekat i njihove kontakt informacije, kao što su brojevi telefona, e-mail adrese. U dodatku ovog dela daje se opisivanje odlučivanja u pogledu odgovornosti različitih uloga kasnijih faza projekta. Odluke za vreme faze planiranja Za vreme faze planiranja tim mora da donese odluke odgovarajući na sledeća 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 vršiti pregled? • Kako će se u budućnosti distribuirati različite verzije rešenja? • Ko će identifikovati rizik u projektu i definisati nepredviđene troškove? • Koji alati će se koristiti za razvoj i praćenje 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 odgovarajući na sledeća 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 trećim licima? • Koja je uloga i odgovornost svakog tim lidera u razvojnom radu? • Ako različite komponente u rešenju su bile razvijene od različitih timova,

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

iskusnog tima i timu za testiranje? • Koja je uloga izvršnog osoblja u projektu? • Koja je uloga podizvođača, ako su neophodni u projektu? Ko će izabrati

podizvođača i ko će pratiti njihov rad? Odluke komuniciranja Odluke komuniciranja projektne strukture dokumenta, specificira komunikacione procese koje će tim voditi tokom projekta, kako međusobno tako i sa kupcima. Tim pravi odluke odgovarajući na sledeća pitanja:

• Ko treba biti informisan pri odlukama planiranja? • Ko će informisati kupce, deoničare i tim pri odlukama planiranja? • Koji tipovi sastanaka će biti održavani, gde će biti održavani 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 Tipični fajl je sastavni deo svakog projeta u organizaciji. Ovaj fajl sadrži informacije kao što su ugovori, rasporedi, i planovi. U projektnoj strukturi dokumenta tim odlučuje koje informacije će se pothranjivati u projektnim fajlovima. Odluke koje projektni fajl mora da sadrži su:

• Koje informacije će biti uključene u projektne fajlove, kao što su projektna specifikacije, rasporedi, planovi, ugovori?

• Ko će kreirati projektni fajl održavanja? • Ko može pristupiti projektnom fajlu? • Ko će čuvati projektni fajl posle završetka projekta i koliko dugo?

Logističke odluke Logističke odluke u projektnoj strukturi dokumenta, dokumentuju odluke donešene poštujući razvoj rešenja. Tim donosi odluke odgovarajući na sledeća pitanja: 1. Koja razvojna praksa će se primeniti u razvoju projekta? Neke mogućnosti

uključuju: 1.1. Metode razvoja kao što su provere specifikacije proizvoda i lista

provere nultih grešaka. 1.2. Metode testiranja 1.3. Metode dokumentacije 1.4. Metode marketinga

2. Ko će definisati sadržaj specifikacije proizvoda? Ko će koristiti specifikacije proizvoda za vreme projekta?

3. Koji alati će se koristiti za realizaciju rešenja? 4. Kako će kriterijum izvršenja proizvodne specifikacije biti utvrđen? 5. Ko će omogućiti timu ažuriranje sa novom verzijom? Upravljanje promenama odluka Upravljanje promenama odluka pokriva procese tima koji će slediti prilikom prihvatanja izmena projekta. Odluke su donešene obazirući se na upravljanje izmenama i uključuje:

• Ko će definisati izmene u projektu? • Koji je datum završetka? Ko će definisati datum završetka, i kako će biti

definisan? • Ko će definisati upravljanje promenama procesa? • Ko će predložiti izmene koje će biti identifikovane i praćenje? 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 sledeća 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 ažurirati? Koliko često raspored glavnog projekta će se ažurirati?

• Ko će identifikovati i pristupiti rešavanju problema, svake razlike? • Ko će biti uključen u razvoj adaptivnih aktivnosti? Ko će preporučiti i

odobriti adaptivne aktivnosti? Analiza rizika Rizik je mogućnost gubitka. Gubitak može biti bilo šta; od gubitka kvaliteta rešenja do povećanja troškova, premašivanja krajnjih rokova ili nedovršetka projekta. MSF preporučuje da rizik projekta se mora pratiti kontinualno kroz projekat. Proces upravljanja rizikom Bitni aspekt razvoja uspešnog rešenja je kontrolisanje i presretanje rizika koji je bitan u projektu. Najveći broj pojedinaca spaja koncept rizika sa potencijalnim gubitkom vrednosti, kontrole, funkcionalnosti, kvaliteta ili roka završetka projekta. Međutim, rizik projekta takođe uključuje greške za postizanje maksimalne koristi kao i greške u donošenju odluka, koje mogu da vode do gubitka poslovne mogućnosti. Koraci u procesu upravljanju rizikom Definiše se šest koraka preko kojih, menadžer rizikom, upravlja i izvršava strategije upravljanja rizikom, dokumentuje ih za buduće 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 može da koristi za donošenje odluka, i određuje 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.

• Praćenje rizika i izveštavanje – Praćenje stanja specifičnih rizika i napretka njihovog plana presretanja. Tim, kupci i deoničari se izveštavaju o ovom napretku.

• Kontrola rizika – Izvršavanje plana presretanja rizika i izveštavanje o statusu rizika.

• Učenje o riziku – Dokument i lekcije za učenje iz projekta tako da tim i organizacija mogu ponovo iskoristiti te informacije.

modul - Dizajniranje Faza planiranja

Za vreme faze planiranja tim definiše rešenje kao i sledeće informacije: šta se razvija, kako se razvija i ko razvija. Ova faza može početi čak i za vreme faze predviđanja, uvek kad se sakupe dovoljno informacija da bi se izvršila njihova analiza. U toku faze planiranja, tim nastavlja sa radom iz prethodne faze i razrađuje detaljnu organizaciju i analizu. Rezultati faze planiranja su arhitektura i dizajn rešenja, planovi za realizaciju razvoja, kao i distribuciju rešenja. Postoje tri dizajn procesa u fazi planiranja: konceptualni, logički i fizički dizajn. Ova tri procesa nisu paralelna. Njihove početne i krajnje tačke se međusobno preklapaju i međusobno su zavisni. Logički dizajn je zavistan od konceptualnog dizajna dok je fizički dizajn zavistan od logičkog dizajna. Bilo koja promena u

konceptualnom dizajnu deluje na logički dizajn a to neminovno povlači uticaj na fizički dizajn. Uloge pojedinih dizajna i uloge u timu u fazi planiranja: Tip dizajna Perspektive Svrha Konceptualni Sagledava problem iz perspektive

korisnika i posla Definiše problem i rešenje u obliku korisničkog scenarija

Logički Sagledava rešenje iz perspektive projektnog tima

Definiše rešenje logičkog seta kooperativnih servisa

Fizički Sagledava rešenje iz perspektive ljudi iz razvoja

Definiše servise rešenja i tehnologije.

Svaka uloga u timu tokom faze planiranja ima različite odgovornosti:

• Menadžment proizvoda – Ova uloga je odgovorna za izradu zahteva, analiziranje tekućeg poslovnog stanja, optimizaciju konceptualnog rešenja i kreiranje konceptualnog dizajna.

• Program menadžment – Ova uloga je odgovorna za opšti dizajn sa naglaskom na logičkom dizajnu i funkcionalnoj specifikaciji. Takođe kreira projektne planove i vremeski raspored i odgovoran je za kompletiranje faze planiranja.

• Razvoj – Ova uloga je odgovorna za kreiranje logičkog i fizičkog dizajna rešenja. Tim takođe definiše vreme i zahtevani trud za razvoj i stabilizaciju rešenja.

• Testiranje - Obezbeđuje testiranje rešenja. Osim toga još je odgovorna za vrednovanje dizajna, definisanje plana i vremenskog rasporeda za osobine koje treba testirati.

• Menadžment realizacije – Vrednuje dizajn za laku distribuciju, rukovanje i podršku. Ova uloga planira vremenske rasporede distribucije rešenja.

• Iskusni korisnik – Obezbeđuje da će korisnici biti u mogućnosti korišćenja proizvoda. Ova uloga je odgovorna za analiziranje korisničkih potreba i kreiranje podrške vrednovanje kompletnog korisničkog dizajna.

Kontrolne tačke i isporučivost faze planiranja Faza planiranja se završava na kontrolnoj tački na kojoj dolazi do slaganja između projektnog tima, kupca i projektnih deoničara, u vezi isporuke i cilja projekta. Konačne isporuke na kontrolnoj tački 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. Uključuje 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 definiše datum isporuke projekta.

• Ažuriranje dokumenta rizika glavnog projekta – Rizik glavnog projekta je bio razvijen još u fazi predviđanja. Međutim tokom faze planiranja mora se vršiti ažuriranje, dokumenata rizika, koji su se eventualno kasnije pojavili u samoj tekućoj fazi a koje nismo mogli predvideti ranije.

Svi ovi dokumenti su tekući 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 deoničara. Funkcionalna specifikacija Funkcionalna specifikacija definiše š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 različite kontrolne tačke u projektu su sadržani u funkcionalnoj specifikaciji. Funkcionalna specifikacija je virtualno spremište 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, logičkog dizajna i fizičkog dizajna procesa. Ove upotrebne činjenice mogu uključiti UML modele kao što su dijagrami slučajeva, korisničke scenarije, zahteve kandidata, karakteristike kandidata i različite informacione module. Ciljevi funkcionalne specifikacije

• Utvrđivanje zajedničko razumevanje poslovnih i korisničkih zahteva – Osobine rešenja zavise od poslovnih i korisničkih zahteva koje rešenje treba da zadovolji. Finkcionalna specifikacija pomaže kupcu i projektnom timu da dostignu zajeničko razumevanje zahteva rešenja.

• Raščlanovanje problema i modulizacija logičkog rešenja – Za uspešnost kompleksnih projekata, važno je da tim jasno identifikuje sve delove problema. Takođe, je neophodno da tim raščlani rešenje na jasne, nedvosmislene delove. Funkcionalna specifikacija pomaže timu da pojednostavi rešenje u logičke delove i dokumente. Takođe pomaže da se naprave izmene u ranoj fazi u toku razvoja procesa. To čini rešenje manje riskantnim i jeftinijim nego da se izmene vrše kasnije.

• Omogućavanje strukture za planiranje, vremenski raspored i razvoj rešenja – Funkcionalna specifikacija omogućava takođe timu da kreira predviđanje troškova i budžet celog projekta, resursa i zahtevano vreme za realizaciju. Tim za testiranje koristi funkcionalnu specifikaciju za kreiranje test slučajeva i test scenarija u ranoj fazi projekta. Menadžment tim realizacije koristi funkcionalnu specifikaciju za razmeštanje rešenja i podršku razvoja u test okruženju.

• Služi kao ugovor između tima i kupca za to šta treba da se isporuči – U najvećem broju organizacija, funkcionalna specifikacija služi kao ugovor između tima i kupca; i predstavlja pisani dokaz šta treba da bude razvijeno i isporučeno.

Elementi funcionalne specifikacije Elementi koji su mogući u funkcionalnoj specifikaciji, moraju se dati u posebnim dokumentima a to su: 1) Sažet konceptualni dizajn – Sažet konceptualni dizajn uključuje informacije

kao što su pregled rešenja i arhitektura rešenja. Sledeći elementi iz konceptualnog dizajna se koriste u funkcionalnoj specifikaciji:

a) Slučajevi korišćenja b) Korisnički scenario c) Kontekstni modeli

Ovi elementi mogu postojati u različitom obliku. Na primer konteksni modeli mogu biti slike sa ekrana, postojeće fotokopije korisničkih uputstava ili izveštaja. Slučajevi korišćenja mogu biti uzeti iz dokumentacione baze

podataka dok konceptualni korisnički interfejs (UI), prototipova, može biti u elektronskoj formi.

2) Sažet logički dizajn – U okviru logičkog dizajna uključene su informacije kao što su korisnici, objekti i atributi. Elementi iz faze logičkog dizajna koji su uključeni u funkcionalnu specifikaciju su:

a) Aktivnost i modeli niza aktivnosti b) Logički objekat i modeli servisa c) Korisnički interfejs (UI) redosled ekrana d) Logički model baze podataka e) Sistemska arhitektura

3) Sažeti fizički dizajn – Omogućava sažeti fizički dizajn i uključuje informacije koje su ključni delovi dokumenta, kao što su aplikacija i infrastruktura. Sledeći elementi iz fizičkog dizajna su uključeni u funkcionalnu specifikaciju:

a) Paketi komponenata b) Tehnologija distribucije komponenata c) Tehnologija korišćenja uslova d) Opisi UI ekrana e) Fizički model baze podataka

Standardi i procesi – Ovaj deo uključuje informacije o standardima i procesima koje tim koristi kao ograničenje za predstavljanje različitih aktivnosti za projekat. Takođe uključuje detalje o kvalitetu i meračima performansi koji će biti korišćeni. Proces konceptualnog dizajna Proces konceptualnog dizajna počinje za vreme faze predviđanja i nastavlja se u fazi planiranja. Tokom ovog procesa vrši se sakupljanje, analiza i prioritetizacija poslova kao i korisnička perspektiva; da bi se kreirala prezentacija rešenja na visokom nivou. Prilikom sakuplanja informacija, jako je bitno da tim razume razliku između zahteva od različitih kategorija:korisnik, sistem, operacija i posao. Da bi ste napravili ispravan i korisni koncept dizajn rešenja, neophodno je da koristite metode za razumevanje rešenja i komunikaciju rešenja sa svim tipovima korisnika. Omogućavanjem ove komunikacije, vi kreirate modele aktivnosti koji će pokrivati opseg rešenja. Model ovih aktivnosti i njihovi delovi generišu korisničke slučajeve i korisničke scenarije.

Ciljevi konceptualnog dizajna

Bez konceptualnog dizajna možete kreirati rešenje ali sa velikim problemima. Ciljevi kreiranje konceptualnog dizajna uključuje:

• Razumevanje poslovnog problema koji treba da se reši • Razumevanje poslovnog zahteva, zahteva kupca i korisničkog zahteva • Opisivanje budućih stanja poslova

U konceptualnom dizajnu projektni tim namerava da razume kontekst problema, zapisuje poslovne aktivnosti i pokušava da shvati njegove granice i relacije. Koraci konceptualnog dizajna Konceptualni dizajn se sastoji iz tri koraka koji se nalaze na baznoj liniji a pošto je ovaj dizajn i iterativni proces, koraci se ponavljaju onako kako se zahtevaju. 1. Istraživanje – Za vreme ovog koraka, predstavljaju se sledeće aktivnosti:

a. Dobijanje odgovora na ključna pitanja b. Identifikacija ključnih poslovnih procesa i aktivnosti c. Prioritetizacija procesa i aktivnosti

d. Ocena valjanosti, redefinisanje i skica zahteva, korisničkih slučajeva, i korisnički scenarija koji se kreiraju za vreme faze predviđanja

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

aktivnosti i relacije okruženja 3. Optimizacija

a. Optimizacija konceptualnog rešenja formiranog za vreme faze predviđanja b. Ocena validnosti i testiranje poslovnih procesa

Optimizacije bazne linije se sastoji u približavanju baznoj liniji konceptualnog dizajna.

modul - Dizajniranje Konceptualni dizajn Posle sakupljanja detaljnih informacija o poslu, korisničkim zahtevima i poslovnim procesima, tim nastavlja analizirajući korak konceptualnog dizajna. Analizirajući korak konceptualnog dizajna U toku analizirajućeg koraka konceptualnog dizajna, sintetizuju se informacije koje ste sakupili za vreme istraživanja i kreiranja detaljnog korisničkog scenarija. Svrha analizirajućeg koraka je:

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

aktivnosti, i poslovne relacije okruženja. Aktivnosti u analizirajućem koraku Analizirajući korak predstavlja sledeće aktivnosti:

• Sintezu informacija • Predefinisanje use case dijagrama • Izbor odgovarajuće arhitekture aplikacije rešenja • Kreiranje konceptualnog modela rešenja

Sinteza informacija, znači proces prihvatanja sakupljenih informacija i interpretacija rezultata. Sinteza analizirajućeg koraka Sledeća tabela prikazuje ključne aktivnosti i isporuke analizirajućeg koraka Aktivnosti Isporuke Sinteza sakupljenih informacija

• Informacioni modeli

• Relacije između poslovnog procesa, poslovnog sistema i korisnika

• Proces radnog toka • Sekvence aktivnosti • Ažurirani korisničkih profila • Zahtevi kandidata • Detaljni use case Kreiranje korisničkih scenarija Tekući korisnički scenario

Preformulacija zahteva Kada vršite preformulaciju zahteva pridržavajte se sledećih kriterijuma:

1. Zahtevi moraju biti dobro definisani. 2. Zahtevi moraju biti sažeti 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, omogućava da budete uvereni da je tim bio istrajan u otkrivanju kritičnih zahteva. Korisnički zahtevi – Korisnički zahtevi definiše ne funkcionalni aspekt korisničke interakcije sa rešenjem. Oni vam pomažu da definišete korisnički interfejs i predstavlja očekivanje rešenja u obliku pouzdanosti, raspoloživosti i prihvatljivosti. Uspešno rešenje zadovoljava i organizacione potrebe za tehnologijom i korisnička očekivanja sa primenom tehnologije.

Sistemski zahtevi – Sistemski zahtevi specificiraju male transakcije i njihove faze u sistemu, i pomoću projektnog tima definiše kako novo rešenje da bude u interakciji sa postojećim sistemima. Projektni tim takođe identifikuje kritične zavisnosti sa spoljnim sistemom sa kojim se mora upravljati. Pre razvoja novog rešenja, projektni tim mora razumeti tekuću infrastrukturu u organizaciji.

Operativni zahtevi – Operativni zahtevi opisuju šta rešenje mora isporučiti za maksimiziranje operativnosti sa redukcijom vremena i rizika. Ključni elementi operativnosti su:

• Bezbednost • Raspoloživost i pouzdanost • Upravljivost • Scalabilnost • Podrživost

Poslovni zahtevi – Poslovni zahtevi opisuju organizacione potrebe i iščekivanje rešenja. Definiše se šta rešenje treba da da, poslovne mogućnosti ili da se ispune poslovni zahtevi.

Redefinisanje use case dijagrama

Za vreme faze predviđanja, projektni tim kreira use case dijagram, specificira sve use case-ove visokog nivoa u organizaciji. Svrha ovog use case dijagrama je lista ključnih use case-ova u sistemu, da definiše opseg rešenja i postavi osnovu za koncept rešenja. Kreiranjem koncepta modela dizajna, neophodno je da redefinišete use case-ove sa opsegom rešenja korišćenjem sakupljanje informacija za vreme istraživačkog koraka konceptualnog dizajna. Redefinisanje use case dijagrama, predstavlja sledeće aktivnosti:

• Kreiranje subordinate use case - va • Kreiranje korisničkih scenarija za svaku subordinatu use case-ova • Validacija svakog use case - a i korisničkog scenarija na osnovu

originalnog intervijua, nasuprot druge dokumentacije • Redefinisanje zahteva sa validacijom use case i informacijom korisničkog

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 podređenih use case-ova Kreiranje podređenih use case-ova, vi dajete kritičnu ocenu svakog use case-a u celokupnom use case dijagramu za dati opseg projekta. Onda indetifikujete svaku aktivnost preko use case-a, indetifikujete sve učesnike i relacije između različitih aktivnosti i učesnika.

Izbor arhitekture aplikacije Ključni naglasak u konceptualnom dizajnu je konceptualni model rešenja. Da bi ste kreirali konceptualni model potrebno je da razumete servise koje rešenje mora da omogući.

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

Logičke komponente pristupa podacima Agenti servisa

Sloj podataka

Izvor podataka Servisi

Prezentacioni sloj

Poslovni servisni sloj

Dodatni servisni sloj

Servisi u rešenju

Servis je definisan kao logička aplikaciona jedinica koja uključuje metode implementacije na rad, funkcije ili transformacije. Servisi su udruženi sa akcijama i primenjuje poslovna pravila, manipulacija podacima i omogućuje akcije kao što su dodavanje, pronalaženje, pregled i modifikaciju podataka. Servisima se može pristupiti preko mreže kroz interfejs koji sadrži specifikacije interfejsa. Kupcu nije važno kako je servis primenjen; već mu je važna mogućnost predstavljanja zahtevane akcije. Tipovi servisa

Tipični servisi koje rešenje omogućava su:

• Korisnički servisi – Korisnički servisi su logičke jedinice aplikacije, koji omogućavaju korisnički interfejs u aplikaciji. On upravlja interakcijom između aplikacije i korisnika.

• Poslovni servisi – Poslovni servisi su logičke jedinice aplikacije koje primenjuju poslovna pravila u ispravnim redosledima. Poslovni servis skriva primenu logičkog poslovnog pravila i trasformiše podatke od korisničkog servisa drugim poslovnim servisima i servisima podataka.

• Servisi podataka – Servisi podataka su logičke jedinice aplikacije koji omogućavaju’detalje najnižeg vidljivog nivoa za manipulaciju podacima. Koristite servise podataka za primenu poslovne sheme na smeštanju podataka koristeći aplikaciju. Servisi podataka su iskorišćeni za upravljanje svim vrstama podataka, statičkih, strukturnih i dinamičkih.

• Sistemski servisi – Sistemski servisi su logičke jedinice aplikacije koje omogućavaju funkcionalnost izvan poslovne logike. Zajednički sistemski servisi uključuju:

o Servise bekapa o Servise obrade grešaka o Bezbednosne servise o Servise poruka

Arhitektura aplikacije

Takođe 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 uključuje detaljnu primenu. Arhitekture aplikacija uključuje:

1. Klijent/server arhitektura 2. Slojevita arhitektura 3. Stateless arhitektura 4. Arhitektura keša 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 možete podeliti procesne zahteve radi ispunjenja aktivnosti između dva uređaja. Međutim jedno od ograničenja ove arhitekture je visoka klijentska zavisnost od servera. Ako veza između klijenta i servera je u kvaru, klijent ne može da odradi čak ni osnovne aktivnosti. Ova aplikaciona arhitektura ne bi trebalo da se koristi kada se zahteva mogućnost uklapanja, kao i za bilo koje rešenje koje mora omogućiti veliki broj zahteva.

Slojevita arhitektura – Slojevita arhitektura je razvijena na verzijama klijent/server arhitekturi i sastavljena od hijerahijskih slojeva. Različiti servisi u aplikaciji su jasno pozicionirani u specifičnim slojevima na sličan način tako da mogu komunicirati sa drugim servisima jedino ako je sloj susedan. Sloj enkapsulira servise i zaštićuje jedan servis od drugog; dok istovremeno omogućava jednostavne interfejse za deobu resursa. Prezentacioni, poslovni, servisi podataka i servisi smeštanja podataka su međusobno različiti slojevi u slojnoj arhitekturi. Prednosti slojevite strukture uključuje poboljšan sistem uklapanja i visoku bezbednost. Možete takođe balansirati servisima preko raspoloživih resursa i različitih slojeva. Takođe slojevi omogućavaju primenu bezbednosti sa dobro-definisanim granicama, sa malim negativnim uticajem na komunikaciju između servisa sa sistemom. Međutim ovaj pristup povećava kompleksnost rešenja.

Stateless arhitektura – Stateless arhitektura je verzija klijent/server ili slojevita arhitektura u kojoj svaki klijentski zahtev sadrži sve informacije koje su zahtevane od servera radi razumevanja zahtevnog procesa. Informacije nisu smeštene kod klijenta. Prednosti stateless sistema uključuje:

• Poboljšana preglednost • Pouzdanost • Skalabilnost

Arhitektura keša – Keširanje je sledeči pristup u kome aplikacija omogućuje odgovore za neke klijentske zahteve bez prosleđivanja zahteva drugom uređaju. Primenom ove vrste aplikacione arhitekture, neophodno je da indentifikujete šta može a šta ne da se kešira. Takođe je neophodno definisati način upravljanja životnim vekom elementa u kešu. Zato što keširanje izbegava stalni prenos zahteva i odgovora između klijenata i servera, performanse aplikacije i mreže su velike. Ova arhitektura omogućava visok stepen uklapanja, preko kreiranja lokalnog smešanja za najčešće zahteve sredstava, dok u drugom slučaju biće u redu čekanja na pristup. Međutim keširanje smanjuje efikasnost rešenja.

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, dodajući proxies kroz siste ako je neophodno. Ova arhitektura omogućava da kreirate visoko fleksibilne i uklapajuće aplikacije preko

distribucionih procesiranja i preostalog stateless na serveru. Takođe ova arhitektura je složeno, upravljivo i fleksibilno rešenje.

Optimizacija konceptualnog dizajna

Poslednji korak konceptualnog dizajna je optimizacija. Za vreme optimizacije, vi dizajnirate rešenje uzimajući u obzir koncept rešenja koji će biti u konačnoj aplikaciji.

Optimizacija procesa – Prilikom istraživanja i analiziranja tekućeg poslovnog procesa, vi definišete koje procese ćete uključiti u rešenje i kako će se ovi procesi iskoristiti. Rukovodioci ili vlasnici procesa, korisnici, i projektni tim moraju raditi zajedno na rešenju. Takođe prilikom dizajna morate voditi računa da scenario eliminiše neefikasnost, uska grla i ponavljanje istih informacija. Aktivnosti koje opisuju buduća stanja – Da bi opisali budući status, tim mora da uradi sledeće aktivnosti:

• Da ima viziju budućnosti • Da poboljša postoječu produktivnost • Da Razmotri porebe prema željama • Da uravnoteži posao sa zahtevima korisnika • Da uravnoteži sadržaj sa tehničkom izvodljivošću • Redizajniranje tekućeg procesa za optimalnom podrškom ključnih

proizvodnih aktivnosti i procesa uključujući, poslovne procese koji su redizajnirali i prihvatili eksperti.

• Optimiziranje ulaznih procesa • Integrisanje procesa kad god je to moguće • Eliminisanje neefikasnosti, uskih grla i ponavljanje istih informacija

Redizajniranje procesa iz perspektive korisnika – Da bi se indetifikovali zahtevi iz korisničke perspektive, treba imati na umu sledeće stavke:

• Indentifikovanje neželjenih pojedinih aktivnosti, uskih grla i beznačajnih faza u procesu

• Integrisanje pojedinačnih funkcionalnih informacionih sistema u konsolidovane široke procesne sisteme

• Određivanje minimalnog nivoa performanse koje mora biti dostignuta u samom procesu

• Pokušaj da se dizajniraju procesi koje bi postigli iste rezultate ali sa manje napora

• Smanjivanje praznog hoda sistema zahvaljujući indentifikaciji faza koje bi mogle da se odvijaju istovremeno umesto jedna za drugom.

• Poboljšanje sistema zahvaljujući snadbevanju korisnika sa svim potrebnim informacijama, kao što su povratne informacije o performansama koja omogućava da se problemi odmagh razreše

Ocena redizajniranog procesa

Procena redizajniranog procesa se radi da bi se odredilo da li postoji bilo kakvo nerazumevanje ili nedostatak informacije koje zahtevaju korisnici. Takođe treba potvrditi da nema problema bez obzira na različita gledišta rešenja članova tima. Vrši se i procena troškova i korisnosti od tekućeg rešenja. 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

Pošto se kreira konceptualni dizajn onda se vrši njegova ocena sa uz učešće svih korisnika. Valjanost konceptualnog dizajna rešenja nasuprot korisničkog slučajeva, korisničkog scenarija, poslovnih zahteva, arhitekture, rizika, mogućih resursa i vremena i svih drugih činjenica koje su razvijene.

Razlog za ocenu konceptualnog dizajna – Scenario ocene valjanosti trebalo bi takođe da uključi ocenu rezultata prioritetnih aktivnosti. Neophodna ocena konceptualnog dizajna rešenja je zato što:

1. Smanjuje rizik 2. Pomaže vam da pronađete nestale informacije 3. Pokazuje promenljive poglede i prezentuje rešenje, posebno između

poslova i korisnika 4. Verifikuje opseg aktivnosti 5. Pomaže pri prioritetizaciji 6. Omogućava baznu liniju za nastavljanje logičkog dizajna

Koraci u ocenjivanju konceptualnog dizajna – Proces za ocenjivanje, testiranje i redizajniranje može uključiti sledeće korake:

1. Redizajn posla 2. Kreiranje seta scenarija za podržavanje posla 3. Izbor tehnika za ocenjivanje sistema 4. Crtanje korisničkoh interfejsa 5. Dobijanje korisničke 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 slažu sa pojedinim akcijama i događajima. Igranje uloga (simulacija) – Skup izabranih korisnika rukovode sa više scenarija kako bi ocenili procese, indetifikovali područja za mogućee ispravke. Aktivnost pomaže timu da izvrši selekciju jednog od scenarija koji treba da se detaljnije dizajnira. Prototip – Obezbeđuje detalje procesa, tok procesa, organizacione implikacije i tehnološke mogućnosti. Prototip je efikasan način za komuniciranje sa združenim i sintetizovanim zahtevima korisnika. Može da se kreira ili u elektronskoj ili u papirnoj varijanti. Prototipovi treba da se pregledaju i procene od strane tima i takođe treba da se omogući menadžmentu da donese odluku o dizaknu finalnog procesa.

modul - Dizajniranje Logički dizajn

Logički dizajn je definisan kao proces opisivanja rešenja u organizacijama, strukture i interakcije delova sa stanovišta projektnog tima. Logički dizajn obrađuje sledeće:

1. Definiše sastavne delove rešenja 2. Omogućava infrastrukturi da sadrši sve delove rešenja zajedno 3. Ilustruje kako je rešenje ukomponovano sa korisnicima i drugim

rešenjima.

Kada se kreira logički dizajn tim uzima u obzir sve poslovne, korisničke, sistemske i operativne zahteve i određuje potrebu za: bezbednošću, praćenjem, logovanjem, skalabilnosti, upravljanjeм porukama, obradом grešaka, licenciranjem, globalizacijom, arhitekturom aplikacije i integracijом sa drugim sistemima. Logički dizajn može početi i pre nego što se završi konceptualni dizajn. Odluka o početku logičkog dizajna se donosi od slučaja do slučaja i u zavisnosti od projekta i od projektnog tima. Kada projektni tim pređe sa konceptualnog na logički dizajn menja se i perspektiva projekta. Za vreme konceptualnog dizajna, projektni tim definiše poslovni problem baziran na sakupljenim podacima iz poslovnog i

korisničkog okruženja, dok kod logičkog dizajna daje se rešenje iz sopstevog pogleda. Dobar logički dizajn zavisi od dobrog konceptualnom dizajna. Ako projektni tim kreira dobar logički dizajn, onda bi trebalo da bude lako svakom novom članu tima da sagleda dizajn, odredi važne delove rešenja i razume kako delovi rade, zajedno da bi rešili poslovni problem. Često se dešava da rad na logičkom dizajnu se preklapa sa radom na fizičkom dizajnu. Aktivnosti logičkog dizajna

Ako bi se vršila detaljna analiza, logički dizajni bi se mogao razbiti na sledeće aktivnosti:

1. Analiza logičkog dizajna u kojoj tim predstavlja sledeće aktivnosti: 1.1. Prečišćavanje liste alata i tehnologija za upotrebu 1.2. Identifikacija poslovnih objekata i servisa 1.3. Identifikacija važnih atributa i ključnih relacija

2. Optimizacija logičkog dizajna sa sledećim aktivnostima: 2.1. Prečišćavanje logičkog dizajna 2.2. Vrednovanje logičkog dizajna

Za vreme logičkog dizajna mogu se pojaviti novi zahtevi ili da se otkriju zahtevi koje ste prethodno predvideli. Tog trenutka tim mora da se obrati kupcu da bi verifikovao te zahteve i da kupac sam odluči šta će raditi sa tim zahtevima. U zavisnosti od kupčevog odgovora, opseg projekta se može promeniti. Ako se menja opseg projekta, onda se vrši ispravka dokumentacije i modela, tako da se te izmene uzmu u obzir. Rezultati logičkog dizajna

Rezultati logičkog dizajna su procesi:

1. Logički objektni model 2. Preliminarni dizajn korisničkog interfejsa 3. Logički model podataka

Ovi rezultati logičkog dizajna služe kao osnova za fizički dizajn. Logički dizaj može biti opisan sledećim rečima:

• Logički dizajn je nezavistan od fizičke primene. Prvenstveni cilj logičkog dizajna je šta rešenje mora da uradi.

• Logički dizajn nije tehnološko rešenje. Ono pomaže projektnom timu da specificira poslovne potrebe i mora biti podržan preko rešenja i tehnoloških ograničenja i mogućnosti.

• Logički model nije optimizovan za izabrani fizički model. On pomaže projektnom timu da identifikuje odgovarajuće tehnologije koje mogu biti korišćenje za dobijanje rešenja.

Prednosti logičkog dizajna

Kreiranje logičkog dizajna ima nekoliko prednosti kao što su: pomoć pri kreiranju jake veze između članova tima koji imaju tehničko znanje i one koji nemaju.

1. Logički dizajn pomaže upravljanju kompleksnosti projekta preko definisanja strukture rešenja, opisujući delove rešenja i kako delovi uzajamno deluju jedan na drugi.

2. Logički dizajn daje i podršku zahtevima konceptualnog dizajna preko verifikacije dizajna koji će rešiti poslovni problem. Takođe pomaže timu da otkrije greške i postojanje u konceptualnom dizajnu, eliminišući višak u zahtevima i indetifikaciju potencijalnog ponovnog korišćenja u scenariju.

3. Logički dizajn služi kao kontaktna tačka za organizovanje kooperacije između više sistema u poslovanju i omogućava složeni pogled na projekat.

4. Koristi se kao početna tačka fizičkog dizajna. Odgovornosti timskih uloga za vreme logičkog dizajna

Za vreme logičkog dizajna, svaki član tima ima različiti set odgovornosti. Na primer tim menadžment programa je odgovoran za razvoj funkcionalne specifikacije, ostvarivanje komunikacije i vremenskim rasporedom održavanja projekta i izveštavanje o statusu projekta. Uloge tima Uloga Primarna aktivnost Sekundarna aktivnost Menadžment proizvoda Obezbeđuje dizajn za

potrebe posla i kupca Upravlja kupčevim očekivanjima

Menadžment programa Uzima prvenstvenu odgovornost za isporuku logičkog dizajna

Definiše projektni plan, uključujući resurse, raspored i rizik

Razvoj Identifikuje servise i pridružene objekte

Služi kao tehnološki konsultant za validaciju i tehnologiju prototipa

Testiranje Validacija logičkog dizajn modela nasuprot konceptualnog dizajna

Definisanje preliminarnog plana testiranja

Iskusni korisnik Definisanje ciljeva korisničkih performansi i predloženog rešenja

Definisanje preliminarnog plana za obrazovanje korisnika

Menadžment realizacije Validacija izvodljivosti primenljivog rešenja

Definisanje infrastrukture i rešenja distribucije

Kreiranje logičkog dizajn modela

Za vreme analize logičkog dizajna tim razgrađuje problem i rešava ga preko manjih jedinica nazvanih modula. Modul je logička jedinica iskorišćena kao abstraktni pojam za use case i scenarija koja se kreiraju u konceptualnom dizajnu. Za svaki modul, tim identifikuje objekte, servise, atribute i relacije. Redefinisanje liste tehnologija u logičkom dizajnu

Tokom logičkog dizajna tim nadalje redefiniše listu tehnologija koje su u prethodnoj fazi već bile razmatrane, i dodaju se dodatne tehnologije na listu. Tokom vrednovanja kandidatske tehnologije, tim uzima u obzir poslovna razmatranja kao i razmatranje arhitekture preduzeća. Poslovna razmatranja

Neka od poslovnih razmatranja uključuje.

• Izvodljivost – Definiše da li će aktuelna tehnologija zadovoljiti poslovne potrebe

• Trošak proizvoda – Razumevanje kompletne liste troškova, koja uključuje razvoj, uslugu, licencu za prodaju i troškove nadogradnje.

• Iskustvo – Razumevanje da li korisnici imaju iskustva sa različitim tehnologijama koje imaju veliki udeo u rešenju.

• Korisnost investicije – Svaki investitor mora da odgovari na pitanje korisnosti same investicije. Ne treba se izabrati tehnologija samo zato što je nova.

• Rok – Rok za proizvod je prihvatljiv na tržištu, ako je razuman, stabilan i ima poznate moguće resurse.

• Podrživost – Kada izaberete tehnologiju, važno je da možete realizovati podršku za sve vreme kreiranja rešenja.

Drugi faktori koji se razmatraju prilikom izbora tehnologije:

1. Lak za razvoj 2. Prednosti poređenja 3. Potrebno vreme za tržište 4. Industrijsko predviđanje proizvoda 5. Mogućnost integracije sa postojećim sistemom

Razmatranje arhitekture preduzeća - Arhitektura preduzeća opisuje tekuće stanje i planove budućeg stanja. Rešenje mora uzeti u obzir ograničenja u arhitekturi preduzeća. Izbor tehnologije mora biti takav da omogućava rad i sa drugim sistemima u organizaciji.

Razmatranje tehnologije - Bezbednost – Vrednovanje razmatranja bezbednosti za novo rešenje u obliku autorizacija (autentifikacija), kontroli pristupa, enkripcije (šifrovanja) i praćenja. Autentifikacija i autorizacija su dva odvojena koraka u procesu dozvoljavanja pristupa korisnika resursima. Autorizacija definiše da li osoba ima pravo na korišćenje i dopušta autorizovanom korisniku dozvoljene akcije sa sistemom. Bezbednosni servis takođe omogućava šifrovanje za zaštitu informacija u toku transporta ili smeštanja. Praćenje, kreira trajan zapis akcija pojedinca koje su aktivnosti rađene ili ko pokušava da radi sa sistemom. Standardne servisne interakcije - Kada tim izabere standardni interakcijski servis, potrebno je oceniti glavnu integralnu platformu nasuprot snazi i performansama. Pristup podacima - Kada izabirate servis pristupa podacima, razmotrite performanse, standardizaciju, buduće pravce, upravljanje pristupa podacima i različite podrške smeštenju podataka. Smeštanje podataka - Sistemi smeštanja podataka su iskorišćeni za smeštanje svih poslovnih informacija, kao što su zaposleni, kompanija, informacije o kupcima. Sistemski servisi - Projektni tim trebalo bi da vrednuje i sistemske servise koji se zahtevaju i da se identifikuju tehnologije koje će omogućiti te servise. Razvojni alati - Razvojni alati omogućavaju razvoj različitih delova aplikacije, kao što su servisi i komponente. Operativni sistemi – Kada se izabere operativni sistem, zabeležiti da servisi, koji su omogućeni preko operativnog sistema, mogu značajno reducirati kod aplikacije. Identifikacija poslovnih objekata

Objekti su definisani kao ljudi ili stvari koji opisuju korisnički scenario. Forme objekata su osnova za servise, atribute i relacije. Efektivni metod za identifikaciju objekata je razmatranje korisničkog scenarija za use case i identifikaciju imenica. Kada se razmatraju imenice i pridodaju glagoli možete identifikovati objekte i pridružene servise. Rečenica sa subjektom, glagolom i direktnim objektom, pokazuje dva moguća poslovna objekta – subjekat i direktan objekat. Identifikacija atributa

Atributi objekta su definisani kao vrednosti podataka koje objekat sadrži. Atributi su poznati kao osobine. Identifikacija atributa za objekat, vraća korisnički

scenario. Traženjem reči ili fraza podrobnije definiše objekat. Za identifikaciju atributa objekta projektni tim bi trebalo da razmotri svaki poslovni objekat u pokušaju da odgovori na sledeća pitanja:

1. Kako je uopšteno opisan objekat i koji je on deo sistema? 2. Kako je objekat opisan u kontekstu odgovornosti rešenja? 3. Koje informacije objekat sadrži? 4. Koje informacije objekat treba da održava tokom vremena? 5. Koje je stanje pod kojim objekat može postojati?

Identifikacija servisa

Servis je specifična osobina koju poslovna komponenta mora da predstavi. Ona se odnosi na operacije, funkcije ili transformacije koje mogu biti primenjene ili da budu primenjene od objekta. Koristite servise za primenu poslovnih pravila, manipulaciju podataka i pristup informacijama. Identifikacija servisa za objekat, predstavlja korisnički scenario nasuprot identifikaciji akcija koje objekti moraju da urade. Mora se takođe napraviti analiza šta je objekat namerio da uradi i vrstu podataka koje objekat treba da održi. Identifikacija relacija

Relacije ilustruju način na koji su objekti povezani jedni sa drugim. UML definiše četiri tipa relacija: zavisnost, uopštenost, pridruženost i realizacija. Zavisnost – Relacija između dva objekta u kojem promena u jednom objektu (nezavisnom) može uticati na osobinu ili servis drugog objekta (zavistan). Koristiti zavisnost kada želite da pokažete da jedan objekat koristi drugi.

Zavisnost

Uopštenost – Relacija između opšte stvari (nazvanog roditelj) i specijalizovanog ili specifične stvari (nazvanog dete).

Rukovodilac Knjigovodja Prevodilac

Zaposlen

Pridruženost – Strukturna relacija pridruženosti opisuje vezu između objekata. Agregacija je specijalni tip pridruživanja koja predstavlja relaciju između celine i delova.

Kontrola Rukovodilac

Periodična kontrola

Realizacija – Relacija između klasa u kojoj jedna apstraktna klasa specificira rad sa drugom klasom.

modul – Dizajniranje Dokumentovani izlazi logičkog dizajna

Tokom logičkog dizajna, tim kreira nekoliko izlaza koji će pomoći tokom razvoja rešenja. Ti izlazi uključuju logički objektni model, logički model podataka i preliminarni korisnički interfejs (UI). Postoje nekoliko alata za dokumentaciju i dijagrame ovih izlaza. Relacioni model - Dve značajne tehnike za objašnjenje relacija u modelu su karta saradnje odgovornih klasa (CRC) i sekvencioni dijagram.

Karta saradnje odgovornih klasa - se fokusira na odgovornosti visokog nivoa umesto detaljnih metoda i atributa. Projektni tim koristi (CRC) kartu kao iznenadnu ideju u opisu odgovornosti klasa. Svrha identifikovanja odgovornosti klasa je da se identifikuju servisi. CRC karta pokazuje sve klase sa kojima klasa mora da je u interakciji i identifikuje relaciju između njih.

Sekvencioni dijagram – sekvencioni dijagram pokazuje učesnike i objekte koji uzimaju učešće u interakciji sa listom hronoloških događaja koji se generišu. Vertikalna linija dela dijagrama predstavlja objektno vreme bitisanja. Strelica između vremena bitisanja dva objekta predstavlja poruku, koji oblik komunikacije postoji između dva objekta koja komuniciraju kada se dešavaju aktivnosti. Prijem poruke zahteva, razmatra se kao zahtev događaja. Redosled u kome ove poruke se pojavljuju je od vrha ka dnu strane.

Kreiranje logičkog objektnog modela

Glavni izlaz iz logičkog dizajna je dizajn rešenja u logičkom objektnom modelu. Logički objektni model je kreiran iz objekata, servisa, atributa, relacija, koje su ranije kreirane u procesu logičkog dizajna. Kada se kreira logički objekat modela, važno je razmotriti sve poslovne i korisničke zahteve koje su primenljivi u vašem scenariju, kao što su bezbednost, globalizacija, lokalizacija, praćenje i logovanje, obrada grešaka, integracija sa postojećim sistemom i menadžment stanja. Takođe je važno razmotriti i sva poslovna ograničenja kada kreirate logički objektni model za dizajn rešenja. Da bi ste predstavili logički dizajn možete uzeti logički model objekta ili logički model podataka. Međutim projektni tim možda želi da kreira oba modela za predstavljanje logičkog dizajna na različite načine. Oba modela bi mogla biti neophodna ako jedan model predstavlja deo dizajna koji je mnogo jasniji od onog drugog. On predstavlja srednju stanicu prirodnog progresa od konceptualnog do fizičkog dizajna.

Identifikacija entiteta – Entiteti mogu mogu biti definisani kao bilo koja osoba, mesto, deo, ili koncept definisanja podataka ili podaci koji treba da se sakupe i sačuvaju. Atribut je karakteristika koja bliže određuje osobine entiteta. Entitet može imati veći broj atributa.

Definisanje tabela – Objekti koji su identifikovani u analizi objektnog dizajna su jaki kandidati za tabele i mogu se transformisati u tabele za vreme fizičkog dizajna. Tabele su sredstvo ovih objekata gde čuvaju svoje informacije.

Definisanje kolona – Atributi objektne forme pridodati su kolonama odgovarajućih tabela.

Definisanje relacija – Posle identifikacije tabela i njihovih kolona, neophodno je identifikovati bilo koji spoj između tabela. Kao spoj predstavljena je relacija između objekata.

Kardinalnost - je identifikacija osobine relacije. Omogućava vam da specificirate broj navoda entiteta koji su mogući na svakoj strani relacije.

Dizajn preliminarnog korisničkog interfejsa

Korišćenjem objekata, servisa, atributa i relacija koji su identifikovani za vreme koraka analize logičkog dizajna, tim može doneti odluku da kreira i preliminarni korisnički interfejs i da dizajnira bazu podataka. Kreiranje preliminarnog korisničkog interfejsa i baze podataka, omogućeno je projektnom timu da opiše tok procesa krajnjem iskusnom korisniku kao i kupcu. Lista objekata i servisa daju timu ideju o vrsti funkcionalnosti koju korisnik očekuje. Tim može koristiti ove informacije za dizajn korisničkog interfejsa i njegovih elemenata kao što su dugmad, tekst polja i stavke menija. Optimizacija logičkog dizajna Posle faze analiziranja, tim prelazi na optimizirajući korak. Na ovom koraku pravi izazov za tim je prečišćeni i optimizovani dizajn u poređenju sa korisničkim scenariom i zahtevima.

Prečišćeni objekti

Za vreme koraka analize logičkog dizajna, projektni tim identifikuje objekte. Svi objekti mogu da ne budu potpuno relevantni za rešenje. Kada tim prečisti objekte dobijaju se relevantni objekti. Pravila – Kada redefiniše objekte, uzmite u obzir sledeće:

1. Ako dva objekta izražavaju istu informaciju ili kontrolu iste aktivnosti, vi možete ih kombinovati da dobijete kombinovani objekat sa imenom koji je više opisan.

2. Objekat bi trebao da bude specifičan. Neki objektni kandidati bi mogli da se kreiraju vrednovanjem dodatnih informacija iz scenarija. Ovi objekti

nisu obavezno netačni, ali je nephodno da budu više shatljivi ili realni. U dodatku možete da želite da predstavite ove objekte za definisanje kao i njihovo mesto u opsegu projekta.

3. Ako je atribut neophodan za postojanje nezavisnosti u rešenju, pridodajte ga objektu.

4. Možda je potrebno da imate novi objekat za kontrolu ili koordinaciju seta servisa.

5. Možete takođe koristiti servise za pregled liste objekata. Za svaki servis, identifikujte objekat na koji servis deluje.

Verifikacija postojećeg logičkog objektnog modela

Verifikaciju postojećeg logičkog objektnog modela možete ostvariti verifikacijom pojedinih objekata i prolaskom kroz korisnički scenario. Najvažnija aktivnost u optimizaciji i finalizaciji logičkog dizajna je vrednovanje logičkog objektnog modela, nasuprot postojećeg seta zahteva. Za svaki zahtev koji je definisan, logički dizaj stvara dokument. Ako postoje zahtevi koji nisu dokumentovani, potrebno je da modifikujete vaš logički dizajn tako da ih pridodate nedostajućim zahtevima. Posle završetka svih ovih aktivnosti, spremni ste da pređete u proces fizičkog dizajna.

Verifikacija pojedinih objekata – Verifikacijom pojedinih objekata, vi identifikujete objektne ulaze i izlaze i sposobnosti ili funkcionalnosti koje objekat mora omogućiti. Za bilo koji dati ulaz, vi biste trebalo tačno predstaviti izlaz i osobine i verifikovati nezavisne delove objekta.

Uspostavljanje kontrole u logičkom dizajnu

Ispitivanjem interakcija objekata za različite scenarije, prikazuju se aktivnosti neophodne da budu predstavljene u specifičnim delovima. Jedan mogući način je predstavljanje objektne interakcije korišćenjem dijagrama stanja. Identifikaciju kontrole toka, omogućava vam interakcija sekvence objekata. Kontrola logičkog dizajna:

• Garantovanje integriteta transakcije scenarija • Koordiniranje servisa kroz veći broj objekata • Identifikovanje međuzavisnosti objekata

Tipovi kontrole – Kontrole mogu biti sinhrone i asinhrone. Sinhrone kontrole odnose se na situacije u kojima objektni servisi su pozvani i pozvani objekti čekaju na kontrolu koja će se vratiti. U sinhronom scenariju, kontrola je prenenešena od objekta koji je pozvao ka pozvanom objektu i operacija se izvršava odmah. Objekat koji zove je suspendovan dok pozvani objekat ne kompletira aktivnost. Posle kompletiranje operacije, kontrola je vraćena objektu koji je zove.

Kod asinhrovane kontrole, klijent objekta može proslediti zahtev i onda da nastavi predstavljati druge aktivnosti. Servis će procesovati zahtev i zabeležiti klijenta kada je proces iskompletiran.