Ingegneria del Software

Transcript

1 UNIVERSITA DI FIRENZE Facoltà di Ingegneria Ingegneria del Software Prof. Giacomo Bucci ( ) Ciclo di Vita Ciclo a Cascata e a V Modelli agili Standard e Normativa PROVVISORIO

2 Il ciclo di vita Da ANSI / IEEE Std Il ciclo di vita è il periodo di tempo che: inizia quando un prodotto software viene concepito termina quando il prodotto software non viene più usato Costituisce il contesto organizzativo per lo sviluppo di un progetto Detto anche processo software Ciclo di vita G. Bucci 2

3 Il ciclo di vita (processo software) Organizzato in fasi. Grossolanamente: sviluppo e uso La fase di uso è molto più lunga della fase di progetto e sviluppo durante la fase d uso è normale apportare modifiche Inizio Rilascio Abbandono Sviluppo Leggenda metropolitana: Uso Il costo della fase di uso (costo maintenance) è il 70% del totale Ciclo di vita G. Bucci 3

4 Ciclo di vita Due classi estreme di modelli del ciclo Modelli Prescrittivi fasi ben codificate in successione organizzazione e metodi Esempio: modello cascata Modelli Agili privilegiano l adattabilità riducono la burocrazia Esempio: Extreme programming Code & Fix : Non è niente!!! Ciclo di vita G. Bucci 4

5 Ciclo di vita Serve un modello che possa essere: controllato diviso in fasi che consenta di identificare i semilavorati lungo il processo di produzione che permetta di identificare milestones etc. Ciclo di vita G. Bucci 5

6 Schema preliminare Requisiti Analisi Spec. Requisiti Spazio del problema Progettazione Spec. Progetto Realizzazione Spazio della soluzione Codice corretto Ciclo di vita G. Bucci 6

7 Modello del ciclo di vita a Cascata W. W. Royce, Winston W., Managing the Development of Large Software Systems, IEEE 1970 Ciclo di vita G. Bucci 7

8 Modello a cascata Capostipite di tutti i modelli di ciclo di vita risente dell epoca in cui è stato formulato albori dell industria del software macchine/strumenti scadenti E un po il modello industria pesante o piano quinquennale Ciclo di vita G. Bucci 8

9 Modello a Cascata: Fasi e deliverables (i principali) Studio di Fattibilità Analisi Più una caterva di altri documenti SRS Progetto Elementi di disturbo Codifica Test unit DS Integraz Test sist. Codice e risultati test Manutenz Ciclo di vita G. Bucci 9

10 Fasi Ogni fase ha un obiettivo definito; si basa sui risultati della fase precedente Le fasi corrispondono ad attività che transformano i loro ingressi in uscite; presuppongono la verifica ai milestones Ciclo di vita G. Bucci 10

11 Milestone E un evento predefinito che serve a misurare il progredire dello sviluppo Un milestone prevede normalmente: la consegna di prodotti (intermedi) - detti deliverable un esame (review) formale (l emissione di un documento) Ciclo di vita G. Bucci 11

12 Analisi/specifica dei requisiti L analisi è lo studio di un problema prima di intraprendere qualsiasi azione (*) L analisi è lo studio del dominio di un problema, che porta alla specifica di un comportamento esternamente osservabile, a una descrizione coerente e fattibile di ciò che occorre realizzare De Marco Structured Analysis and System Specification", Yourdon Press, Ciclo di vita G. Bucci 12

13 Analisi Analisi SRS Il principale deliverable prodotto è l SRS Fornisce una base di confronto e di accordo contrattuale con il committente Dovrebbe produrre anche il Manuale Utente e il Piano di test del sistema Il manuale utente dice meglio di qualunque altra cosa come si comporterà il sistema Il piano di test dice come verranno condotti i test del sistema Grande approfondimento Ciclo di vita G. Bucci 13

14 Progettazione SRS Progetto DS La Specifica di Progetto (DS) contiene l architettura del software: Scomposizione del sistema in sottosistemi Identificazione dei moduli e delle relazioni tra i moduli (struttura del sistema secondo una conveniente rappresentazione) Interfacce Convenzioni di chiamata... Ciclo di vita G. Bucci 14

15 Realizzazione C&T DS Codice e risultati test Codifica I singoli moduli vengono sviluppati in base alla specifica di progetto, nel linguaggio di programmazione scelto Test individuali I singoli moduli vengono provati per conto proprio Ciclo di vita G. Bucci 15

16 Integrazione Il fatto che i singoli moduli siano individualmente testati non è sufficiente a garantire il corretto funzionamento del sistema Spesso si scoprono incongruenze progettuali Normalmente è la fase più dolente Si parla di alfa test, beta test, COLLAUDO Ciclo di vita G. Bucci 16

17 Manutenzione I costi per la manutenzione sono di norma superiori ai costi di sviluppo Si parla di un 70% del costo totale (sviluppo più manutenzione) Correttiva (eliminazione errori) Adattativa (alle condizioni esterne) Perfettiva (nuove funzionalità, eliminazione di funzionalità inutili) di norma oltre il 50% della manutenzione Sui costi di manutenzione hanno grande incidenza: la modalità di progetto e sviluppo la qualità della documentazione Ciclo di vita G. Bucci 17

18 Documentazione Documentazione tecnica interna motivazioni per le assunzioni fatte e le decisioni prese in ogni fase risultati dei test Documentazione tecnica esterna struttura del sistema istruzioni per l installazione guida alla soluzione dei problemi... Documentazione per l utente finale Manuale utente prontuario (quick reference) guided tour... Ciclo di vita G. Bucci 18

19 Costi modifiche (tradizionale) Dati sperimentali indicavano che il costo dei cambiamenti cresceva esponenzialmente nel tempo Ciclo di vita G. Bucci 19

20 Se i costi crescono esponenzialmente: Bisogna pianificare bene le attività del progetto Scoprire un errore subito fa salvare denaro Modificare il modello è meglio che modificare il codice =>Investire sulle fasi di analisi =>BDUF (big design up-front) E proprio così? Ciclo di vita G. Bucci 20

21 Il modello a cascata Presume che sia possibile definire esattamente quali sono i requisiti del sistema Presume che i requisiti siano stabili Ma i requisiti non sono stabili E la traduzione dei processi manifatturieri: La Fiat deve pianificare esattamente la catena di montaggio. Il SW può essere cambiato sempre Ciclo di vita G. Bucci 21

22 Problemi del ciclo a cascata Tende a spostare in avanti le verifiche: Ci si può accorgere troppo tardi di errate concezioni o di errori Produce disallineamento tra ciò che viene fatto e ciò che era desiderato Il prodotto risultante finisce per soddisfare le esigenze degli sviluppatori, anziché quelle dei committenti. Ciclo di vita G. Bucci 22

23 Cosa ci si aspetta Dall uso di strumenti, tecniche e metodi attuali Ciclo di vita G. Bucci 23

24 Perché investire tanto nella fase iniziale quando non si sa bene dove si va a cascare? Perché investire su cose che possono rivelarsi del tutto inutili?...il tempo dirà al momento opportuno cosa fare e cosa non fare Ciclo di vita G. Bucci 24

25 Inoltre Il modello a cascata Tende a irreggimentare Non si adatta allo spirito del programmatore (un progettista/inventore piuttosto che un produttore) E burocratico impone la produzione di una quantità di semilavorati che disturba il programmatore Occorrono modelli meno rigidi Ciclo di vita G. Bucci 25

26 Prototipazione Un modo per ridurre i problemi Prototipo: una realizzazione parziale di un sistema, costruita allo scopo di permettere a committenti, utenti e sviluppatori una miglior conoscenza del problema e delle sue soluzioni Usa e getta Prototipo evolutivo Ciclo di vita G. Bucci 26

27 Prototipazione L uso di prototipi aiuta nella scrittura di SRS Il committente preferisce vedere un prototipo piuttosto che un documento scritto Il prototipo mette in evidenza aspetti non previsti Alcuni requisiti (p.e., i formati delle videate) possono essere estratti direttamente dal prototipo e portati in SRS Il processo deve essere ordinato: successivi rilasci di SRS e relativi prototipi, fino ad arrivare a SRS definitivo. Ciclo di vita G. Bucci 27

28 Evoluzione tecnologica Nel processo software: dal metodo a cascata ai metodi agili Ciclo di vita G. Bucci 28

29 Modello iterativo-evolutivo Successivi ampliamenti e rifiniture attraverso iterazioni multiple (feedback) Il sistema cresce incrementalmente Ciclo di vita G. Bucci 29

30 UP Unified Process Modello proposto da chi ha definito UML E iterativo e incrementale Ogni iterazione è fatta di: Requisiti, analisi, progettazione, implementazione, test E pilotato dai casi d uso (requisiti) Ciclo di vita G. Bucci 30

31 RUP This diagram is Copyright IBM. Ciclo di vita G. Bucci 31

32 UP Sostanzialmente ci riferiremo ad esso W. Zuser, S. Biffl, T. Grechenig, M. Kohle,, Ingegneria del software con UML e Unified process, McGraw-Hill, 2004 Ciclo di vita G. Bucci 32

33 Modelli leggeri/agili Nati in opposizione (estrema) ai metodi tradizionali I metodi tradizionali sono inadeguati specialmente quando: i requisiti sono incerti o variabili si richiede una rapida risposta ai cambiamenti di mercato Ciclo di vita G. Bucci 33

34 Modelli leggeri/agili Ogni applicazione pone problemi diversi E irrealistico definire un processo universalmente valido, senza cadere nei generici richiami al buon senso Occorre adattare il processo alle specifiche esigenze del caso Le tecnologie moderne aiutano Ciclo di vita G. Bucci 34

35 Modelli leggeri/agili Il lavoro aggiuntivo per i semilavorati intermedi risulta in una burocrazia inutile, che influisce in maniera negativa su flessibilità e efficienza. ridurre il lavoro di supporto, convogliando il massimo dello sforzo sulla mera produzione dell applicazione Ciclo di vita G. Bucci 35

36 Manifesto (2001) Privilegiare gli individui e le loro interazioni rispetto a processi e strumenti la disponibilità di sw funzionante rispetto a un ampia documentazione la collaborazione col cliente rispetto alla negoziazione dei contratti la pronta risposta ai cambiamenti rispetto all esecuzione di un piano Ciclo di vita G. Bucci 36

37 ..ovvero Dettagliate specifiche formali, approfondite analisi e puntigliosa documentazione sono considerate attività troppo costose rispetto ai benefici apportati limitano la flessibilità del processo che deve poter modificare i propri obiettivi in ogni momento. Ciclo di vita G. Bucci 37

38 XP extreme Programming (l agile estremo) Ciclo di vita G. Bucci 38

39 What is XP? XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. -- Kent Beck. XP is: Humane. Honest. Productive. Professional. Fun. Ciclo di vita G. Bucci 39

40 What is XP? XP is a discipline of software development. There are certain things you must do. You must write tests before code. You must program in pairs. You must integrate frequently. You must be rested. You must communicate with the customer daily. You must follow the customer s priorities. You must leave the software clean and simple by the end of the day. You must adapt the process and practices to your environment. Ciclo di vita G. Bucci 40

41 extreme Programming Evita la produzione di semilavorati diversi da quelli necessari alla realizzazione delle applicazioni Mira a fornire meccanismi che, in corso d opera, danno agli sviluppatori la consapevolezza che ciò che stanno costruendo soddisferà pienamente le esigenze del committente/utente Ciclo di vita G. Bucci 41

42 Attività Quattro attività fondamentali che si ripetono per tutto il progetto: scrittura del codice dell applicazione (coding); verifica delle funzionalità (testing); osservazione dell ambiente inteso come desideri del committente, opportunità tecnologiche, sviluppi di mercato (listening); progetto dell applicazione (design). Ciclo di vita G. Bucci 42

43 Criteri I programmatori sono responsabili non solo della codifica dell applicazione, ma anche della sua verifica L enfasi è sulla verifica: Prima di scrivere le istruzioni pensare a come si testano nessuna istruzione dovrebbe essere considerata veramente parte dell applicazione finché non ne sia stato verificato l effetto secondo le attese Ciclo di vita G. Bucci 43

44 What makes XP familiar? XP matches the behavior of successful programmers in the wild. Tests. Refactoring. Evolutionary delivery. Incremental planning. Low overhead. Ciclo di vita G. Bucci 44

45 Processo La costruzione dell applicazione procede in maniera iterativa cogliendo le reazioni dei committenti e riprogettando, in maniera adeguata, le sue funzionalità e i meccanismi adottati per ottenerle Ciclo di vita G. Bucci 45

46 Extreme programming Pianificazione attività (planning the game) Brevi Iterazioni, Rilasci frequenti (Short releases) Progetti semplici (simple design) Integrazione continua (continous integration) Ristrutturazione del codice (refactoring) Verifica di ogni funzionalità (testing) Programmazione a coppie (pair programming) Proprietà collettiva del codice (collective ownership) Partecipazione del committente (onsite costumer) Uso di standard di codifica (coding standards) Rinuncia la lavoro straordinaro (40 h/w) Ciclo di vita G. Bucci 46

47 Costi con XP (pretesi) Sarà vero? Difficile! Ciclo di vita G. Bucci 47

48 Vantaggi XP Coinvolgimento del cliente Attività più gratificante per il programmatore Riduzione dei costi Maggior adeguamento al cambiamento in corso d opera Ciclo di vita G. Bucci 48

49 Problemi XP C è il rischio di cadere nel CODE & FIX Contrario a ogni pratica ingegneristica Conta troppo sulla qualità delle persone Chi fa software non sempre è un genio!!! Hacker XP Cascata Agili Adattativi Pianificati Pescrittivi Ciclo di vita G. Bucci 49

50 Lavoro individuale Approfondire il modello XP andare al sito dell XP Visitare il sito Ciclo di vita G. Bucci 50

51 Bibliografia W. Zuser e altri, Ingegneria del software con UML e Unified process, McGraw-Hill, 2004 Kent Beck Extreme Programming Explained: Embrace Change, Addison-Wesley (1999) B. Boehm, Get Ready with Agile methods, with Care, IEEE Computer Genn. 2002, pp Ciclo di vita G. Bucci 51

52 Quando la sicurezza è il requisito principale Sostanzialmente viene seguito il criterio del metodo a cascata: analisi e progettazione accurate sin dall inizio. Analisi dei requisiti, analisi del rischio, tracciabilità dei requisiti, pianificazione, assicurazione della qualità, versionamento,.. Ciclo di vita G. Bucci 52

53 Sicurezza Al termine sicurezza corrispondono due termini inglesi: safety e security Safety: the condition of being safe; freedom from danger, risk, or injury Security: something that gives or assures safety Si parla spesso di safety integrity level per indicare la misura della garanzia che un sistema dà di essere libero da determinati pericoli. Ciclo di vita G. Bucci 53

54 Dove e come Sistemi embedded, sistemi medicali, controllo del traffico aereo, ecc.. Devono garantire affidabilità, sicurezza, qualità, Di norma il processo software è strutturato come un modello a V (un adeguamento del modello a cascata) Normative e standard (di prodotto e di processo) per i vari settori (ferrovie, avionica,..) Ciclo di vita G. Bucci 54

55 Modello a V (in generale) Originally issued as a standard of the German Federal Administration The V-Modell is a process model for planning and executing Projects. The V-Modell improves project transparency, project management and the probability of success by defining concrete practices with associated results and responsible Roles Describes the development process from a functional point of view, defining a set of activities and products (results) that have to be produced. Publicly available It has been adopted by many companies and tailored to a variety of specific application contexts Ciclo di vita G. Bucci 55

56 Modello a V (in generale) Ciclo di vita G. Bucci 56

57 Produzione di sistemi HW/SW Ciclo di vita G. Bucci 57

58 Ciclo di vita G. Bucci 58

59 defines User Requirements, specifying both functional requirements and non-functional requirements. Ciclo di vita G. Bucci 59

60 identifies main system units and allocates User Requirements to each of them. Ciclo di vita G. Bucci 60

61 examines both software and hardware resources of each unit, decomposing them into software and hardware components that, according to the notation of Software Configuration Management, are referred to as Computer Software Configuration Items (CSCIs) and Hardware Configuration Items (HCIs). Ciclo di vita G. Bucci 61

62 V Model In software context Aimed at regulating the processes of system development, maintenance and modification in the software life cycle. Mentioned within a variety of process quality standards such as RTCA/DO-178B and CENELEC Ciclo di vita G. Bucci 62

63 Modello a V (solo SW) Ciclo di vita G. Bucci 63

64 Associaz. standardizzazione ISO (International Standard Organization) CEN/CENELEC (Comité européen de normalisation / Comité européen de normalisation en électronique et en électrotechnique) ECMA (European Computer Manufacturers Association) ANSI (American National Standards Institute) NIST (National Institute of Standards and Technology) IEEE UNI (Ente Nazionale Italiano di Unificazione) DOD, FDA..e molte altre Ciclo di vita G. Bucci 64

65 Ciclo di vita G. Bucci 65

66 Cosa contiene uno standard Scopo del documento EN 50128: This Standard concentrates on the methods which need to be used in order to provide software which meets the demands for safety integrity which are placed upon it by Definizione dei termini Identificazione degli attori Ciclo di vita Elencazione della documentazione richiesta Raccomandazioni Ciclo di vita G. Bucci 66

67 ESEMPIO: Normative CEI EN 50128, EN La Normativa specifica le procedure ed i requisiti tecnici per lo sviluppo del software nelle applicazioni ferroviarie EN Railway applications - Communication, signalling and processing systems - Safety related electronic systems for signalling Ciclo di vita G. Bucci 67

68 Fail-Safe I sistemi elettronici per il segnalamento ferroviario sono critici per la sicurezza. Devono conformarsi a criteri per il raggiungimento di Safety Requirements. Ovvero devono rispondere a seconda delle funzioni svolte a determinati SIL (Safety Integrity Level) software safety integrity level: A classification number which determines the techniques and measures that have to be applied in order to reduce residual software faults to an appropriate level 5 livelli : da 0 a 4 (zero praticamente nessun provvedimento) Ciclo di vita G. Bucci 68

69 EN Le normative europee CEI EN e forniscono dettagli circa i criteri da applicare per i processi di: Formazione del personale; Gestione della sicurezza; Gestione della qualità; Specifica dei requisiti del sistema; Definizione dell architettura del sistema; Definizione delle caratteristiche progettuali; Progettazione; Valutazione degli effetti dei guasti; Verifica e validazione Ciclo di vita G. Bucci 69

70 Modello a V di EN50128 Ciclo di vita G. Bucci 70