CMMI

tuotekehityksen kypsyysmalli

Capability Maturity Model Integration (CMMI) on tuotekehityksen kypsyysmalli, joka sisältää 22 (25) avainprosessialuetta, joiden pitäisi sisältyä yrityksen tuotekehitysprosesseihin ja käytäntöihin. Kypsyysmalleissa toiminnan kehittäminen jaotellaan tasoihin (askelmiin), joita kiivetään ylöspäin - tähdäten kypsempään,järjestelmälliseen toimintaan. Epäkypsässä organisaatiossa prosessit ovat kertaluonteisia, improvisoituja. Kypsissä organisaatioissa prosessit ovat dokumentoituja, toistettavia, johdettuja ja optimoituja. Prosessien on oltava myös koulutettuja, käyttöönotettuja, tuettuja ja mitattuja.

CMMI-kypsyysmallia voidaan noudattaa joko tasoittaisena (engl. staged) tai jatkuvana (engl. continuous) versiona. Molemmat versiot sisältävät kaikki 22 prosessialuetta. Eri kypsyystasoilla keskitytään eri prosessialueiden parantamiseen. Jokaiseen prosessialueeseen kuuluu sekä yleisiä että erityisiä tavoitteita ja käytäntöjä. Prosessialue katsotaan täytetyksi, kun kaikki yleiset ja erityiset tavoitteet ja käytännöt saadaan täytettyä.

CMMI-mallia käytetään siis sekä organisaation kypsyystason määrittämiseen (esimerkiksi alihankkijaa arvioitaessa) että tuotekehitysorganisaation laatujohtamisen ja prosessinkehittämisen viitekehyksenä, kertomaan minkälaisia käytäntöjä organisaation prosesseihin kannattaisi vielä lisätä. Malli on koostettu parhaiden käytäntöjen pohjalta (benchmarking).

CMMI:n kolme eri alalle erikoistunutta versiota muokkaa

  • CMMI ohjelmistokehitykselle (engl. CMMI for development (CMMI-DEV)), jonka versio 1.02 on julkaistu jo vuonna 2000. Nykyinen versio on 1.3, joka on julkaistu vuonna 2010. Nimensä mukaisesti tämä malli on kehitetty erityisesti ohjelmistokehityksen tarpeet huomioon ottaen. [1]
  • CMMI palveluille, versio 1.2 (engl. CMMI for services (CMMI-SVC)) on vielä kehitysvaiheessa oleva malli, joka tarjoaa ohjeistusta palveluiden tarjoajille. Malli julkaistaneen vuoden 2009 puolella.päivitettävä [2]
  • CMMI hankinnalle, versio 1.2 (engl. CMMI for Acquisition (CMMI-ACQ)) on julkaistu marraskuussa 2007 ja sen pääpaino on tuotteiden ja palvelujen hankintaan liittyvissä toiminnoissa. [3]

CMMI-DEV: prosessialueet muokkaa

Prosessijohtaminen muokkaa

  • Organisaation innovaatio ja järjestäytyminen, Organizational Innovation and Deployment (OID)
Tämä prosessialue valikoi ja käyttää hyödykseen ehdotettuja vähittäisiä ja innovatiivisia parannuksia, jotka vaikuttavat organisaation kykyyn vastata lupaamiinsa laadullisiin ja prosessin suorituskyvyllisiin tavoitteisiin. Käyttöönotettavien parannusten valitseminen perustuu kvantitatiiviseen ymmärrykseen todennäköisistä hyödyistä ja kustannuksista.[1]
  • Organisaation prosessien määrittely, Organizational Process Definition +IPPD (OPD+IPPD)
Prosessialueen tarkoituksena perustaa ja säilyttää organisaation standardiprosessit, työympäristön standardit ja muut organisaation edut ja päämäärät.[1]
  • Prosessit organisaation näkökulmasta, Organizational Process Focus (OPF)
Auttaa organisaatiota suunnittelemaan, toteuttamaan ja ottamaan käyttöön organisaation laajuisia prosessien parannuksia, jotka pohjautuvat olemassa olevien prosessien ja prosessien apukeinojen vahvuuksien ja heikkouksien ymmärtämiseen.[1]
  • Organisaation prosessin suorituskyky, Organizational Process Performance (OPP)
Organisaation liiketoimintatavoitteista saadaan määrällisiä tavoitteita laadun ja prosessin suorittamiseen. Organisaatio tarjoaa projekteille ja tukiryhmille yleisiä mittapuita, prosessin suorituskyvyn lähtökohtia sekä prosessin suorituskykymalleja.[1]
  • Organisaation kouluttaminen, Organizational Training (OT)
Identifioi organisaation strategiset koulutuksen tarpeet sekä taktiset, yleiset koulutuksen tarpeet, joita ilmenee organisaation projekteissa ja tukiryhmissä.[1]
  • Integroitu projektin johtaminen, Integrated Project Management +IPPD (IPM+IPPD)
Projektille määritellyn prosessin perustaminen ja ylläpito. Prosessit räätälöidään kunkin projektin erikoistarpeet huomioon ottaen käyttäen lähtökohtana organisaation standardiprosesseja.
Kun integroidun projektin johtamisen perään lisätään vielä IPPD (lyhenne sanoista Integrated Product and Process Development), kyse on integroidusta tuotteen ja prosessien kehityksestä, tehtävästä joka koskee useampaa tiimiä. Tällöin yhteisen näkemyksen luominen ja tiimien riittävä yhteistyö on tärkeää.[1]

Projektinhallinta muokkaa

  • Projektisuunnittelu, Project Planning (PP)
Prosessialue käsittelee projektisuunnitelman kehittämistä, osakkaiden tarkoituksenmukaista mukanaoloa, suunnitelmaan sitoutumista ja suunnitelmassa pitäytymistä.[1]
  • Projektin valvonta ja hallinta, Project Monitoring and Control (PMC)
Toimintojen valvontaa ja tarvittaessa korjaavien toimien käyttöönottoa. Projektisuunnitelmassa päätetään, kuinka tarkasti projektia valvotaan, kuinka usein edistymistä tarkistetaan, sekä kuinka edistymisen valvonta toteutetaan.[1]
  • Toimittajasopimusten hallinta, Supplier Agreement Management (SAM)
Osoittaa projektien tarpeen omaksua ne osat työstä, jotka toimittajat ovat tehneet. Toimittajan edistymistä ja suorituskykyä seurataan valvomalla työn tuotoksia ja työprosesseja, toimittajasopimusta tarkastellaan uudelleen tarvittaessa. Toimittajan tekemät komponentit arvioidaan ja testataan. [1]
  • Riskienhallinta, Risk Management (RSKM)
Riskienhallinta on eteenpäinsuuntautunutta ja jatkuvaa. Sen aktiviteetit sisältävät riskimuuttujien tunnistamisen, riskien arvioinnin ja niiden lieventämisen.[1]
  • Määrällinen projektin johtaminen, Quantitative Project Management (QPM)
Soveltaa määrällisiä ja tilastollisia tekniikoita prosessin suorituskyvyn hallintaan ja tuotteiden laadunvarmistukseen.[1]

Tekniset prosessit muokkaa

  • Vaatimusten hallinta, Requirements Management (REQM)
Kuvailee vaatimusten kontrollointiin ja hankkimiseen sekä asiaankuuluvien suunnitelmien ja aineiston ajan tasalla pitämiseen liittyviä toimintoja. Tämän prosessialueen ansiosta voidaan jäljittää asiakkaan vaatimukset tuotteen komponenttien tasolle asti.[1]
  • Vaatimusten kehittäminen, Requirements Development (RD)
Identifioi asiakkaiden tarpeet ja muokkaa ne tuotteen vaatimuksiksi. Tällä tavoin syntyneet tuotteen ja sen komponenttien vaatimukset kuvailevat selkeästi ohjelmiston kehittäjän ymmärtämillä ja käyttämillä termeillä tuotteen suorituskykyä, suunnittelun erityispiirteitä, varmennusvaatimuksia jne. [1]
  • Tekninen ratkaiseminen, Technical Solution (TS)
Tämä prosessialue kehittää teknisiä datapaketteja tuotteen komponenteille, joita PI tai SAM -prosessialueet käyttävät.[1]
  • Tuotteen integrointi, Product Integration (PI)
Tuotteen integroinnin prosessialue sisältää parhaaseen mahdolliseen integraation jaksoon, tuotteen komponenttien integrointiin, sekä tuotteen asiakkaalle toimitukseen liittyviä käytäntöjä. [1]
  • Varmennus, Verification (VER)
Prosessialue pitää huolen siitä, että valitut työn tuotteet ovat niille määriteltyjen vaatimusten mukaisia. Varmennus on yleensä vähittäinen prosessi, alkaen tuotteen komponenttien varmentamisella ja yleensä loppuen kokonaan kasatun tuotteen varmentamiseen. Varmennuksen yhtenä osana on myös vertaisarviointi. Vertaisarvioinnit on todistetusti tehokas menetelmä virheiden huomaamiseen sekä poistamiseen varhaisessa vaiheessa ja ne mahdollistavat arvokkaan näkökulman työn tuotteisiin ja niiden komponentteihin. [1]
  • Validointi, Validation (VAL)
Tämä prosessialue validoi tuotteita peilaten niitä asiakkaan tarpeisiin. Se, että validointivaatimukset kehitetään yhteistyössä asiakkaan kanssa on tärkeä elementti tässä prosessialueessa. Validoinnin kohteita ovat mm. tuotteet, niiden komponentit, sekä valikoidut välivaiheen tuotteet ja prosessit.[1]

Tukiprosessit muokkaa

  • Kokoonpanon hallinta, Configuration Management (CM)
Tukee kaikkia prosessialueita vakiinnuttamalla ja ylläpitämällä ehyttä työn tuotetta hyödyntämällä kokoonpanon tunnistamista, kontrollointia, tilanteen kirjanpitoa ja seurantaa. Esimerkkejä työn tuotteista, jotka voidaan käsitellä tämän prosessialueen avulla sisältävät mm. suunnitelmat, menetelmänkuvaukset, vaatimukset, suunnitelmadatan, piirustukset, tuotteen erittelyt, koodin, kääntäjät, tuotteen datatiedostot, sekä tuotteen tekniset julkaisut.[1]
  • Prosessin ja tuotteen laadunvarmistus, Process and Product Quality Assurance (PPQA)
Tarjoaa toimintatapoja suoritettujen prosessien, sekä työn tuotteiden ja palvelujen objektiiviseen arviointiin kun niitä verrataan soveltuviin prosessin määrittelyihin, standardeihin ja menettelytapoihin. Jos näissä katselmuksissa nousee esille jotakin ongelmia, tämä prosessialue pitää huolen siitä, että niihin puututaan. [1]
  • Mittaus ja analyysi, Measurement and Analysis (MA)
Mittaus ja analyysi tukee kaikkia muita prosessialueita tarjoamalla tiettyjä toimintatapoja projektin ja organisaation opastamiseen kun sovitetaan mittaustarvetta ja –päämäärää puolueettomia tuloksia tarjoavaan mittaustapaan. [1]
  • Päätöksenteon analyysi ja ratkaiseminen, Decision Analysis and Resolution (DAR)
Tämä prosessialue tukee kaikkia prosessialueita määrittelemällä, mitkä ongelmat pitäisi käydä läpi virallisen arviointiprosessin avulla. [1]
  • Syysuhteen analyysi ja ratkaiseminen, Causal Analysis and Resolution (CAR)
Tämän prosessialueen avulla projektin jäsenet tunnistavat valikoitujen vikojen syyt ja muut ongelmat sekä toimivat niiden ehkäisemiseksi tulevaisuudessa.[1]

Lähteet muokkaa

  1. a b c d e f g h i j k l m n o p q r s t u v w Software Engineering Institute. (2010). CMMI for development, version 1.3. Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/reports/10tr033.pdf
  2. Software Engineering Institute. (2008b). CMMI for services (CMMI-SVC), partner and piloting draft, V0.9c. Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html
  3. Software Engineering Institute. (2007b). CMMI for acquisition, version 1.2. Carnegie Mellon University. Retrieved from http://www.sei.cmu.edu/pub/documents/07.reports/07tr017.pdf

Aiheesta muualla muokkaa