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