Projets informatique : caractéristiques et méthodes de développement

Les caractéristiques d'un projet informatique

En informatique comme dans tout autre domaine, chaque projet est unique (ou presque...). Cependant, pour l'essentiel, ils présentent un certain nombre de caractéristiques que nous essayons de recenser ici.

Travailler sur un projet informatique nécessite de travailler sur 2 domaines: Un projet informatique est en général un projet développé au service d'une autre discipline, appelée discipline métier. Le logiciel qui va être développé va donc devoir manipuler des objets propres à cette autre discipline, souvent inconnue ou mal connue des développeurs, appelés objets métiers. C'est une des parties compliquées dans le développement d'un projet informatique : comprendre un domaine qui n'est pas le sien, discuter avec des personnes n'ayant pas les mêmes connaissances et qui vont devoir essayer de se mettre au niveau des développeurs.
Les projets sont en général sous-spécifiés: Un cahier des charges pour un projet informatique est en général très vague, et de nombreux points ne sont pas précisés. En effet, dans la façon dont les humains agissent, il y a énormément d'implicites, de "connaissances métiers" jamais rappelées, etc. Or un ordinateur ne fonctionne pas avec des implicites : tout doit être clairement explicité. Cette explicitation, souvent absente du cahier des charges, risque d'être effectuée par le développeur, qui n'a pas les compétences métiers adéquates, ce qui mènera à un produit final qui ne satisfera pas le client.
La charge est difficile à estimer: Même pour des développeurs expérimentés, estimer la charge (le travail) que va demander un projet reste un problème extrèmement difficile. Aussi, juger de la faisabilité d'un projet, le chiffrer sont des tâches compliquées, et de mauvaises décisions peuvent s'avérer catastrophiques.
Valider une solution n'est pas évidente: Les situations dans lesquels un logiciel va être utilisé sont extrèmement nombreuses, et avoir la garantie que le code développé fournira la bonne solution dans tous les cas est un problème quasi insoluble. Réduire au minimum les risques d'erreur est donc un problème très compliqué.
Un projet n'est que rarement "fini": Quand un constructeur vous livre une voiture, le travail sur la voiture en question est terminé pour lui. Il pourra éventuellement travailler sur une nouvelle version du modèle, mais ce sera en fait pour lui un nouveau projet, concernant d'autres clients. Ce n'est en général pas le cas avec un logiciel. À peine le logiciel a-t-il été livré qu'une nouvelle version améliorant et/ou corrigeant la précédente est déjà en route, version qui sera entre autres destinée à remplacer celles déjà livrées. Il y a donc une importance forte de l'historique sur un projet (lorque cela oblige à travailler avec du code ancien difficilement modifiable, on parle de code legacy).

Aperçu de quelques grandes méthodes de développement

Le modèle en tunnel

Hyperbole utilisée pour caractériser les développements ne suivant aucune méthodologie.

Le modèle en cascade

Ce modèle est le premier à avoir identifié les phases suivantes d'un développement :

Spécification : phase de recensement des besoins
Conception préliminaire : définition de l'architecture générale du logiciel
Conception détaillée : définition de la structure de chaque module du logiciel
Implantation : codage à proprement parler

Le modèle en V

Le modèle en V reprend le modèle en cascade, mais introduit les tests, avec plusieurs niveaux de tests. Chaque phase du modèle en V permet de définir les tests d'un niveau, mais les tests ne seront exécutés qu'à la fin, une fois le code produit.

Le modèle en spirale ou modèle itératif

Ce type de modèle repart du modèle en cascade, enrichi avec une phase de validation mais, au lieu d'effectuer chacune des phases pour tout le logiciel, on les exécute fonctionnalité par fonctionnalité, en ajoutant progressivement les nouvelles fonctionnalités au code déjà développé.

Le développement agile

Le développement agile fait suite au Manifeste Agile publié en 2001. Il prône un développement itératif en insistant sur la qualité du produit, la réactivité aux changements, et des relations humaines saines, suite aux dérives engendrées par une application trop stricte de méthodes toujours plus lourdes.