Aula 4 - Avaliação de SW

Prévia do material em texto

Unidade II – Testes de Verificação 
10 – Analisando cada fase 
Unidade II 
Avaliação de Software 
Prof. Ulisses Sperle Graça 
Março/2013 
2 
 Cada fase do projeto de software cumpre uma 
importante de entendimento do problema e da definição 
de uma solução mais adequada às necessidades do cliente. 
Cabe ao processo de qualidade de software garantir que 
cada etapa esteja sendo concluída adequadamente para 
que a próxima etapa seja desempenhada da forma mais 
produtiva possível. 
A etapa de verificação tem importância fundamental no 
processo de qualidade, pois focaliza suas ações nas etapas 
iniciais do projeto, nas quais geralmente ocorre a maior 
incidência de erro. 
Fazendo uma Reflexão 
3 
 Geralmente, as etapas de um projeto produzem 
documentos sem que estes sofram avaliação direta, 
impedindo que determinado problema seja avaliado por 
diferentes ângulos, aumentando os riscos das decisões 
formalizadas serem inconsistentes. 
É aqui que a verificação ganha força e torna-se um 
importante mecanismo na prevenção de erros, pois atua 
diretamente na fonte das decisões e avalia se 
determinadas atividades críticas do processo estão sendo 
realizadas. 
Introdução 
4 
Análise das Fases dos Testes de Verificação 
 
Modelo 
de 
Negócios 
 
 
Implementação 
 
Análise 
e 
Modelagem 
 Revisar Contexto do Mercado e Necessidades Cliente; 
 Revisar Riscos do Projeto; 
 Auditar Alternativas de Execução do Projeto; 
 Revisar Estudo de Viabilidade do Projeto; 
 Revisar Arquitetura da Aplicação; 
 Revisar o Modelo Estático do Projeto de Software; 
 Revisar o Modelo Dinâmico do Projeto de Software; 
 Revisar Nível de Componentização; 
 Revisar Nível de Reutilização; 
 
 Modelo de Negócios; 
 Análise de Riscos; 
 Arvore de Decisão; 
 Estudo de Viabilidade; 
 Arquitetura da Aplicação; 
 Modelos Estáticos; 
 Modelos Dinâmicos; 
 Modelos Distribuição; 
 Código-Fonte; 
 Componentes; 
 Manual do Usuário; 
 Revisar o Código-Fonte; 
 Avaliar Complexidade do Código-Fonte; 
 Auditar Rastreabilidade entre Componentes;. 
 Revisar Manual do Usuário; 
 
 Especificação Requisitos; 
 Rastreabilidade; 
 Revisar Especificação de Requisitos Funcionais; 
 Revisar Especificação de Requisitos Não funcionais; 
 Revisar Priorização de Requisitos; 
 Auditar Rastreabilidade de Requisitos; 
 
 
 
Especificação 
de 
Requisitos 
Fase da 
Verificação 
Principais 
Produtos 
Principais Atividades da 
Fase de Verificação 
5 
 Normalmente esta fase não é convenientemente 
explorada e é crucial para sucesso do projeto. 
 É aqui que estabelecemos o primeiro contato com as 
necessidades, expectativas e exigências do cliente, 
conseguindo estabelecer uma macrovisão da extensão do 
projeto e dos principais objetivos a serem alcançados. 
 Espera-se a criação da macrovisão, possibilitando um 
dimensionamento dos recursos humanos, físicos e financeiros 
necessários. 
 Com essa visão bem definida, os prazos e custos 
adequadamente projetados e objetivos e necessidades a serem 
alcançadas, poderemos avaliar se é vantajoso prosseguir ou não 
com o projeto. 
Verificação de Negócios 
6 
O objetivo é garantir que os diversos documentos 
produzidos tenham total aderência às necessidades 
apontadas pelos clientes, pois muitos projetos são 
iniciados sem a validação da macrovisão pelo cliente. 
Possibilita explorar alguns aspectos que poderiam 
inviabilizar um projeto, levando o cliente a perder uma 
oportunidade de negócio devido ao mal dimensionamento. 
Pontos de Verificação de Negócios 
 
Modelo 
de 
Negócios 
 Revisar Contexto do Mercado e Necessidades Cliente; 
 Revisar Riscos do Projeto; 
 Auditar Alternativas de Execução do Projeto; 
 Revisar Estudo de Viabilidade do Projeto; 
 Modelo de Negócios; 
 Análise de Riscos; 
 Arvore de Decisão; 
 Estudo de Viabilidade; 
Fase da 
Verificação 
Principais 
Produtos 
Principais Atividades da 
Fase de Verificação 
7 
Pontos críticos para avaliarmos a qualidade desses documentos: 
 Avaliar se todas as necessidades, metas e exigências foram listadas; 
 Verificar se a modelagem de negócios cobre todas as necessidades; 
 Conferir se as projeções são baseadas em indicadores confiáveis; 
 Avaliar a existência de alternativas de solução; 
 Avaliar o ROI em cada alternativa existente; 
 Validar as opções de investimento. 
Pontos de Verificação de Negócios 
 Modelar as necessidades e estabelecer uma macrovisão. 
 Identificar expectativas e exigências do cliente; 
 Estimar prazos e custos do projeto de software 
 Modelo de Negócios 
 Verificar aderência do modelo de negócios com a macrovisão. 
 Verificar as expectativas e exigências do cliente; 
 Verificar se projeções foram realizadas criteriosamente. 
 Verificação de Negócios 
1 
8 
Deverá existir um checklist para cada documento produzido na 
fase de verificação da modelagem de negócios. 
É conveniente que todos os documentos gerados sejam 
revisados pelo cliente, uma vez que serão eles que “pagarão a 
conta” caso as coisas não sejam bem planejadas. 
Deve-se estabelecer um critério de finalização apoiado no 
aceite de toda a documentação referente à modelagem de 
negócios e ao documento que descreve as condições técnicas e 
financeiras a que será submetido esse projeto. Exemplos: 
 Modelagem de negócios assinada pelas diretorias e gerências 
envolvidas; 
 Proposta de projeto de software assinada pelas diretorias e 
gerências envolvidas. 
Pontos de Verificação de Negócios 
9 
Tem a missão de detalhar todos os aspectos funcionais e 
não funcionais relativos à solução a ser construída, 
estabelecendo todo o conjunto de especificações de 
negócio em seu nível máximo de detalhamento. 
É nesse momento que as áreas de negócio e TI detalham e 
estabelecem a verdadeira dimensão do projeto. 
É aqui que refinamos as expectativas do cliente em 
relação ao produto, já que seu detalhamento possibilita a 
descoberta de aspectos não discutidos. 
Poderão ser rediscutidos custos e prazos para a 
introdução dos referidos aspectos. 
Verificação de Requisitos 
10 
Os requisitos direcionarão todas as fases posteriores do 
desenvolvimento, que serão registrados sem especificar 
como serão implementados. 
A qualidade dos requisitos é um importante indicador de 
uma organização, pois bons controles de requisitos estão 
geralmente associados ao nível de maturidade 
organizacional. 
É comum que novos requisitos sejam incorporados ao longo 
do projeto. Gerenciar bem essa demanda adicional de 
requisitos significa controlar os impactos de tempo e 
recursos. Trata-se de uma fase crítica do processo. 
Verificação de Requisitos 
11 
Os revisores deverão concentrar-se na identificação de 
todos os requisitos funcionais e não funcionais. É muito 
comum que os requisitos sejam relatados de forma 
simplificada, sem que exista real entendimento sobre o 
que está sendo listado. 
Cada requisito deve ser claro para que não produza uma 
interpretação errada, o que provocaria um erro na 
concepção do produto e gerando um custo adicional. 
Pontos de Verificação de Requisitos 
Fase da 
Verificação 
Principais 
Produtos 
Principais Atividades da 
Fase de Verificação 
 Especificação Requisitos; 
 Rastreabilidade; 
 Revisar Especificação de Requisitos Funcionais; 
 Revisar Especificação de Requisitos Não funcionais; 
 Revisar Priorização de Requisitos; 
 Auditar Rastreabilidade de Requisitos; 
 
 
 
Especificação 
de 
Requisitos 
12 
Requisitos funcionais  funcionalidade a ser 
implementada no software para atender a uma 
necessidade de automação. 
Requisitos não funcionais  características implícitas que 
são esperadas de todosoftware profissionalmente 
desenvolvido. 
Pontos de Verificação de Requisitos 
13 
Pontos críticos para avaliarmos a qualidade dos requisitos: 
 Completo: todos os requisitos devem estar documentados; 
 Claro: deve expressar seu propósito em relação ao projeto; 
 Simples: deve expressar sua essência com uma simples definição; 
 Preciso: deve ser exato e sem dar margens à dúvidas; 
 Consistente: não deve possuir conflitos com outros requisitos; 
Testável: deverá permitir a verificação se foi adequadamente implementado; 
 Relevante: deve pertencer ao escopo do projeto em questão; 
 Factível: deverá ser viável a sua implementação. 
Pontos de Verificação de Requisitos 
 Identificar os requisitos funcionais; 
 Identificar os requisitos não funcionais; 
 Identificar a arquitetura da aplicação. 
 Especificação de 
Requisitos 
 
 Verificar a consistência dos requisitos funcionais; 
 Verificar a consistência dos requisitos não funcionais; 
 Verificar a rastreabilidade entre requisitos e necessidades. 
 
Verificação de 
Requisitos 
2 
14 
Expressões como ser um software seguro, fácil de usar, fácil de 
manter, ter boa performance, são muitas vezes mal explicadas. São 
através desses parâmetros que avaliaremos se os requistos foram 
bem implementados ou não. 
Ex: as consultas a pedidos (100 usuários simultâneos e em diferentes 
sites) deverão ocorrer em até 10 segundos. 
Deverá existir um checklist para cada documento produzido na fase 
de verificação de requisitos. 
O critério de finalização desta etapa deve garantir que todos os 
requisitos foram adequadamente identificados. Eles devem refletir o 
que o cliente espera receber quando o software estiver disponível e 
servirá como uma espécie de contrato de serviço. Exemplos: 
 Especificações funcionais criadas e revisadas; 
 Especificações não funcionais criadas e revisadas; 
 Rastreabilidade entre requisitos e entre necessidades. 
Pontos de Verificação de Requisitos 
15 
Tem o objetivo de definir uma solução tecnológica que 
suporte não somente os requisitos estabelecidos pelo 
cliente, mas também requisitos de qualidade que são 
exigidos de todo software profissionalmente desenvolvido. 
Uma boa modelagem deve contemplar características como 
flexibilidade (acomodar mudanças), escalabilidade 
(suportar crescimento), ser reutilizável etc. 
Verificação da Análise e Modelagem 
16 
Muitas vezes, as soluções modeladas nem sempre são 
adequadas a longo prazo, evidenciando falhas no seu 
processo de definição. 
As revisões possibilitam validar determinados aspectos 
críticos da solução (ex.: parametrização) 
Verificação da Análise e Modelagem 
 
Análise 
e 
Modelagem 
 Revisar Arquitetura da Aplicação; 
 Revisar o Modelo Estático do Projeto de Software; 
 Revisar o Modelo Dinâmico do Projeto de Software; 
 Revisar Nível de Componentização; 
 Revisar Nível de Reutilização; 
 
 Arquitetura da Aplicação; 
 Modelos Estáticos; 
 Modelos Dinâmicos; 
 Modelos Distribuição; 
17 
O objetivo desta fase não está somente na avaliação da 
aderência da solução tecnológica aos requisitos funcionais 
e não funcionais, mas também avaliar a modelagem como 
um todo. 
Nessa fase, as revisões devem simular cenários de 
mudanças que possibilitem avaliar o quanto a solução 
consegue absorver mudanças de negócios e tecnologias 
que poderão ocorrer ao longo do tempo, simulando um 
impacto direto na arquitetura da solução modelada. 
Pontos de Verificação da Análise e Modelagem 
18 
Alguns pontos que poderão ser avaliados durante esse processo: 
 Avaliar se todos os requisitos funcionais e não funcionais contemplam a 
solução; 
Avaliar se a arquitetura suporta o crescimento e a segurança desejados; 
Avaliar se a arquitetura suporta futuras mudanças de negócios e de 
tecnologia; 
Avaliar se a arquitetura pode ser operacionalizada em vários ambientes; 
Avaliar as restrições e problemas conhecidos da arquitetura a ser adotada. 
Pontos de Verificação da Análise e Modelagem 
 Modelar uma solução que suporte todos os requisitos; 
 Modelar uma arquitetura flexível, escalável e reutilizável; 
 Modelar uma arquitetura que suporte mudanças. 
 Análise e Modelagem 
 
 Verificar a consistência da arquitetura da solução; 
 Verificar aderência de requisitos funcionais com a solução; 
 Verificar aderência de requisitos não funcionais com a solução; 
 
Verificação da 
Análise e Modelagem 
3 
19 
Um checklist de verificação da análise e modelagem 
deverá existir para cada documento a ser revisado. 
Caso o projeto esteja utilizando diagramas UML para 
representaras decisões de modelagem e da arquitetura, 
poderemos empregar uma checklist com as seguintes 
características, mostradas no próximo slide: 
Pontos de Verificação da Análise e Modelagem 
20 
Check-List do Diagramas UML 
 
 Diagramas de Classes 
 - Todas as classes possuem nome e descrição adequados. 
 
 OK 
 
 Não OK 
 
- Todos os atributos da classe possuem nome e descrição adequados. 
 
 OK 
 
 Não OK 
 
- Todos os serviços da classe possuem nome e descrição adequados. 
 
 OK 
 
 Não OK 
 
Diagrama de Estado 
 - Todas as transições de estado possuem um serviço ou evento associado. 
 
 OK 
 
 Não OK 
 
- Todos os estados possuem nome e descrição adequados. 
 
 OK 
 
 Não OK 
 
- Todas as transições de estado refletem o real ciclo de vida da classe. 
 
 OK 
 
 Não OK 
 
Diagramas de Componentes 
 - As “Packages” agrupam componentes com mesmas características. 
 
 OK 
 
 Não OK 
 
- Cada componente agrupa classes de única camada: user, business, data 
 
 OK 
 
 Não OK 
 
- Todas as dependências dos Componentes foram estabelecidas. 
 
 OK 
 
 Não OK 
 
Pontos de Verificação da Análise e Modelagem 
21 
Pontos de Verificação da Análise e Modelagem 
Checklist da Arquitetura 
Suportar Mudanças nos Negócios 
Existem parametrizações que modificam a 
funcionalidade da aplicação 
Sim Não 
Suportar Mudanças Tecnológicas 
O software possui independência do banco de 
dados 
Sim Não 
O software possui independência do sistema 
operacional 
Sim Não 
O software possui independência de browsers Sim Não 
22 
Um critério de finalização para esta etapa, deve garantir que a 
solução modelada atenda adequadamente a todos os requisitos, além 
de incorporar características que deixam a arquitetura flexível e 
aderente a futuras mudanças. 
Essa arquitetura deverá ser validada com toda a equipe, inclusive a 
equipe técnica do cliente (se for o caso). 
Alguns critérios que poderia ser usados para finalizar esta fase: 
 Diagramas estáticos (classes e objetos) criados e revisados; 
 Diagramas dinâmicos (estados, sequências e atividades) criados 
e revisados; 
 Diagramas de distribuição (componentes e implantação) criados 
e revisados 
Pontos de Verificação da Análise e Modelagem 
23 
Essa fase encerra o ciclo de verificação dos testes. 
Aqui, toda a documentação produzida nas fases anteriores 
será transformada em código de uma determinada 
linguagem. 
Muitas organizações começam seu ciclo de verificação aqui. 
Como muitas possuem um fraco processo de coleta de 
requisitos e modelagem de negócios, tal verificação torna-
se inócua. 
Transformar em código especificações ruins, incompletas e 
imprecisas acarreta produtos inadequados e pouco 
confiáveis. 
Verificação da Implementação 
24 
Algumas empresas realizam um processo formal de 
verificação do código produzido, onde os testadores 
avaliam linha por linha em busca de erros, alternativas 
melhores, comentam nomes e declarações não compatíveis 
com os documentos gerados antes.Este processo pode ser muito informal, onde cada 
desenvolvedor avalia o código de outro profissional em 
busca de erros. 
Verificação da Implementação 
 
 
Implementação 
 Código-Fonte; 
 Componentes; 
 Manual do Usuário; 
 Revisar o Código-Fonte; 
 Avaliar Complexidade do Código-Fonte; 
 Auditar Rastreabilidade entre Componentes;. 
 Revisar Manual do Usuário; 
 
25 
O objetivo desta fase é garantir a qualidade do código-
fonte gerado. 
Essa qualidade será atribuída pela prática das chamadas 
“regras da boa programação”, que podem contemplar 
diversas norma e padrões corporativos seguidos que 
devem ser seguidos pelas equipes de desenvolvimento. 
Pontos de Verificação da Implementação 
26 
Alguns pontos que poderão ser considerados críticos para avaliar: 
 Comparar os modelos da arquitetura com os códigos-fonte; 
 Utilizar ferramenta de análise estática para avaliar a complexidade dos fontes; 
Avaliar as mensagens apresentadas ao usuário final; 
 Inspecionar a existência de rotinas de tratamento de erros nos programas 
críticos; 
 Inspecionar se o volume de comentários é suficiente e a legibilidade do código; 
 Inspecionar o padrão de nomenclaturas existentes. 
Pontos de Verificação da Implementação 
 Traduzir modelos em estruturas internas dos códigos; 
 Traduzir os requisitos de negócios, regras e comportamentos 
em código-fonte. 
 Implementação 
 
 Garantir que os fontes estão compatíveis com os modelos; 
 Garantir a aplicação das normas e padrões de desenvolvimento; 
 Garantir reduzido nível de complexidade das fontes; 
 
Verificação da 
Implementação 
4 
27 
Uma checklist da implementação deverá contemplar um 
único documento a ser inspecionado. 
No caso de linguagens de programação, alguns pontos 
serão específico de cada tecnologia, enquanto outros 
serão comuns. 
Existirá uma checklist específica para o banco de dados. 
Pontos de Verificação da Implementação 
28 
Pontos de Verificação da Implementação 
Checklist do Banco de Dados 
Comparação do Modelo de Dados com o Banco de Dados 
Todas as tabelas do modelo foram implementadas Sim Não 
Todos os campos de cada tabela foram implementados SIM Não 
Todos os índices de cada tabela foram implementados Sim Não 
Todos os stored procedures de cada tabela foram implementados Sim Não 
Todas as visões do modelo de dados foram implementadas Sim Não 
Todos os campos de cada visão foram implementados Sim Não 
29 
Podemos empregar uma ferramenta cujo objetivo é realizar, de forma 
automática, inspeções nos códigos gerados pela equipe de 
desenvolvimento. 
Essa ferramenta realizará uma análise das normas e padrões 
relacionada às boas práticas da programação. 
Também será analisada a complexidade do código-fonte, que avaliará 
se os códigos estão sendo construídos ou não. 
O resultado será uma lista de não conformidades que será analisada 
pela equipe de desenvolvimento até que os critérios de finalização 
sejam alcançados, considerando o código-fonte OK. 
Pontos de Verificação da Implementação 
30 
A ferramenta utiliza a métrica de McCabe para determinar o nível de 
complexidade do código (complexidade ciclomática) e identificar a 
probabilidade, onde: 
 Complexidade Ciclomática: é o nível de complexidade segundo a métrica de 
McCabe; 
 Avaliação da Complexidade: estabelece as categorias de complexidade 
possíveis a serem atribuídas a um código-fonte; 
 Esforço de Manutenção e Teste: dimensiona o esforço necessário para a 
realização de testes caixa branca e realização de manutenções nas diversas 
categorias de complexidade de um código-fonte; 
 Probabilidade de Inserção de erros:dimensiona a possibilidade de risco 
associado às categorias de complexidades de uma determinada manutenção 
inserir um novo erro. 
Análise da Complexidade do Código 
31 
Análise da Complexidade do Código 
Thomas McCabe se baseia na representação do fluxo de controle de um 
programa. Ela determina o número de regiões num gráfico planar. 
 
Uma vez que o número de regiões aumenta com o número de caminhos 
de decisão e laços, esta métrica oferece uma medida quantitativa da 
dificuldade de fazer testes e uma indicação da confiabilidade geral. 
 
Estudos experimentais indicam uma relação entre esta métrica e o 
número de erros no programa, bem como no tempo de descobrir e 
corrigir estes erros. 
 
V(G) = 10 parece ser um limite superior para o tamanho modular 
32 
Notação do Grafo de Fluxo 
Exemplo: Segmento de programa fonte e seu correspondente grafo 
de fluxo. 
 procedure:sort 
 
1: do while records remain 
 read record; 
2: if record field1 = 0 
3: then process record; 
 store in buffer; 
 increment counter; 
4: else if record field2 = 0 
5: then reset counter; 
6: else process record; 
 store in file; 
7: endif 
 endif 
8: enddo 
9: end 
1 
2 
4 
6 5 
7 
3 
8 
9 
nó 
ramo 
R1 
R2 R3 
R4 
Região 
33 
Pontos de Verificação da Implementação 
Complexidade 
Ciclomática 
 
Avaliação 
da Complexidade 
 
Esforço de 
Manutenção e 
Teste 
 
Probabilidade de 
inserção de erros 
 
< 5 
 
Simples 
 
Baixo Esforço 
 
1 % 
 
5-10 
 
Moderado 
 
Médio Esforço 
 
5 % 
 
11-20 
 
Difícil 
 
Grande Esforço 
 
10 % 
 
21-50 
 
Muito Difícil 
 
Muito Complexo 
 
30 % 
 
> 50 
 
Impossível testar 
 
Refazer 
 
- 
 
34 
Pontos de Verificação da Implementação 
Complexidade 
Ciclomática 
 
Avaliação 
da Complexidade 
 
Percentual Máximo 
Permitido 
 < 5 
 
Simples 
 
100 % 
 5-10 
 
Moderado 
 
20 % 
 11-20 
 
Difícil 
 
5 % 
 21-50 
 
Muito Difícil 
 
Não Permitido 
 > 50 
 
Impossível testar 
 
Não Permitido 
 
Segundo o critério de finalização pela análise da complexidade de 
código, somente serão considerados em conformidade os fontes 
que estiverem de acordo com os critérios estabelecidos abaixo: