Ciclosoftware PDF

Il ciclo di vita del software
Il ciclo di vita del software Il ciclo di vita del software

IS IS
Contenuti
Il ciclo di vita  Il ciclo di vita del software
 Il modello a cascata
del SW
IS 

Modelli iterativi
Il modello a spirale
Ingegneria del Software  Altri modelli
V. Ambriola, G.A. Cignoni,
C. Montangero, L. Semini  Seminario: cicli di vita in ISO/IEC 12207
Aggiornamenti : T. Vardanega (UniPD)
Dipartimento di Informatica, Università di Pisa 1/36 Dipartimento di Informatica, Università di Pisa 2/36

IS IS
Il concetto di ciclo di vita – 1 Il concetto di ciclo di vita – 2
 Concezione → sviluppo → utilizzo → ritiro  Un ciclo di vita concreto attua processi di progetto
 Istanziati a partire dal modello dei processi definiti
 Per identificare le attività necessarie
 Ci basiamo su modelli generici, indipendenti dal progetto / prodotto  Pone vincoli su pianificazione e gestione del progetto
 Decomponiamo le fasi in attività
 Adottiamo una terminologia consistente  È indipendente da metodi e strumenti di sviluppo
 Precede e non segue la loro selezione
 Per organizzare le attività
 Identifichiamo le dipendenze tra i loro ingressi e le loro uscite  Richiede un sistema di qualità|g| per garantire e
 Fissiamo il loro ordinamento nel tempo misurare conformità|g| e maturità|g|
 Definiamo criteri di completamento e di avanzamento
 Temi che approfondiremo in una prossima lezione
IS 2012 - Ingegneria del Software 1


IS IS
Evoluzione dei modelli Modello sequenziale (a cascata) – 1
 “Code-’n-Fix” : un non-modello  Definito nel 1970 da Winston W. Royce

 Attività eseguite senza organizzazione preordinata  “Managing the development of large software systems:
concepts and techniques”
 Risulta in progetti caotici non gestiti né gestibili
 Successione di fasi rigidamente sequenziali
 Modelli organizzati (alcuni …)  Non ammette ritorno a fasi precedenti
 Cascata rigide fasi sequenziali  Eventi eccezionali fanno ripartire dall’inizio
 Incrementale realizzazione in più passi
 Prodotti
 Evolutivo con ripetute iterazioni interne
 Principalmente “documenti”, fino a includere il SW
 A spirale contesto allargato e modello astratto  Emissione e approvazione di documenti come condizione necessaria per
 Agile dinamico, a cicli iterativi e incrementali l’avvio della fase successiva (modello «document driven»)

IS IS
Modello sequenziale (a cascata) – 2 Modello sequenziale (a cascata) – 3
 Ogni stato di vita (fase) è caratterizzato da pre-  Ogni fase viene definita in termini di
condizioni di ingresso e post-condizioni di uscita  Attività previste e prodotti attesi in ingresso e in uscita
 Il loro soddisfacimento è dimostrato da prodotti costituiti prima da  Contenuti e struttura dei documenti
documentazione e poi da SW
 Responsabilità e ruoli coinvolti
 Le fasi sono distinte e non si sovrappongono  Scadenze di consegna dei documenti
 Adatto allo sviluppo di sistemi complessi sul piano  Presentano dipendenze causali e temporali
organizzativo
 Le iterazioni costano troppo per essere un buon mezzo di  Ciascuna fase comporta azioni specifiche
mitigazione dei rischi tramite approssimazioni successive  Realizzate come attività erogate dai processi coinvolti


IS IS
Schema generale Schema secondo ISO 12207
Le iterazioni
Analisi sono parte della Analisi
manutenzione
Progettazione Progettazione
5.3.2 AR sistema
• Fattibilità 5.3.4 AR software
• Requisiti
Realizzazione Insieme dei processi primari Realizzazione
• Specifica 5.3.3 DA sistema
5.3.5 DA software
• Architetturale Processo “Sviluppo”
5.3.6 DD software
• Dettaglio Manutenzione Manutenzione
Attività del processo “Sviluppo”
• Codifica 5.3.7 Codifica software
5.3.8 Integrazione software
• Prove
5.3.9 Collaudo software
• Integrazione AR: analisi dei requisiti 5.5 Manutenzione
5.3.10 Integrazione sistema
• Correzione DA: progetto (design) architetturale
• Collaudo DD: progetto (design) di dettaglio 5.3.11 Collaudo sistema
• Adattamento
• Miglioramento

IS IS
Correttivi del modello sequenziale Correttivi: iterazione o incremento?
 Difetto principale: eccessiva rigidità  Non sempre gli stakeholder comprendono dall’inizio
 Stretta sequenzialità tra fasi ogni aspetto del sistema richiesto
 Non ammette modifiche nei requisiti in corso d’opera
 In tal caso bisogna decidere cosa sia meglio fare per aiutare
 Richiede molta manutenzione
 Se il problema è molto complesso conviene prevedere iterazioni
 Esprime una visione burocratica e poco realistica
 Ma le iterazioni possono essere distruttive e eliminare e rimpiazzare lavoro precedente
 Correttivo 1: prototipazione  Non sempre è desiderabile rimandare alle fasi finali

 Prototipo di tipo “usa e getta” l’integrazione di tutte le parti del sistema (big bang)
 Solo per capire meglio i requisiti
 In tal caso è meglio l’integrazione successiva di piccole parti
 Questo è un procedimento incrementale
 Correttivo 2: cascata con ritorni
 Ogni ciclo di ritorno raggruppa sottosequenze di fasi  Iterazione e incremento coincidono quando la
sostituzione raffina ma non ha impatto sul resto


IS IS
Vantaggi dei modelli incrementali Vantaggi dei modelli iterativi
 Possono produrre “valore” a ogni incremento  Sono applicabili a qualunque modello di ciclo di vita
 Un insieme non vuoto di funzionalità diventa presto disponibile  Consentono maggior capacità di adattamento
 I primi incrementi possono corrispondere a fasi di prototipazione
 Evoluzione di problemi, soluzioni possibili e tecnologie utilizzabili
 Che aiutano a fissare meglio i requisiti per gli incrementi successivi
 Diversificazione dei requisiti del committente
 Ogni incremento riduce il rischio di fallimento  I requisiti restano stabili solo in casi molto rari
 Senza però azzerarlo a causa dei costi aggiuntivi derivanti dalle  Soluzione generale
eventuali iterazioni
 Decomporre la realizzazione del sistema
 Le funzionalità essenziali sono sviluppate nei primi  Identificare e trattare prima le componenti più critiche
incrementi  Quelle più complesse
 Oppure quelle i cui requisiti non sono sufficientemente chiari
 Attraversano più fasi di verifica
 E quindi diventano più stabili con ciascuna iterazione  Ma il numero di iterazioni va limitato superiormente

IS IS
Modello incrementale – 1 Modello incrementale
 Prevede rilasci multipli e successivi  Analisi e progettazione architetturale non ripetute

 Requisiti principali sono identificati e fissati completamente
 Ciascuno realizza un incremento di funzionalità
 Architettura del sistema è identificata e fissata definitivamente
 Essenziale per pianificare i cicli di incremento
 I requisiti utente sono classificati e trattati in
base alla loro importanza strategica  La realizzazione è incrementale
 Attività di progettazione di dettaglio, codifica e prove
 I primi rilasci puntano a soddisfare i requisiti più importanti
 Prima i requisiti essenziali poi quelli desiderabili
 I requisiti importanti sono stabili dall’inizio  Integrazione, collaudo, eventuale rilascio
 Quelli meno importanti possono stabilizzarsi in corso di sviluppo


IS IS
5.3.1 Istanziazione Numero di iterazioni
del processo
Analisi e
Progettazione
Progettazione
5.3.2 AR sistema di dettaglio
5.3.3 DA sistema
Accettazione
5.3.4 AR software
5.3.5 DA software Realizzazione
5.3.6 DD software 5.3.9 Collaudo software
5.3.11 Collaudo sistema
Le iterazioni sono La validazione è
parte dello sviluppo anch’essa incrementale 5.3.7 Codifica software
Tratto da: Ian Sommerville, Software Engineering, 8th ed.

IS IS
Modello evolutivo – 1 Modello evolutivo – 2
 Aiuta a rispondere a bisogni non inizialmente  Analisi preliminare

preventivabili  Per identificare i requisiti di massima
 Per definire l’architettura di massima
 Per pianificare i passi di analisi e realizzazione evolutiva
 Può richiedere il rilascio e il mantenimento di
più versioni esterne in parallelo  Analisi e realizzazione di evoluzione
 Per raffinamento ed estensione dell’analisi
 Comporta il riattraversamento di fasi di ciclo  Per progettazione, codifica, prove e integrazione
di vita
 Rilascio di “prototipi”, poi accettazione finale


IS IS
Il prototipo diventa
visibile al committente
Analisi
preliminare
Analisi e
5.3.1 Istanziazione Progettazione Prototipo oppure
del processo
Accettazione finale
5.3.2 AR sistema
5.3.3 DA sistema 5.3.3 DA sistema Realizzazione
5.3.4 AR software 5.3.4 AR software 6.6 Revisione
5.3.5 DA software 5.3.5 DA software oppure
5.3.6 DD software 5.3.9 Collaudo software
5.3.11 Collaudo sistema
Ogni fase ammette
5.3.7 Codifica software
iterazioni multiple e Il numero di iterazioni
effettuate è conseguenza
e parallele stessa del ciclo interno!

IS IS
Modello a spirale – 1 Modello a spirale – 2
 Proposto da Barry W Boehm  Pone grande attenzione sugli aspetti gestionali

 IEEE Computer, maggio 1988  Pianificazione delle fasi
 Analisi dei rischi (modello «risk driven»)
 Per miglior controllo dei rischi di progetto
 Richiede forte interazione tra committente e
 Cicli interni rapidi e ripetuti fornitore
 Committente: definizione degli obiettivi
 Dedicati ad analisi e sviluppi prototipali definizione dei vincoli sulla pianificazione
 Fornitore: sviluppo e validazione
 Cicli esterni che aderiscono a un qualsiasi
 Entrambi: analisi dei rischi
altro modello standard di ciclo di vita


IS IS
Modello a spirale – 3 Fasi del modello a spirale
 Prevede quattro attività principali  Definizione degli obiettivi

 Requisiti, rischi, strategia di gestione
 Definizione degli obiettivi
 Analisi dei rischi
 Analisi dei rischi
 Studio delle conseguenze
 Sviluppo e validazione  Valutazione delle alternative con l’ausilio di prototipi e simulazioni
 Pianificazione  Sviluppo e validazione
 Realizzazione del prodotto
 Modello astratto da specializzare  Pianificazione
 Come rappresentarlo in termini dei diagrammi di processo?  Decisione circa il proseguimento
 Pianificazione del proseguimento

IS IS
Schema generale Modello a componenti
Definizione Analisi Analisi dei Analisi delle Adattamento dei
degli obiettivi 2 dei rischi Requisiti Componenti Requisiti
(esplorazione delle alternative)
Valutazione via Progettazione Sviluppo e

con Riuso Integrazione
Prototipi e
Revisioni
3
Validazione
Simulazioni di Sistema
1
 Nasce dall’osservazione che molto di quello che ci serve fare è già stato
fatto e molto di quello che faremo ci potrà servire ancora
Pianificazione Sviluppo e  Massima attenzione al riuso sistematico di componenti preesistenti
del nuovo ciclo 4 Validazione proprie oppure “off-the-shelf”


IS IS
Metodi agili – 1 Metodi agili – 2
 Nascono alla fine del ’90 come reazione alla  L’idea base è il concetto di “user story”
eccessiva rigidità dei modelli allora in vigore
 Un compito significativo che l’utente vuole svolgere con il
 http://agilemanifesto.org/
SW richiesto
 Quattro principi fondanti
1) Individuals and interactions over processes and tools  Ogni “user story” è definita da
 L’eccessiva rigidità ostacola l’emergere del valore
 Un documento di descrizione
2) Working sofware over comprehensive documentation
 La documentazione non sempre corrisponde a SW funzionante  La minuta di conversazioni con il cliente (gli stakeholder in
3) Customer collaboration over contract negotiation generale) per fissare la comprensione comune
 L’interazione con gli stakeholder va incentivata
 La strategia da usare per confermare che il SW realizzato
4) Responding to change over following a plan
 La capacità di adattamento al cambiare delle situazioni è importante
soddisfi gli obiettivi

IS IS
Metodi agili – 3 Scrum – 1
 Migliori assunti base
 È possibile suddividere il lavoro da fare in piccoli incrementi a valore
aggiunto che possono essere sviluppati indipendentemente
 È possibile sviluppare questi incrementi in una sequenza continua
dall’analisi dei requisiti all’integrazione
 Obiettivi strategici
 Poter costantemente dimostrare al cliente quanto è stato fatto
 Verificare l’avanzamento tramite progresso reale
 Dare agli sviluppatori la soddisfazione del risultato
 Assicurare che l’intero prodotto SW è ben integrato e verificato
 Esempi
 Scrum (caos organizzato), Kanban (just-in-time), Scrumban


IS IS
Scrum – 2 Dal dire al fare ...
Un assaggio di metodo agile in stage (D. Giorgini, 2011)

IS IS
Ripartizione dei costi sui modelli Riferimenti
Modello sequenziale
 Applicazioni serie “normali”  W.W. Royce, “Managing the development of large software
 ~ 60% dei costi allo sviluppo systems: concepts and techniques”, Atti della conferenza
Modello iterativo
“Wescon ’70”, agosto 1970
 ~ 40% alla qualifica
 B.W. Bohem, “A spiral model of software development
 I costi complessivi variano al and enhancement”, IEEE Software, maggio 1998
variare del dominio e del tipo
Modello “component-based”
di sistema  Center for Software Engineering,
http://sunset.usc.edu/research/spiral_model
 La ripartizione dei costi sulle
 ISO/IEC TR 15271:1998, Information Technology – Guide
fasi varia al variare del Modello evolutivo for ISO/IEC 12207
modello e del dominio
 Sistemi critici: > 60% qualifica  Scrum: http://www.scrumalliance.org/learn_about_scrum

Ciclosoftware PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ciclosoftware PDF

Caricato da

Copyright:

Formati disponibili

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software

Il ciclo di vita  Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software

IS 2012 - Ingegneria del Software 1

Il ciclo di vita del software Il ciclo di vita del software

 “Code-’n-Fix” : un non-modello  Definito nel 1970 da Winston W. Royce

Il ciclo di vita del software Il ciclo di vita del software

IS 2012 - Ingegneria del Software 2

Il ciclo di vita del software Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software

 Correttivo 1: prototipazione  Non sempre è desiderabile rimandare alle fasi finali

IS 2012 - Ingegneria del Software 3

Il ciclo di vita del software Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software

 Prevede rilasci multipli e successivi  Analisi e progettazione architetturale non ripetute

IS 2012 - Ingegneria del Software 4

Il ciclo di vita del software Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software

 Aiuta a rispondere a bisogni non inizialmente  Analisi preliminare

IS 2012 - Ingegneria del Software 5

Il ciclo di vita del software Il ciclo di vita del software

Tratto da: Ian Sommerville, Software Engineering, 8th ed.

Il ciclo di vita del software Il ciclo di vita del software

 Proposto da Barry W Boehm  Pone grande attenzione sugli aspetti gestionali

IS 2012 - Ingegneria del Software 6

Il ciclo di vita del software Il ciclo di vita del software

 Prevede quattro attività principali  Definizione degli obiettivi

Il ciclo di vita del software Il ciclo di vita del software

Valutazione via Progettazione Sviluppo e

IS 2012 - Ingegneria del Software 7

Il ciclo di vita del software Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software

IS 2012 - Ingegneria del Software 8

Il ciclo di vita del software Il ciclo di vita del software

Un assaggio di metodo agile in stage (D. Giorgini, 2011)

Il ciclo di vita del software Il ciclo di vita del software

IS 2012 - Ingegneria del Software 9

Potrebbero piacerti anche