Méthodologie de Conception: 2 Tracks Unified Process

Page 1 sur 18Lecteur de document UniversityLib

Méthodologie de Conception: 2 Tracks Unified Process

Software Development Methodology · notes

<!-- Slide number: 1 --> # Méthodologie de Conception 2 Tracks Unified Process DSI3 2017-2018

Notes:

<!-- Slide number: 2 --> # Plan Présentation de 2TUP

2TUP, un processus UP

2TUP et UML

Les apports de 2TUP

2TUP en détail

2TUP dans la pratique

<!-- Slide number: 3 --> # Introduction

Scrum RUP XUP 2TUP ASD EssUP Extreme Programming AUP EUP Crystal UP DSDM Méthodes unifiées Méthodes agiles

Notes:

<!-- Slide number: 4 --> # Présentation de 2TUP Processus créé par Valtech

Pourquoi 2TUP ?

Réponse aux contraintes de changement continuel imposées aux SI des entreprises

![G:\Users\hamzus\AppData\Local\Temp\Rar$DR01.498\industry.png](Picture2.jpg) SI Contraintes fonctionnelle Contraintes techniques

Notes: Valtech est un groupe français de conseil en technologies, e-business, management, et de formation professionnelle. C’est un grand groupe (1100 employés) présent à l’international

Je ne m’étends pas sur ce sujet, Nadia en parlera plus longuement par la suite

<!-- Slide number: 5 --> # Présentation de 2TUP Définition d’un processus :

Processus

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

Contraintes

Délais Coûts

Notes: 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

<!-- Slide number: 6 --> # Présentation de 2TUP

Définition d’un processus unifié

Plusieurs processus unifiés, pas un seul

Trame commune des meilleures pratiques de développement

Caractéristiques d’un processus unifié

Incrémental

Itératif

Piloté par les risques

Orienté composant

Orienté utilisateur

Notes: 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

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 : on a vu qu’ils sont 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

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.

Publicité

Orienté utilisateur : Les utilisateurs sont à l’origine du développement

On développera par la suite les caractéristiques qui nous sont apparues comme les plus importantes

<!-- Slide number: 7 --> # Présentation de 2TUP

Axe fonctionnel La réalisation du système consiste à fusionner les résultats des deux branches

Axe technique Idée de base

Notes: 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 fonctionnel Un axe technique

La réalisation du système consiste à fusionner les résultats des deux branches

D’où…

<!-- Slide number: 8 --> # Présentation de 2TUP

![](Picture2.jpg)

Notes: Une forme en Y

Du coté de la branche fonctionnelle : Capture des besoins fonctionnels : elle aboutit à un modèle des besoins focalisé sur le métier des utilisateurs. Elle minimise le risque de produire un système inadéquat avec les besoins des utilisateurs. De cette capture, la MOE consolide les spécifications et en vérifie la cohérence et l’exhaustivité. -Analyse : étude des spécifications afin de savoir ce que le système va réellement réaliser en termes de métier. Découpage en composants.

Du coté de la branche technique : -Capture des besoins techniques : recensement des outils, des matériels et des technologies à utiliser ; des contraintes (temps de réponse maximal, contraintes d’intégration avec l’existant) -> tout cela va aboutir à une première conception de l’architecture technique -Conception générique : Découpage en composants nécessaires à la construction de l’architecture technique. Il est généralement conseillé de réaliser un prototype pour assurer la validité de l’architecture. Cette étape permet de minimiser l’incapacité de l’architecture technique à répondre aux contraintes opérationnelles

Enfin, la branche du milieu : -Conception préliminaire : étape délicate durant laquelle on intègre le modèle d’analyse dans l’architecture technique. Le but ici est de savoir dans quel composant technique on met nos fonctionnalités issues de l’analyse. -Conception détaillée : conception de chaque fonctionnalité -Etape de codage : phase de programmation de ces fonctionnalités, avec des tests au fur et à mesure -Etape de recette : phase de validation des fonctions du système développé

<!-- Slide number: 9 --> # 2TUP, un processus UP

Un processus piloté par les risques

4 principaux risques

Les solutions apportées par ce processus

L’inadéquation aux besoins des utilisateurs

L’incapacité de l’architecture technique à répondre aux contraintes opérationnelles

Le non respect des coûts et délais

Le manque de qualité

Politique d’incréments

Gestion prioritaire des deux premiers risques

Notes: Gestion prioritaire des deux premiers risques : en effet, on a vu dans la slide précédente que la branche fonctionnelle permettait de minimiser le risque de produire un système qui ne satisferait pas les besoins des utilisateurs et que la branche technique permettait de minimiser le risque d’ incapacité de l’architecture technique à répondre aux contraintes opérationnelles, avec notamment la réalisation d’un prototype.

Politique d’incréments : permet de classer les différents modules, et donc de traiter en priorité les problèmes présentant le plus de risque. Ainsi, si dès le premier module, on se rend compte qu’on ne sait pas faire, ou qu’on ne peut pas faire dans les délai et budget impartis, on doit réellement se poser les questions quant à la continuité du projet. De plus, comme nous l’avons dit tout à l’heure, le suivi des incréments constitue un excellent contrôle des couts et délais.

<!-- Slide number: 10 --> # 2TUP, un processus UP

Un processus piloté par les exigences des utilisateurs

La branche gauche est chargée de capturer les besoins fonctionnels auprès des utilisateurs consommateurs

La branche droite est chargée de capturer les besoins techniques auprès des utilisateurs exploitants

Deux types d’acteurs

L’utilisateur consommateur des fonctions du système

L’utilisateur exploitant le système Les utilisateurs sont à l’origine de la conception

Notes: L’utilisateur consommateur des fonctions du système : il correspond à un poste, un rôle ou un métier dans l’entreprise. Il attend du système qu’il lui apporte une plus-value dans l’exercice de sa profession. L’utilisateur exploitant le système : rôle technique et opérationnel commun à tous les SI, exploitant/administrateur. Lui attend du système des performances, une tenue à la charge, une sécurité d’accès… Cet utilisateur est souvent négligé dans les autres méthodes de gestion de projets.

Cette capture se fera grâce à l’établissement des cas d’utilisation.

Cette capture se fera grâce à l’établissement des cas d’utilisation techniques, qui aboutiront ensuite à des spécifications d’architecture.

<!-- Slide number: 11 --> # 2TUP et UML Définition de Unified Modeling Langage :

UML

Buts

Langage de modélisation graphique et textuel

comprendre et décrire des besoins, spécifier et documenter des systèmes, concevoir des solutions,

Unification des notations et concepts orientés objet Moyen d’établir le suivi des décisions prises, depuis la spécification jusqu’au codage

Publicité

Notes: Je vais commencer par une rapide description d’Uml :

Ce langage a de nombreux objectifs : comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures de logiciel, concevoir des solutions et communiquer des points de vue

Moyen d’établir le suivi des décisions prises, depuis la spécification jusqu’au codage -> fil tendu entre les différentes étapes de construction, qui permet de remonter du code aux besoins

<!-- Slide number: 12 --> # 2TUP et UML

Le recours à la modélisation est une pratique indispensable au développement

Relation entre 2TUP et UML

UML est le langage de modélisation objet standard de ce processus

Correspondance entre les différents diagrammes d’UML et les étapes de 2TUP

Notes: Un modèle est une abstraction du résultat, dont le but est de documenter, de prévoir, d’étudier, de collecter ou d’estimer les informations d’un système. C’est donc la vue sur une spécification ou sur une solution de système, pris à un niveau de détail pertinent pour exprimer ou concevoir la cible de l’étape en cours

UML est le langage de modélisation objet standard de ce processus -> d’ailleurs, c’est ce processus qui est utilisé dans « UML en action »

<!-- Slide number: 13 --> # 2TUP et UML

Capture des besoins fonctionnels

Diagramme des cas d’utilisation, Diagrammes de séquence, Diagrammes de collaboration

Analyse

Diagramme de classes, Diagrammes d’états transition

Capture des besoins techniques

Diagramme des cas d’utilisation

Conception générique

Diagramme de déploiement

Conception préliminaire

Diagramme de composants, Diagramme de déploiement

Conception détaillée

Diagramme de classes, Diagramme de séquence, Diagramme de collaboration, Diagramme d’états, Diagramme d’activités, Diagrammede composants

Notes: Donc on voit que du côté fonctionnel, dès la première étape, on fait le diagramme de cas d’utilisation (qui énonce toutes les fonctionnalités que doit faire le système) et on fait une première ébauche des diagrammes de séquence et des diagrammes de collaboration pour saisir les scénarios d’utilisation du système. Lors de la seconde étape, on commence à faire un premier diagramme de classes (il représente les classes intervenant dans le système) et les diagrammes d’états (le diagramme d’états est un diagramme déterministe qui décrit sous forme de machine à états finis le comportement du système ou de ses composants).

Du côté technique, on ajoute les fonctionnalités techniques au diagramme de cas d’utilisation lors de la première étape. Lors de la seconde, on fait une ébauche du diagramme de déploiement (qui représente la structure du réseau informatique dans lequel va s’insérer l’application à développer et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux).

Puis, à la jonction des deux branches, lors de la conception préliminaire, on complète le diagramme de déploiement et on fait le diagramme de composants (qui représente la structure physique des composants du système. Les composants du système sont les fichiers, les bibliothèques, les bases de données). Enfin, lors de la conception détaillée, on affine la majorité des diagrammes effectués précédemment afin de permettre aux développeurs de coder les fonctionnalités de manière très précise et adaptée aux besoins des utilisateurs.

(Le diagramme d’activités permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.)

<!-- Slide number: 14 --> # Les apports de 2TUP Capitalisation de la connaissance de l’entreprise

investissement pour le moyen et long terme Capitalisation d’un savoir-faire technique

investissement pour le court et moyen terme

Notes: Branche gauche : elle capitalise les connaissances de l’entreprise et représente donc un investissement pour le moyen et long terme. Les fonctionnalités du SI sont en effet indépendantes des technologies utilisées.

Branche droit : elle capitalise le savoir-faire technique de l’entreprise et représente donc un investissement pour le court et moyen terme. Les techniques développées pour le système peuvent l’être de manière indépendante des fonctions à réaliser

Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux SI de l’entreprise : Changement de technologies : en effet, une entreprise qui maintiendrait son modèle fonctionnel peut le réaliser sous différentes technologies : il suffit de « greffer » une nouvelle architecture technique pour mettre à jour un système existant. -Ajout de fonctionnalités : en effet, on peut réutiliser une architecture technique

Pour résumer, il permet à la fois de capitaliser la connaissance métier sur la branche gauche et de réutiliser un savoir-faire technique sur la branche droite. En d’autres termes, un meilleur contrôle sur les capacités d’évolution et de correction de tels systèmes.

<!-- Slide number: 15 --> # 2TUP en détail Capture des besoins

Étude préliminaire

Besoins fonctionnels

Besoins techniques

Cahier des charges

Cas d’utilisations

Spécifications techniques

Acteurs

Publicité

Classes candidates

Spécifications de l’architecture

Messages

Validation et consolidation

Cas d’utilisation techniques

Modélisation du contexte

Notes: Hamza jusqu’à la fin

<!-- Slide number: 16 --> # 2TUP dans la pratique Analyse

Découpage en catégorie

Modèle statique

Modèle dynamique

Classes

Scénarios

Découpage en catégorie

Associations

Diagrammes états transitions

Opération

Diagrammes d’interaction

Dépendances

Optimisation

Validation

Notes:

<!-- Slide number: 17 --> # Conception d’architecture

Conception générique

Conception préliminaire

Conception détaillée

Tout

Modèle de déploiement/ exploitation

Framworks techniques

Interfaces utilisateurs

Modèle logique

Interface catégories

Développement de prototype

Conception IHM

<!-- Slide number: 18 --> # Conclusion

Avantages d’une méthode

Grand projet et SI complexe

Gestion des risques

Management de projet

UP

Notes: Avantages d’une méthode : d’où on vient, où en va Gestion des risques : prise en charge de deux axes du projet Pratiques agiles : itératif, incrémental axée sur le développement Management de projet : découpage permet une meilleure gestion