<\/HEAD>
Todos hemos estado allí. Tu estómago está gruñendo, pero toda tu energía mental está enfocada en arreglar el coche frente a ti que va a cincuenta en el carril rápido. Cuando las personas están hangry (hambrientas\/enojadas) pueden parecer irritables y agitadas, tal vez incluso señalar cada pequeño detalle que está saliendo mal, cuando el problema real es tan simple como stoy hambriento. 9Feed me!. <\/P>
El diagnóstico erróneo ocurre todo el tiempo y puede traducirse en muchas otras facetas de la vida, incluyendo problemas de software, pero ¿podrías diagnosticar problemas de software cuando parece que tu software está hangry? <\/P>
La buena noticia es que con algo de práctica y habilidades de observación, cualquiera puede categorizar problemas de software como un profesional. Este blog te ayudará a guiarte cuando te encuentres con problemas de software. La intención es levantar las muchas capas que pueden complicar los problemas, para que puedas declarar con precisión, pero de manera simple, el problema con el que necesitas ayuda.<\/P>
<\/P>
Los síntomas de los problemas de software son observables por el usuario final en muchas formas, como un error, degradación del rendimiento o un bloqueo del software, por nombrar algunos. Esperamos que estas interrupciones impulsen a los usuarios a llamar a Esri Support y registrar un caso para investigación. En Esri Support, nuestros analistas tienen un conjunto específico de habilidades. Pocos de nosotros somos generalistas, y esta estructura está diseñada para proporcionar a nuestros clientes soporte técnico élite... en otras palabras, no usamos scripts.<\/P>
¿Por qué es esto importante? Uno de los primeros pasos para registrar un caso con Esri Support es proporcionar una descripción del problema, que se usará para formar una línea de asunto en el caso. Estas líneas de asunto pueden ser modificadas a medida que se adquiere más conocimiento sobre el problema mediante la investigación, pero esta línea inicial es un factor importante para determinar qué analista será responsable del caso primero.<\/P>
<\/P>
Determinar el síntoma general ayuda a guiar el proceso de triaje y la duración del caso. Exploremos estos síntomas con más detalle.<\/P>
<\/P>
1. Error: <\/P>
Los mensajes de error nos detendrán en seco. A veces los mensajes son muy útiles y nos dicen exactamente lo que necesitamos saber para continuar, otras veces no tanto. Cuando los usuarios encuentran errores siempre solicitamos una captura de pantalla del error y el flujo de trabajo (clics) que condujeron al error. Por ejemplo, Error: identificador del sistema de coordenadas inválido se ve al agregar datos desde una geodatabase empresarial Oracle en ArcMap.<\/P>
<\/P>
2. Degradación del rendimiento: <\/P>
Personalmente, este es el problema más frustrante de encontrar. No hay error; en cambio, el proceso es lento y el reloj de arena giratorio no te dice cuándo puedes esperar que el rendimiento vuelva a la normalidad. Cuando llegan casos de rendimiento a mi escritorio, primero evalúo la lentitud, porque "lentitud" es un término relativo y algo que es lento en un entorno puede ser óptimo en otro. El síntoma aquí no es solo rendimiento, sino específicamente degradación del rendimiento. En otras palabras, hubo un rendimiento más óptimo que ahora se ha degradado.<\/P>
Los síntomas de bajo rendimiento pueden ser causados por muchas cosas incluyendo flujos de trabajo, recursos sobrecargados y compatibilidad del software por nombrar algunos. Para comenzar a solucionar problemas siempre es útil tener un caso comparativo disponible para investigación. Si crees que estás viendo lentitud en el software, primero pregúntate '¿esto es lento comparado con qué?' <\/P>
Por ejemplo, usar ArcMap 10.1 sp1 para hacer el mismo flujo de trabajo con los mismos datos toma 1 segundo, mientras que usar ArcMap 10.5.1 toma 20 segundos,<\/EM> o Previsualizar la clase de entidad A en ArcCatalog toma 1 segundo, mientras que previsualizar la clase B toma 20 segundos. Ambas características están almacenadas en la misma geodatabase empresarial.<\/EM><\/P>Estos ejemplos nos dan un ejemplo "rápido" y uno "lento" que pueden compararse entre sí. Observa en estos ejemplos que solo hay una diferencia en los flujos de trabajo, dándonos variables controladas y una sola variable dependiente para revisar... correcto, como científicos.<\/P><\/P>3. Resultados inesperados: <\/P>Este síntoma, como el rendimiento, no producirá un error, pero a diferencia de los síntomas de rendimiento, estos procesos se completan aparentemente con éxito. Sin embargo, cuando se analizan los resultados son incorrectos o incompletos. Los resultados inesperados también pueden tomar la forma de herramientas deshabilitadas o atenuadas.<\/P>Por ejemplo, Abro ArcCatalog para habilitar Editor Tracking en mi clase de entidad, pero Habilitar Editor Tracking está atenuado,<\/EM> o Creé una réplica de mi clase de entidad Estados Unidos, pero solo 48 estados fueron replicados en la geodatabase hija.<\/EM><\/P>La mayoría de las veces los resultados inesperados provienen de un problema en el flujo de trabajo. Alguna configuración que necesitaba estar activada para que esta herramienta funcionara no estaba activada o las propiedades\restricciones sobre estos datos causaron los resultados inesperados. En el primer ejemplo anterior la conexión debe hacerse como propietario de los datos para habilitar Editor Tracking. Cualquier otra conexión de usuario verá la opción Editor Tracker atenuada. El segundo ejemplo donde no todos los datos han sido replicados puede deberse a filtros colocados sobre los datos replicados o clases de relación que hacen cumplir la integridad referencial en la base de datos. <\/P> <\/P>4. Bloqueo:<\/P>Clic, clic boom va la dinamita. No hay error. Lo mejor que puedes hacer es reabrir el software e intentarlo nuevamente. Esri considera todos los bloqueos como bugs. Queremos que nuestro software te dé un error significativo que te ayude a completar tu trabajo. Los bloqueos ocurren cuando el software encuentra un argumento que no sabe cómo resolver. Siempre reporta bloqueos a Esri Support para que podamos asegurarnos que nuestro software entienda cómo manejar estas situaciones.<\/P> <\/P>Los problemas de software pueden ser complejos y emplear múltiples tecnologías que requieren diferentes niveles de experiencia en muchos temas diferentes. Estos problemas pueden ser más abordables respondiendo a la pregunta "¿Qué observé durante mi trabajo diario que me llevó a solicitar ayuda?" Aunque siempre hay excepciones, el 90% del tiempo puedo comenzar a responder esa pregunta con uno o más síntomas discutidos en este blog. Espero que esto ayude a iluminar la oscuridad percibida alrededor de los problemas del software y como siempre, llámanos si encuentras alguno de estos problemas o simplemente tienes preguntas para nosotros. <\/P><\/P>esrisupport<\/P><\/BODY><\/HTML>
