CVS : CICLI DI VITA DEL SOFTWARE

a.a. 2017/2018

Prof. Aniello Cimitile

… una definizione IEEE

Software life cycle: 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

Acronimi: SLC CVS

• Un CVS ( SLC) è un framework che coordina e relaziona, in base ai metodi selezionati e adottando o meno specifici modelli, un insieme di processi software interagenti

• In tali cicli, con riferimento ai processi ISO/IEC12207, sono sempre esplicitamente o implicitamente riferiti, anche se talvolta alcuni di essi sono raggruppati in una unica fase di lavorazione, sia i processi specifici della produzione software che quelli tecnici che si sviluppano nel contesto, sia, infine, quelli organizzativi e gestionali.

Sono molto diffusi la definizione e l’uso di un sub- frame dei CVS denominato Ciclo di Produzione del Software (CPS) che strettamente coordina e relaziona i soli processi che precedono il rilascio del software in esercizio.

Da una definizione IEEE … Software development cycle: “… begins with the decision to develop a software product and ends when the product is delivered.”

• I cicli di vita che sono stati proposti, sperimentati ed usati, intensamente analizzati e discussi sono numerosi

• Le pietre miliari di tale sviluppo possono essere esemplarmente rappresentate dalla seguente classificazione, fatta sulla base dei metodi che tali cicli adottano: – WATERFALL MODEL

• Classico modello fondato su Heavy Methods – MODELLI «DO IT TWICE»

• … tipicamente fondato su metodi prototipali – MODELLI EVOLUTIVI, INCREMENTALI ED ITERATIVI

• Fondati su Metodi IID ( Iterative and Incremental Development)

• UP: processi unificati fondati su modellazione UML – MODELLI A COMPONENTI

• Fondati sul Riuso – MODELLI AGILI

• Sono fondati sui metodi Agili ( o lightweight) più moderni e costituiscono anche una decisa evoluzione dei metodi IID

WATERFALL MODEL

• Il ciclo di vita a cascata è stato il primo ciclo di vita « studiato» nella IS

• Esso è totalmente ispirato dalle concezioni tayloristiche dei processi di produzione industriale

• Processi totalmente orientati sul prodotto (… l’utente-acquirente è fuori …)

• … divisi in fasi di lavorazione concepite come veri e propri compartimenti stagni …

• … regole rigide ed immodificabili, da catena di montaggio …

• Al di la della diversa denominazione delle fasi e dei processi software che in esse si sviluppano (*), un waterfal model è caratterizzato da:

– Una organizzazione rigidamente SEQUENZIALE delle fasi

– I Deliverables prodotti in una fase sono INPUT per la fase successiva

– I prodotti di una fase sono «CONGELATI», ovvero non sono più modificabili se non innescando un processo formale e sistematico di modifica

– I Milestones sono solo alla fine di ogni fase

(*) NB. I watefall model si sono sviluppati ben prima di una chiara conquista del concetto di Processo Software secondo ISO/IEC 12207 …;

REQUISITI

PROGETTO

CODIFICA

TESTING

MANUTENZIONE

Uno dei tanti esempi di waterfall model reperibili in letteratura

La denominazione e la scelta delle fasi varia al variare delle specifiche esigenze del proponente, …

..ad esempio, nel caso specifico, rispetto alla Copertura di un CVS completo , mancano processi come Installazione, Esercizio, Ritiro ..

Nelle Fasi sono sempre presenti i processi relativi all’analisi ed alla definizione dei Requisiti, alla Progettazione di Architettuta (HLD) e di dettaglio (LLD), alla Programmazione; quasi sempre quelli relativi al Testing ed alla Manutenzione.

• … non mancano pregi, … ma sono molti i limiti

• Ad esempio: – Il sistema software diventa installabile solo

quanto è totalmente finito ..

– Né l’utente, né il management committente possono giudicare dell’adesione del sistema alle proprie aspettative prima della fine

– I cambiamenti non sono «visti bene» …

– Impossibilità di overlap di attività diverse

– …………………………………………………………….

• …. una storica «sentenza» di Basili e Larman

IEEE Computer , June 2003

The Warterfall Model was adopted because software development was guided by DoD standards. In reality, software development is a complex, continous, iterative, and repetitive process. The waterfall does not reflect this complexity.

… una prima proposta alternativa …

Modelli «Do it twice»

• … furono presentati così

If the program is being developed for the first time, arrange matters so that the version finally delivered to the customer is actually the second version insofar as critical design / operation areas are concerned

… rilevante ruolo della «prima versione» per la definizione dei requisiti

Il Modello proposto è fondato su Metodi Prototipali trova riferimento nelle produzioni industriali precedute dalla realizzazione di prototipi, simulatori, «muletti» , etc. E’ anche un primo esempio di modello evolutivo il sistema software viene prodotto sulla base della evoluzione delle conoscenze e delle esperienza maturate con la realizzazione della prima versione …..

• Modello con Pilota

–Viene costruito un primo Sistema Pilota, non orientato alla produzione e puramente esplorativo

–… abbastanza completo ma anche «rough around the edges» ( grossolanamente rifinito …., raffazzonato …)

– È orientato a verificare la fattibilità del sistema, ad avere feedbacks ( anche dal customer) ed indicazioni per la produzione

• Modello con Prototipo

– Costruzione veloce di un prototipo con tecnica:

1. MOCK – UP: costruzione interfaccia utente;

2. BREADBOARDS : implementazione di funzionalità critiche;

Nel caso 1. coinvolgimento e confronto con l’utente per definire in modo completo e senza ambiguità i requisiti ….

Nel caso2. : conoscere bene le criticità prima di garantire ….

REQUISITI PROGETTAZIONE «VELOCE»

PROTOTIPO o PILOTA

VALIDAZIONE REQUISITI

Ciclo di PRODUZIONE

… un esempio di «do it twice»

….buttare pilota e prototipi

(trowaway prototype) e non

Usarli in Produzione ………!!!! ????

MODELLI EVOLUTIVI, INCREMENTALI,ITERATIVI

• … costituiscono una prima significativa rottura con il Waterfall Model, rispetto al quale ci si propone di produrre prima qualcosa di utile, installabile ed operativo

• I metodi IID ( Incremental and Iterative Mhetods) su cui si fondano rispondono a tre esigenze fondamentali che vengono concretamente recepite ed affrontate nell’organizzazione stessa del ciclo

• EVOLUTIVI – … dalla lezione di Lehman, i modelli organizzano il CVS

come una successione di Evoluzioni che espandono il sistema …;

• INCREMENTALI – … i modelli fondano su uno sviluppo incrementale; si

parte con la implementazione di un primo subset di requisiti ed il rilascio in esercizio del relativo software; si continua col rilascio in sequenza di nuove versioni ciascuna arricchita dalla implementazione di un nuovo definito set di requisiti

• ITERATIVI – … ogni evoluzione / incremento del sistema è ottenuto

con la iterazione di uno stesso ciclo produttivo, con processi stabili e maturi

Una rappresentazione ispirata al celeberrimo modello a spirale di Boehm

In effetti il modello a spirale è un metamodello ( o un generatore di modelli) che consente di distribuire lungo il percorso antiorario della spirale processi e fasi diverse …

Requisiti Progetto Programmi Testing EVOLUZIONE

HLD Sottositemi e Priorità

Progetto Stralcio e LLD

Code & Test

Integration & Test

Installazione & Manutenzione

Analysis Set New Objectives Service & Test Design Measure Use Find Solution/Evaluate Sell Make

….. esempi ….

• I modelli IID introducono anche nuove esigenze : – La pianificazione e la

gestione di ogni incremento

– La gestione delle configurazioni

– La gestione del rischio

Processi che ora diventano permanenti e necessari fin dai primi passi

….. un’altra celebre schematizzazione

Dal punto di vista concettuale la sperimentazione dei metodi IID legati a questa tipologia di cicli ha portato tali metodi ad essere alla base di tutte le proposte più Recenti di CVS e CPS

UP Unified Process RUP Rational Unified Process

• E’ un processo basato su metodi IID ma ulteriormente specializzato con un totale ancoraggio alla modellazione UML;

• … è stato proposto con l’ambizione di diventare il modello unico di CVS capace di soppiantare ed inglobare ogni altro tipo di CVS;

• … è supportato da un prodotto commerciale, un sistema software sviluppato ed implementato da Rational Corporation ( … poi IBM).

• La prima novità del RUP è che i tradizionali processi software (

… requirements , …, design,…implementation …), che vengono chiamati DISCIPLINES ( in precedenza anche Workflows) si dispiegano attraversando 4 FASI che si sviluppano nel tempo – INCEPTION (AVVIO) – ELABORATION (ELABORAZIONE) – CONSTRUCTION (COSTRUZIONE) – TRANSITION ( TRANSIZIONE )

• La seconda è che l’approccio IID si concretizza attraverso: – CICLI che riguardano tutte le fasi (…INCREMENTALITA’) – ITERAZIONI che si sviluppano nelle singole fasi

• Il totale ancoraggio ad UML è fissato nella produzione ed evoluzione lungo tutte le fasi di diagrammi sia della famiglia UML - Structure che UML-Behaviour per le rappresentazioni statica e dinamiche delle caratteristiche di sistema

• Ogni Ciclo produce una NUOVA RELEASE

• Alla fine di ogni Fase vi sono le MILESTONES

• Ogni Iterazione in una fase si conclude con un PRODOTTO FINITO ( caratteristico della fase)

INCEPTION ELABORATION CONSTRUCTION TRANSITION

Milestones Milestones Milestones Milestones

Ciclo

MILESTONES e RELEASES: la vasta gamma di Modelli UML che vengono prodotti

( Use Case, Class Diagram, Sequence Diagram, etc.)

DISCIPLINES

Una Classica Schematizzazione del RUP

• Le Discipline ( … i processi software …) sono attive lungo tutto il tempo di sviluppo di un ciclo e quindi attraversano tutte e quattro le fasi …

• … anche se con intensità e volume variabile ..

– nella fase di INCEPTION, in cui il sistema viene concepito e se ne costruisce una visione, si ha il picco dei processi di Requirements

• … ma la gestione dei Requisiti in tutte le fasi è una delle caratteristiche fondamentali del RUP;

– nella fase di ELABORAZIONE, in cui si delineano i prodotti software, si ha il picco dei processi di Design;

– nella fase di CONSTRUCTION, in cui vengono costruiti i prodotti software si ha il picco dei processi di Implementazione e Testing;

– nella fase di TRANSITION, in cui avviene il trasferimento dei prodotti nell’ambiente operativo, si ha il picco dei processi di «dispiegamento» ( Operation Process ).

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter. #1

Phases Process Disciplines

Iterations

Iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

Iter. #m

Iter. #m+1

Deployment

Configuration Mgmt

Requirements

Elaboration Transition Inception Construction

Supporting Disciplines

Una Iterazione attraversa tutte le discipline nella dimensione qualitativa e quantitativa relativa alla fase stessa Il ciclo è fortemente gestito e controllato ( …CMM…), come dimostrato in particolare proprio dalla uniforme distribuzione dei picchi del Project Management in tutte le fasi ( … in particolare un picco ad ogni iterazione nelle fasi …)

P r e l i m i n a r y I t e r a t i o n ( s )

i t e r . # 1

i t e r . # 2

i t e r . # n

i t e r . # n + 1

i t e r . # n + 2

i t e r . # m

i t e r . # m + 1

I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n

I t e r a t i o n s

P h a s e s

A n i t e r a t i o n i n t h e e l a b o r a t i o n p h a s e

R

D

I

T

A

Il Prodotto finito di una iterazione in una fase ( es. Elaborazione) passa alla fase successiva ….

NB. Sono state proposte versioni del RUP con discipline e fasi ampliate o ristrette; in effetti, Concettualmente, entrambe possono essere variate ( ad esempio, come in figura, separando l’Analisi dalla Progettazione )

… la evoluzione da RUP ad EUP ( enterprise unified process) …

• Vengono aggiunte due nuove fasi

– Production

– Retirement

• … ed una nuova disciplina

– Operation and Support

MODELLI CON O PER RIUSO

• L’introduzione del Riuso in modo esplicito nei CVS è diventata una ovvia necessità con la diffusione di produzioni software che dall’uso di librerie sono via via passate alla integrazione di COTS, di wrapping di sistemi e componenti legacy, al CBSE, ai Framework, ai Patterns, … in generale a cicli nei quali il riuso è basilare pilastro strategico;

• sono, quindi, proliferate varianti ai cicli proposti per recepire la gestione e la realizzazione del Riuso

… una classica variante al modello a spirale di Boehm

Introduzione dei Processi per il Riuso ( Reuse Asset Mgm, Reuse Program Mgm .. In ISO/IEC 12207).

… un classico modello Component Based, in cui il Riuso comincia a valle della progettazione

REQUIREMENTS COMPONENTS

ANALYSIS DESIGN with

REUSE

DEVELOPMENT & INTEGRATION

TESTING

REQUIREMENTS MODIFICATION

… ancora un ciclo Component Based dove il Riuso comincia a livello dei requisiti, …. concorrendo alla loro definizione

NB. È in questa direzione che si colloca il Riuso dettato dalla circolare 63/2013 per la PA ( e che definisce processo dell’acquirente per la PA italiana)

Da precedenti progetti Nuovo Sistema Sistema

di Repositories

REQUISITI REQUISITI

PROGETTO PROGETTO

CODICE CODICE

TESTING TESTING

REP ( R)

REP ( P)

REP ( C)

REP ( T)

… il FULL REUSE MODEL di BASILI

Riuso separato dei singoli Prodotti dei Processi Software Riuso combinato dei Prodotti di Processi diversi grazie alla Tracciabilità

Organizzazione, Popolamento e Gestione Delle repositories

… un esempio di ciclo su framework (*)

(*) il modello è una proposta di CAP GEMINI

MODELLO DI COMPONENTE

ESEMPIO

Conforms to a Component MODEL

Independently Deployed

Composed without MODIFICATION

and according to a MODIFICATION STANDARD

SOFTWARE COMPONENTS CBSE

MODELLI DI SVILUPPO AGILE

• Si fondano sui Metodi Agili e si sono sviluppati a partire dal 2000 ( … sono la prima proposta del XXI secolo …)

• Anche in questo caso, sono una risposta ad una nuova domanda di software, cresciuta col diffondersi di applicazioni WEB ma non solo

• Per questa nuova domanda , le condizioni di mercato cambiano con velocità di gran lunga superiori a quelli dei tradizionali cicli di sviluppo del software; diventa impossibile definire completamente ed ex ante i Requisiti che emergono improvvisamente sulla base di nuove opportunità e minacce competitive; bisogna seguire l’esigenza di frequenti cambiamenti e veloci rilasci del cliente/utente

• Diventano indispensabili nuovi modelli di sviluppo caratterizzati da grande capacità di adattamento e da straordinaria agilità e snellezza produttiva ed organizzativa ….

• Nel 2001 viene pubblicato, da parte di 16 proponenti, l’ormai celebre

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT

Manifesto per lo Sviluppo Agile di Software

Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.

Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni più che i processi e gli strumenti

Il software funzionante più che la documentazione esaustiva

La collaborazione col cliente più che la negoziazione dei contratti

Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,

consideriamo più importanti le voci a sinistra.

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

© 2001, gli autori sopraindicati; questa dichiarazione può essere copiata liberamente in qualsiasi forma, purché sia inclusa questa stessa nota.

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del

cliente.

Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.

Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta

la durata del progetto.

Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.

Una conversazione faccia a faccia è il modo più efficiente e più efficace per

comunicare con il team ed all'interno del team.

I 12 Principi del Manifesto

Il software funzionante è il principale metro di misura di progresso.

I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo

costante.

La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità.

La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.

Le architetture, i requisiti e la progettazione migliori emergono da team che si

auto-organizzano.

A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Valori

Principi

CICLI Crystal

Scrum

XP

KANBAN

ASD

DSDM FDD

La Piramide dello Sviluppo Agile: dopo i 4 Valori e la loro articolazione in 12 Principi sono fiorite numerose proposte e concrete applicazioni di cicli

Lo crescita e la applicazione di queste proposte è in pieno ed impetuoso sviluppo, …

SCRUM

• SCRUM: pacchetto di mischia del Rugby

• Un Product Owner, un Team di Sviluppo (Scrum Development Team), un Facilitatore dei rapporti fra Team e Owner ( Scrum Master)

Si procede per successione di SPRINTS

SPRINT : un blocco rapido di lavoro con rilascio di prodotto max in un mese !

• Product Backlog:

– Lista ordinata per priorità dei requisiti del prodotto

• Sprint Backlog

– Lista dei lavori (task) da farsi in uno Sprint

ARTIFATTI SCRUM

Sprint Meetings • SPRINT Planning 8 ore

• Daily SCRUM Meeting 15 m

• SPINT Review 4 ore

• SPRINT Retrospective 3 ore

SPRINT Blocco rapido di lavoro

2 – 4 settimane Crea un incremento

consegnabile

Il set di funzionalità che vengono inserite in uno sprint provengono dal product backlog, che è

un insieme di requisiti, con priorità ad alto livello, di lavoro da compiere

…. una classica schematizzazione di SCRUM

Esempio di SCRUM Product Backlog

Requisiti: User Stories

Primato Product Owner: Stories e Priorità

Stime: Team

ESEMPIO di Product

Backlog e Release

TEAM + SCRUM MASTER

+ PRODUCT OWNER

Piano Releases: NON E’ STATICO .. ad ogni sprint …

ESEMPIO di SPRINT BACKLOG

Team in Sprint Planning

UN TOOL DI RILEVAZIONE E MONITORAGGIO ANDAMENTO LAVORO … ma anche di raccolta Serie Storiche e Previsione

Primato. SCRUM MASTER

La Lavagna di SCRUM (SCRUM BOARD )

SCRUM BOARD in real world

Piattaforme Tecnologiche di Supporto SCRUM BOARD «virtualizzata»

XP PROGRAMMAZIONE ESTREMA (eXtreme Programming)

• Produrre artifatti strettamente necessari ( … ad esempio, tutta la modellazione UML e RUP è pesante e costosa … rispetto ai benefici …)

• Ridare, nei processi tecnici, dominanza alla produzione di codice ed al testing – Test Driven Development – Pair Programming

• Ridiventano centrali i Programmatori a cui spetta anche la verifica ed il testing

• Cicli veloci di Pianificazione, Progettazione ( semplificata : invece dei modelli UML, semplici schede CRC), Codifica , Testing.

… una classica schematizzazione di Extreme Programming

Diagram of extreme programming as explaine to Beck .k, & Fowler, M (2004)

K. Beck & M.Fowler 2004

… una classica schematizzazione di ASD

… da Jim Highsmith, uno dei 16 …

• I sostenitori delle metodologie tradizionali sono troppo statici e preferiscono

produrre documentazione perfetta piuttosto che un sistema funzionante che

risponda alle esigenze dell’utente

• I sostenitori delle metodologie leggere o agili sono ex hacker che hanno

fatto fortuna e che avranno delle brutte sorprese quando si troveranno a

trasformare i loro giocattoli in software funzionante