"Sin una hoja de ruta, que podría estar conduciendo en círculos".
- Ley de Bryce
INTRODUCCIÓN
Muy bien, has corrido el depurador de programas repetitiva y cheques todo salió bien. Pero por alguna razón desconocida, todo el sistema no funciona. Tanto el diseño de software y base de datos se ve bien, pero usted va loco tratando de Stark-que bailan al localizar el problema. ¿Has considerado que tal vez no sea un defecto en el diseño del software o base de datos en absoluto? Eso tal vez el problema reside en la arquitectura general del sistema, o posiblemente su justo usted?
En muchos casos, el diagnóstico de un problema es más doloroso que corregirlo. Mientras que yo he revisado los principios básicos de verificación en el pasado, ver;
N º 41 - "Prueba 1, 2, 3 ..." - 12 de septiembre 2005
http://www.phmainstreet.com/mba/ss050912.pdf
Aquí, quiero discutir algunos consejos para el diagnóstico de problemas.
TRES CONSEJOS
1. Camine por el sistema y verifique la interfaces hombre / máquina.
Hace años, fuimos contratados por una compañía de fabricación grande en el noreste de que tenía problemas para la aplicación de su nuevo sistema de control de los centros. El sistema fue el estado de la técnica respecto de la programación y la tecnología DBMS. Pero simplemente no podía conseguir que funcione, no importa lo que pretendían. Frustrada, la empresa nos contrató para ver si podíamos encontrar el problema. En lugar de estudiar el código fuente, como el equipo de desarrollo ha hecho, hemos comenzado por la cartografía de la arquitectura general del sistema.
He descrito el "orgullo" Estructura del Sistema Estándar Concepto en más de una ocasión, pero en pocas palabras, un sistema puede ser dibujado como una jerarquía de cuatro niveles que representan una estructura de producto. Considerando que una estructura de producto se compone de cuatro niveles de representación de productos, conjuntos, subconjuntos, y las operaciones, el "orgullo" también se descompone el sistema en:
NIVEL 1 - SISTEMA DE
NIVEL 2 - SUB-SYSTEM (Procesos de Negocios)
NIVEL 3 - PROCEDIMIENTOS (Administrativos y de Informática)
NIVEL 4 - Fases de (para Procedimientos Administrativos) y programas (por procedimientos informáticos)
Este enfoque de aplicación general para la definición de la arquitectura del sistema hace una hoja de ruta cómoda para caminar a través de todos los aspectos del sistema y la validación de su integridad. Tales diagramas jerarquía puede ser producido a partir de repositorios IRM o de algunas herramientas gráficas simples. En nuestro trabajo de consulting, sin embargo, simplemente lo esbozado con papel y lápiz. Básicamente, caminamos a través del sistema, incluidos en la muestra de trabajo y espera para el hombre interfaces máquina /. Inevitablemente, nos encontramos con un sub-sistema en el que el equipo muestra los errores en el taller que requieren atención por el capataz. El capataz fue a tomar las medidas correctivas y responder a la computadora. Sólo había un problema con esto: nadie le había dicho el jefe de taller por nada de esto. Luego escribió un simple procedimiento administrativo para el capataz que tomaron las acciones necesarias y el sistema funciona correctamente a partir de entonces ("milagrosamente", como dijo nuestro cliente).
El resultado será un punto importante: sistemas fallarán más por la falta de procedimientos administrativos que para bien programada procedimientos informáticos. Aunque la empresa de fabricación había producido algún software bastante elegante, que había pasado por alto completamente el interfaz hombre-máquina. De nuevo, el "orgullo" Estructura del Sistema Estándar Concepto había proporcionado la necesaria
hoja de ruta, sino porque el cliente no apreció la necesidad de esta de arriba hacia abajo heliográfica técnica, no tenían idea de dónde estaba todo.
2. Trabaja al revés.
Cuando el diagnóstico de los procesos de negocio, procedimientos y programas, hay una inclinación natural a ir de principio a fin en el diagnóstico de un problema. A veces usted puede encontrar un hipo aplicando este enfoque, otras veces no. En lugar, trate de trabajar hacia atrás desde el extremo para iniciar, desde la salida a la entrada. Una vez más, el mapa del diseño mediante un diagrama de flujo o alguna técnica gráfica. Si el procesamiento implica decisiones importantes, dibujar un árbol de decisión o una mesa. Estos gráficos son muy valiosos para la validación de
diseño lógico.
3. Tener un segundo par de ojos se vean más de su trabajo.
A medida que se penetren en la mecánica de un diseño, muy a menudo lo obvio se vuelve menos evidente para nosotros. Aquí, otro par de ojos puede ver fácilmente un problema al que nos han pasado por alto. Esto es particularmente beneficioso en los comercios adheridos, de conformidad con las normas de diseño determinado. prácticas uniformes de diseño hace
es más fácil de detectar anomalías que sin esas normas.
Cuando la persona viene de segunda también es importante. Si la persona viene de su grupo de trabajo y está familiarizado con su estilo de diseño, él / ella puede muy bien ser capaz de detectar un problema. Por otra parte, quizá no. Tal vez el problema será invisible para ellos. En este caso, es posible que desee consultar a un neutral
tercera persona con una nueva perspectiva sobre el problema. Esto puede ser una persona de dentro de la empresa o, posiblemente, un consultor externo.
CONCLUSIÓN
ayudas gráficas, como diagramas de flujo y diagramas, son útiles para diagnosticar un problema, pero también recuerdo a desafiar el gráfico. No es raro que los gráficos no para cubrir lo que está sucediendo en realidad. Un buen repositorio de IRM está siendo muy valiosa para que acrediten diseños. El diseño es ya sea debidamente registrada
en el Repositorio de IRM o no lo es. Además, esta herramienta proporciona los medios para estudiar la relación de recursos de información (también conocido como "análisis de impacto") que puede revelar elementos desconocidos que afectan a un diseño.
Más importante aún, la idea de mantener una arquitectura de sistema (desarrollado por el "orgullo" Estructura del Sistema Estándar Concepto) proporciona la hoja de ruta necesaria para encontrar su camino a través de un sistema, independientemente de su complejidad. Muchos programadores ver gráficos como frívola sobre todo porque sólo se preocupan de su pequeña pieza del rompecabezas y no les preocupa la imagen total. Pero para aquellos de ustedes que necesitan para ver el cuadro total, la arquitectura del sistema es el primer paso lógico para el diagnóstico de problemas.
Para obtener más información sobre el "orgullo" Estructura del Sistema Estándar Concepto, véase:
http://www.phmainstreet.com/mba/pride/is.htm