1.
Qualidade de Software:
Produto e Processo
Conceitos, ISO, CMMI e MPS.Br
Reinaldo de Oliveira Castro
Tiago Antônio da Silva
Victor Gomes da Silva

2.
Roteiro
● Conceitos
● Histórico
○ Crise do software
● Qualidade de software
○ Produto e processo
● ISO
● CMMI
● MPS.Br
● Referências

3.
Questão sobre qualidade
Por que qualidade de software?
1. Aumento da complexidade
2. Atender as especificações do cliente
3. Concorrência
4. Confiabilidade dos resultados

4.
Conceitos de qualidade
Conformidade com requisitos funcionais e de
desempenho explicitamente declarados,
normas de desenvolvimento explicitamente
documentadas e características implícitas, que
são esperadas em todo software desenvolvido
profissionalmente.
(PRESSMAN, p. 580, 2006)

5.
Conceitos de qualidade
É um conceito complexo que não é
diretamente comparável com a qualidade na
manufatura.
(SOMMERVILLE, p.423, 2007)
Na manufatura, a noção de qualidade tem
sido aquela em que o produto desenvolvido
deve atender às suas especificações.
(CROSBY, 1979)

6.
Histórico
● Crise do software
● Engenharia de software era raridade
● Dificuldades no desenvolvimento
● Alta demanda
● Prazos e orçamentos sempre estouravam
● Baixa qualidade
● Não atingiam requisitos
Por quê?

7.
Histórico

8.
Qualidade de produto
● Baixo número de defeitos
● Atinge padrões necessários?
Ex: manutenção, confiabilidade, etc...
● Diretamente proporcional a qualidade do
processo de desenvolvimento
Ex: linha de produção

9.
Qualidade de Produto
● ISO/IEC 9126: norma para qualidade de
produto de software.
● O modelo propõe a analise de um produto de
software por meio de atributos de
qualidade.

10.
Qualidade de produto
● ISO/IEC 9126: divisão das características e
sub-características

11.
Qualidade de produto
● Funcionalidade
○ As funcionalidades desejadas pelo usuário, explícitas
ou implícitas, foram atendidas?
● Confiabilidade
○ O produto se mantém confiável (sem perda de
dados, recuperando-se de falhas, etc) em situações
adversas?
● Usabilidade
○ O software é intuitivo e fácil de usar pelo usuário?

12.
Qualidade de produto
● Eficiência
○ O software se comporta como esperado em relação
às restrições de tempo e recurso?
● Manutenabilidade
○ O software é flexível para suportar as manutenções
corretivas, evolutivas e perfectivas?
● Portabilidade
○ O sistema pode ser facilmente transferido de um
sistema para outro?

13.
Principais fatores de qualidade de
produto
(SOMMERVILLE, 2007)

14.
Qualidade de processo

15.
Qualidade do produto baseada em
processo
(SOMMERVILLE, 2007)

16.
Qualidade de processo
A qualidade do processo corresponde ao nível
utilizado na implementação de um processo
aceitável e na produção dos artefatos. Esse
processo inclui medições e critérios de
qualidade.

17.
Características de processo
● Facilidade de compreensão
● Visibilidade
● Facilidade de apoio
● Aceitabilidade
● Robustez
● Facilidade de manutenção
● Rapidez
(SOMMERVILLE, p. 440, 2007)

18.
Ciclo de aprimoramento do processo
(SOMMERVILLE, 2007)

19.
ISO's
ISO - International Organization for
Standardization
9000 - Padrões de qualidade gerais para
qualquer tipo de organização
9001 - Mais específica: processo de qualidade
nas organizações que projetam, desenvolvem e
mantêm produtos

20.
ISO 9001
Quatro seções principais:
1. Objetivos
2. Relações com outras normas
3. Definições
4. Requisitos do sistema de qualidade

21.
ISO 9001: requisitos do sistema de
qualidade
4.1: requisitos de natureza organizacional e
institucional
4.2: requisitos da documentação do Sistema
da Qualidade
4.3 a 4.20: demais requisitos como
especificação, projeto, documentos e dados,
aquisição, rastreabilidade, processos, testes,
produto não-conforme, ação corretiva, manuseio,
registros, auditorias, treinamento, serviços,
técnicas estatísticas

22.
ISO 9000-3
Orientações para aplicação da ISO 9001 ao
projeto, desenvolvimento, fornecimento,
instalação de manutenção de software.
● 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.

23.
ISO 9000-3
Definições sobre o planejamento da qualidade
de software:
● Definição do ciclo de vida utilizado
● Definição dos critérios para início e fim de
cada fase de projeto
● Identificação dos tipos de análise crítica
● Identificação dos procedimentos de gestão
de configuração, validação, verificação e
teste

24.
ISO 9000-3
● Não tem melhoria continua de processo
como o CMM.
● Não diz como fazer, somente o quê tem que
ser feito.
● Qualidade do processo não do produto.

25.
Estado da Arte ISO
Software Quality Engineering in the new ISO standard:
ISO/IEC 24748 - Systems and software engineering - Guide
for life cycle management (2012)
Problema: ISO não está de acordo com o que o mercado precisa.
Objetivo: Investigar a ISO em questão do ciclo de vida e mostrar que não é
suficiente para ter um software de qualidade usando o processo que ela
descreve.
Solução: Adicionar conceitos de Engenharia de Software baseados na qualidade
para aprimorar e melhorar a norma. Baseadas nas normas da IEEE e ISO/IEC.
Resultado: A Engenharia de software é quase totalmente ausente nesse novo
padrão da ISO.

26.
Estado da Arte ISO
Do Software Process Improvements Lead to ISO 9126
Architectural Quality Factor Improvement? (2010)
Problema: Pesquisas não são voltadas para a melhoria da arquitetura e sim para
melhoria dos processos e definições de qualidade. Qualidade do processo
CMMI tem uma ligação muito fraca com a ISO 9126.
Objetivo: Fazer a revisão sistemática e orientar para um trabalho futuro,
considerando a arquitetura como fator de qualidade.
Solução: Criar um modelo que abrange tanto processo para melhoria de
qualidade do produto quanto a arquitetura da ISO 9126.
Resultado: A pesquisa mostrou que a arquitetura definida pela ISO influência
diretamente na qualidade do produto e ajudaria no processo do CMMI.

27.
Estado da Arte ISO
Applying ISO 9001:2000, MPS.BR and CMMI to Achieve
Software Process Maturity: BL Informatica’s Pathway (2010)
Problema: Como utilizar uma um desses processos para incorporar o modelo de
maturidade em micro e pequenas empresas.
Objetivo: Estudar os processos, compará-los e reduzir esses processos para
aplicar em pequenas empresas.
Solução: Aplicar os processos modificados na empresa.
Resultado: Os processos modificados resultaram em baixa qualidade do
produto desenvolvido negando a viabilidade de reduzir os processos de
qualidade e reafirmando que a qualidade do produto esta ligada com a
qualidade do processo.

28.
Estado da Arte ISO
Process Assessment Issues of the ISO/IEC 29110 emerging
standard (2011)
Problema: Talvez o novo padrão de ciclo de vida de processo da ISO não seja
eficiente para pequenas empresas.
Objetivo: Avaliar o processo da ISO /IEC 29110
Solução: Criar um modelo exemplar de avaliação de processos (PAM) e avaliar
o processo ISO baseado no PRM (Process Reference Model)
Resultado: Criou o modelo exemplar, mas não sitou testes com a ISO/IEC
29110

29.
Ferramentas
ARM - Nasa - fornece medidas que podem ser
usadas para avaliar a qualidade de um
documento de requisitos de software.
QPR ProcessGuide and Scorecard, desenvolvida
por QPRSoftware, fornece apoio para Seis
Sigma e outras abordagens de gestão de
qualidade

30.
Ferramentas
Quality Tools Cookbook, desenvolvida por
Sysma e Manley, fornece descricões úteis de
ferramentas de gestão clássica de qualidade tal
como diagramas de controle, espalhamento,
afinidade e matriciais.
Quality Tools and Templates, desenvolvida por
iSixSigma, descreve uma ampla gama de
ferramentas e métodos úteis para gestão de
qualidade.

31.
CMMI - Definição
● CMMI: Capability Maturity Model
Integration
● Modelo de referência que contém as
melhores práticas (genéricas ou específicas)
necessárias ao desenvolvimento e
manutenção de produtos e serviços,
englobando todo o ciclo de vida (desde
concepção até a entrega e manutenção).

32.
CMMI - Corpo de conhecimento
● O corpo de conhecimento (body of
knowledge) é dividido em disciplinas:
○ System Engineering (SE)
○ Software Engineering (SW)
○ Integrated Product and Process Development
(IPPD)
○ Supplier Sourcing (SS)
Uma disciplina é formada por áreas de
processos.

33.
CMMI - Estrutura dos elementos

34.
CMMI - Estrutura dos elementos
Gerenciamento de
requisitos

35.
CMMI - Estrutura dos elementos
O objetivo do Gerenciamento de Requisitos (REQM) é
gerenciar os requisitos dos produtos do projeto (e dos
componentes do produto) e identificar inconsistências
entre estes requisitos e os planos e produtos de trabalho
do projeto.

36.
CMMI - Estrutura dos elementos

37.
CMMI - Estrutura dos elementos
Referencie a área de processo Planejamento de Projeto
para maiores informações sobre como planos de projeto
são baseados nos requisitos e precisam ser revisados
com as mudanças destes. (...)

38.
CMMI - Estrutura dos elementos
SG1 - Gerenciar requisitos

39.
CMMI - Estrutura dos elementos
SP 1.1 Obter e entender os requisitos.
SP 1.2 Obter comprometimento em relação aos requisitos.
SP 1.3 Gerenciar mudanças de requisitos.
SP 1.4 Manter rastreabilidade bidirecional dos requisitos.
SP 1.5 Indentificar inconsistências entre requisitos e
planos/produtos de projeto.

40.
CMMI - Estrutura dos elementos
● Estabelecer critérios para avaliação e aceitação de requisitos.
● Analisar os requisitos para garantir que os critérios foram
alcançados.
● Chegar em um entendimento sobre os requisitos com o provedor
dos requisitos para garantir o comprometimento do restante dos
participantes do projeto.

41.
CMMI - Estrutura dos elementos
● Lista de critérios para avaliação e aceitação de
requisitos.
● Resultado da análise em relação aos critérios.
● Documento de aceitação dos requisitos por ambas
as partes.

42.
CMMI - Estrutura dos elementos

43.
CMMI - Estrutura dos elementos

44.
CMMI - Estrutura dos elementos

45.
CMMI - Níves de maturidade

46.
CMMI - Representação Staged
Legenda: todas as áreas de processo.

47.
CMMI - Representação Continuous
Legenda: uma ou mais áreas de processo.

48.
CMMI - Estado da arte
Uso de Práticas Ágeis para Alcançar o CMMI 5: Uma
Abordagem Inovadora (1/2)
Problema enfrentado no artigo: dificuldade de integração entre os
métodos ágeis e os modelos de maturidade.
Objetivo do artigo: descrever como essa integração foi possível na área de
processo Inovação e Desenvolvimento Organizacional, utilizando o método
Define, Measure, Analyse, Design and Verify (DMADV) definido na
metodologia Six Sigma.

49.
CMMI - Estado da arte
Uso de Práticas Ágeis para Alcançar o CMMI 5: Uma
Abordagem Inovadora (2/2)
Conclusões após a leitura:
1a.) Título dá maior amplitude em relação ao que realmente foi abordado.
2a.) Não fez o relacionamento direto de como as práticas selecionadas estavam
atendendo os objetivos específicos da área de processo.

50.
CMMI - Estado da arte
Is Process Compliance a Driver for Project Success? (1/5)
Problema enfrentado no artigo: descobrir formalmente até que ponto o
cumprimento de processos em uma organização influencia os resultados de um
projeto.
Objetivo do artigo: tratar um projeto como um sistema, representando-o por
meio de um "modelo de função de transferência", listando as entradas/saídas e
correlacionando estatisticamente as várias saídas com o cumprimento de
processos como entrada.

51.
CMMI - Estado da arte
Is Process Compliance a Driver for Project Success? (2/5)

52.
CMMI - Estado da arte
Is Process Compliance a Driver for Project Success? (3/5)

53.
CMMI - Estado da arte
Is Process Compliance a Driver for Project Success? (4/5)

54.
CMMI - Estado da arte
Is Process Compliance a Driver for Project Success? (5/5)
Conclusões após a leitura:
1a.) Sim, influencia diretamente na qualidade das saídas e consequentemente
no sucesso do projeto.
2a.) Quanto maior o cumprimento do processo maior é a redução do "barulho"
que é um fator de entrada inerente a todo projeto.

55.
CMMI - Estado da arte
Software Maintenance Productivity and Maturity (1/3)
Problema enfrentado no artigo: verificar se a aplicação de modelos de
maturidade em organizações dedicadas a manutenção de software podem
resultar em melhoria dos indicadores de manutenção corretiva e adaptativa.
Objetivo do artigo: extrair dados durante um período de 4 anos de uma
organização dedicada à manutenção de software e, em paralelo, aplicar práticas
para melhoria de processo de software, confirmando se é útil a utilização de
modelos de maturidade de software nessas organizações.

56.
CMMI - Estado da arte
Software Maintenance Productivity and Maturity (2/3)

57.
CMMI - Estado da arte
Software Maintenance Productivity and Maturity (3/3)
Conclusões após a leitura:
1a.) O gráfico deixa claro que é benéfica a implantação de modelos de
maturidade de software em organizações dedicadas à manutenção de software.

58.
CMMI - Estado da arte
Scrum and CMMI - Going from Good to Great (1/1)
Problema enfrentado no artigo: não se aplica.
Objetivo do artigo: demonstrar como a utilização de Scrum juntamente com
CMMI resultou em adaptabilidade e em predictabilidade e servir como um guia
de como adotar essa combinação em outras organizações.
Conclusões após a leitura:
1a.) Novamente, não existe um formalismo na descrição do mapeamento entre
as práticas do Scrumm e os objetivos específicos e genéricos da área de processo
planejamento de projeto.

59.
MPS.Br: Melhoria do Processo de
Software Brasileiro
● Criado pela Softex, universidades e apoiado
pelo governo.
● Mais acessível a empresas menores.
● Modelo de Referencia "Inspirado" no CMMI
(Normas ISO 12 207 e 15 504 -> Spice).
● Movimento de qualidade: garantir
sobrevivencia das empresas.
● Implementação mais gradual (7 níveis).
● Dividido em 3 partes.

60.
MPS.Br: Melhoria do Processo de
Software Brasileiro

61.
MPS.Br: Melhoria do Processo de
Software Brasileiro
1) MR-MPS: Modelo de referencia
composto por 7 níveis de maturidade
■ Cada subnível possui sua área de processo:
■ Processos fundamentais
● Exemplos: gerencia de requisitos e solução técnica.
■ Processos organizacionais
● Exemplos: gerencia de projeto e definição do processo
Organizacional.
■ Processo de apoio
● Exemplos: Garantia de qualidade e treinamento.

62.
MPS.Br: Melhoria do Processo de
Software Brasileiro

63.
MPS.Br: Melhoria do Processo de
Software Brasileiro

64.
MPS.Br: Melhoria do Processo de
Software Brasileiro
2) MA-MPS: Modelo de avaliação
● Como é feita => 1 Avaliador líder
No mínimo 1 avaliador adjunto
No mímimo 1 técnico da empresa
● Estruturando a avaliação:
○ Planejar, preparar e orientar a avaliação.
○ Conformidade com as normas.
○ Relatar, registrar e publicar os resultados.
○ Duração: 2 à 4 dias.
○ Válida por 3 anos

65.
MPS.Br: Melhoria do Processo de
Software Brasileiro
3) MN-MPS: Modelo de Negócio
● Permite que uma instituição torne-se certificadora MPS.
Br de outras instituições.
E para tal realiza-se o credenciamento em documento
(apresentação) na Softex, por exemplo.
○ Apresentado-se o "know-how" necessário, a empresa passa a
ser um agente certificador, quando apresentada as estratégias
para:
■ Implementação do modelo.
■ Seleção e treinamento de consultores.
■ Seleção e treinamento de avaliadores.
○ E ainda havendo pessoal capacitado e aprovado nas provas
específicas:
■ Consultores e avaliadores.

66.
MPS.Br: Estado da Arte (1/4)
Dificuldades e Fatores de Sucesso na
Implementação de Processos de Software
Utilizando o MR-MPS e o CMMI
Objetivo: Identificar dificuldades fatores de sucesso na implementação do
MR-MPS e CMMI.
Problema: Falta de competência, comprometimento, liderança. Erro na
estratégia de implementação.
Solução: Motivação da equipe, grau de experiência e comprometimento.
Resultado: O comprometimento dos colaboradores é um agente facilitador na
implantação dos modelos propostos.

67.
MPS.Br: Estado da Arte (2/4)
Práticas do Modelo MPS em Fábricas de Software: um estudo
exploratório sobre as percepções dos gerentes de projeto
Objetivo: Avaliar as expectativas dos gerentes de projeto sobre o modelo MPS
nas fábricas de software no Brasil.
Problema: Como o modelo MPS é visto nas fábricas de software no Brasil?
Solução: Aprimoramento ou "reciclagem" dos gerentes. Tendo em vista que
eles (gerentes) entendem a importancia do modelo (MPS).
Resultado: 44% dos entrevistados utiliza poucas vezes os modelos CMMI ou
MPS.BR, sendo que foi notada uma grande discrepancia entre os conceitos e a
implementação prática.

68.
MPS.Br: Estado da Arte (3/4)
Implementação do Nível F do MR-MPS com Práticas Ágeis
do Scrum em uma Fábrica de Software
Objetivo: Alcançar o nível F do MR-MPS em um ambiente ágil.
Problema: Quais as aobrdagens para superar os obstaculos e alcançar o nível
F do MR-MPS em um ambiente ágil?
Solução: Integração das ferramentas (Redmine e MS Project), gerando uma
primeira baseline e eliminando as baselines intermediárias, sendo que serão
geradas novas baselines ao final de cada sprint. Sendo que as auditorias
ocorreriam antes da documentação ser entregue ao cliente.
Resultado: Com ferramental adequado, não se perde qualidade do MR-MPS
com a adoção da metododologia Scrum.

69.
MPS.Br: Estado da Arte (4/4)
Influência e Impacto do Programa MPS.BR na Pesquisa
Relacionada à Qualidade de Software no Brasil
Objetivo: Identificar a influencia do MSP.BR do ponto de vista bibliográfico na
qualidade de software produzido.
Problema: Qual o impacto do MPS.BR na qualidade do software produzido no
Brasil?
Solução: Não foram identificados estudos objetivos que descreviam o MPS.BR
na qualidade de software no Brasil.
Resultado: Como demostrado anteriormente, trabalhos dedicados a
investigação da influencia do MPS.BR foram realizados.

70.
Referências
PRESSMAN, R. S. Engenharia de Software. São Paulo: McGraw-Hill, 2006.
SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Education,
2007.
CHRISSIS, M. B., KONRAD, M., SHRUM, S. CMMI: Guidelines for Process
Integration and Product Improvement. Boston: Pearson Education, 2004.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. Qualidade de
Software. São Paulo: Makron Books, 2001.
CHRISSIS, M. B., KONRAD, M., SHRUM, S. CMMI - Guidelines for
Process Integration and Product Improvement. Addison- Wesley, 2003.
CMMI Product Team. CMMI-Dev. Techinal Report, SEI, 2010.

71.
Referências
DUNTIL, D. et al. Software Quality Engineering in the new ISO
standard: ISO/IEC 24748 - Systems and software engineering -
Guide for life cycle management . Disponível em: <http://bit.
ly/HPbUVR>. Acesso em: 04 abr. 2012.
LAVALLÉE, M. et al. Do Software Process Improvements Lead to ISO
9126 Architectural Quality Factor Improvement?. Disponível em: <http:
//bit.ly/HmyunW>. Acesso em: 04 abr. 2012.
SANTOS, G. et al. Applying ISO 9001:2000, MPS.BR and CMMI to
Achieve Software Process Maturity: BL Informatica’s Pathway.
Disponível em: <http://bit.ly/HPcZ03> . Acesso em: 04 abr. 2012.
SALIOU, P. Process Assessment Issues of the ISO/IEC 29110 emerging
standard. Disponível em: <http://bit.ly/Hil4HF> . Acesso em: 04 abr. 2012.

72.
Referências
JAKOBSEN, C. R., SUTHERLAND, J. Scrum and CMMI – Going from
Good to Great. Proceedings of Agile Conference, 2009.
SHENVI, A. A. Is Process Compliance a Driver for Project Success?
Proceedings of the 5th India Software Engineering Conference, ACM, 2012.
DESHARNAIS, J., APRIL, A. Software Maintenance Productivity and
Maturity. Proceedings of the 11th International Conference on Product
Focused Software, ACM, 2010.
MARÇAL, A. S. C. et al. Uso de Práticas Ágeis para Alcançar o CMMI 5:
Uma Abordagem Inovadora. Proceedings of the IX Simpósio Brasileiro de
Qualidade de Software, 2010.

73.
Referências
ROCHA, A. R. et al. Dificuldades e Fatores de Sucesso na
Implementação de Processos de Software Utilizando o MR-MPS e o
CMMI. Disponível em: <bit.ly/HRX02S>. Acesso em: 04 abr. 2012.
MENOLLI, A. et al. Práticas do Modelo MPS em Fábricas de Software:
um estudo exploratório sobre as percepções dos gerentes de projeto
. Disponível em: <http://bit.ly/HRXfux>. Acesso em: 04 abr. 2012.
CATUNDA, E. et al. Implementação do Nível F do MR-MPS com
Práticas Ágeis do Scrum em uma Fábrica de Software. Disponível em:
<http://bit.ly/IQ7EpC>. Acesso em: 04 abr. 2012.
SANTOS, G. Influência e Impacto do Programa MPS.BR na Pesquisa
Relacionada à Qualidade de Software no Brasil. Disponível em: <http:
//bit.ly/IlzLe2>. Acesso em: 04 abr. 2012.