Meilleures pratiques de développement des sites et - DSI

Meilleures pratiques de développement des sites et - DSI
Centre national de la recherche scientifique
Direction des systèmes d'information
Meilleures pratiques de développement
des sites et applications Web à la DSI
Référence : CNRS/DSI/BMSD/Qualité/meilleures-pratiques.doc
Date : 24/01/2005
Version : 2.0
Auteurs : groupe de travail "développement des applications Web à la DSI"
Diffusion : DSI
Objet du document : identifier les meilleures pratiques pour le développement de sites et d'applications Web à la
DSI.
Développement des sites et applications Web à la DSI : meilleures pratiques
Table des mises à jour du document
Version
Date
Objet de la mise à jour
1.0
09/05/2003
Modifications apportées à la forme du document (mise en gras
des pratiques, ajout de commentaires ou justifications).
Insertion de recommandations issues d’un document existant
déjà à la DSI : « démarche de conception de sites Web ».
Mise à disposition du document par le groupe de travail.
1.1
16/05/2003
Ajouts de précision au niveau du cahier des charges, de la
déclaration CNIL et des références vers le site
« Développement Web » de la DSI.
1.2
21/10/2003
Changement de références pour la déclaration CNIL : de la DAJ
à la DSI.
1.3
14/04/2004
Suppression des adresses mail (pour éviter les Spam).
1.4
18/05/2004
Remplacement de la fiche de cadrage par une note de cadrage,
validée par la maîtrise d’ouvrage.
Suppression de la demande de modification (non appropriée).
Ajout d’un tableau de suivi des anomalies.
1.5
07/07/2004
Ajout de dispositions sur :
- l’application de la charte graphique CNRS,
- l’identification de l’impact sur les équipes SSI en délégation,
- les aspects communication,
- le suivi d’avancement mensuel.
Suppression de la pratique « mettre à disposition du prestataire
des locaux à la DSI ».
2.0
24/01/2005
Intégration de la démarche d’expression et analyse des
besoins avec UML.
Renforcement des relations avec l’équipe RUE (démarche
d’urbanisation).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
2 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
Liste des processus et activités
FIG. 1 : CYCLE DE VIE ---------------------------------------------------------------------------------------------------------------------------------------5
FIG. 2 : ACTEURS DU PROJET---------------------------------------------------------------------------------------------------------------------------6
PRO : PROCESSUS DE PRODUCTION ---------------------------------------------------------------------------------------------------------------7
PRO-1
PRO-2
PRO-3
PRO-4
PRO-5
PRO-6
Intégration dans le système d'information .............................................................................. 7
PRO-1.1
Identifier le périmètre de l’application _______________________________________ 7
PRO-1.2
Identifier les interactions avec d'autres applications ___________________________ 7
PRO-1.3
Profiter des retours d’expérience DSI_______________________________________ 7
PRO-1.4
Rédiger une note de cadrage _____________________________________________ 7
PRO-1.5
Prendre en compte les activités transverses à la DSI__________________________ 8
Maîtrise de la technologie....................................................................................................... 10
PRO-2.1
Intégrer le BEST dans le projet____________________________________________ 10
PRO-2.2
Comprendre les technologies utilisées _____________________________________ 11
Expression des besoins et exigences...................................................................................... 12
PRO-3.1
Recueillir et analyser les besoins fonctionnels et opérationnels _________________ 12
PRO-3.2
Développer une maquette ________________________________________________ 13
PRO-3.3
Identifier l'environnement technique de production_____________________________ 14
Conception-réalisa tion ............................................................................................................ 15
PRO-4.1
Rédiger la documentation fonctionnelle détaillée______________________________ 15
PRO-4.2
Concevoir l'architecture de l'application _____________________________________ 15
PRO-4.3
Rédiger la documentation technique _______________________________________ 16
Validation et recette................................................................................................................ 17
PRO-5.1
Organiser les validations et les recettes ____________________________________ 17
PRO-5.2
Gérer les anomalies ____________________________________________________ 18
PRO-5.3
Valider fonctionnellement l'application ______________________________________ 18
PRO-5.4
Valider techniquement l'application ________________________________________ 18
Accompagnement du changement ......................................................................................... 19
PRO-6.1
Constituer le système d'aide _____________________________________________ 19
PRO-6.2
Mettre en place le circuit d'assistance aux utilisateurs ________________________ 19
PRO-6.3
S’assurer de la mise en place d’actions de communication_____________________ 19
SUP : PROCESSUS DE SUPPORT ---------------------------------------------------------------------------------------------------------------------20
SUP-1
SUP-2
SUP-3
SUP-4
SUP-5
Conduite de projet .................................................................................................................. 20
SUP-1.1
Maîtriser les relations avec la maîtrise d'ouvrage et les utilisateurs _______________ 20
SUP-1.2
Favoriser les échanges au sein du bureau___________________________________ 21
SUP-1.3
Effectuer un suivi réactif du projet__________________________________________ 21
SUP-1.4
Suivre un cycle de vie itératif et incrémental _________________________________ 23
SUP-1.5
Capitaliser les connaissances du projet ____________________________________ 23
Gestion de la sous-traitance .................................................................................................... 24
SUP-2.1
Constituer le cahier des charges __________________________________________ 24
SUP-2.2
Contractualiser ________________________________________________________ 24
SUP-2.3
Informer l'équipe projet des dispositions contractuelles ________________________ 25
SUP-2.4
Maîtriser les relations avec le prestataire____________________________________ 25
Gestion de la documentation .................................................................................................. 27
SUP-3.1
Gérer la documentation sur serveur DSI ____________________________________ 27
SUP-3.2
Identifier les modèles de document et les livrables ____________________________ 27
Gestion de configuration logiciel ............................................................................................ 29
SUP-4.1
Gérer les environnements ________________________________________________ 29
SUP-4.2
Gérer les livraisons du prestataire _________________________________________ 29
SUP-4.3
Organiser l'exploitation __________________________________________________ 30
Gestion des changements....................................................................................................... 31
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
3 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP-5.1
SUP-5.2
Gérer les évolutions en cours de développement _____________________________ 31
Préparer la réalisation d'une version en maintenance __________________________ 31
Introduction
Organisation du document
Ce document présente les pratiques retenues à la DSI pour le développement des site et applications Web. Ces
meilleures pratiques sont regroupées par activités au sein de processus.
Exemple :
Processus : PRO-1 Intégration dans le système d'information
Activité : PRO-1.1 Identifier le contexte d'utilisation de l’application
Pratique : 1. Identifier les rôles et responsa bilités des différents acteurs (utilisateurs).
Les processus sont classés en deux catégories : production et support.
Chaque processus est identifié par le code de la catégorie (PRO ou SUP) suivie d'un numéro (exemple PRO-1).
Chaque processus est caractérisé par des principes, puis est décomposé sous forme d'activités.
Chaque activité est référencée par l'identifiant du processus + un numéro (exemple PRO-1.1). Chaque activité est
énoncée sous forme de phrase commençant par un verbe à l'impératif, puis est déclinée sous forme de pratiques
visant à satisfaire les principes du processus.
Chaque pratique est énoncée sous forme de phrase (en caractères gras) commençant par un verbe à l'impératif. La
pratique peut être suivie de renseignements complémentaires ou d'exemples. Les pratiques sont numérotées (1, 2,
3…). Les pratiques sont issues des retours d'expérience des projets de la DSI ou de l'état de l'art des meilleures
pratiques.
Le présent document ainsi que les modèles des documents référencés dans les meilleures pratiques (note de
cadrage, fiche de suivi de projet, etc.) sont disponibles dans le site « Développement Web » de la DSI :
http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/.
Définitions :
• Application Web : « il s’agit d’applications où l’utilisateur interagit avec un serveur Web, que ce soit en
intranet ou en internet, pour accéder à des données ou des services. L’interaction est personnalisée et ne se
limite pas à la recherche d’information classique traitée dans la catégorie site Web » (source : ADAE).
• Site Web : « il s’agit pour l’essentiel de «pousser » de l’information vers l’utilisateur, en le guidant au
mieux » (source : ADAE).
Les pratiques retenues dans ce document s’appliquent indifféremment aux applications ou aux sites Web. Afin de
simplifier la formulation, le terme « application » est utilisé.
Pour les pratiques dédiées aux sites Web, il est mentionné explicitement « Dans le cas de sites Web, … ».
Abréviations
•
•
•
•
•
•
•
•
•
ADAE = agence pour le développement de l’administration électronique
BAGA = bureau des affaires générales et de l'administration de la DSI
BBFC = bureau budget, finances et comptabilité de la DSI
BEST = bureau d'études et de support techniques de la DSI
BGAS = bureau gestion des activités scientifiques de la DSI
BMSD = bureau des méthodes et du support à la déconcentration de la DSI
BPRH = bureau gestion du personnel et des ressources humaines de la DSI
BSU = bureau du support aux utilisateurs de la DSI
DSI = direction des systèmes d’information
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
4 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
FIG. 1 : CYCLE DE VIE
Phases
PROCESSUS
Etude préalable
Construction
Mise en
production
Intégration dans le
système
d'information
Maîtrise de la
technologie
Expression des
besoins et exigences
Conceptionréalisation
Validation et recette
Maquette
Version
incrémentale
Validation
maquette
Recette
intermédiaire
Version
finale
Recette
finale
Accompagnement du
changement
Conduite de projet
Gestion de la soustraitance
Gestion de la
documentation
Gestion de
configuration logiciel
Gestion des
changements
Légende : importance de la charge de travail et de la criticité des processus dans les phases
Forte
Moyenne
Faible
Absente
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
5 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
FIG. 2 : ACTEURS DU PROJET
Représentants
maîtrise d'ouvrage
Equipe fonctionnelle
(BBFC, BGAS ou BPRH)
Groupe
d'utilisateurs
Equipes SSI
en délégation
Gestionnaire
des marchés
(BAGA)
Equipe projet
Prestataire
Ergonome, graphiste, méthodes,
animation RSI (BMSD)
Equipe technique (BEST)
Assistance aux utilisateurs (BSU)
informations
sur
l'application
pratiques,
orientations
retours
d'expérience
règles
Equipe RUE :
- urbanisation
- référentiel
- EAI
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
Groupe de travail :
- applications Web
DSI
24/01/2005
6 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO : PROCESSUS DE PRODUCTION
PRO-1 Intégration dans le système d'information
Chaque nouvelle application fait l'objet d'une réflexion préalable de positionnement et d'intégration dans le système
d'information existant.
Une note de cadrage du projet décrit le contexte d'utilisation de l'application et permet de mobiliser les ressources
transverses intervenant sur le projet.
PRO-1.1 Identifier le périmètre de l’application
1.
Identifier les rôles et responsabilités des différents acteurs (utilisateurs).
Il faut se demander quels sont les utilisateurs (en termes de rôles) que l’on souhaite atteindre et non
pas qu’est-ce que le Web nous permet de faire (l’application doit être agencée en fonction des
différents profils d’utilisateurs visés). Les utilisateurs ciblés sont les utilisateurs «directs», ceux qui
auront besoin des pages et non pas tous ceux qui pourront y accéder.
Lorsque l’application sera en production, on pourra chercher à mieux connaître les utilisateurs par le
biais d’un questionnaire accessible depuis l’application ou d’une enquête de satisfaction (envoyée
aux abonnés d’une liste de diffusion si elle existe).
2.
Etudier le processus métier concerné et identifier le périmètre de l’application.
3.
Utiliser l’outil PowerAMC pour modéliser les acteurs et processus métier.
Cf. guide « Expression et analyse des besoins en UML avec PowerAMC »
PRO-1.2 Identifier les interactions avec d'autres applications
4.
Commencer à lister les flux de données avec d'autres applications, identifier les données de
référence, se positionner par rapport à la plate-forme EAI.
5.
Prévoir les évolutions nécessaires d'applications existantes (pour permettre les échanges).
6.
Identifier d’où l’application sera accessible.
PRO-1.3 Profiter des retours d’expérience DSI
7.
Parcourir d’autres applications Web appartenant au contexte de l’application : identifier les
caractéristiques à reconduire.
8.
Consulter la base de connaissances DSI (site « Développement Web » de la DSI).
PRO-1.4 Rédiger une note de cadrage
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
7 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
9.
Rédiger une note de cadrage du projet.
10. Faire valider la note de cadrage par la maîtrise d’ouvrage du projet et la direction de la DSI.
PRO-1.5 Prendre en compte les activités transverses à la DSI
11. Transmettre la note de cadrage du projet au staff DSI, ainsi qu’à l'ergonome, au graphiste, à
l’animateur du réseau RSI (BMSD), à l’équipe RUE (groupes de travail référentiels partagés,
EAI et urbanisation).
12. Organiser une réunion de lancement avec l’ergonome et le graphiste DSI pour définir le
périmètre de leurs interventions et les modalités d’application de la charte graphique
CNRS.
Au cours de cette réunion de lancement :
•
l’équipe projet précise le contexte du projet,
•
l’ergonome présente le type d’intervention proposé compte tenu du contexte du projet
(nature, état d’avancement, délais, etc.) : élaboration de règles d’ergonomie et/ou inspection
ergonomique (si des écrans existent déjà). L’ergonome explique l’objectif de chacune de ces
actions,
•
le graphiste présente les principes génériques de la charte graphique (accompagnés
d’exemples). La charte graphique CNRS doit être adoptée par toute application Web produite
par la DSI, de manière plus ou moins forte selon les possibilités de la technologie.
L’application de cette charte graphique implique de faire appel à plusieurs compétences
transverses à la DSI : les points de contact privilégiés pour l’équipe projet sont l’ergonome et
le graphiste DSI ; ceux-ci feront le lien avec d’autres compétences à la DSI au niveau de la
communication CNRS (correspondant DIST, qui définit en particulier les codes couleurs) et
au niveau des technologies Web (pour l’intégration des éléments graphiques dans les
pages).
13. Organiser une réunion de lancement avec l’équipe RUE pour définir le périmètre de leurs
interventions.
Au cours de cette réunion de lancement :
•
l’équipe projet précise le contexte du projet,
•
l’équipe RUE présente les modalités d’intégration dans le SI global : au niveau de la définition
et utilisation des référentiels partagés, de la mise en œuvre des flux via la plate-forme EAI,
de la définition des services applicatifs…
14. Identifier l’impact de l’application sur les équipes SSI (services du système d’information)
en délégation et définir leur rôle.
Contacter l’animateur du réseau RSI à la DSI (BSMD) pour définir la participation des équipes SSI au
projet :
•
si l’impact sur les équipes SSI est faible voire inexistant en terme de participation au
développement et à l’exploitation de l’application, il s’agira seulement de les tenir informés
(via des mails, les Journées Trimestrielles…),
•
s’il y a lieu d’impliquer davantage les équipes SSI, leur participation peut s’effectuer via des
groupes de travail, des sessions de formation…
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
8 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
15. Prévenir l'assistance aux utilisateurs de la DSI (BSU) de la date de mise en production de
l'application (nouvelle application ou nouvelle version).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
9 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-2 Maîtrise de la technologie
L'équipe fonctionnelle comprend suffisamment les aspects techniques pour pouvoir dialoguer avec le BEST et le
prestataire.
Les choix stratégiques techniques du projet (respect des orientations cibles) sont confiés au BEST.
PRO-2.1 Intégrer le BEST dans le projet
16. Informer les responsables du BEST dès le début du projet en formalisant la demande, leur
transmettre la note de cadrage du projet.
17. Déterminer si la conception-réalisation de l'application est confiée à un prestataire ou
s'effectue en interne au BEST.
La réalisation en interne d’une application permet d'acquérir une expertise technique DSI facilitant les
réalisations ultérieures en sous-traitance (cas des applications expérimentales).
18. Demander aux responsables de BEST d'identifier les intervenants BEST dans le cadre du
projet.
En particulier pour :
•
la définition du cahier des charges technique et les relations avec le prestataire éventuel,
•
le développement (si interne DSI),
•
la mise en œuvre des environnements de recette et de production,
•
la préparation et la mise en exploitation.
19. Organiser une réunion de lancement avec les intervenants du BEST et planifier leurs
interventions.
20. Planifier des réunions techniques (avec l'équipe fonctionnelle, le BEST et le prestataire).
En particulier pour :
•
la présentation de l'architecture technique retenue (en début de développement),
•
la présentation de l'architecture technique détaillée et des procédures d'installation et
d'exploitation (en fin de développement).
21. Permettre les relations directes entre le BEST et le prestataire (tracées dans des
documents).
Il s’agit pour cela :
•
d’identifier les interlocuteurs, noms, adresses mél et tél,
•
de demander que les décisions prises soient tracées dans des documents (méls, comptesrendus de réunion ou relevés de conclusions) adressés en copie à l'équipe fonctionnelle.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
10 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-2.2 Comprendre les technologies utilisées
22. Rechercher les informations sur l'environnement technique retenu pour l'application (cf. site
« Développement Web » de la DSI).
23. Demander les formations ou sensibilisations nécessaires auprès du chef de bureau.
24. Partager l'information entre le BEST et l'équipe fonctionnelle.
Par exemple, organiser des réunions, les échanges de documents, prévoir la présence de l'équipe
fonctionnelle lors d'interventions de BEST ou de présentations techniques.
25. Demander au BEST sous forme écrite, les argumentaires sur les choix techniques.
26. Rendre les documents techniques accessibles à l'équipe fonctionnelle, y compris les méls.
Tous les documents, y compris les méls doivent être stockés dans le répertoire de la documentation
du projet, sur serveur de la DSI.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
11 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-3 Expression des besoins et exigences
Les exigences fonctionnelles sont minimales mais rapidement complétées par la manipulation d'une maquette ou
d'une version incrémentale de l'application.
La prise en compte du graphisme et de l'ergonomie est primordiale et intervient dès le début du projet.
Le choix de l'environnement technique s'effectue également dès le début du projet.
PRO-3.1 Recueillir et analyser les besoins fonctionnels et opérationnels
27. Faire choisir le nom de l'application par le groupe des utilisateurs.
28. Recueillir les besoins fonctionnels (mais surtout pas en termes de solutions).
•
Différentes techniques, issues de l’ergonomie, peuvent être utilisées : questionnaires, entretiens
individuels ou collectifs, observations sur site afin de repérer les procédures de travail des
utilisateurs.
•
Définir les besoins à un niveau global.
•
Accepter leur incomplétude. Spécifier le minimum. Arrêter de spécifier dès que la maîtrise
d'ouvrage et les utilisateurs sont d'accord.
•
Vérifier que la formulation de chaque besoin est claire et concise, que l'énoncé est concentré sur
une seule idée, que chaque besoin est vérifiable.
•
Si on n'a pas assez d'éléments pour détailler un besoin dans une itération : le changer de priorité
et le passer à une autre itération.
29. Demander aux utilisateurs de classer les besoins fonctionnels par ordre de priorité (en tenir
compte pour constituer les versions incrémentales et pour organiser la navigation).
Pour cela, analyser la valeur ajoutée de chaque besoin, informer les utilisateurs des contraintes
techniques, de performance, de délais… puis trancher dans le sens de la simplification.
Les tâches les plus importantes apparaîtront sur la page d’accueil et seront toujours accessibles.
30. Recueillir les exigences opérationnelles.
Par exemple : gestion des accès et des autorisations, sécurité et intégrité des données, nombre
d'utilisateurs, durée de vie….
31. Utiliser l'outil PowerAMC pour modéliser le contexte statique, dynamique, les cas
d’utilisation et le modèle du domaine.
Cf. guide « Expression et analyse des besoins en UML avec PowerAMC »
32. Formaliser les exigences dans un document Exigences fonctionnelles. Insérez les
diagrammes PowerAMC dans ce document Word.
Cf. guide « Expression et analyse des besoins en UML avec PowerAMC »
33. Transmettre les Exigences fonctionnelles à l’équipe RUE.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
12 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-3.2 Développer une maquette
Définition :
Maquette = représentation graphique des pages, du système de navigation et donc du découpage en tâches pour
l'utilisateur. Son développement ne s'effectue pas forcément dans la technologie retenue pour l'application ; la
maquette est a priori jetable.
34. Définir l'enchaînement des pages de l'application et les règles d’ergonomie.
Dans un premier temps, il s’agit d’identifier les principes génériques d'ergonomie (navigation, en
respectant la charte graphique CNRS) puis ensuite de définir les règles d'ergonomie spécifiques à
l'application. Pour cela, faire intervenir l'ergonome de la DSI.
35. Utiliser l'outil PowerAMC pour modéliser la navigation dans les pages de l’application.
Cf. guide « Expression et analyse des besoins en UML avec PowerAMC »
36. Formaliser les exigences d’ergonomie, graphisme et d’interface utilisateur dans un
document Conception de l’interface utilisateur. Insérez les diagrammes PowerAMC dans ce
document Word.
Cf. guide « Expression et analyse des besoins en UML avec PowerAMC »
37. Décliner la charte graphique CNRS pour l’application.
La charte graphique CNRS doit être appliquée sur les pages de l’application. Pour cela, faire
intervenir le graphiste de la DSI (qui travaille avec une personne ayant des compétences au niveau
des technologies Web à la DSI). Dans un premier temps, une rencontre est organisée avec le
prestataire afin de déterminer la faisabilité de la mise en oeuvre de la charte en fonction des
contraintes techniques. Ensuite le graphiste produit la ligne graphique de l’application et fournit des
fichiers graphiques (gif).
Si le graphisme est sous-traité au prestataire, le graphiste DSI lui communique, dans un premier
temps, la charte graphique CNRS générique et les codes couleurs, puis il doit valider les travaux
graphiques réalisés par le prestataire.
38. Faire une maquette en interne à la DSI ou la demander au prestataire.
L’équipe projet peut utiliser l'outil Frontpage, PowerPoint ou Word pour réaliser une maquette des
pages. On ne peut maquetter qu’une branche type de l’application : la plus importante ou la plus
délicate.
La réalisation de la maquette permet de réajuster/finaliser les règles d’ergonomie (prise en compte
des contraintes techniques, ajout de règles…).
Sur demande de l’équipe projet, une première maquette HTML peut être fournie la personne de la DSI
ayant des compétences en technologies Web, maquette intégrant la charte graphique. Dans ce cas,
une rencontre est organisée avec le prestataire pour valider la solution technique d’intégration de la
charte graphique.
39. Utiliser des données réalistes dans la maquette.
L’objectif est que les utilisateurs ne se focalisent pas sur les données elles-mêmes.
40. Effectuer une revue sur l’ergonomie et le graphisme de la maquette.
Cette revue s’effectue en présence, si possible, de l’ergonome et du graphiste de la DSI, d'un
représentant de l'équipe fonctionnelle et du prestataire s’il y a participé : elle permet d'ajuster les
règles d'ergonomie et l’application de la charte graphique avant de montrer la maquette aux
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
13 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
utilisateurs (si le prestataire et l’équipe projet sont sur des lieux géographiques différents de celui de
l’ergonome et du graphiste, les remarques se font par mèl).
41. Organiser pour les utilisateurs une réunion de présentation et d'évaluation de la maquette.
Au cours de cette réunion, leur préciser les éléments à valider, leur laisser manipuler la maquette,
recueillir leurs remarques. Pour cela :
•
soit on leur demande de réaliser une succession de tâches que l’on aura décrites dans un
scénario, tâches représentatives des tâches réelles,
•
soit on leur laisse le temps de naviguer et de découvrir l’application comme bon leur semble
à travers une exploration libre mais commentée de leur part.
En plus des observations que l’on aura faites, on pourra demander ensuite aux utilisateurs ce qu’ils
pensent de l’application : est-ce que la navigation leur semble intuitive, les informations faciles à
trouver et s’ils se sont bien familiarisé avec l’ensemble de l’application, est-ce que l’organisation de
l’application est en accord avec leur mode de travail, est-ce que les informations ont pertinentes,
complètes…
42. Vérifier la cohérence entre la maquette et la formalisation des besoins fonctionnels.
Il s’agir d’éviter les redondances de spécification (alléger si besoin la formalisation des besoins). En
complément de la maquette, on peut tout de même garder les principes génériques.
PRO-3.3 Identifier l'environnement technique de production
43. Respecter les orientations techniques préconisées par BEST (cf. site « Développement
Web » de la DSI).
44. Demander au BEST de définir l'environnement technique cible, de mettre en valeur les
points critiques (dans le cahier des charges).
45. Définir avec BEST les responsabilités et les exigences pour l'exploitation (dans le cahier des
charges).
Par exemple :
•
la journalisation des événements et des incidents : stockage des fichiers log dans un même
répertoire, délai d'épuration, mentions indispensables en dehors de la date de début et de fin,
éléments critiques qui permettront de savoir si l'opération s'est bien déroulée, gestion des incidents…
•
les statistiques d'utilisation : volume, fréquence, pages concernées, mesure de performances
(requêtes..)...
•
etc.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
14 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-4 Conception-réalisation
La conception fonctionnelle (architecture applicative) est généralement confiée au prestataire. La documentation
fonctionnelle doit favoriser la maintenabilité de l'application.
S'il n'est pas possible d'effectuer suffisamment de livraisons de versions incrémentales de l'application, les itérations
peuvent s'appuyer sur des livraisons et ajustements de la documentation fonctionnelle. Si les ajustements de chaque
itération s'effectuent sur des versions incrémentales de l'application, la documentation revêt moins d'importance en
cours de construction mais doit tout de même exister et être à jour en fin de développement (fin de la prestation).
La conception technique est généralement confiée au prestataire. La documentation technique doit favoriser la
maintenabilité de l'application.
PRO-4.1 Rédiger la documentation fonctionnelle détaillée
46. Généralement, confier la rédaction initiale de la documentation fonctionnelle détaillée au
prestataire.
Par la suite, les mises à jour en maintenance sont de préférence réalisées en interne DSI et
constituent le cahier des charges des nouvelles versions.
47. Exiger une trame minimale (mais suffisante) de documentation fonctionnelle détaillée.
Cette documentation contiendra : architecture fonctionnelle, règles de gestion, algorithmes,
enchaînement des pages, lien entre les champs dans les pages et les données du modèle, modèle
de données logique et physique ; mais pas besoins de description textuelle des écrans.
48. Construire la documentation de manière itérative.
Il s’agit de faire rédiger et ajuster la documentation fonctionnelle détaillée au fur et à mesure du
développement (ne pas attendre que la documentation soit terminée et validée pour démarrer la
réalisation de l'application).
49. En interne à la DSI, maintenir à jour les règles d'ergonomie et la ligne graphique
spécifiques à l’application.
A priori, ces documents ne doivent pas évoluer beaucoup.
PRO-4.2 Concevoir l'architecture de l'application
50. Recommander l’élaboration et la publication de schémas de données XML.
Ceci permet de favoriser l’interopérabilité et la dématérialisation des échanges et de faciliter la
conservation des documents échangés.
Préférer l’utilisation de schémas XML à celle des DTD.
51. Demander à l'équipe de réalisation (prestataire ou BEST) de respecter les principes
d’interopérabilité.
Ce qui se traduit par :
•
Eviter autant que possible les choix propriétaires, par définition trop liés à un fournisseur et peu
interopérables.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
15 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
•
Privilégier les solutions faisant l'objet d'une activité de standardisation.
•
Privilégier les solutions basées sur des systèmes ouverts, modulaires et évolutifs.
•
Favoriser l'utilisation de frameworks techniques, de composants…
•
Argumenter les choix technologiques.
•
Stabiliser l'architecture au cours d'une des premières itérations.
52. Demander à l’équipe de réalisation de rester en contact avec le graphiste de la DSI pendant
l’intégration de la charte graphique CNRS (tenir informée l’équipe fonctionnelle).
Pour toute difficulté technique rencontrée ou pour faire valider au fil de l’eau l’application de la charte
graphique CNRS, l’équipe de réalisation peut faire appel à la personne ayant les compétences en
technologies Web, voire au graphiste de la DSI. Si les contacts ont lieu sans la présence d’un
membre de l’équipe fonctionnelle, demander que les décisions prises soient tracées dans des
documents (méls, comptes-rendus de réunion ou relevés de conclusions) adressés en copie à
l'équipe fonctionnelle.
PRO-4.3 Rédiger la documentation technique
53. Confier la rédaction initiale (ainsi que les mises à jour en maintenance) de la
documentation technique détaillée au prestataire.
Si le développement ne se fait pas en interne DSI, la confier au BEST.
54. Exiger une trame minimale (mais suffisante) de documentation technique.
La documentation contiendra : conception technique détaillée (architecture technique, frameworks,
règles de développement…), manuel d'installation, manuel d'exploitation.
55. Construire la documentation technique détaillée de manière itérative.
Il s’agit de faire rédiger et ajuster la documentation au fur et à mesure du développement (ne pas
attendre que la documentation soit terminée et validée pour démarrer le codage de l'application).
56. Faire valider la documentation technique détaillée par le BEST au plus tôt dans la phase de
construction (la diffuser à l'équipe d'exploitation).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
16 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-5 Validation et recette
L'application et la documentation sont validées au fur et à mesure des versions incrémentales.
Les tests s'effectuent dans tous les cas dans un environnement indépendant de l'environnement de développement.
La validation fonctionnelle s'appuie sur la documentation fonctionnelle détaillée.
La validation technique est primordiale.
PRO-5.1 Organiser les validations et les recettes
Définitions :
Validation : processus d'évaluation/appréciation d'éléments (documentation ou maquette). On utilisera le terme
"validation" pour l'activité qui termine la mise au point de la maquette.
Recette : processus de validation/acceptation formelle des livrables du prestataire (documentation et application). La
recette est découpée en autant de jalons que de versions intermédiaires livrées par le prestataire.
57. Pour la validation de la maquette, prévoir les ressources humaines : équipe fonctionnelle,
ergonome, graphiste.
58. Pour la validation de la maquette, tracer les modifications à apporter sur des copies d'écran
préalablement imprimées et dans un relevé de conclusions.
Indiquer dans le relevé de conclusions le nombre de pages total, le diffuser à tous les participants. A
ce niveau, il n'est pas nécessaire de mettre en œuvre un suivi d'anomalies.
59. Pour la validation des documents livrés par le prestataire, écrire les remarques de relecture
directement sous forme de marques de révision dans le document.
Dans ce contexte, c’est plus efficace que l'utilisation de fiches de relecture.
60. Organiser une réunion de préparation de la recette avec le prestataire et le BEST.
61. Demander au prestataire de livrer ses plans de tests (ou y avoir accès).
62. Pour la recette, prévoir les ressources humaines : équipe fonctionnelle, ergonome,
graphiste, assistance aux utilisateurs, BEST.
63. Tester d'autant plus l'application que les délais de développement sont courts.
64. Pour chaque version incrémentale de l'application, identifier les cas de tests à effectuer
(dont quelques uns de non-régression). Partir des cas d’utilisation identifiés lors de
l’expression des besoins.
Réduire la recette finale à un simple jalon similaire aux jalons de recette intermédiaires.
65. Utiliser une fiche de suivi des cas de tests.
66. Ne pas planifier précisément (dates) les cas de tests.
67. Donner le top de départ de la recette quand l'installation est correcte.
68. Si des sites pilotes sont prévus, prévoir un accompagnement par l'ergonome.
L’ergonome réalisera une évaluation ergonomique auprès des utilisateurs.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
17 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-5.2 Gérer les anomalies
69. En recette, formaliser les anomalies détectées et effectuer un suivi de ces anomalies.
70. Utiliser de préférence l'outil proposé par le prestataire (si la DSI peut y accéder) ; sinon,
utiliser l'outil MANTIS (open-source) ou un tableau de suivi des anomalies.
71. Pour chaque anomalie, identifier précisément la plate-forme de recette : poste, OS,
navigateur (versions).
72. Pendant la recette, faire des points réguliers de présentation des anomalies au prestataire.
Au cours de ces points, il peut être procédé à un ajustement en direct dans l'outil de gestion des
anomalies.
73. Affecter les corrections d'anomalies à l'itération suivante.
Ceci permet de ne pas perdre de temps à re-tester la même version (sauf dans le cas d'anomalies
bloquantes pour le jalon de recette en cours et dans le cas de la recette sur la version finale).
PRO-5.3 Valider fonctionnellement l'application
74. Identifier le responsable des tests fonctionnels.
75. Spécifier les tests fonctionnels à mettre en œuvre pour l'application à partir de la
documentation fonctionnelle détaillée.
76. Prévoir des tests de recette sur le respect des règles d'ergonomie (prévenir l'ergonome) et
de la charte graphique CNRS (prévenir le graphiste DSI).
77. Mettre en œuvre des tests unitaires et des tests de scénarios (basés sur les cas d’utilisation.
Il s’agit par exemple :
•
pour les tests unitaires : validation systématique par page (formats, boutons, liens…) ; présence,
bon fonctionnement, vérification des contrôles particuliers,
•
pour les tests de scénarios : circulation des informations entre les acteurs, scénario nominal et
alternatifs des cas d’utilisation.
PRO-5.4 Valider techniquement l'application
78. Identifier le responsable des tests techniques (BEST ou équipe fonctionnelle).
79. Spécifier les tests techniques à mettre en œuvre.
Ces tests sont identifiés à partir du cahier des charges et de la documentation technique détaillée
spécifique à l'application : montée en charge, temps de réponse, sécurité, plates-formes différentes
(poste, OS, navigateurs).
80. Demander au BEST de préparer l'environnement technique de recette et planifier la
période de tests.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
18 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
PRO-6 Accompagnement du changement
Le système d'aide est essentiellement orienté "métier" et pas "manipulation de l'application" (car la manipulation doit
être intuitive).
Par contre, il est primordial d'organiser le circuit d'assistance aux utilisateurs.
PRO-6.1 Constituer le système d'aide
81. Faire produire tous les textes (y compris l’aide) par le groupe de travail utilisateur.
Le vocabulaire utilisé est ainsi davantage "métier".
82. Proposer une plaquette de présentation de l'application ou un mémo pour les utilisateurs.
83. Proposer une aide en ligne orientée métier.
Si les contraintes de sécurité le permettent, mettre cette aide en ligne dans le site Web de la
direction fonctionnelle ou du service CNRS concerné et pas dans l'application.
Ne pas développer d'aide en ligne pour la manipulation de l'application. En effet la manipulation de ce
type d’application doit être intuitive. Une telle aide en ligne peut éventuellement être proposée sur des
points bien ciblés (par exemple : moteur de recherche…).
Ne pas organiser de formation à la manipulation de l'application. Seule une formation "métier" peut
s'avérer nécessaire.
PRO-6.2 Mettre en place le circuit d'assistance aux utilisateurs
84. Formaliser le circuit d'assistance aux utilisateurs spécifique pour l'application.
Par exemple, l’assistance de niveau «métier » est assurée par la maîtrise d’ouvrage, au niveau
« technique » par l’assistance aux utilisateurs de la DSI.
85. Former l'équipe de l'assistance aux utilisateurs à l'application, durant la période de recette
de l'application.
PRO-6.3 S’assurer de la mise en place d’actions de communication
86. Proposer des supports de communication complémentaires à ceux de la maîtrise d’ouvrage.
La communication auprès des utilisateurs est de la responsabilité de la maîtrise d’ouvrage. La
maîtrise d’ouvrage dispose généralement d’outils de communication propres pour communiquer
auprès des utilisateurs ciblés : site Web, lettre du Web SG…
L’équipe projet DSI peut proposer des supports complémentaires : Web DSI, lettre SI…
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
19 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP : PROCESSUS DE SUPPORT
SUP-1 Conduite de projet
Le pilotage du projet favorise les échanges, la réactivité et l'adaptabilité aux changements intervenant en cours de
projet.
Le cycle de vie est itératif, incrémental, et prend en compte les aspects techniques tôt dans le cycle.
La fiche de suivi de projet trace les événements du projet et capitalise les connaissances au fur et à mesure.
SUP-1.1 Maîtriser les relations avec la maîtrise d'ouvrage et les
utilisateurs
1.
Identifier une personne ou un comité qui puisse décider au fur et à mesure du
développement.
Il s’agit de pouvoir décider à tous les niveaux : orientations générales ou détails. Il faut également
s'assurer de sa disponibilité.
Dans le cas d’un site Web, le comité peut être un comité éditorial.
2.
Dans le cas d’un site Web, identifier les rôles et responsabilités des éditeurs (ceux qui
mettent en forme l’information en ligne via des éditeurs HTML) et des responsables de
contenu (ceux qui sont responsables des informations sur le fond).
Il s’agit d’identifier la nature des informations mises en ligne, la fréquence des mises à jour, la
gestion de l’information obsolète, l’activité de transformation de l’information pour adapter la
communication à l’écran, la relecture… Il faut essayer de préciser la charge supplémentaire de travail
que cela occasionnera pour chacun.
3.
Identifier un groupe d'utilisateurs qui puisse exprimer les besoins, évaluer et valider la
maquette.
Il faut également s'assurer de sa disponibilité.
4.
Planifier quelques jalons : réunion de lancement, points d'avancement, présentation et
validation d'une maquette ou d'une version incrémentale, date de mise en production.
5.
Après chaque contact, formaliser les décisions prises dans un document.
Plus précisément à l’aide des documents suivants :
•
mél : pour un coup de fil,
•
compte-rendu de réunion : dans le cas d'une réunion avec un nombre important de personnes et
des décisions majeures prises,
•
relevé de conclusions, rédigé (manuscrit), signé et diffusé en séance aux participants : dans le
cas d'une réunion avec peu d'intervenants ou beaucoup de points de détail traités…
•
note : pour des décisions "officielles" à diffuser à des destinataires hors du projet.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
20 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
6.
Garder l'historique des décisions ayant un impact sur le cahier des charges et sur les délais.
7.
Dans le cas de traitement automatisé d'informations nominatives, informer la maîtrise
d'ouvrage et effectuer la déclaration à la CNIL.
Pour cela consulter le site de la DSI du CNRS : http://www.dsi.cnrs.fr/cnil/. Généralement, s’il y a
une liste de noms de personnes manipulée dans l’application, il suffit de faire une déclaration de
fichiers informatisés (Demande d’avis). Il est dans tous les cas préférable de demander une
confirmation à la personne en charge des déclarations CNIL au sein de la DSI.
Attention, il faut compter de 1 à 2 mois entre l'envoi du dossier et la réponse de la Cnil.
8.
Si une déclaration est faite à la CNIL, mettre les informations légales sur la page d'accueil.
SUP-1.2 Favoriser les échanges au sein du bureau
9.
Identifier les compétences au sein du bureau.
Il s’agit en particulier d’évaluer les compétences actuelles et le plan de formation à mettre en œuvre
(outil de maquettage, environnement technique, PowerAMC…).
On peut également créer une liste de diffusion électronique regroupant les personnes concernées par
des applications Web au sein du bureau (pour échanger facilement des informations).
10. Prévoir des réunions régulières au sein du bureau.
L’objectif est de partager les connaissances sur tous les sujets.
11. Diffuser à l’ensemble de l’équipe les comptes-rendus des réunions extérieures au bureau.
SUP-1.3 Effectuer un suivi réactif du projet
12. Déterminer les jalons majeurs du projet (pas de planification détaillée).
Par exemple, le contenu et la date de validation de chaque version incrémentale. Si besoin est, pour
des raisons de taille de projet ou de visibilité du projet, tenir à jour un planning avec MSProject (cf. le
manuel d’utilisation de MSProject et un modèle de planning dans les modèles de documents du site
« Développement Web » de la DSI).
13. Tenir à jour quotidiennement la fiche de suivi de projet.
Cette fiche contient l’historique des événements extérieurs, des décisions, le tableau de suivi des
actions (jalons, tâches de la maîtrise d'ouvrage, livraisons du prestataire…).
Il est préférable qu'une seule personne à jour la fiche de suivi de projet : le responsable de
l'application à la DSI (chef de projet).
14. Effectuer un point d’avancement mensuel auprès de la maîtrise d’ouvrage et de la DSI.
Chaque responsable d’application à la DSI (chef de projet) doit effectuer un point d’avancement
mensuel. Il s’agit d’envoyer la fiche de suivi de projet actualisée (ou partie de cette fiche, sans les
annexes par exemple) aux destinataires initiaux de la note de cadrage (maîtrise d’ouvrage, liste staff
DSI, participants au projet) afin de les tenir informés de l’avancement du projet. Avant diffusion, la
fiche est actualisée avec les travaux effectués pour la période écoulée ou en cours, les difficultés ou
risques rencontrés ou pressentis pour la période à venir, la mise à jour du planning.
S’il y a lieu, organiser une réunion afin de débattre des éléments envoyés.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
21 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
15. Communiquer régulièrement le planning du projet au staff DSI et aux équipes transverses
intervenant (BEST, BMSD, BSU, équipe RUE).
16. Gérer les risques.
Les risques peuvent être par exemple une non-implication des utilisateurs, un congé de ressources
critiques de l'équipe projet… (cf. liste des risques dans les modèles de documents du site
« Développement Web » de la DSI).
Tout au long du projet, prendre les décisions en fonction de leur impact sur la réduction des risques.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
22 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP-1.4 Suivre un cycle de vie itératif et incrémental
Définitions :
• Cycle itératif = les différents livrables du projet (application ou documentation) ne sont pas validés définitivement
à la fin d'une phase mais raffinés sur la base de versions successives.
• Cycle incrémental = les livrables du projet sont découpés et planifiés en lots, en fonction de priorités fixées par
les utilisateurs ou pour réduire des risques (techniques en particulier).
• Maquette = représentation graphique des pages, du système de navigation et donc du découpage en tâches
pour l'utilisateur. Son développement ne s'effectue pas forcément dans la technologie retenue pour l'application ;
elle est a priori jetable.
• Version incrémentale de l'application = version intermédiaire développée dans la technologie cible,
permettant de valider un sous-ensemble de caractéristiques fonctionnelles, techniques ou ergonomiques.
17. Identifier les itérations du cycle et les versions incrémentales de l'application.
Ces itérations sont identifiées en fonction des exigences fonctionnelles (priorités des utilisateurs),
techniques ou ergonomiques et des risques, de la taille et du budget du projet :
•
projet court (2-3 mois) = maquette, livraisons et recettes intermédiaires de la documentation de
conception (cf. pratique ci-dessous), version finale,
•
projet moyen (3-6 mois) = maquette, prototype de l'architecture, première version, version finale.
Les itérations courtes ne devraient porter que sur des incréments en réalisation nécessitant peu de
conception.
Si les délais sont trop courts ou le budget insuffisant pour effectuer des livraisons intermédiaires de
l'application, s'appuyer sur une maquette puis sur des livraisons et des validations intermédiaires de
la documentation de conception.
Chaque version incrémentale de l'application doit être exécutable et testable.
Définir les objectifs, la portée, la durée, les critères d'évaluation, les activités et les responsabilités
pour chaque itération (s’appuyer sur les cas d’utilisation identifiés en expression et analyse des
besoins).
Trouver un nom pour chaque itération.
18. Planifier chaque livraison et validation de version incrémentale.
19. Réactualiser le planning de façon itérative : à la fin de chaque itération.
SUP-1.5 Capitaliser les connaissances du projet
20. Faire un bilan en fin de projet (à partir de la fiche de suivi de projet).
21. Capitaliser les pratiques intéressantes pour la conduite de projet et pour les applications
Web.
Par exemple les règles d'ergonomie, les frameworks réutilisables, les règles de développement.
22. Enrichir la base de connaissances DSI (site « Développement Web » de la DSI).
Mettre à jour les meilleures pratiques, mettre à jour les informations sur l'application, donner accès à
la note de cadrage et au bilan de projet.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
23 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP-2 Gestion de la sous-traitance
Le choix du prestataire est primordial pour la réussite du projet. Il s'agit d'établir un partenariat avec le prestataire,
d'instaurer une réelle confiance.
Les relations avec le prestataire sont formalisées de manière minimale (sinon augmentation des coûts et délais) mais
suffisante (pour la maîtrise du projet).
SUP-2.1 Constituer le cahier des charges
23. Partir d'une trame de cahier des charges.
Cette trame contient des exigences fonctionnelles, opérationnelles, ergonomiques, techniques et
contractuelles.
Préciser dans le cahier des charges que le cycle de vie à suivre est itératif et incrémental. Si elles
sont connues, indiquer le nombre et le contenu des versions incrémentales, sinon demander au
prestataire de les déterminer dans son offre.
Demander au prestataire qu'il utilise :
•
PowerAMC (ou format compatible) pour le modèle de données,
•
la suite MSOffice pour les documents.
Demander au prestataire les dispositions qualité et de conduite de projet, nécessaires et suffisantes,
qu'il va mettre en œuvre pour le projet (dans le cadre de ce type de projets, de taille petite ou
moyenne, les procédures habituelles de Tierce Maintenance Applicative ou de conduite de grands
projets doivent être allégées).
Prévoir une réunion de transfert de connaissances en fin de développement avec au minimum une
présentation de l'architecture technique et des procédures d'installation et d'exploitation.
Faire en sorte que les estimations des charges des candidats puissent être comparées entre elles
(préparer un cadre de réponse).
24. Initialiser le rapport d'analyse des offres.
Le modèle du document est à demander à l’animateur qualité à la DSI.
Ce rapport contient la liste des critères et leur pondération. Il est initialisé en même temps que le
cahier des charges afin d'ajuster celui-ci en parallèle à la définition des critères d’évaluation : le cadre
de réponse au cahier des charges doit faciliter l'appréciation des critères et donc la comparaison des
offres.
25. S'il existe une maquette, la mettre dans le cahier des charges.
S'il n'y a pas de maquette, préciser les éléments incontournables à respecter (en particulier les
règles d’ergonomie et la charte graphique CNRS).
26. Sélectionner les sociétés (généralement trois) auxquelles envoyer le cahier des charges.
SUP-2.2 Contractualiser
27. Informer le gestionnaire des marchés à la DSI (BAGA).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
24 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
28. Choisir le prestataire en s'aidant du rapport d'analyse des offres
Dans le cas d'un montant inférieur au seuil de 90 K€ HT = "marché sans formalité préalable"). Ce
rapport contient une grille de critères d'analyse à ajuster et à pondérer en fonction du projet ainsi
qu'un argumentaire de choix (demander le modèle à l’animateur qualité à la DSI).
29. Négocier des délais de validation-recette suffisamment longs.
En effet des dérives sont possibles ou l'équipe DSI peut être sollicitée par ailleurs de manière
imprévue.
30. Prévoir un délai plus long pour la réception de la documentation fonctionnelle et technique
détaillée que pour l'application.
Priorité est donnée à la mise en production. Mais au final, la documentation doit être à jour pour la
maintenance.
31. Transmettre le cahier des charges, le rapport d'analyse des offres et l'offre retenue au BAGA,
pour envoi à la délégation régionale.
Le service financier de la délégation établira alors le contrat (clauses administratives : droits de
propriétés, obligation de confidentialité, statut du personnel du prestataire travaillant dans les locaux
de la DSI…), à signer par le CNRS et le prestataire.
Note : si le cahier des charges devait aboutir à la notification d’un simple bon de commande, il devrait
être complété par les clauses administratives stipulées ci-dessus.
SUP-2.3 Informer l'équipe projet des dispositions contractuelles
32. Au cours d'une réunion interne DSI, présenter les dispositions contractuelles à l'équipe.
33. Rendre les documents contractuels accessibles à l'équipe, dans le répertoire de la
documentation du projet, sur serveur DSI.
34. Informer régulièrement l'équipe projet sur l'avancement du marché.
En particulier sur des aspects tels que la durée de la garantie, les possibilités de commandes pour
de la maintenance….
SUP-2.4 Maîtriser les relations avec le prestataire
35. Lors de la réunion de lancement avec le prestataire, présenter le mode de dialogue entre la
DSI et le prestataire.
Il s’agit de définir précisément les circuits, les documents, leur formalisme… Rappeler également au
prestataire les modalités de facturation de la prestation, décrites dans le contrat (voir avec le BAGA).
36. Identifier les interlocuteurs, leurs responsabilités et la façon de les contacter (noms,
adresses mél, tél).
37. Mettre en relation l'ergonome et le graphiste de la DSI avec le prestataire.
Si les contacts ont lieu sans la présence d’un membre de l’équipe fonctionnelle, demander que les
décisions prises soient tracées dans des documents (méls, comptes-rendus de réunion ou relevés
de conclusions) adressés en copie à l'équipe fonctionnelle.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
25 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
38. Définir la fréquence des points d’avancement (rendez-vous pris au point d'avancement
précédent) et tracer par écrit chaque décision.
En particulier :
•
les points téléphoniques sont tracés dans un mél,
•
les réunions "flash" sont tracées en séance par un relevé de conclusions manuscrit et diffusé à
chaque participant.
39. Planifier des jalons (réunions, livraisons) avec le prestataire.
Il s’agit des dates de réunions (lancement, préparation recette, suivi de projet, comité de pilotage
avec responsables) et de livraisons du prestataire.
40. Demander la justification de chaque non-respect d'une exigence de la DSI.
Par exemple le non-respect de spécifications, de règles d'ergonomie, de la charte graphique CNRS,
de délais…
La justification doit être signifiée à la DSI par un mél au moment de la prise de décision.
Réagir rapidement aux méls du prestataire.
41. Etablir un bilan de la prestation et du suivi effectué en fin de projet (dans la fiche de suivi de
projet).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
26 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP-3 Gestion de la documentation
La documentation du projet est simplifiée mais gérée sur serveur comme pour les autres projets.
SUP-3.1 Gérer la documentation sur serveur DSI
42. Créer un répertoire du projet sur le serveur dans [buzet ou montmartre]/projets/autresapplis-[bureau].
Il existe dans ce répertoire : un sous-répertoire par projet (l’accès est en R/W pour toute l’équipe
projet), un sous-répertoire COMMUN pour les documents communs à toutes les applications
(comptes-rendus de réunion, de présentations techniques, qualité…).
43. Découper le répertoire du projet en sous-répertoires, reprenant les phases et activités du
projet.
•
Gestion projet (GP), Relations prestataire (SSII), Qualité (QU),
•
Etude préalable (EP), Etude détaillée (ED), Etude technique (ET), Réalisation (RE), Réception
(RC), Mise en oeuvre (MO, contient l'accompagnement au changement, la mise en production et
l'exploitation).
44. Gérer les versions de la documentation (indépendamment des versions de l'application).
45. Stocker les méls dans les répertoires du projet sur serveur.
SUP-3.2 Identifier les modèles de document et les livrables
46. Référencer chaque document en page de garde et dans le pied de page de chacune des
pages.
La référence est de la forme : CNRS/DSI/[projet]/[activité]/[identification-document] avec :
•
[projet] : code du projet,
•
[activité] : code de l'activité = GP (gestion de projet), QU (qualité), EP (étude préalable), ED
(étude détaillée), ET (étude technique), RE (réalisation), RC (réception), MO (mise en œuvre). Ce
code correspond au répertoire dans lequel est stocké le document,
•
[identification-document] : nom logique du fichier.
47. Utiliser les modèles de documents de la DSI (cf. site « Développement Web » de la DSI).
•
document type DSI
•
note de cadrage du projet = CADRAGE (EP)
•
fiche de suivi de projet = SUIVI-PROJET (GP)
•
exigences fonctionnelles = EXIGENCES-FONCTIONNELLES (EP)
•
conception de l’interface utilisateur = CONCEPTION-INTERFACE (EP)
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
27 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
•
cahier des charges = CAHIER-DES-CHARGES (EP)
•
demande de modification = DM-[identification-demande] (GP)
•
portefeuille des demandes de modification = SUIVI-DM (GP)
•
cr de réunion = CR-AAMMJJ (GP ou SSII)
•
relevé de conclusions, rédigé en séance, manuscrit = RC-AAMMJJ
•
fiche de suivi des cas de tests = SUIVI-TESTS (RC)
•
tableau de suivi des anomalies = SUIVI-FA (RC)
•
procès-verbal de réception = PV-[n° commande XLAB] (SSII)
•
dossier d'exploitation = DOSSIER-EXPLOITATION (MO)
•
journal d'exploitation = JOURNAL-EXPLOITATION (MO).
48. Demander au prestataire de livrer les documents respectant des règles minimales de forme
et accompagnés d'un bon de livraison.
Les règles minimales de forme de la documentation sont : nom, référence, date, version, historique
des versions, numéro de page, marques de révision apparentes.
Les documents livrés sont les suivants :
•
conception fonctionnelle détaillée (à stocker dans ED)
•
conception technique détaillée (à stocker dans ET)
•
plan de test (à stocker dans RC)
•
manuel d'installation (à stocker dans MO)
•
manuel d'exploitation (à stocker dans MO)
•
plaquette (à stocker dans MO).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
28 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP-4 Gestion de configuration logiciel
La gestion des versions s'effectue au niveau de l'application globale (cf. les informations sur la gestion de
configuration dans le site « Développement Web » de la DSI).
Les environnements de développement, de recette et de production sont différenciés.
Toute manipulation est tracée dans le journal d'exploitation.
SUP-4.1 Gérer les environnements
49. Identifier les environnements : de développement (mis en œuvre par le prestataire), de
recette et de production.
50. Planifier la mise en œuvre des environnements DSI suffisamment tôt avant la recette.
51. A la DSI, gérer en configuration l'application globale ou bien des lots de livraison (par
exemple si multi-plates-formes ou multi-prestataires).
Pour ce type d'application, il ne paraît pas nécessaire de mettre en œuvre une gestion des versions
au niveau des composants du source.
52. Demander au BEST d'archiver les différentes versions de l'application et les sources.
53. Identifier à chaque livraison toute nouvelle version de l'application par un numéro de
version : [version].[sous-version].[état technique].
Ce numéro est initialisé à 1.1.1.
Le numéro de version est incrémenté à chaque évolution fonctionnelle importante, le numéro de sousversion : lors d'une évolution fonctionnelle minime, l'état technique : lors d'une correction logicielle.
54. Si un outil de gestion de configuration est jugé nécessaire en interne à la DSI, utiliser un
outil de type CVS (open-source) et le préciser dans le cahier des charges.
SUP-4.2 Gérer les livraisons du prestataire
55. Demander au prestataire de formaliser le contenu de ses livraisons par un bon de livraison.
Le bon de livraison doit préciser la version des éléments livrés (application ou document) et la liste
des modifications implémentées.
Stocker les bons de livraison dans le répertoire de la documentation du projet sur le serveur DSI.
56. Demander au prestataire d'accompagner la livraison de chaque version intermédiaire, d'un
manuel d'installation à jour.
Dans le manuel d’installation,les évolutions doivent être tracées d'une version à l'autre.
57. En mise au point ou en maintenance, demander au prestataire de regrouper les évolutions
ou corrections pour minimiser les livraisons.
Une fréquence régulière de livraison est souhaitable en maintenance.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
29 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
Ceci facilite la planification des tâches de l'équipe d'exploitation de la DSI. Il doit être exceptionnel
d'avoir plusieurs livraisons d'une application dans une même journée.
SUP-4.3 Organiser l'exploitation
58. Diffuser le cahier des charges à l'équipe d'exploitation de BEST.
Le cahier des charges doit être transmis en début de projet pour que l’équipe d’exploitation puisse
prévoir l'organisation de l'exploitation en conséquence.
59. Mettre en place un planning de mise en exploitation avec le BEST.
60. Demander au BEST de préparer le dossier d'exploitation.
Ce dossier contient la description de la configuration de l'environnement de production, des
procédures de mise en exploitation et des procédures d'exploitation courante, de sécurité et
d'archivage.
61. Dès que possible (avant la fin de la recette), livrer à BEST le manuel d'exploitation livré par
le prestataire.
L’équipe d’exploitation pourra ainsi préparer la mise en production (mise à jour du dossier
d'exploitation).
62. Dès que l'application est en production, tenir à jour (BEST) le journal d'exploitation.
Ce journal trace toutes les manipulations effectuées dans les différents environnements (installation
des versions incrémentales, scripts, correction des bugs, mise à jour des données…).
63. Dans le cas d’un site Web, communiquer aux différents éditeurs les éléments nécessaires
pour mettre en ligne l’information.
Leur donner une « trousse à outils » : charte de fonctionnement du site, comment mettre les
informations en ligne, à qui s’adresser en cas de problème, description et explication de l’utilisation
de la ligne graphique, principes de navigation, guide de recommandations ergonomiques.
Effectuer une vérification régulière des liens internes et externes (prêter une attention particulière aux
liens vers des signets).
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
30 / 31
Développement des sites et applications Web à la DSI : meilleures pratiques
SUP-5 Gestion des changements
En cours de développement ou en maintenance, toute demande de changement est intégrée dans un portefeuille
des modifications.
La maintenance corrective ou évolutive de l'application ne s'effectue pas au fil de l'eau (souvent pas de marché prévu)
mais se planifie à l'avance.
SUP-5.1 Gérer les évolutions en cours de développement
64. Consigner les demandes d'évolution dans le portefeuille des modifications.
Les demandes d'évolution peuvent concerner la version en cours de réalisation ou les versions
incrémentales prévues de l'application, ou même des versions qui ne seront développées
qu'ultérieurement, dans le cadre de la maintenance de l'application.
65. Donner accès au portefeuille des modifications (un extrait éventuellement) : à l'équipe
projet, à la maîtrise d'ouvrage et à un groupe d'utilisateurs.
66. Faire valider les évolutions par un groupe d'utilisateurs.
67. Transmettre les évolutions au prestataire pour la version en cours.
SUP-5.2 Préparer la réalisation d'une version en maintenance
68. Prévoir suffisamment de délai pour le développement d'une nouvelle version (réactivité du
prestataire).
69. Analyser (en concertation avec l'ergonome de la DSI) les demandes d'assistance reçues à
l'assistance aux utilisateurs de la DSI.
Ceci permet de proposer des évolutions à valeur ajoutée pour les utilisateurs.
70. Consigner les demandes de correction ou d'évolution dans le portefeuille des modifications.
71. Mettre l'extrait du portefeuille des modifications que l'on souhaite développer dans le cahier
des charges.
Cet extrait est accompagné des documents de spécification ou de conception fonctionnelle de
l'application mis à jour (marques de révision apparentes).
72. Dans le cahier des charges, indiquer les documents existants (documentation technique)
que le prestataire devra maintenir à jour.
En particulier ne pas oublier l'aide en ligne s’il en existe une.
73. S'assurer que la compétence fonctionnelle et technique du prestataire est maintenue (si on
choisit le prestataire initial).
74. Ajuster le portefeuille des modifications lors de la réunion de lancement avec le prestataire.
75. Lors de la mise en production d'une nouvelle version, s'assurer d'abord que l'on pourra
revenir rapidement à la version précédente, an cas de problème majeur.
CNRS/DSI/BMSD/Qualité/meilleures -pratiques.doc
24/01/2005
31 / 31
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising