Estimer les activités de support - maintenance des applications logicielles

Estimer les activités de support - maintenance des applications logicielles Traduction de l article : «Sizing Application Maintenance and Support Activities» October 2014 Anjali Mogre - Penelope Estrada Nava Atos - India Patrick HAMON V1.2 Février 2015 1/12

INTRODUCTION Une des clés de succès de tout projet est une estimation fiable. Une bonne estimation va permettre de planifier, de prévoir les ressources et le budget pour que le projet réussisse. Le suivi et la surveillance du projet, permettront de mesurer les écarts avec le plan. Pour l'estimation de logiciels, généralement deux méthodes sont utilisées, le jugement d'experts / méthode Delphi, ou une méthode de dimensionnement «scientifique» - consistant à mesurer la «taille» du logiciel en termes de Points de Fonction (IFPUG, Cosmic, ) et multipliée par la productivité spécifiques de l organisation basées sur les données historiques. L'estimation de l'effort est calculé avec : taille* productivité (Heures / Taille). ENJEUX DE L'ESTIMATION DE LA MAINTENANCE LOGICIELLE ET DES ACTIVITES DE SUPPORT La maintenance du logiciel est défini dans la «Norme IEEE Standard pour la maintenance logicielle, IEEE 1219», comme la modification d'un produit logiciel après la livraison afin de corriger les défauts, améliorer les performances ou d'autres aspects, ou pour adapter le produit à un environnement modifié. L'objectif est de modifier le logiciel existant tout en préservant son intégrité. IEEE a défini trois types de maintenance la maintenance adaptative, la maintenance corrective, la maintenance préventive. La maintenance est nécessaire pour s assurer que le logiciel continue à satisfaire les besoins des utilisateurs. La maintenance doit être réalisé afin de: Corriger les défauts Améliorer la conception Apporter des améliorations Interfacer avec d'autres systèmes Adapter les programmes à différentes fonctionnalités hardware, software, du système Migration de logiciel Retirer, arrêter un logiciel Le logiciel en production nécessite un support à l'utilisateur final. Le support de l'utilisateur final comprend le maintien de données, la résolution des requêtes de l'utilisateur, et la résolution des demandes de service. Les demandes de maintenance et de support sont généralement gérées avec des tickets au sein d un outil de gestion des incidents, allant du client à l'équipe de maintenance. Les points de fonction (IFPUG) pour la conception logicielle ne peuvent être appliqués pour la maintenance et les activités de support. IFPUG recommande des pratiques spécifiques d'estimation des travaux de maintenance. (IFPUG - Partie 3 - Counting practice). Estimer le support et la maintenance de logiciels Février 2015 2/12

Actuellement, il n existe aucune norme disponible pour estimer l'effort associé à la maintenance des logiciels et des activités de support. En général, l estimation pour les projets de maintenance logicielle est effectuée en utilisant un jugement d'expert. Cet article présente une approche pour définir un modèle d estimation pour les activités de maintenance et de support. CHALLENGE Aujourd'hui, il est essentiel de maintenir et supporter les applications logicielles en production. Les activités de maintenance et de support doivent faire face à trois défis différents : Mesurer la charge de travail et estimer l'effort - comment mesurer la taille du contrat et comment prévoir et estimer les efforts nécessaires pour les activités de support Enjeux de gestion - comment s assurer que le coût des activités de maintenance de logiciels sont conformes au budget avec les ressources disponibles Enjeux techniques - où faire le changement, les efforts pour les tests de régression, et comment améliorer la maintenabilité Les problèmes techniques sont généralement traités par l'équipe technique. La formation permet de former les nouveaux membres de l'équipe pour aborder efficacement les questions techniques. Si l'estimation est erronée, il est possible que les problèmes de gestion explosent et réduisent la rentabilité du projet voir génère des pertes. En outre, une estimation correcte de la taille de l'équipe peut aider à la définition d'un bon engagement de niveau de service et, par conséquent, l'équipe de maintenance sera en mesure de fournir le bon niveau de service, et avoir des clients satisfaits. L'estimation est une clé pour s assurer que le projet est sous contrôle. Les deux approches les plus populaires pour estimer les ressources pour la maintenance des logiciels sont l'utilisation de modèles paramétriques et l'utilisation de l'expérience [ISO14764-99: s7.4.1]. La meilleure approche pour l'estimation des activités de maintenance du logiciel est de combiner les données empiriques et l expérience. Il n existe aucune méthode reconnue pour estimer la «taille» de la maintenance des applications ou des activités de support. La «taille» n est pas disponible, il n est pas donc possible de mesurer la productivité et utiliser les valeurs de productivité pour l'estimation. Estimer le support et la maintenance de logiciels Février 2015 3/12

NORMES INTERNATIONALES - MESURES DE LA PRODUCTIVITE POUR LA MAINTENANCE D'APPLICATION Les communautés mondiales ont développé quelques définitions qui peuvent être adoptées pour les mesures de productivité. La norme EEI 1045 décrit la productivité à calculer en termes d'efforts vs lignes de codes ou de Points de Fonction. Elle mentionne que la productivité doit être utilisée pour les projets de maintenance de logiciels; toutefois, elle ne caractérise pas comment elle doit être mesurée. La norme ISO / IEC 15939 - Est utilisé comme une base du modèle CMMi (Capability Maturity Model - Intégration). Il définit les mesures de base et les mesures dérivées. La productivité est une mesure dérivée. Cependant, la norme ne mentionne pas spécifiquement le calcul de la productivité. Le modèle CMMi permet d'améliorer la qualité et la productivité; Mais le modèle ne donne pas d'indications sur la méthode à utiliser pour le calcul de la productivité. IFPUG - International Function Point Users Group décrit la méthode à utiliser pour déterminer la taille du logiciel en termes de Points de Fonction. Pour les mesures de la productivité, les entrées sont mesurées en termes d effort en heure tandis que la production est mesurée en termes de «taille» de l ensemble des travaux délivrés en termes de Point Fonction (FP). IFPUG fournit une méthodologie standard pour mesurer la taille du logiciel en termes de points de fonction FP. Cependant, par définition, les Points de Fonction, ne sont pas appropriés pour une application du type maintenance logicielle où les ensembles de travaux sont très petits. Les Points de Fonction sont adapté pour les grands développements. Une autre mesure courante de la taille du logiciel est le nombre de lignes de codes. Il suffit de mesurer les lignes de code écrites dans le logiciel pour offrir les fonctionnalités requises. Il n y a pas de contestation dans la mesure des lignes de code. Il est plus facile de mesurer les lignes de code que les Points de Fonction. Cependant, ce n est pas une bonne mesure, car un logiciel mal écrit, qui a plus de lignes, a une meilleure productivité qu'un bon logiciel qui a utilisé approche objet et fournit la même fonctionnalité en moins de lignes de code. De plus, la maintenance de l'application nécessite de changer, d ajouter ou supprimer quelques lignes de code. Ainsi, la maintenance en heures / lignes de code ne donne pas une bonne mesure de la productivité. The International Software Benchmarking Standards Group Limited (ISBSG) Propose d évaluer la productivité de maintenance en termes de ratio d'heures / FP ou Heures / KLOC Le ratio de maintenance est calculé comme un effort (en heures) normalisée à une période de l'année, divisé par taille d application (en FP). Cependant; on ne connait pas typiquement la taille de l'ensemble du logiciel devant être maintenue, d'où l'utilisation limitée d ISBSG. La vitesse de traitement des demandes de changement dépendra de la maintenabilité du code ou d enjeux business; par conséquent, il peut ne pas être possible d'estimer l'effort uniquement à partir de la taille (Points de Fonction) de l application qui doit être maintenue. Estimer le support et la maintenance de logiciels Février 2015 4/12

L effort / ticket pourrait être l'une des mesures de productivité. Cependant, c est une mesure faussée car il ne tient pas compte du type et de la complexité du ticket. Les équipes projet en charge de la résolution des tickets complexes auront plus d efforts à fournir par ticket, par rapport aux équipes projet en charge de la résolution ticket simples cela donne une productivité erronée. Donc ce n est pas une approche qui peut être utilisée pour mesurer, comparer la productivité et décider des actions d'amélioration de la productivité. SOLUTION PROPOSEE Il y a un besoin évident de mesurer la «taille» du travail à fournir pour une petite demande de changement et une demande d'assistance. Une fois que la «taille» du travail est déterminée; il est possible de définir quels projets peuvent être utilisés pour comprendre les tendances de la productivité, de diagnostiquer les zones sensibles et de définir des actions d'amélioration de productivité. L'ITIL (Information Technology Infrastructure Library) est l'approche la plus répandue au niveau mondial pour la gestion de service informatique. Elle prévoit un cadre pratique, clair et sans ambigüité pour l'identification, la planification, la prestation et le soutien des services informatiques de l'entreprise. ITIL classifie une demande de service ou un ticket d'entrée dans différentes catégories telles que, la demande de service, les questions, les incidents, les changements standard, les petits changements, et les problèmes. Notre solution propose de mesurer la «taille» de la maintenance et du support des tickets en termes de mesures spécifiques Atos - Work Point (WP) basé sur le modèle ITIL. Work Point - WP est défini en fonction du type de ticket et la complexité du ticket. Les types de tickets sont alignés avec les définitions des tickets ITIL et nous avons défini quatre niveaux de complexité - simple, médium, complexe et très complexe. Ticket Type Appel / Plainte Production / Contrôle Question / Information Definition des Work Point (WP) demande de service Incident Problème Changement standard Petits changements GDP Complexity Simple 0.5 0.5 0.5 0.1 0.2 1 0,3 1 0.5 Medium 1 0.75 0.1 0.2 0.4 3 0.5 2 1 Complexe NA 0.1 0.2 0.3 0.6 5 0.8 2.5 2 Très complexe NA 0.3 0.3 0.4 0.8 9 NA NA NA Conseil Le tableau suivant montre comment les WP sont définis : Les WP définis ci-dessus représentent la «taille» ou «poids» d'un ticket. Par exemple, un simple changement standard est de 0,3 WP tandis qu un simple petit changement est 1 WP. Les définitions initiales des WP sont faites avec l'hypothèse qu une équipe ayant une compétence "moyenne" devra fournir la même quantité d'effort par type de ticket et par niveau de complexité, indépendamment de la technologie utilisée ou du type d'application maintenue. À ce stade, comme nous comptons des heures, et non pas une «taille», nous devons «convertir» les efforts en WP, par conséquent nous supposons une base de productivité de 10 heures / WP. Estimer le support et la maintenance de logiciels Février 2015 5/12

La connaissance des experts de même que des données historiques constitue la base pour arriver au calibrage de WP. Par exemple, des données historiques montre qu un changement simple prend 3 heures d'effort, donc les WP pour les «changements simples et standards» est 0,3 tandis qu'un petit changement simple prend 10 heures d'effort donc le WP pour un simple changement est 1 WP. La définition de la complexité est un peu délicate. Le mot complexité est dérivé du mot latin complexus ce qui signifie tordu ensemble tandis que le dictionnaire d Oxford définit la complexité comme l assemblage de plusieurs parties étroitement liées. La complexité du travail peut dépendre de la perception de chaque individu. Cependant, pour avoir une mesure objective de la Taille du travail, la complexité doit être définie de façon objective. Dans le modèle de WP, la complexité est définie en fonction de la priorité, de la gravité, de l'impact sur le Business, du type de changement, de l'âge de la demande, et de la maturité du client. Le niveau de service du support est également utilisé pour définir la complexité des tickets: un service de support ne peut généralement pas résoudre des tickets avec des niveaux de complexité élevés. Les gestionnaires de projet, avec l'aide d'experts en la matière, cartographient les types de tickets spécifiques au projet afin de s approprier le type de tickets ITIL et les lignes directrices de la complexité définies dans le modèle. Le mappage du type de tickets et de la complexité convenue sera utilisé pendant toute l'exécution du contrat. L effort actuel pour la résolution des tickets est utilisé pour aligner la définition initiale du projet avec ses types de tickets, aux définitions données dans le modèle si aucune donnée historique n est disponible. Le tableau suivant montre comment la nomenclature ticket de projet spécifique s'aligne sur le modèle de WP standard. Il est nécessaire que la cartographie des tickets soit discutée, examinée et approuvée par les managers et les responsables qualité pour s assurer que la taille est correcte en fonction d'un élément de travail standard (WP). Exemple de mapping de ticket type Correspondance type de ticket de projet / nomenclature spécifique No Type de billets Projet spécifiques Reportez-vous à la définition du type de ticket et les informaions sur la complexité Modèle type de tickets Modèle de WP complexité de WP Remarques 1 Extraction de données - Simple Petit changement Simple Ecrire une requête SQL pour extraire les données et envoyer le rapport 2 Défaut - Priorité 1 Incident Simple Priorité telle que définie par le client 3 Défaut - Priorité 2 Incident Medium 4 Incident - Sévérité 1 Incident Complèxe L'application a cessé de fonctionner 5 Incident - Sévérité 3 Incident Medium Erreur de données - des données doient être mise à jour 6 Demande de changement Petit changement Medium Une demande de modification pour corriger le code 7 Demande de changement pb - priorité 1 Incident Complèxe 8 Changement de code (password) Demande de service Simple Réinitialiser le mot de passe 9 Question - Comment Question / Information Simple Informations facilement disponibles dans le FAQ 10 Question - Comment Question / Information Medium Une études est nécessaires pour fournir des informations Une fois terminé, l'exercice d'alignement du modèle de WP par type de tickets avec le type de tickets spécifiques du projet, chaque ticket est classé selon le standard, puis la complexité standard et la «taille» totale des tickets fermés pendant la période particulière peut être saisie. Estimer le support et la maintenance de logiciels Février 2015 6/12

Chaque ticket est classé dans l'un des types de ticket standards et selon la définition de la complexité spécifique du projet. Une fois le ticket catégorisé, la taille du ticket est prise dans la table de définition de WP. Chaque ticket a une «taille» attribuée en WP selon les règles prédéfinies. L effort réel passé pour la résolution ticket est saisie. Il peut être difficile d obtenir ces données; la génération de ces données doit être extraite de l'outil de gestion des incidents. Catalogue de productivité pour les projets - Détail du Ticket Nom du contrat Nom Numéro de contrat A######## Mois/Année août-12 Technologie 0.0 Productivité : temps / WP 8.2 Efficacité : Effort/WP 6.76 Ticket - module de travail Ticket - module de travail Type de Ticket Description du ticket UO Complexité No. Du Ticket WP Heure réelle Niveau de support Remarque 1 Ticket 1 Incident Simple 1 0.1 0.5 L1 2 Ticket 2 Demande / Information Medium 2 0.1 1 L1 3 Ticket 3 Demande de Service Complexe 1 0.2 12 L2 4 Ticket 4 Changement Strandard Complexe 1 0.8 8 L2 5 Ticket 5 Petit Changement Simple 1 1 0.5 L3 6 Ticket 6 Problème Medium 3 6 5 L3 7 Ticket 7 Incident Complexe 1 0.8 9 L2 8 Ticket 8 Demande / Information Très Complexe 2 0.4 3 L1 9 Ticket 9 Demande de Service Simple 1 0.05 1 L1 10 Ticket 10 Changement Standard Medium 2 0.8 10 L2 Definition des Work Point (WP) Ticket Type GDP Complexity Appel / Plainte Production / Contrôle Question / Information demande de service Incident Problème Changement de norme Petits changements Conseil Simple 0.5 0.5 0.5 0.1 0.2 1 0.3 1 0.5 Medium 1 0.75 0.1 0.2 0.4 3 0.5 2 1 Complexe NA 0.1 0.2 0.3 0.6 5 0.8 2.5 2 Très complexe NA 0.3 0.3 0.4 0.8 9 NA NA NA La somme des WP donne la «taille» totale du travail effectué au cours de la période considérée. Le ratio WP total / total des efforts consacrés à résoudre les tickets donne la productivité de de l'équipe d'ingénierie. La productivité totale des projets peut être calculée en ajoutant, dans le dénominateur, les efforts de gestion de projet et de la qualité. Les fonctions services de support et de livraison restant dans ITIL - Gestion de la configuration, la gestion des release, la gestion de la capacité... - peuvent être ajoutées dans le modèle WP mais elles nécessitent un processus très mature pour capturer les activités et les efforts liés à ces fonctions. Comme tous les projets utilisent la même définition de WP, il est possible d'ajouter ou de comparer différents projets, et la productivité peut être déduite au niveau d un groupe de projets ou au niveau de la Business Unit. Il est possible d'obtenir la tendance de la productivité et de parvenir à des actions spécifiques de productivité. Une analyse détaillée des données du projet va révéler des zones critiques réelles auxquelles est confronté le projet. La productivité peut être calculée au niveau de type de ticket et il est possible d'identifier et de prendre des mesures ciblées pour l'amélioration de la productivité. Estimer le support et la maintenance de logiciels Février 2015 7/12

LA PRODUCTIVITE DE REFERENCE La productivité de référence peut être obtenue sur la base des données recueillies à partir de plusieurs projets. Les données sur la productivité peuvent être recueillies auprès de tous les projets de maintenance applicative chaque mois; les tickets résolus au cours du mois. Toutes les données sont collectées, les valeurs aberrantes (le cas échéant) sont enlevées. Les projets à très faible volume de données, des chiffres très élevés ou une très faible productivité avec une variation identifiable sont considérés comme des valeurs aberrantes. Le nombre total de projets, le nombre total de tickets, les efforts peuvent être consolidés au niveau trimestriel ou semestriel. 2014-Q1 2013-H2 2013-H1 Nb de projets fournissant des données de la productivité 126 110 105 Période Jan 2013 - March 2014 Jan-Dec 2013 Jan - June 2013 Nb de points de données (sans les valeurs aberrantes) 1333 810 540 Nb de technologies 37 34 34 Niveau de compétence 2.53 2.49 2.51 Nb total de ticket 444 061 250 031 158 527 WP 170 175 98 149 64 609 Effort total 1,463,653 859,88 561,102 Effort en inginérie 1,199,861 710,693 470,393 % Effort de gestion de projet 18% 17% 16% Productivité totale 8.60 8.76 8.68 Productivité des ingénieurs 7.05 7.24 7.28 AET (Activity Time / Ticket) 3.30 3.44 3.54 AET (Engineering time / Ticket) 2.70 2.84 2.97 Les résultats présentés dans le tableau ci-dessus, révèlent que la productivité des contrats en 2013-H1 est de 8,68 heures par WP. Cela signifie que les équipes ont une meilleure performance par rapport à la productivité de base de 10 heures / WP car ils passent 1,32 heures de moins pour la même quantité de charge de travail. Le niveau de compétence, en 2013-H1 est de 2,51; nous pouvons déduire le niveau de compétence «moyenne» à 2,9. Par conséquent, la productivité de base est de 8,68 heures / WP et peut être associée à un niveau de compétences de 2,9. D'autres mesures fourniront des informations sur la façon dont se comporte la productivité par rapport à la distribution du type de ticket, le niveau de compétence des équipes, ou les technologies ajoutées ou supprimées, etc. Les détails de la répartition globale de tickets peuvent être obtenus ; il est également possible d'obtenir les références de productivité par technologiques spécifiques, par secteur d'activité, par la taille relative de contrat. Les détails de la distribution globale de billets peuvent être obtenus comme suit: Estimer le support et la maintenance de logiciels Février 2015 8/12

Petit Changement Consultation Distribution du travail Changement standard Problème Incident Production / monitoring Demande / information Demande de service Appel / plainte Production / monitoring Demande / information Demande de service Incident Problème Changement standard Petit Changement Consultation Sur la base des données des tickets, il est possible de déduire la productivité de base d une technologie spécifique de la manière suivante: technologie principale Points de données WP total Temps / Effort total (H) Efforts d'ingénierie Total # de ticket Niveaux de compétence de l'équipe Productivité (Temps total / WP) Productivité Engineering (Temps d'ingénierie / WP) SAP 241 61,497 537,602 424,809 172,943 2.64 8.74 6.91 JAVA 200 30,070 215,085 180,061 37,918 2.42 7.15 5.99 Telecom BSS 12 15,049 150,182 127,894 49,720 2.57 9.98 8.50 Dotnet 191 13,960 116,270 96,216 28,170 2.69 8.33 6.89 BSCS 32 9,552 86,828 76,660 19,655 2.97 9.09 8.03 Oracle 91 9,291 76,978 63,591 34,728 2.61 8.28 6.84 Oracle Apps 83 6,357 58,759 46,364 7,055 2.64 9.24 7.29 Unité centrale 74 4,244 42,479 36,684 8,844 2.34 10.01 8.64 La productivité de base ci-dessus peut être utilisée pour : Estimer de nouvelles offres Comparer la productivité Mise en place d'objectifs de productivité Comparer les performances des projets ESTIMATION L'effort consacré à la mesure de la productivité est d autant plus utile si les données de productivité sont utilisées pour les estimations futures. L'estimation de l'effort est possible à deux niveaux différents; l'estimation de l effort d un ticket associé à un projet en cours et, deuxièmement, pour de nouvelles offres. Estimer le support et la maintenance de logiciels Février 2015 9/12

ESTIMATION DE L EFFORT DES PROJETS EN COURS Pour les projets en cours le même modèle peut être utilisé pour estimer l'effort par ticket. Quand le ticket arrive, le ticket peut être classé selon le type de ticket standard et la complexité. Cette catégorisation donne la «Taille» du ticket en termes de WP. Ce WP multiplié par la valeur de la productivité de base du projet donnera l'effort estimé par ticket. En utilisant le modèle ci-dessus, le chef de projet peut définir le temps nécessaire pour résoudre le ticket. Estimation des efforts pour les nouvelles offres Pour estimer les efforts pour les nouvelles offres, l'équipe d'estimation, en s appuyant sur les exigences et les discussions avec le client, sera en mesure de s entendre sur le volume et la nature du travail. Estimer le support et la maintenance de logiciels Février 2015 10/12

L'équipe d'estimation devra estimer Le nombre total de tickets à résoudre La distribution des tickets selon le type de ticket et la complexité La technologie Les efforts nécessaires pour les risques et imprévus En entrant la distribution, les tickets et la complexité dans le modèle WP, on peut arriver à la «taille du travail» en termes de Work Point (WP). Une fois que la «taille» des travaux est estimé, l estimation des efforts peut être déduite de la productivité / WP pour la technologie concernée. Si l'équipe d'estimation n est pas en mesure de déterminer la distribution des tickets, celle-ci peut être estimée à partir des données historiques (si disponible). Les efforts estimés sont calculés ainsi = WP * productivité de base de la technologie La productivité peut être ajustée en fonction des compétences de l'équipe disponible. Si la productivité de base n est pas disponible pour une technologie donnée, on peut utiliser une technologie similaire ou ajuster la productivité de tous les projets. L'effort estimé ci-dessus est l effort d'ingénierie - nécessaires par l'équipe technique pour résoudre les tickets ; les efforts de gestion de projet, les risques et tous les autres efforts devant être pris en compte pour arriver au coût final du projet. Conclusion : Le modèle Atos-WP a prouvé qu'il est possible de commencer à mesurer la «taille» de la maintenance des logiciels et des activités de support qu implique généralement la résolution de petits tickets. Le modèle est déployé chez Atos - à l'échelle mondiale Pour définir la productivité de base au niveau d une l'organisation Pour mesurer l'amélioration de la productivité des projets Pour déduire des actions d'amélioration continue Estimer le support et la maintenance de logiciels Février 2015 11/12

Pour démontrer d une année à l autre l'amélioration de la productivité que l'on peut offrir au client De fixer des objectifs de productivité Et le plus important : d estimer les efforts pour les nouveaux projets autant que pour les projets en cours Déployer ce modèle a non seulement contribué à mesurer la productivité, mais a aussi eu un effet positif dans l'amélioration de la qualité globale des données des projets. Cette approche apporte de la transparence dans les efforts qui ont été dépensés sur des projets. Les projets sont capables de diagnostiquer les difficultés et sont en mesure de proposer des actions d'amélioration de la productivité. Afin de garantir un déploiement correct et standard du modèle, Atos utilise les mêmes chiffres WP dans tous les cas. Les chiffres de WP présentés dans cet article sont des exemples de valeurs Atos peut offrir le processus, les outils, la formation et le conseil pour déployer le modèle et aider à une autre organisation dans son programme de mesure de la productivité et l'estimation des efforts support et la maintenance des logiciels. Source : «Sizing Application Maintenance and Support Activities» October 2014 Anjali Mogre - Penelope Estrada Nava REMARQUES SUR L ARTICLE L approche s appuie sur ITIL pour définir les travaux de support/maintenance, propose une technique pour définir une taille homogène des travaux, et décrit comment associer la complexité. Le modèle d estimation ne fait pas le lien avec le nombre de bugs estimés qui dépend de la taille du logiciel produit. A PROPOS D ESTIMANCY Estimancy : l art d estimer les projets Estimancy permet de rendre les estimations de projets plus simples, plus rapides, et surtout plus fiables. Estimancy propose la première solution de Gestion des Estimations de Projets, Web et Open Source. La solution d Estimancy permet d industrialiser le processus d estimation des coûts de développement et de maintenance de logiciels ou de systèmes, mais également de beaucoup d autres domaines de l ingénierie. Pour plus d informations : www.estimancy.com Estimer le support et la maintenance de logiciels Février 2015 12/12