É o processo ou atividade para leitura de um artefato de seu software visando assegurar que ele cumpre sua especificação e atende às necessidades de seus usuários e ocorre em diferentes momentos do software.
Tem como objetivo validar e verificar os artefatos de software.
Pode ser aplicada a qualquer artefato produzido ao longo do processo de desenvolvimento de software.
As revisões podem ser:
PARES (PEER-REVIEWS): aumenta a probabilidade de defeitos a
serem encontrados. Utilizam:
o ANÔNIMIDADE: relacionamentos pessoais não afetam a
revisão.
o INDEPENDÊNCIA DOS REVISORES EM RELAÇÃO AO ARTEFATO
A SER REVISADO: permite uma avaliação objetiva sem conflitos de interesse.
TIPOS DE REVISÃO DE SOFTWARE
I N S P E Ç Ã O D E S O F T W A R E
Os benefícios e custos são:
Inspeções vêm sendo utilizadas há mais de duas décadas;
Existe evidência experimental de sua usabilidade e
adequabilidade;
Provêem um bom meio para o gerente do projeto monitorar a
Podem amenizar atividades de manutenção, evitando que erros
se propaguem pelo ciclo de vida;
Apresentam baixo custo devido ao fato do revisor não precisar
investir muito tempo ou mesmo não demandar ferramentas sofisticadas para realizá-las. Entretanto uma alta taxa de atividades de inspeção ao longo do pr0ocesso pode acrescer de 5% a 10% o custo final.
Figura 26 – Comparativo de Com e Sem Inspeção
PROCESSO DE INSPEÇÃO DE SOFTWARE
Figura 27 – Processo de Inspeção
PAPEIS: atuam ao longo das atividades da inspeção para que no final do processo tenha um documento com os requisitos de software bem elaborados.
- moderador: - inspetor;
- autor do documento. ATIVIDADES:
- planejamento: efetuado pelo moderador que identificada baseada nas características do artefato, quem seriam os mais interessados em participar da inspeção e distribuía para as pessoas selecionadas nesta atividade;
- preparação individual: recebiam o material e se preparavam para a reunião para identificar defeitos.
- reunião de inspeção: depois marcava a reunião e durante ela era feito a leitura critica do documento de requisitos para encontrar os defeitos. No final tinha-se a lista de defeitos que era entregue ao autor
- retrabalho: fazer os reajustes de acordo com o que foi elaborado. - continuação: verifica se precisa ou não passar por outra inspeção.
PROCESSO TRADICIONAL DE INSPEÇÃO
PLANEJAMENTO
Responsável: moderador Tarefas:
- Definir contexto da inspeção: descrição da inspeção, como a preparação individual deverá ocorrer, documento a ser inspecionado, autor do documento, entre outros.
- Selecionar inspetores: recomenda-se utilizar entre 3 e 5 inspetores em uma inspeção.
- Distribuir material.
PREPARAÇÃO INDIVIDUAL
- Responsável: Inspetor
- Tarefas: estudar os artefatos e fazer anotações sobre os artefatos.
REUNIÃO DE INSPEÇÃO
- Envolvidos: moderador, inspetores e autor - Tarefas:
- Leitura do documento com a equipe discutindo possíveis defeitos (duração recomendada 2 horas);
- Produzir uma lista de defeitos;
- Em casos de discordância a decisão sobre registrar um defeito ou não (falso positivo) é do moderador.
RETRABALHO
- Responsável: Autor
- Tarefa: corrigir os defeitos encontrados.
CONTINUAÇÃO
- Responsável: Moderador - Tarefa:
- Analisar correções do autor e inspeção como um todo; - Re-avaliar qualidade do artefato inspecionado;
- Decidir sobre a necessidade de uma nova inspeção.
W A L K T H R O U G H S
Alternativa com um processo menos rigoroso do que o de inspeções de software. Papéis sugeridos: líder, autor, escrivão e revisores.
Procedimento: os participantes são guiados através dos artefatos pelo líder (que eventualmente é o próprio autor) em uma reunião. Durante est reunião deve interromper a apresentação caso encontrem defeitos. Muitas vezes condições de entrada e saída e decisões são pressupostos pelo líder que segue sua linha de raciocínio durante a apresentação.
Possuem custo aproximadamente igual ao de inspeções mas seus resultados são inferiores:
Não providenciar resultados mensuráveis;
Não fornecer base para a aplicação de controle estatístico de processos,
necessários para evoluir na maturidade de processos de software.
Pode ser usado para atividades de brainstorming para explorar
alternativas de projeto e resolução de problemas (focadas em encontrar defeitos).
G
GEER R EENNCCIIAAMMEENNTTOO DDEE MMUUDDAANNÇÇAA DDEE R R EEQQUUIISSIITTOOSS
Figura 28 – Esquema do Gerenciamento de Requisitos (Fonte: extraído da Web)
Gerenciamento de Mudança de Requisitos é o processo de controlar as mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento.
Novos requisitos surgem durante o processo de desenvolvimento.
Diferentes pontos de vista possuem diferentes requisitos e esses são
frequentemente contraditórios. Mudanças nos requisitos
A prioridade dos requisitos pode mudar para atender novas demandas
de negócio;
Requisitos podem sofrer alteração quando muda a regra de negócio; As pessoas que pagam pelo software/sistema podem especificar os
requisitos de maneira conflitantes com os requisitos das pessoas que irão utilizar o software/sistema;
A empresa e o ambiente técnico do software/sistema se modificam
durante o processo de desenvolvimento.
Os principais objetivos desse processo são (KOTONYA;
SOMMERVILLE, 1998):
Gerenciar alterações nos requisitos acordados; Gerenciar relacionamentos entre requisitos;
Gerenciar dependências entre requisitos e outros documentos
produzidos durante o processo de software.
Para tal, o processo de gerência de requisitos deve incluir as seguintes atividades:
Figura 29 – Atividades de Gerência de Requisitos (Fonte: WIEGERS, 2003)
O controle de mudança define os procedimentos, processos e padrões que devem ser utilizados para gerenciar as alterações de requisitos, assegurando que qualquer proposta de mudança seja analisada conforme os critérios estabelecidos pela organização (KOTONYA; SOMMERVILLE, 1998). Mudanças podem ser necessárias em diferentes momentos e por
diferentes razões. De maneira geral, o controle de mudanças envolve atividades como (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003):
Verificar se uma mudança é válida;
Descobrir quais os requisitos e artefatos afetados pela mudança, o
que envolve rastrear informações;
Estimar o impacto e o custo das mudanças; Negociar as mudanças com os clientes;
Alterar requisitos e documentos associados.