Le projet Skool est présentement en développement. Il consiste à mettre sur pied différents types de formations spécialisées en affaires électroniques pour favoriser le développement et l'adoption des TIC dans vos organisations.
Osmose Interactif inc. /

Blogue

Suivez-nous sur les médias sociaux

Twitter Facebook YouTube

Un exemple qui démontre pourquoi c’est difficile d’estimer l’échéancier et le budget de développement d’un logiciel

Ceux qui n’oeuvrent pas dans l’industrie du développement logiciel ont parfois de la difficulté à comprendre pourquoi développer un logiciel prend toujours plus de temps que prévu. La raison est qu’il y a toujours des imprévus. Contrairement à la construction d’une maison où les étapes et spécifications sont relativement faciles à estimer, le développement logiciel est un acte de création.

J’ai pour vous un très bon exemple qui m’est arrivé il y a quelques mois pendant le développement de Proximag.

Proximag permet de gérer les commandes d’un réseau agroalimentaire de vente en circuit court. Il permet au producteur de savoir la quantité à apporter aux points de chute et permet aux responsables de points de chute de savoir quels produits vont dans quelles commandes. Il comprends aussi un site web où les clients peuvent passer leur commandes et des rappels par courriel quand c’est le temps de commander ou de venir chercher leur commande. Finalement, l’application produit un rapport qui dit quels montants doivent être remis aux producteurs par chacun des points de chute selon les commissions établies.

Maintenant, voici un exemple de fonction qui semble simple à première vue mais qui est très complexe en réalité.

Certains réseaux vont facturer les taxes sur certains produits. Mais d’autres non. Par conséquent, il faut que le réseau puisse configurer s’il utilise les taxes ou non. Et ensuite le logiciel doit prendre en considération si les taxes sont activées ou non.

Je vous imagine déjà dire « C’est simple, t’as juste à faire une valeur vrai/faux et si les taxes sont activées, tu affiches les taxes dans la commande et le rapport des ventes ». Simple, n’est-ce pas?

Vous oubliez un petit détail. Peut-être qu’un réseau n’utilise pas les taxes aujourd’hui mais que dans 6 mois, ils vont devoir taxer certains produits. Il faut donc que les commandes puissent utiliser ou non les taxes selon si les taxes étaient actives au moment de la création de cette commande.

Cette partie est relativement simple. Vous ajoutez un champ dans la table des commandes qui dit si oui ou non les taxes étaient active au moment de cette commande.

Mais le rapport des ventes est plus compliqué. Il faut que vous repassiez les commandes qui sont incluses dans le rapport afin de déterminer si une de celles-ci utilise les taxes. Si ce n’est pas le cas, vous n’avez pas besoin d’afficher les taxes dans le rapport, sinon vous devez afficher les taxes.

Et ce n’est que la pointe de l’Iceberg. Il faut également prendre en considération les changements aux taux de taxes, la taxation de certains produits mais pas d’autres et ainsi de suite.

C’est un excellent exemple qui démontre bien que certaines fonctions sont beaucoup plus compliquée que prévues. C’est ce qui fait que c’est extrèmement difficile d’estimer les coûts et les échéanciers de développement d’un logiciel. La cible continue toujours d’avancer au fur et à mesure que le développement progresse parce que l’équipe découvre des aspects du logiciel qui requiert du travail supplémentaire afin d’atteindre un niveau de qualité et de robustesse acceptable.

Publié le par André-F. Landry | Posted in Processus de développement logiciel | Commentaires fermés

Catégories