cesar/di-ufpe1 © 1998, alexandre vasconcelos introdução à qualidade de software alexandre m....

CESAR/DI-UFPECESAR/DI-UFPE 11©© 1998, Alexandre Vasconcelos 1998, Alexandre Vasconcelos

Introdução à Qualidade de SoftwareIntrodução à Qualidade de Software

Alexandre M. Lins de VasconcelosDepartamento de Informática - UFPE

[email protected] 2718430


MotivaçãoMotivação

O principal objetivo da Engenharia de Software (ES) é ajudar a produzir software de qualidade;

Empresas que desenvolvem software de qualidade são mais competitivas;

Empresas que utilizam software de alta qualidade podem, em geral, oferecer um melhor serviço a um preço mais competitivo.


Conceitos de QualidadeConceitos de Qualidade

Definição genérica: “Propriedade, atributo ou condição das coisas ou das pessoas

capaz de distingui-las das outras e de lhes determinar a natureza” (Aurélio).

Outras definições: Qualidade é estar em conformidade com os requisitos dos

clientes; Qualidade é antecipar e satisfazer os desejos dos clientes; Qualidade é escrever tudo o que se deve fazer e fazer tudo o que

foi escrito.


Conceitos de QualidadeConceitos de Qualidade

Segundo a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade é: A totalidade das características de uma entidade que lhe confere

a capacidade de satisfazer as necessidades explícitas e implícitas.


Conceito de Qualidade de SoftwareConceito de 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” (Pressman).


Fatores de Qualidade de SoftwareFatores de Qualidade de Software

A noção de qualidade de software pode ser descrita por um grupo de fatores, requisitos ou atributos, tais como: confiabilidade, eficiência, facilidade de uso, modularidade, legibilidade, etc;

Podemos classificar estes fatores em dois tipos principais: externos e internos;

Fatores InternosFatores Externos


Fatores de Qualidade de SoftwareFatores de Qualidade de Software

Fatores externos são percebidos tanto pelas pessoas que desenvolvem software quanto pelos usuários. Por exemplo, confiabilidade, eficiência e facilidade de uso são fatores externos;

Fatores internos são percebidos apenas pelas pessoas que desenvolvem software. Por exemplo, modularidade e legibilidade são fatores internos;

Se os fatores internos forem observados, os fatores externos serão consequentemente observados. De fato, os fatores internos são um meio para se alcançar os fatores externos.


Fatores Externos de Qualidade de SoftwareFatores Externos de Qualidade de Software

software

correção

robustez

integridade

eficiência

portabilidade

facilidade de uso



Facilidade de uso: a facilidade de aprender como usar o software;

Eficiência: o bom uso dos recursos computacionais; Portabilidade: a facilidade de transferir software entre

ambientes operacionais.



Correção: habilidade do software executar suas tarefas exatamente como definida pelos requisitos e especificação;

Robustez: habilidade de um software funcionar mesmo em condições anormais;

Integridade: a habilidade do sistema de proteger seus vários componentes contra acessos ou modificações indevidos.


Processos de EngenhariaProcessos de Engenharia Especificação - define os requisitos e limitações do

sistema Projeto - Produz um modelo do sistema Manufatura - construção do sistema Teste - verifica se o sistema satisfaz a

especificação Instalação - entrega o sistema ao usuário e garante

sua operacionalidade Manutenção - repara falhas no sistema quando elas

são descobertas


O Processo de SoftwareO Processo de Software

Um conjunto estruturado de atividades necessárias para o desenvolvimento de um sistema de software

• Especificação• Projeto• Implementação• Validação• Evolução

As atividades variam de acordo com a organização e o tipo de sistema sendo desenvolvido


Características do ProcessoCaracterísticas do Processo

Facilidade de Entendimento• O processo está definido e bem entendido?

Visibilidade• O progresso do processo está externamente visível?

Suportabilidade• O processo pode ser apoiado por ferramentas CASE?

Aceitabilidade• O processo é aceito pelas pessoas envolvidas nele?


Qualidade do processo e qualidade do produto estão intimamente relacionados;

Um bom processo é normalmente necessário para produzir um bom produto;

Para produtos manufaturados, o processo é o principal determinante de qualidade;

Para projetos, outros fatores também são importantes.

Processos e Qualidade do ProdutoProcessos e Qualidade do Produto


Dimensões da Qualidade do SoftwareDimensões da Qualidade do Software

Productquality

Developmenttechnology

Cost, time andschedule

Processquality

Peoplequality


Estude um processo existente para entender suas atividades

Produza um modelo abstrato do processo. Normalmente representado graficamente. Várias visões diferentes (ex. atividades, deliverables, etc.) podem ser necessárias

Analise o modelo para descobrir problemas do processo. Envolve discutir atividades com as partes interessadas

Análise e Modelagem do ProcessoAnálise e Modelagem do Processo


Modelos de processos públicos e processos padronizados É sempre melhor começar o processo de análise com um modelo

existente. As pessoas então poderão estender e mudá-lo. Questionários e entrevistas

Devem ser cuidadosamente projetadas. Participantes podem contar o que eles acham que você quer ouvir.

Análise Etnográfica Envolve a assimilação do conhecimento do processo através da

observação

Técnicas de Análise do ProcessoTécnicas de Análise do Processo


Atividades Tem um objetivo claramente definido, condições de entrada e

saída. Normalmente executadas por uma única pessoa. Processos

Conjunto de atividades com alguma coerência e um objetivo bem definido.

Deliverables (entrega) Saída tangível de uma atividade. Usualmente um documento.

Condições Predicado que deve valer antes ou depois de um processo ou

atividade.

Elementos do Processo de SoftwareElementos do Processo de Software


Papéis Uma área limitada de responsabilidade. Exemplos: gerente de

configuração, engenheiro de teste, etc. Exceções

Um evento que requer um tratamento especial e que não é tratado por atividades normais. Usualmente tratadas quando surgem sem uma estratégia prévia.

Comunicação Um troca de informação entre pessoas ou pessoas e

computadores

Elementos do Processo de SoftwareElementos do Processo de Software


Informal Não há um modelo detalhado do processo. O time de

desenvolvimento escolhe sua própria forma de trabalhar Gerenciado

Processos são definidos e guiam o desenvolvimento Metódico

Processos são definidos por algum método de desenvolvimento (OMT, Booch, etc)

Suportado Processo suportado por alguma ferramenta CASE

Classificação do ProcessoClassificação do Processo


Aplicabilidade do ProcessoAplicabilidade do Processo

PrototypesShort-lifetime products4GL business systems

Informalprocess

Large systemsLong-lifetime products

Managedprocess

Well-understoodapplication domains

Re-engineered systems

Methodicalprocess


O processo a ser usado depende do tipo de produto em desenvolvimento Para grandes sistemas, o gerenciamento é geralmente o principal

problema. Portanto, você precisará de um processo gerenciado. Para projetos menores, uma informalidade será possível;

Não existe um processo uniforme que possa ser padronizado em qualquer organização;

Você poderá ter altos custos se forçar um processo não apropriado num time de desenvolvimento.

Escolha do ProcessoEscolha do Processo


Ferramentas de suporte a processosFerramentas de suporte a processos

Informalprocess

Managedprocess

Methodicalprocess

Improvingprocess

Specializedtools

Analysis anddesign

workbenches

Projectmanagement

tools

Configurationmanagement

tools

Generictools


Melhoria do ProcessoMelhoria do Processo

Os estudos sobre qualidade estão na sua maioria voltados para o melhoramento do processo de desenvolvimento;

Ao melhorar a qualidade do processo está se dando um grande passo para se garantir também a qualidade do produto.


Entender o processo existente Introduzir mudanças de processo para alcançar objetivos

organizacionais, que são associados à melhoria da qualidade, redução de custos e aceleração de prazos

A maior parte do trabalho de melhoria de processo até o momento tem abordado a redução de defeitos. Reflete a atenção cada vez maior da indústria para a questão da qualidade

Objetivos da Melhoria do ProcessoObjetivos da Melhoria do Processo


Análise do Processo Modele e analise (quantitativamente se possível) os processos

existentes. Métricas são necessárias. Identificação de Melhorias

Identifique os gargalos de qualidade, custo e escalonamento Introdução das Mudanças de Processo

Modifique o processo para remover os gargalos identificados Treinamento na Mudança do Processo

Treine a equipe envolvida com os novos processos propostos Ajuste da Mudança

Evolua e melhore os processos revisados

Estágios da Melhoria do ProcessoEstágios da Melhoria do Processo


Estágios da Melhoria do ProcessoEstágios da Melhoria do Processo

Processmodel

Process changeplan

Trainingplan

Feedback onimprovements

Revised processmodel

Analyseprocess

Identifyimprovements

Tuneprocess changes

Introduceprocess change

Trainengineers


Quando for possível, dados quantitativos do processo devem ser coletados Contudo, quando as organizações não têm processos

padronizados bem definidos isto pode ser difícil, pois você não saberá o que medir. Um processo precisa ser definido antes de qualquer medição ser possível

Medições do processo devem ser usadas para avaliar a melhoria do processo

Mas isto não implica que as medições devem guiar as melhorias. Os objetivos organizacionais devem guiar as melhorias.

Medindo o ProcessoMedindo o Processo


Objetivos das MétricasObjetivos das Métricas

Independentemente da métrica usada, sempre se busca os mesmos objetivos Melhorar o entendimento da qualidade do produto; Atestar a efetividade do processo; Melhorar a qualidade do trabalho realizado a nível de projeto.


Tempo que se leva para completar as atividades do processo Ex. Tempo do calendário ou esforço para completar uma

atividade ou processo Recursos necessários para os processos ou atividades

Ex. Esforço total em pessoa-dias, custo de viagens, recursos computacionais

Número de ocorrências de um determinado evento Ex. Número de defeitos descobertos

Classes de Medições de ProcessosClasses de Medições de Processos


Objetivos - Goals O que a organização quer alcançar? O objetivo da melhoria do

processo é satisfazer estes objetivos Questões

Questões a respeito das áreas de incerteza relacionadas com os objetivos. Como poderemos reduzir o tempo de produção de requisitos?Como diminuir o número de linhas de código com defeitos?

Métricas Medições para coletar as respostas às perguntas

Paragima GQM (Goal-Question-Metric)Paragima GQM (Goal-Question-Metric)


Controle e Garantia de QualidadeControle e Garantia de Qualidade

Gerentes querem os melhores projetistas para projetar o produto, mas em geral não podem tê-los;

Não existe técnica que possibilite o desenvolvimento de software isento de defeitos;

Controle de Qualidade evita que produtos defeituosos sejam entregues aos clientes (relaciona-se à validação);

Garantia da Qualidade tenta produzir software com uma baixa taxa de defeitos (relaciona-se à verificação);

Existe então a necessidade de concentrar esforços em métodos de SQA (Software Quality Assurance);

O papel de SQA é monitorar os métodos e padrões que os engenheiros de software usam.


Atividades de SQAAtividades de SQA

Em SQA temos uma variedade de tarefas, as quais podemos dividir em dois grandes grupos: Engenheiros de software: fazem o desenvolvimento dos sistemas

(trabalho técnico); Grupo de SQA: responsabilidades sobre o plano de qualidade,

inspeção, conservação de registros históricos, análise do produto desenvolvido e reporting das atividades de SQA ao gerente do projeto.


Atividades de SQAAtividades de SQA

O SEI (Software Engineering Institute) recomenda as seguintes atividades para o grupo de SQA Preparar uma plano de SQA; Participar da descrição do projeto de software; Revisar as atividades dos engenheiros de software; Documentar e consertar os desvios; Registrar discordâncias e reportar para o gerente; Gerenciar mudanças e métricas de software.


Atividades de SQA:Atividades de SQA:revisões de softwarerevisões de software

São um filtro no processo de ES; Não são limitadas à especificação, projeto e código. Defeito: anomalia do produto (IEEE); Revisões Técnicas Formais (RTF): destinam-se a

encontrar erros durante o processo antes que eles se tornem defeitos;

50% a 60% do total de erros são introduzidos durante o projeto de software;

RTF podem descobrir cerca de 75% desses erros.


Atividades de SQA: Atividades de SQA: medidas de produtividade de programaçãomedidas de produtividade de programação

A qualidade do software depende da produtividade de programação, a qual é afetada por: qualidade da documentação; linguagem de programação; disponibilidade de ferramentas; experiência do programador; comunicação no projeto; grau de dependência entre módulos; práticas de programação bem definidas.


Atividades de SQA:Atividades de SQA:medidas de confiabilidademedidas de confiabilidade

“Probabilidade de uma operação de programa de computador ser livre de falha”.

É um elemento importante para a qualidade do software; Exemplo: um software que opera corretamente em 96 das

suas 100 execuções, tem uma confiabilidade de 0.96.

não conformidade com osrequisitos de software


Confiabilidade x SegurançaConfiabilidade x Segurança

Confiabilidade usa a análise estatística para determinar a probabilidade de que

uma falha venha a ocorrer. Segurança

examina as maneiras segundo as quais as falhas resultam em condições que podem levar a uma deformação.


Plano de SQAPlano de SQA

Especifica os objetivos, as tarefas de SQA a serem realizadas, os padrões, os procedimentos a estrutura organizacional e os mecanismos de auditoria;

Documentos de ES exigidos: Especificação de Requisitos, Descrição de Projeto, Plano (e Relatório) de Verificação e Validação, Documentação do Usuário.


Certificação de QualidadeCertificação de Qualidade

Não basta que a qualidade exista, ela deve ser reconhecida pelo cliente;

Deve existir uma certificação oficial emitida com base em um padrão;

As certificações são dadas por instituições competentes; Exemplos de certificação:

Selo SIF de qualidade de produtos alimentícios; Selo ABIC de qualidade do café; Classificação da rede hoteleira.


Certificação do Produto ou do Processo?Certificação do Produto ou do Processo?

Hoje em dia, a qualidade do processo é mais importante do que a qualidade final do produto;

Existem normas e padrões tanto para produtos quanto para processos.


Padrões de Qualidade de SoftwarePadrões de Qualidade de Software

Qualidade de produtos de software - ISO 9126 (versão brasileira - NBR 13596);

Qualidade de pacotes de software - ISO 12119; Qualidade do processo de software

ISO 9000 / ISO 9001 Capability Maturity Model (CMM)

Outros padrões para qualidade de processo Personal Software Process (PSP) SPICE


Qualidade de produtos de software - Qualidade de produtos de software - ISO 9126ISO 9126

Conjunto de características que devem estar presentes em um software de qualidade: Funcionalidade - satisfaz as necessidades? Confiabilidade - é imune a falhas? Usabilidade - é fácil de usar? Eficiência - é rápido e “enxuto”? Manutenibilidade - é fácil de modificar? Portabilidade - é fácil de usar em outro ambiente?

Muitas destas características são subjetivas; Outras podem ser definidas por meio de métricas.


Qualidade de pacotes de software - Qualidade de pacotes de software - ISO 12119ISO 12119

Trata da avaliação de “software de prateleira”; Descreve detalhes que devem estar presentes no

software, tais como: Documentação do usuário de fácil compreensão; Um sumário e um índice remissivo na documentação do usuário; Presença de um manual de instalação com instruções detalhadas; Possibilidade de verificar se uma instalação foi bem sucedida; Especificação de valores limites para os dados de entrada; etc.


Qualidade do processo de software - Qualidade do processo de software - Capability Maturity Model (CMM)Capability Maturity Model (CMM)

Descreve princípios e práticas relacionadas à maturidade do processo de software;

Tem o objetivo de ajudar as organizações a melhorarem seus processos de software em termos de um caminho evolutivo que vai de ad hoc (processos caóticos) a processos maduros e disciplinados;

Para isto define o conceito de nível de maturidade: base evolucionária bem definida direcionada a obter um processo de software maduro.


Organizações maduras Organizações imaturas

Papéis e responsabilidades bem Processo improvisado definidos Existe base histórica Não existe base histórica

É possível julgar a qualidade do Não há maneira objetiva de julgar produto qualidade do produto

A qualidade dos produtos e Qualidade e funcionalidade do processos é monitorada produto podem ser sacrificadas O processo pode ser atualizado Não há rigor no processo a ser seguido Existe comunicação entre o gerente e seu grupo Resolução de crises imediatas

MaturidadeMaturidade


Componentes do CMMComponentes do CMM

Níveis de Maturidade Áreas-chave de processo Características comuns Práticas-chave


Os 5 Níveis de MaturidadeOs 5 Níveis de Maturidade

Inicial Processo caótico e ad hoc. O gerenciamento épensado” durante o desenvolvimento.

ReproduzívelProcessos estabelecidos por experiênciasanteriores.

DefinidoProcessos padronizados, documentados eintegrados.

GerenciadoMedidas de qualidade são coletadas. O processoe o produto são entendidos e controlados quantitativamente.

OtimizadoUm processo de melhora contínuo é capacitadop/retorno quantitativo do processo e das idéias.


Inicial Essencialmente não controlado. Resultado imprevisível.

Reproduzível Procedimentos definidos e usados para gerenciamento de Produto

Definido Procedimentos e estratégias definidas e usadas para

gerenciamento de Processo Gerenciado

Estratégias definidas e usadas para Gerenciamento de Qualidade Otimizado

Estratégias definidas e usadas para Melhoria do Processo

Níveis no Modelo de MaturidadeNíveis no Modelo de Maturidade


Nível 1: InicialNível 1: Inicial

Foco : pessoas competentes e heróis

O processo de desenvolvimento é desorganizado e atécaótico. Poucos processos são definidos e o sucessodepende de esforços individuais e heróicos.


Nível 2: RepetívelNível 2: Repetível

Foco: Processos de gerenciamento de projetos

Os processos básicos de gerenciamento de projeto estão estabelecidos e permitem

acompanhar custo, cronograma e funcionalidade. É possível repetir o sucesso de um processo utilizado anteriormente em outros projetos similares.


Nível 3: DefinidoNível 3: Definido

Foco: Processos de engenharia e apoio

Tanto as atividades de gerenciamento quanto de engenharia do processo de desenvolvimento de software estão documentadas, padronizadas e integradas em um padrão de desenvolvimento da organização. Todos os projetos utilizam uma versão aprovada e adaptada do processo padrão de desenvolvimento de software da organização.


Nível 4: GerenciadoNível 4: Gerenciado

Foco: Qualidade do Produto e do Processo

São coletadas medidas detalhadas da qualidade do produto e processo de desenvolvimento de software. Tanto o produto quanto o processo de desenvolvimento de software são entendidos e controlados quantitativamente.


Nível 5: OtimizadoNível 5: Otimizado

Foco: Melhoramento contínuo do Processo

O melhoramento contínuo do processo é conseguido através de um “feedback” quantitativo dos processos e pelo uso pioneiro de idéias e técnicas inovadoras.


Áreas-chave de processo (KPA’s)Áreas-chave de processo (KPA’s)

Indicam as áreas que uma organização deve enfocar para melhorar seu processo de software;

O CMM define 18 KPA’s distribuídas nos 5 níveis; Cada KPA é descrita em termos de práticas-chave que

contribuem para satisfazer seus objetivos. descrevem a infra-estrutura e atividades que contribuem para a

implementação e institucionalização da KPA.


Áreas-chave de processoÁreas-chave de processo

KPA 1: não existem KPA’s para este nível; KPA 2: interesses relacionados ao estabelecimento do

controle básico de administração de projeto; KPA 3: problemas organizacionais e de projeto; KPA 4: estabelecem um entendimento quantitativo do

processo de software e do produto; KPA 5: cobrem os problemas que a organização e os

projetos devem endereçar para implementar uma melhora contínua e mensurável do processo de software.


Áreas-chave de processo do Nível 2 - Áreas-chave de processo do Nível 2 - RepetívelRepetível

Repetível (2)

Gerenciamento da Configuração de Software Garantia da Qualidade de Software Gerenciamento de Subcontrato de Software Acompanhamento de Projeto de Software Planejamento de Projeto de SoftwareGerenciamento de Requisitos


Definido (3)

Revisões (peer review) Coordenação Intergrupos Engenharia de Produto de Software Gerenciamento de Software Integrado Programa de Treinamento Definição do Processo da OrganizaçãoFoco no Processo da Organização

Áreas-chave de processo do Nível 3 - Áreas-chave de processo do Nível 3 - DefinidoDefinido


Gerenciado (4)

Gerenciamento da Qualidade de Software Gerenciamento Quantitativo do Processo

Áreas-chave de processo do Nível 4 - Áreas-chave de processo do Nível 4 - GerenciadoGerenciado


Otimizado (5)

Gerenciamento da Mudança no Processo Gerenciamento da Mudança Tecnológica Prevenção de Defeito

Áreas-chave de processo do Nível 5 - Áreas-chave de processo do Nível 5 - OtimizadoOtimizado


Características ComunsCaracterísticas Comuns

Compromisso a realizar Capacidade de realizar Atividades realizadas Medições e análise Verificação da implementação

As características comuns são itens a serem observados para que sepossa verificar a implementação e institucionalização de cada área-chavede processo.

Cada característica comum possui práticas-chave a serem realizadas.


A ênfase é no gerenciamento do projeto e não no desenvolvimento do produto.

Não incorpora a análise de risco como uma área crítica do processo.

Não define o seu domínio de aplicabilidade Dificuldade para implantação em pequenas empresas

Críticas ao Modelo CMMCríticas ao Modelo CMM


Curiosidades sobre o CMMCuriosidades sobre o CMM

Só existem atualmente cinco empresas no mundo no nível 5: BOEING; Loral Systems (IBM); Unidade da Motorolla (Índia); Base de Eduards (USAF); Lock Hit (empresa de aviação).

No Brasil temos: Nível 2: NEC, ERICSON, CITIBANK; Nível 3: XEROX; Equitel/Siemens: implantou nível 2 ou 3, mas não se certificou.


Comparação entre ISO 9001 e CMMComparação entre ISO 9001 e CMM

CMM Ênfase no contínuo

processo de melhora;

Enfoca estritamente o software;

Não é uma norma emitida por uma instituição de padronização.

ISO 9001 Ênfase no critério mínimo

para um sistema de qualidade aceitável;

Tem um escopo mais abrangente;

Por ser mais conhecido e embutir um padrão internacional mínimo de qualidade, o ISO talvez traga melhores resultados para a empresa.


Comparação entre ISO 9001 e CMM -Comparação entre ISO 9001 e CMM -perguntasperguntas

Em que nível do CMM poderia se encaixar uma organização em conformidade com o ISO 9001? A ISO 9001 atende boa parte das KPA’s do nível 2 e algumas do nível 3.

Uma organização de nível 2 (ou 3) poderia ser considerada em conformidade com o ISO 9001? Provavelmente.

Meus esforços na melhoria do processo e no gerenciamento de qualidade deveriam ser baseados no ISO 9001 ou no CMM?

Estas perguntas não têm uma resposta definitiva.


O processo de software consiste naquelas atividades envolvidas no desenvolvimento de software

Modelos de processo incluem a descrição de tarefas, atividades, papéis, comunicações, deliverables e outros processos

Processos podem ser classificados com informal, gerenciado, metódico e de melhoria.

Melhoria de processo envolve análise do processo, padronização, medições e mudanças

Pontos PrincipaisPontos Principais


Devemos coletar métricas para responder questões específicas sobre o processo de software usado

O modelo CMM classifica os processos de software como inicial, repetíveis, definidos, gerenciáveis e otimizados

Ele identifica processos chaves que devem ser utilizados em cada nível

O modelo da SEI é apropriado para grandes projetos desenvolvidos por grande time de engenheiros

Pontos PrincipaisPontos Principais


ConclusãoConclusão Qualidade é um conceito complexo, porque significa diferentes coisas para diferentes

pessoas; Não há uma simples medida para qualidade de software que seja aceitável para

todos os projetos de todas as empresas; Para estabelecer ou melhorar a qualidade de software, deve-se definir os aspectos

de qualidade nos quais se está interessado e, então, decidir como fazer para medi-los;

A implantação de um sistema de qualidade permite um aumento de produtividade, uma melhoria da qualidade do produto final e um aumento da satisfação dos clientes e da própria empresa;

A falta de consciência de muitas empresas e profissionais que lidam com sistemas complexos tem sido um dos maiores problemas em adotarem uma política de qualidade;

Apesar dos custos elevados, é importante introduzir sistemas de gerenciamento de qualidade de software, como o ISO 9001 ou o CMM.

CESAR/DI-UFPECESAR/DI-UFPE 6969©© 1998, Alexandre 1998, Alexandre VasconcelosVasconcelos

Introdução à Qualidade de SoftwareIntrodução à Qualidade de Software

Situação da Qualidade de Software no Brasil


Elaboração de planos estratégicos, plano Elaboração de planos estratégicos, plano de negócios ou planos de metasde negócios ou planos de metas

Categorias 1993 1995 1997% % Nº %

Atualização sistemática 34,5 21,7 159 27,0Revisão sem periodicidade fixa 38,5 34,2 183 31,1Em implantação 13,1 24,7 150 25,5Não elabora 13,8 19,5 97 16,5


Inclusão de metas ou diretrizesInclusão de metas ou diretrizespara a qualidadepara a qualidade

Categorias 1993 1995 1997% % Nº %

Sistemática 41,2 38,9 199 40,4Eventual 29,0 29,3 141 28,7Pretende incluir 15,4 28,7 131 26,6Não inclui 14,3 3,1 21 4,3


Coleta de indicadores da qualidadeColeta de indicadores da qualidadede produtos e serviçosde produtos e serviços

Periodicidade 1993 1995 1997% % Nº %

Sistemática 26,9 25,1 174 29,5Quando necessário 41,8 42,1 192 32,6Em estudo 13,8 21,7 141 23,9Não coleta 17,5 11,1 82 13,9


Contabilidade de custos da qualidadeContabilidade de custos da qualidadee da não-qualidadee da não-qualidade

65%

20%

9%

6%381

118 5534

Não mantém Em estudo Em projetos específicos Sistemática

410

4 669

Sistemática Em projetos específicos93 95 97


Programa da qualidade total ou similarPrograma da qualidade total ou similar46%

36%

18%272

212104

Não tem Em estudo Implantado

12

47

11

3818

36

Implantado Em estudo93 95 97


Certificação do sistema da qualidadeCertificação do sistema da qualidade

Empresas Certificadas 1995 1997Setor de Informática ... 124Pesquisa da Qualidade 8 44 Certificação ISO 9001 8 35 Certificação ISO 9002 1 11 SW explicitado no certificado 1 15


Conhecimento do Modelo CMMConhecimento do Modelo CMM

71%

24%

5%

419143

27

Não conhece Conhece, mas não usa Conhece e usa

311

5

24

Conhece e usa Conhece, mas não usa95 97


Métodos para apoiar a participação dosMétodos para apoiar a participação dosempregados na solução de problemasempregados na solução de problemas

1993 1995 1997 % % Nº %

Reuniões de trabalho 43,6 61,3 437 74,6Procedimentos informais 34,9 37,4 214 36,5Times, equipes ou círculos ... 12,4 123 21,0Programas de sugestões ... 18,7 113 19,3Outros métodos 14,6 2,5 28 4,8Não adota/em estudo 6,9 10,8 47 8,0


Avaliação de desempenho dos funcionáriosAvaliação de desempenho dos funcionários


Sistemática 18,2 16,4 103 17,5Eventual 13,8 11,3 62 10,6Informal 44,7 54,0 281 47,9Em implantação 9,5 7,0 63 10,7Não realiza 13,8 11,3 78 13,3


Pesquisa de satisfação dos funcionáriosPesquisa de satisfação dos funcionários


Sistemática 6,1 6,8 49 8,3Eventual 9,0 14,1 62 10,6Informal 56,7 50,1 272 46,3Em implantação 7,2 4,3 53 9,0Não realiza 20,9 24,7 151 25,7


Pesquisas de satisfação dos clientesPesquisas de satisfação dos clientes


Sistemática 21,3 18,7 147 25,0Eventual 50,5 45,3 248 42,2Em implantação 8,7 14,6 78 13,3Dados de terceiros 1,8 3,6 27 4,6Não realiza 17,7 17,8 88 15,0


Estruturas de atendimento eEstruturas de atendimento eresolução de reclamaçõesresolução de reclamações

76%60%

40%7%

72%

48%38%

71%

12% 11%Suporte Visitas Hot-line Internet

93 95 9776%

40%


Uso de dados de pesquisa ou de reclamaçõesUso de dados de pesquisa ou de reclamações44%

11%

9%36%

25963

51 211

Sistemática Não usa Em estudo Eventual

39 4341 3544 36

Sistemática Eventual93 95 97


Engenharia de SoftwareEngenharia de SoftwarePrincipais métodos para prevenção de defeitosPrincipais métodos para prevenção de defeitos

Tipos 1993 1995 1997% % Nº %

Controles de versão 52,5 53,7 327 61,1Prototipação 39,4 46,5 259 48,4Gerência de projetos ... ... 235 43,9Métodos orientados a objetos ... 43,4 216 40,4Análise de requisitos 45,0 47,4 210 39,3Métodos estruturados ... ... 210 39,3Projeto da interface com o usuário ... ... 207 38,7Análise crítica conjunta ... ... 194 36,3


Engenharia de SoftwareEngenharia de SoftwareOutros métodos para prevenção de defeitosOutros métodos para prevenção de defeitos

Tipos 1993 1995 1997% % Nº %

Reuso ... 37,3 110 20,6Engenharia da informação ... ... 104 19,4Medições da qualidade (Métricas) ... ... 48 9,0JAD ... 9,9 46 8,6Gestão de configuração ... ... 40 7,5Desenvolvimento em sala limpa ... ... 36 6,7Estimação da confiabilidade ... 10,1 32 6,0Gestão de mudança ... ... 32 6,0QFD ... 1,7 11 2,1Outros ... ... 19 3,6


Engenharia de SoftwareEngenharia de SoftwarePrincipais métodos para detecção de defeitosPrincipais métodos para detecção de defeitos

Tipos 1993 1995 1997% % Nº %

Testes de sistema 64,2 62,2 392 69,4Testes de campo 55,0 58,2 357 63,2Testes de usabilidade ... ... 327 57,9Testes funcionais 58,5 48,8 329 58,2Testes de aceitação 46,8 47,6 278 49,2Validação ... ... 250 44,2


Engenharia de SoftwareEngenharia de SoftwareOutros métodos para detecção de defeitosOutros métodos para detecção de defeitos

Tipos 1993 1995 1997% % Nº %

Testes de unidade ... 23,6 137 24,2Revisões estruturadas ... 2,0 113 20,0Auditorias ... ... 102 18,1Inspeções formais ... 10,1 100 17,7Testes estruturais ... ... 97 17,2Verificação independente ... ... 81 14,3Outros ... ... 16 2,8


Principais Ferramentas UtilizadasPrincipais Ferramentas Utilizadas

Tipos 1993 1995 1997% % Nº %

Dicionários de dados 34,0 38,4 222 39,2Gerador de relatórios 36,2 44,5 218 38,4Gerador de telas 45,7 46,7 207 36,5Depurador interativo 34,4 33,3 167 29,5Gerador de código-fonte 30,1 37,3 162 28,6Gerenciador de projetos ... ... 143 25,2


Outras ferramentas utilizadasOutras ferramentas utilizadasTipos 1993 1995 1997

% % Nº %Gerenc. bibliotecas de módulo 26,6 20,4 116 20,5Gerador de gráficos 24,5 20,7 115 20,3Documentador 19,1 18,6 104 18,3Prototipador 18,4 16,6 90 15,9Distribuição de software ... ... 86 15,2CASE Lower 24,5 26,5 81 14,3CASE Upper ... ... 79 13,9Gerador de entrada de dados 45,7 46,7 63 11,1


Mais Ferramentas utilizadasMais Ferramentas utilizadasTipos 1993 1995 1997

% % Nº %Gerenciador de configuração 10,3 57 10,1Gerenciador de documento ... ... 54 9,5Driver de teste 6,5 52 9,2Gerador de dados de teste 8,9 5,8 50 8,8Analisador de código 10,3 9,9 50 8,8Otimizador 15,2 8,8 38 6,7Outras ... 7,0 26 4,6Não utiliza 21,3 10,8 122 21,5


Principais documentos adotadosPrincipais documentos adotadosTipos 1993 1995 1997

% % Nº %Manual do usuário 64,5 83,3 436 76,0Help on-line 46,1 62,3 369 64,3Contratos e acordos 66,3 67,1 360 62,7Guia de instalação 46,1 44,5 317 55,2Documentação de programas ... 45,4 313 54,5Documentação no código 49,3 47,3 311 54,2Especificação de sistema 62,4 54,1 293 51,0Documentação comercial 51,4 46,6 248 43,2Doc. de descrição do produto ... ... 241 42,0


Outros documentos adotadosOutros documentos adotadosTipos 1993 1995 1997

% % Nº %Projeto de sistema 56,7 40,2 223 38,9Manual de treinamento 42,6 43,8 209 36,4Documentação de marketing ... ... 193 33,6Doc. do processo de software ... ... 141 24,6Plano de testes 36,2 22,4 125 21,8Resultados de revisões / testes 31,6 21,9 126 22,0Plano de controle da qualidade ... ... 39 6,8Outros ... ... 12 2,1Não adota documentação ... 2,5 17 3,0


Biblioteca Técnica EspecializadaBiblioteca Técnica Especializada

49%

40%

11%

284232

61

Sem registro bibliográfico Com registro bibliográfico Não mantém

45,1 43,345 4640,249,2

Com registro Sem registro

93 95 97

cesar/di-ufpe1 © 1998, alexandre vasconcelos introdução à qualidade de software alexandre m....

Documents