Udvikler
8. maj, 2020
App Dev Manager darroll Valsh deler en introduktion til CMMI udvikling for udviklere.
Capability Maturity Model Integrated (CMMI) er et procesforbedrings-og vurderingsprogram, der integreres med andre procesforbedringsprogrammer såsom Projektledelsesorganet for viden (PMBOK) og Agile. Det arbejder for at strømline og standardisere alle processer og give et middel til at have Tilsyn og handlingsrettede målinger for udvikling, tjenester, leverandørstyring, Cyber modenhed, og andre.
hvad jeg vil gøre er at give et overblik over CMMI Dev fra en udviklers perspektiv. Vi springer over projektledelsen, forretningsanalytiker, konfigurationsstyring og test af dele af CMMI DEV for at fokusere på virkningen af CMMI på et udviklingsteam. Hvis der er interesse for de andre roller eller kapaciteter, der kan være et godt emne til en senere blogindlæg. Bare bemærk, at der er meget arbejde, der sker, før udviklere kommer i gang, selv i smidig udvikling.
lad os komme i gang:
BRS, eller Forretningskravspecifikationen er, hvor det hele begynder, dette er den eneste kilde til sandhed. Det er her de forretningsmæssige krav, som produktejeren underskriver. Mens udviklerne kan høres om oprettelse af BRS, er dette primært BA ‘ s ansvar. men det er her en udvikler virkelig kan lære den applikation, de Udvikler, at kende; et sted at få det store billede.
design på højt niveau og lavt niveau er arkitekturdokumentationen, der viser, hvordan komponenterne i applikationen er forbundet. I det høje niveau design, ville vi lægge ud eksterne afhængigheder og hvordan brugerne og/eller systemer vil interagere med t vores system. Det lave niveau design ville lægge ud, hvordan interne komponenter interagerer med hinanden. Gennemgang af disse ville give en anden udvikler en meget hurtig forståelse af applikationens funktion.
SRS, eller specifikation af programkrav, er, hvor udvikleren dokumenterer, hvordan applikationen skal bygges. Det er her tjenester dokumenteres, afhængigheder er lagt ud, og generelt hvordan koden skal fungere, baseret på BRS, der blev oprettet. Dette gøres typisk, før koden er skrevet og er en standardopgave. Jeg ved, at nogle spørger, hvorfor vi skulle gøre dette. Min kode er selvdokumenterende. Og mens jeg er sikker på det er, kode er spredt gennem hundredvis af filer og tusindvis af linjer kode. Og nogle gange er hensigten ikke så klar, som vi gerne vil. SRS giver os et dokument at se på med en klar oversigt over, hvad vi kan forvente. Det skitserer brugssager og forventet adfærd i en konsekvent herregård.
når vi har defineret, hvad vi skal gøre, og derefter skrive koden, er det tid til at få nogen til at gennemgå, hvad vi gjorde. Indtast Kodeanmeldelsen. Dette er ikke kun en god praksis for at fange fejl og sikre, at vi følger bedste praksis og retningslinjer, det er en fantastisk måde at dele, hvad applikationen gør. Den blotte handling at gennemgå koden med et andet sæt øjne giver os en anden person, der er bekendt med, hvordan koden fungerer. Da dette er blevet standard praksis på tværs af de fleste udviklingshold, jeg vil ikke belabor denne ene.
enhedstest er et andet hovedophold for de fleste udviklingsprogrammer. Enhedstest uanset om det er udført som en del af testdrevet udvikling eller udført efter koden er skrevet, er en af de bedste måder at sikre, at fremtidige ændringer ikke introducerer fejl i vores kode. I en CI / CD-pipeline kan vi sørge for, at alle test passerer, før vi tillader kode at blive tjekket ind. Dette hjælper os med at holde koden i god stand.
individuelt er der værdi i hvert sæt dokumenter ovenfor, men de reelle gevinster begynder, når du kan binde alle disse oplysninger sammen. I begyndelsen af processen med indsamling af krav, vi starter en Kravsporbarhedsmatrice, der giver os mulighed for at forbinde forretningskrav, programmelkrav, kode, enhedstest, testplaner og sager, og brugeraccept sammen. Forestil dig seks måneder i et stort projekt, og en ændring får en testsag til at mislykkes. Vi kan nu gå tilbage til kravene, finde ud af, hvad formålet med denne kode er, vide nøjagtigt, hvor koden er for den logik, ændre enhedstesten for at fange den nye sag og implementere en løsning inden for timer, ikke dage.
på kort sigt kan CMMI virke som overkill, men selv på små projekter forkorter den viden, der er fanget ved at følge processen, cyklussen, jo længere du er væk fra projektet. For ikke at nævne, om du aldrig har arbejdet på projektet før.
Udvikler Support
App Dev Kundesucces Account Manager, Microsoft Developer Support
Følg