Planilha de como validar um software

19 de novembro de 2015

Esta é uma publicação que tem uma planilha em Excel para se validar um software e até mesmo uma planilha com um programa, publicada pela Imasters 

Recentemente, no meu trabalho, surgiu a necessidade de definir uma validação formal de requisitos de software. Atualmente no nosso processo, após o levantamento de requisitos, é elaborada uma especificação de requisitos e após a conclusão da mesma, o documento é submetido para avaliação e consenso da área técnica (desenvolvimento) e do cliente.

O objetivo da avaliação da especificação, além de obter o consenso da área técnica e do cliente, também visa uma avaliação da qualidade da especificação, através da atribuição de uma nota. Para o cliente é enviado um formulário por e-mail e na área técnica este formulário é preenchido no próprio Sistema de Workflow da Análise.

O que percebemos é que estava faltando um padrão de validação dos requisitos que servisse de base principalmente para a área técnica. Por conta dessa necessidade efetuei uma pesquisa de métodos de validação de requisitos e estou compartilhando a compilação dos resultados encontrados através desse artigo.

O objetivo da validação de requisitos é descobrir erros nos requisitos documentados. Exemplos típicos de erros são ambiguidades, incompletudes e contradições. Documentos de requisitos são documentos de referência para todas as demais atividades de desenvolvimento.

Consequentemente, erros afetam negativamente todas as atividades posteriores de desenvolvimento. Um erro de requisito descoberto quando o sistema já está implementado e operando exige a revisão de todos os artefatos pelo erro, tais como, código fonte, artefatos de testes e descrições de arquitetura. A correção de erros nos requisitos, quando o sistema já está em produção, implica custos significativos.

Um contrato entre o cliente e o contratado baseia-se frequentemente em documentos de requisitos. Erros críticos em requisitos podem levar ao cumprimento de acordos contratuais, como por exemplo, o escopo de suprimentos e serviços de qualidade esperada ou prazos de conclusão.
Revalidação de requisitos de software

A validação ocorre em um momento específico durante o processo de desenvolvimento, apoiando-se no nível de conhecimento dos avaliadores naquele momento. Durante a engenharia de requisitos, os stakeholders adquirem conhecimentos adicionais sobre o sistema em planejamento.

Consequentemente, uma validação positiva de requisitos não garante que os requisitos ainda continuem válidos em um momento posterior.

Avaliação de requisitos deveria ser realizada várias vezes nos seguintes casos:
  1. Grande quantidade de ideias e tecnologias inovadoras usada no sistema;
  2. Acréscimo significativo de conhecimento durante a engenharia de requisitos;
  3. Projeto de longa duração;
  4. Validação de requisitos realizada muito cedo;
  5. Domínio desconhecido;
  6. Reutilização de requisitos.
  7. Utilização de checklist para a validação

Checklist (ou lista de verificação) é um conjunto de perguntas e/ou afirmações sobre determinada circunstância. O checklist pode ser aplicado sempre que muitos aspectos precisam ser considerados em um ambiente complexo e que nenhum aspecto possa ser omitido.

Uma lista de verificação para a validação de requisitos contém perguntas que facilitam a identificação de erros. O uso de checklists para a validação de requisitos é muito comum na prática. Ele pode especificar uma lista de perguntas a ser estritamente seguida. Essas perguntas devem obrigatoriamente ser respondidas pelo avaliador. A lista de verificação serve como um meio para abordar a validação de forma estruturada.

Aplicar o checklist para a validação de requisitos de maneira bem sucedida depende da maleabilidade e complexidade da lista de verificação. Um grande número de perguntas pode dificultar o uso da lista, pois o avaliador não possui uma visão aprofundada das perguntas, sendo forçado a consultá-la frequentemente.

Recomenda-se, portanto, elaborar uma lista de verificação de tal forma que ela seja mais longa do que uma página. Além disso, perguntas formuladas de forma demasiadamente genérica ou abstrata podem dificultar o uso. Sendo assim, as perguntas devem ser da forma mais precisa possível.
Checklist de requisitos de software

Checklist é uma técnica usada durante Revisões Técnicas Formais (RTF), atividade que garante a qualidade do software. Seus objetivos são:
  1. Descobrir erros de função, de lógica ou de implementação para qualquer representação do software;
  2. Verificar que o software em questão atende aos requisitos especificados;
  3. Garantir que o software foi representado de acordo com padrões pré-definidos;
  4. Garantir que o software seja desenvolvido de maneira uniforme;
  5. Desenvolver projetos mais gerenciáveis.
O checklist ajuda o gerente a coordenar a reunião de RTF e ajuda cada revisor a focar nas características importantes. Os checklists devem ser aplicados a documentos de análise, projeto, codificação, e teste, focando os aspectos e defeitos comuns da fase correspondente. Por exemplo, as questões no checklist para a fase de requisitos devem apontar os problemas e defeitos que podem aparecer nos documentos de especificação de requisitos e correlatos.

Tabela 1 – Características de uma boa especificação de requisitos:
Fonte: Norma IEEE 830-1998.

Tabela 2 – Princípios por trás do manifesto ágil:
Fonte [Agile Manifesto 2011]

Analisando as informações acima e com base nos processo de Analise de Sistema, decidiu-se escolher as características “Não ambíguo”, “Completo” e “Consistente”, pois estas características estão totalmente envolvidas no processo de Análise. As demais características não foram consideradas por estarem relacionadas aos processos de Qualidade e Homologação de Software e neste primeiro momento estes processos não são o foco do estudo.

Segue o modelo de Checklist elaborado com base na análise e compilação de vários modelos encontrados e de acordo com as características elencadas como necessárias para validação da especificação de requisitos, considerando como premissa o cenário de visão do cliente, que visa a validação funcional dos requisitos.

Tabela 3 – Modelo de Checklist de Validação de Requisitos:

Referências:

Padrão IEEE de Especificação de Requisitos de Software – IEEE830
Livro: Fundamentos Da Engenharia De Requisitos

1 comentários:

Vanessa Guimarães disse...

boa tarde Carla
sou empreiteiro de acabamento to entrando no ramo de granitina mais to por fora de preços
poderia me ajuda
to fazendo um colégio e cobrei 51 reais o metro dando a granitina e os frisos
mais não sem como cobra a resina
quanto custa o polimento de granitina antiga
você poderia me ajuda
meu e-mail e vitoriabrasilltda@hotmail.com


Postar um comentário

Os comentários são muito bem vindos e importantes, mas assine com seu Nome/URL, onde trabalha e de qual estado/cidade você é.

 
Clube do Concreto | by TNB ©2010