Come è possibile ricavare da un insieme di requisiti del business i requisiti determinanti per la comprensione della quota parte «informatica» di un problema? Come è possibile ricavare da un insieme di requisiti del business una stima affidabile del costo dello sviluppo?

1. Caso di studio: Il CIO solitario
Andrea Colleoni | Colleoni.INFO

2. Il CIO solitario
Quando il CIO si trova a dover prendere una decisione e ha bisogno di
un supporto indipendente.

3. Sintomi

Il business richiede un nuovo servizio ed espone i suoi requisiti al CIO.

Il nuovo servizio ha tutte le caratteristiche per diventare un nuovo progetto informatico, dato che il
servizio non è erogabile dal sistema informativo attuale.

Il CIO ha bisogno di fare uno scouting delle soluzioni disponibili e di realizzare il progetto.

Che fare?


Introdurre un nuovo prodotto che eroghi il servizio out-of-the-box e sviluppare un’integrazione.


Personalizzare il proprio sostema informativo.
Realizzazare un nuovo software integrato.
Chi sono i cointeressati?

I fornitori, che proporranno le loro soluzioni; nessun fornitore dirà che la propria soluzione non va bene, ma che
è la più adatta in quel contesto.

Il business o la proprietà, proporranno i loro partner.

Il CIO su cui ricadranno tutte le responsabilità se il progetto fallisce.

4. Problema n° 1: l’analisi

Come è possibile ricavare da un insieme di requisiti del business i requisiti determinanti per la
comprensione della quota parte «informatica» del problema?
Soluzione tipica:

Lasciare che sia il business a descrivere su un documento informale i propri bisogni e trasmettere o condividere
con i fornitori questi bisogni. I fornitori faranno poi la loro analisi dei requisiti.
La nostra soluzione :

Esistono metodologie e strumenti affidabili e consolidati per produrre in tempi brevi un’analisi completa dei
requisiti in un contesto di sviluppo di software di qualità, comprendente: piano dei test, requisiti non funzionali,
matrice delle competenze.
Benefici:

L’analisi da parte di un soggetto terzo, garantisce l’indipendenza della scelta. Il fornitore tenderà a porre in
risalto la soluzione che produce il maggior margine.

Il CIO non ha bisogno di avere un ingegnere del software nel suo staff, ma ne richiede i servizi on-demand.

Con un insieme ordinato di requisiti è possibile produrre una stima più precisa.

5. Problema n° 2: la stima

Come è possibile ricavare da un insieme di requisiti del business una stima affidabile del costo dello
sviluppo?
Soluzione tipica:

Chiedere quotazioni a tutti i fornitori conosciuti.
La nostra soluzione :

Esistono metodologie e strumenti per produrre in tempi brevi una stima del costo industriale di un insieme di requisiti, a
prescindere dalle tecnologie di implementazione.
Benefici:

La stima da parte di un soggetto terzo, garantisce l’indipendenza della scelta.

Il CIO non ha bisogno di avere un ingegnere del software nel suo staff, ma ne richiede i servizi al momento opportuno.

Con una stima, si può discutere del budget; con un insieme di requisiti no.

Con una stima si può scrivere un capitolato più preciso su cui chiedere una quotazione ai fornitori.

6. Problema n° 3: la direzione dei lavori

A che punto siamo con lo sviluppo? Quando posso far vedere qualcosa al business?
Soluzione tipica:

Tempestare di telefonate il PM del fornitore e chiedere incontri, SAL, verifiche e richiedere tempi
certi.
La nostra soluzione :

Una direzione dei lavori terza, che coinvolge gli stakeholders con SAL periodici; un unico
interlocutore per progetti multi fornitore. Nessun rischio nascosto. Competenza tecnica nelle fasi
dello sviluppo.
Benefici:

La direzione dei lavori da parte di un soggetto terzo, garantisce un’informazione indipendente.

Il CIO non ha bisogno di avere un PM nel suo staff, ma lo richiede in modalità on demand.

Il CIO non ha bisogno di riporre illimitata fiducia nel PM del fornitore.

7. Problema n° 4: la verifica

Avevamo chiesto che fosse implementata questa funzionalità, ma nel software consegnato non è
implementata come la volevamo noi.
Soluzione tipica:

Il forinitore chiede un addendum al contratto e sviluppa la funzionalità richiesta; nella migliore delle ipotesi si
può ottenere uno sconto commerciale dovuto all’incomprensione.
La nostra soluzione :

Una verifica costante e in itinere rispetto al piano dei test. Mockups, deliverable frequenti e processi AGILE per
anticipare i problemi di interpretazione tra fornitore e business.
Benefici:

Si affronta il cambiamento, prima di aver affrontato il costo dello sviluppo di feature non richieste o non più
utili.

Il fornitore è più motivato, e il business più coinvolto.

Oggettività dei test rispetto al ciclo di vita del progetto; minor probabilità di contenzioso con il fornitore.

8. Risultati finali

Proprio come per la consulenza fiscale, anche il CIO non è solo e può farsi consigliare
da un consulente esterno on-demand.

Non ci sono costi fissi, ma variabili e funzione della dimensione dei progetti.

Non ci sono oneri di formazione, dato che i nostri professionisti sono esperti aggiornati.

Maggiore proabilità di successo dei progetti software.

Minor costo relativo dei progetti falliti.

Oggettività nella comunicazione con business, fornitori, proprietà, management.

9. Colleoni.INFO
Ingegneria del software
http://www.colleoni.info/wp/slideshare