Adaptation des questionnaires aux phases GSBPM

[BulotF]

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 :

• 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 : <xs:attribute name="collectCheck" type="xs:boolean"/>(valeur faux si "Actif en reprise seulement" est coché)
• au sein de "ControlCriticityEnum", ajout éventuel de modalités
• dans "ControlType", ajout de : <xs:attribute name="confirmable" type="xs:boolean"/>
• dans le type abstrait "VariableType", ajout de : <xs:element name="TargetPhase" type="SurveyPhaseEnum" minOccurs="0" maxOccurs="unbounded"/>
• 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 : <xs:attribute name="confirmable" type="xs:boolean"/>

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)