Poslovni informacioni sistemi

Download Report

Transcript Poslovni informacioni sistemi

MSF okvir/model procesa






Framework - podrška metodologijama
MSF discipline
MSF timski model
Kako organizovati projektne timove
Kako upravljati kompromisima (tradeoffs)
Faze u MSF modelu procesa
17.7.2015
MSF
1
Microsoft Solution Framework - MSF
• Uputstva za tehnološke, procese, projekte i radne timove, uključuje
najbolju praksu MS
• Pristup je baziran na definisanim principima, modelima, disciplinama,
konceptima, uputstvima i potvrđenim praksama
• Obezbeđuje discipline upravljanja projektima, rizikom i procesima
(operativnom spremnosti)
• Namenjen za uspešno upravljanje svim elementima projekata (ljudi, procesi,
alati) za razvoj poslovnih tehničkih rešenja
• Obezbeđuje dva pristupa životnom ciklusu projekta: model vodopada i
spiralni model.
– Model vodopada –svi zadaci u jednoj fazi se moraju završiti pre nego
što se pređe na sledeću fazu.
– Spiralni model – model se bazira na kontinualnoj potrebi za
usavršavanjem zahteva.
– Ovaj model je pogodan za brzi razvoj aplikacija (Rapid Application
Development – RAD).
17.7.2015
MSF
2
Kako radi MSF model procesa



MSF procesni model kombinuje najbolje principe modela vodopada i spiralnog
modela.
Spiralnost se definiše i u okviru samog projekta, a i u okviru kritičnih tačaka
(milestones).
Microsoft-ov primer poboljšavanja kvaliteta verzija istog softverskog
proizvoda:
Functionality
Version 3
Version 2
Version 1
Time
17.7.2015
MSF
3
• Framework
kao kompas,
usmerava kretanje i
daje upravljačke
smernice
17.7.2015
1st Avenue
Orange Street
• Metodologija
daje tačne
smernice za
poznato odredište
Plum Street
MSF podrška metodologijama
2nd Avenue
3rd Avenue
4th Avenue
N
Smith River
W
E
S
MSF
MSF
4
Zašto izabrati MSF?
Statistički pokazatelji:
 16 % uspešnih projekata
 31% neuspelih projekata
 53% projekata koji su uspeli, ali su probili
rokove ili su isporučeni sa lošijom
funkcionalnošću i dr.
 Sa MSF-om zabeležen je rast od 20%
uspešnih projekata sa svakodnevnom
tendencijom porasta.
17.7.2015
MSF
5
Zašto izabrati MSF?
Propali
31%
53%
Uspešni
Promenjeni
•Rokovi
•resursi
•funkcionalnosti
16%
(Standish Grupa)
17.7.2015
MSF
6
MSF discipline
1.Upravljanje rizicima (Risk management):
– identifikovanje rizika (brainstorming) Knowledge
Skills
– analiza rizika (identifikacija, procena
Abilities
verovatnoće događaja rizika)
– procena rizika (procena uticaja na
ishod projekta, načun ublažavanja)
Evaluate
– praćenje rizika
– kontrola rizika
– analiza iskustava
Define
Assess
Change
2.Spremnost (Readiness management) – kako podizati nivo
spremnosti tima (motivacija, edukacija, zainteresovanost,
iskustvo i dr.):
– Definisanje scenarija - analiza kompetencija neophodnih za uspešno
planiranje, kreiranje i upravljanje rešenjem.
– Procena – analiza kompetencija u odnosu na različite uloge u poslu.
– Upravljanje promenama – poboljšanje veština kroz obuku i praćenje
napredovanja.
– Ocenjivanje – MSF tim određuje da li su planovi obuke bili efektivni i da li
je stečeno znanje uspešno implementirano na poslu.
17.7.2015
MSF
7
MSF discipline
3.
Upravljanje projektima (Project management):
Mnoge funkcije projekt menadžera preuzima uloga
program menadžera.
Definiše i upravlja ciljem i obimom projekta.
Integriše planiranje i upravljanje promenama.
Priprema budžet i upravlja troškovima.
Priprema i prati dinamički plan projekta.
Osigurava alokaciju resursa za projekat.
Olakšava timsku i spoljnu komunikaciju.
Olakšava proces upravljanja rizicima.
Dokumentuje i nadgleda proces upravljanja kvalitetom
tima.
17.7.2015
MSF
8
MSF model tima
• Specifira 6 različitih uloga
• Ističe važnost uloga, odgovornosti i ciljeva članova
tima
• Omogućava fleksibilnost, brže prilagođavanje
ciljevima projekta, veličini tima i veštinama članova
tima
• Ne postoji uloga projekt menadžera, ni rigidna
hijerarhijska struktura u procesu odlučivanja.
• Sve uloge u timu ispunjavaju određeni cilj
• Glavne odluke se donose konsenzusom tima
• Ukoliko se konsenzus ne može postići, program
menadžer donosi konačnu odluku
17.7.2015
MSF
9
Kako organizovati projektne timove
Vodi početne razgovore sa
naručiocima posla, prikuplja
zahteve, dogovara šta će se
raditi, uspostavlja rokove,
ograničenja.
Poznaje obe strane
procesa, proizvodnje i
upotrebe. Unosi podatke,
analizira performanse,
koriguje ekrane kako bi
rešenje bilo što
upotrebljivije...
Upravljanje
proizvodom
Upravljanje
programom
Korisničko
iskustvo
Pravi Help, implementira i
instalira sistem.
Odgovoran je za
rukovanje i održavanje
sistema.
17.7.2015
Upravljanje
razvijenom
verzijom
Sastavlja funkcionalnu
specifikaciju (master project
plan i master project
schedule). Odgovoran je za
razvoj i isporuku rešenja.
Odgovorni za razvoj
tehnološkog rešenja
prema specifikacijama
dobijenih od strane
program menadžera.
Razvoj
Testiranje
MSF
Jedna od važnijih rola. Pronalazi bug-ove
(npr. istovremeno koristi 100 korisnika), proba
sve module kako bi finalno rešenje blo što
stabilnije, upoređuje funkcionalnost programa
sa ciljevima i vizijom projekta.
10
Kako upravljati kompromisima (tradeoffs)
• Da bi uspešno definisali cilj i
upravljali projektom, potrebno je:
–identifikovati ograničenja
projekta
–upravljati kompromisima Resursi
–uspostaviti kontrolu
Raspored
promena
–pratiti napredak projekta.
Fiksirani
Odabrani
Prilagodljivi
Funkcionalnost
b) Tradeoff matrix
Funkcionalnost
a) Tradeoff triangle
17.7.2015
 U projektima postoji jasan odnos između resursa,
rasporeda (dinamičkog plana) i funkcionalnosti
projekta.
 S obzirom da je skoro nemoguće ostvariti
istovremeno sve ciljeve, neophodno je upravljati
MSF
11
kompromisima.
Faze u MSF procesnom modelu
Deployment
Complete
5
Release Readiness
Approved
4
1
Vision/Scope
Approved
MSF
3
2
Project Plans
Approved
Scope Complete
17.7.2015
MSF
12
Definisanje vizije budućeg rešenja
(envisioning the solution)
http://www.microsoft.com/msf
 Faza
Envisioning
 Kreiranje dokumenta Vision/Scope Document
 Kreiranje dokumenta Project Structure Document
 Analiziranje rizika
17.7.2015
MSF
13
Namena faze definisanja vizije (Envisioning)
• Identifikovati projektne ciljeve i ograničenja:
– inicijalne rizike, zahteve, uska grla, budžetska sredstva ...
– rezultate studije o izvodljivosti projekta
Uvođenje
kompletirano
Ključni tim organizovan
Vision/Scope Baseline
Vizija/Obim
odobren
• Definisati obim projekta (granice projekta, šta nije uključeno u
projekat ...)
• Proceniti neophodne resurse (br. ljudi, hardverske potencijale
i dr)
• Identifikovati dinamički plan projekta i odrediti tačku
završetka projekta.
17.7.2015
14
MSF
Uloge i odgovornosti članova tima
Odgovoran za odnose sa klijentima i
postavljanje liste zahteva
Osigurava kreiranje vision/scope
Uspostavlja ciljeve
projektovanja (klijent/server,
Analiziraju se performanse
rešenja i podrška
korisnicima
Razmatranje rešenja za
ispunjavanje potreba
korisnika
17.7.2015
Uspostavlja infrastrukturu
projekta
Upravljanje
programom
Korisničko
iskustvo
Uloga sistem administratora
Kako će se rešenje postaviti
Identifikuje zahteve uvođenja
rešenja
Određuje kako i kada će biti
uvedeno.
višeslojna arhitektura, pocket PC
klijenti, web rešenje B2B i dr.)
Upravljanje
proizvodom
Upravljanje
objavljivanjem
rešenja
Razvoj
Testiranje
Obezbeđuje feedback na kvalitet
ciljeva
MSF
Predlaže akcije kako
bi se osigurao
kvalitet
Odgovara na pitanje
da li je to izvodljivo
Obezbeđuje tehnički
feedback
Pomaže u proceni
izvodljivosti
15
Kako formirati projektni tim
• Definisati:
– Znanje
– Veštine
– Nivo performansi (ispunjavanje rokova, dostizanje
kvaliteta u zadatim rokovima)
– Raspoloživost članova tima
– Budžet projekta
– Bezbednosna provera članova tima
17.7.2015
MSF
16
•
•
•
•
•
Izlazna dokumenta faze Envisioning
Vision/scope dokument – opisuje ciljeve projekta i ograničenja (zahtevi
koji će se ispuniti, funkcionalnosti i inicijalni dinamički plan)
Project structure dokument – org. struktura projekta, proces upravljanja
projektom, uloge i odgovornosti članova tima.(AWC)
Risk assessment dokument – inicijalna identifikacija, analiza rizika i
upravljanje rizicima.
Interna dokumenta
– Prilozi\AWC - Actors Catalog.xls
– Prilozi\AWC - Business Rules Catalog.xls
– Rečnik termina – rečnik od end-user-a, npr. šta je konto.
– Candidate technologies (npr., SQL Server, Oracle, Access ...)
– Coding guidelines (Visual Studio, XML, ...)
Mogu se takođe uključiti i:
– Inicijalna lista testiranih funkcionalnosti
– Prilozi\AWC - Requirements - Chapter 3.xls
– Preliminarna arhitektura
– GUI storyboard
17.7.2015
MSF
17
Kreiranje Vision/Scope dokumenta
•
•
•
•
•
•
•
•
Šta je Vision/Scope dokument?
Kako se kreira Problem Statement?
Kako se kreira Vision Statement?
Kako se kreiraju User Profiles?
Kako se definišu granice (scope) projekta?
Kako se kreira Solution Concept?
Kako se identifikuju Project Goals?
Kako se vrednuje Vision/Scope dokument?
17.7.2015
MSF
18
Šta je Vision/Scope dokument?
•
•
Prvi zvaničan dogovor između svih učesnika u projektu.
Vodi i usmerava tim do postizanja određenih poslovnih
ciljeva.
• Sadrži:
 Ciljeve i ograničenja poslovnog rešenja:
–
–
Identifikacija problema – prepoznavanje problema koji moraju da se
reše.
Definisanje vizije – uvođenje i održavanje integralnog rešenja.
 Korisničke profile
 Obim projekta – npr., obuhvatiće kadrove, proizvodnju, neće
marketing i sl.
 Koncept rešenja – npr., pravi se DOT.NET tehnologijom, SQL
Serverom ...
 Ciljeve projekta:


Poslovne ciljeve – npr. izveštaj za menadžment svakog dana u 5.00,
svaki menadžer dobije listu dugovanja i sl.
Projektne ciljeve – npr., realizacija pilot projekta rešenja PIS
 Kritične faktore uspeha
 Inicijalni
dinamički plan aktivnosti
17.7.2015
MSF
19
Kako se identifikuje problem?
• Identifikacija problema (Problem statement)
– narativni prikaz poslovnih očekivanja
– razumevanje poslovnih problema određuje dizajn rešenja
– podvlači poslovne probleme koje tim mora da reši
Primeri:
– Treba da povećamo broj online registracija tako što ćemo
napraviti sopstveni Web sajt sa kojim će se lakše
pretraživati.
– Telefonski operateri ne mogu da rukuju sa velikim brojem
poziva zbog vremena koje im je neophodno za navigaciju sa
tekućom aplikacijom.
– Organizacija treba da eliminiše tekuće troškove koji prate
ranije verzije hardversko-softverskih rešenja
– Korisnici zahtevaju jasne instrukcije od rešenja PIS za
otklanjanje grešaka kada se dogode
17.7.2015
MSF
20
Kako se definiše vizija (Vision Statement)?
• Kratak, jasan i motivišući iskaz zajedničke vizije rešenja
PIS, koji omogućava rad tima sa konsenzusom
• Dobra vizija treba da ima sledeće karakteristike:
– Specifična – usredsređena na poslovni problem
– Merljiva – da projektni tim može odrediti uspešnost projekta
– Dostižna – sa datim resursima vremena, budžeta i veština
tima
– Relevantna – usredsređena na određeni poslovni problem
– Vremenski određena – sa jasnim očekivanim vremenom
isporuke
Primer:
Do kraja godine, postaćemo najproduktivnija proizvodna
kompanija u industriji povećanjem naše online prodaje
17.7.2015
MSF
21
Kako se kreiraju korisnički profili?
• Shvatiti ko su i identifikovati korisnike za koje se razvija
rešenje
• Kada se identifikuju korisnici treba razmotriti i odrediti:
– Ciljeve –lista očekivanja korisnika u interakciji sa
proizvodom
– Ograničenja –na sposobnost korisnika da koristi rešenje
– Podrška – iskustva korisnika sa sličnim proizvodima
– Globalni korisnici –različite kulture i zahtevi za lokalizaciju
– Tok informacija između korisnika – tipovi komunikacija,
njihov značaj i obim podataka
– Funkcije korisnika – opisati zadatke koje korisnik izvršava
– Organizaciona komunikacija – opisati ograničenja
hijerarhijske strukture na komuniciju korisnika
– Politike donošenja odluka – koje direktno utiču na
efektivnost implementacije rešenja
– Dodatni faktori – raspoloživost resursa na korisničkim
lokacijama, nekompatibilni protokoli, mrežni OS i dr
17.7.2015
MSF
22
Kako definisati obim projekta (Scope)?
• Opisati granice PIS, šta će biti, a šta neće biti uključeno u projekat.
• Granice PIS odrediti na osnovu vizije i zahtevanih funkcionalnosti.
• Definisati i prečistiti zahteve koje projekat mora da ispuni.
Primer preliminarnog zahteva: Sistem mora da podrži lokalizaciju za
krajnje korisnike
Primer prečišćenog zahteva: Sistem mora da ima procedure za
globalizaciju, lokalizaciju i dostupnost.
• Navesti koje funkcionalnosti će zadovoljiti trenutno rešenje, a koje
sledeća verzija
• Odrediti korisničke pretpostavke i ograničenja projekta, koje znatno utiču
na ciljeve projekta, na primer:
– Koristiti Microsoft .NET Framework za razvoj rešenja
– Anfažovati dva razvojna tima
– Obezbediti OLAP i OLTP sisteme itd.
– Ograničenja: budžet, tekuće karakteristike PIS, arhitektura RM, OS,
znanja korisnika.
17.7.2015
MSF
23
Use case dijagram
na bazi
intervjua
Granice sistema
17.7.2015
MSF
24
Kako kreirati konceptualno rešenje (Solution Concept)?
• Konceptualno rešenje - namera naćina realizacije zahteva projekta
• Uključuje konceptualni model arhitekture hw/sw rešenja PIS:
– Primer 1: za e-commerc Web sajt, odlučiti da li raditi samostalno,
angažovati drugu kuću, ili nabaviti gotovo rešenje
– Primer 2: gde hostovati web sajt: na lokalnim serverima ili koristiti usluge
provajdera?
• Nakon procene opcije, za konceptno rešenje izabrati onu koja najbolje
odgovara potrebama, resursima i vremenskim okvirima
• Konceptualno rešenje uključuje sledeće elemente:
– Faktore uspešnosti projekta i kriterijume prihvatljivosti – uključuju
zahteve koji moraju biti zadovoljeni pre nego što se krene u realizaciju
rešenja
– Inicijalni pristup razvoju i isporuci rešenja - scenariji načina
implementacije, broj korisnika i lista faktora funkiconalnosti novog
rešenja
– Inicijalni opis funkcionalnosti rešenja - koje ukazuju na poslovni
problem
17.7.2015
MSF
25
Kako identifikovati ciljeve projekta?
• Poslovni ciljevi (business goals) obuhvataju:
– ono što klijent želi postići sa rešenjem PIS
– analizu matrice kompromisa i određivanje prioriteta
Primer: za projekat e-commerce web sajta, poslovni ciljevi bi
bili:
• proširiti tržište kompanije i tamo gde nema fizičkih prodavnica
• skratiti vremena prodaje efikasnijim korišćenjem online sajtova
• integrisati sve dobavljače, skratiti vreme porudžbine i isporuke.
• Projektni ciljevi (design goals) obuhvataju:
– fokus na atribute rešenja i prioritete među ciljevima.
Primer: ciljevi projektovanja e-commerce sajta:
• smanjiti vreme download-ovanja strane
• smanjiti zavisnost od konekcije sa serverom
• smanjiti vreme i nivo neophodnog rada za online registracije
17.7.2015
MSF
26
Vrednovanje Vision/Scope dokumenta
• Tim pregleda i modifikuje nacrt vision/scope dokumenta
• Tim organizuje sastanak sa klijentima i usaglašava:
– konačni dogovor o obimu projekta i granicama rešenja
– poslovne potrebe koje rešenje treba da ispuni
– viziju i oblast rešenja
– kompromise za definisanje granica sistema
– projektne ciljeve rešenja
– faktore rizika projekta
– inicijalni koncept upravljanja projektom rešenja PIS
– članove projektnog tima
– mehanizme za upravljanje projektom
• Dobijanje formalnog odobrenja vision/scope dokumenta
• Odobren dokument predstavlja kraj faze envisioning
17.7.2015
MSF
27
Project Structure dokument
• Definiše način na koji će tim organizovati i
upravljati projektom, uključujući:
– uloge i odgovornosti tima i klijenata
– komunikacione odluke
– logističke odluke vezane za razvoj rešenja
– odluke upravljanja promenama na projektu
– odluke procene progresa
• Komponente project structure dokumenta su:
– tim i struktura tima
– procene projekta - model troškova po fazama
– Prilozi\AWC - Project Structure.doc
17.7.2015
MSF
28
Project Structure dokument (1)
•
•
•
•
Namena dokumenta
Dinamički plan projekta (gantogram)
Model troškova
Tabelarni prikaz rokova završetka dokumenata
projekta
• Struktura tima
• Pristup upravljanju promenama
• Ograničenja
17.7.2015
MSF
29
Šta je Risk Management?
• Rizik projekta:
– potencijalni gubitak - sve što umanjuje kvalitet rešenja, povećava
troškove, premašuje rokove ili ukazuje na pad projekta
– kontrola i ublažavanje rizika projekta - osnovni aspekt uspešnog
razvoja rešenja
• Upravljaje rizikom:
– proaktivan pristup za kontrolu, ublažavanje i održavanje rizika na
prihvatljivom nivou
– definiše proces od šest koraka kroz koje tim upravlja tekućim rizicima
projekta
2Analiza i
1
Identifikovanje
rizika
sortiranje
prema
prioritetu
Izveštaj o rizicima
5
Kontrola
6
Učiti
Baza podataka
rizika, koncepti
rizika i postupak
17.7.2015
rešavanja (procesi)
3
Dokument
procene
rizika
Top n
rizici
Praćenje i
izveštavanje
Planiranje i
pravljenje
rasporeda
4
MSF Identifikovati i upravljati rizicima tokom
svih faza projekta
30
Sadržaj Risk Assessment dokumenta
Sadržaj
Opis
Izjava o faktoru rizika
Priroda svakog pojedinačnog faktora rizika
Verovatnoća pojave rizika
Verovatnoća da se rizik desi (u skali od 1 do 10)
Intenzitet rizika
Frekvencija pojave rizika
Intenzitet uticaja faktora rizika na projekat-i
Frekvencija pojave faktora rizika -f
Plan ublažavanja rizika
Sveukupna pretnja rizika: R=p*i*f
(izloženost riziku = verovatnoća * intenzitet*frekv.); preostali RRp=(R*A)/Mz; A-vrednost imovine; Mz –mere zaštite
Rp
Plan zaštite za ublažavanje faktora rizika
Plan za vanredne događaje
Koraci koji se preduzimaju kada se rizik dogodi
Uloge
za upravljanje
17.7.2015
MSF
rizikom
Ime člana tima koji je zadužen i odgovoran za upravljanje određenim
faktorima rizika
Izloženost riziku
31
Kako se kreira Risk Assessment dokument?
• Program menadžer kreira dokument Procena rizika
• Tim identifikuje faktore rizika
• Proceniti svaki faktor preostalog rizika, prema formuli:
Rp = (p * i*f)/Mz
• Izloženost Rp riziku je jednak proizvodu verovatnoće,
frekvekcije pojave i intenziteta potencijalnog uticaja rizika
na sistem uz preduzete mere zaštite
• Kreirati listu od 10 glavnih faktora rizika
– Rangirati faktore rizike po intenzitetu uticaja na
sistem
• Prilozi\AWC - Risk Tool.xls
• Prilozi\AWC - Simple Risk
Assessment Tool.xls
17.7.2015
MSF
32
MSF
Kreiranje konceptualnog dizajna





Uvod u fazu planiranja
Pregled funkcionalne specifikacije
Pregled konceptualnog projektovanja procesa
Izgradnja konceptualnog dizajna
Optimizacija konceptualnog dizajna
17.7.2015
MSF
33
Faza planiranja

Obrađuje informacije koje su prikupljene tokom faze envisioning
Faza definisanja vizije
Faza planiranja
Opšti zahtevi
Detaljni zahtevi
Grubi scenario
Detaljan scenario upotrebe
Koncept rešenja
Funkcionalna specifikacija
Kandidati za pristupe
17.7.2015
MSF
Dokumenti:
 Konceptualni dizajn
 Logički dizajn
 Fizički dizajn
34
Faza planiranja 1
Odobrena vizija
Odobreni plan projekta
U okviru faze planiranja razvija se konceptni, logički i fizički
dizajn rešenja
Konceptualni
Logičkil
Fizički
Pogled tima
17.7.2015
MSF
Pogled korisnika i
poslovnog sistema
Pogled projektanta
(developer’s
perspective)
35
Uloge i odgovornosti u fazi planiranja
Razvija use cases i usage
scenarios
Odgovoran za korisničke
zahteve, lokalizaciju i zahteve
prihvatljivosti rešenja
Razvija korisničku
dokumentaciju i planove obuke
Analizira poslovne zahteve
Započinje komunikacioni plan
Kreira konceptualni dizajn
Upravljanje
proizvodom
Upravljanje
programom
Korisničko
iskustvo
Odgovoran za konceptualni
i logički dizajn
Odgovoran za
funkcionalnu specifikaciju
Kreira master project plan,
budžet i raspored
the
Ocenjuje dizajn
Odgovoran za operativne
zahteve
Planira i pravi raspored za
uvođenje rešenja u sistem
17.7.2015
Upravljanje
objavljenom
verzijom
Razvoj
Testiranje
Ocenjuje dizajn
Razvija test zahteva
MSF planove testiranja i
Obezbeđuje
njegov raspored
Osigurava teničku
izvodljivost
Kreira logički i fizički
dizajn
Određuje plan razvoja,
procenjuje i pravi
raspored
36
Ključne tačke faze planiranja
• Faza planiranja se završava kada se odobri plan projekta
• Kritične tačke faze planiranja su:
– Funkcionalna specifikacija
– Glavni plan projekta
– Glavni dinamički plan projekta
– Ažuriran dokument procene rizika
Odobrena vizija
Validacija tehnologije
Funkcionalna specifikacija
Glavni projektni plan
Glavni dinamički plan projekta
Pripremljeno okruženje za razvoj i
testiranje rešenja
17.7.2015
Odobren
MSF
projektni plan
37
Funkcionalna specifikacija
• Definicija - virtuelni repozitorijum projekta koji sadrži:
–
–
–
–
–
–
–
dizajn rešenja
Use case dijagram
Usage scenarios dijagrame
korisničke zahteve i
funkcionalnosti rešenja
definiše šta će biti isporučeno (pilot rešenje/deo rešenja)
Služi kao ugovor između tima i klijenta
• Ciljevi:
–
–
–
–
Prikupljanje zahteva
Dokumentovanje problema
Modularizovanje rešenja
Obezbeđivanjje osnove za planiranje projekta i dinamičkog plana
projekta
17.7.2015
MSF
38
Elementi funkcionalne specifikacije
Elementi
Artefakti
Pregled
konceptualnog
dizajna
Use cases*
Usage scenarios, kontekstni modeli kao što su UI ekranski
prikazi
Pregled logičkog
dizajna
Modeli sekvence zadataka, logički modeli objekata i usluga,
konceptualni modeli predloženog rešenja, UI ekrani, logički
model baze podataka, arhitektura sistema
Pregled fizičkog
dizajna
Topologija distribucije komponenti, infrastruktura
arhitekture i dizajna, opis GUI ekrana, fizički model baze
podataka ...
Standardi i procesi
Sigurnost, pakovanje, održavanje, podrška, stabilizacija,
uvođenje
*Prilozi\AWC
17.7.2015

MSF
- UseCasesChapter2SrpskaVerzija.vsd
Prilozi\AWC Functional Specification Summary.doc
39
Šta je konceptualni dizajn?
Visok nivo prezentacije rešenja:
Prikuplja, analizira i postavlja
prioritete na poslovne i
korisničke poglede na problem
i rešenje
Modelira zahteve
Ciljevi konceptualnog dizajna:
Razumevanje poslovnih
problema koji treba da budu
rešeni
Razumevanje zahteva
poslovanja, klijenta i krajnjeg
korisnika
Opisuje ciljno buduće stanje
sistemaMSF
17.7.2015
Odobrena
vizija/domen
Baseline
Odobren
projektni plan
Konceptni
Logički dizajn
Fizički dizajn
40
Koraci konceptualnog dizajna
 Istraživanje:
identifikuju se ključni poslovni procesi, vrednuju
i proširuju zahtevi, slučajevi korišćenja i scenarija upotrebe
 Analiza: dokumentuju se i modeliraju tokovi poslova,
sekvence zadataka i veze u okruženju
 Optimizacija: optimizuje se konceptno rešenje i vrednuje i
testira poboljšani poslovni proces
Istraživanje
Analiza
Optimizacija
Konceptni
dizajn
17.7.2015
MSF
41
Koraci analize kod konceptualnog dizajna
• Namena:
– razmatra mogućnost projektovanja želja
korisnika
– razmatra korisničke i poslovne procese i
aktivnosti
– modeluje i dokumentuje zadatke, poslovne tokove
i sadržaj
• Zadaci:
– transformisanje prikupljenih podataka u informaciju
od značaja
– prerada use case dijagrama
– izbor arhitekture aplikacije za rešenje
– kreiranje konceptualnog modela rešenja
17.7.2015
MSF
42
Servisi u rešenju PIS
• Cilj konceptualnog dizajna - konceptualni model rešenja.
• Za kreiranje konceptualnog modela treba razumeti servise
koje rešenje mora da obezbedi.
• Servisi su logičke aplikacione jedinice koje se izvršavaju
akcijama, uključujući:
– metode za implementaciju operacija,
– funkcionisanje ili transformisanje,
– implementaciju poslovnih pravila,
– rukovanje podacima,
– dodavanje, pregledanje, modifikaciju podataka i dr.
• Klijente ne zanima kako su servisi implementirani, već da li
mogu da izvrše željenu akciju.
17.7.2015
MSF
43
Servisi u rešenju PIS (1)
• Tipični servisi koje rešenje obezbeđuje su:
– Korisnički servisi – obezbeđuju korisnički interfejs u aplikaciji,
omogućavaju interakciju između aplikacije i njegovih korisnika.
– Poslovni servisi – obezbeđuju da se poslovna pravila izvršavaju
prema tačno određenoj sekvenci; kriju logiku implementacije
poslovnih pravila i transformišu podatke iz korisničkih i poslovnih
procesa i procesa (servisa) podataka.
– Servisi podataka – obezbeđuju najmanje vidljive detalje za
rukovanje sa podacima; koriste se za implementaciju poslovne
šeme nad uskladištenim podacima koje koristi aplikacija.
– Sistemski servisi – obezbeđuju funkcionalnost van poslovne
logike; uključuju backup servise, servise za rukovanje sa
greškama, bezbednosne servise, servise za rad sa porukama.
17.7.2015
MSF
44
Primeri servisa
Korisnički servisi
prikazivanje
Poslovni servisi
popunjavanje
Servisi podataka
17.7.2015
porudžbine
prikazivanje računa klijenta
prikazivanje informacija o proizvodu
porudžbine
ažuriranje informacija na računu klijenta
izvlačenje informacija o proizvodu
provera zaliha proizvoda
informacije porudžbine
račun klijenta
informacije o proizvodu
MSF
45
Arhitektura aplikacije
•
•
•
•
•
•
•
•
Servisi su organizovani prema arhitekturi aplikacije.
Arhitektura aplikacije:
– sastoji se od definicija, pravila i relacija koje formira struktura jedne
aplikacije
– pokazuje kako je aplikacija struktuirana, ali ne i kako je implementirana
– fokusira se na rešenje, a ne na tehnologije za implementaciju rešenja.
Za razvoj konceptualnog modela rešenja, treba izabrati aplikacioni model i
kandidate aplikacione arhitekture
Projektni tim bira arhitekturu zasnovanu na servisima koje rešenje mora da
obezbedi i na korisničkim očekivanjima o performansama tog rešenja.
Pretpostavke i ograničenja utiču na izbor arhitekture rešenja.
Pretpostavke podrazumevaju na primer OS koji (će) se koristiti u PIS.
Ograničenja mogu biti raspoloživi budžet, vreme, veštine i resursi
Arhitekture aplikacija koje se koriste su:
– klijent/server arhitektura
– slojevita arhitektura
– stateless arhitektura
– cache arhitektura
– hibridna arhitektura (slojevita-klijent-keš-stateless-cache-server) omogućava kreiranje fleksibilne i skalabilne aplikacije
17.7.2015
MSF
46
Opis arhitektura aplikacija
•
Klijent/server arhitektura:
– klijent započinje i kontroliše sesiju sa serverom.
– server izvršava zahtevanu operaciju i vraća rezultat klijentu
– Ograničenje - velika zavisnost klijenta od servera.
•
Slojevita arhitekutra (layered):
–
–
–
–
proširena verzija klijent/server arhitekture sastavljena od hijerarhijskih slojeva.
različiti servisi u aplikaciji su jasno pozicionirani na određene slojeve
samo servisi na susednim slojevima mogu međusobno komunicirati
slojevi enkapsuliraju i štite servise jedan od drugih obezbeđujući jednostavni set interfejsa
za deljene resurse
– Primeri: servisi prezentacije, poslovni servis i servis podataka.
– Prednosti - poboljšani skalabilnosti i bezbednost sistema.
•
Stateless arhitektura:
– verzija klijent/server ili slojevite arhitekture
– svaki klijentski zahtev sadrži sve informacije koje zahteva server za obradu zahteva
– nijedna informacija se ne skladišti kod klijenta.
•
Cache arhitektura:
– drugi pristup u kojem aplikacija obezbeđuje način za obradu klijentskog zahteva bez
forward-ovanja tog zahteva drugim mašinama
– za implementaciju ove arhitekture, treba identifikovati šta se može, a šta ne keširati i
– definisati načine upravljanja vremenom artikala u kešu.
17.7.2015
MSF
47
Struktura aplikacije PIS

U dobro struktuiranoj aplikaciji, informacija se kreće između tri sloja:
 Korisnički sloj (prezentacije) – predstavlja informacije korisniku
i prikuplja informacije od korisnika. Tehnologije koje se koriste:
npr., X-Windows Presentation Manager, itd.
 Sloj poslovnih procesa – radi nad informacijama u skladu sa
funkcionalnim specifikacijama aplikacije.
 Sloj podataka – održava operaciona ograničenja koja vode
poslovanje. Osigurava da ni jedna aplikacija ne protivureči ovim
pravilima.

Danas se aplikacije predstavljaju putem: mobilnih telefona, Wireless
Markup Language (WML), Web browsers (HTML, Style Sheets,
JavaScript), PDF itd.
17.7.2015
MSF
48
Višeslojna arhitektura aplikacije
•
•
•
Neki od ovih slojeva velike i složene aplikacije mogu se dalje
podeliti(Sl.).
Stored procedures (sačuvane procedure) su:
– uobičajene alatke koje se upotrebljavaju u DB
– kompajlirani SQL iskazi upakovani u vidu programa u samu DB
– obezbeđuju znatno brži odziv DB na SQL iskaz, pošto su već
kompajlirane
Prednosti višeslojne arhitekture aplikacija:
– Umanjuje složenost iz perspektive razvijalaca, npr., oni koji
prave Data Objects ne moraju poznavati poslovnu logiku rada
aplikacije, o čemu brinu Business Objects.
– Priprema za promene, npr., zamena stare baze podataka i
modifikacija Data Objects za upotrebu nove baze, bez koriekcije
Business Objects.
– Ovakve aplikacije su pristupačnije u odnosu na klasične
klijent/server aplikacije gde svaki klijent mora imati zasebnu
vezu sa DB. Npr., možete uspostaviti skup veza sa DB i
postaviti ih kao deljene za Data Objects, što znači uslugu više
klijenata nego što ima veza sa DB.
– Povećana mogućnost ponovne upotrebe. Veoma je lako
određene komponente ponovo upotrebiti u drugim aplikacijama.
– Velika sigurnost. Korisnik nikada ne pristupa direktno podacima,
već uvek preko poslovnog sloja. Na taj način se može sprečiti
slučajno ili namerno kvarenje podataka.
17.7.2015
MSF
Database
Stored Procedures
Data Objects
Data-Centric Business
Objects
User-Interface-Centric
Business Objects
Presentation
49
Primer dijagama komponenti aplikacije PIS
17.7.2015
MSF
50
Izbor arhitekture aplikacije-konceptualni model
Bezbednost
Operacioni menadžment
Komunikacija
Korisnici
Sloj podataka
17.7.2015
1
Komponente korisničkog interfejsa (UI)
2
Komponente procesa UI
Interfejsi servisa
Poslovni
workflows
Poslovne
komponente
Komponente pristupa
podacima
Poslovni
objekti
Sloj
prezentacije
Sloj servisa
poslovanja
Agenti usluga
Sloj dodatnih
servisa
Izvori podataka
Usluge
MSF
51
PRIMER: Konceptualni model arhitektura aplikacije
17.7.2015
MSF
52
Primer: Višeslojni pristup
 Pre
Rešenje 1
Rešenje 2
Rešenje 3
DB
DB
DB
1 fakultet
2 fakultet
3 fakultet
 Sada
višeslojni pristup
Pocket PC
DB komunikaciona komponenta
koja kompenzuje prelazak baze u
MySQL ili ORACLE ili SQL
Server.
studepredaispiti
nti
vači
ADO.NET
17.7.2015
DB
MSF
53
Koraci validacije konceputalnog modela
Koraci:
17.7.2015
1
Reinženjering posla
2
Izgraditi nekoliko scenarija koji prikazuju posao
3
Nacrtati korisničke interfejse
4
Dobiti povratnu informaciju od korisnika
5
Ponavljati korake sve dok korisnik ne bude zadovoljan
MSF
54
Kreiranje logičkog dizajna
 Pregled
logičkog dizajna
 Izgradnja logičkog dizajna
 Dokumentovanje logičkog dizajna
 Optimizacija logičkog dizajna
17.7.2015
MSF
55
Šta je logički dizajn?
• Proces definisanja rešenja iz perspektive projektnog tima
• Zadaci
Analiza
Prerada preporučenih tehnologija
Odobrena
vizija/domen
Identifikovanje poslovnih ciljeva i usluga
Identifikovanje atributa i relacija
Optimizacija
Analiza
Poboljšanje logičkog dizajna
Validacija logičkog dizajna
Odobren
projektni plan
Logički dizajn
Logički dizajn
17.7.2015
MSF
56
Koje su prednosti logičkog dizajna?
• Pomaže da se upravlja kompleksnošću
projekta
• Verifikuje da dizajn prikazuje poslovni
problem
• Olakšava koordinaciju između višestrukih
sistema
• Koristi se kao osnova fizičkog dizajna
17.7.2015
MSF
57
Koje su odgovornosti tima tokom
logičkog dizajna?
Štiti poslovne i
korisničke potrebe
Formuliše korisničke
ciljeve i predloženo
rešenje
Upravljanje
programom
Korisnička
iskustva
Upravljanje
verzijom
rešenja
Ocenjuje izvodljivost
implementacije rešenja
17.7.2015
Odgovara za logički
dizajn
Upravljanje
proizvodom
Razvoj
Pomaže u redizajnu
servisa i
identifikovanih
pridruženih objekata
Testiranje
Osigurava
da je logički
MSF
dizajn valjano urađen
58
Obrada liste kandidantnih tehnologija u logičkom dizajnu
•
•
•
Poslovna razmatranja:
– Izvodljivost, troškovi proizvoda, iskustva, povraćaj
investicija (ROI), zastarelost i drugi faktori
– Legacy (nasleđe, ostavština) problem definiše da naša
IT rešenja traže više ulaganja od uvođenja IT projekta
Održavanje nas više košta nego njegov razvoj
Razmatranje arhitekture preduzeća:
– Rešenje mora da bude u okviru ograničenja i
trenutnog i budućih planova
Razmatranje tehnologije:
– Bezbednost, pristup podacima, skladištenje podataka,
sistemski servisi, alati razvoja i operativni sistemi.
17.7.2015
MSF
59
Kako identifikovati poslovne objekte?
Efektivan metod za identifikovanje poslovnih objekata:
 proučiti usage scenarija
 identifikovati imenice i pridruženi glagole
 prevesti imenice i glagole u objekte i pridružene servise
Scenarijo
Ljudi ili
stvari
Obračun vremena (Bill Time)
Konsultant traži naziv
klijenta
Na osnovu zahtevanog
naziva, sistem izvlači broj
klijenta
Konsultant obračunava
vreme za klijenata
17.7.2015
MSF
Poslovni
objekti
60
Kako identifikovati atribute?
 Atributi (svojstva) su definicije vrednosti podataka koje
objekat poseduje
 Ispitati usage scenarije na prideve i dodatne imenice koje
nisu u kategoriji objekata
Poslovni objekt
Kupac
17.7.2015
MSF
Atribut
Vrednosti jednog stanja
Account Number
10076
Name
Contoso, Ltd.
Address
123 East Main
Credit
Approved
Last Consultant
Greg Chapman
61
Kako identifikovati servise?
Servisi su specifična ponašanja koje poslovni objekat mora da izvršava
Ispitati usage scenarios na glagole
Scenariji
Obračun vremena
 Konsultant traži naziv
klijenta
 Na osnovu zahtevanog
naziva, sistem izvlači
broj klijenta
 Konsultant
obračunava vreme za
klijenta
17.7.2015
Akcije
Servisi
Uzorak teksta scenarija
Servisi kandidati
 Konsultant traži naziv
klijenta
 Na osnovu zahtevanog
naziva, sistem izvlači
broj klijenta
 Konsultant pregleda
prethodne račune za
broj klijenta
 Konsultant obračunava
vreme za klijenta
Pronaći klijenta
MSF
Izvući broj klijenta
Pregledati istoriju
računa
Pripisati časove
62
Kako identifikovati relacije?
Zaposleni je osoba
Relacija generalizacije
Spisak zaposlenih
Lista zaposlenih sadrži zaposlene
Relacija celina/deo
“sadrži”
Kompanija
“je”
Osoba
Zaposleni
“radi za”
“je”
Konsultant je osoba
Relacija generalizacije
17.7.2015
“obezbeđuje
servis”
Zaposleni radi za kompaniju
Relacija celina/deo
Konsultant obezbeđuje servise zaposlenom
Relacija interakcije
Konsultant MSF
63
UML relacije
• UML definiše četiri tipa relacija:
– Zavisnost:
• relacija između dva objekta gde promene u jednom objektu
mogu da utiču na ponašanje i servise drugog objekta
• upotrebiti je ako se želi pokazati kako jedan objekat koristi drugi
Product
-Weight
-Height
-Width
-Depth
-Color
Product Catalog
-ProductCollection
+AddNewProduct (Product p)()
–
–
–
Asociajacija:
predstavlja relaciju između celine i njegovih delova
agregacija je specijalni tip asocijacije npr: Porudžbina sadrži stavke porudžbine
Product
-Weight
-Height
-Width
-Depth
-Color
17.7.2015
-IsOrganizedBy
-Organizes
Category
-CategoryID
-CategoryName
*
*
MSF
64
Tipovi relacije asocijacija
(composition):
 obično u jednoj relaciji
agregacije
 njeni delovi su vremenski
zavisni od celine.
Primer: Porudžbina sadrži
stavke podrudžbine.
Agregacija (aggregation):
 ukoliko njeni delovi nisu
vremenski zavisni od
celine.
Order
Kompozicija
17.7.2015
MSF
1
0..*
Order Line Item
Company
1
1..*
Person
65
UML relacije
Customer
• Generalizacija
(generalization):
– relacija između generalnog
tipa (roditelja) i podtipova
(dece).
Low-Volume Customer
Large Reseller Customer
Organization
• Realizacija (realization):
Party
– relacija između klasa
– jedna apstraktna klasa specifira
zadatke koje druga klasa mora
da sprovede.
17.7.2015
MSF
+Create an Account()
+Delete and Account()
+Update an Account()
-Name
-Address
-Phone
-Primary Contact
-Status
-Comments
+Add Contact()
+Update Contact()
+Delete Contact()
66
Kako modelovati relacije?
•
Dijagram sekvenci (sequence diagrams):
– Prikazuje hronološki uređene učesnike i objekte koji učestvuju u jednoj
interakciji
– Prikazuju događaje koje učesnici i objekti generišu
– Mogu pojasniti tok kontrole i sekvence ponašanja
Primer logičkog dizajna dijagrama sekvenci:
ProductClerk
Search
Catalog
Product
Engineering
Open Catalog
Enter Product ID
Search for Product
Locate Product
Pull Product from Catalog
Return Product Information
Add New Spec to Product Record
Mark Product as "ready-for-review"
Auto-Notification for Review
Review Product
Mark Product as "approved"
Auto-Notification of Approval
Save Changes
17.7.2015
MSF
67
Kako kreirati logički objektni model?
•
•
Na osnovu prethodno definisanih objekata, servisa, atributa i relacija u procesu logičkog dizajna
Razmatra se: bezbednost, globalizacija, lokalizacija, osmatranje i praćenje, logovanje,
rukovanje greškama, integracija sa postojećim sistemima
Primer logičkog modela objekta:
Product Catalog
Order Line Item
-Catalog ID
-Start Date
-Expiration Date
-Season
-Items
-Promotional Matter
+Search for Product()
+Set Filters()
+Get Details()
+Set Details()
-Product ID
-Quantity
-Unit Price
-Ship Date
-Unit Price Discount
-Line Total
-Backorder Date
+Add Product()
+Set Quantity()
+Set Discount()
+Validate Discount()
1
1
Category
0..*
-Category ID
-Category Name
+List Products()
+List SubCategories()
0..*
1..*
0..*
Order
-Order ID
-Order Date
-Ship Date
-Delivery Date
-Shipping Address
-Shipping Method
-Total Weight
-Sales Person
-Purchase Order Number
-Currency
-SubTotal
-Tax Amount
-Freight Amount
-Total Due
-Status
-Credit Card Number
-Credit Card Expiration
-Comments
+Set Delivery Address()
+Confirm Address()
+Set Payment Details()
+Make Payment()
+Track Status()
1..*
1
Party
+Create an Account()
+Delete and Account()
+Update an Account()
Employee
-Employee ID
-Name
-Address
-Phone
-Email
-Role
-Start Date
-Current Salary
-Active Flag
-National ID number
-Birth Date
-Login ID
-Password
-Marital Status
-Gender
-Manager ID
-Department
*
Customer
Organization
-Account Number
-Shipping Preference
-Product Preferences
-Notification Preference
-Name
-Organization
-Shipping Address
-Phone
-Email
-Credit Cards
-Billing Addresses
-User ID
-Password
-Birthday
-Gender
-Role
+Get Address List()
+Add Address()
+Validate Signature()
-Name
-Address
-Phone
-Primary Contact
-Status
-Comments
+Add Contact()
+Update Contact()
+Delete Contact()
Product Clerk
Product
-In Stock Flag
-Promotional Description
-Promotional Discount
-Name
-Stock Unit ID
-Photo
-ReOrder Point
-Weight
-Dimensions
-Category
+Print Product Specs()
+View Product Specs()
+Get Summary Information()
+Get Details()
+Set Details()
*
*
+Edits Product Data()
Sales Manager
+Approves Discounts between 15% to 20%()
+Applies discounts up to 20%()
+Creates Orders()
Sales Representative
+Applies 15 % discount()
+Requests up to 20% discount()
+Creates orders()
+Takes Phone Orders()
Analysis Query
*
17.7.2015
MSF
*
*
-Query Id
-Query
-Description
-EmployeeId
+Create Query()
+Edit Query()
+Delete Query()
*
68
*
Kako kreirati logički model podataka?
• Pretvoriti
konceptualne potrebe za podacima u objekte i
relacije
Evidencija
Zaposleni
Ime
Prezime
Adresa
E-mail
kompletira
ugovara sa
Zaposleni
Klijent
Datum
Troškovi
UkupnoSati
Opis
MSF
šalje se
NazivKlijenta
AdresaKlijenta
GradKlijenta
DržavaKlijenta
Datum
Iznos
Klijent
Naziv
Adresa
Grad
Država
17.7.2015
Račun
šalje se
69
Kako kreirati preliminarni dizajn korisničkog interfejsa?
- Za svaki scenario treba nacrtati dizajn korisničkog interfejsa
Kategorije unutar
kataloga
Kriterijum pretrage se koristi za
pretraživanje trenutnog kataloga
Tekuće specijalne ponude
u specifičnom katalogu
Povezuje na “Home”,
“Help”, “Računi”,
“Praćenje porudžbine” i
dr.Takođe uključuje
napomenu o autorskim
pravima (copyright)
17.7.2015
MSF
70
Optimizacija logičkog dizajna
• Kako preraditi (prečistiti) objekte?
• Kako verifikovati postojeći logički objektni model?
• Kako uspostaviti kontrolu u logičkom dizajnu?
Odobrena
Vizija/Obim
Analiza
Optimizacija
Odobreni planovi
projekta
Logički dizajn
17.7.2015
MSF
Analiza Baseline-a
Baseline
logičkog dizajna
71
Kako prečistiti objekte?
•
•
Odrediti da li su objekti relevantni za rešenje
Razmotriti
– Redundantnost informacija ili funkcionalnosti
– Specifičnost objekata
– Oblast projekta
– Potrebe za dodavanjem objekata radi
kontrole ili koordinacije skupa servisa
17.7.2015
MSF
72
Primer: Optimizacija

Primer optimizacije:
1)
magacioner popunjava otpremnicu
2)
magacioner popunjava prijemnicu

Problemi kod dupliranih objekata je ažuriranje

Kako otpremnica i prijemnica imaju iste atribute, to će onda
biti jedan objekat sa dodatnim atributom npr.
tip=ulazna/izlazna.
Dokumenti
Artikli
Stavke
∞
Tip
dokumenta
∞
1
prijemnica
1
1
∞
otpremnica
faktura
profaktura
17.7.2015
MSF
73
Kako verifikovati postojeći logički objektni model?
• Vrednovati prema zahtevima:
– logički model podataka je nekompletan ukoliko i jedan
jedini zahtev korisnika nije pokriven
• Vrednovati individualne objekte:
– identifikovati ulaze i izlaze jednog objekta i
mogućnost ili funkcionalnost koju objekat mora da
obezbedi
– pravovremeno predvideti izlaze i ponašanja za svaki
ulaz
• Proći kroz scenario:
– verifikovati nezavisnost i sekvencu objekata i servisa
vođenjem komplentnog scenarija
17.7.2015
MSF
74
Kreiranje fizičkog dizajna




Pregled fizičkog dizajna
Analiza fizičkog dizajna
Racionalizacija fizičkog dizajna
Implementacija fizičkog dizajna
17.7.2015
MSF
75
Šta je fizički dizajn?
•
•
•
•
•
Prikazuje kako će biti implementirano rešenje
Identifikuje odgovarajuće tehnologije za razvoj rešenja
Transformiše logički u fizički dizajn
Obezbeđuje osnovu za fazu razvoja (development-a)
Tim razvija specifikaciju komponenti i topologiju za
uvođenje rešenja
Konceptualni dizajn
Scenarija
Logički dizajn
Servisi i objekti,
korisnički interfejs i
logička baza podataka
17.7.2015
MSF
Fizički dizajn
Komponente, korisnički
interfejs i fizička
baza podataka
76
Odgovornosti tima tokom fizičkog dizajna
Upravlja klijentskim očekivanjima
Kreira komunikacioni plan
Ocenjuje fizički dizajn prema
zahtevima korisnika
Dizajnira Help-ove
Upravljanje
proizvodom
Upravljanje
programom
Korisničko
iskustvo
Upravljanje
verzijom
rešenja
Ocenjuje uticaj fizičkog
dizajna na infrastrukturu
Razvoj
Testiranje
Ocenjuje i vrednuje
funkcionalnost i
konzistentnost fizičkog
dizajna i usage scenarija
17.7.2015
Odgovoran za proces
fizičkog dizajna
Kreira funkcionalnu
specifikaciju
MSF
Projektuje modele, planove
razvoja i rasporede i procenjuje
razvoj
77
Izlazni dokumenti fizičkog dizajna
•
•
•
•
•
•
Dijagrami klasa
Modeli komponenti, dijagram sekvenci ili dijagram
aktivnosti rešenja
Šema baze podataka
Model uvođenja (deployment)
– mrežna topologija
– topologija razmeštaja (deployment)
Pakovanje i strategija distribucije
Model programiranja
17.7.2015
MSF
78
Koraci kod fizičkog dizajna
Odobrena
vizija/domen
Istraživanje
Analiza
Racionalizacija
Odobren
projektni plan
Implementacija
Konceptni
Fizički dizajn
Logički dizajn
Fizički dizajn
17.7.2015
MSF
79
1. Koraci istraživanja
• Fokusiranje na kreiranje tehničkih rešenja
• Identifikovanje fizičkih zahteva
– performanse, troškovi vs. korist, lakoća korišćenja,
pouzdanost
• Identifikovanje fizičkih ograničenja
– budžet, raspored, topologija mreže, bezbednost
• Razrešavanje konflikta između zahteva i
ograničenja
• Izlazna dokumenta faze istraživanja su:
– trenutna topologija mreže/podataka/komponenti
– fizički zahtevi aplikacije
– ažurirani planovi procene i ublažavanja rizika
17.7.2015
MSF
80
2. Analiza fizičkog dizajna
• U fazi analize tim kreira i poboljšava sledeće
modele fizičkog dizajna:
– Dijagrami klasa (statička struktura aplikacije)
– Dijagram sekvenci (dinamički aspekt objekata)
– Dijagram aktivnosti (umesto d. sekvenci)
• uključuju zahteve za fizičku platformu i za
tehnologijom
• identifikuju potencijalni workflow proces
– Dijagram komponenti (zavisnosti između
komponenti ili paketa komponenti)
17.7.2015
MSF
81
Primer: Dijagram klasa za komponente porudžbine
oCatalog
+getCatalogItems(in Category : String, in currentPage : Integer) : <unspecified>
+addCatalogItem() : Boolean
+removeCatalogItem() : Boolean
+GetProductInfo(in ProductID : Integer) : oProductSpec
+GetCustomerReviews(in ProductID : Integer) : <unspecified>
oSecurity
oRole
oOrder
oCatalogItem
+ProductID : Integer
+New() : Boolean
+Delete() : Boolean
+isDuplicate ??() : Boolean
+edit() : Boolean
1
+OrderNumber : Integer
+OrderDate : Date
+ProposedDeliveryDate : Date
+ShippingAddress
*+TotalDue : Currency
+createOrder() : Boolean
+deleteOrder(in OrderNumber : Integer) : Boolean
+addOrderDetail(in ProductID : Integer, in Quantity : Integer) : Boolean
+removeOrderDetail(in ProductID : Integer) : Boolean
+CalculateTotalDue(in OrderNumber : Integer) : Currency
+ValidatePayment() : Boolean
+ShowOrderStatus(in OrderNumber : Integer) : oOrder
oCustomer
*
-CustomerID
1
-EmpID
+AddShippingAddress(in ShippingAddress) : Boolean
+AmendShippingAddress() : Boolean
+DeleteShippingAddress() : Boolean
1
1
0..1
*
17.7.2015
oEmployee
oOrderDetail
oShoppingCart
+ItemDescription : String
+Quantity : int
+StandardPrice : Currency
+DiscountedPrice : Currency
+New()
+Delete()
+AmendQuantity()
+ApplyDiscount()
+AddProductToCart()
+ChangeQuantityInCart()
+RemoveProductFromCart()
+ViewCart()
+ProvidePayment()
+ProvideShippingDetails()
-DoCreditCheck()
MSF
82
Primer: Dijagram sekvence
• Dodavanje
Contact
proizvoda u katalog
NewProductForm.aspx
SQL Database
CatalogItem.aspx
RequestNewProductForm(UserRole,NewProductDataset)
productDesc(statechanged)
productSpec(statechanged)
«precondition»
{isinRole(ProductionClerk)}
productPicture(statechanged)
submit(controlsChanged,newProductDataset)
productDatasetUpdate(all)
RequestCatalogIDnumber(UserCredential)
ReturnCatalogIDnumber(RowGuid)
CatalogItemCreate(newProductDataset)
ItemCreated(success(Boolean))
CatalogItemDisplay(confirmedProductDataset)
17.7.2015
MSF
83
Primer: Dijagram komponenti za proces poručivanja
Use Microsoft Excel on client to manipulate analysis from Microsoft SQL Server TM OLAP cubes
Locate Facilities
Analysis Services
Use groups for divisions within the company
Use roles per titled position
Use WindowsIdentity for empolyee credentials
Use GenericIdentity for Customer credentials
Orders
Customer Catalog
Security
Search (Microsoft SharePoint Portal Server
TM)
17.7.2015
Contact Management (Microsoft Outlook)
MSF
84
Kako kreirati preliminarni model uvođenja?
(deployment model)
• Topologija mreže pokazuje:
– Radne stanice i servere i ukazuje na njihove
funkcije
– Infrastrukturu mreže koja povezuje računare
• Topologiju komponenti i podataka:
– Mapa koja ukazuje na lokacije paketa,
komponenti i njihovih servisa u relaciji sa
topologijom mreže i lokacijama baze
podataka.
17.7.2015
MSF
85
Primer: Topologija uvođenja komponenti i podataka
Adventure Works Cycles Data and Component
Topology
INTERNET
Internal Windows Clients
ROUTER
Internal Web Clients
Internal
Firewall
External
Firewall
EXTRANET
Internet
Information
Server
Posebni serveri MAIL
Contact
Storage
17.7.2015
SHAREPT
Search
FS
File and
Print
services
PRODCAT
Customer
Catalog
and
Orders
OLAP
Analysis
Services
MSF
INTRANET
Internet
Information
Server
86
3. Racionalizacija fizičkog modela
• Iterativni proces dizajna optimalnog rešenja
• Ciljevi:
– distribucija servisa i
– pakovanje servisa u komponente
• Za strategiju distribucije i pakovanja komponenti
potrebno je razmotriti:
– menadžment stanja na klijentskoj strani:
• svojstva, skrivena polja, kolačiće, stringove upita i
– menadžment stanja na serverskoj strani:
• stanje aplikacije, stanje sesije i stanje baze podataka
• Tim razmatra: skalabilnost, performanse, upravljivost,
upotrebljivost, granularnost
17.7.2015
MSF
87
Kako pakovati komponente?
Bezbednost
Operacioni menadžment
Komunikacija
Korisnici
1
UI komponente
2
UI komponente procesa
Interfejsi servisa
Poslovni
Workflows
Poslovne
komponente
Logičke komponente
pristupa podacima
Servisi podataka
17.7.2015
MSF
Poslovni
objekti
Agenti servisa
Servisi
88
Kako distribuirati preliminarne komponente?
User and
Business
Services
Business
Services
Consultant
Preliminary
Component
Distribution
Preliminary
Component
Distribution
Display time
sheet
Get final job
number
Submit time
sheet
Consultant
Consultant
Consultant
Retrieve time
sheet
Assign job to
customer
Display time
sheet
Consultant
Data and
Business
Services
17.7.2015
Preliminary
Component
Distribution
Store time
sheet
Get time
sheet
MSF
Update time
sheet
Consultant
Archive time
sheet
89
Kako kreirati deployment model?
• Kreirati dijagram koji pridružuje aplikacije njegovim
servisima u topologiji servera
Klijent
Zahtev klijenta
Internet Information Services
17.7.2015
MSF
Serveri
OLAP
Mail
SharePoint
ASP.NET
Podaci o bezbednosti
Active Directory®
Poslovni podaci
SQL Server
90
4. Implementacija fizičkogi modela
• Tim određuje model programiranja, interfejse i internu
strukturu za svaku komponentu
• Model programiranja razmatra:
– tehnologije implementacije, koheziju i sprezanje, višenitni model
rukovanja greškama, bezbednost, distribuciju i dr.
• Opis interakcije i interfejsa komponenti (obično XML
web servisi) i razmatra:
– fizička ograničenja DB, performanse, indeksiranje, PK i FK, mograciju
podataka itd.
• Koraci in house dizajna PIS od početka:
– projektovanje arhitekture aplikacije, DB, intefejsa sistema, ažuriranja
plana projekta
• Koraci integracija kupljenog rešenja u PIS:
– identifikacija potrebe, prikupljanja potencijalnih rešenja,selekcija,
ugovaranje i nabavka
17.7.2015
MSF
91
Primer: Fizički model baze podataka
• Tim razmatra sledeće:
– Ograničenja fizičke
baze podataka kao
što su memorija i
veličina diska
– Performanse
(deadlock detekcija,
indeksiranje ...)
– Primarni ključevi i
spoljni ključevi
– Migracija podataka
iz prethodnih sistema
baza podataka i dr.
17.7.2015
MSF
CatalogItems
PK
GUID
FK1
ItemID
Description
Specification
Picture
CategoryID
Categories
PK
CategoryID
CategoryText
Orders
PK
GUID
OrderDate
ShippedDate
ShipName
ShipAddress
ShipCity
ShipRegion
ShipPostalCode
ShipCountry
GUID
Order Details
PK,FK3 OrderGUID
PK
DetailLineID
FK2
UnitPrice
Quantity
CatalogItemGUID
Discount
92