Préface de Philippe Desfray - Coauteur du standard UML - Directeur R&D SOFTEAM


Ce livre propose UML à toute personne soucieuse de mettre en œuvre ce langage de formalisation lors d'une analyse du métier : analystes et concepteurs bien entendu mais aussi architectes, chefs de projet, responsables MOE et Business Analysts.

Le pourcentage de projets réussis, c'est-à-dire respectant leur QCDP (Qualité Coûts Délai Périmètre) est estimé à 30% par le célèbre Chaos Report du Standish Group. Ce chiffre reste étonnamment stable depuis plusieurs années, malgré le progrès des normes et l'extension des certifications.

L'auteur est convaincu de l'efficacité d'UML comme outil de construction de solutions et comme facteur de réussite d'un projet. La démarche qu'il propose démarre des préoccupations exclusivement métier (les considérations techniques ne seront pas traitées dans ces pages) et l'auteur décrit une méthode accessible, satisfaisant à la fois les métiers et les IT : observer pour formaliser (« Comment ça va marcher ? »), formaliser pour comprendre (« A quoi ça va servir ? »), comprendre pour agir (« Comment ça va être fait ? »).

Dans ce livre, il expose les caractéristiques vraiment utiles d'UML (en version 2.5), et décrit sa mise en œuvre, étape par étape,  au sein d'un projet « fil rouge ». Il propose l'utilisation de cet outil dans plusieurs contextes : gestion de projet, évaluation des charges, tests et recettes applicatives, rédaction des cahiers des charges.

Des éléments complémentaires sont en téléchargement sur le site www.editions-eni.fr.


Les chapitres du livre :
Préface – Introduction – Ingénierie de l'analyse du métier – Description dynamique (les acteurs agissent) – Description dynamique (l'information se transforme) – Description fonctionnelle du système – Description structurale du système – Description collaborative du système – UML au service de l'architecture – Rédiger le cahier des charges fonctionnel d'un projet – Les impacts d'UML sur la recette d'un livrable – Évaluation des charges d'un projet spécifié en UML

Téléchargements

• Des fichiers complémentaires (1,54 Mo)

Préface

1. Introduction

Introduction

1. Pourquoi ce livre ?
   1. 1. Pourquoi UML ?
   2. 2. Pourquoi la business analysis (analyse du métier) ?
   3. 3. La génèse d’UML
2. Fil rouge : la société LOCA’ROYANS
   1. 1. L’activité de LOCA’ROYANS
   2. 2. Les responsables opérationnels de LOCA’ROYANS
   3. 3. Compte rendu des entretiens : extraits
      1. a. L’informatique : état actuel
      2. b. Quelques anomalies de fonctionnement énumérées par M. Centplont
      3. c. Attentes émanant des métiers

Ingénierie de l'analyse du métier

1. Pourquoi l’analyse du métier ?
   1. 1. Les compétences de l’analyste dumétier
   2. 2. L’analyste du métier et le chefde projet
   3. 3. Les facteurs de réussite des projets
2. Les changements et les adaptations de l’entreprise par les projets
   1. 1. Adapter l’entreprise
      1. a. Améliorer en profitant des nouvelles technologies
      2. b. Transformer l’entreprise
   2. 2. Penser une véritable ingénieriedu besoin
      1. a. Collecter les besoins
      2. b. Organiser, hiérarchiser et administrer lesbesoins
      3. c. Formaliser les besoins
      4. d. Vérifier l’implémentationcorrecte des besoins
      5. e. Légitimer les besoins
3. L’International Institute of Business Analysis (IIBA)
4. Le cycle de vie du projet
5. Le cycle de vie de la solution
6. Le cycle de vie des exigences
7. À retenir pour la suite
   1. 1. Le cycle de vie du produit (de la fourniture)
   2. 2. Les différentes parties prenantes d’unprojet

Description dynamique (les acteurs agissent)

1. L'état des lieux
   1. 1. La description dynamique
   2. 2. Les autres descriptions
2. La notion de processus
3. La représentation formelle de processus : trois niveaux
   1. 1. La représentation minimaliste
   2. 2. La représentation développée
   3. 3. La représentation détaillée
4. L'identification des processus d’une entreprise
   1. 1. Le bien ou le service fourni
   2. 2. Les événements déclencheurs
   3. 3. Le nommage des processus
   4. 4. Les trois catégories de processus
   5. 5. Les notions de partie prenante et d’acteur
5. Quelques processus de LOCA’ROYANS
   1. 1. Le processus louer Véhicule
      1. a. La description littérale
      2. b. L’analyse
      3. c. La représentation minimaliste
      4. d. La représentation développée
      5. e. La représentation détaillée
      6. f. Les éléments majeurs du modèle
   2. 2. Le processus restituer Véhicule
      1. a. La description littérale
      2. b. L’analyse
      3. c. La modélisation UML : le diagramme d’activité (représentation détaillée)
      4. d. Les éléments du modèle
      5. e. Le flux de contrôle et les flux d’objets
      6. f. Les processus sont paramétrables
6. Le cycle de vie des objets du métier
7. Le référentiel UML du projet
8. Pour aller plus loin
9. À retenir
10. Les prochaines étapes

Description dynamique (l'information se transforme)

1. L'état des lieux
2. La notion de machine à états
   1. 1. Définition
   2. 2. Le diagramme de la machine à états
      1. a. Le diagramme minimaliste
      2. b. Le diagramme développé
      3. c. Le diagramme détaillé
      4. d. Les autres renseignements portés par lestransitions
      5. e. La jonction entre les transitions : la complexité événementielle
3. Les propriétés de l’état
   1. 1. La transition et le comportement
      1. a. L’autotransition
      2. b. La transition interne
   2. 2. La hiérarchie entre états (automatehiérarchique)
   3. 3. Les actions et les activités
   4. 4. Les pseudo-états
      1. a. Les pseudo-états attachés aux fluxde contrôle
      2. b. Les pseudo-états attachés aux étatscomposites
      3. c. Les états concurrents d’un systèmecomplexe
4. La description de la sémantique du système
   1. 1. Les diagrammes de protocole d’utilisation
   2. 2. Les diagrammes de protocole de calcul
5. Pour aller plus loin
   1. 1. Les comportements déterministes et non déterministes
   2. 2. À quels objets UML attacher une machine à états ?
   3. 3. La syntaxe des diagrammes d’activité etde cycle de vie
6. À retenir
7. Les prochaines étapes

Description fonctionnelle du système

1. L'état des lieux
2. La notion de cas d’utilisation
   1. 1. Définition
   2. 2. Exemples de cas d’utilisation
   3. 3. Le cas d’utilisation et processus
   4. 4. Le diagramme des cas d’utilisation
      1. a. Le diagramme minimal
      2. b. Le diagramme développé
      3. c. Le diagramme détaillé
      4. d. Les insuffisances du diagramme des cas d’utilisation
3. La description textuelle des cas d’utilisation
   1. 1. La description textuelle minimale
      1. a. Le cas d’utilisation choisir Véhicule
      2. b. Les règles du contenu
      3. c. Les transactions métier
      4. d. L’interface homme-machine (IHM)
   2. 2. La description textuelle développée
   3. 3. La description textuelle détaillée
      1. a. Le cas d’utilisation choisir Véhicule
      2. b. Les règles de gestion
      3. c. Les exceptions et les extensions
4. Les concepts UML en jeu
   1. 1. Le cas d’utilisation
   2. 2. L’acteur
   3. 3. Les représentations
5. Pour aller plus loin
   1. 1. Le cas d’utilisation et le pilotage de projet
   2. 2. Le cas d’utilisation et l’architecture logicielle
   3. 3. Les cas d’utilisation et le modèle économique
      1. a. Les quatre dimensions d’un modèle économique
      2. b. Le système d’information et le modèle économique
6. À retenir
   1. 1. Le double avantage à tirer d’uneformalisation des cas d’utilisation
   2. 2. Le double devenir des cas d’utilisation

Description structurale du système

1. L'état des lieux
2. Les notions de classe et de composant
   1. 1. Définitions
   2. 2. Exemples
   3. 3. Les diagrammes de classes
      1. a. Le diagramme de classes minimaliste
      2. b. Le diagramme de classes développé
      3. c. Le diagramme de classes détaillé
   4. 4. La notion UML de composant
   5. 5. Les autres notions de la vue statique
      1. a. L’héritage
      2. b. Le diagramme d’instances (ou diagramme d’objets)
      3. c. Les associations qualifiées
      4. d. Les classes associations
   6. 6. Les ports et les interfaces
3. Les concepts UML en jeu
   1. 1. La classe
   2. 2. Le port et l’interface
   3. 3. L’association
   4. 4. Le composant
4. Pour aller plus loin
   1. 1. La classe paramétrée
   2. 2. L’association ternaire
   3. 3. Les stéréotypes et la valeur attachée
      1. a. Le stéréotype
      2. b. La valeur attachée
   4. 4. Le paquetage
5. Conclusion
   1. 1. Les solutions spécifiques : l’analysepréfigure la conception
   2. 2. Les solutions industrielles : adapter afind’adopter
   3. 3. Et toujours : structurer pour simplifier

Description collaborative du système

1. L'état des lieux
2. La notion de comportement
   1. 1. Spécifier un comportement en UML
   2. 2. Synchroniser des comportements
   3. 3. Comportement... de qui ?
   4. 4. Déclencher des comportements : les signaux et les événements
   5. 5. Les interactions
      1. a. Le diagramme de séquences
      2. b. Le diagramme de communication
      3. c. Le diagramme d’interaction
3. Les concepts UML en jeu
   1. 1. L’interaction, le fragment combiné, la lignede vie, l’appel d’interaction (interaction use)
   2. 2. Le message, le signal, l’événement,le comportement
   3. 3. L’invariant d’état
4. Pour aller plus loin
5. Conclusion

UML au service de l'architecture

1. L'état des lieux
2. L’architecture en entreprise
   1. 1. Répondre à deux besoins :généricité et cohérence interne
   2. 2. L’architecture comme source de cohérence et support de la transformation
      1. a. C’est une métaphore...
      2. b. La définition normée de l’architectured’entreprise
      3. c. Les autres définitions : l’architectureselon TOGAF et Praxeme
3. L’architecture en entreprise selon TOGAF et Praxeme
   1. 1. Le framework TOGAF version 9.1
      1. a. La mise en œuvre de TOGAF
      2. b. Les outils proposés par TOGAF
   2. 2. La méthodologie Praxeme
      1. a. Les produits
      2. b. Les procédés et processus
   3. 3. TOGAF et Praxeme : des réponsespertinentes aux exigences de cohérence et de généricité ?
   4. 4. Un retour sur la généricité
      1. a. La généricité selon TOGAF
      2. b. La généricité selon Praxeme
4. Les apports d’UML à l’architecture
   1. 1. Les diagrammes UML natifs au service de l’architecture
      1. a. TOGAF et UML
      2. b. Praxeme et UML
   2. 2. Les diagrammes d’architecture natifs proposéspar UML
      1. a. Le diagramme de composants
      2. b. Le diagramme de structure composite
      3. c. Le diagramme de déploiement
   3. 3. Spécialiser UML : les profils
5. Pour aller plus loin
6. Conclusion

Rédiger le cahier des charges fonctionnel d'un projet

1. L'état des lieux
2. La notion de cahier des charges fonctionnel (CdCF) ?
   1. 1. Définition
   2. 2. Déterminer les fonctions de service a minima
   3. 3. Les autres manières de déterminerles fonctions de service
   4. 4. Naissance du CdCF en France
   5. 5. Qu’est-ce qu’un besoin ?
      1. a. Les besoins implicites et explicites
      2. b. La mise en cohérence des besoins
3. Le plan-type proposé par la norme ISO
   1. 1. Les chapitres du CdCF
   2. 2. Les modèles UML pouvant alimenter ce CdCF
4. Le cahier des charges dans le cycle en V et les cycles agiles
   1. 1. Le cycle en V : exposer le problème,puis le résoudre
      1. a. Le cahier des charges, un référentielaccompagnant le produit toute sa vie
      2. b. Le cahier des charges, un référentiel à deux étages
   2. 2. Les cycles agiles : poser le problèmetout en le résolvant
      1. a. Rejeter le CdCF : un choix managérialqui ne s’impose pas
      2. b. L’agilité appelle à lagénéricité du CdCF, non à sonabolition
5. Livré mais toujours sous responsabilité
6. Pour aller plus loin

Les impacts d'UML sur la recette d'un livrable

1. L'état des lieux
2. Les types fondamentaux de recettes
3. La recette technique d’un produit spécifié en UML
   1. 1. Les tests de cas d’utilisation
      1. a. Le scénario de tests
      2. b. La fiche de tests
      3. c. Le résultat des tests
      4. d. La décision d’acceptation ou derefus du cas d’utilisation
      5. e. L’environnement des tests unitaires
   2. 2. Les tests d’assemblage
      1. a. Ce qui doit être testé en assemblage
      2. b. Ce qu’il est inutile de tester en assemblage
   3. 3. Les autres tests pouvant être facilitéspar UML
   4. 4. Les apports d’UML à la recette technique
4. La priorisation des tests par les risques
   1. 1. L’évaluation du risque
   2. 2. L’analyse de risques de deux cas d’utilisation de LOCA’ROYANS
      1. a. L’identification du risque
      2. b. L’évaluation du risque
      3. c. La priorisation : la comparaison des risques
   3. 3. La répartition des ressources en fonctiondes risques
5. Pour aller plus loin

Évaluation des charges d'un projet spécifié en UML

1. L'état des lieux
2. Comment évaluer les charges
3. Exemple de méthode de répartition proportionnelle
4. Le modèle COCOMO
5. La méthode d’évaluation analytique
6. La méthode des points de fonction
7. L'évaluation de la charge d’un projet UML : la méthode Karner
   1. 1. La détermination du poids non ajusté desacteurs
   2. 2. La détermination du poids non ajusté descas d’utilisation
   3. 3. Le calcul du nombre de points brut du CU
   4. 4. Le calcul du nombre de points ajusté du CU
      1. a. La complexité technique
      2. b. L’environnement
      3. c. Le nombre de points ajusté de deux CU deLOCA’ROYANS
   5. 5. L’évaluation et la ventilation de la charge
8. Pour aller plus loin
9. Conclusion