Controle de configuração ou CM, do inglês Change Management, é uma atividade de vital importância ao longo do ciclo de desenvolvimento do software que, apesar de não ser desenvolvimento nem verificação, vale a pena comentar neste capítulo. O desenvolvimento de um software, na maioria dos projetos, não é um processo linear, com começo, meio e fim, pois existem sempre mudanças onde se torna necessário retroceder no processo para refazer alguma parte que já havia sido concluída.
É neste cenário que o controle de configuração mostra o seu valor. A área de CM pode ser vista como um processo que, assim como a verificação, acompanha todo o desenvolvimento de um software. Ela se sub-divide em duas: controle de versão e controle de mudança. O controle de versão é o sistema pelo qual será possível guardar e recuperar as diversas versões dos arquivos do projeto, e não falo somente de código-fonte, mas também requisitos, documentação, testes, e tudo mais que sofra mudanças ao longo do projeto. Nas diversas ferramentas de controle de versão, como o Subversion e o Git, são dadas identificações a cada versão que o usuário deseja guardar, e assim é possível comparar versões de arquivos, recuperar arquivos antigos e mesclar modificações feitas em paralelo por usuários diferentes. O controle de versão por si só já é muito útil para a atividade de verificação, mas ela normalmente é acompanhada pelo controle de mudanças.
O controle de mudanças é o sistema que registra as solicitações de alterações em um software e implementa um fluxo de trabalho a ser realizado por diversos responsáveis até que estas alterações sejam efetivadas. O fluxo geralmente passa por uma avaliação da solicitação, onde são avaliados todos os impactos em arquivos, seguida pela aprovação, implementação da mudança e verificação de sua correta efetivação. Durante a avaliação do impacto, ou análise de impacto, são listados todos os artefatos que terão que ser alterados, normalmente requisitos, código fonte e testes. Fala-se artefatos ao invés de arquivos pois alguns deles podem estar em uma base de dados e não necessariamente em formato de arquivos. Para esta análise podem ser utilizadas as matrizes de rastreabilidade, explicadas adiante. Quando a solicitação é encerrada, todo o fluxo foi executado e os artefatos estarão coerentes, como se aquela mudança tivesse sido parte da definição inicial do software. Guarda-se, então, a versão daqueles artefatos modificados. Ferramentas de controle de mudança mais conhecidas são o Jira, Trac e Bugzilla.
Muitas vezes, quando se abre uma solicitação de mudança, ou Problem Report, não se sabe o que precisa ser alterado, mas apenas o erro que está sendo observado. Este é o caso, por exemplo, quando um teste é executado e falha. A solicitação deve ser feita descrevendo-se a condição em que ocorre o problema e como ele se manifesta, uma vez que quem encontrou o problema pode não conhecer detalhes da implementação nem tampouco saber julgar a melhor opção de correção. Em seguida, o fluxo do controle de mudança passa por uma fase de investigação para que seja descoberta a causa do problema e seja proposta uma alternativa de solução. Outras vezes a solicitação de mudança é feita sem que haja um defeito, mas sim uma necessidade de alteração para evoluir o software. Em ambos os casos, o ciclo de CM pouco se altera, passando pelas mesmas fases e tendo o mesmo tipo de impacto nas demais atividades.
Já vimos uma forma em que o controle de mudança pode ser útil para a atividade de verificação: quando um teste falha e precisa ser reportado (ou de maneira mais geral, quando qualquer verificação falha). Entretanto, CM é utilizado em vários outros momentos e pode ser considerado como um apoio imprescindível às atividades de V&V. Quando se realiza uma revisão de código fonte, por exemplo, é necessário registrar qual a versão dos arquivos onde se realizará a atividade, utilizando qual versão do standard de código e contra qual versão de requisitos. Quando descrevermos a atividade de revisão ficará mais claro por que são necessários tantos arquivos diferentes em controle de versão.
Desta forma, a atividade é feita de maneira "controlada", pois se tem controle do que foi revisado. Quando uma mudança for necessária, através de uma solicitação no sistema de controle de mudança, serão analisados quais artefatos serão modificados e estes, então, necessitarão de uma nova revisão. O próprio standard poderia ser modificado, incluindo uma ou mais regras, e assim seria necessário saber quais foram os arquivos revisados utilizando-se a versão antiga, para que eles fossem revisados contra as novas regras.
Se não fossem registradas todas as versões necessárias ao início da revisão, e o mesmo vale para análises, inspeções e testes, seria impossível avaliar quais foram os impactos de uma mudança e então seria necessário ser conservador e realizar todas as atividades de verificação novamente. Percebemos então que o controle de configuração protege o trabalho de V&V, preservando o trabalho realizado e possibilitando um retrabalho pontual onde for necessário.
Comentários
Postar um comentário