nadziranje kvalitete temeljeno na analizi i sintezi procesa razvoja programske opreme

SVEUČILI�TE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Gordan Topić

NADZIRANJE KVALITETE TEMELJENO NA ANALIZI I SINTEZI PROCESA RAZVOJA

PROGRAMSKE OPREME

MAGISTARSKI RAD

Zagreb, 2005. godina.

Magistarski rad je izrađen na Zavodu za telekomunikacije Fakulteta elektrotehnike i računarstva Sveučili�ta u Zagrebu, uz podr�ku Centra za istra�ivanje i razvoj, Instituta za razvoj komutacijskih sustava i odjela podr�ke poslovanju tvrtke Ericsson Nikola Tesla d.d.

Mentor: Prof. dr. sc. Dragan Jevtić

Magistarski rad ima: 111 stranica, 51 sliku i 16 tablica.

Rad br.: 03-Ac-25/2000

Z A H V A L A Zahvaljujem se svim ljudima dobre volje koji su mi pomogli u ostvarivanju ovog rada svojim znanjem, sugestijama ili podr�kom. Nadalje, zahvaljujem se odjelima Software Design-a i IS/IT Business Support-a kompanije Ericsson Nikola Tesla na osiguranju potrebnog vremena i logistici pri izradi rada. Poimenice, posebno se zahvaljujem kompanijskom menad�eru kvalitete kompanije Ericsson Nikola Tesla dr. sc. Ivici Osliću za korekcije i sugestije, menad�eru za okoli� kompanije Ericsson Nikola Tesla dipl. ing. Dubravki Bačun za potrebne informacije i znanje vezano uz očuvanje okoli�a i odr�ivi razvoj, doc. dr. sc. �eljki Car na savjetima i detaljnoj korekturi, prof. dr. sc. Draganu Jevtiću za vodstvo i nesebično davanje znanja kroz duge razgovore vezane uz bit istra�ivanja i stanja svijesti koje bi trebao zadovoljavati jedan istra�ivač, svojoj majci, ocu, sestri i cijeloj obitelji na podr�ci, pogotovo mojoj djevojci Jasmini Rissi zaslu�noj za ubrzavanje procesa magistriranja i iskazanoj ljubavi. Unaprijed se zahvaljujem svim onim osobama koje će ovaj rad koristiti u daljnjim istra�ivanja temeljenim na prirodnoj ravnote�i u svrhu harmonizacije dru�tva, odr�ivog napretka čovjeka i njegove svijesti.

Posvećeno mojem ocu Ljubomiru...

Povjerenstvo za ocjenu rada:

1. Doc. dr. sc. �eljka Car � predsjednik

2. Prof. dr. sc. Dragan Jevtić � mentor

3. Prof. dr. sc. Vlatko Čerić � Ekonomski fakultet Sveučili�ta u Zagrebu

Povjerenstvo za obranu rada:

1. Doc. dr. sc. �eljka Car � predsjednik

2. Prof. dr. sc. Dragan Jevtić � mentor

3. Prof. dr. sc. Vlatko Čerić � Ekonomski fakultet Sveučili�ta u Zagrebu

Datum obrane rada: 08. lipnja 2005.

Sadr�aj

Uvod ........................................................................................................................................... 7

1 Upravljanje razvojem i osiguravanje kvalitete softvera................................................ 9

1.1 Kvaliteta proizvoda i usluga ...................................................................................... 9 1.1.1 Cjelovito ovladavanje kvalitetom .................................................................. 9 1.1.2 ISO norme sustava upravljanja kvalitetom .................................................. 11

1.2 Kvaliteta i razvoj softvera u telekomunikacijskoj industriji .................................... 14 1.2.1 Osiguravanje kvalitete u razvoju telekomunikacijskog softvera ................. 14 1.2.2 Procesi razvoja softvera ............................................................................... 15

1.3 Odr�ivi razvoj i za�tita okoli�a................................................................................. 18

2 Model razvojnog procesa softvera ................................................................................. 20

2.1 Dinamika i modeliranje sustava............................................................................... 20 2.2 Svrha modela i principi modeliranja........................................................................ 20 2.3 Osnovne ideje simulacije ......................................................................................... 21 2.4 Opis modela razvojnog procesa softvera MRPS...................................................... 22

2.4.1 Faze MRPS-a ............................................................................................... 22 2.4.2 Dekompozicija procesnih faza MRPS-a na podprocese .............................. 23 2.4.3 Struktura procesnih uloga u MRPS-u .......................................................... 28 2.4.4 Dokumentacija MRPS-a............................................................................... 30

3 Modeliranje, simulacija i optimizacija MRPS-a Petrijevim mre�ama....................... 34

3.1 Pristup modeliranju poslovnog procesa ................................................................... 34 3.2 Cilj modeliranja i simulacije sustava ....................................................................... 34

3.2.1 Upoznavanje rada sustava ............................................................................ 34 3.2.2 Pobolj�anje performansi sustava � optimizacija resursa .............................. 35

3.3 Izvori podataka za izradu simulacijskog modela ..................................................... 35 3.3.1 Vremenski planovi ....................................................................................... 35 3.3.2 Promatranje značajki procesa....................................................................... 35 3.3.3 Opisi procesa i procesnih uloga ................................................................... 36 3.3.4 Proces i projekt u praksi � iskustvena metoda ............................................. 36

3.4 Modeliranje i simulacija razvojnog procesa softvera Petrijevim mre�ama ............. 37 3.4.1 Petrijeve mre�e � definicija i povijest razvoja ............................................. 37 3.4.2 Elementi Petrijeve mre�e ............................................................................. 37 3.4.3 Primjer modeliranja i simulacije jednostavnog poslovnog procesa klasičnom

Petrijevom mre�om ...................................................................................... 38 3.4.4 Obojene Petrijeve mre�e .............................................................................. 42 3.4.5 Varijable modeliranog sustava..................................................................... 45 3.4.6 Izlazne varijable sustava - performanse sustava .......................................... 51

3.5 Izgradnja simulacijskog modela elementima CPN pomagala.................................. 51 3.5.1 Hijerarhijska struktura CPN modela ............................................................ 51

3.6 Sintaksna provjera ispravnosti modela .................................................................... 70 3.7 Planiranje i izvođenje simulacijskih eksperimenata ................................................ 71

3.7.1 Zadatak simulacijskog mjerenja................................................................... 71 3.7.2 Procjena posla i određivanje broja članova razvojnog tima......................... 72 3.7.3 Broj i vrste simulacijskih mjerenja .............................................................. 72

3.8 Analiza rezultata simulacijskog mjerenja ................................................................ 74 3.8.1 Analiza utro�enog vremena.......................................................................... 74 3.8.2 Analiza tro�kova projekta ............................................................................ 76 3.8.3 Analiza minimuma i optimalno rje�enje ...................................................... 78 3.8.4 Procesne značajke optimalnog slučaja ......................................................... 78

3.9 Daljnje mogućnosti eksperimentiranja..................................................................... 80 3.10 Primjer iz prakse ...................................................................................................... 81 3.11 Zaključak poglavlja modeliranja procesa ................................................................ 83

4 Osiguravanje kvalitete proizvoda informacijskom analizom podataka mjerenja .... 84

4.1 Uvod u informacijsku analizu .................................................................................. 84 4.2 Klasični pristup osiguravanja i mjerenja kvalitete softvera ..................................... 84

4.2.1 Inspekcije dokumenata................................................................................. 85 4.2.2 Izvje�taji pogre�aka testiranja i gustoća pogre�aka...................................... 86

4.3 Nadogradnja klasičnog pristupa osiguranja kvalitete .............................................. 86 4.3.1 Nenumerička priroda humanističkih parametara kvalitete softvera............. 88 4.3.2 Pristup rudarenju podataka i organizacija znanja izrazitom logikom .......... 89 4.3.3 Informacijska analiza ID3/C4.5 algoritmom............................................... 91 4.3.4 Prednosti i mane informacijske analize stablom odlučivanja ...................... 96 4.3.5 Analiza i predikcije kvalitete softvera primjenom algoritma C5.0 .............. 97

4.4 Zaključak poglavlja informacijske analize ............................................................ 101

5 Zaključak........................................................................................................................ 102

Literatura .............................................................................................................................. 104

Kratice: .................................................................................................................................. 108

Sa�etak................................................................................................................................... 109

Ključne riječi......................................................................................................................... 109

Summary ............................................................................................................................... 110

Keywords............................................................................................................................... 110

�ivotopis ................................................................................................................................ 111

Magistarski rad � Nadziranje kvalitete temeljeno na analizi i sintezi procesa razvoja programske opreme

7

Uvod

Va�nost informacijskih sustava i automatizacije procesa neprestano raste u svim područjima ljudskog �ivota i rada [10]. Moderni svijet dana�njice nalazi se u informacijskom dru�tvu, gdje se sve vi�e ljudi zapo�ljava na području prikupljanja podataka, obrade informacija, te razvoju softvera [11]. Globalna povezanost i nagli razvoj informacijske tehnologije uvjetuju veliku produkciju i distribuciju znanja [50]. Prema istra�ivanjima Stanford University USA, cjelokupno ljudsko znanje se od 1960. godine udvostručuje svakih 5-8 godina, dok informacija postaje temeljni resurs poslovanja [8]. U novonastalim odnosima, informacija je novi temelj konkurentnosti. Informacijska kriza zadesila je sva područja ljudske aktivnosti. Prepoznata je kao prenatrpanost podacima, nemogućnost sređivanja, obrade i snala�enja u ogromnoj količini podataka, nemogućnost vrednovanja i brzog traganja za �to relevantnijom informacijom. Neorganiziranost i nemogućnost upravljanjem velikim količinama informacija, glavni je problem zemalja u razvoju. Upravljanje poslovima u tvrtkama nikada nije bilo te�e nego danas. Vrijeme za dono�enje poslovnih odluka sve je kraće, a utjecaj donesenih odluka sve je dalekose�niji. Odlučujući faktor uspjeha je sposobnost brzog prihvaćanja promjena u načinu rada, komunikacijama i uslugama [12]. Sreća je naklonjena prilagodljivim i inovativnim korporacijama, dok inertnim tvrtkama preostaje neizvjesna budućnost. Stoga, velike transnacionalne kompanije reorganiziraju svoje upravljačke strukture s ciljem povećanja poslovne uspje�nosti. Razvijene zemlje i njihove industrije postaju dominantne, kao jaki proizvođači informacijske opreme i znanja. Dominacija tih zemalja rezultira informacijsko-tehnolo�kim imperijalizmom, velikim problemom s neugodnim posljedicama za zemlje u razvoju. Informacijska znanost kao umijeće upravljanja i prikupljanja informacija je jo� uvijek dominantno znanje, pod kojim se podrazumijeva ono znanje s kojim manja interesna grupa potčinjava većinu, ostvarujući neku prednost, a najče�će konkurentnost i profit.

Svijet danas dramatično ovisi o softveru. Gotovo da ne postoji vi�e ljudska djelatnost gdje softver nije prisutan. Softver (SW) je postao presudan za ljudske �ivote, te po nekim procjenama danas čini 90% vrijednosti proizvoda iz informacijskog i komunikacijskog sektora. Konvergencija računarske, komunikacijske i medijske tehnologije čini ulogu softvera jo� značajnijom, otvarajući nepregledan prostor za nove sadr�aje, aplikacije i usluge [17]. Velik udio u razvoju i odr�avanju softvera optada na telekomunikacijsku industriju, koja se po metodama razvoja softvera svrstava u sam vrh umje�nosti organiziranja. Digitalna telefonska centrala ubraja se u slo�enije izume čovječanstva. Po pitanju kvalitete, softver se ne razlikuje od drugih proizvoda. Kvaliteta proizvodnje pojavljuje se kao ključni faktor tr�i�ta i direktno utječe na uspje�nost proizvodnje. Konkurentnost u proizvodnji softvera ovisi o kvaliteti proizvedenog softvera, ali i o brzini isporuke istog, stoga mnogi projekti u zastarjevaju i prije nego li su dovr�eni. S druge strane, softver ne trpi forsiranje razvoja, tj. usiljenu brzinu stvaranja zbog br�e isporuke. Kvaliteta softvera naglo pada uslijed skraćivanja rokova ili krive procjene vremena potrebnog za razvoj. Softver je poput �ivog bića, nasljeđuje lo�e karakteristike svojih stvaratelja, �to se odnosi na organizacijske i kompetetivne mogućnosti razvojnih timova. U kvaliteti softvera oslikava se organiziranost, spontanost, znanje i predanost. Budući da je kvalitetan softver preslika kvalitetnog, organiziranog, kompetentnog


8

i zadovoljnog tima, logično je ulo�iti trud i energiju u ovladavanje postupcima osiguravanja kvalitete. O kvaliteti softvera ovisit će i kvaliteta usluga u budućem dru�tvu, ali i sigurnost �ivota uopće. Iz tog razloga treba se staviti akcent na pronala�enje metoda kojima se vrijeme isporuke softvera skraćuje, bez da se gubi na kvaliteti, s tim da se sva prija�nja iskustva razvojnih timova, procesa i postupaka koriste u slijedećim projektima.

Rukovodstva velikih korporacija nastoje ubrzati dono�enje odluka analize i smanjiti inercije procesa [1]. Pri rje�avanju tih zadataka, kompetentna i napredna rukovodstva koriste mehanizme simulacija slo�enih procesa proizvodnje. Na osnovu velikog broja podataka dobivenih od mjerenja i nadzora cijelog proizvodnog procesa, pomagalima informacijske analize i simulacije dinamike procesa, mogu se izvesti kontinuirana pobolj�anja sustava shodno Demingovom krugu [18], čime mo�e biti rije�en zadatak dono�enja odluka iz velike količine informacija, koje je te�ko cjelovito obuhvatiti i obraditi ljudskim umom [1][2]. U svrhu predviđanja potrebnih resursa za proizvodnju kvalitetnog softvera u optimalnom vremenskom roku, predstavljena je ideja modeliranja softverskog razvojnog procesa putem obojenih Petrijevih mre�a. S druge strane odr�avanje kvalitete u kompleksnim sustavima sadr�i osnovni nedostatak: velika količina podataka dobivena mjerenjem i promatranjem sustava, ne mo�e biti procesirana ljudskim umom na takav način, da se brzo i lako do dođe ispravnih logičkih zaključaka, nu�nih za odr�avanje i povećanje kvalitete sustava. Kako je kvaliteta proizvodnje i proizvoda bitan faktor u konkurentnosti, nu�no je promatrati i utjecati na kvalitetu jednog velikog proizvodnog sustava, �to zahtjeva velike analize i prikupljanja podataka iz kojih je gotovo nemoguće donijeti zaključak za korektivnu radnju. Jo� veća je pote�koća izvesti predikciju pona�anja takvog sustava, mijenjajući parametre u cilju pobolj�anja kvalitete. Kako bi se omogućio sistemski uvid u znanje sadr�ano u gomilama podataka dobivenih mjerenjem i promatranjem sustava proizvodnje softvera, opisana je metoda rudarenja podataka algoritmom C5.0, nasljednikom algoritama ID3 i ID4. Također, opisan je pristup nadogradnje dosada�njeg načina osiguravanja kvalitete softvera u razvojnoj industriji, uvođenjem novih parametara promatanja vezanim uz psiho-sociolo�ke značajke članova razvojnih timova, poput stresa i kompetencija [1][2][3][8][10][11][12][13][17] [48][50].


9

1 Upravljanje razvojem i osiguravanje kvalitete softvera

Softver se ne proizvodi na klasičan način, budući je koncipiran kao apstraktna logička struktura. Bez računala, kao fizičkog medija, beskoristan je i nepostojeći, stoga vi�e nalikuje na misao, nego na proizvod. Sam proces razvoja softvera ne unosi potencijalne pogre�ke, već ako sustav sadr�i gre�ku, onda je ona napravljena u procesu razvoja softvera. Pogre�ke i nedostaci moraju se ispraviti ponovnim razvojem. Razvoj softvera je mlada disciplina, stoga je potrebno koristiti sve raspolo�ive poznate discipline, metode i tehnike kako bi se dobio �to kvalitetniji softver u �to kraćem vremenu. Osnovne discipline za razvoj softvera jesu računarske znanosti, matematika i logika, međutim kvalitetan softver je nemoguć bez visoke razine organizacijskih sposobnosti i praksi osiguranja kvalitete. [17]

1.1 Kvaliteta proizvoda i usluga

Kvaliteta je stupanj u kojemu skup svojstvenih značajka zadovoljava zahtjeve. Kvaliteta se posti�e preventivom, a ne isključivo kontroliranjem. Podrazumijeva rad ili uslugu bez gre�aka, a ne prihvatljivu razinu istih. Kvaliteta proizvoda i usluga osnovni su uvjet za uključivanje u međunarodnu podjelu rada i jedini mogući način dugoročnog povezivanja u zajedničko tr�i�te. Postići kvalitetu znači ovladati svim elementima proizvodnog sustava koji su neophodni za postizanje kvalitete. Na taj način suvremene organizacije, koje imaju volju i kadrove, plasiraju proizvode na razvijena tr�i�ta. Marketing ili tr�i�na definicija kvalitete nam govori da u poslovnim krugovima vi�e nema dileme, da je jedino uz kvalitetu, koja odgovara zahtjevima i očekivanjima kupaca, moguće trajno biti prisutan na tr�i�tu. Stoga, neophodno je da proizvođač stalno istra�uje �to kupac u smislu kvalitete očekuje i shodno tome unaprijeđuje i mijenja procese. Danas su tr�i�ta prenatrpana proizvodima, a jedino kvalitetan proizvod dobiva kupca. Smatra se da menad�ment nije upoznat dovoljno s kvalitetom, jer svega 4% podataka o stanju kvalitete dolazi do uprave. Svaka gre�ka iznad prihvatljiva razine kvalitete smanjuje prodaju za 3-4%. Dakle, kvaliteta proizvoda se stvara zbog dugoročne prisutnosti na tr�i�tu, odnosno dobiti [14].

1.1.1 Cjelovito ovladavanje kvalitetom

Cjelovito ovladavanje kvalitetom (engl. Total Quality Management, TQM) znači ovladati kvalitetom proizvoda i usluga, planirati, razvijati, proizvoditi i prodavati takve proizvode i usluge, koji na najekonomičniji način i dugoročno zadovoljavaju potro�ača. Potro�ača ne interesira da li proizvođač ima pote�koće i da li ih shvaća. Potro�ač �eli i zahtjeva da proizvođač ovladava procesom reprodukcije i realizira proizvod ili uslugu koja njemu odgovara. Za postizanje takvog cilja unutar svake organizacije i poduzeća u cjelini, te u pojedinim područjima rada, mora se ovladati kvalitetom u svim segmentima proizvodnje:


10

• MARKETING: ustanoviti stvarne karakteristike koje kupac od nas tra�i, proslijediti njegove �elje, ustanoviti neophodne, minimalne norme i �to u�e biti povezan s kupcem,

• RAZVOJ: razviti takve proizvode, koji su jednaki ili bolji od konkurentnih, pratiti proizvode konkurencije, provjeravati i mjeriti razvojne rezultate, uključivati u ispitivanja i nezavisne (treće) institucije, pratiti proizvod u eksploataciji i stalno pobolj�avati rezultate,

• PRIPREME: pripremiti procese i dokumentaciju koji omogućuju stalno i ravnomjerno postizanje kvalitete razvijenih proizvoda, provjeravati sposobnosti procesa i opreme, certificirati proizvode već u fazi pripreme proizvodnje,

• KONTROLA: redovito obavljati kontrolu, nadzor i ispitivanje proizvoda i pojedinih operacija, kontrolirati i pobolj�avati kvalitetu procesa,

• PRODAJA: isporučivati kvalitetno i u točno dogovorenim rokovima, osigurati kvalitetan, brz i učinkovit servis i odr�avanje proizvoda ili usluge, osigurati informacijsku i ostalu pomoć kupcu u kori�tenju proizvoda.

Te aktivnosti TQM-a predstavljaju sustav rada i bit će uspje�ne ako:

• idu od vi�ih prema ni�im razinama upravljanja (od predsjednika poduzeća do radnika),

• obuhvaćaju sve sektore, slu�be, odjele i proizvodne jedinice,

• uključuju i kooperante ili dobavljače sirovina, kupce ili korisnike.

U početku, kvaliteta se odnosila na proizvod, ali ubrzo je postalo jasno da se kvaliteta mora odnositi i na proizvodne procese. TQM definira tri osnovna načina osiguranja kvalitete: osiguranje kvalitete kontrolom, osiguravanje kvalitete ovladavanjem procesa proizvodnje i osiguravanje kvalitete u fazi razvoja [14].

Osiguranje kvalitete kontrolom

Najstariji način osiguranja kvalitete proizvoda kvalitete proizvoda je kontrola kvalitete proizvoda, od strane kontrolora, na kraju proizvodnog ciklusa, koji odvaja kvalitetan od nekvalitetnog proizvoda. Razvijene zemlje su uvelike smanjile taj način osiguranja kvalitete proizvoda, jer je takva kontrola skupa, lo�i se proizvodi moraju odbaciti kao �kart ili doraditi, �to iziskuje dodatne tro�kove, a ukoliko je količina lo�ih proizvoda velika, nije moguće spriječiti dolazak nekvalitetnog proizvoda na tr�i�te. Taj način nije prihvatljiv u nekim visoko sofisticiranim tehnologijama i kod kompleksnih proizvoda, te se stoga smatra vrlo lo�im. Proizvodnja softvera je jedna od tih tehnologija u kojoj je nazamislivo isključivo osiguranje kvalitete kontrolom proizvoda na kraju proizvodnog procesa [14].

Osiguravanje kvalitete upravljanjemem procesom proizvodnje

Ako proces daje samo dobre proizvode, tad se smatra da se vlada svim parametrima procesa. Način osiguranja kvalitete upravljanjem procesom proizvodnje razvijen je u SAD, gdje je proučavana sposobnost procesa (eng. capability) usavr�avajući ga sve dok rezultat normalnog


11

djelovanja tog procesa nije bio dobar proizvod. Kod takvog načina, za ovladavanje svim parametrima procesa, bilo je potrebno sudjelovanje svih slu�bi u cilju integriranog ovladavanja kvalitetom. (eng. Integrated Quality Control) [14]. Osim �to proces treba pratiti prirodne značajke ljudskog pona�anja, treba biti optimalan, prilagodljiv promjenama i lako upravljiv.

Osiguravanje kvalitete u fazi razvoja

Pristup osiguravanja kvalitete u fazi razvoja smatra se danas najsuvremenijim, jer daje najbolje rezultate u smislu kvalitete zadovoljavanja zahtjeva korisnika i kupca. Razvijen je u 50-im godinama pro�log stoljeća u Japanu. Prije nego li krene faza proizvodnje nekog proizvoda, izvode se analize kvalitete, predviđanja i ispitivanja pouzdanosti u različitim uvjetima. Na takav način osiguranje kvalitete je već ugrađeno u samom razvoju proizvoda. Jedna od konstatacija, prihvaćena među stručnjacima iz elektroindustrije tvrdi, da je u 75-80% uzrok gre�aka proizvoda, učinjena gre�ka u razvoju istog. Bitan razlog visoke razine kvalitete japanskih proizvoda je potenciranje osiguranja u fazi razvoja, �to se svodi na komparativno uklanjanje nedostataka u ranijim fazama razvoja proizvoda, prije nego li je započeo proizvodni proces. Razlozi koji opravdavaju i idu u prilog osiguravanju kvalitete u fazi razvoja su:

• ako kvaliteta nije osigurana već u fazi razvoja, onda drugi načini osiguranja kvalitete (kontrolom ili ovladavanjem procesa) nisu mogući ili su vrlo skupi, a rezultati osiguranja kvalitete ograničeni,

• pogre�ka učinjena u razvoju proizvoda mo�e dovesti cijelu organizaciju u propast, pa je osiguravanje kvalitete u razvoju i ulaganje u preventivu neizbje�no,

• u osiguranju kvalitete u fazi razvoja, svi odjeli i slu�be, mogu uspje�no sudjelovati kod ovladavanja procesa i davanja dobrih proizvoda.

U pogledu tro�kova, osiguravanje kvalitete u fazi razvoja, je najbolji način, iako je jasno da će svaka organizacija ili proces proizvodnje imati neke slabe točke, nad kojima treba postaviti kontrolu kao dopunski način osiguranja kvalitete. Shodno tome nu�no je razvijati metode i načine pristupa osiguravanja kvalitete u fazi razvoja [14].

1.1.2 ISO norme sustava upravljanja kvalitetom

U svijetu postoje brojne organizacije i normizacijske ustanove koje nastoje svojim djelovanjem i definiranjem zahtjeva na kvalitetu pokriti određena područja osiguranja kvalitete. Jedna od njih je i ISO međunarodna organizacija, kojima se nastoji za�tititi proizvođača putem ISO normi koje se temelje na procesnom sustavu proizvodnje. Norma ISO 9000:2000 nastala je 1987. godine kao spoj prethodnih standarda i normi u proizvodnji (NS 5800, ASME, BS 5750, AQAP, CSA Z 299, MIL-Q-9859, ANSI/ASQC), prvu reviziju do�ivljava 1994, a slijedeću 2000. ISO 9000:2000 norma je prvi korak implementacije TQM-a.

ISO organizacija

ISO je međunarodna organizacija za normizaciju koju čine nacionalne normizacijske ustanove iz različitih industrijskih zemalja iz cijeloga svijeta. Norme pripremaju tehnički


12

odbori, ali i međunarodne organizacije, vladine i nevladine. ISO tehničke norme doprinose svim vrstama poslovanja te djelotvornijem, sigurnijem i či�ćem razvoju, proizvodnji i isporuci proizvoda i usluga, olak�avajući trgovinu između zemalja. ISO norme u sebi sadr�e norme koje osiguravaju za�titu potro�ača ili korisnika proizvoda i usluga. ISO izrađuje norme prema zahtijevima tr�i�ta, te ih stvaraju stručnjaci iz industrijskih, tehničkih i poslovnih područja kojima su norme potrebne. Objavljene pod oznakom �međunarodne norme�, ISO norme predstavljaju međunarodni konsenzus o �stanju tehnike� u razmatranoj tehnologiji [18]. ISO usko surađuje s Međunarodnim elektrotehničkim povjerenstvom (IEC). Jedna od najva�nijih stvari koje je norma uvela je obaveza odr�avanja i izvođenja pojedinih elemenata sustava upravljanja kvalitetom, kada je on jednom uspostavljen [48].

Norma ISO 9000:2000

Norma ISO 9000:2000 uključuje skupinu od dokumenata koji slu�e za uspostavu, primjenu i pobolj�anje sustava upravljanja kvalitetom. Uključuje u sebi slijedeće norme:

• ISO 9000 � Koncepti i riječnik,

• ISO 9001 � Zahtjevi norme (osnova za certifikaciju),

• ISO 9004 � Smjernice.

Norma ISO 9001:2000 je glavna norma i utvrđuje kriterije za certifikaciju. Primjenljiva je na sve vrste organizacija - proizvodne, uslu�ne i upravne, neovisno o njihovoj veličini i neovisno o tome da li se radi o fizičkom proizvodu ili usluzi. Temeljena je na procesnom pristupu, pri čemu je proces svaka aktivnost koja prima ulaze i pretvara ih u izlaze. Norma uvodi pojam "zainteresirane strane" koji uz kupca, uključuje i druge pojedince, te skupine na koje organizacija utječe svojim ukupnim djelovanjem. Mjerenje zadovoljstva kupca i ostalih zainteresiranih strana postaje obvezno i osnova je za pobolj�anje sustava. Uz opće zahtjeve na sustav i njegovu dokumentaciju, norma navodi sljedeće skupine zahtjeva:

• odgovornost poslovodstva (privr�enost poslovodstva, usmjerenost na kupca, politika kvalitete, planiranje odgovornosti, ovlasti i komuniciranje),

• upravljanje resursima (pribavljanje resursa, ljudski resursi, infrastruktura, radno okru�enje),

• realizacija proizvoda projektiranje i razvoj, nabavljanje, proizvodni i uslu�ni postupci, nadzor nad mjernom opremom),

• mjerenje, analiziranje i pobolj�anja (mjerenje i nadziranje, upravljanje neusklađenim proizvodom, analiza podataka, pobolj�anja).

Prihvaćanje sustava upravljanja kvalitetom je strate�ka odluka organizacije. Na oblikovanje i primjenu sustava upravljanja kvalitetne organizacije utječu promjenljive potrebe, posebni ciljevi, proizvodi koje proizvodi, procesi, veličina i ustrojstvo organizacije [14][18][21][22].


13

Procesni pristup

ISO međunarodna norma promiče prihvaćanje procesnog pristupa u razvoju, primjeni i pobolj�anju djelotvornosti sustava upravljanja kvalitetom, s ciljem povećanja zadovoljstva korisnika. Da bi neka organizacija djelotvorno funkcionirala, treba utvrditi brojne povezane radnje i njima upravljati. Aktivnost koja upotrebljava određeno sredstva u nekom vremenskom periodu i upravlja njima radi pretvaranja ulaza u izlaze, mo�e se smatrati procesom. Često izlaz iz jednog procesa čini izravno ulaz u drugi proces. Primjena sustava procesa u organizaciji, utvrđivanje tih procesa i njihovih međusobnih djelovanja, te upravljanje tim procesima, naziva se procesnim pristupom. Korist od procesnog pristupa je stalno upravljanje vezom između pojedinačnih procesa u sustavu procesa, njihovim kombinacijama i međudjelovanjima. Kad se upotrebljava u sustavu upravljanja kvalitetom, takav pristup ističe va�nost:

• razumijevanja zahtjeva i njihovih zadovoljavanja,

• potrebu razmatranja procesa u kategorijama dodane vrijednosti,

• mjerenja radnih značajki i učinkovitosti,

• neprekidnog pobolj�avanja procesa na temelju mjerenja procesa i proizvoda.

Model procesno utemeljena sustava upravljanja kvalitetom prikazan je na slici (Slika 1-1). Slika obja�njava procesne veze i prikazuje ulogu korisnika u određivanju zahtjeva, kao ulaza u proces proizvodnje. Praćenje zadovoljstva korisnika zahtjeva vrijednovanje informacija koje se odnose na predod�bu korisnika o zadovoljstvu, tj. zadovoljava li organizacija korisnikove zahtjeve. Model prikazan na slici (Slika 1-1) obuhvaća sve zahtjeve norme, ali ne prikazuje procese na razini pojedinosti.

Slika 1-1: Demingov krug, poznat kao "planiraj-provedi-provjeri-pobolj�aj"

metodologije, kao model procesno utemeljena poslovnog sustava upravljanja kvalitetom.


14

Demingov krug

Demingov krug, metodologija poznata kao "planiraj-provedi-provjeri-pobolj�aj" (eng: Plan-Do-Check-Act), primjenjuje se u procesnom poslovanju, a ukratko obja�njava se kao:

• Planiraj: Analiziraj i utvrdi ciljeve i procese potrebne za dobivanje rezultata u skladu sa zahtjevima korisnika i politikom organizacije.

• Provedi: Primjeni utvrđene procese, izvedi planirane aktivnosti.

• Provjeri: Prati i mjeri proizvod i procese prema politici, ciljevima i zahtjevima za proizvod i izvje�tavaj o rezultatima.

• Pobolj�aj: Ispravi pogre�ke na proizvodu i sustavu, korekcijama i korektivnim akcijama. Poduzimaj radnje za neprekidno pobolj�avanje djelotvornosti procesa i zaključi.

Lit. [14][18][21][22][48].

1.2 Kvaliteta i razvoj softvera u telekomunikacijskoj industriji

Kompleksni informacijski sustavi zahtjevaju visoku razinu organizacije u razvoju softvera. Telefonska digitalna centrala odličan je primjer velikog sustava, čiju kompleksnost ne čini samo ogromni volumen kôda sadr�an u brojnim programskim cjelinama zvanim blokovi, već i dimenzija proizvodne linije koja se razlikuje za svako tr�i�te. De�ava se da u isto vrijeme na tr�i�tu postoje različite verzije telekomunikacijskog softvera za različite tipove telefonske centrale, �to biva diktirano ugovorom s korisnikom. Nadalje, svaka verzija ima svoj sustav i frekvenciju otkrivanja pogre�aka, pa iste verzije programa ne moraju nu�no imati jednako ispravljene gre�ke. Iz svega ovog se vidi da ako se �eli izbjeći nesređenost i kaotičnost u poslovanju, sustav razvoja takvog softvera mora biti na zavidnoj razini organizacije. Takve sustave jedino mogu odr�avati i razvijati velike mre�e međusobno povezanih stručnih timova. Dokumentacija mora imati striktno određeni tok i pravila pisanja, kako bi se uvela preglednost i mogućnost snala�enja. Procesi koji podr�avaju takvu dokumentaciju, moraju biti pedantno definirani i vođeni, a osobe odgovorne za njih dovoljno kompetentne da ih prilagođavaju prema potrebama razvoja. Sve to mora podr�avati vrlo jaki informacijski sustav i organizacijska struktura bez koje je sve to nemoguće izvesti.

1.2.1 Osiguravanje kvalitete u razvoju telekomunikacijskog softvera

Veliki doprinos novim metodama razvoja softvera pridonijeli su radovi i istra�ivanja na području osiguravanja kvalitete, standarda i certifikacijskih normi. Softverska industrija susreće se s problemima kvalitete iz razloga �to diktat tr�i�ta zahtijeva �to kraće vrijeme isporuke i �to kvalitetnije proizvode. Da bi u takvim okolnostima neka tvrtka bila konkurentna, mora biti na visokoj organizacijskoj razini, �to podrazumijeva adekvatno planiranje, optimalan sustav dokumentiranja, multiprocesnu organizacijsku strukturu, pouzdan i brz informacijski sustav i visokokvalificirane i kompetentne stručnjake. Uz ISO


15

9000:2000 normu kao osnovu i prvi korak cjelovitom ovladavanju kvalitete, telekomunikacijska industrija koristi jo� neke kompleksnije i zahtjevnije modele osiguravanja kvalitete softverskog proizvoda kao �to je CMM, tj. CMMI.

CMM i CMMI modeli razvoja

Sposobnost i zrelost organizacije za razvoj softvera (engl. Capability Maturity Model - CMM) ocjenjuje se modelom razvijenim i objavljenim 1991. godine od strane Software Engineering Institute (SEI). To je otvoreni sustav izgradnje i pobolj�anja softverskih istra�ivačkih i razvojnih organizacija, koji omogućuje postupno uvođenje procesnih elemenata na 5 razina:

1. INICIJALNA RAZINA: Cijeli razvojni proces percipiran je poput "oblaka" u kojem nema definicije njegovih elementarnih procesa, te se procjena izvr�i nakon isporuke.

2. RAZINA PONOVLJIVOSTI PROCESA: Ograničena definicija procesa; procesi se percipiraju kao crne kutije, a mjerljivost je moguća na mjestima kontrole ili miljokazima postavljenim između tih procesa.

3. RAZINA DEFINIRANIH PROCESA: Procesi su definirani s podprocesima, postoji sljedivost u projektnoj metrici unutar procesa.

4. RAZINA UPRAVLJAJUĆIH PROCESA: dobro definirani procesi, mjerljivi na mjestima kontrole postavljenih na vezama između podprocesnih faza koje predstavljaju aktivnosti.

5. RAZINA OPTIMIZIRAJUĆIH PROCESA: potpuna sljedivost akcija unutar podprocesa i potpuna definicija procesa, čine potpunu kontrolu razvojnog procesa.

Inicijativa stvaranja ovog modela do�la je od strane vlade SAD-a, u svrhu postizanja sposobnosti razvoja softvera visoke kvalitete, gdje je kori�ten prvi put od ministarstva obrane u avionskoj i svemirskoj industriji. Ubrzo, model je prepoznat i kori�ten od drugih industrija razvoja softvera, a pokazao se vrlo koristan i u telekomunikacijskoj industriji. U Ericssonovim korporacijama prihvaćen kao glavna okosnica pobolj�anja unutar softverske sistemske inicijative. Danas je CMM pre�ao u Capability Maturity Model Integration (CMMI), tj. u model koji nije koncentriran isključivo na sposobnost razvoja softverskog proizvoda, već integrira razvoj procesa i proizvoda, uključujući sistemsko i softversko in�enjerstvo. U ovom radu opisane tehnike simulacije, optimizacije, predikcije i dobivanja znanja iz procesa pripadaju elementima 4. i 5. razine CMMI modela [17][37].

1.2.2 Procesi razvoja softvera

Manji programski paketi pri razvoju ne zahtjevaju slo�enu organizacijsku strukturu i disciplinu razvoja. Nerijetko se sreće u praksi da mnoge male tvrtke pod softverskim in�enjeringom podrazumijevaju direktno kodiranje, odnosno programiranje radnog zadatka. Međutim razvoj ozbiljnog i kompleksnog softvera podrazumijeva puno vi�e. Samo kodiranje mali je djelić razvojnog ciklusa, neznatan s obzirom na analizu i sintezu problema koje zahtijeva kupac. Međutim, razvoj softvera je puno vi�e. Budući da je softver apstraktan, njegova prava proizvodnja odvija se u ljudskom umu, gdje misaoni tokovi stvaraju


16

podatkovne strukture, koje kodiranjem, tj. programiranjem bivaju simbolički formirane i materijalizirane izvr�avanjem na računarskim sustavima. Softversko in�enjerstvo, prema definiciji IEEE-a, je primjena sustavnog, discipliniranog i mjerljivog pristupa na razvoj, rad i odr�avanje softvera. Odnosi se na teoriju, metode, modele, pomagala i tehnike potrebne za razvoj softvera, stoga sve �to se mo�e iskoristiti iz drugih disciplina treba primijeniti. Posljednjih godina ide se u tom smjeru pa je postignut velik napredak u razvoju. Dominantne faze tradicionalnog razvoja softvera, implementacija i ispitivanje, potisnute su u korist rukovođenja, upravljanja zahtjevima i razvoja [17].

Proces vođenja projekta ─ PROPS

Ericssonov opći model za vođenje projekata u vi�eprojektnoj okolini naziva se PROPS. Smatra se jednim od najboljih modela za vođenje projekta. Slijedi vodopadni model razvoja ili njegovu inkrementalnu varijantu. Njegove prednosti očituju se kod kompleksnih sustava kao �to su telekomunikacijski čiji se �ivotni ciklus prote�e na vi�e desetljeća. Model je temeljen na tri bitna aspekta: poslovnom, organizacijskom i operativnom. Model se sastoji od 4 faze: faze prethodne studije, studije izvodljivosti, faze izvr�avanja i faze zatvaranja. U fazi prethodne studije provjerava se ideja s poslovne, tehničke i komercijalne strane. Studija izvedivosti osigurava osnovu za dobar i uspje�an projekt, nakon koje slijedi faza izvr�avanja projekta, koja je najobimnija i najzahtjevnija. Na kraju dolazi faza zaključivanja projekta, koja osigurava ponovljivost uspje�nih aktivnosti unutar projekta. Također, model se sastoji od vi�e paralelnih linija, tj. procesa: nadzor, vođenje i izvr�enje projekta. Uz linije definirana je i dokumentacija koja treba na određeni način biti vođena. Faze su međusobno odvojene točkama odluke (engl. tollgate) na kojima se donose određene odluke za daljnje odvijanje projekta. Postoji 6 točaka odluka: nulta označava početak projekta, prva početak studije izvodljivosti, druga početak faze izvr�avanja, treća nastavak faze izvr�avanja prema zacrtanom planu, četvrta označava isporuku proizvoda, a peta početak faze zaključivanja. Mjesta kontrole ili miljokazi (engl. milestone) predstavljaju va�na mjerna mjesta unutar projekta, čije vrijednosti moraju biti dosegnute. Za razliku od točaka odluke koje su postavljene na točno definirana mjesta, mjesta kontrole mogu biti proizvoljno postavljena i u bilo kojem potrebnom broju kroz projekt. PROPS je ugrađen u mnoge procese razvoja softvera u telekomunikacijskoj industriji korporacije Ericsson kao �to su AXE10 Software Development Process koji pripada naprednoj vrsti linearnih ili vodopadnih razvojnih procesa telekomunikacijskog softvera [5][17][38].

Linearni ili vodopadni procesi

Prvi razvojni procesi u softverskoj industriji bili su relativno jednostavni i preslikavani su iz drugih industrija. Strukturirani kao linearni procesi, odnosili su se isključivo na razvoj proizvoda. Linearni ili vodopadni procesi (engl. waterfall processes), podijeljeni su na niz odvojenih faza, gdje ne postoji paralelizam i svaka slijedeća faza ne mo�e započeti ako prethodna nije zavr�ena. Linearni procesi u proizvodnji softvera, u svojoj osnovnoj strukturi (Slika 1-2). Sastoje se od sedam faza:


17

ZAHTJEVI

RAZVOJ

ODR�AVANJE

VERIFIKACIJA

ISPITIVANJE

OCJENAIZVEDIVOSTI

KODIRANJE

1

0

3

4

2

Slika 1-2: Linearni ili vodopadni proces (engl. waterfall) prikazan u 7 faza; slijedeća faza

ne mo�e započeti dok prethodna nije zavr�ena. Trokutaste zastavice označavaju točke odluke, tj. mjesta na kojima se vr�i nadzor projekta.

Faza definicije zahtjeva podrazumijeva određivanje ciljeva i granica projekta kojeg treba započeti, količinu resursa i vremenska ograničenja. Ova faza je inicirana dokumentom koji je sklopljen s naručiteljem, a u kojem se nalaze glavni zahtjevi �to se i kakva funkcionalnost tra�i, postavljaju se zahtjevi na kvalitetu, te u kojim vremensko-financijskim okvirima funkcionalnost mora biti izvedena. U ocjeni izvedivosti tim stručnjaka i rukovodstvo projekta promatraju i ispituju mogućnosti izvedbe. Predla�u se načini rje�avanja i izrađuje se vi�e studija. Promatra se tehnička izvedivost, operativna prihvatljivost i ekonomska opravdanost. Faza ocjene izvedivosti zahtijeva detaljnu analiza sustava i analizu zahtjeva. Analiza se radi za svaku alternativu, nakon koje se izabire ona koja se smatra optimalnom. Slijedi faza razvoja gdje se izabrana alternativa analizira i razvija u skladu sa zahtjevima, ali jo� uvijek u vidu dokumentacije. Precizno se definiraju hardver i softver. Dekomponiranjem sustava dolazi se do specifikacije modula i njihovog komuniciranja. Realizaciju sustava kodiranjem vr�e dizajneri na temelju napisane dokumentacije u prethodnim fazama. Nakon kodiranja slijede ispitivanja sustava i verifikacija, tj. implementacija sustava. Pogre�ke nakon implementacije sustava, rje�avaju se i odr�avaju postimplementacijom, tj. u fazi odr�avanja. Nedostatak linearnih procesa su nasljeđivanje problema i gre�aka iz prethodne faze. Problem koji nastane u početnim, �iri se u ni�im fazama i te�ko ga je ili nemoguće ispraviti. Linearni procesi zahtjevaju veliko vrijeme razvoja i pogodni su za velike i slo�ene projekte, dok za male mogu biti neisplativi. Također, vrlo je te�ko uklopiti naknadne promjene zahtjeva, jednom kad je već otpočeo razvoj. Vrlo brzo se pokazalo da softver zahtjeva djelotvornije procese koji zahtjevaju uigranije timove, veliku procesnu adaptivnost, definiranu organizacijsku strukturu i kompetentne stručnjake. Danas se linearni procesi kombiniraju s evolucijskim ili iterativnim procesima, ili zadr�avaju svoju linearnu strukturu i u određenim fazama uvode paralelizam s ciljem bolje iskoristivosti ljudskih resursa i skraćenja vremena trajanja. Brzina promjena koju diktira tr�i�te, bitno utječe na kvalitetu i pouzdanost softverskog proizvoda, jer skraćuje rokove isporuke. Nekvalitetni proizvod te�ko pronalazi kupca, a nepo�tivanje rokova isporuke daje prednost konkurenciji. [5][17][51]


18

Iterativni razvojni proces ─ RUP

Model razvoja zvan RUP (engl. Rational Unified Process) sličan je PROPS-u, s tom razlikom da je RUP iterativni razvojni model, gdje se svi sadr�ajni aspekti iterativno razvijaju uz dodavanje novih funkcionalnosti. RUP kao model pogodniji je za razvoj manjih projekata, a budući je iterativan, daje brojne revizije gotovog proizvoda [17]. Sastoji se od 4 faze: pokretanje ideje, elaboracije arhitekture, konstrukcije verzije i tranzicije proizvoda. Po zavr�etku svake faze, kao i u PROPS-u, nalazi se točka odluke. Vrlo često se koristi za kreiranje telekomunikacijskog softvera koji se stvara na vanjskim platformama, tj. izvan AXE sustava. U ovom radu neće se posebno obrađivati ovaj model u svrhu simulacije i optimizacije.

1.3 Odr�ivi razvoj i za�tita okoli�a

Razvijati se odr�ivo znači brinuti se o očuvanju okoli�a kvalitetnijim kori�tenjem svih resursa, te aktivno pridonositi dugoročnoj socijalnoj, ekonomskoj i ekolo�koj stabilnosti zajednici kojoj pripadamo. Također, vrlo je va�no osiguravati sigurno i zdravo radno okru�enje za sve zaposlenike, osiguravati jednake mogućnosti svim zaposlenicima, sve u svrhu te�nje da softverski proizvodi i usluge budu iznad očekivanja tr�i�ta s obzirom na najvi�e etičke standarde. Odr�ivi razvoj je dugoročna i sveobuhvatna poslovna strategija, gdje isključivo fokusiranje na profitabilnost znači dugoročni gubitak za ljudsku rasu, dru�tvene, ekolo�ke i poslovne sustave. Stoga je potreban zaokret u razmi�ljanju i stavovima, gdje se iznova mora krenuti od čovjeka i okoli�a. Trka za profitom donosi nekvalitetni softverski proizvod, nezadovoljstvo radnika i korisnika, pad sigurnosti i iscrpljivanje ljudskih radnih resursa iznad njihovih granica. Budućnost ne ovisi o ekonomsko-marketin�kim diktaturama, već u harmoniziranju proizvodnje i tr�i�ta sa zahtjevima prirodnih i ljudskih istinskih potreba i evolucije. Dana�nji polo�aj čovjeka u galopirajućoj tehnologiji je neodr�iv: potencijalna informacijska preopterećenost jedna je od negativnih efekata informatizacije [4]. Ljudske sposobnosti primanja informacija čulima i razumom su ograničene, a povećani pritisak u tom smislu izaziva neurozu, bijes i otupljelost. Informacijska tehnologija pojavljuje se kao sredstvo napada na privatni �ivot, izvor stresa, pojačanja otuđenosti, manipulacije i sukoba. Pitanje je do koje granice će ljudsko tijelo biti sposobno prihvaćati ogromne količine informacija i različitih podra�aja, bez da ostane traga na njegovom psihičkom zdravlju. Mnoga od novijih tehnolo�kih unaprijeđenja namijenjena radu u uredima, ignoriraju logiku ljudskog pona�anja. Na taj se način u uredski �ivot i rad unosi dodatna konfuzija. Neprilagođena tehnologija i procesi rezultiraju stresnim radnim okru�enjem, radnim mjestom koje nije humano niti efikasno. Dana�nji uredi, preplavljeni digitalnim napravama raznih profila, imaju malo veze s jednostavnim i shvatljivim radnim mjestom nedavne pro�losti [13]. Stoga, odr�avanje kvalitete proizvoda i sustava, kao i rje�enje informacijske krize ima, osim ekonomske, i dru�tveno-humanističku va�nost koja zahtijeva radikalnu promjenu svijesti. Postavlja se i pitanje definicije kvalitete: da li je kvaliteta vezana isključivo uz profit i zadovoljstvo kupaca. Osiguranje kvalitete znači odr�ivi razvoj, tj. osiguranje bolje kvalitete svima � kako sada�njem nara�taju, tako i onima koji tek dolaze. Rukovodstva moraju naučiti razmi�ljati o dru�tvenoj vrijednosti i vrijednosti okoli�a, unaprijed, uključujući i radna mjesta. Poslovni svijet trebao bi doprinositi odr�ivom ekonomskom razvoju, radeći sa zaposlenicima, njihovim obiteljima, lokalnom zajednicom i dru�tvom u cjelini, kako bi se pobolj�ala kvaliteta �ivota. Dana�nja ekonomija započinje eru ekodjelotvornosti, kao neophodni strate�ki element


19

u ekonomiji zasnovanoj na znanju i njegovoj integraciji. U tome le�i buduća konkurentnost [4]. Napredni �ivi organizmi svoju kompleksnost zahvaljuju izuzetnoj moći organizacije prirode; recikliranju prethodnih iskustava i nadogradnji na jednostavnijim već stvorenim strukturama. Softver kao ljudski produkt direktno je ovisan o evolutivnim snagama prirode koje su ispoljene kroz ljudsku kreativnost. Budućnost će zahtijevati da se kruti racionalni umovi podvrgnu diktatu prirodnih zakona stvaranja, a ne diktatu tr�i�ta i trci za profitom koji već sad pokazuju katastrofalne promjene na dru�tvu i u okoli�u. Odr�ivi razvoj moguća je iskra u stvaranju novih kvaliteta proizvodnje, raspodjele i �ivota. [4][10][12][13][15][16]


20

2 Model razvojnog procesa softvera

2.1 Dinamika i modeliranje sustava

Sistemska dinamika je metoda kontinuirane simulacije sustava s povratnom spregom, tj. sustava u kojima pojedini elementi mogu utjecati na sebe same preko lanca uzroka i posljedica. Modeli pritom zdru�uju pojedinačne događaje i prikazuju ih kao kvazikontinuirane tokove. Procesi koji se odvijaju u sustavu, u pravilu nisu lako uočljivi, tako da je sustav potrebno modelirati u odgovarajućem vremenskom okviru i s odgovarajućim stupnjem zdru�ivanja događaja. Procesi koji se modeliraju u sistemskoj dinamici promatraju se sa stajali�ta različitih resursa (npr. ljudi, narud�bi ili novca) koji prelaze iz stanja u stanje. Osnivač sistemske dinamike i njezine primjene u području managementa, te u dru�tvenim sustavima, bio je profesor Jay Forrester, profesor menad�ementa na Sloan School of Management, Massachusetts Institute of Technology. Godine 1946. Forrester je vodio MIT Digital Computer Laboratory u kojem je izgrađeno prvo digitalno računalo, izumio je magnetsku memoriju sa slučajnim pristupom koja je omogućila razvoj pouzdanih digitalnih računala. Također, upravljao je razvojem SAGE sustava za zračnu obranu sjeverne Amerike. Zadnjih godina zagovara kori�tenje sistemske dinamike kao osnove relevantnijeg obrazovanja za pred�kolski i �kolski uzrast. Modeli sistemske dinamike omogućuju istra�ivanje dinamike razvoja dru�tvenih, tehničkih i biolo�kih sustava u vremenu, te analizu upravljanja radom sustava. Sistemska dinamika koristi se u različitim oblicima poslovnih odluka kao �to su problemi zapo�ljavanja, rast poduzeća, proizvodnja i zalihe, vođenje projekta, interaktivne poslovne igre i sl. [34]

2.2 Svrha modela i principi modeliranja

Model je pribli�ni prikaz sustava ili procesa koji slu�i za razumijevanje sustava, te za njegovo mijenjanje ili upravljanje njime. Modeli moraju biti �to jednostavniji, a ipak ispravni za svrhu za koju su napravljeni. Modeli omogućuju opis kompleksnih fenomena, njihovo bolje razumijevanje, komunikaciju onih koji rje�avaju problem i samo rje�avanje problema. Modeli u istra�ivanju prirode, uključujući i ljudsko pona�anje, slu�e za razumijevanje strukture i funkcioniranje prirode, te kao oruđe za postavljanje i dokazivanje hipoteza, tj. formuliranje ideja. U in�enjerstvu i ekonomiji modeli slu�e za oblikovanje novih rje�enja, ispitivanje svojstava rje�enja, te izbor najpovoljnijeg rje�enja. Modeliranje zamjenjuje eksperimentiranje �u �ivo� koje obično zahtjeva dosta vremena, ima veliku cijenu, ponavljanje eksperimenata je skupo, te mo�e biti opasno. Modeliranje je umijeće, a ne znanost; zahtjeva zdrav razum, moć apstrakcije, sistematičnost i iskustvo. Treba se paziti kod izbora granica sustava s okolinom, stoga model treba obuhvatiti samo fenomene od interesa [33, Osnove modeliranja]. Previ�e slo�ene i detaljne modele te�ko je razumijeti i vrednovati, dok pojednostavljeni modeli gube bitne elemente za obja�njavanje uzroka pona�anja.


21

Preporuka je razvijati model u jednostavnim modulima s dobro definiranim funkcijama. To olak�ava izgradnju i provjeru modela. Također, po�eljno je koristiti metode za razvoj algoritama i programa, koje su sastavni dio softverskog in�enjerstva. Kako bi se model mogao s pouzdano�ću koristiti, razvija se u malim koracima, gdje se modulima obavezno pojedinačno provjerava logička i kvantitativna ispravnost [33][34].

Rezultat istra�ivanja pokazuje kako to čine eksperti za modeliranje:

• modele razvijaju tijekom du�eg vremena,

• intenzivan kontakt s klijentima,

• koriste analogije i crte�e,

• razvijaju vi�e alternativnih modela,

• uvijek kreću od malog modela i pro�iruju ga,

• 15% vremena tro�e na razmi�ljanje o kontekstu problema i njegovo razumijevanje,

• 60% vremena tro�e na razvoj strukture modela i analizu podataka,

• 15% vremena tro�e na vrednovanje modela, procjenu korisnosti i prihvatljivosti za klijenta,

• 10% vremena tro�e na procjenu parametara i računanje rezultata pomoću modela [33].

2.3 Osnovne ideje simulacije

Simulacija omogućuje kvantitativnu analizu poslovnih procesa i daje odgovore na pitanja ��to-ako?� Značajke poslovnih procesa odvijaju se u vremenu, uključuju slučajne veličine, koriste resurse poslovnog sustava, velik broj međusobno povezanih elemenata, gdje su ljudi sudionici poslovnog procesa. Kao i kod ostalih modela, principi razvoja simulacijskih modela zahtijevaju određivanje granice između sustava i okoline, tra�enje odgovarajuće slo�enosti odnosno detaljnosti modela, vrednovanje modela. Simulaciju trebamo kad jeanaliza modela analitičkim metodama previ�e slo�ena, te kad su eksperimenti s realnim sustavom skupi, opasni ili nemogući. Stvaranje povjerenja u simulacijski model traje tijekom cijelog procesa izgradnje modela. U njemu moraju sudjelovati i eksperti za simulacijsko modeliranje i donositelji odluka. Za vrednovanje simulacijskog modela koriste se statističke i računarske tehnike, procjene eksperata, grafički prikaz izlaznih varijabli modela i animacija rada modela. Simulacijski modeli nisu manje vrijedni zato �to su aproksimacije stvarnosti [32]. Upravo ih to čini korisnim, jer iz stvarnosti uzimaju one najva�nije dijelove. Tako je stvarnost lak�e razumijeti. Upravo u tu svrhu bilo je korisno simulirati razvoj softvera obojenim Petrijevim mre�ama. Modeliranjem simulacijskog sustava, bilo je moguće stvarati određeno znanje o stvarnom procesnom sustavu i njegovom pona�anju.


22

2.4 Opis modela razvojnog procesa softvera MRPS

Kompleksnost razvoja telekomunikacijskog softvera zahtjeva slo�enu projektnu organizaciju s akcentom na efikasne projektne procese i tokove dokumenata. Najkraća definicija svakog razvojnog procesa softvera, bez obzira bio on linearni ili iteracijski, mo�e se svesti na četiri faze: analizu, dizajn, testiranje i isporuku (Slika 2-1). U procesu isporuke sadr�ani su i dijelovi �ivotnog ciklusa softverskog proizvoda koji se odnose i na odr�avanje proizvoda. Međutim, u ovom slučaju, proces razvoja kao svoj izlaz ima gotov softverski proizvod, dok faze naknadnog odr�avanja nisu uključene u ovu studiju. U ovom poglavlju bit će opisan model procesa razvoja softvera, na temelju kojeg će se u idućem poglavlju izgraditi simulacijski model razvojnog procesa softvera. Model razvojnog proces softvera (MRPS) i pripadajućeg mu hardvera, nastao je kao poku�aj pojednostavljivanja razvojnog procesa telekomunikacijskog softvera AXE 10 koji prati strukturu PROPS-a. MRPS je pseudoproces koji prati logiku slo�enih razvojnih procesa softvera, ali sadr�i neke pojedinosti preuzete iz RUP-a. Sustav dokumentacije i projektne organizacije, definiran je proizvoljno na načelima stvaranja razvojnih procesa, te također predstavlja pojednostavljenu sliku istih. MRPS je definiran u svrhu prezentacije, pristupa modeliranju i simulaciji kompleksnih poslovnih procesa metodom obojenih Petrijevih me�a.

2.4.1 Faze MRPS-a

Prva faza naziva se analiza i započinje zahtjevom, kao ulaznim dokumentom (Slika 2-1), koji se sastoji od �to točnije definiranih �elja kupca za kojeg se softverski proizvod razvija. Početak prve faze označen je mjestom kontrole MK0 (engl.Milestone, MS0) [38]. Faza analize zavr�ava u točki odluke TO2 (engl.Tollgate, TG2), gdje se na temelju rezultata analize zahtjeva, proračuna tro�kova resursa i zaključaka sistemske studije, mora donijeti odluka da li se kreće u daljnji razvoj proizvoda ili se odustaje od istog. U slučaju da je odobren nastavak razvoja softverskog proizvoda, započinje faza softverskog dizajna u kojoj se vr�e daljnje analize i dekomponiranja funkcionalnosti. Funkcionalnosti su podijeljene na programske jedinice koje se nazivaju blokovi ili moduli. Svaki modul tvori svojevrsnu zasebnu cjelinu koja je definirana određenom količinom funkcija koje treba ta cjelina izvr�iti. Faza softverskog dizajna zavr�ava kodiranjem funkcionalnosti i jednostavnim, osnovnim testom (engl. Basic Test). Nakon �to su funkcionalnosti iskodirane, tj. nakon MK3, započinje faza funkcijskog testa (engl. Function Test) u kojem se blokovi podvrgavaju ispitivanju u simuliranoj funkcijskoj okolini. Uz softver obično se razvija i hardver (HW), stoga je u tom slučaju potrebno izvr�iti i zasebno testiranje hardvera. Nakon �to su i softver i hardver istestirani, priskače se sistemskom testu (engl. System Test), gdje je testirana cjelina koju čini i hardver i softver. Točka odluke TO4 nagovje�tava zavr�etak faze testiranja u kojoj je sustav manje ili vi�e istestiran. Problem koji se redovito javlja u fazi testiranja je ka�njenje prethodnih faza, te zbog toga faza testiranja kraće traje. Budući da vremenski rokovi ne smiju biti �probijeni�, zbog kraće faze testiranja u najvećem broju slučajeva, smanjuje se pouzdanost, a time i kvaliteta proizvoda. Upravo u TO4 se odlučuje da li pomaknuti rok isporuke ili se dr�ati zadanih rokova na u�trb kvalitete proizvoda.


23

TO2

TO4

TO5MK0

MK

3

Ulazni dokument:ZAHTJEV

Dono�enje odluke:Početak DIZAJNA

Početak fazeTESTIRANJA

Početak fazeISPORUKE

Zatvaranje projekta:analize i raporti

D I Z A J NA

N A

L I Z A T

E S

T I

R A

NJ

EI S

P O

R U

K A

Proizvod

Slika 2-1: Četiri osnovne faze MRPS-a koji prati strukturu PROPS-a

Pomicanje rokova redovito povećava tro�kove razvoja i poskupljuje proizvod. Odluči li se isporučiti proizvod, započinje se faza isporuke u kojoj se vr�e zavr�ne radnje poput pakiranja proizvoda, uputstava za upotrebu i izvje�taji kvalitete istog. Zavr�etak faze isporuke označava se s TO5.

2.4.2 Dekompozicija procesnih faza MRPS-a na podprocese

Podprocesi faze analize

Svaka faza u razvoju softvera sastoji se od podprocesa (Slika 2-2). Podprocesi mogu slijediti jedan za drugim, tvoreći tako jednu fazu kao cjelinu, ili mogu biti izvr�avani paralelno u nekim dijelovima vremena. Tako se vidi da je faza analize sastavljena od 4 podprocesa, od kojih su tri sekvencijalna (analiza zahtjeva, studije izvedljivosti sustava i analize sustava), dok je posljednji (plan resursa) paralelan s podprocesom sistemske analize. Podproces nazvan analiza zahtjeva započinje, kao i sama faza analize, ulaznim dokumentom na kojem su specificirani zahtjevi kupca � zahtjevom. Kao �to je vidljivo u tablici (Tablica 2-1), u svakom podprocesu nastaju određeni dokumenti za kojeg je odgovorna jedna od osoba u razvojnom timu. Tako se vidi da u podprocesu analize zahtjeva nastaju dokumenti specifikacija zahtjeva i sistemska skica, za koje je odgovoran analizator sustava. Podproces sistemske studije započinje ulazom tih dokumenata i označava se s MK1, te traje sve do TO1. Obično se u tom prvom dijelu faze analize razmatraju i predla�u različita rje�enja i eventualni se za svako od


24

tih rje�enja rade prototipovi, a na temelju toga se poku�ava napraviti i određeni financijski osvrt. Međutim, s TO1 mora se odlučiti kojim putem će se krenuti u daljnji razvoj softverskog proizvoda, tj. treba se izabrati jedna od alternativa. Izborom jednog od koncepata započinje podproces sistemske analize, a paralelno s njim započinju i pripreme projektnog rukovodstva, analize tro�kova, resursa i planiranje konfiguracije radne okoline u podprocesu planiranja resursa. Podproces planiranja resursa započinje u MK2 ne�to kasnije, nego podproces sistemske analize. Razlog tome je taj �to je za pisanje projektne dokumentacije potrebno �to vi�e tehničkih pojedinosti koje se nalaze u dokumentima implementacije, sve s ciljem �to bolje procjene i planiranja razvoja. Često se ti svi dokumenti nadopunjuju iteracijski poprimajući veći broj revizija, �to govori da su međusobno vrlo ovisni. Dakle, u podprocesu sistemske studije nastaju dokumenti softverske i hardverske razrade, za čiju izradu je također odgovoran analizator sustava, na temelju kojih se u podprocesu sistemske analize stvaraju dokumenti implementacije softvera, hardvera, te dokument test analize. Podprocesom planiranja resursa nastaje projektna dokumentacija: plan kvalitete, konfiguracijski plan, plan rizika i plan mjerenja s odgovornostima kao �to su navedene u tablici (Tablica 2-1). Zavr�etkom podprocesa planiranja resursa dolazi se do TO2 u kojoj treba biti done�ena odluka da li nastaviti daljnji razvoj dotičnog softverskog proizvoda ili odustati od razvoja istog. Uobičajeno je u praksi nastaviti s razvojem proizvoda ili čak dogovoriti druge uvjete s naručiteljem, bio on sponzor projekta ili neki kupac-klijent. Uglavnom do odustajanja dolazi u slučaju kad se proizvod razvija za tr�i�te s vrlo jakom konkurencijom. U tom slučaju, ispitivanje tr�i�ta i odlična procjena vlastitih mogućnosti i resursa od ključne je va�nosti za stvaranje kvalitetnog proizvoda, ali i za opstanak projekta, a mo�da i same tvrtke.

TO2

MK

0

Analizazahtjeva

Sistemstudija

SistemAnaliza

Planresursa

D I Z A J N

Podjelazadatka

Moduldizajn Kodiranje

T E S T I R A NJ E

Podjelazadatka Test Sistem

test

ISPORUKA

Pisanje uputa i inspekcije

Ispravakgre�aka

Pisanjeraporta

kvalitete

Instalacijai pakiranjeproizvoda

Osnovnitest

TO1

TO0

MK

1

MK

2

A N A L I Z A

TO3

MK

3

TO4

TO5

PROIZVOD

Slika 2-2: Prikaz podprocesa unutar MRPS-a. S donje strane procesnih faza vidljive su

točke odluke (crveni rombovi), a s gornje strane vidljiva su mjesta kontrole (zelene strelice). Podprocesi sadr�avaju aktivnosti razvoja i SW i HW.

Podprocesi faze dizajna

Nakon �to je done�ena odluka za nastavak razvoja softverskog proizvoda, na temelju implementacijske dokumentacije i dokumenta test analize, dijeli se posao na tri tima: softverski, hardverski i test tim. U slučaju da se razvija proizvod kojemu nije potrebna hardverska podr�ka, tada izostaje hardverska grana dokumentacije i tima. Međutim, kod telekomunikacijskog razvoja često je softver nerazdvojiv od hardvera, budući da nove funkcionalnosti zahtjevaju jednako i nadogradnju u softveru i hardveru. Softverski tim koristi softverski implementacijski dokument i dalje razvija ideju budućeg proizvoda. Sama


25

funkcionalnost dalje se dekomponira na podfunkcionalnosti, blokove ili module, koji se dalje definiraju preko određenog broja funkcija koje trebaju biti kodirane, tj. isprogramirane i istestirane. Svaki takav modul, ovisno o njegovoj kompleksnosti, daje se jednom ili vi�e dizajnera softvera da ga razviju i izvedu osnovni test. Prije nego li dizajner pristupi kodiranju dodjeljenog mu modula, mora funkcije tog modula opisati i definirati u dokumentu funkcije modula koji je nastao daljnjim dekomponiranjem ideje buduće softverske komponente preuzete iz dokumenta softverske implementacije. Nakon kodiranja i osnovnog testa, dizajner je du�an napisati i opisati cjelokupnu funkcionalnost i funkcije modula u dokument zvan opis modula, koji osim opisa sadr�i blok i sekvencijalne dijagrame modula. U hardverskoj grani hardver in�enjer ima zadatak pribaviti određeni hardver ili podesiti simulacijsku okolinu. Također vrlo velikim projektima mogu biti dodijeljeni cijeli hardverski timovi stručnjaka koji razvijaju određeni hardver, međutim, ta opcije nije razmatrana u ovom modelu. Test grana, tj. test menad�er du�an je analizirati hardverske i softverske zahtjeve, te na temelju njih načiniti test plan i listu prema kojoj će isti biti testirani u fazi testiranja. Dakle, podprocesom modul dizajna jo� uvijek se ne programira, već se dalje razla�e i definira ideja budućeg softvera i tek nakon TO3 započinje paralelno kodiranje modula od strane dizajnera. Kako koja funkcija modula biva iskodirana, tako ona biva i testirana osnovnim testom od strane dizajnera. Osnovni test primjenjuje se samo u okvirima funkcije svakog pojedinog modula. Svi moduli moraju biti iskodirani i provjereni osnovnim testom do MK3, nakon kojeg započinje faza testiranja i glavni posao se prebacuje u test granu. Praksa pokazuje da je vremena gotovo uvijek premalo da bi se do kraja ispitale sve funkcije modula, stoga jo� uvijek ostaju skrivene pogre�ke u kodu, koje se nasljeđuju u fazi testiranja, a neke od njih bivaju isporučene s proizvodom na tr�i�te. �to je količina skrivenih pogre�aka veća, to je odr�avanje proizvoda zahtjevnije i skuplje, a potvrda tr�i�ne kvalitete, ni�a. Također, �to je prije pogre�ka nađena u ranijim fazama razvoja, to će budući proizvod biti kvalitetniji, ali i jeftiniji, jer cijena ispravljenja pogre�ke eksponencijalno raste s proteklim vremenom od definicije zahtjeva. Stoga veliki i kompleksni projekti zahtijevaju vrlo jaku procesno-projektnu organizaciju, gdje se poseban akcent daje na ispravan način pisanja dokumenata, �to zahtijeva određivanje i pravila za njihovo pisanje. Bit svega toga je pronala�enje �to boljeg kontroliranog mehanizma razvoja početne ideje i njenog dokumentiranja. Pisani dokument lak�e i jeftinije je inspektirati, nego kasnije tehnički testirati module i proizvod, te ispravljati pronađene gre�ke. Smatra se da je vi�e od 60% pogre�aka nađeno u fazi razvoja, prije nego li je softverski proizvod izbačen na tr�i�te, stoga nije čudno �to ozbiljne kompanije ula�u velike napore u ovladavanju dokumentima, kao nosiocima ideje proizvoda, upravo u fazi analize i početnih faza dizajna. Najkori�tenija tehnika za tu svrhu je metoda inspekcija softverskih dokumenata (engl. Software Document Inspections) i kratkih osvrta (engl. reviews), dok je u početnim fazama definicije i analize kori�tena tehnika ýgeneriranja idejaý, ýmo�danih olujaý ili ýsijevanja mozgovaý (engl. brain storming), sve u cilju pronala�enje optimalnog puta razvoja temeljne ideje.

Podprocesi faze testiranja

Moduli su iskodirani i pro�li su kroz osnovni test. Dizajn tim dovr�ava poslove oko pisanja dokumentacije vezane uz svaki modul pojedinačno, stvarajući zavr�ne revizije dokumenta, zvanog opis modula, u kojem je pohranjeno cjelokupno znanje i struktura iskodiranog modula. Prije nego li započne faza testiranja, svi softverski moduli moraju biti spojeni u jednu cjelinu koja se naziva softverski blok, kako bi mogla biti testirana konačna funkcionalnost ugrađenog, ali i nasljeđenog softvera. Da bi otpočela faza testiranja, na mjestu MK3 provjerava se da li je sintetiziran softverski blok i da li je test lista pro�la inspekciju pred


26

testiranje. Kad je sve to zadovoljeno započinje faza testiranja. Posao se raspodjeljuje tako da dizajneri započinju pisanje korisničke dokumentacije, tj. uputstava koja slu�e korisniku i daju mu temeljno znanje o proizvodu. Vrlo je va�no da dotična dokumentacija prođe dovoljan broj inspekcija, kako bi se postigla zadovoljavajuća kvaliteta izlazne korisničke dokumentacije. Kod inspektiranja korisničke dokumentacije koriste se iste metode kao i kod inspektiranja projektno-tehničke dokumentacije. Korisnička dokumentacija je, uz hardver i softver, jednako bitan dio proizvoda koji se isporučuje kupcu, stoga je njena razina kvalitete jednako bitna kao i kvaliteta tehničkog dijela proizvoda. U slučaju da je proizvod isključivo softverskog karaktera, posao funkcijskog testiranja se dijeli na određen broj testera, koji prema test listi pripremaju funkcijski test. Svaki tester dobiva određeni modul ili funkcijsku cjelinu koju mora ispitati na temelju test slučajeva izvedenih iz test liste. Bit funkcijskog testa je pronala�enje skrivenih pogre�aka u kôdu i izvje�tavanje istih, kako bi ih tim dizajnera mogao ispraviti. Kako razvoj telekomunikacijskog softvera prati i razvoj pripadajućeg mu hardvera, u tom je slučaju nu�no imati i hardver test tim koji je zadu�en za testiranje hardverske cjeline. U tom slučaju, nakon funkcijskog i hardverskog testa slijedi objedinjavanje softvera i hardvera u sustav ili se sve skupa ugrađuje u već postojeći sustav koji mora proći nakon toga kroz sistemski test, kako bi se otklonile pogre�ke sustava. Međutim, u slučaju razvoja softvera manjih veličina koji ne zahtjeva specijalnu hardversku podr�ku, niti se ugrađuje u veći postojeći sustav, testiranje se svodi samo na funkcijski test. Za izvje�tavanje svake pronađene pogre�ke u bilo kojem testu (funkcijskom, hardverskom ili sistemskom) koristi se izvje�taj pogre�aka, temeljni dokument procesa izvje�tavanja pogre�aka (engl. Trouble Report Process). Pro�irena dinamika procesa izvje�tavanja pogre�aka, nije posebno razlagana u ovom radu, iako je taj proces vrlo bitan u industriji razvoja softverskog proizvoda. Rečeno je već da rano otkrivanje pogre�ke u kôdu drastično smanjuje tro�kove proizvodnje, i čak uz temeljite inspekcije projektno-tehničke dokumentacije, statistike pokazuju da se 60% pogre�aka pronalazi u funkcijskom testu, 30% u sistemskom, a tek 10% u 6 mjeseci nakon �to je proizvod isporučen na tr�i�te ili kupcu. Ta statistika vrijedi kod suvremenog pristupa testiranju softverskog proizvoda koji je razvijan u organizaciji visoke i vi�e razine procesnog organiziranja. Neorganizirane tvrtke se ne mogu nositi s izazovima razvoja kvalitetnog i pouzdanog softvera. Njihovi su proizvodi upitne kvalitetete, a nepouzdanost istih uvelike je posljedica organizacijske stihije takvih tvrtki i nekompetentnosti njihovog rukovodećeg kadra.

Podprocesi faze isporuke

Faza isporuke započinje prola�enjem kroz TO4, gdje se odlučuje kada i pod kojim uvjetima će proizvod biti isporučen. Proizvod bi trebao do TO4 biti iskodiran i istestiran u svim podprocesnim fazama testa. Naime, vrlo često se u praksi de�ava da softverski proizvod nije temeljito i u potpunosti istestiran. Moguće je to zbog lo�eg planiranja ili procjene projektnog rukovodstva, ali i uslijed neplaniranih te�koća, koje se pojavljuju u pojedinoj fazi razvoja unatoč dobrom planiranju rizika. Stoga je nu�na procjena kvalitete proizvoda prije nego li isti bude isporučen na tr�i�te. Nedovoljno i lo�e testirani softverski proizvodi u podprocesima funkcijskog i sistemskog testiranja prenose svoju neispravnu funkcionalnost na tr�i�te, �to uvelike poskupljuje cijenu samog proizvoda. Nije samo problem u financijskim gubicima kroz procese odr�avanja isporučenog softverskog proizvoda, već i u razini pouzdanosti proizvoda. Povjerenje tr�i�ta u tvrtku koja razvija softver, rezultat je kvalitete proizvoda razvijenih i isporučenih od strane te tvrtke. Već i samo jedan natprosječno lo� proizvod mo�e dovesti u pitanje ne samo njegovo odr�avanje i daljnju proizvodnju, već i samu tvrtku koja dotični softverski proizvod razvija. U svakom slučaju, gubitak povjerenja u kvalitetu proizvoda neke tvrtke, znači gubitak sredstava koja dodatno moraju biti ulo�ena, kako u


27

odr�avanje proizvoda, tako i u jaču marketin�ku kampanju koja bi, bar djelomično, prikrila nesposobnost tvrtke i nisku kvalitetu njenog proizvoda. Stoga, projektno rukovodstvo mora donijeti odluku na temelju analize proizvoda tokom faza projekta, kolika je kvaliteta proizvoda, te na temelju toga poduzeti daljnje akcije, kako bi bio isporučen �to kvalitetniji proizvod sa �to manjim tro�kovima. Jedna od mogućnosti, je probijanje rokova isporuke i produ�enje faze testiranja, �to će rezultirati manjim tro�kovima, nego �to bi bili tro�kovi nastali preuranjenom isporukom nekvalitetnog proizvoda. Svaka ozbiljnija softverska kompanija procjenjuje kvalitetu svog proizvoda prije nego li je on isporučen, te shodno tome ima unaprijed dogovorenu razinu kvalitete ispod koje proizvod ne isporučuje. U fazi isporuke softverskom proizvodu se daje njegov konačni oblik, bilo da se fizički pakira u tr�i�nu ambala�u ili u softverskim po�iljkama (engl. shipment). Tim radnjama obično prethodi stvaranje instalacijskih programa (engl. install shield) koji su podr�ka kupcu pri instaliranju proizvoda u infomacijski sustav. U slučaju softverskih po�iljki, proizvodi se ne pakiraju u ambala�u, niti se isporučuju uz podr�ku instalacijskih programa. Budući da su takve isporuke po�iljki dijelovi jo� većih budućih sistemskih cjelina, obično se isporučuju lokalnom mre�om i pohranjuju u projektne baze podataka. Sistemski timovi sastavljaju softverske pakete pristigle od različitih razvojnih timova u konačnu cjelinu koja biva testirana na realnom sustavu. Vrlo va�na stavka procesa isporuke je pisanje dokumenta izvje�taja kvalitete, u kojem su sadr�ane analize pogre�aka nastalih u razvoju proizvoda, pa bile one otkrivene u inspekcijama dokumenata ili u fazama testiranja proizvoda. Također su pohranjene informacije o potro�nji resursa i analize rezultata mjerenja procesa. Svi ti podaci mogu biti sagledavani od savjesnih rukovodećih timova s ciljem da uka�u na propuste i daju smjernice za pobolj�anje kvalitete i razvoj nekih budućih softverskih proizvoda, koji će biti razvijeni pod sličnim uvjetima. Vrijednost izvje�taja kvalitete je proporcionalna količini ulo�enih aktivnosti mjerenja, praćenja i pobolj�anja sustava razvoja softvera, na sličan način kako je to opisao Deming. To je jedini način da se osigura kakva-takva preglednost cijelog �ivotnog ciklusa razvoja softverskog proizvoda, koji biva izra�en jezikom parametara, bitnih za razvoj kvalitetnog proizvoda, u određenom vremenskom roku. Samo tako, na temelju prethodnih iskustava, moguće je svrsishodno utjecati na pobolj�anje budućih proizvoda. Dakle, kao rezultat razvoja softverskog proizvoda, uz sam proizvod, i korisničku dokumentaciju, dobiva se cijeli niz procesno-projektnih dokumenata, među kojima su i oni koji sadr�e znanje kako cjelokupni sustav di�e i stvara. Veliki nedostatak takvog načina umjeravanja i pode�avanja sustava je taj �to je potreban veći broj različitih projektnih iskustava s istim timovima na istom ili sličnom proizvodu. Takvi kompleksni razvojni procesi traju mjesecima, a ponekad i godinama, te je zbog toga vrijeme pora�avajući faktor. Nemoguće je u tim velikim periodima i kroz du�e vrijeme zadr�ati promjene koje trpi projektni kadar. Moguće su fluktuacije kadrova, promjene diktata tr�i�ta i mno�tvo drugih, jo� nedovoljno istra�enih, parametara za koje tek treba biti otkrivena statistika. Nemoguće je procjenjivati kvalitetu proizvoda u kojemu sudjeluje mno�tvo ljudi. Na ljude i na njihove radne učinke, zadovoljstvo i kompetenciju, utječu mnogi parametri, koji uglavnom nisu obuhvaćeni uobičajenom studijom kvalitete razvoja softvera. Moguće je samo davati pretpostavke i poku�ati izgraditi neki početni model ocjenjivanja i predikcije takvih kompleksnih proizvodnih sustava. Jasno je da se takav mehanizam sastoji od velikog broja skrivenih mehanizama koji ne pripadaju samo sferi tehnike, ekonomije i organizacije rada, već psihologije, sociologije pa i fiziologije čovjeka. Ne smije se smetnuti s uma da je glavno proizvodno pomagalo u razvoju proizvoda informacijske ere, čovječji mozak, a kao takav jo� je uvijek nedovoljno zastupljen u svim analizama proizvodnih sustava, također kao i sam čovjek. Jedno od slijedećih poglavlja osvrnut će se na moguće rje�enje tog problema, tj. kako obuhvatiti �to veći broj različitih informacija vezanih uz stvaranje veličanstvenih oruđa kao �to je to softver dana�njice.


28

Također, postoji alernativna mogućnost; kako umjeriti i opisati dinamiku i pona�anje tako kompleksnog proizvodnog sustava, kao �to je to proces razvoja softvera, i to u puno kraćem vremenskom roku, s mogućno�ću pronala�enja optimalnih uvjeta i vrijednosti parametara koji utječu na povećanje kvalitete proizvoda. U ovom radu bit će ukratko obja�njena metoda simulacije i optimizacije razvojnog procesa softvera putem obojenih Petrijevih mre�a.

2.4.3 Struktura procesnih uloga u MRPS-u

Projektni tim ima slojevitu organizacijsku strukturu. Takve strukture su nu�ne, kako bi se izgradio pouzdani proizvodni mehanizam, potreban za realizaciju jedne ideje u konačni softverski proizvod. Razvojni proces softvera mo�emo definirati kao princip stvaranja kojim oblikujemo neku funkcionalnost iz početne ideje i utjelovljujemo putem softverskog kôda u informacijskom sustavu. Početnu ideju percipiramo kao zahtjev kupca na �eljenu funkcionalnost koja prolazi kroz određeni tretman. Akceptirana ideja postepeno biva ekspandirana i transmutirana kroz misaone tokove i mentalni napor razvojnog tima, sve do konačno realiziranog proizvoda. Stoga, budući softverski proizvod mo�emo smatrati esencijom misli i znanja koncentriranih u svrhovitu apstraktnu formu softverskog kôda. Dakle, vrlo je jasno da buduća kvaliteta proizvoda neće isključivo ovisiti o uvjetima rada, procjeni tr�i�ta ili te�ini izvedbe zadatka, niti će ovisiti o sirovoj statistici praćenja dinamike razvoja različitih proizvoda, već će uvelike ovisiti o psihofizičkom stanju pojedinaca koji grade timove, o njihovoj kompetenciji, zadovoljstvu, motivaciji, entuzijazmu i mnogim drugim činiteljima, koji će biti obrađeni u kasnijim poglavljima. Pojedinci, dakle, sačinjavaju timove, a timovi čine sustave. Svaki sustav zahtjeva određenu količinu energije ulo�ene u njegovu organizaciju, kako bi isti mogao ispravno obavljati svoju funkciju. Stoga, ozbiljne kompanije ula�u velike napore u znanje ovladavanjem organizacijskim vje�tinama, među kojima je primarno upravljanje timovima i definiranje optimalne organizacijske strukture. Projektni tim ima slojevitu organizacijsku strukturu. Takve strukture su nu�ne, kako bi se izgradio pouzdani proizvodni mehnizam potreban za realizaciju softverskog proizvoda iz početne ideje.

Na slici (Slika 2-3) prikazan je jedan jednostavni primjer organizacijske strukture, prikladan za opisani model razvojnog procesa softvera (MRPS) koji će u kasnijim poglavljima biti razmatran i simuliran. Gornji sloj nazvan je upravljačkom strukturom i u njemu se nalaze rukovoditelji koji se brinu za prirodni tok razvoja softverskog proizvoda, ali i za odr�avanje samog procesnog mehanizma. Stoga taj tim u ovom primjeru sadr�i projektnog menad�era i menad�era kvalitete. Projektni menad�er ne bavi se tehničkim stvarima vezanim uz razvoj proizvoda, već je njegov zadatak stvaranje projektnog tima, raspodjela zadataka i planiranje dinamike posla shodno dogovorenim rokovima. Njegova je svrha dr�ati se projektnog procesa i upravljati njegovim fazama. Za razliku od njega, menad�er kvalitete je potreban za praćenje i predviđanje kvalitete proizvoda, ali i za odr�avanje i pobolj�avanje procesa razvoja koji su uključeni u projektni proces (Slika 2-1). Menad�ment kvalitete trebao bi biti neovisan o projektnoj i tehničkoj liniji upravljanja. U malim projektima i malim tvrtkama, jedan čovjek mo�e obavljati te dvije uloge dosta uspje�no, međutim u velikim proizvodno-razvojnim sustavima, nu�na je podjela posla na vi�e ljudi ili čak timove odgovorne za takve vrste poslova. Slijedeću razinu čini tehničko projektno rukovodstvo koje se sastoji od ljudi odgovornih za tehničku realizaciju i razvoj softvera. Njihova znanja su uglavnom tehničke prirode i vezana su uz neku od specijaliziranih grana koje se pojavljuju u samom procesu razvoja, na primjer dizajn, testiranje, hardver ili konfiguracija okoline. Za razliku od


29

upravljačke strukture, ne brinu se toliko oko samog toka projekta, koliko oko načina razvoja funkcionalnosti proizvoda.

IZVR

�NI

TIM

OVI

PRO

JEK

TNO

RU

KO

VOD

STVO

UPR

AVL

JAČ

KA

STR

UK

TUR

A

ANALIZATORSUSTAVA

KONFIGURACIJSKI

MENAD�ERARHITEKT TEST

MENAD�ERHARDVERIN�ENJER

PROJEKTMENAD�ER

MENAD�ERKVALITETE

DIZAJNERI TESTERI

Slika 2-3: Organizacijska struktura procesnog tima koji se koristi u MRPS-u

Ovaj model procesa razvoja na tu razinu ima svrstane analizatora sustava, arhitekta softvera, test i konfiguracijskog menad�era, te sklopovskog in�enjera. Analizator sustava je osoba visokih tehničkih kompetencija i iskustava. Njegovo znanje mora biti onoliko �iroko da obuhvaća cjelokupnost sustava koji se razvija, dakle pokriva sadr�aje svih njegovih elemenata. To su uglavnom osobe s vi�e godina stručnog rada na istim ili sličnim sustavima, a bitno je da su pro�li kroz sve radne uloge koje se pojavljuju u razvojnom tehničkom timu. Njegov je zadatak analizirati zahtjeve kupca i na temelju njih predlagati rje�enja budućeg informacijskog sustava, uključujući i hardver i softver. Kad se odredi smjer budućeg razvoja, va�no je da razradi sustav odvajajući hardver i softver, i predlo�i optimalni razvoj funkcionalnosti koje trebaju biti razvijene. Dokumenti za koje je analizator sustava nadle�an su hardverska i softverska razrada, uključujući i analizu zahtjeva. Inspekcijom spomenutih dokumenata, daljnja analiza nastavlja se po granama, tj. arhitekt stvara implementacijsku sliku budućeg softvera, kao �to hardverski in�enjer to isto čini s hardverskom komponentom. Dokumenti koji nastaju nazivaju se softver i hardver implementacija i ustvari su vi�e prijedlog funkcija bez tehničkih detalja. Konfiguracijski menad�er priprema konfiguracijski plan, a test menad�er plan prema kojem će se odvijati testiranje. Svi oni su u bliskom kontaktu s projektnim menad�erom i koordinatorom kvalitete, jer osim strukture sustava, pravilno se moraju isplanirati resursi i vrijeme potrebno za razvoj sustava. Dakle, ideja o budućem sustavu postupno je razvijana, a funkcionalnost je dekomponirana u manje funkcionalnosti i funkcije koje sustav treba sadr�avati. Teorijski, tad se mo�e smatrati da je sustav dobro


30

definiran i da mo�e otpočeti faza dizajna. U fazi dizajna dizajnerski timovi preuzimaju dokumentaciju i na temelju nje analiziraju skupove funkcija i njihove zadaće, koje su im dodjeljene, svakom pojedinačno u vidu modula. Paralelno s dizajnerskim timovima, test tim priprema test slučajeve kojima ispitivati buduće funkcionalnosti. Po kompetencijama dizajn i test timovi ne zahtjevaju specijalističke kadrove, iako su oni dobro do�li unutar tih timova, bilo kao tehnički kordinatori ili in�enjeri vi�eg stupnja.

2.4.4 Dokumentacija MRPS-a

Kao �to se vidi iz tablice (Tablica 2-1) opisani MRPS koristi 22 različita dokumenta. U pojedinim slučajevima mo�e se koristiti i manji broj dokumenata, na primjer kod malih projekata, neke dokumente nije potrebno pisati. Mali projekti ne zahtjevaju neke od projektnih uloga, kao �to je u ovom slučaju menad�er kvalitete. U tom slučaju, posao menad�era kvalitete mo�e preuzeti projektni menad�er, dok dokumenti kao �to su plan mjerenja i plan rizika nastoje se obraditi dodatnim poglavljima u projektnom planu. Takve promjene procesa ili prilagođavanja (engl. process tailoring) su česta pojava u kvalitetnim organizacijama, jer se na taj način vr�i u�teda vremena i resursa bez pada kvalitete proizvoda.

FAZA Br DOKUMENT ODGOVORNOST PODPROCES 0 Zahtjev naručitelj Analiza zahtjeva 1 Specifikacija Zahtjeva analizator sustava Analiza zahtjeva 2 Sistamska Skica analizator sustava Analiza zahtjeva 4 Softverska Razrada analizator sustava Sistemska studija 5 Hardverska Razrada analizator sustava Sistemska studija 6 Implementacija Softvera arhitekt Sistemska analiza 7 Implementacija Hardvera hardver in�enjer Sistemska analiza 8 Test Analiza test menad�er Sistemska analiza 9 Projektni Plan projektni menad�er Planiranje resursa

10 Plan Kvalitete *menad�er kvalitete Planiranje resursa 11 *Plan Rizika projektni menad�er Planiranje resursa 12 *Plan Mjerenja menad�er kvalitete Planiranje resursa

AN

AL

IZA

13 Konfiguracijski Plan konfiguracijski mngr. Planiranje resursa 14 Test Plan test menad�er Podjela zadataka 15 Hardverski Plan hardver in�enjer Podjela zadataka 16 Funkcija Modula dizajner Modul dizajn 17 Opis Modula dizajner Kodiranje D

IZA

JN

18 Test Lista tester Kodiranje 19 Raport Pogre�aka tester Ispravak gre�aka TEST 20 Uputstvo dizajner Pisanje uputa

ISPORUKA 21 Raport Kvalitete *menad�er kvalitete Raport kvalitete

Tablica 2-1: Popis dokumenata, odgovornosti i pripadajućih procesa u različitim fazama MRPS-a (* koristi se samo kod procesne opcije velikog projekta)

Dokumenti se pi�u prema točno utvrđenim pravilima pisanja, koja su definirana u procesnim dokumentima zadu�enim za njihovu definiciju (engl. document instruction). Osim tih procesnih dokumenata postoje i dokumenti koji definiraju procese (engl. process description) i dokumenti kojima se pridaju zadaci pojedinoj projektnoj ili procesnoj ulozi (engl. role


31

description, work instruction). Da bi se zadr�ala jednostavnost opisanog modela procesa kojeg treba simulirati, takvi dokumenti neće biti dijelovi njegove strukture, već se smatra da su oni definirani prema nekoj od normi, na primjer skupini normi ISO 9000.

Naziv i opis dokumenata MRPS-a

Dokumenti kori�teni u MRPS-u opisani su prema redoslijedu pojavljivanja u razvojnom procesu i njegovim procesnim fazama (Slika 2-4):

S O F T V E R S K A D O K U M E N T A C I J A

Specifik.Zahtjeva

SoftverskaRazrada

Implementacija

Softvera

FunkcijaModula

OpisModula

Uputstvo(startanje)

H A R D V E R S K A D O K U M E N T A C I J A

Sistemskaskica

Hardver.Razrada

Implementacija

Hardvera

HardverskiPlan

T E S T D O K U M E N T A C I J A

TestAnaliza

TestPlan

TestLista

RaportPogre�aka

P R O J E K T N A D O K U M E N T A C I J A

*PlanKvalitete

*PlanMjerenja

Konfigur.Plan

Projektniplan

*PlanRizika

RaportKvalitete

Zahtjev

TO2

TO1

TO0

TO3

TO4

TO5

MK

0

MK

1

MK

2

MK

3

PlanKvalitete

Uputstvo(kraj)

* samo kod opcije: VELIKI PROJEKT Slika 2-4:Raspodjela projektne dokumentacije prema fazama, tj. redoslijedu pojavljivanja

i pripadnost: softverska, hardverska, test i projektna dokumentacija

Zahtjev � dokument u kojem su navedeni zahtjevi naručitalja. Projektno rukovodstvo je odgovorno za pravilnu definiciju dokumenta, kao i njegovo tumačenje kupcu, ali je kupac odgovoran za taj dokument kao potpisnik istog. Obično u velikim organizacijskim sustavima postoji tim za definiranje zahtjeva, sastavljen od projektnog rukovodstva, ekonomista, pravne slu�be i stručnjaka raznih drugih djelatnosti koje su potrebne za �to kvalitetniju definiciju zahtjeva, na temelju kojeg se sklapa ugovor.

Specifikacija zahtjeva � dokument nastao analizom zahtjeva od strane analizatora sustava. U sebi ima detaljno pobrojane i opisane zahtjeve koje budući sustav mora izvr�avati. Za dokument je odgovoran analizator sustava, a uz njega, inspektira ga i netko iz projektnog rukovodstva, uz obavezno prisustvo projektnog menad�era.


32

Sistemska skica � također, dokument nastao analizom zahtjeva od strane analizatora sustava. Sadr�i skicu budućeg sustava koji bi trebao izvr�avati funkcionalnosti definirane u dokumentu specifikacije zahtjeva. Kao i u prethodno opisanom dokumentu, za sistemsku skicu dokument je odgovoran analizator sustava, a uz njega, inspektira ga i netko izprojektnog rukovodstva, uz obavezno prisustvo projektnog menad�era. Sistemska skica mo�e sadr�avati vi�e prijedloga rje�enja stvaranih iz različitih kuteva gledi�ta.

Softverska razrada � dokument koji nastaje u slijedećem valu dokumenata analize. Proizlazi iz specifikacije zahtjeva i sistemske skice. U njemu je detaljnije obja�njena funkcionalnost, ali sa strane softvera koji mora biti razvijen.

Hardverska razrada � dokument sličan softverskoj razradi, ali s tipično hardverskim sadr�ajem. Po ničem drugom se ne razlikuje od softverske razrade, stoga kao i taj dokument razrađuje sistemsku skicu s tehničke strane hardvera koji bi trebao biti koncipiran tako da podr�ava informacijski sustav sa softverske strane.

Implementacija softvera � puno detaljniji dokument po pitanju prijedloga buduće funkcionalnosti sa strane softvera. Temeljna funkcionalnost biva razlomljena na funkcije i programske cjeline zvane moduli. Dokument sadr�i razne informacije implementacijskog karaktera kao i informacije o dokumentaciji koja mora biti isporučena zajedno s proizvodom. Za dokument je odgovoran i stvara ga arhitekt. Dokument mora vi�e puta biti inspektiran od strane projektnog i tehničkog rukovodstva, kako bi se izbjegle buduće implementacijske gre�ke u softveru, a time pojeftinio i ubrzao razvoj proizvoda. Implementacija softvera je jedan od temeljnih i najva�nijih dokumenata u razvojnom procesu.

Implementacija hardvera � hardver zahtijeva jednaku pa�nju kod razvoja kao i softver. Poput dokumenta implementacije softvera, ovaj dokument vrlo detaljno opisuje performanse potrebnog hardvera, njegovu funkciju i prijedlog implementacije.

Test analiza � dokument kojeg stvara test menad�er na temelju implementacijske dokumentacije. U njemu su sadr�ani test slučajevi potrebni za ispitivanje proizvoda u svim fazama testa, bio on funkcijski, hardverski ili sistemski. Test menad�er je odgovoran za taj dokument. Kao i sve dokumente, nu�no ga je inspektirati.

Projektni plan � dokument za koji je odgovoran projektni menad�er. Stvara ga na temelju dokumenata analize zahtjeva i dopunjava ga cijelom fazom analize. Projektni plan podlo�an je čestim promjenama, �to ovisi o procesu promjene zahtjeva. Projektni plan sadr�i sve bitne podatke o raspodjeli resursa, organizaciji projekta, isporuci, projektnim fazama, timovima, vremenskim planovima, a po mogućnosti mo�e imati uključeno poglavlje kvalitete i analize rizika.

Plan rizika � dokument koji sadr�i i rukovodi mogućim rizicima koji se mogu pojaviti tokom projekta. Pi�e se uglavnom u velikim i slo�enim projektima i mijenja se od faze do faze. U malim i ne tako zahtjevnim projektima mo�e se svrstati u neko od poglavlja projektnog plana ili kao dio plana kvalitete.

Plan kvalitete � menad�er kvalitete bitna je uloga u cijelom projektu, jer kordinira timovima i procesima, te svojim akcijama osigurava kvalitetu budućeg proizvoda. Stoga je odgovoran za pisanje i sprovođenje dokumenta kvalitete u kojem se vr�i predikcija kvallitetu proizvoda na temelju različitih projektnih parametara i iskustvima s pro�lih projekata. Mo�e sadr�avati smjernice na temelju kojih se svaraju dokumenti planiranja rizika i plan mjerenja, ili sam sadr�i opis mjerenja koja će se koristiti na projektu.


33

Plan mjerenja � ako se pi�e posebno, taj dokument je va�an jer daje informacije o tome �to i kako mjeriti tokom projekta, a kako bi se na temelju tih mjerenja mogao vr�iti utjecaj na pobolj�anje kvalitete proizvoda i predviđanje kvalitete istog.

Konfiguracijski plan � sastavljen od strane konfiguracijskog menad�era, sadr�i informacije o softverskim pomagalima kojima će se razvijati proizvod, planira se radna okolina, platforma, revizijska nomenklatura dokumentacije, načini pohranjivanja projektnih modula i dokumentacije baze podataka, kao i gotovog proizvoda.

Test plan � nastaje paralelno s razvojem dizajn faze i stvaranjem modula. Temelji se na dokumentu test analize, a sadr�i tablice ispitnih slučajeva kojima će se testirati pojedini moduli. Za test plan odgovoran je test menad�er.

Test lista � puno detaljniji dokument pisan od strane testera koji sprema ispitivanje pridjeljenog mu modula. Test plan se pi�e za svaki modul. Odgovornost za svaki pojedinu test listu preuzima tester za određenu funkciju ili modul. U pojedinim slučajevima jednostavne implementacije, zajedničku test listu mo�e pisati i test menad�er.

Raporti (izvje�taji o pogre�kama) � dokumenti koji opisuju tip i moguće rje�enje pogre�aka koje su prona�li testeri na svom modulu ili funkciji koju testiraju. Izvje�taji o pogre�kama su ulazni dokumenti zasebnog procesa kojim se ispravljaju poge�ke nastale u procesu testiranja. Izvje�taje prihvaćaju dizajneri modula, te shodno njima ispravljaju neispravnosti istih. Izvje�taji o pogre�kama ne podlije�u inspekcijama dokumenata. Broj izvje�taja ovisi o pronađenim pogre�kama.

Hardverski plan � konačni dokument vezan uz definiciju hardvera nekog sustava. Do detalja je razrađen hardverski sustav, predlo�eni su sklopovi koji moraju biti implementirani i proizvođač koji isporučuje hardver. Hardver in�enjer je odgovoran za dokument i provjeru hardverskih dijelova kao cjeline. U velikim sustavima kao �to su telefonske digitalne centrale, postoje posebne tvrtke unutar korporacija koje se bave isključivo razvojem hardvera za podr�ku softvera. Predmet ovog rada neće se osvrtati na razvoj hardvera kao podr�ke softveru.

Funkcija modula � dokument koji nastaje kao rezultat dokumenta implementacije softvera i nastaje od strane dizajnera softvera. Dokument nastaje isključivo za jednu softversku cjelinu, blok ili modul i pi�e se neposredno prije kodiranja. Sadr�i vrlo detaljne blok dijagrame i detaljne opise funkcija koje trebaju biti iskodirane. Nakon uspje�ne inspekcije dokumenta, određeni modul se kodira prema tom dokumentu.

Opis modula � sličan dokument kao prethodni, ali puno detaljnije i točnije opisan. Uglavnom nastaje kao pro�irenje dokumenta funkcija modula. Pi�e ga dizajner nakon kodiranja određenog modula.

Uputstvo � uputstvo ili korisnička dokumentacija je dokument ili vi�e dokumenata koji se isporučuje zajedno s proizvodom. Korisnička dokumentacija ne smije sadr�avati tehničke opise koje sadr�ava ostala projektna dokumentacija, već se treba orijentirati na jednostavno, jasno i pregledno opisivanje funkcionalnosti koje obavlja gotovi proizvod. Česta je praksa da takvi dokumenti bivaju i po vi�e puta inspektirani, prije nego li se isporuče zajedno s gotovim proizvodom.

Raport (izvje�taj o kvaliteti) � dokument koji sadr�i proračune kvalitete po modulima, aktivnosti koje su poduzimane u cilju povećanja kvalitete, opisane načine mjerenja koja su se koristila, procese, standarde i sve �to je bilo vezano uz osiguranje kvalitete. Za dokument je odgovoran menad�er kvalitete. Dokument mo�e biti odlično iskori�ten za novi početak razvoja nekog proizvoda, te za predikciju kvalitete budućih proizvoda.


34

3 Modeliranje, simulacija i optimizacija MRPS-a Petrijevim mre�ama

Industrija razvoja softvera je temeljena na velikim i kompleksnim poslovnim procesima, gdje je razvojni proces jedan od najkompliciranijih. Zadatak koji se pojavljuje u upravljanju takvim poslovnim procesima je stvaranje optimalnog vremenskog plana razvoja za određene radne uvjete. U ovom poglavlju prikazano je kako pridobiti procesno znanje korisno za optimizaciju poslovnih aktivnosti. U tu svrhu, za modeliranje i simulaciju procesnih struktura, kori�tene su obojene Petrijeve mre�e s ciljem predviđanja vremena i cijene, potrebnih za razvijanje softverskog proizvoda u određenim uvjetima. U poglavlju je obja�njen i optimiziran prethodno opisani MRPS.

3.1 Pristup modeliranju poslovnog procesa

Modeliranje procesa također ima svoj proces, tj. način pristupa modeliranju. Započinje se definicijom cilja modeliranja. Tu se uglavnom radi o upoznavanju rada i optimizaciji procesa. Nakon toga nu�no je osvrnuti se na izvore podataka koji su kori�teni pri modeliranju procesnog sustava. Uglavnom se tu radi o vremenskim projektnim planovima, promatranju značajki procesa, dokumentaciji opisa procesa i uloga, te iskustvenoj metodi, tj. uključenosti u sam proces. Za izgradnju simulacijskog modela koristi se određena tehnologija, za koju se smatra da će dati najbolje rezultate pri određenom ulo�enom vremenu i trudu. U tu svrhu odabrane su obojene Petrijeve mre�e, budući je njima moguće opisati najzahtjevnije procese, hijerarhijski dekomponirajući sustav procesa do �eljene razine. U izgradnju se uključuje i sintaksna provjera, planiranje i izvođenje simulacijskih eksperimenata i tra�enja optimalnog slučaja za pojedine početne vrijednosti procesnih parametara [32][33].

3.2 Cilj modeliranja i simulacije sustava

Cilj stvaranja MRPS-a i njegove simulacije mogao bi se svesti na upoznavanje rada sustava, pobolj�anje performansi sustava i smanjenje tro�kova sustava.

3.2.1 Upoznavanje rada sustava

Primarni cilj ovog rada jest pristup zadatku modeliranja i simulacije slo�enih poslovnih procesa koji se koriste za razvoj softvera u velikim industrijama. Problemi koji se javljaju kod opisa nekog procesnog sustava u razvoju softvera su nemogućnost definiranja i mjerenja pojedinih faza, koje su uglavnom vezane uz ljudsku mentalnu kreativnost. Stoga je cilj predlo�iti način na koji se mo�e opisati kreativni ljudski proces stvaranja softvera. Primjer MRPS-a jo� uvijek nije dovoljno precizno opisan, da bi se na temelju njega mogli promatrati mikrouvjeti koji djeluju na proizvodnju, ali mo�e biti izvrsno pomagalo kod predviđanja utro�ka vremena i proizvodnih resursa projekta definiranog ulaznim varijablama. Također, model je dovoljno razrađen (tri razine) da uka�e na način kojim se mo�e izvesti zahtjevnije


35

modeliranje. Tehnika je ista, ali zahtjeva vi�e pa�nje i radnih sati u preciznom definiranju strukture modela, te skupljanju informacija o stvarnom sustavu.

3.2.2 Pobolj�anje performansi sustava � optimizacija resursa

Jedan od ciljeva je i optimizacija resursa utro�enih za razvoj softverskog proizvoda, tj. način na koji se iz opisanog modela mogu dobiti pokazatelji koji utiču na dinamiku procesa i potro�nju resursa. Mora se napomenuti da je ovdje akcent na pristupu i načinu optimizacije, a ne na dobivanju stvarnih rezultata. Problem je pridobiti informacije iz slo�enog procesnog sustava, poput opisanog, međutim vrlo je lako doći do bitnih rezultata ukoliko raspola�emo detaljnim informacijama o samom procesu. Dakle optimizacija MRPS-a je prikaz načina kako optimizirati velike procesne sustave.

3.3 Izvori podataka za izradu simulacijskog modela

Vjerovatno najte�i i najzahtjevniji dio stvaranja simulacijskog modela jest prikupljanje podataka potrebnih za simulaciju nekog sustava, u ovom slučaju procesa za razvoj softvera. Nema kvalitetne simulacije bez kvalitetnih podataka kojima se mo�e dosljedno opisati proces. Podaci se mogu prikupiti iz različitih izvora: projektno-procesne dokumentacije, promatranja i mjerenja procesa, rezultata mjerenja kvalitete proizvoda, prikupljanju osobnih iskustava članova procesnog tima i sl.

3.3.1 Vremenski planovi

Svaka ozbiljna tvrtka mora sadr�avati detaljne projektne planove za razvoj svojih proizvoda i usluga. Poslovanje bez te osnove je nezamislivo, stoga izrada simulacijskog modela procesa za takav način poslovanje nema svrhe. Drugim riječima, tvrtka bi morala imati razinu organizacije koja odgovara bar 3. razini CMMI modela. Projektni plan pisan je od strane projektnog rukovodstva i sadr�ava detaljnu procjenu vremena koje će biti potro�eno na pojedine aktivnosti poput programiranja, pisanja dokumentacije, inspekcije, testiranje i slično. Također, procjena se radi prema osobi i prema zadaći koju ta osoba mora obaviti u točno definiranom vremenskom roku. Već projektni plan i slika točno definiranog procesa, preuzeta iz procesne dokumentacije, mogu biti dovoljni kao dobar temelj simulacijskog modela. Na temelju dokumenta opisa procesa (engl. Process Description) definira se gruba struktura procesa i tokovi radnji koje moraju biti obavljene. Projektni plan sadr�i podatak o gruboj dinamici tih tokova, stoga početna razina modela mo�e biti definirana. Međutim, to jo� uvijek nije dovoljno za precizno modeliranje [5].

3.3.2 Promatranje značajki procesa

Proces, iako definiran, ima svoje značajke, bitno različite od teorijskog opisa. Te značajke često izlaze van mogućnosti mjerenja i zadiru u psihologiju tima i pojedinca. Drugim riječima, praksa primjene procesa je vrlo bitna u modeliranju. Ponekad nije moguće opisati neko radno mjesto skupom akcija, pa se značajka takvog radnog mjesta mo�e izraziti


36

statistički u odnosu na pojedinu fazu, bilo to u količini potro�enog vremena, ili postignutoj normi proizvodnje. U procesima kao �to je razvoj softvera, nemoguće je izvr�iti bilo kakva mjerenja količine posla, kao �to bi to bio slučaj u ostaloj proizvodnji poput tekstilne, prehrambene ili na primjer metalne industrije. Posao u softverskoj industriji je striktno mentalne prirode i nemjerljiv je nekom pouzdanom metodom. Stoga se pribjegava promatranju i statistici gdje je ona god moguća. Niti sam programer nema uvid u potrebno vrijeme za neku određenu operaciju koju treba izvesti. Tu je potrebno puno prakse i promatranja već uhodanih procesa kako bi se izvukla neka korisna statistika. Ako postoji stihija u procesnom pristupu, podaci prikupljeni u analizi takvog sustava neće biti od velike koristi. Dobro je promatrati kroz du�i period pojedinca, njegove radne mogućnosti, navike i skonosti, te ih poku�ati opisati nekim jednostavnim statističkim modelom. Npr, koliko je potrebno određenom zaposleniku da razvije određeni softver pod određenim uvjetima. Za tu svrhu mogu biti kori�tene informacijske analize nad velikim količinama prikupljenih podataka znane kao rudarenje podataka, �to će biti obrađeno u kasnijim poglavljima.

3.3.3 Opisi procesa i procesnih uloga

Dokumenti opisa procesa i procesnih uloga, ako postoje u tvrtci, nerazdvojivi su jedni od drugih. Pretpostavka je da se tvrtka, koja se bavi razvojem softvera, nalazi bar na toj razini organizacije da definira svoje procese i radne uloge, te ih uredno dokumentira, promatra i mjeri. Bez tih osnovnih stvari te�ko je ili čak nemoguće stvarati kvalitetan softver, pogotovo ako je riječ o vi�emjesečnom ili vi�egodi�njem razvoju. Dokumenti opisa procesa moraju imati definirane procese �to je vrlo korisno u modeliranju. Također, procesne uloge i njihovi opisi mogu sadr�avati dovoljan broj podataka koji mogu biti ugrađeni u opisani model. Prije bilo kakvog mjerenja na terenu preporuka je da se dobro prouče svi procesni i projektni dokumenti, zatim da se napravi skica modela i onda se ide u daljnju dekompoziciju aktivnosti, za koje će vjerovatno biti potrebno opse�nije mjerenje ili promatranje.

3.3.4 Proces i projekt u praksi � iskustvena metoda

Iskustvo i primjena u praksi definiranih procesa je od najveće va�nosti za valjanost simulacije nekog modela kojeg se opisuje. Empirijska komponenta daje �ivost procesu, stoga iskusno procesno rukovodstvo posjeduje znanje o adaptaciji procesa u svakom času i prilagođava procese prema potrebi u danom trenutku. To znanje, koje ne mo�e biti izra�eno formulom, obuhvaćeno mjerenjem, niti definirano riječima je upravo empirijsko znanje. Dakle, nemoguće je detaljno modelirati bilo koji proces, ako nisi uključen u njega svojom pa�njom ili radnom aktivno�ću. To bi trebao biti temeljni teorem ispravnog modeliranja poslovnih procesa.


37

3.4 Modeliranje i simulacija razvojnog procesa softvera Petrijevim mre�ama

3.4.1 Petrijeve mre�e � definicija i povijest razvoja

Petrijeve mre�e su grafičko i matematičko pomagalo za modeliranje, primjenljivo na različite vrste sustava. To je formalni jezik prikladan za modeliranje konkurentnih sustava i sustava s dijeljenjem resursa (engl. resource sharing), model s kojim se uspje�no predočuje statičko, dinamičko i intervalno vremensko znanje. Početkom 60-tih godina pro�log stoljeća Carl Adam Petri prvi je definirao i razvio sveobuhvatnu teoriju za diskretno paralelne sustave, koju je formulirao kao jezik teorije automata na konceptu istodobnosti ili paralelizma. Petrijeve mre�e vrlo brzo su prepoznate kao najadekvatniji i vrlo prihvatljiv jezik, prepoznat za obja�njavanje i analizu sinkronizacije, komunikacije i dijeljenje resursa među konkurentnim procesima. Međutim, poku�aji da se Petrijeve mre�e koriste u praksi doveli su do dva glavna problema. Prvi problem bila je veličina modela koji je postizao ogromne dimenzije zato �to nije postojao koncept podataka, te su se sve manipulacije podacima morale predstavljati izravno strukturom mre�e. Također, nije postojao koncept hijerarhije, �to se pokazalo kao drugi problem. Uslijed tog nedostatka nije bilo moguće stvarati velike i kompleksne modele, koji bi bili sačinjeni putem odvojenih podmodela s ispravno definiranim sučeljima. Navedeni problemi počeli su se otklanjati krajem 70-tih i početkom 80-tih godina pro�log stoljeća, kad je započeo razvoj hijerarhijskih Petrijevih mre�a visoke razine. Obojene Petrijeve mre�e (engl. Coloured Petri Nets - CPN) su jedan od dva najpoznatija modela Petrijevih mre�a visoke razine. Obojene Petrijeve mre�e (CPN) utjelovljuju rje�enja oba problema: dopu�taju strukturiranje podataka i hijerarhijsku dekompoziciju, bez naru�avanja kvalitete svojstava originalnih Petrijevih mre�a. [23][35][19][24].

3.4.2 Elementi Petrijeve mre�e

Petrijevu mre�u čini struktura mjesta i prijelaza. Mjesta imaju značenje uvjeta, a prijelazi imaju značenje događaja. Prijelazi su definirani kao sustav uvjeta i događaja, gdje uvjet treba biti zadovoljen kako bi se izveo neki događaj. Treći element mre�e čine oznake (engl. token). Oznake postavljene u nekom mjestu označuju ispunjenje uvjeta kojeg to mjesto označava. Grane (engl. arc), kojima su mjesta i prijelazi povezani, sačinjavaju četvrti element mre�e. Grane imaju svoj smjer i svoju te�inu ili propusnost. O te�ini grane ovisi koliko oznaka istodobno mo�e propustiti oznaka.

Slika 3-1: Jednostavna Petrijeva mre�a: 2 mjesta, 2 grane, 1 prijelaz i 1 oznaka

Na slici (Slika 3-1) prikazan je primjer jednostavne Petrijeve mre�e, sačinjene od dva mjesta (mjesto A i B) povezana granama s jednim prijelazom. U mjestu A nalazi se jedna oznaka, �to označava ispunjenost uvjeta predstavljenog mjestom A. Mjesto B nema oznaka, stoga nema


38

ispunjen uvjet koji mu je simbolički doznačen. Petrijeve mre�e izvr�avaju se u koracima, gdje u svakom koraku biva izvr�en jedan prijelaz, ako su zadovoljeni njegovi uvjeti. Prijelazi mogu biti izvr�avani pojedinačno ili simultano, kod mre�a s vi�e prijelaza. U ovom slučaju, dovoljan je jedan korak da bi se izvr�ila aktivnost ili događaj predstavljen prijelazom i da bi mjesto B poprimilo oznaku, tj. zadovoljenjem uvjeta prijelaza (oznaka u mjestu A) daje jednu oznaku u mjestu B. Simbolički, na taj način mo�emo opisati ne�to slo�eniji mogući slučaj iz stvarnosti, obja�njen u primjeru na slici (Slika 3-2).

Slika 3-2: Primjer opisa jednostavnog procesa koji se pojavljuje u praksi

Kako bi se objasnila osnova modeliranja paralelnih situacija Petrijevom mre�om, mo�e se uzeti za primjer slijedeći slučaj: potrebno je određeni dokument neke tvrtke popuniti određenim informacijama (1 oznaka u mjestu: DOKUMENTI) i odabrati osobu koja će izvesti tu zadaću, tj. događaj (prijelaz: ispuni!). Za tu svrhu na raspolaganju su 3 osobe (3 oznake u mjestu: LJUDI). Kako bi se stvorili uvjeti za ispunjenje zadaće (1 oznaka u mjestu: ISPUNJEN DOKUMENT), potrebno je stvoriti uvjete u mjestima ODABRAN i PRIPREMLJEN, �to zahtjeva modeliranje jo� dvije aktivnosti predstavljene prijelazima Izaberi! i Pripremi! Dok god se i u mjestu LJUDI i u mjestu DOKUMENTI nalaze oznake, one će se prenositi u mjesta ODABRAN i PRIPREMLJEN, �to znači da će biti ispunjen onoliki broj dokumenata koliko ima ljudskih resursa, ili obrnuto, bit će potro�eno onoliko ljudskih resursa koliko postoji dokumenata (oznake u mjestu DOKUMENTI). Rezultat simulacije bit će prikazan brojem oznaka u mjestu ISPUNJEN DOKUMENT. U opisanom primjeru ulazne varijable modeliranog sustava bit će broj dokumenata i količina ljudskih resursa, a izlazne varijable ili performanse opisanog sustava bit će broj ispunjenih dokumenata, tj. broj oznaka u mjestu ISPUNJEN DOKUMENT. [23][35][46][47][48].

3.4.3 Primjer modeliranja i simulacije jednostavnog poslovnog procesa klasičnom Petrijevom mre�om

Kako bi se pokazala nedostatnost modeliranja i simulacije klasičnim Petrijevim mre�ama, u slijedećim poglavljima bit će prikazan jedan mali primjer modeliranja i simulacije poslovnog procesa tehnikom klasičnih Petrijevih mre�a. Primjer bi trebao pokazati nu�nost kori�tenja kompleksnijih i učinkoviijih metoda modeliranja i simulacije, kao �to su obojene Petrijeve mre�e, koje predstavljaju nadogradnju osnovnog modela Petrijeve mre�e. Također, primjer opisuje osnove pristupa modeliranju poslovnih procesa i tumačenja rezultata simulacija.


39

Opis procesa nabave

Kao model simulacije jednog jednostavnog procesa uključenog u razvoj softverskog proizvoda, prikazan je proces nabave, koji se koristi kao proces podr�ke u razvoju softvera u većim odjelima. Proces je strukturiran prema pravilima ISO 9000:2000 standardima i sastoji se od 10 faza koje predstavljaju različita stanja toka dokumentacije i akcija kori�tenih za nabavu softverskih i hardverskih komponenti nu�nih u proizvodnji. Procesom upravlja nadzorni tim sastavljen od jednog zaposlenika ili vi�e ljudi. Tim je zadu�en za kontrolu procesa, upravljanje tokom dokumenata i promjenu statusa dokumenata u procesu. Unutar procesa nalazi se dio, koji povezan na vanjski proces nabave, nije upravljiv od strane nadzornog tima. Taj je dio procesa na kompanijskoj razini ili, u specifičnom slučaju, mo�e biti predstavljen kao kompanijsko skladi�te softverskog i hardverskog materijala. Svakoj komponenti, koja se nabavlja prikazanim procesom, pridru�en je njezin dokument nabave. Dokument nabave nastaje iniciranjem zahtjeva za nabavu i zatvara se tek nakon �to nabavljeni proizvod biva identificiran i funkcijski potvrđen kao ispravan. U simulaciji Petrijevom mre�om, dokument nabave prikazan je oznakom koja putuje kroz mjesta, koja zamjenjuju faze procesa.

Slika 3-3: Proces nabave unutar odjela za razvoj softvera, tokovi i statusi dokumenata:

(NP-narud�ba pokrenuta, NO-neodobrena narud�ba, OD-odobrena narud�ba, IN-inicirana narud�ba, IDN-identificiran proizvod, PV-povratak u vanjski proces nabave i BRS-brisanje narud�be)

Cilj simulacije je pronaći optimalni sustav upravljanja procesom, uključujući i broj zaposlenih u nadzornom timu. Za simulaciju i testiranje tog procesa nije potrebno potro�iti vi�e od jednog tjedna, ako su nam poznate akcije i slijed radnji koje proces mora obaviti, prosječno vrijeme obavljanja svake faze i tokovi dokumenata. Slika (Slika 3-3) prikazuje proces nabave u svim fazama i statusima pripadajućih dokumenata. Dakle, svaka procesna faza mora biti izmjerena kako bi se cijeli proces mogao dekomponirati u Petrijevu notifikaciju. Statističko vrijeme


40

potrebno za svaku fazu i tok dokumenta, izračunato je na temelju promatranja pona�anja svake pojedine faze, jer proces je ovisan o uigranosti tima, kompetenciji i nekim drugim faktorima koji nisu obuhvaćeni ovom simulacijom [23][35][19][24].

Proces nabave opisan Petrijevom mre�om prikazan je na slici (Slika 3-4). Model procesa pretvoren u Petrijevu mre�u sadr�i 18 mjesta (P1-P18) i 17 prijelaza (T1-T17), od kojih su 3 inhibicijska prijelaza (T3, T7, T12) koji su upotrebljeni za statističku kontrolu grananja na prijelazima P2, P6 i P10 [1].

Slika 3-4: Model procesa nabave modeliran Petrijevom mre�om

Vrijednosti naznačene pored prijelaza predstavljaju ka�njenje ili vrijeme iskori�teno za pojedinu akciju. Izuzeci su prijelazi bez ka�njenja označeni s �1. Referentno vrijeme kori�teno kao korak u mre�i je efektivni radni sat po zaposleniku. jedan korak predstavlja simultano izvr�avanje svih prijelaza kojima su zadovoljeni uvjeti. Vrijednost naznačena iznad pojedinih grana predstavlja broj istovjetnih grana. U svrhu optimizacije procesa, izvedeno je vi�e simulacija, prikazanih u tablici (Tablica 3-1). Nakon simulacije procesa pronađeni su konflikti u mjestima P2, P6, P10, P12 i P15, te su rije�eni statističkom kontrolom s pomoću mjesta P16, P17, P18 i P19 i njima pridru�enim prijelazima. Proces je simuliran s jednim, dva


41

i tri zaposlenika koji su prisutni u nadzornom centru, �to je prikazano s brojem oznaka u mjestu P15 koje predstavlja resurs nadzornog centra.

Simulacija Oznake Prioritet Napomena Koraci A 1 - gomilanje u P8 > P3 1630 B 2 - gomilanje u P8 >> P3 1072 C 1 početni gomilanje u P3 ~ P8 1798

D 2 početni gomilanje samo u P8, premje�tanje s P1 u P8, zatim s P8 u P13 1202

E 3 početni gomilanje u P8, neprekidan tok bez premje�tanja = slučaju 4. 1012

F 1 krajnji gomilanje u P3 > P8 1408 G 2 krajnji manje gomilanje P3=P8, kontinuitet 1012 H 3 krajnji gomilanje samo u P8 1012 I 2 S-krj gomilanje u P3 406 J 3 S-krj gomilanje u P3 281 K 2 gre�ke 1105

Tablica 3-1: Simulacije Petrijeve mre�e procesa nabave (jedan korak odgovara jednom radnom satu zaposlenika, broj oznaka kontrolnog mjesta naveden je u drugoj koloni, a predstavlja broj zaposlenika u nadzornom timu)

Mijenjanjem prioriteta prijelaza dobivene su različite vrijednosti utro�enog vremena, stupac Koraci u tablici (Tablica 3-1), navedenih kao broj sati potreban u obradi i nabavi 100 zahtjeva. Ako prioritet prijelaza pada od početnog prijelaza ka krajnjem prijelazu, onda se naziva početnim prioritetom, tj. prioritetne zadaće nadzornog centra padaju s odmicanjem procesnih faza prema prijelazu T17. Ako je veći prioritet pridru�en zavr�nim fazama, stvar je obrnuta. Prioritet naveden u simulaciji (I) i (J) odnosi se na slučaj kad bi vanjski proces nabave uklonili iz procesa, �to znači da odjel posjeduje svoje skladi�te i ne treba svaku narud�bu naručivati van tvrtke. Simulacija (K) je specifični slučaj u koji su uključene sve mogućnosti pogre�aka u nabavi i povratnih grana. Temelji se na vjerojatnosti da je 5% krivo definiranih, i 10% neodobrenih narud�bi, 5% neispravnih potvrda sukladnosti i 4% neispravne funkcionalnosti, pronađeno funkcijskom verifikacijom. Simulacije (I), (J) i (K) su specifični slučajevi simulacije (G) kao optimalne s najmanjim vremenom i najmanjim brojem ljudskih resursa u nadzornom centru [1][35].

Tumačenje rezultata simulacije Petrijevom mre�om

Različite simulacije nad različitim modelima su pokazale da cijeli proces nadzora mogu obavljati 2 zaposlenika, �to čini proces optimalnim. Vrijeme nabave uvelike ovisi o vanjskom procesu nabave, gre�ke i vraćanja u povratnim granama procesa su dobro asimilirane, te vrlo malo produ�uju prosječno vrijeme nabave na 100 zahtjeva. Vidljivo je da povećanjem broja zaposlenika nadzornog tima iznad 2 se ne dobiva na brzini obrade zahtjeva, dakle, 2 zaposlenika čine optimum za zadanu strukturu procesa. Investiranjem u opremu lokalnog skladi�ta materijala zaobilazi se vanjski proces nabave, �to uvelike smanjuje prosječno vrijeme nabave, te i rasterećuje vanjski proces i resurse. Prioritet treba dati zavr�nim fazama procesa nabave, a administraciju iz prvih faza staviti u drugi plan [1]. Time se posti�e bolja iskoristivost procesa i kontinuitet obrade zahtjeva po svakoj procesnoj fazi. Zavr�ne faze


42

procesa nabave imaju prioritet nad novim zahtjevima nabave, dakle nad početnim fazama procesa.

Zaključak modeliranja sustava klasičnim Petrijevim mre�ama

Svaki proces mo�e biti simuliran ovim načinom, bez obzira na granu industrije. Vi�e procesa neke slo�ene organizacije mo�e biti opisano na taj način i spojeno u jedan veliki i cjeloviti simulacijski model, koji mo�e predstavljati cijelu organizaciju i ciklus proizvodnje, uključujući i ljudsko pona�anje u različitim okolnostima [1]. O mnogim faktorima in�enjerskog tima zadu�enog za modeliranje i simulaciju procesnih sustava, ovisi preciznost i dubina dekomopozicije poslovnog procesa. Rezultati dobiveni simulacijom, uvelike će ovisiti o ulo�enom trudu i sredstvima u napore �to preciznijeg modeliranja. Međutim, pokazalo se da klasične Petrijeve mre�e nisu dovoljne za simulacije velikih i kompleksnijih sustava. Čak i ovaj vrlo jednostavan primjer pokazuje kolika je veličina modela izvedena svega na nekoliko svojstava procesa koji su promatrani. Svakako da bi isti model poprimio puno veće dimenzije da se pristupilo puno detaljnijoj analizi svake pojedine faze i međuakcija koje trebaju biti izvedene. To bi zahtjevalo veći trud, ali i veću snala�ljivost u samoj shemi Petrijevog modela, koja bi postala nepregledna. Također, javile bi se pote�koće s predstavljanjem različitih vrsta podataka samo jednom vrstom oznaka, stoga bi model morao imati dodatne podmre�e, koje bi kontrolirale pojedine tokove oznaka kako ne bi do�lo do njihovog mije�anja. Zaključak je, dakle, da metoda simulacije klasičnim Petrijevim mre�ama nije podesna za modeliranje i simulaciju velikih i kompleksnih poslovnih procesa. To bi predstavljalo ili veliki utro�ak vremena i sredstava, ili s druge strane, dobivanje općenitih podataka nedovoljnih za korekciju realnog poslovnog sustava. Iz tog razloga, potrebno je prijeći na slo�eniju i zahtjevniju analizu i modeliranje sustava metodom obojenih Petrijevih mre�a, koje su kao nadogradnja klasičnih Petrijevih mre�a, pokazale zadovoljavajuće rezultate u primjeni kod modeliranja i simulacije stvarnih poslovnih procesa [1][35].

3.4.4 Obojene Petrijeve mre�e

Nadogradnja klasičnih Petrijevih mre�a

Obojene Petrijeve mre�e su grafički orijentiran jezik pogodan za specifikaciju, simulaciju i verifikaciju sustava. Naročito su prikladne za sustave koji se sastoje od brojnih paralelnih procesa koji međusobno komuniciraju. Tipičan primjer primjene su područja komunikacijskih protokola, distribuiranih sustava, automatiziranih proizvodnih sustava, analize tokova poslovanja i tehnologije razvoja čipova. Obojene Petrijeve mre�e (engl. CP-nets ili CPNs) je jezik za modeliranje razvijen za sustave u kojima komunikacija, konkurentnost i dijeljenje resursa igraju va�nu ulogu. CPN kombiniraju snagu običnih Petrijevih mre�a sa snagom programabilnih jezika visoke razine. Petrijeve mre�e omogućavaju opisivanje procesnog međudjelovanja, dok programski jezik omogućava definiranje tipova podataka i rukovanje njihovim vrijednostima. Obojene Pertijeve mre�e razvijene su kao skup softverskih pomagala nazvanih CPN pomagala (engl. CPN Tools) [19][20].


43

�to su CPN pomagala

CPN pomagala su skupina softverskih pomagala razvijenih u svrhu editiranja, simulacije i analize obojenih Petrijevih mre�a. Posjeduju vrlo intuitivan grafički prikaz prilagođen ljudskoj percepciji. CPN pomagala se sastoje od skupa modula, prikazanih kao stranice od kojih svaka sadr�i svoju mre�u mjesta i prijelaza povezanih granama. Moduli međusobno komuniciraju preko skupova dobro definiranih sučelja, na sličan način kako to čine moderni programabilni jezici, kao na primjer u objektnom programiranju. Mo�da najva�nija karakteristika CPN-a je način grafičkog prikaza koji čini osnovnu strukturu kompleksnog CPN modela vrlo vizualnom, te vrlo shvatljivo međudjelovanje individualnih procesa. Grafički editor temeljen je na naprednim interakcijskim tehnikama. Odzivi omogućavaju prikaz poruka kontekstualnih pogre�aka i naznačuju ovisnosti i odnose među elementima mre�e. Alat omogućuje inkrementalno sintaksno provjeravanje i generaciju koda kako mre�a biva građena. Brzi simulator vrlo uspje�no barata i s vremenskim i nevremenskim mre�nim modelima. Potpuni i djelomični grafovi stanja mogu biti generirani i analizirani uključujući i izvje�taj o ograničenjima svojstava. CPN pomagala kori�tena su u brojnim praktičnim projektima s raznolikim područjima primjene. CPN pomagala su razvijena na danskom sveučili�tu u Aarhus u kasnim 80-tim i početkom 90-tih godina. Prvenstveno je to bilo Design/CPN pomagalo koje je prvi razvijen i kori�ten u vi�e od 800 različitih organizacija. U slijedećoj generaciji razvijen je CPN Tool koji se i danas koristi u vi�e od 700 organizacija i individualno u 70 zemalja svijeta [19][20][44][46][47].

Kratki opis CPN pomagala

CPN također, ima formalni, matematički prikaz s vrlo dobro definiranom sintaksom i semantikom. Taj prikaz je temelj za definiranje različitih procesnih svojstava i metoda analize. Bez tog matematičkog prikaza, ne bi bilo moguće razviti jak i značajan CPN jezik. Bez obzira na to, praktična primjena CPN-a zadovoljava intuitivno razumjevanje semantike i sintakse. To je analogno programabilnim jezicima uspje�no primjenljivim od strane korisnika koji nisu prisni s formalnim, matematičkim definicijama tih jezika. CPN modeli mogu se konstruirati sa ili bez određene vremenske reference. CPN modeli bez vremenske komponente obično su kori�teni za potvrđivanje funkcionalno-logičke ispravnosti sustava. Dok se mre�ni modeli s vremenskom komponentom koriste za procjenu performansi nekog sustava. CPN modeli mogu biti simulirani interaktivno ili automatski. Interaktivnu simulaciju kontrolira korisnik, gdje je moguće vidjeti efekte sa svakim pojedinačnim korakom, direktno na grafičkom prikazu CPN-a. To znači da korisnik mo�e istra�ivati različita stanja medu dopu�tenim prijelazima, �to je slično debagiranju korak po korak (engl. single-step debugging). To omogućava lagani prolaz ili �etnju kroz CPN model, istra�ujući različite scenarije i provjeravajući da li pojedini model radi očekivano. To je u suprotnosti s paketnim simulacijskim tehnikama koje se koriste u "crnim kutijama", gdje korisnik definira ulaz i inspektira izlaz, ali ima vrlo malo mogućnosti da shvati i napravi validaciju modela na kojem je simulacija građena. Iskustvo i detaljno znanje o sustavu, koje korisnik povećava tokom razvoja i validacije simulacijskog modela, je često va�no kao i rezultati koje korisnik dobiva iz tekuće simulacije. Automatska simulacija slična je izvr�avanju nekog programa. Kod nje je bitno omogućiti �to br�e izvođenje simulacije CPN modela bez detaljnije ljudske interakcije i inspekcije. Bez obzira na to, korisnik jo� uvijek mora sam interpretirati simulacijske rezultate.


44

Za�to koristiti CPN?

Tri su osnovna razloga za�to koristiti CPN pomagalo:

• CPN, kao prikaz modeliranog sustava, mo�e biti kori�ten kao specifikacija ili prezentacija sustava koji se �eli izgraditi

• izgradnjom modela istra�uje se novi sustav prije nego li je konstruiran, te ispituje simulacijom i formalnom analizom

• intuiciji blizak način prikaza i kreacije sustava, koji in�enjerima nude olak�ano snala�enje i razumijevanje u modelima velikih sustava.

CPN ima dobro definiranu semantiku koja vrlo jasno i nedvosmisleno definira pona�anje svake obojene mre�e. CPN je generalan, stoga vrlo lako mo�e biti kori�ten kod opisivanja pona�anja velikih i slo�enih sustava. Jednostavnim, jakim i malobrojnim primitivima, moguće je razviti vrlo jaku metodu analize. Sadr�i jasnu i određenu definiciju i stanja i akcija, �to je u suprotnosti s većinom jezika za opis sustava koji obično opisuju ili stanja ili akcije, ali nikad oboje. Koristeći CPN, vrlo lako se mo�e mijenjati fokus sa stajali�ta stanja, na stajali�te akcija i obrnuto. Također, semantika je izgrađena na pravoj istovremenosti, a ne na preplitanju. Kod preplitanja je nemoguće imati dvije akcije u isto vrijeme, tj. u istom koraku, �to znači da se akcije mogu izvr�avati samo jedna nakon druge. Semantika prave istovremenosti ili konkurentnosti je bli�a ljudskoj prirodi, stoga i lak�a za upotrebu. Hijerarhijski opis sustava vrlo je povoljan za definiciju velikih sustava, �to je jo� jedna od velikih prednosti CPN-a. CP-mre�e integriraju opise kontrole i sinkronizacije s opisom upravljanja podacima, �to znači da se na običnom listu papira mo�e vidjeti koji su uvjeti, okolina i efekti svake akcije. Mnogi drugi grafičko-deskriptivni jezici rade s grafovima koji opisuju samo okolinu od pojedine akcije, dok je detaljno pona�anje specificirano odvojeno. Također, mre�e mogu biti pro�irene s konceptom vremena. To znači da je moguće koristiti isti jezik za modeliranje, specifikaciju i validaciju funkcijsko-logičkih svojstava (kao �to je slučaj s konfliktima), te koristiti ga i za provođenje svojstava u vremenu (npr. mjerenje prosječnih vremena čekanja). Glavna ideja koja le�i iza uvođenja vremenskog koncepta u CPN je pojam globalnog sata, čiju vrijednost nosi svaka od oznaka i pokazuje kad je ista spremna da bude obrađena od strane nekog prijelaza. Jedna od velikih prednosti je ta da je CPN stabilan u slučaju manjih promjena na modeliranom sustavu. To je isku�ano na mnogim praktičnim primjerima �to znači da manje modifikacije sustava ne stvaraju promjene u kompletnoj strukturi sustava. Moguće je stoga djelomično dodati novi sekvencijalni proces bez promjene strukture mre�e koja je prikazana postojećim procesima. Također, CPN nudi interaktivnu simulaciju gdje su rezultati prikazani direktno na CPN dijagramu, �to je vrlo korisno za debagiranje pojedinih dijelova velikih modela, jednako kao �to to čini programer na programskom kodu, prije nego li je on potpuno isprogramiran. Vrijednosti podataka u svakoj oznaci koja putuje mre�om mogu biti provjerene. Također, CPN nudi vi�e verifikacijskih metoda, znanih kao analiza prostora stanja Petrijeve mre�e i invariantne analize. U tom pogledu, moguće je dokazati, u matematičkom smislu te riječi, da sustav sadr�i određeni skup svojstava i pravila pona�anja. Bez obzira na tu mogućnost, industrijski sustavi su često toliko komplicirani da ih je nemoguće ili vrlo skupo testirati do kraja njihovu ispravnost. Stoga se formalna verifikacija ograničava na najva�nije podsustave ili aspekte kompleksnog sustava. Dakle, CPN sadr�i brojne formalne metode za analizu kojima modelirane mre�e mogu biti testirane. Također, sadr�i i pomagala koja


45

omogućuju crtanje, te prikaz simulacije i formalne analize. Sve te značajke vrlo su bitne za kori�tenje ovakvog pomagala u praksi. [19][20][44][46][47]

Analiza Petrijevih mre�a s pomoću CPN pomagala

Petrijeve mre�e mogu biti analizirane na vi�e različitih načina: prvi je je svakako, metodom interaktivne simulacije, �to je slično debagiranju. To znači da je moguće napraviti detaljno istra�ivanje pona�anja modeliranog sustava izvr�avanjem CPN modela. Moguće je napraviti mjesta prekida i pregledati rezultate simulacije. Slijedeća vrsta analitičke metode je automatska simulacija koja je slična izvr�avanju programa, stoga omogućava brzo izvr�enje vi�e tisuća ili miliona prijelaza. Naravno, svrha je istra�iti funkcionalnu ispravnost sustava ili njegovih performansi, na primjer identificirati uska grla sustava, procijeniti mjesta za međuspremnike (engl. buffer space). Treća metoda analize su grafovi događaja (engl. occurrence graphs), također znani pod imenima grafovi dosega ili grafovi stanja (engl. state spaces, reachability graphs). Osnovna ideja grafova događaja ili stanja je konstruirati graf, gdje svaki čvor predstavlja jedno od mogućih stanja koje se pojavljuje u sustavu, a svaka grana grafa predstavlja moguću promjenu takvih stanja. Očigledno je da svaki graf mo�e imati vrlo veliki broj elemenata, čak i za vrlo male CPN modele. Bez obzira na to, grafovi će biti konstruirani potpuno automatski. Postoje tehnike koje čine analizu i rad s takvim grafovima mogućim, bez gubitka analitičke snage. To su tehnike građene nad ekvivalentnim klasama.

Četvrta metoda analize je analiza invariance. Ta metoda vrlo je slična analizi običnih programa, gdje korisnik konstruira skup izraza koji moraju provjeriti sva stanja sustava u dosegu. Ti izrazi su kori�teni kao test svojstva modeliranog sustava, na primjer dokaz odsutnosti mrtvih petlji. Ta metoda, moglo bi se reći, je ekvivalentna funkcijskom i sistemskom testiranju kod softverskih programa. [19][20][44][45][46][47]

3.4.5 Varijable modeliranog sustava

Varijable sustava kojeg se modelira sadr�e odabrane podatke, koje sustav zahtjeva za simulaciju ili ih daje kao rezultat. Stoga se varijable dijele na ulazne i izlazne varijable. U slijedećim poglavljima bit će navedene i obja�njene varijable koje su kori�tene u modeliranju, simulaciji i optimizaciji MPRS-a [33].

Ulazne varijable

Ulazne varijable modeliranog sustava čine:

• varijable projektne specifikacije,

• vremenske varijable za pojedinu procesnu fazu,

• varijable ljudskih resursa,

• varijable projektne dokumentacije,

• pomoćne varijable modela.


46

Varijable projektne specifikacije

Varijable projektne specifikacije slu�e za definiranje vrste razvojnog procesa. U ovom slučaju, kao primjer je uzet mogući izbor varijabli projektne specifikacije razvojnog procesa. Moguće vrijednosti varijabli pridru�ene su slijedećim opcijama:

• proces velikih projekata,

• proces malih projekata,

• proces projekta razvoja softvera iz početka,

• proces projekta u kojima se nadopunjuje već prije razvijeni softver,

• opcija razvoja isključivo softverskog proizvoda,

• opcija razvoja softvera i pripadajućeg hardvera.

Tih �est opcija, grupirane su u tri varijable (Slika 3-5), tj. postoji �est vrsta različitih procesa u jednom procesu razvoja ili �est različitih pona�anja istog procesa, �to ovisi o definiciji početnih uvjeta. U ovom radu nisu posebno razmatrani i analizirani svi načini, već su oni modelirani samo kao prijedlog mogućeg načina modeliranja i pristupu analizi procesnog sustava. Na slici (Slika 3-5) u vrhu, prikazana je deklaracija varijabli projektne specifikacije u softverskom pomagalu za modeliranje i simuliranje obojenim Petrijevim mre�ama, CPN Tools.

Slika 3-5: Deklaracija ulaznih varijabli međufaze analize u CPN pomagalima


47

Vremenske varijable procesnih faza

Svaka procesna faza opisana je skupom varijabli, vremenskim varijablama kojima se definira pretpostavljeno vrijeme za izvr�avanje određenih aktivnosti unutar faza procesa. Na slici (Slika 3-5) u donjem dijelu prikazan je skup vremenskih varijabli međufaza analize, koje su uglavnom odnose na vrijeme potrebno za stvaranje određenog dokumenta. U varijablama faze analize iznimke su varijable kojima je definirano, npr. prosječno vrijeme utro�eno po jednom projektnom sastanku, vrijeme administracije ili inspekcije dokumenta. Izbor vremena je deterministički (zbog jednostavnosti modela), iako je vrlo jednostavno svakoj varijabli pridodati stohastičku funkciju ili bilo kakav drugi oblik funkcijski definiranog vremena.

Slika 3-6: Deklaracija ulaznih varijabli dizajna

Deklaracija varijabli dizajn faze: navedena su dva polja s vrijednostima vremena potrebnim za dizajniranje pojedinog modula, njegovo kodiranje i pisanje odgovarajuće dokumentacije, slika (Slika 3-6). Varijable dizajna i kodiranja modula, definirane su kao polja vrijednosti dizajna, kako zadani broj modula ne bi bio strogo definiran. Model automatski proračuna koliko je vrijednosti upisano u polja i prema tome zaključuje koliki je broj modula u sustavu. Oba polja moraju imati isti broj elemenata, jer u protivnom dolazi do pogre�ke u izvr�avanju simulacije. U deklaraciji na slici (Slika 3-6) radi se o pet modula s istim zadanim vemenima, od 300 radnih sati dizajna po modulu i 200 radnih sati utro�enih na kodiranje modula.

Slika 3-7: Vremenske ulazne varijable pridru�ene fazi testiranja

Ulazne varijable za fazu testiranja slijede istu logiku deklariranja kao i u prethodnim primjerima, �to je prikazano na slici (Slika 3-7). Ako se prati proces i vodi redovita statistika pogre�aka na prethodnim projektima, moguće je predvidjeti koliko će se otkriti pogre�aka u


48

funkcionalnosti ukupno na projektu ili pojedinačno po modulima. Tehnike predviđanja pogre�aka (engl. fault density prediction) u određenim fazama isporuke temelje se na rezultatima koji su dobiveni empirijski, dugogodi�njim praćenjem statistike pogre�aka pri određenoj razini organizacije odjela za razvoj.

Slika 3-8: Deklaracija ulaznih varijablt faze isporuke

Deklaracija varijabli faze isporuke prikazana je na slici (Slika 3-8). Time je dovr�eno deklariranje varijabli po fazama procesa.

Varijable ljudskih resursa

Varijable ljudskih resursa definirane su kao nazivi 9 različitih projektnih uloga koje se mogu pojaviti u MRPS-u, vidljivih na slici (Slika 3-9).

Slika 3-9: Ulazne varijable modela koje definiraju broj ljudskih resursa

Vrijednosti varijabli mogu varirati prema �eljenom broju članova projektnog tima, s ograničenjem donje granice vrijednosti za pojedine uloge, kao �to je slučaj s brojem dizajnera i testera u njihovim pripadajućim timovima. Pojedine uloge, iako deklarirane, u pojedinim slučajevima nisu kori�tene od strane MRPS-a, budući da su pojedini procesi modelirani bez njihovog upliva. Takav je slučaj kod izbora procesa malog projekta, gdje se ne koriste uloge menad�era kvalitete, ili na primjer procesa koji ne sadr�i razvoj hardvera pa uloga hardverskog in�enjera nije potrebna u takvom razvojnom procesu.

Slika 3-10: Deklaracija projektne boje u kojoj se nalaze alfanumeričke oznake pridru�ene

dokumentima, mjestima kontrole, točkama odluke i kontrolni toka procesa.

Varijable projektne dokumentacije sadr�e popis mogućih dokumenata koji se koriste u razvojnom projektu, a opisani su u tablici (Tablica 2-1) Kao �to je vidljivo iz slike (Slika


49

3-10), dokumenti su definirani u CPN pomagalima kao različite oznake (engl. tokens) jedne te iste projektne boje označene slovom P. Boja P pripada jednostavnim skupovima boja (engl. Simple Colour Sets), tzv. nabrajajućem skupu boja (engl. Enumerated Colour Sets), gdje su indentifikatori eksplicitno navedeni u deklaraciji. Te vrijednosti moraju biti alfanumeričkog tipa [20]. Dakle, svaki dokument definiran je kao oznaka koja putuje Petrijevim modelom procesa razvoja softvera, isključivo onim mjestima koja su deklarirana kao projektna (slovo P) ili granama koje su deklarirane odgovarajućom oznakom iz projektne boje ili varijablom pridru�enoj projektnoj boji. Uz oznake dokumentacije, projektna boja sadr�i jo� dodatne oznake stanja dokumenata ili akcija, oznaku izvje�taja i procesne oznake za pojedine točke odluke i mjesta kontrole, (Slika 3-10). Također boja P deklarirana je kao boja s vremenskom komponentom, �to znači da se oznakama te boje, sa svakim korakom izvr�enja, pridjeljuju određene vrijednosti vremena. Te vrijednosti vremena koriste se za proračun potrebnog vremena kod izvr�avanja svake pojedine faze, ali i čitavog projekta. Ova boja, međutim, ne nosi informaciju o opterećenosti ljudskih resursa i utro�enom vremenu po procesnoj ulozi projektnog tima.

Pomoćne varijable modela

Pomoćne varijable sustava pripadaju klasičnoj deklaraciji CPN modela, a radi se o deklaracijama varijabli koje omogućuju pravilan rad modeliranog sustava. One nisu va�ne ili su vrlo malo bitne osobi koja koristi model za simulaciju. Naime, to su interne varijable modela, prikazane na slici (Slika 3-11).

Slika 3-11: Pomoćne varijable modeliranog MRPS-a

Pod definicijom pomoćnih varijabli modela, uvr�tene su i deklaracije boja. Tako su deklarirane boje koje model koristi u simulacijama za tokove dokumentacije, resursa, proračun vremena aktivnosti:


50

Boja M: pripada indeksiranom skupu boja (engl. Index Colour Sets), grupi jednostavnih skupova boja. Koristi se za upravljanje kod manipulacije modulima koji su bili naznačeni u poljima vrijednosti projektne specifikacije faze dizajna modula. Oznake te boje poprimaju indekse brojeva proporcionalno količini zadanih modula u poljima vrijednosti projektne specifikacije.

Boja T: boja pripada nabrajajućim skupovima boja i sadr�i troslovne oznake koje simboliziraju članove razvojnog tima brojčano navedene u deklaraciji varijabli ljudskih resursa.

Boja H: također boja koja pripada nabrajajućem skupu boja. Sadr�i oznaku koja predstavlja jedan radni sat potro�en u stadiju testiranja.

Boja I: pripada numeričkom skupu boja bez decimalnog mjesta (engl. Integer Colour Sets). Ova boja se primjenjuje u gotovo svim mre�ama modela, gdje je god potrebno manipulirati brojčanim vrijednostima, koje moraju bit pridru�ene nekoj varijabli.

Boja TI: ova boja pripada slo�enim skupovima boja (engl. Compound Colour Sets) budući da je slo�ena od dvije prethodno deklarirane boje (boja T i boja I) kao kartezijev produkt tih dviju boja. Također oznaka timed deklarira boju u vremenskoj domeni, stoga ova boja predstavlja opterećenje ljudskih resursa u procesu razvoja softvera, tj. koliko je svaka procesna uloga projektnog tima bila kori�tena u razvojnom procesu.

Boja MI: ovo je također boja koja pripada slo�enim skupovima boja. Također se sastoji od kombinacije dvije boje koje čine dvodimenzionalni zapis: boja M predstavlja modul, a boja I predstavlja vrijeme pridru�eno tom modulu. Boja se koristi kod rukovanja modulima u fazi dizajna i kodiranja, te rukovanjem vremenima potrebnim za izvr�avanje pojedinih aktivnosti u dotičnim fazama. Boja nema vremensku komponentu, tj. nije definirana u vremenskoj domeni.

U pomoćne varijable modela svrstane su i CPN varijable koje se koriste u natpisima grana i segmentima kôda, čije vrijednosti se mogu mijenjati tijekom izvr�avanja simulacije. One su deklarirane tako da koriste ključnu riječ var i pridru�uju se jednoj od prethodno deklariranih boja (Slika 3-11). Varijabla koja pripada odeđenoj boji podr�ava isključivo oznake te boje. Među varijablama se nalazi i dekaracija vrijednosti ljudskih resursa, tj. projektnog tima Tim (Slika 3-12).

Slika 3-12: Definiranje vrijednosti ljudskog resursa, deklariranog kao skup timskih

slo�enih oznaka, koje se koriste u CPN modelu

To je pomoćna varijabla sustava deklarirana kao vrijednost i koristi se za inicijalizaciju mjesta koje sadr�i ljudske resurse, tj. pridru�uje svakoj oznaci TI boje količinsku vrijednost određene procesne uloge u projektnom timu. Deklarirana je kao zavr�na deklaracija, budući da prije nje


51

moraju biti deklarirane varijeable i navedene vrijednosti kojima se ona koristi u svojoj deklaraciji.

3.4.6 Izlazne varijable sustava - performanse sustava

Izlazne varijable predstavljaju performanse modeliranog sustava i u MRPS-u su to vremenske oznake projektne boje (oznaka P) koje putuju sustavom i zavr�avaju u mjestima predviđenim za izvje�tavanje. Izlazne varijable su, dakle, vremenskog karaktera i predstavljaju vrijeme u satima potro�eno za pisanje određenog dokumenta, izvr�enje određene faze ili radnu opterećenost svake pojedine procesne uloge. Izlazne varijable ne moraju posebno biti deklarirane u CPN modelu, budući da ih čine oznake projektne boje, koje su definirane na samom početku. Pravim izlaznim varijablama smatramo vrijednosti vremenske komponente pojedinih oznaka procesne boje, nakon izvr�enja kompletne simulacije modela, sve dok nakon određenog broja koraka te oznake ne zauzmu zavr�na mjesta izvje�tavanja. Na temelju vrijednosti izlaznih varijabli bit će tumačeni rezultati simulacije, �to će biti navedeno u daljnjim poglavljima [20].

3.5 Izgradnja simulacijskog modela elementima CPN pomagala

Na prvi pogled, čak i vrlo jednostavni sustavi, u pravilu su slo�eni i opse�ni, stoga je posebno slo�en zadatak iznaći kako prikazati takav sustav. To je osnovni problem koji prate procese analize, a to je upoznavanje i istra�ivanja postojećeg sustava u cilju modeliranja sustava za njegovu buduću simulaciju. Nemoguće je opisati, čak vrlo male sustave, ako nemamo mogućnost hijerarhijskog prikaza strukture. Dakle, kako bi se izbjegla nezgrapnost pristupa se dekompoziciji procesnog sustava, tj. sustav se razbija na podsustave, a podsustavi na manje procesne jedinice, sve dok se ne zadovolji određena dubina analize. Dekomponirajući sustav dolazi se do hijerarhijske strukture sustava. Djelomično je to već napravljeno i navedeno u drugom poglavlju (Slika 2-2).

3.5.1 Hijerarhijska struktura CPN modela

Prikaz slo�enog sustava, tj. procesa ima dva moguća pristupa razvoja: jedan je od donjih slojeva ka gornjem ili odozdo-nagore (engl. bottom-up development), ili odozgo-nadolje (engl. top-down development). CPN pomagala podr�avaju oba modela razvoja. Budući da je MRPS nastajao analizom poslovnog procesa razvoja softvera uz djelomičnu upotrebu PROPS-a, postojali su vrlo dobri temelji modeliranja sustava odozdo-nadolje ili top-down metodom. Oba procesa su detaljno obja�njena u procesnoj dokumentaciji koja se koristi u svakodnevnom radu tvrtki koje ih koriste. Uglavnom, to su skice i smjernice kako razviti kvalitetan softver i izgraditi zadovoljavajuću organizaciju koja će to uspje�no izvesti. Pod organizacijom se smatra rukovanje tokovima dokumentacije i znanja, te iskoristivost ljudskih resursa u zadanom vremenu, bez njihovog preopterećenja. Prije nego li se objasni struktura modela, potrebno je navesti i objasniti elemente CPN pomagala koja omogućuju hijerarhijsku dekompoziciju i povezanost podsustava.


52

Elementi CPN modela i hijerarhijske strukture

Slično modularnom programiranju, konstruiranje CPN modela mo�e biti razlomljeno u manje zaokru�ene cjeline ili podmre�e koristeći elemente unutar CPN pomagala koja podr�avaju rad s hijerarhijskom strukturom. Osnovni element je supstitucijski prijelaz (engl. substitution transition). Konceptualno, mre�e sa supstitucijskim prijelazima su mre�e s mnogostrukim slojevima ili razinama, tj. moguće je model prikazati poprilično jednostavno, dajući skicu sustava kao pojednostavljeni prikaz sustava kojeg se modelira. U takvim mre�ama, supstitucijski prijelazi predstavljaju opću sliku podprocesa ili mre�e koja je utisnuta u njegovu funkcionalnost, tj. vidljiva na ni�oj razini. Silazeći na sve ni�u i ni�u razinu, moguće je opisivati funkcionalnosti sve detaljnije i detaljnije, po�tujući pravila top-down modeliranja. Upravo to je kori�teno pri modeliranju MRPS-a. Model je modeliran na tri razine. Prva ili najvi�a razina (engl. top-level), nazvana PROCES (ime je navedeno u gornjem lijevom kutu) predstavlja faze razvojnog ciklusa softvera (Slika 3-13), kao �to je to vidljivo na sici (Slika 2-1) 2. poglavlja.

Slika 3-13: Prva (najvi�a) razina CPN modela MRPS-a; mre�a sastavljena od mjesta,

prijelaza i grana. Mjesta predstavljaju točke odluke i mjesta kontrole, a prijelazi sadr�e mre�e druge hijerarhijske razine.

Kao �to je vidljivo iz slike (Slika 3-13) četiri faze razvojnog procesa predstavljene su s četiri supstitucijska prijelaza (prijelazi: ANALIZA, DIZAJN, TEST i ISPORUKA). Osim navedenih, postoji i peti supstitucijski prijelaz koji slu�i za prikupljanje podataka tokom izvođenja, tj. simulacije modela. Prijelazi u modelu su predstavljeni kao pravokutnici, a ako predstavljaju cijeli dio mre�ne strukture, tako da sadr�e podmre�u, onda se takvi prijelazi nazivaju supstitucijskim i pored sebe sadr�e plavičastu pravokutnu oznaku podmre�e (engl. subpage tag) s navedenim imenom iste. Za primjer, supstitucijski prijelaz RAPORT sadr�i podmre�u koja je naznačena plavičastom oznakom podmre�e i slovom R kao njenim nazivom.


53

Osim opisanih prijelaza, vidljiva su i mjesta koja odgovaraju mjestima kontrole i točkama odluke u PROPS-u, tj. razvojnom procesu softvera, MRPS-u. Boje i nazivi mjesta odgovaraju određenim točkama odluke i mjestima kontrole. Svako mjesto mora imati deklaraciju boje kojoj pripada, tj. samo oznake te boje moći će koristiti to mjesto. Nemoguć je slučaj da je mjesto deklarirano s vi�e boja, osim ako te boje nisu dijelovi slo�enih skupova boja, koji opet kao takvi predstavljaju jedinstvenu boju. Deklaracija tipa mjesta nalazi se u donjem desnom kutu mjesta kao natpis skupa boje kojoj mjesto pripada. U gore navedenom slučaju, sva mjesta pripadaju projektnoj boji P, stoga se u tim mjestima mogu naći isključivo oznake te boje. Boje pridru�ene bilo kojem mjestu, unaprijed moraju biti deklarirane u sektoru za deklaraciju, koji se nalazi s lijeve strane CPN pomagala. Prijelazi i mjesta međusobno su povezani usmjerenim granama (engl. arcs) koje su definirane pripadajućim izrazima. Ti izrazi obično se nalaze iznad ili u neposrednoj blizini grane i odgovaraju joj po boji. Svi izrazi koji se koriste u CPN pomagalu, uključujući i deklaracije, pisani su CPN ML-u (engl. Coloured Petri Nets Markup Language). Izraz grane mora biti u skladu s bojom mjesta kojemu je grana pridru�ena. Grane pridru�ene supstitucijskim prijelazima ne moraju imati izraze, budući da se oni definiraju na podrazinama, tj. na posljednjem sloju ili podmre�i unutar tog supstitucijskog prijelaza. Ako su izrazi navedeni na takvim granama, tada nemaju semantičko značenje.

Mre�a koja sadr�i supstitucijske prijelaze naziva se nadmre�a ili nadmodel (engl. superpage), a mre�a koja predstavlja supstitucijski prijelaz i nalazi se na ni�oj razini, naziva se podmre�a ili podmodel (engl. subpage). Nadmre�e i podmre�e su povezane identičnim mjestima u oba slučaja. Mjesta koja se koriste za njihovo povezivanje su specijelna mjesta koja pripadaju fuzijskim skupovima (engl. fusion sets). CPN hijerarhija podr�ava metodu definiranja funkcionalno identičnih mjesta, koja mogu biti postavljena na bilo kojoj razini, u bilo kojem broju i na bilo kojoj strukturi mre�e sustava. �to god se dogodi jednom od tih mjesta, ista stvar se događa i svim ostalim mjestima istog fuzijskog skupa, kao da oznake bivaju teleportirane u sva mjesta isto definiranog fuzijskog skupa. Tehnika fuzijskih mjesta koristi se u slučajevima kad u istoj mre�i postoji mjesto na koje treba priključiti puno grana, koje bi zbog svoje du�ine ili kompleksnosti mre�e, naru�avale preglednost iste. Stoga svakoj takvoj grani mo�emo pridru�iti po jedno mjesto istog fuzijskog skupa i time pojednostaviti grafičku strukturu mre�e, bez naru�avanja njezine funkcionalnosti. Drugi slučaj kori�tenja fuzijskih mjesta je slučaj kada na različitim razinama i u različitim mre�ama postoji potreba za dosegom istog mjesta. Tada se to mjesto zamjeni mjestom, tj. članovima fuzijskog skupa koji predstavlja to mjesto. Grafički tada pridjeljujemo to mjesto bilo kojoj mre�noj strukturi, iako se u osnovi radi o jednom te istom mjestu [19][20][44][45][46][47]. Na sličan način povezuju se nadmre�e i podmre�e kad je u pitanju supstitucijski prijelaz. Koriste se fuzijski skupovi specijalne namjene i oni sadr�e uvijek samo dvije vrste mjesta: mjesta koja se nalaze u nadmre�i i slu�e kao utičnica (engl. socket), a pridru�ena su supstitucijskom prijelazu, te mjesta koja se nalaze u podmre�i i pandani su utičnicama u nadmre�i, nazivaju se priključcima (engl. port). Priključci nekog supstitucijskog prijelaza nadmre�e moraju prema tipu skupa boja, odgovarati pridru�enim utičnicama podmre�e koju predstavlja taj supstitucijski prijelaz nadmre�e.


54

Izgradnja podprocesne razine MRPS-a u CPN-u

Faze MRPS-a koje sačinjavaju taj proces, modelirane su na procesnoj ili vr�noj razini kao supstitucijski prijelazi. Svaka od tih faza opisana je podmre�om implantiranom u funkcionalnost određenog supstitucijskog prijelaza. Time dekompozicijom razvojnog procesa modeliramo drugu, podprocesnu razinu, koja je podrazina prve, glavne ili procesne razine prikazane na slici (Slika 3-13). Tako je supstitucijskom prijelazu ANALIZA procesne razine pridjeljena podmre�a istog naziva, prikazana na slici (Slika 3-14).

Slika 3-14: Podmre�a druge razine ANALIZA pridjeljena istoimenom supstitucijskom

prijelazu

Kao �to se vidi iz slike podmre�e analize, mre�a sadr�i dva priključak-mjesta iz fuzijskog skupa. Radi se o mjestima MK0 i TO2 koji su identični svojim pandanima na procesnoj razini mjestima-utičnicama supstitucijskog prijelaza. Mjesta priključci navedene podmre�e imaju različitu ulogu, �to je naznačeno oznakom tipa priključka (engl. port-type tag). Mjesto MK0 predstavlja ulazni priključak (engl. In port), a mjesto TO2 izlazni priključak (engl. Out port). Podmre�a analize sastoji se od četiri supstitucijska prijelaza koji predstavljaju podmre�e treće razine, zvane operativna razina. Ostali prijelazi nisu supstitucijski i slu�e za izvje�tavanje vremena u podmre�u druge razine, čiji se supstitucijski prijelaz nalazi na glavnoj, procesnoj razini. Mjesto MK1 predstavlja prvo mjesto kontrole gdje dolazi do odvajanja različitih oznaka koje dolaze iz podmre�e treće razine zvane ANALIZA ZAHTJEVA. Sličan slučaj je i s ostalim mjestima, gdje su uvjeti selekcije oznaka vidljivi kao istobojni natpisi navedeni iznad pripadnih grana. Identičan slučaj je i sa slijedećom podmre�om druge razine prikazanoj na slici (Slika 3-15).


55

Slika 3-15: Podmre�a druge razine supstitucijskog prijelaza DIZAJN

Radi se o opisu faze dizajna, koja sadr�i tri supstitucijska prijelaza koji opisuju četiri različita podprocesa faze dizajna, navedenih na slici (Slika 2-2). Podprocesi KODIRANJE i OSNOVNI TEST modelirani jednom mre�om, stoga im je pridjeljen jedan supstitucijski prijelaz. U ovoj podmre�i pojavljuje se fuzijsko mjesto nazvano DOKUMENT BAZA fuzijske oznake DBf, jer predstavlja bazu dokumenata u koju se spremaju dokumenti koji nastaju u različitim fazama MRPS-a. Bilo bi gotovo nemoguće izvesti to fuzijsko mjesto kao obično mjesto, �to će se vidjeti u daljnjem izlaganju.


56

Slika 3-16: Podmre�a druge razine supstitucijskog prijelaza TEST

Istu logiku modeliranja opisanu u prethodnim primjerima mre�a druge razine, imaju i slijedeće dvije podmre�e: TEST (Slika 3-16) i ISPORUKA (Slika 3-17). Podmre�a faze testiranja sadr�i četiri supstitucijska prijelaza koja odgovaraju podprocesima faze testiranja, dakle jo� dvije podmre�e treće, operativne razine.

Slika 3-17: Podmre�adruge razine supstitucijskog prijelaza ISPORUKA

Posljednja u nizu podmre�a druge razine, je podmre�a supstitucijskog prijelaza RAPORT, supstitucijske oznake R, slika (Slika 3-18).


57

Slika 3-18: Podmre�a druge razine supstitucijskog prijelaza RAPORT. Sastavljena je

isključivo od fuzijskih mjesta koja slu�e kao monitor izlaznih veličina

To je specifični oblik podmre�e, budući da ne sadr�i, niti prijelaze, niti grane. Cijela mre�a je sastavljena od fuzijskih mjesta, koja u ovom slučaju predstavljaju monitor rezultata simulacije. Mo�e se reći da su to zavr�na mjesta cijelog modela procesa. U gornjem redu, crvena priključak-mjesta slu�e kao deponij oznaka pojedinih procesnih faza. Kako koja procesna faza biva zavr�ena, tj. kako koja procesna oznaka prolazi mjesta kontrole i točke odluke, �alje se marker iz tih podmre�a u podmre�u izvje�tavanja. Kako markeri izvje�tavanja pripadaju skupu projektne boje P koja je deklarirana u vremenskoj domeni, ti markeri, stoga, nose i vremensku informaciju o prolasku kroz pojedinu fazu, koja zavr�ava u navedenim fuzijskim mjestima. Osim tih mjesta,u podmre�i izvje�tavanja nalazi se i fuzijsko mjesto baze dokumenata, također s oznakama dokumenata i vremenima kada su provjereni i spremljeni u bazu. Plavo fuzijsko mjesto, fuzijske oznake Tf, predstavlja skup ljudskih resursa, tj. procesnih uloga kori�tenih u simulaciji modela, stoga i nosi naziv TIM. Pri samoj inicijalizaciji cjelokupnog modela, timsko fuzijsko mjesto biva inicijalizirano vrijedno�ću varijable Tim koja je deklarirana kao zavr�na pomoćna varijabla u sektoru deklaracije, slika (Slika 3-12). Dakle, timsko fuzijsko mjesto nakon inicijalizacije (za slučaj da je odabrana opcija velikog SW/HW procesa razvoja projekta ispočetka), sadr�avat će 16 oznaka skupa TI boje. To je vidljivo pojavljivanjem broja 16 u zelenom kru�iću koji se nalazi pored tog mjesta. Osim tog kruga oznaka, u zelenom pravokutniku pored njega su prikazane vrijednosti svake pojedine oznake koja se nalazi u tom mjestu. Kako oznake navedenog fuzijskog mjesta pripadaju slo�enom skupu boja, �to je vidljivo u zelenom pravokutniku: TI boja je kartezijev produkt boje članova tima T i numeričke boje I koja predstavlja vrijeme koje je određena uloga bila kori�tena u procesu razvoja. Dakle, svaka oznaka se sastoji od broja koji predstavlja broj identičnih oznaka boje (npr. 1 ili 3). Nakon broja slijedi apostrof koji označuje početak oznake i zatim slijedi oznaka, koja je u ovom slučaju slo�ena iz dvije boje uređene kao Kartezijev produkt, to je troslovna �ifra procesne uloge i broja radnih sati unutar zagrade, odvojenih zarezom. U slučaju da oznaka pripada vremenskoj domeni, nakon njenog navođenja konkatenira joj se vremenski marker @ i iza njega pozitivni cijeli broj koji predstavlja pridjeljena vrijednost internog sata. Npr. prva oznaka 1'(SAN,0)@0 znači da se u


58

mjestu TIM boje TI nalazi 1 oznaka uređenog para (SISTEM , 0 radnih sati), koja se nalazi u početnom mjestu, dakle nije putovala modelom, oznaka @0. Različite oznake međusobno su odijeljene operatorom ++. Zeleni pravokutnik za prikaz boja ne mora uvijek biti vidljiv, �to je stvar izbora, dok je zeleni krug broja oznaka u mjestu uvijek prisutan, kad god neka oznaka postoji u bilo kojem mjestu. Na taj način je rije�en prikaz dinamike simulacije CPN modela.

Izgradnja operativne razine MRPS-a u CPN-u

Kao �to se mo�e vidjeti iz slike (Slika 2-2) u poglavlju 2, MRPS unutar svojih faza analize, dizajna, testiranja i isporuke, sadr�i cijeli niz međusobno povezanih podprocesa. Svaki od tih podprocesa, opisanih u prethodnom poglavlju, sadr�i niz radnji koje tvore strukturu podprocesa. Te radnje opisane su na trećoj razni CPN modela određenim tokom akcija unutar podprocesa. Aktivnosti predstavljaju onaj stvarni operativni posao koji se de�ava unutar opisanih procesa u nekoj organizacijskoj jedinici, stoga one ovise od organizacije do organizacije, tj. različite su u različitim radnim uvjetima, od odjela do odjela. Na slici (Slika 3-19) prikazana je podmre�a treće razine, tj. podmre�a supstitucijskog prijelaza faze analize na drugoj razini, zvanog ANALIZA ZAHTJEVA.

Slika 3-19: Podmre�a treće (operativne) razine pridru�ene supstitucijskom prijelazu

ANALIZA ZAHTJEVA, koji se nalazi u podmre�i druge razine zvane ANALIZA

Podmre�a ANALIZA ZAHTJEVA operativne razine definirana je kao skup aktivnosti ili radnji koje u njoj moraju biti obavljene od strane određenih članova tima i u unaprijed definiranom vremenu naznačenom u deklaracijama varijabli faze analize. Kao �to se vidi iz slike, potrebno je analizirati zahtjev, napisati dokumente analize zahtjeva, izvr�iti inspekciju tih dokumenata i pospremiti ih bazu dokumenata. Za sve te akcije točno je propisano u procesnoj dokumentaciji tko ih i u kojem trenutku izvr�ava, dok projektna dokumentacija mora sadr�avati vrijeme potrebno za njihovo izvođenje i administraciju. Na temelju tih podataka, simulacijom će biti utvrđeno realno vrijeme obavljanja tih aktivnosti, opterećenje ljudskih


59

resursa i cijena izvr�enog posla. Mjesta MK0 i MK1 čine priključke na nadmre�u treće razine, tj. na supstitucijski prijelaz. Budući je cjelokupni model inicijaliziran, u mjesu MK0 nalazi se oznaka zahtjeva projektne boje P, �to je vidljivo u zelenom pravokutniku vrste oznaka i brojčano u kru�iću broja oznaka u mjestu. Radnja Zahtjev-ANALIZIRAJ predstavljena je prijelazom, koji nije supstitucijski, budući da ne postoji slijedeća razina CPN modela. Zelena aureola oko njega naznačuje da su ispunjeni svi ulazni uvjeti da prijelaz bude izveden. Dva su ulazna uvjeta: prvi je da postoji projektna oznaka zahtjeva, a druga je da postoji bar jedan analizator sustava (SAN) u fuzijskom mjestu ljudskih resursa, tj. timskom mjestu. Nakon izvr�enja prvog koraka simulacije modela pojavit će se dvije oznake projektne boje u slijedećem mjestu (1'SpecZahtj@21 i 1'SistSkica@21), kako je to definirano u grani koja povezuje to mjesto s Zahtjev-ANALIZIRAJ prijelazom. Time će biti stvoreni uvjeti za izvr�enje slijedećeg prijelaza (NAPISATI DOKUMENTE). Ako se obrati pa�nja na vremenske komponente tih dvaju oznaka, vidi se da su se promijenile vremenske vrijednosti u odnosu na vrijednost vremenske komponente oznake Zahtjev. To znači da je za izvr�enje akcije analiziranja zahtjeva trebalo potro�iti 21 radni sat, �to je iznos definiran izrazom u gornjem desnom kutu prijelaza Zahtjev-ANALIZIRAJ maslinasto-zelenom bojom (@+vZ+adm). Na taj se način svakoj akciji opisanoj CPN modelom mo�e pridjeliti vrijednost vremena, samo kao rastuća pozitivna funkcija. Svim oznakama, koje će stvoriti taj prijelaz, bit će uvećana vrijednost vremenske komponente za taj iznos, koji je u ovom slučaju, definiran u deklaracijama, tj. kao ulazne varijable pojektne specifikacije (vrijeme analize zahtjeva i vrijeme potrebno za administraciju). Ista stvar je s oznakom u ljudskim resursima, na kojoj je vidljivo da je bila kori�tena 11 radnih sati (1'(SAN,21)@ 21). Elementi mre�nog modela koji označuju tokove projektnih oznaka i dokumentacije pobojani su crnom bojom, iznimno crvenom i zelenom, ako je riječ o mjestima kontrole i točkama odluke. Dijelovi mre�e koji upravljaju raspodjelom ljudskih resursa, ne mije�aju se s tokovima projektnih oznaka, te su naznačeni plavom bojom radi lak�eg vizualnog snala�enja u modelu.

Slika 3-20: Prikaz stanja AZ podmre�e nakon 5 izvr�enih koraka simulacije: tri

dokumenta su napisana i inspektirana, te spremljena u dokument bazu. Za tu aktivnost kori�tena su 4 ljudska resursa. Cijela aktivnost izvedena je za 67 radnih sati.

Nakon 5 izvr�enih koraka simulacije, model je �izvr�io� sve akcije potrebne za simulaciju operacijske faze ANALIZA ZAHTJEVA, kao �to je to prikazano na slici (Slika 3-20). U fuzijskom mjestu baze dokumenata nalaze se tri oznake napisanih i inspektiranih dokumenata. Prema vremenskim komponentama tih oznaka vidljivo je u kojem su vremenu zauzele to


60

fuzijsko mjesto, drugim riječima, koliko je trebalo tim dokumentima da budu napisani i inspektirani (21, 64, 67 sati). Također, vidljivo je da za cjelokupnu operaciju analize zahtjeva treba proteći 67 efektivnih radnih sati, �to bi u praksi značilo oko 8 i pol radnih dana (vidljivo je iz vremenske komponente 1'Ok@67 projektne oznake). Međutim, da bi se obavila ta operacija u navedenom vremenu potrebno je uposliti 4 osobe na projektnim du�nostima arhitekta, analizatora sustava (engl. system analyst), projektnog i test menad�era koji ukupno potro�e 125 radna sata (67+46+6+6), �to je vidljivo u pravokutniku vrste timskih oznaka, slika (Slika 3-20). Stoga, vrijednost 125 ne označava vremenski period potreban za izvođenje akcije, već ukupno utro�eno vrijeme, �to se definira kao cijena utro�enog rada računata u zaposlenik satima [mh ili mhr, engl. man-hour]. U mjestu MK1, koje je zavr�no mjesto operacijske faze ANALIZA ZAHTJEVA, nalaze se 4 oznake: oznake zavr�etka faze za svaki pojedini dokument (1'Ok@64 i 1'Ok@67) i markeri izvje�tavanja prolaska kroz mjesto kontrole MK1, koji će kasnije biti kori�teni u podmre�i izvje�tavanja na drugoj razini. Time su zadovoljeni uvjeti potrebni za nastavljanje simulacije modela, preno�enjem oznaka u slijedeću podmre�u treće razine, koja je predstavljena supstitucijskim prijelazom SISTEM STUDIJA na drugoj razini, prikazano slikom (Slika 3-21).

Slika 3-21: Podmre�a treće razine opisuje aktivnosti SISTEMSKE STUDIJE

Podmre�a operativne razine nosi naziv SISTEM STUDIJA, a sastoji se od aktivnosti vezanih uz pisanje i inspektiranje dokumenata razrade softvera i hardvera. Ova podmre�a se ne razlikuje konceptualno od prethodno opisane, tj. ne sadr�i neke nove elemente dinamike pona�anja koje bi trebalo posebno objasniti. Kao �to se vidi, ulazna priključnica mjesta kontrole MK1 ove podmre�e je identična s izlaznom priključnicom podmre�e ANALIZE ZAHTJEVA, dakle oznake zavr�nog stanja iz prethodnog primjera, postat će ulazne oznake podmre�e sistemske studije. Isti mehanizam prijenosa oznaka vrijedi za sve podmre�e treće razine, �to je diktirano pravilima hijerarhijske strukture CPN pomagala. Ne�to slo�enija mre�na struktura prikazana je na podmre�i supstitucijskog prijelaza SISTEMSKA ANALIZA, prikazano slikom (Slika 3-22).


61

Slika 3-22: Podmre�a treće razine opisuje aktivnosti SISTEMSKE ANALIZE

Razlika pona�anja ove podmre�e, s obzirom na prethodne dvije, jest pojava paralelizma u izvođenju aktivnosti, �to se mo�e razumjeti kao podjela posla na podtimove nakon �to je sustav bio prostudiran. S obzirom na zadane početne uvjete u deklaracijama projektne specifikacije, odabire se vrsta razvojnog procesa, a time i dokumentacija koja prati određeni proces. Npr. dokumenti implementacije hardvera neće biti pisani u ovoj fazi, ako se projektom ne razvija hardverska komponenta proizvoda. Dakle, u ovoj fazi definira se koji će dokumenti implementacije biti pisani i inspektirani, te shodno tome se iskori�tavaju određene projektne uloge, tj. ljudski resursi. Podmre�a supstitucijskog prijelaza PLANIRANJE RESURSA je posljednja podmre�a treće razine koja pripada aktivnostima procesne faze ANALIZA, prikazano slikom (Slika 3-23).


62

Slika 3-23: Podmre�a treće razine opisuje aktivnosti PLANIRANJA RESURSA

Djelomično, ova podmre�a biva startana čim se pojavi uvjet, tj. projektna oznaka Okk u podmre�i SISTEMSKA ANALIZA, nakon definiranja dokumenata implementacije. To znači da aktivnosti pisanja dokumenata kvalitete u podmre�i PLANIRANJE RESURSA započinju paralelno s aktivnostima pisanja implementacijske dokumentacije podmre�e SISTEMSKA ANALIZA. Projektna faza analize zavr�ava pojavom projektnih oznaka u mjestu TO2, čime se stvaraju uvjeti za početak simulacije faze dizajna. Prva mre�a treće razine faze dizajna prikazana je na slici (Slika 3-24). Ta mre�a opisuje supstitucijski prijelaz faze dizajna na drugoj razini, nazvan PODJELA ZADATAKA.


63

Slika 3-24: Podmre�a treće razine opisuje aktivnosti PODJELE ZADATAKA

Također, unutar te podmre�e nalazi se istoimeni prijelaz čija je zadaća podijeliti zadatke razvojnim timovima, nastalim na temelju podprocesa PLANIRANJE RESURSA. Tehnikom definiranja slo�enih oznaka, posao dizajna modula je prikazan slo�enom bojom MI, koja je slo�ena od dva jednostavna skupa boja M i I, koji predstavljaju module i pridijeljeno im vrijeme potrebno za dizajn. Boja MI nema vremensku komponentu i slo�ena je kao zapis dvije boje (engl. Record Colour Sets). Na taj način omogućeno je svakom modulu da se tretira kao nezavisna oznaka, tj. entitet koji nosi informaciju o vremenu potrebnom za vlastiti dizajn, te tako putuje mre�om. U osnovi, te entitete modula stvaraju mjesto PODJELA PO MODULIMA i prijelaz PRIDJELI VRIJEME. Kako se radi o čisto matematičkoj akciji pridjeljivanja, spomenuti prijelaz nema vremensku komponentu, �to znači da operacija ne tro�i resurs vremena. Ostale aktivnosti opisane su kao paralelne radnje koje trebaju biti izvr�ene u opisanoj podmre�i uz određene vremenske i ljudske resurse. Tako slo�ene oznake modula boje MI dolaze u podmre�u treće razine supstitucijskog prijelaza nazvane MODUL DIZAJN. Tamo se obrađuju na način da vremenska informacija koju nose u sebi biva pridijeljena vremenskoj komponenti svakog pojedinog modula, u aktivnosti koja se odnosi na pisanje dokumenta funkcionalnosti modula, slika (Slika 3-25).


64

Slika 3-25: Podmre�a treće razine opisuje aktivnosti MODUL DIZAJNA

Ovisno o broju modula koji moraju biti dizajnirani, pi�e se i inspektira određeni broj dokumenata funkcionalnosti modula, a shodno tome se tro�e određeni ljudski resursi, kao uče�će dizajnera i arhitekta u tim aktivnostima. Kad su svi dokumenti funkcionalnosti modula inspektirani i ovjereni od arhitekta, prelazi se u fazu kodiranja istih, prema tim inspektiranim dokumentima, slika (Slika 3-26).

Podmre�a supstitucijskog prijelaza KODIRANJE I OSNOVNI TEST, konceptualno je gotovo identična s prethodnom: kori�tena je ista tehnika opisa posla kodiranja svakog modula posebno, oznakama slo�ene boje MI. To je ujedno i posljednja podmre�a faze dizajna, �to znači da se pojavom svih potrebnih oznaka u mjestu MK3, ostvaruju uvjeti za početak simulacije projektne faze TEST, tj. podprocesa testiranja. Kao �to je vidljivo u podmre�i druge razine koja opisuje aktivnosti faze testiranja, slika (Slika 3-16), primjećuje se da se aktivnosti testiranja obavljaju paralelno s pisanjem korisničke dokumentacije i ispravljanjem pronađenih pogre�aka. Testeri su zadu�eni za testiranje modula prema test dokumentaciji stvorenoj u prethodnim fazama, a dizajneri su odgovorni za �to br�e ispravljanje pronađenih pogre�aka u svojem modulu, �to im je prioritetan zadatak.

Kad dizajneri isprave pogre�ke, prelaze na pisanje korisničke dokumentacije vezane uz njihovu funkcionalnost, opisano podmre�om treće razine faze testiranja PISANJE UPUTA, slika (Slika 3-27).


65

Slika 3-26: Podmre�a treće razine opisuje aktivnosti KODIRANJE I OSNOVNI TEST

Slika 3-27: Podmre�a treće razine opisuje aktivnosti PISANJE UPUTA


66

Ova podmre�a opisuje aktivnosti supstitucijskog prijelaza druge razine testiranja vezanog uz pisanje korisničke dokumentacije. U cijelom procesu testiranja kori�tena je drugačija logika opisivanja posla. Problem koji se pojavio u opisivanju ove faze je taj, �to je posao rascjepkan u sitnim dijelovima vremena. Npr. dizajner ispravlja pogre�ku onda kad je ona pronađena i kad je ispravljena, onda nastavlja s pisanjem dokumentacije. Također, svaki dizajner sam sebi planira vrijeme koje će i kada utro�iti za pojedinu aktivnost, stoga je nemoguće paralelizam tih aktivnosti prikazivati kao do sada kontinuiranim vremenom. U tu svrhu definirana je specifična vrsta oznaka cjelobrojnog skupa boja, koja sadr�i vrijeme opisano kao skup diskretnih vrijednosti koje predstavljaju pojedinačni radni sat, tj. 1 mh (čovjek-sat). To su diskretne oznake h boje H. Deklarirana vrijednost ulazne varijable vUP predstavlja količinu radnih sati koja bi trebala biti utro�ena na pisanje korisničke dokumentacije. Ta vrijednost se pretvara u ekvivalentni broj oznaka, normiranih na jedan radni sat, koje sadr�i mjesto vUP SATI. Kako dizajneri sudjeluju i u pisanju uputa i u ispravljanju pogre�aka (opisano u drugoj podmre�i), oni tro�e taj resurs vremena shodno tome koliko su raspolo�ivi u određenom trenutku. Time je osigurano maksimalno kori�tenje paralelizma. Kad god neki dizajner nema posla, on mo�e uskočiti u aktivnosti nekog drugog dizajnera (npr. pisanje korisničke dokumentacije) koji je, npr. zatrpan poslom oko ispravljanja pogre�aka. Takva je stvarna dinamika rada u razvojnim timovima, da se vrijeme �to je moguće bolje koristi, a to je opet zadaća linijskog i projektnog rukovodstva. Sličan mehanizam primijenjen je i u podmre�i funkcijskog i hardverskog testa, prikazanoj na slici (Slika 3-28).

Slika 3-28: Podmre�a treće razine opisuje aktivnosti FUNKCIJSKOG i HARDVERSKOG

TESTIRANJA

Hardversko i funkcijsko testiranje obavlja se paralelno: svaka grana ima svoj fond sati koji su predviđeni za testiranje. Kad su svi sati potro�eni, smatra se da je ta faza zavr�ila. Funkcijsko testiranje je obavezno, međutim hardverski test je opcionalni, �to znači da ga neće biti u određenim procesima razvoja koji mogu biti odabrani kao simulacija. Sličan slučaj je i sa


67

sistemskim testom, slika (Slika 3-29), koji se primjenjuje samo u slučaju kod razvijanja dijela softvera koji će biti ugrađen u neki već postojeći sustav.

Slika 3-29: Podmre�a treće razine opisuje aktivnosti SISTEMSKOG TESTA

Slika 3-30: Podmre�a treće razine opisuje aktivnosti ISPRAVKA GRE�AKA


68

Nakon �to se taj softver ugradi u postojeći sustav, cijeli sustav s uključenom novom funkcionalno�ću mora biti podvrgnut ispitivanju u tzv. sistemskom testu. Tek nakon obavljenog sistemskog testa, sustav se smatra ispravnim, a sve pogre�ke koje bivaju nađene nakon isporuke proizvoda, bit će otklanjane procesima odr�avanja proizvoda, koji nisu uključeni u razvojni proces. Rezultat testiranja nedvojbeno je određena količina prijavljenih pogre�aka sustava dokumentiranih u obrascima zvanim izvje�taji pogre�aka (engl. Trouble Reports). Izvje�tajima upravlja poseban i neovisan proces, koji je na jednostavan način opisan posljednjom podmre�om treće razine faze testiranja, slika (Slika 3-30).

Podmre�a pripada supstitucijskom prijelazu ISPRAVAK GRE�AKA koji se nalazi na drugoj razini faze testiranja. Po strukturi, mre�a koristi isti koncept opisivanja aktivnosti vezanih uz ispravak pogre�aka, kao �to je to osigurano i u ostalim podmre�ama te faze. Posebnim metodama informacijske analize, moguće je predvidjeti kolika će biti pronađena količina pogre�aka u pojedinoj fazi testiranja. Shodno tome, aktivnostima ispravljanja pogre�aka bit će pridjeljena određena količina resursa vremena, navedenog vrijedno�ću ulaznih varijabli Hgr, Fgr i Sgr. Nakon �to budu potro�eni vremenski resursi predviđeni za ispravak pogre�aka pronađenih u testiranju, pojavit će se uvjeti za prelazak u zavr�nu fazu isporuke proizvoda, gdje se poduzimaju zavr�ne aktivnosti potrebne za isporuku razvijenog sustava i zatvaranje razvojnog procesa. Faza isporuke opisana je s dvije podmre�e treće razine. Zavr�ni poslovi oko instalacije i pakiranja proizvoda opisani su podmre�om prikazanoj na slici (Slika 3-31).

Slika 3-31: Podmre�a treće razine opisuje aktivnosti ISPORUKE PROIZVODA

Podmre�a je jednostavna i ne sadr�i nikakve nove elemente koji nisu već prethodno obja�njeni. Također, isti je slučaj s posljednjom podmre�om treće razine koja opisuje izvje�taj o kvaliteti, tj. stvaranje zavr�nog dokumenta vezanog uz kvalitetu proizvoda i rezultate procesa, slika (Slika 3-32).


69

Slika 3-32: Podmre�a treće razine opisuje aktivnosti RAPORTIRANJA KVALITETE

Time je operativna razina potpuno opisana podmre�ama koje opisuju supstitucijske prijelaze mre�a druge, tj. podprocesne razine, kao �to je navedeno u tablici koja prikazuje hijerarhijsku strukturu cjelokupnog modela po razinama, vidljivo tablicom (Tablica 3-2).

BROJ I NAZIV RAZINE CPN MODELA � NAZIVI MRE�A

1. Procesna 2. Podprocesna 3. Operativna Analiza Zahtjeva (AZ) Sisitem Studija (SS) Sistemska Analiza (SA) ANALIZA

Plan Resursa (PR) Podjela Zadataka (PP) Modul Dizajn (MD) DIZAJN Kodiranje i Osnovni test (KD) Pisanje Uputa i Inspekcija (PU) Testiranje (TS) Sistem Test (ST TEST Ispravak Gre�aka (IS) Instalacija i Pakiranje (IP) ISPORUKA Pisanje Raporta Kvalitete (RK)

---PROCES---

RAPORT -

Tablica 3-2: Pregled hijerarhijska struktura modela: 3 razine mre�a

Jo� uvijek je moguće CPN model razrađivati uvodeći nove dekompozicijske razine, međutim, zbog nedostatka detaljnih podataka o određenim ljudskim aktivnostima i izbjegavanju kompleksnosti modela, nije imalo smisla uvoditi slijedeću razinu. Rezultati simulacije ovako dekomponiranog sustava pokazali su dovoljnu informativnost o razvoju pojedinog softverskog proizvoda, kao i način na koji je moguće svaki slični poslovni proces dekomponirati s najvećom precizno�ću [44][45][46][47][48].


70

3.6 Sintaksna provjera ispravnosti modela

CPN pomagala automatski provjeravaju sintaksnu ispravnost mre�e koja se trenutno stvara ili koja je učitana posebnom indikacijom s pomoću boja koje se mijenjaju u ovisnosti kako provjera sintakse napreduje. Indikacija bojama vidljiva je kao vrst aure koja se pojavljuje na svim elementima mre�e uključujući i deklarativni sektor, bez obzira da li je mre�a otvorena u editoru ili ne. Narančasta aura koja se pojavljuje, označava element koji jo� nije pro�ao sintaksnu provjeru. Kod učitavanja mre�nog modela, sintaksna provjera mo�e uzeti nekoliko minuta prije nego li bude provjerena, �to ovisi o veličini modela i brzini računala na kojem se model simulira. Tokom faze provjere sintakse elementi mre�e mijenjaju boje aure od narančaste, preko �ute, sve dok ili ne izgube auru (model sintaksno ispravan) ili poprime crvenu auru koja označava prisustvo sintaksne pogre�ke u modeliranju mre�e. Postoji mogućnost da narančasta aura ne nestaje, �to označava da ne�to nedostaje ili postoji pogre�ka u svezi s elementom mre�e koji se provjerava. Postoji redoslijed provjere pravila koja moraju biti zadovoljena da bi svaki pojedini element bio ispravan:

MJESTO � bit će ispravno ako ima definiranu boju kojoj pripada, tj. natpis boje, niti jedan pridru�eni priključak i utičnica ne smiju imati pogre�ku u sintaksi

GRANA � bit će ispravna ako je ispravno mjesto kojem je pridru�ena i ako sadr�i natpis koji je definira

PRIJELAZ � bit će ispravan ako sva njegova mjesta kojima je okru�en su sintaksno ispravna i ako su sve grane, kojima je prijelaz povezan s tim mjestima, sintaksno ispravne.

Nadalje, ako mjesto sadr�i oznaku priključka koja nije navedena u nadmre�i, tj. priključak nije povezan sa supstitucijskim prijelazom nadmre�e, to mjesto neće moći biti sintaksno provjereno, te će sadr�avati pogre�ku. Dakle, prije nego li supstitucijski prijelaz bude provjeren na vr�noj razini, njegova podmre�a mora biti sintaksno ispravna. �uta aura označava da je tekući element mre�e upravo pro�ao sintaksnu provjeru. U slučaju pojave crvene aure, koja označava postojanje pogre�ke, pojavit će se i oblak izvje�taja s tekstom pogre�ke. Sve dok pogre�ka dotičnog elementa ne bude ispravljena, daljnja provjera istog neće se nastaviti. Pogre�ke pronađene u deklaracijskom sektoru bit će pocrtane crvenom crtom, te će se pojaviti u oblačiću tekst pogre�ke u sintaksi deklaracije. Sintaksna pogre�ka pronađena u deklaraciji nekog elementa izazvat će pojavu sintaksnih pogre�aka u svim mre�ama koje taj element koriste. Deklaracije i natpisi, tj. nazivi elemenata mre�e moraju biti jedinstveni i točni (s obzirom na alfanumeričke simbole), inače se također pojavljuje crvena aura sintaksne pogre�ke, prikazane na ispitavanom elementu. Sintaksnom provjerom, direktno se generira ML kôd mre�nog modela.

Nakon sintaksne provjere cijelog modela moguće je izvr�iti inicijalizaciju mre�nog modela i pokrenuti simulaciju. Simulacija se mo�e odvijati korak po korak ili odjednom. Tokom simulacije, moguće je da budu pronađene pogre�ke unutar mre�e, koje nisu mogle biti identificirane u statičnoj kontroli sintakse. Takve gre�ke bit će signalizirane na isti način kao i obične sintaksne pogre�ke; crvenom aurom oko elementa i oblačićem izvje�taja [19][20][47].


71

3.7 Planiranje i izvođenje simulacijskih eksperimenata

Nakon �to je cjelokupna procesna struktura modelirana do određenog stupnja dekompozicije, a simulacijski model sintaksno provjeren, prelazi se na simulacijska mjerenja. Simulacijsko mjerenja sastoje se od istovrsnih simulacija s različitim početnim uvjetima naznačenim preko deklarativnog sektora modela, a očituju se u razlici broja članova projektnog tima.

3.7.1 Zadatak simulacijskog mjerenja

Zadatak simulacijskog mjerenja je pronaći optimum ljudskih resursa za obavljanje poslova na razvoju proizvoda unutar određenog vremena i u određenim financijskim mogućnostima. Uz pronala�enje glavnog optimuma poslovanja, kao dodatna zadaća se postavlja iznala�enje alternativnih optimuma poslovanja, npr. kao �to je razvoj softvera:

• u najkraćem mogućem vremenskom roku, uz dopu�teno odstupanje u tro�kovima

• s najmanjim mogućim tro�kovima, uz dopu�teno odstupanje u vremenu razvoja

Drugim riječima, potrebno je izraditi funkciju vremena i cijene razvoja softverskog proizvoda s parametrom ljudskog resursa, te na takvim funkcijama naći minimume koji će predstavljati optimalna rje�enja. U tu svrhu bit će potrebno obaviti određenu količinu simulacijskih mjerenja. Kao primjer, izabran je projektni zadatak sa slijedećim zahtjevima:

• vrijeme potrebno za razvoj gotovog softvera ne smije prijeći 2000 sati, �to je ekvivalent vremenskom razdoblju od godine dana (nu�ni uvjet)

• cijena ne smije prijeći vrijednost od 40000 utro�enih radnih sati (dovoljni uvjet)

• potrebno je izabrati optimalni slučaj s obzirom na �to manju količinu ljudskog resursa, te cijenu i vrijeme trajanja razvoja

Dakle, 2000 sati sačinjava 250 radnih dana od po 8 sati, a 250 radnih dana sačinjava 50 radnih tjedana od 5 radnih dana ili 40 radnih sati. Ako se radne tjedne pomno�i sa stvarnim brojem dana dobiva se vremensko razdoblje od 350 dana, �to je pribli�no jednako vremenskom roku od jedne godine. Cijena od 40000 radnih sati, iznosi 6.000.000$, ako se uzme da je brutto prosječna cijena radnog sata u razvojnom timu 150$. Potrebno je naći optimum između vremena i ulo�enih sredstava kod izrade softverskog proizvoda, da budu zadovoljeni gornje postavljeni uvjeti.


72

3.7.2 Procjena posla i određivanje broja članova razvojnog tima

Prije nego li se počne sa simulacijskim mjerenjem, moraju se definirati ulazne veličine varijabli modela. Procjena vrijednosti varijabli projektne specifikacije radi se na temelju analize posla kojeg treba obaviti. Tu se koriste znanja sistemskih in�enjera i iskustva preuzeta iz prethodnih projekata, te se na temelju toga određuje okvirna satnica prema dijelovima posla koji se treba izvesti. Na temelju toga dodjeljuju se projektne uloge, s tim da će broj članova izvr�nih timova varirati, kako bi se simulacijom prona�ao optimalni broj dizajnera i testera za procijenjeni posao. U tablici (Tablica 3-3) prikazane su vrijednosti varijabli projektne specifikacije za početno mjerenje. Na temelju tih vrijednosti moguće je započeti seriju simulacijskih mjerenja.

3.7.3 Broj i vrste simulacijskih mjerenja

U tablici (Tablica 3-4) prikazani su rezultati simulacijskih mjerenja. Poduzeto je 100 različitih mjerenja u kojima su se mijenjale vrijednosti ulaznih varijabli izvr�nih timova, tj. broj dizajnera i testera. Zbroju testera i dizajnera dodan je broj ostatka članova razvojnog tima, da bi se dobio ukupan broj ljudi koji rade na razvoju softverskog proizvoda. Nakon zavr�etka svake pojedine simulacije, u slijedećem redu zabilje�en je broj radnih sati, tj. efektivni vremenski interval koji je protekao do zavr�etka razvoja proizvoda. Taj iznos predstavlja efektivno vrijeme potrebno za razvoj, koje kad se pomno�i s brojem članova razvojnog tima, dobiva se cijena u radnim satima koja je potro�ena u razvoju. U ovim mjerenjima nije razmatrana mogućnost preklapanja posla, tj. smatra se da su svi članovi tima zauzeti za rad u drugim projektima, iako u određenim fazama ni�ta ne rade. Drugim riječima, plaćeni su onoliki broj dana koliko projekt traje, bez obzira na radni učinak. Dakako, to nije slučaj u praksi. Dočim određeni član projektnog tima izvr�i svoju zadaću u projektu, linijsko rukovodstvo ga pridjeljuje nekom slijedećem projektu, iako jo� uvijek nije zavr�io prethodni projekt, međutim posao tog člana je zavr�en. Naravno, u simulaciji je moguće doći i do broja korisnih radnih sati koje je utro�io svaki pojedini član tima za svoj rad na projektu.


73

PROJEKTNA SPECIFIKACIJA

Faza: ANALIZA projekt = "veliki" zadatak = "dopuna" hardver = "da" adm = 1 ins = 2 prs = 1 vZ = 40 vSZ = 80 vHR = 40 vSR = 60 vTA = 60 vIS = 90 vIH = 40 vPM = 40 vPR = 40 vPK = 40 vPP = 40 vKP = 40

(veliki / mali) (novo / dopuna - postojećeg softvera) (da / ne) (administracija - vrijeme, pohrana u DB) (inspekcijsko vrijeme po dokumentu i čovjeku) (prosječno trajanje jednog projektnog sastanka) (Zahtjev - vrijeme analize) (SpecZahtj - vrijeme pisanja) (HardRaz - vrijeme pisanja) (SoftRaz - vrijeme pisanja) (TestAn - vrijeme pisanja) (ImpSoft - vrijeme pisanja) (ImpHard - vrijeme pisanja) (PlanMjer - vrijeme pisanja, *VELIKI PROJEKT ) (PlanRizik - vrijeme pisanja, * VELIKI PROJEKT) (PlanK- vrijeme pisanja) (ProjPlan - vrijeme pisanja) (KonfPlan - vrijeme pisanja)

Faza: DIZAJN modDIZAJN = [200,200,300,300,300,500,600] modKOD = [300,300,400,400,400,500,600] insD = 2 vTL = 80 vHI = 40 vPO = 40 vHP = 40 vTP = 140

(broj sati dizajna po modulu + pisanje FunkMod) (broj sati kodiranja po modulu + osnovni test + pisanje OpisMod) (prosjek inspekcije po dokumentu DIZAJN faze) (TestList - pisanje dokumenta slučajeva testiranja) (vrijeme hardver implementacije) (vrijeme pripreme konfiguracije i radne okoline) (HardPlan - vrijeme pisanja) (TestPlan - vrijeme pisanja

Faza: TEST Ftest = 3000 Htest = 1000 Stest = 1400 Fgr = 200 Hgr = 100 Sgr = 450 vUP = 120

(broj planiranih sati za funkcijski test) (broj planiranih sati za hardverski test; hardver="da") (broj planiranih sati za sistemski test; zadatak=dopuna) (broj sati predviđen za ispravku gre�aka u funkcijskom testu) (broj sati predviđen za ispravku gre�aka u hardverskom testu) (broj sati predviđen za ispravku gre�aka u sistemskom testu) (broj sati predviđen za pisanje korisničke dokumentacije)

Faza: ISPORUKA vRK = 40 vIP = 60 zap = 10

(RapK- vrijeme pisanja) (vrijeme pakiranja i stvaranja instalacije) (zavr�na provjera proizvoda i dokumentacije)

TIM (ljudski resursi) Sistem = 1 ProjektMng = 1 Arhitekt = 1 TestMng = 1 HardverIng = 1 MngK= 1 Dizajner = 3 (>=3, varijabilne vrijednosti ovisno o mjerenju) Tester = 2 (>=2, varijabilne vrijednosti ovisno o mjerenju)

Tablica 3-3: Početne vrijednosti varijabli projektne specifikacije za simulacijsko mjerenje


74

3.8 Analiza rezultata simulacijskog mjerenja

Analiza mjerenja rezultata dijeli se na ovisnost vremena utro�enog na razvoj o broju testera i dizajnera, te cijeni projekta koje je rezultat umno�ka broja razvojnog tima i utro�enog vremena.

3.8.1 Analiza utro�enog vremena

Na slici (Slika 3-33) prikazane su vrijeme potrebno za razvoj proizvoda, koje ovisi o broju članova u dizajn i test timu.

1000

1500

2000

2500

3000

3500

4000

4500

5000

3 4 5 6 7 8 9 10 11 12 dizajneri

vrije

me

2 TES3 TES4 TES5 TES6 TES7 TES8 TES9 TES10 TES

Slika 3-33: Funkcije dobivene simulacijskim mjerenjem: vrijeme potrebno za razvoj

proizvoda ovisno o broju dizajnera te brojem testera kao parametar

Kao �to je vidljivo iz slike, samo pojedine krivulje u određenim dijelovima grafa zadovoljavaju vremenski uvjet razvojnog vremena, koje ne smije prijeći vrijednost od 2000 sati. Ta područja zadovoljavaju nu�an uvjet proizvodnje, ali ne i dovoljan. Dovoljan uvjet je taj da utro�ena sredstva ne smiju prema�iti dogovorenu vrijednost od 40000 radnih sati. Sam izgled funkcije u tri dimenzije predstavljen je plohom prikazanom na slici (Slika 3-34), gdje plavo područje označava vrijednosti koje zadovoljavaju nu�an uvjet.


75

1. 2-testera

dizajneri 3 4 5 6 7 8 9 10 11 12 tim 12 13 14 15 16 17 18 19 20 21 vrijeme [h] 4927 4325 4125 4025 3913 3809 3609 3609 3609 3532

cijena [mh] 59124 56225 57750 60375 62608 64753 64962 68571 72180 74172 2. 3-testera


















cijena [mh] 58422 46508 44068 43248 42500 41652 37854 39200 40600 39690

Tablica 3-4: Rezultati simulacijskih mjerenja: minimumi i izabrani optimumi (tamno)


76

16

S10

2000

4000

vrijeme

testeri

dizajneri2000-40000-2000

Slika 3-34: Rezultati vremena prikazani u 3D sustavu: os dizajnera, os testera i vrijeme.

Plava povr�ina plohe zadovoljava vremenski uvjet.

Na grafu je vidljivo kako je funkcija vremena u asimptotskom padu, kako raste broj članova dizajnerskog i testerskog tima. To međutim, nikako ne mora značiti da je i tako s cijenom tro�kova projekta.

3.8.2 Analiza tro�kova projekta

Mjerenja su grupirana u 10 različitih podskupina od 10 mjerenja, �to je definirano brojem članova tima za testiranje kao parametrom grupe. Svaka ta grupa ima svoj minimum tro�kova utro�enih za razvoj pod definiranim okolnostima. Stupac minimuma grupe mjerenja obojan je sivom bojom. Također, postoje vrijednosti koje su otisnute masnim znamenkama i podcrtane, �to označava najmanje moguće vrijeme ili najmanju moguću cijenu ko�tanja dobivenu kao rezultat simulacijskih mjerenja. Crveno označene vrijednosti predstavljaju logički optimum. Kako se mo�e vidjeti na slici (Slika 3-35), grafovi tro�kova su u rastu i imaju svoje minimume. Mo�e se zapaziti da povećanjem broja članova u timu testera, te funkcije imaju sve manji rast.


77

35000

40000

45000

50000

55000

60000

65000

70000

75000

3 4 5 6 7 8 9 10 11 12dizajneri

radn

i sat

i2 TES3 TES4 TES5 TES6 TES7 TES8 TES9 TES10 TES

Slika 3-35: Funkcije tro�kova razvoja dobivene simulacijom: broj testera je parametar

Vrlo mali odsječci pojedinih funkcija zadovoljavaju dovoljni uvjet proizvodnje, tj. uvjet da tro�kovi ne prelaze 40000 radnih sati, �to je lak�e vizualno dočarati trodimenzionalnim grafom prikazanim na slici (Slika 3-36).

1

4

7

10

0

40000

80000

40000-800000-40000

Slika 3-36: Prikaz funkcije tro�kova razvoja proizvoda: Plava područja plohe označavaju

prihvatljivu cijenu razvoja.

Plavo područje plohe sadr�i vrijednosti koje zadovoljavaju dovoljni uvjet, tj. dopu�tene tro�kove proizvodnje, na temelju kojih se mogu izvesti vrijednosti ulaznih varijabli koje


78

predstavljaju broj članova dizajnerskog i testerskog tima. Također, unutar tog plavog područja nalazi se minimum funkcije, koji ujedno predstavlja najmanju moguću cijenu razvoja proizvoda.

3.8.3 Analiza minimuma i optimalno rje�enje

Ako se razmotre minimumi vrijednosti trajanja i cijene u tablici rezultata mjerenja, odmah se uviđaju dvije stvari (Tablica 3-4):

• najkraće razvojno vrijeme nalazi se u 12. mjerenju 10. grupe mjerenja i iznosi 1323 h, sa cijenom ko�tanja 39690 mh i timom od 30 ljudi

• najmanja cijena je u 9. mjerenju 8. grupe rezultata, gdje tim od 25 ljudi za 1511 h razvije proizvod za cijenu od 37775 mh

• čini se da bi optimum mogao biti prikazan u 9. mjerenju 9. grupe: 26 ljudi, 1453 h, 37778 mh

Niti ostale bliske vrijednosti gore navedenima, nisu zanemarive, te mogu biti kori�tene za planiranje od strane projektnog rukovodstva, prema potrebi, tj. ovisno o tome da li je prioritetna cijena, ljudstvo ili vrijeme razvoja. Ako se uzme za slučaj da se tra�i optimalno rje�enje za sva tri parametra, do njega se mo�e doći tra�enjem minimuma produkta vrijednosti. Npr, tra�i se minimum parametra p=LJUDI×VRIJEME×CIJENA, koji se radi lak�eg zapisivanja podijeli s nekim vi�eznamenkastim koeficijentom, **npr. s milijunom. Tako se za ta tri navedena tri slučaja dobivaju vrijednosti (Tablica 3-5):

LJUDI VRIJEME CIJENA PARAMETAR 30 1323 39690 1575,3

25 1511 37775 1426.9

26 1453 37778 1427,18

Tablica 3-5: Tri minimuma koji zahtjevaju nu�an i dovoljan uvjet razvoja proizvoda.

Dakle, optimalni slučaj čine rezultati 9. mjerenja 8. grupe rezultata, �to dokazuje vrijednost potamnjenog parametra iz tablice (Tablica 3-5). Svi ostali slučajevi mjerenja imaju nepovoljniji parametar p, od navedenog.

3.8.4 Procesne značajke optimalnog slučaja

Nakon �to je pronađen optimalni slučaj, dobiven simulacijom razvojnog procesa, moguće je iz daljnje analize Petrijevog modela dobiti podatke o opterećenosti ljudskih resursa, tj. procijeniti koliko će pojedina projektna uloga imati vremenskog udjela u razvoju proizvoda. Tako se iz vremenskih odsječaka zavr�nih oznaka fuzijskog timskog mjesta, dobivaju vrijednosti opterećenja članova tima, �to je prikazano na grafikonu (Slika 3-37)


79

333

281

105

319

103

126

83

691,7

600,4

0 100 200 300 400 500 600 700 800

SAN

PRM

ARH

TSM

HRI

MKV

KNF

DIZ

TES

radni sati

Slika 3-37: Opterećenje članova tima u optimalnom slučaju

Kao �to se vidi, najveće projektno opterećenje imat će operativni timovi, tj. dizajneri i testeri.

0200400600800

1000120014001600

MK1

TO1

MK2

TO2

TO3

MK3

TO4

TO5

Proiz

vod

vrije

me

[h]

Slika 3-38: Dinamika potro�nje vremenskog resursa od točke do točke. Veća strmina

znači vi�e potro�enog vremena na promatranu projektnu fazu.

MK1 TO1 MK2 TO2 TO3 MK3 TO4 TO5 Proizvod

207 313 407 537 746 838 1439 1482 1511

Tablica 3-6: Tablica vremenskih vrijednosti u trenutku prolaska kroz pojedine točke odluke i mjesta kontrole.

U tablici (Slika 3-38 i Tablica 3-6) upisane su vrijednosti vremena pri prolasku kroz pojedina mjesta kontrole i točke odluke za optimalni slučaj. Na temelju vrijednosti vremena, izveden je


80

graf na istoj slici, koji dočarava dinamiku potro�nje vremenskog resursa od točke do točke. �to je veća strmina između dvije točke, to je veća količina vremena potrebna za prijelaz te međufaze. Najveća strmina je između mjesta kontrole MK3 i točke odluke TO4, �to znači da za ovaj slučaj projektne specifikacije, procesna faza testiranja tro�i najvi�e vremena.

3.9 Daljnje mogućnosti eksperimentiranja

Ukoliko se radi o vi�e uzastopnih ili paralelnih razvojnih projekata, postoji mogućnost da se ljudski resursi raspodjeljuju prema potrebi u druge projekte za vrijeme du�ih perioda stagnacije pojedinih članova tima. Time se, u konačnici, drastično smanjuje cijena po projektu, upravo zato �to ljudski resurs biva potpuno iskori�ten unutar njegovog 40-satnog radnog tjedna. Ukoliko je to slučaj, tad obja�njena ploha funkcije tro�kova (Slika 3-36) nije potrebna, jer daje netočni rezultat. Tad je za procjenu posla dovoljno zadovoljiti samo nu�an uvjet, tj. vremensku funkciju razvoja proizvoda. Ako se optimalni slučaj, dobiven prethodnim simulacijama, primjeni na dva ili vi�e projekata koji bi se morali paralelno razvijati u istom timu, prosječna vremena razvoja od projekta do projekta bi se uvelike razlikovala od optimalnog slučaja. Međutim, ukupno vrijeme razvoja proizvoda kod svih projekata, ukupno bilo bi manje, nego bi bila suma vremena razvoja uzastopnog razvoja, tj. da se razvoj jednog proizvoda nastavlja nakon drugog ili da svaki projekt ima svoj razvojni tim. Naravno, da bi u�teda u vremenu značila i u�teda u financijama, kao �to je to navedeno u tablici (Tablica 3-7)

#proizvoda Vremena razvoja svakog proizvoda posebno 1. 1511 1969 3215 3873 4091

2. - 2297 3551 4060 4532

3. - - 3880 4315 4659

4. - - - 4643 4914

5. - - - - 5243

#pr×1511 1511 3022 4533 6044 7555

u�teda [%] 0,00 23,99 14,41 23,18 30,60

Tablica 3-7: Paralelni razvoj proizvoda u istom razvojnom timu

Kao �to se vidi iz tablice, već ako isti tim razvija dva proizvoda istovremeno, ukupno vrijeme takvog razvoja je manje, nego li je zbroj dvaju vremena razvoja jednog proizvoda. �to znači da je isplativije oba projekta razvijati paralelno, nego za svaki projekt imati poseban tim ili razvijati jedan proizvod za drugim. Naravno, to vrijedi ako okolnosti ugovorenog posla to dozvoljavaju. U�teda je u svim slučajevima, iznad 20%, �to se mo�e zahvaliti optimalnim kori�tenjem ljudskih resursa na poslovima u oba projekta. Opterećenje zaposlenika se izjednačava, na način da djelatnici koji trenutno nemaju posla na jednom projektu prelaze raditi na drugi projekt, i obrnuto. Međutim, kako se mo�e vidjeti iz grafa na slici (Slika 3-39), kada se razvija vi�e proizvoda istovremeno povećavaju se pojedinačna vremena razvoja proizvoda.


81

0100020003000400050006000

1 2 3 4 5 broj projekata

vrije

me

[h] 1.PROJEKT

2.PROJEKT3.PROJEKT4.PROJEKT5.PROJEKT

Slika 3-39: Vremena razvoja proizvoda, ovisno o broju paralelnih proizvoda koji se

razvijaju

Npr. ako se razvijaju dva ista proizvoda paralelno u dva razvojna tima, simulacija pokazuje da će vrijeme razvoja u oba slučaja biti jednaka, tj. 1511 h. Međutim, razvijaju li se paralelno s istim timom, ukupno vrijeme će biti manje od zbroja pojedinačnog razvoja. U to m slučaju prvi proizvod kasnit će s isporukom za 458 h. Na tu anomaliju, treba paziti u slučaju kad je strogo definirano da prvi proizvod treba biti isporučen nakon 1511 sati. Tada se mora svaki proizvod razvijati unutar posebnog razvojnog tima, �to poskupljuje projekt.

3.10 Primjer iz prakse

Za istu projektnu specifikaciju, bit će predlo�ene 3 različite financijske konstrukcije koje se temelje na broju članova u operativnim timovima (testeri i dizajneri). Ako se uzme za primjer da treba, u �to kraćem vremenu i uz �to manje tro�kova, razviti dva jednaka softverska proizvoda, neki od logičnih izbora projektnog rukovodstva mogli bi biti:

• svakom modulu pridru�iti po jednog dizajnera i testera, dakle 7 dizajnera i 7 testera,

• svakom modulu pridru�iti po jednog dizajnera, a broj testera smanjiti ispod polovice, budući da svi moduli nisu jednake du�ine, stoga dio modula dolazi tek kasnije na testiranje.

To bi moglo biti rezoniranje projektnog rukovodstva, ukoliko ono ne bi imalo informacije o dinamici sustava, dobivene simulacijom procesnog modela.


82

Ako se uzme da se projekti odvijaju jedan za drugim, a cijena brutto radnog sata je 150$, financijski izvje�taj bi tada izgledao (Tablica 3-8):

SLUČAJ: UKUPNO VR. [h] CIJENA [mh] CIJENA [$] RAZLIKA [$]

Optimalni 2297 57425 8.613.750,- -

1 3962 83302 12.495.300,- 3.881.550,-

2 6022 102374 15.356.100,- 6.742.350,-

Tablica 3-8: Tablica stvarnih tro�kova razvoja proizvoda izra�ena u $ (mh = 150 $ )

Kao �to se vidi, optimalni slučaj čije su vrijednosti vremena preuzete iz tablice (Tablica 3-8) imat će cijenu puno manju, nego li je to slučaj u bilo kojem navedenom slučaju. U prvom slučaju vrijeme će biti prema�eno, kao i cijena za 45%, dok će u drugom slučaju to�kovi biti 78,3% veći nego za optimalni slučaj. Ako se usporede timovi u svim slučajevima, vidljivo je da nema nekih radikalnih promjena, sve se de�ava oko nekoliko ljudi vi�e ili manje, �to na dinamiku sustava djeluje gotovo nepredvidivo.

Ovaj primjer samo je jedan mali prikaz, koliko je moguće pogrije�iti u procjeni jednog poslovnog procesa, ako ne poznajemo njegove dinamičke osobine. Stvar se mo�e drastično pogor�ati ukoliko proizvodne jedinice nemaju definirane procese, čime kvaliteta poslovanja, a time i proizvoda, postaje nepredvidiva, s tendencijom ka lo�em.


83

3.11 Zaključak poglavlja modeliranja procesa

Bilo koji poslovni proces mo�e biti simuliran na ovakav način, kako je opisano u prethodnim poglavljima, bez obzira na granu industrije u kojoj se koristi. Vi�e procesa neke slo�ene organizacije mo�e biti opisano i spojeno u jedan kompleksni i cjeloviti simulacijski model, koji mo�e predstavljati cijelu organizaciju i ciklus proizvodnje, uključujući i ljudsko pona�anje u različitim okolnostima [1][2]. Opisani model primjera razvojnog procesa softvera sastoji se od 19 obojenih Petrijevih mre�a hijerarhijski poslo�enih u tri razine. Model ukupno sadr�i 120 mjesta, od kojih 25 čine fuzijska mjesta, a 41 mjesto vr�i ulogu priključaka na supstitucijske prijelaze mre�a vi�e razine. Ukupan broj prijelaza u modelu je 74, među kojima je i 18 supstitucijskih prijelaza. Broj deklariranih boja je 7, među kojima se nalaze 2 slo�ene boje i 2 boje s vremenskim komponentama. Ukupan broj varijabli koje podr�avaju kretanje oznaka je 10. Matematička simulacija poslovnog procesa mo�e uveliko odstupati od realnih rezultata koji bi se pojavili u praksi: vrlo je te�ko predvidjeti ljudsko pona�anje, jer se ono sastoji od brojnih komponenti, fizičke, mentalne i du�evne prirode, koje je nemoguće ili te�ko ukomponirati u simulacijske modele. Svaki pojedinac je individua za sebe, reagira na različite uvjete drugačije, nego li njegov poslovni kolega. Stoga �to vrijedi za jednog zaposlenika, nije nu�no da vrijedi za drugog, pogotovo kad je riječ o mentalno-kreativnoj proizvodnji, kao �to je slučaj u razvoju softvera. Sve te različite individualne volje sačinjavaju jedinstven tim kojemu je zajednička jedino grupna dinamika, koja predstavlja rezultantu tih pojedinačnih stremljenja i aktivnosti. Upravo akcent proučavanja i mjerenja trebala bi biti ta grupna dinamika, koja se mora promatrati i pratiti iz projekta u projekt, po mogućnosti bez fluktuacije ljudskih resursa unutar timova, kako bi timovi nakon nekog vremena postali uigraniji, a time i otkrili svoje kauzalnosti djelovanja i stvaranja. Također, ista grupna dinamika mora biti proučavana i mjerena sa �to vi�e različitih parametara koji moraju �to skladnije i točnije opisati ljudsko pona�anje u određenim uvjetima u kojim djeluju projektni timovi. Trebaju se koristiti sva moguća znanja, kako iz matematike i statistike, tako i iz ostalih područja poput psihologije, medicine, biologije i sl. Na taj način lak�e će se moći dekomponirati i modelirati one najni�e operativne razine simulacijskih modela, kako bi isti poprimili predikcijske karakteristike. Opisivanje i predviđanje grupne dinamike razvojnih timova bit će i u budućim vremenima velik izazov, koji će zahtjevati puno vi�e i jače kompetencije zbog kompleksnosti ljudskog bića i njegovog kreativnog rada. Vrlo je vjerojatno da će timovi stručnjaka s područja osiguranja kvalitete i koordinacije procesa, na početku svakog projekta izvoditi temeljite procjene proizvoda i procesa koji ga moraju stvoriti. Proces će stvarati proizvod, a u stvaranju proizvoda će nastajati proces u rekurzivnom nastojanju da se postigne �to veća kvaliteta i isplativost, kako proizvoda, tako i procesa [19][20][44][45][46][47].


84

4 Osiguravanje kvalitete proizvoda informacijskom analizom podataka mjerenja

4.1 Uvod u informacijsku analizu

Osiguravanje kvalitete proizvoda informacijskom analizom izmjerenih podataka, pripada planiranju kvalitete u fazi razvoja proizvoda, koja se temelji na mjerenju, prikupljanju i analizi rezultata mjerenja kvalitete prethodno razvijenih proizvoda. Drugim riječima, nastoji se pridobiti znanje o kvaliteti proizvoda na temelju prethodnih iskustava proizvodnje. U tu svrhu potrebno je izvoditi zahtjevno praćenje kvalitete putem mjerenja i promatranja rada sustava, na temelju kojih se mogu poduzimati korektivne akcije u budućoj proizvodnji. Velika količina podataka, dobivena mjerenjem i promatranjem sustava, ne mo�e biti procesirana ljudskim umom na takav način, da se brzo i lako dođe do ispravnih logičkih zaključaka nu�nih za odr�avanje i povećanje kvalitete sustava. Promatrati i utjecati na kvalitetu i rizike jednog velikog proizvodnog sustava zahtjeva velike analize i prikupljanja podataka. Iz tih podataka je nemoguće izvesti korektivnu radnju, a kamo li izvesti predikciju pona�anja takvog sustava promjenom parametara u cilju pobolj�anja kvalitete. U ovom poglavlju je opisana metoda analize i predviđanja kvalitete softvera, temeljena na informacijskoj analizi prikupljenih podataka mjerenja, uz pomoć stabla odlučivanja, pod nazivom C5.0 algoritam. Algoritam se temelji na informacijskoj teoriji gdje je kori�tena entropija kao mjera koja određuje koliko je koji podatak informativan za postizanje kvalitete proizvoda. Time se prikupljeni podaci br�e obrađuju te donose odluke, kako bi mogle biti poduzete korektivne radnje u sustavu ili korekcije na proizvodu. Takav pristup omogućuje predikciju kvalitete, prije nego li je otpočeo razvoj softverskog proizvoda, budući je temeljen na analizi podataka mjerenja i pona�anja sustava u prethodnim razvojnim aktivnostima.

4.2 Klasični pristup osiguravanja i mjerenja kvalitete softvera

Proizvodnja softvera zahtijeva stalna mjerenja tijekom svih faza procesa proizvodnje. Nezamislivo je proizvesti kvalitetan softverski proizvod bez testiranja. Svaki softver u svom proizvodnom ciklusu mora proći kroz osnovni test (engl. Basic Test) i funkcijski test (engl. Function Test), a projektna dokumentacija na temelju koje se softver proizvodi, mora proći inspekcije softverskih dokumenata. Inspekcije softverskih dokumenata (engl. Software Document Inspections) nu�ne su kako bi pogre�ke softverskog koda bile otkrivene u �to ranijim fazama, �to bitno smanjuje tro�kove proizvodnje, te testiranja i odr�avanja softvera. Pod pretpostavkom da se inspekcije dokumenata pravilno obavljaju, bilje�e rezultati, te vodi statistika inspekcija i testiranja, moguće je statistički predvidjeti koliko će pogre�aka ostati


85

neotkriveno u softveru koji će biti isporučen. Tako je moguće proračunati i pribli�ni iznos tro�kova odr�avanja tog softvera. Nakon određenog broja projekata u sličnim uvjetima rada, moguće je u svakom nadolazećem projektu, grubo predvidjeti kvalitetu budućeg softvera u određenim proizvodnim okolnostima i dobiti elemente za analizu rizika [35]. Dosada�nja predviđanja kvalitete softvera temeljila su se na statističkim parametrima numeričke prirode poput rezultata inspekcija softverskih dokumenata, gustoće pogre�aka po volumenu koda, količine utro�enih radnih sati, tro�kova razvoja i sl.

4.2.1 Inspekcije dokumenata

Inspekcija softverskih dokumenata je formalna metoda za provjeru dokumenata, čitanjem i analiziranjem. Inspekcijski proces razvijen je u IBM-u, gdje su inspekcije najrigorozniji formalni tip pregleda i osvrta na dokumente. Osnovna svrha inspekcija dokumenata je u�tedjeti i sačuvati vrijeme i novac dostizanjem ispravne kvalitete dokumenta. Oko 60% defekata na proizvodu pronađeni su prije početka kodiranja. Defekti pronađeni u ranim fazama lak�e su i jeftinije ispravljivi, stoga se propu�teni defekti nasljeđuju u slijedećim fazama projekta [5][6][25]. Cijena defekata eksponencijalno raste s obzirom na razvojne faze proizvoda (Slika 4-1).

0

4000

8000

12000

16000

Analiza Dizajn Funk.Test Sistem.Test Instalacija

$

Slika 4-1: Eksponencijalno rastuća ovisnost tro�kova ispravljanja pogre�aka u različitim

fazama razvoja softverskog proizvoda [31]

Svrha inspekcija nije samo tra�enje defekata u ranoj fazi razvoja softvera, već i smanjenje ovisnosti o testiranju, reduciranje odr�avanja softverskog proizvoda nakon isporuke, provjera kvalitete dokumenata, unaprijeđivanje procesa, �irenje tehničkog znanja i edukacija u cilju inspekcijske prakse. Svrha nije tra�enje novih tehničkih alternativa ili tehnička diskusija. U inspekcijama se prikupljaju podaci na temelju kojih mo�e biti predviđeno koliko preostaje prikrivenih pogre�aka unutar kôda, te u kojim granicama bi se mogli kretati tro�kovi odr�avanja isporučenog proizvoda. Bilje�i se: trajanje pripreme (engl. preparation rate), trajanje sastanka i brzina inspekcije (broj stranica/satu inspekcije) koja ovisi o sposobnosti apsorpcije informacija, tipu dokumenta, kompleksnosti inspektirane materije i broju ulaznih dokumenata. Također, bilje�e se i prebrojavaju defekti u dokumentu koji mogu biti veliki


86

(engl. major) i mali defekti (engl. minor). Neotkrivanje velikih defekata uzrokuje implementacijsku gre�ku ili gre�ku funkcionalnosti čija ispravka će ko�tati puno vi�e u kasnijim fazama, dok mali defekt mo�e biti razrije�en kasnije ili čak ne mora, jer ne uzrokuje implementacijsku pogre�ku ili povećava tro�kove projekta poput gramatičkih pogre�aka. Klasifikacija pogre�aka ovisna je o vrsti dokumenta, kojem čitateljstvu je taj dokument namijenjen, tj. da li je dokument projektni, operacijski, unutra�nji ili vanjski dokument. Za praćenje i predviđanje kvalitete softverskog proizvoda, promatraju se količine pronađenih velikih defekata, količina utro�enog vremena i brzina inspektiranja [5][6].

4.2.2 Izvje�taji pogre�aka testiranja i gustoća pogre�aka

Jedna od metoda procjene kvalitete softverskog proizvoda temelji se na praćenju i prebrojavanju pogre�aka (engl. Trouble Reports) u procesima testiranja. Svaki pojedini modul nakon uspje�nog funkcijskog testa ima određeni broj prijavljenih pogre�aka. Iskustvo govori da se u funkcijskom testiranju otkriva 60% pogre�aka, u sistemskom testiranju 30%, a 10% pogre�aka pronalazi se u 6 mjeseci rada softvera nakon isporuke. Stoga se nastoji �to vi�e pogre�aka pronaći u funkcijskom testu, ali s druge strane te�i se da takvih pogre�aka bude �to manje. To se posti�e većim anga�manom u inspektiranju projektne dokumentacije. Mjera koja opisuje kvalitetu svakog pojedinog modula naziva se gustoća pogre�aka (engl. Fault Density-FD). Gustoća pogre�aka je omjer pogre�aka izvje�tavanja nekog testa i volumena kôda izra�enog u tisućama nekomentiranih linija. Određivanje razine kvalitete nekog softverskog proizvoda čini prosječna vrijednost svih gustoća pogre�aka po modulima, i ona je definirana tr�i�tem ili planom kvalitete koji se temelji na analizama i strategiji poslovanja. Uz gustoću pogre�aka, u svrhu praćenja kvalitete, koriste se i mjere preciznosti tro�kova (engl. Cost Planning Precision-CPP), te mjera odstupanja u vremenu razvoja proizvoda (engl. Lead Time Precision-LTP). Mjere CPP i LTP, promatrane su u razdoblju razvoja softverskog proizvoda, tj. od točke odluke TO2 do točke odluke do zavr�etka testiranja. CPP je relativno odstupanje u planiranoj i realiziranoj cijeni izra�enoj kao čovjek-sati u postocima, dok je LTP relativno odstupanje u realiziranim i planiranim danima također izra�eno u postocima. CPP i LTP nisu kori�teni u ovom radu za procjenu i analizu kvalitete softvera, dok je gustoća pogre�aka u funkcijskom testu kori�tena kao glavni kriterij kvalitete u informacijskoj analizi [5][6].

4.3 Nadogradnja klasičnog pristupa osiguranja kvalitete

Opća teorija sustava, nastala na poticaj biologa Ludwiga von Bertalanffyja, proklamira izgradnje modela na području sistemskih znanosti kako bi se umanjila redundantnost i ponavljajuće gre�ke sustava. Napu�ta se analitički pristup i sve vi�e se te�i spoznaji cjeline, tzv. sistemskom pristupu. Analitički pristup mora biti zamijenjen sistemskim mi�ljenjem u kojem je va�na spoznaja cjeline, jer sistemski pristup omogućuje promatranje tehnologije s humanističkog stanovi�ta pri čemu se ne zanemaruje niti jedna komponenta [8]. Obzirom da softver zadire duboko u područje misli i ideje čovjeka, kvaliteta je usko povezana s cijelim nizom psiho-sociolo�kih faktora radne grupe i pojedinca. Ograničavanje na parametre isključivo tehničke prirode, bez da se uzmu u obzir psiho-sociolo�ki, vode tradicionalnom analitičkom pristupu koji nije dovoljan za kvalitetno zaključivanje, a time i za poduzimanje adekvatnih korektivnih akcija [35].


87

U svrhu cjelovite spoznaje sustava i elemenata koji utječu na kvalitetu softvera, napravljena je kongnitivna mapa faktora koji utječu na kvalitetu (Slika 4-2), a nisu dosad uključivani u statističke proračune kvalitete softverskog proizvoda. Kongnitivna mapa je prikaz uzročno-posljedičnih veza među elementima sustava, koje tvore dijagram uzročnih petlji, tj. povratnih sprega. Povratna sprega je zatvoren krug uzroka i posljedica koji dovodi do toga da neki element sustava utječe sam na sebe. Pozitivna povratna sprega označava uzrok koji utječe sam na sebe tako da pojačava promjene u jednom smjeru. Povratnom spregom posti�e se ili stalni porast ili stalno smanjenje tog uzroka. Negativna povratna sprega označava uzrok koji utječe sam na sebe tako da dovodi do promjene smjera vlastitog djelovanja. Na primjer kvalitetnija izobrazba programera zahtjeva financijska ulaganja, dakle financijska sredstva se smanjuju kad se ula�e u kompetencije, �to je prikazano negativnom uzročnom vezom. Veće kompetencije smanjuju vrijeme rje�avanja problema i razvoja softvera. To znači manje opterećenje ljudskih resursa i kraće razvojno vrijeme, te stoga vi�e vremena ostaje za kvalitetniji rad i testiranje proizvoda. Dakle, indirektno veće kompetencije programera indirektno povećavaju kvalitetu proizvoda, �to je direktno vezano sa zadovoljstvom kupca ili tr�i�ta. Time se zatvara uzročna petlja: kvaliteta osigurava nove kupce i zadr�ava stare koji osiguravaju nova financijska sredstva za razvoj proizvoda, ali i za profit. Moguće je takav dijagram kvalitete nadopuniti novim vezama i elementima, do neslućenih razmjera, ali treba imati u vidu da sustavi koji se sastoje od većeg broja povratnih sprega imaju komplicirani razvoj pona�anja sustava u vremenu kojeg čovjek nije u stanju intuitivno predvidjeti.

ZADOVOLJSTVOKUPCA

KVALITETASOFTVERA

LJUDSKIRESURSIOPTEREĆENJE

MOTIVACIJA

VREMENSKIROKOVI

RADNAOKOLINA

PODR�KA

OSOBNIDOHOCI

IZOBRAZBA

PROMJENEZAHTJEVA

F I N

A N

C I

J S

K A

S

R E

D S

T V

A

POZITIVNA UZROČNA VEZA NEGATIVNA UZROČNA VEZA

Slika 4-2: Elementi koji utječu na razinu kvalitete i njihove međusobne ovisnosti


88

U uzročnom dijagramu (Slika 4-2) definirani su određeni faktori koji utječu na razvoj kvalitetnog softvera, a tiču se procesa, pojedinaca, grupe, okoline i financijskih resursa kao baze osiguranja kvalitete. Dijagram pokazuje da su svi elementi direktno ili indirektno povezani s financijskim resursima. Svaki takav sustav te�i optimumu, gdje niti jedan element ne smije postizati svoju krajnost, a određena razina kvalitete mora biti osigurana uz �to manja financijska ulaganja. Iako je prikazan relativno jednostavan dijagram, njegovo pona�anje vrlo je te�ko ili nemoguće opisati simulacijskim tehnikama, zbog te�ke mjerljivosti nenumeričke prirode faktora koji utječu na kvalitetu softvera [32][33].

4.3.1 Nenumerička priroda humanističkih parametara kvalitete softvera

Klasični pristup osiguranja kvalitete softvera nu�no je nadopuniti parametrima poput razine stresa, kompetencije programera, radnog opterećenja, radnih uvjeta i okoline, motivacije i zadovoljstva, učestalih promjena zahtjeva na funkcionalnost, te mnogih drugih parametara koje se mo�e proizvoljno odabrati prema intuiciji ili preuzeti iz dijagrama uzročnih veza. Takvi parametri čak ne moraju imati vidljivu uzročno-posljedičnu vezu s kvalitetom, međutim moguća va�nost i uzročnost biva dokazana tek informacijskom analizom nad ispravno prikupljenim podacima. Ljudsko pona�anje, radne sposobnosti, intelektualni doseg, zadovoljstvo ili motivacija programera u različitim uvjetima rada jednostavnije je opisati riječima, nego brojevima. Podaci ovakve vrste mogu biti stvarani na temelju promatranja, mogu biti preuzeti iz dokumenata upravljanja ljudskim resursima ili lokalnih anketa napravljenih u svrhu osiguravanja kvalitete. Tako se dobivaju nenumerički parametri poput riječi ili čak simbola koji moraju biti ugrađeni u model analize i predikcije kvalitete softvera u fazi razvoja proizvoda. Sistemski pristup počiva na nu�nosti obrade velikog opsega različitih informacija, na temelju kojih se donose odluke o akcijama u sustavu [15][16]. Stoga je problem naći primjeren način predviđanja kvalitete softverskog proizvoda ili metodu koja bi mogla obuhvatiti i parametre nenumeričke prirode, posebno kad je u promatranju prisutan velik broj parametara. U tu svrhu potrebno je koristiti sustave potpore odlučivanju.

Sustavi potpore odlučivanju i informacijska analiza

Sustavi potpore odlučivanju (engl. Decision Support System, DSS) su računalni sustavi koji podupiru procese odlučivanja, tako �to poma�u rukovodstvima organizacija u analizi i identifikaciji informacija potrebnih za dono�enje odluka. Sustavi za potporu odlučivanju najkorisniji su u situacijama u kojima nije očito koje su informacije potrebne za odluku, te koje bi kriterije trebalo upotrijebiti pri odlučivanju. Ozbiljne organizacije razvoja softvera nastoje poduzimati �to opse�nija mjerenja i praćenja kvalitete softvrskog proizvoda i procesa. Pri tom se mogu pojaviti slo�ene baze podataka iz kojih je nemoguće zaključivati s ciljem pobolj�anja kvalitete proizvoda. Klasične statističke metode koje se koriste pri analizi ne daju odgovore na uzroke rasta ili pada kvalitete, niti daju mogućnost predviđanja kvallitete nekog budućeg proizvoda s obzirom na neke početne uvjete. Nova stepenica razvoja kod osiguranja kvalitete softverskog proizvoda te�i kori�tenju informacijske analize. Npr. ako se davimo u podacima, a �edni smo znanja, pri tom nas metode rudarenja podataka mogu dovesti do znanja o njima. Rudarenje podataka (engl. data mining) je jedan od načina koji se koristi kao potpora odlučivanju. Rudarenje podataka obuhvaća metode ispitivanja povezanosti među


89

podacima, klasificiranje podataka u srodne skupine, ispitivanje trendova i sl. Rudarenje podataka mo�e koristiti klasifikaciju objekta u skupove izrazite i neizrazite logike.

Izrazita i neizrazita logika i skupovi

Izrazita logika temelji se na klasifikaciji objekata u izrazite skupove. Izraziti skupovi (engl. crisp sets) imaju čvrsto definirane granice pripadnosti objekta skupu. Objekt opisan atributima i njegovim vrijednostima, mo�e pripadati skupu ili mu ne pripadati, objekt pripada samo jednom od skupova koji definiraju moguće klase nekog tipa. Dakle, kategorije su potpuno odijeljene i nema preklapanja objekta među skupovima ili klasama. Najjednostavniji je slučaj izrazite logike algoritam ID3, koji objekte klasificira u dvije kategorije odnosno skupa. Npr. u slučaju procjene kvalitete softverskog proizvoda, postoje samo dvije vrijednosti: proizvod je kvalitetan ili nekvalitetan. Proizvod kao objekt klasifikacije nastoji se klasificirati prema tim kategorijama, striktno će pripadati samo jednoj. Granice razdvajanja između kvalitetnog i nekvalitetnog proizvoda, definirane su od strane korisnika, koji postavlja kriterije kvalitete, tj. određuje granice skupova ili klasa. Za razliku od izrazite logike, neizrazita logika (engl. fuzzy logic) ima vi�e mogućih vrijednosti istinitosti. Objekt mo�e u različitoj mjeri pripadati u vi�e kategorija istodobno, jer između kategorija postoji postepeni prijelaz, te se one u nekoj mjeri preklapaju. Npr: neki softverski proizvod na granici kvalitete mo�e pripadati kvalitetnim proizvodima sa stupnjem pripadnosti od 9% i istovremeno biti nekvalitetan u stupnju od 86%. Zbog jednostavnosti, za potrebe informacijske analize i osiguravanje kvalitete softverskog proizvoda, u ovom radu je kori�tena izrazita logika izgradnje informacijskog stabla kvalitete softvera, s pomoću algoritama rudarenja podataka, koji su bazirani na Shannon i Weaver-ovoj informacijskoj teoriji računanja informativnosti mjerene entropijom [2][35].

4.3.2 Pristup rudarenju podataka i organizacija znanja izrazitom logikom

Klasični pristup osiguranja kvalitete softvera koristi teoriju vjerojatnosti koja govori o vjerojatnosti pojave nekog fenomena u pripadnosti određenoj populaciji. Na primjer, analizom kvalitete programskih modula dobivena je vjerojatnost kvalitete određenog modula u nekom rasponu kvalitete. Međutim, ako se pro�iri sustav definicije kvalitete i iskoristi se izrazita logika, tada se ne govori o populaciji već o određenom individualnom objektu populacije. Izrazita logika opisuje karakteristike objekta kvalitete. Na primjer, modul je programirao ekspert u dovoljnom vremenskom roku, pa se za modul smatra da zadovoljava zadane kriterije kvalitete. Sve prikupljene informacije dobivene mjerenjem i promatranjem, nu�no je prilagoditi informacijskoj analizi i rudarenju podataka na jedinstven način. Kao prvo, potrebno je definirati kriterij odluke, u ovom slučaju kategorije kvalitete softverskog proizvoda.

Definicija strukture objekta kvalitete i klasa odluke

Kvaliteta softvera u izrazitoj logici imat će dvije kategorije klase ili skupa odluke: kategoriju kvalitete i nekvalitete. Svaki objekt koji je uključen u informacijsku analizu striktno će pripadati jednoj od tih kategorija. Granicu među kategorijama ili definiciju klasa određuje


90

rukovodstvo za osiguravanje kvalitete. Redovita je projektna praksa u kojoj rukovodstvo unaprijed definira razinu kvalitete pojedinih programskih modula, prije nego li je započet njihov razvoj. To je obično izra�eno gustoćom pogre�aka po volumenu efektivnog kôda, iznad koje se programski modul smatra nekvalitetnim. Ako se uzme za primjer kvaliteta softverskog proizvoda, promatraju se 4 parametra: iskustvo programera, njegova motiviranost za posao, opterećenje izra�eno u vremenskim rokovima i kori�tenje inspekcijskih praksi kod pisanja dokumentacije. Ti parametri su atributi kojima opisujemo objekt promatranja kroz definirane klase. Dakle, parametri kvalitete su atributi, a modul je objekt kojemu je pridru�ena jedna od kategorija ili klasa kvalitete. Nadalje svaki atribut mo�e biti numeričke ili nenumeričke prirode. Atribut nenumeričke prirode definiran je određenim skupom vrijednosti, koje su unaprijed definirane, dok se za numeričke atribute ka�e da koriste kontinuirane veličine, tj. brojeve. Kako su sva 4 atributa izra�ena nenumerički, potrebno je definirati njihove vrijednosti, kao opisne veličine koje će se koristiti u klasifikaciji. Svaka veličina, također mora biti definirana kao skup, na primjer koji je kriterij po kojem odlučujemo da li je programer neiskusan, iskusan ili ekspert. Tako se definiraju atributi, uključujući i kategoriju kvalitete s klasama odluke, pa se dobiva tablica transformacije (Tablica 4-1).

ATRIBUT VRIJEDNOSTI Inspekcije da, ne Programer neiskusan, iskusan, ekspert Rokovi dovoljni, kratki Motivacija motiviran, slaba KVALITETA Kvalitetno, Nekvalitetno

Tablica 4-1: Atributi i njihove vrijednosti kori�teni u informacijskoj analizi ID3 algoritmom

Dakle, svaki modul kao objekt sustava kvalitete, bit će opisan s 4 parametra kvalitete ili atributa, kojima će biti pridjeljena klasa kategorije kvalitete, kvalitetno ili nekvalitetno, u odnosu na definiranu granicu kvalitete.

Stvaranje informacijske baze podataka

Nakon definicije klasa odluke, objektnih atributa i njihovih vrijednosti, primjenom tablice atributa i pravila definicije koja pridru�uju vrijednosti atributima, moguće je iz baza podataka mjerenja i nadziranja sustava, načiniti novu bazu podataka, koja će biti pogodna za informacijsku analizu algoritmima izrazite ili neizrazite logike, odnosno rudarenju podataka. U ovom slučaju, za primjer, sačinjena je tablica od 10 objekata, tj. softverskog modula koji su opisani putem vrijednosti 4 atributa i kojima je pridru�ena klasa, tj. kategorija kvalitete, (Tablica 4-2).


91

Modul Inspekcije Programer Rokovi Motivacija KVALITETA

1 da ekspert dovoljni motiviran Kvalitetno 2 da iskusan dovoljni motiviran Kvalitetno 3 ne iskusan dovoljni slaba Nekvalitetno 4 ne iskusan kratki slaba Nekvalitetno 5 da neiskusan dovoljni motiviran Kvalitetno 6 ne neiskusan dovoljni slaba Nekvalitetno 7 ne ekspert kratki motiviran Nekvalitetno 8 da ekspert kratki slaba Kvalitetno 9 da neiskusan kratki motiviran Nekvalitetno

10 da iskusan kratki slaba Kvalitetno Tablica 4-2: Baza učenja ili informacijska baza podataka nastala transformacijom

podataka s pomoću tablice atributa i njihovih vrijednosti.

Ovakva informacijska baza pogodna je za obradu informacijskim algoritmom ID3/C4.5, putem kojeg će se dobiti stablo odlučivanja informacijske analize, koje predstavlja znanje o sustavu kvalitete kojeg se opisivalo.

4.3.3 Informacijska analiza ID3/C4.5 algoritmom

Baza podataka podesna za informacijsku analizu ID3/C4.5 algoritmima naziva se i bazom učenja (engl. training set). Baza učenja prikazana tablicom (Tablica 4-2) predstavlja jedan jednostavni primjer. Stvarni sustav zahtjeva vi�e atributa i njihovih vrijednosti, te �to veću količinu atributima opisanih objekata ili zapisa (engl. records) kako bi dobiveno znanje o sustavu bilo �to točnije izvedeno. U tu svrhu bit će opisan osnovni ID3 algoritam, na kojim se temelje svi ostali algoritmi (npr. C5), te stablo i tumačenje pravila dobivenih iz analize dobivene primjenom algoritma.

ID3 algoritam i stablo odlučivanja

Algoritmi ID3/C4.5 razvio je Quinlan u svrhu stvaranja klasifikacijskih modela iz podataka, zvanih također istabla odlučivanja. Algoritam slu�i za klasifikaciju podataka iz velikih i za�umljenih baza podataka, koristeći Shannonovu i Weaverovu teoriju informacije, te računje informativnosti pomoću entropije. Podaci su organizirani u instance ili objekte, koji se predstavljeni kao fiksni skup atributa s pripadajućim vrijednostima kojima je pridru�ena diskretna kategorija ili klasa. Zadatak algoritma je izgraditi stablo odlučivanja na temelju pitanja i odgovora koje predstavljaju atributi s vrijednostima, te kategorija ili atribut klase odluke. Stablo odluke se sastoji od čvorova, grana i zavr�nih stanja ili listova stabla. Čvorove predstavljaju atributi, grane su njihove vrijednosti, a li�će su kategorije ili klase odluke kojima objekt pripada. Objekt sastavljen od atributa i vrijednosti predstavlja jednu od putanja po stablu od korijenskog atributa do klase odluke. Da bi se stvorila odluka, kreće se od korijena stabla kojeg čini najinformativniji atribut izračunat entropijom. Zatim se granama, koje predstavljaju vrijednosti tog atributa, sti�e do slijedećeg najinformativnijeg atributa, također izračunatog entropijom između preostalih atributa. Postupak se iterativno ponavlja sve dok ne preostanu čvorovi čije grane sadr�e isključivo listove iste kategorije ili klase [1][5][7][9].


92

Entropija i izgradnja stabla odlučivanja algoritmom ID3

Entropiju, kao mjeru nesređenosti ili kolebljivosti, uveo je u komunikacijske sustave Shannon. Entropija je mjera nečistoće ili homogenosti nekog odabranog podskupa unutar nekog skupa. Ako je baza učenja od T zapisa ili objekata podijeljena na temelju izlaznog atributa kategorije u k klasa {C1, C2,... ,Ck}, onda je prosječan iznos informacije potrebne za identifikaciju klase jednak entropiji H(PT), gdje je PT vjerojatnost distribucije nad klasama, izračunata iz baze učenja (Izraz 4-1):

⎟⎟⎠

⎞⎜⎜⎝

⎛=

TC

TC

TC

TP k,...,,)( 21

(4-1) Ako se primjeni ovaj izraz na tablicu u prethodnom poglavlju (tablica primjera), dobiva se vjerojatnost (Izraz 4-2):

5,,10,105,

105

21 ==⎟⎠⎞

⎜⎝⎛= CCTPT (4-2)

U izrazu 4-2, T označava veličinu baze učenja ili skupa iz kojeg izdvajamo podskupove C1 i C2 koji korespondiraju s klasama "Kvalitetno" i "Nekvalitetno". Drugim riječima, baza podataka podjeljena je na dva skupa od po 5 elemenata koji pripadaju istovrsnim klasama ili kategorijama kvalitete. Na temelju toga, moguće je izračunati entropiju nad skupom objekata T izra�enu u bitovima [bit]:

bitppTHn

iii 1

105lg

105

105lg

105)(log)(

12 =⎟

⎠⎞

⎜⎝⎛ +−=−= ∑

=

(4-3)

Kao �to se vidi iz izraza 4-3, dobiven je maksimalni iznos entropije jednak 1. Na isti način mo�e se izračunati entropija svakog pojedinog atributa u svrhu pronala�enja onog s najmanjim iznosom entropije. Iznos se računa prema izrazu 4-4

)(),(1

i

n

i

i THTT

TXH ∑=

= (4-4)

Skup T je podijeljen na podskupove T1,T2,...,Tn na temelju vrijednosti atributa za kojeg se entropija računa, označenog kao X. Dobiveni iznos govori o količini informativnosti koju ima izlazni atribut klasifikacije (KVALITETA) u odnosu na poznavanje vrijednosti atributa X. Naravno, da se između entropija svih atributa, izabire atribut s najmanjom entropijom. Taj atribut predstavlja ishodi�ni čvor ili korijen stabla, čije vrijednosti sačinjavaju grane tog čvora. Cijeli postupak prve iteracije prikazan je slikom (Slika 4-3):


93

( ) ( )

( ) ( )

( ) ( )

( ) ( ) ( ) bitHHH

THTHTHTH

TTT

bitHHTHTHTH

TT

bitHHTHTHTH

TT

bitHHTHTHTH

TTT

neiskusaniskusanekspert

iskusanneiskusanekspert

slabamotiviran

slabamotiviran

kratkidovoljni

kratkidovoljni

neda

neda

95.0,103,

104,

103

)(103)(

104)(

103),(

43,

97.0,105,

105)(

105)(

105),(

5,

97.0,105,

105)(

105)(

105),(

5,

39.0010465.0

106,

104,

106)(

104)(

106),(

4,610:iteracija Prva

32

31

42

42

31

32

Programer

53

52

52

53Motivacija

53

52

52

53Rokovi

44

40

61

65nspekcije

,

I

=++=

=++=

==

=+=+=

=

=+=+=

=

=⋅+⋅=+=+=

===

Slika 4-3: Prva iteracija ID3 algoritma: računanje najinformativnijeg čvora

Shodno računanju entropije atributa u prvoj iteraciji, pronađen je atribut s najmanjom entropijom (INSPEKCIJE). U slijedećoj iteraciji ponavlja se gore opisani postupak za svaku granu koju čvor inspekcije sadr�i. Budući da grana "ne" sadr�i homogeni skup, tj. isključivo objekte s kategorijom "Nekvalitetno", druga iteracija bit će rađena za granu "da". Skup uzoraka baze učenja, tj. objekata neće sadr�avati vi�e 10 elemenata, već 6, budući da se 4 objekti koji pripadaju klasi "Nekvalitetno" grane "ne" uklanjaju iz računanja. Na taj način proračunava se slijedeći najinformativniji čvor od preostalih, a to je atribut PROGRAMER slika (Slika 4-4):

( ) ( )

( ) ( )

( ) ( ) ( ) bitHHH

THTHTHTH

TTT

bitHHTHTHTH

TT

bitHHTHTHTH

TTT

neiskusaniskusanekspert

iskusanneiskusanekspert

slabamotiviran

slabamotiviran

kratkidovoljni

kratkidovoljni

33.0,62,

62,

62

)(62)(

62)(

62),(

2,,

54.0,62,

64)(

62)(

64),(

2,4

46.0,63,

63)(

63)(

63),(

3,6:iteracija Druga

21

21

20

22

20

22

Programer

20

22

41

43Motivacija

31

32

31

32Rokovi

=++=

=++=

=

=+=+=

==

=+=+=

==

Slika 4-4: Druga iteracija ID3 algoritma nad preostalim čvorovima


94

Postupak se ponavlja iteracijski sve dok ne preostanu grane s istorodnim klasama kvalitete. Na taj način dobiva se ID3 stablo odlučivanja, prikazano na slici (Slika 4-5):

PROGRAMER

INSPEKCIJE

ROKOVI

KN

kratki

da

iskusan ekspert

neiskusan

K

ne

dovoljni

NK

(4) (2) (2) (1) (1)

Slika 4-5: Klasifikacijsko stabla, dobiveno ID3 algoritmom.

Mo�e se primijetiti, da stablo odlučivanja ne mora sadr�avati sve atribute kao čvorove, �to ovisi o raspodjeli zapisa ili objekata po klasama odluke. U navedenom slučaju, atribut MOTIVACIJA nije uključen u elemente stabla, budući je ID3 algoritam uspje�no izgradio strukturu odlučivanja na temelju ostala 3 atributa. Zavr�na stanja ili listovi stabla predstavljaju vrijednosti klasifikacijskog atributa KVALITETA {Kvalitetno, Nekvalitetno}, a brojevi podno njih označavaju količinu zapisa ili objekata baze učenja koji odgovaraju toj klasi, tj. putanji od početnog čvora do zavr�nog stanja. Svaka putanja po stablu mo�e se pretvoriti u if-then pravila kojima se mo�e testirati bilo kakav objekt iste strukture atributa.. Na taj način, jednom izgrađeno stablo odlučivanja, predstavlja znanje sustava opisanog objektima, kojim se mogu donositi odluke nad nepoznatim uzorcima, tj. objektima slične strukture. Na primjer Ako INSPEKCIJE = da, & ako PROGRAMER = ekspert, onda KVALITETA = Kvalitetno.

Analiza i pravila stabla odlučivanja

Klasifikacijska pravila (engl. Classification rules) predstavljaju alternativu stablu odlučivanja. Jednom kad je stablo odlučivanja stvoreno, vrlo ga je jednostavno pretvoriti u sustav pravila. Pretvaranje stabla u sustav pravila ima vi�e prednosti, a kao prva je preglednost i čitljivost, budući su pravila puno lak�a za percepciju i shvaćanje, nego li je to samo stablo, naročito kad se radi o velikim i kompliciranim stablima. Tehnika se sastoji u trasiranju svakog mogućeg puta u stablu odlučivanja, gdje se serije testova bilje�e kao preduvjeti, a zavr�ni čvorovi kao zaključci koji daju klasu koja zadovoljava pravilo. Nepotrebni preduvjeti se eliminiraju u svrhu eliminiranja pravila kori�tenjem raznih statističkim metodama; Hi-kvadrat test, Fisherov egzaktni test, Yatesova korekcija kontinuiteta, konstruiranje Tablica kontigencije ili jednostavno, eliminacija preduvjeta koji nemaju efekta ili se pojavljuju samo jednom. Stablo odluke je jednostavno transformirati u sustav pravila, kao i pridodati novo pravilo skupu pravila, ali je gotovo nemoguće iz klasifikacijskih pravila u stablo odluke. O tehnici generiranja pravila ovisi kolika će biti pouzdanost generiranih pravila, stoga je za generiranje pravila iz navedenog primjera, kori�ten C5.0 algoritam. Algoritam je usavr�ena i komercijalna verzija ID3 algoritma, a izveden je iz C4 i C4.5 algoritama koji se temelje na osnovnom ID3


95

algoritmu. Analiza navedenog primjera C5.0 algoritmom, izgrađen je skup od 4 pravila prikazan tablicom tablica (Tablica 4-3):

# KLASIFIKACIJSKA PRAVILA KLASA VJEROJATNOST1. INSPEKCIJE = da

ROKOVI = dovoljni Kvalitetno 81.6 %

2. INSPEKCIJE = da MOTIVACIJA= slaba Kvalitetno 71.5 %

3. INSPEKCIJE = ne Nekvalitetno 80.1 %

4. ROKOVI = kratki MOTIVACIJA= motiviran Nekvalitetno 79.1 %

Tablica 4-3: Klasifikacijska pravila-alternativa stablu odluke, dobivena su primjenom C5.0 algoritma na stvoreno stablo odlučivanja

Na temelju generiranih pravila, puno je lak�e donijeti odluku i upravljati sustavom kojeg se opisuje bazom učenja i analizira algoritmom. Na temelju navedenih pravila, lako je zaključiti:

• ako se �eli razviti kvalitetan softver, svakako se moraju koristiti metode inspekcija dokumenata koje uz dovoljno velike rokove osiguravaju kvalitetu u 81,6% slučajeva,

• čak i uz slaburadnu motivaciju, inspekcije u 71,5% slučajeva osiguravaju kvalitetan proizvod,

• izostanak inspekcija u 80,1% slučajeva daje nekvalitetan proizvod • kratki rokovi isporuke, unatoč motiviranosti za rad, u 79,1 % slučajeva daju

nekvalitetan proizvod. Kratko rečeno, klasifikacijska pravila pru�aju znanje o sustavu, a stablo odlučivanja se koristi u testiranju sustava, gdje nepoznati objekt klasificiramo prema njegovim vrijednostima atributa [7][9][29][30][43].

Nedostaci ID3 algoritma i njegova pro�irenja

Algoritam ID3 mo�e generirati stablo dovoljno kompleksno da točno klasificira sve primjere iz skupa podataka za učenje. Iako je to u odredjenim slučajevima razumna strategija, u većini situacija stvara dodatne pote�koće, zbog �uma u podacima, ili pak nedovoljno velikog uzorka podataka koji bi trebao predstavljati populaciju primjera za odredjeni klasifikacijski problem. Bez obzira o kojem se slučaju radi, ID3 algoritam stvara prekomjernu specijalizaciju modela (engl. over-fitting), �to znači da se pri modeliranju daje prevelika te�ina slučajnim varijacijama vrijednosti podataka. Takvi modeli tipično imaju veliku prediktivnu točnost na skupu primjera za učenje, a značajno ni�u na novim, tj. nepoznatim primjerima podataka, odnosno testnom skupu podataka. Problem je djelomično rje�iv tehnikama zaustavljanja rasta stabla prije nego se postigne savr�ena klasifikacija primjera iz skupa podataka za učenje ili skraćivanjem pojedinih grana stabla. Pri tom se mogu koristiti validacijski skupovi podataka, koji su različiti od onog kori�tenog za generaciju stabla ili statističke metode nad čvorovima � kandidatima za skraćivanje. Slijedeći nedostatak algoritma ID3 je problem atributa s neodređenim vrijednostima (engl. missing values) unutar skupa podataka za učenje. U mnogim praktičnim primjenama postoje atributi kod kojih određeni postotak primjera ima neodređene vrijednosti. Jedna od strategija za rje�avanje ovog problema je kori�tenje najče�će vrijednosti atributa. Slično je i s problemom gdje vrijednost nedostaje, tj. vrijednost nije


96

poznata. Postoji i problem numeričkih vrijednosti: osnovni oblik ID3 algoritma ograničen je atributima koji imaju ograničen skup diskretnih vrijednosti, �to nije slučaj s kontinuiranim veličinama, te se za kontinuirane atribute izvode binarni testovi koji uključuju sve vrijednosti za koje se atribut razlikuje. Svi ovi nedostaci rije�eni su algoritmom C4.5, koji predstavlja pobolj�anu verziju ID3 algoritma. Algoritam je predlo�io Quinlan 1993, gdje algoritam generira klasifikacijsko stablo odlučivanja za skup podataka učenja rekurzivno razdjeljujući podatke testovima koji daju najveći faktor informacijske dobiti. Komercijalni nasljednik C4.5 je C5.0 algoritam koji rje�ava najva�nije nedostatke prethodnika:

• mo�e koristiti atribute s kontinuiranim veličinama, datume, funkcije, itd. • radi sa "za�umljenim" podacima i vrijednostima atributa koje nedostaju ili su

neodređene, • posjeduje algoritme skraćivanja stabala u svrhu dobivanja pouzdanijeg stabla, • procjenjuje iznose pogre�aka kod dono�enja odluka, • izgrađuje pravila s mogućno�ću spajanja vi�e vrijednosti u jednu, • koristi metode validacije i testiranja stabla odlučivanja, • mogućnost kori�tenja vi�e izlaznih klasa ili kategorija, kao i mogućnost fuzzy-evih

skupova itd. Zbog svih tih prednosti i jednostavnijeg rukovanja, algoritam C5.0 je kori�ten u informacijskoj analizi u svrhu iznala�enja metoda za osiguranje i predikciju kvalitete softverskog proizvoda [30][43].

4.3.4 Prednosti i mane informacijske analize stablom odlučivanja

Nemogućnost odabiranja predikcijskih metoda na temelju neuronskih mre�a (koriste isključivo numeričke veličine), jedna od mogućih metoda predikcije kvalitete softvera je metoda informacijskim stablom odlučivanja. Prednosti metode analize i predikcije stablom odlučivanja su:

• sposobnost generiranja razumljivih modela, • relativno mali zahtjevi na računalne resurse (vrijeme i memorija), • sposobnost kori�tenja svih tipova atributa (kategorički, numerički), • stabla odlučivanja jasno odra�avaju va�nost pojedinih atributa za konkretni

klasifikacijski, odnosno predikcijski problem, • laka priprema i manipulacija podacima preuzetim iz poslovnih sustava.

Međutim, postoje i neka ograničenja i mane ovakve metode, stoga kod pripreme podataka i analize sustava treba imati na umu:

• metode stabla odlučivanja su manje prikladne za probleme kod kojih se tra�i predikcija kontinuiranih vrijednosti ciljnog atributa,

• metode stabla odlučivanja sklona su gre�kama u vi�eklasnim problemima s relativno malim brojem primjera za učenje modela, tj. objekata,


97

• u nekim situacijama generiranje stabla odlučivanja mo�e bit računalno zahtjevan problem, kao npr: sortiranje kandidata za testiranje na čvorovima, metode skraćivanja stabla, kod kojih je potrebno generirati velik broj stabala da bi se odabralo najbolje za klasifikaciju primjera određenog problema,

• stabla odlučivanja nisu dobro rje�enje za klasifikacijske probleme kod kojih su regije odredjenih klasa omeđene nelinearnim krivuljama u vi�e-dimenzionalnom atributnom prostoru. Većina metoda stabla odlučivanja testiraju u svojim čvorovima vrijednosti jednog atributa, i time formiraju pravokutne regije u vi�e-dimenzionalnom prostoru.

Lit. [2][7][9][30][32][33][34][35]

4.3.5 Analiza i predikcije kvalitete softvera primjenom algoritma C5.0

Primjer naveden u tablici (Tablica 4-2) samo je uvod u analizu i predikciju upotrebom algoritma C5.0 u svrhu stvaranja stabla odlučivanja i pravila klasificiranja. U stvarnoj predikciji sustava kvalitete razvoja softvera potrebno je koristiti puno vi�e atributa u opisu objekta kvalitete. Slijedeći primjer je kompleksniji, te pokazuje smjer i način analize sustava kvalitete.

M INSPEKCIJE FUNKCIJSKI TEST DIZAJN KV

# Ins.vr.

Br. str.

Br. pog

Brz. ins.

Vol. stari

Vol. imp.

Rad sat

Fn.Tst

FD. stari Programr Rokovi Motivac. FD

1 10 h 8 2 0.8 4605 347 150 2 0.70 iskusan kratki slaba 0,43

2 4 h 7 3 1.75 1562 232 200 2 0.9 iskusan stresno motiviran 1,28

3 18 h 18 9 1 2364 684 500 6 0.1 neiskusan kratki slaba 2,54

4 10 h 51 10 5.1 3289 456 300 3 0.34 ekspert dovoljni motiviran 0,91

5 4 h 14 7 3.5 2589 132 100 3 0.7 neiskusan stresno motiviran 1,16

6 20 h 63 9 3.15 7682 50 100 2 0.9 neiskusan kratki motiviran 0,26

7 30 h 136 11 4.55 10232 246 350 12 1.1 iskusan kratki motiviran 1,17


9 9 h 36 1 4 1587 468 200 4 9.6 iskusan kratki slaba 2,52


11 45 h 289 7 6.42 18018 1234 350 21 1.3 iskusan stresno slaba 1,17

12 6 h 11 2 1.83 1345 250 50 2 0.40 neiskusan kratki motiviran 1,49

13 8 h 48 3 6 806 232 150 4 0.63 neiskusan kratki slaba 4,96

14 6 h 23 4 3.83 6978 890 220 9 0.89 neiskusan stresno slaba 1,29

15 24 h 120 11 5 23652 790 250 22 1.5 ekspert dovoljni motiviran 0,93

16 40 h 201 13 5 12385 2366 300 11 0.95 ekspert stresno slaba 0,89

17 6 h 13 1 2.17 10233 236 200 2 0.12 neiskusan dovoljni slaba 0,20

18 12 h 105 6 8.75 8063 566 120 5 0.2 iskusan kratki slaba 0,62

19 26 h 165 7 6.35 16037 899 250 19 0.89 ekspert kratki slaba 1,18

20 4 h 14 7 3.5 2589 132 100 3 0.7 iskusan stresno slaba 1,16

Tablica 4-4: Tablica učenja nastala na temelju prikupljanja podataka o kvaliteti 20 modula tokom inspekcija softverskih dokumenata, dizajna i testiranja (redni broj modula; inspekcijsko vrijeme, broj stranica, broj velikih pogre�aka, brzina


98

inspektiranja; naslijeđeni volumen koda, impaktirani volumen koda, radni sati, broj pogre�aka u funkcijskom testu, naslijeđena gustoća pogre�aka; iskustvo programera, dovoljnost rokova, motivacija programera; nova gustoća pogre�aka)

Organizacija podataka kvalitete u svrhu stvaranja tablice učenja

Ovaj primjer nastoji koristiti sve moguće podatke koji su dostupni jednom kordinatoru kvalitete u odjelu razvoja softvera. I dalje je kori�tena metoda praćenja kvalitete svakog pojedinog modula, tj. softverskog bloka. Analiza je rađena na 20 objektnih zapisa koji predstavljaju pojedini softverski modul (Tablica 4-4) Svaki modul temelji se na podacima preuzetim iz inspekcija softverskih dokumenata, podacima o samom bloku, te podacima o osobi koja je radila na dizajniranju modula. Podaci inspekcija dokumenata čine kontinuirane veličine i tu pripadaju: ukupno vrijeme potro�eno na inspekcije dokumenata potrebnih za budući dizajn funkcionalnosti modula, ukupni broj stranica dokumenata, broj pogre�aka, te brzina inspektiranja. Radi se o inspekciji dokumenata isključivo vezanih uz izgrađivanj novih funkcionalnosti. Podaci o modulu sastoje se od ključnih značajki svakog modula, također strukturiranih kao kontnuirane veličine: prvobitni volumen kôda prije nadogradnje, volumen ugradbenog kôda, broj utro�enih radnih sati na novu funkcionalnost, broj pogre�aka funkcijskog testa, te nasljeđena gustoća pogre�aka starog modula.

ATRIBUT VRIJEDNOSTI INS_VRIJEME kontinuirane BR_STRANICA kontinuirane INS_DEFEKTI kontinuirane BRZINA_INS kontinuirane VOLUMEN kontinuirane IMPAKTIRANO kontinuirane RADNI_SATI kontinuirane F_TEST kontinuirane FD_STARI kontinuirane PROGRAMER neiskusan, iskusan, ekspert ROKOVI dovoljni, kratki, stresno MOTIVACIJA motiviran, slaba KVALITETA Kvalitetno, Relativno, Nekvalitetno

Tablica 4-5: Popis atributa s mogućim vrijednostima, na temelju kojih je nastala tablica učenja (Tablica 4-4)

Kao i u prethodnom primjeru kori�tene su diskretne, tj. opisne veličine u posljednjoj grupi podataka o stresu, motivaciji i iskustvu programera, dok je na temelju zavr�ne gustoće pogre�aka modula rađena klasifikacija. Za razliku od pro�log primjera, klasifikacija kvalitete u ovom primjeru rađena je s pomoću 3 klasifikacijska skupa: kvalitetnim modulom se smatra modul s manje od 1 pogre�ke po 1000 nekomentiranih linija koda, relativno kvalitetnim se smatraju svi oni moduli čija je gustoća pogre�aka između 1 i 2 pogre�ke po 1000 linija nekomentiranog koda, a nekvalitetnim modulima smatraju se ostali moduli, tj. s gustoćom pogre�ke većom od 2 pogre�ke po 1000 linija nekomentiranog koda. Na temelju tablice (Tablica 4-4) mo�e se izvesti tablica atributa i njihovih veličina (Tablica 4-5). Od ukupno 13


99

atributa, 9 ih koristi kontinuirane veličine, 3 diskretne, dok se klasifikacijski atribut sastoji od 3 klase.

Stablo odlučivanja, klasifikacijska pravila i analiza dobivenog znanja

Nakon analize algoritmom C5.0 dobiveno stablo odlučivanja ne koristi sve atribute, već samo one atribute koji su bitni za dono�enje odluke (Slika 4-6), dok ostali ne igraju veliku ulogu u odlučivanju. Kao �to se vidi, stablo se sastoji od 4 razine, 5 čvorova i 7 zavr�nih skupova odluke. U zagradama zavr�nih skupova naznačena je količina objekata ili zapisa čija putanja vodi do tog klasifikacijskog skupa, tj. lista stabla. Za �to veću točnost stabla odlučivanja potrebno je imati �to vi�e zapisa, tj. različitih modula i podataka koji ih opisuju. U tom slučaju stablo odlučivanja bi izgledalo puno drugačije i vjerovatno bi koristilo puno vi�e atributa iz tablice učenja za čvorove odluke.

Slika 4-6: Klasifikacijsko stablo odlučivanja dobiveno algoritmom C5.0

Na temelju ovog primjera stabla odlučivanja izvedeno je 5 klasifikacijskih pravila navedenih u tablici (Tablica 4-6):

# KLASIFIKACIJSKA PRAVILA KLASA VJEROJATNOST

1. VOLUMEN > 2589 F_TEST <= 6 Kvalitetno 87.5 %

2. BRZINA_INS <= 5.1 PROGRAMER = ekspert Kvalitetno 80 %

3. VOLUMEN <= 2589 F_TEST <= 3 Relativno 83.3 %

4. F_TEST > 6 Relativno 66.7 %

5. VOLUMEN <= 2589 F_TEST > 3 Nekvalitetno 80 %

Tablica 4-6: Klasifikacijska pravila izvedena iz stabla odlučivanja


100

Na temelju prva dva pravila mo�e se zaključiti da kvaliteta softverskog proizvoda u opisanom projektnom timu ovisi o broju pogre�aka pronađenih u funkcijskom testu, koji ne smije za velike module prelaziti broj 6. Inspekcije bi se trebale pa�ljivo pripremati tako da se poku�a osigurati brzina inspekcija manja od 5 stranica po satu, za eksperte. Za ostale programere, potrebno je raditi detaljnije inspekcije s jo� manjom brzinom inspektiranja. Iz stabla je vidljivo da relativno mali moduli mogu biti kvalitetni, jedino ako broj pogre�aka funkcijskog testa ne prelazi broj 3, dok za veće vrijednosti pada kvaliteta. Veliki moduli ovise također o pogre�kama funkcijskog testa, ali i o iskustvu programera, te pa�ljivim softverskim inspekcijama dokumenata nad op�irnom dokumentacijom.

Predikcija kvalitete izvedena na temelju generiranog stabla odlučivanja

Ovako izgrađeno stablo odlučivanja mo�e poslu�iti za predikciju kvalitete softvera već kod samog planiranja dizajna modula. Neka se za primjer uzme modul od 3000 linija nekomentiranog kôda: postavlja se pitanje, kako pristupiti dizajniranju takvog modula, a da on statistički zadovoljava kvalitetu? Kako algoritam C5.0 unutar sebe ima i mogućnost testiranja stabla odlučivanja, unoseći poznate vrijednosti budućeg modula, dobit će se informacija o vjerojatnoj razini kvalitete nakon isporuke modula (Tablica 4-7):

# VOLUMEN FN. TEST PROGRAMER BRZINA INS. VJ. KVALITETE 1 3000 linija ? ekspert 4 str/satu Kvalitetno [68%] 2 3000 linija 7 pogr. ekspert 4 str/satu Kvalitetno [60%]

3 3000 linija ? iskusan ─ Kvalitetno [36%] Relativno [36%]

4 3000 linija ? neiskusan ─ Kvalitetno [36%] Relativno [27%]

5 3000 linija ? ? 5 str/satu Kvalitetno [50%] Relativno [19%]

Tablica 4-7: Primjer predikcije kvalitete softvera gotovim stablom odlučivanja.

U prvom slučaju predikcije vidi se da modul od 3000 linija (softverska dokumentacija je pro�la inspekciju brzine 4 stranice/satu), kojeg programira ekspert, posti�e vjerojatnost od 68%. U slučaju da se pretpostavi količina od 7 pogre�aka pronađenih u funkcijskom testu, vjerojatnost kvalitete će pasti za 8%. U slučaju da se zadatak dizajniranja modula pridjeli programeru s manje iskustva, vjerojatnost kvalitete i dalje će padati. Budući da su nepoznate vrijednosti nekih atributa, niti vjerojatnost kvalitete neće biti pouzdana. Na primjer u slučaju da se ne poznaje iskustvo i kompetencija programera, kao u slučaju 5, uz ne�to formalnije inspekcije od 5 str/satu, vjerojatnost isporuke zadovoljavajuće kvalitete modula bit će 50% s vjerojatno�ću relativne kvalitete od 19%. Na sličan način mo�e se vrlo brzo izvesti predikcija bilo kakvog modula, s poznatim i nepoznatim vrijednostima atributa, �to je jako povoljno za upravljanje rizicima, planiranje resursa u projektu, kao i kvalitete, prije nego li je i otpočela faza dizajna.


101

4.4 Zaključak poglavlja informacijske analize

Dobar sustav sam sebe odr�ava. Da bi se sustav dovelo na takvu organizacijsku razinu, potrebno je znanje o njegovim �ivotnim ciklusima i znanja koja nam omogućuju da takve sustave mjerimo, simuliramo i predviđamo. Praćenje �ivotnih ciklusa softvera i njihovo umjeravanje je nezahvalno, jer ciklusi mogu trajati mjesecima i godinama, često se u pojedinim fazama mijenjati, iskakati iz pravila pona�anja, prilagođavati novim uvjetima, a sve to ote�ava dobivanje prave slike o tim ciklusima. Nadalje za predviđanje je potrebna statistika, �to znači dovoljna količina podataka o ciklusima. Velika količina podataka statistički se relativno lako obradi i mo�e dati dobre pokazatelje sustava, ali ne daje smjernice �to činiti da bi se ne�to promijenilo, jer previ�e je parametara koji se mogu mijenjati i utjecati na kvalitetu.

Zbog jednostavnosti u ovom poglavlju obrađen je jednostavan primjer pripreme podataka i njihove informacijske analize putem C5.0 algoritma, koji pripada metodama klasifikacije u izrazite skupove. S druge strane je moguće koristiti i neizrazitu logiku kod stvaranja dubinskog znanja o podacima. Time bi se moglo dublje ući u analizu kvalitete budućeg proizvoda. Također, skup podataka učenja, odnosno tablica atributa i njihovih vrijednosti trebala bi sadr�avati puno vi�e elemenata, bili to atributi, njihove vrijednosti ili objekti koji tvore zapise tablice o kojima ovisi će pouzdanost generiranog stabla odlučivanja. Tim osiguranja kvalitete mora imati visoke i �iroke kompetencije kako bi �to bolje mogao obuhvatiti uzroke koji utječu na promjenu kvalitete i izgraditi relativno pouzdani model pri dono�enju odluka i predviđanju buduće kvalitete proizvoda [7][9][16][26][27][28][29][30] [32][33][34][35][40][41][43][49].


102

5 Zaključak

U ovom radu obja�njene su dvije metode koje je moguće ugraditi u visoke standarde osiguranja kvalitete, a primijenjene su na primjeru osiguranja kvalitete i razvoja softvera. Prema svojoj prirodi te metode pripadaju 5. razini CMMI modela, budući da posjeduju mogućnosti optimizacije, predviđanja, potpune analize i upravljivosti svakog elementa razvojnog procesa, dajući pri tom kao rezultat znanje o procesu, timovima, proizvodu i dinamici razvoja. Modeliranje razvojnog procesa metodom obojenih Petrijevih mre�a pru�a detaljni uvid i kontrolu u svaki dio i svaki resurs razvojnog procesa, s preduvjetom da je isti detaljno opisan elementima Petrijeve notacije do zadovoljavajuće razine dekompozicije. U ovom primjeru model je opisan na tri razine, strategijskoj, taktičkoj i operativnoj. Strategijsko-projektna razina sadr�i grubu sliku elemenata razvojnog procesa prikazanih kao faze razvoja, te dio za prikupljanje i analizu rezultata simulacije. Taktička razina sadr�i opis podprocesa kori�tenih unutar faza razvoja, mjesta kontrole (miljokaze) i točke odluke. Svaki podproces opisan je na operativnoj razini mre�om koja upravlja projektnim podacima, resursima, dokumentacijom tokovima razvoja. U drugom dijelu obja�njen je pristup prikupljanja podataka iz praćenja kvalitete razvoja softverskog modula, uključujući i podatke o članovima razvojnog tima poput stresa i kompetencija, metodom rudarenja podataka. Akcent prikupljanja podataka je temeljen na slobodi odabira bilo kojeg parametra i njegovih vrijednosti za kojeg se smatra da utječe na kvalitetu razvoja softvera. Informacijska analiza algoritmom C5.0 nad prikupljenim podacima o kvaliteti, pridaje informacijsku vrijednost određenom parametru kvalitete, stvarajući pravila klasifikacije i klasifikacijsko stablo. Stablo omogućuje predviđanje kvalitete softverskog modula prije početka njegovog razvoja, čak ako i nisu poznati svi parametri, tj. atributi kvalitete.

Diktat budućnosti i tehnologije stvarat će sve veće i slo�enije sustave. U tim sustavima ljudski faktor odlučivanja igrat će presudnu ulogu. Slo�enost tih sustava zahtjevat će pomoćna tehnolo�ka sredstva kojima će biti moguće donositi pravovremene aktivnosti s ciljem odr�avanja kvalitete i pobolj�anja sustava. Sustavi neće biti promatrani isključivo na procesno-proizvodni način, već će se u svrhu odr�ivog razvoja, morati prihvatiti sistemski pristup rje�avanja problema, �to znači da će čovjek i njegova priroda imati centralno mjesto. [4]. Dakle, budućnost će zahtijevati da analize proizvodnih sustava obuhvaćaju i psiho-sociolo�ke parametre timova i pojedinca, stvarajući tako sistemski pristup upravljanja, putem simulacije velikih proizvodnih sistema.

Rje�enje informacijske krize i smjernice daljnjeg napretka, kako proizvodnje tako i dru�tva u cjelini, treba tra�iti u odr�ivom razvoju, tj. skrbi pojedinaca, institucija i firmi u odr�ivim rje�enjima koja poku�avaju odr�ati krhku ravnote�u između ekonomije, dru�tva i ekologije [4]. Filozofija profita nije rje�enje budućeg ljudskog napretka. Oni koji prvi shvate cjelovitost znanja i nu�nost sistemskog pristupa, shvatit će da daljnji napredak nauke i dru�tva mo�e ovisiti o pomagalima koji će ljudima davati bolji uvid u statička i dinamička svojstva proizvodnih procesa, ali stavljanjem čovjeka u prvi plan ispred profita kroz odr�ivi razvoj. Stoga, ne treba robovati standardima, već se koncentrirati na poslovnu efikasnost, okoli� i napredak ljudske zajednice. Prihvatiti tendencije odr�ivog razvoja u cilju stvaranja kvalitetnijeg tr�i�ta. Omogućiti protok informacija kroz sve slojeve uprave i poduzeća i iskoristiti to u sistemskom pristupu koji podr�ava takav trend, jer danas se tokovi informacija


103

u tvrtkama svode na feudalno informacijsko okru�enje u kojem menad�eri pojedinih poslovnih jedinica zadr�avaju sve vrijedne informacije za sebe, a s druge strane stvaraju privid slobodnog toka informacija [13]. Time bi moglo doći i do promjene u dru�tveno proizvodnim odnosima tr�i�ta koje bi imalo neke druge smjernice mo�da humanije za čovjeka i njegov um kao osnovno oruđe proizvodnje. Konkurentnost treba tra�iti u promjeni ljudskih vrijednosti, zakona i normi koje će ići u smjeru ljudskog napretka, očuvanja okoli�a i cjelokupnog zadovoljstva, a ne u profitnoj utrci. Postepeno uni�tenje potro�ačkig mentaliteta i trke za profitom, trebalo bi omogućiti razvoj budućnosti koja će osigurati kvalitetniji su�ivot s prirodom kroz kvalitetne i sigurne proizvode koji prate ljudski razvoj na svim razinama.


104

Literatura

[1] G. Topić and D. Jevtić, Process Measuring and Monitoring in Multi-Process Industry Using Petri Nets Technology In Accordance with ISO 9000:2000, Proceedings of the 10th International Conference on Software, Telecommunications and Computer Networks - SoftCOM 2002, pp. 35-39, Split, Venice, Ancona, Dubrovnik, Croatia, 2002.

[2] G. Topić and D. Jevtić, Software Quality Prediction Based on Information Analysis � A Decision Tree Approach, Proceedings of the 11th International Conference on Software, Telecommunications and Computer Networks - SoftCOM 2003, pp. 277-281, Split, Venice, Ancona, Dubrovnik, Croatia, 2003.

[3] V. Srića, Osnove informatike, Ekonomska biblioteka, Zagreb 1985.

[4] Hrvatski poslovni savjet za odr�ivi razvoj � HRPSOR, Poslovni svijet u odr�ivom razvoju: Ususret Svjetskom skupu u Johannesburgu 2002 i nakon toga, World Business Council for Suitable Development, ISBN 953-98964-0-1

[5] Ericsson Quality Institute, Ericsson Quality Auditing, LME-Q 038 19-EN-LZU 110 7112-29 Uen Rev A 1995-04-18.

[6] Tom Gilb and D. Graham, Software Inspections, Addison Wesley Longman Limited, 1993.

[7] UGAI Lectures, Workshop: Building Classification Models: ID3 and C4.5, Providing and Integrating Educational Resources for Faculty Teaching Artificial Intelligence, Temple University in Philadelphia, June 20 - June 25, 1994, http://yoda.cis.temple.edu:8080/UGAIWWW/

[8] V. Srića, Poslovna Informatika, Dru�tvo za razvoj informatičke pismenosti, Zagreb 1992.

[9] Tutorial: Decision Trees: ID3, Monash University, Faculty of Information Technology, CSE5230 Data Mining, Semester 2, 2002.

[10] V. Srića, Budućnost i perspektive informatike, Osnove informatike, Ekonomska biblioteka, Vara�din 1985.

[11] M. Tuđman, Obavijest i znanje, Radovi zavoda za informacijske studije, knjiga 2, Zagreb 1990.

[12] M. Valdevit, 1997 Godina opasnog �ivljenja, List hrvatske po�te i telekomunikacija, HPT s p.o, broj 3/97

[13] M. Valdevit, Kako pre�ivjeti u informacijskom gospodarstvu, List hrvatske po�te i telekomunikacija, HPT s p.o, broj 4/97

[14] 6. �kola kvalitete � Biro Q, 1. tematska skupina, Kvaliteta u svijetu � razvoj, Opatija 29.1-2.2. 2001, (pripremio: Lotar Kozina)

http://yoda.cis.temple.edu:8080/UGAIWWW/


105

[15] G. Topić, Osiguranje i povećanje kvalitete ovladavanjem procesa proizvodnje � nadzor, mjerenje i simulacija procesa tehnologijom Petrijevih mre�a, 5. hrvatska konferencija o kvaliteti, �ibenik, 2004

[16] G. Topić, Planiranje osiguravanja kvalitete predikcijom i informacijskom analizom rezultata dobivenih praćenjem kvalitete proizvoda, 5. hrvatska konferencija o kvaliteti, �ibenik, 2004

[17] A. Carić, Istra�ivanje i razvoj u informacijskoj komunikacijskoj tehnologiji, 1. izdanje, Element, Zagreb 2003.

[18] ISO 9000, Odabir i uporaba (bro�ura), Dr�avni zavod za normizaciju i mjeriteljstvo RH 2001 http://www.dznm.hr

[19] University of Aarhus, CPN Tools for Coloured Petri Nets - Help, CPN Group, Denmark, http://wiki.daimi.au.dk:8000/cpntools-help

[20] University of Aarhus, CP Net Fundamentals � Design/CPN Tutorial for the Macintosh, CPN Group, Denmark, http://wiki.daimi.au.dk:8000/cpntools-help

[21] Quality management systems, Requirements, International Standard ISO 9001, Third edition, 2000-12-12.

[22] Quality management systems, Guidelines for performance improvements, International Standard ISO 9004, Second edition, 2000-12-15.

[23] I. Lovrek, Modeli telekomunikacijskih procesa: teorija i primjena Petrijevih mre�a, Zagreb, �kolska knjiga 1997, ISBN 953-0-30621-0

[24] J. L. Peterson: Petri net theory and the modeling of systems, Prentice-Hall, 1981.

[25] Measurement: 3-day training, Q-Labs Presentation Template: Managing Software Risks with World -Class Customers, Conducted by Erik Johansson, Johan Brantestam.

[26] Lucas Ballard, �Topics in Machine Learning � Decision Tree Learning�, Web Project September 18, 2002, http://www.cs.brandeis.edu/~cs113/classprojects/~lballard/cs113/proj1.html

[27] Osmar R. Zaiane, Principles of Knowledge Discovery in Databases, Chapter 7: �Data Classification�, University of Alberta, 1999.

[28] Joseph P. Bigus, Jennifer Bigus, Constructing Intelligent Agents Using Java, Second edition, Wiley Computer Publishing, John Wiley & Sons, Inc, 2001, chapter 5: �Learning Systems�

[29] S. Sovilj, Otkrivanje znanja u skupovima podataka � seminarski rad, FER, Sveučili�te u Zagrebu, rujan 2003, http://www.zemris.fer.hr/predmeti/kdisc/weka2.pdf

[30] Data mining server (DMS) instituta �Ruđer Bo�ković�, Stabla odlučivanja (tutorial), Zagreb, http://dms.irb.hr

[31] William E.Perry, Effective Methods for Software Testing, Second Edition, Published by John Wiley & Sons, Inc.

[32] V. Čerić, Međunarodni poslijediplomski studij poslovnog upravljanja (MBA), kolegij: Upravljanje proizvodnjom i uslugama, ljetni semestar 2002/2003, seminari:

- Rudarenje podataka - Upravljanje potpunom kvalitetom - Metode odlučivanja

http://www.dznm.hr/

http://wiki.daimi.au.dk:8000/cpntools-help

http://wiki.daimi.au.dk:8000/cpntools-help

http://www.cs.brandeis.edu/~cs113/classprojects/~lballard/cs113/proj1.html

http://www.zemris.fer.hr/predmeti/kdisc/weka2.pdf

http://dms.irb.hr/


106

- Simulacija http://oliver.efzg.hr/~vlceric/mba-upu/mba-upu.html

[33] V. Čerić, Dodiplomski studij ekonomije, kolegij: Modeliranje primjenom računala u poslovnoj ekonomiji, ljetni semestar, 2003/2004, seminari:

- Sistemska dinamika - Vi�ekriterijsko odlučivanje. - Osnove modeliranja - Neizrazita logika http://oliver.efzg.hr/~vlceric/mprpe/mprpe.html

[34] V. Čerić, Poslijediplomski studij "Informatički management", kolegij: Sustavi potpore odlučivanju, zimski semestar, 2004/2005, seminari:

- Potpora odlučivanju - Vi�ekriterijsko odlučivanje - Sistemska dinamika - Neizrazita logika http://oliver.efzg.hr/~vlceric/IM-SPO/IM-SPO.html

[35] G. Topić, Metode planiranja i nadzora proizvodnje softvera i procesa s ciljem povećanja kvalitete, XXVII Međunarodni skup MIPRO, Opatija 2004.

[36] G. Topić, Modeliranje razvojnog procesa softvera i optimizacija resursa upotrebom obojenih Petrijevih mre�a, XXVII Međunarodni skup MIPRO, Opatija 2005.

[37] The Software Engineering Institute (SEI), CMMI web site, Carnegie Mellon University Pittsburgh, http://www.sei.cmu.edu/cmmi/cmmi.html

[38] Ericsson Project Management Institute, A General Model for Project Management in Multiproject Organization, Ericsson Business Consulting AB, 2000, ISBN 91-89438-11-6

[39] S. Maguire, Kako upravljati razvojenim procesom, (engl. Debbuging the Development Process), Znak, 1995.

[40] G. Topić, Diplomski rad br. 1794: Raspoznavanje tonskih signala u telefonskom kanalu neuronskom mre�om s vremenskim ka�njenjem, Sveučili�te u Zagrebu � FER, Zagreb 1999.

[41] S. Smith, Machine Learning, School of Computing Science Middlesex University, 1998, http://www.cs.mdx.ac.uk/staffpages/serengul/The.ID3.algorithm.htm

[42] Ericsson Rational Unified Process (ERUP) - 2003, http://erup.ericsson.se/erup_prod/rup2002sr1_erup71/tour/tour.htm

[43] Rulequest Research, Effective data mining tools, Data Mining Tools See5 and C5.0 � Help, http://www.rulequest.com/see5-info.html

[44] University of Aarhus, CPN Tools for Editing, Simulating, and Analysing Coloured Petri Nets, Department of Computer Science, Denmark

[45] K. Jensen, Resource Allocation, based on exsample Sect. 1.2.of Vol. 1 of the CPN Book, Aarhus University, Denmark

[46] K. Jensen, Coloured Petri Nets: Basis concepts, analysis methods and practical use, vol. 1, ISBN 3-540-60943-1 Springer-Verlag Berlin Heidelberg New York, 1996.

http://oliver.efzg.hr/~vlceric/mba-upu/mba-upu.html

http://oliver.efzg.hr/~vlceric/mprpe/mprpe.html

http://oliver.efzg.hr/~vlceric/IM-SPO/IM-SPO.html

http://www.sei.cmu.edu/cmmi/cmmi.html

http://www.cs.mdx.ac.uk/staffpages/serengul/The.ID3.algorithm.htm

http://erup.ericsson.se/erup_prod/rup2002sr1_erup71/tour/tour.htm

http://www.rulequest.com/see5-info.html


107

[47] University of Aarhus, CPN/Tools: A Post-WIMP Interface for editing and Simulating Coloured Petri Nets, Department of Computer Science, Denmark

[48] Slovenski institut za kakovost in meroslovje (SIQ), Unutarnja prosudba sustava kvalitete ISO 9001:2000, izdanje 1, Zagreb, 2001.

[49] Y. H. Pao, Adaptive Pattern Recognition and Neural Networks, Case Western Reserve University, Addison-Wesley Publising Company, Inc.

[50] J. Lasić-Lazić, Znanje o znanju, Filozofski fakultet, Zavod za informacijske studije odsjeka za informacijske znanosti, Zagreb, 1996.

[51] R. Mario, Projektiranje informacijskih sustava, Informator Zagreb 1991.


108

Kratice:

AXE � automatska telefonska centrala razvijena u Ericsson-u

CMMI � Capability Maturity Model Integration

CPN � Coloured Petri Nets

CPN ML � Coloured Petri Nets Markup Language

CPP � Cost Planning Precision

DSS � Decision Support System

HW � hardware

IEEE � Institute of Electrical and Electronics Engineers

ISO � International Standard for Standardization

LTP � Lead Time Precision

MK � mjesto kontrole (engl.Milestone)

MRPS � Model razvojnog procesa softvera

PROPS � Ericssonov opći model za vođenje projekata

RUP � Rational Unified Process

SEI - Software Engineering Institute

SW � software

TO � točka odluke (engl.Tollgate)

TQM - Total Quality Management


109

Sa�etak

Naslov: "NADZIRANJE KVALITETE TEMELJENO NA ANALIZI I SINTEZI PROCESA RAZVOJA PROGRAMSKE OPREME"

Kompleksnost razvoja kvalitetnog softverskog proizvoda upućuje na potrebu pronala�enja učinkovitih metoda koje iz podataka dobivenih mjerenjem omogućuju nadgledanje procesa razvoja softvera. S obzirom na osiguravanje kvalitete softverskog proizvoda, istra�ivana je potencijalna učinkovitost simulacijskih postupaka i primjene algoritama informacijske analize, u cilju pronala�enja mogućnosti za nadziranje procesa razvoja i predviđanje kvalitete proizvoda prema zadanim zahtjevima. Osiguravanje kvalitete ovladavanjem procesa izvedeno je tehnologijom obojenih Petrijevih mre�a. Proces razvoja softvera u telekomunikacijskoj industriji softvera je modeliran, simuliran i optimiziran s obzirom na resurse. Osiguravanje kvalitete u fazi razvoja softverskog proizvoda temelji se na informacijskoj analizi podataka iz prethodnih projektnih iskustava, izgradnjom stabla odlučivanja algoritmom ID3/C4.5, podobnom za predviđanje kvalitete proizvoda. Te�nja da softverski proizvodi i usluge budu iznad očekivane tr�i�ne razine kvalitete, zadovoljavaju se najvi�i etički standardi i poslovna strategija odr�ivog razvoja.

Ključne riječi

osiguravanje kvalitete softverskog proizvoda, razvojni proces softvera, obojene Petrijeve mre�e, simulacija i optimiziranje poslovnog procesa, rudarenje podataka, stabla odlučivanja, predviđanje kvalitete proizvoda, odr�ivi razvoj


110

Summary

Title: "QUALITY MONITORING BASED ON ANALYSIS AND SYNTHESIS OF SOFTWARE DEVELOPMENT PROCESS"

Complexity of quality and software product development demands investigation for efficient methods that use collected maesuring data usable for monitoring of the software development process. Regarding to quality assurance of software product, potentially efficacy of simulation methods and applying of information analysis algorithm are investigated, for the sake to find the possibilities for process monitoring and quality prediction according to given requirements. Quality assurance by process controlling is presented by technology of Coloured Petri Nets. Software development process in telecomunication industry is modeled, simulated and optimized according to the resources. Quality assurance in the development phase of software product is based on information analysis of collected process data from the past phases, by decision tree building with algorihtm ID3/C4.5, which is usable for product quality prediction. Tendency is that software products and services would be above expected level of market quality, in order to satisfy the highest ethical standards and business strategy of sustainable development.

Keywords

quality assurance of software product, software development process, coloured Petri net, simulation and optimization business process, datamining, decision trees, product quality prediction, sustainable development


111

�ivotopis

Rođen sam 20. lipnja 1971. godine u Zagrebu. Nakon zavr�ene osnovne �kole, pohađam CUO za elektroniku, preciznu mehaniku i optiku �Ruđer Bo�ković�, gdje maturiram 1990. godine s odličnim uspjehom. Nakon odslu�ene JNA, privremeno upisujem Prirodoslovno-matematički fakultet, smjer: Profesor matematike i informatike u Zagrebu (1991 � 1992.). U jesen 1992. godine upisujem Fakultet elektrotehnike i računarstva, gdje 1999. diplomiram na zavodu za telekomunikacije s radom �Prepoznavanje govora i signala u telefonskom kanalu TDNN neuronskom mre�om� pod mentorstvom prof. dr.sc. Ignaca Lovreka. U proljeće 2000. upisujem poslijediplomski studij na istom faklultetu pod mentorstvom prof. dr.sc. Dragana Jevtića. Također, od 1996. pohađam Filozofski fakultet, smjer informacijskih znanosti, gdje sam trenutno apsolvent. Organizator sam veslačke sekcije Filozofskog fakulteta u Zagrebu i sudionik 2, 3. i 4. međufakultetske trke osmeraca (1995 � 1999.) i dugi niz godina volonterski sam radio na projektima za�tite bjeloglavog supa, otok Cres.

Objavljeni radovi:

Process Measuring and Monitoring in Multi-Process Industry Using Petri Nets Technology In Accordance with ISO 9000:2000, SoftCOM 2002, Split, Venice, Ancona, Dubrovnik, Croatia, 2002, Software Quality Prediction Based on Information Analysis � A Decision Tree Approach, SoftCOM 2003, Split, Venice, Ancona, Dubrovnik, Croatia, 2003, Osiguravanje i povećavanje kvalitete ovladavanjem procesa proizvodnje - nadzor, mjerenje i simulacija procesa tehnologijom petrijevih mre�a, 5 hrvatska konferencija o kvaliteti, �ibenik 2004, Planiranje osiguravanja kvalitete u fazi razvoja, predikcijom i informacijskom analizom rezultata dobivenih praćenjem kvalitete proizvoda, 5 hrvatska konferencija o kvaliteti, �ibenik 2004, Metode planiranja i nadzora proizvodnje softvera i procesa s ciljem povećanja kvalitete, MIPRO 2004, Opatija, Croatia

Radno iskustvo: • Hrvatska izvje�tajna novinska agencija, sistem operater, honorarno (1993 � 1994.) • Ericsson Nikola Tesla, Odjel za istra�ivanje i razvoj (1999 - ):

- Software Quality Process Coordinator - SW designer - IS/IT Consultant (Business Support)

• Metroart d.o.o. suosnivač i direktor (2000 � 2004.), honorarno Ostale aktivnosti: • član Hrvatskog dru�tva za kvalitetu, (2004 -) • član Hrvatskog udru�enja za očuvanje prirodnog i kulturno povijesnog nasljeđa Hrvatske

SVANIMIR i eko centra CAPUT INSULAE, projekti za�tite bjeloglavog supa u Belom na Cresu, (1994 � 2001.)

• član CSEAM (Studies Centre of Environmental Education for the Mediterranean Area), pilot projekt Alpe-Adria pod pokroviteljstvom Vijeća Europe (1996 -)

• tajnik BK �Metalac� u Zagrebu (2001 - )

nadziranje kvalitete temeljeno na analizi i sintezi procesa razvoja programske opreme

Documents