Qualidade, Verificação e Validação

Qualidade, Verificação e Validação Tópicos em SI Informações gerais Código da Disciplina: 4620A-04 Turma: 168 Carga Horária: 30 horas-aula (somente módulo prof. Rodrigo Espindola) Número de Créditos: 04 Horário das aulas: 5NP Presença será verificada ao final da aula. Prof. Rodrigo Espindola PUCRS, FACIN Rodrigo.Espindola@pucrs.br Objetivos O cumprimento da disciplina busca dar ao aluno, ao final do semestre,condições de: 1. Elaborar e executar Planos de Teste de Software; 2. Selecionar técnicas de teste de software de acordo com as características dos produtos a serem testados; 3. Utilizar e projetar ferramentas de apoio ao teste de software; 4. Posicionar-se criticamente em relação à qualidade de processos e produtos de software. Avaliação Fórmula do Grau G1 G1 = (P1 + P2 + T1 + T2)/4 Onde: P1 Prova 1, abrange as unidades 1 a 3; P2 Prova 2, abrange as unidades 4 e 5; T1 Trabalho 1; T2 Trabalho 2. Datas P1-26/04 P2-21/06 PS - 28/06 G2-05/07 Observações: Na Faculdade de Informática a prova de substituição está prevista apenas para os casos em que o aluno falta a uma das provas. Aula Data Dia Hora Conteúdo 1 01/03 Qui NP Apresentação 3 08/03 Qui NP Visão geral de Qualidade e V&V 5 15/03 Qui NP Revisões Técnicas Formais 7 22/03 Qui NP Inspeções 9 29/03 Qui NP Walkthrough; exercício em grupo 11 05/04 Qui NP Feriado - Semana Santa - Feriado Escolar 13 12/04 Qui NP Exercícios 15 19/04 Qui NP Exercícios 17 26/04 Qui NP Prova 1 18 01/05 Ter NP Feriado - Dia do Trabalho - Feriado Nacional 19 03/05 Qui NP Perfil profissional 20 08/05 Ter NP Teste Estrutural; Trabalho 1 21 10/05 Qui NP Ética em Computação x Técnicas de Revisão 23 17/05 Qui NP Técnicas nos modelos 25 24/05 Qui NP Exercícios 27 31/05 Qui NP Exercícios 29 07/06 Qui NP Feriado - Corpus Christi - Feriado Municipal 31 14/06 Qui NP Trabalho 2: realização em aula e entrega 33 21/06 Qui NP Prova 2 35 28/06 Qui NP Prova Especial 37 05/07 Qui NP Prova G2 Material Internet PDF na página da disciplina em: http://www.inf.pucrs.br/~respindola 1

Quem somos nós? Rodrigo Espindola Bacharel em Sistemas de Informação PUCRS; Mestre em Ciência da Computação PPGCC; 13 anos atuando na área de TI; Coordenador técnico do projeto MS-CMMI3; E vocês? Nome? Experiência profissional? O que é qualidade na sua opinião? Expectativas? Conceitos A Qualidade de Software é definida por [PRESSMAN 2001] como: Conformidade com requisitos funcionais e de performance explicitamente estabelecidos, padrões de desenvolvimento explicitamente documentados e características implícitas inerentes a todo o profissional desenvolvedor de software. Conceitos Fundamentos da Qualidade de SW [PRESSMAN 2001]: Requisitos de software são a base na qual a qualidade é medida. Falta de conformidade com requisitos É falta de qualidade. Padrões especificados definem o conjunto de critérios de desenvolvimento que guiam a maneira na qual o software é construído. Se o critério não é seguido, a falta de qualidade é quase certa. Um conjunto de requisitos implícitos são frequentemente não mencionados (Ex: Facilidade de uso ou manutenção). Se o SW está de acordo com os requisitos explícitos mas falha nos implícitos a qualidade do SW é suspeita. Conceitos Garantia da qualidade de software: Conjunto de atividades técnicas aplicadas durante todo o processo de desenvolvimento do produto; O objetivo é garantir que tanto o processo de desenvolvimento quanto o produto desenvolvido atinjam os níveis de qualidade especificados; Conceitos Verificação Assegura que o produto atende às especificações Estamos construindo certo o produto? Validação Assegura que o produto atende às necessidades Estamos construindo o produto certo? Para reflexão Qual a importância do teste no contexto da qualidade de software? O teste é necessário? O teste é suficiente? Por que? 2

Teste X Qualidade de SW A qualidade não é testável. Se ela não existe antes de você começar a testar, ela não existirá quando o teste estiver terminado. A qualidade é incorporada no SW através da aplicação de processo de engenharia de software, tais como: Aplicação adequada de métodos e ferramentas; Revisões técnicas formais e revisão por pares efetivas; Acompanhamento e gerenciamento sólido; Defeito Defeito Erro Falha Defeito: Deficiência mecânica ou algorítmica que se ativada pode levar a uma falha. Erro: Item de informação ou estado de execução inconsistente. Falha: Evento notável onde o sistema viola suas especificações. Tipos de defeito Taxonomia definada por Shull (1998) a partir do padrão IEEE Std 830-1998 para especificação de requisitos: Tipo de Defeito Omissão Ambigüidade Inconsistência Fato Incorreto Inf. Estranha Definição Informação necessária não incluída Informação passível de múltiplas interpretações Informações conflitantes Informação que não é verdadeira para as condições especificadas Informação desnecessária OBS: De acordo com (Travassos et al., 2001) esta taxonomia também é aplicável a outros artefatos. Omissão 1. Algum requisito importante relacionado à funcionalidade, ao desempenho, às restrições de projeto, a atributos ou a interface externa não foi incluído; 2. Não está definida a resposta do software para todas as possíveis situações de entrada de dados; 3. Faltam seções na especificação de requisitos; 4. Faltam referências de figuras, tabelas e diagramas; 5. Falta definição de termos e unidades de medida. Exemplo de omissão Requisitos: 1. Livros podem ser emprestados para professores, funcionários e alunos. 2. O prazo de devolução para alunos é de 5 dias. 3. O prazo de devolução para professores é de 10 dias. 4. Dependendo da categoria do livro, o prazo poderá ser maior. Quais os defeitos nestes requisitos? Qual o prazo de devolução para funcionários? Quais as categorias possíveis? Quais os prazos diferenciados para cada categoria? Ambigüidade Um requisito tem várias interpretações devido a diferentes termos utilizados para uma mesma característica ou vários significados de um mesmo termo para um contexto em particular. 3

Exemplo de ambigüidade Requisitos: A multa será cobrada apenas de usuários do tipo aluno e professor. Qual o defeito neste requisito? Duas interpretações podem ser tiradas deste requisito devido ao uso incorreto do e : 1. A multa será cobrada tanto de professores quanto de alunos; 2. A multa será cobrada apenas de professores que também forem alunos; Inconsistência Dois ou mais requisitos são conflitantes. Exemplo de inconsistência: É permitido no máximo 10 renovações de um mesmo livro. Alunos podem permanecer com o mesmo livro por no máximo um semestre. Qual o defeito nestes requisitos? Inconsistências entre os períodos máximos de empréstimo nos dois requisitos. Fato incorreto Um requisito descreve um fato que não é verdadeiro, considerando as condições solicitadas para o sistema. Informação estranha As informações fornecidas no requisito não são necessárias ou mesmo usadas. Origem dos defeitos A tradução incorreta de informações entre as diversas etapas do processo de desenvolvimento de software é a principal causa de defeitos em software. Quanto mais cedo o defeito for identificado, menor será o custo de sua correção. Solução: Introduzir atividades de VER&VAL ao longo de todo o processo de desenvolvimento de software. Verificação e Validação (V&V) É uma abordagem disciplinada para avaliar a qualidade dos produtos de software durante todo o ciclo de vida do produto. [SWBOK] Objetivo: Assegurar que o software cumpra com suas especificações e atenda às necessidades dos clientes Constitui um processo em si Deve ser contemplado em todo o ciclo de vida Não apenas na etapa após desenvolvimento 4

Verificação e Validação (V&V) Por que utilizar técnicas de verificação e validação? Resultados de estudos experimentais evidenciam benefícios da utilização destas técnicas no desenvolvimento de software. A utilização destes métodos na indústria tem mostrado resultados positivos considerando tanto produtividade quanto qualidade. Alguns fatos sobre VER&VAL Inspeções aumentam significativamente a produtividade, qualidade e estabilidade dos projetos [FARGAN1976] Uma combinação de diferentes técnicas de VER&VAL apresenta melhor desempenho do que qualquer método isoladamente [HETZEL1976 e MEYER1978] Qualidade melhora a produtividade [MILLS1983] Corrigir um defeito após a entrega do produto é frequentemente 100 vezes mais caro que corrigi-lo durante as atividades de requisitos e projeto do sistema [BOEHM e BASILI 2001] Testes podem provar a presença de erros, não sua ausência [DIJKSTRA1970] Resultado Falta de documentação adequada; Falta de conhecimento técnico; Falhas de comunicação; Custo proibitivo para replicação de um ambiente equivalente ao operacional; Falta de planejamento; Qualidade não é considerada tão importante quanto prazo e custo; Baixo comprometimento do cliente com a validação; Falta de critérios de ver & val; Falta de método adequado para ver & val; Alta rotatividade dos funcionários; Falta de maturidade do processo; Exercício Por favor, reunir-se em grupos de 5 pessoas; Debater e listar os principais fatores que dificultam, na sua opinião, a realização de verificação e validação na empresa onde vocês trabalham / trabalharam (15min); Escolher um relator do grupo para apresentar a lista de dificuldades (5min p/ grupo); Resultados de grupos anteriores 1. Pouca efetividade nas revisões (revisões pró-forma); 2. Revisão de formato vs. revisão de conteúdo; 3. Critérios para revisões não estão claros ou ausentes; 4. Falta de padronização de artefatos causando falso positivo; 5. Perfil inadequado dos revisores ou falta de mapeamento dos perfis; 6. Falta de background dos revisores no projeto ou negócio; 7. Técnicas inadequadas para revisões ou falta de conhecimento das mesmas; 8. Revisão de 100% dos artefatos não seria necessária; 9. Análise de impacto das revisões nos artefatos dependentes; 10. Dificuldades para planejamento das revisões; 11. Dificuldades para cobrança dos resultados de revisões externas; 12. Limitações de acesso a documentação pelos revisores; 13. Erros básicos encontrados em tempo de teste; Resultados de grupos anteriores 1. Discrepância grande entre o produto e as especificações; 2. Corte das revisões em função de prazos; 3. Falta de ferramentas para automação de testes de regressão; 4. Falta de roteiros de teste; 5. Testes de requisitos não-funcionais inadequados ou ausentes; 6. Falta de ferramenta para revisões; 7. O teste é apertado contra o final do projeto (falta de planejamento); 8. Elaboração dos testes pelo analista de requisitos; 9. Amadurecimento do time em relação aos processos novos; 10. Atualizações de documentação não gerenciada; 11. Ambientes de teste instáveis; 12. Pouco conhecimento do cliente quanto ao processo de desenvolvimento; 13. Dificuldades de comunicação entre as áreas; 14. Omissão de artefatos (casos de teste, roteiros, etc.); 15. Baixa qualidade das especificações de requisitos; 16. Falta da participação do time de teste desde o início do projeto; 5

Verificação Avalia se o produto cumpre com: Sua especificação Requisitos funcionais e não-funcionais Padrões estabelecidos Validação Assegura que o software atende às expectativas do cliente Importante antecipar a validação dos requisitos evitando erros e omissões Pode não esgotar possíveis problemas Alguns aspectos podem ser identificados apenas durante a implementação Técnicas Em geral, as seguintes técnicas são adotadas: Revisões Inspeções Testes Outras: Prototipação Simulação Auditorias São complementares Técnicas - Revisões Determinam o grau de correspondência entre o produto, sua especificação, padrões estabelecidos e necessidades do cliente Não demonstram se o software é operacionalmente útil ou se suas características não-funcionais atendem os requisitos desejados Chamada estática Não requer que o sistema seja executado Técnicas - Revisões Em geral são classificadas em: Revisões técnicas formais Peer review Inspeção Walkthrough Opiniões de especialistas Técnicas - Testes Objetivos: Encontrar inconsistências entre o programa e sua especificação Avaliar o desempenho e a confiabilidade do programa e como ele se comporta sob condições operacionais Envolvem executar uma implementação do software com os dados de teste e examinar as saídas dele e seu comportamento operacional Dados reais ou não 6

Técnicas - Testes A existência de defeitos ou inadequações é inferida pelo exame das saídas e anomalias identificada Chamada dinâmica Requer trabalhar com uma representação executável do sistema Meta É estabelecer a confiança de que o produto é adequado a seu propósito Não significa que o produto está livre de defeitos Garante que o produto é suficientemente bom para o uso pretendido O nível de confiança dependerá: Das expectativas do cliente/usuário Do ambiente de mercado para o produto Do custo inerente as atividades de V&V Planejamento de V&V O processo de V&V é dispendioso Planejamento é fundamental Trazer resultados positivos Agregar valor Buscar equilíbrio entre: Custos e resultados esperados Orçamento disponível e complexidade do produto Estar alinhado ao restante do projeto Planejamento de V&V É o apoio para a equipe técnica projetar e realizar atividades de V&V Não é apenas gerencial Revisado periodicamente Levar em consideração limitações inerentes: Tempo e orçamento Subjetividade Qualificação do pessoal Qualificação do processo de V&V Planejamento de V&V Deve contemplar: Qual o ESCOPO Quais TÉCNICAS vão ser adotadas Quais os CRITÉRIOS DE ACEITAÇÃO Os RESPONSÁVEIS Por realizar as atividades Por prover suporte Qual o CRONOGRAMA das atividades Qual a documentação de apoio Quais são os procedimentos a serem seguidos Quais os recursos físicos necessários Hardware e Software CMMI: Verificação Objetivo: Garantir que os produtos atendam os requisitos especificados. Métodos que podem ser adotados: Revisão por pares (Inspeção, Walkthrough) Análise Simulação Teste Demonstração 7

CMMI: Verificação CMMI: Verificação CMMI: Verificação CMMI: Validação Objetivo: Demonstrar que o produto preenche seu propósito quando colocado em ambiente de uso. CMMI: Validação CMMI: Validação 8

Bibliografia GALIN, Daniel. Software Quality Assurance. Great Britain: Pearson - Addison Wesley, 2004. SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003. 9