Scelta di un modello di processo: esempio

Modelli di processo e richiesta del committente Quantità di requisiti Partizionabilità dei requisiti Stabilità requisiti Tipo SW Richiesta innovativa Disponibilità dei requisiti Cascata Alta Qualunque Anche SW critico; non privilegia il tempo Rilascio incrementale Alta per singolo incremento Meno adatto al SW critico; privilegia il tempo anche se non come RAD Discreta Prototipo evolutivo Buona per singolo incremento/ raffinamento Anche SW critico; con attenzione al tempo Prototipo usa e getta Scarsa Poco adatto al SW safety-critical

Commenti alle Attività Generiche per i rappresentare i modelli di processo

Attività Generiche (Pressman) Principali: Comunicazioni; Pianificazione; Modellazione; Costruzione, Dispiegamento Collaterali/Ombrello: controllo (monitoraggio del progetto), gestione dei rischi; valutazione della qualità; revisioni tecniche formali; misurazioni; gestione delle configurazioni; gestione del riuso; preparazione e produzione del prodotto Il tentativo è concentrarsi il più possibile sulla natura principale delle attività, limitando le informazioni sulla sequenza delle attività

Attività Generiche (Pressman) Communication (Comunicazioni) Planning (Pianificazione) Modeling (Modellazione) Requirements specification (modellazione analitica) Design (modellazione progettuale) Construction (Costruzione) Code generation (generazione codice) Testing (collaudo) Deployment (Dispiegamento) Attenzione: sul testo Deployment è tradotto come Implementazione, cioè in modo non corretto.

Comunicazioni E’ un’attività necessaria alla comprensione (o deduzione) dei requisiti del software che mette in evidenza la fondamentale comunicazione tra differenti ruoli Anche se non è esplicito, può essere utile per la scelta del modello di processo da adottare; può essere utile per la negoziazione dei tempi e dei costi di progetto (fattibilità economica) Produce, nella visione di Pressman, il documento dei requisiti; l’attività di modellazione produce (e non solo) invece il modello di analisi dei requisiti (modello analitico o specifica dei requisiti) E’ tuttavia ragionevole che una seppur minima attività di modellazione dei requisiti potrebbe svolgersi internamente alla comunicazione se la modellazione è svolta con l’obiettivo di comunicare e cioè di deduzione dei requisiti (§5.2); ed è anche ragionevole che nella comunicazione vi sia una, seppur minima, attività di pianificazione (§5.2)

Modellazione L’attività di modellazione è, secondo Pressman, quell’attività necessaria alla specifica dei requisiti (o modello analitico) usando qualche notazione, a partire dal documento dei requisiti; l’attività di modellazione si estende poi anche alla progettazione del software quindi alla specifica del software (o modello di progetto), garantendo una transizione corretta e completa Due elementi fondamentali che possono essere modellati secondo Pressman: I requisiti del software, Il software entrambe sotto le condizioni di tempi, costi e risorse, al fine di valutare le alternative possibili, in accordo alla qualità accettabile del prodotto software Ma non è pensabile che questa attività venga fatta in modo indipendente dalle comunicazioni con il committente (§7.4)

Visione per Attività Generiche Operative Fattibilità (comunicazione) Determinazione (Raccolta) dei requisiti (può comprendere la deduzione e la negoziazione dei requisiti) (comunicazione) Specifica dei requisiti (modellazione analitica) Progettazione del software (modellazione progettuale) Codifica (costruzione) Test (costruzione) Installazione (dispiegamento) Manutenzione Pianificazione e Contollo Verifica e Validazione

Visione per Attività Operative Permangono alcune ambiguità: si tratta del software stesso ovvero di un suo prototipo Determinazione dei requisiti --- di cosa? Progettazione --- di cosa? la determinazione dei requisiti può in certi casi contenere molti elementi di specifica dei requisiti o, eventualmente, coincidere (ed infatti talvolta le due attività si trovano sotto il nome di analisi dei requisiti) Ad esempio, la specifica dei requisiti (o parte di essa) permette di verificare (anche formalmente) l’esistenza di conflitti (inconsistenze) tra requisiti distinti e quindi, diventa strumento fondamentale anche per determinare i requisiti stessi Le attività generiche operative danno un’idea della sequenza e di cosa effettivamente deve essere fatto

Relazioni tra Attività Generiche Fattibilità: Comunicare (quanto basta) Pianificare (quanto basta) Modellare (quanto basta) Determinazione dei requisiti: Comunicare (molto) Pianificare (dipende) Modellare (dipende) Costruire (dipende) Specifica dei requisiti: Modellare analiticamente (molto) Fare il meno possibile per capire se si può fare (ovvero come farlo al meglio)! Fare il più possibile per capire cosa si deve fare esattamente! Fare il più possibile per descrivere precisamente cosa deve essere fatto, in modo da poterlo fare!

Visione per Obiettivi Ingegneria di sistema Permette di capire esattamente cosa dovrebbe fare il sistema=software+ambiente del software (requisiti del sistema) Ingegneria dei requisiti (del software) Sulla base di cosa dovrebbe fare il sistema, determina e specifica i requisiti del software Ingegneria della progettazione (del software) Sulla base della specifica dei requisiti del software, tenendo presente gli aspetti di qualità del software, specifica l’architettura del software e, su questa base, specifica le componenti software più semplici

Ingegnerie ed Attività Le tre ingegnerie prevedono sia più attività generiche operative sia più attività generiche secondo Pressman Meglio concentrarsi sulle Ingegnerie che risultano relativamente meno ambigue e con obiettivi ben definiti

Esempio Punto di partenza: la richiesta del committente Possibile contenuto della richiesta del committente: Cosa, dal suo punto di vista, si vorrebbe fare (problem statement) Eventuali vincoli La motivazione del perché si vorrebbe fare (cioè il contesto in cui si andrà ad inserire sia il software che dovrà essere sviluppato, in relazione all’ambiente in cui tale software opererà: Software+Ambiente=Sistema) Quando si vorrebbe avere e quanto dovrebbe costare Eventuali sistemi esistenti ed eventuale visione d’insieme di tali sistemi (correlazioni) I benefici che dovrebbero ottenersi In quali condizioni il software risultante può essere considerato un successo

Esempio: precisazione E’ tuttavia possibile che una richiesta del committente sia in realtà il prodotto di un’attività di sviluppo del software svolta dal committente stesso o n P l a i g M d e C s t r u c D p y m v f b k o n P l a i g M d e C s t r u c D p y m v f b k Richiesta Richiesta (potrebbe già essere un vero e proprio documento dei requisiti)

Richiesta di Esempio (I) Realizzare un sistema di supporto alla vendita di biglietti, con o senza prenotazione, per treni, in modo che sia utilizzabile via web anche direttamente dall’utente finale….continua Il tempo di consegna è tre anni dalla data d’inizio (esclusa la fattibilità) Il costo, del solo sviluppo del software, dovrebbe essere attorno a 5 M euro Il costo della fattibilità dovrebbe essere attorno a 100 000 Euro. Si pensa rendere un servizio utile alla clientela e permettere una razionalizzazione delle risorse aziendali interne Il successo dell’iniziativa è dovuto ai seguenti fattori: Il sistema è usato dagli utenti (clienti) Il sistema garantisce rigidamente che un biglietto può essere usato solo per il numero di persone per cui tale biglietto è stato emesso

Richiesta di Esempio (II) Si vuole sviluppare un sistema per il controllo del movimento di ascensori…continua Il costo previsto non deve essere superiore a 1 M Euro e deve essere terminato in 1,5 anni Il sistema deve essere robusto e evitare qualunque tipo di incidente Il sistema dovrebbe permettere agli utenti di ottenere l’ascensore nel tempo massimo di 1’