Pagina: 1 di 37

Anno Accademico 2006-2007

Corso di Studi in Informatica Applicata Università degli Studi di Catania

Campus di Comiso

Tesina di Ingegneria del Software I e II

“Progettazione di un sistema informatizzato per la

gestione funzionale di un parcheggio a pagamento” (PARK on LINE)

Corso di Ingegneria del Software

Prof. Giuseppe Scollo

A cura di Daniele Rimmaudo e Rosario Sgarlata

Pagina: 2 di 37

Park on Line

Indice

1 INTRODUZIONE ......................................................................................................................3

1.1 IDEA DEL PROGETTO ................................................................................................................7

1.2 DIAGRAMMA DEI CASI D’USO...................................................................................................8

2 METODOLOGIA DEL PROCESSO DI SVILUPPO...........................................................9

3 STUDIO DI FATTIBILITÀ.....................................................................................................13

3.1 DEFINIZIONE DEGLI OBIETTIVI ...............................................................................................13

3.2 STRATEGIE E POLITICHE DI GESTIONE ....................................................................................13

3.3 STIMA DEI COSTI E TEMPI DI REALIZZAZIONE ........................................................................14

3.3.1 Tempi di realizzazione ...................................................................................................14

3.3.2 Costi di produzione ........................................................................................................15

3.4 CONSIDERAZIONI ...................................................................................................................16

4 SPECIFICA DEI REQUISITI ................................................................................................17

4.1 ARCHITETTURA HARDWARE ..................................................................................................17

4.2 DIAGRAMMA DEI COMPONENTI ..............................................................................................18

5 ANALISI DELLE METRICHE FUNZIONALI.....................................................................19

6 PROGETTAZIONE ................................................................................................................23

7 SVILUPPO E COLLAUDO...................................................................................................34

8 INSTALLAZIONE MANUTENZIONE .................................................................................35

Pagina: 3 di 37

Park on Line

1 Introduzione

(Rimmaudo – Sgarlata)

Il termine Ingegneria del Software (Software Engineering) nasce alla fine degli anni ’60

in seguito al profondo cambiamento nel modo di usare i calcolatori elettronici che generò

il problema della cosiddetta “software crisis”. Questa fu causata dall’ introduzione dei

computers della terza generazione. Dette macchine erano di svariati ordini di grandezza,

più potenti di quelle della generazione precedente, quindi applicazioni particolarmente

complesse che prima parevano irrealizzabili divennero possibili.

L’implementazione di queste applicazioni richiese la realizzazione di sistemi software di

dimensioni notevoli.

Nei primi anni della loro diffusione, i computer venivano invece progettati e utilizzati

esclusivamente per risolvere problemi molto specifici. Il computer, in questo primo

periodo, era usualmente un supporto per il calcolo ed il software veniva scritto da un

programmatore che era, allo stesso tempo, utente finale dell’applicazione stessa, cioè

era lo stesso soggetto a scrivere ed utilizzare un programma. Quando, intorno al 1960, i

sistemi informatici diventano più grandi e complessi, le due figure del programmatore e

dell’utente si separano, nascono così i team di persone che si occupano di sviluppare

software di grandi dimensioni; non è più pensabile, infatti, che una sola persona affronti

tutti i dettagli di un problema complesso. In seguito alla richiesta di applicazioni sempre

più critiche e sofisticate, soprattutto in ambiente industriale, nasce il concetto di

Ingegneria del Software (intorno al 1968) definita come disciplina che regola lo sviluppo

di prodotti software di buona qualità, definendo le attività necessarie a gestire,

organizzare e in definitiva portare a buon fine la realizzazione, manutenzione ed

evoluzione di un sistema software di grandi dimensioni (processo di sviluppo software).

L’Ingegneria del Software è quindi un approccio sistematico allo sviluppo, rilascio,

manutenzione e ritiro di un prodotto software. Quando il software era molto semplice

l’attività di produzione era svolta in genere da un unico soggetto, che era allo stesso

tempo programmatore e utente. Attualmente non è più così e diversi soggetti sono

coinvolti nel processo di produzione del software. Il programmatore è usualmente un

soggetto distinto dall’utente, nasce anche la figura del committente che non è sempre

Pagina: 4 di 37

Park on Line

coincidente con l’utente. Il prodotto software è quindi il risultato del lavoro di più

persone, che spesso operano in momenti diversi. Pertanto è importante stabilire delle

attività regolamentate in modo tale da supportare ogni fase dello sviluppo, le

interrelazioni tra i vari soggetti coinvolti in esso, la comunicazione delle informazioni

necessarie per lo svolgimento di fasi successive. Il processo di sviluppo del software è quindi costituito da quelle attività e dai risultati ad esse connessi che sono necessarie

alla produzione del prodotto software.

Le principali attività, fondamentali e comuni in tutti i processi di sviluppo del software

sono:

ü Specifica del software. Vengono definite le funzionalità del software e i vincoli

sotto cui questo deve essere usato.

ü Sviluppo del software. Realizzazione dei programmi necessari per

l’implementazione delle funzionalità individuate nella specifica.

ü Validazione del software. Il software prodotto deve essere validato per

assicurarsi che esso realizzi esattamente ciò che il committente vuole.

ü Evoluzione del software. Il software deve evolversi per adattarsi ai cambiamenti

ritenuti necessari dal committente.

Il committente del prodotto quantifica e qualifica i suoi desideri circa il pacchetto

software da realizzare. Da queste richieste nascono le caratteristiche (le funzionalità che

deve sostenere, le possibilità da prevedere, …) e i requisiti (su quale hardware deve

funzionare, in quali situazioni particolari deve essere usato, …) che il prodotto deve

avere.

Solitamente si ha un dialogo preliminare tra il committente e un analista o specificatore,

in cui viene redatto un documento che presenta, in modo più o meno specifico, i requisiti

e le caratteristiche desiderate. Questa è la fase della specifica dei requisiti del software:

i requisiti vengono solitamente codificati con un linguaggio di specifica, che può avere

vari gradi di rigorosità e formalità:

ü Linguaggi di specifica informali: in genere il linguaggio naturale, usato per

descrivere le caratteristiche del prodotto mediante una serie di frasi;

Pagina: 5 di 37

Park on Line

ü Linguaggi di specifica semiformali e formali: descrizioni fornite mediante un

formalismo di qualche tipo (grafico, equazioni matematiche,linguaggi logici,

etc…).

I linguaggi di questo tipo suppongono l’esistenza di una teoria di supporto utile per

testare il soddisfacimento di determinati vincoli da parte della specifica.

Quando la prima fase è terminata inizia la fase di realizzazione, che riguarda le

modalità con cui il sistema software raggiungerà le caratteristiche e i requisiti richiesti. In

questa fase si sceglie il supporto hardware più adatto, si sceglie il tipo di

programmazione, si scompone il problema in più sottoprogetti da affidare a persone

diverse. Inoltre si fornisce l’implementazione degli algoritmi secondo le specifiche di

progetto.

La validazione è necessaria per garantire che il prodotto rilasciato sia conforme alle

specifiche e ottenga i risultati previsti. Si cerca quindi di “esercitare” il prodotto fornendo

dei dati critici o mirati a ottenere una data elaborazione. Si controlla quindi che il

prodotto funzioni correttamente.

È bene chiarire subito che la “Correttezza” è una qualità non sempre dimostrabile per il

software. Normalmente non è possibile testare un programma per provare la sua

correttezza con ogni possibile dato di ingresso. Come conseguenza si ha che la

correttezza del software è una proprietà in generale indecidibile. Si parla normalmente di

correttezza relativa ai risultati osservati con gli input forniti.

La fase di validazione prevede due stadi: la verifica e la successiva vera e propria

validazione.

La verifica viene effettuata prima del rilascio del prodotto da parte di chi ha sviluppato il

prodotto stesso.

La validazione viene generalmente svolta dal committente. Questi esamina il prodotto

finito per giudicare se funziona come ci si aspettava e in quale misura ha soddisfatto le

aspettative. Quindi il committente giudica se il programma è efficiente, se ha una buona

interfaccia utente, se è facile da usare, etc…

La validazione viene conferita solo se la verifica della qualità del prodotto dà esito

positivo.

Pagina: 6 di 37

Park on Line

I requisiti in un progetto di sviluppo software.

La gestione dei requisiti (acquisizione, analisi, negoziazione, specifica, validazione) è

una delle discipline più critiche dello sviluppo software, perché influenza in modo diretto

il successo o il fallimento dei progetti.

L'altalena è la metafora più comune per la gestione dei requisiti nei progetti software.

In questo documento, per le specifiche di progettazione, verranno utilizzati diagrammi

UML, in quanto sono uno standard ed evitano le possibili ambiguità.

Pagina: 7 di 37

Park on Line

1.1 Idea del Progetto

(Rimmaudo – Sgarlata)

Si vuole realizzare un sistema informativo per la gestione automatizzata di parcheggi

con intenso traffico ed elevate dimensioni (parcheggi aeroporti, stazioni ferroviarie).

Il sistema consentirà l’utilizzo del parcheggio direttamente on-line oppure tramite

operatore on-site.

Il sistema deve essere accessibile, principalmente, da remoto tramite interfaccia WEB e

in locale (in casi particolari e tramite operatore). In particolare, tramite internet, deve

essere possibile prenotare un posto auto e stamparne la prenotazione con un codice a

barre che consentirà l'accesso immediato al parcheggio una volta davanti la barriera di

accesso.

Lo scopo che si prefigge questo documento è quello di formalizzare ciò che dovrà

essere sviluppato e implementato nelle fasi successive del progetto.

In seguito si descriverà la progettazione del sistema tramite l'uso di diversi diagrammi

prodotti utilizzando il linguaggio di modellazione unificato (UML).

L'uso che faremo del linguaggio UML sarà quindi di tipo forward-engineering con un

livello di dettagli tra il modo d’uso sketch ed il modo d’uso blueprint.

Parte degli stessi diagrammi verranno utilizzati in modo ”reverse-engineering” nella

documentazione da fornire all’acquirente. Il tutto sarà comunque più che sufficiente ad

una buona documentazione ed esposizione del progetto.

Alcuni diagrammi comportamentali saranno utilizzati per descrivere l’uso pratico di

PARK on LINE e quindi includeranno comportamenti svolti da umani che interagiranno

con il sistema (utenti, operatori di botteghino).

Si individuano subito, dalle specifiche di progetto, i possibili casi d’uso esposti

nell’omonimo diagramma di seguito riportato:

Pagina: 8 di 37

Park on Line

1.2 Diagramma dei casi d’uso (Sgarlata)

Pagina: 9 di 37

Park on Line

2 Metodologia del processo di sviluppo (Rimmaudo – Sgarlata)

L'obiettivo di questa fase è progettare l'architettura del processo produttivo per un

prodotto per il quale sono stati determinati gli aspetti di qualità indicati nell’introduzione.

Data l'eterogeneità dei prodotti software e delle aziende che li realizzano non esiste un

unico modello di sviluppo del software adeguato a tutte le situazioni; pertanto, sorge la

necessità di progettare un processo di sviluppo che sia consono alle caratteristiche di

qualità desiderate del prodotto e dal Committente, nonché alle caratteristiche

dell'Azienda di produzione.

Negli anni sono stati definiti diversi modelli di processo ciascuno dei quali si adatta

meglio ad alcuni dei fattori di qualità indicati nell’introduzione o ai diversi soggetti che

sono coinvolti nella produzione.

Nel nostro caso il Produttore crea il software e fornisce l’hardware necessario al

funzionamento del sistema per poi immetterlo sul mercato.

Sarà il Produttore stesso a decidere quali sono gli obiettivi da conseguire. In questo

caso sono da considerare molteplici aspetti per rendere il prodotto competitivo: corretta

valutazione dei tempi di sviluppo, percezione di quale sarà la risposta del mercato

all’immissione di un simile prodotto, valutazione del rapporto costi di sviluppo/valore del

prodotto.

Lo scenario generale di centralità dell'Utente e di ottimizzazione delle risorse aziendali

nel processo di sviluppo di PARK on LINE fanno così propendere per l'adozione del

Modello a Cascata.

Lo scopo di questo modello è quello di valutare tutte le attività necessarie allo sviluppo

del software: interazione tra gruppi diversi, valutazione dei rischi economici, tempo

necessario a completare il prodotto, etc…Tutte queste attività complementari alla

scrittura del software sono molto importanti per la buona riuscita del prodotto finale,

quindi questo modello vede la produzione come una serie di passi, l’output di ogni passo

è un semilavorato da passare alla fase successiva. Con la definizione del ciclo di vita a

cascata si introduce quindi un modello strutturato, si regolamentano dei passi da

compiere nello sviluppo di un prodotto software, l’ordine di tali passi e si stabiliscono le

regole di transizione da un passo al successivo.

Pagina: 10 di 37

Park on Line

Il ciclo di vita a cascata per PARK on LINE

Studio di fattibilità

Si deve innanzitutto dare la definizione del problema avendo chiaro ogni aspetto del

problema stesso. Questo normalmente accadrà dopo un numero sufficiente di

interazioni tra committente e produttore del software. Devono essere valutati

specificatamente:

ü i costi e i tempi di produzione

ü le risorse umane necessarie

ü le risorse hardware necessarie

ü le alternative con cui il prodotto può essere sviluppato, relativamente ai costi, ai

tempi.

Analisi, modellazione e specifica dei requisiti

A partire dalle ipotesi preliminari si definiscono in modo preciso le caratteristiche del

sistema e i suoi requisiti funzionali, cioè quello che il sistema deve offrire all’utente finale

in termini di funzionalità.

Pagina: 11 di 37

Park on Line

Il documento prodotto in questa fase deve avere delle caratteristiche ben precise

affinché la fase successiva possa essere affrontata correttamente.

Un requisito è una scrittura più o meno formale e rigorosa di una caratteristica del

sistema, fatta dallo specialista.

Progettazione

In questa fase si definisce l’architettura software su cui si baserà la realizzazione. È

possibile considerare una scomposizione del problema in sottoproblemi attraverso la

definizione di una struttura modulare e delle relazioni tra i moduli.

Sviluppo e collaudo unità

È la fase realizzativa. Ogni modulo, come unità indipendente, viene implementato e

controllato per assicurarne la correttezza.

Integrazione, Installazione, Manutenzione

Quando il prodotto è stato realizzato, spesso è necessario apportare delle modifiche, sia

perché il prodotto non risulta rispettare completamente le specifiche fissate, sia perché

si ritiene necessario perfezionare alcune funzionalità e caratteristiche. Per rilevare questi

casi si effettua la distribuzione del prodotto ad un numero ristretto di persone (beta-

testers) che lo utilizzano con lo scopo di rilevare il maggior numero di malfunzionamenti

o difetti. Si possono fare piccole modifiche oppure, se siamo molto lontani dai requisiti, si

può scegliere di fare la reingegnerizzazione del sistema, in pratica ripartire da capo.

Finita con successo la fase di manutenzione si può eseguire il rilascio del sistema.

Pagina: 12 di 37

Park on Line

Considerazioni

Il modello del ciclo di vita a cascata è stato ed è molto utilizzato in contesto industriale

per la sua chiarezza e linearità: i passi sono ben distinti e susseguenti, il metodo preciso

e rigoroso. Proprio questi sono i punti di forza, ma anche le limitazioni di un modello

troppo rigido: i requisiti vengono “congelati” nelle prime fasi del progetto, quando ancora

non sono stati affrontati i problemi di realizzazione pratica del prodotto, quindi è facile

trovarsi alla fine con un prodotto non soddisfacente o che presenta dei

malfunzionamenti inaspettati.

Sarebbe più opportuno, quindi, effettuare degli accorgimenti durante il processo

realizzativo e immettere dei feedback di verifica.

Questo modello si basa sul presupposto che ogni fase può essere perfezionata o

raffinata a seconda dei risultati dell’analisi effettuata nella fase precedente.

Si ovvia così alla rigidità del modello del Ciclo di vita a cascata.

Ai fini della soddisfacibilità si inserisce il concetto di qualità. Per poter individuare e

determinare la qualità di un prodotto si sono date delle regole, allo scopo di garantire

all’utente un determinato livello di qualità. Un valido esempio è fornito dagli standard

ISO (International Organization for Standardization); tale organizzazione ha da tempo

pubblicato una serie di standard sulla qualità, la serie ISO 9000 per cui un prodotto “ISO

approved” rispetta le garanzie di qualità fornite dall’ente. Esiste la figura dell’ispettore

che verifica la qualità del prodotto con una check list, una lista di domande, talvolta

volutamente contraddittorie tra loro, cui il produttore deve rispondere. Citiamo lo

standard ISO 9126 che descrive le procedure da seguire per documentare in modo

idoneo tutto ciò che avviene durante il processo di produzione.

La certificazione di appartenenza a uno standard è particolarmente importante per i

software “critici”, oppure nel caso di certificazione fiscale; per questo esistono specifici

enti di certificazione che analizzano i prodotti, al fine di testare la loro soddisfacibilità

rispetto agli standard ISO.

Pagina: 13 di 37

Park on Line

3 Studio di fattibilità (Sgarlata)

Per studio di fattibilità si intende lo svolgimento di un'analisi atta a valutare le scelte

aziendali da prendere. In particolare, questa fase ha come scopo quello di determinare

la convenienza o meno di sviluppare l'idea di progetto scaturita dalle esigenze degli

utenti in un prodotto realizzabile.

Le decisioni vengono prese dopo un'analisi di costi e benefici e degli strumenti posseduti

dall'azienda.

3.1 Definizione degli obiettivi Gli obiettivi che si intendono raggiungere dallo sviluppo di questo progetto sono:

ü realizzazione di un software per la gestione funzionale di parcheggi a pagamento

di elevate dimensioni;

ü il software deve rispondere ai requisiti di qualità richiesti dagli standard

internazionali;

ü il prodotto deve soddisfare le esigenze del mercato, quindi essere adattabile ad

ogni richiesta o tecnologia innovativa;

ü il software deve risultare affidabile, cioè garantire livelli di performance prefissati,

in date condizioni e per un dato periodo di tempo;

ü garantire la portabilità del prodotto, cioè assicurarne l'indipendenza dalla

piattaforma hardware;

ü rendere il processo di produzione più efficace minimizzando i costi e i tempi;

3.2 Strategie e politiche di gestione Per lo sviluppo di questo progetto si prevede l’utilizzo del seguente personale:

n°1 progettista e analista: ha il compito di progettare, programmare e analizzare il

software;

n°1 programmatore con ottima conoscenza in gestione di basi dati e programmazione

con linguaggi orientati ad oggetti, e buona conoscenza assemblaggio hardware.

n°1 coordinatore dei processi di produzione;

n°1 esperto di marketing: necessario al fine di pubblicizzare il prodotto nel mercato.

Pagina: 14 di 37

Park on Line

3.3 Stima dei costi e tempi di realizzazione Lo studio di fattibilità ha come scopo quello di dare un'idea di massima della

convenienza nel realizzare l'idea di progetto. Poiché le informazioni a disposizione

dell'azienda sono limitate non è possibile dare una valutazione precisa dei costi di

produzione e dei tempi di realizzazione. Effettuare una stima di questi due fattori aiuta

però a capire quale sarà lo sforzo complessivo che dovrà sostenere l'organizzazione

aziendale.

3.3.1 Tempi di realizzazione

Per la realizzazione del prodotto nella forma standard è previsto un tempo minimo di

nove mesi, comprensivo di analisi e collaudo. Tale stima, però, può subire variazioni in

relazione alle personalizzazioni richieste dagli utenti.

Il calcolo del tempo di realizzazione previsto è stato effettuato utilizzando il modello di

stima dei costi del software, COCOMO (COnstructive COst MOdel). Metrica definita da

B. Boehm con l'obiettivo di descrivere il costo di produzione.

La teoria fornisce una serie di tre modelli:

Basic COCOMO: questo modello calcola lo sforzo e il costo per lo sviluppo di un

software come funzione della dimensione del programma espressa in linee di codice

stimate;

Intermediate COCOMO: oltre alla dimensione del programma si introducono nella

funzione degli indicatori che includono valutazioni del prodotto, dell'hardware disponibile,

del personale e degli attributi del progetto;

Advanced COCOMO: incorpora le caratteristiche della precedente descrizione

separando gli indicatori per ogni fase del processo di sviluppo;

Il modello basilare ha come scopo quello di dare una stima dello sforzo totale (in mesi

persona) e del tempo di sviluppo, utilizzando come unico parametro la previsione delle

dimensioni del prodotto finale. Le stime prodotte hanno una percentuale di scostamento

inferiore al 20% nel 25% dei casi.

Pagina: 15 di 37

Park on Line

Le due formule utilizzate da questo modello sono le seguenti:

Sforzo E = ab * (S)bb

Tempo di sviluppo D = cb * (E)db

dove, E (effort) indica la quantità di lavoro (espressa in Mesi/Persona), D (duration)

rappresenta il tempo di sviluppo (espresso in Mesi) e S rappresenta il numero di linee di

codice previste (espresse in migliaia).

Per il calcolo di questi indici sono stati adoperati i coefficienti standard del modello Basic

COCOMO che hanno i seguenti valori:

ab bb cb db 2,4 1,05 2,5 0,38

Considerando una stima approssimativa di 10.000 righe di codice sono stati registrati i

seguenti risultati:

E = 2,4 * 101,05 = 26,9 mesi/persona D = 2,5 * 26,90,38 = 8,7 mesi Dai precedenti valori è possibile determinare il numero minimo di persone richieste per

sviluppare il progetto:

P = E/D = 26,9/8,7 = 3,1

3.3.2 Costi di produzione

La stima dei costi di produzione tiene conto delle spese che l'azienda dovrà sostenere.

Affitto locali € 220,00 mensili;

2 PC € 2200,00;

acquisto di software € 300,00;

energia elettrica pari a € 60,00 mensili

specialista in marketing di € 600,00 mensili.

Calcolando l'ammontare delle spese totali si ottiene una stima dei costi durante il

periodo di produzione pari a € 10.420,00.

Pagina: 16 di 37

Park on Line

3.4 Considerazioni Dallo studio di fattibilità si evidenziano delle stime di costi e di tempi che rientrano

pienamente nelle disponibilità presenti all'interno dell'organizzazione.

Nel caso in cui ciò dovesse comportare dei problemi si provvederà all’assunzione di un

programmatore part-time affinché vengano rispettate le previsioni di completamento del

prodotto.

Infine, da un'analisi di mercato effettuata si prospettano buone opportunità di lancio e di

acquisto del prodotto grazie anche alle sue peculiarità di personalizzazione.

Pagina: 17 di 37

Park on Line

4 Specifica dei requisiti (Rimmaudo)

4.1 Architettura Hardware L’ architettura di PARK on LINE consiste principalmente in un calcolatore di ultima

generazione su cui far girare il web server, il server data base e il software per la

gestione delle periferiche. Queste ultime sono costituite da:

ü Numero 2 lettori di codici a barre da installazione fissa (a colonnina)

ü Numero 1 display alfanumerico

ü Numero 1 barriera traffico

Tutte le periferiche sono dotate di elettronica di gestione e di schede di rete, per cui si

interfacciano con il server tramite cavi ethernet in cat 5.

Inoltre si prevede la presenza di un ulteriore calcolatore (di potenza inferiore al primo)

per l’utilizzo, da parte dell’operatore, come terminale di controllo da locale dell’intero

sistema.

Pagina: 18 di 37

Park on Line

4.2 Diagramma dei componenti Si passa alla descrizione infrastrutturale del sistema con uno schema che sarà

sicuramente utile in fase di cablaggio del sistema:

Pagina: 19 di 37

Park on Line

5 Analisi delle metriche funzionali (Rimmaudo)

Le metriche sono delle tecniche per misurare il sistema che si è sviluppato. Si dividono

in due categorie:

ü metriche di tipo funzionale ü metriche di tipo dimensionale.

Nelle metriche di tipo dimensionale si studia la dimensione del sistema vista come

dimensione del programma:

il numero di linee di codice: valutando in modo diverso il codice a seconda dello stile

di programmazione, del linguaggio scelto, dell’uso di commenti.

Nelle metriche di tipo funzionale, che sono più sofisticate, si ricava un indice che ci dà

le dimensioni del programma rispetto alla funzione che si deve svolgere. Questa è una

indicazione del numero di funzioni che il programma dovrà effettuare. Per fare questo

conto si definisce il metodo dei punti–funzione ( FP ). In particolare vengono

considerati i seguenti indici:

ü numero di input: numero di informazioni distinte fornite dall’utente, usate dal

programma come dati d’ingresso;

ü numero di output: numero di dati distinti che escono dal programma come

conseguenza degli input forniti;

ü numero di richieste: numero delle interrogazioni in linea che producono una

risposta immediata;

ü numero di file: numero di files creati o usati internamente dal programma

ü numero di interfacce esterne: numero di files o insiemi di dati forniti dal

programma ad altri programmi o all’utente.

Per effettuare il calcolo in base al nostro software, esaminiamo i requisiti richiesti dal

programma:

GESTIONE UTENTI PRENOTAZIONI PARCHEGGI

Pagina: 20 di 37

Park on Line

numero di input

numero di output

numero di richieste

numero di file

numero di interfacce esterne

GESTIONE

UTENTI 6 1 1 1 1

PRENOTAZIONI 5 1 1 1 1

PARCHEGGI 1 2 1 1 2

Con le tabelle seguenti si determina il valore dei (FP) e si ottiene un valore pesato di un

ciascun indice VP.

Gestione utenti

INDICI VALORI PESO

SEMPLICE PESO MEDIO

PESO COMPLESSO VP

n. input 6 3 4 6 18

n. output 1 4 5 7 5

n. richieste 1 3 4 6 4

n. file 1 7 10 15 10

n. interfacce 1 5 7 10 5

Prenotazioni

INDICI VALORI PESO

SEMPLICE PESO MEDIO

PESO COMPLESSO VP

n. input 5 3 4 6 15

n. output 1 4 5 7 5

n. richieste 1 3 4 6 4

n. file 1 7 10 15 10

n. interfacce 1 5 7 10 5

Pagina: 21 di 37

Park on Line

Parcheggi

INDICI VALORI PESO

SEMPLICE PESO MEDIO

PESO COMPLESSO VP

n. input 1 3 4 6 3

n. output 2 4 5 7 14

n. richieste 1 3 4 6 6

n. file 1 7 10 15 10

n. interfacce 2 5 7 10 10

Si determina il valore dei punti – funzione ( FP ) usando una tabella e dando dei pesi al

tipo di programma. Il peso dipende dal tipo di operazione, si ottiene un valore pesato di

un indice VP:

Il valore di FP viene poi ottenuto attraverso la seguente formula: FP = UFP * VFC dove: UFP = ∑i = 1…5 VP (Unadjusted Function Point) UFP = 42 (per gestione utenti); UFP = 39 (per gestione prenotazioni); UFP = 43 (per gestione parcheggi); VFC = 0.65 + 0.01 * ∑ i = 1...14 Fi (Volumetric Concentration Factor)

I valori Fi sono 14 parametri di aggiustamento che vengono calcolati in base al

questionario e ai valori (compresi tra 0 e 5) riportati in basso, a seconda dell'influenza

che il fattore i-esimo (i = 1...14) ha nello sviluppo del programma.

Gli Fi sono fattori di complessità del programma, che non riguardano tanto la funzionalità

(quella calcolata in UFP) quanto lo sforzo aggiuntivo che dovrà essere fatto per

rispondere ai 14 requisiti funzionali.

0 = ininfluente

1 = incidenza scarsa

2 = incidenza moderata

3 = incidenza media

4 = incidenza significativa

5 = essenziale

Pagina: 22 di 37

Park on Line

1. Il sistema richiede procedure di recovery e backup affidabili? 5 2. E' richiesta la trasmissione di dati? 4 3. Vi sono funzionalità che richiedono elaborazioni distribuite? 0 4. Le prestazioni sono critiche? 3 5. Il programma funzionerà in un ambiente operativo già pesantemente utilizzato?

0

6. Il sistema richiede funzionalità avanzate per l'emissione e la consultazione in linea di dati?

2

7. Le funzionalità di immissione dei dati devono essere costruite tramite interfacce a finestre?

5

8. Gli archivi principali sono aggiornati in tempo reale? 5 9. Le informazioni scambiate tra utente e programma sono complesse? 1 10. Il codice del programma è complesso? 3 11. Il codice è scritto per essere riusabile? 5 12. Nel progetto sono incluse anche le attività di installazione e conversione? 5 13. Il programma è stato progettato per essere installato presso diversi utenti?

1

14. Il programma è stato progettato per facilitare l'uso e le modifiche da parte dell'utente?

2

Si può considerare il valore di VFC lo stesso per quanto riguarda il conteggio degli altri

moduli del programma.

VFC = 0,65 + 0,01*(5+4+0+3+0+2+5+5+1+3+5+5+1+2) =1,06

Quindi : UFP = 42 + 39 + 43 = 124

VFC = 1,06

FP = 124 * 1,06 = 131,44

Essendo il nostro programma scritto in Java, la conversione per determinare una misura

delle linee di codice (LOC) sarà il prodotto per la costante 53:

LOC = 131,44 * 53 = 6.966

Le linee di codice previste saranno circa 7.000

Pagina: 23 di 37

Park on Line

6 Progettazione (Rimmaudo – Sgarlata)

OBIETTIVO DELLA PROGETTAZIONE: produrre SW dotato delle caratteristiche di

qualità ponendo la massima attenzione su AFFIDABILITÀ, MODIFICABILITÀ, COMPRENSIBILITÀ e RIUSABILITÀ, il che vuol dire minori costi e maggiore qualità:

AFFIDABILITÀ elemento sostanziale soprattutto per applicazioni in tempo reale e

sistemi critici. Una buona progettazione aumenta l'affidabilità in quanto fa si che la

codifica rispecchi interamente quanto espresso dalle specifiche anche in termini di

consistenza, completezza.

MODIFICABILITÀ il SW è sempre soggetto a modifiche ed il progetto deve tenere conto

di diversi fattori :

Cambiamenti nel sistema di calcolo: i prodotti validi hanno vita applicativa molto

lunga, perciò è facile che debbano esser portati su HW diversi ed appoggiarsi a Sistemi

Operativi differenti; la progettazione non deve quindi dipendere troppo da uno specifico ambiente operativo. COMPRENSIBILITÀ facilita i controlli di consistenza nei confronti delle specifiche ed il

passaggio alla codifica; inoltre un progetto comprensibile ed opportunamente

documentato può essere rivisto ed utilizzato anche da persone estranee alla sua

originaria stesura.

RIUSABILITÀ è uno degli scopi fondamentali di un buon processo di sviluppo del SW.

La riusabilità si ottiene a seconda del modo in cui viene operata la scomposizione del

sistema complessivo nei vari sottosistemi. Due i vantaggi principali della riusabilità :

1) Netta diminuzione di costi e tempi di produzione.

2) Maggiore affidabilità delle parti già sottoposte ad uso operativo rispetto a quelle

realizzate ex novo.

Obiettivo delle tecniche di riuso è ottenere un insieme di componenti elementari di alto

livello per generare comodamente applicazioni più complesse.

Nel diagramma delle classi, in seguito riportato, viene spiegata in dettaglio la struttura

del software, descrivendone le classi con i relativi attributi e metodi.

Pagina: 24 di 37

Park on Line

(Rimmaudo)

Pagina: 25 di 37

Park on Line

Diagrammi delle attività

Seguono adesso una serie di diagrammi di attività che descrivono il comportamento del

sistema nei diversi possibili scenari.

ü Prenotazione e disdetta posto parcheggio tramite WEB;

ü Prenotazione e disdetta posto parcheggio al botteghino;

ü Attività di entrata/uscita dal parcheggio senza l'ausilio di operatore del

botteghino;

ü Attività di entrata nel parcheggio tramite operatore del botteghino;

ü Attività di uscita dal parcheggio tramite operatore del botteghino.

Pagina: 26 di 37

Park on Line

(Rimmaudo)

Pagina: 27 di 37

Park on Line

(Sgarlata)

Pagina: 28 di 37

Park on Line

(Rimmaudo)

Pagina: 29 di 37

Park on Line

(Sgarlata)

Pagina: 30 di 37

Park on Line

(Sgarlata)

Pagina: 31 di 37

Park on Line

(Sgarlata)

Diagramma di macchina a stati e di sequenza

Per una più chiara esposizione ed immediata comprensione del funzionamento in

automatico del sistema tramite prenotazione WEB scegliendo la modalità di pagamento

con carta di credito (modalità “target” prevalente del sistema) si forniscono anche un

diagramma di macchina a stati e un diagramma di sequenza.

Un ulteriore diagramma di sequenza viene fornito per la modalità di pagamento al

botteghino.

Pagina: 32 di 37

Park on Line

(Rimmaudo)

Pagina: 33 di 37

Park on Line

(Rimmaudo)

Pagina: 34 di 37

Park on Line

7 Sviluppo e collaudo (Rimmaudo – Sgarlata)

Per l’attività di sviluppo e collaudo abbiamo assemblato un prototipo dell’hardware del

sistema PARK on LINE dopo aver testato il corretto funzionamento di ogni singola unità

(Lettore codice a barre, display alfanumerico, etc.).

Questo ha consentito un’attività ottimale di sviluppo del software poiché si sono potute

alternare fasi di testing durante la sua evoluzione.

I test sono stati condotti simulando tutti i vari possibili scenari d’uso propri e impropri al

fine di testarne la robustezza funzionale.

Il collaudo è stato eseguito dagli stessi programmatori dell'azienda.

Il software prodotto per il collaudo è stato arricchito di istruzioni di controllo a run-time

che hanno facilitano il rilevamento degli errori. Esempi di tali istruzioni sono:

ü il controllo che non si acceda a indici non validi di array;

ü il controllo che tutta la memoria allocata venga disallocata prima della

terminazione;

In alcuni casi, è stato utilizzato un ambiente hardware di esecuzione che supporta

specificatamente il debugging e il testing.

Pagina: 35 di 37

Park on Line

8 Installazione Manutenzione (Rimmaudo – Sgarlata)

L’installazione del software verrà effettuata dopo aver completato l’assemblaggio,

presso il sito del cliente, dell’hardware. Queste operazioni saranno effettuate dai

programmatori dell’azienda che svolgono pure mansioni da sistemista hardware. Prima

di consegnare l’impianto al cliente si procederà all’effettuazione del collaudo, in loco, di

tutte le funzionalità del sistema.

La fase di manutenzione comprende tutte le attività di modifica del software successive

al suo rilascio presso il cliente o la sua immissione sul mercato. Queste attività possono

essere volte a correggere errori del software, adattarlo a nuovi ambienti operativi, o

estenderne le funzionalità.

La manutenzione incide sui costi, si stima che il 60% dei costi dipende dalla

manutenzione. Infatti, ogni modifica al software comporta necessariamente l’esecuzione

di nuovi test, sia relativi alle nuove funzionalità eventualmente introdotte, sia mirati a

verificare che le modifiche apportate non abbiano compresso funzionalità preesistenti.

Pagina: 36 di 37

Park on Line

BIBLIOGRAFIA Prof. Giuseppe Scollo – Dispense del corso Ingegneria del Software 1 – Università degli

studi - Catania

Roger. S. Pressman – Principi di ingegneria del software – McGraw-Hill

Martin Fowler – UML Distilled (Third Edition)

SITI INTERNET Guida utente Sparx Systems - http://www.sparxsystems.com/bin/EAUserGuide.pdf

Program. HTML – Guida UML - http://programmazione.html.it/guide/leggi/41/guida-uml/

Analisi-disegno.com - http://www.analisi-disegno.com/uml/uml.htm

ArgoUml - www.argouml.tigris.org

www.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/gamel/cocomo.html

http://fmt.isti.cnr.it/~gnesi/matdid/metriche.pdf

http://giove.isti.cnr.it/mondo-digitale.pdf

www.wikipedia.org

www.google.com

TOOL USATO PER I DIAGRAMMI UML Enterprise Architect v.6.5 - http://www.sparxsystems.com/bin/easetup.exe

Pagina: 37 di 37

Park on Line