| Modelli di Produzione del
SW: dal Ciclo a Cascata all’Open Source |
| 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 |
| Il processo edit-compile-test |
| Il processo edit-compile-test |
| Il processo edit-compile-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 |
| Segmentare il ciclo di vita |
| Segmentare il ciclo di vita |
| Segmentare il ciclo di vita |
| 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 |
| ISO9000-3 è ISO9001 per le fabbriche del sw |
| Capability Maturity Model |
| La famiglia dei processi sw
orientati alla qualità |
| Il Rational Unified Process |
| 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 | |||
| 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 |
| 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 | |
| ciancarini@cs.unibo.it | |
| www.cs.unibo.it/~cianca |