Rappels. Génie logiciel. En résumé. Planifier sur deux échelles. Risques Planification a deux échelles. Philippe Dugerdil

Transcription

1 Rappels Génie logiciel Philippe Dugerdil Risques Planification a deux échelles Project plan Iteration plan Planification basée sur les risques Notion de risque Revue d itération Planifier sur deux échelles En résumé Inception Elaboration Construction Transition Evaluer les risques Planifier le projet oui Changement des risques? Evaluer l itération jj.mm.aa jj.mm.aa non jj.mm.aa Planifier la prochaine itération 3 1

2 Répertoire des spécifications Gérer les spécifications incrémentales Avant qu elles ne vous gèrent! Contient la documentation des spécifications incrémentales Nécessaire pour la gestions des modifications de spécifications Attributs typiques Origine (qui l a demandé?) Date Etat (soumis, accepté, implanté, rejeté, ) Difficulté / effort associé Risque / impact sur l architecture Stabilité (risque que cela change?) Bénéfice attendu, pour qui? Priorité pour l utiisateur? 5 Exemple: attributs de spécifications et leur gestion dans «Requisite pro» 8 2

3 Faire simple Demande changement effectif Demandeur /mandant Chef projet RISQUES? Si on ne fait pas? Si on le fait: Impact sur les autres composants Impact sur l architecture Impact sur le planning et des priorités Suivant la situation la spécification s exprimera à l aide des outils présentés (UC, BR, contraintes techniques, NFR) ou encore description de bug Gérer les demandes et les conséquences! Mise en place d une gestion des changements Enregistrer les demandes de changement Gérer les l impact sur les specs Gérer les demandes de changement Images: Copyright (c) , Rational Software Corporation Philippe Dugerdil Image: - CUI RUP - Université 2003, IBM de Genève Corporation

4 Exemple de format simple de demandes de changement Gérer les dépendances et l impact sur le planning Date Auteur Description Priorité Status Date status & visa Responsable Traitement Problème Changement proposé Coût Impact (composant, module, système) Effort (durée, nbre ressources, ) Soumis Reporté Redondant (avec...) Rejeté En attente d'info Ouvert Assigné Résolu Erreur au test Vérifié Fermé Image: RUP 2003, IBM Corporation Nouvelle spec / changement Résumé: les contraintes sur le planning Ré-évaluer les risques Re-planifier le projet Communiquer l impact sur le planning et les livrables Re-planifier la prochaine itération 4

5 Nombre et durée des itérations f(nb use-case, risques, taille projet) Recommandations: itération courtes (agilité) Rappel: SCRUM Product backlog livrable ~2 semaines C est le mandant qui décide Avec vos conseils avisés! sprint sprint sprint sprint sprint 18 Planifier et renégocier Bonnes pratiques 1. Ne pas planifier ce qu on ne connaît pas 2. A mesure qu on avance dans les itérations on améliore sa propre capacité à planifier 3. Si on se rend compte qu on ne pourra pas livrer la totalité a. Ne pas chercher à faire des miracles b. Renégocier (ressources, délais, livrables) It is often preferable to deliver less on time than to be late [Cantor M. - Object-Oriented Project Management with UML, Wiley]

6 Typical RUP project structure Effort Durée Philippe Dugerdil Image: - CUI RUP - Université 2003, IBM de Genève Corporation