Riassunto esame Ingegneria del software, Prof. De Lucia Andrea, libro consigliato Object Oriented Software Engineering, Bernd Bruegge

Ingegneria del software: metodi e tecniche

Capitolo 1 - Introduzione

1.1 Software

Le economie di tutti i paesi sviluppati sono dipendenti dal software, che rappresenta una delle voci rilevanti del PIL di questi paesi e, ogni giorno, un numero sempre più alto di sistemi contengono software o dipendono da esso. La sua evoluzione è avvenuta attraverso varie fasi. Si è partiti da una fase di Arte, durante la quale le applicazioni venivano sviluppate da singole persone e utilizzate dagli stessi sviluppatori, per passare a una fase di Artigianato, durante la quale le applicazioni venivano sviluppate da piccoli gruppi specializzati per un cliente. Tuttavia, i costi per tenere una propria unità informatica erano troppo alti e si è giunti così alla fase di Industria: il software è diffuso in diversi settori, sono cresciute le dimensioni, la complessità e la criticità delle applicazioni, si è sviluppato un vero e proprio mercato con relativa concorrenza, è nata la necessità di migliorare la produttività e la qualità, i progetti vengono gestiti e il software è in continua evoluzione. Insomma, oggi, il software è ovunque!

Una prima distinzione su cui prestare attenzione è quella tra programma e prodotto software. Per un programma, l’autore è anche l’utente, non è documentato, quasi mai è testato e non c’è progetto. In altre parole non serve un approccio formale al suo sviluppo. Un prodotto software, invece, è usato da persone diverse da chi lo ha sviluppato. Si tratta di un prodotto industriale, il cui costo è circa 10 volte il costo del corrispondente programma e, ovviamente, richiede un approccio formale allo sviluppo. Questi prodotti si possono dividere in due categorie:

• Prodotti generici: sistemi stand-alone prodotti da una organizzazione e venduti a un mercato di massa. Sono quelli meno costosi perché la spesa per lo sviluppo è ammortata nel tempo (ad esempio, Microsoft Office).
• Prodotti specifici: sistemi commissionati da uno specifico utente e sviluppati specificatamente per quest’ultimo da un qualche contraente.

La fetta maggiore della spesa mondiale è nei prodotti generici, ma il maggior sforzo di sviluppo è chiaramente nei prodotti specifici.

Di seguito sono riportate varie definizioni formali del termine Software:

• Dizionario della lingua italiana (Devoto, Oli - 1971): Software: il corredo dei linguaggi e dei programmi di cui è munito un sistema elettronico per l’elaborazione dei dati.
• Learner’s Dictionary Oxford Advanced (1992): Software: dati, programmi, e tutto ciò che non è parte di un computer ma usato quando si lavora con quest’ultimo.
• Standard IEEE (Institute of Electrical and Electronics Engineers) 610.12-1990: Software: l’insieme dei programmi, delle procedure ed eventuali documentazioni allegate, e dei dati pertinenti le operazioni di un sistema computerizzato.

Quindi, si intende l’insieme completo dei programmi, delle procedure con eventuali documentazioni allegate e dei dati progettati dagli sviluppatori per un utente e tutto ciò che viene rilasciato a quest’ultimo.

In altre parole, il software non è solo il codice, ma tutti gli “artefatti” che lo accompagnano e che sono prodotti durante l’intero processo di sviluppo: codice, documentazione, casi di test, specifiche di progetto, procedure di gestione, manuali utente…

Data la sua natura, il software è completamente diverso da ogni altro prodotto industriale classico e, in generale, di ingegneria: è intangibile, malleabile, ad alta intensità di lavoro umano, spesso costruito ad hoc, invece che assemblato, e manutenzione significa cambiamento.

Durante il processo evolutivo del software, sono stati sfatati molti miti:

• Management: “Con computer potenti e moderni risolviamo tutti i problemi”. “Se siamo in ritardo possiamo recuperare aumentando il numero di programmatori”.
• Cliente: “Un’affermazione generica degli scopi è sufficiente per cominciare a scrivere programmi”. “I mutamenti nei requisiti di un progetto si gestiscono facilmente grazie alla flessibilità del software”.
• Programmatore: “Una volta messo in opera il programma, il lavoro è finito”. “Il solo prodotto di un progetto concluso è il programma”.

Queste affermazioni, oggi, sono ritenute tutte errate.

1.2 Ingegneria del Software

I problemi che si possono incontrare nella produzione del software dipendono da vari fattori: costi, ritardi e abbandoni, affidabilità.

Costi

Il software ha costi elevati! Principalmente si tratta dei costi, espressi in mesi/uomo, delle risorse umane: ore lavoro o manpower (il più dominante), hardware, software e risorse di supporto. Anche il testing influisce su questi costi, impiegandone fino al 50%, si preferisce infatti non ritardarlo, perché alla fine costa sempre di più. Inoltre la manutenzione costa più dello sviluppo: per sistemi che rimangono a lungo in esercizio i costi di manutenzione possono essere svariate volte il costo di produzione! In genere, la produttività media è da 300 a 1000 linee di codice rilasciate per mese/uomo. Nello scenario attuale, se un’azienda tiene una persona a lavorare per un anno (anno/uomo), al cliente costa $100.000, cioè $8.000 per mese/uomo. Un cliente, infatti, paga da $8 a $25 per linea di codice rilasciata e per un prodotto di dimensioni medio-piccole (circa 50.000 linee di codice) da $500.000 a $1.250.000. E la manutenzione è ancora più gravosa: se una linea di codice costa $25, al cliente, un intervento su una linea di codice in manutenzione può costare fino a $1.000!

Ritardi e abbandoni

Si possono verificare ritardi e abbandoni (“runaway project”) nelle consegne, con conseguente aumenti dei costi. Eccone alcuni esempi:

• Il progetto di un sistema di comando e controllo per la US Air Force fu stimato dalla azienda vincitrice per la fornitura intorno ai $400.000, costo rinegoziato successivamente a $700.000, poi a $2.500.000 e infine a $3.200.000. In altre parole, il costo finale divenne maggiore di circa 10 volte la stima iniziale e con un notevole ritardo rispetto alla stessa stima! (Da un report del 1981).
• Una azienda nel settore della grande distribuzione di prodotti aveva richiesto un sistema che, stima iniziale, sarebbe stato sviluppato in 9 mesi al prezzo di $250.000 (da un report del 1989). Due anni dopo, e dopo una spesa di $2.500.000, il lavoro non era stato ancora completato e fu stimato che erano necessari altri $3.600.000!! Risultato: il progetto fu abbandonato!

Affidabilità

Il software è spesso inaffidabile e molti malfunzionamenti sono rilevati durante l’operatività del sistema. Da un’analisi del ministero della difesa USA risulta che più del 70% di tutti i malfunzionamenti in sistemi con complicati e sofisticati apparati meccanici, elettrici, idraulici, etc., sono dovuti al software (vedi l’Arianne 5 e la sonda MARINER).

Da queste considerazioni nasce la necessità di un approccio ingegneristico alla produzione software, per poter sviluppare il giusto prodotto, al giusto costo, nel tempo giusto e con la giusta qualità. Lo scopo dell’Ingegneria del Software riguarda la costruzione di software di grandi dimensioni, di notevole complessità e sviluppati tramite lavoro di gruppo. Progetti software di questo tipo hanno tipicamente versioni multiple, una lunga durata e frequenti cambiamenti volti ad eliminare difetti, ad adattare il prodotto a nuovi ambienti e volti a introdurre miglioramenti e nuove funzionalità. Uno dei “guru” dell’Ingegneria del software, Parnas, ne ha dato la seguente definizione: “Costruzione multi-persona di software multi-versione”.

Uno degli obiettivi fondamentali dell’Ingegneria del Software è quello di contestualizzare il software. Infatti, la maggior parte del SW è collocata all’interno di un “sistema” misto HW/SW e l’obiettivo finale di chi produce è creare tale sistema in maniera da soddisfare globalmente i requisiti dell’utente. Da qui segue il coinvolgimento nella definizione dei requisiti del sistema. È quindi essenziale la conoscenza del dominio applicativo per un efficace sviluppo del SW, perché lo stesso è utile solo se riesce a condensare nei suoi algoritmi la conoscenza di tale dominio applicativo. Contrariamente, invece, il SW potrebbe essere inutile o dannoso (ad esempio, il sistema di controllo di un aeroplano).

Sono state date varie definizioni formali di Ingegneria del Software:

• Da “Standard Glossary of Software Engineering Terminology” (1993) dell’IEEE (Institute of Electrical and Electronics Engineers): Applicazione di una strategia sistematica, disciplinata e misurabile allo sviluppo, esercizio e manutenzione del software (programmi, procedure, regole e associata documentazione, dati).
• La disciplina tecnologica e manageriale che riguarda la produzione sistematica e la manutenzione dei prodotti software che vengono sviluppati e modificati entro i tempi e i costi preventivati (D. Farley).

In generale, l’ingegneria del software si occupa dei metodi, delle metodologie, dei processi e degli strumenti per la gestione professionale (sviluppo, manutenzione, ritiro) del software. Si basa su Principi, quali:

• Rigore: concetto primitivo (precisione, accuratezza).
• Formalità: oltre il rigore (fondamento matematico).
• Separazione di aspetti diversi: affrontare separatamente i vari lati di un problema complesso.
• Modularità: suddividere un sistema complesso in parti più semplici.
• Astrazione: si identificano gli aspetti cruciali in un certo istante, ignorando gli altri.
• Anticipazione del cambiamento: la progettazione deve favorire l’evoluzione del SW.
• Generalità: tentare di risolvere il problema nella sua accezione più generale.
• Incrementalità: lavorare per passi successivi.

Metodo (o tecnica): procedimento generale per risolvere classi di problemi specificati di volta in volta (linee guida o regole che governano le attività; il metodo dei minimi quadrati, il metodo di Montecarlo, il metodo di Newton, come fare il brodo di carne, come fare il lesso, ...).

Metodologia: insieme di principi, metodi ed elementi di cui una o più discipline si servono per garantire la correttezza e l’efficacia del proprio procedere (ad esempio la metodologia della macerazione carbonica permette di ottenere vini novelli, freschi, profumati, …).

Strumento (tool): un artefatto, un sistema per fare qualcosa in modo migliore (ad esempio, il frullatore per fare la maionese, un cavatappi per aprire una bottiglia), insomma, un supporto SW pratico all’applicazione.

Procedura: una combinazione di strumenti e metodi che, assieme, permettono di produrre un certo prodotto (ad esempio, la ricetta della Saker Torte: montare a neve le chiare di 4 uova ...).

Paradigma: un particolare approccio o filosofia per fare qualcosa (ad esempio, lo stile della cucina, cucina Francese, quella Italiana, quella Cinese, …).

Anche il processo ha definizioni diverse:

• Un processo è un particolare metodo per fare qualcosa costituito da una sequenza di passi che coinvolgono attività, vincoli e risorse (Pfleeger).
• Un processo è una particolare metodologia operativa che nella tecnica definisce le singole operazioni fondamentali per ottenere un prodotto industriale (Zingarelli).

Ma che cosa è un processo software? Un metodo per sviluppare del software (Sommerville). In generale, un processo software è un insieme organizzato di attività che sovrintendono alla costruzione del prodotto da parte del team di sviluppo, utilizzando metodi, processi, metodologie e strumenti. È suddiviso in varie fasi secondo uno schema di riferimento (il ciclo di vita del software), ed è descritto da un modello: informale, semi-formale o formale (maturità del processo).

Lo Standard IEEE 610.12-1990 definisce il Processo di sviluppo del software come “il processo mediante il quale le richieste dell’utente vengono tradotte in un prodotto software. Il processo include traduzione delle richieste dell’utente in requisiti software, trasformazione dei requisiti software in progetto, implementazione del progetto in codice, testing del codice, e a volte, installazione e collaudo del software per la messa in esercizio. Queste attività possono sovrapporsi o essere eseguite iterativamente. Esistono alcuni Cicli di vita del software (CVS) che permettono di definire la modalità di sviluppo di un software: sviluppo incrementale, prototipazione rapida, modello a spirale, modello a cascata”.

Secondo B. Boehm i Progetti possono essere suddivisi in classi:

In uno scenario del genere, le necessità del Project Management sono: project planning (definire attività, risorse da allocare, tempi), project monitoring e controllo, metriche di prodotto e di processo per misurare e controllare...

A tali scopi esistono sistemi software che forniscono un supporto automatico per le attività di un processo software, detti CASE (Computer-Aided Software Engineering). Si dividono in:

• Upper-CASE: Strumenti che supportano le attività delle fasi di analisi e specifica dei requisiti e progettazione di un processo software. Includono editor grafici per sviluppare modelli di sistema e dizionari dei dati per gestire entità del progetto.
• Lower-CASE: Strumenti che supportano le attività delle fasi finali del processo, come programming, testing e debugging. Includono generatori di GUI per la costruzione di interfacce utente, debuggers per supportare la ricerca di program fault e traduttori automatici per generare nuove versioni di un programma.

Capitolo 2 - Ciclo di vita del software

2.1 Overview

Secondo lo Standard IEEE 610.12-1990, il ciclo di vita del software è il periodo di tempo che inizia quando il software viene concepito e termina quando il prodotto non è più disponibile per l’uso. Tipicamente, include le fasi di concepimento, requisiti, progetto, implementazione, test, installazione e collaudo, una fase operativa e di manutenzione, e a volte, una fase di ritiro. Queste fasi possono sovrapporsi o essere eseguite iterativamente.

Questo concetto è differente da quello di Ciclo di Sviluppo del Software poiché rappresenta il periodo di tempo che inizia con la decisione di sviluppare un prodotto software e termina quando il prodotto è completato. Questo ciclo, tipicamente, include le fasi di requisiti, progetto, implementazione, test, e a volte, una fase di installazione e collaudo. Queste fasi possono sovrapporsi o essere eseguite iterativamente, a seconda dell’approccio scelto per lo sviluppo. Inoltre, questo termine è a volte usato sia per indicare un lungo periodo di tempo, sia per indicare il periodo che termina quando il software non subisce più variazioni da molto, oppure per indicare l’intero ciclo di vita del software.

Un modello del Ciclo di Vita del Software (CVS) è una caratterizzazione descrittiva o prescrittiva di come un sistema software viene o dovrebbe essere sviluppato. I modelli di processo software sono precise e formalizzate descrizioni di dettaglio delle attività, degli oggetti, delle trasformazioni e degli eventi che includono strategie per realizzare e ottenere l’evoluzione del software. Molti autori, tuttavia, usano i termini processo di sviluppo del software e ciclo di vita del software come sinonimi.

Esistono vari modelli di CVS, nati negli ultimi 30 anni: Waterfall (cascata), Prototyping, Incremental delivery (approcci evolutivi), Spiral model. La definizione di questi modelli è influenzata da molti aspetti: specificità dell’organizzazione produttrice, know-how (conoscere come un’operazione deve essere eseguita correttamente), area applicativa e particolare progetto, strumenti di supporto, diversi ruoli produttore/committente.

In un’ottica di alto livello, comunque, un CVS consta delle seguenti fasi:

• Definizione: si occupa della cosa. In particolare, si occupa di determinare i requisiti, le informazioni da elaborare, le funzioni e le prestazioni attese, il comportamento del sistema, le interfacce, i vincoli progettuali, i criteri di validazione.
• Sviluppo: si occupa del come. In altre parole, si occupa di definire il progetto, l’architettura software, la strutturazione dei dati, delle interfacce e dei dettagli procedurali, di tradurre il progetto nel linguaggio di programmazione e dei collaudi.
• Manutenzione: si occupa delle modifiche, come correzioni, adattamenti, miglioramenti, prevenzione.

2.2 Modello a cascata (Waterfall)

Modello popolare negli anni ’70, grazie a Royce, nato come reazione al “code and fix” (provare il codice e aggiustarlo approccio errato) originario e trova ispirazione dall’industria manifatturiera. È un modello sequenziale lineare, cioè con una progressione sequenziale (in cascata) di fasi, senza ricicli, per meglio controllare tempi e costi. Definisce e separa le varie fasi e le attività del processo.