I.1.4 Notion de qualité pour un logiciel
En génie logiciel, divers travaux ont mené
à la définition de la qualité du logiciel en termes de
facteurs, qui dépendent, entre autres, du domaine de l'application et
des outils utilisés. Parmi ces derniers nous pouvons citer :
Validité : aptitude d'un produit
logiciel à remplir exactement ses fonctions, définies par le
cahier des charges et les spécifications.
Fiabilité ou robustesse : aptitude d'un
produit logiciel à fonctionner dans des conditions anormales.
Extensibilité (maintenance) : facilité avec
laquelle un logiciel se prête à sa maintenance,
c'est-à-dire à une modification ou à une extension des
fonctions qui lui sont demandées.
Réutilisabilité : aptitude d'un
logiciel à être réutilisé, en tout ou en partie,
dans de nouvelles applications.
Compatibilité : facilité avec
laquelle un logiciel peut être combiné avec d'autres logiciels.
Efficacité : Utilisation optimales des
ressources matérielles.
Portabilité : facilité avec
laquelle un logiciel peut être transféré sous
différents environnements matériels et logiciels.
Vérifiabilité : facilité de
préparation des procédures de test.
Intégrité : aptitude d'un logiciel
à protéger son code et ses données contre des accès
non autorisés. Facilité d'emploi :
facilité d'apprentissage, d'utilisation, de préparation
des données, d'interprétation des erreurs et de rattrapage en cas
d'erreur d'utilisation.
Ces facteurs sont parfois contradictoires, le choix des
compromis doit s'effectuer en fonction du contexte.
10
I.2. MODELISATION, CYCLES DE VIE ET
METHODES
I.2.1 Pourquoi et comment modéliser ?
Qu'est-ce qu'un modèle ?
Un modèle est une représentation
abstraite et simplifiée (i.e. qui exclut certains
détails), d'une entité (phénomène, processus,
système, etc.) du monde réel en vue de le décrire, de
l'expliquer ou de le prévoir. Modèle est synonyme de
théorie, mais avec une connotation pratique : un modèle, c'est
une théorie orientée vers l'action qu'elle doit servir.
Concrètement, un modèle permet de réduire
la complexité d'un phénomène en éliminant les
détails qui n'influencent pas son comportement de manière
significative. Il reflète ce que le concepteur croit important pour la
compréhension et la prédiction du phénomène
modélisé. Les limites du phénomène
modélisé dépendant des objectifs du modèle.
Pourquoi modéliser ?
Modéliser un système avant sa réalisation
permet de mieux comprendre le fonctionnement du système. C'est
également un bon moyen de maîtriser sa complexité et
d'assurer sa cohérence. Un modèle est un langage commun,
précis, qui est connu par tous les membres de l'équipe et il est
donc, à ce titre, un vecteur privilégié pour communiquer.
Cette communication est essentielle pour aboutir à une
compréhension commune aux différentes parties prenantes
(notamment entre la maîtrise d'ouvrage et la maîtrise d'oeuvre
informatique) et précise d'un problème donné.
Dans le domaine de l'ingénierie du logiciel, le
modèle permet de mieux répartir les tâches et d'automatiser
certaines d'entre elles. C'est également un facteur de réduction
des coûts et des délais. Par exemple, les plateformes de
modélisation savent maintenant exploiter les modèles pour faire
de la génération de code (au moins au niveau du squelette) voire
des aller-retours entre le code et le modèle sans perte d'information.
Le modèle est enfin indispensable pour assurer un bon niveau de
qualité et une maintenance efficace. En effet, une fois mise en
production, l'application va devoir être maintenue, probablement par une
autre équipe et, qui plus est, pas nécessairement de la
même société que celle ayant créée
l'application.
Le choix du modèle a donc une influence capitale sur
les solutions obtenues. Les systèmes non-triviaux sont mieux
modélisés par un ensemble de modèles indépendants.
Selon les modèles employés, la démarche de
modélisation n'est pas la même.
11
Qui doit modéliser ?
La modélisation est souvent faite par la maîtrise
d'oeuvre informatique (MOE). C'est malencontreux, car les priorités de
la MOE résident dans le fonctionnement de la plate-forme informatique et
non dans les processus de l'entreprise.
Il est préférable que la modélisation
soit réalisée par la maîtrise d'ouvrage (MOA) de sorte que
le métier soit maître de ses propres concepts. La MOE doit
intervenir dans le modèle lorsque, après avoir défini les
concepts du métier, on doit introduire les contraintes propres à
la plate-forme informatique.
Il est vrai que certains métiers, dont les
priorités sont opérationnelles, ne disposent pas toujours de la
capacité d'abstraction et de la rigueur conceptuelle nécessaires
à la formalisation. La professionnalisation de la MOA a pour but de les
doter de ces compétences. Cette professionnalisation réside
essentiellement dans l'aptitude à modéliser le système
d'information du métier : le maître mot est
modélisation. Lorsque le modèle du système
d'information est de bonne qualité, sobre, clair, stable, la
maîtrise d'oeuvre peut travailler dans de bonnes conditions. Lorsque
cette professionnalisation a lieu, elle modifie les rapports avec
l'informatique et déplace la frontière des
responsabilités, ce qui contrarie parfois les informaticiens dans un
premier temps, avant qu'ils n'en voient apparaître les
bénéfices.
Maîtrise d'ouvrage et maîtrise
d'oeuvre
Maître d'ouvrage (MOA) :
Le MOA est une personne morale (entreprise, direction etc.), une
entité de l'organisation. Ce n'est jamais une personne.
Maître d'oeuvre (MOE) :
Le MOE est une personne morale (entreprise, direction etc.)
garante de la bonne réalisation technique des solutions. Il a, lors de
la conception du SI, un devoir de conseil vis-à-vis du MOA, car le SI
doit tirer le meilleur parti des possibilités techniques.
Le MOA est client du MOE à qui il passe commande d'un
produit nécessaire à son activité. Le MOE fournit ce
produit ; soit il le réalise lui-même, soit il passe commande
à un ou plusieurs fournisseurs (« entreprises ») qui
élaborent le produit sous sa direction.
La relation MOA et MOE est définie par un contrat qui
précise leurs engagements mutuels.
12
Lorsque le produit est compliqué, il peut être
nécessaire de faire appel à plusieurs fournisseurs. Le MOE assure
leur coordination ; il veille à la cohérence des fournitures et
à leur compatibilité. Il coordonne l'action des fournisseurs en
contrôlant la qualité technique, en assurant le respect des
délais fixés par le MOA et en minimisant les risques.
Le MOE est responsable de la qualité technique de la
solution. Il doit, avant toute livraison au MOA, procéder aux
vérifications nécessaires (« recette usine »).
| 
