Revisão de Software

Uma forma efetiva para melhorar a Qualidade de Software. Devendo ser aplicadas em vários pontos durante o desenvolvimento do software. Pode ser vista como uma maneira de usar a diversidade de um grupo de pessoas para:

• Apontar melhorias necessárias ao produto;
• Confirmar as partes de um produto em que uma melhoria não é desejada ou não é necessária;
• Realizar um trabalho técnico com uma qualidade mais uniforme de forma a tornar este trabalho técnico mais administrável.

Tipos de Revisões

Podemos identificar diversos tipos de revisão (Rodrigues, 2001; Paula Filho, 2003):

• Discussão de um problema técnico na hora do café. Informal, mas às vezes efetivo;

• Apresentação do projeto de software para uma audiência de clientes, administradores e pessoal técnico.

•Revisão de Apresentação (walktrought). O autor apresenta o material em ordem lógica, sem limite de tempo a um grupo que verifica o material na medida em que ele vai sendo apresentado.

.• Revisões Técnicas (thecnical review). Inclui avaliações técnicas de artefatos específicos, realizadas em pequenos grupos, para verificar se eles estão conformes com padrões e especificações e se, eventuais modificações nos artefatos foram efetuados de maneira correta.

•Inspeção ou Revisão Técnica Formal (Formal technical review). Técnica mais formal que a revisão técnica, com objetivo principal a identificação e a remoção de defeitos. Origatório: geração de uma lista de defeitos com classificação e a requisição de ações de correção.

Inspeções

Atividade de Garantia de Qualidade de Software e tem por objetivo:

1) Descobrir erros de função, lógica ou implementação em qualquer representação do software.

2) Verificar se o software que se encontra em revisão atende a seus requisitos.

3) Garantir que o software tenha sido representado de acordo com padrões pré-definidos.

4) Obter um software que seja desenvolvido uniformemente.

5) Tornar os projetos mais administráveis.

6) espaço de treinamento possibilitando que os engenheiros juniores observem diferentes abordagens a análise, projeto e implementação de software.

7) promover backup e continuidade. Várias pessoas se familiarizam com partes do software que de outro modo poderiam não conhecer.

Uma Revisão Técnica Formal é conduzida em uma reunião e será bem sucedida se for planejada, controlada e cuidada. Independentemente do formato de Revisão Técnica, toda Reunião de Revisão deve estar de acordo com:

1) Envolver de 3 a 5 pessoas na revisão.

2) Deve haver uma preparação para a reunião (essa preparação não deve exigir mais de 2 horas de trabalho de cada pessoa).

3) A Reunião de Revisão deve durar menos de 2 horas. A Inspeção focaliza uma parte específica (pequena) do software – aquela com maior probabilidade de descoberta de erros.

Sucesso na Inspeção

Muitos defeitos diferentes podem ser descobertos numa simples inspeção. Sendo que no teste, um defeito, pode mascarar outro e, portanto várias execuções são necessárias. O domínio do reuso e os conhecimentos de programação permitem aos revisores já terem visto os tipos de erros que normalmente aparecem.

Inspeções de programas

Podemos usar um enfoque formalizado de revisão de documentos ou de programas. O propósito explícito deve ser o da DETEÇÃO (não a correção). Defeitos podem ser erros lógicos, isto é, anomalias no código que podem indicar uma condição errônea (ex. variável não instanciada) ou a não aderência a padrões.

Checklist de erros comuns devem ser usadas para dirigir a inspeção e deve ser adequado à linguagem de programação utilizada. Quanto mais ‘fraca’ a checagem de tipo, maior o checklist. Exemplos: Inicialização, Nomeação de constantes, termino de loop, li­mites de arranjos, etc.

Processo de Inspeção

Plano

Visão Geral

Preparação Individual

Reunião de Inspeção

Revisão

Acompanhamento

Microsoft Word – NotasDeAula5Novo.doc

Diretrizes da revisão

As diretrizes devem ser estabelecidas antecipadamente, distribuídas a todos os revisores, ter a concordância de todos e então ser encaminhada.

Conjunto mínimo de diretrizes para as revisões técnicas formais:

1) Revise o produto, não o produtor.

2) Fixe e mantenha uma agenda.

3) Limite o debate e a refutação (razão que vai contra uma premissa, lema ou conclusão).

4) Enuncie as áreas problemáticas, mas não tente resolver cada problema anotado.

5) Faça anotações por escrito.

6) Limite o número de participantes e insista numa preparação antecipada.

7) Desenvolva uma lista de conferência (checklist) para cada produto que provavelmente será revisto.

8) Atribua recursos e uma programação de tempo para as Revisões Técnicas                  Formais.

9) Realize um treinamento significativo para todos os revisores.

10) Reveja suas antigas revisões.

Sistema de Controle de Versão

Software com a finalidade de controlar diferentes versões de um documento, isto é o

histórico e o desenvolvimento de códigos fontes ou qualquer outro tipo de documentação.

É sistema que está se tornando cada vez mais presente em em­presas e instituições de tecnologia e desenvolvimento de software. Também muito utilizado no desenvolvimento de software livre, onde os fontes mais atuais podem ser obtidos diretamente destes sistemas. 

Alguns Sw proprietários:

Visual SourceSafe (VSS) produto da Microsoft para controle de ver­são, integrado a muitas IDEs da Microsoft.

Rational ClearCase produto da IBM para controle de versão. Tem um plugin para o Eclipse.

Sw livres:

Concurrent Version System (CVS) software livre clássico e bem tes­tado.

Subversion (SVN) está substituindo o CVS aos poucos; é uma alterna­tiva também livre e mais eficiente. Muitas fundações não­ governamentais sem fins lucrativos ligadas ao desenvolvimento de software como a Apache Foundation já adotaram o Subversion como padrão.

MediaWiki software livre que combina Wiki com um sistema inte­grado de controle de versões. Sites com os projetos da Wikimedia, tal como a Wikipédia mantém o sistema Media Wiki para o controle das versões dos documentos. Este sistema permite o trabalho simultâneo de milhares de voluntários.

Funcionamento Básico

Cada sistema tem sua particularidade, embora a maioria deles compartilhe os conceitos básicos descritos a seguir:

Repositório – Tais informações como todo o histórico ficam guardadas num repositório (repository em inglês), num servidor qualquer. Geralmente o acesso é feito por um cliente pela rede (via socket) e pode ser feito localmente quando o cliente está na mesma máquina do servidor.

O repositório armazena a informação um conjunto de documentos de modo persistente num sistema de arquivos ou num banco de dados qualquer. É possível que o armazenamento seja feito em outros dispositivos capazes de “eternizar” e resgatar facilmente a informação.

Cada servidor pode ter vários sistemas de controle de versão e cada sistema pode ter diversos repositórios, limitando se na capacidade de gerenciamento do software e também no limite físico do hardware. Geralmente um repositório possui um endereço lógico que permite a conexão do cliente. Esse endereço pode ser um conjunto IP/porta, uma URL, um caminho do sistema de arquivos etc.

Cada desenvolvedor possui em sua máquina uma cópia local (working copy em inglês) somente da última versão de cada documento. Essa cópia local geralmente é feita num sistema de arquivos simples. Sendo que a cada alteração relevante do desenvolvedor é necessário “atualizar” as informações do servidor submetendo (commit em inglês) as alterações. O servidor então guarda a nova alteração junto com todo o histórico mais antigo. Se o desenvolvedor quer atualizar sua cópia local é necessário atualizar as informações locais, e para isso é necessário fazer baixar novidades do servidor (update em inglês).

Envio e Resgate de versões

A principal função do sistema de controle de versão:

Armazenar todo o histórico de desenvolvimento do documento, desde o primeiro envio até sua última versão. Permitindo que seja possível resgatar uma determinada versão de qualquer data mais antiga, evitando desperdício de tempo no desenvolvimento para desfazer alterações quando se toma algum rumo equivocado.

Tais envios das alterações, quando se deseja minimizar conflitos de versões, facilitarem no desfazer de alterações e também no controle do histórico, recomenda se que uma alteração seja enviada cada vez que o software estiver minimamente estável, i. e., cada vez que uma parte/seção/função nova (ou mudança) esteja funcionando corretamente. Assim sendo não é recomendável o envio quando o documento como um todo possa causar alguma dificuldade no desenvolvimento de outro colaborador, como um código não compilando ou com algum bug que comprometa todo o funcionamento, por exemplo.

Cada “envio” é na maioria dos sistemas chamado de “commit”, ou seja, submeter e efetivar as alterações no repositório, mas em alguns é conhecido como chekin, assim como o processo de desfazer chekout e a atualização das versões como um todo Get last verson.

Cada envio produz uma nova versão no repositório e é armazenado como “uma fotografia” do momento. Muitas vezes é possível acrescentar comentários no envio das alterações, o que facilita também numa possível análise do histórico.

Em sistemas no estilo do CVS (Concurrent Version System (Sistema de Versões Concorrentes), o controle de versão é feito por cada documento individualmente. Assim, para pegar uma “fotografia” de determinado momento, elas não ficam “alinhadas” em função da versão.

Microsoft Word – NotasDeAula5Novo.doc

Num sistema mais moderno, como o SVN, o controle de versão é feito por cada envio ao servidor. Ou seja, há uma versão global para todos os documentos.

Trabalho em Equipe

O sistema também é bastante útil quando se trabalha com vários desenvolvedores de modo simultâneo, resolvendo de modo muito satisfatório conflitos de versões. As maiorias dos sistemas possuem diversos recursos como mesclagem e divisão de ramo do desenvolvimento para auxiliar nessas tarefas.

Passos no controle de versões

1°) passo: atualizando

2°) passo: desenvolvendo

3°) passo: submetendo

4°) passo: necessita atualização

5°) 5°passo: baixando atualização e mesclando

6°) e último passo: submetendo a versão final

Sem sistemas de controle de versão

Quando se compartilha o mesmo projeto numa rede diretamente num sistema de arquivos simples, sem um sistema de controle de versão, a chance de haver conflito aumenta muito. Alguns arquivos ficam bloqueados para escrita enquanto está sendo usado, o fluxo de informação pela rede é alto porque a cada vez é necessário reenviar o documento todo e a chance de corromper arquivos também aumenta; isto não acontece com um sistema de controle de versão, pois cada desenvolvedor possui uma cópia local do projeto, trabalhando localmente, baixando as atualizações e enviando as alterações.

Mesclagem e comparação de versões

Quando se utiliza um sistema de controle de versões cada desenvolvedor pode trabalhar tranquilamente em sua cópia local e o sistema fica encarregado de mesclar o que for necessário de acordo com as mudanças simultâneas.

A mesclagem (ou merge em inglês) consiste na aglutinação automática de versões através da comparação entre elas. Esta pode ser feita também manualmente quando o conflito é direto, ou seja, quando há alterações simultâneas no mesmo ponto do documento. Sendo possível também comparar quaisquer versões entre si, enviadas a qualquer tempo. Saber exatamente o que foi acrescentado, modificado ou excluído em qualquer ponto dos documentos. Permitindo a análise minuciosa das alterações desde a criação do projeto até seu estado atual.

Obs.: Alguns sistemas não possuem o sistema de “mesclagem”, portanto quando há conflito é necessário resolvêlo manualmente como descreve a subseção seguinte.

Resolução de Conflitos

Quando dois ou mais desenvolvedores modificam uma mesma região num documento aí é necessário resolver o conflito “manualmente”. O software de Cliente fará uma cópia de segurança da sua alteração para que não haja chance de você perdê-la e depois mostrará o local de conflito. O software geralmente mostra os conflitos na tela e o desenvolvedor escolhe qual versão manter. Em regra quando acontece esse tipo de coisa é porque houve falha na organização de divisão do trabalho e provavelmente uma alteração semelhante foi produzida na mesma região.

Ramificações e Marcações

Em sistema moderno de controle de versões é possível quebrar a linha do desenvolvimento em mais de um caminho, sendo chamado de ramificação (ramo), braços ou em inglês branches. Isso é muito útil quando se conquista uma versão estável dos documentos (ou software) ou quando se quer fazer uma tentativa “não convencional” fora do ramo principal.

Otimização de Espaço e Velocidade

Um sistema assim mantém armazenado apenas a primeira versão e as diferenças entre elas, até formar a última, com o principal objetivo de economizar espaço. É claro que também existem outras otimizações que guardam a versão final ou versões recentes para que algumas operações possam ser feitas de modo mais rápido (utilizando uma espécie de cache). Assim, dependendo do sistema e da configuração, é possível compactar algumas partes do repositório muito antigas que não estão sendo utilizadas de modo a salvar espaço.

Tais sistemas são otimizados para trabalhar com arquivos texto e muitas vezes não se dão muito bem com arquivos binários. Os sistemas mais modernos trabalham melhor com esse segundo tipo de arquivo, mas ainda assim de forma pouco satisfatória: tanto pelo alto consumo de espaço quanto pela dificuldade de se fazer comparação entre uma versão e outra.

Principais Vantagens

De se manter um sistema de controle de versão como bases num desenvolvimento de software ou no desenvolvimento de um documento de texto qualquer são:

• Controle do histórico: fácil fazer, fácil desfazer. Fácil também analisar o histórico do desenvolvimento de documentos, como também fácil resgatarem versões antigas. É possível analisar cada mínima alteração, desde a primeira versão até a última.

•Trabalho em equipe: um sistema de controle de versão permite que centenas de pessoas trabalhem sobre os mesmos documentos ao mesmo tempo e minimiza muito os possíveis conflitos de edições. Quanto mais documentos e menos pessoas, menos chances de conflitos. Quanto mais envios ao sistema, as chances de conflitos também diminuem.

•Controle de versões estáveis: é possível marcar onde é que o documento estava com uma versão estável, podendo ser facilmente resgatado.

Vocabulário

Veja o vocabulário típico da maioria dos sistemas de controle de versão:

Repositório / Repository local no Sistema onde fica armazenado todas as versões, desde a primeira até a última. Cada Sistema pode possuir de 0 a N repositórios.

Cópia local / Working copy É geralmente uma pasta no sistema operacional do desenvolvedor (do lado Cliente) que mantém a cópia da última versão do projeto. É através da cópia local que o Cliente compara com a última versão do Servidor e sabe exatamente o que foi modificado.

Baixar / CheckOut Quando não existe cópia local e é necessário baixar todo o projeto do Servidor.

Submeter / Commit Enviar as alterações da cópia local ao Servidor através do Cliente.

Modificação, diferença ou mudança (Change ou diff) Representa a diferença entre uma versão e outra de um mesmo documento.

Atualização / Update Atualiza na cópia local as novidades do Servidor, provavelmente as mudanças enviadas por outro desenvolvedor.

Versão desatualizada / Uptodate Acontece quando alguém submete um documento que você está trabalhando antes de você. Nesse caso é necessário fazer uma atualização para que o Cliente tente mesclar as alterações que, na prática e na grande maioria das vezes são bem sucedidas.

Mesclagem / Merge ou Integration Permite que mais de um utilizador modifique um mesmo documento ao mesmo tempo, comparando as diferenças e mesclando mantendo as duas alterações (se possível). A mesclagem geralmente é feita localmente (lado Cliente) na atualização de um documento quando há uma versão no Servidor mais recente que a sua.

Revisão ou Versão / Revision ou Version Representa um determinado “momento” (uma “fotografia”) de um repositório ou documento.

Conflito / Conflict Acontece geralmente quando não há planejamento nas alterações dos documentos e mais de um desenvolvedor modifica simultaneamente o mesmo local de um mesmo documento. Quando um desenvolvedor envia e atualiza poucas vezes sua cópia local, as chances dos conflitos ocorrerem a dificuldade de resolvê-los aumentam significativamente.

Resolução de conflito / Conflict resolve ou Solve Quando os desenvolvedores precisam analisar o que entrou em conflito e escolher qual alteração fará parte da versão final.

Ramificação ou braço / Branche Quando a linha de desenvolvimento precisa ser dividida em duas ou mais.

Marcação / Tag É dar um nome a um determinado “momento” do repositório, ou seja, é como uma “fotografia” de determinada data.

Travar / Lock Em alguns sistemas é possível bloquear um arquivo e ninguém pode alterá-lo nesse momento. Isso é muito pouco usado, mas é útil com arquivos binários e/ou difíceis de serem mesclados.

Abaixo os endereços na WEB dos principais sistemas de controle de versão:

Concurrent Version System (CVS): http://savannah.nongnu.org/projects/cvs/

Subversion (SVN): http://subversion.tigris.org/

VisualSourceSafe(VSS):http://msdn.microsoft.com/vstudio/products/vssafe/default.aspx

Rational ClearCase:http://www306.ibm.com/software/awdtools/clearcase/

MediaWiki: http://www.mediawiki.org/wiki/MediaWiki

GNU CSSC: http://cssc.sourceforge.net/

Revision Control System (RCS):http://www.gnu.org/software/rcs/rcs.html