Qualidade

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 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õesespecificados 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ícitosque 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çãoa um padrão mínimo exigido; • condição de atendimento duranteo 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ível Estratégico Alta gerência O que? PQ Como? Nível TáticoMédia Gerência MQ Nível operacional Supervisores, Técnicos e Operadores PO IT - EP - D RQ Em todos os níveis Níveis Estruturais de um Sistema de Qualidade

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.