Modelli di Produzione del SW:
dal Ciclo a Cascata
all’Open Source
Paolo Ciancarini
Dip. Scienze dell’Informazione
Università di Bologna
Alcuni eventi
1968: NATO Conference on Software Engineering
1969: IBM effettua il “software unbundling”
1970: Royce descrive il Waterfall Model
1976: Lettera aperta di B.Gates sulla pirateria sw
1987: Articolo Osterwail
1988: Modello a spirale di Boehm
1990: Conferenze su Sw Process Modeling
1998: Netscape viene distribuito Open Source
2002: Proposte di legge su Open Source
Il sw è un prodotto industriale
L’industria mondiale del sw è cresciuta nell’ultimo decennio a
tassi di almeno il 10% annuo
Molti nuovi servizi di rete si basano su innovazioni
tecnologiche software (es. Napster, aste online, ecc.)
Un telefonino contiene 5 MLOC (fonte Nokia)
Windows XP contiene 40 MLOC (Windows 95: 11 MLOC)
Il costo di sviluppo di un programma cresce col quadrato
delle sue dimensioni [Berra-Meo 2001]
Il software è un prodotto speciale
È invisibile e intangibile
È facilmente duplicabile e distribuibile su rete
Non è in sé brevettabile (ma protetto)
Non è garantito
Viene acquisito su licenza
• Proprietaria (normale, shareware)
• Public domain
• Open source
Perché studiare il processo di produzione
del sw?
Servono sistemi software più affidabili e sicuri:
il processo di produzione influenza tali qualità
Il processo software impatta l’organizzazione
L’organizzazione impatta il processo software
Esistono parecchi diversi processi di sviluppo,
adatti ad organizzazioni, prodotti e mercati diversi
Alcuni strumenti sono efficaci solo nell’ambito di
processi i cui scopi sono ben definiti
Il processo edit-compile-test
edit
Il processo edit-compile-test
edit
compile
Il processo edit-compile-test
edit
compile
test
Il processo edit-compile-test
edit
compile
• Molto veloce, feedback rapido
• Disponibilità di molti strumenti
• Specializzato per la codifica
• Non incoraggia la documentazione
• Non scala: in-the-large, in-the-many
• Ingestibile durante la manutenzione
test
Programming in the small/large/many
Programming in-the-small:
un programmatore, un modulo = edit-compile-test
Programming in-the-large:
progettare software decomposto in più moduli,
su più versioni, su più configurazioni
Programming in-the-many:
progettare software <<grande>> richiede la
cooperazione ed il coordinamento di più
programmatori, nell’ambito di un ciclo di vita
Segmentare il ciclo di vita
specifica
È la fase di stesura dei requisiti e
di descrizione degli scenari d’uso
Segmentare il ciclo di vita
specifica
progetto
Il progetto determina un’architettura software
capace di soddisfare i requisiti specificati
Segmentare il ciclo di vita
specifica
progetto
costruzione
La costruzione, o codifica, è una fase
complessa che include il testing e
termina con il deployment del sistema
Segmentare il ciclo di vita
specifica
progetto
costruzione
manutenzione
Manutenzione perfettiva
Manutenzione correttiva
Manutenzione adattiva
Modello a cascata
Molto dettagliato
Molto rigido
Orientato alla
documentazione
Orientato agli standard
Adatto per
organizzazioni
gerarchizzate
Rischioso
Modello a cascata, versione a V
conceptual phase
research phase
required
operational
capability
design &
test & evaluation operation
development phase phase
& maintenance phase
certificazione
operation
& maintenance
operational
testing &
evaluation
engineering
studies
validazione
Experimental
development
concept
evaluation
System
Requirements
Review
System
Design
Review
validazione
system
decomposition
& allocation
verifica
software
requirements
Preliminary
sw analysis
& design
Preliminary
design
review
acceptance test
& evaluation
validazione
verifica
verifica
Detailed sw
analysis &
design
verifica
coding &
debug
Critical
design review
system
performance
testing
sw/hw
integration
& testing
sw system
integration
& testing
sw subsystem
integration
& testing
software
cpci testing
customer
delivery
audit
functional
configuration
audit
Descrivere un processo
Occorre
Occorre
Occorre
Occorre
Occorre
Occorre
descrivere/monitorare le attività
descrivere/assemblare gli strumenti
descrivere/assegnare i ruoli
descrivere/controllare i gli eventi
descrivere/validare i documenti
descrivere/verificare i criteri di qualità
Software processes are software, too!
Descrivere un processo sw
Processo software:
L’insieme strutturato di
attività, eventi, documenti e procedure necessari
per la costruzione di un sistema software
Benefici della modellazione dei processo sw:
“Migliora il processo per migliorare il prodotto”
Miglior coordinamento del team di sviluppo
Accumulazione di esperienza
Modello a spirale (Boehm)
Adatto se requisiti instabili
Non lineare
Flessibile
Valuta il rischio
Modelli orientati alla qualità
I cicli di vita orientati alla qualità si basano di
solito su modelli analitici almeno idealmente
quantitativi
ISO 9000
Capability Maturity Model (CMM)
Six Sigma
Extreme programming
ISO 9000
ISO9000-3 è ISO9001 per le fabbriche del sw
ISO 9000
Quality management and quality assurance standards;
guidelines for selection and use
ISO 9001
Quality systems model for quality assurance in design,
development, production, installation, and servicing
ISO 9002
Quality systems model for quality assurance in
production and installation
ISO 9003
Quality systems model for quality assurance in final
inspection and test
ISO 9004
Quality management and quality systems elements.
Guidelines
Capability Maturity Model
Level
Characteristic
Key challenges
Optimizing
Improve feedback into process
Identify process indicators
Managed
(Quantitative) measured process
Automatic collection of process
data, to analyze and modify the
process itself
Defined
(Qualitative) process defined and
istituzionalized
Process measurement
Process analysis
Quantitative Quality Plans
Repeteable
(Intuitive)
process dependent on individuals
Establish a Processw Group
Identify a Process Architecture
Introduce SE methods and tools
Initial
Ad hoc/ Chaotic
No cost estimation, planning,
management
Project management
Project planning
Software Quality Assurance
La famiglia dei processi sw
orientati alla qualità
Il Rational Unified Process
• L’avvento di UML ha portato alla definizione
di specifici modelli di processo: il RUP è uno di questi
• Il ciclo di vita RUP è suddiviso in una serie di
iterazioni
• Ogni ciclo è composto da una serie di fasi




Concezione
Elaborazione
Costruzione
Transizione
Concezione
Elaborazione
Costruzione
tempo
Transizione
RUP: concezione (inception)
• Scopo
 Stabilire il business case per il nuovo sistema o per
l’aggiornamento di un sistema esistente.
• Prodotti
 I requisiti chiave per il progetto
 Una valutazione iniziale del rischio
• Prodotti opzionali:
 Un prototipo concettuale
 Un primo modello del dominio (completo al 10, 20%)
RUP: elaborazione
• Scopo




Analizzare il dominio del problema
Stabilire un’accurata base architetturale
Evidenziare gli elementi ad alto rischio del progetto
Sviluppare un piano per la realizzazione del progetto
Prodotti
Un
modello del sistema con il contesto, gli scenari ed il modello del dominio
L’architettura
dell’eseguibile
Un
piano rivisto dei rischi
Un
piano di sviluppo e di testing
Una
descrizione della release
Una
prima versione dello User Manual
RUP: costruzione
• Scopo
 Sviluppare incrementalmente un prodotto software
completo pronto per essere inserito nella comunità
degli utenti
• Prodotti
 Una serie di rilasci degli eseguibili
 Dei prototipi comportamentali
 I risultati dell’assicurazione di qualità
 La documentazione utente e del sistema
 Il piano di rilascio
 Criterio di valutazione per l’iterazione successiva
RUP: transizione
• Scopo
 Inserire il prodotto software nella comunità degli
utenti
• Prodotti
 Una serie di rilasci degli eseguibili
 I risultati dell’assicurazione di qualità
 Documentazione utente e di sistema aggiornata
 Analisi delle prestazioni del sistema dopo il rilascio
Il RUP è un modello iterativo
• Una iterazione è un ciclo di sviluppo che porta al
rilascio di una parte del prodotto finale
• Ogni iterazione tocca tutti gli aspetti dello sviluppo sw
• Ogni rilascio iterativo è una parte pienamente
documentata del sistema finale
Phases
Process Components
I nception
Elaboration
Construction
Transition
Requirements
Analysis
Architecture
Level
Design
Class Level
Implem entation
Test
Supporting Activities
Project Management
Process Configuration
preli mi nary iteration it erati on iterati on iterati on iteration
iteration(s)
#1
#2...
#n
#n+1
#n+2...
Iterations
iterati on iteration
#m
#m+1...
Il processo Microsoft
Pianificazione
• Documento programmatico
• Specifica
• Team management
Sviluppo
• 3-4 Sottoprogetti
Stabilizzazione
• Collaudo interno
• Collaudo esterno
• Golden master
La filosofia Open Source
Ogni buon prodotto software inizia da un problema
personale di uno sviluppatore
I bravi programmatori sanno cosa scrivere. I migliori sanno
cosa riscrivere
Quando hai perso interesse in un programma che hai
costruito, è tuo dovere passare le consegne ad un
successore competente
Trattare gli utenti come sviluppatori è la strada migliore per
ottenere debugging efficace e rapidi miglioramenti del
codice
Distribuisci presto, distribuisci spesso e presta ascolto agli
utenti
Stabilita una base di betatester e cosviluppatori
sufficientemente ampia, ogni problema verrà rapidamente
definito e qualcuno troverà la soluzione adeguata
Il processo Open Source
• Il processo è ”pubblico”
• Le implementazioni sono
controllate da un board
che revisiona e testa il
codice proposto
• modifiche moderate
• build frequenti
• proprietà collettiva
• ”no maintenance”
Open Source nalla PA?
Da una proposta di legge 20/3/2002
1. La pubblica amministrazione è tenuta ad utilizzare, nella propria
attività, programmi per elaboratore elettronico dei quali possieda il
codice sorgente.
2. La pubblica amministrazione, nella scelta dei programmi per
elaboratore elettronico necessari alla propria attività, privilegia
programmi appartenenti alla categoria del software libero o, in
alternativa, programmi a codice sorgente aperto. In tale ultimo caso,
il fornitore deve consentire la modificabilità del codice sorgente senza
costi aggiuntivi per l'amministrazione.
3. La pubblica amministrazione che intenda avvalersi di un software non
libero, deve motivare analiticamente la ragione della scelta.
Ø
Conclusioni
“Silver bullets” nel processo di sviluppo:
Conclusioni
“Silver bullets” nel processo di sviluppo:
Il mito del metodo
Conclusioni
“Silver bullets” nel processo di sviluppo:
Il mito del metodo
Il mito degli strumenti
Conclusioni
“Silver bullets” nel processo di sviluppo:
Il mito del metodo
Il mito degli strumenti
Il mito della gestione del progetto
Conclusioni
“Silver bullets” nel processo di sviluppo:
Il mito del metodo
Il mito degli strumenti
Il mito della gestione del progetto
Il mito dell’organizzazione del lavoro
Conclusioni
“Silver bullets” nel processo di sviluppo:
Il mito del metodo
Il mito degli strumenti
Il mito della gestione del progetto
Il mito dell’organizzazione del lavoro
Il mito della qualità
Conclusioni
L’impatto della ricerca e degli standard software
L’impatto delle nuove tecnologie software
L’impatto delle nuove infrastrutture di
comunicazione e coordinamento
L’impatto di nuovi modelli educativi
L’impatto della certificazione professionale
Fine
Grazie per l’attenzione!
Paolo Ciancarini
[email protected]
www.cs.unibo.it/~cianca