Entendendo Problemas de Software: Software Hangry

TinaMorgan1

<\/HEAD>

Todos nós já passamos por isso.  Seu estômago está roncando, mas toda a sua energia mental está focada em consertar o carro à sua frente que está indo a cinquenta na faixa rápida.  Quando as pessoas estão hangry (hungry\/angry), podem parecer irritadas e agitadas, talvez até apontem cada pequena coisa que está dando errado, quando o problema real é tão simples quanto stou com fome.  Me alimente!. <\/P>

Diagnósticos errados acontecem o tempo todo e podem se traduzir em muitos outros aspectos da vida, incluindo problemas de software, mas você conseguiria diagnosticar problemas de software quando parece que seu software está hangry? <\/P>

A boa notícia é que, com alguma prática e habilidades de observação, qualquer um pode categorizar problemas de software como um profissional.  Este blog vai ajudar a guiá-lo ao encontrar problemas de software.  A intenção é levantar as muitas camadas que podem complicar os problemas, para que você possa declarar o problema com precisão, porém de forma simples, para o qual precisa de ajuda.<\/P>

<\/P>

Os sintomas dos problemas de software são observáveis pelo usuário final de várias formas, como um erro, degradação de desempenho ou uma falha do software, para citar alguns.  Esperançosamente, essas interrupções levam os usuários a ligar para o Esri Support e registrar um caso para investigação.  No Esri Support, nossos analistas possuem um conjunto específico de habilidades.  Poucos de nós são generalistas, e essa estrutura é projetada para fornecer aos nossos clientes suporte técnico de eliteem outras palavras, não usamos scripts. <\/P>

Por que isso é importante?  Um dos primeiros passos para registrar um caso no Esri Support é fornecer uma descrio do problema, que será usada para formar a linha de assunto do caso.  Essas linhas de assunto podem ser alteradas conforme mais conhecimento é adquirido sobre o problema durante a investigação, mas essa linha inicial é um grande fator para determinar qual analista será responsável pelo caso primeiro. <\/P>

 <\/P>

Determinar o sintoma geral ajuda a guiar o processo de triagem e o ciclo de vida do caso.   Vamos explorar esses sintomas com mais detalhes.<\/P>

<\/P>

1.  Erro: <\/P>

Mensagens de erro nos paralisam.  Às vezes as mensagens são muito úteis e nos dizem exatamente o que precisamos saber para prosseguir, às vezes nem tanto.  Quando os usuários encontram erros, sempre solicitamos uma captura de tela do erro e o fluxo de trabalho (cliques) que levou ao erro.  Por exemplo, rro: identificador do sistema de coordenadas inválido é visto ao adicionar dados de um banco geodatabase corporativo Oracle no ArcMap.<\/P>

<\/P>

2.  Degradação de desempenho:  <\/P>

Pessoalmente, este é o problema mais frustrante de encontrar.  Não há erro; em vez disso, o processo está lento e a ampulheta giratória não informa quando você pode esperar que o desempenho volte ao normal.  Quando casos de desempenho chegam à minha mesa, primeiro avalio a lentidão, porque "lentidão" é um termo relativo e algo lento em um ambiente pode ser ótimo em outro.  O sintoma aqui não é apenas desempenho, mas especificamente degradação do desempenho.  Em outras palavras, houve um desempenho mais ideal que agora se degradou.<\/P>

Sintomas de desempenho lento podem ser causados por muitas coisas incluindo fluxos de trabalho, recursos sobrecarregados e compatibilidade do software para citar alguns.   Para começar a solucionar problemas, sempre é útil ter um caso comparativo disponível para investigação.  Se você acredita estar vendo lentidão no software, primeiro pergunte a si mesmo 'isso está lento comparado a quê?'  <\/P>

Por exemplo, m usar ArcMap 10.1 sp1 para fazer o mesmo fluxo de trabalho nos mesmos dados leva 1 segundo, enquanto usar ArcMap 10.5.1 leva 20 segundos , <\/EM>ou visualização da classe de feição A no ArcCatalog leva 1 segundo, enquanto visualizar a classe B leva 20 segundos. Ambas as feições estão armazenadas no mesmo banco geodatabase corporativo . <\/EM><\/P>Esses exemplos nos dão um exemplo "rápido" e um exemplo "lento" que podem ser comparados entre si.  Note nestes exemplos que há apenas uma diferença nos fluxos de trabalho, nos dando variáveis controladas e uma única variável dependente para revisar... certo, como cientistas.<\/P><\/P>3.  Resultados inesperados:  <\/P>Este sintoma, como o desempenho, não produzirá um erro, mas diferente dos sintomas de desempenho, esses processos serão concluídos aparentemente com sucesso.  No entanto, quando os resultados são analisados eles estão incorretos ou incompletos.   Resultados inesperados também podem se manifestar na forma de ferramentas desabilitadas ou esmaecidas.<\/P>Por exemplo, u abro ArcCatalog para habilitar Editor Tracking na minha classe de feição, mas Habilitar Editor Tracking está esmaecido , <\/EM>ou u criei uma réplica da minha classe de feição dos Estados Unidos, mas apenas 48 estados foram replicados no banco geodatabase filho .<\/EM><\/P>Na maioria das vezes resultados inesperados decorrem de um problema no fluxo de trabalho.  Alguma configuração que precisava ser ativada para esta ferramenta funcionar não foi ativada ou propriedades/ restrições nesses dados causaram os resultados inesperados.  No primeiro exemplo acima a conexão deve ser feita como proprietário dos dados para habilitar Editor Tracking.  Qualquer outra conexão do usuário verá a opção Editor Tracker esmaecida.  O segundo exemplo onde nem todos os dados foram replicados pode ser devido a filtros aplicados aos dados sendo replicados ou classes de relacionamento impondo integridade referencial do banco de dados.  <\/P> <\/P>4.  Falha:<\/P>Clique clique bum vai a dinamite.  Não há erro.  O melhor que você pode fazer é reabrir o software e tentar novamente.  A Esri considera todas as falhas como bugs.  Queremos que nosso software lhe dê um erro significativo que ajude você a completar seu trabalho.  Falhas ocorrem quando o software encontra um argumento que não sabe como resolver.  Sempre reporte falhas ao Esri Support para que possamos garantir que nosso software saiba como lidar com essas situações.<\/P> <\/P>Problemas de software podem ser complexos e envolver múltiplas tecnologias que requerem diferentes níveis de especialização em muitos assuntos diferentes.  Esses&nbspproblemas podem ser mais acessíveis respondendo à pergunta "O que observei durante meu trabalho diário que me levou a pedir ajuda"?   Embora sempre haja exceções, 90% das vezes posso começar respondendo essa pergunta com um ou mais dos sintomas discutidos neste blog. &nbspEspero que isso ajude a iluminar a escuridão percebida em torno dos problemas de software e como sempre, ligue para nós se encontrar algum desses problemas ou simplesmente tiver perguntas para nós. <\/P><\/P>esrisupport<\/P><\/BODY><\/HTML>

TinaMorgan1

George, 

I am so sorry I overlooked this post back in November!

My understanding of the crash pop up is that it does go to an Esri development team for review, but unfortunately I do not have much more insight on it than that.  I will see what I can find out.  

This article, though, is more specifically when the user who sees a crash wishes to contact Esri Support for investigation of those issues.  It is common that users ask us "Why all of the questions", so this was in hopes going to clarify why.  

If you listened to Car Talk, it's the same scenario.  Someone calls in with a description of an issue.  Ray and (the late) Tom would then have to ask clarifying questions like "do you hear the rattle when the air conditioning is on?  Now is it a rattle or a screeching sound or both?  What year is your car?", because they understand the mechanics used to run an air conditioner.  Your answers help them give effective advice like "since this is an older car, and it only happens when the AC is on, and it is a rattle with a screeching sound I'd say check your Serpentine belt.". 

As mentioned, a crash is a bug in our eyes.  We do not want that to happen.  I encourage you to call support to report the crash if it is still happening.