qualidade de software - luiz leaoluizleao.com/docencia/fap/qualidade/qualidade_und_03.pdf · nbr...

Qualidade de Software

Luiz Leão – [email protected]

http://www.luizleao.com


Luiz Leão – [email protected]

http://www.luizleao.com

UNIDADE III – Sistema de Garantia de Qualidade

mailto:[email protected]

http://www.luizleao.com/

mailto:[email protected]

http://www.luizleao.com/



Conteúdo da Unidade

• A abordagem NBR ISO 9000

• Modelos de qualidade de produto de software

– NBR ISO/IEC 9126 (software)

– NBR ISO/IEC 12119 (pacote)

– NBR ISO/IEC 9241 (usabilidade)

– NBR ISO/IEC 14598 (avaliação)

• Modelos de melhoria e avaliação de processo de software

– NBR ISO 9000 3

– NBR ISO/IEC 12207 (ciclo de vida)

– NBR ISO/IEC 15504 (SPICE avaliação)

– CMMI (melhoria de processo)

– MPS.BR (melhoria de processo)



A preocupação com a melhoria da qualidade de produto e de

serviço motivou a criação de modelos de Qualidade de

Produto de Software.

Avaliações de produtos através de algum tipo de certificação

emitida com base numa padronização.

Introdução



A ISO (International Organization for Standardization) e a IEC

(International Electrotechnical Commission) elaboraram um

conjunto de normas que tratam sobre a atual padronização

mundial para a qualidade de produtos de software.

O NBR ISO 9000 é a versão brasileira da norma

A Abordagem NBR ISO 9000

NBR ISO/IEC 9126 (Software)



É uma norma composta por um conjunto de características que

devem ser verificadas em um software para que ele seja

considerado um "software de qualidade“, bem como, métricas

usadas na sua avaliação (medição, pontuação e julgamento dos

softwares).





Estrutura

• ISO/IEC 9126-1:

– Modelo de Qualidade;

• ISO/IEC 9126-2:

– Métricas Externas - Apoio para definição dos atributos de qualidade;

• ISO/IEC 9126-3:

– Métricas Internas - Apoio para definição dos atributos de qualidade;

• ISO/IEC 9126-4:

– Métricas de Qualidade em Uso.



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

NBR ISO/IEC 9126-1 (Qualidade de Software)



• A capacidade de um software prover funcionalidades que

satisfaçam o usuário em suas necessidades declaradas e

implícitas, dentro de um determinado contexto de uso.


Funcionalidade



Suas sub-características são:

• Adequação: – Mede o quanto o conjunto de funcionalidades é adequado às necessidades do usuário;

• Acurácia (ou precisão): – Representa a capacidade do software de fornecer resultados precisos ou com a precisão

dentro do que foi acordado/solicitado;

• Interoperabilidade: – Trata da maneira como o software interage com outro(s) sistema(s) especificados;

• Segurança: – Mede a capacidade do sistema de proteger as informações do usuário e fornecê-las apenas

(e sempre) às pessoas autorizadas. Segurança também pode estar dirigida em, processar

gerar e armazenar as informações.

• Conformidade: – Trata da padronização, politicas e normas de um projeto.


Funcionalidade



• O produto se mantém no nível de desempenho nas

condições estabelecidas.


Confiabilidade




• Maturidade: – Entendida como sendo a capacidade do software em evitar falhas

decorrentes de defeitos no software;

• Tolerância a Falhas: – Representando a capacidade do software em manter o funcionamento

adequado mesmo quando ocorrem defeitos nele ou nas suas interfaces

externas;

• Recuperabilidade: – Foca na capacidade de um software se recuperar após uma falha,

restabelecendo seus níveis de desempenho e recuperando os seus

dados;


Confiabilidade



• A capacidade do produto de software ser compreendido, seu

funcionamento aprendido, ser operado e ser atraente ao usuário.

• Note que este conceito é bastante abrangente e se aplica mesmo a

programas que não possuem uma interface para o usuário final. Por

exemplo, um programa batch executado por uma ferramenta de

programação de processos também pode ser avaliado quanto a sua

usabilidade, no que diz respeito a ser facilmente compreendido,

aprendido, etc.

• Além disto, a operação de um sistema é uma interface Humano-

Computador (IHC) sujeita às avaliações de usabilidade.


Usabilidade




• Inteligibilidade – Representa a facilidade com que o usuário pode compreender as suas funcionalidades e

avaliar se o mesmo pode ser usado para satisfazer as suas necessidades específicas;

• Apreensibilidade: – Identifica a facilidade de aprendizado do sistema para os seus potenciais usuários;

• Operacionalidade: – É como o produto facilita a sua operação por parte do usuário, incluindo a maneira como ele

tolera erros de operação;

• Atratividade: – Envolve características que possam atrair um potencial usuário para o sistema, o que pode

incluir desde a adequação das informações prestadas para o usuário até os requintes

visuais utilizados na sua interface gráfica;


Usabilidade



• O tempo de execução e os recursos envolvidos são compatíveis

com o nível de desempenho do software.


• Comportamento em Relação ao Tempo:

– Avalia se os tempos de resposta (ou de processamento) estão dentro das

especificações;

• Utilização de Recursos:

– Mede tanto os recursos consumidos quanto a capacidade do sistema em utilizar

os recursos disponíveis;


Eficiência



• A capacidade (ou facilidade) do produto de software ser modificado,

incluindo tanto as melhorias ou extensões de funcionalidade quanto

as correções de defeitos, falhas ou erros.


Manutenibilidade




• Analisabilidade:

– Identifica a facilidade em se diagnosticar eventuais problemas e identificar as

causas das deficiências ou falhas;

• Modificabilidade:

– Caracteriza a facilidade com que o comportamento do software pode ser

modificado;

• Estabilidade:

– Avalia a capacidade do software de evitar efeitos colaterais decorrentes de

modificações introduzidas;

• Testabilidade:

– Representa a capacidade de se testar o sistema modificado, tanto quanto as

novas funcionalidades quanto as não afetadas diretamente pela modificação;


Manutenibilidade



• A capacidade do sistema ser transferido de um ambiente para

outro.

• Como "ambiente", devemos considerar todo os fatores de

adaptação, tais como diferentes condições de infra-estrutura

(sistemas operacionais, versões de bancos de dados, etc.),

diferentes tipos e recursos de hardware (tal como aproveitar um

número maior de processadores ou memória).

• Além destes, fatores como idioma ou a facilidade para se criar

ambientes de testes devem ser considerados como características

de portabilidade.


Portabilidade




• Adaptabilidade:

– Representando a capacidade do software se a adaptar a diferentes ambientes

sem a necessidade de ações adicionais (configurações);

• Capacidade Para ser Instalado:

– Identifica a facilidade com que pode se instalar o sistema em um novo ambiente;

• Coexistência:

– Mede o quão facilmente um software convive com outros instalados no mesmo

ambiente;

• Capacidade para Substituir:

– Representa a capacidade que o sistema tem de substituir outro sistema

especificado, em um contexto de uso e ambiente específicos. Este atributo

interage tanto com adaptabilidade quanto com a capacidade para ser instalado;


Portabilidade

NBR ISO/IEC 12119 (Pacote)




• Esta norma é aplicável à avaliação de pacotes de

software na forma em que são oferecidos e liberados

para uso no mercado

• É importante salientar que não é objetivo desta norma

tratar o processo de produção do software, suas

atividades e produtos intermediários ou o sistema de

qualidade do produtor




• Entende-se por pacote de software o “conjunto completo

e documentado de programas fornecidos a diversos

usuários para uma aplicação ou função genérica”

• Exemplos: processadores de texto, planilhas

eletrônicas, bancos de dados, software gráficos,

programas para funções técnicas ou científicas e

programas utilitários

• Também conhecidos internacionalmente como COTS –

Commercial off-the-Shelf




• Os potenciais usuários desta norma são:

– Fornecedores que estejam especificando os requisitos para um

pacote de software, projetando um modelo para descrever

produtos, divulgando seus próprios produtos, submetendo

produtos à certificação;

– Entidades certificadoras que pretendam estabelecer um modelo

de certificação por terceira parte;

– Entidades de credenciamento que credenciam entidades de

certificação ou laboratórios de teste;

– Laboratórios de testes que deverão seguir as instruções de

teste para certificação ou para a emissão de marca de

conformidade com a norma;




• Os potenciais usuários desta norma são (Cont.):

– Auditores de laboratórios de testes que julgam a competência

de laboratórios de teste;

– Compradores que pretendam comparar os requisitos

necessários para executar uma determinada tarefa com a

informação presente nas descrições de produtos existentes ou

verificar se os requisitos foram atendidos;

– Usuários que pretendam se beneficiar com produtos melhores.



Estrutura Básica da ISO/IEC 12119

• Requisitos de Qualidade

– Descrição do Produto

– Documentação do Usuário

– Programa e Dados

• Instruções para Teste

– Pré-requisitos de Teste

– Atividades de Teste

– Registros de Teste

– Relatório de Teste

– Teste de Acompanhamento



Estrutura Básica da ISO/IEC 12119



Requisitos de Qualidade

• Um pacote de software deve possuir a documentação

do pacote, que é composta por:

– Descrição do Produto

– Documentação do Usuário

– Programa e Dados




• É um documento que expõe as principais propriedades

de um pacote de software, com os seguintes objetivos:

– Auxiliar o usuário ou os potenciais compradores deste produto,

na avaliação da adequação do produto às suas reais

necessidades

– Servir como base para testes

Descrição do Produto




• Este documento deve estar disponível ao usuário,

independentemente da aquisição do produto, através de

um catálogo, de um arquivo de apresentação ou

qualquer outro meio disponível que alcance esse

objetivo

• A descrição deve ser clara, compreensível e harmônica

com outros documentos associados

• A norma propõe aspectos práticos e diretos, indicando

“o quê” deve conter esta descrição





• Algumas dessas indicações podem ser mandatórias

(termo “deve”) ou recomendáveis (termo “pode”)

• É importante observar que o uso de um requisito como

recomendável está diretamente relacionado com o tipo

do produto, ou seja, para alguns tipos de produto esses

requisitos podem ser mandatórios

– Por exemplo, um sistema de reserva de passagens aéreas tem

como um dos requisitos mandatórios a eficiência





Documentação do Usuário

• É o conjunto completo de documentos, disponíveis na

forma impressa ou não, que é fornecido para utilização

de um produto, sendo também uma parte do produto

• Ela deve incluir todos os dados necessários para a

instalação (se necessário), para o uso da aplicação e

para a manutenção do produto de software




Documentação do Usuário




Programas e Dados

• Os requisitos de qualidade para Programas e Dados

utilizam as mesmas definições das características de

qualidade da Norma ISO/IEC 9126.

• As características de Funcionalidade, Confiabilidade e

Usabilidade são destacadas e devem ser verificadas

através do uso do produto

• Não há requisitos específicos para os aspectos de

eficiência, manutenibilidade e portabilidade

• Qualquer requisito declarado na documentação do

pacote referente às características citadas, deve estar

em conformidade




Programas e Dados



Instruções para Teste

• Este item recomenda como um produto deve ser testado

em relação aos requisitos de qualidade




Pré-requisitos de Teste




Atividades de Teste




Registros de Teste

• Os registros devem conter informações suficientes para

permitir a repetição do teste, através de um Plano de

Teste com os casos de teste, os resultados associados

e a identificação das pessoas envolvidas




Relatório de Teste

• Deve conter um resumo com os objetos e resultados

dos testes efetuados com a seguinte estrutura:

– Identificação do produto

– Sistemas computacionais utilizados

– Documentos usados

– Resultados dos testes da Atividade de Teste

– Lista das não-conformidades

– Data de encerramento do teste




Teste de Acompanhamento

• Quando um produto é testado novamente (considerando

o teste anterior), todas as partes modificadas e as

partes inalteradas, mas influenciáveis pelas

modificações, devem ser testadas como se fosse um

produto novo

NBR ISO/IEC 9241 (Usabilidade)



• Na avaliação de usabilidade de sistemas interativos, o

padrão internacional mais comum é a norma ISO 9241.

• Considera mais o ponto de vista do usuário e seu

contexto de uso do que as características ergonômicas

do produto.




• A parte 11 (1998) desta norma redefine usabilidade

como “a capacidade de um produto ser usado por

usuários específicos para atingir objetivos específicos

com eficácia, eficiência e satisfação em um contexto

específico de uso.”




• Para melhor compreensão desse enunciado, a norma

ISO 9241-11 (1998) também esclareceu outros

conceitos:

• Usuário: Pessoa que interage com o produto.

• Contexto de Uso: Usuários, tarefas, equipamentos

(hardware, software e materiais), ambiente físico e

social em que o produto é usado.

• Eficácia: Precisão e completeza com que os usuários

atingem objetivos específicos, acessando a informação

correta ou gerando os resultados esperados.




• Eficiência: Precisão e completeza com que os usuários

atingem seus objetivos, em relação à quantidade de

recursos gastos.

• Satisfação: Conforto e aceitabilidade do produto,

medidos por meio de métodos subjetivos e/ou objetivos.


NBR ISO/IEC 14598 (Avaliação)



• A norma ISO 14598 define um processo de avaliação da

qualidade do software .

• A ISO 14598 orienta que o seu uso deve ser feito em

conjunto com a norma ISO 9126, já que esta define as

métricas de qualidade de software.




• No processo de avaliação definido nesta norma, a

identificação das necessidades do usuário é um passo

importante para a qualidade do uso.

• Tais requisitos são informais por natureza e precisam

ser formalizados. Eles podem ser quantificados e a

qualidade de uso avaliada em métricas (ISO 9126).




• Processos abordados na norma:

– Parte 1: Visão Geral

– Parte 2: Planejamento e Gestão

– Parte 3: Processo para Desenvolvedores

– Parte 4: Processo para Adquirintes

– Parte 5: Processo para Avaliadores

– Parte 6: Documentação de Módulos de Avaliação




• Define um processo de avaliação de produtos de

software dividido em quatro fases:

1. Estabelecimento de requisitos de avaliação

2. Especificação da avaliação

3. Projeto da avaliação

4. Execução da avaliação


Parte 1: Visão Geral



• Define um processo de avaliação de produtos de

software dividido em quatro fases:

1. Estabelecimento de requisitos de avaliação

2. Especificação da avaliação

3. Projeto da avaliação

4. Execução da avaliação


Parte 2: Planejamento e Gestão

Modelos de Melhoria e Avaliação de Processo

de Software

NBR ISO 9000-3



• Em junho de 1993 foi criado o guia ISO 9000-3, com

diretrizes para aplicação da ISO 9001 onde, para cada

item desta, existe um correspondente na ISO 9000-3

que o detalha e o adequa ao software.

• Haja visto, a ISO 9000-3 é um guia para a aplicação da

ISO 9001 para o fornecimento, desenvolvimento e

manutenção de software.

NBR ISO/IEC 9000-3



NBR ISO/IEC 9000-3

• As diretrizes propostas na ISO 9000-3 cobrem questões

como:

– Entendimento dos requisitos funcionais entre contratante e

contratado

– Uso de metodologias consistentes para o desenvolvimento de

software

– Gerenciamento de projeto desde a concepção até a

manutenção.



NBR ISO/IEC 9000-3

• Uma das limitações da ISO 9000-3 é que ela não trata

de aspectos como a melhoria contínua do processo de

software (SPI – Software Process Improvement) como

faz o modelo CMM ou a norma SPICE (ainda em

desenvolvimento, nesse momento).

• Desta forma, o que a ISO 9000-3 traz é apenas quais

processos a organização deve ter e manter, mas não

trata orienta quanto aos passos que devem ser seguidos

para chegar a desenvolver estes processos – nem de

como aperfeiçoa-los.



NBR ISO/IEC 9000-3

• A primeira edição da ISO 9000-3 (e a NBR-ISO 9000-3

atual) agrupava as diretrizes em três partes principais:

– Estrutura: Descreve aspectos organizacionais, relacionados ao

sistema de qualidade.

– Atividades do ciclo de vida: Descreve as atividades de

desenvolvimento de software.

– Atividades de suporte: Descreve as atividades que apoiam as

atividades do ciclo de vida.



NBR ISO/IEC 9000-3

• Além disto, a ISO 9000-3 organizava e dava nomes às

diretrizes diferentes dos utilizados na ISO 9001.

• Neste caso era necessário uma tabela de mapeamento

entre as diretrizes da ISO 9000-3 e da ISO 9001

causando uma série de transtornos.



NBR ISO/IEC 9000-3

• Esta estrutura, nomenclatura e arranjo particular das

diretrizes foram abandonados nas edições mais

recentes.

• Estas seguem exatamente a estrutura da ISO 9001, e

suas diretrizes têm o mesmo nome.

NBR ISO/IEC 12207 (Ciclo de Vida)




• Estabelece uma estrutura comum para os processos de

ciclo de vida de software, com terminologia bem

definida, que pode ser referenciada pela indústria de

software.

• Aplica-se à aquisição de sistemas, produtos e serviços

de software, para o fornecimento, o desenvolvimento, a

operação e a manutenção de produtos de software, quer

sejam executados interna ou externamente a uma

organização.




• Contém um conjunto de processos, atividades e tarefas

projetado para ser adaptado de acordo com cada

projeto de software.

• A estrutura cobre o ciclo de vida do software desde a

concepção de ideias até a descontinuação do software.

• O processo de adaptação consiste na supressão de

processos, atividades e tarefas não aplicáveis.




• Descreve a arquitetura dos processos de ciclo de vida

de software, mas não especifica os detalhes de como

implementar ou executar as atividades e tarefas

incluídas nos processos.

• Não pretende prescrever o nome, formato ou conteúdo

explícito da documentação a ser produzida.

• Não prescreve um modelo específico de ciclo de vida ou

métodos de desenvolvimento de software.




• As partes envolvidas são responsáveis pela seleção de

um modelo de ciclo de vida para o projeto e pelo

mapeamento dos processos, atividades e tarefas dentro

desse modelo.

• As partes envolvidas são também responsáveis pela

seleção e aplicação dos métodos e pela execução das

atividades e tarefas adequadas ao projeto.



• Processos Fundamentais;

• Processo de Apoio;

• Processos Organizacionais;

• Processos de Adaptação


Estrutura




Estrutura

NBR ISO/IEC 15504 (SPICE Avaliação)



• Software Process Improvement and Capability

dEtermination – Melhoria de Processos de Software e

Determinação de Capacidade

• É um modelo baseado em níveis de capacidade mais

geral e abrangente que os modelos anteriores e mais

específico para software que a ISO 9001

• Apresenta uma estrutura para Avaliação (e Melhoria)

de Processo

ISO/IEC 15504 – SPICE



• Influenciada por um conjunto de padrões que na base

do projeto SPICE.

• Incluindo, a sua principal fonte de inspiração é a norma

ISO 12207 – um standard internacional da ISO para os

processos do ciclo de vida do software.




• Melhoria Contínua: Avaliação identifica oportunidades

de melhoria. Feita por organizações que buscam

melhorias internas

• Determinação da Capacidade: Avaliação identifica

riscos com o fornecedor. Feita por terceiros ao

realizarem contratos de prestação de serviços ou

fornecimento de produtos.


Contextos de Utilização:



• 1991: Estudo sobre a necessidade de uma norma para

avaliação de processos de software.

• 1993: Início do Projeto SPICE (Software Process

• Improvement and Capability dEtermination).

• 1998: Versão Inicial da “norma SPICE” (publicada como

Relatório Técnico - TR).

• 2003: Encerramento do Projeto SPICE e publicação da

parte 2.

• 2004: Publicação das partes 1, 3 e 4.


Histórico:



• Focada exclusivamente em software.

• É um modelo para avaliação de processos de software.

• Possui um modelo de referência que é a base da

Avaliação dos Processos.

• Dá suporte a todo o ciclo de vida do software.

• Dividida em 9 partes.

• Apenas um Relatório Técnico e não uma norma

internacional.

A “Norma SPICE”



A “Antiga Norma SPICE”



A “Norma SPICE”: Processos (Parte 7)



• É uma norma internacional.

• É genérica, não sendo mais dedicada exclusivamente a

software.

• Introduz o conceito de Modelo de Referência de

Processo, que é externo à norma (antiga parte 2).

• Para ser aplicada à software, deve ser complementada

pela ISO/IEC 12207, considerando suas emendas 1 e 2.




• Dividida em 5 partes:

– 1: Conceitos e vocabulário (antigas partes 1 e 9)

– 2: Estrutura (framework) do processo de avaliação (antiga parte

3).

– 3: Recomendações para a realização de uma avaliação (antigas

partes 4 e 6)

– 4: Recomendações para melhoria de processos e determinação

de capacidade (antigas partes 7 e 8).

– 5: Um exemplo de aplicação com base na ISO 12207.




ISO/IEC 15504: Estrutura



• Parte 1 - Conceitos e vocabulário (informativa): Provê uma

introdução geral aos conceitos de avaliação de processos e um

glossário de termos relacionados à avaliação.

• Parte 2 - Realização de uma avaliação (normativa): Define os

requisitos normativos para a realização de uma avaliação de

processo e para modelos de processo em uma avaliação, e define

uma infra-estrutura de medição para avaliar a capacidade de

processo. Essa infraestrutura de medição define nove atributos de

processo, agrupados em seis níveis de capacidade de processo.

ISO/IEC 15504



• Parte 3 - Guia para a realização de avaliações (informativa): Provê

orientações para interpretar os requisitos para a realização de uma

avaliação.

• Parte 4 - Guia para uso na melhoria de processo e na determinação da

capacidade de processo (informativa): Provê orientações para a

utilização de avaliação de processo para propósitos de melhoria de

processo e de determinação da capacidade.

• Parte 5 - Um Exemplo de modelo de avaliação de processo baseado

na ISO/IEC 12207 e suas Emendas 1 e 2 (informativa): Contém um

exemplo de modelo de avaliação de processo que é baseado no modelo de

processo de referência definido na ISO/IEC 12207 e suas emendas 1 e 2.

ISO/IEC 15504



• [1] Visão geral e vocabulário

• [2] Estrutura para medição de capacidade de processo, composta por seis

níveis de capacidade(0 a 5)

• [2] Requisitos para um processo de avaliação de processo

• [2] Requisitos para modelos de referência de processo

• [2] Requisitos para modelos de avaliação de processo

• [2] Requisitos para verificação de conformidade de uma avaliação

• [3] Guia para avaliação de processo

• [3] Orientações para qualificação de avaliadores competentes

• [3] Exemplo de atividades de um processo de avaliação

• [4] Guia para utilização dos resultados de uma avaliação de processo, para

melhoria ou determinação de capacidade

• [5] Exemplo de um modelo de avaliação de processo de software

ISO/IEC 15504: Estrutura Normativo



• Dimensão de Processo: Corresponde à definição de

um conjunto de processos considerados universais e

fundamentais para a boa prática da engenharia de

software; Atualmente, um modelo de referência de

processo no domínio de software é a ISO 12207;

• Dimensão de Capacidade: Permite uma avaliação

detalhada dos processos executados por uma

organização. Trabalha com: – Níveis de capacidade

– Atributos de processo

ISO/IEC 15504: Dimensões



ISO/IEC 15504: Dimensões



• 1.1 Execução: O processo atinge os objetivos

esperados.

• 2.1 Administração do Processo: Objetivos do

processo são identificados e sua execução é planejada.

Responsabilidades são atribuídas, a infra-estrutura é

fornecida e a comunicação entre os envolvidos é

gerenciada.

• 2.2 Administração do Produto: Produtos do processo

são identificados e documentados, requisitos para eles

são definidos e revisões e ajustes são efetuados

conforme necessário.

ISO/IEC 15504: Atributos de Processo



• 3.1 Definição: Um processo padrão é definido para a

organização.

• 3.2 Implementação: Os elementos identificados em 3.1

são postos em prática.

• 4.1 Medição: Estabelecem-se objetivos quantitativos,

bem como as medições a serem realizadas e a

frequência de sua aplicação. Os resultados são

coletados, analisados e publicados na organização.

• 4.2 Controle: Estabelecem-se limites de variação para

as medidas e ações corretivas para tratar as causas de

desvios em relação a esses limites.




• 5.1 Inovação: Objetivos de melhoria são estabelecidos.

Oportunidades de melhoria são identificadas.

• 5.2 Otimização: O desempenho do processo é medido

e o impacto das melhorias propostas é comparado com

os objetivos esperados. A implementação de mudanças

é gerenciada.




Grau de Satisfação

N

Não atingido

0 a 15% Existe pouca ou nenhuma evidência de

que o atributo de processo seja

alcançado.

P

Parcialmente

atingido

16 a 50% Existe evidência de uma abordagem

significativa para atingir o atributo,

mas alguns aspectos (tais como

resultados) são ainda imprevisíveis.

L

Largamente

atingido

51 a 85% O desempenho do processo pode

variar em algumas áreas.

T

Totalmente

Atingido

86 a 100% Não há nenhuma falta ou falha

significativa.

ISO/IEC 15504: Avaliação de Atributos



Nível de Capacidade

1 2 3 4 5

1.1 L ou T T T T T

2.1 L ou T T T T

2.2 L ou T T T T

3.1 L ou T T T

3.2 L ou T T T

4.1 L ou T T

4.2 L ou T T

5.1 L ou T

5.2 L ou T

ISO/IEC 15504: Níveis Exigidos de

Capacidade de Processo



• Com o sucesso do SW-CMM, novos modelos

semelhantes forma desenvolvidos:

– P-CMM: Gestão de Recursos Humanos

– SA-CMM: Aquisição de Software

– SE-CMM: Engenharia de Sistemas

– Etc.

CMMI – Introdução



• Porém, como possuem estruturas diferentes entre si,

dificultando o uso mais de um modelo no mesmo

projeto, surgiu o CMMI, cuja finalidade é evoluir o

modelo anterior (SW-CMM), integrando os diversos

modelos criados




CMMI – Evolução



• Versões do CMMI:

– Versão 1.0: Agosto de 2000

– Versão 1.1: Março de 2002

– Versão 1.2: Agosto de 2006 (CMMI for Development)

– Versão 1.3: Novembro de 2010




• A versão atual do CMMI (1.3), apresenta 3 modelos:

– CMMI for Development (CMMI-DEV), voltado ao processo de

desenvolvimento de produtos e serviços.

– CMMI for Acquisition (CMMI-ACQ), voltado aos processos de

aquisição e terceirização de bens e serviços.

– CMMI for Services (CMMI-SVC), voltado aos processos de

empresas prestadoras de serviços.




• Aumento do foco nas atividades;

• Integração dos processos existentes;

• Eliminar inconsistências;

• Reduzir duplicações;

• Fornecer terminologia comum;

• Assegurar consistência com a norma ISO 15504

(SPICE);

• Flexibilidade e Extensão para outras disciplinas.

CMMI – Objetivos



• Prover um guia para a melhoria de processos

organizacionais e habilidades de gestão do

desenvolvimento, aquisição e manutenção de produtos

e serviços.

CMMI – Resumindo...



• O CMMI não é um conjunto de processos definidos a

serem utilizados na organização

• O CMMI não é uma metodologia

CMMI – Atenção!!



• O CMMI possui 2 representações:

– Representação Contínua

– Representação por Estágios

CMMI

Representações:



• Possibilita à organização utilizar a ordem de melhoria

que melhor atende os objetivos de negócio da empresa.

• É caracterizado por Níveis de Capacitação (Capability

Levels):

CMMI

Representação Contínua



• Níveis de Capacitação

• Agrupamento das Áreas de Processo por Categoria

• Avaliação da capacidade das Áreas de Processo

CMMI

Representação Contínua – Resumo



• Oferece máxima flexibilidade na utilização do modelo

para a melhoria de processos

– A organização pode escolher a ordem de melhoria que melhor

se encaixa a seus objetivos

• Permite comparação com outras organizações processo

a processo

• Fácil comparação com a ISO 15504

CMMI

Representação Contínua – Vantagens



• Os processos da organização que precisam ser

melhorados devem ser conhecidos previamente

– Nem sempre isso é possível

• Flexibilidade de escolha não é de 100%

– Existem dependências entre as áreas de processo – isto pode

limitar as escolhas da organização

• Maior retorno sobre o investimento de empresas com

abordagem contínua ainda não foi comprovado

CMMI

Representação Contínua – Desvantagens



• Nível 0: Incompleto

• Nível 1: Executado

• Nível 2: Gerenciado

• Nível 3: Definido

• Nível 4: Gerenciado Quantitativamente

• Nível 5: Otimizado

CMMI

Representação Contínua – Níveis de Capacitação



CMMI

Representação Contínua – Níveis de Capacitação



• O nível incompleto corresponde, no caso mais simples,

à não-realização de um processo.

• Se o processo é implantado pela organização, o nível 0

é atribuído quando um ou mais objetivos específicos da

área de processo não são satisfeitos.

CMMI

Nível 0 – Incompleto



• Para estar no nível 1, cada processo deve cumprir todos

os objetivos específicos de sua área.

• Um processo utiliza entradas determinadas e leva à

obtenção de produtos específicos, identificados como

saídas.

CMMI

Nível 1 – Realizado



• Os processos são monitorados, controlados, e

revisados, assim como os produtos resultantes

• Todo processo é institucionalizado, sendo ancorado nos

objetivos da organização e devendo cumprir com metas

como custo, prazo e qualidade.

• É planejado e seu desempenho é gerenciado de acordo

com tal plano de ação.

CMMI

Nível 2 – Gerenciado



• O processo está adaptado a um conjunto de processos

padronizados da organização, seguindo suas diretivas.

• Processos padronizados são estabelecidos e

melhorados continuamente.

• A descrição de um processo definido inclui, entre outros

tópicos, suas entradas, atividades, medidas,

verificações e saídas

CMMI

Nível 3 – Definido



• São estabelecidas métricas quantitativas para avaliar os

processos e os produtos.

• Os riscos envolvidos no aprendizado para

desenvolvimento em um novo domínio da aplicação

são cuidadosamente gerenciados.

• Como resultado desse maior controle, coleta de dados e

gerenciamento de riscos, os produtos de software

tendem a apresentar maior qualidade.

CMMI

Nível 4 – Gerenciado Quantitativamente



• O processo gerido quantitativamente é alterado e

adaptado para atender às necessidades

negociais/estratégicas da empresa.

• Um processo otimizado possui como foco a melhoria

contínua de desempenho.

• Esse objetivo é buscado por melhorias tecnológicas

incrementais e de inovação.

CMMI

Nível 5 – Otimizado



• Disponibiliza uma sequência pré-determinada para

melhoria baseada em estágios que não deve ser

desconsiderada, pois cada estágio serve de base para o

próximo.

• É caracterizado por Níveis de Maturidade (Maturity

Levels):

CMMI

Representação Por Estágios



• Níveis de Maturidade

• Agrupamento de Áreas de Processo por Nível

• Avaliação da Organização como um todo

CMMI

Representação Por Estágios – Resumo



• Provê uma sequência bem definida de melhoria de

processos

• Permite comparações entre organizações por meio do

uso de níveis de maturidade

• Provê uma única classificação que resume os

resultados das avaliações e permite a comparação

simples entre organizações

CMMI

Representação Por Estágios – Vantagens



• Rigidez na escolha das áreas de processos a serem

melhoradas

– Mesmo se não for de interesse da empresa é necessário

melhorá-lo

• O custo pode ser maior, caso a empresa não tenha

interesse em algumas áreas de processo, mas tenha

que implementá-la mesmo assim

CMMI

Representação Por Estágios – Desvantagens



• Nível 1: Inicial

• Nível 2: Gerenciado

• Nível 3: Definido

• Nível 4: Gerenciado Quantitativamente

• Nível 5: Otimizado

CMMI

Representação Por Estágios – Níveis de

Maturidade



CMMI

Representação Por Estágios – Níveis de

Maturidade



• Processos são ad hoc e caóticos

• A organização não fornece um ambiente estável para

apoiar os processos

• O sucesso depende do heroísmo e da competência de

pessoas individualmente

• Organizações neste nível se comprometem além de sua

capacidade, abandonam o processo em momentos de

crise e são incapazes de repetir os próprios sucessos

CMMI

Nível 1 – Inicial



• Os processos são planejados e executados de acordo

com uma política

• Recursos adequados e pessoas experientes são

envolvidos para produzir saídas controladas

• Inclui medição, controle e revisão dos processos

• É alcançado pelas metas específicas das áreas de

processo de nível 2 e a meta genérica 2

CMMI

Nível 2 – Gerenciado



• Processos são bem caracterizados e entendidos, e são

descritos em padrões, procedimentos, ferramentas e

métodos

• No nível 2, cada projeto tinha seus padrões,

procedimentos, etc... No nível 3 há um padrão da

organização

• Os projetos estabelecem seus processos adaptando

este padrão


processos de nível 2 e 3 e metas genéricas 2 e 3

CMMI

Nível 3 – Definido



• Objetivos quantitativos são estabelecidos para a

qualidade e desempenho dos processos

• Medições são feitas por meio de técnicas estatísticas e

quantitativas, apenas para os subprocessos mais

relevantes


processo de nível 2, 3 e 4 e metas genéricas 2 e 3

CMMI

Nível 4 – Gerenciado Quantitativamente



• Os processos são melhorados continuamente com

base no entendimento quantitativo das

• causas comuns de variações inerentes aos processos

• As melhorias são escolhidas e comparadas ao seu

custo e impacto na organização


processo de nível 2, 3, 4 e 5 e metas genéricas 2 e 3

CMMI

Nível 5 – Em Otimização



• A principal diferença é a forma como cada

representação é aplicada

• Os níveis de capacitação (Contínua) são aplicados na

melhoria de processos de uma organização para cada

área

• Os níveis de maturidade (Por Estágios) indicam

melhorias na organização como um todo.

CMMI

Contínua X Por Estágios



CMMI

Contínua X Por Estágios

MPS.BR



MPS.BR

• Melhoria de Processos do Software Brasileiro

• Desenvolvido pela Softex (Associação para Promoção da

Excelência do Software Brasileiro), tem como objetivo a melhoria

de processos de software nas micros, pequenas e médias

empresas (PMEs), a um custo acessível, em diversos locais do

país.

• Como?

– Desenvolvimento (e Aprimoramento) do Modelo MPS.BR.

– Implementação e Avaliação do Modelo MPS.BR em Empresas, com

foco em grupos de empresas.



MPS.BR

Estrutura



MPS.BR

Desenvolvimento e Aprimoramento



MPS.BR

Base Técnica do MPS.BR



MPS.BR

Níveis de Maturidade

• A - Em Otimização;

• B - Gerenciado quantitativamente;

• C - Definido;

• D - Largamente Definido;

• E - Parcialmente Definido;

• F - Gerenciado;

• G - Parcialmente Gerenciado.



MPS.BR

Níveis de Maturidade

qualidade de software - luiz leaoluizleao.com/docencia/fap/qualidade/qualidade_und_03.pdf · nbr...

Documents