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 editcompile

Il processo edit-compile-test editcompiletest

Il processo edit-compile-test editcompiletest 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-test Programming in-the-large: progettare software decomposto in più moduli, su più versioni, su più configurazioni Programming in-the-many: progettare software > 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

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 ISO è ISO9001 per le fabbriche del sw ISO 9000Quality management and quality assurance standards; guidelines for selection and use ISO 9001Quality systems model for quality assurance in design, development, production, installation, and servicing ISO 9002Quality systems model for quality assurance in production and installation ISO 9003Quality systems model for quality assurance in final inspection and test ISO 9004Quality management and quality systems elements. Guidelines

Capability Maturity Model LevelCharacteristicKey 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 ConcezioneElaborazioneCostruzioneTransizione 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 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

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