Aplikativni softver

Ciljevi kursa

SW

SW
SW
SW

1) Da

studenti:

sagledaju kompleksnost procesa

koje obavlja sistemski softver
naue kako da priu problemu
koga reavaju sa inenjerskog
aspekta, upotrebom APS
naue kako se izaberu i ocene
potreban softverski proizvod
detaljno upoznaju vetine rada
sa predvienim softverskim
paketima

2) Da

studenti:

ovladaju osnovama
hardverske organizacije
raunara

Aplikativni softver

Uvod
Analiza sistema je razlaganje problema na
delove, tj. potprobleme (PP) koje moemo
da razumemo i koje moemo da reimo.
Veze izmeu potproblema su izuzetno
vane, jer mogu biti kljuni faktor u
nalaenju reenja sloenog problema.
PP1
Sinteza reenja je sklapanje
parcijalnih reenja (R) u cilju
nalaenja kompletnog reenja
problema i izbora aplikacije

R1

o
Ak

ji p
o
t
s
po

e
o tr

PROBLEM

PP2

PP3

R2

R3

ba

APLIKATIVNI
APLIKATIVNI
SOFTVER
SOFTVER

REENJE

Aplikativni softver

Pojam aplikativnog softvera

Aplikativni softver ine programi
napravljeni za specifinu svrhu i nisu
u direktnoj vezi sa hardverom. Pri
svom izvravanju oslanjaju se na
sistemski softver, posebno na
operativni sistem. Obino se kupuju
odvojeno od raunarskog hardvera.

Word proc.

Graphics

Spreadsh.

Web app.

Databases

Games

Aplikativni softver
Assembler

Debugger

Sistemski softver obuhvata programe

File Mng.
OS
na niskom nivou (low-level) koji slue
Sistemski softver
za kontrolu operacija nad raunarskom
opremom.
Raunarski hardver

Compilers
Utilities

U nekim sluajevima nema jasne granice izmeu sistemskog i aplikativnog softvera.

Na primer, nema saglasnosti oko toga da li je Internet Explorer web browser deo
Windows OS ili nije.

Aplikativni softver

Izazovi pri izradi softvera (1)

Svaki problem se moe reiti na vie naina. Oni se razlikuju po
efikasnosti, preciznosti, mogunosti modifikovanja, korisnosti,
razumljivosti i drugim osobinama. Stoga upotreba i pisanje softvera
zahteva znanje, ali i domiljatost i vetinu.

Haker

Ume da napie kod koji neto radi nema kvaliteta

Ume da proizvede sveobuhvatan stabilan i

razumljiv kod koji se lako odrava i koji
efikasno radi ono zbog ega je napravljen.
Taj kod predstavlja visoko kvalitetan softver.

Softverski
inenjer

Aplikativni softver

Izazovi pri izradi softvera (2)

I pored toga to proizvoai tee softveru bez mana, u stvarnosti mnogi
softverski proizvodi sadre nedostatke, zato treba obratiti mnogo panje
pri njihovom izboru
Neoekivana upotreba sistema
usled zloupotrebe
usled nestrunog rukovanja

O emu treba
voditi rauna?

Trite diktira brz razvoj softvera

Kvalitet je neophodan

brza isporuka ostavlja malo

vremena za testiranje, pa su greke
ee
ponekad je tee ispraviti uoene
nedostatke, nego napisati
kompletan novi softver

to je nedostatak due
neotkriven, njegovo otklanjanje
vie kota (trokovi ispravljanja
greke u fazi analize su 10 puta
manji od trokova nakon
isporuke).

Aplikativni softver

ta je dobar softver?
Kvalitet softvera zavisi od konteksta posmatranja. Na primer, nedostaci
koji se toleriu u softveru za obradu teskta, ne mogu se prihvatiti u
sistemima gde je faktor bezbednosti izuzetno bitan.

Kvalitet softvera mora se posmatrati na vie naina:

Kvalitet proizvoda
Kvalitet postupka izrade proizvoda
Kvalitet proizvoda u kontekstu poslovnog okruenja u
kome e se koristiti

Aplikativni softver

Kvalitet proizvoda
Karakteristike proizvoda koje odreuju kvalitet zavise od toga
ko analizira softver
Korisnik

Projektant

smatra da je softver kvalitetan ako radi

na odgovarajui nain, lako se ui i
koristi.
Korisnik meri: tip i broj otkaza.

razmatra interne karakteristike

proizvoda i procenjuje nedostatke.
Projektant meri: broj nedostataka u
zahtevima, projektu i kodu.

Modeli kvaliteta
dovode u vezu spoljni pogled korisnika i
unutranji pogled programera na softver.

Aplikativni softver

Boehm-ov model kvaliteta (1)

Boehm-ov model kvaliteta (Boehm i dr., 1978.) je jedan od
najpoznatijih modela. On predstavlja hijerarhiju karakteristika od kojih
svaka doprinosi ukupnom kvalitetu. U model su ukljuena oekivanja
kako korisnika, tako i programera.
Po ovom modelu, kvalitetan softver je onaj koji:
radi ono to korisnik od njega trai,
ispravno i efikasno koristi raunarske resurse,
jednostavan je za uenje i korienje,
dobro je projektovan, dobro kodiran i lako se testira i odrava.

Aplikativni softver

10

Boehm-ov model kvaliteta (2)

Nezavisnost od ureaja

Prenosivost

Samosadrivost
Tanost

Pouzdanost

Potpunost
Robustnost/integritet

Efikasnost

Opta
korisnost

Osnovni
naruilac

Doslednost
Odgovornost

Ljudsko inenjerstvo

Efikasnost ureaja
Pristupanost

Mogunost testiranja

Mogunost
odravanja

Razumljivost

Komunikativnost
Samoopisivost
Strukturisanost

Mogunost izmene

Saetost
itljivost
Proirivost

Aplikativni softver

11

Kvalitet u kontekstu poslovanja

Kvalitet sa aspekta poslovanja se posmatra u zavisnosti od proizvoda i
usluga koje prua poslovni sistem iji je softver sastavni deo. Pri tome
se analizira poslovna vrednost proizvoda.

Tehnika
vrednost proizvoda

Povratak investicije

Poslovna
vrednost proizvoda

........

Krai put do kupca

Kvalitet
proizvoda

Kvalitet
procesa

Produktivnost

Aplikativni softver

12

Uesnici u razvoju softvera i njegovi

korisnici
Kupac je kompanija,
Projektant je
kompanija,
organizacija ili
pojedinac koji pravi
softverski sistem za
kupca.

a
ez
v
ba
o
a
n
r
o
u
ov
b
g
e
U
otr
p
a
Im

Kupac

organizacija ili
pojedinac koji
finansira razvoj
softverskog sistema.

Korisnik je
jedan ili vie
pojedinaca koji
e stvarno
koristiti sistem.

Softverski sistem
Ima potrebu

Projektant

Kupac

Uesnici u projektu mogu istovremeno da imaju vie uloga. Na primer, ako neki
sektor u kompaniji razvija sam softver za svoje potrebe, on je istovremeno i
kupac i korisnik i projektant.

Aplikativni softver

Faze u razvoju softvera (1)

Analiza i definisanje zahteva.

U ovoj fazi se u saradnji sa kupcem utvruju zahtevi koji opisuju

sistem. Pri njihovom definisanju uzimaju se u obzir entiteti, aktivnosti i
ogranienja koja postoje u sistemu, kao i interakcija sistema sa
okruenjem.
Projektovanje (dizajn) sistema.
U cilju zadovoljenja definisanih zahteva, generie se projekat sistema
koji opisuje finkcionalnost sistema i njegov izgled sa stanovita kupca.
Projekat obino sadri snimke ekrana, izvetaje koji e se generisati,
interakciju sistema sa korisnikom, itd.
Projektovanje programa.
Kada kupac odobri projekat sistema, generiu se pojedinani
podprojekti pogodni za programsku realizaciju.
Implementacija (pisanje) programa.

13

Aplikativni softver

14

Faze u razvoju softvera (2)

Testiranje modula.
Nakon pisanja programa, najpre se testiraju individualni delovi koda, tj.
pojedinani moduli.
Testiranje integrisanog sistema.
Moduli se povezuju u celinu i testira se da li moduli dobro rade u spezi sa
drugim modulima.
Zavrno testiranje sistema.
Proverava se da sistem slui svojoj nameni, tj. da li zadovoljava
postavljene zahteve.
Isporuka sistema.
Odravanje.
Tokom upotrebe sistema mogu se uoiti razni problemi koje treba reavati.
Proces razvoja softvera je svaki opis razvoja softvera koji sadri neke od
nabrojanih faza, organizovanih tako da proizvode proveren kod.

Aplikativni softver

15

Modeli procesa razvoja softvera (1)

SPECIFIKACIJA
SPECIFIKACIJA
ZAHTEVA
ZAHTEVA

MODEL
MODEL
PROCESA
PROCESA
RAZVOJA
RAZVOJA

ISPORUENI
ISPORUENI
PROIZVOD
PROIZVOD

Razlozi za modelovanje procesa

Kada grupa opie primenjivani proces projektovanja, opis postaje zajedniko
shvatanje aktivnosti, resursa i ogranienja ukljuenih u razvoj softvera.
Modelovanje pomae u nalaenju nedoslednosti, vikova i izostavljenih
elemenata u samom procesu, to poboljava efikasnost procesa.
Model treba da odraava ciljeve razvoja. Nakon izrade modela projektni tim
ocenjuje aktivnosti sa aspekta njihove usklaenosti sa postavljenim ciljevima.
Svaki proces mora biti napravljen prema situaciji u kojoj e se primenjivati.
Modelovanje procesa pomae da projektni tim utvrdi mesta na kojima su
potreba prilagoavanja.

Aplikativni softver

Modeli procesa razvoja softvera (2)

Kaskadni model (model vodopada)
V model
Fazni razvoj (inkrementalni i iterativni)
Prototipski model
Model specifikacije rada
Transformacioni model
Spiralni model
Agilne metode (ekstremno programiranje)

16

Aplikativni softver

17

Kaskadni model (1)

Kaskadni model ili model vodopada (Royce, 1970.) predstavlja veoma
visok nivo apstrakcije razvojnog procesa ije su faze kaskadno prikazane.
ANALIZA
ANALIZA
ZAHTEVA
ZAHTEVA

Osobine modela
Jedna faza razvoja treba

da se u potpunosti okona
pre poetka sledee faze.

PROJEKTOVANJE
PROJEKTOVANJE
KODIRANJE
KODIRANJE
Za svaku aktivnost procesa

definiu se kritine take i

meuproizvodi, to olakava
praenje stepena gotovosti
projekta.

TESTIRANJE
TESTIRANJE
OPERATIVNI
OPERATIVNIRAD
RAD
I IODRAVANJE
ODRAVANJE

Aplikativni softver

18

Kaskadni model (2)

Prednosti modela

Nedostaci modela

Jednostavnost koja

Ne odraava povratne

olakava pruanje objanjenja

kupcima.

sprege koje zbog greaka i

nepreciznosti zahteva postoje
u stvarnosti.

Dobijanje pune
funkcionalnosti sistema.
Eksplicitno ukazivanje na
meuproizvode koji su
neophodni za zapoinjanje
sledee faze.
Pogodan za sluaj kada je
neophodno odjednom
zameniti stari sistem.

Sistem je obino preveliki

da se uradi u jednoj iteraciji.
Nije pogodan kod znatnih
izmena zahteva.

Aplikativni softver

19

V model (1)
V model (nemako Ministarstvo odbrane, 1992.) je modifikovani kaskadni
model koji pokazuje odnos testiranja i faza analize i projektovanja, inei
eksplicitnim neke povratne sprege koje su skrivene u kaskadnom modelu.
ANALIZA
ANALIZA
ZAHTEVA
ZAHTEVA

Validacija zahteva

OPERATIVNI
OPERATIVNIRAD
RADI I
ODRAVANJE
ODRAVANJE
ZAVRNO
ZAVRNO
TESTIRANJE
TESTIRANJE

PROJEKTOVANJE
PROJEKTOVANJE
SISTEMA
SISTEMA
Verifikacija projekta
PROJEKTOVANJE
PROJEKTOVANJE
PROGRAMA
PROGRAMA
KODIRANJE
KODIRANJE

TESTIRANJE
TESTIRANJE
SISTEMA
SISTEMA

TESTIRANJE
TESTIRANJEDELOVA
DELOVA
I IINTEGRACIJE
INTEGRACIJE

Aplikativni softver

V model (2)
V model se prvenstveno bavi aktivnostima i ispravnim radom sistema, za
razliku od kaskadnog modela koji je usredsreen na dokumente i
meuproizvode.
Kako se koristi
V model?
Testiranje delova, testiranje sistema pri integraciji i testiranje sistema
bave se ispravnou programa i mogu se koristiti za verifikovanje
dizajna programa.
Zavrni test slui za validaciju zahteva, tj. proveru da li su svi zahtevi
potpuno implementirani.
Ako se pronau problemi tokom verifikacije ili validacije, aktivnosti sa
leve strane V modela mogu se ponoviti radi popravke i poboljanja
zahteva, dizajna ili koda, pre nego to se ponove testiranja na desnoj
strani modela.

20

Aplikativni softver

21

Fazni razvoj (1)

KORISNICI PROJEKTNI
TIM

Fazni razvoj je nain projektovanja softvera koji omoguava isporuivanje

sistema u delovima, tako da je korisnicima na raspolaganju jedan deo
funkcija, dok je ostatak funkcija jo u razvoju. Zato obino postoje dva
sistema koji uporedo funkcioniu: produkcioni i razvojni sistem.
Razvojni sistemi

Izrada verzije 1

Izrada verzije 2

Izrada verzije 3
Vreme

Produkcioni sistemi

Upotreba verzije 1

Upotreba verzije 2

Upotreba verzije 3

Produkcioni sistem je onaj koji trenutno koriste naruilac i korisnik. Razvojni sistem
predstavlja sledeu verziju koja se priprema da zameni postojei produkcioni
sistem. Sistemi se obino nazivaju prema rednom broju njihove verzije. Tako,
projektni tim uvek radi na verziji n+1, dok je verzija n u fazi operativnog korienja.

Aplikativni softver

Fazni razvoj (2)

Inkrementalni razvoj podrazumeva da se sistem u skladu sa
specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se
definiu kao funkcionalni podsistemi, tako da se svakoj novoj verziji
prikljuuju nove funkcije. Sistem se nadograuje do potpune
funkcionalnosti.

Iterativni razvoj takoe podrazumeva podelu sistema na podsisteme

prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s
tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema.
Svaka sledea verzija unapreuje prethodnu.

22

Aplikativni softver

23

Fazni razvoj (3)

Pogodnosti inkrementalnog razvoja

Pogodnosti iterativnog razvoja

Operativni podskup funkcija po

zahtevima korisnika moe biti vrlo
brzo isporuen.

Obuka moe da pone sa prvom

verzijom, to je dobro, jer praenje
izvravanja nekih funkcija moe da
sugerie poboljanja u kasnijim
verzijama.

Projektni tim moe da ima

relativno mali broj ljudi.
Progres na projektu je vidljiv (nije
samo u okviru dokumenata).
Mogunost odziva od strane
korisnika kroz ceo ciklus razvoja
vodi ka stabilnijim meurezultatima
i sistemu uopte.

Na trite moe da se izae vrlo

rano, ako se radi o funkcionalnostima
koje nikada ranije nisu bile nuene.
este verzije omoguavaju brzo
otkanjanje nepredvienih problema.
Projektni tim moe da se usredsredi
na razliite oblasti usavravanja u
razliitim verzijama (na pr. korisniki
interfejs, performanse sistema itd.).

Aplikativni softver

24

Prototipski model (1)

Prototipski model se zasniva na izradi prototipova. Ovaj model
omoguava da se kompletan sistem ili delovi sistema brzo konstruiu
radi razjanjenja ili boljeg razumevanja otvorenih pitanja, sve sa ciljem
smanjenja rizika i neodreenosti prilikom projektovanja sistema.
LISTA
REVIZIJA
revizija
prototipa

LISTA
REVIZIJA

pogled korisnika
ili naruioca

PROTOTIPSKI
PROTOTIPSKI
ZAHTEVI
ZAHTEVI
ZAHTEVI SISTEMA
(nekada neformalni
ili nekompletni)

LISTA
REVIZIJA

PROTOTIPSKI
PROTOTIPSKI
PROJEKAT
PROJEKAT

PROTOTIPSKI
PROTOTIPSKI
SISTEM
SISTEM

TEST
TEST
ISPORUENI SISTEM

Prototip je delimino razvijen proizvod koji omoguava

naruiocima i projektantima da ispitaju neke aspekte predloenog
sistema i odlue da li je on pogodan i potreban u sklopu gotovog
proizvoda.

Aplikativni softver

25

Prototipski model (2)

REVIZIJA
ZAHTEVI
SISTEMA

ZAHTEVI
ZAHTEVI

REVIZIJA
PROJEKAT
PROJEKAT

REVIZIJA
SISTEM
SISTEM

TEST
TEST

ISPORUENI
SISTEM

PRIMER RAZVOJA SISTEMA

Definisanje skupa zahteva od strane naruioca i korisnika.

Ispitivanje alternativa (analize moguih ekrana, tabela i dr. izlaza iz
sistema).
Revizija zahteva prema eljama naruioca i korisnika.
Prelazak na fazu projektovanja.
Istraivanje varijanti u projektovanju.
Revidiranje inicialnog dizajna dok svi uesnici ne budu zadovoljni.
Ako se pri razmatranju varijanti dizajna naie na probleme koji potiu
od zahteva, vraa se na ponovnu specifikaciju zahteva.
Kodiranje sistema uz razmatranje varijanti sa moguim iteracijama
kroz zahteve i dizajn.

Aplikativni softver

26

Model specifikacije rada

Model specifikacije rada (Zave, 1984.) omoguava projektnom timu i
naruiocu da u ranim fazama projektovanja ispitaju zahteve sistema i
njihove implikacije, i po potrebi ih koriguju. Zahtevi se pre poetka
projektovanja ocenjuju ili izvravaju na nain koji pokazuje prirodu sistema,
koristei programske pakete. Tako se izbegavaju problemi u kasnijim
fazama koji mogu da nastanu usled neodreenosti vezane za zahteve
sistema. Ovaj model, za razliku od tradicionalnih modela, objedinjuje
funkcionalnost i dizajn i time spaja potrebe naruioca sa implementacijom.
Izvriti i revidirati

SPECIFIKACIJA
SPECIFIKACIJA
RADA
RADA
(orijentisana
(orijentisanaka
ka
problemu)
problemu)

ZAHTEVI SISTEMA

TRANSFORMISANA
TRANSFORMISANA
SPECIFIKACIJA
SPECIFIKACIJA
(orijentisana
(orijentisanaka
ka
implementaciji)
implementaciji)

TEST
TEST
ISPORUENI SISTEM

Aplikativni softver

27

Transformacioni model
Transformacioni model (Balzer, 1981.) pokuava da redukuje
mogunost greke primenom niza transformacija kojima se specifikacija
zahteva pretvara u sistem koji moe da se isporui. Sekvence
transformacija i odluka se uvaju kao formalni zapis u okviru dizajna.
Poreenje sa
zahtevima;
aurirati ako je
potrebno

FORMALNI ZAPIS O RAZVOJU

Niz transformacija
sa obrazloenjima

TRANSFORMACIJA
NN
.........
TRANSFORMACIJA
FORMALNA
FORMALNA

SPECIFIKACIJA
SPECIFIKACIJA
ZAHTEVI SISTEMA

TRANSFORMACIJA
TRANSFORMACIJA22
TRANSFORMACIJA
TRANSFORMACIJA11

TEST
TEST
ISPORUENI SISTEM

Transformacioni model veoma mnogo obeava. Glavna smetnja da bude ire

prihvaen je neophodnost formalne specifikacije da bi transformacije mogle nad
njom da se izvravaju.

Aplikativni softver

28

Spiralni model (1)

Spiralni model (Boehm, 1988.) posmatra razvoj softvera u svetlu prisutnih
rizika tako to kombinuje aktivnosti razvoja sa upravljanjem rizicima. Na
taj nain se postiu manji rizici, a i njihova kontrola je olakana.
Po spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije:
Zahtevi i plan razvoja
Validacija zahteva

1. Opis funkcionisanja sistema

na visokom nivou apstrakcije
2. Definisanje skupa zahteva
3. Generisanje dizajna sistema

Testiranje

Dokument Principi rada

Validacija i verifikacija
dizajna

4. Testiranje

U svakoj iteraciji, radi se analiza rizika koja identifikuje rizike i odreuje razliite
varijante sa aspekta zahteva i ogranienja za njihovo minimiziranje. Zatim se
izradom prototipova verifikuju izvodljivost i pogodnost varijanti pre nego to se
odabere odgovarajua.

Aplikativni softver

29

Spiralni model (2)

anje
Testir

i di
zaj
n
talj
n
De

nt
e

Va
r ij

an
te

3
ija
nt
e
Va
r

i rad
a

ip

a
m
e
r
ra
i p ru
e
v
v
e
e
ft
ht oftv
so
a
Z s
ajn
a
z
ij
c
i
a
d
Vali
D
zahteva
cija i
a
d
i
l
a
V
nje
izajna
d
a
a
j
i
r
c
a
di
verifik
Ko

Pric
ip

tip
oto
Pr

t
to

Plan
implementacije

Plan
inte
i tes gracije
tiran
je

ip

1
start
Zahtevi,
plan razvoja

ot
ot
Pr

Var
ijan
te

a rizik
a2
1
ka
ir zi
a
1
liz
otip
a
t
o
n
r
P
A

o
Pr

ija

a3

Analiz

Plan
razvo
ja

Plan

Ocenjivanje
varijanti i rizika

rizika 4

Analiza riz
ik

nja 3
e

i
n
Orga
enja 2

i
n
a
Org

ja
en
ni
ga
Or

Va
r

Analiza

ja 4
n
e

i
n
Orga

Odreivanje
ciljeva, varijanti i
ogranienja

Razvoj i
testiranje

Aplikativni softver

Agilne metode (1)

Agilne metode (Agile Alliance, 2001.) su nastale kao otpor mnogim
ranijim modelima razvojnog procesa koji su pokuavali da nametnu
neki oblik discipline vezane za osmiljavanje softvera,
dokumentovanje, razvoj i testiranje. Ideja je da se naglasi uloga
fleksibilnosti u spretnom brzom razvoju softvera.
4 principa agilnog razvoja
Za uspenost projekta najvaniji
su kvalitet ljudi koji na njemu
rade i kvalitet njihove saradnje.
Postupci i alati imaju sporedni
znaaj.

Umesto planiranja i praenja

plana, vanije je odgovarati na
promene, jer se ne mogu svi
zahtevi predvideti na poetku
razvoja.

Bolje je uloiti vreme u izradu

softvera koji radi, nego u izradu
sveobuhvatne dokumentacije.

Zajedniki rad sa naruiocem

je vrlo vaan, jer se tako
naruilac ukljuuje u kljune
aspekte razvoja.

30

Aplikativni softver

31

Agilne metode (2)

Primeri agilnih procesa

Ekstremno programiranje, XP (eXtreme Programming), (Beck, 1999.)

predstavlja skup tehnika za omoguavanje kreativnosti projektnog tima uz

minimizovanje prekomernog administriranja.
Crystal (Cockburn, 2002.) predstavlja skup pristupa zasnovanih na injenici da
svaki projekat zahteva razliit skup dogovora i metodologija. Stoga je najvanije
nai nain za jednostavnu i kompaktnu organizaciju projektnog tima kako bi
razvojni proces bio bri i efikasniji.
Scrum (Object Technology, Schwaber & Bedle, 2002.) je model koji se zasniva

na iterativnom razvoju, gde se svaka 30-dnevna iteracija naziva sprint, a slui za

implementiranje zaostalih zahteva najvieg prioriteta. Vie samoorganizovanih i
autonomnih timova paralelno implementira delove proizvoda. Koordinacija se vri
na kratkim dnevnim sastancima (scrum).
Adaptivni razvoj softvera, ASD (Adaptive Software Development) (Highsmith
& Bayer, 2000.) se zasniva na est osnovnih principa: fokusiranju tj. postavljanju
ciljeva, opisu na bazi svojstava, iterativnosti, potovanju utvrenog vremena
isporuke, prihvatanju rizika i tretiranju izmena kao prilagoavanje sistema, a ne
kao greaka.

Aplikativni softver

32

Ekstremno programiranje (1)

Karakteristike agilnosti
Povratna
sprega

Komunikacija

Jednostavnost

Odvanost

Komunikacija podrazumeva neprestanu razmenu informacija izmeu

naruioca i projektnog tima.
Jednostavnost ohrabruje projektni tim da odabere najjednostavniji dizajn
ili implementaciju koji odgovaraju potrebama naruioca.
Odvanost je posveenost blagovremenim i estim isporukama funkcija.
Povratne sprege se ugrauju u razliite aktivnosti tokom procesa
razvoja.

Aplikativni softver

33

Ekstremno programiranje (2)

Igra planiranja. Generiu se mape svih

Programiranje u paru.

buduih verzija (ta sadre i rokovi isporuke).

Faktori XP-a

Male verzije. Funkcije su dekomponovane

na male delove koji se isporuuju, a zatim
proiruju. Koriste se inkrementalni i iterativni
ciklusi.

Metafora. Pojektni tim se usaglaava oko

zajednike vizije rada sistema.

Jednostavan dizajn.Tretiraju se samo

aktuelne potrebe.

Testovi pre kodiranja. Funkcionalne

testove definie naruilac, a izvrava tim.
Testove delova realizuje tim radi verifikacije.

Preraivanje koda. Promena zahteva

primorava tim da preispita postojea reenja.
Ovo je najvei problem.

Kolektivna svojina. Svaki uesnik moe

da izmeni bilo koji deo sistema, dok je on u fazi
razvoja.

Neprekidna integracija. Rade se dnevne

ili satne isporuke. Naglasak na malim
inkrementima poboljanja.

Odriv korak. Umorni ljudi vie gree.

Sugerie se 40 sati nedeljno rada. Ako to nije
dovoljno, neto nije u redu (rokovi ili resursi).

Naruilac raspoloiv na terenu.

Standardi kodiranja. Insistira se na njima
zbog boljeg razumevanja u timu.

Aplikativni softver

34

Alati i tehnike za modelovanje

Izbor alata i tehnika za modelovanje zavisi od sadraja modela. Postoje
razliite vrste notacija koje se mogu koristiti:
tekstualne, u kojima se procesi iskazuju kao funkcije,
grafike, u kojima se procesi prikazuju u formi hijerarhije pravougaonika i
strelica,
kombinovane, koje kombinuju slike, tekst i grafiki prikaz sa tabelama.
Poeljne osobine alata i tehnika za modelovanje (Curtis, Kellner & Over, 1992.):
1. Da ljudima olakaju razumevanje i meusobnu komunikaciju.
2. Da prue podrku poboljanju procesa. Tehnika treba da identifikuje komponente razvoja i
odravanja, omogui viekratnu upotrebljivost procesa i podprocesa, kao i poreenje
alternativa.
3. Da prue podrku upravljanju procesom. Tehnika treba da omogui planiranje i
prognoziranje, nadgledanje i upravljanje procesom, kao i merenje kljunih karakteristika
procesa.
4. Da obezbede automatsko voenje tokom izvravanja procesa. Tehnika treba da definie
okruenje za razvoj softvera, obezbedi smernice i sugestije i sauva viekratno
upotrebljive reprezentacije procesa za kasniju upotrebu.
5. Da prue podrku automatskom izvravanju procesa. Tehnika treba da automatizuje
proces u celosti ili delimino.