Sistemi Informativi Aziendali - Esame del 18/2/2020

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:

  1. Il diagramma delle classi
  2. Il modello del processo (diagramma BPMN)).
  3. Il caso d’uso a livello user goal per la registrazione di un nuovo utente
  4. L’effort richiesto per sviluppare il caso d’uso di registrazione di un nuovo utente attraverso gli use case points

Diagramma delle classi

Prima variante che include le classi rappresentanti i concetti essenziali.

Osservazioni:

Seconda variante con dettagli maggiori che introduce alcune varianti.

Osservazioni:

Diagramma BPMN

Prima soluzione:

Osservazioni:

Seconda soluzione

Osservazioni:

Terza soluzione

Osservazioni:

Errori tipici BPMN

Narrativa del caso d’uso

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

Errori tipici Narrativa del caso d’uso

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

Effort estimation

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

Errori tipici Effort Estimation

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.