01 53 63 37 87
Fiche plan type d’un cahier des charges infocentre - datawarehouse
consulting formations PMP® simulateur PMP®Delf, centre de formation en maîtrise d'ouvrage, maîtrise d'oeuvre et gestion de projets à Paris met à votre disposition cette fiche technique.
L’évolution du marché, des produits et la position de la concurrence ont engagé une réflexion qui s’est concrétisée à l’occasion d’une étude d’opportunité en un projet d’enrichissement du système d’information.
Un audit récent a mis l’accent sur une mauvaise restitution et une insuffisante utilisation des informations par les différents services de l’entreprise.
La Direction a donc décidé d’entreprendre un projet dont l’objectif essentiel est la constitution d’un serveur permettant un large accès aux informations contenues dans les systèmes opérants.
Ce projet traitera de :
La définition des données (partagées ou non) à mettre en lignes pour les différents utilisateurs ;
Après avoir démontré la pertinence de la demande, l’étude d’opportunité a initialisé le projet. À cette occasion, le budget et les principales échéances (cf. . §1.6) ont été fixées. Le comité de pilotage et les différents acteurs ont été nommés. Les différentes conclusions sont disponibles dans le dossier d’opportunité. Les détails de l’organisation du projet sont contenus dans le plan d’assurance qualité actuellement conservé par le chef de projet.
L’étude de faisabilité conduite durant le premier trimestre a permis de choisir une solution à développer. La suite du projet a été approuvée par le comité de pilotage (cf. relevé de décision joint au contrat d’étude de faisabilité). La solution choisie est décrite dans le dossier de faisabilité. A l’issue du choix en comité de pilotage le contrat de spécification a été signé par les représentants de la maîtrise d’ouvrage et de la maîtrise d’œuvre.
La phase de spécification (générale) a produit le présent document.
Le présent cahier des charges a pour objet de choisir un partenaire pour mener à bien les phases de spécification détaillée et de réalisation.
La maîtrise d’œuvre est assurée par la direction informatique interne. Elle pilotera à ce titre les travaux de sous-traitance. Un contrat de spécification a été établi entre la maîtrise d’ouvrage et la maîtrise d’œuvre pour formaliser les besoins et les exigences produits dans le présent document.
Les principaux objectifs visent à restituer dans de bonnes conditions de délai et de fiabilité les informations contenues dans les différents fichiers :
Ces informations doivent être utilisées à des fins d’aide à la gestion et d’aide à la décision. Certaines devront être des informations élaborées déduites des informations élémentaires brutes des fichiers, quelquefois peu significatives pour les gestionnaires.
Les domaines connexes au projet étudié sont les suivants :
Les relations entre le projet et les différents domaines concernés dans l’entreprise sont symbolisées dans l'exemple ci-après.
Toutefois dans le cadre de l’avant projet il a été décidé de traiter dans une première version uniquement les données souhaitées par le domaine commercial. Ce choix, son argumentation et le cycle de développement de cette première itération sont décrits dans le plan d’assurance qualité du projet.
Les principaux axes d’évolution retenus sont de :
L’enjeu principal quant à lui est de rester positionné sur notre marché traditionnel.
Des fonctions d’extraction devront permettre de récupérer dans chaque application de gestion les informations qui ont été choisies pour être dans le réservoir d’information.
Une fonction d’injection devra permettre d’alimenter le réservoir à partir des informations extraites par les extracteurs.
Des fonctions de consultation devront permettre de gérer et d’exécuter des requêtes sur le réservoir.
Fournir ici la référence du contrat de spécifications, dans lequel figurent des informations relatives au planning et au budget global souhaité, tel qu'identifié à l'issue de l'étude de faisabilité.
Si l’application à réaliser fait partie d’un ensemble plus vaste de logiciels à livrer, décrire très succinctement les développements envisagés lors de l’étude de faisabilité, avec le calendrier de déploiement.
Le planning et le budget ont été signés et consignés dans le contrat de spécifications et sont aujourd’hui disponibles auprès du chef de projet.
Les grandes échéances sont les suivantes.
Le site pilote du premier projet (le domaine commercial) est prévu pour la fin de l’année.
Le déploiement est programmé en janvier de l’année prochaine.
Les projets concernant les domaines gestion et RH seront conduits l’année prochaine en parallèle de janvier à juillet. La mise en œuvre devra se terminer en décembre.
Reprendre ici les éléments de risque identifiés lors de la faisabilité au niveau de la solution et, sans que cela ne la remette en cause, les éventuelles réserves faites à son égard lorsque la faisabilité a été prononcée.
Réactualiser si nécessaire ces éléments à la date de lancement de l’étape de spécification.
Lors de l’étude de faisabilité des travaux ont permis de mesurer les risques afin de définir la stratégie du projet.
Cette analyse a été faite par la construction d’un profil de risque en positionnant le projet au vu de différents critères (cf. la fiche de description de cette approche de mesure des risques accessible sur l’intranet de la société). Les résultats de cette analyse sont décrits en détails dans le dossier de faisabilité.
À titre d’information les tableaux ci-dessous indiquent respectivement le profil de risques initial du projet et le profil obtenu en prenant en compte la stratégie de conduite retenue (et décrite dans le PAQ).
Il s’agit de spécifier de façon exhaustive et détaillée les fonctionnalités attendues.
Il s’agit de(s) domaine(s) d’activité(s), le(s) activité(s), les flux (internes ou avec l’extérieur), les processus concernés par l’informatisation.
Ces informations sont récupérées à partir du dossier de faisabilité
La présente application concerne tous les métiers de l’entreprise, notamment la gestion des clients, des commandes, des ventes (pour le commercial), la gestion des stocks, la facturation la comptabilité (pour la gestion), la gestion des salariés (pour les ressources humaines).
Le premier cycle ne concerne que les métiers commerciaux
Il s’agit de lister de façon exhaustive les types de sites concernés par l’informatisation. Pour chaque type de site identifié, on précisera le nombre de sites impliqués.
Ces informations sont récupérées à partir du dossier de faisabilité.
Notre entreprise ne dispose actuellement que d’un seul site, le siège.
Il s’agit de lister de façon exhaustive les types d’acteurs (au sens poste de travail RH : facturier, comptable, accueil, ...) concernés par l’informatisation. Pour chaque type d’acteur identifié, on précisera le nombre d’acteurs impliqués.
Ces informations sont récupérées à partir du dossier de faisabilité.
Tous les acteurs de l’entreprise sont concernés par cette application.
Il s’agit de lister de façon exhaustive les tâches, procédures, organigramme type ... qui sont concernés par l'informatisation.
Ces informations sont récupérées à partir du dossier de faisabilité.
Les principales tâches et procédures concernées par le projet sont :
Il s’agit de spécifier de façon exhaustive et détaillée les fonctionnalités attendues.
Description synthétique (quelques lignes) mais exhaustive des fonctionnalités à mettre en œuvre. Les fonctionnalités correspondent aux services que l'application doit rendre à l'utilisateur final, au vu des futures missions de ce dernier.
Ces fonctionnalités sont la raison d'être de l'application.
Cette description s’effectue à partir des éléments déjà identifiés au dossier de faisabilité.
Il convient d'identifier explicitement les fonctionnalités jugées fondamentales pour la MOA.
Les fonctionnalités destinées à l’utilisateur final sont essentiellement les suivantes :
Les autres fonctionnalités permettent de gérer le contenu de la base d’informations :
Croisement fonctionnalité/métiers/types de sites/types d’acteurs/organisation du travail.
Il s’agit également de préciser de façon exhaustive, à partir de ce croisement, les contraintes de la future organisation du travail qui s’appliqueront à chaque fonctionnalité : fréquences d'utilisation, les plages horaires d'utilisation (en précisant les éventuels phénomènes de concentration (exemple : tous les lundis matin, les utilisateurs vont solliciter la même fonctionnalité), nombre d’utilisateurs, dispersion géographique.
Cette description exhaustive s’effectue à partir des éléments déjà identifiés au dossier de faisabilité
La première liste des fonctions ci-dessus concerne l’ensemble de l’entreprise. En revanche, la seconde ne concerne que le département informatique. Les travaux d’extraction et d’intégration sont réalisés mensuellement.
Un comité d’évolution devra être constitué pour définir les évolutions du contenu.
Description succincte (sous la forme d'un graphe) de la manière dont les différentes fonctionnalités de l’application s’enchaîneront logiquement les unes par rapport aux autres pour assurer au final le service attendu par l’utilisateur. Par exemple, pour assurer la facturation mensuelle des clients, l’application enchaînera les fonctionnalités suivantes :
Remarques :
Les fonctionnalités de l’application peuvent être regroupées en 2 processus, un processus d’extraction/injection et un processus de gestion des requêtes.
1.le processus d’extraction / injection
2.le processus de gestion des requêtes
L’ensemble des fonctions de consultations est exécutable à la demande des utilisateurs.
Ces fonctions sont les suivantes :
Lister de façon exhaustive des règles de gestion associées aux fonctionnalités listées au paragraphe 3.1.
Les règles de gestion associées aux données manipulées (règle de calcul par exemple) sont quant à elles décrites au paragraphe 4.1.
Remarque : ces règles de gestion correspondent à celles que souhaitent mettre en place la MOA (et qui par ailleurs sont jugées faisables par la MOE) et celles qui s’imposent à elle, du fait par exemple des systèmes connexes ou de la législation en vigueur. Ces dernières doivent être bien distinguées.
Les principales règles de gestion sont les suivantes :
Les données dont on parle ici sont décrites en détail au paragraphe 4. Il s'agit uniquement d'associer chaque fonctionnalité avec les objets de gestion et les données qu'elle manipule (création, modification, suppression, lecture, copie).
Il convient d'identifier de façon particulière les fonctionnalités manipulant des données nominatives, afin de pouvoir les déclarer ensuite à la CNIL.
Il convient de distinguer les données spécifiques à l’application (décrivant les requêtes) et les données mise à disposition dans le réservoir. Ces dernières sont présentées dans le chapitre suivant (§ 4).
Les données décrivant les requêtes sont les suivantes :
Il s’agit essentiellement de l’entité de gestion « requête ».
Extrait du dictionnaire sémantique des données concernées, ainsi que les règles de gestion associées (calcul, mise à jour, contrôle, ...).
Ce dictionnaire est établi sur la base du dictionnaire sémantique des données déjà existantes. Il explicite fonctionnellement les données élémentaires associées à chaque objet de gestion concerné et qui présentent un intérêt pour la MOA.
Il s’agit également d’identifier les informations considérées par la MOA comme fondamentales.
Cette description s’effectue à partir des éléments déjà identifiés au dossier de faisabilité.
Chaque donnée gérée par l’application a alimenté le dictionnaire des données. Les rubriques renseignées dans le cadre de la définition fonctionnelle du besoin sont les suivants :
La description sémantique des données est complétée par un modèle conceptuel et organisationnel de donnée, et un modèle de flux.
Le dictionnaire des données et les modèles associés sont gérés par notre atelier de génie logiciel ABDC ( « au bonheur des concepteurs »).
Ce paragraphe est le pendant du paragraphe 4.1 pour les données échangées avec d’autres applications, internes ou externes à la société. Il conviendra de préciser le mode (synchrone/asynchrone) et la périodicité de ces échanges.
La définition sémantique (Cf. paragraphe 4.1) précise l’application d’origine de chaque information.
Par ailleurs, une synthèse est représentée par un modèle de flux mettant en relation l’ensemble des applications de gestion et le présent projet (Cf. modèle de contexte dans l’agl ABDC). Pour chacun des flux ce modèle précise la périodicité.
Ce paragraphe est le pendant du paragraphe 4.1 pour les données issues d'un référentiel. Il conviendra de préciser le mode (synchrone/asynchrone) et la périodicité des alimentations correspondantes.
Préciser, pour chaque donnée, le nombre d'occurrences et son évolution dans le temps.
Le cas échéant, signaler explicitement les données pour lesquelles une forte variation de la volumétrie est possible, en fournissant la raison.
La définition sémantique des données (Cf. paragraphe 4.1) précise la volumétrie pour chacune d’entre elle.
Pour les données concernées : durée de rétention et procédure d'historisation à proprement parler (automatique sur la base de critères prédéfinis, manuel, ...).
Remarque : ce qui concerne le fait de savoir comment les données historisées/archivées doivent rester accessibles/récupérables est traité de façon explicite dans le paragraphe 6.3.
La base d’information est constituée tous les mois. Les versions des mois N-2 et N-1 sont conservées, ainsi que la version de décembre de chaque année. Un modèle organisationnel des données précise ces choix.
Il s’agit ici de décrire de façon exhaustive les principes de communication entre l’utilisateur final et sa future application.
Cette description exhaustive pourra reprendre les éléments relatifs aux exigences ergonomiques identifiées au dossier de faisabilité.
Remarque : Ces différents éléments ont pu faire l'objet d'une maquette globale lors de l'étude de faisabilité. Au stade des spécifications, il peut être pertinent de recourir à une maquette détaillée, qui facilitera d'autant le processus de validation des spécifications (DFB + DCG).
Il s'agit ici de décrire de façon exhaustive la logique d'accès des utilisateurs aux différentes fonctionnalités de la future application, telles qu'elles sont décrites au paragraphe 3 :
Cette interface ne concerne que les fonctions de consultation. Les fonctions d’extraction et d’injection n’ont pas d’interface significative.
L’étude d’opportunité a fixé que les fonctionnalités de consultation seraient supportées par un logiciel du commerce. Ainsi, aucune architecture de dialogue homme-machine n’est imposée. Toutefois il conviendra dans le choix de l’outil de vérifier la pertinence de l’architecture proposée.
Il s’agit ici de préciser:
L’outil choisi devra permettre de rendre accessible la définition sémantique pour chaque donnée.
Description des types de rapports nécessaires (finalité, destinataires, contenu, rupture (sous-totaux...), agrégations (niveau de détail), fréquence...), du mode d'activation et de désactivation,...
Les éditions sont traitées comme des requêtes et donc définies par l’utilisateur et le comité d’évolution.
Il s’agit de préciser ici toutes les informations qui sont indispensables à la MOE pour construire une solution totalement appropriée au besoin exprimé par la MOA.
Ces éléments d’information ont pu être évoqués en tout ou partie dans les paragraphes précédents mais sont ici présentés en tant que tels et de façon détaillée.
Remarque: s’il y des variantes locales, elles devront figurer dans ce paragraphe (ex: heure d’ouverture différente dans les DOM,..)
Ils reprennent des éléments déjà évoqués au dossier de faisabilité et sont en cohérence avec les facteurs de réussite exprimés lors de l’étude d’opportunité (pour ceux qui relèvent de l’informatique).
Ces exigences seront en toutes ou parties:
Il s’agit ici de préciser de façon exhaustive les éléments du futur environnement de travail qui devront être pris en compte par la future application.
Il peut s’agir par exemple :
L’application à mettre en place devra s’inscrire dans l’ensemble des solutions techniques actuellement en place. Il s’agit pour l’essentiel :
Expression, par la MOA, des temps de réponses et/ou débits (tant de factures par heures par exemple), de la variation des volumes (caractères saisonnier) à respecter, compte tenu des objectifs métier poursuivis et des résultats attendus en terme de performance (cf. paragraphe 1.4.2 du dossier d’opportunité).
Les temps de réponse feront l’objet d’une surveillance serrée par le comité d’évolution. Ils devront être inférieurs à un seuil acceptable. Toutefois, les temps de réponses seront fonction de la complexité de la requête. Il sera donc possible de simuler une requête, cette simulation donnant des informations tangibles sur la durée de la requête.
Préciser de façon exhaustive, dans le cadre des fonctionnalités correspondantes, les règles d'accès aux données historisées. Dans le cas d'une historisation hors ligne, préciser quel type de procédure de récupération la MOA souhaite mettre en œuvre, compte tenu de la fréquence envisagée de ce type d’accès.
Remarque : Ces informations, combinées à celles fournies au paragraphe 4.5, permettront à la MOE de développement de concevoir la solution permettant de garantir que les données historisées seront toujours accessibles.
L’ensemble des archives (Cf. Paragraphe 4.5) est directement accessible pour l’ensemble des utilisateurs.
Le portail d’entrée de l’application permettra de choisir la version à consulter.
Préciser, pour des données qui sont logiquement indépendantes les unes des autres (issues de plusieurs bureaux par exemple) si certaines d'entre elles doivent être visibles (lecture/écriture) simultanément par tout ou partie des utilisateurs.
Selon le cas, ce genre de contrainte aura pour conséquence un regroupement physique de ces données ou la mise en place d'une solution donnant l'illusion qu'elles sont regroupées.
Cette sécurité découle de l’importance accordée par la MOA à certaines fonctionnalités et à certaines données de l’application, comme indiqué aux paragraphes 3.1 et 4.1.
Cette description exhaustive s’effectue à partir des éléments déjà identifiés au paragraphe 2.2.1.8 du dossier de faisabilité et d’une analyse fine des risques d’insécurité encourus, compte tenu de l’utilisation prévue de l’application et de son environnement.
Confidentialité, droits d'accès
La MOA indique ici de façon explicite :
La direction générale de l'entreprise a décidé que l’ensemble des données de l’application sera accessible par tout le personnel, à l’exception des données RH et Comptable, pour lesquelles les règles de confidentialité définies pour les autres applications restent valables.
Intégrité
La MOA spécifie ici de façon explicite :
L’application ne faisant que de la consultation et non de la modification aucun problème d’intégrité ne se pose.
Disponibilité
La MOA spécifie ici le niveau de disponibilité qu'il souhaite avoir (24/24?), mode de fonctionnement dégradé de l’application en cas de problèmes, la durée admissible d’interruption de service, les délais maximum de reprise après panne,...
L’application devra être disponible 24 heures sur 24.
Un contrat devra être négocié avec un sous-traitant pour héberger une image de notre application. Elle sera utilisée en cas d’indisponibilité de notre site.
Il s’agit ici de préciser le comportement de l’application lorsque l’utilisateur détecte une anomalie de fonctionnement et la procédure de reprise de traitement. Cela concerne par exemple la manière dont il conviendra de traiter le cas de figure où un bordereau incomplet empêcherait sa saisie (abandon pur et simple ou mémorisation des informations déjà saisies puis routage vers une personne chargée de résoudre le problème).
Chaque anomalie constatée par les utilisateurs devra être signalée à la Hot Line.
La Hot Line s’engage à donner à :
En complément du mécanisme d'alerte décrit au paragraphe 5.1, il s’agit ici de préciser la façon dont l’application doit traiter les erreurs de fonctionnement (disque plein par exemple) ou de manipulation : historisation dans un éventuel journal, durée de rétention de ce journal, niveau de finesse et de traçabilité des erreurs,...
Le résultat de chaque requête sera accompagné des conditions d’exécution :
La MOA doit fournir ici la liste des fonctionnalités qu'il considère comme critiques pour la réussite de son projet.
Une fonctionnalité peut être critique pour plusieurs raisons :
Les différentes fonctionnalités étant nécessaires pour le bon fonctionnement de l’application, elles sont toutes jugées critiques.
Ce paragraphe consiste en une synthèse des paragraphes 6.x ci-dessus et, en toute logique, doit inclure les fonctionnalités identifiées comme fondamentales au paragraphe 3.1. C'est à partir des informations fournies ici que la MOE pourra identifier la liste des transactions critiques (au sens informatique).
Ce paragraphe est à remplir dans le cas où l’application à mettre en œuvre correspond à un lot provisoire, en attente d’une version définitive. Il s’agit alors ici d’indiquer le niveau d’évolutivité et de maintenabilité attendu pour cette version provisoire, compte tenu de sa durée de vie souhaitée par la MOA.
Le contenu du serveur doit pouvoir évoluer rapidement pour répondre à l’évolution des différents besoins de l’utilisateur.
Dans un premier temps il a été choisi de mettre en place un nouveau schéma semestriellement. Cette évolution est pilotée par le comité d’évolution et un comité technique.
Il s'agit ici de préciser les activités de contrôle qui doivent être automatisées (nature, fréquence, durée,...), les statistiques à fournir à cet égard ainsi que les éléments utiles au contrôle de 1er et 2ème degré (responsable, informations de reporting nécessaires.
L’administrateur des données et le comité technique valident chaque mois les conditions dans lesquelles s’est déroulé le processus « Extraction – Injection » et donnent son feu vert pour la mise à disposition.
Cette description s’effectue à partir des éléments déjà identifiés au dossier de faisabilité et résulte d’une négociation entre les souhaits de la MOA et les contraintes de la MOE.
Il s’agit de décrire notamment :
Il convient d’indiquer explicitement le mode de bascule souhaitée par la MOA (bascule immédiate ou étalée dans le temps).
Dans le cas d’une bascule progressive (par sites et/ou par fonctionnalité ou lorsque, par précaution, la MOA souhaite conserver l'ancien système), il convient de décrire le type de cohabitation à mettre en œuvre avec le ou les systèmes existants.
Remarque : Ce type de cohabitation sera à considérer systématiquement pour la phase de sites pilotes.
Au fur et à mesure de la mise en service de nouvelles requêtes les éditions équivalentes produites actuellement par les applications de gestion seront supprimées après comparaison des résultats.
Il s’agit ici de recenser tous les besoins fonctionnels relatifs à l’environnement technique de recette fonctionnelle, à la constitution de jeux d’essais automatisés, à la réalisation d’une base école, à la mesure des objectifs métier et des enjeux du projet pour la Société...
Ces besoins découlent des réflexions portant sur le cadre de la recette fonctionnelle (protocole de recette fonctionnelle) et sur la solution d’accompagnement.
La MOA fournit ici le glossaire des termes métiers employés dans le présent document.