Au Pied Levé - À Main Levée
I-1.3. Démarrer
par , 01/04/2020 à 11h40 (318 Affichages)
■ PrémicesAPL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.
■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■
- Prémices
- Étude de l’existant
- Étude préalable
- Démarrage effectif
- Création de la BDD
- Création d’un menu « light »
- Création du référentiel métier
- Création de la nomenclature (catalogue)
- Vues BDD
Comme pour le RAD dans sa phase de Cadrage, chaque démarrage est suspendu :
- à un engagement total de la direction, présenté comme une stratégie d’entreprise,
- à une ressource de coordination de haut niveau formellement affectée au projet, donc à un budget et à des ressources logistiques.
Pas de budget, pas de serveur, pas de postes de travail, pas d’application. C’est aussi simple que ça.
Le déblocage d’une situation peut être immédiat (Examens-Concours) comme il peut parfois laisser le temps de réaliser une Étude préalable (Formation Continue). Quel que soit le contexte, le démarrage effectif est imprévisible, envisager un cahier des charges modélisant le système en bonne et due forme relève de l’utopie. Avec une méthode classique Top-down ou même en RAD (2/3 Top-down + 1/3 Bottom-up), ce sont les développeurs qui prennent l’initiative en maitrisant toujours leurs investissements (procédure, modélisation). En APL-AML, le développeur avance en terrain vierge (pas de procédure) et navigue à vue (pas de modélisation). C’est le besoin immédiat qui dirige, la succession événementielle des étapes du cycle de gestion. Pour ce qui concerne la Formation Continue, le cahier des charges s’est résumé en cette phrase : « Ne pas faire moins bien que ce qui existe ».
PS : Le soi-disant 1/3 Bottom-up du RAD n’est en fait pas du pur Bottom-up. C’est comme si un grand cuisinier venait faire la cuisine chez un particulier en amenant sa recette et tous ses produits sauf le poivre et le sel, au lieu de faire la cuisine chez le particulier à partir d’une recette qu’il crée sur place avec les produits qu’il trouve. C’est comme accorder la mention « Origine France garantie » à un produit qui ne mérite que l’appellation « Fabriqué en France ».
■ Étude de l’existant
Par existant, il faut comprendre l’outil informatique agonisant voire abandonné de l’utilisateur. Un développement Au Pied Levé est généralement l’ultime recours à un existant moribond symptomatique d’une obsolescence. Pour survivre, l’utilisateur a dû s’adapter à la dégradation de son outil et la réalité de la problématique s’en trouve dénaturée. L’étude de l’existant n’apporterait rien et n’engendrerait qu’une perte de temps à un moment où précisément il n’y en a pas.
Il est difficile d’imaginer à quel point certaines entités administratives puissent être livrées à elles-mêmes, délaissées ou ignorées par l’entité informatique de leur structure.
Peut-on croire qu’un service Examens-Concours qui organise des dizaines concours par an et gère des milliers de candidatures, ne fonctionne que grâce à une gestionnaire ayant quelques notions d’Excel ?
Peut-on croire qu’un autre service Examens-Concours ne fonctionne qu’avec des embryons dupliqués de fonctionnalités en DBase II dont les données spécifiques de chaque concours important sont en « dur » dans les programmes (titre, épreuves, dates, lieux, etc.) ? Peut-on croirea que les gestionnaires de ce même service ne puissent imprimer que grâce à une petite imprimante bureautique prêtée par un autre service ? Peut-on croire que cette solution soit l’œuvre d’un service informatique ?
Peut-on croire que le micro-ordinateur utilisé par la Formation Continue nécessite une sauvegarde toutes les demi-heures et finisse par ne plus fonctionner… à cause de sa batterie ? Peut-on croire qu’une batterie neuve fasse découvrir, les paramètres internes ayant été perdus, que la capacité du disque dur était bridée en fonction d’un contrat ?
Peut-on croire qu’une application ait été purement et simplement abandonnée par un utilisateur et ne serve plus qu’à justifier une maintenance qui n’en nécessite plus depuis bien longtemps ?
■ Étude préalable
APL-AML ne s’appuie sur rien, pas davantage sur une étude préalable que sur un cahier des charges ou une modélisation. Le contexte peut cependant offrir l’opportunité d’entreprendre une étude préalable. Le document produit n’impacte pas les développements mais sa description de la problématique sous son angle administratif constitue une approche didactique intéressante.
Formation Continue :
En attendant qu’un budget soit débloqué, une étude préalable a été menée par un groupe de travail composé de deux développeurs, la responsable métier, une gestionnaire et parfois le responsable de la Mission Académique qui conçoit les formations. À noter que la participation d’une gestionnaire à ce petit groupe de travail est l’initiative de la responsable métier qui y voyait, comme ça se pratiquait dans les années 70, le moyen de faire accepter plus facilement le futur logiciel à ses collègues.
Durant le premier trimestre 1991, des réunions avaient donc lieu, deux heures par semaine, chaque vendredi après-midi. Dans les faits, ces réunions donnaient à l’utilisateur l’illusion qu’il se passait quelque chose, que l’informatique s’occupait de sa problématique mais concrètement, c’était le calme plat.
Cette étude préalable fut le prétexte pour les informaticiens de s’approprier un micro-ordinateur afin d’en rédiger les comptes rendus. À l’époque, la denrée était aussi rare que l’était l’utilisation des outils bureautiques. L’étude préalable a toutefois permis d’aborder les points suivants :
- HISTORIQUE
- ORGANIGRAMME
- INTERVENANTS
- DIAGRAMME DES FLUX
- ÉTUDE DES POSTES
- ÉLABORATION DU PLAN ACADÉMIQUE DE FORMATION
- GESTION DES STAGES PAF (Plan Académique de Formation)
- GESTION DES STAGES PNF (Plan National de Formation)
- GESTION DES MOYENS
- LEXIQUE
Début mai 1991, un budget minimaliste « providentiel » permet l’acquisition in-extrémis d’un premier serveur Unix, du SGBD Informix et d’une dizaine de terminaux. On oublie l’étude préalable qui sera toutefois consultée de loin en loin, par curiosité, pour mesurer le chemin parcouru. La première ligne de code est écrite mi-mai 1991, soit une semaine après la décision prise par le Ministère de développer une nouvelle application nationale (GAIA) sous Unix. Trois jours plus tard, la saisie des candidatures est opérationnelle.
NB : Une étude préalable pour la Formation Continue est proposée dans les billets « Annexes ».
■ Démarrage effectif
Attention !... C’est brutal ! Le développeur n’est pas dans la modélisation, assis confortablement derrière son bureau, avec le temps de la réflexion dans sa bulle confort, mais dans la réalité, le développement en live, avec des gestionnaires et des utilisateurs dépendants, confiants ou sceptiques, qui attendent, qui observent, qui s’inquiètent, qui espèrent.
Coordination, communication, initiatives, acquisition de nouvelles compétences… Tout va très vite, dans toutes les directions. L’important, c’est d’assurer, de maintenir le cap, d’éteindre tous les départs de feu au fur et à mesure qu’ils se déclarent, de garder confiance en soi.
■ Création de la BDD
L'EDI du SGBD Informix permet de créer dans un premier temps une BDD vierge constituée des seules tables système. Le nom du dossier destinataire de la BDD (suffixé .dbs par Informix) devient le nom (sans le suffixe) de la BDD.
Le nom de l’application (ex : Ex&Co) peut très bien être différent du nom de la BDD (ex : concours). Le caractère « & » d’Ex&Co que l’on doit protéger sous Unix complique son utilisation dans les shells. Ex&Co est en quelque sorte le nom de scène de l’application, utilisé dans les écrans et les états et concours le nom d’usage de la BDD, utilisé par le SGBD.
Prévoir l’arborescence des développements avant de créer sa BDD.
Exemple :
À noter que le nom du répertoire de développement est le même que celui de la BDD (sans le suffixe « .dbs ») ; c’est une question de cohérence, une façon de satisfaire l’œil, d’éviter une charge mentale, de faciliter les développements, de simplifier les sauvegardes :
- soit la totalité de l’application (/concours),
- soit le développement (/concours/concours),
- soit la BDD (/concours/concours.dbs).
■ Création d’un menu « light »
Informix propose un système de menus. Son utilisation ajoute deux tables supplémentaires dans le system catalog : sysmenus et symenuitems.
La création d’un embryon de menu via l'EDI d'Informix permet de structurer l'inconnu, de faire croire aux gestionnaires que l’application a toujours existé, et leur donne accès aux premières fonctionnalités du logiciel, notamment les écrans de saisie.
Lorsque l’évolution de certaines fonctionnalités impose une restructuration du menu, il convient de l’entreprendre à l’occasion d’un nouveau cycle de gestion ou après une période de vacances afin de laisser aux gestionnaires le temps d’oublier leurs automatismes.
NB : Deux systèmes de menus sont proposés dans les billets « Annexes ».
Les menus ci-dessus sont des menus aboutis, bien qu’encore perfectible mais au début des développements, ces menus étaient approximatifs et surtout seuls les items utiles dans l’instant étaient opérationnels. Les gestionnaires, sous pression, n’avaient pas le temps de s’aventurer sur les items qui anticipaient les fonctionnalités en gestation. L’important était que ces items soient là, qu’ils fassent déjà partie du paysage, que les gestionnaires les digèrent inconsciemment, ou mieux qu’ils suscitent des réactions.
Pour les Examens-Concours, l’organisation des premiers concours a profité aux concours organisés plus tardivement. Le menu JURY a été greffé à l’occasion de la deuxième série de concours de septembre à décembre.
■ Création du référentiel métier
Le référentiel métier, ce sont les tables de la Base de Données contenant les « références », c’est-à-dire les données stables du système d'information. C’est un ensemble de tables le plus souvent indépendantes (Grades, Établissement, etc.) mais pas obligatoirement (ex. : Départements -► Communes -► Codes postaux).
Il s’agit ni plus, ni moins, de créer les premières tables de la Base de Données. L’EDI du SGBD permet de les créer facilement, soit via une interface graphique sobre et pratique, soit via de simples requêtes SQL.
Quelques heures suffisent pour planter le décor. À l’aide d’écrans rudimentaires générés facilement et instantanément via l’EDI, le développeur assure dans un premier temps la saisie des paramètres applicatifs et des tables de référence peu conséquentes, confiant les éventuelles saisies de masse aux gestionnaires. Plus tard, ces écrans sans prétentions ergonomiques, ni esthétiques, seront revisités pour rendre les gestionnaires autonomes dans de meilleures conditions d’utilisation.
À noter que certaines tables peuvent souvent s’initialiser, via quelques requêtes SQL, depuis des tables provenant d’autres Bases de Données de l’entreprise (ex. : Grades, Établissements).
En termes de modèle de données, un schéma embryonnaire de type entité-relation suffit pour démarrer et n’a même pas besoin d’être formalisé avec force détails. L’expérience aidant, une visualisation mentale permet de créer rapidement les premières tables. Les entités référentes, leurs attributs et leurs identifiants s’imposent sans ambiguïté.
■ Création de la nomenclature (catalogue)
L’activité d’une entité métier revient souvent à gérer une offre et une demande. L’offre se concrétise en quelque sorte par une nomenclature ou un catalogue et la demande par un public, une clientèle.
La nomenclature définit le type d’activité de l’entité métier, elle concrétise en fait l’objet social de l’entité : examens-concours, formations, etc. La nomenclature se présente concrètement par plusieurs tables liées entre-elles par une relation « 1,n ».
Exemple :
La mise en relation de l’offre et de la demande fait généralement l’objet d’une démarche indépendante :
- FCPE : Publication du Plan Académique de Formation (PAF).
- Ex&Co : Ouverture des concours, affichages et publicité.
Selon la problématique métier, la mise en relation initiale de l’offre et de la demande peut permettre d’initialiser une partie de la nomenclature.
Toute la nomenclature n’est pas forcément nécessaire pour rendre opérationnelle la saisie de la demande. Une partie peut être différée et renseignée le moment voulu.
Créer le référentiel métier et la nomenclature est le préalable au développement de la première fonctionnalité qui s’avèrera être vraisemblablement une saisie de la demande.
Dans certains cas comme la formation interne, qui concerne tout le personnel de l’entreprise, la table des personnes peut s’initier depuis la BDD qui gère le personnel.
Offre-demande : Certaines problématiques purement administratives, comme une gestion du personnel par exemple, ne s’inscrivent pas dans cette approche conceptuelle « offre-demande ». Ce ne sont généralement pas des problématiques en désespérance évoluant dans un contexte dramatique. Elles s’accommodent sans doute mieux de développements plus conventionnels.
■ Vues BDD
APL-AML est une démarche de développement bottom-up à partir des besoins. Contrairement à une démarche top-down qui étudie séparément Données et Traitements, le développement ne s’appuie ni sur un Modèle Conceptuel des Données, ni sur un Modèle Conceptuel des Traitements. La fonctionnalité (le besoin) crée l’organe (les tables et leurs attributs).
Concrètement, la fonctionnalité à développer entraine, si nécessaire, la création de nouvelles tables et/ou l’ajout d’attributs à des tables existantes. On peut assimiler l’ensemble des données indispensables au développement de la fonctionnalité à une vue BDD, une vue de la BDD réelle en cours de construction. On n’est pas dans la modélisation, le virtuel mais dans le monde réel, le concret. On ne pense pas « entités » mais « tables ». Tout SGBD permet d’intervenir aisément sur sa BDD. Le développement des fonctionnalités au fur et à mesure des besoins construit progressivement la BDD.
Consulter le profil
Marquer ce blog comme lu
