Vous êtes sur la page 1sur 9

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

Vous aimerez peut-être aussi