Discuter:Rad (ancienne unité)

Un article de Wikipédia, l'encyclopédie libre.

J'ai viré un copyvio (mal placé, de toute façon) de [1]. Voici le texte :

	Rad (ancienne unité) fait partie du projet de la physique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à la physique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet, où vous pourrez vous y joindre et consulter la liste des tâches et des objectifs. Le portail de la physique pourrait aussi vous intéresser.
Ébauche	Cet article a été classé comme d'Avancement ébauche selon le Tableau d'évaluation du projet. (Voir les statistiques)
Faible	Cet article a été classé comme d'Importance faible selon le Tableau d'évaluation du projet. (Contester?)

RAD (Rapid Application Development), en français Développement accéléré d'application (DAA), est aussi une méthode de conduite de projet permettant de développer rapidement des applications de qualité. Les fondements méthodologiques du DAA peuvent être exprimés à travers dix principes :

[modifier] 1. Confier l’expression des besoins aux utilisateurs

Même si l’on veut aller vite, il est nécessaire de déterminer ce que l’on attend du futur système avant de commencer à le construire. Cela permet gagner du temps en évitant les retours en arrière. L’originalité du DAA est de confier la responsabilité et la description de ces attentes aux utilisateurs.

[modifier] 2. Organiser l’expression des besoins

Le DAA reconnaît que les besoins ne sont pas donnés, qu’il ne suffit pas de les recueillir ou d’observer un fonctionnement existant. Les exprimer requiert un travail de distanciation et d’imagination de la part des utilisateurs. La méthode les aide, sans leur demander un apprentissage spécifique. Le DAA permet par ailleurs de gérer la diversité des points de vue, car les besoins exprimés peuvent être multiples et contradictoires.

[modifier] 3. Introduire une dimension temporelle dans l’expression des besoins

II est souvent difficile, voire périlleux, d’arrêter l’expression des besoins au terme d’un délai réduit. Le DAA permet d’affiner progressivement les besoins, par une organisation adéquate, suffisamment souple pour prendre en compte des modifications. La méthode prévoit des garde-fous pour éviter le « syndrome de Pénélope » : défaire la nuit ce qui a été fait le jour...

[modifier] 4. Ajuster les besoins

Le DAA propose un renversement dans la définition du périmètre de l’application. Classiquement, le recensement des fonctions du futur système permet de déterminer la charge de réalisation. Le DAA offre une perspective inverse : on limite volontairement la durée du développement et on ajuste le contenu de l’application. Cela conduit les utilisateurs à faire des choix. Ils se centrent sur les fonctions essentielles. D’autres, jugées secondaires, sont réduites, abandonnées ou différées.

[modifier] 5. Raccourcir les circuits de décision

Sans décision, l’avancement du projet est fictif. L’expérience montre que les décisions se prennent difficilement dans les projets qui mettent en jeu de nombreux utilisateurs. Ceci pénalise la durée de projet. C’est pourquoi le DAA organise le projet de façon à y intégrer les décideurs. Les modalités de conception et de développement sont adaptées à des décisions rapides.

[modifier] 6. Structurer les problèmes selon la structure de décision

Pour aller vite, il faut pouvoir partager le travail. Le découpage du domaine se base en grande partie sur la structure de décision de l’entreprise. Chaque élément du domaine relève d’un décideur pertinent qui participe au projet.

[modifier] 7. Utiliser des techniques existantes

Le DAA ne mise pas sur l’invention d’une technique « miracle ». La réussite réside dans l’assemblage de différentes techniques utilisées de façon judicieuse. Le DAA s’appuie sur quatre techniques spécifiques :

• JRP [IBM, 1984] : cette technique est une aide à l’expression des besoins par les utilisateurs ;
• JAD [IBM, 1984] : cette technique organise le processus de conception de façon à y faire participer les utilisateurs ;
• Time-box [Dupont, 1989] : cette technique limite la durée de la réalisation à une enveloppe-temps maximale ;
• Pilotage RAD : cette technique permet de placer le projet sous contrôle, pour en garder la maîtrise. La méthode structure par ailleurs l’utilisation du prototypage.
• Enfin, deux techniques complémentaires, l’estimation des charges et l’organisation de la réutilisabilité, favorisent la réussite d’un projet RAD.

[modifier] 8. Travailler en session participative

Le travail en session participative est un mode de travail collectif, intense et limité dans le temps. Il réunit utilisateurs et informaticiens. Cela permet aux utilisateurs de faire une coupure dans leur activité opérationnelle, pour prendre des décisions à moyen terme. Par ailleurs, cela favorise la constitution d’une équipe et accompagne la recherche de consensus.

[modifier] 9. Anticiper

Si l’on veut aller vite, tout en conservant le principe du travail en groupe, il est nécessaire d’organiser rigoureusement les travaux préparatoires aux sessions. Toute réunion doit être préparée. La charge de préparation est répartie entre différents acteurs. Cela permet d’engager chaque participant et d’alléger le poids du travail en groupe.

[modifier] 10. Utiliser des outils performants

Les outils allègent le travail. L’outil de prototypage s’accompagne en général d’une aide à la conception et d’un référentiel, facilitant la documentation et la réutilisation.