cours génie logiciel - Laurent Henocque
UML, Objet, Logiciel, Diagramme, Méthodologie ... Examen oral individuel : ...
Cycle de vie des applications informatiques; Génie logiciel, perspective
historique ...
Part of the document
18/3/95 maison : styles pour fusion du cours, pied de page, en tete
Contrôle Qualité en Programmation Laurent Henocque
http://laurent.henocque.free.fr/
Enseignant Chercheur ESIL/INFO France
http://laurent.henocque.perso.esil.univmed.fr/ [pic] Cette création est mise à disposition selon le Contrat Paternité-Partage
des Conditions Initiales à l'Identique 2.0 France disponible en ligne
http://creativecommons.org/licenses/by-sa/2.0/fr/
ou par courrier postal à Creative Commons, 559 Nathan Abbott Way, Stanford,
California 94305, USA. version 1.4 en date du 17 Novembre 2008
Introduction Le génie logiciel est une discipline qui vise à structurer et organiser
l'ensemble des activités liées à la réalisation de logiciels, et à
promouvoir des niveaux de qualité croissants.
L'expérience des succès et échecs de l'industrie informatique a permis de
dégager des concepts assez fédérateurs, et de mesurer leur efficacité.
L'activité des chercheurs dans des domaines aussi variés que la
psychologie, la linguistique, l'ergonomie et l'informatique évidemment a
permis de faire apparaître des notions dont certaines font preuve
aujourd'hui d'une grande acceptation du marché. La programmation orientée
objet en est un exemple, avec son langage phare qui est C++. De très grands
projets ont été réalisés selon des méthodes de spécification et de garantie
de qualité souvent dérivées de méthodes utilisées pour l'industrie
spatiale. On sait que l'efficacité maximale sur un projet informatique est
obtenue pour deux personnes travaillant pendant six mois. Mais les grands
logiciels sont réalisés par des équipes immenses (une centaine
d'ingénieurs) en plusieurs années.
Ce cours a pour projet de donner les bases de techniques de travail
reconnues comme nécessaires pendant tout le cycle de vie du logiciel, et
d'apprendre les méthodes qui permettent d'affronter systématiquement et de
résoudre les problèmes.
Fréquemment, les cours de génie logiciel s'appuient sur la chronologie
naturelle des projets, en débutant par la spécification, pour continuer par
la conception et finir par la programmation et la gestion de projet. Ce
cours aborde les aspects individuels de la programmation, sur la base du
langage C++, mais gagne a être abordé avant même que de parler de
conception et de spécification Les raisons sont notamment que : 1. nous pensons que la qualité des étapes préalables à la programmation
effective d'un logiciel, à savoir cahier des charges et conception,
dépendent de la connaissance de principes de qualité fondamentaux
dans la programmation. 2. le langage C++ couvre par sa puissance expressive une partie très
importante des besoins liés à la rédaction de documents de
spécification et à une conception orientée objet. L'utilisation de C++ ne doit pas faire oublier que le concepteur (au sens
large) d'un logiciel doit faire preuve d'ouverture d'esprit, et de
malléabilité. En effet, une fois maîtrisées les étapes de spécification et
de conception, l'étude préalable à la réalisation d'un logiciel conduit
souvent à l'utilisation de langages ou d'outils dont on n'est pas forcément
familier.
La démarche qualité présentée dans ce cours sur la base du langage C++
peut être vue comme un exemple de ce qui doit être effectivement mis en
oeuvre quels que soient le langage, la méthode et les outils utilisés au
final. Plan Nous verrons donc dans une première partie les concepts fondamentaux de
qualité logicielle, et notamment les notions de contrats, d'invariants et
une discussion sur la notion de test.
Ensuite, nous évaluerons de quelle manière l'activité de programmation
peut être organisée, dans un objectif de qualité. Une troisième partie
liste des considérations techniques sur la qualité. Enfin, certains aspects
humains (psychologiques notamment) seront abordés. Partie 1 Qualité en programmation: Notions fondamentales
1.1. Le contrat Principe fondamental dans toutes les activités industrielles ou plus
généralement économiques, le contrat est aussi un fondement de toutes les
étapes de l'élaboration d'un logiciel, de sa spécification jusqu'à son
abandon. Bien sûr, en fonction du point auquel on se situe, la nature et
les effets des différents contrats seront variables. Toutefois, on peut
reconnaître parmi les fonctions du contrat les éléments fondamentaux
suivants:
. le contrat garantit une communication sans défaut, par un examen
exhaustif de tous les cas nécessaires. Un bon contrat lève toute ambiguité
entre ses parties.
. le contrat est un support fondamental de la simplicité des solutions
mises en oeuvre pour le respecter. En effet, il permet de travailler en
monde clos, et de ne pas anticiper des évolutions improbables.
En matière de génie logiciel, les documents contractuels sont nombreux.
L'ensemble de ces pièces décrit les réponses aux questions suivantes :
. "quoi" : quelles sont les fonctionnalités à implanter,
. "comment ": comment accède t'on à ces fonctionnalités,
. "quand" quelles sont les limites hors desquelles ces
fonctionnalités ne sont pas accessibles (pas implantées).
Ces contrats lient dans tous les cas des "clients" et des "fournisseurs".
Trois niveaux fondamentaux de contrat sont usuels en informatique, et lient
des parties distinctes. Le plus haut niveau permet la communication entre
acheteur du logiciel et prestataire, c'est le cahier des charges
(spécification). Le niveau suivant lie les membres d'une équipe
d'informaticiens, c'est la conception. Enfin, avec la granularité
nécessaire, le dernier niveau lie les programmes entre eux. 1.1.1. La spécification : contrat entre client et
fournisseur Un contrat fondamental lie le prestataire d'une solution informatique et
son client: la spécification. Son document de référence est le cahier des
charges. Une fois accepté, il constitue un engagement des deux parties. Le
client admet que ses besoins y sont exprimés de façon correcte et complète,
et donc accepte d'avance toute solution conforme. Le prestataire sait de
son côté que les solutions qu'il envisage sont réalisables (dans les
délais, ceux ci pouvant apparaître comme un besoin dans la spécification).
Il a la garantie qu'aucun besoin nouveau ne viendra briser l'édifice qu'il
va construire.
L'acceptation du cahier des charges a donc pour effet de figer la partie
initiale de l'étude, permettant à la conception, puis au développement, de
se faire sur des bases solides. Il ne faudrait pas croire pour autant que
la spécification est réalisée indépendamment de ces phases ultérieures.
L'engagement de réalisation rend implicite la validation technique des
solutions envisagées. Cette validation peut aller jusqu'à la programmation
de certains modules pour tester une faisabilité. Par ailleurs, l'expression
des besoins par le client est parfois floue, et nécessite des interactions
entre les parties sur la base d'un prototype. Dans ce cas, des itérations
successives conduiront par exemple à l'acceptation d'un prototype qui sera
jugé adéquat.
Certaines activités logicielles ne comportent pas de client tangible, et
l'on pourrait être tenté de passer outre une phase de spécification
contractuelle. C'est le cas notamment dans l'édition de produit logiciel,
ou l'on tente de répondre à un besoin qui n'est pas toujours exprimé (sauf
peut être par une étude de marché sérieuse). Il est pourtant nécessaire
d'exprimer de manière écrite les engagements que prendront les différents
acteurs. La renégotiation en cours de réalisation d'un point de la
spécification est une opération qui peut conduire à des dépassements
considérables de budget. Un document écrit entre le service de recherche et
développement et sa direction est le meilleur témoin des responsabilités de
chacun.
Dans la mesure ou la spécification est une vue exacte du logiciel à
réaliser, ce document est la première pierre de sa documentation, et sa
qualité initiale sera un profit à toutes les étapes du travail et en
particulier à la fin.
Dans de nombreux cas, la pression exercée par l'extérieur sur le
prestataire pour faire démarrer les choses le plus vite possible aura pour
effet de réduire le temps passé sur la rédaction d'un document, sinon sur
la réflexion associée. Le prestataire doit avoir la force de lutter pour
écarter les points d'ombre, et éviter de laisser des bombes à retardement
dans la spécification.
Au niveau de la spécification, le "quoi" reflète l'ensemble des
fonctionnalités du produit, le "comment" sera souvent la spécification de
l'interface homme machine, et le "quand" correspondra à la mention
explicite rigoureuse des différentes limites de fonctionnement du système
(pas plus de 3 utilisateurs, pas de facture à zéro, etc...). 1.1.2. La conception : contrat liant les membres de
l'équipe Le contrat qui lie l'ensemble des développeurs entre eux et avec le chef de
projet est la conception. La conception décrit de manière détaillée
l'ensemble des solutions techniques devant être mises en oeuvre pour
implanter ce qui a été spécifié. Il est formellement impossible de faire
plus, ou moins, que ce que la conception a décrit. Aucune initiative
indi