Utvikler
8 Mai, 2020
App Dev Manager Darroll Walsh deler en introduksjon TIL CMMI utvikling for utviklere.
Capability Maturity Model Integrated (CMMI) er et prosessforbedrings-og vurderingsprogram som integreres med andre prosessforbedringsprogrammer som Project Management Body Of Knowledge (Pmbok) og Agile. Det arbeider for å effektivisere og standardisere alle prosesser og gi et middel til å ha tilsyn og handlings beregninger For Utvikling, Tjenester, Leverandørstyring, Cyber Modenhet, og andre.
Det jeg vil gjøre er å gi en oversikt over CMMI Dev fra en utviklerperspektiv. Vi vil hoppe over prosjektledelse, forretningsanalytiker, konfigurasjonsstyring og testing av DELER AV CMMI DEV for å fokusere på VIRKNINGEN AV CMMI på et utviklingsteam. Hvis det er interesse for andre roller eller evner som kan være et godt emne for en senere bloggoppføring. Bare vær oppmerksom på at det er mye arbeid som skjer før utviklere kommer i gang, selv I Smidig utvikling.
La oss komme i gang:
BRS, Eller Forretningskrav Spesifikasjonen er der det hele begynner, dette er den eneste kilden til sannhet. Dette er hvor forretningskravene som produkteieren signerer på. Mens utviklerne kan bli konsultert på å skape BRS, dette er hovedsakelig ansvaret FOR BA ‘ s. Men, dette er hvor en utvikler kan virkelig bli kjent med programmet de utvikler; et sted å få det store bildet.
design På høyt og lavt nivå er arkitekturdokumentasjonen som viser hvordan komponentene i applikasjonen er koblet til. I design på høyt nivå vil vi legge ut eksterne avhengigheter og hvordan brukerne og / eller systemene vil samhandle med systemet vårt. Lavnivådesignet vil legge ut hvordan interne komponenter samhandler med hverandre. Gjennomgang av disse vil gi en annen utvikler en veldig rask forståelse av arbeidet i søknaden.
SRS, Eller Programvarekrav Spesifikasjon, er der utvikleren dokumenter hvordan programmet skal bygges. Dette er hvor tjenester er dokumentert, avhengigheter er lagt ut, og generelt hvordan koden skal fungere, basert på BRS som ble opprettet. Dette gjøres vanligvis før koden skrives og er en standardoppgave. Jeg vet at noen spør hvorfor vi trenger å gjøre dette. Koden min er selvdokumenterende. Og mens jeg er sikker på at det er, er koden spredt gjennom hundrevis av filer og tusenvis av kodelinjer. Og noen ganger er intensjonen ikke så klar som vi ønsker. SRS gir oss ett dokument å se på med en klar oversikt over hva vi kan forvente. Den skisserer brukstilfeller og forventet oppførsel i en konsekvent herregård.
etter at vi har definert hva vi skal gjøre, og deretter skrive koden, er det på tide å få noen til å vurdere hva vi gjorde. Skriv Inn Koden Gjennomgang. Dette er ikke bare en god praksis for å fange eventuelle feil og sikre at vi følger beste praksis og retningslinjer, det er en fin måte å dele hva programmet gjør. Bare å gjennomgå koden med et annet sett med øyne gir oss en annen person som er kjent med hvordan koden fungerer. Siden dette har blitt standard praksis på tvers av de fleste utviklingsteam, vil jeg ikke belabor denne.
Enhetstesting er et annet hovedopphold for de fleste utviklingsprogrammer. Enhetstesting enten det er Gjort som En Del Av Testdrevet Utvikling eller gjort etter at koden er skrevet, er en av de beste måtene å sikre at fremtidige endringer ikke innfører feil i koden vår. I en CI/CD-rørledning kan vi sørge for at alle tester passerer før vi tillater kode å bli sjekket inn. Dette hjelper oss å holde koden i god stand.
Individuelt er det verdi i hvert sett med dokumenter ovenfor, men de virkelige gevinsten begynner når du kan knytte all denne informasjonen sammen. I begynnelsen av kravinnsamlingsprosessen starter Vi En Kravsporbarhetsmatrise som gjør at vi kan knytte forretningskrav, programvarekrav, kode, enhetstester, testplaner og saker og brukeraksept sammen. Tenk deg seks måneder inn i et stort prosjekt, og en endring fører til at et testfall mislykkes. Vi kan nå gå tilbake til kravene, finne ut hva formålet med koden er, vet nøyaktig hvor koden er for den logikken, endre enhetstesten for å fange den nye saken, og implementere en løsning innen timer, ikke dager.
PÅ kort sikt KAN CMMI virke som overkill, men selv på små prosjekter forkorter kunnskapen ved å følge prosessen syklusen jo lenger du er borte fra prosjektet. For ikke å nevne om du aldri har jobbet med prosjektet før.
Utviklerstøtte
App Dev Kundesuksess Account Manager, Microsoft Developer Support
Følg