Ingegneria del software

Introduzione

L'ingegneria del software 232g65c è, secondo alcune definizioni, "una disciplina della scienza delle metodologie atta a risolvere i problemi di programmazione" e "lo studio dei principi, metodi e strumenti per sviluppare e mantenere i sistemi software".

L'evoluzione del software a cui abbiamo assistito fino ad ora (tab. 1.1) ha reso necessaria la nascita di questa nuova scienza.

Tab 1

In particolare l'ingegneria del software 232g65c comincia a delinearsi durante la 2° epoca causa la mancanza di metodologie, mentre durante la 3° epoca comincia a svilupparsi anche il campo della ricerca.

L'ingegneria del software è una conseguenza dell'ingegneria dell'hardware e dei sistemi. Include un insieme di tre elementi chiave che sono metodi, strumenti e procedure che consentono al responsabile di controllare il processo di sviluppo del software e offrono al professionista le basi per costruire software di alta qualità e in modo produttivo. Esaminiamo brevemente ognuno di questi elementi:

I metodi dell'ingegneria del software 232g65c dicono al tecnico "come fare" per costruire il software. I metodi comprendono un vasto insieme di compiti come pianificazione e stime del progetto, analisi dei requisiti del software e del sistema; progettazione delle strutture dei dati, dell'architettura dei programmi e delle procedure per gli algoritmi, codifica, testing, manutenzione. I metodi per l'ingegneria del software 232g65c spesso introducono un linguaggio speciale o una notazione grafica e un insieme di criteri per la qualità del software.

Gli strumenti dell'ingegneria del software 232g65c forniscono un supporto automatizzato o semi-automatizzato ai metodi. Oggi, esistono strumenti che supportano ciascuno dei metodi prima descritti. Quando gli strumenti sono integrati in modo che l'informazione creata da uno strumento possa essere usata da un altro, si ha un sistema di supporto per lo sviluppo del software detto Computer-Aided Software Engineering (CASE, ingegneria del software assistita dall'elaboratore). Il CASE è l'unione di software, hardware, e una base di dati per l'ingegneria del software 232g65c , ossia una struttura di dati che contiene informazioni importanti sull'analisi, la progettazione, la codifica e il testing che permette di creare un ambiente per l'ingegneria del software, analogamente al CAD/CAE (Computer-Aided Design/Engineering per l'hardware).

Le procedure dell'ingegneria del software 232g65c sono la colla che tiene uniti i metodi e gli strumenti e che permette uno sviluppo razionale e tempestivo. Le procedure definiscono la sequenza con cui i metodi dovranno essere applicati; definiscono, poi, ciò che dovrà essere consegnato (documenti, tabulati, moduli, ecc.), oltre ai controlli che aiutano ad assicurare la qualità e a coordinare le modifiche e ai passi che devono essere fatti dai responsabili del software per stimare gli avanzamenti.

L'ingegneria del software è fatta di passi che comprendono i metodi, gli strumenti e le procedure prima definiti. Tali passi sono spesso indicati come i paradigmi dell'ingegneria del software.

Un paradigma dell'ingegneria del software 232g65c è scelto sulla base della natura del progetto e dell'applicazione, dei metodi e degli strumenti che devono essere usati e dei controlli e dei risultati richiesti. In particolare, tre modelli sono stati oggetto di ampie discussioni e vengono descritti di seguito.

Il processo

Il processo è suddiviso in 4 fasi principali:

• Fase di specifica;
• Fase di sviluppo;
• Fase di validazione;
• Fase di manutenzione.

Queste fasi hanno durata di tempo differente l'una dall'altra, in relazione anche all'esigenza dei singoli progetti (nei progetti molto grandi, ad esempio, viene dato molto tempo alla fase di specifica).

Il processo, inoltre, ha caratteristiche proprie che sono:

Comprensibilità: a cosa tende il processo esplicitamente definito e quanto facile da capire è la definizione di processo?

Visibilità: le attività del processo terminano in risultati chiari così che il progresso del processo è esternamente visibile?

Supportabilità: fin dove le attività del processo possono essere supportate da attrezzi CASE?

Accettabilità: il processo definito è accettabile e usabile dagli ingegneri responsabili per produrre il prodotto del software?

Affidabilità: il processo è disegnato in modo che gli errori del processo sono evitati o sono bloccati prima che si producono errori del prodotto?

Robustezza: il processo può continuare nonostante problemi inaspettati?

Manutenzione: il processo può evolversi per rispecchiare cambiamenti dei requisiti organizzativi o miglioramenti identificati nel processo?

Rapidità: quanto velocemente può essere completato il processo di consegna di un sistema da una specifica data?

Il ciclo di vita del software

Per ciclo di vita del software si intende la scomposizione del processo di produzione del software in una sequenza ordinata di fasi temporali precisamente definite.

Il ciclo di vita del software comincia con la fase di definizione del problema da cui si ottiene il documento in cui si individuano i propositi del progetto, gli obiettivi e i maggiori vincoli.

Con la seconda fase, quella dell'analisi dei requisiti, si determinano i servizi che il sistema deve fornire e se questi servizi possono essere attuati con l'ausilio dell'informatica. Da questa fase si ottengono essenzialmente il documento dei requisiti e il budget preliminare.

La fase di specifica, invece, si occupa di descrivere le soluzioni, gli input, gli output e le funzioni del progetto e fornisce il documento di specifica (che può essere visto come un manuale per gli utenti) e il piano di sviluppo.

La fase di progettazione si occupa di come sarà strutturato il software a livello di interfaccia uomo-macchina. Pertanto da questa fase si avrà il documento di design con la relativa architettura e il design dettagliato.

Durante la fase di codifica, invece, si traduce il lavoro sino ad ora fatto in un linguaggio informatico (C, Visual C++, ecc.) e si redige il documento relativo e il piano-test finale.

Infine vi sono la fase di testing, durante la quale si prova il software perché non dia errore durante l'esecuzione e che fornisce il documento di test e il documento finale compreso di manuali di sistema, utenti e i documenti per la manutenzione, cioè l'ultima fase del ciclo di vita del software, che consiste nell'adattare l'applicazione ai possibili cambiamenti e capire se è sempre valida.

La figura seguente illustra il passaggio tra una fase e un'altra dove l'output (documenti, report, prodotto) di uno stadio diviene l'input di quello successivo.

Attività Controllo

output

Attività Controllo

Fase input

report docum. prodotto

I modelli del processo

Al fine di risolvere un determinato problema, l'équipe di analisti deve trovare una strategia mediante la quale sia possibile la risoluzione del problema in esame.

A tal proposito si utilizzano 4 tipi fondamentali di modelli:

Modello sequenziale (o a cascata o waterfall) che riproduce il ciclo di vita del software;

Modello evolutivo, che consiste nel proporre un progetto iniziale che poi si migliorerà fino ad ottenere il progetto finale;

Modello assemblaggio componenti, che utilizza elementi utilizzabili per diverse applicazioni;

Modello dei metodi formali, per il momento riservato alla ricerca.

A tal proposito illustriamo alcune figure relative ai modelli qui sopra descritti.

Fig 1

Fig. 2

Fig. 3

Team 3

Team 2

Team 1

60 - 90 giorni Fig. 4

Nella fig. 1 è illustrato il modello sequenziale di cui si è parlato in precedenza. Questo modello ha come vantaggio la semplicità d'uso in quanto è un modello molto intuitivo, ma ha come svantaggio la difficile modifica di una delle fasi poiché questa modifica avrebbe un costo molto elevato.

Le figg. 2 e 3 mostrano, invece, due variazioni del modello evolutivo, che tratta specificazione, sviluppo e convalidazione come attività concorrenti (vedi fig. 6). La fig. 2 sintetizza lo schema del modello incrementale che può essere visto anche come un insieme di modelli sequenziali. Questo modello è utile nel caso in cui le persone che cooperano sono poche oppure quando il progetto dovrà durare molto nel tempo. La fig.3, invece, mostra lo schema di un altro tipo di modello evolutivo, vale a dire la prototipazione che risulta utile qualora non si abbiano idee chiare sui requisisti del cliente, quando si utilizzano tecniche e strumenti poco conosciuti, quando gli algoritmi da implementare sono particolarmente difficili, ecc. In questi casi si opta per la prototipazione poiché è facile modificare il progetto iniziale o parti di esso, ma allo stesso tempo risulta un po' svantaggioso perché in caso il tempo sia insufficiente per terminare il progetto, il prototipo diventa il prodotto finale; inoltre la prototipazione non è molto affidabile e in molti casi il prodotto appare molto complesso.

La fig. 4 schematizza il modello RAD, un modello misto che unisce il modello assemblaggio componenti allo sviluppo di tipo sequenziale. L'utilizzo del modello assemblaggio componenti è molto vantaggioso poiché si lavora su componenti collaudate (classi di dati, di procedure, ecc.) e si riducono i tempi di sviluppo e i costi di realizzazione, ma per implementarlo si deve avere molta preparazione. Il modello RAD viene utilizzato quando il tempo a disposizione è poco; il lavoro viene suddiviso in équipe che lavorano su diverse parti del progetto (vedi fig.) e solitamente si lavora su moduli pronti e già testati. Questo modello, però, non è adatto quando i rischi sono molto elevati.

La fig. 5, infine, mostra il modello a spirale, considerato un tipo particolare di modello evolutivo. Questo modello tratta gruppi di attività relativi al problema; esso sarà più o meno complesso secondo la complessità del problema. In questo caso il processo è articolato in diversi settori ed è da adattare alle situazioni possibili. Benché non sia molto facile da implementare vista la grande conoscenza del software necessaria e abbia dei costi molto elevati, è un modello molto valido e si hanno subito dei risultati soddisfacenti.

Il modello dei metodi formali, non illustrato in figura, fa parte dei modelli sperimentali e comprende un'attività che conduce alla specifica matematica del software; questi modelli sono utili agli analisti del software in quanto da essi potranno verificare le applicazioni, ma il loro sviluppo risulta al momento lento e molto costoso e quindi non ancora applicabile.

Attività concorrenti

Fig. 6

La visibilità del processo

La necessità che il processo di realizzazione di un'applicazione sia ben visibile nasce dalla necessità dei capo-progetti di seguire lo sviluppo del processo stesso.

La visibilità del processo si raggiunge attraverso la creazione di documenti distribuibili che sono il risultato delle attività del processo ed è costituita sostanzialmente da:

documenti;

report dell'attività;

review.

Secondo il modello usato si può avere una diversa visibilità del processo come evidenziato nello schema seguente.

Modello  Visibilità

Sequenziale OK

Evolutivo Povera

Metodi formali OK

Assemblaggio componenti Si/No (secondo lo sviluppo delle librerie

Spirale OK

Gestione dei progetti software

La gestione dei progetti software è un'attività propria dell'ingegneria del software di cui fanno parte 3 componenti principali quali:

persone (che è la componente più importante)

problema

processo.

La componente "persone", a sua volta, si suddivide in:

dirigenti

capi progetti

tecnici

clienti

utenti finali.

La comunicazione fra questi individui viene effettuata tramite rapporti, resoconti, riunioni e risulta molto importante per il buon esito del progetto.

Tra i vari documenti che scaturiscono da questa comunicazione vi sono in particolare:

Piano di qualità riguardo le procedure e gli standard da seguire;

Piano di convalidazione, che fornisce informazioni circa l'approccio al progetto, le risorse e il timing;

Piano di gestione e configurazione, che tratta le procedure e la struttura del progetto;

Piano di mantenimento, circa i requisiti, i costi e gli sforzi di mantenimento;

Piano di gestione staff, che riguarda i tecnici e i compiti da assegnare.

Quando vengono stabiliti questi piani, il capo progetto fa una tabella (fig.7) con i problemi da risolvere e per ognuno di questi descrive il tempo di realizzazione. Da questa tabella esce o una rappresentazione grafica o una rappresentazione a barre (fig. 8).

Task  Duration (days) Dependencies

T1 8

T2 15

T3 15 T1

T4 10

T5 10 T2,T4

T6 5 T1,T2

T7 20 T1

T8 25 T4

T9 15 T3,T6

T10 15 T5,T7

T11 7 T9

T12 10 T11

Fig. 7

Durata stimata Ritardo che può esistere

11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T2   T1   T4

T3   T7   M1   Start

T5   T6   T8   M3   M5

M2

T9

T10   M7   M4

T11

T12   M6

M8

Finish

Fig. 8

Tra le attività che devono essere eseguite dalle persone, vi sono le cosiddette attività ausiliarie, cioè:

gestione di configurazione;

controllo di qualità.

Il compito della gestione di configurazione riguarda principalmente il controllo delle varie versioni del progetto e si articola in diverse sotto-attività:

riconoscimento del cambiamento;

controllo del cambiamento;

garanzia dell'implementazione;

riferimento del cambiamento agli interessati;:

controllo versione;

controllo modifica.

La gestione di configurazione viene effettuata seguendo quelle che sono le specifiche di progettazione e di collaudo come da fig. 9.

Specifiche di progettazione

Modelli dei dati

Codice sorgente

Specifiche di collaudo

Modulo di interfaccia

Fig. 9

Fig. 10

La figura 10 rappresenta la gestione delle versioni di un software: la prima versione (che può essere ad esempio il prototipo nel modello prototipazione) viene di solito indicata con il numero 1.0. Successivamente se si modifica questa versione lasciando invariate alcune parti essenziali si continua il "conteggio" lasciando inalterato il primo numero (1.1, 1.2, .); si può, però, migliorare piccole parti delle versioni procedendo con la numerazione, ad esempio, 1.1.1. Se, però, della prima versione vengono cambiate alcune parti essenziali, allora la nuova versione cambierà numero diventando ad esempio la versione 2.0.

Nella successiva figura si illustra, invece, uno schema riguardante l'operazione di modifica del database in un progetto.

Fig. 11

Nell'operazione modifica, da quanto si evince dalla figura, un oggetto acquisito per essere modificato deve avere l'accordo delle "autorità" competenti; per effettuare la modifica dell'oggetto si deve chiedere l'estrazione del progetto, dopodiché il tecnico del software reinserisce la versione modificata del progetto che viene inserita nella base di dati del progetto stesso.

La qualità del software

Col passare degli anni, come spiegato in precedenza, il sempre crescente sviluppo del software ha reso necessaria una maggiore attenzione verso quella che è la qualità del software.

I primi che si resero conto dell'importanza che ha il controllo della qualità non solo nella creazione di un software, ma anche nella produzione dei prodotti in generale, furono i giapponesi negli anni '60 grazie all'intuito di Edward Deming che da allora è considerato il padre di quella che in ambito aziendale viene chiamata "qualità totale".

Per quanto riguarda la qualità del software, questa è vista sotto diversi aspetti:

strategia di gestione;

tecnologia;

revisioni tecniche formali;

strategia di collaudo;

gestione della documentazione e delle modifiche;

procedura di conformità agli standard;

meccanismi di misurazione e di stesura dei resoconti.

In riferimento alle procedure di conformità agli standard è opportuno precisare che per i prodotti software esiste un'apposita istituzione che regolamenta gli standard che si chiama ISO e a cui tutti i progettisti devono fare riferimento.

Vi sono due tipi di qualità:

progettazione (riguardo il materiale, le persone, i fornitori, .);

conformità (se le specifiche sono conformi o meno alla progettazione).

Il controllo di qualità viene effettuato mediante:

esami;

collaudi;

revisioni;

auditing.

1000 4-1000x

Costo relativo alla correzione degli errori

100

30-70x

15-40x

10 10x

1x 3-6x

1

Requisiti Codice Coll.sistema

Fig. 12

Progettaz. Collaudo Offerta sul

sviluppo campo

L'importanza di un buon controllo di qualità del software si riflette sui costi relativi alla correzione degli errori (come da fig.12).

Il grafico in figura scaturisce dai dati di una statistica riguardante i costi relativi alla correzione degli errori e mostra come un errore non corretto a livello dell'analisi dei requisiti si propaga alle altre fasi amplificandone i costi per la sua correzione. Infatti, se l'errore viene ipoteticamente corretto in fase di analisi dei requisiti o in fase di progettazione, i costi per eliminarlo sono quasi irrisori (nell'esempio del grafico 1 unità di misura); ma se lo stesso errore viene scoperto in fase di collaudo del sistema o addirittura quando il software è già in commercio, i costi per la sua rimozione aumentano vertiginosamente (fino ad arrivare a 1000 volte l'unità di misura).

Se l'équipe che progetta il software è molto "rigida", lavora cioè secondo canoni ben precisi ed ha un buon affiatamento, si avrà un prodotto di alta qualità, altrimenti bisogna procedere attuando una politica di garanzia della qualità.

Da quanto detto ci si rende subito conto che il fattore "qualità" è di importanza basilare per creare un buon progetto ed è soggetto a norme (e standard) sia di livello internazionale (ISO) che a livello aziendale. Pertanto possiamo affermare che qualità è sinonimo di rispetto:

dei requisiti funzionali e prestazionali enunciati esplicitamente;

delle conformità a standard di sviluppo esplicitamente documentate;

delle caratteristiche implicite che ci si aspetta da un prodotto realizzato professionalmente.

Inoltre uno studioso di questa materia, McCall, ha enunciato gli 11 fattori di qualità di un software:

correttezza: il grado di conformità del programma alle specifiche e agli obiettivi del cliente;

affidabilità: il grado in cui un programma svolge la propria funzione con la precisione richiesta;

efficienza: la quantità di risorse e di codice perché il programma adempia la propria funzione;

integrità: il grado in cui è possibile controllare l'accesso al software e ai dati da parte di persone non autorizzate;

usabilità: lo sforzo necessario per apprendere e utilizzare il programma, a prepararne i dati d'ingresso e a interpretarne i dati d'uscita;

manutenzione: lo sforzo necessario per localizzare e correggere un errore nel programma;

flessibilità: lo sforzo necessario per modificare un programma in esercizio;

provabilità: lo sforzo necessario per stabilire, tramite collaudo, se un programma svolge la funzione prevista;

portabilità: lo sforzo richiesto per trasportare un programma da un ambiente, hardware o software, a un altro;

riusabilità: il grado in cui un programma può essere utilizzato di nuovo in altre applicazioni; è correlato al modo in cui il programma è assemblato e alla portata delle funzioni svolte dal programma;

interoperabilità: lo sforzo richiesto per far interagire il programma con altri programmi.

Per assicurare un buon livello di qualità del prodotto i tecnici lavorano "fianco a fianco" con delle équipe dette SQA, Software Quality Assurance, che svolgono i seguenti compiti:

sorvegliano il lavoro dei tecnici per evitare la presenza di errori;

pianificano l'attività di progettazione;

danno la conformità al progetto;

forniscono assistenza ai tecnici.

Per quanto riguarda gli standard e le normative ISO, esiste una norma che garantisce la qualità nell'ambito dell'ingegneria del software 232g65c ed è la norma ISO 9001. Secondo questa normativa, un sistema di garanzia di qualità deve soddisfare venti requisiti. Poiché la norma ISO 9001 si applica a qualsiasi disciplina ingegneristica, è stato pubblicato un documento (ISO 9000-3) che guida la sua interpretazione nel contesto del processo software.

I venti requisiti riguardano gli argomenti seguenti:

1. Responsabilità gestionali.
2. Sistema di qualità.
3. Revisione del contratto.
4. Controllo della progettazione.
5. Controllo della documentazione e dei dati.
6. Acquisto.
7. Controllo di prodotti forniti dal cliente.
8. Identificazione e reperibilità del prodotto.
9. Controllo del processo.
10. Ispezione e collaudi.
11. Controllo degli strumenti per ispezioni, misurazioni e collaudi.
12. Stato delle ispezioni e dei collaudi.
13. Controllo di prodotti non conformi.
14. Azioni correttive e preventive.
15. Trattamento, memorizzazione, confezione, conservazione e consegne.
16. Controllo dei record di qualità.
17. Esami interni della qualità.
18. Addestramento.
19. Assistenza.
20. Tecniche statistiche.

Ingegneria dei requisiti

L'ingegneria dei requisiti è quel processo che determina i servizi che il sistema deve fornire e le costruzioni sotto le quali dover operare.

Durante la fase di analisi del problema occorre capire di cosa ha bisogno il problema stesso e se tale problema è risolvibile con il supporto dell'informatica: in questa fase, quindi, bisogna capire cosa fare.

I requisiti si distinguono in requisiti funzionali (servizi + funzionalità) e requisiti non funzionali (requisiti impliciti).

La difficoltà nell'individuazione dei requisiti consiste nel fatto che il più delle volte il cliente non è un esperto informatico. In questi casi, quando cioè i requisiti sono imprecisi, si utilizza un modello di processo creato per affinare i requisiti.

Fig. 13

L'analisi dei requisiti si suddivide in 4 fasi principali:

studio della fattibilità (definisce se il sistema proposto rientra nel budget e deve essere piuttosto rapido;

analisi dei requisiti;

definizione dei requisiti;

specificazione dei requisiti.

Definizione dei requisiti

Fig. 14

Specificazione dei requisiti

Fig. 15

Fig. 16

Gli schemi nelle figure 14 e 15 sintetizzano le caratteristiche che un software deve soddisfare in fase di definizione dei requisiti e di specificazione dei requisiti.

La figura 16, invece, assegna a ciascuna delle tre fasi (definizione dei requisiti, specificazione dei requisiti e specificazione del software) le persone che vi possono interagire. Si nota come il "cliente-ingegnere" e "l'architetto di sistema" possano contribuire a ciascuna delle tre fasi, mentre altre figure professionali compaiano solo in una fase o due.

Per poi "implementare" i requisiti occorre seguire uno dei seguenti modelli:

modello data flow;

modello semantico;

modello object;

modello formale.

I modelli di tipo data flow descrivono un flusso di dati e vengono esemplificati con l'utilizzo dei DFD, Data Flow Diagram (Diagramma del flusso di dati) come nell'esempio in figura.

Incassi

Tasse

Utente