Cycle de vie d’un projet

Cycle de vie d’un projet

Un projet revient à faire quelque chose qui n’existe pas encore, à concrétiser une intention, que l’on doit inventer, réaliser comme si on savait le faire. L’erreur et le tâtonnement sont à exclure en raison des coûts qu’ils suscitent. Ainsi, un projet repose sur une méthode de travail et d’organisation spécifique. Le coût conditionne en partie la bonne marche d’un projet. Tout chef de projet le sait, plus les modifications sont tardives, plus le coût est élevé. Il s’agit donc de savoir au plus tôt ce que l’on veut, comment on le veut pour quand on le veut pour réduire ou éviter toutes dépenses onéreuses. Il s’agit alors d’imbriquer concrètement le -quoi faire- , le -comment faire- dans une dimension temporelle scrupuleusement gérée. L’Afitep-Afnor (X 50-105) définit le projet comme :  » une démarche spécifique qui permet de structurer méthodiquement et progressivement une réalité à venir…; un projet est défini et mis en oeuvre pour répondre au besoin d’un client (…) et implique un objectif et des besoins à entreprendre avec des ressources données ». Gérer un projet revient donc en : – une prise en compte maximale d’un ensemble de paramètres hétérogènes, connus, méconnus voire inconnus (les fameux impondérables) qui ne s’allient pas forcément ensemble et avec lesquels il faut compter et généralement faire avec. Car investir dans une définition structurée et détaillée au début implique une dépense moindre pour les modifications potentielles. Ces paramètres conjuguent : – le quoi faire (le ou les objectifs escomptés), le temps, les moyens disponibles (humains, matériels, financiers…) et nécessaires pour obtenir le résultat recherché.

Le principe de modèle en cascade est de découper le projet en phases distinctes sur le principe du non-retour. Lorsque une phase est achevée, son résultat sert de point d’entrée à la phase suivante. Ce modèle, développé dans les années 1970 par W. ROYCE a servi pendant des années de modèle de référence.L’avantage de ce modèle est de proposer au fur et à mesure une démarche de réduction des risques, en minimisant au fur et à mesure l’impact des incertitudes. L’impact d’une incertitude dans la phase de développement étant plus faible que l’impact d’une incertitude dans les phases de Conception ou de Spécifications, plus le projet avance, plus les risques diminuent. Néanmoins, cette démarche, basée sur un processus de contrôle qualité en fin de chaque phase, a l’inconvénient d’exclure l’utilisateur dès la phase de conception car trop technique. Le contrôle qualité significatif survient alors en fin de projet, et, à ce moment, si l’utilisateur s’aperçoit que le système ne répond pas correctement aux besoins exprimés, il peut être trop tard. Le modèle en cascade est adapté aux projets de durée inférieure à l’année, sur des projets à forte composante réglementaire, comme les projets de back-office. Pour de grands systèmes, cette démarche présente également l’inconvénient de ne pas permettre de mener, en parallèle, le développement de modules d’applications.

L’assurance qualité est le processus qui permet de vérifier en continu la qualité du produit à fur et à mesure de sa fabrication. Le modèle en V met l’accent sur ce processus. Il confronte les différents niveaux de test avec les phases de projet de même niveau. Ceci permet à chaque étape de définir non seulement les fonctions, mais également les critères de validation. La cohérence entre les deux éléments permet de vérifier en continu que le projet progresse vers un produit répondant aux besoins initiauxCe modèle est adapté aux projets de taille et de complexité moyenne. C’est une amélioration du modèle en cascade traditionnel. Il permet d’identifier et d’anticiper très tôt les éventuelles évolutions des besoins. C’est aussi un moyen de vérifier de la maturité des utilisateurs, car s’il en était autrement, ils se trouveraient dans l’incapacité de fournir des test de recettes dès la phase de spécification. C’est un modèle avantageux pour une maîtrise d’œuvre, rassurant pour une maîtrise d’ouvrage qui doit cependant s’engager significativement. 3. La planification dans le projet La planification d’un projet de système d’information consiste à prévoir l’ordonnancement des opérations sur le plan des délais et sur le plan de l’utilisation des ressources. Il convient dans un premier temps de mesurer le « poids » d’un projet en terme de charges et donc de durée ; dans un second temps, il s’agit d’optimiser la succession des tâches et aboutir ainsi à un calendrier des opérations. Enfin, dans le développement du projet, il faut effectuer régulièrement des contrôles de suivi et éventuellement apporter des modifications au calendrier.