SlideShare une entreprise Scribd logo
1  sur  116
Bienvenue à la formation
Analyse de Processus et Workflow
1
Philippe DORNBUSCH
Responsable du service Projets RH & Management
Direction des Ressources Humaines du CA IDF
Le tour de table des participants à cette formation
2
3
Tu me dis, j’oublie
Tu m’enseignes, je me souviens
Tu m’impliques, j’apprends
Benjamin Franklin, (1706-1790), écrivain, inventeur et homme politique américain
L’importance de la mise en pratique pendant cette formation
Programme de la formation
Introduction et Définition des processus
Atelier fil rouge : mise en pratique avec des études de cas concrets
Méthode d’Analyse des processus
Merise et son Modèle Conceptuel de Communication (MCC)
4
Le Workflow (automatisation des tâches du processus)
L’analyse logicielle avec UML (Unified Modeling Langage)
Devoir individuel puis corrigé du devoir
Organisation pratique de la journée 1
9h-9h30 Accueil des participants et tour de table
9h30 - 10h30 Définition et méthode d’analyse des processus
10h30 - 11h Pause
5
13h30 - 15h Définition d’un Workflow
11h – 12h30 Exercice d’analyse de processus : le télétravail
12h30 - 13h30 Pause déjeuner
15h - 15h30 Pause
15h30 - 17h Merise et le Modèle Conceptuel de Communication
Organisation pratique de la journée 2
9h00 - 10h30 Réalisation d’un MCC
10h30 - 11h Pause
6
13h30 - 15h Cas d’utilisation et diagramme de séquence
11h -12h30 L’analyse logicielle avec UML
12h30 - 13h30 Pause déjeuner
15h - 15h30 Pause
15h30 - 16h30 Le Quiz individuel
16h30 – 17h00 Correction du Quiz et Conclusion de la formation
7
Introduction à la notion de processus
Définition d’un Processus
• Un processus est un ensemble d'activités corrélées ou en interaction qui utilise
des éléments d'entrée pour produire un résultat escompté. Ces éléments sont
soit des objets matériels (pouvant être perçus comme des flux par
la logistique à des fins d'évaluation) soit des informations, soit les deux.
8
Définition d’un Processus
• Il ne faut pas confondre « processus » avec
« procédure ».
• Le premier décrit les activités de l'entreprise
selon une vision transversale par rapport à
l'organisation de celle-ci, tandis que le second
explicite le "comment faire" dans cette
organisation.
• L'approche processus permet d'identifier et de
maîtriser les interfaces entre les différentes
activités.
9
Définition d’un Processus
• Le processus répond aux questions : QUOI
FAIRE ? POUR QUELLE VALEUR AJOUTÉE ?
• La procédure répond aux questions : COMMENT
FAIRE ? QUAND ? QUI ?
• Le mode opératoire répond de plus aux
questions : OÙ ? SELON QUEL PROCÉDÉ ?
• Le mode pilotage répond de plus à la question :
COMBIEN ?
10
Méthode d’analyse des processus
11
L'analyse des processus – les étapes
• Lorsqu'on veut optimiser ou transformer radicalement un
processus, on a besoin d'une méthode rigoureuse.
• L'analyse des processus est l'outil le mieux adapté à ces
deux tâches. En mode « transformation radicale », elle
aide à changer non seulement les façons de faire, mais
également les façons de voir, soit les paradigmes des
personnes concernées.
• En outre, cette méthode favorise la participation en
mettant à contribution des salariés de divers secteurs qui
travaillent en contact constant avec les acteurs du
processus (dans une démarche de type « expert », les
participants sont en vase clos sans interaction avec
l'environnement).
12
L'analyse des processus – les étapes
La méthode implique deux questions fondamentales, celle
de la pertinence et celle de l'efficacité des activités et des
étapes du processus. En d'autres mots:
• Faisons-nous les bonnes choses pour nos clients ?
• Les faisons-nous de la meilleure façon ?
13
Les résultats escomptés
• Processus redessinés, prêts à être implantés et qui
livrent un résultat conforme aux spécifications du
client.
• Processus qui améliorent la performance
organisationnelle sur 4 axes à la fois: client,
ressources humaines, ressources financières et
opérations.
• Recommandations concernant le nouveau processus
et description des impacts sur l'encadrement, les
gains et investissements financiers, la technologie,
les ressources humaines, etc.
14
Les conditions de succès
• S'assurer que les processus analysés sont
prioritaires ou liés aux orientations stratégiques.
• Dès le début de la démarche, s'associer en mode
concerté avec les instances syndicales.
• Faire preuve de transparence à toutes les étapes.
• Concevoir et appliquer une stratégie de
communication pour informer toute
l'organisation.
15
Les conditions de succès
• Être prêt à investir du temps, de l'énergie et des
ressources.
• Respecter les membres de l'équipe (liberté de
s'associer ou non aux recommandations).
• Confier à une ressource externe le soin
d'accompagner l'équipe (rigueur
méthodologique, apprentissage des outils et du
processus de changement organisationnel).
16
17
Analyse d’un processus
Le Télétravail en entreprise
Le parcours du Télétravail
La demande du collaborateur
Le collaborateur enregistre sa
demande de télétravail à partir de
l’outil dédié (Téléflow)
1
Collaborateur du siège
3
La signature de l’avenant au contrat de
travail
Après accord du manager, le
collaborateur fournit les pièces
demandées par la DRH puis signe
son avenant
La décision du manager
Le manager organise une réunion
d’analyse de la demande avec le
collaborateur et décide (accord /
refus)
2 4
3
5
La récupération du matériel
Le collaborateur récupère le matériel
requis auprès de DOMS/IT
Le démarrage du télétravail
Le collaborateur installe le matériel
à son domicile et télétravaille le
moment venu
Le parcours du Télétravail
La demande du collaborateur1
Avant de faire sa demande, le collaborateur peut autoévaluer
ses aptitudes et ses motivations au télétravail à l’aide de la grille
disponible sur chorale NET
 Le collaborateur crée une demande à partir de Téléflow
La décision du manager2
 Le manager est prévenu par mail de la demande de
télétravail de son collaborateur
 Le manager organise un entretien (dans un délai de 30 jours
à compter de la réception du mail) avec son collaborateur pour
en apprécier l’éligibilité au télétravail. Il utilise la Grille d’éligibilité
au télétravail disponible sur chorale NET
 Le manager acte sa décision, en la motivant, sur Téléflow
(dans un délai de 60 jours à compter de l’entretien)
La signature de l’avenant au contrat de travail3
 Le collaborateur est prévenu par mail de la décision de son
manager
 En cas d’accord du manager, le collaborateur dépose dans
Téléflow une attestation sur l’honneur de la conformité de
l’installation électrique de son domicile et une attestation de
couverture Multi risques habitation intégrant la pratique du
télétravail. Des modèles et exemples sont disponibles sur
chorale NET
 La DRH contrôle la conformité des documents puis fait
parvenir au manager l’avenant en double exemplaire qui les
remet à son collaborateur
La récupération du matériel4
 DOMS annonce par mail au collaborateur que le matériel
requis est disponible
 Le collaborateur vient récupérer son matériel en suivant les
instructions de DOMS et signe une prise en charge.
Le démarrage du télétravail5
 Le collaborateur installe le matériel à son domicile en suivant
les indications du Guide Technique du Télétravail mis à disposition
sur chorale NET
 Le collaborateur peut commencer le télétravail à la date
convenue dans l’avenant
 Le collaborateur signe l’avenant. Il envoie à la DRH l’avenant
papier signé (nécessité juridique) et en dépose une copie dans
Téléflow. Il conserve le deuxième exemplaire
Pour le télétravailleur
• Préparer votre journée de télétravail en vous assurant d’avoir
tous les éléments nécessaires.
• Fixez-vous des objectifs et des livrables à réaliser au cours de
la journée.
• Fixez, avec votre manager, des plages de joignabilité.
• Les documents confidentiels doivent rester sur le lieu de
travail et ne doivent pas être emmenés au domicile
• Même si vous êtes en télétravail, vous avez l’obligation de
vous rendre au rendez-vous, réunions et formations durant
lesquels votre présence est impérative en décalant si besoin
votre journée de télétravail dans la même semaine, avec
accord de votre hiérarchie.
• Informez vos collègues que vous êtes en télétravail. Rappelez
que vous êtes joignable comme sur votre lieu de travail
habituel.
• Délimitez votre espace de travail à domicile
• Adoptez une bonne posture de travail
Pour le manager et l’équipe
• Favorisez les réunions d’équipe les jours où le télétravailleur
est présent.
• Quand la réunion a lieu un jour où il n’est pas présent,
n’oubliez pas de l’intégrer à distance.
• N’omettez pas le télétravailleur dans l’envoi de vos mails.
• Ayez le réflexe de solliciter le télétravailleur comme vous le
feriez quand il est présent au bureau et non un collègue parce
que lui est physiquement là.
• Même en dehors des locaux, le télétravailleur est joignable
aux heures habituelles et pas seulement en cas d’urgence.
Organiser le télétravail
Calendrier de déploiement par vagues successives de 50
collaborateurs
vague 1 : ouverture du Workflow des demandes aux collaborateurs le 18 avril –
validation Managers jusqu’au 5 Mai - Équipement de 50 collaborateurs au 1er juin
2017
vague 2 : validation Managers jusqu’au 19 Mai - Équipement de nouveaux
collaborateurs au 1er juillet 2017
vague 3 : validation Managers jusqu’au 18 Août - Équipement de nouveaux
collaborateurs au 1er octobre 2017
puis nouvelles vagues trimestrielles à compter de 2018 (janvier et juillet)
Les 4 étapes dans l’analyse des processus
22
Les 4 étapes de l'analyse des processus
• Élaborer le mandat de l'équipe
• Analyser le processus actuel
• Baliser
• Élaborer la nouvelle architecture du processus
23
Les 4 étapes de l'analyse des processus
1 - Élaborer le mandat de l'équipe
Après avoir reçu de la direction les grandes lignes de la
situation problématique, l'équipe de travail :
• identifie les frontières du ou des processus à analyser
• recueille les attentes des clients face aux résultats qui leur sont
livrés
• recueille les attentes des propriétaires du processus
concernant la performance
• élabore son mandat en précisant les résultats spécifiques du ou
des nouveaux processus ainsi que les valeurs sur lesquelles elle
s'appuiera tout au long du travail à accomplir.
• Le mandat est présenté pour approbation au comité de
direction et au gestionnaire concerné (généralement, les
membres de l'équipe font la présentation).
24
Les 4 étapes de l'analyse des processus
25
2 - Analyser le processus actuel
• L'équipe recueille sur le terrain les informations nécessaires
pour faire la cartographie du flux des processus étudiés
(ordinogramme).
• La cartographie est constamment validée par les gens du
terrain afin de s'assurer qu'on décrit la situation actuelle et
non ce qu'on souhaiterait avoir plus tard.
• Ce travail permet par la suite de faire l'analyse de la valeur
de chacune des étapes et d'établir par la même occasion une
série de constats objectifs sur l'efficacité du processus
analysé.
• On effectuera souvent en parallèle à la cartographie une
analyse financière sommaire basée sur les coûts d'obtention
de la qualité des résultats produits par les processus actuels.
Les 4 étapes de l'analyse des processus
26
2 - Analyser le
processus actuel
Les 4 étapes de l'analyse des processus
27
2 - Analyser le
processus actuel
La demande du collaborateur
Le collaborateur enregistre sa
demande de télétravail à partir de
l’outil dédié (Téléflow)
1
Collaborateur du siège
3
La signature de l’avenant au contrat de
travail
Après accord du manager, le
collaborateur fournit les pièces
demandées par la DRH puis signe
son avenant
La décision du manager
Le manager organise une réunion
d’analyse de la demande avec le
collaborateur et décide (accord /
refus)
2 4
3
5
La récupération du matériel
Le collaborateur récupère le matériel
requis auprès de DOMS/IT
Le démarrage du télétravail
Le collaborateur installe le matériel
à son domicile et télétravaille le
moment venu
Les 4 étapes de l'analyse des processus
28
3 – Baliser (ou benchmarker)
• Les constats résultant de l'analyse permettent
d'identifier des cibles de balisage. La direction est mise
à contribution pour aider l'équipe à établir des contacts
avec diverses entreprises.
• Par la suite l'équipe planifie et organise son balisage en
préparant une série de questions qui portent soit sur
les façons de faire ou les façons de voir (concepts) des
thèmes ciblés.
• À son retour, l'équipe fait le bilan de ses découvertes et
identifie les premières possibilités d'adaptation.
Les 4 étapes de l'analyse des processus
29
4 - Élaborer la nouvelle architecture du processus
• L'équipe précise le nouveau concept qui appuiera la nouvelle
architecture du processus.
• Ensuite, elle effectue une nouvelle cartographie en mettant
l'accent sur la pertinence de chacune des activités ou étapes
ainsi que sur la meilleure façon de l'exécuter.
À titre indicatif, le nouveau processus devrait viser les
barèmes suivants :
• au moins 65 % d'activités à valeur ajoutée,
• de 10 à 15 % d'activités de contrôle et de vérification,
• de 10 à 15 % d'activités de décision
• un maximum de 10 % de délai et de transport,
• et aucune activité inutile.
Les 4 étapes de l'analyse des processus
30
4 - Élaborer la nouvelle architecture du processus
• Une fois la cartographie terminée, l'équipe identifie les
impacts qu'aura la nouvelle architecture, particulièrement sur
l'encadrement, les ressources humaines et la technologie.
Elle précise également les gains et investissements requis.
• De nombreuses consultations sont effectuées auprès des
services de soutien pour valider ou raffiner certains éléments.
• Puis l'équipe élabore une série de recommandations pour
l'implantation éventuelle des nouveaux processus.
• Enfin, elle présente le fruit de son travail à l'équipe de
direction.
• La direction aura à décider quelles recommandations seront
retenues et implantées.
Un exemple d’analyse de processus (Mouvement québécois de la Qualité)
31
Un exemple d’analyse de processus
32
1 - Le mandat
Une organisation dans le domaine des
télécommunications au Québec veut revoir les
façons de faire de ses équipes techniques. Après
avoir compris le problème et les attentes de la
direction, l'équipe propose que le nouveau
processus permette entre autres de :
 résoudre 100 % des problèmes ne nécessitant pas
un déplacement lors de la prise d'appel
 éliminer 80 % du papier
 réduire les charges d'exploitation de 25 %
Un exemple d’analyse de processus
33
2 - L'analyse des processus actuel
Il s'est dégagé plusieurs constats de l'analyse
des processus :
 pas de calendrier de rendez-vous
 surutilisation et surmanipulation de papier
 qualité livrée non conforme aux attentes
 pas de communication entre les secteurs.
Un exemple d’analyse de processus
34
3 - Le balisage ou benchmarking
Le balisage a pour but d'apprendre des autres.
Les membres de l'équipe visitent 19 entreprises
au Québec, au Canada et aux États-Unis. Leurs
constatations :
 utilisation de nouvelles technologies (terminaux
à bord des véhicules)
 organisation du travail basée sur le concept des
équipes semi-autonomes
 nouveau rôle du répartiteur.
Un exemple d’analyse de processus
35
4 - Le redesign
À partir d'un nouveau concept, l'équipe
propose 12 transformations majeures sur trois
axes :
 le client
 les employés
 les opérations
Gains prévus : 4.000.000 $ sur trois ans
Définition d’un Workflow
Conduite de projet 36
Définition d’un Workflow
• Le WORKFLOW décrit
 Les tâches à accomplir
 Les acteur d’un processus
 Le circuit et modes de validation
 Les délais
• Le Workflow fournit à chacun des acteurs les
informations nécessaires pour la réalisation de sa
tâche !
37
A quoi ça sert ?
• Exemples de Workflow
 un système de rédaction coopérative pour mettre
sous Intranet la documentation professionnelle de
l'entreprise
• Les contributions, validations, approbations etc. parcourent
un workflow qui automatise l'adressage et permet le
contrôle des délais
 un workflow pour la signature des conventions de
partenariat
• actuellement, ces conventions suivent des parcours
compliqués et les délais de signature sont aléatoires
38
A quoi ça sert ?
• Exemples de Workflow
 pour la préparation du budget informatique d'une
grande entreprise,
 un workflow permet de rassembler les descriptions de
projets, synthétiser les demandes, préparer les arbitrages.
Il implique les directions, le contrôle de gestion et la
mission système d'information
 Pour la gestion d’un service d'assistance téléphonique
à la force de vente
39
Les outils de modélisation
• Le moteur de Workflow
 Dispositif logiciel permettant d’exécuter une ou
plusieurs définitions de Workflow
 Par abus de langage on peut appeler ce dispositif
logiciel « WORKFLOW »
40
Les outils de modélisation : MERISE et UML
Conduite de projet 41
Les méthodes et diagrammes associés
• Merise
 Sépare les traitements des données
 MCC (Modèle Conceptuel de Communication)
• Méthodes associées à UML
 Unified Modeling Langage
 langage graphique basé sur des concepts OBJETS 
Diagramme de Cas d’Utilisation
42
MERISE - MEthode pour Rassembler les Idées Sans Effort
Conduite de projet 43
La méthode MERISE (Principes)
• Création : en 1978-79 par Peter Chen et Hubert
Tardieu à Aix en Provence
• Signifie : MEthode pour Rassembler les Idées
Sans Effort ou encore vient du merisier qui est un
porte-greffe !
• But : Conception de Système d'Information (SI)
par la modélisation Pour projets de toutes tailles
44
La méthode MERISE (Principes)
La méthode MERISE s'appuie sur 3 points :
• Le cycle de vie (très variable selon les projets)
 Gestation et Conception
 Réalisation et Exploitation
 Maintenance (évolution, adaptation, mort)
• Le cycle de spécification (ou d'abstraction) du
système d'information (SI)
 Domaine des données : la mémorisation de l'information
 Domaine des traitements : les processus de traitement de
l'information
• Le cycle de décision
45
46
Exemple d’un MCC
Réalisation d’un Modèle Conceptuel
de Communication (MCC)
Exemple de MCC
Une entreprise commerciale est constituée de trois services
principaux : ventes, comptabilité et magasin.
Pour chaque commande passée, le bon est transmis du service
vente au service comptabilité qui envoie la facture au client (qui
lui, renverra le règlement).
Le service ventes enverra un bon de sortie au magasin pour le
déstockage. Ce dernier envoie le bon de livraison et
la commande au client.
En ce qui concerne les stocks, c'est le magasin qui décide seul du
réapprovisionnement auprès du fournisseur.
Exemple de MCC
On dénombre cinq acteurs : Client, Service ventes,
Service comptabilité, Magasin et Fournisseur.
On dénombre ensuite sept flux :
(1) et (2) Bon de commande : (du client au service ventes et du
service ventes au service comptabilité).
(3) Facture : du service comptabilité au client.
(4) Règlement : du client au service comptabilité.
(5) Bon de sortie : du service ventes au magasin.
(6) Bon de livraison+commande : du magasin vers le client.
(7) Bon de commande fournisseur pour éventuel
réapprovisionnement: du magasin vers le fournisseur.
Exemple de MCC
Service
Ventes
Service
Compta
Client
Fournisseur
Magasin
1
2
3
4
5
6
7
Référentiel
Décision
MERISE MCC - Modèle conceptuel de la communication
Conduite de projet 50
Merise : le niveau conceptuel
• Le Modèle Conceptuel de Communication (MCC)
définit les flux et les domaines
 Inventaire des informations et données
 Délimitation du système étudié
• Le modèle Conceptuel de Traitement (MCT) décrit
les règles et les contraintes générales du SI.
• Le Modèle Conceptuel de Données (MCD) décrit
l'organisation des données
Cohérence du MCD / MCC et au MCT
Validation par l'utilisateur
51
Modèle conceptuel de communication (MCC)
• N'existait pas dans les premières versions de MERISE
• A été introduit en rapport avec les Use Case d'UML
• Approche systémique : une entreprise est un
système. L'entreprise échange avec l'extérieur, avec
d'autres systèmes. Tout système interne ou externe est
appelé INTERVENANT.
• Tout système se décompose en sous systèmes
fonctionnels ou INTERVENANTs.
52
Modèle conceptuel de communication (MCC)
53
Le type DOMAINE est représenté par un grand ovale (ou patatoïde) regroupant
le cas échéant des sous domaines (plus petits ovales). Dans chaque ovale on
indique le nom du domaine.
Le type MESSAGE est représenté par une flèche entre deux domaines et/ou
intervenants avec le nom du message écrit au dessus de la flèche
Modèle conceptuel de communication (MCC)
54
Un DOMAINE est un système ou sous-système qui a une mémoire et un SI. Un
domaine est fonctionnel, il joue un rôle. Un domaine peut se décomposer en sous-
domaines.
Exemple : une entreprise (qui est un domaine) se compose des domaines Vendre,
Produire, Gérer le personnel ; ses partenaires sont Client, Etat, …
Modèle conceptuel de communication (MCC)
• Pour une entreprise de livraison on pourra distinguer
les Intervenants : LIVRER, FACTURER, ENCAISSER
• Un PARTENAIRE est un intervenant extérieur à
l'entreprise.
• Exemples de partenaires FONCTIONNELs: CLIENT qui
paye, FOURNISSEUR qui approvisionne, …
• Un partenaire est PHYSIQUE s'il est vu
fonctionnellement sous plusieurs facettes.
• Exemple : EDF est à la fois un fournisseur et un client
pour l'entreprise qui construit des transformateurs
électriques.
55
Modèle conceptuel de communication (MCC)
• Définition
 Un MCC détermine, par affinage successifs des
activités, la composition du domaine d'étude sans en
décrire le comportement.
• Le MCC se construit par raffinement successif
56
Modèle conceptuel de communication (MCC)
• Définition :
 Le MCC détermine le domaine d'étude et ses
échanges avec l'environnement.
• Concepts associés
 Domaine d'étude
 Acteurs externes
 Domaines connexes
 Message
57
MCC : Les concepts associés
• Domaine d'étude
– Sous ensemble cohérent de l'entreprise ou de l'organisme, bien
délimité et formant le contenu du sujet à étudier
• Activité
– Ensemble de traitements homogènes qui transforment ou manipulent
des données
• Message
– Représentation d'un échange d'informations entre deux composants
du système ou entre un composant du système et un système
extérieur
• Acteur externe
– Source ou destination de données située en dehors du système étudié
Gammes opératoires
• Objectifs
– Partitionner le domaine étudié en activités
– Point de passage obligé pour modéliser les traitements
– Maitriser la progression vers le détail du système
• Niveau de détail
– On s'arrête quand l'activité correspond à une opération.
• Démarche
– Identifier les flux de données entrant et sortant du domaine
– Identifier les activités
– Raffiner par conservation ou décomposition
Définition de l'organisation
• La première étape de ce modèle est d'arriver à isoler
le système en le délimitant. Il s'agit donc de définir le
système et les éléments externes avec lesquels il
échange des flux d'information. Ces éléments
extérieurs sont appelés acteurs externes (ou
partenaires).
Définition de l'organisation
• La seconde étape consiste à découper l'organisation
en entités appelées acteurs internes (ou domaines).
Lorsque les domaines d'une organisation sont trop
importants, ils peuvent être décomposés eux-mêmes
en sous-domaines.
Diagramme de contexte
• Le diagramme de contexte a pour but de représenter les flux
d'informations entre l'organisation et les acteurs externes
selon une représentation standard dans laquelle chaque objet
porte un nom :
• l'organisation est représentée par un rectangle
• les acteurs externes sont représentés par des ellipses en
pointillés
• les flux d'information sont représentés par des flèches dont
l'orientation désigne le sens du flux d'information
Diagramme conceptuel de flux
• Ce diagramme (appelé aussi modèle conceptuel de la
communication) permet de compléter le diagramme de
contexte en décomposant l'organisation en une série
d'acteurs internes. Dans ce diagramme la représentation
standard est la suivante :
• Les acteurs internes sont représentés par des ellipses
• les messages internes sont représentés par des flèches
MERISE MCC – Exemple de Modèle conceptuel de la communication
Conduite de projet 64
Exemple de MCC - Niveau 0
Assurance
Assuré
Déclaration de sinistre
Niveau prise en charge
Règlement sinistre
Expert
Garage Agréé
Facture
Exemple de MCC - Niveau 1
Sinistre
Auto
Compta
Assuré
Garage Agréé
Expert
Déclaration de sinistre
Niveau prise en
charge
Facture
Ordre de
paiement
Paiement
67
Travail en sous-groupe sur la réalisation d’un MCC
Réalisation d’un Modèle Conceptuel
de Communication (MCC)
Exercice Merise MCC
Voici la description du fonctionnement d'une société de services :
Modélisation du système de gestion des affaires d'une société de service.
Le Service Commercial est chargé d'examiner les études de demande client (cahier des
charges). Si ceux-ci correspondent à l'activité de la société, le dossier est transmis à la
Direction Technique qui élabore un devis estimatif. Celui-ci est complété au Service
Commercial, édité et envoyé au client pour accord.
Si le devis commercial est accepté par le client, le Service Commercial adresse une
demande d'étude technique au Service Technique.
Le Directeur Technique élabore des devis techniques qui correspondent à un
découpage en lots du devis technique.
Chaque devis est transmis à un Chef de Projet. Celui-ci procède à un nouveau
découpage technique du devis et établit le planning de réalisation en affectant chacun
des postes du devis technique à un Analyste Programmeur.
Exercice Merise MCC
Les Analystes Programmeurs établissent chaque jour un compte rendu d'activité. Chaque
semaine, le Chef de Projet édite un rapport d'avancement et informe la Direction
Technique de la situation des travaux en cours.
Lorsqu'un poste du devis technique est réalisé, le chef de Projet transmet les programmes
au client qui établit un procès verbal de réception. La recette est signalée au Service
Comptable pour facturation.
Chaque mois, une proposition de facture est établie par le Service Comptable et transmise
à la Direction Technique pour être validée. Cette proposition correspond à l'ensemble des
lignes du devis commercial non facturées.
Les factures sont ensuite éditées et envoyées au client par le Service Comptable.
Etablir le M.C.C. correspondant à l'organisation de cette société, en mettant en scène les
acteurs suivants, et en prenant la société comme référentiel :
Le Client.
Le Service Commercial.
La Direction Technique.
Le Chef de Projet.
L'Analyste Programmeur.
Le Service Comptable.
Analyse de Process et Workflow 70
L’analyse logicielle avec UML (Unified Modeling Langage)
Conduite de projet 71
L’analyse logicielle avec UML
Les différents types de diagrammes
Tout comme la construction
d’une maison nécessite des
plans à différents niveaux
(vision extérieure, plan des
différents étages, plans
techniques…), la réalisation
d’une application informatique
ou d’un ensemble d’applications
est basée sur plusieurs
diagrammes.
L’analyse logicielle avec UML
Les différents types de diagrammes
Le langage UML est constitué de diagrammes. À ce jour, il
existe 13 diagrammes « officiels ». Ces diagrammes sont tous
réalisés à partir du besoin des utilisateurs et peuvent être
regroupés selon les deux aspects suivants :
L’analyse logicielle avec UML
Les différents types de diagrammes
Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi
faire ? Comment les actions devront-elles se dérouler ? Quelles
informations seront utilisées pour cela ?
Les aspects liés à l’architecture : Quels seront les différents
composants logiciels à utiliser (base de données, librairies,
interfaces, etc.) ? Sur quel matériel chacun des composants
sera installé ?
UML modélise donc le système logiciel suivant ces deux modes
de représentation.
UML = Unified Modeling Langage
• Nous allons donc dans un premier temps décrire ces différents
aspects d’un logiciel grâce au schéma 4+1 vues et parcourir
brièvement les différents diagrammes qui les composent
La vue (4 + 1)
• Vue des besoin utilisateurs
– Cette vue (dont le nom exact est "vue des cas
d'utilisation"), guide toutes les autres
• Vue logique
– Cette vue de haut niveau se concentre sur
l’abstraction et l’encapsulation, elle modélise les
éléments et mécanismes principaux du système
• Vue des processus
– Cette vue est très importante dans les
environnements multitâches
La vue (4 + 1)
• Vue des composants
– Cette vue de bas niveau (aussi appelée "vue
de réalisation"), Identifie les modules qui
réalisent (physiquement) les classes de la vue
logique
• Vue de déploiement
– Cette vue très importante dans les
environnements distribués, décrit les
ressources matérielles et la répartition du
logiciel dans ces ressources
Vue des cas d’utilisation
• Cette vue guide toutes les autres
– A l'aide de scénarios et de cas d’utilisation,
cette vue conduit à la définition d'un
modèle d'architecture pertinent et cohérent
– Elle définit les besoins des clients du
système et centre la définition de
l'architecture du système sur la satisfaction
(la réalisation) de ces besoins
– Cette vue est la "colle" qui unifie les quatre
autres vues de l'architecture
Diagrammes
Dynamiques
 diagramme de cas utilisation
 diagramme de séquences
 diagramme de collaborations
 diagramme d‘états-transitions
 diagramme d‘activité
Statiques
 diagramme de classes
 diagramme d‘ objets
 diagramme de composants
 diagramme de déploiement
3 axes de modélisation
Fonctionnel
Statique
Dynamique
- Diagramme de Use Cases
(diagramme d’activité)
(diagramme de séquence)
- Diagramme de Classe
(diagramme d’objet)
- Diagramme de composants
(diagramme de déploiement)
- Diagramme d’état
(diagramme d’activité)
(diagramme de séquence)
- Diagramme de collaboration
L’analyse logicielle avec UML (Zoom sur le Use Cases)
Conduite de projet 81
Cas d’utilisation
• Ce diagramme décrit les situations auxquelles
le système doit répondre.
• Il permet d’établir les fonctionnalités
nécessaires au bon fonctionnement d’un site
internet, quels sont les différents acteurs et
quelles relations existent entre eux
– On se place du point de vue de l'utilisateur.
Diagramme de cas d’utilisation
• Il contient
– des acteurs : ce sont des personnes ou systèmes extérieurs
à l'application, et qui interagissent avec elle.
– des cas d'utilisation : représentent une fonctionnalité (un
objectif à atteindre) du système à construire. Ils sont en
relation avec des acteurs et d'autres cas d'utilisation
– des relations : elle sont généralement orientées
– le système : représente l'application et les cas d'utilisation
– Les packages : correspondent à des regroupements logiques
Diagramme de cas d’utilisation
Diagramme de cas d’utilisation
Acteur : se représente sous la forme d’un petit
personnage ou sous la forme de classe avec le mot clé
<<acteur>>
Note : se représente sous la forme de « papier plié »
précisant certaines contraintes
Cas d’utilisation : se représente sous la forme d’ellipse.
Les cas d’utilisation peuvent être contenus dans un
rectangle qui représente les limites du système
Association : représente la relation entre un acteur et un
cas d’utilisation, elle se schématise par un trait.
<<Acteur>>
Nom de
l’acteur
• Les relations entre cas d’utilisation
– Relation de généralisation
• Le cas d’utilisation enfant est une spécialisation du
cas d’utilisation parent qui peut être abstrait.
Cas d’utilisation
Enfant
Cas d’utilisation
Parent
Cas d’utilisation
Cas d’utilisation
• Les relations entre cas d’utilisation
– Relation d’inclusion
• Cette relation permet de décomposer les
comportements et de définir des comportements
partageables entre plusieurs cas d’utilisation.
• Une instance du cas d ’utilisation source comprend le
comportement décrit dans le cas d’utilisation
destination.
Cas d’utilisation Destination
Cas d’utilisation Source
<<inclus>>
Cas d’utilisation
• Les relations entre cas d’utilisation
– Relation d’extension
• Le cas d’utilisation source ajoute son comportement
au cas d’utilisation destination.
• Elle permet de modéliser des variantes de
comportement d’un cas d’utilisation.
<<étend>>
Cas d’utilisation Destination
Cas d’utilisation Source
Cas d’utilisation
• Exemple des différentes relations entre cas
d’utilisation
Virement
Point d’extension :
vérification
supplémentaire après
identification
Client local
Client distant
Virement
par
internet
Identification
<<inclus>>
Vérification
solde compte
<<étend>>
si Montant > 100 €
L’analyse logicielle avec UML (Le diagramme de séquence)
Conduite de projet 90
Diagramme de séquence
• Le Diagramme de séquence présente un
écoulement dans le temps. Il séquence les
différents messages.
• Ce diagramme montre les messages avec
valeur et sans valeur qui sont échangés entre
les différents acteurs.
• La notion de temps est importante elle
permet de temporiser et d’ordonner les
messages.
Diagramme de séquence
Système
Porteur de CB
SA Visa/Mastercard
Introduction carte
Demande de code secret
Code (valeur)
Demande autorisation
Autorisation (solde)
Demande montant retrait
Retrait (valeur)
Demande ticket
OK
éjection carte
Récupérer carte
Éjection billets + ticket
Récupération billets + ticket
Axedutemps
Vérification carte
Vérification code Voir A2 et B4
code erroné
Contrôle montant
Voir A6 ticket refusé
L’analyse logicielle avec UML (Les diagrammes)
Conduite de projet 93
Les diagrammes UML
• Voici quelques exemples de diagramme qui peuvent être utilisés
dans une démarche d’analyse et de conception d’un logiciel. Ne
vous inquiétiez pas du nombre de diagrammes ci-dessous. Il s’agit
ici simplement de vous familiariser à ces diagrammes.
• L’objectif est d’avancer pas à pas dans l’analyse des besoins initiaux
des utilisateurs, afin de travailler plus particulièrement les 4
diagrammes suivants :
1. le diagramme de contexte. Ce diagramme n’est pas officiellement
désigné comme diagramme UML. Il ne fait donc pas partie des 13
diagrammes « officiels », mais il est utile pour la définition des
acteurs, avant de commencer à s’intéresser à d’autres aspects,
tels que les packages et les cas d’utilisation.
2. le diagramme de package
3. le diagramme de cas d’utilisation
4. le diagramme d’activité.
Les besoins des utilisateurs (1)
• Cette partie représente le cœur de l’analyse. Il est
composé de cas d’utilisation (que nous verrons
plus tard). On y décrit le contexte, les acteurs ou
utilisateurs du projet logiciel, les fonctionnalités
du logiciel mais aussi les interactions entre ces
acteurs et ces fonctionnalités. C’est d’ailleurs
aussi le cœur de notre cours.
• Le besoin des utilisateurs peut être décrit à
l’aide de deux diagrammes.
Les besoins des utilisateurs (1)
• Le diagramme de packages permet de décomposer le système en catégories ou
parties plus facilement observables, appelés « packages ». Cela permet également
d’indiquer les acteurs qui interviennent dans chacun des packages.
Les besoins des utilisateurs (1)
• Dans l’exemple précédent, nous voyons que le logiciel
que nous concevons peut être divisé en trois parties
(ou packages) observables séparément :
• La gestion des commandes client
• La gestion des stocks
• La gestion des achats
•
• La boîte qui entoure les packages (la boîte bleue)
correspond au système (c’est-à-dire le logiciel) qui est
analysé.
Les besoins des utilisateurs (1)
• Le diagramme de cas d’utilisation représente les fonctionnalités (ou dit
cas d’utilisation) nécessaires aux utilisateurs. On peut faire un diagramme
de cas d’utilisation pour le logiciel entier ou pour chaque package.
Étant donné que le diagramme de cas d’utilisation détaille le contenu d’un
package, ici la boîte bleue correspond au package qui est détaillé.
Vue logique (2)
• La vue logique a pour but d’identifier les
éléments du domaine, les relations et
interactions entre ces éléments. Cette vue
organise les éléments du domaine en «
catégories ». Deux diagrammes peuvent être
utilisés pour cette vue.
Vue logique (2)
• Le diagramme de classes
• Dans la phase d’analyse, ce diagramme représente les entités (des informations)
manipulées par les utilisateurs. Dans la phase de conception, il représente la
structure objet d’un développement orienté objet.
Vue logique (2)
• Le diagramme d’objets sert à illustrer les classes complexes en utilisant
des exemples d’instances. Une instance est un exemple concret de
contenu d’une classe. En illustrant une partie des classes avec des
exemples (grâce à un diagramme d’objets), on arrive à voir un peu plus
clairement les liens nécessaires
Vue des processus (3)
• La vue des processus démontre :
• la décomposition du système en processus et
actions ;
• les interactions entre les processus ;
• la synchronisation et la communication des
activités parallèles.
• La vue des processus s’appuie sur plusieurs
diagrammes.
Vue des processus (3)
• Le diagramme de séquence permet de décrire
les différents scénarios d’utilisation du
système.
Vue des processus (3)
• Le diagramme d’activité représente le déroulement des actions,
sans utiliser les objets. En phase d’analyse, il est utilisé pour
consolider les spécifications d’un cas d’utilisation.
Vue des processus (3)
• Le diagramme de collaboration (appelé également diagramme de
communication) permet de mettre en évidence les échanges de messages
entre objets. Cela nous aide à voir clair dans les actions qui sont
nécessaires pour produire ces échanges de messages. Et donc de
compléter, si besoin, les diagrammes de séquence et de classes.
Vue des processus (3)
• Le diagramme d’état-transition permet de
décrire le cycle de vie des objets d’une classe
Vue des processus (3)
• Le diagramme global
d’interaction permet de
donner une vue
d’ensemble des
interactions du système.
Il est réalisé avec le
même graphisme que le
diagramme d’activité.
Chaque élément du
diagramme peut ensuite
être détaillé à l’aide d’un
diagramme de séquence
ou d’un diagramme
d’activité.
Vue des processus (3)
• Le diagramme de temps est destiné à l’analyse et la conception de
systèmes ayant des contraintes temps-réel. Il s’agit là de décrire les
interactions entre objets avec des contraintes temporelles fortes.
L’aspect lié à l’architecture du logiciel
• Pour rappel, cette partie du schéma 4+1 vue
permet de définir les composantes à utiliser
(exécutables, interfaces, base de données,
librairies de fonctions, etc.) et les matériels sur
lesquels les composants seront déployés.
Vue des composants (4)
• La vue des composants (vue de réalisation)
met en évidence les différentes parties qui
composeront le futur système (fichiers
sources, bibliothèques, bases de données,
exécutables, etc.).
• Cette vue comprend deux diagrammes :
Vue des composants (4)
• Le diagramme de structure composite décrit
un objet complexe lors de son exécution.
Vue des composants (4)
• Le diagramme de composants décrit tous les
composants utiles à l’exécution du système
(applications, librairies, instances de base de
données, exécutables, etc.).
Vue de déploiement (5)
• La vue de déploiement décrit les ressources
matérielles et la répartition des parties du
logiciel sur ces éléments. Il contient un
diagramme :
• Le diagramme de déploiement correspond à
la description de l’environnement d’exécution
du système (matériel, réseau…) et de la façon
dont les composants y sont installés.
Vue de déploiement (5)
En synthèse
• UML est constitué de 13 diagrammes qui
représentent chacun un concept du système ou
logiciel.
• Un logiciel peut être vu en considérant les
aspects fonctionnels et les aspects d’architecture
du logiciel. Ces deux aspects sont composés de 4
vues du logiciel à développer, organisés autour
des besoins des utilisateurs. C’est le 4+1 vues.
• Chacune des 4+1 vues est constituée de
diagrammes.
Merci de votre attention
116

Contenu connexe

Tendances

Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Ayoub Minen
 
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-ConsultingRapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-ConsultingMohamed Cherkaoui
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineMohamed Amine Mahmoudi
 
QCM système d'information
QCM système d'informationQCM système d'information
QCM système d'informationFrust Rados
 
Le processus d'achat et approvisionnement
Le processus d'achat et approvisionnement Le processus d'achat et approvisionnement
Le processus d'achat et approvisionnement Aboubakr Moubarak
 
Ressources Humaines Maroc Telecom
Ressources Humaines Maroc TelecomRessources Humaines Maroc Telecom
Ressources Humaines Maroc TelecomImane Qmichou
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
cahier des charges
cahier des chargescahier des charges
cahier des chargesamine niba
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Atelier 3 gestion de bases de données sous odoo
Atelier 3 gestion de bases de données sous odooAtelier 3 gestion de bases de données sous odoo
Atelier 3 gestion de bases de données sous odooAbdelouahed Abdou
 
Ingénierie de formation, compil de P. Clauzard
Ingénierie de formation, compil de P. ClauzardIngénierie de formation, compil de P. Clauzard
Ingénierie de formation, compil de P. Clauzardphilip61
 
Manuel des TP : Atelier systèmes 2
Manuel des TP : Atelier systèmes 2Manuel des TP : Atelier systèmes 2
Manuel des TP : Atelier systèmes 2Faycel Chaoua
 
Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesTahani RIAHI
 
plan de formation
plan de formation plan de formation
plan de formation errhif imane
 

Tendances (20)

Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
 
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-ConsultingRapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
 
QCM système d'information
QCM système d'informationQCM système d'information
QCM système d'information
 
QCM Sécurité Informatique
QCM Sécurité InformatiqueQCM Sécurité Informatique
QCM Sécurité Informatique
 
Le processus d'achat et approvisionnement
Le processus d'achat et approvisionnement Le processus d'achat et approvisionnement
Le processus d'achat et approvisionnement
 
Le GRH
Le GRH Le GRH
Le GRH
 
Ressources Humaines Maroc Telecom
Ressources Humaines Maroc TelecomRessources Humaines Maroc Telecom
Ressources Humaines Maroc Telecom
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Memoire de master en GRH
Memoire de master en GRHMemoire de master en GRH
Memoire de master en GRH
 
cahier des charges
cahier des chargescahier des charges
cahier des charges
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Atelier 3 gestion de bases de données sous odoo
Atelier 3 gestion de bases de données sous odooAtelier 3 gestion de bases de données sous odoo
Atelier 3 gestion de bases de données sous odoo
 
Ingénierie de formation, compil de P. Clauzard
Ingénierie de formation, compil de P. ClauzardIngénierie de formation, compil de P. Clauzard
Ingénierie de formation, compil de P. Clauzard
 
Manuel des TP : Atelier systèmes 2
Manuel des TP : Atelier systèmes 2Manuel des TP : Atelier systèmes 2
Manuel des TP : Atelier systèmes 2
 
Modèle cahier des charges site web
Modèle cahier des charges site webModèle cahier des charges site web
Modèle cahier des charges site web
 
Presentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'EtudesPresentation de soutenance du Projet Fin d'Etudes
Presentation de soutenance du Projet Fin d'Etudes
 
Slide farany l3
Slide farany l3Slide farany l3
Slide farany l3
 
Gestion de la carrière
Gestion de la carrièreGestion de la carrière
Gestion de la carrière
 
plan de formation
plan de formation plan de formation
plan de formation
 

Similaire à Analyse de processus et workflow

Formation analyse de processus et workflow
Formation analyse de processus et workflowFormation analyse de processus et workflow
Formation analyse de processus et workflowEchecs et Stratégie
 
Gestion des projets
Gestion des projetsGestion des projets
Gestion des projetsAnas Mansour
 
Portfolio TC 26juin15
Portfolio TC 26juin15Portfolio TC 26juin15
Portfolio TC 26juin15Tony Chauvet
 
Restitution atelier assistant personnel du 1304
Restitution atelier assistant personnel du 1304Restitution atelier assistant personnel du 1304
Restitution atelier assistant personnel du 1304Nathalie Plegades
 
Restitution atelier Assistant personnel #9 du 1905
Restitution atelier Assistant personnel #9 du 1905Restitution atelier Assistant personnel #9 du 1905
Restitution atelier Assistant personnel #9 du 1905Nathalie Plegades
 
Atelier sur la planification
Atelier sur la planificationAtelier sur la planification
Atelier sur la planificationProsygma
 
Expression de besoin pour le si
Expression de besoin pour le siExpression de besoin pour le si
Expression de besoin pour le sifatima zahra FANDI
 
Formation fiabilité et maintenance 2014 2015
Formation fiabilité et maintenance 2014 2015Formation fiabilité et maintenance 2014 2015
Formation fiabilité et maintenance 2014 2015Michel Cote
 
Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...
Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...
Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...PMI-Montréal
 
Web-formation | L'Obeya pour le pilotage de projets Lean Développement
Web-formation | L'Obeya pour le pilotage de projets Lean DéveloppementWeb-formation | L'Obeya pour le pilotage de projets Lean Développement
Web-formation | L'Obeya pour le pilotage de projets Lean DéveloppementXL Groupe
 
Cymgle2 formation-structurez-vos-equipes-14-points-pdus
Cymgle2 formation-structurez-vos-equipes-14-points-pdusCymgle2 formation-structurez-vos-equipes-14-points-pdus
Cymgle2 formation-structurez-vos-equipes-14-points-pdusCERTyou Formation
 
Restitution atelier assistant personnel du 120516
Restitution atelier assistant personnel du 120516Restitution atelier assistant personnel du 120516
Restitution atelier assistant personnel du 120516Nathalie Plegades
 
Web-formation - "Le Lean Office"
Web-formation - "Le Lean Office"Web-formation - "Le Lean Office"
Web-formation - "Le Lean Office"XL Groupe
 
Movc formation-management-of-value-mov-foundation-plus-practitioner
Movc formation-management-of-value-mov-foundation-plus-practitionerMovc formation-management-of-value-mov-foundation-plus-practitioner
Movc formation-management-of-value-mov-foundation-plus-practitionerCERTyou Formation
 
Comment mener un recrutement efficace
Comment mener un recrutement efficaceComment mener un recrutement efficace
Comment mener un recrutement efficaceEnactusFrance
 
Boubaddara Youssef: Mise en place d'un SMQ par Mme Debethune
Boubaddara Youssef: Mise en place d'un SMQ par Mme DebethuneBoubaddara Youssef: Mise en place d'un SMQ par Mme Debethune
Boubaddara Youssef: Mise en place d'un SMQ par Mme DebethuneYoussef Boubaddara
 
Démarche qualité slideshare
Démarche qualité slideshareDémarche qualité slideshare
Démarche qualité slideshareBéatrice BRINET
 

Similaire à Analyse de processus et workflow (20)

Formation analyse de processus et workflow
Formation analyse de processus et workflowFormation analyse de processus et workflow
Formation analyse de processus et workflow
 
Gestion des projets
Gestion des projetsGestion des projets
Gestion des projets
 
Formation gestion de projet
Formation gestion de projetFormation gestion de projet
Formation gestion de projet
 
Portfolio TC 26juin15
Portfolio TC 26juin15Portfolio TC 26juin15
Portfolio TC 26juin15
 
Restitution atelier assistant personnel du 1304
Restitution atelier assistant personnel du 1304Restitution atelier assistant personnel du 1304
Restitution atelier assistant personnel du 1304
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
 
Restitution atelier Assistant personnel #9 du 1905
Restitution atelier Assistant personnel #9 du 1905Restitution atelier Assistant personnel #9 du 1905
Restitution atelier Assistant personnel #9 du 1905
 
Atelier sur la planification
Atelier sur la planificationAtelier sur la planification
Atelier sur la planification
 
Expression de besoin pour le si
Expression de besoin pour le siExpression de besoin pour le si
Expression de besoin pour le si
 
Formation fiabilité et maintenance 2014 2015
Formation fiabilité et maintenance 2014 2015Formation fiabilité et maintenance 2014 2015
Formation fiabilité et maintenance 2014 2015
 
Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...
Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...
Symposium 2017 - Atelier 104 Gérer la capacité de l’organisation à réaliser s...
 
Lync - Télétravail et mobilité
Lync - Télétravail et mobilitéLync - Télétravail et mobilité
Lync - Télétravail et mobilité
 
Web-formation | L'Obeya pour le pilotage de projets Lean Développement
Web-formation | L'Obeya pour le pilotage de projets Lean DéveloppementWeb-formation | L'Obeya pour le pilotage de projets Lean Développement
Web-formation | L'Obeya pour le pilotage de projets Lean Développement
 
Cymgle2 formation-structurez-vos-equipes-14-points-pdus
Cymgle2 formation-structurez-vos-equipes-14-points-pdusCymgle2 formation-structurez-vos-equipes-14-points-pdus
Cymgle2 formation-structurez-vos-equipes-14-points-pdus
 
Restitution atelier assistant personnel du 120516
Restitution atelier assistant personnel du 120516Restitution atelier assistant personnel du 120516
Restitution atelier assistant personnel du 120516
 
Web-formation - "Le Lean Office"
Web-formation - "Le Lean Office"Web-formation - "Le Lean Office"
Web-formation - "Le Lean Office"
 
Movc formation-management-of-value-mov-foundation-plus-practitioner
Movc formation-management-of-value-mov-foundation-plus-practitionerMovc formation-management-of-value-mov-foundation-plus-practitioner
Movc formation-management-of-value-mov-foundation-plus-practitioner
 
Comment mener un recrutement efficace
Comment mener un recrutement efficaceComment mener un recrutement efficace
Comment mener un recrutement efficace
 
Boubaddara Youssef: Mise en place d'un SMQ par Mme Debethune
Boubaddara Youssef: Mise en place d'un SMQ par Mme DebethuneBoubaddara Youssef: Mise en place d'un SMQ par Mme Debethune
Boubaddara Youssef: Mise en place d'un SMQ par Mme Debethune
 
Démarche qualité slideshare
Démarche qualité slideshareDémarche qualité slideshare
Démarche qualité slideshare
 

Plus de Echecs et Stratégie

Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durableEchecs et Stratégie
 
Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durableEchecs et Stratégie
 
Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durableEchecs et Stratégie
 
Jeu d'échecs et stratégie d'entreprise
Jeu d'échecs et stratégie d'entrepriseJeu d'échecs et stratégie d'entreprise
Jeu d'échecs et stratégie d'entrepriseEchecs et Stratégie
 
Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique Echecs et Stratégie
 
Développement durable et Green it
Développement durable et Green itDéveloppement durable et Green it
Développement durable et Green itEchecs et Stratégie
 
Formation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe DornbuschFormation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe DornbuschEchecs et Stratégie
 

Plus de Echecs et Stratégie (20)

Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durable
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
 
Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durable
 
Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durable
 
Jeu d'échecs et stratégie d'entreprise
Jeu d'échecs et stratégie d'entrepriseJeu d'échecs et stratégie d'entreprise
Jeu d'échecs et stratégie d'entreprise
 
Developpement durable et green it
Developpement durable et green itDeveloppement durable et green it
Developpement durable et green it
 
Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique
 
Stratégie d'entreprise
Stratégie d'entrepriseStratégie d'entreprise
Stratégie d'entreprise
 
Cours de Gestion du temps
Cours de Gestion du tempsCours de Gestion du temps
Cours de Gestion du temps
 
Formation Gestion de projet
Formation Gestion de projetFormation Gestion de projet
Formation Gestion de projet
 
Développement durable et Green it
Développement durable et Green itDéveloppement durable et Green it
Développement durable et Green it
 
Formation en conduite de projet
Formation en conduite de projet Formation en conduite de projet
Formation en conduite de projet
 
Cours de Gestion du temps
Cours de Gestion du tempsCours de Gestion du temps
Cours de Gestion du temps
 
Formation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe DornbuschFormation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe Dornbusch
 
La Gestion du Temps
La Gestion du TempsLa Gestion du Temps
La Gestion du Temps
 
Stratégie d'entreprise
Stratégie d'entrepriseStratégie d'entreprise
Stratégie d'entreprise
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Apprendre à jouer aux echecs
Apprendre à jouer aux echecsApprendre à jouer aux echecs
Apprendre à jouer aux echecs
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 

Dernier

PowerPoint-de-Soutenance-de-TFE-infirmier.pdf
PowerPoint-de-Soutenance-de-TFE-infirmier.pdfPowerPoint-de-Soutenance-de-TFE-infirmier.pdf
PowerPoint-de-Soutenance-de-TFE-infirmier.pdfDafWafia
 
PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024
PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024
PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024frizzole
 
Formation IAT pour sonelgaz chlef algérie.ppt
Formation IAT pour sonelgaz chlef algérie.pptFormation IAT pour sonelgaz chlef algérie.ppt
Formation IAT pour sonelgaz chlef algérie.pptBOULANORICHRAF
 
Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...
Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...
Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...Pedago Lu
 
Les débuts de la collection "Le livre de poche"
Les débuts de la collection "Le livre de poche"Les débuts de la collection "Le livre de poche"
Les débuts de la collection "Le livre de poche"ArchivesdeLyon
 
Quitter la nuit. pptx
Quitter          la        nuit.    pptxQuitter          la        nuit.    pptx
Quitter la nuit. pptxTxaruka
 
Système National de Santé au- Maroc-(2017)."pdf"
Système National de Santé au- Maroc-(2017)."pdf"Système National de Santé au- Maroc-(2017)."pdf"
Système National de Santé au- Maroc-(2017)."pdf"tachakourtzineb
 
Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...
Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...
Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...Technologia Formation
 
Quitter la nuit. pptx
Quitter        la             nuit.   pptxQuitter        la             nuit.   pptx
Quitter la nuit. pptxTxaruka
 
rapport de stage gros oeuvre_compressed.pdf
rapport de stage gros oeuvre_compressed.pdfrapport de stage gros oeuvre_compressed.pdf
rapport de stage gros oeuvre_compressed.pdfOssamaLachheb
 
Webinaire Technologia | DAX : nouvelles fonctions
Webinaire Technologia | DAX : nouvelles fonctionsWebinaire Technologia | DAX : nouvelles fonctions
Webinaire Technologia | DAX : nouvelles fonctionsTechnologia Formation
 

Dernier (12)

PowerPoint-de-Soutenance-de-TFE-infirmier.pdf
PowerPoint-de-Soutenance-de-TFE-infirmier.pdfPowerPoint-de-Soutenance-de-TFE-infirmier.pdf
PowerPoint-de-Soutenance-de-TFE-infirmier.pdf
 
PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024
PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024
PLANNING HEBDO ET CR LYCEE COUDON 21 MAI2024
 
Formation IAT pour sonelgaz chlef algérie.ppt
Formation IAT pour sonelgaz chlef algérie.pptFormation IAT pour sonelgaz chlef algérie.ppt
Formation IAT pour sonelgaz chlef algérie.ppt
 
Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...
Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...
Fiche - Accompagnement du travail coopératif au sein d’une équipe d’enseignan...
 
Traitement des eaux usées par lagunage a macrophytes.pptx
Traitement des eaux usées par lagunage a macrophytes.pptxTraitement des eaux usées par lagunage a macrophytes.pptx
Traitement des eaux usées par lagunage a macrophytes.pptx
 
Les débuts de la collection "Le livre de poche"
Les débuts de la collection "Le livre de poche"Les débuts de la collection "Le livre de poche"
Les débuts de la collection "Le livre de poche"
 
Quitter la nuit. pptx
Quitter          la        nuit.    pptxQuitter          la        nuit.    pptx
Quitter la nuit. pptx
 
Système National de Santé au- Maroc-(2017)."pdf"
Système National de Santé au- Maroc-(2017)."pdf"Système National de Santé au- Maroc-(2017)."pdf"
Système National de Santé au- Maroc-(2017)."pdf"
 
Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...
Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...
Présentation Webinaire Cohésion - Concevoir et mettre en place une CMDB, comm...
 
Quitter la nuit. pptx
Quitter        la             nuit.   pptxQuitter        la             nuit.   pptx
Quitter la nuit. pptx
 
rapport de stage gros oeuvre_compressed.pdf
rapport de stage gros oeuvre_compressed.pdfrapport de stage gros oeuvre_compressed.pdf
rapport de stage gros oeuvre_compressed.pdf
 
Webinaire Technologia | DAX : nouvelles fonctions
Webinaire Technologia | DAX : nouvelles fonctionsWebinaire Technologia | DAX : nouvelles fonctions
Webinaire Technologia | DAX : nouvelles fonctions
 

Analyse de processus et workflow

  • 1. Bienvenue à la formation Analyse de Processus et Workflow 1 Philippe DORNBUSCH Responsable du service Projets RH & Management Direction des Ressources Humaines du CA IDF
  • 2. Le tour de table des participants à cette formation 2
  • 3. 3 Tu me dis, j’oublie Tu m’enseignes, je me souviens Tu m’impliques, j’apprends Benjamin Franklin, (1706-1790), écrivain, inventeur et homme politique américain L’importance de la mise en pratique pendant cette formation
  • 4. Programme de la formation Introduction et Définition des processus Atelier fil rouge : mise en pratique avec des études de cas concrets Méthode d’Analyse des processus Merise et son Modèle Conceptuel de Communication (MCC) 4 Le Workflow (automatisation des tâches du processus) L’analyse logicielle avec UML (Unified Modeling Langage) Devoir individuel puis corrigé du devoir
  • 5. Organisation pratique de la journée 1 9h-9h30 Accueil des participants et tour de table 9h30 - 10h30 Définition et méthode d’analyse des processus 10h30 - 11h Pause 5 13h30 - 15h Définition d’un Workflow 11h – 12h30 Exercice d’analyse de processus : le télétravail 12h30 - 13h30 Pause déjeuner 15h - 15h30 Pause 15h30 - 17h Merise et le Modèle Conceptuel de Communication
  • 6. Organisation pratique de la journée 2 9h00 - 10h30 Réalisation d’un MCC 10h30 - 11h Pause 6 13h30 - 15h Cas d’utilisation et diagramme de séquence 11h -12h30 L’analyse logicielle avec UML 12h30 - 13h30 Pause déjeuner 15h - 15h30 Pause 15h30 - 16h30 Le Quiz individuel 16h30 – 17h00 Correction du Quiz et Conclusion de la formation
  • 7. 7 Introduction à la notion de processus
  • 8. Définition d’un Processus • Un processus est un ensemble d'activités corrélées ou en interaction qui utilise des éléments d'entrée pour produire un résultat escompté. Ces éléments sont soit des objets matériels (pouvant être perçus comme des flux par la logistique à des fins d'évaluation) soit des informations, soit les deux. 8
  • 9. Définition d’un Processus • Il ne faut pas confondre « processus » avec « procédure ». • Le premier décrit les activités de l'entreprise selon une vision transversale par rapport à l'organisation de celle-ci, tandis que le second explicite le "comment faire" dans cette organisation. • L'approche processus permet d'identifier et de maîtriser les interfaces entre les différentes activités. 9
  • 10. Définition d’un Processus • Le processus répond aux questions : QUOI FAIRE ? POUR QUELLE VALEUR AJOUTÉE ? • La procédure répond aux questions : COMMENT FAIRE ? QUAND ? QUI ? • Le mode opératoire répond de plus aux questions : OÙ ? SELON QUEL PROCÉDÉ ? • Le mode pilotage répond de plus à la question : COMBIEN ? 10
  • 11. Méthode d’analyse des processus 11
  • 12. L'analyse des processus – les étapes • Lorsqu'on veut optimiser ou transformer radicalement un processus, on a besoin d'une méthode rigoureuse. • L'analyse des processus est l'outil le mieux adapté à ces deux tâches. En mode « transformation radicale », elle aide à changer non seulement les façons de faire, mais également les façons de voir, soit les paradigmes des personnes concernées. • En outre, cette méthode favorise la participation en mettant à contribution des salariés de divers secteurs qui travaillent en contact constant avec les acteurs du processus (dans une démarche de type « expert », les participants sont en vase clos sans interaction avec l'environnement). 12
  • 13. L'analyse des processus – les étapes La méthode implique deux questions fondamentales, celle de la pertinence et celle de l'efficacité des activités et des étapes du processus. En d'autres mots: • Faisons-nous les bonnes choses pour nos clients ? • Les faisons-nous de la meilleure façon ? 13
  • 14. Les résultats escomptés • Processus redessinés, prêts à être implantés et qui livrent un résultat conforme aux spécifications du client. • Processus qui améliorent la performance organisationnelle sur 4 axes à la fois: client, ressources humaines, ressources financières et opérations. • Recommandations concernant le nouveau processus et description des impacts sur l'encadrement, les gains et investissements financiers, la technologie, les ressources humaines, etc. 14
  • 15. Les conditions de succès • S'assurer que les processus analysés sont prioritaires ou liés aux orientations stratégiques. • Dès le début de la démarche, s'associer en mode concerté avec les instances syndicales. • Faire preuve de transparence à toutes les étapes. • Concevoir et appliquer une stratégie de communication pour informer toute l'organisation. 15
  • 16. Les conditions de succès • Être prêt à investir du temps, de l'énergie et des ressources. • Respecter les membres de l'équipe (liberté de s'associer ou non aux recommandations). • Confier à une ressource externe le soin d'accompagner l'équipe (rigueur méthodologique, apprentissage des outils et du processus de changement organisationnel). 16
  • 17. 17 Analyse d’un processus Le Télétravail en entreprise
  • 18. Le parcours du Télétravail La demande du collaborateur Le collaborateur enregistre sa demande de télétravail à partir de l’outil dédié (Téléflow) 1 Collaborateur du siège 3 La signature de l’avenant au contrat de travail Après accord du manager, le collaborateur fournit les pièces demandées par la DRH puis signe son avenant La décision du manager Le manager organise une réunion d’analyse de la demande avec le collaborateur et décide (accord / refus) 2 4 3 5 La récupération du matériel Le collaborateur récupère le matériel requis auprès de DOMS/IT Le démarrage du télétravail Le collaborateur installe le matériel à son domicile et télétravaille le moment venu
  • 19. Le parcours du Télétravail La demande du collaborateur1 Avant de faire sa demande, le collaborateur peut autoévaluer ses aptitudes et ses motivations au télétravail à l’aide de la grille disponible sur chorale NET  Le collaborateur crée une demande à partir de Téléflow La décision du manager2  Le manager est prévenu par mail de la demande de télétravail de son collaborateur  Le manager organise un entretien (dans un délai de 30 jours à compter de la réception du mail) avec son collaborateur pour en apprécier l’éligibilité au télétravail. Il utilise la Grille d’éligibilité au télétravail disponible sur chorale NET  Le manager acte sa décision, en la motivant, sur Téléflow (dans un délai de 60 jours à compter de l’entretien) La signature de l’avenant au contrat de travail3  Le collaborateur est prévenu par mail de la décision de son manager  En cas d’accord du manager, le collaborateur dépose dans Téléflow une attestation sur l’honneur de la conformité de l’installation électrique de son domicile et une attestation de couverture Multi risques habitation intégrant la pratique du télétravail. Des modèles et exemples sont disponibles sur chorale NET  La DRH contrôle la conformité des documents puis fait parvenir au manager l’avenant en double exemplaire qui les remet à son collaborateur La récupération du matériel4  DOMS annonce par mail au collaborateur que le matériel requis est disponible  Le collaborateur vient récupérer son matériel en suivant les instructions de DOMS et signe une prise en charge. Le démarrage du télétravail5  Le collaborateur installe le matériel à son domicile en suivant les indications du Guide Technique du Télétravail mis à disposition sur chorale NET  Le collaborateur peut commencer le télétravail à la date convenue dans l’avenant  Le collaborateur signe l’avenant. Il envoie à la DRH l’avenant papier signé (nécessité juridique) et en dépose une copie dans Téléflow. Il conserve le deuxième exemplaire
  • 20. Pour le télétravailleur • Préparer votre journée de télétravail en vous assurant d’avoir tous les éléments nécessaires. • Fixez-vous des objectifs et des livrables à réaliser au cours de la journée. • Fixez, avec votre manager, des plages de joignabilité. • Les documents confidentiels doivent rester sur le lieu de travail et ne doivent pas être emmenés au domicile • Même si vous êtes en télétravail, vous avez l’obligation de vous rendre au rendez-vous, réunions et formations durant lesquels votre présence est impérative en décalant si besoin votre journée de télétravail dans la même semaine, avec accord de votre hiérarchie. • Informez vos collègues que vous êtes en télétravail. Rappelez que vous êtes joignable comme sur votre lieu de travail habituel. • Délimitez votre espace de travail à domicile • Adoptez une bonne posture de travail Pour le manager et l’équipe • Favorisez les réunions d’équipe les jours où le télétravailleur est présent. • Quand la réunion a lieu un jour où il n’est pas présent, n’oubliez pas de l’intégrer à distance. • N’omettez pas le télétravailleur dans l’envoi de vos mails. • Ayez le réflexe de solliciter le télétravailleur comme vous le feriez quand il est présent au bureau et non un collègue parce que lui est physiquement là. • Même en dehors des locaux, le télétravailleur est joignable aux heures habituelles et pas seulement en cas d’urgence. Organiser le télétravail
  • 21. Calendrier de déploiement par vagues successives de 50 collaborateurs vague 1 : ouverture du Workflow des demandes aux collaborateurs le 18 avril – validation Managers jusqu’au 5 Mai - Équipement de 50 collaborateurs au 1er juin 2017 vague 2 : validation Managers jusqu’au 19 Mai - Équipement de nouveaux collaborateurs au 1er juillet 2017 vague 3 : validation Managers jusqu’au 18 Août - Équipement de nouveaux collaborateurs au 1er octobre 2017 puis nouvelles vagues trimestrielles à compter de 2018 (janvier et juillet)
  • 22. Les 4 étapes dans l’analyse des processus 22
  • 23. Les 4 étapes de l'analyse des processus • Élaborer le mandat de l'équipe • Analyser le processus actuel • Baliser • Élaborer la nouvelle architecture du processus 23
  • 24. Les 4 étapes de l'analyse des processus 1 - Élaborer le mandat de l'équipe Après avoir reçu de la direction les grandes lignes de la situation problématique, l'équipe de travail : • identifie les frontières du ou des processus à analyser • recueille les attentes des clients face aux résultats qui leur sont livrés • recueille les attentes des propriétaires du processus concernant la performance • élabore son mandat en précisant les résultats spécifiques du ou des nouveaux processus ainsi que les valeurs sur lesquelles elle s'appuiera tout au long du travail à accomplir. • Le mandat est présenté pour approbation au comité de direction et au gestionnaire concerné (généralement, les membres de l'équipe font la présentation). 24
  • 25. Les 4 étapes de l'analyse des processus 25 2 - Analyser le processus actuel • L'équipe recueille sur le terrain les informations nécessaires pour faire la cartographie du flux des processus étudiés (ordinogramme). • La cartographie est constamment validée par les gens du terrain afin de s'assurer qu'on décrit la situation actuelle et non ce qu'on souhaiterait avoir plus tard. • Ce travail permet par la suite de faire l'analyse de la valeur de chacune des étapes et d'établir par la même occasion une série de constats objectifs sur l'efficacité du processus analysé. • On effectuera souvent en parallèle à la cartographie une analyse financière sommaire basée sur les coûts d'obtention de la qualité des résultats produits par les processus actuels.
  • 26. Les 4 étapes de l'analyse des processus 26 2 - Analyser le processus actuel
  • 27. Les 4 étapes de l'analyse des processus 27 2 - Analyser le processus actuel La demande du collaborateur Le collaborateur enregistre sa demande de télétravail à partir de l’outil dédié (Téléflow) 1 Collaborateur du siège 3 La signature de l’avenant au contrat de travail Après accord du manager, le collaborateur fournit les pièces demandées par la DRH puis signe son avenant La décision du manager Le manager organise une réunion d’analyse de la demande avec le collaborateur et décide (accord / refus) 2 4 3 5 La récupération du matériel Le collaborateur récupère le matériel requis auprès de DOMS/IT Le démarrage du télétravail Le collaborateur installe le matériel à son domicile et télétravaille le moment venu
  • 28. Les 4 étapes de l'analyse des processus 28 3 – Baliser (ou benchmarker) • Les constats résultant de l'analyse permettent d'identifier des cibles de balisage. La direction est mise à contribution pour aider l'équipe à établir des contacts avec diverses entreprises. • Par la suite l'équipe planifie et organise son balisage en préparant une série de questions qui portent soit sur les façons de faire ou les façons de voir (concepts) des thèmes ciblés. • À son retour, l'équipe fait le bilan de ses découvertes et identifie les premières possibilités d'adaptation.
  • 29. Les 4 étapes de l'analyse des processus 29 4 - Élaborer la nouvelle architecture du processus • L'équipe précise le nouveau concept qui appuiera la nouvelle architecture du processus. • Ensuite, elle effectue une nouvelle cartographie en mettant l'accent sur la pertinence de chacune des activités ou étapes ainsi que sur la meilleure façon de l'exécuter. À titre indicatif, le nouveau processus devrait viser les barèmes suivants : • au moins 65 % d'activités à valeur ajoutée, • de 10 à 15 % d'activités de contrôle et de vérification, • de 10 à 15 % d'activités de décision • un maximum de 10 % de délai et de transport, • et aucune activité inutile.
  • 30. Les 4 étapes de l'analyse des processus 30 4 - Élaborer la nouvelle architecture du processus • Une fois la cartographie terminée, l'équipe identifie les impacts qu'aura la nouvelle architecture, particulièrement sur l'encadrement, les ressources humaines et la technologie. Elle précise également les gains et investissements requis. • De nombreuses consultations sont effectuées auprès des services de soutien pour valider ou raffiner certains éléments. • Puis l'équipe élabore une série de recommandations pour l'implantation éventuelle des nouveaux processus. • Enfin, elle présente le fruit de son travail à l'équipe de direction. • La direction aura à décider quelles recommandations seront retenues et implantées.
  • 31. Un exemple d’analyse de processus (Mouvement québécois de la Qualité) 31
  • 32. Un exemple d’analyse de processus 32 1 - Le mandat Une organisation dans le domaine des télécommunications au Québec veut revoir les façons de faire de ses équipes techniques. Après avoir compris le problème et les attentes de la direction, l'équipe propose que le nouveau processus permette entre autres de :  résoudre 100 % des problèmes ne nécessitant pas un déplacement lors de la prise d'appel  éliminer 80 % du papier  réduire les charges d'exploitation de 25 %
  • 33. Un exemple d’analyse de processus 33 2 - L'analyse des processus actuel Il s'est dégagé plusieurs constats de l'analyse des processus :  pas de calendrier de rendez-vous  surutilisation et surmanipulation de papier  qualité livrée non conforme aux attentes  pas de communication entre les secteurs.
  • 34. Un exemple d’analyse de processus 34 3 - Le balisage ou benchmarking Le balisage a pour but d'apprendre des autres. Les membres de l'équipe visitent 19 entreprises au Québec, au Canada et aux États-Unis. Leurs constatations :  utilisation de nouvelles technologies (terminaux à bord des véhicules)  organisation du travail basée sur le concept des équipes semi-autonomes  nouveau rôle du répartiteur.
  • 35. Un exemple d’analyse de processus 35 4 - Le redesign À partir d'un nouveau concept, l'équipe propose 12 transformations majeures sur trois axes :  le client  les employés  les opérations Gains prévus : 4.000.000 $ sur trois ans
  • 37. Définition d’un Workflow • Le WORKFLOW décrit  Les tâches à accomplir  Les acteur d’un processus  Le circuit et modes de validation  Les délais • Le Workflow fournit à chacun des acteurs les informations nécessaires pour la réalisation de sa tâche ! 37
  • 38. A quoi ça sert ? • Exemples de Workflow  un système de rédaction coopérative pour mettre sous Intranet la documentation professionnelle de l'entreprise • Les contributions, validations, approbations etc. parcourent un workflow qui automatise l'adressage et permet le contrôle des délais  un workflow pour la signature des conventions de partenariat • actuellement, ces conventions suivent des parcours compliqués et les délais de signature sont aléatoires 38
  • 39. A quoi ça sert ? • Exemples de Workflow  pour la préparation du budget informatique d'une grande entreprise,  un workflow permet de rassembler les descriptions de projets, synthétiser les demandes, préparer les arbitrages. Il implique les directions, le contrôle de gestion et la mission système d'information  Pour la gestion d’un service d'assistance téléphonique à la force de vente 39
  • 40. Les outils de modélisation • Le moteur de Workflow  Dispositif logiciel permettant d’exécuter une ou plusieurs définitions de Workflow  Par abus de langage on peut appeler ce dispositif logiciel « WORKFLOW » 40
  • 41. Les outils de modélisation : MERISE et UML Conduite de projet 41
  • 42. Les méthodes et diagrammes associés • Merise  Sépare les traitements des données  MCC (Modèle Conceptuel de Communication) • Méthodes associées à UML  Unified Modeling Langage  langage graphique basé sur des concepts OBJETS  Diagramme de Cas d’Utilisation 42
  • 43. MERISE - MEthode pour Rassembler les Idées Sans Effort Conduite de projet 43
  • 44. La méthode MERISE (Principes) • Création : en 1978-79 par Peter Chen et Hubert Tardieu à Aix en Provence • Signifie : MEthode pour Rassembler les Idées Sans Effort ou encore vient du merisier qui est un porte-greffe ! • But : Conception de Système d'Information (SI) par la modélisation Pour projets de toutes tailles 44
  • 45. La méthode MERISE (Principes) La méthode MERISE s'appuie sur 3 points : • Le cycle de vie (très variable selon les projets)  Gestation et Conception  Réalisation et Exploitation  Maintenance (évolution, adaptation, mort) • Le cycle de spécification (ou d'abstraction) du système d'information (SI)  Domaine des données : la mémorisation de l'information  Domaine des traitements : les processus de traitement de l'information • Le cycle de décision 45
  • 46. 46 Exemple d’un MCC Réalisation d’un Modèle Conceptuel de Communication (MCC)
  • 47. Exemple de MCC Une entreprise commerciale est constituée de trois services principaux : ventes, comptabilité et magasin. Pour chaque commande passée, le bon est transmis du service vente au service comptabilité qui envoie la facture au client (qui lui, renverra le règlement). Le service ventes enverra un bon de sortie au magasin pour le déstockage. Ce dernier envoie le bon de livraison et la commande au client. En ce qui concerne les stocks, c'est le magasin qui décide seul du réapprovisionnement auprès du fournisseur.
  • 48. Exemple de MCC On dénombre cinq acteurs : Client, Service ventes, Service comptabilité, Magasin et Fournisseur. On dénombre ensuite sept flux : (1) et (2) Bon de commande : (du client au service ventes et du service ventes au service comptabilité). (3) Facture : du service comptabilité au client. (4) Règlement : du client au service comptabilité. (5) Bon de sortie : du service ventes au magasin. (6) Bon de livraison+commande : du magasin vers le client. (7) Bon de commande fournisseur pour éventuel réapprovisionnement: du magasin vers le fournisseur.
  • 50. MERISE MCC - Modèle conceptuel de la communication Conduite de projet 50
  • 51. Merise : le niveau conceptuel • Le Modèle Conceptuel de Communication (MCC) définit les flux et les domaines  Inventaire des informations et données  Délimitation du système étudié • Le modèle Conceptuel de Traitement (MCT) décrit les règles et les contraintes générales du SI. • Le Modèle Conceptuel de Données (MCD) décrit l'organisation des données Cohérence du MCD / MCC et au MCT Validation par l'utilisateur 51
  • 52. Modèle conceptuel de communication (MCC) • N'existait pas dans les premières versions de MERISE • A été introduit en rapport avec les Use Case d'UML • Approche systémique : une entreprise est un système. L'entreprise échange avec l'extérieur, avec d'autres systèmes. Tout système interne ou externe est appelé INTERVENANT. • Tout système se décompose en sous systèmes fonctionnels ou INTERVENANTs. 52
  • 53. Modèle conceptuel de communication (MCC) 53 Le type DOMAINE est représenté par un grand ovale (ou patatoïde) regroupant le cas échéant des sous domaines (plus petits ovales). Dans chaque ovale on indique le nom du domaine. Le type MESSAGE est représenté par une flèche entre deux domaines et/ou intervenants avec le nom du message écrit au dessus de la flèche
  • 54. Modèle conceptuel de communication (MCC) 54 Un DOMAINE est un système ou sous-système qui a une mémoire et un SI. Un domaine est fonctionnel, il joue un rôle. Un domaine peut se décomposer en sous- domaines. Exemple : une entreprise (qui est un domaine) se compose des domaines Vendre, Produire, Gérer le personnel ; ses partenaires sont Client, Etat, …
  • 55. Modèle conceptuel de communication (MCC) • Pour une entreprise de livraison on pourra distinguer les Intervenants : LIVRER, FACTURER, ENCAISSER • Un PARTENAIRE est un intervenant extérieur à l'entreprise. • Exemples de partenaires FONCTIONNELs: CLIENT qui paye, FOURNISSEUR qui approvisionne, … • Un partenaire est PHYSIQUE s'il est vu fonctionnellement sous plusieurs facettes. • Exemple : EDF est à la fois un fournisseur et un client pour l'entreprise qui construit des transformateurs électriques. 55
  • 56. Modèle conceptuel de communication (MCC) • Définition  Un MCC détermine, par affinage successifs des activités, la composition du domaine d'étude sans en décrire le comportement. • Le MCC se construit par raffinement successif 56
  • 57. Modèle conceptuel de communication (MCC) • Définition :  Le MCC détermine le domaine d'étude et ses échanges avec l'environnement. • Concepts associés  Domaine d'étude  Acteurs externes  Domaines connexes  Message 57
  • 58. MCC : Les concepts associés • Domaine d'étude – Sous ensemble cohérent de l'entreprise ou de l'organisme, bien délimité et formant le contenu du sujet à étudier • Activité – Ensemble de traitements homogènes qui transforment ou manipulent des données • Message – Représentation d'un échange d'informations entre deux composants du système ou entre un composant du système et un système extérieur • Acteur externe – Source ou destination de données située en dehors du système étudié
  • 59. Gammes opératoires • Objectifs – Partitionner le domaine étudié en activités – Point de passage obligé pour modéliser les traitements – Maitriser la progression vers le détail du système • Niveau de détail – On s'arrête quand l'activité correspond à une opération. • Démarche – Identifier les flux de données entrant et sortant du domaine – Identifier les activités – Raffiner par conservation ou décomposition
  • 60. Définition de l'organisation • La première étape de ce modèle est d'arriver à isoler le système en le délimitant. Il s'agit donc de définir le système et les éléments externes avec lesquels il échange des flux d'information. Ces éléments extérieurs sont appelés acteurs externes (ou partenaires).
  • 61. Définition de l'organisation • La seconde étape consiste à découper l'organisation en entités appelées acteurs internes (ou domaines). Lorsque les domaines d'une organisation sont trop importants, ils peuvent être décomposés eux-mêmes en sous-domaines.
  • 62. Diagramme de contexte • Le diagramme de contexte a pour but de représenter les flux d'informations entre l'organisation et les acteurs externes selon une représentation standard dans laquelle chaque objet porte un nom : • l'organisation est représentée par un rectangle • les acteurs externes sont représentés par des ellipses en pointillés • les flux d'information sont représentés par des flèches dont l'orientation désigne le sens du flux d'information
  • 63. Diagramme conceptuel de flux • Ce diagramme (appelé aussi modèle conceptuel de la communication) permet de compléter le diagramme de contexte en décomposant l'organisation en une série d'acteurs internes. Dans ce diagramme la représentation standard est la suivante : • Les acteurs internes sont représentés par des ellipses • les messages internes sont représentés par des flèches
  • 64. MERISE MCC – Exemple de Modèle conceptuel de la communication Conduite de projet 64
  • 65. Exemple de MCC - Niveau 0 Assurance Assuré Déclaration de sinistre Niveau prise en charge Règlement sinistre Expert Garage Agréé Facture
  • 66. Exemple de MCC - Niveau 1 Sinistre Auto Compta Assuré Garage Agréé Expert Déclaration de sinistre Niveau prise en charge Facture Ordre de paiement Paiement
  • 67. 67 Travail en sous-groupe sur la réalisation d’un MCC Réalisation d’un Modèle Conceptuel de Communication (MCC)
  • 68. Exercice Merise MCC Voici la description du fonctionnement d'une société de services : Modélisation du système de gestion des affaires d'une société de service. Le Service Commercial est chargé d'examiner les études de demande client (cahier des charges). Si ceux-ci correspondent à l'activité de la société, le dossier est transmis à la Direction Technique qui élabore un devis estimatif. Celui-ci est complété au Service Commercial, édité et envoyé au client pour accord. Si le devis commercial est accepté par le client, le Service Commercial adresse une demande d'étude technique au Service Technique. Le Directeur Technique élabore des devis techniques qui correspondent à un découpage en lots du devis technique. Chaque devis est transmis à un Chef de Projet. Celui-ci procède à un nouveau découpage technique du devis et établit le planning de réalisation en affectant chacun des postes du devis technique à un Analyste Programmeur.
  • 69. Exercice Merise MCC Les Analystes Programmeurs établissent chaque jour un compte rendu d'activité. Chaque semaine, le Chef de Projet édite un rapport d'avancement et informe la Direction Technique de la situation des travaux en cours. Lorsqu'un poste du devis technique est réalisé, le chef de Projet transmet les programmes au client qui établit un procès verbal de réception. La recette est signalée au Service Comptable pour facturation. Chaque mois, une proposition de facture est établie par le Service Comptable et transmise à la Direction Technique pour être validée. Cette proposition correspond à l'ensemble des lignes du devis commercial non facturées. Les factures sont ensuite éditées et envoyées au client par le Service Comptable. Etablir le M.C.C. correspondant à l'organisation de cette société, en mettant en scène les acteurs suivants, et en prenant la société comme référentiel : Le Client. Le Service Commercial. La Direction Technique. Le Chef de Projet. L'Analyste Programmeur. Le Service Comptable.
  • 70. Analyse de Process et Workflow 70
  • 71. L’analyse logicielle avec UML (Unified Modeling Langage) Conduite de projet 71
  • 72. L’analyse logicielle avec UML Les différents types de diagrammes Tout comme la construction d’une maison nécessite des plans à différents niveaux (vision extérieure, plan des différents étages, plans techniques…), la réalisation d’une application informatique ou d’un ensemble d’applications est basée sur plusieurs diagrammes.
  • 73. L’analyse logicielle avec UML Les différents types de diagrammes Le langage UML est constitué de diagrammes. À ce jour, il existe 13 diagrammes « officiels ». Ces diagrammes sont tous réalisés à partir du besoin des utilisateurs et peuvent être regroupés selon les deux aspects suivants :
  • 74. L’analyse logicielle avec UML Les différents types de diagrammes Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi faire ? Comment les actions devront-elles se dérouler ? Quelles informations seront utilisées pour cela ? Les aspects liés à l’architecture : Quels seront les différents composants logiciels à utiliser (base de données, librairies, interfaces, etc.) ? Sur quel matériel chacun des composants sera installé ? UML modélise donc le système logiciel suivant ces deux modes de représentation.
  • 75. UML = Unified Modeling Langage • Nous allons donc dans un premier temps décrire ces différents aspects d’un logiciel grâce au schéma 4+1 vues et parcourir brièvement les différents diagrammes qui les composent
  • 76. La vue (4 + 1) • Vue des besoin utilisateurs – Cette vue (dont le nom exact est "vue des cas d'utilisation"), guide toutes les autres • Vue logique – Cette vue de haut niveau se concentre sur l’abstraction et l’encapsulation, elle modélise les éléments et mécanismes principaux du système • Vue des processus – Cette vue est très importante dans les environnements multitâches
  • 77. La vue (4 + 1) • Vue des composants – Cette vue de bas niveau (aussi appelée "vue de réalisation"), Identifie les modules qui réalisent (physiquement) les classes de la vue logique • Vue de déploiement – Cette vue très importante dans les environnements distribués, décrit les ressources matérielles et la répartition du logiciel dans ces ressources
  • 78. Vue des cas d’utilisation • Cette vue guide toutes les autres – A l'aide de scénarios et de cas d’utilisation, cette vue conduit à la définition d'un modèle d'architecture pertinent et cohérent – Elle définit les besoins des clients du système et centre la définition de l'architecture du système sur la satisfaction (la réalisation) de ces besoins – Cette vue est la "colle" qui unifie les quatre autres vues de l'architecture
  • 79. Diagrammes Dynamiques  diagramme de cas utilisation  diagramme de séquences  diagramme de collaborations  diagramme d‘états-transitions  diagramme d‘activité Statiques  diagramme de classes  diagramme d‘ objets  diagramme de composants  diagramme de déploiement
  • 80. 3 axes de modélisation Fonctionnel Statique Dynamique - Diagramme de Use Cases (diagramme d’activité) (diagramme de séquence) - Diagramme de Classe (diagramme d’objet) - Diagramme de composants (diagramme de déploiement) - Diagramme d’état (diagramme d’activité) (diagramme de séquence) - Diagramme de collaboration
  • 81. L’analyse logicielle avec UML (Zoom sur le Use Cases) Conduite de projet 81
  • 82. Cas d’utilisation • Ce diagramme décrit les situations auxquelles le système doit répondre. • Il permet d’établir les fonctionnalités nécessaires au bon fonctionnement d’un site internet, quels sont les différents acteurs et quelles relations existent entre eux – On se place du point de vue de l'utilisateur.
  • 83. Diagramme de cas d’utilisation • Il contient – des acteurs : ce sont des personnes ou systèmes extérieurs à l'application, et qui interagissent avec elle. – des cas d'utilisation : représentent une fonctionnalité (un objectif à atteindre) du système à construire. Ils sont en relation avec des acteurs et d'autres cas d'utilisation – des relations : elle sont généralement orientées – le système : représente l'application et les cas d'utilisation – Les packages : correspondent à des regroupements logiques
  • 84. Diagramme de cas d’utilisation
  • 85. Diagramme de cas d’utilisation Acteur : se représente sous la forme d’un petit personnage ou sous la forme de classe avec le mot clé <<acteur>> Note : se représente sous la forme de « papier plié » précisant certaines contraintes Cas d’utilisation : se représente sous la forme d’ellipse. Les cas d’utilisation peuvent être contenus dans un rectangle qui représente les limites du système Association : représente la relation entre un acteur et un cas d’utilisation, elle se schématise par un trait. <<Acteur>> Nom de l’acteur
  • 86. • Les relations entre cas d’utilisation – Relation de généralisation • Le cas d’utilisation enfant est une spécialisation du cas d’utilisation parent qui peut être abstrait. Cas d’utilisation Enfant Cas d’utilisation Parent Cas d’utilisation
  • 87. Cas d’utilisation • Les relations entre cas d’utilisation – Relation d’inclusion • Cette relation permet de décomposer les comportements et de définir des comportements partageables entre plusieurs cas d’utilisation. • Une instance du cas d ’utilisation source comprend le comportement décrit dans le cas d’utilisation destination. Cas d’utilisation Destination Cas d’utilisation Source <<inclus>>
  • 88. Cas d’utilisation • Les relations entre cas d’utilisation – Relation d’extension • Le cas d’utilisation source ajoute son comportement au cas d’utilisation destination. • Elle permet de modéliser des variantes de comportement d’un cas d’utilisation. <<étend>> Cas d’utilisation Destination Cas d’utilisation Source
  • 89. Cas d’utilisation • Exemple des différentes relations entre cas d’utilisation Virement Point d’extension : vérification supplémentaire après identification Client local Client distant Virement par internet Identification <<inclus>> Vérification solde compte <<étend>> si Montant > 100 €
  • 90. L’analyse logicielle avec UML (Le diagramme de séquence) Conduite de projet 90
  • 91. Diagramme de séquence • Le Diagramme de séquence présente un écoulement dans le temps. Il séquence les différents messages. • Ce diagramme montre les messages avec valeur et sans valeur qui sont échangés entre les différents acteurs. • La notion de temps est importante elle permet de temporiser et d’ordonner les messages.
  • 92. Diagramme de séquence Système Porteur de CB SA Visa/Mastercard Introduction carte Demande de code secret Code (valeur) Demande autorisation Autorisation (solde) Demande montant retrait Retrait (valeur) Demande ticket OK éjection carte Récupérer carte Éjection billets + ticket Récupération billets + ticket Axedutemps Vérification carte Vérification code Voir A2 et B4 code erroné Contrôle montant Voir A6 ticket refusé
  • 93. L’analyse logicielle avec UML (Les diagrammes) Conduite de projet 93
  • 94. Les diagrammes UML • Voici quelques exemples de diagramme qui peuvent être utilisés dans une démarche d’analyse et de conception d’un logiciel. Ne vous inquiétiez pas du nombre de diagrammes ci-dessous. Il s’agit ici simplement de vous familiariser à ces diagrammes. • L’objectif est d’avancer pas à pas dans l’analyse des besoins initiaux des utilisateurs, afin de travailler plus particulièrement les 4 diagrammes suivants : 1. le diagramme de contexte. Ce diagramme n’est pas officiellement désigné comme diagramme UML. Il ne fait donc pas partie des 13 diagrammes « officiels », mais il est utile pour la définition des acteurs, avant de commencer à s’intéresser à d’autres aspects, tels que les packages et les cas d’utilisation. 2. le diagramme de package 3. le diagramme de cas d’utilisation 4. le diagramme d’activité.
  • 95. Les besoins des utilisateurs (1) • Cette partie représente le cœur de l’analyse. Il est composé de cas d’utilisation (que nous verrons plus tard). On y décrit le contexte, les acteurs ou utilisateurs du projet logiciel, les fonctionnalités du logiciel mais aussi les interactions entre ces acteurs et ces fonctionnalités. C’est d’ailleurs aussi le cœur de notre cours. • Le besoin des utilisateurs peut être décrit à l’aide de deux diagrammes.
  • 96. Les besoins des utilisateurs (1) • Le diagramme de packages permet de décomposer le système en catégories ou parties plus facilement observables, appelés « packages ». Cela permet également d’indiquer les acteurs qui interviennent dans chacun des packages.
  • 97. Les besoins des utilisateurs (1) • Dans l’exemple précédent, nous voyons que le logiciel que nous concevons peut être divisé en trois parties (ou packages) observables séparément : • La gestion des commandes client • La gestion des stocks • La gestion des achats • • La boîte qui entoure les packages (la boîte bleue) correspond au système (c’est-à-dire le logiciel) qui est analysé.
  • 98. Les besoins des utilisateurs (1) • Le diagramme de cas d’utilisation représente les fonctionnalités (ou dit cas d’utilisation) nécessaires aux utilisateurs. On peut faire un diagramme de cas d’utilisation pour le logiciel entier ou pour chaque package. Étant donné que le diagramme de cas d’utilisation détaille le contenu d’un package, ici la boîte bleue correspond au package qui est détaillé.
  • 99. Vue logique (2) • La vue logique a pour but d’identifier les éléments du domaine, les relations et interactions entre ces éléments. Cette vue organise les éléments du domaine en « catégories ». Deux diagrammes peuvent être utilisés pour cette vue.
  • 100. Vue logique (2) • Le diagramme de classes • Dans la phase d’analyse, ce diagramme représente les entités (des informations) manipulées par les utilisateurs. Dans la phase de conception, il représente la structure objet d’un développement orienté objet.
  • 101. Vue logique (2) • Le diagramme d’objets sert à illustrer les classes complexes en utilisant des exemples d’instances. Une instance est un exemple concret de contenu d’une classe. En illustrant une partie des classes avec des exemples (grâce à un diagramme d’objets), on arrive à voir un peu plus clairement les liens nécessaires
  • 102. Vue des processus (3) • La vue des processus démontre : • la décomposition du système en processus et actions ; • les interactions entre les processus ; • la synchronisation et la communication des activités parallèles. • La vue des processus s’appuie sur plusieurs diagrammes.
  • 103. Vue des processus (3) • Le diagramme de séquence permet de décrire les différents scénarios d’utilisation du système.
  • 104. Vue des processus (3) • Le diagramme d’activité représente le déroulement des actions, sans utiliser les objets. En phase d’analyse, il est utilisé pour consolider les spécifications d’un cas d’utilisation.
  • 105. Vue des processus (3) • Le diagramme de collaboration (appelé également diagramme de communication) permet de mettre en évidence les échanges de messages entre objets. Cela nous aide à voir clair dans les actions qui sont nécessaires pour produire ces échanges de messages. Et donc de compléter, si besoin, les diagrammes de séquence et de classes.
  • 106. Vue des processus (3) • Le diagramme d’état-transition permet de décrire le cycle de vie des objets d’une classe
  • 107. Vue des processus (3) • Le diagramme global d’interaction permet de donner une vue d’ensemble des interactions du système. Il est réalisé avec le même graphisme que le diagramme d’activité. Chaque élément du diagramme peut ensuite être détaillé à l’aide d’un diagramme de séquence ou d’un diagramme d’activité.
  • 108. Vue des processus (3) • Le diagramme de temps est destiné à l’analyse et la conception de systèmes ayant des contraintes temps-réel. Il s’agit là de décrire les interactions entre objets avec des contraintes temporelles fortes.
  • 109. L’aspect lié à l’architecture du logiciel • Pour rappel, cette partie du schéma 4+1 vue permet de définir les composantes à utiliser (exécutables, interfaces, base de données, librairies de fonctions, etc.) et les matériels sur lesquels les composants seront déployés.
  • 110. Vue des composants (4) • La vue des composants (vue de réalisation) met en évidence les différentes parties qui composeront le futur système (fichiers sources, bibliothèques, bases de données, exécutables, etc.). • Cette vue comprend deux diagrammes :
  • 111. Vue des composants (4) • Le diagramme de structure composite décrit un objet complexe lors de son exécution.
  • 112. Vue des composants (4) • Le diagramme de composants décrit tous les composants utiles à l’exécution du système (applications, librairies, instances de base de données, exécutables, etc.).
  • 113. Vue de déploiement (5) • La vue de déploiement décrit les ressources matérielles et la répartition des parties du logiciel sur ces éléments. Il contient un diagramme : • Le diagramme de déploiement correspond à la description de l’environnement d’exécution du système (matériel, réseau…) et de la façon dont les composants y sont installés.
  • 115. En synthèse • UML est constitué de 13 diagrammes qui représentent chacun un concept du système ou logiciel. • Un logiciel peut être vu en considérant les aspects fonctionnels et les aspects d’architecture du logiciel. Ces deux aspects sont composés de 4 vues du logiciel à développer, organisés autour des besoins des utilisateurs. C’est le 4+1 vues. • Chacune des 4+1 vues est constituée de diagrammes.
  • 116. Merci de votre attention 116