20 Modélisation des processus de l`entreprise

Transcription

Modélisation
de logiciels de gestion
20. Modélisation des processus de l’entreprise
1 Préambule
L’identification des événements que nous avons traitée au chapitre « 310 Les événements »
du cours de méthodologie [1] permet de recenser les événements métier ou système auxquels
le futur SII devra être capable de donner une réponse.
Cette réponse aux événements est réalisée par le SII sous forme de traitements informatisés.
Préalablement à la spécification des traitements informatisés, nous devons nous assurer
d’avoir parfaitement compris le déroulement des processus métier qui devront être supportés,
totalement ou partiellement, par les traitements informatiques.
En finalité, la modélisation des processus de l’entreprise vise deux objectifs :
• Comprendre le fonctionnement de l’entreprise;
cette compréhension passe par une description
sous forme de modèle des actions menées au sein
de l’entreprise suite à un stimuli (événement) ; ce
stimuli peut être externe, interne ou temporel.
• Disposer d’une expression relativement claire des
besoins métier de l’entreprise pour établir les
spécifications des traitements et données du futur
système d’information informatisé (SII).
Figure 1 - Informatique de gestion
Remarque: L’objectif de ce chapitre est de présenter sommairement les différents modèles de
processus métier; d’autres cours ou chapitres présenteront les différents modèles en détail.
Cours de modélisation 2005/2006
http://lgl.isnetne.ch/modelisation-2005
20. Modélisation des processus
30.09.2006/ P-A. Sunier
1/11
http://lgl.isnetne.ch
2 Le concept de processus
[CM-05] Un processus est un système dynamique orienté vers la réalisation
d’un objectif.
Un processus est un système au sens où nous l’avons défini au chapitre « 60 Concepts de
l’approche classique de développement de SII » du cours de méthodologie [1].
Un processus étant un système, nous allons essayer de l’appréhender
en nous intéressant à l’ensemble des éléments (activités, rôles,
acteurs, ressources, entrées, résultats…) qui le compose et des
relations existantes entre ces éléments.
Figure 2 - Processus "Poser une fenêtre"
Naturellement, la seule étude des parties d’un système, ne suffit pas à en appréhender sa
complexité :
• dynamique - nous devrons tenir compte de son ouverture sur l’environnement qui le
pousse à évoluer dans le temps.
• orienté – son évolution ne se déroule pas au hasard, le système reste sous-tendu à
l’atteinte de sa finalité.
Par exemple, il y a quelques années un processus de paiement s’appuyait sur une
transaction postale, au fil du temps il a évolué pour prendre en compte des
changements environnementaux comme l’apparition des virements bancaires ou plus
récemment des paiements par Internet ; mais, malgré de probables changements
internes, ce processus de paiement, conserve sa finalité qui consiste à traiter une
transaction financière.
• réalisation d’un objectif – comme nous l’avons expliqué plus haut, la réalisation de
l’objectif exprime le fait que le processus, en tant que système ouvert, évoluera tout en
tendant à atteindre la finalité de sa conception.
Dans la vision systémique de la définition de processus que nous venons de donner, les
éléments d’un processus peuvent être eux-mêmes des processus en interaction les uns les
autres.
Nous pouvons considérer l’entreprise dans son ensemble comme un processus de premier
niveau ; les départements constitutifs de l’entreprise comme des processus de deuxième
niveau ; les services des différents départements comme des processus de troisième niveau…
30.09.2006/ P-A. Sunier
2/11
Les interactions entre éléments d’un système deviennent des flux de données ou de matières 1
entre les sous processus d’un processus de niveau supérieur.
Certains auteurs préconisent de décrire un processus non pas en terme de sous processus mais
en termes d’activités, elles-mêmes décomposées en tâches.
Notre modeste expérience, nous amène à proposer d’utiliser les deux démarches
conjointement:
• Les processus de haut niveau sont décomposés en sous processus de niveau inférieur ;
la profondeur variera en fonction de l’ampleur du système entreprise pris en compte.
Si l’analyse porte sur l’entier d’une entreprise, nous aurons une multitude de niveaux;
si l’analyse porte sur un simple service comme une gestion de notes de frais, un ou
deux niveaux peuvent suffire.
• Les processus de dernier niveau ; les feuilles de l’arbre des processus seront décrites
en terme d’activités ; elles-mêmes décomposées en tâches.
3 Diagrammes de flux de travaux
Dans l’optique du premier objectif de la modélisation des processus métier, à savoir la
compréhension du fonctionnement de l’entreprise, nous proposons de réaliser des diagrammes
dits de flux de travaux.
Les diagrammes de flux de travaux peuvent être réalisés selon de multiples formalismes.
Nous avons choisi le formalisme des flux fonctionnels croisés 2 qui nous semble approprié à
favoriser le dialogue entre les experts métiers les plus pointus et les personnes ignorantes du
métier.
1
Au niveau du métier de l’entreprise nous avons des flux physiques ; par contre au niveau du SI nous n’aurons
plus que des flux de données.
2
Certains auteurs parlent aussi de diagramme « Qui, Quand, Quoi ». Le qui représente les travées de
responsabilités, le quand représente la chronologie temporelle et le quoi représente les activités successives.
30.09.2006/ P-A. Sunier
3/11
Figure 3 - Flux de travaux du processus "Inscription d'un enfant" de notre crèche
Les flux fonctionnels croisés sont réalisés sous forme d’une suite d’activités recevant des
données 3 en entrée et fournissant des données en sortie.
Les données sont représentées sous forme d’entrepôts de données contenant des données dans
un état précis.
A l’exception des entrepôts de données qui peuvent faire office de déclencheur ou de réponse
du processus modélisé, tout entrepôt de données est doté d’une activité en amont qui
l’alimente et d’une activité en aval qui le consomme.
Des travées sont disposées dans le diagramme pour représenter les responsabilités des
diverses activités. Les activités sont ordonnées pour représenter le déroulement
chronologique.
3
En principe, tous les auteurs parlent de données car ils s’intéressent au traitement de l’information nécessaire
au métier ; mais, plus justement, il serait tout à fait possible d’avoir des entrées/sorties physiques ou de matières
pour représenter les processus du système opérant. En reprenant notre exemple de boulangerie, l’activité de
pétrissage recevrait en entrée de la farine, du levain… et fournirait en sortie de la pâte.
30.09.2006/ P-A. Sunier
4/11
4 Modéliser les processus métier
La modélisation des processus métier varie selon que l’on choisisse une approche classique ou
une approche orientée objet.
Pour illustrer ce chapitre, nous avons reproduit les diagrammes que nous avions réalisés dans
le cadre du projet de recherche [ISNet-43] ; ce projet visait à comparer les deux approches :
fonctionnelle ou classique d’une part et orientée objet d’autre part.
Lors de ce projet, nous avons réalisé la modélisation métier d’un cas pratique avec les deux
approches. Ainsi, nous pouvons aisément comparer les apports de chacune des deux
approches.
Le cas pratique du projet concernait la gestion des bugs des produits livrés par un fabricant de
cartes de téléphonie. Ces cartes permettaient de transformer un PC en centrale téléphonique.
4.1 Approche classique
4.1.1 Modèle de processus
En approche classique, de nombreux courants de pensée ont proposés leurs propres
formalismes de représentation. Mais la plupart des formalismes se ressemblent; ils présentent
tous, d’une manière ou d’une autre, des séquences d’activités ordonnées dans le temps. Les
activités sont reliées entre elles par des flux de données ou de matière; les données ou les
matières peuvent être stockées si nécessaire dans des entrepôts.
Les diagrammes de flux de travaux que nous avons présentés précédemment sont d’excellents
candidats pour servir de base à la modélisation des processus métier d’entreprise.
Le diagramme de la Figure 4 correspond au modèle de processus de notre cas pratique; il a été
réalisé avec l’atelier de génie logiciel Designer d’Oracle.
Remarque: L’outil de modélisation de processus métier de Designer permet de représenter les
événements de déclenchement et de finalisation du processus représenté.
30.09.2006/ P-A. Sunier
5/11
Figure 4 - Diagramme de processus de la gestion des bugs
4.1.2 Transition entre les représentations métier et système
d’information
Contrairement à l’approche objet qui peut
s’appuyer sur l’unification du processus de
développement avec UP et l’unification de
modélisation avec UML, l’approche
classique ne propose pas de concepts
formalisés pour passer de la représentation
métier à la représentation du système
d’information. Chaque méthode ou
constructeur d’atelier de génie logiciel
(AGL) propose sa solution.
L’AGL Designer d’Oracle « transforme »
automatiquement les processus métier qui
manipulent de l’information en fonctions
informatiques du système d’information ; les entrepôts de données, à l’exclusion des entrepôts
de matière, sont également « transformés » en entrepôts de données du système d’information.
Figure 5 - Entreprise système
30.09.2006/ P-A. Sunier
6/11
4.2 Approche orientée objet
En approche orientée objet, notamment avec le processus unifié UP, plusieurs modèles
supportés par le langage UML sont utilisés pour modéliser les divers aspects des processus
métier d’entreprise.
La présentation ci-dessous n’est pas exhaustive ; de cas en cas, l’informaticien de gestion
utilise les modèles UML les plus appropriés à la situation qui l’occupe.
[Voir le chapitre « 70 Concepts de l’approche orientée objet de développement de SII » du
cours de méthodologie [1]]
4.2.1 Modèle de cas d’utilisation métier
Le modèle des cas d’utilisation métier s’applique à l’entreprise dans son ensemble.
Les acteurs métiers sont dans l’environnement externe de l’entreprise, ce sont les clients, les
fournisseurs, les gouvernements, les banques, d’autres entreprises ou systèmes informatiques.
Les cas d’utilisation métier sont des services fournis par l’entreprise et attendus par les acteurs
externes.
Le modèle des cas d’utilisation métier permet d’exprimer les besoins en processus métier
mais, il n’exprime en aucun cas la dynamique qu’il peut y avoir entre et à l’intérieur des
différents cas d’utilisation.
Figure 6 - Diagramme des cas d'utilisation métier de la gestion des bugs
Remarque: L’acteur externe du diagramme de la Figure 6 est nommé Appelant ; dans les
diagrammes suivants, il est nommé Client. Appelant et Client sont des synonymes.
30.09.2006/ P-A. Sunier
7/11
4.2.2 Modèle d’activités
Le modèle d’activités est un modèle de la famille des flux de travaux.
Il peut s’utiliser en amont de la démarche pour comprendre le fonctionnement de l’entreprise.
En plus de cette utilisation en amont, nous conseillons vivement d’utiliser le modèle
d’activités et les diagrammes d’activités pour montrer la dynamique interne des cas
d’utilisation.
Figure 7 - Diagramme d'activités de la gestion des bugs
30.09.2006/ P-A. Sunier
8/11
4.2.3 Modèle de séquences
Le modèle de séquence est un cas particulier du modèle des interactions.
Il peut s’utiliser en amont de la démarche pour représenter des cas particuliers de déroulement
de processus sous forme de diagrammes unitaires. Ensuite, à partir de plusieurs diagrammes
ou scénarios il est possible de faire ressortir les règles de généralisation qui permettront de
spécifier les cas d’utilisation ou de réaliser des diagrammes d’activités.
En plus de cette utilisation en amont, le diagramme de séquence peut être utilisé pour définir
les scénarios essentiels que les cas d’utilisation réalisés devront supporter ; ces scénarios
essentiels seront la base des jeux de tests d’intégration.
Figure 8 - Diagramme d'un scénario d'annonce de problème
4.2.4 Modèle de machines états transitions
Le modèle de machines états transitions permet de définir très précisément le comportement
d’une unité de traitement ; cette unité de traitement peut être un processus métier.
Nous reviendrons plus en détail sur le modèle de machines états transitions dans un chapitre
spécifique.
30.09.2006/ P-A. Sunier
9/11
4.2.5 Transition entre les représentations métier et système
Le modèle d’objets métier d’UP permet de modéliser la transition entre la représentation
métier et la représentation du système d’information.
Les travailleurs d’interface 4 assurent la transition entre les acteurs métiers et le système
d’information ; les travailleurs d’interface seront « transformés » en acteur du système
d’information et leurs besoins en traitement informatisés seront exprimés sous forme de cas
d’utilisation système.
Figure 9 - Modèle des objets métier de la gestion des bugs
Le modèle des objets métier est un cas particulier de modèle de collaboration 5 d’UML.
4
SAV, Marketing, Test et R&D pour notre gestion de bugs de la Figure 9.
Tout comme le modèle de séquence, le modèle de collaboration est un cas particulier de modèle d’interaction ;
la plupart des AGL permettent de passer de l’un à l’autre automatiquement.
5
30.09.2006/ P-A. Sunier
10/11
5 Références bibliographiques
[1]
Cours de méthodologie HES - 2005
http://lgl.isnetne.ch/methodologie-2005HES/index.htm
[CM-05]
Processus métiers et SI de C. Morley, J. Hugues, B. Leblanc, o.Hugues
2005 c/o Dunod
[ISNet-43]
Atelier de génie logiciel - Approche fonctionnelle ou objet
Concurrence ou complémentarité ?
P.-A. Sunier et consorts, 2001/2003
http://lgl.isnetne.ch/isnet43
30.09.2006/ P-A. Sunier
11/11

20 Modélisation des processus de l`entreprise

Transcription

Documents pareils

70 Concepts de l`approche orientée objet de développement de SII

APIS DE TABLE POUR SQL SERVER

Exemples de diagrammes SysML sur un portail automatique

Fiche Produit CANON i-SENSYS MF 4410 Type Imprimante Laser

lauréats 2015 - Institut Français du Luxembourg

Modélisation de logiciels de gestion 120. Modélisation des données

Formation UML complète Plan de cours