SaniSystem_stampa

Università degli studi di Pisa

FACOLTA’ DI INGEGNERIA

Corso di laurea magistrale in

Ingegneria Informatica per la Gestione d’Azienda

Progetto di Gestione della Qualità

Docente:

Gigliola Vaglini

Autori:

Giacomo Migliorini

Giacomo Mucci

Mirko Nigi

Anno Accademico 2010-2011

2

Sommario

1. Introduzione .............................................................................................................................. 5

1.1 Obiettivo .................................................................................................................................. 5

1.2 Scopo ....................................................................................................................................... 5

1.3 Glossario .................................................................................................................................. 5

1.4 Overview .................................................................................................................................. 7

2. Descrizione generale ................................................................................................................. 8

2.1 Prospettiva del prodotto ......................................................................................................... 8

2.2 Funzionalità del prodotto ........................................................................................................ 8

2.3 Caratteristiche dell’utente ....................................................................................................... 8

2.4 Vincoli generali ........................................................................................................................ 8

3. Specifica dei requisiti ................................................................................................................ 9

3.1 Presentazione .................................................................................................................... 9

3.2 Attori .................................................................................................................................. 9

3.2.1 ASL ................................................................................................................................... 10

3.2.2 Farmacista ........................................................................................................................ 10

3.2.3 Laboratorio ...................................................................................................................... 11

3.2.4 Medico ............................................................................................................................. 11

3.2.5 Medico di famiglia ........................................................................................................... 12

3.2.6 Medico libero professionista ........................................................................................... 12

3.2.7 Paziente ........................................................................................................................... 12

3.3 Casi d’uso ......................................................................................................................... 13

3.3.1 Diagramma dei casi d’uso ................................................................................................ 13

3.3.2 Specifiche dei casi d’uso .................................................................................................. 14

3.4 Requisiti non funzionali ................................................................................................... 23

4. Relazione di progetto .............................................................................................................. 24

4.1 Diagramma delle classi .................................................................................................... 25

4.2 Diagrammi di sequenza ................................................................................................... 26

4.2.1 AllegareEsame ................................................................................................................. 26

4.2.2 AllegareRicetta ................................................................................................................. 26

3

4.2.3 CompilazioneRicetta ........................................................................................................ 27

4.2.4 ConvenzionaMedico ........................................................................................................ 27

4.2.5 CreaCartellaClinica ........................................................................................................... 28

4.2.6 Login ................................................................................................................................. 28

4.2.7 RegistrazioneSistema ....................................................................................................... 29

4.2.8 RicercaEsame ................................................................................................................... 29

4.2.9 RicercaProfiloPaziente ..................................................................................................... 30

4.2.10 RicercaRicettaAttiva ..................................................................................................... 30

4.2.11 ScegliMedico .................................................................................................................. 31

4.3 Prototipo ................................................................................................................................ 31

5. Piano di processo .................................................................................................................... 34

5.1. Diagramma di Gantt ........................................................................................................ 35

5.2. Diagramma di PERT .......................................................................................................... 36

6. Valutazione dello sforzo .......................................................................................................... 37

6.1. Analisi dei Function Point ................................................................................................ 37

6.2. Calcolo dei Function Point ............................................................................................... 39

6.2.1. Complessità degli EI (External Input) ........................................................................... 39

6.2.2. Complessità degli OE (External Output) ...................................................................... 40

6.2.3. Complessità degli EQ (External Queries) ..................................................................... 41

6.2.4. Complessità degli EIF e degli ILF .................................................................................. 41

6.3. Calcolo dei fattori di aggiustamento ............................................................................... 42

6.4. Calcolo FP e Loc ............................................................................................................... 42

6.5. Analisi CoCoMo ................................................................................................................ 43

6.6. Scale Driver ...................................................................................................................... 43

6.7. Wizard Cost Driver ........................................................................................................... 44

6.8. Risultati Costar 7.0 ........................................................................................................... 46

6.9. Conclusioni dell’analisi CoCoMo ...................................................................................... 51

7. Piano di qualità........................................................................................................................ 52

7.1. Modello ISO 9126 ............................................................................................................ 52

7.1.1. Qualità interna ed esterna ........................................................................................... 52

7.1.1.1. Funzionalità .............................................................................................................. 55

7.1.1.2. Affidabilità ................................................................................................................ 56

4

7.1.1.3. Usabilità .................................................................................................................... 56

7.1.1.4. Efficienza .................................................................................................................. 57

7.1.1.5. Manutenibilità .......................................................................................................... 57

7.1.1.6. Portabilità ................................................................................................................. 58

7.1.1.7. Sviluppi futuri ........................................................................................................... 58

7.2. Modello ISO 12207 .......................................................................................................... 59

7.2.1 Processi primari ............................................................................................................... 59

7.2.2 Processi di supporto ........................................................................................................ 60

7.2.3 Processi organizzativi ....................................................................................................... 60

8. Test del prodotto .................................................................................................................... 61

8.1 Test Design Specification ................................................................................................. 61

8.2 Test Case Specification .................................................................................................... 61

8.2.1 RicercaProfiloPaziente .............................................................................................. 62

8.2.2 Login ......................................................................................................................... 62

8.2.3 RegistrazioneSistema ............................................................................................... 63

8.2.4 CompilazioneRicetta ................................................................................................. 63

8.2.5 AllegareRicetta ......................................................................................................... 64

8.2.6 AllegareEsame .......................................................................................................... 64

8.2.7 CreaCartellaClinica ................................................................................................... 64

8.2.8 RicercaRicettaAttiva ................................................................................................. 65

8.2.9 RicercaEsame ............................................................................................................ 65

8.2.10 InoltraRichiestaRimborso ......................................................................................... 66

8.2.11 ConvezionaMedico ................................................................................................... 66

8.2.12 ScegliMedico............................................................................................................. 67

9. Diario di gruppo ...................................................................................................................... 68

10. Diari individuali .................................................................................................................... 73

10.1. Nigi Mirko – PM ............................................................................................................... 73

10.2. Migliorini Giacomo – QE .................................................................................................. 75

10.3. Mucci Giacomo – TS & L .................................................................................................. 76

5

1. Introduzione

1.1 Obiettivo

L’obiettivo della progettazione documentata è quella di realizzare un sistema per la

gestione elettronica delle ricette mediche. Il sistema si chiamerà “SaniSystem” e verrà

prodotto pensando ad una utenza con poca dimestichezza con il lavoro ai PC, quindi

realizzando una interfaccia grafica più intuitiva possibile.

1.2 Scopo

La documentazione presentata è stata redatta con l’obiettivo di presentare in maniera

dettagliata tutti i requisiti e le relative idee di progettazione seguite per la realizzazione del

prodotto.

Inoltre la documentazione rispetterà gli attributi di qualità descritti nello standard SRS.

1.3 Glossario

Termine Definizione

Medico Il medico è il professionista che si occupa della

salute umana, prevenendo, diagnosticando e

curando le malattie.

Ricetta

Prescrizione scritta di una o più sostanze

medicinali con l'indicazione delle modalità di

somministrazione, o di un esame, rilasciata da

un medico.

Paziente

Un paziente è una persona che si rivolge ad un

medico o ad una struttura di assistenza

sanitaria per accertamenti o problemi di

salute.

Tessera sanitaria La Tessera Sanitaria è una tessera personale

6

che ha sostituito il tesserino plastificato del

codice fiscale per tutti i cittadini italiani aventi

diritto alle prestazioni del Servizio Sanitario

Nazionale (SSN) e muniti di codice fiscale.

Farmacista

Il farmacista è il professionista che si occupa

della corretta dispensazione dei medicamenti

e che, disponendo di una profonda

preparazione scientifica è autorizzato a

preparare nella loro forma farmaceutica, a

fabbricare e controllare i farmaci (secondo

Farmacopea), nonché a consigliare in materia

di farmaci e a svolgere educazione sanitaria

presso la popolazione.

ASL

Azienda Sanitaria Locale, in passato chiamata

USL (Unità Sanitaria Locale) : era stata

chiamata così l'associazione di un certo

numero di comuni per la gestione democratica

dei servizi.

Laboratorio di analisi

Un laboratorio di analisi è un particolare

laboratorio chimico dove vengono effettuate

misure su materiali e sostanze, allo scopo di

produrre un referto che attesti le

caratteristiche dell'oggetto dell'analisi.

Farmaco Sostanza usata per trattare, prevenire o

diagnosticare una malattia.

Patologia Malattia, stato morboso.

Esenzione Ipotesi in cui, in presenza di determinati

presupposti di legge, la tassa non è dovuta

Prescrizione Sinonimo di Ricetta.

Convenzione Una convenzione è un accordo tra due o più

7

soggetti (persone fisiche, enti, stati ecc.) con il

quale gli stessi regolano questioni di comune

interesse.

Ticket Il ticket (dall'inglese: biglietto) indica il costo

associato ad una prestazione del Servizio

Sanitario Nazionale.

Cartella clinica

La cartella clinica è un insieme di documenti

nei quali viene registrato dai medici un

complesso di informazioni concernenti un

determinato paziente allo scopo di poterne

rilevare ciò che lo riguarda in senso

diagnostico-terapeutico anche in tempi

successivi.

1.4 Overview

La presente documentazione è redatto nel seguente modo: in prima istanza è stato stilato

una accurata analisi dei requisiti presentati dal committente, che saranno integrati da altri

requisiti che il gruppo di lavoro riterrà necessario inserire per lo sviluppo del prodotto.

Successivamente sarà redatta la valutazione dei costi che lo sviluppo del prodotto

comporterà, sia in termini di costi monetari che in costi temporali.

La documentazione presenterà anche le scelte riguardo i modelli dei processi di sviluppo,

la pianificazione del lavoro, i piani di qualità e i piani di testing del prodotto.

Al termine della documentazione sarà presentato anche un diario del gruppo di lavoro

riportante le attività svolte lungo il tempo di progettazione e redazione del presente

documento.

8

2. Descrizione generale

2.1 Prospettiva del prodotto

SaniSystem è un sistema indipendente e self-contained, quindi non è possibile avere

confronti con prodotti simili.

2.2 Funzionalità del prodotto

Il sistema SaniSystem consente di gestire elettronicamente le ricette mediche tramite la

tessera sanitaria. Il medico compilerà la ricetta tramite SaniSystem ed il paziente potrà

ritirare i farmaci in farmacia presentando esclusivamente la propria tessera sanitaria. Il

farmacista, dopo aver verificato le ricette attive del paziente, potrà inoltrare la richiesta di

pagamento alla ASL di competenza nel caso in cui il paziente sia esente dal pagamento del

ticket.

Il sistema SaniSystem consente inoltre di automatizzare anche esami medici presso i

laboratori di analisi convenzionati. Anche in questo caso tutte le informazioni saranno

disponibili soltanto con la presentazione della tessera sanitaria del paziente.

2.3 Caratteristiche dell’utente

Nella progettazione del prodotto verrà fatta l’ipotesi che l’utente del sistema non abbia

alcun tipo di esperienza con dei sistemi di gestione elettronica, né capacità tecniche.

2.4 Vincoli generali

Nella progettazione del prodotto saranno rispettati i seguenti vincoli:

nessuna dipendenza con i sistemi operativi sottostanti

tempi di risposta minimi

ogni operazione sarà eseguita in maniera sicura e indivisibile

possibilità di cambiamento del database sottostante

9

3. Specifica dei requisiti

3.1 Presentazione

Il sistema SaniSystem consente di gestire elettronicamente le ricette mediche tramite la

tessera sanitaria. Il medico compilerà la ricetta tramite SaniSystem ed il paziente potrà ritirare

i farmaci in farmacia presentando esclusivamente la propria tessera sanitaria. Il farmacista,

dopo aver verificato le ricette attive del paziente, potrà inoltrare la richiesta di pagamento alla

ASL di competenza nel caso in cui il paziente sia esente dal pagamento del ticket.

Il sistema SaniSystem consente inoltre di automatizzare anche esami medici presso i

laboratori di analisi convenzionati. Anche in questo caso tutte le informazioni saranno

disponibili soltanto con la presentazione della tessera sanitaria del paziente.

3.2 Attori

Nella seguente tabella sono riportati tutti gli attori che interagiscono con SaniSystem con i

rispettivi ruoli:

Attori Ruolo

ASL Istituto che controlla medici e pazienti nella propria zona di

appartenenza

Farmacista Persona che vende i medicinali prescritti al Paziente

Laboratorio Entità in cui vengono gli svolti gli esami sul Paziente

Medico Persona che visita un Paziente

Medico convenzionato

ASL

Medico con convenzione ASL, prescrive medicinali a carico

dell’ASL o del paziente

Medico di Famiglia Medico assegnato ad una famiglia di Pazienti

Medico libero

professionista

Medico senza convenzione ASL, prescrive medicinali

esclusivamente a carico del Paziente

Paziente Cliente del sistema

Nei seguenti paragrafi verranno analizzati gli attributi e le attività di ciascun attore.

10

3.2.1 ASL

Per registrarsi a SaniSystem è necessario che le ASL forniscano le seguenti informazioni:

ID_ASL (*)

Password

Indirizzo mail

Area di competenza

(*) Al momento della registrazione l’attributo ID_ASL verrà generato automaticamente in

maniera univoca.

Per effettuare il Login sarà necessario inserire nel sistema username e password, ed in

questo modo ogni ASL sarà in grado di effettuare le seguenti operazioni:

Consultare i profili di ogni paziente registrato.

Stabilire convenzioni con qualunque medico residente nel territorio di sua

competenza.

3.2.2 Farmacista

Per registrarsi a SaniSystem è necessario che ogni farmacista fornisca le seguenti

informazioni:

ID_Farmacia (*)

Password

Indirizzo mail

Nome Farmacia

Indirizzo Farmacia

(*) Al momento della registrazione l’attributo ID_Farmacia verrà generato

automaticamente in maniera univoca.

Per effettuare il Login sarà necessario inserire nel sistema username e password inseriti al

momento della registrazione, in questo modo ogni farmacista sarà in grado di effettuare le

seguenti operazioni:


11

Ricerca di una ricetta attiva.

Inoltro di richieste di pagamento alla ASL di competenza nel caso in cui il paziente

risulti esente dal pagamento del ticket.

3.2.3 Laboratorio

Per registrarsi a SaniSystem è necessario che ogni laboratorio di analisi fornisca le

seguenti informazioni:

ID_Laboratorio (*)

Password

Indirizzo mail

Nome Laboratorio

Indirizzo

(*) Al momento della registrazione l’attributo ID_Laboratorio verrà generato



momento della registrazione, in questo modo ogni laboratorio di analisi sarà in grado di

effettuare le seguenti operazioni:


Ricerca di una prescrizione d’esame attiva.

Inoltro di richieste di pagamento alla ASL di competenza nel caso in cui il paziente

risulti esente dal pagamento del ticket.

3.2.4 Medico

Per registrarsi a SaniSystem è necessario che ogni medico fornisca le seguenti

informazioni:

ID_Medico (*)

Password

Nome

Cognome

Indirizzo mail

12

Indirizzo

(*) Al momento della registrazione l’attributo ID_Medico verrà generato



momento della registrazione, in questo modo ogni medico sarà in grado di effettuare le

seguenti operazioni:

Compilazione di una ricetta

Collegamento di una nuova ricetta al profilo di un paziente

Collegamento di una nuova esame al profilo di un paziente

3.2.5 Medico di famiglia

Il medico di famiglia è un medico che è in grado di effettuare le seguenti operazioni:

Creazione di una cartella clinica di un paziente

Prescrizione di ricette e/o esami con pagamento a carico della ASL di competenza nel

caso in cui il paziente risulti esente dal pagamento di ticket

3.2.6 Medico libero professionista

Il medico che svolge la propria attività come libero professionista non è in grado di

svolgere funzioni aggiuntive (oltre a quelle di medico) sul sistema SaniSystem.

3.2.7 Paziente

Per registrarsi a SaniSystem è necessario che ogni paziente fornisca le seguenti

informazioni:

Numero tessera sanitaria

Password

Nome

Cognome

Indirizzo mail

Indirizzo di residenza

13

Per effettuare il Login sarà necessario inserire nel sistema il numero della tessera sanitaria

e la password inserita al momento della registrazione, in questo modo ogni paziente sarà in

grado di effettuare le seguenti operazioni:

Scelta del medico di famiglia

3.3 Casi d’uso

3.3.1 Diagramma dei casi d’uso

14

3.3.2 Specifiche dei casi d’uso

Di seguito sono riportate le specifiche dei casi d’uso del sistema:

Caso d’uso RicercaProfiloPaziente

Use Case ID UC1

Brief Description Gli attori ricercano un profilo paziente all’interno del sistema

Primary Actor(s) Farmacista, Laboratorio, ASL

Secondary

Actor(s)

Nessuno

Precondition(s) 1. Gli attori si loggano al sistema

Main Flow 1. Il caso d’uso inizia quando si seleziona “Ricerca Paziente”

2. Il sistema cerca il profilo del paziente selezionato

3. IF il sistema trova il profilo del paziente

3.1. RETURN true

4. ELSE

4.1. RETURN false

Postcondition(s) 1. Il sistema dice se ha trovato il profilo del paziente

Alternative

Flow(s)

Nessuno

15

Caso d’uso Login

Use Case ID UC2

Brief Description Gli attori si loggano all’interno del sistema

Primary Actor(s) Medico, Farmacista, Laboratorio, ASL, Paziente

Secondary Actor(s) Nessuno

Precondition(s) Gli attori non sono loggati al sistema

Main Flow

1. Il caso d'uso inizia quando gli attori selezionano "Login".

2. Gli attori inseriscono il proprio username e la propria password.

3. IF (il sistema non riconosce i dati inseriti)

3.1. Il sistema informa gli attori della non correttezza dei dati.

4. ELSE

4.1. Il sistema informa che l'accesso è avvenuto con successo.

Postcondition(s) 1. Gli attori sono loggati al sistema

Alternative Flow(s) Nessuno

Caso d’uso RegistrazioneSistema

Use Case ID UC3

Brief Description Gli attori si registrano nel sistema

Primary Actor(s) Medico, Farmacista, Laboratorio, ASL, Paziente


Precondition(s) Nessuno

Main Flow 1. Il caso d’uso inizia quando gli attori selezionano “Registrati”

2. DO il sistema chiede le informazioni obbligatorie all’attore

3. L’attore inserisce le informazioni

4. WHILE le informazioni inserite non sono valide

5. Il sistema crea l’account dell’attore

Postcondition(s) 1. Un nuovo account è stato creato per l’attore


16

Caso d’uso CompilazioneRicetta

Use Case ID UC4

Brief Description Medico compila una ricetta a un paziente

Primary Actor(s) Medico


Precondition(s) 1. Il Medico sta visualizzando la cartella clinica del paziente

Main Flow 1. Il caso d’uso inizia quando il Medico seleziona CompilaRicetta

2. Il Medico inserisce i dati necessari alla compilazione della ricetta

3. IF (il sistema non riconosce i dati inseriti)

3.1. Il sistema informa il Medico della non correttezza dei dati.

4. ELSE

4.1. Il sistema informa che la compilazione della ricetta è avvenuta

con successo.

Postcondition(s) 1. La ricetta viene salvata all’interno del sistema


Caso d’uso AllegareRicetta

Use Case ID UC5

Brief Description Medico allega una ricetta alla cartella clinica del paziente



Precondition(s) 1. Il Medico sta visualizzando la cartella clinica del paziente

Main Flow

1. Il caso d’uso inizia quando il Medico seleziona AllegaRicetta

2. include(CompilaRicetta)

3. Il sistema allega la ricetta al paziente

Postcondition(s) 1. Una nuova ricetta è stata allegata alla cartella clinica del paziente


17

Caso d’uso AllegareEsame

Use Case ID UC6

Brief Description Medico allega una nuova richiesta di esame alla cartella clinica

del paziente.



Precondition(s) 1. Il Medico sta visualizzando la cartella clinica del paziente.

Main Flow 1. Il caso d’uso inizia quando il Medico seleziona AllegaEsame.

2. Il Medico inserisce i dati necessari alla compilazione della richiesta

di esame.

3. IF (il sistema non riconosce i dati inseriti).


4. ELSE

5. Il sistema informa che la compilazione della richiesta di esame è

avvenuta con successo.

Postcondition(s) 1. Una nuova richiesta di esame è stata allegata alla cartella clinica del

paziente.


18

Caso d’uso CreaCartellaClinica

Use Case ID UC7

Brief Description Il MedicoDiFamiglia crea la cartella clinica del paziente

Primary Actor(s) MedicoDiFamiglia


Precondition(s) 1. Il Medico sta visualizzando i dati del paziente.

Main Flow 1. Il caso d’uso inizia quando il MedicoDiFamiglia seleziona

CreaCartellaClinica

2. Il Medico inserisce i dati necessari alla creazione della cartella

clinica.



4. ELSE

5. Il sistema informa che la compilazione della cartella clinica è

avvenuta con successo.

Postcondition(s) 1. E’ stata creata la cartella clinica del paziente


19

Caso d’uso RicercaRicettaAttiva

Use Case ID UC8

Brief Description Il Farmacista ricerca una ricetta attiva all’interno del sistema

Primary Actor(s) Farmacista


Precondition(s) 1. Il Farmacista è loggato all’interno del sistema

Main Flow 1. Il caso d’uso inizia quando il Farmacista seleziona

RicercaRicettaAttiva

2. Il Farmacista inserisce i dati del cliente

3. Il sistema cerca le ricette attive allegate alla cartella clinica del

paziente

4. Extension point <InoltraRichiestaRimborso>

Postcondition(s) 1. Il sistema restituisce le ricette attive allegate alla cartella clinica del

paziente


20

Caso d’uso RicercaEsame

Use Case ID UC9

Brief Description Il LaboratorioDiAnalisi ricerca una richiesta di esame all’interno

del sistema.

Primary Actor(s) LaboratorioDiAnalisi


Precondition(s) 1. Il LaboratorioDiAnalisi è loggato all’interno del sistema.

Main Flow 1. Il caso d’uso inizia quando il LaboratorioDiAnalisi seleziona

RicercaEsame

2. Il LaboratorioDiAnalisi inserisce i dati del cliente.

3. Il sistema cerca le richiste di esame allegate alla cartella clinica del

paziente.

4. Extension point <InoltraRichiestaRimborso>

Postcondition(s) 1. Il sistema restituisce le richieste di esame allegate alla cartella

clinica del paziente.


Caso d’uso InoltraRichiestaRimborso

Use Case ID UC10

Brief Description Gli attori inoltrano una richiesta di rimborso alla ASL

Primary Actor(s) Farmacista, LaboratorioDiAnalisi


Precondition(s) 1. Gli attori hanno visualizzato una ricetta o una richiesta di esame

Main Flow 1. Il caso d’uso inizia quando gli attori selezionano

InoltraRichiestaRimborso.

2. Il sistema invia la richiesta di rimborso all’ASL

Postcondition(s) 1. La richiesta di rimborso è stata inviata alla ASL


21

Caso d’uso ConvenzionaMedico

Use Case ID UC11

Brief Description L’ASL stabilisce una convenzione con un Medico residente nel suo

territorio di competenza.

Primary Actor(s) ASL


Precondition(s) 1. L’ASL è loggata al sistema

Main Flow 1. Il caso d’uso inizia quando l’ASL seleziona ConvenzionaMedico.

2. L’ASL inserisce i dati del Medico con cui stabilire la convenzione.


3.1. Il sistema informa l’ASL della non correttezza dei dati.

4. ELSE

5. Il sistema informa che la convenzione con il Medico è stata stabilita.

Postcondition(s) 1. L’ASL ha stabilito una convenzione con un Medico residente nel suo

territorio di competenza.


22

Caso d’uso ScegliMedico

Use Case ID UC12

Brief Description Il Paziente sceglie come medico di famiglia un qualunque medico

convenzionato con la sua ASL di appartenenza.

Primary Actor(s) Paziente


Precondition(s) 1. Il paziente è loggato al sistema

Main Flow 1. Il caso d’uso inizia quando il Paziente seleziona ScegliMedico.

2. Il Paziente inserisce i dati del Medico da scegliere come medico di

famiglia.


3.1. Il sistema informa il Paziente della non correttezza dei dati.

4. ELSE

5. Il sistema informa che il medico di cui sono stati inseriti i dati è

stato scelto come medico di famiglia del Paziente.

Postcondition(s) 1. Il Paziente ha scelto il medico di cui ha inserito i dati come medico

di famiglia.


23

3.4 Requisiti non funzionali

Nei precedenti paragrafi è stato descritto cosa il sistema deve fare, ovvero i requisiti

funzionali. I requisiti non funzionali rappresentano le caratteristiche del sistema che non

interessano direttamente l’utente, ovvero rappresentano come il sistema funziona.

I requisiti non funzionali possono essere suddivisi in:

Requisiti interni, ovvero quelli incorporati nella struttura del sistema software

Requisiti esterni, ovvero quelli osservabili a tempo di esecuzione.

Manutenibilità: deve essere possibile effettuare operazioni di modifica al sistema per

eliminare eventuali errori e/o per migliorare la qualità del software. Questo

requisito risulta importante nel caso in cui in futuro nasca l’esigenza di

introdurre nuove funzionalità.

Usabilità: il sistema è pensato per una vasta fascia di utenti, quindi il suo utilizzo deve

risultare semplice anche a coloro che non hanno un’elevata dimestichezza con le

tecnologie informatiche.

Robustezza: nel caso in cui si verifichino situazioni non previste dalle specifiche (dati di input

non corretti, carico di lavoro elevato, etc) il sistema deve essere in grado di

tornare in uno stato consistente.

Sicurezza: devono essere stabilite politiche di controllo degli accessi, in modo che l’utente

possa accedere soli ai servizi di sua competenza. Poiché SaniSystem manipola dati

altamente personali è stato deciso di consentire l’accesso al sistema tramite un

username ed una password per tutti gli attori. Inoltre il numero della tessera

sanitaria di ciascun paziente costituisce già un dato che difficilmente può venire

nelle mani di una terza persona malintenzionata che voglia violare la privacy di un

paziente.

Integrità: è necessario minimizzare il rischio di alterazione dei dati durante la loro

trasmissione e memorizzazione.

24

4. Relazione di progetto

Ogni Medico deve innanzitutto registrarsi a SaniSystem inserendo i propri dati anagrafici ed il

suo indirizzo di residenza in modo tale che possa stabilire una convenzione con la ASL della

zona. Una volta stabilita una convenzione, un MedicoLiberoProfessionista può essere scelto da

un Paziente come suo MedicoDiFamiglia. Quest’ultimo ha la possibilità di prescrivere ricette o

richieste di esami con il pagamento del ticket a carico della ASL di competenza nel caso in cui il

Paziente abbia diritto all’esenzione. Il MedicoDiFamiglia invierà alla ASL la patologia riscontrata

nel paziente, quindi la ASL inserirà nel campo TipoEsenzione il codice corrispondente alla

patologia o alla particolare situazione (gravidanza, reddito basso, etc.) per cui paziente ha

diritto all’esenzione del ticket. Nel database del sistema ci sarà una tabella in cui c’è una

corrispondenza fra le diverse patologie ed il tipo di medicinali che servono per curarle. Quando

un Paziente si recherà in Farmacia per ritirare il medicinale di cui necessita, il farmacista

visualizzerà le ricette attive nella cartella clinica del paziente ed il sistema verificherà

automaticamente (collegandosi al database) se il medicinale dev’essere pagato dal Paziente,

oppure se dev’essere inviata una richiesta di pagamento ticket alla ASL di competenza. La

stessa verifica viene fatta dal Laboratorio per quanto riguarda le richieste di Esami.

Per poter utilizzare SaniSystem è necessario che ogni utente effettui la registrazione inserendo

i parametri descritti nel paragrafo 1.2, in particolare è richiesto l’inserimento di una password

per ogni utente per garantire la sicurezza e la privacy dei pazienti.

Nei seguenti paragrafi le funzionalità di SaniSystem sono descritte attraverso i seguenti

diagrammi UML:

Diagramma delle classi

Diagrammi di sequenza

25

4.1 Diagramma delle classi

Nella seguente figura è riportato il diagramma delle classi.

26

4.2 Diagrammi di sequenza

Nei seguenti paragrafi sono riportati i diagrammi di sequenza, i quali illustrano le interazioni

dei vari attori con le varie classi attraverso le opportune funzioni.

4.2.1 AllegareEsame

4.2.2 AllegareRicetta

27

4.2.3 CompilazioneRicetta

4.2.4 ConvenzionaMedico

28

4.2.5 CreaCartellaClinica

4.2.6 Login

29

4.2.7 RegistrazioneSistema

4.2.8 RicercaEsame

30

4.2.9 RicercaProfiloPaziente

4.2.10 RicercaRicettaAttiva

31

4.2.11 ScegliMedico

4.3 Prototipo

Nel seguente paragrafo sono illustrate alcune schermate del sistema in modo tale da poter

fornire al committente un’idea di come verranno realizzate le interfacce.

Di seguito è mostrata la schermata iniziale che viene visualizzata all’apertura di SaniSystem:

32

La seguente immagine mostra la schermata che viene visualizzata per poter effettuare la

registrazione al sistema.

Di seguito è mostratala schermata che il sistema mostra quando un laboratorio di analisi

ricerca il tipo di analisi sono state prescritte dal medico al paziente.

33

Quando una ASL deve convenzionare un medico in modo tale che esso possa diventare un

medico di famiglia, visualizzerà la schermata riportata nell’immagine sottostante.

34

5. Piano di processo

La scelta di un modello di processo è una fase fondamentale nella creazione di un software,

infatti esso determina le fasi e specifica le regole principali che il processo dovrà seguire.

Il processo di sviluppo software è il modo in cui viene organizzato e praticato lo sviluppo dei

sistemi. Esso è legato alle relazioni cliente-fornitore, all’assetto organizzativo dell’IT e al

sistema di gestione delle risorse umane. Modificare un processo di sviluppo esistente, senza

tenere conto delle sue relazioni con questi aspetti, causa problemi. Quindi l’innovazione di

processo va sempre effettuata facendo i conti con il conteso relazionale ed organizzativo in cui

avviene lo sviluppo.

Gli strumenti utilizzati per il piano di processo sono:

Diagramma di Gantt

Diagramma di Pert

35

5.1. Diagramma di Gantt

Il diagramma di Gantt fornisce una descrizione grafica ed un programma di tutte le attività

mettendo in evidenza gli elementi che costituiscono un progetto e le loro interdipendenze.

L’asse orizzontale rappresenta il periodo totale del progetto, suddiviso in giorni, mentre

nell’asse delle ordinate sono rappresentate tutte le varie attività che compongono il progetto.

Tale strumento è molto importante sia nella fase operativa che in quella di controllo, infatti

tramite questo diagramma è possibile non solo realizzare il tempo minimo necessario per la

realizzazione del progetto, ma anche controllare se viene rispettato lo schedule pianificato.

Sotto è riportato il diagramma di Gantt relativo allo sviluppo di SaniSystem.

36

5.2. Diagramma di PERT

Il Diagramma di PERT (Project Evaluation Review Technique) è una rappresentazione grafica

della mappa di attività che fanno parte di un progetto. Ogni attività è raffigurata con un

cerchio o un rettangolo, e rappresenta un nodo che può restare indipendente o essere

collegato con altri nodi, se le relative attività sono collegate e interdipendenti fra loro.

Alla base del PERT c'è la WBS (Work Breakdown Structure), con cui si elencano e si riportano

nel progetto tutte le attività. Di seguito è riportato il diagramma di Gantt relativo allo sviluppo

di SaniSystem:

http://www.problemsetting.it/pages/wbs.htm

37

6. Valutazione dello sforzo

6.1. Analisi dei Function Point

Per stimare il numero di LoC (Line of Code) che verranno sviluppate per la realizzazione di

SaniSystem è stata utilizzata la tecnica dei Function Point. Tale analisi è un metodo standard

per misurare lo sviluppo del software dal punto di vista dell’utente. L’analisi dei Function Point

si concretizza in una serie di punteggi (pesi) assegnati secondo le seguenti regole di conteggio:

Input (EI)

Interrogazioni (EQ)

Output (EO)

File logici interni (ILF)

File logici esterni (EIF)

Di seguito si indicano i valori degli Unadjusted Function Point (UFP) secondo la loro

complessità. Tali UFP sono il punto di partenza per determinare gli FP effettivi tramite un

fattore di aggiustamento.

Numero di valori UFP Weight (W)

semplici medi complessi

Input esterni (EI) 3 4 6

Output esterni (EO) 4 5 7

Interrogazioni esterne (EQ) 3 4 6

File esterni di interfaccia (EIF) 5 7 10

File interni logici (ILF) 7 10 15

Il fattore di aggiustamento (VAF) viene misurato sulla base di 14 caratteristiche generali del

sistema, le quali vengono utilizzate al file di valutare la complessità delle funzionalità. Di

seguito sono elencate le 14 caratteristiche:

38

1. Comunicazione dati 8. Aggiornamento interattivo

2. Distribuzione dell'elaborato 9. Complessità elaborativa

3. Prestazioni 10. Riusabilità

4. Utilizzo intensivo della configurazione 11. Facilità di installazione

5. Frequenza delle transazioni 12. Facilità di gestione operativa

6. Inserimento dati interattivo 13. Molteplicità di siti

7. Efficienza per l'utente finale 14. Facilità di modifica

Per ognuna di esse viene attribuito un valore, relativamente all'applicazione in oggetto,

utilizzando una scala di valori detta anche scala del grado di influenza DI (Degree of Influence).

Nella seguente tabella sono riportati i valori possibili ed il rispettivo grado di influenza:

Valore Grado di influenza

0 non presente, o nessuna influenza

1 Influenza poco significativa

2 Influenza moderata

2,5 Influenza intermedia

3 Influenza media

4 Influenza significativa

5 Influenza massima (fattore determinante)

39

La somma dei pesi delle caratteristiche, TDI (Total Degree of Influence), determina il valore

del Fattore di Aggiustamento (VAF), secondo la seguente formula:

Moltiplicando il fattore di aggiustamento per il numero di FP calcolati nella fase precedente

si ottengono i Function Point pesati.

6.2. Calcolo dei Function Point

Nei seguenti paragrafi sono riportate le complessità degli Unadjusted Function Point (UFP)

per ogni caso d’uso.

6.2.1. Complessità degli EI (External Input)

Caso d’uso EI

RicercaProfiloPaziente

3 Bassa

Login

3 Bassa

RegistrazioneSistema

6 Alta

CompilazioneRicetta

6 Alta

AllegareRicetta

0 -

AllegareEsame

0 -

CreaCartellaClinica

6 Alta


3 Bassa

RicercaEsame

3 Bassa

InoltraRichiestaRimborso

0 -

ConvenzionaMedico 4 Medio

ScegliMedico 4 Medio

Totale 38

UFP VAF

40

I casi d’uso riportati in tabella con valore uguale a 0 presentano una complessità

irrilevante.

6.2.2. Complessità degli OE (External Output)

Caso d’uso OE


7 Alta

Login

4 Bassa


4 Bassa

CompilazioneRicetta

5 Media

AllegareRicetta

4 Bassa

AllegareEsame

4 Bassa

CreaCartellaClinica

5 Media


5 Media

RicercaEsame

5 Media


0 -

ConvenzionaMedico 4 Bassa

ScegliMedico 4 Bassa

Totale 51

La complessità del caso d’uso RicercaProfiloPaziente è stato giudicato con un’alta

complessità perché visualizza tutte le molteplici informazioni riguardanti il paziente. Per

quanto riguarda il caso d’uso CreaCartellaClinica la sua complessità è stata valutata di

media poiché si ipotizza che al momento della creazione non vi sia allegata nessuna ricetta

o richiesta d’esame. Il caso d’uso InoltraRichiestaRimborso non ha alcuna complessità a

livello di EO, infatti è una procedura automatica che non visualizza alcuna informazione.

41

6.2.3. Complessità degli EQ (External Queries)

Caso d’uso EQ


3 Bassa

Login

3 Bassa


6 Alta

CompilazioneRicetta

6 Alta

AllegareRicetta

3 Bassa

AllegareEsame

3 Bassa

CreaCartellaClinica

6 Alta


3 Bassa

RicercaEsame

3 Bassa


0 -

ConvenzionaMedico 4 Media

ScegliMedico 4 Media

Totale 44

Il caso d’uso CompilazioneRicetta è stato valutato di alta complessità perché tutti i dati

devono essere inseriti nel database, quindi la complessità è la stessa di EI.

6.2.4. Complessità degli EIF e degli ILF

Sia per quanto riguarda gli EIF (External Interface Files) che per gli ILF (Internal Logic Files)

i valori sono nulli poiché SaniSystem non fa utilizzo di alcun file logico.

42

6.3. Calcolo dei fattori di aggiustamento

Nella seguente tabella sono riportati i valori di aggiustamento che sono stati utilizzati.

Caratteristica Valore

Comunicazione dati

3

Distribuzione dell’elaborazione

1

Prestazioni

3

Utilizzo intensive della configurazione

0

Frequenza delle transazioni

3

Inserimento dati interattivo

4

Efficienza per l’utente finale

5

Aggiornamento interattivo

3

Complessità elaborative

2

Riusabilità

2

Facilità d’installazione 4

Facilità di gestione operative 4

Molteplicità di siti 0

Facilità di modifica 3

Totale 37

6.4. Calcolo FP e Loc

Dai dati specificati nei precedenti paragrafi è possibile calcolare il valore del Function Point

utilizzando la formula illustrata nel paragrafo 4.1. In particolare risulta:

Per calcolare la corrispondenza fra FP e LoC è stato fatto riferimento alla “backfire” di Capers

Jones. In particolare il linguaggio di programmazione che verrà utilizzato per realizzare

43

SaniSystem è Java, quindi il numero di istruzioni corrispondenti per ogni FP è pari a 53. Quindi

il calcolo delle Line of Code risulta:

Quindi per realizzare SaniSystem saranno necessarie circa 7208 linee di codice Java.

6.5. Analisi CoCoMo

Per effettuare una stima temporale dello sforzo è stata utilizzata la tecnica del CoCoMo

(Constructive Cost Model), il quale consente di valutare parametri fondamentali come il

tempo di consegna ed i mesi-uomo necessari per la realizzazione di un prodotto software.

Per questa analisi è stato utilizzato il software free Costar 7.0 , il quale ha come vincolo 5000

per il numero di linee di codice in ingresso. Quindi la seguente analisi è relativa a 5000 LoC

(Line of Code) e non 7208 come calcolato precedentemente tramite la tecnica dei Function

Point.

Il modello di stima selezionato è il COCOMO II.2000 con MBASE/RUP Phases.

6.6. Scale Driver

Nella seguente tabella sono riportati i valori assegnati agli Scale Driver, ovvero ai 5 fattori più

importanti per la determinazione del costo del progetto.

Scale Driver Valore assegnato

PREC (Precedentness ) High

FLEX (Development Flexibility) Low

RESL (Architecture / Risk Resolutions) High

TEAM (Team Cohesion) Very High

PMAT (Process Maturity) High

Lo scale driver PREC indica l’esperienza che il team ha acquisito in progetti simili realizzati

precedentemente. È stato assegnato il valore “High” in quanto il gruppo di lavoro è in

possesso di buone conoscenze sulle strutture di applicazioni client/server in vari linguaggi di

44

programmazione (C++, Java e VB) ma non specifiche per il campo medico/farmaceutico e

applicazioni a forte impatto grafico.

Lo scale driver FLEX indica la flessibilità dei requisiti del progetto. È stato selezionato il valore

“Low” poiché la specifica consegnata dal committente è rigorosa, lasciando libertà solo sugli

aspetti puramente grafici.

Lo scale driver RESL specifica l’architettura ed il piano di rischio. È stato selezionato “High” in

quanto la struttura gerarchica dei ruoli è ben definita e non sono stati rilevati rischi particolari

in fase di analisi delle specifiche di progetto. Tuttavia è stato deciso di lasciarsi una probabilità

di errore del 25%.

Lo scale driver TEAM indica la relazione che si ha con gli stakeholder del sistema. È stato

selezionato “Very High” dato che il committente è sempre stato disponibile e tempestivo per

fornire tutti i chiarimenti di cui c’è stato bisogno, oltre ad aver già fornito i requisiti in maniera

dettagliata.

Lo scale driver PMAT specifica la conoscenze degli strumenti utilizzati per la realizzazione del

sistema. È stato selezionato “High” visto che la conoscenza degli strumenti è alta.

6.7. Wizard Cost Driver

Nella seguente tabella sono riportati tutti i Cost Driver, ovvero i 17 coefficienti correttivi

utilizzati per il calcolo dello sforzo richiesto per la realizzazione di SaniSystem.

Cost Driver Descrizione Valore scelto

ACAP – Analyst Capability

Capacità degli analisti nello

sviluppo del progetto Nominal

APEX – Application Experience Esperienza del team nel settore Very Low

PCAP – Programmer Capability Capacità dei programmatori Nominal

PLEX – PLatform EXperience

Esperienza del team sulla specifica

piattaforma Low

LTEX – Language & Tool

Experience

Conoscenza del linguaggio e

dei tool Very Low

45

PCON – Personnel CONtinuity

Turn-over annuale

dell'organizzazione Very High

TOOL – use of software tools Tipologia dei tool di sviluppo Very High

SITE – Multisite Development

Localizzazione geografica del team e

metodologie di comunicazione Extra High

SCED – Develpment Schedule

Relazione fra schedule nominale e

reale Nominal

TIME – Execution Time

Constraint

Percentuale di utilizzo della CPU da

parte del software Nominal

STOR – Main Storage

Constraint Memoria utilizzata dal software Nominal

PVOL – Platform Volatility Durata di vita della piattaforma Low

RELY – requie reliability Affidabilità richiesta Nominal

DATA – Database size

Quantità di dati necessari per

testare il Software Very High

CPLX – Product Complexity Complessità del software Low

RUSE – Required Reusability Riusabilità dei componenti Low

DOCU – Documentation Match

Life-cycle Needs

Quantità di documentazione

Prevista Nominal

Per quanto riguarda il cost driver ACAP (Analyst Capability Cost Driver) è stato selezionato il

valore “Nominal” poiché rappresenta il valore medio, mentre è stato selezionato il valore

“Very Low” per APEX (APplication EXperience) perché Sanysistem è il primo progetto per

quanto riguarda il settore medico per tutti i membri del gruppo. La capacità dei

programmatori del team è nella media, quindi il cost driver PCAP (Programmer Capability Cost

Driver) è stato selezionato con il valore “Nominal”. Il cost driver PLEX (PLatform EXperience) è

stato impostato “Low” dato che i membri del gruppo hanno sinora realizzato poche

applicazioni di tipo Client/Server. Il cost driver LTEX (Language and Tool Experience) è stato

impostato “Very Low” poiché i membri del team utilizzano per la prima volta questi specifici

46

tools; invece il cost driver PCCD (Personnel Continuity Cost Driver) è stato selezionato “Very

High” in quanto il gruppo non ha alcun ricambio e quindi non è in grado di effettuare

turnover. Il cost driver TOOL (Use of Software Tools Cost Driver) è stato selezionato “Very

High” dato che i tools utilizzati sono all’avanguardia. Il team lavora sempre insieme ed

interagisce in maniera diretta, quindi il cost driver SITE (Multisite Development Cost Driver) è

stato impostato “Extra High”. Per quanto riguarda i tempi di consegna non è stata fatta

nessuna pressione da parte del committente, quindi il cost driver SCED (Development

Schedule Cost Driver) è stato impostato con il valore “Nominal”. La percentuale di utilizzo della

CPU da parte di SaniSystem dev’essere leggera, quindi il TIME (Execution Time Constraint Cost

Driver) è stato selezionato “Nominal”. Lo STOR (Main Storage Constraint Cost Driver) è stato

selezionato “Nominal” in quanto è previsto lo scarico di tutte le transazioni su un database

centralizzato. Il cost driver PVOL (Platform Volatility Cost Driver) è stato impostato “Low”

infatti a meno di aggiornamenti catastrofici, il sistema deve essere performante su tutte le

macchine per un lungo periodo. RUSE (Required Reliability Cost Driver) è stato selezionato

“Nominal”, poiché le ricette da far scalare all’ASL prolungherebbero le attività burocratiche

manuali. DATA (Database Size Cost Driver) è stato selezionato “Very High”, infatti SaniSystem

necessita di un elevato numero di query che è necessario testare, invece il cost driver CPLX

(Product Complexity Cost Driver) è stato selezionato “Low” dato che il software non dovrà fare

elaborazioni complicate, ma lavorare quasi esclusivamente su un database. La scelta di

progetto è stata quella di non fare niente nell’ottica della riusabilità, quindi il cost driver RUSE

(Required Reusability Cost Driver) è stato selezionato “Low”. Per quanto riguarda la

documentazione è previsto il rilascio di un manuale d’uso e una lista di Frequantly Asked

Questions in modo tale che ogni utente sia in grado di risolvere autonomamente alcuni dei

problemi che si possono presentare più spesso. Per tale motivo il cost driver DOCU

(Documentation match to life-cycle needs) è stato impostato “”Nominal”.

6.8. Risultati Costar 7.0

L’analisi CoCoMo effettuata tramite il software Costar 7.0 ci consente di fare una stima del

costo finale per la realizzazione di SaniSystem.

Nella seguente figura sono riportate le retribuzioni mensili di ogni componente del team.

47

Inoltre abbiamo impostato le percentuali di tempo che ciascun membro del gruppo lavorerà

nelle diversi fasi di realizzazione del sistema. Nella seguente immagine sono riportati i valori

inseriti.

48

Nella seguente immagine sono riportati i risultati ottenuti in termini di sforzo.

49

Dai risultati forniti dall’Effort Report se ne deduce che lo sforzo totale necessario è pari a

13.9 mesi-uomo. Nella seguente tabella è riportato in maniera dettagliata lo sforzo necessario

per ciascuna fase:

Fase Mesi-uomo

Inception Phase 0.7

Elaboration Phase 2.8

Construction Phase 8.9

Transition Phase 1.4

Nella seguente immagine sono riportati i risultati ottenuti in termini di costi.

Dall’analisi risulta che il costo totale per la realizzazione di SaniSystem sarà di circa 21.800 $.

La fase più onerosa risulterà quella della Construction nella quale verrà implementata la prima

release del sistema. Essa risulta anche la fase che richiede il maggior sforzo in termini di mesi-

uomo.

Nella seguente immagine è riportato il Detail Report, il quale stima il numero di mesi che

effettivamente saranno necessari per la realizzazione di SaniSystem.

50

Il seguente grafico illustra la suddivisione dei vari costi in relazione ai mesi necessari per la

realizzazione del sistema forniti dal Detail Report.

51

Di seguito è riportato lo Schedule Report il quale illustra lo sforzo in termini di mesi-uomo ed

il costo in termini di denaro suddiviso nei 10 mesi necessari per la realizzazione del sistema.

6.9. Conclusioni dell’analisi CoCoMo

Come già precedentemente detto nel paragrafo 3.5 la demo del software Costar 7.0 ha un

limite per quanto riguarda le LoC a 5000. Dall’analisi dei FP siamo giunti alla conclusione che

per l’implementazione di SaniSystem saranno necessarie circa 7208 linee di codice, circa il 45%

in più di quelle che abbiamo inserito nell’analisi CoCoMo. Supponendo che sia lo sforzo in

termini di mesi-uomo, sia i costi crescano in maniera lineare all’aumentare della LoC risulta:

Sforzo (mesi-uomo) = mesi-uomo

Costo ( ) =

Questi ultimi valori sono da considerarsi come stime indicative, in quanto l’ipotesi

dell’incremento lineare dello sforzo e dei costi non rispecchia perfettamente la realtà.

52

7. Piano di qualità

Per garantire la qualità del sistema SaniSystem si è deciso di seguire lo standard ISO 9126,

per definire il modello dei requisiti qualitativi del sistema, e lo standard ISO 12207 per definire

in modo preciso i processi del ciclo di vita di SaniSystem a partire dalla formulazione dei

requisiti, allo sviluppo, all'esercizio ed alla manutenzione.

7.1. Modello ISO 9126

Lo standard ISO 9126 distingue tre famiglie di caratteristiche che influenzano la qualità di un

software, i quali corrispondono a tre diversi punti di vista:

Qualità in uso: capacità del prodotto software di abilitare specifici utenti ad

ottenere determinati obiettivi con efficacia, produttività, sicurezza e soddisfazione.

Qualità interna: richiama invece un meccanismo tipo “white box” e si riferisce alle

caratteristiche “statiche” del software, ciò è indipendentemente dall'ambiente in

cui esso è destinato ad operare.

Qualità esterna: può essere associata ad una vista tipo “black box” e si riferisce alle

caratteristiche del software, nel momento in cui esso è funzionante nell'ambiente

operativo di un computer.

7.1.1. Qualità interna ed esterna

Secondo il modello proposto dalla norma, i requisiti sono raggruppabili in sei

caratteristiche e in ventuno sotto-caratteristiche. La misurazione degli attributi di qualità

viene effettuata associando una metrica ad ogni sotto-caratteristica. Nella seguente

immagine sono riportate le sotto-caratteristiche associate ad ogni caratteristica:

53

Di seguito riportiamo una breve descrizione di ogni caratteristica:

1. Funzionalità : un software è considerato funzionale nella misura in cui le procedure in esso

contenute coincidono con le funzioni richieste. Un buon programma deve innanzitutto essere

conforme alla specifica dei requisiti che il cliente ha richiesto.

2. Affidabilità : un software è ritenuto affidabile quando è in grado di mantenere il livello di

prestazioni sotto determinate condizioni e per un determinato periodo di tempo. Un sistema

è tanto più affidabile quanto meno di frequente si manifestano malfunzionamenti, durante

l’utilizzo del sistema stesso. L'affidabilità può anche essere considerata come la misura con

cui l'utente può fidarsi del software.

3. Usabilità : un software è considerato usabile in proporzione alla facilità con cui gli utenti

operano per sfruttare appieno le funzionalità offerte dal software. Un software è facile da

usare se un essere umano lo reputa tale, è quindi una caratteristica soggettiva e può

dipendere in buona parte dalla formazione e dalla cultura dell’utente che lo utilizza.

L'interfaccia utente ha un ruolo determinante per quanto riguarda la semplicità di utilizzo di

un'applicazione.

4. Efficienza: l'efficienza di un software è proporzionale al rapporto tra il livello generale di

prestazioni del software e l'ammontare delle risorse necessarie al suo funzionamento. Un

sistema è efficiente se usa memoria, CPU e tutte le altre risorse in modo proporzionato ai

servizi che svolge, ovvero eliminando inutili sprechi. È importante cercare di prevedere in

54

maniera accurata quali saranno le risorse che un software impegnerà durante la sua

esecuzione in quanto interventi a posteriori per migliorare questo aspetto sono in genere

complessi e molto costosi.

5. Manutenibilità: è l'attitudine del software ad essere modificato e corretto a costi

accessibili ed in tempi rapidi. Una volta rilasciato un programma è facile pensare di dovere

effettuare interventi sul codice per correggere bug, adattare o perfezionare alcune funzioni.

Più un software è facile da correggere e da migliorare minori sono i costi di manutenzione e

sviluppo.

6. Portabilità : un software è considerato portabile quando è possibile trasferirlo in modo

sufficientemente veloce da un ambiente (hardware, sistema operativo, etc.) ad un altro. È

diventato un aspetto fondamentale perché consente di avere vantaggi economici, in quanto si

possono ammortizzare i costi trasportando l’applicazione in diversi ambienti.

Nei seguenti sotto paragrafi sono riportati i valori delle metriche che sono stati stabiliti per

ogni sotto caratteristica.

55

7.1.1.1. Funzionalità

SOTTO CARATTERISTICA

DESCRIZIONE METRICA VALORE

Adeguatezza

La capacità del prodotto software di fornire un

appropriato insieme di funzioni per gli specificati compiti ed

obiettivi all’utente

Numero dei requisiti non soddisfatti

0

Accuratezza

La capacità del prodotto software di fornire i giusti

risultati con il dovuto grado di precisione.

Percentuale dei casi di comportamento

inconsistente. 2%

Interoperabilità

La capacità del prodotto software di interagire con uno o

più sistemi specificati.

Numero fallimenti nell’interazione con altri

sistemi. 0

Sicurezza

La capacità del prodotto software di proteggere le

informazioni da accessi non autorizzati.

Numero degli accessi non autorizzati avvenuti

con successo. 0

Conformità

La capacità del prodotto software di aderire a standard,

convenzioni o leggi relativamente alle funzionalità .

Difformità con

regolamenti di varia natura.

0

56

7.1.1.2. Affidabilità

SOTTO

CARATTERISTICA DESCRIZIONE METRICA VALORE

Maturità

La capacità del prodotto software di

evitare malfunzionamenti a causa di errori

nel codice.

Numero di

crash del sistema < 5/anno

Tolleranza


mantenere un livello specifico di

prestazioni in caso di errori nel codice o

utilizzi scorretti del prodotto.

Tempo di

risposta nel caso

di errori.

< 30 sec

Recuperabilità


ristabilire uno specifico livello di

prestazioni e recuperare i dati in caso di

malfunzionamenti.

Numero di

informazioni

perse.

< 0.05%/anno

7.1.1.3. Usabilità

SOTTO

CATEGORIA DESCRIZIONE METRICA VALORE

Comprensibilità


rendersi comprensibile all’utente, per

essere usato in particolari attività o

scopi.

Numero di richieste di

aiuto da parte

dell’utente

< 1/2000

Accessi

Apprendibilità La facilità di apprendimento dell’utilizzo

del prodotto software.

Tempo medio di

apprendimento

dell’utente

≈ 2 giorni

Operabilità


permettere all’utente di operare con

esso e controllarlo.

Numero di errori

commessi dagli utenti < 10 / giorno

57

7.1.1.4. Efficienza

SOTTO


Tempestività

La capacità del prodotto software

di fornire risposte appropriate in

tempi ragionevoli, negli usi previsti.

Tempi

di risposta < 15 sec

Uso delle risorse

La capacità del prodotto software

di fare un uso appropriato delle

risorse durante gli usi previsti.

Utilizzo della CPU < 50 %

7.1.1.5. Manutenibilità

SOTTO


Analizzabilità

La capacità del prodotto

software di essere analizzato

al fine di rilevare errori nel

codice

Numero di cause

di difetti identificate 100 %

Modificabilità


software di permettere di

effettuare una specifica

modifica

Livello di

documentazione e

grado di modularità

del sistema

Alto

Stabilità


software di evitare effetti

inattesi a causa di modifiche

del software

Percentuale

riduzione rischio di

comportamenti

inaspettati a seguito

di modifiche

< 1 %

Testabilità


software di permettere la

validazione delle modifiche

al codice

Numero di moduli

non testabili

indipendentemente

0

58

7.1.1.6. Portabilità

SOTTO


Adattabilità


software di essere adattato

a diversi ambienti operativi

senza modifiche del codice.

Numero di

piattaforme

sottostanti

supportate

2 (*)

Installabilità


software di essere installato

in un ambiente specifico.

Tempo necessario

per l’installazione 8 ore

Coesistenza


software di coesistere con

software di terze parti,

condividendo le risorse.

Numero di

incompatibilità

rilevate con altre

componenti

0

(*) SaniSystem verrà realizzato con il linguaggio Java, quindi il software sarà indipendente dal

sistema operativo sottostante. Non sarà necessaria alcuna modifica al codice poiché la Java

Virtual Machine adatterà dinamicamente il codice al sistema operativo installato sulla

macchina. In particolare è stato inserito il valore 3 facendo riferimento ai principali sistemi

operativi attualmente in commercio (Windows, Apple e Linux).

7.1.1.7. Sviluppi futuri

SaniSystem è stato sviluppato tenendo conto di eventuali sviluppi futuri che potrebbero

essere richiesti dal committente in seguito al sopravvenire di nuove esigenze; tali esigenze

potranno nascere per esempio a seguito dell’emanazione di nuove norme. Per facilitare

l’evoluzione del sistema è stato deciso di sviluppare il software in maniera modulare

nonostante il committente non avesse fornito alcuna indicazione in proposito. Inoltre è stata

fornita una documentazione ben dettagliata, la quale si rivelerà fondamentale nel caso in cui il

futuro sviluppo del software verrà affidato ad un team diverso da quello che lo ha progettato.

59

7.2. Modello ISO 12207

La norma ISO 12207 ha come obiettivo principale quello di definire in modo preciso i

processi di tutto il ciclo di vita del software, a partire dalla formulazione dei requisiti,

analizzando la fase di sviluppo, quella d’esercizio fino ad arrivare alla fase di manutenzione.

Per quanto riguarda i processi informatici, nella norma essi vengono suddivisi in tre

categorie:

Primari: comprendenti le attività direttamente legate allo sviluppo del software.

Di supporto: che includono la gestione dei documenti e dei processi di controllo della

qualità .

Organizzativi: che coprono gli aspetti manageriali e quelli riguardanti la gestione

delle risorse.

Per ognuno di tali processi sono chiaramente evidenziati:

L’obiettivo e le responsabilità

La lista delle attività che lo compongono

I singoli compiti nei quali è suddivisa un’attività

La norma consiglia inoltre il ciclo per il controllo dei processi basato sulla sequenza PDCA

(Plan, Do, Check, Act). Particolare attenzione viene inoltre posta al fatto che il software va

sempre considerato parte di un sistema, all’interno del quale dovrà essere integrato e poter

funzionare.

7.2.1 Processi primari

I processi primari trattano le attività di:

Acquisizione

Fornitura

Sviluppo

Esercizio

Manutenzione.

60

Ogni processo primario è definito e descritto dalla norma in termini di attività (activities) e

compiti (tasks). Ogni compito o task deve indicare cosa una azione che il processo deve fare

("what to do") e non come la deve fare ("how to do”).

7.2.2 Processi di supporto

I processi di supporto aiutano ogni altra attività nel garantire il successo e la qualità del

progetto, e possono essere attivati da un processo primario o da un altro processo di

supporto. In particolare la norma descrive otto processi di supporto:

1. Documentazione

2. Gestione della configurazione

3. Assicurazione della qualità

4. Verifica

5. Validazione

6. Review congiunte

7. Audit

8. Risoluzione dei problemi

7.2.3 Processi organizzativi

Lo standard ISO 12207 prevede i seguenti processi organizzativi:

Gestione dello sviluppo

Gestione delle infrastrutture

Gestione del miglioramento

Formazione

Tali processi aiutano nel definire, controllare e migliorare gli altri processi ovvero quelli

primari e quelli organizzativi.

61

8. Test del prodotto

Il seguente piano di testing è stato redatto con l’obiettivo di tracciare le linee guida per la

fase di testing dell’applicazione. A tal scopo è stata definita una procedura sia per i casi d’uso

da verificare che per le attività di testing. Queste ultime saranno svolte da un team diverso da

quello di sviluppo.

La procedura selezionata è la seguente:

Determinare le funzionalità (input, relativi output, precondizioni e postcondizioni) per

effettuare dei test funzionali per ogni caso d’uso

Verificare se le funzionalità scelte per i test funzionali riescono a coprire tutti i possibili

scenari

Effettuare i test funzionali su ogni caso d’uso

Effettuare nuovamente i test funzionali, integrando mano a mano due o più casi d’uso

Effettuare al termine un alpha-testing sull’hardware disponibile

8.1 Test Design Specification

Nel Test Design Specification (TDS) vengono dettagliate le condizioni di test ed i risultati

attesi per una o più caratteristiche del software; il TDS può quindi essere descritto da più Test

Case Specification. Il test di unità verrà effettuato inserendo prima i dati corretti ed in seguito

altri non corretti. In tal modo sarà possibile valutare il comportamento dell’applicazione ed

eventualmente correggerlo.

8.2 Test Case Specification

Nel Test Case Specification vengono specificati i dati da utilizzare per le varie condizioni di

test identificate nel TDS.

62

8.2.1 RicercaProfiloPaziente

Input corretto:

Selezionato RicercaProfiloPaziente

inserito codice di un paziente esistente nel database

Output atteso: visualizzazione del profilo del paziente ricercato

Input scorretto:

Selezionato RicercaProfiloPaziente

inserito codice non esistente nel database

Output atteso: restituzione di errore di paziente non esistente

Precondizioni:

Attore loggato al sistema

Infrastruttura tra terminale e database attivo

8.2.2 Login

Input corretto:

Selezionato Login

inserito identificativo e password relativi ad un Utente Registrato

Output atteso: Utente loggato al sistema

Input scorretto:

Selezionato Login

inserimento di identificativo e/o password errati

Output atteso: Accesso al sistema negato, richiedere nuovamente dati per login

Input scorretto:

Selezionato Login

Mancato inserimento di identificazione e/o password

Output atteso: Richiedere completamento di tutti i campi

Precondizioni:


63

8.2.3 RegistrazioneSistema

Input corretto:

Selezionato RegistrazioneSistema

Inserimento di tutte le informazioni obbligatorie in formato consistente

Output atteso: registrazione di un nuovo elemento al sistema

Input scorretto:


Mancato inserimento di alcune informazioni obbligatorie

Output atteso: Richiesta completamento di tutti i campi obbligatori

Input scorretto:


Inserimento di alcune informazioni non consistenti

Output atteso: Richiedere informazioni per i campi non consistenti

Precondizioni:


8.2.4 CompilazioneRicetta

Input corretto:

Iniziata procedura di compilazione ricetta

Inserimento di dati riconosciuti dal sistema come consistenti

Output atteso: Notifica di compilazione avvenuta con successo

Input scorretto:


mancato inserimento di dati obbligatori

Output atteso: sistema richiede i dati mancanti

Input scorretto:


inserimento di dati non consistenti

Output atteso: sistema notifica i campi non consistenti e richiede nuovo inserimento

Precondizioni:

64

Medico loggato al sistema

Medico seleziona la compilazione di una ricetta quando allega una ricetta al

profilo di un paziente

Infrastruttura tra terminale e database attiva

8.2.5 AllegareRicetta

Input corretto:

Selezionare “Allega ricetta”

Compilazione ricetta eseguita con successo

Output atteso: inizio procedura di compilazione ricetta.

Precondizioni:


Medico sta visualizzando la cartella clinica di un paziente


8.2.6 AllegareEsame

Input corretto:

Selezione di allegare esame

Inserimento delle informazioni necessarie in modo consistente

Output atteso: Allegato esame al profilo del paziente

Input scorretto:


Mancato inserimento di informazioni necessarie

Output atteso: Sistema richiede inserimento delle informazioni mancanti

Input scorretto:


Inserimento di dati inconsistenti

Output atteso: Sistema richiede inserimento di dati consistenti

Precondizioni:


Medico che sta visualizzando il profilo di un paziente


8.2.7 CreaCartellaClinica

Input corretto:

65

MedicoDiFamiglia seleziona creazione di una cartella clinica

Inserimento dati consistenti

Output atteso: Inserita nuova cartella clinica nel database

Input scorretto:


Mancato inserimento di dati obbligatori

Output atteso: Sistema richiede i dati mancanti

Input scorretto:


Inserimento dati inconsistenti

Output atteso: Sistema richiede il nuovo inserimento dei dati inconsistenti

Precondizioni:

MedicoDiFamiglia loggato al sistema


8.2.8 RicercaRicettaAttiva

Input corretto:

Farmacista selezione RicercaRicettaAttiva

Farmacista inserisce codice tessera sanitaria di un cliente registrato al

sistema

Output atteso: Visualizzate, se ci sono, le ricette attive e in seguito disattivate

Input scorretto:

Farmacista selezione RicercaRicettaAttiva

Farmacista inserire codice tessera sanitaria non valido

Output atteso: Sistema notifica codice non esistente

Precondizioni:

Farmacista loggato al sistema


8.2.9 RicercaEsame

Input corretto:

Laboratorio seleziona RicercaEsame

66

Inserito codice tessera sanitaria di un paziente registrato al sistema

Output atteso: Visualizzate, se ci sono, Esami attivi e in seguito disattivati.

Input corretto:

Laboratorio seleziona RicercaEsame

Inserito codice tessera sanitaria non valido

Output atteso: Sistema richiede nuovo inserimento di un codice tessera sanitaria

Precondizioni:

Laboratorio loggato al sistema


8.2.10 InoltraRichiestaRimborso

Input corretto:

Farmaco venduto o effettuato esame a carico dell’ASL

Output corretto: inoltrata richiesta di rimborso all’ASL di competenza

Precondizioni:


8.2.11 ConvezionaMedico

Input corretto:

ASL seleziona ConvenzioneMedico

Inserite informazioni di Medico registrato e nella zona di competenza

Output atteso: Medico diventa convenzionato

Input scorretto:

ASL seleziona Convenziona Medico

Inserite informazioni di Medico registrato ma non nella zona di competenza

Output atteso: Sistema nega la convenzione

Input scorretto:

ASL seleziona ConvenzionaMedico

Inserite informazioni di Medico non registrato o informazioni non

consistenti

Output atteso: Sistema notifica l’inesistenza del Medico descritto nel database

67

Precondizioni:

ASL loggata al sistema


8.2.12 ScegliMedico

Input corretto:

Paziente seleziona ScegliMedico

Paziente inserisce i dati di un Medico registrato al sistema

Output atteso: Medico è assegnato al Paziente

Input scorretto:

Paziente seleziona ScegliMedico

Paziente inserisce i dati di un Medico non registrato o dati non consistenti

Output atteso: Sistema notifica l’inesistenza del Medico nel Database

Precondizioni:

Paziente loggato al sistema


68

9. Diario di gruppo

Data: 6 Aprile 2011

Luogo: Dipartimento Ing. Informatica - Laboratorio blu

Durata: 4 ore

Partecipanti e ruolo:

Nigi Mirko – PM

Migliorini Giacomo – QE

Mucci Giacomo – TS & L

Ordine del giorno:

1. Pianificazione dei ruoli

2. Pianificazione della strumentazione da utilizzare

3. Pianificazione della documentazione

4. Analisi delle specifiche

Attività:

1. Sono stati attribuiti i seguenti ruoli ai membri del gruppo:

Nigi Mirko – PM



È stato deciso che Mucci Giacomo ricoprirà sia il ruolo di Quality Engineer che quello di

Library a causa della mancanza di un quarto componente del gruppo.

2. È stato deciso di utilizzare i seguenti strumenti per la realizzazione del progetto:

Microsoft Word 2010

Microsoft Project 2010

Costar 7.0 DEMO

Dropbox

Microsoft PowerPoint 2007

3. Sono stati stabiliti i template da utilizzare per la stesura dei diari.

4. Sono stati individuati gli attori e casi d’uso.

69

Data: 13 Aprile 2011

Luogo: Dipartimento Ing. Informatica - Laboratorio blu

Durata: 4 ore


Nigi Mirko – PM



Ordine del giorno:

1. Elaborazione del capitolo relativo alla relazione di progetto

2. Inizio della valutazione preventiva dello sforzo tramite la tecnica CoCoMo

Attività:

1. È stata elaborata una descrizione delle funzionalità di SaniSystem attraverso una

descrizione informale e tramite documentazione UML, in particolare:

a. Diagramma della classi

b. Diagramma dei casi d’uso

c. Specifiche dei casi d’uso

2. Si è iniziata a fare una valutazione dei costi iniziando ad impostare i parametri richiesti

dal software Costar 7.0


Luogo: Dipartimento Ing. Informatica – Aula ADInform

Durata: 3 ore


Nigi Mirko – PM



Ordine del giorno:

1. Elaborazione dei diagrammi di sequenza dei casi d’uso più significativi

70

2. Valutazione preventiva dello sforzo tramite la tecnica CoCoMo

Attività:

1. Terminata la descrizione delle funzionalità di SaniSystem attraverso l’elaborazione

dei diagrammi di sequenza e una descrizione informale delle funzionalità non

funzionali.

2. Elaborazione della valutazione dei costi tramite la tecnica CoCoMo con l’ausilio del

software Costar 7.0.

Data: 4 Maggio 2011

Luogo: Dipartimento Ing. Informatica – Aula ADInform 1

Durata: 2 ore


Nigi Mirko – PM



Ordine del giorno:

1. Revisione generale del progetto

2. Valutazione dei costi tramite la tecnica Function Point

Attività:

1. È stato revisionata la relazione di progetto elaborata sino ad oggi.

2. Si è iniziata a fare una stima dello sforzo tramite la tecnica dei Function Point.

Data: 11 Maggio 2011


Durata: 2 ore


Nigi Mirko – PM


71

Ordine del giorno:

1. Valutazione dei costi tramite la tecnica Function Point

Attività:

1. È stata terminata la stima delle LoC (Line of Code) tramite la tecnica dei Function Point.



Durata: 3 ore


Nigi Mirko – PM


Ordine del giorno:

1. Valutazione dello sforzo e dei costi tramite la tecnica CoCoMo

2. Stesura del Piano di Processo

3. Elaborazione delle prove di Testing da effettuare sul sistema

Attività:

1. È stata effettuata la stima dello sforzo in termini di mesi-uomo e dei costi tramite la

tecnica CoCoMo tramite l’utilizzo del software Costar 7.0.

2. È stato elaborato il diagramma di Gantt e quello di PERT

3. Si è iniziato ad elaborare il Testing


Luogo: Dipartimento Ing. Informatica – Aula Laboratorio Blu

Durata: 3 ore


Nigi Mirko – PM

72



Ordine del giorno:

1. Elaborazione del piano di Testing da effettuare sul sistema

2. Elaborazione del piano di Qualità

Attività:

1. È stato terminata l’elaborare del piano di Testing

2. Elaborazione del piano di Qualità seguendo gli standard ISO 9126 e ISO 12207

Data: 1 Giugno 2011

Luogo: Dipartimento Ing. Informatica – Aula Laboratorio Blu

Durata: 4 ore


Nigi Mirko – PM



Ordine del giorno:

1. Revisione generale del progetto

2. Preparazione della presentazione del progetto

Attività:

1. È stata fatta una revisione generale di tutto il lavoro svolto

2. È stata realizzata una presentazione del progetto in PowerPoint 2007

73

10. Diari individuali

10.1. Nigi Mirko – PM

Data: 06/04/2011

Luogo: AdInf1, Università di Pisa

Durata: 4 h

Attività: Una volta assegnatomi il ruolo di Project Manager, ho dato il compito di Quality

Engineer a Migliorini e i compiti di Tool Specialist e Librarian a Mucci, mancando un quarto

elemento al team.

In seguito sono stati determinati gli strumenti da utilizzare per lo svolgimento della

pianificazione e progettazione del sistema, denominato dal team SaniSystem. In particolare è

stato definito l’utilizzo di una Dropbox per la condivisione dei vari documenti.

Il team ha inoltre eseguito una analisi dei requisiti, individuando gli attori del sistema, gli

attributi e i casi d’uso. Una volta individuati, abbiamo disegnato il diagramma dei casi d’uso,

redatto le specifiche informali degli attori e individuato i casi d’uso significativi da

dettagliare.

Data: 13/04/2011


Durata: 4 h

Attività: E’ stato definito dal gruppo i diagrammi e i discorsi da affrontare per sviluppare il

capitolo della Relazione di progetto, individuando come funzionali alla relazione un

diagramma delle classi, i diagrammi di sequenza dei casi d’uso significativi individuati nella

riunione precedente e alcuni discorsi pratici sulle azioni che ogni utente del sistema può

compiere.

Infine sono stati valutati gli indici da utilizzare per una adeguata valutazione dello sforzo da

inserire nel software Costar 7.0

74

Data: 20/04/2011


Durata: 3h

Attività: Ricontrollati gli indici per valutazione CoCoMo e inserimento parametri di costi.

Stilatura dei primi report di CoCoMo basati su 5000 LoC. Pianificazione del lavoro per la

sessione successiva.

Data: 11/05/2011


Durata: 2h

Attività: Valutazione indici non aggiustanti della FP per determinazione delle linee di codice.

Data: 18/05/2011


Durata: 3h

Attività: Determinati i fattori di aggiustamento per analisi Function Point. Determinazione

LoC. Stesura del Piano di Progetto. Stesura del Piano di Testing, Test Design Specification e

primi casi d’uso all’interno del Test Case.

Data: 26/05/11

Luogo: Laboratorio Blu, Dip. IET, Università di Pisa

Durata: 3h

Attività: Terminazione della stesura dei Test Case Specification.

75

Data: 01/06/11

Luogo: Laboratorio Blu, Dip. IET, Università di Pisa

Durata: 4h

Attività: Revisionato il diario e tutto il progetto, preparazione presentazione in Powerpoint.

10.2. Migliorini Giacomo – QE

Data: 06/04/2011

Luogo: ADInf1, Universita’ di Pisa

Durata: 4 ore

Attività: E’ stata effettuata l’analisi dei requisiti del sistema insieme al PM e al TS-L. E’ stato

creato il Glossario dei termini utile nella specifica dei requisiti.

Sono stati determinati i tool da utilizzare per lo svolgimento della pianificazione e della

progettazione del sistema, denominato dal team Sanisystem. Infine si e’ cominciata la

creazione delle specifiche dei casi d’uso, che verra’ continuata la prossima volta.

Data: 20/04/2011


Durata: 4 ore

Attività: E’ stata completata la creazione delle specifiche dei casi d’uso del sistema.

E’ stato valutato, insieme al PM e al TS-L, l’analisi CoCoMo e Function Point.

Data: 04/05/2011


Durata: 2 ore

E’stata continuata la realizzazione dei diagrammi dei sequenza.

Sono stati valutati insieme al TS-L, altri fattori dell’analisi CoCoMo e Function Point.

Data: 26/05/2011

Luogo: Laboratorio Blu, Universita’ di Pisa

76

Durata: 4 ore

Attività: Sono stati portati a termine i diagrammi di sequenza del sistema, grazie ai quali

sono stati anche aggiornate le specifiche dei casi d’uso.

Sono stati valutati insieme al PM e TS-L tutti gli altri aspetti del progetto riguardante il Piano

della Qualità e il Piano del Testing.

Data: 01/06/2011

Luogo: A28 e AdInf1, Universita’ di Pisa

Durata: 4 ore

Attività: E’ stata portata a termine la relazione del progetto con la parte riguardante la fase

di testing del progetto stesso; dopo la stesura sono stati anche ricontrollati i capitoli

precedenti.

E’ stata creata una presentazione in formato PowerPoint di supporto durante l’esposizione

del progetto agli stakeholder delle varie fasi di lavorazione dei risultati ottenuti.

10.3. Mucci Giacomo – TS & L

Data: 6 Aprile 2011

Luogo: Dipartimento IET, aula ADInform1

Durata: 4 ore

Attività:

Riunione iniziale in cui mi sono stati assegnati i ruoli di Tool Specialist e Librarian.

Elaborazione dei template da utilizzare per la documentazione, in particolare:

o Diario di gruppo

o Diario individuale

o Relazione finale

Stesura dei seguenti paragrafi:

o 1.1

o 1.2

77



Durata: 4 ore

Attività:

Elaborazione del diagramma delle classi.


o 1.3

o 1.5

o 2

o 2.1



Durata: 3 ore

Attività:

Elaborazione delle specifiche dei casi d’uso.


o 1.3.2

o 1.2

Supporto al PM per la valutazione dello sforzo.

Data: 4 Maggio 2011


Durata: 2 ore

Attività:

Correzione generale dei capitoli precedentemente scritti

Stesura di capitoli relativi all’analisi FP, in particolare:

o 3.1

o 3.2

o 3.3

o 3.4

78


Luogo: Dipartimento IET, Laboratorio Blu

Durata: 3 ore

Attività:


Stesura dei paragrafi relativi all’analisi CoCoMo, in particolare:

o 3.5

o 3.6

o 3.7

o 3.8

o 3.9



Durata: 3 ore

Attività:


Elaborazione del piano di Qualità insieme al QE.

Stesura del 5° capitolo paragrafi relativo al piano di Qualità.

Data: 1 Giugno2011


Durata: 4 ore

Attività:

Stesura del 6° capitolo relativo al piano di Testing

Revisione generale dei capitoli precedentemente scritti

Elaborazione della presentazione in PowerPoint insieme al QE

SaniSystem_stampa

Documents

Transcript of SaniSystem_stampa