APPLICAZIONI INFORMATICHE

Presentazione sul tema: "APPLICAZIONI INFORMATICHE"— Transcript della presentazione:

1 APPLICAZIONI INFORMATICHE
i requisiti applicazioni informatiche - ingegneria dei requisiti

2 Ingegneria dei Requisiti
applicazioni informatiche - ingegneria dei requisiti

3 Progetti Software “26% di progetti software terminano con successo”
Standish Group, CHAOS Report, 2000 “… cioè il 74% fallisce” Standish Group, CHAOS Report, 2000 Il 26% che vede la luce comunque ha problemi: Denver Airport: più di 50 milioni di US$ per errori del sistema di controllo dei bagagli London Ambulance Service: il sistema è stato disattivato dopo un giorno di funzionamento applicazioni informatiche - ingegneria dei requisiti

4 applicazioni informatiche - ingegneria dei requisiti
Tom De Marco “Il 56% degli errori di un software possono essere riferiti ai requisiti” Durante lo sviluppo di un software, più tardi un errore viene rilevato più costoso sarà risolverlo Molti errori sono fatti durante la raccolta e l’analisi dei requisiti Molti errori relativi ai requisiti possono (e devono) essere rilevati il prima possibile Errori tipici: uso di fatti non corretti, omissioni, inconsistenze e ambiguità Errori nella specifica dei requisiti sono uno dei problemi principali per l’industria software applicazioni informatiche - ingegneria dei requisiti

5 applicazioni informatiche - ingegneria dei requisiti
Costi applicazioni informatiche - ingegneria dei requisiti

6 applicazioni informatiche - ingegneria dei requisiti
… in Europa Un questionario inviato a società ha rilevato: Per gli analisti i problemi principali sono: Specifica dei requisiti (53%) Gestione dei requisiti (43%) Documentazione (36%) Test (35%) applicazioni informatiche - ingegneria dei requisiti

7 applicazioni informatiche - ingegneria dei requisiti
Definizione L’ingegneria dei requisiti è una sotto area dell’ingegneria del software che studia il processo di definizione dei requisiti del sistema da realizzare. E’ una nuova area che ha avuto origine nel 1993 con “the 1st International Symposium on R.E.” Ora siamo alla 12 edizione. “Il processo di definizione dei requisiti è un’interfaccia tra i desideri (o bisogni) dei clienti e la realizzazione dei questi requisiti come sistema software” applicazioni informatiche - ingegneria dei requisiti

8 … un’altra definizione
L’ingegneria dei requisiti è: “Lo sviluppo e l’uso di tecnologie per raccogliere, specificare e analizzare i requisiti degli utenti/clienti che saranno poi realizzati da un sistema software” applicazioni informatiche - ingegneria dei requisiti

9 applicazioni informatiche - ingegneria dei requisiti
Fred Brook’s “The most difficult part of building a software system is to decide, precisely, what must be built. No other part of the work can undermine so badly the resulting software if not done correctly. No other part is so difficult to fix later.” applicazioni informatiche - ingegneria dei requisiti

10 applicazioni informatiche - ingegneria dei requisiti
Requisiti di sistema Definiscono che cosa un sistema deve fare e sotto quali vincoli deve operare, ad esempio: Il sistema dovrà archiviare i dati di una biblioteca, in particolare dati relativi ai libri, ai giornali, le riviste, video, nastri audio e CD-ROM. Il sistema dovrà permettere agli utenti di fare delle ricerche per titolo, autore, o ISBN. L’interfaccia al sistema dovrà essere realizzata utilizzando un browser web. Il sistema dovrà gestire almeno 20 transazioni per secondo Il sistema dovrà essere accessibile attraverso l’uso di password applicazioni informatiche - ingegneria dei requisiti

11 applicazioni informatiche - ingegneria dei requisiti
Tipi di requisiti Requisiti Funzionali: definiscono parte delle funzionalità del sistema Requisiti di implementazione: come il sistema dovrà essere implementato Requisiti di prestazione: specificano le prestazioni minime accettabili per il sistema Requisiti di usabilità: specificano il tempo massimo per mostrare l’uso del sistema applicazioni informatiche - ingegneria dei requisiti

12 applicazioni informatiche - ingegneria dei requisiti
Tipi di requisiti Requisiti non funzionali Esprimono vincoli sotto i quali il software dovrà operare Possono essere visti come qualità specifiche che il software dovrà avere Costi Sicurezza Robustezza Portabilità Requisiti -1 Condizioni che non si devono mai verificare Solitamente associate a requisiti non funzionali applicazioni informatiche - ingegneria dei requisiti

13 Problemi legati ai requisiti
I requisiti non riflettono i reali bisogni dei clienti I requisiti sono inconsistenti e/o incompleti E’ costoso cambiare i requisiti dopo che sono stati definiti e concordati Possono esserci delle incomprensioni tra i clienti e chi a raccolto e analizzato i requisiti, tra chi ha raccolto i requisiti e il progettista, tra il progettista e chi realizzerà il sistema. applicazioni informatiche - ingegneria dei requisiti

14 Un esempio di incompletezza
Il sistema dovrà permettere agli utenti di fare delle ricerche per titolo, autore, o ISBN. Che cosa significa per i CD-ROM? Possono non avere un ISBN Vale solo per i libri Immaginate se realizzate il sistema con questo requisito senza considerare i CD-ROM. Non possiamo scrivere requisiti universali, ma possiamo tentare di essere il più possibile completi. applicazioni informatiche - ingegneria dei requisiti

15 Determinazione dei requisiti
Fornire una definizione informale dei requisiti Generalmente in questa fase si parla anche di servizi attesi dal sistema e vincoli a cui deve sottostare L’attività di raccolta dei requisiti è svolta da un analista di business (o di sistema) utilizzando tecniche diverse, che possono spaziare dalle tradizionali interviste ai clienti andando (se necessario) fino alla costruzione di prototipi. Analisi delle duplicazioni e contraddizioni Revisioni e rinegoziazione dei requisiti Documento dei requisiti applicazioni informatiche - ingegneria dei requisiti

16 Raccolta o negoziazione dei requisiti
Discussione con clienti e esperti del dominio Esperti del dominio  conoscenza del dominio Clienti  requisiti Casi d’uso e conoscenza del domino devono essere integrati applicazioni informatiche - ingegneria dei requisiti

17 Metodi di raccolta requisiti
Tradizionali Interviste Questionari Osservazioni Studio dei documenti e dei sistemi software Metodi moderni Prototipi Sviluppo cooperativo delle applicazioni Sviluppo rapido delle applicazioni Analizziamoli applicazioni informatiche - ingegneria dei requisiti

18 applicazioni informatiche - ingegneria dei requisiti
Interviste Condotte principalmente con i clienti (anche gli esperti possono essere intervistati) Problemi Generalmente i clienti hanno solo una vaga idea dei requisiti del sistema e non sono in grado di esprimerli Possono anche richiedere funzionalità che vanno fuori i costi e gli obiettivi del progetto Possibili conflitti Due tipi di intervista: Strutturata (formali) Non strutturate (informali) applicazioni informatiche - ingegneria dei requisiti

19 applicazioni informatiche - ingegneria dei requisiti
Interviste Strutturate Preparate in anticipo Un’agenda Domande predeterminate (aperte o chiuse) Sono generalmente accompagnate da interviste informali (non strutturate) Non strutturate Incontri informali Senza domande anticipate o obiettivi prederminati Incoraggiare il cliente a parlare di ciò che ha in mente, su cui l’analista potrebbe non aver riflettuto Per entrambe si parte da un contesto di discussione (ad esempio un breve documento inviato in anticipo) applicazioni informatiche - ingegneria dei requisiti

20 applicazioni informatiche - ingegneria dei requisiti
Domande da evitare Domande sulle quali l’intervistatore esprime (direttamente o indirettamente) la propria opinione sul problema dobbiamo fare le cose nel modo in cui le facciamo? Domande prevenute, simili alle precedenti, eccetto che l’opinione dell’intervistatore è chiaramente espressa non intendi fare questo, vero? Domande contenenti già la risposta devi fare le cose in questo modo, non è vero? Importante è ascoltare applicazioni informatiche - ingegneria dei requisiti

21 applicazioni informatiche - ingegneria dei requisiti
Questionari In aggiunta alle interviste Sostituiscono le interviste quando il progetto è a basso rischio con obiettivi ben definiti Non è possibile chiedere chiarimenti sui quesiti e le risposte Vantaggi: tempo per valutare la risposta, anonimato Svantaggi: non c’è la possibilità di discutere e approfondire i quesiti applicazioni informatiche - ingegneria dei requisiti

22 applicazioni informatiche - ingegneria dei requisiti
Questionari I quesiti dovrebbero essere chiusi (evitare i quesiti aperti) Tre tipi: A scelta multipla A punteggio Con ordinamento applicazioni informatiche - ingegneria dei requisiti

23 applicazioni informatiche - ingegneria dei requisiti
Osservazioni Ricerca di fatti attraverso l’osservazione: Osservazione passiva: l’analista osserva le attività senza interruzioni o coinvolgimento diretto del cliente che lavora (anche con videocamera). Osservazione attiva: l’analista partecipa direttamente alle attività ed entra a far parte del gruppo di lavoro. Svolte per periodi lunghi e con differenti carichi di lavoro Difficoltà: le persone tendono a comportarsi diversamente quando osservate applicazioni informatiche - ingegneria dei requisiti

24 Studio dei documenti e dei sistemi software
….. per approfondire la conoscenza di dominio Documenti organizzativi: modulistica aziendale (compilata, se possibile) descrizione delle procedure lavorative e delle politiche di intervento piani di business organigrammi corrispondenza fra uffici minute di incontri registrazioni contabili corrispondenza esterna lamentele clienti ecc. applicazioni informatiche - ingegneria dei requisiti

25 Studio dei documenti e dei sistemi software
Moduli e rapporti di sistema: schermate e rapporti computerizzati (con la relativa documentazione), manuali operativi di sistema, documentazione utente, documentazione tecnica, modelli di analisi di progetto, ecc. Libri, riviste, pacchetti proprietari (sistemi ERP) - internet applicazioni informatiche - ingegneria dei requisiti

26 Negoziazione e validazione
In parallelo alla raccolta dei requisiti Validazione e negoziazione fatta sul documento dei requisiti (acquisiti) Revisione del documento Requisiti fuori dal contesto Matrice di dipendenza dei requisiti Priorità e rischi associati ai requisiti applicazioni informatiche - ingegneria dei requisiti

27 applicazioni informatiche - ingegneria dei requisiti
Matrice di dipendenza Requisito R1 R2 R3 R4 Conflitto Indipendenti Sovrapposto Conflitti: discussi con i clienti Sovrapposti: riscritti per eliminare le sovrapposizioni applicazioni informatiche - ingegneria dei requisiti

28 applicazioni informatiche - ingegneria dei requisiti
Goal Analisys la goal analysis è una tecnica che aiuta il progettista a focalizzarsi sugli obiettivi che un sistema software deve raggiungere, e fornisce i mezzi per raffinare questi obiettivi, esplorando più soluzioni alternative applicazioni informatiche - ingegneria dei requisiti

29 applicazioni informatiche - ingegneria dei requisiti
Goal Analisys si definiscono gli obiettivi si definiscono le strategie per raggiungerli l’analisi comparativa tra le strategie porta ad scelta che deve essere condivisa applicazioni informatiche - ingegneria dei requisiti

30 applicazioni informatiche - ingegneria dei requisiti
Goal Analisys What QUALI obiettivi si devono portare a compimento in questo passo? Why PERCHE’ questi obiettivi? How COME vengono eseguiti questi obiettivi? applicazioni informatiche - ingegneria dei requisiti

31 Priorità e rischi associati ai requisiti
Analisi del rischio: identifica i requisiti che potrebbero causare difficoltà nello sviluppo Tipologie di rischio: rischio tecnico, rischio di prestazione, rischio di sicurezza, rischio di integrità dei database, rischio nel processo di sviluppo, rischio politico, rischio legale, rischio di volatilità Valutazione della priorità: permette la ritaratura del progetto rispetto ai ritardi (es. scaricando i requisiti con bassa priorità per rispettare tempi di progetto). Le priorità devono essere negoziate con gli utenti tendo conto dei fattori di rischio applicazioni informatiche - ingegneria dei requisiti

32 applicazioni informatiche - ingegneria dei requisiti
Acquisti on line Un esempio di definizione dei requisiti applicazioni informatiche - ingegneria dei requisiti

33 Acquisti online – “raccolta” dei requisiti
(R1) Il cliente usa la pagina web del produttore per vedere la configurazione standard del computer (server, desktop, portatile) scelto. Il prezzo è esplicitamente mostrato (R2) Il cliente sceglie di vedere i dettagli della configurazione: per l’acquisto oppure per definire un’altra configurazione più adatta. Il costo di qualunque configurazione può essere calcolato su richiesta del cliente (R3) Il cliente può scegliere di ordinare il computer direttamente online oppure può richiedere un incontro con il venditore prima di confermare l’ordine, per ottenere maggiori spiegazioni sui dettagli dell’ordine, una negoziazione del costo, etc. (R4) Per ordinare, il cliente deve riempire online un modulo con i dettagli della spedizione, l’indirizzo di fatturazione, e i dettagli di pagamento (carta di credito o assegno) (R5) Dopo che l’ordine del cliente è stato inviato e confermato, il venditore invia elettronicamente una richiesta al magazzino con i dettagli della configurazione ordinata (R6) I dettagli della transazione, compresi un numero d’ordine e un numero cliente, sono inviati via al cliente, permettendo a quest’ultimo di controllare lo stato d’ordine (R7) Il magazzino riceve la fattura dal venditore e spedisce il computer al cliente applicazioni informatiche - ingegneria dei requisiti

34 Acquisti online - strutturazione dei requisiti
Requisito Attore Attività R1 Cliente Mostrare configurazione Computer Standard R2 Costruire Configurazione Computer R3 Cliente, Venditore Ordinare Computer configurato, richiedere contatto commerciale R4 Ordinare Computer configurato, verificare e accettare pagamento cliente R5 Venditore, Magazzino Informare magazzino su ordine R6 Ordinare computer configurato, aggiornare stato ordine R7 Stampare fattura applicazioni informatiche - ingegneria dei requisiti

35 Acquisti online - documento dei requisiti
1. Premessa 1.1 Obiettivo e scopo del prodotto 1.2 Contesto di business 1.3 Stackeholders 1.4 Soluzioni preliminari 1.5 Sintesi del documento 2. Servizi del sistema 2.1 Scopo del sistema 2.2 Requisiti funzionali 2.3 Requisiti non funzionali 3. Vincoli di sistema 3.1 Requisiti di interfaccia 3.2 Requisiti di presentazione 3.3 Requisiti di sicurezza 3.4 Requisiti operativi 3.5 Requisiti politici e legali 3.6 Altri vincoli 4. Aspetti progettuali 4.1 Problemi aperti 4.2 Programma preliminare 4.3 Previsione costi Appendici Glossario Documenti e moduli di business Riferimenti applicazioni informatiche - ingegneria dei requisiti

36 Acquisti online - negoziazione dei requisiti
Ma non è meglio verificare la disponibilità a magazzino prima che il cliente completi l’ordine? Ma sei proprio sicuro che ti serva … Ma non sarà che il tuo cliente potrebbe … Ma non succede mai che l’ordine arriva in questo modo … applicazioni informatiche - ingegneria dei requisiti

37 applicazioni informatiche - ingegneria dei requisiti
Il primo problema … Un bel problema … Forse … IL PROBLEMA ! applicazioni informatiche - ingegneria dei requisiti