32
Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative. Jean-Pierre Vickoff, RAD.fr

Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

Embed Size (px)

Citation preview

Page 1: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

Méthode RADÉléments fondamentaux

Le Développement Rapide d'Applications

Organisation des développements,conduite de projets,ingénierie applicative.

Jean-Pierre Vickoff, RAD.fr

Page 2: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 2

© 2000, Jean-Pierre Vickoff, RAD.fr

Méthode

RAD

Le Développement Rapide d'Applications

Jean-Pierre VickoffRAD.fr

Page 3: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 3

© 2000, Jean-Pierre Vickoff, RAD.fr

SOMMAIRE DU DOCUMENT

MÉTHODE RAD 1

1. MÉTHODE DE DÉVELOPPEMENT LOGICIEL RAD 5

1.1. Structure de développement 51.2. Description globale des phases 61.3. Approfondissement des phases 71.4. Phase INITIALISATION 81.5. Phase CADRAGE 91.6. Phase DESIGN 101.7. Phase CONSTRUCTION 141.8. Phase FINALISATION 171.9. Objectifs et travaux par phase 171.10. Principaux documents par phase 25

2. BIBLIOGRAPHIES ET RÉFÉRENCES 26

2.1. Bibliographie RAD, Conduite de projet 262.2. Bibliographie Objet 262.3. Bibliographie Management, Qualité 262.4. Divers documents, normes, standards 272.5. Principaux WEB et contributeurs 282.6. Index 292.7. Figures 312.8. Tableaux et listes 31

Page 4: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 4

© 2000, Jean-Pierre Vickoff, RAD.fr

RAD, méthode pour une

conduite de projet

« haute performance »

« Il est vrai que pendant que je ne faisois que considérer les mœurs desautres hommes ... que le plus grand profit que j'en retirois étoit que,voyant plusieurs choses qui, bien qu'elles nous semblent fortextravagantes et ridicules, ne laissent pas d'être communément reçueset approuvées par d'autres grands peuples. »

René Descartes, Discours de la méthode

Page 5: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 5

© 2000, Jean-Pierre Vickoff, RAD.fr

11.. MMéétthhooddee ddee ddéévveellooppppeemmeenntt llooggiicciieell RRAADD

La méthode RAD et le Processus Qualité RAD2, impliquent 3 intervenantsprincipaux (MOA, MOE, GAR1).

Pour la maîtrise d’œuvre les grandes phases de la démarche sont :

§ Initialisation (mise en condition de l’organisation).

§ Cadrage (expression des objectifs).

§ Design (conception du futur système).

§ Construction (développement de l’application).

§ Finalisation (livraison des fonctionnalités attendues).

Le projet est piloté selon un suivi rigoureux des contraintes, des risques et de laqualité technique.

La maîtrise d’ouvrage doit assurer :

§ L’expression des exigences et sa validation permanente.

§ La préparation au changement organisationnel.

§ La recette fonctionnelle et technique.

§ Le démarrage.

Le projet est piloté selon un suivi rigoureux de la qualité fonctionnelle (rapport deFocus, suivis des divergences). Le Groupe d’Animation et de Rapport prend encharge les communications et la formalisation des informations.

1.1. Structure de développementLa structure méthodologique du projet s'appuie :

§ la méthode RAD et son cycle semi-itératif2 en ce qui concerne les principesfondamentaux de conduite de projet ;

§ le processus RAD2 pour l’ordonnancement pratique des opérations dedéveloppement ;

§ une techniques de modélisation adaptée à la typologie de l’application (Merise /UML / Flux / etc.).

Pour rappel (et en synthèse), la méthode RAD implique :

1. Un cycle de développement sécurisant et court fondé sur un phasage simple :Cadrage, Design, Construction et l’absolu respect d’une dimension temporelle(90 jours optimum, 120 jours maximum) [Martin 1991]3.

2. Une architecture de communication engageant des groupes de travail destructure et de composition variable selon les besoins des phases et respectant un

1 Maîtrise d'ouvrage, maîtrise d’œuvre, Groupe d'Animation et de Rapport2 Merise ou SDMS utilisent un cycle en cascade, alors que DSDM ou RUP préconisent un cycletotalement itératif.3 Les trois premiers points définissent les principes de la méthode RAD telle que James Martinl’avait conçue dès la fin des années 80.

Page 6: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 6

© 2000, Jean-Pierre Vickoff, RAD.fr

mode opératoire précis structuré en trois étapes : pré-session, session, post-session [Mucchielli 1987].

3. Des méthodes, techniques et outils permettant de définir et d’appliquer deschoix portant sur quatre natures d'objectifs potentiellement contradictoires :budget, délais, qualité technique, qualité fonctionnelle et visibilité4 [Vickoff 1998].

4. Une architecture de conception s’appuyant sur les techniques de l'objet etparticulièrement sur celles qui permettent une conception « en vue demodifications » [McCarty 1997].

5. Une architecture de réalisation qui impose, pour garantir la qualité technique,des normes minimales, des revues de projet, des jalons zéro-défaut5 et quirecommande, pour garantir la qualité fonctionnelle, le prototypage actif et lesFocus6 de visibilité [McConnell 1996].

1.2. Description globale des phasesLa méthode RAD structure le cycle de vie du projet en 5 phases :

§ L’Initialisation définit l’organisation, le périmètre et le plan de communication.

§ Le Cadrage définit un espace d’objectifs, de solutions et de moyens.

§ Le Design modélise la solution et valide sa cohérence systémique.

§ La Construction réalise en prototypage actif (validation permanente).

§ La Finalisation est un contrôle final de qualité en site pilote.

Mise en condition de l’organisationMise en condition de l’organisation

Interviews de groupeExpression des besoins

Interviews de groupeExpression des besoins

Qualité et support site piloteQualité et support site pilote

Mise en opération du SWATMise en opération du SWAT

Création d’un état de livraisonpermanente pour 1er FOCUS

Création d’un état de livraisonpermanente pour 1er FOCUS

Spécification

RéalisationValidationModélisation du systèmeModélisation du système

Figure 1. — Jalons décisifs du cycle projet RAD

Dans un second niveau de détail (figures 1 et 2), ces phases comprennent :

1. INITIALISATION (préparation de l’organisation et communication )

Cette phase permet de définir le périmètre général du projet, de structurer le travailpar thèmes, de sélectionner les acteurs pertinents et d’amorcer une dynamique deprojet. Cette phase représente environ 6% du projet en charge.

4 Visibilité = capacité de contrôle offerte aux responsables.5 Jalon zéro-défaut (ZD) : jalon du projet intégrant une validation technique, une intégration etune validation fonctionnelle par l'utilisateur.6 Focus : réunion plénière de présentation débouchant sur une validation globale.

Page 7: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 7

© 2000, Jean-Pierre Vickoff, RAD.fr

2. CADRAGE (analyse et expression des exigences)

La spécification des exigences est du ressort des utilisateurs. Ils expriment leursbesoins lors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours desessions par commission (thème). Cette phase représente environ 9% du projet.

3. DESIGN (conception et modélisation)

Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage età la validation des modèles organisationnels : flux, traitements, données. Ils validentégalement le premier niveau de prototype présentant l’ergonomie et la cinématiquegénérale de l’application. Il est prévu entre 4 et 8 jours de sessions par commission.Cette phase représente environ 23% du projet. A partir de la phase de Design laparallélisation du travail est possible (figure 3).

4. CONSTRUCTION (réalisation, prototypage)

Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module parmodule. L’utilisateur participe toujours activement aux spécifications détaillées et à lavalidation des prototypes. Plusieurs sessions itératives sont nécessaires. Cette phasereprésente environ 50% du projet. A partir de la phase de Construction, à laparallélisation du travail peut s’ajouter la sérialisation (figure 3).

5. FINALISATION (recette et déploiement)

Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phased’officialiser une livraison globale et de transférer le système en exploitation etmaintenance. Cette phase représente environ 12% du projet.

Initialisation du projet etimmersion animateur &coordinateurs dans ledomaine fonctionnel

Initialisation du projet etimmersion animateur &coordinateurs dans ledomaine fonctionnel

2/1

120 jours

maximumRéunion de lancement etd’individualisation

Réunion de lancement etd’individualisation

CADRAGECADRAGE

GénéralisationGénéralisation

Entretienpropriétaire

Entretienpropriétaire

Site piloteSite pilote

Focus R1Focus R1

Focus R2Focus R2

Recette UtilisateursRecette Utilisateurs

Focus R3Focus R3

DESIGNDESIGN

15/1 18/1 1/2 18/2 10/4 10/5 30/7 20/8 1/930/5 30/6

CONSTRUCTIONCONSTRUCTION

Focus CFocus C

Focus DFocus D

Figure 2. — Principales étapes d’un cycle de projet à 120 jours

1.3. Approfondissement des phasesVoici pratiquement et succinctement comment se déroule un projet RAD.

La première des conditions réside dans la présence d’un animateur ou d’uncoordonnateur maîtrisant parfaitement tous les aspects du RAD. Dans les projets oùdes dissensions pourraient apparaître entre les différents interlocuteurs, ce spécialistede l’entretien de groupe doit nécessairement être neutre. Fonctionnellement, troiscatégories d’intervenants participent à un projet RAD : ceux « pour action » qui sontconvoqués, ceux « pour validation » qui sont souhaités et ceux « pour information »qui peuvent s’inviter.

Il est illusoire de vouloir développer avec des ressources à temps partiel un projetstratégique ou sous contrainte de temps.

Page 8: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 8

© 2000, Jean-Pierre Vickoff, RAD.fr

La maîtrise d’ouvrage doit s’investir aussi régulièrement dans la validation de safuture application (prototype7) que la maîtrise d’œuvre le fait dans la production.

Seul le respect de ces conditions de communication permettra aux développementsmodernes de sortir de leur enlisement actuel. Lorsque la charge de travail ainsi dédiéeà la spécification et au prototypage est trop importante pour la maîtrise d’ouvrage etdéséquilibre sa production opérationnelle, des ressources supplémentaires lui sontaffectées. Leur coût est inclus dans le budget global du projet. Le retour surinvestissement de ce recouvrement de fonction est chiffrable et positif. Une desmissions de l’animateur est de justifier l’impact de chaque action en termes de retoursur investissement.

L’animateur, en plus de son rôle de facilitateur, est le garant du respect de la méthode.Il informe les maîtrises des écarts observés et de leur conséquence sur la stratégieinitialement décidée. Il forme les intervenants, contrôle la planification,l’ordonnancement des tâches et le suivi de leur exécution. Il s’assure de l’efficacité desentretiens (participation, progression, centrage des thèmes, respect des priorités) et dela performance de l’environnement technologique, méthodologique.

Afin de soutenir l’évolution positive des motivations et la dynamique d’équipe, desmoyens matériels sont à sa disposition : budget pour actions incitatives aurenforcement de la cohésion interpersonnelle, amélioration du cadre de travail,assouplissement des contraintes matérielles, prise de décision démocratique, primesur atteinte d’objectifs.

L’animateur est « neutre » vis-à-vis des deux maîtrises et cette neutralité doit le fairedépendre de la direction générale [Boehm 1998] ou d’une instance arbitre entrel’informatique et la direction utilisatrice.

1.4. Phase INITIALISATIONLa phase d’Initialisation a pour objectif d’informer les intervenants des contraintesd’un projet RAD.

Après une courte Immersion dans le domaine fonctionnel, le pilote, les coordinateurset l’animateur présentent aux dirigeants et à la maîtrise d’ouvrage les contraintes de laméthode et le plan d’action à respecter. Un plan de communication est produit.

Cette étape a pour nom l’Entretien propriétaire. Si nécessaire, une opération deréingénierie des procédés « métier » précède l’automatisation du domaine.

Une Réunion de lancement du projet est ensuite organisée. Elle regroupe tous lesacteurs recensés et donne lieu à l’individualisation des travaux préparatoires, à laspécification des exigences de la future application et à sa modélisation. Dans le cadredu plan de communication, les utilisateurs sont répartis dans des groupes de travail8

organisés par thèmes. Cette étape doit s’effectuer en quelques dizaines de minutes.

Il faut distinguer le principe des groupes de travail de celui des Focus. :

7 Le prototype est un état intermédiaire du développement. C'est une version opérationnelle del'application en cours d'amélioration. Le prototype est un système, éventuellement trèsincomplet, mais dans son dimensionnement réel. Dans le respect de règles strictes deconstruction, il est utilisable en fonctionnalités partielles. Il constitue un ensemble minimum,mais viable, de fonctions représentatives.

Le prototype se transforme progressivement en exécutable, limité dans un premier temps ausite pilote. Après recette fonctionnelle et technique, le déploiement et la montée en chargeconsacrent leur version finale. Le prototype continue par la suite à être amélioré. Cettecontinuité dans l'évolution s'appelle la maintenance applicative.8 Le travail de groupe implique la disponibilité totale et permanente de tous les participants,particulièrement des décisionnaires. Ce point doit être explicitement reconnu par les membresdu groupe et par leur encadrement.

Page 9: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 9

© 2000, Jean-Pierre Vickoff, RAD.fr

§ Un groupe de travail réunit généralement moins de dix personnes qui concourent àl'analyse d'un problème et à l'élaboration de la solution.

§ Un Focus peut rassembler un nombre élevé de participants pour unesensibilisation, une prise de connaissance ou un jugement général (validation) surle produit en cours de réalisation.

Les utilisateurs associés en permanence à un développement RAD doivent être engrande partie les réels exécutants des tâches à automatiser.

Le choix des utilisateurs participant au projet est fonction de leur motivation affirmée(pour les deux tiers d’entre eux). Ce point est essentiel au RAD, les futurs clients dusystème représentent une force de proposition fonctionnelle.

L'entretien de groupe est la meilleure forme de réunion pour déterminer lesfonctionnalités générales d'un système. Lorsque celui-ci est conséquent, un individuisolé a difficilement une vue d'ensemble objective et complète. Parfois, pour réaliserdes fonctions identiques, les méthodes de travail sont différentes d'un participant àl'autre. L'analyse commune des diverses pratiques aboutit à un consensus sur la plusefficace. L'interview de groupe, par la communication qu’il suscite, éveillenaturellement la réflexion, l'évolution, le progrès dans la recherche d’amélioration dela qualité.

La réunion de lancement (d’une demi-journée à une journée) est souvent considéréecomme le lancement officiel du projet RAD. A l'issue de la réunion de lancement, lesparticipants disposent de quelques jours pour réaliser la préparation de la premièreréunion de Cadrage dont la date est fixée.

1.5. Phase CADRAGEIl est inutile d’engager des ressources humaines de qualité et coûteuses si lesressources matérielles (salle, vidéoprojecteur, micros, logiciels) ne sont pasdisponibles. Le coût direct et la démotivation résultant de ce genre de situationsont tels que le qualificatif « RAD » peut être oublié.

Lors du CADRAGE auquel participent les décideurs, l’animateur obtient leverrouillage des exigences, des budgets, des délais et de la solution globale sur lesplans stratégique, fonctionnel, technologique et organisationnel.

Dans le cas où les exigences et les ressources divergeraient, il faut attribuer despriorités aux fonctionnalités en termes de retour sur investissement. Cettemodélisation des traitements peut s’effectuer sous la forme d’une hiérarchie defonctions et/ou suivant le principe des cas d’utilisation.

Le cadrage nécessite des équipes de taille intermédiaire9, incluant des utilisateurs detous niveaux. Le processus est le suivant :

§ dans chaque domaine, les thèmes principaux sont déterminés ;

§ dans le cas d’un domaine stable, il n’est pas nécessaire de réaliser une étudedétaillée de l’existant en session plénière ;

§ dans les domaines où les fonctionnalités sont instables, un effort de réflexiondevra être engagé et le cercle d’interlocuteurs élargi.

Modéliser en direct avec un vidéoprojecteur électronique. Dans le principe, lamodélisation concrète des flux et des fonctionnalités devra être engagée le plus tôtpossible avec un outil adéquat.

9 Taille des groupes : Cadrage jusqu’à une douzaine d’utilisateurs ; Design de un à sixutilisateurs ; en Construction un ou deux utilisateurs ; lors des Focus tous les intervenants sontconviés.

Page 10: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 10

© 2000, Jean-Pierre Vickoff, RAD.fr

La durée des sessions de Cadrage est d’une demi-journée ou d’une journée. Il estpossible en cas de contraintes de délais de réaliser des sessions pouvant atteindre 5jours. Le Cadrage complet peut alors être réalisé en une seule session. Les sessions deCadrage engagent simultanément les informaticiens de conception-développement (leSWAT) et les utilisateurs. Seules les validations d’un ensemble conséquent modélisénécessitent un Focus.

En général, les groupes d'utilisateurs qui participent aux séances de définition de lafuture application sont limités à quelques personnes significatives. Pour améliorer lacouverture de cette activité et lever un maximum de risques, il est souhaitabled'élargir la base de participants dans le cadre d'une consultation préalable. Cetteapproche s'avère généralement efficace et est indispensable dans le cadre d'unmanagement par la qualité de service (MTQS). Avant la réunion officielle, on engageradonc une réflexion sur l'ensemble des thèmes composant le domaine applicatif.

CADRAGE

DESIGN

DESIGN

CONSTRUCTION

CONSTRUCTION

30, 60, 90 ou 120 Jours maximum

Pré

para

tion

Fin

alis

atio

n6% 23% 50% 12%9%

Parallélisation Sérialisation

Figure 3. — Phasage et parallélisation (grand projet)

1.6. Phase DESIGNLa phase suivante, le DESIGN, repose sur la disponibilité d’un AGL de conceptionléger et puissant. Cet outil est utilisé « en direct », dans une salle spécialement équipéede moyens de vidéoprojection et de communication. Sous la coordination del’animateur, les utilisateurs significatifs et les concepteurs-développeurs travaillentalors en commun et en direct à la modélisation détaillée des traitements et des donnéesde l’application. La présentation d’un premier niveau de prototype conclut cettephase.

Le RAD s’appuie sur les techniques dérivées de l’objet et préconise unearchitecture à « modèles variables » ainsi qu’une conception « en vue demodifications ».

Le concepteur s’attache à mettre en œuvre une conception « en vue de modification ». Ilutilise un niveau d’abstraction élevé et définit initialement un modèle de données,suffisamment généraliste, pour couvrir en un seul axe de structuration l’ensemble dumétier de l’organisation ou la partie concernée par le système. Le noyau stable acquis,il modélise en couches périphériques la variété de traitements permettant de mettre enœuvre des stratégies opérationnelles. En cas d’évolution, il suffit d’adapter la coucheconcernée. Ces concepts sont repris et détaillés dans les paragraphes suivants.

Modéliser avec un niveau d’abstraction « métier » est le meilleur moyen de repousserles limites d’un existant et de garantir les capacités d’évolution ultérieure del’applicatif. Par ailleurs, un système basé sur une structuration « métier » des donnéeset sur une stratification des traitements dispose d’une grande capacité d’évolution

Page 11: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 11

© 2000, Jean-Pierre Vickoff, RAD.fr

d’une pérennité exceptionnelle. Cette approche s’avère plus facile à développer malgrésa généralité :

§ les parties les moins sujettes à évolution sont réalisées en premier ;

§ les autres parties sont planifiées dans un ordre dicté par leur stabilité.

Le but est d’obtenir tous les modules du système simultanément disponibles aumoment du déploiement.

Abstraction, structuration, isolation, cohésion, modularité, généralisation,encapsulation et surtout dissimulation sont les techniques de base de la modélisationqui permettent la mise en œuvre d’une architecture de conception évolutive. AvecUML, la modélisation Objet propose les « cas d’utilisation ». De nombreux outilssupportent maintenant cette approche (figure 4).

Figure 4. — Modélisation UML des exigences (Paradigm Plus)

Plaidoyer pour une modélisation simple et cohérente

Modéliser10 les activités de l’entreprise étendue nécessite des techniques et des outilsaussi puissants que simples d’usage. Lors de la conception d'une application classiquede gestion, la préoccupation première de l'informaticien est généralement d'élaboreravec l'utilisateur la description de l'architecture applicative représentée par unmodèle synthétique mais exhaustif du domaine à considérer. Cette architectureapplicative prend toute son importance avec l'évolution typologique des projets. Eneffet la tendance actuelle est à la transversalité des solutions informatiques (ERP11,Supply-Chain12) et le nombre de composants et d'interfaces avec les autres élémentsdu système d'information se multiplie.

Pour être pratiquement utilisable, le modèle représentatif d’une architectureapplicative doit permettre une vision simultanée des acteurs et des événements quiconditionnent leurs actions ainsi que des procédés employés et de leur séquenced'exécution. Les dépendances fonctionnelles et organisationnelles sont alors mises en

10 Modélisation : représentation théorique d'un système dans le but d'en maîtriser la complexitéau prix d'une certaine réduction du détail.11 Entreprise Ressource Planning.12 Ensemble de tous les composants (maillons) impliqués dans la production et concourant àson efficacité et à sa qualité.

Page 12: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 12

© 2000, Jean-Pierre Vickoff, RAD.fr

évidence. Bien entendu, la globalité de l’information manipulée doit aussi apparaître.L’ensemble permet de révéler les interfaces des sous-systèmes avec les autres(dépendances organiques).

A ce jour, trois possibilités sont offertes à l'informaticien pour représenter et réduire aumieux cette complexité : l'approche française Merise, l'approche américaine par lesflux (DFD13, Gane & Sarson, SASD14) et, depuis peu, UML15 qui consacre la fusion desprincipales approches « Orientées Objet ».

Modéliser permet de réduire la complexité pour la maîtriser, néanmoins le modèle nereprésente pas, dans l'état actuel de nos outils, la réalité de la solution. Lamodélisation, si elle s'avère souvent indispensable, n'en reste pas moins une opérationqu'il faut considérer comme parasitaire en regard de la fourniture des fonctionnalitésréelles.

Dans ces conditions, le défi imposé alors par la performance est l'obtention d'unevision complète du SI en un seul modèle.

L'analyse d'un système d'information de gestion révèle l'omniprésence des données àtous les niveaux de décomposition des traitements. Ces données ne doivent cependantpas être trop détaillées afin de préserver la lisibilité du modèle. Un outil demodélisation efficace doit donc être susceptible de représenter une décomposition destraitements intégrant leur environnement d'exécution et de disposer d'un accès sous-jacent au référentiel des données. Ce référentiel est décrit selon une approcherelationnelle ou objet.

Merise s'appuie sur la dichotomie de trois niveaux de préoccupations (données,traitements, communication) et de multiples niveaux d'abstraction (conceptuel,organisationnel, logique ou physique). Merise impose la production et la validationcroisée d'un nombre rebutant de modèles, aussi cette méthode ne convient plus auxexigences générales des projets actuels. Le concept objet qui associe données ettraitements semble théoriquement plus proche, mais il impose dans la réalité de lamodélisation de multiples formes de représentation complémentaires. La gymnastiqueintellectuelle permettant de « zapper » d'une vue à l'autre n'est pas encore à la portéed'un utilisateur même averti soucieux de valider simplement son futur système.

Avec les outils actuels, il semble donc impossible d'obtenir une représentationexhaustive, détaillée, compréhensible, simple et structurée à la fois des informations,de leur environnement et des procédés utilisés pour les manipuler. Si l'OO16 avec UMLreprésente certainement le futur normalisé de la modélisation, il est indispensable quedes outils simples et puissants viennent en faciliter la mise en œuvre. Les outils enquestion devront permettre une représentation de la réalité unique doncmultidimensionnelle. En attendant, il faut l'admettre, seule l'approche par les flux (encomplément de la description relationnelle des données) est suffisamment puissante etoutillée pour atteindre raisonnablement et économiquement ce but et permettre delever le risque inhérent à l'absence de modélisation auxquels sont toujours soumis denombreux projets.

13 Data Flow Design.14 System Analyse System Design.15 Unified Modeling Language.16 Orienté Objet.

Page 13: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 13

© 2000, Jean-Pierre Vickoff, RAD.fr

Modélisation dynamique et évolution stratégique

Sur le plan pratique les buts et les formes de modélisation sont remis en question.

Le concepteur assimile la divergence du statique et du dynamique, de ce quireprésente le cœur du métier et de ce qui est imposé par l’évolution. Il doit privilégier,mais sans la rendre unique, l’approche par les processus bien qu’elle ne représentequ’une vision momentanément figée de l’organisation (c’est à travers l’axe des flux quel’organisation évolue).

Avec la généralisation d’une modélisation « métier » (systématique dans tout projetObjet), la notion d’informatique et d’organisation, dont l’application consistait le plussouvent à reproduire avec la dernière technologie un existant insatisfaisant, renouvelletotalement son « approche » du changement.

Une vision économiquement viable de la réactivité d'un SI impose de le concevoir envue de sa « modification permanente17 ». Il est alors préférable, comme d’ailleurs lesméthodes objets le préconisent, de figer initialement la vision statique, c’est-à-dire ladescription des données. Cette vision est plus stable dans le temps, car elle représentele « métier » de l’organisation. La capacité de généraliser suffisamment la descriptionde ces données permet d'obtenir un noyau de base dont les risques de remise enquestion sont limités à un changement fondamentalement du métier de l’organisation(type de services ou de produits). L’ensemble des descriptions représente la mémoiredes processus de l’entreprise.

Dans un contexte concurrentiel, si l’architecte du système d’information dispose d’unniveau d’abstraction suffisant, il définit en premier un modèle des donnéessuffisamment généraliste pour couvrir en un seul axe de structuration l’ensemble desactivités prises en compte par le système. Cela conduit à une représentation uniquedescriptive de l’activité.

Le noyau stable acquis, on développe en couches périphériques la variété detraitements permettant de mettre en œuvre des pratiques agressives. En casd’évolution, il suffit d’adapter la couche concernée, le noyau de données restantinchangé.

Un système basé sur une structuration métier, des données et une stratification destraitements dispose d’une très grande capacité d’évolution et donc d’une pérennitéexceptionnelle. Il est aussi plus facile à développer, même s'il paraît global. En effet, onréalise en premier les parties les plus stables dans le temps, celles qui seront les moinssujettes à évolution, puis on développe ensuite les autres dans l’ordre de leur stabilité.Les multiples modules du système sont alors rendus simultanément disponibles aumoment du déploiement général.

Les formes de la modélisation transdomaines

Dans la plupart des systèmes ne concernant qu’un seul domaine, la modélisationdes flux n’est pas primordiale ; seule est fondamentale la modélisation des données.Par contre, dans l’architecture d’un système multi-domaines ou transdomaines, lamodélisation des flux prend une importance particulière.

Néanmoins, le plus souvent, il n'est pas utile de détailler le système au-delà d’uncertain niveau. Suivant la taille du système deux ou trois niveaux de décompositionsont suffisants. Dans le cas d’usage d’un outil permettant de modéliser les flux, il fautobtenir parallèlement une hiérarchie des fonctions18. C’est en partant de cettehiérarchie de fonctions que l’on détaille si nécessaire le modèle fonctionnel.

17 « en vue de modification », pratiques de conception et de réalisation d'une solutioninformatique orientées en vue de faciliter son évolution régulière.18 La représentation de la structure d'un SI ou d'une application sous la forme d'une hiérarchiede fonctions est la forme de modélisation la plus simple et la plus compréhensible pour un non-informaticien.

Page 14: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 14

© 2000, Jean-Pierre Vickoff, RAD.fr

Le prototypage utilisé par la méthode RAD19 déporte la partie détaillée desspécifications dans l’action de réalisation, aussi, le descriptif documenté est-il limité àl’indispensable (le juste suffisant).

Les flux permettent aussi de préciser une partie de l’information manipulée. Dans lescas les plus simples (en termes de complexité des relations entre données) on peut àtravers les flux modéliser totalement le système (workflow20). Une des raisons pourlesquelles il est préférable de ne pas trop détailler ces modèles est leur relativevolatilité. En effet, ils s’altèrent au rythme de l’évolution organisationnelle, voire despratiques commerciales. Seul le modèle des données le plus stable dans le temps, etd’ailleurs le plus concrètement utile en terme d’usage informatique, doit êtretotalement et parfaitement détaillé.

C’est donc dans la rigueur et la perfection du modèle de données et dans le choixjudicieux des principes et niveaux de décomposition des modèles de flux et de lahiérarchie de fonctions (traitements) que réside la performance de réalisation d’unsystème autant que son évolutivité.

Le temps des bricoleurs de la méthode et du développement s'achève. Le futur de laprofession se présente comme un défi industriel vital et passionnant.

1.7. Phase CONSTRUCTIONLa phase de CONSTRUCTION affine le prototype21. Elle fusionne les étapes classiquesde spécification détaillée, de réalisation (codage), de tests unitaires et de testsd’intégration, ainsi que la plus grande partie des tests de cheminement fonctionnel quiconstituent la recette initiale de l’application. Cette homogénéité constitue, avec laprise de décision immédiate et la validation permanente, les bases mêmes de laproductivité et de la qualité RAD.

Pour atteindre cette performance, les outils de Construction utilisés doivent êtrechoisis avec soin, une charte graphique doit avoir été validée, des normes deprogrammation employées, un modèle de transaction généralisé à tous les modules.

La validation permanente, comme son nom l’indique, est réellementpermanente. Elle s’effectue à chaque séance de travail avec l’utilisateur.

La validation permanente garantit lors de chaque ajout de fonctionnalité la conformitéau besoin. Le groupe de travail idéal comprend un membre du SWAT et un ou deuxutilisateurs.

Un développement RAD se distingue par la mise en œuvre de plusieurs techniques deréalisation.

§ SWAT : organisation d’une équipe de profil « concepteur-développeur » basée surla compétence, la complémentarité, l’autonomie et la démocratie.

19 RAD est une méthode axée sur la communication, la validation permanente de l'utilisateur etutilisant des pratiques formelles (processus et plan qualité RAD2, modes opératoires,architectures de conception et de réalisation, etc.).20 Workflow (flux de travail) : définit généralement un outil permettant de maîtriser la circulationdes informations entre leurs points d'élaboration.21 RAD est une méthode basée sur le partenariat. L'utilisateur s'affirme le vrai maître de sonapplication et, par sa participation active, il s'en approprie la réalisation. Le RAD et leprototypage permettent de réaliser en concevant, tout en testant ce que l'on réalise. Le résultatgarantit ce que l'on peut qualifier de « Really Approved Design » : une conception réellementapprouvée par les utilisateurs. Un bon développeur RAD utilise un langage ou outil de type« visual » et dispose d'une panoplie de customs-controls. L'ensemble représente un AGL deréalisation évolutif et ouvert. Les possibilités de cet AGL sont présentées aux utilisateurs avantla première séance de prototypage. De la diversité et de la puissance de ces outils peuventémerger des idées brillantes d'application. Des petits groupes d'utilisateurs sont délégués enassistance à la réalisation des fonctionnalités spécifiques (Construction Assistance Team).

Page 15: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 15

© 2000, Jean-Pierre Vickoff, RAD.fr

§ Normes de codage : normes publiées et acceptées visant à uniformiser lestechniques de codage.

§ Validation permanente : engagement continu des utilisateurs dans le prototypagelors de réunions informelles qui engagent un ou deux utilisateurs par concepteur-développeur.

§ Revue de code : principes planifiés et acceptés de vérifications croisées de laconformité des pratiques de codage aux normes publiées.

§ Jalons zéro-défaut (ZD) : technique orientée « planning » ; elle permet decontrôler l’avancement de l’application en matière de visibilité et de qualité. Desjalons ZD peuvent être, si nécessaire, planifiés entre les Focus. Ils correspondent àune revue du code suivie d’une intégration et d’une validation complète decheminement par l’utilisateur de base.

§ Focus : réunion plénière de présentation et de validation du projet dans toutes sesdimensions.

§ Etat de livraison permanente : une version de l’application est maintenue dans unétat livrable suite à un Focus ayant confirmé le jalon ZD. Elle peut être présentée àtout moment ou utilisée si nécessaire en fonctionnalités réduites.

§ Techniques de conception en vue de modifications : ont pour but de faciliterl’évolution ultérieure de l’application. Elles sont mises en œuvre lors de la phase deDesign. En phase de Construction il existe des techniques dont le but est similaire.L’ensemble de ces techniques a pour finalité de permettre une évolution continuedepuis la conception, la réalisation et jusqu'à la maintenance, prolongementnaturel de la vie d’une application.

§ Structure de Construction itérative et incrémentale : dès le début de la phase deConstruction un plan d’évolution du prototype est précisé. Il définit et segmentel’ensemble des fonctionnalités à produire, lors de chaque borne de validation,appelée Focus. La segmentation peut être verticale ou horizontale :

§ une segmentation verticale repose sur un simple découpage en modules ou enécrans ;

§ une segmentation horizontale se base sur la notion de priorité des fonctions etimpose souvent que l’ensemble des modules soit mis en chantiersimultanément, mais à un niveau de fonctionnalité limité.

La notion de Focus couvre en pratique l’enchaînement de plusieurs étapescontraignantes pour le SWAT (figure 5).

Le facteur décisif pour fixer la cadence des Focus doit être le nombre defonctionnalités additionnelles attendues.

Concrètement, un Focus débute par la planification d’une charge de travail à réaliserdans un délai précis (de 10 à 20 jours). Participent au Focus tous les acteurs du projet.Outre le travail de développement, la planification comprend la préparation du Focus,sa réalisation et le laps de temps nécessaire à l’exploitation des informations que cettemanifestation permet de dégager. L’organisation de la communication préalable auFocus est du ressort de l’animateur RAD.

Quelques jours avant la date fixée pour le Focus, en fonction de l’avancement validé,le coordonnateur technique stoppe les développements. Les utilisateurs ayantparticipé aux séances de spécification et de validation permanente sont alors impliquésdans une étape de vérification de la qualité fonctionnelle. Le maximum de correctionsde divergences visuelles ou mineures doit être effectué. En général, la validationpermanente réduit cette tâche à une simple formalité. Cette étape cesse au plus tarddeux jours avant le Focus.

Chaque membre du SWAT focalise alors sur l’amélioration technique qualitative desa propre production. Si les normes de codage publiées et acceptées ont été respectées,

Page 16: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 16

© 2000, Jean-Pierre Vickoff, RAD.fr

une journée suffit pour vérifier une production de deux semaines. L’équipe procèdealors à des revues croisées. Le niveau de qualité requis peut être très variable d’uneapplication à une autre selon sa typologie. Cette étape prend fin lorsque la qualité del’application atteint un niveau suffisant en robustesse, normalisation, documentationet conformité aux exigences fonctionnelles.

Le membre du SWAT chargé de l’intégration des modules réalise alors cette opération.Il s’attache tout particulièrement à tester les interfaces des applicatifs mettant en œuvredes données communes (externes, globales).

Les utilisateurs ayant participé aux séances de spécification et de validationpermanente sont alors rappelés pour la dernière étape de vérification de la qualitéfonctionnelle et des cheminements. L’intervention des utilisateurs est indispensable,car ils devront manipuler l’application durant le Focus et ils sont susceptibles dedéclencher des événements que le développeur n’aurait pas imaginés. A ce point,seules les divergences bloquantes et majeures sont corrigées. Cette opération impliqueun minimum de tests de non-régression et une étape complète d’intégration.

Publication des normes

État de livraison permanente (n)

PROTOTYPAGE

Planification Jalon ZD

Planification FOCUS

étape Vérification personnelle

étape Revue de code (croisée)

étape Vérification utilisateur

étape Intégration modules

Prise en comptedes remarques

Étapes M.O.Étapes M.E.

Figure 5. — Architecture de réalisation (Focus de visibilité)

Durant le Focus, les rapporteurs devront consigner les éventuels incidents et lesobservations qui ne manqueront pas d’être émises par une nombreuse assistance. Lespersonnes ne participant pas aux spécifications ont souvent un avis a posteriori etparfois une vision plus profonde ou plus précise des évolutions du métier. Cesressources étant le plus souvent des décisionnaires, leurs recommandations doiventêtre étudiées sous un angle de vision prospective. C’est d’ailleurs souvent cetteabsence de vision qui confine une application dans un cadre strictement opérationnelalors qu’elle aurait pu revêtir une dimension stratégique.

L’intervalle entre deux Focus ne doit pas être assimilé à un effet tunnel (même réduit).Le Focus est une affaire de visibilité externe ponctuelle et non un moyen de validationinterne. Entre deux Focus, les concepteurs-développeurs sont en contact avec lesutilisateurs qui participent en direct à la spécification de détail. Lors d’un Focus,l’utilisateur manipule la partie de l’application a laquelle il a contribué. Les spectateursobservent et critiquent. Le groupe d’animation et de rapport note les observations.

Page 17: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 17

© 2000, Jean-Pierre Vickoff, RAD.fr

Sur le plan des communications, l’organisation d’un Focus est identique à celle d’unesession de travail. Le nombre de Focus dépend de la durée du projet et de sacomplexité22. Il est en général planifié 3 ou 4 Focus pour un « petit » projet et de 4 à 8Focus pour un projet intermédiaire.

Lors du Focus, la discrétion de l’informaticien est proportionnelle à son efficacitétechnique et à la puissance de sa méthode.

Tableau 1. — Nombre de Focus en fonction du projet

Durée du projet en jours 30 60 90 120

Nombre moyen de Focus 2 3 4 5

1.8. Phase FINALISATIONPour de multiples raisons dont notamment les techniques de validation permanente etde jalons zéro-défaut, la recette RAD est beaucoup moins conséquente qu’une recetteclassique.

La phase de FINALISATION comprend, entre autres, la formation, les activités liéesau déploiement, le bilan de projet, le retour de connaissance. Elle clôture le projetRAD.

1.9. Objectifs et travaux par phasePour chacune des phases du projet, la suite de ce document précise :

§ son objectif, son contenu et la liste des travaux à réaliser,

§ les principaux produits en entrée,

§ les produits en sortie (la liste des livrables de la phase),

§ les acteurs de production,

§ les actions de contrôle et de validation.

22 Un projet considéré comme « petit » selon les critères du RAD engage une ou deuxressources expérimentées pour une durée de 30 à 90 jours. Un projet « intermédiaire » engageune équipe (SWAT, Skill With Advanced Tools) de 4 à 6 concepteurs-développeurs pour unedurée de 60 à 120 jours. Les grands projets utilisent des techniques de parallélisation durant laphase de DESIGN et de sérialisation durant la phase de CONSTRUCTION. La planification desFocus dépend alors du nombre d'équipes et du style de projet.

Page 18: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 18

© 2000, Jean-Pierre Vickoff, RAD.fr

Phase INITIALISATION

La phase d’Initialisation prépare les intervenants aux contraintes d’un projet RAD.Après une courte immersion dans le domaine fonctionnel, lors d’un entretienpropriétaire, l’équivalent d’une étude de faisabilité, les contraintes de la méthode etun plan d’action à respecter sont présentés à la maîtrise d’ouvrage.

Un modèle et un plan de communication sont produits. Si nécessaire, un BPR ou demodélisation au niveau « métier » précède l’automatisation du domaine. Une réunionde lancement du projet est ensuite organisée. Elle regroupe tous les acteurs recensés etdonne lieu à l’individualisation des travaux préparatoires à la modélisation dusystème.

Tableau 2. — Synthèse phase Initialisation

Objectifs de la phase

INITIALISATION

Formaliser les objectifs, valider le périmètre du projet et lesexigences.

Envisager un planning, l'organisation et le Pland’Assurance Qualité du projet.

Travaux à réaliser Acteurs

GAR +

Produits / Livrables

Répertorier l’ensembledes intervenants

MOA Plan de communication

Définir les objectifsstratégiques du projet

MOA Périmètre applicatif

Recherche de solutions MOE Rapport de faisabilité

Evaluer les moyensnécessaires.

MOE Evaluation des charges

Accord MOE / MOA MOE +

MOALettre d’engagement

Lancement projet MOA Plan de réunion et documents

Actions de contrôle en fin de phase

Validation des objectifs par le Maître d'Ouvrage.

Accord de la direction générale (budget, engagement de ressources).

Page 19: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 19

© 2000, Jean-Pierre Vickoff, RAD.fr

Phase CADRAGE

Le Cadrage et la première partie du Design s’appuient sur une approche top-down quipermet de respecter la cohérence systémique et les choix stratégiques ou opérationnels(à l’inverse de la Construction qui privilégie la définition détaillée des exigences etapplique une approche bottom-up). Lors du Cadrage auquel participent les décideurs,l’animateur obtient le verrouillage des exigences, des budgets, des délais et de lasolution globale sur les plans stratégique, fonctionnel, technologique etorganisationnel. Dans le cas où les exigences et les ressources divergeraient, destechnique « AV » permettent d’attribuer des priorités aux fonctionnalités en termes deretour sur investissement. Cette modélisation des traitements s’effectue sous la formed’une hiérarchie de fonctions.

Tableau 3. — Synthèse phase Cadrage

Objectifs de la phase

CADRAGE

Formaliser les exigences.Etablir le Plan de cadrage.

Engager les ressources.

Travaux à réaliser Acteurs

GAR +

Produits / Livrables

Stratégique DG Objectifs hiérarchisés

Fonctionnel MOA+

MOE

Hiérarchie de fonctions ou Cahier des Charges ouGestion des exigences

Technologique MOE(PPI)

Rapport de solutions

Organisationnel MOA

(CPU)

Plan d’accompagnement du changement, modèle« métier »

Contraintes MOEMOA

Ressources, cycle de développement, planification,etc.

Actions de contrôle en fin de phase

Validation des objectifs et des contraintes par le Maître d'Ouvrage et ses experts.

Validation des solutions et des contraintes par le Maître d'Œuvre et ses experts.

Page 20: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 20

© 2000, Jean-Pierre Vickoff, RAD.fr

Phase DESIGN

Cette phase repose sur l’usage d’un AGL de conception léger et puissant. Dans lamesure du possible, cet outil est utilisé « en direct », dans une salle spécialementéquipée de moyens de vidéoprojection et de communication.

Sous la coordination de l’animateur, les utilisateurs significatifs et les concepteurs-développeurs travaillent alors en commun et en direct à la modélisation détaillée destraitements et des données de l’application. Si la performance immédiate estrecherchée, la modélisation des données reste classique et s’appuie sur le modèleentité-relation. La présentation d’un premier niveau de prototype conclut cette phase.

Tableau 4. — Synthèse phase Design

Objectifs de la phase

DESIGN

Définir la solution cible en termes de modèles, valider unpremier prototype

Travaux à réaliser Acteurs

GAR +

Produits / Livrables

Modélisation MOE +

MOA

Liste détaillée des fonctionnalités et modèle dedonnées exhaustif

Documentationtechnique

MOE Modèles issus de l’AGL de conception

Révision del'évaluation

MOE +

MOA

Charges et planning révisés

Actions de contrôle en fin de phase

Validation de la conception d'ensemble.

Validation des choix technologiques.

Validation des modèles et du prototype.

Validation des charges et du planning.

Pour atteindre une réelle performance, les outils de Construction doivent être choisis avecsoin (VB, Delphi, PB, D2000, etc.) ; une charte graphique doit avoir été validée etinstrumentée ; des normes de programmation publiées, un modèle de transaction généraliséapplicable à tous les modules et, si possible, le cadre d’une méta-application devront être mis àla disposition des équipes ; tous les participants devront utiliser les outils choisis et les normesarrêtées.

Page 21: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 21

© 2000, Jean-Pierre Vickoff, RAD.fr

Phase CONSTRUCTION

Cette phase affine le prototype, elle fusionne les étapes classiques de :

§ spécification détaillée,

§ réalisation (codage),

§ tests unitaires et tests d’intégration (en Focus),

§ la plus grande partie des tests de cheminements fonctionnels et la recette informellede l’application.

Tableau 5. — Synthèse phase Construction

Objectifs de la phase

CONSTRUCTION

Réaliser l’application et livrer rapidement desfonctionnalités.

Travaux à réaliser Acteurs

GAR +

Produits / Livrables

Publication des normes MOE Normes de développement

Planification FOCUS MOE

MOACalendrier des présentations

Etablissement des jeuxd'essai utilisateurs

MOE

MOAJeux d'essai utilisateurs

Prototypage ACTIF envalidation permanente

MOE

MOAJalons zéro-défaut

FOCUS MOE

MOAApplication en fonctionnalités partielles

Site Pilote MOE

MOAApplication utilisable

Documentationutilisateur

MOA On-line, contextuelle, papier

Documentationtechnique

MOE Intégrée aux modules développés

Actions de contrôle en fin de phase

Recette générale de l’application.

Phase FINALISATION

Cette phase engage surtout la MOA. Elle comprend, entre autres, la formation desutilisateurs, la surveillance d’un site pilote et les activités liées au déploiement général.Elle clôture le projet RAD.

Une application réalisée suivant les principes de la méthode RAD est validée enpermanence par ses utilisateurs. La recette d’une application RAD est donc beaucoupplus rapide qu’une recette classique.

Selon l’importance du projet et les principes de l’organisation en termes de recette etde déploiement, il peut être nécessaire d’organiser tout ou partie des étapes décritesdans les tableaux suivants.

Page 22: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 22

© 2000, Jean-Pierre Vickoff, RAD.fr

Etape « Préparation de la mise en œuvre »

Tableau 6. — Finalisation, étape de mise en œuvre

Objectifs de l’étape

Préparation de la mise en œuvre

Préparer le changement : - préparer la recette, - produire la documentation utilisateur, - établir le plan de démarrage, - transférer la connaissance auxformateurs, - mettre en place la nouvelle organisation.

Produits / FournituresTravaux à réaliser Acteurs

prérequis livrables

Réalisation de la recette finale MOE

MOAexigences PV de recette

Rédaction des manuels utilisateurs MOE

MOAManuelsutilisateurs

Rédaction du manuel d’exploitation MOE

MOAManuelexploitation

Préparation de la formation MOA ManuelsUtilisateurs

Supports deformation

Etablissement du plan de formation,préparation de l'environnement et dela logistique de formation

MOA Supports deformation,planning duprojet

Plan deformation,environnementet logistiqued’opération

Formation des futurs formateursauprès des utilisateurs finaux

MOA Supports, plande formation etlogistique

Formateursopérationnels

Mise en place des procéduresorganisationnelles

MOA

DGExigencesorganisation-nelles

Procéduresopérationnelles

Etablissement du plan de démarrage,incluant reprises de données, labascule technique, les tests aprèsbascule.

MOA

MOEPlan dedémarrage

Communication aux utilisateurs(planning, formation, plan dedémarrage, etc.).

DG

MOANotesd'information

Actions de contrôle en fin de phase

Validation de la stratégie de recette et des jeux d'essais.

Validation des scénarios de tests internes.

Validation du manuel utilisateur, du manuel administrateur, du plan de formationet des supports de formation : interne à la MOA.

Validation du plan de démarrage par la MOE et la MOA.

Validation des charges et planning par la MOE, puis par le comité de suivi.

Page 23: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 23

© 2000, Jean-Pierre Vickoff, RAD.fr

Etape « Recette officielle »

Tableau 7. — Synthèse Finalisation, étape recette officielle

Objectifs de l’étape

Recette officielle

Recette de l'application avant sa mise enœuvre. Recette de la reprise de donnéesavant bascule effective.

Travaux à réaliser Acteurs Produits / Fournitures

Prérequis Livrables

Recette interne MOE avant livraison à laMOA :- recette des interfaces,- recette fonctionnelle du lot assemblé- recette de la reprise des données

MOE

MOA

Scénarios detests et jeuxd’essais

Lot assemblé etopérationnelpour les testsfonctionnels etd'intégration

Application

Journal destests

Recette fonctionnelle utilisateurs,incluant les interfaces et la reprise desdonnées

MOE

MOA

Cahier derecette,jeux d'essais,applicationintégrée

Applicationrecettéefonctionnellepar lesutilisateurs.Journal destests.

Intégration technique du lot, incluantles tests de charge et les tests réseau.

MOE

DTI

Application etrecettefonctionnelle

Application« recettée »technique

Communication auprès des utilisateurs. MOE

MOA

GAR

Notesd'information

Actions de contrôle en fin de phase

Vérification de la complétude des tests en rapprochant le journal des tests, du cahierde recette et du jeu d'essais : par la MOA (CPU) et la MOE (PPI).

Page 24: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 24

© 2000, Jean-Pierre Vickoff, RAD.fr

Etape « Organisation et Démarrage»

Tableau 8. — Synthèse, finalisation, démarrage

Objectifs de l’étape

Organisation et démarrage

Mettre en œuvre l'application etaccompagner le changement

Travaux à réaliser Acteurs Produits / Fournitures

prérequis Livrables

Etablissement de l'environnementd'exploitation et de l'infrastructure dusupport d'exploitation

DTI

MOEManuelExploitation

Exploitationopérationnelle

Mise en œuvre du plan de démarrage(incluant la reprise des données)

MOE

DTIApplication« recettée »,Plan deDémarrage

Applicationexploitable

Audit du fonctionnement etévaluation des écarts : - d'objectifs fonctionnels - de couverture des exigences

MOETous documentsdu projet,applicationopérationnelle

Bilan,Propositiond'orientationsfonctionnelleset techniques

Amélioration et optimisation dusystème DTI

Documents etapplication enopération

Applicationoptimisée

Formation des utilisateurs MOA Formateursformés,supports etlogistique deformation,

Utilisateursformés

Déploiement technique DTI Plan deDéploiement

Application enservice

Actions de contrôle en fin de phase

Validation du bilan et des orientations fonctionnelles et techniques.

Recette de la mise en service.

Page 25: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 25

© 2000, Jean-Pierre Vickoff, RAD.fr

1.10. Principaux documents par phaseTableau 9. — Documents conseillés en clôture de phase

Phases Etapes ou travaux Documents produits avant clôture

Préparation Entretien initial Engagement réciproque des maîtrises

Immersionanimateur

Périmètre applicatif. Plan decommunication

Réunion delancement

Travaux individualisés. Planning accepté

Cadrage Sessions despécifications desexigences

Focus de fin deCadrage

Modèle global des flux (DFD)

Modèle hiérarchique des traitements

Design Sessions conceptionsolution

Focus de fin deDesign

Modèle détaillé des données et (si utile)

Modèle détaillé des flux et traitements

Prototype initial

Construction Revues de code etde projet

Revuesfonctionnelles

État de livraisonpermanente

Focus deprésentation

Application opérationnelle validée :

- fonctionnellement par les utilisateurs

- techniquement par jalons zéro-défaut

Finalisation Déroulements descheminementsfonctionnels

Homologation et recette

Page 26: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 26

© 2000, Jean-Pierre Vickoff, RAD.fr

22.. BBiibblliiooggrraapphhiieess eett rrééfféérreenncceess

2.1. Bibliographie RAD, Conduite de projet

Martin James, Rapid Application Development, Macmillan, 1991.

Vickoff Jean-Pierre, RAD - Développement Rapide d’Applications, Méthodes et outils,les règles à respecter dans le développement d’application client-serveur, MGI, 1995, puisMacmillan, 1996.

Vickoff Jean-Pierre, REENGINEERING, Vite fait bien fait, Le Paradigme du futurimmédiat, QI, 1998.

Vickoff Jean-Pierre, Réingénierie du développement d’application, Méthodes, processus,techniques et pratiques de conduite de projet sous contraintes, Gartner Group, 1999.

Boehm B. & Bose P. A Collaborative Spiral Software Process Model, USC, 1994

Bouchy S. L'Ingénierie des systèmes d'information évolutifs, Eyrolles, 1994

Clark B. The Effects of software process maturity on software development effort, USC, 1997

Englewood C. JAD the Group Session, Approach to system design, Prentice Hall, 1991.

Egyed A. & Boehm B. Telecooperation Experience with the WinWin System, USC, 1998

Henry A. & Monkam-Daverat L. Rédiger les procédures de l’entreprise, Les Éditionsd’organisation, 1995.

Mc Carty J. 54 Règles d'or pour un grand logiciel, Microsoft Press, 1997.

McConnell S. Stratégie de développement rapide, Microsoft Press, 1996.

Panet G. & Letouche R. Merise 2, modèles et techniques Merise avancés, Les Éditionsd'organisation, 1994.

Yourdon E. Modern Structured Analysis, Englewood Cliffs, 1989.

2.2. Bibliographie Objet

Budd T. La Programmation par objets, Edition Addison-Wesley, 1991.

Jacobson I. Le Génie logiciel orienté objet, Addison-Wesley, 1993.

Lai M. UML - La Notation unifiée de modélisation objet, InterEdition, 1997.

Lemay L. & Perkins C. L. Le Programmeur JAVA, Macmillan, 1996

Muller P. A. Modélisation Objet avec UML, Eyrolles, 1997.

Rumbauch J. OMT Modélisation et conception orientées objet, Prentice Hall Masson, 1996.

Vauquier D. Développement orienté objet, principes, processus, procédés, Eyrolles, 1993.

2.3. Bibliographie Management, Qualité

Ballay J-F. Capitaliser et transmettre les savoir-faire de l’entreprise, Eyrolles, 1997.

Bartoli A. Communication et organisation, pour une politique générale cohérente, LesÉditions d'organisation, 1994.

Beaudoin P. La Gestion du changement, une approche stratégique pour l'entreprise enmutation, Stratégies d'entreprise, 1990.

Champy J. Reengineering Management, HarperCollins Publishers, 1995.

Chapman C. & Ward S. Project Risk Management : Processes, Techniques andInsights, Edition Wiley, 1997.

Page 27: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 27

© 2000, Jean-Pierre Vickoff, RAD.fr

Courtot E. La gestion des risques dans les projets, Edition Economica, 1998

Delafollie G. Analyse de la valeur, Hachette, 1991.

Hammer M. & Champy S. Reengineering the Corporation, A manifesto for BusinessRevolution, Harper Business, 1993.

Henry A. & Monkam L., Rédiger les procédures de l’entreprise, Éditions d’organisation,1995.

Laudoyer G. La Certification, un moteur pour la qualité, Les Éditions d'organisation, 1993.

Lamprecht J-L. ISO 9000 Se préparer à la certification, AFNOR, 1994.

Lefebvre C. Concevoir et conduire un projet de changement, Les Presses du management,1997.

Maders H-P. & Gauthier E. & Le Gallais C. Conduire un Projet d’Organisation, Editionsd’Organisation, 1998

Nizet J. & Huybrechts C. Interventions systémiques dans les organisations, Intégration desapports de Mintzberg et de Palo Alto, Editions DeBoeck Université, 1998

Mucchielli R. L'Interview de groupe, ESF, 1987.

Renaud-Coulon A. La Désorganisation compétitive, Maxima, 1996

Richard J. & Paula S. Delivering Results: Evolving BPR from Art to Engineering, TexasA&M University, 1998

Sary P. La Stratégie de la programmation neurolinguistique dans l'entreprise, Editions Retz,1990.

Wenger E. 1998, Communities of Practice - Learning, Meaning and Identity, Cambridge UniversityPress.,

2.4. Divers documents, normes, standards

En ce qui concerne les travaux du SEI sur CMM :

§ SEI/CRIM, 1993, Paulk Modèle d'évolution des capacités logiciel.

§ IEEE Software, 1993, Paulk & M.C. Curtis & B. & Chrissis, M.B. & Weber, C.V.Capability Maturity Model, Version 1.1, Vol. 10, No. 4, July 1993, pp. 18-27.

§ SEI, 1995, Paulk The Capability Model : Guidelines for Improving the Software Process.

En ce qui concerne les normes ISO (Evaluation, Qualité, SPICE) :

§ ISO 9001-1994, Model for quality assurance in design, development, production,installation and servicing.

§ ISO 9000-3-1991, Quality management and quality assurance standards (Part 3:Guidelines for the application of ISO 9001 to the development, supply and maintenance ofsoftware).

§ ISO 9004-4-1993, Quality management and quality system elements (Part 4: Guidelines forquality improvement).

§ ISO 8402 et X 50-125, Management de la qualité et assurance de la qualité – Vocabulaire

§ ISO/IEC12207-1-1994, Software life cycle processes (ingénierie du logiciel)

§ ISO/IEC12119-1995, Software products - Evaluation and test.

§ ISO/IEC 9126-1991, Software quality characteristics.

§ ISO 9294, Ligne directrice pour la gestion de la documentation technique du logiciel

Ainsi que diverses références aux documents suivants :

§ Craigmyle, M., and I. Fletcher, Improving IT effectiveness through software processassessment, Software Quality Journal, Vol. 2, pp 257-264 (1993).

Page 28: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 28

© 2000, Jean-Pierre Vickoff, RAD.fr

§ Humphrey, W.S., Managing the Software Process, Addison Wesley, 1989.

§ Kuvaja, P., Simila, J., Krzanik, L., Bicego, A., Koch, G. and Saukkonen, S., SoftwareProcess Assessment and Improvement: The BOOTSTRAP Approach. Blackwell, 1994.

§ Bell Communications Research, Inc., Quality Program Specification for SurveillanceManagement Process(SMP) Software (General), QPS 88.001, Issue 1.

§ AFCIQ-PDL, Recommandation de plan de développement logicel.

§ AFCIQ-PAQL, Recommandation de plan d’assurance qualité logiciel.

§ SCE - Software Capability Evaluation Training Guide / SPA - Software ProcessAssessment Training Guide, Software Engineering Institute, Pittsburgh Pennsylvania.

§ F. Coallier, N. Gammage, A.W. Graydon, Trillium - Software Process Self-assessmentCapability Assessment , Bell Canada, PI Q008, Issue 4.0, March 1993.

2.5. Principaux WEB et contributeurs

AFAV, Association française pour l'analyse de la valeur, http://www.afav.asso.fr

AFITEP, Association francophone de management de projet, http://www.afitep.fr

American Society for Quality, http://www.asqc.org

Business Processes Ressources Centre, http://bprc.warwick.ac.uk/bp-gold.html

Business Process Reengineering Advisory Group,http://www.eil.utoronto.ca/tool/list.html

COCOMO, Constructiv Cost Model,http://sunset.usc.edu/CORADMO/coradmo.html

CORADMO, Constructiv Cost Model,http://sunset.usc.edu/CORADMO/coradmo.html

CRIM, Centre de génie logiciel appliqué de Montréal, http://www.CRIM.CA/cgla

DACS, Data Analysys Center for Software (Cost estimation),http://mach10.rome.kaman.com/cgi-bin/keylist

Esprit Project 27599 – RAMSES RAD for MSS,http://www.esi.es/ESSI/Reports/All/27599/

IDEF method, http://www.idef.com

IFPUG, International Function Point Users Group, http://www.ifpug.org

ISO, Software Process Assessment, http://www.sqi.gu.edu.au/sc7/wg10/

SEI, The Software Engineering Institute, http://www.sei.cmu.edu

Software Engineering & its Applications (TFGL du CNAM),http://web.cnam.fr/TFGL

Staffordshire Universityhttp://www.soc.staffs.ac.uk/~cmtrmk/rad/new/course/rad1.htm

UML, Informations sur UML, http://www.essaim.univ-mulhouse.fr/uml

University of California, Davis,http://sysdev.ucdavis.edu/webadm/document/rad_toc.htm

Pour terminer, je remercie particulièrement les participants assidus des réunions de lacommission AFITEP IM-CP-Processus. Leur contribution à la formalisation des diversaspects de la conduite de projet, a facilité la rédaction de plusieurs parties de cetouvrage.

Page 29: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 29

© 2000, Jean-Pierre Vickoff, RAD.fr

2.6. Index

A

abstraction · 11abstraction

métier · 10AFNOR · 28AGL de conception · 20architecture

applicative · 11assistance · 14

B

budgetcadrage · 9, 19

C

certification · 28cohérence systémique · 19communication

espace · 10, 20modèle · 8, 18plan · 8qualité · 9

consensusentretien · 9

CPI · 19, 23CPU · 19, 23customs-controls · 14

D

décomposition · 12, 13dichotomie · 12DSDM · 5DTI · 23, 24dynamique

de projet · 6

E

entité-relation · 20entretien

de groupe · 7, 9ergonomie · 7

F

facilitateur · 8Focus · 5, 6, 9, 15, 16, 17, 25Focus

communication · 15pratiques · 15, 17principe · 8validation · 15

fonctionnalitésgénérales · 9partielles · 8spécifiques · 14

fonctionnelcheminement · 14, 21conformité · 15couverture · 9, 19domaine · 8, 18

formationutilisateur · 17, 21

G

Gartner Group · 27groupe de travail · 9

H

hiérarchie de fonctions · 13, 19hiérarchie de fonctions

modélisation · 17modèlisation · 9

I

immersion · 8ISO · 28

J

jalons ZD · 15James Martin · 27

L

lancement officiel · 9livrable · 15livraison · 5, 7, 15, 23, 25

M

maintenanceapplicative · 8, 15

motivation · 9

Page 30: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 30

© 2000, Jean-Pierre Vickoff, RAD.fr

N

non régression · 16normalisation · 16

O

outilconstruction · 14, 20

P

pérennité · 10périmètre

général · 6pilote

site · 21planification · 8, 15, 17, 19planification

pratiques · 15présentation

prototype · 10, 20processus

réingénierie · 8prototypage · 14prototypage

construction · 7validation · 15

prototype · 8prototype

évolution · 15niveau · 7, 10, 20

Q

qualité fonctionnelle · 5, 6, 16qualité technique · 5, 6

R

rapporteurs · 16recette · 5, 8, 17, 21, 22, 23, 25recette

initiale · 14, 21partielle · 7

réingénierie · 8

René Descartes · 4ressource

priorisation · 9, 19RUP · 5

S

session pleinière · 9, 10site pilote · 8SPICE · 28stratification · 10structuration

métier · 13technique · 11

SWAT · 7, 15, 16, 17SWAT

composition · 10organisation · 14

systémiquecohérence · 19

T

thèmesdécoupage · 6, 9

travail de groupe · 8typologie

risques · 16

U

utilisateurexigences · 7réel · 9validation · 15

utilisateursapprobation · 14

utilisateurs significatifs · 10, 20

V

validation permanente · 14, 16verrouillage · 9, 19vidéoprojecteur · 9visibilité · 6, 15, 16vision prospective · 16

Page 31: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

RAD , la méthode de développement rapide d'applications 31

© 2000, Jean-Pierre Vickoff, RAD.fr

2.7. Figures

Figure 1. — Jalons décisifs du cycle projet RAD 6

Figure 2. — Principales étapes d’un cycle de projet à 120 jours 7

Figure 3. — Phasage et parallélisation (grand projet) 10

Figure 4. — Modélisation UML des exigences (Paradigm Plus) 11

Figure 5. — Architecture de réalisation (Focus de visibilité) 16

2.8. Tableaux et listes

Tableau 1. — Nombre de Focus en fonction du projet 17

Tableau 2. — Synthèse phase Initialisation 18

Tableau 3. — Synthèse phase Cadrage 19

Tableau 4. — Synthèse phase Design 20

Tableau 5. — Synthèse phase Construction 21

Tableau 6. — Finalisation, étape de mise en œuvre 22

Tableau 7. — Synthèse Finalisation, étape recette officielle 23

Tableau 8. — Synthèse, finalisation, démarrage 24

Tableau 9. — Documents conseillés en clôture de phase 25

Page 32: Méthode RAD · Méthode RAD Éléments fondamentaux Le Développement Rapide d'Applications Organisation des développements, conduite de projets, ingénierie applicative

Jean-Pierre Vickoff est avant tout pilote de projet et concepteur-développeur. Canadien et Français, il s’est spécialisé en Amérique duNord dans les méthodes de développements sous contraintes.

Consultant en qualité et en performance, il produit des communicationspour la presse professionnelle et des rapports pour le Gartner Group. Ilest l’auteur de plusieurs ouvrages, dont RAD et Réingenierie dudéveloppement d’applications. Il préside la commission conduite deprojet IM-CP de l’AFITEP et interviens auprès des établissementsmembres de la Conférence des Grandes Ecoles.

Pilote 2010 n’est pas un livre dans le sens littéraire du terme mais un support d’étude, deréflexion et d’action. Pilote 2010 instrumente l’ensemble des méthodes, pratiques et outilsindispensables à la productivité du développement ainsi qu’à la qualité des applications. Pilote2010 constitue une source unique de références opérationnelles en matière de :

§ Conduite de projet (classique, décisionnel, NET)

§ Plan d’Assurance-Qualité du développement

§ Pilotage des risques et métrique quantitative des charges

§ Méthodes, pratiques, outils de la performance

§ Processus d’ingénierie du développement (RAD2-UML)

§ Processus spécialisé e-commerce

§ Gestion des Exigences, des Validations et des Divergences

§ Gestion de la communication et des rapports entre acteurs

§ Notations et techniques de modélisation (Merise, Flux, Objet)

§ Ingénierie « métier » et accompagnement organisationnel, BPR, MTQS

§ Industrialisation, choix de solutions, progiciel, externalisation

§ Planification, documentation, plan de tests, gestion de configuration

§ Standards d’évaluation et d’amélioration (SEI-CMM/ISO-SPICE)

Ces thèmes sont traités sous une forme directement utilisable.

Pilote 2010 propose aussi dans un format MS Office :

§ Un ensemble normalisé de documents de projet

§ Un plan d’Assurance-Qualité générique

§ Divers processus (RAD2, progiciel, externalisation)

§ Un rapport standard de pilotage de projet

§ Un logiciel d’évaluation de charge, d’optimisation et de négociation

§ Une présentation et une formation à la méthode RAD

Dans un univers de performances, où l’obligation de résultats s’impose à tous progressivement,la rigueur devient l’alliée du changement. Les pilotes de SI se doivent alors d’envisagerimmédiatement l’acquisition d’une nouvelle culture « projet » et de l’appliquer à l’évolution de leurprofession. Dans cette optique, Pilote 2010 leur propose une couverture complète et en l’état del’art, des évolutions du métier. Cette ambition positionne l’ouvrage comme la Bible dudéveloppement d’applications pour la décennie en cours.