1er avril 2005
7.
Méthodologie
Résumé :
La réalisation devra suivre une méthodologie compatible avec les pratiques du projet « halfj ». |
Lotissement
Pour ses applications web, le projet « halfj »
suit habituellement un plan de lotissement tel que ci-dessous : - un prototype papier,
- un dossier de maquettage HTML,
- une maquette HTML fonctionnelle,
- l'application web finale.
Le but du prototype papier
est de convenir des enchaînements d'écrans, et des scénarios fonctionnels qui seront suivis lors des tests, ainsi que pour la validation.
On ne demande pas de réalisation technologique pour ce lot : il peut s'agir d'un document électronique Adobe Illustrator imprimable en CMYK sur du papier A4, comme ce peut être un document papier avec de simples dessins à main levée.
En revanche, les principaux éléments de maquettage doivent être montrés, ainsi que la cinématique de navigation.
Le dossier de maquettage doit être un ensemble de pages HTML consultables hors ligne, idéalement depuis un CD-ROM ou une archive « .zip », avec parcours séquentiel page à page. Ce dossier est à destination des équipes de validation, ergonomique et fonctionnelle. Il sert à valider : - l'intégration dans le site principal,
- l'aspect multilingue,
- la mise en forme du HTML,
- la taille du HTML,
- les temps d'affichage du HTML,
- le respect des normes HTML,
- le respect des contraintes d'ergonomie HTML du projet « halfj », notamment la présence de
@title
dans les liens hyper-texte.
La maquette fonctionnelle est un site web dynamique, qui réagit correctement aux paramètres HTTP saisis, et qui couvre toute la combinatoire des possibilités, mais qui ne sert pas d'indicateur de performances ou de temps de réponse du serveur. En plus des points de validation fournis par le dossier de maquettage, la maquette fonctionnelle sert à valider : - les enchaînements d'écrans,
- la bonne gestion des paramètres HTTP,
- le comportement de l'application en fonction des actions de l'utilisateur.
C'est sur l'application web finale
que seront soumis à validation les temps d'accès serveur. Par rapport à la maquette fonctionnelle, cette livraison est vue en général comme une optimisation des temps de traitements serveur.
Validations
Des cycles de validation par le projet « halfj » ont lieu à chaque livraison d'un lot, en général en parallèle de la réalisation du lot suivant.
Ce point est souvent compris en disant que le projet suit un « cycle itératif », même si ce n'est pas rigoureusement le cas. En tout état de cause, ces validations intermédiaires font partie d'une démarche de pilotage par les risques.
Chaque cycle de validation s'organise de la façon suivante : - réception du lot.
- confrontation du lot livré aux cahier des charges technique.
- confrontation du lot livré aux cahier des charges fonctionnel.
- rédaction d'un bilan de validation.
- arbitrage. Retour éventuel en 1, après amendement du cahier des charges pour préciser les point d'évolutions.
- validation, ou rejet, du lot.
Conduite de projet
La conduite de projet est à la charge de l'intégrateur.
Toutefois, le projet « halfj » souhaite avoir des rapports en début, en cours, et en fin de réalisation, afin de s'assurer au fil de l'eau que le besoin initial a correctement été compris, que la réalisation finale répondra bien à ce besoin, et afin d'être informé des imprévus et des difficultés rencontrées.
Suivi de l'avancement
Un état des lieux régulier sera fourni par l'intégrateur au projet « halfj », sous la forme : - d'une liste de livrables, avec une description détaillée de chaque livrable,
- d'un lotissement des livraisons,
- d'une liste de tâches « visibles » par le projet « halfj »,
- d'un curseur d'avancement (de 0% à 100%) sur chaque tâche,
- d'un suivi des difficultés rencontrées,
- d'un échéancier global : rétro-planning sur les tâches en cours, et planning à venir.
Cet état des lieux devra pouvoir être présenté sous une forme textuelle linéaire, par exemple un document papier.
Documentation
Dossier de couverture fonctionnelle
L'intégrateur aura la charge de fournir une documentation fonctionnelle qui devra préciser la couverture fonctionnelle de l'application livrée.
Ce document est à destination de la maintenance.
Audit d'ergonomie
L'intégrateur aura la charge de fournir une liste des principes d'ergonomie suivis par l'application livrée.
Documentation d'architecture
La documentation d'architecture technique fournie en fin de réalisation par l'intégrateur devra couvrir les aspects suivants : - architecture physique de livraison du système : les différents matériels, systèmes, et tous produits, sur lesquels l'installation finale de l'application aura eu lieu. Les documentations d'architecture physique devront mentionner les dates des « photos », les caractéristiques techniques et les versions des produits, et les volumétries constatées ou prévues. Elles ne doivent pas recenser les différents niveaux de déploiement.
- architecture physique d'intégration : l'architecture physique qui aura servi à la validation de l'application par le projet « halfj ».
- architecture de déploiement d'intégration : les différentes configurations de déploiement des composants techniques, dans son instance d'intégration. Cette documentation sur la configuration d'intégration doit être exhaustive.
- architecture physique de qualification : l'architecture physique qui aura servi à la qualification de l'application par l'intégrateur, ainsi que les produits utilisés, notamment les outils de mesures de performances.
- architecture de déploiement de qualification : les différentes configurations de déploiement, utilisées pour la qualification de l'application par l'intégrateur.
- architecture physique de développement : l'architecture physique qui aura servi au développement, ainsi que les produits utilisés, notamment l'environnement de développement.
- architecture technique du système : les différents composants techniques du système à déployer : ordonnanceurs, applications, bases de données, annuaires... Cette documentation ne doit pas préciser les versions des produits, mais seulement leur rôle logique. Elle doit décrire les standards utilisés dans la réalisation, ainsi que les principaux enchaînements d'activités et les principaux protocoles et flux.
- architecture logique de composants : les différents composants techniques de l'application à installer : modules, frameworks, fichiers de configuration, fichiers statiques... Cette documentation doit décrire les principaux enchaînements d'activités, et les principaux protocoles et flux.
Documentation de conception
La documentation de conception fournie par l'intégrateur devra être exhaustive quant aux packages et fichiers qui constituent l'application.
|