C’est la question à cent mille balles, comme disent nos amis Français : combien cela coûtera-t-il à développer cette application ? Malheureusement, la réponse n’est jamais simple et jamais unique car il y a mille et un facteurs qui en feront varier le coût de développement… dont la méthodologie de travail et la notoriété de l’entreprise soumissionnaire ne sont pas les moindres !
Le client saisit-il bien toutes les subtilités et les implications sur le plan du développement logiciel de ses objectifs d’affaires ? Veut-il une couche importante d’Intelligence d’Affaires ? Quelle est la nature et l’état de son environnement TI actuel ? Y a-t-il conflit en perspective ou incompatibilité entre l’application souhaitée et les systèmes / applications en place ? Faudra-t-il développer d’autres applications ou mettre en place d’autres systèmes afin d’arrimer cette application ? Dans quelle mesure, cette application est-elle critique à l’atteinte des objectifs d’affaires de l’entreprise du client et si c’est le cas, devrons-nous remplacer certains systèmes en place ou en implanter d’autres ? Devrons-nous optimiser certains processus des applications en place afin d’harmoniser l’interaction avec l’application développée ? Quelle méthodologie le développeur utilisera-t-il ? Quelle est l’architecture retenue ?
S’agit-il d’un billet sur la Gestion de Projets ? Loin de là. Et Dieu sait que la gestion de Projets a fait couler beaucoup d’encre en TI depuis une décennie et que cela mériterait toute une série de billets en soi… que nous ferons peut-être en 2010. Mais pour les besoins de ce billet, nous prendrons pour acquis que tous les développeurs appliquent de bonne pratique en matière de Gestion de Projets.
La liste des facteurs et possibilités ayant un impact sur le coût de développement pourrait s’allonger pendant longtemps; cependant, j’ai pris le parti de faire le tour de la question, ne serait-ce que sommairement et ce, pour le bénéfice de tous ces clients qui nous font confiance malgré le doute qui subsiste en leur esprit. Alors, quels sont les facteurs qui expliquent / justifient les variations de coût de développement d’une application TI ?
Variations libres sur un thème de Développement d’une application TI
Taille de l’équipe de développement
Bien sûr qu’il y a un rapport assez direct entre le nombre de jours/homme et le coût de développement d’une application mais disons que c’est un peu plus subtil que cela.
Le rapport entre le coût de développement et le nombre de ressources utilisées n’est pas directement proportionnel mais obéit plutôt à une courbe en palier; en ce sens, que deux ressources qui font 25 heures de développement produiront moins qu’une ressource qui fait 50 heures de développement et ce, parce qu’en 50 heures, la ressource aura eu le temps de plonger profondément dans le code et de bien s’en imprégner jusqu’à entrevoir, puis découvrir et saisir les subtilités et défis de programmation de l’application souhaitée, ce qui ne sera pas nécessairement le cas des deux ressources à 25 heures !!!
Un autre phénomène favorise la création du premier palier, soit lorsque le nombre de développeurs sera suffisamment grand qu’il requerra un niveau de Gestionnaires; ce qui augmentera les coûts mais n’augmentera pas d’autant la productivité, enfin, pas proportionnellement.
Technologie utilisée (C# / Flex / Java / Ruby-on-Rails / Python)
Qu’y a-t-il à dire, vous êtes Open Source ou pas ! Vous ne jurez que par Microsoft, c’est tout aussi bon; à vous de voir ! Chaque technologie a son champ d’application privilégié et ses avantages. Que ce soit une technologie plus jeune demandera habituellement une expertise particulière et augmentera le coût de développement et d’entrerien.
Documentation
Il faut documenter, on ne saurait assez le dire et le redire ! Et malgré cela, on trouve encore nombre d’applications non-documentées en entreprise et dont l’entretien sera extrêmement coûteux. Pourquoi ? Parce qu’il faudra deviner. Et oui, voilà pourquoi la documentation est si importante; une application non documentée peut coûter de 2 à 3 fois plus cher à entretenir. Cela prend du temps mais il est impératif de bien documenter à deux niveaux et au moins sur les items ci-dessus :
– technologie
- structure de données
- architecture
- OS vs Code
- relations
– usager
- administrateurs
- droits et privilèges
- intrants /extrants (I/O)
- fonctions et processus
Méthodologie de Développement
Outre l’envergure et le calibre de l’entreprise (Agile, CMMI, etc.) de développement logiciel, la qualité du personnel compte tout autant car elle déterminera sa productivité et le coût de développement.
– productivité de l’équipe de développement
- compétences
- expérience
- motivation
- contrat de travail (syndicalisation)
Contrainte de Sécurité
Cet aspect est aussi souvent négligé mais il est extrêmement critique à la survie de l’entreprise en cas de désastre. Ainsi, il faut du temps pour identifier les exigences minimales au bon fonctionnement de l’entreprise et prévoir les procédures correspondantes.
– procédures de récupération en cas de désastre
- exigences minimales de récupération des données
- exigences minimales de récupération des systèmes
- alertes, consignes et procédures de réinstallation
Architecture utilisée
Cette décision, ce choix technologique est on ne peut plus critique et nous reviendrons sur le sujet dans un autre billet mais sommairement; voici quelques critères qui auront un impact sur le coût de développement de votre application :
- protocole de communication
- design technologique
- nb. de couches utilisées
- application orientée service ou orientée objet
Erreurs de conception technologique
Il y a peu à dire sur ce plan. Choisissez des fournisseurs TI qui ont l’expertise du type d’applications que vous recherchez, une méthodologie éprouvée, l’expérience de votre secteur d’activités et la capacité de production requise. Et rappelez-vous, si le deal est trop bon, vous en paierez le véritable prix… plus tard.
Bonne compréhension des besoins
Cet aspect fait souvent défaut aux projets qui sont confiés à des ressources « off-shore », quand il ne se fait pas une lacune grave, parce que ces dernières ne partagent pas la même culture et ce faisant, peuvent difficilement comprendre la réalité d’affaires des entreprises d’ici.
CONCLUSION SUR LE COÛT DE DÉVELOPPEMENT
Y a-t-il une règle d’or au Développement logiciel ? S’il y en avait une, tout le monde le saurait… et l’appliquerait ! Cependant, tout le monde s’entend pour dire que la méthodologie de développement « Agile » se veut une garantie de productivité et que le modèle CMMI est la norme ISO 9001 du Développement logiciel. Nous le savons, puisque chez Analystik, nous avons implanté la méthodologie Agile et nous venons tout juste de terminer un programme de certification CMMI, niveau 3.
On peut toutefois aussi tirer certaines conclusions basées sur des années d’expérience pratique et de cas réels. En toute humilité, voici donc ma règle d’or :
Déterminez la taille de la plus petite équipe fonctionnelle (capable de produire des livrables pour approbation client), reproduisez cette équipe en autant de copies requises par l’ampleur du projet, décloisonnez votre espace de travail afin de favoriser la bonne communication entre vos équipes. Ajoutez un Gestionnaire de Projets à toutes les 3-4 équipes.
Bonne semaine,
Voilà donc un bon article, bien passionnant. J’ai beaucoup aimé et n’hésiterai pas à le recommander, c’est pas mal du tout ! Elsa Mondriet / june.fr