[05] QuaSftw Qualidade do Processo

Prévia do material em texto

1
Rafael Targino
rtargino@unicarioca.edu.br
@rafatargino
QUALIDADE DE SOFTWARE
Unidade II - Qualidade do Processo
2
Programa da Aula
• Qualidade de Processo de Software
• Norma ISO/IEC 12207
• Norma ISO/IEC 15504
• CMMI
• MPS.Br
• Qualidade do produto não se atinge de forma 
espontânea.
• A qualidade dos produtos de software depende 
fortemente da qualidade do processo de software 
usado para desenvolvê-los. 
• Um bom processo de software não garante que os 
produtos de software produzidos são de boa 
qualidade, mas é um indicativo de que a organização 
é capaz de produzir bons produtos de software .
Produto X Processo
3
A implantação de um Programa de 
Qualidade de Software começa, 
normalmente, pela definição e
implantação de um processo de 
software.
O Significado de Processo
• Cada processo recebe entradas
• Entradas são transformadas por um processo.
• Um processo gera saídas (os produtos do processo).
• Clientes são receptores das saídas.
• Fornecedores são provedores de serviços ou matérias-primas 
(entradas do processo).
4
Processo de Software
• Sub-processos
– Atividades
– Sub-atividades
– Pré-atividades
– Artefatos
• Insumos
• Produtos
– Recursos
• Humanos
• Software
• Hardware
– Procedimentos
• Métodos
• Técnicas
• Roteiros
Programa da Aula
• Qualidade de Processo de Software
• Norma ISO/IEC 12207
• Norma ISO/IEC 15504
• CMMI
• MPS.Br
5
Norma ISO/IEC 12207
• Em 1989 o JTC1 iniciou o desenvolvimento da ISO 
12207, com o objetivo de identificar os Processos do 
Ciclo de Vida de Software.
• Foi desenvolvida com a participação de vários países, 
dentre eles o Brasil.
• Publicada em 1995 (versão NBR em 1998)
• Sofreu duas emendas:
– Amd 1 (2002): introdução de novos processos e definição de 
propósitos e resultados esperados para cada processo.
– Amd 2 (2004): trata de um número de questões técnicas e 
editoriais menores na Amd 1.
Norma ISO/IEC 12207
• 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.
• 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.
6
O que não tem na Norma ISO/IEC 12207
• 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.
Estrutura da ISO/IEC 12207
• Processos possuem propósito e resultado(s). Todos 
os processos possuem pelo menos uma atividade. 
Os processos, junto com suas declarações de 
propósito e resultados, constituem um Modelo de 
Referência de Processo.
• Atividades são unidades de construção usadas para 
agrupar tarefas relacionadas. 
• Uma tarefa é uma cláusula detalhada para a 
implementação de um processo. Pode ser um 
requisito (deve - “shall”), uma recomendação 
(deveria - “should”) ou uma permissão (pode-
“may”).
• Notas são usadas quando uma informação 
explanatória é necessária para melhor descrever a 
intenção ou os mecanismos de um processo
7
Estrutura da ISO/IEC 12207
• Propósito do Processo: 
– O principal objetivo da execução do processo. 
Convém que a implementação do processo forneça 
benefícios tangíveis aos envolvidos.
• Resultado do Processo: 
– Um resultado observável da realização com sucesso 
do propósito do processo.
– Um resultado pode ser:
• um artefato produzido;
• uma mudança significativa de estado; e
• o atendimento das especificações, como por exemplo: 
requisitos, metas etc.
Estrutura da ISO/IEC 12207
• 24 processos
– Agrupados em 4 categorias 
• 95 atividades
• 325 tarefas
• 224 resultados
8
Categorias de Processo
• Os processos da ISO/IEC 12207 são agrupados em quatro 
categorias:
– Fundamentais: constituem um conjunto de processos que 
atendem às partes fundamentais (pessoa ou organização / 
adquirente, fornecedora, desenvolvedora, operadora ou 
mantenedora do software).
– De Apoio: auxiliam um outro processo e contribuem para o 
sucesso e qualidade do projeto, podendo ser realizados, quando 
necessário, por outro processo.
– Organizacionais: empregados por uma organização para 
estabelecer e implementar uma estrutura subjacente, constituída 
de processos de ciclo de vida e pessoal associados, e melhorar 
continuamente a estrutura e os processos. São tipicamente 
empregados fora do domínio de projetos e contratos específicos.
– Há, ainda, o processo de adaptação, que define as atividades 
básicas necessárias para executar as adaptações.
Processos da ISO/IEC 12207
Processos Fundamentais Processos de Apoio
P
ro
ce
sso
 d
e A
d
a
p
ta
çã
o
Aquisição Documentação
Fornecimento Gerência de Configuração
Desenvolvimento
Operação
Garantia da Qualidade
Verificação
Validação
Revisão Conjunta
Manutenção
Auditoria
Usabilidade
Gerência de Resolução de Problemas
Gerência de Solicitação de Mudanças
Avaliação do Produto
Processos Organizacionais
Gerência Engenharia de Domínio
MelhoriaGestão de Ativos Infra-estrutura
Gestão de Programa de Reúso Recursos Humanos
9
Processos Fundamentais e seus Propósitos
• Aquisição: obter um produto e/ou serviço que satisfaça a 
necessidade expressa pelo cliente.
• Fornecimento: fornecer um produto ou serviço ao cliente 
que atenda aos requisitos acordados.
• Desenvolvimento: transformar um conjunto de requisitos 
em um produto de software ou um sistema baseado em 
software que atenda às necessidades explicitadas pelo 
cliente.
• Operação: operar o produto de software no seu ambiente 
e fornecer suporte aos clientes desse produto.
• Manutenção: modificar um produto de software/sistema 
após sua entrega para corrigir falhas, melhorar o 
desempenho ou outros atributos, ou adaptá-lo a mudanças 
no ambiente.
Processos de Apoio e seus Propósitos (1/3)
• Documentação: desenvolver e manter registradas as 
informações do software produzidas por um processo.
• Gerência de Configuração: estabelecer e manter a 
integridade de todos os produtos de trabalho de um 
processo ou projeto e disponibilizá-los a todos os 
envolvidos.
• Garantia da Qualidade: fornecer garantia de que os 
produtos de trabalho e processos estão em 
conformidade com os planos e condições predefinidos.
10
Processos de Apoio e seus Propósitos (2/3)
• Verificação: confirmar que cada produto de trabalho de 
software e/ou serviço de um processo ou projeto reflete 
apropriadamente os requisitos especificados.
• Validação: confirmar que são atendidos os requisitos de 
um uso específico pretendido para o produto de trabalho 
de software.
• Revisão Conjunta: manter um entendimento comum com 
os envolvidos (stakeholders) a respeito do progresso obtido 
em relação aos objetivos acordados e ao que deveria ser 
feito.
• Auditoria: determinar, de forma independente, a 
conformidade dos produtos e processos selecionados com 
os requisitos, planos e contratos, quando apropriado.
Processos de Apoio e seus Propósitos (3/3)
• Gerência de Resolução de Problema: assegurar que todos 
os problemas identificados são analisados e resolvidos e 
que as tendências são identificadas.
• Usabilidade: garantir que sejam considerados os interesses 
e necessidades dos envolvidos de forma a proporcionar 
otimização do suporte e do treinamento, aumento da 
produtividade eda qualidade do trabalho, melhoria das 
condições para o trabalho humano e redução das chances 
de rejeição do sistema por parte do usuário.
• Avaliação de Produto: garantir, através de exame e 
medição sistemáticos, que o produto atende às 
necessidades especificadas e implícitas dos seus usuários.
11
Processos Organizacionais e seus Propósitos (1/2)
• Gerência: organizar, monitorar e controlar a iniciação e a 
execução de qualquer processo de forma a atingir as suas 
metas de acordo com as metas de negócio da organização. 
É estabelecido por uma organização para garantir a 
aplicação consistente de práticas por parte da organização 
e dos projetos.
• Infraestrutura: manter uma infraestrutura estável e 
confiável, necessária para apoiar a execução de qualquer 
outro processo. A infraestrutura pode incluir hardware, 
software, métodos, ferramentas, técnicas, padrões e 
instalações para o desenvolvimento, a operação ou a 
manutenção.
• Melhoria: estabelecer, avaliar, medir, controlar e melhorar 
um processo de ciclo de vida de software.
Processos Organizacionais e seus Propósitos (2/2)
• Recursos Humanos: fornecer à organização os recursos 
humanos adequados e manter as suas competências 
consistentes com as necessidades do negócio.
• Gestão de Ativos: gerenciar a vida dos ativos 
reutilizáveis desde a sua concepção até a sua 
descontinuação.
• Gestão do Programa de Reuso: planejar, estabelecer, 
gerenciar, controlar e monitorar esse programa em 
uma organização e sistematicamente explorar as 
oportunidades de reuso.
• Engenharia de Domínio: desenvolver e manter 
modelos, arquiteturas e ativos de domínio.
12
Exemplo de Atividades de um Processo
• Atividades do Processo de Desenvolvimento na ISO/IEC 
12207 
– Implementação do processo;
– Análise dos requisitos do sistema;
– Projeto da arquitetura do sistema;
– Análise dos requisitos do software;
– Projeto de arquitetura do software;
– Projeto detalhado do software;
– Codificação e testes do software;
– Integração do software;
– Testes de qualificação do software;
– Integração do sistema;
– Teste de qualificação do sistema;
– Instalação do software;
– Apoio à aceitação do software
Exemplo de Tarefas de uma Atividade
• Tarefas da Atividade “Análise dos requisitos do software” na 
ISO/IEC 12207:
– O desenvolvedor deve estabelecer e documentar os requisitos do 
software, incluindo as especificações das seguintes características 
de qualidade: 
– (i) especificações funcionais e de capacidade, 
– (ii) interfaces externas ao item de software, 
– (iii) requisitos de qualificação, 
– (iv) especificações de proteção, segurança e de engenharia de 
fatores humanos (ergonomia), 
– (vi) definição de dados e requisitos de bases de dados, 
– (vii) requisitos de instalação e aceitação do produto, 
– (viii) documentação do usuário,
– (ix) requisitos do usuário para execução, operação e manutenção. 
Um guia para especificar as características de qualidade pode ser 
encontrado na ISO/IEC 9126.
13
Exercício/Discussão em Sala de Aula
• Considerando:
– A Norma ISO/IEC 12207 não especifica os detalhes de como 
implementar ou executar as atividades e tarefas incluídas nos 
processos.
– 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.
• Como ficaria a adaptação dos processos 
definidos na ISO/IEC 12207 nos modelos de 
ciclo de vida Cascata, Espiral e Scrum?
Programa da Aula
• Qualidade de Processo de Software
• Norma ISO/IEC 12207
• Norma ISO/IEC 15504
• CMMI
• MPS.Br
14
ISO/IEC 15504
• Apresenta uma estrutura para Avaliação (e Melhoria) 
de Processo
• Contextos de Utilização:
– 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.
ISO/IEC 15504
• Também conhecida como SPICE
• É 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.
• Para ser aplicada a software, deve ser complementada.
• A ISO 12207 pode ser o Modelo de Referência de 
Processo, quando a ISO 15504 for aplicada à software.
15
Melhoria
da
Organização
Decisão e 
comprometimento
para a melhoria
Institucionaliza
a melhoria
Prepara
institucionalização
da melhoria
Inicia
ciclo de
melhoria
Avalia
práticas
correntes
Planeja
ações de
melhoria
Realiza
ações de
melhoria
Abordagem de um Programa de 
Melhoria de Processo
ISO 15504: Processo de Avaliação
Modelo de Referência de 
Processo
• Domínio e Escopo
• Propósito do Processo
• Resultados Esperados
Arcabouço de Medição
• Níveis de Capacidade
• Atributos de Processo
• Escala de Classificação
Modelo de Avaliação de Processo
Processo de Avaliação
Planejamento
Coleta de Dados
Validação dos Dados
Classificação dos Atributos de Processo
Relatório
Papéis e Responsabilidades
Entradas Saídas
Seção 4.2
Seção 4.3
Seção 4.4 Seção 4.5
Seção 5
16
ISO/IEC 15504: Dimensões
• Dimensão de Processo: se limita à verificação da 
execução ou não dos processos.
• Dimensão de Capacidade: permite uma avaliação 
detalhada dos processos executados por uma 
organização. Trabalha com:
– Atributos de processo 
– Níveis de capacidade
Processo 
executado
dentro de 
limites de
controle 
definidos e
com medições
detalhadas e
analisadas
Processo 
planejado e 
acompanhando,
e satisfaz 
requisitos
definidos de:
✓ qualidade,
✓ prazo,
✓ e custos
Processo 
executado
e gerenciado 
com uma 
adaptação de
um processo 
padrão 
definido, eficaz
e eficiente
Processo 
geralmente
atinge os 
objetivos,
porém sem
padrão de 
qualidade
e sem controle
de prazos e 
custos
5
Otimizando
4
Previsível
3
Estabelecido
2
Gerenciado
1
Executado
0
Incompleto
Processo não 
existe ou falha 
em atingir seus 
objetivos
Processo
melhorado
continuamente 
de forma 
disciplinada
ISO 15504: Níveis de Capacidade
17
Programa da Aula
• Qualidade de Processo de Software
• Norma ISO/IEC 12207
• Norma ISO/IEC 15504
• CMMI
• MPS.Br
CMMI (Capability Maturity Model Integration)
• É um modelo que descreve orientações para a 
definição e implantação de processos.
• O modelo não descreve processo algum, são 
orientações definidas através das práticas 
especificadas.
• 22 Áreas de Processo (disciplinas)
18
CMMI (Capability Maturity Model Integration)
• Criado pelo SEI (Software Engineering Institute) em 
1991 por solicitação do Departamento de Defesa dos 
EUA para avaliação da capacidade de seus 
fornecedores.
• Inicialmente o modelo focava apenas no software
– Chamado de CMM
Por que a utilização de modelos de 
qualidade como o CMMI tiveram grande 
adoção?
• Tendência cada vez maior que as empresas que não 
tenham a TI como sua atividade fim de passar o 
desenvolvimento de software para fornecedores externos
– Fábricas de Software
– Fábricas de Teste
• Governo brasileiro adotando a obrigatoriedade da empresa 
fornecedora de estar em conformidade com o modelo
• Processo de Certificação/Auditoria
– É caro!
• Indústria de consultoria, auditoria e certificadora
– As vezes o modelo só é seguido quando a auditoria está sendo 
feita.
19
Fluxo Típico de Desenvolvimento com 
Fábrica de Software
Engenharia de Software
OrganizaçãoCliente
Fábrica 
de Software
Requisitos
Especificações 
de Software
Verificação das
Especificações
Código Executável
Verificação e Validação (Homologação)
Terceirização - Fábrica de Testes
• A Fábrica de Testes deve gerenciar todas as demandas 
de testes e inspeções e estabelecer modelos que 
suportem tanto os testes manuais quanto os 
automatizados, estabelecendo uma metodologia única 
de testes, independente da tecnologia empregada.
• A Fábrica de Testes irá trabalhar verificando e validando 
os artefatos produzidos pela Fábrica de Software.
Engenharia de Software
20
Fluxo Típico de Desenvolvimento com 
Fábrica de Software
Engenharia de Software
Organização 
Cliente
Fábrica de Software
Requisitos
Especificações 
de Software
Verificação das
Especificações
Verificação
Fábrica de Testes
Código Executável
Validação (Homologação)
Requisitos
Ranking CMMI (Maturity Profile 09/2015)
21
Páises com organizações CMMI nível 5
CMMI – O Processo de Avaliação no Brasil
Total de Empresas Certificadas no Brasil por nível (2014)
22
CMMI – Investimento e Tempo de Maturação
• O investimento médio para adequação dos processos 
às práticas do CMMI é de R$ 250 mil, mas existe 
variação do investimento de acordo com os cenários 
avaliados. 
• No Brasil, esse valor já oscilou entre R$ 150 mil e R$ 
1,5 milhões. 
• O tempo médio para chegar a um nível de maturidade 
oscila entre 12 e 45 meses (tanto o investimento 
quanto o tempo variam de acordo com o porte da 
unidade avaliada e o nível de maturidade almejado).
 3 modelos divididos em áreas de conhecimento:
 CMMI for Development - (CMMI-DEV), voltado ao 
processo de desenvolvimento de produtos e serviços.
 CMMI for Services (CMMI-SVC), voltado aos processos 
de aquisição e terceirização de bens e serviços.
 CMMI for Acquisition (CMMI-AQU), voltado aos 
processos de empresas prestadoras de serviços.
CMMI (Capability Maturity Model Integration)
23
CMMI (Capability Maturity Model Integration)
• É definido em termos de áreas de Processo (PAs):
– Ex: Planejamento de Projeto, Monitoração e Controle de 
Projetos, etc.
• Cada área de processos (PA) é definida em termos de 
Objetivos Específicos (SGs) e Práticas Específicas (SPs) 
que são necessárias para satisfazê-los.
• 22 Áreas de Processo (disciplinas)
CMMI (Capability Maturity Model Integration)
24
 Áreas de Processo de Engenharia:
 Gerência de Requisitos (REQM)
 Desenvolvimento de Requisitos (RD)
 Solução Técnica (TS)
 Integração do Produto (PI)
 Verificação (VER)
 Validação (VAL)
CMMI (Capability Maturity Model Integration)
 Áreas de Processo de Gerência de Projetos:
 Planejamento de Projeto (PP)
 Monitoração e Controle de Projeto (PMC)
 Acordo com Fornecedores (SAM)
 Gerência Integrada do Projeto (IPM)
 Gerência de Riscos (RSKM)
 Gerência Quantitativa do Projeto (QPM)
CMMI (Capability Maturity Model Integration)
25
 Áreas de Processo de Gerência de Processos:
 Definição do Processo Organizacional (OPD)
 Foco no Processo Organizacional (OPF)
 Treinamento Organizacional (OT)
 Desempenho do Processo Organizacional (OPP)
 Implantação de Inovações na Organização (OID)
CMMI (Capability Maturity Model Integration)
 Áreas de Processo de Suporte (Guarda-Chuva):
 Garantia da Qualidade do Processo e do Produto 
(PPQA)
 Gerência de Configuração (CM)
 Medição e Análise (MA)
 Análise de Decisão e Resolução (DAR)
 Análise de Causas e Resolução (CAR)
CMMI (Capability Maturity Model Integration)
26
CMMI (Capability Maturity Model Integration)
• Exemplo – Área de Processo / Objetivo Específico / Prática Específica
– Planejamento do Projeto
• OE 1 Estabelecer Estimativas 
– PE 1.1 Estime o escopo do projeto
– PE 1.2 Estabeleça estimativas de produto do trabalho e atributos de tarefas
– PE 1.3 Defina o ciclo de vida do projeto
– PE 1.4 Determine estimativas de esforço e custo
• OE 2 Desenvolver um Plano do Projeto
– PE 2.1 Estabeleça o orçamento e o cronograma
– PE 2.2 Identifique os riscos de projeto
– PE 2.3 Planeje a gestão de dados
– PE 2.4 Planeje a gestão de recursos
CMMI – Duas formas de Avaliação / 
Representação por Estágio x Contínua
• Por Estágios
– 5 Níveis de Maturidade (nível 1 ao 5)
– Agrupamento de Áreas de Processo por Nível
– Avaliação da Organização / Unidade Organizacional como um 
todo
• Contínua
– Níveis de Capacidade (nível 0 ao 5)
– Agrupamento de Áreas de Processo por Categoria
– Avaliação da Capacidade nas Áreas de Processo
• As PAs do CMMI são as mesmas para ambas as 
representações.
27
Representações por Estágio x Contínua
Em Estágios
NM1
NM2
NM3
NM4
NM5
Um conjunto de áreas de 
processo de um nível de 
maturidade (NM).
PA PA
C
a
p
a
c
id
a
d
e
PA
Contínua
Uma única área de processo 
(PA) ou um conjunto de áreas 
de processo.
Representação por Estágios
Nível de Maturidade
• Um nível de maturidade é um patamar evolutivo bem 
definido, que visa a alcançar um processo de software 
maduro. 
• Os níveis são uma forma de priorizar as ações de 
melhoria, de tal forma que se aumente a maturidade 
do processo de software. 
• No nível 2 por exemplo, são focados aspectos 
gerenciais dos projetos.
28
• O conceito de maturidade é baseado na noção de que 
alguns processos provêm mais estrutura e controle do que 
outros.
CMMI – Níveis de Maturidade
Processo continuamente 
melhorado
Processo previsível e controlado
Processo consistente e padronizado
Processo disciplinado
1- Inicial
2- Repetível
3- Definido
4- Gerenciado
5- Otimizado
Processo imprevisível e sem controle
CMMI: Nível 1 (Inicial)
entrada saída
• O processo de software é caracterizado como sendo 
imprevisível e ocasionalmente caótico.
• Poucos processos são definidos e o sucesso 
depende de esforços individuais e, muitas vezes, 
heroicos.
• O processo de software é uma caixa preta, de forma 
que somente as entradas e os produtos finais 
podem ser vistos com clareza. 
29
CMMI: Nível 1
• Organizações no nível 1 apresentam deficiências de 
planejamento e enfrentam dificuldades ao realizarem previsões.
• Cronogramas e planos são irrealistas.
• Como não há credibilidade no planejamento, mesmo aquilo que 
foi planejado não é seguido.
• Não há controle de requisitos e o cliente só os avalia na entrega 
do produto.
• É comum passar diretamente dos requisitos à codificação.
• A documentação é encarada como algo inútil.
• São comuns reações intransigentes à coleta de dados e ao uso 
de padrões, documentação e ferramentas.
CMMI: Nível 2 (Repetível)
entrada saída
• Processos básicos de gerência de projetos são 
estabelecidos para controle de custos, prazos e escopo.
• É possível repetir sucessos de projetos anteriores em 
aplicações similares.
• Ao invés do processo ser uma única caixa preta, ele 
passa a ser uma sequência de caixas pretas que 
asseguram a visibilidade em determinados pontos, os 
marcos do projeto.
30
CMMI: Nível 2
• Neste nível, organizações têm maior probabilidade de cumprir 
compromissos de requisitos, prazos e custos, mas desde que 
sejam semelhantes a outros realizados anteriormente.
• A organização é disciplinada, mas não está bem preparada para 
mudanças.
• Há preocupação com a gerência do projeto. Os gerentes 
acompanham custos, cronogramas e funcionalidades de cada 
um dos projetos. Porém, a gerência ainda não é proativa, 
tomando ações normalmente quando se está diante de uma 
crise.
• Os projetos podem ter processos diferentes. No entanto, existe 
uma política para guiar os projetos no estabelecimento dessesprocessos.
• Controla-se a evolução dos requisitos, permitindo avaliações ao 
final de cada marco do projeto, e controla-se, também, a 
evolução das configurações do software.
CMMI: KPAs do Nível 2
• Gerência de Requisitos
• Planejamento de Projetos
• Supervisão e Acompanhamento de Projetos
• Gerência da Subcontratação de Software
• Garantia da Qualidade de Software
• Gerência de Configuração de Software 
31
CMMI: Nível 3 (Definido)
entrada saída
• Um processo de software, composto por atividades de 
gerência e engenharia, é documentado, padronizado e 
integrado em um processo de software padrão da 
organização.
• Todos os projetos utilizam uma versão aprovada e adaptada 
do processo organizacional para desenvolvimento e 
manutenção de software.
• A organização interna das tarefas está definida e visível 
CMMI: Nível 3
• Processos utilizados são estabelecidos e padronizados em toda a 
organização.
• Os processos pertencem à organização e não aos projetos.
• O Grupo de Processos (Software Engineering Process Group - SEPG) é 
responsável pelos processos da organização.
• Apesar da padronização, é possível adaptar os processos para as 
necessidades particulares de um projeto.
• Processos de engenharia de software são considerados ao lado dos processos 
gerenciais.
• Há treinamento técnico e gerencial.
• A organização consegue se manter dentro do processo mesmo em períodos 
de crise.
• Como o processo é bem definido, caso um desenvolvedor abandone o 
projeto antes de seu término, o impacto é relativamente menor que nos 
níveis anteriores.
• Passagem do nível 2 para o 3: a padronização realizada é a oportunidade de 
escolher as melhores práticas existentes na organização.
32
CMMI: KPAs do Nível 3
• Foco no Processo da Organização 
• Definição do Processo da Organização 
• Programa de Treinamento 
• Gerência de Software Integrada 
• Coordenação entre grupos 
• Engenharia de Produtos de Software 
• Revisão por Pares 
CMMI: Nível 4 (Gerenciado)
entrada saída
• Métricas detalhadas do processo de software e da 
qualidade do produto são coletadas.
• Tanto o processo como o produto de software são 
quantitativamente compreendidos e controlados.
33
CMMI: Nível 4
• A organização estabelece metas quantitativas de qualidade e 
produtividade para as atividades do processo e para os produtos 
produzidos são estabelecidas para cada projeto.
• Medidas de qualidade e produtividade são coletadas em todos 
os projetos como parte de um processo organizacional de 
medição e estabelecem uma base quantitativa para que os 
gerentes possam avaliar o progresso do desenvolvimento e a 
ocorrência de problemas.
• Os projetos melhoram o seu controle sobre os produtos e 
processos e a variância das medidas é diminuída.
• É estabelecido o controle estatístico de processos.
• Uma organização no nível 4 passa a ter uma gestão feita com 
bases quantitativas.
CMMI: KPAs do Nível 4
• Gerência Quantitativa dos Processos
• Gerência da Qualidade de Software
34
CMMI: Nível 5 (Otimizado)
entrada saída
• A melhoria contínua do processo é estabelecida por 
meio de sua avaliação quantitativa, e da implantação 
planejada e controlada de tecnologias e idéias 
inovadoras.
CMMI: Nível 5
• A organização está engajada na melhoria contínua de seus 
processos, possuindo meios para identificar fraquezas e 
fortalecer o processo de forma proativa, prevenindo defeitos.
• O entendimento do processo ultrapassa os processos praticados, 
possibilitando compreender os efeitos de alterações potenciais 
no processo.
• Melhorias em processos e tecnologias são planejadas e 
executadas como parte das atividades de rotina.
• Mudanças mais significativas de processos ou de tecnologias são 
feitas a partir de análises de custo / benefício com base em 
dados quantitativos cuja coleta iniciou-se no nível 4.
35
CMMI: KPAs do Nível 5
• Prevenção de Defeitos 
• Gerência da Evolução dos Processos 
• Gerência da Evolução das Tecnologias 
CMMI – Representação por Estágios
Níveis de Maturidade
36
Áreas de Processo por Cada Estágio
Representação Contínua: Motivação
• A abordagem estagiada representa que uma organização deverá 
cumprir todos os objetivos específicos de uma área de processo
– Exemplo: Área de Processo de Desenvolvimento de Requisitos
• Estabelece 6 Níveis de Capacidade
• Cada Área de Processo existem Metas Específicas e Genéricas e 
para cada uma é definida os níveis de capacidade
37
Representação Contínua: Estrutura
Generic Practices
Generic Goals
Process Area 2Process Area 1 Process Area n
Specific Goals
Specific Practices Práticas Genéricas
Metas Genéricas
Área de Processo 2Área de Processo 1 Área de Processo n
Metas Específicas
Práticas Específicas
Níveis de Capacidade
Representação Contínua
• Um nível de capacidade descreve a capacidade de uma 
área de processo.
• Há seis níveis de capacidade, cada um representando 
uma camada na base para a melhoria contínua do 
processo.
• Assim, níveis de capacidade são cumulativos, ou seja, 
um nível de capacidade mais alto inclui os atributos 
dos níveis mais baixos.
• Uma vez que os modelos CMMI são projetados para 
descrever níveis discretos de melhoria de processo, 
níveis de capacidade provêm uma ordem recomendada 
para abordar a melhoria de processo dentro de cada 
área de processo.
38
Representação Contínua: Vantagens
• Fornece maior flexibilidade focando em áreas de 
processo específicas de acordo com metas e objetivos 
de negócio
• Permite a comparação de áreas de processo entre 
diferentes organizações
• Foco bem definido nos riscos específicos de cada área 
de processo
• Estrutura compatível com a ISO/IEC 15504
Representação Contínua
5 Otimizado
4 Gerenciado Quantitativamente
3 Definido
2 Gerenciado
1 Realizado
0 Incompleto
Níveis de Capacidade
39
Exercício
• Considerando o cenário abaixo, discuta quais áreas de 
processos do CMMI são mais necessárias nesta empresa? 
Dica: foque no Nível 2 de maturidade por estágios.
– A empresa faz o levantamento dos requisitos com o cliente 
tentando esclarecer todas as ambiguidades. 
– Após a fase de levantamento dos requisitos, o projeto passa para a 
fase de codificação. 
– Ao final da codificação e geração do executável, o projeto é 
testado. 
– Só após o teste, o cliente é acionado novamente para a entrega do 
código gerado. 
– Durante a fase de codificação e após verificar um atraso no 
cronograma, mais profissionais foram incluídos na equipe e parte 
do projeto foi terceirizada. 
– Após a codificação do produto, toda a equipe foi deslocada para o 
desenvolvimento de outro projeto. 
Programa da Aula
• Qualidade de Processo de Software
• Norma ISO/IEC 12207
• Norma ISO/IEC 15504
• CMMI
• MPS.Br
40
MPS.Br - Motivação
• Em 2003, dados da Secretaria de Política de 
Informática do MCT apontavam que apenas 30 
empresas no Brasil possuíam avaliação CMM e 214 
possuíam certificação ISO 9001.
• Claramente, as empresas locais favoreceram a ISO 
9000.
• Dados de uma pesquisa do MIT 1, apontavam que até 
2003, na Índia 32 empresas atingiram o nível 5 do 
CMM, enquanto a China tinha apenas uma e o Brasil 
nenhuma.
• Em relação ao CMM, a maioria das empresas chinesas 
e brasileiras não estava em um nível suficientemente 
alto de maturidade do processo para competir com as 
empresas indianas.
1 Ref: Slicing the Knowledge-based Economy in Brazil, China and India: 
a tale of 3 software industries [MIT, 2003]
Como atingir níveis de maturidade CMMI 
no Brasil?
Empresas 
exportadoras 
e grandes
Níveis de maturidade CMMI 4 e 5
Custo não é crítico – 4 a 10 anos
Pequenas emédias
Níveis de maturidade 2 e 3
Custo é crítico – 2 a 3 anos
41
MPS.Br
• Objetivo: 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
• Criado em 2005 com foco nas pequenas e 
médias empresas brasileiras.
• Objetivo: fornecer um caminho viável para a 
implementação e avaliação de melhoria de 
processo.
• Mantido por equipe técnica composta de 
pessoas da indústria, academia e governo.
MPS.BR
42
MPS.Br
MPS.BR
Realidade das 
Empresas Brasileiras
ISO /IEC 12207
ISO /IEC 15504
CMMI
SOFTEX
Governo
Universidades
Base Técnica
CMMI X MPS.BR
• 7 níveis de maturidade, o que possibilita uma implantação 
mais gradual e uma maior visibilidade dos resultados de 
melhoria de processo, com prazos mais curtos.
• Compatibilidade com CMMI, conformidade com as normas 
ISO/IEC 15504 e 12207.
• Adaptado para a realidade brasileira (foco em micro, 
pequenas e médias empresas).
• Custo acessível (em R$)
43
Estrutura do Modelo MPS.Br
Programa
MPS.BR 
Modelo de 
Negócio 
(MN-MPS) 
Método de 
Avaliação 
(MA-MPS) 
Guia de Aquisição Guia Geral
Modelo de 
Referência 
(MR-MPS) 
Guia de Avaliação Documento do Programa
ISO/IEC 12207
Guias de Implementação 
ISO/IEC 15504CMMI-DEV
Modelo de Referência: MR-MPS
• Contém as definições dos níveis de maturidade, 
processos (com propósitos e resultados esperados) e 
atributos do processo (com resultados esperados).
• As atividades e tarefas necessárias para atender ao 
propósito e aos resultados esperados de um processo 
não são definidas, ficando a cargo dos usuários do MR-
MPS.
44
Níveis de Maturidade
• São uma combinação entre processos e sua 
capacidade.
• O progresso e o alcance de um determinado nível de 
maturidade do MR-MPS se obtém quando são 
atendidos os propósitos e todos os resultados 
esperados dos respectivos processos e dos atributos de 
processo estabelecidos para aquele nível.
• Os níveis de maturidade estabelecem patamares de 
evolução de processos, caracterizando estágios de 
melhoria da implementação de processos na 
organização.
Níveis de Maturidade
• O MR-MPS define sete níveis de maturidade:
– A. Em Otimização
– B. Gerenciado Quantitativamente
– C. Definido
– D. Largamente Definido
– E. Parcialmente Definido
– F. Gerenciado
– G. Parcialmente Gerenciado
45
Equivalência com CMMI
Níveis de Maturidade
Nível MPS.BR Nível CMMI
G
2
F
E
3
D
C
B 4
A 5
Equivalência com CMMI
Níveis de Maturidade
• A divisão em estágios, embora baseada nos níveis de 
maturidade do CMMI-DEV, tem uma graduação 
diferente, com o objetivo de possibilitar uma 
implementação e avaliação mais adequada às micros, 
pequenas e médias empresas. 
• A possibilidade de se realizar avaliações considerando 
mais níveis também permite uma visibilidade dos 
resultados de melhoria de processos em prazos mais 
curtos.
46
Níveis de Maturidade e Processos
Garantia da Qualidade / Medição
Aquisição / Gerência de Configuração
Avaliação e Melhoria do Processo Organizacional / Definição do
Processo Organizacional / Gerência de Recursos Humanos /
Gerência de Reutilização / Gerência de Projetos (evolução)
Desenvolvimento de Requisitos / Integração do Produto/ Projeto
e Construção do Produto / Verificação / Validação
Análise de Decisão e Resolução / Gerência de Reutilização
(evolução) / Desenvolvimento para Reutilização / Gerência de
Riscos
G
F
E
D
C
Gerência de Requisitos
Gerência de Projeto
Gerência de Projeto (evolução)
Análise de Causas de Problemas e Resolução
A
B
Parcialmente 
Gerenciado
Gerenciado
Parcialmente 
Definido 
Largamente 
Definido 
Definido 
Gerenciado 
Quantitativamente 
Em Otimização 
Estrutura do MR-MPS
• Estrutura
– Cada processo é composto de um propósito e de resultados 
esperados de sua execução, o que permite avaliar e atribuir 
graus de efetividade na execução do processo.
– A capacidade do processo está relacionada ao atendimento 
dos atributos de processo associados aos processos de cada 
nível de maturidade.
47
Capacidade do Processo
• Expressa o grau de refinamento e institucionalização 
com que o processo é executado na organização / 
unidade organizacional.
• Está relacionada com o atendimento aos atributos de 
processo associados aos processos de cada nível de 
maturidade.
• À medida que a organização / unidade organizacional 
evolui nos níveis de maturidade, um maior nível de 
capacidade para desempenhar o processo deve ser 
atingido pela organização.
Capacidade e Atributos de Processo
• Atributos de Processo (AP):
– AP 1.1 – O processo é executado
– AP 2.1 – O processo é gerenciado
– AP 2.2 – Os produtos de trabalho do processo são 
gerenciados
– AP 3.1 – O processo é definido
– AP 3.2 – O processo está implementado
– AP 4.1 – O processo é medido
– AP 4.2 – O processo é controlado
– AP 5.1 – O processo é objeto de inovações
– AP 5.2 – O processo é otimizado continuamente
Introduzidos na Versão 1.2
48
Níveis de 
Maturidade 
e 
Capacidade
Exemplo – Resultados Esperados para o 
Nível G – Parcialmente Gerenciado 
Nível Processos Capacidade
G
Gerência de Projetos
Resultados: GPR 1 a GPR 17
GPR 4, 10 e 13 (até o Nível F)
AP 1.1 e AP 2.1
Resultados: 
RAP 1 a RAP 8
sendo RAP 4 (G)
Gerência de Requisitos
Resultados: GRE 1 a GRE 5
49
Exemplo
Nível G: Gerência de Projetos
• Resultados Esperados (GPR 1 a GPR 9):
1. O escopo do trabalho para o projeto é definido.
2. As tarefas e os produtos de trabalho do projeto são dimensionados 
utilizando métodos apropriados.
3. O modelo e as fases do ciclo de vida do projeto são definidas. 
4. O esforço e o custo para a execução das tarefas e dos produtos de 
trabalho são estimados com base em dados históricos ou referências 
técnicas.
5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos 
de controle, são estabelecidos e mantidos.
6. Os riscos do projeto são identificados e o seu impacto, probabilidade de 
ocorrência e prioridade de tratamento são determinados e 
documentados.
7. Os recursos humanos para o projeto são planejados considerando o 
perfil e o conhecimento necessários para executá-lo.
8. As tarefas, os recursos e o ambiente de trabalho necessários para 
executar o projeto são planejados.
9. Os dados relevantes do projeto são identificados e planejados quanto à 
forma de coleta, armazenamento e distribuição. Um mecanismo é 
estabelecido para acessá-los, incluindo, se pertinente, questões de 
privacidade e segurança.
Exemplo
Nível G: Gerência de Projetos
• Resultados Esperados (GPR 10 a GPR 17): 
10. Planos para a execução do projeto são estabelecidos e reunidos no 
Plano do Projeto.
11. A viabilidade de atingir as metas do projeto, considerando as restrições 
e os recursos disponíveis, é avaliada. Se necessário, ajustes são 
realizados.
12. O Plano do Projeto é revisado com todos os interessados e o 
compromisso com ele é obtido.
13. O progresso do projeto é monitorado com relação ao estabelecido no 
Plano do Projeto e os resultados são documentados.
14. O envolvimento das partes interessadas no projeto é gerenciado.
15. Revisões são realizadas em marcos do projeto e conforme estabelecido 
no planejamento.
16. Registros de problemas identificados e o resultado da análise de 
questões pertinentes, incluindo dependências críticas, são 
estabelecidos e tratados com as partes interessadas.
17. Ações paracorrigir desvios em relação ao planejado e para prevenir a 
repetição dos problemas identificados são estabelecidas, 
implementadas e acompanhadas até a sua conclusão.
50
Exemplo
Nível G: Gerência de Requisitos
• Resultados Esperados (GPR 1 a GPR 5): 
1. O entendimento dos requisitos é obtido junto aos fornecedores de 
requisitos;;.
2. Os requisitos de software são aprovados utilizando critérios objetivos;
3. A rastreabilidade bidirecional entre os requisitos e os produtos de 
trabalho é estabelecida e mantida;;
4. Revisões em planos e produtos de trabalho do projeto são realizadas 
visando identificar e corrigir inconsistências em relação aos requisitos.
5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
Diferenciais do MPS.BR
• 7 níveis de maturidade, o que possibilita uma 
implantação mais gradual e uma maior visibilidade dos 
resultados de melhoria de processo, com prazos mais 
curtos.
• Compatibilidade com CMMI, conformidade com as 
normas ISO/IEC 15504 e 12207.
• Adaptado para a realidade brasileira (foco em micro, 
pequenas e médias empresas).
• Custo acessível (em R$)
51
Referências Bibliográficas
• KOSCIANSKI, A. e SOARES, M. S. 
Qualidade de Software. NOVATEC.
• PRESSMAN, R. S. Engenharia de 
Software. McGraw Hill,
• Notas de Aula do Prof. David 
Zanetti, Qualidade de Software -
Unicarioca