Up1

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Favorites, Groups & Events

    Up1 - Presentation Transcript

    1. UP-XP Process unifié Agilité
    2. Demander le programme (1)
      • LE PROCESSUS UNIFIE
      • Un processus itératif et incrémental.
      • Un processus piloté par les exigences utilisateurs.
      • L'architecture à base de composants.
      • La modélisation graphique UML.
      • La qualité du logiciel.
      • Le contrôle des changements.
      • LES PHASES DU PROCESSUS UNIFIE
      • La phase d'inception.
      • La phase d'élaboration.
      • La phase de construction.
      • La phase de transition.
      • LES CONCEPTS DU PROCESSUS UNIFIE
      • Les rôles.
      • Les activités et leurs enchaînements.
      • Les produits tangibles.
    3. Demander le programme (2)
      • LES ACTIVITES DU PROCESSUS UNIFIE
      • La modélisation métier.
      • La gestion des exigences.
      • L'analyse et la conception.
      • L'implémentation
      • Les tests.
      • Le déploiement.
      • La gestion de projet et l’environnement de développement
      • La gestion de la configuration et des changements.
      •  
      • IMPLEMENTER LE PROCESSUS UNIFIE
      • La configuration.
      • La planification des itérations.
      • Les guides méthodologiques.
      • Les modèles de documents.
      • VERS LES METHODES AGILES
      • Les concepts.
      • EXtreme programming : un exemple de méthode agile.
    4. Plan du cours Industrialisation des processus
      • La gestion de projet classique
      • Les nouveaux concepts
      • Unified process
      • Vers l’agilité
      • Les tests (UP-XP)
      • Autres outils indispensables (UP-XP)
    5. UP-XP Introduction Gestion de projet Les concepts de base (OO & UML)
    6. Industrialisation
    7. Les 4 axes d’un processus
    8. Exemple de processus
    9. Processus : définition
      • Le processus est une déclaration plus ou moins organisée, plus ou moins formelle, dont un groupe ou un individu va s’y prendre pour livrer la solution à une demande ou à un problème.
      • C’est en général une approche que l’on peut réutiliser lorsque le problème ou la demande est répétitif.
    10. Mise en place d’un processus (SEI)
    11. Gestion de projet classique (1)
      • Phase Préliminaire  : la réflexion sur l’intérêt du projet en lui-même, en terme d’opportunité stratégique, suivant la manière dont se présente l’avenir …
      • Jalon de Lancement du projet : on décide (au niveau “politique”) qu’il y a lieu de lancer un projet spécifique, et on y consacre un chef de projet, une équipe, des moyens, un responsable et un budget.
      • Phase d’Expression du besoin  : la définition de ce que l’on attend (les fonctions attendues), le périmètre, ce sur quoi on va évaluer le projet, ce qui est important et ce qui l’est moins.
      • Jalon de Validation du besoin  : le client valide l’expression de ses besoins (ainsi les évolutions dans l’approche des besoins pourront être tracées et justifieront d’éventuels ajustements du plan projet), ce sont les bases sur lesquelles le projet va être bâti.
      • Phase de Faisabilité  : l’étude de ce qui est techniquement et économiquement faisable. Consultation des maîtres d’œuvres possibles, comparaison des propositions techniques et financières des réalisateurs possibles.
      • Jalon du Choix de la solution  : signature du contrat qui précise ce qui sera fait et la manière de le faire.
      • Phase de Développement  : le maître d’œuvre coordonne les travaux sur le “produit papier”, pour préciser ce qui doit être fait jusqu’au dernier boulon.
      • Jalon de Lancement du chantier (éventuel) : quand le “produit papier” est suffisamment défini, on peut faire le point avant de lancer les travaux de réalisation.
      • Phase de Réalisation  : le chantier est lancé, les travaux avancent pour transférer le “produit papier” dans le réel.
      • Phase de Vérification (qui peut commencer très tôt, sur le “produit papier”) : sur le produit réel ou sur le produit papier, on vérifie (ou on calcule) que les caractéristiques attendues sont bien au rendez-vous (avec les écarts éventuels, qu’il faut alors gérer).
      • Jalon de Qualification  : après vérification, la définition de référence du produit est la bonne et ne sera plus modifiée (du moins, pas aussi facilement).
      • Jalon de Livraison (et recette) encore appelée Acceptation  : on remet le produit entre les mains du client, qui en devient propriétaire (et peut émettre des réserves sur les écarts constatés). C’est la fin du projet proprement dit.
      • Phase d’Exploitation , qui commence le plus souvent par la levée des réserves, et voit la fin de la relation contractuelle.
    12. Gestion de projet classique (2)
    13. Le cycle en V (Cascade)
      • Winston Royce (1970)  Walker Royce (1990)
      V
    14. Les normes de gestion de projet
      • L' ISO 10006:2003 donne des conseils sur l'application du management de la qualité aux projets.
      • Elle est applicable à des projets de complexité variable, qu'ils soient petits ou grands, de courte ou longue durée, qui se situent dans des environnements différents, quel que soit le type de produit ou de processus de projet. Il peut être nécessaire d'adapter ces conseils à un projet précis.
      • L'ISO 10006:2003 ne constitue pas un guide pour le «management de projet» en lui-même, mais se contente de donner des conseils sur la qualité dans le cadre des processus de management de projet alors que l'ISO 9004 donne des conseils sur la qualité dans le cadre des processus relatifs au produit du projet et sur l'«approche processus».
      • Il convient de noter que la présente Norme internationale est un recueil de conseils et qu'elle n'est pas destinée à être utilisée pour des besoins de certification/enregistrement.
      • Gérer les risques
      • Gérer le projet
        • Estimer les charges
        • Planifier
        • Suivre l’avancement
      • Gérer les modifications
      • Gérer la communication
      Les activités de management de projet Des activités de gestion pour… piloter !
      • Définir le rythme
      • Lancer la production
      • Tout au long du projet :
        • Déclenchement des autres activités du projet
      • Suivre l’avancement selon le cadencement défini
      • Réaliser le suivi financier selon le cadencement défini  
      • Préparer la tenue de chaque réunion
      • Tenir la réunion
      • Mettre en œuvre les décisions de pilotage 
      • Rapporter aux instances de contrôle
      Les activités
      • Objectifs
        • De réduire la criticité des risques potentiels
        • Réduire l’impact des risques avérés
      • Risques couverts
        • Mauvaises surprises quant à l’atteinte des objectifs projet
      • Points essentiels
        • Identifier les facteurs d’insuccès
        • Préparer et faire aboutir les actions préventives et palliatives
      Gérer les risques
      • Principe :
        • Une attitude permanente de mesure et de pilotage
      • L’aboutissement
        • Budgétiser chaque type d’activité de chaque phase
        • Budgétiser
          • Les coûts directs
          • Pour tous les produits de la phase en cours
      • La règle d’or
          • « ON PRODUIT DES JOURS * HOMMES BUDGETES »
          • « ON DEPENSE DES JOURS * HOMMES CONSTATES »
      Estimer
    19. Estimer pour Planifier La méthode des trois wagons (BCG) Hiérarchisation des fonctions CoCoMo PERT …… .
      • Comparer 2 à 2 chaque fonction
      • A chaque comparaison est associé un poids variant entre 1 et 3 (1 signifiant peu de différence)
      • Exemples :
        • F2 est plus importante que F1 avec un poids relatif de 1
        • F4 est plus importante que F1 avec un poids relatif de 2
      • Poids de la fonction 5 :
        • Somme de toutes les cases orangées (1+1+1+1)
      • Poids de toutes les fonctions :
        • Somme de tous les poids de fonction
      • Poids relatif de la fonction 5 :
        • 4 / 27 = 14,80 %
      • Hiérarchie des fonctions
      Hiérarchiser les fonctions No.
      • La fonction F6 représente 30 % du budget du projet pour un poids de 3,7 %
        • Améliorer le coût de la solution, ou
        • Supprimer la fonction du périmètre
      Déterminer la valeur des fonctions
      • La fonction F4 représente 5 % du budget pour un poids de 29,66 %
        • Intégrer cette fonction dans le périmètre minimal
    22. Planifier avec Fibonacci Plus c’est compliqué et plus ça ….. Et si c’est encore plus compliqué alors ça ….. Encore plus
    23. Cocomo : un outil
    24. Cocomo : Les résultats ACT DET
    25. Planifier méthode prédictive
      • Gant, Temps, €, ….
    26. Suivre l’avancement et on réagit …
      • Objectifs
        • Maîtriser le produit, ses coûts et ses délais
        • Offrir au client la flexibilité appropriée
      • Risques couverts
        • Dérives
        • Insatisfaction client
      • Points essentiels
        • Étudier l’impact de toute demande de modification sur le produit, ses coûts et ses délais de développement
        • N’engager la modification qu’après décision du responsable du projet
      Gérer les modifications
      • Recevoir une demande de modification
      • Évaluer la demande
      • Décider
      • Réaliser la demande
      • Clore la demande
      • Modifier
        • Les produits
        • Les pratiques
        • Les ressources
      Gérer les modifications No.
    29. PERT
      • On est le 16/12/2008 (total des taches = 8 mois)
      • Quelle sera la date du mariage, dans 8 mois => 16/08?
      • Quelles sont les tâches critiques ?
      • Trouver la date de début au plus tard de chacune des tâches
      Tâches Durée RV Mairie 15 Choix de la date Réserver une salle 60 DJ 15 Dépend de la salle Traiteur 30 Dépend de la salle Faire part 30 Envoyer FP 1 Réponses FP 30 Robe 60
    30. Correction Trouver les dates de début Au plus tard
    31. Les Méthodes classiques : Conclusion(1) « La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch
    32. Les Méthodes classiques : Conclusion(2)
      • On est également en droit de se poser les questions suivantes :
      • · L’approche prédictive du BTP est-elle adaptée au monde du logiciel ?
      • · Si certains aspects de ce processus échouent de façon récurrente, n’est-ce pas parce que ceux-ci ne sont pas abordés correctement ?
      • · Définir le rôle du chef de projet et le cantonner dans une attitude réactive est-elle la bonne approche?
      • . Qu’en est-il des membres de l’équipe de développement ?
    33. UP-XP Les concepts de base
    34. Programmation fonctionnelle
    35. Programmation objet Programme principal o1 o2 o3 o4 o5 new fqq
    36. Les concepts Objet
      • Abstraction : Classe
      • Encapsulation
      • Héritage
      • Polymorphisme
    37. Pourquoi l’objet ?
    38. Fonctionnel versus Objet
    39. Un modèle : Définition Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose (petit robert) Top Model
    40. UML : La genèse DOC-PDF UML1.3 = 4,7MB DOC-PDF UML2.0 = 5.8 MB 2003 2.0 Booch-93 Rumbaugh( OMT2) Oct-95 0.8 Jacobson (use case - sdl) Juillet-96 0.9 Janv-97 1.0 Nov-97 1.0 Sept-97 1.1 (OMG) 2000 1.4
    41. Taille des projets
      • 1-2 ans & 6-12 personnes  Couper les projets
    42. UP-XP UP - RUP
    43. UP : La base PU est à base de composants PU utilise UML PU est piloté par les cas d’utilisation PU est centré sur l’architecture PU est itératif et incrémental
    44. UP & RUP Unify Process (Énorme process pour tous) RUP Rational Unify Process Process customisé à partir du UP C'est un outil (site web, customisable) Custom AirFranceUP
    45. RUP : La genèse
    46. UP
    47. RUP : Principes
    48. Les artefacts
      • Activité de gestion de projet
        • Comptes rendus, planning d’activité, ….
      • Résultats
        • Modèles
        • Code source
        • Spécifications
        • … ..
    49. Les rôles
      • Les analystes (exigences)
      • Les développeurs
      • Les testeurs
      • Les managers (gèrent le processus)
      • Le chef de projet
      • Les autres (Client, MOA, stakeholder, ….)
    50. Les activités
      • Modélisation métier
      • Les Besoins
      • Analyse et conception
      • Implémentation
      • Tests
      • Déploiement
      • Gestion de configuration
      • Gestion du projet
      • Environnement
      Etudié plus tard
    51. BPM
    52. Modélisation métier Stéréotypes UP Fournisseur Les process Les objets de L’entreprise Client Les employés business use case
    53. Modélisation métier Artefacts et rôles
      • Rôle : Business Process Analyst
      • Artefacts :
        • Business Glossary
        • Business Use case Model
    54. Les besoins
      • Les exigences
      • Les cas d’utilisation +
      • Le document supplémentaire (architecture)
    55. Gestion des exigences http://www.alm.tv/permalink/1734/sameliorer-sur-la-gestion-des-exigences-un-premier -pas-vers-lindustrialisation.aspx
    56. Gestion des exigences Artefacts et rôles
      • Rôle : System Analyst (qui connait le métier)
      • Artefacts :
        • Supplementary Specifications : Document recensant toutes les exigences qui ne peuvent pas être capturées par les UC. Exigences non fonctionnelles ou transversales (performance, sécurité, contraintes légales, standards d’entreprise, ….
        • Use case Model : ce modèle central du RUP concerne les exigences fonctionnelles des utilisateurs
        • Glossaire
        • Business case et vision : ROI du projet
        • Risk list
        • Proto d’IHM
    57. Les grands types d’exigences
      • exigences fonctionnelles
      • exigences opérationnelles
      • exigences de performance
      • exigences d’architecture
      • exigences d’interface
      • exigences de construction
      • exigences de données
      • exigences de qualité
    58. Gestion des exigences : Processus
    59. Gestion des exigences : Outils
    60. Gestion des exigences : CaliberRM
    61. Use Case : Exercice Une société de vente par correspondance vous demande de développer son système informatique. Ce système doit pouvoir prendre en compte des commandes passées par la poste et des commandes passées par internet. Il doit suivre les expéditions qui ne sont effectuées que si le paiement est OK. Les paiements se font par carte bancaire dans le cas d'internet et par chèque dans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Le nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article atteint un seuil minimal, alors il faut passer une nouvelle commande au fournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stock disponible, l'expédition est faite par un robot existant au quel il suffit de passer les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client.
    62. Analyse (1) Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions
    63. Analyse (2) Boundary-Controleur-Entité (1) Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement
    64. Analyse (2) Boundary-Contrôleur-Entité (2)
    65. Analyse (2) Boundary-Contrôleur-Entité (3)
    66. Conception (1)
    67. Conception (2)
    68. Architecture
      • Exemple : persistance JAVA
        • Mapping Objet-Relationnel
        • JDBC
        • Serialization
      • Découpe des modules (Composants)
      • Travail de l’architecte
        • Input : Document spécifications supplémentaires
        • Trouver une solution technique
        • Maquette, validation de la solution
        • Formation, explication, exemples
        • Validation des résultats
    69. Example: Incorporating JDBC Steps
      • Provide access to the class libraries needed to implement JDBC
        • Provide java.sql package
      • Create the necessary DBPersistentClasses
        • Guideline: One DBPersistentClass per persistent class
      • Incorporate DBPersistentClasses into the design
        • Allocate to package/layer
        • Add relationships from persistence clients
      • Create/Update interaction diagrams that describe:
        • Database initialization
        • Persistent class access: Create, Read, Update, Delete
    70. JDBC: Static View ResultSet getString() : string (from java.sql) Connection createStatement() : Statement (from java.sql) DriverManager getConnection(url, user, pass) : Connection (from java.sql) DBPersistentClass create() : PersistentClass read(searchCriteria : string) : PersistentClassList update(c : PersistentClass) delete(c : PersistentClass) 1 1 PersistenceClient (from SamplePersistence Client) PersistentClass getData() setData() command() new() (from SamplePersistentClass) PersistentClassList new() add(c: PersistentClass) (from SamplePersistentClass) 0..* 1 0..* 1 Roles to be filled by the designer applying the mechanism Statement executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int (from java.sql)
    71. JDBC : Read : Connection : Statement : ResultSet : PersistenceClient : DBPersistent Class : PersistentClass : PersistentClassList 1. read(string) 1.1. createStatement( ) 1.2. executeQuery(string) 1.4. new() 1.5. getString( ) 1.6. setData( ) called for each attribute in the class returns a Statement 1.3. new( ) Create a list to hold all retrieved data 1.7. add(PersistentClass) Add the retrieved course offering to the list to be returned Repeat these operations for each element returned from the executeQuery() command. The PersistentClassList is loaded with the data retrieved from the database. The SQL statement built by the DBPersistentClass using the given criteria is passed to executeQuery() The criteria used to access data for the persistent class
    72. JDBC Read : Example de code public void Read (String critere){ //SELECT FROM `A` WHERE nom = 'Sylvie' ; Statement statement; String SQL = "SELECT * FROM `A`" + critere + ";"; System.out.println(SQL); try { statement = conn.createStatement(); ResultSet resultset = statement.executeQuery(SQL); while (resultset.next()) { String id, nom, sexeString; int age; boolean sexe = true; id= resultset.getString(1); nom = resultset.getString(2); age = resultset.getInt(3); sexeString = resultset.getString(4); if (sexeString == "F") sexe = false; A a =new A (nom,age, sexe); a.Afficher(); // Il ne reste plus qu'a mettre ces objets ds la liste // et rendre le liste } } catch (SQLException ex) { // handle any errors System.out.println("SQLException: " + ex.getMessage()); System.out.println("SQLState: " + ex.getSQLState()); System.out.println("VendorError: " + ex.getErrorCode()); } }
    73. BD
    74. Architecture : Composants
    75. Architecture : Déploiement
    76. Analyse et conception Artefacts et rôles
      • Rôles :
        • Software Architect : Architecte
        • Designer : Programmeur, Analyste
        • Data Designer
      • Artefacts :
        • Software Architecture
        • Design Model
        • Deployment model
        • Data model
    77. Implémentation
    78. Implémentation Artefacts et rôles
      • Rôles :
        • Software Architect : Architecte
        • Implementer : Programmeur, Analyste
        • Integrateur
      • Artefacts :
        • Implementation model
        • Build (les sources et autres ressources)
    79. Autres activités (1) Artefacts et rôles
      • Déploiement :
        • Rôle : Deployment manager
        • Artefacts : Deployment plan, Product
      • Tests
        • Rôle : Test Designer
        • Artefact : Test plan , Test suite (source des tests)
      • Environnement :
        • Role : process engineer
        • Artefact : Development case (process customisé), guidelines, Development infrastructure (machines et outils)
    80. Autres activités (2) Artefacts et rôles
      • Gestion de configuration :
        • Rôle : Change control manager
        • Artefacts : Project repository (bd de tous les artefacts du projet), Change Requests (gestion des DM et des RT)
      • Gestion de projet
        • Rôle : Project manager
        • Artefact :
          • Software development plan (planning global mis à jour après chaque itération), il contient les tâches à réaliser et les ressources associées.
          • Iteration plan
    81. Les meilleurs pratiques
      • Développer itérativement;
      • Gérer les exigences;
      • Utiliser une architecture à base de composants;
      • Modéliser visuellement;
      • Vérifier continuellement la qualité;
      • Gérer les changements.
    84. Phase d’inception
      • Objectifs
        • Comprendre le périmètre du projet
        • Étudier la rentabilité du projet
        • Adhésion des intervenants
        • Décision de continuer
      • Jalon LCO (LifeCycle Objective)
        • Objectifs définis
    85. La phase d’élaboration
      • Objectifs
        • Réduire les risques techniques majeurs
        • Créer une architecture de référence
        • Comprendre les éléments nécessaires à la construction du système
      • Jalon LCA (LifeCycle Architecture)
        • Architecture définie
    86. La phase de construction
      • Objectifs
        • Construire la 1ère version opérationnelle du produit, puis les suivantes ….
        • Chaque itération révise et étend (en les stabilisant) les produits de la phase d’élaboration
      • Jalon IOC (Initial Operational Capability)
        • Première version exploitable
        • De nouveaux produits sont créés
    87. La phase de transition
      • Objectifs
        • Construire la version finale du produit et la livrer au client
        • Former les utilisateurs
        • Exécuter des tests
        • Préparer le lancement du produit
      • Jalon PR (Product Release)
        • Livraison finale
    90. Organisation des modèles (UP) Les sources Les UC realization (Documentation) Les composants (physiques et logiques) Les machines Définition des besoins VOPC
    91. Phases et Activités
    101. RUP : Ses forces
      • Cadre générique
      • Référentiel de bonnes pratiques;
      • Gestion des risques dans les projets;
      • Cadre propice à la réutilisation;
      • Approche basée sur l’architecture;
      • Traçabilité à partir des Uses Cases jusqu’au
      • déploiement.
    102. RUP : Ses faiblesses
      • Coût de personnalisation souvent élevé;
        • Autres logiciels propriétaires (Rational) indispensables;
      • Très axé processus :
        • peu de place pour le code et la technologie ;
      • Vision non évidente ni immédiate:
      DEVELAY Isabelle EDORH-A. Semeho GUIBOUT Nicolas
    103. RUP : Conclusion
      • RUP considéré comme:
        • un framework de processus génériques;
        • un métaprocessus;
      • Démarche itérative
        • Réduction des risques;
      • Facile à expliquer et à valider (les livrables);
      • Finalement pas très populaire…
      DEVELAY Isabelle EDORH-A. Semeho GUIBOUT Nicolas
    104. UP-XP Vers les méthodes agiles XP Scrum
    105. Qu’est ce qu’une méthode agile
      • Deux caractéristiques fondamentales
        • Adaptatives plutôt que prédictive
          • Favorables au changement
          • Planification plus souple
        • Orientée vers les personnes plutôt que vers les processus
          • Travailler avec les spécifités de chacun
          • responsabilité
    106. Le manifeste agile
    107. Les méthodes agiles
    108. Les 4 valeurs de XP (1)
      • Communication
      • FeedBack
      • Simplicité
      • Courage
    109. Les 4 valeurs de XP (2)
      • Communication
      • XP intègre réellement le client au projet pour qu'il définisse mieux ses besoins, arbitre les priorités et apporte ses connaissances métier à l'équipe.
      • XP fait travailler tous les développeurs ensemble et les fait participer à toutes les activités du développement, créant ainsi une réelle dynamique d'équipe.
      • XP rend accessible à tous les intervenants l'ensemble des indicateurs d'avancement du projet.
      • • Feedback
      • XP fournit des livraisons régulières au client pour lui permettre d'affiner et de compléter la définition de ses besoins à partir de données concrètes.
      • XP met en place des batteries de tests d'acceptation qui mesurent concrètement l'avancement des développements.
      • XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui détectent instantanément toute régression.
      • • Simplicité
      • XP s'assure que seules les fonctionnalités demandées par le client sont implémentées.
      • XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et conserver une grande vitesse de développement tout au long du projet.
      • • Courage
      • XP donne au jour le jour une transparence maximale sur l'état d'avancement réel du projet.
      • XP s'attaque aux problèmes dès qu'ils se présentent, en autorisant des retours en arrière s'ils sont nécessaires.
    110. Les principes de base B.Vinot
      • Seul le code source fait foi, il possède une odeur
      • L’important c’est le programmeur
      • Faire le plus simple possible
      • Restructurer dès que nécessaire
      • Pratiquer la programmation par paire
      • Les spécifications sont des « histoires d’utilisateurs »
      • La planification est un jeu
      • Livrer fréquemment
      • Tester encore, toujours et tout le temps
      • Être courageux
    111. Le chef de projet Agile la qualité essentielle du leader sera le charisme plus que l’autorité.
    112. Le cycle de l’agilité
      • Les 3 rythmes :
      • Le rythme du projet
      • Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet.
      • Le rythme journalier, qui montre la progression au sein de l’itération.
      • Ces rythmes suivent la même progression :
      • préparation,
        • Une idée claire (sinon précise) de l’objectif à atteindre.
        • Une façon de vérifier que la réalisation atteint l’objectif.
      • réalisation (laisser faire l’équipe)
      • retour d’expérience ,
      • adaptation.
    113. User story
      • Taille : carte postale
      • Ecrite par le client
      • N’est qu’un résumé
      • Le reste est verbal
      • Affectation d’une priorité
      • Affectation sur une itération
      • Ecriture des tests finaux
      le client L’équipe de dvp
      • Affectation d’un coût
      • Découpage en tâches
      • Affectation sur une itération (voir partielle)
      • Prise de responsabilité d’un développeur pour
        • une tâche
      • Discussion avec le client
      • Réalisation en binôme
      • Ecritures des TU
      • Passage des tests finaux
    114. Exemple Scrum : Une release UC User story Planning game DVP Tests Le client est dans la salle
    115. Les tâches à faire (le radiateur)
    116. Stand up meeting
      • Tous les jours 15 mn
      • Toute l’équipe
      • Chacun doit dire (15/6 = 2mn30s)
        • Les problèmes qu’il a eu la veille si ils ne sont pas résolus
        • Ce qu’il pense pouvoir faire aujourd’hui
      • On est pas là pour résoudre les pb, mais
        • pour les faire connaitre,
        • prendre un RV ds la journée avec le sauveur
        • si il n’y a pas de sauveur, il faudra réestimer la tâche.
      • Mise à jour du planning journalier (Sprint) et de la liste des PB
      • Si plusieurs équipes scrum de scrum (entre scrum masters)
    117. Stand up meeting : Objectifs
      • Evaluer l'avancement du travail
      • Identifier les obstacles(problèmes) nuisant à la progression
      • Garder l'équipe concentrée sur l'objectif du sprint
      • Améliorer l'esprit d'équipe
      • Permettre une communication objective sur l'avancement
    118. Stand up meeting : Les erreurs
      • La réunion n'a pas lieu tous les jours
      • la réunion commence en retard
      • Tout le monde ne s'exprime pas
      • Des personnes bavardent en aparté
      • Une personne interrompt les autres
      • On s'adresse uniquement au ScrumMaster
      • On parle de choses sans rapport avec les tâches du sprint
    119. Exemple Scrum : Une release
    120. Planification classique
      • Planifier par tâches, c’est adopter une approche tayloriste du développement logiciel. La première conséquence de cette approche est la déresponsabilisation : les membres de l’équipe acquièrent le sentiment de n’être qu’un engrenage de la machine. Dans un tel état d’esprit, il leur importe plus d’échapper aux reproches en accomplissant les tâches qui leur sont désignées que de contribuer à la réussite globale du projet. On ne peut mobiliser les énergies sans engagement, on ne peut obtenir cet engagement sans participation.
    121. Planifier (Planning game)
      • Planning de version :
      • Une version = 2 à 6 mois
      • Chaque user story a un poids et une priorité
      • Le client en choisit et définit l’ordre de réalisation
      • Les programmeurs répartissent ces US dans des itérations
      • Planning des itérations : planning game)
      • Une itération = 1-3 semaines (durée fixe)
      • Prendre les US par ordre de priorité
      • Décomposer chaque US en tâches
      • Estimer chaque tâche
      • Chacun prend la responsabilité des tâches qu’il pense pouvoir mener pendant l’itération (en binôme) et en réajuste le cout sur lequel il s’engage
    122. Product backlog (au début)
    123. Product backlog (après estimation)
    124. Suivi de projet (Release)
    125. Suivi de projet (Itération)
    126. Vélocité (1)
      • La vélocité est la mesure du nombre de points finis pendant une itération. Elle donne une indication de la capacité de l'équipe . Quand elle est utilisée à bon escient, la mesure de la vélocité permet à l'équipe :
      • de s'engager sur le court terme (contenu d'une itération)
      • de prévoir sur le moyen terme (planning de release)
      • Pour le point 1, l'idée est de se baser sur la mesure concrète de la vélocité pour en déduire la capacité pour la prochaine itération. Ce n'est qu'une indication, car lors de la réunion de planification de l'itération , le périmètre est plus défini par l'engagement de l'équipe sur ce qu'elle estime pouvoir faire que par un total de points égal à la vélocité passée [ 1 ]
      • Pour le point 2, le calcul de la vélocité concourt à la production du beurdone de release . Cependant le reste à faire utilisé dans le burn down dépend aussi des variations de périmètre. Ce n'est pas parce que l'équipe a une vélocité qui augmente que le reste à faire diminue, en particulier si de nombreux bugs viennent s'ajouter dans le backlog. Encore quelques remarques pour différencier vélocité de productivité :
      • La vélocité est basée sur les estimations en points. Et malheureusement, si la vélocité augmente, il n'y a pas moyen de savoir si c'est dû à une amélioration de la productivité ou à des mauvaises estimations. Il est aussi possible augmenter artificiellement la vélocité
      • La vélocité est une mesure de l'équipe, pas de personnes individuelle
      V = nb de points / (nb de jours * nb de personne)
    127. Vélocité (2)
    128. Développement (1)
      • Faire le plus simple possible
      • 1 jour de modélisation sur 10
      • Binômes
      • Personne n’est propriétaire du code  Equipe
      • CR journalier
    129. Binômes (1)
      •   Il y en a un qui fait le code pendant que l ’autre fait les tests
      • Il y en a un qui code pendant que l’autre le surveille 
      • Il y en a un qui code pendant que l’autre se repose 
      • Il y en a un qui tient la souris, l ’autre a le clavier... 
      • Cela coûte forcément deux fois plus cher 
      • J ’ai mes habitudes de codage...
      • J ’aime travailler tout seul 
      • Binômer, c’est multiplier les couts
      • par 2
    130. Binômes (2)
      • Deux personnes travaillant ensemble pour concevoir, tester, coder...
      • Une seule machine
        • un conducteur: manipule la machine, réalise le travail
        • un observateur: propose, conseille, vérifie, et réfléchi à la stratégie globale
      • Changements de conducteur fréquents
      • Changements de binôme fréquents
      • Travail dense, exigeant, productif et efficace
      • L’un regarde le clavier, l’autre l’écran, et on discute
    131. Cycle de vie du binôme « 1 + 1 = 1 [...] 1 + 1 = 11 » Jean-Claude Van Damme.
    132. Qualités d’ ½ binôme
      • Ouverture d'esprit et remise en question
      • Courage (de se mettre à nu)
      • Communication active (pas de rétention d'information)
      • Respect de l'autre et de son travail
      • Capacité à tourner (tâches, fonctionnalités, personnes...)
      • A se rendre non indispensable
      • Travailler à deux
      • A partager la gloire... Et les erreurs
      • il est « plus facile de former un débutant (à l'agilité) que de déformer un gourou ».
    133. La modélisation agile
      • Il faut modéliser (1 jour sur 10)
      • Les modèles sont faux
      • Modéliser à plusieurs
      • Moins de diagrammes de classe et plus de diagrammes d’interaction (et en //)
      • Ne pas passer trop de temps avec les outils, faire de reverse
      • Modéliser pour soi même
    134. Les bureaux agiles
    135. Développement (2)
      • Faire le plus simplement possible
        • Faire simple mais pas simpliste
        • Commencer simple
        • Ne pas faire de sur spécification
        • Pas de savants
        • Problème des design patterns
        • Homogénéité de l’équipe avant tout
        • Les cimetières sont remplis de gens indispensables
        • Faire de la réorganisation de code
          • Revue (binômes)
          • Une seule fois
          • Refactoring
    136. Faire le plus simple possible (1)
      • Faire le plus simple possible
      • Ne pas faire de sur spécification, mais penser à demain
      • Réorganiser le code
      • Compliquer le code (ex DP)
        • Former, convaincre sinon ne pas faire
        • Nivèlement par le bas, mais tout le monde comprend
      • Ne pas prendre d’expert
      • Se méfier des architectes
    137. Faire le plus simple possible (2)
      • if (n==3) System.out.print ("III");
      • if (n==2) System.out.print ("II");
      • if (n==1) System.out.print ("I");
      • ----------------------------------------------
      • while (n > 0) { System.out.print("I"); n = n - 1; }
      • -----------------------------------------------
      • if (n == 9) { System.out.print("IX"); n = n - 9; }
      • if (n >= 5) { System.out.print("V"); n = n - 5; }
      • if (n == 4) { System.out.print("IV"); n = n - 4; }
      • while (n > 0) { System.out.print("I"); n = n - 1; }
    138. Faire le plus simple possible (3)
      • while (n >= 100)
      • { System.out.print("C " );n = n - 100;}
      • if (n >= 90) { System.out.print("XC");n = n - 90; }
      • if (n >= 50) { System.out.print("D "); n = n - 50; }
      • if (n == 40) { System.out.print("XD"); n = n - 40; }
      • while (n >= 10) { System.out.print("X "); n = n - 10; }
      • if (n == 9) { System.out.print("IX "); n = n - 9; }
      • if (n >= 5) { System.out.print("V "); n = n - 5; }
      • if (n == 4) { System.out.print("IV "); n = n - 4; }
      • while (n >= 1) { System.out.print ("I "); n = n - 1; }
    139. Faire le plus simple possible (4)
      • if (n == 9) { System.out.print("IX "); n = n - 9; }
      • if (n >= 5) { System.out.print("V "); n = n - 5; }
      • if (n == 4) { System.out.print("IV "); n = n - 4; }
      • while (n >= 1 0) { System.out.print ("I "); n = n - 1; }
      •  n = Tester(n,1,0);
      • ---------------------------------------------------------------------
      • Int Teter(int n , int p , int ind)
      • {
      • if (n >= 9 * p) { System.out.print(tab[ind]+tab[ind + 2]); n = n - (9 * p); }
      • if (n >= 5 * p) { System.out.print(tab[ind + 1]); n = n - (5 * p); }
      • if (n == 4 * p) { System.out.print(tab[ind]+ tab[ind+1]); n = n - (4 * p); }
      • while (n >= p) {System.out.print(tab[ind]); n = n - p;}
      • return n;
      • }
      • // 0 1 2 3 4 5 6
      • private static String tab[]= { "I","V", "X","L","C","D","M"};
    140. Faire le plus simple possible (5)
      • package nommbrearabe;
      • public class Main {
      • // 0 1 2 3 4 5 6
      • private static String tab[]= { "I","V", "X","L","C","D","M"};
      • public static void main(String[] args) {
      • for (int i = 1; i<250 ;i++)Calculer(i);
      • }
      • private static void Calculer(int n) {
      • System.out.print (n + &quot;=&quot;);
      • while (n>=1000)System.out.print(&quot;M&quot;);
      • n = Tester(n,100,4);
      • n = Tester(n , 10, 2);
      • n = Tester(n,1,0);
      • System.out.println(&quot;&quot;);
      • }
      • private static int Tester (int n , int p,int ind){
      • if (n >= 9 * p) { System.out.print(tab[ind]+tab[ind + 2]); n = n - (9 * p); }
      • if (n >= 5 * p) { System.out.print(tab[ind + 1]); n = n - (5 * p); }
      • if (n == 4 * p) { System.out.print(tab[ind]+ tab[ind+1]); n = n - (4 * p); }
      • while (n >= p) {System.out.print(tab[ind]); n = n - p;}
      • return n;
      • }
      • }
    141. UP-XP Test DTD
    142. Les tests (1)
    143. Les tests (2)
      • Tests unitaires (X-UNIT)
        • Déclarer les classes que l‘on veut tester (via les digrammes UML si possible)
        • Ecrire le programme de test
        • Lancer le programme de test  Echec
        • Ecrire le programme
        • Lancer le test jusqu’au  Succès
        • Archiver le test ( TestSuite )
        • Ecrits par le programmeur
      • Tests de recette
        • Des outils
        • IHM Textuelles (automatique)
        • Outils de test
        • Ecrits par le client
      RMQ : Si possible, écrire et tester le programme avant de l’écrire (TTD)
    144. Junit : Echec avant écriture du programme
    145. Ecriture du programme
      • public class Personne {
      • private String nom;
      • private int age;
      • private String adresse ;
      • public Personne(String nom, String adresse) {
      • super();
      • this.nom = nom;
      • this.adresse = adresse;
      • age = 0;
      • }
      • public int getAge() {return age; }
      • public void setAge(int age) {this.age = age; }
      • public String getNom() {return nom; }
      • public String getAdresse() {return adresse; }
      • public void Afficher(){
      • System. out.println(&quot;Personne :&quot;+nom+&quot;,&quot;+age+&quot;,&quot;+adresse);
      • }
      • public void Travailler(){ age--;}
      • }
    146. Junit : Syntaxe
    147. Junit : Ecriture du test et run
    148. Junit : testSuite
    149. IHM DOS Blalal Gfgd gghdghds
    150. Test IHM Web : Selenium
    151. Outil de test automatique Tester les IHM http://www.alm.tv/Accueil/tabid/381/Default.aspx
    152. UP-XP Les outils indispensables
    153. Les outils
      • Le client
      • Des outils de DVP
        • avec du refactoring et du TU
      • UML (avec ou sans outil)
      • Gestion de la configuration
      • Des outils de test fonctionnel
      • Un outil de gestion de projet
    154. Refactoring
      • 100 fois sur le métier remettez votre ouvrage
      Solution trop lourde Architecture complexe Réparer avant de continuer Faire le ménage tous les jours, puis faire un nettoyage de printemps.
    155. Refactoring (NetBeans)
    156. Refactoring (Eclipse)
    157. Gestion de Configuration DVP Test Intégration Check in Check out
      • Mode :
      • lock
      • merge
    158. Gestion conf : arborescence S1 S2 S1.VF S1.VO S1.VF.1 S1.VF.2 S1.VF.3 S2.1 S1 S2 R1.1 R1.2 R2 R1
    159. Gestion conf : Méthode de travail
    160. Gestion des changements (1)
    161. Gestion des changements (2) MySQL Serveur Web
    162. Gestion des changements Bugzilla : Etats des DM
    163. Gestion de projet http://www.extremeplanner.com/tour/
    164. UP-XP Conclusions
    165. Retours d’expérience
        • Chrysler (la paye)
        • Métro de Newcastle
        • Postes de supervision TGV Madrid-Barcelone
    166. Bibliographie (livres) UML Laurent Audibert (www)
    167. Bibliographie (www) IBM-Rational
    168. UP-XP Etude de cas VPC
    169. Use Case : Correction
    170. UC : Secrétaire
    171. UC: Détails
    172. UC: Suppléments
    173. IHM : Secrétaire
    174. Idem (Visio)
    175. UC Web
    180. UC : Requirements
    181. IHM WEB

    + VINOT BernardVINOT Bernard, 2 years ago

    custom

    806 views, 0 favs, 1 embeds more stats

    Process objet

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 806
      • 805 on SlideShare
      • 1 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 21
    Most viewed embeds
    • 1 views on http://192.168.10.100

    more

    All embeds
    • 1 views on http://192.168.10.100

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    What's New

    © 2009 SlideShare Inc. All rights reserved.