Dezvoltator
8 mai, 2020
App Dev Manager darroll Walsh împărtășește O introducere în dezvoltarea CMMI pentru dezvoltatori.
Capability Maturity Model Integrated (CMMI) este un program de îmbunătățire și evaluare a proceselor care se integrează cu alte programe de îmbunătățire a proceselor, cum ar fi Project Management Body Of Knowledge (PMBOK) și Agile. Funcționează pentru a eficientiza și standardiza toate procesele și pentru a oferi un mijloc de supraveghere și metrici acționabile pentru dezvoltare, servicii, gestionarea furnizorilor, maturitate Cibernetică și altele.
ceea ce vreau să fac este să ofere o imagine de ansamblu a CMMI Dev din perspectiva unui dezvoltator. Vom sări peste managementul de proiect, analistul de afaceri, managementul configurației și testarea porțiunilor CMMI DEV pentru a ne concentra asupra impactului CMMI asupra unei echipe de dezvoltare. Dacă există interes pentru celelalte roluri sau capacități, acesta poate fi un subiect bun pentru o intrare ulterioară pe blog. Rețineți că există o mulțime de lucruri care se întâmplă înainte ca dezvoltatorii să înceapă, chiar și în dezvoltarea agilă.
să începem:
BRS, sau cerințele de afaceri Caietul de sarcini este în cazul în care totul începe, Aceasta este singura sursă de adevăr. Aici sunt cerințele de afaceri pe care proprietarul produsului le semnează. În timp ce dezvoltatorii pot fi consultați cu privire la crearea BRS, aceasta este în principal responsabilitatea BA. cu toate acestea, aici un dezvoltator poate cunoaște cu adevărat aplicația pe care o dezvoltă; un loc pentru a obține imaginea de ansamblu.
modele de nivel înalt și de nivel scăzut este documentația de arhitectură care arată modul în care sunt conectate componentele aplicației. În proiectarea la nivel înalt, vom stabili dependențele externe și modul în care utilizatorii și/sau sistemele vor interacționa cu sistemul nostru. Designul de nivel scăzut ar stabili modul în care componentele interne interacționează între ele. Revizuirea acestora ar oferi unui alt dezvoltator o înțelegere foarte rapidă a funcționării aplicației.
SRS, sau specificația cerințelor Software, este locul în care dezvoltatorul documentează modul în care va fi construită aplicația. Aici sunt documentate serviciile, sunt stabilite dependențele și, în general, modul în care se presupune că funcționează codul, pe baza BRS care a fost creat. Acest lucru se face de obicei înainte de scrierea codului și este o sarcină standard. Știu că unii se întreabă de ce ar trebui să facem asta. Codul meu se auto-documentează. Și în timp ce eu sunt sigur că este, codul este răspândit prin sute de fișiere și mii de linii de cod. Și uneori intenția nu este atât de clară pe cât ne-am dori. SRS ne oferă un document la care să ne uităm cu o schiță clară a ceea ce ne putem aștepta. Acesta prezintă cazurile de utilizare și comportamentul așteptat într-un conac consistent.
după ce definim ce vom face și apoi scriem codul, este timpul ca cineva să revizuiască ceea ce am făcut. Introduceți revizuirea Codului. Aceasta nu este doar o bună practică pentru a prinde orice greșeli și pentru a ne asigura că urmăm cele mai bune practici și orientări, ci este o modalitate excelentă de a împărtăși ceea ce face aplicația. Simplul act de revizuire a codului printr-un al doilea set de ochi ne oferă o a doua persoană care este familiarizată cu modul în care funcționează codul. Deoarece aceasta a devenit o practică standard în majoritatea echipelor de dezvoltare, nu o voi face pe aceasta.
testarea unității este o altă ședere principală a majorității programelor de dezvoltare. Testarea unitară, indiferent dacă este efectuată ca parte a dezvoltării bazate pe teste sau după scrierea codului, este una dintre cele mai bune modalități de a vă asigura că modificările viitoare nu introduc erori în codul nostru. Într-o conductă CI/CD ne putem asigura că toate testele trec înainte de a permite verificarea codului. Acest lucru ne ajută să păstrăm codul în stare bună de funcționare.
individual există valoare în fiecare set de documente de mai sus, cu toate acestea, câștigurile reale încep atunci când puteți lega toate aceste informații împreună. La începutul procesului de colectare a cerințelor, începem o matrice de trasabilitate a cerințelor care ne permite să legăm împreună cerințele de afaceri, cerințele software, codul, testele unitare, planurile și cazurile de testare și acceptarea utilizatorilor. Imaginați-vă șase luni într-un proiect mare și o schimbare face ca un caz de testare să eșueze. Acum ne putem întoarce la cerințe, să aflăm care este scopul acelui cod, să știm exact unde este codul pentru acea logică, să modificăm testul unitar pentru a prinde noul caz și să implementăm o remediere în câteva ore, nu Zile.
pe termen scurt, CMMI poate părea excesiv, dar chiar și pe proiecte mici, cunoștințele capturate urmând procesul scurtează ciclul cu cât sunteți mai departe de proiect. Ca să nu mai vorbim dacă nu ați mai lucrat niciodată la proiect.
Suport Pentru Dezvoltatori
Manager De Cont Pentru Succesul Clienților App Dev, Suport Pentru Dezvoltatori Microsoft
Urmați