Processo di sviluppo software. slide 1

Transcript

1 Processo di sviluppo software slide 1

2 Processo di sviluppo software Visione d'insieme Nella figura seguente, usando UML, diamo una visione d'insieme del tutto generale del processo di sviluppo software A parte le cose già viste, ne svilupperemo solo la parte sui modelli di processo, rimandando a Cultura Aziendale per le parti di management Terminologia Di seguito riportiamo una slide terminologica Warning È in corso un grosso dibattito e revisione dei modelli del processo di sviluppo software, con interi volumi nuovi dedicati Diamo una visione sintetica anche del dibattito; a IS2 se ne parla più diffusamente slide 2

3 Terminologia (nel contesto di SE ) Paradigma stili riferiti a varie fasi dello sviluppo software, per esempio: in programmazione: paradigma funzionale (ML), OO (Java), imperativo (C), logico (PROLOG) nel processo di sviluppo software: SA (Structural Analysis), OO (Analysis and Design) analogia in cucina: la cucina emiliana, ligure, francese, nouvelle cuisine; (a un livello più alto di astrazione) la cucina vegetariana, lo slow food, il fast food, ecc ; in musica: rap, hard-rock, classica, swing, ecc Processo un insieme strutturato e organizzato di attività che si svolgono per ottenere un risultato (qui un sistema software) Analogia: il servizio di ristorazione in un particolare ristorante Mc Donald o Spizzico Modello di processo un insieme strutturato e organizzato di regole e passi da seguire nell eseguire un processo Analogia: il modello di servizio ristorante Mc Donald o Spizzico Standard un insieme di proprietà che devono essere soddisfatte nello svolgere un processo e che hanno valore di misura di certificazione (ISO, CMMI, V-Model) riconosciuta a qualche livello ufficiale (è a un livello di astrazione diverso dal modello di processo; un processo può o no soddisfare uno standard; ma possiamo anche avere un modello soddisfacente o no a uno standard) Analogia: gli standard definiti dalle associazioni di ristoratori o di albergatori (con eventuali classificazioni, numero di stelle), gli standard igienici stabiliti dalle leggi dei singoli paesi slide 3

4 SE/SDP istanzia/conforme a NB. Si sta parlando di software Talvolta/spesso se ne deve parlare nel contesto dello sviluppo di un sistema (Computer-based System Engineering) System development 1 istanzia/conforme a Process Management Model 1 Software Development Model Software Quality Assurance * Software * Development * Process Management comprende 0..1 Configuration Management gestisce Software Development Process Model istanzia/ conforme a Software Development Process fa uso di * Documentation 1..* Tool * produce slide 4

5 Processo Consiste dell insieme di attività necessarie a raggiungere uno scopo, organizzate temporalmente Per ciascuna attività indica Scopo dell attività nel contesto del processo Criteri di inizio e fine Risorse usate e prodotti risultanti Può essere composto di sotto-processi Indica vincoli e controlli da applicare alle attività, sottoprocessi, prodotti intermedi e finali, risorse Esercizio proposto Estendere la figura UML del lucido precedente per descrivere i contenuti di questo lucido slide 5

6 Modelli di sviluppo del processo software diverse tipologie di modelli modelli come insieme di principi da seguire ES. waterfall, waterfall con iterazione, a spirale, prototyping ecc... modelli come insieme di regole da seguire nell'organizzare e svolgere le attività di processo Es. RUP (Rational Unified Process) es di modello prescrittivo XP (Extreme Programming) es di modello agile modelli che sono anche standard (e che definiscono il processo mediante regole da seguire, documentazione da produrre, ecc.) Vincolante per ottenere un riconoscimento di adeguatezza Spesso includono tecniche di QA (Assurance Quality) Es. V-Model slide 6

7 Waterfall Model/Modello a Cascata Storicamente il primo modello del processo di sviluppo software Mette in cascata i passi tradizionali dello sviluppo di un sistema (software), secondo quello che abbiamo visto nell introduzione e che riportiamo qui di seguito,con i ruoli professionali associati Deriva dal processo manifatturiero e ha forti analogie con lo sviluppo di altri sistemi (vedere esempio su costruzione di casa per i Sigg. Rossi) Ogni fase produce un prodotto che (tranne all ultimo passo) è l input della fase successiva Nessuna indicazione su come si passa da input ad output (nessuna idea di tracciabilità) slide 7

8 Waterfall Model REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT&INTEGRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE slide 8

9 The roles of the development team Software development steps Requirements analysis and definition System design Program design Program implementation Unit testing Integration testing System testing System delivery Maintenance trainer tester programmer designer analyst Developer Roles slide 9

10 Waterfall Model 2 QuickTime and a TIFF (LZW) decompressor are needed to see this picture. Figura alternativa dal Pressman Fa capire che i punti cruciali sono linearizzazione comunicazione fra box attraverso documenti nessuna tracciabilità esplicita quali siano i contenuti dei singoli box non è rilevante per decidere se un modello è a cascata possono essere a diversi livelli di astrazione slide 10

11 Pregi Pregi e difetti del Waterfall model enfasi su alcuni aspetti, come l analisi dei requisiti e il progetto di sistema, che tendevano ad essere trascurati nell approccio naive (aka: da badilante ): problema e poi via col codice begin Difetti inadeguato se inteso meccanicamente come una serie di passi a sé stanti Ci deve essere una continua interazione fra i passi vedasi figura seguente per uno scenario worst case modello waterfall con feedback e iterazioni (salmon waterfall model) slide 11

12 slide 12

13 Waterfall model Waterfall model (software life-cycle) (with iteration (reiterazioni)) Salmon waterfall model (G. Reggio) PROBLEM Requirement analysis/val REQUIREMENTS DEFINITION/SPECIFICATION Design/val ver DESIGN SPECIFICATION Implementation /val ver CODE Testing WORKING SYSTEM FEEDBACK ITERATION [da Royce ( 70, ma in pratica anche prima) via B. Boehm ( 76)] val validation: are we building the right product (quello che si voleva)? ver verification: are we building the product right (nel modo corretto)? slide 13

14 Modello Waterfall con Prototyping REQUIREMENTS ANALYSIS Validate SYSTEM DESIGN PROGRAM DESIGN Verify CODING PROTOTYPING UNIT & INTEGRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE slide 14

15 V-Model Nato in Germania, Ministero della difesa, 1992, ora è anche uno standard per tutte le amministrazioni pubbliche Copre vari livelli di attività Procedure "What has to be done? Methods "How is something to be done? Tool Requirements "What is to be used to do something? Consiste di 4 sottomodelli Project management Software development Quality assurance Configuration management Tool Configuration Management Quality Assurance System Development Project Management Procedure Methods Requirements slide 15

16 V-Model Nella parte di sviluppo software questo modello, chiaramente ispirato al waterfall model, evidenzia come attività di testing e maintenance (parte destra della V) sono collegate a quelle di analysis and design (parte sinistra della V) ogni controllo (di verifica e validazione) fatto a destra che non dia buon esito porta a un rifacimento/modifica di quanto fatto a sinistra in sostanza, nel modello a V sono più esplicitate certe iterazioni e rifacimenti che sono nascosti nel waterfall originale OPERATION & MAINTENANCE REQUIREMENTS ANALYSIS Validate requirements ACCEPTANCE TESTING SYSTEM DESIGN Verify design SYSTEM TESTING PROGRAM DESIGN UNIT & INTEGRATION TESTING CODING slide 16

17 Phased development Sviluppo di varie release incrementali, di cui solo l ultima è completa dopo la prima release, si procede in parallelo: utilizzo di una release e sviluppo della successiva (con feedback) D E V E L O P E R S BUILD RELEASE 1 Development systems BUILD RELEASE 2 BUILD RELEASE 3 Time U S E R S USE RELEASE 1 Production systems USE RELEASE 2 USE RELEASE 3 slide 17

18 Phased development modalità Può seguire un approccio incrementale o iterativo Es. word processing package con capacità 1. creare testo 2. cut&paste 3. formattare testo Approccio incrementale o a moduli le funzionalità vengono aggiunte un po alla volta nell esempio del word-processor 3 release corrispondenti alle capacità elencate Approccio iterativo o per features/funzionalità tutte le funzionalità dall inizio, ma in forma ridotta nell esempio del word-processor tutte le release hanno tutte le funzionalità ma release 1: interfaccia a comandi release 2: interfaccia grafica, ma alcune funzionalità sono lente release 3: sistema finale In realtà spessissimo la modalità è mista Release 3 Release 1 Release 2 Release 1 Release 2 Release 3 slide 18

19 Vantaggi dello sviluppo a fasi la riduzione del sistema nelle prime release facilita l allenamento dell utente e l osservazione della sua reazione da parte degli sviluppatori si possono utilizzare team di sviluppatori con competenze diverse (ad esempio specialisti di GUI) fix the bugs early (presto) risposta rapida al mercato (sin dall inizio time to market, prendere il tempo giusto sul mercato, sia dopo negli adattamenti a nuove esigenze) slide 19

20 Modelli tradizionali/prescrittivi Waterfall model, V-model Progetti reali si conformano raramente allo schema sequenziale Spesso e difficile per il cliente enunciare esplicitamente tutti i requisiti Il cliente deve essere paziente: versione funzionante solo alla fine, errore in fase iniziale puo avere conseguenze disastrose Stati bloccanti e tempi di attesa Modelli incrementali Requisiti iniziali piuttosto ben definiti La dimensione del progetto preclude processo lineare Necessita di fornire urgentemente alcune funzionalita da raffinare ed espandere nelle release successive Modelli evolutivi Pensati per considerare prodotto che evolve nel tempo Tengono conto delle modifiche/evoluzioni dei requisiti durante lo sviluppo slide 20

21 Modelli a Prototyping Prototyping = creazione di un prototipo si basano sulla realizzazione di un prototipo funzionante del sistema, su cui sperimentare/testare i risultati il prototipo è ridotto nel senso che ha meno funzionalità a livello quantitativo e/o qualitativo (ad esempio rispetto a requisiti di friendliness -meno interfacce grafiche-, di robustezza, ecc) è meno efficiente in termini di prestazioni il prototipo deve essere sviluppato in generale in un linguaggio di alto/altissimo livello che rende economici i tempi di realizzazione; ad esempio linguaggio di programmazione logico (PROLOG) in cui si passa facilmente dai requisiti all eseguibile; questi linguaggi permettono anche modifiche più rapide Problema economico e psicologico: i prototipi vanno buttati slide 21

22 Modello a prototipi Elenco di modifiche Elenco di modifiche Elenco di modifiche Modifica prototipo review di utenti/clienti Requisiti del prototipo Progettazione del prototipo Sistema prototipo Test Requisiti del sistema (spesso informali e incompleti) Sistema finale slide 22

23 Modelli a Prototyping Quando i requisiti sono definiti in termini di obiettivi generali ma sono troppo vaghi e devono essere raffinati Il prototipo e meccanismo per identificare i requisiti, da scartare Il rischio e di non farlo e cosi scelte non ideali diventano parte integrante del sistema puo (spesso e ) essere combinato con altri modelli aggiornamento allo stato attuale: l uso del prototyping è molto di moda anche in forme diverse, in cui si usa il linguaggio finale ma si realizzano sistemi ridotti (vedi Extreme Programming) slide 23

24 Modello a Spirale Correntemente è l approccio più realistico per sistemi e sw di grandi dimensioni approccio evolutivo con interazioni continue fra cliente e developer usa il prototyping come metodo di riduzione del rischio, ma ad ogni stadio dell evoluzione del prodotto conserva l approccio sistematico a passi del ciclo di vita classico ma con un approccio più realistico deve essere completato/instanziato con modelli per le varie attività (scelti sulla base dell analisi dei rischi) slide 24

25 Spiral Model (Barry Boehm, 1988) Planning Initial requirements gathering and project planning Planning based on customer comments Risk analysis Risk analysis based on initial requirements Risk analysis based on customer reactions Go, no-go decision Customer evaluation Initial sw prototype Next level prototype Engineered system Customer evaluation Engineering Planning: determinazione di obiettivi, alternative, vincoli Risk analysis: analisi delle alternative e identificazione/risoluzione dei rischi Engineering: sviluppo del prodotto di successivo livello Customer evaluation: valutazione dei risultati dell engineering dal punto di vista del cliente slide 25

26 Il raggio rappresenta i costi fino a quel punto slide 26

27 Modello a spirale slide 27

28 Il modello della specifica operazionale slide 28

29 Il modello trasformazionale slide 29

30 RUP Rational Unified Process RUP è un modello del processo di sviluppo software nonostante si chiami lui stesso RUP Process Va letto nel senso il processo di sviluppo software secondo il metodo unificato di Rational Unificato proviene dalla storia della sua nascita (e quindi dalla sua natura): ha (messo insieme) unificato i metodi di sviluppo proposti dai tres amigos: Booch, Rumbaugh e Jacobson RUP segue l approccio Object-Oriented e ingloba per la parte di Requisiti l approccio a Use Case (casi d uso) tipico di Jacobson (da Ericsson in poi) Nella versione più recente i Requirements sono preceduti dal Business Modelling Essenzialmente il Business Modelling (modelling nel senso di UML: specificare modellando con tecniche tipo UML) significa specificare la conoscenza relativa al dominio del problema (domain Knowledge, domain modelling) prima ancora di specificare i requisiti del sistema che deve risolvere il problema Sviluppi ulteriori (EUP) enfatizzano sempre più aspetti di gestione e inserimento nel contesto aziendale slide 30

31 RUP Rational Unified Process È uno dei più recenti modelli del processo di sviluppo software sviluppato da Rational Software (la ditta che ha prodotto UML) The Ericsson Approach (Jacobson) The Rational approach (Booch + Rumbaugh) Objectory Process Rational Objectory Process ( Jacobson) UML (Jacobson + Booch + Rumbaugh) Rational Unified Process 5.0 RUP (si legge ar-iu-pi o rap ) (Jacobson + Booch + Rumbaugh) slide 31

32 RUP Rational Unified Process RUP è un modello che incorpora molte delle idee dal modello a spirale (iterazione, prototyping, phased development) RUP si presenta piuttosto come uno schema di modello da essere adattato ( tailored ) ai diversi casi RMC Rational Method Composer: tool per supportare l adattamento di RUP a realtà aziendali specifiche In genere è visto come un modello per sistemi grandi, ma ora Rational lo propone anche in versione per sistemi piccoli BUP (IBM) Basic UP usato per/supportato da Eclipse per progetti piccoli AUP Agile UP coniuga aspetti di UP e dei processi agili È supportato da tools (visuali) in ogni fase Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practive perspective that suggests good practice. slide 32

33 Pratiche fondamentali in RUP Sviluppare il software ciclicamente Sviluppo incrementale guidato dalle esigenze del cliente Gestire i requisiti documentazione esplicita analisi preliminare dell impatto Analisi dei rischi per passare da una fase alla successiva Usare architetture basate sui componenti Creare modelli visuali del software usando UML Verificare la qualità del software standard aziendali Controllare le modifiche del software gestione delle configurazioni slide 33

34 RUP phase model slide 34

35 Inception RUP phases Establish the business case for the system. Elaboration Develop an understanding of the problem domain and the system architecture. Construction System design, programming and testing. Transition Deploy the system in its operating environment. slide 35

36 Static workflows Workflow Business modelling Requirements Analysis and design Implementation Test Deployment Configuration and change management Project management Environment Description The business processes are modelled using business use cases. Actors who interact with the system are identified and use cases are developed to model the system requirements. A design model is created and documented using architectural models, component models, object models and sequence models. The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process. Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation. A product release is created, distributed to users and installed in their workplace. This supporting workflow managed changes to the system (see Chapter 29). This supporting workflow manages the system development (see Chapter 5). This workflow is concerned with making appropriate software tools available to the software development team. slide 36

37 Visione statica e dinamica di RUP Engineering disciplines Support disciplines slide 37

38 EUP (E=Enterprise) - evoluzione di RUP slide 38

39 MDD - Model Driven Development Centrata su modelli guidano lo sviluppo formali nel senso di manipolabili da strumenti automatici unico linguaggio per tutti i livelli di astrazione Rielaborazione moderna dell approccio trasformazionale idealmente trasformazioni automatiche Lo sforzo si concentra su modello a livello business (creare, validare, aggiornare...) definizioni di mappe fra livelli slide 39

40 MDD - Model Driven Development business analyst CIM Computational Independent Model requisiti architect/ designer PIM Platform Independent Model design astratto le mappe catturano l esperienza e la rendono riusabile developer/ tester PSM Platform Specific Model design dettagliato slide 40

41 Metodi prescrittivi e metodi agili Da circa metà degli anni '90 Dibattito/controversia su Metodi prescrittivi e Metodi agili Metodi prescrittivi ( plan-driven) Es. RUP, V-model quelli che seguono un approccio classico dell'ingegneria dei sistemi fondato su processi ben definiti e con i passi standard requisiti/progetto/realizzazione questi metodi sono suscettibili di miglioramento secondo standard di misure di miglioramento del processo (es. CMM Capability Maturity Model, SPICE,etc.) concetti chiave: architettura del software di sistema, verifica, validazione, maturità, miglioramento slide 41

42 Metodi agili Agile Software Development Nati alla fine degli anni '80 dopo il successo di progetti (medio/piccoli) portati avanti da Kent Beck e altri sviluppatori di alto livello; primo libro di Beck nel 1999 sul metodo XP, Extreme Programming Vedi in generale hanno come punto di partenza l'idea del rapid prototyping una rivitalizzazione della filosofia del programmare come "arte (craft) piuttosto che processo industriale ("humanistic approach" nel talk di Beck a FASE '98) (approccio chaordic=chaos+order) sulla spinta del cambiamento in atto con l'internet economy che chiede flessibilità e velocità identificano approcci vari XP/Extreme Programming, Crystal Methods, Lean Development, Scrum, Adaptive Software Development/ASD problema principale secondo loro: evoluzione riuniti in un Manifesto for Agile Software Development (febbraio 2001) (vedi CACM, Comunication Association Computer Machine, sept. 2001) slide 42

43 Agile Software Manifesto Sulla base del risultato di un indagine su 200 progetti Conforming to plan was no longer the primary goal; satisfying customer at the time of delivery, not at project initiation took preference The question today is not how to stop change early in a project but how to better handle inevitable changes throughout its life cycle In contrasto con gli approcci tradizionali prescrittivi nei quali si tende ad assumere we could anticipate the complete set of requirements early and reduce cost by eliminating change We have come to value: individuals and interactions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plane slide 43

44 Concetti chiave dei metodi agili NB Quasi tutti concetti già noti. La novità sta soprattutto nel mix e nella mentalità che dà la prevalenza all'uso abbastanza libero di questi concetti piuttosto che all'uso di un modello di processo predefinito (infatti i vari approcci agili si differenziano nella libertà di come realizzano il mix) Ciclo rapido/consegne frequenti Ogni ciclo/iterazione affronta solo un pezzo e si deve concludere rapidamente Sviluppo test-driven Ogni funzionalità implementata deve essere accompagnata da test e testing Progettazione semplice motto YAGNI :You Aren't Going to Need It; pianificare in vista di funzionalità future è visto come perdita di tempo Refactoring just-in-time redesign (ma è anche una necessità per il modo di lavorare a pezzi /user stories) Pair programming programmazione esclusivamente in due sulla stessa stazione Meeting di riflessione e valutazione dopo ogni iterazione Tacit/implicit knowledge Conoscenza nella testa di chi lavora piuttosto che nei documenti Co-location Gli sviluppatori devono lavorare assieme e gli utenti devono essere presenti e disponibili slide 44

45 Stile di lavoro dei metodi agili Es.XP principles Vedi produce the first delivery in weeks (2-3) to achieve an early win and rapid feedback invent simple solution, so there is less to change and making those changes is easier improve design continually, making the next step less costly to implement test constantly, for early, less expensive, defect detection (Vedi XPRules e XP map nel sito xprogramming) slide 45

46 Principi base dell XP Pianificazione incrementale Story cards e task di sviluppo Piccole release Progettazione semplice Sviluppo guidato dai test Refactoring Pair-programming (programmazione a coppie) Possesso collettivo Integrazione continua Ritmo sostenibile Clienti on-site slide 46

47 Gestionali Problemi dei metodi agili La conoscenza è nella testa degli sviluppatori Si addice solo a sviluppatori molto bravi Contrattuali Tipo di contratto (a tempo o a risultato?) Quando è soddisfatto il contratto? Convalida No parallelismo Continuo refactoring anche dei test Manutenzione Documentazione scarsa Architettura complessa determinata dalla release attuale slide 47

48 Vedi bellissimo libro Valutazione B.Boehm-R.Turner, Balancing agility and discipline,addison- Wesley,2004 Stare alla larga dalle faide degli ultras In realtà Ciascuno degli approcci si trova a proprio agio se "gioca in casa" metodi prescrittivi: sistemi grandi e complessi, spesso safety-critical o con forti richieste di affidabilità e dunque requisiti stabili e ambiente predicibile metodi agili: sistemi e teams piccoli, clienti e utenti disponibili, ambiente e requisiti volatili Nuova proposta di Boehm (quello della spirale) approccio flessibile fondato sulla valutazione dei rischi: valutare per ogni aspetto del processo se conviene o no applicare, e in che misura, una componente del modello di processo Consiglio: avete già troppo nel sangue l'indisciplina e il gusto da hacker; qualunque dose di disciplina e di metodo per voi è persino poca; sarete sempre più sul versante del chaos che dell'order slide 48