„MODEL VODOPADA U RAZVOJU VELIKIH RAZMJERA“

STUDIJA SLUČAJA

Predmet: Modeliranje poslovnih procesa

Mentor: Habul dr. Aida Studenti: Ajla Ćeman 4860-73627
Selma Hodžić 4864-7398
Ajša Čosić 4925-73272
Minela Selman 4572
Studij: Menadžment
Smjer: Menadžment i informacione tehnologije

Sarajevo, novembar 2020

SAŽETAK

Razvoj vodopada je i dalje široko korišten način rada u kompanijama za razvoj softvera.
Prijavljeni su mnogi problemi vezani za model. Najčešće prihvaćeni problemi su npr. da se suoče
s promjenama i da se pogreške često otkrivaju prekasno u procesu razvoja softvera. Međutim,
mnogi problemi pomenuti u literaturi zasnovani su na vjerovanjima i iskustvima, a ne na
empirijskim dokazima. Da bismo riješili ovaj istražni jaz, upoređujemo probleme u literaturi sa
rezultatima studije slučaja u Ericsson AB u Švedskoj, istražujući pitanja u modelu vodopada.
Studija slučaja ima za cilj potvrđivanje ili kontradiktornost uvjerenja o tome koji su problemi u
razvoju vodopada kroz empirijska istraživanja.
 SADRŽAJ

1. Uvod.........................................................................................................................................4
2. Povezani rad.............................................................................................................................5
3. Model vodopada u kompaniji...................................................................................................6
4. Dizajn studije slučaja................................................................................................................9
4.1. Istraživačka pitanja...........................................................................................................9
4.2. Odabir slučaja i jedinice analize.......................................................................................9
4.3. Postupci prikupljanja podataka.......................................................................................10
4.4. Pristup analizi podataka..................................................................................................12
4.5. Prijetnje valjanosti...............................................................................................................13
5. Kvalitativna analiza podataka................................................................................................14
5.1. A problemi..........................................................................................................................14
5.2. B problemi...........................................................................................................................15
5.3. C problemi...........................................................................................................................15
5.4. D problemi..........................................................................................................................16
6. Kvantitativna analiza podataka..............................................................................................17
7. Uporedna analiza slučaja i SotA............................................................................................17
8. Zaključak................................................................................................................................19
LITERATURA..............................................................................................................................21
 1. Uvod

Prva publikacija o modelu vodopada upisana je u članak Walter Royce 1970. godine (1). U
literaturi se čini da postoji sporazum o problemima povezanim s korištenjem modela vodopada.
Problemi su (između ostalog) da se model ne može dobro nositi s promjenama, stvara puno
prepravki i dovodi do nepredvidive kvalitete softvera zbog kasnih testiranja (2). Uprkos
identificiranim problemima, model se i dalje koristi u softverskoj industriji, a neki su istraživači
čak ubjeđeni da će se koristiti mnogo duži vremenski period (3). U istraživanju se mogu vidjeti
sljedeći trendovi. Prvo, izgleda da model nije interesantan za istraživače da se usredotoče jer se
smatra staromodnim. Umjesto toga, nedavne studije imaju mnogo više fokusa na agilni i
inkrementalni razvoj. Drugo, postoji vrlo malo empirijskog istraživanja koja potvrđuju uvjerenja
o modelu vodopada. Kako bismo identifikovali dokaze empirijskog istraživanja modela
vodopada, izvršili smo sljedeću pretragu na Inspec & Compendex:

- "model vodopada" ili "razvoj vodopada" i "empirijsku" ili "studiju slučaja" ili "industrijsku".

Inspec & Compendex je odabran jer integriše mnoge baze podataka u cijelom tekstu u
računarima i stoga se smatra dobrom polaznom tačkom. Pretraga je rezultirala u 33 publikacije u
kojima nijedna od publikacija nije bila izričito fokusirana na proučavanje modela vodopada u
industrijskom okruženju. Dakle, većina problema prijavljenih na modelu vodopada uglavnom se
zasniva na uvjerenjima i iskustvima istraživača. Shodno tome, radi pružanja značajnih dokaza o
korisnosti modela vodopada u industriji potrebno je empirijsko istraživanje. Evaluiranje
korisnosti empirijski pomaže donošenju odluka o tome da li će model koristiti u specifičnom
kontekstu (ovdje je razvoj velikih razmjera).
Da bismo se suočili sa ovim istraživačkim jazom, vodili smo studiju slučaja koja se fokusirala na
identifikaciju problema u razvoju vodopada i upoređivala ih sa onim što je rečeno u literaturi.
Nadalje, pitanja koja su se identificirala temelje se na njihovoj kritičnosti. Slučaj koji se
proučava je razvoj stranice Ericsson AB, Švedska. Model vodopada korišten je u kompaniji već
nekoliko godina. Studija slučaja je sprovedena u skladu sa uputstvima koje je dao Yin (4).
Studija slučaja daje sljedeće doprinose istraživanju razvoja vodopada:
1) Ilustracija implementacije vodopada u praksi u okviru velikog industrijskog razvoja softvera,
2) Identifikacija pitanja koja se odnose na model vodopada i njihovu prioritizaciju koja pokazuje
najvažnija pitanja
3) Upoređivanje rezultata studije slučaja sa najsavremenijim tehnologijama (SotA).

Ostatak ovog rada je strukturiran na sljedeći način: Odeljak 2 daje pregled povezanih radova.
Nakon toga, odeljak 3 ilustruje model vodopada koji se koristi u preduzeću. Odjeljak 4
predstavlja nacrt studije slučaja. Analiza prikupljenih podataka data je u odjeljku 5 (kvalitativna
analiza) i odjeljku 6 (kvantitativna analiza). Odjeljak 7 podrazumijeva upoređivanje rezultata i
stanja tehnike. Odjeljak 8 zaključuje rad.

2. Povezani rad

Literatura identificira niz problema vezanih za model vodopada. Pregled problema

identifikovanih u literaturi prikazan je u Tabeli 1. Pored identifikovanih članaka razmatrali smo
knjige o prednostima i manama modela vodopada. Model vodopada povezan je sa visokim
troškovima i efektima (2) (5). To jest, zahtijeva odobrenje mnogih dokumenata, promjene su
skupe za implementaciju, iteracije zahtijevaju puno posla i prerađivanja, a problemi se obično
guraju u kasnije faze (2). Nekoliko studija je izričito fokusirano na model vodopada i određeni su
razlozi za neuspjeh pristupa vodopada. Jedan od razloga koji pominje nekoliko studija je
upravljanje velikim obimom, tj. zahtjevima se ne može dobro upravljati, te je to identificirano
kao glavni razlog za neuspjeh (7) (8) (9). Posljedice su bile da se trenutne potrebe kupaca ne
obrađuju do kraja projekta (7), što rezultira time što se mnoge od izvedenih funkcija ne koriste
(9). Osim toga, postoji problem u integraciji cjelokupnog sistema na kraju i testiranja [10].
Istraživanje 400 projekata s vodopadom pokazalo je da softver koji se razvija ili nije
implementiran ili ako je implementiran, ne koristi se. Razlozi za to su promjene potreba i
nedostatak prilika za razjašnjenje nesporazuma.
To je uzrokovano nedostatkom prilika za kupca da daju povratne informacije o sistemu (13).
Posebno, model vodopada ne uspijeva u kontekstu velikih složenih projekata ili istraživačkih
projekata (3).
Sa druge strane, razvoj vodopada ima i prednosti. Model vodopada je predvidljiv i skreće pažnju
na detaljno planiranje arhitekture i strukture softvera, što je posebno važno kada se radi o velikim
sistemima. Bez fokusiranja na planiranje arhitekture postoji rizik da se odluke o dizajnu
zasnivaju na prešutnom znanju, a nisu izrčito dokumentovane i pregledane (14).

Tabela 1 Problem razvoja vodopada ( stanje umjetnosti)

ID Problem Referenca
L01 L01 Visoka cijena i troškovi za pisanje i odobravanje dokumenata za 2;5
svaku razvojnu fazu.
L02 Izuzetno teško odgovoriti na promjene. 2;5;6
L03 Iteracija faze zahtijeva znatne troškove za preradu. 2
L04 Kada se sistem stavlja na upotrebu, korisnici kasno otkrivaju problem 1;2;7
ranih faza i sistem ne odgovara na trenutne zahtjeve.
L05 Problemi završenih faza ostavljaju se za kasnije faze. 2
L06 Upravljanje velikim brojem zahtjeva koji se moraju temeljiti na nastavku 7;8;9
razvoja.
L07 Big – Bang integracija i test cijelog sistema na kraju projekta može 1;10;11
dovesti do neočekivanih problema sa kvalitetom, visokih troškova i
prekoračenja rasporeda.
L08 Nedostatak mogućnosti za kupca da daju povratne informacije o sistemu. 10

3. Model vodopada u kompaniji

Model vodopada koji se koristi u kompaniji prolazi kroz faze koje zahtijevaju inženjering,
projektiranje i implementaciju, ispitivanje, puštanje i održavanje. Između svih faza dokumenti
moraju proći provjeru kvalitete, a ovaj se pristup naziva modelom pozornice (15). Pregled
procesa prikazan je na slici 1. Objašnjavamo različite faze i obezbjeđujemo izbor stavki
kontrolne liste kako bi se pokazalo kakav je način provjere kvaliteta kako bi se odlučilo da li se
softverski artefakt razvijen u određenoj fazi razvoja može prenijeti u susjednu fazu.
Slika 1 Model vodopada u kompaniji

Zahtjevi inženjerstva: U ovoj fazi, potrebe kupaca su identificirane i dokumentirane na visokoj

nivou apstrakcije. Nakon toga se zahtjevi razvrstavaju tako da se mogu koristiti kao ulaz (input)
u fazi projektiranja i implementacije. Zahtjevi (na visokom i niskom nivou apstrakcije) se čuvaju
u spremištu zahtjeva. Iz ovog spremišta se biraju zahtjevi koji se implementiraju. Broj odabranih
zahtjeva ovisi o raspoloživim resursima za projekat. Kako novi proizvodi nisu izgrađeni od nule,
dijelovi starog proizvoda (glavna linija proizvodnje, slika 1.) koriste se kao ulaz u fazu zahtjeva.
Na vratima kvalitete (između ostalog) provjerava se da li su svi zahtjevi shvaćeni, dogovoreni i
dokumentovani. Pored toga, provjerava se da li su identifikovani relevantni stakeholderi i da li će
rješenje podržati poslovnu strategiju.
Dizajn (projektiranje) i implementacija: U fazi projektovanja arhitektura sistema se kreira i
dokumentuje. Nakon toga se odvija stvarni razvoj sistema. Programeri takođe provode osnovno
testiranje jedinica prije nego što predaju razvijeni kod u fazu testiranja. Kontrolna lista kvaliteta
(između ostalog) verifikuje da li je arhitektura ocijenjena, postoje li odstupanja od zahtjeva u
odnosu na prethodnu odluku o kvalitetu i postoji li odstupanje od planiranog vremenskog slijeda,
napora ili opsega proizvoda.

Testiranje: U ovoj fazi, sistem integracije je testiran u pogledu kvalitete i funkcionalnih

aspekata. Da bi se donijela odluka o tome može li se sistem primijeniti, mjerne performanse (npr.
propusnost) prikupljaju se u ispitnom laboratoriju. Kako kompanija pruža potpuna rešenja
(uključujući hardver i softver), testovi moraju biti sprovedeni na različitim hardverskim i
softverskim konfiguracijama, budući da se oni razlikuju među kupaca. Ishod faze se preispituje
prema kontrolnoj listi da bi se utvrdilo da li je sistem verifikovan i da li postoje odstupanja od
prethodnih odluka o kvalitetu u smislu kvaliteta i vremena, da li su određeni planovi za predaju
proizvoda kupcu prema smjernicama kompanije i da li ishod projekta zadovoljava kupce.

Izdanje: U fazi puštanja proizvod se unosi u stanje isporuke. To jest, dokumentacija za otpremu
je završena (npr. Uputstvo za instalaciju sistema za kupce i korisničke vodiče). Nadalje, treba da
se programiraju uputstva za izgradnju sistema. Uputstva za izgradnju mogu se koristiti za
omogućavanje i onemogućavanje funkcija glavne linije proizvoda kako bi se sistem prilagodio
specifičnim potrebama kupaca. Na vratima kvalitete (između ostalog) provjerava zadovoljava li
ishod zahtjeve kupaca, je li kupac prihvatio ishod i da li je krajnji ishod predstavljen na vrijeme i
ispunio svoje zahtjeve kvalitete. Također treba obaviti i post-mortem analizu.

Održavanje: Nakon što je proizvod izdat kupcu, mora se održavati. To jest, ukoliko klijenti
otkriju probleme u proizvodu, prijavljuju ih kompaniji i dobiju podršku u njihovom rješavanju.
Ako su problemi nastali zbog grešaka u proizvodu, paketi za ažuriranje sistema se isporučuju
kupcima.
 4. Dizajn studije slučaja

Kontekst u kojem se sprovodi studija je Ericsson AB, vodeća i globalna kompanija za rješavanje
problema u oblasti telekomunikacija i multimedija. Takva rešenja uključuju sisteme punjenja za
mobilne telefone, multimedijalna rešenja i mrežna rešenja. Tvrtka je certificirana ISO 2001:
2000. Tržište u kojem tvrtka posluje može se okarakterizirati kao vrlo dinamična uz visoke
inovacije u proizvodima i rješenjima. Razvojni model je tržišno vođen, što znači da se zahtjevi
prikupljaju od velike baze potencijalnih krajnjih kupaca, ne znajući tačno ko će biti klijenti.

4.1. Istraživačka pitanja

U studiji slučaja treba odgovoriti na sljedeća glavna pitanja istraživanja:

1. Koji su najkritičniji problemi u razvoju vodopada u velikom industrijskom razvoju?

2. Koje su razlike i sličnosti između stanja tehnike i rezultata studije slučaja?

Relevantnost istraživačkih pitanja može se naglasiti na sljedeći način: Slični radovi pokazuju niz
problema vezanih uz razvoj vodopada. Međutim, premalo je empirijskih dokaza o ovoj temi i
stoga je potrebno više podataka. Nadalje, kritičnost problema dosad nije riješena, što otežava
odlučivanje na koji način je najpogodnije poboljšati model ili će pak uvođenje novog načina rada
pomoći u poboljšanju ključnih izazova u modelu vodopada.

4.2. Odabir slučaja i jedinice analize

Slučaj koji se proučava je jedna razvojna stranica Ericsson AB. Kako bi se razumjeli problemi
koji su se dogodili kada se model vodopada koristio u kompaniji, analiziraju se tri podsistema
(S1, S2 i S3) koji su izgrađeni prema modelu. Sistemi koji se istražuju u ovoj studiji slučaja
imaju ukupnu veličinu od cca. 2.000.000 LOC (kao što je prikazano u tabeli 2.). LOC mjera
uključuje samo kod proizveden u preduzeću (isključujući biblioteke nezavisnih proizvođača).
Osim toga, navedeno je i broj lica uključenih u izgradnju sistema. Poređenje sistema koji se
uzima u obzir za ovu studiju i veličine Apache web servera pokazuje da je sistem koji se
proučava znatno veći, te se može smatrati velikim sistemom.
Tabela 2 Jedinice analize

Jezik Veličina (LOC) Br. osoba

Cjelokupni sistem >5,000,000 -
S1 C++ 300,000 43
S2 C++ 850,000 53
S3 Java 24,000 17
Apache C++ 220,000 90

4.3. Postupci prikupljanja podataka

Podaci se prikupljaju putem intervjua i iz procesne dokumentacije.

Izbor ispitanika.

Ispitanici su izabrani tako da je sveukupno razvojni životni ciklus pokriven, od zahtjeva do

testiranja i puštanja u rad. Nadalje, svaka uloga u procesu razvoja treba da bude predstavljena na
ako je moguće, najmanje dvije osobe. Izbor ispitanika obavljen je na sljedeći način:

1. Kompletna lista ljudi dostupnih za sistem koji se proučava. Ukupno 153 ljudi su na ovoj listi
kao što je prikazano u Tabeli 2.

2. Za izbor osoba koristili smo uzorkovanje klastera. Najmanje dvije osobe iz svake uloge (uloge
su klasteri) su nasumično izabrane sa liste. Što je više osoba dostupno za jednu ulogu, više osoba
je izabrano.

3. Izabrani ispitanici su dobili e-mail u kojem je objašnjeno zašto su bili izabrani za studiju.
Pored toga, e-mail sadrži informacije o svrsi studije i poziv za intervju. Ukupno je kontaktirano
44 osobe od kojih je 33 prihvatilo poziv.

Raspodela ljudi između različitih uloga prikazana je u Tabeli 3. Uloge su podeljene na "Šta",
"Kada", "Kako", "Osiguranje kvaliteta" i "Upravljanje životnim ciklusom".

- Šta: Ova grupa ljudi se bavi odlukom šta da se razvije i uključuje ljude iz strateškog upravljanja
proizvodima, tehničkih menadžera i sistemskih menadžera.
- Kada: Ljudi u ovoj grupi planiraju vremensko razdoblje razvoja softvera iz perspektive
tehničkog i projektnog upravljanja.
- Kako: Ovdje se definira arhitektura i odvija se stvarna implementacija sistema. Osim toga,
programeri provjeravaju vlastiti kôd (testovi jedinica).
- Osiguranje kvalitete: Osiguranje kvalitete je odgovorno za testiranje softvera i pregleda
dokumentacije.

- Upravljanje životnim ciklusom: To uključuje sve aktivnosti koje podupiru ukupan razvojni
proces, poput upravljanja konfiguracijom, održavanja i podrške, i pakiranje i otprema proizvoda.

Tabela 3 Distribucija ispitanika između uloga i jedinica analize

S1 S2 S3 Ukupno
Šta (Zahtjevi) 2 1 1 4
Kada (Planiranje projekta) 3 2 1 6
Kako (Implementacija) 3 2 1 6
Osiguranje kvalitete 4 3 - 7
Upravljanje životnim ciklusom 6 4 - 10
Ukupno 18 12 3 33

Dizajn intervjua

Razgovor se sastoji od pet dijelova, trajanje intervjua je otprilike 1 sat za svaki dio. U prvom
dijelu intervjua ispitanici su dobili uvod o svrhi studija i obrazloženje zašto su odabrani. Drugi
dio se sastoji iz pitanja koja se tiču pozadine, iskustva i trenutnih aktivnosti ispitanika. Nakon
toga, pitanja su prikupljena kroz polustrukturirani intervju. Kako bismo prikupili što je moguće
više pitanja, postavljena su pitanja iz tri perspektive: zagušenje/usko grlo, prerada i nepotrebni
rad. Ispitanici bi trebali navesti vrstu zastoja/ uskog grla, prerade ili nepotrebnog rada koji su
iskusili, što ga je prouzrokovalo i gdje se nalazio u tom procesu.

Dokumentacija procesa

Proučavana je kako bi se što bolje i dublje razumio sam proces. Dokumentacija uključuje npr.
specifikacije procesa, materijale za obuku za procese i prezentacije zaposlenicima tijekom
sastanaka.
 4.4. Pristup analizi podataka

Problemi vezani uz model vodopada u tvrtki identificirani su u skladu s četiri koraka opisana
u nastavku.

Koraci se temelje na više od 30 sati preuzetih intervjua i izvršio ih je prvi autor tijekom tri
mjeseca:

1. Grupisanje (klasteri): Sirovi podaci iz transkripata grupirani su, grupirajući izjave koje
pripadaju zajedno. Na primjer, sve izjave vezane za inženjering zahtjeva su grupisane
zajedno. Nakon toga, izjave koje se odnose na slične oblasti u okviru jedne grupe (npr.,
Sve oblasti koje se odnose na inženjerske vremenske zahtjeve) su grupisane.
2. Derivacija izvještaja o problematici: Neobrađeni podaci sadrže detaljna objašnjenja i
stoga se apstrahuju dobivanjem izjava o problemu iz sirovih podataka, objašnjavajući ih
kratko u jednoj ili dvije rečenice. Rezultat je bio niz problemskih izjava u kojima su
izjave varirale na razini apstrakcije i mogle bi se dodatno grupisati.
3. Mapa misli izvještaja o problematici: Izjave o problemima grupisane su na temelju
međusobnog odnosa i njihove razine apstrakcije. Naprimjer, problemi povezani s
vremenom dovršavanja zahtjeva grupisani su unutar jedne grane pod nazivom "dugoročni
zahtjevi za vođenje“. To je dokumentirano u obliku mape misli. Problemi s višom
razinom apstrakcije bliži su centru mape misli nego pitanja s nižom razinom apstrakcije.
4. Provjera valjanosti problema: U istraživanjima kvalitativne prirode uvijek postoji rizik da
su podaci pristrani tumačenjem istraživača. Stoga su pitanja validirana u dvije radionice s
tri predstavnika kompanije. Predstavnici detaljno poznaju proces. Zajedno, ovdje opisani
koraci analize reproducirani su s autorima i predstavnicima tvrtke. Za to je odabran
podskup slučajno odabranih izjava o problemima. Nije bilo značajnijih neslaganja
između sudionika radionice o ishodu analize. Dakle, valjanost izjava o izdavanju može se
smatrati visokom.

Nakon što su identifikovali probleme, prioritizirali su ih u A-problemi (kritički), B-problemi

(veoma važni), C-problemi (važni), D-problemi (manje važni) i E-problemi (lokalni).
A Problem se pominje u više uloga i više od jednog podsistema. Štaviše, problem se odnosi na
više od 1/3 ispitanika.

B Problem se pominje u više uloga i više od jednog podsistema. Štaviše, problem se odnosi na
više od 1/5 ispitanika.

C Problem se pominje u više uloga i više od jednog podsistema. Štaviše, problem se odnosi na
više od 1/10 ispitanika.

D Problem se pominje u više uloga i više od jednog podsistema. Štaviše, problem se odnosi na
1/10 ispitanika ili manje..

E. Problem se odnosi samo na jednu ulogu ili jedan podsistem.

4.5. Prijetnje valjanosti

Tokom izrade studije važno je utvrditi prijetnje validnosti ishoda studije koja će omogućiti da
preduzmu mjere kojima će ih ublažiti. Pretnje relevantne za studij su: konstrukcija validnosti,
vanjska validnost i pouzdanost

Konstrukcija Validnost: Validnost izgradnje se bavi dobijanjem pravih mjera za koncept koji se
izučava. Jedina opasnost je izbor ljudi pomoću kojih se može dobiti odgovarajući uzorak za
odgovaranje na pitanja istraživanja. Stoga, iskusni ljudi iz kompanije odabrali su ispitanike koji
najbolje poznaju kompaniju i osobe u njoj. Od ovih ispitanika uzet je slučajni uzorak. Izbor
predstavnika kompanije obavljen je po sljedećim kriterijima: procesiranje znanja, uloga,
distribucija kroz podsisteme I imajući dovoljan broj uključenih ljudi Pored toga, prijetnja je da
prisustvo istraživača utiče na ishod istraživanja. Validnost je također ugrožena ako su pitanja
pogrešno shvaćena ili pogrešna tumačenja.

Vanjska validnost: Jedina prijetnja za validnost je da je samo jedan slučaj izučavan. Dakle,
kontekst i slučaj su detaljno opisani i podržavaju generalizaciju identifikovanih problema.
Studijski procesni model slijedi glavna načela vodopada i na taj način mogu biti dobro
generalizovani za taj model. Pored toga, ishod se upoređuje sa najsavremenijim iskustvom.
Pouzdanost: Ova prijetnja se bavi ponavljanjem, a posebno da bi se isti rezultat mogao naći ako
ponovite isto istraživanje pod istim uslovima. Uvijek postoji rizik da na ishod istraživanja utiče
tumačenje istraživača. Da bi se ublažila ova prijetnja, istraživanje je dizajnirano tako da se
podaci prikupljaju iz različitih izvora.

5. Kvalitativna analiza podataka

U studiji slučaja identifikovano je 38 problema. Većina problema kategorizirana je u klasi E.

Prikazana je distribucija problema između inžinjerskih zahteva (RE), dizajna i razvoja(DI),
verifikacija i validacija (VV), oslobađanje (R), održavanje (M),i upravljanje projektima (PM) . U
analizi problema fokusiramo se na klase od A do D, jer su oni najviše relevantni jer su
prepoznate kroz uloge i sisteme. Dakle, oni imaju vidljiv utjecaj na sveukupni razvojni proces.
Međutim, to ne podrazumijeva da su lokalna pitanja potpuno irelevantna, oni imaju mali uticaj
na cijelokupni razvojni proces i samim tim ne prepoznaju druge uloge.

Tabela 4 Broj problema u klasifikaciji

5.1. A problemi

P01: Dugoročne prednosti inžinjerske faze dovode do toga da je potrebno promjeniti zahtjeve ili
odbaciti već implementirane i prikazane zahtjeve jer je istraženi domen veoma dinamičan.
Udaljenost od kupca izazvala je nesporazume u kojima je došlo do izmijene zahtjeva ili
odbacivanja zahtjeva. Zbog složenosti opseg koji treba definisati broj zahtjeva je bio previsok za
date resurse što je rezultiralo odbacivanjem zahteva (i ponekad je to učinjeno kasno u procesu
razvoja).
P02: Pokrivenost testa u razvoju vodopada smanjena je iz više razloga.Testiranje se završava
kasno u projektu i stoga ako je došlo do kašnjenja u razvoju, testiranje mora biti
kompromitovano, jer je to jedan od poslednjih koraka u razvoju. Nakon što je cijelokupni sistem
implementiran ima previše toga što se mora testirati odjednom Dodatni faktori su testiranje koje
se odnosi na kvalitet koje često ima nizak prioritet u odnosu na funkcionalno testiranje, trivijalne
stvari su testirane intenzivno, a resursi se koriste za testiranje istih stvari dvaput zbog problema
sa koordinacijom.

5.2. B problemi

P03: Što je testiranje duže, veća je količina pronađenih nedostataka. Broj grešaka i kvalitetnih
problema negativno utiče na korišćenje modela vodopada razvoja. Glavni razlog za ovo je kasno
testiranje nakon što je sve bilo implementirano. Ovo pruža kasne povratne informacije kada se
vrši testiranje na softverskim proizvodima.Osim toga, osnovno testiranje je zapostavljeno jer je
došlo do slabe interakcije između dizajna i testiranja, što dovodi do nepoznavanja jedno drugog u
uslovima zanemarivanja osnovnog testiranja. Također zbog komunikacijskih problema, počinje
provjera nedovršenog koda što je dovelo do velikog broja lažnih grešaka (ne prave greške).

P04: Imajući kasne rezultate testa o greškama koje je teško popraviti, što je posebno povezano za
probleme koje se odnose na kvalitetne atribute sistema (npr. performanse).Ove vrste problema
često su ukorenjene u arhitekturi sistema koji je teško promijeniti kasnije u projektu.

5.3. C problemi

P05: Ispitanici su naglasili da se proizvodi dosta dokumentacijeu fazi zahtjeva. Jedan od

navedenih razloga je ograničena ponovna upotrebadokumentacije (tj. iste informacije se
prijavljuju nekoliko puta). Štaviše,koncept zahtjeva izradu puno dokumentacije i kontrolnih listi
koje se moraju ispuniti prije nego što se usvoje zahtevi sledeće faze.

P06: Dizajn i implementacija imaju slobodan kapacitet, razlozi za to su da zahtevi moraju biti
precizirani do najsitnijih detalja, odlučivanje traje dugo ili zahtjevani resursa su svezani zbog
prevelikog obima zahtjeva. Ovo ima negativan uticaj na dizajn, jer dizajneri moraju čekati input
od inženjera prije nego što počnu da rade.
P07: Iz perspektive dizajnera, nije uvijek jasno koju verziju treba implementirati i ko treba
implementirati. Uzrok ovog problema je da taj posao često počinje na nedovršenim ili
neodobrenim zahtjevima koji nisu bili pravilno određeni.

P08: Potrebna je jaka podrška da se izvrši veći broj ispravki na već objavljenom softveru. Kao
posljedica toga, kupci ne mogu čekati da se ispravke poprave i da izađe sledeća verzija softvera, i
tako ispravke predstavljaju vremenski problem. U ovom domenu, proizvodi imaju visok stepen
varijabilnosti i stoga nekoliko proizvodnih grana moraju biti podržane.

P09: Fokus na kompetencije ljudi u razvoju vodopada je sužen, ali specijalizovan. To je zbog
toga što su ljudi jasno razdvojeni u njihovim fazama i disciplina i to znanje nije dobro
raspoređeno među njima. Jedan sagovornik istekao je da postoje komunikacione barijere između
faza. Štaviše,zabilježen je nedostatak povjerenja. To jest, ljudi su sposobni ali ne prepoznaju
svoju ličnu snagu do stepena koji bi trebali.

5.4. D problemi

P10: Novi zahtevi nemaju izolovani uticaj, umjesto toga mogu uticati na više podsistema.
Međutim, zbog velikog obima zahtjeva, zahtjevi zavisnosti često se zanemaruju.

P11: Obim zahteva bio je preveliki za resurse implementacije.Kao posledica toga, dizajneri i
arhitekte su preopterećeni zahtevima koje se ne mogu realizovati sa datim resursima. Štaviše,
nakon što je projekat, uslijedilo je više zahteva od kupca. Kao posledica toga, zahtevi se ne mogu
implementirati od strane arhitekte i dizajnera jer se već suočavaju sa situacijom preopterećenja.

P12: Testna dokumentacija je postala preobilna iz razloga što postoji dosta zastarjelih
dokumenata. Razlog za visoku količinu dokumentacije u većini slučajeva jeste taj što je proces
bio centralno dokumentiran.

P13: Kada se bavite različitim podsistemima, locirati grešku predstavlja problem jer problem
može biti prikazan samo u jednom podsistemu, ali zbog komunikacione barijere svi projektni
podsistema nisu svijesni problema.
 6. Kvantitativna analiza podataka

Sljedeća tabela prikazuje raspodjelu vremena (trajanja) u razvojnom procesu. Inženjerska faza
zahtjeva traje veoma dugo u poređenju sa drugim fazama. Izgleda da je implementacija sistema
najmanje vremenski intenzivna aktivnost.

Tabela 5 Raspodjela vremena (trajanja) u fazama (u%)

Zahtjevi Implementacija i Kontrola Puštanje Ukupno

dizajn
41 17 19 23 100

Sljedeće su mjerili broj zahtjeva za promjenu po implementiranom zahtevu, broj odbačenih

zahtjeva i procenat grešaka pronađenih u sistemskim testovima koji je trebalo pronaći u ranijim
testovima (test funkcije i komponentatest). Konkretno,veliki broj odbačenih zahtjeva i uzrok za
promjenu zahtjeva su povezani sa problemom P01. Sa perspektive kvalitete, postotak greške od
31% je simptom P03 (povećanje broja grešaka kod kasnog testiranja) i P04 (vrste greške koje su
pronađene u sistemskim testovima mogle su se naći ranije i tada bi ih bilo lakše popraviti).

7. Uporedna analiza slučaja i SotA

Problemi u studiji slučaja su formulisana drugačije od onih koji su identifikovani u literaturi, jer
na formulisanje problema uticao je ishod kvalitativne analize podataka.Zbog toga, objašnjavamo
kako i zašto su problemi od najvećeg značaja za studi slučaja i SotA međusobno povezani.
Najvažniji problemi su povezani sa fazom inženjerskih zahteva, i verifikaciju i validaciju (oba
identifikovana u literaturi). Utvrdili su da se zahtjevi često moraju preoblikovati ili odbaciti
(P01). Kvantitativna analiza pokazuje da se 41% vremena troši za inženjerske zahtjeve. Morajući
definisati veliki obim zahtjeva, produžava vrijeme rada i time smanjuje stabilnost zahtjeva.Kao
posledica toga, model vodopada nije pogodan u razvoju velikih razmjera. Što se tiče pitanja
verifikacije koje je identificirano u literaturi navodi se da testiranje čitavog sistema na kraju
projekta dovodi do neočekivanih problema u kvalitetu i prekoračenje projekta. Ovaj problem se
povezuje sa studijem slučaja na sledeće načine: Prvo, testiranje mora biti kompromitovano i na
taj način pokrivenost testa se smanjuje kada ima određene rokove koji ne dozvoljavaju projektu
prekoračenja (P02). Drugo, greške koje su kasnije pronađene u procesu je teško
popraviti,posebno ako su ukorenjeni u arhitekturu sistema (P07). Problemi kategorizovani u C
probleme su izmješani, oni podrazumjevaju probleme povezane sa zahtjevima, dizajnom,
održavanjem I project menadžmentom. Problemi koji spadaju u D kategoriju pokazuju sličan
obrazac kao I najkritičniji problem (A i B kategorije), oni su povezani sa zahtjevima, I
varifikacijom I validacijom. Kao što je ranije navedeno, manje od polovine problema problema
klasifikovanih u C i D kategorije problema identifikovane su ranije u litaretauri. Objašnjenje
problema koji još nisu identifikovani dato je u kvalitativnoj analizi. Također je interesatno
posmatrati da većina lokalnih problema je povezana sa project menadžmentom i održavanjem.
 8. Zaključak

Ovaj studij slučaja istražuje probleme povezane sa vodopad modelom primijenjenim u kontekstu
velikog razvoja softvera i upoređuje saznanja sa literaturom. Rezultati kažu da najkritičniji
problem u vodopad razvojnom modelu su povezani sa zahtjevima i varifikacijom. Kao
posljedicu, vodopad model nije pogodan za korištenje u velikim razvojima softvera. Kada se
poredi literatura sa istraživanjima studija slučaja pokazano je da svi problemi navedeni u
literaturi se pojavljuju u studiji slučaja. Ali, istraživanja studije slučaja pružaju detaljnije
objašnjenje problema i identifikuju četiri nova problema, 1) nejasnoća ko implementira koju
vrstu zahtjeva, 2) veliki trud za održavanje, 3) specijalizirani fokus na kompetencije ljudi i
manjak pouzdanja kod ljudi i 4) problemi u lociranju greške zbog komunikacijskih barijera.
LISTA TABELA I SLIKA
Tabela 1 Problem razvoja vodopada ( stanje umjetnosti)................................................................6
Tabela 2 Jedinice analize...............................................................................................................10
Tabela 3 Distribucija ispitanika između uloga i jedinica analize..................................................11
Tabela 4 Broj problema u klasifikaciji..........................................................................................14
Tabela 5 Raspodjela vremena (trajanja) u fazama (u%)................................................................17
Y

Slika 1 Model vodopada u kompaniji..............................................................................................7

LITERATURA

1. Royce, W.: Managing the development of large software systems: Concepts and
techniques. In: Proc. IEEE WESCOM. IEEE Computer Society Press, Los Alamitos
(1970) 2
2. Sommerville, I.: Software Engineering, 7th edn. Pearson Eductation Ltd., London (2004)
3. Raccoon, L.B.S.: Fifty years of progress in software engineering. SIGSOFT Softw. Eng.
Notes 22(1), 88–104 (1997)
4. Yin, R.K.: Case Study Research: Design and Methods, 3rd edn. Applied Social Research
Methods Series, vol
5. Prentice Hall, Englewood Cliffs (2002) 5. McBreen, P.: Software craftsmanship: the new
imperative. Addison-Wesley, Boston (2002)
6. Pfleeger, S.L., Atlee, J.M.: Software engineering: theory and practice, 3rd edn. Prentice
Hall, Upper Saddle River (2006)
7. Jarzombek, J.: The 5th annual jaws s3 proceedings (1999)
8. Thomas, M.: It projects sink or swim. British Computer Society Review 2001 (2001)
9. Johnson, J.: Keynote speech: Build only the features you need. In: Proceedings of the 4th
International Conference on Extreme Programming and Agile Processes in Software
Engineering (XP 2002) (2002)
10. Jones, C.: Patterns of Software Systems: Failure and Success. International Thomson
Computer Press (1995)
11. Sametinger, J.: Software engineering with reusable components: with 26 tables. Springer,
Berlin (1997)
12. Anderson, D.J.: Agile Management for Software Engineering: Applying the Theory of
Constraints for Business Results (The Coad Series). Prentice Hall PTR, Englewood Cliffs
(2003)
13. Cohen, D., Larson, G., Ware, B.: Improving software investments through requirements
validation. In: Proceedings of the 26th Annual NASA Goddard Software Engineering
 Workshop (SEW 2001), Washington, DC, USA, p. 106. IEEE Computer Society, Los
Alamitos (2001)
14. Boehm, B.: Get ready for agile methods, with care. Computer 35(1), 64–69 (2002)
15. Karlstr¨om, D., Runeson, P.: Combining agile methods with stage-gate project
management. IEEE Software 22(3), 43–49 (2005)