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

■ 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 códigos 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. - FONTE: UFMG.