MODULE No 02

Titre : Quelques définitions (et redéfinitions !)

But : Proposer des définitions de quelques termes qui apparaissent très souvent lorsque au début du cycle de vie du logiciel

Antécédents : Module 01.

Corps : Voici le liste des termes que nous allons essayer de mieux cerner : besoin, contrainte, exigence, ingénierie, logiciel, machine, modèle et système

a. Besoin (need en anglais). « Situation de manque ou prise de conscience d’un manque » (TLF) Cet « ou » unit la partie « objective » de la définition « situation de manque » (et il y a donc, au moins en théorie, un moyen de le vérifier) avec une partie subjective où intervient un sujet (un humain) qui a conscience (qui ressent, qui sait…) qu’il lui manque quelque chose. Dans le langage courant « besoin » a toujours une connotation très subjective et la conscience du manque est souvent la condition essentielle pour parler de besoin. Note On oublie ici tout ce que l’inconscient recèle et qui occupe à temps plein bien de psychanalystes ».Fin de la note. En GL souvent le manque est un « manque à gagner » : c’est-à-dire qu’il s’agit d’une situation où une entreprise a besoin d’améliorer sa façon de produire, de concevoir, de distribuer, etc. Et pour satisfaire ce manque elle peut induire des besoins (plus ou moins artificiels) dans les personnes qui seront les utilisateurs du système créé pour satisfaire leurs besoins ! Même s’il y a des situations plus nuancées que celle que nous venons de décrire, il ne faut pas oublier que dans le contexte économique actuel les besoins qui n’ont pas de retombés économiques ne sont souvent pas considérés comme des « vrais » besoins. Dans notre cours, indépendamment de comment on est arrivé à les formuler, on considérera les besoins comme l’explicitation d’un problème qui doit être analysé pour trouver une solution. Le besoin, malgré le flou qui l’entoure, est le point de départ de notre travail d’analystes.

b. Contrainte. La contrainte, pour nous, sera une imposition non discutable sur ce que l’on veut que le logiciel fasse. Exigence et contraintes sont des termes sémantiquement assez proche. Donc ce que l’on demande à une machine de faire peut être une contrainte ou une exigence en fonction du niveau de rigidité de la demande : l’exigence est plus souple (ce qui ne veut pas dire qu’elle ne doit pas être satisfaite).

c. Exigence (requirement en anglais). Dans le module précédent nous avons vu les définitions d’un dictionnaire de la langue française où le mot clef nous semblait être « impérativement » et une définition de IEEE std. 610.12.

d. Ingénierie. On peut considérer l’ingénierie comme la base de toutes les disciplines qui appliquent des approches fondées sur les mathématiques à la construction de machines et qui essayent de maîtriser le plus possible les processus de conception et de production de la machine. Pour maîtrise les processus des mesurages sont introduits tout au long du cycle de vie.

e. Logiciel. La définition du module précédent tirée de IEEE Std 610.12 nous suffit.

f. Machine. Un artefact humain composé de parties nécessaires à la réalisation des fonctions qui ont présidé à sa construction. Une partie d’une machine peut être une machine. Une machine est, bien sûr, un système mais un système sans vie. Un programme est une machine.

g. Modèle. « Représentation simplifiée et plus ou moins formalisée d'un processus, d'un système » (Le Robert). « Une simplification de la réalité, créée pour mieux comprendre le système à créer. » (Manuel d’UML) Ce qui semble être important c’est « simplification », c’est-à-dire le fait que l’on a devant nous quelque chose de plus facile à manipuler intellectuellement ou physiquement. Le modèle atomique de Bohr est un bon exemple de simplification de la réalité des atomes. Le terme « Modèle » est actuellement employé à toutes les sauces (on verra dans la suite du cours une critique détaillée de « modèle » et « modélisation »).

h. Système. Quelques ajouts par rapport aux considérations du module 01. Malgré le titre du cours nous essayerons d’éviter le plus possible d’employer le terme « système ». Dans la limite du possible nous parlerons de machine et d’humain (qui, à notre avis, sont deux types de systèmes tellement différents qu’il ne vaut pas la peine de les subsumer sous le même concept). Ceci n’implique pas que nous sommes contre une approche systémique mais que,. dans une approche systémique à la technique, il est souhaitable de garder bien séparés les humains des machines.

Ce qui pour le « Génie logiciel » nous donne : « L’application d’une approche systématique, maîtrisée, quantifiable au développement, à l’exploitation et à la maintenance du logiciel : c’est-à-dire l’application de l’ingénierie au logiciel. » (IEEE Std 610.12)

Conséquents :

· Être conscients de comment certains termes, pourtant si simples ! deviennent problématiques dès qu’on les regarde d’un peu plus près.

Note 01 :