Unidade II Atividades em PDS: Testes. Unidade III Suporte e Manutenção. Processo Desenvolvimento Software

Transcrição

1 Unidade II Atividades em PDS: Testes Unidade III Suporte e Manutenção

2 Atividades Básicas em um PDS Definição / Especificação: (o quê?) Análise econômica Análise de requisitos Especificação de requisitos Desenvolvimento : (como?) Arquitetura do sistema (desenho ou projeto de software) Implementação (codificação) Testes Manutenção: Documentação Suporte e Treinamento Melhoria Contínua

3 Mapa Conceitual da Disciplina

4 Objetivos Conhecer as atividades de Testes do processo de desenvolvimento Entender as necessidades da etapa de teste na melhoria da qualidade do sistema Analisar os diversos tipos de testes

5 Objetivos Conhecer as atividades de: Suporte Manutenção Entender a importância da documentação: do Processo do Produto

6 Introdução O pior erro e o mais caro é aquele que chega ao cliente e é descoberto por ele As falhas causam prejuízos financeiros As falhas causam a perda de confiança do cliente

7 Introdução Porque algumas pessoas não testam o software? Teste é um processo caro Desconhecem técnicas de teste adequadas Só se preocupam com teste na fase final do projeto Dificuldade em implantar um processo de teste Desconhecem a relação custo/benefício

8 Por que testar?

9 Por que testar? Encontrar o maior número possível de defeitos no software O mais cedo possível Evitar Falhas Antes que chegue ao usuário Garantir a qualidade do software Fator Preponderante

10 Testes Os testes são destinados a mostrar o que um programa faz, o que pretende fazer e para descobrir os defeitos do programa antes desse ser colocado em uso. Ao testar o software, você executa um programa usando dados artificiais. Podem revelar a presença de erros, NÃO a sua ausência. O teste é parte de um processo de verificação e validação mais geral, que também inclui técnicas de validação estática. Um software não pode ser exaustivamente testado Sucesso ligado principalmente às habilidades dos testadores

11 Fluxo de Testes Preparação Planejamento dos Testes (Identificar os itens a testar) Desenho dos Testes (Casos de Teste) Realização Implementação (Montagem do Ambiente) Execução ( Execução efetiva ) Entrega (Resultados e Relatórios )

12 Técnicas de Testes Os testes pelos quais passam o sistema devem ter 2 perspectivas Testes Funcionais ou Testes de Caixa Preta: garantem o atendimento aos requisitos são conduzidos na interface do software Testes Estruturais ou Testes de Caixa Branca: garantem que o software tenha estrutura sólida: robustez as tecnologias foram aplicadas adequadamente? os componentes funcionam como uma unidades coesas? verifica detalhes do código

13 Testes Funcionais ou de Caixa Preta Não considera a forma como o código está implementado (detalhes internos) Objetivo: O SW produz os resultados esperados? Os requisitos estão sendo atendidos. Não requer conhecimento prévio da tecnologia empregada e da implementação do código

14 Testes Estruturais ou de Caixa Branca Verifica a arquitetura interna do software Objetivo: Identificar os defeitos nas estruturas internas do software Teste de cada detalhe da estrutura do código Requer conhecimento técnico da tecnologia e do projeto de software. Deve ser bem planejado

15 Testes estáticos x Testes dinâmicos Testes estáticos ou Verificações ANTES da implementação Inspeções, revisões, auditorias Testes nas fases iniciais qualidade Qualidade no processo Testes dinâmicos ou Validações DURANTE OU APÓS a implementação Precisa de parte ou todo sistema implementado Qualidade no produto

16 Modalidade de Testes Concepção TESTES DINÂMICOS EXECUÇÃO Requisitos Análise Desenho Implementação Testes Manutenção TESTES ESTÁTICOS REVISÕES AUDITORIAS TESTES ESTÁTICOS REVISÃO DE CÓDIGO 16

17 Modalidade de Testes Níveis dos Testes O planejamento dos testes deve ocorrer em diferentes níveis e em paralelo ao desenvolvimento do software: Teste de Unidade Teste de Integração Teste de Sistema Teste de Regressão Teste de Aceitação

18 Teste de Unidade 1ª. Etapa do processo de validação. Testa 1(uma) unidade: modulo/classe Geralmente realizado na fase de Codificação Objetivo: garantir a qualidade dos componentes do software, individualmente, avaliando: Estrutura interna usar estratégia de caixa branca Se a unidade atende aos requisitos usar testes da caixa preta

19 Teste de Integração Natural continuidade dos testes de Unidade Verificar a compatibilidade da nova unidade com as demais, já prontas. Verificar se Juntas e integradas, as unidades funcionam e realizam o trabalho que o sistema precisa. Cuidado: alteração de componentes. Geralmente aplica-se estratégia da caixa preta, testando as interfaces entre as unidades, que se integram

20 Teste de Sistema Estágio mais complexo da validação Valida-se a solução como um todo Aqui as falhas individuais já estão sanadas (espera-se) Ambiente (Hw, SO, rede e etc) bem próximo da realidade da operação) Testa-se a integração com sistemas externos, dispositivos físicos (hw) Dificuldade de vislumbrar os vários cenários de uso. Realiza-se os testes não-funcionais do sistema: estresse, desempenho, usabilidade

21 Teste de Regressão Categoria Especial de Bateria de Testes Verificar se o sistema tem mesmo comportamento após ser alterado Executar novamente um subconjunto dos testes previamente executados Assegurar que alterações em partes do produto não afetem as partes já testadas Alterações durante a manutenção podem introduzir erros nas partes previamente testadas Recomenda-se que sejam automatizados

22 Teste de Aceitação Homologação: interna e externa Último estágio do processo de validação Último processo formal de detecção de erros no sistema para permitir ao cliente determinar se aceita ou não o sistema Uso por usuários finais que simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Usuários interagem com sistema completo Reduz o risco da entrega

23 Testes Mitos O teste é inimigo do desenvolvedor A equipe de testes deve ser criada com os desenvolvedores menos capacitados da equipe de desenvolvimento, afinal, quaquer um pode testar. Quando todo o software estiver pronto (o que talvez nunca aconteça), ele seguirá para o pessoal fazer o teste.

24 Testes Premissas O processo de testes começa em paralelo com o processo de desenvolvimento e integra-se a ele, ao longo. Inserção de técnicas de revisões e inspeções nos documentos e modelos produzidos Os testes em si devem priorizar as funcionalidades mais críticas, que podem por em risco o negócio Quanto mais cedo o erro for encontrado, mais barata a sua solução

25 Suporte Canal de comunicação pelo qual o cliente relata a ocorrência de um problema com o software, solicitando a sua solução Função do Suporte: Identificar a natureza do problema Caso se trate de um problema conhecido, auxiliar ou executar a solução do problema Caso contrário, fazer o encaminhamento do mesmo para a equipe de desenvolvimento Presencial ou remoto Níveis de disponibilidade Tudo acertado em contrato

26 Manutenção Fase que tem: Início: quando o sistema é instalado no ambiente do usuário, para uso. Fim: quando o sistema torna-se obsoleto e é substituído. Motivos da obsolescência: Tecnologia ultrapassada Custo de manutenção supera benefícios

27 Manutenção Ciclo de Vida do Sistema = Ciclo de desenvolvimento + Manutenção Logo Quanto maior o tempo da fase de manutenção, maior a vida útil do sistema

28 Manutenção A qualidade da manutenção vai depender da qualidade no processo de desenvolvimento Documentação atualizada e adequada Código eficiente e bem documentado Desafio: manter documentação atualizada, na medida em que são feitas alterações no sistema.

29 Manutenção Mudança de software é inevitável Novos requisitos surgem quando o software é usado; O ambiente de negócio muda; Erros devem ser reparados; Novos computadores e equipamentos são adicionados ao sistema; O desempenho ou a confiabilidade do sistema deve ser melhorada.

30 Tipos de Manutenção Reativas Manutenção Corretiva Realizada após a descoberta de defeitos. Manutenção Adaptativa Adaptar o software as mudanças do ambiente. Manutenção Evolutiva (Melhorias) Atender pedidos do usuário para modificar funções existentes ou incluir novas funções.

31 Tipos de Manutenção Proativas Manutenção Perfectiva Melhorar a performance ou manutenabilidade Manutenção Preventiva Detectar e corrigir erros antes que se tornem falhas

32 Distribuição do Esforço de Manutenção

33 Custos de Manutenção Relação dos custos gerais ao longo do processo de desenvolvimento e da manutenção. Quanto mais esforço no desenvolvimento maior facilidade de manutenção

34 Afetam o custo da manutenção Tipo de Aplicação Rotatividade e disponibilidade de Pessoal Duração da vida útil do sistema Ambiente (em que o sistema está inserido) que se modifica Características do hardware Qualidade do projeto, do código, da documentação e dos testes Caracteristicas das L.P. usadas

35 Afetam o tempo da manutenção Coesão dos elementos Desejável a alta coesão Acoplamento dos elementos Desejável o baixo acoplamento Documentação Desejável completa e atualizada

36 Pedido de Mudanças São feitos pelos utilizadores, clientes ou gerentes. Os pedidos devem ser documentados e analisados devem conter: Data Pedido Tipo de Mudança Na prática, alguns pedidos devem ser implementados urgentemente: Reparar falhas Mudanças no ambiente Mudanças urgentes do negócio

37 Previsão de Manutenção

38 Documentação para Suporte Manual do Sistema Manual de Referência Facilidades do uso do sistema Erros que podem ocorrer e como agir Manual de Instalação como instalar o sistema, plataformas de operação, pré-requisitos necessários.

39 Documentação para Manutenção Possibilitar que a equipe entenda o que foi pensado e as soluções dadas. Possibilitar que as alterações, versões e novas funções possam ser documentadas. Gestão de Configuração de Software Tipo de documentação: Textual Modelos (diagramas). Ferramentas CASE ajudam a manter a documentação VIVA e atualizada.

40 Documentação do Processo Cronogramas Acompanhar o andamento dos prazos Relatórios Acompanhamento do consumo de recursos Padronização de processos Da empresa Ou referencia nacional / internacional Comunicação entre projetos. Lições aprendidas

41 Referência para Estudo Esta apresentação Material da Estácio Livro Engenharia de Software Fundamentos e Padrões Wilson de Pádua Capítulo 8 Testes Engenharia de Software Sommerville, 6ED Capítulo 19 Verificação e Validação Capítulo 20 Testes de Software Capítulo 27 Mudanças em Software Capítulo 28 Reengenharia de Software

42 Para Descontrair