« Méthodes de génie logiciel avec Ada/Première partie » : différence entre les versions

Contenu supprimé Contenu ajouté
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 8 :
:''La méthode HOOD a été conçue pour répondre à un appel d'offres de l'Agence spatiale européenne qui voulait une méthode spécifique pour Ada.''
:''Langage sans méthode n'est que ruine... de la société de service.''
Nous voyons, à travers ces quelques exemples, une contradiction dans la perception du rôle du langage par rapport à celui de la méthode : simple moyen de traduire une conception en une forme compréhensible par l'ordinateur pour les uns, expression directe et vérifiée de la conception pour les autres. En fait, les deux ont raison... selon le langage considéré. Dans cette partie, nous allons étudier les rapports des méthodes aux langages, et nous verrons que si les autres langages ne peuvent que partiellement apporter leur soutien aux méthodes, Ada a été conçu précisément pour leur servir de prolongement naturel.
 
=Rôle et principes des méthodes de conception=
 
Si la nécessité d'une méthode est bien établie dans le développement de logiciels industriels, elle est trop souvent ressentie comme une gêne par le programmeur, qui souhaiterait toujours coder immédiatement.
immédiatement. D'ailleurs, celui-ci a souvent écrit des programmes sans utiliser de méthode, et ils ont très bien marché.
est trop souvent ressentie comme une gêne par le programmeur, qui souhaiterait toujours coder
ont très bien marché. L'intérêt d'une méthode ne se fait sentir qu'à long terme, souvent au niveau des phases d'intégration.
immédiatement. D'ailleurs, celui-ci a souvent écrit des programmes sans utiliser de méthode, et ils
phases d'intégration. Ceux qui pensent pouvoir s'en dispenser nous rappellent cette citation d'un industriel américain du début du siècle :
ont très bien marché. L'intérêt d'une méthode ne se fait sentir qu'à long terme, souvent au niveau des
phases d'intégration. Ceux qui pensent pouvoir s'en dispenser nous rappellent cette citation d'un
industriel américain du début du siècle :
 
''Nous n'avons que faire du téléphone ; nous possédons un système de coursiers qui fonctionne très bien.''
 
Aussi est-il important de bien comprendre le rôle joué par les méthodes pour la conception et leur impact sur le cycle de vie.
leur impact sur le cycle de vie. La décision d'écrire un programme d'informatique est toujours prise dans le but de résoudre un problème du monde réel<ref>Sauf pour ceux qui écrivent des virus, qui cherchent alors plutôt à créer des problèmes…</ref>.
L'expression de la solution informatique souhaitée est le cahier des charges, qui définit ce que doit faire l'application informatique. Nous
dans le but de résoudre un problème du monde réel<ref>Sauf pour ceux qui écrivent des virus, qui
Nous allons parler ici des méthodes permettant, à partir de là, d'obtenir un programme répondant à ses exigences ; il s'agit donc de ce que l'on appelle les méthodes de conception détaillée, par opposition aux méthodes de spécification qui interviennent dans l'établissement du cahier des charges.
cherchent alors plutôt à créer des problèmes...</ref>. L'expression de la solution informatique
souhaitée est le cahier des charges, qui définit ce que doit faire l'application informatique. Nous
allons parler ici des méthodes permettant, à partir de là, d'obtenir un programme répondant à ses
exigences ; il s'agit donc de ce que l'on appelle les méthodes de conception détaillée, par opposition
aux méthodes de spécification qui interviennent dans l'établissement du cahier des charges.
 
<references />
 
==Complexité et limitations de l'esprit humain==
Lorsque le problème à résoudre est suffisamment simple, il est relativement facile de concevoir directement le programme à partir du cahier des charges.
Dans l'enseignement traditionnel de l'informatique, qui se réduit trop souvent à l'enseignement de la programmation, on fait exprès de donner des problèmes dont la solution se déduit relativement facilement de l'énoncé.
directement le programme à partir du cahier des charges. Dans l'enseignement traditionnel de
Même si l'on impose une méthode à l'étudiant, celui-ci a généralement l'impression qu'elle est inutile, car il se sent capable de produire directement la solution.
l'informatique, qui se réduit trop souvent à l'enseignement de la programmation, on fait exprès de
Bien souvent, il écrira tout de suite le programme et ne produira les documents de conception que par la suite, pour faire plaisir au professeur.
donner des problèmes dont la solution se déduit relativement facilement de l'énoncé. Même si l'on
impose une méthode à l'étudiant, celui-ci a généralement l'impression qu'elle est inutile, car il se
sent capable de produire directement la solution. Bien souvent, il écrira tout de suite le programme
et ne produira les documents de conception que par la suite, pour faire plaisir au professeur.
 
Ne jetons pas la pierre aux seuls étudiants : deux ans plus tard, ceux-ci sont ingénieurs et continuent à appliquer les mêmes méthodes de travail.
continuent à appliquer les mêmes méthodes de travail. ''Le problème est que cela fonctionne parfaitement !''
parfaitement !'' Bien sûr on connaît parfois quelques difficultés de maintenance, la survie du programme est mise en péril lors du départ du concepteur initial, mais ''grosso modo'' on y arrive, d'autant mieux que l'entreprise dispose de personnels « doués ».
Mais insensiblement, la taille des programmes tend à augmenter.
programme est mise en péril lors du départ du concepteur initial, mais ''grosso modo'' on y arrive,
On continue à développer de la même façon, avec des difficultés croissantes, mais puisqu'on y arrivait jusqu'à présent, il n'y a pas de raison que cela ne continue pas à fonctionner…
d'autant mieux que l'entreprise dispose de personnels «doués». Mais insensiblement, la taille des
Le problème est qu'il existe une taille critique, que l'on peut évaluer aux alentours de {{formatnum:10000}} lignes de code par programmeur<ref>Cette limite ne provient pas de mesures précises, mais est plutôt déterminée intuitivement par nos expériences personnelles.
programmes tend à augmenter. On continue à développer de la même façon, avec des difficultés
10 000 lignes de code par programmeur<ref>Cette limite ne provient pas de mesures précises, mais est plutôt déterminée intuitivement par nos expériences personnelles. Nous pensons cependant que la plupart des chefs de projet seront d'accord avec ce chiffre.</ref>, pour laquelle les problèmes de gestion vont soudain déborder les capacités des programmeurs.
croissantes, mais puisqu'on y arrivait jusqu'à présent, il n'y a pas de raison que cela ne continue pas
déborder les capacités des programmeurs. Un proverbe résume bien ce phénomène :
à fonctionner... Le problème est qu'il existe une taille critique, que l'on peut évaluer aux alentours de
10 000 lignes de code par programmeur<ref>Cette limite ne provient pas de mesures précises, mais est plutôt déterminée intuitivement par nos expériences personnelles. Nous pensons cependant que la plupart des chefs de projet seront d'accord avec ce chiffre.</ref>, pour laquelle les problèmes de gestion vont soudain
déborder les capacités des programmeurs. Un proverbe résume bien ce phénomène :
 
''On ne construit pas un pont sur un estuaire en extrapolant une passerelle sur une rivière.''