Il Processo Software

Il Processo Software 03/04/13

Prodotto Software Prodotto di qualità Tempi e costi determinati

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

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.

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.

Ciclo di vita del Software

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

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

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

Modello sequenziale (1/3) Waterfall (a cascata) Modello a cascata - sequenziale: Royce 1970 Requisiti e analisi Progettazione Implementazione and collaudo unitario Integrazione and collaudo sistema Mantenimento

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.

Modello sequenziale (3/3) alternativa: modello a V Il modello a V è percorso da sinistra a destra seguendo la lettera: le attività della costruzione precedono quelle della validazione e della verifica. Ma l'accettazione è preparata allo stesso tempo della costruzione. Permette di meglio approfondire la costruzione e di meglio pianificare la risalita. Il modello a V rende più esplicito le iterazioni e riproduzione di attività in confronto al modello a cascata.

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

Modelli evolutivi (2/5) Prod. Idea Release 1.0 Release 2.0 Produzione di release

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

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

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?

Modello prototyping (1/3) caratteristiche Prod. Idea Analisi Requisiti sconosciuti Nuova tecnologia Prototipo Mantenimento Progettazione Implementazione Vita del Prodotto Test

Modello prototyping (2/3) generalizzazione

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

Modello a spirale (1/3) Boehm 1988 : mette l'accento sull'analisi dei rischi settori 2 1 fasi 4 3 Analisi dei rischi per ridurli e controllarli

Modello a spirale (2/3) 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 Integra modelli di cascata e prototyping Modello adatto per progetti complessi e costi elevati dove la componente rischio è fondamentale.

Modello a spirale (3/3) vantaggi/svantaggi Vantaggi Aiuta alla gestione dei rischi Adattabilità ai cambiamenti Costruzione in frammenti: stima dei costi più facile Svantaggi Alta livello di complessità, competenza per la valutazione delle incertezze, dei rischi,... Costi per valutazione dei rischi possono essere più elevati che la costruzione della soluzione stessa; Costruzione in frammenti: stima dei costi più facile

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

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

Modello trasformazionale Balzar 1981 Seria di trasformazioni cambiamenti struttura dati selezione di algoritmi ottimizzazione compilazione Necessità specifiche formali

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

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

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

Modello UP (3/5) caratteristiche Incentrato sull architettura

Modello UP (4/5) Fasi

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

Taylorism

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

Metodi Agile Menifesto Agile www.agilemanifesto.org Feb. 2001 Agile Alliance

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)

Metodi Agile 4 valori per 12 principi generali

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

Metodi Agile caratteristiche Whole team tradizionale Agile

Metodi Agile caratteristiche comunicazione Limita gli errori

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

Metodi Agile esempi Esempio di processo Agile (Scrum, Feauture Driven Development (o FDD), dx (processo minimale di RUP) e Crystal) 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

Metodi Agile e altri processi

Metodi Agile non adatto a

Metodi Agile risultati

Metodi Agile risultati

Metodi Agile risultati

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

Modello XP i 4 valori Comunicazione Semplicità Feedback Un buon feedback richiede buoni testi (100% funzionante a ogni ciclo) Coraggio

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

Modello XP Come RUP eccetto che Tutti lo fanno Scritto in piccolo, più orale Meno è fatto lato design

User story User story equivalente ai use case User story meno dettagliate che use case Solo una frase o due Descrizione limitata Come lo sviluppatore conosce cosa vuole il cliente con i user story? CS427 18-52

XP timeline (1) Customer Developers Write stories Pick stories Estimate stories CS427 Implement stories 18-53

Modello XP Similar to RUP except that Everyone does it Little written, more oral Less is done up-front

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

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

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