Spēju brieduma modelis (CMM) & tas ir programmatūras inženierijas līmeņi

Satura rādītājs:

Anonim

Kas ir CMM?

Spēju termiņa modeli izmanto kā etalonu, lai izmērītu organizācijas programmatūras procesa briedumu.

CMM tika izstrādāts programmatūras inženieru institūtā 80. gadu beigās. Tas tika izstrādāts ASV Gaisa spēku finansēta pētījuma rezultātā, lai novērtētu apakšuzņēmēju darbu. Vēlāk, pamatojoties uz CMM-SW modeli, kas izveidots 1991. gadā, lai novērtētu programmatūras izstrādes briedumu, daudzi citi modeļi ir integrēti CMM-I, tie ir

Šajā apmācībā mēs iemācīsimies,

  • Kas ir spēju brieduma modeļa (CMM) līmeņi?
  • Kas notiek dažādos CMM līmeņos?
  • Cik ilgs laiks nepieciešams CMM ieviešanai?
  • CMM iekšējā struktūra
  • CMM modeļu ierobežojumi
  • Kāpēc izmantot CMM?

Kas ir spēju brieduma modeļa (CMM) līmeņi?

  1. Sākotnējais
  2. Atkārtojams / Pārvaldīts
  3. Definēts
  4. Kvantitatīvi Pārvalda
  5. Optimizēšana

Kas notiek dažādos CMM līmeņos?

Līmeņi Aktivitātes Ieguvumi
1. līmeņa sākotnējais
  • 1. līmenī process parasti ir haotisks un ad hoc
  • Spēju raksturo, pamatojoties uz indivīdiem, nevis uz organizāciju
  • Progress nav mērīts
  • Izstrādātie produkti bieži ir grafiki un pārsniedz budžetu
  • Plašas grafika, izmaksu, funkcionalitātes un kvalitātes mērķu variācijas
Nav. Projekts ir kopējais haoss
Pārvalda 2. līmeni
  • Prasību pārvaldība
  • Novērtējiet projekta parametrus, piemēram, izmaksas, grafiku un funkcionalitāti
  • Izmēri faktisko progresu
  • Izstrādājiet plānus un procesu
  • Ir definēti programmatūras projekta standarti
  • Identificēt un kontrolēt produktus, ziņojumus par problēmām utt.
  • Procesi dažādos projektos var atšķirties
  • Procesi kļūst vieglāk uztverami
  • Vadītāji un komandas locekļi tērē mazāk laika, lai izskaidrotu, kā lietas tiek darītas, un vairāk laika - to izpildei
  • Projekti ir labāk novērtēti, labāk plānoti un elastīgāki
  • Kvalitāte ir integrēta projektos
  • Sākotnēji izmaksas varētu būt augstas, taču tās pārsniedz virsstundas
  • Jautājiet vairāk dokumentu un dokumentācijas
Definēts 3. līmenis
  • Precizēt klientu prasības
  • Atrisiniet dizaina prasības, izstrādājiet ieviešanas procesu
  • Pārliecinās, vai produkts atbilst prasībām un paredzētajam lietojumam
  • Sistemātiski analizējiet lēmumus
  • Labojiet un kontrolējiet iespējamās problēmas
  • Procesa uzlabošana kļūst par standartu
  • Risinājums pāriet no "kodēšanas" uz "inženieriju"
  • Kvalitātes vārti parādās visā projekta laikā, iesaistot visu procesā iesaistīto komandu
  • Riski tiek mazināti un nepārsteidz komandu
4. līmenis kvantitatīvi pārvaldīts
  • Statistiski pārvalda projekta procesus un apakšprocesus
  • Izprotiet procesa veiktspēju, kvantitatīvi vadiet organizācijas projektu
  • Optimizē procesa veiktspēju visā organizācijā
  • Veicina kvantitatīvu projektu vadību organizācijā.
5. līmeņa optimizācija
  • Savlaicīgi atklājiet un novērsiet defektu cēloni
  • Identificējiet un izvietojiet jaunus rīkus un procesu uzlabojumus, lai apmierinātu vajadzības un biznesa mērķus
  • Veicina organizatoriskās inovācijas un ieviešanu
  • Dod impulsu cēloņu analīzei un izšķirtspējai

Pēc diagrammas ir attēlots, kas notiek dažādos CMM līmeņos

Cik ilgs laiks nepieciešams CMM ieviešanai?

CMM ir vēlamākais produkta kvalitātes uzturēšanas process jebkuram programmatūras izstrādes uzņēmumam, taču tā ieviešana prasa nedaudz ilgāku laiku, nekā paredzēts.

  • CMM ieviešana nenotiek vienā dienā
  • Tas vienkārši nav tikai "papīrs".
  • Tipiski ieviešanas laiki ir
    • 3-6 mēneši -> sagatavošanai
    • 6-12 mēneši -> ieviešanai
    • 3 mēneši -> novērtējuma sagatavošanai
    • 12 mēneši -> katram jaunam līmenim

CMM iekšējā struktūra

Katrs CMM līmenis ir definēts galvenajā procesa apgabalā vai KPA , izņemot 1. līmeni. Katrā KPA ir definēta saistīto darbību kopa, kas, veicot kopīgi, sasniedz mērķu kopumu, kas tiek uzskatīts par būtisku programmatūras spēju uzlabošanai

Dažādiem CMM līmeņiem ir noteikti KPA, piemēram, CMM-2 modelim, KPA ir

  • REQM - prasību pārvaldība
  • PP- projekta plānošana
  • PMC - projekta uzraudzība un kontrole
  • SAM- Piegādātāja līgumu pārvaldība
  • PPQA process un kvalitātes nodrošināšana
  • CM-konfigurācijas pārvaldība

Tāpat arī citiem CMM modeļiem jums ir noteiktas KPA. Lai uzzinātu, vai KPA ieviešana ir efektīva, ilgstoša un atkārtojama, tā tiek kartēta, pamatojoties uz sekojošo

  1. Apņemšanās uzstāties
  2. Spēja uzstāties
  3. Aktivitātes veic
  4. Mērīšana un analīze
  5. Īstenošanas pārbaude

CMM modeļu ierobežojumi

  • CMM nosaka procesa virzienu, nevis tā ieviešanas veidu
  • Tas nepaskaidro visas programmatūras procesa uzlabošanas iespējas
  • Tas koncentrējas uz programmatūras jautājumiem, bet neņem vērā stratēģisko biznesa plānošanu, tehnoloģiju ieviešanu, produktu līnijas izveidi un cilvēkresursu pārvaldību
  • Tajā nav norādīts, kādā uzņēmējdarbībā organizācijai vajadzētu būt
  • CMM šobrīd nebūs noderīga projektā, kam ir krīze

Kāpēc izmantot CMM?

Šodien CMM programmatūras nozarē darbojas kā "apstiprinājuma zīmogs". Tas dažādos veidos palīdz uzlabot programmatūras kvalitāti.

  • Tas ved uz atkārtojamu standarta procesu un tādējādi samazina mācību laiku, kā paveikt lietas
  • Praktizēt CMM nozīmē praktizēt standarta izstrādes protokolu, kas nozīmē, ka tas ne tikai palīdz komandai ietaupīt laiku, bet arī sniedz skaidru priekšstatu par to, kas jādara un ko var sagaidīt
  • Kvalitatīvās aktivitātes labi iederas projektā, nevis tiek uzskatītas par atsevišķu pasākumu
  • Tas darbojas kā piepilsētas loceklis starp projektu un komandu
  • CMM centieni vienmēr ir vērsti uz procesa uzlabošanu

Kopsavilkums

CMM pirmo reizi tika ieviests 80. gadu beigās ASV gaisa spēkos, lai novērtētu apakšuzņēmēju darbu. Vēlāk ar uzlabotu versiju tā tika ieviesta, lai izsekotu programmatūras izstrādes sistēmas kvalitātei.

Viss CMM līmenis ir sadalīts piecos līmeņos.

  • 1. līmenis (Sākotnējais): kur prasības sistēmai parasti ir neskaidras, pārprastas un nekontrolētas. Process parasti ir haotisks un ad-hoc.
  • 2. līmenis (Pārvalda): novērtējiet projekta izmaksas, grafiku un funkcionalitāti. Ir definēti programmatūras standarti
  • 3. līmenis (noteikts): pārliecinās, vai produkts atbilst prasībām un paredzētajam lietojumam
  • 4. līmenis (kvantitatīvi pārvaldīts): statistiski pārvalda projekta procesus un apakšprocesus
  • 5. līmenis (briedums): identificējiet un izvietojiet jaunus rīkus un procesu uzlabojumus, lai apmierinātu vajadzības un biznesa mērķus