1
Ingegneria del Software 2 – CVS e Processi Software 1
Lezione 2Ciclo di Vita e Processi Software
Ingegneria del Software 2 – CVS e Processi Software 2
Riferimenti bibliografici
• I. Sommerville – Ingegneria del Software – 8a edizione – Cap.4
• R. Pressman- Principi di Ingegneria del Software- 4 edizione- Cap. 3
2
Ingegneria del Software 2 – CVS e Processi Software 3
Obiettivi della lezione
1. Richiamare I concetti di Ciclo di Vita del Software e di Ciclo di Sviluppo Software
2. Classificare I Modelli di Processo Software fondamentali
Ingegneria del Software 2 – CVS e Processi Software 4
Il Ciclo di Vita del Software (CVS)
• Standard IEEE 610.12-1990 (Glossary of Software Engineering Terms)
• Software Life Cycle: The period of time that starts whena software product is conceived and ends when the product is no longer available for use. The software life cycle typicallyincludes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkoutphase, operation and maintenance phase, and sometimes, retirement phase. Note: These phases may overlap or beperformed iteratively. Contrast with Software DevelopmentCycle.
3
Ingegneria del Software 2 – CVS e Processi Software 5
Ciclo di Sviluppo Software
• Standard IEEE 610.12-1990
• Software Development Cycle : (1) The period of time that begins with the decision to develop a software product and ends whenthe product is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Contrastwith Software Life Cycle.
• Notes: The phases listed above may overlap or be performediteratively, depending upon the software development approach used. (2) This term is sometimes used to mean a longer period of time, either the period that ends when the software is no longer being enhanced by the developer, or the entire software life cycle
Ingegneria del Software 2 – CVS e Processi Software 6
Una architettura per la definizione di CVS
• Standard IEEE 12207.0-1996/ 2008 (Software Life-CycleProcesses)
• Software Life Cycle Processes: the Standard defines a framework containing the processes, activities,and tasks in the development, operation and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use
4
Ingegneria del Software 2 – CVS e Processi Software 7
Ciclo di Vita ed i suoi Processi (St.ISO12207-1996)
LIFE CYCLE
SUPPORTING
CONFIGURATION MANAGEMENTDOCUMENTATION
QUALITY ASSURANCE
VERIFICATIONVALIDATION
JOINT REVIEW
AUDIT
PROBLEM RESOLUTION
PRIMARY
DEVELOPMENT
OPERATION
MAINTENANCE
ACQUISITION
SUPPLY
ORGANIZATIONAL
MANAGEMENT
INFRASTRUCTURE
IMPROVEMENT
TRAINING
Ingegneria del Software 2 – CVS e Processi Software 8
Ciclo di Vita ed i suoi Processi (St.ISO12207- 2008 nuova versione)
5
Ingegneria del Software 2 – CVS e Processi Software 9
Processi Software: definizione
• Processo : – un insieme di attività concentrate nel tempo finalizzate alla
realizzazione di un particolare output.• Processo Software:
– Un insieme strutturato di attività necessarie per lo sviluppo diun sistema software.
– Specifica;– Progettazione (o Design);– Validazione;– Evoluzione
• Progetto Software: è un impegno (con date di inizio e fine stabilite) a produrre un prodotto o servizio, con specificate risorse e requisiti
Ingegneria del Software 2 – CVS e Processi Software 10
Modelli di Processo Software
• Un processo software può essere organizzato usando i Modelli di Processo Software:– I Modelli di Processo Software (talora detti ancora
CVS) definiscono la struttura di massima di un processo software, indicando le fasi in cui si articola e i criteri di successione.
– Un Modello di processo software è unarappresentazione astratta di un processo.
– Fornisce una descrizione del processo da unaparticolare prospettiva.
6
Ingegneria del Software 2 – CVS e Processi Software 11
Quali Modelli di Processo Software?
• Una possibile classificazione:
1. Processi basati su documentazione• Basati su linguaggi semi-formali per la specifica dei
documenti (es. UML), e richiedono trasformazioni e controlli manuali dei prodotti intermedi
2. Processi basati su Metodi Formali– Basati su linguaggi formali di specifica, con
trasformazioni e controlli automatici dei prodotti intermedi
3. Approcci AGILI– Uso ridotto di documentazione
Ingegneria del Software 2 – CVS e Processi Software 12
Processi basati su Metodi Formali
• Uso di formalismo matematico per esprimere i requisiti– Es. Specifiche algebriche (es. per tipi di dato astratto)– Es. approccio basato su modelli di stato
• Uso di tecniche di model checking per provare la correttezza sul modello
• Trasformano automaticamente le specifiche in codice– La correttezza è preservata– La verifica è ottenuta implicitamente
DefinizioneRequisiti
SpecificaFormale
Trasformazioneformale
Integrazione e Testing di sistema
7
Ingegneria del Software 2 – CVS e Processi Software 13
Processi basati su Metodi Formali
• Problemi– necessità di specifici skill (in linguaggi matematici)– Impossibilità a specificare formalmente alcune parti – Difficoltà del cliente nella convalida dei requisiti
• Applicabilità– Non adatti per sistemi di grandi dimensioni– Usati solo per parti critiche
Ingegneria del Software 2 – CVS e Processi Software 14
• In questo corso approfondiremo:– (1) Processi basati su documentazione – (3) Processi basati su metodi AGILI
8
Ingegneria del Software 2 – CVS e Processi Software 15
Modelli di Processo dalla letteratura
• Basati su documentazione:– Waterfall– Evolutivo– Basato sul Riuso (di Componenti, Linee di Prodotto…)– Incrementale– A Spirale – Rational Unified Process (UP e RUP) …
• AGILI:– XP (eXtreme Programming) – TDD (Test Driven Development)– Scrum, Lean, …
Ingegneria del Software 2 – CVS e Processi Software 16
Il Waterfall model
DefinizioneRequisiti
Progettazionesoftware
Codifica e Testing di unità
Operatività eManutenzione
Integrazione eTesting di Sistema
9
Ingegneria del Software 2 – CVS e Processi Software 17
• Fasi sequenziali ben definite• Sviluppo Guidato dalla documentazione
ma...
• Troppo rigido/ burocratizzato• Rilascia software solo a completamento di tutte le fasi• Richiede conoscenza immediata e stabilità dei requisiti
Il Waterfall model
Ingegneria del Software 2 – CVS e Processi Software 18
Modello a cascata: una varianteFattibilità
validazione
Analisi e specifica deirequisiti
validazione
Progettazione
verifica
Codificaverifica
Testing
V&V
Messa in esercizio
V&V
Manutenzione
Ri-validazione
Verifica: Stabilire la verità dellacorrispondenza tra un prodotto software e la sua specificaValidazione: Stabilire l’appropriatezza di un prodotto software rispetto alla sua missioneoperativa
Validazione : Stiamo costruendo il prodottogiusto?Verifica : Stiamo costruendo giustamente ilprodotto?
10
Ingegneria del Software 2 – CVS e Processi Software 19
Modello di Sviluppo a V (V-Model)
• Un’altra variante …
• Molto usata per sviluppo di software embedded
Ingegneria del Software 2 – CVS e Processi Software 20
• Basato sull’idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraversovarie versioni. Due modelli fondamentali:
• (A) Sviluppo Esplorativo– L’obiettivo è di lavorare col cliente per esaminare i requisiti
iniziali e farli evolvere fino al sistema finale. Dovrebbepartire da pochi requisiti ben compresi e aggiungere nuovecaratteristiche proposte dal cliente.
• (B) Prototipale (Usa e Getta)– L’obiettivo è di comprendere i requisiti del sistema. Si parte
da requisiti poco chiari e si realizzano prototipi per esplorarei requisiti e chiarirli.
Sviluppo Evolutivo
11
Ingegneria del Software 2 – CVS e Processi Software 21
(A) Sviluppo evolutivo- Esplorativo
DescrizioneRequisitiiniziali
Specificarequisiti
Specificarequisiti
ConvalidaConvalida
SviluppoSviluppo
VersioneFinale
VersioniIntermedie
Versione Iniziale
Ingegneria del Software 2 – CVS e Processi Software 22
(A) Sviluppo evolutivo- Esplorativo
• Vantaggi:– Rapido feedback e possibilità di far cambiare I requisiti
• Problemi– Mancanza di visibilità del processo (è anti-economico
documentare ogni versione del sistema);– I sistemi diventano spessomal strutturati (per i continui
cambiamenti);– Richiedono particolari skills (es. Uso di linguaggi di
prototipazione rapida)• Applicabilità
– A sistemi interattivi di piccole e medie dimensioni (<500.000 LOC);
– Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l’interfaccia utente);
– Per sistemi destinati a vita breve.
• Per grandi sistemi è consigliabile un approccio misto.
12
Ingegneria del Software 2 – CVS e Processi Software 23
(B) Sviluppo Evolutivo- Prototipale
• Realizzazione di una prima implementazione (prototipo), più o meno incompleta da considerare come una ‘prova’, con lo scopo di:– accertare la Fattibilità del prodotto– validare i Requisiti
• Dopo la fase di utilizzo del prototipo si passa alla produzione della versione definitiva del Sistema Sw mediante un modello che, in generale, è di tipo waterfall.
Ingegneria del Software 2 – CVS e Processi Software 24
Modello con Prototipo (Usa e Getta)
REQUISITI PROGETTAZIONEVELOCE
SVILUPPOPROTOTIPO
VALUTAZIONE ERAFFINAMENTO
REQUISITI
SVILUPPO PRODOTTO
CVSCLASSICO
13
Ingegneria del Software 2 – CVS e Processi Software 25
IS basata sul Riuso
• Sviluppo basato sul riuso sistematico, integrandoComponenti esistenti o interi sistemi COTS (Commercial-off-the-shelf)
• Fasi del Processo (CBSE)– Specifica dei requisiti;– Analisi dei componenti;– Modifica dei Requisiti (specificando i componenti disponibili);
– Progettazione con riuso;– Sviluppo e Integrazione.
• Necessita di appositi standard per la specifica dicomponenti.
Ingegneria del Software 2 – CVS e Processi Software 26
Sviluppo basato sul Riuso
SpecificaRequisiti
SpecificaRequisiti
Analisi Dei componenti
Analisi Dei componenti
Modifica deirequisiti
Modifica deirequisiti
Convalida delSistema
Convalida delSistema
Sviluppo E Integrazione
Sviluppo E Integrazione
Progetto del Sistema con riuso
Progetto del Sistema con riuso
14
Ingegneria del Software 2 – CVS e Processi Software 27
Processi di sviluppo Iterativi
• In un ambiente globale di rapidi cambiamenti, è essenziale per la competitività delle aziende che il software di cui necessitanosia sviluppato e consegnato in tempi rapidi!
• La mutevolezza ed instabilità dei requisiti impongono diadottare processi di sviluppo ciclici, in cui il software vieneconsegnato in una serie di incrementi, prodotti in vari cicli diprocesso (iterazioni) in cui si ritorna sulle fasi già condotte
• I cicli di processo possono essere applicati ad ogni genericomodello di processo.
• Due possibili approcci:– (A) Sviluppo e Consegna Incrementale;– (B) Sviluppo a Spirale.
Ingegneria del Software 2 – CVS e Processi Software 28
(A) Sviluppo e Consegna Incrementale
• Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la consegna sono eseguiti per incrementi,dove ogni incremento rilascia parte dellefunzionalità richieste .
– Ai requisiti Utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con I primiincrementi.
– Una volta partito lo sviluppo di un incremento, I relativirequisiti devono essere congelati, mentre I requisiti coinvoltiin incrementi successivi possono continuare ad evolvere.
– I servizi comuni possono essere implementati all’inizio del processo, o quando una funzione è richiesta da un datoincremento.
15
Ingegneria del Software 2 – CVS e Processi Software 29
(A) Sviluppo e Consegna Incrementale
IndividuazionePreliminare requisiti
IndividuazionePreliminare requisiti
Assegnazione requisitiagli incrementi
Assegnazione requisitiagli incrementi
Progettoarchitetturale
Progettoarchitetturale
Integrazionedell’incremento
Integrazionedell’incremento ConvalidaConvalidaConvalida
dell’incremento
Convalidadell’incremento
Sviluppodell’incremento
Sviluppodell’incremento
Sistema Incompleto
SistemaCompleto
Ingegneria del Software 2 – CVS e Processi Software 30
Esempio di processo incrementale
Requisiti: R1, R2, R3Architettura: M1, M2, M3, M4Pianificazione: 3 iterations
Iteration1R1, requires M1, M2Develop and integrate M1, M2Deliver R1
Iteration2R2, requires M1, M3Develop M3, integrate M1, M2, M3Deliver R1 + R2
Iteration3R3, requires M3, M4Develop M4, integrate M1, M2, M3, M4Deliver R1 + R2 + R3
16
Ingegneria del Software 2 – CVS e Processi Software 31
Vantaggi dello sviluppo incrementale
– I clienti non devono aspettare il sistema completoper la consegna, ma possono disporre al più presto dei requisiti più critici, attraverso I primi incrementi.
– I primi incrementi possono essere usati come prototipo per aiutare a definire I requisiti degliincrementi successivi.
– Si riduce il rischio di un fallimento totale del progetto.– I servizi a più alta priorità saranno anche testati più
intensamente degli altri.
Ingegneria del Software 2 – CVS e Processi Software 32
Problemi dello sviluppo Incrementale
• Problemi– Gli incrementi devono essere relativamente piccoli
(<=20.000 LOC) ma può essere difficile predisporre i requisiti in incrementi della dimensione giusta.
– Le funzionalità comuni (richieste da più requisiti) potrebbero non essere identificate abbastanza presto, giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti.
17
Ingegneria del Software 2 – CVS e Processi Software 33
Un esempio: Extreme programming
• Extreme Programming– Un esempio di approccio allo sviluppo basato su
sviluppo e consegna di piccolissimi incrementi difunzionalità.
– Si basa su un continuo miglioramento del codice, sulcoinvolgimento dell’utente nel processo di sviluppo, e sulla programmazione a coppie.
Ingegneria del Software 2 – CVS e Processi Software 34
(B) Sviluppo a Spirale (di Boehm)
• Il processo è rappresentato come una spirale, piuttosto che una sequenza di attività con retro-azioni.
• Ogni giro nella spirale rappresenta una fase del processo.
• Non prevede fasi prefissate a priori (come la specifica o il design) ma i cicli sono definiti in base al caso specifico.
• C’è una esplicita gestione dei rischi che vengonovalutati e risolti durante tutto il processo.
• Metamodello perché comporta la selezione di un modello di CVS da adottare nello sviluppo.
18
Ingegneria del Software 2 – CVS e Processi Software 35
Modello di sviluppo a spirale
Riskanalysis
Riskanal ysis
Riskanal ysis
Riskanal ysis Pr oto-
type 1
Pr ototype 2
Pr ototype 3Oper a-tionalpr oto ype
Concept ofOper ation
Simula tions , models , benchmar ks
S/Wrequir ements
Requir ementv alidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
Integ ra tiontest
AcceptancetestService De velop , verify
ne xt-level pr oduct
Evalua te alterna tives,identify, resolv e risks
Deter mine objecti ves,alterna tives and
constr aints
Plan ne xt phase
Integ rationand test plan
De velopmentplan
Requir ements planLife-cycle plan
REVIEW
1. Determinazione di obiettivi, alternative e
vincoli
3. Sviluppo e Verifica del prodotto4. Pianificazione
della fase successiva
2. Valutazione di alternative,
identificazione e risoluzione dei
rischi
Ingegneria del Software 2 – CVS e Processi Software 36
Settori del modello a spirale
• Determinazione degli obiettivi– Definizione di obiettivi , vincoli e piano di gestione della
fase.
• Valutazione e riduzione del rischio– Si analizzano I rischi della fase e si scelgono le attività
necessarie a gestire I rischi.• Sviluppo e Convalida
– Si sceglie un modello di sviluppo per il sistema tra I modelli generici.
• Pianificazione– Il progetto viene revisionato e si decide se continuare con
un nuovo giro della spirale. Si pianifica tale giro.
19
Ingegneria del Software 2 – CVS e Processi Software 37
• Il RUP (Rational Unified Process)– Un esempio di modello di processo “ibrido”
Ingegneria del Software 2 – CVS e Processi Software 38
Unified Process (UP) Booch, Rumbaugh, Jacobson (autori sia di UML che UP)
UML (Unified ModelingLanguage)
• Linguaggio per la modellazione e costruzione di sistemi software.
• È Standard OMG (ObjectManagement Group) dal 1997
UP (Unified Process)
• È il processo definito dai tre autori per lo sviluppo con utilizzo di UML
• Non è uno standard
• La versione commerciale è nota come RUP (RationalUnified Process) creata da IBM
20
Ingegneria del Software 2 – CVS e Processi Software 39
Rational Unified Process (RUP)
• Un moderno modello di processo software derivato da UML e dal relativo processo.
• Include tutte le caratteristiche dei modelli generici(sviluppo iterativo ed incrementale)
• Individua 3 prospettive sul processo: – Una prospettiva dinamica che mostra le fasi del
modello al fluire del tempo;– Una prospettiva statica che mostra le attività
(workflow) coinvolte;– Una prospettiva pratica che suggerisce le buone
regole da seguire.
Ingegneria del Software 2 – CVS e Processi Software 40
Prospettiva dinamica: Le fasi del RUP
Phase iteration
Inception Elaboration Construction TransitionAvvio Elaborazione Costruzione Transizione
Iterazione delle fasi
21
Ingegneria del Software 2 – CVS e Processi Software 41
Le fasi del RUP
• Avvio– Stabilire gli obiettivi di business (e relativi limiti, fattibilità e
giustificazioni economiche) per il sistema.
• Elaborazione– Ottenere una comprensione del dominio del problema (e
specificare i requisiti), stabilire una struttura architetturaleed il piano di progetto.
• Costruzione– Progettare, programmare e testare il sistema
incrementalmente.
• Transizione– Trasferire il sistema nel suo ambiente operativo.
Ingegneria del Software 2 – CVS e Processi Software 42
Fasi, Iterazioni ed Incrementi
Avvio Elaborazione Costruzione Transizione
Release ReleaseReleaseReleaseReleaseReleaseRelease
It. Avvio It. Elab. It. Costr . It. Trans.
• Ogni fase può essere eseguita in modo ciclico (più iterazioni) , con risultati sviluppati in modo incrementale.
• Anche l’intero sistema delle fasi può essere ripetuto ciclicamente.
22
Ingegneria del Software 2 – CVS e Processi Software 43
Prospettiva Statica: I Workflow
• Il RUP prevede vari workflow (6 attività principali e 3 di supporto):– Modellazione Processi di business– Requisiti– Analisi e Progettazione– Implementazione
– Test– Rilascio– Gestione della configurazione e delle modifiche– Gestione del Progetto– Ambiente
Ingegneria del Software 2 – CVS e Processi Software 44
Workflow e Fasi
• Il RUP non vincola l’esecuzione delle attività a specifiche fasi
• Tutti i workflow del RUP possono essere eseguiti in qualunque iterazione del processo.
• Ovviamente nelle prime iterazioni gli sforzi si concentreranno sui workflow di modellazione e dei requisiti, nelle successive sulla implementazione e sul test.
23
Ingegneria del Software 2 – CVS e Processi Software 45
Distribuzione dei workflow per fasi
Incept ion Elabor at ion Const ruct ion Tr ansition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support
Ingegneria del Software 2 – CVS e Processi Software 46
Le sei pratiche fondamentali del RUP
• Sviluppare il software iterativamente:– Pianificare gli incrementi in base alle priorità del cliente
• Gestire i requisiti:– Documentare esplicitamente I requisiti ed I cambiamenti
effettuati• Usare architetture basate su componenti:
– Strutturare l’architettura con un approccio a componenti• Creare modelli visuali del software:
– Usare modelli grafici UML per rappresentare viste statiche e dinamiche del sistema
• Verificare la qualità del software:– Verificare l’aderenza a standard di qualità aziendali
• Controllare le modifiche al software:– Gestire I cambiamenti e le configurazioni del software
24
Ingegneria del Software 2 – CVS e Processi Software 47
Configurazione del RUP
• Il RUP è un processo generico di sviluppo software:
– deve essere istanziato per ciascuna organizzazione e per ciascun progetto specifico, aggiungendo: standard, modelli di documento standard, strumenti, …
• Punti di forza:– Separazione di fasi e workflow– Le fasi sono dinamiche e vanno pianificate, i workflow sono
statici e sono attività tecniche condotte nelle varie fasi– Comprende un vasto insieme di linee guida e template per
operare con approccio OO e basato su componenti
– Definisce in modo accurato: Ruoli, Attività, Input Output delle varie attività
Ingegneria del Software 2 – CVS e Processi Software 48
Costi del RUP
• Impatto organizzativo– Può portare ad una riorganizzazione completa del lavoro
• Impatto culturale– Può comportare una ridefinizione del modo di lavorare
• Costi tecnologici– L’utilizzo del processo é agevolato dall’uso di strumenti (tool)
specifici (come quelli della suite Rational)• Costi di avvio
– Adattamento del processo– Divulgazione– Inquadramento dei processi esistenti
• Spesso si rinuncia ad adottare il RUP proprio perchè essocomporta un drastico cambiamento nel modo di lavorare dellepersone, che potrebbero reagire (sul breve termine) diminuendo la loro produttività
25
Ingegneria del Software 2 – CVS e Processi Software 49
Scelta di un Modello di Processo: alcuni aspetti da valutare
• tolleranza del modello ai rischi che si potranno incontrare• facilità di comunicazione tra sviluppatori e utilizzatori• stabilità dei requisiti noti; probabilità di esistenza di requisiti (ancora) non
noti• importanza di rilasci ‘early’ di (parziali) funzionalità• Intrinseca complessità del problema e delle probabili soluzioni• (anticipata) conoscenza di frequenza e dimensione di richieste di
cambiamento• maturità dell’applicazione (o del dominio applicativo)• disponibilità e priorità di fondi• flessibilità dello scheduling e budget (scadenze per il ricevimento e spesa
dei fondi; possibilità di modificare gli incrementi per ottimizzare costi e minimizzare rischi)
• criticità del rispetto di scheduling e budget• adeguatezza del processo ‘istituzionale’ e tool di sviluppo dello
sviluppatore• corrispondenza tra organizzazione del management e il modello da adottare
Ingegneria del Software 2 – CVS e Processi Software 50
Ulteriori Riferimenti bibliografici
• Booch, Rumbaugh, Jacobson, Unified Software DevelopmentProcess, Addison Wesley 1999
• Kroll, Kruchten, Booch, The Rational Unified Process MadeEasy: a Practitioner’s Guide to RUP, Addison Wesley, 2003
• J.Arlow, I. Neustadt, UML2 e Unified Process- Analisi e progettazione Object-Oriented, 2 ed., McGraw Hill 2006