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
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 test
• Molto veloce, feedback rapido
• Disponibilità di molti strumenti
• Specializzato per la codifica
• Non incoraggia la documentazione
• Non scala: in-the-large, in-the-many
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
required
operational
capability
engineering
studies
Experimental
development
concept
evaluation
system
decomposition
& allocation
software
requirements
Preliminary
sw analysis
& design
Detailed sw
analysis &
design
coding &
debug
software
cpci testing sw subsystem
integration
& testing sw system
integration
& testing sw/hw
integration
& testing system
performance
testing acceptance test
& evaluation operational
testing &
evaluation operation
& maintenance certificazione
validazione
validazione
validazione
verifica
verifica
verifica
verifica
research phase conceptual phase
design &
development phase
operation
& maintenance phase test & evaluation
phase
System
Requirements
Review
System
Design
Review
Preliminary
design
review
Critical
design review
functional
configuration
audit customer
delivery
audit
Descrivere un processo
Occorre descrivere/monitorare le attività
Occorre descrivere/assemblare gli strumenti Occorre descrivere/assegnare i ruoli
Occorre descrivere/controllare i gli eventi Occorre descrivere/validare i documenti
Occorre 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
Capability Maturity Model
Level Characteristic Key challenges Optimizing
Improve feedback into process Identify process indicatorsManaged
(Quantitative) measured process Automatic collection of process data, to analyze and modify the process itselfDefined
(Qualitative) process defined and istituzionalizedProcess 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/ ChaoticNo 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 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
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
Requirements Analysis
Architecture Level
Class Level Implem entation Design
Phases
Process Components Inception Elaboration Construction Transition
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
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
