Engenharia de Software III

Transcrição

1 Departamento de Informática Programa de Pós Graduação em Ciência da Computação Laboratório de Desenvolvimento Distribuído de Software Estágio de Docência

2 Qualidade de Software

3 O que significa Qualidade de Software? Conformidade aos requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido.

4 O que significa Qualidade de Software? Conformidade do Software aos Requisitos Funcionais e aos Requisitos Não- Funcionais estabelecidos!

5 Qualidade a partir de Diferentes Pontos de Vista O usuário deseja que o produto de software esteja em conformidade com as suas necessidades e seja confiável, eficiente e fácil de ser utilizado. O produtor do software deseja um produto de fácil manutenção, verificação e fácil de ser entendido e adaptado. O gerente deseja que o processo de desenvolvimento seja produtivo e fácil de ser controlado.

6 Atributos de Qualidade de software (ou Requisitos Não- Funcionais) segundo McCall: Manutenibilidade Flexibilidade Capacidade de Teste Revisão do Produto Transição do Produto Portabilidade Reusabilidade Interoperabilidade Operação do Produto Corretitude Usabilidade Eficiência Integridade

7 Atributos de Qualidade Manutenibilidade: o esforço exigido para localizar e reparar erros num programa. Flexibilidade: esforço exigido para modificar um programa operacional. Testabilidade: o esforço exigido para testar um programa a fim de garantir que ele execute a sua função pretendida. Portabilidade: o esforço exigido para transferir um programa de um ambiente de hardware e/ou software para outro.

8 Atributos de Qualidade Reusabilidade: à medida que um programa (ou partes de um programa) pode ser reutilizado em outras aplicações. Interoperabilidade: o esforço exigido para fazer com que dois sistemas ou componentes se comuniquem. Corretitude: à medida que um programa satisfaz a sua especificação e cumpre os objetivos visados pelo cliente. Confiabilidade: a probabilidade de operação livre de falhas de um programa de computador num ambiente específico durante determinado tempo.

9 Atributos de Qualidade Eficiência: a quantidade de recursos de computação e de código exigida para que um programa execute a sua função. Integridade: à medida que o acesso ao software ou a dados por pessoas não-autorizadas pode ser controlado. Usabilidade: o esforço exigido para aprender a operar o software, preparar a entrada e interpretar a saída de um programa.

10 Requisitos Não-Funcionais ISO 9126 Interoperabilidade: Capacidade de interagir com outros sistemas; Segurança de acesso: Capacidade de evitar acesso não autorizado a programas e dados. Características relacionadas a confiabilidade do software: referem-se à capacidade do software manter o seu nível de desempenho, sob condições estabelecidas, por um determinado período de tempo, sendo elas:

11 Requisitos Não-Funcionais ISO 9126 Maturidade: Avalia a freqüência de falhas no software. Tolerância a falhas: Avalia a capacidade de manter o nível de desempenho em casos de falhas. Recuperabilidade: Avalia a capacidade do software em restabelecer e restaurar dados após a falha.

12 Requisitos Não-Funcionais ISO 9126 Características relacionadas a usabilidade do software: referem-se ao esforço necessário ao uso e à homologação individual de tal uso, por um conjunto de usuários estabelecidos ou subentendido. Representada por uma característica Universidade Estadual de MaringCaracterísticas relacionadas a que usabilidade é a: do software: referem-se ao esforço necessário ao uso e à homologação individual de tal uso, por um conjunto de usuários estabelecidos ou subentendido. Representada por uma característica que é a: Operacionalidade: Avalia o esforço do usuário para Operacionalidade: Avalia o esforço do usuário para operar e operar controlar e a controlar operação de a software.á operação - 4º de ano software. de Informática

13 Requisitos Não-Funcionais ISO 9126 Características relacionadas a manutenibilidade do software: Refere-se ao esforço necessário para fazer modificações específicas no software. São elas: Modificabilidade: Avalia o esforço necessário para a modificação e remoção de defeitos; Testabilidade: Avalia o esforço necessário para validar as modificações realizadas.

14 Requisitos Não-Funcionais ISO 9126 Características relacionadas a portabilidade do software: Refere-se à habilidade do software ser transferido de um ambiente para outro. Representada por apenas característica que é a: Adaptabilidade: Avalia a capacidade de adaptação do software em outros ambientes sem exercer ações e procedimentos adicionais e diferentes daqueles previstos originalmente para esta finalidade.

15 Gerenciamento de Qualidade de Software

16 A constante busca pela qualidade e pela satisfação, faz com que os gerentes de projetos se preocupem com a melhor maneira de gerenciar seus produtos.

17 Outro fator de grande relevância é o cliente Mais exigente Busca pela agilidade e qualidade

18 Segundo nos apresenta: CLELAND/IRELAND (2006); alguns fatores que evidenciam problemas nas etapas do projeto são: O projeto excedeu os custos e/ou a programação almejada? O projeto não é adequado à missão, aos objetivos e às metas da empresa? Permitiu-se que o projeto fosse além do ponto em que os resultados seriam necessários para cumprir as expectativas do cliente?

19 Foi feito um desenho errado dos padrões técnicos de desempenho do projeto? A alta administração não deu suporte ao projeto?

20 É de extrema importância que um projeto independente de sua área de atuação, ou linha de pesquisa, possua um planejamento inicial e um gerenciamento contínuo. CAVALIERI/CAMPBELL (2005)

21 Características Sub-características Pergunta chave para a Sub-característica 1.Funcionalidade (Satisfaz as necessidades?) A dequação A curácia Propõe-se a fazer o que é apropriado? Presença das funções especificadas? Faz o que foi proposto de forma correta? O produto gera resultados precisos ou dentro do esperado? Interoperabilidade Interage com os sistemas especificados? Conformidade Segurança de A cesso Está de acordo com as normas, leis, etc? Está de acordo com padrões, convenções ou regras? Evita (ou ao menos previne) acesso não autorizado aos dados?

22 2.C onformidade (é imune a falhas?) M aturidade Tolerância a Falhas R ecuperabilidade C om que freqüência apresenta falhas? O correndo falhas, como ele reage? capacidade do produto para manter determinados níveis de desempenho mesmo na presença de problemas. É capaz de recuperar dados em caso de falha? capacidade do produto para reestabelecer o nível de desempenho desejado e recuperar dados em caso de ocorrência de falha.

23 3.U s a b ilid a d e (é fá c il d e u s a r? ) In te le g ib ilid a d e É fá c il e n te n d e r o c o n c e ito a p lic a ç ã o? A p re e n s ib ilid a d e É fá c il a p r e n d e r a u s a r? O p e ra c io n a lid a d e É fá c il d e o p e ra r e c o n tr o la r?

24 4.Eficiência (é rápido e enxuto?) Tempo Recursos Qual é o tempo de resposta, a velocidade de execução? Medida do tempo de resposta e de processamento ou taxas de processamento (throughput), ao executar a funções prescrita s. Quanto recurso usa? Durante quanto tempo? Medida da quantidade de recursos necessários (CPU, disco e memória, dentre outros) e a duração do seu uso ao executar as funções prescritas.

25 5.Manutenibilidade (é fácil de modificar?) Analisabilidade Modificabilidade Estabilidade Testabilidade É fácil de encontrar uma falha, quando ocorre? Esforço necessário para diagnosticar deficiências ou causas de falhas, ou localizar as partes a serem modificadas para corrigir os problemas É fácil modificar e adaptar? esforço necessário para realizar alterações, remover falhas ou para adequar o produto a eventuais mudanças de ambiente operacional. Há grande risco quando se faz alterações? É fácil testar quando se faz alterações?

26 6.P o rtabilid ad e (é facil d e u sar em o u tro am b ien te?) A d ap tab ilid ad e É fácil ad aptar a o u tro s am b ien tes? C apacid ade p ara ser in staladé ofácil in stalar em outro s am b ien tes? C o n fo rm id ad e E stá de acord o co m p ad rõ es d e p ortabilidad e? C ap acid ad e p ara su b stitu iré fácil usar p ara su b stitu ir o u tro?

27 SQA Software Quality Assurance (Garantia de Qualidade de Software)

28 Garantia de Qualidade de Software De que forma garantir a qualidade de software? 1. Aplicando métodos técnicas e ferramentas ao longo do desenvolvimento; 2. Realizando planejamento de projeto e estimativas; 3. Realizando revisões técnicas formais;

29 Garantia de Qualidade de Software 4. Realizando testes de software através de diferentes e complementares enfoques; 5. Aplicando padrões ao desenvolvimento; 6. Controlando mudanças de software; 7. Realizando medições.

30 Garantia de Qualidade de Software A Garantia de Qualidade de Software envolve um conjunto de atividades aplicadas ao longo de todo o processo de desenvolvimento. A qualidade de um produto é obtida ao longo do seu processo de criação e não imposta após o fato!

31 Aplicando métodos técnicos A qualidade de software é projetada num produto ou sistema. Ela não é imposta após o fato (ou seja, após o software pronto). Por essa razão, a SQA inicia-se de fato com o conjunto de métodos e ferramentas técnicas que ajudam o analista a conseguir uma especificação de elevada qualidade.

32 Revisões técnicas formais Reunião de Revisão: encontro formal onde um modelo é apresentado a técnicos e usuários para comentários e aprovação; Inspeção: avaliação técnica formal onde modelos são examinados em detalhe por um técnico ou grupo (outros que não os desenvolvedores) para detecção de erros, de violação de padrões préestabelecidos e outros problemas.

33 Revisões técnicas formais Walkthrough: reunião formal de revisão préagendada na qual revisores (técnicos) e o produtor do software participam. Concentra-se em um módulo ou parte do software. O produtor caminha através do produto explicando o material (a documentação), enquanto os revisores levantam questões.

34 Revisões técnicas formais Ao final de uma revisão, os participantes devem decidir se: 1. Aceitam o produto sem modificações; 2. Aceitam o produto com pequenas modificações; 3. Não aceitam o produto devido a erros graves localizados. Um relatório de revisão e uma lista das questões a serem revisadas (defeitos) devem ser gerados.

35 Revisões técnicas formais Objetivos: Descobrir erros no software no início do ciclo de vida; Verificar se o software atende aos seus requisitos; Garantir que o software segue padrões; Tornar os projetos mais administráveis; Tornar o projeto conhecido por mais pessoas.

36 Diretrizes de Revisão Revise o produto, não o produtor; Fixe e mantenha uma agenda; Limite o debate; Faça anotações; Reveja antigas revisões; Desenvolva uma checklist para cada produto; Limite o número de participantes e o tempo da reunião.

37 Testes de software Os custos envolvidos associados às falhas de software estimulam a realização de uma atividade de teste cuidadosa e bem planejada. Não é incomum que uma organização gaste 40% do esforço de projeto total em teste.

38 Objetivos da Atividade de Teste 1. A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro. 2. Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto. 3. Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.

39 Controle de Mudanças no Software O gerenciamento de configuração de software é uma atividade aplicada durante todo o processo de engenharia de software. Configuração do software envolve: documentos, programas e estruturas de dados. Mudanças efetuadas num objeto (ou item) de configuração desenvolvido e revisado (ou seja, que conste de uma baseline) resultam na criação de uma nova versão deste objeto.

40 Controle de Mudanças no Software O processo de controle de mudanças inicia-se com um pedido de mudança, leva a uma decisão de aceitar ou rejeitar o pedido de mudança, e culmina com a atualização controlada de um ou mais SCI (Software Configuration Item). Deve ser analisado o impacto da mudança sobre todo o software.

41 Exercício

42 André Dias Martins Bacharel em Ciências Contábeis Bacharel em Sistemas de Informação Especialista em Ciências Econômicas Especialista em Desenvolvimento de Sistemas para Web Especialista em Didática e Metodologia para o Ensino Superior Mestrando em Ciência da Computação (Engenharia Software) andredias.uem@gmail.com