Qualidade Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção.

Apresentação em tema: "Qualidade Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção."— Transcrição da apresentação:

1 Qualidade Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção com qualidade. “Tem-se dado grande importância ao processo como forma de se garantir um software de melhor qualidade.”

2 Qualidade 1) Requisitos de Software
QUALIDADE enfatiza três importantes conceitos: 1) Requisitos de Software formam a base a partir da qual a qualidade é avaliada. Falta de concordância com os requisitos é falta de qualidade. 2) Padrões especificados definem um conjunto de Critérios de Desenvolvimento que orientam a maneira como o software é construído. Se o critério não for seguido, certamente haverá falta de qualidade. 3) Requisitos Implícitos que freqüentemente não são mencionados. (ex: desejo de boa manutenibilidade). Se o software atende aos requisitos explícitos, mas falha nos requisitos implícitos, a qualidade é suspeita.

3 Qualidade? A priori Qualidade é um conceito muito subjetivo, pois dependendo da percepção de cada! Pode se distinguir dois pontos de vista importantes: Ponto de vista do cliente; Ponto de vista do fornecedor.

4 Ponto de Vista do Cliente
A qualidade de um produto está ligada ao: seu desempenho; comprimento fiel das especificações; relação custo/benefício; seu padrão de excelência em relação a um padrão mínimo exigido; condição de atendimento durante o processo de aquisição; tradição no mercado; adequação ao uso de cada um; segurança de uso que ele traz;

5 Ponto de Vista do Fornecedor
Capacidade de levar a satisfação ao cliente; relação custo/benefício; adequação ao mercado, à concorrência, e aos clientes.

6 Níveis Estruturais de um Sistema de Qualidade
Nível Estratégico Alta gerência Nível Tático Média Gerência Em todos os níveis Nível operacional Supervisores, Técnicos e Operadores PQ MQ PO IT - EP - D RQ O que? Como? PQ - Política de Qualidade Intenções e diretrizes globais de uma organização relativas à qualidade. MQ - Manual da Qualidade Documento onde constam essas políticas. Planejamento da implementação. PO - Procedimentos Operacionais Documento que reúne todos os procedimentos e técnicas de controle para assegurar que os requisitos planejados da qualidade serão atendidos. IT - Instruções de Trabalho Instruções detalhadas onde constam as técnicas, processos, etc. de como se realizar determinadas atividades do processo produtivo. EP - Especificações Detalham requisitos especificados para assegurar a adequação dos produtos às necessidades do cliente D - Desenhos Detalham requisitos a serem seguidos na produção para assegurar a adequação dos produtos. RQ - Registros da Qualidade Registra todas as atividades a ser controladas e o modo como foram controladas no processo produtivo. Primeiro Seminário do Projeto "Jovem Cientista-UFMA"

7 Visões sobre a importância da qualidade do produto e do processo
Visão que aborda a qualidade do produto Funcionalidade, confiabilidade, utilizabilidade, eficiência, manutenibilidade e portabilidade. Visão que aborda a qualidade do processo Dos requisitos do usuário à entrega do produto final, existe um processo de desenvolvimento complexo e dividido em fases, que pode comprometer a qualidade do software.

8 Modelo de Processo de Software
Modelo de Processo é representado por um conjunto seqüencial de atividades, objetivos, transformações e eventos que encapsulam estratégias para o cumprimento da evolução do software. A efetividade de um modelo depende da adequação deste com as metas do projeto, ex. confiabilidade, produtividade e recursos disponíveis. Um modelo de processo deve ser flexível.

9 Gerência de Processo de Software
A gerência de processo objetiva a geração de produtos de acordo com o planejado e, ao mesmo tempo, melhorar a capacidade de produzir software com mais qualidade. Melhor capacidade de lidar com o software: Passo 1. Compreender o estado atual do processo; Passo 2. Desenvolver uma visão do processo desejado; Passo 3. Estabelecer ações para a melhoria do processo; Passo 4. Gerar um plano para acompanhar estas ações; Passo 5. Compreender os recursos para execução do plano; Passo 6. Recomeçar a partir do Passo 1. Para a evolução do processo de software é necessário ter uma maneira para medí-lo.

10 Fatores da Qualidade de Software ( McCall)
Manutenibilidade: Posso consertá-lo? Flexibilidade: Posso mudá-lo Testabilidade: Posso testá-lo? Portabilidade: Poderei usá-lo em outra máquina? Reusabilidade: Poderei reutilizá-lo em outra máquina? Interoperabilidade: Poderei compor uma interface com outro sistema?

11 Fatores da Qualidade de Software ( McCall)
Corretitude: Ele faz aquilo que eu quero? Confiabilidade: Ele se comporta com precisão o tempo todo? Eficiência: Ele rodará no meu hardware tão bem quanto possível? Integridade: Ele é seguro? Usabilidade: Ele foi projetado para o usuário?

12 Técnicas de Teste de Software
A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro; Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto; Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.

13 Objetivos da Atividade de Teste
    Projetar testes que descubram sistematicamente diferentes classes de erros e façam-no com uma quantidade de tempo e esforço mínimos. Se a atividade de teste for conduzida com sucesso, ela descobrirá erros no software. A atividade de teste não pode mostrar a ausência de bugs; ela só pode mostrar se defeitos de software estão presentes. Se erros graves forem encontrados com regularidade  a qualidade e a confiabilidade de software são suspeitas. Se erros facilmente corrigíveis forem encontrados  a qualidade e a confiabilidade do software estão aceitáveis ou os testes são inadequados para revelar erros graves. Se não for encontrado erro  a configuração de teste não foi suficientemente elaborada e erros estão escondidos no software.

14 Abordagens de Teste Teste de Caixa Preta Teste de Caixa Branca
Teste de Caminho Básico Caminho Independente Complexidade Ciclomática Teste de Estrutura de Controle Teste de Condição Teste de Fluxo de Dados Teste de Laços

15 Teste de Caixa Preta Concentram-se nos requisitos funcionais do software. O teste de caixa preta procura descobrir erros nas seguintes categorias: 1) funções incorretas ou ausentes 2) erros de interface 3) erros nas estruturas de dados ou no acesso a bancos de dados externos 4) erros de desempenho 5) erros de inicialização e término

16 Teste de Caixa Branca É um método de projeto de casos de teste que usa a estrutura de controle do projeto procedimental para derivar casos de teste. Podem ser derivados casos de teste que: garantam que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez. (2) exercitem todas as decisões lógicas para valores falsos ou verdadeiros. (3) executem todos os laços em suas fronteiras e dentro de seus limites operacionais. (4) exercitem as estruturas de dados internas para garantir a sua validade.

17 Teste de Caminho Básico
O método de caminho básico possibilita que o projetista do caso de teste derive uma medida de complexidade lógica de um projeto procedimental e use essa medida como guia para definir um conjunto básico de caminhos de execução.

18 Verificação e Validação
Verificação: refere-se ao conjunto de atividades que garante que o software implementa corretamente um função específica. “Estamos construindo certo o produto?” Validação: refere-se ao conjunto de atividades que garante que o software que foi construído é “rastreável” às exigências do cliente. “Estamos construindo o produto certo?”

19 Organização para Realização de Teste
Quando o teste se inicia há um conflito de interesses: ·         Desenvolvedores: interesse em demonstrar que o programa é isento de erros. ·         Responsáveis pelos testes: interesse em mostrar que o programa tem erros. Do ponto de vista psicológico: ·    Análise, Projeto e Codificação de Software são tarefas construtivas Teste é tarefa destrutiva

20 Uma Estratégia de Teste de Software
Teste de Unidade: concentra-se em cada unidade do software, de acordo com o que é implementado no código fonte. Teste de Integração: concentra-se no projeto e na construção da arquitetura de software. Teste de Validação: os requisitos estabelecidos como parte da análise de requisitos de software são validados em relação ao software que foi construído. Teste de Sistema: o software e outros elementos do sistema são testados como um todo.

21 Manutenção de Software
Alterações efetuadas no software depois de sua liberação. As alterações ocorrem por diversas razões. As razões para as alterações determinam a categoria de manutenção. Fase mais problemática do Ciclo de Vida de Software Pode despender mais de 70% de todo esforço de uma Organização Esses sistemas devem continuar rodando e as alterações são inevitáveis

22 Manutenção de Software
Por que é exigida tanta Manutenção e por que é despendido tanto Esforço nessa atividade? Idade Média de 10 a 15 anos Quando foram implementados , o tamanho do programa e espaço de armazenamento eram o principal interesse Migração Para Novas Plataformas Sistemas mau estruturados Melhoramentos Para Atender Novas Necessidades Nenhuma preocupação com a Arquitetura Global Codificação, Lógica e Documentação ruins

23 Categorias de Manutenção
Identificar e Corrigir Erros  Manutenção Corretiva Adaptar o Software ao Ambiente  Manutenção Adaptativa Atender Pedidos do Usuário para : Modificar Funções Existentes, Incluir Novas Funções e Efetuar Melhoramentos Gerais Manutenção Perfectiva Melhorar a manutenibilidade ou confiabilidade futuras e fornecer uma base melhor para futuros melhoramentos  Manutenção Preventiva

24 Tarefas da Manutenção Estabelecer uma organização para a manutenção;
Descrever o procedimento de avaliação e comunicação; Definir sequencias padronizadas de eventos ( para os pedidos de manutenção); Estabelecer procedimento para registrar a história das atividades de manutenção; Definir critérios de revisão e avaliação.