Ohjelmistokehitys: laatustandardit. Capability Maturity Model (CMM) Yrityksen laatujärjestelmän ja ohjelmiston elinkaaren perusasiakirjat

Valtion ja kansainvälisten standardien lisäksi kehitysprosessin sertifioinnissa on useita lähestymistapoja. Tunnetuimmat niistä Venäjällä ovat ilmeisesti CMM ja CMMI.

CMM (Capability Maturity Model) on ohjelmistojen luontiprosessien kypsyysmalli, joka on suunniteltu arvioimaan tietyn yrityksen kehitysprosessin kypsyysastetta. Tämän mallin mukaan kehitysprosessin kypsyysasteita on viisi. Ensimmäinen taso vastaa kehitystä "sellaisena kuin se tapahtuu", kun kehittäjät lähestyvät jokaista projektia kuin se olisi saavutus. Toinen vastaa enemmän tai vähemmän vakiintuneita prosesseja, jolloin voit luottaa kohtuullisella varmuudella projektin myönteiseen lopputulokseen. Kolmas vastaa kehitettyjen ja hyvin kuvattujen prosessien läsnäoloa, joita käytetään kehityksessä, ja neljäs vastaa aktiivista mittareiden käyttöä johtamisprosessissa tavoitteiden asettamiseen ja niiden saavuttamisen seuraamiseen. Lopuksi viides taso viittaa yrityksen kykyyn optimoida prosessi tarpeen mukaan.

CMM- ja CMMI-vaatimukset

CMM:n tulon jälkeen alettiin kehittää erikoistuneita kypsyysmalleja tietojärjestelmien luomiseen, toimittajan valintaprosessiin ja joihinkin muihin. Niiden pohjalta kehitettiin integroitu CMMI-malli (Capability Maturity Model Integration). Lisäksi CMMI yritti voittaa CMM:n tuolloin ilmenneet puutteet - prosessien muodollisten kuvausten roolin liioittelua, kun tietyn dokumentaation olemassaolo arvioitiin paljon korkeammalle kuin pelkkä vakiintunut, mutta kuvaamaton. käsitellä asiaa. CMMI keskittyy kuitenkin myös hyvin formalisoidun prosessin käyttöön.

Näin ollen CMM- ja CMMI-mallien perustana on kehitysprosessin formalisointi. Ne pyrkivät kehittäjiin toteuttamaan määräyksissä ja ohjeissa yksityiskohtaisesti kuvatun prosessin, joka puolestaan ​​edellyttää laajan projektidokumentaation kehittämistä asianmukaista valvontaa ja raportointia varten.

CMM:n ja CMMI:n yhteys iteratiiviseen kehitykseen on epäsuorampi. Muodollisesti kumpikaan ei esitä erityisiä vaatimuksia vesiputouksen tai iteratiivisen lähestymistavan noudattamiselle. Joidenkin asiantuntijoiden mukaan CMM on kuitenkin yhteensopivampi vesiputouslähestymistavan kanssa, kun taas CMMI mahdollistaa myös iteratiivisen lähestymistavan käytön.

Tietenkin RUP on iteratiivinen menetelmä. Vaikka pakollista vaatimusta kaikkien vaiheiden suorittamisesta tai tietyn vähimmäismäärän iteraatioita ei ole virallisesti ilmoitettu missään RUP:ssa, on koko lähestymistapa keskittynyt siihen, että niitä on melko paljon. Iteraatioiden rajallinen määrä ei salli RUP:n kaikkien etujen täysimääräistä hyödyntämistä. Samalla RUP:ia voidaan käyttää myös käytännössä vesiputousprojekteissa, joissa itse asiassa on vain pari iteraatiota: yksi "Build"-vaiheessa ja toinen "Transfer"-vaiheessa. Muuten, vesiputousprojekteissa tätä iteraatioiden määrää todella käytetään. Järjestelmän testaamiseen ja koekäyttöön kuuluukin sitten korjausten tekeminen, mikä voi sisältää tiettyjä analyysiin, suunnitteluun ja kehittämiseen liittyviä toimia, eli itse asiassa ne ovat toinen läpikulku kaikissa kehitysvaiheissa.

RUP-metodologia

Mitä tulee metodologian muodollisuuteen, RUP tarjoaa käyttäjälle erittäin laajan valikoiman mahdollisuuksia. Jos teet kaiken työn ja tehtävät, luot kaikki artefaktit ja suoritat kaikki arvioinnit melko muodollisesti (virallisen arvioijan kanssa, valmistelemalla täydellistä arviota sähköisen tai paperillisen asiakirjan muodossa jne.), RUP voi osoittautua erittäin muodolliseksi, raskaaksi menetelmäksi. Samaan aikaan RUP antaa sinun kehittää vain niitä artefakteja ja suorittaa vain ne työt ja tehtävät, jotka ovat tarpeen tietyssä projektissa. Ja valitut artefaktit voidaan suorittaa ja tarkastella mielivaltaisilla muodollisuuksilla. Voit vaatia jokaisen asiakirjan yksityiskohtaista käsittelyä ja huolellista toteutusta, yhtä huolellisesti laaditun ja toteutetun katsauksen toimittamista ja jopa vanhan käytännön mukaisesti jokaisen sellaisen katsauksen hyväksymistä yrityksen tieteelliseltä ja tekniseltä neuvostolta. Tai voit rajoittua sähköpostiin tai luonnokseen paperilla. Lisäksi on aina yksi mahdollisuus: muodostaa dokumentti päässäsi, eli pohtia asiaa ja tehdä rakentava päätös. Ja jos tämä päätös koskee vain sinua, rajoita itsesi esimerkiksi ohjelmakoodin kommenttiin.

Näin ollen RUP on iteratiivinen metodologia, jossa on erittäin laaja valikoima mahdollisia ratkaisuja kehitysprosessin formalisoinnissa.

Tehdään yhteenveto artikkelin toisesta osasta. RUP, toisin kuin useimmat muut menetelmät, antaa sinun valita laajasti kehitysprosessin formalisaatio- ja iteratiivisuuden asteen projektin ja kehittyvän organisaation ominaisuuksien mukaan.

Keskustelemme seuraavassa osassa, miksi tämä on niin tärkeää.

V. Iljin.

TopSBI Companyn laatupalvelun johtaja

"Jos teet jotain

väärin - ei tarvetta
odottaa oikeaa tulosta."

Kiinan kansan viisautta

Kattava ratkaisu ohjelmistojen laadunvarmistusongelmiin sisältää yhden tai toisen laadunhallintajärjestelmän kehittämisen ja käyttöönoton (Quality Management System - QMS). Maailmankäytännössä ISO 9000 -sarjan kansainvälisten standardien vaatimuksiin perustuva järjestelmä on levinnyt laajimmalle, koska se määrittelee yleisimmät vaatimukset, mukaan lukien ohjelmistojärjestelmien vaatimukset, ja siten yleisesti ottaen ennalta prosessien kypsyys, joka on tarpeen monien IT-alan mallien ja standardien noudattamiseksi .

Mutta kysymykseen siitä, takaavatko laatujärjestelmän toteuttaminen ja onnistunut sertifiointi laadukkaan tuotteen julkaisun, on vastattava rehellisesti - "ei".

Vaikka Gartner Group korostaa, että ISO 9000 on "hyvä idea", se suosittelee, että ISO 9001 -sertifiointia pidettäisiin vain lähtökohtana matkalla laatuun (1).

Se muodostaa laatujärjestelmän "rungon", ja tämän järjestelmän täyttäminen "lihaksilla" (ammattimainen sisältö, joka perustuu erityisiin alan standardeihin ja menetelmiin, kuten CMM) voi varmistaa markkinoiden kasvavia vaatimuksia vastaavan laatutason.

Yllä olevaan liittyen niin metodologisesta kuin käytännön näkökulmasta monet laadunhallinnan asiantuntijat pitävät IT-yritysten kehittämisstrategian rakentamista järkevänä seuraavasti:

Ensin kehitetään ja toteutetaan laadunhallintajärjestelmä ISO 9001:2000 -mallin mukaisesti. (Loppujen lopuksi useimmat yritykset, jotka ovat nyt SW-CMM:n 4. ja 5. tasolla, saivat ensin prosessinsa ISO-mallin mukaisiksi. Kuten käytäntö osoittaa, tämä on paras vaihtoehto QMS-kehityksen hallinnassa ja riskien vähentäminen).

Ja vasta sitten alkaa kehittää ja toteuttaa SW-CMM-mallin ja sitten tarvittaessa CMMI-mallin keskeisiä prosesseja.

Ymmärtääksemme, kuinka oikein tämä todella on, verrataan näitä malleja.

1. Hakijoiden arviointi.

Katsotaanpa lyhyesti suosituimpia standardeja, joita IT-yritys voi käyttää liiketoimintaprosessiensa optimointiin.

ISO 9001. Suosituin, ja erityisesti Euroopassa, on ISO 9001 (2)

Samanaikaisesti, järjestelmällisesti, täysin monimutkaisten järjestelmien rakentamisen kurinalaisuuden mukaisesti, ISO 9001 -standardi mahdollistaa toisaalta organisaatiojärjestelmän rakentamisen "ylhäältä alas": yrityksen tavoitteista ja sen politiikoista. - organisaatiorakenteeseen ja liiketoimintaprosessien muodostukseen, ja toisaalta - organisaatiojärjestelmän iteratiiviseen kehittämiseen mittaus- ja parannusmekanismeja käyttäen.

Yksinkertaisesti sanottuna ”laatu” on ISO 9000 -standardisarjan mukaan tilanne, jossa kuluttajat saavat valmistajalta tuotteita, jotka vastaavat heidän suoria vaatimuksiaan ja piileviä odotuksiaan. Siksi laadunhallintaan kuuluu ISO 9000:n mukainen ns. "prosessilähestymistapa", kun mallinnetaan ja toteutetaan optimaalisin "prosessimuunnosten" ketju, jolla varmistetaan, että valmistaja havaitsee kuluttajien tarpeet ja sisällytetään mihin tahansa tuotteeseen ilman vääristymiä.

Monet ohjelmistokehitysorganisaatiot käyttävät menestyksekkäästi tätä tunnettua ISO 9000 -standardisarjaa. Tämän sarjan standardien uusi versio julkaistiin vuonna 2000 ja sisältää jo CMM:stä lainattuja käsitteitä kuten prosessilähestymistapa, analyysi ja mittaus, prosessin parantaminen. malli ja aiemmat puuttuvat aiemmista ISO 9000 versioista. On kuitenkin huomattava, että tämän sarjan standardit ovat universaaleja - ne eivät ole keskittyneet mihinkään tiettyyn toimialaan, eivät ota huomioon IT-alan erityispiirteitä ja tässä Tietenkin, spesifikaatioasteen suhteen, ovat huomattavasti huonompia kuin CMM. Lisäksi ISO 9000 ei tarkoita minkäänlaista vaatimustenmukaisuuden asteittaista (tasoa) ja siten vaikeuttaa tietyn organisaation "todellisten" kykyjen määrittämistä ja vastaavasti tapoja kehittää niitä edelleen.

CMM(Capability Maturity Model) on Carnegie Mellon Universityn (USA) Software Engineering Instituten kehittämä malli, joka kuvaa yritysten ohjelmistokehitysprosessien kypsyysmallia (3). Tämän mallin puitteissa jokaiselle yritykselle voidaan verrata tiettyä tasoa (yksi viidestä mahdollisesta), mikä osoittaa ohjelmistokehitysprosessin saavutetun laadun. Koska nämä standardit on kehitetty ensisijaisesti virtaviivaistamaan urakoitsijoiden valintaa Yhdysvaltain puolustusministeriölle, niissä kiinnitetään erityistä huomiota ohjelmistoprojektien hallintaprosesseihin, kun taas kehityksen teknisiä näkökohtia käsitellään vähemmän.

SW-CMM v.1.1 (Capability Maturity Model for Software) sisältää 316 avainkäytäntöä. Keskeiset käytännöt ovat sitä, mitä tulee ottaa käyttöön yrityksessä ja mihin prosessiarviointia tekevä tiimi kiinnittää huomiota. Ne yhdistetään alueiksi - Key Practices Areas (KPA) - nämä ovat jo joukko toisiinsa liittyviä prosesseja, jotka yhdessä suoritettuina johtavat tiettyjen tavoitteiden saavuttamiseen.

CMMI(Capability Maturity Model Integration) - CMM-mallin jatkokehitys. CMMI-SE/SW-versiossa 1.02 (CMMI for Systems Engineering/Software Engineering), joka soveltuu ehkä parhaiten ohjelmistojärjestelmien kehittäjille, Key Practices -toimien määrä on jo 417.

Avainkäytäntöjen lisääntyminen liittyy juuri CMMI:n kehittämisen tarkoitukseen - mallin pitäisi auttaa välttämään eri teollisuuden CMM-mallien käyttöön liittyviä ongelmia.

(Vuodesta 1991 lähtien CMM-malleja on kehitetty erilaisiin sovelluksiin, joista merkittävimmät ovat:

Ohjelmistokehitysprosessin kypsyysmalli (Capability Maturity Model for Software - SW-CMM)
- prosessin kypsyysmalli järjestelmän uudelleensuunnittelua varten (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- Integroitujen tuotekehitysprosessien kypsyysmalli Integrated Product Development Capability Maturity Model - IPD-CMM)

Näiden mallien pohjalta rakennettiin CMMI. Se on imenyt näiden mallien parhaat puolet ja poistanut monien mallien olemassaolon aiheuttaman epäselvyyden joidenkin käsitteiden tulkinnassa - siksi keskeisten käytäntöjen määrä on lisääntynyt merkittävästi).

On selvää, että tämä on jo osoittautunut huomattavasti "raskaammaksi" malliksi - katso. Riisi. 1, jota ei myöskään ole vielä riittävästi testattu käytännössä (se julkaistiin vasta vuonna 2002). Tältä osin mallia toteutettaessa on mielestäni mahdollisia suuria riskejä, jotka liittyvät sekä ohjelmistokehityksen nopeuden perusteettomiin menetyksiin että samanaikaisesti toteutetun KPA:n toiminnan (ja tuen) työvoimakustannusten yksiselitteiseen nousuun. - katso. Kuva 1. Kolmessa eri IT-yrityksessä QMS:n jo rakentaneena ammattilaisena minusta näyttää siltä, ​​että CMMI-mallissa tasapaino tarpeellisen ja riittävän välillä on selvästi järkkynyt - IT-yrityksen henkilöstö (ja tämä on yleensä enimmäkseen "kooditaiteilijoita") se yksinkertaisesti "ei hyväksy" niin monia valvottuja määräyksiä (tässä on erittäin suuri riski rakentaa "Potemkin-kylä"!)

Riisi. 1 KPA-koostumuksen vertailu CMM- ja CMMI-malleissa.

Lisäksi CMMI:n arviointi tulee olemaan huomattavasti kalliimpaa, koska se on hyväksytty SEI Pääarvioija" Niitä on edelleen hyvin vähän, ja nämä palvelut ovat paljon kalliimpia kuin CMM-mallin noudattamista arvioitaessa.

Lisäksi monet ulkomaiset laadunhallinnan asiantuntijat (jonka mielipiteestä olen tällä hetkellä täysin samaa mieltä) ovat melko skeptisiä CMMI:n suhteen sen hyödyllisyyden kannalta pienissä ja keskisuurissa organisaatioissa (tällaiset organisaatiot ovat tyypillisiä Venäjälle). ). On jopa esitetty mielipide, että jonkin ajan kuluttua SEI:n on joko julkaistava mukautettu SW-CMM v.2 tai ryhdyttävä vastaaviin toimiin. Nuo. Jos markkinat eivät hyväksy mallia ja tällaiset edellytykset ovat jo olemassa tätä artikkelia kirjoitettaessa, SEI:n on mukauduttava markkinoiden vaatimuksiin.

Edellä mainitun yhteydessä näyttää tarkoituksenmukaiselta analysoida jo mainittu tarpeellisen ja riittävän tasapaino kaikissa näissä päälaadunhallintamalleissa.

Suoritetaan se seuraavissa koordinaateissa (katso. Riisi. 2) :

kehitysprosessien säätelyaste - merkitään tämä käsite - R.P.,

suunniteltujen tulosten saavuttamisen todennäköisyys - merkitään tämä käsite - PQ.

Kuvassa Kuva 2 esittää asiantuntija-arvion sääntelyn asteen ja suunniteltujen tulosten saavuttamisen todennäköisyyden välisestä tasapainosta, jonka tekijä on suorittanut näiden mallien vaatimusten sisällyttämisen käytännön tuloksiin mallien kehittämis- ja toteutusprosesseihin. ohjelmistot (ohjelmistot).

Matemaattisesti derivaatan suuruus on: F(Q) = dPQ\dRQ(tehokkuuden kasvu laadun saavuttamisessa dPQ vaatimusten täyttämisen tukemiseen käytetty työaika lisääntyy dRQ), pienenee vastaavasti seuraavassa järjestyksessä : ISO 9000, CMM, CMMI.

Siksi kuva Fig. 2 selittää selkeästi ja yksinkertaisesti:

ISO 9000 -mallin suosio,

menetelmän oikeellisuus: ensin ISO ja vasta sitten tarvittaessa CMM,

jonkin verran skeptisyyttä CMMI-mallin tehokkuudesta.

Riisi. 2 Analyysi sääntelyn asteen ja suunniteltujen tulosten saavuttamisen todennäköisyyden välisestä tasapainosta (tekijän asiantuntija-arvion mukaan)

Tarkastellaan nyt toista IT-yrityksissä laajalti käytössä olevaa ohjetta, joka mainitaan alla analysoitaessa QMS-toteutuskäytäntöjä.

Tämä PMBoK(Guide to the Project Management Body of Knowledge) on Project Management Institute -projekti, joka yhdistää projektinhallinnan alalta kertynyttä tietoa. Asiakirjan viimeisin versio julkaistiin vuonna 2000 ja sai samalla American Standards Institute ANSI:n standardin statuksen (vaikka ANSI- ja IEEE-standardeja pidetään muodollisesti amerikkalaisina, suurin osa niistä on de facto kansainvälisiä). Tärkeä PMBOK:n ominaisuus on, että se käsittelee projektinhallintaa yleisessä mielessä, viittaamatta tiettyihin aihealueisiin, kuten tietotekniikkaan, ja siksi sitä ei voida käyttää itsenäisesti - alla tarkastellaan vaikutusta, jonka tämä antaa, kun sitä käytetään yhdessä ISO 9000:n kanssa.

Pohditaan nyt, kuinka jo suositun ISO 9001:2000 -standardin vaatimukset liittyvät yhä suositummaksi tulleen CMM-mallin yleisiin ominaisuuksiin {3}- cm. Riisi. 3.

Riisi. 3. CMM:n yleisten ominaisuuksien ja ISO 9001:2000 elementtien välinen vastaavuus

Kuten edellä mainittiin, jokaiselle HMM-tasolle on tunnusomaista joukko avainprosessialueet - KPA (Key Process Areas) - cm. Kuva 3. Saavuttaa kaikki tavoitteet sisällä KPA Tietylle tasolle SMM määrittää organisaation tämän tason noudattamisen. Jos vähintään yksi tavoite on vähintään yksi KPA Jos CMM-tasoa ei saavuteta, organisaatio ei voi täyttää tätä CMM-tasoa. KPA voidaan jakaa kolmeen kategoriaan: johtajat , organisatorinen Ja tarjoamalla (cm. Riisi. 4).

CMM ei määrittele kaikkia ohjelmistokehityksen kannalta tärkeitä prosesseja; se korostaa vain ne, jotka ovat välttämättömiä SMM-tason saavuttamiseksi, ja ne ovat mukana KPA. Jokainen KPA on jaettu 5 yhteiseen ominaisuuteen (Yleiset ominaisuudet): Suoritussitoumus (Kommentti suoritukseen); Suorituskyky; Suoritetut toiminnot; Mittaus ja analyysi; Toteutuksen tarkistaminen

Yleinen omaisuus" Suoritettavat toimet" kuvaa toimenpiteitä, jotka on suoritettava tavoitteiden saavuttamiseksi KPA, loput neljä yleistä ominaisuutta kuvaavat muodollisia tekijöitä, jotka tekevät prosessista osan organisaatiokulttuuria. Kaiken täydellinen toteutus tärkeimmät käytännöt kaikista yhteisistä ominaisuuksista varmistaa tavoitteiden saavuttamisen KPA. Keskeiset käytännöt kuvaavat, millainen työnkulusta (tai prosessielementistä tai infrastruktuurin osasta) tulee tulla, mutta eivät määrittele saavutusmenetelmää (tiettyjä teknologioita tai tekniikoita), vaikka joissakin käytännöissä annetaan yleisiä suosituksia. Eri olosuhteissa sama tulos voidaan saavuttaa eri tavoin. Nämä ovat pikemminkin yleisiä toimintaperiaatteita kuin erityisiä toimia.

Yhteisten ominaisuuksien johdonmukainen käyttöönotto toteuttaa itse asiassa liiketoimintaprosessien parantamisen syklin (Business-process Improvement - BPI-cm. Riisi. 5.), eli liiketoimintaprosessien jatkuva parantaminen (BP).

Riisi. 5. Liiketoimintaprosessien jatkuvan parantamisen sykli CMM-mallin ja ISO 9000:2000 mukaisesti.

Halu saada vaatimustenmukaisuustodistus mahdollisimman lyhyessä ajassa pakottaa konsulttiyritykset ja laadunhallinnan asiantuntijat käyttämään kaikkien lueteltujen korkean tason mallien joustavuutta ja vaatimuskehystä omiin "itsekkäisiin" tarkoituksiinsa.
Tämän tapahtumien pakottamisen seurauksena esimerkiksi ISO 9000:2000 -sertifikaatin saaneelle organisaatiolle on määritelty vain vähimmäisvaatimukset ISO 9001:n mukaisia ​​prosesseja, ei kaikkia prosesseja, joita yritys vaatii toimivat tehokkaasti - katso. Riisi. 2. Lisäksi prosessien yksityiskohtaisuus ei välttämättä riitä ymmärtämään selkeästi, mitä prosessien sisällä tapahtuu ja kuka on vastuussa mistäkin prosessin tehtävistä.
Parhaimmillaan vain muutama testiprojekti on käynyt läpi uudet menettelyt, ja jonkin ajan kuluttua niiden säätöjen ja lisäysten tarve tulee selväksi. Usein heti QMS-sertifioinnin jälkeen prosessit unohdetaan seuraavaan valvonta-auditointiin asti ja unohdetaan käytetyt taloudelliset resurssit ja työntekijöiden innostus.
Itse asiassa riippumattomana tilintarkastajana toimiessa on erittäin vaikeaa todistaa, että hyväksytty prosessin yksityiskohtien taso ei selvästikään riitä yrityksen laadunhallintajärjestelmän tehokkaaseen toimintaan. Mutta päinvastaista todistaminen on äärimmäisen vaikeaa ISO 9000 -auditointiin varatussa ajassa (tätä voidaan käyttää erittäin menestyksekkäästi auditoijaa vastaan). Käytäntö osoittaa, että tehokkaita edes 3. kypsyystason prosesseja (sekä ISO 9000:aan perustuvia prosesseja) on mahdotonta rakentaa nopeasti.
Tämän saavuttamiseksi ei riitä, että kuvataan vain prosessit ottaen huomioon valitun mallin vaatimukset. Suurin vaikeus on, että se on välttämätöntä Suunnittele organisaation tuotantokulttuuri uudelleen .

Ja tämä on mahdotonta tehdä johdon vahvalla tahdolla. Tästä syystä CMM:ssä määritelty lähestymistapa on yksinkertaisesti käyttökelpoisempi ja realistisempi kuin ISO 9000 cm:n mallit. Riisi. 5.

Tarkastellaan nyt, kuinka käytännössä on mahdollista rakentaa molempien mallien kanssa yhteensopiva QMS.

Asiantuntijaarvio keskeisten CMM-prosessien kattavuusasteesta ISO 9000:2000 -standardin vaatimusten kanssa CMM:n tekijöiden itsensä arvion (4) mukaisesti on esitetty kohdassa Kuva 6.

Itse asiassa heidän arviointinsa suoritettiin kahdella koordinaatilla:

varmuusaste (prosentteina) kehitysprosessien (SWP) noudattamisesta kypsyystason kanssa CMM:n puitteissa -" säännös";

tällaisen tarjonnan mahdollisuusaste (%), jonka antaa ISO 9000:2000 - " tilaisuus".

Kuten voidaan nähdä Riisi. 6, ISO 9000:2000 -vaatimukset luovat todellisen mahdollisuuden saavuttaa jopa SWP-kypsyysaste (CMM Level 5).

Kuitenkin siinä mielessä, että jo varmistetaan vähintään kolmannen (CMM Level 3) tason SWP-kypsyys, ISO 9000:2000 -mallin mukaista QMS:ää on kuitenkin muutettava hieman - eli kehitetään ja toteutetaan vielä kaksi organisaatiomenettelyä ( Organisaatioprosessin määritelmä ja painopiste) ja yleinen hallintomenettely ( Integroitu ohjelmistohallinta ), jonka sisältö ei ole vaikeaa kenellekään IT-yritykselle.

Mutta voit ja pitäisi mennä pidemmälle (CMM-taso 4) - esimerkiksi suluissa näkyy tämän artikkelin kirjoittajan arvio (samoissa koordinaateissa - tuettavuus ja ominaisuudet), joka vastaa ISO 9000:n mukaista laadunhallintajärjestelmää: 2000 malli, jossa QMS-prosessimaisemaa täydennetään prosessien projektinhallinnalla toisen edellä mainitun standardin vaatimusten mukaisesti PM Bok- Tämä auttaa sinua merkittävästi lisäämään sellaisten kypsyyttä SWP, Miten:

Projektien edistymisen seuranta (ohjelmistoprojektien seuranta ja valvonta);

• Ohjelmistoprojektien suunnittelu;

Yleinen ohjelmistojen hallinta (Integroitu ohjelmistojen hallinta);

Prosessinhallinta kvantitatiivisten arvioiden avulla (Quantitative Process Management).

Riisi. 6. Asiantuntijaarvio keskeisten CMM-prosessien kattavuusasteesta ISO 9000:2000 -vaatimusten kanssa

Kuten voidaan nähdä Kuva 6., CMM-malli on siihen upotettujen periaatteiden mukaan hyvin lähellä ISO 9001:2000 -standardin mukaisesti rakennettua ja projektinhallintaprosesseilla täydennettyä laatujärjestelmää. PM BoK..

Jotta tuotantoprosesseja määriteltäessä ei tekisi turhaa työtä ISO 9000:n mukaisen sertifioinnin ja myöhemmän CMM-arvioinnin kanssa, suosittelen sisällyttämään (tai ehkä rajoittumaan niihin - IT-yrityksellehan nämä ovat tuotantoprosesseja) !) kaikki mitä tarvitaan CMM KPA -mallissa. Näin yhtiö samanaikaisesti:

täyttää vaatimukset ISO 9001:2000 prosessilähestymistavan käyttöönotosta;

kaikki tarvittavat asiakirjat CMM prosessit ( KPA);

toteuttaa useita tällaisia ​​tärkeitä vaatimuksia ISO 9001:2000 Miten:

metriikkaan perustuva prosessinhallinta (Kvantitatiivinen prosessinhallinta);

alihankintasopimusten hallintaan perustuva toimittajien hallinta ( Ohjelmistojen alihankintasopimusten hallinta );

kuluttajien vaatimusten analyysi vaatimusten hallinta ( Vaatimusten hallinta );

henkilöstöhallinnon pohjalta Koulutusohjelma );

viestintähallinta perustuu muodollisten mallien luominen organisaation prosesseista ( Organisaatioprosessin määritelmä );

käynnistää parannusmekanismin (Suunnittele-Tee-Tarkista -Toiminto) kaikki kuvatut prosessit (SWP) kaikkien viiden johdonmukaisen täytäntöönpanon kautta Yleiset piirteet-cm. Riisi. 5.

Jos siis käytät KPA CMM:ää BP:nä ja käytät ohjelmistokehityksen projektinhallintamenettelyjä koskevia vaatimuksia PM BoK, Tällöin tällä tavalla rakennettu QMS voidaan arvioida CMM Taso 4 - cm. Riisi. 7.

Riisi. 7. Kaavio CMM-tason 4 saavuttamiseksi käyttämällä ISO 9000 QMS -mallia ja PM BoK 2000 -opasta yhdessä.

Lopuksi esitän selkeyden vuoksi (tekijän tyylitelmässä) kaavion IT-yrityksen QMS:n toiminnasta ISO 9000- ja CMM-mallien johdonmukaisella toteutuksella - ks. Riisi. 8.

Riisi. 8. QMS:n toimintakaavio ISO 9000- ja CMM-mallien johdonmukaisella toteutuksella (tekijän tyylitelty)

Tässä on tärkeää ymmärtää, että sekä CMM että ISO 9001:2000 ovat itsessään vain työkaluja jatkuvaan parantamiseen.

Siten ISO 9001:2000 -standardin mukaisen sertifioinnin ja sertifikaatin vahvistamisen tulee edistää yrityksen prosessien laadun kasvua, jossa prosessin laadun kasvun arviointikriteerinä on yrityksen saavuttaminen uudelle tasolle. BPI eli heidän arvionsa perustuu jo malliin CMM {3}.

Kirjallisuus

"Ohjelmiston laadun arviointi", V. Lipaev, Sinteg, 2001.

ISO 9001:2000. Laadunhallintajärjestelmä. Vaatimukset.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software (SW-CMM), versio 1.1. // CMU/SEI-93-TR-024, - helmikuu, 1993.

Huomautus: Luultavasti tunnetuimman ohjelmistokehitysprosessien parantamismenetelmän, CMM:n, taustalla olevia ideoita tutkitaan yksityiskohtaisesti. HMM:n logiikka ja rakenne analysoidaan. HMM:n ja aiemmin tutkittujen prosessimallien välinen yhteys esitetään.

Upea käytännöllinen työkalu, joka on luotu sisällä prosessilähestyminen toiminnan kuvaukseen suunnitteluorganisaatio, erityisesti kehittyvät organisaatiot Tietojärjestelmä, osoittaa HMM-metodologian. CMM tulee sanoista Capability Maturity Model, joka tarkoittaa karkeasti "hallintajärjestelmän kypsyysmallia". Kirjallisuudessa CMM:ää kutsutaan useammin organisaation kypsyysmalliksi, ja aion myös noudattaa tätä perinnettä.

SMM:n syntyhistoria on seuraava. 80-luvun lopulla. viime vuosisadalla Yhdysvaltain puolustusministeriö määräsi Institute of Software Engineeringin 1eng. SEI - Software Engineering Institute Carnegie Mellon University pyrkii luomaan kriteerijärjestelmän alihankkijoiden valinnalle ohjelmistokehitysprojekteissa. Työ valmistui vuonna 1991, ja tuloksena syntyi CMM-malli. On välittömästi tehtävä varaus, että malli ei sisällä taloudellista, taloudellista, poliittista tai organisatorista valintakriteeri alihankkija sekä kriteerit mahdollisuudesta päästä luokiteltuun työhön (todennäköisesti tällaisia ​​tehtäviä ei asetettu). Puhumme vain kriteereistä, jotka kuvaavat mahdollisen alihankkijan kykyjä ohjelmistojärjestelmien kehittämisessä.

CMM:n rakenne

Mallin luojat ottivat organisaation prosessit lähtökohtana arvioidessaan organisaation kykyä tehdä laadukasta työtä, jota kutsuttiin kypsyydeksi. Sitten he tekivät useita ei-triviaaleja oletuksia, jotka monet IT-asiantuntijat (ja ehkä useimmat heistä) hyväksyivät ja tunnustivat oikeudenmukaisiksi.

Oletus 1. On olemassa laadullisesti erilaisia ​​kypsyysasteita suunnitteluorganisaatio, kehittyy Tietojärjestelmä(HMM-mallissa on viisi tällaista tasoa).

Oletus 2. Jokainen kehitysorganisaatio on kiinnostunut siirtymään korkeammalle kypsyysasteelle (ei pelkästään lisätäkseen mahdollisuuksiaan Puolustusministeriön sopimuskilpailussa, vaan myös oman parantamisensa vuoksi).

Oletus 3. Siirtyminen on mahdollista vain järjestyksessä seuraavalle tasolle. Tason yli on mahdotonta "hyppää" (tarkemmin sanottuna organisaation riskit kasvavat jyrkästi).

Siten tasot muodostavat "tikkaat", joita pitkin organisaatio nousee kehittyessään. Jokaiselle tasolle on ominaista organisaation prosessien tietty koostumus ja ominaisuudet. SMM:n "tasojen tikkaat" ovat saaneet laajaa tunnustusta ja levitystä. Tältä hän näyttää.

Taso 1 "aloittelija". Koko tuotantoprosessille on ominaista, että se syntyy joka kerta tiettyä projektia varten ja joskus jopa kaoottiseksi. Vain muutama prosessi on määritelty, ja projektin onnistuminen riippuu yksilöiden ponnisteluista.

Taso 2 "Toistettavissa". Projektinhallinnan perusprosessit on luotu, joiden avulla voit seurata kustannuksia, seurata työaikataulua ja luodun ohjelmistoratkaisun toimivuutta. Prosessien kurinalaisuus, jota vaaditaan aiempien onnistumisten toistamiseksi vastaavissa sovelluskehitysprojekteissa, on perustettu.

Taso 3 "määritelty". Tuotantoprosessi on dokumentoitu ja standardoitu sekä hallinnan että suunnittelun osalta. Tämä prosessi on integroitu organisaation vakiotuotantoprosessiin. Kaikissa projekteissa käytetään hyväksyttyä, räätälöityä versiota organisaation vakiovalmistusprosessista.

Taso 4 "Hallinnoitu". Tuotantoprosessista ja luodun tuotteen laadusta kerätään yksityiskohtaisia ​​kvantitatiivisia indikaattoreita. Sekä tuotantoprosessia että tuotteita arvioidaan ja ohjataan kvantitatiivisesta näkökulmasta.

Taso 5 "Optimointi". Prosessin jatkuva parantaminen saavutetaan kvantitatiivisella palautteena prosessista ja edistyneiden ideoiden ja teknologioiden toteuttamisesta siinä.

Tarkkuuden puutteesta huolimatta annettu määritelmä ei intuitiivisesti useimmiten aiheuta vastalauseita. Lisäksi kokeneet asiantuntijat ymmärtävät, miksi siirtymät ovat mahdollisia vain naapuritasolle, ja on myös selvää, miksi tällaiseen siirtymiseen kannattaa yleensä pyrkiä. Samanaikaisesti HMM-malli ei sisällä kvantitatiivisia tai edes muodollisia perusteita tälle lähestymistavalle, mikä ei kuitenkaan millään tavalla vähennä sen etuja.

Mitä seuraavaksi tapahtuu, kuten he sanovat, on tekniikasta kiinni. Mallin rakenne määritellään (kuva 7.1), annetaan määritelmät ja aloitetaan huolellinen työ kunkin prosessin tarkasti kuvaamiseksi kullakin tasolla. Jotta voimme arvioida tehdyn käytännön arvon, menemme osaksi tätä tietä.

Riisi. 7.1.

Kuvassa 7.1 sisältää seuraavat käsitteet.

Avainprosessiryhmä. Kuten (Paulk, et al., 1995) todetaan, "jokainen avainprosessien ryhmä määrittelee toisiinsa liittyvien toimintojen lohkon, jonka tuloksena saavutetaan joukko tavoitteita, jotka ovat merkittäviä tuotantoprosessin tuottavuuden lisäämisen kannalta. esimerkiksi ryhmälle avainprosesseja" Vaatimusten hallinta"(Katso kuva 7.2) tavoitteena on sovittaa yhteen ohjelmistokehitysprojektin vaatimukset asiakkaan ja kehittäjän välillä."

CMM:ssä ei ole yksittäisiä prosesseja. Sen sijaan on olemassa erillisiä teoksia, joita kutsutaan avainkäytännöiksi (katso alla), jotka on yhdistetty tuloilla ja lähdöillä toisiinsa ja jotka toimivat rakennusprosessien lähdemateriaalina. CMM ei anna ohjeita siitä, miten prosessit tulisi rakentaa, eli kuinka keskeiset käytännöt tulisi linkittää loogisiksi sarjoiksi. Keskeisiä käytäntöjä kutsutaan avainprosessiryhmiksi.

CMM:n avainprosessien ryhmät on kartoitettu kypsyystasoille (Kuva 7.2), eli kaikki tason käytännöt ovat vuorovaikutuksessa vain toistensa kanssa eivätkä ole vuorovaikutuksessa muiden tasojen käytäntöjen kanssa. Näin voimme taata kaikkien prosessien täyden toimivuuden tietyllä tasolla ja siten korreloida tason organisaation valmistuneen kehitysvaiheen kanssa.

Adjektiivi "avain" tarkoittaa, että niitä on prosessiryhmiä(eli joukko käytäntöjä), jotka eivät ole avainasemassa tietyn kypsyystason kannalta, eli eivät liity tämän tason tavoitteiden saavuttamiseen (katso alla). HMM-malli ei kuvaa kaikkea prosessiryhmiä liittyvät ohjelmistojen kehittämiseen ja ylläpitoon. Se kuvaa vain niitä ryhmiä, jotka on määritelty tuotantoprosessin tuottavuuden avaintekijöiksi.

Tavoitteet. HMM:n tavoitteet eivät liity prosesseihin, vaan avainprosessien ryhmiin. Kuten edellä mainittiin, tavoitteet saavutetaan toteuttamalla keskeisiä käytäntöjä. CMM:ssä tavoitteen saavuttaminen tarkoittaa sitä, että ensinnäkin avainkäytäntöjen suorittamisen jälkeen saavutetaan haluttu tulos ja toiseksi se saavutetaan melko johdonmukaisesti. Tapa, jolla avainprosessien ryhmän tavoitteet saavutetaan, voi vaihdella projekteista toiseen riippuen eroista aihealue tai ympäristöön.

Jos nämä tavoitteet saavutetaan kaikissa projekteissa, tämä tarkoittaa, että organisaatio on saavuttanut sen tuotantoprosessin kypsyyden, johon tämä avainprosessien ryhmä liittyy.

Luku. Osat (niitä on viisi kullakin tasolla ja ne ovat aina samat) edustavat avainprosessiryhmien ominaisuuksia, jotka on toteutettava vastaavalla tasolla. Nämä ominaisuudet kuvaavat, kuinka prosessit toteutetaan ja missä määrin ne on laillistettu organisaatiossa, eli virallisesti hyväksytty ja johdonmukainen yrityksen menettelytapojen, käytäntöjen ja muiden prosessien kanssa. Nämä ovat viisi osaa.

Suoritusvelvoitteet

Kuvaile toiminnot, jotka organisaation on suoritettava varmistaakseen prosessin vakiintumisen ja vakauden. Toteutussitoumukset liittyvät tyypillisesti organisaatiopolitiikan laatimiseen ja ylimmän johdon tukeen.

Edellytykset

Kuvaa edellytykset, jotka projektissa tai organisaatiossa on täytettävä tuotantoprosessin asiantuntevaksi toteuttamiseksi; liittyvät yleensä resursseihin, organisaatiorakenteisiin ja vaadittuun koulutukseen.

Toimenpiteet suoritettu

Kohdassa "Suoritetut toiminnot" kuvataan tällä tasolla suoritettavat olennaiset työt. Suoritettavat toiminnot sisältävät tyypillisesti suunnitelmien laatimista ja tiettyjen toimintojen toteuttamista, töiden suorittamista ja seurantaa sekä tarvittaessa korjaavia toimenpiteitä.

Mittaukset ja analyysit

Osa "Mittaukset ja

"Jokainen keskeisten prosessien ryhmä ilmaistaan ​​avainkäytännöillä, joiden toteuttaminen edistää ryhmän tavoitteiden saavuttamista. Avainkäytännöt kuvaavat infrastruktuuria ja toimintaa, jotka vaikuttavat eniten avainprosessiryhmän tehokkaaseen toteuttamiseen ja perustamiseen.

Jokainen keskeinen käytäntö koostuu yhdestä lauseesta, joka on usein laajennettu yksityiskohtaisemmaksi kuvaukseksi, joka voi sisältää esimerkkejä ja selvennyksiä. Ydinkäytännöt, joita joskus kutsutaan huipputason ydinkäytännöiksi, määrittävät peruskäytännöt, -menettelyt ja -toiminnot avainprosessien ryhmälle. Yksityiskohtaisen kuvauksen osia kutsutaan usein osakäytännöiksi."

Ydinkäytännöt kuvaavat MITÄ on tehtävä, mutta niitä ei pidä pitää dogmina, jotka kertovat MITEN tavoitteet saavutetaan. Keskeisten prosessien ryhmän tavoitteet voidaan saavuttaa vaihtoehtoisilla käytännöillä. Keskeisten käytäntöjen tulkinnan tulee olla järkevää, jotta avainprosessiryhmän tavoitteet voidaan saavuttaa tehokkaasti, vaikkakin ehkä muodollisesti eri tavalla kuin CMM:n suosittelema.

Näkymä IT-johtamisen toiminnasta, jossa prosessien sijaan tarkastellaan niiden komponentteja - avainkäytäntöjä ja prosessit ovat läsnä vain virtuaalisesti, avainkäytännöistä rakennettavana asiana, näyttää ensisilmäyksellä hieman eksoottiselta. Tähän asti IT-hallinnan parantamisen tehtävä on ratkaistu ottamalla käyttöön valmiita prosesseja referenssiprosessimallista. Nyt on monia tasoja, jotka sisältävät erilaisia ​​(eli prosesseihin integroimattomia) keskeisiä käytäntöjä ja suositeltua etenemisjärjestystä tasojen läpi. IT-hallinta CMM:n mukaan paranee, kun se siirtyy korkeammalle kypsyysasteelle. Mitä tällaiselle edistymiselle tapahtuu?

Tasojen määritelmissä (katso kuva 7.2) esiintyi sellainen käsite kuin "tuotantoprosessi". Se on mukana myös avainprosessien ryhmän määritelmässä, eikä tämä ole sattumaa. Tuotantoprosessi tai, kuten SMM:ssä oikein kutsutaan, organisaation standardituotantoprosessi (SPPO) on yksi koko mallin keskeisistä käsitteistä.

Tarkastelemme laadunvarmistusmallien kehitystä "prosessikypsyysmallin" tai "kyvyn kehittämismallin" perusteella. CMM (Capability Maturity Model). Huolimatta siitä, että malli SMM Tavoitteena on ohjelmistojen laadun varmistaminen, sen metodologiset näkökohdat soveltuvat minkä tahansa tuotteen (tavarat, työt, palvelut) laadunvarmistusmalleihin.

Pääasia mallissa SMM on organisaation kypsyyden käsite.

Kehittymätön pidetään organisaationa, jossa ohjelmistokehitysprosessi riippuu vain tietyistä esiintyjistä ja johtajista, ja päätökset tehdään usein "lennossa". Tässä tapauksessa on suuri todennäköisyys ylittää budjetti tai jättää projektin määräaika ohi, ja siksi johtajat joutuvat käsittelemään vain välittömien ongelmien ratkaisemista.

Kypsä Organisaatiota harkitaan, jos seuraavat ehdot täyttyvät:

• – ohjelmistotuotteiden luomiseen ja projektien hallintaan on selkeästi määritellyt menettelyt, joita selkeytetään ja parannetaan pilottihankkeissa analysoimalla "kustannus-tuotto"-komponentteja;
• – arviot työn suorittamisen ajasta ja kustannuksista perustuvat kertyneeseen kokemukseen ja ovat siksi melko tarkkoja;
• – Yrityksellä on standardit ohjelmistokehityksen, testauksen ja toteutuksen prosesseille, säännöt lopullisen ohjelmakoodin suunnittelulle, komponenteille, rajapinnoille jne. Kaikki tämä muodostaa ohjelmistokehitysprosessia tukevan infrastruktuurin ja yrityskulttuurin.

Standardi siis SMM on laadunvarmistusmalli, joka koostuu organisaation kypsyyden arviointikriteereistä ja resepteistä olemassa olevien prosessien parantamiseen. Mallissa SMM Organisaatioille on määritelty viisi kypsyysastetta, joiden ominaisuudet on esitetty kuvassa. 5.3.

Riisi. 5.3. Viisi mallin kypsyysastettaSMM

Ensimmäinen taso (alkutaso) on perusta yrityksen kehittämiselle seuraavilla tasoilla. Uskotaan, että organisaation lähtötasolla ei ole vakaita edellytyksiä laadukkaan ohjelmiston luomiselle. Näin ollen minkä tahansa projektin tulos riippuu täysin johtajan henkilökohtaisista ominaisuuksista ja ohjelmoijien kokemuksesta. Tämä tarkoittaa, että yhden projektin menestys voi toistua vain, jos samat johtajat ja ohjelmoijat määrätään seuraavaan projektiin. Jos johtajat tai ohjelmoijat, jotka ovat saaneet kokemusta projekteista, lähtevät yrityksestä, heidän poistuessaan tuotettujen ohjelmistojen laatu laskee jyrkästi.

On syytä huomata, että alkutasolla, stressaavissa tilanteissa, jotka riippuvat voimakkaasti inhimillisestä tekijästä, kehitysprosessi rajoittuu koodin kirjoittamiseen ja minimaaliseen testaukseen.

Toisen saavuttaminen toistettava taso (toistettavissa oleva taso) määräytyy projektinhallintatekniikan käyttöönoton perusteella yrityksessä. Yrityksen suunnittelu ja projektinhallinta perustuu kertyneeseen kokemukseen, kehitettäville ohjelmistoille on olemassa ja niitä käytetään standardeissa, joiden noudattamista valvoo erityinen laadunvarmistusryhmä. Uskotaan, että toinen taso voi sekä tarjota mahdollisuuksia lisäparannuksiin (siirtyminen kolmannelle tasolle), eikä se sulje pois mahdollisuutta kriittisissä olosuhteissa ohjelmiston luontiprosessin laadun regressiiviseen palautumiseen alkuperäiselle tasolle.

Kolmas, tietty taso (määritetty taso) ominaista se, että ohjelmistojen luonti- ja ylläpitoprosessi on täysin dokumentoitu ohjelmistokehityksestä projektinhallintaan. Tämän tason toteuttamisen hypoteesi on, että standardointiprosessissa yritys siirtyy tehokkaimpiin käytäntöihin ja teknologioihin. Organisaatioon on luotava oma ryhmä ohjelmistokehityksen ja projektinhallinnan standardien luomiseksi ja ylläpitämiseksi. Kolmannen tason saavuttamisen edellytyksenä on jatkuvan ammatillisen kehityksen ja työntekijöiden koulutuksen ohjelman läsnäolo yrityksessä. Uskotaan, että tältä tasolta alkaen organisaatio lakkaa olemasta riippuvainen tiettyjen kehittäjien ominaisuuksista, eikä sillä ole taipumusta luisua alemmalle tasolle stressaavissa tilanteissa.

Neljäntenä, hallittava taso (hallittu taso) Yritys määrittää kvantitatiivisia laatuindikaattoreita - sekä ohjelmistotuotteille että niiden luomisprosesseille kokonaisuutena. Parempi projektinhallinta saavutetaan siten vähentämällä eri projektimittareiden varianssia. Tässä tapauksessa toteutettujen ohjelmistojen luontiprosessien merkitykselliset (signaali)variaatiot erotetaan prosessin satunnaisista (kohina) vaihteluista.

Viides (korkein), optimointitaso (optimointitaso) jolle on ominaista se, että parannustoimenpiteitä ei sovelleta vain olemassa oleviin prosesseihin, vaan myös uusien teknologioiden käyttöönoton tehokkuuden arvioimiseen. Yrityksen päätehtävänä tällä tasolla on jatkuvasti parantaa olemassa olevia prosesseja. Samalla prosessin parantamisen pitäisi auttaa estämään mahdolliset virheet ja viat. Samalla tulee tehdä työtä ohjelmistokehityksen kustannusten alentamiseksi.

Kehitysmallit

Vaatimusprosessien parantaminen

Laadunhallinnan paradigma tapana organisoida tuotantoa ilmestyi kauan sitten. Ideoita on upotettu ISO9000-standardiryhmään 1) , ovat juurtuneet erityisesti sellaisiin "neuvostoliittolaisiin" keksintöihin, kuten rationalisointiehdotusten tukemiseen, mentorointiin jne.

Prosessilähtöisen yritysorganisaation nykyaikaisessa konseptissa jatkuvan laadun parantamisen prosessi on yksi keskeisistä asemista.

Ohjelmistoteollisuudessa ISO9000-sarjan lisäksi menestyneimmät laatustandardit ovat SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Laadunhallintamenetelmien aktiivinen käyttöönotto lännessä alkoi 1960-luvun alussa. ISO9000-sarjan standardit perustuvat CPI (Continuous Process Improvement) ja TQM (Total Quality Management) lähestymistapaan. Sodanjälkeisen Japanin talouden elpyminen johtui suurelta osin TQM:ään upotetuista ideoista.

Laatu on termi, joka toisille tarkoittaa tarvetta tehdä mitä kuluttaja haluaa, toisille sitä, mikä vastaa hänen tarpeitaan. ISO 9001:2000:ssa määritelty laadunhallinta perustuu ensisijaisesti ajatukseen, että ihmiset menestyvät paremmin, jos he tietävät mitä tekevät. .

Siksi ennen minkään toimenpiteen aloittamista sinun tulee saada vastauksia kysymyksiin: mitä on tehtävä, kuka tarkistaa, mitä on tehty, miten se tulisi tehdä ja kuinka määrittää, että työ on valmis? Sinun on myös harkittava, kuinka aiot hallita prosessia ja miten sitä voidaan parantaa.

ISO9000:n perusperiaatteet:

• Keskittyminen asiakkaiden tarpeisiin;
• Johdon aktiivinen johtajarooli;
• Esiintyjien osallistuminen parannusprosesseihin;
• Prosessilähestymistavan toteuttaminen;
• Systemaattinen lähestymistapa johtamiseen;
• Jatkuvien parannusten varmistaminen;
• Tosiasioihin perustuva päätöksenteko;
• Molempia osapuolia hyödyttävät suhteet tavarantoimittajien kanssa.

Tämän ryhmän standardien kiistaton etu johtuu siitä, että niitä on testattu monissa yrityksissä ympäri maailmaa. Näiden standardien suositukset ovat kuitenkin melko yleisiä eivätkä ota huomioon IT-alan yritysten erityispiirteitä. Tämän saavuttamiseksi on kehitetty erityisiä lähestymistapoja, joista keskustellaan jäljempänä.

CMM (The Capability Maturity Model) -standardin on kehittänyt Carnegie Mellonin yliopiston Software Engineering Institute (SEI).

Standardin tarkoituksena on arvioida ohjelmistokehitysorganisaation kypsyysastetta. Tasoja on viisi: alku, toistettava, määritelty, hallittu ja optimointi (katso lisätietoja). Tämä standardi on tullut laajalti tunnetuksi, ja huomattava osa länsimaisista IT-yrityksistä on sertifioitu CMM:n mukaan.

Vuonna 2000 SEI julkaisi CMMI-SE/SW:n, integroidun mallin sekä ohjelmistojen että järjestelmän suunnitteluominaisuuksien parantamiseksi.

CMMI-SE/SW:llä on kaksi muotoa. Porrastettu esitys vastaa SW-CMM-rakennetta pienten tasojen nimien tarkennuksilla. Viisi kypsyystasoa sisältävät 22 prosessialuetta, jotka on esitetty taulukossa 14.1. (CMU/SEI, 2000a). Jatkuvassa edustuksessa on erilainen näkemys: samat 22 aluetta on jaettu 4 kategoriaan: prosessinhallinta, projektinhallinta, rakentaminen ja tuki (CMU/SEI, 2000b).

Kypsyystasojen sijaan jatkuva näkymä määrittelee kuusi kykytasoa kullekin prosessialueelle. Tämän näkymän avulla kukin organisaatio voi päättää, minkä kykytason se täyttää kullakin 22 prosessialueella.

Kuten CMM:ssä, tässä standardissa tasolla 2 on alue nimeltä "vaatimusten hallinta", mutta toisin kuin aikaisemmassa standardissa, tasolla 3 on myös erillinen osa "vaatimussuunnittelu". Tämän alueen asettaminen tasolle 3 ei tarkoita, että organisaation projekteille asetettuja vaatimuksia, jotka eivät saavuta tasoa 2, ei tarvitse kerätä ja dokumentoida. Vaatimushallinnan nähdään auttavan luomaan ennakoitavampia ja vähemmän kaoottisia projekteja, mikä on CMM Level 2:n ydin. Ottamalla käyttöön prosessin muutoksen hallintaan ja vaatimusten tilan tarkistamiseen, organisaatio voi keskittyä enemmän korkealaatuisten vaatimusten kehittämiseen.

Vaatimukset Hallintaprosessialue

Keskeisiä aiheita ovat muun muassa kuinka kehitystiimin tulisi saada ymmärrystä vaatimuksista ja ratkaista ongelmia asiakkaiden kanssa, ottaa projektin jäsenet mukaan vaatimustyöhön ja hallita muutosta. Toisin kuin SW-CMM, jäljitys (yksi tärkeimmistä vaatimuksista) sisältyy tarkasteltavaan prosessialueeseen. Standardi käsittelee seuraavia reititysominaisuuksia:

• varmistaa, että alhaisen tason tai toissijaisten vaatimusten lähteet kirjataan;
• jäljitetään jokainen vaatimus toissijaisiin vaatimuksiin ja sijoitetaan se funktioihin, objekteihin, prosesseihin ja toteuttajiin;
• horisontaalisten yhteyksien luominen samaan tyyppiin kuuluvien vaatimusten välille.

Vaatimukset Engineering Process Area

CMMI-SE/SW kuvaa kolme vaatimussuunnittelutekniikkaa:

• tekniikat, jotka määrittelevät täydellisen joukon asiakkaan vaatimuksia, joita käytetään sitten kehittämään vaatimuksia tuotteelle (tunnistamaan hankkeen sidosryhmien tarpeet; muuttamaan tarpeet ja rajoitukset asiakkaan vaatimuksiksi);
• tekniikat, jotka määrittelevät täydellisen joukon vaatimuksia tuotteelle (tuotekomponenttien määrittäminen; tuotteen komponenttien asettaminen; liitäntävaatimusten määrittäminen);
• tekniikat toissijaisten vaatimusten hankkimiseksi, vaatimusten ymmärtämiseksi ja validoimiseksi (toimintakonseptien ja skenaarioiden laatiminen; järjestelmän vaaditun toiminnallisuuden määrittäminen; toissijaisten vaatimusten analysointi; tuotteen luomisen kustannusten, ajoituksen ja riskin arvioiminen; vaatimusten hyväksyminen).

Sekä CMM että CMMI määrittelevät tavoitteet, joihin projekti- tai ohjelmistokehitysorganisaation tulee pyrkiä eri prosessialueilla. He suosittelevat myös tekniikoita näiden tavoitteiden saavuttamiseksi.

CMMI-SE/SW säätelee vaatimustenhallinnan, vaatimusten suunnittelun ja muiden prosessialueiden välisiä suhteita (Kuva 14.1).