Tarkvaraarendus: kvaliteedistandardid. Capability Maturity Model (CMM) Ettevõtte kvaliteedisüsteemi ja tarkvara elutsükli põhidokumendid

Lisaks riiklikele ja rahvusvahelistele standarditele on arendusprotsessi sertifitseerimisel mitmeid lähenemisviise. Kuulsaimad neist Venemaal on ilmselt CMM ja CMMI.

CMM (Capability Maturity Model) on tarkvara loomise protsesside küpsusmudel, mis on mõeldud arendusprotsessi küpsustaseme hindamiseks konkreetses ettevõttes. Selle mudeli järgi on viis arendusprotsessi küpsuse taset. Esimene tase vastab arendusele "nagu see juhtub", kui arendajad lähenevad igale projektile nii, nagu see oleks vägitegu. Teine vastab enam-vähem väljakujunenud protsessidele, kui saate mõistliku kindlusega loota projekti positiivsele tulemusele. Kolmas vastab arenduses kasutatavate väljatöötatud ja hästi kirjeldatud protsesside olemasolule ning neljas mõõdikute aktiivne kasutamine juhtimisprotsessis eesmärkide seadmiseks ja nende saavutamise jälgimiseks. Lõpuks viitab viies tase ettevõtte võimele protsessi vastavalt vajadusele optimeerida.

CMM ja CMMI nõuded

Pärast CMM-i tulekut hakati välja töötama spetsiaalseid küpsusmudeleid infosüsteemide loomiseks, tarnijate valikuprotsessiks ja mõneks muuks. Nende põhjal töötati välja integreeritud CMMI (Capability Maturity Model Integration) mudel. Lisaks püüdis CMMI ületada selleks ajaks ilmnenud CMM-i puudujääke – protsesside formaalsete kirjelduste rolliga liialdamist, kui teatud dokumentatsiooni olemasolu hinnati palju kõrgemale kui lihtsalt väljakujunenud, kuid kirjeldamata. protsessi. CMMI on aga keskendunud ka väga formaliseeritud protsessi kasutamisele.

Seega on CMM ja CMMI mudelite aluseks arendusprotsessi formaliseerimine. Nende eesmärk on arendajatel rakendada eeskirjades ja juhendites üksikasjalikult kirjeldatud protsess, mis omakorda ei nõua asjakohaseks kontrolliks ja aruandluseks suure hulga projektidokumentide väljatöötamist.

CMM-i ja CMMI seos iteratiivse arendusega on kaudsem. Formaalselt ei esita ei üks ega teine ​​juga ega iteratiivse lähenemise järgimiseks konkreetseid nõudeid. Mõnede ekspertide sõnul ühildub CMM siiski rohkem kose lähenemisviisiga, samas kui CMMI võimaldab kasutada ka iteratiivset lähenemist.

Loomulikult on RUP korduv metoodika. Kuigi kohustuslikku nõuet läbida kõik faasid või teatud minimaalne iteratsioonide arv pole RUP-is kuskil ametlikult märgitud, on kogu lähenemine keskendunud sellele, et neid on päris palju. Piiratud iteratsioonide arv ei võimalda RUP-i kõiki eeliseid täielikult ära kasutada. Samas saab RUP-i kasutada ka praktiliselt koseprojektides, mis sisaldavad tegelikult vaid paari iteratsiooni: üks “Ehitamise” faasis ja teine ​​“Ülekande” faasis. Muide, jugaprojektides kasutatakse seda iteratsioonide arvu tegelikult. Süsteemi testimine ja proovitöö hõlmab ju paranduste tegemist, mis võivad hõlmata teatud analüüsi, projekteerimise ja arendusega seotud toiminguid, st tegelikult on need järjekordsed arendusfaasid.

RUP metoodika

Mis puutub metoodika formaalsusesse, siis RUP pakub kasutajale väga laia valikut võimalusi. Kui teete kõik tööd ja ülesanded, loote kõik artefaktid ja viite läbi kõik ülevaated üsna formaalselt (ametliku retsensendiga, koostades täieliku ülevaate elektroonilise või paberdokumendi vormis jne), võib RUP osutuda olema äärmiselt formaalne, kaalukas metoodika. Samal ajal võimaldab RUP arendada ainult neid artefakte ja täita ainult neid töid ja ülesandeid, mis on konkreetses projektis vajalikud. Ja valitud artefakte saab teostada ja üle vaadata suvalise formaalsusastmega. Võite nõuda iga dokumendi üksikasjalikku läbitöötamist ja hoolikat täitmist, sama hoolikalt täidetud ja teostatud ülevaate andmist ning isegi vana tava järgi iga sellise ülevaate kinnitamist ettevõtte teadus- ja tehnikanõukogus. Või võite piirduda meili või paberil visandiga. Lisaks on alati veel üks võimalus: vormistada oma peas dokument, ehk mõelda vastavale teemale ja teha konstruktiivne otsus. Ja kui see otsus puudutab ainult sind, siis piirdu näiteks kommentaariga programmi koodis.

Seega on RUP iteratiivne metoodika, millel on arendusprotsessi vormistamise mõttes väga lai valik võimalikke lahendusi.

Teeme kokkuvõtte artikli teisest osast. Erinevalt enamikust teistest metoodikatest võimaldab RUP teil valida laias valikus arendusprotsessi formaliseerituse ja iteratiivsuse astme, sõltuvalt projektide ja areneva organisatsiooni omadustest.

Miks see nii oluline on, arutame järgmises osas.

V. Iljin.

TopSBI ettevõtte kvaliteediteeninduse juht

"Kui sa midagi teed

vale - pole vaja
oodata õiget tulemust."

Hiina rahvatarkused

Tarkvara kvaliteedi tagamise probleemide terviklik lahendus hõlmab ühe või teise kvaliteedijuhtimissüsteemi (Quality Management System - kvaliteedijuhtimissüsteemi) väljatöötamist ja juurutamist. QMS). Maailmapraktikas on enim levinud just ISO 9000 seeria rahvusvaheliste standardite nõuetel põhinev süsteem, kuna see määratleb kõige üldisemad nõuded, sealhulgas tarkvarasüsteemidele esitatavad nõuded, ning määrab sellega üldiselt ette esialgsed. protsesside küpsus, mis on vajalik paljude IT-valdkonna tööstusmudelite ja standardite järgimiseks .

Kuid küsimusele, kas kvaliteedisüsteemi rakendamine ja edukas sertifitseerimine tagab kvaliteetse toote väljalaske, tuleb vastata ausalt - "ei".

Rõhutades, et ISO 9000 on "suurepärane idee", soovitab Gartner Group ISO 9001 sertifikaati käsitleda vaid lähtepunktina teel kvaliteedi poole (1).

See paneb paika kvaliteedisüsteemi “skeleti” ning selle süsteemi täitmine “lihastega” (professionaalne sisu, mis põhineb tööstuse eristandarditel ja metoodikatel, nagu CMM) võib tagada kasvavatele turunõuetele vastava kvaliteeditaseme.

Seoses eeltooduga peavad paljud kvaliteedijuhtimise valdkonna eksperdid nii metodoloogilisest kui ka praktilisest aspektist soovitavaks koostada IT-ettevõtete arengustrateegia järgmiselt:

Esmalt töötage välja ja rakendage kvaliteedijuhtimissüsteem vastavalt ISO 9001:2000 mudelile. (Lõppude lõpuks tegi enamik ettevõtteid, mis on praegu SW-CMM-i 4. ja 5. tasemel, oma protsesside ISO mudeliga vastavusse viimise. Nagu praktika näitab, on see QMS-i arendamise juhtimise seisukohalt parim valik. ja riskide vähendamine).

Ja alles siis alustage SW-CMM mudeli ja seejärel vajadusel CMMI mudeli võtmeprotsesse arendamist ja juurutamist.

Et mõista, kui õige see tegelikult on, võrrelgem neid mudeleid.

1. Taotlejate läbivaatamine.

Teeme põgusa ülevaate populaarsematest standarditest, mida IT-ettevõte saab kasutada oma äriprotsesside optimeerimiseks.

ISO 9001. Kõige populaarsem ja eriti Euroopas on ISO 9001 (2)

Samal ajal, metoodiliselt, täielikult kooskõlas keeruliste süsteemide ehitamise distsipliiniga, näeb ISO 9001 standard ette ühelt poolt organisatsioonisüsteemi ülesehitamist "ülalt alla": ettevõtte eesmärkidest ja selle poliitikast lähtudes. - organisatsioonilisele struktuurile ja äriprotsesside kujundamisele ning teisalt - organisatsioonisüsteemi iteratiivsele arendamisele mõõtmis- ja parendusmehhanismide kaudu.

Lihtsamalt öeldes on “kvaliteet” ISO 9000 standardite sarja järgi olukord, kus tarbijad saavad tootjalt tooteid, mis vastavad nende otsestele nõuetele ja varjatud ootustele. Seetõttu hõlmab kvaliteedijuhtimine vastavalt ISO 9000-le nn. "Protsessilähenemine", kui modelleeritakse ja rakendatakse optimaalseim "protsessimuutuste" ahel, tagades, et tootja tajub tarbijate vajadusi ja kehastab neid moonutusteta mis tahes tootes.

Paljud tarkvaraarendusorganisatsioonid kasutavad edukalt seda tuntud standardite sarja ISO 9000. Selle seeria standardite uus versioon ilmus 2000. aastal ja sisaldab juba CMM-ist laenatud mõisteid protsessi lähenemine, analüüs ja mõõtmine, protsesside täiustamine. mudel ja varasemad puuduvad ISO 9000 eelmistes versioonides. Siiski tuleb märkida, et selle seeria standardid on universaalsed - need ei ole keskendunud ühelegi konkreetsele tööstusharule, ei võta arvesse IT-valdkonna eripärasid ja Muidugi on spetsifikatsiooni astme poolest CMM-ist märgatavalt madalamad. Lisaks ei viita ISO 9000 nõuetele vastavuse astmeid (tasemeid) ja teeb seega keeruliseks konkreetse organisatsiooni „tõeliste” võimete ja vastavalt nende edasise arendamise viiside kindlaksmääramise.

CMM(Capability Maturity Model) töötas välja Carnegie Melloni ülikooli (USA) Tarkvaratehnika Instituut ja see kirjeldab ettevõtete tarkvaraarenduse protsesside küpsuse mudelit (3). Selle mudeli raames saab iga ettevõtte puhul võrrelda teatud taset (üks viiest võimalikust), mis näitab tarkvara arendusprotsessi saavutatud kvaliteeti. Kuna need standardid töötati välja eelkõige USA kaitseministeeriumi töövõtjate valimise protsessi sujuvamaks muutmiseks, pööratakse neis erilist tähelepanu tarkvaraprojektide juhtimise protsessidele, samas kui arenduse tehnilisi aspekte käsitletakse vähem.

SW-CMM v.1.1 (tarkvara võimekuse küpsusmudel) sisaldab 316 peamist praktikat. Võtmetavad on need, mida tuleks ettevõttes rakendada ja millele protsessi hindamist läbi viiv meeskond tähelepanu pöörab. Need on kombineeritud valdkondadeks – Key Practices Areas (KPA) – need on juba omavahel seotud protsesside kogumid, mis koos teostades viivad teatud eesmärkide saavutamiseni.

CMMI(Capability Maturity Model Integration) – CMM mudeli edasiarendus. CMMI-SE/SW versioonis 1.02 (CMMI for Systems Engineering/Software Engineering), mis on ehk kõige sobivam tarkvarasüsteemide arendajatele, ulatub võtmepraktikate arv juba 417-ni.

Võtmepraktikate kasv on seotud just CMMI arendamise eesmärgiga – mudel peaks aitama vältida erinevate tööstusharude CMM-mudelite kasutamisega seotud probleeme.

(Alates 1991. aastast on CMM-mudeleid välja töötatud erinevate rakenduste jaoks, millest olulisemad on:

Tarkvaraarenduse protsessi küpsusmudel (Capability Maturity Model for Software – SW-CMM)
- protsessi küpsusmudel süsteemi ümberkujundamiseks (Electronic Industries Alliance'i ajutine standard – EIA/IS 731)
- integreeritud tootearendusprotsesside küpsusmudel Integreeritud tootearenduse võimekuse küpsusmudel - IPD-CMM)

Nende mudelite põhjal ehitati CMMI. See on neelanud nendest mudelitest parimad, kõrvaldades mitmete mudelite olemasolust tuleneva ebaselguse mõnede mõistete tõlgendamisel – seetõttu on võtmepraktikate arv oluliselt suurenenud).

On selge, et see on juba osutunud oluliselt "raskemaks" mudeliks - vt. Riis. 1, mida pealegi pole praktikas veel piisavalt testitud (väljastati alles 2002. aastal). Sellega seoses on minu arvates mudeli rakendamisel võimalikud suured riskid, mis on seotud nii tarkvaraarenduse kiiruse põhjendamatute kadudega kui ka samaaegse üheselt mõistetava tööjõukulude suurenemisega juurutatud KPA toimimiseks (ja toeks). - vaata. Joon 1. Praktikuna, kes on juba kolmes erinevas IT-ettevõttes QMS-i ehitanud, tundub mulle, et CMMI mudelis on vajaliku ja piisava tasakaal selgelt häiritud - IT-ettevõtte personal (ja see, reeglina on enamasti “koodikunstnikud”), nii palju kontrollitud määrusi lihtsalt “ei aktsepteeri” (siin on väga suur oht “Potjomkini küla” rajamiseks)!

Riis. 1 KPA koostise võrdlus CMM ja CMMI mudelites.

Lisaks on CMMI hindamine alates loa saanud oluliselt kallim SEI Juhtiv hindaja" Neid on endiselt väga vähe ja need teenused on palju kallimad kui CMM-mudelile vastavuse hindamisel.

Veelgi enam, paljud kvaliteedijuhtimise valdkonna väliseksperdid (kelle arvamusega ma hetkel täielikult nõustun) on CMMI suhtes üsna skeptilised selle kasulikkuse kontekstis selle rakendamiseks väikestes ja keskmise suurusega organisatsioonides (just sellised organisatsioonid on Venemaale tüüpilised). ). On isegi avaldatud arvamust, et mõne aja pärast peab SEI kas välja laskma kohandatud SW-CMM v.2 või astuma sarnaseid samme. Need. Kui turg mudelit ei aktsepteeri ja sellised eeldused on juba käesoleva artikli kirjutamise ajal olemas, peab SEI kohanema turunõuetega.

Seoses eelnevaga tundub asjakohane analüüsida juba mainitud vajaliku ja piisava tasakaalu kõigis neis peamistes QMS mudelites.

Teeme selle järgmistes koordinaatides (vt. Riis. 2) :

arenguprotsesside reguleerimise aste - tähistame seda mõistet - R.P.,

planeeritud tulemuste saavutamise tõenäosus - tähistame seda mõistet - PQ.

Joonisel fig. Joonisel 2 on kujutatud eksperthinnangut reguleerituse taseme ja kavandatud tulemuste saavutamise tõenäosuse vahelise tasakaalu kohta, mille autor on läbi viinud nende mudelite nõuete juurutamise praktika tulemustele. tarkvara (tarkvara).

Matemaatilises mõttes on tuletise suurusjärk: F(Q) = dPQ\dRQ(kvaliteedi saavutamise efektiivsuse kasv dPQ nõuete täitmise toetamisele kuluva tööaja suurenemisega dRQ), väheneb vastavalt järgmises järjestuses : ISO 9000, CMM, CMMI.

Seetõttu joonis fig. 2 selgitab selgelt ja lihtsalt:

ISO 9000 mudeli populaarsus,

metoodika õigsus: esmalt ISO ja alles siis vajadusel CMM,

teatav skeptitsism CMMI mudeli tõhususe suhtes.

Riis. 2 Reguleerituse taseme ja kavandatud tulemuste saavutamise tõenäosuse vahelise tasakaalu analüüs (vastavalt autori eksperthinnangule)

Vaatleme nüüd teist IT-ettevõtetes laialdaselt kasutatavat juhendit, mida allpool QMS-i juurutamise praktika küsimusi analüüsides mainitakse.

See PMBoK(Guide to the Project Management Body of Knowledge) on projektijuhtimise instituudi projekt, mis hõlmab kogutud teadmisi projektijuhtimise valdkonnast. Dokumendi viimane versioon avaldati 2000. aastal ja sai samal ajal ka Ameerika standardiinstituudi ANSI standardi staatuse (kuigi ANSI ja IEEE standardeid peetakse formaalselt ameerikalikeks, on enamik neist de facto rahvusvahelise iseloomuga). PMBOK-i oluline omadus on see, et see käsitleb projektijuhtimist üldises tähenduses, viitamata konkreetsetele teemavaldkondadele, nagu IT, ja seetõttu ei saa seda kasutada iseseisvalt – allpool vaatleme, millist mõju see annab, kui seda kasutatakse koos ISO 9000-ga.

Mõelgem nüüd, kuidas on juba populaarse ISO 9001:2000 standardi nõuded seotud üha populaarsemaks muutuva CMM-mudeli üldiste omadustega. {3}- cm. Riis. 3.

Riis. 3. CMM-i üldiste omaduste ja ISO 9001:2000 elementide vastavus

Iga HMM-i taset, nagu eespool mainitud, iseloomustab komplekt võtmeprotsessi valdkonnad – KPA (Key Process Areas) – cm. Joonis 3. Kõigi sisemiste eesmärkide saavutamine KPA teatud taseme puhul määrab SMM organisatsiooni vastavuse sellele tasemele. Kui vähemalt üks eesmärk on vähemalt üks KPA kui CMM-i taset ei saavutata, ei saa organisatsioon seda CMM-i taset täita. KPA võib jagada kolme kategooriasse: juhid , organisatsiooniline Ja pakkudes (cm. Riis. 4).

CMM ei määratle kõiki tarkvaraarenduse jaoks olulisi protsesse; see tõstab esile ainult need, mis on vajalikud SMM-i taseme saavutamiseks, ja need on kaasatud KPA. Iga KPA on jagatud 5 ühiseks omaduseks (Common Features): Täitmise kohustus (Comment to soorita); Esinemisvõime; Teostatud tegevused; Mõõtmine ja analüüs; Rakenduse kontrollimine

Üldvara" Toimingud, mida tuleb teha" kirjeldab tegevusi, mida tuleb eesmärkide saavutamiseks teha KPA, ülejäänud neli üldist omadust kirjeldavad formaalseid tegureid, mis muudavad protsessi organisatsioonikultuuri osaks. Kõigi täielik täitmine peamised tavad kõigi ühiste omadustega tagab eesmärkide saavutamise KPA. Põhitavad kirjeldavad, milliseks töövoog (või protsessielement või infrastruktuuri osa) peaks kujunema, kuid ei määratle saavutamise meetodit (konkreetseid tehnoloogiaid või tehnikaid), kuigi mõnede tavade jaoks on antud üldised soovitused. Erinevate tingimuste korral võib sama tulemuse saavutada erineval viisil. Need on pigem üldised tööpõhimõtted kui konkreetsed tegevused.

Ühiste omaduste järjepidev rakendamine rakendab tegelikult äriprotsesside täiustamise tsüklit (äriprotsesside täiustamine - BPI-cm. Riis. 5.), st. äriprotsesside (BP) pidev täiustamine.

Riis. 5. Äriprotsesside pideva täiustamise tsükkel vastavalt CMM mudelile ja ISO 9000:2000 standardile.

Soov saada võimalikult lühikese aja jooksul vastavussertifikaat sunnib konsultatsioonifirmasid ja kvaliteedijuhtimisega tegelevaid spetsialiste kasutama kõigi loetletud kõrgetasemeliste mudelite paindlikkust ja nõuete raamistikku oma “isekas” eesmärkidel.
Selle sündmuste sundimise tulemusena on näiteks organisatsioonil, mis on saanud ISO 9000:2000 sertifikaadi, ISO 9001 järgimiseks määratletud ainult minimaalne nõutav protsesside komplekt, mitte aga kõik protsessid, mida ettevõte nõuab toimivad tõhusalt – vt. Riis. 2. Lisaks ei pruugi protsesside detailsus olla piisav, et mõista selgelt, mis protsesside sees toimub ja kes protsessis milliste ülesannete eest vastutab.
Parimal juhul on uued protseduurid läbinud vaid üksikud testprojektid ning mõne aja möödudes selgub vajadus nende kohenduste ja täienduste järele. Tihtipeale unustatakse protsessid kohe pärast QMS sertifitseerimist kuni järgmise järelevalveauditini, unustades kulutatud rahalised ressursid ja töötajate entusiasm.
Tõepoolest, kui tegutsete sõltumatu audiitorina, on väga raske tõestada, et vastuvõetud protsesside üksikasjalikkuse tase ei ole ettevõtte kvaliteedijuhtimise tõhusaks toimimiseks ilmselgelt piisav. Kuid ISO 9000 auditile eraldatud aja jooksul on üliraske tõestada vastupidist (seda saab väga edukalt kasutada audiitorile vastu astudes). Praktika näitab, et isegi 3. küpsusastmega efektiivseid protsesse (nagu ka ISO 9000-l põhinevaid protsesse) pole võimalik kiiresti üles ehitada.
Selle saavutamiseks ei piisa lihtsalt protsesside kirjeldamisest valitud mudeli nõudeid arvestades. Peamine raskus seisneb selles, et see on vajalik ümber kujundada organisatsiooni sees tootmiskultuur .

Ja seda on võimatu teha juhtkonna tahtejõulise otsusega. Seetõttu on CMM-is määratletud lähenemisviis lihtsalt elujõulisem ja realistlikum kui ISO 9000 cm mudelid. Riis. 5.

Vaatleme nüüd, kuidas on praktikas võimalik ehitada mõlema mudeliga ühilduv QMS.

Eksperthinnang CMM-i võtmeprotsesside ISO 9000:2000 nõuetega hõlmatuse astme kohta vastavalt CMM-i autorite endi hinnangule (4) on näidatud Joonis 6.

Tegelikult viidi nende hindamine läbi kahe koordinaadi järgi:

kindlusaste (%) arendusprotsesside (SWP) vastavuse küpsustasemele CMM raames -" säte";

sellise sätte võimalikkuse määr (%), mis on antud standardiga ISO 9000:2000 - " võimalus".

Nagu näha on Riis. 6, ISO 9000:2000 nõuded loovad reaalse võimaluse saavutada isegi SWP küpsuse ülemine (CMM Level 5) tase.

Kuid juba vähemalt kolmanda (CMM Level 3) taseme SWP küpsuse tagamise mõttes vajab ISO 9000:2000 mudeli kohane QMS veidi muutmist - nimelt veel kahe organisatsioonilise protseduuri väljatöötamist ja juurutamist ( Organisatsiooni protsessi määratlus ja fookus) ja üldine juhtimisprotseduur ( Integreeritud tarkvarahaldus ), mille sisu pole raske ühelegi IT-ettevõttele.

Kuid võite ja peaksite minema kaugemale (CMM tase 4) - näiteks sulgudes on näidatud selle artikli autori hinnang (samades koordinaatides - toetatavus ja võimalused), mis vastab ISO 9000 järgi QMS-ile: 2000 mudel, milles QMS protsessimaastikku täiendatakse protsesside projektijuhtimisega vastavalt teise ülalmainitud standardi nõuetele PM Bok- see aitab teil oluliselt suurendada selliste toodete küpsust SWP, Kuidas:

Projektide edenemise jälgimine (Tarkvaraprojektide jälgimine ja järelevalve);

• Tarkvaraprojektide planeerimine;

Üldine tarkvarahaldus (Integreeritud tarkvarahaldus);

Protsessi juhtimine kvantitatiivsete hindamiste kaudu (Quantitative process management).

Riis. 6. Eksperthinnang põhiliste CMM-protsesside katvuse kohta ISO 9000:2000 nõuetega

Nagu näha on Joonis 6., CMM-mudel on sellesse põimitud põhimõtete järgi väga lähedane ISO 9001:2000 standardi järgi üles ehitatud ja projektijuhtimise protsessidega täiendatud kvaliteedisüsteemile. PM BoK..

Et mitte teha asjatut tööd, tehes samaaegselt ISO 9000 järgi sertifitseerides ja sellele järgnevat CMM-i järgi hindades, soovitan oma tootmisprotsesside defineerimisel kaasata (või võib-olla nendega piirduda - IT-ettevõtte jaoks on need ju tootmisprotsessid !) kõik vajalik CMM KPA mudelis. Seega ettevõte samaaegselt:

vastab nõuetele ISO 9001:2000 protsessipõhise lähenemisviisi juurutamise kohta;

kõik vajalikud dokumendid CMM protsessid ( KPA);

rakendab mitmeid selliseid olulisi nõudeid ISO 9001:2000 Kuidas:

meetrikapõhine protsessijuhtimine (Kvantitatiivne protsessijuhtimine);

tarnijate juhtimine allhankehalduse alusel ( Tarkvara allhankehaldus );

põhjal tarbijate nõudmiste analüüs nõuete haldamine ( Nõuete haldamine );

põhinev personalijuhtimine Treeningprogramm );

põhinev kommunikatsioonijuhtimine organisatsiooni protsesside formaalsete mudelite loomine ( Organisatsiooni protsessi määratlus );

käivitab parendusmehhanismi (Planeeri-tee-kontrolli-tegevus) kõik kirjeldatud protsessid (SWP) kõigi viie järjekindla rakendamise kaudu Ühised omadused-cm. Riis. 5.

Seega, kui kasutate KPA CMM-i BP-na ja kasutate tarkvara arendamise projektijuhtimisprotseduuride nõudeid PM BoK, siis saab sel viisil konstrueeritud QMS-i hinnata CMM tase 4 - cm. Riis. 7.

Riis. 7. Skeem CMM 4. taseme saavutamiseks, kasutades ISO 9000 QMS mudelit ja PM BoK 2000 juhendit koos.

Kokkuvõtteks esitan selguse huvides (autori stiliseeringus) IT-ettevõtte QMS-i toimimise skeemi ISO 9000 ja CMM mudelite järjepideva rakendamisega - vt. Riis. 8.

Riis. 8. Kvaliteedisüsteemi toimimise skeem ISO 9000 ja CMM mudelite järjepideva rakendamisega (autori stiliseerimine)

Siinkohal on oluline mõista, et nii CMM kui ka ISO 9001:2000 on iseenesest vaid vahendid pidevaks täiustamiseks.

Seega peaks ISO 9001:2000 standardi kohane sertifitseerimine ja sertifikaadi kinnitamine aitama kaasa ettevõtte protsesside kvaliteedi kasvule, kus protsessi kvaliteedi kasvu hindamise kriteeriumiks on ettevõtte jõudmine uuele tasemele. BPI ehk nende hinnang põhineb juba mudelil CMM {3}.

Kirjandus

"Tarkvara kvaliteedi hindamine", V. Lipaev, Sinteg, 2001.

ISO 9001:2000. Kvaliteedijuhtimissüsteem. Nõuded.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Tarkvara võimekuse küpsusmudel (SW-CMM), versioon 1.1. // CMU/SEI-93-TR-024, - veebruar, 1993.

Märkus: Üksikasjalikult uuritakse ideid, mis on tõenäoliselt kõige tuntuma tarkvara arendusprotsesside täiustamise metoodika – CMM – aluseks. Analüüsitakse HMM-i loogikat ja struktuuri. Näidatud on seos HMM-i ja varem uuritud protsessimudelite vahel.

Sees loodud suurepärane praktiline tööriist protsessi lähenemine tegevuse kirjeldusele projekteerimisorganisatsioon, eelkõige arenevad organisatsioonid Infosüsteemid, demonstreerib HMM-i metoodikat. CMM tähistab võimekuse küpsusmudelit, mis tähendab umbkaudu "juhtimissüsteemi küpsusmudelit". Kirjanduses nimetatakse CMM-i sagedamini kui organisatsiooni küpsusmudelit ja seda traditsiooni järgin ka mina.

SMM-i tekkimise ajalugu on järgmine. 80ndate lõpus. eelmisel sajandil tellis USA kaitseministeerium Tarkvaratehnoloogia Instituudi 1eng. SEI – Tarkvaratehnika instituut Carnegie Melloni ülikool töötab selle nimel, et luua kriteeriumide süsteem tarkvaraarendusprojektide alltöövõtjate valimiseks. Töö valmis 1991. aastal ja tulemuseks oli CMM-mudel. Kohe tuleb teha reservatsioon, et mudel ei sisalda rahalist, majanduslikku, poliitilist, organisatsioonilist valikukriteeriumid alltöövõtja, samuti salastatud töödele juurdepääsu võimaluse kriteeriumid (tõenäoliselt selliseid ülesandeid ei seatud). Jutt käib ainult kriteeriumidest, mis kirjeldavad potentsiaalse alltöövõtja võimekust tarkvarasüsteemide arendamise osas.

CMM struktuur

Mudeli loojad võtsid organisatsiooni protsessid aluseks, et hinnata organisatsiooni võimet teha kvaliteetset tööd, mida nimetati küpsuseks. Seejärel tegid nad mitu mittetriviaalset oletust, mida paljud IT-spetsialistid (ja võib-olla enamik neist) hiljem aktsepteerisid ja õiglaseks tunnistasid.

Eeldus 1. Küpsusastmeid on kvalitatiivselt erinevad projekteerimisorganisatsioon, arenev Infosüsteemid(HMM-i mudelis on viis sellist taset).

2. eeldus. Iga arendusorganisatsioon on huvitatud kõrgemale küpsusastmele liikumisest (mitte ainult selleks, et suurendada oma võimalusi kaitseministeeriumi lepingute konkursil, vaid ka enda täiustamise eesmärgil).

3. eeldus. Üleminek on võimalik ainult järjekorras järgmisele tasemele. Üle taseme “hüppamine” on võimatu (täpsemalt suurenevad organisatsiooni jaoks riskid järsult).

Seega moodustavad tasemed “redeli”, mida mööda organisatsioon arenedes tõuseb. Iga taset iseloomustab organisatsiooni protsesside teatud koostis ja omadused. SMM-i "tasandite redel" on pälvinud laialdast tunnustust ja levitamist. Selline ta välja näeb.

Tase 1 "Algaja". Tootmisprotsessi tervikuna iseloomustatakse kui iga kord konkreetse projekti jaoks loodud ja mõnikord isegi kaootilist. Määratletakse vaid mõned protsessid ja projekti edu sõltub üksikisikute pingutustest.

Tase 2 "Korratav". Kehtestatud on põhilised projektijuhtimise protsessid, mis võimaldavad jälgida kulusid, jälgida töögraafikut ja loodud tarkvaralahenduse funktsionaalsust. Kehtestatud on protsessidistsipliin, mis on vajalik sarnaste rakenduste arendusprojektide varasemate edusammude kordamiseks.

3. tase "määratletud". Tootmisprotsess on dokumenteeritud ja standardiseeritud nii juhtimise kui disaini osas. See protsess on integreeritud organisatsiooni standardsesse tootmisprotsessi. Kõik projektid kasutavad heakskiidetud kohandatud versiooni organisatsiooni standardsest tootmisprotsessist.

4. tase "Hallatud". Kogutakse üksikasjalikud kvantitatiivsed näitajad tootmisprotsessi ja loodud toote kvaliteedi kohta. Nii tootmisprotsessi kui ka tooteid hinnatakse ja kontrollitakse kvantitatiivsest aspektist.

5. tase "Optimeerimine". Protsessi pidev täiustamine saavutatakse protsessist saadava kvantitatiivse tagasiside kaudu ning arenenud ideede ja tehnoloogiate rakendamisega selles.

Vaatamata ranguse puudumisele ei tekita antud määratlus intuitiivselt enamasti vastuväiteid. Pealegi saavad kogenud spetsialistid aru, miks on üleminekud võimalikud vaid naabertasandile, samuti on selge, miks sellise ülemineku poole üldse tasub püüelda. Samas ei sisalda HMM-mudel selle lähenemise kvantitatiivset ega isegi formaalset põhjendust, mis aga ei vähenda kuidagi selle eeliseid.

Mis edasi saab, nagu öeldakse, on tehnika küsimus. Määratakse kindlaks mudeli struktuur (joonis 7.1), antakse definitsioonid ja alustatakse vaevarikast tööd, et iga protsessi igal tasandil täpselt kirjeldada. Selleks, et hinnata tehtu praktilist väärtust, läheme sellest osa.

Riis. 7.1.

Joonisel fig. 7.1 sisaldab järgmisi mõisteid.

Võtmeprotsessi rühm. Nagu on öeldud (Paulk et al., 1995), "iga võtmeprotsesside rühm määratleb seotud tegevuste ploki, mille tulemusena saavutatakse eesmärkide kogum, mis on tootmisprotsessi tootlikkuse tõstmiseks olulised. näiteks võtmeprotsesside rühma jaoks" Nõuete haldamine"(Vt joonis 7.2) eesmärk on ühildada kliendi ja arendaja nõuded tarkvaraarendusprojektile."

CMM-is pole üksikuid protsesse. Selle asemel on olemas eraldi teosed, mida nimetatakse võtmepraktikateks (vt allpool), mis on omavahel sisendite ja väljundite kaudu ühendatud ning toimivad ehitusprotsesside lähtematerjalina. CMM ei anna juhiseid selle kohta, kuidas protsesse tuleks üles ehitada, st kuidas tuleks võtmepraktikaid loogilisteks järjestusteks siduda. Võtmepraktikate komplekte nimetatakse võtmeprotsessirühmadeks.

Võtmeprotsesside rühmad CMM-is on kaardistatud küpsustasemetele (joonis 7.2), st kõik ühe taseme praktikad suhtlevad ainult üksteisega ja ei suhtle teiste tasandite praktikatega. See võimaldab meil tagada kõigi protsesside täieliku funktsionaalsuse konkreetsel tasemel ja seega korreleerida taset organisatsiooni lõppenud arenguetapiga.

Omadussõna "võti" viitab sellele, et neid on protsessi rühmad(st praktikate kogum), mis ei ole konkreetse küpsusastme seisukohast võtmetähtsusega, st ei ole seotud selle taseme eesmärkide saavutamisega (vt allpool). HMM-mudel ei kirjelda kõike protsessi rühmad seotud tarkvaraarenduse ja hooldusega. See kirjeldab ainult neid rühmi, mis on tootmisprotsessis määratletud kui peamised tootlikkuse määrajad.

Eesmärgid. HMM-i eesmärgid ei ole seotud protsessidega, vaid võtmeprotsesside rühmadega. Nagu eespool mainitud, saavutatakse eesmärgid võtmepraktikate rakendamise kaudu. CMM-is tähendab eesmärgi saavutamine seda, et esiteks saavutatakse pärast põhipraktikate läbimist soovitud tulemus ja teiseks saadakse see üsna järjepidevalt. Viis, kuidas võtmeprotsesside rühma eesmärgid saavutatakse, võib projektiti erineda, sõltuvalt erinevustest ainevaldkond või keskkond.

Kui need eesmärgid saavutatakse kõigi projektide puhul, tähendab see, et organisatsioon on jõudnud tootmisprotsessi küpsustasemele, millega see võtmeprotsesside rühm on seotud.

Peatükk. Sektsioonid (neid on igal tasandil viis ja need on alati samad) esindavad võtmeprotsesside rühmade omadusi, mida tuleb vastaval tasemel realiseerida. Need omadused kirjeldavad, kuidas protsesse rakendatakse ja mil määral need on organisatsioonis legaliseeritud, st ametlikult heaks kiidetud ja kooskõlas ettevõtte protseduuride, poliitikate ja muude protsessidega. Need on viis jaotist.

Täitmiskohustused

Kirjeldage tegevusi, mida organisatsioon peab läbi viima, et tagada protsessi väljakujunemine ja stabiilsus. Rakenduskohustused on tavaliselt seotud organisatsiooni poliitikate kehtestamisega ja kõrgema juhtkonna toetusega.

Eeldused

Kirjeldada eeldusi, mis peavad olema projektis või organisatsioonis täidetud tootmisprotsessi pädevaks elluviimiseks; tavaliselt seotud ressursside, organisatsiooniliste struktuuride ja nõutava koolitusega.

Teostatud operatsioonid

Jaotises "Teostatud toimingud" kirjeldatakse sisulist tööd, mida sellel tasemel tuleb teha. Teostatud toimingud hõlmavad tavaliselt plaanide koostamist ja konkreetsete tegevuste elluviimist, tööde teostamist ja jälgimist ning vajadusel parandusmeetmete võtmist.

Mõõtmised ja analüüs

Jaotis "Mõõtmised ja

"Iga võtmeprotsesside gruppi väljendavad võtmepraktikad, mille rakendamine aitab kaasa grupi eesmärkide saavutamisele. Võtmepraktikad kirjeldavad infrastruktuuri ja toiminguid, mis annavad suurima panuse võtmeprotsesside rühma efektiivsesse elluviimisse ja sisseseadmisse.

Iga põhipraktika koosneb ühest lausest, mida sageli laiendatakse üksikasjalikumaks kirjelduseks, mis võib sisaldada näiteid ja selgitusi. Põhitavad, mida mõnikord nimetatakse ka tipptasemel põhipraktikateks, kehtestavad põhiprotsesside rühma põhipoliitikad, protseduurid ja toimingud. Üksikasjaliku kirjelduse komponente nimetatakse sageli alampraktikateks."

Põhitavad kirjeldavad, MIDA tuleb teha, kuid neid ei tohiks võtta dogmana, mis ütleb, KUIDAS eesmärke saavutada. Võtmeprotsesside rühma eesmärke saab saavutada alternatiivsete tavade abil. Peamiste tavade tõlgendamine peaks olema mõistlik, võimaldades saavutada võtmeprotsessirühma eesmärgid tõhusal viisil, kuigi võib-olla formaalselt erinev CMM soovitatust.

Vaade IT-juhtimise tegevustest, milles protsesside asemel käsitletakse nende komponente – võtmepraktikaid ja protsessid on olemas vaid virtuaalselt, kui võtmepraktikatest ülesehitatavast asjast, tundub esmapilgul mõneti eksootiline. Seni lahendati IT-juhtimise täiustamise ülesanne võrdlusprotsessimudelist valmisprotsesside kasutuselevõtuga. Nüüd on palju tasemeid, mis sisaldavad erinevaid (st ei ole protsessidesse integreeritud) põhipraktikaid ja soovitatud astmete läbimise järjestust. IT-juhtimine paraneb CMM-i kohaselt, kui see liigub kõrgemale küpsustasemele. Mis sellise eduga edasi saab?

Tasandite definitsioonides (vt joonis 7.2) ilmus selline mõiste nagu “tootmisprotsess”. See on olemas ka võtmeprotsesside rühma määratluses ja see pole juhus. Tootmisprotsess või, nagu seda SMM-is täpselt nimetatakse, organisatsiooni standardne tootmisprotsess (SPPO) on kogu mudeli üks keskseid kontseptsioone.

Vaatleme kvaliteedi tagamise mudelite arengut protsessi küpsusmudeli või võimekuse parandamise mudeli alusel. CMM (Capability Maturity Model). Vaatamata sellele, et mudel SMM on suunatud tarkvara kvaliteedi tagamisele, selle metoodilised aspektid on rakendatavad mis tahes toote (kaubad, tööd, teenused) kvaliteedi tagamise mudelite puhul.

Peamine asi mudelis SMM on organisatsiooni küpsuse mõiste.

Ebaküps peetakse organisatsiooniks, kus tarkvara arendusprotsess sõltub ainult konkreetsetest tegijatest ja juhtidest ning otsused tehakse sageli "lennult". Sel juhul on suur tõenäosus ületada eelarvet või jääda projekti tähtajast mööda ning seetõttu on juhid sunnitud tegelema vaid koheste probleemide lahendamisega.

Küpsed Organisatsioon loetakse, kui on täidetud järgmised tingimused:

• – tarkvaratoodete loomiseks ja projektide juhtimiseks on selgelt määratletud protseduurid, mida pilootprojektides täpsustatakse ja täiustatakse, analüüsides “kulu-kasumi” komponente;
• – hinnangud tööde tegemise aja ja maksumuse kohta põhinevad kogunenud kogemustel ja on seetõttu üsna täpsed;
• – ettevõttel on standardid tarkvara arendamise, testimise ja juurutamise protsesside kohta, reeglid lõpliku programmikoodi, komponentide, liideste jms kujundamiseks. Kõik see moodustab taristu ja ettevõtte kultuuri, mis toetab tarkvara arendusprotsessi.

Nii et standard SMM on kvaliteedi tagamise mudel, mis koosneb organisatsiooni küpsuse hindamise kriteeriumidest ja retseptidest olemasolevate protsesside täiustamiseks. Mudelis SMM Määratletud on viis organisatsioonide küpsusastet, mille omadused on toodud joonisel fig. 5.3.

Riis. 5.3. Viis mudeli küpsusastetSMM

Esimene tase (esialgne tase) on aluseks ettevõtte arengule järgmistel tasanditel. Arvatakse, et organisatsiooni algtasemel pole kvaliteetse tarkvara loomiseks stabiilseid tingimusi. Järelikult sõltub iga projekti tulemus täielikult juhi isikuomadustest ja programmeerijate kogemustest. See tähendab, et ühe projekti edu saab korrata ainult siis, kui järgmisesse projekti on määratud samad juhid ja programmeerijad. Kui projektides kogemusi omandanud juhid või programmeerijad lahkuvad ettevõttest, siis nende lahkumisega langeb toodetava tarkvara kvaliteet järsult.

Tuleb mõista, et algtasemel, stressirohketes olukordades, mis sõltuvad suuresti inimfaktorist, taandub arendusprotsess koodi kirjutamisele ja minimaalsele testimisele.

Teise saavutamine korratav tase (korduv tase) on määratud projektijuhtimise tehnoloogia rakendamisega ettevõttes. Planeerimine ja projektijuhtimine ettevõttes põhineb kogutud kogemustel, arendatava tarkvara puhul on olemas ja kasutusel standardid, mille täitmist jälgib spetsiaalne kvaliteeditagamisgrupp. Arvatakse, et teine ​​tase võib pakkuda nii võimalusi edasiseks täiustamiseks (kolmandale tasemele üleminek) kui ka ei välista võimalust kriitilistes tingimustes tarkvara loomise protsessi kvaliteedi regressiivseks naasmiseks algtasemele.

Kolmandaks teatud tase (määratletud tase) mida iseloomustab tõsiasi, et tarkvara loomise ja hooldamise standardprotsess on täielikult dokumenteeritud alates tarkvaraarendusest kuni projektijuhtimiseni. Selle taseme rakendamise hüpotees on, et standardimise käigus läheb ettevõte üle kõige tõhusamatele tavadele ja tehnoloogiatele. Tarkvaraarenduse ja projektijuhtimise standardite loomiseks ja haldamiseks tuleb organisatsiooni sees luua spetsiaalne rühm. Kolmanda taseme saavutamise eelduseks on pideva professionaalse arengu ja töötajate koolitamise programmi olemasolu ettevõttes. Arvatakse, et alates sellest tasemest lakkab organisatsioon sõltumast konkreetsete arendajate omadustest ega kipu stressiolukordades libisema madalamale tasemele.

Neljandal, juhitav tase (hallatud tase) Ettevõte kehtestab kvantitatiivsed kvaliteedinäitajad - nii tarkvaratoodete kui ka nende loomise protsesside jaoks tervikuna. Seega saavutatakse parem projektijuhtimine, vähendades erinevate projektinäitajate dispersiooni. Sel juhul eraldatakse rakendatud tarkvara loomise protsesside tähenduslikud (signaali) variatsioonid protsessi juhuslikest (müra) variatsioonidest.

viies (kõrgeim), optimeerimise tase (optimeerimise tase) mida iseloomustab asjaolu, et parendusmeetmeid rakendatakse mitte ainult olemasolevate protsesside puhul, vaid ka uute tehnoloogiate kasutuselevõtu tõhususe hindamiseks. Ettevõtte põhiülesanne sellel tasemel on olemasolevate protsesside pidev täiustamine. Samas peaks protsessi täiustamine aitama vältida võimalikke vigu ja defekte. Samal ajal tuleks teha tööd tarkvaraarenduse kulude vähendamiseks.

Parandusmudelid

Nõudeprotsesside täiustamine

Kvaliteedijuhtimise paradigma kui tootmise korraldamise viis tekkis juba ammu. Ideed on manustatud ISO9000 standardite rühma 1) , on juurdunud eelkõige sellistes “nõukogude” leiutistes nagu ratsionaliseerimisettepanekute toetamine, mentorlus jne.

Protsessile orienteeritud ärikorralduse kaasaegses kontseptsioonis on pideva kvaliteedi parandamise protsess üks võtmepositsioone.

Seoses tarkvaratööstusega on lisaks ISO9000 seeriale kõige edukamalt tõestatud kvaliteedistandardid SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Kvaliteedijuhtimise meetodite aktiivne juurutamine läänes algas 1960. aastate alguses. ISO9000 seeria standardid põhinevad CPI (Continuous Process Improvement) ja TQM (Total Quality Management) lähenemisviisidel. Sõjajärgse Jaapani majanduse taastumine oli suuresti tingitud TQM-i juurutatud ideedest.

Kvaliteet on mõiste, mis ühtede jaoks tähendab vajadust teha seda, mida tarbija soovib, teise jaoks seda, mis tema vajadustele vastab. Kvaliteedijuhtimine, nagu on määratletud ISO 9001:2000, põhineb peamiselt ideel, et inimesed toimivad paremini, kui nad teavad, mida nad teevad. .

Seetõttu peaksite enne toimingu alustamist saama vastused küsimustele: mida on vaja teha, kes kontrollib tehtut, kuidas seda teha ja kuidas teha kindlaks, et töö on lõpetatud? Samuti peate kaaluma, kuidas kavatsete protsessi juhtida ja kuidas seda parandada.

ISO9000 põhiprintsiibid:

• Keskendumine kliendi vajadustele;
• Juhtkonna aktiivne juhtroll;
• Teostajate kaasamine parendusprotsessidesse;
• Protsessi lähenemisviisi rakendamine;
• Süstemaatiline lähenemine juhtimisele;
• Pideva täiustamise tagamine;
• Faktipõhine otsuste tegemine;
• Vastastikku kasulikud suhted tarnijatega.

Selle rühma standardite vaieldamatu eelis tuleneb asjaolust, et neid on testitud paljudes ettevõtetes üle maailma. Nende standardite soovitused on aga üsna üldised ega võta arvesse IT-valdkonna ettevõtete eripära. Selle saavutamiseks on välja töötatud spetsiaalsed lähenemisviisid, mida arutatakse allpool.

CMM (võimekuse küpsusmudel) standardi töötas välja Carnegie Melloni ülikooli Tarkvaratehnika Instituut (SEI).

Standardi eesmärk on hinnata tarkvaraarenduse organisatsiooni küpsusastet. Taset on viis: esialgne, korratav, määratletud, hallatav ja optimeeriv (lisateavet vt). See standard on saanud laialt tuntuks, märkimisväärne hulk Lääne IT-ettevõtteid on sertifitseeritud CMM-i järgi.

2000. aastal andis SEI välja CMMI-SE/SW, integreeritud mudeli nii tarkvara kui ka süsteemi projekteerimise võimaluste parandamiseks.

CMMI-SE/SW-l on kaks vormi. Lavastatud esitus vastab SW-CMM struktuurile koos tasemenimede väiksemate täpsustustega. Viis küpsusastet sisaldavad 22 protsessipiirkonda, mis on näidatud tabelis 14.1. (CMU/SEI, 2000a). Pidev esitus võtab teistsuguse vaate: samad 22 valdkonda on struktureeritud 4 kategooriasse: protsessijuhtimine, projektijuhtimine, ehitus ja tugi (CMU/SEI, 2000b).

Küpsustasemete asemel määratleb pidev vaade iga protsessipiirkonna jaoks kuus võimekuse taset. See vaade võimaldab igal organisatsioonil otsustada, millisele võimekuse tasemele ta kvalifitseerub igas 22 protsessivaldkonnas.

Nagu CMM-is, on ka selles standardis 2. tasemel valdkond nimega “Nõuete haldamine”, kuid erinevalt eelmisest standardist on tasemel 3 ka eraldi valdkond “Nõuete projekteerimine”. Selle valdkonna paigutamine 3. tasemele ei tähenda, et nõudeid organisatsiooni projektidele, mis ei jõua 2. tasemele, ei pea koguma ja dokumenteerima. Nõudehaldust nähakse aitajana luua prognoositavamaid ja vähem kaootilisi projekte, mis on CMM Level 2 olemus. Võttes kasutusele muudatuste juhtimise ja nõuete staatuse kontrollimise protsessi, saab organisatsioon rohkem keskenduda kvaliteetsete nõuete väljatöötamisele.

Nõuded Juhtimisprotsessi valdkond

Võtmeteemadeks on see, kuidas arendusmeeskond peaks omandama arusaamist nõuetest ja lahendama probleeme klientidega, kaasama projektiliikmeid nõuete töösse ja juhtima muutusi. Erinevalt SW-CMM-ist on jälgimine (üks põhinõuete omadusi) kaasatud vaadeldavasse protsessivaldkonda. Standard käsitleb järgmisi marsruutimise omadusi:

• madala taseme või teisejärguliste nõuete allikate registreerimine;
• iga nõude jälgimine sekundaarsete nõueteni ja selle paigutamine funktsioonidesse, objektidesse, protsessidesse ja täitjatesse;
• horisontaalsete seoste loomine samasse liiki kuuluvate nõuete vahel.

Nõuded Tehnilise protsessi valdkond

CMMI-SE/SW kirjeldab kolme nõuete inseneritehnikate komplekti:

• tehnikad, mis määratlevad täieliku kliendi nõuete komplekti, mida seejärel kasutatakse tootele esitatavate nõuete väljatöötamiseks (projekti sidusrühmade vajaduste tuvastamine; vajaduste ja piirangute teisendamine kliendi nõueteks);
• tehnikad, mis määratlevad tootele täieliku nõuete komplekti (kehtestada toote komponendid; seada nõuded toote komponentidele; määrata liidese nõuded);
• tehnikad sekundaarsete nõuete saamiseks, nõuetest arusaamiseks ja nende valideerimiseks (töökontseptsioonide ja stsenaariumide kehtestamine; süsteemi vajaliku funktsionaalsuse määramine; sekundaarsete nõuete analüüsimine; toote loomise maksumuse, ajastuse ja riski hindamine; nõuete kinnitamine).

Nii CMM kui ka CMMI sätestavad eesmärgid, mille poole projekti- või tarkvaraarendusorganisatsioon peaks erinevates protsessivaldkondades püüdlema. Samuti soovitavad nad tehnikaid, mis aitavad neid eesmärke saavutada.

CMMI-SE/SW reguleerib seoseid nõuete haldamise, nõuete kavandamise ja muude protsessivaldkondade vahel (joonis 14.1).