Création de logiciel : comment évaluer sa conception et être plus productif ?

L'évaluation et le chiffrage de la conception d'un logiciel, notamment de sa taille, des efforts, des coûts et des durées impliqués, est souvent la source de discussions animées par les évaluateurs de logiciels. Les chefs de projet sont généralement responsables de cette activité.

Le développement de logiciels concentre plusieurs activités différentes qui font appel à des connaissances spécialisées, notamment en matière de recueil, d’analyse et de gestion des besoins ; conception de logiciels, codage et vérification et validation indépendantes (IV&V) ; mise en œuvre, déploiement, installation et mise en service. Chacune de ces activités est réalisée par une personne qualifiée, qui a recours à divers outils, plus ou moins complexes.

Voir tous les logiciels Editeurs de logiciels

Qu'est-ce que la productivité ? Définition

La productivité est définie comme le taux de production pour des inputs donnés. La productivité est exprimée en « tant d’unités de production par jour » ou « tant d’unités de production par heure ». La productivité est également définie comme le rapport entre les inputs et les outputs.

Dans le contexte de cet article, la productivité fait référence au taux de production d’une unité sortante à l’aide d’un ensemble d’intrants, pour une durée déterminée.

Problèmes dans l’évaluation de la taille d'un logiciel

Au sein de l’industrie informatique actuelle, on trouve plusieurs unités de mesure de la taille d’un logiciel. Ces unités incluent par exemple les points de fonction, points de cas d’utilisation (use case points - UCP), points d’objet, points de fonctionnalité, points d’Internet, points de test, l’analyse des points de fonction (FPA), les lignes de code (LOC), etc. Il n’existe pas de mesure consacrée permettant de convertir la taille d’un logiciel en l’une ou l’autre de ces unités.

Étrangement, dans le cadre de ces mesures, la taille du logiciel est ajustée (augmentée ou diminuée), en fonction de facteurs tels que la complexité. Pourtant, la taille est un caractère immuable. Par exemple, un kilo de fromage ne devient pas plus lourd ou plus légèr si la personne qui le pèse est plus ou moins expérimentée en matière de pesée, ou si la balance est mécanique ou électronique. Prenons un autre exemple : un kilomètre reste un kilomètre, que ce soit un jeune ou une personne âgée qui parcoure cette distance en marchant ou que la distance soit mesurée sur une autoroute ou dans une rue animée.

Cependant, la vitesse à laquelle les résultats sont obtenus change. Si l’on prend les exemples ci-dessus, la personne âgée parcourra certainement le kilomètre plus lentement que le jeune. On couvre par ailleurs plus rapidement un kilomètre sur l’autoroute qu’en ville.

En outre, il n’y a pas d’accord sur la façon de compter les LOC. Devrait-on compter des propositions logiques ou physiques ? Et comment traite-t-on la documentation en ligne ? Doit-elle être prise en compte ou non ?

Ce sont quelques-uns des principaux problèmes liés l'évaluation de la taille d'un logiciel

Préoccupations concernant la productivité

L’industrie de l’édition de logiciels est obsédée par la possibilité d’énoncer un taux de productivité unique, empirique, regroupant toutes les activités.

Des tentatives ont été réalisées pour que la productivité soit définie comme 10 heures-personnes par point de fonction, tout en précisant que l’unité heure-personne par point de fonction puisse varier de 2 à 135 en fonction de la taille du produit, de l’équipe et d’autres facteurs. « Définir la productivité » signifie attribuer un chiffre représentant les efforts nécessaires, exprimés en heures-personnes, pour développer une unité de taille de logiciel, afin de pouvoir convertir la taille du logiciel (en points de fonction) en efforts de développement (en heures-personnes). Parfois, il arrive que des intervalles soient choisis, par exemple de quinze à trente heures par UCP. À d’autres moments, des formules empiriques sont créées sur la base d’un ensemble de facteurs, comme dans le cas du « constructive cost model » (COCOMO).

Le problème de ces mesures de productivité est qu’elles regroupent toutes les activités — analyse des besoins, conception, revue, tests, etc. — en une seule mesure. Pourtant, les compétences requises pour ces tâches sont différentes, tout comme les outils utilisés, les intrants et les sortants. Les regrouper sous le titre de « développement de logiciels » et donner une seule mesure de productivité ne peut permettre qu’une estimation très approximative, et jamais précise.

Concevoir un logiciel mieux et plus vite : comment devenir plus productif ?

Le développement de logiciels fait appel aux activités suivantes :

• les activités de préparation du projet, notamment étude de faisabilité, budgétisation financière et validation du projet (approbation financière et technique, et « lancement du projet »)
• les activités de lancement du projet, telles que l’identification du chef de projet, la création d’une équipe de projet et la mise en place de l’environnement de développement ; la planification du projet ; la mise en place de divers protocoles, à savoir les accords de niveau de service et les démarches concernant les rapports de progression ; la formation liée au projet
• les activités de génie logiciel, notamment l’analyse des besoins des utilisateurs ; l’analyse des besoins logiciels ; la conception de logiciels, le codage et les tests unitaires ; les différents types de tests d’intégration, tests fonctionnels, tests négatifs, tests de système et d’acceptation ; la préparation de la documentation
• les activités de déploiement, y compris l’installation du matériel et du système ; la création de la base de données ; l’installation du logiciel d’application ; la réalisation des essais pilotes ; la formation des utilisateurs ; la phase parallèle et le déploiement effectif
• les activités de clôture du projet, notamment la documentation des bonnes et des mauvaises pratiques ; analyse du projet (fin du projet) ; dossiers d’archivage ; publication des ressources ; libération du chef de projet de ses obligations ; lancement de la maintenance du logiciel

Lorsque nous parlons des « règles de base » de l’industrie (procédures admises et reposant sur le bon sens) en matière de productivité, il est difficile de déterminer les activités incluses au taux de productivité. Personne ne parierait sur la mesure de la productivité, bien qu’il s’agisse d’une règle de base du secteur.

Jetons un œil à la nature de ces activités :

1. Analyse des besoins : comprendre et documenter ce dont a besoin l’utilisateur, ce qu’il veut et à quoi il s’attend de manière à ce que les concepteurs de logiciels comprennent parfaitement et puissent concevoir un système dans le strict respect des exigences énoncées. La dépendance à l’égard de facteurs externes est élevée.
2. Conception du logiciel : tenir compte des différentes options existant en ce qui concerne le matériel, le logiciel système et la plateforme de développement ; parvenir au choix optimal pour chacun ; concevoir une architecture qui répond aux exigences énoncées et aux attentes des clients. L’architecture doit être compatible avec les technologies actuelles et la conception documentée de telle manière que les programmeurs comprennent et livrent un produit conforme aux spécifications d’origine de l’utilisateur. Il existe plusieurs alternatives et la conception de logiciels étant une activité majeure et stratégique, les erreurs ont de graves conséquences.
3. Codage : développer un code logiciel conforme à la conception et qui contient le moins d’erreurs possible (il est si facile de laisser involontairement des « bogues » à l’intérieur).
4. Révision du code : étudier le code écrit par un autre programmeur, déchiffrer ses fonctionnalités et essayer de prédire les erreurs que le client pourrait rencontrer lorsqu’il utilise le logiciel.
5. Test : essayer de découvrir tous les défauts qui pourraient être laissés dans le logiciel. Cependant, trouver la quasi-totalité des défauts est impossible. De plus, tester l’intégralité du logiciel est une activité peu pratique.

La nature de ces activités étant si différente, il est évident que la productivité pour chacune d'entre elles n'est pas uniforme (et ne peut donc être décrite par le même chiffre). Le rythme de travail diffère pour chacune de ces activités.

Elles ne dépendent pas de la quantité de code produite, mais d'autres facteurs, tels que :

1. les exigences, qui dépendent de l'efficacité et de la clarté de leur source (utilisateurs ou documentation)
2. la conception, qui dépend de la complexité du traitement, des alternatives disponibles et des contraintes en fonction desquelles la fonctionnalité doit être conçue
3. la révision du code, qui dépend du style de codage
4. le contrôle, qui dépend de la façon dont le code est écrit (plus il y a des erreurs, plus il faut de temps pour tester et retester)
5. le codage lui-même, qui dépend de la qualité de la conception

Par conséquent, nous devons établir des chiffres de productivité différents pour chacune de ces activités.

Tentons de dresser un parallèle pour l’industrie, par exemple avec le poinçonnage. Les activités à mener à bien sont : 1) installation de la machine ; 2) installation des outils ; 3) chargement de la tâche ; 4) poinçonnage du trou ; 5) ébavurage du trou ; 6) nettoyage ; 7) livraison de la feuille pour l’opération suivante.

Si plusieurs trous sont perforés, le temps « par trou » diminue, car les activités de configuration sont des activités ponctuelles.

Par conséquent, si l’on considère le codage d’une unité, par exemple, les activités à réaliser pourraient être : 1) recevoir les instructions ; 2) étudier le document de conception ; 3) coder l’unité ; 4) tester et déboguer l’unité pour la fonctionnalité spécifique ; 5) tester et déboguer l’unité pour une utilisation quelconque ; 6) supprimer le code inutile de l’unité ; 7) effectuer un test de régression de l’unité ; 8) transférer l’unité pour l’étape suivante.

De même, nous pouvons proposer des micro-activités pour chaque phase de développement du logiciel.

Chiffres liés à la productivité : empiriques ou basés sur une étude méthodique ?

Chacune des activités ci-dessus montre un taux de réussite différent. Les temps standards pour chacune de ces activités doivent être établis. Une fois que cela est fait, des techniques d’étude de travail, telles que la synthèse ou l’estimation analytique, doivent être utilisées pour estimer la durée totale de la mission.

Que les techniques d’étude des délais soient utilisées pour réaliser des études de productivité individuelles ou pour recueillir des données empiriques, le développement de logiciels n’est ni totalement mécanique ni totalement créatif. Il est également irréaliste de planifier des activités présentant une forte composante créative ; les méthodes d’étude de travail tiennent compte de cet aspect du développement de logiciels. Beaucoup de recherches sont en cours sur la « productivité des cadres », et peut-être que des méthodes pour « minuter » la productivité dans le cadre de l’édition de logiciels seront disponibles à l’avenir. Actuellement, les données empiriques semblent être la solution de choix.

Où obtenons-nous des données empiriques ? La première option est par l’intermédiaire d’études des délais qui utilisent des techniques d’ingénierie industrielle. L’autre façon, plus facile et plus fiable, consiste à se fonder sur les données historiques fournies par les fauilles de temps.

La majorité des logiciels de gestiond et temps utilisés par l’industrie sont orientés sur la paie et la facturation. Ils ne collectent pas de données au plus petit niveau pour établir des tendances en matière de productivité. La plupart de ces logiciels consignent deux ou trois niveaux de données, outre la date et l’heure. Un projet s’inscrit toujours au premier niveau, et les deuxièmes et troisièmes niveaux peuvent être occupés par un module et un composant, un composant et une activité, ou une combinaison similaire. Outre la date et l’heure auxquelles l’employé est présent, les feuilles horaires doivent enregistrer cinq niveaux de données : le projet, le module, le composant, la phase de développement et la tâche réalisée. Ainsi, des données seraient disponibles pour établir des mesures de productivité de façon empirique et de manière réaliste.

Actuellement, les activités de développement de logiciels se concentrent sur la macro-productivité. Cette tendance doit changer, et nous devons passer de la macro à la micro-productivité. Pour ce faire, nous devons modifier nos logiciels de feuilles de temps et la profondeur des données que nous collectons.

Étudier la productivité au micro-niveau présente les avantages suivants :

• Meilleure prévisibilité du développement de logiciel
• Estimations de meilleure qualité pour améliorer la tarification pendant l’élaboration du projet et les phases de finalisation
• Établissement d’objectifs plus précis lors de la répartition des tâches, ce qui renforce la confiance des éditeurs de logiciels
• Estimation des coûts plus précise

Voir tous les logiciels Editeurs de logiciels

Conclusion

Il est important de comprendre la différence entre les termes productivité et capacité. La productivité est le taux de réussite d’une micro-activité ; la capacité est le taux de réussite d’une installation (usine, organisation, etc.), et plusieurs activités sont incluses dans le schéma des capacités. À des fins d’évaluation du logiciel, l’accent doit passer de la macro-productivité (capacité) à la productivité (pour la micro-activité). La collecte de données empiriques est privilégiée afin d’obtenir des mesures de productivité pour les différentes activités de développement de logiciels, car les techniques d’études des délais et tâches ne peuvent fournir des résultats satisfaisants lorsque la mission présente un fort degré de créativité (ce qui est le cas de l’édition de logiciels). Pour recueillir les données empiriques, il est nécessaire d’améliorer les logiciels d’enregistrement des horaires. Nous recommandons cette marche à suivre pour calculer les chiffres de productivité à tous les micro-niveaux.

Au sujet des auteurs

Murali Chemuturi est expert en génie industriel au sein de l’Indian Institution of Industrial Engineering. Il a évolué pendant plus de trente ans dans des organisations professionnelles, dont ECIL, TCS, Metamor et Satyam. Il a d’abord travaillé dans la fabrication, puis dans les TI. Il dirige actuellement Chemuturi Consultants et il s’intéresse particulièrement aux logiciels pour l’industrie du développement de logiciels. Il a mené plusieurs programmes de formation en entreprise pour la gestion de projets logiciels et l’évaluation de logiciel.

Sarada Kaligotla a terminé son Master en applications informatiques et est titulaire de la certification Project Management Professional (PMP) obtenue au Project Management Institute (PMI) en plus d’être analyste certifiée dans le domaine de la qualité de logiciel (CSQA) du Quality Assurance Institute (QAI). Elle travaille actuellement pour Blue Cross Blue Shield dans le Massachusetts. Sarada a six ans d’expérience dans l’industrie du logiciel, ainsi que dans la gestion de projet et de développement.