APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM...

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 2012

2012/1-12




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 2012

2012/1-12



Por


Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Cláudio Ratke, Mestre – Orientador, FURB

______________________________________________________ Membro: Prof. Oscar Dalfovo, Doutor – FURB

______________________________________________________ Membro: Prof. Mauro Marcelo Mattos, Doutor – FURB

Blumenau, 02 de julho de 2012.

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

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.

Os bons livros fazem “sacar” para fora o que a pessoa tem de melhor dentro dela.

Lina Sotis Francesco Moratti

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.

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.

LISTA DE FIGURAS

Figura 1 - Formulário de requisição de mudança utilizando a ferramenta redmine ................. 18

Figura 2 - Processo de gerenciamento de mudança .................................................................. 19

Figura 3 - Exemplo da utilização de ramos de desenvolvimento ............................................. 23

Figura 4- Retrato de um repositório após a criação de um ramo .............................................. 24

Figura 5 - Interface do Finalbuilder ......................................................................................... 25

Figura 6 - Processo de Gerenciamento de Liberação ............................................................... 28

Figura 7 - Fluxo do processo atual ........................................................................................... 30

Figura 8 - Visão geral do trabalho desenvolvido ...................................................................... 33

Figura 9 - Fluxo proposto por este trabalho ............................................................................. 34

Figura 10 - Tela de Gerenciamento de Liberações ................................................................... 35

Figura 11 - Fluxo do processo de liberação .............................................................................. 36

Figura 12 - Diagrama de caso de uso do módulo cliente.......................................................... 38

Figura 13 - Diagrama de caso de uso módulo servidor ............................................................ 39

Figura 14 - Modelo de entidade relacional do ERP.................................................................. 40

Figura 15 - Modelo de entidade relacional do redmine ............................................................ 40

Figura 16 - Modelo de entidade relacional do cliente .............................................................. 41

Figura 17 - Arquivo WSDL gerado pelo Delphi Xe2 .............................................................. 42

Figura 18- Implementação do método SolicitaVersao publicada pelo webservice .................. 43

Figura 19 - Tela de login do usuário......................................................................................... 44

Figura 20 - Tela de gerenciamento de liberações ..................................................................... 44

Figura 21 - Opção para criar um novo release.......................................................................... 45

Figura 22 - Relação de clientes aptos a receber a atualização .................................................. 46

Figura 23 - Tela de envio de e-mail do release note ................................................................ 47

Figura 24 - Tela de release notes com a opção de buscar a origem de cada registro ............... 47

Figura 25 - Aviso do sistema caso o arquivo de atualização não for informado ...................... 48

Figura 26 - Caixa de dialogo utilizada para informar o arquivo de atualização ....................... 48

Figura 27 - Tela do servidor de atualizações ............................................................................ 49

Figura 28 - Tela do cliente de atualização ................................................................................ 50

Figura 29 - Biblioteca definitiva de software ........................................................................... 51

Figura 30 - Resumo das respostas da questão 1 ....................................................................... 52



Figura 33- Resumo das respostas da questão 4 ........................................................................ 52


Figura 35 - Formulário de avaliação do trabalho desenvolvido ............................................... 66

LISTA DE QUADROS

Quadro 1 - Fatores que influenciam a estratégia de sistema de release ................................... 21

Quadro 2 - Proposta de Indicadores de desempenho ................................................................ 29

Quadro 3 - Requisitos funcionais ............................................................................................. 37

Quadro 4 - Requisitos não funcionais ...................................................................................... 37

Quadro 5 - Caso de uso Verifica atualizações disponíveis ....................................................... 58

Quadro 6 - Caso de uso Baixa atualizações disponíveis .......................................................... 59

Quadro 7 - Caso de uso Iniciar a Instalação das atualizações .................................................. 60

Quadro 8 - Caso de uso Notifica versão atual .......................................................................... 61

Quadro 9 - Caso de uso Efetuar Login ..................................................................................... 62

Quadro 10 - Caso de uso Efetuar Login ................................................................................... 63

Quadro 11 - Caso de uso Consultar versões instaladas ............................................................ 64

Quadro 12 - Caso de uso Visualizar release notes ................................................................... 64

Quadro 13 – Caso de uso Enviar e-mail de release notes ........................................................ 65

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

SUMÁRIO

1 INTRODUÇÃO .................................................................................................................. 12

1.1 OBJETIVOS DO TRABALHO ......................................................................................... 12

1.2 ESTRUTURA DO TRABALHO ....................................................................................... 13

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14

2.1 SISTEMA DE GESTÃO EMPRESARIAL ...................................................................... 14

2.2 CAPABILITY MATURY MODEL INTEGRATION (CMMI) ....................................... 15

2.2.1 Gerenciamento de configuração ...................................................................................... 15

2.2.1.1 Itens de configuração (ICs)........................................................................................... 16

2.2.1.2 Linhas de base .............................................................................................................. 16

2.2.2 Gerenciamento de mudanças ........................................................................................... 17

2.2.3 Gerenciamento de versões e releases............................................................................... 19

2.2.3.1 Gerenciamento de releases ........................................................................................... 20

2.2.4 Integração Contínua ......................................................................................................... 21

2.2.5 Ferramentas de apoio ....................................................................................................... 22

2.2.5.1 Subversion .................................................................................................................... 22

2.2.5.1.1 Ramos de desenvolvimento (Branches) .................................................................... 23

2.2.5.2 FinalBuilder ................................................................................................................. 24

2.2.5.2.1 FinalBuilder Server ................................................................................................... 25

2.2.5.3 Redmine ........................................................................................................................ 25

2.3 ITIL.................................................................................................................................... 26

2.3.1 Gerenciamento de Liberação........................................................................................... 27

2.3.1.1 Biblioteca de Software Definitivo ................................................................................ 28

2.3.1.2 Indicadores de desempenho .......................................................................................... 29

2.4 SISTEMA ATUAL ........................................................................................................... 29

2.5 TRABALHOS CORRELATOS ........................................................................................ 30

3 DESENVOLVIMENTO .................................................................................................... 32

3.1 LEVANTAMENTO DE INFORMAÇÕES ....................................................................... 32

3.2 ESPECIFICAÇÃO ............................................................................................................. 36

3.3 MODELAGEM .................................................................................................................. 38

3.3.1 Diagrama de casos de uso ................................................................................................ 38

3.3.2 Modelo de dados relacional ............................................................................................. 39

3.4 IMPLEMENTAÇÃO ......................................................................................................... 41

3.4.1 Técnicas e ferramentas utilizadas .................................................................................... 41

3.4.2 Operacionalidade da implementação ............................................................................... 43

3.4.2.1 Gerenciador de atualizações (Cliente/Servidor) ........................................................... 43

3.4.2.2 Servidor de atualizações ............................................................................................... 49

3.4.2.3 Cliente de atualizações ................................................................................................. 49

3.5 RESULTADOS E DISCUSSÃO ....................................................................................... 51

4 CONCLUSÕES .................................................................................................................. 54

4.1 EXTENSÕES .................................................................................................................... 54

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 56

APÊNDICE A – Descrição dos Casos de Uso ...................................................................... 58

ANEXO A – Formulário de avaliação do trabalho desenvolvido ...................................... 66

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.

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.

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).

15

2.2 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).

2.2.1 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.

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).

2.2.1.1 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.

2.2.1.2 Linhas de base

Segundo Couto (2007) uma linha de base ou baseline é um conjunto de especificações

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).

2.2.2 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.

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.

19

Fonte: Sommerville (2003, p. 555).

Figura 2 - Processo de gerenciamento de mudança

2.2.3 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 2.2.1.3). 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;

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 2.2.5.

2.2.3.1 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.

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 Descrição Qualidade técnica do sistema 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.

Quinta ler de Lehman Quando houver uma mudança significativa no software ela poderá ser seguida de um release de correção.

Competição Quando um produto concorrente está disponível. Requisitos de mercado 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

2.2.4 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

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 e-mail, 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).

2.2.5 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.

2.2.5.1 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

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.

2.2.5.1.1 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

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

2.2.5.2 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.

25

Fonte: Finalbuilder (2012).

Figura 5 - Interface do Finalbuilder

2.2.5.2.1 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.

2.2.5.3 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

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 e-mail;

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 e-mail;

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

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).

2.3.1 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.

28

act Processo de Gerenciamento de Liberação

Início

Identificação dosrequisitos da liberação

Contrução da liberação

Autorizada?

Validada?

Distribuir?

Implementar a liberação

Correção da liberação

Executar procedimentode "back out"

Aprovada?

Fim

Não

[Não]

Sim

Não

Não

Sim

Sim

[Sim]

Fonte: Adaptado de Magalhães e Pinheiro (2007, p. 246).

Figura 6 - Processo de Gerenciamento de Liberação

2.3.1.1 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).

29

2.3.1.2 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 Indicador

Eficiência Índice de evolução dos incidentes advindos das liberações realizadas. Índice de atualização dos ICs em produção.

Eficácia Índice de liberações implementadas dentro do prazo estabelecido. Índice de redução do prazo médio de implantação de liberações.

Efetividade Índice de liberações implementadas sem a necessidade de backout. Índice de satisfação dos usuários com a implantação das liberações.

Economicidade Índice de liberações realizadas dentro do orçamento acordado. Índice de cumprimento das exigências legais de licenciamento.

Fonte: Magalhães e Pinheiro (2007, p. 258).

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.

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 asmodificaçõesnescessárias

Libera arquiv osenvolv idos na mudança

Atualiza Ambiente deprodução

Solicitação atendida?

Fim

Conecta no serv idor docliente

Faz a transferêcia dosarquivos

[Sim]

[Não]

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

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 80.000 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).

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.

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.

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)

Avaliação

Definir Classificação

Definir Prioridade

Correção, Adaptação, Evolução

Baixa, Normal, Alta, Urgente,

Imediata

Analizar Impacto

Avaliar se a requisição é

coerente, viável e nescessária.

Estabelacer TempoEstimado

Atribuir a uma versão

Atribuir a um responsável

Definir Categoria

Implementa asmodificaçõesnescessárias

Realiza Testes/Validação

Atualiza tempo detrabalho

Gera uma baseline

Implementação OK?

Define Situação(Resolv ido)

Define Situação(Autorizado)

Define Situação(Reaberto)

Define Situação(Homologação)

Libera VersãoAtualiza AmbienteHomologação

Realiza Testes/Validação

Requisição atendida?

Atualiza AmbienteProdução

Define Situação(Concluído)

Fim

Util izar a tela de Gerenciamento

de Liberações.

Criação de um Branch no

Sistema de Controle de Versão

(SCM)

[Não]

[Sim]

[Não]

[Sim]

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

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 2.2.5.1.

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 102.

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 11.

2 As informações confidenciais exibidas na figura 10 foram ofuscadas.

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 Caso de Uso

RF01: O sistema deverá no módulo cliente verificar a disponibilidade de

novas versões do software.

UC01

RF02: O sistema deverá no módulo cliente baixar as atualizações do

software.

UC02

37

RF03: O sistema deverá no módulo cliente iniciar a instalação das

atualizações do software.

UC03

RF04: O sistema deverá no módulo cliente notificar ao módulo servidor

a versão atual do ERP.

UC04

RF05: O sistema deverá no módulo servidor permitir o usuário efetuar o

login no sistema.

UC05

RF06: O sistema deverá no módulo servidor manter o cadastro de

Atualizações (Código, Arquivo de atualização, Clientes Aptos).

UC06

RF07: O sistema deverá no módulo servidor exibir uma lista de clientes

aptos para a atualização.

UC06

RF08: O sistema deverá no módulo servidor informar quais clientes

poderão fazer a atualização.

UC06

RF09: O sistema deverá no módulo servidor permitir ao usuário liberar a

atualização.

UC06

RF10: O sistema deverá no módulo servidor visualizar a versão atual

utilizada pelos clientes.

UC07

RF11: O sistema deverá no módulo servidor permitir a visualização do

release note com as alterações contidas na atualização.

UC08

RF12: O sistema deverá no módulo servidor permitir o envio do release

note por e-mail

UC09

Quadro 3 - Requisitos funcionais

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

38

3.3 MODELAGEM

Esta seção apresenta os diagramas necessários para o entendimento do sistema

proposto.

3.3.1 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

39

Figura 13 - Diagrama de caso de uso módulo servidor

3.3.2 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.

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.

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.

3.4.1 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.

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.

43

Figura 18- Implementação do método SolicitaVersao publicada pelo webservice

3.4.2 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.

3.4.2.1 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á

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

203.

Figura 20 - Tela de gerenciamento de liberações


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 2.2.5.3).

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.

46

Figura 22 - Relação de clientes aptos a receber a atualização

4Na 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 e-mail. Para isso, na guia release note é

preciso clicar na opção “E-Mail”. Em seguida é necessário informar o endereço, assunto e

clicar em “Enviar”. O processo de envio do release note via e-mail é exibido na Figura 23.


47

Figura 23 - Tela de envio de e-mail do release note

Cada registro do release note possui um código de tarefa, com uma opção de localizar

a sua origem.

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

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

49

Com todas as informações devidamente preenchidas o usuário deve clicar em salvar.

Concluindo assim o processo de liberação.

3.4.2.2 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.

3.4.2.3 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 2.3.1.1). Este aplicativo deve estar

instalado em todos os clientes que possam receber novas atualizações.

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.

51

Figura 29 - Biblioteca definitiva de software

Após a extração dos arquivos é dado início a atualização dos arquivos e banco de

dados entre outras funcionalidades as quais não fazem parte do escopo deste trabalho.

3.5 RESULTADOS E DISCUSSÃO

Para obter uma avaliação da opinião dos envolvidos no projeto, foi elaborado um

formulário utilizando a Ferramenta Google Docs. Sete pessoas responderam ao questionário,

entre elas 57% tem mais de 10 anos de experiência na área de TI. O resultado obtido foi

satisfatório, levando em consideração o grau de experiência e envolvimento dos entrevistados,

além de respostas positivas. Ficou evidente que as melhorias proporcionadas por este trabalho

são facilmente identificadas.

Os detalhes dos resultados obtidos podem ser visualizados nas Figuras 30, 31, 32, 33 e

34.

52

Figura 30 - Resumo das respostas da questão 1



Figura 33- Resumo das respostas da questão 4


53

Em comparação com os trabalhos correlatos, a ferramenta apresentou grande

vantagem, principalmente por fazer a integração e extração de dados de ferramentas de apoio

largamente utilizadas no processo de gerenciamento de configuração e gerenciamento de

mudança. Além de automatizar o processo de atualização a ferramenta fornece dados

essenciais para o planejamento de liberação de novos releases.

54

4 CONCLUSÕES

Neste trabalho foi proposto o desenvolvimento de um aplicativo que automatiza o

processo de liberação de software. Auxiliando os membros da equipe de liberação a

identificar os clientes aptos a receber a nova atualização, monitorar a versão utilizada por cada

cliente, além de manter um histórico de todas as liberações efetuadas pela empresa. O

aplicativo ainda faz a integração com o sistema de projetos redmine, extraindo informações

utilizadas na criação de release notes de cada liberação. Para concluir foi adicionado a

possiblidade de enviar por e-mail a relação de modificações contidas em cada liberação.

Utilizando conceitos recomendados pelas metodologias ITIL e CMMI o trabalho

alcançou todos os seus objetivos, além de auxiliar na elaboração de um novo fluxo de

trabalho, que proporciona objetividade e define responsabilidade sobre cada etapa do processo

de requisição de mudança, fornecendo um ganho de qualidade e maior controle dos serviços

prestados.

As ferramentas e tecnologias utilizadas foram adequadas, atendendo todas as

exigências para o sucesso deste projeto.

A realização deste trabalho contribuiu para a expansão dos conhecimentos sobre as

metodologias ITIL e CMMI, que foram elementos essenciais para guiar o objetivo deste

trabalho. Além disso, novas oportunidades foram identificadas, despertando o interesse pelas

demais áreas tratadas por estas metodologias.

4.1 EXTENSÕES

Para ampliar a utilidade da ferramenta desenvolvida neste trabalho, recomenda-se a

criação de indicadores de qualidade, para possibilitar o comparativo da evolução da qualidade

dos processos. Alguns indicadores recomendados são:

a) a quantidade de retornos identificados no ambiente de homologação;

b) a quantidade de retornos identificados na qualidade;

c) o número de incidentes causados por cada atualização.

Outra recomendação para trabalhos futuro é a automatização do envio de e-mail em

55

cada etapa da liberação.

Ao iniciar uma liberação, na etapa de homologação o sistema deve enviar um e-mail

com a lista de tarefas resolvidas para todos os contatos envolvidos na homologação. A partir

do momento que todas as tarefas estão homologadas, consequentemente a versão está apta a

ser atualizada no ambiente de produção. Neste momento um novo e-mail deve ser enviado aos

contatos da gerência. Fazendo com que todas as mudanças efetuadas no sistema sejam

notificadas a todos os envolvidos.

56

REFERÊNCIAS BIBLIOGRÁFICAS

AMBROSI, Airison. Protótipo de software para atualização automática de versão de arquivos. 2004. 43 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) - Universidade Regional de Blumenau, Blumenau.

BECTA, Advice. FITS Release Management. [S.I.], 2004. Disponível em: <http://www.becta.org.uk/tsas/docs/fits_release.pdf>. Acessado em: 27 maio 2012.

BON, Jan V. Fundamentos do gerenciamento de serviços em TI baseado no ITIL. 1. ed. Tradução Van Haren Publishing. Holanda, 2006.

BORTH, André. Ferramenta de apoio a gerência de configuração de software baseado no modelo CMMI. 2005. 82 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) - Universidade Regional de Blumenau, Blumenau.

CAELUM. Integração contínua e o processo Agile. Rio de Janeiro, 2008. Disponível em: < http://blog.caelum.com.br/integracao-continua>. Acessado em: 10 jun. 2012.

CARVALHO, Ricardo. Auto-atualização de aplicativos em delphi. [S.l.], 2012. Disponível em: < http://edn.embarcadero.com/br/article/33973>. Acessado em: 27 maio 2012.

CIGAM. ERP. Novo Hamburgo, 2012. Disponível em <http://www.cigam.com.br/erp/>. Acessado em 11 maio 2012.

COLLINS, Ben; FITZPATRICK, Brian; PILATO, C. Version control with subversion: For subversion 1.4. California: TBA, 2007. 348 p.

COUTO, Ana Brasil. CMMI: integração dos modelos de capacitação e maturidade de sistemas. Rio de Janeiro: Ciência Moderna, 2007. XIII, 276 p.

CSIRT, PoP-MG. Mantendo sistemas operacionais atualizados. [S.l.], 2008. Disponível em: < http://www.csirt.pop-mg.rnp.br/docs/so/atualizacao.html>. Acesso em: 27 abr. 2012.

ESTUBLIER, J. Software Configuration Management: Proceedings of the Conference on The Future of Software Engineering. Ireland: Limerick, 2000.

FINALBUILDER. Finalbuilder. Camberra, 2012. Disponível em: <http://www.finalbuilder.com/finalbuilder.aspx>. Acessado em: 13 maio 2012.

FOWLER, Martin. Continuous integration. Chicago, 2006. Disponível em: <http://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 10 jun. 2012.

57

GASPAR, Marcelo; GOMES, Thierry; MIRANDA, Zailton. T. I. Mudar e Inovar: Resolvendo conflitos com ITIL V3 – aplicando a um estudo de caso. 2. ed. Distrito Federal: Senac, 2011.

HABERKORN, Ernesto M. Teoria do ERP - Enterprise Resource Planning. São Paulo: Makron Books, 1999. 332 p.

KIOSKEA. O que é um software shareware. [S.l.], 2011. Disponível em: < http://pt.kioskea.net/faq/5208-o-que-e-um-software-shareware>. Acessado em: 10 mar. 2012.

MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de serviços de TI na prática: uma abordagem com base na ITIL. São Paulo: Novatec, 2007. 667 p.

MELLON, Carnegie. CMMI para desenvolvimento – Versão 1.2. [S.l.], 2006. Disponível em: <http://www.sei.cmu.edu/library/>. Acessado em: 26 maio 2012.

PFLEEGER, Shari L. Engenharia de software: Teoria e prática. 2. ed. Tradução Prentice Hall do Brasil, 2004.

REDMINE. Redmine. Cidade, 2012. Disponível em: <http://www.redmine.org/>. Acessado em: 13 maio 2012.

SAMAGAIA, Jeferson, R. Sistema de gerenciamento de controle de liberação de versão de sistemas web baseado na recomendação ITIL utilizando SHELL UNIX. 2007. 93 f. Trabalho de Conclusão de Curso (Bacharel em Ciências da Computação) - Universidade Regional de Blumenau, Blumenau.

SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison Wesley, 2003. XVI, 592 p.

SUSSMAN, Ben; FITZPATRICK, Brian; PILATO, C. Version control with subversion: For subversion 1.7. California: TBA, 2011. 441 p.

UPDATESTAR. Updatestar. Berlin, 2011. Disponível em: <http://client.updatestar.com/en/updatestar/features/>. Acesso em: 10 mar. 2012.

58

APÊNDICE A – Descrição dos Casos de Uso

Este Apêndice apresenta a descrição dos casos de uso conforme previstos no(s) diagrama(s) apresentado(s) na seção 3.3.1. Os Quadros de 6 a 13 apresentam a descrição dos mesmos.

UC01 Verificar atualizações disponíveis

Descrição Permite ao Gerente de TI verificar a disponibilidade de novas atualizações.

Ator Gerente de TI

Pré-condição O servidor no qual o AppUpdade Client está rodando deverá estar conectado a internet.

Fluxo Principal 1 - Gerente de TI clica em “Verificar Atualizações”; 2 - Sistema verifica a disponibilidade de novas atualizações; 3 - Sistema exibe a mensagem “Existem atualizações disponíveis”; 4 - Gerente TI clica em “OK”.

Fluxo Alternativo • Nos passo 3, o sistema pode retornar que não há atualizações disponíveis, caso isso ocorra o Gerente de TI poderá voltar a executar o passo 1 assim mais tarde.

Pós-Condição Gerente Ti verificou a disponibilidade de novas atualizações.

Quadro 5 - Caso de uso Verifica atualizações disponíveis

59

UC02 Baixar atualizações disponíveis

Descrição Permite ao Gerente de TI iniciar o download das atualizações disponíveis.

Ator Gerente de TI

Pré-condição O servidor no qual o AppUpdade Client está instalado deverá estar conectado a internet. A execução do UC1 deverá ter retornado positivo a existência de novas atualizações. O servidor no qual o AppUpdade Client está instalado deverá ter espaço suficiente em disco.

Fluxo Principal 1. Gerente de TI clica em “Baixar Atualizações”;

2. Sistema iniciar o download das atualizações;

3. Sistema exibe o progresso do download;

4. Sistema exibe a mensagem “Download concluido, a atualização está pronta para ser executada”;

5. Gerente TI clica em “OK”.

Pós-Condição Gerente Ti efetuou o download das atualizações disponíveis.

Quadro 6 - Caso de uso Baixa atualizações disponíveis

60

UC03 Iniciar a Instalação das atualizações

Descrição Permite ao Gerente de TI iniciar a instalação das atualizações

Ator Gerente de TI

Pré-condição O Pack de atualização já deve ter sido baixado. Os arquivos que serão atualizados não devem estar em uso por outro processo ou usuário.

Fluxo Principal 1 - Gerente de TI clica em “Iniciar Atualização”; 2 – Gerente de TI verifica a existência de usuários ativos no ERP; 3 - Sistema inicia o Pack de atualização para que o gerente de TI prossiga a atualização.

Fluxo Alternativo • Nos passo 2, pode ser identificado existência de usuários ativos no ERP, nesse casso todos devem sair do sistema para que o Gerente de TI recomece a atualização executando novamente o passo 1.

Pós-Condição Gerente TI Iniciou a instalação do Pack de Atualização.

Quadro 7 - Caso de uso Iniciar a Instalação das atualizações

61

UC04 Notificar versão atual

Descrição Permite ao Gerente de TI informar ao AppUpdate Manager a verão atual do ERP.

Ator Gerente de TI

Pré-condição O servidor no qual o AppUpdade Client está instalado deverá estar conectado a internet.

Fluxo Principal 1. Gerente de TI clica em “Notificar Versão Atual”;

2. Sistema envia as informações ao AppUpdade Manager;

3. Sistema exibe a mensagem “Notificação enviada”;

4. Gerente TI clica em “OK”.

Pós-Condição Gerente TI enviou as informações da ultima atualização para o AppUpdade Manager.

Quadro 8 - Caso de uso Notifica versão atual

62

UC05 Efetuar login

Descrição Permite ao usuário efetuar o login no sistema.

Ator Usuário

Pré-condição Usuário deve estar cadastrado no banco de dados.

Fluxo Principal 1 - Usuário informa login e senha e clica em “confirmar”. 2 - Sistema valida os dados de login informados pelo usuário; 3 - Sistema habilita os controles da tela principal.

Fluxo Alternativo • No passo 1, pode haver um erro ao validar os dados de login;

• Sistema exibe mensagem “Usuário ou senha inválida”.

Pós-Condição A permissão de controle da tela principal é concebida ao usuário.

Quadro 9 - Caso de uso Efetuar Login

63

UC06 Cadastra Pack de Atualização

Descrição Permite ao Usuário cadastrar um novo Pack de atualização e definir Clientes Aptos ao recebimento das atualizações.

Ator Usuário

Pré-condição O usuário deve estar logado no sistema.

Fluxo Principal 1 – Usuário clica em “Incluir Pack”; 2 – Sistema lista os clientes aptos a receber a atualização. 3 – Usuário informa o local do arquivo de atualização; 4 – Usuário define quais clientes receberão a atualização; 5 – Usuário clica em “Salvar”

Fluxo Alternativo • No passo 5, caso o local do arquivo não foi informada, o sistema irá exibir a mensagem “Arquivo de atualização não foi informado”;

• No passo 5, caso o nenhum cliente for selecionado, o sistema irá exibir a mensagem “Ao menos um cliente deve ser informado”.

Cenário - Liberação

6 – Usuário clica em “Liberar atualização”; 7 – Sistema exibe a mensagem “Atualização liberada com sucesso”.

Cenário - Bloqueio

6 – Usuário clica em “Bloquear atualização”; 7 – Sistema exibe a mensagem “Atualização bloqueada com sucesso”.

Cenário - Edição 1 - Usuário clica em “Alterar”. 2 - Sistema habilita a alteração do registro atual. 3 - Usuário faz as alterações necessárias. 4 - Usuário clica em “Salvar”;

Pós-Condição A versão é disponibilizada para download através do ApppUpdade

Client para os clientes selecionados.

Quadro 10 - Caso de uso Efetuar Login

64

UC07 Consultar versões instaladas

Descrição Permite ao Usuário visualizar qual a data da ultima atualização e versão utilizada por cada cliente.

Ator Usuário


Fluxo Principal 1 – Usuário clica em “Consultar versão clientes”; 2 – Sistema lista todos os clientes e a versão utilizada por cada um deles;

Pós-Condição As informações sobre a versão utilizada pelos clientes é exibida.

Quadro 11 - Caso de uso Consultar versões instaladas

UC08 Visualizar release notes

Descrição Permite ao Usuário visualizar a lista de tarefas resolvidas para a versão que está sendo liberada.

Ator Usuário


Fluxo Principal 1 – Usuário clica em “Release Notes”; 2 – Sistema lista todas as tarefas relacionadas a versão e faz uma agrupamento por cliente e tipo de tarefa.

Pós-Condição As informações sobre a tarefas relacionadas a versão serão exibidas

Quadro 12 - Caso de uso Visualizar release notes

65

UC09 Enviar e-mail de release notes

Descrição Permite ao Usuário enviar a lista de tarefas resolvidas por e-mail

Ator Usuário


Fluxo Principal 1 - Usuário clica em “Release Notes”; 2 - Usuário clica em “Email”; 3 - Sistema lista todas as tarefas relacionadas a versão; 4 – Usuário informa o e-mail do destinatário; 4 – Usuário clica em enviar.

Pós-Condição As informações sobre a tarefas relacionadas a versão serão enviadas para os destinatários informados.

Quadro 13 – Caso de uso Enviar e-mail de release notes

66

ANEXO A – Formulário de avaliação do trabalho desenvolvido

Conforme descrito na seção 3.5 foi elaborado um formulário para avaliar a

opinião dos envolvidos no projeto. A Figura 35 exibe o formulário distribuído.

Figura 35 - Formulário de avaliação do trabalho desenvolvido

APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM...

Documents

Transcript of APLICATIVO PARA ATUALIZAÇÃO AUTOMATICA DE UM...