Soluzione
Versione 1.0 / 2020-04-01
Una società di servizi vuole informatizzare la vendita degli ski-pass sul territorio nazionale.
Il sistema prevede che il cliente scarichi una app sul proprio cellulare (facendolo diventare uno ski-pass virtuale) e richieda gratuitamente l’attivazione del servizio inserendo direttamente nella app i propri dati anagrafici, di residenza, bancari (IBAN o carta di credito) ed il proprio numero di cellulare. La conferma dei dati avviene tramite un codice OTP (one time password) generata automaticamente dal sistema ed inviata all’utente via SMS. L’utente deve quindi inserire il codice ricevuto via SMS all’interno della app per completare il processo di registrazione. Ad ogni smartphone è assegnato un codice univoco generato dalla app stessa, ed è associato ad ogni cliente. In caso di smarrimento o sostituzione dello smartphone, lo sciatore potrà associarne uno nuovo, ripetendo la procedura di registrazione, dove inserirà solo il suo codice fiscale (essendo l’utente già registrato) e la OTP ricevuta via SMS. È necessario salvare lo storico dei dispositivi associati.
Lo sciatore può recarsi sulle piste da sci con il proprio smartphone ed avvicinarlo al tornello di ogni impianto di risalita. Il sistema ogni volta registra il codice identificativo dei tornelli degli impianti di risalita frequentati dallo sciatore. Al termine di ogni giornata, in base all’orario del primo passaggio e dell’ultimo passaggio, il sistema addebita il costo di un abbonamento mattutino (8-12), pomeridiano (12-16) o giornaliero (8-16). Al termine della stagione (31/03), se la somma degli addebiti supera quello relativo allo ski-pass stagionale, il sistema riaccredita all’utente la differenza tra il costo dello stagionale ed i costi da lui già sostenuti.
Il rimborso della differenza rispetto alla tariffa stagionale deve essere approvata da un addetto che può verificare, per ogni cliente che ne ha diritto, tutte le transazioni effettuate. In caso di anomalie, non si effettua alcun rimborso.
L’azienda decide di affidare parte dello sviluppo ad un team specializzato basato negli Stati Uniti e parte ad un team locale basato in Europa. Si decide di utilizzare l’inglese come lingua di riferimento ed il Lead Analyst è un esperto del settore di madrelingua svedese con un livello di inglese professionale. Entrambi i team sono impegnati su molti altri progetti, ma hanno un livello di esperienza molto elevato sia nel contesto di questo tipo di applicativi sia nella programmazione ad oggetti ed hanno un costo giornaliero medio di 1000 euro. Sono richieste misure di sicurezza molto elevate per la gestione dei dati bancari degli utenti.
Nel contesto dello scenario delineato sopra, si definisca:
Prima variante che include le classi rappresentanti i concetti essenziali.
Osservazioni:
Tariffa
limita le ripetizioni, l’importo di un particolare tipo di skipass (e.s. Pomeridiano) è riportato una sola volta e non ripetuto per ogni addebitoCliente
e non al Dispositivo
, in quanto allo smarrimento di un dispositivo solitamente viene mantenuto il numeroDispositivo
(attenzione: non sul dispositivo!)stato
in Rimborso
permette di tenere traccia delle diverse fasi di un rimborso:
inizialmente è DA_VALUTARE
poi viene sottoposto all’addetto
l’addetto lo può approvare portandolo nello stato APPROVATO
successivamente verrà effettuato l’accredito diventando ACCREDITATO
,
nel caso in cui l’addetto non approvi lo stato diventa CANCELLATO
Seconda variante con dettagli maggiori che introduce alcune varianti.
Osservazioni:
Passaggio
è legato al Dispositivo
invece del cliente: sebbene corretta, questa è una soluzione più complessa che non offre alcun vantaggio specificoTornello
, qui è indicato solo il codice ma potrebbe avere più informazioni ed eventualmente essere legato ad un comprensorio (anche se questa parte non è richiesta dal testo),Giornata
rappresenta un’aggregazione di tutti i passaggi fatti in un giorno, è distinta dalla classe Addebito
Osservazioni:
Osservazioni:
Osservazioni:
Use case | Registrazione di un nuovo utente |
---|---|
Scope | App |
Level | User-goal |
Intention in context | L’utente vuole iscriversi al servizio attraverso la registrazione |
Primary actor | Cliente |
Support actor | SMS-Gateway |
Stakeholders’ interest | Società: acquisizione di nuovi clienti |
Precondition | Avere scaricato app (non è una condizione verificata dal sistema…) |
Minimum guarantees | - |
Success guarantees | Iscrizione del cliente ed inserimento nel sistema dei dati del cliente |
Trigger | - |
Main success scenario | |
1. Cliente chiede al sistema di registrarsi | |
2. Il sistema chiede i dati anagrafici | |
3. Cliente compila e conferma | |
4. Il sistema verifica i dati e richiede IBAN e numero di telefono | |
5. Cliente inserisce i dati e conferma | |
6. Il sistema genera la OTP e la invia al SMS-Gateway | |
7. L’SMS-Gateway conferma l’invio | |
8. Il sistema richiede la OTP | |
9. Cliente inserisce la OTP | |
10. Il sistema conferma l’iscrizione | |
Extensions | |
3.a.;5.a. Cliente annulla: il caso d’uso fallisce | |
4.a. I dati anagrafici errati: torna al punto 3 | |
4.b. I dati anagrafici sono di un cliente già registrato: | |
– 4.b.1. Il sistema richiede il Codice Fiscale | |
– Passa al punto 6 | |
6.a. Il numero e inesistente: torna al punto 5 | |
6.b. IBAN non valido: torna al punto 5 | |
7.a. l’SMS-Gateway segnala un errore: torna al punto 6 | |
7.b. l’SMS-Gateway non risponde in tempo utile: il caso d’uso fallisce | |
10.a. la OTP è errata: il caso d’uso fallisce |
L’SMS gateway non è inserito come support actor come visto a lezione.
Non è indicata l’app scaricata come prerequisito
Non è indicata la success guarantee: essere inserito a sistema.
Non avviene l’alternanza utente sistema nella narrativa
AW = 3 + 1 = 4
UCW= 10
UUCP = 1 + 10 = 14
Factor | Description | Weight | Rating |
---|---|---|---|
T1 | Distributed System | 2 | 4 |
T2 | Response time | 2 | 3 |
T3 | End User Efficiency | 1 | 5 |
T4 | Complex Internal Processing | 1 | 2 |
T5 | Reusable Code | 1 | 2 |
T6 | Easy to install | 0.5 | 5 |
T7 | Easy to use | 0.5 | 5 |
T8 | Cross-platform support | 2 | 3 |
T9 | Easy to change | 1 | 5 |
T10 | Concurrent | 1 | 2 |
T11 | Includes Security Features | 1 | 5 |
T12 | Provides Access for 3rd parties | 1 | 1 |
T13 | User Training Required | 1 | 0 |
TCF = 0.6 + 0.01 * 47 = 1.07
Factor | Description | Weight | Rating |
---|---|---|---|
F1 | Familiarity With The Project | 1.5 | 5 |
F2 | Application Experience | 0.5 | 0 |
F3 | Object Oriented Experience | 1 | 5 |
F4 | Lead Analyst Capability | 0.5 | 4 |
F5 | Motivation | 1 | 5 |
F6 | Stable requirements | 2 | 1 |
F7 | Part Time Workers | -1 | 5 |
F8 | Difficulty of programming language | -1 | 0 |
ECF = 1.4 - 0.03 * 9 = 1.13
UCP = 14 * 1.07 * 1.13 = 16.93
n1 = 3
n2 = 1
Ore Uomo per UCP = 14
Effort in ore uomo = 16.93 * 14 = 237
Effort in giorni uomo = 237 / 8 = 29.6
Manca l’SMS gateway come actor weight. In questo caso bisogna indicare 1 perché è una API.
Valori bassi in T3, T6, T7, T8. Trattandosi di una app mobile questi aspetti sono molto importanti e devono avere valori molto alti
Valori scambiati tra F1 e F2. La application experience è relativo alla classe di applicazioni e qui andava indicato un valore alto. Per quanto riguarda F1 doveva essere necessariamente 0 in quanto il progetto era nuovo e nessuno poteva conoscerlo.
F7 con valori bassi. Era indicato nel testo che il team di sviluppo lavorava ad altri progetti
Formule sbagliate.
Errore nel calcolare i giorni uomo a partire dalle ore uomo. È sufficiente dividere per 8.