GES800 Module 3 - Gestion de Projet

Le processus de comprendre les besoins d'un projet et d'identifier les solutions possibles pour y répondre.

La stratégie de réponse aux besoins implique la création d'une liste d'options, l'analyse de ces options et la sélection de la meilleure pour répondre aux besoins.

La stratégie de réponse aux besoins aide à garantir que toutes les parties prenantes du projet comprennent les besoins et la solution choisie.

Un plan détaillé de réalisation d'un projet qui décrit les phases et les étapes clés du développement.

L'approche de développement sert de sommaire de l'échéancier du projet, décrivant les grandes étapes et phases de développement.

Décrit la façon dont une solution sera déployée, en tenant compte des différentes options possibles: déploiement complet, par module, par département ou par phase.

Un ensemble de phases et d'étapes définies qui guident le développement et la livraison d'un projet, permettant un suivi et un contrôle efficaces.

Un cycle de vie du projet où chaque phase est complétée avant de passer à la suivante, avec un processus de validation à chaque étape.

L'étape où les besoins du projet sont définis et documentés en détail.

L'étape où le plan du projet, y compris les coûts et les échéanciers, est défini et validé.

L'étape où les travaux du projet sont exécutés et livrés.

Permet d'améliorer la vitesse de développement, la qualité, le suivi, les relations client, de minimiser les charges indirectes et de réduire l'exposition au risque.

La connaissance et la stabilité des besoins, la connaissance de l'architecture et de la technologie, la robustesse désirée du produit, la complexité de la réalisation, la possibilité de changements, le besoin de démontrer le progrès, les risques du projet et la possibilité d'améliorations futures.

Une méthode de développement logiciel où chaque phase (analyse des besoins, conception de haut niveau, conception détaillée, développement, test, livraison) est complétée de manière séquentielle, sans retour en arrière.

Le modèle en cascade est le plus simple à comprendre et à contrôler, permettant de suivre l'avancement du projet.

Le modèle en cascade ne permet pas de voir les problèmes majeurs avant la fin du projet et rend les changements difficiles.

Le modèle en cascade est idéal pour de grands projets avec des besoins stables et une technologie éprouvée.

Le modèle en cascade est adapté pour créer une nouvelle version d'un produit existant ou pour migrer un produit vers une nouvelle plateforme.

Le modèle en cascade est adapté lorsque la qualité est prioritaire par rapport au coût et aux délais.

Le modèle en cascade est utile lorsque l'équipe est inexpérimentée ou manque de compétences techniques.

Une méthode de développement où le projet est divisé en phases (lots) et chaque phase est livrée séparément.

Le modèle en spirale est une méthode de développement logiciel qui combine les avantages de différents modèles. Il est conçu pour gérer les risques en divisant le projet en cycles de développement successifs.

Le modèle en spirale est particulièrement adapté lorsque les besoins du projet sont complexes et mal définis, nécessitant une gestion des risques.

Le modèle en spirale implique une planification minutieuse et une compréhension approfondie des risques. Cela peut exiger une expertise et une expérience considérables.

La méthode de développement incrémental consiste à développer un produit par étapes successives, en livrant des versions fonctionnelles avec des fonctionnalités ajoutées à chaque itération.

Le développement incrémental présente plusieurs avantages, tels que la réduction des risques en divisant le projet en parties plus petites, la possibilité d'obtenir rapidement un retour d'information et la flexibilité pour adapter le produit aux changements.

Le modèle évolutif permet de livrer des fonctionnalités progressivement, même si toutes les exigences ne sont pas encore définies. Il permet aux utilisateurs de bénéficier des premières livraisons et de fournir des commentaires pour affiner les besoins.

Le modèle évolutif est idéal lorsque les besoins ne sont pas totalement clairs au début, mais que l'on comprend bien une partie spécifique des besoins. Il est également utilisé pour les solutions achetées, car il permet d'adapter progressivement le produit acheté.

Ce sont des principes et des pratiques de développement qui mettent l'accent sur la collaboration, la flexibilité et la livraison rapide de valeur.

Les valeurs fondamentales de l'agilité mettent l'accent sur les personnes plutôt que les processus, sur le logiciel fonctionnel plutôt que la documentation, sur la collaboration avec les clients plutôt que les contrats, et sur la réaction au changement plutôt que le suivi d'un plan.

Les 12 principes agiles guident l'application des valeurs de l'agilité dans la pratique.

Le premier principe de l'agilité met l'accent sur la satisfaction du client en livrant constamment des logiciels fonctionnels.

Le deuxième principe de l'agilité exalte le changement comme une opportunité pour s'adapter aux besoins du client.

Le troisième principe de l'agilité encourage les livraisons fréquentes de logiciels fonctionnels, favorisant les cycles courts de développement.

Le modèle de livraison par étapes implique la réalisation de sorties de produits progressives et indépendantes. Chaque sortie est livrée au fur et à mesure qu'elle est terminée et contient des fonctionnalités spécifiques. Les sorties successives apportent de nouvelles fonctionnalités, améliorant ainsi le produit progressivement.

Ce modèle est adapté aux projets complexes dont les besoins sont connus, stables et compris. Il est idéal pour les projets qui peuvent être découpés en morceaux indépendants, ce qui permet une livraison plus rapide des premiers résultats. Le modèle par étapes permet également de gérer les changements avec plus de flexibilité.

La gestion de projet dans le modèle par étapes est une tâche complexe. Les gestionnaires de projet doivent être capables de gérer de multiples équipes qui travaillent en parallèle. La coordination entre les équipes est essentielle pour assurer la cohérence du produit final. Des challenges supplémentaires sont liés au testing et à l'intégration des différentes sorties.

La méthode "Design to Schedule" consiste à planifier un projet en fonction d'un calendrier défini. Les fonctionnalités sont priorisées et développées par ordre d'importance. Ce modèle permet de fournir un produit minimal viable à une date précise.

La méthode "Design to Schedule" est un outil puissant pour les projets où les délais sont critiques. Cependant, elle présente quelques inconvénients. Si l'ensemble du produit n'est pas réalisé, le temps consacré à la planification (spécification, architecture et conception) est perdu. Il est également difficile de garantir que les fonctions les plus importantes seront développées si les priorités ne sont pas soigneusement définies.

Le modèle "Design to Schedule" est particulièrement pertinent lorsque des contraintes de temps et d'argent sont primordiales. Idéal pour les projets incertains, il permet de livrer les fonctionnalités les plus importantes en premier, réduisant ainsi les risques. La planification des itérations doit être minutieuse pour maximiser l'impact des premières livraisons.

Ce modèle offre une bonne stratégie pour garantir la sortie d'un produit à une date précise. Il est particulièrement utile pour des parties du projet non critiques, permettant de les réaliser en parallèle sans affecter le calendrier global du projet.

La méthode "Design to Schedule" peut entraîner une perte de temps si le projet n'est pas mené à terme. La planification excessive peut se révéler inutile si les priorités ne sont pas correctement définies, car il est alors possible de ne pas développer des fonctions importantes.