Sviluppatore
8 Maggio, 2020
App Dev Manager Darroll Walsh condivide un’introduzione allo sviluppo CMMI per gli sviluppatori.
Il Capability Maturity Model Integrated (CMMI) è un programma di miglioramento e valutazione dei processi che si integra con altri programmi di miglioramento dei processi come il Project Management Body of Knowledge (PMBOK) e Agile. Funziona per semplificare e standardizzare tutti i processi e fornire un mezzo per avere supervisione e metriche attuabili per lo sviluppo, i servizi, la gestione dei fornitori, la maturità informatica e altri.
Quello che voglio fare è fornire una panoramica di CMMI Dev dal punto di vista di uno sviluppatore. Salteremo le parti di project management, business analyst, configuration management e testing di CMMI DEV per concentrarci sull’impatto di CMMI su un team di sviluppo. Se c’è interesse per gli altri ruoli o capacità che può essere un buon argomento per un post successivo blog. Basta notare che c’è molto lavoro che accade prima che gli sviluppatori inizino, anche nello sviluppo Agile.
Cominciamo:
Il BRS, o requisiti di business Specifica è dove tutto inizia, questa è l’unica fonte di verità. Questo è dove i requisiti di business che il proprietario del prodotto firma fuori su. Mentre gli sviluppatori possono essere consultati sulla creazione del BRS, questa è principalmente la responsabilità di BA. Tuttavia, questo è dove uno sviluppatore può davvero conoscere l’applicazione che stanno sviluppando; un posto per ottenere il quadro generale.
High-level e Low-level designs è la documentazione dell’architettura che mostra come i componenti dell’applicazione sono collegati. Nel design di alto livello, avremmo delineato le dipendenze esterne e il modo in cui gli utenti e/o i sistemi interagiranno con il nostro sistema. Il design di basso livello avrebbe stabilito come i componenti interni interagiscono tra loro. Rivedere questi darebbe un altro sviluppatore una comprensione molto rapida del funzionamento dell’applicazione.
Il SRS, o Requisiti Software Specifica, è dove lo sviluppatore documenta come l’applicazione sta per essere costruito. Questo è dove i servizi sono documentati, le dipendenze sono disposte e in generale come dovrebbe funzionare il codice, in base al BRS che è stato creato. Questo viene in genere fatto prima che il codice sia scritto ed è un’attività standard. So che alcuni si chiedono perché dovremmo farlo. Il mio codice si sta auto-documentando. E mentre sono sicuro che lo sia, il codice viene diffuso attraverso centinaia di file e migliaia di righe di codice. E a volte l’intenzione non è così chiara come vorremmo. L’SRS ci dà un documento da guardare con un chiaro profilo di ciò che possiamo aspettarci. Delinea i casi d’uso e il comportamento previsto in un maniero coerente.
Dopo aver definito ciò che stiamo per fare, e quindi scrivere il codice, è il momento di avere qualcuno rivedere quello che abbiamo fatto. Inserisci la revisione del codice. Questa non è solo una buona pratica per catturare eventuali errori e garantire che stiamo seguendo le migliori pratiche e linee guida, è un ottimo modo per condividere ciò che l’applicazione sta facendo. Il semplice atto di rivedere il codice con una seconda serie di occhi ci dà una seconda persona che ha familiarità con il funzionamento del codice. Poiché questo è diventato una pratica standard nella maggior parte dei team di sviluppo, non lo farò.
Unit Testing è un altro soggiorno principale della maggior parte dei programmi di sviluppo. Unit testing se fatto come parte di Test Driven Development o fatto dopo che il codice è stato scritto, sono uno dei modi migliori per assicurarsi che le modifiche future non introducono errori nel nostro codice. In una pipeline CI / CD possiamo assicurarci che tutti i test passino prima di consentire il check-in del codice. Questo ci aiuta a mantenere il codice in buone condizioni.
Individualmente c’è valore in ogni set di documenti sopra, tuttavia, i guadagni reali iniziano quando puoi legare tutte queste informazioni insieme. All’inizio del processo di raccolta dei requisiti, iniziamo una matrice di tracciabilità dei requisiti che ci consente di collegare i requisiti aziendali, i requisiti software, il codice, i test unitari, i piani e i casi di test e l’accettazione degli utenti. Immagina sei mesi in un grande progetto e un cambiamento causa il fallimento di un test case. Ora possiamo tornare ai requisiti, scoprire qual è lo scopo di quel codice, sapere esattamente dove si trova il codice per quella logica, modificare il test unitario per catturare il nuovo caso e implementare una correzione in poche ore, non giorni.
A breve termine, CMMI può sembrare eccessivo, ma anche su piccoli progetti, la conoscenza acquisita seguendo il processo accorcia il ciclo più a lungo si è lontani dal progetto. Per non parlare se non hai mai lavorato al progetto prima.
Developer Support
App Dev Successo del cliente Account Manager, Microsoft Developer Support
Seguire