• Save
 

I requisiti nello sviluppo software - leggi generali e varianti contestuali

on

  • 706 views

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

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

Statistics

Views

Total Views
706
Slideshare-icon Views on SlideShare
698
Embed Views
8

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 8

http://www.linkedin.com 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

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

    I requisiti nello sviluppo software - leggi generali e varianti contestuali I requisiti nello sviluppo software - leggi generali e varianti contestuali Presentation Transcript

    • I requisiti nello sviluppo software- leggi generali e varianti contestuali - ©Adriano Comai 2011 www.analisi-disegno.com
    • 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
    • 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
    • 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
    • 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
    • Requisiti e prodotti …©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 6
    • Requisiti, componenti, test componenti sistema esigenze requisiti stakeholders test©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 7
    • Ruoli e requisiti Architetto / Committente Sviluppatore Designer Stakeholder Responsabile Analista Tester progetto Gestore servizio©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 8
    • 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
    • Requisiti? Conoscenza Comunicazione©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 10
    • Need goal requirement Bisogni Obiettivi Requisiti©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 11
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Ruoli e requisiti Architetto / Committente Sviluppatore Designer Stakeholder Responsabile Analista Tester progetto Gestore servizio©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 23
    • 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
    • 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
    • Interlocutori e requisiti Esigenza Committente Realizzatore©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 26
    • Più interlocutori Esigenza Committente Analista Esigenza Esigenza Realizzatore Designer©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 27
    • ©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 28
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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