Progettazione della soluzione · Fase 03 · Come lavoriamo
Strategia e architettura definiscono come un sistema debba essere strutturato. La Progettazione della Soluzione determina esattamente cosa viene costruito — i flussi di lavoro specifici, le interfacce, i contratti dei dati e i comportamenti in caso di guasto che trasformano una direzione progettuale in qualcosa che un team può effettivamente costruire.
Questa fase non inizia con un'implementazione. Inizia con una specifica che è stata verificata con evidenze prima che venga scritta una sola riga di codice di produzione.
Questa non è la domanda
"Cosa dovremmo costruire?"
Questa domanda, invece
"Questo specifico progetto si comporta davvero come ci aspettiamo, nelle condizioni che incontrerà effettivamente — e possiamo dimostrarlo prima di impegnare risorse di ingegneria per costruirlo?"
Progettare · Prototipare · Testare · Misurare · Specificare
Perché il design segue l'architettura
L'architettura di riferimento della fase precedente definisce livelli, scelte tecnologiche e aspetti trasversali. Non definisce ancora come dovrebbe comportarsi uno specifico flusso di lavoro quando una richiesta è ambigua, né cosa succede quando un'integrazione restituisce dati malformati. La progettazione della soluzione colma questa lacuna — senza di essa, "architettura" rimane un diagramma, non un sistema.
Architettura di riferimento → Specifica della soluzione
Perché il rigore nella progettazione conta
La ricerca di Barry Boehm sull'economia dell'ingegneria del software — pubblicata per la prima volta nel 1976 e ampliata nel suo libro del 1981 Software Engineering Economics — ha rilevato che il costo per correggere un difetto aumenta considerevolmente più tardi esso viene scoperto.
~1×
Costo per correggere un difetto individuato durante la progettazione.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
10×–100×
Costo per correggere lo stesso difetto dopo il rilascio in produzione, variabile in base alla scala del progetto.
Boehm, Software Engineering Economics (1981); Boehm & Basili, IEEE Computer (2001).
Questa conclusione è stata rivista nel tempo. La revisione del 2001 degli stessi Boehm e Basili ha rilevato che la curva è significativamente più piatta per team più piccoli che iterano rapidamente e dispongono di solide pratiche di testing e consegna continua. Il moltiplicatore non è universale, e noi non lo trattiamo come tale.
Ma la direzione della scoperta non è stata smentita: individuare un difetto di progettazione prima che venga costruito è meno costoso che trovarlo dopo. Per questo OpenQCore considera prototipazione e testing parte integrante della progettazione stessa — non una fase che avviene dopo che la costruzione è già iniziata.
Dall'architettura alla specifica
Ogni decisione architetturale della fase precedente viene scomposta in specifiche concrete.
La sequenza esatta di passi, punti decisionali, eccezioni e passaggi che una soluzione deve supportare — basata sul Modello del flusso di lavoro dello Stato Attuale prodotto durante la discovery, non su un processo ideale reimmaginato.
Ciò che ogni utente, sistema o agente effettivamente vede, invia e riceve — schermate, flussi conversazionali, contratti API e i campi rilevanti in ogni passo.
La forma esatta, le regole di validazione, l'approccio alla gestione delle versioni e la proprietà dei dati che si spostano tra i componenti.
Cosa fa il sistema — e cosa esplicitamente non fa — in condizioni normali, nei casi limite e nelle condizioni di guasto.
Output
Specifica della soluzione (Bozza)
Progettazione del flusso di lavoro e delle interazioni
Un'interfaccia conversazionale sovrapposta a un flusso di lavoro difettoso non risolve il flusso — lo nasconde, finché il vincolo sottostante non riemerge altrove.
La Solution Design parte dalle evidenze sul flusso di lavoro raccolte durante la discovery e pone una domanda strutturale prima di una domanda di interfaccia: quali passaggi di questo processo dovrebbero essere automatizzati, quali dovrebbero rimanere umani, e dove esattamente avviene il trasferimento di responsabilità tra loro? Mappiamo questo in modo esplicito, così che i punti human-in-the-loop siano una decisione di progettazione deliberata — non il risultato fortuito delle capacità tecnologiche disponibili.
Punti di controllo espliciti in cui la revisione, il giudizio o l'autorizzazione umana sono richiesti per progettazione — non per omissione.
Limiti definiti con precisione su ciò che un sistema è autorizzato a decidere o eseguire senza l'approvazione umana.
Percorsi progettati per i casi che esulano dalla gestione normale — non fallimenti silenziosi né ripiegamenti predefiniti.
Prototipazione e sperimentazione
OpenQCore considera il design nelle fasi iniziali allo stesso modo in cui la design science considera un artefatto dei sistemi informativi: qualcosa costruito appositamente per poter essere valutato rispetto a un problema reale, e non semplicemente ammirato per la sua eleganza. Questo approccio — formalizzato nell'influente Design Science in Information Systems Research di Hevner et al. (MIS Quarterly, 2004) — tratta l'artefatto e la sua valutazione come inseparabili. Applichiamo lo stesso ragionamento guidato da ipotesi utilizzato durante la discovery anche a livello di design.
Una decisione progettuale specifica e falsificabile — non un'indicazione vaga.
Una rappresentazione funzionante sufficiente per testare la decisione — non necessariamente pronta per la produzione.
Input reali o realisticamente rappresentativi, non esempi idealizzati scelti per avere successo.
Confronto con la linea di base e i criteri di successo stabiliti durante la discovery — non un'impressione soggettiva della qualità.
Il design viene mantenuto, modificato o abbandonato in base a quanto mostrato dal test — non in base a quanto lavoro è già stato svolto.
L'obiettivo di un prototipo non è dimostrare che un design possa funzionare. È determinare se lo fa in modo affidabile, nelle condizioni che il sistema definitivo dovrà effettivamente affrontare.
Specifiche di dati e interfaccia
I fallimenti di integrazione raramente derivano da una singola decisione evidentemente sbagliata. Tendono a nascere dall'ambiguità — un campo ritenuto sempre presente, un caso di errore che nessuno ha annotato, una discrepanza di versione che nessuno aveva previsto.
Questo è un lavoro deliberatamente poco appariscente. È anche il lavoro che determina se un sistema che funziona bene in una demo continuerà a funzionare bene in produzione, dopo sei integrazioni e diciotto mesi.
Progettare per il fallimento, non solo per il successo
La maggior parte dei fallimenti di progettazione non sono fallimenti del percorso ideale. Sono fallimenti di ciò che accade quando qualcosa va storto — un sistema a monte va in timeout, un documento non viene estratto correttamente, un modello è incerto, un utente compie un'azione inattesa. OpenQCore progetta deliberatamente queste condizioni invece di scoprirle in produzione.
Cosa fa il sistema quando la fiducia in un output è bassa — incluso se e come lo comunica.
Quali funzionalità rimangono disponibili quando una dipendenza fallisce, invece di un'interruzione dell'intero sistema.
Le condizioni specifiche in cui un caso viene assegnato a un operatore umano e quale contesto accompagna tale passaggio.
Come si comporta il sistema con input malformati, sequenze inaspettate o tentativi di uso improprio — non solo con richieste ben formate.
Un sistema a cui non è mai stato chiesto "cosa succede quando questo fallisce?" non è stato veramente progettato. È stato solo dimostrato.
Criteri di validazione definiti prima della costruzione
In linea con il principio stabilito durante la fase di discovery — che il successo deve essere definito prima dell'implementazione — la progettazione della soluzione produce criteri di accettazione espliciti e scritti e un piano di test prima dell'inizio dello sviluppo in produzione.
Ciò che la soluzione deve fare correttamente, espresso in termini verificabili.
In linea con le caratteristiche di qualità del software riconosciute — inclusi efficienza delle prestazioni, affidabilità, usabilità, sicurezza e manutenibilità, come organizzato dal modello di qualità del prodotto software ISO/IEC 25010 — specificati come obiettivi misurabili piuttosto che come aspirazioni generali.
Gli scenari specifici, i set di dati e le condizioni contro cui la soluzione verrà valutata prima di considerarla pronta per la realizzazione in produzione.
Il gate di revisione del design
Questa pratica ha precedenti: il metodo formale di ispezione del design e del codice di Michael Fagan, introdotto in IBM nel 1976, ha stabilito che una revisione strutturata basata su criteri individua i difetti prima e in modo più affidabile rispetto all'approvazione informale. OpenQCore applica lo stesso principio alla progettazione della soluzione.
La specifica è sufficientemente precisa, il prototipo ha soddisfatto i criteri di valutazione e lo sviluppo può iniziare.
La direzione di fondo è solida, ma elementi specifici devono essere rivisti in base a quanto emerso dai test.
Il lavoro di progettazione ha rivelato un vincolo che l'architettura non aveva previsto — la risposta appropriata è rivedere la struttura, non progettare aggirando il vincolo.
Il lavoro di design ha evidenziato un rischio — tecnico, operativo, di sicurezza o etico — che richiede una decisione al di sopra dell'autorità del team di design prima di procedere.
Un gate di design che dice sempre sì non è un gate.
Cosa produce la progettazione della soluzione
A seconda dell'ambito dell'incarico, questa fase produce:
Flussi di lavoro, interfacce, contratti dei dati e comportamento, con dettagli sufficienti per costruire senza dover rideterminare l'intento.
Rappresentazioni visive del flusso dei processi, compresi i punti espliciti con intervento umano.
Schemi, regole di validazione e strategia di gestione delle versioni per ogni interfaccia tra componenti.
Cosa è stato testato, rispetto a quale baseline, e cosa i risultati confermano o escludono.
Condizioni di guasto documentate e la risposta del sistema progettata per ciascuna.
Le condizioni specifiche e misurabili che la soluzione realizzata deve soddisfare prima del rilascio.
Dalla progettazione allo sviluppo e all'integrazione
La progettazione della soluzione produce una specifica testata e validata — non un sistema finito. La fase successiva trasforma quella specifica in software funzionante, integrato con i sistemi con cui deve operare.
Specifiche della soluzione → Valutazione del prototipo → Criteri di accettazione → Sviluppo e integrazione
Fase 04
Costruire la soluzione specificata in base ai criteri di accettazione definiti — non su ipotesi.
Riferimenti di ricerca e metodologici
Boehm, B. — Software Engineering Economics (1981); Boehm, B. & Basili, V. — "Software Defect Reduction Top 10 List," IEEE Computer (2001)
Fonte delle conclusioni sul costo del cambiamento citate sopra, inclusa la revisione successiva che mostra una curva più piatta per team più piccoli e che iterano rapidamente.
Hevner, A., March, S., Park, J., & Ram, S. — "Design Science in Information Systems Research," MIS Quarterly (2004)
Quadro fondamentale per considerare un artefatto dei sistemi informativi e la sua valutazione come inseparabili — la base per il ciclo prototipo-test-affinamento descritto sopra.
Fagan, M. — "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal (1976)
Origine della revisione strutturata della progettazione basata su criteri come pratica ingegneristica formale, citata nel 'Design Review Gate' sopra.
ISO/IEC 25010:2011 — Systems and Software Quality Requirements and Evaluation (SQuaRE) — System and Software Quality Models
Fonte delle caratteristiche di qualità non funzionali citate nei criteri di accettazione sopra.
