« 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é. 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
''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.
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.
▲souhaitée est le cahier des charges, qui définit ce que doit faire l'application informatique. Nous
<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é.▼
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.▼
▲impose une méthode à l'étudiant, celui-ci a généralement l'impression qu'elle est inutile, car il se
▲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.
Mais insensiblement, la taille des programmes tend à augmenter.
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…▼
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.
▲croissantes, mais puisqu'on y arrivait jusqu'à présent, il n'y a pas de raison que cela ne continue pas
▲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.''
|