c4d4b09f-5d24-44a8-98ec-42d9e1fe70ba

Prévia do material em texto

TESTES DE 
SOFTWARE E 
GERÊNCIA DE 
CONFIGURAÇÃO
Aline Maciel Zenker 
Controle de mudanças
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Descrever o processo de gerenciamento de mudanças e a sua 
terminologia.
  Explicar o gerenciamento de versões.
  Listar modelos de gerenciamento de versões: centralizados e 
distribuídos.
Introdução
No desenvolvimento de um software, o gerenciamento de configuração 
é imprescindível. Esse gerenciamento é um conjunto de práticas e 
atividades que permitem que os gestores, desenvolvedores, analistas e 
testadores controlem o desenvolvimento de um projeto, a fim de evitar 
falhas na entrega. O gerenciamento permite identificar as mudanças 
necessárias para o bom funcionamento do sistema, mantendo a inte-
gridade e a qualidade do projeto e, com isso, garantindo a satisfação 
do cliente.
Neste capítulo, você vai ver como ocorre o processo de gerenciamento 
de mudanças de softwares. Você também vai conhecer a terminologia 
utilizada no gerenciamento. Além disso, você vai ver os modelos de 
controle de versões existentes para monitorar as mudanças.
Processo de gerenciamento de mudanças
Mudanças nunca são fáceis. Porém, como você sabe, muitas vezes elas são 
necessárias. Isso ocorre também na área de Tecnologia da Informação (TI): se 
há um problema em um software, é necessário fazer adaptações e corrigir as 
falhas. Entretanto, na maioria das ocorrências, as mudanças não são analisadas 
e não há registros de como são feitas. Isso acaba gerando problemas ainda 
maiores do que aqueles que já existiam.
Para que esses problemas não ocorram, é necessário controlar a mudança, 
planejando-a e executando-a de forma organizada. Assim, deve-se considerar:
  Por que mudar?
  O que e quando mudar?
  Quem fará a mudança?
  Será possível reproduzir a mudança?
As respostas a essas perguntas podem ser replicadas com o processo de 
gerenciamento de mudanças. O gerenciamento de mudanças possui etapas e 
ferramentas automatizadas para controlar as alterações organizadamente. Sua 
finalidade é verificar se as mudanças são necessárias e garantir que sejam 
feitas como planejado. Além disso, é preciso justificar cada uma das mudanças 
realizadas, marcando itens de configurações, testando cada procedimento 
de modificação e assegurando a existência de um plano de recuperação 
do sistema. O plano de recuperação é um backup de uma versão anterior à 
mudança, disponível para uso caso seja necessário.
As práticas e atividades de gerenciamento de software são divididas em 
três grupos:
  controle de mudanças — controle e acompanhamento de mudanças;
  controle de versões — registro da evolução do projeto;
  integração contínua — estabelecimento da integridade do sistema.
A alteração de qualquer item dentro de um sistema precisa ser controlada. É 
necessário saber qual foi a mudança, quem a fez, em que dia e em qual horário. 
As alterações podem ser feitas por meio de ferramentas de controle de versões. 
Para compreender melhor os procedimentos relacionados às mudanças em 
softwares, observe a Figura 1, a seguir.
Controle de mudanças2
Figura 1. Processo de controle de mudanças.
Fonte: Adaptada de Pressman (2011).
O processo de controle de mudanças se inicia com o reconhecimento da 
necessidade da mudança. Tal processo passa por fases, tais como: pedido da 
mudança feito pelo usuário ou testador, avaliação do desenvolvedor, relatório e 
decisão da autoridade controladora (rejeitar a mudança ou aceitá-la). Se ocorre 
3Controle de mudanças
rejeição, o usuário é avisado e encerra o processo. Caso seja aceita, a mudança 
passará por etapas como: uma fila para ser processada, pessoas nomeadas para 
fazer a mudança, registro de saída, mudança, registro de entrada e testes. Por 
fim, a mudança é incluída na nova versão do software.
Terminologia
O gerenciamento de projetos utiliza alguns termos ao trabalhar com as etapas 
do processo de mudança. Veja a seguir.
  Baseline: também chamada de “linha de base”, é um guia do projeto, 
com todas as alterações aprovadas. É um modelo do que já foi planejado 
e do que está estabelecido; uma amostra visual de que o projeto está 
pronto para ser iniciado ou continuado. A cada mudança aprovada para 
ser executada, atualizam-se as linhas de base do projeto para novos 
acompanhamentos, monitoramentos e controles.
  Artefato: é o resultado de um conjunto de atividades provenientes das 
tarefas envolvidas no processo de desenvolvimento de um sistema de 
software. Por exemplo: um documento do software, um requisito e um 
diagrama.
  Commit: é o ato de criar o artefato no repositório pela primeira vez 
ou de criar uma nova versão do artefato quando ele passar por uma 
modificação.
  Check-out (clone): é o ato de criar uma cópia de trabalho local do 
repositório.
  Workspace: é o lugar onde o desenvolvedor mantém todos os artefatos 
de que ele precisa para realizar uma tarefa. Os workspaces são como 
espaços de trabalho isolados uns dos outros.
  Codeline: é um conjunto de arquivos, fontes e artefatos que abrangem 
algum componente de software, armazenando a evolução das mudanças 
ocorridas ao longo do tempo. Os artefatos podem ser planos de projetos, 
avaliações de risco e documentos gerados durante o processo de mudança.
  Branch: é uma versão de uma codeline que se inicia na versão central 
(trunk) e evolui independentemente. Por exemplo: no controle de ver-
sões GIT, um branch é simplesmente um leve ponteiro móvel para um 
desses commits.
  Merge: é a integração entre mudanças realizadas de uma codeline para 
outra. Ou seja, é a integração entre versões diferentes, com o objetivo 
de gerar uma versão com todas as alterações realizadas.
Controle de mudanças4
Princípios gerais do gerenciamento de mudanças
Os princípios gerais para o gerenciamento de mudanças norteiam a estrutura 
e a identifi cação dos principais estágios para a efetiva mudança no software. 
Veja os princípios a seguir.
  Utilizar controle de versões: o controle de versões possibilita a organi-
zação e a comunicação do trabalho.
  Fazer builds periódicos e integrar frequentemente: os builds e a inte-
gração permitem que os desenvolvedores verifiquem o funcionamento 
do software quando partes dele são executadas em conjunto. O período 
de build é determinado pela empresa. A integração do software demora 
certo tempo, adicionando um overhead ao processo de desenvolvimento.
  Permitir trabalho autônomo: cada membro da equipe controla que versão 
e que componente são trabalhados.
  Utilizar ferramentas: o controle de versões manual é aplicável a projetos 
pequenos, com poucas demandas de alterações. Porém, em projetos 
maiores, o uso de ferramentas para controlar mudanças, versões e 
outros aspectos é fundamental para evitar erros.
Gerenciamento de versões
Um sistema de controle de versões gerencia as diferentes versões de um 
projeto de software. Ele organiza o projeto para possibilitar um acompa-
nhamento do histórico de desenvolvimento. O gerenciamento de versões 
preocupa-se com a identidade e a manutenção da rastreabilidade das versões 
de um sistema.
O controle de versões é uma atividade. Ele pode ser automatizado por um 
sistema que registra todas as alterações realizadas, possibilitando ao usuário 
resgatar versões específicas. Já uma versão é uma criação, uma estruturação 
do sistema, diferenciando itens específicos do projeto. Por meio das versões, 
é possível diferir alguma função, algum item ou os dados do sistema.
Existem releases de sistema, versões que são distribuídas aos clientes. Todo 
release possui novas funções e aceita uma nova plataforma — definida como o 
sistema em que o release liberado irá executar, o hardware de que necessitará, 
etc. No entanto, nem todas as versões são de release. Existem muitas versões 
não distribuídas que são criadas para organizar e testar o sistema. Ainda pode 
haver versões internas utilizadas no desenvolvimento do sistema.
5Controlede mudanças
As versões podem ser controladas por meio de ferramentas que gerenciam 
o acesso aos componentes do sistema — itens que sofreram alterações. Elas 
podem ser identificadas por meio de um número explícito e único. Além disso, 
não seguem obrigatoriamente um mesmo esquema. Um projeto pode passar 
pela versão tag 1 (versão 1.0) e após pela versão tag 2 (versão 2.0). Também 
pode haver subversões com pequenas correções, como 1.1, 1.1.1, 2.1 e assim 
sucessivamente. Para entender melhor, observe a Figura 2, a seguir.
Figura 2. Identificação de versões.
Vantagens de utilizar o controle de versões
O controle de versões possui diversas vantagens. Entre elas, considere as 
listadas a seguir.
  Armazenamento de histórico: o sistema de versionamento guarda a 
evolução do projeto e todas as alterações de cada arquivo, registrando 
quem fez o quê, quando e onde. Também permite recuperar uma revisão 
específica do arquivo sempre que desejado.
Controle de mudanças6
  Desenvolvimento do projeto em equipe: por meio do controle de 
versões, é possível o desenvolvimento do projeto com uma equipe de 
desenvolvedores, todos trabalhando paralelamente no mesmo código, 
sem sobrescrevê-lo.
  Manutenção de versões do projeto: pode-se manter variações no 
projeto e manter linhas diferentes de evolução do mesmo projeto, ar-
mazenando versões de evoluções. Por exemplo: versão 1.0, versão 2.0.
As ferramentas de controle de versões gerenciam a mudança aplicada ao 
software, indicando:
  o que foi modificado no código;
  qual foi o usuário que fez a modificação;
  em que dia e em que hora ocorreu a mudança;
  qual foi a versão alterada.
Além disso, elas apresentam um histórico em ordem decrescente. Na 
Figura 3, a seguir, você pode ver um exemplo de identificação de versões.
Figura 3. Identificação de versões.
Fonte: NetBeans (2019, documento on-line).
7Controle de mudanças
Modelos de gerenciamento de versões
O funcionamento do controle de versões pode variar de acordo com a fer-
ramenta adotada. Tal ferramenta pode utilizar um modelo de controle cen-
tralizado ou distribuído. Todo controle de versões se divide em duas partes: 
repositório e área de trabalho. Para armazenar o histórico de evoluções do 
projeto e o registro de alterações e mudanças, é utilizado o repositório. A 
área de trabalho é utilizada para armazenar cópias dos arquivos do projeto, 
identifi cadas normalmente pelo número da versão.
Quando há um histórico de evoluções, é preciso fazer um update na versão 
da área de trabalho e um commit de retorno ao repositório. A origem repositório 
envia as modificações contidas para o destino área de trabalho, enquanto a 
área de trabalho “comita” um pacote com uma ou mais alterações feitas no 
arquivo. Cada commit enviado pela área de trabalho gera uma nova revisão 
no repositório, guardando as modificações feitas e registrando quando ocor-
reram e quem as fez. Essas revisões são mantidas e podem ser recuperadas 
e analisadas sempre que desejado. São, justamente, o histórico do projeto.
Considere este exemplo: dois desenvolvedores trabalham no mesmo projeto. 
Um dos desenvolvedores utiliza uma função chamada check-out ou update 
para acrescentar uma funcionalidade ao sistema e iniciar as alterações. O 
outro desenvolvedor faz alterações e as envia ao servidor utilizando a função 
chamada check-in ou commit.
O sistema de controle de versões alerta que o arquivo do primeiro desenvol-
vedor está desatualizado. Além disso, possibilita a ele enviar as informações 
adicionadas e mesclar as diferentes versões. O sistema ainda indica o local 
onde foram feitas atualizações, os trechos de código incluídos ou removidos 
e os casos de conflito, dando a opção de subscrever ou mesclar manualmente.
Várias interfaces de desenvolvimento (IDES) — como NetBeans, Eclipse, Visual Studio, 
entre outras — já incluem plugins para a integração de um sistema de controle de 
versões. Um plugin é um programa, ferramenta ou extensão que se encaixa em outro 
programa principal para adicionar mais funções e recursos a ele.
O controle de versões com modelo centralizado possui um único reposi-
tório central e várias cópias de trabalho, uma para cada desenvolvedor. Toda 
Controle de mudanças8
mudança é passada primeiro para o repositório e depois distribuída entre todas 
as áreas de trabalho. Esse modelo tem como centro das atividades o repositório. 
Esse tipo de controle é recomendado para projetos com poucos desenvolvedores 
envolvidos e que trabalham no mesmo local, na mesma empresa, utilizando 
um único servidor, ou seja, um único repositório.
Os desenvolvedores que escrevem seus códigos utilizando um modelo de 
sistema de controle centralizado, ao fazerem check-out, geram o carregamento 
de uma cópia do projeto em sua área de trabalho. Após, é executado o comando 
update, para trazer as novas versões de atualizações, e o comando commit, a 
fim de enviar as modificações realizadas ao repositório central.
Um exemplo de ferramenta de controle de versões com modelo centralizado 
é o Subversion. Conhecido como SVN, ele é uma ferramenta para o controle 
de versões de um software. O Subversion permite, além do desenvolvimento 
conjunto com o uso de um repositório único, o envio de conteúdo, o armaze-
namento de logs e a geração de estatísticas diversas.
A Figura 4 apresenta o controle de versões centralizado: um único re-
positório e várias cópias de trabalho que se comunicam apenas por meio do 
repositório central.
Figura 4. Controle de versões centralizado.
9Controle de mudanças
O controle de versões com modelo distribuído possibilita o uso de mais 
de um repositório com sua área de trabalho independente das demais áreas 
de trabalho envolvidas no projeto. Esse controle é indicado para os projetos 
nos quais há uma equipe com vários desenvolvedores, que podem estar em 
locais diferentes, como em filiais distantes umas das outras.
O modelo distribuído possui vários repositórios, e as operações de check-
-in e check-out são feitas na própria máquina do desenvolvedor. A comu-
nicação continua sendo por meio de commit e update. Porém, ao contrário 
do que ocorre no modelo centralizado, as áreas de trabalho do modelo 
distribuído podem se comunicar entre si. Quando isso ocorre, recomenda-
-se usar um servidor como centro do envio dos arquivos, centralizando as 
alterações gerais, evitando a perda do controle do projeto e garantindo o 
versionamento correto.
Para a comunicação entre o servidor principal e as áreas de trabalho, é 
preciso usar duas novas operações: pull (puxar) e push (empurrar). O pull 
atualiza o repositório local, que centraliza todas as alterações feitas, em outro 
repositório integrado a uma área de trabalho. Ou seja, ele utiliza a versão de 
outra área de trabalho e possibilita a mescla dela com a sua versão. Por sua 
vez, o push envia as alterações do repositório local para outro repositório de 
destino, que integra outra área de trabalho, ou seja, envia a sua versão a outra 
área de trabalho.
Um exemplo de ferramenta de controle de versões distribuído é o GIT. 
Essa ferramenta faz o controle de versões de um software utilizando um 
repositório para cada área de trabalho, além de um repositório maior para 
controlar as demais áreas. A ferramenta permite projetos colaborativos com 
desenvolvedores de todo o mundo.
A Figura 5 apresenta o controle de versões distribuído com vários reposi-
tórios, um para cada cópia do trabalho. As cópias se comunicam e, para não 
haver perda de controle, há um repositório central via servidor remoto para 
hospedar o projeto. Nele, são feitas as atualizações gerais e as mesclagens 
das alterações.
Como você viu, o gerenciamento de mudanças requer um controle de 
versões. Além disso, ele resolve diversos problemas relacionados ao desen-
volvimento de softwares. Portanto, é uma prática de engenharia de software 
comprovadamente eficaz, auxiliando na organização do projeto e no com-
partilhamento do código.
Controle de mudanças10
Figura 5. Controlede versões distribuído.
NETBEANS. NetBeans IDE Features. [2019]. Disponível em: https://netbeans.org/features/
ide/versioning.html. Acesso em: 28 maio 2019.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto 
Alegre: AMGH, 2011.
Leituras recomendadas
DEVMEDIA. ITIL: como implantar o gerenciamento de mudanças. 2014. Disponível em: 
https://www.devmedia.com.br/itil-como-implantar-o-gerenciamento-de-mudan-
cas/31162. Acesso em: 28 maio 2019.
LAUDON, K.; LAUDON, J. Sistema de informação gerenciais. 9. ed. São Paulo: Pearson, 2011.
MAGALHÃES, I. L.; PINHEIRO, W. B. Gerenciamento de serviços de TI na prática: uma 
abordagem com base na ITIL. São Paulo: Novatec, 2007.
PORTAL DA GOVERNANÇA DE TIC DO TRT 11ª REGIÃO. Gerenciamento de mudanças. 2015. 
Disponível em: https://governanca.trt11.jus.br/index.php/publicacoes2/processos-itil/
gerenciamento-de-mudan%C3%A7as.html. Acesso em: 28 maio 2019.
11Controle de mudanças