Post on 05-Jul-2015
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
1
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:
Consultare i profili di ogni paziente registrato.
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
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 laboratorio di analisi sarà in grado di
effettuare le seguenti operazioni:
Consultare i profili di ogni paziente registrato.
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
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 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
Secondary Actor(s) Nessuno
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
Alternative Flow(s) Nessuno
16
Caso d’uso CompilazioneRicetta
Use Case ID UC4
Brief Description Medico compila una ricetta a un paziente
Primary Actor(s) Medico
Secondary Actor(s) Nessuno
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
Alternative Flow(s) Nessuno
Caso d’uso AllegareRicetta
Use Case ID UC5
Brief Description Medico allega una ricetta alla cartella clinica del paziente
Primary Actor(s) Medico
Secondary Actor(s) Nessuno
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
Alternative Flow(s) Nessuno
17
Caso d’uso AllegareEsame
Use Case ID UC6
Brief Description Medico allega una nuova richiesta di esame alla cartella clinica
del paziente.
Primary Actor(s) Medico
Secondary Actor(s) Nessuno
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).
3.1. Il sistema informa il Medico della non correttezza dei dati.
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.
Alternative Flow(s) Nessuno
18
Caso d’uso CreaCartellaClinica
Use Case ID UC7
Brief Description Il MedicoDiFamiglia crea la cartella clinica del paziente
Primary Actor(s) MedicoDiFamiglia
Secondary Actor(s) Nessuno
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.
3. IF (il sistema non riconosce i dati inseriti).
3.1. Il sistema informa il Medico della non correttezza dei dati.
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
Alternative Flow(s) Nessuno
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
Secondary Actor(s) Nessuno
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
Alternative Flow(s) Nessuno
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
Secondary Actor(s) Nessuno
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.
Alternative Flow(s) Nessuno
Caso d’uso InoltraRichiestaRimborso
Use Case ID UC10
Brief Description Gli attori inoltrano una richiesta di rimborso alla ASL
Primary Actor(s) Farmacista, LaboratorioDiAnalisi
Secondary Actor(s) Nessuno
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
Alternative Flow(s) Nessuno
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
Secondary Actor(s) Nessuno
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. IF (il sistema non riconosce i dati inseriti).
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.
Alternative Flow(s) Nessuno
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
Secondary Actor(s) Nessuno
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. IF (il sistema non riconosce i dati inseriti).
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.
Alternative Flow(s) Nessuno
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:
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
RicercaRicettaAttiva
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
RicercaProfiloPaziente
7 Alta
Login
4 Bassa
RegistrazioneSistema
4 Bassa
CompilazioneRicetta
5 Media
AllegareRicetta
4 Bassa
AllegareEsame
4 Bassa
CreaCartellaClinica
5 Media
RicercaRicettaAttiva
5 Media
RicercaEsame
5 Media
InoltraRichiestaRimborso
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
RicercaProfiloPaziente
3 Bassa
Login
3 Bassa
RegistrazioneSistema
6 Alta
CompilazioneRicetta
6 Alta
AllegareRicetta
3 Bassa
AllegareEsame
3 Bassa
CreaCartellaClinica
6 Alta
RicercaRicettaAttiva
3 Bassa
RicercaEsame
3 Bassa
InoltraRichiestaRimborso
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
La capacità del prodotto software di
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à
La capacità del prodotto software di
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à
La capacità del prodotto software di
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à
La capacità del prodotto software di
permettere all’utente di operare con
esso e controllarlo.
Numero di errori
commessi dagli utenti < 10 / giorno
57
7.1.1.4. Efficienza
SOTTO
CATEGORIA DESCRIZIONE METRICA VALORE
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
CATEGORIA DESCRIZIONE METRICA VALORE
Analizzabilità
La capacità del prodotto
software di essere analizzato
al fine di rilevare errori nel
codice
Numero di cause
di difetti identificate 100 %
Modificabilità
La capacità del prodotto
software di permettere di
effettuare una specifica
modifica
Livello di
documentazione e
grado di modularità
del sistema
Alto
Stabilità
La capacità del prodotto
software di evitare effetti
inattesi a causa di modifiche
del software
Percentuale
riduzione rischio di
comportamenti
inaspettati a seguito
di modifiche
< 1 %
Testabilità
La capacità del prodotto
software di permettere la
validazione delle modifiche
al codice
Numero di moduli
non testabili
indipendentemente
0
58
7.1.1.6. Portabilità
SOTTO
CATEGORIA DESCRIZIONE METRICA VALORE
Adattabilità
La capacità del prodotto
software di essere adattato
a diversi ambienti operativi
senza modifiche del codice.
Numero di
piattaforme
sottostanti
supportate
2 (*)
Installabilità
La capacità del prodotto
software di essere installato
in un ambiente specifico.
Tempo necessario
per l’installazione 8 ore
Coesistenza
La capacità del prodotto
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:
Infrastruttura tra terminale e database attivo
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:
Selezionato RegistrazioneSistema
Mancato inserimento di alcune informazioni obbligatorie
Output atteso: Richiesta completamento di tutti i campi obbligatori
Input scorretto:
Selezionato RegistrazioneSistema
Inserimento di alcune informazioni non consistenti
Output atteso: Richiedere informazioni per i campi non consistenti
Precondizioni:
Infrastruttura tra terminale e database attivo
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:
Iniziata procedura di compilazione ricetta
mancato inserimento di dati obbligatori
Output atteso: sistema richiede i dati mancanti
Input scorretto:
Iniziata procedura di compilazione ricetta
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 loggato al sistema
Medico sta visualizzando la cartella clinica di un paziente
Infrastruttura tra terminale e database attivo
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:
Selezione di allegare esame
Mancato inserimento di informazioni necessarie
Output atteso: Sistema richiede inserimento delle informazioni mancanti
Input scorretto:
Selezione di allegare esame
Inserimento di dati inconsistenti
Output atteso: Sistema richiede inserimento di dati consistenti
Precondizioni:
Medico loggato al sistema
Medico che sta visualizzando il profilo di un paziente
Infrastruttura tra terminale e database attiva
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:
MedicoDiFamiglia seleziona creazione di una cartella clinica
Mancato inserimento di dati obbligatori
Output atteso: Sistema richiede i dati mancanti
Input scorretto:
MedicoDiFamiglia seleziona creazione di una cartella clinica
Inserimento dati inconsistenti
Output atteso: Sistema richiede il nuovo inserimento dei dati inconsistenti
Precondizioni:
MedicoDiFamiglia loggato al sistema
Infrastruttura tra terminale e database attivo
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
Infrastruttura tra terminale e database attiva
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
Infrastruttura tra terminale e database attiva
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:
Infrastruttura tra terminale e database attiva
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
Infrastruttura tra terminale e database attiva
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
Infrastruttura tra terminale e database attivo
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
Migliorini Giacomo – QE
Mucci Giacomo – TS & L
È 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
Partecipanti e ruolo:
Nigi Mirko – PM
Migliorini Giacomo – QE
Mucci Giacomo – TS & L
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
Data: 20 Aprile 2011
Luogo: Dipartimento Ing. Informatica – Aula ADInform
Durata: 3 ore
Partecipanti e ruolo:
Nigi Mirko – PM
Migliorini Giacomo – QE
Mucci Giacomo – TS & L
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
Partecipanti e ruolo:
Nigi Mirko – PM
Migliorini Giacomo – QE
Mucci Giacomo – TS & L
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
Luogo: Dipartimento Ing. Informatica – Aula ADInform 1
Durata: 2 ore
Partecipanti e ruolo:
Nigi Mirko – PM
Migliorini Giacomo – QE
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.
Data: 18 Maggio 2011
Luogo: Dipartimento Ing. Informatica – Aula ADInform 1
Durata: 3 ore
Partecipanti e ruolo:
Nigi Mirko – PM
Mucci Giacomo – TS & L
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
Data: 26 Maggio 2011
Luogo: Dipartimento Ing. Informatica – Aula Laboratorio Blu
Durata: 3 ore
Partecipanti e ruolo:
Nigi Mirko – PM
72
Migliorini Giacomo – QE
Mucci Giacomo – TS & L
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
Partecipanti e ruolo:
Nigi Mirko – PM
Migliorini Giacomo – QE
Mucci Giacomo – TS & L
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
Luogo: AdInf1, Università di Pisa
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
Luogo: AdInf1, Università di Pisa
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
Luogo: AdInf1, Università di Pisa
Durata: 2h
Attività: Valutazione indici non aggiustanti della FP per determinazione delle linee di codice.
Data: 18/05/2011
Luogo: AdInf1, Università di Pisa
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
Luogo: ADInf1, Universita’ di Pisa
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
Luogo: ADInf1, Universita’ di Pisa
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
Data: 13 Aprile 2011
Luogo: Dipartimento IET, aula ADInform1
Durata: 4 ore
Attività:
Elaborazione del diagramma delle classi.
Stesura dei seguenti paragrafi:
o 1.3
o 1.5
o 2
o 2.1
Data: 20 Aprile 2011
Luogo: Dipartimento IET, aula ADInform1
Durata: 3 ore
Attività:
Elaborazione delle specifiche dei casi d’uso.
Stesura dei seguenti paragrafi:
o 1.3.2
o 1.2
Supporto al PM per la valutazione dello sforzo.
Data: 4 Maggio 2011
Luogo: Dipartimento IET, aula ADInform1
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
Data: 18 Maggio 2011
Luogo: Dipartimento IET, Laboratorio Blu
Durata: 3 ore
Attività:
Correzione generale dei capitoli precedentemente scritti
Stesura dei paragrafi relativi all’analisi CoCoMo, in particolare:
o 3.5
o 3.6
o 3.7
o 3.8
o 3.9
Data: 26 Maggio 2011
Luogo: Dipartimento IET, Laboratorio Blu
Durata: 3 ore
Attività:
Correzione generale dei capitoli precedentemente scritti
Elaborazione del piano di Qualità insieme al QE.
Stesura del 5° capitolo paragrafi relativo al piano di Qualità.
Data: 1 Giugno2011
Luogo: Dipartimento IET, Laboratorio Blu
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