Université de Montréal Département d'informatique et de recherche opérationnelle IFT3902 Automne 2007 24 Septembre 2007 IFT3912 Développement, Maintenance de Logiciels Démo2 : Gestion de la qualité, WBS et COCOMO Professeur: Yann-Gaël Guéhéneuc Démonstrateur: Naouel Moha Étude de cas : Système de gestion Billetron On considère un système (Billetron) de vente de billets pour des spectacles de toutes sortes. Billetron fait des contrats avec des centaines de lieux de commerce où il installe un point de vente muni d un terminal. Chaque fois qu une nouvelle salle de spectacles ou d évènement sportif devient client de Billetron, les données qui la décrivent sont rentrées en ligne. Ces données permettent de localiser la salle, de préciser les catégories de places, le nombre dans chaque catégorie et beaucoup d autres informations composées. Le système ne présente pas de problèmes de programmation complexe. Il tournera sur une seule machine mais il sera extrêmement charge, certains jours, à certaines heures. On souhaite aussi que l utilisation par les vendeurs soit très facile. Enfin, les acheteurs de billets n aiment pas attendre. Ce sont les seules exigences sortant de normale. Exercice 1 : Gestion de la qualité & CMM (Capability Maturity Model) 1. Selon l étude de cas, définissez les différents critères (ou caractéristiques) de qualité auxquels le logiciel devra répondre. Pour chacun des critères définis, définir les objectifs et les niveaux de qualité et indiquer les moyens mis en œuvre pour évaluer la qualité. 2. Indiquer le niveau de maturité CMM de l entreprise de l étude de cas. Citer les éléments supplémentaires nécessaires pour atteindre le niveau supérieur. 1
Exercice 2 : WBS (Work Breakdown Structure) 1. Qu est-ce que WBS? WBS est une décomposition successive d une activité plus grande (le projet lui même) dans des activités plus petites. 2. À quoi ça sert? Nous avons besoin de WBS afin de faire des estimations de coût et de travail (effort) à faire et de développer un calendrier consistent. Estimer le coût: Estimer le coût de toutes les activités Inclure le coût des éléments dans le coût total du système Performance du calendrier: Savoir quelles activités sont finies Mesurer le progrès Étude de cas simple : La tâche consiste à implanter un mini compilateur d un sous-ensemble de C qui offre également une interface usager pour écrire le code et le compiler. 1. Identifier les activités du projet en précisant les types de décomposition 2. Allouer des ressources à chaque activité 3. Allouer du temps à chaque activité 2
Exercice 3 : COCOMO (COnstructive COst MOdel) (a) COCOMO de base En appliquant la méthode COCOMO estimer la taille moyenne de l'équipe qui faudrait prévoir pour développer un logiciel estimé à environ 40 000 instructions sources (SLOC), le projet est simple et l équipe du développement est relativement réduite. (b) COCOMO intermédiaire Soit à développer un logiciel de gestion d un système de gestion de manutention dans un atelier d assemblage de voiture (ateliers flexibles). Le système logiciel doit fonctionner sous des contraintes particulièrement fortes. Le système à développer est une partie d'un système complexe et fortement connecté de matériels et de logiciels se trouvant dans l atelier entre autre le système de pilotage des robots. Des normes et des procédures opérationnelles surtout de sécurité doivent être prises en compte. En conséquence, les modifications de spécifications destinées à contourner des problèmes logiciels sont en général impossibles et les coûts de validation extrêmement élevés. Nous avons calculé les PF de ce système. Cette tâche de comptage nous a coûté 2 jours de travail (5 heures/jour) ; la productivité de l équipe d estimation était de 200 PF/heures. Le système est développé avec les langages C et C++. Admettons qu un PF correspond à 65 lignes de code C++ et 85 lignes de code C. On prévoit que 70% du système serait développé avec C++. Les consignes données par les responsables de l atelier sont les suivantes : Une défaillance pose de sérieux problème particulièrement de sécurité. Une défaillance peut mettre en péril la vie humaine. Le système fonctionne 16h/j et 65% de la puissance matérielle disponible sera utilisée. La taille de la base de données à utiliser (en octets) est entre 8 à 10 fois le nombre de lignes sources livrées. Les conditions de développement se caractérisent par : Des outils CASE couvrant l'intégralité du cycle de vie sont disponibles. Méthode de programmation moderne, évoluée et expérimentée par l équipe de développement. La complexité du produit est très élevée à cause de traitement parallèle et gestion de données complexes. 1) Après avoir déterminé le type de projet, calculer l estimation de l effort et de la charge ainsi que la taille moyenne de l équipe en utilisant COCOMO de base. 2) Identifier les facteurs qui influencent les estimations dans ce projet ainsi que leurs valeurs respectives (voir tableau ci-dessous). 3) Calculer l effort, la durée et la taille moyenne de l équipe de développement en tenant compte des contraintes et consignes données dans le texte 3
Tableau des multiplicateurs d attributs de projet Table extraite de Boehm (1981). Notez que TB signifie très bas, B bas, M moyen, E élevé, TE très élevé et TTE très, très élevé. 1: Multiplicateurs d'attributs de projet Attributs Valeurs TB B M E TE TTE FIAB 0,75 0,88 1,00 1,15 1,40 -- DONN -- 0,94 1,00 1,08 1,16 -- CPLX 0,70 0,85 1,00 1,15 1,30 1,65 TEMP -- -- 1,00 1,11 1,30 1,66 ESPA -- -- 1,00 1,06 1,21 1,56 VIRT -- 0,87 1,00 1,15 1,30 -- CSYS -- 0,87 1,00 1,07 1.15 -- APTA 1,46 1.19 1,00 0,86 0,71 -- EXPA 1,29 1,13 1,00 0,91 0,82 -- APTP 1,42 1,17 1,00 0,86 0,70 -- EXPV 1,21 1,10 1,00 0,90 -- -- EXPL 1,14 1,07 1,00 0,95 -- -- PMOD 1,24 1,10 1,00 0,91 0,82 -- OLOG 1,24 1,10 1,00 0,91 0,83 -- DREQ 1,23 1,08 1,00 1,04 1.10 -- 4
Annexe Cocomo (Pour plus d information sur les facteurs d influence «cost drivers») Les attributs du projet sont: Fiabilité requise du logiciel (FIAB) : notée sur une échelle allant de très faible, où une défaillance ne pose pas de problème particulier, à très élevée, où une défaillance met en péril la vie humaine, en passant par moyenne, où une défaillance est la cause de pertes recouvrables. Taille de la base de données (DONN) : notée de faible, où la taille de la base de données (en octets) est moins de dix fois le nombre de lignes sources livrées, à très élevée, où la taille de la base de données est plus de mille fois plus grande que le programme, en passant par moyenne, où la taille de la base de données est entre dix et cent fois la taille du système. Complexité du produit (CPLX) : notée sur une échelle allant de très faible à très élevée. Les produits de complexité faible utilisent des opérations d'e/s (entrées/sorties) simples, des structures de données simples et du code «linéaire». Les produits de complexité moyenne utilisent des opérations d'entrées/sorties évoluées, plusieurs fichiers, des procédures de bibliothèque et des communications entre modules. Une complexité élevée peut signifier: traitement parallèle, gestion de données complexes etc. Les attributs de l'environnement matériel et logiciel sont les contraintes de temps d'exécution et d'espace mémoire qui affectent la productivité. Il y a quatre attributs de ce type: Contraintes de temps d'exécution (TEMP): noté de moyen à très élevé. Moyen signifie que 50% de la puissance disponible sera utilisée, très élevé signifie que 95% de la puissance disponible sera utilisée. Contraintes d'espace mémoire (ESPA) : noté de la même manière que TEMP. Volatilité de la machine virtuelle (VIRT) : la machine virtuelle est la combinaison de matériel et de logiciel sur laquelle le produit logiciel est développé. Ce facteur sera noté faible si cette machine n'est modifiée «qu'occasionnellement (une fois par an), moyen si elle est modifiée tous les six mois et très élevé si elle est modifiée toutes les deux semaines. Contraintes du système de développement (CSYS) : notée de très faible pour le développement à l'aide d'un système interactif, à très élevée pour un système non interactif et peu disponible. Cinq attributs du personnel sont pris en compte afin de refléter l'expérience et l'aptitude de l'équipe de développement travaillant sur le projet. Ces attributs sont: l'aptitude à l'analyse (APTA), l'expérience dans le domaine d'application (EXPA), l'expérience de la machine virtuelle (EXPV), l'aptitude à la programmation (APTP) et l'expérience du langage de programmation (EXPL) Ils sont tous notés de très faible, qui signifie peu ou pas d'expérience au très élevé qui signifie plus de trois ans d'expérience, en passant par moyen, qui signifie au moins un an d'expérience. Les attributs du projet sont liés à l'utilisation d'outils, au contrôle de l'avancement du projet et à l'utilisation de méthodes de 5
programmation modernes telles que la conception fonctionnelle descendante, les revues de conception et de codage, la programmation structurée, etc. Les attributs du projet sont les suivants: Méthodes de programmation modernes (PMOD) : noté de très faible, en l'absence de méthode, au très élevé lorsque la méthode est évoluée et l'équipe expérimentée dans son utilisation. Outils logiciels (OLOG) : la disponibilité d'outils logiciels peut avoir un impact significatif sur l'effort nécessaire au développement d'un système. Cette disponibilité est notée de très faible lorsque seuls des outils très primitifs, tels que des assembleurs, sont utilisés, à très élevée lorsque des outils couvrant l'intégralité du cycle de vie sont disponibles. Durée requise du développement (DREQ) : cet attribut mesure l'écart entre la durée de développement de la durée obtenue avec le modèle COCOMO simple. Une valeur très faible signifie une durée écourtée, alors qu'une valeur très élevée signifie une durée rallongée. Des valeurs élevées ou des valeurs faibles impliquent toutes deux un effort de développement supplémentaire. 6