Définition des besoins pour le logiciel (Collection études et logiciels informatiques)

Yves Constantinidis

Description

Définir les besoins pour un logiciel est un processus difficile qui fait appel à des compétences humaines, techniques et méthodologiques très variées, alliant rigueur et créativité. Une étude efficace des besoins réduit très sensiblement le coût du développement et de la maintenance d'une application et accroît sa qualité. Définition des besoins pour le logiciel est un outil d'aide à la maîtrise d'ouvrage et à la conception de projets. Il permet de recueillir et d'analyser les besoins et d'élaborer un cahier des charges pour un logiciel. L'ouvrage décrit : les étapes pour définir les besoins en partant des objectifs, les différentes techniques de recueil et d'analyse, une méthode efficace pour élaborer un cahier des charges, des plans types de cahiers des charges et un guide de rédaction, des conseils techniques et des recommandations aux managers, des études de cas.
Chapitre 1. Le besoin et l'exigence. La relation client-fournisseur. Besoin, demande, exigence, spécification. Le cycle de vie du logiciel. À qui s'adresse ce livre ? Guide de lecture. Chapitre 2. Qu'est-ce qu'un "bon" logiciel ? Les attributs fondamentaux du logiciel. Trois niveaux de vision de la qualité. Les caractéristiques de la qualité. La fiabilité. La maintenabilité. La portabilité et la facilité d'installation. La transparence. L'esthétique. La variabilité. Chapitre 3. La maîtrise de l'ouvrage. Projet, oeuvre et ouvrage. Les trois activités sous la responsabilité de la maîtrise d'ouvrage. Le cahier des charges. La validation. Le suivi du projet. Chapitre 4. La définition des objectifs. Au préalable : une décision de changement. Le contenu de la phase d'objectifs. Les activités de la phase d'objectifs. L'analyse de l'existant. L'analyse des parties prenantes (les acteurs). L'étude comparative. La déclaration d'objectifs. Chapitre 5. Recueil et analyse des besoins. Activités de l'ingénierie des besoins. Les grandes étapes. De la difficulté d'exprimer les besoins. L'intervention de recueil des besoins. Typologie des exigences. Les diverses techniques de recueil et d'analyse. Chapitre 6. Sept critères d'ergonomie. Qu'est-ce que l'ergonomie ? Ergonomie : la qualité vue de l'utilisateur. Les sept règles d'ergonomie. L'application des principes d'ergonomie à la construction du logiciel. Chapitre 7. Le cahier des charges : élaboration. L'utilité du cahier des charges. Producteurs et consommateurs des exigences. Centrer le projet autour du cahier des charges. Présentation de la démarche. Lancer le projet d'élaboration du cahier des charges. Spécifier l'objectif. Analyser l'existant. Proposer des améliorations. Réviser l'organisation. Les défauts fréquents sur un cahier des charges. Conseils pratiques et précautions à prendre. Chapitre 8. Le cahier des charges : guide de rédaction. Présentation de ce chapitre. La norme X50-151. Autres modes de présentation du cahier des charges. Guide de rédaction du cahier des charges. Chapitre 9. Validation et diagnostics. Validation des exigences. Les différentes méthodes de validation. Audits et diagnostics de logiciel. Mesure de l'utilisabilité : le questionnaire SUMI. Chapitre 10. La gestion et le suivi des exigences. Pourquoi les exigences doivent être gérées ? Comment les exigences doivent être gérées. Les activités de gestion des exigences. De la rentabilité des opérations de gestion. Chapitre 11. Quelques conseils techniques. Considérer la définition des exigences comme un vrai projet. Gérer par les objectifs. Choisir le bon modèle de cahier des charges. Utiliser les outils avec discernement. Utiliser de multiples techniques et formalismes. Maquetter et prototyper juste ce qu'il faut. Chapitre 12. Aspects managériaux et facteurs humains. Savoir quels sont les acteurs. Ne pas croire que le client a toujours raison. Gérer les priorités dynamiquement et chercher le consensus. Connaître le coût et la valeur de chaque exigence. Gérer la qualité, par la qualité et avec la qualité du produit. Alterner rigueur et imagination. Choisir un représentant des utilisateurs dynamique et volontaire. Garder en permanence le contact avec les utilisateurs. Informer et faire participer toutes les parties prenantes. Perdre du temps pour en gagner. Chapitre 13. Trois études de cas. Une histoire de communication. Cas numéro 1 : le RAD perverti. Cas numéro 2 : la lourdeur qui tue. Cas numéro 3 : la simplicité gagnante. Chapitre 14. Un nouveau métier : le designer de logiciel. Rigueur et innovation. La construction de la qualité. Le besoin d'un designer. Un homme de terrain, une vision stratégique. Quel avenir pour le designer ? Conclusion. Glossaire. Bibliographie. Sites web utiles.

Sujets

• Informatique
• Fonctionnement et organisation de l'entreprise
• Économie

Informations

• Publié par: Hermès - Editions Lavoisier
• Date de parution: 28 juin 2006
• Nombre de lectures: 87
• EAN13: 9782746228375
• Langue: Français

Extrait

C HAPITRE 1

Le besoin et l’exigence

Avant de nous embarquer dans l’ingénierie des besoins proprement dite, il est important de définir les motsbesoins et exigences dans un double contexte : d’une part, la relation entre client et fournisseur, et d’autre part, le cycle de vie du logiciel.

1.1. La relation client-fournisseur

La relation client fournisseur est la relation fondamentale de la vie économique. Le client est celui qui a un besoin, qui fait une demande auprès d’un fournisseur ; lequel traduit cette demande 1 en une solution (produit ou service) vendue au client .

En théorie, les choses sont simples : le client éprouve un besoin et s’adresse à un fournisseur. Le fournisseur traduit cette demande en spécifications, qu’il fait valider par le client, et réalise ensuite un service, ou fabrique un produit selon ces spécifications.

1. Cette définition n’exclut pas que le client et le fournisseur appartiennent à la même entreprise. Dans cet ouvrage le motclient (resp.fournisseur) pourra être considéré comme un synonyme demaître d’ouvrage(resp.maître d’œuvre).

14 Définition des besoins pour le logiciel

Dans la réalité, bien sûr, les choses sont beaucoup plus complexes. Dans la majorité des cas, la demande reflète très mal le besoin ; elle en privilégie quelques aspects, à un instant donné, qui traduisent plus le problème du moment que de véritables nécessités à long terme. De plus, la demande est maladroitement formulée et le fournisseur perçoit un message brouillé d’où il extrait des spécifications inadaptées. Enfin, client et fournisseur ont rarement la même culture : leurs vocabulaires sont différents et ils ne portent pas attention aux mêmes éléments. A partir de ce message brouillé, le fournisseur réalise souvent une solution qui a peu de chances de satisfaire le véritable besoin de l’utilisateur.

1.2. Besoin, demande, exigence, spécification

1.2.1.Le besoin

Derrière le motbesoin se cachent deux significations, parfois fort différentes. La première concerne les besoins affichés, généralement liés à l’entreprise : amélioration de l’efficacité de l’entreprise, gain de parts de marché, avantage concurrentiel durable, réduction des coûts, service à la clientèle.

Mais sous ces besoins exprimés se cachent d’autres préoccupations, plus secrètes, en rapport avec les objectifs personnels : conserver son autorité, renforcer sa place dans l’entreprise, se débarrasser des gêneurs, renforcer son pouvoir, se mettre en valeur, se soustraire aux responsabilités, ou préparer son évolution de carrière hors de l’entreprise… qui se résument dans l’acronyme mnémoniquebesoin utilisé par les vendeurs : –bien-être: confort matériel, environnement de travail ; –estime: besoin de considération, reconnaissance des capacités ; –sécurité: craintes de prise de risques individuels ;

Le besoin et l’exigence 15

–orgueil: réussite d’un défi, promotion ; –intérêt: salaires, primes, avantages divers ; –nouveauté: curiosité vis-à-vis d’un nouveau produit, d’un projet innovant.

Une des activités du consultant eningénierie des besoinsest de distinguer les besoins personnels des besoins de l’entreprise, de négocier les conflits entre les différents types de besoins, et de chercher à obtenir un équilibre entre eux.

1.2.2.La demande

La demande est une description subjective et partielle de la perception d’un besoin, par une personne, à un instant donné. Très souvent, la demande dépasse largement le véritable besoin, du moins sur certains points. Sur d’autres points, ou exprimée par d’autres personnes, la demande passe sous silence des besoins essentiels.

La solution pragmatique réside dans un compromis. Il appartient aux deux parties de définir ensemble une cible commune à mi- chemin entre un besoin inaccessible et une demande trop partielle. Nous appelleronsexigence l’expression formelle de cette cible. Dans l’intérêt des deux parties, il faut pouvoir facilement mesurer le degré de satisfaction d’une exigence.

1.2.3.L’exigence

Une exigence est la formalisation d’une cible commune pour le client et le fournisseur. Par rapport à la demande, l’exigence tient compte descontraintes, et introduit une notion de consensus. L’exigence est une caractéristique demandée par le client et acceptée par le fournisseur.

16 Définition des besoins pour le logiciel

L’exigence introduit une notion demesure. Il faut que l’on puisse objectivement à la fin des travaux constater qu’une exigence a été satisfaite ou non. Ce qu’on appelle « la qualité » est avant tout la conformité aux exigences.

1.2.4.La spécification

Enfin, laspécification est la traduction des exigences dans un langage convenu entre le client et le fournisseur. Elle permet d’éviter les effets pervers qui irritent leurs relations, y compris dans le cas où les deux parties, client et fournisseur, sont de bonne foi. L’activité de spécifier est une démarche industrielle.

Besoins

le besoin non exprimé

le réaliste

les exigences

Spécifications

le faisable

La tentation du technicien

Contraintes

Demande

le rêve

Figure 1.1.Des besoins à la solution : le développement des exigences

La démarche d’ensemble, qui consiste à passer des besoins aux exigences spécifiées par un certain nombre d’étapes contrôlées, s’appelledéveloppement des exigences. Ce qui rend l’exercice extrêmement difficile est la nécessité de tenir compte en permanence des écarts entre le besoin (exprimé ou non), la demande (qui peut correspondre à un besoin ou non, être

Le besoin et l’exigence 17

faisable ou non) et les contraintes, en découvrant le besoin non exprimé, et en filtrant la demande irréaliste (le rêve) et en résistant à la tentation du technicien (réaliser ce qui ne correspond pas à un besoin).

1.3. Le cycle de vie du logiciel

Le cycle de vie du logiciel peut être représenté de plusieurs manières. Le schéma de la figure 1.2 en donne une représentation en huit phases. En effet, contrairement au « cycle de développement », qui correspond à un projet, et comporte donc un début et une fin, la vie du logiciel est véritablement cyclique : dans la majorité des cas, la dernière phase d’un cycle s’enchaîne avec la première étape du cycle suivant. Cette représentation permet de mettre en avant une idée importante dans le cadre de cet ouvrage : la technologie du logiciel est une technologie de l’évolution.

Exploitation et maintenance

Installation et déploiement

Retrait

Tests et qualification

Objectifs et concepts

Exigences

Conception

Réalisation

Figure 1.2.Le cycle de vie du logiciel