Unità di Apprendimento 5: Gestione di progetti informatici e requisiti software

Unità di apprendimento 5

Gestione di progetti informatici 0110110110101010100110110101010 TTOLIOLIO 101010 0101 011101001010 00 1010 01110101010100101 101010100101/ DIOT C IO SOTOOUnità di apprendimento 5 Lezione 3 Progetto: fattibilità e analisi dei requisiti 0110110110101010100110110101010 TTOLIOLIO 0101 101010 DIOT C IO SOTOO 011101001010 00 1010 01110101010100101 101010100101In questa lezione impareremo ...

• le diverse tipologie di requisiti software
• i requisiti utente e i requisiti di sistema
• i requisiti funzionali e i requisiti non funzionali

3/21

Il processo di produzione del software

Ciclo del processo produttivo del software:

• Progetto che si suddivide in due parti:
• Preprogetto che si suddivide a sua volta in due fasi:
• Studio di fattibilità o preanalisi: raccolta dei requisiti dell'utente modello utente), modello funzionale, dei dati e tecnologico e prima valutazione dei rischi e dei costi con un preventivo di massima;
• Pianificazione: stesura del WBS e valutazione del lavoro, dei tempi e dei costi
• Progetto in cui si formula il preventivo o il bando di gara d'appalto derivanti dall'analisi dei requisiti, arrivando alla composizione e stipula del contratto fra le parti.

4/21

Studio di fattibilità

Lo studio di fattibilità parte da una idea di progetto nata a seguito dell'individuazione di una situazione insoddisfacente emersa da audit della qualità, dalla consapevolezza di una nuova necessità di adeguamento tecnologico o da un'analisi dei processi e della loro redditività. Deve analizzare i seguenti aspetti:

• Tecnico: se tecnologicamente è possibile realizzare il progetto
• Organizzativo: impatto del progetto nell'azienda
• Motivazionale: il nuovo sistema deve essere desiderato dai fruitori
• Economico: analisi costi/benefici
• Temporale: individuazione di un tempo di realizzazione accettabile del progetto

5/21

Scomposizione dello studio di fattibilità

Lo studio di fattibilità può essere scomposto in due sotto- fasi:

• Analisi dei requisiti dell'utente: descrizione ad alto livello di COSA realizzare e prima stima dei costi.
• Preanalisi e valutazione dei costi: definizione delle specifiche e scomposizione del progetto in base alle esigenze tecniche, organizzative e di risorse finanziare e umane. Si valutano i costi e i tempi per definire l'effettiva realizzabilità del progetto.

6/21

Ingegneria dei requisiti

Analisi dei requisiti dell'utente: descrizione ad alto livello di COSA realizzare e prima stima dei costi:

• Analisi del problema: cosa deve fare il sistema software in base alle necessità degli utenti, l'ambiente in cui verrà usato, le condizioni di mercato e di funzionamento.
• Definizione delle funzionalità: operatività, vincoli interni ed esterni, prestazioni,
• Redazione del SRS (Software Requirements Specificaion o Specifica dei Requisiti Software): documento in cui si formalizzano i requisiti raccogliendo le specifiche tecniche e funzionali del sistema.
• Convalida delle specifiche: analisi e validazione da parte del committente del SRS.

7/21

Requisiti software e stakeholder

Un requisito è costituito da qualsiasi informazione, comunque ottenuta, circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare. La definizione dei requisiti rappresenta:

• l'analisi completa dei bisogni dell'utente;
• l'analisi del dominio del problema; e ha lo scopo di definire quello che il sistema deve fare. Le persone coinvolte nel processo sono gli stakeholder, individuati fra coloro che in qualche modo sono interessate alla messa in opera del sistema, a ogni livello dell'organizzazione. Gli stakeholder forniscono spesso una descrizione astratta e imprecisa del sistema. Spetta all'analista rielaborarle per ottenere una descrizione dettagliata e matematica dello stesso, per evitare successivi errori difficili da recuperare.

8/21

Classificazione dei requisiti software

I requisiti software possono essere classificati secondo due diversi punti di vista:

• Livello di dettaglio:
• requisiti utente (user requirements)
• requisiti di sistema (system requirements)
• Tipo di requisito che rappresentano:
• requisiti funzionali
• requisiti non funzionali
• requisiti di dominio

9/21

Livello di dettaglio dei requisiti

• Requisiti utente: sono le esigenze sentite dall'utente finale e descritte con il suo linguaggio.
• Requisiti di sistema: vincoli tecnologici esistenti, vincoli fiscali e/o legislativi (sicurezza, privacy, contabilità CEE). Esempio: Requisito utente
• L'applicazione deve visualizzare file esterni prodotti da altri pacchetti. Requisito di sistema
• L'utente deve poter definire il tipo di file esterni.
• Ad ogni tipo di file deve essere associato il tool che lo ha generato.
• Ad ogni tipo di file deve essere associata un'icona che lo rappresenti.
• L'utente deve poter scegliere l'icona per un certo tipo di file.
• Selezionando l'icona del file deve essere eseguita l'applicazione in grado di visualizzarlo.

10/21

Tipo di requisito: funzionali e non funzionali

• Requisiti funzionali: funzionalità che il sistema deve avere, cioè i servizi forniti agli utenti. Devono essere completi e coerenti. Facilmente verificabili in sede di collaudo. Esempi:
• L'utente deve poter fare ricerche sia sull'intero insieme di dati, sia su un suo sottoinsieme.
• Ad ogni nuovo ordine deve essere associato un identificatore unico.
• Requisiti non funzionali: imposti dalle modalità operative e i vincoli imposti dall'organizzazione o dall'esterno. Difficili da verificare in sede di collaudo. Esempio:
• I documenti di progetto devono essere conformi allo standard XY-010.
• Il sistema software non deve rilasciare ai suoi operatori nessuna informazione personale relativa ai clienti, tranne nominativo e identificatore.
• Il tempo di risposta del sistema all'inserimento della password dell'utente deve essere inferiore ai 10 secondi.

11/21

Tipo di requisito: di dominio

Requisiti di dominio: dipendono dal dominio in cui il sistema deve operare (riservatezza, leggi della fisica e/o della tecnologia, regole matematiche, normative, ecc.). Facilmente verificabili in sede di collaudo. Esempi:

• I documenti di rendiconto contabile devono essere stampati alla ricezione e cancellati subito dopo.
• Richiesta di login tramite user-id e password per accedere ad un'area protetta. Esempio generico - Carta di credito (requisiti funzionali, non funzionali, di dominio) Una banca rilascia ai suoi clienti una carta di credito con la quale è possibile effettuare il pagamento degli acquisti e, presso uno sportello, effettuare il prelievo di contanti, visualizzare il saldo e l'estratto conto. Il sistema deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 e deve essere disponibile a persone portatori di Handicap. Le operazioni di pagamento possono essere fatte entro un limite massimo mensile e quelle allo sportello richiedono una autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile e adattabile alle future esigenze bancarie.

12/21

Raccolta dei requisiti

La raccolta dei requisiti è detta anche fase di esplorazione:

• Si parte dall'esame delle richieste del committente (chi ha richiesto il progetto).
• Si individuano gli stakeholder da coinvolgere, con cui dialogare per esplorare il problema e raccogliere le informazioni che diventeranno la parte centrale per la definizione dei requisiti.
• Si procede con l'esplorazione, che può essere effettuata avvalendosi di tecniche diverse.

13/21

Tecniche di esplorazione: interviste individuali

• Interviste individuali: possono essere strutturate e mirate ad un aspetto particolare, riguardanti, ad esempio, un requisito già individuato e che richiede di essere dettagliato. Possono essere effettuate a diverse figure:
• al committente: lui stesso indicherà i possibili stakeholder più significativi fra il personale;
• agli stakeholder: più persone saranno intervistate, maggiori saranno le informazioni che si potranno ottenere, anche se queste potrebbero essere contradditorie (dipende dai diversi punti di vista).

14/21

Criteri di scelta e domande per gli stakeholder

Tecniche di esplorazione:

• Esempi di criteri per la scelta degli stakeholder:
• chi usa il sistema e con quali compiti;
• chi ottiene informazioni dal sistema;
• chi dà informazioni al sistema;
• quali persone sono da più anni nell'organizzazione;
• chi sono gli attori esterni che interagiscono con l'organizzazione.
• Esempi di domande da porre agli stakeholder:
• quali attività svolge;
• descrivere il flusso normale delle attività;
• descrivere cosa può andare male nel flusso delle attività;
• cosa non funziona nel sistema attuale;
• come credi che debba essere usato il sistema;
• cosa ti aspetti quando parte il sistema;
• come vorresti usare il sistema.

15/21

Tecniche di esplorazione: questionari e focus group

Tecniche di esplorazione:

• Questionari: insiemi di domande strutturate, da sottoporre a più persone contemporaneamente, al fine di ottenere delle statistiche. Di solito, contengono affermazioni con 5 possibili risposte (scala di Likert): completamente d'accordo, d'accordo, incerto, in disaccordo, in completo disaccordo.
• Focus group (gruppi di discussione): un mediatore cerca di condurre un brainstorming in cui ognuno esprime le proprie opinioni. Lo scopo è cercare di confrontare tutti i contributi. C'è la possibilità che emergano soluzioni condivise dal gruppo. Il mediatore deve essere molto abile.

16/21

Tecniche di esplorazione: osservazioni e analisi

Tecniche di esplorazione:

• Osservazioni sul campo: si affianca l'utente durante il suo lavoro in quanto spesso si hanno difficoltà nel descrivere le proprie funzioni o nell'evidenziare i punti critici. E' un metodo efficace ma oneroso.
• Suggerimenti spontanei degli utenti: gli utenti danno suggerimenti ed opinioni utilizzando appositi forum.
• Analisi della concorrenza e dei best practice: possibile se ci sono prodotti già simili sul mercato. Si cerca di analizzare le soluzioni, i punti di forza, i best practice (esperienze migliori).

17/21

Validazione dei requisiti

Validazione dei requisiti: Una volta raccolti, i requisiti devono essere validati. L'operazione è fatta insieme agli utenti di riferimento ricercando gli eventuali conflitti e le sovrapposizioni, quindi si apportano le modifiche necessarie. Questo avviene prima della stesura del documento di SRS. Dopo la revisione, ogni requisito è identificato con un codice anche di tipo gerarchico, come visto per la WBS.

18/21