ESTÁGIO CURRICULAR I e II MELHORIAS NO MÓDULO DE VENDAS E DISTRIBUIÇÃO DE PRODUTOS DO PRODUTO LOGIX

Transcrição

1 MARCELO NEUMANN ESTÁGIO CURRICULAR I e II MELHORIAS NO MÓDULO DE VENDAS E DISTRIBUIÇÃO DE PRODUTOS DO PRODUTO LOGIX EMPRESA: TOTVS S/A SETOR: SUSTENTAÇÃO SUPERVISOR: JULIANO TEÓFILO CABRAL MAIA ORIENTADOR: EDINO MARIANO LOPES FERNANDES CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS CENTRO DE CIÊNCIAS TECNOLÓGICAS - CCT UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC JOINVILLE SANTA CATARINA - BRASIL NOVEMBRO/2012

2 2 APROVADO EM.../.../... Professor Edino Mariano Lopes Fernandes Mestre em Ciência da Computação Professor Orientador Professor Rafael Rodrigues Obelheiro Doutor em Engenharia Elétrica Professor Rui Jorge Tramontin Junior Doutor em Engenharia Elétrica Juliano Teófilo Cabral Maia Coordenador da CONCEDENTE

3 3 Carimbo da Empresa UNIDADE CONCEDENTE Razão Social: TOTVS S/A CGC/MF: / Endereço: Avenida Santos Dumont, 831 Bairro: Bom Retiro CEP: Cidade: Joinville UF: SC Fone: (47) Supervisor: Juliano Teófilo Cabral Maia Cargo: Coordenador ESTAGIÁRIO Nome: Marcelo Neumann Matrícula: Endereço: Rua Cerro Azul, 713 Bairro: Nova Brasília CEP: Cidade: Joinville UF: SC Fone: (47) Curso de: Tecnologia em Análise e Desenvolvimento de Sistemas Título do Estágio: Melhorias no Módulo de Vendas e Distribuição de Produtos do Produto LOGIX. Período: 10/09/2012 à 05/11/2012 Carga horária: 240 h AVALIAÇÃO FINAL DO ESTÁGIO I e II PELO CENTRO DE CIÊNCIAS TECNOLÓGICAS Representada pelo Professor da Disciplina: CONCEITO FINAL DO ESTÁGIO I e II Excelente (9,1 a 10) Muito Bom (8,1 a 9,0) Bom (7,1 a 8,0) Regular (5,0 a 7,0) Reprovado (0,0 a 4,9) NOTA ETG I (Média do Processo) NOTA ETG II (Média do Processo) Rubrica do Professor da Disciplina Joinville / /

4 4 Nome do Estagiário: Marcelo Neumann QUADRO I AVALIAÇÃO NOS ASPECTOS PROFISSIONAIS QUALIDADE DO TRABALHO: Considerando o possível. ENGENHOSIDADE: Capacidade de sugerir, projetar, executar modificações ou inovações. CONHECIMENTO: Demonstrado no desenvolvimento das atividades programadas. CUMPRIMENTO DAS TAREFAS: Considerar o volume de atividades dentro do padrão razoável. ESPÍRITO INQUISITIVO: Disposição demonstrada para aprender. INICIATIVA: No desenvolvimento das atividades. SOMA Pontos QUADRO II AVALIAÇÃO DOS ASPECTOS HUMANOS ASSIDUIDADE: Cumprimento do horário e ausência de faltas. DISCIPLINA: Observância das normas internas da Empresa. SOCIABILIDADE: Facilidade de se integrar com os outros no ambiente de trabalho. COOPERAÇÃO: Disposição para cooperar com os demais para atender as atividades. SENSO DE RESPONSABILIDADE: Zelo pelo material, equipamentos e bens da empresa. SOMA Pontos PONTUAÇÃO PARA O QUADRO I E II Sofrível - 1 ponto, Regular - 2 pontos, Bom - 3 pontos, Muito Bom - 4 pontos, Excelente - 5 pontos LIMITES PARA CONCEITUAÇÃO AVALIAÇÃO FINAL Pontos De 57 a SOFRÍVEL SOMA do Quadro I multiplicada por 7 De 102 a REGULAR SOMA do Quadro II multiplicada por 3 De 148 a BOM SOMA TOTAL De 195 a MUITO BOM De 241 a EXCELENTE Nome da Empresa: TOTVS S/A. Representada pelo Supervisor: Juliano Teófilo Cabral Maia. CONCEITO CONFORME SOMA TOTAL Rubrica do Supervisor da Empresa Local: Data: Carimbo da Empresa

5 5 UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS - CCT PLANO DE ESTÁGIO CURRICULAR I e II OBRIGATÓRIO ESTAGIÁRIO Nome: Marcelo Neumann Matrícula: Endereço (Em Jlle): Cerro Azul, 713 Bairro: Nova Brasília CEP: Cidade: Joinville UF: SC Fone: (47) marceloneumann@ymail.com Regularmente matriculado no semestre: 2/2012 (5º) Curso: Tecnologia em Analise e Desenvolvimento de sistemas Formatura (prevista) Semestre/Ano: 2/2012 UNIDADE CONCEDENTE Razão Social: Totvs S/A CGC/MF: / Endereço: Av. Santos Dumont, 831 Bairro: Bom Retiro CEP: Cidade: Joinville UF: SC Fone: (47) Atividade Principal: Desenvolvimento Supervisor: Juliano Teófilo Cabral Maia Cargo: Coordenador do Supervisor: maia@totvs.com.br Telefone/Ramal: 3139 DADOS DO ESTÁGIO Área de atuação: Sustentação Departamento de atuação: Vendas Fone: (47) Ramal: 3056 Horário do estágio: 08:00h às 12:00h e 13:30h às 15:30h Total de horas do Estágio: 240 Período: 10/09/2012 à 05/11/2012 Total de horas semanais: 30 Nome do Professor Orientador: Edino Mariano Lopes Fernandes Departamento: Departamento de Ciência da Computação Disciplina(s) simultânea(s) com o estágio Quantas: 6 Quais: Sociologia das Organizações (SOR), SQL (TES-03), Desenvolvimento de Aplicações na Web (TES-04), Análise e Projeto de Sistemas Avançados (TES-12), Programação Paralela (TES-17), Fundamentos de Computação Gráfica (TES-28). OBJETIVO GERAL Fazer a análise e o desenvolvimento de melhorias e retrabalhos no módulo de Vendas e Distribuição de Produtos do produto Logix, utilizando a linguagem 4GL.

6 6 ATIVIDADES OBJETIVO ESPECÍFICO HORAS 1. Treinamento 2. Análise 3. Desenvolvimento 4. Testes 5. Documentação Realizar treinamentos referentes à linguagem utilizada (Informix 4GL), banco de dados (Oracle, Informix) e ao módulo de Vendas do produto Logix. Analisar as ocorrências e/ou sugestões de melhorias reportadas pelos clientes sobre o produto (área de Vendas), verificar a viabilidade e prever as possíveis alterações no código fonte. Fazer o detalhamento conforme um documento padrão pré-estabelecido pela empresa. Desenvolver/codificar o que foi especificado no detalhamento utilizando as ferramentas case, framework, entre outros padrões adotados pela Totvs. Testar se a alteração foi, realmente, efetiva. Verificar o comportamento do programa antes e depois da alteração. Documentar tudo o que foi alterado (telas, regras de negócio, tabelas,...) e escrever de forma clara e objetiva um Release Notes que é entregue ao cliente para que o mesmo fique ciente do que foi alterado no produto. Evidenciar os testes realizados com imagens e/ou vídeos. Mostrar claramente que a situação foi corrigida Assinatura do Aluno Assinatura do Supervisor da Empresa Data: Carimbo da Empresa Data: Assinatura do Profess1or Assinatura do Membro do Assinatura do Coordenador de Orientador Comitê de Estágio Estágio Data: Data: Data:

7 7 CRONOGRAMA FÍSICO E REAL PERÍODO (20 horas) ATIVIDADES Treinamento Análise Desenvolvimento Documentação Testes P R P R P R P R P R P R Legenda: P - Previsto / R - Realizado

8 8 A Deus, Aos meus pais, Hilario e Fatima e meu irmão, Gleison, À minha namorada, Pâmela, E a todos os demais familiares e colegas.

9 9 AGRADECIMENTOS Aos meus pais e familiares que sempre me apoiaram nas minhas decisões, a minha namorada que sempre entendeu e, mais do que isso, me ajudou nos momentos de dificuldades. A todos os colegas que fiz na universidade e no meu trabalho, por todo o companheirismo e contribuição para o meu crescimento. Aos professores por todo o conhecimento repassado, pela atenção oferecida, pelo comprometimento e principalmente pela paciência para com os alunos. A todos que contribuíram direta ou indiretamente com meu crescimento pessoal e profissional. Menção especial a Hilario, Fatima e Gleison Neumann, Pâmela Lópes, Diego Ecker Valtrick, Diego Fernando Venturi, Tânia Mara Moreno e Grupo de Oração Jovem Anjos de Deus.

10 10 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS Geral Específicos Justificativa ORGANIZAÇÃO DO ESTUDO APRESENTAÇÃO DA CONCEDENTE SEGMENTOS PRODUTOS CLIENTES DESENVOLVIMENTO TREINAMENTOS/FERRAMENTAS Informix 4GL e ADVPL Metadados TFS TotvsTec SSIM UltraEdit GOLD Vendas PROCEDIMENTOS Abertura do chamado Análise Codificação e Testes CONCLUSÃO DO CAPÍTULO CONSIDERAÇÕES FINAIS GLOSSÁRIO REFERÊNCIAS BIBLIOGRÁFICAS... 36

11 11 LISTA DE FIGURAS Figura 1. Trecho de código do programa vdp Figura 2. Tela da ferramenta de criação de formulários FRM Figura 3. Tela do TFS Pasta dos códigos-fonte do VDP Figura 4. Tela da IDE TotvsTec Figura 5. Monitor de Tarefas do SSIM Figura 6. Programa VDP8020 aberto no editor de texto UltraEdit Figura 7. Tela Principal do GOLD Figura 8. Opção "Liberação Especial Logix" do GOLD Figura 9. Tela do SSIM (Tele-Atendimento) Figura 10. Tela do VDP8880 (Cadastro de Componentes Antigo) Figura 11. Tela do VDP10150 (Cadastro de Componentes Novo) Figura 12. Tela do SSIM (Controle de Execução) Figura 13. Tela do TFS (Criação de uma Workspace) Figura 14. Tela do programa VDP8020 (Geração de OM X Pedido)... 32

12 12 RESUMO Neste relatório estão descritas as atividades realizadas durante o período de estágio na empresa TOTVS, torre de Sustentação e módulo de Vendas e Distribuição de Produtos, no segundo semestre de Foi realizada uma melhoria no software Logix que levou à prática alguns conceitos de análise, desenvolvimento, testes e documentação de sistemas ensinados na academia. Para isso, a empresa concedeu treinamentos referentes à linguagem de programação usada (Informix 4GL e Metadados), padrões adotados pela empresa, ferramentas mais utilizadas e regras de negócio do módulo de atuação.

13 13 1 INTRODUÇÃO Este relatório expõe todos os passos necessários para realizar uma correção ou melhoria no produto Logix, da empresa TOTVS, e entregar de forma segura para o cliente. Para garantir a efetividade da alteração, é imprescindível o conhecimento da regra de negócio do módulo, o domínio da linguagem de programação e banco de dados, assim como a utilização das ferramentas de desenvolvimento utilizadas pela empresa. Precisa-se identificar qual o impacto da alteração sobre todo o produto para então, prever as possíveis mudanças nos demais módulos. 1.1 OBJETIVOS Geral Realizar a análise e o desenvolvimento de melhorias e retrabalhos no módulo de Vendas e Distribuição de Produtos do produto Logix, utilizando a linguagem 4GL Específicos Realizar treinamentos referentes à linguagem utilizada (Informix 4GL), banco de dados (Oracle e Informix) e ao módulo de Vendas do produto Logix Analisar as ocorrências e/ou sugestões de melhorias reportadas pelos clientes sobre o produto (área de Vendas), verificar a viabilidade e prever as possíveis alterações no código-fonte. Fazer o detalhamento conforme um documento padrão pré-estabelecido pela empresa. Desenvolver/codificar o que foi especificado no detalhamento utilizando as ferramentas CASE, framework, entre outros padrões adotados pela Totvs. Testar se a alteração foi realmente efetiva. Verificar o comportamento do programa antes e depois da alteração. Documentar tudo o que foi alterado (telas, regras de negócio, tabelas,...) e escrever de forma clara e objetiva um Release Notes que é entregue ao cliente para que o mesmo fique ciente do que foi alterado no produto. Evidenciar os testes realizados com imagens e/ou vídeos. Mostrar claramente que a situação foi corrigida Justificativa A vida acadêmica proporciona o conhecimento teórico, mas nem sempre provê as atividades práticas necessárias para o pleno desenvolvimento do acadêmico. A realização desse

14 14 estágio proporcionará o ganho de experiência na área de análise e desenvolvimento de sistemas, contribuindo para a formação de um profissional de qualidade. Grandes sistemas, como os de gestão empresarial, estão mais propensos a falhas de programação devido à sua complexidade. Além disso, várias alterações se fazem necessárias por motivos legais: adaptação do sistema a um novo processo ou a uma nova lei, por exemplo. Para isso, a Totvs mantém uma equipe denominada Sustentação, composta por profissionais graduados e experientes e estagiários, sendo que estes, com o objetivo de preparação para o trabalho e integração ao ambiente organizacional. Essa equipe é responsável pelas alterações posteriores à venda do software. O estágio nessa área proporcionará ao acadêmico: aprender técnicas e estratégias para a realização de uma boa análise sobre ocorrências reportadas pelos clientes em relação ao sistema; compreender algumas regras de negócio, procedimentos e tecnologias; absorver conceitos relacionados, principalmente, aos sistemas de gestão empresarial. 1.2 ORGANIZAÇÃO DO ESTUDO O presente documento está dividido da seguinte forma: Capítulo 1: Aborda a introdução, objetivos gerais e específicos, justificativa do estágio e a organização do estudo. Capítulo 2: Traz informações sobre a empresa concedente do estágio, como um breve resumo de sua história, alguns dos principais produtos ofertados e seus maiores clientes. Capítulo 3: Detalha todas as atividades desenvolvidas durante o estágio, explicando as regras de negócio envolvidas no processo.

15 15 2 APRESENTAÇÃO DA CONCEDENTE A TOTVS é uma empresa multinacional de software, serviços e tecnologia. Fundada em 1983 por Laércio Cosentino e Ernesto Haberkorn, com a criação da Microsiga Softwares S/A, só passou a se chamar TOTVS após a aquisição da Logocenter, em 2005 (TOTVS). É a 6ª maior fabricante de softwares aplicativos do mundo, sendo líder absoluta no Brasil, com mais de 50% de participação de mercado e na América Latina, com 35%. Conta aproximadamente com 10 mil colaboradores e está presente em 23 países por meio de unidades e franquias (TOTVS). 2.1 SEGMENTOS Para atender todos os portes e tipos de empresa, a TOTVS possui uma ampla variedade de produtos e serviços, com soluções para 10 segmentos (TOTVS): 1. Agroindústria; 2. Construção e Projetos; 3. Distribuição e Logística; 4. Educacional; 5. Financial Services; 6. Jurídico; 7. Manufatura; 8. Saúde; 9. Serviços; 10. Varejo. 2.2 PRODUTOS Atualmente a TOTVS oferece ao mercado soluções administrativas, sistêmicas, de processos, de desempenho e de infraestrutura. Os produtos da TOTVS fornecem serviços de BI (Business Intelligence), CRM (Customer relationship management), ERP (Enterprise resource planning), NFE (Nota Fiscal Eletrônica), entre outros. A empresa criou uma própria rede social, inicialmente denominada byyou, onde o usuário possui dois perfis (um pessoal e um corporativo) em uma mesma rede, proporcionando troca de conhecimentos tanto no âmbito pessoal como no profissional. O byyou está sendo usado pelos colaboradores e clientes, mas já começou a ser ofertado no mercado.

16 16 A principal solução da empresa é o ERP, que atualmente está subdividido em produtos, reflexo da aquisição de várias empresas concorrentes. Um dos produtos ofertados é o Logix (herdado com a aquisição da Logocenter) que atende clientes dos mais diversos setores. 2.3 CLIENTES A TOTVS possui mais de 26 mil clientes ativos. Destacam-se: Tigre; ALL América Latina Logística; Urbano; Fundição Tupy; Marcegaglia do Brasil; Vinícola Perini; Marfrig; Timac; Víqua; Klin.

17 17 3 DESENVOLVIMENTO Neste capítulo estão descritas todas as atividades realizadas até o momento da elaboração deste relatório. Durante o período do estágio foram realizadas atividades relacionadas a melhorias não faturadas no produto Logix. A TOTVS oferece suporte aos seus clientes, permitindo que os mesmos informem caso haja alguma inconformidade no produto e também sugiram melhorias. Uma melhoria é avaliada quanto à sua utilidade. Se for útil para todos os clientes, é classificada como não faturada e, portanto, não é cobrada do cliente. Do contrário, torna-se faturada, onde o mesmo deve pagar pelos serviços prestados. Com o intuito de capacitar o profissional para a realização das atividades, foram concedidos treinamentos. 3.1 TREINAMENTOS/FERRAMENTAS Os treinamentos realizados na empresa foram através de manuais, gravações em vídeo e atividades presenciais. De modo geral, os assuntos abordados foram as linguagens de programação, ferramentas de desenvolvimento e regras de negócio do módulo VDP (Venda e Distribuição de Produtos). A seguir, descrevem-se brevemente os assuntos abordados nos treinamentos Informix 4GL e ADVPL O Informix 4GL é uma linguagem de programação de quarta geração desenvolvida pela Informix Corporation, em 1986 (Wikipedia). Uma das maiores facilidades que a linguagem proporciona é a interação direta com banco de dados, tornando possível incluir qualquer operação de banco diretamente no código-fonte (Figura 1). Isso ajuda no entendimento, agiliza a análise e acelera muito o desenvolvimento de programas (estimado em 10 a 20 vezes mais rápido que as linguagens de 3ª geração (Manual 4GL)). Assim como grande parte das linguagens de programação, o programa é iniciado em uma função MAIN e pode conter várias funções e variáveis. As variáveis podem ser definidas como: Globais: podem ser modificadas por qualquer função (externa ou interna) que o programa chamar; Modulares: podem ser usadas por qualquer função interna do programa; Locais: somente utilizadas dentro da função onde foi definida.

18 18 As telas e seus componentes são gerenciados com a utilização da linguagem de programação ADVPL (Advanced Protheus Language), desenvolvida pela própria TOTVS enquanto Microsiga. O leiaute da tela e algumas características dos campos são definidos em um arquivo de extensão PER. Em busca da independência de plataforma, a TOTVS criou seu próprio ambiente de trabalho, denominado Protheus, que deu origem ao conceito de RPO (Repositório Protheus de Objetos). Um código-fonte compilado é salvo em um repositório junto aos demais já compilados. Com isso, um programa pode chamar qualquer outra função que, em tempo de execução, será procurada no RPO. Figura 1. Trecho de código do programa vdp Fonte PRIMÁRIA, Metadados Segundo Ikematu (2001), Metadados são dados que descrevem atributos de um recurso.. Comumente é definido como dados sobre dados. Visando agilizar ainda mais o processo de desenvolvimento do sistema, principalmente a construção das telas, a TOTVS desenvolveu uma ferramenta CASE intitulada Metadados, que basicamente é um ambiente onde o usuário indica quais as tabelas do banco de dados o seu programa vai cadastrar e quais as colunas deverão aparecer em tela e a tela é construída automaticamente. Essa ferramenta além de ser muito intuitiva, possui vários recursos interessantes, inclusive validações em campos e manipulações de tabelas do banco de dados. A tela construída, também chamada de formulário, é gravada em um arquivo de extensão XML e, para ser executada, faz-se necessário ter um código-fonte escrito com linguagem 4GL/ADVPL que referencie esse formulário.

19 19 Outra vantagem de se utilizar essa tecnologia é a padronização das telas e mensagens de inconsistências, pois a própria ferramenta monta os componentes da tela e sugere algumas mensagens para consistir um campo obrigatório, por exemplo. Caso haja necessidade, o desenvolvedor consegue alterar as mensagens e até mesmo a tela, mas, por padrão, deixam-se as pré-estabelecidas. Além da construção de formulários, a ferramenta permite que se criem tabelas, zoom para campos da tela e barras de ferramentas. A Figura 2 mostra o ambiente FRM0002, responsável pelo cadastro de formulários cadastrais, que são os programas responsáveis pela manipulação de tabelas TFS O TFS (Team Foundation Server) é uma plataforma de gerenciamento de arquivos, oferecida pela Microsoft (Microsoft). Essa ferramenta CASE é utilizada na TOTVS para controle dos projetos e arquivos. Ela garante o controle de versões, a rastreabilidade e a segurança das alterações. Figura 2. Tela da ferramenta de criação de formulários FRM0002. Fonte PRIMÁRIA, Nessa ferramenta, o analista inclui o documento com a alteração a ser realizada, o responsável pela codificação visualiza o mesmo e busca os arquivos a serem alterados, reservando-os para que mais ninguém consiga efetivar alguma versão antes da sua alteração. Ao

20 20 finalizar, o desenvolvedor efetiva a alteração no TFS, que incrementa a versão do arquivo e grava o anterior em um histórico que pode ser consultado posteriormente. Para auxiliar a rastreabilidade das alterações, o TFS obriga o desenvolvedor a associar a sua alteração a algum chamado e descrever brevemente o que foi realizado naquela versão. Esses registros são muito úteis, principalmente para as pessoas que trabalham no atendimento ao cliente, pois é possível verificar quando, onde e quem fez a mudança no programa. A Figura 3 mostra os arquivos contidos na pasta programas, do módulo Vendas, da versão 10R2-11R0 do produto Logix. No painel à direita, temos cinco colunas, a primeira indica Figura 3. Tela do TFS Pasta dos códigos-fonte do VDP Fonte PRIMÁRIA, o nome do arquivo (neste exemplo são todos códigos-fonte no formato 4GL). A segunda indica o seu estado, se a coluna não estiver preenchida significa que o arquivo está livre para ser alterado e se estiver como lock, edit, está sob o controle de algum usuário que ainda está alterando o mesmo. Após ser efetivada a alteração, o arquivo passa para o estado lock, permanecendo assim até a liberação do chamado relacionado. A terceira coluna se refere ao usuário que alterou ou está alterando o arquivo. A quarta indica se foi feita um cópia do arquivo na máquina local e

21 21 se a mesma está atualizada. Por último se tem a informação da data e hora da última alteração realizada TotvsTec TotvsTec é uma IDE (Integrated Development Environment ou Ambiente Integrado de Desenvolvimento) desenvolvida pela própria TOTVS, que possibilita a organização de projetos, edição de códigos-fontes, compilação de programas e telas, depuração de programas, entre outras funcionalidades. A interface padrão é mostrada na Figura 4. A criação dessa IDE (também conhecida por TOTVS Dev Studio) foi um grande passo dado pela empresa, pois reduziu muito o custo da geração e manutenção do sistema tanto nela quanto nos seus clientes, pois dependia-se de tecnologias de terceiros para compilar e executar os programas. No produto Logix, o compilador TotvsTec dá origem a um programa executável (de extensão 4go ou 4gi) que é interpretado em tempo de execução (Manual TotvsTec). Figura 4. Tela da IDE TotvsTec. Fonte PRIMÁRIA, 2012.

22 SSIM Com o intuito de controlar o atendimento aos clientes, a TOTVS optou por trabalhar com o sistema de chamados, onde o cliente reporta a sua dúvida, sugestão ou crítica e é atendido por um profissional especializado (esse processo é detalhado na seção 3.2). Para gerenciar esses chamados, utiliza-se o Protheus 10 SSIM (Suport System Integration Manager), desenvolvido internamente com o intuito de facilitar o controle e o relacionamento entre o cliente, a equipe de atendimento e a equipe de manutenção do sistema. Outros recursos proporcionados por esta ferramenta: apontamento de horas, histórico das interações do cliente com a equipe de atendimento, construção de gráficos de Gantt, gerenciador de tarefas, divisão de tarefas por filiais e integração com o TFS. Na Figura 5 tem-se o Monitor de Tarefas do SSIM de um usuário (também conhecido por recurso). Neste exemplo existem quatro atividades, a primeira indicando Reunião, a segunda Apoio N1, a terceira Apoio N4 e por fim a atividade do chamado TERQOW. Como mencionado anteriormente, o apontamento de horas é feito automaticamente pela ferramenta, bastando apenas executar uma das tarefas presentes no Monitor de Tarefas. Por isso, surgiu a necessidade de incluir atividades auxiliares, como as três primeiras desse exemplo. A atividade de reunião é apontada quando o recurso estiver participando de alguma reunião ou treinamento. Apoio indica que o usuário está ajudando alguém, N1 da própria equipe e N4 de outra. A última atividade refere-se ao chamado que está pendente com o recurso. Figura 5. Monitor de Tarefas do SSIM Fonte PRIMÁRIA, 2012.

23 UltraEdit Outra ferramenta utilizada no produto Logix é o UltraEdit, um editor de texto comercial criado pela IDM Computer Soluctions, em 1994, que possui muitos recursos para programadores. Com ele o desenvolvedor tem liberdade para incluir macros, configurar e realçar sintaxes, converter arquivos em vários formatos, editar arquivos via FTP (File Transfer Protocol), abrir arquivos em abas entre outras utilidades (Ultraedit). A Figura 6 mostra sua interface, destacando-se o painel à direita onde são exibidas todas as funções do código-fonte aberto. É um editor leve e simples, além de ser flexível em relação aos sistemas operacionais. Há versões que funcionam em Windows, Linux e MacOS, muito útil quando se utiliza máquinas virtuais com sistemas diferentes máquina virtual Linux no Windows, por exemplo. Figura 6. Programa VDP8020 aberto no editor de texto UltraEdit. Fonte PRIMÁRIA, GOLD Com o intuito de organizar e padronizar alguns procedimentos, a TOTVS desenvolveu o GOLD (Gerenciador de Objetos Logix e Datasul) voltado aos produtos Logix e Datasul, ilustrado na Figura 7.

24 24 Para garantir a qualidade da resolução de um chamado, o mesmo passa por uma série de atividades de testes e documentação, o que faz com que retarde a liberação e disponibilização da alteração aos clientes. Em alguns casos, não é possível aguardar todo o tempo para realizar o ajuste ou correção no sistema do cliente, faz-se então uma liberação especial do chamado para ele. A liberação especial é feita através do envio de um patch que, basicamente, é um arquivo com todos os artefatos alterados no chamado para o cliente atualizar em seu RPO. O GOLD facilita esse trabalho, nele você inicia e finaliza o desenvolvimento de um chamado, automaticamente a ferramenta busca no TFS quais os fontes foram alterados no chamado e monta o patch. Figura 7. Tela Principal do GOLD Fonte PRIMÁRIA, Caso haja a necessidade, o usuário pode publicar o chamado para o cliente apenas clicando na opção Publicar, na tela de Liberação Especial (Figura 8). Além disso, essa ferramenta é integrada aos cadastros do Metadados, tornando muito mais prática a exportação de formulários criados nessa tecnologia. O GOLD possui o conceito de pré-requisito. Em alterações mais complexas, que impactem várias rotinas como, por exemplo, a alteração de uma tabela do banco de dados, o chamado deve ser marcado como pré-requisito. Marcando-o com esta opção, se algum outro

25 25 chamado utilizar algum artefato alterado neste, ao fazer a liberação especial desse outro chamado, automaticamente o GOLD enviará a outra correção (marcada como pré-requisito). Figura 8. Opção "Liberação Especial Logix" do GOLD Fonte PRIMÁRIA, Vendas Vendas é um módulo muito extenso e complexo que engloba muitos conceitos e rotinas. Em uma visão geral, compreende o cadastro de clientes e fornecedores, a inclusão de pedidos, a geração de ordens de montagem e o faturamento de notas fiscais. Pelo fato de existir inúmeros detalhes e parâmetros, foi feito um treinamento presencial que abordou as principais rotinas: pedido, ordem de montagem e faturamento. Para incluir um pedido é necessário informar, principalmente, o cliente, a natureza de operação, a condição de pagamento, o tipo de frete e de entrega e os itens do pedido. Após incluir um pedido, deve ser gerada uma OM (Ordem de Montagem) para ele. Em termos de cadastro, é a rotina mais simples, mas em processamento é uma das mais importantes. A ordem de montagem, também conhecida por romaneio, consiste em verificar as informações do pedido, reservar os itens no estoque, se necessário, e organizá-los nos caminhões levando em consideração o tamanho e o peso da carga e buscando juntar cargas que terão a mesma rota. O estoque dos itens pode ser controlado pelo Logix, quando isso acontece, a OM também faz a reserva do item, indicando o local exato do mesmo no estoque. Após a geração, deve-se incluir uma solicitação de faturamento, onde são indicadas algumas informações de caráter legal, como série, subsérie, tipo e espécie da nota fiscal. Somente após a inclusão dessa solicitação de faturamento é que pode ser gerada a nota fiscal.

26 PROCEDIMENTOS Neste capítulo são relatados os procedimentos realizados desde o processo de abertura até o envio do chamado TEGL09 para a atividade de Teste Unitário Abertura do chamado Um cliente abriu esse chamado reportando a seguinte situação: (...) Foi atualizado o pacote 3 e 4 e conforme o chamado TDTYUK estaria resolvido o problema de saldo do estoque no momento da geração da OM. Foi feito os testes e não esta funcionando. (...). A TOTVS trabalha com o sistema de pacotes de atualizações (ao qual o cliente se refere) que normalmente são disponibilizados aos clientes a cada trimestre. O objetivo de utilizar esse sistema é manter os clientes com o software sempre atualizado. Em sistemas complexos como o ERP Logix, é comum encontrar pequenas inconformidades em alguns programas ou rotinas. Portanto, para não liberar todas as alterações na medida em que são finalizadas, as mesmas são agrupadas e enviadas em um único patch, facilitando a atualização do sistema e gerando menos transtorno ao cliente. Retomando ao chamado, o primeiro atendimento foi realizado pela equipe de consultoria que verificou as versões dos códigos-fonte que o cliente estava usando e classificou o incidente Figura 9. Tela do SSIM (Tele-Atendimento) Fonte PRIMÁRIA, 2012.

27 27 como uma não conformidade do produto que impedia a operação do programa, mas com saída contorno. Automaticamente o SSIM alterou o grau de criticidade do chamado para Médio. A Figura 9 mostra a consulta do chamado TEGL09 na opção Tele-Atendimento do SSIM, no painel inferior estão todas as interações feitas nele. Nesse painel é possível consultar os textos e os anexos incluídos tanto pelo cliente quanto por funcionários. Ao finalizar o atendimento, o chamado é enviado à equipe de desenvolvimento para que seja feita a correção no sistema. Primeiramente o chamado fica sob a responsabilidade do líder da equipe, este deve planejar todas as próximas atividades, informando quais recursos serão responsáveis por quais atividades. Finalizado o planejamento, encerra-se essa atividade, criando a de Especificar Procedimentos do Sistema no Monitor de Tarefas do recurso definido pelo líder. O recurso responsável por essa etapa é chamado de analista do chamado Análise Ao iniciar a atividade de Especificar Procedimentos do Sistema, primeiramente deve ser consultado o histórico do chamado no SSIM (opção Tele-Atendimento ). Caso seja constatado que o cliente está com versões muito anteriores à atual do programa com a inconsistência, é importante consultar o histórico de alterações do programa no TFS, visando encontrar alguma alteração realizada que pudesse solucionar o problema ou então encontrar a alteração que originou o mesmo. Caso não haja correções disponibilizadas no TFS, deve-se contatar a pessoa que fez o primeiro atendimento com o intuito de buscar mais informações. Isso se faz necessário porque os contatos telefônicos não ficam registrados no SSIM. Nesse chamado, só foi identificada a real necessidade do cliente após o contato com a equipe de atendimento. A situação reportada era pertinente à geração de ordem de montagem de um pedido, que não mostrava corretamente a quantidade disponível em estoque para alguns itens com componentes. Um pedido é composto por itens, e um item pode ser um serviço ou um produto. Caso seja um produto, pode ter grade e/ou componentes. A grade foi implementada para agrupar itens. Uma grade é uma característica como uma cor ou um tamanho. Por exemplo: uma empresa que vende camisas somente com cores e tamanhos diferentes não precisa cadastrar um item para cada cor e tamanho ( CAMISA AZUL P, CAMISA PRETA P, CAMISA PRETA M,...) basta cadastrar o item CAMISA e atribuir as grades COR e TAMANHO a ela. Um item do Logix suporta até 5 grades.

28 28 No módulo de Vendas do Logix, um item pode ser composto por outros, conforme o exemplo: um item CARRO é composto por 5 itens PNEU, 1 item MOTOR, 1 item VOLANTE e outros itens. No momento da venda, não serão vendidos os itens separadamente Figura 10. Tela do VDP8880 (Cadastro de Componentes Antigo) Fonte PRIMÁRIA, e sim, o item CARRO, que contém todos. Para relacionar um item com seus componentes, tem-se o programa VDP8880 (Figura 10). Inicialmente, não foi imaginado que poderia haver casos onde um item pode ter grade e componentes. Após a criação e liberação do VDP8880 surgiu essa necessidade. Portanto, foi desenvolvido outro programa com o mesmo objetivo, o VDP10150 (Figura 11), porém com suporte ao conceito de grade. Como o primeiro já estava liberado e já havia clientes o utilizando, optou-se por manter os dois cadastros. Dois cadastros diferentes, em duas tabelas diferentes, para o mesmo fim prejudica muito o processo de análise dos programas envolvidos, pois se faz necessário o cuidado para que a alteração funcione independentemente da forma de estrutura utilizada. O processo de análise do chamado TEGL09 foi extenso, pois além de ser necessário esse cuidado com os dois cadastros, a complexidade da alteração em termos de código era grande e a solução mais simples seria bastante trabalhosa.

29 29 Definida a possível solução, era preciso montar um arquivo de especificação, onde o analista do chamado mostra alguns itens importantes para as próximas atividades, como por exemplo: Figura 11. Tela do VDP10150 (Cadastro de Componentes Novo) Fonte PRIMÁRIA, Objetivo do chamado: resumo do que será alterado; Alteração na regra de negócio: detalha o impacto da alteração na regra de negócio, mostra como era antes e como ficará depois da alteração; Detalhamento técnico: indica quais fontes serão alterados e sugere uma possível alteração, assim como o número de horas necessárias para codificar o chamado. Release Notes: todo o chamado deve possuir um texto escrito em linguagem simplificada sobre as alterações realizadas, que será enviado ao cliente que abriu o chamado. O texto deve possuir as rotinas alteradas, o incidente e a implementação. Plano de teste: indica como deverá ser feito o teste, quais os cadastros, parâmetros, configurações necessárias para simular o erro. Deve mostrar o que acontece antes e o que deverá acontecer após a alteração. A especificação, também chamada de orçamento, é enviada ao líder da equipe para que o mesmo avalie a dificuldade da alteração e direcione para a pessoa que ele julgar mais apta para realizar a codificação.

30 30 Para finalizar a etapa de especificação é necessário incluir uma pasta no TFS com o código do chamado e inserir o arquivo dentro da mesma. Em seguida, ir ao SSIM e finalizar a atividade referente ao chamado, informando 100% no campo de percentual executado, conforme mostra a Figura 12. Finalizando essa etapa, será criada automaticamente a atividade Codificar Componentes/Programa no Monitor de Tarefas da pessoa responsável pela codificação do chamado. Figura 12. Tela do SSIM (Controle de Execução) Fonte PRIMÁRIA, Codificação e Testes Para iniciar o processo de codificação de um chamado, primeiramente se faz necessário executar a tarefa no SSIM, procurar o arquivo com a especificação do chamado e reservar os códigos-fonte a serem alterados no TFS. No chamado TEGL09 foi previsto alterar os arquivos VDP8020.4gl e VDP1020.4gl. Para reservar um arquivo, primeiramente se cria uma workspace nova no TFS, mapeando o local do arquivo em sua máquina local (Figura 13). O passo seguinte é criar uma cópia local do arquivo a ser alterado e, em seguida, escolher a opção Check Out for Edit..., que fará a reserva do mesmo. Após estar com todos os arquivos em edição, deve-se ir ao GOLD e iniciar o desenvolvimento do chamado informando a respectiva workspace e, então, começa-se a codificação.

31 31 Figura 13. Tela do TFS (Criação de uma Workspace) Fonte PRIMÁRIA, Neste chamado foi identificada a necessidade da inclusão de alguma lógica, para que o programa de geração de ordem de montagem por pedido (VDP8020) considerasse a reserva dos itens componentes ao informar a quantidade a reservar de um item, descontando o saldo em estoque dos demais. Por exemplo, uma empresa pode vender um item celular que possui os componentes aparelho e carregador, mas no mesmo pedido pode ser vendido o carregador separadamente, totalizando 2 carregadores e 1 aparelho. Supondo que no estoque há somente 1 carregador e 1 aparelho, no programa de geração da ordem de montagem, ao informar que será reservado 1 celular, o saldo em estoque do item carregador deverá ser zerado, impedindo que o usuário informe a quantidade a reservar do mesmo. A lógica que foi implementada consistiu na criação de uma tabela temporária para armazenar o saldo em estoque, a quantidade reservada e a necessária de todos os itens do pedido. Ao buscar as informações dos itens do pedido, o programa carrega a tabela temporária que é atualizada conforme a interação do usuário no campo Qtd reserv (Figura 14). O código-fonte alterado possuía cerca de 8500 linhas e se tratava de uma rotina crítica e pesada, o que dificultou ainda mais o processo de codificação. Foi preciso um cuidado especial em relação ao desempenho do programa, visto que a base de dados dos clientes é muito superior à utilizada nos testes internos. Um dos cuidados foi a definição de uma variável para indicar se o pedido possui algum item com componente, caso não haja nenhum item nessas condições, é

32 32 atribuído um valor à variável, fazendo com que o programa desconsidere a tabela temporária, poupando processamentos desnecessários, como o carregamento e atualização da mesma. Ao finalizar a codificação iniciou-se o processo de testes, onde foi preciso resgatar do documento de especificação o plano de testes e montar a base de dados. Para montar a base, primeiramente foram cadastrados alguns itens (no programa MAN9922), em seguida os mesmos foram relacionados no cadastro de componentes (VDP8880), depois foi incluído saldo em estoque (SUP0710) e só então criado o pedido (VDP03134) utilizando os itens cadastrados. Com o cenário pronto, bastava apenas interagir com o programa de geração de ordem de montagem (VDP8020) conferindo se o programa faz as consistências e mostra o saldo do item corretamente. Figura 14. Tela do programa VDP8020 (Geração de OM X Pedido) Fonte PRIMÁRIA, Todo o processo de teste deve ser devidamente evidenciado. O procedimento adotado como padrão da Sustentação do Logix é um documento com imagens que mostram todos os programas executados, detalhando as operações realizadas, o banco de dados utilizado e as parametrizações do sistema. Esse documento deve ser inserido no SSIM na etapa de Codificação e será vistoriado pelas pessoas responsáveis pelas etapas de testes, executadas antes da liberação oficial do chamado.

33 33 Após anexar as evidências de teste ao chamado, deve ser feito o Check In dos arquivos alterados no TFS. Em seguida, é necessário finalizar o desenvolvimento do chamado no GOLD e gerar um patch com os objetos do mesmo. Neste chamado, foi preciso publicar a correção para o cliente antes da liberação oficial, pois o mesmo solicitou e se prontificou a ajudar com os testes. O cliente atualizou e retornou positivamente, pedindo a efetivação da alteração. Então, a atividade já poderia ser encerrada. Para encerrá-la, basta ir ao SSIM e finalizar a tarefa pertinente ao chamado, enviando o mesmo para a etapa de Testa Analista. Nesta próxima atividade foi feito um teste mais aprofundado e completo da alteração e, portanto, não pôde ser alocada para a mesma pessoa que fez a codificação. Em paralelo com a atividade de Teste Analista é gerada outra, Revisar Documentação, responsável por corrigir o Release Notes e incluí-lo em um documento que será disponibilizado para os clientes através dos pacotes de atualizações do produto. Após a aprovação destas, é criada mais uma atividade, a de Realizar Teste Integrado, onde o chamado é testado em um banco de dados diferente (geralmente nos primeiros testes é utilizado o banco Oracle e no integrado, SQL Server ou Informix) e com uma base de dados muito maior, visando se aproximar à realidade dos clientes. Assim que o responsável por este último teste aprovar, o chamado é disponibilizado oficialmente ao cliente solicitando retorno quanto à efetividade da alteração. Caso o mesmo não responder o aceite da solução em 15 dias, o chamado é encerrado automaticamente. 3.3 CONCLUSÃO DO CAPÍTULO Neste capítulo foram relatadas as atividades realizadas no decorrer do estágio na empresa. Iniciou-se com embasamentos sobre as linguagens de programação utilizadas, em seguida foram identificadas as ferramentas de análise e desenvolvimento e, posteriormente, houve o treinamento referente à área de vendas. Foi detalhado também, o processo de solução do chamado utilizado para demonstração dos procedimentos de alteração no software.

34 34 CONSIDERAÇÕES FINAIS É importante citar neste relatório a contribuição do curso de Tecnologia em Análise e Desenvolvimento de Sistemas durante o estágio. Destacam-se as disciplinas voltadas à lógica e linguagem de programação, principalmente Introdução à Ciência da Computação e Estrutura de Dados, que foram imprescindíveis no desenvolvimento das atividades na empresa, visto que a atuação foi também na codificação de programas. Conceitos de análise de sistemas, análise de requisitos e testes unitários, adquiridos na disciplina de Engenharia de Software, também foram utilizados, assim como a ideia alimentada em Análise de Sistemas de que o cliente geralmente não sabe exatamente o que precisa. Por último, destaca-se a importância de Banco de Dados, já que é um pré-requisito para trabalhar em sistemas grandes, principalmente em um ERP. Atuar em uma empresa de porte grande e líder do setor de sistemas gerenciais traz benefícios para um profissional da área de tecnologia. A experiência que se adquire durante um processo de estágio justifica muitas teorias e conceitos ensinados no curso. Absorver técnicas não demostradas na academia, compreender regras de negócio e desenvolver o potencial de análise são atividades importantes realizadas durante um estágio.

35 35 GLOSSÁRIO Artefatos: Arquivos contidos em um chamado. CASE: Computer Aided Software Engineering. Chamados: Ocorrências reportadas pelos clientes, geralmente correções, dúvidas ou melhorias no sistema. Check Out: Reservar um arquivo no TFS. Check In: Efetivar uma versão de algum arquivo no TFS. Compilação: Junção de programas, tradução de linhas de código para alguma linguagem de baixo nível (linguagem de máquina). Depuração: Visualização da execução do programa linha por linha. Grau de criticidade: Severidade da ocorrência (Planejada, Baixa, Média, Alta ou Crítica) Patches: Arquivos com programas executáveis que localizam e sobrescrevem arquivos antigos. Sustentação: Nomenclatura dada às áreas da TOTVS que têm relação com o suporte e manutenção do produto. Workspace: Espaço de trabalho, onde são feitas manipulações nos arquivos no TFS. Zoom: Tela de pesquisa de algum campo do formulário, que traz as informações préestabelecidas para que sejam selecionadas.

36 36 REFERÊNCIAS BIBLIOGRÁFICAS TOTVS. Quem somos. Disponível em: Acesso em: 15 de outubro de Segmentos. Disponível em: Acesso em: 15 de outubro de WIKIPÉDIA Informix 4GL. Disponível em: Acesso em: 18 de outubro de ADVPL. Disponível em: Acesso em: 18 de outubro de Microsoft Team Foundation Server. Disponível em: Acesso em: 26 de novembro de TOTVS TDN Manual de uso da Ferramenta SSIM. Disponível em: Acesso em: 18 de outubro de TOTVS Development Studio. Disponível em: +Development+Studio. Acesso em: 18 de outubro de Metadados. Disponível em: Acesso em: 18 de outubro de Moredata. Programação em Informix 4GL. Disponível em: Acesso em: 18 de outubro de Ultraedit. Produtos Disponível em: Acesso em: 25 de outubro de IKEMATU, R. S. Gestão de metadados: sua evolução na tecnologia da informação. Data Grama Zero - Revista de Ciência da Informação, v. 2, n. 6, dez