Vicente Merino demandait, dans le dernier post sur la complexité et l’effort de QA : « Comment estimer cet effort lorsque l’on ne dispose pas de code ?» et plus précisément « Est-il possible de décider, au début du projet, si celui sera suffisamment important pour nécessiter une équipe de QA indépendante et formaliser un plan de tests ? ».

Imaginons par exemple que vous êtes responsable des applications au sein d’une Telco. Il est donc de votre responsabilité que :

• les clients puissent se connecter sur le site web pour consulter leur facture, leur nombre de points, acquérir de nouveaux services, un nouveau portable, etc.
• les employés au service des clients puissent se connecter sur ce même site mais également à d’autres applications afin de vérifier le compte d’un client, un défaut éventuel de paiement, etc
• et d’une manière générale, que les applications commerciales permettent de vendre et que les applications financières permettent de facturer.

Un jour, le directeur commercial et le directeur financier viennent vous trouver pour vous dire ‘Nous allons lancer une nouvelle offre commerciale majeure : il faut que les applications soient prêtes pour le lancement dans 2 mois’.

Evidemment, vous avez quelques questions visant à préciser les caractéristiques de cette nouvelle offre afin de pouvoir préparer un plan projet et mobiliser vos équipes. Evidemment, les réponses sont assez vagues : vous comprenez seulement que les évolutions demandées seront importantes et toucheront à bon nombre d’applications. Il ne s’agit pas simplement de créer une nouvelle offre mais de modifier certaines mécanismes de vente, de promotion, de remise, de paiement, etc. et les structures de données pour ces traitements.

Dans un tel exemple, il n’est pas possible d’attendre que les spécifications soient suffisamment établies pour pouvoir débuter le projet, il faudra démarrer celui-ci le plus tôt possible et travailler avec les utilisateurs en cycles itératifs afin de créer les spécifications et développer au fur et à mesure que celles-ci se précisent. Une méthodologie de type Agile sera la plus efficace dans ce type de situation.

Nous avons vu également dans ce post ‘Cas d’utilisation – Ensemble et sans heurts’ comment un cycle d’Intégration Continue permet aux développeurs de tester le code au fur et à mesure qu’il est développé. En estimant la complexité des différentes évolutions pour les différentes applications touchées, il sera possible de décider au plus tôt dans le projet, d’une phase de Quality Gate permettant à une équipe de QA indépendante de réaliser une campagne de tests sur les modules les plus critiques.

Dans cet exemple, le projet a déjà débuté, ce qui ne répond donc pas exactement à la question de Vicente, mais je voulais simplement signaler qu’il est possible de déterminer le plus tôt possible si les services d’une telle équipe seront nécessaires, voire même d’estimer avant la phase de QA quelle serait l’ampleur de celle-ci et l’effort de test.

Prenons maintenant le cas où l’évaluation de cet effort – et en fait de tout le projet – doit être réalisé avant que débute celui-ci. Cette fois-ci, le directeur commercial vous parle d’un projet de produit complètement nouveau et le directeur financier vous demande quel serait le coût pour développer de nouvelles applications complètement différentes pour les clients et le service clientèle, et s’il serait possible d’utiliser les applications financières existantes ou s’il faudra en créer de nouvelles.

Comment faire pour évaluer l’effort de développement et de QA, les charges en jour/hommes et une ébauche de planning ? Dans un tel cas, nous allons procéder par analogie.

Même s’il s’agit d’un projet nouveau pour lesquels nous ne disposons pas de spécifications, nous avons déjà réalisé de telles applications pour des cas ‘métier’ semblables, et nous pouvons tenter d’évaluer la complexité et la taille du projet en nous basant sur différents points pour lesquels nous avons des données de référence. Je vais pour cela reprendre une liste fournie par Gustavo Terrera, professionnel de QA avec un très bon blog consacré à ces thèmes : testingbaires.com.

La liste de ces éléments est la suivante :

• Nombre d’applications, nombre de modules nouveaux ou à faire évoluer, nombre de fonctionnalités par module : nous avons une connaissance métier suffisante pour pouvoir recréer la chaîne des différentes applications nécessaire pour cette offre nouvelle et identifier les modules fonctionnels.
• Criticité de chaque module, criticité de chaque fonctionnalité au sein de chaque module, á développer / à tester, profils des utilisateurs. Une fois cette carte des différents modules établie, nous pouvons tenter d’estimer la complexité de chacun d’entre eux, là encore en raisonnant par analogie avec des applications semblables que nous connaissons bien.
• Nombre de bases de données, nombre de traitements batch, nombre d’interfaces, nombre de navigateurs différents pour lesquels effectuer les tests, technologies mises en œuvre, langages de développement, exigence de tests de performance, de sécurité, … Nous nous intéressons maintenant à la dimension technique, afin d’évaluer l’effort de test. Nous pouvons solliciter l’équipe de QA qui possède plus de références que nous pour effectuer cette évaluation.

Sur la base de ces différentes données, nous pouvons maintenant effectuer une évaluation du temps nécessaire pour définir et réaliser les tests, et pour la réalisation de la documentation.

Cette estimation par analogie ne sera pas forcément très précise, mais elle permet de présenter un ou plusieurs scénarios et justifier ceux-ci avec des données basées sur notre connaissance de cas semblables.

Ces deux différents exemples devraient normalement couvrir la majorité des cas :

• Un besoin métier suffisamment critique donnera lieu le plus souvent à un projet qui notamment s’il est urgent, débutera avec une analyse minimale de coûts et sans évaluation très précise des efforts de développements et de QA. Certaines méthodologies ou process nous permettent cependant de préciser ceux-ci le plus tôt possible dans le cycle de vie du projet.
• Plus le projet sera important ou nouveau ou présentera un risque pour l’entreprise, et plus il sera nécessaire de calculer le retour sur investissement. Il faudra alors procéder à une analyse la plus rigoureuse possible des coûts, ce qui sera possible si notre connaissance fonctionnelle et notre expérience est proche de ce projet. L’inconvénient réside dans l’existence ou la collecte de ces données, en nombre suffisant pour pouvoir nous constituer un référentiel qui permette une évaluation par comparaison avec celles-ci.

Reste un cas, probablement plus rare, mais qui peut se rencontrer. Cette fois-ci, le directeur commercial et le directeur financier vous expliquent qu’ils étudient la possibilité de se lancer sur un nouveau marché : vendre des assurances par téléphone à tous les clients, assurance voyage, assurance maladie, assurance accident, etc…

Cette fois-ci, nous ne disposons plus de références qui nous permettent d’estimer, par analogie, le coût de réalisation d’un tel système, ni ne possédons la connaissance fonctionnelle nécessaire. Que faire ?

J’ai posé la question à Capers Jones, certainement la personne la plus experte en matière d’estimation de coûts (et de Function Points) qui m’a fait parvenir un document disponible sur son site web Namcook.com concernant l’estimation de coûts AVANT que les spécifications fonctionnelles soient disponibles, à l’aide d’une méthode (brevetée). Celle-ci repose sur un questionnaire portant sur des données normalement disponibles avant le début du projet, telles que :

1. Salaire moyen et charges de travail de l’équipe de projet.
2. Date de début et date de livraison souhaitées pour le projet.
3. Méthodologie de développement : Agile, RUP, etc..
4. Niveau CMMI de l’équipe de projet.
5. Langage de programmation : C#, Java, SQL, etc.
6. Nature du projet : nouveau, évolution, etc.
7. Catégorie de projet : interne, commercial, etc.
8. Type de projet : client-server, application web, etc.
9. Périmètre du projet : sous-programme, programme, système, etc.
10. Complexité fonctionnelle du thème applicatif, complexité de code, de données, etc.

Les réponses à ces questions forment un ‘pattern’ qui est ensuite comparé à un référentiel de plus de 13 000 projets, avec l’idée que des projets avec des patterns identiques devraient normalement présenter des similitudes de taille et d’efforts.

Vous pouvez ainsi bénéficier d’un référentiel avec les données qui vous manquent et une méthode qui permet d’estimer la taille d’un projet et les niveaux de coûts et de risques. Vous trouverez sur le site Namcook toutes les informations sur cette méthode Software Risk Master.

Dernier point : les 3 exemples que nous avons vu peuvent se combiner en autant d’approches complémentaires.

Et vous, quelles méthodes utilisez-vous pour estimer l’effort de développement et de QA en début de projet ?

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.