Capability Maturity Model (CMM) & det är nivåer inom programvaruteknik

Innehållsförteckning:

Anonim

Vad är CMM?

Capability Maturity Model används som ett riktmärke för att mäta mognaden i en organisations mjukvaruprocess.

CMM utvecklades vid Software Engineering Institute i slutet av 80-talet. Det utvecklades som ett resultat av en studie finansierad av US Air Force som ett sätt att utvärdera underleverantörernas arbete. Senare baserat på CMM-SW-modellen som skapades 1991 för att bedöma mognaden av mjukvaruutveckling, är flera andra modeller integrerade med CMM-I de är

I den här handledningen lär vi oss,

  • Vad är CMM-nivåer (Capability Maturity Model)?
  • Vad händer på olika nivåer av CMM?
  • Hur lång tid tar det att implementera CMM?
  • Intern struktur för CMM
  • Begränsningar av CMM-modeller
  • Varför använda CMM?

Vad är CMM-nivåer (Capability Maturity Model)?

  1. Första
  2. Repeterbar / hanterad
  3. Definierat
  4. Kvantitativt hanterad
  5. Optimerande

Vad händer på olika nivåer av CMM?

Nivåer Aktiviteter Fördelar
Nivå 1 Initial
  • På nivå 1 är processen vanligtvis kaotisk och ad hoc
  • En förmåga kännetecknas av individerna och inte av organisationen
  • Framsteg ej uppmätt
  • Produkter som utvecklas är ofta schemalagda och över budget
  • Stora variationer i schema, kostnad, funktionalitet och kvalitetsmål
Ingen. Ett projekt är Total Chaos
Nivå 2 hanterad
  • Kravshantering
  • Uppskatta projektparametrar som kostnad, schema och funktionalitet
  • Mät faktiska framsteg
  • Utveckla planer och bearbeta
  • Programvaruprojektstandarder definieras
  • Identifiera och kontrollera produkter, ändringar av problemrapporter etc.
  • Processer kan skilja sig mellan olika projekt
  • Processer blir lättare att förstå
  • Chefer och teammedlemmar spenderar mindre tid på att förklara hur saker görs och mer tid på att genomföra det
  • Projekten är bättre uppskattade, bättre planerade och mer flexibla
  • Kvalitet integreras i projekt
  • Räkning kan vara högt initialt men går ner övertid
  • Be mer pappersarbete och dokumentation
Nivå 3 definierad
  • Förtydliga kundernas krav
  • Lös designkrav, utveckla en implementeringsprocess
  • Se till att produkten uppfyller kraven och avsedd användning
  • Analysera beslut systematiskt
  • Åtgärda och kontrollera potentiella problem
  • Processförbättring blir standarden
  • Lösningen går från att "kodas" till att "konstrueras"
  • Kvalitetsgrindar dyker upp under hela projektinsatsen med hela teamet involverat i processen
  • Riskerna mildras och överraskar inte laget
Nivå-4 Kvantitativt hanterad
  • Hanterar projektets processer och delprocesser statistiskt
  • Förstå processprestanda, hantera kvantitativt organisationens projekt
  • Optimerar processprestanda i hela organisationen
  • Främjar kvantitativ projektledning i en organisation.
Nivå 5 Optimering
  • Upptäck och ta bort orsaken till defekter tidigt
  • Identifiera och distribuera nya verktyg och processförbättringar för att möta behov och affärsmål
  • Främjar organisatorisk innovation och distribution
  • Ger drivkraft till kausalanalys och lösning

Följande diagram ger en bildrepresentation av vad som händer på olika CMM-nivå

Hur lång tid tar det att implementera CMM?

CMM är den mest önskvärda processen för att upprätthålla produktens kvalitet för alla programvaruutvecklingsföretag, men dess implementering tar lite längre tid än vad som förväntas.

  • CMM-implementering sker inte över natten
  • Det är bara inte bara ett "pappersarbete".
  • Typiska tider för implementering är
    • 3-6 månader -> för beredning
    • 6-12 månader -> för implementering
    • 3 månader -> för beredning av bedömningen
    • 12 månader -> för varje ny nivå

Intern struktur för CMM

Varje nivå i CMM definieras i nyckelprocessområde eller KPA , förutom nivå 1. Varje KPA definierar ett kluster av relaterade aktiviteter som när de utförs kollektivt uppnår en uppsättning mål som anses viktiga för att förbättra programvarufunktionen

För olika CMM-nivåer finns det uppsättning KPA, till exempel för CMM-modell 2 är KPA

  • REQM- Kravshantering
  • PP- Projektplanering
  • PMC- Projektövervakning och kontroll
  • SAM- hantering av leverantörsavtal
  • PPQA-process och kvalitetssäkring
  • CM-konfigurationshantering

På samma sätt har du för andra CMM-modeller specifika KPA: er. För att veta om implementeringen av en KPA är effektiv, varaktig och repeterbar, kartläggs den på följande basis

  1. Åtagande att utföra
  2. Förmåga att prestera
  3. Aktiviteter utförs
  4. Mätning och analys
  5. Verifierar genomförandet

Begränsningar av CMM-modeller

  • CMM bestämmer vad en process ska adressera istället för hur den ska implementeras
  • Det förklarar inte alla möjligheter till förbättring av programvaruprocesser
  • Den koncentrerar sig på programvaruproblem men överväger inte strategisk affärsplanering, att använda tekniker, etablera produktlinje och hantera mänskliga resurser
  • Den säger inte om vilken typ av verksamhet en organisation ska ha
  • CMM kommer inte att vara användbart i projektet som har en kris just nu

Varför använda CMM?

Idag fungerar CMM som ett "godkännande" i mjukvaruindustrin. Det hjälper på olika sätt att förbättra mjukvarukvaliteten.

  • Den styr mot en repeterbar standardprocess och minskar därmed inlärningstiden för hur man får saker gjort
  • Att öva på CMM innebär att man övar standardprotokoll för utveckling, vilket innebär att det inte bara hjälper teamet att spara tid utan också ger en tydlig bild av vad man ska göra och vad man kan förvänta sig
  • Kvalitetsaktiviteterna gelar bra med projektet snarare än att betraktas som en separat händelse
  • Det fungerar som en pendlare mellan projektet och teamet
  • CMM-ansträngningar är alltid att förbättra processen

Sammanfattning

CMM introducerades först i slutet av 80-talet i US Air Force för att utvärdera underleverantörernas arbete. Senare, med förbättrad version, implementerades den för att spåra kvaliteten på programvaruutvecklingssystemet.

Hela CMM-nivån är uppdelad i fem nivåer.

  • Nivå 1 (initial): Där kraven på systemet vanligtvis är osäkra, missförstådda och okontrollerade. Processen är vanligtvis kaotisk och ad-hoc.
  • Nivå 2 (hanterad): Beräkna projektkostnad, schema och funktionalitet. Programvarustandarder definieras
  • Nivå 3 (definierad): Ser till att produkten uppfyller kraven och avsedd användning
  • Nivå 4 (kvantitativt hanterad): Hanterar projektets processer och delprocesser statistiskt
  • Nivå 5 (mognad): Identifiera och distribuera nya verktyg och processförbättringar för att möta behov och affärsmål