IT Project Management

Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux alentours de 1970 par Winston W. Royce. Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que s'ils sont jugés satisfaisants. Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement sur la base qu'une étape ne remet en cause que l'étape précédente, ce qui est dans la pratique s'avère insuffisant.

Dans les entreprises, tous les projets suivent une méthode de conduite de projet. La plus connue est la Démarche de cycle en V. De manière analogue à d'autres branches de l'ingénierie, la production du logiciel suit une série d'étapes de la démarche de cycle de V. À chacune de ces étapes sont associés des outils et des méthodes propres à atteindre les objectifs visés. De même, le cycle en V est une méthode d'organisation très connue qui tire ses origines de l'industrie lourde, à propos de la conception du système SAGE (Semi-Automatic Ground Environment), un dispositif militaire de surveillance et de défense aérienne. Adaptée à l'informatique dans les années 80 et imaginée pour remplacer le cycle en cascade, cette méthodologie est toujours utilisée dans le développement des projets informatiques, même si plusieurs dérivées existent. En outre, le cycle en V permet de définir un cadre mixte composé d'offshore « loin des côtes » et de local. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet.

La cycle en V montre que la réalisation d'une application peut se découper en trois (03) grandes parties : La phase de conception, la phase de réalisation (codage) et la phase de validation. Les phases de conception et de validation se découpent en plusieurs parties. Chaque étape ne peut être réalisée qu'une fois que l'étape précédente est terminée, ce qui diminue les prises de risque sur le projet.

Ce qui est bien visible sur le diagramme du cycle, c'est que chaque étape de conception possède son alter ego de validation. Il devient alors assez aisé de valider un projet, car le référentiel de test est connu très précisément.

Par ailleurs, la méthode de projet sert à conduire le projet IT à son terme en respectant les impératifs de qualité, coût et délai est le découpage du projet en phases. Chaque phase, comme on a signalé précédemment, est accompagnée d'une fin d'étape destinée à formaliser la validation de la phase écoulée avant de passer à la phase suivante.

De plus, tous les projets IT suivent une méthode de conduite de projet. Ils s'inscrivent dans les bonnes pratiques d'une entreprise. Pour mener à bien, la réalisation d'un projet informatique d'une certaine taille, le chef de projet doit découper le projet en plusieurs phases, et prévoir un environnement de travail et d'exécution par phase.

Proposé par B. Boehm en 1988, ce modèle de cycle de vie tient compte de la possibilité de réévaluer les risques en cours de développement, il emprunte au prototypage incrémental mais lui adjoint une dimension relevant de la prise de décision managériale et non purement technique. Il couvre l'ensemble du cycle de développement d'un produit.

Autrement dit, c'est un modèle qui repose sur le fait qu'il y a une relation contractuelle entre le fournisseur et le client. Plusieurs cycles sont effectués. Chaque cycle donne lieu à une contractualisation s'appuyant sur les besoins exprimés lors du cycle précédent. Un cycle est composé des étapes suivantes (voir figure 10):

• Analyse du risque ;

• Développement d'un prototype ;

• Simulation et essais du prototype ;

• Détermination des besoins (à des mailles différentes selon le cycle), à partir des résultats des essais ;

• Validation des besoins par un comité de pilotage ;

• Planification du cycle suivant.

Le dernier cycle permet de développer la version finale et implémenter le logiciel.

Depuis plusieurs années, la gestion des projets informatiques repose sur la méthode agile. En substance, la méthode agile consiste en des méthodes de gestion et d'évolution de projet qui reposent sur le découpage du projet sous forme de sprint. De plus, elle se base sur la notion de communauté de projet dans laquelle les développeurs et les utilisateurs sont présents en permanence pour exprimer ou répondre à une question liée au projet.

Par ailleurs, cette méthode a aujourd'hui largement fait ses preuves et elle fonctionne dans de nombreux projets (création de site internet, développement d'une application, d'un logiciel spécifique ou d'une couche applicative supplémentaire, etc.). En revanche, elle nécessite une adaptation / une révision des contrats informatiques qui dans la majorité des cas ne prennent pas en compte les effets engendrés par l'utilisation de cette méthode.

Néanmoins, l'utilisation de la méthode agile a également une incidence sur la forme du calendrier prévisionnel transmis au client (MOA). Le calendrier doit désormais s'appuyer sur les étapes de sprint et plus sur les étapes mentionnées plus haut (expression des besoins, phase de conception puis intégration...).

En conclusion, la méthode agile est parfaitement compatible avec la réussite d'un projet informatique. Il suffit pour le client et le prestataire de réviser et personnaliser le contrat informatique qui les unit.

Dans ce but, les méthodes agiles prônent quatre (4) valeurs fondamentales :

1. L'équipe «Personnes et interaction plutôt que processus et outils». La communication est une notion fondamentale.

2. L'application «Logiciel fonctionnel plutôt que documentation complète». Il est vital que l'application fonctionne.

3. La collaboration «Collaboration avec le client (MOA) plutôt que négociation de contrat». Le client doit être impliqué dans le développement.

4. L'acceptation du changement «Réagir au changement plutôt que suivre un plan». La planification initiale et la structure du logiciel doivent être flexibles (évolution de la demande du client)

Finalement, on peut dire que le choix des modèles se fait selon certains critères tel que la nature du projet, sa taille, la nature du client et les compétences de l'équipe.