OO Analysis and Design

Le applicazioni software enterprise strategiche sono molto spesso applicazioni che hanno un ciclo di vita medio/lungo. Quelle che realizziamo in CGN hanno appunto queste caratteristiche, poiché, tranne poche eccezioni, la loro vita non è breve e spesso coincide con quella della corrispondente pratica o normativa prevista dagli enti interessati (Agenzia delle Entrate, INPS, ecc.)
Questo è un aspetto molto importante perché il software, a differenza di molti altri prodotti ingegneristici, ha l'intrinseca caratteristica di cambiare durante il suo ciclo di vita: vengono richiesti infatti modifiche alle funzionalità già supportate oppure ampliamenti con nuove caratteristiche da offrire all'utente.

Ciò che serve, quindi, per governare i cambiamenti del software, senza far scadere progressivamente la qualità e la manutenibilità, è acquisire dei principi e degli strumenti concettuali e tecnici adatti. – ALBERTO TRONCHIN - IT Board e Scrum Master

Sono questi strumenti che permettono di risolvere, ma anche di prevenire, le problematiche strutturali che inevitabilmente si presentano quando si deve intervenire su una base di codice esistente.
È importante che la struttura iniziale di nuove applicazioni sia progettata in origine per permettere rapidi e agevoli interventi strutturali successivi.
Una buona progettazione parte quindi dall’adozione di tecniche di analisi e design che prima di tutto aiutino il team a fare chiarezza sul cosiddetto “spazio del problema” e poi supportino la fase di definizione di quel modello di dominio che meglio di altri si presta a supportare la soluzione applicativa.
L’esperienza maturata negli anni ci ha dimostrato che l’uso avveduto di tecniche e modelli a basso carico cognitivo (User Story Mapping, Impact Mapping, Event Storming) facilita la fase di emersione e condivisione della conoscenza e il chiarimento dei veri bisogni degli utenti, specialmente quando chi partecipa al progetto, come utente o come esperto di dominio, non ha nessun background tecnico-ingegneristico, ma una forte competenza sul dominio specifico oppure, cosa non trascurabile, conosce i propri bisogni. Citando Alberto Brandolini, "Non è la conoscenza dell’esperto di dominio che finisce in produzione nelle mani degli utenti, ma quello che il team di sviluppo ha capito".
Quindi, tutto ciò che aiuta il team a comprendere quello che dovrà poi implementare non solo è importante, ma è essenziale.
In fase di design, abbiamo sperimentato che l'approccio object oriented, l'adozione di paradigmi quali il Domain Driven Design e il ricorso a design pattern ricorrenti producono i migliori risultati proprio quando si affrontano domini complessi e si realizzano applicazioni effettivamente di livello enterprise (citando M.Fowler, "Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data").