UML au service de l'analyse des métiers : Business Analysis

Auteur(s) :

Clave, Antoine Découvrir l'auteur

Résumé

Une présentation des caractéristiques d'UML 2.5, et des modes de mise en oeuvre de ce langage de formalisation dans différents secteurs d'activité.

Contributeur(s)
- Desfray, Philippe. Préfacier, etc.
Éditeur(s)
- Éditions ENI
Date
- cop. 2016
Notes
- UML = Unified modeling language
- La couv. porte en plus : "Fichiers complémentaires à télécharger"
- La 4ème de couv. porte en plus : "Sur www.editions-eni.fr : le projet global de modélisation illsutrant, les chapitres du livre (version modelio"
- Contient un "flashcode" permettant d'accéder à un contenu via Internet
Langues
- Français
Description matérielle
- 1 vol. (341 p.) : ill., tabl., graph.; ; 21 cm
Collections
- Collection Datapro
Sujet(s)
ISBN
- 978-2-409-00097-3
Indice
- 681.1 Analyse informatique
Quatrième de couverture
- UML au service de l'analyse des métiers (Business Analysis)
  Ce livre propose UML à toute personne soucieuse de mettre en oeuvre 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 Croup. 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 le : caractéristiques vraiment utiles d'UML (en version 2.5), et décrit sa mise en oeuvre é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
Tables des matières
- - UML
  - au service de l'analyse des métiers (Business Analysis)
  - Préface
  - Introduction
  - 1. Pourquoi ce livre ?13
  - 1.1 Pourquoi UML ?13
  - 1.2 Pourquoi la business analysis (analyse du métier) ?15
  - 1.3 La genèse d'UML16
  - 2. Fil rouge : la société LOCA'ROYANS17
  - 2.1 L'activité de LOCA'ROYANS17
  - 2.2 Les responsables opérationnels de LOCA'ROYANS18
  - 2.3 Compte rendu des entretiens : extraits19
  - 2.3.1 L'informatique : état actuel19
  - 2.3.2 Quelques anomalies de fonctionnement énumérées par M. Centplont19
  - 2.3.3 Attentes émanant des métiers20
  - Chapitre 1
  - Ingénierie de l'analyse du métier
  - 1. Pourquoi l'analyse du métier ?23
  - 1.1 Les compétences de l'analyste du métier24
  - 1.2 L'analyste du métier et le chef de projet25
  - 1.3 Les facteurs de réussite des projets28
  - 2. Les changements et les adaptations de l'entreprise par les projets29
  - 2.1 Adapter l'entreprise29
  - 2.1.1 Améliorer en profitant des nouvelles technologies29
  - 2.1.2 Transformer l'entreprise31
  - 2.2 Penser une véritable ingénierie du besoin34
  - 2.2.1 Collecter les besoins34
  - 2.2.2 Organiser, hiérarchiser et administrer les besoins34
  - 2.2.3 Formaliser les besoins37
  - 2.2.4 Vérifier l'implémentation correcte des besoins38
  - 2.2.5 Légitimer les besoins38
  - 3. L'International Institute of Business Analysis (IIBA)40
  - 4. Le cycle de vie du projet42
  - 5. Le cycle de vie de la solution43
  - 6. Le cycle de vie des exigences44
  - 7. À retenir pour la suite45
  - 7.1 Le cycle de vie du produit (de la fourniture)45
  - 7.2 Les différentes parties prenantes d'un projet46
  - Chapitre 2
  - Description dynamique (les acteurs agissent)
  - 1. L'état des lieux49
  - 1.1 La description dynamique50
  - 1.2 Les autres descriptions50
  - 2. La notion de processus51
  - 3. La représentation formelle de processus : trois niveaux52
  - 3.1 La représentation minimaliste52
  - 3.2 La représentation développée54
  - 3.3 La représentation détaillée56
  - 4. L'identification des processus d'une entreprise58
  - 4.1 Le bien ou le service fourni58
  - 4.2 Les événements déclencheurs59
  - 4.3 Le nommage des processus59
  - 4.4 Les trois catégories de processus60
  - 4.5 Les notions de partie prenante et d'acteur61
  - 5. Quelques processus de LOCA'ROYANS62
  - 5.1 Le processus louer Véhicule63
  - 5.1.1 La description littérale63
  - 5.1.2 L'analyse63
  - 5.1.3 La représentation minimaliste64
  - 5.1.4 La représentation développée65
  - 5.1.5 La représentation détaillée66
  - 5.1.6 Les éléments majeurs du modèle66
  - 5.2 Le processus restituer Véhicule70
  - 5.2.1 La description littérale70
  - 5.2.2 L'analyse71
  - 5.2.3 La modélisation UML : le diagramme d'activité (représentation détaillée)71
  - 5.2.4 Les éléments du modèle72
  - 5.2.5 Le flux de contrôle et les flux d'objets72
  - 5.2.6 Les processus sont paramétrables74
  - 6. Le cycle de vie des objets du métier75
  - 7. Le référentiel UML du projet75
  - 8. Pour aller plus loin78
  - 9. À retenir79
  - 10. Les prochaines étapes79
  - Chapitre 3
  - Description dynamique (l'information se transforme)
  - 1. L'état des lieux81
  - 2. La notion de machine à états83
  - 2.1 Définition84
  - 2.2 Le diagramme de la machine à états85
  - 2.2.1 Le diagramme minimaliste85
  - 2.2.2 Le diagramme développé86
  - 2.2.3 Le diagramme détaillé87
  - 2.2.4 Les autres renseignements portés par les transitions88
  - 2.2.5 La jonction entre les transitions : la complexité événementielle89
  - 3. Les propriétés de l'état90
  - 3.1 La transition et le comportement90
  - 3.1.1 L'autotransition90
  - 3.1.2 La transition interne92
  - 3.2 La hiérarchie entre états (automate hiérarchique)93
  - 3.3 Les actions et les activités94
  - 3.4 Les pseudo-états95
  - 3.4.1 Les pseudo-états attachés aux flux de contrôle95
  - 3.4.2 Les pseudo-états attachés aux états composites97
  - 3.4.3 Les états concurrents d'un système complexe98
  - 4. La description de la sémantique du système100
  - 4.1 Les diagrammes de protocole d'utilisation100
  - 4.2 Les diagrammes de protocole de calcul102
  - 5. Pour aller plus loin103
  - 5.1 Les comportements déterministes et non déterministes103
  - 5.2 À quels objets UML attacher une machine à états ?103
  - 5.3 La syntaxe des diagrammes d'activité et de cycle de vie104
  - 6. À retenir104
  - 7. Les prochaines étapes105
  - Chapitre 4
  - Description fonctionnelle du système
  - 1. L'état des lieux107
  - 2. La notion de cas d'utilisation109
  - 2.1 Définition109
  - 2.2 Exemples de cas d'utilisation110
  - 2.3 Le cas d'utilisation et processus112
  - 2.4 Le diagramme des cas d'utilisation114
  - 2.4.1 Le diagramme minimal114
  - 2.4.2 Le diagramme développé117
  - 2.4.3 Le diagramme détaillé119
  - 2.4.4 Les insuffisances du diagramme des cas d'utilisation121
  - 3. La description textuelle des cas d'utilisation122
  - 3.1 La description textuelle minimale123
  - 3.1.1 Le cas d'utilisation choisir Véhicule123
  - 3.1.2 Les règles du contenu124
  - 3.1.3 Les transactions métier125
  - 3.1.4 L'interface homme-machine (IHM)125
  - 3.2 La description textuelle développée126
  - 3.3 La description textuelle détaillée128
  - 3.3.1 Le cas d'utilisation choisir Véhicule128
  - 3.3.2 Les règles de gestion130
  - 3.3.3 Les exceptions et les extensions131
  - 4. Les concepts UML en jeu133
  - 4.1 Le cas d'utilisation133
  - 4.2 L'acteur134
  - 4.3 Les représentations135
  - 5. Pour aller plus loin136
  - 5.1 Le cas d'utilisation et le pilotage de projet136
  - 5.2 Le cas d'utilisation et l'architecture logicielle136
  - 5.3 Les cas d'utilisation et le modèle économique137
  - 5.3.1 Les quatre dimensions d'un modèle économique137
  - 5.3.2 Le système d'information et le modèle économique138
  - 6. À retenir139
  - 6.1 Le double avantage à tirer d'une formalisation des cas d'utilisation139
  - 6.2 Le double devenir des cas d'utilisation140
  - Chapitre 5
  - Description structurale du système
  - 1. L'état des lieux141
  - 2. Les notions de classe et de composant142
  - 2.1 Définitions142
  - 2.2 Exemples145
  - 2.3 Les diagrammes de classes147
  - 2.3.1 Le diagramme de classes minimaliste147
  - 2.3.2 Le diagramme de classes développé150
  - 2.3.3 Le diagramme de classes détaillé154
  - 2.4 La notion UML de composant157
  - 2.5 Les autres notions de la vue statique159
  - 2.5.1 L'héritage159
  - 2.5.2 Le diagramme d'instances (ou diagramme d'objets)164
  - 2.5.3 Les associations qualifiées166
  - 2.5.4 Les classes associations167
  - 2.6 Les ports et les interfaces170
  - 3. Les concepts UML en jeu173
  - 3.1 La classe173
  - 3.2 Le port et l'interface175
  - 3.3 L'association175
  - 3.4 Le composant177
  - 4. Pour aller plus loin182
  - 4.1 La classe paramétrée182
  - 4.2 L'association ternaire183
  - 4.3 Les stéréotypes et la valeur attachée186
  - 4.3.1 Le stéréotype186
  - 4.3.2 La valeur attachée188
  - 4.4 Le paquetage189
  - 5. Conclusion189
  - 5.1 Les solutions spécifiques : l'analyse préfigure la conception189
  - 5.2 Les solutions industrielles : adapter afin d'adopter190
  - 5.3 Et toujours : structurer pour simplifier191
  - Chapitre 6
  - Description collaborative du système
  - 1. L'état des lieux193
  - 2. La notion de comportement195
  - 2.1 Spécifier un comportement en UML196
  - 2.2 Synchroniser des comportements196
  - 2.3 Comportement... de qui ?197
  - 2.4 Déclencher des comportements : les signaux et les événements199
  - 2.5 Les interactions201
  - 2.5.1 Le diagramme de séquences202
  - 2.5.2 Le diagramme de communication210
  - 2.5.3 Le diagramme d'interaction211
  - 3. Les concepts UML en jeu212
  - 3.1 L'interaction, le fragment combiné, la ligne de vie, l'appel d'interaction (interaction use)212
  - 3.2 Le message, le signal, l'événement, le comportement215
  - 3.3 L'invariant d'état219
  - 4. Pour aller plus loin220
  - 5. Conclusion221
  - Chapitre 7
  - UML au service de l'architecture
  - 1. L'état des lieux223
  - 2. L'architecture en entreprise228
  - 2.1 Répondre à deux besoins : généricité et cohérence interne228
  - 2.2 L'architecture comme source de cohérence et support de la transformation232
  - 2.2.1 C'est une métaphore232
  - 2.2.2 La définition normée de l'architecture d'entreprise232
  - 2.2.3 Les autres définitions : l'architecture selon TOGAF et Praxeme233
  - 3. L'architecture en entreprise selon TOGAF et Praxeme236
  - 3.1 Le framework TOGAF version 9.1236
  - 3.1.1 La mise en oeuvre de TOGAF236
  - 3.1.2 Les outils proposés par TOGAF238
  - 3.2 La méthodologie Praxeme241
  - 3.2.1 Les produits242
  - 3.2.2 Les procédés et processus246
  - 3.3 TOGAF et Praxeme : des réponses pertinentes aux exigences de cohérence et de généricité ?247
  - 3.4 Un retour sur la généricité251
  - 3.4.1 La généricité selon TOGAF251
  - 3.4.2 La généricité selon Praxeme251
  - 4. Les apports d'UML à l'architecture253
  - 4.1 Les diagrammes UML natifs au service de l'architecture254
  - 4.1.1 TOGAF et UML254
  - 4.1.2 Praxeme et UML259
  - 4.2 Les diagrammes d'architecture natifs proposés par UML262
  - 4.2.1 Le diagramme de composants262
  - 4.2.2 Le diagramme de structure composite262
  - 4.2.3 Le diagramme de déploiement263
  - 4.3 Spécialiser UML : les profils264
  - 5. Pour aller plus loin266
  - 6. Conclusion267
  - Chapitre 8
  - Rédiger le cahier des charges fonctionnel d'un projet
  - 1. L'état des lieux269
  - 2. La notion de cahier des charges fonctionnel (CdCF) ?271
  - 2.1 Définition271
  - 2.2 Déterminer les fonctions de service a minima272
  - 2.3 Les autres manières de déterminer les fonctions de service272
  - 2.4 Naissance du CdCF en France274
  - 2.5 Qu'est-ce qu'un besoin ?275
  - 2.5.1 Les besoins implicites et explicites276
  - 2.5.2 La mise en cohérence des besoins277
  - 3. Le plan-type proposé par la norme ISO278
  - 3.1 Les chapitres du CdCF278
  - 3.2 Les modèles UML pouvant alimenter ce CdCF279
  - 4. Le cahier des charges dans le cycle en V et les cycles agiles280
  - 4.1 Le cycle en V : exposer le problème, puis le résoudre280
  - 4.1.1 Le cahier des charges, un référentiel accompagnant le produit toute sa vie280
  - 4.1.2 Le cahier des charges, un référentiel à deux étages281
  - 4.2 Les cycles agiles : poser le problème tout en le résolvant284
  - 4.2.1 Rejeter le CdCF : un choix managérial qui ne s'impose pas284
  - 4.2.2 L'agilité appelle à la généricité du CdCF, non à son abolition285
  - 5. Livré mais toujours sous responsabilité287
  - 6. Pour aller plus loin289
  - Chapitre 9
  - Les impacts d'UML sur la recette d'un livrable
  - 1. L'état des lieux291
  - 2. Les types fondamentaux de recettes293
  - 3. La recette technique d'un produit spécifié en UML295
  - 3.1 Les tests de cas d'utilisation295
  - 3.1.1 Le scénario de tests296
  - 3.1.2 La fiche de tests299
  - 3.1.3 Le résultat des tests301
  - 3.1.4 La décision d'acceptation ou de refus du cas d'utilisation303
  - 3.1.5 L'environnement des tests unitaires304
  - 3.2 Les tests d'assemblage306
  - 3.2.1 Ce qui doit être testé en assemblage306
  - 3.2.2 Ce qu'il est inutile de tester en assemblage309
  - 3.3 Les autres tests pouvant être facilités par UML309
  - 3.4 Les apports d'UML à la recette technique309
  - 4. La priorisation des tests par les risques310
  - 4.1 L'évaluation du risque311
  - 4.2 L'analyse de risques de deux cas d'utilisation de LOCA'ROYANS312
  - 4.2.1 L'identification du risque312
  - 4.2.2 L'évaluation du risque312
  - 4.2.3 La priorisation : la comparaison des risques312
  - 4.3 La répartition des ressources en fonction des risques313
  - 5. Pour aller plus loin314
  - Chapitre 10
  - Évaluation des charges d'un projet spécifié en UML
  - 1. L'état des lieux315
  - 2. Comment évaluer les charges316
  - 3. Exemple de méthode de répartition proportionnelle316
  - 4. Le modèle COCOMO317
  - 5. La méthode d'évaluation analytique319
  - 6. La méthode des points de fonction320
  - 7. L'évaluation de la charge d'un projet UML : la méthode Karner320
  - 7.1 La détermination du poids non ajusté des acteurs321
  - 7.2 La détermination du poids non ajusté des cas d'utilisation321
  - 7.3 Le calcul du nombre de points brut du CU322
  - 7.4 Le calcul du nombre de points ajusté du CU322
  - 7.4.1 La complexité technique322
  - 7.4.2 L'environnement324
  - 7.4.3 Le nombre de points ajusté de deux CU de LOCA'ROYANS325
  - 7.5 L'évaluation et la ventilation de la charge326
  - 8. Pour aller plus loin327
  - 9. Conclusion328
  - Index331
Origine de la notice:
- FR-751131015