Page 1

Pagina: 1 di 37

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

Anno Accademico 2006-2007


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

3.4 4

E TEMPI DI REALIZZAZIONE ........................................................................14

3.3.1

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

3.3.2

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

CONSIDERAZIONI ...................................................................................................................16 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 (betatesters) 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

numero

di

di

output

richieste

6

1

PRENOTAZIONI 5 PARCHEGGI

numero di input GESTIONE UTENTI

1

numero di

numero di

file

interfacce esterne

1

1

1

1

1

1

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

PESO

PESO

PESO

INDICI

VALORI

SEMPLICE

MEDIO

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

PESO

PESO

PESO

Prenotazioni

INDICI

VALORI

SEMPLICE

MEDIO

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 PESO

PESO

PESO

INDICI

VALORI

SEMPLICE

MEDIO

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? 2. E' richiesta la trasmissione di dati? 3. Vi sono funzionalità che richiedono elaborazioni distribuite? 4. Le prestazioni sono critiche? 5. Il programma funzionerà in un ambiente operativo già pesantemente utilizzato? 6. Il sistema richiede funzionalità avanzate per l'emissione e la consultazione in linea di dati? 7. Le funzionalità di immissione dei dati devono essere costruite tramite interfacce a finestre? 8. Gli archivi principali sono aggiornati in tempo reale? 9. Le informazioni scambiate tra utente e programma sono complesse? 10. Il codice del programma è complesso? 11. Il codice è scritto per essere riusabile? 12. Nel progetto sono incluse anche le attività di installazione e conversione? 13. Il programma è stato progettato per essere installato presso diversi utenti? 14. Il programma è stato progettato per facilitare l'uso e le modifiche da parte dell'utente?

5 4 0 3 0 2 5 5 1 3 5 5 1 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

Tesi - Progettazione di un sistema informatizzato per la gestione funzionale di un parcheggio a paga  

Tesina di Ingegneria del Software I e II Corso di Ingegneria del Software Prof. Giuseppe Scollo Anno Accademico 2006-2007 A cura di Daniele...

Read more
Read more
Similar to
Popular now
Just for you