Questo è il progetto iniziale per la definizione di un API di comunicazione tra i componenti del core di UNGUESS.
L'obiettivo è quello di definire una serie di blocchi che possono essere utilizzati per costruire i servizi di UNGUESS. Ogni servizio potrà contare su un numero variabile di blocchi permettendoci di adattarci ad ogni necessità.
I blocchi base ma non unici che costituiscono un servizio sono:
- Blocco Quests: Elenco di missioni da svolgere, richiede il rispetto di determinate condizioni di accesso per poterne prendere parte.
- Blocco Costs: Elenco di blocchi di costo che possono essere automaticamente calcolati dal sistema (es: determinato dalle quests) o inserito a mano dall'utente (es: campagna pubblicitaria facebook, costo in giornate del csm).
- Blocco Price: Prezzo del servizio.
- Blocco Taxonomies: Elenco di taxonomie che possono essere utilizzate per raggruppare un servizio. Non ha impatto sull'esecuzione del servizio, ma è utile solo a fini statistici.
graph TD;
Service-->Quest1;
Service-->Quest2;
Service-->Price;
Service-->Costs;
Service-->Taxonomies;
Quest1-->StepBugFinding;
Quest1-->StepThinkingAloud;
Quest2-->StepBugFinding;
Quest2-->Survey;
E' l'elemendo fondamentale del servizio, corrisponde all'attività che si vuole completare ed è formata da un elenco di blocchettini di tipo Step.
Prevede una serie di condizioni di accesso che determinano la partecipazione del tester e l'impatto sul costo del servizio e un numero atteso di output obiettivo (esempio: numero di tester con completamento della missione).
Consiste in un elenco di condizioni che devono essere soddisfatte per poter prendere parte alla quest. In questo modo il tester che soddisfa questi requisiti può in autonomia decidere se svolgere o meno la quest. Tutte le ulteriori logiche di ingaggio sono gestite direttamente dalla piattaforma dei tester che potrà estendere queste condizioni.
ESEMPIO: QUEST RAPIDA
La piattaforma dei tester potrò decidere di auto-eliminare la partecipazione di un tester se non viene completata entro un certo tempo. In questo modo verrà liberato un posto che potrà essere occupato da un altro tester con le medesime caratteristiche. Il tutto senza influenzare la piattaforma customer o quella core.
Le regole di accesso inizialmente disponibili saranno:
- TimedAccessCondition: La quest è accessibile solo per un determinato periodo di tempo.
- TesterListAccessCondition: La quest è accessibile solo per una lista di tester specifica.
- TesterDeviceAccessCondition: La quest è accessibile solo per un certo tipo di dispositivo.
- TesterLimitAccessCondition: La quest è accessibile solo per un certo numero di tester.
Il blocco di tipo Step è una singola attività da svolgere con uno specifico output. Ogni step ha come compito quello di richiedere lo svolgimento di una determinata attività e contribuirà ad aumentare il valore di costo e tempo della quest a cui appartiene. Inizialmente sono previste tre tipologie di step:
- BugForm Step
- Survey Step
- Media Step
Lista di blocchi di costo che determina come verranno determinati i costi del servizio. Inizialmente verranno predisposti due possibili blocchettini e poi estesi in base all'utilizzo.
Questo blocchettino si occuperà di calcolare il costo del servizio in base al numero di quest e alla configurazione dei singoli step. Per cui un servizio dello stesso tipo ma con un numero superiore di step o condizioni di accesso particolari avrà un contributo di costo differente.
Blocchettino libero con il quale sarà possibile indicare una specifico costo, (...) TBD
TBD
TBD
TBD STRAPI DOC
sequenceDiagram
Customer Platform->>+Core: Require service
Core-->>-Tester Platform: Publish quests on Tryber
Tester Platform->>+Core: Retrieve outputs
Core->>+Customer Platform: Keep customer updated
Core-->>-Tester Platform: Award testers