Il Processo Software

Transcript

1 Il Processo Software

2 Prodotto Software Prodotto di qualità Tempi e costi determinati

3 Processo Software Attività portanti Famiglia di compiti Attività ausiliari Quadro di riferimento

4 Processo Software fasi Specifiche del SW Funzionalità del SW e costrizioni sulle operazioni devono essere definite. Sviluppo del SW Per rispondere alle specifiche, il SW deve essere prodotto. Validazione del SW Il SW deve essere convalidato per essere sicuro che incontro i requisiti del cliente. Evoluzione del SW Il SW deve evoluire per rispondere ai futuri desideri del cliente.

5 Processo Software caratteristiche Obiettivi del processo L obiettivo del processo di produzione è di soddisfare le aspettative del cliente consegnando prodotti di qualità nei tempi e budget pre-stabiliti. Il processo deve riflettere gli oggettivi dello sviluppo, come costruire un software di alta qualità, trovare gli errori il più rapidamente possibile, and soddisfare budget e vincoli di tempi.

6 Ciclo di vita del Software Il ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sotto-attività fra loro coordinate, una scomposizione in fasi di attività sequenziali ben definite nel tempo. Attività Controlli prodotto doc report Attività Controlli

7 Processo Software i modelli Ognuno processo deve essere tagliato per la particolare situazione per laquale viene applicato. Un modello di processo aiuta l equipe di sviluppo a capire meglio attività, risorse e vincoli per la produzione del software. I principali modelli di processi sono i seguenti: Sequenziali Incrementali Evolutivi Formali RAD UP Agili

8 Modello Build and Fix Applicazione applicazioni semplici contesto comprensibile da sviluppatori Svantaggi cambiamenti non benvenuti

9 Impossibile visualizzare l'immagine. La memoria del computer potrebbe essere insufficiente per aprire l'immagine oppure l'immagine potrebbe essere danneggiata. Riavviare il computer e aprire di nuovo il file. Se viene visualizzata di nuovo la x rossa, potrebbe essere necessario eliminare l'immagine e inserirla di nuovo. Impossibile visualizzare l'immagine. La memoria del computer potrebbe essere insufficiente per aprire l'immagine oppure l'immagine potrebbe essere danneggiata. Riavviare il computer e aprire di nuovo il file. Se viene visualizzata di nuovo la x rossa, potrebbe essere necessario eliminare l'immagine e inserirla di nuovo. Impossibile visualizzare l'immagine. La memoria del computer potrebbe essere insufficiente per aprire l'immagine oppure l'immagine potrebbe essere danneggiata. Riavviare il computer e aprire di nuovo il file. Se viene visualizzata di nuovo la x rossa, potrebbe essere necessario eliminare l'immagine e inserirla di nuovo. Impossibile visualizzare l'immagine. La memoria del computer potrebbe essere insufficiente per aprire l'immagine oppure l'immagine potrebbe essere danneggiata. Riavviare il computer e aprire di nuovo il file. Se viene visualizzata di nuovo la x rossa, potrebbe essere necessario eliminare l'immagine e inserirla di nuovo. Impossibile visualizzare l'immagine. La memoria del computer potrebbe essere insufficiente per aprire l'immagine oppure l'immagine potrebbe essere danneggiata. Riavviare il computer e aprire di nuovo il file. Se viene visualizzata di nuovo la x rossa, potrebbe essere necessario eliminare l'immagine e inserirla di nuovo. Modello sequenziale (1/3) Waterfall (a cascata) Modello a cascata - sequenziale: Royce 1970 Requisiti e analisi Progettazione Progettazione Sistema e sw Implementazione and collaudo unitario Integrazione and collaudo sistema Mantenimento

10 Modello sequenziale (2/3) caratteristiche Vantaggi Processo visibile intuitivo Svantaggi fasi devono essere complete (prima il prossimo) spesso è difficile enunciare dalla parte del cliente tutti i requisiti cliente deve essere paziente prodotto poco visibile, OK/NOK solo alla fine attesa dell équipe di sviluppatori cambiamenti non benvenuti.

11 Modello sequenziale (3/3) alternativa: modello a V I tests sono in relazione con l analisi e la progettazione. Il modello a V rende più esplicito le iterazioni e riproduzione di attività in confronto al modello a cascata.

12 Modelli evolutivi (1/5) Attività concorrenziali Modello Incrementali Specifiche Versione Initiale descrizione Sviluppo Versioni Intermediarie Modello Iterativo Validazione Versione Finale

13 Modelli evolutivi (2/5) Produzione di release

14 Modelli evolutivi (3/5) modello incrementale Produrre più sequenze lineari nel tempo Sviluppo inizia con una parte dei requisiti del software ben capiti release

15 Modelli evolutivi (4/5) modello iterativo Consegna di un sistema completo ma non finito Cambiamento funzionalità con new release

16 Modelli evolutivi (5/5) caratteristiche Vantaggi meno persone per lo sviluppo migliore organizzazione delle attività (non disponibilità completa materiale, personale, ) soluzione disponibile training in anticipo correzione problemi in anticipo focalizzazione dell expertise in fasi Svantaggi troppi cambi uccidono la struttura del sistema Poca visibilità del processo iterativo, come misurare i progressi?

17 Modello prototyping (1/3) caratteristiche Requisiti sconosciuti Nuova tecnologia

18 Modello prototyping (2/3) generalizzazione

19 Modello prototyping (3/3) vantaggi/svantaggi Vantaggi rapido aiuta a definire i requisiti fino a loro stabilità pilota nuova tecnologia, prova di funzionalità riducendo costi e rischi diventa il prodotto Svantaggi è il prodotto troppo lente, pesante, complicato

20 Modello a spirale Boehm 1988 settori fasi Analisi dei rischi per ridurli e controllarli

21 Modello a spirale caratteristiche Passi identificare i rischi, attribuire una priorità sviluppare prototipi per identificare i rischi iniziando da quello più importante utilizzare qualsiasi modello per implementare ognuno ciclo se un ciclo riguardando un rischio è stato compilato con successo,. valutare il risultato del ciclo e pianificare il ciclo seguente se un rischio non ha potuto essere risolto, finire il progetto immediatamente

22 Modello RAD (1/2) Modello anni 80 Obiettivo: migliorare la qualità dello sviluppo, riducendo i tempi e facilitando la gestione dei costi. modello iterativo con tempi di sviluppo ridotti costruzione di sistemi come collezioni di componenti utilizzo di applicazioni con metodi 4GL riuso

23 Modello RAD (2/2) caratteristiche Progetti di grande dimensione dove è richiesto risorse umane in sufficienza. Non funziona su progetti high-tech

24 Modello trasformazionale (1/2) Balzar 1981 Seria di trasformazioni cambiamenti struttura dati selezione di algoritmi ottimizzazione compilazione Necessità specifiche formali

25 Vantaggi Test rigorosi Modello trasformazionale (2/2) caratteristiche Svantaggi necessita esperti

26 Modello UP (1/2) Proposto nel 1999 da Grady Booch Ivar Jacobson James Roumbauch Iterativo incrementale

27 Modello UP (2/4) caratteristiche Guidato dei casi d uso e dall analisi dei rischi

28 Modello UP (3/5) caratteristiche Incentrato sull architettura

29 Modello UP (4/5) Fasi

30 Modello UP (5/5) Fasi Avvio Fattibilità, analisi dei rischi, requisiti essenziali per definire il contesto del sistema, eventuale prototipo (20% casi d uso definiti) Elaborazione Analisi dei requisiti, analisi dei rischi, sviluppo di un architettura di base, piano per la fase di costruzione (80% casi d uso definiti) Costruzione Analisi, disegno, implementazione, verifica Transizione Beta testing, aggiustamento delle prestazioni, creazione di documentazione aggiuntiva, attività di formazione, guide utenti, creazione di un kit per la vendita

31 Metodi Agile CHAOS Report, Standish Group: 66% of projects failed or are challenged in 2002 Large projects are failing more often than small projects Only 52% of features make it into product

32 Metodi Agile Menifesto Agile Feb Agile Alliance

33 Metodi Agile Manifesto (2001) Stiamo portando alla luce metodi migliori di sviluppare software facendolo in prima persona e aiutando altri a farlo. Attraverso questo tipo di lavoro siamo giunti ai seguenti valori: Persone e interazioni più che processi e tools Software che funziona più che una documentazione esaustiva Collaborazione con il cliente più che negoziazione contrattuale Rispondere al cambiamento più che seguire un piano prestabilito. Cioé, mentre c è un valore nelle voci sulla destra, attribuiamo un valore maggiore a quelle sulla sinistra. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Pratiche e Valori (corraggio, simplicità, communicazione, feedback)

34 Metodi Agile 4 valori per 12 principi generali

35 Metodi Agile caratteristiche sviluppo evolutivo con iterazioni corte gestione di progetto adattativo più che predittivo consegna incrementale agility: rapido e risponsa flexibile ai cambiamneti I metodi Agile encoraggiono: semplicita comunicazione auto-organizzazione dell équipe

36 Metodi Agile caratteristiche I metodi Agile cercano a: soddifare clienti con versioni frequenti accolgliere i cambiamneti

37 Modello XP Esempio di processo Agile (Scrum, Feauture Driven Development (o FDD), dx (processo minimale di RUP) e Crystal)

38 Metodi Agile caratteristiche

39 Metodi Agile i modelli Agile Modeling Agile Unified Process (AUP) Dynamic Systems Development Method (DSDM) Essential Unified Process (EssUP) Exia Process (ExP) Extreme Programming (XP) Feature Driven Development (FDD) Open Unified Process (OpenUP) Scrum Crystal Clear Velocity tracking Kanban (development) GSD

40 Modello XP Origine Kent Beck 1996 Progetto vetrina delle risorse umane della Chrystler Principi Spingere all estrema, le buone pratiche dell ingegneria del software 4 valori di base 12 pratiche Segue il manifesto Agile

41 Modello XP i 4 valori Comunicazione Semplicità Feedback Coraggio

42 Pratiche originarie di XP Modello XP Corrispondenti nel nuovo XP storie ciclo settimanale pianificazione ciclo trimestrale margine di sicurezza ciclo settimanale ciclo trimestrale rilasci piccoli rilasci incrementali rilasci giornalieri progettazione semplice progetto incrementale testing programmazione guidata dai test refactoring progetto incrementale pair programming pair programming proprietà collettiva del codice codice condiviso build di 10 minuti integrazione continua integrazione continua rilasci giornalieri 40 ore alla settimana energia sul lavoro cliente sul posto coinvolgimento reale del cliente Standard di codifica // Metafora //

43 Modello XP

44 Modello XP Applicazione Nessuna sub-appalto Non-critico Progtto non complesso Situazione emergenza Soddisfazione cliente immediata Rischio / costo minimale Supportare imprevisti Qualità Coerenza limitata (non gestione di configurazione) Nessuna certificazione Agile

45 Caratteristiche Processi Caratteristiche Comprensibile Descrizione esplicite e facile a capire la definizione del processo? Visibile Sopportabile attività del processo danno dei risultati chiari facendo vedere esternamente i progressi del processo? fino quel punto il processo può essere supportato da strumenti CASE? Accettabile Affidabile Robusto Rapido accettabile degli ingeneri per produrre il SW? processo designato in modo di evitare gli errori o può essere ricuperato prima di risultare in errori? può il processo evoluire? quanto rapido é il processo per fornire un sistema completo da specifiche date?

46 Riferimenti Libri Principi di Ingegneria del software, Pressman Software ingegneering, Theory and Practice (cap. 2) S.L.PFleeger -International Edition Ingegneria del software, creatività e metodo (cap. 8) Addison Wesley