Kako organizirati razvoj softvera u skladu s

ISO 9001 sustavom kakvoce

Uvod
Tekst govori o mojim iskustvima u ARBOR INFORMATICI kod izgradnje sustava kakvoce prema zahtjevima
standarda ISO 9001 i primjeni stecenog iskustva na razvoja softvera.
Ideje iz ovog clanka uskladene su sa zahtjevima standarda ISO 9001 Sustavi kakvoce Model za
osiguravanje kakvoce u zamisli, razvoju, proizvodnji, ugradbi i odrzavanju tj. tockom 4.4. Upravljanje
zamilju (Design control), te ISO 9000-3:1997(E) Guidelines for the application of ISO 9001:1994 to the
development, supply, installation and maintenance of computer software.
Vjerujem da ce mnogi koji su zapoceli izgradnju sustava kakvoce, a osnovna djelatnost im je razvoj softvera,
pronaci u ovom tekstu temelje s kojih mogu odmah krenuti u taj slozeni posao.

Opcenito
Cilj ovladavanja razvojem softvera je da se razvojne aktivnosti obavljaju pod kontroliranim uvjetima, na
organiziran nacin, brzo i ekonomicno, a da konacni proizvod u cijelosti zadovolji zahtjeve koji su unaprijed
definirani od strane narucitelja.
Razvoj softvera (u irem smislu) dijelimo i pratimo kroz sljedece faze:
postavljanje strategije sustava,
analiza sustava ili djela sustava za koji se izraduje softver,
dizajn (oblikovanje) sustava,
izgradnja (programiranje) sustava s usporednom izgradnjom dokumentacije,
prijelaz na novi sustav i
produkcija s novim sustavom.
Za slozene i dugotrajne projekte potrebno je osigurati jasnu organizaciju, poznavanje i primjenu izabranih
metodologija rada kod vodenja i realizacije projekata, tehnicku opremljenost (strojnu i programsku) te
odgovarajuci kadar koji ce se trajno usavravati.
Napomena: Razvojni projekt se odnosi na jednu ili vie faza iz navedene podjele. U uzem smislu razvoj softvera je analiza, dizajn i programiranje
(kod nekih je to, nazalost, samo programiranje)!

Planiranje razvoja softvera

ARBOR INFORMATIKA polazi od strateke odrednice da je za uspjenu realizaciju projekta potrebno ukljuciti
kupca kao ravnopravnog partnera i zajedno s njim definirati ciljeve projekta. Pored navedenog potrebno je
definirati nositelje posla (radni tim) sa strane narucitelja i izvodaca. U definiciji ciljeva ukljucen je narucitelj s
timom odredenim za realizaciju projekta i izvodac sa voditeljem projekta i vlastitim timom.

Voditelj projekta sa strane narucitelja je kljucna osoba koja se imenuje u samom pocetku projekta i na njoj pociva
uspjenost realizacije projekta. Pozeljne karakteristike voditelja projekta su:
poznavanje metodologije vodenja projekata,
poznavanje informatickih tehnologija i alata,
uocavanje slabih rjeenja i sposobnost brzog pronalazenja alternativnih rjeenja,
mogucnost prepoznavanja nedostataka u radu (npr. slaba dokumentiranost sustava ili loa medusobna
komunikacija),
sposobnost jasnog i sazetog ocitovanja (pismeno i usmeno) o problemima i napretku projekta.
Narucitelj i izvodac moraju sagledavati i druge aspekte projekta da bi mogli planirati sve faze u zivotnom ciklusu
razvoja softvera. Bitni cimbenici koje treba prepoznati na vrijeme (prije potpisivanja ugovora) i voditi racuna o
njima su:
vrsta poslovne problematike koja se rjeava projektom
tip projekta
referentni projekti
rezultat projekta (sustav za produkciju, MIS, DSS, unapredenje postojeceg sustava i sl)
rokovi (fiksni vs. oko kojih se pregovara)
ljudski resursi
tehnicki resursi
politicko i financijsko okruzenje
Sagledavanjem svih navedenih cimbenika postavlja se projektni zadatak. Projektni zadatak trebao bi postaviti
narucitelj posla. U praksi cesto narucitelj nema dovoljno znanja i/ili iskustva da postavi projektni zadatak pa su s
toga moguce i alternativne kombinacije u postavljanju zadatka; npr. narucitelj-izvodac ili treca strana angazirana
od narucitelja (konzultant).
Projektnim zadatakom, pored definicije ciljeva, obima i granica projekta mora predvidjeti to vie elemenata iz
prethodno navedenih tocaka. Osnovni dokument koji nastane kao rezultat rada na projektnom zadatku je plan
realizacije projekta (plan tijeka projekta, plan resursa, plan komunikacije, plan prihoda i rashoda, plan
zavretka projekta). Voditelj projekta zajedno s rukovodstvom izraduje plan realizacije projekta i procjenjuje
potrebne resurse. Ove dvije aktivnosti su u medusobnoj korelaciji zato jer bez jasno definiranih faza i koraka u
izvrenju projektnog zadatka nije moguce predvidjeti sve potrebne resurse; i obrnuto, bez poznavanja
raspolozivih resursa nemoguce je napraviti plan realizacije projekta.
Plan realizacije projekta donosi se i prati po fazama (vidi poglavlje: Faze razvoja softvera s definiranim ulazima i
izlazima).

Organizacijski i tehnoloki preduvjeti

O organizacijskim i tehnolokim preduvjetima mogla bi se napisati cjeli niz clanaka, pa cemo s toga samo
navesti potrebne preduvjete:
jasna organizacijska struktura s definiranim odgovornostima i obvezama,
izabrana metodologija kao referentna osnovica od koje se polazi i prilagodava nacin rada konkretnim
zahtjevima na projektu,
tehnologija kojom gradimo proizvod i
kvalificirani djelatnici.

Ad 1. U ARBOR INFORMATICI postoje bogata iskustva u realizaciji razvojnih projekata kroz hjerarhijskofunkcionalnu organizacijsku shemu, pa do u novije vrijeme, projektne organizacije poslova. Organizacijska
struktura i opis poslova definirani su u pravilniku QRG SW 00 01,
Ad 2. ARBOR INFORMATIKA na svojim dosadanjim i buducim projektima u potpunosti ili djelomicno, zavisno
od velicine i tipa projekta, koristi metodologiju pod nazivom ORACLE CASE*Method koju je inicijalno razvio g.
Richard Barker.
Ad 3. Smatram da je izbor tehnologije manji problem. Vecina dananjih projektantsko-programerskih alata
podrzava sve napredne koncepte u razvoju softvera (zajednicki repozitorij, objektno programiranje, nekoliko
prizntih metodologija, RAD, generatori koda u vie programskih jezika i sl.). Tu je i veliki broj raznorodnih
nezavisnih proizvodaca softvera koji imaju alate za unapredenje kvalitete razvoja softvera (debugging,
generiranje testnih podataka i testiranje na zadane uvjete, pisanje jasnog koda i sl.)
ARBOR INFORMATIKA bazira svoj razvoj na Oracle tehnologiji (Oracle RDBMS, projektantski alat
Designer/2000 i programerski alat Developer/2000).
Za obavljanje ostalih aktivnosti kao to su svakodnevni uredski poslovi, medusobna komunikacija, planiranje
posla i slicno koriste se Microsoftovi proizvodi: MS Office, MS Project, MS Exchange itd.
Ad 4. Zadnji, ujedno i najvazniji (pred)uvjet za razvoj kvalitenog softvera jeste kvalitetan kadar. Samo se od
iskusnih ljudi koji se stalno usavravaju i napreduju moze traziti i ocekivati uspjena realizacija slozenih razvojnih
projekata.

Faze razvoja softvera s definiranim ulazima i izlazima

Jedan od najznacajnijih elemenata u planiranju ostvarenja svakog projekta je na vrijeme uociti i organizirati
posao po fazama. Pored navedenog vazno je uociti, definirati i kontrolirati slijedece (detaljno u ISO 9000-3
tocka 4.4. Design control):
ulazi za razvojnu fazu - svi zadaci (ulazi) moraju biti jasno definirani i dokumentirani i to na nacin da se rjeenje
(izlazi) moze provjeriti. Mora biti omoguceno da se nekompletni, dvosmisleni ili oprecni zahtjevi razrjee s
osobom odgovornom za donoenje takvih zahtjeva (ISO 9000-3 t.4.4.4).
izlazi iz razvojne faze - svi zadaci (izlazi) moraju biti definirani, dokumentirani i obavljeni prema unaprijed
dogovorenoj specifikaciji (ISO 9000-3 t.4.4.5).
postupci provjere svake faze - mora postojati plan po kojem se provjeravaju izlazi iz prethodne faze i
usaglaavanje izlaza s ulazima u narednu fazu. Preglede je potrebno obavljati u predvidenim rokovima
(kontrolne tocke) a rezultate pregleda koristiti za uskladenje zahtjeva unutar faze i uskladenjem izlaza i ulaza
medu fazama. O svim aktivnostima potrebno je voditi zapise (ISO 9000-3 t.4.4.6).

analiza mogucih problema unutar svake faze i

analiza uspjenosti rjeenja specificiranih zahtjeva.
U razvoju softvera razlicite metodologije predvidaju razlicite podjele posla po fazama. Poto se ARBOR
INFORMATIKA kod izgradnje sustava kakvoce pridrzavao ORACLE CASE metodologije dobili smo
odgovarajucu dokumentaciju (poslovnik, postupke i upute) koja proizlazi iz nje, a to su:
Strategija - Ulaz u ovu fazu je projektni zadatak. Svaki poslovni sustav je jedinstven pa iz toga proizlazi da su
rezultati strateke studije jedinstveni i specificni promatranom sustavu. U uputi QIN SW 04 06 dane su smjernice
(moguci sadrzaj) strateke studije.
Analiza - Opisano u postupku Projektiranje softvera - QPR SW 04 03.
Dizajn - Opisano u postupku Projektiranje softvera - QPR SW 04 03.
Izgradnja - Opisano u postupku Programiranje softver - QPR SW 04 04.
Dokumentacija - U cjelokupnom procesu rada stvara se tehnicka dokumentacija koja opisuje sustav. Tehnicka
dokumentacija je namjenjena onima koji odrzavaju sustav i moze je upotrebljavati samo osposobljeni tim koji je
upoznat s metodologijom rada i razvojnim alatima. U ovoj fazi se pie korisnicka dokumentacija bilo u obliku
prirucnika, bilo u obliku on-line pomoci. Pregledi ulaza i izlaza po ovoj fazi dani su u postupcima Projektiranje
softvera - QPR SW 04 03 i Programiranje softver - QPR SW 04 04.
Prijelaz - Opisano u postupku Uvodenje softvera - QPR SW 04 02.
Produkcija - Opisano u postupku Odrzavanje softvera - QPR SW 04 01.

Ocjena realizacije projekta

Ocjena je specificna i primjerena svakoj fazi iz zivotnog ciklusa razvoja softvera. Osnovno pitanja na koje treba
dati odgovor kod ocjenjivanja svake faze je:
ostvaruju li se ciljevi iz projektnog zadatka?
ispunjavamo li odrednice iz ugovora?
pridrzavamo li se planova realizacije projekta tj. dogovora?
Smisao takvih akcija jeste potvrditi ili promjeniti ciljeve postavljene u projektnom zadatku i revidirati planove
realizacije projekta. Poto analiza rezultata rada tj. ocjena izlaza iz pojedinih faza dodatno povecava trokove
projekta, s toga se ona rijetko sprovodi pa su stoga cesta iznenadenja s konacnim rezultatima projekta. Takoder
je problem u tome to narucitelj cesto nije strucan ili pak nije voljan angazirati vanjske strucnjake za obavljanje
takvog posla.
Nita bolja situacija nije kod potvrde i ovjere softverskog proizvoda. Zbog cestog nedostatka vremena (citaj
novca) ovim aktivnostima se cesto posvecuje formalna paznja i to nazalost u trenutku kada je proizvod skoro pa
gotov.

Potvrda i ovjera softverskog proizvoda

Redovitim sprovodenjem procesa potvrde i ovjere dobivamo odgovore na pitanja:

da li dobro radimo softverski proizvod (verifikacija)?

da li je dobar softverski proizvod (validacija)?
U svakoj razvojnoj fazi, prema unaprijed utvrdenim planovima tj. dogovorom izmedu narucitelja i izvodaca
(voditelja projekta) odreduje se sadrzaj, nacin i nivo detaljnosti potvrde i ovjere softverskog proizvoda.
Voditelj projekta je zaduzen da organizira proces potvrde i ovjere softverskog proizvoda u suradnji s razvojnim
timom. On je odgovoran da se aktivnosti obavljaju u skladu s postavljenim planovima i dokumentirano, te da se
uoceni nedostaci bilo u procesu rada ili na proizvodu uklone. Takoder je duznost voditelja da ukljuci narucitelja u
proces ovjere softverskog proizvoda. Narucitelj se ukljucuje u proces preko zajednickog tima ili osoba izabranih
za ovjeru proizvoda.
Proces potvrde i ovjere se izvodi kroz devet koraka koji su detaljno opisani u uputi Plan testiranja softvera QIN SW 04 05. Postupci se mogu iterativno ponavljati dok se ne dobije potvrda da zadovoljava dogovorenu
specifikaciju ili propisane standarde (kriterije prihvatljivosti).

Promjene u projektnom zadatku u razvoju softvera

Promjene zamisli tj. promjena projektnog zadatka takoder je vezana na model zivotnog ciklusa razvoja softvera.
Model dijelimo u dvije cjeline, a to su logicka izgradnja sustava i fizicka izgradnja sustava. to ranije dode do
promjena specifikacija po kojima se zapocelo raditi to su posljedice i utjecaji na izgradnju sustava manji. U dijelu
fizicke izgradnje sustava naoko male promjene ponekad uzrokuju znacajne trokove u razvoju softvera.
Logicka izgradnja sustava - ova cjelina se sastoji od tri faze, a to su: strategija, analiza i dizajn. Faza strategije
je pravo vrijeme kada se moraju uociti, profilirati i definirati sve zelje korisnika. Ovdje su promjene u zamisli
prirodne i pozeljne (borba miljenja). Posljedica je dobro ili loe definiran projektni zadatak od kojeg sve pocinje.
U fazi analize sustava (prije detaljne analize) moze doci do izmjena nekih od zahtjeva, ali je bitno da se potivaju
osnovni zahtjevi iz projektnog zadatka. Promjene mogu biti dvosmjerne, od strane narucitelja ili od strane
projektanta. Ugovorom treba predvidjeti takve promjene.
U fazi dizajna bitno je onemoguciti ili minimalizirati dodatne zahtjeve za promjenama na softverskom proizvodu.
Naknadne zahtjeve treba predvidjeti ugovorom ili su stvar nove narudzbe tj. novog ugovora.
Fizicka izgradnja sustava - sastoji se od programiranja, izrade dokumentacije, prijelaza na novi sustav i
produkcije u novom sustavu. Po zavretku faze dizajna moraju postojati detaljni planovi koji definiraju rokove
zavretka preostalih faza sustava i samog sustava, predvidjeti potrebne resurse kod prijelaza na novi sustav i
probleme produkcije sustava i sl. Moguce su promjene takvih planova, ali ne promjene arhitekture sustava.
Sve ove mogucnosti treba predvidjeti ugovorom ili su stvar nove narudzbe tj. novog ugovora.

Literatura
ISO 9001:1994 Sustavi kakvoce Model za osiguravanje kakvoce u zamisli, razvoju, proizvodnji, ugradbi i
odrzavanju
ISO 9000-3:1997(E) Guidelines for the application of ISO 9001 to the development, supply, installation and
maintenance of computer software.

CASE*Method - Tasks and Deliverables, Richard Barker, 1994.

Vodenje informatickih projekata i sustavi kvalitete, ZIH, 1996.

Zakljucak - prema potrebama i zahtjevima!

DEFINICIJE POJMOVA
Razvoj softvera - sve aktivnosti koje obuhvacaju analizu sustava za koji se izraduje softver, izrada
programa, procedura, pravila, izrada tehnicke i korisnicke dokumentacije, kao i aktivnosti vezane za
pripremu podataka, uvodenje i odrzavanje softvera.
Softver (software) - intelektualno ostvarenje koje obuhvaca programe, procedure, pravila i
odgovarajucu dokumentaciju pridruzenu sistemu procesiranja podataka. Napomena: Softver je
neovisan o mediju na kojem je snimljen (apliciran).
Softverski proizvod (software product) - skup kompjuterskih programa, procedura, odgovarajuce
dokumentacije i podataka koji predstavljaju funkcionalnu cjelinu i koji su pripremljeni za isporuku
korisniku.
Softverski modul (software item) - bilo koji dio softverskog proizvoda u razvojnoj fazi ili zavrnom
stupnju razvoja.
Razvoj (development) - sve aktivnosti koje rezultiraju softverskim proizvodom.
Faza (phase) - odredeni segment rada. Napomena: faza ne podrazumijeva koritenje specificnog
modela zivotnog-ciklusa, niti vremenski period razvoja softverskog proizvoda.
Potvrda (verification) - proces procjene proizvoda promatrane faze radi osiguranja ispravnosti i
konzistentnosti u odnosu na proizvode i standarde uzete kao ulaze za tu fazu.
Ovjera (validation) - potvrada ispitivanjem i prikupljanjem objektivnih dokaza da je softver sukladan s
potrebama korisnika. Obicno se provodi na zavrnom proizvodu u odredenim uvjetima uporabe
(konkretni uvjeti koji postoje kod korisnika). Ako su predvidene razlicite uporabe, moze se provesti
vie ovjera.
Projektni zadatak - dokument po kome se pokrece projekt informatizacije sustava.
Plan(ovi) realizacije projekta - Sastoji se od specificiranih aktivnosti korisnika i izvodaca. Moze(mogu)
se odnositi na plan tijeka projekta, plan resursa, plan komunikacije, plan prihoda i rashoda, plan
zavretka projekta.

SADRZAJ:
Uvod
Opcenito
Planiranje razvoja softvera
Organizacijski i tehnoloki preduvjeti
Faze razvoja softvera s definiranim ulazima i izlazima
Ocjena realizacije projekta
Potvrda i ovjera softverskog proizvoda
Promjene u projektnom zadatku u razvoju softvera
Literatura
Zakljucak

arko Batovanovi roen je 1962. godine. Informatikom se bavi 14 godina od toga 10 godina
profesionalno. Donedavno je radio kao rukovoditelj Sektora softvera u ARBOR INFORMATICI, a sada
je direktor CONSULTOR-a koji prua savjetodavne usluge na podruju informatike i sustavima
kakvoe.