Professional Documents
Culture Documents
PS 2 - Proces Razvoja Softvera
PS 2 - Proces Razvoja Softvera
Uvod
Proces razvoja
uređeni skup zadataka koje treba uraditi da bi se napravio proizvod
ili pružila usluga
definisanje aktivnosti i resursa
definisanje ograničenja (budžet, vremenski rokovi, prostor, redosled aktivnosti,
raspoloživost alata,...)
Metodologija razvoja
disciplina u razvoju u cilju veće efikasnosti
3
3. Projektovanje programa
generisanje potprojekata (modula) pogodnih za programsku realizaciju
veze između modula i načini razmene podataka
4. Implementacija programa
izrada programskog koda prema projektu
4
7. Održavanje sistema
ispravljanje grešaka nakon isporuke
unapređivanje sistema (novi zahtevi ili promene u okruženju)
Modelovanje
SPECIFIKACIJA MODEL ISPORUČENI
ZAHTEVA PROCESA PROIZVOD
RAZVOJA
Razlozi za modelovanje
Tradicionalne metode
Projektovanje
Kodiranje
Osobine
+ -
ne podržava povratne sprege koje postoje
u stvarnosti (više iteracija, dopuna
jednostavnost, olakšava zahteva, greške u završenim fazama,...)
komunikaciju sa kupcima
ne ukazuje na način povezivanja faza
lako praćenje projekta (kako izlaz jedne faze transformisati u
rezultat sledeće faze)
laka primena modela; jedna
iteracija; pogodan kada u razvoj softvera se ne posmatra kao
kratkom roku treba zameniti rešavanje problema; model koristi
stari sistem novim industrijski pristup, a razvoj softvera je
stvaralački, a ne proizvođački proces
V model (1)
Nemačko Ministarstvo odbrane,1992.g.
Završno
testiranje
Projektovanje
sistema Testiranje
celog sistema
Verifikacija projekta
V model (2)
Kako se koristi
V model?
testiranje
V model (3)
+ -
podržava povratne sprege,
pogodan za razvoj složenih,
nedovoljna fleksibilnost, pri povratku
realnih sistema
na ranije faze, nije dovoljno samo
uneti izmene, već treba ažurirati
omogućava verifikaciju i validaciju
sve naredne faze zajedno sa
sistema
dokumentacijom
daje kvalitetan proizvod zbog
zahteva obimne resurse i veća
strogo kontrolisanog procesa
novčana sredstva jer je razvojni tim
razvoja
brojan
vodi računa o testiranju u
ranim fazama projekta
12
Fazni razvoj
velika konkurencija na tržištu diktira kraći razvoj; najveći prihod od novijih
softvera
Razvojni sistemi
RAZVOJNI
TIM
Produkcioni sistemi
13
v2 v2 v3
v1 v1 v1
14
+
brza isporuka operativnog skupa funkcija; već nakon prve faze,
korisnik ima skup funkcija iz finalnog proizvoda
Primer
v1 v2 v3
16
+
mogućnost rane obuke; već nakon prve faze delimična obuka može
da počne (organizacija interfejsa, načini izvršavanja funkcija,...),
korisnici sugerišu moguća poboljšanja
Zahtevi Isporučeni
sistem
18
+ -
nedovoljna analiza; fokusiranje na prototipove
odvraća od analize na nivou celog sistema;
redukovanje vremena i
posledice mogu biti: previđanje boljih rešenja,
troškova; detaljna analiza pri
nekompletna specifikacija, konačna rešenja
izradi prototipa zahteva u ranoj
teška za održavanje
fazi utvrđuje šta korisnik zaista
želi, a time se ubrzava razvoj i
konfuzija između prototipova i finalnih
smanjuju troškovi
sistema; prototipovi nisu finalni proizvodi koje
treba “samo malo doraditi”; potreban je veliki
intenzivna interakcija sa
napor za uvođenje provere grešaka ili
korisnicima
mehanizama zaštite; korisnici prihvataju
svojstva prototipa kao finalna, iako će biti
izbačena, pa nastaje konflikt sa razvojnim
timom
19
tipične transformacije:
kvadrant 1: kvadrant 2:
određivanje ciljeva, evaluacija alternativa,
alternativa i ograničenja identifikacija i procena rizika
kvadrant 4: kvadrant 3:
planiranje sledeće razvoj i verifikacija putem
iteracije testiranja
23
Plan razvoja
Integracija i
plan testiranja
4 Plan isporuke 3
24
+ -
redukovanje rizika; sistem se ograničena primena; model nije pogodan za
razvija izradom prototipa za manje projekte, već najbolje radi u slučaju
najvažnije karakteristike, velikih i složenih projekata
a onda se po testiranju
prototipa, unose izmene u neophodno znanje o rizicima; potrebna
sistem; tako su rizici najmanji velika veština u radu sa rizicima; uvođenje
rizika uvećava troškove i to uvećanje može
dobra kontrola troškova; pošto da bude veće od troškova izrade sistema
su prototipovi mali, troškovi se
lako procenjuju složenost modela; striktno definisan protokol
razvoja je nekada teško ispoštovati
aktivno učešće korisnika
25
RUP (1)
Rational Software (IBM),1996.g.
RUP (2)
RUP (3)
U svakoj iteraciji, zadaci su organizovani u 9 disciplina:
inženjerske discipline
poslovno modelovanje
zahtevi
analiza i projektovanje
implementacija
testiranje
isporuka
discipline za podršku
konfiguracija i upravljanje izmenama
upravljanje projektom
okruženje
28
RUP (4)
RUP posmatra životni ciklus projekta kroz 4 faze:
faza započinjanja – razumevanje ciljeva i obima projekta,definisanje
funkcionalnosti i slučajeva korišćenja, predlog bar jednog rešenja, razmatranje
troškova i rizika; rezulat faze: kritična tačka u kojoj se odlučuje da li je projekat
izvodljiv i finansijski prihvatljiv (dalje | odustajanje)
RUP (5)
FAZE
Zahtevi
Analiza i
projektovanje
DISCIPLINE
Implementacija
Testiranje
Isporuka
Konfiguracija
i izmene
Upravljanje
projektom
Okruženje
vreme
RUP (6)
+ -
visok nivo prilagodljivosti; RUP neprilagođenost malim projektima
samo preporučuje, ništa ne kod kojih faze započinjanja i razrade
zahteva gube na značaju
+ -
fokusiranje tima na razvoj metod se teško sprovodi
softvera; nema mnogo
dokumentacije i sastanaka nije lako naći dovoljno programera
za rigorozno sprovođenje praksi
prijatna radna atmosfera;
mogućnosti za učenje i klijenti možda ne žele da se uključe
napredovanje, 8-časovno radno u projekat zbog drugih obaveza
vreme, nema nezamenljivih
teško uklopiti karaktere u savršenu
dobar softver po prihvatljivoj celinu
ceni; smanjen rizik jer se sve
izmene prihvataju