Brevet FR2916561A1 — publié le 20081128

B06-0083FR - GBR/EVH Entreprise unipersonnelle à responsabilité limitée - EURL : AGILII SARL Système de gestion de la réalisation d'un logiciel informatique par une méthode agile Invention de : Patrice PETIT 2 Système de gestion de la réalisation d'un logiciel informatique par une méthode agile La présente invention porte sur un système de gestion de la réalisation d'un logiciel informatique par une méthode agile. Une méthode agile est une méthode de développement ou réalisation informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur ou client, ce qui permet une grande réactivité vis-à-vis de ses demandes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client, et à améliorer le respect des coûts et des délais prévus pour la réalisation du logiciel informatique. A ces fins, les méthodes agiles privilégient quatre fondamentaux : - les individus et leurs interactions plutôt que les processus et les outils. L'équipe est bien plus importante que les moyens matériels ou les procédures, il est préférable d'avoir une équipe soudée et qui communique composée de développeurs de niveau moyen, plutôt qu'une équipe composée de développeurs individualistes, même brillants. La communication est une notion fondamentale. - un logiciel qui fonctionne, plutôt que la réalisation d'une documentation exhaustive. Il est important que l'application fonctionne, le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. - la collaboration avec le client plutôt que la négociation de contrats. Le client doit être impliqué dans la réalisation du logiciel, il ne faut pas se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un retour continu sur l'adaptation du logiciel à ses attentes. - la réaction au changement plutôt que le suivi d'un plan figé. La planification et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les livraisons du logiciel en cours de développement au client provoquent souvent des demandes d'évolutions du logiciel. I1 faut accepter les changements de priorités du client et les modifications des fonctionnalités souhaitées. I1 existe des systèmes automatisés d'aide à la planification et à la gestion de la réalisation de logiciels informatiques, tels que décrits dans les demandes de brevets US 2006/0112175, US 2005/0114830, et EP 1 193 630. Les systèmes décrits dans ces documents ne permettent pas d'identifier avec suffisamment de précision les causes engendrant des dérives ou des problèmes dans la planification de la réalisation du logiciel, ou dans l'estimation de sa date de livraison finale, tout en respectant les critères ou valeurs d'agilité. En outre, l'estimation de la date de livraison, ou délai prévu de fin de réalisation, manque de précision. Aussi, un but de l'invention est de proposer un système de gestion de la réalisation d'un logiciel informatique par une méthode agile, qui améliore la détection de problèmes de réalisation, et en détermine les causes, et qui améliore la précision de la détermination d'un délai prévu de fin de réalisation du logiciel. Selon un aspect de l'invention, il est proposé un système de gestion de la réalisation d'un logiciel informatique par une méthode agile, comprenant des moyens d'entrée pour entrer une valeur initiale d'un paramètre représentatif du temps estimé pour effectuer la réalisation du logiciel, et pour entrer de manière itérative la valeur d'un paramètre représentatif du temps estimé pour effectuer des étapes de réalisation correspondant à une itération. Le système comprend, en outre, des moyens de détermination d'un délai prévu de fin de réalisation dudit logiciel à partir desdits temps estimés, des premiers moyens d'analyse de l'évolution du paramètre représentatif du temps estimé de réalisation des étapes des itérations, des deuxièmes moyens d'analyse de l'évolution au cours des itérations du délai prévu de fin de réalisation du logiciel, et une bibliothèque de données comprenant des données représentatives de problèmes de réalisation en fonction de l'évolution du paramètre représentatif du temps estimé pour la réalisation des étapes des itérations, et en fonction de l'évolution du délai prévu de fin de réalisation du logiciel. I1 est ainsi possible d'identifier de manière précise des problèmes de réalisation du logiciel. En outre, il est possible, de manière aisée, de faire évoluer le système, et notamment la bibliothèque de données, de manière, avec l'expérience, à étoffer le nombre de données représentatives de problèmes de réalisation du logiciel, et ainsi d'améliorer encore la précision dans la détection des problèmes de réalisation du logiciel. Dans un mode de réalisation, les moyens de détermination d'un délai prévu de fin de réalisation comprennent des moyens d'extrapolation non linéaire. En effet, une extrapolation non linéaire permet d'obtenir un délai prévu de fin de réalisation avec une précision fortement améliorée. Dans un mode de réalisation, le système comprend des moyens de détection de survenue d'un problème de réalisation représenté dans la bibliothèque de données. Dans un mode de réalisation, les moyens d'entrée comprennent des tableaux pouvant être complétés manuellement et des moyens d'acquisition de données capables d'élaborer des fichiers de données représentatifs des contenus desdits tableaux. Ainsi, les différents intervenants de la réalisation du logiciel peuvent remplir des tableaux, généralement sous forme de fiches, dans lesquels ils mentionnent le temps passé pour effectuer certaines tâches, et estiment des durées pour terminer ces tâches ou en effectuer d'autres. Les fiches peuvent être sous forme papier ou sous formes d'écrans électroniques muni de mémoires mortes. Les moyens d'acquisition, qui comprennent par exemple une caméra sont capables de faire une acquisition de ces données et de les stocker sous forme de fichiers informatiques de données. En variante, les moyens d'entrée comprennent des moyens d'affichage pour afficher des tableaux pouvant être complétés par l'intermédiaire de moyens de saisie de données, et des moyens d'acquisition de données capables d'élaborer des fichiers de données représentatifs des contenus desdits tableaux. Les moyens d'affichages peuvent, par exemple, comprendre un écran d'ordinateur, et les moyens de saisie de données un clavier d'ordinateur. Dans un mode de réalisation, le système comprend des moyens de reconnaissance de modifications apportées au contenu des tableaux, et des moyens de prise en compte des modifications. Ainsi, lorsque les tableaux sont modifiés, les modifications sont prises en compte, et les fichiers de données correspondants sont mis à jour. Dans un mode de réalisation, le système comprend des moyens d'alerte pour générer une alerte lorsque des données ont été enlevées d'un tableau ou lorsqu'un tableau a été enlevé depuis une durée supérieure à une durée de seuil. Ainsi, l'équipe réalisant le logiciel est alertée par une alarme lorsqu'une donnée à mettre à jour dans un tableau n'a pas été mise à jour assez rapidement. A ces fins, les fiches peuvent être identifiées par reconnaissance d'une signature, par un code barre, ou par une étiquette électronique, par exemple de type RFID. Dans un mode de réalisation, lesdits moyens d'analyse sont adaptés pour délivrer en sortie des informations affichable sous forme de courbes en deux dimensions. Ainsi, le responsable du projet peut visualiser facilement l'évolution temporelle de ce paramètre. Selon un autre aspect de l'invention, il est également proposé un procédé de gestion de la réalisation d'un logiciel informatique par une méthode agile. On entre une valeur initiale d'un paramètre représentatif du temps estimé pour effectuer la réalisation du logiciel, et on entre de manière itérative la valeur d'un paramètre représentatif du temps estimé pour effectuer des étapes de réalisation correspondant à une itération. On détermine un délai prévu de fin de réalisation dudit logiciel à partir desdits temps estimés, et on analyse l'évolution du paramètre représentatif du temps estimé de réalisation des étapes des itérations. On analyse l'évolution au cours des itérations du délai prévu de fin de réalisation du logiciel, et on utilise une bibliothèque de données pour identifier des problèmes de réalisation en fonction de l'évolution du paramètre représentatif du temps estimé pour la réalisation des étapes des itérations, et en fonction de l'évolution du délai prévu de fin de réalisation du logiciel. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, de quelques exemples nullement limitatifs, et faite en référence aux dessins annexés, sur lesquels - la figure 1 illustre schématiquement un système de gestion de la réalisation d'un logiciel informatique par une méthode agile selon un aspect de l'invention ; - la figure 2 représente l'évolution, au cours des itérations de réalisation, d'un paramètre représentatif du temps estimé pour effectuer une étape de réalisation, selon un aspect de l'invention ; et - la figure 3 illustre schématiquement la détermination d'un délai prévu de fin de réalisation du logiciel selon un aspect de l'invention. Tel qu'illustré sur la figure 1, le système comprend un élément d'affichage 1, par exemple sous forme d'un panneau d'affichage. En variante cet élément d'affichage pourrait être un écran de type écran d'ordinateur. Des moyens d'acquisition de données 3 comprennent une caméra 4 et un module de réception de données 5 auquel elle est reliée, par exemple par une liaison filaire 5a. En variante, les moyens d'acquisition de données peuvent comprendre une caméra, par exemple une webcam transmettant, par liaison sans fil, des données au module de réception de données 5. Le module de réception de données 5 fait partie d'une plateforme ou serveur 6. Des tableaux 7 pouvant être complétés manuellement sont mis à jour à chaque itération, et affichées sur l'élément d'affichage 1. Le module de réception de données 5 est capable de mettre les données d'un tableau 7, transmises sous forme d'images par la caméra 4, sous forme de fichiers de données numériques stockées en mémoire dans une mémoire 8. Le module 5 peut par exemple comprendre une carte d'acquisition de données vidéo, pouvant être capable de chiffrer ces données. Un module 9 de reconnaissance de modifications apportées au contenu de tableaux 7 et un module 10 de prise en compte des modifications permettent de tenir à jour les fichiers mémorisés représentant le contenu des tableaux 7. Les modules 9 et 10 peuvent, par exemple, comprendre une carte spécifique, dédiée à cet effet Le serveur 6 comprend en outre une bibliothèque de données 11, par exemple sous forme d'une base de données, comprenant des données représentatives de problèmes de réalisation du logiciel en fonction de l'évolution du paramètre représentatif du temps estimé pour effectuer les étapes de réalisations des itérations, et en fonction de l'évolution du délai prévu de fin de réalisation du logiciel. Un module de détermination 12 permet de déterminer un délai prévu de fin de réalisation du logiciel à partir desdits temps estimés. Le module de détermination 12 comprend, par exemple, des mémoires, des liens d'accès à la mémoire 8, et un calculateur pour déterminer le délai prévu de fin de réalisation du logiciel. La plateforme 6 comprend, en outre, un premier module d'analyse 13 de l'évolution du paramètre représentatif du temps estimé de réalisation des étapes des itérations, et un deuxième module d'analyse 14 de l'évolution au cours des itérations du délai prévu de fin de réalisation du logiciel. Un module de détection 15 permet de détecter la survenue d'un problème de réalisation représenté dans la bibliothèque de données 11. Le module de détection 15 comprend, par exemple, un comparateur des fichiers dans la mémoire 8 avec les données de la bibliothèque 11. En outre, un module d'alerte 16 peut générer une alerte, par exemple en déclenchant une alarme visuelle et/ou auditive 17 lorsque des données ont été enlevées d'un tableau 7 ou qu'un tableau 7 a été enlevé depuis une durée supérieure à une durée de seuil. Le module d'alerte 16 comprend, par exemple, un récepteur de signal transmis par le module de détection 15, et un émetteur de signal déclenchant l'alarme 17. Le module de détermination 12 d'un délai prévu de fin de réalisation du logiciel comprend un module 18 d'extrapolation non linéaire de l'évolution du paramètre représentatif du temps estimé pour finir la réalisation du logiciel en fonction de l'itération courante de développement. Le module 18 d'extrapolation non linéaire comprend, par exemple, des mémoires et un calculateur. Les modules 5, 9, 10, 12, 15, 16 et 18 peuvent être réalisés sous forme logicielle ou matérielle, par exemple de circuits intégrés. Une telle extrapolation non linéaire 20 est représentée sur la figure 3, sur laquelle est également représentée une extrapolation linéaire 21 classiquement effectuée dans les méthodes agiles. En ordonné de la figure 3, la charge estimée ou le temps estimé restant pour finir la réalisation du logiciel est exprimé en points. Un point représente une valeur de référence permettant de quantifier une durée élémentaire de travail. Le système de la figure 1 permet de gérer la réalisation d'un logiciel informatique par une méthode agile. La figure 2 illustre un exemple d'estimation du temps, en points, d'étapes à réaliser pour les différentes itérations successives. Dans l'exemple, la réalisation du logiciel est faite en treize itérations, et à chaque itération le temps de réalisation de certaines étapes est estimé. L'extrapolation non linéaire effectuée par le module d'extrapolation non linéaire 18 permet d'améliorer sensiblement la précision de la détermination du délai prévu de fin de réalisation du logiciel. Le module de détection 15 détecte la survenue du problème de réalisation représenté dans la bibliothèque de données 11 par des données représentatives de problèmes de réalisation en fonction de l'évolution du paramètre représentatif du temps estimé pour la réalisation des itérations, et en fonction de l'évolution du délai prévu de fin de réalisation du logiciel. En effet, si l'évolution du paramètre représentatif du temps estimé pour la réalisation des itérations est discontinue, la cause peut être la gestion simultanée d'autres projets par l'équipe de développement, l'inexpérience de l'équipe qui ne sait pas encore précisément estimer le temps pour la réalisation des étapes des itérations, un projet qui démarre, ou une équipe qui vient de changer. Si le paramètre représentatif du temps estimé pour la réalisation des étapes des itérations reste sensiblement nul, et que des données de tableaux ont été modifiées, la cause est sûrement due à une ré-estimation du temps de réalisation de certaines étapes, ou à des modifications de spécifications fonctionnelles du logiciel après leur développement. Un paramètre représentatif du temps estimé pour la réalisation des étapes des itérations restant sensiblement nul peut aussi indiquer une livraison partielle du logiciel, pour laquelle l'équipe s'est investie au lieu de continuer à réaliser d'autres étapes, ou des congés pris par des personnes de l'équipe de développement. Si le paramètre représentatif du temps estimé pour la réalisation des étapes des itérations reste sensiblement constant, que l'estimation de la valeur du paramètre représentatif du temps estimé pour finir la réalisation du logiciel évolue aléatoirement et que les tableaux sont régulièrement modifiés, cela peut indiquer que le client modifie les fonctionnalités demandées au logiciel durant leur réalisation. Si la valeur du paramètre représentatif du temps estimé de réalisation des étapes des itérations décroît au cours des itérations, et que la valeur du paramètre représentatif du temps estimé pour finir la réalisation du logiciel s'amortit au cours des itérations, alors cela peut être dû à une modification de l'équipe de développement du logiciel. La présente invention permet de mettre en oeuvre automatiquement la gestion de la réalisation d'un logiciel informatique par une méthode agile et de détecter automatiquement les problèmes de réalisation au cours du développement du logiciel. En outre, la présente invention permet d'avoir une estimation d'une précision améliorée du délai prévu de fin de réalisation du logiciel. REVENDICATIONS 1. Système de gestion de la réalisation d'un logiciel informatique par une méthode agile, comprenant des moyens d'entrée (1, 2) pour entrer une valeur initiale d'un paramètre représentatif du temps estimé pour effectuer la réalisation du logiciel, et pour entrer de manière itérative la valeur d'un paramètre représentatif du temps estimé pour effectuer des étapes de réalisation correspondant à une itération, et des moyens de détermination (12) d'un délai prévu de fin de réalisation dudit logiciel à partir desdits temps estimés, caractérisé en ce qu'il comprend des premiers moyens d'analyse (13) de l'évolution du paramètre représentatif du temps estimé de réalisation des étapes des itérations, des deuxièmes moyens d'analyse (14) de l'évolution au cours des itérations du délai prévu de fin de réalisation du logiciel, et une bibliothèque de données (11) comprenant des données représentatives de problèmes de réalisation en fonction de l'évolution du paramètre représentatif du temps estimé pour la réalisation des étapes des itérations, et en fonction de l'évolution du délai prévu de fin de réalisation du logiciel. 2. Système selon la revendication 1, dans lequel les moyens de détermination (12) d'un délai prévu de fin de réalisation comprennent des moyens d'extrapolation non linéaire (18). 3. Système selon la revendication 1 ou 2, comprenant des moyens de détection (15) de survenue d'un problème de réalisation représenté dans la bibliothèque de données (11). 4. Système selon l'une des revendications 1 à 3, dans lequel les moyens d'entrée comprennent des tableaux (7) pouvant être complétés manuellement et des moyens d'acquisition de données (4, 5) capables d'élaborer des fichiers de données représentatifs des contenus desdits tableaux (7). 5. Système selon l'une des revendications 1 à 3, dans lequel les moyens d'entrée comprennent des moyens d'affichage (2) pour afficher des tableaux pouvant être complétés par l'intermédiaire de moyens de saisie de données, et des moyens d'acquisition de données capables d'élaborer des fichiers de données représentatifs des contenus desdits tableaux. 6. Système selon la revendication 4 ou 5, comprenant des moyens de reconnaissance (9) de modifications apportées au contenu des tableaux, et des moyens de prise en compte (10) des modifications. 7. Système selon l'une des revendications 4 à 6, comprenant des moyens d'alerte (16, 17) pour générer une alerte lorsque des données ont été enlevées d'un tableau ou lorsqu'un tableau a été enlevé depuis une durée supérieure à une durée de seuil. 8. Système selon l'une des revendications précédentes, dans lequel lesdits moyens d'analyse (13, 14) sont adaptés pour délivrer en sortie des informations affichable (2) sous forme de courbes en deux dimensions. 9. Procédé de gestion de la réalisation d'un logiciel informatique par une méthode agile, dans lequel on entre une valeur initiale d'un paramètre représentatif du temps estimé pour effectuer la réalisation du logiciel, et on entre de manière itérative la valeur d'un paramètre représentatif du temps estimé pour effectuer des étapes de réalisation correspondant à une itération, et on détermine un délai prévu de fin de réalisation dudit logiciel à partir desdits temps estimés, caractérisé par le fait qu'on analyse l'évolution du paramètre représentatif du temps estimé de réalisation des étapes des itérations, on analyse l'évolution au cours des itérations du délai prévu de fin de réalisation du logiciel, et on utilise une bibliothèque de données pour identifier des problèmes de réalisation en fonction de l'évolution du paramètre représentatif du temps estimé pour la réalisation des étapesdes itérations, et en fonction de l'évolution du délai prévu de fin de réalisation du logiciel.