Modeli_procesa

Modeli procesa razvoja programskog proizvoda dr.sc. Tihana Galinac Grbac

Ciljevi  Znati

što je model životnog ciklusa programskog proizvoda osnovne faze općeg modela životnog ciklusa programskog proizvoda

 Razumijeti

 Raspoznavati

osnovne modele životnog ciklusa programskog proizvoda i znati kada su primjenjivi

Sadržaj  Definicija

modela procesa životnog ciklusa prog. proizvoda  Opći model životnog ciklusa prog. proizv.  Modeli procesa životnog ciklusa programskog proizvoda  Vodopadni

model

 Prototyping  Inkrementalni

model  Spiralni model  Formalni razvoj  Modeli zasnovani na ponovnoj upotrebljivosti  Rapidni modeli razvoja

Proces i model procesa  Prema

International Organization for Standardization (ISO): skup međusobno povezanih aktivnosti kojima se ostvaruje pretvorba ulaza u izlaz.  Procesi životnog ciklusa programskog proizvoda definiraju se kao skup procesa, aktivnosti i poslova koje izvode ljudi da bi razvili i održavali programski proizvod.  Proces je

 Modeli

procesa

slične naravi koji su grupirani zajedno u model.  Apstraktna reprezentacija procesa koja opisuje proces iz određene perspektive.  Procesi

Modeli procesa životnog ciklusa programskog proizvoda (ž.c.p.p.)  Okvir

ili pojednostavljen opis procesa, aktivnosti i poslova koji se obavljaju u ž.c.p.p. za razvoj, izvođenje i održavanje, od definiranja zahtjeva do povlačenja programskog proizvoda iz uporabe.  Opisuju faze ž.c.p.p. i redosljed njihova izvođenja.  Postoji mnogo razli čitih modela procesa ž.c.p.p. i njihova implementacija varira od kompanije do kompanije ali svi imaju zajedničke uzorke (pattern).



model



Opći model Inženjerstvo zahtjeva

Dizajn Implementacija Test



Svaka faza proizvodi isporuke koje su potrebne za sljedeću fazu ž.c.  Korisnički zahtjevi se formaliziraju u zahtjeve kojima se može započeti razvoj programskog proizvoda  Zahtjevi se prevode u dizajn dokumentaciju u fazi dizajna  Dizajn dokumentacija se koristi za kodiranje u fazi implementacije  Programski proizvod nastao u fazi implementacije se testira u fazi testiranja



model



Primjeri modela procesa S

S

T

S

I

D

D I T

Vodopadni model 

Sljed kaskada



Postoji puno verzija vodopadnog modela, sve se sastoje od osnovnih zadataka a modeli se razlikuju prema načinu podjele zadataka u faze

Studija izvedivosti Inženjerstvo zahtjeva Dizajn Implementacija Testiranje

Nedostatci vodopadnog modela  Nefleksibilan

na promjene zahtjeva pa teško udovoljava željama korisnika i uvjetima okoline, sustav dođe u fazu testiranja događa se veliki prasak – veliki broj neispravnosti uzrokuje kašnjenja s testiranjem i dodatne troškove,

 Kad

 Korisnik

nema informacije o sustavu za vrijeme trajanja cijelog procesa razvoja - nepovjerenje, jedino u slučajevima kada su zahtjevi dobro definirani i neće se mijenjati

 Primjeren

Prototyping Inženjerstvo zahtjeva

Dizajn

Implementacija

Test

Faze prototipiranja sustava

Dizajn

Implementacija

Test

Održavanje Faze razvoja sustava

Prednosti i nedostatci prototyping modela  Prednosti

sustava su aktivno uključeni u razvoj  Konačni sustav je jednostavniji za korištenje i održavanje  Korisnički zahtjevi su bolje provedeni  Konačni sustav ima manje nepotrebnih mogućnosti  Rana identifikacija problema  Veća kvaliteta dizajna  Korisnici

 Nedostatci

konačnog sustava  Konačni sustav ima manje mogućnosti  Konačni sustav je kompleksan za održavanje  Manja kvaliteta dizajna  Zahtjeva iskusne stručnjake  Performanse

Prototyping - primjena se ne zna točno što se želi od sustava, a trenutna situacija je nezadovoljavaju ća  Za definiciju sustava i specifikaciju zahtjeva prije velikih investicija u njegovu realizaciju  Definicija zahtjeva kod sustava s fokusom na korisničko sučelje  Kod primjene modela uslijed česte promjene sustava i nedovoljnoj brizi o kvaliteti potrebno je paziti na  Kada

 Svjesnost

korisnika i dizajnera o nedostatcima modela  Planiranje i nadzor otežani

Inkrementalni model  Motivacija

S

nastanka inkrementalnog modela je da se korisniku isporučuje sustav u manjim cjelinama koje mogu raditi samostalno  Opći proces se odvija u iteracijama, tako da svaka iteracija procesa isporući skup samostalnih cjelina korisniku  Sustav se inkrementalno izgrađuje i svaki inkrement je samostalna radna cjelina sustava

D I T

Inkrement 1 D I T

Inkrement 2

D I T

Inkrementalni model – prednosti i nedostatci  Prednost

ovog modela nad vodopadnim

 Rana

isporuka manjih cjelina (koje rade) korisniku  Rani uvid korisnika u stanje razvoja sustava  Aktivno uključivanje korisnika  Zahtjevi

su definirani u jedinoj fazi koja nije dio iterativnog procesa ali omogu ćena je jednostavnija njihova promjena  Isporuke radnih dijelova sustava (dijelova funkcionalnosti) čime se postiže povjerenje korisnika i traži rana povratna korisni čka informacija  Optimalan za velike organizacije razvoja koje teško ispunjavaju uvjete fleksibilnosti

Spiralni model Spiralni zato jer slika koja prikazuje T S model pokazuje po četak u sredini i kontinuirano se ponovno prolazi kroz sve osnovne aktivnosti komunikacije s korisnikom, planiranje, analiza rizika, I D inženjerstvo, izgradnja i isporuka, te evaluacija korisnika.  Aktivna suradnja s korisnikom za vrijeme trajanja cijelog procesa, u svakoj iteraciji korisnik je uklju čen tako da dodatno specificira zahtjeve 

Spiralni model – prednosti i nedostatci  Potpuno

fleksibilan na promjene

 Problemi

kod organizacije razvoja usljed fleksibilnosti koje pruža korisniku: proces

je slabo vidljiv,

nestabilan zahtjevi sustav nije

i nepredvidiv,

su nestabilni,

slabo strukturiran,

primjeren za velike organizacije razvoja i sustave koji se evolucijski razvijaju

Formalan razvoj programskog proizvoda na transformaciji matematički formulirane specifikacije zahtjeva u različite forme, pa sve do konačno izodljivog koda (executabile code).

 Zasnovan

 Svakom

transformacijom se istražuje ispravnost prema specifikaciji

Definiranje zahtjeva

Formalna specifikacija

Formalna transfomacija

Integracija i testiranje sustava

Formalni razvoj pp - problemi  Potreba

za specijaliziranim vještinama i dodatnim obukama osoblja kako bi se implementirala

 Problemi

s formalnom specifikacijom nekih aspekata sustava

 Problemi

kod održavanja tako dobivenog programskog proizvoda

Modeli zasnovani na konceptu ponovne upotrebljivosti (reusability)    

COTS (Commercial-off-the-shelf) model Zasnovan na principu lego kockica Osnovna ideja je sustavno korištenje postoje ćih komponenti Osnovne faze procesa su:  Analiza

komponenti,  Prilagodba zahtjeva  Dizajn sustava s ponovnom upotrebljivosti postoje ćih komponenti  Razvoj i integracija 



Modelu je pridodana velika pozornost u posljednjem desetljeću ali još uvijek nedovoljno prikupljenog iskustva iz industrije Potrebna je velika baza kako bi se mogle ponovno upotrijebiti neke komponente

Rapidni modeli razvoja  Svojstveni

razvojnom okruženju naglih i brzih (rapid) promjena (ekonomski uvjeti, konkurencija)

 Nastale

kao odgovor na prethodne jako procesno i planski orijentirane pristupe razvoju

 Osnovni Brzi

moto:

razvoj korisnog programskog proizvoda

Osnovne karakteristike rapidnih modela razvoja  

Preklapanje faza inženjerstva zahtjeva, dizajna i implementacije Dokumentacija postoji ali je svedena na nužnosti: Ne postoji detaljna specifikacija zahtjeva, samo najosnovniji korisnički zahtjevi  dizajn dokumentacija je minimizirana, obi čno generirana automatski 



Inkrementalni razvoj 



Mali paketi isporuke 



Sustav se proizvodi kao serija verzija od kojih je svaka radna, Nove funkcionalnosti koje se isporu čuju u inkrementima su mali korisnički paketi

Česte isporuke 

Česte isporuke korisniku, tipi čno svaka 2 do 3 tjedna

Osnovne karakteristike rapidnih modela razvoja (nastavak) 

Česte integracije sustava 



Izbjegavanje velikog praska (big bang), velika funkcionalnost pa pri integraciji dolazi do puno problema koje je onda teško i skupo za riješiti

Uključenost korisnika/naru čioca Korisnik je aktivno uklju čen u razvoj tako što specificira i procjenjuje svaku verziju sustava.  Time se postiže rani odaziv korisnika 



Fleksibilnost na promjene: 



Preferira se neformalna komunikacija, 



promjene na svaku verziju mogu se dodatno specificirati kao zahtjevi na neku budu ću verziju čim manje formalnih dokumentiranih sastanaka

Mali radni timovi bez unaprijed definiranih zadatka

Agile manifest (2001)  Individue

i njihove interakcije su važnije od procesa i alata  Programski proizvod koji radi važniji je od svekolike dokumentacije  Međudjelovanje s korisnikom/naručiteljem je važnije od specificiranja i pregovaranja ugovora  Prilagođavanje promjenama je važnije od praćenja plana

Aktivna uključenost svih sudionika

Karakteristični predstavnici: Agile metode  eXtreme

Programming (Back, 1999)

 Scrum

(Schwaber, Beedle 2001)

 Crystal

(Cockburn, 2001)

 Adaptive

Software Development (Highsmith, 2000)

 Feature

Driven Development (Palmer, Felsing, 2002)

Procesni i planski orijentirani modeli s agilnim karakteristikama  Usljed

objavljivanja uspješnih rezultata primjenom Agile metoda sve se češće integriraju u ostale modele razvoja postojeći

sljedni modeli nisu dovoljno fleksibilni na globalne rapidne uvjete razvoja (ekonomske promjene)

nasljeđeni iz klasičnih slijednih s preuzetim nekim osnovnim principima Agile metoda  Primjena:  Modeli

češće se koristi u svim vrstama projekata, a količina Agile pristupa ovisna je o sustavu koji se razvija (zahtjevi na pouzdanost, sigurnost, evolucijski sustavi), timu koji razvija sustav (globalno distribuirani).

 Sve

Procesni i planski orijentirani modeli s agilnim karakteristikama  Osnovni

problemi

li su sustavi razvijani koristeći Agile metode jednostavni za održavanje?  Da li su takvi modeli prigodni za sustave koji se evolucijski razvijaju?  Koja je optimalna količina dokumentacije potrebna?  Koliko česte ispruke su realne (2 tjedna)?  Da li je primjena Agile metoda učinkovita kod velikih i globalno distribuiranih timova?  Koje tehnologije su dostupne/primjenjive za primjenu Agile metoda?  Da li je sposobnost dizajnera i programera zadovoljavajuća za primjenu Agile metoda?  Da

Modeli_procesa

Recommend Documents