Université du Québec École de technologie supérieure Département de génie de la production automatisée GPA777 Introduction au génie logiciel Chapitre 2 Monitoring et mécanismes de révision Copyright, 2000 Tony Wong, Ph.D., ing. 1 Monitoring (1) Le monitoring est appliqué après avoir créer le plan du projet. Son rôle est de contrôler l avancement des travaux en fonction du plan établi. Le but est de s assurer le respect des échéanciers du projet. 2 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 1
Monitoring (2) Il existe plusieurs façons de réaliser le monitoring: Rencontres périodiques sur l état du projet; Discuter et présenter la progression et les problèmes rencontrés. Évaluation de toutes les révisions réalisées durant le processus de développement (la révision logicielle est présentée dans les pages suivantes). 3 Monitoring (3) Déterminer l état du projet en fonction des milestones et des dates importantes du projet. Les milestones et les livrables sont des balises importantes du projet. Les problèmes de développement sont souvent manifestés par le non respect de ces balises. Comparer la date de départ réel des travaux avec celle indiquée dans le diagramme de Gantt. Souvent, le départ tardif des travaux est un symptôme qu il faut surveiller. 4 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 2
Monitoring (4) Rencontre informelle et ponctuelle avec les membres de l équipe de développement. Ces rencontres informelles peuvent aider à déceler les problèmes avant leurs manifestations. Que faire lorsqu il y a problème dans le respect des échéanciers? Si le problème est mineur: Allocation supplémentaire des ressources; Réajustement du plan du projet; Modification de l horaire des travaux. 5 Monitoring (5) Que faire lorsqu il y a problème dans le respect des échéanciers? Si le problème est majeur: Adopter le processus incrémental pour le développement: Itération #1 Analyse Conception Codage Test Livraison de l'itération #1 Itération #2 Analyse Conception Codage Test Livraison de l'itération #2 Itération #3 Analyse Conception Codage Test Livraison de l'itération #3 6 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 3
Monitoring (6) En reconnaissant que le produit ne peut être livré à temps: Un nouveau horaire est établi en utilisant le modèle de développement incrémental. Le but est de produit un livrable à la fin de chaque itération. Chaque activité du processus est surveillée. Lorsqu une activité est à ±10% de son échéancier, on passe immédiatement à l activité suivante. Le livrable à la fin d une itération n est pas complet mais deviendra à la fin des autres itérations. 7 Révision formelle (1) Les révisions techniques formelles (FTR) sont des «filtres» appliqués au processus du génie logiciel [SOMM97]. Elles sont appliquées à différentes étapes du processus pour découvrir les erreurs et de les éliminer. Elles sont qualifiées formelles parce qu il existe des procédures précises qui encadrent leur déroulement. 8 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 4
Révision formelle (2) Les objectifs d un FTR: Découvrir les erreurs; vérifier que le logiciel satisfait les exigences; assurer que le logiciel est développé selon les standards établis; rendre le projet de développement plus facile à gérer. Les FTR sont aussi connues sous le nom de: Inspection, «walkthrough», «round-robin review» 9 Révision formelle (3) La composition des FTR: Membres de l équipe de développement, les gestionnaires et parfois les clients et le département de marketing. Le format des FTR: Réunion officielle. Le nombre de participants: De 3 à 7 personnes; le chef réviseur, les réviseurs, le producteur du module à réviser. 10 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 5
Révision formelle (4) La durée: Moins que 2h. La préparation: Un ordre du jour; le matériel à révisé est envoyé au préalable aux réviseurs; L étendue des FTR: Porte sur un ou deux modules logiciels à réviser; de cette façon, la préparation des réviseurs est minimisée. 11 Révision formelle (5) Le rôle des participants: Réviseurs Producteur Chef réviseur Réviseur secrétaire Marketing Producteur: responsable du module à réviser. Chef réviseur: coordonne le déroulement des FTR. Réviseur: Étudier le module à réviser et soulever des points à débattre d une manière impartiale. Réviseur-secrétaire: Noter par écrit les points invoqués. 12 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 6
Révision formelle (6) Le déroulement d une FTR : Le responsable d un module logiciel (le producteur) constate la fin des travaux de son module; il contacte le gestionnaire du projet pour lui faire part de son désir de réviser son travail; le gestionnaire contacte le chef réviseur; ce dernier prépare un dossier technique sur le module (avec l aide du producteur) et l achemine aux réviseurs; les réviseurs sont normalement les autres membres de l équipe de développement; 13 Révision formelle (7) les réviseurs étudient le dossier (normalement cette activité prend moins que 2h); À la réunion: Un des réviseur est désigné comme réviseur - secrétaire; le producteur effectue une présentation de son module (le «walk through») et explique les détails de son fonctionnement; les réviseurs et le producteur s engagent pour une période de Q&A (Questions et réponses); 14 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 7
Révision formelle (8) À la fin d une FTR: Les participants doivent décider: Accepter le travail sans modification; rejeter le travail (problème majeur); Le travail doit être réviser de nouveau. Accepter provisoirement le travail (problème mineur) Il n y a pas lieu de réviser à nouveau le travail. Signature d un document attestant la participation des personnes et la conclusion de la FTR. 15 Révision formelle (9) Rapports découlant des FTR: À l aide des notes prises par le réviseur - secrétaire, deux documents devront être produits: Une liste de litiges; un sommaire de révision. Sommaire de révision: 1 page; décrivant le travail révisé; le responsable du travail; les constatations et la conclusion. 16 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 8
Révision formelle (10) Liste des litiges: Liste des problèmes relevés; les correctifs à apporter; La liste des litiges est attachée au sommaire de révision. Le document est distribué aux gestionnaires et aux membres de l équipe de développement. Le document constitue une entrée dans l historique du processus de développement. 17 Révision formelle (11) Les problèmes relevés dans la liste des litiges: Ils sont à corriger par le producteur; le suivi est réalisé par le chef réviseur et/ou par le département QA (Assurance de qualité). Quelques heuristiques pour encadrer les FTR: Réviser le travail et non le producteur!! Il est essentiel d avoir un ordre du jour qui est succinct. 18 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 9
Révision formelle (12) Le chef réviseur joue le rôle de modérateur pour limiter les débats aux points du jour. Tous les participants doivent prendre des notes écrites (black book). Limiter le nombre de participants. Réviser les révisions effectuées précédemment pour déceler les omissions. Pour connaître davantage sur les FTR: http://satc.gsfc.nasa.gov/fi/fipage.html 19 Fin du chapitre 2 Ø Références: [SOMM96] Sommerville, I., Software Engineering. Harlow, England : Addison-Wesley, 1996. [PRES97] Pressman, R. S., Software Engineering, A practitionner s approach. New York : McGraw-Hill, 1997. [HTTP01]http://studentweb.tulane.edu/~mtruill/devpert.html [HTTP02]http://www.eob.org/gantt.htm [HTTP03]http://www.fit.qut.edu.au/ILE/ile/Subjects/ITB421 /Bridge/3gl.htm#topic2a 20 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 10
Fin du chapitre 2 Ø Références: [ROYC70] Royce, W. W., «Managing the development of large software systems: concepts and techniques,» Proc. IEEE WESTCON, pp. 1-9, 1970. [BRAD94] Bradac, M., Perry, D., Votta, L., «Prototyping a process monitoring experiment,» IEEE Trans. Software Engineering, vol. 20, no. 10, pp. 774-784, oct. 1994. [BRAD94] Butler, J., «Rapid Application Development in action,» Managing Sys. Dev., Applied Computer Research, vol. 14, no. 5, pp. 6-8, mai 1994. 21 Fin du chapitre 2 Ø Références: [BEOH88] Boehm, B., «A spiral model for softeware development and enhancement,» Computer, vol. 21, no. 5, pp. 61-72, mai 1988. [HTTP04]http://sunset.usc.edu/research/COCOMOII/cocomo_m ain.html 22 Département de génie de la production automatisée - Tony Wong, Ph.D., ing. 11