PM_DomoticApp

Indice

Documentazione di progetto

Analisi dello stato

AS IS

TO BE

NICE TO HAVE

Condictions of Satisfaction (COS)

Condizione Obiettivo
Protocollo univoco per tutti i dispositivi Tutti i dispositivi devono poter essere registrati sull’applicativo, senza perdere le proprie funzionalità
Restare nel budget €2 M
Feedback dagli utenti Positivi o suggerimenti per nuove aggiunte
UX e UI Interfaccia grafica accessibile per chiunque, semplice ed intuitiva
Modularità Il sistema deve poter essere espandibile facilmente per possibili aggiunte di nuove funzionalità
Vecchi applicativi non scompaiono L’applicativo non deve essere un sostituto per i vecchi applicativi quanto più un supporto
Alte performance L’applicativo deve poter rispondere velocemente agli utenti, se installato sul dispositivo aziendale tempo di risposta < 100 ms
Comunicazione di guasti Se si presenta un errore, non lo si deve mascherare ma si deve avvisare l’utente
Aggiornamento applicativo autonomo L’applicativo deve poter essere aggiornato dall’utente senza un nuovo intervento dell’azienda
Gestione dei permessi efficace Gli utenti devono essere soddisfatti della gestione dei permessi dell’applicativo

Project Overview Statement (POS)

Problema / Opportunità Molteplici applicativi diversi per la gestione di molteplici dispositivi diversi e completa assenza di cooperazione/competizione tra i vari dispositivi
Goal Creare un applicativo che riesca a gestire l'insieme di dispositivi eterogenei in modo facile ed intuibile, portando anche cooperazione e/o competizione tra di loro
Obbiettivi
  • Creazione di un protocollo che permetta la descrizione formale di dispositivi IoT eterogenei.
  • Implementazione di un linguaggio di scripting a blocchi per la programmazione di script che permettono la cooperazione e competizione dei dispositivi presenti nel sistema.
  • Implementazione di un sistema software che permetta la gestione di molteplici dispositivi IoT eterogenei, degli utenti, dei loro permessi e degli script.
  • Sviluppo di un'interfaccia utente semplice ed intuitiva, che sia simile in ogni pagina così che gli utenti possano imparare rapidamente ad usare l'applicativo.
  • Fornire la possibilità di essere notificati di un dispositivo che va offline/online o quando uno script da errore.
Criteri di successo
  • Tutti i dispositivi aziendali devono poter essere utilizzati attraverso l'applicativo e senza perdita di funzionalità.
  • Gli utenti imparano ad utilizzare l'applicativo in circa 3/4 giorni, massimo 7.
  • Almeno il 70% degli utenti che possiedono 4 o più dispositivi IoT utilizzano l'applicativo insieme ai vecchi applicativi.
  • Soddisfazione pari o superiore all'80% nelle recensioni.
  • Aumento del guadagno annuale di almeno 15% entro 2 anni dalla fine del progetto.
Assunzioni
  • Gli utenti admin del sistema sono mediamente esperti di tecnologia: sanno usare uno smartphone e navigare su internet.
Ostacoli
  • Gli utenti potrebbero volere funzionalità avanzate o specifiche per certi dispositivi che vanno oltre lo scopo del progetto.

Analisi dei Rischi

Rischi tecnici

ID Rischio Triangolo dello scope Impatto Probabilità Mitigazione
#001 Basse performance Qualità Alto Bassa Mitigare
#002 Tempo per creare il protocollo troppo lungo Tempo Medio Media Piano di contingenza
#003 Difficoltà nell’integrazione dei vari sottosistemi Scope Alto Bassa Mitigare
#004 Difficoltà nel creare un linguaggio di script adatto Scope Alto Media Piano di contingenza
#005 Gestione dei permessi utenti complessa Scope Basso Bassa Accettare
#006 Uso di librerie su cui non si è formati Scope Medio Bassa Mitigare
#007 UX e UI non efficaci Qualità Alto Media Piano di contingenza
#008 Sistema non modulare Scope Medio Alta Evitare

Rischi di gestione progetto

ID Rischio Triangolo dello scope Impatto Probabilità Mitigazione
#009 Scarsa cura nell’allocazione delle risorse Risorse Alto Media Evitare

Rischi di organizzazione

ID Rischio Triangolo dello scope Impatto Probabilità Mitigazione
#010 Non disponibilità di dispositivi da testare Risorse Alto Bassa Evitare
#011 Budget non sufficiente Costo Alto Media Evitare
#012 Errata assegnazione delle priorità ai vari sottosistemi Risorse Alto Media Evitare

Piani di contingenza

ID Rischio Piano di contingenza
#002 Si può lavorare al protocollo mentre altri lavorano ad altre parti, perciò si può nel caso aumentare il tempo a disposizione per lavorare al protocollo finchè gli altri lavorano al resto del sistema
#004 Si può discutere del linguaggio insieme ad altri sviluppatori o architetti per cercare di trovare una soluzione, ispirandosi anche ad altri linguaggi a blocchi conosciuti
#007 Utilizzo di prototipi intermedi da far valutare agli utenti in modo da ricevere feedback e tornare sulla giusta strada

Requirements Breakdown Structure (RBS)

Goal -> R1: Devices Protocol Goal -> R2: Scripts management subsystem Goal -> R3: Presentation subsystem Goal -> R4: Devices management subsystem Goal -> R5: Devices registration subsystem Goal -> R6: Users management subsystem Goal -> R7: Permissions management subsystem Goal -> R8: Notifications management susbystem

User Stories

Da Voglio poter Così che
Utente Creare una task con istruzioni di tutti i tipi anche se non ho i permessi su certi dispositivi Qualcuno diverso da me potrà eseguirla oppure darmi i permessi per farlo io stesso
Utente Creare un’automazione senza le istruzioni che eseguono le azioni sui dispositivi su cui non ho i permessi Non possa eseguire azioni sui dispositivi che l’admin non vuole farmi usare
Admin Gestire i permessi utente-dispositivo Gli utenti possano eseguire azioni solamente sui dispositivi che voglio
Admin Gestire una whitelist ed una blacklist per ogni task A prescindere dai permessi utente-dispositivo un utente possa eseguire o non eseguire la task
Admin Gestire una editlist per una task o una automazione Possa decidere quali utenti possono modificare tale task o automazione (per un’automazione controllo anche chi può attivarla/disattivarla)
Admin Eliminare un gruppo di dispositivi senza eliminare i dispositivi dal server Possa continuare ad usarli ma senza quel gruppo specifico
Utente Aggiungere un’istruzione ad uno script che invii una notifica con un messaggio personalizzato a qualcuno nello specifico Possa decidere a chi inviare un messaggio personalizzato in modo automatico
Utente Aggiungere un’istruzione ad uno script che blocchi lo script per una quantità di tempo specificata Possa interrompere il flusso di controllo dello script per un tot di tempo
Utente Aggiungere un’istruzione ad uno script che faccia partire un’altra task Il mio script attuale si fermi fino alla fine dell’esecuzione della task avviata
Utente Aggiungere un’istruzione ad uno script che crea una costante tipizzata con un valore specifico Possa utilizzare tale valore in seguito dentro lo stesso script
Utente Aggiungere un’istruzione ad uno script che quando eseguito legga il valore di una proprietà specifica di un particolare dispositivo Tale valore venga messo dentro una costante da utilizzare in seguito dentro lo stesso script
Utente Aggiungere un’istruzione ad uno script che esegue un’azione su un certo dispositivo Possa eseguire azioni in modo pre-programmato e/o automatico
Utente Aggiungere un’istruzione di If che confronta due valori dello stesso tipo tra di loro Possa eseguire delle istruzioni solo nel caso in cui la condizione torni vero
Utente Aggiungere un’istruzione di If-Else che confronta due valori dello stesso tipo tra di loro Possa eseguire certe istruzioni nel caso in cui la condizione sia vera e altre istruzioni altrimenti
Utente Decidere se un’automazione parte in base al ricevimento di un evento di un dispositivo o secondo un certo periodo di tempo Possa automatizzare l’esecuzione delle automazioni secondo i miei bisogni, possibilmente creando cooperazione tra i dispositivi
Utente Cambiare il mio username e la mia password Possa tener aggiornati i miei dati

Definition of Done

Sarà fondamentale seguire la metodologia del TDD (Test Driven Development) per lo sviluppo software dove possibile. Questo permette di definire una user story così come una funzione/sottofunzione della RBS completata al 100% quando:

Ovviamente il primo punto non può valere per il presentation subsystem in quanto non è possibile testare l’interfaccia grafica. In questo caso, il punto sarà scambiato con:

Modello PMLC

Users Management Subsystem

Metodologia: Lineare

Motivazione: Lo scope è ben definito e non cambierà, la soluzione è chiara ed è possibile usare una COTS per accelerare i lavori.

Devices Management Subsystem

Metodologia: Incrementale

Motivazione: Non si è completamente sicuri di come visualizzare le proprietà ed eseguire le azioni di un dispositivo, per questo bisognerà procedere di volta in volta testando se le funzionalità sviluppate rispettano i requisiti che sono chiari e ben definiti.

Devices Protocol

Metodologia: Adattivo

Motivazione: Il protocollo comune tra i dispositivi dovrà essere creato durante il progetto ed essendo qualcosa di completamente nuovo per l’azienda potrebbe richiedere vari cambi di requisiti e di idee per la soluzione finale.

Devices Registration Subsystem

Metodologia: Incrementale

Motivazione: I requisiti sono chiari e ben definiti, ma ci sono tante soluzioni possibili e bisogna sceglierne una che potrebbe cambiare per vari motivi, come performance o semplicità di utilizzo/messa in pratica.

Scripts Management Subsystem

Metodologia: Adattivo

Motivazione: La gestione degli script è complicata ed è previsto che ci saranno molti cambiamenti anche dei requisiti nel corso del progetto.

Permissions Management Subsystem

Metodologia: Iterativo

Motivazione: La gestione dei permessi è qualcosa di complesso e si ha bisogno del feedback di utenti per poter capire se i requisiti sono corretti e completi.

Notifications Management Subsystem

Metodologia: Lineare

Motivazione: Requisiti ben definiti e soluzione già ben utilizzata in più progetti, non sarà necessario modificare questo sottosistema una volta progettato.

Presentation Subsystem

Metodologia: Incrementale

Motivazione: I requisiti sono piuttosto stabili e ben definiti, ma la soluzione è da perfezionare attraverso dei prototipi intermedi da far provare ad altri sviluppatori ed esperti del settore. Arrivati ad un certo punto di completezza del prototipo possono essere rilasciate versioni beta da far provare direttamente agli utenti e perfezionare l’applicativo attraverso il feedback ricevuto.

##