Qualité d’un logiciel

Validité

La validité (correction, justesse, conformité) est la capacité que possède un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications.

Adéquation entre :

Même le logiciel le mieux conçu techniquement, s’il ne rend pas les services escomptés, est inutile et son développement aura été du temps perdu.

Problèmes de conception

Wendel et Golterman

Wendel et Golterman

Pour améliorer la qualité d’un logiciel :

Chaos Manifesto

Les problèmes liés à l’informatique sont essentiellement des problèmes de logiciel.

En 1995, le Standish group publiait un rapport accablant :

Restons optimistes

Même parmi les critiques les plus sévères du Standish group (The Rise and Fall of the Chaos Report Figures) :

Le taux de succès augmente très significativement quand on emploie des méthodes agiles ou un développement incrémental.

Coût d’un logiciel

Coût global

Le coût d’un logiciel n’est pas seulement le coût de production de sa première version. Il intègre égalmement :

Dilbert

Dilbert

Poids de la maintenance

La maintenance absorbe les 2/3 du coût global d’un logiciel

Corriger un problème est d’autant plus coûteux qu’il vient d’une erreur en amont :

La moitié du coût global d’un logiciel vient donc d’une mauvaise compréhension des besoins (Zeltovitz, De Marco).

Modélisation

Pour maîtriser le développement d’un logiciel

Nécessité de maîtriser toutes les étapes du développement d’un logiciel :

Nécessité d’améliorer la communication :

Unified Modeling Language

Langage de modélisaton définissant un ensemble de diagrammes cohérents les uns avec les autres pour modéliser :

Utilisation d’UML en pratique

A utiliser conjointement à :

Roundtrip engineering par des Ateliers de Génie Logiciel (Modelio par exemple) :

Conception par décomposition fonctionnelle

Approche descendante :

C’est la fonction qui donne la forme du système.

Conception Orientée Objet

C’est la structure du système lui donne sa forme.

L’implémentation d’une COO est plus facile en utilisant des langages de Programmation Orientés Objet (C++, Java, Smalltalk, C# etc).

Méthodologie

Trop ou pas assez ?

xkcd

xkcd

Procéder par développement incrémental / agile

UML est un langage, pas une méthode

Il est nécessaire d’avoir une méthode pour utiliser correctement le langage UML. A minima :

  1. Définition des fonctionnalités attentues par l’utilisateur avec des Diagrammes de Cas d’Utilisation
  2. Ordonner les cas d’utilisation du plus important au plus accessoire
  3. Démarrer par les cas d’utilisation les plus centraux et pour chaque cas :
    1. Définir précisément les scénarios sous-tendus par le cas d’utilisation à l’aide d’un Diagramme de Séquence pour le documenter
    2. Définir les types d’objets nécessaires à la résolution du cas considéré et enrichir le Diagramme de classes en conséquence
    3. Coder chaque méthode

NB : les diagrammes sont susceptibles d’évoluer à n’importe quelle étape du développement.


Module d’UML