I requisiti nello sviluppo software - leggi generali e varianti contestuali

878 views
716 views

Published on

Il webinar mostra una panoramica sulle più accreditate tecniche di scrittura e gestione dei requisiti per ottimizzarne la raccolta, la stesura e la condivisione.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
878
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

I requisiti nello sviluppo software - leggi generali e varianti contestuali

  1. 1. I requisiti nello sviluppo software- leggi generali e varianti contestuali - ©Adriano Comai 2011 www.analisi-disegno.com
  2. 2. Adriano Comai • Formazione umanistica, da 30 anni nello sviluppo software • Consulenza per molte organizzazioni in Italia e all’estero • Oltre 400 corsi e seminari su diversi aspetti dello sviluppo • Decine di articoli pubblicati su riviste informatiche • Guida “Requirements-by-Example”, con esempi di requisiti ben specificati e indicazioni pratiche per gli analisti, diffusa e usata in tutto il mondo • Scaricabile, anche in versione italiana, dal mio sito www.analisi-disegno.com©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 2
  3. 3. Centralità dei Requisiti Acquisto • di prodotti • di servizi Sviluppo • di software • di sistemi complessi (Hardware + Software)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 3
  4. 4. Andamento dei progetti sw Esito dei progetti (fonte: The Standish Group, su un campione di migliaia di progetti internazionali) Successo Parziale insuccesso Fallimento (cancellati, (meno funzioni, più tempi e costi) o mai utilizzati) 2010 37% 42% 21% 2006 35% 46% 19% 1998 26% 46% 28% 1994 16% 53% 31% • Il campione include aziende e pubblica amministrazione, ma non software house o aziende di consulenza • Percentuali di fallimento superiori per i progetti di dimensioni maggiori e nelle grandi organizzazioni. Progetti con costo di risorse < $750.000 hanno una percentuale di successo del 73% (dato 2006)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 4
  5. 5. Perché i progetti falliscono Requisiti incompleti 13,1% Mancato coinvolgimento utente 12,4% Mancanza risorse 10,6% Attese irrealistiche 9,9% Mancanza supporto direzione 9,3% Cambiamento requisiti 8,7% Mancanza pianificazione 8,1% Non serviva più 7,5% Carenze del Management IT 6,2% Incompetenza sulle tecnologie 4,3% Altro 9,9% (fonte: The Standish Group)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 5
  6. 6. Requisiti e prodotti …©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 6
  7. 7. Requisiti, componenti, test componenti sistema esigenze requisiti stakeholders test©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 7
  8. 8. Ruoli e requisiti Architetto / Committente Sviluppatore Designer Stakeholder Responsabile Analista Tester progetto Gestore servizio©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 8
  9. 9. Attività per i requisiti • Raccolta requisiti (gathering) • Analisi requisiti (analysis) • Gestione dei requisiti (management) • Ingegneria dei requisiti (engineering) • …©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 9
  10. 10. Requisiti? Conoscenza Comunicazione©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 10
  11. 11. Need goal requirement Bisogni Obiettivi Requisiti©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 11
  12. 12. Cosa si vorrebbe • che tutti i requisiti siano già chiari alla partenza del progetto • che siano completamente privi di ambiguità, e specifichino nel dettaglio cosa dovrà fare il sistema©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 12
  13. 13. La realtà: i requisiti vanno scoperti • usando tecniche (“arti”) efficaci ed efficienti ⇒…e parecchi emergeranno solo quando il sistema verrà effettivamente utilizzato©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 13
  14. 14. Esprimere requisiti è difficile • Esprimere requisiti per evolvere e migliorare di un sistema esistente è relativamente semplice • Ma per qualcosa di nuovo, è molto più complesso “Spesso, il modo migliore per scoprire requisiti che nessuno ancora conosce è rilasciare il prodotto in modo incrementale. Ogni volta che i clienti ricevono un rilascio tirano fuori decine di altre funzioni che vorrebbero avere. È un dato di fatto che il numero di nuovi requisiti pensati dai clienti è proporzionale al numero di requisiti già soddisfatti.” (Alan Davis 2005)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 14
  15. 15. Legge: Quanto è maggiore il livello di innovazione, tanto più è difficile chiarire i requisiti allinizio del progetto.©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 15
  16. 16. Sprechi Non tutti i requisiti hanno la stessa importanza Mediamente: • il 45% delle funzionalità di un sistema non viene mai utilizzato • il 19% viene utilizzato solo raramente (fonte: Standish Group 2004)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 16
  17. 17. Obiettivi del committente Bisogni Obiettivi derivano da una o più esigenze (“di business”), alle quali il committente intende rispondere con un cambiamento©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 17
  18. 18. Stakeholder (parti interessate) • “dimenticare” uno o più stakeholder può risultare critico per il successo del progetto • il loro coinvolgimento nel progetto ha un costo, che va valutato in termini di rischi / opportunità©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 18
  19. 19. Requisiti in conflitto È normale che in un progetto vi siano requisiti in conflitto: • A causa di richieste troppo onerose a fronte di risorse limitate (budget, tempi) • o quando gli stakeholder hanno punti di vista contrastanti Il conflitto tra requisiti deve emergere il prima possibile (per poterlo gestire con costi e in tempi contenuti).©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 19
  20. 20. Univocità del committente • il committente è il principale decisore nel progetto… • quindi deve essere unico, ed il suo ruolo deve essere noto a tutte le parti interessate • nel caso di progetti complessi, che coinvolgono numerose aziende (o aree diverse della medesima azienda), il ruolo di committente può essere attribuito a: – un “delegato” – un “comitato guida”©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 20
  21. 21. Incontrare le parti interessate interviste e incontri vanno preparati con cura: • per minimizzare i tempi necessari • per massimizzare i risultati interviste individuali incontri collettivi©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 21
  22. 22. Come scoprire i requisiti strade complementari: • interviste e incontri • analisi di sistemi e/o procedure organizzative preesistenti • costruzione di prototipi • identificazione e descrizione degli scenari di utilizzo del sistema (casi d’uso)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 22
  23. 23. Ruoli e requisiti Architetto / Committente Sviluppatore Designer Stakeholder Responsabile Analista Tester progetto Gestore servizio©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 23
  24. 24. Legge: I requisiti devono essere espressi (comunicati) Variante: Le modalità di espressione dei requisiti dipendono al contesto in cui si opera©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 24
  25. 25. Criticità dei sistemi Vita umana Denaro Immagine Nessuna criticità Tipicamente, diversi livelli di formalizzazione dei requisiti©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 25
  26. 26. Interlocutori e requisiti Esigenza Committente Realizzatore©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 26
  27. 27. Più interlocutori Esigenza Committente Analista Esigenza Esigenza Realizzatore Designer©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 27
  28. 28. ©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 28
  29. 29. Legge: Più ruoli intermedi esistono tra chi ha lesigenza e chi implementa, più sono le comunicazioni da gestire. Più queste comunicazioni avvengono in sequenza e sono basate su documenti formalizzati, più crescono i tempi di realizzazione e i rischi di incomprensione.©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 29
  30. 30. Perché i requisiti cambiano Tra i motivi più comuni: • non ci si era capiti bene prima • cambiamento di vincoli “esterni” (es. legislativi) • cambiamento a livello di mercato (es. concorrenti con prodotti dalle caratteristiche più innovative) • cambiamento di scenari tecnologici (es. nuove opportunità, tecnologie in declino) • cambiamento di committente©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 30
  31. 31. Legge: Il cambio di requisiti in corso dopera è una costante in ogni progetto non elementare.©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 31
  32. 32. Legge: Il cambio di requisiti in corso dopera è tanto più costoso quanto più tardi avviene. Variante: Il costo del cambiamento per i requisiti non funzionali è di solito molto superiore a quello per i requisiti funzionali.©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 32
  33. 33. Legge: Maggiore il tempo che passa tra la definizione del requisito e la verifica del suo soddisfacimento, maggiori i rischi. (il “congelamento dei requisiti” preoccupa molto i committenti…)©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 33
  34. 34. Grazie per l’attenzione! Per approfondimenti e altri materiali: www.analisi-disegno.com © Adriano Comai 2011©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 34

×