Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Modelli del Ciclo di Vita del Software: come si fanno (o si dovrebbero fare) i sistemi software
Fausto Fasano
Fausto Fasano
Fausto Fasano
Fausto Fasano
Fausto Fasano
Fausto Fasano
10
Modello a Cascata
Fausto Fasano
11
Studio di fattibilit
Valutazione preliminare di costi e benefici Varia a seconda della relazione committente/ produttore Obiettivo
Stabilire se avviare il progetto, individuare le possibili opzioni e le scelte pi adeguate, valutare le risorse umane e finanziarie necessarie
definizione preliminare del problema scenari - strategie alternative di soluzione costi, tempi, modalit di sviluppo per ogni alternativa
Corso di Ingegneria del Software 12
Fausto Fasano
Fausto Fasano
13
Progettazione
Definizione di una struttura opportuna per il SW Scomposizione del sistema in componenti e moduli
allocazione delle funzionalit ai vari moduli definizione delle relazioni fra i moduli
Distinzione fra:
architectural design: struttura modulare complessiva (componenti) detailed design: dettagli interni a ciascuna componente
Deployment: distribuzione e gestione del software presso lutenza Manutenzione: evoluzione del SW.
Segue le esigenze dellutenza. Comporta ulteriore sviluppo per cui racchiude in s nuove iterazioni di tutte le precedenti fasi
Fausto Fasano
15
Contro
requisiti congelati alla fine della fase di analisi requisiti utente spesso imprecisi: lutente sa quello che vuole solo quando lo vede n lutente n il management possono giudicare prima della fine delladesione del sistema alle proprie aspettative
Fausto Fasano
16
Nella realt
Di norma le specifiche del prodotto sono incomplete o inconsistenti Lapplicazione evolve durante tutte le fasi
Non esiste una netta separazione tra le fasi di specifica, progettazione e produzione overlap e ricicli esistono! in alcuni casi auspicabile sviluppare prima una parte del sistema e poi completarlo (utente finale = mercato)
Fausto Fasano
17
Fausto Fasano
Verifica: Stabilire la verit della corrispondenza tra un prodotto software e la sua specifica Convalida: Stabilire lappropriatezza di un prodotto software rispetto alla sua missione operativa
verification Integrazione e test di sistema V&V Messa in esercizio V&V Manutenzione Re-validation
Verification: are we building the product right ? Validation: are we building the right product ? (B. Boehm)
Fausto Fasano
19
... Feedback
Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
Ian Sommerville
Fausto Fasano
20
Il Modello a V
Analisi e specifica dei requisiti Progetto di sistema Progetto di dettaglio Validazione requisiti Messa in servizio e manutenzione Testing di accettazione Verifica design Testing di sistema Testing di unit e integrazione codifica
Fausto Fasano Corso di Ingegneria del Software 21
Sviluppo evolutivo
Concurrent activities Specification Initial version Intermediate versions
Outline description
Development
Validation
Final version
Ian Sommerville
Fausto Fasano
23
Fausto Fasano
24
Prototipazione (1)
mock-ups: produzione completa dellinterfaccia utente. Consente di definire con completezza e senza ambiguit i requisiti (si pu, gi in questa fase, definire il manuale di utente) breadboards: implementazione di sottoinsiemi di funzionalit critiche del SS, non nel senso della fattibilit ma in quello dei vincoli pesanti che sono posti nel funzionamento del SS (carichi elevati,tempo di risposta,...), senza le interfacce utente. Produce feedback su come implementare la funzionalit (in pratica si cerca di conoscere prima di garantire).
Fausto Fasano
25
Prototipazione (2)
Prototipazione throw-away
Pervenire ad una migliore comprensione dei requisiti del prodotto da sviluppare Lo sviluppo dovrebbe avviarsi con la parte dei requisiti meno compresa
Prototipazione esplorativa
Pervenire ad un prodotto finale partendo da una descrizione di massima e lavorando a stretto contatto con il committente Lo sviluppo dovrebbe avviarsi con la parte dei requisiti meglio compresa
Fausto Fasano
26
Il prototipo uno strumento di identificazione dei requisiti di utente; incompleto, approssimativo, realizzato utilizzando parti gi possedute o routines stub. Il prototipo deve essere gettato !
Fausto Fasano
27
Prototipi preliminari
Obiettivo lavorare con i clienti ed evolvere i prototipi verso il sistema finale. Si dovrebbe avere unidea chiara dei requisiti ben compresi
Prototipi
Sviluppo evolutivo
Problemi
Perdita di visibilit del processo Spesso il prodotto finito scarsamente strutturato Sono richieste competenze specifiche nelluso di linguaggi di prototipazione rapida (RAD) Perdita di visibilit del processo da parte del management
Applicabilit
Per sistemi interattivi di taglia medio-piccola Per parti di sistemi pi grandi (esempio sviluppo UI) Per sistemi con un ciclo di vita breve
Fausto Fasano
29
Trasformazioni formali
Lo sviluppo viene visto come una sequenza di passi che trasformano formalmente una specifica in una implementazione
Formal transformations T1 T2 T3 T4
Formal specification
R1
R2
R3
Executable program
P1
Ian Sommerville
P2
P3
P4
Fausto Fasano
30
Trasformazioni formali
Problemi
Competenze e skill specifici per lapplicazione delle tecniche Difficolt nella specifica formale di parti del sistema (ad esempio linterfaccia utente) Costi di sviluppo in genere pi elevati Il committente non comprende le specifiche formali
Applicabilit
Giustificata nello sviluppo di sistemi critici (safety o security)
Fausto Fasano Corso di Ingegneria del Software 31
prevede repository di componenti riusabili a diversi livelli di astrazione, prodotti durante le diverse fasi del ciclo di vita durante lo sviluppo di un nuovo sistema:
specifiche, progetti, codice, test case, ... riuso di componenti esistenti popolamento delle repository con nuove componenti
Fausto Fasano
33
Sviluppo incrementale
Risolve la difficolt a produrre lintero sistema in una sola volta nel caso di grandi progetti SW Le difficolt possono essere sia del produttore che del committente - questultimo potrebbe non avere limmediata disponibilit finanziaria necessaria per lintero progetto Il prodotto viene consegnato con pi rilasci
Fausto Fasano
34
Modello incrementale
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, o insieme di attivit, di integrazione di nuovi sottosistemi prodotti con quelli gi in esercizio
Define outline requirements Assign requirements to increments Design system architecture
Integrate increment
Fausto Fasano
35
Testing pi esaustivo
I rilasci iniziali agiscono come prototipi e consentono di isolare requisiti per i successivi incrementi I servizi a pi alta priorit sono anche quelli che vengono maggiormente testati
Fausto Fasano
36
ogni versione aggiunge nuove funzionalit/sottosistemi da subito sono presenti tutte le funzionalit/sottosistemi che vengono successivamente raffinate, migliorate
Fausto Fasano
37
Incrementale vs Iterativo
Incrementale
Iterativo
Fausto Fasano
38
Extreme programming
Approccio recente allo sviluppo del software basato su iterazioni veloci che rilasciano piccoli incrementi delle funzionalit Partecipazione pi attiva del committente al team di sviluppo Miglioramento costante e continuo del codice (verifica e adeguamento in tempi estremamente ridotti)
Fausto Fasano
39
Modello a spirale
Formalizzazione del concetto di iterazione
Ha il riciclo come fondamento
Il processo viene rappresentato come una spirale piuttosto che come sequenza di attivit
Ogni giro della spirale rappresenta una fase del processo Le fasi non sono predefinite ma vengono scelte in accordo al tipo di prodotto Ogni fase prevede la scoperta, la valutazione e il trattamento esplicito dei rischi
E un meta-modello
Possibilit di utilizzare uno o pi modelli Il ciclo a cascata si pu vedere come un caso particolare (una sola iterazione)
Fausto Fasano
40
REVISIONE rischi
Piano dei requisiti a del ciclo di vita Piano di sviluppo Piano di integrazione test
Simulazioni, modellazione, benchmark Esplorazione dei concetti Requisiti SW Design Detailed prodotto design Validazione codifica requisiti
Fausto Fasano
41
Fausto Fasano
42
I modelli ed il rischio
Cascata
alti rischi per sistemi nuovi, non familiari per problemi di specifica e progetto Bassi rischi nello sviluppo di applicazioni familiari con tecnologie note
Prototipazione
bassi rischi per le nuove applicazioni, specifica e sviluppo vanno di pari passo alti rischi per la mancanza di un processo definito e visibile
Trasformazionale
alti rischi per le tecnologie coinvolte e le professionalit richieste
Fausto Fasano
43
Fausto Fasano
44
Fausto Fasano
45
Output documents Feasibility study, Outline requirements Requirements document Functional specification, Acceptance test plan Draft user manual Architectural specification, System test plan Interface specification, Integration test plan Design specification, Unit test plan Program code Unit test report Module test report Integration test report, Final user manual System test report Final system plus documentation
46