Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Scienze Matematiche Fisiche e Naturali
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Sergio Di Martino » 2.Il Ciclo di vita del Software: i modelli di Processo


Obiettivi della lezione

Comprendere il concetto di Processo Software.
Comprendere il concetto di Modello di Processo Software.
Comprendere i principali Modelli di Processo:

  • a cascata;
  • evolutivo;
  • prototipale.

Processo/Ciclo di vita del software

“Un processo è un particolare metodo per fare qualcosa costituito da una sequenza di passi che coinvolgono attività, vincoli e risorse” (Pfleeger).

“Processo: una particolare metodologia operativa che nella tecnica definisce le singole operazioni fondamentali per ottenere un prodotto industriale” (Zingarelli).

“Processo software: un metodo per sviluppare del software” (Sommerville).

Un Processo Software è un insieme organizzato di attività che sovrintendono alla costruzione del software da parte del team di sviluppo utilizzando metodi, tecniche, metodologie e strumenti.

È suddiviso in fasi, che vanno dalla nascita fino alla dismissione (o morte) del software.
Per un parallelo con la biologia, è noto come ciclo di vita del software.

Molti autori usano i termini processo [di sviluppo del] software e ciclo di vita del software come sinonimi.

Sofware development process: The process by which user needs are translated into a software product. The process involves translating user needs into software requirements, transforming the software requirements into design, implementing the design in code, testing the code, and sometimes, installing and checking out the software for operational use.
Note: These activities may overlap or be performed iteratively”.

Macropassi fondamentali del processo software

Macropassi fondamentali del processo  software.

Macropassi fondamentali del processo software.


Attività richieste nel processo di sviluppo software

Attività richieste nel processo di sviluppo software.

Attività richieste nel processo di sviluppo software.


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.
  • Si conclude con una offerta al Cliente.

Output: documento di fattibilità:

  • definizione preliminare del problema;
  • scenari – strategie alternative di soluzione;
  • costi, tempi, modalità di sviluppo per ogni alternativa.

Analisi dei requisiti e Progettazione

L‘analisi dei requisiti rappresenta l’analisi completa dei bisogni dell’utente e dominio del problema. Coinvolgimento di committente e ingegneri del SW.
Obiettivo: descrivere le caratteristiche di qualità che l’applicazione deve soddisfare.
Output: documento di specifica dei requisiti.
Per progettazione (o System/Object Design) si intende la 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:

  • System Design: struttura modulare complessiva (componenti);
  • Object Design: dettagli interni a ciascuna componente.

Obiettivo: descrivere come il software sarà strutturare per fare le funzionalità descritte nell’analisi dei requisiti.
Output: documento di specifica di progetto possibile l’uso di linguaggi per la progettazione (UML).

Obiettivo dell’ analisi dei requisiti.

Obiettivo dell' analisi dei requisiti.

Obiettivo della progettazione (o System/Object Design).

Obiettivo della progettazione (o System/Object Design).


Fasi basse del processo e Problemi di sviluppo

Fase basse del processo

Implementazione: ogni modulo viene codificato nel linguaggio scelto e testato in isolamento.
Testing:

  • composizione dei moduli nel sistema globale;
  • verifica del corretto funzionamento del sistema;
  • validazione che il sistema faccia ciò che vuole il cliente.

Installazione: distribuzione e gestione del software presso l’utenza.
Manutenzione: evoluzione del SW. Segue le esigenze dell’utenza. Comporta ulteriore sviluppo per cui racchiude in sé nuove iterazioni di tutte le precedenti fasi.

Problemi nel processo di sviluppo del software
E’ qualcosa di altamente intellettuale e creativo, basato su giudizi delle persone: non è possibile (almeno con i sistemi attuali) automatizzarlo.
I requisiti sono complessi e ambigui: il cliente non sa bene, dall’inizio, cosa deve fare il software.
I requisiti sono variabili: cambiamenti tecnologici, organizzativi, etc…
Modifiche frequenti sono difficili da gestire: difficile stimare i costi ed identificare cosa consegnare al cliente.

I Modelli di Processo e loro caratteristiche

Come organizziamo la sequenza di passi del processo software, per massimizzare alcune carattistiche?
Il processo di sviluppo deve essere modellato esplicitamente, per poter essere gestito e monitorato.
I modelli di processo software sono descrizioni precise e formalizzate delle attività, delle trasformazioni, dei deliverables e degli eventi per realizzare e/o ottenere l’evoluzione del software.
Obiettivo: introdurre stabilitá, controllo e organizzazione in una attivitá tendenzialmente caotica, massimizzando alcune delle caratteristiche del processo.

Una strutturazione dell’organizzazione del lavoro nelle fabbriche del software in:

  • fasi della produzione;
  • tipi di attività;
  • collegamento ed interfacciamento;
  • controllo e misura.

ma anche linee guida per: organizzare, pianificare, dimensionare personale, assegnare budget, schedulare e gestire, …definire e prescrivere prodotti e documenti da rilasciare al committente (deliverables), determinare e classificare metodi e strumenti più adatti a supportare le attività previste, framework per analizzare, stimare, migliorare.

Tipologie di Modelli di processo e loro Valutazione

Esistono vari Modelli di processo, nati (scoperti?) negli ultimi 30 anni:

  • waterfall (cascata);
  • evolutivo;
  • trasformazionale;
  • basato sul riuso;
  • spiral model;
  • eXtreme Programming.

Molti aspetti influenzano la definizione del modello:

  • specificità dell’organizzazione produttrice;
  • know-how;
  • area applicativa e particolare progetto;
  • strumenti di supporto;
  • diversi ruoli produttore/committente.

Tipologie di Modelli di processo e loro Valutazione (segue)

Esattamente come esistono dei parametri di qualità per un software, esistono dei parametri per valutare la “bontà” di un modello con cui sviluppare il software:

  • Comprensibilità: Quanto è facile apprendere il processo?
  • Visibilità : Quanto facilmente il processo fa capire a che punto dello sviluppo si è giunti?
  • Supportabilità (CASE tools): Esistono tool che supportano il processo? Quali e quante fasi sono supportate? A che livello?
  • Accettabilità: Le persone coinvolte nel processo manifestano il loro consenso?
  • Affidabilità: Il processo facilità l’individuazione di errori? Il software prodotto è di alta qualità?
  • Robustezza: Quanto è robusto il processo nel gestire cambiamenti in corso d’opera?
  • Mantenibilità: Il processo è in grado di adattarsi ai cambiamenti nell’organizzazione che lo usa?
  • Rapidità: Il porta ad un rapido sviluppo del software?

Il più semplice (e peggiore) modello di processo

  • Molto veloce, feedback rapido
  • Molti strumenti disponibili
  • Specializzato per codifica
  • Non incoraggia la documentazione
  • Non scala (in the large, in the many)
  • Ingestibile durante manutenzione

Esercizio
Come si pone rispetto a:

  • Comprensibilità?
  • Visibilità?
  • Supportabilità?
  • Accettabilità?
  • Affidabilità?
  • Robustezza?
  • Mantenibilità?
  • Rapidità?
Modello Edit-Compile-Test.

Modello Edit-Compile-Test.


L’approccio Tayloristico

Frederick Taylor – “The Principles of Scientific Management” (1911).

  • Gestione gerarchica;
  • Passi fissi, non fluidi;
  • Separare nettamente le postazioni di lavoro;
  • Il lavoro, una volta suddiviso, diventa specializzato in un singolo task;
  • Processo orientato al prodotto, non al cliente: “Any customer can have a car painted any color that he wants so long as it is black” – Henry Ford;
  • Processo ripetibile.

E’ stato per decenni il fondamento dell’industria mondiale.

Frederick Taylor.

Frederick Taylor.


Modelli a Cascata (Waterfall) – ‘70

Applicazione dell’approccio Tayloristico all’informatica. Popolare negli anni ‘70: reazione al “code and fix” originario.
Modello sequenziale lineare:

  • progressione sequenziale (in cascata) di fasi, senza ricicli, al fine di meglio controllare tempi e costi; definisce e separa le varie fasi e attività del processo;
  • nullo (o minimo) overlap fra le fasi;
  • uscite intermedie: semilavorati del processo (documentazione di tipo cartaceo, programmi);
  • consente un controllo dell’evoluzione del processo: attività trasversali alle diverse fasi.

Ogni fase raccoglie un insieme di attività omogenee per metodi, tecnologie, skill del personale, etc.
Ogni fase è caratterizzata da: attività (tasks), prodotti di tali attività (deliverables), controlli di qualità/stato (quality control measures). La fine di ogni fase è un punto rilevante del processo (milestone). I semilavorati output di una fase sono input alla fase successiva.
I prodotti di una fase vengono “congelati”, ovvero non sono più modificabili se non innescando un processo formale e sistematico.


Modello a cascata: vantaggi e svantaggi

Pro:

  • ha definito molti concetti utili (semilavorati, fasi ecc.);
  • ha rappresentato un punto di partenza importante per lo studio dei processi SW;
  • facilmente comprensibile e applicabile;
  • è un modello molto rigoroso: si applica bene in qualunque contesto in cui i requisiti siano stabili e chiari.

Contro:

  • interazione con il committente solo all’inizio e alla fine: requisiti congelati alla fine della fase di analisi; requisiti utente spesso imprecisi: “l’utente sa quello che vuole solo quando lo vede”; errori nei requisiti scoperti solo alla fine del processo;
  • il nuovo sistema software diventa installabile solo quando è totalmente finito: né l’utente né il management possono giudicare prima della fine dell’adesione del sistema alle proprie aspettative.

Utilizzo nella realtà industriale:

  • l’applicazione evolve durante tutte le fasi;
  • overlap e loop sono inevitabili!
  • in alcuni casi è auspicabile sviluppare prima una parte del sistema e poi completarlo (utente finale= mercato);
  • … la manutenzione non può essere considerata marginale.

Prototipazione Usa e Getta (throw-away)

L’obiettivo è capire i requisiti del sistema e quindi sviluppare una definizione migliore dei requisiti. Il prototipo sperimenta le parti del sistema che non sono ancora ben comprese. 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. Il prototipo è uno strumento di per validare i requisiti e/o validarne la fattibilità; è incompleto, approssimativo, realizzato utilizzando parti già possedute. Il prototipo deve essere gettato!

Esistono due tipi di prototipi usa&getta:

  1. Mock-ups: produzione completa dell’interfaccia utente. Consente di disambiguare parte dei requisiti, grazie all’interazione col cliente. Si può, già in questa fase, definire il manuale di utente;
  2. Breadboards: implementazione di sottoinsiemi di funzionalità critiche del software, per validarne vincoli e fattibilità (carichi elevati, tempo di risposta, …), senza le interfacce utente. Produce feedbacks su come implementare la funzionalità (in pratica si cerca di conoscere prima di garantire).
Prototipo throw-away.

Prototipo throw-away.


I Modelli Evolutivi e Prototipazione Evolutiva

Il modello evolutivo cerca di superare i limiti principali del modello a cascata, introducendo il concetto di prototipizzazione evolutiva.
È un modello costituito da poche fasi che si ripetono:

  • realizzazione di un artefatto;
  • consegna al cliente;
  • ottenere dei feedback;
  • modificare il progetto in base a tali feedback.

Prototipazione evolutiva
Si inizia a sviluppare ciò che è ben chiaro del problema. Nella fase di evoluzione:

  • si analizza l’esperienza di uso del SW sul campo e si utilizza la maggiore conoscenza per definire nuovi obiettivi;
  • si determinano esigenze e nuove funzionalità emerse o non coperti in precedenza;
  • si riprende il ciclo dalla definizione dei requisiti alla messa in esercizio e manutenzione del nuovo SW nato dall’arricchimento ed evoluzione del precedente.
Modelli evolutivi.

Modelli evolutivi.

Prototipazione Evolutiva.

Prototipazione Evolutiva.


I Modelli Evolutivi: Pro e Contro

Prototipazione Evolutiva (sviluppo esplorativo)

  • L’obiettivo è lavorare con il cliente ed evolvere verso il sistema finale a partire da una specifica di massima.
  • Lo sviluppo inizia con le parti del sistema che sono già ben specificate, aggiungendo via via nuove caratteristiche.
  • Il modello porta al sistema finale.

Prototipazione Usa e Getta (throw-away)

  • L’obiettivo è capire i requisiti del sistema e quindi sviluppare una definizione migliore dei requisiti.
  • Il prototipo sperimenta le parti del sistema che non sono ancora ben comprese.
  • Il modello fa comprendere i requisiti, poi il prototipo si butta e si procede con altro modello di processo.

Soluzione parziale ai problemi del modello a cascata

  • Aiuta a ridurre gli errori nei requisiti.
  • Coinvolge maggiormente il cliente → Maggiore soddisfazione del cliente.
  • Aiuta ad avere consapevolezza di cosa si sta realizzando.

I Modelli Evolutivi: Pro e Contro (segue)

Problemi

  • Modello indisciplinato → Bassa qualità interna
  • Manca visibilità nel processo
  • Sistemi spesso strutturati male
  • Difficoltà nella parallelizzazione tra diversi team

Applicabilità

  • Sistemi interattivi di piccola o media dimensione
  • Per parti di sistemi più grandi (es. interfaccia utente)
  • Per sistemi a vita breve

Modello a spirale

Prova a unire i vantaggi del modello evolutivo con quelli del modello a cascata.

Ogni fase inizia con un obiettivo di design, e termina con un’interazione col cliente, che rivede il progresso ottenuto.

Un momento di analisi e di ingegnerizzazione è presente in ogni fase del progetto.

Ripetizione ciclica di task regions:

  • determinazione obiettivi, vincoli, alternative;
  • valutazione alternative, analisi dei rischi;
  • sviluppo, verifica e convalida;
  • pianificazione prossimo ciclo.

Ogni ciclo di spirale (che può corrispondere con una fase del processo software) si compone di quattro fasi.

Il raggio rappresenta il costo accumulato.

La dimensione angolare il progresso nel processo.

Un possibile modello a spirale.

Un possibile modello a spirale.


Rischi

Rischi = fattori variabili che influiscono negativamente sulla riuscita di un progetto:

  • di tipo tecnico;
  • di tipo non tecnico.

Esempi:

  • personale non qualificato per le attività da effettuare;
  • budget e pianificazione irrealistici;
  • errori di definizione delle funzionalità;
  • errori di definizione dell’interfaccia utente;
  • funzionalità non richieste ma costose (gold planting);
  • instabilità dei requisiti;
  • difetti in componenti sviluppati da terze parti;
  • errori in attività svolte all’esterno dell’azienda;
  • uso di tecnologie non consolidate o inaffidabili.

Rischi (segue)

Gestione dei rischi
Compito di chi gestisce (il manager) è minimizzare i rischi.

Il rischio è insito in tutte le attività umane ed è una misura dell’incertezza sul risultato dell’attività.

Alti rischi provocano ritardi e costi imprevisti.

Il rischio è collegato alla quantità e qualità delle informazioni disponibili: meno informazione si ha più alti sono i rischi.

I modelli e la gestione dei rischi

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.

I modelli e la gestione dei rischi

Modello a spirale: vantaggi e svantaggi
Vantaggi:

  • rende esplicita la gestione dei rischi;
  • aiuta a determinare errori nelle fasi iniziali;
  • obbliga a considerare gli aspetti di qualità;
  • integra sviluppo e manutenzione.

Svantaggi:

  • richiede persone in grado di valutare i rischi;
  • può creare problemi nella definizione del contratto col cliente;
  • per poter essere usato deve essere adattato alla realtà aziendale e/o al team.

Rischi nel tempo per modelli iterativi e waterfall.

Modello trasformazionale

Basato sulla trasformazione di una specifica matematica in un programma eseguibile, attraverso trasformazioni che permettono di passare da una rappresentazione formale ad un’altra.
Le trasformazioni devono preservare la correttezza. Questo garantisce che il programma soddisfi la specifica.
Tra i più famosi: CleanRoom, della IBM.

Formal systems development
Problemi:

  • richiede una conoscenza specializzata ed esperienza nell’applicazione della tecnica;
  • difficoltà nello specificare formalmente alcuni aspetti del sistema come per esempio le interfacce;
  • pochi esempi di applicazione per sistemi complessi.

Applicabilità:

  • uso di questo modello in altri modelli, per migliorare il processo di sviluppo di sistemi critici (specialmente quelli in cui la sicurezza è un aspetto importante).
Formal systems development.

Formal systems development.


Scelta del Modello di Processo

Per sistemi o sottosistemi di cui si hanno requisiti stabili e competenze forti sulle tecnologie da impiegare si può adottare il modello a cascata: ottima qualità interna: zone non completamente specificate, interfacce utente possono impiegare prototipi.

Sistemi critici per le persone o cose (safety critical) con requisiti stabili, possono essere sviluppati con approcci trasformazionali (se possibile) o con modelli a cascata.

Sistemi con requisiti altamente instabili possono utilizzare modelli evolutivi.

Sistemi di grosse dimensioni, non critici, possono essere sviluppati con modelli incrementali.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion