Anna Rita Fasolino » 2.Ciclo di Vita e Processi Software

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

Il Ciclo di Vita del Software (CVS)

• Standard IEEE 610.12-1990
• Software Life Cycle: The period of time that starts when a software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note: These phases may overlap or be performed iteratively. Contrast with Software Development Cycle.

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 when the product is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Contrast with Software Life Cycle.
• Notes: The phases listed above may overlap or be performed iteratively, 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.

Una architettura per la definizione di CVS

• Standard IEEE 12207.0-1996
• 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.

Ciclo di Vita ed i suoi Processi (St.ISO 12207)

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 di un sistema software.
  • Specifica;
  • Progettazione (o Design);
  • Validazione;
  • Evoluzione.

Modelli di Processo Software

Un processo software può essere organizzato usando i Modelli di Processo Software:

Quali modelli di Processo Software?

Una possibile classificazione:

1. Processi basati sulla 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.

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.

• Trasformano automaticamente le specifiche in codice
  • La correttezza è preservata;
  • La verifica è ottenuta implicitamente.

Definizione→Requisiti→Specifica Formale→Trasformazione Formale→Integrazione e Testing di sistema

Processi basati su Metodi Formali (segue)

• 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

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)

Sviluppo Evolutivo

Basato sull’idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraverso varie 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. Dovrebbe partire da pochi requisiti ben compresi e aggiungere nuove caratteristiche 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 esplorare i requisiti e chiarirli.

(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.

Modello con Prototipo (Usa e Getta)

Processi di sviluppo Iterativi

In un ambiente globale di rapidi cambiamenti, è essenziale per la competitività delle aziende che il software di cui necessitano sia sviluppato e consegnato in tempi rapidi!
La mutevolezza ed instabilità dei requisiti impongono di adottare processi di sviluppo ciclici, in cui il software viene consegnato in una serie di incrementi, prodotti in vari cicli di processo (iterazioni) in cui si ritorna sulle fasi già condotte.

I cicli di processo possono essere applicati ad ogni generico modello di processo.

Due possibili approcci:

• (A) Sviluppo e Consegna Incrementale;
• (B) Sviluppo a Spirale.

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 delle funzionalità richieste.

• Ai requisiti Utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con i primi incrementi.
• Una volta partito lo sviluppo di un incremento, i relativi requisiti devono essere congelati, mentre I requisiti coinvolti in incrementi successivi possono continuare ad evolvere.
• I servizi comuni possono essere implementati all’inizio del processo, o quando una funzione è richiesta da un dato incremento.

Sviluppo e Consegna Incrementale

Esempio di processo incrementale

Requisiti: R1, R2, R3
Architettura: M1, M2, M3, M4
Pianificazione: 3 iterations

• Iteration1
  • R1, requires M1, M2
  • Develop and integrate M1, M2
  • Deliver R1
• Iteration2
  • R2, requires M1, M3
  • Develop M3, integrate M1, M2, M3
  • Deliver R1 + R2
• Iteration3
  • R3, requires M3, M4
  • Develop M4, integrate M1, M2, M3, M4
  • Deliver R1 + R2 + R3

Vantaggi dello sviluppo incrementale

• I clienti non devono aspettare il sistema completo per 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 degli incrementi successivi.
• Si riduce il rischio di un fallimento totale del progetto.
• I servizi a più alta priorità saranno anche testati più intensamente degli altri.

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.

Un esempio: Extreme programming

Extreme Programming

• Un esempio di approccio allo sviluppo basato su sviluppo e consegna di piccolissimi incrementi di funzionalità.
• Si basa su un continuo miglioramento del codice, sul coinvolgimento dell’utente nel processo di sviluppo, e sulla programmazione a coppie.

(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 vengono valutati e risolti durante tutto il processo.

• Metamodello perché comporta la selezione di un modello di CVS da adottare nello sviluppo.

Modello di sviluppo a spirale

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.

Unified Process (UP)

Booch, Rumbaugh, Jacobson (autori sia di UML che UP)

• UML (Unified Modeling Language)

• Linguaggio per la modellazione e costruzione di sistemi software.
• È Standard OMG (Object Management 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 (Rational Unified Process) creata da IBM.

Rational Unified Process (RUP)

Il RUP (Rational Unified Process):Un esempio di modello di processo “ibrido”.

• 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.

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

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.
  

Distribuzione dei workflow per fasi

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.

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à.

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è esso comporta un drastico cambiamento nel modo di lavorare delle persone, che potrebbero reagire (sul breve termine) diminuendo la loro produttività.

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.