Tout au long du cycle de vie du projet, les utilisateurs doivent être en mesure de tester tous les résultats intermédiaires. #
Les clients sont invités à définir le plus précisément possible leurs besoins tout au long des phases de définition et de conception. C’est un défi pour deux raisons. Pour commencer, les consommateurs ont une compréhension limitée du potentiel et des impossibilités de la technologie de l’information. Ils n’ont aucune idée de ce qui est ou devrait être faisable, et ils ne savent pas non plus ce qu’ils devraient ou ne devraient pas désirer. Deuxièmement, les consommateurs manquent souvent d’une compréhension approfondie de leurs propres processus commerciaux.
De nombreuses initiatives informatiques incluent l’informatisation des processus commerciaux actuels d’une organisation. Même si les consommateurs ont travaillé avec des processus pendant une longue période, ils n’ont souvent pas la capacité de concevoir leurs propres processus commerciaux. Ils peuvent bien fonctionner à leur manière, mais ne peuvent pas spécifier de quelle manière il s’agit. Une définition exacte du processus est requise avant de développer un logiciel qui pilotera l’informatisation. La complexité des clients augmente car ils doivent expliquer les procédures en vigueur.
Critères de détermination #
Souvent, la liste des critères produite lors de la phase de définition est incomplète. Les programmeurs créent des logiciels conformément à cette liste partielle pendant la phase de mise en œuvre. Lorsque les consommateurs rencontrent des versions bêta d’un nouveau logiciel, des besoins supplémentaires deviennent évidents. «Ça a l’air sympa, mais pourriez-vous peut-être le réparer pour que je n’aie pas à entrer constamment mon mot de passe?» Les programmeurs se plaignent souvent que les clients ne sont pas sûrs de ce qu’ils veulent. Les clients affirment qu’en tant qu’experts, les développeurs de logiciels auraient dû identifier ce que les clients veulent plus tôt dans le processus.
Une conception fonctionnelle complète a été créée pour un projet logiciel qui comprenait le traitement automatisé des demandes pour un service Web. De nombreux besoins des clients ont été compilés. Après avoir ajouté quelques conceptions d’écran et schémas de flux, les programmeurs ont pu commencer.
Gestion des clients et des contraintes #
Peut-être en raison des contraintes de temps sévères du projet ou peut-être en raison de l’organisation plutôt chaotique du client, les concepteurs avaient oublié de se composer d’un élément essentiel : l’administration manuelle. Le programme a traité les demandes. Comme les demandes devaient être traitées automatiquement, les programmeurs ont estimé qu’aucune administration humaine ne serait nécessaire. Ce critère a également été omis de la conception fonctionnelle.
Lorsque le programme a été fourni pour les tests, le client a découvert que de nombreuses applications présentaient des exceptions. Ces demandes ne peuvent pas être traitées automatiquement et doivent être traitées manuellement. Cependant, le programme fonctionnait entièrement automatiquement.
Les gestion de projet cascade nécessite de tester le résultat réel du projet à la fin de la phase de mise en œuvre. C’est tard stade de développement . Entre la phase de définition, la phase de conception et la phase de mise en œuvre, des mois voire plus d’un an peuvent s’écouler. Si des défauts de conception sont découverts à un stade avancé du projet, il peut être coûteux, voire impossible, de modifier le programme sans démarrer complètement un nouveau projet. Étant donné qu’il est pratiquement impossible de définir tous les critères à l’avance, une approche de travail permettant de tester les résultats (intermédiaires) est souhaitable.
Analyse des exigences #
Lors de la comparaison d’un certain nombre d’éditeurs de logiciels potentiels, un client s’est renseigné sur les possibilités. Une partie était hésitante et a remis en question la faisabilité de bon nombre des demandes du client. La partie adverse était représentée par un agent commercial agressif.
Lorsqu’un client s’enquérait de la faisabilité d’une demande spécifique, le commercial appelait ses codeurs. «Pouvons-nous créer une fonction qui effectue X?» Le programmeur, qui pensait principalement en termes techniques, a déclaré que tout était théoriquement concevable. Ni le programmeur ni le vendeur n’étaient préoccupés par gestion de projet faisabilité (p. ex. temps, argent, complexité et risque).
L’excitation du représentant des ventes a surpassé le comportement retenu de l’autre partie. Le client a choisi l’offre agressive du commercial. Le projet nouvellement acquis a ensuite été confié à un chef de projet et à une équipe de programmeurs.
Après un certain temps, il est devenu évident que le projet n’était pas à la hauteur des attentes du client. Cela était en partie dû au fait que les procédures étaient beaucoup plus complexes pour le client qu’elles n’y paraissaient au départ. Lors d’un échange houleux entre les deux parties, le client a déclaré que le vendeur « avait déclaré que la fonctionnalité X ne poserait pas de problème ».
