primjena spc metode u razvoju softvera - bib.irb.hr · ključne riječi: kontrolna karta, kvaliteta...

5. HRVATSKA KONFERENCIJA O KVALITETI

NADICA HRGAREK, dipl. inf. mr. sc. GORAN VOJKOVIĆ, dipl. iur. InfoDom d.o.o. , Zagreb [email protected], [email protected]

PRIMJENA SPC METODE U RAZVOJU SOFTVERA Ključne riječi: kontrolna karta, kvaliteta softvera, razvoj softvera, SPC, Statistical Process Control, statistička kontrola procesa Sažetak Kako bi se proizveo visokokvalitetni softver, njegova završna verzija, namijenjena korisniku, treba imati što je moguće manje programskih grešaka. Zadatak upravljanja kvalitetom u projektu razvoja softvera je: planirati odgovarajuće aktivnosti kontrole kvalitete, a potom adekvatno izvršiti i kontrolirati te aktivnosti na način da se najveći broj grešaka pronađe u tijeku procesa proizvodnje, odnosno, prije nego što se softverski proizvod isporuči krajnjem korisniku. Kvantitativne metode mjerenja kao što je SPC (Statistical Process Control) metoda mogu se, osim u industriji, primjeniti i na području kontrole kvalitete softvera kao i kontrole procesa razvoja softvera. Cilj rada je prikazati mogućnost primjene SPC metode u razvoju softvera. U ovom radu, opisat ćemo pristup kvantitativnog upravljanja kvalitetom kroz predviđanje grešaka i statističko upravljanje procesom. U radu će se kroz primjer prikazati primjena najvažnijeg alata statističkog upravljanja procesom – kontrolne karte. Kontrolne karte se koriste za određivanje da li je proces pod kontrolom, odnosno, da li je proces u stabilnom stanju ili ne. Društvima koji se bave proizvodnjom softvera uvođenje ove metode u okviru CMM (Capability Maturity Model for Software) modela i ISO 9001 sustava upravljanja kvalitetom može doprinjeti povećanju konkurentnosti u odnosu na ona društva koja ne primjenjuju statističke metode za praćenje procesa.

1. UVOD Posljednjih godina raste broj informatičkih društava koje se bave razvojem softvera i usredotočuju se na primjenu koncepta statističke kontrole procesa u procesu razvoja softvera, obično kao program poboljšavanja procesa razvoja koji se temelji na CMM1-modelu za softver. Posebna pozornost posvećuje se razini 4 (upravljana razina) CMM-modela kod koje se naglasak stavlja na mjerenje procesa razvoja softvera, kvalitetu proizvoda i analizu odstupanja. Mjerenje produktivnosti i kvalitete odvija se u svim fazama procesa razvoja softvera i u svim projektima. Analiza rezultata je osnova za ocjenjivanje kvalitete procesa i proizvoda. Upravljana razina pretpostavlja primjenu metoda statističke kontrole i analize razvojnog procesa. Pokazalo se da se SPC metoda može primijeniti u procesu razvoja softvera kao alat koji unaprijeđuje taj proces i osigurava povećanje kvalitete softvera. Od statističkih metoda kontroliranja procesa najčešće se koriste kontrolne karte. 1 CMM-model namjenjen je ocjeni sposobnosti proizvođača softvera za narudžbe koje nisu vojnog karaktera. CMM-metodom određuje se zrelost cjelokupne softverske tvrtke i nije moguće odrediti zrelost nekog konkretnog softverskog projekta. U CMM-modelu razlikujemo 5 razina zrelosti procesa razvoja softvera: (1) inicijalna (engl. initial), (2) ponavljajuća (engl. repeatable), (3) definirana (engl. defined), (4) upravljana (engl. managed) i (5) optimirajuća (engl. optimizing).

mailto:[email protected]

mailto:[email protected]


Autori Carleton i Florac [1], [2] spominju primjenu SPC metode i kontrolnih karti u kontekstu poboljšanja procesa razvoja softvera kroz mjerenje i analizu tog razvojnog procesa. Paulk [6] govori o primjeni SPC metode u PSP2 (Personal Software Process) modelu, koji predstavlja jednu verziju CMM modela sa svrhom poboljšanja kvalitete softvera. Jacob i Pillai [5] prikazuju primjenu SPC metode za poboljšanje kodiranja i pregled koda. Kvaliteta procesa u kojem nastaje kvaliteta proizvoda ovisi o usklađenosti ili odstupanjima u aktivnostima koji čine proces i o vremenu koje je potrebno za odvijanje procesa. Faktori koji utječu na kvalitetu procesa razvoja softvera su: ljudski potencijali; praćenje, analiza i kontinuirano unaprjeđivanje procesa; otkrivanje nesukladnosti, odstupanja (varijacija) i problema u što ranijoj fazi procesa i rješavanje problema na mjestu nastanka. SPC je snažan alat za postizanje, praćenje (kontrolu) i unaprjeđivanje kvalitete proizvoda i procesa sa ciljem otkrivanja grešaka (odstupanja) i otklanjanja njihovih uzroka. 2. STATISTICAL PROCESS CONTROL (SPC) METODA Postavlja se pitanje što je statistička kontrola procesa (engl. Statistical Process Control; njem. statistische Prozesskontrolle, statistische Prozessregelung)? Možemo reći da statistička kontrola procesa podrazumijeva korištenje Ishikawa-inih sedam osnovnih alata za kontrolu kvalitete:

1. dijagrami tijeka (engl. flow charts; njem. Flussdiagramme, Ablaufdiagramme), 2. dijagrami rasipanja (engl. scatter diagrams; njem. Streungsdiagramme, xy-Diagramme,

Korrelationsdiagramme), 3. histogrami (engl. histograms; njem. Histogramme), 4. Pareto (ABC) analiza (engl. Pareto analysis; njem. Pareto Analyse), 5. dijagrami uzroka i posljedica («riblja kost» dijagrami, Ishikawa dijagrami), (engl. cause-

and-effect (fishbone) diagrams, Ishikawa charts; njem. Ursachen-Wirkungs-Diagramme, Fischgrätendiagramme, Ishikawa-Diagramme),

6. poligoni frekvencija (engl. run (trend) charts; njem. Werteverlauf), 7. kontrolne karte (engl. control charts; njem. Regelkarten, Qualitätsregelkarten,

Kontrollkarten) [6] Alati za kontrolu kvalitete služe za praćenje i postizanje stabilnosti procesa te osiguranje kvalitete (programskog) proizvoda. Dijagram tijeka prikazuje redoslijed odvijanja aktivnosti u procesu. «Dijagram tijeka (eng. «Flowchart diagram») je grafički prikaz koji na pregledan način prikazuje odvijanje svih faza postupka pomoću unificiranih simbola.» [4] Dijagram rasipanja ili raspršenja (korelacije) grafički prikazuje odnose između pripadajućih varijabli (promjenom nezavisne varijable x mijenja se zavisna varijabla y). Histogram grafički prikazuje raspored učestalosti pojave nekog parametra određenog procesa, te širinu rasipanja i težište raspodjele (položaj i oblik). 2 PSP kao model osobnog softverskog procesa razvio je Watts S. Humphrey <http://www.sei.cmu.edu/tsp/watts-bio.html> (14.04.2004.) sa ciljem da pomogne prvenstveno malim softverskim tvrtkama i projektnim timovima. Premise koje leže u temelju PSP-modela su: povećana osobna disciplina sudjelovanja u procesu pomaže u povećanju učinkovitosti pojedinog softverskog inženjera i sa poboljšanjem rada pojedinca postoji velika vjerojatnost poboljšanja rada tima i projekta.

http://www.sei.cmu.edu/tsp/watts


Pareto dijagram (ABC analiza, dijagram značajnosti) počiva na Paretovoj hipotezi koja glasi «manjina čini većinu». Vrlo često mali broj uzroka proizvodi najveći dio učinka. Dijagam uzroka i posljedica (Ishikawa dijagram ili dijagram «riblja kost») se koristi za pronalaženje uzroka problema. Svaki potencijalni problem se upisuje u dijagram u odnosu na glavne kontrolne točke u procesu razvoja softvera (definiranje zahtjeva, analiza i dizajn, kodiranje testiranje, implementacija i ljudski potencijali). Dijagram uzroka i posljedica uveo je japanski znanstvenik i guru kvalitete Kaoru Ishikawa3 (1915.-1989.) početkom 50-ih godina u japansku industriju čelika. Iako se uz SPC povezuju mnoge druge tehnike, SPC uvijek podrazumijeva korištenje kontrolnih karti. Kontrolna karta je poligon frekvencija kojemu su dodane kontrolne granice koje ukazuju na normalno ponašanje procesa. Statistička kontrola procesa je skup metoda i postupaka za prikupljanje, obradu, analizu, tumačenje i prikaz podataka s ciljem osiguravanja kvalitete proizvoda i procesa. Svrha statističke kontrole procesa je: utvrditi sposobnost procesa za proizvodnju proizvoda koji zadovoljavaju korisničke zahtjeve, pratiti proces kako bi se otkrile varijacije zbog kojih je proces izvan kontrole i kako bi se poduzele korektivne mjere za korekciju procesa i njegovo održavanje pod kontrolom. Kontrolirani procesi su stabilni procesi, a stabilni procesi omogućuju predviđanje rezultata. Na slici 1 prikazane su četiri ključne odgovornosti upravljanja procesom razvoja softvera (engl. Software Process Management Responsibilities). Na početku se proces mora definirati, nakon definicije slijedi izvršavanje procesa koje ne predstavlja ključnu odgovornost, proces se mjeri pomoću definiranih parametara, kontrolira i slijedi njegovo ponovno izvršavanje. Rezultati mjerenja služe kao osnova za poboljšanje procesa nakon čega slijedi ponovno definiranje procesa. Ovaj model izrađen je analogno prema Demingovom PDCA krugu upravljanja kvalitetom.

Poboljšanjeprocesa

Mjerenjeprocesa

Definiranje procesa

Kontrolaprocesa

Izvršavanjeprocesa

Slika 1. Četiri ključne odgovornosti upravljanja procesom razvoja softvera [2] 3. KONTROLNE KARTE Kontrolne karte (engl. control charts; njem. Kontrollkarten) grafički prikazuju promjene, koje bi mogle dovesti do pada kvalitete, na jednoj karti s definiranim graničnim vrijednostima. Kontrolne 3 Prema Kaoru Ishikawa-i osnovni elementi učenja i prakse na području kvalitete su: (1) neposredna primjena statističkih metoda, (2) primjena sedam osnovnih alata u praksi kvalitete, (4) prošireni klasični Demingov PDCA (engl. Plan-Do-Check-Act – planiraj-uradi-provjeri-djeluj) ciklus, (5) teorija i praksa krugova kvalitete, (6) kontrola kvalitete u cijelom društvu i (7) školovanje i trening za kvalitetu.


karte su efikasan alat za praćenje i upravljanje procesima. Prvu statističku kontrolnu kartu izradio je 1924. godine američki fizičar, inženjer i statističar Walter Andrew Shewhart4 (1891.-1967.), koji je poznat i kao otac statističke kontrole procesa. Kontrolne karte poznate su i pod nazivom Levey-Jennings kontrolne karte. Razlikujemo više vrsta kontrolnih karata koje se primjenjuju ovisno o karakteru procesa koji se kontrolira (slika 2). Sve kontrolne karte pripadaju jednoj od dvije osnovne grupe:

1. varijabilne kontrolne karte za mjerljive vrijednosti procesa (iz podataka dobivenih u procesu mjerenjem), računaju se različiti statistički pokazatelji: aritmetička sredina X (engl. arithmetic mean, average; njem. arithmetisches Mittel), standardna devijacija σ (engl. standard deviation; njem. Standardabweichung), varijanca σ2 (engl. variance; njem. Varianz), medijan M (engl. median; njem. Median, Zentralwert), mod ili najčešća vrijednost Mo (engl. mode; njem. Modus), raspon varijacija ili rang R (engl. range; njem. Spannweite)),

2. atributne kontrolne karte za atributivne vrijednosti procesa (prati se broj loših proizvoda i broj grešaka); tablica 1.

KONTROLNE KARTE

Varijabilne kontrolne karte

Atributne kontrolne karte

x-karta p-karta c-kartau-kartas-karta R-karta np-karta

Slika 2. Kontrolne karte Tablica 1. Atributne kontrolne karte

Veličina uzorka Jedinice Greške

n=konstanta

np-karta praćenje broja (komada) neispravnih jedinica

c-karta praćenje broja grešaka u uzorku

n≠konstanta

p-karta praćenje udjela (%) neispravnih (loših) jedinica

u-karta praćenje prosječnog broja grešaka po jedinici (npr. složeni proizvod, samo 1 komad)

Praćenje procesa pomoću kontrolnih karti se temelji na vezi između velikog broja relativno malih uzoraka (n1, ..., nk) i osnovnog skupa (N). Kontrolna karta je dijagram za grafičko prikazivanje vrijednosti dobivenih ispitivanjem niza uzoraka (engl. sample; njem. Stichprobe). Vrijednosti se nakon upisivanja uspoređuju sa kontrolnim 4 Američki znanstvenik Walter A. Shewhart smatra se ocem statističke kontrole procesa i modernog upravljanja procesima. Razvio je teoriju uzorkovanja i PDCA ciklus (krug) kontinuiranog unapređivanja (poboljšavanja) kvalitete koji je danas poznat kao Demingov PDCA krug. Napisao je dvije knjige: 1931. godine objavio je knjigu pod naslovom «Economic Control of Quality of Manufactured Product» (Ekonomična kontrola kvalitete industrijskog proizvoda), a 1939. godine knjigu pod naslovom «Statistical Method from the Viewpoint of Quality Control» (Statistička metoda sa stanovišta kontrole kvalitete).


granicama (engl. control limits; njem. Eingriffsgrenzen) i ako je potrebno, s granicama upozorenja (engl. warning limits; njem. Warngrenzen). Kontrolne granice se izračunavaju uz vjerojatnost od 99%, a granice upozorenja sa vjerojatnošću 95%. Struktura kontrolne karte prikazana je na slici 3. Razlikujemo sljedeće granice i sredinu koja predstavlja očekivanu vrijednost:

• gornja kontrolna granica (engl. UCL – Upper Control Limit; njem. OEG – obere Eingriffsgrenze),

• donja kontrolna granica (engl. LCL – Lower Control Limit; njem. UEG – untere Eingriffsgrenze),

• gornja granica upozorenja (engl. UWL – Upper Warning Limit; njem. OWG – obere Warngrenze),

• donja granica upozorenja (engl. LWL – Lower Warning Limit; njem. UWG – untere Warngrenze),

• sredina – očekivana vrijednost (engl. CL – centerline; njem. M – Mittellinie). Kontrolne granice postavljaju se za tri osnovna slučaja:

(1) praćenje nepoznatog procesa sa ciljem utvrđivanja njegovih prirodnih granica u pogledu oblika (njem. Form), položaja (njem. Lage) i rasipanja (njem. Streuung),

(2) na temelju poznatih prošlih podataka o procesu (veličina i vrijednosti uzorka u vremenu) i (3) na temelju unaprijed zadanih tolerancija (engl. specification limits; njem. Toleranzgrenzen)

koje postavljaju kupci, inženjeri, itd.

Slika 3. Struktura kontrolne karte Kontrolne karte osiguravaju statističku metodu za razlikovanje između varijacija uzrokovanih tipičnim operacijama u procesu i varijacijama uzrokovanih anomalijama u procesu. Na proces mogu utjecati dvije vrste uzroka: slučajni ili vjerojatni (engl. common causes; njem. zufällige Streuungseinflüsse) i značajni (posebni, specijalni) uzroci (engl. assignable (special) causes; njem. systematische Streuungseinflüsse). Slučajni uzroci su svojstveni procesu, stabilni su i predvidljivi; dok su značajni uzroci nestabilni, ne nastaju pod utjecajem slučaja, ne mogu se predvidjeti i mogu opet nastupiti ukoliko se ne provedu korektivne mjere za njihovo otklanjanje. Primjenom statističkih kontrolnih karata proces se može dovesti pod kontrolu i održavati u tom stanju. Proces je pod kontrolom (stabilan) kada vrijede sljedeći uvjeti: od 25 uzoraka u slijedu svi su unutar kontrolnih granica, od 35 uzoraka najviše je 1 izvan granica, te od 100 uzoraka najviše su 2 izvan kontrolnih granica.

sredina – očekivana vrijednost

gornja kontrolna granica

donja kontrolna granica

Uzorak / vrijeme →

donja granica upozorenja

gornja granica upozorenja


4. PRIMJENA SPC METODE U PROCESU RAZVOJA SOFTVERA Weller [7] govori o primjeni kvantitativnih metoda, kao što je SPC, na projektima razvoja softvera i to u području testiranja softvera. Florac, Carleton i Barnard [3] u članku opisuju uspješnu praktičnu primjenu metoda statističke kontrole procesa u projektu pod nazivom «The Space Shuttle Onboard Software» za analiziranje i razumijevanje ponašanje procesa razvoja softvera. Veličine i parametri koji se mogu pratiti i mjeriti u procesu razvoja softvera mogu biti:

• veličina programa u broju linija koda (LOC – Lines of Code, KLOC – thousand Lines of Code),

• veličina isporučenog softverskog proizvoda u broju linija izvornog koda bez komentara i praznih linija (SLOC – Source Lines of Code),

• broj modificiranih linija koda, • broj novih linija koda, • vrijeme razvoja softvera u minutama, satima, danima, tjednima, itd., • vrijeme testiranja, • broj neriješenih problema, • udio neotkrivenih pogrešaka, • vrijeme otklanjanja programskih grešaka, • broj zahtjeva za promjenom aplikacije, • broj promjena aplikacije u različitim fazama razvoja softvera, • broj softverskih inženjera koji rade na projektu, • broj testera koji obavljaju testiranje softvera, • broj modula, • broj programskih grešaka (engl. bug; njem. Softwarefehler), broj programskih grešaka

po modulu, • broj godina iskustva razvojnog tima, • broj otkrivenih grešaka u toku prve godine rada softverskog proizvoda klasificiranih po

tipu greške, • broj otklonjenih programskih grešaka za vrijeme testiranja i kompiliranja/KLOC • broj programskih grešaka otkrivenih u različitim vrstama testova (unit test, integracijski

test, testiranje sustava, test prihvatljivosti kod korisnika i sl.). Uz navedene parametre u procesu razvoja softvera Florac i Carleton navode još i mnogo drugih varijabli i atributa koji se mogu mjeriti [2]. Razvoj softvera se bitno razlikuje od bilo kojeg drugog proizvodnog procesa. SPC-metoda je svoju prvu primjenu našla u industriji i proizvodnji. U posljednjih desetak godina, ona svoju primjenu također nalazi i u procesu razvoja softvera za poboljšanje tog procesa. Ukoliko primjenimo SPC-metodu u procesu razvoja softvera na odgovarajući način, ona može ukazati na potencijalne probleme u procesu i povećati kvalitetu softvera. Na slici 4 prikazana je primjena kontrolne karte za prikaz broja prijavljenih, ali neriješenih problema u prvih 30 tjedana sistemskog testiranja (Izvor: [1]). Na apscisi su prikazani tjedni sistemskog testiranja, a na ordinati pojedinačne vrijednosti (broj neriješenih prijavljenih problema i rang). Karta prikazuje da je proces pod kontrolom i da je stabilan. Srednja vrijednost neriješenih prijavljenih problema iznosi oko 20 (CL = 20,04). Gornja kontrolna granica neriješenih problema iznosi oko 32 (UCL = 31,6), a donja kontrolna granica oko 8 (LCL = 8,49). Ukoliko bi u budućnosti


broj neriješenih problema bio iznad kontrolnih granica proces bi postao nestabilan i trebalo bi potražiti uzrok nastanka njegove nestabilnosti (npr. nedovoljno iskustvo softverskih inženjera, nedostatan broj programera/testera koji rade na projektu, testiranje softvera u kasnoj fazi razvoja softvera, itd.).

Slika 4. Kontrolna karta za backlog neriješenih problema

U tablici 2 zbirno su prikazani različiti tipovi i broj pogrešaka (npr. pogreška u funkciji, sučelju, algoritmu, dokumentu, itd.) po svakoj komponenti. Ukupno je ispitana 21 komponenta, a broj otkrivenih pogrešaka iznosio je 471 (Izvor: [2]). Tablica 2. Različiti tipovi i brojevi pogrešaka otkriveni za vrijeme ispitivanja komponenata Na temelju dobivenih podataka iz tablice 2 izrađena je XmR kontrolna karta prikazana na slici 5 (Izvor: [2]).

Component 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Totals

Defects 12 16 18 32 22 16 23 35 15 27 16 25 20 26 20 23 23 36 22 27 17 471

Defect Type Number of Defects per Type per Com ponent

Function 3 5 4 4 4 3 3 20 4 11 2 3 3 5 3 7 4 5 5 15 2 115

Interface 2 2 4 4 3 4 2 3 3 4 2 3 5 3 3 3 2 16 6 2 4 80

Tim ing 1 1 0 1 1 0 2 1 0 0 2 0 1 1 1 1 1 0 1 0 0 15

Algor ithm 0 0 1 14 2 0 0 0 0 0 0 1 5 2 7 6 5 1 2 0 1 47

Checking 1 1 5 1 7 1 1 2 0 1 6 3 1 12 1 0 2 4 3 5 2 59

Assignment 0 2 0 4 1 2 1 3 2 3 2 8 1 0 2 1 2 1 0 1 1 37

Build/Pkg. 3 1 1 2 1 0 0 4 3 6 1 0 2 1 1 1 3 2 2 2 1 37

Docum ent 2 4 3 2 3 6 14 2 3 2 1 7 2 2 2 4 4 7 3 2 6 81


Defects 12 16 18 32 22 16 23 35 15 27 16 25 20 26 20 23 23 36 22 27 17 471


Function 3 5 4 4 4 3 3 20 4 11 2 3 3 5 3 7 4 5 5 15 2 115

Interface 2 2 4 4 3 4 2 3 3 4 2 3 5 3 3 3 2 16 6 2 4 80

Tim ing 1 1 0 1 1 0 2 1 0 0 2 0 1 1 1 1 1 0 1 0 0 15

Algor ithm 0 0 1 14 2 0 0 0 0 0 0 1 5 2 7 6 5 1 2 0 1 47

Checking 1 1 5 1 7 1 1 2 0 1 6 3 1 12 1 0 2 4 3 5 2 59

Assignment 0 2 0 4 1 2 1 3 2 3 2 8 1 0 2 1 2 1 0 1 1 37

Build/Pkg. 3 1 1 2 1 0 0 4 3 6 1 0 2


Defects 12 16 18 32 22 16 23 35 15 27 16 25 20 26 20 23 23 36 22 27 17 471


Function 3 5 4 4 4 3 3 20 4 11 2 3 3 5 3 7 4 5 5 15 2 115

Interface 2 2 4 4 3 4 2 3 3 4 2 3 5 3 3 3 2 16 6 2 4 80

Tim ing 1 1 0 1 1 0 2 1 0 0 2 0 1 1 1 1 1 0 1 0 0 15

Algor ithm 0 0 1 14 2 0 0 0 0 0 0 1 5 2 7 6 5 1 2 0 1 47

Checking 1 1 5 1 7 1 1 2 0 1 6 3 1 12 1 0 2 4 3 5 2 59

Assignment 0 2 0 4 1 2 1 3 2 3 2 8 1 0 2 1 2 1 0 1 1 37

Build/Pkg. 3 1 1 2 1 0 0 4 3 6 1 0 2 1 1 1 3 2 2 2 1 37

Docum ent 2 4 3 2 3 6 14 2 3 2 1 7 2 2 2 4 4 7 3 2 6 81


Slika 5. XmR kontrolna karta za ukupni broj pogrešaka otkrivenih tokom inspekcije komponenata 5. ZAKLJUČAK Zbog jake konkurencije na tržištu, informatička društva koja se bave razvojem softvera moraju kontinuirano pratiti i poboljšavati svoje procese, proizvode i usluge, da bi mogle opravdati zadovoljstvo postojećih i budućih korisnika svojih proizvoda i usluga. Statistička kontrola procesa uključuje korištenje statističkih tehnika za mjerenje i analizu varijacija (odstupanja) u procesu. Svoju primjenu najčešće nalazi u proizvodnim procesima (npr. procesi u automobilskoj i prehrambenoj industriji), međutim, pokazalo se da se koncept statističke kontrole procesa efikasno može primijeniti i u kontroliranju procesa razvoja softvera. Kontrolne karte su najvažniji alat statističke kontrole procesa za održavanje procesa pod kontrolom, alat za dovođenje procesa pod kontrolu i alat za utvrđivanje da li je postignuta stabilnost i kontrola procesa. Ukoliko se rezultati mjerenja u kontrolnim kartama nalaze izvan izračunatih kontrolnih granica, potrebno je regulirati proces poduzimanjem odgovarajućih korektivnih (popravnih) radnji. Ako postoji uveden sustav upravljanja kvalitetom, korektivne radnje trebaju se poduzeti u skladu sa propisanim postupkom sustava kvalitete. SPC metoda ima važnu ulogu o poboljšanju procesa razvoja softvera, a time utječe i na poboljšanje kvalitete programskog proizvoda. Rezultati mjerenja procesa razvoja softvera mogu se prikazati pomoću kontrolnih karata i služiti kao podloga za odlučivanje na razini projekta, pa čak i cijelog informatičkog društva koje se bavi proizvodnjom softvera. Samo takav proces razvoja softvera, koji je stabilan i pod kontrolom, daje kvalitetan programski proizvod. LITERATURA: [1] Carleton, A. (2001): Statistical Process Control for Software, Software Engineering Institute

<http://www.sei.cmu.edu/str/descriptions/spc.html> (08.04.2004.) [2] Florac, W. A.; Carleton, A. D. (1999): Measuring the Software Process: Statistical Process Control for Software

Process Improvement, Addison-Wesley, Reading, Massachusetts [3] Florac, W. A.; Carleton, A. D.; Barnard, J. R. (2000): Statistical Process Control: Analyzing a Space Shuttle

Onboard Software Process, IEEE Software, Vol. 17, No. 4, July/August, str. 97-106 [4] Injac, N. (2002): Mala enciklopedija kvalitete; II dio – Drugo prerađeno izdanje; Informacije; Dokumentacija;

Auditi, Oskar, Zagreb [5] Jacob, A. L.; Pillai, S. K. (2003): Statistical Process Control to Improve Coding and Code Review, IEEE Software,

Vol. 20, No. 3, May/June, str. 50-55 [6] Paulk, M. C. (2000): Applying SPC to the Personal Software Process, Software Engineering Institute, Carnegie

Mellon University, Pittsburgh, USA <http://www.sei.cmu.edu/activities/cmm/high-maturity/spc-psp-icsq.pdf> (08.04.2004.)

[7] Weller, E. F. (2000): Practical Applications of Statistical Process Control, IEEE Software, Vol. 17, No. 3, May/June, str. 48-54

0 5 10 15 20

25

05101520

30354045

LCL = 0

CL = 22.4

UCL = 44.9

Mov

ing

Ran

geTo

tal D

efec

ts

Component Number0 5 10 15 20

0

5

10

15

20

25

30

CL = 8.45

UCL = 27.6

0 5 10 15 20

25

05101520

30354045

LCL = 0

CL = 22.4

UCL = 44.9

Mov

ing

Ran

geTo

tal D

efec

ts


0

5

10

15

20

25

30

CL = 8.45

UCL = 27.6

0 5 10 15 20

25

05101520

30354045

LCL = 0

CL = 22.4

UCL = 44.9

Mov

ing

Ran

geTo

tal D

efec

ts


0

5

10

15

20

25

30

CL = 8.45

UCL = 27.6

0 5 10 15 20

25

05101520

30354045

25

05101520

30354045

05101520

30354045

LCL = 0

CL = 22.4

UCL = 44.9

Mov

ing

Ran

geTo

tal D

efec

ts


0

5

10

15

20

25

30

0

5

10

15

20

25

30

CL = 8.45

UCL = 27.6

http://www.sei.cmu.edu/str/descriptions/spc.html

http://www.sei.cmu.edu/activities/cmm/high-maturity/spc-psp-icsq.pdf

primjena spc metode u razvoju softvera - bib.irb.hr · ključne riječi: kontrolna karta, kvaliteta...

Documents