Anteprima
Vedrai una selezione di 6 pagine su 22
Ingegneria del software - il ciclo della vita del software Pag. 1 Ingegneria del software - il ciclo della vita del software Pag. 2
Anteprima di 6 pagg. su 22.
Scarica il documento per vederlo tutto.
Ingegneria del software - il ciclo della vita del software Pag. 6
Anteprima di 6 pagg. su 22.
Scarica il documento per vederlo tutto.
Ingegneria del software - il ciclo della vita del software Pag. 11
Anteprima di 6 pagg. su 22.
Scarica il documento per vederlo tutto.
Ingegneria del software - il ciclo della vita del software Pag. 16
Anteprima di 6 pagg. su 22.
Scarica il documento per vederlo tutto.
Ingegneria del software - il ciclo della vita del software Pag. 21
1 su 22
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

Modellazione aziendale

Modellazione dei dati

Modellazione del processo dei dati

Generazione dell'applicazione

Collaudo e sostituzione

60 - 90 giorni

Fig. 4 http://www.quellidiinformatica.org

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 requisiti 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

Il 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.

È 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 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 losviluppo 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 - 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,T2T7 20 T1T8 25 T4T9 15 T3,T6T10 15 T5,T7T11 7 T9T12 10 T11 Fig. 7Durata stimata Ritardo che può esistere4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9http://www.quellidiinformatica.org 8StartT4T1T2M8 M1M2 T7T3M5T8 M3T6T5M4T9 M7T10M6T11T12 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

diinterfacciahttp://www.quellidiinformatica.org

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 sullaTecnico del Base di dati delControllo proprietàSoftware progettoaccessi BloccoOggetto della Oggetto dellaconfigurazione configurazioneEstrazione(versione estratta) (versione acquisita) Fig. 11Nell’operazione modifica, da quanto si evince dalla figura, un oggetto acquisito per esseremodificato deve avere l’accordo delle “autorità” competenti; per effettuare la modifica dell’oggettosi deve chiedere l’estrazione del progetto, dopodiché il tecnico del software reinserisce la versionemodificata del progetto che viene inserita nella base di dati del progetto stesso.http://www.quellidiinformatica.org 10

La qualità del softwareCol passare degli anni, come spiegato in precedenza, il sempre crescente sviluppo del software hareso 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-1000x100 Costo relativo alla30-70x correzione degli errori15-40x10 10x1x 3-6x1 Requisiti Codice Coll.sistemaProgettaz. Collaudo Offerta sul Fig. 12sviluppo campo

L’importanza di un buon controllo di qualità del software si riflette sui costi relati

Dettagli
Publisher
A.A. 2012-2013
22 pagine
SSD Ingegneria industriale e dell'informazione ING-INF/05 Sistemi di elaborazione delle informazioni

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à Università degli studi di Napoli Federico II o del prof Fassolino Rita.