01 53 63 37 87

certification PMI

fiche de connaissance

Fiche plan type d’un cahier des charges infocentre - datawarehouse

consulting formations PMP® simulateur PMP®

Plan type d’un cahier des charges infocentre - datawarehouse

Delf, centre de formation en maîtrise d'ouvrage, maîtrise d'oeuvre et gestion de projets à Paris met à votre disposition cette fiche technique.


Sommaire

Rappel du contexte général du projet

  • Historique du projet
  • Objectifs à atteindre, besoins à satisfaire
  • Positionnement et périmètre du projet
  • Axes d'évolution et enjeux 
  • Principes de base de la solution fonctionnelle retenue en étude de faisabilité
  • Planning et budget du projet
  • Risques / réserves éventuelles identifiés lors de la faisabilité

Couverture organisationnelle de l’application à mettre en œuvre

  • Métiers
  • Types de sites
  • Types d’acteurs
  • Organisation du travail

Les fonctionnalités de l’application à mettre en œuvre

  • Liste des fonctionnalités
  • Positionnement dans l'organisation cible
  • Enchaînements logiques des fonctionnalités
  • Règles de gestion associées
  • Données manipulées

Données à gérer

  • Description sémantique des données et règles de gestion associées
  • Données échangées
  • Données de type référentiel
  • Volumétrie
  • Historisation des données

Interface utilisateur

  • Architecture du dialogue homme-machine
  • Aides       
  • Éditions

Exigences vis-à-vis de l'application

  • Contraintes liées aux futures conditions de travail
  • Niveau de performances
  • Accès aux données historisées
  • Niveau de visibilité sur les données
  • Niveau de sécurité
  • Comportement de l'application face aux anomalies
  • Traçabilité des erreurs
  • Fonctionnalités critiques
  • Évolutivité / Maintenabilité
  • Contrôle interne

Migration de l’existant à mener

  • Nature de l’existant à reprendre
  • Bascule ancien/nouveau système

Besoins fonctionnels connexes


Rappel du contexte général du projet

Historique du projet

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 ;

  • L’alimentation d’un réservoir d’informations à partir des applications existantes ;
  • Le choix d’un outil permettant de formuler des requêtes multicritères.

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.

Objectifs à atteindre, besoins à satisfaire

Les principaux objectifs visent à restituer dans de bonnes conditions de délai et de fiabilité les informations contenues dans les différents fichiers :

  • Mettre à disposition des informations de pilotage ;
  • Rendre cohérent l’ensemble des informations publiées ;
  • Disposer de procédures pertinentes et efficaces.

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.

Positionnement et périmètre du projet

Les domaines connexes au projet étudié sont les suivants :

  • Le domaine commercial concerne la gestion des clients, des commandes et des ventes (valorisation, CA, ….) ;
  • Le domaine gestion concerne la gestion des stocks, la facturation et la comptabilité ;
  • Le domaine production traite de la gestion de production.
  • Le domaine « Produit » gère le catalogue.

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.

Axes d'évolution et enjeux

Les principaux axes d’évolution retenus sont de :

  • Rendre de plus en plus disponible les informations aux utilisateurs ;
  • Favoriser progressivement les opérations logiciels.

L’enjeu principal quant à lui est de rester positionné sur notre marché traditionnel.

Principes de base de la solution fonctionnelle retenue en étude de faisabilité

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.

Planning et budget du projet

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.

Risques / réserves éventuelles identifiés lors de la faisabilité

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).


Couverture organisationnelle de l’application à mettre en œuvre

Il s’agit de spécifier de façon exhaustive et détaillée les fonctionnalités attendues.

Métiers

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

Types de sites

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.

Types d’acteurs

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.

Organisation du travail

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 :

  • La recherche de prospect ;
  • Le suivi clientèle ;
  • La gestion des stocks ;
  • La gestion des commandes ;
  • Le suivi des ventes ;
  • La facturation ;
  • L’enregistrement comptable.

Les fonctionnalités de l’application à mettre en œuvre

Il s’agit de spécifier de façon exhaustive et détaillée les fonctionnalités attendues.

Liste des fonctionnalités

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 :

  • La gestion des requêtes
  • Les consultations (exécution des requêtes)
  • La production d’états.

Les autres fonctionnalités permettent de gérer le contenu de la base d’informations :

  • Les extractions et injections de données ;
  • La gestion des demandes d’évolutions ;
  • L’assistance à l’utilisation.

Positionnement dans l'organisation cible

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.

Enchaînements logiques des fonctionnalités

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 :

  1. Identification des clients présentant telles caractéristiques
  2. Récupération des informations X, Y et Z relatives aux commandes non encore facturées
  3. Calcul des montants, compte tenu des tarifs en vigueur et des droits à promotion
  4. Génération des bordereaux de facturation
  5. Fournitures pour impression de l'ensemble des bordereaux constitués triés par départements.

Remarques :

  • Il s'agit de décrire ici la logique de fonctionnement interne de l'application, du point de vue fonctionnel. L'enchaînement de ces fonctionnalités peut être entièrement automatisé ou bien nécessiter l'intervention de l'utilisateur. Dans ce cas, les principes de l'interface homme-machine à mettre en place sont décrit au paragraphe 5.
  • Le cas échéant, on précisera dans quelle mesure l'application dépend d'autres applications (génération d'un événement déclenchant ou service rendu).

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 :

  • Construire une requête ou choisir une requête ;
  • Simuler une requête (estimation des temps) ;
  • Exécuter une requête ;
  • Sauvegarder le résultat d’une requête ;
  • Cataloguer une requête.

Règles de gestion associées

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 :

  • La fiabilité des données est sous la responsabilité de chaque responsable des applications de gestion.
  • L’ensemble des opérations de mise à disposition des données devra être fait avant le dernier jour ouvrable du mois.
  • L’administrateur des données de la société devra valider le serveur avant de le mettre à disposition.
  • Les requêtes nouvelles ne peuvent être cataloguées que par des utilisateurs habilités.
  • Toute requête cataloguée doit être décrite et communiquée à l’ensemble des utilisateurs potentiels.
  • Une requête dont le type d’exécution dépasse x secondes cpu devra être interrompue.
  • Les requêtes cataloguées non utilisées pendant 6 mois, seront archivées.
  • Les demandes d’évolutions acceptées par le comité d’évolution devront être en œuvre dans les 3 mois.

Données manipulées

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 :

  • Nom de la requête
  • Type de requête (requête ou état)
  • Date de création
  • Date de mise à jour
  • Date de dernière exécution
  • Nombre d’exécution
  • Nom de l’auteur
  • Définition de la requête

Il s’agit essentiellement de l’entité de gestion « requête ».


Données à gérer

Description sémantique des données et règles de gestion associées

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 :

  • Le nom de la donnée en conformité avec les règles d’appellation interne ; (cf. fiche sur l’intranet).
  • La définition sémantique de la donnée en conformité avec les règles de définition interne (cf. fiche sur l’intranet).

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 »).

Données échangées

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é.

Données de type référentiel

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.

Volumétrie

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.

Historisation des données

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.


Interface utilisateur

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).

Architecture du dialogue homme-machine

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 :

  • Accueil,
  • Navigation au sein de l'application (par les données ou par menus, la cinématique d'enchaînement des écrans pouvant être prédéterminée ou pas selon les types d'utilisateurs),
  • Exigences de la MOA relativement aux messages de confirmation, d'erreur,...
  • éventuelles interactions avec des systèmes connexes de type bureautique

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.

Aides

Il s’agit ici de préciser:

  • La liste des thèmes à aborder, le degré de précision des thèmes par cible, la définition de la structure des informations de l’aide générale,
  • Le mode d'activation et de désactivation du système d'aide en ligne de l'application., Les procédures d'accès à la documentation de l'application (papier ou électronique).

L’outil choisi devra permettre de rendre accessible la définition sémantique pour chaque donnée.

Éditions

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.


Exigences vis-à-vis de l'application

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:

  • testées à l’occasion de la recette fonctionnelle,
  • inscrites dans le contrat de service. À ce titre, la maîtrise d’ouvrage précisera explicitement, au fil des paragraphes ci-dessous, les exigences de qualité de service qu’elle souhaite voir prises en compte dans le contrat de service ainsi que les indicateurs de mesure associés.

Contraintes liées aux futures conditions de travail

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 :

  • Dans le cadre d’une application de gestion de stocks, de la nécessité pour l’utilisateur de saisir les bordereaux de livraison tout en gardant ses gants et tout en restant sur le quai de chargement, même par temps de pluie.
  • Des contraintes relatives aux logiciels de services (réutiliser tel type d’imprimante, messagerie, etc....).

L’application à mettre en place devra s’inscrire dans l’ensemble des solutions techniques actuellement en place. Il s’agit pour l’essentiel :

  • un poste de travail client Windows NT
  • les imprimantes réseaux de chaque service
  • le serveur d’exploitation

Niveau de performances

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.

Accès aux données historisées

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.

Niveau de visibilité sur les données

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.

Niveau de sécurité

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 :

  • Les profils d’accès, c’est à dire les ensembles de droits d’accès à la future application (matériel/logiciel de base, locaux,...), à ses fonctionnalités et à ses données. Ces profils accès seront attribués à des individus ou à des groupes d’individus, pendant une période donnée.
  • Le cas échéant, la MOA précisera le niveau de traçabilité qu'elle souhaitera avoir (qui a fait quoi et quand), ainsi que les modalités d'accès aux traces correspondantes (procédures et habilitations).
  • La procédure d’administration de ces droits d’accès dans le cadre de la future organisation du travail.

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 :

  • Les contraintes liées à l'intégrité des données (peut-on ou non se permettre de perdre des données, sur quelle période),
  • Les éventuelles contraintes organisationnelles relatives à l'intégration de dispositifs tels que les anti-virus,
  • Ses éventuels besoin en terme de traçabilité des actions entreprises.

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.

Comportement de l'application face aux anomalies

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 à :

  • Court terme, une solution de contournement ainsi qu’un délai pour le traitement de cette anomalie ;
  • Moyen terme, une solution de traitement de l’anomalie dans le délai annoncé.

Traçabilité des erreurs

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 version du serveur consulté
  • l’algorithme de calcul utilisé

Fonctionnalités critiques

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 :

  • Niveau de performance exigé particulièrement important,
  • Fréquence d'utilisation élevée, par tout ou partie des utilisateurs,
  • Importance fonctionnelle fondamentale,
  • Fonctionnalité déjà informatisée dans un système existant (performances de référence),
  • Fonctionnalités présentant un risque de rejet de la part des utilisateurs (par exemple parce qu'elle suppose d’eux qu’ils changent leurs habitudes de travail sans leur apporter en contrepartie de valeur ajoutée)

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).

Évolutivité / Maintenabilité

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.

Contrôle interne

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.


Migration de l’existant à mener

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.

Nature de l’existant à reprendre

Il s’agit de décrire notamment :

  • La nature des données à reprendre (y compris leurs origines)
  • Les volumes à récupérer

Bascule ancien/nouveau système

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.


Besoins fonctionnels connexes

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.


Annexe : glossaire des termes /abréviations"métiers" employés.

La MOA fournit ici le glossaire des termes métiers employés dans le présent document.