Razvoj softvera: standardi kvalitete. Capability Maturity Model (CMM) Osnovni dokumenti sustava kvalitete poduzeća i životnog ciklusa softvera

Osim državnih i međunarodnih standarda, postoji nekoliko pristupa certificiranju procesa razvoja. Najpoznatiji od njih u Rusiji su, očito, CMM i CMMI.

CMM (Capability Maturity Model) je model zrelosti procesa kreiranja softvera, koji je dizajniran za procjenu razine zrelosti razvojnog procesa u određenoj tvrtki. Prema ovom modelu postoji pet razina zrelosti razvojnog procesa. Prva razina odgovara razvoju "kako se događa", kada programeri pristupaju svakom projektu kao da je podvig. Drugi odgovara više ili manje uspostavljenim procesima, kada se s razumnim povjerenjem može računati na pozitivan ishod projekta. Treća odgovara prisutnosti razvijenih i dobro opisanih procesa koji se koriste u razvoju, a četvrta odgovara aktivnoj uporabi metrike u procesu upravljanja za postavljanje ciljeva i praćenje njihovog postizanja. Konačno, peta razina odnosi se na sposobnost tvrtke da optimizira proces prema potrebi.

CMM i CMMI zahtjevi

Nakon pojave CMM-a počeli su se razvijati specijalizirani modeli zrelosti za stvaranje informacijskih sustava, za proces odabira dobavljača i neki drugi. Na temelju njih razvijen je integrirani CMMI (Capability Maturity Model Integration) model. Osim toga, CMMI je pokušao prevladati nedostatke CMM-a koji su se do tada pojavili - preuveličavanje uloge formalnih opisa procesa, kada je prisutnost određene dokumentacije ocijenjena puno višom od samo dobro uspostavljene, ali ne i opisane. postupak. Međutim, CMMI je također usredotočen na korištenje vrlo formaliziranog procesa.

Dakle, osnova CMM i CMMI modela je formalizacija procesa razvoja. Oni imaju za cilj programere da provedu proces detaljno opisan u propisima i uputama, koji, zauzvrat, ne mogu a da ne zahtijevaju izradu velike količine projektne dokumentacije za odgovarajuću kontrolu i izvješćivanje.

Veza između CMM-a i CMMI-ja i iterativnog razvoja više je neizravna. Formalno, ni jedan ni drugi ne postavljaju posebne zahtjeve za pridržavanje vodopada ili iterativnog pristupa. Međutim, prema nekim stručnjacima, CMM je kompatibilniji s vodopadnim pristupom, dok CMMI također dopušta korištenje iterativnog pristupa.

Naravno, RUP je iterativna metodologija. Iako obavezni zahtjev za dovršetkom svih faza ili određenog minimalnog broja iteracija nije formalno naznačen nigdje u RUP-u, cijeli pristup je fokusiran na činjenicu da ih ima dosta. Ograničeni broj ponavljanja ne dopušta da se u potpunosti iskoriste sve prednosti RUP-a. U isto vrijeme, RUP se također može koristiti u praktički vodopadnim projektima, koji zapravo uključuju samo nekoliko iteracija: jednu u fazi "Build", a drugu u fazi "Transfer". Usput, u vodopad projektima ovaj broj ponavljanja se zapravo koristi. Uostalom, testiranje i probni rad sustava uključuje i korekcije koje mogu uključivati ​​određene radnje vezane uz analizu, projektiranje i razvoj, odnosno zapravo su još jedan prolaz kroz sve faze razvoja.

RUP metodologija

Što se tiče formalnosti metodologije, RUP korisniku pruža vrlo širok raspon mogućnosti. Ako obavite sve poslove i zadatke, izradite sve artefakte i provedete sve preglede sasvim formalno (sa službenim recenzentom, pripremate potpuni pregled u obliku elektroničkog ili papirnatog dokumenta itd.), RUP može ispasti biti krajnje formalna, teška metodologija. U isto vrijeme, RUP vam omogućuje da razvijate samo one artefakte i obavljate samo one poslove i zadatke koji su nužni u konkretnom projektu. A odabrani artefakti mogu se izvršiti i pregledati s proizvoljnim stupnjevima formalnosti. Možete zahtijevati detaljnu razradu i pažljivo izvršenje svakog dokumenta, pružanje jednako pažljivo dovršenog i izvršenog pregleda, pa čak, prema staroj praksi, odobriti svaki takav pregled na znanstveno-tehničkom vijeću poduzeća. Ili se možete ograničiti na e-mail ili skicu na papiru. Osim toga, uvijek postoji još jedna mogućnost: oblikovati dokument u svojoj glavi, odnosno razmisliti o relevantnom pitanju i donijeti konstruktivnu odluku. A ako se ova odluka tiče samo vas, ograničite se, na primjer, na komentar u programskom kodu.

Dakle, RUP je iterativna metodologija s vrlo širokim rasponom mogućih rješenja u smislu formalizacije procesa razvoja.

Rezimirajmo drugi dio članka. RUP, za razliku od većine drugih metodologija, omogućuje odabir u širokom rasponu stupnja formalizacije i iterativnosti procesa razvoja, ovisno o karakteristikama projekta i organizacije u razvoju.

Razgovarat ćemo o tome zašto je to toliko važno u sljedećem dijelu.

V. Iljin.

Voditelj službe kvalitete tvrtke TopSBI

„Ako išta poduzmeš

pogrešno - nema potrebe
očekujte pravi rezultat."

Kineska narodna mudrost

Sveobuhvatno rješenje problema osiguranja kvalitete softvera uključuje razvoj i implementaciju jednog ili drugog sustava upravljanja kvalitetom (Sustav upravljanja kvalitetom - QMS). U svjetskoj praksi najviše je rasprostranjen sustav koji se temelji na zahtjevima međunarodnih normi serije ISO 9000, jer definira najopćenitije zahtjeve, uključujući i one za programske sustave, te time općenito predodređuje početne zrelost procesa koja je neophodna za usklađivanje s mnogim industrijskim modelima i standardima u IT području .

Ali na pitanje garantira li implementacija sustava kvalitete i uspješna certifikacija izlazak kvalitetnog proizvoda na tržište mora se iskreno odgovoriti - "ne".

Iako naglašava da je ISO 9000 "sjajna ideja", Gartner Group preporučuje da se certifikat ISO 9001 smatra samo početnom točkom na putu do kvalitete (1).

Postavlja "kostur" sustava kvalitete, a punjenje ovog sustava "mišićima" (profesionalni sadržaj temeljen na posebnim industrijskim standardima i metodologijama, kao što je CMM) može osigurati razinu kvalitete koja zadovoljava rastuće zahtjeve tržišta.

U vezi s navedenim, kako s metodološkog tako i s praktičnog gledišta, mnogi stručnjaci iz područja upravljanja kvalitetom smatraju uputnim strategiju razvoja IT tvrtki graditi na sljedeći način:

Najprije razviti i implementirati QMS prema modelu ISO 9001:2000. (Uostalom, većina tvrtki koje su sada na 4. i 5. razini SW-CMM-a prvo su prošle kroz usklađivanje svojih procesa s ISO modelom. Kao što praksa pokazuje, ovo je najbolja opcija u smislu upravljanja razvojem QMS-a i smanjenje rizika).

I tek tada početi razvijati i implementirati ključne procese SW-CMM modela, a zatim, ako je potrebno, CMMI modela.

Da bismo shvatili koliko je to točno, usporedimo ove modele.

1. Pregled pristupnika.

Uzmimo kratki pregled najpopularnijih standarda koje IT tvrtka može koristiti za optimizaciju svojih poslovnih procesa.

ISO 9001. Najpopularniji, a posebno u Europi, je ISO 9001 (2)

Istodobno, metodički, u potpunom skladu s disciplinom izgradnje složenih sustava, norma ISO 9001 osigurava, s jedne strane, izgradnju organizacijskog sustava „odozgo prema dolje”: od ciljeva poduzeća i njegovih politika - na organizacijsku strukturu i formiranje poslovnih procesa, a s druge - iterativni razvoj organizacijskog sustava kroz mehanizme mjerenja i poboljšanja.

Jednostavno rečeno, “kvaliteta”, prema seriji standarda ISO 9000, je situacija u kojoj potrošači od proizvođača dobivaju proizvode koji ispunjavaju njihove izravne zahtjeve i latentna očekivanja. Stoga upravljanje kvalitetom, sukladno ISO 9000, podrazumijeva korištenje tzv. „procesni pristup“, kada se modelira i provodi najoptimalniji lanac „procesnih transformacija“, osiguravajući da proizvođač uoči potrebe potrošača i utjelovi ih u bilo kojem proizvodu bez iskrivljenja.

Mnoge organizacije za razvoj softvera uspješno koriste ovu dobro poznatu seriju standarda ISO 9000. Nova verzija standarda u ovoj seriji objavljena je 2000. i već sadrži koncepte kao što su procesni pristup, analiza i mjerenje, poboljšanje procesa, posuđene od CMM-a model i ranije nedostajao u prethodnim verzijama ISO 9000. Međutim, treba napomenuti da su standardi ove serije univerzalni - nisu usmjereni ni na jednu specifičnu industriju, ne uzimaju u obzir specifičnosti IT sfere i, u ovom smislu, naravno, u smislu stupnja specifikacije, primjetno su inferiorni u odnosu na CMM. Osim toga, ISO 9000 ne podrazumijeva nikakve gradacije (razine) usklađenosti te stoga otežava utvrđivanje „pravih“ sposobnosti pojedine organizacije i, sukladno tome, načina njihova daljnjeg razvoja.

CMM(Capability Maturity Model) razvio je Institut za softversko inženjerstvo pri Sveučilištu Carnegie Mellon (SAD) i opisuje model zrelosti procesa razvoja softvera u poduzećima (3). U okviru ovog modela za svaku tvrtku može se usporediti određena razina (jedna od pet mogućih) koja ukazuje na postignutu kvalitetu procesa razvoja softvera. Budući da su ti standardi prvenstveno razvijeni kako bi pojednostavili proces odabira izvođača za Ministarstvo obrane SAD-a, posebnu pozornost posvećuju procesima upravljanja softverskim projektima, dok su tehnički aspekti razvoja manje pokriveni.

SW-CMM v.1.1 (Capability Maturity Model for Software) ima 316 ključnih praksi. Ključne prakse su ono što bi trebalo implementirati u poduzeću i na što će tim koji provodi procjenu procesa obratiti pozornost. Kombiniraju se u područja - Key Practices Areas (KPA) - to su već skupovi međusobno povezanih procesa koji, kada se izvode zajedno, dovode do postizanja određenog skupa ciljeva.

CMMI(Capability Maturity Model Integration) - daljnji razvoj CMM modela. U CMMI-SE/SW verziji 1.02 (CMMI for Systems Engineering/Software Engineering), možda najprikladnijoj za programere softverskih sustava, broj ključnih praksi već doseže 417.

Povećanje ključnih praksi povezano je sa samom svrhom razvoja CMMI-ja - model bi trebao pomoći u izbjegavanju problema povezanih s korištenjem različitih industrijskih CMM modela.

(Od 1991. CMM modeli su razvijeni za različite primjene, od kojih su najznačajnije:

Model zrelosti procesa razvoja softvera (Capability Maturity Model for Software - SW-CMM)
- model zrelosti procesa za reinženjering sustava (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- model zrelosti procesa integriranog razvoja proizvoda Integrated Product Development Capability Maturity Model - IPD-CMM)

Na temelju tih modela izgrađen je CMMI. Upio je najbolje od tih modela, eliminirajući dvosmislenost u tumačenju nekih pojmova zbog prisutnosti mnogih modela - stoga se broj ključnih praksi značajno povećao).

Jasno je da se ovo već pokazalo kao značajno “teži” model – vidi. Riža. 1, koji, osim toga, još nije dovoljno ispitan u praksi (izdan je tek 2002.). S tim u vezi, po mom mišljenju, pri implementaciji modela mogući su veliki rizici, povezani kako s neopravdanim gubicima u brzini razvoja softvera, tako i s istovremenim nedvosmislenim povećanjem troškova rada za rad (i podršku) implementiranog KPA. - vidjeti. Slika 1. Kao praktičaru koji je već izgradio QMS u tri različite IT tvrtke, čini mi se da je u CMMI modelu jasno poremećena ravnoteža onoga što je potrebno i što je dovoljno - osoblje IT tvrtke (a ovo, u pravilu uglavnom “umjetnici koda”) jednostavno “neće prihvatiti” toliko kontroliranih propisa (ovdje postoji vrlo veliki rizik izgradnje “Potemkinovog sela”)!

Riža. 1 Usporedba sastava KPA u modelima CMM i CMMI.

Osim toga, procjena za CMMI će biti znatno skuplja, budući da je ovlaštena SEI Glavni procjenitelj" I dalje će biti vrlo malo s, a te će usluge biti puno skuplje nego kod procjene usklađenosti s CMM modelom.

Štoviše, mnogi strani stručnjaci u području upravljanja kvalitetom (s čijim se mišljenjem trenutno u potpunosti slažem) prilično su skeptični prema CMMI-ju u kontekstu njegove korisnosti za implementaciju u malim i srednjim organizacijama (upravo takve organizacije tipične su za Rusiju ). Postoji čak mišljenje da će nakon nekog vremena SEI morati ili izdati prilagođeni SW-CMM v.2, ili poduzeti neke slične korake. Oni. ako tržište ne prihvati model, a takvi preduvjeti već postoje u vrijeme pisanja ovog članka, SEI će se morati prilagoditi zahtjevima tržišta.

U vezi s navedenim, čini se primjerenim analizirati već spomenutu ravnotežu potrebnog i dovoljnog u svim ovim glavnim modelima QMS-a.

Provedimo to u sljedećim koordinatama (vidi. Riža. 2) :

stupanj regulacije razvojnih procesa - označimo ovaj koncept - R.P.,

vjerojatnost postizanja planiranih rezultata - označimo ovaj pojam - PQ.

Na sl. Na slici 2. prikazana je stručna procjena ravnoteže između stupnja uređenosti i vjerojatnosti postizanja planiranih rezultata koju je proveo autor na temelju rezultata prakse uvođenja zahtjeva ovih modela u procese razvoja i implementacije softver (softver).

U matematičkom smislu, veličina derivacije je: F(Q) = dPQ\dRQ(povećanje učinkovitosti u postizanju kvalitete dPQ uz povećanje radnog vremena utrošenog na podršku ispunjavanju zahtjeva dRQ), smanjuje se u skladu s tim u sljedećem nizu : ISO 9000, CMM, CMMI.

Stoga Sl. 2 jasno i jednostavno objašnjava:

popularnost modela ISO 9000,

ispravnost metodologije: prvo ISO, a tek onda po potrebi CMM,

određeni skepticizam u pogledu učinkovitosti CMMI modela.

Riža. 2. Analiza ravnoteže između stupnja uređenosti i vjerojatnosti postizanja planiranih rezultata (prema stručnoj procjeni autora)

Razmotrimo sada još jedan vodič, koji se naširoko koristi u IT tvrtkama i koji će biti spomenut u nastavku kada se analiziraju pitanja prakse implementacije QMS-a.

Ovaj PMBOK(Guide to the Project Management Body of Knowledge) projekt je Instituta za upravljanje projektima koji objedinjuje akumulirano znanje iz područja upravljanja projektima. Najnovija verzija dokumenta objavljena je 2000. godine i istodobno je dobila status standarda Američkog instituta za norme ANSI (iako se standardi ANSI i IEEE formalno smatraju američkim, većina njih je de facto međunarodne prirode). Važna značajka PMBOK-a je da razmatra upravljanje projektima u općenitom smislu, bez upućivanja na specifična predmetna područja kao što je IT, te se stoga ne može koristiti samostalno - u nastavku ćemo pogledati učinak koji to daje kada se koristi u kombinaciji s ISO 9000.

Razmotrimo sada kako se zahtjevi već popularnog standarda ISO 9001:2000 odnose na opća svojstva sve popularnijeg CMM modela {3}- cm. Riža. 3.

Riža. 3. Podudarnost između općih svojstava CMM-a i elemenata ISO 9001:2000

Svaka razina HMM-a, kao što je gore spomenuto, karakterizirana je skupom ključna procesna područja - KPA (Key Process Areas) - cm. sl.3. Postizanje svih ciljeva unutar KPA za određenu razinu, SMM utvrđuje usklađenost organizacije s ovom razinom. Ako je barem jedan cilj barem jedan KPA jer razina CMM nije postignuta, tada organizacija ne može zadovoljiti ovu razinu CMM. KPA mogu se podijeliti u tri kategorije: menadžeri , organizacijski I pružanje (cm. Riža. 4).

CMM ne definira sve procese relevantne za razvoj softvera; ističe samo one koji su nužni za postizanje SMM razine, a uključeni su u KPA. Svaki KPA podijeljen je na 5 zajedničkih svojstava (Common Features): Predanost izvedbi (Comment to perform); Sposobnost izvedbe; Provedene aktivnosti; Mjerenje i analiza; Provjera implementacije

Opće svojstvo " Radnje koje treba izvršiti" opisuje radnje koje je potrebno izvršiti da bi se postigli ciljevi KPA, preostala četiri opća svojstva opisuju formalne čimbenike koji čine proces dijelom organizacijske kulture. Potpuna egzekucija svih ključne prakse svih zajedničkih svojstava osigurava postizanje ciljeva KPA. Ključne prakse opisuju što bi tijek rada (ili element procesa, ili dio infrastrukture) trebao postati, ali ne definiraju metodu postignuća (specifične tehnologije ili tehnike), iako su dane opće preporuke za neke prakse. Za različite uvjete, isti se rezultat može postići na različite načine. Ovo su opća načela rada, a ne specifične akcije.

Dosljedna implementacija zajedničkih svojstava zapravo implementira ciklus poboljšanja poslovnih procesa (Business-process Improvement - BPI-cm. Riža. 5.), tj. kontinuirano poboljšanje poslovnih procesa (BP).

Riža. 5. Ciklus kontinuiranog poboljšanja poslovnih procesa prema CMM modelu i ISO 9000:2000.

Želja za dobivanjem potvrde o sukladnosti u što kraćem roku prisiljava konzultantske tvrtke i stručnjake koji se bave upravljanjem kvalitetom da fleksibilnost i okvir zahtjeva svih navedenih modela visoke razine iskoriste za vlastite “sebične” svrhe.
Kao rezultat ovog forsiranja događaja, organizacija, na primjer, koja je primila certifikat ISO 9000:2000, ima samo minimalni potrebni skup procesa definiran za usklađivanje s ISO 9001, a ne sve procese koje tvrtka zahtijeva da djelotvorno djelovati - vidjeti. Riža. 2. Osim toga, razina detalja u procesima možda neće biti dovoljna za jasno razumijevanje onoga što se događa unutar procesa i tko je odgovoran za koje zadatke unutar procesa.
U najboljem slučaju, samo je nekoliko probnih projekata prošlo nove procedure, a nakon nekog vremena postaje jasna potreba za njihovim prilagodbama i dopunama. Često se odmah nakon certificiranja QMS-a procesi zaboravljaju do sljedećeg nadzornog audita, zaboravljajući na utrošena financijska sredstva i entuzijazam zaposlenika.
Zaista, kada djelujete kao neovisni revizor, vrlo je teško dokazati da usvojena razina detalja procesa očito nije dovoljna za učinkovito funkcioniranje QMS-a tvrtke. No, iznimno je teško dokazati suprotno u vremenu predviđenom za ISO 9000 audit (to se vrlo uspješno može iskoristiti kod suprotstavljanja auditoru). Praksa pokazuje da je nemoguće brzo izgraditi učinkovite procese čak i 3. stupnja zrelosti (kao i procese temeljene na ISO 9000).
Da bi se to postiglo, nije dovoljno samo opisati procese uzimajući u obzir zahtjeve odabranog modela. Glavna poteškoća je u tome što je potrebno redizajnirati proizvodnu kulturu unutar organizacije .

A to je nemoguće učiniti samovoljnom odlukom uprave. Zbog toga je pristup definiran u CMM-u jednostavno održiviji i realističniji od modela ISO 9000 cm. Riža. 5.

Razmotrimo sada kako je u praksi moguće izgraditi QMS kompatibilan s oba modela.

Stručna procjena stupnja pokrivenosti ključnih CMM procesa zahtjevima ISO 9000:2000, u skladu s procjenom samih autora CMM (4), prikazana je u sl.6.

Zapravo, njihova procjena je provedena duž dvije koordinate:

stupanj osiguranja (u %) usklađenosti razvojnih procesa (SWP) sa razinom zrelosti u okviru CMM-a -" odredba";

stupanj mogućnosti (u%) takve odredbe, koji je dan ISO 9000:2000 - " prilika".

Kako se vidi iz Riža. 6, Zahtjevi ISO 9000:2000 stvaraju stvarnu priliku da se postigne čak i gornja (CMM razina 5) razina SWP zrelosti.

Međutim, u smislu već osigurane zrelosti SWP-a najmanje treće (CMM Level 3) razine, QMS prema modelu ISO 9000:2000 treba malo modificirati - naime, razviti i implementirati još dvije organizacijske procedure ( Definicija organizacijskog procesa i fokus) i opći postupak upravljanja ( Integrirano upravljanje softverom ), čiji sadržaj nije težak ni za jednu IT tvrtku.

Ali možete i trebate ići dalje (CMM Level 4) - na primjer, u zagradama je prikazana procjena autora ovog članka (u istim koordinatama - podrška i mogućnosti), što odgovara QMS-u prema ISO 9000: 2000 model, u kojem je procesni krajolik QMS-a dopunjen upravljanjem projektima procesa u skladu sa zahtjevima druge gore navedene norme PM Bok- ovo će vam pomoći da značajno povećate zrelost više takvih SWP, Kako:

Praćenje napretka projekata (praćenje i nadzor softverskih projekata);

• Planiranje softverskog projekta;

Opće upravljanje softverom (Integrirano upravljanje softverom);

Upravljanje procesima kroz kvantitativne procjene (Quantitative process management).

Riža. 6. Stručna procjena stupnja pokrivenosti ključnih CMM procesa zahtjevima ISO 9000:2000

Kako se vidi iz sl.6., CMM model je po načelima ugrađenim u njega vrlo blizak QMS-u izgrađenom prema normi ISO 9001:2000 i dopunjenom procesima upravljanja projektima u skladu s PM BoK..

Kako ne biste radili nepotreban posao uz istodobnu certifikaciju prema ISO 9000 i naknadnu ocjenu prema CMM-u, preporučam da prilikom definiranja svojih proizvodnih procesa uključite (ili se možda ograničite na njih - ipak su to za IT tvrtku proizvodni procesi) !) sve što je potrebno u modelu CMM KPA. Dakle, tvrtka istovremeno:

ispunjava zahtjeve ISO 9001:2000 o uvođenju procesnog pristupa;

svi potrebni dokumenti CMM procesi ( KPA);

implementira niz tako važnih zahtjeva ISO 9001:2000 Kako:

upravljanje procesima temeljeno na metrici (Upravljanje kvantitativnim procesima);

upravljanje Dobavljačima na temelju upravljanja podugovorima ( Upravljanje softverskim podugovorima );

analiza zahtjeva potrošača na temelju upravljanje zahtjevima ( Upravljanje zahtjevima );

upravljanje ljudskim resursima temeljeno na Program treninga );

upravljanje komunikacijom na temelju stvaranje formalnih modela organizacijskih procesa ( Definicija organizacijskog procesa );

pokreće mehanizam poboljšanja (Planiraj-Učini-Provjeri -Akcija) sve opisane procese (SWP) kroz dosljednu provedbu svih pet Zajedničke značajke-cm. Riža. 5.

Dakle, ako koristite KPA CMM kao BP i koristite zahtjeve za postupke upravljanja projektom za razvoj PS-a PM BoK, onda se ovako konstruiran QMS može ocijeniti na CMM razina 4 - cm. Riža. 7.

Riža. 7. Shema za postizanje CMM razine 4 korištenjem modela ISO 9000 QMS i priručnika PM BoK 2000.

Zaključno, iz razloga jasnoće (u autorovoj stilizaciji), predstavljam dijagram funkcioniranja QMS-a informatičke tvrtke uz dosljednu implementaciju modela ISO 9000 i CMM - vidi. Riža. 8.

Riža. 8. Shema funkcioniranja QMS-a uz dosljednu implementaciju modela ISO 9000 i CMM (stilizacija autora)

Ovdje je važno razumjeti da su i CMM i ISO 9001:2000 samo alati za kontinuirano poboljšanje.

Dakle, certifikacija prema normi ISO 9001:2000 i potvrda certifikata treba pridonijeti rastu kvalitete procesa tvrtke, pri čemu je kriterij za ocjenu rasta kvalitete procesa izlazak poduzeća na novu razinu. BPI odnosno njihova procjena već se temelji na modelu CMM {3}.

Književnost

"Procjena kvalitete softvera", V. Lipaev, Sinteg, 2001.

ISO 9001:2000. Sustav upravljanja kvalitetom. Zahtjevi.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Model zrelosti sposobnosti za softver (SW-CMM), verzija 1.1. // CMU/SEI-93-TR-024, - veljača, 1993.

Napomena: Detaljno je proučavan niz ideja na kojima se temelji vjerojatno najpoznatija metodologija za poboljšanje procesa razvoja softvera - CMM. Analizirana je logika i struktura HMM-a. Prikazana je veza između HMM-a i prethodno proučavanih modela procesa.

Prekrasan praktičan alat stvoren unutar procesni pristup na opis djelatnosti projektantska organizacija, posebno organizacije koje se razvijaju Informacijski sustavi, demonstrira HMM metodologiju. CMM je kratica za Capability Maturity Model, što otprilike znači "model zrelosti sustava upravljanja". U literaturi se CMM češće naziva modelom organizacijske zrelosti, pa ću i ja slijediti tu tradiciju.

Povijest nastanka SMM-a je sljedeća. Krajem 80-ih. prošlog stoljeća, američko Ministarstvo obrane naredilo je Institutu za softversko inženjerstvo 1eng. SEI - Institut za softversko inženjerstvo Sveučilište Carnegie Mellon radi na stvaranju sustava kriterija za odabir podizvođača u projektima razvoja softvera. Radovi su završeni 1991. godine, a rezultat je bio CMM model. Odmah je potrebno napomenuti da model ne sadrži nikakve financijske, ekonomske, političke, organizacijske kriterij odabira podizvođača, kao i kriterije za mogućnost pristupa klasificiranom poslu (vjerojatno takvi zadaci nisu postavljeni). Govorimo samo o kriterijima koji opisuju sposobnosti potencijalnog podizvođača u pogledu razvoja softverskih sustava.

struktura CMM

Tvorci modela uzeli su organizacijske procese kao osnovu za procjenu sposobnosti organizacije da kvalitetno obavlja posao, što je nazvano zrelost. Zatim su iznijeli nekoliko netrivijalnih pretpostavki, koje su kasnije mnogi IT stručnjaci (a možda i većina njih) prihvatili i prepoznali kao poštene.

Pretpostavka 1. Postoje kvalitativno različite razine zrelosti projektantska organizacija, razvijanje Informacijski sustavi(postoji pet takvih razina u HMM modelu).

Pretpostavka 2. Svaka razvojna organizacija zainteresirana je za prelazak na višu razinu zrelosti (ne samo kako bi povećala svoje šanse u konkurenciji za ugovore Ministarstva obrane, već i radi vlastitog usavršavanja).

Pretpostavka 3. Prijelaz je moguć samo na sljedeću razinu po redu. Nemoguće je "preskočiti" razinu (točnije, rizici za organizaciju naglo rastu).

Dakle, razine čine “ljestvicu” po kojoj se organizacija uzdiže kako se razvija. Svaku razinu karakteriziraju određeni sastav i svojstva procesa organizacije. SMM-ova "ljestvica razina" dobila je široko priznanje i širenje. Ovako ona izgleda.

Razina 1 "Početnica". Proizvodni proces u cjelini okarakteriziran je kao kreiran svaki put za određeni projekt, a ponekad čak i kaotičan. Definirano je tek nekoliko procesa, a uspjeh projekta ovisi o trudu pojedinaca.

Razina 2 "Ponovljivo". Uspostavljeni su osnovni procesi upravljanja projektima koji omogućuju praćenje troškova, nadzor rasporeda rada i funkcionalnosti izrađenog softverskog rješenja. Uspostavljena je disciplina procesa potrebna za ponavljanje prethodnih uspjeha u sličnim projektima razvoja aplikacija.

Razina 3 "Definirano". Proizvodni proces je dokumentiran i standardiziran za upravljanje i dizajn. Ovaj je proces integriran u standardni proizvodni proces organizacije. Svi projekti koriste odobrenu, prilagođenu verziju standardnog proizvodnog procesa organizacije.

Razina 4 "Upravljano". Prikupljaju se detaljni kvantitativni pokazatelji procesa proizvodnje i kvalitete stvorenog proizvoda. I proces proizvodnje i proizvodi procjenjuju se i kontroliraju s kvantitativnog gledišta.

Razina 5 "Optimizacija". Kontinuirano poboljšanje procesa postiže se kvantitativnom povratnom informacijom iz procesa i implementacijom naprednih ideja i tehnologija u njega.

Unatoč nedostatku strogosti, dana definicija intuitivno najčešće ne izaziva primjedbe. Štoviše, iskusni stručnjaci razumiju zašto su prijelazi mogući samo na susjednu razinu, a također je jasno zašto je vrijedno težiti takvom prijelazu općenito. Istodobno, HMM model ne sadrži nikakvo kvantitativno, pa čak ni formalno opravdanje za ovaj pristup, što međutim ni na koji način ne umanjuje njegove prednosti.

Što će se dalje dogoditi, kako kažu, stvar je tehnike. Određuje se struktura modela (slika 7.1), daju se definicije i počinje mukotrpan rad na preciznom opisivanju svakog procesa na svakoj razini. Kako bismo ocijenili praktičnu vrijednost učinjenog, proći ćemo dio ovog puta.

Riža. 7.1.

Na sl. 7.1 sadrži sljedeće koncepte.

Ključna grupa procesa. Kao što je navedeno u (Paulk, et al., 1995), "svaka grupa ključnih procesa definira blok povezanih aktivnosti, kao rezultat kojih se postiže niz ciljeva koji su značajni za povećanje produktivnosti proizvodnog procesa. na primjer, za grupu ključnih procesa" Upravljanje zahtjevima"(Vidi sliku 7.2) cilj je pomiriti zahtjeve za projekt razvoja softvera između kupca i programera."

U CMM-u nema pojedinačnih procesa. Umjesto toga, postoje odvojeni radovi, nazvani ključnim praksama (vidi dolje), međusobno povezani ulazima i izlazima i služe kao izvorni materijal za procese izgradnje. CMM ne daje smjernice o tome kako bi se procesi trebali konstruirati, odnosno kako bi ključne prakse trebale biti povezane u logične slijedove. Skupovi ključnih praksi nazivaju se grupama ključnih procesa.

Grupe ključnih procesa u CMM-u preslikavaju se na razine zrelosti (Slika 7.2), tj. sve prakse na razini međusobno djeluju samo jedna s drugom, a ne interakcije s praksama na drugim razinama. To nam omogućuje da zajamčimo potpunu funkcionalnost svih procesa na određenoj razini i, prema tome, koreliramo razinu sa završenom fazom razvoja organizacije.

Pridjev "ključ" implicira da postoje grupe procesa(tj. skup praksi) koje nisu ključne sa stajališta određene razine zrelosti, tj. nisu povezane s postizanjem ciljeva ove razine (vidi dolje). HMM model ne opisuje sve grupe procesa vezano uz razvoj i održavanje softvera. Opisuje samo one skupine koje su identificirane kao ključne odrednice produktivnosti u procesu proizvodnje.

Ciljevi. Ciljevi u HMM-u nisu povezani s procesima, već sa skupinama ključnih procesa. Kao što je gore spomenuto, ciljevi se postižu kroz implementaciju ključnih praksi. U CMM-u, postizanje cilja znači da se, prvo, nakon završetka ključnih praksi, postiže željeni rezultat, i, drugo, da se postiže prilično dosljedno. Način na koji se postižu ciljevi skupine ključnih procesa može se razlikovati od projekta do projekta ovisno o razlikama u predmetno područje ili okoliš.

Ako su ovi ciljevi postignuti za sve projekte, to znači da je organizacija dosegla razinu zrelosti proizvodnog procesa na koji se veže ova skupina ključnih procesa.

Poglavlje. Sekcije (ima ih pet na svakoj razini i uvijek su iste) predstavljaju svojstva grupa ključnih procesa koji se moraju implementirati na odgovarajućoj razini. Ova svojstva opisuju kako se procesi provode i u kojoj su mjeri legalizirani u organizaciji, tj. službeno odobreni i u skladu s korporativnim procedurama, politikama i drugim procesima. Ovo je pet odjeljaka.

Obveze izvršenja

Opišite aktivnosti koje organizacija mora obavljati kako bi osigurala uspostavu i stabilnost procesa. Obveze provedbe obično se odnose na uspostavu organizacijskih politika i podršku višeg rukovodstva.

Preduvjeti

Opisati preduvjete koji moraju biti ispunjeni u projektu ili organizaciji za kvalitetnu provedbu proizvodnog procesa; obično se odnose na resurse, organizacijske strukture i potrebnu obuku.

Operacije izvedene

Odjeljak "Obavljeni poslovi" opisuje sadržajne poslove koji se moraju obaviti na ovoj razini. Operacije koje se izvode obično uključuju izradu planova i provedbu specifičnih aktivnosti, izvršavanje i praćenje rada te poduzimanje korektivnih radnji prema potrebi.

Mjerenja i analiza

Odjeljak "Mjerenja i

"Svaka grupa ključnih procesa izražena je ključnim praksama čija implementacija doprinosi ostvarenju ciljeva grupe. Ključne prakse opisuju infrastrukturu i operacije koje daju najveći doprinos učinkovitoj implementaciji i uspostavi grupe ključnih procesa.

Svaka ključna praksa sastoji se od jedne rečenice, često proširene u detaljniji opis koji može uključivati ​​primjere i pojašnjenja. Temeljne prakse, koje se ponekad nazivaju temeljne prakse najviše razine, uspostavljaju osnovne politike, procedure i operacije za skupinu ključnih procesa. Komponente detaljnog opisa često se nazivaju pod-prakse."

Temeljne prakse opisuju ŠTO treba učiniti, ali ih ne treba shvatiti kao dogmu koja govori KAKO postići ciljeve. Ciljevi skupine ključnih procesa mogu se postići alternativnim praksama. Tumačenje ključnih praksi mora biti razumno, dopuštajući postizanje ciljeva ključne procesne grupe na učinkovit način, iako možda formalno drugačije od onog koje preporučuje CMM.

Pogled na aktivnosti IT menadžmenta u kojem se umjesto procesa razmatraju njihove komponente - ključne prakse, a procesi su prisutni samo virtualno, kao nešto što se može izgraditi od ključnih praksi, na prvi pogled izgleda pomalo egzotično. Do sada se zadatak poboljšanja IT upravljanja rješavao uvođenjem gotovih procesa iz referentnog modela procesa. Sada postoje mnoge razine koje sadrže različite (tj. neintegrirane u procese) ključne prakse i preporučeni slijed napredovanja kroz razine. Upravljanje informatičkom tehnologijom, prema CMM-u, poboljšava se kako prelazi na više razine zrelosti. Što se događa s takvim napredovanjem?

U definicijama razina (vidi sl. 7.2) pojavio se koncept kao što je "proizvodni proces". Prisutan je i u definiciji skupine ključnih procesa i to nije slučajnost. Proizvodni proces ili, kako se točno naziva u SMM-u, Standardni proizvodni proces organizacije (SPPO), jedan je od središnjih koncepata cijelog modela.

Razmotrit ćemo evoluciju modela osiguranja kvalitete na temelju "modela zrelosti procesa" ili "modela poboljšanja sposobnosti" CMM (Model zrelosti sposobnosti). Unatoč tome što model SMM usmjeren je na osiguranje kvalitete softvera, a njegovi metodološki aspekti primjenjivi su na modele osiguranja kvalitete bilo kojeg proizvoda (roba, radova, usluga).

Glavna stvar u modelu SMM je koncept organizacijske zrelosti.

Nezreo se smatra organizacijom u kojoj proces razvoja softvera ovisi samo o određenim izvođačima i menadžerima, a odluke se često donose “u hodu”. U tom slučaju postoji velika vjerojatnost prekoračenja budžeta ili propuštanja roka za projekt, pa su menadžeri prisiljeni baviti se samo rješavanjem trenutnih problema.

zrelo Organizacija se smatra ako su ispunjeni sljedeći uvjeti:

• – postoje jasno definirane procedure za izradu softverskih proizvoda i upravljanje projektima, koje se u pilot projektima pojašnjavaju i unapređuju analizom komponenti „trošak – dobit“;
• – procjene vremena i troškova izvođenja radova temelje se na prikupljenom iskustvu i stoga su prilično točne;
• – tvrtka ima standarde za procese razvoja, testiranja i implementacije softvera, pravila za dizajn konačnog programskog koda, komponenti, sučelja itd. Sve to čini infrastrukturu i korporativnu kulturu koja podržava proces razvoja softvera.

Dakle standard SMM je model osiguranja kvalitete koji se sastoji od kriterija za procjenu zrelosti organizacije i recepata za poboljšanje postojećih procesa. U modelu SMM Definirano je pet razina zrelosti organizacija čije su karakteristike prikazane na sl. 5.3.

Riža. 5.3. Pet razina zrelosti modelaSMM

Prva razina (početna razina) je osnova za razvoj poduzeća na sljedećim razinama. Smatra se da na početnoj razini organizacije ne postoje stabilni uvjeti za stvaranje kvalitetnog softvera. Posljedično, rezultat bilo kojeg projekta u potpunosti ovisi o osobnim kvalitetama upravitelja i iskustvu programera. To znači da se uspjeh na jednom projektu može ponoviti samo ako su isti voditelji i programeri dodijeljeni sljedećem projektu. Ako menadžeri ili programeri koji su stekli iskustvo na projektima napuste poduzeće, tada s njihovim odlaskom kvaliteta proizvedenog softvera naglo pada.

Treba znati da se na početnoj razini, u stresnim situacijama koje uvelike ovise o ljudskom faktoru, proces razvoja svodi na pisanje koda i minimalno testiranje.

Postizanje drugog ponovljiva razina (ponovljiva razina) određena je implementacijom tehnologije upravljanja projektima u poduzeću. Planiranje i upravljanje projektima u poduzeću temelji se na stečenom iskustvu, za softver koji se razvija postoje i koriste se standardi čiju usklađenost nadzire posebna skupina za osiguranje kvalitete. Vjeruje se da druga razina može pružiti mogućnosti za daljnje poboljšanje (prijelaz na treću razinu) i ne isključuje mogućnost, pod kritičnim uvjetima, regresivnog povratka kvalitete procesa stvaranja softvera na početnu razinu.

Treći, određenu razinu (definirana razina) karakterizira činjenica da je standardni proces izrade i održavanja softvera potpuno dokumentiran, od razvoja softvera do upravljanja projektom. Hipoteza za implementaciju ove razine je da u procesu standardizacije poduzeće prelazi na najučinkovitije prakse i tehnologije. Unutar organizacije mora se stvoriti posebna grupa za izradu i održavanje standarda razvoja softvera i upravljanja projektima. Preduvjet za postizanje treće razine je prisutnost programa stalnog stručnog usavršavanja i usavršavanja zaposlenika u poduzeću. Smatra se da počevši od ove razine, organizacija prestaje ovisiti o kvaliteti pojedinih programera i nema tendenciju skliznuti na nižu razinu u stresnim situacijama.

Na četvrtom, upravljiva razina (upravljana razina) Poduzeće uspostavlja kvantitativne pokazatelje kvalitete - kako za softverske proizvode tako i za procese njihovog stvaranja u cjelini. Time se poboljšava upravljanje projektom smanjenjem varijance različitih pokazatelja projekta. U ovom slučaju, značajne (signalne) varijacije implementiranih procesa kreiranja softvera su odvojene od slučajnih (šumnih) varijacija procesa.

Peti (najviši), razina optimizacije (razina optimizacije) karakteriziran činjenicom da se mjere poboljšanja primjenjuju ne samo na postojeće procese, već i za procjenu učinkovitosti uvođenja novih tehnologija. Glavni zadatak poduzeća na ovoj razini je kontinuirano poboljšavanje postojećih procesa. U isto vrijeme, poboljšanje procesa trebalo bi pomoći u sprječavanju mogućih grešaka i nedostataka. Istodobno treba raditi na smanjenju troškova razvoja softvera.

Modeli poboljšanja

Poboljšanje procesa zahtjeva

Paradigma upravljanja kvalitetom kao način organizacije proizvodnje pojavila se davno. Ideje ugrađene u skupinu standarda ISO9000 1) , ukorijenjeni su, posebno, u takvim "sovjetskim" izumima kao što su podrška prijedlozima racionalizacije, mentorstvo itd.

U suvremenom konceptu procesno orijentiranog poslovnog organiziranja, proces stalnog poboljšanja kvalitete zauzima jedno od ključnih mjesta.

U odnosu na softversku industriju, uz ISO9000 seriju, najuspješnije dokazani standardi kvalitete su SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Aktivno uvođenje metoda upravljanja kvalitetom na Zapadu počelo je ranih 1960-ih. Standardi serije ISO9000 temelje se na filozofiji pristupa CPI (Continuous Process Improvement) i TQM (Total Quality Management). Gospodarski oporavak poslijeratnog Japana bio je uvelike zahvaljujući idejama ugrađenim u TQM.

Kvaliteta je pojam koji za jedne znači potrebu da se radi ono što potrošač želi, za druge ono što zadovoljava njegove potrebe. Upravljanje kvalitetom, kako je definirano u ISO 9001:2000, temelji se prvenstveno na ideji da ljudi rade bolje ako znaju što rade. .

Stoga, prije nego što započnete bilo kakvu akciju, treba dobiti odgovore na pitanja: što treba učiniti, tko će provjeriti što je učinjeno, kako to treba učiniti i kako utvrditi da je posao završen? Također morate razmotriti kako ćete upravljati procesom i kako ga možete poboljšati.

Osnovna načela ISO9000:

• Koncentracija na potrebe kupaca;
• Aktivna liderska uloga menadžmenta;
• Uključivanje izvođača u procese poboljšanja;
• Primjena procesnog pristupa;
• Sustavni pristup upravljanju;
• Osiguravanje stalnih poboljšanja;
• Donošenje odluka na temelju činjenica;
• Obostrano korisni odnosi s dobavljačima.

Nedvojbena prednost standarda ove skupine je činjenica da su testirani u mnogim poduzećima širom svijeta. Međutim, preporuke ovih standarda prilično su općenite i ne uzimaju u obzir specifičnosti poduzeća u IT industriji. Da bi se to postiglo, razvijeni su specijalizirani pristupi, o kojima se govori u nastavku.

Standard CMM (Model zrelosti sposobnosti) razvio je Institut za softversko inženjerstvo (SEI) na Sveučilištu Carnegie Mellon.

Svrha standarda je procijeniti razinu zrelosti organizacije za razvoj softvera. Postoji pet razina: početna, ponovljiva, definirana, upravljana i optimizirajuća (za više detalja pogledajte). Ovaj je standard postao široko poznat; značajan broj zapadnih IT tvrtki certificiran je prema CMM-u.

Godine 2000. SEI je objavio CMMI-SE/SW, integrirani model za poboljšanje mogućnosti dizajna softvera i sustava.

CMMI-SE/SW ima dva oblika. Prikaz u fazama odgovara strukturi SW-CMM s manjim pojašnjenjima naziva razina. Pet razina zrelosti sadrže 22 procesna područja, prikazana u tablici 14.1. (CMU/SEI, 2000a). Kontinuirano predstavljanje ima drugačiji pogled: ista 22 područja strukturirana su u 4 kategorije: upravljanje procesima, upravljanje projektima, izgradnja i podrška (CMU/SEI, 2000b).

Umjesto razina zrelosti, kontinuirani prikaz definira šest razina sposobnosti za svako procesno područje. Ovaj prikaz omogućuje svakoj organizaciji da odluči za koju razinu sposobnosti se kvalificira u svakom od 22 područja procesa.

Kao iu CMM-u, u ovoj normi na razini 2 postoji područje pod nazivom “Upravljanje zahtjevima”, ali, za razliku od prethodnog standarda, na razini 3 postoji i zasebno područje “Inženjering zahtjeva”. Postavljanje ovog područja na razinu 3 ne znači da zahtjeve za projekte organizacije koji ne dosegnu razinu 2 ne treba prikupljati i dokumentirati. Smatra se da upravljanje zahtjevima pomaže u stvaranju predvidljivijih i manje kaotičnih projekata, što je bit CMM razine 2. Usvajanjem procesa za upravljanje promjenama i provjeru statusa zahtjeva, organizacija se može više usredotočiti na razvoj zahtjeva visoke kvalitete.

Područje procesa upravljanja zahtjevima

Ključne teme uključuju kako bi razvojni tim trebao steći razumijevanje zahtjeva i riješiti probleme s klijentima, uključiti članove projekta u rad na zahtjevima i upravljati promjenama. Za razliku od SW-CMM, praćenje (jedno od ključnih svojstava zahtjeva) uključeno je u procesno područje koje se razmatra. Norma govori o sljedećim kvalitetama usmjeravanja:

• osiguravanje bilježenja izvora niskih ili sekundarnih zahtjeva;
• praćenje svakog zahtjeva do sekundarnih zahtjeva i njegovo postavljanje u funkcije, objekte, procese i izvršitelje;
• uspostavljanje horizontalnih veza između zahtjeva koji pripadaju istoj vrsti.

Zahtjevi Područje inženjerskih procesa

CMMI-SE/SW opisuje tri skupa tehnika inženjeringa zahtjeva:

• tehnike koje definiraju kompletan skup zahtjeva kupaca, koji se zatim koriste za razvoj zahtjeva za proizvod (identificirati potrebe dionika projekta; prevesti potrebe i ograničenja u zahtjeve kupaca);
• tehnike koje definiraju kompletan skup zahtjeva za proizvod (uspostavljanje komponenti proizvoda; postavljanje zahtjeva za komponente proizvoda; određivanje zahtjeva za sučelje);
• tehnike za dobivanje sekundarnih zahtjeva, razumijevanje zahtjeva i njihova validacija (uspostaviti operativne koncepte i scenarije; odrediti potrebnu funkcionalnost sustava; analizirati sekundarne zahtjeve; procijeniti troškove, vrijeme i rizik stvaranja proizvoda; odobriti zahtjeve).

I CMM i CMMI navode ciljeve koje projekt ili organizacija za razvoj softvera trebaju nastojati postići u različitim područjima procesa. Oni također preporučuju tehnike koje će pomoći u postizanju ovih ciljeva.

CMMI-SE/SW regulira odnose između upravljanja zahtjevima, inženjeringa zahtjeva i drugih područja procesa (Slika 14.1).