OSIGURANJE KVALITETE SOFTVERA

Ninoslav Slavek

SADRAJ
_____________________________________________________________________________________________

UVOD DIO I: KVALITETA SOFTVERA 1. SPECIFINOSTI SOFTVERA I KVALITETA 2. METRIKE I MJERENJE KVALITETE SOFTVERA 3. OSIGURANJE KVALITETE SOFTVERA DIO II: NORME I MENEDMENT 4. NORME SOFTVERA 5. PLANIRANJE, ORGANIZIRANJE I KONTROLA PROJEKTA 6. MENEDMENT PROMJENA I KONFIGURACIJE SOFTVERA DIO III: PROCES RAZVOJA SOFTVERA
7. 8. 9.

IVOTNI CIKLUS SOFTVERA MODELIRANJE PROCESA USAVRAVANJE PROCESA

DIO IV: OPTIMIRANJE PROCESA 10. MODEL RAZINE ZRELOSTI PROCESA (CMM) 11. METODA BOOTSTRAP 12. METODA SPICE 13. PRISTUP UNAPREENJU ASESMENTA PROCESA

Uvod
Kriza softvera evidentna je u dva glavna aspekta; krizi upravljanja projektima, i krizi osiguranja kvalitete prema slijedeoj listi prioriteta: organizacija i voenje softverskih projekata metode i tehnike razvoja softvera tehnologija (ukljuivi tehniku infrastrukturu i CASE alate)

PRVI DIO Kvaliteta softvera Specifinosti softvera i kvaliteta

Softver ima neke specifinosti koje uzrokuju probleme. Softver je apstraktni rezultat mentalnog procesa, on je nevidljiv, samo su apstraktni opisi razliitih aspekata softvera kao podaci, funkcije, kontrole, korisnika suelja dostupna u obliku dijagrama ili tekstova. Softver je nematerijalan i samim time teko ga je mjeriti. Teko je nadalje menedirati neim to ne moemo izmjeriti. Nedostatak pouzdanih mjerila proizvoda i procesa oteava planiranje i kontrolu. Kvaliteta isporuenog softvera se ne moe garantirati: proizvodnost nije kvantificirana i zamjetno je niska, dok su trokovi razvoja i procjene isporuke esto nerealne. Iskustvo pokazuje da se zahtjevi na softver esto mijenjaju, vane analize se provode povrno to uzrokuje promjene zahtjeva i specifikacija na softver, ve prema prema nadolazeim potrebama, meutim, softver je lako mijenjati ali je teko mijenjati ga korektno. Kvaliteta softvera posebno je vana tamo gdje se softver koristi za upravljanje i nadzor kritinih sustava, tj. tamo gdje greke softvera ili ispad softvera iz rada moe uzrokovati gubitak ljudskih ivota ili uzrokovati velike materijalne gubitke (vojna industrija, avio- industrija, istraivanje svemira, nuklearne elektrane). Sa stajalita menadmenta tri su osnovna meuovisna parametra koje je potrebno kontrolirati tijekom razvoja softvera: trokove, redoslijed izvoenja radova i kvalitetu. Kako bi proizveli softver sa to niim trokovima, i kako bi bili sposobni menedirati njegov razvoj, razvoj softvera mora biti temeljen na valjanoj inenjerskoj praksi. Problemi povezani sa softverom i stalna kriza softvera posljedica je injenice da nije uvijek jasno kako se provjerena inenjerska praksa moe i treba primjeniti na razvoj softvera. Nova iskustva, i to je vanije, nova saznanja o odreenim inenjerskim procesima, mogu u veliko pridonijeti poboljanju u kvaliteti i proizvodnosti.

to je kvaliteta softvera?
Da bismo odgovorili na pitanje treba odgovoriti to je to kvaliteta, i to je softver.

Prema Websters Unabridged Dictionary, kvaliteta je: bilo koja karakteristika ili karakteristike koje mogu uiniti objekt dobrim ili loim, hvale vrijednim ili vrijednim osude; stupanj vrsnoe to je stvari posjeduju. Sa tradicionalno tehnolokog stajalita, su prikladna neka razmatranja M. J. Jurana: Osnovni temeljni blok na kojem se izgrauje sposobnost za uporabu jest karakteristika kvalitete. Za nae potrebe pojam softver je preuzet iz definicije softvera u knjizi Matthew J. i drugi: raunalski programi, procedure, pravila, pridrueni podaci i dokumentacija u vezi s radom raunalskog programa. Definicija kvalitete softvera je: sposobnost za upotrebu ukupnog softverskog proizvoda.

Razine kvalitete
Razvoj kvalitete softvera koji se moe promatrati sukladno razvoju svakog drugog industrijskog proizvoda prikazan je na slici 1.1. TQM

QA

QC Slika 1.1 Razvoj kvalitete softvera Najnia razina je Kontrola kvalitete QC (engl. Quality Control), karakterizira je odvajanje dobrih od loih proizvoda na ulaznoj, meufaznoj i zavrnoj kontroli. Via razina je Osiguranje kvalitete QA (engl. Quality Assurance), karakterizira je: prijelaz u organizaciji za kvalitetu ukljuivanjem svih funkcija poduzea na osiguranje kvalitete, uvoenje politike kvalitete u organizaciji i primjena meunarodnih normi kao to je to na primjer norma ISO 9000, odnosno ISO 9000-3. Najvia razina je Potpuno upravljanje kvalitetom TQM (engl. Total Quality Management), to znai potpuno ukljuivanje svih funkcija i svih zaposlenih u poduzeu, dobavljaa i kupaca na ostvarivanju visoke kvalitete uz najnie trokove. Naela koncepta TQM Koncept TQM se temelji na nekoliko naela: 1. Nuno je izravno sudjelovanje poslovodstva najvie rukovodstvo poduzea treba svojim djelovanjem dokazati deklarirana stajalita u vezi kvalitete, s obzirom da sve aktivnosti zapoinju s vrha nadolje;

2. Potreban je timski rad jer tim, pokazalo se, nalazi bra i bolja rjeenja od pojedinaca; 3. Nuno je sudjelovanje svih zaposlenih postizanje kvalitete je zadatak svih zaposlenih; 4. Nuno je kolovanje svih zaposlenih, od svih razina rukovodstva do svih zaposlenih; 5. Trai se sudjelovanje kupaca povratna informacija kupca bitna je za poboljanje proizvoda; 6. Nuno je stalno usavravanje kvalitete poznavanje tehnika usavravanja kvalitete omoguavaju provoenje usavravanja; 7. Nuno je stalno odravanje i preispitivanje normi norme stalno treba aurirati kako bi se usuglasile sa stalno viim zahtjevima za kvalitetom. Danas se kvaliteta ne shvaa toliko kao odravanje zadane kvalitete, nego vie kao krug njezina stalnog poboljanja i odravanja.

Uvoenje sustava kvalitete

Sustav kvalitete je mehanizam koji primjenjuje principe upravljanja kvalitetom u organizaciji. Sustav se odnosi na aktivnosti koje imaju utjecaj na kvalitetu krajnjeg proizvoda; ukljuivi organizacijsku strukturu, odgovornosti, procedure, procese i resurse potrebne za implementaciju upravljanja kvalitetom. Koraci na uvoenju sustava - Prvi korak na unapreenju sustava kvalitete u poduzeu je definiranje politike kvalitete, koja na jasan i razumljiv nain postavlja ciljeve poduzea prema kvaliteti i nain ostvarenja ciljeva. - Drugi korak je definiranje sustava kvalitete to se moe postii koritenjem normi kao to je to na pr. ISO 9000. Time se postie da e: sustav biti u skladu s zahtjevima normi, zahtjevi i smjernice e pomoi da sustav kvalitete bude sustavan i sveobuhvatan. - Trei korak je, i glavni zahtjev normi ISO 9000, dokumentiranje sustava kvalitete i osiguranje da se dokumentirane procedure u potpunosti prihvaaju i primjenjuju unutar organizacije.

Dokumentacija sustava kvalitete

Tri su glavna dokumenta koji detaljno definiraju organizaciju i zadae osiguranja kvalitete, to su: Poslovnik kvalitete; Program osiguranja kvalitete; Plan osiguranja kvalitete Poslovnik kvalitete Poslovnik kvalitete je saeti prikaz organizacijskih i funkcijskih postupaka, pravilnika, normi, propisa i uputa za izradu programa i planova, te provjeru sustava kvalitete, sadraj poslovnika prikazan je tablicom 1-1: Tablica 1-1: Poslovnik kvalitete 1. Organizacija 2. Kvaliteta u marketingu i inenjeringu 3. Kvaliteta u razvoju 4. Upravljanje dokumentacijom 5. Kvaliteta u nabavi 6. Kvaliteta u proizvodnji 7. Kvaliteta u rukavanju i otpremi 8. Kvaliteta odravanja 9. Kontrola i kalibracija mjerne i test opreme

10. Neusklaenosti i korektivne akcije 11. Dokumentacija kvalitete i statistike metode 12. Trokovi kvalitete 13. kolovanje i motivacija za kvalitetom 14. Audit sustava kvalitete Program osiguranja kvalitete Program osiguranja kvalitete je dokumentirani niz postupaka i aktivnosti primjenjenih za osiguranje kvalitete u poduzeu. On se izrauje za asortimanski zaokruene proizvode koji imaju sline zahtjeve za osiguranje kvalitete. Program moe biti sveukupni za cijelo poduzee, ili pojedinani za pojedini ugovor ili projekt. Zajedniki program poduzea se realizira kroz specifine programe pojedinih odjela/biroa/radnih jedinica. Plan osiguranja kvalitete Plan osiguranja kvalitete je dokument izveden iz programa osiguranja kvalitete u kome su navedeni postupci, sredstva i aktivnosti u vezi kvalitete koji se odnose na pojedinani ugovor ili projekt.

Menedment kvalitete
U inenjerstvu kvalitete softvera, kvaliteta, cijena i vrijeme su tri meusobno ovisna faktora, kako je to prikazano na slici. Ako su dva od ovih faktora konstante, trei faktor nije mogue kontrolirati. Razvoj Uvoenje Koritenje Odravanje Cijena

Vanjski atributi
Robusnost Tonost Pouzdanost Djelotvornost

Kvaliteta

Vrijeme

Unutarnji atributi
Proirivost Prenosivost Odravljivost Cjelovitost

Razvoj Uvoenje Trajanje

Slika 1.2 Odnos kvaliteta, vrijeme, cijena

Ova tri elementa uzrokuju i najvee probleme, jer su trokovi i vrijeme isporuke softvera esto iznad predvienih veliina, a esto softver ne zadovoljava zahtjeve korisnika. Meutim, zadovoljstvo korisnika je osnovni cilj osiguranja kvalitete. Definirana kvaliteta za odreeni datum isporuke se moe postii samo ako je na raspolaganju primjeren proraun. Kako bi se dostigla definirana kvaliteta unutar definiranog prorauna, mora biti dovoljno vremena da bi se udovoljilo zahtjevima na softver. Ako su vrijeme i proraun nepromjenljivi, tada kvaliteta trpi zbog tih ogranienja. Kako bi se razrijeila ova situacija, potrebno je detaljno definirati ciljeve. Za veinu projekata vrijeme i proraun su nepromjenljivi. Prema tome, ciljeve kvalitete je potrebno opisati za razliite razine finoe, i potrebno je definirati prioritete. Na taj nain mogue je pronai prihvatljivo rjeenje u konfliktnoj situaciji. U razumno due vrijeme, investiranje u usavravanje kvalitete dovodi do znaajnog smanjenja trokova. Unutarnji i vanjski faktori kvalitete Faktori kvalitete softverskog proizvoda dijele se na unutarnje i vanjske faktore. Vanjski faktori su oni ije postojanje ili ne postojanje mogu zamijetiti korisnici proizvoda. T su: robusnost, pouzdanost, tonost, uinkovitost, jedostavnost upotrebe. Prenosivost, proirivost, ponovna upotrebljivost, cjelovitost i odravljivost su unutarnji faktori kvalitete koje moe percipirati samo inenjer razvoja softvera. Unutarnji faktori su klju osiguranja da su zadovoljeni vanjski faktori. Gornje ukazuje na to da je kvaliteta softvera multidimenzionalni koncept s faktorima kvalitete koji nisu neovisni nego utjeu jedan na drugi. Zadovoljenje zahtjeva na kvalitetu softverskog proizvoda trai primjeren kvalitativno usmjeren razvojni proces. Potrebno je prvenstveno definirati koliko je kvaliteta softvera vana za organizaciju. Nadalje, treba oblikovati politiku kvalitete za organizaciju i definirati ciljeve kvalitete.

Metrike i mjerenje kvaliteta softvera

Metrike softvera mjere atribute softvera i odnose se na razliite aspekte kvalitete softvera. Osnovna svrha primjene metrike je poboljanje kvalitete krajnjeg softverskog proizvoda. Drugim rijeima, uz samo mjerenje, metrike trebaju pozitivno utjecati na proizvod na nain da poboljaju njegov razvoj.

to je mjerenje?
Formalna definicija mjerenja je: mjerenje je proces pri kojem se brojevi ili simboli pridodijeljuju atributima entiteta realnog svijeta, na nain da realni svijet opisuju prema tono utvrenim pravilima. Mjerenje je dobivanje informacija o atributima entiteta. Entitet moe biti objekt ili neki dogaaj. Atribut je svojstvo ili karakteristika entiteta od interesa. Proizvodnja softvera je esto izvan kontrole, injenica je da se mjerenja provode malo, a ono to ne mjerimo ili ne moemo mjeriti je van kontrole. Aktivnosti mjerenja moraju imati jasno odreenu svrhu i cilj, i to je ono to odreuje vrstu entiteta i atributa koje je potrebno mjeriti.

Okvir mjerenja softvera

Prva obveza pri aktivnostima mjerenja softvera je utvrditi entitete i atribute od interesa koje elimo mjeriti. Za softver, od interesa su tri klase entiteta ije atribute elimo mjeriti: Procesi, koji se odnose na aktivnosti razvoja softvera i sadre faktor vremena;

Proizvodi, koji su rezultat procesa; Resursi, kao inputi procesa.

Razlikuju se unutarnji i vanjski atributi: - Vanjski atributi procesa, proizvoda ili resursa su oni koje je mogue izmjeriti uzimajui u obzir kako se oni odnose prema svom okoliu. - Unutarnji atributi procesa, proizvoda ili resursa su oni koje je mogue izmjeriti iz samih procesa, proizvoda ili rasursa. Tablica 2-1 opisuje okvir, odnosno, prikazuje komponente mjerenja softvera. Tablica 2-1: Komponente mjerenja softvera Entiteti Procesi
Specifikacija izgradnje Detaljni dizajn Testiranje Proizvodi Specifikacije Dizajn Kodiranje

Unutarnji

Atributi Vanjski
kvaliteta, stabilnost cijene, .. trokovna uinkovitost, cijene, .. trokovna uinkovitost, cijene, .. odravljivost, razumljivost, .. kvaliteta, kompleksnost, odravljivost, pouzdanost, odravljivost, iskoristivost, kvaliteta, uinkovitost, iskustvo, znanje, inteligencija, uinkovitost, kvaliteta, iskoristivost, kvaliteta, udobnost, iskoristivost, pouzdanost, odravljivost, pouzdanost,

Vrijeme, napor, broj zahtjeva za promjenama, Vrijeme, napor, broj pronaenih greaka specifikacije, Vrijeme, napor, broj pronaenih greaka, Veliina, modularnost, redundantnost, funkcionalnost, ponovna iskoristivost, Veliina, ponovna iskoristivost, modularnost, funkcionalnost,.. Veliina, modularnost, aloritamska kompleksnost, strukturnost kontrolnog tijeka, ponovna iskoristivost, . Veliina, razina pokrivanja, Plae, godine, Veliina, strukturiranost, plae, razina komunikativnosti, Veliina, temperatura, svjetlost, Cijena, veliina, Cijena, brzina, veliina memorije,

Test podaci Resursi Osoblje Projektna ekipa Ured Softver Hardver

Zbog svoje prirode, vanjske atribute je teko izmjeriti, takoer za neke nema ni tonih definicija; atribut kao to je to na pr. kvaliteta je toliko openit i ima razliiti znaaj za pojedine korisnike da ga je gotovo besmisleno mjeriti. Nova saznanja u podruju softverskog inenjerstva omoguuju mjerenja i ovih atributa. Postoji veza izmeu unutarnjih i vanjskih atributa, i veza izmeu direktnih i indirektnih mjerenja. Ovo slijedi iz definicije da se unutarnji atributi u principu mogu mjeriti direktno a vanjski se ne mogu mjeriti direktno. U svrhu procjene kvalitete softvera potrebno je mjeriti odreene vanjske atribute kao to su to pouzdanost, upotrebljivost, odravljivost, i dr.

Mjerenje unutarnjih atributa

Inenjerske metode razvijane zadnjih dvadesetak godina odreuju pravila, alate, smjernice, i dr. za izradu softverskih proizvoda. Koritenje metoda vodi ka konstrukciji proizvoda s odreenim strukturnim svojstvima koji su karakterizirani odreenim razinama kvalitete unutarnjih atributa kao to su to modularnost, redundantnost, hijerarhinost i dr. Pretpostavka je da dobra unutarnja struktura atributa vodi ka dobroj vanjskoj kvaliteti, tj. odreena unutarnja struktura atributa osigurava: vanjske atribute koje oekuju korisnici kao na pr. upotrebljivost, pouzdanost, odravljivost; vanjske atribute procesa koje oekuju menaderi kao na pr. proizvodnost, i dr.

Iz gornjega se moe postaviti aksiom: Dobra unutarnja struktura => Dobra vanjska kvaliteta Usprkos intuitivnoj vezi izmeu unutarnje strukture softverskih proizvoda i njegovih vanjskih atributa procesa i proizvoda, do sada je bilo malo znanstvenih pokuaja uspostavljanja njihove veze. Mjerenje duine programa Najee mjerilo duine izvornog programa je broj linija koda (eng.: Lines of Code - LOC). Pri tome: Linija koda je bilo koja linija teksta programa koja nije komentar ili je prazna, bez obzira na broj iskaza ili fragmenata u liniji. Definiramo: NCLOC broj linija bez komentara ili ELOC efektivni broj linija koda (eng.: Effective Lines of Code) CLOC broj linija komentara teksta programa (Number of Comment Lines of Program Text) Ukupna duina programa je: LOC = NCLOC + CLOC Mjerenje funkcionalnosti Funkcionalnost proizvoda je koliina funkcija koje proizvod moe isporuiti. Metoda mjerenja koju je predloio Albrecht 1979, naziva se metoda funkcijske toke. Funkcijske toke izraunavaju se ispunjenjem tablice 2-2 iz specifikacije sustava:

Broj korisnikih inputa: svaki korisniki input koji osigurava aplikacijski orijentirane podatke za softver. Primjeri su imena datoteka i odabir menija; Broj korisnikih outputa: svaki korisniki output koji osigurava aplikacijski orijentirane informacije korisniku. Primjeri su izvjetaji, ekrani, poruke o grekama i slino (pojedinane komponente od ovih se ne ubrajaju); Broj korisnikih upita: Interaktivni inputi koji zahtjevaju odgovor; Broj datoteka: Svaka logika glavna datoteka; Broj vanjskih suelja: Sva suelja koja se koriste za prijenos informacija na drugi sustav.

Tablica 2-2: Izraun funkcijske toke

Stavka Broj korisnikih inputa Broj korisnikih outputa Broj korisnikih upita Broj datoteka Broj vanjskih suelja TEINSKI FAKTOR Jednostavan Prosjean Kompleksan 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10

Npr., ako je procjenjeno da svi inputi, outputi,upiti, glavne datoteke i suelja imaju prosjenu teinsku vrijednost, slijedea formula se moe upotrijebiti za izraun funkcijskih toaka: FT = 4*# Inputa + 5*#Output + 4*# Upita + 10*# Datoteka + 7*# Suelja (# oznaava broj inputa, outputa, ..) Organizacije koje koriste metodu funkcionalne toke razvijaju kriterije za utvrivanje jednostavnih, prosjenih ili kompleksnih teinskih faktora. U svakom sluaju utvrivanje kompleksnosti je subjektivne naravi. Nakon izrauna funkcijske toke, ona se moe iskoristiti kao mjerilo proizvodnosti, kvalitete, i drugih atributa. Proizvodnost = FT / ovjek-mjesec Kvaliteta = Greke / FT Cijena = $ / FT Metrike strukture kontrolnog tijeka Veliki broj radova metrike softvera posveen je izuavanjima strukture kontrolnog tijeka programa. Kontrolni tijek programa prikazuje se grafikonima tijeka. Grafikon se sastoji od skupine toaka (vorova) i linijskih segmenata (smjernica). U dirktnim grafikonima svakoj smjernici se pridruuje dolazni ili odlazni smjer (strelica). Koritenjem ove metrike mogue je na pr. izraunati kompleksnost softverskog proizvoda. McCabe (1976) je ustanovio da je potekoa razumijevanja programa uzrokovana kompleksnou grafikona kontrolnog tijeka programa. Grafikon programa na slici prikazuje kontrolni tijek. Svaki vor s abecednom oznakom predstavlja aktivnost procesa (jedan ili vie iskaza izvornog koda), tijek kontrola ili granjanja prikazan je spojnim strelicama.

Cikliki broj V veznog grafikona G je broj linearno neovisnih staza u grafikonu. Broj G(V) se izraunava se prema formuli: V = E n + 2p Priemu je: E je broj staza n je broj vorova p je broj spojnih komponenti a 1 9 b 4 5 e 8 f 2 c 6 3 7 d 10

Ulazno vorite a Izlazno vorite b V(G) = 9 6 + 2 = 5 Slika 2.1 Kontrolni tijek Za grafikon prikazan primjerom na slici 2.1, V(G) jest 5. Model definira mjeru kompleksnosti modula programa. Broj V(G) moe se izraunati i iz broja regija (u naem sluaju regije su R1 R5) u grafikonu. Regija se moe opisati kao zatvoreno podruje okrueno stazama, u naem sluaju postoji 5 regija. Broj V(G) takoer ukazuje na maksimalnu veliinu modula programa. Na temelju brojnih podataka McCabe je ustanovio da je V(G) = 10 praktiki gornja granica za veliinu modula. Kad ciklomatika kompleksnost prijee ovaj broj, postaje vrlo teko primjereno testirati modul.

Mjerenje vanjskih atributa

Jedan od glavnih ciljeva softverskog inenjeringa je poboljanje kvalitete softverskog proizvoda. Zanima nas koji specifini atributi kvalitete softvera su od interesa za korisnika, i kako moemo izmjeriti doseg do kojeg su ti atributi prisutni u naem softverskom proizvodu. McCall-ov model kvalitete softvera

Prema gore navedenom, softver posjeduje atribute ijim mjerenjima se moe odrediti njegova kvaliteta. Pokuaji odreivanja kvalitete softvera kroz niz njegovih opih atributa rezultiralo je odreivanjem inilaca ili faktora kvalitete prema autoru McCall-u (1976). Faktori kvalitete su vanjski atributi visoke razine kao odravljivost, pouzdanost, iskoristivost, ali ukljuuju i neke atribute koji spadaju u unutarnje atribute kao testibilnost i uinkovitost. Na slici su prikazani faktori kvalitete softvera temeljeni na tri dimenzije proizvoda: 1. 2. 3. operativnosti proizvoda prenosivosti proizvoda reviziji proizvoda

Slika 2.2 Faktori kvalitete softvera Hijerarhijski model Hijerarhijski model kvalitete softvera je prikazan na slici. Na najvioj hijerarhijskoj razini je skupina faktora ili inilaca kvalitete softvera. Na nioj razini je skupina kriterija za svaki faktor kvalitete. Na najnioj razini modela su metrike.

Faktori

Menedment-orijentirani pogled na kvalitetu softvera

Kriteri j

Softversko-orijentirani atributi koji osiguravaju kvalitetu

Metrike
Hijerarhijski model kvalitete softvera Definicije svakog faktora kvalitete opisani su u Tablici 2-3. Tablica 2-3: Definicije faktora kvalitete Faktor
ODRAVLJIVOST FLEKSIBILNOST TESTIBILNOST PRENOSIVOST PONOVNA UPOTREBLJIVOST UNUTARNJA OPERATIVNOST TONOST POUZDANOST DJELOTVORNOST CJELOVITOST UPOTREBLJIVOST

Kvantitativna mjerila atributa

Definicija
Napor potreban za lociranje i otkrivanje greke u izvrnom programu Napor potreban za izmjenu izvrnog programa Napor potreban za testiranje programa u svrhu osiguranja da on obavlja predodreene funkcije Napor potreban za prijenos programa s jednog hardverskog / softverskog okolia sustava na drugi Doseg do kojeg se program moe koristiti u drugoj aplikaciji u odnosu na opseg funkcija koje program obavlja Napor potreban za spajanje jednog sustava s drugim Doseg do kojeg program zadovoljava svoju specifikaciju I ispunjava ciljeve korisnika Doseg do kojeg se za program moe oekivati da e obavljati odreene funkcije s potrebnom preciznou Koliina reunalskih resursa I koda potrebnih programu za obavljanje funkcije Doseg do kojeg se moe kontrolirati pristup programu od neovlatene osobe Napor potreban za uenje, rad, pripremu inputa i interpretaciju outputa programa

Pristup mjerenju navedenih faktora kvalitete temelji se na subjektivnoj evaluaciji zgotovljenog proizvoda. Kriteriji kvalitete Utvrivanje slijedee razine zahtjeva na kvalitetu ukljuuje odreivanje softversko-orijentiranih kriterija. Skup kriterija su atributi softvera koji se odnose se na razliite faktore kvalitete prema definiciji. Njihova identifikacija je automatska i predstavlja detaljniju specifikaciju zahtjeva na kvalitetu. Menader projekta zajedno s QA menederom, menederom razvoja i korisnikom utvruje faktore kvalitete koji su vani za projekt, koristei gore navedene tablice. Odabiru se faktori koji su vani za projekt izbjegavajui nepotrebna mjerenja za manje vane faktore kvalitete. Procedure za utvrivanje vanih faktora kvalitete Zahtjevi na kvalitetu softvera za svaki pojedini sustav su razliiti i ovisni o temeljnim karakteristikama sustava ili aplikacije. Svaki pojedini softverski sustav ili aplikaciju potrebno je evaluirati u vezi njegovih temeljnih karakteristika. Npr. ako se oekuje dugi ivotni vijek aplikacije, tada je za sustav vaan faktor odravljivost; ako je aplikacija neki eksperimentalni sustav gdje se mogu oekivati este promjene specifikacije zahtjeva na softver, tada je faktor fleksibilnost od primarne vanosti; ako je sustav aplikacija realnog vremena ili je aplikacija kritina za sigurnost, tada je pouzdanost najvaniji faktor. Tablica 2-6 prikazuje karakteristike nekih sustava i njihove faktore kvalitete. Tablica 2-6: Karakteristike sustava i faktori kvalitete

Karakteristike Dugotrajan ivotni ciklus

Faktori kvalitete ODRAVLJIVOST FLEKSIBILNOST PRENOSIVOST POUZDANOST POUZDANOST UINKOVITOST TONOST FLEKSIBILNOST POUZDANOST TESTIBILNOST UNUTARNJA OPERATIVNOST POUZDANOST TONOST

Aplikacije realnog vremena / aplikacije kritine za sigurnost Eksperimentalni sustavi Meuovisne aplikacije

Mjerenje pouzdanosti i raspoloivosti

Od mnogih atributa kvalitete softvera visoke razine (faktora) koji su predloeni modelom posebnu vanost imaju: raspoloivost, odravljivost i pouzdanost. Atribut pouzdanost je moda najvaniji atribut kvalitete koji zahtjeva svaki korisnik. To je ujedno atribut koji najbolje moemo mjeriti i predviati. Pouzdanost se definira kao vjerojatnost rada raunalskog programa bez greke u specificiranom okoliu u specificiranom vremenu. Jednostavna mjera pouzdanosti je meuvrijeme izmeu greaka (engl.: Mean Time Between Failure - MTBF), pri emu je: MTBF = MTTF + MTTR MTTF je meuvrijeme do greke (engl.: Mean Time To Failure) MTTR je meuvrijeme do ispravka (engl.: Mean Time To Repair) Problem porasta pouzdanosti softvera Veina razvojnih teorija koje se bave mjerenjem pouzdanosti, odnose se na problem porasta pouzdanosti softvera. Pouzdanost se definira kao vjerojatnost da nee doi do pojave greke tijekom odreenog vremena u specificiranim uvjetima. Neuspjeh softvera se definira kao neprihvatljivo ispadanje iz rada programa uzrokovanog grekama latentnim u softveru. Ako se u fazi testiranja moe s visokom sigurnou procijeniti ukupni broj softverskih greaka latentnih u softveru, pouzdanost softvera se moe kvantitativno procijeniti i izmjeriti. Tada e biti mogue kontrolirati napredak testiranja i predvidjeti vrijeme u kojem e softver biti spreman za isporuku i koritenje. Funkcija pouzdanosti, Ri(t) = P (Ti > t) = 1 Fi(t) je vjerojatnost da e se program odrati za vrijeme t prije nego slijedei puta ispadne iz rada. P oznaava vjerojatnost; Fi(t) se naziva distribucijska funkcija sluajne varijable Ti. Jednadba daje cjelokupan opis nesigurnosti od Ti.

Zadaci osiguranja kvalitete softvera

Zadatak Osiguranja kvalitete softvera (OKS) je monitoring metoda i normi. OKS nije odgovorna za proizvodnju kvalitetnog proizvoda, to je posao razvojnih inenjera. OKS je odgovoran za auditiranje akcija na postizanju kvalitete u organizaciji i upozoravanje menedmenta na bilo koja odstupanja od zacrtanih ciljeva. Primjena osiguranja kvalitete Prije uspostavljanja OKS potrebno je odluiti koliko je kvaliteta softvera vana za organizaciju. OKS je alat menadmenta kojimse osigurava: -

koristi prikladna metodologija razvoja, za projekte se koriste definirane norme i procedure, provode pregledi i auditi, tijekom razvoja proizvodi dokumentacija kao podrka odravanju i usavravanju, koriste se mehanizmi kontrole promjena, plan razvoja softvera i plan OKS su kompatibilni, kontrole kvalitete se provode prema uspostavljenim normama.

Uloga osiguranja kvalitete Samo osobe odgovorne za softverski projekt su odgovorne za kvalitetu radova i krajnjeg proizvoda. Osobe koje rade u OKS-u, same ne mogu uiniti nita u vezi kvalitete. Odgovornosti OKS Pregled / revizija svih razvojnih planova i planova kvalitete u svrhu provjere dovrenosti Pregled / revizija svih planova testiranja u svrhu provjere udovoljavanju normama Pregled / revizija znaajnijih primjera rezultata testiranja u svrhu provjere udovoljenja planova Povremeni audit performanci Upravljanja Konfiguracijom Softvera UKS Prisustvovanje nadzoru dizajniranja i kodiranja u svojstvu moderatora Prisustvovanje svim faznim pregledima / revizijama, te registriranje svih odstupanja od utvrenih normi i procedura. Ako OKS ispunjava svoje obveze, te ako se gotov prizvod ne isporui sve dok OKS ne provede sve kontrole/preglede/revizije, tada OKS pomae menadmentu u usavravanju kvalitete. Funkcije OKS Evaluaciju planiranja softverskog Evaluaciju procesa dizajniranja Praksu osiguranja Evaluaciju prakse kodiranja Evaluaciju. Evaluaciju procesa testiranja i integracije softvera Evaluacija procesa menadmenta i kontrole projekta Pripremu procedura osiguranja kvalitete. Pokretanje programa OKS 1. Iniciranje OKS programa 2. Utvrivanje poslova i dokumentacije OKS-a. 3. Izrada OKS plana 4. Uspostavljanje normi 5. Uspostava OKS funkcije - Uspostavlja se OKS funkcija za izvrenje utvrenog plana.

6. Voenje kolovanja i promocija OKS programa 7. Implementacija OKS plana 8. Evaluacija OKS programa

Plan osiguranja kvalitete

Norma ANSI/IEEE -Std 730 za pripremu POKS-a sadri slijedea poglavlja: Plan osiguranja kvalitete softvera 1. Svrha 2. Referentni dokumenti 3. Upravljanje 4. Dokumentacija 5. Norme, praksa, konvencije 6. Pregledi i auditi 7. Upravljanje konfiguracijom softvera 8. Izvjeivanje o problemima i korektivne aktivnosti 9. Alati, tehnike i metodologije 10. Kontrola koda 11. Kontrola medija 12. Kontrola dobavljaa 13. Prikupljanje podataka, odravanje i prestanak rada

NORMIRANJE I MENEDMENT
Norme softvera
Norma je mjerilo ili temelj za usporedbu, koji se koristi za procjenu veliine, sadraja, vrijednosti ili kvalitete nekog objekta ili aktivnosti. Kod softvera, koriste se dvije vrste normi Jedna vrsta opisuje prirodu objekta koji e se proizvesti, dok druga vrsta definira nain izvoenja radova. Razine norma Zakonske norme uputstva preporuke

Nova norma za neku dravu postaje zakonska norma nakon to je prihvati odgovarajue zakonsko tijelo. Uputstvo ukazuje na nain primjene odreene norme. Preporuka ima oblik norme, ali nema snagu zakonske obveze. Organizacije za normizaciju softvera Neke od organizacija za normizaciju softvera su: - SEI (Software Engineering Institute), - DoD (US Department of Defense), - ANSI (American National Standards Institute) / IEEE (Institute of Electrical & Electronic Engineers), ESA (European Space Agency). Osnovni izvor normi softvera su ANSI i IEEE norme koje nakon odreenog vremena preuzima ISO (International Organization for Standardization).

Norme ISO za kvalitetu ISO (International Organization for Standardization) je meunarodno udruenje nacionalnih tijela za normizaciju. Priprema normi se ostvaruje putem ISO tehnikih komiteta. Svojim tehnikim komitetima krajem sedamdesetih g. zapoelo se s radom na donoenju normi iz podruja kvalitete, to je 1987 g. rezultiralo objavom normi ISO 9000 za kvalitetu. Osnovne ISO norme Objavljene su slijedee osnovne norme: ISO 8402 Upravljanje kvalitetom i osiguranje kvalitete - Rjenik ISO 9000 Upravljanje kvalitetom i norme osiguranja kvalitete Uputstvo za odabir i primjenu normi. ISO 9001 Sustavi kvalitete Model za osiguranje kvalitete u dizajnu, razvoju, proizvodnji, uvoenju i posluivanju ISO 9002 Sustavi kvalitete Model za osiguranje kvalitete u proizvodnji i uvoenju ISO 9003 Sustavi kvalitete Model za osiguranje kvalitete u zavrnoj kontroli i testiranju ISO 10011 Uputstvo za auditiranje sustava kvalitete Svaka zemlja ima specifinu oznaku normi ISO 9000, na primjer u Engleskoj ove norme imaju oznaku BS5750 (British Standard 5750) Zahtjevi norme ISO 9000 Zahtjevi norme ISO 9000 su podijeljene na 20 glavnih poglavlja: ISO 9000 1. 2. 3. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 Podruje primjene Normativne reference Pojmovi Odgovornost uprave Sustav osiguranja kvalitete Pregled ugovora Kontrola projekta Kontrola dokumenata Nabava Proizvodi dobiveni od podizvoaa Identifikacija i slijedivost proizvoda Kontrola procesa Nadzor i testiranje 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 Oprema za nadzor, mjerenje i testiranje Status nadzora i testiranja Kontrola nesukladnih proizvoda Korektivne aktivnosti Rukovanje, skladitenje, pakiranje Upravljanje zapisima o kvaliteti Interni audit kvalitete Trening Usluge Statistike tehnike

ISO norme za kvalitetu softvera

Za softversku industriju, objavljena je norma ISO 9000-3 kao nadopuna normi ISO 9001, pod nazivom: Norme za upravljanje kvalitetom i osiguranje kvalitete, dio 3 Uputstvo za primjenu ISO 9001 u razvoju, isporuci i odravanju softvera. Za softversku industriju vane su slijedee ISO norme: ISO 9001 Sustav kvalitete Model za osiguranje kvalitete u dizajnu, razvoju, proizvodnji, uvoenju i posluivanju. ISO 9000-3 Uputstvo za primjenu ISO 9001 u razvoju, isporuci i odravanju softvera. ISO 9004-2 Upravljanje kvalitetom i elementi sustava kvalitete dio 2.

Norma ISO 9000:2000

Poetkom 2000 g. dolazi do revizije normi ISO 9000; novu strukturu sustava ine: ISO 9000 ISO 9001 ISO 9004 Osnovne zamisli i pojmovi Sustav osiguranja kvalitete Zahtjevi Sustav osiguranja kvalitete Smjernice za poboljanje usluga

Jezgru normi ine: ISO 9000 Nadomjestak za ISO 8402/ISO 9000-1 ISO 9001 Nadomjestak za ISO 9001, 9002, 9003 ISO 9004 Nadomjestak za 9004-1 ISO 10011 (planirani) Nadomjestak za ISO 10011

Za softversku industriju koristi se norma ISO 90003.

Norme za ivotni ciklus softvera

Norma ISO 12207
Meunarodne norme ivotnog ciklusa softvera razvijene su zato da bi se uspostavio zajedniki meunarodni okvir za dobavljanje, razvoj, koritenje i odravanje softvera. Norma ISO/IEC 12207 je objavljena u kolovozu 1995.g., i do danas nije doivjela promjene ISO 12207 opisuje glavne komponente procesa ivotnog ciklusa softvera.

Norma ISO 15504

Za asesment procesa koristi se metoda SPICE.. Metoda je formalizirana kao norma ISO 15504, 2001.g. Tablica 4-4 navodi naslove i ISO brojeve norme. Tablica 4-4: Norma 15504
ISO broj ISO 15504-9 ISO 15504-8 ISO 15504-7 ISO 15504-6 ISO 15504-5 ISO 15504-4 ISO 15504-3 ISO 15504-2 ISO 15504-1 Naziv norme TR 15504-9: Informatika tehnologija Asesment procesa softvera, Dio 9: Rjenik TR 15504-8: Informatika tehnologija Asesment procesa softvera, Dio 8: Uputstvo za upotrebu u odreivanju sposobnosti procesa dobavljaa TR 15504-7: Informatika tehnologija Asesment procesa softvera, Dio 7: Koncepti i uvodnik TR 15504-6: Informatika tehnologija Asesment procesa softvera, Dio 6:Uputstvo za kvalifikaciju asesora TR 15504-5: Informatika tehnologija Asesment procesa softvera, Dio 5: Model asesmenta i indikatori TR 15504-4: Informatika tehnologija Asesment procesa softvera, Dio 4: Uputstvo za provedbu asesmenta TR 15504-3: Informatika tehnologija Asesment procesa softvera, Dio 3: Provedba asesmenta TR 15504-2: Informatika tehnologija Asesment procesa softvera, Dio 2: Referentni model za procese i sposobnost procesa TR 15504-1: Informatika tehnologija Asesment procesa softvera,

Dio 1: Koncepti i uvodnik

Norma ESA PSS-05

Normu ESA PSS-05 razvio je ESA Board for Software Standardization and Control (BSSC). Dokument opisuje norme softverskog inenjerstva koje primjenjuje Europska svemirska agencija (Euro Space Agency ESA).. Dva su aspekta softvera koje disciplina softverskog inenjerstva mora sagledati. To su: proizvod koji treba implementirati i proces kojim softver nastaje. Prvi dio ESA norme odnosi se na aspekte softverskog proizvoda, dok se drugi dio norme odnosi na proces razvoja softvera, tj. na menederske procedure koje se primjenjuju u svrhu monitoringa i kontrole proizvodnje te koritenja softvera.

Saetak
Norma je mjerilo ili temelj za usporedbu koji se koristi za procjenu veliine, sadraja, vrijednosti ili kvalitete objekta ili aktivnosti. Razlikuju se tri razine norma: (1) zakonske norme, (2) uputstva, (3) preporuke. Glavni izvor normi su ANSI i IEEE norme koje nakon odreenog vremena preuzima ISO. Za softversku industriju vane su norme: ISO 9001 Sustav kvalitete, ISO 9000-3 Uputstvo za primjenu ISO 9001 u razvoju, isporuci i odravanju softvera, te ISO 9004-2 Upravljanje kvalitetom i elementi sustava kvalitete. Poetkom 2000. g. dolazi do revizije normi ISO 9000. Norme za ivotni ciklus softvera su ISO 12207, norma ISO 15504 opisuje metodu SPICE za asesment procesa razvoja softvera. Dokument ESA PSS-05 opisuje norme softverskog inenjeringa koje primjenjuje Europska svemirska agencija (ESA). Norma uzima u obzir sve aspekte sustava ukljuivi suelja s raunalskim hardverom i drugim komponentama sustava. Prvi dio norme se odnosi na softverski proizvod, dok se drugi dio odnosi na procese razvoja softvera.

5
Planiranje, organiziranje i kontrola projekta
Da bi se osigurala kvaliteta softvera potrebno je poboljati djelotvornost menedmenta softvera. Menedment kontrole kvalitete projekta ukljuuje: (1) uspostavljanje normi, (2) uspostavljanje kontrolnih toaka, (3) uspostavljanje kontrolnih procedura, i (4) procjenu potrebnog osoblja. Organiziranje softverskog inenjerskog projekta je aktivnost menedmenta, koja rezultira u dizajnu formalne strukture poslova softverskog inenjerstva i meusobnim odnosima tih aktivnosti.

Planiranje projekta
Kod planiranja projekta potrebno je zapitati se: TO planiramo? odgovor na ovo pitanje znai da proizvod ili output mora biti definiran, a poslovi razgraeni do pojedinanih aktivnosti.

Na pitanje TKO ? odgovor znai da mora biti odreeno osoblje na projektu, i specificirane pojedinane odgovornosti. Na pitanje KAKO? odgovor znai da je odobren proraun za projekt, i locirani su resursi; Na pitanje KADA? odgovor znai da mora biti uspostavljen redoslijed izvoenja radova, i utvrene kontrolne toke. Metode menedmenta za kontrolu kvalitete projekta ukljuuju (1) uspostavljanje normi, (2) uspostavljanje kontrolnih toaka, (3) uspostavljanje kontrolnih procedura, i (4) procjenu potrebnog osoblja. Uspostavljanje normi U planu projekta potrebno je navesti popis normi koje e se koristiti na konkretnom projektu, ovdje se ubrajaju norme dokumentacije, norme specifikacija, te norme programiranja/kodiranja. Uspostavljanje kontrolnih toaka Kontrolne toke ili kritine toke odluke su prethodno definirane toke tijekom izvedbe projekta u kojima se donosi odluka o nastavljanju ili prekidu projekta. Softverski projekti obino imaju tri kritine toke odluke da li nastaviti sprojektom: (1) nakon faze mogunosti izvedbe projekta, (2) nakon faze dizajniranja, i (3) nakon faze razvoja, kako je to prikazano na slici 5.1. Faza: Mogunost izvedbe 1 Faza: Dizajniranje Faza: Razvoj Faza: Rad

2 Slika 5.1 Tri kritine toke odluke

Da bi se odluilo o nastavljanju projekta, treba razmotriti slijedea pitanja: Da li je projekt tehniki izvediv? Da li je projekt ekonomski izvediv? Moe li se projekt dovriti u predvieno vrijeme? Koji su rizici od prihvaanja projekta? Koji su dobici od projekta? Da li dobici opravdavaju rizik?

Svaka toka odluke ima slijedee karakteristike: Revidirane procjene trokova i performanci projekta su tonije od prethodne procjene, Dodatne konsolidacije za projekt je potrebno usaglasiti prije nastavljanja na slijedeu fazu, Projekt je u logikoj prekidnoj toki. Projektna dokumentacija proizvedena kao rezultat prethodne faze se kompletira i arhivira za kasniju upotrebu.

Uspostavljanje kontrolnih procedura Plan projekta treba sadravati plan kontrolnih procedura.

Za svaku kritinu kontrolnu toku projekta plan treba specificirati koje procedure e se koristiti za donoenje odluke o nastavku ili prestanku projekta. Procjena potrebnog osoblja Plan projekta treba sadravati takoer i procjenu potrebnog osoblja na projektu. Ispravnost takve procjene glavni je faktor kvalitete i trokova za projekt. Ako se pokae da je broj osoba na projektu pre mali tada e trpjeti kvaliteta ili e doi do kanjenja redoslijeda radova, jer novo osoblje treba odreeno vrijeme da postane proizvodno.

Organiziranje projeka
Organiziranje softverskog inenjerskog projekta je aktivnost menedmenta, koja rezultira u dizajnu formalne strukture poslova softverskog inenjerstva i meusobnim odnosima tih aktivnosti. Organiziranje podrazumjeva utvrivanje i detaljiziranje projektnih aktivnosti za postizanje ciljeva razvojnog projekta, te rasporeivanje tih aktivnosti na logike cjeline. Tablica 5-1 primjer je skupine aktivnosti softverskog inenjerskog projekta koje su grupirane i pridodijeljene organizacijskim entitetima: Tablica 5-1: Aktivnosti projekta
Projektna aktivnost Odjeljivanje i dodijeljivanje zahtjeva na softver jedinici konfiguracije softvera Priprema planova razvoja softvera i dokumentacije Definiranje i implementacija normi i prakse Prikupljanje i evaluacija mjerenja tehnikih performanci Priprema dokumentacije za testiranje softvera Voenje testiranja softvera Podrka testiranju softvera Odravanje biblioteke razvoja softvera Instaliranje softvera isporuenog od dobavljaa Tehnika podrka softverskog sustava Analiza zahtjeva jedinice konfiguracije softvera #1 Dizajn i razvoj jedinice konfiguracije softvera #1 Programiranje Priprema dokumentacije za jedinicu konfiguracije #1 Podrka testiranju Analiza zahtjeva jedinice konfiguracije softvera #2 Ostale aktivnosti kao grupa 1 Identifikacija grupe Inenjering softverskog sustava

Inenjering testiranja softvera

Podrka softverskog sustava

Grupa aplikacije softverskog sustava 1

Grupa aplikacije softverskog sustava 2

Uspostavljanje organizacijske strukture Razvojni softverski projekt se moe strukturirati na nekoliko naina: Konvencionalna organizacijska struktura Projektna organizaciojska struktura Timska struktura

Mnogi menederi projekta nemaju mogunost odabira strukture jer se to esto utvruje politikom organizacije.

Kontrola projekta
Kontrola softverskog inenjerskog projekta podrazumjeva aktivnosti menedmenta koje osiguravaju da se aktualni radovi na projektu provode u skladu s planom. Osnovni procesi kontrole projekta obuhvaaju uspostavljanje planova i normi, te ispravljanje odstupanja. Kontrola je sustav povratne veze koji daje informacije o napredovanju projekta, tj. daje odgovore na pitanja; da li projekt napreduje u skladu s utvrenuim redoslijedom, da li su trokovi u skladu s predvienim, i da li postoje neki drugi problemi koji ometaju razvoj u skladu s planom. Uspostavljanje sustava monitoringa i izvjetavanja Razvoj sustava monitoringa i izvjetavanja uvjetovan je potrebom utvrivanja statusa projekta u bilo kojem momentu razvoja. Meneder projekta je odgovoran za uspostavljanje metoda monitoringa i izvjetavanja o statusu projekta. Paradigma menedmenta temeljnicom (engl. baseline) jest strategija menedmenta koja se koristi za kontrolu ivotnog ciklusa razvoja softvera. Sustav menedmenta temeljnicom integrira skupine faza ivotnog ciklusa softvera te dokumentira i izvjetava o statusu temeljnice. Ovaj sustav: (a) je temeljen na vodopadnom modelu razvoja softvera, (b) ralanjuje projekt na faze kojima se moe menedirati, (c) uspostavlja kontrolne toke, dokumente i izvjetaje, (d) koristi sustav menedmenta konfiguracijom softvera za kontrolu temeljnica. Temeljnice su odreene tehnike toke konfiguracije ivotnog ciklusa softvera, unaprijed ugovorene izmeu inenjera razvoja i korisnika softvera. Ove toke kontrolira i odrava sustav menedmenta konfiguracijom. Menedment konfiguracijom softvera je metoda kontrole i izvjetavanja o statusu konfiguracije softvera i disciplina identifikacije konfiguracije sustava u diskretnim tokama ivotnog ciklusa, u svrhu kontrole promjena. Vie o metodi e biti rije u slijedeem poglavlju. Miljokazi (engl. milestones), imaju glavnu ulogu u kontroli procesa razvoja. Miljokazi su diskretni dogaaji tijekom razvoja softvera ije dogaanje mora biti poznato unaprijed. To su npr. datum isporuke sustava, datumi plaanja, datumi zgotovljenja pojedinih faza, lista dokumenata koju treba osigurati korisnik, svi sastanci i dogovori u vezi projekta na kojima treba biti prisutan i korisnik, i sl. Pregledi su analize procesa razvoja i proizvoda u svrhu procjene napredovanja projekta. Izvjetaji trebaju dati informacije o statusu projekta,

Dokumentiranje kontrolnih metoda

Meneder projekta treba dokumentirati razvoj softvera i metode mjerenja za svoj projekt. Izvjeima o projektu informira zainteresirane o svim odstupanjima izmeu planiranih i aktualnih rezultata, te dokumentirati aktivnosti koje su provedene za ispravak odstupanja.

Saetak

Usvrhu osiguranja kvalitete softvera potrebno je poboljati planiranje projekta, odabrati prvu organizacijsku strukturu i implementirati kontrolu projekata. Metode menedmenta za kontrolu kvalitete projekta ukljuuju: a)uspostavu normi, b) uspostavu kontrolnih toaka, c) uspostavu kontrolnih procedura, d) procjenu potrebnog osoblja. Organiziranje softverskog razvojnog projekta podrazumjeva utvrivanje i detaljiziranje projektnih aktivnosti na logike cjeline. Projekt moe biti strukturiran prema: (1) konvencionalnoj organizacijskoj strukturi, (2) projektnoj strukturi, i (3) timskoj strukturi. Matrinu projektnu strukturu je potrebno dokumentirati u planu organizacije projekta. Kontrola projekta podrazumjeva aktivnosti menedmenta koje osiguravaju da se radovi na projektu provode prema planu. Osnovni procesi kontrole projekta obuhvaaju uspostavljanje planova i normi, te ispravljanje odstupanja.

6
Menedment promjena i konfiguracije softvera
Menedment promjena i konfiguracije softvera (MPKS) jedna je od osnovnih aktivnosti softverskog inenjerstva. MPKS pomae u kontroli promjena i koordinira rad projektne ekipe. To je proces utvrivanja i definiranja konfiguracijskih jedinica u sustavu, kontrola promjena tih jedinica tijekom ivotnog ciklusa, izvjeivanja o statusu konfiguracije tijekom ivotnog ciklusa, izvjetavanje o zahtjevima za promjenama konfiguracije, te verificiranje ispravnosti konfiguracijskih jedinica. MPKS je nadalje disciplina utvrivanja konfiguracija sustava u diskretnim vremenskim jedinicama u svrhu sustavne kontrole promjena konfiguracije te odravanje integriteta i slijedivosti konfiguracije tijekom ivotnog ciklusa softvera.

Nazivlja softverskog sustava

Uloga MPKS je kontrola razvoja elemenata sustava od izgradnje pojedinanih elemenata, sve do uklapanja elemenata u cjelokupni sustav. Vano je koristiti jednoznanu terminologiju sustava. Razvoj sustava zapoinje od izgradnje modula, komponenata, pod-sustavskih proizvoda, podsustava, sve do kompletiranja cjelokupnog sustava, kako je to prikazano na slici 6.1.

Moduli Komponente Proizvodi Pod sustavi Sustav Komponente Proizvodi Podsustavi

Moduli

Slika 6.1 Nazivlja softverskog proizvoda Modulima se implementiraju male samostalne pojedinane funkcije; Komponentama se implementiraju vee pojedinane funkcije kao to su to I/O kontrolni sustav, funkcija redoslijeda odvijanja radova i sl; Podsustavski proizvodi sadre mnoge proizvode, kao na primjer: kontrolne programe, kompajlere operativnog sustava i dr.; Podsustavi velikih sustava sadre mnoge podsustave kao to su to komunikacije, prikazi, procesiranja i dr.; Sustav sadri cjelokupan softver koji zadovoljava zahtjeve korisnika.

Tijekom izgradnje sustava moduli se stalno mijenjaju kako bi se dodale nove funkcije ili ispravile greke, time se mijenjaju i drugi elementi sustava. Proces se podrava testiranjem, hijerahija obuhvaa: Jedinino testiranje pojedinani testovi svakog modula; Integracijsko testiranje kako se moduli integriraju u komponente,proizvode podsustava, podsustave i sustave, testiraju se njihova suelja i meuovisnosti u svrhu osiguranja njihovog tonog dizajniranja i implementacije, Funkcionalno testiranje nakon integriranja elemenata sustava u funkcionalne elemente, testiraju se komponente, podsustavski proizvodi, podsustavi i cjelokupni sustav; Povratno testiranje nakon svakog integracijskog koraka nastaje nova forma koja se testira u svrhu osiguranja da su sve prisutne funkcije koje su postojale u prijanjoj formi.

Funkcije menadmenta konfiguracije

Glavne funkcije MPKS su: Identifikacija konfiguracije softvera Revizije Verzije Uvjetovani kod Audit konfiguracije softvera

Identifikacija konfiguracije softvera Identifikacija konfiguracije softvera je: (1) proces oznaavanja konfiguracijskih jedinica u sustavu uz dokumentiranje njihovih karakteristika, (2) odobrena dokumentacija koja definira konfiguracijske jedinice, i (3) uvjetno odobrena tehnika dokumentacija konfiguracijskih jedinica u sustavu koja se odnosi na specifikacije, slike, i dokumentaciju konfiguracije. Revizije Kada se modul komponente integrira u jedinicu koju je mogue testirati, ona se testira zadnjom verzijom kontrolnog programa. Ako se pronau greke mogu se ponoviti prijanja testiranja kako bi se pronali izvori greaka. Potrebno je imati trag svake promjene nad modulima i pojedinanim testiranjima. Verzije

esto se nekoliko razliitih funkcija mogu implementirati istim modulom samo s malom razlikom koda. Kako se radi o razliitim programima svaki treba imati svoju oznaku verzije i revizije. Uvjetovani kod Uvjetovani kod moe biti jedan izvorni program koji sadri sve verzije programa, a instalira se verzija koja je najprikladnija za korisnika. Tako postoji samo jedan program, a korisnik odabire odreenu kombinaciju za svoju instalaciju. Audit konfiguracije softvera Audit se najee prevodi kao: nadzor, pregled stanja, provjera ili prosudba. Audit je openito unaprijed planirana i sustavno organizirana aktivnost, koja treba posluiti poslovodstvu za poduzimanje korektivnih mjera i poboljanja auditiranog podruja. Plan menedmenta konfiguracije softvera Pri uspostavljanju sustava sustava menedmenta konfiguracijom, prvi korak je razvoj plana menadmenta konfiguracije softvera (PMKS). Primjer sadraja PMKS-a prikazan je tablicom 6-1. Tablica 6-1: Plan menedmenta konfiguracije softvera 1. Pregled Ciljevi PMKS-a Pregled sustava 2. PMKS organizacija Odgovornosti lanovi OKS-a Odnos prema osiguranju kvalitete proizvoda 3. Metode PMKS-a Temeljnice i sadraj Identifikacija sustava Sustav kontrole Audit Alati podrke 4. Procedure PMKS-a Prirunik procedura Forma i zapisi 5. Implementacija PMKS-a Plan osoblja Plan podrke sustava Budet Kontrolne toke implementacije

Saetak
MPKS je vana aktivnost softverskog inenjerstva. MPKS je proces utvrivanja i definiranja konfiguracijskih jedinica sustava, kontrola promjena nad njima, izvjeivanje o statusu i zahtjevima za promjenama konfiguracije, te verificiranje ispravnosti konfiguracijskih jedinica.

Hijerarhija testiranja tijekom izgradnje sustava obuhvaa: (1) testiranje pojedinanih jedinica sustava (modula), (2) integracijsko testiranje, (3) funkcionalno testiranje, i (4) povratno testiranje. Pri uspostavljanju sustava sustava menedmenta konfiguracijom, prvi korak je razvoj plana menadmenta konfiguracije softvera (PMKS).

DIO III Proces razvoja softvera 7

ivotni ciklus softvera
Razvoj softvera moe biti vrlo kompleksan i uvijek postoje alternativni naini rjeavanja procesa. Softversko inenjerstvo je disciplina koja ukljuuje tri glavna elementa - metode, alate i procedure, i koja omoguava menaderima kontrolu procesa razvoja, a praktiarima daje temelje za izgradnju visoko kvalitetnog softvera. Metode ukljuuju veliki broj aktivnosti: planiranje projekta, analizu zahtjeva na sustav, anlizu zahtjeva na softver, dizajn strukture podataka, arhitekturu program, algoritamske procedure, kodiranje, testiranje i odravanje. Procedure softverskog inenjerstva omoguavaju racionalni i pravovremeni razvoj softvera. One definiraju: redoslijed primjene metoda, dokumentaciju za isporuku, kontrole koje pomau osiguranju kvalitete i koordinaciji promjena. Sustavni, slijedni proces razvoja softvera naziva se ivotni ciklus softvera. Modeli procesa razvoja softvera mogu se definirati na tri razine: na U (Universal) razini, na W (Worldly) razini, i na A (Atomic) razini.

Vodopadni model
Vodopadni model je najpoznatiji i najee koriteni U-model procesa razvoja softvera. Razvoj zapoinje uspostavljanjem zahtjeva na sustav. Slijedei korak je analiza zahtjeva nasustavi i softver. Po analizi zahtjeva, izrauje se dokument specifikacije zahtjeva na softver. Za izradu ovog dokumenta moe posluiti norma ANSI/IEEE Std. 830, Specifikacija zahtjeva na softver. Zahtjevi na sustav

Analize

Dizajn Kodiranje Testiranje Odravanje

Slika 7.1 Vodopadni model Dizajn softvera odnosi se na strukturu podataka, arhitekturu softvera i procedure. Faza dizajniranja se dokumentira izradom dokumenta prethodni dizajn, te dokumentom detaljni dizajn. Pri zradi dokumenta moe posluiti ANSI/IEEE Std. 1016, Preporuka za opis dizajna. Slijedea fa za je kodiranje, pri emu se dizajn prevodi u raunalski kod. Nakon kodiranja zapoinje se s testiranjem. Prethodno je potrebno utvrditi strategiju testiranja. Strategija testiranja softvera mora obuhvatiti najnie razine softvera kako bi se verificiralo da je i najmanji segment koda tono implementiran, kao i najvie razine kako bi se validirale glavne funkcije sustava prema zahtjevima korisnika. Testiranje softvera je element sustava verifikacije i validacije (V&V), pri emu se verifikacijom osigurava da softver tono implementira specifinu funkciju, dok se validacijom osigurava da softver udovoljava zahtjevima korisnika. Zadnja faza je odravanje softvera nakon isporuke korisniku. Softver e se mijenjati ako se tijekom koritenja pronau greke, ako korisnik trai neke nove funkcije ili se softver mora prilagoditi novom korisnikom okoliu. Vodopadni model se esto koristi jer razdvaja razvojni proces na razliite faze. Iako model pomae u objanjenju razvojnog procesa softvera, ipak on ima neke nedostatke. Model je koristan u svrhu menediranja, u praksi, faze nisu slijedne nego se preklapaju i ponavljaju. Nadalje, korisnik treba navesti sve zahtjeve na sustav, svaki korak je potrebno detaljno dokumentirati, svaki korak je potrebno u potpunosti dovriti i tek tada prijei na slijedei korak to zahtjeva veliku strpljivost korisnika.

Prototip
Model prototipa daje veu fleksibilnost od vodopadnog modela jer omoguava direktno ukljuivanje korisnika u vrlo ranim fazama razvoja. Na taj nain omoguava se validacija zahtjeva na softver i dizajn softvera.

Ovisno od cilja koji je potrebno postii prototipom, razlikuju se: istraivaki prototip za potrebe razjanjenja zahtjeva na softver, eksperimentalni prototip za ispitivanje predloenog rjeenja, i evolucijski prototip za prilagodbu sustava prema promjenama zahtjeva. Nadogradnja prototipnog pristupa je Spiralni model. 7.2.1 Spiralni model

. U svrhu prevladavanja nedostataka vodopadnog modela Boehm je predloio spiralni model koji takoer spada u U-modele, prikazan na slici 7.2.

t v r iv a n je

c ilj e v a ,

N a p r e d o v Z a b n i rj en i l t e r un a k t oi v r aa , c o m g t a o n ki o e v n i j a r a i A n a liz a r iz ik a A n a liz a r iz ik a A n a liz a r iz ik a P O p e r a t iv n i r o t o t ip p r 3 o t o t i p

P , L P r a I n t i t e

P r o -P r o t o t i p 2 t o t ip 1 la n z a h t K e ov na -, j C p la n c e p t Z a h t j e D v i z na a j n D s o f t v e sr o f t v e r a e la n V a li d a c ija z v o ja z a h t je v a T e s t je d in I v a lid a c e g r a c ij a V e r if ik a c ija s t ir a n je d i z a jn a I n t e g r a c ija P r i h v I a t te n s o t i r a n j e I m p l e t em s e t i - r a n j e n t a c ij a R a z v o s li je d e

t a l jn i d iz a j K o d i r a n j e i c e ija

P la n f a z e

ir a n j e

s lije d e e

j, v e r i f ik a c ija e r a z in e

p r

Slika 7.2 Spiralni model U spiralnom modelu panja se pridaje rizicima na projektu, problemima trokova i naglaava koritenje prototipa. Prema modelu, svaki ciklus ukljuuje napredak istim redoslijedom koraka za svaki dio proizvoda od opeg koncepta sustava, kodiranja, sve do pojedinanog programa. Svaki ciklus spirale zapoinje identifikacijom: ciljeva svakog alternativa implementacije ogranienja koje se nameu aplikacijom pojedine alternative

Slijedei korak je evaluiranje alternativa u odnosu na ciljeve i ogranienja. Slijedei koraci su kao kod vodopadnog modela (koncept, zahtjevi na softver, prethodni dizajn, itd.). Svaki ciklus dovrava se revizijom uinjenog kako bi se osigurali dobri temelji za svaki slijedei ciklus. Nakon svakog ciklusa razvija se prototip kako bi se to ranije uoile i uklonile mogue greke.

W - modeli
W- modeli ivotnog ciklusa softvera su namjenjeni softverskim inenjerima praktiarima. Modeli odreuju faze aktivnosti razvoja, definiraju preduvjete za aktivnosti i rezultate. Primjer W-modela je V-Model ivotnog ciklusa softvera koji je postao de-facto njemaki standard za razvoj projekata u komercijalnom podruju i u podruju razvoja softverskih sustava ministarstva obrane.

PM
Planovi Kontrole/monitoring Informiraju

QA
Metode QA zahtjeva Procjenjuju

SWD Razvijaju sustav/dokumentaciju

CM
Administriraju - konfiguraciju - proizvode - promjene

Slika 7.3 etiri podmodela koji djeluju zajedno V-Model je model procesa ivotnog ciklusa softvera koji se sastoji od aktivnosti i proizvoda za razvoj softvera, osiguranja kvalitete, menadmenta konfiguracijom softvera, te menadmenta projekta. Strukturu ine funkcijski dijelovi koji se nazivaju podmodeli, to su: razvoj softvera (SWD), osiguranje kvalitete (QA), menadment konfiguracijom (CM) i projekt menadment (PM). Ta etiri podmodela su usko povezani i meusobno djeluju jedan na drugog razmjenom proizvoda/rezultata kako je to prikazano na slici 7.3. Podmodel SWD je prikazan na slici 7.4.

sustav Zahtjevi na sustav Dizajn sustava Plan integracije sustava SWD 1 Analiza zahtjeva na sustav i dizajn

SWD 9
Integracija sustava

Detaljno planiranje (DP) Zahtjevi Dizajn DP DP integracijski plan

SWD 2 DP analiza zahtjeva i dizajn

SWD 8
DP integracija

Segment informacija prirunik Program Dokumenti (SWCI) Dokumenti Komponente

SWD 3
Zahtjevi na softver Analiza zahtjeva na softver SWD 4 Prethodni dizajn

SWCI
Integracija

SWD 7
Plan integracije Arhitektura softvera Dizajn suelja Integracija softvera Integracija kompon.

SWD 5
Rijenik podataka Detaljni dizajn

SWD 6
Implementacija Slika 7.4 Podmodel SWD

Ovo je generiki model te sadri opis svake aktivnosti i dokumenta za sve mogue projekte. Za odreeni projekt treba odrediti: koje aktivnosti su potrebne za realizaciju projekta; koji proizvodi se trebaju generirati unutar opsega projekta.

Takoer, za odreeni projekt je potrebno ponititi neke proizvode i neke aktivnost, odgovarajue ponitenje naziva se krojenje. Glavna aktivnost krojenja je osigurati da napor uloen u svaki projekt odgovara zahtjevima ili odreenoj situaciji. Krojenje u V-Modelu se sastoji od dva koraka: 1. opeg odreivanja svih relevantnih aktivnosti i proizvoda na poetku projekta (ugovorno krojenje); 2. odreivanja aktivnosti i proizvo da tijekom realizacije projekta utvrenih na poetku svake glavne aktivnosti u odnosu na pojedinanu situaciju (tehniko korojenje). Ugovorno krojenje rezultira u definicji svih aktivnosti i proizvoda relevantnih za projekt. Svaki proizvod kao i svaka aktivnost se u V-Modelu opisuje samo jedanput, iako se oni mogu pojaviti i vie puta u aktualnom projektu. Tehniko krojenje se odnosi na konkretne trenutne aktivnosti i proizvode. Tako se na pr. Prethodni dizajn odnosi na prethodni dizajn konkretne konfiguracijske jedinice softvera (SWCI). Prema tome, krojenjem se odabiru procesi za aktivnosti i proizvode specifinog projekta u smislu ponitavanja uvjeta za aktivnosti, ili u smislu krojenja formi za razliite vrste projekata. Za odreivanje aktivnosti i proizvoda potrebno je: odredti klasu projekta (admistrativni, tehniki/znanstveni ili standardna aplikacija); odrediti veliinu projekta; odabrati odgovarajuu formu prema vrsti i veliini projekta; provjeriti uvjete implementacije.

A modeli
Za razliku od U modela, A modeli ivotnog ciklusa softvera su vrlo detaljni. Koriste se u uvjetima gdje je potrebno automatizirati specifine aktivnosti ili koristiti normirane metode ili procedure za izoenje odreenih operacija. Na toj razini potrebne su precizne definicije podataka, precizni prikaz tijeka informacija, procedure koje koristi korisnik itd. Definicije A procesa su esto ugraeni u norme procesa; oni se mogu tretirati kao via razina apstrakcije U ili W modela procesa. Jedna od najvanijih toaka tijekom procesa razvoja softvera je da mora postojati stalna opreznost od maguih greaka. U svrhu preventive, koristi se tehnika verifikacije i validacije (V&V).

Verifikacija i validacija (V&V) softvera

Verifikacija softvera znai: 1) Proces utvrivanja da li proizvodi u nekoj fazi ivotnog ciklusa razvoja softvera zadovoljavaju zahtjeve uspostavljene tijekom prethodne faze; 2) Formalni dokaz korektnosti programa; 3) Akt revidiranja, nadzora, testiranja, kontrole, auditiranja ili na drugi nain uspostavljenih i dokumentiranih postupaka, da li dijelovi, procesi, usluge ili dokumenti odgovaraju specificiranim zahtjevima (ANSI/ASCQ A3-1978). Verifikacija je od primarne vanosti za osiguranje kvalitete softverskog proizvoda. Aktivnosti verifikacije za projekt trebaju odraavati stupanj kritinosti softvera i kvalitetu uspostavljenih zahtjeva. Proces verifikacije ivotnog ciklusa softvera je prikazan na slici 7.5. Zahtjevi na projekt Definicija korisnikih zahtjeva dkz svv/dz Definicija zahtjeva na sotver dzs svv/ad Arhitekturni dizajn ad svv/dd Detaljni dizajn Proizvodi Aktivnosti Verifikacija dd SVV/JT svv/dd Jedinino testiranje Kompajlirani moduli SVV/IT Integracijski test Testirani modul SVV/TS Test sustava Testirani podsustav SVV/TP Prihvaeni softver Test prihvatljivosti Testirani sustav

Kodiranje

Slika 7.5 Verifikacija ivotnog ciklusa Validacija znai: Proces evaluacije softvera na kraju razvojnog procesa u svrhu osiguranja udovoljavanju zahtjevima na softver. Aktivnosti verifikacije:

tehniki pregledi i inspekcije trasiranje jedinino testiranje integracijsko testiranje prihvatno testiranje auditiranje

Tehniki pregledi i inspekcije Tehniki pregledima se evaluiraju specifini elementi softvera osiguravajui menaderima evidenciju: da elementi (dokumentacija, kod,..) odgovaraju specifikaciji odreenoj u prethodnoj fazi; da su elementi proizvedeni premaprojektnim normama i procedurama; da su promjene pravilno implementirane, te da imaju utjecaja samo na ona podruja sustava identificirana specifikacijom promjena. Trasiranje Trasiranje zahtjeva da svaki input pojedine faze razvoja bude trasiran prema outputu dotine faze. Tijekom ivotnog ciklusa potrebno je trasirati: korisnike zahtjeve prema zahtjevima na softver i obratno; zahtjeve na softver prema opisu softvera i obratno; jedinino testiranje prema detaljnom dizajnu i obratno; integracijski test prema glavnim komponentama arhitekture i obratno; test sustava prema zahtjevima na softver i obratno; test prihvatljivosti prema korisnikim zahtjevima i obratno. Testiranje Testiranje je proces evaluacije sustava ili komponenata sustava u svrhu: potvrivanja da su zahtjevi zadovoljeni; identifikacije razlika izmeu oekivanih i aktualnih rezultata. Testiranje ukljuuje slijedee aktivnosti: planiranje opeg pristupa i dodijeljivanje resursa; detaljiziranje opeg pristupa za razliite vrste testiranja u dizajnu testiranja; definiranje inputa, predvienih rezultata i uvjeta provedbe u specifikaciji sluajeva testiranja: odreivanje aktivnosti testiranja po pojedinim osobama u procedurama testiranja, opis provedbe i rezultati testiranja u izvjetaju testiranja. Testiranje se moe definirati kao: Usporedba izlaza prema oekivanoj normi. Slijed testiranja je: definiranje oekivanog izlaza (output) unos odgovarajueg ulaza (input) dobivanje izlaza usporedbe prema oekivanom izlazu upozorenje ako usporedba ne daje oekivanu veliinu Auditiranje Audit u smislu V&V je neovisni pregled u svrhu procjene udovoljavanja softvera na zahtjeve, specifikacije, temeljnice, norme, procedure, instrukcije, ugovornim i licencnim zahtjevima.

Saetak
Softversko inenjerstvo je disciplina koja ukljuuje tri glavna elementa metode, alate i procedure, te koja menaderima omoguava kontrolu procesa, a praktiarima daje temelje za uzgradnju kvalitetnog softvera. Modeli procesa razvoja softvera definiraju se na U, W i A razini. Vodopadni model i spiralni model su najpoznatiji i najee koriteni U modeli procesa. V-Model postao je u njemakoj norma za razvoj vojnog i komercijalnog softvera. Verifikacija i validacija softvera provodi se u srhu preventive od moguih greaka tijekom procesa razvoja softvera. Aktivnosti verifikacije ukljuuju: (1) tehnike preglede i inspekcije, (2) trasiranje, (3) jedinino testiranje, (4) integracijsko testiranje, (5) prihvatno testiranje, i (6) auditiranje.

8
Modeliranje procesa razvoja softvera
Meusobne unutarnje veze izmeu kvalitetnog proizvoda ili usluge, i kvalitete procesa, vode ka potrebi usavravanja procesa. Usavravanje procesa zahtjeva analizu postojeih procesa i specifikaciju procesa koji je funkcijski jednak ranijim procedurama, kompatibilan je s organizacijom, i koji se moe menedirati u svrhu stalnog poboljavanja. Aktivnosti analize i usavravanja se grupiraju modeliranjem procesa. Modeliranje procesa moe znaajno doprinijeti provedbi procjene i usavravanja procesa. U softverskom inenjering kao i u drugim industrijama, kvaliteta proizvoda je usko povezana s kvalitetom proizvodnog procesa. Problemi softverskog inenjeringa mogu se svesti na slijedee: softverski proizvod je apstraktan i kompleksan proizvodni proces vezan je prvenstveno uz ljude i greke ljudskog faktora industrija softvera je nesazrela i nestabilna procesi su slabo dokumentirani razvojni procesi iziskuju kolektivni napor to uzrokuje probleme koordinacije i konzistencije.

U kompleksnom procesu razvoja softvera mnogi faktori do izraaja, potreban je globalni pristup rjeavanju problema. Koordinirano koritenje softversko inenjerskih metoda, tehnika i alata omoguava sveobuhvatni pristup kontroli trokova, procjeni vremena i performanci softverskog proizvoda.

Odvajanje procesa
Industrijska zrelost iskazuje se sposobnou odvajanja razvojnog procesa od specifinosti koje se odnose na proizvodnju pojedinanog proizvoda. Takav odvojeni proces djeluje kao model procesa. Odvajanje nije jednostavno, s obzirom da je potrebno odluiti koje karakteristike pojedinanog procesa su specifine za pojedinani proizvod, a koje karakteristike se mogu smatrati relevantnim za model procesa, tako i za budue procese.

Koncepcijski, odvaja se TO od KAKO (u opem obliku). Jasno je da je potrebno odluiti izmeu dva opisa procesa jednog koji pokriva sve vrste proizvoda, ali ne i specifinosti pojedine klase proizvoda i ogranienog opisa koji se ne moe primjeniti na vei broj klasa proizvoda. Model procesa ima nekoliko prednosti: isti model procesa se moe primjeniti na razliite proizvode mogue je analizirati razloge procesa o prednostima i/ili nedostacima odreenih metoda i aktivnosti proces se moe unaprijediti temeljeno na iskustvu. Odvajanje procesa se temelji na iskustvu od prijanjih procesa, uz neki metodoloki koncept, kao to je to na pr. izvedeno u normi ISO 9000. U svrhu opisa procesa preko modela procesa potrebno je nekoliko komponenata (slika 8.1): Vrsta rezultata: Opisuje se meurezultat i krajnji rezultat razvojnog procesa. Dinamika struktura rezultata: Na openiti nain opisuje se kako rezultati ovise jedan o drugome (npr. modul objekta je kompilacija izvornog modula). Vrste aktivnosti: Opisuju se elementarni koraci razvojnog procesa. Aktivnosti koriste rezultate za izvedbu daljnjih rezultata. Njihov opis implicira koritenu metodu. Dinamika struktura tijeka poslova: Opisuje se dinamiki odnos vrsta aktivnosti Vjetine / znanja: Definiraju se vjetine i znanja osoba koje obavljaju specifine aktivnosti. Alati: Opisuju se potrebni alati. Ukljuivanjem alata u modele procesa omoguava se njihova automatizacija. Statika hijerarhija

T K O

Alat

Vjetina / Znanje potrebe

A K O

Vrste aktivnosti

Dinamika Struktura tijeka poslova

definira dinamike odnose

T O

Vrsta rezultata definira razvojni odnos

Dinamika struktura rezultata

Slika 8.1 Kaskadni model softverskih procesa Neke komponente takoer imaju svoju statiku hijerarhiju; na pr. alati imaju pod-alate i sl. Treba napomenuti da govorei o modelu, govorimo samo o vrsti komponenata, za konkretni projekt one trebaju biti navedene. Model procesa treba ukljuivati i druge relevantne procese kao

to su to: upravljanje kvalitetom, upravljanje projektom itd. Modeli procesa idu dalje od modela ivotnog ciklusa softvera. Modeli ivotnog ciklusa softvera prvenstveno definiraju nekoliko faza razvojnog procesa i meu-rezultata, bez opisivanja detaljnih koraka unutar svake faze. Modeli procesa daju detaljne opise procesa, uz detaljne opise posrednih proizvoda i njihova odnosa prema pojedinim aktivnostima. Tako npr. tipini IBM-ov model procesa ADPS ima 180 vrsta aktivnosti i oko 200 vrsta rezultata. Zbog visoke razine detaljiziranosti modeli procesa zahtjevaju io opis odreen metode razvoja.

Okoli softverskog inenjerstva

Modeli procesa rezultiraju u opsenoj dokumentaciji, pri tome je naravno problem koritenja te dokumentacije, jer tijekom projektiranja projektanti jednostavno nemaju vremena i nee koristiti dokumentaciju. Rjeenje je koritenje formaliziranih modela procesa koje moe interpretirati raunalo. Mehanizam se naziva interpretator procesa ili procesni stroj. Jedna od njegovi aktivnosti je voenje korisnika preko modela procesa kroz razvojni proces. Interpretator procesa omoguava razliite funkcije za korisnika: interpretiranje modela procesa definiranje potrebnih alata administriranje meurezultata i krajnjeg rezultata.

Okoli u kojem djeluje procesni stroj, model procesa i alati, naziva se okoli softverskog inenjeringa, funkcije okolia softverskog inenjeringa su prikazane na slici 8.2.

Repozitorij

administriranje Model procesa proizvodi koristi

koristi CASE - alati poziv

Proces razvoja softvera odreivanje interpretacija

kontrole
(Procesni stroj) Interpretator procesa

Slika 8.2 Glavne funkcije okolia softverskog inenjerstva S perspektive korisnika, okoli softverskog inenjerstva ima strukturu prema slici 8.3. Model procesa Razvoj

Navigacija Procesni stroj (Interpretator procesa)

KORISNIK

Rezultat

administriranja

Repozitorij

CASE alati Korisniko Suelje

Model procesa opisuje namjeravani proces Procesni stroj vodi i kontrolira razvojni proces CASE alatima obavljaju se pojedinani razvojni poslovi Repozitorij sadri sve meurezultate i krajnje rezultate i njihove odnose Korisniko suelje osigurava prikladnu prezentaciju korisniku. Slika 8.3 Komponente okolia softverskog inenjeringa

Korisnik obavlja nekoliko aktivnosti: Navigaciju: odluuje to uraditi slijedee, Razvoj: obavljajui kreativan dio softverskog inenjeringa, koristei postojee CASE alate, Administriranje rezultata: posao obavlja interpretator procesa (procesni stroj).

Postojei modeli procesa

Neki od postojeih modela procesa postali su de-facto norme u nekim zemljama ili u nekim industrijskim segmentima. Nie su navedeni neki modeli: ADPS (Application Development Project Support) je okoli softverskog inenjeringa s vrlo kompleksnim modelom procesa (180 vrsta aktivnosti), opisujui razvoj, osiguranje kvalitete i upravljanje projektom, SSADM (Structured System Analysis and Design Method) je de-facto norma u Velikoj Britaniji. Model procesa je vrlo detaljan, poglavito u formi dijagrama tijeka podataka s pridruenim tekstom. U model su ukljueni aktivnosti razvoja, osiguranja kvalitete I upravljanja projektom, ESA (European Space Agency) Model satoji se od skupine dokumenata koji u pisanoj formi opisuju razvojni proces, V - Model je industrijska norma u Njemakoj. Osim modela razvoja softvera, norma takoer ukljuuje osiguranje kvalitete, upravljanje projektom i kontrolu konfiguracije softvera. Model je opisan u poglavlju 7.3.

Saetak

Meusobne veze izmeu kvalitete proizvoda i kvalitete procesa vode ka potrebi usavravanja procesa. Modeliranje procesa znaajno doprinosi mogunosti procjene i usavravanja procesa. Model procesa ima slijedee prednosti: (1) isti model se moe primijeniti na razliite proizvode, (2) proces se moe analizirati, i (3) proces se moe unaprijediti. Mehanizam koritenja formaliziranih modela procesa koje moe interpretirati raunalo naziva se interpretator procesa. Neki od razvijenih modela procesa postali su de-facto norme u nekim zemljama ili nekim industrijskim granama, kao to je to SSADM u Velikoj Britaniji, ili V-Model u Njemakoj.

9 Usavravanje procesa razvoja softvera

Osnovni motiv za uvoenje modela procesa je saznanje da kvaliteta razvojnog procesa snano i pozitivno djeluje na kvalitetu softverskog proizvoda. To je ujedno i izazov za usavravanje samog procesa. U zadnjoj dekadi objavljeno je nekoliko koncepata mjerenja kvalitete procesa razvoja softvera. Metoda CMM (Capability Maturity Model) razlikuje pet razina zrelosti procesa, od inicijalne do optimizirajue razine.

Prednosti opisa modela procesa

Evidentno je da koritenje najbolje prakse, temeljene na modelu procesa, je klju uspjeha softverske industrije i rjeenje problema stalne krize softvera. Brojne su prednosti koje se mogu poluiti iz formalnog opisa modela procesa, neke od njih su: nain na koji e se projekt odvijati je opisan prije poetka samog projekta, projekt se moe lake planirati, procesi postaju transparentni, procesi se mogu usavriti to je neophodni preduvjet za punu zrelost razvoja softvera, rezultirajui proizvod ima bolju kvalitetu, proces se moe certificirati to daje bolji kredibilitet organizacije. Saimajui gornje, moe se zakljuiti da je Model procesa centralna toka kontrole proizvodnje , i usavravanja razvoja softvera.

Razine zrelosti procesa

Procesi razvoja softvera mogue je kontrolirati, mjeriti i usavravati. Iz tog razloga proces definiramo kao niz zadataka / poslova koji, ako se pravilno provedu proizvode eljeni rezultat. Drugim rijeima, djelotvoran proces razvoja softvera treba razmotriti sve odnose potrebnih zadataka / poslova, koritene metode i alate, te znanja, vjetine i motiviranost osoba ukljuenih u projekt. Koraci unapreenja procesa

U svrhu unapreenja razvojnog procesa softvera organizacija treba provesti est osnovnih koraka (Humphrey, 1990): 1. 2. 3. 4. 5. 6. shvatiti postojei status razvojnog procesa softvera razviti viziju eljenog procesa uspostaviti listu poslova za potrebno unapreenje procesa, po prioritetima izraditi plan aktivnosti osigurati resurse za provedbu plana poeti ponovno od toke 1.

Karakteristike razina
Pet je razina zrelosti procesa kako je to prikazano na slici 9.1, sa slijedeim karakteristikama: 1. Inicijalna razina: organizacija djeluje ad-hoc, bez formaliziranih procedura, procjena trokova i projekt menedmenta. U takvim uvjetima organizacija je kaotina i nepredvidiva. Uspjeh projekata iskljuivo ovisi znanju i iskustvu pojedinaca. 2. Ponavljajua razina: uvedene su tehnike menadmenta omoguavajui kontrolu projekata. Organizacija je sposobna menedirati nove situacije temeljeno na prijanjim iskustvima. Nove situacije (kao na pr. Uvoenje nove tehnologije) moe izazvati veliki rizik. 3. Definirajua razina: Organizacija poboljava svoje performance definiranjem i dokumentiranjem procesa. Definirani procesi se mogu analizirati i usavravati. 4. Menedirana razina: Poinju se upotrebljavati kvantitativna mjerila za kontrolu ouputa projekata. Primjenjuje se princip statistike kontrole procesa omoguavajui usavravanje kvalitete i poveanje uinkovitosti. 5. Optimizirajua razina: Organizacija upotrebljava mjerila za utvrivanje i odstranjivanje kroninih uzroka slabih performanci. Procesi se kontinuirano usavravaju pridonosei kvaliteti i uinkovitosti.

Optimirajua razina

Razina 5

Kontrola procesa Upravljana razina Razina 4

Mjerenje procesa Definirana razina Definiranje procesa Ponavljajua razina Razina 3

Razina 2 Osnovne kontrole menadmenta Inicijalna razina Razina 1 Slika 9.1 Razine zrelosti procesa

Opis razina zrelosti

1. Inicijalni procesi (Razina 1) - Na ovoj prvoj razini organizacija djeluje bez formaliziranih procedura, bez procjene trokova i planova projekta. Softverski alati nisu dobro integrirani u procese niti se uniformno upotrebljavaju. Ipak, neke organizacije na ovoj razini mogu imati odreene formalizirane procedure za planiranje i trasiranje radova, ali ne postoji menaderski mehanizam kojim bi osigurala njihova uporaba. Da bi organizacija sa razine 1 dola do razine 2 potrebno je uspostaviti: Menedment projekata Planiranje projektima Trasiranje projekata Menedment podugovaraa Osiguranje kvalitete softvera Menedment promjena i konfiguracije softvera.

Prema tome, organizacije na inicijalnoj razini mogu unaprijediti svoje performance instituiranjem osnovnih kontrola projekta; od toga, najvanije su: menadment projekata, osiguranje kvalitete i menedment promjena. Glavna uloga menadmenta projekata je kontrola provedbe radova na projektima. Projekt menadment zapoinje sa sagledavanjem opsega poslova Za svaki, pa i vrlo mali softverski projekt slijedi izrada plana projekta, uspostavljanje redoslijeda izvravanja radova i osiguranje potrebnih resursa. Osiguranje kvalitete treba osigurati da se radovi provode prema planu s ciljem optimizacije kvalitete, cijene i preuzetih rokova. Djelotvorna organizacija za osiguranje kvalitete treba imati neovisnu liniju izvjetavanja prema menadmentu i dovoljno resursa za monitoring performanci planiranja, implementacije i verifikacije. Tipino grupa za osiguranje kvalitete sadrava 3 do 6 posto softtverske organizacije. Kontrola promjena za softver je osnova za poslovodnu i financijsku kontrolu te tehniku stabilnost. Za razvoj kvalitetnog softvera na predvidljiv nain, potrebno je uspostaviti zahtjeve na softver i odravati ih uz razlonu stabilnost tijekom razvojnog ciklusa. Kako su promjene uvijek potrebne, iskustvo pokazuje da je mnoge promjene mogue odgoditi i ukljuiti ih kasnije. Sve promjene je potrebno paljivo kontrolirati i evidentirati u protivnom niti jedan plan nee biti djelotvoran. 2. Ponavljajui procesi (Razina 2) Organizacija je dostigla stabilni proces s ponavljajuom razinom statistike kontrole uvoenjem stroge discipline projekt menadmenta, kontrole trokova, redoslijeda izvoenja radova i kontrole promjena. Snaga organizacije temelji se na iskustvu na slinim prijanjim projektima; problemi mogu nastati kada se organizacija suoi s novim izazovima.

Kljune aktivnosti za prelazak sa razine 2 na razinu 3, tj. na definirajue procese su: uspostavljanje grupe za softversko inenjerske procese ( Software Engineering Process Group - SEPG) , uspostavljanje arhitekture razvojnog procesa te uvoenje metoda i tehnologija softverskog inenjeringa. Grupu za softversko inenjerske procese SEPG u organizaciji ini 1 do 3 posto od ukupnog broja osoba u organizaciji. Procesna grupa ima zadau usavravanja procesa to ukljuuje: definiranje razvojnog procesa, identifikaciju potrebne tehnologije, preporuivanje projekata te izvjetavanje menadmenta o statusu procesa i njegovim performancama. Uspostavljanje arhitekture razvojnog procesa koji opisuje tehnike i menaderske aktivnosti potrebno je za prvilno izvravanje razvojnog procesa. Proces treba biti prilagoen specifinim potrebama organizacije, varirati e, ovisno o veliini i vanosti projekta, kao i o tehnikoj prirodi radova. Arhitektura je strukturna dekompozicija razvojnog ciklusa na poslove, od kojih svaki ima definirane preduvjete, funkcionalni opis i procedure verifikacije. Uvoenje metoda i tehnologija ukljuuje metode dizajniranja, kontrolu dizajniranja i kodiranja, voenje dokumentacije i metode testiranja. 3. Definirani procesi (Razina 3) Na ovoj razini organizacija je definirala proces kao temelj za dosljedne implementacije i bolje razumijevanje to omoguava daljnje usavravanje procesa. Definirani procesi omoguavaju mjerenja specifinih aktivnosti, za to je arhitektura procesa neophodni preduvjet. Bez obzira na snagu definiranih procesa oni su jo uvijek kvalitativni; malo je podataka koji bi ukazivali na to koliko je savren ili djelotvoran proces. Pitanje je vrednovanja mjerenja softverskih procesa i upotreba dobivenih vrijednosti. Cilj daljnjeg usavravanja je kvantificiranje trokova i dobitaka svake aktivnosti procesa. To znai da je potrebno uspostaviti minimalni temeljni skup mjerila procesa za utvrivanje kvalitete i trokovnih parametara za svaki korak procesa. Potrebno je uspostaviti bazu podataka procesa i resurse za menediranje, te odravanje procesa. Potrebni su dovoljni procesni resursi za prikupljanje i odravanje procesnih podataka te iskusni ljudi koji e moi kontrolirati kvalitetu podataka prije nego to uu u bazu podataka, i koji e osigurati metode analize i interpretacije podataka. Nadalje je potrebno procijeniti kvalitetu svakog proizvoda, te izvijestiti menedment gdje nisu zadovoljeni ciljevi kvalitete. Neovisna grupa za osiguranje kvalitete procjenjuje kvalitetu aktivnosti za svaki projekt i trasira njegovo napredovanje projekta prema utvrenom planu za softversko projekta. 4. Upravljani procesi (Razina 4) Organizacija je uspostavila opsena mjerenja i analize procesa. Problem je u visokim trokovima prikupljanja podataka. Kako postoji ogroman broj potencijalno vrijednih mjerenja softverskog procesa, prikupljanje i odravanje tih podataka je skupo. Iz tih razloga potrebno je unaprijed precizno definirati podatke koji e se prikupljati i nain njihove identifikacije. Svrha mjerenja procesnih podataka je da se to bolje upozna razvijeni proizvod kako bi se poluila informacijska baza za poboljanje procesa. Za prijelaz na slijedeu viu razinu potrebno je automatizirati prikupljanje procesnih podataka te ih koristiti za analizu i modifikaciju procesa u svru preventive i poboljanja djelotvornosti procesa. 5. Optimizirajui procesi (Razina 5) Na ovoj najvioj razini organizacija je postavila temelje za kontinuirano usavravanje i optimiranje procesa. Sve do ove razine organizacijamenaderi razvoja softvera bili su usredotoeni na softverski proizvod te na prikupljanje i analizu podataka koji se direktno odnose na proizvod i njegovo poboljanje. Kod optimizirajueg procesa podaci se koriste za usavravanje samog procesa, ija optimizacija pridonosi kvaliteti i

proizvodnosti. Analizom procesa pronalaze se najslabiji elementi koji se potom mogu poboljati. Ova razina osigurava disciplinirani okoli za profesionalni rad, takoer pomae menaderima da uvide gdje je potrebna pomo i kako ljudima osigurati potrebnu podrku, te razvojnim inenjerima omoguava uvid u performance njihova rada kako bi ga mogli usavriti.

SEPG
SEPG (Software Engineering Process Group) je posebna grupa specijalista za razvoj i usavravanje procesa softvera, aktivnosti su /2/: utvrivanje kljunih problema uspostavljanje prioriteta definiranje plana aktivnosti dodijela osoblja provedba treninga i davanje uputstava pokretanje implementacije trasiranje napretka fiksiranje neizbjenih problema

SEPG ima dva osnovna zadatkakoji se provode istovremeno: iniciranje i odravanje promjena procesa te podrka normalnim operacijama. Promjene procesa su bitan dio procesa razvoja softvera. Promjene zahtjevaju od profesionalaca uenje i uvoenje novih metoda. Svaki novi projekt je vei i kompleksniji od prijanjeg. Bez uspostavljenog procesa softvera, projekt nee imati iskustveno organizacijsko temelje i morati e se izgraivati na temelju brojnih pokuaja i greaka. Promjene su prema tome normalni i neprekidni dijelovi softverskog menedementa, uloga SEPG-a je da se te promjene uinkovito primjenjuju. Jedan od glavnih zadataka SEPG-a je uspostavljanje normi procesa to ukljuuje aktivnosti: a) predlaganje prioriteta za razvoj normi, b) osiguravanje da su izvedeni radovi revidirani, c) osiguravanje ukljuivanje korisnika i eksperata, te koordinacija tih grupa, d) pregled i odobrenje normi. Zadatak SEPG-a je takoer i odravanje baze podataka procesa kao glavnog skladita prikupljenih podataka od softverskih procesa i rezultirajuih proizvoda. Kako bi u SEPG trebali biti ukljueni iskusni, kompetentni profesionalci, oni mogu provoditi i kolovanje o: menedmentu kvalitete softvera, metodama dizajna softvera, metodama projekt menedmenta, te nadzoru dizajna i koda. Najvanije za SEPG je da ogranii svoje djelovanje na one aktivnosti koje se mogu provesti brzo i uinkovito.

Saetak
Kvaliteta razvojnog procesa snano i pozitivno djeluje na kvalitetu softverskog proizvoda. U svrhu unapreenja procesa razvoja softvera, organizacija treba: (1) shvatiti postojei status razvojnog procesa, (2) razviti viziju eljenog procesa, (3) uspostaviti listu poslova za unapreenje postojeeg stanja procesa, (4) izraditi plan aktivnosti, (5) osigurati resurse za provedbu plana, i (6) ponovno zapoeti od toke (1), u svrhu kontinuiranog usavravanja.

Pet je razina zrelosti procesa: 1. Inicijalna razina u kojoj organizacija djeluje bez formaliziranih procedura, procjena trokova, i bez projekt menedmenta, 2. Ponavljajua razina pri kojoj je organizacija sposobna menedirati nove situacije temeljeno na prijanjim iskustvima, 3. Definirajua razina gdje su procesi definirani i dokumentirani, a procesi se mogu usavravati, 4. Menedirana razina gdje se poinju upotrebljavati kvantitativna mjerila kontrole outputa projekata, 5. Optimizirajua razina pri kojoj organizacija provodi kontinuirano usavravanje procesa razvoja softvera. SEPG (Software Engineering Process Group) je posebna grupa specijalista za razvoj i usavravanje procesa softvera. SEPG ima dva osnovna zadatkakoji se provode istovremeno: iniciranje i odravanje promjena procesa te podrka normalnim operacijama.

DIO IV Optimiranje procesa 10

Model razine zrelosti procesa
Model razine zrelosti procesa, odnosno, originalno CMM (Capability Maturity Model) rezultat je istraivanja na SEI (Software Engineering Institute) na Carnegie Mellon University u Pittsburgu SAD. Poetno, model je osnovan sa svrhom podrke napretku prakse softverskog inenjeringa u podruju usavravanja kvalitete softversko-ovisnih sustava za potrebe US Ministarstva Obrane DoD (Department of Defense). Kasnije su CMM poeli poeli koristiti proizvoai softvera za procjenu vlastitih sposobnosti, i za uspostavljanje ciljeva poboljanja procesa. CMM omoguava mjerenje, odnosno procjenu zrelosti softverskih procesa u organizaciji, te uspostavljanje ciljeva za usavravanje procesa. Temelj metode je koncept kontinuiranog usavravanja procesa slijedom pet razina zrelosti procesa opisanih u prethodnom poglavlju. Strukturu CMM-a ine: a) razine zrelosti procesa, b) kljuna praksa procesa, c) zajednike karakteristike procesa, i d) kljuna praksa procesa. Organizacijska zrelost procesa procijenjuje se postupkom koji se naziva asesment. Asesment se moe koristiti za odabir dobavljaa softvera za specifini ugovor ili za poetak programa usavravanja procesa. Aktivnosti asesmenta su:

a) saznanje o radu organizacije, b) utvrivanje glavnih problema, c) preporuke o promjeni procesa. Asesment zavrava konanim izvjeem o asesmentu u kojem se daje prikaz stanja, odnosno zrelosti procesa, te preporuuju podruja koja treba poboljati.

Struktura CMM-a
Struktura CMM-a ukljuuje slijedee elemente, kako je to prikazano na slici 10.1: razine zrelosti procesa kljuna podruja procesa zajednike karakteristike procesa kljuna praksa procesa

Razine zrelosti Ukazuju na Sadre

Sposobnost procesa

Kljuna podruja procesa Arhiviraju Organizirani s

Ciljeve Ciljeve

Zajednikim karakteristikama Adresiraju Sadre

Implementaciju Implementaciju

Kljuna praksa Opisuju

Implementaciju

Slika 10.1 Struktura CMM Razine zrelosti opisuju postojeu zrelost organizacije, tj. sposobnost organizacije da polui rezultate u oekivanom opsegu,

U svrhu dosizanja sposobnosti za svaku razinu, organizacija treba implementirati skup klastera* aktivnosti; na pr. kljuno podruje procesa na razini 2 je planiranje projekta (* klaster orig. eng.: cluster; znai: roj, jato, grozd; tj. fig.: grozd aktivnosti), Svako kljuno podruje procesa (KPP) omoguava dostizanje definiranih ciljeva: na pr., za KPA planiranja projekta cilj je: procjena softvera je dokumentirana u svrhu upotrebe u planiranju i trasiranju softverskog projekta, Ciljevi unutar svakog KPP se postiu implementiranjem skupine povezanih aktivnosti pod nazivom kljuna praksa; na pr. kljuna praksa unutar kljunog podruja procesa projekt menadmenta je procjena opsega radova za softverski proizvod se izvodi prema dokumentiranim procedurama, Kljuna praksa u svakom KPP-u je organizirana u klase pod nazivom zajednike karakteristike, koje adresiraju implementaciju kljunih podruja procesa. Zajednike karakteristike su indikatori uinkovitosti KPP-a.

Zajednike karakteristike kljunih podruja procesa Svaka CMM razina zrelosti sadri kljuna podruja procesa KPP, sa zajednikim karakteristikama: Obveza izvrenja: opisuju se aktivnosti koje organizacija treba provesti za uspostavu procesa razvoja softvera i za osiguranje da e se one provoditi, Sposobnost izvrenja: opisuju se preduvjeti koji moraju postojati kako bi se osiguralo da e se procesi pravilno izvravati, Izvravanje aktivnosti: opisuju se uloge i procedure za izvravanje aktivnosti, Mjerenje i analiza: opisuju se mjerenja i analize, te odreuju statusi izvrenih aktivnosti, Verifikacija izvrenja: opisuju se procesi procesi kojima se osigurava da su performance izvrenih aktivnosti u skladu s dogovorenom politikom i uspostavljenim procedurama.

Procjena i usavravanje procesa

Organizacijska zrelost procesa moe se procijeniti/evaluirati koritenjem modela CMM. Evaluacija se naziva asesment* (*prema eng. Assess, znai odmjeriti, odrediti, procijeniti). Asesment se moe koristiti za odabir dobavljaa softvera za specifini ugovor ili za poetak programa usavravanja procesa. Kada se asesment koristi za usavravanje procesa, CMM slui za uspostavljanje ciljeva usavravanja, i za utvrivanje aktivnosti usavravanja kako bi se postigli utvreni ciljevi. Asesment Usavravanje procesa zapoinje utvrivanjem postojee zrelosti procesa te pokuajem dostizanja slijedee vie razine zrelosti, koja postaje prvi utvreni cilj. Kako bi se ispunili zahtjevi slijedee vie razine zrelosti, organizacija treba implementirati kljuna podruja procesa za tu razinu. Asesment provodi vanjska organizacija certificirana za provoenje asesmenta. Asesirana

organizacija treba odgovoriti (da / ne) na oko 150 pitanja. Za svaku razinu zrelosti postoje kljuna pitanja, potreban je pozitivan skor da za postizanje odreene razinu zrelosti. CMM se koristi ponajvie u USA i Kanadi za vee i velike softverske organizacije (> 200 osoba), dok za male organizacije (< 30 osoba) metoda nije primjenljiva. Metoda daje dobru sliku razine zrelosti organizacije (temeljeno na dostignutoj razini zrelosti), bez detaljnije analize razliitih dobrih i loih elemenata procesa, i isporuuje plan za usavravanje za postizanje slijedee vie razine zrelosti. Faze asesmenta Asesment procesa pomae organizacijama u usavravanju samih sebe prepoznavanjem kritikih problema i uspostavljanjem prioriteta usavravanja. Aktivnosti asesmenta su: a) saznanje o radu organizacije, b) utvrivanje glavnih problema, c) preporuke o promjeni procesa. Asesment obino provodi vanjska organizacija u kojoj su iskusni softverski inenjeri koji imaju iskustvo u provoenju asesmenta. Glavna svrha asesmenta je prepoznati podruja koja moraju imati najvii prioritet za usavravanje, i dati uputstva kako provesti te poslove. Asesment mogu provesti i same organizacije unutar sebe, meutim neke organizacije su pod velikim pritiskom, njihovi menederi mogu biti neiskusni ili je profesionalna razina vrlo niska, tako da je neophodna vanjska suradnja. Tijekom prve faze asesmenta uspostavlja se tim za asesment koji ukljuuje mali tim menedera organizacije koja se asesira i tim vanjske organizacije. Tim menedera asesirane organizacije trebaju sainjavati inenjeri iz nekoliko grupa kao menedmenta projekata, osiguranja kvalitete, programiranja, testiranja i podrke. Provedba asesmenta Nakon upoznavanja opeg ustroja i rada asesirane organizacije, voditelji grupa intervjuiranjem daju odgovore na unaprijed pripremljenu listu pitanja. Intervjuiranje se provodi na sastancima malih grupa za razliite faze procesa razvoja. U otvorenoj diskusiji profesionalci daju svoja vienja i prijedloge u vezi glavnih problema. Na kraju asesmenta tim priprema izvjetaj o prepoznatim problemima u organizaciji. Izvjee o asesmentu Asesment zavrava konanim izvjeem o asesmentu u kojem se daje prikaz stanja, odnosno zrelosti procesa, te preporuuju podruja koja treba poboljati. Kako niti jedna organizacija ne moe provesti vie od nekoliko poboljanja u odreenom vremenu, potrebno je odrediti prioritete i vremenski plan provedbe. Ponovni asesment Asesirana organizacija treba, nakon jedne ili jedne i pol godine ponoviti asesment. Asesment se provodi u svrhu procjene uinjenog napretka i u svrhu uspostavljanje novih prioriteta usavravanja procesa.

Model prijelaza s CMM razine 1 na CMM razinu 2

Po objavljivanju metode CMM provedeno je niz asesmenta u SAD, Kanadi i Japanu. Na temelju prvih asesmenta na 296 projekata u 59 organizacija informatike tehnologije (IT), ustanovljeno je da je preko 80% organizacija na razini zrelosti 1, svega 12% organizacija je dostiglo razinu 2, a 7% razinu 3. Niti za jednu organizaciju ili projekt nije ustanovljena razina zrelosti 4 ili 5. Dugoroni cilj svake IT organizacije bilo bi dostizanje CMM razine 5, kao platforme za uvoenje cjelokupnog sustava upravljanja kvalitetom (TQM). Srednjoroni cilj bio bi dostizanje barem CMM razine 3. Ova razina znai uspostavu sustava osiguranja kvalitete, odnosno to je pretpostavka da je poduzee zadovoljilo minimalne zahtjeve kvalitete prema normi ISO 9000 (ISO 9000-3) i da poduzee moe zatraiti certifikat kvalitete. Kratkoroni cilj bio bi prijelaz s CMM razine 1 na CMM razinu zrelosti 2, koji bi se prema nekim procjenama mogao provesti u roku od 1-2 godine. Ujedno, to je i najtei korak, jer je prijelaz s razine 2 na vie razine ve mnogo laki. Pretpostavke provedbe Da bi IT organizacija prila provedbi prijelaza s CMM razine 1 na razinu 2 pretpostavka je: da je organizacija provela asesment koji je ukazao na razinu zrelosti 1, organizacija eli dostii CMM razinu 2, da organizacija koristi neki od klasinih modela razvoja softvera (na pr. Vodopadni model), da tim zaduen za razvoj (ili SEPG) ima: iskustvo u modeliranju procesa iskustvo o menediranju softverskih projekata iskustvo u razvoju odabranog klasinog modela softvera.

Postupak prijelaza Koraci u prijelazu s CMM razine 1 na razinu 2 su: 1. 2. 3. 4. Izrada scenarija koji opisuje sve aktivnosti prijelaza pridruenih KPP-u i metodu evaluacije, Definiranje modela razvoja ivotnog ciklusa softvera (Vodopadni model), Prikaz, odnosno predloak proizvoda koji e biti rezultat procedura definiranih u toki 3, Izrada liste provjere koja se koristi za trasiranje primjene procedura aktivnosti KPP-a kroz ivotni ciklus softvera, 5. Izrada specifikacije kolovanja i treninga osoblja 6. Prikaz suelja s drugim KPP-a Provedeni asesment ukazao je na jake dobre i slabe strane organizacije za aktivnosti i druge karakteristike pridruene KPP-u. Scenarij ukljuuje izradu i primjenu akcijskog plana za poveanje djelotvornosti slabih strana organizacije i svake pojedine aktivnosti te ostalih karakteristika vezanih uz KPP za CMM razinu 2. Plan takoer predvia i provedbu novog asesmenta, a prvi puta est mjeseci nakon primjene akcijskog plana. Organizacija treba detaljno definirati model razvoja softvera prema nekom od poznatih klasinih modela kao to je to na pr. Vodopadni model, opisan u Poglavlju --. Svaka faza razvoja u modelu

karakterizirana je svojim inputima, outputima, aktivnostima, ulogama i odgovornostima. Odgovornosti su rasporeene na etiri ekipe: Ekipe za pretvorbu (EP) odgovorna za pretvorbu inputa u outpute, Ekipa za menedment konfiguracije (EMK) odgovorna za odravanje konfiguracije sustava provoenjem kontrole promjena i kontrole verzija softvera, Ekipa za menedment projekta (EMP) odgovorna za proraun projekta, izvoenje projekta prema utvrenom redoslijedu Ekipa za osiguranje kvalitete (EOK) Odgovorna za provedbu definiranih procesa i za kvalitetu outputa.

Nadalje, potrebno je definirati: a) Politiku razvoja softvera oitovanje politike rukovodstva iskazom podrke projektu, b) Procedure kontrole dokumenata kontrola verzija dokumenata i kontrola promjena verzija, c) Pregled/reviziju procesa opis minimalnih zahtjeva za reviziju softverskog proizvoda kao rezultata pojedine faze razvoja ivotnog ciklusa softvera uz sudjelovanje: EP, EMK, EMP i EOK. Predloak proizvoda sadri: 1. Plan razvoja softvera plan se moe izraditi prema normi IEEE Std. 730, 2. Iskaz radova pokriva opseg potrebnih radova, svrhu ,ciljeve, ogranienja, pojedinane uloge i odgovornosti projektne ekipe, te popis normi koje e se koristiti, 3. Prikaz strukture radova- struktura razgradnje radova (eng. Work Breakdown Structure- WBS) raslanjuje projekt na elemente, tj. na hijerarhiju definiranih, procijenjenih i trasiranih pojedinanih aktivnosti. Prikaz sadri popis tih elemenata uz pridodijeljene odgovornosti za izvrenje svake aktivnosti, 4. Procjenu rizika rizik u razvoju sustava oznaava razinu nesigurnosti od ne-postizanja svrhe i ciljeva projekta te razinu nesigurnosti od ne-isporuivanja proizvoda u ugovoreno vrijeme prema ugovorenoj cijeni i ugovorenoj razini kvalitete. Liste provjere se izrauje prema odabranom modelu razvoja softvera. Svaka kljuna aktivnost sadri barem jednu listu provjere u kojoj se navode pod-aktivnosti koje treba izvriti svaka ekipa po svakoj fazi modela. Ekipa za provedbu modela prijelaza s razine 1 na razinu 2 treba imati znanja i iskustva u: modeliranju procesa menedmentu projekta procesima softverskog inenejeringa. sustavima osiguranja kvalitete softvera

Saetak
Glavni cilj modela zrelosti procesa (CMM) je procjena zrelosti procesa u organizaciji, te uspostavljanje ciljeva usavravanja. Struktura CMM-a ukljuuje elemente: a) razine procesa, b) kljuna podruja procesa, c) zajednike karakteristike, i d) kljunu praksu. Zrelost procesa procjenjuje se asesmentom koji se moe koristiti za odabir dobavljaa softvera za specifini ugovor ili za poetak programa za usavravanje procesa. Asesment provodi vanjska certificirana organizacija. Asesirana organizacija treba odgovoriti na listu od oko 150 pitanja (odgovori su da/ne). Za svaku razinu zrelosti postoje kljuna pitanja. Konano izjee o asesiranju daje prikaz stanja u organizaciji, tj. ukazuje na dobre i slabe strane procesa, te daje preporuku za poboljanje slabih strana. Ponovni asesment treba ukazati na postignuti napredak i utvrditi nova podruja za usavravanje.

11
Metoda Bootstrap
Bootstrap je Europski odgovor na metodu CMM za odreivanje razine zrelosti procesa. Jedan je od ESPRIT (European Strategic Programme for Research and Development in Information Technology Europski strateki program za istraivanja i razvoj u informatikoj tehnologiji) projekata ija svrha je razvoj metode za asesment softverskog procesa, kvantitativno mjerenje i usavravanje procesa. ESPRIT je jedan od programa namijenjenih tehnolokoj dogradnji europske informatike industrije i tehnolokog obrazovanja. Program je lansiran jo 1984 g. za razdoblje od deset godina s tri osnovna cilja: 1. Promoviranje suradnje na sektoru informatike tehnologije izmeu industrije, sveuilita i istraivakih instituta, na predkompetitivnoj razini, tj. u onoj fazi koja jo ne podrazumijeva proizvodnju komercijalnih trinih artikala, 2. Europsku industriju osigurati s baznim tehnologijama koje su neophodne u trci za dio svjetskog trita, 3. Pridonijeti razvoju i meunarodnom priznanju tehnikih normi na podruju informatike tehnologije Program je imao nekoliko faza, u prvoj fazi ESPRIT I imao je budet od 1,5 milijardi ekua, a realizirano je bilo 227 projekata u 536 poduzea. U drugoj fazi od 1988 g. za razdoblje od pet godina za ESPRIT II bilo je, temeljem ogromnog odziva industrije, rezervirano 3,2 milijardi ekua. Po dovrenju projekta ESPRIT, neki od sudionika koji su koristili metodu Bootstrap uspostavili su meunarodnu organizaciju - Bootstrap Institut za kontinuirano usavravanje metode i usvajanje najnovijih normi za odravanje metode na najmodernijoj tehnolokoj razini.

Pristup Bootstrapa analizi i usavravanju procesa

Tri su paradigme na kojima se temelje asesmenti procesa i metodologije analize procesa: 1. Kvaliteta proizvoda je uvjetovana kvalitetom planiranja i kvalitetom razvojnog procesa, 2. Organizacija je najvanija, a metodologija i metode su vanije od tehnologije, 3. Potrebno je provoditi analize procesa na objektivan i kvantitativan nain. Do sada je objavljen veliki broj normi koje se odnose na softverski inenjering i menedment kvalitete softvera (IEEE, ESA, ISO, SEI). One kombiniraju iskustva mnogih kompanija i organizacija u formi uputstava o tome kako provoditi kontrolne i menadmentske aktivnosti. Pravilo je, da aktivnosti koje nisu pod kontrolom nee rezultirati proizvodom viosoke kvalitete. Neke metodologije analize procesa (npr. CMM) definiraju kljuna podruja procesa i kljunu praksu dajui informacije o neophodnim menaderskim i kontrolnim aktivnostima koje je potrebno provesti za softverski projekt. ISO norme i uputstva definiraju skup atributa procesa koji su neophodni za uspostavljanje okvira sustava kvalitete unutar organizacije. Zadovoljavanjem zahtjeva norme ISO 9000, te prolazei kroz proces certifikacije organizacija moe poluiti certifikat ISO 9000. CMM-ove razine zrelosti i ISO certifikat mogu posluiti kao indikatori kvalitete procesa u organizaciji. Ipak i CMM i ISO ne daju dovoljnu kvantitativnu evaluaciju razvojnog i menaderskog procesa. CMM izraunava jednu razinu zrelosti za cijeli proces, dok ISO certifikacija ne daje kao rezultat skup kvantitativnih mjera. Naravno organizacije trebaju metodologiju koja e omoguiti mjerenje kvantitativnog profila koji e jasno izraziti jake i slabe strane procesa razvoja softvera. Metoda Bootstrap omoguava mjerenja mnogih kljunih atributa procesa u svrhu dobivanja detaljnih informacija o slabostima i jakostima procesa. Te informacije se potom mogu iskoristiti za uspostavljanje plana usavravanja organizacije kao i razvojnog i menederskog procesa. Povratna veza procesa i proizvoda Prema prvoj paradigmi, poboljanje softverskog proizvoda moe se uinkovito provesti poboljanjem procesa razvoja softvera ukljuivi organizaciju, menedment i razvoj. Ovaj iskaz je ispravan ali i nepotpun, jer metode analize procesa ne ukljuuju i statistika mjerenja koja bi ilustrirala oekivane vrijednosti prizvoda temeljene na odreenim poboljanjima procesa. Metodom Bootstrap izgraen je model koji omoguava verifikaciju aktivnosti usavravanja procesa. Pravilo O>M>T Druga paradigma govori da je organizacija (O) najvanija, a metodologije i metode (M) su vanije od tehnologije (T). Ovakovu hipotezu prihvaa Bootstrap; drugim rijeima prije bilo koje investiciju u tehnologiju, treba rijeiti pitanje organizacije razvoja, i pitanje kako izgraditi rjeenja tj. metodologije i metode. Formula prioriteta po razinama i redoslijedu jest: O>M>T

Formula odgovara filozofiji (W. Humphrey): potencijalni izlaz iz stalne krite softvera je u promjenama, tj. u usavravanju organizacije i procesa menediranja, razvoja i odravanja softvera. Projekt bez dobre organizacije je osuen na propast; takoer nee pomoi ni nabava najnovije tehnologije ako nema razraene i prihvaene metodologije razvoja. U aritu interesa Bootstrapa je SPU (engl. Software Producing Unit Jedinica za proizvodnju softvera) tj. malo, vee ili veliko poduzee; ili informatiki odjel u velikoj ili veoj kompaniji gdje se razvijaju i odravaju softverski proizvodi. SPU definira politiku kvalitete, procjenjuje i osigurava resurse, definira norme, praksu, metodologiju i metode koje se primjenjuju na softverske projekte. Projekt je entitet unutar SPU-a koji ima jasno definirani cilj i uinkovito koristi dostupne resurse za proizvodnju odreenog softverskog proizvoda prema utvrenom razvojnom planu. Metoda Bootstrap procjenjuje SPU i projekte unutar SPU-a. Evaluira da li SPU osigurava sve neophodne resurse, te koliko djelotvorno projekti koriste dostupne resurse. Mjerenja i evaluacija metodom Bootstrap Prvi korak kod usavravanja procesa je bolje razumijevanje. Mjerenje i statistike kontrole kvalitete mogu u veliko pomoi kod tog razumijevanja. Mjerenje dovodi do bolje kontrole procesa i do poveanja predvidivosti. Svako razvojno okruenje sastoji se od faktora procesa (mjerljivih Bootstrapom), faktora proizvoda, faktora problema, faktora ljudi, procedura, metoda i tehnologije. Metrike softvera definiraju standardni nain mjerenja nekih od navedenih faktora, kao na pr. veliinu, trokove, napore, profil ekipe za razvoj, okolia, tekoa, komunikacije idr. Metrike softvera pomau u planiranju, menadiranju i monitoringu projekata, boljem razumijevanju softverskog procesa, mjerenju napredovanja, identifikaciji kompleksnih softverskih elemenata, omoguavaju implementaciju programa kvalitete, i drugo. Postoje tri vrste metrika: 1. 2. 3. metrike proizvoda, metrike procesa i metrike resursa.

Svaka vrsta sadri brojne entitete s atributima koji se mogu mjeriti metrikama i ciljevima koje je mogue dosei. Metrike procesa mjere aktivnosti razvojnog procesa (na pr. napore testiranja, uinkovitost); Metrike proizvoda odnose se na atribute proizvoda koji nastaju tijekom procesa (na pr. kompleksnost modula, koliina dokumentacije, odnos greaka); Metrike resursa se mogu promatrati kao statike metrike procesa koje opisuju statike faktore koji djeluju na proces softvera (na pr. profil razvojnog tima, struktura tima).

Bootstrap koristi metrike procesa za mjerenje pojedinanih atributa kvalitete procesa najvie razine kao to su to: menadment projekta i menadment kvalitete. Metoda identificira pojedinane atribute procesa organizacije razvoja softvera ili pojedinanog projekta, i za svaki atribut kvalitete procesa izraunava se razina zrelosti. Ovo omoguava evaluaciju razine zrelosti SPU-a ili projekta, kao i primjenu odreenog atributa kvalitete procesa.

Bootstrap model kvalitete procesa

Model kvalitete procesa prema metodi Bootstrap prikazan je na slici 11.1

Proces Organizacija
Sustav kvalitete Menadment resursima Odabir osoblja Metodologija Trening

Tehnologija
Za svaki atribut metodologije postoji odgovarajui atribut tehnologije

Funkcije neovisne o ivotnom ciklusu sofvera Modeliranje procesa Menadment projekta Kontrola procesa Menadment kvalitete Mjerenje procesa Menadment rizika Menadment dobavljaa Menadment konfiguracije i promjena

Funkcije procesa

Funkcije ivotnog ciklusa softvera Model razvoja Posebni procesi Specifikacija Dizajn Prototipiranje Detaljni dizajn Implementacija Testiranje jedinice Integracijsko testiranje Prihvatno testiranje Odravanje

Slika 11.1 Model kvalitete procesa Bootstrap razlikuje: a) organizacijske, b) metodoloke i c) tehnoloke atribute. Organizacijski atributi sadre: sustav kvalitete, menadment resursima i trening osoblja. Metodoloki atributi su ralanjeni na atribute menedmenta (atributi neovisni o ivotnom ciklusu softvera), atribute procesa, i atribute ivotnog ciklusa softvera. Za svaki metodoloki atribut postoji odgovarajui tehnoloki atribut tako da je mogue mjeriti uinkovitost metodologije i tehnoloko dostignue.

Sustav kvalitete i organizacija Bootstrap ukljuuje koncept procesne grupe softverskog inenjeringa (SEPG) prema metodi SEI/CMM, i koncept dokumentacije osiguranja kvalitete prema ISO 9000-3, kako je to prikazano na slici 11.2.

Proces Organizacija Metodologije Tehnologije

Planiranje i razvoj

Proizvod Funkcionalnost Pouzdanost Slijedivost itd.

Test prihvatljivosti Plan testiranja Zapisi kvalitete Podaci testa Prijenos proizvoda Kupac Povratna veza

Asesment procesa i analize

Usavravanje i uspostavljanje najbolje prakse

Evaluacije, mjerenja, kontrole, provjera koritenja normi

SEPG

SQA
veza Problemi

Slika 11.2 Koncepti SEPG i ISO 9000-3 SEPG periodino procjenjuje softversko inenjerske procese i (1) razvija plan aktivnosti za usavravanje, te (2) uspostavlja norme i procedure najbolje prakse za procese i proizvode. SEPG je takoer odgovorna za identifikaciju i promociju potreba organizacije, te za prijenos nove tehnologije i metodologije u menadmentske i razvojne procese. Prema ISO 9000-3 dokumentacija osiguranja kvalitete sadri dva osnovna zahtjeva. Prvo, organizacija (SPU prema metodi Bootstrap) treba izraditi prirunik kvalitete (PK) koji opisuje: (1) politiku kvalitete, (2) ciljeve OKS-a, (3) organizacijske zahtjeve i odgovornosti menadmenta, (4) definirane uloge OKS-a, (5) funkcije OKS-a, te (6) prikaz formata i strukture plana OKS-a. Drugo, za svaki projekt izrauje se plan osiguranja kvalitete (OKS) temeljen na priruniku kvalitete. Sadraj plana OKS prikazan je u Poglavlju 3.3.4.1. Ekipa za osiguranje softvera (SQA) odgovorna je za provjeru koritenja najbolje prakse koju uspostavlja SEPG. O problemima koje otkrije SQA izvjetava SEPG koji treba razrijeiti probleme.

Atributi menedmenta

Menedment je definiran kao sustav normi, procedura, prakse i tehnologije koje omoguavaju planiranje, organiziranje, upravljanje i kontrolu, potrebnih za uspjeno menadiranje softverskim inenjerskim projektima. Prema metodi Bootstrap atributi menedmenta ukljuuju: (1) (2) (3) (4) (5) menedment projektima, menedment resursima, menedment konfiguracijom softvera i promjenama, menadment kvalitetom, i menedment rizika.

Menedment projektima obuhvaa neophodne planske aktivnosti kao to je to: uspostava redoslijeda razvoja projekta, planove menedmenta projekta, planove menedmenta konfiguracije i promjena, planove kvalitete, i planove testiranja. Planove je potrebno stalno aurirati kako bi u svakom trenutku odraavali aktualno stanje. Projektna knjiga pri tome sadri format, strukturu i sadraj svakog plana kao temelj za izvravanje planskih aktivnosti. Menedment resursima obuhvaa metode i norme za procjenu potrebnih resursa kao to su to: trokovi, potrebno osoblje, softver i hardver. Obuhvaa se takoer i edukacija inenjera kao i nain odabira najprikladnijih osoba za projekt. Menadment konfiguracijom softvera i promjenama je proces identificiranja i definiranja konfiguracijskih elemenata sustava, kontrola elemenata za isporuku i kontrola tih elemenata kroz faze razvoja i odravanja, izvjetavanja o statusu konfiguracije i zahtjeva za promjenama, te verificiranja zgotovljenosti i tonosti elemenata konfiguracije. Menedment kvalitete obuhvaa: (a) aktivnosti izvjetavanja, (b) mehanizme za trasiranje uzroka greaka prema izvjetajima, (c) mehanizme za trasiranje zgotovljenja aktivnosti prema izjvetajima, (d) praksu testiranja, te (e) kljune uloge osoba u procesu isporuke proizvoda. Menedment rizika je proces identificiranja, procjenjivanja i dokumentiranja rizika za projekt i za proizvod pri izmjenama procesa razvoja i softverskog proizvoda. Menedment rizika obuhvaa: identifikaciju nestabilnih dijelova specifikacije sustava i softvera, te uputstva za rjeavanje problema.

Atributi procesa
Modeliranje / opis procesa Nakon normiziranja i dokumentiranja najbolje prakse, ona se koristi za sve projekte, a povremeno je procjenjuje i dopunjava SEPG. Model procesa softvera ukljuuje i definiciju specifinih procesa, te model kvalitete proizvoda uz popis faktora kvalitete. Za svaki faktor kvalitete definira se skup SQA aktivnosti. Mjerenje procesa i proizvoda Razvoj softvera zahtjeva mjerenja procesa i proizvoda. Neki od primjera mjerenja procesa su: status redosljeda projekta, procjena proizvodnost, utroeni napor po pojedinoj aktivnosti, i koliina/vrsta utroenih resursa.

Primjeri mjerenja softverskog proizvoda su: kompleksnost dizajniranog sustava, kompleksnost implementacije, gustoa greaka, opseg testiranja, meuvrijeme pojave greaka tijekom odravanja. Ova mjerenja se mogu pohraniti u bazu podataka i mogu posluiti za utvrivanje slabih strana procesa razvoja, te pomoi menaderima u donoenju odluka o poboljanjima procesa. Kontrola procesa Kao bi se u svakom trenutku mogao utvrditi status projekta, potrebno je odabrati ili razviti sustav monitoringa i izvjetavanja. Projekt meneder treba imati povratnu vezu o napredovanju svog projekta kako bi bio siguran da se sve aktivnosti provode prema zacrtanom planu, miljokazi kao kontrolne toke imaju glavnu ulogu u kontroli procesa. Kontrolne toke su diskretni, odreeni dogaaji tijekom projekta ije izvrenje treba precizno prikazati, te ne smije biti sumnje da je pojedina kontrolna toka u potpunosti provedena. Potrebno je pismeno iskazati bilo koje odstupanje od plana projekta, normi, ili drugih zahtjeva.

Atributi ivotnog ciklusa

Atributi ivotnog ciklusa softvera u Bootstrapu su preuzeti iz norme softverskog inenjeringa ESA PSS-05. Norma opisuje model procesa (normizirani format strukture planova i dokumentacije, metoda, kontrolnih postupaka i sl; dekomponirajui razvojni proces softvera u niz faza (unaprijeeni Model vodopada), s naglaskom na mogunosti ponovnog koritenja (engl. reuse). Svrha ponovnog koritenja je upotreba ve izraenih dijelova softvera za neki prijanji projekt (izvrnog koda, logike strukture, funkcionalne arhitekture). Analogno normi ISO 9001, Bootstrap takoer definira atribut Sustavi posebne namjene koji provjerava mehanizme za posebne softverske procese kao to su to: razvoj sustava realnog vremena, sustava kritinih za sigurnost, i ugraenih sustava.

Modeli i profili kvalitete

Veina modela kvalitete bavi se kvalitetom proizvoda, do sada ima malo modela kvalitete procesa koji bi identificirali sve atribute procesa koji imaju utjecaj na kvalitetu i uinkovitost procesa koji se koristi za razvoj i odravanje softverskog proizvoda. Modeli kvalitete zapoinju odreivanjem ciljeva kvalitete. Tim ciljevima se potom pridijeljuju atributi kvalitete, a zatim svakom atributu dodijeljuju faktori kvalitete. Svaki faktor kvalitete moe ponovno imati faktore kvalitete nie razine, ime nastaje hijerarhija atributa kvalitete. Hijerarhiji atributa pridodaju se mjerila kvalitete faktora. Faktori se evaluiraju prema definiranim mjerilima, ime se dobiva skup izmjerenih vrijednosti koje predstvaljaju kvalitetu procesa ili proizvoda. Bootstrap definira hijerarhiju atributa kvalitete procesa rezultirajui u modelu kvalitete procesa kako je to ve prikazano na slici 11.1. Svakom faktoru kvalitete procesa pridodaje se algoritam razine zrelosti, ime se dobiva kvaliteta procesa / profil zrelosti. Bootstrap identificira hijerarhiju od 30-tak atributa kvalitete procesa prema normi ISO 9000-3.

Izraunavanjem razine zrelosti za svaki atribut i grafikim prikazom rezultata, dobiva se Bootstrap-ov profil zrelosti kvalitete procesa. Profil ukazuje na dobre i loe strane procesa razvoja softvera. Norma ISO 9000-3 definira atribute kvalitete procesa koji su najvaniji za uspostavu sustava kvalitete menadmenta softvera i razvojne organizacije. Upitnik razvijen za model CMM ima samo est atributa koji se odnose na organizaciju i metodologiju. Uzimajui u obzir norme ISO 9000-3 i ESA PSS-05, Bootstrap identificia oko 25 dodatnih atributa kojima se pridodaju pitanja u upitniku.

Upitnik Bootstrapa
Bootstrap koristi dva upitnika za odreivanje zrelosti procesa: 1. Upitnik za procjenu SPO-a (Globalni upitnik - G) 2. upitnik za procjenu projekta / projekata unutar SPO-a (Projektni upitnik - P) U Globalnom upitniku, istrauje se preporuivanje koritenja odreenih procedura, metoda, normi i tehnologije, dok se Projektnim upitnikom istrauje njihovo prihvaanje. To znai da se prvo provjerava da li SPU osigurava sve potrebne resurse, i drugo, s kolikom uinkovitou projekt ili projekti koriste te resurse. Na svaki upit u upitniku odgovara se lingvistikim varijablama: a) slabo, ili ne postoji, b) osnovno ili dobro, c) znaajno ili jako, d) sveobuhvatno ili kompletno. Svaki lingvistiki termin se prevodi u postotke: slabo = %, osnovno = 33%, jako = 66%, i kompletno = 100% (slika 11.5). Pristup Bootstrap algoritma za odreivanje zrelosti moe se usporediti s penjanjem na brdo, s brojevima koraka kako bi se s najnie toke dolo do vrha brda. Svaki korak predstavlja jedno pitanje u upitniku, svaki korak moe biti zadovoljen s 0, 0.33, 0.66, 1. Svaki SPU pokuava postii to vei broj koraka kako bi se to vie pribliio vrhu. Najnia toka je razina zrelosti 1, a vrh brda je razina zrelosti 5. Proraunava se broj koraka koje je SPU izvrio, broj koraka se unosi u dinamiku ljestvicu kojom se potom dobiva razina zrelosti. Ako su sva pitanja na razini i zadovoljena s vrijednou veom ili jednakom od 80%, tada je ta razina u potpunosti zadovoljena. Da bi se dostigla prva via razina, SPU ili projekt mora zadovoljiti sve kljune atribute na postojeoj razini s minimumom od 50%. Upitnik ima slijedeu strukturu koja je odraz hijerarhije atributa kvalitete procesa: Organizacija Sustav kvalitete Menadment resursima Odabir osoblja i trening Metodologija Funkcije koje se odnose na procese Funkcije neovisne o ivotnom ciklusu softvera

Funkcije ivot ciklusa softvera

Tehnologija Za svaki metodoloki atribut postoji odgovarajui tehnoloki atribut

Metodologija asesmenta
Prethodnica asesmenta Prije poetka asesmenta prema metodi Bootstrap potrebno je: odabrati odreeni projekt ili vie projekata koji e se procjenjivati, odrediti osoblje SPU-a koji e davati odgovore na pitanja iz upitnika Osoblje koje e davati odgovore na pitanja iz upitnika ukljuuje: Na razini SPU-a: odgovornu osobu za razvoj odgovornu osobu za OKS Na razini projekta: osobu koja vodi planiranje osobu koja menadira konfiguraciju i promjene osobu koja provodi testiranje osobu koja u ulozi SEPG-a. 11.9.2 Asesment SPU-a Za provoenje asesmenta SPU-a koristi se G (Globalni) upitnik koji se dijeli na upitnike: - G 1, neformalni upitnik koji daje ope informacije o SPU-u i koji se ne boduje - G 2, upitnik kod kojeg se boduje svako pitanje G 1 upitnik: Ope informacije o SPU-u: G 1.1: Profil organizacije G 1.1.1: Struktura G 1.1.2: Vrste proizvoda i usluga G 1.1.3: Poloaj na tritu, broj uposlenih G 1.1.4: Lokacija i logistika, druge lokacije, organizacijske ovisnosti izmeu lokacija G 2 upitnik: Razine zrelosti. Nakon provedenog asesmenta koritenjem Bootstrap-ovog algoritma identificiraju se pojedinani atributi procesa SPU-a ili pojedinanog projekta, te se za svaki atribut procesa izraunava razina zrelosti. To omoguava evaluaciju razine zrelosti SPU-a ili projekta. Interpretacija profila kvalitete procesa

Razina zrelosti 2 znai da se koriste metode razvoja procesa; razina 3 znai da su metode dokumentirane i normizirane za sve projekte; razina 4 znai djelotvornu upotrebu metoda, visoku proizvodnost glavnih procesnih koraka uz kvantitativna mjerenjea kvalitete proizvoda; razina 5 znai da se analiziraju povratne veze, te uspostavljaju planovi aktivnosti za stalno usavravanje procesa. Prikazi etvrtina (na pr. 1.50, 1.75, 2.25) mogu se interpretirati lingvistiki (na pr. koritenje metoda je slabo na 1.25, osnovno na 1.50). Na slici 11.5 primjer je prikaza dijagrama opih atributa SPU-a i jednog od njegovih projekata.

Opi atributi
5 Razina zrelosti 4 3 2 1 0 Razina zrelosti Ukupno org. Ukupno metodol. SPU pro.01

Slika 11.5 Opi atributi SPU i projekta Na slici 11.6 prikazani su organizaciojski atributi SPU-a. Atribut sustav kvalitete i osiguranje kvalitete je na razini 1.75, to znai da SPU definira funkcije i uloge OKS-a ali ne osigurava dokumentaciju; takoer nema SEPG koja bi povremeno provjeravala i poboljavala procese. Menedment resursima je nizak (1.25), to ukazuje da se ne primjenjuje metodologija pri procjeni i osiguravanju resursa. Atribut odabir osoblja i trening (2.00) znai da se uinkovito koristi metoda odabira osoblja i provodi treninzi, ali to nije normizirano i dokumentirano to bi u budunosti trebalo provesti.

Organizacijski atributi
Razina zrelosti 5 4 3 2 1 0 Sustav kvalit. I osig. Kvalitete Menedment resursima Odabir osoblja I trening SPU

Slika 11.6 Organizacijski atributi SPU

Pojedinani atributi SPU i projekta Bootstrap izraunava razinu zrelosti pojedinanih atributa kvalitete procesa SPU-a i njegovog projekta. Na taj nain je omoguena evaluacija razine zrelosti SPU-a i/ili projekta kao i primjena pojedinog atributa kvalitete procesa. Profil zrelosti procesa prikazan na slici 11.7 interpretira se na slijedei nain: Asesirani SPU X je slab u menedmentu projekta (1.25), premda se praksa menedmenta projekta provodi na razini projekta (2.00). To navodi na zakljuak da via razina menadera ne preporua koritenje metoda menedmenta projekta i nita nije uinjeno na odabiru i uvoenju metoda i procedura. To pak uzrokuje da menederi projekta svaki za sebe razvijaju svoje metode. Takva situacija vodi do problema da svaki projekt koristi drugaiju metodu. Revizije projekta su oteane jer nema normizirane metode. Menedment kvalitete za SPU X i za projekt X1 (1.75) se koristi ali se dovoljno ne koriste norme i uputstva. Menedment promjena i konfiguracije softvera (2.00) se provodi dovoljno na razini SPU-a i djelotvorno se koristi i dokumentira za projekt x1 (2.75). SPU ne daje preporuke za koritenje metoda analize i dizajn softverskog sustava koji se razvija. Tako projekt X 1 nema djelotvornu metodologiju za specificiranje zahtjeva i arhitekturni dizajn.

Pojedinani atributi SPU X i projekt X1

5 4,5 4 3,5 3 2,5 2 1,5 1 0,5 0 M ened.M ened.M ened.M ened. M odel Zahtjevi A rh. Det. P roj. Kvalit. K onfig. Rizika razv. Diz ajn Dizajn Testir. Rad I odrav.

Razina zrelosti

SPU Proj. X1

Slika 11.7 Profil kvalitete procesa SPU X i projekta X1 to se tie detaljnog dizajna, projekt X1 ne koristi sve dostupne resurse. SPU preporuuje koritenje modela razvoja softvera to projekt X1 slijedi na istoj razini (2.25). Metode testiranja se koriste ali se ne koriste divoljno norme i uputstva. Odravanje softvera (1.50) trebalo bi poboljati kako za SPU tako i za projekt X1.

Saetak

Bootstrap kao jedan od ESPRIT projekata, europski je odgovor na metodu SEI/CMM za odreivanje zrelosti procesa. Bootstrap prihvaa paradigme softverskog inenjeringa prema kojima: a) poboljanje softverskog proizvoda se moe postii usavravanjem procesa razvoja, i b) organizacija (O) je najvanija, a metode i metodologije (M) su vanije od tehnologije (T). Formula prioriteta po razinama i redoslijedu jest: O>M>T. U aritu interesa Bootstrapa je SPU, tj. organizacija koja se bavi razvojem i odravanjem softvera. Model kvalitete procesa Bootstrapa razlikuje 1.) organizacijske, 2.) metodoloke, i 3.) tehnoloke atribute procesa. Bootstrap ukljuuje koncept SEPG prema metodi SEI/CMM, koncept dokumentacije osiguranja kvalitete softvera prema normi ISO 9000-3, i ivotni ciklus softvera prema normi ESA PSS-05. Bootstrap identificira hijerarhiju od 30-tak atributa procesa, izraunavanjem razine zrelosti za svaki atribut i grafikim prikazom rezultata, dobiva se profil razine zrelosti SPU-a i projekta/ projekata. Za provedbu asesmenta koristi se globalni (G) upitnik, i projektni (P) upitnik.

12
____________________________________________________________________________

Model SPICE ISO 15504

Model SPICE (engl.: Software Process Improvement and Capability dEtermination) iniciran je sa svrhom normizacije asesmenta procesa razvoja softvera. Model se primjenjuje za asesment procesa, utvrivanje jakih i slabih strana procesa te definiranje podruja koja treba usavriti ______________________________________________________________________________

Podruje primjene
U okviru podruja usavravanja procesa, asesment procesa karakterizira praksu razvoja softvera unutar organizacijske jedinice u smislu razine zrelosti procesa. Analize rezultata daju uvid u jake i slabe strane procesa, kao i rizike inherentne procesu. Ovo u nastavku vodi do mogunosti utvrivanja da li su procesi djelotvorni u dostizanju njihovih ciljeva, i do utvrivanja uzroka slabe kvalitete ili prekoraenja vremena i trokova, te do odreivanja prioriteta usavravanja procesa.. Asesment procesa razvoja softvera je prikazan na slici 12.1.

Proces Se ispituje Asesment procesa Vodi prema Vodi prema Utvrivanje sposobnosti

Utvruje promjene na

Utvruje sposobnost i rizik

Usavravanje procesa

Motivira Slika 12.1 Asesment procesa softvera

Dokumentacija
Dokumentacija metode SPICE ukljuuje: Uvodnik (Introduction Guide IG) koji opisuje cjelokupnu dokumentaciju metode te upuuje na odabir dokumenata i njihovo koritenje, Uputstvo za usavravanje procesa (The Process Improvement Guide PIG) opisuje kako definirati inpute i koristiti rezultate asesmenta u svrhu usavravanja procesa, Uputstvo za utvrivanje sposobnosti procesa (The Process Capability Determination Guide PCDG) opisuje kako definirati inpute I koristiti rezultate asesmenta u svrhu utvrivanja sposobnosti procesa, Uputstvo za asesment procesa (The Process Assessment Guide PAG) definira okvir za provoenje asesmenta i uspostavlja temelj rangiranja, utvrivanja omjera i profiliranje sposobnosti procesa, Uputstvo za osnovnu praksu (The Baseline Practices Guide BPG) definira na najvioj razini model procesa koji se koristi za asesment i usavravanje procesa. Osnovne aktivnosti, neophodne za softverski inenjering su strukturirane prema rastuim razinama sposobnosti procesa, Uputstvo za instrumentaciju asesmenta (The Assessment Instrument Guide AI) definira okvirne elemente za konstrukciju instrumenata od pomoi asesoru u provoenju asesmenta, Uputstvo za trening i kvalifikaciju asesora (The Assessor Training and Qualification Guide ATQG) opisuje kolovanje, trening i iskustvo asesora relevantnih za provoenje asesmenta procesa. Opisuju se mehanizmi koji se mogu koristiti za demonstraciju kompetentnosti asesora i za validiranje kolovanja, treninga i iskustva

Dokumenti su meusobno povezani kako je to prikazano na slici 12.2.

Utvrivanje sposobnosti (PCDG) (PAG) Asesment procesa

Usavravanje procesa (PIG)

Model procesa softvera Instrument asesmenta (BPG) (AI) Zahtjevi za trening i kolovanje asesora (ATQG) Slika 12.2 Povezanost dokumenata

Model procesa
Model procesa opisan je u dokumentu BPG koji opisuje arhitekturu procesa u dvije dimenzije, kako je to prikazano na slici 12.3.

SPICE
Model procesa

5 Kategorija procesa: - Inenjering - Projekt - Podrka - Kupac-dobavlja - Organizacija 35 Procesa (201 Osnovna praksa)

6 Razina kvalitete: 1. Kontinuiranog usavravanja 2. Kvantitativno kontrolirana 3. Dobro definirana 4. Planirana i trasirana 5. Neformalna provedba 6. Nema provedbe (26 Zajednike prakse)

Slika 12.3 SPICE model procesa Prva dimenzija u modelu sastoji se od 35 procesa koji su grupirani u 5 kategorija procesa: Kategorija procesa kupac dobavlja ukljuuje procese koji imaju direktni utjecaj na kupca; Kategorija procesa inenjeringa ukljuuje procese koji direktno specificiraju, implementiraju ili odravaju sustav ili softverski proizvod; Kategorija procesa projektiranja ukljuuje procese koji uspostavljaju projekt, te koordiniraju i menediraju projektne resurse; Kategorija procesa podrke ukljuuje procese koji podravaju performance drugih procesa na projektu;

 Kategorija procesa organizacije ukljuuje procese koji uspostavljaju ciljeve poslovanja organizacije i razvojog procesa, proizvoda i resursa, koji pomau organizaciji postizanje postavljenih ciljeva. Proces je skup aktivnosti, temeljne prakse koji pridonose postizanju svrhe procesa. Prema metodi SPICE svaki proces izmeu 3 i 13 temeljnih praksa. Druga dimenzija modela sastoji se od est razina koje tvore stupnjeve zahtjeva, od najnie razine 1 do najvie razine 5. Svaka razina satoji se od zajednikih karakteristika oblikovane opom praksom. Razina 1: temeljna praksa provodi se neformalno. Praksa se strogo ne planira i ne trasira. Performance ovise o naporu i znanju pojedinaca, Razina 2: procesi se planiraju i trasiraju. Performance temeljne prakse u procesu se planiraju i trasiraju. Performance se validiraju prema specificiranim procedurama, proizvodi odgovaraju specificiranim normama i zahtjevima, Razina 3 Dobro-definirana razina. Temeljna praksa se provodi prema dobro-definiranom procesu koristei odobrene, prilagoene verzije normi, procesi su dokumentirani. Osnovna razlika prema planiranoj i trasiranoj razini je da se procesi planiraju i menadiraju koristei organizacijske normirane procese, Razina 4: Kvantitativno-kontrolirana razina. Prikupljaju se i analiziraju detaljna mjerenja performanci. To dovodi do razumijevanja sposobnosti procesa i poboljanoj mogunosti predvianja performanci krajnjeg proizvoda. Razina 5: Kontinuirano usavravanje. Uspostavlja se kvantitativna uinkovitost procesa i performanci temeljeno na poslovodnim ciljevima organizacije. Kontinuirano usavravanje procesa prema tim ciljevima omogueno je analizom povratne veze provedbe definiranih procesa, inovacijama i novim tehnologijama.

Razina 0 Bez provedbe takoer postoji a odnosi se na sveukupno loe provoenje temeljne prakse procesa razvoja. Nema prepoznatljivog proizvoda temeljem proizvodnog procesa ili outputa procesa. Sjedinjavanjem dvije dimenzije modela, SPICE omoguava analiziranje procesa razvoja softvera prema zahtjevima pojedine razine u svrhu utvrivanja sposobnosti procesa. Metoda ne zahtjeva odreivanje: koje procese treba izvriti prije bilo kojeg drugog procesa; koji procesi trebaju dostii koju razinu zrelostim da bi se definirala dobra kvaliteta softverskog proizvoda.

To je specifinost ovog modela u usporedbi s drugim poznatim modeliman kao to su to SEI/CMM ili Bootstrap; SPICE model moe koristiti bilo koja organizacija za bilo koji projekt.

Asesment procesa
Asesment procesa omoguava utvrivanje sposobnosti procesa i mjerenje usavravanja procesa, formalno, utvrivanje sposobnosti poglavito razmatra odnos klijent dobavlja.

Asesment ukljuuje usporedbu postojeeg stanja u organizacijskoj jedinici (OJ) prema modelu procesa. Rezultat asesmenta dobiva se evaluacijom udovoljavanju zahtjeva modela. Originalni aspekt metode SPICE je takoer u srazmjeru odreivanja udovoljenju zahtjeva modela. Asesor prema svojoj odluci prosuuje o postojanju/ne postojanju (bez provedbe) temeljne prakse i primjerenosti modelu koritenjem razmjerne ljestvice. Temeljna praksa postojanje prema razmjernoj ljestvici N; Ne postoji: temeljna praksa ili nije implementirana ili ne proizvodi bilo kakav prepoznatljivi proizvod; Y; Postoji: implementirana temeljna praksa proizvodi prepoznatljiv proizvod, Razmjerna ljestvica primjerenosti temeljne prakse ima 4 stupnja: N; Ne adekvatna: temeljna praksa ili nije implementirana ili ni u kojem stupnju ne pridonosi udovoljenju svrhe procesa; P; Djelomino adekvatna: implementirana temeljna praksa vrlo malo doprinosi u zadovoljavanju svrhe procesa; L; Vrlo adekvatna: implementirana temeljna praksa vrlo mnogo pridonosi zadovoljenju svrhe procesa. F; Potpuno adekvatna: implementirana temeljna praksa u potpunosti pridonosi zadovoljenju svrhe procesa. Razmjerna ljestvica primjerenosti ope prakse ima takoer 4 stupnja: N; Ne primjerena: opa praksa ili nije implementirana ili ili ni u kojem stupnju ne zadovoljava svoju svrhu; P; Djelomino primjerena: implementirana opa praksa malo doprinosi zadovoljenju svoje svrhe; L; Vrlo primjerena: implementirana opa praksa vrlo mnogo doprinosi zadovoljenju svoje svrhe; F; Potpuno primjerena: implementirana opa praksa u potpunosti zadovoljava svoju svrhu. Koritenjem ove ljestvice asesment procesa utvruje profil primjerenosti procesa kako je to prikazano na slici 12.4. Svrha Organizacijska jedinica Ogranienja Odgovornosti Instance procesa (P1, P2, P3, P4, P5)

Asesment procesa

Rezultati

Instrument asesmenta (indikator) Model menedmenta procesa: Procesi / Osnovna praksa Razine / Opa praksa
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

sadraj asesmenta profil procesa za svaku razinu

Primjer za razinu 2:

Bez Djelomino Vrlo Potpuno

P1

P2

P3

P4

P5

Slika 12.4 Profil procesa kao rezultat asesmenta procesa od P1 do P5 SPICE asesment se provodi za svaku fazu procesa prema slijedeim koracima: istrauje se postojanje temeljne prakse koja tvori proces, evaluira se adekvatnost temeljne prakse, evaluira se adekvatnost procesa prema opisanim zahtjevima za svaku od 5 razina.

Postoci provedbe praksi Ne primjerene, Djelomino primjerena, Vrlo primjerena, ili Potpuno primjerena s njihovim opisima modela se moe prikazati na dijagramu. Svi prethodni radovi neophodni za provoenje asesmenta, trening, kolovanje i dr. su opisani u dokumentu PAG.

Metodologija usavravanja procesa

Uputstvo za usavravanje procesa (PIG) opisuje metodologiju za kontinuirano usavravanje kvalitete procesa poglavito bazirano na normi ISO 9004-4. Uputstvo sadri slijedee teme: koritenje rezultata provedenog asesmenta procesa softvera; mjerenje uinkovitosti procesa softvera uinkovitosti usavravanja; utvrivanje aktivnosti za usavravanje procesa na temelju poslovodnih ciljeva; koritenje BPG-a kao vodilje za usavravanje procesa; zahtjevi na osoblje za aktivnosti usavravanja;

rad s menadmentom za usavravanje procesa softvera.

Asesment procesa provodi se iz dva razloga: 1. za inicijalnu dijagnostiku razine zrelosti postojee prakse, prije utvrivanja plana usavravanja procesa. Taj plan treba takoer uzeti u obzir poslovodne potrebe organizacije i druge faktore kao to su to norme, oekivanja klijenata, ili rezultate prijanjih audita kvalitete. 2. Za drugi asesment koji se provodi u svrhu evaluacije napretka i uspjenosti plana usavravanja. Model procesa SPICE moe se iskoristiti za uspostavljanje plana aktivnosti usavravanja koritenjem profila zrelosti procesa kao cilja usavravanja. Svaki zahtjev ope prakse prema razinama, moe se odabrati za za plan usavravanja i smatrati potencijalnim ciljem za usavravanje specifinog procesa. Na primjer, vidi sliku 12.6, organizacijska jedinica moe odluiti poboljati procese 1 do 5: P1, P2, i P4 moraju potpuno zadovoljiti zahtjeve razine 1, tj. sve temeljne prakse koje su opisane modelom e se morati izvriti, Istovremeno, P3 i P5 temeljne prakse morati e se izvravati vrlo primjereno. Postojei profil zrelosti na razini 1
100% 80% 60% 40% 20% 0% P1 P2 P3 P4 P5 Bez Djelomino V rlo Potpuno

Plan usavravanja procesa

Ciljni profil zrelosti procesa na razini 1

100% 80% 60% 40% 20% 0% P1 P2 P3 P4 P5 Bez Djelomino V rlo Potpuno

Slika 12.6 Usavravanje procesa bazirano na ciljnom profilu

Saetak
Model SPICE je snaan alat za procjenu i usavravanje kvalitete softvera. Model asesmenta procesa osigurava preciznost analize softverskih procesa. Dobro poznavanje modela potrebno je prvenstveno asesorima, a i osobama iz organizacije koja se procjenjuje kako bi se izbjegle krive interpretacije. Model svakako daje jasnu viziju razine zrelosti procesa razvoja softvera. SPICE model moe koristiti bilo koja organizacija za bilo koji projekt.