Evaluation les théories

Selon Serge Bouchy :"L'évaluation des charges d'un projet d'ingénierie représente l'un des points d'accumulation de toute la problématique du métier. On voit déjà apparaître que l'évaluation ne peut pas être seulement liée à l'objet à produire, mais tient compte du service apporté autour de lui, de la manière de traiter le projet et du choix des ressources utilisées. De ce fait une part importante de l'évaluation peut être prise en charge par un système expert, puisqu'il s'agit bien d'une démarche où il y a rapprochement permanent entre une base de connaissances (modélisation du savoir) et une base de faits (Modélisation du faire) pour obtenir une modélisation de l'état de l'art (savoir faire)".

  • Thèse sur les Méthodes d’Estimation de Charges dans le cadre d’un projet xNet

    A l’heure où s’impose le retour sur investissement, Microsoft propulse la dernière génération d’architecture distribuée à multiples niveaux. Le gestionnaire s'aperçoit alors que les plus élémentaires outils d’estimation lui font cruellement défaut. D'ailleurs, à l'exception de l'ÉVALUATEUR, il n'existe pas actuellement d’outils de métrique de projet spécifiques au Client-Serveur, à l’objet ou à Windows. Dans la réalité, les gestionnaires s’appuient fréquemment sur une expérience décalée technologiquement et ignorent l’usage d’outils spécialisés. Les outils de conception déterminent et recensent données et traitements avec précision, mais n’évaluent pas directement la charge et les délais d'un projet. Par contre, ces informations sont la base de la plupart des méthodes d'évaluation.

    Les principes de l'Évaluateur sont identiques à ceux des - Points de Fonctions -, mais, si les P.F. évaluent grossièrement un projet, ils ne prennent pas en compte les nouveaux et nombreux paramètres affectant les conditions de sa réalisation et n'autorisent pas une finesse suffisante pour faciliter des négociations de délais, de budget et de réduction de fonctionnalités.

    Techniquement, le processus d’évaluation de projet doit être itératif. La première évaluation basée sur l’expression des besoins de la phase de CADRAGE s’affine au cours du DESIGN (spécification générale, modèle de données, règles de gestion, hiérarchie de fonctions). Il ne faudra pas négliger avant la phase de CONSTRUCTION d’effectuer une étape de recherche de solutions techniques. En effet les technologies et outils de développement récents offrent souvent des possibilités de réduire la planification dans des proportions parfois considérables.

    On introduit ensuite les contraintes logiques, temporelles et les dépendances entre activités qui permettent une planification détaillée. Le suivi consiste à partir de l’évaluation d’analyser la réalité observée, de tirer les conséquences des écarts éventuels et d’apporter les correctifs appropriés. Les outils modernes et conviviaux de gestion de projet comme MS Projet automatise ces aspects.

    Historique COCOMO

    Le tableau " facteurs de pondération COCOMO " liste les paramètres influençant l’évaluation d’un projet selon cette approche. Ces facteurs de pondération s’appliquent sur une charge calculée à partir de l’estimation du nombre de lignes utiles que devrait comprendre l’application à sa livraison. Ce type d’évaluation: s’applique difficilement à un développement utilisant des composants à base d’objets.

    Historique points de fonctions

    Les points de fonctions se basent sur l'analyse des fonctionnalités livrées à l'utilisateur. Malheureusement, si les points de fonctions permettent d’évaluer grossièrement un projet, ils ne prennent pas en compte les nouveaux et nombreux paramètres affectant les conditions de sa réalisation. COCOMO appliquait une distinction sur la complexité du programme définie en trois catégorie (simple, médium, complexe), le principe des points de fonctions distingue trois typologies de projet basées sur la plateforme de développement (mainframe, mini, micro).

    Tout ceci est éloigné des préoccupations du chef de projet RAD qui doit s'appuyer sur une modélisation globale. en phase de CADRAGE pour évaluer fonction par fonction l'investissement que représente l'application. L'évaluation est un des aspects fondamentaux du RAD. Ce thème nécessite de nombreux tableaux et des centaines de paramètres, il ne peut être raisonnablement traité que par un logiciel spécialisé.

     

    Impact technologique

    Avec la généralisation du Client-Serveur, la nature des développements ainsi que la composition des noeuds applicatifs changent fondamentalement. Cette mutation est encore plus évidente dans le nouveau concept de Microsoft : l’architecture de services distribuées à trois niveaux. La simplicité des classiques transactions de l’opérationnel (OLTP) fait place à la complexité du décisionnel (OLAP). Les types d’applications qui en découlent divergent en termes de principes de conception, de réalisation et d’exploitation (serveurs dédiés). Le nombre d’utilisateurs et les temps de réponse admissibles sont autant d’autres éléments de dissociation. Le bénéfice de la réutilisation est aussi confronté à la complexité de production de ces composants. Dans le même temps il est souvent impératif de réduire le projet en charge et surtout en délai. Le phénomène est particulièrement évident dans les applications stratégiques. Il faut alors choisir avec discernement une approche méthode, soit classique, soit Objet ou de développement rapide (RAD), en adéquation avec ces contraintes.

    Actuellement, rien ne facilite réellement l’évaluation des paramètres liés aux nouvelles architectures, technologies et méthodologies. Lorsque le projet innove simultanément dans plusieurs domaines, cette situation conduit à de dangereuses approximations. Ces évolutions techniques non clarifiées conduisent à l’inadéquation des systèmes et aux dérives majeures.

    Mesure de la complexité

    Les métriques les plus récentes s’appuient sur le nombre et la complexité des entités qui composent le modèle de données et la nature de leurs relations. On étend ce dénombrement en introduisant la notion de qualitatif aux écrans, rapports et interfaces. La complexité applicative s’évalue ensuite par l’observation des règles de gestion, d’organisation et du procédural spécifique. Parmi les autres paramètres à prendre en compte, il faut observer le degré de standardisation exigée, la qualité documentaire, la recherche de réutilisabilité, la complexité transactionnelle et les conditions de déploiement.

    Sur le plan des ressources humaines, la spécialisation est un facteur appréciable de productivité. On favorise la disponibilité ponctuelle d’expertise en développement rapide, ergonomie cognitive, documentation et administration de SGBD. Le support technique offert par des développeurs maîtrisant les subtilités des outils "visuals" et de leurs "add-ons" (VBX, OCX, Active X) est un point crucial.

    La lecture de revues spécialisées comme Visual Basic Journal fournit des solutions clés en main (tips and tricks) à des problèmes ardus et hautement techniques qui nécessiteraient des journées de recherche. Il faut aussi tenir compte du niveau de contrôle exigé sur le projet et du retour d’expérience des projets précédents (dérives positives ou négatives, réutilisation). L’impact de tous ces points est pris en compte lors d’une évaluation précise.

    Un fragile équilibre entre délais, coûts directs et formation s’obtient si la maîtrise du retour sur investissement est garantie. Ce qui implique une métrique fiable et des principes d’évaluation adaptés. C’est une évidence, l’heure des projets stratégiques et des applications "kleenex" a sonné et impose une réingénierie des procédés appliquée à la fonction informatique qui tiendra avant tout compte de multiples contraintes. L’impact de ces contraintes sur la réalisation doit être estimée.

    Modèles et techniques

    Au niveau de la conception, et particulièrement pour le décisionnel ou le stratégique, les modèles de traitement Merisiens sont avantageusement remplacés par le principe de la hiérarchie de fonctions. Les processus ainsi répertoriés deviennent plus facilement priorisables en terme de stratégie et de coûts. Parmi les nouveaux additifs aux traitements classiques, le WORKFLOW réserve une place primordiale à l’ingénierie des procédés. Le raisonnement classique en termes de données et de fonctions est insuffisant. Une vision étendue, matricielle et globaliste de l’organisation et de ses communications s’impose. La notion d’automatisation des processus, des flux et des événements s’avère la réponse idéale aux besoins de réactivité des organisations. Cette dimension additionnelle implique une surcouche de procédures dont le coût de modélisation et de développement doit être considéré.

    Afin de répondre efficacement à ces contraintes parfois contradictoires, il faut des approches de développement plus directes en termes de relations, plus homogènes en terme de phases et plus modulaire en terme de réalisation. Pour réduire la charge, on systématise l’emploi d’AGL de conception et de réalisation. Ces outils puissants et modulaires se qualifient avant tout par leur légèreté. Avec Visual Basic et ses "add-ins", la tendance s’oriente vers le couplage fort d’outils de modélisation orientés "métier" avec des moteurs Objet d’accès aux données. Les composants bénéficient de la cohérence d’un référentiel intégré et visuel permettant l’obtention automatique (Wizard) de modules préfabriqués. La réduction des délais s’organise par des sessions parallèles de développement. L’accélération du retour sur investissement incite au découpage en lots suivant les règles de l’enveloppe budgétaire appliquée à chaque fonction (design to cost). Le stratégique impose des livraisons anticipées en fonctionnalités partielles. Cette nécessité est tributaire techniquement et économiquement de l’usage généralisé d’outils de télédistribution. L’ensemble de ces éléments influe sur le quantitatif de l’effort à produire.

    Un nombre croissant d’utilisateurs intermédiaires maîtrisent la bureautique classique et les subtilités des macros. Dans les projets stratégiques, ces connaissances permettent une transition vers la bureautique communiquante. Les outils comme Word, Excel, Access offrent un langage fédérateur Visual Basic for Application et des capacités d’accéder, sans expertise exceptionnelle aux données corporatives (ODBC, OLE). Ces nouvelles capacités rendent les utilisateurs plus autonomes et exigeants. Une part non négligeable de l’effort de spécification et de recette se reporte sur la Maîtrise d’Ouvrage. Une telle osmose entre l’organisation et la technique n’est pas neutre en terme de planification et d’évaluation.

    Comme on le constate, le nombre de paramètres à estimer s’est accru. Dans cette optique, seule une métrique de projet complète permet d’éviter les développements improductifs et les dérives coûteuses. La possibilité de comparer instantanément des scénarios complexes est vitale. Pour être raisonnablement mise en œuvre, une telle opération se doit d’être simple et automatisée.

    Le futur de l'évaluation

    En amont des AGL de conception et de réalisation émergera donc un nouveau type d’AGL. Il sera dédié à la définition, l’évaluation et la planification des nouvelles architectures et technologies de développement. C'est pour cette raison que je vous propose d'utiliser le logiciel Evaluateur. Evaluateur est offert gratuitement à la communauté professionnelle. Évaluateur se base sur une évolution des travaux de Albrecht, Ashby, Boehm, Clark, Egyed, Gacek, Hoh, Lehman, Martin, Maxwell, Pareto, Parkinson, Rayleigh, Shannon, réalisée par Jean-PierreVickoff.

    A partir d'une métrique basée sur les éléments principaux du système, déterminés lors de la phase de CADRAGE, l'Évaluateur estime un nombre de points de fonctionnalités à produire (charge). Il applique ensuite à ce chiffre des facteurs de pondérations liés à votre environnement de réalisation. Ce deuxième chiffre (Unités d'Effort Pondérées) correspond à l'effort nécessaire à la production. Ceci n'est pas un nombre de jours. Le nombre de jours de travail sera déterminé par la productivité des ressources mises en œuvre. La productivité totale engagée fixera les délais de réalisation.

    Lorsque les éléments du projet sont saisis, un module de gestion des RESSOURCES propose une optimisation de la durée du projet et des ressources devant être affectées. Il tient compte de divers paramètres comme la nécessité de former des débutants, de considérer les risques inhérents à la gestion de personnel et la productivité découlant de l'expertise. On peut modifier le nombre de débutants, de confirmés ou d'experts composant une équipe de base. Une fenêtre de saisie limite le nombre de ressources en fonction des règles du RAD. Il est parfois nécessaire de réduire le nombre d'une des catégories pour pouvoir en augmenter une autre. La productivité de l'équipe est affectée par ces opérations. La durée du projet en découle. Les autres contraintes sont de deux types : DELAIS ou RESSOURCES. On peut fixer une date de départ puis appliquer une contrainte de ressources ou de temps. Il est aussi possible de fixer une date de fin pour connaître en retour la date limite de début a respecter. Une documentation en ligne explique le fonctionnement général et une aide contextuelle détaillée est associée à chaque champ. Il suffit d'une heure pour maîtriser un tel produit. A la fin de cette ouvrage, une annexe expose globalement quelques uns des paramètres pris en compte.

    Quelque soit la méthode ou l'outil, les évaluations serviront de base pour statuer sur la poursuite des travaux ; c'est-à-dire l'engagement des ressources humaines et financières nécessaires à la phase suivante du projet. Il y a néanmoins une limite à la précision de toutes les méthodes généralistes d'évaluation. Elles nécessitent d'être pondérées en fonction de conditions spécifiques de réalisation. Dans un projet en cours, un suivi réaliste est donc vital pour l'évaluation des projets suivants. Il détermine les coefficients de pondération propres à l'organisation. L'expérience des membres de l'équipe en développement RAD est ensuite déterminante.

    C'est en général après le premier ou deuxième projet qu'une équipe se rode parfaitement aux principes et outils du RAD. Dans le cas de développeurs conventionnels, l'accroissement de productivité entre les projets peut être démultiplié, particulièrement lorsqu'il se crée des templates de transactions ou de rapports (réutilisation).

    Parmi les autres causes de déperdition de performance, il faut citer des machines de développement sous-dimensionnées (surtout en terme de résolution vidéo) et un environnement réseau déficient. C'est un état de fait fréquent, particulièrement dans les sociétés où les dirigeants n'utilisent pas la bureautique communicante et où les spécialistes du réseau considèrent que tout va bien, alors que les développeurs gaspillent une part non négligeable de leur temps en attente.

     


  • www.RAD.fr ® © Jean-Pierre Vickoff