Qualidade de Software PDF

Qualidade de Software
by Tatiana Felix
2012
Histórinha clássica....
DEFINIÇÃO:
“Qualidade de software é a conformidade a
requisitos funcionais e de desempenho
explicitamente estabelecidos, a padrões de
desenvolvimento explicitamente
documentados, e a características implícitas
que são esperadas de todo software
desenvolvido profissionalmente”
Pressman
DEFINIÇÃO:
“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
O QUE FAZER ?
A qualidade do produto deve ser especificada

para aquilo que o cliente deseja.
Em software, não sabemos como especificar

com toda precisão características tais como,
facilidade de manutenção ou de uso. Ou
seja:
É muito difícil descrever especificações de

softwares completas.
GESTÃO DA QUALIDADE DE SOFTWARE
Para sistemas pequenos é suficiente

estabelecer uma cultura de qualidade entre as
equipes envolvidas de forma que todos os
membros tenham uma abordagem para
qualidade de software.
Mas como gerenciar qualidade em sistemas de

grande porte ??
Em sistemas de grande porte o gerenciamento da
qualidade pode ser estruturado em três atividades
principais:
Planejamento da Qualidade - Definir os requisitos de
qualidade;
Garantia da Qualidade - Embutir qualidade no produto,

definição e controle do processo;
Controle de Qualidade - Medir a qualidade.

Planejamento da qualidade (QA)
Estabelece as qualidades de software

desejadas e descreve como elas devem ser
avaliadas.
Sem essa definição os engenheiros de software

podem entrar em conflito sobre quais atributos
do produto devem ser otimizados (ex.
segurança, facilidade de uso).
Uma estrutura geral para um plano de qualidade é sugerida por
Humphrey (1989) e inclui:
 Apresentação do produto – Descrição do produto e expectativas de

qualidade
 Plano de produto – Datas críticas de liberação e responsabilidades
 Descrições de processos – Os processos que devem ser usados para
desenvolvimento (padrões de processos).
 Metas de qualidades – Identificação e justificativa de atributos críticos de
qualidade
 Gerenciamento de riscos – Riscos que podem impactar na qualidade
- Um plano de qualidade deve ainda conter um

processo definido de avaliação do produto.
- Essa seria uma forma padronizada de

avaliação se certa qualidade, como facilidade
de manutenção ou robustez, está presente no
produto.
Garantia da qualidade (QA)
Está diretamente relacionada a seleção de padrões

que devem ser aplicados ao processo de
desenvolvimento de software e ao produto final.
Os padrões de software são importantes por várias

razões:
- São baseadas no conhecimento sobre as

melhores práticas;
- Dispõem de frameworks para implementação;
- Ajudam na continuidade do processo.
Padrões de Processos x Padrões de Produtos
Padrões de produto – Aplica-se aos artefatos de

produto (documentos de requisitos, padrões de
codificação).
Padrões de processo – Define os processos que

devem ser seguidos durante o desenvolvimento do
software.
Garantia da qualidade no tempo....
- 1900 Avalia o produto depois de pronto
- 1950 Avalia todo o procedimento de produção
- 1970 Avalia e otimiza cada processo
- 1990 Avalia a concepção do produto

Os sistemas de manufatura nos mostrou que

a qualidade do processo de desenvolvimento
afeta diretamente a qualidade dos produtos
entregues.
Embora softwares não sejam manufaturado,

mas sim projetados, a experiência tem
mostrado que a qualidade de processo
também tem influência significativa na
qualidade do produto.
A fim de alcançar garantia de qualidade, algumas medidas
podem ser tomadas para evitar problema de não aderência
aos padrões estabelecidos
a) Revise os padrões regularmente para refletirem

mudanças de tecnologia.
a) Envolva os engenheiros de softwares na seleção de

padrões e inclua no documento de padrões as razões pela
quais as decisões de padronização foram tomadas.
a) Disponha de ferramentas de software para apoiar

padrões.
Órgãos responsáveis pela avaliação e a criação de
normas e padrões:
ISO
IEEE
IEC
ABNT
A ISO e a IEC definem processo de software como
sendo:
“Conjunto de processos usados por uma

organização para: planejar, gerenciar, executar,
monitorar e melhorar as atividades relacionadas
ao software.”
PRINCIPAIS NORMAS PARA SOFTWARE'
ISO9000-3:
ISO9000-3 Normas para aplicação da série ISO9000 e
processos de software.
ISO12207:
ISO12207 Processos do ciclo de vida do software.
ISO25000:
ISO25000 SQuaRE–Software Quality Requirements and
Evaluation
CMM:
CMM Capability Maturity Model
CMMI:
CMMI Capability Maturity Model Integration
PSP:
PSP Personal software Process
ISO15504 (SPICE):
SPICE) Software Process Improvement and
Capability dEtermination
MPS.BR: Melhoria de Processo de Software Brasileiro
ENTENDENDO AS ESTRUTURAS DE PADRÕES
Maior centralizador e Desenvolvedor internacional
publicador internacional de de padrões para as áreas de
padrões eletrotécnica
Desenvolvedor internacional
de padrões para formatos de
dispositivos computacionais
Aqui
entra a
certificação
PRINICPAIS NORMAS ISO 9000
ISO 9000
Sistemas da Qualidade - Modelo para Garantia da Qualidade

ISO 9001 em Projeto, Desenvolvimento, Produção, Instalação e
Assistência
ISO 9002
Modelo para Garantia da Qualidade em Produção, Instalação
e Serviços Associados (MANUFATURA)
ISO 9003
Modelo para Garantia da Qualidade em Inspeção e Ensaios
Finais
NORMAS ISO 9000
ISO 9000-3
ISO 9000-3
É a norma ISO 9001 direcionada para software. Para

cada item da ISO 9001 existem um correspondente na
ISO 9000-3.
Destina-se a fornecer orientação quando um contrato
entre duas partes exigir a demonstração da
capacidade do fornecedor em desenvolver, fornecer e
manter produtos de software.

ISO 9000-3
Principais Diretrizes:
- E s trutura : De s c re ve a s pe c tos orga niza c iona is re la c iona dos a o

s is te ma de qua lida de (re s pons a bilida de da ge rê nc ia ).
- Ativida de s do C ic lo de V ida : De s e nvolve r e doc ume nta r

proc e dime ntos pa ra c ontrola r todo o proje to de de s e nvolvime nto
do s oftw a re .
- Ativida de s de a poio: De s c re ve a tivida de s que a poia m o c ic lo de

vida (re a liza ç ã o de te s te s , ins pe ç ã o)
LEMA DA NORMA:
“Diga o que você faz, faça tudo o

que você diz e documento tudo!”
CERTIFICAÇÃO ISO 9000
Sequência para certificação ISO:
1) Estabelece o Sistema de Qualidade

2) Solicitação ao órgão certificador
3) Visita à empresa
4) Auditoria
5) Emissão do Certificado
Limitações das normas ISO 9000-3
Não trata aspectos de melhoria contínua dos

processos – Software Process Improvements (SPI).
Apenas indica quais processos a organização dever

ter e manter, mas não diz como desenvolver esses
processos.
ISO/IEC-12207
Lançada em 1995, a norma formaliza a arquitetura do

Ciclo de Vida do Software, onde os processos eram
divididos em três grupos. Com sua atualização em
2008 passou-se a ter sete grupos.
Ela descreve com detalhes os processos, atividades e

tarefas que envolvem o fornecimento,
desenvolvimento, operação e manutenção de
produtos de Software
ISO/IEC-12207
Estrutura
A norma categoriza seus grupos de processos em Processos de Contexto de

Sistema e Processos Específicos de Software.
Cada processo é descrito em termos da sua finalidade e os resultados desejados

e lista atividades e tarefas que necessitam de ser realizados para atingir esses
resultados
Padrões sempre
dizem o que fazer,
mas não como fazer!
Grupos de Processos
tem
tem Propósitos
Processos tem
Resultados esperado
tem
Tarefas
tem
Atividades
ISO/IEC-12207 Categorias
Grupos
de processos
ISO/IEC-12207
Exemplo para categoria Processos de Contexto do Sistema
Grupo de processo: – 1. Agreement Processes
Processos definidos: - 1.1 - Acquisition Process e 1.2 – Supply Process
1.1.1. - Propósito : obter o produto que o aquisitor (cliente) necessita
1.1.2. - Resultados: a) critérios de necessidades de aquisição, as metas de produtos e/ou
serviço de aceitação e estratégias de aquisição são definidos;
b) um acordo é desenvolvido que expressa claramente as expectativas,
responsabilidades e obrigações de ambas as adquirente eo fornecedor;
c) um ou mais fornecedores é selecionada;
d) um produto e / ou serviço é adquirido que satisfaz a necessidade do
adquirente indicado;
e) a aquisição é monitorado para que as restrições especificadas, tais
como custo, cronograma e qualidade são cumpridos;
f) entregas de fornecedores são aceitos;
g) quaisquer itens identificados abertos tem uma conclusão satisfatória,
conforme acordado pelo adquirente eo fornecedor.
1.1.3.1. - Atividades: Acquisition Preparation
1.3.1.1.1 - Tarefa: O adquirente começa o processo de aquisição por descrever um
conceito ou uma necessidade de adquirir, desenvolver ou melhorar um
sistema, produto de software ou serviço de software
1.3.1.1.2. O adquirente deve definir e analisar os requisitos de sistema
(...)
ISO/IEC- 25000
Software Quality Requirements and Evaluation

(SQuaRE)
ISO/IEC- 25000 - SQuaRE

SquaRE significa Software Product Quality Requirements and
Evaluation (Requisitos de Qualidade e Avaliação deProdutos de
Software)

Consiste de cinco divisões:
Gestão de Qualidade (2500n)
Modelo de Qualidade (2501n)
Medição da Qualidade (2502n)
Requisitos de Qualidade (2503n)
Avaliação da Qualidade (2504n)

Evolução das séries de normas ISO/IEC-9126 e ISO/IEC-
14598. É uma segunda geração de padrões para qualidade de
produtos de software
ISO/IEC- 9126 e 14598
As normas ISO/IEC 9126 e ISO/IEC 14598 são compostas por 10 documentos:
Norma Conteúdo
9126-1 Modelo de qualidade de software
9126-2 Métricas externas
9126-3 Métricas internas
9126-4 Métricas para qualidade em uso
14598-1 Guia de Avaliação – Visão Geral
14598-2 Planejamento e gerenciamento de avaliações
14598-3 Processo de avaliação para desenvolvedores
14598-4 Processo de avaliação para adquirentes
14598-5 Processo de avaliação para avaliadores
14598-6 Documentação de módulos de avaliação
ISO/IEC- 25000 - SQuaRE
Gerenciamento : os documentos desta divisão estão voltados a todos possíveis usuários
dela,gerentes, programadores, avaliadores, compradores. Aqui são definidos os termos utilizados
em todos os demais documentos e são feitas recomendações e sugestões de caráter geral sobre
como utilizar o Square.
Modelo de qualidade : É definido um modelo hierárquico de características de qualidade,

descrevendo o que se espera de um produto. São definidos também os conceitos de qualidade
externa, interna e em uso , que permitem orientar diferentes perspectivas de avaliação.
Medição : Define- se o que é uma medição e descreve os diversos aspectos relacionados à

realização dessa tarefa. Propõe também uma série de métricas que podem ser utilizadas ou
adaptadas a necessidades especificas.
Requisitos de qualidade : Para garantir qualidade é preciso que valores-alvo tenham sido
previamente especificados, o que faz parte evidentemente da especificação de requisitos.
Avaliação: a Square concretiza-se na realização de uma avaliação de qualidade a partir de

medições cujos resultados são confrontados contra um modelo definido pelo usuário. Para
realizar uma avaliação são sugeridos procedimentos a serem adotados para diferentes públicos
da norma, como desenvolvedores e compradores.
(CMM)
Capability Maturity Model
CMM – Capability Maturity Model
O modelo CMM serve para orientar a organização a implementar a

melhoria contínua do processo de software.
O modelo foi proposto inicialmente por Watts S. Humphrey. Foi

aperfeiçoado pelo SEI - Software Engineering Institute, da Carnegie
Mellon University, dos EUA.
Possui 5 níveis para classificar a organização. A cada nível de

maturidade corresponde um conjunto de práticas de software e de
gestão específicas, denominadas áreas-chave do processo (KPAs -
Key Process Areas). Estas devem ser implantadas para que a
organização possa atingir o nível de maturidade desejado
CMM – Níveis de maturidade
Auto-adaptativo, melhoria
Otimizado (5) do processo contínuo
Gerenciado (4) Quantitativo, controle por

medição
Qualitativo, processo sistematizado e
Definido (3) controlado(consciente)
Intuitivo, baseado na experiência. Inicia-se a implantação
Repetível (2) de mecanismos de gerenciamento de projetos
Inicial (1) Caótico, imprevisível e pessimamente controlado (ad-hoc).

Depende exclusivamente dos indivíduos
O CMM enfatiza a documentação dos processos, seguindo

a premissa de que para realizar alguma melhoria no
processo, é preciso primeiro, conhecê-lo e entendê-lo, e
que a qualidade de um produto é reflexo da qualidade e
gerenciamento do processo utilizado em seu
desenvolvimento.
As KPA's (Key Process Areas) são exatamente os pontos

chaves levantado pelo modelo CMM, nos quais a
organização deve focar para melhorar o seu processo.
NÍVEL CMM FOCO KPAS
--
1) Inicial Pessoas competentes
e heróis
2) Repetitivo Processos de • Gerenciamento de requisitos

gerenciamento de • Planejamento do projeto
projetos • Visão geral e acompanhamento do
projeto
• Gerenciamento de subcontratados
• Garantia da qualidade do software
• Gerenciamento de configuração
NÍVEL CMM FOCO KPAS
3) Definido Processos de engenharia • Foco do processo organizacional

e apoio • Definição do processo organizacional
• Programa de treinamento
• Gerenciamento de software integrado
• Engenharia de produto de software
• Coordenação intergrupos
• Revisão conjunta
4) Gerenciado Qualidade do produto e do • Gerenciamento quantitativo dos
processo processos
• Gerenciamento da qualidade de software
5) Otimizado Melhoramento contínuo do • Prevenção de defeitos
processo • Gerenciamento de mudanças
tecnológicas
• Gerenciamento de mudanças no
processo
CMM – Capability Matutity Model
CMM é composto de vários modelos com diferentes

processos de avaliação:
SW-CMM ou Software CMM, relacionado a área de

engenharia de software;
SA-CMM ou Software Acquisiton, voltado pra disciplina de
aquisição;
SE-CMM ou Systems Engineering CMM, relacionado a
engenharia de sistemas;
P-CMM ou People CMM, direcionado a área de gestão de
recursos humanos
CMM – Capability Matutity Model
- CMM contempla apenas a forma de representação por

estágios através dos níveis de maturidade
- Exige alto custo para empresa aplicar mais de um

modelo CMM, por exemplo SW-CMM e SE-CMM
- Não é compatível com a norma ISO/IEC 15540

CMMI = Capability Maturity Model Integration

CMMI – Capability Matutity Model Integration
Criado pelo SEI (Software Engineering Institute), com o

objetivo de gerar uma nova versão do CMM a fim de
suportar a melhoria de processos e produtos reduzindo a
redundância e eliminando as inconsistências quando da
utilização de modelos isoladamente
O modelo CMMI é mais abrangente que o CMM. A adição

do ‘i’ representa a integração de modelos de capacidade e
maturidade, aumentando a complexidade e exigência
deste novo modelo.
Integra os modelos CMMs (SW-CMM, SE-CMM, AS-CMM

e IPD-CMM) numa estrutura única e tornar o CMM.
CMMI melhora a eficiência, o retorno em investimento e a

efetividade, pois integra também disciplinas como
engenharia de sistemas e engenharia de software,
desenvolvimento de integração de processos e
subcontratação.
Permite a utilização da representação estagiada e também

contínua, no processo de maturidade, o que o torna
compatível com a norma ISO/IEC 15504.
CMMI – Representações
Representação Estagiada: utilizada para verificar o nível

de maturidade (Maturity levels) da organização em geral.
Representações Contínua: utilizada para verificar níveis

de capacidade (Capability Levels) em grupos de
processos.
REPRESENTAÇÃO ESTAGIADA:
REPRESENTAÇÃO CONTÍNUA
Um jeito simples de entender CMMI
Nivel 3 -
Agora é possível conhecer
melhor os processos e seu
funcionamento
Nivel 2 -
Com a gestão por projetos os
processos são executados de
forma sistematizada
Nivel 1 -
A matéria-prima entra o
produto sai, mas ninguém
sabe dizer ao certo como
ele saiu
Um jeito simples de entender CMMI
Nivel5 -
Com o conhecimento
adquirido, já é possível
elaborar estratégias de
melhoria desempenho
dos processos
Nivel 4 -
Com o entendimento do
processo é possível medir
desempenho e realizar
previsões mais precisas
PSP - Personal software process
É um processo de desenvolvimento de software projetado para

ser utilizado por engenheiros de software para a elaboração de
projetos individuais.
Em resumo, PSP se propõe a ajudar as pessoas a serem

melhores engenheiros de softwares
Benefícios:
– melhoria da produtividade: melhor conhecimento e controle
dos mecanismos e tempos de produção
– qualidade dos produtos: resultado do conhecimento das
causas dos erros e do seu controle estatístico
ISO 2500 - SQuaRE
Uma evolução das normas ISO/IEC 9126 (Software product

quality) e ISO/IEC 14598 (Software product evaluation)
O Software product Quality Requirements and Evaluation

(SquaRE ) é uma série de normas e consiste de cinco
divisões :
• ISO/IEC 2500n - Quality Management Division

• ISO/IEC 2501n - Quality Model Division
• ISO/IEC 2502n - Quality Measurement Division
• ISO/IEC 2503n - Quality Requirements Division
• ISO/IEC 2504n - Quality Evaluation Division
ISO 15004
SPICE = Software Process Improvement and Capability dEtermination

ISO 15004 - SPICE
Desenvolvida pela ISO/IEC com apoio do SPICE com

base em vários padrões como o CMM, o Trillium (Bell) e
a Norma 12207.
Não é uma metodologia e sim uma iniciativa para uma

padronização Internacional de Avaliação de Processos
de Software visando a melhoria de processos e a
determinação da capacidade de processos
Foi publicada já como Norma ISO 15504 em março de

2006
ISO 15004 - SPICE
Inclui um modelo de referência, dividido em cinco

categorias de processo e seis níveis de capacitação para
cada processo
Categorias: Níveis de capacitação:
Cliente-Fornecedor (CUS) Nível 0 - Incompleto

Engenharia (ENG) Nível 1 - Realizado
Gerenciamento (MAN) Nível 2 - Gerenciado
Suporte (SUP) Nível 3 - Estabelecido
Organização (ORG) Nível 4 - Previsível
Nível 5 - Otimizado
ISO 15004 -Categorias
ISO 15004 -Categorias
ISO 15004 - Categorias
ISO 15004 – Niveis de Capacidade
MPS-BR
MPS-BR
O MPS-BR acrônimo de Melhoria de Processo de Software
Brasileiro foi criado em dezembro de 2003 e é coordenado pela
Associação para Promoção da Excelência do Software Brasileiro
(SOFTEX)
O objetivo do programa é estabelecer e disseminar modelos de

referência para processos de software que sejam adequado ao
perfil de diferentes empresas com diferentes tamanhos e
características, principalmente as micro, pequenas e médias
empresas
O modelo é baseado nas normas ISO/IEC 12207, ISO/IEC 15504

e no CMMI-DEV. O MPS-BR é uma adaptação do CMMI para a
realidade do mercado brasileiro.
MPS-BR
MPS estabelece um modelo de referência para processos de software
(MR), um processo e um método de avaliação de processos (MA) e
também um modelo de negócio (MN) para apoiar a sua adoção pelas
empresas brasileiras desenvolvedoras de software.
MPS-BR
- O Modelo de Referência MPS define níveis de maturidade que são uma
combinação entre processos e sua capacidade seguindo os requisitos da
norma ISO/IEC 15504.
- A capacidade do processo é a caracterização da habilidade do processo

para alcançar os objetivos de negócio, atuais e futuros;
- A declaração do propósito e os resultados esperados na execução dos

processos, permite avaliar e atribuir graus de efetividade na execução dos
processos
Lembre-se que quando falamos em
maturidade devemos pensar:
transparente, medido e gerenciado
MPS-BR e os
7 níveis de
maturidade
MPS-BR - Como funciona?
AP 1.1 -
Processos O processo é
executado
Gerência de
Requisito
Gerência de
Projeto AP 1.1 -
O processo é
gerenciado
CONTROLE DA QUALIDADE
CQS (Controle de Qualidade de Software) é um

conjunto planejado e sistemático de todas as
ações necessárias para fornecer uma confiança
adequada de que o item ou produto está de
acordo com os requisitos técnicos
estabelecidos.
ANSI/IEEE
Todos os produtos de trabalho tem

especificações definidas e mensuráveis com as
quais podemos comparar o resultado de cada
processo.
Controle de qualidade envolve a monitoração

do desenvolvimento do software para
assegurar que os procedimentos e os padrões
estão sendo seguidos.
Pesquisa realizada pela IBM em 1981 comprovaram que
um erro descoberto durante o projeto custava 1,0
Unidade Monetária (UM) para correção. A correção do
mesmo erro descoberto imediatamente após o início do
teste custaria 6,5 UM's. Já a correção durante o teste
aumentaria para15 UM's. Depois da entrega custaria entre
60 e 100 UM's.
Embora os dados tenha mais de 20 anos, a experiência

nos mostra que permanecem aplicáveis no contexto atual.
Verificação:
assegura a correção e a consistência dos produtos de cada fase do
desenvolvimento e, também, com relação as normas fornecidas
como entrada para a referida fase.
Validação:
avalia a adequação do produto de software aos seus propósitos,
assegurando que o mesmo atenda aos requisitos especificados.
Teste:
execução do código para produzir resultados a serem analisados.
A abordagem para Controle de qualidade pode ser

divido em duas vertentes:
- Revisões de Qualidade
- Avaliação de software com métricas

Revisões de Qualidade
Este é o principal método de validação da

qualidade de um processo ou de um produto
As revisões são aplicadas em vários pontos

durante a engenharia de software e servem para
descobrir erros ou defeitos que podem depois ser
removidos
Revisões de Qualidade
Existem diferentes tipos de revisão com objetivos diferentes:
Inspeções: Detecta erros detalhados nos requisitos, projeto ou

código
Revisões Técnicas Formais: Fornece informações para a gerência

sobre progresso geral do projeto. Foco em prazo, planejamento e
custos.
Além disso, conduz uma análise técnica dos componentes do
produto ou documentação para encontrar inconsistência entre
especificação e projeto, código ou documentação e assegurar que
os padrões de qualidade foram seguidos
Inspeções
A realização de uma inspeção implica, além do planejamento,

preparação e reunião, numa etapa de apresentação, onde os
desenvolvedores fazem um tutorial, de aproximadamente trinta
minutos, sobre o material a ser inspecionado, destacando o que
deve ser analisado.
Na preparação individual, os inspetores devem avaliar o material, de

acordo com a lista de critérios previamente estabelecida.
Ao final, a lista de critérios deve ter sido completamente analisada e

com respostas consensuais a todas as questões. Deve-se decidir,
como resultado: aceitação do produto, ou aceitação com alterações
ou rejeição
Revisões Técnicas Formais
Walkthrough
Envolve as atividades de planejamento, preparação e uma reunião, com

duração em torno de duas horas, com a participação de três a cinco
pessoas.
O material a ser avaliado é distribuído previamente, para os avaliadores se

prepararem para a reunião, através da identificação dos problemas
encontrados.
A reunião é composta de um moderador, de representantes da equipe dos

usuários e de desenvolvimento e de avaliadores externos.
Ao final tem-se como resultado: aceitação do produto, ou aceitação com

alterações ou rejeição
Algumas diretrizes gerais podem ser seguidas no processo de
revisões formais:
Revise o produto e não o produtor

Estabeleça uma agenda e a siga
Limitar debates
Enunciar os problemas, mas não se preocupar em resolver todos
naquele momento
Tome nota por escrito
Limitar o número de participantes
Desenvolver um checklist
Rever suas revisões
Programar tempo para as reuniões
Avaliação de software com métricas
- Se dedica a derivar um valor numérico para algum atributo de um
produto de software ou de processo de software. Comparando os
resultados é possível tirar conclusões sobre a qualidade do software
ou do processo
- As medições permitem fazer previsões de pontos críticos
comparando a complexidade entre componentes.
Ao introduzir métricas de software como parte do

processo de gerenciamento da qualidade, as
organizações devem experimentar descobrir as
métricas mais apropriadas para as suas
necessidades
As métricas de produtos se dividem em duas

classes: Métricas Dinâmicas e Estáticas
Métricas Dinâmicas são coletadas por meio de medições

realizadas durante a execução do programa. Elas estão
relacionadas diretamente com a eficiência do sistema e
confiabilidade.
Exemplo: Tempo de inicialização do sistema, tempo de

execução de determinada função
Métricas Estáticas são coletadas por meio de medições

realizadas em representações do sistema, como projeto,
documentação. Estão diretamente relacionadas a
complexidade do sistema, facilidade de compreensão ou
manutenção do software
Exemplos: Quantidade de Fan-in/Fan-out, complexidade

ciclomática, profundidade de If's
- Fan-in mede o número de funções
que chama uma determinada função
- Fan-out mede o número de funções
que uma determinada função chama.
Outras métricas de softwares podem ser estabelecidas a fim de

alcançar qualidade
Disponibilidade: Tempo médio entre falhas, tempo de médio de

reparo
Segurança: probabilidade de ocorrências de riscos

identificados.
Métricas e Seis Sigmas
“Seis Sigmas é uma metodologia rigorosa e disciplinada que

usa dados e análise estatística para medir e aperfeiçoar o
desempenho operacional de uma empresa pela identificação e
eliminação de defeitos nos processos de fabricação e
relacionado a serviços”
iSixSigma
Originalmente foi desenvolvidas pela Motorola para melhorar
sistematicamente os processos ao eliminar defeitos
Para alcançar o Seis Sigma, um processo não deve produzir

mais de 3,4 defeitos por milhão de oportunidades, implicando
em uma norma de qualidade extremamente alta
A metodologia é inspirada pelo ciclo Plan-Do-Check-Act e seus

três passos centrais são:
Defina (os requisitos do cliente), Meça (o processo existente e

sua saída) e Analise (causa-raíz do defeito)
Para empresas focadas em Para empresas focadas em

criar novos processos, dois melhorar processos, dois
passos adicionais são passos adicionais são
incluídos: incluídos:
Desenhe detalhes do projeto; Aperfeiçoe o processo,

eliminando causas básicas de
Verifique o modelo definido, defeitos;
sua eficácia;
Controle o processo;
Resumo Qualidade
A Gestão da qualidade de Software está preocupada com a

garantia de que o software cumpre seus padrões exigidos,
devendo assim ter seus processos de produção bem definidos.
Procedimentos de garantia de qualidade devem ser

documentados em um manual da qualidade organizacional
Padrões de software (normas) são um encapsulamento das

melhores práticas.
Resumo Qualidade
Revisões são a abordagem mais amplamente utilizado para

avaliar a qualidade do software
A medição de software reúne informações tanto sobre o

processo de software quanto do produto de software.
Métricas de qualidade de produtos devem ser usados para

identificar componentes potencialmente problemáticos.
Não existem métricas de software padronizadas e

universalmente aplicável
( FIM )

Idioma

Qualidade de Software PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Qualidade de Software PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Qualidade de Software

“Qualidade é a totalidade das características

A qualidade do produto deve ser especificada

Em software, não sabemos como especificar

É muito difícil descrever especificações de

Para sistemas pequenos é suficiente

Mas como gerenciar qualidade em sistemas de

Garantia da Qualidade - Embutir qualidade no produto,

Controle de Qualidade - Medir a qualidade.

Estabelece as qualidades de software

Sem essa definição os engenheiros de software

 Apresentação do produto – Descrição do produto e expectativas de

- Um plano de qualidade deve ainda conter um

- Essa seria uma forma padronizada de

Está diretamente relacionada a seleção de padrões

Os padrões de software são importantes por várias

- São baseadas no conhecimento sobre as

Padrões de Processos x Padrões de Produtos

Padrões de produto – Aplica-se aos artefatos de

Padrões de processo – Define os processos que

- 1900 Avalia o produto depois de pronto

- 1950 Avalia todo o procedimento de produção

- 1970 Avalia e otimiza cada processo

- 1990 Avalia a concepção do produto

Os sistemas de manufatura nos mostrou que

Embora softwares não sejam manufaturado,

a) Revise os padrões regularmente para refletirem

a) Envolva os engenheiros de softwares na seleção de

a) Disponha de ferramentas de software para apoiar

“Conjunto de processos usados por uma

Sistemas da Qualidade - Modelo para Garantia da Qualidade

É a norma ISO 9001 direcionada para software. Para

Destina-se a fornecer orientação quando um contrato

entre duas partes exigir a demonstração da

capacidade do fornecedor em desenvolver, fornecer e

manter produtos de software.

- E s trutura : De s c re ve a s pe c tos orga niza c iona is re la c iona dos a o

- Ativida de s do C ic lo de V ida : De s e nvolve r e doc ume nta r

- Ativida de s de a poio: De s c re ve a tivida de s que a poia m o c ic lo de

“Diga o que você faz, faça tudo o

1) Estabelece o Sistema de Qualidade

Não trata aspectos de melhoria contínua dos

Apenas indica quais processos a organização dever

Lançada em 1995, a norma formaliza a arquitetura do

Ela descreve com detalhes os processos, atividades e

A norma categoriza seus grupos de processos em Processos de Contexto de

Cada processo é descrito em termos da sua finalidade e os resultados desejados

Software Quality Requirements and Evaluation

Modelo de qualidade : É definido um modelo hierárquico de características de qualidade,

Medição : Define- se o que é uma medição e descreve os diversos aspectos relacionados à

Avaliação: a Square concretiza-se na realização de uma avaliação de qualidade a partir de

O modelo CMM serve para orientar a organização a implementar a

O modelo foi proposto inicialmente por Watts S. Humphrey. Foi

Possui 5 níveis para classificar a organização. A cada nível de

Gerenciado (4) Quantitativo, controle por

Inicial (1) Caótico, imprevisível e pessimamente controlado (ad-hoc).

O CMM enfatiza a documentação dos processos, seguindo

As KPA's (Key Process Areas) são exatamente os pontos

NÍVEL CMM FOCO KPAS

2) Repetitivo Processos de • Gerenciamento de requisitos

3) Definido Processos de engenharia • Foco do processo organizacional

CMM é composto de vários modelos com diferentes

Métricas de qualidade de produtos devem ser usados para