UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RELATÓRIO DE ESTÁGIO SUPERVISIONADO

Transcrição

1 UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RELATÓRIO DE ESTÁGIO SUPERVISIONADO GILBERTO COLOGNESE VALANDRO FILHO CUIABÁ MT 2011

2 UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO RELÁTORIO DE ESTÁGIO SUPERVISIONADO GILBERTO COLOGNESE VALANDRO FILHO Relatório apresentado à Coordenação do Curso de Ciência da Computação da Universidade Federal de Mato Grosso, para obtenção do título de Bacharel em Ciência da Computação. CUIABÁ MT 2011

3 UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO GILBERTO COLOGNESE VALANDRO FILHO Relatório de Estágio Supervisionado apresentado à Coordenação de Estágio como uma das exigências para obtenção do título de Bacharel em Ciência da Computação da Universidade Federal de Mato Grosso Aprovado por: Prof. Dr. João Paulo Ignácio Ribas Instituto de Computação (Coordenador do Estágio Supervisionado) Prof. Dr. Jésus Franco Bueno Instituto de Computação (Orientador) Prof. Nelcileno Virgílio de Souza Araújo Instituto de Computação (Professor Convidado) Tânia Bueno de Menezes Almeida dos Santos SUPERVISOR

4 DEDICATÓRIA A Deus graças pela fidelidade À minha família pelo incentivo e confiança Aos amigos pela cumplicidade, companheirismo e por todo apoio

5 SUMÁRIO LISTA DE FIGURAS... 6 LISTA DE SIGLAS E ABREVIATURAS... 7 TÍTULO... 8 RESUMO... 8 INTRODUÇÃO REVISÃO DE LITERATURA MODELO DE PROCESSO DE SOFTWARE ITERATIVO E INCREMENTAL GESTÃO DE PROCESSOS FERRAMENTA DE DESENVOLVIMENTO GENEXUS MATERIAS, TÉCNICAS E MÉTODOS RESULTADOS DIFICULDADES ENCONTRADAS CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 30

6 6 LISTA DE FIGURAS Figura 1. Diagrama do Ciclo de Vida Iterativo e Incremental Figura 2. Representação em tabela das ênfases atribuídas a cada fase do desenvolvimento. Campos mais escuros indicam maior ênfase Figura 3. Tela do sistema Eventum exibindo alguns chamados em seus diversos status Figura 4. Tela de abertura de um Novo Chamado e dos campos a serem preenchidos Figura 5. Fluxograma do PDMS do Setor de Operações Continuadas Figura 6. Tela de uma Nova Nota Interna Figura 7. Apontamento de Tempo gasto com diferentes atividades Figura 8. Print da ferramenta Share Point, exibindo a sessão do Projeto Safira Figura 9. Interface do Menu Principal do Sistema SAFIRA da prefeitura de Canoas/RS Figura 10. Ferramenta Genexus 3.0 exibindo uma das principais telas do Modelo SAFIRA Figura 11. Gráfico referente aos dados da Tabela

7 7 LISTA DE SIGLAS E ABREVIATURAS LTDA Limitada GUI Graphical User Interface Interface Gráfica do Usuário PDMS Processo de Desenvolvimento e Manutenção de Software SGQ ISO CASE Sistema de Gestão da Qualidade International Organization for Standardization Organização Internacional para Padronização Computer Aided Software Engineering Engenharia de Software Auxiliada por Computador

8 8 O Ciclo de Vida do Software SAFIRA, com foco na Fase de Implementação Autor: Gilberto Colognese Valandro Filho Orientador: Prof. Dr. Jésus Franco Bueno Supervisor: Tânia Bueno de Menezes Almeida dos Santos RESUMO Este Relatório de Estágio Supervisionado foi desenvolvido com o intuito de explicitar todo o conteúdo pertinente ao período de estágio cumprido na empresa Ábaco Tecnologia de Informação LTDA. As atividades executadas na empresa durante o período de estágio se referem a atividades de Implementação de software. Este software se trata do Modelo SAFIRA, um Modelo de Execução Orçamentária, Contábil e Financeira, implantado em seis diferentes prefeituras municipais distribuídas pelo Brasil. O setor que gerencia este sistema em especial e mais uma série de outros sistemas é o Setor de Operações Continuadas, que segue a metodologia do Modelo de Processo de Software Iterativo e Incremental para administrar o andamento de todos os processos pelos quais os softwares passam. As fases de Implementação neste modelo de processo é o que merece destaque no presente relatório, pois é a etapa onde o sistema sofre alterações de código e novas funcionalidades ou melhorias são acrescentadas em forma de incrementos de software. Para a codificação do sistema, a equipe de desenvolvimento responsável pelo Modelo SAFIRA se utiliza das ferramentas Genexus 3.0 e Genexus 9.0, para as plataformas Desktop e Web, respectivamente. Para qualquer necessidade de modificação de sistema detectada, deve ser realizada a abertura de um Novo

9 9 Chamado no sistema Eventum pelo Analista de Negócio, onde serão especificados, com detalhes, os requisitos referentes à alteração proposta. A equipe de desenvolvimento é então designada para a etapa de codificação, e executa o que foi solicitado. Fases subseqüentes são a de Testes, onde as alterações serão validadas, a de Versão Liberada, onde um conjunto de modificações é disponibilizado para homologação e a própria fase de Homologação, que corresponde à atualização da nova versão na máquina do cliente. Além do conhecimento prático adquirido na fase de Implementação do sistema SAFIRA, como o aprendizado da ferramenta Genexus, vale também destacar o reconhecimento da importância do trabalho em equipe dentro de uma Organização no mercado de trabalho. Em números, foi atendido durante o período de cumprimento de estágio um total de vinte chamados para a Prefeitura de Canoas/RS, três chamados para a Prefeitura de Cachoeiro Itapemirim/ES, e um chamado para a Prefeitura de Rondonópolis/MT. Em termos de experiência, o Estágio Supervisionado proporcionou uma ampliação no conhecimento de programação, constatação da aplicação prática da Engenharia de Software no desenvolvimento de sistemas, especialmente no que envolve Gerência de Projetos e Ciclo de Vida de softwares, e por último, e não menos importante, o comprometimento e responsabilidade pessoal e profissional com a empresa.

10 10 INTRODUÇÃO O presente trabalho, um dos requisitos para obtenção do título de Bacharel em Ciência da Computação, trata-se do Relatório de Estágio Supervisionado onde estarão contidas informações, tais como fundamentos teóricos e práticos relacionados às atividades desenvolvidas, métodos aplicados e procedimentos seguidos no período referente ao Estágio cumprido na empresa Ábaco Tecnologia de Informação LTDA. O objetivo deste Relatório é expor ao corpo docente integrante desta Coordenação e a todos os demais interessados, a aplicação prática dos conhecimentos adquiridos ao longo do curso de graduação em um ambiente do mercado de trabalho. Tal prática está relacionada com a execução de atividades de Implementação desenvolvidas no Modelo de Execução Orçamentária, Contábil e Financeira SAFIRA das prefeituras de Canoas, no Rio Grande do Sul, Cachoeiro Itapemirim, no Espírito Santo e também de Rondonópolis, em Mato Grosso. A organização deste documento se deu na divisão de capítulos, contendo a Revisão de Literatura, que trata dos fundamentos teóricos e práticos relacionados ao estágio, os Materiais, Técnicas e Métodos utilizados e aplicados na área de trabalho, os Resultados apontados após a execução do mesmo, as Dificuldades Encontradas durante o seu período de duração e por fim as Conclusões, correspondentes às considerações finais.

11 11 1. REVISÃO DE LITERATURA De modo a fundamentar a parte prática da execução das atividades do Estágio Supervisionado, faz-se necessário algum embasamento teórico referente à: Modelo de Processo de Software Iterativo e Incremental, Gestão de Processos e Ferramenta de Desenvolvimento Genexus. 1.1 MODELO DE PROCESSO DE SOFTWARE ITERATIVO E INCREMENTAL Um processo de software é um conjunto de atividades e resultados associados que produz um produto de software. [...] Um modelo de processo de software é uma descrição simplificada desse processo de software que apresenta uma visão dele (SOMMERVILLE, 2007, p. 6). Segundo Bezerra (2006), um processo de desenvolvimento de software seguindo a abordagem de Ciclo de Vida Iterativa e Incremental divide o desenvolvimento de um produto de software em ciclos. Nestes ciclos podem ser identificadas as fases de Análise, Projeto, Implementação e Testes. Este modelo foi criado em resposta às deficiências detectadas no Modelo Cascata, o mais tradicional, e pode até mesmo ser visto como uma generalização dele, já que o software é desenvolvido em incrementos e cada incremento é desenvolvido em cascata (Figura 1).

12 12 Figura 1. Diagrama do Ciclo de Vida Iterativo e Incremental. Fonte: BEZERRA, Eduardo, 2006, p. 33. Cada ciclo está associado a um subconjunto de requisitos, que são desenvolvidos quando alocados a um ciclo de desenvolvimento. No próximo ciclo outro subconjunto de requisitos é desenvolvido, produzindo um novo incremento do sistema que contém extensões e refinamentos sobre o anterior. Sendo assim, o sistema segue evoluindo em versões até que se atinja a versão completa do produto. Dentre algumas vantagens desta abordagem estão: Redução dos riscos, já que os custos estão envolvidos a um único incremento e não a um produto inteiro; Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham mais eficientemente quando buscam resultados menores e mais claros; Adaptação à mudança de requisitos, já que os requisitos correspondentes às necessidades dos usuários não podem ser totalmente definidos no início e são refinados durantes as iterações. Existem também algumas desvantagens quanto à aplicação do modelo, como: Dificuldade de gerenciamento, porque as fases do ciclo podem estar ocorrendo de forma simultânea;

13 13 O usuário pode se entusiasmar com a primeira versão do sistema, pensando que ele já corresponde ao sistema como um todo; Riscos comuns a todos os modelos, por exemplo, o projeto pode não satisfazer aos requisitos do usuário, a verba do projeto pode acabar, ou ainda, o sistema de software pode ser entregue ao usuário tarde demais. A Figura 2 representa uma tabela onde se dá a ênfase principal de cada uma das fases do modelo incremental: Figura 2. Representação em tabela das ênfases atribuídas a cada fase do desenvolvimento. Campos mais escuros indicam maior ênfase. 1.2 GESTÃO DE PROCESSOS A Gestão de Processos de Negócio é um conceito que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das organizações através da melhoria dos processos de negócio. São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação. Sua utilização vem crescendo significativamente pela sua utilidade e rapidez na melhoria dos processos das empresas em que já foi implementado. As ferramentas conhecidas como Sistemas de Gestão de Processos do Negócio monitoram o andamento dos processos de forma rápida e barata e é por meio delas que os gestores podem analisar e alterar os processos baseado em dados reais. A direção da empresa pode enxergar, por exemplo, aonde se encontram os gargalos, onde certas tarefas estão sofrendo atraso, o quanto estão atrasando e com que frequência isso ocorre. Em decorrência disto, fatores cruciais para o desempenho

14 14 de uma empresa podem ser identificados e analisados com extrema facilidade e rapidez em detrimento de outras ferramentas que não os Sistemas de Gestão de Processos do Negócio. 1.3 FERRAMENTA DE DESENVOLVIMENTO GENEXUS Genexus é uma ferramenta de desenvolvimento de software criada pela empresa Uruguaia ARTech, baseada em conhecimento e orientada ao desenvolvimento de aplicações corporativas, tanto para o ambiente WEB quanto GUI. O Genexus trabalha com o conhecimento contido na visão dos usuários, capturando tal conhecimento e o sistematizando em uma base de conhecimento puro, o que permite gerar aplicações para múltiplas arquiteturas e plataformas. Em outras palavras, seria dizer que ele é uma ferramenta de desenvolvimento multiplataforma, onde o Analista tem o foco apenas no conhecimento do negócio. Isto faz com que o programador não tenha que conhecer a fundo a programação em si, já que o Genexus cria o código fonte necessário na linguagem desejada e para a base de dados que se decida. Genexus conta com três ambientes: desenho, protótipo e produção. Sua ideia é automatizar tudo aquilo que for automatizável, normalizar a base de dados, o que significa executar uma série de passos no projeto da base de modo a permitir um armazenamento consistente e um eficiente acesso aos dados, e realizar manutenção automática na mesma. Com isso, a ferramenta permite ao analista ou desenvolvedor se concentrar no negócio e focar toda sua atenção naquilo que um programa não poderá fazer: entender os problemas do usuário. Além disso, se torna possível reduzir significativamente os custos de manutenção e os tempos de desenvolvimento dos sistemas.

15 15 2. MATERIAS, TÉCNICAS E MÉTODOS De modo geral, todos os setores e projetos da empresa Ábaco fazem uso de um sistema web denominado Eventum (Figura 3), onde é estabelecido todo o controle das atividades a serem desenvolvidas por parte de um setor/funcionário a outro setor/funcionário. O Reclamante, ou seja, aquele que necessita da prestação de um serviço de outra parte integrante da empresa abre um Novo Chamado (Figura 4) por meio do sistema. Nele, o mesmo deve especificar campos como a Categoria do Chamado, como exemplo, uma consulta técnica ou uma nova implementação ou um reparo de erro, a Prioridade do Chamado, ou seja, se a necessidade de atendimento é altíssima, alta, média, leve ou baixa, o Designado para atendimento, sendo este um setor ou um funcionário responsável, um Resumo do que se trata a solicitação e por fim, uma Descrição Completa do motivo pelo qual o chamado está sendo aberto. Existe também, a possibilidade de se anexar arquivos, caso necessário.

16 Figura 3. Tela do sistema Eventum exibindo alguns chamados em seus diversos status. 16

17 17 Figura 4. Tela de abertura de um Novo Chamado e dos campos a serem preenchidos. O Designado para atendimento recebe então, a notificação de que um chamado foi para ele encaminhado, inicia a realização do serviço e ao finalizá-lo, retorna a solicitação cumprida para o Reclamante que o designou. Uma vez que a solicitação tenha sido atendida por completo, o Reclamante pode então finalizar este chamado e dar sequência em suas atividades. O encaminhamento, o início do desenvolvimento correspondente ao que foi pedido, a finalização, e o fechamento do chamado são todos determinados através da mudança do status do chamado no sistema Eventum, o que permite com que todos aqueles que têm acesso a um projeto visualizem em que situação o chamado se encontra. De forma mais específica, o Setor de Desenvolvimento de Operações Continuadas, onde são desenvolvidas manutenções em sistemas já existentes e que já estão implantadas nos Clientes, também cumpre todas as etapas deste procedimento. Quando uma necessidade de alteração no sistema é identificada, seja ela uma nova implementação, uma melhoria, ou ainda um reparo de erros, um novo chamado é aberto pelo Analista de Negócio e Suporte. Para tanto, o Analista especifica os

18 18 campos na abertura do chamado, como relatado anteriormente, e o mesmo passa ao status de Novo Pedido. Assim que se inicia ou se finaliza as análises de suporte e negócio os status do chamado também são alterados, seguindo sempre a seguinte ordem: Iniciado Análise de Suporte, Concluído Análise de Suporte, Iniciado Análise de Negócio, Concluído Análise de Negócio. Quando o chamado atinge este último estágio, é obrigatoriedade do analista anexar um documento com o levantamento de requisitos, onde a próxima equipe que dará continuidade no procedimento, ou seja, a equipe de Desenvolvimento, analisará o impacto da atualização no sistema, decidirá em conjunto com o Analista de Negócio qual a melhor forma para atender a necessidade do cliente e iniciará a etapa de codificação do sistema. O chamado é sempre encaminhado inicialmente ao líder de uma determinada equipe, que ficará responsável por distribuir o pedido da codificação para o desenvolvedor que ele designar. Nesta etapa o status do chamado é Distribuído para Codificação. O então designado, recebe e altera o status do chamado para Iniciado Codificação, analisa o documento anexado, e inicia o desenvolvimento. Caso haja a necessidade de se interromper esta etapa para o atendimento de outra prioridade, o desenvolvedor pode alterar o status para Paralisado Codificação e assim que estiver pronto a dar continuidade no atendimento do chamado paralisado, retomar a codificação. Finalizando a alteração, o desenvolvedor seleciona o status Concluído Codificação e gera um arquivo de extensão.xpw referente ao objeto do modelo no qual foi feita a modificação. Este arquivo é encaminhado via a todos os desenvolvedores da equipe e anexado no Eventum, para que cada um deles consolide em suas respectivas máquinas o novo objeto com a alteração, de modo que todos os modelos de sistemas de todos os colaboradores mantenham-se sempre atualizados e equivalentes. Vale também destacar que se não existir a possibilidade de uma alteração ser realizada por quaisquer motivos, o desenvolvedor pode devolver o chamado para análise, uma etapa anterior, alterando o status para Devolvido para Análise/Suporte e sempre justificando o motivo da devolução. Assim, basta aguardar o retorno do Analista referente a uma nova Análise de Negócio ou à finalização do chamado.

19 19 Existe um cronograma de versão para cada cliente, e quando cada data deste cronograma é atingida, o líder da equipe gera todos os executáveis correspondentes à versão e executa um procedimento denominado Liberação de Versão, onde todo este pacote de alterações é disponibilizado para testes. Caso exista algum chamado nesta versão que não pôde ser atendido até a data estipulada no cronograma, o líder de desenvolvimento entra em contato com o Analista de Suporte/Negócio, que por sua vez, em conversa com o Cliente, entra em consenso a respeito da definição de outra data de liberação deste chamado. Fica acordado então, que o mesmo poderá ser liberado na próxima versão prevista. Neste momento o status de todos os chamados que consta como Concluído Codificação e Paralisado Teste passam a Disponível para Testes. Os chamados se encontram na situação de Paralisado Teste quando necessitam de atendimento urgente e os executáveis são gerados e liberados antes da versão prevista. Sendo assim, eles permanecem com o mesmo status até que a chegue a data da versão a que ele está vinculado e seja iniciada a etapa de testes juntamente com os demais chamados. O Analista de Negócio seleciona o status Iniciado Teste, realiza os testes necessários e verifica se as solicitações foram integralmente atendidas. Caso positivo, o status passa para Concluído Teste. Caso negativo, o Analista anexa um novo documento denominado Documento de Teste explicitando o que ainda permanece inconforme, e o chamado é retornado para codificação com status Devolvido para Codificação. Assim que todos os chamados referentes a uma Versão são validados na fase de testes, inicia-se a fase de Homologação, onde as modificações são testadas pelo Testador juntamente com o Cliente. Nesta fase os status dos chamados são de Iniciado Homologação e se tudo estiver conforme, o documento de Homologação é assinado pelo cliente oficializando que as solicitações dos chamados liberados foram atendidas. As alterações são homologadas no Cliente e os status passam a Finalizado Homologação. Após todo este processo, o chamado é Finalizado pelo Reclamante (aquele que deu abertura no chamado), e seu novo e último status é o de Finalizado. O Fluxograma do Processo de Desenvolvimento e Manutenção de Software do Setor de Operações Continuadas é demonstrado na Figura 5:

20 20 Figura 5. Fluxograma do PDMS do Setor de Operações Continuadas. Fonte: PDMS Ábaco Eventum. As mudanças de status são feitas através da postagem de Notas Internas (Figura 6), onde cada responsável por dar sequência em um chamado especifica o que iniciará a fazer ou o que acaba de ser concluído. Através das Notas Internas é permitido ao funcionário apontar uma entrada de tempo, o que determina quanto tempo cada um gasta para realizar cada atividade. O Chefe das equipes do Setor de Operações Continuadas faz o levantamento do tempo de trabalho de cada colaborador por meio do lançamento destes minutos gastos na execução das atividades (Figura 7).

21 21 Figura 6. Tela de uma Nova Nota Interna. Figura 7. Apontamento de Tempo gasto com diferentes atividades.

22 22 Além do sistema Eventum, existe ainda outra ferramenta web conhecida como Share Point (Figura 8), onde são compartilhados arquivos de uso comum entre os integrantes de um determinado Projeto, como Documentos de Homologação e de Liberação de Versão, scripts e arquivos executáveis referentes a uma Versão, e arquivos de interesse geral, como o Manual de Gestão da Qualidade, Normas diversas e templates de documentos padronizados para serem utilizados por qualquer colaborador que necessite preencher ou elaborar um. O Sistema de Gestão da Qualidade (SGQ), em busca da certificação da qualidade de seus serviços e da satisfação do cliente, gerencia todos os fluxos de processos das áreas de escopo da empresa (Fábrica de Software, Operações Continuadas, Outsourcing e Treinamentos) visando garantir a total conformidade de suas ações com as normas previstas na NBR ISO 9001:2008. Figura 8. Tela da ferramenta Share Point, exibindo a sessão do Projeto Safira. A ferramenta para Desenvolvimento utilizada no Sistema SAFIRA (Figura 9), um dos sistemas integrantes do Setor, é o Genexus em sua versão 3.0 (Figura 10). As principais Ferramentas CASE que são usadas para dar suporte aos processos são o

23 23 Microsoft Office Word, onde são feitos os levantamentos de requisitos de um chamado e os documentos de testes, o Microsoft Office Excel, onde são desenvolvidos, por exemplo, cronogramas de versão e layouts de relatórios enviados por Clientes, demonstrando como um relatório deve ser exibido após gerado pelo sistema, o PL/SQL Developer, uma Ferramenta de consulta ao Banco de Dados onde são realizadas consultas no Banco, sempre que necessário, e o Microsoft Visual Basic 6.0, onde são simulados os testes das funcionalidades do sistema. Figura 9. Interface do Menu Principal do Sistema SAFIRA da prefeitura de Canoas/RS.

24 24 Figura 10. Ferramenta Genexus 3.0 exibindo uma das principais telas do Modelo SAFIRA. O Modelo SAFIRA é dividido em um grande número de Objetos, que são codificados de acordo com as requisições. Estes objetos podem ser Work Panels, Transações, Procedimentos ou Relatórios. O Desenvolvedor abre os objetos que necessitam de alteração no Genexus, ou ainda, criam novos, e iniciam ali o desenvolvimento. Quando uma alteração é de maior impacto sobre um objeto, por exemplo, quando a modificação de código ou de layout de um relatório é extensa, é executado o procedimento Save As, que gera um novo objeto idêntico ao primeiro. Este novo objeto é o que será codificado, evitando que informações do objeto original sejam perdidas. Sempre que há mudança em um ou mais objetos e o desenvolvedor deseja testá-la, o mesmo seleciona uma função denominada Specify Selected, que é uma espécie de compilação em particular apenas dos objetos que sofreram modificação, e

25 25 logo após seleciona a função Execute, que executa o programa com as alterações já compiladas. Esta prática exclui a necessidade de que todo o modelo seja construído novamente e assim, evita grande desperdício de tempo. Quando uma codificação é concluída, um novo arquivo.xpw é gerado e encaminhado aos demais desenvolvedores da mesma equipe. Ao receber um novo arquivo.xpw, cada colaborador consolida este arquivo em sua máquina e desta forma mantém o seu modelo atualizado e igual ao dos demais.

26 26 3. RESULTADOS O espaço de tempo dedicado às atividades propostas no Estágio Supervisionado certamente gerou resultados positivos. Inicialmente foi possível constatar com clareza, operando no Setor de Operações Continuadas, uma das fases do clico de vida Incremental e Iterativo de um software, a fase de Implementação. O que antes era abstraído apenas em teoria, passou agora a ser visualizado na prática. Todas as tarefas executadas por qualquer Desenvolvedor são acompanhadas pelo líder de Desenvolvimento, já que o trabalho de todos caminha sempre em paralelo e todos devem saber em qual objeto os outros estão trabalhando para evitar sobreposições. Sendo assim, a convivência e cumplicidade com o grupo responsável por esta fase contribuíram muito para o aprendizado de como se dá o trabalho em equipe dentro de uma Organização. Todo o sistema SAFIRA foi desenvolvido através da Ferramenta Genexus e, da mesma forma, toda manutenção necessária é prestada nela. Sendo assim, o conhecimento da ferramenta, de sua linguagem própria e de suas funcionalidades foram todos adquiridos por meio do estudo e do manuseio deste novo ambiente de programação, o que também caracteriza um resultado positivo. Como toda requisição de alteração do software é realizada através dos chamados no sistema Eventum, segue o gráfico ilustrativo (Figura 11) correspondente à quantidade de chamados atendidos em favor do sistema SAFIRA, implantado em três diferentes prefeituras (Tabela 1), desde a inserção na empresa até o momento de conclusão do estágio. Tabela 1. Distribuição do Atendimento de Chamados referentes ao período de 22/08/2011 à 28/11/2011 Canoas Cachoeiro Itapemirim Rondonópolis Gilberto Fonte: PDMS Ábaco Eventum.

27 Figura 11. Gráfico referente aos dados da Tabela 1 27

28 28 4. DIFICULDADES ENCONTRADAS Antes do ingresso na empresa, foi realizado um extenso processo seletivo onde uma das principais etapas era o curso de Genexus. Para que se pudesse obter as noções básicas do funcionamento da ferramenta, o curso foi ministrado utilizando-se a versão do Genexus Evolution, que possui mais recursos do que as versões anteriores. Concluído o curso com sucesso, fui incluído na equipe de Operações Continuadas, como um dos Desenvolvedores do sistema SAFIRA. Ocorreu que a maior parte do sistema foi desenvolvida em uma das primeiras versões do produto, o Genexus 3.0, e por isso, atividades de implementação eram também nele desenvolvidas. Foi nesta divergência que se deu uma das maiores dificuldades durante a execução do estágio, pois o Genexus 3.0 é destinado à plataforma Desktop e o Genexus Evolution à Web. Outras dificuldades encontradas foram o conhecimento da Regra de Negócio do Sistema Contábil, que possui várias particularidades, e o processo de trabalho, que tem todo um fluxo a ser seguido. Entretanto, buscando o auxílio da líder, sempre solícita, e de alguns colegas de trabalho, foi possível absorver até com certa rapidez as regras para o bom andamento das operações no Setor. Muito empenho e dedicação foram despendidos em horas de estudo do sistema e suas funcionalidades, dos comandos e funções da linguagem específica da ferramenta Genexus para que se chegasse a uma abstração do sistema e de tudo o que a ele estava relacionado. Graças a este esforço próprio e à colaboração da equipe, foi possível executar com êxito todas as tarefas que a mim foram designadas.

29 29 5. CONCLUSÕES Todo trabalho desenvolvido na empresa desde o início até a conclusão do Estágio apresentou resultados bastante positivos para o processo de formação profissional. O primeiro deles foi permitir a aquisição de noções maiores de programação de sistemas, com um desafio ainda maior pelo fato de o sistema já estar implantado e ser até então, completamente desconhecido. Um segundo ponto foi a ampliação da visão de Gerência de Processos, onde pôde-se constatar na prática como se dá a administração de cada um dos processos referentes ao desenvolvimento de um software, desde a etapa de Elaboração até a etapa de Transição. A inserção no mercado de trabalho foi também, um fator de extrema importância, uma vez que a seriedade com que a empresa administra seus serviços estimula e exige do funcionário dedicação, comprometimento e responsabilidade com suas competências. Pode-se afirmar com convicção, portanto, que ao final do período destinado à realização do Estágio Supervisionado, as expectativas e objetivos pessoais foram integralmente atendidos graças à colaboração mútua entre empregado e empregador.

30 30 6. REFERÊNCIAS BIBLIOGRÁFICAS BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 2ª Edição. Rio de Janeiro: Campus Fabricio de los Santos. Genexus no Brasil. Disponível por www em (acessado em 24 de novembro de 2011). Rodrigo Santos. Um Pouco Sobre Genexus. Disponível por www em html/ (acessado em 24 de novembro de 2011). SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Pearson Education Washington Grimas. Gestão de Processos de Negócios. Disponível por www em (acessado em 11 de dezembro de 2011).