Sistemi Informativi Aziendali - Esame del 18/2/2020

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:

• la classe Tariffa limita le ripetizioni, l’importo di un particolare tipo di skipass (e.s. Pomeridiano) è riportato una sola volta e non ripetuto per ogni addebito
• vengono registrati tutti i passaggi, poi a fine giornata si identificano il primo e l’ultimo (se presenti) per capire che tariffa addebitare. È impossibile identificare l’ultimo passaggio a priori perché il cliente ne può sempre fare uno succesivo
• il numero di cellulare è associato al Cliente e non al Dispositivo, in quanto allo smarrimento di un dispositivo solitamente viene mantenuto il numero
• l’OTP viene memorizzata, unitamente alla sua scadenza, relativamente al Dispositivo (attenzione: non sul dispositivo!)
• l’attributo 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:

• in questo caso il Passaggio è legato al Dispositivo invece del cliente: sebbene corretta, questa è una soluzione più complessa che non offre alcun vantaggio specifico
• è stata rappresentato come classe a se stante il Tornello, 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),
• la classe Giornata rappresenta un’aggregazione di tutti i passaggi fatti in un giorno, è distinta dalla classe Addebito

Diagramma BPMN

Prima soluzione:

Osservazioni:

• Dopo il primo passaggio si entra in un sottoprocesso che contiene un ciclo in cui vengono effettuati tutti i passaggi successivi della giornata, il sottoprocesso viene interrotto a fine giornata per calcolare l’addebito da effettuare per poi ri-abilitare la lettura del primo passaggio di una futura Giornata
• in assenza di un primo passaggio non viene attivata il sottoprocesso e quindi non ci sarà nessun calcolo dell’addebito
• é sufficiente un solo passaggio per poi attivare il calcolo a fine giornata
• c’è un event subprocess (sottoprocesso di gestione degli eventi) che viene attivato dall’eventi temporale di fine stagione: si calcola il rimborso dovuto e se è diverso da zero viene inviato un messaggio all’addetto
• l’addetto svolge un processo (indipendente) attivato dai messaggi generati a fine stagione dal processo di gestione dei passaggi: per ogni cliente a cui è possibilmente dovuto un rimnborso genera una nuova istanza del processo di verifica del rimborso

Seconda soluzione

Osservazioni:

• la variante principale rispetto alla soluzione precedente è che il calcolo dell’eventuale rimborso è fatto all’interno del processo dell’addetto
• si crea un processo per ogni cliente, poi nel caso in cui non sia dovuto alcun rimborso il processo viene terminato.

Terza soluzione

Osservazioni:

• questa soluzione include un unico pool
• il sottoprocesso di registazione dei passaggi tutti i giorni (anche in assenza di passaggi) genera un evento temporale (non interrupting), poi se sono stati fatti passaggi in giornata viene calcolato l’addebito
• alla fine della stagione il sottoprocesso viene interrotto per calcolare l’eventuale addebito e, se dovuto, segue un’attività a carico dell’adetto per effettuare la verifica delle anomalie ed approvare il rimborso.

Errori tipici BPMN

Narrativa del caso d’uso

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

TCF = 0.6 + 0.01 * 47 = 1.07

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.