Queste tre parole sono forse le più importanti che si possano incontrare nel mondo dell'informatica, così come in quello dell'ingegneria tutta. Infatti, facendo scorrere lo sviluppo di un qualsiasi prodotto attraverso queste tre fasi è possibile affrontare in maniera logica e razionale problemi anche di vaste dimensioni.
L'Analisi consiste nello studiare il problema che si vuole risolvere focalizzando l'attenzione solo sul problema. Non si deve pensare in alcun modo a come risolverlo, ma si deve essere sicuri di sapere cosa ci proponiamo di realizzare, di aver esplorato per bene le conseguenze che ciascun problema porta e, soprattutto, di aver ben chiare le esigenze da soddisfare. Per concludere questa fase, si deve essere capaci di esprimere il problema attraverso le paroline magiche "should", "would" e "could". Questa fase è anche chiamata dominio del problema perchè si dovrebbe riuscire a costruire un modello della realtà da imitare quanto più conciso possibile senza però filtrare dettagli fondamentali per capire la natura del problema stesso.
Il secondo passo è quello della Progettazione, o dominio della soluzione. Qui si pensa esclusivamente al come risolvere i problemi individuati nella fase precedente. Non confondere questa fase dalla successiva è molto difficile perchè si è portati ad usare concetti tipici dell'Implementazione in fase di Progettazione.
Infine*, viene l'Implementazione, la fase in cui si passa alla scrittura effettiva del codice del programma. Se le fasi precedenti sono fatte per bene la fase di implementazione è pressocchè banale in quanto si hanno chiare sin dall'inizio tutte le entità coinvolte, i loro membri e come interagiscono tra di loro.
Tutto questo per dire cosa? Che se il capo in riunione dice mi serve qualcosa che faccia questo, tenendo traccia di questo e quello e che mi dia un'interfaccia così, il povero programmatore, che sarei io, deve faticare il triplo per capire cosa nasconde così gelosamente il capo tra un emisfero e l'altro del cervello.
Il colmo è, poi, che una volta terminato il lavoro, il capo ti chiede di fare una modifica semplice semplice perchè lui "ha pensato di introdurre una miglioria". Peccato che questa miglioria vada applicata al cuore del sistema sviluppato precedentemente rendendo inutilizzabile o quando meno da riadattare il 75% del codice precedentemente prodotto.
Ora capisco che si voglia fare i fighi ad utilizzare un modello di sviluppo agile o quanto meno incrementale ma anche questi modelli prevedono un momento di "sediamoci e decidiamo dove vogliamo andare a parare", pur senza la rigidità del modello a cascata perchè cambiare il motore centrale del sistema non è per niente agile.
Tra l'altro, a farmi rabbia, è che completato questo giro, dovrò rimetterci le mani sopra per supportare un tipo leggermente diverso di dato e ci metto le mani sul fuoco che andrò a toccare per la terza volta la stessa parte del sistema.
* Esiste anche la fase di Testing ma le tre paroline magiche sono tre e "Testing" non c'entrava.
Post
4 commenti:
Ottimo! Ottimo sunti di Ingegneria dei Sistemi Software!
Welcome to the IT World!
Tornando all'ingegneria del software, potresti provare con un prototipo evolutivo (o usa&getta se il caso) e mostra quello al capo per valutare le modifiche da apportare.
Se poi hai problemi col formato dei dati, valuta l'utilizzo di un ORM.
L'approccio in tre punti che hai descritto non si applica forse alla stragrande maggioranza dei problemi nella vita? :)
Detto questo, ti sono vicino perchè mi è capitato più volte di trovarmi nella tua stessa identica situazione.
"Oh ma che bello che sarebbe se introducessi questa cosa qui! Dai che tanto è una cosa da poco e ci metti un attimo!". E tu, dentro, ricominci a seguire i famosi tre punti. Solo che il problema, ora, è trovare la bestemmia perfetta.
@dancerjude:
alla fine uso proprio il modello evolutivo, il problema è che è il capo a non sapere quello che vuole.
L'ORM non è possibile perchè abbiamo un framework enorme autoprodotto che offre le funzionalità di un ORM in maniera abbastanza flessibile. Anzi, il problema forse è proprio questo, lo stack per persistere gli oggetti di Business Logic su DB, per quanto geniale, è molto "a scatola nera". Praticamente io seguo le note che mi sono appuntato e "incrocio le dita". E' fighissimo, ma quando qualcosa non va c'è da sbatterci la testa.
Posta un commento