Up1

UP-XP Process unifié Agilité

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.

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.

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)

UP-XP Introduction Gestion de projet Les concepts de base (OO & UML)

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.

Mise en place d’un processus (SEI)

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.

Gestion de projet classique (2)

Le cycle en V (Cascade) Winston Royce (1970)  Walker Royce (1990) V

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

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

Planifier avec Fibonacci Plus c’est compliqué et plus ça ….. Et si c’est encore plus compliqué alors ça ….. Encore plus

Cocomo : Les résultats ACT DET

Planifier méthode prédictive Gant, Temps, €, ….

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.

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

Correction Trouver les dates de début Au plus tard

Les Méthodes classiques : Conclusion(1) « La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch

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 ?

Programmation objet Programme principal o1 o2 o3 o4 o5 new fqq

Les concepts Objet Abstraction : Classe Encapsulation Héritage Polymorphisme

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

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

Taille des projets 1-2 ans & 6-12 personnes  Couper les projets

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

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

Les artefacts Activité de gestion de projet Comptes rendus, planning d’activité, …. Résultats Modèles Code source Spécifications … ..

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, ….)

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

Modélisation métier Stéréotypes UP Fournisseur Les process Les objets de L’entreprise Client Les employés business use case

Modélisation métier Artefacts et rôles Rôle : Business Process Analyst Artefacts : Business Glossary Business Use case Model

Les besoins Les exigences Les cas d’utilisation + Le document supplémentaire (architecture)

Gestion des exigences http://www.alm.tv/permalink/1734/sameliorer-sur-la-gestion-des-exigences-un-premier -pas-vers-lindustrialisation.aspx

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

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é

Gestion des exigences : Processus

Gestion des exigences : Outils

Gestion des exigences : CaliberRM

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.

Analyse (1) Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions

Analyse (2) Boundary-Controleur-Entité (1) Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement

Analyse (2) Boundary-Contrôleur-Entité (2)

Analyse (2) Boundary-Contrôleur-Entité (3)

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

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

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)

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

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()); } }

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

Implémentation Artefacts et rôles Rôles : Software Architect : Architecte Implementer : Programmeur, Analyste Integrateur Artefacts : Implementation model Build (les sources et autres ressources)

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)

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

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.

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

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

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

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

Organisation des modèles (UP) Les sources Les UC realization (Documentation) Les composants (physiques et logiques) Les machines Définition des besoins VOPC

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.

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

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

UP-XP Vers les méthodes agiles XP Scrum

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é

Les 4 valeurs de XP (1) Communication FeedBack Simplicité Courage

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.

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

Le chef de projet Agile la qualité essentielle du leader sera le charisme plus que l’autorité.

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.

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

Exemple Scrum : Une release UC User story Planning game DVP Tests Le client est dans la salle

Les tâches à faire (le radiateur)

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)

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

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

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.

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

Product backlog (après estimation)

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)

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

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

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

Cycle de vie du binôme « 1 + 1 = 1 [...] 1 + 1 = 11 » Jean-Claude Van Damme.

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 ».

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

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

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

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; }

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; }

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"};

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 + "="); while (n>=1000)System.out.print("M"); n = Tester(n,100,4); n = Tester(n , 10, 2); n = Tester(n,1,0); System.out.println(""); } 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; } }

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)

Junit : Echec avant écriture du programme

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("Personne :"+nom+","+age+","+adresse); } public void Travailler(){ age--;} }

Junit : Ecriture du test et run

Outil de test automatique Tester les IHM http://www.alm.tv/Accueil/tabid/381/Default.aspx

UP-XP Les outils indispensables

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

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.

Gestion de Configuration DVP Test Intégration Check in Check out Mode : lock merge

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

Gestion conf : Méthode de travail

Gestion des changements (2) MySQL Serveur Web

Gestion des changements Bugzilla : Etats des DM

Gestion de projet http://www.extremeplanner.com/tour/

Retours d’expérience Chrysler (la paye) Métro de Newcastle Postes de supervision TGV Madrid-Barcelone

Bibliographie (livres) UML Laurent Audibert (www)

Bibliographie (www) IBM-Rational

Up1

Contenu connexe

Tendances

En vedette

Similaire à Up1

Plus de VINOT Bernard

Up1