# Normes de spécifs

proposition pour échanges

*P. Bauer
mai 2022*

[TOC]

* orga d'un refonte
> *I:\Section_Enquetes-Collecte\Conventions_&_normes*
> **Conventions_org_dev_enquête.odt**
=> à mettre à jour avec nouvelles avancées !!

* Instance d’échange, en plus des échanges au quotidien :
> Comité de suivi des enquêtes : tous les 2 mois
> 05/05 : identification d'un référent unique pour chaque enquete
> Priorisation des dossiers : lors du Cocodici ? de ce comité ? RSD ? dépend peut-être de l'importance

* Cible des travaux menés par Steven et François H.
* Les travaux vont porter sur deux axes complémentaires. L’objectif est de converger vers des choix partagés, efficaces, et utiles à la fois au BCPS comme au BIS.
* Axe 1 : Livrables - Etapes du projet
* Livraisons BCPS : quel contenu pour le ou les fichiers de specs, quel output pour les recettes, quels envois au BIS
* Livraisons BIS : quelles étapes de livraisons d’applis ?
> Bien sur, ces livraisons sont interconnectées. Les étapes de livraisons du BIS dépendront des contenus livrés par le BCPS.
* Axe 2 : Gestion de projet
* Définition des rôles et responsabilités (quels acteurs, quels mandats, qui décide)
* Définition des plannings (qui ? Avec quelles étapes ?)
=> élaboreront une norme pour le planning de fourniture des spécifs, qui n'est pas lobjet du doc ici.

* TC attend un "livrable qui peut être facilement mobilisable : les attendus du BIS concernant les spécifs => ce qu’il faut absolument savoir en début de projet pour évaluer la complexité et la charge induite." et doc Resana des développeurs pour estimer la charge*
> ce qui est coûteux si ça change (ex : l'identifiant). François va le faire.

## modèles de l'IHM
* la définition du modèle
> *I:\Section_Enquetes-Collecte\Conventions_&_normes*
> **Normes_ergo.odt**
=> à mettre à jour (par le BIS - Vanessa) ?
* la définition des rôles gestionnaires/consultants/externes et des boutons sauvegarder/valider/supprimer/quitter
> *I:\Section_Enquetes-Collecte\Conventions_&_normes*
> **IHM des enquêtes permanentes_boutons.odt**
=> vérifier si c'est à jour (par le BIS)
=> à intégrer au doc du modèle (en ne conservant que les infos à jour) ?
* spéc déplacer bouton supprimer
> *I:\Section_Enquetes-Collecte\Conventions_&_normes*
**Déplacement-bouton-supprimer.odt**
=> FAIT suppression du fichier doublon sous le L
=> à supprimer ou fusionner avec doc ci-dessus
* la définition des tableaux de suivi
>*I:\Section_Enquetes-Collecte\Conventions_&_normes*
> **Tableaux de suivi des enquêtes permanentes.odt**
=> FAIT suppression du fichier doublon sous le L
=> comporte MJD, ER, Actad-ETat4, ASJ et futur AAV, mais pas délégués. à ajouter ?
=> à scinder en 2 : normes vs spécificités enquetes

=> ACTION regrouper toutes les infos du modèle IHM dans un même doc
- affichage, ergonomie
- comportements (action d'un bouton)
- rôles
- suivi (règle générale)
Mettre dans spéc des enquetes un onglet où on précise que ca suit la norme (réf au doc de norme), sauf pour tel ou tel point.
Doc sous responsabilité BIS.

## modèles des noms de variables
* mnemo pour élaborations de variables signifiantes
> *I:\Section_Enquetes-Collecte\Conventions_&_normes*
>**Normalisation_variables_enquête.ods**
=> ER et DEL y sont répertoriés (ASJ pas besoin car pas de renommage)
* règles de construction des noms de variables
> n'existe pas, à construire avec le BIS
> à ajouter dans un onglet mais quel doc ?
> lettre onglet(ou pas), ordre détail tableau, etc
ce qui existe actuellement
* **anciennes enquêtes papier** (en gros) : "v" pour variable du questionnaire + numéro/lettre partie + numero question + ordre dans le tableau
* **CDAD** : lettre partie + nom tableau + ordre dans le tableau, sauf TOT et STOT, ND
* **Actad-Etat4** : nom signifiant (8 variables)
* **MJD** : lettre partie + nom tableau + ordre dans le tableau (y.c le total) + _ND ou _DET associé au numéro du total
* **délégué refondu** : lettre partie + nom tableau + nom ligne

* tronc commun des variables des tables de diffusion (et vues de saisie)
>*I:\Section_Enquetes-Collecte\Conventions_&_normes*
**Enquêtes permanentes - Tronc commun des tables de diffusion.odt**
=> FAIT suppression du fichier doublon sous le L
=> à mettre à jour
=> à ajouter comme onglet dans modèle spécif tables ?
* tronc commun des variables des vues des erreurs
> !! différent des codes erreurs
=> à construire. 1 doc commun avec annexes sur spécificités? ou réécrire à chaque enquete ?

=> au BCPS de trancher sur les règles de nommage. voir si on conserver le premier bloc sur nom d'onglet, en particulier
=> faire un seul doc, propre au BCPS qui en est garant, gère sa mise à jour.

## modèle des modalités

* variables
> *I:\Section_Enquetes-Collecte\Conventions_&_normes*
> **Normalisation_table_nomenclature.ods**
> sert à vérifier que la nomenclature n'existe pas déjà, et coller aux nomenclatures des autres enquêtes s'il le faut (ex : OUINONNR)
> c'est une simple extraction de la table
=> à conserver ?
=> mettre plutôt dans le doc des normes de variables une référence à cette table, voire qques nomenclatures fréquentes
=> à BCPS n'être vigilant. pas besoin de TC en base, mais peut-être un TC dans notre doc?.
* codes erreurs
> il faut fixer des règles de nommage, mais où les noter dans l'existant ?
> actuellement : letttre et numéro de la question + numéro de ligne (voire lettre si plusieurs ctrl sur cette ligne).
>> avantage : court et rapide à écrire. pas besoin d'avoir qqc de signifiant
>> inconvénient : décalages lors d'évolution dans le questionnaire (ex : chgt de numéro de question)

> un simple numéro qui s'incrémente comme dans dispo de collecte ? code insignifiant car info déjà dans libellé et spécifs ?
> quelle règle donner?
>> certains proposent des codes qui prennent simplement les noms de variables + ajouter un nombre/lettre ? peut être long, limite les décalages mais ne règle pas tout.
>> Rq : a-t-on besoin de conserver le code d'un an sur l'autre lourd pour le BIS ? oui c'est lourd et source d'erreur en dev.

=> plutôt choix côté BCPS. mais convenir à tous pour éviter de revenir dessus chaque année...
il faut identifier mais pas signifier

## modèle des formats de spécifs
* normaliser les noms de vues

* Actuellement
* le questionnaire avec variables
> indispensable, pour BIS (lors des refontes) et même pour la SEC et chargés d'études
* 1 doc excel qui regroupe : historique des versions + (spécifs refonte) + nommage var + IHM (var, type, lib, mod, filtres, alertes, ctrl) + lib erreurs + lib nomenclatures

* suivi de saisie dans appli : où est-ce spécifié pour ASJ et délégués ?
> - ASJ : dans le doc de réf. peut-être ajouter un onglet dans doc IHM pour préciser spécificités du dispositif, tout en faisant référence au doc de réf ?
> - DEL : dans un doc à part **Spécifications suivi.odt** sous I:/ . à mettre plutôt en annexe du doc de référence ? mode hybride entre enq perm avec SRJ et enq ponc avec no_cmpst.
=> à ajouter au doc de spécif du suivi, en annexe, avec précisions ci-dessus
* 1 doc spécifs vue erreurs
> à dissocier des codes erreurs, qui sont dans spécifs appli
* 1 doc spécifs vue(s) saisie
* 1 doc spécif table(s) diff
> modèle :
>*I:\Section_Enquetes-Collecte\Conventions_&_normes*
**Enquetes permanentes - specifications des tables de diffusion 2021.ods**
=> attention le nom" diffusion" porte confusion à BDSED : trouver un autre nom ?
voir plutôt avec BDSED ? rien en dur . voir dans le wiki
=> transformer en modèle également:
- vue des erreurs
- spécifs des estimations et vue des estimations + rappel existance dans vue de saisie
=> faut-il renommer les noms des tables de diffusion pour harmoniser les pratiques ? où mettre les règles de nommage des vues/tables ?
* bonus : doc estimations délégués
=> j'y ai mis spécif vue/table estimations...
=> à transformer en doc générique, les particularités de chaque enquête en annexe ou dans un fichier excel ?
* attention : éviter le dico des données ? à ne pas donner
* autres éléments fournis ? faut-il le questionnaire sans variables ? non

* dans le futur : proposition
* voir déjà ce qu'il y a en trop, qui n'est pas nécessaire pour le BIS
* 1 doc IHM, yc.c code erreurs et code nomenclatures
=> sans les ND
* le questionnaire avec noms de variables, pour connaître la disposition des variables dans les tableaux. Il ne doit pas y avoir d'adhérence forte de l'IHM au questionnaire, car les contraintes IHM sont fortes : taille caractères. les titres trop longs ou en bas de tableau sont passés en info-bulle (non spécifié mais interprété par Vanessa, te ca convient bien).
*
* 1 doc vues et tables : saisie, erreurs, estimation, diffusion
=> plutôt un doc spécifs **vues d'erreur transversal** avec infos particulirités des chaque enquete
=> un excel avec les vues de saisie, avec liste entière des variables
=> un excel avec les tables de diffusion (qui pourra aller sur le wiki)
* un doc de spécif du **suivi de saisie transversal**
* **1 doc général sur la refonte** en word pourquoi, quoi qui quand, planning, liste des docs en référence, liens, etc ? tout ce qui tourne autour de la refonte mais n'est pas une spécif
> à mettre à jour au fil de la refonte, une seule version en cours. puis laisse une trace de la refonte.
=> comment gérer l'historisation ?
=> faut-il garder un VF par année ? plutôt oui, 1 version datée de la fin de la campagne . pour les années sans évol, faire une version quand même.
*
* erreurs :
* dans les onglets spécifs d'IHM, mettre la liste des codes d'erreurs dans la ligne de la variable où le message d'affichera. ne pas être libellé trop longs car peu lisible dans IHM.
* dans l'onglet erreurs, liste des erreurs : (numero question?), code, libellé, formule avec liste entière des variables (pour faciliter recherche), message à afficher, commentaire si besoin de précisions pour le dev
> voir si ca ne complique pas trop la tache de création des spécifs d'erreurs pour le BCPS. gérable avec duplication du fichier pour travailler sur les 2 onglets en même temps.
> colonne ALERT et colonnes CTRL conservées, mais avec uniquement les codes des erreurs.
* avantage : évite les redondances et risque d'erreur associés. simplifie quand plusieurs erreurs pour une même zone
* onglet nomenclature :
> OK pour garder.
c'est au BCPS de vérifier dans DP_NOMEN_ENQUETE si la nomenclature existe déjà et la reprendre.
sous PG : schéma ENQUETE ou NOMEN ? les 2, selon l'enquête. migration progressive sous NOMEN. faire un Mantis pour dder fusion et lieu unique.

## modèles génériques des recettes
* régles BIS :
* passer en TEST pour que la SEC teste sur une version stable.
* message officiel de mise en recette, dans lequel le BIS donne les chemins et procédures d'accès, et l'attendu de la recette. y.c. projet resana à alimenter
* vérifier les droits SEC dans bases.

* pour recette d'une vue/table
> via un pgm R proposé au sein de la SEC ?
* liste des variables : casse, nom et ordre
* tri des observations (pour les vues uniquement)
* format, longueur
* commentaire de colonne (libellé) : vues de saisis et tables de diffusion
* valeur correspond à l'attendu (lien IHM-table/vue correct), en remplissant questionnaire fictif mais valeurs dans les champs qui sont distingables.
> 2 cas :
> >si vue de saisie livrée avec IHM, alors recette de la vue et du champ de l'IHM en même temps
> > si vue de saisie livrée après IHM, alors IHM recetté avec table(s) de saisie, et vue de saisie recettée avec table de saisie (ou IHM , au choix, mais plus compliqué).
* sous Resana projet "vues et tables": retours sur la recette, déplacer la cartouche
* validation de la prod : accès et intégrité (test questionnaire bidon et son intégration dans les données). test de surface.

* pour recette d'une IHM
* présentation & ergonomie, enchaînements,
* libellés, textes, titres
* organisaton des onglets/tableaux
* champs : format, longueur, nomenc complète
* erreurs : ctrl et alertes testés exhaustivement
* sous Resana projet "monEnquete": retours sur la recette, déplacer ou créer des cartouches.
* validation de la prod : accès et intégrité (test questionnaire bidon et son intégration dans les données). test de surface.

Format de
> sorte de liste à cocher, pour ne rien oublier
> existe-t-il une base préexistante (dans un mail, doc ...) ?
> préconisation de retours BCPS -> BIS : au fil de l'eau, groupé, via Resana, via mail etc.
> conserver une trace ? un bilan, une restitution? pour BIS et SEC ?
> TOP : fournir un jeu de données avec les cas qui doivent être OK, des cas KO etc. [moyen terme]

## orga des dossiers
* modèles des spécifs : tous dans [I:\conventions&normes].
> j'ai retiré ce qu'il y avait sous L:\enq perm \transversal
* spécs uniquement sous I:\ ? et dans le L, mettre des liens si nécessaire, ou suppr certains dossiers. et nettoyer le I:/ avec des archives
* règles de nommage des documents de spécifs :
> une seule et dernière version, nommage sans "v1, ni date" mais une onglet ou en-tête expliquant les modifs ?
* top : gérer les versions avec GIT ?
> je ne sais pas comment procéder. utilisation logiciel particulier ?

## Autres
* faut-il rétrospécifier certaines enquêtes ou le travail du BIS (gestion de Mantis, par exemple)
* clarifier refonte / Mantis ?
* comment organiser cela avec les autres documents ?
*
* surtout le dico des données
* dico des données : faut-il réécrire toutes les infos ? y.c. controles. gérer l'historique de la variable : compilation avec dates de validité ?
* wiki : faut-il réécrire la liste des var en tableau wiki
> peut-on automatiser ? export en tabelau Markfown etc