Le secteur des SSII (Sociétés de

Dimension: px
Commencer à balayer dès la page:

Download "Le secteur des SSII (Sociétés de"

Transcription

1 Les méthodologies informatiques Agiles L utilisation de méthodes de développement adaptatives s inscrit dans une logique d amélioration des performances globales des projets. Dans le domaine informatique, cette recherche s illustre par le recours aux méthodes dites " Agiles ". Jean Guillaume Lalanne nous livre ici un retour d expérience sur l utilisation de ces méthodes. Jean Guillaume Lalanne Architecte d information Cap Gemini Ernst & Young Le secteur des SSII (Sociétés de Service en Informatique) vit actuellement une crise profonde, structurelle. Il est confronté subitement à un durcissement du marché, comme jamais auparavant il n en avait fait l expérience. Ceci l entraîne inexorablement vers une ère d industrialisation. Cette " révolution industrielle " du marché des services va, dans les cinq prochaines années, selon le Gartner Group, être comparable à celles qu ont connus, en d autres temps, les secteurs du textile et de la métallurgie. Les symptômes avant coureurs sont là : réorganisations, réductions des coûts, restructurations, plans sociaux, délocalisations (évidente du fait de la dématérialisation du produit : pas de problèmes de logistique comme dans le cas de l industrie lourde, etc.) et fusions/acquisitions. L éclatement de la bulle Internet et des Télécoms n a fait que mettre à jour des dysfonctionnements déjà existants depuis le début des années 90. Mon propos est davantage de fournir un retour d expérience afin de dégager les points forts et faibles de chasistance technique, d obligation de moyens, et de déve- loppements " sur mesure, elle doit, désormais, développer au " forfait " avec obligation de résultats et suivant une démarche qui génère de la valeur ajoutée Jusqu à présent, les projets n étaient que rarement profitables et s ils l étaient, c était parce qu on avait su faire payer le prix réel au client. D après une étude américaine menée en 1994 sur 8000 projets (1), 16 % d entre eux n ont pas respecté les délais et le budget initial, et pire, 32 % n ont jamais abouti. L étude du Standish Group pour 1998 montre une amélioration par rapport à 1996, puisque le taux d échec des projets tombe de 40% à 28%. En revanche, encore près de la moitié des projets sont en retard et/ou hors budget, ce qui laisse un quart des projets pleinement réussis. Il faut développer aux moindres coûts pour rester compétitif, avec une qualité de livraison irréprochable et dans les délais les plus courts, imposés par les contraintes de " Time To Market (2) " que les clients subissent eux-mêmes. C est dans ce cadre économique que sont apparues et apparaissent de nou- Le bouleversement est grand et la profession se voit contrainte de changer de façon de faire. Encore fondée principalement sur une culture d asvelles méthodologies de développement propres au monde du service informatique. Elles se réclament du qualificatif, un peu pompeux, il est vrai, "d Agiles ". Agile par opposition aux méthodes employées auparavant principalement fondées sur la notion de prédictibilité. Au paradigme de prédiction, ces méthodes proposent le pragmatisme et l adaptation. Dans cet article, il ne sera question que des méthodes agiles que je connais : à savoir, le " Feature Driven Development " (FDD), le " Two Tracks Unified Process " (2TUP), " l Extreme Programming " (XP) et bien que ce produit soit propriétaire, le " Rational Unified Process " (RUP). Il serait bien difficile pour moi de parler de l ensemble des méthodes agiles, elles sont trop nombreuses. Il ne sera pas non plus question de fournir une description détaillée de chacune de celles que je viens de citer ci-dessus, car j en serais bien incapable, préférant en laisser le soin à d éminents confrères (3). 1) Source : 2) Rapidité à livrer un produit, un service au marché (3) Jean-Pierre Vickoff : La Cible N 101-SEPTEMBRE

2 Figure 1 : TUP (Two Track Unified Process) Figure 2 : RUP (Rational Unified Process) cune d elles par comparaison (comparaison avec les méthodologies " Merisiennes ", dites classiques, mais également comparaison entre elles). Les méthodes " Agiles " reposent sur quatre principes de base, qui privilégient (4) : La communication et l interaction qui en résulte, à la contractualisation des spécifications. La compétence et l implication des ressources, au respect de processus formel et d une vision " outillée " à l extrême des développements. La livraison de fonctionnalités réelles, à la production d une documentation pléthorique. Boxing " (5), " Task Boxing "(6)), au respect d une planification figée. Elles ont toutes été fondées toutes à partir de l observation suivante : le développement informatique est plus que ardu. Il est difficile de comprendre ce que le client désire faire vraiment (ou faire faire en l occurrence). Il n exprime jamais ses vrais besoins, car souvent, à un instant t, il les ignore lui-même. Si toutefois il arrivait à le faire, ces derniers évolueront de toute façon au cours du projet. Ils changent du fait même de la création du logiciel. C est la logique du serpent qui se mord la queue. Et même si l on imagine, le cas où un jour, le client formalise correctement ses besoins et ses exigences, il n en demeure pas moins que le développement est, la plupart du temps, complexe : tout projet a ses spécificités techniques et fonctionnelles, qu il est difficile de prévoir. Un système informatique est un édifice souvent vaste et compliqué, ayant un nombre de degrés de liberté pratiquement illimité. Michel Pébereau*, PDG de BNP Paribas déclarait ainsi " l informatique des entreprises, c est un peu les cathédrales du Moyen Age, commencées en style roman et terminées en gothique flamboyant. Les architectes sont morts depuis longtemps et plus personne n a les plans". Toute erreur ou changement peut générer, du fait de cette complexité, par effet domino, une surcharge de travail. Cette surcharge peut devenir exponentielle pour le projet. Il est donc évident que l ensemble des concepts, qui constituent les fondations des méthodes classiques, ne soit plus considéré comme réaliste par les chefs de projet : Le périmètre fonctionnel n est jamais arrêté ; Il n est donc jamais possible de définir un planning précis et figé ; Et donc, pas davantage de se protéger de futurs risques de dérives de projet, en verrouillant les besoins fonctionnels et le planning. Partant de ce constat, les méthodes agiles proposent un processus qui s adapte aux multiples évolutions du contexte par une planification continuellement réévaluée. Le principe d itération pour les unes ou de " release " (7) pour les autres permet de définir une discrétisation L acceptation du changement et la modification des priorités (" Time- Figure 3 : une illustration concrète du décalage des représentations. (4) Source : - (5) Le projet est principalement contraint par une date limite. (6) Le projet est contraint par un nombre incompressible de fonctionnalités à développer. - (7) " Release " pourrait être traduit par le mot livrable. Toutefois, livrable fait penser à la notion de document. Or, ceci ne correspond pas trop à la philosophie des méthodes agiles (XP en particulier). 38 La Cible N 101-SEPTEMBRE 2004

3 temporelle simple qui permet d identifier la " vitesse " et la consommation du projet, afin de pouvoir réajuster régulièrement tous les paramètres du pilotage projet. On peut distinguer quatre étapes majeures dans l évolution des cycles de développement logiciel : Le cycle en cascade, c est le plus simple et le plus connu : on analyse le problème, on conçoit une solution, on construit la solution, on teste cette dernière, on intègre et on déploie. La méthode est séquentielle et l estimation de la durée du projet se résume à une addition des estimations temporelles de ces différentes étapes. Le cycle en spirale : puisque qu il est évident que des erreurs sont faites durant les phases de conception et de construction, le cycle précédent n est pas vraiment réaliste. Est alors apparu la notion d itération. Itérer c est effectuer une tâche en plusieurs passes. Chaque passe améliore le résultat jusqu à qu une validation définisse que la tâche est achevée. L idée est d avancer lentement afin de ne pas laisser passer un bogue qui peut coûter très cher s il est découvert que trop tard dans les phases avales. La notion de validation (ou retour client) apparaît au cours du projet. La difficulté de ce type de cycle réside dans le planning d itérations non prévisibles par essence. Le cycle de développement itératif se calque sur le précédent, sauf qu il ne considère pas l itération comme exceptionnelle. Il part du principe que les itérations vont avoir lieu sans arrêt. Il faut donc essayer d estimer leur nombre. Doucement, à chaque nouvelle itération, le développement devient meilleur et il est de moins en moins nécessaire de revenir sur ce qui a été fait. Le cycle de développement par livraison incrémentale : le problème avec la méthode précédente est qu il faut beaucoup de temps avant de voir quelque chose finalisé. Ce cycle propose au contraire de livrer le logiciel plusieurs fois au client avec toujours davantage de fonctionnalités (les plus importantes au début). La quantité d analyse et d architecture décroît au fur et à mesure des incrémentations. Le problème avec ce type de méthode, c est de savoir ce qui va guider le choix du contenu des incréments : une vision architecturale, la gestion des risques ou celle, économique, des fonctionnalités? Les méthodes agiles partent du principe que le retour client et le retour sur le code déjà développé sont nécessaires et qu il est dommageable de vouloir les éviter, bien au contraire. Il est préférable de livrer au client des incrémentations très brèves afin d avoir un retour quasi continu. Les fonctionnalités dans les incréments sont définies par le client. Une métaphore souvent employée et qui résume bien cet état d esprit est celle des stocks de matières premières et de produits intermédiaires dans l industrie. Tout comme ces derniers, un développement non livré au client peut être considéré comme un passif pour le projet. Il est absolument nécessaire pour la bonne santé du projet de livrer au fur et à mesure les fonctionnalités que l on a développées. Il faut éviter à tous les niveaux du projet les effets tunnels. Dans le même ordre d idée, toute activité support projet qui ne représente aucune valeur ajoutée pour le client doit être réduite à sa plus simple expression. Cette gestion temporelle du projet par itérations et par incréments est essentielle. Elle demeure le principal fondement de l agilité. J insiste sur ce point. Il m apparaît maintenant clairement que l utilisation de ces principes simples aurait pu, à coup sûr, sauver de l échec un certain nombre de projets sur lesquels j ai eu à intervenir. Toutefois, les méthodes agiles ne se limitent pas à cela. Elles proposent un grand nombre de bonnes pratiques, que je propose d analyser par la suite, à la lueur de mon expérience. Auparavant, il me semble utile de rappeler, historiquement, d où proviennent, pour la plupart, ces méthodes agiles. Elles sont le résultat de retour d expérience d un certain nombre de mouvances et techniques : La première et la plus importante à mon sens : la mouvance " Open Source ". Plus que l aspect juridique (ouverture du code, licence particulière, etc.), cette mouvance a avant tout généré un grand nombre de pratiques (et d outils associés) utilisées par des communautés virtuelles gigantesques afin de mener à bien des projets logiciels, internationaux et complexes. LINUX, APACHE, GNU sont les exemples qui viennent les premiers à l esprit. On peut parler de réussites! L impact de cette mouvance sur les pratiques de développement est aussi grand que celui des produits qui ont été développés sur l informatique actuelle. Il est évident qu une méthode comme XP (Extreme Programming) est le fruit de ce monde-là. Il n est alors pas étonnant d y retrouver des pratiques comme l intégration continue (make, build de ANT), le test unitaire continu, la validation des exigences continue (" Issue Tracking "), le retour constant des utilisateurs (" mailing-list ", " bugzilla ", forum, sondages, FAQ), le partage du code (CVS, site collaboratif, distribution code source), la notion de " release " rapide, etc. Il suffit de jeter un coup d œil sur le site (créé au début des années 90!) pour comprendre leur provenance. L apparition du formalisme standard UML et d autres formalismes métiers basés principalement sur XML a permis d introduire une agilité plus grande dans la structuration de l information que le projet doit gérer : information technique et/ou information fonctionnelle. Un meilleur formalisme permet une meilleure compréhension entre les différents acteurs du projet, mais aussi une historisation plus évidente du contexte projet (bien plus évident que le sont des quantités de documents binaires comme WORD, EXCEL ou PDF, etc.). Même si certains récusent cet accès de formalisme, il est le passage né- La Cible N 101-SEPTEMBRE

4 cessaire vers une automatisation de la gestion projet logiciel : le " refactoring " (8) ne cible pas uniquement le code, il cible tous les axes d un projet. La description structurée au format ASCII favorise le " parsing " (9) et donc le retour en arrière, l amélioration continue. Une vision graphique de ce formalisme est toujours plus efficace qu une vision documentaire. Le concept de MDA (" Model Driven Architecture ") participe à cet effort de formalisme. Il n est toutefois qu à ses débuts. Le concept objet : plus que le formalisme qu il engendre, ce concept a énormément apporté dans la capitalisation des bonnes pratiques logicielles (GoF, Design Pattern J2EE). Pour la première fois, il a vraiment permis la réutilisation, première étape vers l industrialisation. A présent, arrêtons nous quelques instants sur les grands principes qui constituent les méthodes agiles, afin de les confronter à l expérience (le tableau ci-dessous en fournit, sous une forme synthétique, une description simple). La notion de " Pair Programming " : Cette technique de développement est acceptable dans les premières étapes des itérations mais n est pas conseillée dans le reste de la phase de production. C est une dépense inconsidérée qui peut coûter très cher sur la fin d un projet. Néanmoins, l intérêt est évident, et j ai eu l occasion de le vérifier, dans les phases d analyses et de design (phase de prototypage, ou de " Proof of Concept "(10)). En outre, elle permet de former de façon croisée les développeurs à tous les aspects de l architecture. Comme dans une équipe de rugby où n importe quel joueur blessé doit pouvoir être remplacé au pied levé, les développeurs doivent être polyvalents afin de pouvoir faire face à tout aléa durant le projet (maladies, vacances, migration vers un autre projet,etc.). Le " Pair Programming " favorise cette agilité de l équipe projet. Les développeurs sont d ailleurs souvent demandeurs d une telle pratique qui leur permet ainsi d accroître leur champ de compétences. " Test-First Design " : Cette première notion rejoint le concept de prototypage ou de " Proof of Concept " cité ci-dessus. Ce sont Principes Agiles Client sur site (On Site Customer) Séance de Planification (Planning Game) Intégration Continue (Continuous Integration) Livraisons Fréquentes (Frequent Releases) Rythme soutenable (Forty-Hour a week) Description rapide Pour une meilleure communication, les clients et les développeurs travaillent dans le même espace autant que possible. Le client définit les scénarios utilisateurs prioritaires. Les développeurs discutent le contenu de ces scénarios, définissent les tâches techniques sous-jacentes, estiment ces tâches et y souscrivent. Le système est intégralement assemblé et testé une à plusieurs fois par jour. Le rythme des livraisons est de l'ordre de quelques semaines. L'équipe ne fait pas d'heures supplémentaires deux semaines de suite. Tests de Recette Recette (Acceptance Tests) Tests Unitaires (Unit Testing) Conception Simple (Simple Design) Métaphore (Metaphor) Remaniement Continu (Refactoring) Convention de Code (Coding Standard) Programmation en binôme (Pair Programming) Propriété collective du code (Collective Code) Ownership Retour d'information rapide sur le système, en général automatisé, constitué à partir de critères de tests définis par le client. Tests automatisés écrits pour chaque classe, chaque méthode, et pour tout "ce qui pourrait casser" en général. Ces tests doivent passer à 100% continuellement. Le code doit passer tous les tests et répond aux critères de maintenabilité : concision, modularité, cohérence, lisibilité. Une analogie utilisée comme modèle conceptuel du système en cours de développement. Ou re-factorisation de code pratiquée sans relâche : modification du code par laquelle on améliore sa conception sans en modifier le comportement. Le code doit suivre une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe. Le code de production est toujours écrit par deux développeurs : le pilote et le copilote. Les binômes changent au cours du projet. Chaque développeur peut modifier chaque partie du code si le besoin s'en fait sentir. (8) Notion de retour en arrière, d amélioration continue du travail fourni. - (9) Lecture automatisée d un document structuré. (10) Notion de prototypage. 40 La Cible N 101-SEPTEMBRE 2004

5 d excellents exercices pour clarifier les besoins fonctionnels (déterminer leurs impacts au plan technique), appréhender leur niveau de risque et leurs coûts éventuels. L architecte doit être pleinement impliqué dans cette activité pour s imprégner de la complexité du projet. " On-Site Customer " : Cela peut être une bonne méthode pour obtenir un feedback continu sur l évolution des développements, pour partager la charge de documentation avec le client et surtout éviter toute " réunionite " qui mobilise trop de ressources pour des résultats souvent très limités. L interaction avec l utilisateur final doit être encadrée car les besoins de ce dernier peuvent rapidement ne plus correspondre à la solution achetée au début : le client achète une maison et il exige une cathédrale! Chaque demande doit être " priorisée " et évaluée en terme de coût. " Coding Standards " : Plus que les notions de convention de nom ou de codage, le concept suggère de toujours utiliser des standards techniques ou des bonnes pratiques métier. Il ne sert jamais à rien " de réinventer la roue ". " Continuous Integration " : Cette méthode est d une grande utilité car elle permet à tous les développeurs de resituer leur travail dans l œuvre plus globale qu est le projet. Il est question dans " l Extreme Programming " de métaphore. On évite ainsi tout cloisonnement des développements. Les processus de test unitaire et de test de non régression assurent la consistance à tout instant de ce qui est intégré, si bien qu une estimation de la qualité des livrables est toujours disponible. " Collective Ownership " : Cette notion est fortement liée à la précédente. Elle permet d éviter également le cloisonnement du projet et de garder son agilité. Ceci n est faisable que lorsqu un système de gestion de configuration performant a été mis en place afin de tracer toute évolution. Ce type de système devient vite l épine dorsale du projet. Cette technique permet également de contraindre le développeur à suivre une convention de codage projet et à abandonner ces mauvaises habitudes. Elle participe au concept de polyvalence de l acteur du projet. La rétention d information n a plus lieu d être. (11) La " roadmap " est la trajectoire à suivre pour atteindre l objectif ou la cible La Cible N 101-SEPTEMBRE 2004 " Refactoring " : Si l idée est parfaitement acceptable pour du développement logiciel mono langage de programmation, elle ne peut en aucune manière se substituer à une démarche architecturale précise. C est sûrement l un des points de désaccord le plus évident entre des méthodes comme RUP, 2TUP et XP. En effet, la phase d initialisation du projet n apparaît pas clairement dans le processus XP. Avant tout commencement de " release " ou d itération, il est forcément nécessaire de compter quelques jours, ne serait-ce que pour obtenir une vision commune avec tous les acteurs, en terme de périmètre, de risque et de budget. Une exploration fonctionnelle et technique, ainsi qu une planification sont effectuées une fois que l on a estimé que le projet a une forte probabilité de succès. XP est plus adapté pour des projets où les risques techniques sont minimes car bien connus (notion de " départ lancé "). C'est le cas des développements logiciels. Dans un processus comme RUP, la phase d architecture qui se trouve au niveau des " Elaborations Itérations " permet de stabiliser les fondations de la solution. XP insiste pour que les " releases " soient fonctionnellement orientées, afin qu elles fournissent une valeur ajoutée immédiatement appréciable par le client. La phase d architecture n est donc pas vraiment prise en compte en tant que telle ; elle est diluée tout au long des différentes " releases ". L idée de XP est de ne pas passer trop de temps à délivrer un travail qui ne représente aucune valeur ajoutée métier aux yeux du client. C est une vision réductrice qui omet de considérer que la réduction des risques est aussi une valeur ajoutée importante pour le client. Il y a toujours toute une série de problèmes d environnement, de systèmes, de matériel qui ne peut être gérée seulement par la philosophie du " Refactoring ". Et XP ne les adresse pas correctement. Il est avant tout un processus de développement logiciel ; or il est évident que la plupart des projets informatiques dépassent ce contexte-là. Le positionnement du projet dans le Système d Information est incontournable afin d assurer le respect de l urbanisation et d estimer les adhérences de la solution avec le système existant. " Metaphor " : Pour de grands projets, l architecture peut difficilement se résumer à une simple métaphore. Néanmoins, il est toujours bon de communiquer les grandes lignes de cette architecture à l ensemble de l équipe projet afin de définir un objectif commun (dans le monde open source, il est question de " roadmap " (11)). " Rapid release " : C est une excellente technique. Elle permet de rassurer rapidement le client et de lui fournir une grande visibilité sur le projet. L acceptation des utilisateurs est acquise plus tôt et le risque de rejet de l outil est intégré rapidement dans le projet. En terme commercial, cette démarche est très appréciée du client car elle fournit une vision modulaire du produit. Il peut relier une " release " à un coût et donc souvent renégocier en interne les priorités de telles ou telles fonctionnalités : il acquiert un argumentaire pour sa politique interne qu une autre approche projet ne fait pas ressortir. Pour l équipe projet, cette démarche permet de communiquer le travail effectué en interne et chez le client. Le risque est d investir énormément sur les premières " releases " et de ne devenir rentable que sur les dernières (si le client ne souhaite pas poursuivre en milieu de projet pour une raison ou une autre, la santé économique du projet n est plus assurée). " Simple Design " : XP est trop orienté vers une conception dirigée par les fonctions métiers. Elle ne prend pas en compte une approche architecturale du type " Fra- 41

6 mework " (12) comme celle proposée par RUP et 2TUP. Il est dangereux de développer ainsi. Des problèmes peuvent n apparaître que lorsque les releases seront intégrés entre elles. Il est alors trop tard pour agir. " 40-hour week " : Il est vrai que les développeurs ont tendance à travailler jusqu à ce que leur programme fonctionne correctement en fin de journée. C est une grossière erreur de penser que le chef de projet doit utiliser ce penchant pour optimiser les journée de développement. A terme, une telle démarche est fortement contre-productive. Le chef doit imposer des horaires fixes à son équipe afin de garder une fraîcheur d esprit tout le long du projet. De nombreuses erreurs de jugement peuvent ainsi être évitées. Les rôles de RUP : RUP insiste sur la discrétisation des rôles afin de bien gérer les compétences sur le projet. XP simplifie cette discrétisation de 30 à 7 afin de promouvoir la polyvalence des acteurs de l équipe et d éviter tout cloisonnement et étiquette. Interlocuteur Maîtrise d ouvrage (MOA)/Client ayant pouvoir de décision : Il est fondamental d avoir des interlocuteurs ayant réellement une expertise client et/ou un pouvoir de décision. Il est trop fréquent de se heurter à des directions projet MOA à diverses têtes, qui contraignent trop souvent le chef de projet MOE (Maîtrise d oeuvre) à faire l utilisation du processus d escalade hiérarchique, très coûteux en terme de temps, de communication projet et de motivation de l équipe. Au même titre que les " Proof Of Concept " techniques et fonctionnels, il est utile de bien évaluer en début de projet les ressources humaines MOA/client mises à disposition. Autonomie et organisation centralisée de l équipe (motivation) : Les méthodes agiles s inspirent clairement des méthodes de fonctionnement des équipes sportives : il est d ailleurs question du " SCRUM " (13), allusion non dissimulée au rugby. Le fonctionnement interne de l équipe projet doit être basé sur le principe du " Gagnant-Gagnant" : à savoir qu un projet ne sera une réussite pour le management que s il est d abord aussi une réussite pour l ensemble des intervenants. Comme nous avons pu le constater tout au long de cet article, les méthodes agiles apportent un grand nombre de nouvelles pratiques. La plupart de ces pratiques sont déjà des " Best Practices " du monde " Open Source " ; en ce sens, elles ont déjà fait leur preuve. Toutefois, même si la majorité d entre elles peuvent être considérées comme positives, toutes ne le sont pas. Un projet Open Source n est pas sujet aux mêmes contraintes qu un projet traditionnel. Les concepts d itérations et d incrémentations sont des concepts phares. L intégration continue, la gestion continue des exigences et la livraison rapide de verticalités produites sont également des notions incontournables. Leur apport est indéniable. Les concepts de " Refactoring " et " First-Design " sont plus sujets à caution. Le principal grief que l on peut émettre à l égard de ces méthodologies - et il est d importance - c est qu elles sont principalement portées par des équipes MOE. Or les équipes MOA chez les clients sont souvent des équipes non familiarisées avec les méthodes agiles. Historiquement, les chefs de projet MOA sont souvent d anciens chefs de projet prestataires, qui ont capitalisé sur les méthodes qui étaient alors en cours. Il y a donc souvent, pour ne pas dire toujours, une différence de méthodologie entre la MOA et la MOE. Il est possible de faire abstraction de cela pour l une ou pour l autre des équipes. Toutefois ceci n est plus possible lorsque la MOA et/ou le Client impose à la MOE, pour des raisons de qualité, la méthodologie maison. Cette dernière étant malheureusement souvent de type documentaire, " Merisien ". Comment alors diriger un projet en utilisant une méthodologie dite agile lorsque la culture du client est fortement empreinte d une philosophie prédictive? Le problème revient alors à s adapter à la méthodologie client sans biaiser son agilité. La tâche peut vite s avérer compliquée. En particulier, comment faire accepter au client une démarche d architecture et de " Proof Of Concept " lorsqu il attend une rédaction de spécifications fonctionnelles, techniques, générales ou détaillées? Comment faire comprendre qu une bonne analyse, une bonne conception ne sont pas synonymes de documents mais au contraire de développement? Le bon fonctionnement de la " tuyauterie " de la solution ne peut être évalué si on se cantonne à la rédaction de spécifications. Il n y a sûrement pas de réponse toute faite à ce genre d interrogations. Toutefois, il est certain que les bonnes pratiques introduites par ces méthodes agiles vont faire leur chemin et devenir des standards de facto que les MOA finiront par adopter à moyen terme. Ces méthodes répondent à des besoins et permettent de résoudre des problèmes. On aurait tort de les considérer comme des phénomènes de mode. Bibliographie : " Extreme Programming Explained ", Kent Beck (Addison-Wesley). " Refactoring : Improving the design of existing code", Martin Folwer (Addison-Wesley) " Extreme Programming Installed ", Ron Jeffries (Addison-Wesley) " Agile Software development", Alistair Cockburn (Addison-Wesley) " The Rational Unified Process", Phillipe Kruchten (Addison-Wesley) "The ten essential of RUP", Leslee Probasco, (Rational Software Whitepaper) Site WEB sur l Extreme Programming : Glossaire : MOA : Maîtrise d ouvrage MOE: Maîtrise d oeuvre 12) Concept très en vogue actuellement et issu principalement de " l open source ". Il s agit de la notion de socle technique et fonctionnalités transverses. - (13) mêlée 42 La Cible N 101-SEPTEMBRE 2004

Les méthodes itératives. Hugues MEUNIER

Les méthodes itératives. Hugues MEUNIER Les méthodes itératives Hugues MEUNIER INTRODUCTION. Toute les méthodes ont le même but : la maîtrise du budget, du planning et de la qualité des projets de développement informatique Plusieurs approches

Plus en détail

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET 1 Tianxiao LIU Licence Professionnelle Réseaux & Sécurité Université de Cergy-Pontoise http://depinfo.u-cergy.fr/~tliu/lpg.php PLAN Objectif et

Plus en détail

Cours Gestion de projet

Cours Gestion de projet Cours Gestion de projet Méthodes de conduite de projet Version Date Auteur V1.8 Septembre 2007 Pascal HEYER 1 Méthodes de conduite de projet Ce document est publié sous la licence libre Creative Commons-BY-NC-SA

Plus en détail

Méthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif.

Méthodes agiles. www.businessinteractif.com CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS. Jean-Louis Bénard jlb@businessinteractif. Méthodes agiles www.businessinteractif.com Jean-Louis Bénard jlb@businessinteractif.fr CONSEIL & DÉVELOPPEMENT DE SOLUTIONS E-BUSINESS 0 20 mai 2002 Sommaire Méthodes agiles : une réponse à un malaise?

Plus en détail

Les méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008

Les méthodes Agiles Introduction. Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Introduction Intervenant : Tremeur Balbous tremeur@agilegardener.com http://www.agilegardener.com/ 04/09/2008 Les méthodes Agiles Le contexte Le Manifeste Agile Une tentative de définition

Plus en détail

Techniques de Développement

Techniques de Développement Techniques de Développement Quelques définitions relatives au développement de logiciel Sébastien Faucou Université de Nantes (IUT de Nantes, département Informatique) Licence Professionnelle Systèmes

Plus en détail

Génie logiciel (Un aperçu)

Génie logiciel (Un aperçu) (Un aperçu) (sommerville 2010) Laurent Pérochon INRA URH 63122 St Genès Champanelle Laurent.perochon@clermont.inra.fr Ensemble d activités conduisant à la production d un logiciel Sur un échantillon de

Plus en détail

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS

Conduite de projets SI. Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Conduite de projets SI Les méthodes «Agiles» N QUAL/1995/3660e ORESYS Agilité : de quoi parle-t-on? Agilité de l entreprise Urbanisme Architectures SOA Agilité du SI ERP Plateformes applicatives agiles

Plus en détail

Introduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg.

Introduction Les processus traditionnels extreme Programming Conclusion. extreme Programming. vers plus d agilité. F. Miller francois.miller@inpg. vers plus d agilité F. Miller francois.miller@inpg.fr FC INPG Octobre 2008 - version 1.0 Introduction Contexte Le monde bouge économie des moyens (humains, financier,...) ; recherche de plus d efficacité

Plus en détail

Gestion de Projet Informatique

Gestion de Projet Informatique Gestion de Projet Informatique Partie 3 : Cycles de vie de projet Licence d'informatique 3 ième Année Tianxiao Liu Université de Cergy-Pontoise 1 GPI T. LIU The earliest moment is when you think it is

Plus en détail

Méthodes Agiles et gestion de projets

Méthodes Agiles et gestion de projets Méthodes Agiles et gestion de projets Eric LELEU Consultant Solutions Collaboratives Contact ericleleu@nordnet.fr Site Personnel http://home.nordnet.fr/~ericleleu Blog http://ericleleu.spaces.live.fr La

Plus en détail

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique»

Gestion de projet Agile. STS IRIS Module 4.2 - «Gérer et organiser un projet informatique» Gestion de projet Agile Module 4.2 - «Gérer et organiser un projet informatique» Sommaire Introduction Principes et méthodes Agiles Scrum 2 Introduction Gestion de projet : démarche structurante assurant

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Gestion Projet. Cours 3. Le cycle de vie

Gestion Projet. Cours 3. Le cycle de vie Gestion Projet Cours 3 Le cycle de vie Sommaire Généralités 3 Séquentiel 7 Itératif/Incrémental 17 Extreme Programming 22 Que choisir? 29 Etats Transverse 33 Cours 3 2006-2007 2 Généralités Cours 3 2006-2007

Plus en détail

Jean-Pierre Vickoff. 2008 J-P Vickoff

Jean-Pierre Vickoff. 2008 J-P Vickoff Agilité étendue Jean-Pierre Vickoff 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Le mouvement Itératif-Incrémental (Agile) Agilité étendue au SI et PUMA Essentiel Entreprise

Plus en détail

Introduction au génie logiciel

Introduction au génie logiciel Introduction au génie logiciel Guillaume Laurent ENSMM 2007 G. Laurent (ENSMM) Introduction au génie logiciel 2007 1 / 36 Plan du cours 1 Problématique du génie logiciel 2 Méthodes de développement logiciel

Plus en détail

Séance 1 Méthodologies du génie logiciel

Séance 1 Méthodologies du génie logiciel Séance 1 Méthodologies du génie logiciel Objectifs : Histoire du développement du logiciel. La crise du logiciel. Explorer les différentes méthodologies de développement. Comprendre l importance d adopter

Plus en détail

Règles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche

Règles d engagement. Présentation Diapositives Bibliographie Questions Les vertus de la marche Règles d engagement Présentation Diapositives Bibliographie Questions Les vertus de la marche Plan Rappels sur l agilité Scrum : une implantation de l agilité Scrum ou XP? Conclusion Historique sélectif

Plus en détail

25/12/2012 www.toubkalit.ma

25/12/2012 www.toubkalit.ma 25/12/2012 www.toubkalit.ma 1 Définition Exemple des méthodes agiles Valeurs Principes Le cycle itératif et incrémental (Itération/Sprint) Schéma de travail Méthode Scrum. Méthode XP (Extreme programming).

Plus en détail

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM

Topologie du web - Valentin Bourgoin - http://www.valentinbourgoin.net. Méthodes agiles & SCRUM Méthodes agiles & SCRUM 1/ Pourquoi les méthodes agiles? Définition d une méthode agile. Fondamentaux. Quand les utiliser? 2/ SCRUM En quoi est-ce une méthode agile? Sprints et releases. Le Product Owner.

Plus en détail

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Direction Générale des Études Technologiques Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Génie Logiciel Mejdi BLAGHGI m.blaghgi@gmail.com Chapitre

Plus en détail

But de cette introduction à la gestion de projets :

But de cette introduction à la gestion de projets : But de cette introduction à la gestion de projets : Présenter quelques méthodes de conception logicielle. Replacer la conception de bases de données dans un contexte plus vaste. Présenter quelques méthodes

Plus en détail

Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles

Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Alignement avec les métiers par le test fonctionnel et d acceptation en projets agiles Laurent PY CEO, Smartesting Laurent.py@smartesting.com @py_laurent www.smartesting.com Guillaume Coquelle Testeur,

Plus en détail

CHAPITRE 3 : LES METHODES AGILES?

CHAPITRE 3 : LES METHODES AGILES? CHAPITRE 3 : LES METHODES AGILES? UE Gestion de Projet Master 1 STIC 2014/2015 Céline Joiron 2 Introduction Après avoir présenté les cycles de vie «classiques» de la gestion de projet L objectif de ce

Plus en détail

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition)

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition) Avant-propos 1. Objectifs du livre 13 2. Structure du livre 14 Un projet informatique 1. Les enjeux 17 1.1 Les buts d'un projet 17 1.2 Les protagonistes d'un projet 18 1.3 Exemples de projets 19 2. Les

Plus en détail

Jean-Pierre Vickoff www.vickoff.com

Jean-Pierre Vickoff www.vickoff.com Techniques du futur Agile Communication - Architecture - Méthode Vers une approche Agile de 3 ème génération Jean-Pierre Vickoff www.vickoff.com Protocole de séance : Précisions techniques immédiates possibles

Plus en détail

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique

Soyez agile. Dans l industrie du logiciel, la. De plus chaque projet informatique Soyez agile Dans l industrie du logiciel, la gestion de projet est confrontée à de nombreux défis. Le principal est de pouvoir assurer l adéquation d un produit et de ses fonctionnalités avec les besoins

Plus en détail

GL - 2 2.2 Processus de développement Cycles de vie

GL - 2 2.2 Processus de développement Cycles de vie GL - 2 2.2 Processus de développement Cycles de vie Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, Ph. Lalanda, I. Parissis, Y. Ledru 1 Plan Introduction Modèles en cascade

Plus en détail

PEPI GPI (Gestion de Projet Informatique) - Note de Cadrage décembre 2010 -

PEPI GPI (Gestion de Projet Informatique) - Note de Cadrage décembre 2010 - I N S T I T U T N A T IO N A L D E L A R E C H E R C H E A G R O N O M I Q U E Pepi Gestion de Projets Informatiques PEPI GPI (Gestion de Projet Informatique) - Note de Cadrage décembre 2010-1 Préambule...

Plus en détail

Les méthodes Agile. Implication du client Développement itératif et incrémental

Les méthodes Agile. Implication du client Développement itératif et incrémental Les méthodes Agile Simon ALEXANDRE - CETIC Plan Overview Agile ne signifie pas Agile signifie Objectifs poursuivis Pourquoi les méthodes Agile apparaissent-elles? Principales causes des échecs de projets

Plus en détail

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts

Les évolutions des méthodes de développement de logiciels. Depuis Merise de l'eau est passée sous les ponts Les évolutions des méthodes de développement de logiciels Depuis Merise de l'eau est passée sous les ponts Programmation Orientée Objets Encapsulation des données et des traitements Polymorphisme Modularité

Plus en détail

Problématique, Constats

Problématique, Constats Problématique, Constats Réactivité de la DSI pour les projets numériques consommateurs Contraintes de temps et de coûts Forte pression des métiers Compétitivité des sociétés externes Décalage de démarrage

Plus en détail

Méthodes de développement

Méthodes de développement 1 / 9 Méthodes de développement Méthodes agiles 1 - Introduction... 2 2 -Le manifeste agile et les méthodes agiles... 2 2.1 Le manifeste agile... 2 2.2 Les méthodes agiles... 3 3 - Caractéristiques communes

Plus en détail

Méthode Agile de 3 ème génération. 2008 J-P Vickoff

Méthode Agile de 3 ème génération. 2008 J-P Vickoff PUMA Essentiel Méthode Agile de 3 ème génération 1 Structure de la présentation PUMA Essentiel méthode Agile de 3 ème génération Quelques principes Agiles Principales pratique Agile de pilotage Structure

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Maîtrise d ouvrage agile

Maîtrise d ouvrage agile Maîtrise d ouvrage agile Offre de service Smartpoint 17 rue Neuve Tolbiac 75013 PARIS - www.smartpoint.fr SAS au capital de 37 500 - RCS PARIS B 492 114 434 Smartpoint, en quelques mots Smartpoint est

Plus en détail

backlog du produit Product Owner

backlog du produit Product Owner Méthodes agiles : Définition: selon Scott Ambler «Une méthode agile est une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées

Plus en détail

PagesJaunes.fr Mise en place de Scrum de scrum. Fabien Grellier Agile Tour 2010 7 Octobre

PagesJaunes.fr Mise en place de Scrum de scrum. Fabien Grellier Agile Tour 2010 7 Octobre PagesJaunes.fr Mise en place de Scrum de scrum Fabien Grellier Agile Tour 2010 7 Octobre 1 Roadmap Le contexte PagesJaunes.fr Le projet PagesJaunes.fr 2009 Rétrospective Conclusion 2 Le contexte PagesJaunes.fr

Plus en détail

Les projets d investissement en PME

Les projets d investissement en PME Le point sur Les projets d investissement en PME Concilier performance économique et conditions de travail L investissement reste un moment clé du développement d une entreprise. C est l occasion de repenser

Plus en détail

Introduction à la modélisation

Introduction à la modélisation Formation INRA-ACTA-ICTA Introduction à la modélisation Les modèles mathématiques pour l agronomie et l élevage 2 nde session, du 28 novembre au 1 er décembre 2005 - Informatique et modèles - Nathalie

Plus en détail

En face du commanditaire, on met un chef de projet qui connait le domaine (banque, administration, etc.)

En face du commanditaire, on met un chef de projet qui connait le domaine (banque, administration, etc.) Atelier «Science du projet» séance 4 8 novembre 2008 Compte rendu 1. Sébastien Larribe : la méthode AGILE, méthode de gestion de projet Sébastien Larribe part de l hypothèse que des méthodes de conception,

Plus en détail

Le cycle de vie : sur mesure Cycle de vie «basique»

Le cycle de vie : sur mesure Cycle de vie «basique» Le cycle de vie : sur mesure Cycle de vie «basique» OPPORTUNITE FAISABILITE CONCEPTION REALISATION RECEPTION MISE EN PRODUCTION MAINTENANCE «Basique» = phases de base nécessaires à la couverture d un cycle

Plus en détail

Quelle organisation pour développer? Les principes et les valeurs de l extreme programming

Quelle organisation pour développer? Les principes et les valeurs de l extreme programming Les principes et les valeurs de l extreme programming XP sont bons 1 Principes Revue de code Production systématique de cas tests Refactoring Solutions simples Métaphores Intégration quotidienne cycles

Plus en détail

Analyse et conception de systèmes d information

Analyse et conception de systèmes d information Analyse et conception de systèmes d information Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch Juin 2005 [SJB-02] Chapitre 3 1 Références Ce document a

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

Plus en détail

Framework Agile Global

Framework Agile Global PUMA Architecte d une génération d entreprises performantes Framework Agile Global Une organisation est fonctionnellement Agile lorsque ses composants opérationnels (ressources humaines, processus opérationnels,

Plus en détail

Vers une méthode Agile de 3 ème génération

Vers une méthode Agile de 3 ème génération Décembre 2012 Agile d hier et Agile de demain Evolution des Méthodes Agiles Vers une méthode Agile de 3 ème génération Jean-Pierre Vickoff Protocoles de séance : Questions techniques immédiates OK mais

Plus en détail

répondre aux défis de l ingénierie logicielle déploiement et mise en œuvre opérationnelle : l'industrialisation au service de la compétitivité

répondre aux défis de l ingénierie logicielle déploiement et mise en œuvre opérationnelle : l'industrialisation au service de la compétitivité répondre aux défis de l ingénierie logicielle déploiement et mise en œuvre opérationnelle : l'industrialisation au service de la compétitivité philippe.ensarguet@orange.com directeur technique Orange Business

Plus en détail

Eclipse Process Framework et Telelogic Harmony/ITSW

Eclipse Process Framework et Telelogic Harmony/ITSW Eclipse Process Framework et Telelogic Harmony/ITSW Boris Baldassari 1 Résumé Une introduction à Eclipse Process Framework (EPF) et au processus OpenUP, et comment tirer profit de ces initiatives dans

Plus en détail

XP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros

XP : plus qu'agile. Extreme Programming v2 et Développement Responsable. Thierry Cros XP : plus qu'agile Extreme Programming v2 et Développement Responsable Thierry Cros Retrouvez cette présentation sur le site http://thierrycros.net Licence CC-BY-NC-SA XP : plus qu'agile Pourquoi XP Installer

Plus en détail

Scrum - Tour d'horizon de la méthode

Scrum - Tour d'horizon de la méthode Scrum - Tour d'horizon de la méthode Agenda Agilité Scrum Pilotage d'un projet agile selon Scrum Contractualisation Forces & questions ouvertes 2 Les méthodes agiles Méthodes de développement d'applications

Plus en détail

Conception et développement des plates-formes webs, de services et des applications mobiles des clients Entreprise: Yaal

Conception et développement des plates-formes webs, de services et des applications mobiles des clients Entreprise: Yaal Université Bordeaux 1 Master Informatique spécialité Système et Réseaux parcours Réseaux Conception et développement des plates-formes webs, de services et des applications mobiles des clients Entreprise:

Plus en détail

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013 UML Mise en œuvre dans un projet 2013 Introduction Rôles et activités dans un projet Définir la méthode de votre projet Adapter la modélisation à la méthode de votre projet Conseils de mise en œuvre de

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

AGILITÉ ET PROJETS AVEC SCRUM

AGILITÉ ET PROJETS AVEC SCRUM AGILITÉ ET PROJETS AVEC SCRUM ENSIMAG 2014 Jean-François Jagodzinski @jfjago www.agilessence.fr 1 Jean-François Jagodzinski - Coach Formateur et accompagnateur d équipes agiles Site -> http://www.agilessence.fr

Plus en détail

LA GESTION DE PROJET INFORMATIQUE

LA GESTION DE PROJET INFORMATIQUE Structurer, assurer et optimiser le bon déroulement d un projet implique la maîtrise des besoins, des objectifs, des ressources, des coûts et des délais. Dans le cadre de la gestion d un projet informatique

Plus en détail

Informatiques. Module : Outils RAD

Informatiques. Module : Outils RAD Management de Projets Informatiques Module : Outils RAD Niveau : S4 du L2/ISIL Génie Logiciel Le terme génie logiciel (en anglais software engineering) désigne l'ensemble des méthodes, des techniques et

Plus en détail

LEAN SOFTWARE DEVELOPMENT. La vision de Mary et Tom Poppendieck

LEAN SOFTWARE DEVELOPMENT. La vision de Mary et Tom Poppendieck LEAN SOFTWARE DEVELOPMENT La vision de Mary et Tom Poppendieck Plan de la présentation 1. Introduction 2. Concept 1 : Eliminer les Gaspillages 3. Concept 2 : Améliorer le Système 4. Concept 3 : Embarquer

Plus en détail

SFR. Mise en place de la gestion des exigences sous DOORS dans le cadre de la refonte du système d'information commercial 14/11/2007

SFR. Mise en place de la gestion des exigences sous DOORS dans le cadre de la refonte du système d'information commercial 14/11/2007 SFR Mise en place de la gestion des exigences sous DOORS dans le cadre de la refonte du système d'information commercial 14/11/2007 1 Sommaire 1- Le contexte et l historique de la Gestion des EXigences

Plus en détail

Moteur Agile de Projet PUMA. Architecte d une génération d Entreprises performantes. Jean-Pierre Vickoff www.rad.fr

Moteur Agile de Projet PUMA. Architecte d une génération d Entreprises performantes. Jean-Pierre Vickoff www.rad.fr PUMA Architecte d une génération d Entreprises performantes Jean-Pierre Vickoff www.rad.fr Sommaire du Moteur de Projet Agile Evolution du courant de pensée Agile... 3 Historique de PUMA... 5 PUMA un framework

Plus en détail

Introduction à l Agile (22/01/2012)

Introduction à l Agile (22/01/2012) Introduction à l Agile (22/01/2012) OCTO 2012 50, avenue des Champs-Elysées 75008 Paris - FRANCE Tél : +33 (0)1 58 56 10 00 Fax : +33 (0)1 58 56 10 01 www.octo.com 1 Plan! Qui suis-je?! Quelques notions

Plus en détail

Les 10 pratiques pour adopter une démarche DevOps efficace

Les 10 pratiques pour adopter une démarche DevOps efficace Les 10 pratiques pour adopter une démarche DevOps efficace William Gravier RESPONSABLE D ACTIVITE DEVOPS SOCIETE POESI 1 QU EST-CE QUE DEVOPS? 2 LES TROIS PROCESSUS DEVOPS 3 L AGILITE DES ETUDES ET L ITILISISATION

Plus en détail

LA GESTION DE PROJET INFORMATIQUE

LA GESTION DE PROJET INFORMATIQUE LA GESTION DE PROJET INFORMATIQUE Lorraine Structurer, assurer et optimiser le bon déroulement d un projet implique la maîtrise des besoins, des objectifs, des ressources, des coûts et des délais. Dans

Plus en détail

1. Considérations sur le développement rapide d'application et les méthodes agiles

1. Considérations sur le développement rapide d'application et les méthodes agiles Chapitre 1 Introduction 1. Considérations sur le développement rapide d'application et les méthodes agiles 1.1 Rappel Longtemps les méthodes en cascade ou en V ont été opposées aux démarches empiriques

Plus en détail

Les Bonnes PRATIQUES DU TEST LOGICIEL

Les Bonnes PRATIQUES DU TEST LOGICIEL Les Bonnes PRATIQUES DU TEST LOGICIEL SOMMAIRE Qu est-ce que le test logiciel? Pourquoi le test est-il un maillon crucial de l ingénierie logicielle? Quels sont les différents types de tests? Qu est-ce

Plus en détail

Agilitéet qualité logicielle: une mutation enmarche

Agilitéet qualité logicielle: une mutation enmarche Agilitéet qualité logicielle: une mutation enmarche Jean-Paul SUBRA Introduction : le manifeste Agile Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logiciels

Plus en détail

Formation : Modélisation avec UML 2.0 et Mise en pratique

Formation : Modélisation avec UML 2.0 et Mise en pratique Formation : Modélisation avec et Mise en pratique Durée : sur 4 Jours soit 28 heures ou sur 5 Jours soit 35 heures Présentation Stage UML (Unified Modeling Language) est la notation standard qui s'est

Plus en détail

ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group

ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group ISTQB Agile Tester en quelques mots ISTQB Marketing Working Group Mai 2014 Qu est-ce que l ISTQB? ISTQB : International Software Testing Qualifications Board (www.istqb.org): Association sans but lucratif

Plus en détail

Les Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis

Les Méthodes Agiles. description et rapport à la Qualité. Benjamin Joguet Rémi Perrot Guillaume Tourgis Les Méthodes Agiles description et rapport à la Qualité Benjamin Joguet Rémi Perrot Guillaume Tourgis 1 Plan Présentation générale d'agile Qu'est ce qu'une méthode Agile? Le manifeste Les valeurs Les principes

Plus en détail

Jean-Pierre Vickoff www.agile-entreprise.com

Jean-Pierre Vickoff www.agile-entreprise.com Jean-Pierre Vickoff www.agile-entreprise.com PUMA Essentiel : Agilité globale et Système d information Jean-Pierre Vickoff Abstract PUMA (Processus Urbanisant les Méthodes Agiles) est une boîte à outils

Plus en détail

Dossier Méthodes SOMMAIRE & 2 MENSUEL PUBLIÉ PAR SOC-INFOS

Dossier Méthodes SOMMAIRE & 2 MENSUEL PUBLIÉ PAR SOC-INFOS SOMMAIRE Dossier Méthodes 4 24 MDA : Privilégier la logique métier Xavier Blanc L ingénierie logicielle guidée par les modèles (MDA) permet d élaborer les modèles métier des systèmes d information de façon

Plus en détail

Introduc)on à l Agile

Introduc)on à l Agile Introduc)on à l Agile 1 D où je viens Études M2 info : Paris Diderot (2009) MS Management de Projets Technologiques : ESSEC / Telecom Paris (2010) Aujourd hui Consultant à OCTO Technology (Conseil en SI)

Plus en détail

Retour d expérience implémentation Scrum / XP

Retour d expérience implémentation Scrum / XP Retour d expérience implémentation Scrum / XP Bruno Orsier Octobre 2008 p.1 Bruno Orsier, Agile Tour 2008 Grenoble Plan Qui sommes nous? Pourquoi Scrum/XP? Historique de la mise en œuvre Bilan Sondage

Plus en détail

QUELS SONT LES DEFIS DE L OUTSOURCING? 3 INTEGRATION DE L OFFRE PROFECI DANS LE CADRE DE LA MISE EN PLACE D UNE RELATION D OUTSOURCING 6

QUELS SONT LES DEFIS DE L OUTSOURCING? 3 INTEGRATION DE L OFFRE PROFECI DANS LE CADRE DE LA MISE EN PLACE D UNE RELATION D OUTSOURCING 6 QUELS SONT LES DEFIS DE L OUTSOURCING? 3 DEFINIR VOS REGLES DU JEU 3 CONTROLER L APPLICATION DES REGLES 3 VOUS OBLIGER A JOUER LE JEU : «RECONNAITRE ET ACCEPTER LES CONTRAINTES S IMPOSANT A VOUS» 4 CONCLUSION

Plus en détail

Développement ebusiness

Développement ebusiness Développement ebusiness Cédric Pulrulczyk ( cedric.pulrulczyk@alcatel.fr ) Alcatel Université Lille I March 2005 Plan Analyse des besoins Méthodologie XP Modélisation UML Outil de développement Tests et

Plus en détail

Réussir le choix de son SIRH

Réussir le choix de son SIRH Réussir le choix de son SIRH Pascale Perez - 17/09/2013 1 L évolution du SI RH 1960 à 1970 : le progiciel de paie. Le système d information RH apparaît dans les années soixante avec la construction des

Plus en détail

SEANCE 2 INTRODUCTION

SEANCE 2 INTRODUCTION SEANCE 2 INTRODUCTION Types de développement des SI Développement sur mesure SI développé from scratch par des pro de SI en fonction des besoins d utilisateur. o Coût o Temps o Erreur o + Besoins Développement

Plus en détail

Analyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.

Analyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML. Analyse et conception objet du logiciel : Méthode de conception objet et notation UML Rémy Courdier Email : Remy.Courdier@univ-reunion.fr Rémy Courdier V2.1 1 Plan du cours Introduction au Génie Logiciel

Plus en détail

Optimiser vos méthodes d organisation (ITIL, COBIT, PRINCE2, ) par la mise en place d un processus de Gestion & Publication des connaissances adapté

Optimiser vos méthodes d organisation (ITIL, COBIT, PRINCE2, ) par la mise en place d un processus de Gestion & Publication des connaissances adapté Optimiser vos méthodes d organisation (ITIL, COBIT, PRINCE2, ) par la mise en place d un processus de Gestion & Publication des connaissances adapté 25/07/06 JJ Mois Année Présentation générale & Présentation

Plus en détail

Application COBOL sur le Web

Application COBOL sur le Web Application COBOL sur le Web Roger Engel Éditions Eyrolles ISBN : 2-212-09116-8 2000 Avant-propos En informatique, nous vivons actuellement des temps fort captivants, caractérisés par de profonds bouleversements,

Plus en détail

Ministère de l intérieur --------

Ministère de l intérieur -------- Ministère de l intérieur -------- Examen professionnel d ingénieur principal des systèmes d information et de communication du ministère de l intérieur Session 2013 Meilleure copie Sujet n 1 - Réseaux

Plus en détail

Plateforme STAR CPM. Gestion intégrée des process multilingues d entreprise Les voies de la performance avec STAR James

Plateforme STAR CPM. Gestion intégrée des process multilingues d entreprise Les voies de la performance avec STAR James Plateforme STAR CPM Gestion intégrée des process multilingues d entreprise Les voies de la performance avec STAR James Groupe STAR Your single-source provider for corporate product communication Le bon

Plus en détail

Business Project Management : Cycle de vie des documents et workflow

Business Project Management : Cycle de vie des documents et workflow Business Project Management : Cycle de vie des documents et workflow Iut de Tours Département Information-Communication Option Gestion de l Information et du Document dans les Organisations Page 1 sur

Plus en détail

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES

Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Yassine ZAKARIA SÉMINAIRE : MÉTHODES AGILES Quelques constats Etude du Standish Group Seul 1/3 des projets informatiques sont qualifiés de succès 50 % sont livrés et opérationnels, mais sont sortis du

Plus en détail

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie Licence en Informatique à Horraire Décalé Cours Gestion de projet informatique Première partie 1 PLAN Introduction 1. Les concepts de base en management de projet : 3-33 2 Les processus du management de

Plus en détail

CRM et GRC, la gestion de la relation client R A LLER PL US L OI

CRM et GRC, la gestion de la relation client R A LLER PL US L OI 3 R A LLER PL US L OI CRM et GRC, la gestion de la relation client Comment exploiter et déployer une solution de relation client dans votre entreprise? Les usages d une CRM Les fonctionnalités d une CRM

Plus en détail

L évolution de l automatisation.

L évolution de l automatisation. Gestion automatisée de la qualité Livre blanc Octobre 2009 L évolution de l automatisation. Etude de l évolution de l automatisation dans la gestion de la qualité des logiciels Page 2 Sommaire 2 Introduction

Plus en détail

Agile Maroc 24 Novembre 2010. Méthodes agiles. Thierry Cros. http://etre-agile.com. Agile Maroc 24 novembre 2010

Agile Maroc 24 Novembre 2010. Méthodes agiles. Thierry Cros. http://etre-agile.com. Agile Maroc 24 novembre 2010 Agile Maroc 24 Novembre 2010 Méthodes agiles Thierry Cros 1 Thierry Cros 10 ans déjà... 2010 Création Extreme Programming France 2009 SigmaT Les Agilistes Toulousains 2010 Membre de «Fédération Agile»

Plus en détail

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum Les méthodes Agiles Introduc)on aux méthodes Agiles Exemple : Scrum Défini)on de base Les méthodes Agiles sont des procédures de concep)on de logiciel qui se veulent plus pragma)ques que les méthodes tradi)onnelles

Plus en détail

Processus de Développement Logiciel

Processus de Développement Logiciel Processus de Développement Logiciel Cours M14 Pierre Gérard Université de Paris 13 IUT Villetaneuse Formation Continue Licence Pro SIL LA TE X Pierre Gérard (P13 IUT FC) Processus de Développement Logiciel

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

Introduction au développement du logiciel

Introduction au développement du logiciel Introduction au développement du logiciel Vers le génie logiciel Université de Nantes Master Miage M1 Plan 1 Introduction 2 Génie logiciel 3 Projet informatique 4 Méthode de développement 5 Qualité Bibliographie

Plus en détail

La fonction d audit interne garantit la correcte application des procédures en vigueur et la fiabilité des informations remontées par les filiales.

La fonction d audit interne garantit la correcte application des procédures en vigueur et la fiabilité des informations remontées par les filiales. Chapitre 11 LA FONCTION CONTRÔLE DE GESTION REPORTING AUDIT INTERNE Un système de reporting homogène dans toutes les filiales permet un contrôle de gestion efficace et la production d un tableau de bord

Plus en détail

LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET. Franck BEULÉ

LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET. Franck BEULÉ LA MÉTHODE AGILE VS LE CYCLE EN V UNE RÉVOLUTION DANS LA GESTION DE PROJET Franck BEULÉ 18 avril 2012 Bienvenue L'hôte de ce soir Franck BEULÉ Chef de Projet senior Chez Vision IT Group depuis 2 ans Actuellement

Plus en détail

Gestion des exigences dans des projets agiles. Témoignage industriel

Gestion des exigences dans des projets agiles. Témoignage industriel Gestion des exigences dans des projets agiles Témoignage industriel Sommaire Contexte de l'intervention Etre agile, c'est quoi? Processus d'ie dans un contexte d agilité organisation structurelle des exigences

Plus en détail

Introduction. Les articles de la presse spécialisée tendent à nous laisser penser que c est en effet le cas :

Introduction. Les articles de la presse spécialisée tendent à nous laisser penser que c est en effet le cas : Introduction Le CRM se porte-t-il si mal? Les articles de la presse spécialisée tendent à nous laisser penser que c est en effet le cas : «75 % de projets non aboutis» «La déception du CRM» «Le CRM : des

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail