<!-- 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
 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

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