Méthodologie 2 Track Unified Process
•Transferir como PPT, PDF•
9 gostaram•21,003 visualizações
Adopter une méthodologie pour développer un système est indéniable au risque de vous planter, cette présentation étale sur ses slides la méthodologie 2TUP, qui fait partie de la famille des Processus unifiés basés sur UML
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Méthodologie 2 Track Unified Process
Semelhante a Méthodologie 2 Track Unified Process (20)
Mais de Zakaria Bouazza
Último
Último (13)
Méthodologie 2 Track Unified Process
- 1. 2TUP 2 track unified process PREEMPTIF@GMAIL.COM
- 2. Problématique: • Complexité croissante des SI > Définir des méthodes. • 50 méthodes en 1994. > Notation et processus spécifique. Uml a ouvert dès lors le terrain > Unification des meilleurs pratiques.
- 3. Un processus d’abord, c’est quoi? Processus Contraintes Objectif
- 4. Processus…Unifié Plusieurs processus unifiés, pas Trame commune des meilleures un seul pratiques de développement UML Piloté par Orienté Orienté Incrémental Itératif utilisateur les risques composant
- 5. 2T + UP= 2TUP • Processus créé par ValTech Oui, mais pourquoi 2TUP? Réponse aux contraintes de changement continuel imposées aux SI des entreprises Contraintes Contraintes Contraintes Contraintes techniques techniques fonctionnelle fonctionnelle
- 6. Axe fonctionnel La réalisation du système consiste à fusionner les résultats des deux branches Axe technique
- 8. 2TUP et la réutilisabilité.
- 9. Un processus itératif et incrémental Une itération est une séquence distincte d'activités qui produit des améliorations ou d'évolutions du système et évalué par les utilisateurs. Un incrément est la différence entre 2 itérations succesives. De plus, le suivi des incréments constitue un excellent contrôle des couts et délais
- 10. Piloté par les risques? Incapacité Imprécision d’intégrer les fonctionnelle technologies
- 11. Un processus piloté par les exigences des utilisateurs Mettre l’accent sur l’exigence des utilisateurs: • Utilisateur Consommateur de fonctions du système. • Utilisateurs exploitant le système (Administrateurs…)
- 12. Voyons un peu les détails!
- 13. 2TUP et UML • Diagramme des cas d’utilisation, Capture des besoins • Diagrammes de séquence, fonctionnels • Diagrammes de collaboration • Diagramme de classes, Analyse • Diagrammes d’états transition Capture des besoins • Diagramme des cas d’utilisation techniques Conception • Diagramme de déploiement générique Conception • Diagramme de composants, préliminaire • Diagramme de déploiement • Diagramme de classes, • Diagramme de séquence, • Diagramme de collaboration, Conception détaillée • Diagramme d’états, • Diagramme d’activités, • Diagrammede composants
- 14. Pour résumer: Plusieurs UP: CASCADE,XP, RUP..
Notas do Editor
- La complexité croissante des systèmes informatiques a conduit les concepteurs à s’intéresser aux méthodes. On a comptabilisé en 1994 jusqu’à 50 méthodes objets différentes. Chaque méthode se définit par une notation et un processus spécifique, mais la plupart convergent en ce qui concerne la sémantique de leur notation. Néanmoins le travail de définition d’un processus est toujours resté dificile, mais UML a ouvert le terrain de l’unification en fusionnant les notations et en apportant précision et rigueur à la définition des concepts introduits. Il a apporté un élan sans précédent à la technologie objet, puisqu’elle y propose un standard à respecter. Il reste cependant à définir le processus pour réellement capitaliser des règles dans le domaine du développement logiciel. On ne pourrait définir un seul processus ca la variété des systèmes ne le permet pas, donc l’unification des processus a été remplacé par l’unfication des meilleurs pratiques.
- Séquence d’étapes, en partie ordonnées Objectif : obtention d’un système logiciel ou évolution d’un système existant qui satisfasse le client (autrement dit, que le résultat obtenu répond bien aux besoins des utilisateurs) Contraintes : Respect des délais Respect des coûts
- Plusieurs processus unifiés, pas un seul : il y a tellement de systèmes, de techniques variés qu’il serait impensable d’envisager un processus qui soit adapté à tous les projets possibles, autrement dit que le développement avec ce processus réponde bien aux objectifs tout en respectant les contraintes; Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement, et non comme l’ultime tentative d’élaborer un processus universel. C’est un Processus de développement logiciel construit sur UML Tout processus unifié doit répondre aux caractéristiques suivantes: Incrémental : définir des incréments de réalisation est en effet la meilleure pratique de gestion des risques d’ordre à la fois technique et fonctionnel. Chaque incrément confirme la preuve de faisabilité auprès de l’équipe de développement et du client. De plus, le suivi des incréments constitue un excellent contrôle des couts et délais Itératif : non seulement à chaque cycle on ajoute une fonctionnalité mais de plus on améliore les fonctionnalités précédentes Piloté par les risques : qui sont d’ailleurs nombreux dans le développement logiciel On peut citer par exemple: inadéquation aux besoins des utilisateurs, le non respect des couts et délais Les causes majeures d’échec d’un projet logiciel doivent être écartées en priorités ; les deux principales causes sont l’incapacité de l’architecture technique à répondre aux contraintes opérationnelles et l’inédaquation du développement aux besoins utilisateurs. Orienté composant : Un composant est un module indépendant, qui pourrait servir pour d’autres projets. Le découpage en modules de ce type de processus se fait aussi bien en modélisation qu’en production, et permet la réutilisation logicielle . Orienté utilisateur : Les utilisateurs sont à l’origine du développement, car la spécification et la conception sont construites à partir des modes d’utilisation attendus par les acteurs du système.
- Qui est un groupe français de conseil en technologies, présent à l’international. Pourquoi 2tup et non pas un autre processus unifié? Justement pour répondre aux contraintes de changement continuel imposées aux SI des entreprises. En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins. Il s’agit des chemins « fonctionnels » et « d’architecture technique », qui correspondent aux deux axes des changements imposés au système informatique.
- Idée de base du 2TUP : toute évolution imposée au SI peut se décomposer et se traiter parallèlement, suivant 2 axes (« 2 tracks ») : Un axe appelé fonctionnel et un autre technique La réalisation du système consiste à fusionner les résultats des deux branches D’où…
- La branche gauche (fonctionnelle) comporte: * La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. (use case) Ceci va réduire le risque de produire un système qui sera inadapté. Et en même temps, Le maître d'oeuvre vérifie si tous les besoins sont cohérents et exhaustives. * l’analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les résultats de l’analyse ne dépendent d’aucune technologie particulière. La branche droite (architecture technique) comporte en un premier lieu de capturer les besoins techniques, càd recenser les outils et les matériels, et prendre en compte l'intégration si il y'a un existant (ancien si à améliorer). et en deuxième lieu la conception générique, qui va définir les composants nécessaires à la construction de l'architecture technique. Il est trés important de réussir cette phase qu'il est conseillé de réaliser un prototype pour le valider. La branche du milieu comporte : • la conception préliminaire, qui représente une étape délicate, car elle intègre le modèle d’analyse dans l’architecture technique de manière à tracer la cartographie des composants du système à développer ; • la conception détaillée, qui étudie ensuite comment réaliser chaque composant; • l’étape de codage, qui produit ces composants et teste au fur et à mesure les unités de code réalisées ; • l’étape de recette, qui consiste enfin à valider les fonctions du système développé.
- C’est d’ici qu’on parle de changement continuel des systèmes d’informations. On a parlé tout à l'heure de réutilisabilité, en effet l'indépendance entre les 2 branches permet de réutiliser la branche fonctionnelle sous différentes technologies. Il suffit juste de greffer la nouvelle architecture. et généralement cette branche fonctionnelle est pour le moyen et le long terme. La branche technique, quand à elle, n'est pas si importante, et elles sont aussi utilisables. Il existe même des architectures techniques prêtes à intégrer. L'évolution des architectures laisse penser aussi que la branche technique est à court terme qui change constamment.
- . L’itération 1 développe les fonctions de validation du principe du système et intègre les outils prévus pour le développement. • L’itération 2 est focalisée sur l’architecture ; elle peut être considérée comme le prototype de réalisation technique. • L’itération 3 avance dans la réalisation des fonctions les plus prioritaires de manière à présenter une première version de déploiement pour les utilisateurs. Elle permet entre-temps d’améliorer et de compléter l’architecture technique. • Les itérations suivantes avancent dans la réalisation des fonctions jusqu’à l’obtention complète du système initialement envisagé.
- La configuration du processus en Y a également été conçue pour gérer en priorité et en parallèle les risques de nature fonctionnelle et technique : • d’une part, les risques d’imprécision fonctionnelle, et d’inadéquation aux besoins sur la branche gauche, • d’autre part les risques d’incapacité à intégrer les technologies, et d’inadaptation technique sur la branche droite. L’exigence d’aboutir à une itération au début permet également d’évaluer très rapidement la capacité à intégrer les technologies nécessaires au projet. Pour décider s’il faut continuer ou non le projet ?
- Un processus piloté par les exigences des utilisateurs Comme nous l'avons vu la probabilité des risques est élevé comme la non adéquation technique et fonctionnelle aux besoins des utilisateurs. Donc on met l'accent sur les exigences des utilisateurs qu'on distingue: L'utilisateur consommateur de fonctions du système, qui correspond généralement à un poste, ou des rôles. L'utilisateur exploitant le système, qui correspond au rôle technique, car en C/S, on attend des performances et la sécurité. Donc l'axe technique permet de voir les administrateurs techniques souvent oublier lors de la livraison
- Sur la branche gauche, pour la capture des besoins fonctionnels, les cas d’utilisation nous donnent métier des fonctions du système. De là vont découler des classes d’analyse qui sont les concepts utilisés par l’utilisateur et des scénarios qui établissent les comportements attendus du système. Sur la branche droite, pour la capture des besoins techniques, la nature des cas d’utilisation a été quelque peu adaptée en fonction des plus-values opérationnelles du système pour ses exploitants. Ces cas vont nous permettre de spécifier l’architecture qui sera sous forme de couches logicielles. Les cas d’utilisation techniques permettent de concevoir les classes techniques pour les contraintes opérationnelles du système. • Lors de la conception préliminaire, les classes obtenues naissent de la distribution des classes d’analyse sur les couches logicielles. Les interactions entre classes de conception permettent de consolider et de vérifier à terme la conception des cas d’utilisation fonctionnelle tenant compte des contraintes opérationnelles. Le pilotage par les cas d’utilisation consiste justement à ordonner les cas d’utilisation par priorité, En réalisant le plus prioritaire d’abord. Pour ajouter le maximum de valeur ajoutée au système, on rentabilise plus rapidement le développement, ce qui va nous permettre de réduire les risques