Ritengo rilevante tenere presente questa idea centrale nel Project Management
,
per ottenere un miglioramento di una delle 3 dimensioni, tempo di consegna, costi, affidabilità, occorre un sacrificio sulle altre due dimensioni.
I trade-off richiesti variano da progetto a progetto ed è necessario essere attrezzati per spaziare in tutte e tre dimensioni.
Favorendo la dimensione tempo, si ha il così detto Svilupppo rapido e fast Time To Market. tuttavia si dovrà sacrificare il tempo necessario al testing e il costo aumenterà se si impiegano più persone o acquistano manufatti intermedi(da modificare).
Favorendo la dimensione costi, si ha il fenomeno del riuso software aggressivo, che porta all'utilizzo di componenti oppure, soluzioni sofwtware pronte(off-the-shelf), a scapido della personalizzazione.
Favorendo la dimensione affidabilità e precisione, si ha metodologie rigorose, testing esteso e multilivello con tool software ma anche con personale apposito, che è ovviamente un costo e richiede tempo, questo è l'approccio necessario per realizzare software "Mission Critical"(es. settore bancario) o "Life Critical"(es. settore trasporti, medicale, energia). Il software ti tipo "Critical", si differenzia dal software convenzionale nelle conseguenze di un errore nel sistema, in questo caso un errore costa molto denaro o addirittura vite umane, non vi è dubbio che per ottenere la sicurezza necessaria occorrerà molto tempo e molto lavoro.
Inplicitamente, lo scenario più richiesto nel contesto Business è quello di Svilupppo rapido, con dead line stretta, in modo che il committente possa approfittare di una opportunità che si presenti sul mercato, tuttavia va sempre tenuto presente che il sistema che andiamo a costruire rimarrà operativo per 5-10 anni o più, prima di venire sostituito.
Il tipico esempio invece di sviluppo one-shot è il sito web, che non verrà mantenuto attivamente per molti anni, ma sostituito nel giro di 2-3 anni.
La dimensione affidabilità e precisione è importante, il software deve fare ciò che promette in modo preciso, ma solitamente in caso di errore del sistema le conseguenze economiche sono relativamente basse, per cui metodologie che prevedano testing approfondito con l'ausilio di personale apposito non sono applicabili, mentre c'è spazio per metodi di testing e monitoring automatizzato.
In questa dimensione il primo aspetto ad essere sacrificato è la ricercatezza e ricchezza della user interface.
La dimensione costi è ovviamente importante, raramente non si è soggetti a budget ristretti, non è tuttavia prioritaria come qualcuno potrebbe credere, nella mia esperienza il committente è disposto a spendere se convinto del ritorno futuro, la risposta a questo problema è comunemente l'uso di componenti(cosa che preferisco) o addirittura l'uso di software pronto da configurare(soluzione spesso deludente), ma ritengo ancora più produttivo controllare attentamente i requirements.
Infatti è controllando i requirements con uno sviluppatore esperto e aiutato da una persona che conosce approfonditamente la logica di business che si possono prendere le decisioni economicamente più produttive.
Le opinioni espresse nel mio blog sono solo questo: mie opinioni.
In nessun modo rappresento le opinioni dei miei clienti in questa sede.
Partita Iva: 02360450205
Content of this site is licensed under Creative Commons Attribution-Share Alike License.
