Enterprise Evaluation – Séparer l’analyse de la conception
Séparer l’analyse de la conception
(décidez ce qui est nécessaire avant de décider remark l’implémenter)
Les projets réussis résolvent les problèmes de l’entreprise
Examiner les objectifs commerciaux que vous essayez de satisfaire avant de vous lancer dans la technologie vous permet d’utiliser la technologie à bon escient, de gérer la portée et de réduire les coûts, en produisant des systèmes qui fonctionnent pour vos purchasers.
Il est facile de se concentrer sur les caractéristiques strategies d’un projet et de perdre de vue la raison de son existence. Chaque projet existe pour résoudre un problème. Soit ce que vous avez ne fonctionne pas assez bien et doit être amélioré, soit vous devez inventer quelque selected de totalement nouveau. Après tout, “Si ce n’est pas cassé, ne le répare pas.”
Trop souvent, les pressions des délais et des budgets nous amènent à contourner l’necessary processus d’analyse des besoins de l’entreprise, et nous sautons directement dans la technologie. Mais combien de fois constatons-nous que le système ne fait pas exactement ce qu’il faut. Les utilisateurs sont obligés d’utiliser des options de contournement, réduisant certains des avantages que nous étions censés fournir, ce qui affecte également notre crédibilité. Combien de fois devons-nous investir du temps et des dépenses supplémentaires pour fournir la model 2 (et 3 et 4 et …), alors qu’un travail minutieux aurait pu révéler les besoins réels plus tôt ?
Le cycle de vie classique de la cascade
Il existe de nombreuses variantes du cycle de vie du développement du système (SDLC) et ce qui go well with peut ne pas être exactement la terminologie utilisée par votre méthodologie. Le contenu des phases est certes simplifié dans ce tableau, mais les projets suivent les phases suivantes :
(IMAGE NON DISPONIBLE ICI – vous pouvez télécharger ce doc complet avec des illustrations de [http://www.irm.com.au/businessanalysispapers.htm]ou voir l’picture sur [http://www.irm.com.au/images/waterfallcycle.jpg])
La sortie de chaque section est l’entrée de la suivante. Déchets à l’intérieur, déchets à l’extérieur. Ou pour le dire un peu plus élégamment, vous ne pouvez pas faire un sac à essential en soie à partir de l’oreille d’une truie. Vous ne pouvez pas implémenter un bon système opérationnel sans un bon système testé, vous ne pouvez pas construire un bon système sans de bonnes spécifications strategies et vous ne pouvez pas concevoir un bon système sans une bonne spécification métier.
Assurez-vous que des personnes talentueuses sont utilisées au début de votre projet, pour vous assurer que vous pouvez obtenir un bon résultat à la fin.
Ne vous trompez pas en pensant que vous rendez service à quelqu’un en contournant l’analyse commerciale et en passant directement à la conception, ou en combinant les deux. Si le délai est serré, négociez une mise en œuvre progressive. Si le price range est serré, supprimez certaines fonctionnalités.
De nombreuses enquêtes, y compris les travaux de Boehm, ont montré de manière constante que l’augmentation du coût de la réparation des erreurs augmente de façon exponentielle plus tard la réparation a lieu dans le SDLC. Une erreur qui coûte un greenback à réparer pendant la section d’initiation coûtera 10 $ si elle est laissée jusqu’à l’analyse, 100 $ à la conception et 1 000 $ si rien n’est fait jusqu’à la mise en œuvre. Pourtant, combien de fois disons-nous « Nous pourrons corriger cela dans le code » ?
Les outils logiciels ne peuvent pas penser à votre place
Shakespeare aurait-il été un meilleur écrivain s’il avait eu un traitement de texte ?
N’importe quel outil croira ce que vous lui dites. Il existe des outils formidables qui élimineront le travail de piratage insensé de votre travail afin que vous puissiez vous concentrer sur ce que vous faites le mieux. Mais ne pensez pas que si vous avez le meilleur outil doable, vos systèmes seront les meilleurs possibles. Si vous ne me croyez pas, prenez votre traitement de texte préféré et écrivez un sonnet que les gens seront ravis de citer dans 400 ans.
Vous devez encore faire votre propre réflexion. C’est à cela que sert l’analyse commerciale.
Séparer l’analyse commerciale de la conception method
L’analyse commerciale consiste à réfléchir à ce que votre answer doit faire, tandis que la conception consiste à déterminer remark y parvenir en utilisant la technologie disponible. En gardant cela à l’esprit, il sera plus facile d’éviter de mélanger ces deux phases. Quoi et Remark. Cela vous aidera à construire des systèmes plus robustes.
Ce que fait votre entreprise ne change pas autant que la façon dont elle est réalisée. La technologie évolue plus rapidement que les besoins des entreprises. Les entreprises se restructurent. Mais ce qu’ils font n’a pas changé, juste quel individu le fait. L’analyse métier donne une vue logique des besoins en matière de processus et de données et n’est pas liée par la mise en œuvre physique.
Les informaticiens et utilisateurs métiers se plaignent régulièrement de leurs incompréhensions. Bien sûr, ils ne se comprennent pas. Les techniciens sont soucieux de tirer le meilleur parti de leur technologie, les utilisateurs sont soucieux d’atteindre leurs objectifs commerciaux. L’analyse commerciale devrait parfaitement combler l’écart.
Les termes de référence produits au cours de la section d’initiation doivent inclure, sans ambiguïté, le problème à résoudre, l’objectif à atteindre pour résoudre ce problème, les contraintes et la portée.
L’analyse commerciale a pour however de :
Strategies d’analyse d’entreprise
Afin de creuser sous les problèmes et de trouver des options, de nombreuses strategies sont utilisées qui sortent du cadre de cet article. Ils comprennent des entretiens soigneusement structurés, la collecte de paperwork, le remue-méninges, l’analyse des risques, l’analyse coûts-avantages et bien d’autres.
Outils d’analyse d’entreprise
Seuls quatre outils sont nécessaires pour l’analyse : deux pour les processus et deux pour les données.
Pour les processus, le diagramme de flux de données (DFD) montre les processus métier d’un système et leurs connexions les uns aux autres, tandis que les spécifications métier montrent les règles métier pour chaque processus. Pour les données, le diagramme entité-relation (diagramme ER) montre les éléments qui doivent être stockés d’un level de vue business, et le dictionnaire de données détaille les éléments spécifiques (champs) nécessaires pour chaque entité et leurs connexions aux flux de données sur le DFD.
L’objectif de cet article n’est pas de montrer remark construire ces modèles, mais de démontrer l’significance de leur utilisation dans un modèle métier plutôt que dans un modèle method.
N’importe quel fool peut dessiner un diagramme ER
C’est vrai, mais la qualité du modèle obtenu laisse souvent à désirer. Reflétez les besoins de l’entreprise dans le modèle et ne laissez rien au hasard. Soyez prudent avec des éléments tels que les relations obligatoires et facultatives et les éléments de données, automobile votre système remaining doit répondre à 100 % des besoins de l’entreprise, et non aux événements les plus probables. N’essayez jamais de combiner la documentation des besoins en données d’entreprise avec une conception de base de données.
Si le modèle business est précis, la conception sera facile à produire et pourra être facilement modifiée à la lumière des exigences commerciales et des nouvelles applied sciences.
Pourquoi un diagramme de flux de données est meilleur qu’une hiérarchie de fonctions
Une hiérarchie de fonctions affiche les principales fonctions d’un système et les détaille, mais ne montre rien des exigences en matière de données pour ces processus. Il est très facile d’omettre par inadvertance des processus de niveau inférieur. Une hiérarchie de fonctions n’est pas immédiatement évidente pour un utilisateur qui doit revérifier l’exactitude de votre modèle.
Un diagramme de flux de données montre de la même manière les principales fonctions et les détails, mais comme les flux de données agissent comme le « colle » qui maintient les processus ensemble, il est easy de construire un tel diagramme en collaboration avec un représentant de l’entreprise. « De quelles informations avez-vous besoin pour effectuer ce processus ? D’où est ce que ça vient? Quelles informations sont produites ? Où va-t-il ? De cette façon, les processus individuels peuvent être progressivement ajoutés au modèle et rien ne sera manqué. Les processus complexes peuvent être détaillés et les processus associés peuvent être regroupés.
Un diagramme de flux de données volumineux est difficile à lire et difficile à maintenir, il perd donc son efficacité en tant qu’outil de communication avec les utilisateurs métier et l’équipe method. Au lieu de cela, ayez environ sept processus par diagramme et accédez à des diagrammes plus détaillés, avec un système de numérotation pour les références croisées. Par exemple, les détails du processus 3 seront numérotés 3.1, 3.2, 3.3, and many others. et apparaîtront sur le diagramme numéro 3. Ensuite, les diagrammes de haut niveau peuvent être utilisés pour la dialogue avec la route et les diagrammes de niveau inférieur peuvent être utilisés pour une double vérification détaillée. avec des utilisateurs specialists dans ce domaine. La hiérarchie des fonctions existe désormais automatiquement. Il n’est pas nécessaire de le dessiner séparément.
De nombreux analystes préfèrent utiliser un modèle de processus qui comprend des « couloirs de nage » pour identifier qui exécute chaque processus. Il s’agit simplement d’un diagramme de flux de données dans un format différent. C’est bien de commencer l’analyse à l’aide d’un tel diagramme, mais à la fin de l’analyse, les couloirs de nage devraient avoir disparu, automobile votre modèle devrait être suffisamment résistant pour survivre aux restructurations de l’entreprise. Vous documentez ce qui doit être fait, pas qui le fait ni remark.
Les dataflows doivent être spécifiés avec leur contenu détaillé dans le dictionnaire de données, tout comme les datastores. Progressivement, le diagramme de flux de données aidera à construire le modèle de données afin que vos définitions de données prennent en cost les processus.
Incluez tous les processus dans le diagramme de flux de données, même ceux qui semblent triviaux. J’ai récemment entendu parler d’un projet qui est tombé dans le piège du « reporter, c’est facile, on va laisser ça jusqu’à la fin ». Au second de la building, les données requises pour les rapports se sont avérées inaccessibles.
Plusieurs variations du modèle
Documentez d’abord le système existant, y compris tous ses défauts, sans aucune amélioration ajoutée. La trigger des problèmes est là quelque half et vous ne devriez pas sauter aux conclusions sur la meilleure façon de le résoudre.
Supprimez le remark du modèle physique actuel, donnant un modèle logique actuel. Ensuite, déterminez la meilleure façon de résoudre les problèmes et incluez de nouvelles exigences. Cela donne le nouveau modèle logique, prêt pour la conception.
Dans certains cas, les problèmes peuvent être résolus en réorganisant simplement les pratiques de travail, ce qui permet d’économiser des dépenses inutiles en matière de conception. Est-ce que cela met l’équipe method au chômage ? Pas du tout. Ils peuvent être libérés pour utiliser leur experience là où elle fera le plus de différence sur d’autres projets.
Rédaction de la spécification
N’écrivez pas une seule grande spécification. Ce sera fake, automobile vous manquerez certains détails et ne pourrez pas le modifier facilement. Et personne ne pourra mémoriser le tout. Au lieu de cela, rédigez une seule spécification pour chaque processus détaillé – une “mini-spécification”. Chacun peut être revérifié avec l’professional business approprié. La assortment de toutes ces mini-spécifications est votre spécification pour l’ensemble du système. Chacun est individuellement facile à entretenir sans affecter le reste de la spécification.
Les spécifications ne doivent inclure aucune data method – simplement les règles commerciales de ce processus. L’équipe de conception peut déterminer la meilleure façon d’y parvenir.
Quoi automatiser ?
L’examen des diagrammes de flux de données avec les représentants commerciaux et l’équipe method vous permettra de décider de la meilleure implémentation. Ceci est basé sur des facteurs tels que ce qui est acceptable pour l’entreprise, ce qui est techniquement doable, ce qui correspond aux contraintes de price range et de temps.
Vous pouvez opter pour une automatisation complète, une automatisation partielle, une mise en œuvre progressive ou une autre excellente idée. Passez ensuite la essential à l’équipe de conception.
Allier analyse et conception
Ne le faites jamais. Vous n’économisez rien.
evaluation
articles