"Sans une feuille de route, vous pourriez être conduite dans les milieux."
- Bryce's Law
INTRODUCTION
Okay, vous avez lancer votre débogueur de programme et les contrôles à répétition tout très bien. Mais pour une raison inconnue, l'ensemble du système est inutilisable. Le logiciel et la conception de base de données semble parfait, mais vous allez Stark Raving-fou pour essayer de localiser le problème. Avez-vous pensé qu'il pourrait ne pas être un défaut dans la conception des logiciels ou des données de base à tous? C'est peut-être le problème réside dans l'architecture globale du système, ou peut-être son juste vous?
Dans de nombreux cas, le diagnostic d'un problème est plus douloureux que de la corriger. Considérant que j'ai passé en revue les principes de base d'essai dans le passé, voir;
N ° 41 - "Test 1, 2, 3 ..." - 12 septembre 2005
http://www.phmainstreet.com/mba/ss050912.pdf
Ici, je veux discuter de quelques conseils pour diagnostiquer les problèmes.
Trois conseils
1. Promenade à travers le système et vérifier les interfaces homme / machine.
Il ya des années, nous avons été contractée par une grande entreprise manufacturière dans le nord qui avait du mal à mettre en œuvre son nouveau système de contrôle de l'atelier. Le système a été l'état de l'art en termes de programmation et de la technologie SGBD. Mais ils ne pouvaient tout simplement pas le faire fonctionner, peu importe ce qu'ils ont essayé. Frustré, l'entreprise a embauché nous pour voir si nous pouvions trouver le problème. Au lieu d'étudier le code source, comme l'équipe de développement avait fait, nous avons commencé par la cartographie de l'architecture globale du système.
J'ai décrit la «fierté» Standard System Concept Structure sur plus d'une fois, mais en un mot, un système peut être établi comme une hiérarchie à quatre niveaux qui représente une structure de produit. Considérant que la structure du produit se compose de quatre niveaux de la représentation des produits, des assemblages, des sous-ensembles, et les opérations, "Pride" se décompose également le système en:
NIVEAU 1 - SYSTEME
NIVEAU 2 - Sous-système (processus d'affaires)
Niveau 3 - Procédures (administratif et informatique)
Niveau 4 - des mesures opérationnelles (pour les procédures administratives) et des programmes (pour les procédures informatiques)
Cette approche universellement applicables pour définir l'architecture du système permet une feuille de route pratique pour marcher dans tous les aspects du système et la validation de son intégrité. diagrammes de cette hiérarchie peut être produite à partir de dépôts IRM ou de certains outils graphique simple. Dans notre mission de conseil bien, nous nous contentons de l'esquisser à l'aide de papier et un crayon. Fondamentalement, nous nous sommes promenés à travers le système, l'échantillon de travail et avait regardé pour les interfaces homme / machine. Inévitablement, nous sommes tombés sur un sous-système dans lequel l'ordinateur affichait des erreurs dans la boutique-de-chaussée nécessitant une attention par le contremaître. Le contremaître a été de prendre les mesures correctives et de répondre à l'ordinateur. Il y avait un seul problème avec ceci: personne ne l'avait dit le contremaître de tout cela. Nous avons ensuite écrit une simple procédure administrative pour le contremaître qui a pris les mesures nécessaires et le système fonctionne correctement par la suite («miraculeusement», comme dit notre client).
Cela soulève un point important: les systèmes échouent plus de l'absence de procédures administratives que pour bien programmé des procédures informatiques. Bien que l'entreprise de fabrication avait produit un logiciel assez élégant, ils avaient complètement oublié l'interface homme / machine. Encore une fois, la «fierté» du Système normalisé concept de structure avaient fourni le nécessaire
Feuille de route, mais parce que le client n'a pas apprécié la nécessité d'un tel top-down Bleus technique, ils n'avaient aucune idée où tout était.
2. Travailler à rebours.
Lorsque le diagnostic de processus d'affaires, procédures et programmes, il existe une tendance naturelle à aller du début à la fin de diagnostiquer un problème. Parfois vous pouvez trouver un hoquet en utilisant cette approche, d'autres fois vous ne pouvez pas. Au lieu de cela, essayer de travailler vers l'arrière de la fin pour commencer, de sortie et son entrée. Encore une fois, la carte de la conception à l'aide d'un organigramme ou une autre technique graphique. Si le traitement implique des décisions importantes, dessiner un arbre de décision ou de la table. Ces graphiques sont très précieux pour la validation
logique de conception.
3. Avoir une deuxième paire de yeux regarder par-dessus votre travail.
Comme nous l'avons s'imprégner dans la mécanique d'un dessin, trop souvent, l'évidence est moins évident pour nous. Ici, une autre paire d'yeux peut facilement voir un problème que nous avons négligé. Ceci est particulièrement avantageux dans les magasins de fonctionnement en conformité avec les normes de conception de certains. pratiques de conception uniforme rend
qu'il soit plus facile de déceler les anomalies que sans de telles normes.
Lorsque la deuxième personne vient est également important. Si la personne vient de votre groupe de travail et vous familiariser avec votre style de design, il peut très bien être en mesure de déceler un problème. Et puis, peut-être pas. Peut-être que le problème sera invisible pour eux aussi. Dans ce cas, vous pouvez consulter un neutre
troisième personne avec un regard neuf sur le problème. Il peut s'agir d'une personne au sein de la société ou, éventuellement, un consultant extérieur.
CONCLUSION
aides graphiques, tels que des organigrammes et des diagrammes, sont utiles pour diagnostiquer un problème, mais me souviens aussi de contester le graphique. Ce n'est pas rare que les graphismes ne pas correspondre à ce qui se passe en fait. Un bon référentiel IRM est également précieux pour étayer dessins. La conception est soit correctement enregistré
dans le référentiel IRM ou n'est pas. En outre, un tel outil fournit les moyens d'étudier la relation entre les ressources d'information (alias "l'analyse d'impact»), qui peut révéler des éléments inconnus à un dessin.
Plus important encore, l'idée de maintenir une architecture système (telle que transposée par la «fierté» Standard System Concept Structure) prévoit la Feuille de route nécessaires pour trouver votre chemin grâce à un système indépendamment de sa complexité. De nombreux programmeurs afficher les graphiques tels que frivole, principalement parce qu'ils ne se préoccupent que de leur petit morceau du casse-tête et sont préoccupés par la situation dans son ensemble. Mais pour ceux d'entre vous qui ont besoin de voir l'image totale, l'architecture du système est la première étape logique pour diagnostiquer les problèmes.
Pour plus d'informations sur la «fierté» Standard System Concept structure, voir:
http://www.phmainstreet.com/mba/pride/is.htm