Scomposizione del lavoro tracciabile
Ogni attività di implementazione è collegata a uno specifico requisito o criterio di accettazione — non a una descrizione della funzionalità vagamente correlata.
Sviluppo e Integrazione · Fase 04 · Come Lavoriamo
Una specifica diventa software.
La progettazione della soluzione produce una specifica testata e criteri di accettazione definiti. Questa fase trasforma quella specifica in software funzionante e verificato — integrato con i sistemi con cui deve operare e dimostrato conforme ai criteri definiti prima dell'inizio dello sviluppo.
Lo sviluppo qui non è interpretazione. Ogni decisione di implementazione risale a una specifica prodotta durante la progettazione — non a ciò che uno sviluppatore presumibilmente pensava fosse l'intento.
Non questa domanda
"Il codice funziona?"
Questa domanda, invece
"Il sistema costruito soddisfa i criteri di accettazione definiti prima di iniziare — in condizioni di integrazione reali, non solo isolatamente?"
Implementazione · Verifica · Integrazione · Tracciabilità · Disciplina di consegna
Perché lo sviluppo segue la progettazione
Niente di tutto ciò è frutto di congetture.
Ogni input per questa fase è stato prodotto durante la progettazione della soluzione: il documento di specifica della soluzione, il rapporto di valutazione del prototipo e i criteri di accettazione e il piano di test. Sviluppare a partire da una specifica non testata riporterebbe semplicemente nel codice di produzione il rischio che la prototipazione era destinata a eliminare.
Specifiche della Soluzione + Criteri di Accettazione → Implementazione Verificata
Perché la disciplina di consegna è importante
Velocità e stabilità vanno misurate insieme, non scambiate l'una con l'altra.
Le prestazioni di consegna del software non sono semplicemente una questione di quanto velocemente un team scrive codice. La ricerca di Forsgren, Humble e Kim — pubblicata in Accelerate: The Science of Lean Software and DevOps (2018), basata sul programma di ricerca pluriennale DevOps Research and Assessment (DORA) su migliaia di organizzazioni — ha identificato due categorie di prestazioni ingegneristiche che devono essere misurate congiuntamente: throughput e stabilità.
Lead time
Quanto tempo impiega una modifica validata a passare dal commit a uno stato distribuibile.
Forsgren, Humble & Kim, Accelerate (2018); DORA, ricerca State of DevOps.
Tasso di fallimento delle modifiche
La percentuale di modifiche che introducono un difetto che richiede interventi correttivi.
Forsgren, Humble & Kim, Accelerate (2018); DORA, ricerca State of DevOps.
Un team che rilascia rapidamente ma rompe frequentemente le cose non performa bene secondo questa ricerca — così come non performa bene un team che rilascia in modo sicuro ma troppo lentamente per avere impatto. OpenQCore considera entrambe le dimensioni in questa fase, invece di ottimizzare solo la velocità.
Dalla specifica all'implementazione
Ogni attività lavorativa è riconducibile a un requisito.
Il lavoro di implementazione viene scomposto direttamente dalla Specifica della Soluzione e dai Criteri di Accettazione — non da una comprensione generale di ciò che il progetto "intendeva ottenere."
Definizione del completamento
Un'attività non è completata quando il codice è stato scritto. È completata quando soddisfa, sotto test, il criterio di accettazione a cui è collegata.
Controllo della deriva delle specifiche
Quando l'implementazione rivela una lacuna o un'ambiguità nella specifica, la specifica viene aggiornata e rivista — non reinterpretata silenziosamente da chi sta scrivendo il codice quel giorno.
Verifica guidata dai test
La verifica avviene a ogni livello, non solo alla fine.
OpenQCore struttura la verifica secondo la piramide dei test — un framework ampiamente utilizzato, reso popolare da Mike Cohn, per bilanciare la copertura dei test tra i livelli di un sistema anziché concentrarla in test end-to-end lenti e costosi.
Test unitari
Verifica rapida e isolata dei singoli componenti rispetto al comportamento specificato — incluso il loro comportamento con input non validi.
Test di integrazione
Verifica che i componenti interagiscano correttamente secondo i contratti di dati definiti durante la progettazione della soluzione.
Test end-to-end
Verifica dei flussi di lavoro completi rispetto ai criteri di accettazione definiti prima dell'inizio dello sviluppo — il livello più ristretto e più costoso, riservato a ciò che lo richiede davvero.
L'obiettivo non è il numero massimo di test. È la certezza che i criteri di accettazione siano effettivamente soddisfatti, al livello a costo più basso in grado di dimostrarlo.
Test di integrazione e dei contratti
Un contratto API è reale solo se viene testato, non solo documentato.
I contratti di dati e API specificati durante la Progettazione della Soluzione non sono trattati come documentazione da seguire in modo informale. OpenQCore applica il testing dei contratti guidato dal consumer — un approccio formalizzato in strumenti come Pact — in cui ogni punto di integrazione viene verificato rispetto a un contratto eseguibile che entrambe le parti dell'integrazione devono soddisfare.
Questo è particolarmente importante per i sistemi che devono connettersi all'infrastruttura esistente: un contratto verificato solo tramite revisione manuale può deviare silenziosamente quando una delle parti cambia. Un contratto che viene testato automaticamente non può deviare silenziosamente.
Revisione del codice e verifica statica
Un secondo revisore rileva ciò che l'autore non riesce a vedere.
Ricerche ampiamente citate sulla revisione del codice tra pari — incluso lo studio condotto presso Cisco Systems e reso noto da Cohen et al. in Best Kept Secrets of Peer Code Review — hanno rilevato che l'efficacia della revisione dipende fortemente da ritmo e portata: revisioni più piccole e più frequenti, eseguite senza pressione temporale, individuano sostanzialmente più difetti rispetto a revisioni ampie svolte rapidamente.
OpenQCore applica una revisione del codice strutturata insieme ad analisi statica automatizzata — controllo dello stile, della complessità e scansione delle vulnerabilità note — come livello di verifica permanente, non come passaggio facoltativo di cortesia prima del merge.
Pipeline di integrazione continua
Ogni modifica viene verificata nello stesso modo, automaticamente.
Commit → Build automatizzato → Test unitari e di integrazione → Analisi statica e di sicurezza → Verifica dei contratti → Pronto per il deployment.
La verifica manuale e incoerente non scala e non fornisce un segnale affidabile sul fatto che una modifica sia effettivamente sicura da rilasciare — una determinazione presa nella fase successiva, Distribuzione e Abilitazione. Ciò che questa fase garantisce è che una modifica che raggiunge quella soglia sia già stata verificata rispetto allo stesso standard automatizzato di ogni modifica precedente.
Pratiche di sviluppo sicuro
La sicurezza viene verificata durante lo sviluppo, non controllata successivamente.
Le pratiche di sviluppo di OpenQCore sono allineate alla struttura descritta nel Secure Software Development Framework (SP 800-218) del NIST — organizzando le attività di sicurezza attorno alla preparazione dell'organizzazione, alla protezione del software, alla produzione di software ben protetto e alla risposta alle vulnerabilità.
Scansione delle dipendenze e delle vulnerabilità
Scansione automatizzata delle dipendenze di terze parti per vulnerabilità conosciute come parte della pipeline standard, non un controllo manuale periodico.
Modellazione delle minacce
Considerazione strutturata di come un componente potrebbe essere utilizzato in modo improprio, informata dai modi di guasto definiti durante la progettazione della soluzione.
Implementazione del principio del minimo privilegio
Ambiti di accesso e permessi implementati al livello più ristretto che soddisfa la specifica — non al livello più ampio che è comodo.
Il Gate di verifica dell'integrazione
Una build non è pronta solo perché compila.
Ogni modifica raggiunge un gate di verifica definito prima di poter essere considerata per il rilascio.
Pronto per il rilascio
Tutti i criteri di accettazione sono soddisfatti e verificati tramite test automatizzati, verifiche dei contratti e scansioni di sicurezza.
Ritorno per correzioni
I difetti specifici identificati devono essere risolti prima che questa modifica possa procedere.
Ritorno alla progettazione
L'implementazione ha rivelato che la specifica stessa non regge nelle condizioni reali — la risposta corretta è rivedere la specifica, non aggirarla con codice.
Escalation del rischio
È stato identificato un rischio di sicurezza, di conformità o architetturale che richiede una decisione al di sopra dell'autorità del team di sviluppo.
Una pipeline che raggiunge sempre "pronta per il rilascio" non verifica nulla.
Cosa produce questa fase
Software pronto per la decisione di rilascio — non ancora rilasciato.
A seconda dell'ambito dell'impegno, questa fase produce:
Codebase verificata
Implementazione tracciabile alla specifica, che supera tutti i livelli di verifica definiti.
Report di copertura dei test
Risultati dei test unitari, di integrazione e end-to-end mappati ai criteri di accettazione.
Suite di test dei contratti
Verifica eseguibile di ogni punto di integrazione definito durante la progettazione della soluzione.
Cronologia delle revisioni del codice
Cronologia delle revisioni documentata e risoluzione dei problemi segnalati.
Risultati della scansione di sicurezza
Rilevamenti su dipendenze, vulnerabilità e analisi statica e le relative risoluzioni.
Documentazione della pipeline CI
La pipeline di verifica automatizzata applicata a questa modifica e a tutte le modifiche successive.
Dallo sviluppo alla distribuzione e abilitazione
Il software verificato non è ancora software in produzione.
Lo sviluppo e l'integrazione producono software che è stato verificato rispetto alla sua specifica — non software che è stato rilasciato, monitorato o dimostrato stabile sotto il carico reale di produzione. La fase successiva disciplina come, quando e con quale sicurezza quel software raggiunge effettivamente la produzione.
Specifiche della soluzione → Implementazione verificata → Distribuzione e abilitazione
Fase 05
Distribuzione e abilitazione
Rilasciare il software verificato in produzione in modo sicuro, deliberato e con un percorso definito per il rollback.
Riferimenti di ricerca e metodologici
Forsgren, N., Humble, J. e Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, ricerca DORA sullo stato del DevOps
Fonte delle metriche di performance di delivery citate sopra.
Cohn, M. — Succeeding with Agile (2009)
Fonte del concetto della piramide dei test citato nella verifica guidata dai test sopra.
Cohen, J. et al. — Best Kept Secrets of Peer Code Review (SmartBear, basato su ricerche presso Cisco Systems)
Fonte dei risultati sull'efficacia delle revisioni del codice citati sopra.
Pact / Contratti guidati dal consumatore
Un approccio consolidato ai contratti di integrazione eseguibili e verificati automaticamente, citato nella sezione sui test di integrazione sopra.
NIST — Secure Software Development Framework, SP 800-218
Fonte della struttura citata nelle pratiche di sviluppo sicuro sopra.