Utvecklare
8 maj, 2020
App Dev Manager Darroll Walsh delar en introduktion till CMMI utveckling för utvecklare.
Capability Maturity Model Integrated (CMMI) är ett processförbättrings-och utvärderingsprogram som integreras med andra processförbättringsprogram som Project Management Body of Knowledge (PMBOK) och Agile. Det fungerar för att effektivisera och standardisera alla processer och ge ett sätt att ha övervakning och handlingsbara mätvärden för utveckling, tjänster, leverantörshantering, Cybermognad och andra.
vad jag vill göra är att ge en översikt över CMMI Dev från en utvecklares perspektiv. Vi kommer att hoppa över Projektledning, affärsanalytiker, konfigurationshantering och testa delar av CMMI DEV för att fokusera på CMMI: s inverkan på ett utvecklingsteam. Om det finns intresse för andra roller eller funktioner som kan vara ett bra ämne för ett senare blogginlägg. Observera bara att det finns mycket arbete som händer innan utvecklare kommer igång, även i smidig utveckling.
Låt oss komma igång:
BRS, eller Business Kravspecifikation är där allt börjar, detta är den enda källan till sanning. Det är här de affärskrav som produktägaren signerar på. Medan utvecklarna kan konsulteras om att skapa BRS, är detta främst BA: s ansvar. det är dock här en utvecklare verkligen kan lära känna applikationen de utvecklar; en plats för att få den stora bilden.
design på hög nivå och låg nivå är arkitekturdokumentationen som visar hur komponenterna i applikationen är anslutna. I högnivådesignen skulle vi lägga ut externa beroenden och hur användarna och/eller systemen kommer att interagera med vårt system. Lågnivådesignen skulle lägga ut hur interna komponenter interagerar med varandra. Att granska dessa skulle ge en annan utvecklare en mycket snabb förståelse för applikationens funktion.
SRS, eller Software Requirements Specification, är där utvecklaren dokumenterar hur applikationen ska byggas. Det är här tjänster dokumenteras, beroenden läggs ut och i allmänhet hur koden ska fungera, baserat på BRS som skapades. Detta görs vanligtvis innan koden skrivs och är en standarduppgift. Jag vet att vissa frågar varför vi skulle behöva göra detta. Min kod är självdokumenterande. Och medan jag är säker på att det är, kod sprids genom hundratals filer och tusentals rader kod. Och ibland är avsikten inte så tydlig som vi skulle vilja. SRS ger oss ett dokument att titta på med en tydlig översikt över vad vi kan förvänta oss. Den beskriver användningsfall och förväntat beteende i en konsekvent herrgård.
när vi har definierat vad vi ska göra och sedan skrivit koden är det dags att någon granskar vad vi gjorde. Ange koden översyn. Detta är inte bara en bra praxis för att fånga några misstag och se till att vi följer bästa praxis och riktlinjer, det är ett bra sätt att dela med sig av vad applikationen gör. Enbart handlingen att granska koden med en andra uppsättning ögon ger oss en andra person som är bekant med hur koden fungerar. Eftersom detta har blivit standardpraxis i de flesta utvecklingsteam, kommer jag inte att arbeta med den här.
enhetstestning är en annan viktig vistelse för de flesta utvecklingsprogram. Enhetstestning oavsett om det görs som en del av testdriven utveckling eller efter att koden har skrivits, är ett av de bästa sätten att se till att framtida ändringar inte introducerar fel i vår kod. I en CI / CD-pipeline kan vi se till att alla tester passerar innan vi tillåter kod att checkas in. Detta hjälper oss att hålla koden i gott skick.
individuellt finns det värde i varje uppsättning dokument ovan, men de verkliga vinsterna börjar när du kan knyta all denna information tillsammans. I början av kravinsamlingsprocessen startar vi en Kravspårbarhetsmatris som gör att vi kan länka affärskrav, programkrav, kod, enhetstester, testplaner och fall och användaracceptans tillsammans. Föreställ dig sex månader in i ett stort projekt och en förändring får ett testfall att misslyckas. Vi kan nu gå tillbaka till kraven, ta reda på vad syftet med den koden är, vet exakt var koden är för den logiken, ändra enhetstestet för att fånga det nya fallet och implementera en fix inom några timmar, inte dagar.
på kort sikt kan CMMI verka som overkill, men även på små projekt förkortar kunskapen som fångas genom att följa processen cykeln ju längre du är borta från projektet. För att inte tala om du aldrig har arbetat med projektet tidigare.
Utvecklarsupport
App Dev Customer Success Account Manager, Microsoft Developer Support
Följ