APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM SISTEMA DE GESTÃO EMPRESARIAL

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM SISTEMA DE GESTÃO EMPRESARIAL MARLON GRACIETTI DE AMORIM BLUMENAU /1-12

2 MARLON GRACIETTI DE AMORIM APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM SISTEMA DE GESTÃO EMPRESARIAL Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação Bacharelado. Prof. Cláudio Ratke, Mestre - Orientador BLUMENAU /1-12

3 APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM SISTEMA DE GESTÃO EMPRESARIAL Por MARLON GRACIETTI DE AMORIM Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Cláudio Ratke, Mestre Orientador, FURB Prof. Oscar Dalfovo, Doutor FURB Prof. Mauro Marcelo Mattos, Doutor FURB Blumenau, 02 de julho de 2012.

4 Dedico este trabalho a todos os meus familiares, amigos e colegas de trabalho, especialmente aqueles que me ajudaram diretamente na realização deste.

5 AGRADECIMENTOS A Deus, pelo seu imenso amor e graça. À minha família, que mesmo longe, sempre esteve presente. Ao meu orientador, Cláudio Ratke, por ter acreditado na conclusão deste trabalho. Aos professores do Departamento de Sistemas e Computação da Universidade Regional de Blumenau por suas contribuições durante os semestres letivos.

6 Os bons livros fazem sacar para fora o que a pessoa tem de melhor dentro dela. Lina Sotis Francesco Moratti

7 RESUMO Este trabalho tem como objetivo o desenvolvimento de uma aplicação que auxilia o planejamento e distribuição das atualizações de um sistema de gestão empresarial. Utilizando práticas recomendas pelo Capability Maturity Model Integration (CMMI) e Information Technology Infrastructure Library (ITIL), o trabalho facilita a agregação dos arquivos e documentos que serão transferidos via internet da empresa desenvolvedora até o servidor de aplicação de cada cliente. O trabalho integra-se a um sistema de gestão empresarial e ao gerenciador de projetos Redmine. Torna possível á equipe de liberação definir quais os clientes aptos a receber os arquivos, faz a formulação do release note. A aplicação ainda faz a supervisão da versão utilizada por cada cliente, dispensando a necessidade de fazer conexões remotas para coletar tais informações. Palavras-chave: ITIL. CMMI. Gestão empresarial. Redmine.

8 ABSTRACT This work aims to develop an application that helps planning and distribution of updates from a business management system. Do you recommend using practices at Capability Maturity Model Integration (CMMI) and Information Technology Infrastructure Library (ITIL), the work facilitates the aggregation of files and documents to be transferred internet to the company developing the application server for each client. The work is part of a business management system and the project manager Redmine. Makes it possible to release staff will determine which customers are able to receive the files, does the wording of the release note. The application also oversees the version used by each customer, eliminating the need to make remote connections to collect such information. Key-words: ITIL. CMMI. Business Management. Redmine.

9 LISTA DE FIGURAS Figura 1 - Formulário de requisição de mudança utilizando a ferramenta redmine Figura 2 - Processo de gerenciamento de mudança Figura 3 - Exemplo da utilização de ramos de desenvolvimento Figura 4- Retrato de um repositório após a criação de um ramo Figura 5 - Interface do Finalbuilder Figura 6 - Processo de Gerenciamento de Liberação Figura 7 - Fluxo do processo atual Figura 8 - Visão geral do trabalho desenvolvido Figura 9 - Fluxo proposto por este trabalho Figura 10 - Tela de Gerenciamento de Liberações Figura 11 - Fluxo do processo de liberação Figura 12 - Diagrama de caso de uso do módulo cliente Figura 13 - Diagrama de caso de uso módulo servidor Figura 14 - Modelo de entidade relacional do ERP Figura 15 - Modelo de entidade relacional do redmine Figura 16 - Modelo de entidade relacional do cliente Figura 17 - Arquivo WSDL gerado pelo Delphi Xe Figura 18- Implementação do método SolicitaVersao publicada pelo webservice Figura 19 - Tela de login do usuário Figura 20 - Tela de gerenciamento de liberações Figura 21 - Opção para criar um novo release Figura 22 - Relação de clientes aptos a receber a atualização Figura 23 - Tela de envio de do release note Figura 24 - Tela de release notes com a opção de buscar a origem de cada registro Figura 25 - Aviso do sistema caso o arquivo de atualização não for informado Figura 26 - Caixa de dialogo utilizada para informar o arquivo de atualização Figura 27 - Tela do servidor de atualizações Figura 28 - Tela do cliente de atualização Figura 29 - Biblioteca definitiva de software Figura 30 - Resumo das respostas da questão Figura 31 - Resumo das respostas da questão

10 Figura 32 - Resumo das respostas da questão Figura 33- Resumo das respostas da questão Figura 34 - Resumo das respostas da questão Figura 35 - Formulário de avaliação do trabalho desenvolvido... 66

11 LISTA DE QUADROS Quadro 1 - Fatores que influenciam a estratégia de sistema de release Quadro 2 - Proposta de Indicadores de desempenho Quadro 3 - Requisitos funcionais Quadro 4 - Requisitos não funcionais Quadro 5 - Caso de uso Verifica atualizações disponíveis Quadro 6 - Caso de uso Baixa atualizações disponíveis Quadro 7 - Caso de uso Iniciar a Instalação das atualizações Quadro 8 - Caso de uso Notifica versão atual Quadro 9 - Caso de uso Efetuar Login Quadro 10 - Caso de uso Efetuar Login Quadro 11 - Caso de uso Consultar versões instaladas Quadro 12 - Caso de uso Visualizar release notes Quadro 13 Caso de uso Enviar de release notes... 65

12 LISTA DE SIGLAS CMMI - Capabilyty Matury Model Integration CRF - Change Request Form CVS - Concurrent Versions System ERP - Enterprise Resource Planning FTP - File Transfer Protocol IC - Itens de Configuração ITIL - Information Technology Infrastructure Library KPI - Key Performance Indicartor LDAP - Lightweight Directory Access Protocol MRP - Material Requirement Planning MRPII - Manufacturing Resource Planning SVN - Subversion TI - Tecnologia da Informação WSDL - Web Service Definition Language

13 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA SISTEMA DE GESTÃO EMPRESARIAL CAPABILITY MATURY MODEL INTEGRATION (CMMI) Gerenciamento de configuração Itens de configuração (ICs) Linhas de base Gerenciamento de mudanças Gerenciamento de versões e releases Gerenciamento de releases Integração Contínua Ferramentas de apoio Subversion Ramos de desenvolvimento (Branches) FinalBuilder FinalBuilder Server Redmine ITIL Gerenciamento de Liberação Biblioteca de Software Definitivo Indicadores de desempenho SISTEMA ATUAL TRABALHOS CORRELATOS DESENVOLVIMENTO LEVANTAMENTO DE INFORMAÇÕES ESPECIFICAÇÃO MODELAGEM Diagrama de casos de uso Modelo de dados relacional... 39

14 3.4 IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Operacionalidade da implementação Gerenciador de atualizações (Cliente/Servidor) Servidor de atualizações Cliente de atualizações RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Descrição dos Casos de Uso ANEXO A Formulário de avaliação do trabalho desenvolvido... 66

15 12 1 INTRODUÇÃO Com o aumento da complexidade da infraestrutura de TI e da dependência das organizações em relação aos serviços de TI, torna cada vez mais necessário o gerenciamento detalhando a liberação de softwares para uso pela organização (MAGALHÃES; PINHEIRO, 2007). Para sustentar essa demanda, as empresas desenvolvedoras de softwares precisam adotar boas práticas para obter o mínimo de impacto e a máxima agilidade na entrega de seus serviços. Segundo Magalhães e Pinheiro (2007) são muito frequentes o emprego de processos simplificados para o gerenciamento de liberação, quando disponíveis, os quais acabam não evitando a ocorrência de incidentes e problemas, passível de provocar a perda da estabilidade da infraestrutura de TI, e consequentemente, a indisponibilidade de serviços de TI. Deixar a tarefa de atualização manual para os usuários é sinônimo de dores de cabeça. Certamente, com esta prática, não dá para garantir que todos farão as atualizações corretamente (CARVALHO, 2011). Além dos riscos e retrabalhos enfrentados com a atualização manual dos softwares, existe também a dificuldade de saber se o cliente está utilizando a versão correta. A solução proposta com o desenvolvimento deste trabalho é a utilização de práticas recomendadas pelo Capability Maturity Model Integration (CMMI) e Information Technology Infrastructure Library (ITIL) para definir um novo processo de trabalho e fazer com que o software a ser atualizado receba notificação de novas versões disponíveis, acesse os arquivos disponibilizados em um servidor, através do File Transfer Protocol (FTP) e, depois de realizada a transferência dos arquivos, o aplicativo irá iniciar o processo de atualização do software, diminuindo o tempo de entrega de correções e melhorias disponibilizadas para cada cliente. 1.1 OBJETIVOS DO TRABALHO O objetivo geral do trabalho é o desenvolvimento de um aplicativo baseado nas recomendações do ITIL e CMMI para a atualização automática de um sistema de gestão empresarial.

16 13 Os objetivos específicos do trabalho proposto são: a) disponibilizar um aplicativo cliente/servidor para fazer a transferência automática da atualização do software; b) permitir o controle sobre a versão do software utilizada pelos clientes; c) automatizar o processo de liberação de versão. 1.2 ESTRUTURA DO TRABALHO Este trabalho está dividido em quatro capítulos. No primeiro capítulo tem-se a introdução os objetivos e a estrutura do trabalho. O segundo capítulo contempla os conceitos dos principais fundamentos que servem de base para o trabalho, a descrição do processo atualmente praticado na empresa, e por fim, os trabalhos correlatos. No terceiro capítulo está descrito o desenvolvimento do aplicativo, as técnicas e ferramentas utilizadas bem como a elaboração dos diagramas para auxiliar na compreensão do aplicativo. No quarto capítulo tem-se as conclusões deste trabalho bem como apresentam-se sugestões para trabalhos futuros.

17 14 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo aborda assuntos a serem apresentados nas seções a seguir, tais como Capability Matury Model Integration (CMMI), gerenciamento de configuração, gerenciamento de mudança, controle de versão, integração contínua, sistema atual e trabalhos correlatos. 2.1 SISTEMA DE GESTÃO EMPRESARIAL O sistema de gestão empresarial mais conhecido como, Enterprise Resource Planning (ERP) é uma ferramenta tecnológica de gestão empresarial, utilizada por empresas do mundo todo (CIGAM, 2011). O ERP faz a integração das informações de gestão em toda a organização, abrangendo finanças, contabilidade, produção, vendas e serviços, gestão de relacionamento com o cliente, entre outras funcionalidades. Sua finalidade é facilitar o fluxo de informações entre todas as funções de negócio dentro dos limites da organização e gerenciar as conexões com as partes interessadas externas (HABERKORN, 1999). De acordo com Haberkorn (1999), no princípio, surgiram aplicativos com finalidades direcionadas para funções específicas nas empresas, operando como ilhas departamentais. Os destaques ficavam na área administrativa, entre os quais Contabilidade, Controle Patrimonial, Estoque, Contas a Pagar/Receber e Folha de Pagamento. Na parte industrial, somente grandes corporações utilizavam os sistemas de Material Requirement Planning (MRP), para planejamento das necessidades de materiais. A década de 80 deu início ao uso de computadores em rede, alavancando aplicações mais robustas e dando início a um grau maior de integração entre os aplicativos. O MRP evolui para Manufacturing Resource Planning (MRPII), planejamento dos recursos de manufatura (CIGAM, 2011).

18 CAPABILITY MATURY MODEL INTEGRATION (CMMI) Organizações desenvolvedoras de software estão adotando práticas de engenharia dos processos de negócio para aumentar a maturidade de sua capacidade em desenvolver software. O objetivo principal dessas organizações é aumentar a eficiência e efetividade das soluções de software para apoiar as necessidades de clientes e dos mercados. Para alcançar este objetivo, as organizações desenvolvedoras de software devem ser mais produtivas, aumentar a qualidade dos produtos de software, diminuir o esforço e custo dos projetos, e lidas com questões críticas relacionadas ao tempo de lançamento de produtos comercias (PFLEEGER, 2004). O CMMI é um modelo de maturidade para melhoria de processo, destinado ao desenvolvimento de produtos e serviços, e composto pelas melhores práticas associadas a atividades de desenvolvimento e de manutenção que cobrem o ciclo de vida do produto desde a concepção até a entrega e manutenção (MELLON, 2006) Gerenciamento de configuração Segundo Sommerville (2003), gerência de configuração é a utilização de modelos e padrões para gerenciar um software em desenvolvimento. Alterações em suas funcionalidades, correções e adaptações, geram diferentes versões do sistema. A gerência de configuração serve para evitar conflitos nos itens de configuração modificados. A gestão de configuração de software pode ser entendida como uma disciplina que permite manter a evolução de produtos de software sobre controle e contribuir para atender as exigências de qualidade e prazo. Ao longo dos anos a gestão de configuração tem evoluído, e atualmente envolve as seguintes áreas de processo (ESTUBLIER, 2000): a) identificação da configuração de produtos de trabalho selecionados que compõem o baseline em determinados instantes; b) controle de mudança nos itens de configuração; c) build de produtos de trabalho a partir do sistema de gestão de configuração; d) manutenção e integridade das linhas de base; e) disponibilização do status e dos dados atuais de configuração para desenvolvedores, usuários finais e clientes.

19 16 Segundo Mellon (2006) os produtos de trabalho colocados sob a gestão de configuração incluem os produtos que são entregues ao cliente, produtos de trabalho internos selecionados, produtos adquiridos, ferramentas e outros itens que são utilizados para criar e descrever esses produtos de trabalho. É possível que produtos adquiridos tenham que ser colocados sob a gestão de configuração tanto pelo fornecedor como pelo projeto. Recomenda-se que sejam estabelecidas cláusulas no contrato com fornecedores para a condução da gestão de configuração. E também que sejam estabelecidos e mantidos métodos para assegurar que os dados estejam completos e consistentes (COUTO, 2007) Itens de configuração (ICs) Segundo Mellon (2006) um item de configuração (IC) é uma entidade selecionada para gestão de configuração, podendo ser composta por diversos produtos de trabalho relacionados que formam uma baseline. Esse agrupamento lógico propicia facilidade de identificação e controle de acesso. Recomenda-se que a seleção de produtos de trabalho para gestão de configuração seja baseada em critérios estabelecidos durante o planejamento. Exemplos de produtos de trabalho que podem fazer parte de um item de configuração: a) descrição de processos; b) requisitos; c) design; d) planos e procedimentos de testes; e) resultados de testes; f) descrições de interfaces; g) diagramas; h) código-fonte; i) ferramentas Linhas de base Segundo Couto (2007) uma linha de base ou baseline é um conjunto de especificações

20 17 ou de produtos de trabalho que tenham sido formalmente revistos, e que, a partir desse ponto de concordância entre os revisores, serve como base para desenvolvimento ou entrega posterior, só podendo ser modificados por meio de procedimentos de controle de mudança. Um baseline representa a atribuição de um identificador a um item de configuração ou a um conjunto de itens de configuração e entidades associadas. À medida que um produto evolui, vários baselines podem ser utilizados para controlar seu desenvolvimento e teste (MELLON, 2006) Gerenciamento de mudanças As necessidades e requisitos organizacionais modificam o tempo de vida útil de um sistema. Isso requer que mudanças sejam feitas no software. Um processo definido de gerenciamento de mudanças associado a ferramentas de apoio garantem que essas mudanças sejam registradas e aplicadas ao sistema de maneira econômica (SOMMERVILLE, 2003). Os procedimentos de gerenciamento de mudança devem ser concebidos pra assegurar que os custos e os benefícios das mudanças sejam adequadamente analisados e as mudanças em um sistema sejam feitas de maneira controlada (SOMMERVILLE, 2003). O primeiro estágio do processo de gerenciamento de mudanças é o preenchimento de um formulário de solicitação de mudança Change Request Form (CRF), em que o solicitante estabelece a mudança requerida no sistema. Tem como objetivo registrar a solicitação da mudança, recomendações, custo estimado, aprovação. Ele pode também incluir uma seção na qual o engenheiro de manutenção faz um esboço de como a mudança deverá ser implementada. As solicitações de mudança devem ser registradas no banco de dados de configuração (SOMMERVILLE, 2003). Um exemplo de um formulário de solicitação de mudança parcialmente preenchido utilizando a ferramenta de apoio redmine é exibido na Figura 1.

21 18 Fonte: Redmine (2012). Figura 1 - Formulário de requisição de mudança utilizando a ferramenta redmine Para alguns contratos, particularmente contratos com o governo, o formulário de solicitação de mudança precisa estar de acordo com um padrão especificado pelo cliente (SOMMERVILLE, 2003, p. 555). Uma vez que o formulário de solicitação de mudança tenha sido submetido, ele é analisado a fim de ser verificado se a mudança é válida. Algumas solicitações de mudanças podem ocorrer em virtudes de erros de compreensão, e não de defeitos do sistema. Outras podem se referir a defeitos já conhecidos (SOMMERVILLE, 2003, p. 555). Quando um conjunto de mudanças é aprovado, ela é encaminhada para a equipe de desenvolvimento ou manutenção, para implementação. À medida que os itens de configuração são modificados, deve ser mantido um registro de mudança feito em cada um deles (SOMMERVILLE, 2003, p. 556). A Figura 2 exibe um exemplo do processo de gerenciamento de mudança.

22 19 Fonte: Sommerville (2003, p. 555). Figura 2 - Processo de gerenciamento de mudança Gerenciamento de versões e releases Ter uma política de gerenciamento de liberação também é muito importante para o sucesso de um projeto. Como o desenvolvimento de um projeto é bastante dinâmico, torna-se frequente a liberação de várias versões do produto (BECTA, 2004). O gerenciamento de liberação é o processo de planejar, compilar, testar e implantar uma versão de distribuição de software, bem como o controle de versionamento e a sua armazenagem. Tem como objetivo garantir a qualidade do ambiente de produção usando procedimentos formais e verificações quando se implementam novas versões (BON, 2006). A forma mais comum de lançamento de versões nos projetos é o congelamento do código, isto é, a criação de uma linha de base (Consultar ). A partir disto, nenhuma funcionalidade é adicionada ao código base, apenas os bugs são corrigidos para o lançamento de uma versão estável. Em seguida é criada uma nova liberação que compreendem uma ou mais mudanças autorizadas. A sua primeira subdivisão baseia-se no nível da liberação. Elas frequentemente são divididas em (BON, 2006, p. 96): a) liberações importantes: em geral com funcionalidades significativamente ampliada. Essas liberações quase sempre eliminam vários erros conhecidos, inclusive soluções de contorno e reparos temporários;

23 20 b) liberações de menor importância: Incluem vários aperfeiçoamentos de menor importância e reparos de erros conhecidos; c) reparos de emergência: normalmente implementadas como um reparo temporário para um problema ou erro conhecido. Novas versões de software devem ser disponibilizadas pela equipe de gerenciamento de configuração, e não pelos desenvolvedores de sistema, mesmo quando não se destinam à liberação externa. Isso facilita manter a consistência da configuração de banco de dados, uma vez que somente a equipe de gerenciamento de configuração pode modificar as informações sobre a versão (SOMMERVILLE, 2003). Uma versão de software é diferente de um release como descreve o autor. Um release de sistema é uma versão que é distribuída para os clientes. Cada release de sistema deve incluir nova funcionalidade ou se destinar a uma diferente plataforma de hardware. Há sempre muito mais versões de um sistema do que releases, uma vez que as versões são criadas dentro de uma organização para o desenvolvimento interno ou testes, e nunca são liberadas para clientes (SOMMERVILLE, 2003, p. 557). Quando um item de configuração precisa ser modificado, este deve ser retirado do sistema de gerenciamento de versão e quando for devolvida uma nova versão do item de configuração deve ser criada (SOMMERVILLE, 2003, p. 557). Este processo é feito pelas ferramentas de apoio como descrito na seção Gerenciamento de releases Segundo Sommerville (2003) um release é uma versão do sistema que é distribuído para os clientes. Os gerentes de release de sistema são responsáveis por decidir quando um sistema será liberado, gerenciando o processo de criação e documentação do release. Um release de sistema não é composto apenas por arquivos inerentes ao sistema. O release pode também incluir (SOMMERVILLE, 2003, p 559): a) arquivos de configuração que definem como o release deve ser configurado para instalações específicas; b) arquivos de dados, são necessários para a operação bem-sucedida do sistema; c) um programa de instalação, que é utilizado para auxiliar a implantação do sistema; d) documentação eletrônica ou em papel que descreve o sistema.

24 21 De acordo com Sommervile (2003, p. 560) a preparação e a distribuição de um release de sistema é um processo dispendioso, particularmente para os produtos de software destinados ao mercado massivo. As decisões sobre quando liberar uma nova versão do sistema devem ser regidas por considerações técnicas e organizacionais, como mostra o Quadro 1. Fator Qualidade técnica do sistema Quinta ler de Lehman Competição Requisitos de mercado Descrição Quando são relatados sérios defeitos nos sistemas, que afetam a utilização do sistema por seus usuários, pode ser necessário um release de correção de defeitos. Para defeitos menores podem ser criados patches. Quando houver uma mudança significativa no software ela poderá ser seguida de um release de correção. Quando um produto concorrente está disponível. O departamento de marketing pode ter assumido o compromisso de que os releases estarão disponíveis em uma determinada data. Proposta de mudanças do cliente Para sistemas customizados, clientes podem ter solicitado uma nova funcionalidade. Fonte: Sommerville (2003, p. 561). Quadro 1 - Fatores que influenciam a estratégia de sistema de release Integração Contínua Integração contínua é uma prática ágil e tem o objetivo de automatizar o processo de compilação de um sistema, como descreve o autor. Integração Contínua é uma prática de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente. (FOWLER, 2006). Segundo Caelum (2008), Integração Contínua tornou-se muito importante para o desenvolvimento de software devido ao grande impacto causado pelas metodologias ágeis. Em equipes que adotaram tais metodologias (extreme Programming, Scrum, entre outras), integração contínua é um dos pilares da agilidade, garantindo que todo o sistema funcione a cada build de forma coesa, mesmo que sua equipe seja grande e diversas partes do código

25 22 estejam sendo alteradas ao mesmo tempo. Basicamente, a grande vantagem da integração contínua está no feedback instantâneo. Isso funciona da seguinte forma; a cada commit no repositório, o build é feito automaticamente, com todos os testes sendo executados de forma automática e falhas sendo detectadas. Se algum commit não compilar ou quebrar qualquer um dos testes, a equipe toma conhecimento instantaneamente (através de , por exemplo, indicando as falhas e o commit causador das mesmas). A equipe pode então corrigir o problema o mais rápido possível, o que é fundamental para não introduzir erros ao criar novas funcionalidades ou refatorar. Integração contínua é mais uma forma de trazer segurança em relação a mudanças, a equipe pode fazer modificações sem medo, pois será avisado caso algo saia do esperado (CAELUM, 2008) Ferramentas de apoio De acordo com Sommerville (2003) os processos de gerenciamento de configuração são padronizados e envolvem a aplicação de procedimentos predefinidos. Eles exigem no gerenciamento cuidados de grande quantidade de dados, e a atenção aos detalhes é essencial. Quando se constrói uma nova versão de software, um único erro de gerenciamento de configuração pode significar que o software não funcionará adequadamente. Como consequência, a ferramenta de apoio é essencial para o gerenciamento de configuração. A seguir são exibidas algumas das ferramentas de apoio para gerência de configuração utilizada no desenvolvimento deste trabalho Subversion O Subversion é um software livre para controle de versão. É utilizado tanto para o desenvolvimento de software livre como para fins corporativos (SUSSMAN, FITZPATRICK, PILATO, 2011). De acordo com o site do aplicativo ele é desenvolvido como um projeto da Apache Software Fundartion, e faz parte de uma grade comunidade de desenvolvedores e usuários. Tem o objetivo de gerenciar arquivos e diretórios, e as modificações feitas neles ao longo do tempo. Isto permite que você recupere versões antigas de seus dados, ou que

26 23 examine o histórico de suas alterações (SUSSMAN, FITZPATRICK, PILATO, 2011, p. 17). Em certo nível, a capacidade de várias pessoas modificarem e gerenciarem o mesmo conjunto de dados de seus próprios locais é o que fomenta a colaboração. Progressos podem ocorrer muito mais rapidamente quando não há um gargalo único por onde todas as modificações devam acontecer. E como o trabalho está versionado, você não precisa ter medo de que seu trabalho perca qualidade por não ter essa via única para modificações se os dados sofrerem alguma modificação indevida, apenas desfaça tal modificação. (SUSSMAN, FITZPATRICK, PILATO, 2011, p. 34). Abaixo estão relacionadas algumas características e benefícios do Subversion (SUSSMAN, FITZPATRICK, PILATO, 2011): a) controle do histórico de alterações; b) trabalho em equipe - Auxilia o trabalho em equipe, torna possível que diversas desenvolvedores trabalhem sobre o mesmo conjunto de documentos ao mesmo tempo. Mitiga o risco de conflitos de edições; c) marcação e resgate de versões estáveis Permite marcar uma versão estável do sistema, facilitando a sua localização no futuro; d) ramificação de projeto possibilita a divisão do projeto em várias linhas de desenvolvimento, que podem ser trabalhadas paralelamente, sem que uma interfira na outra Ramos de desenvolvimento (Branches) Segundo Sussman, Fitzpatrick e Pilato (2011) um ramo é uma linha de desenvolvimento que existe independente de outra linha, e ainda, partilham um histórico em comum. Um ramo sempre se inicia como cópia de outra linha de desenvolvimento e segue rumo próprio a partir deste ponto, gerando seu próprio histórico. Um exemplo é exibido na Figura 3. Fonte: Adaptado de Sussman, Fitzpatrick e Pilato (2011, p. 72). Figura 3 - Exemplo da utilização de ramos de desenvolvimento

27 24 O Subversion tem comandos para ajudar a controlar versões paralelas de um arquivo ou diretório. Ele permite você criar ramos copiando seus dados, e ainda lembra que as cópias têm relação entre si. Ainda é possível duplicar cópias de um ramo para outro. Finalmente, ele pode fazer com que partes de sua cópia de trabalho reflitam ramos diferentes, assim você pode misturar e combinar diferentes linhas de desenvolvimento no seu trabalho de dia-a-dia (SUSSMAN, FITZPATRICK, PILATO, 2011, p. 72). Um exemplo de como fica o repositório com a utilização de ramos é exibido na Figura 4: Fonte: Sussman, Fitzpatrick e Pilato (2011, p. 72). Figura 4- Retrato de um repositório após a criação de um ramo FinalBuilder O FinalBuilder é uma ferramenta integrada para automatizar os processos de compilação, teste e liberação. Com o FinalBuilder, pode-se definir, depurar, manter, executar e agendar um processo de construção de um software (FINALBUILDER, 2012). A Figura 5 exibe a interface do Finalbuilder.

28 25 Fonte: Finalbuilder (2012). Figura 5 - Interface do Finalbuilder FinalBuilder Server O FinalBuilder Server é uma interface para o FinalBuilder baseada na web que permite o gerenciamento centralizado de compilações automatizadas de software. Tem o objetivo de possibilitar aos membros da equipe de gerenciamento de configuração monitorar e controlar todas as suas compilações (FINALBUILDER, 2012). O FinalBuilder server pode dar inicio a compilação das seguintes maneiras (FINALBUILDER, 2012): a) horário agendado (por exemplo Segunda. a Sexta. às 01:00); b) interatividade um usuário pode dar inicio a compilação a qualquer momento; c) gatilho ao identificar mudanças no sistema de controle de versão Redmine O Redmine é um software livre, gerenciador de projetos baseados na web e ferramenta de gerenciamento de mudança. Ele contém calendário e gráfico de Gantt para ajudar na representação visual dos projetos e seus prazos de entrega. Ele pode também trabalhar com múltiplos projetos (REDMINE, 2012). O Redmine é escrito usando o framework Ruby on Rails. Ele é multiplataforma e

29 26 suporta diversos bancos de dados (REDMINE, 2012). Algumas das principais características do Redmine são (REDMINE, 2012): a) suporte a vários projetos; b) controle de acesso flexível baseado em papéis; c) sistema de rastreamento de tarefas; d) gráfico de gantt e calendário; e) gerenciamento de arquivos, notícias e documentos; f) notificações por feeds ou ; g) wiki por projeto; h) fórum por projeto; i) gerenciamento de tempo; j) possibilita a criação de campos personalizados para as tarefas, entradas de tempo, projetos e usuários; k) integração com sistemas de gerenciamento de configuração (SVN, CVS, Git, Mercurial, Bazaar e Darcs); l) criação de tarefas por ; m) suporte a autenticação múltipla LDAP; n) suporte a vários idiomas; o) suporte a vários banco de dados. 2.3 ITIL A Information Technology Infrastructure Library (ITIL) é composta por um conjunto das melhores práticas para a definição dos processos necessários ao funcionamento de uma área de TI. Tem o objetivo de fornecer o máximo alinhamento entre a área de TI e as demais áreas de negócio, de modo a garantir a geração de valor à organização (MAGALHÃES; PINHEIRO, 2007). Segundo Magalhães e Pinheiro (2007) a ITIL fornece uma forma de colocar os processos existentes em um contexto estruturado, validando suas atividades, tarefas, procedimentos e regas. Tornando evidentes as relações entre os processos da era de TI, sendo assim, qualquer falha de comunicação ou falta de cooperação entre as varias funções da érea de TI pode ser detectada. A ITIL fornece um comprovado guia para o planejamento de

30 27 processo padronizado, funções e atividades para os integrantes da equipe de TI, com referencias e linhas de comunicação apropriadas entre elas. Os processos do ITIL direcionadas a serviços podem ser subdivididos em: Suporte ao serviço e Entrega do Serviço. O escopo deste trabalho está direcionado ao Suporte a Serviços, mais especificamente no gerenciamento de liberação (GASPAR, 2011) Gerenciamento de Liberação Segundo Magalhães e Pinheiro (2007) o gerenciamento de liberação é o processo responsável pela implementação das mudanças no ambiente de produção de um conjunto de itens de configuração novos ou que sofreram alterações. Cada vez que são disponibilizadas melhorias ou alterações o gerenciamento de liberação tem a responsabilidade de introduzir às alterações no ambiente de trabalho como descreve o autor. Uma vez que uma ou mais mudanças são desenvolvidas, testadas e empacotadas para implementação, o processo de Gerenciamento de Liberação é responsável por introduzi-las na infraestrutura de TI e gerenciar as atividades relacionadas com tal liberação. (MAGALHÃES; PINHEIRO, 2007, p. 70). O processo de Gerenciamento de Liberação também contribui para aumentar a eficiência da introdução das mudanças no ambiente de produção, combinando-as em uma única liberação e realizando a implementação em conjunto (MAGALHÃES; PINHEIRO, 2007). A Figura 6 exibe o processo de gerenciamento de liberação.

31 28 act Processo de Gerenciamento de Liberação Início Identificação dos requisitos da liberação Autorizada? [Não] [Sim] Contrução da liberação Validada? Não Correção da liberação Sim Distribuir? Sim Não Executar procedimento de "back out" Não Implementar a liberação Aprovada? Sim Fim Fonte: Adaptado de Magalhães e Pinheiro (2007, p. 246). Figura 6 - Processo de Gerenciamento de Liberação Biblioteca de Software Definitivo A biblioteca de Software Definitivo é o local onde todas as versões autorizadas e definitivas de software da organização são armazenadas. Ela armazena as cópias-mestras de todos os softwares comprados (junto com os documentos de licenciamento), assim como as dos softwares desenvolvidos internamente (MAGALHÃES; PINHEIRO, 2007).

32 Indicadores de desempenho Segundo Magalhães e Pinheiro (2007) o processo de Gerenciamento de Liberação necessita prover pontos de controle que permitam avaliar sua eficiência, efetividade e economicidade. Estes pontos de controle são conhecidos como Key Performance Indicator (KPI). O Quadro 2 apresenta alguns indicadores de desempenho. Perspectiva Eficiência Eficácia Efetividade Economicidade Fonte: Magalhães e Pinheiro (2007, p. 258). Indicador Índice de evolução dos incidentes advindos das liberações realizadas. Índice de atualização dos ICs em produção. Índice de liberações implementadas dentro do prazo estabelecido. Índice de redução do prazo médio de implantação de liberações. Índice de liberações implementadas sem a necessidade de backout. Índice de satisfação dos usuários com a implantação das liberações. Índice de liberações realizadas dentro do orçamento acordado. Índice de cumprimento das exigências legais de licenciamento. Quadro 2 - Proposta de Indicadores de desempenho 2.4 SISTEMA ATUAL O sistema atual deixa uma grande margem para erros, pois ignora alguns cuidados vitais para o sucesso de uma modificação no sistema. As solicitações de mudança são realizadas por qualquer usuário do sistema, desta forma muitas delas são desnecessárias ou incoerentes com a regra de negócio proposto pelo sistema. A prioridade das mudanças é estabelecida de forma equivocada, sem uma análise detalhada do impacto que pode causar no sistema. A atualização dos clientes é feita de forma manual. Para isso é preciso realizar uma conexão remota em cada servidor, efetuar a autenticação no FTP, iniciar o download das atualizações, em alguns minutos, após o término do download o colaborador retorna a conexão para iniciar o processo de instalação das atualizações. Além disso, atualizações são realizadas diretamente no servidor de produção sem uma aprovação prévia em um ambiente de homologação, causando muitos problemas que podem ser evitados.

33 30 Para saber a versão utilizada por cada cliente é preciso conectar em cada servidor. A Figura 7 apresenta como é realizado o processo atual. act Sistema Atual Usuário Suporte Desenvolvimento Inicio Solicita uma Mudança Registra solicitação Implementa as modificações nescessárias Conecta no servidor do cliente Libera arquiv os envolv idos na mudança [Não] Faz a transferêcia dos arquivos Solicitação atendida? Atualiza Ambiente de produção [Sim] Fim Figura 7 - Fluxo do processo atual 2.5 TRABALHOS CORRELATOS Alguns trabalhos merecem ser destacados pela utilização da automatização da atualização de arquivos em sistemas de informações. Ambrosi (2004) apresenta a especificação e implementação de um protótipo para fazer atualização automática de arquivos. O autor apresentou uma solução auxiliada por um esquema de controle de versão e utilizando criptografia e algoritmos de resumo de mensagem para garantir a segurança e a integridade dos arquivos (AMBROSI, 2004). Samagaia (2007) apresenta a especificação e desenvolvimento de um ambiente web

34 31 para o gerenciamento de liberações baseada na recomendação ITIL. Dentro do processo do ITIL, o sistema utiliza as disciplinas de gerência da mudança, gerência da liberação e gerência da configuração. O autor apresenta também a utilização de shell que permite o monitoramento do processo de liberação, enviando um informativo aos usuários envolvidos durante o fluxo de aprovação. Borth (2005) apresenta a especificação e desenvolvimento de uma ferramenta de apoio à gerência de configuração de software baseado no modelo CMMI, com o objetivo de auxiliar uma empresa a gerenciar a configuração de software. O autor desenvolveu uma ferramenta voltada ao controle de mudanças, porém sem a utilização de algoritmos para controle de arquivos binários. O UpdateStar é uma ferramenta comercial que pode ser usado para manter aplicativos atualizado com as últimas versões de programas comerciais, gratuitos e Sharewares1. Tem uma base com mais de softwares cadastrados e foi eleito o melhor programa do gênero (CSIRT, 2008). No site do fabricante é possível baixar a ferramenta que possui limitações de uso. O sistema foi desenvolvido pela UPDATESTAR que em parceria com a O&O Software tem como foco o desenvolvimento de aplicativos para manutenção, recuperação, proteção e otimização de dados (UPDATESTAR, 2011). 1 Shareware é um programa de computador disponibilizado gratuitamente, porém com algum tipo de limitação (KIOSKEA, 2011).

35 32 3 DESENVOLVIMENTO Neste capítulo estão descritas as particularidades técnicas do sistema proposto tais como a descrição e a apresentação dos requisitos funcionais e não funcionais e principais diagramas. Conforme definido nos objetivos específicos propostos nesse trabalho, foi desenvolvida uma aplicação para facilitar a liberação de novas versões do software de gestão empresarial. 3.1 LEVANTAMENTO DE INFORMAÇÕES Para reunir informações e automatizar o processo de liberação, o trabalho desenvolvido faz a integração com um sistema de gestão empresarial, gerenciamento de configuração e gerenciamento de mudança. Utilizando práticas recomendas pelo CMMI a equipe de liberação, inicia o processo de liberação e faz a indicação dos arquivos de atualização. Automaticamente os arquivos indicados são disponibilizados em um FTP pelo servidor de atualizações. O servidor ainda tem a responsabilidade de autorizar o download dos arquivos solicitado pelos clientes via webservice. A partir do momento que a atualização é autorizada, os clientes fazem o download automático dos arquivos. Seguindo recomendações do processo de gerenciamento de liberação definido pelo ITIL, é dado inicio ao processo de atualização. Primeiramente em um servidor de homologação em seguida a atualização é enviada para o servidor de produção. A Figura 8 exibe o uma visão geral do trabalho desenvolvido.

36 33 Figura 8 - Visão geral do trabalho desenvolvido Este trabalho tem o objetivo de centralizar a atenção do responsável pela liberação na validação e acompanhamento da versão liberada. Foram inseridos alguns processos para ampliar o controle sobre as soluções desenvolvidas. A Figura 9 exibe uma visão geral do ciclo de vida de uma requisição de mudança realizada pelo cliente.

37 34 act Fluxo Usuário Chave/Membro da equipe Gerente de Projeto (PM) Responsável Gerente de Configuração (CM) Inicio Requisição de Mudança (Tarefa) Avaliar se a requisição é coerente, viável e nescessária. Avaliação Implementa as modificações nescessárias Define Situação (Autorizado) Realiza Testes/Validação Correção, Adaptação, Evolução Definir Classificação Atualiza tempo de trabalho Baixa, Normal, Alta, Urgente, Imediata Definir Prioridade Define Situação (Resolvido) Utilizar a tela de Gerenciamento de Liberações. Definir Categoria Atualiza Ambiente Homologação Libera Versão Analizar Impacto Realiza Testes/Validação Estabelacer Tempo Estimado Gera uma baseline Atribuir a uma versão Atribuir a um responsável Requisição atendida? [Não] Define Situação (Reaberto) [Sim] Define Situação (Concluído) [Não] Implementação OK? [Sim] Atualiza Ambiente Produção Define Situação (Homologação) Fim Criação de um Branch no Sistema de Controle de Versão (SCM) Figura 9 - Fluxo proposto por este trabalho A partir do momento que o cliente informa a necessidade de uma nova funcionalidade no sistema, o Analista faz o levantamento dos requisitos e regras de negócio para a alteração solicitada. Em seguida é realizada a estimativa de tempo e custo da alteração. Caso a solicitação seja aprovada pelo cliente, ela é registrada no sistema de controle de mudanças (redmine) e atribuída a um programador. Com o término do seu desenvolvimento, são

38 35 realizados testes unitários até que a correção esteja em condições de ser liberada para o cliente. Neste momento é realizada uma cópia da versão como o descrito na seção O objetivo deste processo é garantir que possíveis erros possam ser corrigidos após uma liberação para cliente, evitando a necessidade de liberar uma nova atualização antes da sua liberação oficial. Após serem realizados todos os testes de integração a nova versão está pronta para ser liberada. É neste momento que o aplicativo desenvolvido neste trabalho é utilizado. A equipe responsável pela liberação inicia o processo de liberação através da tela de Gerenciamento de liberações exibida na Figura Figura 10 - Tela de Gerenciamento de Liberações O aplicativo desenvolvido armazena um histórico com todas as liberações realizadas e os clientes que receberam cada atualização. Ao incluir uma nova liberação é exibida uma lista com todos os clientes envolvidos no projeto, o sistema faz a recomendação dos clientes aptos a receber a nova atualização exibindo-os na cor amarela, como é exibido na Figura As informações confidenciais exibidas na figura 10 foram ofuscadas.

39 36 Figura 11 - Fluxo do processo de liberação 3.2 ESPECIFICAÇÃO O Quadro 3 apresenta os requisitos funcionais previstos para o sistema e sua rastreabilidade, ou seja, vinculação com os casos de uso associados. Requisitos Funcionais RF01: O sistema deverá no módulo cliente verificar a disponibilidade de novas versões do software. RF02: O sistema deverá no módulo cliente baixar as atualizações do software. Caso de Uso UC01 UC02

40 37 RF03: O sistema deverá no módulo cliente iniciar a instalação das atualizações do software. RF04: O sistema deverá no módulo cliente notificar ao módulo servidor a versão atual do ERP. RF05: O sistema deverá no módulo servidor permitir o usuário efetuar o login no sistema. RF06: O sistema deverá no módulo servidor manter o cadastro de Atualizações (Código, Arquivo de atualização, Clientes Aptos). RF07: O sistema deverá no módulo servidor exibir uma lista de clientes aptos para a atualização. RF08: O sistema deverá no módulo servidor informar quais clientes poderão fazer a atualização. RF09: O sistema deverá no módulo servidor permitir ao usuário liberar a atualização. RF10: O sistema deverá no módulo servidor visualizar a versão atual utilizada pelos clientes. RF11: O sistema deverá no módulo servidor permitir a visualização do release note com as alterações contidas na atualização. RF12: O sistema deverá no módulo servidor permitir o envio do release note por Quadro 3 - Requisitos funcionais UC03 UC04 UC05 UC06 UC06 UC06 UC06 UC07 UC08 UC09 O Quadro 4 lista os requisitos não funcionais previstos para o sistema. Requisitos Não Funcionais RNF01: O sistema deverá rodar em sistema operacional Windows. RNF02: O sistema deverá ser desenvolvido em Delphi. RNF03: O sistema deverá utilizar banco de dados SQL Server. RNF04: O sistema deverá fazer integração com ERP via banco de dados. RNF05: O sistema deverá fazer o download das atualizações via FTP. RNF06: O sistema deverá fazer a comunicação entre os módulos via Web Service. Quadro 4 - Requisitos não funcionais

41 MODELAGEM proposto. Esta seção apresenta os diagramas necessários para o entendimento do sistema Diagrama de casos de uso Os diagramas de casos de usos desenvolvido neste trabalho são exibidos nas Figuras 12 e 13. Para o melhor entendimento do projeto, o detalhamento dos principais casos de uso (UC01, UC02, UC03, UC04, UC05, UC06, UC07, UC08, UC09), encontra-se no Apêndice A. Figura 12 - Diagrama de caso de uso do módulo cliente

42 39 Figura 13 - Diagrama de caso de uso módulo servidor Modelo de dados relacional Nesta subseção é exibido o Modelo de dados Relacional (MER), com base nas tabelas do aplicativo e seus relacionamentos. O dicionário de dados para especificar o sistema, é apresentado no Apêndice B. A Figura 14 exibe a estrutura de tabelas que fazer parte do módulo de gerenciamento utilizado para fazer a liberação das novas versões.

43 40 Figura 14 - Modelo de entidade relacional do ERP A Figura 15 exibe a estrutura de tabelas do redmine, onde as informações para a formulação do release note são extraídas. Figura 15 - Modelo de entidade relacional do redmine A Figura 16 exibe a estrutura utilizada pelo módulo cliente. Aqui são gravadas as informações das versões autorizadas para uso do cliente.

44 41 Figura 16 - Modelo de entidade relacional do cliente 3.4 IMPLEMENTAÇÃO A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da implementação Técnicas e ferramentas utilizadas Para o desenvolvimento do módulo gerencial foi utilizado a ferramenta Delphi na versão 7.0. A opção por esta versão foi influenciada pela necessidade de manter a mesma ferramenta utilizada no desenvolvimento do ERP, facilitando a integração. Para o desenvolvimento dos módulos cliente e servidor foi utilizado o Delphi na versão Xe2, versão atualmente comercializada desenvolvida pela Embarcadero Tecnologies. A Figura 17 exibe arquivo WSDL gerado pelo Delphi.

45 42 Figura 17 - Arquivo WSDL gerado pelo Delphi Xe2 No webservice apenas o método SolicitaVersao foi publicado. Este método tem o objetivo de identificar o cliente que está solicitando uma nova versão, registrar a versão atualmente utilizada, e disponibilizar informações para início do download dos arquivos caso exista algo disponível para o cliente solicitante. A Figura 18 exibe a implementação do método SolicitaVersao.

46 43 Figura 18- Implementação do método SolicitaVersao publicada pelo webservice Operacionalidade da implementação Nesta subseção serão exibidas as informações necessárias para a correta utilização do aplicativo desenvolvido. O sistema de atualização desenvolvido neste trabalho é composto por três aplicativos. A seguir será detalhada a função de cada um dos aplicativos Gerenciador de atualizações (Cliente/Servidor) O gerenciador de atualizações é o principal módulo do sistema de atualização. É através dele que o usuário realiza a liberação de uma nova atualização e visualiza informações inerentes a atualizações anteriormente realizadas. Para ter acesso ao aplicativo é necessário efetuar o login com uma credencial já

47 44 existente no ERP. A Figura 19 exibe detalhes do processo de login. Figura 19 - Tela de login do usuário A partir deste momento o usuário já tem acesso à tela de gerenciamento de atualizações. Em seguida é exibido um histórico com todas as atualizações realizadas e informações sobre quais clientes receberam a atualização, mais detalhes é exibido na Figura Figura 20 - Tela de gerenciamento de liberações 3 As informações confidenciais exibidas na figura 20 foram ofuscadas.

48 45 Ao clicar na opção incluir uma mensagem é exibida fornecendo a opção de ciar ou não um novo release. Esta opção é utilizada para relacionar uma liberação à outra. Caso a liberação inserida seja uma liberação com novas funcionalidades e não apenas correções desenvolvidas para estabilizar uma versão já existente o usuário deve clicar em SIM. A opção relatada é exibida na Figura 21. Figura 21 - Opção para criar um novo release A partir desse momento é iniciado o processo de liberação. O aplicativo faz uma consulta no sistema de gerenciamento de configuração (ver seção 2.2.1), e traz o build atual. Essa informação é utilizada para identificar o exato momento em que a versão foi liberada. Sendo assim, caso uma manutenção futura seja necessária, a equipe de desenvolvimento tem o endereço exato para retornar ao ambiente de trabalho na qual esta versão foi liberada. Em seguida é exibida uma lista de clientes envolvidos no projeto. O sistema destaca os clientes que devem receber atualização em amarelo. A recomendação é feita com base nas tarefas concluídas no aplicativo de gerenciamento de mudança redmine (ver seção ). Além de destacar os clientes recomendados a receber a atualização, o sistema disponibilizar a opção para marcar todos os clientes sugeridos. A Figura 22 exibe maiores detalhes sobre esta opção.

49 46 Figura 22 - Relação de clientes aptos a receber a atualização 4 Na guia Release Notes é exibida uma lista de alterações que serão liberadas com a versão. São exibidas informações como tipo de alteração, cliente, título, código da tarefa e um comentário previamente formatado pelo usuário que finalizou a tarefa. A ferramenta possibilita alterar o agrupamento das informações, fornecendo diferentes visões dos dados listados. Da mesma forma que é feita a sugestão dos clientes recomendados a receber a atualização, toda a informação utilizada para formar o release note é extraída do redmine. O sistema permite o envio do release note via . Para isso, na guia release note é preciso clicar na opção . Em seguida é necessário informar o endereço, assunto e clicar em Enviar. O processo de envio do release note via é exibido na Figura As informações confidenciais exibidas na figura 22 foram ofuscadas.

50 47 Figura 23 - Tela de envio de do release note a sua origem. Cada registro do release note possui um código de tarefa, com uma opção de localizar A Figura 24 apresenta em detalhes as funcionalidades descritas. Figura 24 - Tela de release notes com a opção de buscar a origem de cada registro

51 48 Após ter visualizado as novidades da nova versão e selecionado os clientes que vão receber a nova atualização é hora de indicar o arquivo de atualização. Nesta etapa é fundamental a atenção do usuário, pois o arquivo indicado vai ser distribuído para todos os clientes selecionados. A indicação de um arquivo errado pode arruinar toda a estratégia de liberação. Toda atualização precisa ter uma arquivo relacionado. Caso isso não seja realizado o sistema irá exibir a mensagem exibida na Figura 25. Figura 25 - Aviso do sistema caso o arquivo de atualização não for informado Para indicar o arquivo, o sistema disponibiliza uma opção localizada na parte superior da tela de gerenciamento de atualizações. Como é exibido na Figura 26. Figura 26 - Caixa de dialogo utilizada para informar o arquivo de atualização

52 49 Com todas as informações devidamente preenchidas o usuário deve clicar em salvar. Concluindo assim o processo de liberação Servidor de atualizações O servidor de atualizações é responsável por disponibilizar os arquivos da atualização, e fornecer a comunicação com os clientes de atualização via webservice. A partir do momento que uma liberação é incluída pelo gerenciador de atualizações, o servidor de atualizações identifica a nova liberação e faz o upload dos arquivos indicados pelo o usuário. A Figura 27 retrata o momento em que é realizado o upload de um arquivo de atualização. Figura 27 - Tela do servidor de atualizações A porta pela qual a comunicação entre cliente e servidor é estabelecida é definida no campo porta, como é exibido na Figura 27. Esta porta pode ser alterada antes do servidor ser iniciado, lembrando que, independente da porta utilizada, será necessário uma liberação no firewall, para possibilitar a comunicação dos clientes em ambientes externos à infraestrutura da empresa Cliente de atualizações O Cliente de atualizações é responsável por solicitar a disponibilidade de novas atualizações de software, enviar informações de número de série e versão atualmente utilizada pelo cliente. Além disso, ele armazena as versões disponibilizadas em um local específico, chamado de Biblioteca Definitiva de Software (ver seção ). Este aplicativo deve estar instalado em todos os clientes que possam receber novas atualizações.

53 50 Periodicamente ele envia solicitações ao servidor, com a intenção de identificar a disponibilidade de uma nova versão do software. A partir do momento que uma nova versão é disponibilizada o aplicativo inicia o download dos arquivos de atualização, conforme exibido na Figura 28. Figura 28 - Tela do cliente de atualização Após o término do download da atualização um novo registro é inserido na biblioteca definitiva de software com os dados relacionado à nova atualização. A partir deste momento a extração dos arquivos pode ser iniciada através de um duplo clique no registro da biblioteca conforme exibido na Figura 29.