Diagnostiquer les problèmes du système

"Sans une feuille de route, vous pourriez être conduite en rond." - Loi de Bryce

INTRODUCTION

Okay, vous avez lancer votre débogueur de programme répétitive et vérifie tout ce passera bien. Mais pour une raison inconnue, tout le système est inopérant. Le logiciel et la conception de base de données soit bien présenté, mais vous allez Stark-fou furieux essaie de localiser le problème. Avez-vous pensé qu'il pourrait ne pas être un défaut dans la conception du logiciel ou base de données du tout? Que peut-être le problème réside dans l'architecture globale du système, ou éventuellement son juste vous?

Dans de nombreux cas, le diagnostic du problème est plus douloureux que d'y remédier. Considérant que j'ai passé en revue les principes de test de base dans le passé, ici, je veux discuter de certains conseils pour diagnostiquer des 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 société de fabrication dans le nord qui avait du mal à s'acquitter de leurs magasin nouveau système de contrôle sol. Le système a été l'état de l'art en termes de programmation et SGBD technologie. Mais ils ne pouvaient tout simplement pas à le faire marcher, peu importe ce qu'ils ont essayé. Frustrée, la société a retenu nos services pour voir si nous pouvions trouver le problème. Au lieu d'étudier le code source, comme le développement du personnel avait fait, nous avons commencé par la cartographie de l'architecture globale du système.

J'ai décrit la "fierté" Standard System Structure Concept sur plus d'une occasion, mais en résumé, un système peut être dessiné comme une hiérarchie à quatre niveaux représentant une structure de produit. Tandis qu'une structure de produits se compose de quatre niveaux de la représentation des produits, assemblées, sous-ensembles, et des opérations, «fierté» De même, le système se décompose en:

NIVEAU 1 - SYSTEME DE NIVEAU 2 - Sous-système (Business Processes) niveau 3 - des procédures (administratives et informatiques) Niveau 4 - Étapes opérationnelles (pour les procédures administratives) et des programmes (pour Computer Procedures)

Cette approche d'application universelle pour définir l'architecture du système permet une feuille de route pratique pour marcher à travers tous les aspects du système et la validation de son intégrité. Diagrammes de hiérarchie peut soit être produit à partir des référentiels IRM ou de quelques outils simples graphiques. Dans notre mission de conseil cependant, Nous l'avons simplement esquissé l'utilisation de papier et un crayon. Fondamentalement, nous avons marché à travers le système, à l'échantillonnage de travail et cherché des interfaces homme / machine. Inévitablement, nous sommes tombés sur un sous-système dans lequel l'ordinateur affichait des erreurs dans les ateliers qui nécessitent une attention par le contremaître. Le contremaître était de prendre les mesures correctives et de répondre à l'ordinateur. Il n'y avait qu'un seul problème avec ceci: Personne n'avait dit au 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 a fonctionné correctement par la suite ( "miraculeusement" tant que notre client a dit).

Cela fait apparaître un point important: les systèmes échouent plus pour l'absence de procédures administratives que pour bien programmé des procédures informatiques. Bien que l'entreprise de fabrication avait produit quelques logiciels plutôt élégant, ils avaient complètement négligé l'interface homme / machine. Là encore, la "fierté" Standard System Structure Concept a fourni la feuille de route nécessaire, mais parce que le client n'a pas apprécié la nécessité d'une telle technique de haut en bas bleus, ils n'avaient aucune idée où tout était.

2. Travailler à l'envers.

Lorsque le diagnostic des processus d'affaires, procédures et programmes, il ya 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, essayez de travailler à rebours à partir bout commencer, entre sa sortie et d'entrée. Encore une fois, la carte de la conception à l'aide d'un organigramme ou d'une technique graphique autre. Si la transformation implique des décisions importantes, dessiner un arbre de décision ou une table. Ces graphiques sont très précieux pour la validation
logic design.

3. Avoir une seconde paire d'yeux regarder par-dessus votre travail.

Comme nous s'imprégner dans la mécanique d'une conception, trop souvent, l'évidence devient moins évident pour nous. Ici, une autre paire d'yeux peut facilement voir un problème que nous avons négligé. Cela est particulièrement bénéfique dans les magasins opérant en conformité avec certaines normes de conception. Les pratiques de conception uniforme rend
facilité le repérage des anomalies que sans de telles normes.

Lorsque la deuxième personne est originaire est également importante. Si la personne vient de votre groupe de travail et est familier avec votre style de design, il / elle mai 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 une tierce personne neutre, avec un regard neuf sur le problème. Cela peut être une personne au sein de l'entreprise ou, éventuellement, un consultant extérieur.

CONCLUSION

Aides graphiques, tels que des organigrammes et des diagrammes, sont utiles pour diagnostiquer un problème, mais n'oubliez pas également de contester la graphique. Ce n'est pas rare de voir des graphismes pas correspondre à ce qui se passe en fait. Un référentiel de bonnes IRM est très précieuse pour étayer desseins. La conception est soit correctement enregistrées dans le référentiel IRM ou qu'elle n'est pas. En outre, un tel outil fournit les moyens d'étudier la relation entre les ressources d'information (alias «analyse d'impact»), qui révèlent mai composants inconnus relatif à un dessin.

Plus important encore, l'idée de maintenir une architecture de système (telle que transposée par le "Pride" Standard System Structure Concept) 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 des graphiques tels que frivole, principalement parce qu'ils sont uniquement préoccupés par leur petit morceau du casse-tête et sont peu soucieux de l'image totale. 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 des problèmes.