Caso di studio:   il CIO solitario
Upcoming SlideShare
Loading in...5
×
 

Caso di studio: il CIO solitario

on

  • 430 views

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 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?

Statistics

Views

Total Views
430
Views on SlideShare
428
Embed Views
2

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Potrebbe essere necessaria più di una diapositiva

Caso di studio:   il CIO solitario Caso di studio: il CIO solitario Presentation Transcript

  • Caso di studio: Il CIO solitario Andrea Colleoni | Colleoni.INFO
  • Il CIO solitario Quando il CIO si trova a dover prendere una decisione e ha bisogno di un supporto indipendente.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Colleoni.INFO Ingegneria del software http://www.colleoni.info/wp/slideshare