La technique de la cascade est divisée en étapes. Les chefs de projet doivent inclure des estimations du temps (et donc de l’argent) requis pour chaque étape de leurs plans de projet. Nous avons précédemment établi que les estimations de temps sont intrinsèquement problématiques pour tout projet, d’autant plus lorsqu’elles doivent être fixées tôt dans la vie du projet. Ce n’est tout simplement pas faisable pour les projets logiciels. Envisagez la possibilité qu’une liste qualitativement acceptable de capacités soit compilée pendant la phase de définition. En principe, cela devrait permettre à l’équipe du projet de donner une estimation réaliste du temps nécessaire pour développer chaque fonctionnalité. Cependant, en réalité, il y a trop d’incertitudes pour fournir une approximation juste :
Cependant, en réalité, il y a trop d’incertitudes pour fournir une approximation juste :
- Souvent, après le développement d’une fonctionnalité, il s’avère que le client n’en a pas besoin. Ainsi, les heures passées à développer cette fonctionnalité peuvent être considérées comme vaines.
- Tout au long du projet, les exigences peuvent changer.
- La capacité doit-elle être fournie à un coût élevé ou à faible coût? Il existe de nombreuses techniques de mise en œuvre et de réalisation.
- Comment la fonctionnalité sera-t-elle conçue techniquement? La conception influence grandement le temps nécessaire à sa création.
- Dans quelle mesure le fonctionnement doit-il être d’un niveau élevé ? Par exemple, une application Web doit-elle être entièrement accessible à tout moment, ou doit-elle être autorisée à être indisponible quelques heures par an ?
- Le temps nécessaire pour détecter et corriger les problèmes logiciels varie de quelques minutes à plusieurs semaines.
- Combien de temps faudra-t-il pour que le nouveau logiciel s’installe et s’intègre aux systèmes actuels du client?
- Le manque d’informations sur les solutions potentielles affecte davantage les estimations de temps. De plus, il est difficile d’estimer le temps nécessaire pour acquérir l’expertise requise.
La liste ci-dessus démontre qu’une variété de variables peuvent influencer la durée nécessaire pour développer un nouveau logiciel. Les estimations du temps nécessaire pour développer une fonctionnalité au démarrage d’un projet sont souvent quatre fois trop faibles ou quatre fois trop élevées. Cela implique que le temps requis peut être quatre fois plus ou quatre fois moins qu’une estimation erronée. Au fur et à mesure que le projet se développe, ces estimations deviennent plus précises. Après avoir terminé la conception fonctionnelle, la marge est réduite à 25 % trop ou trop peu. Ce n’est que lorsque la caractéristique a été développée qu’il est possible de donner une estimation avec un degré de confiance élevé.
Risques logiciels #
Logiciel de gestion de projet ne sera jamais totalement exempt d’erreurs. Même pour les programmes bien connus qui sont largement utilisés (par exemple, Word, Excel, Explorer, OS X, PHP et Flash), Internet a des listes de défauts connus. Régulièrement, de nouvelles versions sont mises à disposition sur le marché pour corriger des bogues logiciels. Les clients exigent parfois que le logiciel soit exempt d’erreurs. En réalité, cependant, un tel objectif rendrait la réalisation d’un logiciel irréalisable. De plus, les défauts logiciels ne sont souvent pas inhérents au programme.
Flash a été utilisé pour créer un jeu pédagogique. Le client a accepté de récupérer le jeu sous forme de fichier et de l’installer sur son propre serveur. Au cours du projet, le client a demandé qu’une fonction de score élevé soit ajoutée au jeu pour améliorer la compétitivité des joueurs. Cela nécessiterait du code de script PHP. Les développeurs du jeu ont développé et testé le code du script sur leur propre serveur sous Linux. C’était réussi. Le client a reçu le code du jeu et du script. Cependant, le client a utilisé un serveur Windows et, pour une raison quelconque, le script a cessé de fonctionner correctement. Les meilleures notes n’ont pas été retenues. Le programmeur a finalement besoin d’une semaine pour résoudre le problème. Il s’avère que PHP et Windows ne fonctionnent pas toujours bien ensemble. Le script dans son intégralité ne comportait aucune erreur ! Il a réussi à le faire fonctionner à l’aide d’un hack, et tout le monde était content, mais qui devrait payer pour cette semaine de travail supplémentaire ?
Un autre projet de développement de logiciels comprenait également la création d’applications pédagogiques. Le problème était que le logiciel fonctionnait très bien pour les développeurs mais pas pour le client. Après avoir épuisé toutes les autres possibilités, le programmeur a décidé de rendre visite au client. Il s’est avéré que le client utilisait une machine Pentium III du début des années 1990. La lenteur de l’ordinateur a contribué aux mauvaises performances du logiciel. De plus, les programmeurs ont essayé le logiciel sur un Pentium III, et cela a bien fonctionné. Un examen plus approfondi a montré que le PC du client fonctionnait lentement en raison d’une infection par un virus et un logiciel espion.
Gérer les incertitudes dans le développement de projet #
L’incertitude montrée par les exemples ci-dessus complique le processus de élaborer des plans de projet . De plus, cela complique les négociations entre les parties. Quelqu’un doit supporter les risques associés au travail supplémentaire qui doit être effectué. Si le paiement est effectué à l’heure, le client supporte tous les risques. Lorsqu’un prix fixe est convenu (comme c’est le cas pour les projets financés par des subventions), le développeur de logiciels assume le risque. Quand il y a plus de deux personnes impliquées, la situation devient plus complexe. Dans ce scénario, qui doit supporter le coût des heures supplémentaires travaillées sur le projet ?
Des différends surgissent souvent quant à savoir qui devrait être tenu responsable des retards. Souvent, la personne responsable est difficile à identifier. Il est tout à fait concevable qu’aucune des parties concernées ne soit à blâmer, puisque le « retard » a été causé par une estimation initiale erronée du nombre d’heures nécessaires. Les heures de projet excessives et la question de savoir qui doit payer sont des causes courantes de discorde dans l’industrie des technologies de l’information.
