Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software il processo Processo...

Corso di Laurea Triennale in Ingegneria Corso di Laurea Triennale in Ingegneria InformaticaInformatica

Ingegneria del softwareIngegneria del software

il processoil processo

Processo softwareProcesso software

Ingegneria del Ingegneria del softwaresoftware


Sommario Sommario

1. Prodotto e processo software2. Ciclo di vita del software3. Modelli del processo di sviluppo

1. Modelli a processo prescrittivo2. Modelli

Ingegneria del Ingegneria del softwaresoftware Processo e prodottoProcesso e prodotto

• Prodotto software– Insieme di tutti gli artifatti che permettono l'utilizzo di un

programma da parte di un utente: codice, documentazione, prodotti intermedi quali casi di test, manuali tecnici, ecc.

• Processo software– Insieme organizzato di pratiche (attività) che

sovrintendono alla 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 (maturità del processo)


Corso di Laurea Triennale in Ingegneria Corso di Laurea Triennale in Ingegneria InformaticaInformatica

Ingegneria del softwareIngegneria del software


Modelli di processo Modelli di processo

Ciclo di vita del software



Ciclo di vitaCiclo di vita

• Descrive lo schema secondo cui sono organizzate le varie attività base (fasi) dello sviluppo software: – Specifiche del software, – Progettazione ed Implementazione, – Convalida – Evoluzione.

• Durante la vita del sistema è prevista una singola esecuzione di tutte le fasi di sviluppo

• I cambiamenti ai requisiti causano l’avvio di un nuovo processo di sviluppo

• È indipendente da metodi e strumenti di sviluppo software

• Procedimento “rigido”che non prevede la possibilità di eseguire uno o più passi a ritroso



Obiettivi e limitiObiettivi e limiti

• Propedeutico al processo definito• Richiede controllo di qualità

– Definizione del processo produttivo (standard aziendale) – Identificazione di attività, obiettivi, dipendenze

• Agevola la pianificazione e la gestione dei progetti• È indipendente da metodi e strumenti di sviluppo software



Evoluzione dei modelliEvoluzione dei modelli

• Code-’n-fix: un “non-modello”– Consiste di attività casuali non organizzate– Dà luogo a progetti caotici non gestiti né gestibili

• Modelli a processo prescrittivo– Cascata a rigide fasi sequenziali oppure sue varianti con prototipi e ritorni– Incrementali realizzazione in più passi

• Modello incrementale• (Rapid Application Development) RAD

– Evolutivi modelli ciclici con ripetute iterazioni interne• Prototipi • Spirale contesto allargato a modello astratto

– Modelli specializzati• Sviluppo a componenti • Software orientato dall’aspetto

– Processo unificato• Sviluppo agile

• Extreme programmimg (XP)• Sviluppo di software adattativo (ASD)• Metodo Dynamic Systems Development Method (DSDM)• Metodo Scrum• Crystal• Sviluppo feature driven (FDD)



Il modello a cascataIl modello a cascata

• Definito nel 1970 da Winston Royce• “Managing the development of large software systems: concept and

techniques”

• Una successione di fasi sequenziali– Non consente ritorno a fasi precedenti– Eventi eccezionali fanno ripartire dall’inizio

• Documentazione – Ogni fase produce “documenti” che concretizzano– Emissione ed approvazione di documenti sono condizione necessaria

per l’avvio della fase successiva– Modello “document-driven”



Schema del modello a cascataSchema del modello a cascata



Caratteristiche delle fasiCaratteristiche delle fasi

• Le fasi sono descritte in termini di:– Attività previste e prodotti attesi– Contenuti e struttura dei documenti– Responsabilità e ruoli coinvolti– Scadenze di consegna dei documenti

• Presentano dipendenze causali e temporali• Ciascuna fase determina le proprie attività

Ingegneria del Ingegneria del softwaresoftware ProblemiProblemi

• Problemi legati alla eccessiva rigidità– Il cliente deve essere in grado di enunciare

esplicitamente tutti i requisiti– Non ammette modifiche nei requisiti in corso d’opera– Richiede molta manutenzione– Solo alla fine del processo il cliente riceve una versione

funzionante del software– La natura lineare del modello porta a stati “bloccanti”,

nei quali alcuni membri del team devono attendere che i loro colleghi completino una certa attività




Varianti del modello a cascataVarianti del modello a cascata

• Variante 1: cascata con prototipazione• Prototipo “usa e getta”, solo per capire meglio i requisiti

• Variante 2: cascata con ritorni• Entrambe raggruppano sotto-sequenze di fasi



Modelli iterativiModelli iterativi

• Applicabili a qualunque modello generale di ciclo di vita• Necessità di adattamento ai cambiamenti

• Evoluzione di problemi, soluzioni possibili e tecnologie utilizzabili• Diversificazione dei requisiti del committente

• Soluzione generale• Decomporre la realizzazione del sistema• Differire la realizzazione delle componenti critiche

• Le iterazioni devono essere pianificate



Modello incrementaleModello incrementale

• Analisi e progettazione sono definitive• I requisiti sono identificati completamente• L’architettura del sistema è identificata e fissata• I passi della realizzazione incrementale sono pianificati

• La realizzazione è incrementale• Progettazione di dettaglio, codifica e prove• Integrazione e collaudo

• Accettazione e rilascio di versioni parziali• Dai requisiti essenziali (prima) a quelli desiderabili (poi)



Schema del modello incrementaleSchema del modello incrementale

Analisi e progettazione

Progettazione di dettaglio

Realizzazione

Accettazione di versione



Modello evolutivoModello evolutivo

• Analisi preliminare• Per identificare i requisiti di massima• Per definire l’architettura di massima• Per pianificare i passi di analisi e realizzazione evolutiva

• Analisi e realizzazione di evoluzione• Per raffinamento ed estensione dell’analisi• Per progettazione, codifica, prove e integrazione

• Rilascio di prototipi, accettazione finale



Schema del modello evolutivoSchema del modello evolutivo



Il modello a spiraleIl modello a spirale

• Proposto da Barry W. Boehm nel 1988• Prevede quattro attività principali

• Definizione degli obiettivi• Analisi dei rischi• Sviluppo e validazione• Pianificazione

• È un modello astratto: va specializzato



Fasi del modello a spiraleFasi del modello a spirale

• Definizione degli obiettivi– Requisiti, identificazione dei rischi, piano di gestione

• Analisi dei rischi– Studio delle conseguenze, valutazione delle alternative con

l’ausilio di prototipi e simulazioni• Sviluppo e validazione

– Realizzazione del prodotto• Pianificazione

– Decisione circa il proseguimento, pianificazione del ciclo di vita



Schema del modello a spiraleSchema del modello a spirale



Aspetti del modello a spiraleAspetti del modello a spirale

• Pone grande attenzione sugli aspetti organizzativi• Pianificazione delle fasi• Analisi dei rischi( modello “risk-driven”)

• Richiede forte interazione tra committente e fornitore– Committente: definizione degli obiettivi, pianificazione– Fornitore: sviluppo e validazione– Entrambi: analisi dei rischi

• Applicabile ai cicli tradizionali



Altri modelliAltri modelli

• Modelli agili

• Extreme Programming– Facilita il coinvolgimento (informale) del committente

• Non solo nell’analisi, ma anche in progettazione e sviluppo• Fortemente incrementale ( a passo piccolo)


• Component-based• Massima attenzione al riuso sistematico di

componenti preesistenti proprie od “off-the-shelf”




Schema del modello component-Schema del modello component-basedbased

Analisi delle

componenti

Adattamento dei requisiti

Analisi dei requisiti

Progettazione e riuso

Sviluppo ed integrazione

Validazione di sistema

Ingegneria del Ingegneria del softwaresoftware Sviluppo agileSviluppo agile

• Introdotto nel 2001– K. Beck et al. “Manifesto for agile software

development”, www.agilemodeling.com.

• È focalizzato più sulle persone e le interazioni che sui processi e gli strumenti

• Combina una filosofia e una serie di linee guida per lo sviluppo


Ingegneria del Ingegneria del softwaresoftware ““Filosofia”Filosofia”

• Soddisfazione del cliente e consegna incrementale anticipata del software

• Impiego di gruppi di progettazione compatti e motivati• Impiego di metodi formali• Livello minimo di prodotti collaterali e una generale

semplicità di sviluppo• E’importantissima l’interazione e la collaborazione sia

all’interno del team che con il cliente e l’utente finale• La motivazione del team è fondamentale• Le richieste di cambiamento vengono considerate

positivamente anche se intervengono in fase avanzata. Un team agile è un team in grado di rispondere in modo appropriato ai cambiamenti.



• Fattori umani: competenza, obiettivi comuni, collaborazione, capacità di prendere decisioni, capacità di soluzione creativa dei problemi, reciproca fiducia e rispetto, auto-organizzazione, ecc.

• Il successo dello sviluppo agile dipende dai fattori umani: il processo viene plasmato sulla base delle persone e dei team e non viceversa.

• Per molti tipi di software le fasi di progettazione e costruzione sono parzialmente sovrapponibili cioè possono essere svolte in parallelo in modo che i modelli progettuali possano vengano applicati non appena vengono creati.

• Gli incrementi software (prototipi eseguibili o porzioni di sistemi funzionanti) devono essere forniti con grande frequenza, in modo che l’adattamento tenga il passo dei cambiamenti (imprevedibilità di analisi, progettazione, costruzione e collaudo da punto di vista della pianificazione)


Ingegneria del Ingegneria del softwaresoftware Modelli agiliModelli agili

• Extreme programmimg (XP) – è il modello agile più famoso proposto nel 1999 da Kent Beck.

• Sviluppo di software adattativo (ASD) – modello iterativo per la realizzazione di software e sistemi complessi utilizzando la collaborazione umana, l’auto-organizzazione dei team e l’apprendimento dei singoli membri del team.

• Dynamic Systems Development Method (DSDM) – modello iterativo simile al modello RAD per sistemi che rispondono a vincoli temporali molto rigidi che suggerisce che in ciascun incremento venga svolto solo il lavoro utile per facilitare il passaggio all’incremento successivo.

• Scrum–modello che fornisce frequenti incrementi software definendo le unità di lavoro necessarie per ottenere un’insieme a priorità di requisiti (sprint) e svolgendo riunioni brevi quotidianamente.

• Sviluppo feature driven (FDD) – modello più “formale” che concentra il team di sviluppo sulle funzionalità che hanno valore per il cliente e che possono essere implementate al massimo in due settimane. Rispetto agli altri modelli agili privilegia la progettazione e la gestione della qualità.


Ingegneria del Ingegneria del softwaresoftware Extreme programmingExtreme programming

• Prevede quattro attività strutturali:– Pianificazione– Progettazione– Programmazione– Collaudo

• E’ strettamente connesso all’adozione di metodologie object-oriented su tutto il processo

• Pone un’enfasi molto forte sul test, che viene visto come un’attività da avviare il prima possibile

• La collaborazione tra utenti (cliente) e gruppo di sviluppo è centrale in tutto il processo




Schema dell’ XPSchema dell’ XP



Costo del cambiamentoCosto del cambiamento



Riepilogo Riepilogo

• Il ciclo di vita• Il modello a cascata• Il modelli iterativi• Il modello a spirale



Riferimenti bibliograficiRiferimenti bibliografici

• Testo:

• Altri riferimenti– B.W. Bohem, “A spiral model of software development and

enhancement”, IEEE software, maggio 1998.– W.W. Royce, “Managing the development of large software systems:

concepts and techniques”, Proceedings of “Wescon’70”, agosto 1970.

Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software il processo Processo...

Documents

Transcript of Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software il processo Processo...