Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

1. Introduction. 2. Cahier des charges. 3. Spécification des besoins. 4. Presta

1. Introduction. 2. Cahier des charges. 3. Spécification des besoins. 4. Prestation de services. 5. Exemples d'annexes. Introduction. Le premier contact entre l'informaticien et son client prend des formes différentes, selon qu'il s'agit d'une informatique interne à la société, ou externe, et selon que l'initiative vient de l'un ou de l'autre. On a tendance à appeler 'cahier des charges' tout document qui cherche à préciser la nature du travail, les responsabilités de chacun, le cadre contractuel, etc. Quand le travail commence, il est tout à fait nécessaire de déterminer les besoins à satisfaire. Les relations avec un prestataire -surtout extérieur- doivent être très formalisées. Il s'agit de prévenir, de détecter et de traiter les éventuels conflits, dès leur apparition. Tous ces aspects différents aboutissent à des documents différents, qui se répondent et se complètent entre eux. De plus, de tels documents sont évolutifs, ce qui complique tout ! Pour simplifier, nous dirons que  le cahier des charges est un document chargé d'initialiser un chantier,  la spécification des besoins est le premier travail du chantier,  les aspects juridiques et contractuels sont spécialement traités dans un document à part, mais n'oubliez pas que dans la pratique les domaines empiètent les uns sur les autres. Retour à la table des matières. Cahier des Charges. La plupart des canevas proposés pour les cahiers des charges sont "orientés méthode", c'est à dire qu'ils sont spécifiques aux développements Merise par exemple. D'une manière générale, les points à vérifier qui sont indépendants de la méthode peuvent répondre au classement suivant. Remarque préalable: Merise date du temps où il était inconcevable qu'un utilisateur manifeste la moindre compétence en informatique: le cahier des charges était rédigé par l'informaticien qui jouait un rôle d'organisateur. Le terme de 'cahier des charges utilisateur' désigne dans ce contexte un mode d'emploi de l'application détaillé, avec une garantie de bon fonctionnement attachée. Points à vérifier:  - Qui contracte ? o - Quel client passe le contrat, quel client fera la recette ? o - Sous-traitance autorisée ?  - Quel est l'objet du contrat ? o - Sujet. o - Type (Avant-vente, pré-étude, étude, après-vente). o - Objectifs. o - Propriété finale du produit. o - Confidentialité.  - Quel est le dispositif ? o - Groupe de pilotage. 1. composition, 2. responsabilité, 3. mode de convocation. o - Suivi du projet. o - Planning du projet. o - Budget du projet. Trésorerie. o - Contrôle de gestion (interne). o - Groupe de réalisation. 1. développement 2. tests o - Méthodes de développement. nommer les méthodes choisies, annexer les documents de référence. o - Méthodes d'Assurance Qualité. o - Compatibilités à respecter. o - Plan de documentation.  - Comment se fera la recette ? o - Tests de fonctionnalité. o - Tests de charges. o - Ergonomie, documentation.  - Comment se fera la mise en route o - Installation des matériels. o - Installation des logiciels. o - Saisies initiales, paramétrages. o - Formation des utilisateurs.  - Service Après-Vente. o - Garantie de fonctionnement. o - Assistance à l'emploi.  - Gestion des problèmes. o - Retards de développement. o - Débordement de Budget. o - Non-respet des fonctionnalités. o - Changement des fonctionnalités. o - Retards de paiement. o - Arbitrage. Toutes sortes de documents peuvent se présenter en annexe. Si la solution est déjà étudiée pour partie, des modèles comme le M.C.D. ou le M.C.T. peuvent y figurer. A ce moment, bien sûr le développeur est tenu de s'y conformer, mais sa responsabilité est dégagée d'autant. Retour à la table des matières. Spécification des besoins. L'expression des besoins doit se soumettre à un formalisme suffisant pour être validée, aussi bien par le client que par le réalisateur. pour servir à qualifier (vérifier) les solutions. Une démarche possible:  - Etude des flux. o - Acteurs du mécanisme. o - Informations échangées. o - M.C.T.  - Identifier l'automatisable. o - Définir les entrées. o - Définir les sorties. o - Définir les traitements.  - Identifier les contraintes. o - Sur le processus.  - Normes de développement. o - Sur le produit.  - Fiabilité en fonctionnement.  - Confidentialité.  - Performances en charge.  - Portabilité ultérieure. o - Externes.  - Coûts.  - Interaction avec d'autres softs.  - Contraintes réglementaires. o - Ergonomie, documentation.  - Comme c'est le début de la phase d'analyse proprement dite, il va falloir vérifier o - Pas de besoin mal défini  voeu pieux  silence  sous-spécification o - Pas de solution prématurée.  sur-spécification o - Quantification des besoins. o - Approbation des documents. o - Documentation réutilisable. Toutes sortes de documents peuvent se présenter en annexe. Retour à la table des matières. Prestations de Services et Assistance Technique. La définition du service à rendre doit être assez claire pour que les conflits éventuels soient détectés et traités à temps. Une démarche possible:  - Objet.  - Organisation. o - Organisation et durée.  - Constitution des équipes.  - Accès aux informations.  - Réunions d'avancement.  - Méthodes employées. o - Dossier d'analyse, réalisation.  - Logiciels adaptés.  analyse, approbation.  modifications fonctionnelles ultérieures.  planning de réalisation.  réalisation.  pénalités de retard.  - Logiciels paramétrables.  - Logiciels standards. o - Installation des programmes. o - Réception provisoire. o - Réception définitive. o - Formation.  - Lieu d'éxécution.  - Droit de propriété. o Propriété de l'analyse. o Propriété du logiciel. o Cession des logiciels adaptés. o Licence des logiciels paramétrés. o Intégrité des programmes. o Utilisation des logiciels de base. o Logiciels standards.  - Secret, Utilisation exclusive.  - Non sollicitation de personnel.  - Garantie des logiciels. o - Logiciels adaptés. o - Logiciels paramétrables. o - Exclusions. o - Durée. o - Logiciels standards.  - Montants et Paiements. o - Coûts. o - Modalités de règlement. o - Clause de réserve de propriété.  - Responsabilité et Assurances.  - Limites du contrat. o - Maintenance. o - Configurations matérielles. o - Formation générale utilisateurs. o - Frais accessoires.  - Suspension et résiliation. o Suspension. o Résiliation. o Cession.  - Litiges. Toutes sortes de documents peuvent se présenter en annexe. Retour à la table des matières. Exemples d'annexes: 1. - Documents d'analyse. D'une manière générale, la première version d'un document d'analyse peut se trouver mentionnée: Organigrammes, flux, M.C.D., M.C.T., PERT des travaux... 2. - Etudes, Assistance, Logiciels. o - Champs des applications.  fonctionnalités couvertes.  documentation à fournir. o - Formation. o - Aide au paramétrage. o - Planning général. o - Modalités de règlement. o - Cadencement des facturations. o - Régime des frais de déplacement. o - Organisation de la prestation. 3. - Configuration et coûts matériel. C'est un problème particulier qui se pose quand la prestation logicielle est accompagnée d'une recommandation de matériel, voire une prise en charge de l'aspect matériel ! o - Configuration et coûts. o - Modalités de règlement. o - Cadencement des facturations. o - Livraison et installation. o - Rôle du prestataire. o - Annulation, modification commande. o - Garantie et maintenance. 4. - Méthodes de conduite de projet. Ce point prend beaucoup d'importance quand le client utilise une méthode formelle de qualité, et surtout s'il est lui-même certifié. Il arrive d'ailleurs que le formalisme du client et celui du fournisseur faisant double emploi, on convient d'un moyen terme, qui sera en pratique d'adopter les méthodes et les documents du client. o Méthodes. Il ne suffit pas de citer le nom d'une méthode: Merise en particulier est utilisé sous d'innombrables variantes, il faut citer les documents de référence ! o Manuel d'assurance qualité. o Plan d'assurance qualité. .../... etc uploads/s1/ introduction-au-cahier-du-charge.pdf