Võimekuse küpsuse mudel (CMM). Standardid ISO, SW-CMM

Parandusmudelid

Nõuete täitmise protsesside 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 äriorganisatsiooni kaasaegses kontseptsioonis on pideva kvaliteedi parandamise protsess üks võtmepositsioone.

Tarkvaratööstuse osas on lisaks ISO9000 seeriale edukaimad kvaliteedistandardid SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Kvaliteedijuhtimise meetodite aktiivne juurutamine läänes algas 1960. aastate alguses. ISO9000 seeria standardite aluseks oli CPI (Continuous Process Improvement) ja TQM (Total Quality Management) lähenemisviiside filosoofia. Sõjajärgse Jaapani majanduse tõus oli suuresti tingitud TQM-is sisalduvatest ideedest.

Kvaliteet on termin, mis ühtede jaoks tähendab vajadust teha seda, mida tarbija soovib, teiste jaoks – seda, mis vastab tema vajadustele. Kvaliteedijuhtimine, nagu on määratletud ISO 9001:2000, põhineb eelkõige sellel, et inimesed toimivad paremini, kui nad teavad, mida nad teevad. .

Seetõttu tuleks enne mis tahes tegevuse alustamist saada 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 klientide vajadustele;
• Juhtkonna aktiivne juhtroll;
• Teostajate kaasamine parendusprotsessidesse;
• Protsessi lähenemisviisi rakendamine;
• Süsteemne lähenemine juhtkonnale;
• 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 maailma ettevõtetes. Nende standardite soovitused on aga oma olemuselt üsna üldised ega võta arvesse IT-ettevõtete eripära. Selleks on välja töötatud spetsiaalsed lähenemisviisid, mida arutatakse allpool.

CMM-standardi (võimekuse küpsuse mudel) töötas välja Inseneriinstituut tarkvara(SEI) Carnegie Melloni ülikoolis.

Standardi eesmärk on hinnata organisatsiooni – tarkvaraarendaja – “küpsuse” taset (küpsustasemeid). Eristatakse viit taset: esialgne, korratav, määratletud, hallatav ja optimeeriv (vt täpsemalt). 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-i struktuurile väikeste täpsustustega tasemenimedes. Viis küpsusastet sisaldavad 22 töövoo piirkonda, 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, disain ja tugi (CMU/SEI, 2000b).

Pidevas vaates on küpsustasemete asemel iga protsessivaldkonna jaoks määratletud kuus võimekuse taset. See vaade võimaldab igal organisatsioonil otsustada, millist võimekuse taset nad igas 22 protsessivaldkonnas vajavad.

Nagu CMM-is, on selles standardis 2. tasemel valdkond nimega "Nõuete haldamine", kuid erinevalt eelmisest standardist on tasemel 3 ka eraldi nõuete arendamise ala. Selle valdkonna paigutamine 3. tasemele ei tähenda, et nõudeid organisatsiooniprojektidele, mis ei jõua tasemele 2, ei pea koguma ja dokumenteerima. Nõudehaldust nähakse võimalusena luua prognoositavamaid ja vähem kaootilisemaid projekte, mis on CMM-i 2. taseme põhiolemus. Muutuste juhtimise ja nõuete staatuse kontrollimise protsessi kasutuselevõtmisega saab organisatsioon rohkem rõhku panna kvaliteetsete nõuete väljatöötamisele.

Tabel 14.1.
küpsusaste	Nimi	Töötlemispiirkonnad
	Elementaarne	(Ei)
	Hallatud	Nõuete haldamine Projekti planeerimine Projekti seire ja kontroll Tarnijalepingute haldamine Mõõtmis- ja analüüsiprotsesside ning tootekvaliteedi tagamise konfiguratsioonihaldus
	Kindel	Nõuded Arendus Tehniline lahendus Toote integreerimine Kontrollimine Valideerimisprotsess Fookus Organisatsiooniprotsess Määratlus Organisatsiooni õpe Integreeritud projektijuhtimine Riskijuhtimine Probleemi analüüs ja lahendamine
	kvantitatiivselt juhitud	Esitus organisatsioonilised protsessid Kvantitatiivne projektijuhtimine
	Optimeerimine	Organisatsioonilised uuendused ja nende juurutamine Juhuslik analüüs ja lahendus

Nõuete haldamise protsesside valdkond

Olulisemad teemad hõlmavad seda, kuidas arendusmeeskond peaks omandama arusaamise nõuetest ja lahendama probleeme klientidega, kaasama projekti sidusrühmi nõuetega töötamisse ja juhtima muutusi. Erinevalt SW-CMM-ist on jälgimine (üks nõuete põhiomadustest) kaasatud vaadeldavasse protsessipiirkonda. Standardis käsitletakse järgmisi jälgimise omadusi:

• madala taseme või teisejärguliste nõuete allikate arvestuse esitamine;
• iga nõude jälgimine sekundaarsete nõueteni ja selle järjestamine funktsiooni, objekti, protsessi ja töötaja järgi;
• horisontaalsete seoste loomine samasse liiki kuuluvate nõuete vahel.

Nõuded inseneriprotsesside valdkond

CMMI-SE/SW kirjeldab kolme nõuete väljatöötamise tehnikate 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; vajadused ja piirangud kliendi nõueteks teisendamiseks);
• tehnikad, mis määravad tootele esitatavate nõuete täieliku komplekti (installige toote komponendid; asetage nõuded toote komponentidele; määrake liidese nõuded);
• tehnikad sekundaarsete nõuete saamiseks, nõuetest arusaamiseks ja nende kinnitamiseks (töökontseptsioonide ja stsenaariumide kehtestamine; süsteemi vajaliku funktsionaalsuse määramine; sekundaarsete nõuete analüüsimine; toote loomise maksumuse, aja ja riski hindamine; nõuete kinnitamine).

Nii CMM kui ka CMMI sõnastavad eesmärgid, mida tarkvaraarenduse projekt või organisatsioon peaks püüdlema erinevaid valdkondi protsessid. Samuti soovitavad tehnikat aidates neid eesmärke saavutada.

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

05.04.2007 Vjatšeslav Pankratov

Tänapäeval räägitakse palju tarkvara kvaliteedist ja infosüsteemid, viiakse läbi uuringuid, mis näitavad automatiseeritud äriprotsesside kvaliteedi ja tõhususe sõltuvust. Tarkvara kvaliteet abstraktsest ja mittemateriaalsest kontseptsioonist muundub terviklikuks mõõdikuks tarkvaralahenduse, selle juurutamise projekti, loomisprotsessi ja infosüsteemide kui terviku kasutustaseme hindamiseks. Mis määrab saadete kvaliteedi ja kuidas saate seda mõjutada?

Tänapäeval räägitakse palju tarkvara ja infosüsteemide kvaliteedist, tehakse uuringuid, mis näitavad automatiseeritud äriprotsesside kvaliteedi ja efektiivsuse sõltuvust. Tarkvara kvaliteet abstraktsest ja mittemateriaalsest kontseptsioonist muundub terviklikuks mõõdikuks tarkvaralahenduse, selle juurutamise projekti, loomisprotsessi ja infosüsteemide kui terviku kasutustaseme hindamiseks. Mis määrab saadete kvaliteedi ja kuidas saate seda mõjutada?

Ilmselgelt sõltub tarkvara kvaliteet otseselt selle tootmisprotsessi kvaliteedist. Juhtides tootmisprotsessi ja jälgides selle kõigi tehnoloogiliste etappide tulemusnäitajaid, on võimalik mõjutada toote kvaliteeti. Rääkides programmide omadustest, saame eraldi välja tuua kvantitatiivsed mõõdikud, mida on lihtne mõista ja analüüsida, mis on seotud programmi koodi kvaliteediga (tsüklomaatilise koodi keerukus - mooduli struktuuri keerukus, näiteks sõltumatute marsruutide arv). see); disainihoidla artefaktidele määratud koodiridade arv jne; testid (koodiharude ja moodulite katmine testskriptidega, leitud vigade arvu suhe enne ja pärast toote väljalaskmist, vigade tuvastamise dünaamika jne); rakendusliidese ja tööplatvormide soovituste järgimise nõuete katvus. Kuid arendatud programmide kvaliteedi tagamise protsessitasemele üle minnes tekivad teatud raskused selle protsessi kvaliteedi mõistmisel. Tõepoolest, kuidas hinnata ja mõõta näiteks ühe või teise arendusmeetodi efektiivsust, kui kahe identse tarkvarasüsteemi arendusprojektid praktiliselt puuduvad ja veelgi enam, pole kahte identset kogemuste ja kogemuste poolest identset arendusmeeskonda. oskused? Otsustas lõpptulemus ei ole võimalik: lisaks tarkvara tootmise protsessitingimustele (kasutatav metoodika, projektimeeskonna struktuur, kliendiga suhtlemise meetodid) varieeruvad sageli ka projekti tingimused (tingimused, maksumus ja ressursside maht) suuresti. Tarkvara testimisprotsessi - tootmisprotsessi tehnoloogilise komponendi - üksikasjalikum käsitlemine paljastab testimise efektiivsuse mõõdikute valimise probleemi.

Lisaks konkreetse protsessi praeguse tõhususe taseme otsesele hindamisele on veel huvitavam ülesanne - tõhususe taseme tõstmine või, nagu öeldakse, küpsusaste protsessid. Kui on lahendatud põhiprobleemid testimistööde planeerimisel ja läbiviimisel integreerituna tarkvaraarendusprotsessiga, tekib ülesanne leida optimaalsed organisatsioonilised ja protseduurilised skeemid tööde teostamiseks. Olles vastanud küsimustele "kes" ja "millal", tuleb otsida vastuseid küsimustele "kuidas, mil viisil", "kuidas tulemusi mõõta", "kuidas kontrollida", "kuidas tõhusamalt töötada", ning ka „kuidas andmetele ja kogemustele tuginedes protsessi juhtida ja arendada.

Igapäevapraktikas – konkreetsete tööriistadega töötades – kujuneb IT-spetsialistidel ja projektijuhtidel kindel arvamus kõigi tarkvara kvaliteediga seotud probleemide tehnoloogilisest olemusest ja saavutatavatest tarkvaraarendusprotsesside küpsusastmetest. Selle tulemusena saab müüjate propageeritud usk kvaliteedi parandamise tarkvara jõusse praktikas kasvulavaks ebamõistlikele otsustele metoodikate juurutamiseks või arendusprotsesside automatiseerimiseks, alustades konkreetsete tarkvaralahenduste juurutamisest. Kuid kaasaegsed rajatised arendusprotsesside automatiseerimine on sedavõrd paindlikud ja kohandatavad platvormid, mis nõuavad protsessi komponendi eelnevat põhjalikku uurimist ning järgnevat juurutamist ja kohandamist konkreetsetele tootmistingimustele.

1980. aastal arenes välja Carnegie Melloni ülikooli tarkvaratehnika instituut tarkvara arendusprotsessi küpsusmudel(Capability Maturity Model for Software, CMM), millest hiljem kujunes välja CMMI (Capability Maturity Model Integration), mis on tarkvaratööstuses tunnustatud de facto arendusküpsuse taseme sertifikaat. Analoogiliselt tarkvaraarenduse maailma ja nende protsesside küpsuse olemasolevate mudelitega käsitleme testimisprotsessi küpsuse mudeleid.

Testi küpsusmudelit

Tarkvara testimise küpsusmudel on süstemaatiline lähenemine testimisprotsessi arendamisele, mis pakub efektiivsete protsesside elementide süsteemi ja viise konkreetsete protsessieesmärkide saavutamiseks. Küpsusmudelist lähtuvalt saab lahendada kaks protsessiarenduse põhiülesannet: mõista ja fikseerida käimasoleva testimisprotsess ning välja selgitada parendusvaldkonnad. Praktika näitab, et protsessimuutused on võimalikud ainult siis, kui juhtkond on selgelt aru saanud selliste muudatuste tegemise vajadusest – igasugused struktuurilised ja protseduurilised muudatused on võimatud ilma juhtkonna poliitilise tahteta. Lisaks juhtimistoetuse saamisele ja vajalikke ressursse, nõuab testimisprotsessi muudatuste tegemine nagu iga muu projektitegevus selget planeerimist.

Testikonsultant Terry Weatheril oli üks esimesi, kes võrdles 2001. aastal olemasolevaid testküpsuse mudeleid ja tuvastas kuus mudelit:

testitavuse küpsuse mudel (TMM);

Tarkvara testimise küpsusmudel (TMMSW);

Testimisprotsessi täiustamine (TPI);

katseorganisatsiooni küpsus (TOM);

Testimise hindamisprogramm (TAM);

Kavandatud hindamis- ja testimisalad SW-CMM võtmeprotsesside valdkonnad (SW-CMM KPA).

Seejärel tehti mõnedes mudelites põhimõttelised muudatused; Seega pakub TOM-mudel (selle lõi ja arendas Gerrard Consulting) uuendatud mõõdikute kogumit, mis kirjeldab testimisprotsessi ennast (testi iteratsioonide kestus, testimise stsenaariumide ja funktsionaalsete nõuete suhe jne), mida kogutakse. ja analüüsitakse olemasoleva protsessi kirjeldamise etapis.

Kuue tarkvara testimise küpsusmudeli hulgast tuvastavad praktikud ja konsultandid kaks: Illinoisi Tehnoloogiainstituudis välja töötatud TMMSW ja Sogeti pakutud TPI. Mõlemad mudelid on levinud eelkõige tänu oma lihtsusele, aga ka väljapakutud siseauditi praktikatele, mida saavad läbi viia protsesside täiustamise teele astunud ettevõtte spetsialistid. Mõelge tarkvara testimise küpsusmudelite struktuurile, kasutades näitena TMM-i mudelit.

Tarkvara testimise valdkonna ühe juhtiva konsultandi Thomas Staabi valitud TMMSW mudelit on kõige huvitavam rakendada, kuna see võimaldab koos tavade mõistmise ja kasutamise lihtsusega korraldada organisatsioonidel hinnanguid (hinnanguid) oma ja järk-järgult läheneda oma arengueesmärkidele, kontrollides vahetulemusi. Oma töös valisime ka selle mudeli kasuks, arvestades kodumaiste IT-ettevõtete seas kolmanda osapoole kompetentsi meelitamise tava ebapopulaarsust (ettevõtted püüavad säästa investeerimisprojektid, mis sisuliselt on nii konsultatsiooniprojektid kui ka kaudset kasu toovad projektid, mis hõlmavad protsessimuutusi) ning kutsume tutvuma meie kogemusega, mis näitab ettevõtete valmisolekut iseseisvalt sisemisi muudatusi läbi viia, kasutades selleks oma spetsialiste. . Lähenemisviisi iteratsioon on paljude ettevõtete jaoks võtmepunkt ühe või teise küpsusmudeli valikul, kuna see võimaldab kontrollida protsessi muudatuste elluviimise projekti ajastust.

TMMSW mudeli töötas välja Ilene Barnsteini juhitud spetsialistide rühm 1996. aastal SW-CMM mudeli laiendusena ja täiendusena. Selle eelised hõlmavad vastavust tarkvara testimisprotsesside küpsustasemete ja arendusprotsesside küpsustasemete vahel SW-CMM mudelis. Samuti saab TMMSW mudelit kasutada integreerituna CMMI, ISO-9001 soovituste ja ISO / IEC Std 12207-ga, mis võimaldavad teil saada ametliku sertifikaadi ning pideva auditite ja taassertifitseerimise vormis jälgimise abil jääda etteantud kvaliteeditasemele. . Ühest küljest võimaldab see TMMSW omadus teostada protsessimuudatusi tarkvara testimise osakonnas spetsiaalse projekti näol väiksemas mahus kui CMMI juurutamine kogu organisatsiooni ulatuses (mis säästab raha ja tagab läbipaistvuse); teisest küljest välistab selline lähenemine mitme mudeli kohandamise ja sidumise kulud. Rääkides omamoodi suhtest CMMI-ga, tahaksin rõhutada, et see mudel on IT-maailmas üsna laialt levinud ja pälvinud enda vastu kõrge usalduse, mistõttu on juhtkonnal oluliselt lihtsam protsessimuutuse maksumust motiveerida. projekt.

TMMSW mudel pakub parendusprotsessi lihtsamat planeerimist, juurutamist ja jälgimist. Mudeli puuduste hulgas võib märkida piiratud kirjandust: raamat Practical Software Testing: A Process-oriented Approach, mille avaldas Springer Professional Computing, on võib-olla ainus märkimisväärne töö sellel teemal.

TMMSW mudelil, nagu ka CMM-il, on viis küpsusastet.

1. tase – kaootiline. Tarkvara testimise protsess on oma olemuselt kaootiline, mis eristab enamikku alustavaid ettevõtteid. Testimisprotsessi ei määratleta spetsiaalse tegevusena ja see ei ole koodi silumisprotsessist eraldiseisev. Testimine toimub pärast koodi genereerimist ja süsteemi ehitamist või kokkupanemist. Testimise eesmärk on näidata, et rakendus töötab. Seda taset iseloomustab koolitamata personal, ressursside ja tööriistade nappus. Tarkvara antakse välja ilma testijate ametliku nõusolekuta. Tasemeesmärgid ei ole määratletud.

2. tase – arendusfaas. Tarkvara testimine on kodeerimisest eraldatud ja on järgmise etapina esile tõstetud. Testimise peamine eesmärk on näidata, et rakendus vastab nõuetele. On olemas põhilised lähenemisviisid ja testimistavad. Taseme eesmärgid: määratleda arendus- ja testimisülesanded, luua sobivad protseduurid, algatada testimise planeerimise protsess, fikseerida ja kirjeldada põhilisi testimisprotseduure ja tehnikaid.

3. tase – integreeritud. Testimisprotsess on integreeritud eluring tarkvara arendamine. Testi eesmärgid põhinevad nõuetel. Testimise korraldus on olemas ja testimine ise on ette nähtud ametialane tegevus. Taseme eesmärgid: eraldada testimine eraldi rühma ja määratleda tehniline koolitusprogramm, integreerida testimisprotsess arenduse elutsüklisse ning kontrollida ka testimisprotsessi ennast.

4. tase – juhtimine ja mõõtmine. Testimine on mõõdetav ja kontrollitav protsess. Protsessid on kriitilised kontrollid Projekti artefaktide (katseplaanid ja stsenaariumid, veateated, lõpliku versiooni olekuaruanded jne) (ülevaatus) viitavad testimistegevustele. Toodet testitakse vastavuse osas sellistele kvaliteedinäitajatele nagu töökindlus, kasutatavus, hooldatavus. Testskriptid salvestatakse, salvestatakse testihaldussüsteemi ja neid saab uuesti kasutada koos testandmete kogumitega. Avastatud defekte mitte ainult ei fikseerita, vaid neid analüüsitakse ka formaalsete kriteeriumide alusel: kriitilisus, defekti “kaal”, tähtsus, eluiga jne. Taseme eesmärgid: kriitilise ülevaatuse ja auditi programmide rakendamine organisatsiooni/üksuse tasandil samaväärselt mõõdetud testimisprogrammiga. Kvaliteedi hindamine on pooleli tarkvaratooted.

5. tase – protsesside optimeerimine, vigade vältimine ja kvaliteedikontroll. Testimine on määratletud ja kontrollitud protsess. Testimise maksumuse koos tulemusnäitajatega saab määrata. Testimine kui protsess võimaldab teha muudatusi, mis mõjutavad seda selgelt positiivselt. Rakendatakse ja kasutatakse vigade ennetamise ja kvaliteedikontrolli praktikaid. Testimise peamise lähenemisviisina kasutatakse automatiseeritud testimist. Testide kujundamine, saadud tulemuste analüüsimine, vigade kirjelduste, aga ka testimisega seotud mõõdikute töötlemine toimub vastavate tööriistade abil. Protsessi tavade taaskasutamise lähenemisviis on laialt levinud. Taseme eesmärgid: testimisprotsessi optimeerimine, vigade vältimine ja kvaliteedikontroll.

Kõik loetletud küpsustasemed, välja arvatud esimene, sisaldavad arengueesmärke, mis omakorda sisaldavad alaeesmärke, see tähendab, et need võimaldavad teil mitte ainult töötada tarkvaraarendusprotsesside kvaliteedijuhtimise kõrgetasemeliste ülesannetega, vaid ka sõnastada operatiivseid ülesandeid. ülesanded kõigile projektis osalejatele. Ülesande täitmise kontroll ja analüüs saavutatakse nn ATR-maatriksite (Activities - Tasks - Responsibilities) hõlmamisega - projekti tasemel artefaktid, millega projektis osalejad saavad töötada ilma eelneva ettevalmistuseta või pikaajalise koolituseta. ATR-maatriksid määratlevad tegevused ja ülesanded, mida tuleb mudeli juurutamise igas konkreetses etapis sooritada, ning toimivad nii „teekaardina“ kui ka omamoodi „kontrollnimekirjana“ muudatuste juurutamise protsessis. Mudeli enda pakutavate disainiartefaktide olemasolu on sageli mudeli kohandamise ja rakendamise projekti edukuse kriteerium. Igale ATR-maatriksi tegevusele on määratud kontrollülesanne, mida täidavad juhid, arendajad/testijad või kliendid/kasutajad. Eraldi paneme tähele, et kontroll muudatusprojekti üle ei ole antud projektis valitud inimeste grupile ega konkreetsele isikule, vaid see on üldine projektifunktsioon, millest on huvitatud kõikidel tasanditel projektis osalejad.

Kuni tarkvara testimisprotsesside viienda küpsusastmeni ei ole vaja spetsiaalseid tööriistu ega integreeritud lahendusi, vastupidiselt arendusprotsesside küpsusastmele, kus näiteks nõuete kogumiseks ja analüüsimiseks ning versioonikontrolliks on tööriistad. vajalik tingimus arendusprotsessi kui terviku teatud küpsusastme saavutamine. TMMSW mudeli viiendal tasemel on võimalik kasutada teatud statistilise koodi analüüsi tööriistu, mis võimaldavad lahendada selle küpsusastme ühe sihtülesande - vigade ennetamise, identifitseerides loogilisi vigu sisaldavaid koodilõike ressursi vabastamise operaatorite puudumisel või otsides. kasutamata muutujate või mälumassiivide jaoks. Kuid spetsiaalse tööriista kasutamine pole isegi sellel tasemel kohustuslik; näiteks lähenemine, kui ühe kodeerija kohta on kaks testijat, kellest üks on rohkema arendaja kõrge tase- hõivatud kriitiliste koodiülevaatuste ülesannetega, võimaldab teil lahendada ka vigade vältimise probleemi.

Spetsiifiliste metoodikate kasutamine või mõne valitud metoodika (RUP, MSF või Scrum) järgimine ei taga ka toote kvaliteedi saavutamist ega projekti edukust, kuna tarkvaraarenduse metoodika töötab ainult kindlat tüüpi projekti puhul. Sarnaselt ei anna tarkvara testimisprotsessi jaoks ükski metoodika ilma konkreetse projekti tingimustega kohandamiseta garanteeritud tulemust. Protsessi küpsusmudel on just teatud protsessikvaliteedi taseme saavutamise praktika, mis on rakenduse jaoks huvitav, mis kujutab endast eesmärkide ja nende saavutamise lähenemisviiside ülesehitust, mis võimaldab "sees" kasutada peaaegu suvalist arendusmetoodikat (õige kohandamisega) ja tööriistade komplekt. Mudel selgitab “mida ja kuidas” teha, aga mitte “mida ja mis järjekorras”.

Harjuta

Testimisprotsessi küpsusmudelite soovitusi praktikas rakendades ei näe ettevõte mitte ainult kogutud mõõdikute vormingus edusamme, vaid tunnetab ka reaalselt töörežiimi enda kvalitatiivseid muutusi. On mitmeid märke protsessimuutustest, mida tunnetavad nii juhtkond ja meeskonnaliikmed kui ka arendatava toote kliendid ja tarbijad.

Ajakontrollitud protsess teatud kvaliteeditasemega versioonide avaldamiseks. See ei räägi valmistatud toote ideaalsest kvaliteedist ega täielik puudumine defektid – me räägime nii projektimeeskonna kui ka testimismeeskonna usaldusest välja antud versiooni oleku vastu.

Projekti kõigi etappide korrapärasus ja prognoositav korratavus. Tarkvara testimisprotsesside esialgse küpsusastme tingimustes järgnevad testimistegevused töö viimase etapina ning sageli “kannatavad” piiratud aja ja ressursipuuduse tõttu, mis mõjutab otseselt välja antud versioonide stabiilsust ja nende kvaliteeti. Testimisprotsessi küpsusmudeli kõrgematele tasemetele üleminekuga integreeritakse testimistegevused üha enam tooteversioonide väljatöötamisse ja väljalaskmisse, mis mõjutab positiivselt vajalike ressursside ja aja jaotamist töö lõpetamiseks.

Sellise tarkvara arendamise ja väljalaske protsessi iseloomustava kvalitatiivse näitaja muutus, pärast toote versiooni avaldamist leitud defektide arvuna eksperimentaalses või isegi tootmistegevuses. See näitaja on juhtivtöötajate ja teenuste jaoks väga oluline. tehniline abi, mis võib kinnitada tarkvara kvaliteedi parandamise positiivset dünaamikat, viies läbi klientide või kasutajate registreeritud päringute kvantitatiivse ja kvalitatiivse analüüsi. Positiivsed punktid, on meie hinnangul seotud praktiliste täiustustega planeerimise ja testimise kontrolli staadiumis, kuna sageli puuduvad vead, mis on tingitud just ajapuudusest tehtud testimistööde planeerimiseks ja jälgimiseks.

Kirjandus

Terry Weatherill, testimise küpsuse mudelilabürindis. Tarkvaratestimise professionaalide ajakiri, 2001.

Thomas Staab, SW-TMM kasutamine testimisprotsessi täiustamiseks. Wind Ridge International.

Vjatšeslav Pankratov ([e-postiga kaitstud] ) - tegevdirektor QAExpert ettevõte (Kiiev, Ukraina).

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 arendusprotsesside 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 "kuidas see läheb" arendusele, kui arendajad lähevad iga projekti juurde kui saavutus. Teine vastab enam-vähem väljakujunenud protsessidele, kui on võimalik piisava 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 infosüsteemide loomiseks, tarnijate valimise protsessi ja mõne muu jaoks välja töötama spetsiaalseid küpsusmudeleid. Nende põhjal töötati välja integreeritud CMMI mudel (Capability Maturity Model Integration). Lisaks püüti CMMI-s üle saada selleks ajaks ilmnenud CMM-i puudujääkidest - protsesside formaalsete kirjelduste rolliga liialdamisest, kui teatud dokumentatsiooni olemasolu hinnati palju kõrgemalt kui lihtsalt väljakujunenud, kuid pole kirjeldatud protsessi. Siiski on CMMI keskendunud ka väga formaliseeritud protsessi kasutamisele.

Seega on CMM ja CMMI mudelite aluseks arendusprotsessi formaliseerimine. Need on suunatud arendajatele eeskirjades ja juhistes üksikasjalikult kirjeldatud protsessi elluviimisele, mis omakorda ei nõua asjakohaseks kontrolliks ja aruandluseks suure hulga projektidokumentide väljatöötamist.

CMM-i ja CMMI seos iteratiivse arenguga on kaudsem. Formaalselt ei esitanud kumbki konkreetseid nõudeid kose või iteratiivse lähenemise järgimiseks. Mõnede ekspertide sõnul ühildub CMM siiski rohkem kose lähenemisviisiga, samas kui CMMI võimaldab ka iteratiivset lähenemist.

Loomulikult on RUP korduv metoodika. Kuigi formaalselt pole RUP-is kuskil märgitud kõigi faaside kohustuslikku täitmist või mingit minimaalset iteratsioonide arvu, on kogu lähenemine keskendunud sellele, et neid on päris palju. Piiratud iteratsioonide arv ei võimalda teil RUP-i täielikult ära kasutada. Samal ajal saab RUP-i kasutada ka peaaegu kaskaadprojektides, mis sisaldavad tõesti vaid paari iteratsiooni: üks ehitusfaasis ja teine ​​ülekandefaasis. Muide, see on iteratsioonide arv, mida tegelikult jugaprojektides kasutatakse. Lõppude lõpuks testimine ja proovioperatsioon süsteemid hõlmavad paranduste tegemist, mis võivad hõlmata teatud analüüsi, disaini ja arendusega seotud tegevusi, st tegelikult on need veel üks läbimine kõigist arendusfaasidest.

RUP metoodika

Seoses metoodika formaalsusega pakub RUP kasutajale väga laia valikut võimalusi. Kui teete kõik tööd ja ülesanded, loote kõik artefaktid ja üpris formaalselt (ametliku retsensendiga, koos täieliku ülevaate koostamisega elektroonilise või paberdokumendi vormis jne) läbite kõik ülevaated, võib RUP pöörduda. olema äärmiselt formaalne ja 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 formaalsusega. Võimalik on nõuda iga dokumendi üksikasjalikku uurimist ja hoolikat täitmist, võrdselt hoolikalt koostatud ja vormistatud ülevaate andmist ning isegi vana tava järgi kinnitada iga selline ülevaade 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 valida arendusprotsessi vormistamise ja iteratsiooni astet laias valikus, sõltuvalt projektide ja arendusorganisatsiooni omadustest.

Ja miks see nii oluline on - arutame järgmises osas.

Tarkvara arendamise, tarnimise, juurutamise ja hoolduse ning süsteemiintegratsiooni valdkonnas tegutsevad organisatsioonid tunnevad üha enam, et nende konkurentsivõime põhineb kvaliteedil ja madalal kulul, valmistatavusel.

Selliste organisatsioonide juhid ei suuda alati kujundada strateegiat oma ettevõtte tegevuse tehnoloogia täiustamiseks ja arendamiseks; spetsialistide tööturul vajalik kvalifikatsioon ilmselgelt ei piisa. Samas tarkvaraarenduse ja -operatsiooni tehnoloogiliste protsesside täiustamise valdkonnas rahvusvaheline kogemus pikki aastaid oli ebapiisavalt üldistatud ja formaliseeritud. Alles 1990. aastate alguses kujundas Ameerika Tarkvaratehnoloogia Instituut (SEI) CMM-i organisatsioonide tehnoloogilise küpsuse mudeli (Capability Maturity Model), määrates kindlaks tehnoloogilise küpsuse taseme ja nende taseme. eristavad tunnused. Kümne aasta jooksul on CMM-i testitud paljudes organisatsioonides, selle tõhusust ja usaldusväärsust on kontrollinud tellijaorganisatsioonid, tarkvaramüüjad, kohandatud tarkvaraarenduse ettevõtted ja offshore-programmeerimine.

Tänapäeval on läänes arendusettevõttel praktiliselt suuri raskusi tellimuste saamisega, kui tal pole SMM-i sertifikaati. Tellijad nõuavad töövõtjalt valmistatavuse garantiisid, garantiisid, et töövõtja ei suuda pakkuda ebakvaliteetset teenust.

Ettevõtete tehnoloogilise küpsuse hinnangut saab kasutada:

tellija parimate tegijate valimisel (näiteks hankes);

· tarkvaraettevõtted hindama süsteemselt oma tehnoloogiliste protsesside seisu ja valima valdkonnad nende täiustamiseks;

· ettevõtted, kes otsustavad läbida atestatsiooni, et hinnata "katastroofi mõõtmeid", s.o. tema praegune olek;

audiitorid, et määrata kindlaks standardne sertifitseerimismenetlus ja viia läbi vajalikud hindamised;

ettevõtete ja teenusepakkujate ümberstruktureerimisega seotud konsultatsioonifirmad infotehnoloogiad ja sellega seotud teenused.

Organisatsiooni tehnoloogilise küpsuse kasvades muutuvad tarkvara loomise ja hooldamise protsessid standardsemaks ja järjepidevamaks. Ühtlasi võimaldab protsesside vormistamine standardiseerida nende elluviimise oodatavaid tulemusi ja tagada projektide elluviimise tulemuste prognoositavus.

Protsessi küpsus (tarkvaraprotsessi küpsus)- see on nende juhitavuse, kontrollitavuse ja tõhususe aste. Kasvav tehnoloogiline küpsus viitab protsesside vastupidavuse suurendamise potentsiaalile ja näitab tarkvara arendus- ja hooldusprotsesside kasutamise tõhususe ja järjepidevuse astet kogu organisatsioonis. Protsesside reaalne kasutamine on võimatu ilma nende dokumenteerimiseta ja organisatsiooni personali tähelepanu juhtimiseta, ilma nende rakendamise pideva jälgimise ja täiustamiseta. Hästi kavandatud protsesside võimalused on täielikult määratletud. Protsesside tehnoloogilise küpsuse suurendamine tähendab, et nende rakendamise tulemuste efektiivsus ja kvaliteet võivad pidevalt tõusta.

Tehnoloogilise küpsuse saavutanud organisatsioonides omandavad tarkvara loomise ja hooldamise protsessid standardi staatuse, fikseeritakse organisatsioonilised struktuurid ning määrata kindlaks tootmistaktika ja -strateegia. Nende seadusesse viimisega kaasneb vajadus rajada välja vajalik infrastruktuur ja luua vajalik ettevõtte tootmiskultuur, mis tagab äritegevuseks sobivate meetodite, toimingute ja protseduuride säilimise ka pärast seda, kui selle kõige loojad organisatsioonist lahkuvad.

CMM-mudel arendab välja organisatsiooni kvaliteedisüsteemi sätted, moodustades selle täiuslikkuse kriteeriumid - viis tehnoloogilise küpsuse taset, mida arendusorganisatsioon on põhimõtteliselt saavutatav. Kõrgeim – neljas ja viies tase – on tegelikult omane organisatsioonidele, kes on omandanud kollektiivse arendamise meetodid, milles tarkvara loomise ja hooldamise protsessid on terviklikult automatiseeritud ja tehnoloogiliselt toetatud.

Alates 1990. aastast on SEI USA valitsusasutuste ja toel seda mudelit pidevalt arendanud ja täiustanud, võttes arvesse kõiki uusimaid saavutusi tarkvara loomise ja hooldamise vallas.

SMM on metoodiline materjal, milles määratletakse tarkvara loomise ja hooldamise juhtimissüsteemi moodustamise reeglid ning meetodid tootmiskultuuri järkjärguliseks ja pidevaks täiustamiseks. CMM-i eesmärk on anda arendusorganisatsioonidele vajalikke juhiseid protsesside kvaliteedi parandamise strateegia valimiseks, analüüsides nende tehnoloogilist küpsuse astet ja toodete kvaliteeti enim mõjutavaid tegureid. Keskendudes väikesele hulgale kõige kriitilisematele toimingutele ning süstemaatiliselt parandades nende teostamise tõhusust ja kvaliteeti, saab organisatsioon seeläbi saavutada tarkvara loomise ja hoolduse kultuuri pideva pideva paranemise.

CMM on kirjeldav mudel selles mõttes, et see kirjeldab olulisi (või võtme) atribuute, mis määravad, millisel tehnoloogilise küpsuse tasemel organisatsioon on. See on normatiivne mudel selles mõttes, et metoodikate üksikasjalik kirjeldus määrab kindlaks organisatsiooni taseme, mis on vajalik erineva keerukuse ja kestusega projektide läbiviimiseks USA valitsusasutustega sõlmitud lepingute alusel. CMM ei ole ettekirjutus, see ei kirjuta ette, kuidas organisatsioon peaks arenema. CMM kirjeldab organisatsiooni tunnuseid iga tehnoloogilise küpsusastme jaoks, andmata juhiseid, kuidas tasemelt teisele liikuda. Organisatsioonil võib kuluda mitu aastat, et liikuda esimeselt tasemelt teisele, ja väga vähe aega, et liikuda järgmisele tasemele. Tarkvara loomise tehnoloogia täiustamise protsess kajastub strateegilised plaanid organisatsioon, selle struktuur, kasutatavad tehnoloogiad, üldine sotsiaalkultuur ja juhtimissüsteem.

Igal tasandil kehtestatakse nõuded, mille alusel saavutatakse protsesside olulisemate näitajate stabiliseerimine. Iga tehnoloogilise küpsusastme saavutamine on teatud arvu komponentide ilmumise tagajärg tarkvaraarenduse protsessidesse, mis omakorda toob kaasa nende tootlikkuse ja kvaliteedi tõusu. Joonisel fig. Joonis 1.7 näitab viit CMM-i tehnoloogilise küpsuse taset.

Riis. 1.7. Viis SMM-i tehnoloogilise küpsuse taset

Nooltel olevad pealdised määratlevad protsesside täiustamise funktsioonid tasemelt tasemele liikumisel.

Tasemeid teisest kuni viiendani saab iseloomustada operatsioonide kaudu, mille eesmärk on tarkvara loomise protsesside standardimine ja (või) moderniseerimine, ning toimingute kaudu, mis moodustavad selle loomise protsessid ise. Samal ajal on esimene tase justkui alus, vundament võrdlev analüüsülemised tasemed.

1. tasemel (esialgne) on tarkvara loomise ja hooldamise põhiprotsessid juhuslikud ja kaootilised. Projekti edu sõltub täielikult töötajate individuaalsetest pingutustest. Sellel tasemel ei ole organisatsioonil reeglina tarkvara loomiseks ja hooldamiseks vajalikku stabiilset keskkonda.

Projekti edukus sõltub sel juhul reeglina täielikult juhtkonna energiast ja kogemustest ning esinejate professionaalsest tasemest. Võib juhtuda, et energiline juht ületab projektiprotsessis kõik takistused ja jõuab välja tõeliselt elujõulise tarkvaratoote. Kuid pärast seda, kui selline juht oma ametikohalt lahkub, pole garantiid, et järgmine selline projekt õnnestub. Koos puudumisega nõutav tase projektijuhtimine, isegi arenenud tehnoloogia ei suuda olukorda päästa.

Esimese tasandi protsesse iseloomustab nende ettearvamatus, mis tuleneb asjaolust, et nende koosseis, eesmärk ja järjestus projekti elluviimise protsessis muutuvad juhuslikult sõltuvalt hetkeolukorrast. Seetõttu kulutatakse eraldatud vahendeid üle ja töögraafikud on häiritud. Koolitusvõimeline ja teadlikud spetsialistid organisatsioonides on edu peamine eeldus kõigil küpsusastmetel, kuid esimesel tasemel on see ainus võimalus saavutada vähemalt mingeid positiivseid tulemusi.

2. tasemel (kordatavate protsesside tase) pakuvad projektijuhtimisprotsessid pidevat kontrolli projekti maksumuse, ajakava ja täidetavate funktsioonide üle. Projekti distsipliin on selline, et on võimalik ennustada sarnaste tarkvaratoodete loomise projektide edukust.

Sellel tasemel planeerimine projekteerimistööd ja uute projektide juhtimine põhineb edukalt lõppenud sarnaste projektide kogemusel. Teise taseme põhijooneks on formaliseeritud ja dokumenteeritud efektiivsete projektijuhtimise protsesside olemasolu, mis võimaldab kasutada edukalt läbitud projektide positiivset kogemust. Tõhusad protsessid on need, mis on dokumenteeritud, mida tegelikult kasutatakse, mõõdetakse ja mida on võimalik täiendada. On oluline, et töötajad saaksid nende kasutamise koolitust.

Iga CMM-i taset, alates teisest, iseloomustab mitmete niinimetatud võtmeprotsessirühmade (KPA) olemasolu. CMM-i mudel sisaldab 18 sellist rühma, CMMI-mudeli uusim versioon sisaldab 20 rühma. 2. taseme CMM-i iseloomustab järgmiste protsesside olemasolu organisatsioonis (nende nimed vastavad CMMI-le):

nõuete haldamine;

Konfiguratsiooni juhtimine;

projekti planeerimine;

projekti jälgimine ja kontroll;

lepingute haldamine;

mõõtmine ja analüüs;

protsessi ja toote kvaliteedi tagamine.

Teise tasandi protsesse saab iseloomustada tellituks tänu sellele, et need on ette planeeritud ja nende elluviimine on rangelt kontrollitud, tänu millele saavutatakse projekti tulemuste prognoositavus. Projektide kasvades ja keerukamaks muutudes nihkub tähelepanu tehnilisi aspekte nende rakendamine organisatsioonilistes ja juhtimisaspektides. Protsesside elluviimine nõuab inimestelt tõhusamat ja sidusamat tööd, mis omakorda eeldab dokumenteeritud parimate praktikate uurimist, et tõsta professionaalset tipptaset.

3. tasemel (standardiseeritud protsesside tase) on tarkvaraarenduse protsessid dokumenteeritud, standarditud ja esindavad ühtset tehnoloogiline süsteem kohustuslik kõigile organisatsiooni osakondadele. Kõik projektid kasutavad testitud, heaks kiidetud ja standardi staatusesse tõstetud tarkvara loomiseks ja hooldamiseks ühtset tehnoloogiat.

Sellel tasemel lisatakse 2. taseme protsessidele järgmised protsessid:

nõuete spetsifikatsioon;

toote integreerimine;

kontrollimine;

sertifitseerimine;

organisatsiooni protsesside standardimine;

· haridus;

integreeritud projektijuhtimine;

· Riskide juhtimine;

Analüüs ja otsuste tegemine.

Protsesside kasutamise ja vajadusel kohandamise põhikriteerium sellel tasemel on aidata juhtkonda ja tehnilised spetsialistid projektide elluviimise tõhususe parandamisel. Sellel tasemel luuakse organisatsioonis spetsiaalne rühm, mis vastutab protsesside moodustavate toimingute koostamise eest - tarkvaratehnoloogia protsesside rühm (SEPG).

Iga projekti jaoks mõeldud ühe tehnoloogia põhjal saab selle iseärasusi arvesse võttes välja töötada oma protsessid. Selliseid protsesse CMM-is nimetatakse "projektile orienteeritud tarkvara arendusprotsessideks" (projekti määratletud tarkvaraprotsess).

Iga protsessi kirjeldus sisaldab selle teostamise tingimusi, sisendandmeid, täitmise standardeid ja protseduure, kontrollimehhanisme (näiteks ekspertide arvamused), väljundandmed ja lõpetamistingimused. Protsessi kirjeldus sisaldab ka teavet selle lõpuleviimiseks vajalike tööriistade kohta ja viidet selle täitmise eest vastutavale rollile.

4. taseme (hallatavate protsesside tase) põhieesmärk on hetkekontroll protsesside üle. Juhtkond peab tagama protsesside läbiviimise kindlaksmääratud kvaliteedi piires. Mõõdetud tulemustes võib esineda vältimatuid kadusid ja ajutisi tippe, mis nõuavad sekkumist, kuid üldiselt peab süsteem olema stabiilne.

4. tasemel lisatakse järgmised protsessid:

jõudluse ja tootlikkuse juhtimine;

Kvantitatiivne projektijuhtimine.

Sellel tasemel rakendatakse praktikas üksikasjalikku hindamist nii loomisprotsesside kui ka tarkvaratoote enda kvaliteedile. Sel juhul rakendatakse kvantitatiivseid hindamiskriteeriume.

Kogu organisatsiooni raames töötatakse välja ühtne programm tarkvara loomise produktiivsuse ja selle kvaliteedi kvantitatiivseks kontrollimiseks. Protsesside analüüsi hõlbustamiseks luuakse kõigi organisatsioonis läbiviidavate projektide jaoks ühtne tarkvara loomise ja hooldamise protsesside andmebaas. Arendatakse universaalseid meetodeid kvantifitseerimine protsesside tootlikkus ja nende rakendamise kvaliteet. See võimaldab kvantitatiivselt analüüsida ja hinnata tarkvara loomise ja hoolduse protsesse.

Neljanda tasandi protsesside tulemused muutuvad prognoositavaks, kuna need on mõõdetavad ja varieeruvad etteantud koguseliste piirangute piires. Sellel tasemel on võimalik protsesside ja lõpptoodete kindlaksmääratud kvaliteeti ette planeerida.

5. taseme (optimeeritud protsesside tase) põhieesmärk on tarkvara loomise ja hooldamise protsesside järjepidev täiustamine ja kaasajastamine. Tarkvaraarenduse tehnoloogia kavandatava moderniseerimise eesmärgil luuakse organisatsioonis spetsiaalne üksus, mille põhiülesanneteks on protsesside rakendamise andmete kogumine, nende analüüs, olemasolevate kaasajastamine ja uute protsesside loomine. , nende kinnitus pilootprojektid ja anda neile ettevõtte standardite staatus.

5. tasemel lisatakse järgmised protsessid:

tehnoloogiliste ja organisatsiooniliste uuenduste juurutamine;

põhjus-tagajärg analüüs ja probleemide lahendamine. Tarkvara loomise ja hooldamise protsesse iseloomustavad

järjepidevalt täiustatud, kuna organisatsioon teeb pidevaid jõupingutusi nende moderniseerimiseks. See täiustus laieneb nii kasutatavate protsesside lisavõimaluste tuvastamisele kui ka uute optimaalsete protsesside loomisele ja uute tehnoloogiate kasutamisele.

Innovatsioonid, mis võivad tuua suurimat kasu, on standarditud ja kohandatud tehnoloogilise süsteemiga kogu organisatsiooni ulatuses. Projekti elluviimisega seotud töötajad analüüsivad defekte ja selgitavad välja nende tekkimise põhjused. Tarkvaraarendusprotsesse hinnatakse, et vältida defekte viivate olukordade kordumist ning hindamise tulemusi arvestatakse järgnevates projektides.

Iga järgnev tase annab lisaks täielikuma ülevaate tarkvara loomise ja hooldamise protsessidest.

Esimesel tasemel on protsessid amorfsed (“mustad kastid”) ja nende nähtavus on väga piiratud. Algusest peale ei ole tegevuste koosseis ja eesmärk praktiliselt määratletud, mis tekitab olulisi raskusi projekti staatuse ja selle edenemise kindlaksmääramisel. Nõuded protsesside täitmisele on seatud kontrollimatult. Tarkvaraarendus juhtide (eriti nende, kes ise pole programmeerijad) silmis tundub kohati musta maagiana.

Teisel tasemel kontrollitakse kasutajate nõudmiste täitmist ja tarkvara loomist, kuna määratletakse projektijuhtimise protsesside alused. Tarkvara loomise protsessi võib vaadelda kui "mustade kastide" jada, mida saab juhtida üleminekupunktides ühest "kastist" teise - fikseeritud etapid. Isegi kui juht ei tea, mida “kasti sees” tehakse, on täpselt paika pandud, mis peaks olema protsessi tulemus, ning määratakse selle alguse ja lõpu kontrollpunktid. Seetõttu saab juhtkond tuvastada probleeme musta kasti suhtluspunktides ja neile õigeaegselt reageerida.

Kolmandal tasandil on määratletud "mustade kastide" sisemine struktuur, s.o. ülesanded, millest protsessid koosnevad. Sisemine struktuur esindab viisi, kuidas standardprotsesse organisatsioonis rakendatakse konkreetsetele projektidele. Juhtimislüli ja täitjad teavad oma rolle ja vastutust projektis vajalikul detailsusel. Juhtkond on eelnevalt ette valmistatud riskideks, mis võivad projekti elluviimisel tekkida. Kuna standardiseeritud ja dokumenteeritud protsessid muutuvad ülevaatamiseks "läbipaistvaks", saavad töötajad, kes ei ole projektiga otseselt seotud, õigeaegselt saada täpset teavet selle hetkeseisu kohta.

Neljandal tasemel on protsesside täitmine rangelt seotud tööriistadega, mis võimaldab määrata nende töömahukuse ja täitmise kvaliteedi kvantitatiivseid omadusi. Juhid, kellel on objektiivne kvantitatiivsete mõõtmiste alus, saavad võimaluse täpselt planeerida projekti etappe ja etappe, prognoosida projekti edenemist ning kiiresti ja adekvaatselt reageerida esilekerkivatele probleemidele. Projekti elluviimise protsessis etteantud tähtaegadest, maksumusest ja kvaliteedist tulenevate võimalike kõrvalekallete vähenemisega suureneb nende tulemuste prognoosimise võime pidevalt.

Viiendal tasandil tehakse toodete kvaliteedi parandamiseks ja selle loomise efektiivsuse tõstmiseks pidevalt ja süstemaatiliselt tööd tarkvara loomise uute täiustatud meetodite ja tehnoloogiate loomisel. Tähelepanu ei juhita mitte ainult juba kasutatud, vaid ka uutele tõhusamatele protsessidele ja tehnoloogiatele. Juhid saavad kvantifitseerida tarkvaraarenduse ja hooldustehnoloogia muudatuste mõju ja tõhusust.

Neljas ja viies tase on tarkvaratööstuses haruldased. Seega, kui maailmas jõudis kolmandale tasemele mitusada ettevõtet, siis viienda taseme firmasid oli 62 (SEI 2002. aasta andmetel) ja 72 neljandat. Mõned ei ole huvitatud oma avalikustamisest organisatsioonilised tehnoloogiad, teised teostavad sertifitseerimist lihtsalt kliendi survel.

SMM-i kõrgeima taseme saavutamiseks kulub kümme aastat või rohkem. Kuid isegi 3. tase võimaldab julgelt astuda rahvusvahelisele areenile. SMM-i kasutamiseks ei pea ettevõte otsima unikaalsete võimetega töötajaid, piisab, kui ta mõistab üldist ideed. CMM-i mudeli kirjelduses on üksikasjalikult täpsustatud, mida tuleb teha, et selle mudeli järgi areneda. Iga keskklassi juht on võimeline järgima CMM-i reguleeritud tegevusi.

Uusim versioon CMM 1.1 on peamiselt suunatud suurprojektide elluviimisega tegelevatele suurettevõtetele, kuid seda saavad kasutada ka kahe-kolmeliikmelised grupid või üksikud programmeerijad väikeste projektide (kuni kolm kuud) teostamiseks. Sellistel juhtudel võib CMM-i mudel mängida olulist rolli, kuna uute tellimuste laekumise määrab suuresti eelmiste projektide elluviimise kvaliteet. Väikesed rühmad jäävad 2. tasemega üsna rahule, kuna väikese projekti puhul pole paarinädalane tähtajast kõrvalekaldumine oluline.

Alates 2002. aastast on ametlikult levitatud spetsiaalset CMMI integratsiooniversiooni. See uus arendus SEI, mis hõlmab kõiki ettevõtte tegevuse aspekte: alates väljatöötamisest ja töövõtja valikust kuni koolituse, rakendamise ja hoolduseni. Lisaks on CMMI mudelit laiendatud süsteemitehnoloogia lähenemisviisidega. See mudel sisaldab CMM 2.0 versiooni kavandamisel tehtud arendusi (seda ei lõpetatud), mille peamised muudatused olid suunatud neljanda ja viienda taseme ettevõtete protsesside selgitamisele, mis on kõige olulisem suuremahuliste Ameerika projektide jaoks.

CMM-i mudel on üsna kaalukas ja oluline, kuid see ei tohiks olla ainus alus, mis määrab kogu tarkvaraarenduse protsessi. See oli mõeldud eelkõige ettevõtetele, kes arendavad tarkvara USA kaitseministeeriumi jaoks. Neid süsteeme iseloomustavad nende suured mõõtmed ja pikk kasutusiga, samuti riist- ja muude tarkvarasüsteemidega liidese keerukus. Selliste süsteemide loomisega tegelevad üsna suured programmeerijate meeskonnad, mis peavad vastama Kaitseministeeriumi väljatöötatud nõuetele ja standarditele.

SMM-i puudused on järgmised:

1. Mudel keskendub ainult projektijuhtimisele, mitte tarkvaratoote loomise protsessile. Mudel ei võta arvesse selliseid olulisi tegureid nagu teatud meetodite kasutamine, nagu prototüüpimine, formaalsed ja struktuursed meetodid, staatilise analüüsi tööriistad jne.

2. Mudelis puudub riski- ja otsustusanalüüs, mis takistab probleemide avastamist enne, kui need arendusprotsessi mõjutavad.

3. Mudeli ulatust ei ole määratletud, kuigi autorid tunnistavad, et see on universaalne ja sobib kõikidele organisatsioonidele. Samas ei tee autorid selget vahet organisatsioonide vahel, kes võivad oma tegevuses SMM-i rakendada või mitte. Väiksemad ettevõtted peavad seda mudelit liiga bürokraatlikuks. Vastuseks sellele kriitikale on väikeste organisatsioonide jaoks välja töötatud protsesside täiustamise strateegiad.

peamine eesmärk CMM-mudeli loomisel oli USA kaitseministeeriumi kavatsus hinnata tarkvaratootjate võimalusi. Peal Sel hetkel samas puuduvad selged nõuded arendusorganisatsioonide teatud arengutaseme saavutamiseks. Siiski on üldtunnustatud seisukoht, et kõrgele tasemele jõudnud organisatsioon võidab tõenäolisemalt tarkvara tarnimise hanke. CMM-i alternatiivina pakutakse välja tehnoloogilise küpsuse parandamise protsesside üldistatud klassifikatsioon, mis sobib enamiku organisatsioonide ja tarkvaraprojektide jaoks. Eristada saab mitmeid üldisi parendusprotsesside liike.

1. mitteametlik protsess. Puudub selgelt määratletud parendamise mudel. Seda saab edukalt kasutada eraldi arendusmeeskond

cov. Protsessi mitteametlikkus ei välista formaalseid tegevusi nagu konfiguratsioonihaldus, kuid tegevused ise ja nende seosed ei ole ette määratud.

2. Hallatud protsess. Omab ettevalmistatud mudelit, mis juhib parendusprotsessi. Mudel määratleb tegevused, nende ajakava ja nendevahelised seosed.

3. Metoodiliselt mõistlik protsess. Eeldatakse, et teatud meetodid on paika pandud (näiteks rakendatakse süstemaatiliselt objektorienteeritud disainimeetodeid). Seda tüüpi protsesside puhul on kasulikud protsesside kavandamise ja analüüsi tugitööriistad (CASE-tööriistad).

4. Otsese täiustamise protsess. Omab selgelt määratletud eesmärki täiustada tehnoloogilist protsessi, milleks see on olemas eraldi rida organisatsiooni eelarves ning määratleb uuenduste juurutamise normid ja protseduurid. Sellise protsessi osaks on parendusprotsessi kvantitatiivne analüüs.

Sellist klassifikatsiooni ei saa nimetada selgeks ja ammendavaks - mõned protsessid võivad kuuluda samaaegselt mitut tüüpi. Näiteks protsessi mitteametlikkus on arendusmeeskonna valik. Sama meeskond saab valida konkreetse arendusmetoodika, omades samas kõiki võimalusi protsessi otseseks parendamiseks. See protsess on salastatud mitteametlik, metoodiliselt usaldusväärne, otsene täiustamine.

Selle klassifikatsiooni vajadus tuleneb sellest, et see annab aluse tarkvaraarendustehnoloogia igakülgseks täiustamiseks ning võimaldab organisatsioonil valida erinevat tüüpi parendusprotsesse. Joonisel fig. 1.8 näitab erinevat tüüpi tarkvarasüsteemide seoseid ja nende arendamise protsesse.

Riis. 1.8. Parendusprotsesside rakendatavus

Arendatava toote tüübi teadmine loob vastavuse tarkvarasüsteemid ja parendusprotsessid, mis on näidatud joonisel fig. 1.8 kasulik protsessi täiustamise valimisel. Näiteks peate looma programmi, mis toetab tarkvara üleminekut ühelt arvutiplatvormilt teisele. Sellise programmi eluiga on üsna lühike, mistõttu selle väljatöötamine ei nõua standardeid ja eriline haldus parendamise protsessi, nagu pikaealiste süsteemide loomisel.

Palju tehnoloogilised protsessid neil on praegu CASE tugi, nii et neile saab helistada toetatud protsessid. Metoodiliselt usaldusväärseid protsesse toetavad analüüsi- ja disainivahendid. Tugivahendi tõhusus sõltub rakendatavast parendusprotsessist. Näiteks mitteametlikus protsessis standardsed vahendid tugi (prototüüpimistööriistad, kompilaatorid, silumisriistad, tekstitöötlusprogrammid jne). On ebatõenäoline, et mitteametlikes protsessides hakatakse pidevalt kasutama spetsiaalseid tugivahendeid.

SMM-mudel pole ainulaadne. Peaaegu iga suur ettevõte arendab oma tehnoloogiaid tarkvara loomiseks, mõnikord muutuvad need tehnoloogiad avalikult kättesaadavaks ja väga populaarseks. HMM-i mudeli laialdast populaarsust seostatakse sellega riigi toetus, kuid SMM-i tegelikku tõhusust kritiseerivad paljud juhtivad eksperdid. HMM-i üks peamisi puudusi on seotud tarbetult jäiga nõudega mitte kalduda kõrvale selle mudeli põhimõtetest, isegi kui terve mõistus viitab vastupidisele. Sellised väited absoluutse tõe omamise kohta ei saa äratada kahtlust, seetõttu on väikeste ja keskmise suurusega ettevõtete seas populaarsemad lähenemised, mis jätavad individuaalsele ja kollektiivsele loovusele palju rohkem vabadust. Allpool vaadeldav SPMN-tehnika asub vahepealses asendis jäiga, "raske" vahel, mis on efektiivne suured organisatsioonid lahendused nagu SMM ja kõige paindlikumad tehnoloogiad. Ta ilmub parim variant ettevõtetele, kes ühelt poolt soovivad oma tegevust sujuvamaks muuta juhtimistegevus, ja teisalt plaanivad nad tulevikus siseneda rahvusvahelisele tasemele, kus SMM-i sertifikaat on väga soovitav.

1982. aastal moodustas USA kaitseministeerium komisjoni, mille peamiseks ülesandeks oli uurida probleeme, mis tekivad tarkvaratoodete arendamisel osakonna organisatsioonides. Komisjoni tegevuse tulemusena loodi 1984. aasta detsembris Pittsburghis Carnegie Melloni ülikoolis Tarkvaratehnoloogia Instituut (SEI).

1987 SEI avaldab: Lühike kirjeldus CMM-i struktuurid; tarkvara arendusprotsesside hindamise meetodid; tarkvara tootmisprotsesside küpsuse hindamise meetodid; küsimustik protsesside küpsusastme tuvastamiseks (sõltumatute, Siseauditi ja välisaudit).

1991. aasta CMM v1.0 väljalase.

1992. aasta CMM v1.1 väljalase.

1997 CMM-i järgmise (täiustatud) versiooni väljalaskmine.

CMM-i metoodika töötati välja ja arendati USA-s vahendina parimate tarkvaramüüjate valimiseks riigitellimuste täitmiseks. Selleks tuli luua kriteeriumid arendajaettevõtte põhiprotsesside küpsuse hindamiseks ja määrata nende edasiseks täiustamiseks vajalike toimingute kogum. Selle tulemusena osutus metoodika äärmiselt kasulikuks enamiku ettevõtete jaoks, kes soovivad kvalitatiivselt parandada olemasolevad protsessid tarkvaratööriistade projekteerimine, arendamine, testimine ja nende haldamise taandamine ühtses standardis kirjeldatud arusaadavate ja hõlpsasti rakendatavate algoritmide ja tehnoloogiateni.

SMM-ist on de facto saanud just selline standard. Selle rakendus võimaldab viia tarkvaraarenduse tööstuslikule alusele, tõsta võtmeprotsesside juhitavust ja tootmiskultuuri üldiselt, garanteerides kvaliteetse töö ja projekti õigeaegse teostamise. CMM-i loomise aluseks oli põhiseisukoht, et kvaliteetse tarkvara arendusprotsessi "kriisi" põhimõtteline probleem ei ole uute arendusmeetodite ja -vahendite puudumine, vaid ettevõtte suutmatus organiseerida ja juhtida tehnoloogilisi protsesse.

Hinnata ettevõtte valmisolekut kvaliteedi arendamiseks tarkvara HMM tutvustab põhikontseptsiooni organisatsiooni küpsus(Küpsus). ebaküps Organisatsiooniks loetakse:

• puudub pikaajaline ja projekti planeerimine;
• tarkvara arendusprotsess ja selle põhikomponendid on tuvastamata, protsessi elluviimine sõltub hetketingimustest, konkreetsetest juhtidest ja teostajatest;
• meetodid ja protseduurid ei ole standarditud ega dokumenteeritud;
• tulemus ei ole ette määratud reaalsete kriteeriumidega, mis tulenevad kavandatud näitajatest, standardtehnoloogiate kasutamisest ja väljatöötatud mõõdikutest;
• lahenduse väljatöötamise protsess toimub spontaanselt, kunsti piiril.

Sel juhul on suur tõenäosus ootamatuteks probleemideks, eelarve ületamiseks või projekti tähtaegadest mitte kinnipidamiseks. Sellises ettevõttes juhid ja arendajad reeglina protsesse ei juhi – nad on sunnitud tegelema jooksvate ja spontaanselt tekkivate probleemide lahendamisega. Pange tähele, et sisse see etapp areng on enamik Venemaa ettevõtteid.

Põhijooned küps organisatsioonid:

• ettevõttel on täpselt määratletud ja dokumenteeritud protseduurid nõuete juhtimiseks, planeerimiseks projekti tegevused, konfiguratsioonihaldus, tarkvaratoodete loomine ja testimine, tõestatud projektijuhtimismehhanismid;
• neid protseduure täiustatakse ja täiustatakse pidevalt;
• töö aja, keerukuse ja maksumuse hinnangud põhinevad kogutud kogemustel, välja töötatud mõõdikutel ja kvantitatiivsetel näitajatel, mis muudab need üsna täpseks;
• värskendatud väliseid ja loodud sisestandardeid võtmeprotsessid ja protseduurid;
• on kõigile kohustuslikud reeglid metoodilise programmi ja kasutajadokumentatsiooni koostamisel;
• tehnoloogiad on projektiti pisut erinevad, tuginedes stabiilsetele ja tõestatud lähenemisviisidele ja metoodikatele;
• kasutatakse maksimaalselt ära varasemates projektides, programmimoodulites, tarkvarateegides omandatud korraldus- ja tootmiskogemust;
• aktiivselt katsetatakse ja juurutatakse uusi tehnoloogiaid, hinnatakse nende tõhusust.

SMM määrab viis taset ettevõtte tehnoloogiline küpsus, mille järgi saavad kliendid hinnata potentsiaalseid lepingutaotlejaid ning arendajad tarkvaraarendusprotsesse täiustada.

Iga tase, välja arvatud esimene, koosneb mitmest tasemest protsessi põhivaldkonnad(Põhiprotsess