Business Analysis Introduction Mise en situation 2 https://www.youtube.com/watc

Business Analysis Introduction Mise en situation 2 https://www.youtube.com/watch?v=BKorP55Aqvg Plan du cours 1. Introduction a. Qu’est-ce qu’un Business Analyst ? b. Qu’est-ce qu’une Exigence ? 2. Pre-Study 3. Domain Understanding 4. Requirement Analysis 3 Qu’est-ce qu’un Business Analyst ? 4 Définition 5 Business Analyst - Définition Les Business Analysts (ou analystes d’affaires, ou BA) sont chargés d'analyser les besoins de leurs clients d'affaires. ● Fonction de liaison entre le côté affaires de l'entreprise et les prestataires de services internes et externes. ● Chargé d’étudier et d’analyser le domaine d’affaire ● Proposer une solution ou des recommandations ○ Pas nécessairement technologique. ○ La solution proposée est souvent une optimisation du processus d'affaires existant afin d'éliminer ou de réduire les activités sans valeur ajoutée, ce qui peut engendrer une augmentation de la performance ou une réduction des coûts associés. 6 Rôle du Business Analyst Le BA peut être impliqué dans différentes situations ● Lors de la création d’un nouveau produit. ● Lors de l’amélioration d’un produit actuel. ● Pour aider à résoudre un problème en comprenant la situation et en proposant une solution. ● Pour aider les membres de l'équipe de projet à mieux comprendre les besoins du client. 7 Rôle du Business Analyst L'analyste intervient à différents moments dans la vie du projet. ● Au début d'un projet (compréhension) ○ Pour documenter les processus d'affaires du client. ○ Pour identifier les possibilités d'amélioration. ○ Pour préparer les mandats des projets. ○ Pour aider le management à déterminer quels sont les projets à mettre de l'avant. ○ Pour identifier et documenter les orientations stratégiques et le scope du projet. ○ Pour collecter les besoins des parties prenantes. ○ Pour estimer l'impact du projet sur l'organisation. ● Pendant le projet (aider) ○ Pour aider à atteindre les objectifs fixés. ○ Pour aider l’entreprise à gérer le changement. 8 Rôle du Business Analyst Il peut également ● Intervenir dans / dirigé / effectuer l'analyse des besoins. ● Cerner les contraintes d'affaires. Ces connaissances et cette compréhension sont ensuite transférées aux différentes équipes de développement afin qu’ils comprennent les concepts du domaine et les besoins des utilisateurs. 9 Rôle du Business Analyst Ce rôle varie en fonction de différents facteurs : 1. Le type d'industrie. 2. La taille de l'organisation. 3. Le cycle de vie du projet. 4. La méthodologie (waterfall, agile, etc.). 5. La maturité de l'organisation en termes de pratiques de gestion de projet et d'analyse commerciale. 10 Business Analyst - Limites Souvent confondu avec le chef de projet et l'analyste fonctionnel ● Son travail s'arrête à la limite de l'analyste fonctionnel. ○ Qui doit lui proposer des solutions informatiques en vue du développement. ● Il arrive parfois qu'une même personne jouent les deux rôles. ● Très important de distinguer les besoins du client de la solution ○ La solution peut être changée par l'équipe technique. ○ Le besoin est de la responsabilité du client. 11 Analyses des besoins Toutes analyses passent par 4 phases : 1. Identifier le problème ○ Identifier le problème qui doit être résolu ou l’amélioration qui doit être réaliser. 2. Évaluer l’état actuel ○ Comprendre quels sont les facteurs qui causent le problème. 3. Identifier l’état désiré ○ Identifier avec le client qu’elle est l’état désiré. 4. Comprendre le gap ○ Identifier les éléments manquants pour arriver à la solution. 12 Analyses des besoins 13 Comprendre et définir la situation actuelle Définir la situation future espérée Définir l'écart entre les deux situations Proposer des solutions ou des recommandations Le Problème L'analyste intervient dans l’optimisation de problèmes structurés ou dans la résolution de problèmes non-structurés ● Problème structuré ○ Le problème ainsi que ses causes sont clairement identifiés ○ Les routines pour résoudre le problème sont comprises ○ Des experts savent quelles routines appliquer ● Problème non-structuré ○ Le problème n’est pas bien assimilé: le business constate des effets négatifs, mais comprend mal la chaîne causale qui mène à cet état ○ Les routines pour résoudre le problème sont inexistantes ○ Des experts doivent intervenir pour comprendre le problème, et créer de nouvelles solutions! 14 Combinaison avec d’autres rôles Les analystes d'entreprise peuvent se chevaucher dans des rôles tels que chef de projet ou consultant. Un BA ne fonctionne pas toujours dans des projets liés à l’IT, puisque les compétences de BA sont souvent nécessaires dans des rôles de marketing et financiers. 15 Pré-requis du Business Analyst Il n'y a pas de manière unique et définie pour devenir analyste. 1. Souvent, le BA a une formation technique. ○ Expérience en tant que programmeur ou ingénieur. ○ Diplôme en informatique. ○ Formation en gestion de l’information. 2. Possibilité d’atteindre un rôle de BA à partir d'un rôle d'entreprise. ○ Statut d’expert en la matière + compétences analytiques = Bon BA. 3. Formations spécifiques au métier d'analyste d’affaire. 16 Chaos Report 2015 17 Quelles sont les chances de réussites d’un projet ? Quelles sont les chances et les facteurs de réussites d’un projet ? Pour comprendre le taux de réussite des projets on va se baser sur le Chaos Report de 2015. https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf 18 Taux de succès 19 Respect des contraintes 20 La taille du projet 21 Par industrie 22 Par région du monde 23 Par complexité 24 Par méthodologie 25 LES MÉTHODOLOGIES 26 Méthode de développement Qu'est ce qu'une méthode de développement ? Cadre établi afin de 1. structurer 2. planifier 3. contrôler le processus de développement d'un système d'information. 27 Les disciplines du développement de software 1. Analyse des exigences ○ Comprendre les besoins du client 2. Conception (Design) ○ Définir la solution technique 3. Développement ○ Implémenter la solution 4. Validation (Testing) ○ S’assurer que la solution répond adéquatement aux besoins 5. Déploiement ○ Intégration globale et mise en production 6. Maintenance 28 Différentes méthodologies Les différences entre différentes méthodologies de développement résident essentiellement dans : 1. L'importance donnée à chaque activité. 2. La séquence permise entre chaque activité. Large variété de méthodologie: en cascade, en spirale, incrémentale, agile... 29 Méthode en cascade (“waterfall”) Le cycle en “cascade” se caractérise par des phases séquentielles, qui se succèdent après la validation des livrables produits lors de la phase précédente. 30 Méthode en cascade (“waterfall”) 1. Les besoins sont exprimés et recueillis dans une analyse détaillée. 2. La conception du système qui répondra aux besoins exprimés dans l’analyse. ○ Textuelle ou sous forme de diagrammes. ○ Doit être validée avant le démarrage des développements. 3. Le développement. ○ Doit être achevés pour permettre à l’équipe de testeurs de lancer les tests fonctionnels et techniques. 4. Les tests. 5. Mise en production après que les anomalies aient été corrigées. 31 Méthode en cascade (“waterfall”) Dans ce contexte, et sur la base du périmètre défini, on demande au chef de projet de s’engager sur un planning détaillé de réalisation, prévoyant les jalons de début et fin de phases, et les activités à mener. 32 Réflexion 1. Quels sont les avantages et les inconvénients d'une telle méthode? 2. Quels sont les critères favorable / défavorable pour cette méthode? 33 Avantages 1. Le temps alloué dans les premières phases des projets permet d'atteindre des économies d'échelle. 2. La documentation est aussi importante que le code. Cela permet de pérenniser la connaissance au sein du projet. 3. Approche simple, disciplinée et facile à comprendre. 34 Inconvénients 1. La rigidité de l’approche prédictive. ○ La préoccupation majeure du chef de projet devient alors de coller au plus près au plan. ○ Tout retard ou imprévu est perçu comme échec, incompétence. 2. L’effet tunnel ou "black box". ○ La marge de manœuvre laissée au client pour préciser ou faire évoluer ses attentes est quasi inexistante. 3. Une mauvaise communication. 4. La levée tardive des facteurs à risques. 5. Une documentation pléthorique. 35 Exigences pour la méthode en cascade 1. L'environnement et les exigences sont stables. 2. La technologie est bien connue et mature. 3. Il n'y a rien de nouveau ou d'inconnu dans le projet (prévisibilité). 4. (De nombreux projets semblables ont déjà été exécutés avant). 36 Qui utilise ce genre de méthode? ● Institutionnel ● Banque/Assurance ● Aéronautique ● …. 37 Réflexion Comment pourrait-on modifier le processus waterfall afin de l’améliorer ? 38 Empirisme Agile est fondé sur l’Empirisme. ● La connaissance provient exclusivement de l'expérience. ● On prend des décisions en fonction de ce que l'on sait pas sur ce que l’on croit savoir. ● Agile propose une approche itérative et incrémentale pour optimiser la prévisibilité et contrôler les risques. 39 Incrémentation et itération Incrémentation Le développement va être découpé en plusieurs parties. Chacun des développements vient enrichir l’existant. Un incrément est donc une avancée dans le processus de développement. Itération A chaque itération, les parties prenantes ont l'occasion de faire des commentaires sur l’augmentation la plus récente, ainsi que sur le produit dans son ensemble. Ce retour sera incorporé dans la version suivante. 40 Avantages du développement itératif 1. La communication est de meilleure qualité. ○ L’utilisateur a la possibilité de clarifier ses exigences au fur et à mesure. ○ Malentendus, incompréhensions, incohérences sont mis uploads/Industriel/ ba-1-introduction.pdf

  • 14
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager