Visoka HT strukovnih studija u Kruevcu

Odsek za informatiku i raunarstvo

RAZVOJ INFORMACIONIH
SISTEMA

Doc. Dr Bratislav Blagojevi

Sloenost razvoja IS i modeli ivotnog ciklusa IS

Sloenost razvoja IS savladava se:

Razbijanjem celokupnog razvoja na faze nain

razbijanja na faze se naziva Model ivotnog
ciklusa IS
Dekompozicijom samog sistema, odnosno
definisanjem arhitekture sistema
Funkcionalna (strukturna) ili objektana dekompozicija
Dvoslojna, troslojna ili vieslojna arhitektura
Modeli ivotnog ciklusa IS
Tri osnovne grupe (principa):
Konvencionalni razvoj: striktno praenje svih pravila
inenjerskog pristupa razvoju IS.

Brzi razvoj: to pre doi do kakvog takvog reenja, pa

ga onda usavravati

Formalni (transformacioni) razoj definisanje formalnih

modela i postupaka razvoja formalna transformacija
formalne specifikacije IS u implementaciju.

KONKRETNE MOTODE I PRISTUPI NE SPADAJU

STRIKTNO NI U JEDNU GRUPU KOMBINUJU
DVA ILI SVA TRI PRINCIPA.
Konvencionalni razvoj

Konvencionalni vodopad ivotni ciklus

i sve njegove modifikacije:

Fontana model
Spralni model
(Iterativno) Inkrementalni pristup
KONVENCIONALNI "VODOPAD" IVOTNI CIKLUS
 KONVENCIONALNI IVOTNI CIKLUS
STRUKURNI PRISTUP

1. PLANIRANJE BSP METODA

2. ANALIZA I SPECIFIKACIJA ZAHTEVA
STRUKTURNA SISTEMSKA ANALIZA SSA
NALAENJE SKUPA ATOMSKIH
FUNDAMENTALNIH FUNKCIJA SISTEMA,
NJIHOVIH ULAZA I IZLAZA
OPIS ULAZA, IZLAZA I SKLADITA PREKO
RENIKA SSA.
OPIS POJEDINANIH ATOMSKIH FUNKCIJA
PREKO PSEUDO KODA
 KONVENCIONALNI IVOTNI CIKLUS
STRUKURNI PRISTUP
2. PROJEKTOVANJE
Logiko projektovanje
Izgradnja odgovarajueg modela podataka (model
objekti-veze)
Transformacija modela objekti veze u normalizovan
relacioni model.
Projektovanje strukturnih programa

Fiziko projektovanje
Fiziko projektovanje baza podataka
Projektovanje korisnikog interfejsa
Dodavanje fiikih elemenata strukturnim
programima.
 KONVENCIONALNI IVOTNI CIKLUS
STRUKURNI PRISTUP

4. Implementacija
Kodiranje u nekom strukturnom jeziku i testiranje ili
Primena generatora aplikacija (jezika etvrte generacije)
Relacione baze podataka i dvoslojna klijent-server
arhitektura.
 KONVENCIONALNI IVOTNI CIKLUS
OBJEKTNI PRISTUP

1. PLANIRANJE Nita specifino

1. ANALIZA I SPECIFIKACIJA ZAHTEVA

Izrada Sluajeva korienja: Dijagram sluajeva
korienja i verbalni opis svakog SK
Izrada sistemskih dijsgrama sekvenci
 Opis SK:
1. Uesnici
2. Namena
3. Kratak opis
4. Pre i Post uslovi
5. Opis osnovnog toka
dogaaja
6. Opis alternativnog
toka dogaaja

SISTEMSKI DIJAGRAM
SEKVENCI ZA SLUAJ
KORIENJA PRODAJA
KONVENCIONALNI IVOTNI CIKLUS
OBJEKTNI PRISTUP
3. PROJEKTOVANJE
Logiko projektovanje
Izrada konceptualnog modela (dijagrama klasa
bez operacija)
Izgradnja dijagrama sekvenci, dijagrama
kolaboracije ili dijagrama aktivnosti za opis
dinamike sistema (logike aplikacije)
Izgradnja kompletnog logikog modela sistema
(dijagram klasa sa operacijama definisanim
preko dijagrama sekvenci kolaboracije ili
aktivnosti)
KONVENCIONALNI IVOTNI CIKLUS
OBJEKTNI PRISTUP

4. PROJEKTOVANJE
Fiziko projektovanje (zavisno od
konkretnog okruenja)
Projektovanje baze podataka
Projektovanje korisnikog interfejsa
Dodavanje novih klasa na osnovu
odgovarajuih uzora (pattern-a): MVC patern,
Perzistentni brokeri i mnogi drugi
Izgradnja kompletnog fizikog modela sistema
KONVENCIONALNI IVOTNI CIKLUS
OBJEKTNI PRISTUP

5. IMLEMENTACIJA
Rasporeivanje delova modela na pojedine
elemente vieslojne arhitekture,
Transformacija fizikog modela u konkretno
implenemtaciono okruenje
Dodatno kodiranje
Testiranje
KONVENCIONALNI IVOTNI CIKLUS
NEDOSTACI

Problemi razvoja:
Teko je, gotovo nemogue utvrditi sve zahteve na
poetku projekta i potpuno tano;
Projekti su obino dugotrajni t teko je
skrupulozno sprovesti metodologiju do kraja
Do prve verzije sistema (koja bi trebalo da bude
konana) dolazi se veoma sporo. Zaksneo
povratni uticaj korisnika
Veoma obimna dokumentacija za velike projekte.
KONVENCIONALNI IVOTNI CIKLUS
NEDOSTACI

Problemi odravanja:
Veoma skupo odravanje
Dvostruko odravanje, odravanje koda i odravanje
projektne dokumentacije
U sluaju izmene zahteva treba proi ponovo kroz sve
faze projektaovanja i izvriti izmene. To se obino ne
radi, pa na kraju, i pored ogromnog truda imamo
nesaglasnost koda i projektne dokumentacije.

SVI OVI NEDOSTACI I ZNATNO MANJOJ MERI DOLAZE

DO IZRAAJA U OBJEKTNIM PRISTUPIMA!
Modifikacije konvencionalnog ivotnog
ciklusa: Spiralni model

Analiza i Analiza izvodljivosti

specifikacija zahteva

Evaluacija i Izrada prototipa

Planiranje sledeeg
ciklusa

Prototipovi slie za:

Validaciju kor. Zahteva
Experimenat sa implementacionim okruenjem
Modifikacije konvencionalnog ivotnog ciklusa:
Inkrementalni model

Prethodi podela na podsisteme, odnosno definisanje

polazne arhitekture sistema
Modifikacije konvencionalnog ivotnog ciklusa:
Iterativno-inkrementalni razvoj
(Unified Software Development process)
Brzi (rapid, agile) razvoj
U ovom pristupu, umesto da se trudimo da
detaljnom analizom pokuamo da utvrdimo
potpune zahteve korisnika, pokuavamo da
razvijemo sistem sa nekompletno definisanim
zahtevima.

Prototipski razvoj- rapid prototyping

Agile Software Development

Prototipski razvoj

Prototipovi aplikacija a ne celog sistema

Prethodno definisanje arhitekture sistema: skupa aplikacija i modela
(baze) podataka
Postojanje alata za izradu prototipova, prototip mora brzo i jeftino da
bude uraen (Jezici etvrte generacije)
Loa dokumentacija, teko odravanje ovako izgraenog sistema
Agile Software Development

Cilj je kod koji radi, a ne perfektna

dokumentacija.
Vie se vodi rauna o organizaciji ljudi koji rade
na projektu, a manje o metodologijama i alatima
za razvoj.
Najpopularniji Agile Development pristup je XP
(Extreme Programming).
XP je projektovan za male timove koji treba da
brzo razviju neki softver u okruenju sa stalno
promenljivim zahtevima. U takvom okruenju
konvencionalni ivotni ciklus bi bio neupotrebljiv.
 XP (Extreme Programming)
XP se zasniva na sledeim principima:
1. Planiranje. Korisnik daje procenu dobiti za
realizaciju pojedinih zahteva, a programeri
odgovarajuu procenu trokova i na osnovu toga se
odreuju zahtevi koji e biti realizovani odmah i
zatevi koji e biti odloeni.
2. Jednostavna realizacija. XP tim proizvodi
jednostavne sisteme i a zatim ih uestalo menja i
poboljava
3. Metafora. XP timovi koriste zajedniki sistem
imena i zajedniuki opis sistema.
4. Jednostavno projektovanje. XP podrazumeva da
se svaki program pravi na najednostavniji nain koji
zadovoljava zahteve.
XP (Extreme Programming)
5. Testiranje. Stalno se vri validacija sistema. Prvo se
definie test, a onda se razvija softver koji treba da
ga zadovolji. Korisnik definie test za prihvatanje
sistema.
6. Refactoring. Softver se stalno poboljava, s tim da
se ouva njegova jednostavnost. Ne prave se
duplikati.
7. Programiranje u parovima. Dva programera
razvijaju jedan kod kontroliui jedan drugog. Rade
na istoj maini. Pokazuje se da ovakav razvoja daje
znatno bolje rezultate od individualnog razvoja.
8. Kolektivno vlasnitvo. Ceo kod pripada svim
programerima. Kad god je potrebna neka izmena
bilo ko moe da je izvri.
 XP (Extreme Programming)
9. Stalna integracija. Integracija razvijenih delova
radi se vie puta dnevno. To zahteva uee
svih programera i ubrzava proces razvoja.
10. 40-asovna radna nedelja. Prekovremeni rad
je izuzetak. Programeri treba da budu odmorni,
zdravi i produktivni.
11. Stalno prisustvo korisnika. Znaajno se
poboljava komunikacija, smanjuje potreba za
prepiskom i dokumentacijom.
12. Standardno kodiranje. Svi programeri treba
da piu kod na isti, standardni, nain da bi se
principi XP-a mogli da sprovedu.
 Formalni (transformacioni) razoj

Izvrni kod se dobija iskljuivo transformacijom formalne

specifikacije u implementaciju
Ovakav pristup omoguuje jednostavnu promenu
implementacionog okruenja (platforme) - jednostavno
adaptivno odravanje
Perfektivno odravanje sistema se znaajno
pojednostavljuje nema dvostrukog odravanja
(dokumentacije i koda)
Formalni (transformacioni) razoj

Koji se jezici (modeli) koriste za formalnu

specifikaciju?
Kako se vri transformacija formalne specifikacije u
radni sistem (kod)?
Kako se vri formalna inverzna transformacija?
 Formalni (transformacioni) razoj
U vreme kada je definisan transformacioni pristup
je bio mogu samo za veoma specifine i
jednostavne sisteme za koje ke bilo mogue
definisti formalni specifikacioni jezik i
odgovarajuu transformaciju
CASE alati delimino podravaju ovakav pristup
(Model objekti-veze kao jezik za specifikaciju i
SQL ko radni sistem, na primer)
Osnovna ideja, znaajne prednosti ovoga
pristupa, sve bolji jezici (modeli) za specifikaciju i
CASE alati stalno unapreuju transformacioni
pristup razvoju IS.
Transformacioni razvoj:Cleanroom engineering

Cleanroom engineering koji je predloio IBM (druga

polovina 80-tih) je rigorozni metod razvoja u kome
greke nisu dozvoljene (za razliku od drugih pristupa
koji se zasnivaju na trial-and-error pristupima).

Cleanroom engineering polazi od injenice da su

programi nain realizacije matematikih funkcija. Za
specifikaciju programa neophodno je definisati funkciju
koja u potpunosti opisuje ponaanje koje se od
programa zahteva. Nalaenje procedure koja realizuje
tu funkciju je osnova razvoja softvera.
Transformacioni razvoj:
Cleanroom engineering
 Transformacioni razvoj:Sistemsko-teorijski
ivotni ciklus FON kraj prolog veka
1. Identifikacija sistema: nalaenje funkcionalnog
modela sistema, na osnovu nekog posmatranja
(analize):
S:Fa : T x U ---> Y, a e A}
2. Realizacija sistema: nalaenje modela sistema
u izabranom prostoru stanja.
: U x X X (Funkcija prelaza stanja)
= U x X Y (Izlazna transformacija)
3. Implementacija: kodiranje i testiranje
 Transformacioni razvoj:Sistemsko-teorijski
ivotni ciklus FON kraj prolog veka
Identifikacija sistema skup funkcija (bilo koji
alat za funkcionalnu specifikaciju sistema,
Dijagrami tokova podataka, najbolje, a mogu i
Sluajevi korienja)
Realizacija sistema:
Izbor najpovoljnijeg modela za realizaciju funkcija
Nalaenje minimalne realizacije u okviru izabranog
modela.
SISTEMSKO-TEORIJSKI IVOTNI CIKLUS

Ponekad se u Sistemsko-teorijski ivotni

ciklus daodaje i etvrta faza:

4. Sinteza upravljanja

ime se realizuje upravljaka funkcija IS,

odnosno MIS (Management Information
System)
UPRAVLJAKI INFORMACIONI SISTEMI
Samosinhronzovani skup
Aplikacija

Sinhronizacija preko
podataka u bazi

Omogueno upravljanje
pojedinanim funkcijama

Savremeni menadment je
orjentisan prema upravljanju
procesima koji predstavljaju
orkestraciju funkcija u cilju
obavljanja nekog zadatka.
 Upravljanje procesima- Modeli procesa
Danas postoji gotovo opta saglasnost da je upravljanje
meusobno povezanim i meusobno zavisnim poslovnim
procesima ("process centered management approach")
osnova uspenog funkcionisanja bilo koje organizacije
UPRAVLJAKI INFORMACIONI SISTEMI
Praenje realizacije
nekog ugovora,
Praenje realizacije
narudbenice
kupca,
Sprovoenje nekog
upravnog postupka
i slino.
Odnos poslovnih procesa i poslovnih funkcija

Upravljaki mehanizam sadri:

Model poslovnih procesa
Model organizaciono-tehnolokog okruenja
Operativni plan obavljanja poslovnih procesa
Operacije za upravljanje: lansiranje u suspedndovanje posla,
preraspodela izvrioca i slino
Transformacioni razvoj:Modelom
voeni razvoj
Model Driven Architecture (MDA) koju je
2001 predloila Object Management Group
je an approach to using models in
software development. Zato je bolje
koristiti prevod Modelom voeni razvoj
mego Modelom voene arhitekture.
Pojam arhitektura se vezuje za injenicu da
se preko asptraktnih modela (PIM) moe da
ostvari inteoperabilnost heterogenih sistema.
Modelom voeni razvoj
Computation Independent Model CIM model
odgovarajueg domena, zajedniki renik za
korisnika i projektanta

Platform Independent Model PIM.

Model IS nezavisan od
implementacione platforme.
Specifikacija sistema

Platform Description Model PDM

Model implementacione platforme

Platform Specific Model- PSM

Model IS implementiran u datom
okruenju.
Modelom voeni razvoj

Modelom voeni razvoj omoguava:

Specifikaciju sistema nezavisnu od bilo kakve
implementacije;
Specifikaciju platforme;
Izbor platforme za implementaciju
specifikaovanog sistema;
Transformaciju specifikacije sistema u
izabranu platformu.