Modelli di Produzione del SW:
dal Ciclo a Cascata all’Open Source
Paolo CiancariniDip. Scienze dell’InformazioneUniversità 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 industrialeL’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 reteNon è in sé brevettabile (ma protetto)Non è garantitoViene 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 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
• Ingestibile durante la manutenzione
Programming in the small/large/many
Programming in-the-small: un programmatore, un modulo = edit-compile-testProgramming in-the-large:progettare software decomposto in più moduli, su più versioni, su più configurazioniProgramming 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
progettoIl 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
manutenzioneManutenzione perfettivaManutenzione correttivaManutenzione adattiva
Modello a cascata
Molto dettagliatoMolto rigidoOrientato alladocumentazioneOrientato agli standardAdatto perorganizzazioni gerarchizzateRischioso
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 phaseconceptual 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 ruoliOccorre descrivere/controllare i gli eventiOccorre descrivere/validare i documentiOccorre 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 sviluppoAccumulazione di esperienza
Modello a spirale (Boehm)
Adatto se requisiti instabiliNon lineareFlessibileValuta il rischio
Modelli orientati alla qualità
I cicli di vita orientati alla qualità si basano di solito su modelli analitici almeno idealmente quantitativi
ISO 9000Capability Maturity Model (CMM)Six SigmaExtreme 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 measurementProcess analysisQuantitative Quality Plans
Repeteable
(Intuitive) process dependent on individuals
Establish a Processw GroupIdentify a Process ArchitectureIntroduce SE methods and tools
Initial Ad hoc/ ChaoticNo cost estimation, planning, management
Project managementProject planningSoftware Quality Assurance
La famiglia dei processi sw orientati alla qualità
Il Rational Unified Process
• L’avvento di UML ha portato alla definizionedi 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
tempo
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
progettoProdotti
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
Project ManagementProcess Configuration
RequirementsAnalysis
ArchitectureLevel
Class Level
Implementation
Test
Design
preliminaryiteration(s)
iteration#1
iteration#2...
iteration#n
iteration#n+1
iteration#n+2...
iteration#m
Phases
Process Components
Iterations
i teration#m+1...
Elaboration Construction TransitionInception
Supporting Activities
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 sviluppatoreI bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivereQuando hai perso interesse in un programma che hai costruito, è tuo dovere passare le consegne ad un successore competenteTrattare gli utenti come sviluppatori è la strada migliore per ottenere debugging efficace e rapidi miglioramenti del codiceDistribuisci presto, distribuisci spesso e presta ascolto agli utentiStabilita 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 metodoIl mito degli strumenti
Conclusioni
“Silver bullets” nel processo di sviluppo:Il mito del metodoIl mito degli strumentiIl mito della gestione del progetto
Conclusioni
“Silver bullets” nel processo di sviluppo:Il mito del metodoIl mito degli strumentiIl mito della gestione del progettoIl mito dell’organizzazione del lavoro
Conclusioni
“Silver bullets” nel processo di sviluppo:Il mito del metodoIl mito degli strumentiIl mito della gestione del progettoIl mito dell’organizzazione del lavoroIl mito della qualità
Conclusioni
L’impatto della ricerca e degli standard softwareL’impatto delle nuove tecnologie softwareL’impatto delle nuove infrastrutture di comunicazione e coordinamentoL’impatto di nuovi modelli educativiL’impatto della certificazione professionale
Recommended
