Qualidade

 

a    Qualidade é estar em conformidade com os requisitos dos clientes

a    Qualidade é antecipar e satisfazer os desejos dos clientes

a    Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito

 

 

Qualidade

 

“A totalidade das características de uma

entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas” [NBR ISO 8402]

 

 

A entidade é o produto do qual estamos falando, que pode ser um bem ou um serviço. As necessidades explícitas são as próprias condições e objetivos propostos pelo produtor. As necessidades implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações éticas, as questões de segurança e outras visões subjetivas.

 

   

 

Perspectiva Histórica da Engenharia de Software

 

a    anos 60 - Era Funcional

a    anos 70 - Era do Método

a    anos 80 - Era do Custo

a    anos 90 e depois - Era da Qualidade

 

Qualidade não é um fator de vantagem no mercado, mas é uma necessidade para a garantia da competitividade.

 

 

 

Certificação de Qualidade

 

a    não basta que ela exista, deve ser reconhecida pelo cliente.

 

a    é necessário que exista uma certificação oficial, emitida com base em um padrão.

 

Certificados mais comuns:

 

a    O selo do SIF de inspeção da carne

a    O selo da ABIC nos pacotes de café

a    A classificação em estrelas dos hotéis

a    Os certificados de qualidade da série ISO-9000

 

             Existem alguns organismos normalizadores     

             reconhecidos mundialmente:

 

a    ISO - Internacional Organization for Standardization (http://www.iso.ch/)

a    IEEE - Instituto de Engenharia Elétrica e Eletrônica (http://www.ieee.org/)

a    ABNT - Associação Brasileira de Normas Técnicas (http://www.abnt.org.br/)

 

Porque Qualidade ???

 

Em 2010 a INDÚSTRIA DO SOFTWARE será a maior do mundo em [BET98]:

 

a    volume de negócios

a    quantidade de empresas

a    número de empregos

 

Em 1997 a industria do software se caracterizava por ser [SBP97]:

a    enfocada no cliente

a    estimulada pela internet

a    impulsionada por pesquisa e desenvolvimento

a    carente de talentos humanos

 

Em 1998:

a    satisfação do cliente

a    recrutamento e retenção de empregados agora é uma preocupação

 

 

PBPQ - Programa Brasileiro da  Qualidade e Produtividade

 

Programa criado em 1990 com o objetivo de estabelecer um conjunto ordenado de ações indutoras da modernização industrial e tecnológica contribuindo para a retomada da modernização industrial e tecnológica

a    qualidade de vida

a    qualidade de emprego

a    qualidade e produtividade no setor produtivo

a    qualidade e participação na administração pública

 

 

 

 

 

 

 

Diagnóstico Nacional -
Atividades as empresas no Tratamento de Software

 

Categorias

 

1993

1995

2000

Software pacote

58.73%

42.61%

42.59%

Sob encomenda

42.85%

38.17%

39.08%

Embutido

..

4.12%

5.3 %

Distribuição Terceiros

..

15.24%

13.05 %

 

                       

           

Diagnóstico Nacional -
Profissionais Certificados em Qualidade

Categorias

 

1995

2000

Zero

75.8%

78.1%

1a 2

16.9%

15.4%

3 a 5

4.5%

3.9%

 

6 a 10

0.9%

1.9%

11 a 20

0.7%

0.5%

+ de 20

1.2%

0.2%

 

        

Qualidade do Produto X Qualidade do Processo

 

a    Uma das evoluções mais importantes no estudo

a    da qualidade está em notar que a qualidade do

a    produto é algo bom, mas que qualidade do processo de produção é ainda mais importante.

 

a    Visão que aborda a qualidade do produto.Funcionalidade, confiabilidade, utilizabilidade, eficiência, manutenibilidade e portabilidade (ISO 9126).

 

a    Visão que aborda a qualidade do processo. Dos requisitos do usuário à entrega do produto final, existe um processo de desenvolvimento complexo e

a    dividido em fases, que pode comprometer a qualidade do software.

 

 

Qualidade de Software

 

"Concordância com os Requisitos  Funcionais e de Desempenho  claramente colocados,  Padrões de Desenvolvimento explicitamente documentados e características implícitas que são esperadas de todo software profissionalmente desenvolvido”

 

 

 


A 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: o desejo de boa manutenibilidade). Se o software atende aos requisitos explícitos, mas falha nos requisitos implícitos, a qualidade é suspeita.

 

 

 

Fatores da Qualidade de Software (McCall)   

                                                                                 

                                                           * ISO/IEC 9126:1991 NBR 13596

 

 

1.Manutenibilidade*: Posso consertá-lo?

2. Flexibilidade: Posso mudá-lo

3. Testabilidade: Posso testá-lo?

4. Portabilidade*: Poderei usá-lo em outra máquina?

5. Reusabilidade: Poderei reutilizá-lo em outra máquina?

6. Interoperabilidade: Poderei compor uma interface com outro sistema?

7. Corretitude: Ele faz aquilo que eu quero?

8. Confiabilidade*: Ele se comporta com precisão o tempo todo?

9. Eficiência*: Ele rodará no meu hardware tão bem quanto possível?

10. Integridade: Ele é seguro?

11. Usabilidade*: Ele foi projetado para o usuário?

 

 

 

 

 

Fatores e Métricas de Qualidade (McCall)

 

 Muitos dos Fatores de Qualidade  só podem ser medidos subjetivamente. Mas pode-se definir medidas dos Fatores de Qualidade da seguinte maneira:

Fq = c1 x m1 + c2 x m2 +  ... + cn x mn

Fq : um fator de Qualidade de Software

cn  : coeficientes de regressão

mn  : métricas de características que afetam o Fator de Qualidade

 

 

 

Fatores e Métricas de Qualidade (McCall)

 

- Concisão: a compactação do programa em termos de linhas de código.

- Consistência: o uso de técnicas de projeto e documentação uniformes ao longo do projeto de desenvolvimento de software

- Instrumentação: o quanto o programa monitora sua própria operação e identifica erros que venham a ocorrer.

- Modularidade: a independência funcional dos componentes do programa.

- Autodocumentação: o quanto o código fonte apresenta documentação significativa

- Simplicidade: o quanto um programa pode ser entendido sem dificuldade.

 

 

Qualidade do Produto


 

 

 

 

 

 

 

 

 

 

 

Qualidade do Produto ISO 9126

 

 

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Qualidade do Produto ISO 9126 no Brasil

 

 

a    7,3 % Conhece a norma e usa

a    19,2% Conhece mas não usa

a    73,5% Não conhece

 

Qualidade do Produto ISO 14598

 

Descreve, detalhadamente, todos os passos para que se avalie um software. Leva em consideração 3 grupos de avaliadores:


 

 

!    Esta norma se constituirá, na verdade, de seis documentos distintos, relacionados entre si.

Norma

Nome

Finalidade

14598-1

Visão Geral

Ensina a utilizar as outras normas do grupo

14598-2

Planejamento e Gerenciamento

Sobre como fazer uma avaliação, de forma geral

14598-3

Guia para Desenvolvedores

Como avaliar sob o ponto do vista de quem desenvolve

14598-4

Guia para Aquisição

Como avaliar sob o ponto de vista de quem vai adquirir

14598-5

Guia para Avaliação

Como avaliar sob o ponto de vista de quem certifica

14598-6

Módulos de Avaliação

Detalhes sobre como avaliar cada característica

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Em resumo, esta nova norma complementará a ISO/IEC 9126 e permitirá uma avaliação padronizada das características de qualidade de um software. É importante notar que, ao contrário da 9126, a 14598 vai a detalhes mínimos, incluindo modelos para relatórios de avaliação, técnicas para medição das características, documentos necessários para avaliação e fases da avaliação. Como um exemplo, observe um modelo de relatório de avaliação, segundo um anexo da norma 14598-5:

 

Seção

Itens

1 - Prefácio

Identificação do avaliador
Identificação do relatório de avaliação
Identificação do contratante e fornecedor

2 - Requisitos

Descrição geral do domínio de aplicação do produto
Descrição geral dos objetivos do produto
Lista dos requisitos de qualidade, incluindo
- Informações do produto a serem avaliadas
- Referências às características de qualidade
- Níveis de avaliação

3 - Especificação

Abrangência da avaliação
Referência cruzada entre os requisitos de avaliação e os componentes do produto
Especificação das medições e dos pontos de verificação
Mapeamento entre a especificação das medições com os requisitos de avaliação

4 - Métodos

Métodos e componentes nos quais o método será aplicado

5 - Resultado

Resultados da avaliação propriamente ditos
Resultados intermediários e decisões de interpretação
Referência às ferramentas utilizadas

 

 

Qualidade do Produto ISO 12119

 

 

 

Trata da avaliação de pacotes de software, também conhecidos como "software de prateleira". Além de estabelecer os requisitos de qualidade para este tipo de software, ela também destaca a necessidade de instruções para teste deste pacote, considerando estes requisitos

 

Item

Descrição

1. Escopo

2. Definições

3. Requisitos de qualidade

3.1. Descrição do Produto

Descreve o produto, de forma a ajudar o comprador em potencial, servindo como base para testes. Cada declaração deve ser correta e testável. Deve incluir declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

3.2. Documentação do usuário

Deve ser completa, correta, consistente, fácil de entender e capaz de dar uma visão geral do produto.

3.3. Programas e dados

Descreve em detalhes cada uma das funções do software, incluindo declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

Item

Descrição

4. Instruções para teste

4.1. Pré-requisitos de teste

Lista de itens necessários ao teste, incluindo documentos incluídos no pacote, componentes do sistema e material de treinamento.

4.2. Atividades de teste

Instruções detalhadas sobre os procedimentos de teste, inclusive instalação e execução de cada uma das funções descritas.

4.3. Registro de teste

Informações sobre como os testes foram realizados, de tal forma a permitir uma reprodução destes testes. Deve incluir parâmetros utilizados, resultados associados, falhas ocorridas e até a identidade do pessoal envolvido.

4.4. Relatório de teste

Relatório inlcuindo: identificação do produto, hardware e software utilizado, documentos utilizados, resultados dos testes, lista de não conformidade com os requisitos, lista de não conformidade com as recomendações, datas, etc.

 

 

 

 

Garantia da Qualidade de Produto de Software (SQA)

 

Software Quality Assurance: padrão sistemático e planejado de ações que são exigidas para garantir a qualidade de software. 

 

Essas ações englobam:

1) Aplicação de Métodos Técnicos: ajudam o analista a conseguir uma especificação de elevada qualidade e o projetista a desenvolver um projeto de elevada qualidade.

2) Realização de Revisões Técnicas Formais: para avaliar a qualidade da especificação e do projeto.

3) Atividades de Teste de Software: para ajudar a garantir uma detecção de erros efetiva.

4) Aplicação de Padrões e Procedimentos Formais  no processo de engenharia de software.

5) Processo de Controle de Mudanças: atividade que faz parte do gerenciamento de configuração de software.

6) Mecanismos de Medição: para ser possível rastrear a qualidade de software

7) Anotação e Manutenção de Registros: procedimentos para a coleta e disseminação de informações de garantia de qualidade de software.

 

 

Revisões do Software

 

Meio efetivo para melhorar a Qualidade de Software

 

As Revisões devem ser aplicadas em vários pontos durante o desenvolvimento do software

 

 Revisão é uma maneira de usar a diversidade de um grupo de pessoas para:

 

a    apontar melhorias necessárias ao produto

a    confirmar as partes de um produto em que uma melhoria não é desejada ou não é necessária.

a    realizar um trabalho técnico com uma qualidade mais uniforme de forma a tornar este trabalho técnico mais administrável.

 

TIPOS DE REVISÃO :

 

a    Discussão de um problema  técnico na hora do café

a    Apresentação do projeto de software para uma audiência de clientes, administradores e pessoal técnico

a    Revisões Técnicas Formais:  inclui avaliações técnicas de software realizadas em pequenos grupos (walkthrough).

 

Revisões Técnicas Formais

 

  Objetivos:

 

1) Descobrir erros de função,  lógica ou implementação em qualquer representação do software.

2) Verificar se o software que se encontra em revisão atende a seus requisitos

3) Garantir que o software tenha sido representado de acordo com  padrões pré-definidos

4) Obter um software que seja desenvolvido uniformemente

5) Tornar os  projetos mais  administráveis

           

 

 

 

Além disso:

 

-  espaço de  treinamento possibilitando que os engenheiros juniores observem diferentes abordagens a análise, projeto e implementação de software

 

  - promove backup e continuidade. Várias  pessoas    se familiarizam com partes do software que de outro modo poderiam não conhecer.

 

 Reunião da Revisão de Software

 

Uma  Revisão Técnica Formal  é conduzida  em uma reunião  e será bem sucedida se for planejada, controlada e cuidada.

 

Independentemente do formato de Revisão Técnica, toda Reunião de Revisão deve estar de acordo com:

 

1) Envolver  de 3 a 5 pessoas na revisão

2) Deve haver uma preparação para a reunião (essa preparação   não deve exigir mais de 2 horas de trabalho de cada pessoa)

3) A Reunião de Revisão deve durar menos de 2 horas

 

A Revisão Técnica Formal focaliza uma parte específica (pequena) do software - maior probabilidade de descobrir erros.

 

Diretrizes de Revisão

 

Devem ser estabelecidas antecipadamente, distribuídas a todos os revisores, ter a concordância de todos e então encaminhada.

 

Conjunto mínimo de diretrizes para as revisões técnicas formais:

 

1) Revise o produto, não o produtor.

2) Fixe e mantenha uma agenda

3) Limite o debate e a refutação

4) Enuncie as áreas problemáticas, mas não tente resolver cada problema anotado.

Diretrizes de Revisão

5)  Faça anotações por escrito.

6)  Limite o número de participantes e

insista numa preparação antecipada.

7)  Desenvolva uma lista de conferência (checklist) para cada produto que provavelmente será revisto.

8)  Atribua recursos e uma programação de tempo para as Revisões Técnicas Formais

9)  Realize um treinamento significativo para todos os revisores.

10) Reveja suas antigas revisões.