Au Pied Levé - À Main Levée

APL-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 ■ ■ ■

• Avant-propos
• Introduction au RAD
• Low cost, high speed, high quality
  
  • Phase de Cadrage
  • Phase de Design
  • Phase de Construction
• Récapitulatif des règles d’efficacité d’un projet RAD

RAD - Développement Rapide d'Applications (Jean-Pierre VICKOFF - 1996)

■ Avant-propos

Organisé pour une lecture séquentielle ou une navigation par centres d’intérêts, l’ouvrage de Jean-Pierre VICKOFF aborde les chapitres suivants :

• Introduction
• Axe méthodologique
• Axe systémique
• Axe organisationnel
• Axe communication
• Axe technologique
• Phase de Cadrage
• Phase de Design
• Phase de Construction

Accès aléatoire oblige, les redondances de thèmes et de sujets développés à divers endroits, ont privilégié une transcription de l’ouvrage sous forme d’une synthèse plutôt que d’un résumé.

■ Introduction au RAD

Le RAD, véritable état de l’art en matière de développement en 1996, couvre aussi bien le champ méthodologique classique que les aspects technologiques (modélisation directe), organisationnels et humains (entretien de groupe). Osmose des méthodes, des hommes et des outils, le RAD permet la mise en place d’applications totalement approuvées par les utilisateurs, avec pour avantages :

• La réduction des coûts (Low cost)
• La réduction du cycle de développement (High speed)
• La qualité de la réalisation et un plus grand nombre de fonctionnalités stratégiques (High quality)

Les autres objectifs du RAD sont liés à l’engagement constant et à la satisfaction des utilisateurs en termes de fonctionnalités, de délais et d’ergonomie :

• Le RAD permet et impose naturellement une participation active et une motivation des futurs utilisateurs de l’application qui représentent une force de proposition fonctionnelle. Une application conçue par les utilisateurs et réalisée sous leurs directives n’encourt pas de rejet.
• On livre une partie opérationnelle de l’application le plus rapidement possible afin de réaliser un retour sur investissement immédiat et afin de maintenir la confiance.

« Le principal défi n’est pas technologique, il est humain et organisationnel » (Serge Miranda)

L’approche classique d’une hiérarchie appliquant des contrôles verticaux fait place à l’engagement de l’ensemble des forces opérationnelles du processus horizontal de production, à une attitude évoluée de l’encadrement intermédiaire basée sur le sens du service et une collaboration dépourvue d’autoritarisme.

Parallèlement à un plan d’amélioration continue de la qualité nécessitant un flux continu de la communication (worflow), il faut envisager simultanément la réingénierie de la fonction informatique et celle des fonctions à informatiser. C’est un ensemble de changements difficile à gérer mais rien n’oblige à tout réaliser d’un seul tenant. L’amélioration continue et incrémentale, principe fondamental du RAD, utilise la technique du prototypage qui est un état intermédiaire du développement associant pleinement les utilisateurs dans une recherche de consensus et d’efficacité : il faut faire vite et bien. Le RAD est alors un « processus orchestre » où interviennent à tour de rôle les spécialistes que les fonctionnalités ou la technologie nécessitent.

Maquette et prototype Utiliserions-nous pour nous déplacer une maquette d’avion ? Maquette Selon le petit ROBERT : reproduction à échelle réduite ou grandeur nature, destinée aux études. En informatique, une maquette est un ensemble d’états et d’écrans permettant d’appréhender les enchaînements et la présentation. Prototype Selon le petit ROBERT : premier exemplaire d’un modèle. En informatique, le prototype est une réalisation modélisant le logiciel définitif.

Le prototype est une version opérationnelle de l’application en cours d’amélioration. Possiblement et provisoirement incomplet, son dimensionnement n’en est pas moins réel.

En RAD, on ne perd pas de temps à présenter des maquettes, on réalise avec les outils définitifs un produit qui sera finalement utilisé. Dans le respect des règles strictes de construction, il est utilisable en fonctionnalités partielles. Il constitue un ensemble minimum, mais viable, de fonctions représentatives.

La mauvaise presse faite au RAD est avant tout liée à la notion de rapidité, qui passe pour une absence de rigueur souvent considérée comme incompatible avec la qualité. Au-delà de la productivité de développement, atteindre un haut niveau de qualité nécessite une grande créativité. Dans ce principe, le RAD peut inquiéter car il implique un retour à l’improvisation, principale cause d’échec dans le passé. La vitesse, la qualité et le coût ne sont plus des critères en opposition. Par leur souplesse et leur puissance, les SGBDR et AGL de développement d’aujourd’hui, indissociables du RAD, remplacent avantageusement l’absence de pensée formalisatrice qui étouffe la réflexion et la créativité.

Si l’acronyme « RAD » de l'anglais Rapid Application Development avait été traduit par « développement maîtrisé d’application de qualité approuvée par les utilisateurs », la controverse entre méthode et RAD n’aurait pas eu lieu.

Les statistiques de développement, les problèmes générés par l’informatisation, des besoins fluctuants ou mal évalués, la garantie d’un retour sur investissement, expliquent l’importance d’un développement rapide et une relation permanente avec les utilisateurs.

Dans toutes ses phases, le RAD implique la communication entre utilisateurs et informaticiens et s’assure la qualité de fait. James Martin recommande l’emploi d’un profil « méthodes » formé au RAD et aux techniques d’entretien. La multiplicité des acteurs nécessite une forme innovante de coordination (animateur, rapporteur).

La rigueur du passé, sécurisante mais limitant la liberté d’expression, est remplacée par la productivité totale avec pour seules bornes le budget, le temps ou la satisfaction de l’utilisateur. On recherche « une solution par consensus par opposition à la quête de la perfection traditionnelle » (B. Villetelle). Il ne s’agit plus de réaliser à long terme un applicatif parfaitement adapté à un futur relativement imprévisible mais de remplacer les certitudes d’autrefois par la production de logiciels légers, maintenables, facilement évolutifs.

La prise de décision n’est donc plus un acte déterministe mais une hypothèse sur le futur. Cette hypothèse se veut la plus probable, sans qu’elle puisse constituer une certitude dans le temps. Réaliser des systèmes de complexité croissante avec des produits en cours de stabilisation est une démarche audacieuse et souvent indispensable qui implique un suivi précis et une probabilité de remise en question permanente, une méthode de conduite de l’évolution totalement adaptable.

Avec le sens du service et tout le pragmatisme des Américains (time is money), James Martin nous fournit les garde-fous du syndrome du « jamais fini ». Le « just in time » associé au service maximum obtenu au moindre coût nous conduit alors au principe même de la qualité totale de service.

Le vrai défi de la recherche d’amélioration continue concerne la rupture des barrières de communication mais le plus important reste la motivation des participants qui ne doit pas être déçue.

Judicieusement pratiquée, l’informatique oblige les personnes à travailler plus proprement et apporte à tous un surcroît de productivité. C’est la seule voie vers la qualité totale qui nécessitera de disposer presque instantanément d’applications jetables. La notion de pérennité du logiciel s’efface devant la nécessité de l’évolution. Le cycle est accéléré mais le formalisme classique reste fiable et garantit la cohérence.

■ Low cost, high speed, high quality

Trois phases structurent le développement rapide. Les deux premières s’appuient sur une approche descendante (top-down) et la troisième, sur une approche montante (bottom-up). C’est à l’engagement de la troisième phase que l’on bascule dans le RAD pour garantir l’adéquation du produit aux exigences de l’utilisateur.

1. Phase de Cadrage
   
   Cette phase cerne les objectifs, verrouille les besoins, les budgets, les délais et la solution globale sur les plans stratégique, fonctionnel, technologique et organisationnel. Le projet d’informatisation doit justifier la nécessité de chaque fonctionnalité et en déterminer la priorité.
   
   Les intervenants
   
   
   • Le Maître d’ouvrage (le client, propriétaire de l’application) justifie le projet auprès de la direction générale et engage un budget pour obtenir un produit.
     
     
   • Le Maître d’œuvre (le fournisseur, responsable de la réalisation) coordonne le projet et fournit le produit.
     
     
   • Les Utilisateurs, outre le propriétaire de l’application, sont les gestionnaires, utilisateurs effectifs de l’application et les interlocuteurs, utilisateurs des résultats ou fournisseurs de données.
     
     
   • Le comité de pilotage : un chef de projet + un maître d’ouvrage + quelques spécialistes.
     
     
   • Le groupe de projet : un chef de projet + un coordinateur utilisateur + quelques utilisateurs.
     
     
   • L’équipe RAD : un petit groupe d’informaticiens expérimentés + utilisateurs significatifs motivés.
     
     
   • L’équipe d’experts : ponctuellement, des informaticiens spécialistes des AGL de conception et de réalisation + des experts en communication et réseaux, en design et administration de SGBD, en ergonomie cognitive, en documentation.
   
   Le management d’un projet qualité passe :
   
   
   • Par un engagement total de la direction, présenté comme une stratégie d’entreprise,
   • Par une ressource de coordination de haut niveau formellement affectée au projet, donc un budget et des ressources logistiques,
   • Par une structure d’animation composée d’un ensemble représentatif du personnel qui reçoit une courte formation qualité,
   • Par des équipes d’amélioration ponctuellement crées et formées dont la mission est de rechercher les possibilités d’amélioration d’une fonctionnalité.
   
   Étude d’opportunité
   
   Le chef de projet assisté d’une équipe d’utilisateurs de haut niveau élabore une rapide étude d’opportunité où les aspects valeur ajoutée et retour sur investissement sont les premiers critères à évaluer.
   
   L’étude d’opportunité permet :
   
   
   1. Le positionnement du projet (enjeux, objectifs),
   2. Le bilan critique de l’existant,
   3. La définition globale des besoins,
   4. La compréhension des contraintes,
   5. La remise en cause des orientations technologiques,
   6. La prévision des impacts sur l’organisation,
   7. L’évaluation des ressources à engager,
   8. L’analyse des risques encourus,
   9. La planification des principales échéances.
   
   
2. Phase de Design
   
   Cette phase définit le système à l’aide d’un AGL de conception. Animateur, utilisateurs significatifs et concepteurs-développeurs modélisent traitements et données en s’appuyant sur le modèle classique entité-relation. Un premier niveau de prototype conclut cette phase.
   
   Un plan de travail type d’une session de design se découpe ainsi :
   
   
   1. Détailler les procédures principales,
   2. Construire un diagramme des flux,
   3. Découper les fonctions en traitements,
   4. Décomposer les traitements en modules,
   5. Créer le prototype premier niveau.
      Concevoir et développer RAD implique de disposer des outils AGL les plus performants. La souplesse de ces produits autorise de réaliser les opérations en direct lors des entretiens de prototypage, avec la participation des utilisateurs.
   
   Le RAD ne remplace pas la modélisation du système mais respecte les principes de conduite moderne de l’évolution. La puissance des nouveaux AGL et SGBDR autorise une approche méthodologique simplifiée. Le formalisme d’un référentiel minimum peut être Gane & Sarson (DFD) ou celui des modèles Merise :
   
   
   1. Modèle de Contexte.
      
      Le MC définit les frontières de l’étude et met en évidence, à un niveau très général, les flux d'information échangés entre les acteurs externes, le domaine d'étude et les domaines connexes. Il répond à la question : « quels sont les acteurs et éléments environnants du système ? ».
      
      
   2. Modèle Conceptuel de Communication.
      
      Le MCC structure les communications, répertorie les acteurs, documents et flux ; il identifie les concepts de sécurité.
      
      
   3. Modèle Conceptuel des Données.
      
      Le MCD dégage la structure générale entités-relations dans le respect des principes formels de normalisation. Un dictionnaire des données détaille les attributs de chaque entité.
      
      
   4. Modèle Conceptuel des Traitements.
      
      À partir du MCC et du MCD, le MCT détermine les concepts globaux de traitements, ultérieurement affinés.
      
      
   5. Modèle Organisationnel de Traitements.
      
      Le MOT est une représentation de l'activité de l'organisme étudié qui prend en compte :
      
      
      • La représentation des traitements entre l'homme et la machine,
      • La période de déroulement de chaque tâche,
      • La répartition de la responsabilité de ces traitements (tâches) au niveau des microstructures : services, départements, divisions, poste de travail, bureaux, …
      
      Le modèle organisationnel des traitements consiste donc à représenter le modèle conceptuel des traitements dans un tableau dont les colonnes sont la durée, le lieu, les responsables et ressources nécessaires à une action.
   
   
3. Phase de Construction
   
   Cette phase réalise l’application, affine le prototype, fusionne les étapes classiques. La prise de décision est immédiate et la validation, continue. Une charte graphique doit avoir été validée, des normes de programmation employées, un modèle de transaction généralisé à tous les modules et le cadre d’une méta-application aura été si possible respecté.
   
   « La perfection d’un système d’information réside dans sa capacité à rendre l’information totalement disponible. » Cette facilité s’exprime à travers des applications simples à utiliser.
   
   La spécification détaillée et la réalisation intègrent les fonctions de conception, de développement et de validation dans un processus permanent de collaboration avec l’utilisateur.
   
   L’utilisateur devient réellement le concepteur, il s’affirme comme le vrai maître de son application et s’en approprie la réalisation, il détermine les fonctionnalités et impose la dynamique applicative. L’informaticien devient "prototypeur", il maîtrise les outils de réalisation et représente une force de proposition technologique.
   
   Une équipe RAD est avant tout autonome et responsabilisée : autonome dans les choix techniques des solutions et responsabilisée dans la performance de réalisation qui en découle.
   
   Plusieurs itérations journalières sont possibles, et l’on réalise en concevant, tout en testant ce que l’on réalise. L’efficacité génère plus de fonctionnalités ou réduit le cycle de production.
   
   La conception utilise les mêmes mécanismes intellectuels que la programmation à un niveau d’abstraction plus élevé. En agglomérant la conception et la réalisation, le RAD fusionne le travail de l’analyste et du programmeur. La vrai clé de la productivité est le développeur de haut niveau qui sait intégrer la conception détaillée et la réalisation.
   
   Contrairement à des idées reçues, les programmeurs excessivement compétents et techniques sont à éviter, tout au moins lorsqu’ils s’attachent à mettre en œuvre l’intégralité de leur astucieux savoir. En effet, les langages de développement disposent d’un nombre impressionnant de fonctions complexes. La diversité des solutions possible est telle que la maintenance d’un module réalisé par un « top » développeur peut devenir presque inexploitable après son départ.
   
   La clé de la réussite consiste à maintenir constamment l’application dans un état connu, livrable. Microsoft a nommé cette technique : les jalons ZD (Zéro Défaut). Dans ce contexte de qualité, la livraison réelle est simplement le dernier jalon du projet.
   
   Augmenter les ressources est une solution parfois efficace mais s’avère souvent être un piège lorsqu’elle est employée systématiquement. L’ajout inopportun d’individus à un projet peut produire un ralentissement du travail en cours.
   
   Structures et composants d’une application
   
   Schématiquement, on retrouve les modules suivants :
   
   
   • initialisation, gestion de la sécurité, personnalisation,
   • menus de navigation,
   • aide en ligne contextuelle,
   • modules fonctionnels, gestion du spécifique,
   • gestion généralisée des évènements, des erreurs,
   • gestion des formes d’accès aux données,
   • interface d’intégration.
   
   Étapes fonctionnelles
   
   Concevoir, c’est réaliser : Fonctionnellement, le prototype RAD évolue d’un simple dessin d’écran vers le module finalisé. Durant cette évolution, on implémente les fonctions génériques et spécifiques, le découpage en niveau réduisant le risque fonctionnel. Les itérations valident l’adéquation du produit au besoin, et la réalisation est progressive en complexité. En cas dévolution de la demande, la réactivité est immédiate et les validations permanentes. Le site pilote est naturellement implanté et l’utilisation partielle est envisageable, car l’utilisateur connaît le niveau de complétude. Le projet est réduit en charge, mais surtout en délais.
   
   Itérations
   
   La seule phase itérative, si l’on peut dire, c’est le cycle de gestion. Chaque nouveau cycle offre au développeur l’opportunité d’affiner les fonctionnalités existantes et d’en ajouter de nouvelles.
   
   Les fonctionnalités primordiales sont traitées les premières, les améliorations sont ensuite implémentées et validées. Les utilisateurs testent en réel, les détails étant ajustés immédiatement.
   
   Normes de réalisation
   
   Le RAD s’appuie sur une normalisation draconienne qui a pour but la cohérence et la productivité des développements. Elle permet la réutilisabilité et facilite la maintenance.
   
   Les normes couvrent :
   
   
   • la déclaration du nom des objets et des champs,
   • une sécurité généralisée inclue dans chaque module,
   • une procédure générique de gestion des erreurs,
   • des règles d’utilisation,
   • une norme de documentation adaptée au projet.
   
   Normalisation sémantique et syntaxique
   
   Afin d’être efficace dans un contexte de développement, le vocabulaire est réduit et se base sur des mots clés courts mais significatifs. Les mots ainsi définis font l’objet de listes et de références croisées.
   
   Chaque abréviation doit être rapidement compréhensible. Les règles sont décrites avec souplesse :
   
   
   1. Prendre l’abréviation usuelle quand elle existe,
   2. Prendre les 3, 4 ou 5 premières lettres du mot,
   3. Si la dernière lettre du mot est une voyelle, prendre la première lettre du mot et la dernière syllabe,
   4. Si la dernière lettre du mot est une consonne, prendre la première syllabe et la dernière consonne,
   5. Utiliser des abréviations spécifiques.
   
   Documentation
   
   On distingue trois types de documentation :
   
   
   1. Projet : Les spécifications de programmation se décrivent au cours du prototypage. La documentation technique de réalisation est incorporée aux modules, objets et procédures événementielles dont elle décrit les fonctions. Immédiatement localisable et mise à jour naturellement, elle est enfin réellement exploitable. Il faut faire disparaitre la notion de dossier de programmation, tout en améliorant réellement les conditions de maintenance.
   2. Technique : La documentation technique est maintenant gérée dans les AGL de conception et de réalisation.
   3. Utilisateur : La meilleure des documentations est une aide contextuelle. Les documents produits ont une mise en page « type » et normalisée ISO.
   
   Design d’écran type
   
   Les modules et écrans exigent une homogénéité de leur design. Trois règles régissent, sur le plan ergonomique, la construction d’un standard formel de dessin d’écran :
   
   
   1. Règles relatives à la conception des écrans,
   2. Règle relatives à la fonctionnalité des accès et à la sécurité,
   3. Règles relatives aux validations et traitements communs.
   
   Formation des utilisateurs
   
   Les utilisateurs participant au développement au RAD sot une ressource de support. Ils sont formés à transmettre leur connaissance à leurs collègues. Ils fourniront les explications et les raisons ayant conduit au design et aux fonctionnalités retenues.
   
   Maintenance et évolution
   
   La maintenance et l’évolution sont des parties intégrantes du cycle de vie du système. Elles imposent au mainteneur une grande discipline, car le volume d’informations à manipuler est considérable. La cohérence avec le cycle de programmation doit être maintenue à travers cette activité. Fréquemment au contact des utilisateurs réels du système, le mainteneur doit avoir le sens du contact et de très bonnes relations humaines.

■ Récapitulatif des règles d’efficacité d’un projet RAD

Principes

Formaliser l’approche méthodologique dans un document détaillant la mise en œuvre : « dire ce que l’on fait, écrire ce que l’on dit et faire ce que l’on a écrit. »

Salle RAD

Prévoir une salle spéciale « communicante ».

Animateur

Disposer d’un spécialiste neutre, formé aux techniques d’entretien de groupe, maîtrisant les principes de modélisation RAD.

Formation

Former les utilisateurs significatifs et les représentants de la maîtrise d’ouvrage à la lecture des modèles (entités-relation, hiérarchie de fonction).

Maîtrise d’œuvre

Les rapporteurs RAD savent synthétiser et modéliser en live le discours utilisateur.

Normalisation RAD

Disposer :

• d’un modèle de transaction standard,
• d’une méta-application,
• d’une charte graphique,
• de normes de codage,
• de normes documentaires,
• d’un dictionnaire d’abréviation du vocabulaire du métier.

Verrouillages

Respecter le verrouillage formel des cadrages et de la modélisation avant de procéder à la construction.

Disponibilité des utilisateurs

La maîtrise d’ouvrage engage contractuellement la disponibilité des utilisateurs.

Coordination du projet

Créer des équipes de concepteurs-développeurs autonomes et responsabilisées travaillant en « coordination plate », c’est-à-dire sans chef de projet.

Outils AGL

Disposer d’outils pour produire et gérer simplement et automatiquement :

• un modèle de communication,
• une hiérarchie de fonctions,
• une évaluation de projet,
• une planification,
• un modèle de données,
• un prototype,
• une installation de logiciel,
• une documentation intégrée.

Poste de travail

Fournir aux développeurs des outils de réalisation performant, l’autonomie technique et financière nécessaire.

Organisation

Un spécialiste en organisation (reengineering) étudie les documents et circuits définis lors du cadrage avant d’engager les phases de design et de construction.

III BIBLIOGRAPHIE

▲ II-3.1. PRINCIPES PHILOSOPHIQUES : Citations, proverbes
► III-1. BIBLIOGRAPHIE : RAD - Développement Rapide d'Applications
▼ III-2. BIBLIOGRAPHIE : LA PROGRAMMATION RATIONNELLE