INSTITUTO SUPERIOR POLITÉCNICO DE TECNOLOGIAS E

CIÊNCIAS

Curso de Engenharia Informática

GRUPO Nº 07

Diafuana Lukanu – 20151262

Adriano Serafim – 2014244

Victorino António – 20150099

Modelos e normas de qualidade de software (CMMI)

LUANDA

2017
 1

GRUPO Nº 07

Diafuana Lukanu – 20151262

Adriano Serafim – 2014244

Victorino António – 20150099

Modelos e normas de qualidade de software (CMMI)

Trabalho apresentado na disciplina de

Tópicos Especiais III do IIº Semestre
do 3º ano do curso de Engenharia
Informática do Instituto Superior
Politécnico de Tecnologias e Ciências
(ISPTEC), para abordar sobre os
conceitos sobre modelos e normas de
qualidade de software e como pode-
se aplicar na prática.

Docente: Msc. Ameirys Betancourt Vázquez

LUANDA

2017
 2

RESUMO

Este trabalho visa abordar sobre a norma de qualidade ISO 9000, o CMM e o
CMMI como sendo um modelo de qualidade ou melhoria de processos de software e
representando uma verdadeira evolução do modelo SW-CMM. Sendo que o CMMI é
o mais recente modelo de maturidade para desenvolvimento de software do SEI
(Software Engineering Institute - Carnegie Mellon University - EUA) e é também um
dos maiores influenciadores em gestão de processos de software em todo o mundo.
Palavras-chave: ISO 9000, CMM, CMMI, SEI, qualidade, melhoria.
 3

LISTA DE ABREVIATURAS

CMM Capability Maturity Model;

CMMI Capability Maturity Model Integration;
SEI Software Engineering Institute;
SW Software;

SPI Software Process Improvement;

KPA key process area;

IEEE Institute of Electrical and Electronics Engineers;

UML Unified Modeling Language;
ISO International Organization for Standardization;
ML-2 Maturity Level 2;
ERP Enterprise Resource Planning;
SCAMPI Standard CMMI Appraisal Method for Process Improvement;
ABS Associação Brasileira de Empresas de Software.
 4

SUMÁRIO

INTRODUÇÃO..............................................................................................................5
1. OBJETIVOS DO TRABALHO.............................................................................5
DESENVOLVIMENTO..................................................................................................6
1. NORMA ISO 9000...............................................................................................6
2. CMM....................................................................................................................6
3. CMMI...................................................................................................................7
O que é ?................................................................................................................7
CMMI por estágios..................................................................................................9
CMMI contínuo.....................................................................................................10
Para que serve?...................................................................................................12
Benefícios pelo cmmi no negócio.........................................................................13
Benefícios técnicos pelo CMMI no negócio.........................................................13
Como aplicar?.......................................................................................................13
Estudo de caso: Dalmark Systems.......................................................................14
CONCLUSÕES...........................................................................................................16
REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................17
 5

INTRODUÇÃO

No processo de software tem sido elevada a busca de um produto eficiente e

de qualidade, para tal recorre-se a modelos ou normas baseadas em SPI (melhoria
no processo de software), de modos a garantir a qualidade do software, pois diz-se
que qualidade no processo garante a qualidade no produto.

O primeiro modelo baseado na melhoria de software que destacou-se foi o

CMM (e depois o CMMI). Estes modelos de maturidade de processo proporcionam
uma indicação geral da maturidade de processo exibida por uma organização de
software. Proporcionam também uma sensação qualitativa sobre a eficiência
relativa do processo de software que está em uso no momento.

Na perspectiva de melhoria da qualidade no processo de software nas

organizações, foi criado o Instituto de Engenharia de Software (SEI, do inglês
Software Engineering Institute) dos Estados Unidos. Este encaregou-se de um
estudo de avaliação, com objectivo de se estabelecer modelos.

1. OBJETIVOS DO TRABALHO

O objetivo deste trabalho é o conhecer e aprender a aplicar um modelos e

normas de qualidade de software, CMM e CMMI.

Os objetivos específicos do trabalho são:

 Entender a diferença entre o padrão ISO 9000 com CMM;

 Entender a evolução do CMM para o CMMI;
 Entender o conceito do CMMI;
 Abordar o seu funcionamento e seus benefícios;
 Abordar sobre como pode ser aplicado;
 Mostrar um exemplo prático ou um estudo de caso usando o CMMI.
 6

1. NORMA ISO 9000

Normas de Gestão da Qualidade e Garantia da Qualidade. É um guia de

como as demais normas devem ser usadas. Existem algumas normas dessa família,
que são:

 Norma ISO 9001: Sistemas da Qualidade – Modelo para Garantia da

Qualidade em Projeto, Desenvolvimento, Produção, Instalação e Assistência
Técnica. Para uso quando a conformidade com os requisitos especificados
tiver que ser garantida pelo fornecedor desde o projeto até a manutenção;

 Norma ISO 9000-3: Normas de Gestão da Qualidade e Garantia da

Qualidade – Parte 3. Esta norma define diretrizes para facilitar a aplicação da
norma ISO 9001 a organizações que desenvolvem, fornecem e mantêm
software. Destina-se a fornecer orientação quando um contrato entre duas
partes exigir a demonstração da capacidade do fornecedor em desenvolver,
fornecer e manter produtos de software. Esta norma aplica-se nos processos
de desnvolvimento de software.

2. CMM

Em meados de 1980, o SEI iniciou um estudo sobre como avaliar as

capacidades dos prestadores de serviços de software. O resultado dessa avaliação
de capacidade foi o Modelo Maturidade e de Capacidade (CMM, do inglês Capability
Maturity Model) do SEI. Tornou-se uma estrutura de SPI completa em 1990.

Este tem sido bastante influente em convencer a comunidade de engenharia

de software a levar a sério a melhoria de processos. O CMM para software foi
seguido por uma gama de outros modelos de maturidade e de capacidade, incluindo
o Modelo de Maturidade e de Capacidade de Pessoas (CMM-P, do inglês People
Capability Maturity Model) e o Modelo de Capacidade de Engenharia de Sistemas.

O CMM não é nada mais que a aplicação dos princípios da Qualidade Total e
da Gestão de Projetos ao mundo do software. Assim, o CMM tem sido usado com
sucesso, na íntegra ou adaptado, nos mais variados tipos de empresas, grandes e
pequenas, bem como em várias áreas de atuação.
 7

O CMM classifica as organizações em cinco níveis distintos, cada um com

suas características próprias. No nível 1, estão as organizações mais imaturas, onde
não há nenhuma metodologia implementada e tudo ocorre de forma desorganizada.
Por outro lado, no nível 5 estão as organizações mais maduras, onde cada detalhe
do processo de desenvolvimento está definido, quantificado e acompanhado e a
organização consegue até absorver mudanças no processo sem prejudicar o seu
desenvolvimento.

Figura 01 – Níveis de maturidade do CMM

Do CMM, surge o CMMI (Capability Maturity Model Integration).

3. CMMI

O que é ?

Em uma tentativa de integrar a multiplicidade de modelos de capacidade com

base na noção de maturidade de processos (incluindo seus próprios modelos), o SEI
embarcou em um novo programa para desenvolver um modelo de capacidade
integrado (CMMI). O framework do CMMI substitui os CMMs para Software e
Engenharia de Sistemas e integra outros modelos de maturidade e de capacidade.
 8

Ele tem duas instâncias, por estágio e contínua, e aborda alguns dos pontos fracos
relatados no CMM para Software.

O modelo CMMI destina-se a ser um framework de melhoria de processos

com ampla aplicabilidade em uma gama de empresas (SOMMERVILLE, 2011, p.
504).

O CMMI está dividido em duas formas de representação diferentes –

estagiada e contínua. A estagiada divide as áreas de processo em cinco níveis de
maturidade, à maneira do CMM. A representação contínua define níveis de
capacidade. As diferenças entre ambos são meramente organizacionais, o conteúdo
é equivalente. Ambos podem ser usados para conseguir níveis em suas respectivas
caracterizações.

A sua versão por estágios é compatível com o CMM para Software e permite
que o desenvolvimento de sistemas e processos de gestão de uma organização seja
avaliado e que a ele seja atribuído um nível de maturidade classificado como de 1 a
5. Sua versão contínua permite uma classificação de granularidade mais baixa de
maturidade de processo. Esse modelo fornece uma maneira de classificar 22 áreas
de processo (veja a Tabela 01) em uma escala de 0 a 5.

Tabela 01 – Áreas de processo no CMMI

 9

O modelo CMMI é muito complexo, com mais de mil páginas de descrição.

Para essa abordagem, simplificou-se radicalmente esse modelo. Os principais
componentes do modelo são:

 Um conjunto de áreas de processo relacionadas às atividades de processos

de software. O CMMI identifica 22 áreas de processo relevantes para a
melhoria e a capacidade de processo de software. Estas são organizadas em
quatro grupos no modelo CMMI contínuo. Esses grupos e áreas de processo
relacionadas foram listados na Tabela 01.
 Um número de metas, que são descrições abstratas de um estado desejável
a ser atingido por uma organização. O CMMI tem metas específicas,
associadas a cada área de processo, e define o estado desejável para cada
área. Ele também define metas genéricas associadas com a
institucionalização das boas práticas. A Tabela 02 mostra exemplos de metas
específicas e genéricas no CMMI.

Tabela 02 – Áreas de processo no CMMI e suas metas

CMMI por estágios

O modelo CMMI por estágios é comparável ao Modelo de Maturidade e de

Capacidade de Software, que fornece um meio para avaliar a capacidade de
processo de uma organização em um dos cinco níveis e prescreve as metas que
devem ser alcançadas em cada um desses níveis. A melhoria de processos é
 10

alcançada por meio da implementação de práticas em cada nível, desde os níveis

inferiores até os mais elevados no modelo.

Os cinco níveis no modelo CMMI por estágios são mostrados na Figura 02.
Eles correspondem aos níveis de capacidade de 1 a 5 no modelo contínuo. A
diferença fundamental entre os modelos por estágio e contínuo do CMMI é que o
modelo por estágios é usado para avaliar a capacidade da organização como um
todo, considerando que o modelo contínuo mede a maturidade de áreas de processo
específicas dentro da organização.

Figura 02 – Níveis de maturidade do CMMI por estágios

A principal desvantagem do modelo por estágios (e do CMM para Software) é

seu caráter prescritivo. Cada nível de maturidade tem suas próprias metas e
práticas. O modelo por estágios pressupõe que todas as metas e práticas em um
nível sejam implementadas antes da transição para o próximo nível. No entanto, as
circunstâncias organizacionais podem ser tais que seja mais adequado implementar
as metas e práticas em níveis mais altos antes das práticas de nível mais baixo.
Quando uma organização faz isso, uma avaliação da maturidade dá uma imagem
enganosa de sua capacidade.
 11

CMMI contínuo

Os modelos de maturidade contínuos não classificam uma organização de

acordo com níveis discretos. Em vez disso, eles são modelos mais refinados que
consideram práticas individuais ou grupos de práticas e avaliam o uso de boas
práticas dentro de cada grupo de processo. Portanto, a avaliação de maturidade não
é um único valor, mas um conjunto de valores mostrando a maturidade da
organização para cada processo ou grupo de processos.

O CMMI contínuo considera as áreas de processo mostradas na Tabela 01 e

atribui um nível de avaliação de capacidade de 0 a 5 (conforme descrito
anteriormente) para cada área de processo. Descrevendo os níveis, temos:

 Nível 0 - Incompleto: um processo é parcialmente realizado ou não

realizado. Um ou mais objetivos específicos do processo não estão
satisfeitos;
 Nível 1 - Realizado: um processo realizado satisfaz todos os objetivos
específicos da área de processo e produz algum trabalho;
 Nível 2 - Gerenciado: um processo de capacidade nível 2 é um processo
realizado (nível 1) que também é planejado e executado de acordo com
políticas pré-definidas. Emprega pessoas hábeis com os recursos adequados
para produzir saídas adequadas, envolve os stakeholders principais e é
monitorado, controlado, revisto e avaliado quanto à aderência à sua
descrição. A gerência do processo é relacionada com a realização de
objetivos específicos estabelecidos para o processo, como custo, cronograma
e qualidade.
 Nível 3 - Definido: um processo definido é um processo gerenciado e
ajustado para o conjunto padrão de processos da organização de acordo com
suas políticas de conduta. Esse conjunto é estabelecido e melhorado com o
tempo e descreve os elementos fundamentais de processos que são
esperados nos processos definidos;
 Nível 4 - Gerenciado quantitativamente: um processo neste nível é definido
e controlado com a ajuda de técnicas quantitativas e estatísticas. A qualidade
e o desempenho do processo são compreendidos em termos estatísticos e
são geridos durante sua vida. Objetivos quantitativos para qualidade e
 12

desempenho de processos são estabelecidos e usados como critério na

gerência do processo;
 Nível 5 - Otimizado: um processo otimizado é gerenciado quantitativamente,
alterado e adaptado para atender aos objetivos de negócio atuais e
projetados. Tal processo enfoca a melhoria contínua do desempenho do
processo através de aprimoramentos tecnológicos inovadores e incrementais,
selecionados com base em uma compreensão quantitativa de sua
contribuição esperada à obtenção da melhoria de processos.

Um fragmento de um perfil de capacidade que mostra os processos em níveis

diferentes de capacidade é mostrado na Figura 03. Isso mostra que o nível de
maturidade em gerenciamento de configuração, por exemplo, é alto, mas que a
maturidade do gerenciamento de riscos é baixa.

Figura 03 – Um perfil de capacidade de processo

A principal vantagem do modelo contínuo é que as empresas podem escolher

os processos de melhoria de acordo com suas próprias necessidades e requisitos.

O modelo por estágios obriga as empresas a se concentrarem em diferentes

estágios. Por outro lado, o CMMI contínuo permite critério e flexibilidade, ao mesmo
tempo que permite às empresas trabalharem no framework de melhoria do CMMI.

Para que serve?

 13

O projeto CMMI foi desenvolvido para:

 Definir um ponto inicial para modelos integrados;
 Aprimorar as melhores praticas para a criação de modelos baseados
em lições aprendidas;
 Estabelecer um framework que possibilite a integração futura de
novos modelos;
 Criação de uma forma associada de avaliação de desempenho e
treinamento de produtos;
 Esforço conjunto (mais de 100 profissionais de aproximadamente 30
empresas envolvidas).
Benefícios pelo CMMI no negócio

As vantagens esperadas no negócio:

 Redução substancial em integração de sistemas e tempo de teste com
maior probabilidade de sucesso;
 Uma maior confiabilidade no que refere ao cumprimento de prazos e
custos que foram acordados, inicialmente, perante o cliente que
solicitou o desenvolvimento de um sistema. Essa previsibilidade é
decorrente do rigor que o CMMI exige quanto à medição dos
processos, fato este que conduz à obtenção de uma base histórica
realista e confiável para estes fins;
 Integra várias funções desenvolvidas;
 Estende os benefícios do CMM-SW para todo o projeto e/ou
organização;
 Emprega o princípio da engenharia de sistemas no desenvolvimento
de software;
 Alavancagem no processo de melhoria do investimento.

Benefícios técnicos pelo CMMI no negócio

 Os benefícios trazidos pelo CMMI, visam o crescimento do foco e

consistência em:
 Requisitos de desenvolvimento e administração;
 Design e desenvolvimento de sistemas;
 Integração de sistemas;
 Administração de riscos;
 Métricas e análises;
 Outras atividades relacionadas a engenharia.

Como aplicar?

Para aplicar o CMMI, precisa-se trabalhar os seguintes pontos:

 14

 No nível 2 é preciso trabalhar pontos como Gestão de Requisitos, de

Acordo com Fornecedores e de Configuração, Planejamento e
Monitoramento de Projetos, Medição e Análise;
 No nível 3, os pontos a serem trabalhados são, entre outros, Solução
Técnica, Integração do Produto, Verificação e Validação, Definição de
Processos Organizacionais, Gestão de Riscos, Análise de Decisões e
Resolução;
 Já nos níveis 4 e 5, respectivamente, trabalhamos pontos como
Performance de Processos Organizacionais e Gestão Quantitativa de
Projetos, Inovação e Análise de Causas e Resolução.
À seguir realizam-se etapas das avalições para o CMMI, tais como:
 A primeira etapa de avaliação para o CMMI é o treinamento da equipe
de avaliação, que poderá ser composta somente por profissionais da
consultoria ou da consultoria e dos clientes.
 A segunda etapa é o planejamento da avaliação, onde diversos
aspectos são contemplados, como logística e estabelecimento de
expectativas.
 A terceira etapa é a execução da avaliação, quando o diagnóstico
propriamente dito é realizado. Tipicamente ocorrem de 5 à 10 dias
consecutivos de visitas ao cliente, quando o planejamento da avaliação
é posto em prática. Entrevistas, revisão de documentos e atividades de
consenso da equipe de avaliação são realizadas nesta etapa.
 Por último vem a reportagem dos resultados, que ocorre no último dia
de avaliação, em uma sessão onde comparecem todos os participantes
e eventuais convidados. Ela é seguida por uma sessão executiva, onde
são discutidos os principais aspectos levantados durante a avaliação.

Estudo de caso: Dalmark Systems

O estudo de caso selecionado para esta abordagem foi realizado na Dalmark

Systems, uma empresa que desenvolve e comercializa um software ERP localizada
em Joinville/SC. A Dalmark é classificada como de pequeno porte, de acordo com a
definição da ABES apresentada anteriormente. Esta empresa foi escolhida por fazer
parte, juntamente com outras empresas, de um projeto que está sendo desenvolvido
pelos autores na área de melhoria de software.
Antes de iniciar o projeto de definição de processos segundo o CMMI, a
Dalmark passou por planejamento estratégico que redefiniu sua atuação no
mercado. A empresa migrou de um modelo baseado em serviços para outro,
baseado em produto, optando por desenvolver e comercializar um produto padrão
destinado a pequenas e médias indústrias. A mudança no planejamento estratégico
da empresa motivou a gerência sênior a investir em melhoria de qualidade do
desenvolvimento do software, visto que o modelo de atuação definido pressupunha
um produto de software estável, com pouca necessidade de correções: o foco
 15

deixou de ser os serviços de customização. Com isso, a empresa buscou em um

primeiro momento, se adequar ao modelo CMMI, mas sem a intenção de se
submeter a um processo de avaliação oficial.
Baseado no cronograma da Figura 04, a equipe iniciou os trabalhos. A opção
pelo início das atividades com as áreas de processos relacionados à engenharia de
requisitos foi enfatizada a partir de reflexões resultantes de uma análise de Gap -
SCAMPI Classe C contratada previamente pela Dalmark. Alguns colaboradores da
empresa foram submetidos a entrevistas e outra parte deles, a questionários, que
posteriormente tabulados, apresentam a real situação dos processos da empresa
(pontos fracos e pontos fortes). Debate entre os técnicos, a gerência sênior, e
conforme a opinião já citada anteriormente neste artigo levou ao consenso que, para
se ter uma melhoria dos processos mais rápida e que se pudesse desenvolver uma
base sólida para as outras áreas, a engenharia de requisitos deveria ser priorizada.
A partir destas definições, os participantes do projeto foram submetidos a
treinamentos, através de um projeto do governo do Estado de Santa Catarina: tanto
em relação ao CMMI (conceitos básicos e cada área de processo do ML-2), quanto
a notações técnicas (casos de uso, particularmente).

Figura 04 – Cronograma de trabalho

Diante deste cenário, foram revistos os processos de definição de requisitos

executados pela Dalmark, procurando adequá-los àqueles requeridos pelas áreas de
processo relativas à Engenharia de Requisitos no CMMI. Durante a revisão dos
processos da Engenharia de Requisitos foram recomendados modelos para
especificação da lista de requisitos, assim como a transcrição destes requisitos na
forma de diagramas de casos de uso. A opção da empresa em utilizar casos de uso,
foi justificada não apenas pela facilidade de identificação de ferramentas que
suportam a notação UML e pela tendência mundial neste tipo de modelagem, mas
também pela possibilidade de aplicar reutilização já no nível conceitual e derivar
casos de teste a partir da especificação de casos de uso, uma vez que estes
diagramas seriam criados considerando o ciclo de vida de especificação do
diagrama. Houve ainda preocupação adicional, durante a confecção da lista de
requisitos, em procurar causas raízes para os requisitos, justificando-os a partir de
processos de negócio. Concluída a definição dos processos, a Dalmark iniciou o
amadurecimento do novo processo de Engenharia de Requisitos, repassando-o para
os setores da empresa que não tiveram participação direta durante sua definição.
 16

De acordo com a gerência sênior, o trabalho de capacitação foi fundamental

na absorção dos novos conceitos de qualidade de software, engenharia e
planejamento de projetos. Este conhecimento formou a base que era necessária
para a equipe visualizar o projeto como um todo, e de que forma os processos
internos seriam impactados, o que foi determinante para o sucesso do projeto. Em
relação à adoção da melhoria da qualidade iniciada pela Engenharia de Requisitos,
a gerência sênior afirma que: a engenharia de requisitos passou a ser considerada
fundamental, pois a documentação gerada a partir desta fase permeará todo o fluxo
de desenvolvimento, onde o produto final será validado em relação aos requisitos
originais. A engenharia de requisitos constitui uma das bases de sustentação dos
processos de desenvolvimento de software, em que a qualidade é abrangida desde
a concepção do produto, e não somente na fase de testes, como é abrangida na
metodologia tradicional .
 17

CONCLUSÕES

Como abordou-se, a norma ISO 9000-3 especifica os requisitos para que as

organizações possam assegurar a qualidade de seus produtos e serviços, ao passo
que, o modelo CMMI traz para as micros, pequenas e médias empresas a
possibilidade de estarem melhorando os seus processos de software, tornando-as
mais competitivas e oferecendo produtos desenvolvidos com a mesma qualidade de
empresas internacionais.
Concluiu-se que CMMI (Capability Maturity Model Integration) representa uma
evolução do modelo SW-CMM, e pode-se também concluir que apesar de todo o
sucesso de uso do modelo CMM no mundo, existe a tendência de que ele seja
substituído gradativamente pelo CMMI.
O modelo de maturidade de processo CMMI é um modelo de melhoria de
processos integrado que suporta a melhoria de processos por estágios e contínua.
A melhoria de processos no modelo CMMI baseia-se em atingir um conjunto
de metas relacionadas às boas práticas de engenharia de software e em descrever,
padronizar e controlar as práticas usadas para atingir essas metas. O modelo CMMI
inclui práticas recomendadas que podem ser usadas, mas não são obrigatórias.
O CMMI é uma boa opção para melhoria no processo de software e
consequentemente, na qualidade do software. E muito embora esteja fortemente
fundamentado em software, o CMMI contempla desenvolvimento multidisciplinar,
cobrindo também outras áreas do desenvolvimento de sistemas.
 18

REFERÊNCIAS BIBLIOGRÁFICAS

 PRESSMAN, Roger S. Engenharia de software. 7. ed. Tradução Mônica

Maria G. Travieso. Rio de Janeiro: McGraw-Hill, 2002. 843 p;

 SOMMERVILLE, Ian. Engenharia de software. 6. ed. Tradução Maurício

de Andrade. São Paulo: Addison Wesley, 2003. 592 p;

 FIORINI, Soeli T; STAA, Arndt von; BAPTISTA, Renan Martins.

Engenharia de software com CMM. Rio de Janeiro: Brasport, 1998. 346
p;

 SOUZA, Adilson Moreira de. Implementando o CMMI (Capability

Maturity Model Integration) como ferramenta para gerenciamento de
projetos de Software;

 PRESSMAN, Roger S. Engenharia de software. 5. ed. Tradução

Ariovaldo Griesi. Travieso. São Paulo: McGraw-Hill, 2011;

 SOMMERVILLE, Ian. Engenharia de software. 9. ed. Tradução Kalinka

Oliveira e Ivan Bosnic. São Paulo: Pearson Prentice Hall, 2011;

 Souza, A. J. Implementação do CMMI Nível 2 em Pequenas

Organizações Desenvolvedoras de Software com Base no Projeto
PLATIC - Meta 2 Univille, Monografia de Conclusão do Curso de
Especialização em Tecnologia da Informação da UFPR, 2007, p. 73.