Ingegneria del Software PDF

Ingegneria del Software 1 Ingegneria del Software Capitolo 1 – Introduzione 1.1 Software: Prodotto e Processo Con l’avvento di computer con hardware più sofisticati, si aprirono le porte alla progettazione di software estremamente più grandi. I primi insuccessi in questo nuovo campo fecero pe...

Ingegneria del Software 1 Ingegneria del Software Capitolo 1 – Introduzione 1.1 Software: Prodotto e Processo Con l’avvento di computer con hardware più sofisticati, si aprirono le porte alla progettazione di software estremamente più grandi. I primi insuccessi in questo nuovo campo fecero però capire che erano necessari metodi e tecniche nuove per la gestione e la produzione di essi. Oggigiorno queste tecniche perfezionate sono inglobate nell’Ingegneria del Software. L’Ingegneria del Software è una disciplina ingegneristica che si concentra nei costi di sviluppo dei sistemi software di grandi dimensioni, sviluppati tramite lavoro di gruppo. È possibile che vengono rilasciate più versioni del prodotto software. Tale attività ha senso per progetti di grosse dimensioni e di notevole complessità dove è necessaria la pianificazione. L’ingegneria del software si occupa principalmente di alcuni aspetti fondamentali: i metodi, le metodologie, i processi e gli strumenti per la gestione professionale del software.  Principi I principi riguardano: - il rigore e la formalità; - l’affrontare separatamente le varie problematiche dell’attività; - la modularità: cioè suddividere un sistema complesso in parti più semplici come la tecnica del dividi et impera. Inoltre, ogni modulo deve essere altamente coeso e tra i moduli deve esserci un basso accoppiamento per garantire l’indipendenza tra essi. - Astrazione: si identificano gli aspetti cruciali in un certo istante ignorando gli altri. - Anticipazione del cambiamento: la progettazione deve favorire l’evoluzione del software. - Generalità: tentare di risolvere il problema nel suo caso generale. - Incrementalità: lavorare a fasi di sviluppo, ognuna delle quali viene terminata con il rilascio di una release, anche se piccola.  Metodi e metodologie Un metodo è una particolare procedimento per risolvere problemi specifici, mentre la metodologia è un insieme di principi e metodi che serve per garantire la correttezza e l’efficacia della soluzione al problema.  Strumenti, procedure e paradigmi Uno strumento è un artefatto che viene usato per fare qualcosa in modo migliore. Una procedura è una combinazione di strumenti e metodi finalizzati alla realizzazione di un prodotto. Un paradigma è un particolare approccio o filosofia per fare qualcosa.  Processo Un processo è un particolare metodo per fare qualcosa costituito da una sequenza di passi che coinvolgono attività, vincoli e risorse. Un processo software è l’insieme di attività che costituiscono la costruzione del prodotto da parte del team di sviluppo utilizzando metodi, tecniche, metodologie e strumenti. È suddiviso in varie fasi secondo uno schema di riferimento (il ciclo di vita del software). Descritto da un modello: informale, semi-formale o formale. 2 1.2 Cos’è il software? Il prodotto software non è solo un insieme di linee di codice ma comprende tutti gli “artefatti” che lo accompagnano e che sono prodotti durante l’intero sviluppo come: il codice, la documentazione, i casi di test, manuali e varie specifiche e procedure di gestione. Quindi il software è un prodotto invisibile, intangibile, facilmente duplicabile ma costosissimo: è un’opera dell’ingegno protetto dalle leggi. Inoltre, al software vanno attribuiti altre due keywords: - Requisito software: funzione o proprietà controllabile (testabile) che deve possedere l’implementazione di un prodotto software. È importante per il cliente. Esempio: l’utente deve poter registrarsi, aggiungere o togliere elementi al carrello, specificare indirizzi alternativi, pagare. - Feature software: l’insieme di funzioni che permettono di usare un prodotto software in un servizio o business. È importante per il fornitore. Esempio: carrello per negozio elettronico. 1.3 Programma vs Prodotto Un programma è una semplice applicazione sviluppata, testata e usata dallo stesso sviluppatore. In altri termini, l’autore è anche il cliente. Il prodotto software viene sviluppato per terzi, è un software industriale che ha un costo circa 10 volte superiore ad un normale programma e deve essere corredato di documentazione, manuali e casi di test. I prodotti possono essere generici oppure specifici: - I prodotti generici sono dei software prodotti da aziende e utilizzati da un ampio bacino di utenza diversificato. - I prodotti specifici sono software sviluppati ad-hoc per uno specifico cliente. Il costo dei prodotti generici è maggiore rispetto a quello dei prodotti specifici ma il maggior sforzo di sviluppo è nei prodotti specifici. 1.4 Ecosistemi software Gli ecosistemi software sono mercati, in cui si vendono prodotti (es. AppStore o PlayStore) o componenti e servizi. La caratteristica principale è quella di una collezione di prodotti software, su una piattaforma definita da un’azienda e che vengono sviluppati ed evolvono nello stesso ambiente. 1.5 Software libero Il “Software libero” è software che rispetta la libertà degli utenti e la comunità e non riguarda il suo prezzo. In breve, significa che gli utenti hanno la libertà di eseguire, copiare, distribuire, studiare, modificare e migliorare il software. Un programma è software libero se gli utenti del programma godono delle 4 libertà fondamentali: 1. Libertà di eseguire il programma come si desidera, per qualsiasi scopo (libertà 0). 2. Libertà di studiare come funziona il programma e di modificarlo in modo da adattarlo alle proprie necessità (libertà 1). L'accesso al codice sorgente ne è un prerequisito. 3. Libertà di ridistribuire copie in modo da aiutare gli altri (libertà 2). 4. Libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti da voi apportati, in modo tale che tutta la comunità ne tragga beneficio (libertà 3). 3 1.6 Costi e Manutenzione Il costo del software viene calcolato in base alle ore di lavoro, il software e l’hardware utilizzato e altre risorse di supporto. Il costo della manutenzione è più elevato rispetto a quello di produzione. Il software dopo il suo rilascio, specie se lo stesso ha una vita lunga, ha bisogno di alcune fasi di manutenzione. Per manutenzione intendiamo sia la correzione di eventuali bug, sia l’estensione/modifica di alcune caratteristiche. 1.7 Dipendenze Ogni prodotto software dipende da altri prodotti software, che a loro volta dipendono da altri software. Associamo a ciascun prodotto o sistema software un grafo di dipendenze. I nodi del grafo delle dipendenze sono pacchetti software (es. librerie) in diverse versioni. Abbiamo diversi tipi di dipendenze:  Dipendenze che controlliamo: questo è un codice scritto e di nostra proprietà o della nostra organizzazione.  Dipendenze che non controlliamo: questo è un codice scritto da un fornitore di terze parti o open-source.  Dipendenze rimosse. 4 Capitolo 2 – Ciclo di vita del Software 2.1 Ciclo di Vita del Software: CVS Il ciclo di vita del software è il periodo di tempo che inizia quando un prodotto software è concepito e termina quando il prodotto non è più disponibile per l'uso. Il ciclo di vita del software in genere include una fase concettuale, una fase dei requisiti, fase di progettazione, fase di implementazione, fase di test, fase di installazione e verifica, funzionamento e fase di mantenimento. Queste fasi possono sovrapporsi o essere eseguite iterativamente. Il ciclo di sviluppo del software, invece, è il periodo di tempo che inizia con la decisione di sviluppare un prodotto software e termina con la consegna del prodotto. Questo ciclo in genere comprende una fase dei requisiti, una fase di progettazione, fase di implementazione, fase di test e, talvolta, fase di installazione e verifica. 2.2 Modelli di CVS Un modello del ciclo di vita del software (CVS) è una caratterizzazione descrittiva o prescrittiva di come un sistema software viene o dovrebbe essere sviluppato. I modelli CVS devono avere le seguenti caratteristiche:  Descrizione dell’organizzazione del lavoro nella software house.  Linee guida per pianificare, dimensionare il personale, assegnare budget, schedulare e gestire.  Definizione e scrittura dei manuali d’uso e diagrammi vari.  Determinazione e classificazione dei metodi e strumenti più adatti alle attività da svolgere. Le fasi principali di un qualsiasi CVS sono le seguenti: 1. Definizione (si occupa del cosa). Determinazione dei requisiti, informazioni da elaborare, comportamento del sistema, criteri di validazione, vincoli progettuali. 2. Sviluppo (si occupa del come). Definizione del progetto, dell’architettura software, traduzione del progetto nel linguaggio di programmazione, collaudi. 3. Manutenzione (si occupa delle modifiche). Miglioramenti, correzioni, prevenzione, adattamenti. Modello a Cascata (Waterfall) Definisce che il processo segua una progressione sequenziale di fasi senza ricicli, al fine di controllare meglio tempi e costi. Inoltre, definisce e separa le varie fasi e attività del processo in modo da minimizzare la sovrapposizione tra di esse. Ad ogni fase viene prodotto un semilavorato con la relativa documentazione e lo stesso viene passato alla fase successiva. I prodotti ottenuti da una fase non possono essere modificati durante il processo di elaborazione delle fasi successive e vengono utilizzati come input per la fase successiva. È consigliato utilizzarlo in una situazione in cui i requisiti sono ben definiti. Vantaggi: facile da comprendere e da applicare. Svantaggi: l’interazione con il cliente avviene solo all’inizio e alla fine del ciclo. I requisiti dell’utente vengono scoperti solo alla fine. Se il prodotto non ha soddisfatto tutti i requisiti, alla fine del ciclo, è necessario iniziare daccapo tutto il processo. 5 Organizzazione sequenziale: fasi alte del processo  Studio di fattibilità: effettua una valutazione preliminare dei costi e dei requisiti in collaborazione con il committente. L’obiettivo è quello di decidere la fattibilità del progetto, valutarne i costi, i tempi necessari e le modalità di sviluppo. Output: documento di fattibilità.  Analisi e specifica dei requisiti: vengono analizzate le necessità dell’utente e del dominio d’applicazione del problema. Output: documento di specifica dei requisiti.  Progettazione: viene definita la struttura del software e il sistema viene scomposto in componenti e moduli. Output: definizione dei linguaggi e formalismi. Organizzazione sequenziale: fasi basse del processo  Programmazione e test di unità: ogni modulo viene codificato nel linguaggio e testato separatamente dagli altri.  Integrazione e test di sistema: i moduli vengono integrati tra loro e vengono testate le loro interazioni. Viene rilasciata una beta-release (release esterna) oppure una alpha-release (release interna) per testare al meglio il sistema.  Deployment: rilascio del prodotto al cliente.  Manutenzione: gestione dell’evoluzione del software. Modello verification e validation (V&V) Questo modello è uguale al modello a cascata, ma con la differenza che vengono applicati i ricicli, ovvero al completamento di ogni fase viene fatta una verifica ed è possibile tornare alla fase precedente nel caso la stessa non verifica le aspettative. Modello a V Le attività di sinistra sono collegate a quelle di destra intorno alla codifica. Se si trova un errore in una fase a destra (es. testing di sistema) si ri-esegue il pezzo della V collegato. 6 Modello basati su prototipo Viene usato un prototipo per aiutare a comprendere i requisiti o per valutare la fattibilità di un approccio. Il prototipo, quindi, è la realizzazione di una prima implementazione, più o meno incompleta da considerare come una ‘prova’, con lo scopo di:  accertare la fattibilità del prodotto;  validare i requisiti. Il prototipo è un mezzo attraverso il quale si interagisce con il committente per accertarsi di aver ben compreso le sue richieste, per specificare meglio tali richieste, per valutare la fattibilità del prodotto. Dopo la fase di utilizzo del prototipo si passa alla produzione della versione definitiva del Sistema Software mediante un modello che, in generale, è di tipo waterfall (a cascata). Abbiamo vari tipi di prototipazione: 1. mock-ups: produzione completa dell’interfaccia utente. Consente di definire con completezza e senza ambiguità i requisiti (si può, già in questa fase, definire il manuale di utente). 2. breadboards: implementazione di sottoinsiemi di funzionalità critiche del sistema, cioè i vincoli pesanti che sono posti nel funzionamento del sistema (carichi elevati, tempo di risposta,...), senza le interfacce utente. Produce feedbacks su come implementare la funzionalità (in pratica si cerca di conoscere prima di garantire). 3. Prototipazione “esplorativa”: si inizia a sviluppare le parti del sistema che sono già ben specificate aggiungendo man mano nuove caratteristiche secondo le necessità fornite dal cliente. 4. Prototipo usa e getta (throw-away): lo scopo di questo tipo di prototipazione è quello di identificare meglio le specifiche richieste dall’utente sviluppando dei prototipi che sono funzionanti. Non appena il prototipo è stato verificato da parte del cliente o da parte degli sviluppatori deve essere buttato via. Modello trasformazionale (o trasformazioni formali) Basato su un modello matematico che viene trasformato da una rappresentazione formale ad un’altra. Questo modello comporta problemi nel personale in quanto non è facile trovare persone con le conoscenze giuste per poterlo implementare. E’ cosigliato questo modello quando si hanno requisiti stabili, sistemi critici per le persone o cose. Modello di sviluppo a componenti E’ previsto una repository dove vengono depositate le componenti sviluppate durante le fasi del ciclo di vita. Le componenti vengono prese dalla repository e riutilizzate quando necessario. Questo modello è particolarmente usato per sviluppare software in linguaggi Object Oriented. Modello incrementale Utilizzato per la progettazione di grandi software che richiedono tempi ristretti o costi alti. Vengono rilasciate delle release funzionanti (deliverables) anche se non soddisfano pienamente i requisiti del cliente. 7 Le fasi alte del processo sono completamente realizzate. Il sistema così progettato viene decomposto in sottosistemi (incrementi) che vengono implementati, testati, rilasciati, installati e messi in manutenzione secondo un piano di priorità in tempi diversi. Diventa fondamentale la fase di integrazione di nuovi sottosistemi con quelli già prodotti. I vantaggi sono la possibilità di anticipare da subito delle funzionalità al committente, poiché ciascun incremento corrisponde al rilascio di una parte delle funzionalità; i requisiti a più alta priorità per il committente vengono rilasciati per prima e c’è un minor rischio di fallimento del progetto. Tra i vantaggi abbiamo anche un testing più esaustivo, infatti, i rilasci iniziali agiscono come prototipi e consentono di individuare i requisiti per i successivi incrementi. I modelli incrementali sono accomunati ai modelli iterativi perché entrambi prevedono successive versioni del sistema:  Sviluppo incrementale: ogni versione aggiunge nuove funzionalità/sottosistemi;  Sviluppo iterativo (evolutivo): da subito sono presenti tutte le funzionalità/sottosistemi che vengono successivamente raffinate, migliorate. Modello a spirale Il processo è visto come una spirale dove ogni ciclo viene diviso in quattro fasi: 1. Determinazione degli obiettivi della fase; 2. Identificazione e riduzione dei rischi, valutazione delle alternative; 3. Sviluppo e verifica della fase; 4. Pianificazione della fase successiva. Una caratteristica importante di questo modello è il fatto che i rischi vengono presi seriamente in considerazione e che ogni fine ciclo produce una deliverables. In un certo senso può essere visto come un modello a cascata iterato più volte. I rischi sono causati da una scarsa chiarezza sui requisiti, sulle tecnologie e sulla strutturazione del sistema. In alcuni casi, sono state scelte tecnologie innovative, per le quali manca l’esperienza nel gruppo di progetto. Per risolvere tali problemi, utilizziamo varie iterazioni e la costruzione di prototipi tra cui:  Prototipi di interazione (interfacce utente): per affrontare i rischi legati all'incertezza sui requisiti.  Prototipi architetturali (realizzazione e test di aspetti infrastrutturali): per affrontare i rischi legati alla scelta delle tecnologie ed i dubbi sulla strutturazione del sistema. Successivamente, quando i rischi principali sono stati messi sotto controllo, ogni iterazione ha lo scopo di costruire, in modo progressivo, nuove porzioni del sistema, via via integrate con le precedenti, e di verificarle con il committente e le altre parti interessate. Vantaggi Rende esplicita la gestione dei rischi, focalizza l’attenzione sul riuso, determina errori in fasi iniziali, aiuta a considerare gli aspetti della qualità e integra sviluppo e manutenzione. Svantaggi Richiede un aumento nei tempi di sviluppo, delle persone con capacità di identificare i rischi, una gestione maggiore del team di sviluppo e quindi anche un costo maggiore. 8 Modello a spirale e valutazione dei rischi Il modello a cascata genera alti rischi per progetti nuovi e bassi rischi nello sviluppo di applicazioni familiari con tecnologie già note. Nel modello a prototipazione si hanno bassi rischi nelle nuove applicazioni, mentre, alti rischi per la mancanza di un processo definito e visibile. Nel modello trasformazionale si hanno alti rischi a causa delle tecnologie coinvolte e delle professionalità richieste. Extreme programming Approccio recente per lo sviluppo del software basato su iterazioni veloci che rilasciano piccoli incrementi delle funzionalità. Abbiamo una partecipazione più attiva del committente al team di sviluppo e un miglioramento costante e continuo del codice. 9 Capitolo 3 – Project Management e Comunicazione 3.1 Project Management Il project management racchiude le attività necessarie per assicurare che un progetto software venga sviluppato rispettando le scadenze e gli standard. Le entità fisiche che prendono parte al project management sono: 1. Buiness manager: definisce i termini economici del progetto; 2. Project manager: amministra le risorse, quantifica il lavoro, assicura che gli obiettivi siano raggiunti. Inoltre, panifica, motiva, organizza e controlla lo sviluppo, seleziona il team di sviluppo, stende i rapporti e le presentazioni. 3. Practitioners: hanno competenze tecniche per realizzare il sistema. 4. Customers (clienti): specificano i requisiti del software da sviluppare. 5. End users (utenti): gli utenti che interagiscono con il sistema. 3.2 Definizione di Progetto Un progetto è un impegno, limitato nel tempo, per raggiungere una serie di obiettivi che richiedono un certo effort (sforzo). Un progetto ha un inizio ed una fine ed è realizzato da un’equipe di persone. Un progetto include: - una serie di risultati per un cliente; - attività tecniche e gestionali necessarie per produrre e consegnare i risultati; - risorse consumate dalle attività (persone, budget). 3.3 Organizzazione del Progetto Un'organizzazione di progetto definisce le relazioni tra le risorse, in particolare i partecipanti in un progetto. Un'organizzazione del progetto dovrebbe definire:  Chi decide (struttura decisionale);  Chi segnala il proprio stato a chi (struttura di segnalazione);  Chi comunica con chi (comunicazione struttura). Inoltre un organizzazione di progetto può essere strutturata in maniera gerarchica in cui il nodo principale (la radice) è il chief executive (amministratore). Inoltre non abbiamo comunicazioni dirette tra i figli di un nodo con i figli di un altro nodo. Con questo tipo di organizzazione la comunicazione è sottocontrollo perché esiste la root che controlla, quantifica e gestisce. Per comunicare allo stesso livello esiste la comunicazione peer-to-peer. In questa organizzazione abbiamo una comunicazione paritaria. 10 3.4 Attività del project manager Il project manager si occupa della: - stesura della proposta di progetto; - stima del costo del progetto; - pianificazione (planning) e temporizzazione (scheduling); - monitoraggio e revisioni del progetto; - selezione e valutazione del personale; - stesura di rapporti e presentazioni 3.5 Stesura del piano del Progetto Introduzione Viene definita una descrizione di massima del progetto, vengono consegnati gli elementi con le rispettive date di consegne e vengono pianificati eventuali cambiamenti. Organizzazione del progetto Vengono definite le relazioni tra le varie fasi del progetto, la sua struttura organizzativa, le interazioni con entità esterne, le responsabilità di progetto (le principali funzioni e chi sono i responsabili). Processi gestionali Si definiscono gli obiettivi e le priorità, le assunzioni, le dipendenze, i vincoli, i rischi con i relativi meccanismi di monitoraggio, pianificazione dello staff. Processi tecnici Vanno specificati i sistemi di calcolo, i metodi di sviluppo, la struttura del team, il piano di documentazione del software e viene pianificata la gestione della qualità. Pianificazione del lavoro, delle risorse umane e del budget Il progetto viene diviso in tasks e a ciascuno assegnata una priorità, le dipendenze, le risorse necessarie e i costi. Le attività devono essere organizzate in modo da produrre risultati valutabili dal management. I risultati possono essere milestone (rappresenta il punto finale di un’attività di processo ) o deliverables (risultato fornito al cliente). 3.6 Scheduling di progetto Divide il progetto in attività e mansioni (tasks) e stima il tempo e le risorse necessarie per completare ogni singola mansione. Vengono organizzate le mansioni in modo concorrente, per ottimizzare la forza lavoro e minimizza la dipendenza tra le singole mansioni per evitare ritardi dovuti all’attesa del completamento di un’altra mansione. Sono necessari intuito ed esperienza. Problemi dello Scheduling È difficile stimare la difficoltà dei problemi ed il costo di sviluppo di una soluzione. La produttività non è proporzionale al numero di persone che lavorano su una singola mansione. Infatti, aggiungere personale in un progetto in ritardo può aumentare ancora di più il ritardo. 11 3.7 Grafico delle attività (PERT) Abbiamo diversi tipi di rappresentazione grafica dello scheduling del progetto, tra cui il grafico PERT che mostra la suddivisione del lavoro in attività evidenziando le dipendenze e il cammino critico. Le mansioni non devono essere troppo piccole (una settimana o due di lavoro). Il diagramma di PERT si divide in:  ES (earliest start time): il minimo giorno di inizio dell’attività, a partire dal minimo tempo necessario per le attività che precedono.  EF (earliest finish time): dato l’ES e la durata dell’attività, l’EF è il minimo giorno in cui l’attività può terminare.  LF (latest finish time): il giorno massimo in cui quel job deve finire senza che si crei ritardo per i job che dipendono da lui.  LS (latest start time): dato LF e la durata del job, LS è il giorno massimo in cui quel job deve iniziare senza provocare ritardo per i job che dipendono da lui. Il grafico a barre mostra lo scheduling come calendario dei lavori mentre il diagramma di Gannt esprime la temporizzazione. 3.8 Risk management Il management dei rischi identifica i rischi possibili e cerca di pianificarli per minimizzare il loro effetto sul progetto. Un rischio è una probabilità che si verificherà una circostanza negativa. I rischi si dividono in: - Rischi del progetto: influenzano la pianificazione o le risorse; - Rischi del prodotto: influiscono sulla qualità o sulle prestazioni del software in fase di sviluppo; - Rischi aziendali: influenzano sullo sviluppo dell'organizzazione. Identificazione dei rischi I rischi da identificare sono di vari tipi tra cui: - rischi tecnologici; - rischi delle risorse umane; - rischi organizzativi; - rischi nei tools; - rischi relativi ai requisiti; - rischi di stima/sottostima. Le tipologie di rischi sono le seguenti:  Tecnologici: alcune tecnologie di supporto (database, componenti esterne) non sono abbastanza validi come ci aspettavamo.  Risorse umane: non è possibile reclutare staff con la competenza richiesta oppure non è possibile fare formazione allo staff.  Organizzativi: cambiamenti nella struttura.  Strumenti: ad esempio il codice/documentazione prodotto con un determinato strumento non è abbastanza efficiente.  Requisiti: cambiamenti nei requisiti richiedono una revisione del progetto già sviluppato.  Stima: il tempo richiesto, la dimensione del progetto sono stati sottostimati. 12 Analisi dei rischi Ad ogni rischio va assegnata una probabilità che esso si verifichi e vanno valutati gli effetti dello stesso che possono essere: catastrofici, seri, tollerabili, insignificanti. Pianificazione dei rischi Viene considerato ciascun rischio e viene sviluppata una strategia per risolverlo. Le strategie che possiamo prendere possono essere: - Evitare i rischi con una prevenzione; - Minimizzare i rischi; - Gestire i rischi con un piano di contingenza per evitarli. Monitoraggio dei rischi Ogni rischio viene regolarmente valutato e viene verificato se è diventato meno o più probabile, inoltre i suoi aspetti vanno discussi con il management per valutare meglio i provvedimenti da adottare. 3.9 Reporting vs Comunicazione Il reporting supporta la gestione del progetto monitorando lo stato del progetto, ovvero: - Quale lavoro è stato completato? - Quale lavoro è in ritardo? - Quali problemi minacciano l'avanzamento del progetto? Il reporting non è sufficiente quando due squadre hanno bisogno di comunicare, bensì è necessaria: - una struttura di comunicazione; - un partecipante di ogni squadra è responsabile di facilitare la comunicazione tra i due team. Tali partecipanti sono chiamati collegamento. 3.10 Ruolo Un ruolo definisce un’insieme di responsabilità (“to-dos”). Esiste un mapping tra i ruoli e i partecipanti:  One-to-one (uno a uno): c’è un ruolo e un partecipante. E’ ideale ma raro perché con una sola persona si riesce a ricoprire un intero ruolo ma ciò non è sempre facile.  Many-to-Few (molti vero pochi): ogni project manager assume più ruoli ma ciò è pericoloso perché si deve distribuire in più parti.  Many-to-"Too-Many" (molti a troppi): molti partecipanti che non hanno un ruolo significativo e ciò è controproducente. 3.11 Task Un task descrive una porzione di lavoro tracciata dal management; di solito ha un effort di 3 - 10 giorni lavorativi. Un task è specificato da un work package cioè: - la descrizione del lavoro da svolgere; - precondizioni, la durata, le risorse necessarie; - prodotti di lavoro da produrre ecriteri di accettazione; - gestione dei rischi. 13 Un task deve avere anche criteri di completamento cioè include i criteri di accettazione per i work products prodotti dal task. Un work product è il risultato di un task (un documento, una presentazione, un pesso di codice, …). I work products consegnati al cliente sono chiamati deliverables. Task Size I task sono scomposti in varie dimensioni per consentirne il monitoraggio. La size di un task dipende dalla natura del lavoro e da quanto bene il compito è compreso. Per trovare la size appropriata di un task è buona norma fare riferimento ai progetti precedenti. 3.12 Attività L’attività è l’unità di lavoro principale e porta ai milestone utili per misurare il progresso del progetto software. Le attività possono essere raggruppate in step o in fasi. 3.13 Comunicare è fondamentale In grandi effort si passa più tempo a comunicare che a programmare. Un ingegnere del software deve imparare le cosiddette competenze trasversali: - Collaborazione: cioè negoziare i requisiti con il cliente e con membri della sua squadra e di altre squadre; - Presentazione: cioè presentare una parte importante del sistema durante una revisione; - Gestione: facilitare una riunione di squadra; - Scrittura tecnica: scrivere parte della documentazione del progetto. Comunicazione a eventi vs Comunicazione meccanica La comunicazione a eventi è uno scambio di informazioni con obiettivi e può essere:  schedulata: comunicazione pianificata (Esempi: riunione settimanale del team, revisione). Riguarda: - la definizione del problema presentando gli obiettivi, i requisiti e i vincoli; - la review del progetto ponendo l’attenzione sui modelli del sistema e saremo influenzati dai milestone e deriverables; - la review del client concentrandoci sui requisiti. Questa fase è schedulata dopo la fase di analisi. Abbiamo diversi modi per gestire questo tipo di comunicazione: - Walkthrough (Informale): verifichiamo quello che abbiamo fatto e incrementiamo la qualità del sottosistema. Questo è schedulato da ogni team. - Inspection (Formale): l’obiettivo è di verificare che tutto sia in linea con i requisiti. Ad esempio, quando facciamo vedere il sistema finale al cliente. Questo è schedulato dal project management. - Status Review: trova i problemi e li corregge. - Brainstorming: genera e valuta un insieme di soluzioni per poi decidere come proseguire. - Release: calcola il risultato di attività di sviluppo del software. - Postmortem Review: descrive le lezioni imparate. Viene effettuata alla fine del progetto. 14  non schedulata: comunicazione guidata dagli eventi (Esempi: segnalazione del problema, richiesta di modifica, chiarimento). Riguarda: - Richiesta di chiarimenti: comunicazione che avviene tra sviluppatori, clienti e utenti. - Richiesta di modifica: un partecipante segnala un problema e propone una soluzione. Le richieste di modifica sono spesso formalizzate quando il progetto ha una dimensione notevole. - Risoluzione dei problemi: seleziona un'unica soluzione a un problema per il quale sono state proposte più soluzioni. La comunicazione meccanica è uno strumento o una procedura che può essere utilizzata per trasmettere informazione. Può essere:  Sincrona: il mittente e il destinatario stanno comunicando allo stesso tempo. Abbiamo diversi tipi dicomunicazione sincrona: - Hallway conversation: Supporta conversazioni non pianificate, richiesta di chiarimento, richiesta di modifica. I vantaggi è che tale comunicazione è economica ed efficace per risolvere problemi semplici. Gli svantaggi sono la perdita di informazioni e frequenti malintesi. - Meeting (faccia a faccia, telefono, videoconferenza): Supporta conversazioni pianificate, review del cliente, review del progetto, review dello stato, brainstorming, risoluzione dei problemi. Tra i vantaggi abbiamo l’efficacia per la risoluzione dei problemi e la costruzione del consenso. Per gli svantaggi c’è il costo elevato (persone, risorse), larghezza di banda ridotta. - E-mail: Supporta la release, richiesta di modifica, brainstorming. Ideale per comunicazioni pianificate e annunci. Svantaggiose perché possono essere fraintese, inviate a persone sbagliate, o perse. - Gruppo di notizie: Supporta il rilascio, richiesta di modifica, brainstorming. Vantaggioso per la discussione tra persone che condividono un interesse comune ed è economico. - World Wide Web: Supporta il rilascio, richiesta di modifica, ispezioni. Vantaggioso perhcè fornisce all'utente documenti ipertestuali cioè documenti collegati ad altri. Non supporta facilmente documenti in rapida evoluzione.  Asincrono: mittente e destinatario non stanno comunicando allo stesso tempo. 3.14 Problem Statement Il problem statement è sviluppato dal cliente e descrive:  La situazione attuale;  Le funzionalità che il nuovo sistema dovrebbe supportare;  L'ambiente in cui verrà distribuito il sistema;  Deliverable;  Date di consegna;  Criteri di accettazione. 15 Capitolo 4 – Diagramma UML 4.1 Unified Modeling Language (UML) Il modello UML è un linguaggio (e notazione) univerale, per la creazione di modelli software basato sul paradigma orientato agli oggetti. Nello specifico UML è un:  linguaggio per specificare, costruire, visualizzare e documentare gli artefatti di un sistema;  universale perché può rappresentare sistemi molto diversi, da quelli web ai legacy, dalle tradizionali applicazioni Cobol a quelle oject oriented. Quindi UML è un linguaggio di modellazione, non un metodo, né una metodologia, bensì definisce una notazione standard basata su un meta-modello integrato, cioè definisce le relazioni tra i diversi elementi (classi, attributi, moduli, …). UML prevede una serie di modelli diagrammatici basati sul meta-modello. Inoltre, UML non indica una sequenza di processo, cioè non dice “prima bisogna fare questa attività, poi quest’altra”. UML è una notazione data dall’unione di vari modelli sviluppati intorno agli anni ‘90: 1. OMT (Rumbaugh): si rivelava ottimo in analisi e debole nel disegno; 2. Booch: eccelleva nel disegno e peccava in analisi; 3. OOSE (Jacobson): aveva il suo punto di forza nell’analisi dei requisiti e del comportamento di un sistema ma si rivelava debole in altre aree. 4.2 Architettura a 4 livelli UML è basato su un modello architetturale a 4 livelli: Livello Descrizione Esempio Meta-meta-modello Definisce un linguaggio per la specifica dei meta-modelli. Meta-classi, meta-attributi, metaoperazioni, … Meta-modello Definisce un linguaggio per la specifica dei modelli. Classi, attributi, operazioni, … Modello Definisce un linguaggio per la specifica di un certo domionio applicativo. Classi di uno specifico contesto Oggetti Istanze del modello. Oggetti ottenuti istanziando le classi del modello Nell’architettura a 4 livelli di UML ogni livello è un’astrazione di quello sottostante, ed è definito in termini di quello sovrastante. La sintassi astratta di UML viene definita utilizzando la notazione dei metamodelli ed è espressa tramite diagrammi e linguaggio naturale. 16 4.3 Obiettivi di UML  Fornire all’utente un linguaggio di specifica espressivo, visuale e pronto.  Offrire meccanismi di estensibilità e specializzazione del linguaggio.  Essere indipendente dai linguaggi di programmazione e dai processi di sviluppo.  Incoraggiare la crescita dei tool OO commerciali.  Supportare concetti di sviluppo ad alto livello come frameworks, pattern ed i componenti. 4.4 Cosa non è UML  Non è un linguaggio di programmazione visuale (è un linguaggio di specifica visuale).  UML non è un modello per la definizione di interfacce.  UML non è dipendente dal paradigma di sviluppo nel quale può essere utilizzato. 4.5 Modelli per descrivere Sistemi Software La modellazione di un sistema software è data da vari passi: modellazione funzionale + modellazione ad oggetti + modellazione dinamica.  Modellazione funzionale è rappresentata in UML con i case diagrams e descrive la funzionalità del sistema dal punto di vista dell'utente.  Modellazione ad oggetti è rappresentata in UML con i class diagrams e descrive la struttura del sistema in termini di oggetti, attributi, associazioni e operazioni.  Modellazione dinamica è rappresentata in UML con diagrammi di interazione e descrive il comportamento interno del sistema, cioè come il sistema reagisce agli eventi esterni. 4.6 Diagrammi  Use case diagrams: descrivono i comportamenti funzionali del sistemi dal punto di vista dell’utente;  Class diagrams: descrivono la struttura statica del sistema (oggetti, attributi, associazioni);  Sequence diagrams: descrivono i comportamenti dinamici tra gli ogetti del sistema;  Statechart diagrams: descrivono il comportamento dinamico di un solo oggetto;  Activity diagrams: descrivono il comportamento dinamico del sistema, in particolare il suo flusso di lavoro. Use Case Diagrams (Diagrammi dei casi d’uso) Questo tipo di diagramma mostra come deve essere utilizzato il sistema (casi d’uso) e le relazioni tra attori e casi d’uso. Gli attori sono gli utilizzatori del sistema e coloro che interagiscono con esso. Un caso d’uso, quindi, è uno dei modi possibili per usare il sistema, inoltre, descrive l’interazione tra attori e sistema, non la “logica interna” della funzione. Durante la raccolta dei requisiti l’obbiettivo è di realizzare una diagramma dei casi d’uso per capire chi sono gli attori e quali casi d’uso, cioè quali funzionalità, offre il sistema. Un caso d’uso rappresenta un’insieme di funzionalità di un sistema. La descrizione all’interno dovrebbe essere basata su un verbo o su un sostantivo che esprime l’avvenimento. Un caso d’uso è sempre iniziato da un attore detto primario, gli altri attori che interagiscono con quel caso d’uso sono detti secondari. Un attore rappresenta un ruolo assunto da un utente o altra entità; l’attore non è necessariamente umano. 17 Esempio: Abbiamo due attori: il cliente e il cassiere. I casi d’uso sono 3: acquistare articoli, log in, rimborsare articoli venduti. Il diagramma seguente mostra tutte le funzionalità (o casi d’uso) che può eseguire il cliente che non sono altro un sottoinsieme delle funzionalità del cassiere, perché in più ha la funzionalità di effettuare il log in. Le associazioni collegano gli attori ai casi d’uso mediante un arco. Un attore si può associare solo a casi d’uso, classi e componenti. Un caso d’uso non si può associare ad altri casi d’uso riguardanti lo stesso argomento. Inoltre, abbiamo vari tipi di associazione:  Generalizzazione: si ha un associazione tra un attore o caso d’uso ad un altro più generale.  : è una dipendenza tra casi d’uso; il caso incluso fa parte del comportamento di quello che lo include. L’inclusione non è opzionale ed avviene in ogni istanza del caso d’uso. Inoltre, l’inclusione viene usata anche per riutilizzare parti comuni a più casi d’uso. Non si possono formare cicli di include.  : è una dipendenza tra casi d’uso ma a differenza dell’include il verso della freccia è opposto, inoltre, rappresenta un caso eccezionale o che si verifica di rado. 18 Class Diagrams (Diagramma delle classi) Rappresentano la struttura di un sistema, di conseguenza definisce gli elementi base del sistema. Vengono usati durante la fase di analisi dei requisiti, di system design e object design. È possibile definire diagrammi contenenti classi di oggetti con i loro attributi e operazioni, mostra le relazioni tra le classi (associazioni, aggregazioni e gerarchie di specializzazione/generalizzazione) e può essere utilizzato a diversi livelli di dettaglio (in analisi e in disegno). Una classe rappresenta un concetto e racchiude in sé tutti gli oggetti che hanno le stesse proprietà (attributi e operazioni). In UML una classe è composta da 3 parti:  Nome: con la quale è identificata;  Attribuiti: ogni attributo ha un tipo;  Metodi o Operazioni: ogni operazione ha una firma. Inoltre, il nome di una classe è unico. Un oggetto è un qualcosa di identificabile che ricorda il proprio stato e che può rispondere a richieste tramite operazioni relative al proprio stato. Gli oggetti interagiscono tra di loro richiedendo reciprocamente servizi o informazioni: in risposta ad una richiesta, un oggetto può invocare un’operazione che può cambiare il suo stato. Un oggetto ha due tipi di proprietà: 1. attributi (o variabili di istanza), che descrivono lo stato; 2. operazioni (o metodi), che descrivono il comportamento. Un’istanza rappresenta un fenomeno e il suo nome è sottolineato: il nome deve contenere il nome della classe. Un attributo è una proprietà statica di un oggetto e contiene un valore per ogni istanza. Inoltre, i nomi degli attributi devono essere unici all’interno di una classe. Il valore di un attributo non ha identità (non è un oggetto). Per ciascun attributo si può specificare il tipo ed un eventuale valore iniziale. Infine, gli oggetti avranno una loro identità, non bisogna aggiurngerla negli attributi. Gli attributi derivati sono attributi calcolati e non memorizzati: si usano quando i loro valori variano frequentemente e la correttezza (precisione) del valore è importante. Un’operazione è un’azione che un oggetto esegue su un altro oggetto e che determina una reazione. Le operazioni operano sui dati incapsulati dell’oggetto. I tipi di operazione sono: - selettore (query): accedono allo stato dell’oggetto senza alterarlo; - modificatore: alterano lo stato di un oggetto. 19 Le associazioni denotano una relazione tra classi. La molteplicità di un'associazione è usata per indicare il numero di istanze di una classe. La molteplicità di un’associazione può essere: uno - uno uno - molti molti - molti Un aggregazione viene definita come una relazone non forte ovvero una relazione che collega la classe padre a più componenti, ovvero le classi figlie. La composizione viene definita come una relazione forte ovvero esiste l’aggregato (la classe padre) solo se esistono le componenti. I qualificatori sono utilizzati per ridurre la molteplicità (o cardinalità) di un’associazione.  Senza qualificatore  Con qualificatore L'ereditarietà denota una gerarchia "di tipo". L'ereditarietà semplifica il modello di analisi introducendo una tassonomia (o gerarchia). Le classi figlie ereditano gli attributi e operazioni della classe madre. Una responsibility è un contratto o una obbligazione di una classe. Questa è definita dallo stato e comportamento della classe. Una classe può avere un qualsiasi numero di responsabiltà, ma una classe ben strutturata ha una o poche responsabiltità. Le responsibilità possono essere indicate, in maniera testuale, in una ulteriore sezione, sul fondo della icona della class. È possibile specificare la visibiltà di attributi e operazioni attraverso 3 livelli:  + (public): qualsiasi altra classe con visibilità alla classe data può usare l’attributo/operazione (di default se nessun simbolo è indicato);  # (protected): qualsiasi classe discendente della classe data può usare l’attributo/operazione;  - (private): solo la classe data può usare l’attributo/operazione. 20 Sequence Diagrams (Diagramma di sequenza) Il Sequence diagram è utilizzato per definire la sequenza di eventi di un caso d’uso durante la fase di analisi dei requisiti oppure durante il system design. Inoltre, è un diagramma di interazione: evidenzia come un caso d’uso è realizzato tramite la collaborazione di un insieme di oggetti.  le istanze sono definite dai rettangoli;  gli attori da omini stilizzati;  le lifelines sono rappresentate da linee tratteggiate;  i messaggi sono rappresentati da frecce;  le attivazioni sono rappresentate da rettangoli stretti. Il sequence diagram di UML è utile per identificare o trovare oggetti mancanti. La costruzione richiede tempo, ma ne vale la pena. State (o Statechart) Diagrams Gli Statechart Diagrams specificano il ciclo di vita di un oggetto, in particolare, descrivono una sequenza di stati di un oggetto in risposta a determinati eventi. Rappresentano anche le transizioni causate da un evento esterno e l’eventuale stato in cu esso viene riportato. Ogni diagramma di stato inizia con un cerchio scuro che indica lo stato iniziale e termina con un cerchio bordato che denota lo stato finale. Uno stato è una situazione in cui l’oggetto soddisfa qualche condizione, esegue attività o aspetta qualche condizione. Uno stato possiede alcuni attributi che sono opzionali:  nome: una stringa (uno stato può essere anonimo);  entry / exit actions: azioni eseguite all’ingresso / uscita dallo stato. Non sono interrompibili e hanno una durata istantanea;  Transizioni interne: non causano un cambiamento di stato;  Attività dello stato (interrompibile e ha una durata significativa).  Eventi differiti: non sono gestiti in quello stato ma da altri oggetti in un altro stato;  Sottostati: struttura innestata di stati. Possono essere disgiunti (sequenzialmente attivi) o concorrenti (concorrentemente attivi). La transizione è un cambiamento da uno stato iniziale a uno finale. Possiamo avere una:  transizione esterna: stato finale diverso da stato iniziale;  transizione interna: stato finale uguale a stato iniziale. 21 Le transizioni possiedono alcuni attributi opzionali:  evento: può essere un segnale, un messaggio da altri oggetti o un cambiamento;  condizione di guardia: è una condizione booleana verificata all'avvio di una transizione. La transizione si verifica se l’evento accade e la condizione di guardia è vera.  Azione: è eseguita durante la transizione e non è interrompibile; ha una durata istantanea.  Transizione senza eventi (triggerless) si verificano quando:  con guardia: se la condizione di guardia diventa vera;  senza guardia: se l’attività interna allo stato iniziale è completata. La decomposizione OR (o sottostato sequenziale) è un macro stato formato da una scomposizione in OR degli stati. I sottostati ereditano le transizioni dei loro superstati. La decomposizone AND (o concurrent substates) riguarda più stati eseguiti in parallelo. Se un sottostato raggiunge lo stato finale prima dell’altro, quest’ultimo dovrà aspettare la fine dell’altro stato che ancora non ha terminato. Quando avviene una transizione in uno stato con decomposizione AND, il flusso di controllo subisce una fork (il flusso si dirama in due percorsi paralleli) per poi essere ricomposto in un unico flusso tramite una join. Esempio: All’inizio saremo in idle, successivamente tramite una fork avremo uno stato con due sottostati: testing e commanding. Quando i due sottostati saranno entrambi terminati verrà effettuata una join e torneremo nuovamente in idle. Rappresentazione grafica dei vari elementi dei state diagrams: 22 Esempio: telefonata Activity Diagrams Gli activity diagrams forniscono la sequenza di operazioni che formano un’attività più complessa. Permettono di rappresentare processi paralleli e la loro sincronizzazione. Inoltre, possono essere considerati State Diagram particolari perché ogni stato contiene (è) un’azione. Un Activity Diagram può essere associato:  a una classe;  all’implementazione di un’operazione;  ad uno Use Case;  tutto quello che riguarda l’aspetto “funzionale”. Gli activity diagrams servono a rappresentare i workflow (flussi di lavoro) oppure la logica interna di un processo di qualunque livello. In altri termini, li utilizziamo per rendere più chiaro qualcosa che non è complesso o articolato bensì difficile da vedere leggendo il tutto. Quindi, sono utili per modellare:  comportamenti sequenziali;  non determinismo;  concorrenza;  sistemi distribuiti;  business workflow;  operazioni. Tra gli elementi dell’activity diagram abbiamo:  attività: un’esecuzione non atomica entro uno stato. Le attività possono essere gerarchiche.  transizione: è il flusso di controllo tra due attività successive;  guard expression: espressione booleana (condition) che deve essere verificata per attivare una transition;  branch: specifica percorsi alternativi in base a espressioni booleane; un branch ha una unica transition in ingresso e due o più transition in uscita;  synchronization bar: usata per sincronizzare flussi concorrenti;  fork: per splittare un flusso su più transition verso action state concorrenti; 23  join: unifica più transition da più action state concorrenti in una sola. E’ importante bilanciare il numero di fork e di join.  Activity state: stati non atomici (decomponibili ed interrompibili). Un’activity state può essere a sua volta rappresentato con un activity diagram.  Action state: azioni eseguibili atomiche (non possono essere decomposte né interrotte). Un’action state può essere considerata come un caso particolare di activity state. Esempio: La Swimlane è un costrutto grafico che rappresenta un insieme partizionato di action/activity. Identificano le responsabilità relative alle diverse operazioni. In un Business Model, cioè in un’azienda, identificano le unità organizzative. Una swimlane, è identificata da un nome univoco nel diagramma, mentre le action/activity state sono divise in gruppi e ciascun gruppo è assegnato allo swimlane dell’oggetto responsabile. L’ordine con cui gli swimlane si succedono non ha alcuna importanza. Le transition possono attraversare vari swimlanes per raggiungere i vari stati. Gli swimlanes sono: Cliente, Vendite, Magazzino. 24 Gli object flow sono associazioni tra action/activity state e oggetti. Gli object possono essere:  l’output di una action: l’action crea l’object e graficamente abbiamo la freccia della relationship che punta verso l’object (freccia blu).  l’input di una action: l’action ha bisogno dell’object e graficamente abbiamo la freccia che parte dall’object e punta alla relationship (freccia rossa).  manipolati da qualsiasi numero di action: l’output di una action può essere l’input di un’altra action.  presenti più volte nello stesso diagramma: ogni presenza indica un differente punto della vita dell’ object. Esempio: Package Diagrams I packages aiutano a organizzare i modelli UML creati nelle fasi precedenti, in particolare il loro obiettivo è di ridurre la complessità del sistema. Ad esempio, possiamo suddividere un sistema in sottosistemi e ognuno di questi sottosistemi è modellato come un package. Un package raccoglie un insieme di classi che si occupano della parte funzionale del sistema ma può raccogliere anche altri diagrammi. In fase di Manutenzione e Testing le dipendenze diventano di vitale importanza perché le modifiche su un package potrebbero impattare anche su altre parti del sistema e di conseguenza bisogna modificare anche altri packege. 25 Component Diagrams I component diagrams rappresentano l’implementazione del sistema. Un componente rappresenta un pezzo “fisico” dell’implementazione di un sistema. Questi diagrammi definiscono le relazioni fra i componenti software che realizzano l’applicazione come file sorgenti, binari, eseguibili. Un componente ha un nome e una locazione. E’ mostrato, tipicamente, con il solo nome; per le classi è possibile aggiungere altri dettagli. I componenti possono essere raggruppati in package: se i componenti sono file, i package sono cartelle/directory. Le componenti collaborano tra di loro tramite interfacce. Deployment Diagram Il deployment diagram, anche detto diagramma di allocazione o di dislocazione, permette di rappresentare, a diversi livelli di dettaglio, l’architettura fisica del sistema. Permette anche di evidenziare la configurazione dei nodi run-time e dei componenti situati in questi nodi. Gli elementi del deployment diagram sono i nodi e le connesioni che connettono quest’ultimi. Ciascun nodo è identificato da un nome. Un nodo può:  riportare ulteriori dettagli in compartimenti addizionali o usando tagged value.  può essere in connection con altri nodi, ed avere relationship con componenti e altri nodi. 26 Capitolo 5 – Raccolta dei requisiti 5.1 Ingegneria dei requisiti L’ingegneria dei requisiti coinvolge due attività: raccolta dei requisiti e analisi dei requisiti. La raccolta dei requisiti definisce il sistema in termini compresi dal cliente e richiede la collaborazione tra più gruppi di partecipanti con differenti background. Gli errori commessi durante questa fase sono difficili da correggere e vengono spesso notati nella fase di consegna. Alcuni errori possono essere: funzionalità non specificate o incorrette o interfacce poco intuitive. L’analisi dei requisiti definisce il sistema in termini compresi dallo sviluppatore. Quindi, utenti e sviluppatori devono collaborare per scrivere il documento di specifica dei requisiti (prodotto durante la raccolta dei requisiti) in linguaggio naturale per poi essere successivamente formalizzato e strutturato (in UML o altro) durante la fase di analisi per produrre il modello di analisi. Il primo documento (la specifica dei requisiti) è utile al fine di favorire la comunicazione con il cliente e gli utenti, mentre il documento prodotto nell’analisi è usato dagli sviluppatori. La raccolta dei requisiti e l’analisi dei requisiti si focalizzano sul punto di vista dell’utente e definiscono il confine del sistema da sviluppare, in particolare vengono specificate:  Funzionalità del sistema;  Interazione utente-sistema;  Errori che il sistema deve gestire;  Vincoli e condizioni di utilizzo. Non fanno parte dell’attività di raccolta dei requisiti: - la selezione delle tecnologie da usare per lo sviluppo; - il progetto del sistema e le metodologie da usare; - …. in generale tutto quello che non è direttamente visibile all’utente. Inoltre, tramite la raccolta e l’analisi dei requisiti possiamo rispondere principalmente a due domande: 1. Come identifichiamo gli obiettivi del sistema? 2. Cosa c’è all’interno e all’esterno del sistema? Inizialmente dovremmo ridurre la complessità del problema attraverso 3 modalità: 1. l’astrazione; 2. la decomposizione del problema in sottoproblemi (tecnica didivi et impera); 3. la gerarchia (tecnica a livelli). Per affrontare la decomposizione esistono due modi (che possono essere usati entrambi), ovvero attraverso la decomposizione: 1. funzionale; 2. orientata agli oggetti. 27 Quindi all’inizio potremmo procedere con una descrizione delle funzionalità (tramite gli use cases) per poi procedere trovando gli oggetti (modello a oggetti). Questo ci porta a definire il ciclo di vita dello sviluppo del software: cioè un’insieme di attività e delle loro relazioni per supportare il sviluppo di un sistema software. Documento di specifica dei requisiti Il documento di specifica dei requisiti si focalizza sulla descrizione del sistema da sviluppare e viene stilato tramite il contributo del cliente, degli utenti e degli sviluppatori. Tale documento viene usato come contratto tra cliente e sviluppatori. Il documento di specifica dei requisiti viene poi formalizzato e strutturato durante la fase di analisi per produrre il modello di analisi: infatti, gli sviluppatori costruiscono un modello del dominio di applicazione “osservando” gli utenti nel loro ambiente. Entrambi i documenti rappresentano la stessa informazione ma sono scritti usando linguaggi diversi:  la specifica dei requisiti è scritta in linguaggio naturale e supporta la comunicazione tra cliente e sviluppatori;  il modello di analisi si basa su notazioni formali o semi-formali e supporta la comunicazione tra gli sviluppatori. Problem Statement – Statement of Work Il problem statement è sviluppato dal cliente come descrizione del problema che dovrà affrontare il sistema. Un problem statement descrive: - La situazione attuale riguarda il problema da risolvere e la descrizione di uno o più scenari; - Gli obiettivi; - I requirements (funzionalità) che il nuovo sistema dovrebbe supportare; - L'ambiente in cui verrà distribuito il sistema; - Deliverables (risultati) attesi dal cliente; - Date di consegna; - Una serie di criteri di accettazione che andranno verificati per poter dire se il contratto, tra cliente e sviluppatore, è stato rispettato. 28 5.2 Classificazione dei requisiti Le specifiche dei requisiti sono una sorta di contratto tra il cliente e gli sviluppatori e deve essere curata con attenzione in ogni suo dettaglio. Inoltre le parti del sistema che comportano un maggior rischio devono essere prototipate e provate con simulazioni per controllare la loro funzionalità e ed ottenere un riscontro dall’utente. Esistono varie tipologie di requisiti:  Requisiti funzionali: descrivono le interazioni tra il sistema e l’ambiente esterno (utenti e sistemi esterni) indipendentemente dall’implementazione; in particolare vengono descritti i task dell’utente che il sistema deve supportare.  Requisiti non funzionali: descrivono aspetti del sistema che non sono legati direttamente alle funzionalità del sistema. Ad esempio, sono requisiti non funzionali dettagli implementativi come la riusabilità, le performance o il supporto.  Vincoli (Constraints): sono “pseudo requirements” e riguardano cose imposte o dal cliente o dall’ambiente. Tutto ciò che NON riguarda i requisiti sono: - La struttura del sistema e le tecnologie implementate; - La metodologia di sviluppo; - I linguaggi implementati; - L’ambiente usato per sviluppare il softaware; - La riusabilità: lo sviluppatore non deve essere vincolato nello scrivere delle funzioni che poi potrebbero essere riutilizzate per altro. 5.2.1 Validazione dei requisiti I requisiti devono essere continuamente validati con il cliente e l’utente, la validazione degli stessi è un aspetto molto importante perché ha lo scopo di non tralasciare nessun aspetto. I requisiti devono rispettare le seguenti caratteristiche:  Completezza: devono essere presi in considerazione tutti i possibili scenari, inclusi i comportamenti eccezionali;  Consistenza: i requisiti non devono contraddirsi;  Chiarezza: deve essere definito un unico sistema e non si devono interpretare i vari requisiti in modi differenti;  Correttezza: deve rappresentare il sistema di cui il cliente ha bisogno;  Realismo: se il sistema può essere implementato in tempi ragionevoli;  Verificabilità: se una volta che il sistema è stato implementato è possibile effettuare dei test;  Tracciabilità: se ogni requisito può essere mappato con una corrispondente funzionalità del sistema; I problemi che si possono avere con la validazione dei requisiti possono essere: - I requisiti cambiano velocemente durante la loro raccolta; - Incongruenze ad ogni modifica; - È necessario il supporto di determinati tool. 29 5.2.2 Priorità dei requisiti E’ utile classificare i requisiti in base alla loro priorità per progettare meglio il sistema software: - Alta priorità: sono i requisiti affrontati durante l'analisi, la progettazione e l'implementazione; - Priorità media: requisiti affrontati durante l'analisi e la progettazione; - Bassa priorità: requisiti affrontati solo durante l'analisi. 5.2.3 Greenfield engineering, re-engineering, interface engineering Altri requisiti possono essere specificati in base alla sorgente delle informazioni. Il greenfield engineering avviene quando lo sviluppo di un’applicazione parte da zero, senza alcun sistema preesistente. Il re-engineering è un tipo di raccolta dei requisiti dove c’è un sistema preesistente che deve essere riprogettato a causa di nuove esigenze o nuove tecnologie. L’interface engineering avviene quando è necessario riprogettare un sistema per farlo lavorare in un nuovo ambiente. Un esempio possono essere i sistemi legacy che vengono lasciati inalterati nelle interfacce. 5.3 Attività della raccolta dei requisiti 1. Identificare gli attori; 2. Identificare gli scenari; 3. Identificare i casi d’uso; 4. Raffinare i casi d’uso; 5. Identificare le relazioni tra gli attori e i casi d’uso; 6. Identificare gli oggetti partecipanti (verranno ripresi nella fase di analisi); 7. Identificare i requisiti non funzionali. 5.3.1 Identificare gli attori Un attore è un entità esterna che comunica con il sistema e può essere un utente, un sistema esterno o un ambiente fisico. Ogni attore ha un nome univoco ed una breve descrizione sulle sue funzionalità (es. Teacher: una persona; Satellite GPS: fornisce le coordinate della posizione). Un modo molto semplice per identificare gli attori di un sistema è porsi le seguenti domande: - Quali gruppi di utenti sono supportati dal sistema per svolgere il proprio lavoro, quali eseguono le principali funzioni del sistema, quali eseguono le funzioni di amministrazione e mantenimento? - Con quale sistema hardware o software il sistema interagisce? 5.3.2 Identificare gli scenari Uno scenario è una descrizione testuale, informale, concreta e sintetica di un evento o di una serie di azioni ed eventi. In altri termini vengono elencate una serie di passi che un utente svolge per ottenere quella funzionalità. Infatti, la descrizione è scritta dal punto di vista dell’utente finale. Uno scenario può includere testo, video, foto e story telling. Ogni scenario deve essere caratterizzato da un nome, una lista dei partecipanti e un flusso di eventi. 30 Esistono vari tipi di scenari:  As-is-scenario: sono usati per descrivere una situazione corrente. Vengono di solito usati nella raccolta dei requisiti di tipo re-engineering.  Visionary-Scenario: utilizzato per descrivere funzionalità future del sistema. Vengono di solito usati nei progetti di tipo greenfield engineering e re-engineering.  Evalutation-Scenario: descrivono le funzioni eseguite dagli utenti sul quale poi il sistema viene testato.  Training-Scenario: sono tutorial per introdurre nuovi utenti al sistema. L’identificazione degli scenari è una fase che avviene in stretta collaborazione con il cliente e l’utente. Per poter formulare gli scenari bisogna porsi e porre all’utente le seguenti domande: - Quali sono i compiti primari che l’attore vuole che svolga il sistema? - Quali dati saranno creati/memorizzati/cambiati/cancellati o aggiunti dall’utente nel sistema? - Di quali cambiamenti esterni l’attore deve informare il sistema? - Di quali eventi/cambiamenti deve essere informato l’attore? 5.3.3 Identificare gli Use Cases Un caso d’uso descrive una serie di interazioni che avvengono dopo un’inizializzazione da parte di un attore e specifica tutti i possibili scenari per una determinata funzionalità (visto in altri termini uno scenario è un’istanza di un caso d’uso). Alla fine il risultato della raccolta dei requisiti sarà un Use Case Model, cioè l’insieme di tutti gli use cases che specificano tutte le funzionalità del sistema. Per trovare gli use cases possiamo attraversare il sistema in verticale, cioè discutiamo in dettaglio con l'utente per capire le sue preferenze; oppure potremmo muoverci in orizzontale, cioè quando vogliamo capire lo scope del sistema discutendone con l’utente. Quindi riassumendo, ci muoveremo: - verticalmente, quando il sistema è chiaro nella sua interezza; - orizzontalmente, quando non sappiamo con precisione cosa fa il sistema. Se lo scope del sistema non è chiaro potremmo aiutarci con l’uso di prototipi (mock-ups) in cui rappresentiamo graficamente l’utilizzo del sistema. Ogni caso d’uso contiene le seguenti informazioni: 1. Un nome del caso d’uso che dovrebbe includere dei verbi; 2. I nomi degli attori partecipanti che dovrebbero essere sostantivi; 3. Le condizioni di ingresso/uscita (entry/exit condition); 4. Un flusso di eventi in linguaggio naturale e informale; 5. Le eccezioni che possono verificarsi quando qualcosa va male e sonodescritte in modo distinto e separato; 6. I requisiti speciali che includono i requisiti non funzionali e i vincoli. Inoltre, molto importante è la tracciabilità degli use case. Nel flusso di eventi del caso d’uso vengono distinti gli eventi iniziati dagli attori da quelli iniziati dal sistema in quanto quelli del sistema sono più a destra (con un tab) rispetto a quelli dell’attore. 31 Use Cases Associations Le dipendenze tra gli use cases sono rappresentate mediante le relazioni. Le relazioni sono usate per ridurre la complessità: vengono dettagliati gli elementi che sono manipolati dal sistema, dettagliate le interazioni a basso livello tra l’attore e il sistema, specificati i dettagli su chi può fare cosa, aggiunte eccezioni non presenti. I tipi di relazione degli use cases sono 3: 1. : usata per estendere uno use case A in modo da ottenere un nuovo use case B con le funzionalità di A più altre specificate solo in B. L’arco è tratteggiato con l’etichetta e con la linea rivolta verso il caso eccezionale. Inoltre: - la condizione che attiva lo use case B è inserito nella entry condition dello use case B; - non occorre modificare lo/gli use case che vengono estesi; - l’attivazione può avvenire in un punto qualsiasi del flusso di eventi dello use case base; - sono spessi situazioni eccezionali (failure, cancel, help...). 2. : usata per scomporre un caso d’uso in dei casi d’uso più semplici. La freccia dell’arco è tratteggiata, etichettata con ed è rivolta verso il caso d’uso che viene usato. Ad esempio, se il caso d’uso A include il caso d’uso B, allora possiamo dire che A delega parte delle attività che deve svolgere all’use case B. 3. Generalizzazione: usata per fattorizzare più use cases che hanno dei comportamenti in comune. Gli use cases figli ereditano tutti i comportamenti dello use case padre ma aggiungono anche delle nuove funzionalità. 5.3.4 Identificare gli oggetti partecipanti negli Use Cases Durante la fase di raccolta dei requisiti utenti e sviluppatori devono creare un glossario di termini usati nei casi d’uso. Si parte dalla terminologia che gli utenti hanno (quella del dominio dell’applicazione) e successivamente si negoziano cambiamenti. Il glossario creato è lo stesso che viene incluso nel manuale utente finale. I termini possono rappresentare oggetti, procedure, sorgenti di dati, attori e casi d’uso. Ogni termine ha una piccola descrizione e deve avere un nome univoco e non ambiguo. 5.4 Guida alla scrittura dei Casi d’Uso - I nomi dei casi d’uso dovrebbero iniziare con i verbi; - I nomi di Attori dovrebbero essere sostantivi; - I confini del sistema dovrebbero essere chiari; - Le relazioni causali tra passi successivi dovrebbero essere chiare; - Non bisogna usare la forma passiva; - Un caso d’uso dovrebbe descrivere una transizione utente completa; - Le eccezioni dovrebbero essere descritte separatamente; - Un caso d’uso non dovrebbe descrivere un’interfaccia del sistema (meglio attraverso prototipi mock-up); - Un caso d’uso non dovrebbe superare due o tre pagine; se è troppo lungo si usano le relazioni di include o extend. 32 5.5 Requisiti I requisiti esprimono un bisogno, dei vincoli e delle associazioni. Sono scritti in linguaggio naturale e comprendono un soggetto, un verbo e un complemento: bisogna quindi identificare prima l’oggetto del requisito e poi capire che cosa si deve fare. La forma da rispettare è la seguente: [Condition][Subject][Action][Object][Constraint]. Devono essere evitate le ambiguità, gli aggettivi superlativi, frasi vaghe o un linguaggio “amichevole”. Inoltre, vanno evitati gli avverbi e gli aggettivi, le frasi al negativo e le frasi di comparazione (alto come, migliore di, et.). Alcune qualità dei requisiti sono:  l’usabilità: la facilità con cui gli attori possono utilizzare un sistema per eseguire una funzione, inoltre, l'usabilità deve essere misurabile;  la robustezza: la capacità di un sistema di funzionare anche se l'utente inserisce un input sbagliato o se ci sono cambiamenti nell'ambiente;  la disponibilità: il rapporto tra il tempo di attività previsto di un sistema e il tempo di down previsto. Modello FURPS+: Requisiti non Funzionali Chiamati anche requisiti di qualità, sono:  Usabilità: facilità per l’utente di imparare ad usare il sistema, e capire il suo funzionamento. Includono: - convenzioni adottate per le interfacce utenti; - portata dell’Help in linea; - livello della documentazione utente.  Affidabilità: capacità di un sistema o di una componente di fornire la funzione richiesta sotto certe condizioni e per un periodo di tempo. Includono: - un accettabile tempo medio di fallimento; - l’abilità di scoprire specificati difetti o di sostenere specificati attacchi alla sicurezza.  Performance: riguardano attributi quantificabili del sistema come: - tempo di risposta, quanto velocemente il sistema reagisce a input utenti; - throughput, quanto lavoro il sistema riesce a realizzare entro un tempo specificato; - disponibilità, il grado di accessibilità di una componente o del sistema quando è richiesta; - accuratezza.  Supportabilità: riguardano la semplicità di fare modifiche dopo il deployment. Includono: - adattabilità, l’abilità di cambiare il sistema per trattare concetti addizionali del dominio di applicazione; - mantenibilità, l’abilità di cambiare il sistema per trattare nuove tecnologie e per far fronte a difetti. 33 Modello FURPS+: Pseudo requisiti Chiamati anche vincoli, sono:  Implementazione: vincoli sull’implementazione del sistema, incluso l’uso di tool specifici, linguaggi di programmazione, o piattaforme hardware;  Interfacce: vincoli imposti da sistemi esterni, incluso sistemi legacy e formati di scambio;  Operazioni: vincoli sull’amministrazione e sulla gestione del sistema;  Packaging: vincoli sulla consegna reale del sistema;  Legali: riguardano licenze, regolamentazioni, e certificazioni 5.6 Gestire la raccolta dei requisiti Uno dei metodi per negoziare le specifiche con il cliente è il Joint Application Design (JAD), una completa specifica dei requisiti che include definizioni dei dati, flussi di lavoro, e descrizione delle interfacce. E’ stato sviluppato da IBM, e si compone di 5 attività: 6. Definizione del progetto: vengono intervistati il cliente e il project manager e vengono determinati gli obiettivi del progetto (output: Management Definition Guide). 7. Ricerca: vengono intervistati gli utenti attuali e quelli futuri e vengono raccolte informazioni sul dominio di applicazione e descritti ad alto livello i casi d’uso (output: Session Agenda e Preliminary Specification). 8. Preparazione: si prepara una sessione, un documento di lavoro che è un primo abbozzo del documento finale, un agenda della sessione e ogni altro documenti cartaceo utile che rappresenta informazioni raccolte durante la Ricerca. 9. Sessione: viene guidato il team nella creazione della specifica dei requisiti e il team si accorda sugli scenari, i casi d’uso e interfaccia utente mock-up. 10. Documento finale: viene rivisto il documento finale, rivedendo i documenti di lavoro per includere tutte le decisioni prese durante la sessione. Il documento è rivisto durante la sessione (1-2 ore) e completato. Tracciabilità Un altro aspetto importante è la tracciabilità, l’abilità di avere una visione chiara del progetto e rendere meno complessa e lunga un’eventuale fase di modifica ad un aspetto del sistema. Per fare ciò è possibile creare dei collegamenti tra i documenti per identificare meglio le dipendenze tra le componenti del sistema. La tracciabilità viene implementata mediante una matrice di tracciabilità. RAD Il documento dell’analisi dei requisiti (RAD) contiene la raccolta dei requisiti e l’analisi dei requisiti ed è il documento finale del progetto, serve come base contrattuale tra il cliente e gli sviluppatori. Il RAD descrive completamente il sistema in termini di requisiti funzionali e non funzionali; i partecipanti coinvolti sono: cliente, utenti, project manager, analisti del sistema, progettisti. La prima parte del documento, che include Use Case e requisiti non funzionali, è scritto durante la raccolta dei requisiti, mentre, la formalizzazione della specifica in termini di modelli degli oggetti è scritto durante l’analisi. 34 Riassunto: Documento di Analisi dei Requisiti (RAD) 1. Introduction 1.1. Purpose of the system 1.2. Scope of the system 1.3. Objectives and success criteria of the project 1.4. Definition, acronyms, and abbreviations 1.5. References 1.6. Overview 2. Current system 3. Proposed system 3.1. Overview 3.2. Functional requirements 3.3. Nonfunctional requirements 3.4. System models 3.4.1. Scenarios 3.4.2. Use case model 3.4.3. Object model (during analysis) 3.4.4. Dynamic model (during analysis) 3.4.5. User interface – navigational path and screen mock-up 4. Glossary L’analisi dei requisiti produce in output il modello dei requisiti descritto dai seguenti prodotti:  Requisiti non funzionali e vincoli: quali tempo di risposta massimo, minimo throughput, affidabilità, piattaforma per il sistema operativo, etc.  Use Case model: descrive le funzionalità del sistema dal punto di vista degli attori.  Object model: descrive le entità manipolate dal sistema.  Un sequence diagram per ogni use case: mostra la sequenza di interazioni fra gli oggetti che partecipano al caso d’uso. 5.7 User Stories Una user storie è una descrizione informale e in linguaggio naturale delle funzionalità di un sistema software evidenziando chi?, cosa?, perché?. Sono scritti dal punto di vista di un utente finale e possono essere registrati su schede, post-it o digitalmente nel software di gestione dei progetti. A seconda del progetto, le user stories possono essere scritte da diverse parti interessate come cliente, utente, manager o team di sviluppo. 35 Capitolo 6 – Analisi dei requisiti 6.1 Analisi dei requisiti L’analisi dei requisiti è finalizzata a produrre un modello del sistema chiamato modello di analisi che deve essere corretto, completo, consistente e non ambiguo. Infatti, le ambiguità nascono dal modo in cui si comunica oppure dalle assunzioni fatte dagli autori della specifica e non descritte nei dettagli: identificato un problema nella specifica, occorre risolverlo acquisendo maggiore informazioni dal cliente e dall’utente. L’analisi dei requisiti ha come obiettivo quello di tradurre le specifiche dei requisiti in un modello del sistema formale o semiformale:  formalizzando e strutturando i requisiti si acquisisce maggiore conoscenza ed è possibile scoprire errori nelle richieste;  la formalizzazione costringe a risolvere subito questioni difficili che altrimenti sarebbero rimandate. Quindi, viene costruito un modello che descrive il dominio di applicazione. Il modello di analisi descrive come gli attori e il sistema interagiscono per manipolare il modello del dominio di applicazione. Poiché il modello di analisi può non essere comprensibile al cliente e all’utente è necessario modificare anche il documento di specifica delle richieste. Il modello dell’analisi è composto da 3 modelli individuali: 1. Il modello funzionale rappresentato da casi d’uso e scenari; 2. Il modello ad oggetti dell’analisi rappresentato da diagrammi di classi e diagrammi ad oggetti; 3. Il modello dinamico rappresentato da diagrammi a stati e sequence diagram. Gli use case e gli scenari prodotti nella fase di raccolta dei requisiti sono raffinati per produrre il modello ad oggetti e il modello dinamico. Il modello ad oggetti Il modello ad oggetti rappresenta il sistema dal punto di vista dell’utente; si focalizza sui concetti manipolati dal sistema, le loro proprietà e le loro relazioni. Viene rappresentato con un UML class diagram includendo operazioni, attributi e classi. Il modello dinamico Il modello dinamico si focalizza sul comportamento del sistema utilizzando: - sequence diagram: rappresentano l’interazioni di un insieme di oggetti nell’ambito di un singolo caso d’uso; - diagrammi a stati: rappresentano il comportamento di un singolo oggetto o di alcuni oggetti strettamente accoppiati. Lo scopo del modello dinamico è quello di assegnare le responsabilità ad ogni singola classe e quindi identificare nuove classi, nuove associazioni e nuovi attributi. Sia il modello ad oggetti che il modello dinamico rappresentano concetti a livello utente e non componenti sowtare che poi verranno implementate a livello di codice. 36 Modello ad oggetti 6.2 Entity, Boundary e Control object Il modello ad oggetti è costituto da oggetti di tipo entity, boundary e control.  Gli oggetti entity rappresentano informazioni persistenti tracciate dal sistema (oggetti del dominio di applicazione, “oggetti business”).  Gli oggetti boundary rappresentano l’interazione tra attore e sistema (oggetti relativi all’interfaccia utente, oggetti dell’interfaccia dei dispositivi, oggetti di interfaccia del sistema).  Gli oggetti di controllo realizzano i casi d’uso, rappresentano il controllo dei task eseguiti dal sistema, contengono la logica e determinano l’ordine dell’interazione degli oggetti. UML fornisce il meccanismo degli stereotipi per consentire di aggiungere tale meta-informazione agli elementi di modellazione utilizzando le notazioni: