[Arquivo] Sistema de Reportamento de Bugs (2007)
Meu primeiro artigo científico rejeitado e último escrito, dado o meu desencanto com a dita "comunidade científica". Apesar de muito mal escrito, a proposta era inovadora para a época, e eu inocentemente esperava ter algum reconhecimento por isso.
Anselmo A. Peretto, Marco De Toni, Roberto R. Jonikaites, <nome do professor que não ajudou>
Abstract. The advent of innumerable easinesses that the technology comes bringing in recent years, each time more people uses computerized information systems to make controls of the most varied forms, in professional such as in personal scope. With this, it appears the creation of new necessities and solutions, where companies — softwarehouses — come usufructing of this niche, thus generating a natural competition, where to have a differential in hands can make a great difference. The present article, based on the premise that distinguishing competitive are essential, presents bugs control solution for softwarehouses, reporting by email, due an agent of parallel processing, informations about the bug before of the customer enter in contact to report the problem, improving and speeding the attendance.
Resumo. Com o advento de inúmeras facilidades que a tecnologia vem trazendo nos últimos anos, cada vez mais pessoas utilizem sistemas de informação computadorizados para fazerem controles das mais variadas formas, tanto no âmbito pessoal quanto profissional. Com isto surge a criação de novas necessidades e soluções, onde empresas — softwarehouses — vêem usufruindo deste nicho, gerando assim uma concorrência natural, onde ter um diferencial nas mãos pode fazer uma grande diferença. O presente artigo, baseado na premissa de que diferenciais competitivos são essenciais, apresenta uma solução de controle de bugs para softwarehouses, reportando via e-mail, através de um agente de processamento paralelo, informações sobre o bug antes mesmo de o cliente entrar em contato para reportar o problema, melhorando e agilizando assim o atendimento.
Existem softwarehouses que desenvolvem soluções semelhantes com preços também semelhantes, isto gera uma concorrência diária, onde a propaganda acaba sendo o único diferencial. Visando mudar este último diferencial, empresas apostam em alternativas ímpares, ou seja, desenvolvem soluções diferenciadas ou atendimentos instantâneos e de qualidade excepcional, tudo em nome da excelência.
Uma das alternativas, já utilizadas por sistemas operacionais [Microsoft Windows] e grandes softwares, é o monitoramento e reportamento de bugs [Bugzilla, 2007], ou seja, erros no software decorrentes das mais variadas razões. O conhecimento destes é de vital importância para o aprimoramento do código para o setor de desenvolvimento ou para ter o conhecimento do problema antes mesmo do cliente reportá-lo ao suporte, dando assim um aspecto efetivo de agilidade no atendimento. Os tópicos a seguir mostram a funcionalidade desta solução.
O software por sua vez, pode apresentar modificações, implementações e melhorias, na medida em que for preenchendo os itens da solução apresentada. Porém, o software por si só é inútil, pois ele necessita de diversos fatores para ser utilizado e funcionar, estes fatores podem ser hardware, sistema operacional, topologia de rede, banco de dados, etc. Quanto mais dependências, mais o software fica instável e sucessivo à problemas, pois elas são independentes do software e podem apresentar problemas.
Existem praticamente duas formas de tornar o código-fonte um software executável: a compilação e a interpretação (figura 1). Um software compilado consiste em um arquivo binário gerado pelo compilador, este por sua vez mais rápido que o software interpretado e necessita de mais memória, porém está atrelado ao hardware e/ou ao sistema operacional, dependendo deles para ser executado, pois foi previamente compilado nesta estrutura. O software interpretado é composto por instruções que são executadas por um interpretador; são melhores e mais rápidas para serem efetuadas alterações e atualizações devido o tempo de compilação não existir, e a maior vantagem é a portabilidade, pois são ligados ao interpretador em si, e não diretamente ao hardware.
A proposta detalhada deste artigo, apresentada em um dos tópicos à frente, foi escolhida como base de execução a interpretação, através da linguagem de programação Python, devido as grandes vantagens do interpretador desta linguagem, destacamos três:Linguagem de altíssimo nível, valorizando a abstração, ou seja, a habilidade de concentrar apenas os aspectos essenciais em um determinado contexto, dispensando assim atenção para itens menos importantes ou de menor prioridade;
Portabilidade para Windows, Linux e outros sistemas operacionais;
Código-fonte disponível para manutenções e adaptações rápidas ad hoc;
Figura 2. Arquitetura da thread utilizada.
Figura 3. Arquitetura de um Agente Reflexivo.
Pensando na criticidade de certas instruções, como a última citada, e na preocupação tanto por parte do usuário do software quanto da equipe desenvolvedora, elaboramos esta proposta. Imagine que ocorram problemas em uma determinada instrução que faça movimentações financeiras, onde esta simplesmente se perde, deixando um furo no faturamento por exemplo, o quão seria constrangedor para a equipe de desenvolvimento do software perante a sociedade empresarial do ramo, sem contar no prejuízo do cliente, que de acordo com a quantia perdida e do porte da empresa, retirará o software imediatamente.
Aprofundando assim a explicação e analisando a figura 4, podemos observar que as instruções 1 e 3 estão sendo executadas normalmente, sem interferência do sistema aqui proposto, o que não está ocorrendo na instrução 2, hipoteticamente este é um código crítico e deve ser observado pela equipe de desenvolvimento, ou de qualquer outro administrador que possa tomar providencias para normalizar o ocorrido.
A instrução 2 é executada de forma linear, juntamente com a sua análise, para não interferir no andar normal do software. A análise verifica erros utilizando a própria estrutura da linguagem de programação para identificá-los, ficando a cargo do desenvolvedor filtrar os erros que convier. Nesta proposta estamos reportando todo e qualquer erro, pois como já citamos, o código é crítico e vital.
Ao identificar que a instrução está com problemas, de forma paralela é feita a chamada via thread do agente reflexivo que tomará nota de informações úteis, como o nome e o código do erro, qual função e qual linha ocorreu o erro, qual código-fonte foi utilizado, horário, enfim, há uma gama de opções que podem serem enviadas, porém nos contentaremos com o essencial. Enquanto isso, a linha de execução principal vai sendo executada, e o agente que faz o envio do e-mail para os responsáveis e interessados é enviado paralelamente, de forma invisível para o usuário, pois psicologicamente ele subentenderá que a equipe de desenvolvimento esteja naquele exato momento verificando o seu erro e retornando o mais breve possível, e muitos sabem que esta não é a realidade em uma softwarehouse. Então para não criar falsas impressões, o envio é invisível e discreto.
Ao enviar o e-mail, a thread encerra a sua execução automaticamente e a linha de execução do software continua sendo executada como sempre linearmente, seguindo as instruções que lhe esperam, fechando assim o ciclo.
Este sistema pode não parecer uma ferramenta que revolucionará uma softwarehouse, porém com toda certeza trará mais habilidades para a equipe de desenvolvimento, mais credibilidade para o suporte, pois terão um breve parecer das informações do bug antes mesmo do cliente entrar em contato e mais valorização moral da empresa pela parte dos clientes e grupos empresariais.
O uso propriamente dito de agentes computacionais comprova o que os autores e entusiastas promovem: desenvolvimento de melhores ferramentas e um melhor controle sobre o software desenvolvido. A concepção deste projeto ficaria distorcida e sua utilidade seria reduzida caso não houvesse o importante papel dos agentes computacionais.
Osse, José Sergio. Falta de mão-de-obra especializada pode impedir desenvolvimento tecnológico no país, diz HP. UOL Economia, 25 Maio 2007. Disponível em: <http://noticias.uol.com.br/economia/ultnot/valor/2007/05/22/ult1913u69449.jhtm>. Acesso em: 28 Maio 2007.
Microsoft Corp. Windows. Sistema operacional. Disponível em: <http://www.microsoft.com/>. Acesso em: 01 Junho 2007.
The Mozilla Organization. BUGZILLA. Apoio para gerenciar desenvolvimento de softwares. Disponível em: <http://www.bugzilla.org/>. Acesso em: 28 Maio 2007.
Pressman, Roger S. Engenharia de Software. 1ª ed., Editora McGraw-Hill, 1995.
Bradshaw, J. M. Software Agents. MIT Press, Cambridge, Massachusetts, 1997.
Abstract. The advent of innumerable easinesses that the technology comes bringing in recent years, each time more people uses computerized information systems to make controls of the most varied forms, in professional such as in personal scope. With this, it appears the creation of new necessities and solutions, where companies — softwarehouses — come usufructing of this niche, thus generating a natural competition, where to have a differential in hands can make a great difference. The present article, based on the premise that distinguishing competitive are essential, presents bugs control solution for softwarehouses, reporting by email, due an agent of parallel processing, informations about the bug before of the customer enter in contact to report the problem, improving and speeding the attendance.
Resumo. Com o advento de inúmeras facilidades que a tecnologia vem trazendo nos últimos anos, cada vez mais pessoas utilizem sistemas de informação computadorizados para fazerem controles das mais variadas formas, tanto no âmbito pessoal quanto profissional. Com isto surge a criação de novas necessidades e soluções, onde empresas — softwarehouses — vêem usufruindo deste nicho, gerando assim uma concorrência natural, onde ter um diferencial nas mãos pode fazer uma grande diferença. O presente artigo, baseado na premissa de que diferenciais competitivos são essenciais, apresenta uma solução de controle de bugs para softwarehouses, reportando via e-mail, através de um agente de processamento paralelo, informações sobre o bug antes mesmo de o cliente entrar em contato para reportar o problema, melhorando e agilizando assim o atendimento.
1. Introdução
A evolução da tecnologia vem modificando o cenário e o comportamento organizacional de empresas diariamente [Sauve-Medeiros, 2003], introduzindo conceitos de informática e melhoria de processos através de sistemas de informação. Empresas que desenvolvem soluções em software — softwarehouses — para fins de fomentar estas necessidades, estão crescendo em um número muito acelerado, diversos fatores além das necessidades estão contribuindo para isto, uma delas é a mão-de-obra barata e não especializada recém saída das universidades [Osse, 2007].Existem softwarehouses que desenvolvem soluções semelhantes com preços também semelhantes, isto gera uma concorrência diária, onde a propaganda acaba sendo o único diferencial. Visando mudar este último diferencial, empresas apostam em alternativas ímpares, ou seja, desenvolvem soluções diferenciadas ou atendimentos instantâneos e de qualidade excepcional, tudo em nome da excelência.
Uma das alternativas, já utilizadas por sistemas operacionais [Microsoft Windows] e grandes softwares, é o monitoramento e reportamento de bugs [Bugzilla, 2007], ou seja, erros no software decorrentes das mais variadas razões. O conhecimento destes é de vital importância para o aprimoramento do código para o setor de desenvolvimento ou para ter o conhecimento do problema antes mesmo do cliente reportá-lo ao suporte, dando assim um aspecto efetivo de agilidade no atendimento. Os tópicos a seguir mostram a funcionalidade desta solução.
2. Softwares compilados e softwares interpretados
O produto principal de uma softwarehouse é o seu software, seguido pela solução, onde um é inerente do outro. Sem solução, o software perderá o sentido; e sem software a solução será mais morosa. A solução, uma vez elaborada e apresentada pela softwarehouse e esta assinada pelo cliente, literalmente não haverá maiores modificações, pois o software será desenvolvido baseado nesta solução, qualquer alteração na solução posterior a isto poderá acarretar em uma modificação tão grande no software que não compensará perseguir com o projeto, por isto a solução deve ser muito bem elaborada e definida antes de tudo. [Pressman, 1995]O software por sua vez, pode apresentar modificações, implementações e melhorias, na medida em que for preenchendo os itens da solução apresentada. Porém, o software por si só é inútil, pois ele necessita de diversos fatores para ser utilizado e funcionar, estes fatores podem ser hardware, sistema operacional, topologia de rede, banco de dados, etc. Quanto mais dependências, mais o software fica instável e sucessivo à problemas, pois elas são independentes do software e podem apresentar problemas.
Existem praticamente duas formas de tornar o código-fonte um software executável: a compilação e a interpretação (figura 1). Um software compilado consiste em um arquivo binário gerado pelo compilador, este por sua vez mais rápido que o software interpretado e necessita de mais memória, porém está atrelado ao hardware e/ou ao sistema operacional, dependendo deles para ser executado, pois foi previamente compilado nesta estrutura. O software interpretado é composto por instruções que são executadas por um interpretador; são melhores e mais rápidas para serem efetuadas alterações e atualizações devido o tempo de compilação não existir, e a maior vantagem é a portabilidade, pois são ligados ao interpretador em si, e não diretamente ao hardware.
A proposta detalhada deste artigo, apresentada em um dos tópicos à frente, foi escolhida como base de execução a interpretação, através da linguagem de programação Python, devido as grandes vantagens do interpretador desta linguagem, destacamos três:Linguagem de altíssimo nível, valorizando a abstração, ou seja, a habilidade de concentrar apenas os aspectos essenciais em um determinado contexto, dispensando assim atenção para itens menos importantes ou de menor prioridade;
Portabilidade para Windows, Linux e outros sistemas operacionais;
Código-fonte disponível para manutenções e adaptações rápidas ad hoc;
Figura 1. Diagrama simplificado da execução de um software compilado e interpretado
3. Bugs
“Bug” é o termo utilizado para referenciar um erro. Conta à história que a origem do termo pejorativo “bug” (inseto, em inglês) foi criado em meados do século passado, onde insetos eram atraídos pelas luzes das válvulas, componente utilizado em computadores da época — hoje substituídas por transistores, muitos já desenvolvidos com nanotecnologia — e ao entrarem na enorme estrutura de centenas de quilos daquelas máquinas, estes morriam devido o calor ou causavam curtos-circuitos, danificando o equipamento, ocasionando um erro qualquer. No software o termo foi reutilizado, mesmo não havendo inseto algum para causar erros. Neste projeto, os bugs são o que queremos evitar, por isso o sistema só vai ter efetividade total apenas quando encontrar um ou mais bugs, onde todos os processos serão chamados e executados.4. Thread
Para entendermos como a principal parte do software proposto funciona, primeiramente precisamos entender alguns termos e suas funcionalidades, um deles a thread. Um processador padrão utilizado nos computadores atualmente, processa um software utilizando um processamento de certa forma linear, ou seja, cada comando é executado de forma exclusiva, onde o próximo comando do software só será executado após o término da execução do comando anterior. Para entendermos melhor, imagine um programa de dois passos 1) que some duas variáveis e depois 2) divida o resultado por dois; qual seria a lógica do segundo passo ser executado antes do primeiro? Nenhuma, pois o programa foi concebido para executar o primeiro e depois o segundo passo. Uma thread seria uma ramificação paralela do processo linear, onde uma vez ramificada, esta é processada de forma isolada, tendo um começo, meio (execução) e fim. A principal vantagem da thread é permitir que programas simples executem tarefas autônomas simultaneamente (figura 2).Figura 2. Arquitetura da thread utilizada.
5. Agente de Software
Complementando o tópico anterior em relação a o que devemos compreender inicialmente, apresentamos aqui o responsável por estar enviando as informações dos bugs para os desenvolvedores de forma online, imediata e precisa: o agente computacional. Um agente computacional nada mais é do que uma entidade de software com ou sem auxílio de hardware que realiza um conjunto de atividades pré-definidas pelo seu autor, possuindo autonomia, reatividade, independência, etc. Mais especificamente, a categoria do agente utilizado na proposta é o agente reflexivo (figura 3), este por sua vez possui um nível de inteligência baixo, porém suficiente para executar a tarefa sugerida, onde através de seus sensores são captados estímulos que produzem dados que fomentam a função principal (f()) gerando assim respostas (informações), baseadas nos dados de entrada para que os atuadores possam executá-las dentro do ambiente proposto. Veremos a frente onde o agente reflexivo é encaixado exatamente e qual sua função dentro do projeto. [Bradshaw, 1997]Figura 3. Arquitetura de um Agente Reflexivo.
6. Como funciona o Sistema de Reportamento de Bugs
Em face do conteúdo apresentado nos tópicos anteriores, podemos comentar de forma mais tecnicamente detalhada como o projeto de reportamento de bugs funciona. O software, compilado ou interpretado, possui um código-fonte com linhas de instruções cada qual proveniente da linguagem de programação utilizada, que podem ser desde um simples comando para imprimir um texto ou uma grande instrução que faz movimentações financeiras em um banco de dados.Pensando na criticidade de certas instruções, como a última citada, e na preocupação tanto por parte do usuário do software quanto da equipe desenvolvedora, elaboramos esta proposta. Imagine que ocorram problemas em uma determinada instrução que faça movimentações financeiras, onde esta simplesmente se perde, deixando um furo no faturamento por exemplo, o quão seria constrangedor para a equipe de desenvolvimento do software perante a sociedade empresarial do ramo, sem contar no prejuízo do cliente, que de acordo com a quantia perdida e do porte da empresa, retirará o software imediatamente.
Aprofundando assim a explicação e analisando a figura 4, podemos observar que as instruções 1 e 3 estão sendo executadas normalmente, sem interferência do sistema aqui proposto, o que não está ocorrendo na instrução 2, hipoteticamente este é um código crítico e deve ser observado pela equipe de desenvolvimento, ou de qualquer outro administrador que possa tomar providencias para normalizar o ocorrido.
A instrução 2 é executada de forma linear, juntamente com a sua análise, para não interferir no andar normal do software. A análise verifica erros utilizando a própria estrutura da linguagem de programação para identificá-los, ficando a cargo do desenvolvedor filtrar os erros que convier. Nesta proposta estamos reportando todo e qualquer erro, pois como já citamos, o código é crítico e vital.
Ao identificar que a instrução está com problemas, de forma paralela é feita a chamada via thread do agente reflexivo que tomará nota de informações úteis, como o nome e o código do erro, qual função e qual linha ocorreu o erro, qual código-fonte foi utilizado, horário, enfim, há uma gama de opções que podem serem enviadas, porém nos contentaremos com o essencial. Enquanto isso, a linha de execução principal vai sendo executada, e o agente que faz o envio do e-mail para os responsáveis e interessados é enviado paralelamente, de forma invisível para o usuário, pois psicologicamente ele subentenderá que a equipe de desenvolvimento esteja naquele exato momento verificando o seu erro e retornando o mais breve possível, e muitos sabem que esta não é a realidade em uma softwarehouse. Então para não criar falsas impressões, o envio é invisível e discreto.
Figura 4. Diagrama geral do artigo.
7. Conclusão
Conforme foi deixado claro na introdução, a crescente concorrência entre softwarehouses fica sob domínio dos que dispõem melhores soluções e ferramentas que ajudem seus clientes a gerarem lucros, gerarem controle, gerarem todo um processo de pensar e agir, de forma organizada.Este sistema pode não parecer uma ferramenta que revolucionará uma softwarehouse, porém com toda certeza trará mais habilidades para a equipe de desenvolvimento, mais credibilidade para o suporte, pois terão um breve parecer das informações do bug antes mesmo do cliente entrar em contato e mais valorização moral da empresa pela parte dos clientes e grupos empresariais.
O uso propriamente dito de agentes computacionais comprova o que os autores e entusiastas promovem: desenvolvimento de melhores ferramentas e um melhor controle sobre o software desenvolvido. A concepção deste projeto ficaria distorcida e sua utilidade seria reduzida caso não houvesse o importante papel dos agentes computacionais.
Referências
Sauve, Jacques; Medeiros, Elizabet de. Avaliação do Impacto de Tecnologias da Informação Emergentes nas Empresas. Rio de Janeiro: Editora Qualitymark, 2003.Osse, José Sergio. Falta de mão-de-obra especializada pode impedir desenvolvimento tecnológico no país, diz HP. UOL Economia, 25 Maio 2007. Disponível em: <http://noticias.uol.com.br/economia/ultnot/valor/2007/05/22/ult1913u69449.jhtm>. Acesso em: 28 Maio 2007.
Microsoft Corp. Windows. Sistema operacional. Disponível em: <http://www.microsoft.com/>. Acesso em: 01 Junho 2007.
The Mozilla Organization. BUGZILLA. Apoio para gerenciar desenvolvimento de softwares. Disponível em: <http://www.bugzilla.org/>. Acesso em: 28 Maio 2007.
Pressman, Roger S. Engenharia de Software. 1ª ed., Editora McGraw-Hill, 1995.
Bradshaw, J. M. Software Agents. MIT Press, Cambridge, Massachusetts, 1997.
Feedbacks do EPAC (Encontro Paranaense de Computação) de 2007
"Muito superficial…. sem nenhuma contribuição concreta"
"- Artigo está sem identificação de autores e instituições;
- De acordo com as instruções do congresso, as figuras devem estar em preto e branco;
- De acordo com as instruções do congresso, rótulos de figuras que ultrapassem mais que uma linha devem ser justificados com um recuo de 0,8 em cada margem;
- Palavras em inglês devem estar em itálico;
- Página 5, 3o parágrafo existe a seguinte frase: “Nesta proposta estamos
reportando TODO E QUALQUER ERRO”. Não usar este tipo de afirmação,
pois pode parecer um pouco pretensiosa;
- No item 2, a última frase do segundo parágrafo, bem como o 4o parágrafo todo, estão com texto confuso. Rever as frases;
- Revisar o texto do artigo todo no que diz respeito a concordância verbal,
nominal, acentuação, pontuação, etc. Existem muitos problemas de escrita. Pedir auxílio a alguém caso necessário.
"O artigo está escrito com clareza, didática porém apresenta erros de pontuação. A aplicação é interessante do ponto de vista de Programação e Inteligência Artificial e a idéia é relevante.
O aplicativo é funcional, mas porque não usar um software “made in Brasil” uma vez que o evento é regional e temos muito potencial pra isso???? somente sugestões"
Comentários