Corso di Ingegneria del Software

Transcript

1 Corso di Paolo Bottoni Introduzione allo Unified Process Alcuni lucidi sono tratti dal materiale di supporto a UML2 and the Unified Process, di Arlow e Neustadt Clear View Training 2010 v2.6

2 Obiettivi Discutere UP come metodo strutturato Organizzato in fasi e attività Guidato dai casi d uso Centrato sull architettura Focalizzato sui rischi 2

3 Metodi strutturati Approcci sistematici a sviluppo progetto software Documentazione usa insieme modelli grafici Modelli possibili Modello oggetti Modello di interazione Modello di transizioni di stato Modello strutturale Modello flusso di dati 3

4 Rational Unified Process Derivato da lavoro su UML e processi associati Normalmente descritto da 3 prospettive Prospettiva dinamica: mostra fasi in tempo Prospettiva statica: mostra attività processo Prospettiva pratiche: suggerisce buone pratiche Caratteristiche: Processo guidato da casi d uso Processo centrato su architettura Approccio focalizzato sui rischi 4

5 Prospettiva dinamica: Fasi RUP Phase iteration Inception (Avvio) Stabilire caso di business per sistema Elaboration Sviluppare e comprendere dominio problema e architettura sistema Construction Progettazione, programmazione e test sistema Transition Inception Elaboration Construction Transition Stabilire sistema in ambiente di esecuzione Obiettivi specifici: 5

6 Prospettiva statica Flusso di lavoro Business modelling Requirements Analysis and design Implementation Test Deployment Configuration and change management Project management Environment Descrizione Processi di business modellati con casi di business. Si identificano attori che interagiscono con sistema e si sviluppano casi d'uso per modellare requisiti di sistema. Si crea e documenta modello di progetto, usando modelli architetturali, componenti, a oggetti e di sequenza. Componenti sistema implementati e strutturati in sotto-sistemi di implementazione. Generazione automatica di codice da modello può accelerare processo. Processo iterativo congiunto a implementazione. Test di sistema segue completamento implementazione. Creazione di rilascio prodotto, distribuzione a utenti e installazione in loro ambiente di lavoro. Flusso di lavoro di supporto per gestire cambiamenti sistema. Flusso di lavoro di supporto per gestire sviluppo sistema. Rendere disponibili strumenti software appropriati a squadra sviluppo software. 6

7 Distribuzione nelle fasi 7

8 Contenuto delle iterazioni In Inception e Elaboration Definire ambito progetto, eliminare rischi critici, creare architettura di base Iterazioni producono raffinamenti successivi In Construction Iterazioni producono incrementi Progetto composto da mini-progetti Mini-progetto contenuto di iterazione Ogni iterazione prevede flussi di lavoro 8

9 Inception Quantità di lavoro per le attività principali R A D I Focus Goals Requirements stabilire caso di business e ambito. Catturare requisiti fondamentali. Analysis stabilire la fattibilità Design progettare proof of concept o prototipi tecnici Implementation costruire proof of concept o prototipo tecnico Test generalmente non applicabilie Stabilire fattibilità del progetto creare proof of concept /prototipi tecnici Creare caso di business Ambito del sistema catturare requisiti chiave Identificare rischi critici Inception Elaboration Construction Transition 9

10 Inception - milestone Obiettivi ciclo di vita Condizioni di soddisfazione: Ambito sistema definito Requisiti chiave sistema catturati. Definiti e concordati con stakeholder Esiste visione architetturale, schematica Valutazione rischi Caso di business Confermata fattibilità Stakeholder d accordo con obiettivi progetto 10

11 Elaboration R A D I T Focus Goals Requirements raffinare ambito del sistema e requisiti Analysis stabilire cosa costruire Design creare struttura di base architetturale stabile Implementation costruire la struttura di base architetturale Test provare la struttura di base architetturale Inception Elaboration Construction Transition Creare una struttura di base architetturare eseguibile Raffinare valutazione dei rischi e definire attributi di qualità (tasso di difetti, etc.) Catturare casi d uso fino a 80% dei requisiti funzionali Creare un piano con dettaglio sufficiente per la fase di costruzione Formulare un offerta che includa costi per risorse, tempo, equipaggiamento, personale 11

12 Elaboration - milestone Architettura per ciclo di vita: Condizioni di soddisfazione Creata base di riferimento architetturale, resistente, robusta ed eseguibile Valutazione rischi aggiornata Creato piano di progetto che permetta di formulare offerta realistica Caso di business verificato rispetto a piano Stakeholder d accordo su continuare 12

13 Construction I R A D T Focus Goals Requirements scoprire requisiti eventualmente mancanti Analysis completare il modello di analisi Design completare il modello di progetto Implementation costruire la Capacità Operativa Iniziale Test provare la Capacità Operativa Iniziale Completare identificazione, descrizione e realizzazione dei casi d uso Completare analisi, progetto, implementazione e prova Mantenere l integrità dell architettura di sistema Revisionare la valutazione del rischio Inception Elaboration Construction Transition 13

14 Construction - milestone Capacità Operativa Iniziale - Condizioni di soddisfazione: Prodotto pronto per beta testing in ambiente utente 14

15 Transition I T D Focus Goals Requirements non applicabile Analysis non applicabile Design modificare il progetto se emergono problemi durante beta test Implementation adattare il software per il sito utente. Correggere errori scoperti Test eseguire beta test e prova di accettazione presso l utente Inception Elaboration Construction Transition Correggere difetti Preparare ambiente utente per il nuovo software e adattare il software per operare presso l utente Modificare software se emergono problemi non previsti Creare manuale utente e altra documentazione Fornire consulenza al cliente Condurre revisione post-progetto 15

16 Transition milestone Rilascio prodotto - Condizioni di soddisfazione: Completati beta testing, test di accettazione e correzione difetti Prodotto rilasciato verso comunità utenti 16

17 Buone pratiche RUP Sviluppare software iterativamente Gestire requisiti Casi d'uso e Supplementary Requirement Specification Usare architetture basate su componenti Modellare software visivamente Verificare qualità software Controllare cambiamenti software 17

18 Modelli e Flussi di lavoro 18

19 Notazione dei processi 19

20 Processo guidato da casi d uso Molti tipi di utenti: attori (anche non umani) Caso d'uso: sequenza di azioni effettuate da sistema per produrre risultati di valore per attore Modello formato da attori e casi d'uso sistema 20

21 Cattura dei casi d'uso Attività di raccolta requisiti Modello UC rappresenta requisiti funzionali Diagramma UC descrive parte modello e mostra associazioni fra casi e attori Attori definiscono ambiente sistema Flussi di eventi descrivono comportamenti desiderati Requisiti non funzionali associabili a UC Performance, disponibilità, accuratezza 21

22 Flusso di lavoro di requisiti: ruoli 22

23 Flusso di lavoro di requisiti: Artefatti 23

24 Completamento analisi requisiti find functional requirements Requirements Engineer find non-functional requirements prioritise requirements Architect trace requirements to use cases Estensione flusso di lavoro base in UP con elicitazione e tracciabilità requisiti 24

25 Evoluzione del modello dei casi d'uso Da modello casi d'uso a modello analisi Da modello analisi a modello progetto Classificatori e realizzazioni casi d'uso Classificatori hanno strutture e operazioni, descritti da statechart 25

26 Modello di analisi Descrizione dettagliata requisiti Raffinamento casi d'uso: collaborazioni fra classificatori concettuali Permette creazione di architettura Ha carattere temporaneo (prime iterazioni) Per grandi sistemi mantenuto per tutto progetto 26

27 Flusso di lavoro di analisi: ruoli 27

28 Flusso di lavoro di analisi: artefatti 28

29 Costruzione modello di analisi Procedimento per ogni UC Integrazione analisi nomi-verbi Responsabilità UC date a classi Classi con responsabilità in diversi UC Ogni classe deve soddisfare ogni ruolo di collaborazione definito (Possibile utilizzo schede CRC) Realizzazione UC Collaborazione fra elementi 29

30 Analisi nomi verbi 30

31 Esempi di carte CRC 31

32 Modello di progetto Modello gerarchico Esistono relazioni che attraversano gerarchia Realizzazioni UC tracciabili a realizzazioni in modello di analisi Realizzazioni UC come stereotipi di collaborazioni Riferimento per implementazione 32

33 Flusso di lavoro di progetto: ruoli 33

34 Flusso di lavoro di progetto: artefatti 34

35 Costruzione modello di progetto Classi e realizzazioni UC progettate per sfruttare prodotti e tecnologie utilizzabili Raggruppamento classi di progetto in sottosistemi e definizione interfacce fra sotto-sistemi 35

36 Modello di dispiegamento Definizione organizzazione fisica sistema come rete di nodi computazionali Verifica implementabilità UC per mezzo di componenti eseguiti su nodi definiti 36

37 Flusso di implementazione Pianificare integrazioni di sistema per ogni iterazione (incrementale) Distribuire sistema, componenti eseguibili su nodi in modello di dispiegamento Implementare classi e sottosistemi di progetto. Classi file di codice sorgente Fare test unitari su componenti 37

38 Modello di implementazione Classi progettate implementate come insiemi di file componenti (codice sorgente) Classi compilate e collegate per produrre eseguibili Ordine implementazione/integrazione basato su UC Importanza della prioritizzazione 38

39 Implementazione nelle fasi Fuoco di fase di costruzione Svolta anche durante elaborazione per creare base architetturale Durante transizione per gestire difetti riscontrati durante beta test Aspetti minimi in inception relativi a prototipi di interfaccia 39

40 Flusso di test Verifica che sistema implementi funzionalità descritte in UC e soddisfi requisiti di sistema Modello di test formato da casi di test Collezione di ingressi, condizioni di esecuzione, risultati Tracciabilità a casi d'uso Black box: test definiti da casi d'uso White box: test definiti da realizzazioni 40

41 Flusso di test: ruoli 41

42 Processo centrato sull'architettura Architettura software comporta decisioni su: Organizzazione sistema Elementi strutturali, interfacce, comportamento in collaborazioni Composizione elementi in sottosistemi più grandi Stile architetturale struttura alto livello, meccanismi chiave Centrata su come, non su cosa Progetto architetturale e progetto funzionale 42

43 Principi architetturali Esempio di Ericcson AXE Sistema di switching di telecomunicazioni 1970/oggi, 145 paesi, 180M linee, > 6000 scambi Modularità funzionale: blocchi di classi in base a funzioni Separazione progetto interfacce/sottosistemi di servizio Proiezione sottosistemi su componenti implementazione Basso accoppiamento fra sottosistemi: segnali 43

44 Influenze sull'architettura Casi d'uso significativi per architettura (10-15%) Vincoli e facilitatori Software disponibile (di sistema, legacy, middleware), standard e politiche, requisiti non funzionali, distribuzione Esperienza Architetture precedenti, pattern architetturali 44

45 Sviluppo dell'architettura Iterativo in fase di elaborazione Decisione su disegno ad alto livello Aspetti generali dipendenti da dominio, scelta nodi, selezione di vincoli e abilitatori Aspetti specifici applicazione Funzionalità completa solo quando architettura stabile 45

46 Viste architetturali Per modello di progetto Sottosistemi principali, interfacce, classi principali, classi attive, cicli di vita Per modello di dispiegamento Struttura fisica in termini di nodi connessi Assegnazione di componenti eseguibili a nodi Per modello di implementazione Distinzione responsabilità, e.g. client-server 46

47 Processo iterativo e incrementale Sequenza di pietre miliari Iterazioni e incrementi per ogni fase Criteri essenziali Inception - adeguatezza (viability) Elaboration - realizzabilità Construction - operazionalità iniziale Transition - operazionalità finale 47

48 Sviluppo a piccoli passi Pianificazione ridotta Specifica, progetto e implementazione ridotti Integrazione, test e esecuzione ridotti Se soddisfatti, prossimo passo Elaborazione feedback fra passo e successivo 48

49 Approccio focalizzato sui rischi Rischi determinano iterazioni e priorità Valutazione nuove tecnologie Soddisfazione requisiti Robustezza architettura Iterazioni esplorano rischi in ogni fase 49

50 Rischi relativi alle tecnologie Distribuzione processi su nodi, sincronizzazione Casi d'uso possono dipendere da tecniche computazionali non ben sviluppate 50

51 Rischi relativi all'architettura UC selezionati non definiscono struttura sottosistemi adeguata Framework per riuso non adeguati Nuove versioni software di qualità insufficiente 51

52 Rischi relativi a soddisfazione utente Inadeguatezza estrazione requisiti Valutazione importanza funzioni 52