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 :

• Le besoin effectif de l’utilisateur
• Les fonctions offertes par le logiciel

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

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

• Emphase sur l’analyse des besoins
• Amélioration de la communication (langage commun, démarche participative)
• Travail rigoureux

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 :

• Sur plus de 8000 projets informatiques, moins d’un cinquième étaient couronnés de succès.
• Le coût moyen des logiciels produits était de l’ordre du double des estimations
• Ces statistiques sont mises à jour chaque année, mais la méthodologie est décriée

Restons optimistes

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

• Succès des projets : 1 projet sur 2
• Problèmes importants : 1 projet sur 3 (dépassements importants de délais ou de coûts, fonctionnalités manquantes)
• Echecs des projets : 1 projet sur 6 (abandon du projet)

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 :

• La correction de bugs
• La maintenance

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 :

• 4/5 du coût de maintenance est absorbé par la corections de problèmes de définition des besoins
• 1% seulement concerne les problème de codage

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 :

• Définition des besoins
• Conception
• Codage
• Intégration / Tests

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

• Moins de documents textuels et plus de modèles formels
• A toutes les étapes du développement

Unified Modeling Language

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

• Définition des besoins
• Conception

Utilisation d’UML en pratique

A utiliser conjointement à :

• Des langages de programmation pour le codage proprement dit
• Des IDE facilitant l’intégration et les tests

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

• Toute modification du code est automatiquement répercutée sur les modèles
• Toute intervention sur les modèles vient modifier le code

Conception par décomposition fonctionnelle

Approche descendante :

• Décomposer la fonction globale jusqu’à obtenir des fonctions simples à appréhender et donc à programmer

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

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

• A ne pas faire #1 car voué à l’échec :
  1. Tout modéliser avec UML
  2. Etre très satisfait du résultat
  3. Tout coder
  4. Tout coder
• A ne pas faire #2 car voué à l’échec
  1. Essayer #1
  2. Constater son échec
  3. Ne plus jamais modéliser quoi que ce soit
• A faire :
  1. Modéliser ce qu’il faut pour les fonctionnalités les plus importantes
  2. Développer les fonctionnalités correspondantes
  3. Constater que ce sous-ensemble du logiciel fonctionne
  4. Recommencer pour une fonctionnalité un peu moins critique

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