La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini

Presentazioni simili


Presentazione sul tema: "Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini"— Transcript della presentazione:

1 Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini

2 Progetti Software Tuttavia del 26% non tutti sono esenti da 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 26% di progetti software terminano con successo Standish Group, CHAOS Report, 2000 … cioè il 74% falliscono Standish Group, CHAOS Report, 2000

3 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 lanalisi 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 lindustria software

4 Costi

5 … in Europa Un questionario inviato a società ha rilevato: Per gli analisti I problemi principali sono: –Specifica dei requisiti (53%) –Gestione dei requisiti (43%) –Ducomentazione (36%) –Test (35%)

6 Definizione Lingegneria dei requisiti è una sotto area dellingegneria 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 1 st International Symposium on RE Ora siamo alla 12 edizione. Il processo di definizione dei requisiti è uninterfaccia tra i desideri (o bisogni) dei clienti e la realizzazione dei questi requisiti come sistema software

7 … unaltra definizione Lingegneria dei requisiti è: Lo sviluppo e luso di tecnologie per raccogliere, specificare e analizzare i requisiti degli utenti/clienti (stakeholders) che saranno poi realizzati da un sistema software

8 Fred Brooks 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.

9 Requriements Engineering come disciplina: 1993 –RE (93, 95, 97, ) –ICRE (94, 96, 98, 00) –WER (98, 99, 00, 01) –Requirements Engineering Journal Passato: System Analysis Oggi: A network of processes –Pressione da parte del mercato per software di qualità –Libri (Sommerville, Jackson, Loucopoulos, …) –Tools (Doors, Requisite-Pro, Caliber-RM) Breve storia

10 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 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. –Linterfaccia al sistema dovrà essere realizzata utilizzando un World-Wide-Web browser. –Il sistema dovrà gestire almeno 20 transazioni per secondo –Il sistema dovrà essere accessibile attraverso luso di password

11 Tipi di requisiti Requisiti Funzionali: definiscono parte delle funzionalitaà 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 luso del sistema Requisiti non funzionali –Esprimono vincoli sotto i quali il software dovrà operare –Possono essere visti come qualità specifiche che il software dovrà avere (come il software … Requisiti -1 –Condizioni che non devono mai accadere –Solitamente associati a requisiti non funzionali

12 Probelmi legati ai requisiti I requisiti non riflettono i reali bisogni dei clienti I requisit i 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 anlizzato i requsiti, tra chi ha raccolto i requisiti e il prgettista, e tra il progettista e chi realizzerà il sistema.

13 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. Naturalmente non possiamo scrivere requisiti universali, ma possiamo tentare di essere il più possibile completi.

14 Determinazione dei requisiti Fornire una definizione informale dei requisiti, funzionali e non Generalmente in questa fase si parla anche di servizi attesi dal sistema e vincoli a cui deve sottostare Lattività 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 rinegozazione dei requisiti Documento dei requisiti

15 Raccolta dei requisiti Discussione con clienti e esperti del dominio Esperti del dominio conoscenza del dominio Clienti requisiti (casi duso) Casi duso e conoscenza del domino devono essere integrati

16 Metodi di raccolta requisiti Tradizionali –Interviste –Questionari –Osservazioni –Studio dei docuemnti e dei sistemi software Metodi moderni –Prototipi –Sviluppo cooperativo delle applicazioni –Sviluppo rapido delle applicazioni Analizzziamoli

17 Interviste Condotte principalemnte 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)

18 Interviste Strutturate –Preparate in anticipo –Unagenda –Domande predeterminate (aperte o chiuse) –Sono generalemnte 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 lanalista potrebbe non aver riflettuto Per entrambe si parte da un contesto di discussione (ad esempio un breve documento inviato in anticipo)

19 Doamnde da evitare Domande sulle quali lintervistatore esprime (direttaemnte o indirettamente) la propria opinione sul problema –dobbiamo fare le cose nel modo in cui le facciamo? Domande prevenute, simili alle precedenti, eccetto che lopinione dellintervistatore è chiaraemnte espressa –non intendi fare questo, vero? Domande contenenti già la risposta –devi fare le cose in questo modo, non è vero? Importante è ascoltare

20 Questionari In aggiunta alle interviste –Sostituiscono le interviste quando il progetto è a basso rischio con obiettivi ben definiti Non è possibile chiarimenti sui quesiti e le risposte –Vantaggi: tempo per valutare la risposta, anonomi –Svantaggi: non cè la possibilità di discutere e approfondire i quesiti I quesiti dovrebbero essere chiusi (evitare i quesiti aperti) Tre tipi: –A scelta multipla –A punteggio –Con ordinamento

21 Osservazioni Ricerca di fatti attraverso losservazione: –Osservazione passiva: lanalista osserva le attività senza interruzioni o coinvolgimento diretto del cliente che lavora (anche con videocamera). –Osservazione attiva: lanalista 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 diversaemnte quando osservate

22 Studio dei documenti e dei sistemi software Importante per approfondire la conoscenza di dominio Documenti organizzativi: modulustica 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. Moduli e rapporti di sistema: schermate e rapporti computerizzati (con la relativa documentazione), manuali operativi di sistema, docuemntazione utente, documentazione tecnica, modelli di analisi di progetto, ecc. Libri, riviste, pacchetti proprietari (sistemi ERP) - internet

23 Negoziazione e validazione In parallelo alla raccolta dei requisiti Validazione e negoziazione fatta sul docuemnto dei requisiti (acquisiti) Revisione del documento –Requisiti fuori dal contesto –Matrice di dipendenza dei requisiti –Priorità e rischi associati ai requisiti

24 Matrice di dipendenza RequisitoR1R2R3R4 R1 R2Conflitto R3Indipendenti R4IndipendentiSovrapposto Conflitti: discussi con i clienti Sovrapposti: riscritti per eliminari le sovrapposizioni

25 Priorità e rischi associati ai requisiti Analisi del rischio: identifica i requisiti che potrbbero 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 al ritaratura del progetto rispetto ai ritardi (es. scaricando i requisiti con bassa priorità per rispettare tempi di progetto). Le priorità devono essere negoziate con incontri di gruppo tendo conto dei fattori di rischio

26 Modellizzazione dei casi duso (UML - Unified Modeling Language) Attori: venditore, cliente e magazzino

27 Casi duso Rappresentà ununità funzionale che fornisce valore ad un attore Un attore che non comunica con almeno un caso duso è privo dinteresse, mentre il contrario non è necessariamento vero –Un caso duso che non comunica con alcun attore è permesso –Esistono generalizzazioni o specializzazioni di casi duso Quali sono le responsabilità e le aspettative dellattore verso il sistema? Spesso un caso duso corrisponde ad un requisito funzionali

28 Acquisti online (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 lacquisto oppure per definire unaltra 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 lordine, per ottenere maggiori spiegazioni sui dettagli dellordine, una negoziazione del costo, etc. (R4) Per ordinare, il cliente deve riempire online un modulo con i dettagli della spedizione, lindirizzo di fatturazione, e i dettagli di pagamento (carta di credito o assegno) (R5) Dopo che lordine 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 dordine e un numero cliente, sono inviati via al cliente, permettendo a questultimo di controllare lo stato dordine (R7) Il magazzino riceve la fattura dal venditore e spedisce il computer al cliente

29 RequisitoAttoreCaso duso R1CleinteMostrare configurazione Computer Standard R2ClienteCostruire Configurazione Computer R3Cliente, VenditoreOrdinare Computer configurato, richiedere contatto commerciale R4ClienteOrdinare Computer configurato, verificare e accettare pagamento cliente R5Venditore, MagazzinoInformare magazzino su ordine R6Cliente, VenditoreOrdinare computer configurato, aggiornare stato ordine R7Venditore, MagazzinoStampare fattura Acquisti online Assegnazione dei requisiti ad attori e casi duso

30 Casi duso

31 Diagramma dei casi duso > Il significato della relazione > è che il caso duso Ordinare Computer Configurato può essere esteso dal cliente con il caso duso Richiedere Contatto Commerciale

32 Altri esempi > Inserire Piano di Studi include sempre Convalidare piano di studi : ogniqualvolta il piano di studi è inserito, deve essere anche convalidato

33 … ancora Generalizzazione: Il manager Servizi clienti è un tipo di Impiegato Servizi Cliente il quale, a sua volta, è un tipo di Impiegato

34 Documento dei requisiti 1. Premessa 1.1 Obiettivo e scopo del prdotto 1.2 Contesto di business 1.3 Stackeholders 1.4 Soluzioni preliminari 1.5 Sintesi del docuemnto 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


Scaricare ppt "Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini"

Presentazioni simili


Annunci Google