Sei sulla pagina 1di 188

UNIVERSITA DI PISA Facolt di Ingegneria

Corso di Laurea in INGEGNERIA INFORMATICA PER LA GESTIONE DAZIENDA

Calcetto 2.0
Progetto di Gestione della Qualit

Autori: Fabio Aiuto Irene Bont Federico Bianucci

Anno Accademico 2009-2010

Indice
Capitolo 1 - Specifica dei requisiti .................................................................................................................... 9 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. Presentazione .................................................................................................................................... 9 Specifiche informali del sistema ........................................................................................................ 9 Studio di fattibilit ........................................................................................................................... 11 Attori................................................................................................................................................ 12 Requisiti Funzionali .......................................................................................................................... 12 Dettaglio dei casi duso.................................................................................................................... 15 Requisiti non funzionali ................................................................................................................... 48 Requisiti interni ed esterni ...................................................................................................... 48

1.7.1. 1.8.

Glossario .......................................................................................................................................... 50

Capitolo 2 Relazione di Progetto ................................................................................................................. 51 2.1 2.2 Diagramma dei package .................................................................................................................. 51 Package di analisi ............................................................................................................................. 52 Package Profili ......................................................................................................................... 53 Package Partite ........................................................................................................................ 53 PackageSquadre ...................................................................................................................... 54

2.2.1 2.2.2 2.2.3 2.3 2.4 2.5

Diagramma delle componenti ......................................................................................................... 55 Package di progetto (sottosistemi e interfacce).............................................................................. 56 Diagrammi di sequenza ................................................................................................................... 57 AggiungiGiocatore ................................................................................................................... 57 AvanzaFase .............................................................................................................................. 58 CambiaDataIncontro................................................................................................................ 59 CambiaDatiGiocatore .............................................................................................................. 59 CancellaGiocatore.................................................................................................................... 60 ConfermaListaDefinitiva .......................................................................................................... 61 EmettiMulta ............................................................................................................................. 62 InserisciData ............................................................................................................................ 63 InserisciReferto ........................................................................................................................ 64 InserisciRisultato...................................................................................................................... 65 RichiediCambioData ................................................................................................................ 66 RitiraSquadra ........................................................................................................................... 67 2

2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 2.5.8 2.5.9 2.5.10 2.5.11 2.5.12

2.5.13 2.5.14 2.5.15 2.5.16 2.5.17 2.5.18 2.5.19 2.5.20

TrovaSquadra........................................................................................................................... 67 VisualizzaDatiGiocatore ........................................................................................................... 68 VisualizzaDettagliSquadra ....................................................................................................... 68 VisualizzaElencoSquadre ......................................................................................................... 69 VisualizzaGiocatoriSquadra ..................................................................................................... 70 VisualizzaMiaSquadra .............................................................................................................. 71 VisualizzaPartita....................................................................................................................... 72 VisualizzaRichieste ................................................................................................................... 72

Capitolo 3 Piano di processo........................................................................................................................ 73 3.1. 3.2. Introduzione e definizioni................................................................................................................ 73 Metodologie pesanti ....................................................................................................................... 75 Il modello waterfall.................................................................................................................. 75 Il modello trasformazionale..................................................................................................... 76

3.2.1. 3.2.2. 3.3.

Metodologie iterative ...................................................................................................................... 77 Il modello a spirale .................................................................................................................. 77 Il modello UP ........................................................................................................................... 78

3.3.1. 3.3.2. 3.4.

Metodologie agili ............................................................................................................................. 80 Code and fix ............................................................................................................................. 80 Synchronize and stabilize ........................................................................................................ 81 Extreme Programming ............................................................................................................. 82

3.4.1. 3.4.2. 3.4.3. 3.5.

La nostra scelta: il RUP .................................................................................................................... 83 Le caratteristiche del software ................................................................................................ 83 La struttura di RUP................................................................................................................... 84 L'iterazione: i 5 workflow ........................................................................................................ 85 Ciclo di Vita .............................................................................................................................. 85

3.5.1. 3.5.2. 3.5.3. 3.5.4. 3.6.

Analisi specifica delle fasi ................................................................................................................ 86 Inception Phase ....................................................................................................................... 86 Elaboration Phase .................................................................................................................... 87 Construction Phase .................................................................................................................. 88 Transition Phase ...................................................................................................................... 89

3.6.1. 3.6.2. 3.6.3. 3.6.4. 3.7. 3.8. 3.9.

Piano di Produzione Preventivo ...................................................................................................... 90 Diagramma di GANTT ...................................................................................................................... 91 Analisi del Piano Svolto.................................................................................................................... 92

Capitolo 4 Piano di Qualit .......................................................................................................................... 93 4.1. Modello di qualit ISO 9126 ............................................................................................................ 93 3

4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.1.6. 4.1.7. 4.1.8. 4.2.

Qualit interna ed esterna....................................................................................................... 94 Funzionalit ............................................................................................................................. 96 Affidabilit ............................................................................................................................... 96 Usabilit ................................................................................................................................... 97 Efficienza.................................................................................................................................. 97 Manutenibilit ......................................................................................................................... 98 Portabilit ................................................................................................................................ 98 Qualit in uso ........................................................................................................................... 99

Modello di qualit ISO 12207 ........................................................................................................ 100 Processi primari ..................................................................................................................... 100

4.2.1.

Capitolo 5 Piano di testing ......................................................................................................................... 102 5.1. Test plan ........................................................................................................................................ 102 Schedule dellattivit di testing ............................................................................................. 103

5.1.1. 5.2.

Test Design Specification ............................................................................................................... 103 Tecnica di Testing .................................................................................................................. 103

5.2.1. 5.3.

Test Case Specification .................................................................................................................. 103 Aggiungi Giocatore ................................................................................................................ 104 Autenticazione ....................................................................................................................... 105 Avanza fase ............................................................................................................................ 106 Cambia Data Partita ............................................................................................................... 107 Cambia Dati Giocatore........................................................................................................... 108 Cambia Dati Organizzatore .................................................................................................... 109 Cancella Giocatore ................................................................................................................. 110 Cancella Organizzatore .......................................................................................................... 111 Conferma Lista Definitiva ...................................................................................................... 111 Crea Account Organizzatore .................................................................................................. 112 Crea Nuovo Capitano ............................................................................................................. 113 Emetti Multa .......................................................................................................................... 116 Inserisci Data ......................................................................................................................... 117 Inserisci referto ...................................................................................................................... 118 Inserisci Risultati .................................................................................................................... 119 Notifica Certificati .................................................................................................................. 120 Notifica Pagamenti ................................................................................................................ 121 Pubblica Data Fine Iscrizioni .................................................................................................. 122 Richiedi Cambio Data............................................................................................................. 123 4

5.3.1. 5.3.2. 5.3.3. 5.3.4. 5.3.5. 5.3.6. 5.3.7. 5.3.8. 5.3.9. 5.3.10. 5.3.11. 5.3.12. 5.3.13. 5.3.14. 5.3.15. 5.3.16. 5.3.17. 5.3.18. 5.3.19.

5.3.20. 5.3.21. 5.3.22. 5.3.23. 5.3.24. 5.3.25. 5.3.26. 5.3.27. 5.3.28. 5.3.29. 5.3.30. 5.3.31.

Ritira Squadra ........................................................................................................................ 124 Visualizza Dati Giocatore ....................................................................................................... 125 Trova Dati Organizzatore ....................................................................................................... 126 Trova Squadra ........................................................................................................................ 127 Visualizza Elenco Squadre...................................................................................................... 127 Visualizza Partita .................................................................................................................... 128 Visualizza Referto .................................................................................................................. 128 Visualizza Regolamento ......................................................................................................... 129 Visualizza Dettagli Squadra.................................................................................................... 129 Visualizza Giocatori Squadra ................................................................................................. 130 Visualizza Mia Squadra .......................................................................................................... 130 Visualizza Richieste ................................................................................................................ 131

Capitolo 6 Analisi dello sforzo ................................................................................................................... 132 6.1. Piano di valutazione dello sforzo ................................................................................................... 132 Presentazione ........................................................................................................................ 132 Metriche di misurazione ........................................................................................................ 132 Metriche dimensionali ........................................................................................................... 133 Metriche funzionali................................................................................................................ 133

6.1.1. 6.1.2 6.1.3 6.1.4 6.2. 6.3. 6.4.

Analisi dei punti funzione .............................................................................................................. 134 Calcolo dei Function Point ............................................................................................................. 135 Calcolo dei valori di conteggio per ciascun indice ......................................................................... 145 Determinazione della complessit degli EI (external inputs) ................................................ 145 Determinazione della complessit degli EQ (external queries)............................................. 146 Determinazione della complessit degli EO (external outputs) ............................................ 147 Determinazione della complessit degli EIF (external files) .................................................. 148 Determinazione della complessit degli ILF (internal files) ................................................... 148 Calcolo dei fattori di aggiustamento ..................................................................................... 149 Calcolo FP e LoC ..................................................................................................................... 149

6.4.1. 6.4.2. 6.4.3. 6.4.4. 6.4.5. 6.4.6. 6.4.7. 6.5.

Valutazione dello sforzo con CoCoMo........................................................................................... 150 Scale Driver ............................................................................................................................ 150 Cost Driver ............................................................................................................................. 151 Calcolo del valore conteggio_totale ...................................................................................... 152 Calcolo della sommatoria degli Fi .......................................................................................... 153 Determinazione dei FP .......................................................................................................... 154 Configurazione preliminare del software .............................................................................. 155 5

6.5.1. 6.5.2. 6.5.3. 6.5.4. 6.5.5. 6.5.6.

6.5.7. 6.5.8. 6.5.9. 6.5.10.

Stime prodotte dal software ................................................................................................. 161 Stima dello sforzo .................................................................................................................. 161 Stima della durata.................................................................................................................. 163 Stima del costo ...................................................................................................................... 164

Capitolo 7 Bibliografia................................................................................................................................ 165 Capitolo 8 Strumenti software utilizzati ................................................................................................... 166 Appendice A Verbali delle riunioni............................................................................................................ 167

Indice delle figure


Figura 1 - Diagramma dei casi d'uso ................................................................................................................ 14 Figura 2 Diagramma dei package ................................................................................................................. 51 Figura 3 - Package di analisi ............................................................................................................................. 52 Figura 4 - Package Profili ................................................................................................................................. 53 Figura 5 - Package Partite ................................................................................................................................ 53 Figura 6 - Package Squadre.............................................................................................................................. 54 Figura 7 - Diagramma dei componenti ............................................................................................................ 55 Figura 8 Diagramma delle classi di progetto ................................................................................................ 56 Figura 9 AggiungiGiocatore .......................................................................................................................... 57 Figura 10 - Avanza Fase ................................................................................................................................... 58 Figura 11 - CambiaDataIncontro ..................................................................................................................... 59 Figura 12 CambiaDatiGiocatore.................................................................................................................... 59 Figura 13 - CancellaGiocatore.......................................................................................................................... 60 Figura 14 - Conferma Lista Definitiva .............................................................................................................. 61 Figura 15 - Emetti Multa .................................................................................................................................. 62 Figura 16 - InserisciData .................................................................................................................................. 63 Figura 17 - InserisciReferto .............................................................................................................................. 64 Figura 18 - InserisciRisultato............................................................................................................................ 65 Figura 19 - RichiediCambioData ...................................................................................................................... 66 Figura 20 - RitiraSquadra ................................................................................................................................. 67 Figura 21 - TrovaSquadra................................................................................................................................. 67 Figura 22 - VisualizzaDatiGiocatore ................................................................................................................. 68 Figura 23 VisualizzaDettagliSquadra............................................................................................................. 68 Figura 24 - VisualizzaElencoSquadre ............................................................................................................... 69 Figura 25 - VisualizzaGiocatoriSquadra ........................................................................................................... 70 Figura 26 VisualizzaMiaSquadra ................................................................................................................... 71 Figura 27 - VisualizzaPartita............................................................................................................................. 72 Figura 28 - VisualizzaRichieste ......................................................................................................................... 72 Figura 29 - Ciclo di vita di un prodotto software ............................................................................................. 74 Figura 30 - Modello waterfall .......................................................................................................................... 75 Figura 31 - Modello a spirale ........................................................................................................................... 77 Figura 32 - Unified Process .............................................................................................................................. 78 Figura 33 - Modello "Code and fix" ................................................................................................................. 80 Figura 34 - Rational Unified Process ................................................................................................................ 84 Figura 35 - Attivit (Workflow), con fasi ed interazioni................................................................................... 86 Figura 36 - Diagramma di GANTT .................................................................................................................... 91 Figura 37 - Caratteristiche ISO 9126 ................................................................................................................ 94 Figura 38 - Cost Driver Report ....................................................................................................................... 151 Figura 39 - UnAdjusted Function Points ........................................................................................................ 152 7

Figura 40 - Fattore di aggiustamento ............................................................................................................ 153 Figura 41 - Adjusted Function Point .............................................................................................................. 154 Figura 42 - Scelta del modello di analisi ........................................................................................................ 155 Figura 43 - Scelta del numero di linee di codice previste per ogni FP ........................................................... 156 Figura 44 - Numero di linee di codice sorgente previste (SLOC) ................................................................... 157 Figura 45 - Cost Driver Editor ........................................................................................................................ 158 Figura 46 - Costo mensile di ciascuna delle figure impegnate nella realizzazione del sistema .................... 159 Figura 47 - Percentuale di lavoro in relazione alle fasi di sviluppo ............................................................... 160 Figura 48 - Effort Report ................................................................................................................................ 162 Figura 49 - Stima della durata in relazione alle fasi di sviluppo .................................................................... 163 Figura 50 - Cost Report .................................................................................................................................. 164

Capitolo 1 - Specifica
1.1. Presentazione

dei requisiti

Il sistema consiste in un'applicazione di supporto alla gestione di un torneo di calcetto. Lo scopo del sistema quello di offrire agli utenti un supporto informatico al fine di poter svolgere pi agevolmente i loro compiti. Il sistema deve essere in grado di ricevere le iscrizioni delle squadre e dei giocatori, comunicare calendario e risultati degli incontri, permettere ai capitani delle squadre di comunicare con gli organizzatori. Il tutto fruibile via web attraverso un sito che funge da interfaccia col sistema.

1.2.

Specifiche informali del sistema


Il SW in questione deve essere in grado di far iscrivere nuove squadre al torneo e aggiungere nuovi giocatori all'interno di squadre gi create. La figura del capitano registra la squadra al torneo e contestualmente, tramite linserimento dei propri dati personali, si registra al sistema anche come primo giocatore della squadra creata. Non possono esistere squadre senza giocatori. Il primo giocatore iscritto il capitano. Solo il capitano, previa autenticazione, pu aggiungere o cancellare giocatori dalla sua squadra fornendo i loro dati personali (nome, cognome, data di nascita, numero di telefono). L'iscrizione della squadra considerata ufficiale soltanto quando viene versata la quota di iscrizione (la quota della squadra e non dei singoli giocatori) e tutti i giocatori hanno consegnato il certificato medico. La consegna del certificato medico effettuata manualmente dal capitano allorganizzatore. I giocatori che non consegnano il certificato medico entro il termine delle iscrizioni non faranno parte del torneo. Esiste una data prefissata di fine iscrizione, decisa e pubblicata sul sito dallorganizzatore, entro la quale tutte le squadre devono aver e pagato la quota di iscrizione.

Se entro la data di fine iscrizione ci sono squadre che non hanno versato la quota di partecipazione queste vengono escluse. Dopo la data di fine iscrizione non possono si pi iscrivere altre squadre, aggiungere, eliminare o cambiare giocatori di una squadra iscritta al torneo. Scaduti i termini le squadre iscritte che non hanno almeno 5 giocatori col certificato o che non hanno pagato non faranno parte del torneo. Una squadra non pu saldare il pagamento se non ha registrato almeno 5 giocatori. Solo dopo la scadenza dei termini per liscrizione il sistema fornisce agli organizzatori la lista definitiva delle squadre partecipanti al torneo e verr anche pubblicata sul sito. Considerando la natura del torneo, non previsto il pagamento tramite il sistema. Solo lorganizzatore ha la possibilit di notificare al sistema l'avvenuto pagamento. In qualunque momento (anche durante il torneo) il capitano di una squadra pu richiedere il ritiro della sua squadra con conseguente eliminazione dal torneo e senza nessun rimborso della quota di iscrizione. Dopo la chiusura delle iscrizioni il sistema elabora un calendario con tutti gli accoppiamenti delle squadre. Gli organizzatori (iscritti al sistema immettendo i loro dati personali e dotati di username e password) possono pubblicare sul sito gli accoppiamenti, le date delle partite e i vari risultati accessibili da qualunque visitatore Ogni visitatore pu visualizzare lelenco delle squadre iscritte con i relativi giocatori. Gli organizzatori al termine di ogni partita stilano un referto. Solo i capitani hanno la possibilit di comunicazione diretta con gli organizzatori: possono vedere il referto di qualunque partita, possono formalizzare la richiesta di un cambio della data di un incontro, vedere i giocatori di una squadra e visualizzare il regolamento deciso dagli organizzatori. Il sistema dovr permettere di tenere aggiornate le informazioni relative alle squalifiche (se ce ne sono di nuove per somma di ammonizioni in partite diverse e turni di squalifica ancora da scontare). Gli organizzatori, i capitani e qualunque visitatore possono visualizzare la lista dei giocatori squalificati.
10

Gli organizzatori tramite il sistema possono emettere multe per singoli giocatori o intere squadre. E richiesta anche limplementazione dei seguenti meccanismi di sicurezza: il personale amministrativo deve autenticarsi (mediante una password, che luni ca per tutto il personale amministrativo e decisa al momento dellistallazione del sistema) prima di poter effettuare qualsiasi tipo di operazione. Anche le operazioni degli organizzatori sono permesse previa autenticazione, mediante username e password personali.

1.3.

Studio di fattibilit

Lo scopo dello studio di fattibilit quello di fornire gli elementi di valutazione necessari a prendere una decisione riguardante la realizzazione operativa del progetto. L'opportunita di realizzare il progetto valutata considerando vari ambiti di fattibilit. In particolare sono effettuati: Uno studio di fattibilit tecnica, che verifica che gli aspetti tecnici proposti per la realizzazione del sistema sono effetivamente realizzabili. Uno studio di fattibilit organizzativa, da cui emerge che il progetto realizzabile nell'attuale organizzazione di Calcetto 2.0. Uno studio di fattibilit economica, che dimostra che le risorse economiche necessarie alla realizzazione del sistema sono giustificate dal vantaggio competitivo che la societ otterr dal sistema stesso nel breve-medio periodo. Uno studio di fattibilit temporale, da cui risulta che il sistema realizzabile nei tempi richiesti da Calcetto 2.0. Uno studio di fattibilit motivazionale, secondo cui il nuovo sistema aumenter il livello di soddisfazione percepita dagli utenti grazie alla facilit di utilizzo ed offrir pertanto nuovi stimoli motivazionali.

11

1.4.

Attori
Capitano Visitatore Amministratore Organizzatori SistemaGestioneEmail

1.5.

Requisiti Funzionali

I requisiti funzionali definiscono i comportamenti attesi del sistema in termini di funzionalit e/o servizi offerti all'utente. Il diagramma dei casi d'uso in Figura 1 illustra come tali requisiti vengono percepiti e utilizzati dagli attori del sistema. 1.5.1. CAPITANO 1.5.1.1. Il sistema deve consentire al capitano di autenticarsi 1.5.1.2. Il sistema deve consentire al capitano di registrare una squadra al torneo attraverso la sua registrazione 1.5.1.3. Il sistema deve consentire al capitano di aggiungere nuovi giocatori alla sua squadra 1.5.1.4. Il sistema deve consentire al capitano di cancellare giocatori della sua squadra 1.5.1.5. Il sistema deve consentire al capitano di cambiare i dati dei giocatori 1.5.1.6. Il sistema deve permettere al capitano di chiedere in qualunque momento il ritiro dal torneo della sua squadra 1.5.1.7. Il sistema deve consentire al capitano di conoscere gli accoppiamenti, le date degli incontri, i risultati delle partite 1.5.1.8. Il sistema deve consentire al capitano di vedere i referti di tutte le partite 1.5.1.9. Il sistema deve consentire al capitano di chiedere un cambio di data 1.5.1.10. Il sistema deve consentire al capitano di visualizzare lelenco dei giocatori della sua squadra, con relative informazioni sui certificati consegnati e sul pagamento 1.5.1.11. Il sistema deve consentire al capitano di visualizzare il regolamento 1.5.1.12. Il sistema deve consentire al capitano, solo dopo la chiusura delle iscrizioni, di conoscere per ogni squadra chi sono i giocatori e le loro eventuali squalifiche 1.5.2. VISITATORE 1.5.2.1. Il sistema deve consentire allutente, solo dopo la chiusura delle iscrizio ni, di vedere la lista delle squadre partecipanti al torneo con i rispettivi giocatori e le varie squalifiche
12

1.5.2.2. Il sistema deve consentire allutente di visualizzare gli accoppiamenti, le date degli incontri e i risultati delle partite 1.5.3. AMMINISTRATORE 1.5.3.1. Il sistema deve consentire allamministratore di autenticarsi 1.5.3.2. Il sistema deve consentire allamministratore di creare gli account per gli organizzatori 1.5.3.3. Il sistema deve consentire allamministratore di cambiare i dati di un organizzatore 1.5.3.4. Il sistema deve consentire allamministratore di cancellare un organizzatore

1.5.4. ORGANIZZATORE 1.5.4.1. Il sistema deve consentire allorganizzatore di autenticarsi 1.5.4.2. Il sistema deve consentire all organizzatore di notificare i pagamenti effettuati 1.5.4.3. Il sistema deve consentire all organizzatore di verificare che non si iscrivano squadre o nuovi giocatori oltre la data di fine iscrizioni 1.5.4.4. Il sistema deve consentire all organizzatore di controllare che i pagamenti non vengano fatti per squadre con meno di 5 giocatori (anche se non tutti 5 hanno portato il certificato) ed oltre la data di fine iscrizioni 1.5.4.5. Il sistema deve consentire all organizzatore di notificare la consegna dei certificati medici 1.5.4.6. Il sistema deve consentire all organizzatore di controllare che vengano esclusi dal torneo i giocatori che non hanno consegnato il certificato medico 1.5.4.7. Il sistema deve consentire allorganizzatore di avere, dopo la chiusura delle iscrizioni, una lista definitiva delle squadre partecipanti al torneo con i relativi giocatori 1.5.4.8. Il sistema deve consentire allorganizzatore di pubblicare sul sito gli
accoppiamenti, con le date ed i risultati di ogni partita 1.5.4.9. Il sistema deve consentire allorganizzatore di inserire il referto di ogni partita 1.5.4.10. Il sistema deve consentire allorganizzatore di pubblicare un regolamento del torneo 1.5.4.11. Il sistema deve consentire allorganizzatore di cambiare le date degli incontri 1.5.4.12. Il sistema deve consentire allorganizzatore di conoscere per ogni squadra la situazione del loro pagamento nonch lelenco dei giocatori registrati con linformazione sulla consegna dei loro certificati. 1.5.4.13. Il sistema deve consentire allorganizzatore di conoscere per ogni squadra chi sono i giocatori squalificati 1.5.4.14. Il sistema deve consentire allorganizzatore di predisporre multe a singoli giocatori o ad intere squadre

13

1.5.5.SISTEMAGESTIONEEMAIL 1.5.5.1.

Il sistema deve consentire al SistemaGestioneEmail di avvisare tramite mail il cambiamento della data dellincontro.

Figura 1 - Diagramma dei casi d'uso

14

1.6.

Dettaglio dei casi duso

Ogni istanza di un caso duso (scenario) descrive le effettive modalit di utilizzo del sistema specificando in particolare: Chi inizia il caso duso (Primary Actor) Eventuali altri attori coinvolti (Secondary Actor) La sequenza dei passi con cui viene svolta linterazione tra attori e sistema (Main Flow)

Vengono riportati di seguito gli scenari di successo (scenario base) e alcuni possibili scenari di fallimento dei singoli casi duso.

AggiungiGiocatore

Extension Use Case

AggiungiGiocatore

Use Case ID

UC01

Super Use Case Nessuno.

Brief Description Permette al capitano di aggiungere un giocatore alla propria squadra se le iscrizioni sono ancora aperte.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema. 2. Le iscrizioni sono ancora aperte. 3. Il capitano ha visualizzato l'elenco dei giocatori della squadra.

15

Main Flow

1. Il caso duso inizia quando il capitano seleziona AggiungiGiocatore. 2. Il sistema chiede al capitano di inserire nome, cognome, data di nascita ed email del nuovo giocatore. 3. Il capitano inserisce nome, cognome, data di nascita ed e-mail del nuovo giocatore. 4. Il sistema aggiunge il nuovo giocatore.

Postconditions 1. Un nuovo giocatore stato aggiunto alla squadra del capitano.

Alternative flows

Nessuno.

Autenticazione

Use Case

Autenticazione

Use Case ID

UC02

Super Use Case

Nessuno

Brief Description

L'utente si connette al sistema e viene autenticato.

Primary Actor

Utente.

Secondary Actor(s)

Nessuno.

Preconditions

L'utente non connesso al sistema.

16

Primary Scenario

1. Il caso duso inizia quando lutente seleziona Log On. 2. WHILE lutente non autenticato e il numero di tentativi minore o uguale a tre. 2.1. Il sistema chiede allutente username e password. 2.2. Lutente inserisce username e password. 2.3. Username e password sono corretti. 3. Il sistema ha autenticato lutente.

Postconditions

L'utente stato autenticato.

Secondary Scenario: AutenticazioneFallita

1. Il caso duso inizia quando lutente seleziona Log On. 2. While lutente non autenticato e il numero di tentativi minore o uguale a tre. 2.1. Il sistema chiede allutente username e password. 2.2. Lutente inserisce username e password. 2.3. Username e/o password non sono corretti. 3. Il sistema non permette allutente di autenticarsi.

Postconditions

1. Lutente non stato autenticato. 2. Il sistema non permette allutente di autenticarsi.

AvanzaFase

Use Case

AvanzaFase

Use Case ID

UC03

Super Use Case Nessuno.

17

Brief Description Permette al sistema di elaborare gli accoppiamenti delle squadre per una nuova fase ed aggiornare gli squalificati per le fasi successive. Primary Actor Organizzatore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema. 2. Fase attuale terminata.

Main Flow

1. Il caso d'uso inizia quando l'organizzatore seleziona "AvanzaFase". 2. Il sistema ricava la lista delle squadre ancora in gara. 3. Il sistema elabora gli accoppiamenti della nuova fase con le relative date. 4. Il sistema aggiorna le giornate di squalifica da scontare per ogni giocatore.

Postconditions 1. Il sistema ha elaborato una nuova fase.

Alternative flows

Nessuno.

CambiaDataPartita

Extension Use Case

CambiaDataIncontro

Use Case ID

UC04

Super Use Case

Nessuno.

18

Brief Description L'organizzatore modifica la data di un incontro non ancora giocato.

Primary Actor

Organizzatore.

Secondary Actor(s)

SistemaGestioneEmail.

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la partita. 2. L'incontro non ancora stato giocato.

Main flow

1. L'organizzatore inserisce la nuova data per l'incontro. 2. Il sistema ottiene gli indirizzi email dei capitani delle squadre interessate al cambio di data. 3. Il sistema invia la richiesta di spedizione delle email al SistemaGestioneEmail. 4. Il SistemaGestioneEmail invia le email ai 2 capitani.

Postconditions

1. Il sistema ha memorizzato la nuova data. 2. Il sistema ha notificato il cambio di data ai 2 capitani.

Alternative flows Nessuno.

CambiaDatiGiocatore

Extension Use Case

CambiaDatiGiocatore

Use Case ID

UC05

19

Super Use Case

Nessuno.

Brief Description Permette al capitano di modificare i dati di un giocatore della squadra se le iscrizioni sono aperte.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema. 2. Le iscrizioni sono aperte. 3. Il capitano ha visualizzato l'elenco dei giocatori della sua squadra.

Main Flow

1. Il caso duso inizia quando il capitano seleziona CambiaDatiGiocatore. 2. Include(VisualizzaDatiGiocatore). 3. Il capitano modifica i dati del giocatore. 4. Il sistema registra la modifica dei dati del giocatore.

Postconditions

1. I dati di un giocatore sono stati modificati.

Alternative flows Nessuno.

CambiaDatiOrganizzatore

Use Case

CambiaDatiOrganizzatore

Use Case ID

UC06

20

Super Use Case

Nessuno.

Brief Description Permette all'amministratore di modificare i dati di un organizzatore gi registrato nel sistema.

Primary Actor

Amministratore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'amministratore connesso al sistema.

Main Flow

1. Il caso duso inizia quando lamministratore seleziona CambiaDatiOrganizzatore. 2. Include(TrovaDatiOrganizzatore). 3. Il sistema visualizza i dati dellorganizzatore. 4. Il capitano modifica i dati dellorganizzatore. 5. Il sistema registra la modifica dei dati dellorganizzatore.

Postconditions

1. I dati di un organizzatore sono stati modificati.

Alternative flows Nessuno.

CancellaGiocatore

Extension Use Case

CancellaGiocatore

21

Use Case ID

UC07

Super Use Case

Nessuno.

Brief Description Permette al capitano di cancellare un giocatore dalla squadra se le iscrizioni sono ancora aperte.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema. 2. Le iscrizioni sono aperte. 3. Il capitano ha visualizzato lelenco dei giocatori della sua squadra.

Main Flow

1. Il caso duso inizia quando il capitano seleziona CancellaGiocatore 2. Include(TrovaDatiGiocatore). 3. Il capitano cancella dati del giocatore. 4. Il sistema rimuove il giocatore dallelenco dei giocatori registrati..

Postconditions

1. Il sistema ha cancellato un giocatore dalla squadra.

Alternative flows Nessuno.

22

CancellaOrganizzatore

Use Case

CancellaOrganizzatore

Use Case ID

UC08

Super Use Case

Nessuno.

Brief Description Permette all'amministratore di cancellare l'account di un organizzatore.

Primary Actor

Amministratore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'amministratore connesso al sistema.

Main Flow

1. Il caso duso inizia quando lamministratore seleziona CancellaOrganizzatore. 2. Include(TrovaDatiOrganizzatore). 3. Il sistema visualizza i dati dellorganizzatore. 4. Il sistema rimuove laccount dellorganizzatore.

Postconditions

1. L'organizzatore e il suo account sono stati rimossi.

Alternative flows Nessuno.

23

ConfermaListaDefinitiva

Use Case

ConfermaListaDefinitiva

Use Case ID

UC09

Super Use Case Nessuno.

Brief Description L'organizzatore chiude le iscrizione e ottiene la liste definitiva delle squadre iscritte con relativi giocatori.

Primary Actor

Organizzatore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema.

Main flow

1. L'organizzatore notifica la chiusura delle iscrizioni. 2. Il sistema elimina le squadre per cui non stato notificato il pagamento. 3. Il sistema elimina le squadre che non hanno almeno 5 giocatori con certificato. 4. Per le squadre paganti, che hanno almeno 5 giocatori con certificato, il sistema elimina gli eventuali giocatori senza certificato. 5. Il sistema ottiene la lista definitiva delle squadre iscritte con relativi giocatori ammessi. 6. Il sistema stampa la lista definitiva delle squadre iscritte con relativi giocatori ammessi.

Postconditions

1. Le iscrizioni sono chiuse. 2. L'organizzatore ha a disposizione la lista definitiva delle squadre con giocatori.

Alternative

Nessuno.
24

flows

CreaAccountOrganizzatore

Use Case

CreaAccountOrganizzatore

Use Case ID

UC10

Super Use Case

Nessuno.

Brief Description Permette all'amministratore di creare l'account di un organizzatore.

Primary Actor

Amministratore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'amministratore connesso al sistema.

Main Flow

1. Il caso duso inizia quando lamministratore seleziona CreaAccountOrganizzatore. 2. Il sistema chiede di inserire nome, cognome, data nascita, e-mail e numero di telefono. 3. Il sistema chiede di inserire un username ed una password. 4. Il sistema crea un nuovo account per organizzatore.

Postconditions

1. Un nuovo account organizzatore stato creato.

Alternative flows Nessuno.

25

CreaNuovoCapitano

Use Case

CreaNuovoCapitano

Use Case ID

UC11

Super Use Case Nessuno.

Brief Description Permette ad un utente di registrarsi come capitano della squadra con conseguente registrazione di una nuova squadra.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano non connesso al sistema. 2. Le iscrizioni sono aperte.

Main Flow

1. Il caso duso inizia quando il capitano seleziona CreaNuovoCapitano. 2. Il sistema chiede al capitano di inserire un username ed una password. 3. Il capitano inserisce username e password. 4. Il sistema verifica che lusername scelto sia disponibile e la password sia valida. 5. WHILE lusername non disponibile o la password non valida. 5.1. Il sistema chiede al capitano di inserire un nuovo username e/o una nuova password. 6. Il sistema chiede al capitano di inserire nome, cognome, data di nascita, email, recapito telefonico e nome della squadra. 7. Il capitano inserisce tali informazioni. 8. WHILE nome della squadra gi stato scelto.
26

8.1. Il sistema chiede di scegliere un altro nome per la squadra. 9. Il sistema crea un account per il capitano. 10. Il sistema registra la nuova squadra ed inserisce il capitano come primo giocatore. Postconditions 1. Un nuovo capitano si registrato: il sistema gli ha creato un account. 2. Una nuova squadra si registrata. Alternative flows Nessuno.

EmettiMulta

Extension Use Case

EmettiMulta

Use Case ID

UC12

Super Use Case

Nessuno.

Brief Description

L'organizzatore emette multe ai danni di squadre o singoli giocatori.

Primary Actor

Organizzatore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la squadra.


27

Main flow

1. IF l'organizzatore seleziona "Multa intera squadra" 1.1 l'organizzatore inserisce l'entit della multa. 1.2 Il sistema stampa la multa. 1.3 Fine del caso d'uso. 2. L'organizzatore seleziona un giocatore. 3. L'organizzatore seleziona "Multa giocatore". 4. L'organizzatore inserisce l'entit della multa. 5. Il sistema stampa la multa.

Postconditions

1. Il sistema ha stampato la multa.

Alternative flows

Nessuno.

InserisciReferto

Extension Use Case

InserisciReferto

Use Case ID

UC13

Super Use Case

Nessuno.

Brief Description

L'organizzatore inserisce il referto di una partita giocata e il sistema aggiorna i turni di squalifica dei giocatori.

Primary Actor

Organizzatore.

28

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la partita.

Main flow

1. L'organizzatore inserisce i marcatori e il minuto della realizzazione. 2. L'organizzatore inserisce i cartellini assegnati ai giocatori per ciascuna squadra.

Postconditions

1. Il sistema ha memorizzato il referto.

Alternative flows

Nessuno.

InserisciRisultati

Extension Use Case

InserisciRisultati

Use Case ID

UC14

Super Use Case

Nessuno.

Brief Description

L'organizzatore inserisce il risultato di una partita.

Primary Actor

Organizzatore.

29

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la partita.

Main flow

1. L'organizzatore inserisce il risultato per la partita (solo il numero di gol fatti).

Postconditions

1. Il sistema ha memorizzato il risultato.

Alternative flows

Nessuno.

NotificaCertificati

Extension Use Case

NotificaCertificati

Use Case ID

UC15

Super Use Case

Nessuno.

Brief Description

L'organizzatore notifica la consegna del certificato medico per un giocatore di una squadra.

Primary Actor

Organizzatore

Secondary Actor(s)

Nessuno.

30

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la squadra. 3. L'organizzatore ha selezionato il giocatore. 4. Le iscrizioni sono aperte.

Main flow

1. L'organizzatore notifica la consegna del certificato medico per un giocatore.

Postconditions

1. Il sistema ha memorizzato l'avvenuta consegna del certificato.

Alternative flows

Nessuno.

NotificaPagamenti

Extension Use Case

NotificaPagamenti

Use Case ID

UC16

Super Use Case

Nessuno.

Brief Description

L'organizzatore notifica l'avvenuto pagamento della quota di iscrizione da parte di una squadra

Primary Actor

Organizzatore

Secondary Actor(s)

Nessuno.

31

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la squadra. 3. La squadra ha almeno 5 giocatori registrati (non certificati). 4. Il termine di chiusura di iscrizioni al torneo non scaduto.

Main flow

1. L'organizzatore notifica l'avvenuto pagamento per quella squadra. 2. Il sistema stampa una ricevuta.

Postconditions

1. Il sistema ha memorizzato l'avvenuto pagamento. 2. Il sistema ha stampato una ricevuta.

Alternative flows

Nessuno.

InserisciData

Use Case

InserisciData

Use Case ID

UC17

Super Use Case

Nessuno.

Brief Description

L'organizzatore inserisce, per ogni fase del torneo, le date degli incontri.

Primary Actor

Organizzatore.

Secondary Actor(s)

Nessuno.

32

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la partita.

Main Flow

1. Il caso d'uso inizia quando l'organizzatore seleziona "Inserisci data". 2. L'organizzatore inserisce la data assegnata.

Postconditions

1. Il sistema ha memorizzato le date per tutte le partite della fase attuale.

Alternative flows

Nessuno.

PubblicaDataFineIscrizioni

Use Case

PubblicaDataFineIscrizioni.

Use Case ID

UC18

Super Use Case

Nessuno.

Brief Description

L'organizzatore pubblica la data entro la quale non si accettano pi iscrizioni,pagamenti e modifiche alla squadra.

Primary Actor

Organizzatore.

Secondary Actor(s)

Nessuno.

33

Preconditions

1. L'organizzatore connesso al sistema.

Main flow

1. Il caso d'uso inizia quando l'organizzatore seleziona "Pubblica Data di Fine Iscrizioni". 2. L'organizzatore inserisce la data di fine iscrizioni.

Postconditions

1. Il sistema memorizza la data di fine iscrizioni.

Alternative flows

Nessuno.

RichiediCambioData

Use Case

RichiediCambioData

Use Case ID

UC19

Super Use Case

Nessuno.

Brief Description

Il capitano richiedere formalmente all'organizzazione di spostare la data di un incontro.

Primary Actor

Capitano.

Secondary Actor(s)

Organizzatore.

34

Preconditions

1. Il capitano connesso al sistema. 2. Il capitano ha selezionato la partita.

Main flow

1. Il caso d'uso inizia quando il capitano seleziona "Richiedi cambio data". 2. Il capitano indica la propria preferenza sul cambio di data. 3. L'organizzatore riceve la richiesta da parte del capitano.

Postconditions

Nessuna.

Alternative flows

Nessuno.

RitiraSquadra

Use Case

RitiraSquadra

Use Case ID

UC20.

Super Use Case

Nessuno.

Brief Description

Permette al capitano di ritirare la sua squadra dal torneo in qualunque momento.

Primary Actor

Capitano.

35

Secondary Actor(s)

Organizzatore

Preconditions

1. Il capitano connesso al sistema.

Main Flow

1. Il caso duso inizia quando il capitano seleziona RitiraSquadra". 2. Il sistema identifica la squadra del capitano che ne fa richiesta. 3. Il sistema chiede conferma al capitano. 4. Il sistema elimina la squadra dal torneo. 5. La squadra viene eliminata. 6. IF le iscrizioni sono chiuse 6.1. Il sistema notifica il ritiro della squadra agli organizzatori. 7. Laccount del capitano viene rimosso.

Postconditions

1. La squadra non fa pi parte del torneo. 2. Laccount del capitano stato rimosso.

Alternative flows

Nessuno.

VisualizzaDatiGiocatore

Use Case

TrovaDatiGiocatore

Use Case ID

UC21

Super Use Case

Nessuno.

36

Brief Description

Permette di trovare i dati di un giocatore della squadra.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema.

Main Flow

1. Il sistema chiede al capitano di inserire nome e cognome del giocatore. 2. Il sistema trova e visualizza i dati del giocatore selezionato.

Postconditions

1. Il sistema ha trovato i dati del giocatore.

Alternative flows

Nessuno.

TrovaDatiOrganizzatore

Use Case

TrovaDatiOrganizzatore

Use Case ID

UC22

Super Use Case

Nessuno.

Brief Description

Permette all'amministratore di trovare i dati di un organizzatore.

37

Primary Actor

Amministratore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'amministratore connesso al sistema.

Main Flow

1. Il sistema chiede all'amministratore di inserire nome e cognome dell'organizzatore. 2. Il sistema trova i dati dell'organizzatore.

Postconditions

1. Il sistema ha trovato i dati dell'organizzatore.

Alternative flows

Nessuno.

TrovaSquadra

Use Case

TrovaSquadra

Use Case ID

UC23

Super Use Case

Nessuno.

Brief Description

Permette al capitano o al visitatore di selezionare una squadra tra quelle iscritte per visualizzare lelenco dei giocatori che la compongono. Ma solo dopo che si sono chiuse le iscrizioni. Capitano, Visitatore.

Primary Actor

38

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema. 2. Le iscrizioni sono chiuse.

Main Flow

1. Il caso duso inizia quando il capitano o il visitatore seleziona VediInfoSquadre. 2. Il sistema visualizza lelenco dei nomi delle squadre iscritte. 3. Il capitano o il visitatore seleziona la squadra. 4. Include(VisualizzaGiocatoriSquadra).

Postconditions

1. Una squadra stata selezionata. 2. Vengono mostrati i giocatori della squadra selezionata.

Alternative flows

Nessuno.

VisualizzaElencoSquadre

Use Case

VisualizzaElencoSquadre

Use Case ID

UC24

Super Use Case

Nessuno.

Brief Description

L'organizzatore visualizza l'elenco delle squadre registrate (prima della chiusura delle iscrizioni) e l'elenco definitivo delle squadre iscritte.

Primary Actor

Organizzatore.

39

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema.

Main flow

1. Il caso d'uso inizia quando l'organizzatore seleziona "Vedi Elenco Squadre"2. IF le iscrizioni non sono terminate 2.1 L'organizzatore visualizza l'elenco delle squadre registrate. 3. ELSE visualizza la lista definitiva delle squadre iscritte. 4. IF l'organizzatore seleziona una squadra 4.1 include (VisualizzaDettagliSquadra).

Postconditions

Nessuna.

Alternative flows

Nessuno.

VisualizzaPartita

Use Case

VisualizzaPartita

Use Case ID

UC25

Super Use Case

Nessuno.

Brief Description

Fornisce tutti gli accoppiamenti del torneo con relativa data in cui si disputer l'incontro e risultato finale della partita se giocata.

40

Primary Actor

Capitano, Organizzatore, Visitatore.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano o lorganizzatore connesso al sistema. 2. Le iscrizioni sono chiuse.

Main Flow

1. Il caso duso inizia quando il capitano o lorganizzatore seleziona Vedi partita. 2. Il sistema mostra tutti gli accoppiamenti del torneo. 3. Il sistema per ogni accoppiamento mostra la data dellincontro ed il risultato. Extension point: VisualizzaReferto. Extension point: RichiediCambioData. Extension point: InserisciReferto. Extension point: InserisciRisultati. Extension point: CambiaDataIncontro. Extension point: InserisciData.

Postconditions

Nessuna.

Alternative flows

Nessuno.

VisualizzaReferto Main Extension Use Case VisualizzaReferto

Use Case ID

UC26

41

Super Use Case

Nessuno.

Brief Description

Il capitano visualizza il referto di un incontro giocato

Primary Actor

Capitano

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema 2. Il capitano ha selezionato la partita

Main flow

1. Il capitano visualizza per l'incontro selezionato i marcatori e il minuto della realizzazione 2. Il capitano visualizza i cartellini assegnati ai giocatori delle 2 squadre

Postconditions

Nessuna

Alternative flows

Nessuno

VisualizzaRegolamento Main Use Case VisualizzaRegolamento

Use Case ID

UC27

42

Super Use Case

Nessuno.

Brief Description

Il capitano visualizza il regolamento del torneo.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema

Main flow

1. Il caso d'uso inizia quando il capitano seleziona "Vedi Regolamento". 2. Il capitano visualizza il regolamento del torneo.

Postconditions

Nessuna

Alternative flows

Nessuno

VisualizzaDettagliSquadra

Use Case

VisualizzaDettagliSquadra

Use Case ID

UC28

Super Use Case

Nessuno.

43

Brief Description

Fornisce allorganizzatore lelenco dei giocatori (con squalifiche) della squadra che seleziona, i certificati consegnati e lo stato del pagamento. Organizzatore.

Primary Actor

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema. 2. L'organizzatore ha selezionato la squadra.

Main Flow

1. Il sistema visualizza lelenco dei nomi, cognomi, date di nascita ed e-mail per ogni giocatore che fa parte della squadra. 2. Il sistema per ogni giocatore visualizza le giornate di squalifica da scontare. 3. Il sistema per ogni giocatore visualizza uninformazione che indica se il certificato medico stato o meno consegnato. 4. Il sistema fornisce linformazione sullo stato del pagamento della quota di iscrizione della squadra. Extension point: NotificaPagamento. Extension point: NotificaCertificati. Extension point: EmettiMulta.

Postconditions

Nessuna.

Alternative flows

Nessuno.

44

VisualizzaGiocatoriSquadra

Use Case

VisualizzaGiocatoriSquadra

Use Case ID

UC29

Super Use Case

Nessuno.

Brief Description

Permette di visualizzare, per la squadra selezionata, l'elenco dei giocatori e le loro giornate di squalifica da affrontare. Capitano, Visitatore.

Primary Actor

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano o il visitatore ha selezionato una squadra.

Main Flow

1. Il sistema visualizza l'elenco dei nomi, cognomi, date di nascita e squalifiche da affrontare per ogni giocatore che fa parte della squadra selezionata.

Postconditions

1. Il sistema ha visualizzato l'elenco dei giocatori della squadra selezionata.

Alternative flows

Nessuno.

45

VisualizzaMiaSquadra

Use Case

VisualizzaMiaSquadra

Use Case ID

UC30

Super Use Case

Nessuno.

Brief Description

Fornisce al capitano lelenco dei giocatori della sua squadra, i certificati consegnati e lo stato del pagamento.

Primary Actor

Capitano.

Secondary Actor(s)

Nessuno.

Preconditions

1. Il capitano connesso al sistema.

Main Flow

1. Il caso duso inizia quando il capitano seleziona GestisciMiaSquadra. 2. Il sistema individua la squadra del capitano. 3. Il sistema visualizza lelenco dei nomi, cognomi, date di nascita ed e-mail per ogni giocatore che fa parte della squadra. 4. Il sistema per ogni giocatore visualizza uninformazione che indica se il certificato medico stato o meno consegnato. 5. Il sistema fornisce linformazione sullo stato del pagamento della quota di iscrizione della squadra. Extension point: AggiungiGiocatore. Extension point: CambiaDatiGiocatore. Extension point: CancellaGiocatore.
46

Postconditions

Nessuna.

Alternative flows

Nessuno.

VisualizzaRichieste

Use Case

VisualizzaRichieste

Use Case ID

UC31

Super Use Case

Nessuno.

Brief Description

L'organizzatore pu visualizzare le richieste di cambio data da parte dei capitani e le notifiche inviate dal sistema in caso di ritiro di una squadra.

Primary Actor

Organizzatore.

Secondary Actor(s)

Nessuno.

Preconditions

1. L'organizzatore connesso al sistema.

Main Flow

1. Il caso d'uso inizia quando l'organizzatore seleziona "Visualizza richieste". 2. Il sistema visualizza le richieste di cambio data di una partita formalizzate dai capitani. 3. Il sistema visualizza le eventuali notifiche di ritiro delle squadre.

47

Postconditions

Nessuna.

Alternative flows

Nessuno.

1.7.

Requisiti non funzionali

I requisiti non funzionali, o attributi di qualit, definiscono le modalit operative e di gestione del sistema. A differenza dei requisiti funzionali, che definiscono cosa il sistema deve fare, i requisiti non funzionali stabiliscono piuttosto come il sistema deve lavorare e possono quindi essere pensati come vincoli sullo sviluppo del sistema. I requisiti non funzionali possono essere suddivisi in requisiti interni, o di prodotto, se sono incorporati nella struttura del sistema software, o in requisiti esterni se sono osservabili a tempo di esecuzione.

1.7.1. Requisiti interni ed esterni


Manutenibilit: deve essere possibile apportare modifiche al sistema realizzato in previsione di miglioramento della qualit del software o per eliminare eventuali errori. Questo requisito risulta rilevante nel casi in cui si verifichi la necessit di introdurre nuove funzionalit correlate ad esempio a nuovi vincoli del regolamento. Usabilit: il sistema dovr essere utilizzato da persone che potrebbero non avere un buon livello di conoscenze informatiche per cui: 1. l'interazione con esso non deve presentare un elevato grado di complessit; 2. deve essere fruibile ad un pubblico quanto pi eterogeneo; 3. i giocatori e gli organizzatori devono poter utilizzare il sistema con facilit; 4. lo svolgimento di un'operazione non dovr richiedere passaggi troppo complicati; 5. ai capitani delle squadre deve esser possibile visualizzare le informazioni sulla propria squadra direttamente da Internet e essi non devono installare nessun software specifico per lutilizzo del sistema; Il sistema deve essere dotato di interfaccia grafica proprio per rendere il sistema di pi facile utilizzo: 1. il formato dei caratteri deve essere abbastanza grande (almeno 16) per rendere meno probabili errori di immissione; 2. la pagina di ricerca di una squadra deve presentare una casella di selezione del tipo di
48

ricerca e una casella di testo in cui inserire le parole chiave; 3. quando l'utente sta inserendo una parola il sistema deve presentare una lista di parole per il completamento automatico. 4. il passaggio da una casella all'altra deve essere evidenziato dal sistema , ad esempio colorando lo sfondo dei componenti (una casella di testo pu diventare con sfondo giallo se selezionata); 5. la pagina di riepilogo delle ricerche deve visualizzare una lista degli oggetti trovati ad esempio attraverso delle listbox. L'interfaccia che deve essere presentata ad un amministratore quando questo accede al sistema consiste in una casella di testo per l'immissione della password: 1. la password inserita deve essere nascosta (asterischi al posto delle lettere); 2. una volta che il sistema ha autenticato il dipendente deve presentare un' interfaccia composta da diverse sezioni una per ogni possibile azione che lamministratore pu svolgere (creazione account organizzatore, rimozione account organizzatore, gestione degli account); 3. l'esito di ogni operazione deve essere segnalato allamministratore attraverso delle messagebox; 4. deve essere previsto un pulsante per effettuare l'uscita del sistema. L'interfaccia per l'autenticazione degli organizzatori si presenta nel modo seguente: 1. una volta che il sistema ha autenticato un dipendente deve visualizzare una serie di pannelli per lo svolgimento delle varie operazioni (avanza fase, visualizza partita, modifica partita); 2. anche in questo caso il sistema deve segnalare eventuali errori attraverso delle messagebox; 3. deve essere previsto un pulsante per effettuare l'uscita del sistema. Affidabilit: il sistema deve essere affidabile e poter mantenere i propri dati anche in caso di guasti(problemi di fornitura elettrica, attacchi informatici). Deve essere possibile inoltre pianificare dei backup periodici del database e in caso di guasto, un riavvio del sistema tollerabile, dato che esso non svolge operazioni critiche. Nel caso in cui, quindi, si verifichino situazioni non previste dalle specifiche, il sistema deve tornare in uno stato consistente. Prestazioni: il sistema non svolge operazioni critiche quindi i tempi di risposta che esso deve avere non sono particolarmente stringenti. Tuttavia si richiede che il tempo richiesto ad ogni operazione non superi comunque mai i 30 secondi. Sicurezza: bisogna assicurarsi che lutente abbia accesso a tutti e soli i servizi a lui concessi in base al tipo di autorizzazione fornita allutente del sistema. Confidenzialit: i dati e le informazioni devono essere protetti in modo da garantire la privacy degli utenti e/o evitare che terze parti possano entrarne in possesso. Integrit: necessario ridurre il rischio di alterazione dei dati durante la loro trasmissione o memorizzazione, sia essa accidentale o effettuata da terze parti.
49

Aspetti legali: gli amministratori del sistema sono responsabili in caso di non rispetto delle leggi vigenti sullusura o scambi illegali capitali per quanto specificato al punto 1.2. Gli amministratori non sono ritenuti responsabili in caso di perdita parziale o totale dei dati.

1.8.

Glossario

Account: Rappresenta l'identit degli organizzatori e dei capitani nel sistema, ognuno dei quali ha particolari privilegi. Prevede l'utilizzo di un username e di una password per accedere al sistema. Amministratore del sistema: Utente del sistema responsabile della gestione del sistema stesso. Ammonizione: Cartellino giallo che l'arbitro assegna ad un giocatore per una violazione del regolamento. Capitano: Persona rappresentante di una squadra. Possiede un account e si occupa di registrare i giocatori della propria squadra di cui lui stesso fa parte al torneo. Calendario: Lista degli incontri tra le squadre partecipanti al torneo. La lista contiene data, luogo e nome delle squadre che si affrontano per ogni incontro. Certificato medico: Certificato rilasciato da un medico sportivo che attesta l'idoneit della persona in questione a praticare attivit agonistica. Espulsione: Cartellino rosso dovuto a doppia ammonizione o per allontanamento dal campo di gioco, con squalifica per la partita successiva. Giocatore: Persona che partecipa al torneo. Fa parte di una squadra ed registrato dal capitano. Organizzatore: Persona responsabile dell'organizzazione del torneo e delle relative partite insieme ai capitani. Gli organizzatori non possono far parte di una squadra e prendere parte al torneo. Incontro/Partita: Scontro tra due squadre. La partita organizzata dagli organizzatori. Squalifica: Un giocatore viene espulso durante una partita o viene ammonito, essendo diffidato salta la partita successiva.

50

Capitolo 2 Relazione

di Progetto

Analizzando i requisiti proposti, abbiamo individuato le classi che modellano i concetti chiave e le funzionalit che dovranno essere offerte dal sistema ai suoi utenti.

2.1 Diagramma dei package


Per rappresentare le classi che permettono di offrire le funzionalit richieste al sistema abbiamo utilizzato la notazione UML. Nel diagramma seguente vengono illustrate le relazioni tra i vari package. Successivamente per ogni package daremo una descrizione pi dettagliata.

Figura 2 Diagramma dei package

51

2.2 Package di analisi


Nei seguenti diagrammi illustrata la suddivisione delle classi nei vari package.

Figura 3 - Package di analisi

52

2.2.1 Package Profili

Figura 4 - Package Profili

2.2.2 Package Partite

Figura 5 - Package Partite

53

2.2.3 PackageSquadre

Figura 6 - Package Squadre

54

2.3 Diagramma delle componenti

Figura 7 - Diagramma dei componenti

55

2.4 Package di progetto (sottosistemi e interfacce)

Figura 8 Diagramma delle classi di progetto

56

2.5 Diagrammi di sequenza

2.5.1 AggiungiGiocatore

Figura 9 AggiungiGiocatore

57

2.5.2 AvanzaFase

Figura 10 - Avanza Fase

58

2.5.3 CambiaDataIncontro

Figura 11 - CambiaDataIncontro

2.5.4 CambiaDatiGiocatore

Figura 12 CambiaDatiGiocatore

59

2.5.5 CancellaGiocatore

Figura 13 - CancellaGiocatore

60

2.5.6 ConfermaListaDefinitiva

Figura 14 - Conferma Lista Definitiva

61

2.5.7 EmettiMulta

Figura 15 - Emetti Multa

62

2.5.8 InserisciData

Figura 16 - InserisciData

63

2.5.9 InserisciReferto

Figura 17 - InserisciReferto

64

2.5.10

InserisciRisultato

Figura 18 - InserisciRisultato

65

2.5.11

RichiediCambioData

Figura 19 - RichiediCambioData

66

2.5.12

RitiraSquadra

Figura 20 - RitiraSquadra

2.5.13

TrovaSquadra

Figura 21 - TrovaSquadra

67

2.5.14

VisualizzaDatiGiocatore

Figura 22 - VisualizzaDatiGiocatore

2.5.15

VisualizzaDettagliSquadra

Figura 23 VisualizzaDettagliSquadra

68

2.5.16

VisualizzaElencoSquadre

Figura 24 - VisualizzaElencoSquadre

69

2.5.17

VisualizzaGiocatoriSquadra

Figura 25 - VisualizzaGiocatoriSquadra

70

2.5.18

VisualizzaMiaSquadra

Figura 26 VisualizzaMiaSquadra

71

2.5.19

VisualizzaPartita

Figura 27 - VisualizzaPartita

2.5.20

VisualizzaRichieste

Figura 28 - VisualizzaRichieste

72

Capitolo 3 Piano

di processo

Un primo aspetto fondamentale del management dell'ingegneria del software unefficace pianificazione del processo di sviluppo. Il primo passo della pianificazione consiste nel definire e documentare le ipotesi, gli obiettivi e i vincoli del progetto. Un processo necessita di una chiara descrizione degli obiettivi che possa guidare gli ingegneri nelle decisioni che prendono quotidianamente. Obiettivo della fase di pianificazione del progetto identificare tutti i requisiti esterni e i vincoli del progetto. Una volta identificati i vincoli esterni, il manager del progetto deve produrre un piano che meglio definisca come raggiungere gli obiettivi entro i vincoli imposti. Una delle questioni da affrontare in questa fase quale modello di processo scegliere. Un'altra decisione critica riguarda la determinazione delle risorse necessarie per lo sviluppo del progetto. Le risorse includono sia il numero che le competenze richieste alle persone, la quantit di risorse1 di calcolo (ad esempio: stazioni di lavoro, PC e software di supporto quali DBMS).

3.1.

Introduzione e definizioni

Il presente capitolo definisce ed elabora un piano di processo, con particolare riferimento al ciclo di vita del software e al modello di processo ed alle metodologie di pianificazione del processo. Il ciclo di vita di un prodotto software riguarda le differenti fasi che attraversa il prodotto stesso dallalba al tramonto della sua esistenza; possono individuarsi, nellestrazione pi generale del termine (quindi senza far riferimento alla loro disposizione nel tempo e correlazione, obiettivi del modello di processo) le seguenti propriet: Fase dei requisiti: esplora il dominio ed estrae i requisiti; Fase di analisi: analizza i requisiti, traccia il documento di specifica, traccia il piano di gestione del progetto software, ovvero definisce che cosa il prodotto dovrebbe essere; Fase di progetto: progetta larchitettura e dettaglia le componenti del software, ovvero definisce come il prodotto far ci che stato identificato nella parte di analisi; Fase di implementazione: produce il codice, testa i singoli moduli, opera lintegrazione correttiva ed i test di accettazione; Fase di manutenzione: opera la manutenzione correttiva (17%, corregge errori trovati dopo la consegna), la manutenzione percettiva (65%, migliora il prodotto) e quella adattiva (18%, risponde a modifiche ambientali);
1

Il termine risorse pi generale e include, ad esempio, anche lo spazio fisico occupato dal gruppo di lavoro. Qui noi

73

Fase di pensionamento: presiede al declino del software ed alla implementazione di un nuovo prodotto. il caso del diagramma seguente:

Figura 29 - Ciclo di vita di un prodotto software

Il modello di processo descrive e caratterizza lintero processo di sviluppo del software: esso riguarda il modo in cui si scompone lattivit di realizzazione del prodotto in sot toattivit (scegliendo questo o quel modello di processo) dal grado di coordinazione e dipendenza pi o meno elevato a seconda delle esigenze di progetto contingenti. Dunque mostra limportanza data alle varie fasi del ciclo di vita, cos come la loro disposizione e correlazione allinterno dello sviluppo del software. La scelta del modello di processo pi opportuno per lo specifico software indubbiamente guidata dalle caratteristiche del software stesso; opportuno infatti che le caratteristiche del software siano i punti di focalizzazione del modello di processo scelto. Bisogna dunque definire una breve panoramica dei pi diffusi modelli di processo, al fine di scegliere e caratterizzare approfonditamente quello che meglio si rif al software in esame. Quanto alla pianificazione del processo, essa riguarda la trasposizione nel tempo delle attivit di progetto preventivate, in modo congruente con i vincoli di sviluppo in serie, concorrenza o collaborazione delle attivit stesse, al fine di individuare la finestra di scorrimento temporale di ciascuna attivit ed i ritardi relativi che non comportano il procrastinarsi della data di consegna del progetto. La resa grafica dei concetti esplicitati affidata al diagramma di Gantt.

74

3.2.

Metodologie pesanti Il modello waterfall

3.2.1.

questo il primo modello di ciclo di vita del software strutturato ed organizzato. Detto anche modello sequenziale lineare, suggerisce un approccio sistematico e sequenziale allo sviluppo del software che inizia al livello del sistema e procede attraverso lanalisi, la progettazione, la codifica, il collaudo e il supporto. Tale definizione ha il merito di porre in evidenza il principio che lo contraddistingue: la sequenzialit delle fasi costituenti il processo. Ogni fase riceve in input loutput precedente, ed il proprio output risulta linput della successiva. Lo schema rigido a cascata implica alti costi qualora risulti necessario tornare indietro verso fasi gi percorse.

Figura 30 - Modello waterfall

Storicamente, il modello waterfall ha rappresentato un autentico punto di partenza nel tentativo di fornire delle aree di riferimento di indagine e degli strumenti necessari per investigarle. Fornisce
75

unampia copertura del processo produttivo fin dallinizio con lis tituzionalizzazione dello studio di fattibilit, per concludersi con integrazione e test di sistema. Ma, oltre a coprire completamente il ciclo produttivo, introduce con un ulteriore passo il concetto di manutenzione che tipico del processo evolutivo. Nella realt, la fase di manutenzione rappresenta un processo nel processo vista la sua estrema importanza, e quindi merita maggior attenzione a quella concessa dal waterfall model; resta comunque insindacabile che la cascata ha il merito di aver introdotto per prima questo concetto. Le fasi intermedie producono i cosiddetti semilavorati (deliverables); documentazione per lo pi cartacea, spesso scritta in linguaggio naturale. Un modello di ciclo di vita a cascata, oltre a fornire quanto detto, si preoccupa di definire dettagliatamente i contenuti e la struttura dei semilavorati che devono essere prodotti, e in fase di pianificazione, le date alle quali questi devono essere prodotti.

3.2.2.

Il modello trasformazionale

In questo modello lo sviluppo del software viene visto come una sequenza di passi che trasformano formalmente una specifica in una implementazione. Consta dunque di una sequenza cos formata: Analisi dei requisiti informali Trasformazione in specifiche formali Trasformazione ulteriore in specifiche di pi basso livello Trasformazione in codice eseguibile Ad ogni livello di specifiche formali corrisponde dunque un processore in grado di eseguire trasformazioni manuali, interattive e automatiche. I risultati di questo modello di sviluppo sono tre: Le specifiche formali, la base, insieme alle regole di trasformazione, per la manutenzione Il sistema software da rilasciare Il diario dello sviluppo, che riassume le regole di trasformazione applicato ad ogni livello di dettaglio delle specifiche Allo stato attuale il modello trasformazionale non pu essere considerato un paradigma pratico per la produzione del software, in quanto ancora oggetto di ricerca e vi sono pochi ambienti sperimentali di supporto.

76

3.3.

Metodologie iterative Il modello a spirale

3.3.1.

Il modello a spirale un modello di processo del software che abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale lineare, consentendo un rapido sviluppo di versioni via via pi complete del software. Nel modello a spirale, il software viene sviluppato in una sequenza di versioni crescenti mediante la discussione di molteplici regioni (task region) che caratterizzano ogni giro della spirale.

Figura 31 - Modello a spirale

La spirale ha il pregio di considerare tutto il ciclo di vita; oltre ad arrivare alla consegna del software, permette di strutturare e programmare anche lattivit successiva allinstallazione. In sostanza si occupa anche della manutenzione che molti altri modelli trascurano. Il modello a spirale consigliato per progetti di grandi dimensioni poich permette di raffinare ad ogni giro il materiale precedentemente elaborato ed approvato dal cliente; allinizio probabilmente sar sola documentazione cartacea contenente gli intenti e lo scopo finale, poi si costruiranno, se ritenuti opportuni, dei prototipi da verificare e validare, e cos via fino a giungere al prodotto conclusivo. Con questo modello il software si evolve di pari passo con lavanzare del processo cos da consentire allo sviluppatore e al cliente di valutare meglio i rischi e di reagire ad ogni stadio.
77

3.3.2.

Il modello UP

Lo Unified Process un processo di ingegnerizzazione del software (Software Engineering Process), anche conosciuto come processo di sviluppo del software o metodo di sviluppo del software, che definisce il chi, il che cosa, il quando ed il come dello sviluppo software. UP si basa su tre principi: guidato dallanalisi dei requisiti e dei rischi: importante individuare il prima possibile g li eventuali rischi che si possono dover affrontare nel processo di sviluppo e predisporre le modalit con cui possano essere superati centrato sullarchitettura cio finalizzato alla produzione di unarchitettura robusta, che descriva esattamente gli aspetti strategici di come il sistema suddiviso in componenti e come questi interagiscono e sono dislocati sulle piattaforme hardware iterativo ed incrementale, cio suddivide il progetto in miniprogetti che rilasciano le funzionalit del sistema a pezzi, o incrementi, fino ad ottenere un sistema completamente funzionante. In altre parole, il software prodotto attraverso un processo di raffinamento per passi successivi

Figura 32 - Unified Process

Molte volte il cliente stabilisce gli scopi generali da assegnare al software, ma non specifica in modo dettagliato i requisiti che deve saper soddisfare. In altri casi, lo sviluppatore pu nutrire delle riserve sulla correttezza di alcuni algoritmi o su alcune scelte. Per queste ed altre situazioni, la soluzione migliore la prototipazione.

78

Il paradigma prototipale comincia dalla fase di raccolta dei requisiti. Cliente e sviluppatore si incontrano per definire gli obiettivi complessivi del software; ci si accorda, in questa fase, per una verifica di un primo prototipo che, con molta probabilit, sar costruito rapidamente senza interessarsi alla stabilit o alla sicurezza del sistema. Ne sono un esempio i prototipi mock-up in cui vengono sviluppate appieno solo le maschere per interagire con lutente. Si passa quindi ad una prima validazione del cliente; questo il momento migliore per capire se il committente ha le idee chiare su come dovr essere lapplicazione finale, e per cercare di carpire altre informazioni che consentono allo sviluppatore un ulteriore passo in avanti. Liter si ripete, via via ritoccando i prototipi, in modo da avvicinarsi fino al pieno soddisfacimento del cliente. Il modello in questione un efficace strumento di sviluppo del software qualora venga adoperato in accordo con il cliente fin da subito; restano comunque degli evidenti problemi, tra cui: Il fenomeno del throw-away: si rischia di generare un prototipo che, non approvato dal cliente, si deve gettar via e ricostruire ex-novo; questo oltre a costituire un elevato dispendio di soldi genera anche insofferenza nel cliente, che interpreta lazione come un ritorno allo stato iniziale delle cose I tempi di consegna dei prototipi sono spesso brevi e questo pregiudica la qualit del risultato finale La documentazione associata tipicamente pessima in quanto non sono ben definite le fasi di sviluppo del software Il rapporto costo/tempo per sviluppare un prototipo resta sempre una stima difficile

79

3.4.

Metodologie agili 3.4.1. Code and fix

considerato per lo pi un non modello, in quanto caratterizzabile come un modello iterativo con assenza (o quasi) di organizzazione del processo. Si tratta infatti di un modello in cui il software si adatta progressivamente a ci che il suo progettista desidera. Sostanzialment e lobiettivo capire approssimativamente quale sar la risposta finale del software e di provare ripetutamente a generare codice e correggere gli errori: se la complessit bassa e lesperienza del programmatore buona, allora lapplicazione verr prodotta in breve tempo. La figura del progettista-programmatore tipicamente coincide con quella dellutente finale. Code and fix concede molto allingegnerizzazione del processo tanto che risulta applicato in contesti dove il numero di righe di codice da produrre non oltrepassa le 1500. il modo pi semplice per sviluppare software ma anche il pi costoso. Per tale motivo viene utilizzato tipicamente dalle aziende appena nate. Il modello standard code and fix mostrato nella figura seguente:

Figura 33 - Modello "Code and fix"

La prima fase essenzialmente di codifica (code), magari preceduta da qualche diagramma molto elementare per schematizzare la complessit del problema ed una primordiale soluzione; successivamente si passa alla fase di mini test che volge ad accertare se il programma funziona correttamente e soddisfa i requisiti (quasi certamente non specificati esplicitamente in qualche documento). In caso contrario si ritorna a codificare per fissare (fix) eventuali errori o disturbi. Lultimo passo prevede luscita nel caso in cui il programma soddisfa i requisiti.

80

3.4.2.

Synchronize and stabilize

il modello di processo adottato dalla Microsoft: i team lavorano in parallelo su moduli separati, sincronizzando il loro codice con quello degli altri team e effettuando un controllo regolare lungo il percorso di sviluppo. Questa metodologia permette cambi ad ogni punto del processo, risultando pi flessibile e pi capace di rispondere ai cambiamenti del mercato. Si compone di tre fasi: La pianificazione, definisce gli obiettivi del nuovo prodotto o delle nuove funzioni (features), dando priorit alle funzioni da implementare in base ai bisogni degli utenti. Produce un documento di specifica e uno di pianificazione e definizione per ciascuna feature; Lo sviluppo delle funzioni, suddiviso in tre o quattro sottoprogetti (della durata di un bimestre ciascuno) usando specifiche funzionali atte a definire un piano di produzione. Ciascun sottoprogetto esegue in autonomia il ciclo completo di sviluppo, integrazione di features, testing e debugging. Il prodotto si stabilizza alla fine del sottoprogetto; La stabilizzazione, comprendente un testing interno del prodotto completo, un testing esterno attraverso beta realeases e utilizzatori finali chiamati a testare il software Dalla scomposizione in fasi emergono i seguenti principi chiave: La divisione dei grandi progetti in pi iterazioni con buffer time appropriato La selezione delle caratteristiche principali e ordinamento di priorit basato su dati duso Larchitettura modulare La gestione basata su piccoli compiti individuali e risorse di progetto prestabilite

81

3.4.3.

Extreme Programming

LExtreme Programming si compone essenzialmente di quattro fasi: Scrittura del codice dellapplicazione (coding) Verifica delle funzionalit (testing) Osservazione dellambiente, inteso come desideri del committente, opportunit tecnologiche, sviluppi di mercato (listening) Progetto dellapplicazione (design) Affinch queste attivit possano essere svolte efficacemente vengono identificate alcune prassi fondamentali che aiutano i programmatori a rendere il loro lavoro pi efficiente possibile. Innanzitutto la pianificazione delle attivit, articolata come un gioco in cui sono coinvolti utenti e sviluppatori per stabilire un equilibrio dinamico tra tutti gli attori coinvolti. In particolare gli utenti presentano gli obiettivi da raggiungere descrivendo una serie di scenari, mentre gli sviluppatori stimano per ciascun scenario, il tempo necessario, i rischi e le risorse. Quanto alla scrittura del codice, viene eseguita da coppie di programmatori. Un programmatore, il drive, controlla tastiera e mouse e scrive limplementazione, laltro, il navigatore, osserva limplementazione cercando difetti e partecipa al brainstorming su richiesta. I ruoli di driver e navigatore vengono periodicamente invertiti per garantire limpegno comune; il codice inoltre liberamente accessibile da qualsiasi altro programmatore (questo aspetto favorito peraltro dalluso di standard nella codifica). La coppia responsabile dellesecuzione di un test completo sullunit prodotta e dellintegrazione della nuova unit con le altre. Il cliente, infine, deve essere sempre disponibile per chiarire gli scenari e per prendere rapidamente decisioni critiche. Il modello dunque predilige il lavoro di coppia, che conduce empiricamente ad un incremento del 15% nella qualit del codice e ad una riduzione del 58% del tempo necessario a completare ununit. Aumenta anche lapprezzamento del proprio lavor o e la fiducia nei propri prodotti. Tra gli svantaggi del prodotto invece si annovera la lentezza e limprecisione della fase di test, leccessiva complessit degli scenari, la pochezza di collaudi suggeriti dal cliente.

82

3.5.

La nostra scelta: il RUP Le caratteristiche del software

3.5.1.

Il modello di processo che stato adottato il RUP2, un modello di processo software iterativo sviluppato da Rational Software (oggi parte di IBM). Il RUP non definisce un singolo, specifico processo, bens un framework adattabile che pu dar luogo a diversi processi in diversi contesti (per esempio in diverse organizzazioni o nel contesto di progetti con diverse caratteristiche). pensato soprattutto per progetti di grandi dimensioni. Poich RUP un modello iterativo ed incrementale, il progetto viene suddiviso in iterazioni. Questa scomposizione presenta numerosi vantaggi (in particolare rispetto alla valutazione dell'avanzamento del progetto e alla gestione dei fattori di rischio). L'incrementalit permette la realizzazione dell'applicazione progressivamente ed inoltre la pianificazione guidata dai casi d'uso e dalle priorit architetturali. Il software sviluppato progettato con estrema flessibilit: il sistema infatti assume una definizione netta dei servizi offerti in via del tutto incrementale. Lo sviluppo della parte di analisi infatti guida alla revisione della fase di specifica ed analisi dei requisiti, cui si fa ricorso anche in fase di estesa progettazione, allorch alcune funzioni richiedono la definizione di altre funzioni supplementari. Una tale metodologia di sviluppo non pu che essere guidata da un processo che privilegi i salti pindarici da una fase allaltra conservando lunit e la razionalit della visione dinsieme. Si pertanto scelto di utilizzare, per modellare lo sviluppo del software, il modello RUP. Le motivazioni di questa scelta risiedono nella convergenza tra le caratteristiche di cui si abbisogna per lo sviluppo del software ed i vantaggi offerti dall'UP. In particolar modo questo modello di sviluppo garantisce: lo sviluppo del software in modo iterativo: questo permette di considerare i requisiti che cambiano. L'integrazione non un big bang finale; gli elementi vengono integrati progressivamente, quasi continuamente. Cos facendo i rischi vengono scoperti prima, solitamente durante la fase d'integrazione. Lo sviluppo iterativo inoltre fornisce i mezzi per effettuare dei cambiamenti tattici al prodotto, per competere con i prodotti in circolazione, iterare poi facilita il riutilizzo e le revisioni del disegno. Lo stesso processo di sviluppo pu essere migliorato e raffinato lungo il percorso. La gestione dei requisiti come metodo sistematico per organizzare, comunicare e gestire il cambiamento dei requisiti di un sistema software-intensive o di un'applicazione. I benefici di una gestione efficace dei requisiti sono numerosi: miglior controllo di processi complessi, qualit migliore del software e soddisfazione del cliente, costi e ritardi di progetto ridotti.

Rational Unified Process, estensione dello Unified Process.

83

La verifica continua della qualit del software. La qualit e la responsabilit di ogni membro dell'organizzazione di sviluppo. Nello sviluppo del software attraverso UP, la preoccupazione circa la qualit messa a fuoco su due aree: qualit del prodotto principale (il software o il sistema) e di tutti gli elementi che contiene (per esempio, componenti, sottosistemi, architettura e cos via); qualit del processo, interessata dalla qualit degli artifacts (quali i piani di iterazione, i piani di test, le realizzazioni dei casi d'uso, il modello di disegno e cos via) prodotti a sostegno del prodotto principale. L'efficace gestione dei cambiamenti: intesa un metodo sistematico nel gestire i cambiamenti nei requisiti, nel disegno e nell'implementazione. Attraverso lo sviluppo iterativo, UP offre flessibilit nella progettazione e nell'esecuzione dello sviluppo permette l'evolversi dei requisiti, d risalto alle issues vitali tenendosi al corrente dei cambiamenti ed accertandosi che tutto e tutti siano sincronizzati.

3.5.2.

La struttura di RUP

RUP suddivide il progetto in 4 fasi. All'interno di ciascuna di esse si registrano una o pi iterazioni, laddove questo termine vuole indicare un insieme di attivit che ineriscono alcuni ambiti specifici quali la definizione dei requisiti o la creazione del codice. Per ciascuna fase del processo pertanto si pu accedere, mediante l'iterazione associata, a qualsiasi ambito di modifica ed operare su di esso in maniera pi o meno estesa a seconda della fase di processo in cui ci si trova. opportuno, ad esempio, che la fase iniziale richieder di porre l'accento sulla definizione dei requisiti mentre quella di progettazione sulla creazione del codice, ma nulla impedisce alla prima fase di creare del codice n alla seconda di perfezionare i requisiti. In questo meccanismo risiede tutta la flessibilit, l'adattabilit e la potenza di UP.

Figura 34 - Rational Unified Process

84

3.5.3.

L'iterazione: i 5 workflow

Ogni iterazione genera la cosiddetta baseline, cio una versione parzialmente completa del sistema finale e la documentazione associata. In ogni iterazione, cinque flussi di lavoro (workflow) principali specificano che cosa deve essere fatto e quali capacit sono necessarie: 1. workflow requisiti: cattura che cosa il sistema dovrebbe fare; 2. workflow analisi: raffina e struttura i requisiti; 3. workflow progetto: realizza i requisiti attraverso un'architettura di sistema; 4. workflow implementazione: genera il software; 5. workflow test: verifica che l'implementazione lavori come desiderato. Come sottolineato in precedenza, l'enfasi su un particolare workflow dipende dalla fase in cui l'iterazione viene eseguita nel ciclo di vita del progetto. La suddivisione in iterazioni permette un elevato grado di flessibilit; le iterazioni possono essere eseguite in sequenza oppure alcune di loro, quando possibile, possono essere eseguite in parallelo (mancanza di dipendenza tra gli artefatti). L'esecuzione parallela permette una riduzione del time-to-market (tempo di commercializzazione), ma richiede una pi accurata pianificazione.

3.5.4. Ciclo di Vita


Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi. Le fasi previste sono: Inception Phase (fase iniziale) Elaboration Phase (fase di elaborazione) Construction Phase (fase di costruzione) Transition Phase (fase di transizione)

Ogni fase pu essere composta da una o pi iterazioni, in ciascuna delle quali sono presenti cinque flussi principali di lavoro, permettendo di specificare cosa deve essere fatto e quali sono le capacit necessarie. Requisiti Analisi Progettazione Implementazione Testing

85

Ogni fase termina con un obiettivo (Goal) che deve essere raggiunto e inviato alla fase successiva (Milestone).

Figura 35 - Attivit (Workflow), con fasi ed interazioni

3.6.

Analisi specifica delle fasi

3.6.1. Inception Phase


L'Inception Phase si pu considerare come una particolare elaborazione e precisazione del concetto generale di analisi di fattibilit. Lo scopo principale quello di delineare nel modo pi accurato possibile il business case, ovvero comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinch esso conduca ad un successo commerciale. Fra gli strumenti utilizzati ci sono un modello dei casi d'uso, la pianificazione iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei requisiti e cos via. Se il progetto non
86

supera questa milestone, detta Lifecycle Objective Milestone, esso dovr essere abbandonato o ridefinito. Goal: Far partire il progetto ed avviare le seguenti attivit: Studio di fattibilit: al fine di validare sia le decisioni tecnologiche che le richieste del business pu richiedere lo sviluppo di qualche prototipo; Creare un caso di business: per dimostrare che il progetto produrr benefici quantificabili al business; Identificare le specifiche essenziali per aiutare ad implementare correttamente il sistema; Identificare ed analizzare i rischi critici.

Attivit: Le attivit investono i workflow Requisiti ed Analisi. Durante questa fase potrebbe essere prodotto qualche prototipo, ma non vi verr effettuato alcun test. Milestone: Documenti relativi il risultato dello studio di fattibilit.

3.6.2.

Elaboration Phase

La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'analisi di dominio e un prima fase di progettazione dell'architettura. Questa fase deve concludersi con il superamento di una milestone detta Lifecycle Architecture Milestone. A questo scopo devono essere soddisfatti i seguenti criteri: deve essere stato sviluppato un modello dei casi d'uso completo all'80% deve essere fornita la descrizione dell'architettura del sistema deve essere stata sviluppata un'architettura eseguibile che dimostra il completamento dei casi duso significativi deve essere eseguita una revisione del business case e dei rischi deve essere completata una pianificazione del progetto complessivo

Se il progetto non passa questa milestone, potrebbe ancora essere abbandonato, oppure dovr essere rivisitato. Al termine di questa fase si transita infatti in una situazione di rischio pi elevato, in cui le modifiche all'impostazione del progetto saranno pi difficili e dannose. Goal: Creazione di un'architettura eseguibile; Analizzare e prendere decisioni in merito alla valutazione del rischio;
87

Definire il livello di qualit accettabile (LQA); Catturare almeno l'80% delle specifiche funzionali con i casi d'uso; Creare un piano dettagliato per la fase di costruzione.

Attivit: Le attivit di questa fase investono tutti i workflow, nello specifico: Requisiti: raffina le specifiche del sistema; Analisi: stabilisce cosa costruire; Progettazione: identifica un'architettura stabile; Implementazione: costruisce l'architettura; Test: verifica l'architettura.

Milestone: Specifica dei requisiti del software; Architettura consolidata e verificata.

3.6.3. Construction Phase


In questa fase viene portato a termine il grosso degli sviluppi. Viene prodotta la prima release del sistema. La milestone di questa fase si chiama Initial Operational Capability e rappresenta la prima disponibilit delle funzionalit del sistema in termini di implementazione. Goal: Completare le specifiche mancanti o incomplete, l'analisi, il progetto, ed evolvere l'architettura generata nella fase di Elaborazione nel sistema finale. Attivit: Le attivit di questa fase sono per lo pi concentrate sul workflow Implementazione, ma qualche altra attivit ha luogo anche sugli altri workflow al fine di completare i requisiti, l'analisi ed il progetto. Anche il workflow del Test viene interessato. Nel dettaglio: Requisiti: vengono introdotti i requisiti mancanti; Analisi: terminazione del modello di analisi; Progettazione: terminazione del progetto; Implementazione: viene costruita la capacit operativa iniziale; Test: viene verificata la capacit operativa iniziale.

Milestone: Versione sistema in pre-produzione (Versione beta del sistema).

88

3.6.4.

Transition Phase

Nella fase di transizione, il sistema passa dall'ambiente dello sviluppo a quello del cliente finale. Vengono condotte le attivit di training degli utenti e il beta testing del sistema a scopo di verifica e validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte nella fase di Inception. Se questo non vero si procede a ripetere l'intero ciclo; altrimenti, si raggiunge la milestone detta ProductRelease e lo sviluppo termina. Goal: Fissare i difetti trovati nel beta test e preparare l'installazione del sistema presso il committente. In particolare: Correggere i difetti; Preparare i siti dell'utente per il nuovo sistema software; Predisporre il software per operare opportunamente nei siti dell'utente; Modificare tempestivamente il software se sorgono problemi imprevisti; Creare manuali utente e tutta la documentazione necessaria; Fornire assistenza all'utente; Condurre revisioni del progetto.

Attivit: Le attivit di questa fase sono concentrare sui workflow Implementazione e Test sebbene qualche attivit sia ancora presente nel workflow Progettazione al fine di correggere eventuali errori di progetto sorti durante il beta testing. I workflow Requisiti ed Analisi sono privi di attivit, se cos non fosse, il progetto ha sicuramente dei problemi. Nel dettaglio si ha: Requisiti: Non applicabile; Analisi: Non applicabile; Progettazione: Modifica del progetto nel caso in cui si siano verificati problemi durante la fase di beta testing; Implementazione: Viene configurato il sistema software per l'utilizzo presso il sito dell'utente e si correggono eventuali problemi che si sono manifestati nel beta test. Test: Beta Testing, Test di accettazione svolti presso il sito dell'utente.

Milestone: Versione del sistema software in produzione.

89

3.7.

Piano di Produzione Preventivo

Per descrivere realisticamente il piano di produzione preventivo importante attenersi ai documenti prodotti da ciascuna fase (deliverable documents). Inception: Un documento di riepilogo che stabilisce i requisiti principali, le caratteristiche ed i vincoli del progetto; Un primo modello dei casi d'uso; Un glossario di progetto; Un piano iniziale di progetto; Un documento o un database di stima dei rischi; Un documento di architettura iniziale. Elaboration: Il diagramma UML statico, dinamico e dei casi d'uso; Una stima del rischio aggiornata; Il Piano di Progetto opportunamente dettagliato al fine di consentire la formulazione di un'offerta realistica; Documentazione circa l'architettura software. Construction: Prodotto software stabile; Diagramma UML completo; Piano di Test; Bozza del manuale utente; Piano di Progetto. Transition: Prodotto software completo, installato e testato; Piano di supporto agli utenti; Manuale utente completo.

90

Per ciascuna delle quattro fasi RUP in oggetto a questo progetto sono state stimate le seguenti durate in percentuale:

RUP Phase Inception Elaboration Construction Transition

Durata % 15 30 45 10

3.8.

Diagramma di GANTT

Per un'opportuna gestione temporale delle varie fasi del progetto stato stilato il seguente diagramma di GANTT, con il dettaglio delle singole attivit:

Figura 36 - Diagramma di GANTT

91

3.9.

Analisi del Piano Svolto

Il processo di sviluppo ha riguardato principalmente la fase di Inception e l'attivit cardine stata quella di verificare che tutti gli obiettivi del ciclo di vita dell'applicazione fossero ben definiti e completi. Inoltre stato stilato il seguente elenco di documenti utili e necessari a governare e controllare il progetto: Requisiti principali; Modello dei casi d'uso; Glossario di Progetto; Piano iniziale del progetto.

Avvalendosi dei diagrammi di sequenza e delle classi del progetto stata definita completamente la fase di elaboration. E' stato inoltre formulato un Piano di Test al fine di valutare la qualit del Sistema in oggetto. Mediante la Valutazione preventiva dello Sforzo stata condotta un'analisi circa i costi.

92

Capitolo 4 Piano

di Qualit

Per definire i requisiti di qualit del sistema sono state utilizzate le norme ISO 9126 e ISO 12207.

4.1.

Modello di qualit ISO 9126

Gli scopi di questa norma sono molteplici, tra cui: validare la completezza dai requisiti identificare gli obiettivi software identificare gli obiettivi di progetto identificare gli obiettivi di testing identificare i criteri di Quality Assurance identificare i criteri di accettazione per il prodotto finale

Lo standard distingue tre famiglie di caratteristiche che influenzano la qualit di un software, corrispondenti a tre diversi punti di vista: Qualit in uso la misura complessiva della qualit di un sistema nel suo ambiente operativo, vista dalla prospettiva dell'utente del sistema. Qualit interna richiama invece un meccanismo tipo white box" e si riferisce alle caratteristiche statiche" del software, cio indipendentemente dall'ambiente in cui esso destinato ad operare. Qualit esterna del software 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.

93

4.1.1.

Qualit interna ed esterna

Il modello individua sei caratteristiche fondamentali per la qualit, che vengono a loro volta suddivise in sottocaratteristiche misurabili attraverso opportune metriche, come mostrato in Figura 37.

Figura 37 - Caratteristiche ISO 9126

Le sei caratteristiche principiali sono: 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 proposto. 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 pi raramente, durante l'uso del sistema, si manifestano malfunzionamenti. L'affidabilit pu anche essere considerata come la misura in cui l'utente pu fidarsi del software. Usabilit: un software considerato usabile in proporzione alla facilit con cui gli utenti operano per sfruttare appieno le funzionalit che il software realizza. Un software facile da usare se un essere umano lo reputa tale. E' una caratteristica soggettiva e pu dipendere in buona parte dalla formazione e dalla cultura dell`utente. L'interfaccia utente interviene molto sull'amichevolezza di un'applicazione. 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
94

efficiente se usa memoria, CPU e altre risorse in modo proporzionato ai servizi che svolge, ovvero senza sprechi. E'importante cercare di prevedere in 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 costosi. 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 errori, adattare o perfezionare funzioni. Pi un software facile da correggere e da migliorare minori sono i costi di manutenzione e sviluppo. Portabilit: un software considerato portabile quando possibile trasferirlo in modo sufficientemente veloce da un ambiente (hardware, sistema operativo, etc.) ad un altro. E' diventato un aspetto fondamentale perch consente di avere vantaggi economici, in quanto si possono ammortizzare i costi trasportando l`applicazione in diversi ambienti. Nel caso delle applicazioni web la chiave di volta. Si usano strumenti e tecniche appositamente pensate per dare luogo ad oggetti portabili. Nei paragrafi seguenti vengono riportati i valori delle metriche che sono stati stabili per ogni sottocategoria al fine di garantire la qualit del progetto.

95

4.1.2.

Funzionalit

4.1.3.

Affidabilit

96

4.1.4.

Usabilit

4.1.5.

Efficienza

97

4.1.6.

Manutenibilit

4.1.7.

Portabilit

98

4.1.8.

Qualit in uso

Lo standard stabilisce quattro caratteristiche con cui mappare gli attributi di qualit in uso, riportate in tabella:

Efficacia

Capacit del prodotto di mettere in grado lutente di raggiungere gli obiettivi specificati con la precisione di un particolare contesto operativo. Capacit del prodotto di mettere in grado lutente di spendere una quantit di risorse appropriate in relazione allefficacia ottenuta in un contesto duso. Capacit del prodotto software di raggiungere accettabili livelli di rischio a persone, al software e alle apparecchiature. Capacit del prodotto di soddisfare gli utenti di uno specifico contesto.

Produttivit

Sicurezza Soddisfazione

La qualit in uso la visione che l'utente ha della qualit, quindi il suo raggiungimento subordinato alla soddisfazione della qualit esterna che a sua volta dipendente dalla qualit interna.

99

4.2.

Modello di qualit ISO 12207

La norma ISO 12207 si pone come obiettivo di definire, in modo preciso, i processi del ciclo di vita del software, dalla formulazione dei requisiti, allo sviluppo, all'esercizio ed infine alla manutenzione. I processi informatici nella norma 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 di 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 ogni 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.

4.2.1.

Processi primari

I processi primari descritti nella norma sono cinque, di seguito sono riportate le analisi che sono state effettuate. Acquisizione Non sono previste attivit di acquisizione per questo progetto. Fornitura La realizzazione del sistema si deve attenere alle specifiche fornite dal cliente. In particolare si prevede unanalisi preliminare per capire se l'organizzazione in grado di soddisfare i requisiti richiesti (anche in base all'attuale tecnologia e alle capacit interne dell'azienda). Successivamente si deve passare alla stipula del contratto tenendo conto di possibili evoluzioni del sistema e di attivit di manutenzione future. Una volta completato il sistema deve essere sottoposto ad attivit di validazione ed accettazione al fine del rilascio finale. Tutte queste attivit devono essere pianificate con chiarezza.
100

Sviluppo Il modello di sviluppo adottato RUP. Di conseguenza si fa riferimento ad esso per i dettagli relativi alle varie fasi del processo di sviluppo. Per quanto riguarda le attivit di testing si dovr fare riferimento allo standard IEEE 829 ed inoltre dovr essere effettuata un'analisi di path coverage, che dovr fornire come risultato una copertura del 100% di tutti i path feasible per tutti i moduli che si occuperanno delle transazioni finanziarie. Lo sviluppo si concluder con l'installazione del sistema presso il cliente con opportune attivit di beta testing. Gestione Operativa Durante la fase di beta testing dovranno essere previste delle ore di addestramento degli operatori che dovranno amministrare il sistema. In particolare dovr essere data dimostrazione di come eseguire le procedure di backup e di restore del sistema. Manutenzione Ogni eventuale esigenza di modifica dovr essere gestita in accordo con le norme previste dal contratto definito nell'acquisizione. In particolare si dovr tenere traccia delle modiche, effettuare test di correttezza, rieseguirei test di path coverage se le modifiche riguardano i moduli delle transazioni finanziarie e documentare il tutto.

101

Capitolo 5 Piano

di testing

La documentazione dei test stata redatta secondo le specifiche dello standard IEEE 829. Il processo di testing prevede una fase iniziale di preparazione dei test, una fase successiva di esecuzione dei test ed una fase finale di conclusione dei test. Lo standard prevede la redazione di otto documenti ognuno dei quali descrive uno specifico step del processo di testing, tali documenti possono essere accorpati alle fasi del testing in tal modo: Preparazione dei test Test Plan Test Design Specification Test Case Specification Test procedure Test item transmittal report Esecuzione dei test Test log Test incident report Conclusione dei test Test summary report

La documentazione seguente composta esclusivamente dai documenti previsti dallo standard IEEE 829 per la preparazione dei test, poich in assenza di codice non possiamo proseguire nella esecuzione e nella valutazione dei test.

5.1.

Test plan

Il presente test plan stato redatto con l'obiettivo di tracciare le linee guida secondo le quali avverr la fase di testing dell'applicazione, a tal fine stato definito uno schedule delle attivit di testing e l'elenco dei casi d'uso da verificare. Le attivit di testing verranno svolte da un team diverso da quello di sviluppo.

102

5.1.1.

Schedule dellattivit di testing

a) Dovr essere effettuata un'analisi white box (path coverage), che dovr fornire come risultato una copertura del 100% di tutti i path feasible. b) Ogni singolo modulo deve essere sottoposto a testing black box, osservandone il comportamento sia nel caso di inserimento di input corretti, sia nel caso di input non corretti e validando lo scostamento dai risultati attesi. c) Il test di sistema viene effettuato in modo incrementale, integrando in maniera iterativa i moduli che superano il test di integrazione. d) Una volta terminati correttamente i test black e white box si passer all'esecuzione dei test di integrazione in modo da analizzare l'integrazione fra due o pi moduli. e) Attivit di validazione, svolte esternamente (presso l'ambiente di lavoro del committente). f) Alpha testing con l'utilizzo dei sistemi hardware a disposizione. g) Test di accettazione finale, nel quale il committente decide se l'applicazione soddisfa i requisiti per cui stata commissionata.

5.2.

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.

5.2.1.

Tecnica di Testing

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. Una volta terminato con successo verranno eseguiti i test di path coverage.

5.3.

Test Case Specification

Nel Test Case Specification vengono specificati i dati da utilizzare per le varie condizioni di test identificate nel TDS.

103

5.3.1.
Descrizione servizio Input

Aggiungi Giocatore

Pulsante Aggiungi Giocatore Pulsante Registra Pulsante Annulla Campo Informazioni Anagrafiche Campo email

Input corretto Selezione pulsante Aggiungi Giocatore Inserimento campo Informazioni Anagrafiche Inserimento email Selezione pulsante Registra Risultato atteso Al termine del caso duso viene creato un nuovo giocatore Input scorretto Selezione pulsante Aggiungi Giocatore Inserimento errato campo Informazioni Anagrafiche Inserimento email Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: informazioni anagrafiche errate Input scorretto Selezione pulsante Aggiungi Giocatore Inserimento campi Informazioni Anagrafiche Inserimento errato email Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: email errata

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla. Formato standard dellemail.

104

5.3.2.
Precondizioni

Autenticazione

Lutente non connesso al sistema Descrizione servizio Input Input corretto Selezione pulsante Log On Inserimento campo Nome Utente Inserimento campo Password Selezione pulsante Autentica Risultato atteso Al termine del caso duso lutente viene autenticato Input scorretto Selezione pulsante Aggiungi Giocatore Inserimento errato campo Nome Utente Inserimento campo Password Selezione pulsante Autentica Risultato atteso Visualizzazione del messaggio: Nome Utente errato Input scorretto Selezione pulsante Aggiungi Giocatore Inserimento campo Nome Utente Inserimento errato campo Password Selezione pulsante Autentica Risultato atteso Visualizzazione del messaggio: password errata Pulsante LogOn Campo Nome utente Campo Password Pulsante Autentica Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

105

5.3.3.

Avanza fase

Precondizioni L'organizzatore connesso al sistema. Fase attuale terminata. Descrizione servizio Input Input corretto Selezione pulsante Avanza Fase Risultato atteso Al termine del caso duso vengono visualizzati gli accoppiamenti tra le squadre della nuova fase e la lista dei giocatori squalificati Input scorretto Non sono previsti input scorretti. Pulsante Avanza Fase Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

106

5.3.4.

Cambia Data Partita

Precondizioni L'organizzatore connesso al sistema. L'organizzatore ha selezionato la partita. L'incontro non ancora stato giocato. Descrizione servizio Input Input corretto Selezione partita non ancora disputata Selezione pulsante Cambia Data Inserimento campo Nuova Data Selezione pulsante Conferma Risultato atteso Al termine del caso duso il sistema cambia la data alla partita selezionata e il Sistema Gestione Mail invia una mail di avviso ai due capitani. Input scorretto Selezione partita gi disputata Selezione pulsante Cambia Data Inserimento campo Nuova Data Selezione pulsante Conferma Risultato atteso Visualizzazione del messaggio: partita gi disputata Input scorretto Selezione partita non ancora disputata Selezione pulsante Aggiungi Giocatore Inserimento errato campo Nuova Data Selezione pulsante Conferma Risultato atteso Visualizzazione del messaggio: formato data errato Pulsante Cambia Data Campo Nuova Data Pulsante Conferma Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.
107

5.3.5.

Cambia Dati Giocatore

Precondizioni Il capitano connesso al sistema. Le iscrizioni sono aperte. Il capitano ha visualizzato l'elenco dei giocatori della sua squadra. Descrizione servizio Input Input corretto Selezione pulsante Cambia Dati Giocatore Inserimento campo Dati Anagrafici Inserimento campo email Selezione pulsante Conferma Risultato atteso Al termine del caso duso il sistema cambia i dati del giocatore selezionato. Input scorretto Selezione pulsante Cambia Dati Giocatore Inserimento errato campo Dati Anagrafici Inserimento campo email Selezione pulsante Conferma Risultato atteso Visualizzazione del messaggio: dati anagrafici errati Input scorretto Selezione pulsante Cambia Dati Giocatore Inserimento campo Dati Anagrafici Inserimento errato campo email Selezione pulsante Conferma Risultato atteso Visualizzazione del messaggio: formato email errato Pulsante Cambia Dati Giocatore Campo Dati Anagrafici Campo email Pulsante Conferma Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.
108

5.3.6.
Descrizione servizio Input

Cambia Dati Organizzatore

Pulsante Cambia Dati Organizzatore Campo Dati Anagrafici Campo email Pulsante Conferma Pulsante Annulla

Input corretto Selezione pulsante Cambia Dati Organizzatore Inserimento campo Dati Anagrafici Inserimento campo email Selezione pulsante Conferma Risultato atteso Al termine del caso duso il sistema cambia i dati dellorganizzatore selezionato. Input scorretto Selezione pulsante Cambia Dati Organizzatore Inserimento errato campo Dati Anagrafici Inserimento campo email Selezione pulsante Conferma Risultato atteso Visualizzazione del messaggio: dati anagrafici errati Input scorretto Selezione pulsante Cambia Dati Organizzatore Inserimento campo Dati Anagrafici Inserimento errato campo email Selezione pulsante Conferma Risultato atteso Visualizzazione del messaggio: formato email errato

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

109

5.3.7.
Precondizioni

Cancella Giocatore

Le iscrizioni sono ancora aperte. Descrizione servizio Input Input corretto Selezione pulsante Cancella Giocatore Selezione pulsante Conferma Risultato atteso Al termine del caso duso il sistema cancella il giocatore selezionato. Input scorretto Non sono previsti input scorretti. Pulsante Cancella Giocatore Pulsante Conferma Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

110

5.3.8.
Descrizione servizio Input

Cancella Organizzatore

Pulsante Cancella Organizzatore Pulsante Conferma Pulsante Annulla

Input corretto Selezione pulsante Cancella Organizzatore Selezione pulsante Conferma Risultato atteso Al termine del caso duso il sistema cancella lorganizzatore selezionato. Input scorretto Non sono previsti input scorretti.

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

5.3.9.
Descrizione servizio Input

Conferma Lista Definitiva

Pulsante Chiudi Iscrizioni

Input corretto Selezione pulsante Chiudi Iscrizioni Risultato atteso Al termine del caso duso il sistema stampa la lista definitiva delle squadre partecipanti al torneo. Input scorretto Non sono previsti input scorretti.

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

111

5.3.10.
Descrizione servizio Input

Crea Account Organizzatore

Pulsante Crea Account Organizzatore Pulsante Registra Pulsante Annulla Campo Informazioni Anagrafiche Campo email Campo Username Campo Password

Input corretto Selezione pulsante Crea Account Organizzatore Inserimento campo Informazioni Anagrafiche Inserimento email Inserimento campo Username Inserimento campo Password Selezione pulsante Registra Risultato atteso Al termine del caso duso viene creato un nuovo account amministratore Input scorretto Selezione pulsante Crea Account Organizzatore Inserimento campo errato Informazioni Anagrafiche Inserimento email Inserimento campo Username Inserimento campo Password Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: informazioni anagrafiche errate Input scorretto Selezione pulsante Crea Account Organizzatore Inserimento campo Informazioni Anagrafiche Inserimento errato email Inserimento campo Username Inserimento campo Password Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: email errata Input scorretto
112

Selezione pulsante Crea Account Organizzatore Inserimento campo Informazioni Anagrafiche Inserimento email Inserimento errato campo Username Inserimento campo Password Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: nome utente gi utilizzato

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla. Formato standard dellemail.

5.3.11.
Precondizioni

Crea Nuovo Capitano

Le iscrizioni sono sempre aperte. Descrizione servizio Input Input corretto Selezione pulsante Crea Nuova Squadra Inserimento campo Username Inserimento campo Password Inserimento campo Informazioni Anagrafiche Inserimento email Inserimento nome Nuova Squadra Selezione pulsante Registra
113

Pulsante Crea Nuova Squadra Pulsante Registra Pulsante Annulla Campo Informazioni Anagrafiche Campo Nome Squadra Campo email Campo Username Campo Password

Risultato atteso Al termine del caso duso viene creata una nuova squadra. Input scorretto Selezione pulsante Crea Nuova Squadra Inserimento campo errato Username Inserimento campo Password Inserimento campo Informazioni Anagrafiche Inserimento email Inserimento nome Nuova Squadra Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: username inesistente Input scorretto Selezione pulsante Crea Nuova Squadra Inserimento campo Username Inserimento campo errato Password Inserimento campo Informazioni Anagrafiche Inserimento email Inserimento nome Nuova Squadra Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: password errata Input scorretto Selezione pulsante Crea Nuova Squadra Inserimento campo Username Inserimento campo Password Inserimento errato campo Informazioni Anagrafiche Inserimento email Inserimento nome Nuova Squadra Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: dati anagrafici errati Input scorretto Selezione pulsante Crea Nuova Squadra Inserimento campo Username Inserimento campo Password Inserimento campo Informazioni Anagrafiche Inserimento errato email Inserimento nome Nuova Squadra Selezione pulsante Registra

114

Risultato atteso Visualizzazione del messaggio: email errata Input scorretto Selezione pulsante Crea Nuova Squadra Inserimento campo Username Inserimento campo Password Inserimento campo Informazioni Anagrafiche Inserimento email Inserimento errato nome Nuova Squadra Selezione pulsante Registra Risultato atteso Visualizzazione del messaggio: nome squadra gi usato

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla. Formato standard dellemail.

115

5.3.12.
Precondizioni

Emetti Multa

stata selezionata una squadra. Descrizione servizio Input Input corretto Selezione pulsante Multa Squadra Inserimento campo Importo Multa Selezione pulsante Emetti Multa Risultato atteso Al termine del caso duso viene stampata la multa. Input corretto Selezione pulsante Multa Giocatore Inserimento campo Importo Multa Selezione pulsante Emetti Multa Risultato atteso Al termine del caso duso viene stampata la multa. Input scorretto Selezione pulsante Multa Squadra Inserimento campo Importo Multa Selezione pulsante Emetti Multa Risultato atteso Visualizzazione del messaggio: inserito importo negativo Pulsante Multa Squadra Pulsante Multa Giocatore Pulsante Emetti Multa Pulsante Annulla Campo Importo Multa

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

116

5.3.13.
Precondizioni

Inserisci Data

stata selezionata una partita. Descrizione servizio Input Input corretto Selezione pulsante Inserisci Data Inserimento campo Data Selezione pulsante Memorizza Risultato atteso Al termine del caso duso viene memorizzata la data di svolgimento della partita selezionata Input scorretto Selezione pulsante Inserisci Data Inserimento campo Data Selezione pulsante Memorizza Risultato atteso Visualizzazione del messaggio: formato data non corretto. Pulsante Inserisci Data Pulsante Memorizza Pulsante Annulla Campo Data

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

117

5.3.14.
Precondizioni

Inserisci referto

stata selezionata una partita. Descrizione servizio Input Input corretto Selezione pulsante Inserisci Referto Inserimento campo Marcatori Inserimento campo Minuti Inserimento campo Cartellini Selezione pulsante Memorizza Risultato atteso Al termine del caso duso viene memorizzato il referto della partita. Input scorretto Non sono previsti input scorretti. Pulsante Inserisci Referto Pulsante Memorizza Pulsante Annulla Campo Marcatori Campo Minuti Campo Cartellini

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

118

5.3.15.
Precondizioni

Inserisci Risultati

stata selezionata una partita. Descrizione servizio Input Input corretto Selezione pulsante Inserisci Risultati Inserimento campo Risultato Selezione pulsante Memorizza Risultato atteso Al termine del caso duso viene memorizzato il risultato finale della partita. Input scorretto Selezione pulsante Inserisci Risultati Inserimento campo Risultato Selezione pulsante Memorizza Risultato atteso: Visualizzazione del messaggio: inserito risultato negativo Pulsante Inserisci Risultati Pulsante Memorizza Pulsante Annulla Campo Risultato

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

119

5.3.16.
Precondizioni

Notifica Certificati

stata selezionata una squadra e un giocatore appartenente ad essa. Descrizione servizio Input Input corretto Selezione pulsante Certificato Consegnato Selezione pulsante Memorizza Risultato atteso Al termine del caso duso viene memorizzata lavvenuta consegna del certificato da parte del giocatore. Input scorretto Non sono previsti input scorretti Pulsante Certificato Consegnato Pulsante Memorizza Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

120

5.3.17.
Precondizioni

Notifica Pagamenti

stata selezionata una squadra con almeno 5 giocatori e il termine di chiusura delle iscrizioni al torneo non scaduto. Descrizione servizio Input Input corretto Selezione pulsante Pagamento Selezione pulsante Memorizza Risultato atteso Al termine del caso duso viene memorizzata lavvenuto pagamento della quota di iscrizione. Input scorretto Selezione pulsante Pagamento Selezione pulsante Memorizza Risultato atteso Visualizzazione del messaggio: pagamento gi effettuato. Pulsante Pagamento Pulsante Memorizza Pulsante Annulla

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

121

5.3.18.
Descrizione servizio Input

Pubblica Data Fine Iscrizioni

Pulsante Inserisci Data Fine Iscrizioni Pulsante Memorizza Pulsante Annulla Campo Data

Input corretto Selezione pulsante Inserisci Data Fine Iscrizioni Inserimento campo Data Selezione pulsante Memorizza Risultato atteso Al termine del caso duso viene memorizzata la data di termine iscrizioni. Input scorretto Selezione pulsante Inserisci Data Inserimento campo Data Selezione pulsante Memorizza Risultato atteso Visualizzazione del messaggio: formato data non corretto.

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

122

5.3.19.
Precondizioni

Richiedi Cambio Data

E stata selezionata una partita. Descrizione servizio Input Input corretto Selezione pulsante Richiedi Cambio Data Inserimento campo Data Selezione pulsante Invia Risultato atteso Al termine del caso duso viene inviata la richiesta di modifica della data per la partita corrente. Input scorretto Selezione pulsante Richiedi Cambio Data Inserimento campo Data Selezione pulsante Invia Risultato atteso Visualizzazione del messaggio: formato data non corretto. Pulsante Richiedi Cambio Data Pulsante Invia Pulsante Annulla Campo Data

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

123

5.3.20.
Descrizione servizio Input

Ritira Squadra

Pulsante Ritira Squadra Pulsante Conferma Pulsante Annulla

Input corretto Selezione pulsante Ritira Squadra Selezione pulsante Conferma Risultato atteso Al termine del caso duso viene eliminata la squadra. Input scorretto Non sono previsti input scorretti.

Precondizioni Le iscrizioni al torneo sono chiuse. Input Input corretto Selezione pulsante Ritira Squadra Selezione pulsante Conferma Risultato atteso Al termine del caso duso viene eliminata la squadra e il relativo account del capitano. Input scorretto Non sono previsti input scorretti.

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

124

5.3.21.
Descrizione servizio Input

Visualizza Dati Giocatore

Pulsante Visualizza Dati Giocatore Pulsante Invia Pulsante Annulla Campo Nome Campo Cognome

Input corretto Selezione pulsante Visualizza Dati Giocatore Inserimento campo Nome Inserimento campo Cognome Selezione pulsante Invia Risultato atteso Al termine del caso duso vengono visualizzati i dati del giocatore selezionato. Input scorretto Selezione pulsante Visualizza Dati Giocatore Inserimento campo Nome Inserimento campo Cognome Selezione pulsante Invia Risultato atteso Visualizzazione del messaggio: giocatore non trovato.

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

125

5.3.22.
Descrizione servizio Input

Trova Dati Organizzatore

Pulsante Visualizza Dati Organizzatore Pulsante Invia Pulsante Annulla Campo Nome Campo Cognome

Input corretto Selezione pulsante Visualizza Dati Organizzatore Inserimento campo Nome Inserimento campo Cognome Selezione pulsante Invia Risultato atteso Al termine del caso duso vengono visualizzati i dati del giocatore selezionato. Input scorretto Selezione pulsante Visualizza Dati Organizzatore Inserimento campo Nome Inserimento campo Cognome Selezione pulsante Invia Risultato atteso Visualizzazione del messaggio: organizzatore non trovato.

Condizioni software E' sempre possibile annullare l'operazione tramite la selezione del pulsante annulla.

126

5.3.23.
Precondizioni

Trova Squadra

Le iscrizioni al torneo sono chiuse. Descrizione servizio Input Input corretto Selezione pulsante Vedi Info Squadre Selezione di una squadra Risultato atteso Al termine del caso duso vengono visualizzati i giocatori appartenenti alla squadra selezionata. Input scorretto Non sono previsti input scorretti. Pulsante Vedi Info Squadre

5.3.24.
Descrizione servizio Input

Visualizza Elenco Squadre

Pulsante Elenco Squadre

Input corretto Selezione pulsante Elenco Squadre Selezione di una squadra Risultato atteso Al termine del caso duso vengono visualizzati i dettagli della squadra selezionata. Input scorretto Non sono previsti input scorretti.

127

5.3.25.
Precondizioni

Visualizza Partita

Le iscrizioni al torneo sono chiuse. Descrizione servizio Input Input corretto Selezione pulsante Vedi Partita Risultato atteso Al termine del caso duso vengono visualizzati tutti gli accoppiamenti del torneo con relativa data in cui si disputer l'incontro e risultato finale della partita se giocata. Input scorretto Non sono previsti input scorretti. Pulsante Vedi Partita

5.3.26.
Precondizioni

Visualizza Referto

stata selezionata una partita. Descrizione servizio Input Input corretto Selezione pulsante Referto Risultato atteso Al termine del caso duso vengono visualizzati i marcatori, il minuto di realizzazione e i cartellini assegnati nellincontro selezionato. Input scorretto Non sono previsti input scorretti. Pulsante Referto

128

5.3.27.
Descrizione servizio Input

Visualizza Regolamento

Pulsante Regolamento

Input corretto Selezione pulsante Regolamento Risultato atteso Al termine del caso duso viene visualizzato il regolamento del torneo. Input scorretto Non sono previsti input scorretti.

5.3.28.
Precondizioni

Visualizza Dettagli Squadra

stata selezionata una squadra. Descrizione servizio Input Input corretto Selezione pulsante Info Squadra Risultato atteso Al termine del caso duso vengono visualizzate i dati anagrafici dei giocatori, le squalifiche, i certificati consegnati e lo stato del pagamento di ognuno di essi. Input scorretto Non sono previsti input scorretti. Pulsante Info Squadra

129

5.3.29.
Precondizioni

Visualizza Giocatori Squadra

stata selezionata una squadra. Descrizione servizio Input Input corretto Selezione pulsante Giocatori Risultato atteso Al termine del caso duso vengono visualizzate i dati anagrafici e le relative squalifiche dei giocatori della squadra selezionata. Input scorretto Non sono previsti input scorretti. Pulsante Giocatori

5.3.30.
Descrizione servizio Input

Visualizza Mia Squadra

Pulsante Gestisci Squadra

Input corretto Selezione pulsante Gestisci Squadra Risultato atteso Al termine del caso duso vengono visualizzate le informazioni anagrafiche dei giocatori della propria squadra, con relativo stato di consegna del certificato medico e dello stato di pagamento della quota discrizione. Input scorretto Non sono previsti input scorretti.

130

5.3.31.
Descrizione servizio Input

Visualizza Richieste

Pulsante Visualizza Richieste

Input corretto Selezione pulsante Visualizza Richieste Risultato atteso Al termine del caso duso vengono visualizzate le eventuali richieste di cambio data e di ritiro della squadra. Input scorretto Non sono previsti input scorretti.

131

Capitolo 6 Analisi
6.1.

dello sforzo

Piano di valutazione dello sforzo

6.1.1.

Presentazione

Lobiettivo di questo documento quello di presentare i risultati derivanti dalla valutazione dello sforzo e illustrare le tecniche adottate per pervenire a tali risultati. Il piano di valutazione dello sforzo si articola nei seguenti punti: Metriche di misurazione Calcolo dei punti funzione Analisi CoCoMo

6.1.2 Metriche di misurazione


Per realizzare il piano di valutazione dello sforzo necessario disporre di alcuni punti di partenza. In particolare necessario reperire i dati pi significativi, cio quelli che influenzano il costo di realizzazione del sistema e per questo incidono maggiormente sulla stima dello sforzo. La scelta degli input da considerare ricade necessariamente sulla dimensione del software, dl momento che questo parametro quello che pi di tutti influenza il costo dellapplicazione. Nel mondo del software la dimensione non un concetto assoluto, al punto che esistono differenti metriche: Metriche dimensionali Metriche funzionali

132

6.1.3 Metriche dimensionali


Le metriche dimensionali hanno come obiettivo quello di misurare la dimensione del software in maniera diretta. Le tecniche pi utilizzate sono: Misurazione del numero di linee di codice(LOC): si tratta di una metrica tradizionalmente importante, anche se in realt non sempre significativa, specie se riferita a linguaggi di programmazione differenti. Misurazione del numero degli statement eseguibili previsti (ES) Misurazione delle linee del codice sorgente previste (SLOC) Misurazione del numero di istruzioni previste (KDSI) Misurazione del numero di commenti in un programma (CLOC)

6.1.4 Metriche funzionali


A differenza delle metriche dimensionali, le metriche funzionali consentono una determinazione indiretta della dimensione del software, basata sulla misurazione delle funzionalit che questo deve svolgere. La tecnica pi utilizzata appartenente a questa categoria senza dubbio il calcolo dei punti funzione (FP), che fornisce informazioni importanti anche per quel che riguarda la stima del costo, nonch la previsione del tempo necessario alla realizzazione del sistema. Il calcolo dei punti funzione avviene tramite una relazione empirica che si basa sui valori di cinque indici, che sono: Numero di input esterni (EI): il numero di informazioni distinte provenienti da un utente o da unaltra applicazione che vengono utilizzate come input dal sistema. Numero di output esterni (EO): il numero di informazioni distinte che il sistema fornisce ad un utente o da unaltra applicazione come risultato delle proprie elaborazioni. Numero di richiese esterne (EQ): il numero di interrogazioni online che producono una risposta immediata del sistema. Numero di file logici interni (ILF): il numero di file che risiedono allinterno del sistema. Ogni file un raggruppamento logico di dati. Numero di file dellinterfaccia esterna (EIF): il numero di file che risiedono esternamente al sistema, ma che forniscono dati a questultimo.

133

6.2.

Analisi dei punti funzione

I Function Point sono la misura della dimensione funzionale di un'applicazione, basata sul numero e tipo delle informazioni in entrata, in uscita e in memorizzazione. Per dimensione funzionale di un'applicazione si intende una misura convenzionale standard indipendente dalla tecnologia utilizzata nella realizzazione del software. I Function Point sono quindi di ausilio per stimare a priori l'impegno necessario per realizzare un progetto e a posteriori per calcolare il valore del prodotto e del patrimonio software. Un metodo FSM (dimensione funzionale del software) dovr avere le seguenti caratteristiche: Si basa su una rappresentazione dei requisiti utente vista da una prospettiva degli utenti; Pu essere applicato tempestivamente appena i requisiti funzionali utente sono stati definiti e sono disponibili; Deriva la dimensione funzionale a partire da requisiti funzionali, indipendentemente dai requisiti tecnici e dalla qualit.

La dimensione funzionale inoltre indipendente dall'effort necessario allo sviluppo o alla manutenzione, dalle metodologie impiegate, dai supporti fisici utilizzati e dalle componenti tecnologiche. I Function Point si concretizzano in una serie di punteggi (pesi) assegnati secondo regole di conteggio a Input(EI), Interrogazioni(EQ), Output(EO), File logici interni (ILF), File logici esterni (EIF) evidenti dall'esame dell'applicazione e della sua documentazione. Nel mondo dell'informatica la metrica dei Function Point si sta sostituendo gradualmente alle LoC. Le LoC variano, a parit di funzioni svolte, secondo il tipo di linguaggio utilizzato e sono pi difficilmente quantificabili da quando si sono diffusi maggiormente linguaggi visuali avanzati per GUI e WEB rispetto ai linguaggi software tradizionali. La corrispondenza media che si verifica tra le LoC e i FP chiamata, da Capers Jones, backfire. Secondo tale autore 1 FP equivale a: 320 LoC Assembler; 128 LoC C; 107 LoC Cobol; 91 LoC Cobol II; 55 LoC C++; 35 LoC Java.

134

6.3.

Calcolo dei Function Point

I Function Point rappresentano qualcosa di pi di una tecnica di conteggio in quanto contribuiscono ad un approfondimento delle funzionalit, producendo un miglioramento dell'analisi dei requisiti e rendendone possibile una quantificazione, migliorano le stime, supportano il test di accettazione e migliorano la documentazione generale del software. Gli elementi oggetto di conteggio sono in relazione tra loro. In sintesi i File interni o esterni all'applicazione sono referenziati in modo diverso dalle attivit elementari di Input, Interrogazione e Output. Di seguito si riportano gli intenti primari che le attivit elementari intendono svolgere. Ad esempio un input avr la finalit principale di inserire dati in un file, ma secondariamente potr anche leggere informazioni su un altro file (tra parentesi sono indicati gli intenti non primari):

Attivit elementari Input esterni (EI) Interrogazioni esterne (EQ) Output esterni (EO)

File logico interno (ILF) scrittura (lettura) presentare presentare (scrittura)

File logico esterno (EIF) (lettura) presentare presentare

Un esempio di Input (EI) si verifica con l'acquisizione di dati, un esempio di Interrogazione (EQ) con il fornire una risposta semplice ad una domanda ed un esempio di Output (EO) con la stampa dei dati elaborati. Queste attivit costituiscono i processi elementari, cio le pi piccole unit di azione significative per l'utente.

135

Nella tabella successiva viene indicato il metodo di calcolo dei VPi. Tali valori sono il punto di partenza per determinare i FP.

Mentre i valori pi a destra nella colonna di conteggio vengono moltiplicati per un coefficiente di complessit complesso. E compito di chi effettua lanalisi dello sforzo stabilire per ogni valore di conteggio il livello di complessit appropriato; si tratta pertanto di una valutazione soggettiva che si basa sullosservazione ed il confronto con applicazioni software dello stesso genere gi in uso. Ai fini del calcolo dei punti funzione significativo solamente il valore totale della tabella sopra riportata, ottenuto come somma dei contributi relativi a ciascun indice considerato. Per calcolare i punti funzione, oltre al valore del totale, necessario determinare anche i cosiddetti fattori di aggiustamento (Fi). Si tratta di 14 valori, ognuno dei quali compreso tra 0 e 5, ottenuti rispondendo ad un questionario sulla base della convenzione:

136

Le domande del questionario, relative al sistema, si possono riassumere: 1) Come si valuta il bisogno di operazioni di backup e ripristino affidabili? 2) Come si valuta limpiego di comunicazioni specializzate per trasferire le informazioni da o verso il sistema? 3) Come si valuta limpiego di funzioni di elaborazione distribuita? 4) Come si valuta il fattore di criticit delle prestazioni? 5) Come si valuta il funzionamento del sistema in un ambiente operativo esistente sottoposto ad un utilizzo intensivo? 6) Come si valuta linserimento online dei dati? 7) Come si valuta linserimento online dei dati attraverso una transazione di input costituita da pi operazioni? 8) Come si valuta laggiornamento online dei ILF? 9) Come si valuta la presenza di input, output, file o richieste di natura complessa? 10) Come si valuta la complessit dellelaborazione interna? 11) Come si valuta la progettazione finalizzata al riutilizzo del codice? 12) Come si valuta la presenza della conversione e dellistallazione nella fase di progetto? 13) Come si valuta la possibilit di utilizzare il sistema per pi installazioni e in pi organizzazioni? 14) Come si valuta la progettazione finalizzata alla facilit duso da parte degli utenti?

Per completezza di riporta di seguito il questionario in forma integrale, cos come presentato da uno dei tanti software di valutazione dello sforzo in commercio: 1. Facilit di gestione operativa: si intende verificare se lapplicazione minimizza la necessit di attivit manuali quando sono richieste dallutente: 0 Non ci sono specifiche eccetto le normali procedure di salvataggio

1 4 Controllare quante delle seguenti voci risultano soddisfatte: 5 Sono fornite efficaci procedure di avviamento, salvataggio e ripristino ma richiesto lintervento delloperatore; Sono fornite efficaci procedure di avviamento, salvataggio e ripristino e non richiesto lintervento delloperatore (vale due voci) Lapplicazione minimizza la necessit di montaggio di nastri Lapplicazione minimizza la necessit di gestione della carta Lapplicazione deve svolgere operazioni non presidiate (nessun intervento da parte di un operatore ad eccezione dellavviamento o della chiusura), occorre il recupero automatico di eventuali errori.
137

2. Comunicazione dati: occorre valutare in quale misura lapplicazione riceve e trasmette dati attraverso sistemi di comunicazione (si consideri trasmissione dati anche verso il terminale locale dellunit di controllo) e quanto ci influenza lo sviluppo dellapplicazione, face ndo in modo che siano supportati pi protocolli di trasmissione: 0 Lapplicazione una semplice elaborazione batch o risiede su di un calcolatore che opera autonomamente Lapplicazione batch, ma ha inserimento dati o stampa remoti Lapplicazione batch, ma ha inserimento dati o stampa remoti Lapplicazione utilizza una raccolta dati interattiva o un front-end TP (Tele Processing) verso un processo batch o un sistema di interrogazioni Lapplicazione pi di un front-end ma supporta solo un tipo di protocollo di comunicazione TP Lapplicazione pi di un front-end e supporta pi di un tipo di protocollo di comunicazione

1 2 3

3. Distribuzione dellelaborazione: si cerchi di indicare come sono distribuiti i dati e le funzioni di elaborazione allinterno dei confini dellapplicazione e se lapplicazione interessata dal loro movimento 0 1 Lapplicazione non fornisce ausili al trasferimento dati o funzioni di elaborazione Lapplicazione prepara i dati per lelaborazione da parte dellutente finale su di un altro componente del sistema come un foglio elettronico o un DBMS Lapplicazione prepara , trasferisce ed elabora i dati su di un altro componente del sistema La distribuzione dei dati e funzioni interattiva ed unidirezionale La distribuzione dei dati e funzioni interattiva ed bidirezionale Le funzioni di elaborazione sono eseguite dinamicamente sul componente pi appropriato del sistema

2 3 4 5

138

4. Prestazioni: si indichi se allapplicazione sono posti vincoli stringenti su tempi di rispost a o troughput (quantit di lavoro per unit di tempo) tali da influenzare lo sviluppo: 0 1 2 Nessun particolare requisito prestazionale stato espresso dallutente I requisiti prestazionali espressi non comportano azioni particolari Il tempo di risposta o il troughput sono critici durante le ore di picco. Non richiesta alcuna progettazione per lutilizzo della CPU. Lelaborazione pu essere completata il successivo giorno lavorativo Il tempo di risposta o il troughput sono critici durante tutte le ore lavorative. Non richiesta alcuna progettazione per lutilizzo della CPU. I sistemi interfacciati allapplicazione pongono dei vincoli sul completamento dellelaborazione In aggiunta i requisiti prestazionali richiedono un passo di analisi delle prestazioni durante la progettazione In aggiunta i requisiti prestazionali richiedono analisi delle prestazioni durante le fasi di progettazione, sviluppo, realizzazione

5. Utilizzo estensivo della configurazione: si valuti se lapplicazione stata pensata in funzione di una particolare configurazione di hardware: 0 1 Lapplicazione non vincolata da particolari configurazioni hardware Le configurazioni hardware particolari pongono dei vincoli gi naturalmente soddisfatti dallapplicazione Occorre fare considerazioni su sicurezza e tempi Una parte specifica dellapplicazione richiede un processore con particolari requisiti Limitazioni operative esplicite richiedono un elaboratore dedicato per lapplicazione Lapplicazione pone dei vincoli sui componenti distribuiti del sistema

2 3 4 5

139

6. Inserimento dati interattivo: stabilire se lapplicazione fornisce funzioni per linserimento e il controllo interattivo di dati: 0 Tutte le transazioni sono elaborate in modalit batch Le transazioni per linserimento interattivo di dati sono comprese: 1 2 3 4 5 fra 1% e 7% fra 8% e 15% fra 16% e 23% fra 24% e 30% fra 30% e 100%

7. Frequenza delle transazioni: valutare se una eventuale alta frequenza di transazioni influenza le fasi di progettazione, sviluppo, installazione o gestione dellapplicazione: 0 1 2 3 4 Non previsto un periodo di picco delle transazioni E previsto un periodo di picco delle transazioni E previsto un picco settimanale delle transazioni E previsto un picco giornaliero delle transazioni Lalta frequenza di transazioni dichiarata o gli accordi sui livelli di servizio sono tali da richiedere un passo di analisi delle prestazioni durante la progettazione In aggiunta richiesto luso di strumenti per lanalisi delle presta zioni durante le fasi di progettazione, sviluppo e/o installazione.

140

8. Aggiornamento interattivo: si stabilisca se lapplicazione fornisce laggiornamento interattivo dei suoi file interni logici: 0 1 Nessun aggiornamento previsto Si possono aggiornare in modo interattivo da uno a tre file logici, il volume di aggiornamenti basso e le operazioni sui file semplici Si possono aggiornare da quattro o pi file logici; il volume di aggiornamenti basso e le operazioni sui file semplici E possibile aggiornare la maggior parte dei ILF In aggiunta il sistema stato progettato con protezione contro la perdita di dati In aggiunta elevati volumi di aggiornamento portano a dover considerare i costi di ripristino. Sono presenti procedure di ripristino automatizzate che richiedono il minimo intervento delloperatore.

3 4 5

9. Facilit di modifica: Per valutare linfluenza della facilit di modifica si veda quante fra le seguenti voci riguardano lapplicazione in esame; il loro numero restituisce il grado di influenza (0-5): Sono fornite delle interrogazioni flessibili ad ausili per la produzione di prospetti che gestiscono semplici richieste, ad esempio and oppure or logici applicati solamente ad un ILF; Sono fornite delle interrogazioni flessibili ad ausili per la produzione di prospetti che gestiscono richieste di media complessit, ad esempio and oppure or logici applicati a pi di un ILF(vale due voci) Sono fornite delle interrogazioni flessibili ad ausili per la produzione di prospetti che gestiscono richieste complesse, ad esempio combinazioni di and e or logici applicati a uno o pi ILF I dati di controllo per le funzioni sono in tabelle che lutente pu mantenere con elaborazioni interattive i cambiamenti diventano effettivi il giorno seguente I dati di controllo per le funzioni sono in tabelle che lutente pu mantenere con elaborazioni interattive i cambiamenti diventano immediatamente effettivi il giorno seguente (vale due voci)

141

10. Complessit elaborativa: per valutare linfluenza della complessit elaborativa si stabilisca quante fra le seguenti voci riguardano lapplicazione in esame; il loro numero restituisce il grado di influenza (0-5): Controlli dedicati e/o particolari elaborazioni di sicurezza (per esempio speciali elaborazioni di verifica) Notevole elaborazione logica Notevole elaborazione matematica Molte eccezioni che impediscono landamento a buon fine di transazioni che devono poi essere rifatte o annullate Elaborazione complessa che gestisce pi possibilit di input-output

11. Riusabilit: valutare quanta parte di codice sfruttabile o verr sfruttata da altre applicazioni: Nessuna parte di codice riusabile Il codice riusabile allinterno dellapplicazione stessa Meno del 10% dellapplicazione sfruttabile dallutente per altre necessit non previste dal progetto Il 10% o pi dellapplicazione sfruttabile dallutente per altre necessit non previste dal progetto Lapplicazione stata specificatamente progettata e/o documentata per un facile riuso, essa personalizzabile a livello di codice Come sopra tranne che si pu personalizzare lapplicazione mediante la modifica di parametri utente

142

12. Facilit distallazione: Si determini il grado di facilit di installazione dellapplicazione: Non ci sono specifiche e linstallazione non richiede particolari inizializzazioni Non ci sono specifiche e linstallazione non richiede particolari inizializzazioni Ci sono specifiche per la conversione e linstallazione, sono state fornite guide, ma limpatto sul progetto trascurabile Ci sono specifiche per la conversione e linstallazione, sono state fornite guide, ma limpatto della conversione sul progetto rilevante In aggiunta al punto 2 sono stati forniti strumenti automatici per la conversione e linstallazione In aggiunta al punto 3 sono stati forniti strumenti automatici per la conversione e linstallazione

13. Molteplicit di siti: se lapplicazione nata considerando una sua eventuale diffusione in varie sedi con esigenze simili, per sfruttare questa diffusione: 0 Non necessario considerare pi linstallazione dellapplicazioni in pi sedi (o per pi utenti) 1 2 3 4 Si deve considerare linstallazione in pi siti con hardware e software identici Si deve considerare linstallazione in pi siti con hardware e/o software simili Si deve considerare linstallazione in pi siti con hardware e software diversi Lapplicazione descritta dal punto 1 o 2; inoltre fornita documentazione e piani di supporto per la gestione in pi siti Lapplicazione descritta dal punto 3; inoltre fornita documentazione e piani di supporto per la gestione in pi siti

143

14. Efficienza per lutente finale: si valuti se le eventuali funzioni interattive presentano alcune delle seguenti caratteristiche mirate allefficienza duso per lutente Aiuti di navigazione Menu Help e documentazione in linea Spostamento automatico cursore Scorrimento Stampe remote per mezzo di transazioni interattive Tasti funzionali predefiniti Richiesta di attivazione di job batch attraverso transazioni interattive Selezione con cursore dei dati a video Uso di strumenti grafici per arricchire il contenuto informativo (colori,..) Documentazione mediante hard copy delle transazioni interattive Supporto mouse Pop up Minimizzazione schermate per completare una sessione interattiva Supporto per due lingue (valore 4) Supporto multilingue(valore 6) In base alla quantit delle caratteristiche presenti si assegni un punteggio secondo il seguente criterio: 0 1 2 3 Nessuna caratteristica Da 1 a 3 405 Oltre 6

4 In aggiunta ci sono delle specifiche che impongono una progettazione orientata ai fattori umani, ad esempio uso di valori predefiniti, di modelli, etc. 5 In aggiunta occorre luso di strumenti e procedure per verificare il raggiungimento dellefficienza.

144

Ricavati i valori di Fi (con i che va da 0 a 13) e noto il valore totale (conteggio_totale), possibile calcolare analiticamente FP utilizzando la formula seguente:

FP = conteggio_totale x (0,65 + 0,01 x Fi)


Al fine di determinare la dimensione del sistema software realizzato e di effettuare una conseguente analisi dello sforzo, il team deve scegliere una metrica tra quelle presentate. La scelta ricade sulla metrica funzionale, dal momento che lanalisi dello sforzo basata su FP ritenuta pi affidabile rispetto alla medesima analisi basata sul numero di linee di codice (SLOC). La determinazione dei FP effettuata tramite il software Costar 7.0 attraverso una serie di semplici passaggi che vedremo in seguito.

6.4.

Calcolo dei valori di conteggio per ciascun indice

6.4.1. Determinazione della complessit degli EI (external inputs)

Gli input esterni corrispondono a processi elementari che elaborano dati provenienti dallesterno del sistema. Per individuare gli input esterni si fa riferimento alle seguenti operazioni elementari: Inserimento Modifica e aggiornamento Rimozione

La ricerca degli input esterni ha portato alla costruzione della seguente tabella:

Caso duso Aggiungi Giocatore Cambia Dati Giocatore Cambia Dati Organizzatore Crea Account Organizzatore Crea Nuovo Capitano Emetti Multa Inserisci Referto Inserisci Risultati TOTALE

EI 6 3 3 6 6 4 4 6 38 alta bassa bassa alta alta media media alta

145

6.4.2. Determinazione della complessit degli EQ (external queries)

Le richieste esterne corrispondono a processi elementari composti da un output, che si risolvono in un reperimento di dati. Per individuare le richieste esterne si fa riferimento alle seguenti operazioni elementari: Ricerche Visualizzazioni

La tabella seguente mostra il risultato della ricerca delle richieste esterne:

Caso duso Aggiungi Giocatore Autenticazione Avanza Fase Conferma Lista Definitiva Crea Account Organizzatore Crea Nuovo Capitano Visualizza Dati Giocatore Trova Dati Organizzatore Trova Squadra Visualizza Elenco Squadre Visualizza Partita Visualizza Referto Visualizza Dettagli Squadra Visualizza Giocatori Squadra Visualizza Mia Squadra Visualizza Richieste TOTALE

EQ 3 4 6 6 3 3 3 4 4 3 3 3 4 4 4 4 67 bassa media alta alta bassa bassa bassa media media bassa bassa bassa media media media media

146

6.4.3. Determinazione della complessit degli EO (external outputs)

Gli output esterni corrispondono a processi elementari che elaborano dati inviati allesterno del sistema. Per individuare gli output esterni si fa riferimento alle seguenti operazioni elementari: Notifica Richiesta

La ricerca degli output esterni ha portato alla costruzione della seguente tabella:

Caso duso Avanza Fase Conferma Lista Definitiva Emetti Multa Pubblica Data Fine Iscrizioni Visualizza Dati Giocatore Trova Dati Organizzatore Trova Squadra Visualizza Elenco Squadre Visualizza Partita Visualizza Referto Visualizza Regolamento Visualizza Dettagli Squadra Visualizza Giocatori Squadra Visualizza Mia Squadra Visualizza Richieste TOTALE

EO 7 5 4 4 7 5 5 5 4 5 4 7 7 7 5 81 alta media bassa bassa alta media media media bassa media bassa alta alta alta media

147

6.4.4.

Determinazione della complessit degli EIF (external files)

Non sono previsti gruppi di dati logici referenziati dal sistema e appartenenti al dominio di altre applicazioni.

6.4.5.

Determinazione della complessit degli ILF (internal files)

Si considerano files logici interni i gruppi di dati logici mantenuti allinterno del dominio del sistema tramite processi elementari. Lorganizzazione dei files logici avviene allinterno del sistema mediante relazioni (tabelle) del modello entit-relazioni. Il vincolo da rispettare per quel che riguarda lorganizzazione dei dati logici che ciascun file logico deve contenere almeno una relazione. Per individuare i files logici interni si fa riferimento ai seguenti gruppi di dati logici: Utilizzatori del sistema Proposte Corrispondenze Catalogo Articoli trattati dai clienti

Caso duso Avanza Fase

ILF 10 media

148

6.4.6.

Calcolo dei fattori di aggiustamento

Caratteristica Comunicazione dati Distribuzione dellelaborazione Prestazioni Utilizzo intensivo della configurazione Frequenza delle transazioni Inserimento dati interattivo Efficienza per lutente finale Aggiornamento interattivo Complessit elaborativa Riusabilit Facilit di installazione Facilit di gestione operativa Molteplicit di siti Facilit di modifica Totale

Valore 2.5 0 2 0 2 3 3 0 1 2.5 2 2 0 2 25

6.4.7.

Calcolo FP e LoC

FP = 196 (0.65 + 0.01 25) = 176.4 LoC = 176.4 30 5292

149

6.5.

Valutazione dello sforzo con CoCoMo

Il gruppo ha deciso di servirsi del metodo CoCoMo (Constructive Cost Model) per effettuare una stima temporale dello sforzo. In particolare abbiamo utilizzato l'applicazione Costar 7.0 CoCoMo II 2000 per effettuare i calcoli necessari. CoCoMo un metodo per calcolare il numero di mesi-uomo necessari per portare a termine un progetto software. Il dato di partenza il calcolo delle LoC (Line of code), che sono state stimate nel paragrafo precedente, in seguito si procede determinando i valori degli Scale Driver ed infine quelli dei Cost Driver.

6.5.1.

Scale Driver

Gli scale driver sono 5 fattori considerati pi importanti per stabilire il costo del progetto:

150

6.5.2.

Cost Driver

I cost driver (elencati nella seguente tabella) sono 17 fattori moltiplicativi utilizzati per determinare lo sforzo richiesto.

Le scelte effettuate sono riportate nella seguente figura:

XH=Extra High VH=Very High H=High N=Nominal L=Low VL=Very Low

Figura 38 - Cost Driver Report

151

6.5.3.

Calcolo del valore conteggio_totale

Per il calcolo del valore conteggio_totale il team si servito del software Costar 7.0, che offre un'interfaccia molto immediata per l'inserimento dei valori di conteggio relativi a ciascun indice.

Figura 39 - UnAdjusted Function Points

Il valore conteggio_totale quello evidenziato in rosso e si ottiene analiticamente seguendo la procedura descritta nel paragrafo 6.3.

152

6.5.4.

Calcolo della sommatoria degli Fi

Anche per il calcolo della sommatoria degli Fi si ricorso a Costar 7.0, dal momento che questo software consente di rispondere alle domande del questionario in maniera molto semplice. La figura 40 mostra le risposte fornite alle 14 domande riportate in maniera dettagliata nel paragrafo 6.3.

Figura 40 - Fattore di aggiustamento

Sulla base della compilazione del questionario, il software ha provveduto ad aggiornare il valore

della sommatoria degli F1 ed ha modificato la quantit (0,65 + 0,01 x Fi ), meglio nota come fattore di aggiustamento. Nella figura 40 il fattore di aggiustamento evidenziato in giallo.

153

6.5.5.

Determinazione dei FP

Avendo a disposizione tutti i dati necessari, il calcolo dei FP si ottiene moltiplicando il valore conteggio_totale per il fattore di aggiustamento. Nella figura 41 il valore di FP quello evidenziato in verde e viene chiamato Adjusted Function Points (punti funzione pesati o AFP).

Figura 41 - Adjusted Function Point

154

6.5.6.

Configurazione preliminare del software

Per realizzare il piano di valutazione dello sforzo il team ha deciso di effettuare un'analisi CoCoMo (Constructive Cost Model). CoCoMo uno dei pi famosi modelli di stima per quel che riguarda l'analisi del software; il modello che il team ha deciso di utilizzare un'evoluzione del modello originario e prende il nome di CoCoMo II. L'informazione sul modello di analisi prescelto inserita preventivamente all'interno di Costar 7.0, specificando il ciclo di vita a cui si fa riferimento nel processo di sviluppo del software.

Figura 42 - Scelta del modello di analisi

La versione di Costar utilizzata non ha permesso la scelta di un ciclo di vita personalizzato; come riportato nel piano di processo, infatti, il modello di ciclo di vita scelto dal team una variante del modello a cascata (Waterfall). Tuttavia le differenze rispetto al modello Waterfall classico sono state ritenute poco rilevanti ai fini dell'analisi dello sforzo, per cui si scelto di adottare ugualmente il modello a cascata.

155

Sia CoCoMo che il suo successore basano le loro stime sulla metrica dimensionale, dal momento che di default il parametro rappresentativo della dimensione del software il numero di linee di codice previste (SLOC). Per ricavare questo parametro si pu ricorrere alla metrica funzionale; in figura 43 e 44 mostrato il calcolo di SLOC attraverso Costar 7.0. Indicando il numero di linee di codice previste per ogni FP e conoscendo il valore di questi ultimi, il programma produce la dimensione del software stimata in numero di linee di codice. La scelta del numero di linee di codice previsto per ogni FP dipende dal linguaggio utilizzato; dal momento che la fase d'implementazione sar realizzata solo parzialmente il team ha deciso di inserire un valore pari a 30 nella consapevolezza che tale valore potrebbe essere sottostimato.

Figura 43 - Scelta del numero di linee di codice previste per ogni FP

156

Figura 44 - Numero di linee di codice sorgente previste (SLOC)

Il risultato prodotto da costar 7.0 di 4959 linee di codice ed evidenziato in blu nella figura 44. Una volta ricavato il numero di linee di codice previste, necessario inserire alcuni coefficienti fondamentali alla determinazione delle stime dello sforzo, della dimensione e del costo.

157

Il primo parametro che necessario configurare in Costar 7.0 EAF. Si tratta di un fattore di scala utilizzato per il calcolo della stime dello sforzo e si ricava in seguito alla una scelta di un livello di rating. La scelta del team ricaduta su un livello di rating pari a Nominal.

Figura 45 - Cost Driver Editor

Il valore di EAF calcolato da Costar 7.0 pertanto 1.0.

158

Altrettanto importante la configurazione dei parametri necessari alla stima del costo. Per prima cosa bisogna inserire nel software il costo mensile di ciascuna delle figure impegnate nella realizzazione del sistema (il costo indicato in dollari americani).

Figura 46 - Costo mensile di ciascuna delle figure impegnate nella realizzazione del sistema

159

Quindi bisogna specificare in che percentuale ciascuna di queste figure sar impegnata in ciascuna fase dello sviluppo del sistema.

Figura 47 - Percentuale di lavoro in relazione alle fasi di sviluppo

Infine fondamentale precisare il numero di ore al mese per persona. Il valore di default preso come riferimento da CoCoMo 152 (cio 6 ore considerando la settimana lavorativa comprensiva del sabato); tale valore ritenuto compatibile con il tempo a disposizione di ciascun membro del team.

160

6.5.7.

Stime prodotte dal software

Dopo aver effettuato la configurazione preliminare del software, Costar 7.0 ha prodotto in automatico tre stime molto importanti inerenti lo sforzo, la durata e il costo.

6.5.8.

Stima dello sforzo

La formula utilizzata da CoCoMo per la valutazione dello sforzo la seguente:

Effort = K * EAF * (KSLOC)^B

dove K e B sono due coefficienti ricavati considerando tutti i cost driver e gli scale driver (eccetto SCED) al loro valore di default. I valori dei parametri da considerare sono: K = 2.94 EAF = 1.00 KSLOC = 4.659 B = 1.146

161

Di seguito riportato il report relativo allo sforzo generato in automatico da Costar 7.0.

Figura 48 - Effort Report

Dalla lettura del report si evince che lo sforzo complessivo pari a 12.6 mesi-uomo , cosi distribuito:

Fase Specifica Requisiti (RQ) Progettazione Sistema (PD) Progettazione Moduli (DD) Implementazione e Test di unit (CT) Integrazione e Test (IT)

Sforzo stimato (mesi-uomo) 0.8 2.0 3.1 4.2 2.4

162

6.5.9.

Stima della durata

La formula utilizzata da CoCoMo per la stima della durata tiene conto del valore dello sforzo precedentemente determinato:

Schedule = M * N * (Effort)^Z
dove M, N e Z sono tre coefficienti ricavati considerando tutti i cost drivers e gli scale drivers (eccetto SCED) al loro valore di default.

Figura 49 - Stima della durata in relazione alle fasi di sviluppo

Si ottiene che la durata complessiva stimata pari a circa 9 mesi, dei quali 1.4 riguarda la fase di specifica dei requisiti e i restanti 8.0 le altre fasi di sviluppo.

163

6.5.10.

Stima del costo

Il report dei costi si basa sugli input forniti durante la configurazione ed di seguito riportato:

Figura 50 - Cost Report

Il costo totale del sistema calcetto 2.0 stimato sui 17900 $, pari a circa 14065 euro. Il grafico appena mostrato presenta anche una suddivisione dei costi per fasi di sviluppo; si pu osservare come la fase pi costosa sia quella di progettazione (8300 $ , cio quasi la met del costo complessivo del sistema).

164

Capitolo 7 Bibliografia
Lucidi del corso Gestione della Qualit II Prof.ssa G. Vaglini Lucidi del corso Sistemi informativi Prof. F. Marcelloni Documentazione ISO/IEC 9126 Documentazione ISO/EIC 12207 Documentazione IEEE 829

165

Capitolo 8 Strumenti

software

utilizzati
Microsoft Office Word 2007 Costar 7.0 GanttProject Visual Paradigm Argo UML

166

Appendice A Verbali

delle

riunioni

167

Verbali di gruppo

Verbale del 19/04/2009

Generalit Oggetto: Pianificazione del progetto per l'esame di Gestione della Qualit Data: 19/04/2010 Durata: 2 ore Luogo: Facolt di Ingegneria, Aula Studio Polo B Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Definizione ed assegnamento dei ruoli Pianificazione del lavoro da svolgere Pianificazione della stesura della documentazione Stesura del verbale della presente riunione

Discussione Discussione circa l'assegnamento dei ruoli dei componenti del gruppo Sono state analizzate le specifiche del progetto Sono stati definiti gli strumenti di supporto alla stesura della presente documentazione: l'impaginazione e stata realizzata mediante Word, la definizione del diagramma di GANTT mediante GANTT Project E' stata pianificata la documentazione necessaria E' stato realizzato lo studio di fattibilit

168

Verbale del 20/04/2009

Generalit Oggetto: Pianificazione del progetto per l'esame di Gestione della Qualit Data: 20/04/2010 Durata: 2 ore Luogo: Facolt di Ingegneria, Aula Studio Polo B Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE

Ordine del giorno Revisione generale del progetto di Sistemi Informativi Analisi casi duso Stesura della documentazione; Stesura del verbale della presente riunione.

Discussione Revisione dei requisiti funzionali Revisione del diagramma dei casi d'uso Stesura del verbale della presente riunione.

169

Verbale del 21/04/2009

Generalit Oggetto: Pianificazione del progetto per l'esame di Gestione della Qualit Data: 21/04/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, Aula d'Informatica, Aula A24 Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Revisione del progetto di Sistemi Informativi. Stesura della documentazione; Stesura del verbale della presente riunione.

Discussione Revisione delle specifiche dei casi d'uso Revisione dei requisiti non funzionali Stesura del verbale della presente riunione.

170

Verbale del 26/04/2009

Generalit Oggetto: Pianificazione del progetto per l'esame di Gestione della Qualit Data: 26/04/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, ADinf Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Revisione del progetto di Sistemi Informativi. Stesura della documentazione; Stesura del verbale della presente riunione.

Discussione Revisione dei package Revisione del diagramma delle componenti Revisione dei diagrammi di sequenza Stesura del verbale della presente riunione.

171

Verbale del 28/04/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 28/04/2010 Durata: 4 ore Luogo: Facolt di Ingegneria, Aula A23 Partecipanti e ruolo: Fabio Aiuto PM

Ordine del giorno Stesura del piano di processo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione Sono state realizzate l'introduzione e la descrizione delle metodologie di processo Stesura del verbale della presente riunione

172

Verbale del 29/04/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 29/04/2010 Durata: 6 ore Luogo: Facolt di Ingegneria, Aula Studio Polo B Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Stesura del piano di processo E' stato sviluppato il diagramma di GANTT; Stesura della documentazione; Stesura del verbale della presente riunione

Discussione In sede di riunione stato deliberato di affidare lo sviluppo del piano di processo a RUP (Rational Unified Process), per cui sono state descritte le fasi di cui composto (inception, elaboration, construction e transition); Realizzazione del Diagramma di Gantt e suo inserimento nella documentazione E' stata aggiornata la relativa documentazione ed stata aggiunta al lavoro finora svolto Stesura del verbale della presente riunione

173

Verbale del 30/04/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 30/04/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, ADinf Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Stesura del piano di processo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione Conclusione della descrizione del modello RUP Stesura del piano di produzione preventivo Stesura del verbale della presente riunione

174

Verbale del 03/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 03/05/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, Aula Studio Polo B Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE

Ordine del giorno Stesura del Piano di Qualit Stesura della documentazione; Stesura del verbale della presente riunione

Discussione I membri del gruppo si sono incontrati al fine di redigere il Piano della Qualit riferendosi alla norma ISO 9126 e al materiale didattico fornito dal corso. Sono stati inoltre identificati i processi legati al ciclo di vita del sistema con riferimento alla norma ISO 12207; E' stata aggiornata la relativa documentazione ed stata aggiunta al lavoro finora svolto Stesura del verbale della presente riunione

175

Verbale del 04/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 04/05/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, ADinf Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE

Ordine del giorno Continuazione della stesura del Piano di Qualit Stesura della documentazione; Stesura del verbale della presente riunione

Discussione E stato continuato e completato il Piano di Qualit E' stata aggiornata la relativa documentazione ed stata aggiunta al lavoro finora svolto Stesura del verbale della presente riunione

176

Verbale del 05/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 05/05/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, Aula d'Informatica ADinf Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Realizzazione del Piano di Testing Stesura della documentazione; Stesura del verbale della presente riunione

Discussione Sono stati discussi gli argomenti principali al fine di redigere i paragrafi relativi al Test Design Specification e del Test Case Specification E' stato realizzato il Test Plan Pianificazione della stesura del Test Case Specification, che stata divisa fra i vari membri del gruppo per i tre giorni successivi Stesura del verbale della presente riunione

177

Verbale del 11/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 11/05/2010 Durata: 4 ore Luogo: Facolt di Ingegneria, Aula studio polo B Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Revisione, continuazione e completamento del Piano di Testing; E' stato realizzato il Test Design Specification Stesura della documentazione; Stesura del verbale della presente riunione

Discussione E' stato revisionato il Piano di Testing finora prodotto ed stato inoltre continuato ed ultimato E' stata aggiornata la relativa documentazione ed stata aggiunta al lavoro finora svolto Stesura del verbale della presente riunione

178

Verbale del 12/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 12/05/2010 Durata: 3 ore Luogo: Domicilio di Fabio Aiuto Partecipanti e ruolo: Fabio Aiuto PM Federico Bianucci L, TS

Ordine del giorno Stesura dell'Analisi dello sforzo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione E' stata iniziata l'analisi preventiva dello sforzo avvalendosi del materiale didattico del corso e con il supporto del software Costar 7.0; Stesura del verbale della presente riunione

179

Verbale del 13/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 13/05/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, ADinf Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Stesura dell'Analisi dello sforzo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione Sono stati realizzati l'analisi e calcolo dei punti funzione Stesura del verbale della presente riunione

180

Verbale del 14/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 14/05/2010 Durata: 5 ore Luogo: Facolt di Ingegneria, Aula Studio Polo B Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Stesura dell'Analisi dello sforzo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione E' stato realizzato il calcolo dei valori di conteggio per ciascun indice Inizio della valutazione dello sforzo con CoCoMo Stesura del verbale della presente riunione

181

Verbale del 17/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 17/05/2010 Durata: 4 ore Luogo: Facolt di Ingegneria, Domicilio Fabio Aiuto Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Stesura dell'Analisi dello sforzo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione Valutazione dello sforzo con CoCoMo Stesura del verbale della presente riunione

182

Verbale del 18/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 18/05/2010 Durata: 4 ore Luogo: Facolt di Ingegneria, Domicilio Fabio Aiuto Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Stesura dell'Analisi dello sforzo Stesura della documentazione; Stesura del verbale della presente riunione

Discussione E' stata conclusa la valutazione dello sforzo con CoCoMo Stesura del verbale della presente riunione

183

Verbale del 19/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 19/05/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, Aula A23 Partecipanti e ruolo: Federico Bianucci L, TS

Ordine del giorno Completamento della documentazione Stesura del verbale della presente riunione

Discussione Revisione, aggiornamento, correzione di eventuali errori della documentazione Stesura del verbale della presente riunione

184

Verbale del 20/05/2009

Generalit Oggetto: Realizzazione del progetto per l'esame di Gestione della Qualit Data: 20/05/2010 Durata: 3 ore Luogo: Facolt di Ingegneria, ADinf Partecipanti e ruolo: Fabio Aiuto PM Irene Bont QE Federico Bianucci L, TS

Ordine del giorno Completamento della documentazione e revisione generale del progetto Stesura della documentazione; Stesura del verbale della presente riunione

Discussione Revisione, aggiornamento, correzione di eventuali errori della documentazione Inserimento dei verbali E' stata condotta la revisione generale dell'intero progetto, apportando correzioni, modifiche e precisazioni Stesura del verbale della presente riunione

185

Verbali individuali

Fabio Aiuto (Project Manager)

Giorno 19/04/10 20/04/10 21/04/10 26/04/10

Attivit svolta Revisione generale del sistema Studio di fattibilit Revisione dei requisiti funzionali Revisione del diagramma dei casi d'uso Revisione delle specifiche dei casi d'uso Revisione dei requisiti non funzionali Revisione dei package Revisione del diagramma delle componenti Revisione dei diagrammi di sequenza Introduzione e metodologie del piano di sviluppo Il RUP Il RUP Piano di produzione preventivo Modello di qualit ISO 9126 Modello di qualit ISO 12207 Test Plan Test Design Specification Test Case Specification Test Case Specification Test Case Specification Test Case Specification Piano di valutazione dello sforzo Analisi e calcolo dei punti funzione Calcolo dei valori di conteggio per ciascun indice Valutazione dello sforzo con CoCoMo Valutazione dello sforzo con CoCoMo Valutazione dello sforzo con CoCoMo Giorno libero Revisione generale progetto

Sforzo (ore-uomo) 2 2 3 3

28/04/10 29/04/10 30/04/10 03/05/10 04/05/10 05/05/10 06/05/10 07/05/10 10/05/10 11/05/10 12/05/10 13/05/10 14/05/10 17/05/10 18/05/10 19/05/10 20/05/10

4 6 3 3 3 3 4 4 4 4 3 3 5 4 4 3

186

Irene Bont (Quality Engineer)

Giorno 19/04/10 20/04/10 21/04/10 26/04/10

Attivit svolta Revisione generale del sistema Studio di fattibilit Revisione dei requisiti funzionali Revisione del diagramma dei casi d'uso Revisione delle specifiche dei casi d'uso Revisione dei requisiti non funzionali Revisione dei package Revisione del diagramma delle componenti Revisione dei diagrammi di sequenza Giorno libero Il RUP Il RUP Piano di produzione preventivo Modello di qualit ISO 9126 Modello di qualit ISO 12207 Test Plan Test Design Specification Test Case Specification Test Case Specification Test Case Specification Test Case Specification Giorno libero Analisi e calcolo dei punti funzione Calcolo dei valori di conteggio per ciascun indice Valutazione dello sforzo con CoCoMo Valutazione dello sforzo con CoCoMo Valutazione dello sforzo con CoCoMo Giorno libero Completamento della documentazione

Sforzo (ore-uomo) 2 2 3 3

28/04/10 29/04/10 30/04/10 03/05/10 04/05/10 05/05/10 06/05/10 07/05/10 10/05/10 11/05/10 12/05/10 13/05/10 14/05/10 17/05/10 18/05/10 19/05/10 20/05/10

6 3 3 3 3 4 4 4 4 3 3 5 4 4 3

187

Federico Bianucci (Librarian, Tool Specialist)

Giorno 19/04/10 20/04/10 21/04/10 26/04/10

Attivit svolta Bozza del diagramma di Gantt Giorno libero Revisione delle specifiche dei casi d'uso Revisione dei requisiti non funzionali Realizzazione glossario Revisione dei package Revisione del diagramma delle componenti Revisione dei diagrammi di sequenza Giorno libero Diagramma di Gantt Il RUP Piano di produzione preventivo Giorno libero Giorno libero Test Plan Test Design Specification Test Case Specification Test Case Specification Test Case Specification Test Case Specification Piano di valutazione dello sforzo Analisi e calcolo dei punti funzione Calcolo dei valori di conteggio per ciascun indice Valutazione dello sforzo con CoCoMo Valutazione dello sforzo con CoCoMo Valutazione dello sforzo con CoCoMo Completamento della documentazione Completamento della documentazione

Sforzo (ore-uomo) 2 3 3

28/04/10 29/04/10 30/04/10 03/05/10 04/05/10 05/05/10 06/05/10 07/05/10 10/05/10 11/05/10 12/05/10 13/05/10 14/05/10 17/05/10 18/05/10 19/05/10 20/05/10

4 6 4 3 4 4 4 4 3 3 5 4 5 4 3

188