System Development Plan (SDP) MGT – MiGiocoTutto

Identificativo doc:
MGT_01_SDP
System Development Plan
(SDP)
Ed. 1
Rev. 3
Nome del Progetto
MGT – MiGiocoTutto
Sito web per la gestione di scommesse sportive on-line
Redazione
Verifica Cliente
Fulgenzi Alessandro
MGT_01_SDP_Ed1Rev1
data
data
05/02/2007
Firma
Firma
11/11/2008 16.42
Pag 1 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
INDICE
1.
INTRODUZIONE................................................................................................................................... 3
1.1
1.2
1.3
1.4
2.
OBIETTIVO ........................................................................................................................................ 3
IDENTIFICATIVO DEL DOCUMENTO .................................................................................................. 3
DOCUMENTI DI RIFERIMENTO........................................................................................................... 3
DEFINIZIONI ED ACRONIMI ............................................................................................................... 3
PIANIFICAZIONE GENERALE ......................................................................................................... 5
2.1
SOFTWARE ENGINEERING PROCESS (SEP) ....................................................................................... 5
2.2
PIANIFICAZIONE E CONTROLLO ........................................................................................................ 5
2.3
FLUSSI DI LAVORO ............................................................................................................................ 6
2.3.1
Requisiti ...................................................................................................................................... 6
2.3.2
Analisi......................................................................................................................................... 6
2.3.3
Progettazione.............................................................................................................................. 7
2.3.4
Implementazione......................................................................................................................... 7
2.3.5
Test.............................................................................................................................................. 8
2.4
ITERAZIONI ....................................................................................................................................... 8
2.4.1
INCEPTION - Avviare il progetto .............................................................................................. 8
2.4.2
INCEPTION - Completare e consolidare i requisiti .................................................................. 9
2.4.3
ELABORATION - Analizzare i requisiti e progettare l’architettura del sistema ....................... 9
2.4.4
ELABORATION - Completare la progettazione del sistema.................................................... 10
2.5
RIPARTIZIONE DEL LAVORO ........................................................................................................... 10
2.5.1
Personale disponibile ............................................................................................................... 10
2.5.2
Gantt ......................................................................................................................................... 10
3.
STIMA ................................................................................................................................................... 10
3.1
3.2
4.
TECNICA UTILIZZATA ..................................................................................................................... 11
STIMA QUANTITATIVA.................................................................................................................... 12
GESTIONE DEI RISCHI .................................................................................................................... 15
4.1
DISCUSSIONE GENERALE SUI RISCHI TRATTATI.............................................................................. 15
4.2
TABELLA RIEPILOGATIVA DEI RISCHI ............................................................................................. 16
4.3
RISK MITIGATION, MONITORING, MANAGEMENT (RMMM) ........................................................ 16
4.3.1
RSK_REQ_001 - Requisiti Incompleti o Mutevoli.................................................................... 17
4.3.2
RSK_REQ_002 - Requisiti Errati ............................................................................................. 18
4.3.3
RSK_PRJ_001 - Complessità Sottostimata............................................................................... 19
4.3.4
RSK_PRO_001 - Processo Immaturo....................................................................................... 20
4.3.5
RSK_PRO_002 - Documentazione Incompleta ........................................................................ 21
4.3.6
RSK_PRO_003 - Qualità Scarsa .............................................................................................. 22
4.3.7
RSK_STR_001 - Difficoltà Reperimento Strumenti .................................................................. 23
4.3.8
RSK_STR_002 - Strumenti Inadeguati ..................................................................................... 24
4.3.9
RSK_TME_001 - Ritardi Imprevisti ......................................................................................... 25
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 2 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
1. INTRODUZIONE
1.1 Obiettivo
Questo documento ha come obiettivo la descrizione generale delle modalità con cui sarà
organizzato e svolto il progetto. Sarà costantemente aggiornato nel corso del progetto poiché la sua
stesura impatta su tutte le fasi dello sviluppo.
1.2 Identificativo del documento
Il documento in oggetto è denominato (MGT_01_SDP_ed1rev3).
1.3 Documenti di riferimento
Rxx = Documenti di Riferimento
Cxx = Documenti Correlati
[R01]Glossario (MGT_01_GLO_ed1rev1).
[R02]System Requirements Specifications (MGT_01_SRS_ed1rev3).
1.4 Definizioni ed acronimi
L’acronimo utilizzato per indicare il progetto è : MGT – MiGiocoTutto
I file contenenti la documentazione avranno la seguente struttura :
MGT_<versione_progetto>_<tipo_documento>_<versione_documento>
Per quanto riguarda <tipo_documento> fare riferimento alla seguente tabella :
Acronimo
SDP
SRS
SA
SD
GLO
Tipologia
System Development Plan
System Requirements Specifications
System Analysis
System Design
Glossario
Descrizione
Piano per la gestione del progetto
Documento di specifica dei requisiti
Artefatto del flusso di Analisi
Artefatto del flusso di Progettazione
Glossario del progetto
Tabella 1.1 – Tipologie di documento
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 3 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
<versione_progetto> : è uguale a “01”
<versione_documento> indica la versione e revisione del documento (es. Ed1Rev0 corrisponde a
Edizione 1 Revisione 0).
Per quanto non specificato, fare riferimento al documento [R01].
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 4 di 25
Identificativo doc:
System Development Plan
(SDP)
2.
MGT_01_SDP
Ed. 1
Rev. 3
PIANIFICAZIONE GENERALE
2.1 Software engineering process (SEP)
L’SDP (Software Development Process) adottato per lo sviluppo del progetto è lo Unified Process
(UP, o USDP – Unified Software Development Process).
Tale processo è composto da quattro fasi :
Fase
Inception
Elaboration
Construction
Transition
Descrizione
Avvio del progetto e pianificazione
Analisi e progettazione del sistema
Implementazione del software
Test, integrazione e rilascio
Tabella 2.1 - Fasi dello Unified Process
Le fasi rappresentano l’andamento temporale del progetto ed all’interno di ogni fase vengono svolte
una serie di attività note come flussi di lavoro.
I flussi di lavoro previsti dall’UP consistono nelle consuete attività relative all’ingegneria del
software :
Flusso di lavoro
Requisiti
Analisi
Progettazione
Implementazione
Test
Descrizione
Stabilire cosa deve fare il progetto
Raffinare i requisiti e dare loro una struttura
Concretizzare i requisiti e fissare l’architettura del sistema
Sviluppare il software
Verificare che l’implementazione rispetti i requisiti
Tabella 2.2 – Flussi di lavoro dello Unified Process
Il processo è iterativo ed incrementale, pertanto all’interno di ogni fase è possibile che si cicli più
volte. Ogni iterazione può comprendere anche tutti i flussi di lavoro, ma in realtà il ciclo di vita
prevede che in ogni momento vengano enfatizzati soltanto uno o due di essi.
Oltre ai convenzionali flussi di lavoro, ne esiste uno che prevede un’unica iterazione la cui durata
coincide con quella del progetto, ovvero quello di pianificazione e controllo.
2.2 Pianificazione e controllo
OBIETTIVO: redigere il piano per lo sviluppo e la gestione del progetto
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 5 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
RESPONSABILITÀ: project manager
INPUT: documento dei requisiti
ATTIVITÀ:
1. Chiarimenti sui requisiti
2. Identificazione del ciclo di vita usato nel progetto
3. Stima di costi e tempi
4. Monitoraggio dell’andamento del progetto
5. Traccia dei progressi
6. Analisi dei rischi
7. Gestione delle risorse richieste dal progetto
OUTPUT: questo documento (SDP – System Development Plan)
2.3 Flussi di lavoro
Segue la descrizione dei flussi di lavoro, previsti dall’UP, applicati a questo progetto.
2.3.1 Requisiti
OBIETTIVO: chiarire i requisiti e fornirgli una struttura
RESPONSABILITÀ: Project manager, Analista di sistema, Esperto di dominio
INPUT: documento dei requisiti (arricchito dal PM)
ATTIVITÀ:
1. Ristrutturare i requisiti
2. Formalizzare i requisiti in una bozza dell’SRS
3. Sottoporre l’SRS all’approvazione del cliente
OUTPUT: SRS (System Requirements Specifications) approvato dal cliente
2.3.2 Analisi
OBIETTIVO: chiarire i requisiti e fornirgli una struttura
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 6 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
RESPONSABILITÀ: Analista di sistema, Analista software, Analista di business
INPUT: SRS approvato
ATTIVITÀ:
1. Individuare attori e casi d’uso
2. Modellare i casi d’uso
3. Individuare le classi di analisi
4. Modellare le classi di analisi
5. Suddividere le classi in package
6. Individuare le principali attività che saranno realizzate
7. Realizzare il diagramma delle attività
OUTPUT: SA (System Analysis)
2.3.3 Progettazione
OBIETTIVO: concretizzare i requisiti e fissare l’architettura del sistema
RESPONSABILITÀ: Progettista software
INPUT: SA (System Analysis)
ATTIVITÀ:
1. Concretizzare le classi di analisi in classi di progettazione
2. Raffinare le relazioni tra classi
3. Realizzare il diagramma delle classi (di progettazione)
4. Modellare il diagramma di realizzazione dei casi d’uso
5. Individuare e modellare le interfacce ed i sottosistemi
6. Realizzare i diagrammi di stato
OUTPUT: SD (System design)
2.3.4 Implementazione
OBIETTIVO: sviluppare il software
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 7 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
RESPONSABILITÀ: Team di sviluppo
INPUT: SD (System Design)
ATTIVITÀ:
1. Realizzare il software
OUTPUT: codice sorgente
2.3.5 Test
OBIETTIVO: verificare che il software corrisponda a quanto specificato nei requisiti
RESPONSABILITÀ: Testing Team
INPUT: codice sorgente
ATTIVITÀ:
1. Verificare il funzionamento dei singoli moduli (test unitario)
2. Verificare il funzionamento dell’intero sistema sfruttanto l’interazione fra i moduli (test di
integrazione)
OUTPUT: documentazione che evidenzi l’esito dei test
2.4 Iterazioni
Questa sezione descrive la pianificazione delle iterazioni previste per il progetto. In base allo
svolgimento di ogni iterazione, la pianificazione delle iterazioni successive potrà subire variazioni.
Pertanto questa sezione subirà delle revisioni nel corso dello svolgimento del progetto.
2.4.1 INCEPTION - Avviare il progetto
ITERAZIONE N° : 1
FASE: INCEPTION
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 8 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
OBIETTIVO: avviare il progetto
MILESTONE:
• definizione del modello di documentazione
• produzione dell’SRS iniziale da sottoporre a validazione del cliente
• prima pianificazione del progetto (SDP)
• bozza di analisi del sistema (diagramma delle classi completo al 10%)
2.4.2 INCEPTION - Completare e consolidare i requisiti
ITERAZIONE N° : 2
FASE: INCEPTION
OBIETTIVO: completare e consolidare i requisiti
MILESTONE:
• stesura ed approvazione dell’SRS completa
• matrice di tracciabilità Requisiti/Casi d’uso
• pianificazione dettagliata del progetto (SDP)
• documento di stima del progetto
• analisi dei rischi e piano di mitigazione/gestione
• analisi (realizzazione di casi d’uso, diagrammi di interazione e di attività) del caso d’uso
UC_01 (Gestione account personale)
• diagramma delle classi completo al 30%
2.4.3 ELABORATION - Analizzare i requisiti e progettare l’architettura del sistema
ITERAZIONE N° : 3
FASE: ELABORATION
OBIETTIVO: analizzare i requisiti e progettare l’architettura del sistema
MILESTONE:
• Analisi e progettazione (realizzazione di casi d’uso, diagrammi di interazione, di attività) dei
casi d’uso UC_06 (Gestione bookmaker), UC_08 (Gestione amministratori), UC_05
(Gestione eventi)
• Diagramma delle classi completo all’80%
• Prototipi di interfaccia per i casi d’uso realizzati in questa e nella precedente iterazione
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 9 di 25
Identificativo doc:
System Development Plan
(SDP)
•
MGT_01_SDP
Ed. 1
Rev. 3
Monitoring dei rischi trattati e revisione delle priorità
2.4.4 ELABORATION - Completare la progettazione del sistema
ITERAZIONE N° : 4
FASE: ELABORATION
OBIETTIVO: completare la progettazione del sistema
MILESTONE:
• Analisi e progettazione (realizzazione di casi d’uso, diagrammi di interazione, di attività e di
stato) dei restanti casi d’uso : UC_02 (Consultazione storico eventi), UC_03 (Gestione
portafoglio), UC_04 (Gestione scommesse)
• Diagramma delle classi completo al 100%
• Prototipi di interfaccia per tutti i casi d’uso
• Diagramma di Deployment
2.5 Ripartizione del lavoro
2.5.1 Personale disponibile
2.5.2 Gantt
3. STIMA
Questo paragrafo si occupa di descrivere la metodologia e la realizzazione di una stima quantitativa
per il progetto, sia in termini economici che di quantità di lavoro.
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 10 di 25
Identificativo doc:
MGT_01_SDP
System Development Plan
(SDP)
Ed. 1
Rev. 3
3.1 Tecnica utilizzata
Per quanto riguarda la stima, relativa alle dimensioni del progetto ed alla valutazione economica
dello stesso è stata utilizzata la metodologia delle Function Point.
Tale tecnica prevede l’individuazione di un certo numero di caratteristiche del progetto, raggruppate
per categoria :
Categoria
Input utente
Output utente
Descrizione
Ogni dato immesso dall’utente
Ogni output del sistema che fornisce dati applicativi (report,
schermate, messaggi di errore, ecc) contenenti dati calcolati..
Interrogazioni utente Input in linea fornito dall’utente che genera una risposta in
linea senza che siano effettuati calcoli o prodotti documenti. La
differenza con gli output è che questi contengono dati calcolati
e/o producono report
File
A questo concetto è stata associata in linea di massima una
tabella in base dati. O meglio un concetto ad alto livello del
dominio a cui sarà associata una tabella (eventualmente più di
una per necessità implementative, es. Scommessa)
Interfacce esterne
Numero di interfacce del sistema con sistemi esterni (es.
compagnia di gestione credito)
Tabella 3.1 – Categorie per la stima con Function Point
Per ogni categoria vengono conteggiate le caratteristiche che vi appartengono. Al termine del
conteggio viene associato ad ogni categoria un indice di complessità, come in figura 2.1.
Fattore di peso
Parametro di misurazione
Conteggio
Semplice
Medio
Complesso
Input utente
X
3
4
6
=
Output utente
X
4
5
7
=
Interrogazioni utente
X
3
4
6
=
File
X
7
10
15
=
Interfacce esterne
X
5
7
10
=
Totale
Figura 2.1 – Calcolo dei punti funzione (adattato da Pressman, 1997)
Per calcolare i punti funzione(FP), si utilizza la relazione seguente:
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 11 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
FP = totale x [0,65 + (0,01 x G Fi)]
Dove “totale” è il corrispondente valore della figura 2.1, mentre gli Fi sono “valori di aggiustamento
della complessità”, basati sulle risposte alle domande della tabella 3.2. Le costanti della precedente
equazione ed i pesi applicati ai conteggi del dominio sono determinati empiricamente.
I fattori (Fi) che seguono dovranno essere valutati su una scala da 0 a 5 :
0
Nessuna
influenza
Fi
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
1
Incidentale
2
Moderata
3
Media
4
Significativa
5
Essenziale
Il sistema richiede salvataggi e recuperi affidabili?
Si richiedono comunicazioni di dati?
Ci sono funzioni di elaborazione distribuita?
Le prestazioni sono un fattore critico?
Il sistema funzionerà in un ambiente operativo esistente, utilizzato a fondo?
Il sistema richiede inserimenti di dati in linea?
L’inserimento di dati in linea richiede che la transazione si articoli in più schermi o più
operazioni?
I file principali sono aggiornati in linea?
I dati d’ingresso o di uscita, i file e le interrogazioni sono complessi?
L’elaborazione interna è complessa?
Il codice è stato progettato per essere riusabile?
La progettazione comprende anche conversione e installazione?
Il sistema è stato progettato per essere installato in più organizzazioni?
L’applicazione è stata progettata per facilitare le modifiche e per essere di semplice uso da parte
dell’utente finale?
Tabella 3.2 - Valori di aggiustamento della complessità
3.2 Stima quantitativa
Segue il dettaglio della stima effettuata in base ai criteri precedentemente elencati.
Input utente
Dati iscrizione utente, dati portafoglio, dati scommesse, dati nuovi eventi, dati nuovi esiti, dati
nuovi bookmaker, dati amministratori.
Totale elementi : 7
Complessità : media
Output utente
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 12 di 25
Identificativo doc:
MGT_01_SDP
System Development Plan
(SDP)
Ed. 1
Rev. 3
Stampa scommessa, calcolo vincita, visualizzazione statistiche evento
Totale elementi : 3
Complessità : semplice
Interrogazioni
Vis. Propri dati (anagrafici + portafoglio), lista eventi, storico evento, lista scommesse in corso,
storico scommesse effettuate, lista bookmaker, lista amministratori,
Totale elementi : 8
Complessità : media
File
Anagrafica, eventi, scommesse, portafoglio, esiti, vincite
Totale elementi : 6
Complessità : media
Interfacce
Compagnia di gestione credito
Totale elementi : 1
Complessità : media
Calcolo del totale :
Fattore di peso
Parametro di misurazione
Conteggio
Semplice
Medio
Complesso
Input utente
7
X
3
4
6
=
28
Output utente
3
X
4
5
7
=
12
Interrogazioni utente
8
X
3
4
6
=
32
File
6
X
7
10
15
=
60
Interfacce esterne
1
X
5
7
10
=
7
Totale
139
Figura 2.2 – Calcolo dei punti funzione (adattato da Pressman, 1997)
Determinazione dei valori di aggiustamento della complessita
Fi
1
Domanda
Il sistema richiede salvataggi e recuperi affidabili?
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Peso
5
Pag 13 di 25
Identificativo doc:
System Development Plan
(SDP)
2
3
4
5
6
7
8
9
10
11
12
13
14
MGT_01_SDP
Ed. 1
Si richiedono comunicazioni di dati?
Ci sono funzioni di elaborazione distribuita?
Le prestazioni sono un fattore critico?
Il sistema funzionerà in un ambiente operativo esistente,
utilizzato a fondo?
Il sistema richiede inserimenti di dati in linea?
L’inserimento di dati in linea richiede che la transazione si
articoli in più schermi o più operazioni?
I file principali sono aggiornati in linea?
I dati d’ingresso o di uscita, i file e le interrogazioni sono
complessi?
L’elaborazione interna è complessa?
Il codice è stato progettato per essere riusabile?
La progettazione comprende anche conversione e
installazione?
Il sistema è stato progettato per essere installato in più
organizzazioni?
L’applicazione è stata progettata per facilitare le modifiche e
per essere di semplice uso da parte dell’utente finale?
Totale
Tabella 3.3 - Valori di aggiustamento della complessità
Rev. 3
4
0
1
2
4
4
4
3
2
4
3
4
5
45
Calcolo dei punti funzione(FP) :
FP = 139 x [0,65 + (0,01 x 45)]
= 139 x 1.1
= 152.9
Tempi
Stimando una capacità aziendale di 6.5 FP/mese (ipotetica)
Si perviene ad una durata stimata di :
152.9 / 6.5 = 23.5 mesi uomo (durata complessiva stimata)
Costi
Ipotizzando un costo aziendale medio di 3000 €/mese per ogni risorsa
Si ottiene un costo stimato di :
21.5 x 3000 = 70500 € (costo complessivo stimato)
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 14 di 25
Identificativo doc:
MGT_01_SDP
System Development Plan
(SDP)
Ed. 1
Rev. 3
4. GESTIONE DEI RISCHI
Questo paragrafo si occupa di descrivere quali rischi saranno trattati e come questo sarà fatto.
4.1 Discussione generale sui rischi trattati
La gestione dei rischi è un’attività propedeutica alla buona riuscita di un progetto. Durante il suo
svolgimento è possibile che ci troviamo di fronte a problemi di varia natura, che potrebbero metterci
in difficoltà in merito al rispetto dei requisiti, dei tempi o dei costi.
Se c’è stata una buona valutazione dei rischi ed un piano per affrontarli, saremo pronti ad attuare le
strategie necessarie per farvi fronte e ridurre al minimo le eventuali perdite che potrebbero causare.
I rischi che si possono presentare nello sviluppo di un sistema software possono essere di varia
natura :
-
-
-
relativi al Prodotto
• requisiti
• progetto
• fattori di qualità
relativi all’ambiente di sviluppo
• processo di sviluppo
• strumenti e macchinari
• management
• ambiente di lavoro
relativi ai vincoli o a fattori esterni al progetto
• costi
• tempi
• licenze
• stakeholders
In merito all’attuale progetto, saranno prese in considerazione le categorie di rischi riportate nella
tabella 4.1
Categoria
Prodotto
Prodotto
Ambiente
Ambiente
Vincoli
MGT_01_SDP_Ed1Rev1
Sottocategoria
Requisiti
Progetto
Processo
Strumenti di sviluppo
Tempi
Tabella 4.1 – Categorie di rischio
Acronimo
REQ
PRJ
PRO
STR
TME
11/11/2008 16.42
Pag 15 di 25
Identificativo doc:
MGT_01_SDP
System Development Plan
(SDP)
Ed. 1
Rev. 3
In base alla categorizzazione della tabella 4.1, l’identificativo di un rischio sarà così composto :
RSK_XXX_<progressivo a tre cifre>
Dove XXX corrisponde all’acronimo della tabella 4.1
4.2 Tabella riepilogativa dei rischi
Segue la lista dei rischi identificati :
ID
RSK_REQ_002
RSK_TME_001
RSK_STR_002
RSK_REQ_001
RSK_PRJ_001
RSK_PRO_001
RSK_PRO_002
RSK_STR_001
RSK_PRO_003
Name
Requisiti errati
Ritardi imprevisti
Strumenti inadeguati
Requisiti incompleti o mutevoli
Complessità sottostimata
Processo immaturo
Documentazione incompleta
Difficoltà reperimento strumenti
Qualità scarsa
Priority*
1
1
1
2
2
2
2
2
3
Probability (%)
20
70
70
30
30
60
50
50
40
Impact**
1
2
2
2
3
2
3
2
4
Tabella 4.2 – Tabella dei rischi identificati
* La priority assume uno dei seguenti valori : hi(1), medium(2), low(3)
* L’impact assume uno dei seguenti valori : catastrofic(1), critical(2) , marginal(3), negligible(4)
La precedente tabella sarà modificata durante tutto il corso del progetto in base ai risultati del
monitoraggio.
4.3 Risk Mitigation, Monitoring, Management (RMMM)
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 16 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.1 RSK_REQ_001 - Requisiti Incompleti o Mutevoli
ID : RSK_REQ_001
TITLE : REQUISITI INCOMPLETI O MUTEVOLI
PRIORITY : MEDIUM
DESCRIPTION :
C’è la possibilità che i requisiti varino durante il progetto
PROBABILITY : 30%
IMPACT : CRITICAL
MITIGATION :
- durante la fase di racocolta ed analisi dei requisiti, approfondire il più possibile i vari aspetti del progetto
- portare il cliente a sviscerare ogni aspetto del problema che per lui potrebbe sembrare scontato
MONITORING :
Richiedere costanti feedback al cliente per accerttarsi di non aver dimenticato niente (o meglio che il cliente non abbia
dimenticato niente).
MANAGEMENT :
Introdurre tempestivamente i nuovi requisiti facendo però attenzione a non stravolgere il piano (causando ritardi ed
insoddisfazione del cliente).
Informare il cliente che i nuovi requisiti comporteranno un ritardo o un aumento di costo del sistema.
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 17 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.2 RSK_REQ_002 - Requisiti Errati
ID : RSK_REQ_002
TITLE : REQUISITI ERRATI
PRIORITY : HI
DESCRIPTION :
I requisiti individuati sono errati per una o più delle seguenti cause :
- non si è compreso bene ciò che l’utente ha chiesto
- l’utente si è espresso in maniera errata
- l’utente non aveva ben chiaro di cosa avesse bisogno
PROBABILITY : 20%
IMPACT : CATASTROFIC
MITIGATION :
Durante la fase di raccolta ed analisi dei requisiti, assicurarsi di svolgere le seguenti attività :
- evitare ambiguità in ciò che il cliente espone
- assicurarsi di aver capito esattamente le sue parole
- portare il cliente a riflettere sulle proprie richieste per approfondire le sue idee ed evitare che ci siano requisiti dati per
scontato ma non espressamente dichiarati
- fornire al cliente la specifica dettagliata dei requisiti e farlo rendere conto che il sistema conterrà tutto e solo quanto
espressamente dichiarato
MONITORING :
Richiedere costanti feedback al cliente per accerttarsi di non aver dimenticato niente (o meglio che il cliente non abbia
dimenticato niente).
MANAGEMENT :
Introdurre tempestivamente i nuovi requisiti facendo però attenzione a non stravolgere il piano (causando ritardi ed
insoddisfazione del cliente).
Informare il cliente che i nuovi requisiti comporteranno un ritardo o un aumento di costo del sistema.
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 18 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.3 RSK_PRJ_001 - Complessità Sottostimata
ID : RSK_PRO_001
TITLE : COMPLESSITÀ SOTTOSTIMATA
PRIORITY : MEDIUM
DESCRIPTION :
Il sistema potrebbe essere più complesso del previsto.
Questo può verificarsi a causa di una racolta ed analisi dei requisiti superficiale, che
porta inevitabilmente ad azioni correttive in corso d’opera
PROBABILITY : 30%
IMPACT : CRITICAL
MITIGATION :
Approfondire ogni aspetto (sia di business che tecnico) con il cliente per metterlo al corrente delle eventuali difficoltà
che potrebbero essere incontrate.
In questo modo il cliente sarà più clemente in caso di ritardi causati dai suddetti problemi
Fissare dei tempi di contingency e costi aggiuntivi (per l’intervento di altre risorse) per gestire aspetti del sistema che
non erano stati previsti
MONITORING :
Rivedere periodicamente l’intero progetto man mano che prende corpo per valutare eventuali punti oscuri, trattati
parzialmente, dietro i quali potrebbero nascondersi difficoltà impreviste.
MANAGEMENT :
Sfruttare i tempi di contingency ed eventualmente personale aggiuntivo per gestire l’evento imprevisto
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 19 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.4 RSK_PRO_001 - Processo Immaturo
ID : RSK_PRO_001
TITLE : PROCESSO IMMATURO
PRIORITY :
DESCRIPTION :
PROBABILITY :
IMPACT :
MITIGATION :
MONITORING :
MANAGEMENT :
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 20 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.5 RSK_PRO_002 - Documentazione Incompleta
ID : RSK_PRO_002
TITLE : DOCUMENTAZIONE INCOMPLETA
PRIORITY : MEDIUM
DESCRIPTION :
Poiché la struttura stessa della documentazione è di recente definizione, c’è la
possibilità che presenti delle lacune.
PROBABILITY : 50%
IMPACT : MARGINAL
MITIGATION :
In base alla propria esperienza, cercare un modello di documentazione che ricopra tutti gli aspetti che dovremo
affrontare. Se possibile, acquisire un modello che sia stato precedentemente sfruttato per scopi simili
MONITORING :
Rivedere frequentemente la documentazione per verificare che copra tutti gli aspetti del progetto di cui abbiamo
bisogno
MANAGEMENT :
Aggiungere le parti mancanti (se assolutamente necessarie), oppure rimandare tale revisione ad una versione successiva
del progetto
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 21 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.6 RSK_PRO_003 - Qualità Scarsa
ID : RSK_PRO_003
TITLE : QUALITÀ SCARSA
PRIORITY : LOW
DESCRIPTION :
La documentazione, in quanto aggregazione di modelli diversi o definizione ex novo,
potrebbe presentare pecche qualitative rispetto ai modelli previsti per rispettare le
direttive di Quality Assurance.
PROBABILITY : 40%
IMPACT : NEGLIGIBLE
MITIGATION :
Verificare che il modello di documentazione prodotta rispetti le linee guida per la Qualità Assurance che si intende
adottare (ISO, CMM, CMMI)
MONITORING :
Confrontare periodicamente il modello di documentazione copra gli aspetti previsti dal Sistema di Qualità
MANAGEMENT :
Aggiornare il modello di documentazione per renderlo conforme al sistema di qualità
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 22 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.7 RSK_STR_001 - Difficoltà Reperimento Strumenti
ID : RSK_STR_001
TITLE : DIFFICOLTÀ REPERIMENTO STRUMENTI
PRIORITY : MEDIUM
DESCRIPTION :
Nel corso del progetto si avrà bisogno di diversi tipi di strumenti (definizione modelli,
editor, ecc).
Non tutti sono di facile reperimento e potrebbe essere necessario spendere molto per
acquistare le relative licenze.
PROBABILITY : 50%
IMPACT : CRITICAL
MITIGATION :
Effettuare approfondite ricerche di mercato per reperire prodotti efficaci con licenze free o a basso costo.
Valutare l’acquisizione di prodotti in “valutazione” la cui scadenza sia successiva al termine del progetto
MONITORING :
Verificare che le licenze non siano soggette a scadenza entro i termini di consegna del progetto.
MANAGEMENT :
Procurarsi, se possibile, strumenti con licenza free per non incidere sui costi di progetto. Tali strumenti dovranno essere
il più possibile simili a quelli già utilizzati per evitare sessioni di addestramento del personale.
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 23 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.8 RSK_STR_002 - Strumenti Inadeguati
ID : RSK_STR_002
TITLE : STRUMENTI INADEGUATI
PRIORITY : LOW
DESCRIPTION :
Lavorare con gli strumenti giusti è fondamentale.
In caso contrario si avranno problemi in fase di sviluppo, si andrà incontro a ritardi e
potrebbe essere necessario affrontare spese impreviste per far fronte ad improvvise
necessità
PROBABILITY : 10%
IMPACT : MARGINAL
MITIGATION :
Accertarsi in anticipo che il personale conosca gli strumenti che si intende adottare per lo sviluppo
Accertarsi che gli stessi strumenti siano già stati utilizzati con successo da altri per i nostri stessi scopi
Creare una lista di strumenti di riserva analoghi a quelli scelti per eventuali sostutizioni in corso d’opera
MONITORING :
Verificare periodicamente che non ci siano artefatti richiesti dal sistema che non siano realizzabili con gli strumenti a
disposizione
MANAGEMENT :
Verificare la possibilità di non produrre il documento richiesto senza incidere sul buon esito del progetto.
In caso contrario, ricercare, nella lista di strumenti alternativi precedentemente stilata, uno strumento che consenta la
produzione della documentazione necessario. Nel caso in cui tale strumento non sia gratuito, sottrarre il suo costo dal
budget disponibile.
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 24 di 25
Identificativo doc:
System Development Plan
(SDP)
MGT_01_SDP
Ed. 1
Rev. 3
4.3.9 RSK_TME_001 - Ritardi Imprevisti
ID : RSK:TME_001
TITLE : RITARDI IMPREVISTI
PRIORITY : HI
DESCRIPTION :
Il tempo stimato a disposizione potrebbe non essere realistico.
Impegni imprevisti (lavorativi/familiari) potrebbero causare un ritardo del progetto
PROBABILITY : 70%
IMPACT : CRITICAL
MITIGATION :
Fissare scadenze più stringenti di quelle stimate per il progetto (stabilire un tempo di contingency), in modo da
rispettare i tempi anche in caso di ritardi imprevisti.
Effettuare uno sforzo maggiore nei momenti in cui si ha più tempo disponibile
MONITORING :
Verificare periodicamente di essere sempre in anticipo sulla tabella di marcia
MANAGEMENT :
Nel caso in cui si rischi di non rispettare i tempi di un’iterazione, cercare eventuali attività da spostare alle iterazioni
successive e ripianificare le stesse (con tempi più stringenti ma pur sempre realistici) per rientrare nei tempi previsti
MGT_01_SDP_Ed1Rev1
11/11/2008 16.42
Pag 25 di 25