Modelli di Produzione del SW: dal Ciclo a Cascata all’Open Source

1. Modelli di Produzione del SW:dal Ciclo a Cascata all’Open Source Paolo Ciancarini Dip. Scienze dell’Informazione Università di Bologna

2. 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

3. 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]

4. 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

5. 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

6. Il processo edit-compile-test edit

7. Il processo edit-compile-test edit compile

8. Il processo edit-compile-test edit compile test

9. 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

10. 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

11. Segmentare il ciclo di vita È la fase di stesura dei requisiti e di descrizione degli scenari d’uso specifica

12. Segmentare il ciclo di vita specifica Il progetto determina un’architettura software capace di soddisfare i requisiti specificati progetto

13. Segmentare il ciclo di vita specifica progetto La costruzione, o codifica, è una fase complessa che include il testing e termina con il deployment del sistema costruzione

14. Segmentare il ciclo di vita specifica progetto costruzione Manutenzione perfettivaManutenzione correttivaManutenzione adattiva manutenzione

15. Modello a cascata • Molto dettagliato • Molto rigido • Orientato alladocumentazione • Orientato agli standard • Adatto perorganizzazioni gerarchizzate • Rischioso

16. Modello a cascata, versione a V

17. 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!

18. 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

19. Modello a spirale (Boehm) • Adatto se requisiti instabili • Non lineare • Flessibile • Valuta il rischio

20. 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

21. ISO 9000 • ISO9000-3 è ISO9001 per le fabbriche del sw

22. Capability Maturity Model

23. La famiglia dei processi sw orientati alla qualità

24. Concezione Elaborazione Costruzione Transizione tempo 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

25. 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%)

26. 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

27. 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

28. 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

29. P h a s e s I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n P r o c e s s C o m p o n e n t s T r a n s i t i o n R e q u i r e m e n t s A n a l y s i s A r c h i t e c t u r e L e v e l D e s i g n C l a s s L e v e l I m p l e m e n t a t i o n T e s t S u p p o r t i n g A c t i v i t i e s P r o j e c t M a n a g e m e n t P r o c e s s C o n f i g u r a t i o n p r e l i m i n a r y i t e r a t i o n i t e r a t i o n i t e r a t i o n i t e r a t i o n i t e r a t i o n i t e r a t i o n i t e r a t i o n i t e r a t i o n ( s ) # 1 # 2 . . . # n # n + 1 # n + 2 . . . # m # m + 1 . . . I t e r a t i o n s 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

30. Il processo Microsoft • Pianificazione • Documento programmatico • Specifica • Team management • Sviluppo • 3-4 Sottoprogetti • Stabilizzazione • Collaudo interno • Collaudo esterno • Golden master

31. 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

32. 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”

33. 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.

34. Conclusioni “Silver bullets” nel processo di sviluppo:

35. Conclusioni “Silver bullets” nel processo di sviluppo: • Il mito del metodo

36. Conclusioni “Silver bullets” nel processo di sviluppo: • Il mito del metodo • Il mito degli strumenti

37. Conclusioni “Silver bullets” nel processo di sviluppo: • Il mito del metodo • Il mito degli strumenti • Il mito della gestione del progetto

38. 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

39. 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à

40. 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

41. Fine Grazie per l’attenzione! Paolo Ciancarini ciancarini@cs.unibo.it www.cs.unibo.it/~cianca