V. Ilyin.

Vodja službe za kakovost pri TopSBI

"Če kaj narediš

narobe - ni potrebno
pričakujte pravi rezultat."

Narodna kitajska modrost

Celovita rešitev za naloge zagotavljanja kakovosti programska orodja vključuje razvoj in implementacijo določenega sistema vodenja kakovosti (Quality Management System - QMS). V svetovni praksi je najbolj razširjen sistem, ki temelji na zahtevah mednarodnih standardov. Serija ISO 9000, ker natančno opredeljuje najsplošnejše zahteve, vključno s tistimi za PS, in tako na splošno že vnaprej določa začetno zrelost procesov, ki je nujna za skladnost s številnimi industrijskimi modeli in standardi na področju IT. .

Toda na vprašanje, ali uvedba sistema kakovosti in uspešno certificiranje zagotavljata izdajo kakovostnega izdelka, je treba iskreno odgovoriti - "ne".

Ob poudarjanju, da je ISO 9000 »odlična ideja«, skupina Gartner priporoča, da se na certificiranje ISO 9001 gleda le kot na izhodišče na poti do kakovosti (1).

Postavlja tako rekoč »okostje« sistema kakovosti in polnjenje tega sistema z »mišicami« (strokovne vsebine, ki temeljijo na že posebnih industrijskih standardih in metodologijah, kot je CMM) lahko zagotovi raven kakovosti, ki ustreza naraščajočim zahteve trga.

Glede na navedeno, tako z metodološkega kot praktičnega vidika, številni strokovnjaki s področja vodenja kakovosti menijo, da je primerno zgraditi strategijo razvoja IT podjetij, kot sledi:

Najprej razviti in implementirati QMS po modelu ISO 9001:2000. (Konec koncev je večina podjetij, ki so zdaj na 4. in 5. stopnji SW-CMM, najprej šla skozi uskladitev svojih procesov z modelom ISO. Kot kaže praksa, je ta najboljša možnost v smislu obvladovanja razvoja QMS in zmanjševanja tveganj).

In šele nato začnite razvijati in izvajati ključne procese modela SW-CMM in po potrebi modela CMMI.

Da bi razumeli, kako je to res pravilno, primerjajmo te modele.

1. Pregled prosilcev.

Preživimo kratek pregled najbolj priljubljeni standardi, ki jih IT podjetje lahko uporablja za optimizacijo svojih poslovnih procesov.

ISO9001. Najbolj priljubljen, zlasti v Evropi, je ISO 9001(2)

Hkrati pa metodično, v celoti v skladu z gradbeno disciplino zapleteni sistemi, standard ISO 9001 zagotavlja po eni strani konstrukcijo organizacijski sistem"od zgoraj navzdol": od ciljev podjetja in njegove politike - do organizacijske strukture in oblikovanja poslovnih procesov, na drugi pa - iterativnega razvoja organizacijskega sistema skozi mehanizme merjenja in izboljševanja.

Poenostavljena "kakovost" v skladu s serijo standardov ISO 9000 je situacija, v kateri potrošniki od proizvajalca prejmejo izdelke, ki izpolnjujejo njihove neposredne zahteve in implicitna pričakovanja. Zato vodenje kakovosti v skladu z ISO 9000 vključuje uporabo t.i. "procesni pristop", ko se modelira in izvaja najbolj optimalna veriga "transformacij-procesov", ki zagotavlja, da proizvajalec zazna potrebe potrošnikov in jih uteleši v katerem koli izdelku brez izkrivljanja.

Številne organizacije za razvoj programske opreme uspešno uporabljajo to dobro znano serijo standardov ISO 9000. Nova različica standardi te serije so bili izdani leta 2000 in že vsebujejo koncepte, kot so procesni pristop, analiza in merjenje, izboljšanje procesov, izposojeni iz modela CMM in prej odsotni v prejšnjih različicah ISO 9000. Res je treba opozoriti, da so standardi te serije so univerzalne - niso osredotočene na nobeno specifično industrijo, ne upoštevajo posebnosti IT sfere in so v tem smislu seveda glede na stopnjo specifikacije opazno slabše od CMM. Poleg tega ISO 9000 ne pomeni nikakršnih stopenj (stopenj) skladnosti in s tem otežuje določitev »pravih« zmogljivosti organizacije in s tem tudi načinov njihovega nadaljnjega razvoja.

CMM(Capability Maturity Model) je razvil Inštitut za programsko inženirstvo na Univerzi Carnegie Mellon (ZDA) in opisuje model zrelosti razvojnega procesa. programsko opremo v podjetjih (3). V okviru tega modela je za vsako podjetje mogoče primerjati določen nivo (ena od petih možnih), ki kaže na doseženo kakovost procesa razvoja programske opreme. Ker so bili ti standardi razviti predvsem za poenostavitev postopka izbire izvajalca za Ministrstvo za obrambo ZDA, se osredotočajo na procese vodenja projektov programske opreme, medtem ko so tehnični vidiki razvoja manj zajeti.

V SW-CMM v.1.1 (Model zrelosti zmogljivosti za programsko opremo) je 316 ključnih praks. Ključne prakse so, kaj je treba implementirati v podjetju in na kaj bo pozorna skupina za ocenjevanje procesov. Združeni so v področja – Key Practices Areas (KPA) – to so že sklopi medsebojno povezanih procesov, ki ob skupnem izvajanju vodijo k doseganju določenega niza ciljev.

CMMI(Capability Maturity Model Integration) - nadaljnji razvoj modela CMM. V različici CMMI-SE / SW 1.02 (CMMI za sistemski inženiring / programsko inženirstvo), morda najbolj primeren za razvijalce programski sistemi, - število ključnih praks doseže 417.

Povečanje ključnih praks je povezano s samim namenom razvoja CMMI – model naj bi pomagal preprečiti težave, povezane z uporabo različnih industrijskih modelov CMM.

(Od leta 1991 so bili CMM razviti za različne aplikacije, najpomembnejši so:

Model zrelosti procesa razvoja programske opreme (Capability Maturity Model for Software - SW-CMM)
- model zrelosti procesa za reinženiring sistemov (vmesni standard zavezništva elektronskih industrij - EIA/IS 731)
- model zrelosti integriranih procesov razvoja izdelkov, model zrelosti integriranega razvoja izdelkov - IPD-CMM)

Na podlagi teh modelov je bil zgrajen CMMI. Absorbirala je najboljše od teh modelov in odpravila dvoumnost pri interpretaciji nekaterih konceptov zaradi prisotnosti številnih modelov – zato se je število ključnih praks znatno povečalo).

Jasno je, da se je to izkazalo za bistveno težjega modela - glej sl. riž. eno, ki poleg tega še ni bil dovolj preizkušen v praksi (izšel je šele leta 2002). V zvezi s tem so po mojem mnenju pri izvajanju modela možna velika tveganja, povezana tako z neupravičenimi izgubami pri hitrosti razvoja programske opreme kot s hkratnim nedvoumnim povečanjem stroškov dela za delovanje (in podporo) implementiranega KPA. - glej. Slika 1. Kot praktiku, ki je že zgradil QMS v treh različnih IT podjetjih, se mi zdi, da je v modelu CMMI očitno kršeno ravnovesje med potrebnim in zadostnim – kadri IT podjetja (in to kot pravilo, večinoma "umetniki kode") preprosto "ne bodo sprejeli" takšnega števila nadzorovanih predpisov (obstaja zelo veliko tveganje za izgradnjo "Potemkinove vasi")!

riž. 1 Primerjava sestave KPA v modelih CMM in CMMI.

Poleg tega bo ocena za CMMI bistveno dražja, odkar je odobrena SEI Glavni ocenjevalec" ov bo še vedno zelo malo, te storitve pa bodo veliko dražje kot pri ocenjevanju skladnosti z modelom CMM.

Poleg tega je veliko tujih strokovnjakov s področja vodenja kakovosti (s katerimi se trenutno popolnoma strinjam) precej skeptično do CMMI v kontekstu njegove uporabnosti za implementacijo v malih in srednje velikih organizacijah (prav takšne organizacije so tipične za Rusijo). ). Obstaja celo mnenje, da bo moral SEI čez nekaj časa bodisi izdati prilagojen SW-CMM v.2, bodisi narediti nekaj podobnih korakov. tiste. če trg ne sprejme modela in takšni predpogoji v času pisanja tega članka že obstajajo, se bo morala SEI prilagoditi zahtevam trga.

Glede na navedeno se zdi primerno analizirati že omenjeno ravnovesje, kaj je potrebno in zadostno v vseh teh osnovnih modelih QMS.

Narišimo ga v naslednjih koordinatah (glej sl. riž. 2) :

stopnja regulacije razvojnih procesov - označimo ta koncept - RP,

verjetnost doseganja načrtovanih rezultatov - označite ta koncept - PQ.

Na sl. 2 je prikazana strokovna ocena ravnotežja stopnje regulacije in verjetnosti doseganja načrtovanih rezultatov, ki jo je izvedel avtor na podlagi rezultatov prakse implementacije zahtev teh modelov pri razvoju in implementaciji PS (programske opreme). orodja).

V matematičnem smislu je vrednost izpeljanke: F(Q) = dPQ \ dRQ(povečanje učinkovitosti pri doseganju kakovosti dPQ s povečanjem stroškov delovnega časa za podporo izpolnjevanju zahtev dRQ), se zmanjša v naslednjem zaporedju : ISO 9000, CMM, CMMI.

Zato sl. 2 jasno in preprosto pojasnjuje:

priljubljenost modela ISO 9000,

pravilnost metodologije: najprej ISO in šele nato, če je potrebno, CMM,

nekaj skepticizma glede učinkovitosti modela CMMI.

riž. 2 Analiza ravnotežja med stopnjo regulacije in verjetnostjo doseganja načrtovanih rezultatov (po avtorjevi strokovni oceni)

Poglejmo si še en vodnik, ki se pogosto uporablja v IT podjetjih in bo omenjen v nadaljevanju pri analizi vprašanj prakse implementacije QMS.

to je PMBoK(Vodnik po vodenje projektov Zbirka znanja) je Projekt Management Institute, ki je vsrkal nabrano znanje s področja projektnega vodenja. Najnovejša različica dokumenta je bila objavljena leta 2000 in je hkrati dobila status standarda ameriškega inštituta za standarde ANSI (čeprav standarda ANSI in IEEE formalno veljata za ameriške, je večina od njih de facto mednarodne narave). Pomembna značilnost PMBoK je, da obravnava vodenje projektov v splošnem smislu, ne da bi bil vezan na posebna področja, kot je IT, in ga zato ni mogoče uporabiti samostojno - spodaj bomo razmislili, kakšen učinek ima to, če se uporablja v povezavi z ISO 9000.

Poglejmo zdaj, kako so zahteve že priljubljenega standarda ISO 9001:2000 v korelaciji s splošnimi lastnostmi vse bolj priljubljenega modela HMM. {3}- cm. riž. 3.

riž. 3. Skladnost med splošnimi lastnostmi CMM in elementi ISO 9001:2000

Za vsako raven HMM, kot je navedeno zgoraj, je značilen niz področja ključnih procesov - KPA (Key Process Areas) - cm. sl.3. Doseganje vseh ciljev znotraj KPA za določeno raven CMM ugotavlja skladnost organizacije s to ravnjo. Če je vsaj en cilj od vsaj enega KPA ker raven CMM ni dosežena, potem organizacija te ravni CMM ne more doseči. KPA lahko razdelimo v tri kategorije: menedžerji , organizacijski in zagotavljanje (cm. riž. 4).

CMM ne opredeljuje vseh procesov, pomembnih za razvoj programske opreme; izpostavlja le tiste, ki so potrebni za doseganje ravni SMM in so vključeni KPA. Vsak KPA je razčlenjeno na 5 skupnih značilnosti: zavezanost k izvedbi (Comment to perform); Sposobnost izvajanja; Izvedene dejavnosti; Merjenje in analiza (Measurement and Analysis); Preverjanje izvajanja

Splošna lastnina" Izvedena dejanja" opisuje ukrepe, ki jih je treba izvesti za dosego ciljev KPA, preostale štiri splošne lastnosti opisujejo formalne dejavnike, ki so del procesa organizacijska kultura. Popolna izvedba vsega ključne tehnike (ključna praksa) vseh skupnih lastnosti zagotavlja doseganje ciljev KPA. Ključne operativne prakse opisujejo, kaj naj postane delovni tok (ali procesni element ali del infrastrukture), vendar ne opredeljujejo, kako doseči ( posebne tehnologije ali tehnike), čeprav so za nekatere tehnike podana splošna priporočila. Za različni pogoji enak rezultat je mogoče doseči na različne načine. Raje je splošna načela delo kot posebna dejanja.

Zaporedna izvedba skupnih lastnosti dejansko izvaja cikel izboljšanja poslovnega procesa (Business-process Improvement - BPI-cm. riž. 5.), tj. nenehno izboljševanje poslovnih procesov (BP).

riž. 5. Cikel stalnega izboljševanja poslovnih procesov po modelu CMM in ISO 9000:2000.

Želja po pridobitvi certifikata o skladnosti v najkrajšem možnem času sili svetovalna podjetja in strokovnjake, ki se ukvarjajo z vodenjem kakovosti, da uporabljajo fleksibilnost in okvirne zahteve vseh zgoraj naštetih modelov na visoki ravni za lastne "sebične" namene.
Zaradi tega vsiljevanja dogodkov ima organizacija, na primer, ki je prejela certifikat ISO 9000:2000, le minimalni zahtevani nabor procesov za skladnost z ISO 9001 in ne vseh procesov, ki jih podjetje potrebuje za delovanje. učinkovito - glej spodaj. riž. 2. Poleg tega stopnja podrobnosti procesov morda ne zadošča za jasno razumevanje dogajanja znotraj procesov in kdo je odgovoren za katere naloge znotraj procesa.
AT najboljši primer le nekaj testnih projektov je šlo skozi nove postopke, čez nekaj časa pa postane jasno, da jih je treba popraviti in dopolniti. Pogosto se takoj po certificiranju QMS na procese pozabi do naslednje opazovalne revizije, pri čemer se pozabi na porabljene finančna sredstva in navdušenje osebja.
Ko delujete kot neodvisni revizor, je zelo težko dokazati, da sprejeta raven podrobnosti procesa očitno ne zadostuje za učinkovito delovanje QMS podjetja. A nasprotno je v času, namenjenem za presojo ISO 9000, izredno težko dokazati nasprotno (to se lahko zelo uspešno uporabi pri nasprotovanju revizorju). Praksa kaže, da je nemogoče hitro zgraditi učinkovite procese niti 3. stopnje zrelosti (kot tudi procese, ki temeljijo na ISO 9000).
Da bi to dosegli, ni dovolj samo opisati procese ob upoštevanju zahtev izbranega modela. Glavna težava je v tem, da preoblikovati proizvodno kulturo znotraj organizacije .

In to je nemogoče storiti z močno voljno odločitvijo vodstva. Zato je pristop, ki je opredeljen v CMM, preprosto bolj izvedljiv in realističen kot v modelih ISO 9000 – glej. riž. 5.

Poglejmo zdaj, kako je v praksi mogoče zgraditi QMS, ki je združljiv z obema modeloma.

Strokovna ocena stopnje pokritosti ključnih procesov CMM z zahtevami ISO 9000:2000 v skladu z oceno avtorjev CMM (4) je prikazana v sl.6.

Sama ocena je bila izvedena po dveh koordinatah:

stopnja razpoložljivosti (v %) skladnosti razvojnih procesov (SWP) s stopnjo zrelosti znotraj CMM - " zadostnost";

stopnja možnosti (v %) takšne zadostnosti, ki daje ISO 9000:2000 - " možnost".

Kot je razvidno iz riž. 6, Ustvarjajo zahteve ISO 9000:2000 prava priložnost da doseže celo zgornjo (CMM raven 5) stopnjo zrelosti SWP.

V smislu že zagotavljanja zrelosti SWP vsaj tretje stopnje (CMM Level 3) je treba QMS po modelu ISO 9000:2000 nekoliko izboljšati - in sicer razviti in implementirati še dva organizacijska postopka. ( Opredelitev organizacijskega procesa in osredotočenost) in postopek splošno upravljanje (integrirano upravljanje programske opreme ), katerih vsebina za nobeno IT podjetje ni težka.

A mogoče in potrebno je iti še dlje (CMM Level 4) - na primer v oklepaju je ocena avtorja tega članka (v istih koordinatah - razpoložljivost in zmogljivost), ki ustreza QMS po ISO 9000 :2000 model, v katerem procesno pokrajino QMS dopolnjuje procesno vodenje projektov v skladu z že zahtevami drugega zgoraj omenjenega standarda P.M. Bok- to vam bo pomagalo bistveno povečati zrelost še tako SWP, kot:

Spremljanje napredka projektov (Sledenje in nadzor projektov programske opreme);

• Projektno načrtovanje (Projektno načrtovanje programske opreme);

Splošno upravljanje programske opreme (Integrirano upravljanje programske opreme);

Vodenje procesov s kvantitativnimi presojami (Quantitative process management).

riž. 6. Strokovna ocena stopnje pokritosti ključnih procesov CMM z zahtevami ISO 9000:2000

Kot je razvidno iz sl.6., je model CMM po svojih načelih zelo blizu QMS, zgrajenemu po standardu ISO 9001:2000 in dopolnjen s procesi vodenja projektov v skladu z PM BoK..

Ker ne delaš dodatno delo ob hkratnem certificiranju po ISO 9000 in naknadnem ocenjevanju po CMM priporočam, da pri definiranju svojih proizvodnih procesov vključite (ali se morda omejite nanje – navsezadnje so to proizvodni procesi za IT podjetje!) Vsi so nujni v modelu CMM KPA. Tako podjetje hkrati:

izpolnjuje zahteve ISO 9001:2000 o izvajanju procesnega pristopa;

vse potrebne dokumente CMM procesi ( KPA);

izpolnjuje številne pomembne zahteve ISO 9001:2000 kot:

upravljanje procesov, ki temelji na meritvah (Kvantitativno upravljanje procesov);

Upravljanje dobaviteljev na podlagi upravljanja s podizvajalci ( Upravljanje s podizvajalci programske opreme );

analiza zahtev potrošnikov na podlagi upravljanje zahtev ( Upravljanje zahtev );

temelji na upravljanju človeških virov Programi usposabljanja osebja (Program usposabljanja );

upravljanje komunikacije na podlagi gradnjo formalnih modelov organizacijskih procesov ( Opredelitev organizacijskega procesa );

sproži mehanizem za izboljšanje (Načrtuj-Dо-Preveri-ukrep) vse opisane procese (SWP) z doslednim izvajanjem vseh petih Skupne lastnosti-cm. riž. 5.

Če torej uporabimo KPA CMM kot BP in uporabimo zahteve za postopke vodenja projekta razvoja PS P.M.BoK, potem je tako zgrajen QMS mogoče v celoti oceniti CMM Raven 4 - glej. riž. 7.

riž. 7. Shema za doseganje 4. stopnje CMM s skupno uporabo modela QMS po ISO 9000 in vodnika PM BoK 2000.

Za zaključek, zaradi jasnosti (v avtorskem slogu) predstavljam diagram delovanja QMS IT podjetja z dosledno implementacijo modelov ISO 9000 in CMM – glej sl. riž. osem.

riž. 8. Shema delovanja QMS z dosledno implementacijo ISO 9000 in modelov CMM (avtorska stilizacija)

Pri tem je pomembno razumeti, da sta tako CMM kot ISO 9001:2000 samo orodji za nenehno izboljševanje.

Tako naj bi certificiranje po standardu ISO 9001:2000 in potrditev certifikata prispevala k rasti kakovosti procesov podjetja, pri čemer je merilo za oceno rasti kakovosti procesov, da podjetje doseže novo raven. bpi, to pomeni, da je njihovo vrednotenje že točno po modelu CMM {3}.

Literatura

"Ocena kakovosti programske opreme", V. Lipaev, Sinteg, 2001

ISO 9001:2000. Sistem vodenja kakovosti. Zahteve.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Model zrelosti zmogljivosti za programsko opremo (SW-CMM), različica 1.1. // CMU/SEI-93-TR-024, februar 1993.

Opomba: Podrobno je preučen nabor idej, na katerih temelji verjetno najbolj znana metodologija za izboljšanje procesov razvoja programske opreme, CMM. Analizirana je logika in struktura HMM. Prikazana je povezava med HMM in predhodno raziskanimi procesnimi modeli.

Čudovito praktično orodje, ustvarjeno v okviru procesni pristop na opis dejavnosti projektantska organizacija zlasti organizacija, ki se razvija Informacijski sistemi, prikazuje metodologijo HMM. CMM je kratica za Capability Maturity Model, kar v grobem pomeni "model zrelosti sistema upravljanja". V literaturi se CMM pogosteje omenja kot model organizacijske zrelosti in tej tradiciji bom sledil tudi jaz.

Zgodovina nastanka SMM je naslednja. Konec 80. let. prejšnjega stoletja je obrambno ministrstvo ZDA naročilo Institute of Software Engineering 1Eng. SEI - Inštitut za programsko inženirstvo Univerza Carnegie Mellon dela na sistemu meril za izbiro podizvajalcev pri projektih razvoja programske opreme. Delo je bilo končano leta 1991 in rezultat je bil CMM. Takoj moramo narediti pridržek, da model ne vsebuje nobenega finančnega, gospodarskega, političnega, organizacijskega kriterij izbora podizvajalec, pa tudi merila za možnost sprejema na tajno delo (verjetno takšne naloge niso bile postavljene). Govorimo le o kriterijih, ki opisujejo sposobnost potencialnega podizvajalca v smislu razvoja programskih sistemov.

Struktura CMM

Ustvarjalci modela so procese organizacije vzeli za osnovo za ocenjevanje sposobnosti organizacije za kakovostno opravljanje dela, kar (zmožnost) smo imenovali zrelost. Nato so naredili nekaj netrivialnih predpostavk, ki so jih kasneje številni IT strokovnjaki (in morda večina) sprejeli in priznali kot poštene.

Predpostavka 1. Obstajajo kvalitativno različne stopnje zrelosti projektantska organizacija razvijajo Informacijski sistemi(v modelu HMM je pet takih ravni).

Predpostavka 2. Vsaka razvojna organizacija je zainteresirana za prehod na višjo stopnjo zrelosti (ne samo zato, da bi povečala svoje možnosti v boju za pogodbe ministrstva za obrambo, ampak tudi zaradi lastnega izboljšanja).

Predpostavka 3. Prehod je možen le na naslednjo stopnjo po vrsti. Nemogoče je "skočiti" čez raven (natančneje, tveganja za organizacijo se hkrati močno povečajo).

Tako ravni tvorijo "lestev", po kateri se organizacija vzpenja kot lastnega razvoja. Za vsako raven je značilna določena sestava in lastnosti procesov organizacije. SMM "Level Ladder" je bila splošno sprejeta in razširjena. Evo, kako izgleda.

Stopnja 1 "Začetnik". Za celoten proizvodni proces je značilno, da nastaja vsakič za določen projekt, včasih pa celo kaotičen. Opredeljenih je le nekaj procesov, uspeh projekta pa je odvisen od truda posameznikov.

2. stopnja "ponovljiv". Vzpostavljeni so glavni procesi vodenja projektov, ki vam omogočajo spremljanje stroškov, spremljanje urnika dela in funkcionalnosti ustvarjenega projekta. programska rešitev. Vzpostavil procesno disciplino, potrebno za ponovitev preteklih uspehov v podobnih projektih razvoja aplikacij.

3. stopnja "določeno". Proizvodni proces je dokumentiran in standardiziran tako za upravljanje kot za inženiring. Ta proces je integriran v standardni proizvodni proces organizacije. Vsi projekti uporabljajo odobreno prilagojeno različico standardnega operativnega procesa organizacije.

Stopnja 4 "Upravljano". Zbrani so podrobni kvantitativni kazalniki proizvodnega procesa in kakovosti ustvarjenega izdelka. Tako proizvodni proces kot izdelki se ocenjujejo in nadzorujejo s kvantitativnega vidika.

Stopnja 5 "Optimizacija". Nenehno izboljševanje procesa se doseže s kvantitativno povratne informacije s procesom in implementacijo naprednih idej in tehnologij v njem.

Kljub pomanjkanju strogosti zgornja definicija intuitivno najpogosteje ne vzbuja ugovorov. Poleg tega izkušeni strokovnjaki razumejo, zakaj so prehodi možni le na naslednjo raven, pa tudi zakaj se je za tak prehod sploh vredno prizadevati. Hkrati model HMM ne vsebuje nobene kvantitativne ali celo formalne utemeljitve takšnega pristopa, kar pa ne zmanjša njegove prednosti.

Nadalje, kot pravijo, je stvar tehnologije. Struktura modela je definirana (slika 7.1), podane so definicije in mukotrpno delo se začne natančno opisati vsak proces na vsaki ravni. Da bi ocenili praktično vrednost opravljenega, pojdimo skozi del te poti.

riž. 7.1.

Na sl. 7.1 vsebuje naslednje koncepte.

Skupina ključnih procesov. Kot je navedeno v (Paulk, et al., 1995), "vsaka skupina ključnih procesov opredeljuje blok povezanih dejavnosti, zaradi katerih se doseže niz ciljev, ki so pomembni za povečanje produktivnosti proizvodnega procesa. Za na primer za skupino ključnih procesov " Upravljanje zahtev"(Glej sliko 7.2) cilj je uskladiti zahteve projekta razvoja programske opreme med stranko in razvijalcem."

Ne v CMM posameznih procesov. Namesto tega obstajajo ločena dela, imenovana ključne prakse (glej spodaj), ki so med seboj povezana z vhodi in izhodi in služijo kot izvorni material za gradbene procese. CMM ne daje navodil o tem, kako naj bodo procesi strukturirani, to je povezovanje ključnih praks v logična zaporedja. Nabori ključnih praks se imenujejo skupine ključnih procesov.

riž. 7.2.

Skupine ključnih procesov v CMM so preslikane na stopnje zrelosti (slika 7.2), to pomeni, da vse prakse na ravni medsebojno delujejo le med seboj in ne sodelujejo s praksami na drugih ravneh. To vam omogoča, da zagotovite popolno izvedbo vseh procesov na določeni ravni in s tem povežete raven z zaključeno stopnjo razvoja organizacije.

Pridevnik "ključni" pomeni, da obstajajo procesne skupine(tj. nizi praks), ki niso ključni glede na določeno stopnjo zrelosti, torej niso povezani z doseganjem ciljev te stopnje (glej spodaj). Model HMM ne opisuje vsega procesne skupine v zvezi z razvojem in vzdrževanjem programske opreme . Opisuje le tiste skupine, ki so opredeljene kot ključne determinante produktivnosti proizvodnega procesa.

Cilji. Cilji v CMM niso povezani s procesi, temveč s skupinami ključnih procesov. Kot je navedeno zgoraj, se cilji dosegajo z izvajanjem ključnih praks. V CMM doseganje cilja pomeni, da se, prvič, po izvedbi ključnih praks doseže želeni rezultat, in drugič, doseže se precej dosledno. Način, na katerega se dosežejo cilji skupine ključnih procesov, se lahko razlikuje od projekta do projekta zaradi razlik v predmetno področje ali okolje.

Če so ti cilji uresničeni pri vseh projektih, potem to pomeni, da je organizacija dosegla stopnjo zrelosti proizvodnega procesa, ki je v korelaciji to skupino ključnih procesov.

Odsek. Razdelki (na vsaki ravni jih je pet in so vedno enaki) predstavljajo lastnosti skupin ključnih procesov, ki jih je treba implementirati na ustrezni ravni. Te lastnosti opisujejo, kako se procesi izvajajo in v kolikšni meri so legalizirani v organizaciji, torej uradno odobreni in usklajeni s korporativnimi postopki, politikami in drugimi procesi. Tukaj je pet razdelkov.

Izvedbene obveznosti

Opišite ukrepe, ki jih mora izvesti organizacija, da zagotovi, da je proces vzpostavljen in stabilen. Obveznosti glede uspešnosti se običajno nanašajo na vzpostavitev organizacijskih politik in podporo najvišjega vodstva.

Predpogoji

Opišite predpogoje, ki morajo biti izpolnjeni v projektu ali organizaciji za kompetentno izvajanje proizvodnega procesa; običajno povezana z viri, organizacijske strukture in zahtevano usposabljanje.

Operacije v teku

Razdelek Operacije v teku opisuje vsebinsko delo, ki ga je treba opraviti na tej ravni. Operacije, ki se izvajajo, običajno vključujejo ustvarjanje načrtov in izvajanje posebnih operacij, izvajanje in sledenje dela ter po potrebi sprejemanje korektivnih ukrepov.

Meritve in analize

Razdelek "Meritve in

»Vsaka skupina ključnih procesov je izražena s ključnimi praksami, katerih izvajanje prispeva k doseganju ciljev skupine. Ključne prakse opisujejo infrastrukturo in poslovanje, ki najbolj prispevajo k učinkovitemu izvajanju in vzpostavitvi skupine ključnih procesov.

Vsaka ključna praksa je sestavljena iz enega stavka, ki mu pogosto sledi podrobnejši opis, ki lahko vključuje primere in pojasnila. Ključne prakse, včasih imenovane ključne prakse najvišji nivo, vzpostaviti osnovne politike, postopke in operacije za skupino ključnih procesov. Komponente natančen opis pogosto imenovani podprakse."

Ključne prakse opisujejo, KAJ je treba narediti, vendar jih ne smemo jemati kot dogmo o tem, KAKO je treba doseči cilje. Cilje ključne procesne skupine je mogoče doseči z alternativnimi praksami. Razlaga ključnih praks mora biti razumna in omogoča doseganje ciljev skupine ključnih procesov učinkovit način, čeprav morda formalno in drugače od priporočenega CMM.

Pogled na aktivnosti upravljanja IT, pri katerih se namesto procesov upoštevajo njihove komponente - ključne prakse, procesi pa so prisotni le virtualno, kot nekaj, kar je mogoče zgraditi iz ključnih praks, je na prvi pogled videti nekoliko eksotično. Doslej je bila naloga izboljšanja upravljanja IT rešena z uvedbo že pripravljenih procesov iz referenčnega modela procesov. Zdaj obstaja nabor ravni, ki vsebuje različne (tj. niso integrirane v procese) ključne prakse in priporočeno zaporedje za premikanje po ravneh. Upravljanje IT se po mnenju CMM izboljšuje, ko se premakne na višjo stopnjo zrelosti. Kaj se zgodi s to promocijo?

V definicijah nivojev (glej sliko 7.2) se je pojavila takšna stvar, kot je "proizvodni proces". Prisotna je tudi v opredelitvi skupine ključnih procesov in to ni naključje. Proizvodni proces ali, kot se v CMM pravilno imenuje standard Postopek izdelave Organizacije (OSS) so eden od osrednjih konceptov celotnega modela.

Novembra 1986 je Ameriški inštitut za programsko inženirstvo (SEI) v sodelovanju z Mitre Corporation začel razvijati raziskavo zrelosti procesa razvoja programske opreme, ki naj bi pomagala izboljšati njihove notranje procese.

Razvoj tega pregleda je spodbudila zahteva zvezne vlade ZDA po metodi za ocenjevanje podizvajalcev za razvoj programske opreme. Prava težava je bila nezmožnost upravljanja velike projekte. V mnogih podjetjih so bili projekti izvedeni znatno pozno in presegajo proračun. Treba je bilo najti rešitev za ta problem.

Septembra 1987 je SEI izdal povzetek procesov razvoja programske opreme, ki opisuje njihove stopnje zrelosti, kot tudi vprašalnik, namenjen ugotavljanju področij v podjetju, kjer so bile potrebne izboljšave. Vendar pa je večina podjetij ta vprašalnik obravnavala kot končni model, zaradi česar je bil vprašalnik po 4 letih preoblikovan v pravi model, Capability Maturity Model for Software (CMM). Prvo različico CMM (verzija 1.0), izdano leta 1991, so leta 1992 revidirali udeleženci delovnega srečanja, ki se ga je udeležilo približno 200 strokovnjakov za programsko opremo in člani skupnosti razvijalcev.

Posledično je bil izdan Standard CMM, različica 1.1, ki se še vedno aktivno uporablja po vsem svetu.

riž. 1. Globalni vpliv uporabe SMM

Razlogi za to zanimanje za SMM so jasni. Kljub temu, da se tako sami razvijalci programske opreme kot njihovo vodstvo pogosto zelo zavedajo svojih nenehnih težav, se ne morejo strinjati, katere spremembe podjetje sploh potrebuje. Brez oblikovanja enotne strategije izboljšav vodstvo ne more najti medsebojnega razumevanja z zaposlenimi glede najpomembnejših nalog izboljšav. Da bi dosegli največji rezultat vloženega truda v izboljšanje procesov, je potrebna fazna razvojna strategija, ki bo zrelost razvojnih procesov izboljševala postopoma, na evolucijski način.

Nenehno izboljševanje procesov temelji na postopnem gojenju kulture podjetja in ne na implementaciji revolucionarnih novosti. CMM zagotavlja načrt za to postopno izboljšanje, razdeljeno na 5 stopenj zrelosti procesa. Teh 5 stopenj je lestvica za ocenjevanje stopnje zrelosti procesov razvoja programske opreme v podjetju in za merjenje njihovih parametrov.

riž. 2. Načelo postopnega povečevanja stopnje zrelosti: možnosti za razvoj organizacije

Tu so glavne značilnosti vsake stopnje:

1. Začetno - razvojni proces je kaotičen. Nekaj ​​procesov je opredeljenih in uspeh projektov je odvisen od posameznih akterjev.
2. Ponovljiv - Vzpostavljeni osnovni procesi vodenja projektov: sledenje stroškov, urnik dela in funkcionalnost. Poenostavljeni nekateri procesi, potrebni za ponovitev prejšnjih dosežkov na podobnih projektih (projekti s podobnimi aplikacijami).
3. Definirano - razvoj programske opreme in procesi vodenja projektov so opisani in implementirani v enoten sistem procesi podjetja. Vsi projekti uporabljajo standardni proces razvoja programske opreme in podpore za organizacijo, prilagojen določenemu projektu.
4. Upravljano - Zbira podrobne kvantitativne podatke o delovanju razvojnih procesov in kakovosti končni izdelek. Analizirata se pomen in dinamika teh podatkov.
5. Optimizacija – Nenehno izboljševanje procesov temelji na kvantitativnih podatkih o procesih in na poskusni implementaciji novih idej in tehnologij.

Uvod v SW-CMM

(Izboljšanje zrelosti procesov razvoja programske opreme na podlagi modela zrelosti zmogljivosti inštituta za programsko inženirstvo za programsko opremo)

Tečaj je namenjen:
Za vodje podjetij za razvoj programske opreme, vodje oddelkov in projektov za razvoj programske opreme ter strokovnjake za kakovost, ki jih zanima:

izboljšanje preglednosti obstoječih proizvodnih procesov;

povečanje produktivnosti procesov in podjetja kot celote;

znižanje stroškov proizvodnje in obsega obstoječe »skrite« proizvodnje;

izboljšanje ugleda podjetja v profesionalnem okolju;

odpiranje novih trgov za izdelke.

2.1 Stroški, trajanje in rezultati. Statistika industrije
2.2 Donosnost naložbe v CMM

3.1 TQM (Popolno upravljanje kakovosti), SPI (izboljšanje procesov programske opreme) in najboljše poslovne prakse kot osnova CMM
3.2 Osnovni koncepti TQM. Uporaba pristopov TQM v proizvodnji programskih izdelkov
3.3 Prednosti in tveganja modela za izboljšanje procesa CMM
3.4 Koncept procesa. Glavne sestavine procesnega pristopa
3.5 Stopnje zrelosti procesa

9.1 Sistem standardov za IT industrijo (načrt)
9.2 Razmerje ISO do CMM, Racionalni poenoten proces, Vodenje projekta
9.3 Aplikacija CMM za majhne organizacije
9.4 Česa ni v SMM
9.5 Dokumenti in postopki

10.1 Končni pregled SW-CMM. Porazdelitev po svetu. Glavne težave
10.2 CMMI (Capability Maturity Model Integration) - nadaljnji razvoj modela CMM

Komplet diapozitivov, praktična učna gradiva, dodatna gradiva za samostojno učenje.

Celoten nabor dokumentov o SW-CMM (besedilo standarda, metode ocenjevanja, industrijske statistike, primeri dokumentov)

Praktični tečaj o tehnologiji implementacije modela SW-CMM v IT podjetja

Kratka opomba:
Namen tega tečaja je pomagati podjetjem, da samostojno in kompetentno načrtujejo in izvajajo delo pri implementaciji modela izboljšanja zrelosti procesa, pomagajo preprečiti pogoste napake in težave, ki so nastale med izvajanjem.

Tečaj je namenjen:
Tečaj je namenjen vodjem podjetij in oddelkov, ki se ukvarjajo z razvojem programske opreme, vodjem projektov, vodjem kakovosti in drugim, ki jih zanima izboljšanje kakovosti svojega razvoja in certificiranje svojih procesov za CMM.

Pregled priznanih standardov na področju vodenja kakovosti za IT (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. Na CMM prek ISO?

5 evolucijskih stopenj pri upravljanju organizacijskih procesov. Razlaga modela zrelosti zmogljivosti funkcionalnost). CMM

Model zrelosti zmogljivosti CM-CEI organizacijski model, ki opisuje 5 evolucijskih stopenj (stopenj), na katerih se vodijo procesi v organizaciji.

Prvotno ustvarjen za razvoj programske opreme, bistvo modela zrelosti zmogljivosti je, da mora biti organizacija sposobna sprejeti in podpreti svoje programske aplikacije. Model predlaga tudi konkretne korake in pobude, ki bodo organizaciji pomagale pri rasti na naslednjo raven.

5 stopenj modela zrelosti sposobnosti

Začetni (procesi so ad hoc, kaotični ali pa jih je dejansko le nekaj definiranih) Ponovljivi (osnovni procesi so vzpostavljeni in obstaja disciplina, da se teh procesov držimo) Definirani (vsi procesi so definirani, dokumentirani), poenoteni in integrirani) Upravljani ( procesi se merijo z združevanjem podrobnih podatkov o procesih in njihovi kakovosti) Optimiziranje (Optimiziranje) ( stalen razvoj proces s kvantitativnimi povratnimi informacijami in testiranjem novih idej in tehnologij)

Model razvoja programske opreme

CMM opisuje načela in prakse, ki so osnova koncepta zrelosti programskega procesa. Zasnovani so tako, da pomagajo podjetjem za razvoj programske opreme in prodajnim podjetjem, da izboljšajo sofisticiranost svojih procesov programske opreme na evolucijski način. Začenši od ad hoc, kaotičnih procesov, naprej do zrelih, discipliniranih procesov programske opreme. Poudarek je na prepoznavanju ključnih procesnih področij in zglednih praks, ki lahko tvorijo disciplinirane procese programske opreme. Koncept zrelosti CMM ustvarja kontekst, v katerem:

Vaje je mogoče ponoviti. Če neke operacije ne ponovite, je ne bi smeli izboljšati. Obstajajo pravila, postopki in prakse, ki prisilijo organizacijo k izvajanju in doslednemu izvajanju. Najboljše prakse za organizacijo proizvodnega dela se lahko hitro delijo med skupine. Prakse so opredeljene tako, da omogočajo izmenjavo med projekti in s tem zagotavljajo nekaj standardizacije za organizacijo. Odstopanja pri izvedbi teh metod so čim manjša. Za naloge so postavljeni kvantitativni cilji; meritve pa so vzpostavljene, izdelane in vzdrževane kot osnova za vrednotenje. Prakse se nenehno izboljšujejo za izboljšanje zmogljivosti (optimizacija).

Model zrelosti zmogljivosti je uporaben ne le za razvoj programske opreme, temveč tudi za opis evolucijskih ravni organizacij na splošno in za opis ravni upravljanja, ki jo je organizacija uvedla ali želi doseči.

Struktura modela razvoja značilnosti

Stopnje zrelosti so večplasten koncept, ki zagotavlja doslednost discipline, ki je potrebna za doseganje nenehnih izboljšav. Tu je pomembno omeniti, da organizacija razvije sposobnost vrednotenja posledic nove prakse, tehnologije ali orodja. Zato ne gre za sprejemanje teh inovacij, temveč za to, kako ta inovativna prizadevanja vplivajo na obstoječe prakse. Podpira projekte, skupine in organizacije, tako da jim daje osnovo za sprejemanje informiranih odločitev. Ključna procesna področja – Ključno procesno področje (KPA) opredeljuje skupino povezanih dejavnosti, ki ob skupnem izvajanju dosegajo številne pomembne cilje. Cilji – Cilji ključnega procesnega področja opisujejo določbe, ki morajo obstajati za to ključno procesno področje. Predpise je treba izvajati na učinkovit in varen način. Obseg, v katerem so cilji izpolnjeni, kaže, kakšne sposobnosti je organizacija vzpostavila na tej ravni odličnosti. Cilji določajo obseg, meje in namen vsakega ključnega področja procesa. Splošne značilnosti – Splošne značilnosti vključujejo prakse, ki izvajajo in institucionalizirajo ključna procesna področja. Teh 5 vrst splošne značilnosti vključujejo: zavezanost izvajanju, sposobnost izvajanja, pobude, ki jih je treba izvesti, merjenje in analize ter nadzor izvajanja. Ključne prakse – Ključne prakse opisujejo infrastrukturne elemente in prakse, ki najbolj učinkovito prispevajo k izvajanju in institucionalizaciji ključnih procesnih področij.

Merila za opredelitev procesa

Merila za opredelitev procesa so nabor procesnih elementov, ki jih je treba vključiti v opis procesa programske opreme, da jih ljudje lahko uporabljajo v praksi. Za določitev meril morate zastaviti vprašanje - "Katere informacije o procesu programske opreme so potrebne za dokumentacijo?"

Uvod

Najpomembnejši del sodobnih kompleksnih sistemov so programski izdelki – intelektualna komponenta. Programski izdelki se danes uporabljajo za reševanje problemov upravljanja na skoraj vseh področjih človekove dejavnosti: v gospodarstvu, družbenem, vojaškem in drugih področjih. Zagotavljanje visoke kakovosti domačih programskih izdelkov med njihovim množičnim razvojem in dostavo za različna področja uporabe v državi in ​​na svetovnem trgu je postalo strateški cilj.

Trenutno obstajata dve skoraj samostojni področji standardizacije programskega inženiringa in zagotavljanja kakovosti programskih izdelkov, ki ju lahko pogojno imenujemo profili standardov ISO ( Mednarodna organizacija standardizacija) in model zrelosti SEI (US Software Engineering Institute). Prvi so precej v celoti zastopani v [ , ], drugi pa v [ , ]. Glavna vsebina članka je posvečena modelom zrelosti.

Da bi zagotovili konkurenčnost v svetu kompleksnih programskih izdelkov in možnost njihovega uspešnega izvoza, jih je treba razviti in certificirati v skladu z zahtevami profili mednarodnih standardov na podlagi ISO 9000:2000 oz modeli zrelosti - CMMI: 2003(Integracija modela zrelosti zmogljivosti - model ocenjevanja zrelosti integriranega programskega inženiringa). Ti dve smeri sta si metodološko zelo blizu in se deloma križata prek medsebojnih referenc.

Izboljšanje tehnično-ekonomskih kazalnikov in kakovosti programskih izdelkov ter preprečevanje napak in okvar je zagotovljeno z uporabo sodobnih tehnologij in sistemov programskega inženiringa. računalniško podprto oblikovanje. To so visoko zmogljive tehnologije, ki varčujejo z viri za ustvarjanje programskih kompleksov visoke kakovosti, zanesljivosti in varnosti, katerih cilj je zmanjšati skupne stroške virov za načrtovanje, implementacijo in vzdrževanje programskih orodij (PS). Za to je treba najprej uporabiti metode in orodja za analizo in načrtovanje, ki zagotavljajo konkretizacijo in čim bolj natančno predstavitev ciljev, namenov in funkcij že od začetka. življenski krog(LC) PS in preprečevanje širjenja morebitnih sistemskih okvar na naslednje stopnje razvoja. Takšne tehnologije programskega inženiringa omogočajo odpravo ali znatno zmanjšanje ravni sistemskih, algoritemskih in programskih napak v programskih izdelkih, ki se prenašajo v delovanje. Poleg tega so učinkoviti pri spreminjanju in vzdrževanju programske opreme ter pri spremembah zunanje okolje.

Za certificiranje kakovosti, zanesljivosti in varnosti uporabe kompleksnih, kritičnih sistemov so programski izdelki, ki se v njih uporabljajo, podvrženi certificiranje certificirani, problemsko usmerjeni testni centri ali laboratoriji. Takšne teste je treba izvajati, ko programi upravljajo zapletene, kritične procese ali obdelujejo tako pomembne informacije, da lahko pomanjkljivosti v njih ali nezadostna kakovost povzročijo znatno škodo. Certifikacijski testi bi morali ugotoviti skladnost programskih kompleksov z zahtevami dokumentacije in jim omogočiti delovanje v mejah sprememb parametrov zunanjega okolja, preučenih med preskusi. Za te vrste testov je značilna največja resnost in globina preverjanj in jih morajo izvajati strokovnjaki, neodvisni od razvijalcev in strank (uporabnikov).

Osnova za certificiranje naj bodo podrobni in učinkoviti programi in metode za testiranje programskih paketov na skladnost s standardiziranimi zahtevami kupcev, posebej zasnovani testni problemi in generatorji za njihovo oblikovanje ter visoka usposobljenost in avtoriteta preizkuševalcev. Uporaba v podjetjih-razvijalcih programskih izdelkov, certificiranih sistemov kakovosti za zagotavljanje življenjskega cikla PS na podlagi zahtev ISO 9000:2000 oz CMMI: 2003, zagotavlja visoko, trajnostno kakovostno upravljanje procesov in izdelkov njihovega življenjskega cikla, v mnogih primerih pa omogoča tudi olajšanje certificiranja končnega programskega izdelka. Zato naročniki kompleksnih programskih projektov izbirajo izvajalce, ki imajo certifikate, ki potrjujejo njihovo uporabo sistemov zagotavljanja kakovosti na podlagi prilagojenih profilov mednarodnih standardov ali modelov zrelosti.

Vrzeli v usposabljanju v metodah programskega inženiringa puščajo širok prostor za samovoljo strokovnjakov pri ocenjevanju kakovosti njihovega dela, pa tudi za pojav številnih napak in napak v programskih projektih. Povečanje kompleksnosti in odgovornosti sodobne naloge rešujejo programi, pa tudi morebitno škodo zaradi nezadostne kakovosti njihovih rezultatov, je bistveno povečala aktualnost obvladovanja metod popolnega, standardiziranega opisa zahtev glede lastnosti kakovosti in metod za merjenje njihovih realnih, doseženih vrednosti. na različnih stopnjah življenjskega cikla programske opreme. Potreba po poznavanju konceptov, definicij in metod za ocenjevanje značilnosti kakovosti programskih izdelkov se je močno povečala.

Hiter porast in zaplet programskih kompleksov vodita v nastanek velikih programskih ekip s strokovno delitvijo dela, v katerih je treba na enem projektu urediti usklajene dejavnosti skupin strokovnjakov. Obljube razvijalcev v pogodbah o dobavi visokokakovostne programske opreme v dogovorjenih časovnih okvirih se pogosto ne držijo. Pogosto se to zgodi zaradi dejstva, da naročnik in izvajalec ocenjujeta raven kakovosti po različnih merilih in se o tem vprašanju ne strinjata, pristop k ocenjevanju kakovosti programov pa ni dovolj formaliziran. Poleg tega včasih ni sposobnosti za ustrezno oceno sredstev, potrebnih za doseganje visokokakovostnih programov. Zaradi tega kakovost programskih izdelkov pogosto ostaja nizka, nezanesljiva in nekonkurenčna na mednarodnem trgu. Zato je najpomembnejša težava pri razvoju in uporabi mnogih sodobnih sistemov je usposabljanje in izobraževanje strokovnjakov s področja programskega inženiringa, uporaba mednarodnih standardov, ki prispevajo k visoki kakovosti programske opreme in njene zanesljive ocene z glavnim ciljem - izdelati projektne procese obvladljiva, in rezultati so predvidljivo. Treba je biti sposoben formalizirati zahteve in doseči specifične vrednosti lastnosti kakovosti delovanja in uporabe kompleksnih programskih paketov ob upoštevanju virov, ki so na voljo za zagotavljanje in izboljšanje te kakovosti.

Model zrelosti CMMI - 1.1 izpopolnjuje in izboljšuje prejšnje modele CMM(glej ), delno pa upošteva tudi osnovne zahteve obstoječih mednarodnih standardov na področju upravljanja programske opreme. Pomembna pozornost v CMMI je namenjen razvojnim procesom in upoštevanju ponovitev pri spreminjanju zahtev strank, njihovi sledljivosti do funkcij, komponent, testov in projektne dokumentacije. AT zadnji čas pojavile so se informacije o posodobitvi različice SEI različice iz leta 2003 CMMI-1.1 na podlagi zbranih izkušenj in povratnih informacij podjetij. Leta 2006 naj bi izdal novo, bistveno nadgrajeno različico modela CMMI-1.2, po katerem je treba različico 1.1 postopoma opustiti. Do konca leta 2007 naj uporabniki preidejo na različico CMMI-1.2, v prihodnje pa bo postalo obvezno formalizirano ocenjevanje kakovosti (certificiranje) podjetniške tehnologije na področju programskega inženiringa. Obdobje veljavnosti certifikata bo omejeno na tri leta. Stranke in razvijalci velikih programskih sistemov naj se na te spremembe pripravijo pred uradno objavo različice 1.2 s strani SEI.

Struktura in vsebina modela zrelosti CMMI - 1.1

Dve možnosti modela CMMI-1.1 zasnovan za zagotavljanje neprekinjeno vrednotenje niza procesov na določenem področju razvoja programske opreme oz fazno ocenjevanje in izboljševanje zrelosti podjetja, pa tudi za organizacijo življenjskega cikla programskih kompleksov nasploh. Modeli CMMI nuditi pomoč strokovnjakom pri organizaciji in izboljšanju njihovih izdelkov, pa tudi pri racionalizaciji in servisiranju procesov razvoja in vzdrževanja PS. Koncept teh modelov zajema upravljanje in vrednotenje zrelosti kompleksnih sistemov, programski inženiring ter procese ustvarjanja integriranih programskih produktov in izboljševanja njihovega razvoja. Sestavni deli kontinuirnih in stopenjskih modelov so si v veliki meri podobni in jih je mogoče izbrati in uporabiti v drugačni sestavi in ​​zaporedju uporabe, odvisno od lastnosti in značilnosti posameznih projektov.

Možnosti opisa modela so zgrajene po eni shemi, ki vključuje splošne razdelke:

• predgovor;
• 1 oddelek - uvod;
• Oddelek 2 - model komponent;
• Oddelek 3 - terminologija;
• 4. razdelek - vsebina ravni in glavne komponente vsake različice modela (razvoj ciljev in postopkov);
• Oddelek 5 - struktura interakcije procesov; štiri kategorije procesov v razdelku 7 so označene, njihov splošni pregled in sheme interakcij s procesi CMMI:
  • upravljanje procesov;
  • management - vodenje projektov;
  • inženiring (tehnologija);
  • podpora;
• Razdelek 6 - Uporaba modela CMMI- kratka priporočila za uporabnike o uporabi modela in usposabljanju; ugotovljena je združljivost in skladnost procesov modela z reguliranimi procesi prejšnjega modela CMM v delih 2 in 3 standarda ISO 15504.
• Razdelek 7 je zadnji, največji v vsakem standardu, zavzema približno 500 strani celotnega dokumenta, kar je več kot 700 strani. V tem razdelku so podana podrobna priporočila za izvedbo vsakega od v njem navedenih procesov, ki upoštevajo značilnosti posameznega modela.

Prva možnost(neprekinjen) model odraža dokument: Integracija modela zrelosti zmogljivosti (CMMI) za sistemski inženiring/programsko inženirstvo/integrirani razvoj izdelkov in procesov, različica 1.1, neprekinjeno zastopanje (CMMI-SE/SW/IPPD, V1.1, neprekinjeno). Model ocenjevanja zrelosti integriranega sistemskega inženiringa/programskega inženiringa/integriranih izdelkov in razvojnega procesa - neprekinjen pogled. V tem modelu je sedmi odsek sestavljen iz procesov:

• upravljanje procesov:
  • organizacija usposabljanja;
  • organizacija transformacije (spremembe) procesov;
  • organiziranje inovacij in širitev;
• vodenje projektov:
  • načrtovanje projektov;
  • spremljanje in nadzor projektnih procesov;
  • Upravljanje tveganj;
  • kvantitativno vodenje projektov;
• inženiring (tehnologija):
  • upravljanje zahtev;
  • razvoj zahtev;
  • tehnične rešitve;
  • integracija izdelkov;
  • preverjanje;
  • validacija (potrditev, odobritev);
• podpora:
  • upravljanje konfiguracije;
  • analiza in odločanje o spremembah;
  • analiza temeljnih vzrokov in rešitev problema (odprava napak).

Pet dodatkov zagotavlja:

AMPAK- sestavo uporabljenih literarnih virov in dokumentov, ki pa ne omenja standardov ISO;

AT- okrajšave;

Z- terminologija, ki temelji na glosarju ISO uporablja samo v štirih standardih ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - opisi zahtev in predlogi za oblikovanje komponent modela po stopnjah zrelosti;

E - seznam udeležencev razvoja CMMI- projekt.

V tem modelu je pozornost usmerjena na organizacijske procese, na načrtovanje, vodenje in nadzor procesov za izvajanje programskih projektov, na razvoj in obvladovanje zahtev za programske izdelke. Spodaj so primeri podrobnosti v CMMI nekateri od njih.

Načrtovanje projekta tako v tem kot v drugem modelu vključuje:

• ocena možna velikost(mere) programskega izdelka;
• ocena kompleksnosti funkcij in značilnosti projekta PS;
• opredelitev modela in stopenj življenjskega cikla programskega paketa;
• študija izvedljivosti projekta - določitev stroškov, delovne intenzivnosti in trajanja življenjskega cikla RTP;
• razvoj faznega urnika dela in proračuna projekta;
• analiza, identifikacija in ocena projektnih tveganj;
• načrtovanje in vodenje dokumentacije procesov in izdelkov v življenjskem ciklu projekta PS;
• načrtovanje in razporeditev tehničnih in človeških virov po fazah življenjskega cikla PS;
• načrtovanje zagotavljanja znanja in usposobljenosti ekipe strokovnjakov za izvedbo projekta;
• posplošitev in analiza sklopa načrtov za projekt PS;
• usklajevanje del in sredstev za faze življenjskega cikla s strani razvijalca z naročnikom projekta PS;
• dokumentiranje delovnega načrta in njegovo potrditev s strani vodje razvijalca projekta.

Procesi razvoja zahtev na programski izdelek so podobni procesom v obeh modelih in vključujejo:

• prepoznavanje dejanskih potreb stranke in uporabnikov po funkcijah in značilnostih programskega izdelka;
• razvoj in usklajevanje med naročnikom in razvijalcem začetnih, osnovnih zahtev za funkcije programskega produkta;
• določitev razpoložljivih virov in omejitev projekta programske zbirke;
• razčlenitev osnovnih začetnih zahtev za funkcije PS na nabor zahtev za komponente in teste programskega paketa;
• formalizacija zahtev za vmesnike med komponentami, z operacijskim in zunanjim okoljem;
• razvoj koncepta programskega produkta in scenarijev za njegovo uporabo;
• razvoj zahtev za posplošene značilnosti funkcionalne ustreznosti in uporabo funkcij programskega izdelka za predvideni namen.

Upravljanje zahtev oba modela vključujeta:

• doseganje nedvoumnega razumevanja zahtev za projekt PS s strani naročnika in razvijalcev;
• pridobivanje s strani naročnika od razvijalcev obveznosti, da izpolni vse svoje zahteve za programski izdelek;
• upravljanje sprememb zahtev za projekt PS, dogovorjenih med naročnikom in razvijalcem;
• zagotavljanje pravilnosti sprememb od splošnih zahtev za projekt PS do zahtev za komponente in posamezne procese;
• ugotavljanje in ugotavljanje neskladij med procesi razvoja projekta in zahtevami strank.

Druga možnost predstavi dokument: Integracija modela zrelosti zmogljivosti (CMMI) za sistemski inženiring/programsko inženirstvo/integrirani razvoj izdelkov in procesov, različica 1.1, postopna predstavitev (CMMI-SE/SW/IPPD, V1.1, postopno). Model ocenjevanja zrelosti integriranega sistemskega inženiringa/programskega inženiringa/integriranih izdelkov in razvojnega procesa - postopno uvajanje. Model temelji na ohranjanju koncepta petih stopenj zrelosti CMM[ , ]. Sestava procesov se praktično ponavlja zgoraj opisano za prvo različico modela, vendar v nekoliko drugačnem zaporedju in z relativno majhnimi dodatki.

Prva stopnja je značilna velika negotovost v sestavi in ​​vsebini procesov v različnih relativno enostavnih projektih, zato v dokumentu ni komentirana. Zato pri razjasnitvi in ​​podrobni vsebini procesov v fazni različici CMMI priporočljivo omejiti štiri glavne ravni:

• druga stopnja- formalizira osnovno upravljanje projekti:
  • upravljanje zahtev;
  • načrtovanje projektov;
  • spremljanje in nadzor projekta;
  • upravljanje pogodb z dobavitelji;
  • merjenje in analiza procesov in izdelkov;
  • zagotavljanje kakovosti procesov in izdelkov;
  • upravljanje konfiguracije;
• tretja stopnja- vsebuje standardizacijo glavnih procesov:
  • razvoj zahtev;
  • tehnične rešitve;
  • integracija izdelkov;
  • preverjanje;
  • validacija (certifikacija);
  • vsebina organizacijskih procesov;
  • opredelitev organizacijskih procesov;
  • organizacija usposabljanja;
  • integrirano upravljanje projektnih procesov in produktov;
  • Upravljanje tveganj;
  • integracija razvojne ekipe;
  • integrirano upravljanje dobaviteljev;
  • analiza in reševanje problemov (odprava napak);
  • organizacija okolja za integracijo;
• četrta stopnja- opredeljuje kvantitativno upravljanje:
  • organizacija zastopanja kakovosti procesov;
  • kvantitativno upravljanje celotnega projekta in virov;
• peta stopnja- optimizacija, nenehno izboljševanje:
  • organizacija, inovativnost, kvantitativno upravljanje procesov in zagotavljanje virov;
  • analiza vzrokov napak, izboljšanje kakovosti in upravljanje procesov in izdelkov.

Aplikacije v drugi različici modela so po sestavi podobne zgornjim aplikacijam za prvi model. Priporočljivo je, da se prijavite na vsaki višji stopnji zrelosti vse procese prejšnje nižje stopnje. V obeh različicah modela je vsak zgoraj poudarjen osnovni proces komentiran s podrobnimi priporočili za njegovo praktično izvajanje, ki vsebujejo opise približno 20–30 strani, poenotenih v strukturi:

• splošni cilji procesa, ki jih je treba doseči;
• uvodne besede in splošen opis procesne funkcije;
• specifični cilji procesa;
• upravljanje procesov;
• razvoj procesnih zahtev;
• interakcija in vmesniki z drugimi procesi;
• praktični cilji - zahtevani rezultati procesnih aktivnosti;
• načrtovanje dejanj v določenem procesu;
• analiza in validacija (potrditev) rezultatov izvajanja procesa;
• spremljanje in nadzor procesa.

Ta priporočila v smislu obsega, vsebine in popolnosti opisov osnovnih procesov so podobna številnim standardom za profil življenjskega cikla PS, predstavljenim v. Naročanje in ocenjevanje popolnosti uporabljenih procesov v skladu s stopnjami zrelosti vam omogoča, da ugotovite proizvodni potencial podjetij - razvijalcev programskih izdelkov v smislu predvidene kakovosti procesov in rezultatov njihovih dejavnosti ter pripravljenosti za certificiranje za skladnost z določeno stopnjo zrelosti modela CMMI - 1.1.

Poudarek na modelih CMMI je namenjen procesom upravljanja projekta PS. Te zahteve in procesi modelov praktično ustrezajo urejenim in podrobnim priporočilom v standardih. ISO 9001:2000 in glavne komponente profila kompleksnih standardov življenjskega cikla PS [ , ]. Zahteve za postopke v funkcionalnih oddelkih 4-8 standardov ISO 9001, ISO 9004, ISO 90003 v modelu je mogoče primerjati številne vsebinsko ustrezne razdelke CMMI(na sliki 1 območje prekrivanja vsebine). Skupnost procesov in zahtev je v podobnosti: sestava, terminologija, struktura, seznam priporočenih procesov vodenja, načrtovanje, obračunavanje razpoložljivih virov, izvajanje procesov programskega inženiringa, vrednotenje in organizacija strokovnjakov.

Slika 1. Skupnost procesov in zahtev standardov in modelov zrelosti

Z vidika podpore in reguliranja celotnega življenjskega cikla velikih programskih projektov so pomanjkljivosti modelov CMMI glede profila obstoječih standardov ISO lahko vključuje naslednje:

Razvito je bilo obsežno tehnično poročilo, ki je bilo prvotno odobreno leta 1998 za določitev stopnje zrelosti procesov za zagotavljanje življenjskega cikla zgoraj predstavljenega PS. ISO 15504, sestavljen iz devetih delov in številnih aplikacij. Orisuje model zrelosti CMM in osem osnovnih načel programskega inženiringa, ki temeljijo na standardu ISO 9000:2000. Nato notri ISO ta dokument je bil korenito revidiran, zmanjšan, poenostavljen struktura in vsebina, pri čemer so v celoti ohranjeni cilji in koncept ter odobren kot standard v petih delih.

Standardno ISO 15504:1-5:2003-2006 ureja ocenjevanje in certificiranje zrelosti procesov ustvarjanja, vzdrževanja in izboljševanja programskih orodij in sistemov, ki jih izvajajo podjetja:

• ugotavljanje stanja lastnih tehnoloških procesov in njihovo izboljšanje;
• ugotavljanje primernosti lastnih procesov za izpolnjevanje posebnih zahtev ali razredov zahtev strank;
• zaradi njegove primernosti za izvajanje določenih pogodb s strankami PS in sistemov.

Standard prispeva k: samooceni zrelosti podjetij, zagotavljanju ustreznega upravljanja atestiranih procesov, določanju profila ocen procesov, ustreza pa tudi vsem obsegom in velikosti OS in sistemov. Uporaba standarda je namenjena razvoju podjetij in strokovnjakov kultura nenehnega izboljševanja tehnološka zrelost zagotavljanje življenjskega cikla PS, ki izpolnjuje poslovne cilje projektov in optimizacijo porabe razpoložljivih virov. Ocena zrelosti procesov v podjetju ponuja priložnost za primerjavo in izbiro le-teh, ki so za določene projekte zaželene:

• za kupce, kupce, uporabnike programskih izdelkov in sistemov: zmožnost ugotavljanja trenutne in potencialne zrelosti dobaviteljevih procesov življenjskega cikla;
• za prodajalce in razvijalce: sposobnost določanja trenutne in potencialne zrelosti lastnih procesov življenjskega cikla programske opreme in sistemov, področij in prednostnih nalog za izboljšanje procesov;
• za maturitetne ocenjevalce: okvir za vodenje in izboljšanje ocenjevalnih procesov.

Odobritev v standardu je obravnavana v dva vidika: izboljšati procese življenjskega cikla PS in sistemov določenega podjetja ter ugotoviti, ali deklarirana zrelost projektov ali podpornih procesov podjetja ustreza dejansko uporabljenim procesom. To se odraža v naslednjih petih delih standarda. ISO 15504:1-5:2003-2006.

1. del - Koncept in besedišče. Vsebuje splošne informacije o postopkih certificiranja zrelosti programske opreme in sistemov ter priporočilih o uporabi delov standarda. Opredeljene so splošne zahteve za certificiranje, terminologija, struktura, določen obseg preostalih delov standarda.

2. del - Izvedba (izdelava) certificiranja. Vključuje podrobne zahteve za izvajanje certifikacijskih procesov kot osnovo za izboljšanje in določanje stopnje zrelosti tehnoloških procesov za zagotavljanje življenjskega cikla PS in sistemov. Dokument opredeljuje postopke za izvajanje atestiranja, modele za priporočene postopke za atestiranje in verifikacijo procesov, tako da so objektivni, smiselni in reprezentativni.

3. del - Navodila za izdelavo certificiranja. Zagotavlja pregled tehnologije za izvajanje procesov ocenjevanja zrelosti in interpretacije izvajanja zahtev. Odraža: izvedbo certificiranja; merilna orodja za določanje procesov zrelosti; izbira in uporaba certifikacijskih orodij; ocenjevanje usposobljenosti overiteljev; preverjanje skladnosti potrdila z navedenimi zahtevami. Orodja za validacijo lahko podjetja uporabljajo pri načrtovanju, upravljanju, spremljanju, nadzoru in izboljšanju programskih izdelkov in sistemov, pri njihovem pridobivanju, razvoju, uporabi in vzdrževanju.

4. del – Navodila za uporabnike za izboljšanje procesa in zrelost procesa v teh dveh vidikih. Priporoča se več korakov, ki vključujejo: uporabo rezultatov postopkov validacije; postavljanje ciljev za ocenjevanje zrelosti; določitev začetnih podatkov za certificiranje; ocena možnega zmanjšanja nastalih tveganj; koraki za izboljšanje procesov; korake za določitev stopnje zrelosti; primerjava rezultatov analize kvalifikacij z zahtevami.

5. del - Vzorčni model postopkov certificiranja za skladnost z zahtevami, predstavljenimi v 2. delu. Obsežen dokument (162 strani) ponuja praktične primere prejšnjih delov standarda za organizacijo, vrednotenje in izboljšanje ocen zrelosti procesov življenjskega cikla za različna področja uporabe, projekte programske opreme in podjetja.

Pri praktični izvedbi projektov in zagotavljanju življenjskega cikla kompleksne programske opreme je razvijalcem in dobaviteljem včasih težko prepoznati in izpostaviti prednosti modelov za uporabo. CMMI. Glede na tradicijo podjetja in značilnosti velikega projekta je pogosto priporočljivo uporabiti PS kot glavno polno profil standardovISO, in za oceno strank stopnjo zrelosti vodenje, organizacijska in tehnološka podpora projektom PS uporabljajo posebna priporočila CMMI. Te smernice je mogoče učinkovito uporabiti pri certificiranje kakovosti procesa v podjetjih, ki zagotavljajo življenjski cikel PS, kot alternativo ali skupaj s certificiranjem po nizu standardov upravljanja ISO 9000, odvisno od posebnosti projekta in zahtev prijavitelja za certificiranje programskega izdelka ali tehnologije za zagotovitev njegovega življenjskega cikla.

Organizacija certificiranja programskih izdelkov

Certificiranje je sestavljeno iz vrste organizacijskih procesov, ki sestavljajo certifikacijski sistem, so ti procesi podprti z urejenimi postopki in dokumenti in jih morajo izvajati usposobljeni, pooblaščeni strokovnjaki - inšpektorji. Za certificiranje podjetja-razvijalca in rezultatov njegovih dejavnosti - programski izdelki, modeli CMMI ali standardnih profilov ISO[ , ] priporočena je določena disciplina, ki naj bo prilagojena specifičnim značilnostim objektov in okolja življenjskega cikla PS. Spodaj navedeni postopki in dokumenti so zasnovani za velike projekte in jih je mogoče zmanjšati po dogovoru med razvijalci, strankami in overitelji v enostavnejših primerih.

Certifikacijsko delo se prične z akreditacijo organa ali preskuševalnega laboratorija, oblikovanjem in oddajo vloge in kompleta dokumentov centralnemu certifikacijskemu organu za odločitev o ustreznosti akreditacije. Če so rezultati testa pozitivni, se sestavi in ​​izda potrdilo o akreditaciji.

Pravilnik o certifikacijskem organu ali laboratoriju je glavni dokument, ki določa predmetno področje akreditacije, pravni status, funkcije, strukturo, pravice in obveznosti, metode, sredstva in organizacijo preizkusov. Potni list certifikacijskega laboratorija (centra) mora vsebovati podatke o opremi z računalniško opremo, potrebno za testiranje, o osebju in osebju, opremi za testiranje orodij, oskrbi z regulativnimi, tehničnimi in metodološkimi dokumenti ter o drugih virih, potrebnih za testiranje. testiranje.

Kakovostna ponudba vsebuje izjavo o načelih, opis metod in postopkov, povezanih z izvajanjem glavnih funkcij in nalog certifikacijskega organa ali laboratorija, ki zagotavljajo kakovost preskusov in zaupanje v rezultate ocenjevanja, preizkusov in pregledov. Priročnik o kakovosti običajno vključuje razdelke [ TWLSC$

• politika na področju zagotavljanja kakovosti testiranja in pregledov;
• opremljanje centra z ustreznimi metodološkimi materiali in programsko opremo ter orodji za testiranje;
• formalizacija zahtev za testne objekte;
• politika na področju tehnične opremljenosti centra in razvoja kadrov;
• arhiviranje in varnostni nadzor dokumentacije rezultatov certificiranja.

Prijavitelj za ocenjevanje proizvodov ali procesov, ki so predmet certificiranja, pošlje vlogo certifikacijskemu organu v obliki, ki je sprejeta v sistemu certificiranja. Certifikacijski organ izvaja dela na pripravi in ​​organizaciji certificiranja izdelkov ob prijavi. To delo vključuje:

• izbira sheme certificiranja ob upoštevanju posebnosti izdelkov (obseg, tehnologija, zahteve regulativnih dokumentov itd.) in predloge razvijalca;
• določitev števila in vrstnega reda vzorčenja in komponent, ki jih je treba testirati, če to ni določeno v standardih;
• izbira in identifikacija pooblaščenega preskusnega laboratorija za izvajanje testov;
• priprava osnutka pogodbe za opravljanje del.

Pripravljalni del dela na certificiranju se zaključi z objavo odločbe v obliki, ki je sprejeta v sistemu certificiranja. Odločitev se skupaj z osnutkom pogodbe o izvajanju del pošlje vlagatelju. Pri organizaciji certifikacijskih testov, izbiri in preučevanju veljavnih regulativnih dokumentov za izdelke, deklarirane za certificiranje, se izvajajo metode testiranja in ocenjevanja rezultatov.

Vlagatelj se dokončno odloči, kateri elementi sistema kakovosti, področja in vrste organizacijskih in tehničnih dejavnosti so predmet preverjanja pri certificiranju v določenem časovnem intervalu. Vlagatelj mora ustvariti pogoje in predložiti dokumente za zagotovitev postopkov preverjanja. Certifikacijskemu organu lahko predloži poročila o preskusih, opravljenih med razvojem in proizvodnjo izdelkov, dokumente o preskusih, ki jih opravijo tuji preskusni laboratoriji, in druge dokumente, ki kažejo na skladnost tehnologije ali izdelkov z uveljavljenimi zahtevami. Na podlagi analize dokumentiranih dokazil o skladnosti svojih izdelkov z uveljavljenimi zahtevami, predloženih z vlogo, se lahko certifikacijski organ odloči za zmanjšanje obsega preskusov ali izdajo certifikata.

Teste izvajajo preskuševalni laboratoriji, ki so akreditirani za izvajanje le tistih testov, ki so predvideni v njihovih regulativnih, akreditacijskih dokumentih. Če preskusov ni mogoče izvesti v preskuševalnem laboratoriju akreditiranega laboratorija, lahko preskuse izvede osebje tega laboratorija pri proizvajalcu ali potrošniku tega izdelka z uporabo lastnih zmogljivosti preskuševalnega laboratorija ali preskusnih zmogljivosti, ki so na voljo pri dobavitelju. .

Postopek certificiranja programskih izdelkov in sistemov kakovosti podjetja vključuje:

• analiza in izbor s strani razvijalca oziroma naročnika (prosilca) organa, pristojnega za to področje, in pooblaščenega laboratorija za izvajanje certifikacijskih testov;
• vložitev vlagatelja vloge za testiranje certifikacijskemu organu in sprejem odločitve certifikatorjev o vlogi, izbiro certifikacijske sheme, sklenitev certifikacijske pogodbe;
• opredelitev zahtev za sistem kakovosti podjetja in/ali za različico programskega izdelka, ki se testira;
• izvajanje certifikacijskih testov sistema kakovosti podjetja ali različice programskega izdelka s strani certifikacijskega laboratorija;
• analiza dobljenih rezultatov in odločitev laboratorija in/ali certifikacijskega organa o možnosti izdaje certifikata o skladnosti vlagatelju;
• izdaja certifikacijskega organa vlagatelju - certifikata in licence za uporabo znaka skladnosti in izdajanje certificiranih izdelkov - različice programskega izdelka;
• izvajanje inšpekcijskega nadzora s strani certifikacijskega organa certificiranega sistema kakovosti podjetja in/ali izdelkov;
• izvajanje korektivnih ukrepov s strani vlagatelja v primeru kršitve skladnosti procesov sistema kakovosti in/ali izdelkov z uveljavljenimi zahtevami in v primeru napačne uporabe znaka skladnosti.

Pri preverjanju odgovornosti vodstva razvijalca za kakovost izdelkov je treba ugotoviti, ali ima podjetje ali projekt dokumentirano politiko kakovosti, cilje in zaveze ter stopnjo, do katere je ta politika razumljena, izvajana in vzdrževana v delovnem stanju na vse ravni organizacije. Ugotoviti je treba, da ima podjetje predstavnika vodstva, ki ima ne glede na druge naloge pooblastila in odgovornost za stalno izvajanje zahtev standardov in regulativnih dokumentov sistema kakovosti. Razpoložljivost zahtev, postopkov, orodij in usposobljenega osebja za praktično izvajanje procesov sistema kakovosti ter ustreznost in sistematično dokumentiranje vseh komponent, zahtev in določil sistema kakovosti, ki je celostni proces skozi celotno življenjsko dobo. cikla PS, je treba preveriti. Preverjanje sistema kakovosti mora vsebovati definicijo:

• razpoložljivost in popolnost tehnološke dokumentacije ter izpolnjevanje njenih zahtev v praksi;
• stanje tehnološke opreme in razpoložljivost sistema za njihovo vzdrževanje;
• obstoj in učinkovitost sistema nadzora in testiranja;
• stanje merilnih in preskusnih instrumentov;
• razpoložljivost sistema za ugotavljanje in odpravljanje ugotovljenih pomanjkljivosti v izdelkih ali tehnologiji.

Na podlagi preskusov se ovrednotijo ​​dobljeni rezultati in utemeljijo sklepi o skladnosti ali neskladnosti izdelkov ali procesov z zahtevami regulativnih dokumentov. Poročila o preskusih se predložijo certifikacijskemu organu, na njegovo zahtevo pa tudi vlagatelju. Poročila o preskusih se hranijo za obdobja, ki so določena v pravilih sistemov certificiranja izdelkov in v dokumentaciji preskusnega laboratorija, vendar ne manj kot tri leta.

Po prejemu in preverjanju popolnosti in kakovosti dokumentacije morajo strokovnjaki preskusnega laboratorija izvesti preverjanje stopnje dejanske uporabe sistema kakovosti v podjetju. Testiranje se začne z razvojem programa za testiranje sistema kakovosti, ki naj služi kot delovni načrt za nadaljnje delo. Program je interni delovni dokument laboratorija za testiranje in mora vsebovati seznam del, ki je podroben v skladu s posebnostmi razvijalca in vključuje analizo popolnosti in kakovosti predloženih izvornih dokumentov ter stopnjo njihove praktične uporabe. pri oblikovanju, razvoju in dostavi programske opreme. Preverjanje uporabe postopkov sistema kakovosti izvaja preskuševalni laboratorij na delovnih mestih podjetja, ki zagotavlja življenjski cikel PS. Izvajajo se preverjanja prisotnosti strokovnjakov-razvijalcev ustreznih dokumentov na delovnem mestu in popolnosti uporabe njihovih določb in priporočil. Preglede stanja projekta in notranje presoje sistema kakovosti, procesov in/ali izdelkov naj izvaja osebje, neodvisno od tistih, ki so neposredno odgovorni za izvajanje teh del.

Metode za preverjanje kakovosti razvoja mora biti zagotovljena potrebna sredstva za izvajanje testnega programa, metod načrtovanja in razvoja zasebnih inšpekcijskih postopkov. Metode morajo vsebovati: predmete in cilje testiranja; ocenjeni kazalniki kakovosti; pogoji in postopek testiranja; metode obdelave, analize in vrednotenja rezultatov testov; tehnično podporo za testiranje in poročanje. Navesti je treba strojno in programsko opremo, uporabljeno med preskusi in preskusni postopek, ter pričakovane rezultate preverjanj. Razviti je treba metode za nadzor popravkov, ukrepe za odpravo napak, če tako zahtevo prejme služba za upravljanje revizije. Služba za upravljanje testnega programa bi morala določiti postopke za ohranjanje zaupnosti vseh informacij o preskusih in podatkov, ki jih hranijo ocenjevalci.

Poročila o preskusih predloženo vlagatelju in certifikacijskemu organu. Vlagatelj lahko certifikacijskemu organu predloži poročila o preskusih ob upoštevanju pogojev njihove veljavnosti, opravljenih med razvojem in proizvodnjo izdelkov, ali dokumente o preskusih, ki jih izvajajo domači ali tuji preizkuševalni laboratoriji, akreditirani ali priznani v sistemu certificiranja. Na podlagi poročil o certifikacijskih preskusih se ocenijo pridobljeni rezultati in utemeljijo sklepi o skladnosti ali neskladnosti izdelkov z zahtevami regulativnih dokumentov.

Zaključek o rezultatih certifikacijskih testov razvijajo ga certifikatorji in vsebuje posplošene informacije o rezultatih testiranja in utemeljitev za izdajo certifikata. V primeru negativnih rezultatov certifikacijskih testov se sprejme odločitev o zavrnitvi izdaje certifikata o skladnosti. Po zaključku certificiranega izdelka ali sistema kakovosti se lahko preizkusi ponovijo. Rezultati analize stanja tehnologije oziroma kakovosti izdelka so sestavljeni z aktom, ki podaja ocene za vsa mesta preizkusnega programa in vsebuje zaključke, vključno z Skupna ocena stanje proizvodnje in izdelkov, potreba po korektivnih ukrepih. Akt uporablja certifikacijski organ skupaj s poročili o preskusih, vlogo za izdajo in določitev roka veljavnosti certifikata za programski izdelek, pogostost inšpekcijskega nadzora in tudi za pripravo korektivnih ukrepov.

Na podlagi rezultatov certifikacijskih preizkusov in pregleda dokumentacije se sprejme odločitev o izdaji certifikata. V primeru negativnih rezultatov certifikacijskih testov se sprejme odločitev o zavrnitev izdaje potrdila skladnost. Poleg tega se lahko podjetju vlagatelju pošljejo predlogi za odpravo domnevnih vzrokov za negativne rezultate testov, po zaključku certificiranih izdelkov se lahko testi ponovijo.

Certifikacijski organ po analizi poročil o preskusih, ocenjevanju proizvodnje, certificiranju sistema kakovosti, analizi dokumentacije, navedene v odločitvi o vlogi, oceni skladnost izdelkov z uveljavljenimi zahtevami, na podlagi mnenja strokovnjakov sestavi certifikat. in ga registrira. Pri spremembah projektne ali obratovalne dokumentacije, ki bi lahko vplivale na kakovost sistema ali programskega izdelka, certificiranega med certificiranjem, mora prijavitelj o tem obvestiti certifikacijski organ, da se odloči o potrebi po dodatnih preizkusih. Po registraciji začne potrdilo veljati in se pošlje podjetju vlagatelju. Hkrati z izdajo potrdila se lahko izda podjetje prosilec licenco za pravico do uporabe znaka skladnosti.

Za certificirane programske izdelke v času njihovega delovanja v celotnem obdobju veljavnosti certifikata o skladnosti, inšpekcijski nadzor. Inšpekcijski nadzor se izvaja v obliki periodičnih in nenačrtovanih pregledov skladnosti z zahtevami glede kakovosti tehnologije in certificiranih izdelkov. Predmeti nadzora, odvisno od sheme certificiranja, so certificirani izdelki, sistem kakovosti ali stabilnost proizvodnje podjetja razvijalca. Pri določanju frekvence in glasnosti inšpekcijski pregled upoštevajo se naslednji dejavniki: stopnja potencialne nevarnosti programskega izdelka, stabilnost proizvodnje, obseg izdaje, razpoložljivost in uporaba sistema kakovosti med razvojem, informacije o rezultatih testov izdelka in njegovih proizvodnja, ki jo izvaja proizvajalec, organi državni nadzor in nadzor.

Rezultati inšpekcijskega nadzora so sestavljeni z aktom, ki ocenjuje rezultate vzorčnih testov in drugih pregledov, naredi splošno ugotovitev o stanju proizvodnje certificiranih izdelkov in možnosti ohranitve veljavnosti izdanega certifikata. Akt je shranjen v certifikacijskem organu, njegove kopije pa se pošljejo razvijalcu in organizacijam, ki so sodelovale pri inšpekcijskem nadzoru. Na podlagi rezultatov inšpekcijskega nadzora lahko certifikacijski organ začasno prekine ali prekliče certifikat ter odvzame licenco za pravico do uporabe znaka skladnosti v primeru neskladnosti izdelkov z zahtevami regulativnih dokumentov, ki jih je preveril med certificiranjem, saj pa tudi v naslednjih primerih:

• temeljne spremembe v modelu zrelosti, profilu standardov, predpisih o izdelkih ali preskusni metodi;
• spremembe v zasnovi (sestavi), popolnosti izdelkov;
• spremembe v organizaciji ali tehnologiji razvoja in proizvodnje;
• neizpolnjevanje zahtev tehnologije, metod nadzora in preskušanja, sistema kakovosti, če lahko navedene spremembe povzročijo neskladnost izdelkov z zahtevami, ki se kontrolirajo pri certificiranju.

Odločitev o zadržanju veljavnosti certifikata in licence za pravico do uporabe znaka skladnosti ni sprejeta, če lahko vlagatelj s korektivnimi ukrepi, dogovorjenimi s certifikacijskim organom, ki ga je izdal, odpravi ugotovljene vzroke neskladnosti in potrdi , brez ponovnega testiranja v pooblaščenem laboratoriju, skladnost izdelka ali postopkov z normativnimi dokumenti. Če tega ni mogoče storiti, se veljavnost certifikata razveljavi in ​​licenca za pravico do uporabe znaka skladnosti se razveljavi. Podatke o začasnem prenehanju ali preklicu certifikata posreduje certifikacijski organ, ki ga je izdal, prijavitelju, potrošnikom in drugim zainteresiranim organizacijam. Veljavnost certifikata in pravice do označevanja izdelkov z znakom skladnosti se lahko podaljša, če razvijalec izpolnjuje naslednje pogoje:

• ugotavljanje vzrokov neskladnosti in njihovo odpravljanje;
• predložitev certifikacijskemu organu poročila o opravljenem delu za izboljšanje in zagotavljanje kakovosti izdelkov;
• izvajanje dodatnih preizkusov izdelkov po metodah in pod nadzorom certifikacijskega organa ter pridobivanje pozitivnih rezultatov.

Dokumentacija procesov in rezultatov certificiranja programskih izdelkov

Sestava in vsebina dokumentacije za certificiranje sistema kakovosti podjetja so odvisna od značilnosti načrtovanja, razvoja in modifikacije programske opreme, pa tudi od zahtev po njihovi kakovosti in značilnosti tehnološkega okolja. Zato je treba izbrati potreben nabor dokumentov za vsako podjetje ali projekt in ga prilagoditi tem značilnostim. Kazalniki sistema kakovosti, ki se ocenjujejo pri certificiranju, so razpoložljivost ustreznih dokumentov in praktična izpolnjevanje zahtev določene stopnje modela zrelosti. SMMI ali prilagojen profil standardov, ki temelji na ISO 9000:2000, pa tudi opise delovnih mest, ki so jih na njihovi podlagi ustvarili strokovnjaki podjetja-razvijalca. Vlagatelj mora pripraviti in preizkušalnemu laboratoriju predložiti sklop dokumentov, dogovorjenih med naročnikom in razvijalcem in odobrenih za preverjanje njihove zanesljivosti, ustreznosti sestave in izdelave v skladu z regulativnimi dokumenti.

Okvirni nabor osnovnih dokumentov za certificiranje je sestavljen iz treh skupin:

• osnovni predpisi sisteme kakovosti v skladu z nomenklaturo in vsebino profila standardov na podlagi ISO 9000:2000 ali modeli zrelosti SMMI, pa tudi program, priročnik in navodila, ki so jih pripravili razvijalci na njihovi podlagi, predstavljeni preizkuševalcem (strokovnjakom) sistema kakovosti ali izdelkov revidiranega podjetja;
• izvorni dokumenti, ki označujejo posamezno podjetje ali projekt, pa tudi življenjski cikel programskega orodja, ki jih je pripravilo vodstvo projekta za certificiranje njegove kakovosti;
• Dokumenti o poročilih preizkuševalcev, ki odražajo rezultate presoje (certificiranja) sistema kakovosti podjetja in/ali programskega izdelka, predloženi certifikacijskemu organu, vlagatelju in vodstvu revidiranega podjetja.

Programski izdelek ali sistem kakovosti podjetja, predložen v certifikacijo, je treba predložiti skupaj z ustrezno dokumentacijo. Seznam in približna vsebina skupin teh dokumentov sta osredotočena na splošni primer preverjanja sistemov kakovosti podjetij, ki zagotavljajo življenjski cikel velikih programskih izdelkov. Nabor dokumentov se lahko zmanjša in prilagodi po dogovoru med prijaviteljem, overiteljem in vodstvom revidiranega podjetja v skladu z značilnostmi projektov programske opreme. Nekatere dokumente je mogoče združiti v integrirana poročila z jasno odgovornostjo določenih strokovnjakov za njihovo izvajanje.

Osnovni dokumenti sistema kakovosti podjetja in življenjskega cikla programske opreme

1. Koncept, terminologija, zahteve in napotki za izboljšanje učinkovitosti - sistemi vodenja kakovosti - ISO 9000:2000 ali različico modela zrelosti CMMI.
2. Prilagojene različice ali seznam razdelkov in priporočil standardov ISO 12207, ISO 15504, njihove spremembe in smernice za uporabo, izbrane med prilagoditvijo in obvezne za uporabo v sistemu kakovosti posameznega podjetja ali projekta programskega produkta.
3. Prilagojena različica ali seznam razdelkov in priporočil standarda ISO 900003, izbran med prilagoditvijo in obvezen za uporabo v sistemu kakovosti podjetja, ki proizvaja programski izdelek.
4. Osnovne značilnosti in lastnosti kakovosti projekta PS, identificirane, prilagojene in specificirane na podlagi standardov ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Prilagojena različica in odobrena izdaja priročnika za vzdrževanje in upravljanje konfiguracije na podlagi priporočil standardov ISO 14764, ISO 10007, ISO 15846.
6. Nabor opisov delovnih mest, ki opredeljujejo odgovornost, pooblastila in postopek za interakcijo vsega vodstvenega, izvajalskega in preverjanja dela osebja, vključenega v postopke sistema kakovosti podjetja za določen projekt PS.

Izvorni dokumenti, ki odražajo značilnosti življenjskega cikla določenega programskega orodja

1. Opis značilnosti programskih izdelkov, ustvarjenih v podjetju, sistema in zunanjega okolja njihovega življenjskega cikla, potrebnih za prilagoditev in pripravo delovnih različic standardov in zahtev projekta PS in sistema kakovosti podjetja v skladu z priporočila standardov ISO 12207, ISO 15504, ISO 90003 in ISO 9126.
2. Opis ciljev, zahtev in obveznosti podjetja razvijalca na področju sistema kakovosti, meril kakovosti procesov in produktov razvoja, dostave in podpore celotnega življenjskega cikla programske opreme.
3. Nabor operativnih dokumentov, ki se dobavljajo stranki in uporabnikom za zagotovitev življenjskega cikla in uporabe določene različice programskega izdelka na podlagi prilagojenih standardov ISO 9294, ISO 15910, ISO 18019.
4. Dokumentacija in orodja za avtomatizacijo za načrtovanje, razvoj, spreminjanje, nadzor in testiranje, ki se uporabljajo za zagotavljanje življenjskega cikla programskega izdelka.
5. Načrti in metode za testiranje aplikacije in ocenjevanje učinkovitosti procesov sistema kakovosti podjetja in programskega produkta.
6. Metode vzdrževanja, identifikacija komponent in dokumentacije programskega izdelka, analiza in odobritev različic programske opreme in podatkovnih kompleksov.
7. Metodologija za upravljanje konfiguracije, odobritev, shranjevanje, zaščito, kopiranje različic programskih izdelkov in spremljajočih dokumentov ter zbiranje in shranjevanje podatkov o lastnostih kakovosti, evidentiranih v arhivu podjetja v življenjskem ciklu različic programskih izdelkov.

Nastali testni dokumenti - certificiranje sistema kakovosti podjetja in / ali programskega izdelka

1. Poročilo o razpoložljivosti, ustreznosti in sistematičnem izvajanju dokumentacije, prilagojene zahtevam in določilom sistema kakovosti podjetja, ki zagotavlja celostni proces zagotavljanja kakovosti skozi celoten življenjski cikel programskega produkta.
2. Rezultati spremljanja in testiranja stanja in uporabe sistema kakovosti, ki se izvajajo periodično za ugotavljanje njegove ustreznosti in učinkovitosti.
3. Poročilo o razpoložljivosti in vzdrževanju metod za izvajanje pregledov in dokumentirana poročila o rezultatih dosežene kakovosti pri izpolnjevanju zahtev certifikacijske pogodbe z naročnikom.
4. Rezultati registracije doseženih kakovostnih lastnosti programskega paketa: identifikacija, kopičenje, shranjevanje registriranih podatkov o značilnostih in atributih kakovosti programskega izdelka in njegovih komponent.
5. Rezultati izvedbe razvojnega načrta, dokumentirani vhodni in izhodni podatki razvojnih stopenj in protokoli za preverjanje izvajanja življenjskega cikla PS.
6. Rezultati praktičnega izvajanja programa kakovosti in izvajanja reguliranih dejavnosti na področju kakovosti v vseh fazah življenjskega cikla PS.
7. Rezultati certificiranja okoljskih simulatorjev in testnih generatorjev ter ocena njihove zadostnosti za izvajanje certifikacijskih testov programskega izdelka.
8. Rezultati analize izvajanja načrtov in preskusnih metod, poročila o preskusih, ocene skladnosti rezultatov preskusov z zahtevami ter rezultati preskusov, ki jih potrdijo predstavniki vlagatelja, naročnika in dobavitelja.
9. Akt rezultatov preverjanja dejanskih značilnosti življenjskega cikla programskega sistema in sistema kakovosti podjetja, sklepi o njihovi skladnosti z zahtevami za certificiranje proizvodnje programskega izdelka.
10. Certifikat sistema kakovosti podjetja in/ali programskega izdelka ter zagotavljanje njegovega življenjskega cikla, licenca za uporabo znakov skladnosti.

Literatura

V.V. Lipaev -- Profili standardov življenjskega cikla programske opreme. -- Informacije o Jetu, glasilo, št. 12, 2005

K. Milman, S. Milman -- SMMI je korak v prihodnost. -- odprti sistemi., N 5-6 (2005), N 2 (2006) , 2005, 2006

Ocenjevanje in certificiranje zrelosti procesov za izdelavo in vzdrževanje programskih orodij in informacijskih sistemov ISO IEC TR 15504-CMMI. Per. iz angleščine -- M.: Knjiga in posel, 2001

V.V. Lipaev -- Procesi in standardi življenjskega cikla kompleksne programske opreme. Imenik.-- M.: SINTEG, 2006

V.V. Lipaev -- Metode za zagotavljanje kakovosti programske opreme velikega obsega.-- M.: RFBR. SINTEG, 2003

"; antisource: "Programski izdelki se zdaj uporabljajo za reševanje problemov upravljanja na skoraj vseh področjih človekove dejavnosti: v gospodarstvu, socialnem, vojaškem in drugih področjih. Zagotavljanje visoke kakovosti domačih programskih izdelkov v času njihovega množičnega razvoja in dostave za različne aplikacije v državi in ​​na svetovnem trgu je postala strateška naloga."; pogoj: 1]$