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

Costruirne uno da buttar via viene da "non sapere cosa non sai" all'inizio, quindi impari mentre vai a quello che avresti dovuto fare all'inizio.

Il secondo effetto di sistema viene da "ora sapendo ciò che non sapevi, ma non sapendo quello che ancora non conosci". Il secondo effetto del sistema deriva dal tentativo di costruire un sistema più grande, più lucido e più complesso del primo, senza le conoscenze necessarie all'inizio - sembra molto simile a quello che succede con il primo sistema.

Quindi il secondo effetto del sistema non è una contraddizione. Costruire un secondo sistema con le stesse funzionalità del primo è (a mia conoscenza) mai fatto. Il secondo sistema deve sempre essere "migliore", quindi più complesso, quindi sono previsti problemi sostanzialmente simili al primo sistema, che dovrebbero essere buttati via.

Quindi costruisci uno da buttare via, buttalo e costruiscilo di nuovo senza ampliamento dell'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 saltate diverse cose, quindi il sistema risultante è andato storto. Lasciatemi descrivere alcuni dei passaggi mancanti:

Gestione della qualità - Fai bene la prima volta! Non usare mai hack temporanei o compromessi temporanei. Non ci devono essere modifiche necessarie. 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 del progetto - Definisci chiaramente il tuo ambito iniziale, pianifica come verrà consegnata la soluzione, crei una linea di base, mantieni il piano. Non perdere tempo su tutto ciò che non è sul percorso critico.

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

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

Implementazione: codifica il software come nel progetto. Tutto il codice deve essere collegato ai componenti dalla SD.

Convalida - Test delle 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 di Ingegneria del software. Questo è il modo in cui costruisci la giusta soluzione software per le reali esigenze aziendali e la costruisci in tempo, a budget, alle specifiche.

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

• Analisi di fattibilità (in particolare come creare un caso aziendale)
• Gestione del progetto (in particolare Piano di progetto e Registro dei rischi con attenuazione del rischio)
• Ingegneria dei requisiti (elicitazione, analisi, specifica, convalida)
• Progettazione software (ingegneria del software basata su componenti e UML)
• Costruzione del software (schemi di progettazione, strutture, programmazione difensiva)
• Convalida del software (test dell'unità, UAT, ecc.)