La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software

Transcript

1 Ingegneria del software (software engineering) La branca dell'ingegneria che si occupa della realizzazione di sistemi software. La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software Esplode a partire dagli anni 70, laddove per la crescente integrazione del supporto informatico nel contesto sociale e per lo sviluppo delle tecnologie hardware si avverte fortemente l esigenza di sviluppare prodotti software sempre più complessi ed evoluti Tipologia dei prodotti software Prodotti generici Sistemi stand-alone prodotti da aziende di sofware ed immessi sul libero mercato Prodotti personalizzati Sistemi commissionati per specifiche esigenze di utente (es. un sistema bancario) Complessità di capire, descrivere ed implementare le funzionalità richieste. Aumento dei costi di produzione

2 Obiettivi Legati all'evoluzione dello sviluppo del software (inteso come attività industriale) dai punti di vista: tecnologico (es. attraverso la definizione di nuovi linguaggi di programmazione) metodologico (es. la generazione ed il perfezionamento di modelli di sviluppo del software) identificando una formalizzazione del processo di realizzazione di un prodotto software dalla fase di concepimento fino alla sua morte funzionale.

3 Le caratteristiche di un prodotto software installato ed in uso sono essenzialmente riconducibili : Manutenibilità Faciltà di modifica per soddisfare nuovi requisiti Affidabilità In caso di malfunzionamento il software non deve produrre danni, ovvero elevata regolarità di funzionamento e protezioni per gestiore in sicurezza l evento malfunzionmento Efficienza Il software non deve fare un uso indiscriminato di memoria e di tempo di calcolo Faciltà di utilizzo Corredato da una interfaccia di utente semplice, snella e compatta nonché da appropriata documentazione

4 Ciclo di vita di un software Un concetto che ha assunto negli ultimi decenni un'importanza sempre più elevata, spostando l'idea di software dalla genericità di manufatto verso un'idea di vero e proprio prodotto industriale. Qualunque industria manifatturiera nel suo ciclo produttivo utilizza un modello al fine di: -pianificare le attività e le risorse necessarie -prevedere e controllare tempi e costi del processo e la qualità del prodotto L 'ingegneria del software, nell ottica di questa esigenza, cerca di definire Modelli che permettano a team di tecnici di realizzare in cooperazione prodotti sempre più evoluti. Allo scopo definisce una sequenze di fasi che individuano tappe specifiche nella realizzazione di un prodotto software

5 Alla fine degli anni 60: con la crescente implementazione del supporto informatico nel contesto sociale sorgeva forte l'esigenza di sviluppare prodotti sempre più complessi ed evoluti che rispondessero alle richieste delle grandi utenze. Nell antecedente temporale agli anni 60 lo sviluppo del software era prettamente a produzione personale. Gli informatici erano pochi ed isolati, con produzione alquanto limitata del software Molti programmi erano sviluppati tipicamente per applicazioni di tipo locale. Ciò che veniva sviluppato era pensato per un unico cliente e ad ogni progetto lavorava quasi sempre una sola persona che produceva un prodotto senza scrivere alcuna documentazione il che ne limitava fortemente l utilizzo nel tempo Soprattutto in riferimento alla manutenzione ed ad eventuali attività di ampliamento

6 L innovazione negli anni 60 nel settore della progettazione del SW si caratterizza tramite la metodolgia della programmazione strutturata che rivolge una forte critica dell utilizzo della struttura di controllo del salto condizionato (goto, "vai a"), di largo utilizzo nella produzione software degli anni '60 (approccio code and fix, programmazione per tentativi ed errori) quale strumento fondamentale per la definizione e manutenzione di algoritmi complessi. In un celebre articolo del 1968, Goto statement considered harmful, Edsger Dijkstra discusse approfonditamente gli effetti deleteri del goto sulla qualità del software, e in particolare sulla leggibilità e modificabilità del sw (il cosiddetto problema del codice simile a piatti di spaghetti). L affermazione della programmazione strutturata trovò ulteriore supporto nella pubblicazione Flow Diagrams, Turing Machines, and Languages with Only Two Formation Rules, in cui Corrado Böhm e Giuseppe Jacopini dimostrarono che, sulla base di tre soli tipi di strutture di controllo: sequenza, iterazione e alternativa ritenute fondamentali qualsiasi programma scritto utilizzando la struttura goto poteva essere riscritto senza utilizzarla

7 Nella realizzazione di un prodotto software è importante svolgere una serie di passi, ovvero una sorta di percorso (processo software o ciclo di vita ) che aiuti ad ottenere risultati di alta qualità anche in considerazione di tempi stimati. Tale percorso si riferisce al modo in cui una metodologia di Sviluppo scompone l'attività di realizzazione di prodotti sw in sottoattività (moduli) fra loro coordinate, il cui risultato finale è il prodotto stesso e tutta la documentazione a esso associato Tale processo si configura essenzialmente in -Attività portanti: una serie di compiti da svolgere necessariamente; -Attività ausiliarie: finalizzate essenzialmente ad aumentare la qualità del software Il ciclo di vita di un prodotto software si basa su dei modelli

8 Modello a cascata (waterfall model) Il primo modello utilizzato Per tale modello la realizzazione di un prodotto software consta di una sequenza di fasi strutturata in:. Analisi Analisi fattibilità Analisi Analisi requisiti Codifica e testing testing Integrazion e e testing testing Manutenzione Rilascio Ciascuna di queste fasi produce un ben preciso output utilizzato poi come input per la fase successiva (da cui la metafora della cascata). Ogni fase del processo viene documentata.

9 Analisi di fattibilità: Finalizzata, tramite una forte interazione con l utente e comprensione del dominio applicativo (scuola,banca,..), a catturare i requisiti del committente (cosa deve fare l applicazione) ovvero capire cosa vuole il cliente e come ottenerlo Ha lo scopo di determinare se vale la pena da un punto di vista tecnico ed economico di realizzare il sistema del quale si andranno a definire i requisiti. E essenzialmente una valutazione preliminare atta a determinare il rapporto costi/benefici della produzione del sistema secondo le esigenze del committente, individuando le soluzioni possibili e le alternative, i costi in termini di risorse finanziare ed umane per le varie soluzioni. L atto finale è una documentazione denominata studio di fattibilità che giustifichi il go o la end del processo.

10 Analisi dei requisiti Determinazione di cosa dovrà fare il sistema (indipendentemente da come farlo (what<>how) ovvero l identificazione e la descrizione dei requisiti funzionali richiesti e dei vincoli esistenti (es. specifiche operazioni che il sistema non deve fare) Genera una prima suddivisione in moduli (disegno documentato dell architettura del software) con la individuazione delle relazioni esistenti fra di essi. Ogni modulo dovrà realizzare una funzionalità logica autosufficiente nel sistema complessivo. Risultato di questa fase è un documento di specifica dei requisiti che dovendo avere l avvallo del committente e dovendo essere usato da chi (single o team) svilupperà il sistema dovrà possedere requisiti di completezza, precisione e comprensibilità.

11 Al fine di poter verificare, in fase di testing, il soddisfacimento dei requisiti di utente, come atto finale integrativo della fase di analisi dei requisiti viene prodotto un ulteriore documento detto piano di test del sistema. Codifica, o sviluppo dei moduli: I moduli sono codificati tramite un linguaggio di programmazione e con metodi di programmazione strutturata quali ad esempio la tecnica top-down o dei raffinamenti successivi. In questa fase per ogni modulo viene definito l associato piano di prove Testing (o test di modulo): esecuzione di prove per verificare il funzionamento dei singoli moduli

12 Integrazione dei moduli I vari moduli vengono integrati nel rispetto della sequenza logica del progetto e si procede al test di integrazione, ovvero alla esecuzione di prove per verificare la correttezza del funzionamento complessivo del sistema (alpha test) Rilascio del sistema o delivery Il software viene consegnato all utenza (generalmente una utenza ridotta e selezionata) per una verifica del sistema nelle condizioni reali (versione Beta) per risoluzione di eventuali problemi non considerati nella analisi dei requisiti. L atto finale è la distribuzione a tutta l utenza.

13 Manutenzione Tutto ciò che accade dal momento della consegna del sistema alla sua dismissione Comprende tutte le attività volte a migliorare, estendere e correggere il sistema nel tempo. Si caratterizzano essenzialmente attività di: Manutenzione correttiva: Correzione di errori residui presenti nel sistema ed individuati nel tempo Manutenzione adattiva: Modifica del sistema, se possibile, per adattarlo a nuove sopravvenute esigenze dell utenza Manutenzione percettiva: Tese a migliorare le prestazioni del sistema in termini di qualità

14 Il modello a cascata si attesta sulle prerogative: Il processo di sviluppo del software è soggetto a sequenzialità e pianificazione delle fasi L implementazione del prodotto è prevista solo quando sono perfettamente chiari gli obiettivi (di estrema importanza le fasi di analisi dei requisiti e disegno dell architettura del sistema) Queste prerogative,soprattutto in progetti di grandi dimensioni non sempre vengono rispettate ed è facile il generarsi di scollamento fra i team preposti alle diverse attività

15 Spesso: si anticipa la fase di codifica rispetto alla terminazione della fase analisi requisiti c è cattiva comunicazione o interpretazione fra utente ed analista il che inficia i risultati della fase di analisi con ripercussioni sulle fasi successive nell arco temporale di produzione del software,che può anche essere abbastanza lungo, sorgono delle esigenze necessarie e non previste nella primordiale fase di analisi spesso si hanno cicli di feedback (il caso dell alpha e del beta testing) per la correzione degli errori. Tale feedback, purtroppo, deve essere lineare e, quindi, non si possono effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera lineare Ne consegue che il modello a cascata, per la sua rigidezza, (una fase non inizia se non totalmente terminata la fase precedente) può implicare una elevata attività manutentiva che comporta forte aumento dei costi di sviluppo previsti e generazione di un prodotto non corrispondente ai requisiti di qualità previsti nella fase iniziale di analisi.

16 Modello prototipale Molto spesso, con il fallimento della prima versione software, si rende necessario e conveniente rifare in toto l applicazione. In tale modello si utilizza la prima versione come un throw-away (un prototipo "cestinabile") che viene utilizzata temporaneamente dall utenza con conseguente valutazione ed individuazione di carenze o omissione di requisiti. Il prototipo viene distrutto e si procede a produrre ex novo l'applicazione, utilizzando ancora il modello a cascata, sulla base delle informazioni avute dall utilizzo del prototipo Interazione con il committente Realizzazione/modifica prototipo Test prototipo con il committente

17 Il modello prototipale, se da una parte coinvolge maggiormente il committente nella definizione delle specifiche, riducendo fortemente le incomprensioni sulla definizione delle specifiche, dall altra, sulla inconsistenza di un valida fase di analisi iniziale può comportare enorme spreco di risorse (generazione di diversi prototipi) Può accadere di accettare come prodotto finale una versione ancora prototipale

18 Modello incrementale Il processo di sviluppo del software è vincolato al modello a cascata fino alla fase del disegno dell intera applicazione Questo comporta che: nella fase di analisi vanno individuati: -i sottosistemi (moduli) -come si interfacciano Ogni incremento di sottosistema deve prevedere: -codifica e testing del corrispondente modulo -integrazione fra moduli esistenti -collaudo del sistema allo stato dell arte Vantaggio del modello è che il committente,potendo intervenire in valutazione sulla parte sviluppata, potrà richiedere modifiche ai requisiti sulle parti ancora da incrementare. Inoltre saranno possibile interventi di manutenzione diretta sull ultimo modulo incrementato

19 Un esempio di sviluppo mediante modello incrementale: un editor di testi Vers1 Vers2 Vers3 Gestione file, editing, stampa documenti Gestione file, editing, stampa documenti,correttore ortografico Gestione file, editing, stampa documenti, correttore ortografico formattazione pagina Altri modelli Modello basato sulle trasformazioni Modello a spirale