RAD La Méthode

Transcription

RAD La Méthode

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
RAD , la méthode de développement rapide d'applications
2
Méthode
RAD
Le Développement Rapide d'Applications
Jean-Pierre Vickoff
RAD.fr
© 2000, Jean-Pierre Vickoff, RAD.fr
3
SOMMAIRE DU DOCUMENT
MÉTHODE RAD
1
1. MÉTHODE DE DÉVELOPPEMENT LOGICIEL RAD
5
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
1.7.
1.8.
1.9.
1.10.
Structure de développement
Description globale des phases
Approfondissement des phases
Phase INITIALISATION
Phase CADRAGE
Phase DESIGN
Phase CONSTRUCTION
Phase FINALISATION
Objectifs et travaux par phase
Principaux documents par phase
5
6
7
8
9
10
14
17
17
25
Bibliographie RAD, Conduite de projet
Bibliographie Objet
Bibliographie Management, Qualité
Divers documents, normes, standards
Principaux WEB et contributeurs
Index
Figures
Tableaux et listes
26
26
26
27
28
29
31
31
2. BIBLIOGRAPHIES ET RÉFÉRENCES
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
26
4
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 des
autres hommes ... que le plus grand profit que j'en retirois étoit que,
voyant plusieurs choses qui, bien qu'elles nous semblent fort
extravagantes et ridicules, ne laissent pas d'être communément reçues
et approuvées par d'autres grands peuples. »
René Descartes, Discours de la méthode
5
1. Méthode de développement logiciel RAD
La méthode RAD et le Processus Qualité RAD2, impliquent 3 intervenants
principaux (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 la
qualité 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 de
Focus, suivis des divergences). Le Groupe d’Animation et de Rapport prend en
charge les communications et la formalisation des informations.
1.1. Structure de développement
La structure méthodologique du projet s'appuie :
§ la méthode RAD et son cycle semi-itératif2 en ce qui concerne les principes
fondamentaux de conduite de projet ;
§ le processus RAD2 pour l’ordonnancement pratique des opérations de
dé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 de
structure 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 Rapport
2
Merise ou SDMS utilisent un cycle en cascade, alors que DSDM ou RUP préconisent un cycle
totalement itératif.
3
Les trois premiers points définissent les principes de la méthode RAD telle que James Martin
l’avait conçue dès la fin des années 80.
6
mode opératoire précis structuré en trois étapes : pré-session, session, postsession [Mucchielli 1987].
3.
Des méthodes, techniques et outils permettant de définir et d’appliquer des
choix 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 et
particulièrement sur celles qui permettent une conception « en vue de
modifications » [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 qui
recommande, pour garantir la qualité fonctionnelle, le prototypage actif et les
Focus6 de visibilité [McConnell 1996].
1.2. Description globale des phases
La 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
Miseen
encondition
conditionde
del’organisation
l’organisation
Interviews
Interviewsde
degroupe
groupe
Expression
Expressiondes
desbesoins
besoins
Création
Créationd’un
d’unétat
étatde
delivraison
livraison
permanente
permanentepour
pour1er
1erFOCUS
FOCUS
Spécification
Mise
Miseen
enopération
opérationdu
duSWAT
SWAT
Modélisation
Modélisationdu
dusystème
système
Validation
Réalisation
Qualité
Qualitéetetsupport
supportsite
sitepilote
pilote
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 travail
par thèmes, de sélectionner les acteurs pertinents et d’amorcer une dynamique de
projet. Cette phase représente environ 6% du projet en charge.
4
Visibilité = capacité de contrôle offerte aux responsables.
Jalon zéro-défaut (ZD) : jalon du projet intégrant une validation technique, une intégration et
une validation fonctionnelle par l'utilisateur.
6
Focus : réunion plénière de présentation débouchant sur une validation globale.
5
7
2. CADRAGE (analyse et expression des exigences)
La spécification des exigences est du ressort des utilisateurs. Ils expriment leurs
besoins lors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de
sessions 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ématique
gé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 la
parallélisation du travail est possible (figure 3).
4. CONSTRUCTION (réalisation, prototypage)
Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par
module. L’utilisateur participe toujours activement aux spécifications détaillées et à la
validation des prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase
représente environ 50% du projet. A partir de la phase de Construction, à la
parallé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 phase
d’officialiser une livraison globale et de transférer le système en exploitation et
maintenance. Cette phase représente environ 12% du projet.
Focus
FocusR1
R1
120 jours
maximum
Réunion
Réunionde
delancement
lancementetet
d’individualisation
d’individualisation
Focus
FocusR2
R2
Focus
FocusCC
Initialisation du projet et
Initialisation du projet et
immersion animateur &
immersion animateur &
coordinateurs dans le
coordinateurs dans le
domaine fonctionnel
domaine fonctionnel
Focus
FocusR3
R3
CADRAGE
CADRAGE
Recette
RecetteUtilisateurs
Utilisateurs
Focus
FocusDD
DESIGN
DESIGN
Entretien
Entretien
propriétaire
propriétaire
2/1
15/1
18/1
Site pilote
Site pilote
CONSTRUCTION
CONSTRUCTION
Généralisation
Généralisation
1/2
18/2
10/4
10/5
30/5
30/6
30/7
20/8
1/9
Figure 2. — Principales étapes d’un cycle de projet à 120 jours
1.3. Approfondissement des phases
Voici 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’un
coordonnateur maîtrisant parfaitement tous les aspects du RAD. Dans les projets où
des dissensions pourraient apparaître entre les différents interlocuteurs, ce spécialiste
de l’entretien de groupe doit nécessairement être neutre. Fonctionnellement, trois
catégories d’intervenants participent à un projet RAD : ceux « pour action » qui sont
convoqué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 projet
stratégique ou sous contrainte de temps.
8
La maîtrise d’ouvrage doit s’investir aussi régulièrement dans la validation de sa
future application (prototype7) que la maîtrise d’œuvre le fait dans la production.
Seul le respect de ces conditions de communication permettra aux développements
modernes 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 et
déséquilibre sa production opérationnelle, des ressources supplémentaires lui sont
affectées. Leur coût est inclus dans le budget global du projet. Le retour sur
investissement de ce recouvrement de fonction est chiffrable et positif. Une des
missions de l’animateur est de justifier l’impact de chaque action en termes de retour
sur 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égie
initialement 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é des
entretiens (participation, progression, centrage des thèmes, respect des priorités) et de
la performance de l’environnement technologique, méthodologique.
Afin de soutenir l’évolution positive des motivations et la dynamique d’équipe, des
moyens matériels sont à sa disposition : budget pour actions incitatives au
renforcement de la cohésion interpersonnelle, amélioration du cadre de travail,
assouplissement des contraintes matérielles, prise de décision démocratique, prime
sur atteinte d’objectifs.
L’animateur est « neutre » vis-à-vis des deux maîtrises et cette neutralité doit le faire
dépendre de la direction générale [Boehm 1998] ou d’une instance arbitre entre
l’informatique et la direction utilisatrice.
1.4. Phase INITIALISATION
La phase d’Initialisation a pour objectif d’informer les intervenants des contraintes
d’un projet RAD.
Après une courte Immersion dans le domaine fonctionnel, le pilote, les coordinateurs
et l’animateur présentent aux dirigeants et à la maîtrise d’ouvrage les contraintes de la
mé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 de
ré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 les
acteurs recensés et donne lieu à l’individualisation des travaux préparatoires, à la
spécification des exigences de la future application et à sa modélisation. Dans le cadre
du 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 de
l'application en cours d'amélioration. Le prototype est un système, éventuellement très
incomplet, mais dans son dimensionnement réel. Dans le respect de règles strictes de
construction, 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 au
site pilote. Après recette fonctionnelle et technique, le déploiement et la montée en charge
consacrent leur version finale. Le prototype continue par la suite à être amélioré. Cette
continuité 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 membres
du groupe et par leur encadrement.
9
§ 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 une
sensibilisation, une prise de connaissance ou un jugement général (validation) sur
le produit en cours de réalisation.
Les utilisateurs associés en permanence à un développement RAD doivent être en
grande 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 du
système représentent une force de proposition fonctionnelle.
L'entretien de groupe est la meilleure forme de réunion pour déterminer les
fonctionnalités générales d'un système. Lorsque celui-ci est conséquent, un individu
isolé a difficilement une vue d'ensemble objective et complète. Parfois, pour réaliser
des 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 plus
efficace. L'interview de groupe, par la communication qu’il suscite, éveille
naturellement la réflexion, l'évolution, le progrès dans la recherche d’amélioration de
la qualité.
La réunion de lancement (d’une demi-journée à une journée) est souvent considérée
comme le lancement officiel du projet RAD. A l'issue de la réunion de lancement, les
participants disposent de quelques jours pour réaliser la préparation de la première
réunion de Cadrage dont la date est fixée.
1.5. Phase CADRAGE
Il est inutile d’engager des ressources humaines de qualité et coûteuses si les
ressources matérielles (salle, vidéoprojecteur, micros, logiciels) ne sont pas
disponibles. Le coût direct et la démotivation résultant de ce genre de situation
sont tels que le qualificatif « RAD » peut être oublié.
Lors du CADRAGE auquel participent les décideurs, l’animateur obtient le
verrouillage des exigences, des budgets, des délais et de la solution globale sur les
plans stratégique, fonctionnel, technologique et organisationnel.
Dans le cas où les exigences et les ressources divergeraient, il faut attribuer des
priorités aux fonctionnalités en termes de retour sur investissement. Cette
modélisation des traitements peut s’effectuer sous la forme d’une hiérarchie de
fonctions et/ou suivant le principe des cas d’utilisation.
Le cadrage nécessite des équipes de taille intermédiaire9, incluant des utilisateurs de
tous 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 étude
détaillée de l’existant en session plénière ;
§
dans les domaines où les fonctionnalités sont instables, un effort de réflexion
devra être engagé et le cercle d’interlocuteurs élargi.
Modéliser en direct avec un vidéoprojecteur électronique. Dans le principe, la
modélisation concrète des flux et des fonctionnalités devra être engagée le plus tôt
possible avec un outil adéquat.
9
Taille des groupes : Cadrage jusqu’à une douzaine d’utilisateurs ; Design de un à six
utilisateurs ; en Construction un ou deux utilisateurs ; lors des Focus tous les intervenants sont
conviés.
10
La durée des sessions de Cadrage est d’une demi-journée ou d’une journée. Il est
possible en cas de contraintes de délais de réaliser des sessions pouvant atteindre 5
jours. Le Cadrage complet peut alors être réalisé en une seule session. Les sessions de
Cadrage engagent simultanément les informaticiens de conception-développement (le
SWAT) 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 la
future application sont limités à quelques personnes significatives. Pour améliorer la
couverture de cette activité et lever un maximum de risques, il est souhaitable
d'élargir la base de participants dans le cadre d'une consultation préalable. Cette
approche s'avère généralement efficace et est indispensable dans le cadre d'un
management par la qualité de service (MTQS). Avant la réunion officielle, on engagera
donc une réflexion sur l'ensemble des thèmes composant le domaine applicatif.
30, 60, 90 ou 120 Jours maximum
CONSTRUCTION
CADRAGE
Parallélisation
Sérialisation
CONSTRUCTION
Finalisation
Préparation
DESIGN
DESIGN
6%
9%
23%
50%
12%
Figure 3. — Phasage et parallélisation (grand projet)
1.6. Phase DESIGN
La phase suivante, le DESIGN, repose sur la disponibilité d’un AGL de conception
léger et puissant. 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 des traitements et des données
de l’application. La présentation d’un premier niveau de prototype conclut cette
phase.
Le RAD s’appuie sur les techniques dérivées de l’objet et préconise une
architecture à « modèles variables » ainsi qu’une conception « en vue de
modifications ».
Le concepteur s’attache à mettre en œuvre une conception « en vue de modification ». Il
utilise 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 du
mé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 couche
concerné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 repousser
les limites d’un existant et de garantir les capacités d’évolution ultérieure de
l’applicatif. Par ailleurs, un système basé sur une structuration « métier » des données
et sur une stratification des traitements dispose d’une grande capacité d’évolution
11
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 au
moment du déploiement.
Abstraction, structuration, isolation, cohésion, modularité, généralisation,
encapsulation et surtout dissimulation sont les techniques de base de la modélisation
qui permettent la mise en œuvre d’une architecture de conception évolutive. Avec
UML, la modélisation Objet propose les « cas d’utilisation ». De nombreux outils
supportent 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 outils
aussi puissants que simples d’usage. Lors de la conception d'une application classique
de gestion, la préoccupation première de l'informaticien est généralement d'élaborer
avec l'utilisateur la description de l'architecture applicative représentée par un
modèle synthétique mais exhaustif du domaine à considérer. Cette architecture
applicative prend toute son importance avec l'évolution typologique des projets. En
effet la tendance actuelle est à la transversalité des solutions informatiques (ERP11,
Supply-Chain12) et le nombre de composants et d'interfaces avec les autres éléments
du système d'information se multiplie.
Pour être pratiquement utilisable, le modèle représentatif d’une architecture
applicative doit permettre une vision simultanée des acteurs et des événements qui
conditionnent leurs actions ainsi que des procédés employés et de leur séquence
d'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é.
12
é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 au
mieux cette complexité : l'approche française Merise, l'approche américaine par les
flux (DFD13, Gane & Sarson, SASD14) et, depuis peu, UML15 qui consacre la fusion des
principales approches « Orientées Objet ».
Modéliser permet de réduire la complexité pour la maîtriser, néanmoins le modèle ne
représente pas, dans l'état actuel de nos outils, la réalité de la solution. La
modélisation, si elle s'avère souvent indispensable, n'en reste pas moins une opération
qu'il faut considérer comme parasitaire en regard de la fourniture des fonctionnalités
réelles.
Dans ces conditions, le défi imposé alors par la performance est l'obtention d'une
vision 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 cependant
pas être trop détaillées afin de préserver la lisibilité du modèle. Un outil de
modélisation efficace doit donc être susceptible de représenter une décomposition des
traitements intégrant leur environnement d'exécution et de disposer d'un accès sousjacent au référentiel des données. Ce référentiel est décrit selon une approche
relationnelle 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 validation
croisée d'un nombre rebutant de modèles, aussi cette méthode ne convient plus aux
exigences générales des projets actuels. Le concept objet qui associe données et
traitements semble théoriquement plus proche, mais il impose dans la réalité de la
modélisation de multiples formes de représentation complémentaires. La gymnastique
intellectuelle permettant de « zapper » d'une vue à l'autre n'est pas encore à la portée
d'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ésentation
exhaustive, 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 UML
représente certainement le futur normalisé de la modélisation, il est indispensable que
des outils simples et puissants viennent en faciliter la mise en œuvre. Les outils en
question devront permettre une représentation de la réalité unique donc
multidimensionnelle. En attendant, il faut l'admettre, seule l'approche par les flux (en
complément de la description relationnelle des données) est suffisamment puissante et
outillée pour atteindre raisonnablement et économiquement ce but et permettre de
lever le risque inhérent à l'absence de modélisation auxquels sont toujours soumis de
nombreux projets.
13
Data Flow Design.
14
System Analyse System Design.
15
Unified Modeling Language.
16
Orienté Objet.
13
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 qui
repré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ésente
qu’une vision momentanément figée de l’organisation (c’est à travers l’axe des flux que
l’organisation évolue).
Avec la généralisation d’une modélisation « métier » (systématique dans tout projet
Objet), la notion d’informatique et d’organisation, dont l’application consistait le plus
souvent à reproduire avec la dernière technologie un existant insatisfaisant, renouvelle
totalement son « approche » du changement.
Une vision économiquement viable de la réactivité d'un SI impose de le concevoir en
vue de sa « modification permanente17 ». Il est alors préférable, comme d’ailleurs les
méthodes objets le préconisent, de figer initialement la vision statique, c’est-à-dire la
description des données. Cette vision est plus stable dans le temps, car elle représente
le « métier » de l’organisation. La capacité de généraliser suffisamment la description
de ces données permet d'obtenir un noyau de base dont les risques de remise en
question 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émoire
des processus de l’entreprise.
Dans un contexte concurrentiel, si l’architecte du système d’information dispose d’un
niveau d’abstraction suffisant, il définit en premier un modèle des données
suffisamment généraliste pour couvrir en un seul axe de structuration l’ensemble des
activités prises en compte par le système. Cela conduit à une représentation unique
descriptive de l’activité.
Le noyau stable acquis, on développe en couches périphériques la variété de
traitements permettant de mettre en œuvre des pratiques agressives. En cas
d’évolution, il suffit d’adapter la couche concernée, le noyau de données restant
inchangé.
Un système basé sur une structuration métier, des données et une stratification des
traitements 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, on
réalise en premier les parties les plus stables dans le temps, celles qui seront les moins
sujettes à é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 au
moment 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élisation
des 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, la
modé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’un
certain niveau. Suivant la taille du système deux ou trois niveaux de décomposition
sont suffisants. Dans le cas d’usage d’un outil permettant de modéliser les flux, il faut
obtenir parallèlement une hiérarchie des fonctions18. C’est en partant de cette
hié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 solution
informatique 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érarchie
de fonctions est la forme de modélisation la plus simple et la plus compréhensible pour un noninformaticien.
14
Le prototypage utilisé par la méthode RAD19 déporte la partie détaillée des
spé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 les
cas 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 pour
lesquelles il est préférable de ne pas trop détailler ces modèles est leur relative
volatilité. En effet, ils s’altèrent au rythme de l’évolution organisationnelle, voire des
pratiques commerciales. Seul le modèle des données le plus stable dans le temps, et
d’ailleurs le plus concrètement utile en terme d’usage informatique, doit être
totalement et parfaitement détaillé.
C’est donc dans la rigueur et la perfection du modèle de données et dans le choix
judicieux des principes et niveaux de décomposition des modèles de flux et de la
hiérarchie de fonctions (traitements) que réside la performance de réalisation d’un
système autant que son évolutivité.
Le temps des bricoleurs de la méthode et du développement s'achève. Le futur de la
profession se présente comme un défi industriel vital et passionnant.
1.7. Phase CONSTRUCTION
La phase de CONSTRUCTION affine le prototype21. Elle fusionne les étapes classiques
de spécification détaillée, de réalisation (codage), de tests unitaires et de tests
d’intégration, ainsi que la plus grande partie des tests de cheminement fonctionnel qui
constituent la recette initiale de l’application. Cette homogénéité constitue, avec la
prise de décision immédiate et la validation permanente, les bases mêmes de la
productivité et de la qualité RAD.
Pour atteindre cette performance, les outils de Construction utilisés doivent être
choisis avec soin, 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.
La validation permanente, comme son nom l’indique, est réellement
permanente. 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 deux
utilisateurs.
Un développement RAD se distingue par la mise en œuvre de plusieurs techniques de
réalisation.
§
SWAT : organisation d’une équipe de profil « concepteur-développeur » basée sur
la 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 et
utilisant 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 circulation
des 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 son
application et, par sa participation active, il s'en approprie la réalisation. Le RAD et le
prototypage permettent de réaliser en concevant, tout en testant ce que l'on réalise. Le résultat
garantit ce que l'on peut qualifier de « Really Approved Design » : une conception réellement
approuvé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 de
réalisation évolutif et ouvert. Les possibilités de cet AGL sont présentées aux utilisateurs avant
la 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 en
assistance à la réalisation des fonctionnalités spécifiques (Construction Assistance Team).
15
§
Normes de codage : normes publiées et acceptées visant à uniformiser les
techniques de codage.
§
Validation permanente : engagement continu des utilisateurs dans le prototypage
lors de réunions informelles qui engagent un ou deux utilisateurs par concepteurdéveloppeur.
§
Revue de code : principes planifiés et acceptés de vérifications croisées de la
conformité des pratiques de codage aux normes publiées.
§
Jalons zéro-défaut (ZD) : technique orientée « planning » ; elle permet de
contrôler l’avancement de l’application en matière de visibilité et de qualité. Des
jalons 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 de
cheminement par l’utilisateur de base.
§
Focus : réunion plénière de présentation et de validation du projet dans toutes ses
dimensions.
§
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 faciliter
l’évolution ultérieure de l’application. Elles sont mises en œuvre lors de la phase de
Design. 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 continue
depuis la conception, la réalisation et jusqu'à la maintenance, prolongement
naturel de la vie d’une application.
§
Structure de Construction itérative et incrémentale : dès le début de la phase de
Construction un plan d’évolution du prototype est précisé. Il définit et segmente
l’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 et
impose souvent que l’ensemble des modules soit mis en chantier
simultanément, mais à un niveau de fonctionnalité limité.
La notion de Focus couvre en pratique l’enchaînement de plusieurs étapes
contraignantes pour le SWAT (figure 5).
Le facteur décisif pour fixer la cadence des Focus doit être le nombre de
fonctionnalités additionnelles attendues.
Concrètement, un Focus débute par la planification d’une charge de travail à réaliser
dans 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 cette
manifestation permet de dégager. L’organisation de la communication préalable au
Focus 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 ayant
participé aux séances de spécification et de validation permanente sont alors impliqués
dans une étape de vérification de la qualité fonctionnelle. Le maximum de corrections
de divergences visuelles ou mineures doit être effectué. En général, la validation
permanente réduit cette tâche à une simple formalité. Cette étape cesse au plus tard
deux jours avant le Focus.
Chaque membre du SWAT focalise alors sur l’amélioration technique qualitative de
sa propre production. Si les normes de codage publiées et acceptées ont été respectées,
16
une journée suffit pour vérifier une production de deux semaines. L’équipe procède
alors à des revues croisées. Le niveau de qualité requis peut être très variable d’une
application à une autre selon sa typologie. Cette étape prend fin lorsque la qualité de
l’application atteint un niveau suffisant en robustesse, normalisation, documentation
et 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 œuvre
des données communes (externes, globales).
Les utilisateurs ayant participé aux séances de spécification et de validation
permanente 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 de
dé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 implique
un minimum de tests de non-régression et une étape complète d’intégration.
Publication des normes
Planification FOCUS
Planification Jalon ZD
PROTOTYPAGE
étape Vérification personnelle
Prise en compte
des remarques
étape Revue de code (croisée)
étape Vérification utilisateur
étape Intégration modules
Étapes M.E.
Étapes M.O.
État de livraison permanente (n)
Figure 5. — Architecture de réalisation (Focus de visibilité)
Durant le Focus, les rapporteurs devront consigner les éventuels incidents et les
observations qui ne manqueront pas d’être émises par une nombreuse assistance. Les
personnes ne participant pas aux spécifications ont souvent un avis a posteriori et
parfois une vision plus profonde ou plus précise des évolutions du métier. Ces
ressources étant le plus souvent des décisionnaires, leurs recommandations doivent
être étudiées sous un angle de vision prospective. C’est d’ailleurs souvent cette
absence de vision qui confine une application dans un cadre strictement opérationnel
alors 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 validation
interne. Entre deux Focus, les concepteurs-développeurs sont en contact avec les
utilisateurs 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 spectateurs
observent et critiquent. Le groupe d’animation et de rapport note les observations.
17
Sur le plan des communications, l’organisation d’un Focus est identique à celle d’une
session de travail. Le nombre de Focus dépend de la durée du projet et de sa
complexité22. Il est en général planifié 3 ou 4 Focus pour un « petit » projet et de 4 à 8
Focus 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 FINALISATION
Pour de multiples raisons dont notamment les techniques de validation permanente et
de jalons zéro-défaut, la recette RAD est beaucoup moins conséquente qu’une recette
classique.
La phase de FINALISATION comprend, entre autres, la formation, les activités liées
au déploiement, le bilan de projet, le retour de connaissance. Elle clôture le projet
RAD.
1.9. Objectifs et travaux par phase
Pour 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 deux
ressources expérimentées pour une durée de 30 à 90 jours. Un projet « intermédiaire » engage
une équipe (SWAT, Skill With Advanced Tools) de 4 à 6 concepteurs-développeurs pour une
durée de 60 à 120 jours. Les grands projets utilisent des techniques de parallélisation durant la
phase de DESIGN et de sérialisation durant la phase de CONSTRUCTION. La planification des
Focus dépend alors du nombre d'équipes et du style de projet.
18
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 entretien
propriétaire, l’équivalent d’une étude de faisabilité, les contraintes de la méthode et
un 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 de
modélisation au niveau « métier » précède l’automatisation du domaine. Une réunion
de lancement du projet est ensuite organisée. Elle regroupe tous les acteurs recensés et
donne lieu à l’individualisation des travaux préparatoires à la modélisation du
système.
Tableau 2. — Synthèse phase Initialisation
Objectifs de la phase
INITIALISATION
Travaux à réaliser
Formaliser les objectifs, valider le périmètre du projet et les
exigences.
Envisager un planning, l'organisation et le Plan
d’Assurance Qualité du projet.
Acteurs Produits / Livrables
GAR +
Répertorier l’ensemble
des intervenants
MOA
Plan de communication
Définir les objectifs
stratégiques du projet
MOA
Périmètre applicatif
Recherche de solutions
MOE
Rapport de faisabilité
Evaluer les moyens
nécessaires.
MOE
Evaluation des charges
Accord MOE / MOA
MOE +
Lettre d’engagement
MOA
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).
19
Phase CADRAGE
Le Cadrage et la première partie du Design s’appuient sur une approche top-down qui
permet 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 et
applique 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 la
solution globale sur les plans stratégique, fonctionnel, technologique et
organisationnel. Dans le cas où les exigences et les ressources divergeraient, des
technique « AV » permettent d’attribuer des priorités aux fonctionnalités en termes de
retour sur investissement. Cette modélisation des traitements s’effectue sous la forme
d’une hiérarchie de fonctions.
Tableau 3. — Synthèse phase Cadrage
CADRAGE
Formaliser les exigences.
Etablir le Plan de cadrage.
Engager les ressources.
GAR +
Stratégique
DG
Fonctionnel
MOA+ Hiérarchie de fonctions ou Cahier des Charges ou
Gestion des exigences
MOE
Technologique
MOE
(PPI)
Rapport de solutions
Organisationnel
MOA
Plan d’accompagnement du changement, modèle
« métier »
(CPU)
Contraintes
MOE
MOA
Objectifs hiérarchisés
Ressources, cycle de développement, planification,
etc.
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.
20
Phase DESIGN
Cette phase repose sur l’usage d’un AGL de conception léger et puissant. Dans la
mesure 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 concepteursdéveloppeurs travaillent alors en commun et en direct à la modélisation détaillée des
traitements et des données de l’application. Si la performance immédiate est
recherchée, la modélisation des données reste classique et s’appuie sur le modèle
entité-relation. La présentation d’un premier niveau de prototype conclut cette phase.
Tableau 4. — Synthèse phase Design
Définir la solution cible en termes de modèles, valider un
premier prototype
DESIGN
GAR +
Modélisation
MOE +
MOA
Documentation
technique
Révision
l'évaluation
MOE
de MOE +
Liste détaillée des fonctionnalités et modèle de
données exhaustif
Modèles issus de l’AGL de conception
Charges et planning révisés
MOA
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 avec
soin (VB, Delphi, PB, D2000, etc.) ; une charte graphique doit avoir été validée et
instrumenté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 normes
arrêtées.
21
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 informelle
de l’application.
Tableau 5. — Synthèse phase Construction
Réaliser l’application et livrer rapidement des
fonctionnalités.
CONSTRUCTION
GAR +
Publication des normes
MOE
Normes de développement
Planification FOCUS
MOE
Calendrier des présentations
MOA
Etablissement des jeux
d'essai utilisateurs
MOE
Prototypage ACTIF en
validation permanente
MOE
FOCUS
MOE
MOA
Jeux d'essai utilisateurs
Jalons zéro-défaut
MOA
Application en fonctionnalités partielles
MOA
Site Pilote
MOE
Application utilisable
MOA
Documentation
utilisateur
MOA
On-line, contextuelle, papier
Documentation
technique
MOE
Intégrée aux modules développés
Recette générale de l’application.
Phase FINALISATION
Cette phase engage surtout la MOA. Elle comprend, entre autres, la formation des
utilisateurs, 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 en
permanence par ses utilisateurs. La recette d’une application RAD est donc beaucoup
plus rapide qu’une recette classique.
Selon l’importance du projet et les principes de l’organisation en termes de recette et
de déploiement, il peut être nécessaire d’organiser tout ou partie des étapes décrites
dans les tableaux suivants.
22
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
Réalisation de la recette finale
Préparer le changement :
- préparer la recette,
- produire la documentation utilisateur,
- établir le plan de démarrage,
- transférer la connaissance aux
formateurs,
- mettre en place la nouvelle organisation.
Acteurs
MOE
Produits / Fournitures
prérequis
livrables
exigences
PV de recette
MOA
Rédaction des manuels utilisateurs
Manuels
utilisateurs
MOE
MOA
Rédaction du manuel d’exploitation
Manuel
exploitation
MOE
MOA
Préparation de la formation
MOA
Manuels
Utilisateurs
Supports de
formation
Etablissement du plan de formation,
préparation de l'environnement et de
la logistique de formation
MOA
Supports de
formation,
planning du
projet
Plan de
formation,
environnement
et logistique
d’opération
Formation des futurs formateurs
auprès des utilisateurs finaux
MOA
Supports, plan
de formation et
logistique
Formateurs
opérationnels
Mise en place des procédures
organisationnelles
MOA
Exigences
organisationnelles
Procédures
opérationnelles
Etablissement du plan de démarrage,
incluant reprises de données, la
bascule technique, les tests après
bascule.
MOA
Communication aux utilisateurs
(planning, formation, plan de
démarrage, etc.).
DG
DG
MOE
MOA
Plan de
démarrage
Notes
d'information
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 formation
et 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.
23
Etape « Recette officielle »
Tableau 7. — Synthèse Finalisation, étape recette officielle
Recette officielle
Recette de l'application avant sa mise en
œuvre. Recette de la reprise de données
avant bascule effective.
Acteurs
Prérequis
Livrables
Recette interne MOE avant livraison à la MOE
MOA :
MOA
- recette des interfaces,
- recette fonctionnelle du lot assemblé
- recette de la reprise des données
Scénarios de
tests et jeux
d’essais
Lot assemblé et
opérationnel
pour les tests
fonctionnels et
d'intégration
Application
Recette fonctionnelle utilisateurs,
incluant les interfaces et la reprise des
données
MOE
MOA
Cahier de
recette,
jeux d'essais,
application
intégrée
Application
recettée
fonctionnelle
par les
utilisateurs.
Journal des
tests.
Intégration technique du lot, incluant
les tests de charge et les tests réseau.
MOE
DTI
Application et
recette
fonctionnelle
Application
« recettée »
technique
Communication auprès des utilisateurs.
MOE
MOA
GAR
Journal des
tests
Notes
d'information
Vérification de la complétude des tests en rapprochant le journal des tests, du cahier
de recette et du jeu d'essais : par la MOA (CPU) et la MOE (PPI).
24
Etape « Organisation et Démarrage»
Tableau 8. — Synthèse, finalisation, démarrage
Organisation et démarrage
Mettre en œuvre l'application et
accompagner le changement
Acteurs
prérequis
Etablissement de l'environnement
d'exploitation et de l'infrastructure du
support d'exploitation
DTI
Mise en œuvre du plan de démarrage
(incluant la reprise des données)
MOE
Audit du fonctionnement et
évaluation des écarts :
- d'objectifs fonctionnels
- de couverture des exigences
MOE
DTI
MOE
Livrables
Manuel
Exploitation
Exploitation
opérationnelle
Application
« recettée »,
Plan de
Démarrage
Application
exploitable
Tous documents
du projet,
application
opérationnelle
Bilan,
Proposition
d'orientations
fonctionnelles
et techniques
Documents et
application en
opération
Application
optimisée
Amélioration et optimisation du
système
DTI
Formation des utilisateurs
MOA
Formateurs
formés,
supports et
logistique de
formation,
Utilisateurs
formés
Déploiement technique
DTI
Plan de
Déploiement
Application en
service
Validation du bilan et des orientations fonctionnelles et techniques.
Recette de la mise en service.
25
1.10. Principaux documents par phase
Tableau 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
Immersion
animateur
Périmètre applicatif. Plan de
communication
Réunion de
lancement
Travaux individualisés. Planning accepté
Sessions de
spécifications des
exigences
Modèle global des flux (DFD)
Cadrage
Modèle hiérarchique des traitements
Focus de fin de
Cadrage
Design
Sessions conception
solution
Focus de fin de
Design
Construction
Revues de code et
de projet
Revues
fonctionnelles
Modèle détaillé des données et (si utile)
Modèle détaillé des flux et traitements
Prototype initial
Application opérationnelle validée :
- fonctionnellement par les utilisateurs
- techniquement par jalons zéro-défaut
État de livraison
permanente
Focus de
présentation
Finalisation
Déroulements des
cheminements
fonctionnels
Homologation et recette
26
2. Bibliographies et références
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, puis
Macmillan, 1996.
Vickoff Jean-Pierre, REENGINEERING, Vite fait bien fait, Le Paradigme du futur
immé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,
d’organisation, 1995.
Mc Carty J. 54 Règles d'or pour un grand logiciel, Microsoft Press, 1997.
Les Éditions
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 Éditions
d'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 en
mutation, Stratégies d'entreprise, 1990.
Champy J. Reengineering Management, HarperCollins Publishers, 1995.
Chapman C. & Ward S. Project Risk Management : Processes, Techniques and
Insights, Edition Wiley, 1997.
27
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 Business
Revolution, 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, Editions
d’Organisation, 1998
Nizet J. & Huybrechts C. Interventions systémiques dans les organisations, Intégration des
apports 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, Texas
A&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 University
Press.,
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 of
software).
§ ISO 9004-4-1993, Quality management and quality system elements (Part 4: Guidelines for
quality 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 process
assessment, Software Quality Journal, Vol. 2, pp 257-264 (1993).
28
§ Humphrey, W.S., Managing the Software Process, Addison Wesley, 1989.
§ Kuvaja, P., Simila, J., Krzanik, L., Bicego, A., Koch, G. and Saukkonen, S., Software
Process Assessment and Improvement: The BOOTSTRAP Approach. Blackwell, 1994.
§ Bell Communications Research, Inc., Quality Program Specification for Surveillance
Management 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 Process
Assessment Training Guide, Software Engineering Institute, Pittsburgh Pennsylvania.
§ F. Coallier, N. Gammage, A.W. Graydon, Trillium - Software Process Self-assessment
Capability 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
http://www.esi.es/ESSI/Reports/All/27599/
RAD
for
MSS,
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 University
http://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 la
commission AFITEP IM-CP-Processus. Leur contribution à la formalisation des divers
aspects de la conduite de projet, a facilité la rédaction de plusieurs parties de cet
ouvrage.
29
2.6. Index
A
abstraction · 11
abstraction
métier · 10
AFNOR · 28
AGL de conception · 20
architecture
applicative · 11
assistance · 14
B
budget
cadrage · 9, 19
C
certification · 28
cohérence systémique · 19
communication
espace · 10, 20
modèle · 8, 18
plan · 8
qualité · 9
consensus
entretien · 9
CPI · 19, 23
CPU · 19, 23
customs-controls · 14
D
décomposition · 12, 13
dichotomie · 12
DSDM · 5
DTI · 23, 24
dynamique
de projet · 6
E
entité-relation · 20
entretien
de groupe · 7, 9
ergonomie · 7
F
communication · 15
pratiques · 15, 17
principe · 8
validation · 15
fonctionnalités
générales · 9
partielles · 8
spécifiques · 14
fonctionnel
cheminement · 14, 21
conformité · 15
couverture · 9, 19
domaine · 8, 18
formation
utilisateur · 17, 21
G
Gartner Group · 27
groupe de travail · 9
H
hiérarchie de fonctions · 13, 19
hiérarchie de fonctions
modélisation · 17
modèlisation · 9
I
immersion · 8
ISO · 28
J
jalons ZD · 15
James Martin · 27
L
lancement officiel · 9
livrable · 15
livraison · 5, 7, 15, 23, 25
M
maintenance
applicative · 8, 15
motivation · 9
facilitateur · 8
Focus · 5, 6, 9, 15, 16, 17, 25
Focus
N
non régression · 16
normalisation · 16
O
outil
construction · 14, 20
P
pérennité · 10
périmètre
général · 6
pilote
site · 21
planification · 8, 15, 17, 19
planification
pratiques · 15
présentation
prototype · 10, 20
processus
réingénierie · 8
prototypage · 14
prototypage
construction · 7
validation · 15
prototype · 8
prototype
évolution · 15
niveau · 7, 10, 20
Q
qualité fonctionnelle · 5, 6, 16
qualité technique · 5, 6
R
rapporteurs · 16
recette · 5, 8, 17, 21, 22, 23, 25
recette
initiale · 14, 21
partielle · 7
réingénierie · 8
30
René Descartes · 4
ressource
priorisation · 9, 19
RUP · 5
S
session pleinière · 9, 10
site pilote · 8
SPICE · 28
stratification · 10
structuration
métier · 13
technique · 11
SWAT · 7, 15, 16, 17
SWAT
composition · 10
organisation · 14
systémique
cohérence · 19
T
thèmes
découpage · 6, 9
travail de groupe · 8
typologie
risques · 16
U
utilisateur
exigences · 7
réel · 9
validation · 15
utilisateurs
approbation · 14
utilisateurs significatifs · 10, 20
V
validation permanente · 14, 16
verrouillage · 9, 19
vidéoprojecteur · 9
visibilité · 6, 15, 16
vision prospective · 16
2.7.
31
Figures
Figure 1. — Jalons décisifs du cycle projet RAD
Figure 2. — Principales étapes d’un cycle de projet à 120 jours
6
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
Jean-Pierre Vickoff est avant tout pilote de projet et concepteurdéveloppeur. Canadien et Français, il s’est spécialisé en Amérique du
Nord dans les méthodes de développements sous contraintes.
Consultant en qualité et en performance, il produit des communications
pour la presse professionnelle et des rapports pour le Gartner Group. Il
est l’auteur de plusieurs ouvrages, dont RAD et Réingenierie du
développement d’applications. Il préside la commission conduite de
projet IM-CP de l’AFITEP et interviens auprès des établissements
membres 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, de
réflexion et d’action. Pilote 2010 instrumente l’ensemble des méthodes, pratiques et outils
indispensables à la productivité du développement ainsi qu’à la qualité des applications.Pilote
2010 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’envisager
immédiatement l’acquisition d’une nouvelle culture « projet » et de l’appliquer à l’évolution de leur
profession. Dans cette optique, Pilote 2010 leur propose une couverture complète et en l’état de
l’art, des évolutions du métier. Cette ambition positionne l’ouvrage comme la Bible du
développement d’applications pour la décennie en cours.

RAD La Méthode

Transcription

Documents pareils

Détail de l`offre : Responsable MOA et Base de données (H/F

asso ancien de sion - Lycée Notre Dame de Sion à Marseille

Bras manipulateur

Longueur d`arc (avec radian) Définitions Les côtés d`un angle au

Gagnez 1 des 10 trolleys de GIVI d`une valeur de € 174,99

Formulaire de mécanique

Le secours des méthodes “agiles”

Description de l`acte infirmier et modalités de facturation

Traits D`co - Janv. 2014