La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

© Reproduction interdite ALTRAN Nord – TI Introduction aux méthodologies de développement Cours HEI 2009-2010.

Présentations similaires


Présentation au sujet: "© Reproduction interdite ALTRAN Nord – TI Introduction aux méthodologies de développement Cours HEI 2009-2010."— Transcription de la présentation:

1 © Reproduction interdite ALTRAN Nord – TI Introduction aux méthodologies de développement Cours HEI

2 © Reproduction interdite Sommaire Les Méthodologies de développement (Conduite de Projet Informatique ) 1.Introduction : le projet 2.Le cycle de vie dun projet 3.Méthodes de développement 4.Versionning

3 © Reproduction interdite 1- Introduction Genèse du projet Idée Besoin Opportunité Innovation PROJET

4 © Reproduction interdite Définition L'Afitep-Afnor (X ) définit le projet comme : " une démarche spécifique qui permet de structurer méthodiquement et progressivement une réalité à venir...: un projet est défini et mis en œuvre pour répondre au besoin d'un client (...) et implique un objectif et des besoins à entreprendre avec des ressources données". 1- Introduction Composantes « Quoi » Objectifs, Fonctionnalités Temps Délais, échéances Moyens disponibles Humains et Techniques Financiers (coût) Qualité Selon le domaine dactivités

5 © Reproduction interdite 2- Cycles de vie dun projet : 1.Définition dun cycle de vie 2.Méthodes

6 © Reproduction interdite « Le cycle de vie dun logiciel est la période située entre le début de la conception et larrêt de lexploitation de ce logiciel. » « Le cycle de vie regroupe un ensemble dactivités suivant les normes AFNOR Z Il est envisagé à un instant donné et va comprendre les progrès technologiques et les contraintes organisationnelles » (A. Carlier, 1994) Le cycle de vie dun logiciel « correspond à lidentification des états successifs dune application ou dun produit déterminé. Il est essentiellement dynamique, évolutif et presque toujours progressif » (A. Carlier, 1994) 2.1- Définition du cycle de vie

7 © Reproduction interdite SéquentielleItératives CascadeEvolutiveObjet Principe de découper le projet en phases distinctes sur le principe du non-retour. Développée dans les années 1970 par W. ROYCE Principe basé sur la polyvalence et une approche pluridisciplinaire, qui tendent à minimiser l'impact de l'évolution des besoins en cours de projets Principe basé sur la séparation de létude darchitecture de celle de létude fonctionnelle afin de paralléliser au maximum les tâches. Procède par itération comme pour lévolutive. Avantage: proposer au fur et à mesure une démarche de réduction des risques, en minimisant au fur et à mesure l'impact des incertitudes. Avantage : permettent de se rapprocher davantage des utilisateurs, et ainsi favorisent l'assurance qualité Avantage : Permet de prendre en compte les problèmes darchitecture dès le début du projet. Conforme à lapproche objet dont la dynamique est plutôt ascendante en matière de composants darchitecture. Inconvénient : exclusion de l'utilisateur dès la phase de conception car trop technique. Le contrôle qualité significatif survient seulement en fin de projet. Inconvénient : le produit, résultat d'évolutions permanentes, peut devenir complexe et difficilement maintenable Inconvénient : Tout repose sur lexpertise de léquipe projet Risque : refus de recette utilisateur Risque : Maintenance difficile 2.2- Principales méthodes de conduite de projet

8 © Reproduction interdite Exemples de méthodes de conduite de projet : Dynamiques en cascade : Modèle en b Modèle de loti Modèle parallèle Modèle en V Dynamiques évolutives (ou dites « Agile ») : Spirale RAD DSDM (Dynamic System Development Management) RUP (Rational Unified Process) SCRUM (sprint) Extreme Programming 2.2- Méthodes

9 © Reproduction interdite 3- Méthodes de conduite de projet : 1.Le modèle en cascade 2.Modèle en V 3.Autres modèles 4.Les étapes dun projet

10 © Reproduction interdite 3.1- Modèle de développement en cascade Expression des besoins Spécifications Conception Développement Tests Maintenance Projets de petite taille, Projets de Back-Office Démarche basée sur la spécialisation des tâches qui tendent à contenir les risques et les coûts, dans un enchaînement de phases qui reste simple et intuitif

11 © Reproduction interdite L'assurance qualité est le processus qui permet de vérifier en continu la qualité du produit à fur et à mesure de sa fabrication. Le modèle en V met l'accent sur ce processus. Il confronte les différents niveaux de test avec les phases de projet de même niveau. Ceci permet à chaque étape de définir non seulement les fonctions, mais également les critères de validation. La cohérence entre les deux éléments permet de vérifier en continu que le projet progresse vers un produit répondant aux besoins initiaux. Ce modèle est adapté aux projets de taille et de complexité moyenne. C'est une amélioration du modèle en cascade traditionnel. Il permet d'identifier et d'anticiper les éventuelles évolutions des besoins. C'est aussi un moyen de vérifier la maturité des utilisateurs, car s'il en était autrement, ils se trouveraient dans l'incapacité de fournir des tests de recette dès la phase de spécification. C'est un modèle avantageux pour une maîtrise d'œuvre et rassurant pour une maîtrise d'ouvrage, qui doit cependant s'engager significativement Modèle en « V » (variante du modèle en cascade)

12 © Reproduction interdite 3.3- Le modèle en «V» Expression des besoins Spécifications Conception DéveloppementTests unitaires Tests dintégration Recette Exploitation

13 © Reproduction interdite 3.4- Autres modèles Principe du modèle itératif Nouveau besoin (documentation, code, test) Faisabilité Elaboration Fabrication Transition Exploitation ou tests par les utilisateurs

14 © Reproduction interdite Similaire au modèle en cascade, il met l'accent sur le processus de maintenance qui est évalué à 70% du cycle complet. Ce modèle réutilise les scénarios de tests bâtis pendant la phase de développement, notamment pour les tests de non-régression, ainsi que les procédures de mise en exploitation. Ce modèle se projette plus loin que le traditionnel cycle en cascade. Il peut servir de base à une maîtrise d'ouvrage pour bâtir un projet complet de développement et de maintenance d'une grosse application de back office. Son intérêt est de prévoir lors de chaque phase projet la réutilisation des tests et des procédures de mise en exploitation Autres modèles Modèle en « B »

15 © Reproduction interdite Développement Maintenance Expression du besoin Spécifications Conception Développement Tests Exploitation Évaluation Expression du besoin Spécifications Conception Développement 3.4- Autres modèles Modèle en « B »

16 © Reproduction interdite Modèle Incrémental ou en lots Le modèle incrémental ou loti permet de gérer les projets de développement de grands systèmes. Il découpe le système en domaines qui sont traités individuellement sur le modèle en cascade. Une des idées du modèle incrémental est de gérer la complexité. C'est un modèle adapté aux projets de grande envergure. Néanmoins, l'architecture du système doit permettre de définir des domaines suffisamment découplés. Dans le cas contraire, certains incréments doivent attendre que les incréments avec lesquels ils sont liés, soient suffisamment développés. Lorsqu'on leur propose un développement par lot, les maîtrises d'ouvrage doivent vérifier le couplage des domaines. Modèle parallèle Le modèle parallèle est un modèle incrémental couplé soit par le temps (les différents domaines doivent être mise en production au même moment), soit par les composants (certains composants du système sont étroitement liés). Bien qu'il réduise la complexité, comme le modèle incrémental, il ne parvient pas à supprimer les risques de délai. Il suppose des montées en charge rapides, avec des équipes relativement fournies. Adopter ce modèle suppose que les autres facteurs du projet ne présentent pas de risques significatifs. Néanmoins, la maîtrise d'ouvrage devra être attentive à la composition de l'équipe projet et à son mode de management Autres modèles

17 © Reproduction interdite Modèle en spirale Principe : Identifier les risques, leur affecter une priorité Développer des prototypes pour réduire les risques, en commençant par le plus grand risque Utiliser un modèle en V ou en cascade pour implémenter chaque cycle de développement Contrôler : si un cycle concernant un risque est achevé avec succès, évaluer le résultat du cycle, planifier le cycle suivant si le risque est non résolu, interrompre le projet 3.4- Autres modèles

18 © Reproduction interdite 4 phases dans le déroulement du cycle en spirale (défini par Barry Boehm en 1988) : 1.détermination des objectifs, des alternatives et des contraintes ; 2.analyse des risques, évaluation des alternatives ; 3.développement et vérification de la solution retenue ; 4.revue des résultats et vérification du cycle suivant Autres modèles

19 © Reproduction interdite Modèle de type « Prototype » « Un prototype est la première version d'un produit qui vient d'être réalisé afin d'être mis au point ». Autrement il faut parler de maquette, qui recouvre la réalisation à petite échelle de tout ou partie d'un produit à réaliser. Par abus de langage, nous nommerons prototype les maquettes réutilisables. Les prototypes peuvent être construits suivant un axe horizontal ou vertical. Horizontaux, ils couvrent une couche technique du système sur l'ensemble des fonctions à développer. Verticaux, ils couvrent un échantillon de fonctions sur l'ensemble des couches techniques. Généralement les prototypes réalisés sont des 2 types. Les prototypes peuvent être réutilisables, comme lors d'un cycle de vie itératif qui étoffe à chaque itération le prototype initial jusqu'au produit fini. Ils peuvent être également jetables à des fins de vérification fonctionnelle ou technique (faisabilité). Sur les projets techniques, menés par de petites équipes, l'intérêt est de gagner en flexibilité, et de se libérer des contraintes d'une méthodologie plus large. Pour des projets où les utilisateurs sont largement impliqués, on préfèrera toujours un cycle de vie RAD Autres modèles

20 © Reproduction interdite 3.4- Autres modèles Modèle du cycle itératif RAD Structure d une phase dans le cycle RAD Cycles de prototypage Le cycle de vie RAD (Rapid Application Development) est employé lorsque une implication forte de l'utilisateur est nécessaire. Il permet de construire le système avec l'utilisateur, et participe ainsi à l'assurance qualité. Néanmoins la condition sine qua non pour mettre en œuvre un cycle RAD est de s'appuyer sur un solide AGL (atelier de génie logiciel) qui seul peut garantir un passage rapide du concept à la mise en œuvre. L'équipe projet doit nécessairement maîtriser l'AGL employé, c'est le risque principal des projets RAD.

21 © Reproduction interdite DSDM "Dynamic System Development Management" (DSDM) met en œuvre de manière structurée la plupart des principes des modèles évolutifs afin de les rendre efficaces dans le cadre de grands projets. L'objectif initial de DSDM était de pallier le manque de formalisation du concept RAD en proposant une méthode structurée pour le mettre en œuvre. DSDM est une méthode basée sur une démarche évolutive et incrémentale, c'est à dire que non seulement le système est produit au cours d'itérations, mais en plus il est divisé en lots, et livré de manière progressive. DSDM est composé de 5 phases : 1.La faisabilité (expression du besoin, coûts/bénéfices, évaluation des risques) ; 2.Létude business (spécification des fonctions et hiérarchisation) ; 3.Le modèle fonctionnel (prototypes horizontaux et tests) ; 4.La conception et la réalisation (prototypes verticaux et tests) ; 5.La mise en œuvre (optimisation et mise en production). DSDM doit être l'objet des mêmes attentions que le modèle RAD Autres modèles

22 © Reproduction interdite RUP "Rationale Unified Process" est une méthode développement propriété de la société Rational et basé sur l'utilisation de l'atelier Rational. Elle est vendue sous la forme d'une documentation hypertexte et d'outils incorporables à chaque composant de l'AGL de Rational. C'est une méthode évolutive, qui met en œuvre les mêmes principes que le RAD ou le développement en spirale. Elle composée de 4 phases : 1.Linception (initial "use case", coût/bénéfice, risques, planification) ; 2.Lélaboration ("use case" à 80% terminés, architecture logicielle, prototype) ; 3.La construction (développement) ; 4.La transition (tests, conversion et déploiement). RUP utilise le niveau élevé d'automatisation que lui procure l'AGL Rational. Il permet d'une part de planifier des itérations à l'intérieur de chaque phase, de paralléliser les processus au maximum : ainsi la définition d'architecture peut commencer tandis que les spécifications ne sont pas terminées Autres modèles

23 © Reproduction interdite 3.5- Les étapes dun projet (Extrait dune proposition commerciale) Linitialisation du projet Létude darchitecture La conception fonctionnelle et technique La Réalisation Les tests La recette interne La recette fonctionnelle Lintégration La conversion et la reprise des données Le site pilote Le déploiement technique La formation Documentations

24 © Reproduction interdite 3.5- Les étapes dun projet Linitialisation du projet Cette phase permettra aux équipes de la maîtrise dœuvre de : 1.Intégrer le détail des enjeux, objectifs et contraintes du projet, 2.Intégrer lenvironnement fonctionnel et technique du projet, 3.Constituer / intégrer les groupes de travail du projet, 4.Définir un macro planning et confirmer léventuel lotissement fonctionnel, 5.Définir finement lensemble des livrables du projet,

25 © Reproduction interdite 3.5- Les étapes dun projet Létude darchitecture Cette étude aura pour principaux objectifs : 1.De définir larchitecture applicative, notamment sur la reprise des composants existants, et la conception des composants techniques et fonctionnels propres au domaine, 2.De définir larchitecture technique et de valider définitivement les outils de développement, 3.Damender, le cas échéant, le périmètre fonctionnel du projet, 4.De finaliser le lotissement défini par la maîtrise douvrage au regard des contraintes architecturales identifiées, 5.De définir larchitecture des données : localisation, répartition, modèle, réplication, sauvegardes, 6.Initialiser les tableaux de suivi des risques, 7.Davancer dans le degré de détail du planning, 8.Dinitialiser un squelette dapplication qui permettra deffectuer une expérimentation ayant pour finalité de valider les principes de lIHM, larchitecture technique, et la cartographie fonctionnelle,

26 © Reproduction interdite 3.5- Les étapes dun projet La conception fonctionnelle et technique Cette phase concerne lélaboration des éléments suivants : 1.Architecture applicative (impact issu du découpage fonctionnel), 2.Spécifications techniques, 3.Spécifications fonctionnelles détaillées, 4.Interfaces homme machine (maquettage statique et / ou dynamique), 5.Construction du modèle de données MCD et du MPD, 6.Rédaction des jeux et des plans de tests dassemblage,

27 © Reproduction interdite 3.5- Les étapes dun projet La Réalisation Pour certains projets, il est parfois recommandé de réaliser une maquette opérationnelle ne comportant que quelques développements. Cette étape aura pour objectif principal de recetter le socle technique et en particulier de vérifier la montée en charge, ainsi que la conformité des travaux en fonction des attentes du client. Elle permettra à larchitecte système et aux équipes systèmes du client de valider et / ou damender les éléments darchitecture ainsi quéventuellement quelques consignes de développement. En outre, elle permettra de définir larchitecture réseau nécessaire tant en terme de débit que de temps de réponse. Le lotissement du projet sera défini au cours de la phase dInitialisation.

28 © Reproduction interdite 3.5- Les étapes dun projet Les tests Cette étape consiste à concevoir et exécuter un plan de tests. Dans la pratique, il convient dintégrer les développements unitaires au sein de larchitecture technique cible, tout en testant la cohérence fonctionnelle et technique globale de lapplication, avant livraison et installation sur le site du client. Les tests réalisés seront : Un test spécifique du Framework après développement sur la base de la conception définie au début de la conception fonctionnelle et technique, Un test de réception des composants achetés pour le projet, Les tests unitaires des fonctions développées, Les tests dassemblage sur les plates-formes de développement avec données réelles permettant entre autres le test des procédures de reprise, Pour la maquette opérationnelle, un test de charge initialement prévu sera réalisé, Les test dintégration sur les plates-formes, Les tests de charge sur chacun des lots sachant que pour une architecture 3 tiers, cette partie nécessite plutôt un monitorat détaillé des composants serveurs et réseau lors de linstallation. Si nécessaire, un test sur automate pourra être prévu,

29 © Reproduction interdite 3.5- Les étapes dun projet Tests des composants externes Lobjectif de cette étape est de sassurer que lensemble des composants externes à lapplication sont conformes sur les plans fonctionnel et métier aux spécifications prévues dans les phases de conception. Sur un plan technique, il sagit de sassurer que le composant technique ne crée aucune interaction non-souhaitée (ou interférence) de par son installation, registration, instanciation,… Les composants externes sont par exemple et suivant les technologies employées des composants OCX, VBX, DLL, EJB,…. La qualification technique pourra avoir été réalisée dans le cadre dun projet antérieur

30 © Reproduction interdite 3.5- Les étapes dun projet Tests Unitaires Ces tests sont réalisés au fil de leau par léquipe de développement. Chaque personne de cette équipe consigne que le développement de la fonction X a été réalisé par lui et après exécution en environnement de développement ou sur simulateur. Il sagit de confirmer que cette fonction est conforme aux spécifications fonctionnelles et techniques décrites. Tests dassemblage Ces tests sont réalisés par le chef de projet ou sous son autorité par une personne de léquipe de développement détachée sur cette mission. Cette phase permet de sassurer que lensemble des composants techniques développés ou acquis sinterfacent correctement : lapplication fonctionne sans défaillance, les résultats attendus sont conformes sur les axes règles de calcul et règles de gestion. Cette phase seffectue sur le jeu dessai de développement.

31 © Reproduction interdite 3.5- Les étapes dun projet Tests dintégration Cette phase de test seffectue sur une plate-forme dintégration déclarée conforme par le client à lenvironnement de production. Cela concerne tant les aspects techniques (OS serveur, base, client) que les interfaces (entrantes notamment), ainsi que le jeu de données. Tests de charge Lobjectif de cette phase est deffectuer une montée en charge des données entrantes et existantes dans lapplication. La base de données sera chargée avec une volumétrie équivalente au fonctionnement nominal de lapplication. Les transactions devront seffectuer dans les temps de réponses prévues lors de lélaboration du cahier de charge. A défaut de temps de réponse décrit, lapplication devra prouver quelle fournit les réponses attendues avec la volumétrie nominale.

32 © Reproduction interdite 3.5- Les étapes dun projet Test de stress Cette étape permet de simuler lintégralité des accès (TP et Batch) effectués simultanément sur lapplication sur une période de référence, généralement une période de pointe pour lapplication. Ces tests sont généralement réalisés à laide dun automate qui enchaîne des scénarios de tests définis au préalable. Les tests de stress peuvent également servir au remplissage de la base ; Les tests de charges seront alors effectués à lissue des tests de stress.

33 © Reproduction interdite 3.5- Les étapes dun projet La recette interne Il sagit dune validation interne, effectuée par la direction projet, des livrables avant fourniture au client du lot réalisé. La recette interne assure que le chef de projet en charge du projet suit le déroulement des actions de la contractualisation à la mise en œuvre du résultat prévu. La recette fonctionnelle La recette fonctionnelle est effectuée par le client et plus spécifiquement par le Chef de Projet Utilisateur du Client. Elle est usuellement effectuée sur la plate-forme de développement ou la plate-forme dintégration. Les compléments et/ou évolutions détectées lors de la recette fonctionnelle peuvent donner lieu à létablissement davenant(s) au contrat

34 © Reproduction interdite 3.5- Les étapes dun projet Lintégration Cette opération sera placée sous la responsabilité du chef de projet client accompagné par lArchitecte Système notamment pendant les phases dinstallation et de démarrage de la plate-forme. La correction des dysfonctionnements doit être assurée de manière réactive. Le client pourra être assisté sur les différents dans la réalisation des tests de recette du système, et dans la mise au point globale du système. La conversion et la reprise des données Dans le cas dune migration de système avec reprise des données existantes, la phase de conversion et reprise est considérée comme un sous-projet du projet de réalisation. La reprise des données donne lieu à lélaboration de spécifications, développement et tests identifiés. Les règles que doivent respecter les données en entrée ainsi que leur structure sont fournies par le client. Un taux de rejet peut être admis en production. Il devra être fixé au plus tard au démarrage de cette phase.

35 © Reproduction interdite 3.5- Les étapes dun projet Le site pilote Dans le cas dun site pilote : pour chacun des lots produits et des évolutions en garantie, un site pilote sera réalisé. Le site pilote pourra être installé après la validation du Procès Verbal (PV) de recette dintégration. Cette étape permet de vérifier le fonctionnement réel du projet. Ce mode de fonctionnement saccompagne dune exploitation sous contrôle. Le déploiement technique Ces étapes sont placées sous la responsabilité du client, plus précisément les équipes Installations pour le déploiement technique, et des équipes déploiements / Formation.

36 © Reproduction interdite 3.5- Les étapes dun projet La formation La formation peut prendre plusieurs formes. Elle peut viser les utilisateurs mais aussi les équipes techniques (exemple : les équipes de maintenance). Différentes déclinaisons sont envisageables en fonction du contexte projet considéré : Les sessions de formation : elles sappuient sur lalternance dun enseignement théorique et des mises en pratiques immédiates (TP). Les sessions de formation doivent impérativement être intégrées dès le début dans le plan projet : pour quelles soient optimales, les formations doivent être synchronisées avec le déploiement sur sites ou le passage en maintenance (formation des équipes techniques). Elle nécessite également la mise en place dune infrastructure dédiée (logistique : salle de formation équipée, organisationnelle : disponibilité complète des stagiaires, technique : disponibilité de plates formes dédiées). Le transfert de compétences : il est principalement dédié aux équipes techniques dexploitation ou de maintenance. Lobjectif est de traiter sur la fin du projet lensemble des points critiques du projet en parfaite transparence. Laccompagnement en production : il se met en place lorsque la montée en charge et/ou le déploiement représente(nt) un enjeu majeur et critique du projet. Ainsi, lensemble des anomalies pouvant survenir sont traitées en collaboration directe avec léquipe projet.

37 © Reproduction interdite 3.5- Les étapes dun projet Documentations Dossier de Conceptions Fonctionnelles et Techniques Ce dossier décrit lensemble des transactions, éditions, traitements batch de lapplication cible. Le dossier de conception fonctionnelle et technique décrit également lensemble des règles de gestion, de calcul, denchaînement et dergonomie à réaliser. Il constitue la référence pour la recette. Dossier de recette Le dossier de recette consigne lensemble des remarques (bloquantes, mineures, évolutions) identifiées lors de la recette fonctionnelle. Il reprend ou fait référence aux règles de gestion décrites dans le dossier de Conceptions Fonctionnelles et Techniques.

38 © Reproduction interdite 3.5- Les étapes dun projet Documentations Cahier du développeur Le cahier du développeur précise larchitecture générale du code de lapplication, les composants techniques utilisés, les options de développement (option du projet, de compilation, versions de shells, composants, …) ainsi que les règles particulières utilisées. Son principal objectif est de permettre à un développeur reprenant le projet de démarrer dans les meilleures conditions. Préconisations techniques Ce document reprend lensemble des préconisations nécessaires au bon fonctionnement de lapplication dans lenvironnement de production. Procédures dinstallation Sont décrits dans ces documents lensemble des procédures nécessaires à linstallation de lapplication ainsi que des composants nécessaires à linstallation. Dans le cas dune installation automatisée, elle décrit le chemin de la routine dinstallation à lancer, les principaux écrans et le résultat attendu in fine.

39 © Reproduction interdite 3.5- Les étapes dun projet Documentations Guide de dépannage Ce guide reprend ou décrit les principales opérations permettant de débloquer une situation dincident quil soit technique ou issu dun blocage fonctionnel. Exemple : procédure de compactage / réparation de base, dé fragmentation de base, reconstruction dindex, réinstallation de composant et/ou doutil, déverrouillage ou modification dindicateur en base,… Cahier dexploitation Ce cahier doit contenir lensemble des procédures assurant lexploitation normale de lapplication et sa disponibilité prévue pour les utilisateurs. On y trouvera notamment : les procédures spécifiques de sauvegarde spécifiques si elles ne sont pas prises en charge par le système, les procédures de compactage, de ré-indexation, les procédures de purge, les procédures de reprise en cas dindicent, les procédures de relance dune procédure normalement automatique

40 © Reproduction interdite 3.5- Les étapes dun projet Documentations Support de formation utilisateurs Ce document permet la formation des utilisateurs aux outils. Sauf stipulation particulière, il ne comporte pas de volet métier. Support de formation technique Ce document permet la formation des acteurs techniques en vue de la reprise du projet par une autre équipe. Son contenu est détaillé au démarrage du projet, notamment dans le cadre dun transfert de compétences intégrés dès le début au périmètre du projet.

41 © Reproduction interdite Logiciels de gestion de version : CVS (Concurrent Versions System), Bitkeeper, SourceSafe Logiciels de gestion de configuration Par rapport aux précédents, apportent des outils permettant : 1.de gérer les demandes de modification du système à faire évoluer. 2.de mettre en correspondance les demandes de modifications avec les changements apportés au système Exemples : Synergy (Telelogic), PVCS, Perforce ou ClearCase 4- Outils de versionning

42 © Reproduction interdite ALTRAN Nord – TI Altran Nord / Adventec Parvis de Rotterdam 1606 Tour Lilleurope Tél. : +33 (0) Fax. : +33 (0)


Télécharger ppt "© Reproduction interdite ALTRAN Nord – TI Introduction aux méthodologies de développement Cours HEI 2009-2010."

Présentations similaires


Annonces Google