1 qualidade de software aline vasconcelos cefet campos aline.vasconcelos@terra.com.br

1

Qualidade de SoftwareQualidade de Software

Aline Vasconcelos

CEFET Campos

aline.vasconcelos@terra.com.br

2

O que significa Qualidade de Software?

• “Conformidade a 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.”

3

O que significa Qualidade de Software?

• Conformidade do Software aos

Requisitos FuncionaisRequisitos Funcionais e aos Requisitos Requisitos

Não-FuncionaisNão-Funcionais estabelecidos!!!!!!

4

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 estendido e adaptado.

• O gerente deseja que o processo de desenvolvimento seja produtivo e fácil de ser controlado.

5

Atributos de Qualidade de Software

• Atributos de Qualidade de software (ou Requisitos Não-Funcionais) segundo McCall:

Revisão do Produto

Transição doProduto

Operação do Produto

Manutenibilidade

Flexibilidade

Capacidade de Teste

Portabilidade

Reusabilidade

Interoperabilidade

Corretitude Eficiência

Usabilidade Integridade

6

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.

7

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.

8

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.

9

Medição dos Atributos de Qualidade

• Representam, em sua maioria, medidas indiretas do software.

• Medidas diretas (ou métricas de software) ajudam a indicar a adequação do sistema aos atributos de qualidade, como:– Complexidade Ciclomática de McCabe,

– Coesão e Acoplamento,

– etc.

10

Medindo a Confiabilidade do Software

• A confiabilidade do software, ao contrário de muitos outros fatores de qualidade, pode ser medida diretamente e estimada com base em dados históricos e de desenvolvimento.

• Uma medida simples da confiabilidade é o tempo médio entre falhas:

– MTBF = MTTF + MTTR

– Onde: MTBF – Mean Time Between Failures; MTTF – Mean Time to Failure; MTTR – Mean Time to Repair

11

Requisitos Não-FuncionaisDescrição das características e subcaracterísticas de qualidade utilizadas

(ISO/IEC 9126-1)

• Características relacionadas a funcionalidade do software : referem-se à existência de um conjunto de funções que satisfaz necessidades explícitas ou implícitas e suas propriedades específicas, para a finalidade a que se destina o produto. São elas:

– 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. São elas:

– 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

• 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 que é a:

– Operacionalidade: Avalia o esforço do usuário para operar e controlar a operação de software.

 • Características relacionadas a eficiência do software: Refere-se ao relacionamento entre o nível

de desempenho do software e a quantidade de recursos utilizada, sob condições estabelecidas. São elas:

– Comportamento em relação ao tempo: Avalia o tempo de resposta, o tempo de processamento e as taxas de “troughput” durante a execução do software.

– Comportamento em relação aos recursos: Avalia a quantidade de recursos utilizada e a duração desta utilização durante a execução do software.

– Throughput: representa o volume de trabalho que um computador pode realizar em um dado período de tempo. (Tanenbaum)

13

Requisitos Não-Funcionais

• 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.

• 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.

14

SQA SQA Software Quality Assurance Software Quality Assurance

(Garantia de Qualidade de Software)(Garantia de Qualidade de Software)

15

Garantia de Qualidade de Software • De que forma garantir a qualidade de software

(SQA - Software Quality Assurance):

• 1. Aplicando métodos técnicos e ferramentas ao longo do desenvolvimento;

• 2. Realizando planejamento de projeto e estimativas;

• 3. Realizando revisões técnicas formais;

16

Garantia de Qualidade de Software

• Atividades para SQA (continuação):

• 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.

17

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”!

18

1. 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.

19

3. Revisões técnicas formais(FTR - Formal Technical Reviews)• 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.

20

3. Revisões técnicas formais(FTR - Formal Technical Reviews)

• 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.

21

3. Revisões técnicas formais(FTR - Formal Technical Reviews)

• 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.

22

3. Revisões técnicas formais(FTR - Formal Technical Reviews)• 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.

23

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.

24

4. 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.

25

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.

26

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.

27

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.