Introduzione all Ingegneria del Software

Transcript

1 Introduzione all Ingegneria del Software Alessandro Martinelli 10 Dicembre 2013 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software Waterfall Model Modelli a Spirale Sviluppo Incrementale ed Iterativo Agile Software Development ed Extreme Programming Il Rilascio del Software e le Versioni Fondamenti di Informatica II

2 Ingegneria del Software Due parole : Software e Ingegneria Software Linguaggi (C,Java), Paradigmi (Procedurali, ad Oggetti), Metafore di Programmazione Codice di Programmazione Strumenti di Case (Eclipse) Ingegneria Progettazione, Disegno Sviluppo e Produzione Verifica, Collaudo Uso di Strumentazione Tecnica Applicazione di Standard A. Martinelli Modelli di Sviluppo 10/12/ / 29

3 Ingegneria del Software Ingegneria del Software Ingegneria del Software Un insieme di pratiche Ingegneristiche che servono a supportare e a migliorare la realizzazione di un prodotto software. Migliorare? Ridurre i tempi di sviluppo Ridurre gli errori di produzione. Sfruttare soluzioni standard di cui beneficino modularità, riciclabilità, portabilità, usabilità... A. Martinelli Modelli di Sviluppo 10/12/ / 29

4 Alcuni Elementi di Ingegneria del Software Le pratiche dell Ingegneria del Software Tra le pratiche principali dell Ingegneria del Software troviamo: Metriche : forniscono valutazioni oggettive e misurabili del codice. Design Pattern : offrono dei modelli di progettazione utili e riciclabili. Linguaggi di Modellazione : offrono uno strumento per l analisi e la progettazione del Software. Esempio: i Diagrammi delle Classi UML Metodologie e Tool per lo Sviluppo : formalizzano la tecnica di sviluppo del Software, standardizzando lo sviluppo stesso e consentendo un più semplice coordinamento tra gli sviluppatori. Questa lezione è dedicata soprattutto ai modelli di sviluppo sui Modelli di Sviluppo. A. Martinelli Modelli di Sviluppo 10/12/ / 29

5 Alcuni Elementi di Ingegneria del Software Metriche Alcuni esempi di metriche: LoC (Lines of Code) : ne esistono molte varianti Fattore di qualità : Q = LoC N Errori Critica alle Metriche LoC o simili Famose intorno agli anni 80, venivano usate per misurare la produttività degli sviluppatori e sono state estremamente criticate, perché: Poco significative. Favoriscono la ripetizione e la duplicazione di codice. Sfavoriscono interventi volti a migliorare la riusabilità del codice. Perchè: le metriche buone (come la Lack of Cohesion in Methods) sono quelle che l ingegnere usa per valutare la qualità del proprio operato, non quelle usate dai dirigenti per valutare la produttività degli ingegneri. A. Martinelli Modelli di Sviluppo 10/12/ / 29

6 Modelli di Sviluppo del Software Modelli di Sviluppo del Software Per agevolare l organizzazione ed il flusso di lavoro di grandi progetti è necessario definire un Modello di Sviluppo attraverso il quale vengono pianificate ed organizzate le attività di Sviluppo. La scelta del Modello di Sviluppo è vincolata: Dalle persone coinvolte Dai requisiti temporali (i.e. Pagamento alla consegna) Dalla dimensione del progetto Dalla tipologia di Progetto Dal periodo storico in cui il progetto è iniziato Sulle Metodologie di Sviluppo Il tema della Metodologia di Sviluppo è un tema molto caldo al giorno d oggi. Le Metodologie moderne sono talvolta complesse. C è una forte entropia sull argomento, perchè gli interessati si informano unicamente sul web. C è una diffusa ingenuità ed ignoranza sull argomento. A. Martinelli Modelli di Sviluppo 10/12/ / 29

7 Modelli di Sviluppo del Software Le Fasi dello Sviluppo Ogni Modello di Sviluppo ha come obiettivo quello di pianificare lo Sviluppo in fasi ben determinate Ogni fase avrà obiettivi specifici e farà uso di strumenti differenti. Il coordinamento delle fasi deve consentire di raggiungere l obiettivo finale che è la realizzazione di un progetto. Fasi tipiche dello sviluppo : Definizione dei Requisiti Analisi Codifica Validazione (Testing/Debugging) Rilascio A. Martinelli Modelli di Sviluppo 10/12/ / 29

8 Il Modello a Cascata Il Waterfall Model (Modello a Cascata) Il Modello a Cascata definisce un elenco di attività che devono essere svolte in sequenza. Il concetto di Modello a Cascata può essere applicato a differenti tipologie di Cascate. Il modello originale prevedeva questi passi: Definizione delle Specifiche Progettazione Implementazione Integrazione (con i dispositivi e gli altri sistemi con cui il progetto si deve integrare) Validazione: Testing(per verificare l esistenza di errori) e Debugging (per rimuove gli errori). Installazione. Manutenzione. A. Martinelli Modelli di Sviluppo 10/12/ / 29

9 Il Modello a Cascata Il Waterfall Model (Modello a Cascata) Specifiche Progetto Implementazione Verifica Manutenzione A. Martinelli Modelli di Sviluppo 10/12/ / 29

10 Il Modello a Cascata Il Waterfall Model : Difetti La fase di definizione delle Specifiche è Definita una volta per tutte. Questo rende impossibile rivedere le specifiche qualora durante lo sviluppo si presentassero delle complicazioni. La fase di progettazione avviene prima di tutto lo sviluppo; anche in questo caso è impossibile tornare sui propri passi qualora le cose non andassero come si deve La fase di Manutenzione è particolarmente critica. Il progetto è chiuso. Qualsiasi esigenza aggiuntiva diventa difficile da soddisfare in un secondo momento. A. Martinelli Modelli di Sviluppo 10/12/ / 29

11 Il Modello a Spirale Le critiche al Modello a Cascata suggeriscono un l uso di un Modello che consenta di tornare sui propri passi. Il Modello a Spirale complica quello a cascata con le seguenti considerazioni: Definito l elenco di specifiche e di funzionalità di un prodotto, gli sviluppatori selezionano alcuni obiettivi iniziali. Il processo di sviluppo, che qui è detto ciclo, prevede questi step: Definizione Specifiche Valutazione dei rischi legati allo sviluppo Implementazione Validazione (Testing-Debugging) Terminato il processo di Validazione, vengono considerati nuovi obiettivi e nuovi requisiti e si ricomincia da capo. Il Modello è a Spirale perchè ad ogni ciclo di sviluppo si produce una nuova versione del progetto, di dimensione crescente. Soprattutto nella fase iniziale, le versioni sono dette Prototipi, ed il processo di selezione dei requisiti nelle prime fasi viene detto Prototipazione. A. Martinelli Modelli di Sviluppo 10/12/ / 29

12 Il Modello a Spirale 3 4 Implementazione Validazione Rilascio Prototipo 2 Valutazione Rischi Requisiti 1 A. Martinelli Modelli di Sviluppo 10/12/ / 29

13 Il Modello a Spirale Il Modello a Spirale è in genere vantaggioso perchè consente di descrivere un processo un poco per volta. La fase di valutazione dei rischi rende più robusta la gestione del progetto La progettazione a piccoli passi consente di valutare più rapidamente eventuali difficoltà di sviluppo. Lo sviluppo un poco alla volta rende anche più facili le fasi di testing e debugging: E più facile definire test adeguati. E più facile trovare gli errori se si è modificato meno codice. A. Martinelli Modelli di Sviluppo 10/12/ / 29

14 Sviluppo Incrementale ed Iterativo Col Modello a Spirale spesso si introducono il concetto di Sviluppo Incrementale ed Iterativo. Sviluppo Iterativo Quando lo sviluppo segue delle iterazioni, ovvero è ciclico. Sviluppo Incrementale Quando lo sviluppo si basa su specifiche che vengono definite un po alla volta. I clienti/commissionanti od utenti possono giocare un ruolo fondamentale. In tutti i casi l uso dello Sviluppo Incrementale ed Iterativo favorisce lo sviluppo dei Prototipi che possono essere rilasciati al commissionante. Questo consente al commissionante di Rivalutare le specifiche, diventando parte integrande e fondamentale del processo di Sviluppo. A. Martinelli Modelli di Sviluppo 10/12/ / 29

15 Sviluppo Incrementale ed Iterativo Requirements, Testing Analisi, Design Implementation Initial Planning Deployment Evaluation Testing I Rilasci (Deployment) diventano un elemento fondamentale perchè consentono all utente finale di avere una valutazione in corso d opera del lavoro svolto. A. Martinelli Modelli di Sviluppo 10/12/ / 29

16 I Modelli Evolutivi e l Agile Software Development Modelli Evolutivi L Agile Software Development (in italiano si usa l espressione Metodologie Agili) rientra nei cosidetti Modelli Evolutivi, che si fondano sull idea centrale di coinvolgere il cliente o l utente, fornendogli continue nuove versioni in modo che possa essere partecipe nello sviluppo del progetto. L Obiettivo principale dell Agile Software Development è rendere il cliente il più soddisfatto possibile. Inoltre, si cerca di sostituire il modello di ciclo fisso, con qualcosa di più elastico e dinamico. A. Martinelli Modelli di Sviluppo 10/12/ / 29

17 Dal Manifesto dell Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work 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 plan That is, while there is value in the items on the right, we value the items on the left more. A. Martinelli Modelli di Sviluppo 10/12/ / 29

18 Dal Manifesto dell Agile Software Development Individuals and interactions Le Persone e le loro relazioni sono molto più importanti della strumentazione tecnica o degli strumenti che vengono utilizzati per produrre software. Working software E inutile realizzare del software difficile da utilizzare o poco comprensibile da capire e poi fornire tonnellate di documentazione. E molto meglio scrivere codice facile da capire e da usare. Nell Agile Software Development il cliente diventa un elemento partecipe del progetto e le considerazioni di cui sopra lo coinvolgono. Customer collaboration La partecipazione del cliente o del committente al progetto, aumenta la probabilità che sia soddisfatto del lavoro che viene svolto. La partecipazione avviene effettuando continui rilasci e dando quindi la possibilità al cliente di vedere il proprio progetto crescere. A. Martinelli Modelli di Sviluppo 10/12/ / 29

19 Responding to change (Operare per il cambiamento) Cambiamento Tutti i sistemi cambiano e si evolvono nel tempo. I Clienti partecipano e contribuiscono con nuove idee, o propongono nuove caratteristiche. I cambiamenti in corso d opera rendono la manutenzione del Software difficile. Come deve avvenire la Progettazione per tenere conto del Cambiamento? A. Martinelli Modelli di Sviluppo 10/12/ / 29

20 Responding to change : Progettazione Agile La Progettazione Agile non avviene in un momento ben definito. Avviene continuamente, tutte le volte che nel codice si verifica uno dei seguenti problemi. Cambiamento Rigidità: il sistema è difficile da cambiare Fragilità: le modifiche causano malfunzionamenti Immobilità: i sorgenti sono difficili da riutilizzare Viscosità: i cambiamenti compatibili con l architettura sono difficili da realizzare Complessità inutile: il sistema è più complicato del necessario Ripetizioni inutili: i sorgenti contengono codice simile Opacità: la funzione dei moduli non è facilmente comprensibile Nello Sviluppo Agile non si fa mai progettazione, ma si fa piuttosto Riprogettazione (Refactoring) A. Martinelli Modelli di Sviluppo 10/12/ / 29

21 Responding to Change : Modularità Fin dall inizio della storia della programmazione si è cercato di definire il concetto di Modularità Modularità Lo studio di metodologie agili ha contribuito a migliorare il concetto di Modularità, soprattutto per quanto riguarda la programmazione ad oggetti Il Refactoring aiuta ad ottenere moduli con una elevata Coesione ed un Basso livello di Accoppiamento, e a definire astrazioni, in modo da rende gli oggetti più riciclabili. E l Agile Software Development che ha introdotto i principi SOLID, oggigiorno considerati principi generali di una buona programmazione ad oggetti. Perché è fondamentale nell Agile Software Development rispondere ai cambiamenti di specifiche: Se i moduli sono coesi, sono tanti e piccoli ed è più facile fare le modifiche solo dove occorre. Se i moduli sono disaccoppiati, le modifiche non si propagheranno nel codice. I principi SOLID aiutano a mantenere alta la Coesione e basso l Accoppiamento. A. Martinelli Modelli di Sviluppo 10/12/ / 29

22 Extreme Programming (XP) (1/4) Formulato da Kent Beck, Ward Cunningham e Ron Jeffries intorno al 1999, Istituisce su una serie di pratiche per lo Sviluppo Agile: Pair Programming Planning Game Test-Driven Development Whole-Team Continuous Integration Refactoring o Design Improvement Small Releases Coding Standards Collective Code Ownership Symple Design System Metaphor Sustainable Pace A. Martinelli Modelli di Sviluppo 10/12/ / 29

23 Extreme Programming (XP) (2/4) Pair Programming Due Programmatori lavorano allo sviluppo del codice. Questa pratica ha lo svantaggio di aumentare i tempi di sviluppo, ma diminuisce la probabilità che durante lo sviluppo vengano fatti errori. Planning Game La Pianificazione non avviene una volta per tutte, ma avviene continuamente e sulla base di interventi anche del cliente, un po come in un gioco dove il cliente fa la prima mossa, il programmatore lo segue e così via fino a progetto realizzato Test-Driven Development I Test vengono realizzati prima ancora di scrivere codice. Questa prassi ha l enorme vantaggio di aiutare a capire come devono essere sviluppate certe cose, oltre a fornire una base stabile per le fasi di debugging. Whole-Team L Utente finale del sistema DEVE contribuire ed essere parte integrante dello sviluppo, la sua opinione conta più di ogni altra idea su come il progetto debba andare avanti. A. Martinelli Modelli di Sviluppo 10/12/ / 29

24 Extreme Programming (XP) (3/4) Continuous Integration I cambiamenti vengono integrati continuamente nel codice, e mai rimandati ad una successiva fase di progettazione. Refactoring La riscrittura del codice che non cambia la funzionalità del programma, è usata perchè rende il codice più snello, generale e quindi più semplice da integrare e riutilizzare nel tempo. Small Releases Continue consegne rendono il cliente e l utente sia più responsabile del lavoro che viene svolto, sia più fiducioso. Coding Standards Il codice dovrebbe sempre seguire delle regole standard definite fin dall inizio del progetto A. Martinelli Modelli di Sviluppo 10/12/ / 29

25 Extreme Programming (XP) (4/4) Collective Code Ownership Tutti sono responsabili di tutto. Il codice è condiviso ed appartiene a tutti. Symple Design Nella progettazione, le soluzioni più semplici dovrebbero essere sempre le migliori System Metaphor Usare delle metafore su come il sistema funziona. Le Metafore possono essere viste come storie (Users Stories) che forniscono informazioni sul sistema, ma che dovrebbero farlo in modo più semplice da capire per tutti. Sustainable Peace Non fare straordinare, non eccedere, fare pause. I programmatori quando sono freschi e riposati fanno meno errori... A. Martinelli Modelli di Sviluppo 10/12/ / 29

26 Un tipico ciclo di sviluppo nell Extreme Programming Stima rilascio Iterazione con l'utente iterazione Acceptance Test ogni giorno Pianifica Rilascio Pianifica Iterazione Test Driven Development continuamente Implementazione Refactoring Integrazione Working Software A. Martinelli Modelli di Sviluppo 10/12/ / 29

27 Il Rilascio del Software Rilascio (Deployment) Con rilascio si intende la generazione di una versione che viene messa a disposizione degli utenti finali. Lo Sviluppo Incrementale ed Iterativo e l Extreme Programming prevedono un meccanismo a rilasci continui che consente l interazione con l Utente Finale L utente finale diventa partecipe allo sviluppo del software Ma chi sono gli utenti? Nei software commerciali o comunque pensati per il grande pubblico, gli sviluppatori con chi dovrebbero andare a parlare? A. Martinelli Modelli di Sviluppo 10/12/ / 29

28 Il Rilascio del Software: le Versioni Il Deployment genera Versioni. Quando l Utente è un commissionante, o comunque una persona fisica Si usa il termine Milestone per indicare un insieme di specifiche ed una data entro cui devono essere raggiunte. Fornitore e commissionante si accordano sulle Milestone valide, e prevedono un rilascio a testimonianza di ogni Milestone. Quando l Utente è un gruppo e non c è una persona fisica a cui rivolgersi Una possibilità è pagare o coinvolgere degli utenti tipo per contribuire allo sviluppo. L avvento di internet ha tuttavia stravolto il modo in cui certi progetti vengono seguiti. I Deployement vengono fatti in rete. Gli utenti possono contribuire attraverso sistemi con chat e dibattiti in rete. A. Martinelli Modelli di Sviluppo 10/12/ / 29

29 Il Rilascio del Software: Tipologie di Rilascio La pratica di rilasciare versioni in rete ha contribuito alla nascita di una terminologia per la classificazione dei rilasci: Pre-Alpha Una versione Pre-Alpha è una versione esemplificativa delle funzionalità che il programma potrebbe avere. Alpha Una versione Alpha è una versione del programma non completa, ma con alcune cose funzionanti Beta Una versione Beta è una versione di Test. Le versioni Beta dovrebbero avere tutte o quasi tutte le funzionalità già implementate. Versione Candidata per il rilascio (talvolta Gamma o Delta) Una Versione che si suppone essere definitiva. E tuttavia noto che questi termini sono spesso usati in modo approssimativo. A. Martinelli Modelli di Sviluppo 10/12/ / 29