Costruisci uno da buttare via contro l'effetto del secondo sistema

Da un lato c'è un consiglio che dice "Costruisci uno da buttare via". Solo dopo aver finito un sistema software e aver visto il prodotto finale, ci rendiamo conto di cosa è andato storto in fase di progettazione e comprendiamo come avremmo dovuto farlo davvero.

D'altra parte c'è "l'effetto del secondo sistema" che dice che il secondo sistema dello stesso tipo che è progettato è di solito peggiore del primo; ci sono molte funzionalità che non si adattavano al primo progetto e che sono state inserite nella seconda versione, portando in genere a eccessivamente complesse e eccessivamente progettate.

Non è qui una contraddizione tra questi principi? Qual è la visione corretta dei problemi e dov'è il confine tra questi due?

Credo che queste "buone pratiche" siano state inizialmente promosse nel libro fondamentale The Mythical Man-Month di Fred Brooks.

So che alcuni di questi problemi sono risolti dalle metodologie Agile, ma in fondo il problema è che i principi sono ancora validi; ad esempio, non vorremmo apportare modifiche importanti al design 3 sprint prima di andare in diretta.

Costruire uno da buttare via deriva dal "non sapere cosa non sai" all'inizio, quindi impari mentre vai avanti cosa avresti dovuto fare all'inizio.

Il secondo effetto di sistema proviene da "ora sapendo ciò che non sapevi, tuttavia non sapendo ciò che ancora non sai", vale a dire il secondo effetto di sistema deriva dal tentativo di costruire un sistema più grande, più lucido, più complesso del primo, a insaputa necessario all'inizio - sembra molto simile a ciò che accade con il primo sistema.

Pertanto l'effetto del secondo sistema non è contraddizione. Costruire un secondo sistema con le stesse funzionalità del primo è (per quanto ne sappia) mai fatto. Il secondo sistema deve sempre essere "migliore", quindi più complesso, quindi si prevedono problemi sostanzialmente simili al primo sistema, che dovrebbero essere eliminati.

Quindi creane uno da buttare via, gettalo e ricostruiscilo senza allargare l'ambito, e non avrai un secondo problema di sistema. (Questo tende ad essere fatto più spesso su pianeti con cieli viola, mari rosa e maiali volanti.)

Il problema a cui ti riferisci significa che sono state saltate diverse cose, quindi il sistema risultante è andato storto. Vorrei descrivere alcuni dei passaggi mancanti:

Gestione della qualità: fallo bene la prima volta! Non usare mai hack temporanei o compromessi temporanei. Non devono essere necessarie rilavorazioni. Tutte le risorse sono utilizzate in modo efficiente e tutto ciò che fai è un contributo adeguato al progetto.

Analisi di fattibilità - Scopri le esigenze aziendali. Crea un business case per il progetto.

Piano di progetto: definire chiaramente l'ambito iniziale, pianificare come verrà consegnata la soluzione, creare una linea di base, attenersi al piano. Non perdere tempo su tutto ciò che non è sul percorso critico.

Ingegneria dei requisiti - Requisiti aziendali espliciti (ad esempio acquisizione di processi aziendali e determinazione delle operazioni aziendali che devono essere supportate dal sistema computerizzato, traduzione delle operazioni aziendali 1: 1 in casi d'uso del sistema). Convalida e verifica! (stiamo costruendo la cosa giusta? Stiamo costruendo la cosa giusta?) Tutti i requisiti devono essere collegati alle esigenze aziendali originali.

Progettazione software - Traduci i casi d'uso e il modello di dominio in progettazione di componenti e architettura di soluzioni. Tutti i componenti devono essere collegati ai requisiti di RE.

Implementazione: codifica il software come nella progettazione. Tutto il codice deve essere collegato ai componenti da SD.

Convalida - Test di unità, test di integrazione, prestazioni, ... (tutti i casi d'uso di RE dovranno ora essere testati)

Questi sono alcuni aspetti chiave di un processo software. Le attività menzionate fanno parte dell'ingegneria del software. È così che costruisci la giusta soluzione software per le reali esigenze aziendali e la costruisci in tempo, budget, su specifica.

Cerca questi termini per creare un software migliore e farlo bene la prima volta:

• Analisi di fattibilità (in particolare come costruire un caso aziendale)
• Gestione del progetto (in particolare piano di progetto e registro dei rischi con attenuazione dei rischi)
• Ingegneria dei requisiti (elicitazione, analisi, specifica, validazione)
• Software Design (UML e ingegneria del software basata su componenti)
• Costruzione di software (modelli di progettazione, framework, programmazione difensiva)
• Convalida del software (unit test, UAT, ecc.)