Pogues et Bowie en général a été conçu avec en ligne de mire la phase de collecte.
Avec la prise en compte de la phase de reprise, on s'aperçoit que s'il est explicite que pour les variables collectées, elles n'existent jamais avant la collecte et toujours après, il y a 3 types d'objets dont l'existence nécessite d'être explicitée à chaque phase :
les contrôles : si les contrôles de collecte sont obligatoires en reprise, la réciproque est fausse
les variables externes : certains contrôles de reprise s'appuient sur des variables que l'on se refuse à utiliser en collecte (ou qui ne sont tout simplement pas calculables à ce moment-là)
les variables calculées : là, il y a 3 phases où elles peuvent avoir de l'utilité ou non : collecte, reprise et analyse / diffusion : si l'on souhaite utiliser dans l'analyse des indicateurs liés aux filtres, on n'a pas besoin des variables qui permettent de personnaliser des libellés avec le e du féminin
Stakeholders
Permettre aux concepteurs de spécifier les contrôles spécifiques à la phase de reprise sans utiliser de nouvel outil.
Stack
Condition de non-régression : Côté Eno, génération depuis le DDI : si le VariableGroup correspondant à la phase n'existe pas, prendre toutes les variables et tous les contrôles.
Risque : le nombre de questionnaires au format Lunatic se démultiplie lorsque l'on ajoute les modes et les phases...
DDI
Pour les contrôles, j'envisageais de compléter la liste des modalités de d:TypeOfComputationItem (liste que j'avais déjà faite passer de 3 à 6 valeurs à cause des contrôles de lignes de tableau dynamique)
Pour les variables (externes et calculées), j'avais envisagé d'utiliser des l:VariableGroup avec l:TypeOfVariableGroup qui correspondrait à la phase (COLLECTION ; EDITION...) ; ces groupes de variables interviendraient en tant que filtres sur les listes de variables pour les cas de DDI multi-Instrument pour ne pas insérer en collecte de variables qui ne servent qu'en reprise
Pogues
Pour les contrôles :
ajout d'une case à cocher : "Actif en reprise seulement"
éventuellement modification de la liste des modalités de "Criticité"
(sous condition de criticité) : ajout d'un booléen "Confirmable"
Pour les variables (externes comme calculées)
ajout d'une liste de phases : "Collecte" , "Reprise", "Analyse" toutes les 3 cochées (fonctionnant selon le même principe que les modes)
Pogues-model :
dans "ControlType", ajout de : (valeur faux si "Actif en reprise seulement" est coché)
au sein de "ControlCriticityEnum", ajout éventuel de modalités
dans "ControlType", ajout de :
dans le type abstrait "VariableType", ajout de :
SurveyPhaseEnum serait la liste des valeurs pour les phases. Si je reprends les grandes étapes du GSBPM, j'aurais ainsi : COLLECT ; PROCESS ; ANALYSE (mais le nombre de modalités et leurs libellés peuvent être différents)
Eno
Il génèrerait des questionnaires différents selon la phase... Et pourrait indiquer dans le questionnaire généré le mode et la phase ?
Lunatic-model
au sein de "ControlCriticityEnum", ajout éventuel de modalités
dans "ControlType", ajout de :
Lunatic
L'attribut confirmable devrait n'avoir d'effet que sur l'orchestrateur.
Seul l'enrichissement éventuel de la liste des criticités des contrôles pourrait avoir un effet limité (validation des modalités correctes, voire évolution de la fonction hasCriticalError)
Business case
Pogues et Bowie en général a été conçu avec en ligne de mire la phase de collecte. Avec la prise en compte de la phase de reprise, on s'aperçoit que s'il est explicite que pour les variables collectées, elles n'existent jamais avant la collecte et toujours après, il y a 3 types d'objets dont l'existence nécessite d'être explicitée à chaque phase :
Stakeholders
Permettre aux concepteurs de spécifier les contrôles spécifiques à la phase de reprise sans utiliser de nouvel outil.
Stack
Condition de non-régression : Côté Eno, génération depuis le DDI : si le VariableGroup correspondant à la phase n'existe pas, prendre toutes les variables et tous les contrôles.
Risque : le nombre de questionnaires au format Lunatic se démultiplie lorsque l'on ajoute les modes et les phases...
DDI
Pogues
Pogues-model :
Eno
Il génèrerait des questionnaires différents selon la phase... Et pourrait indiquer dans le questionnaire généré le mode et la phase ?
Lunatic-model
Lunatic
L'attribut confirmable devrait n'avoir d'effet que sur l'orchestrateur. Seul l'enrichissement éventuel de la liste des criticités des contrôles pourrait avoir un effet limité (validation des modalités correctes, voire évolution de la fonction hasCriticalError)