Che materia stai cercando?

Anteprima

ESTRATTO DOCUMENTO

Fig. 3

Team 3

Modellazione

Team 2 aziendale

Modellazione

Modellazione dei dati

Team 1 aziendale Modellazione

Modellazione

Modellazione del processo

dei dati

aziendale Generazione

dell’applicaz.

Modellazione

Modellazione del processo Collaudo e

dei dati sostituzione

Generazione

dell’applicaz.

Modellazione

del processo Collaudo e

sostituzione

Generazione

dell’applicaz.

Collaudo e

sostituzione

60 – 90 giorni Fig. 4

http://www.quellidiinformatica.org 5

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

http://www.quellidiinformatica.org 6

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 Versione iniziale

Specificazione Versione

Outline Sviluppo intermedia

description Verifica Versione finale

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:

http://www.quellidiinformatica.org 7

- 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

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

http://www.quellidiinformatica.org 8

Start

T4

T1

T2

M8 M1

M2 T7

T3

M5

T8 M3

T6

T5

M4

T9 M7

T10

M6

T11

T12 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 Modelli dei

dati

progettazione Modulo di

interfaccia

http://www.quellidiinformatica.org 9

Specifiche di Fig. 9

1.3 1.4

1.2 2.0 2.1

1.0 1.1 1.1.1 1.1.2 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.

Dati sugli esami Oggetto della

Reinserimento

Oggetto della configurazione

(versione acquisita)

configurazione

(versione modif.) Sblocco Dati sulla

Tecnico del Base di dati del

Controllo proprietà

Software progetto

accessi Blocco

Oggetto della Oggetto della

configurazione configurazione

Estrazione

(versione estratta) (versione acquisita) 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.

http://www.quellidiinformatica.org 10

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

100 Costo relativo alla

30-70x correzione degli errori

15-40x

10 10x

1x 3-6x

1 Requisiti Codice Coll.sistema

Progettaz. Collaudo Offerta sul Fig. 12

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

http://www.quellidiinformatica.org 11

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; la quantità di risorse e di codice perché il programma adempia la propria

- efficienza:

funzione;

- integrità: il grado in cui è possibile controllare l’accesso al software e ai dati da parte di

persone non autorizzate;

lo sforzo necessario per apprendere e utilizzare il programma, a prepararne i dati

- usabilità:

d’ingresso e a interpretarne i dati d’uscita;

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

lo sforzo necessario per modificare un programma in esercizio;

- flessibilità:

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

funzione prevista;

lo sforzo richiesto per trasportare un programma da un ambiente, hardware o

- portabilità:

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; lo sforzo richiesto per far interagire il programma con altri programmi.

- interoperabilità:

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.

Tecnici Equipe SQA

http://www.quellidiinformatica.org 12

Per quanto riguarda gli standard e le normative ISO, esiste una norma che garantisce la qualità

nell’ambito dell’ingegneria del software 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.

Studio di Analisi dei

fattibilità requisiti Definizione

dei requisiti

Report di Specifiche

http://www.quellidiinformatica.org 13

fattibilità dei requisiti


PAGINE

22

PESO

114.81 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Ingegneria del Software e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Fassolino Rita.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Ingegneria del software

Ingegneria del Software
Dispensa
Ingegneria del software - Esercizi
Esercitazione
Ingegneria del Software – Introduzione
Dispensa
ingegneria del software esame svolto Completo Russo
Appunto