Este documento apresenta um projeto para implantação do CMMI nível dois de maturidade e Scrum na empresa Realize-se. O projeto aborda requisitos, planejamento, monitoramento, fornecedores, medição, garantia de qualidade e gestão de configuração de acordo com as áreas de processo do CMMI nível dois. A implantação visa melhorar os processos da empresa e trazer benefícios como redução de custos e maior satisfação do cliente.

1. UNIVERSIDADE SALGADO DE OLIVEIRA
CAMPUS GOIÂNIA
SISTEMAS DE INFORMAÇÃO
DESENVOLVIMENTO DE PROJETO PARA
IMPLANTAÇÃO DO CMMI NIVEL DOIS DE
MATURIDADE E SCRUM NA
EMPRESA REALIZE-SE
por
BRUNA MARTINS DE ALMEIDA
DIOGO ROCHA FERREIRA DE MENEZES
PAULO ROBERTO VASCONCELOS
Goiânia, Junho de 2014

2. UNIVERSIDADE SALGADO DE OLIVEIRA
CAMPUS GOIÂNIA
SISTEMAS DE INFORMAÇÃO
DESENVOLVIMENTO DE PROJETO PARA
IMPLANTAÇÃO DO CMMI NIVEL DOIS DE
MATURIDADE E SCRUM NA
EMPRESA REALIZE-SE
por
BRUNA MARTINS DE ALMEIDA
DIOGO ROCHA FERREIRA DE MENEZES
PAULO ROBERTO VASCONCELOS
Relatório final submetido a avaliação, como requisito parcial para obtenção da aprovação na
disciplina Estágio Supervisionado
Orientador: Prof.ª Ana Carolina Prado, MSc
Goiânia, Junho de 2014

3. A Deus por todas as bênçãos, e pela sua
graça e misericórdia sem fim. À minha
mãe pelo apoio, paciência e pelo seu
grande amor. Ao meu pai por sempre
acreditar no meu potencial. Á minha irmã
pelo companheirismo e preocupação.
Bruna Martins de Almeida.
A Deus primeiramente, por me fortalecer e
capacitar a mais este desafio lançado em
minha vida e pela certeza de que minha
missão mal começou.
Diogo Rocha Ferreira de Menezes.
Agradeço minha mãe e meu pai pelo apoio
e pelo amor, aos professores pela ajuda e
por nós guiar nesse trabalho. Aos meus
amigos muito obrigados pelo
companheirismo e ajuda.
Paulo Roberto Vasconcelos Filho.

4. Agradecimentos
Diogo Rocha:
 Aos meus pais, pela confiança, amor e apoio;
 A todos meus amigos e professores que fizeram parte da minha formação, o meu muito
obrigado.
Paulo Roberto Vasconcelos Filho:
 Aos Meus pais, pela vida e ensinamentos;
 Aos meus amigos e professores por me ajudarem a superar obstáculos, obrigado por tudo.

5. Resumo
O presente trabalho tem por objetivo analisar as pequenas e médias empresas
desenvolvedoras de software que hoje em dia preocupam cada vez mais em desenvolver um
diferencial competitivo para o mercado, o que muitas vezes não acontece por conta de
problemas financeiros. Nesse trabalho é tratado o contexto das pessoas que desenvolvem um
sistema de software, a tecnologia que é empregada por eles, e a organização do processo de
desenvolvimento. Para o desenvolvimento da pesquisa utilizou-se da aplicação do CMMI
nível de maturidade dois e o Scrum. Foi percebida uma grande vantagem a ser alcançada
decorrente da implantação da pesquisa, o qual foi confirmado redução de gastos e maior
satisfação do usuário final, entre outros benefícios. Dessa forma, essa pesquisa pôde
comprovar a importância dos processos e qualidade em desenvolvimento de software, no qual
irá ser apresentado um projeto para implantação do CMMI de maturidade dois e Scrum na
empresa Realize.
Palavras chaves: 1. CMMI. 2. Scrum. 3. processos e qualidade em
desenvolvimento de software.

6. LISTA DE ABREVIATURAS E SIGLAS
CASE – Computer – Aided Software Engineering
CCB - Comitê de Controle de Configuração
CM - Configuration Management
CMM - Capability Maturity Model
CMMI - Capability Maturity Model Integration
CMMI – ACQ- CMMI for Acquisition
CMMI – DEV - CMMI for Development
CMMI – SVC - CMMI for Services
CMU - Carnegie Mellon University
DOD - Departament of Defense
EIA - Electronics Industry Alliance
EUA - Estados Unidos da América
GG - Generic Goal
GP - Generic Practices
GQM - Goal Question Metric
IBM - International Business Machines
INCOSE - International Council on Systems Engineering
IPD - CMM - Integrated Product Development Capability Maturity Model
MA - Measurement and Analysis
MPS.BR - Melhoria de Processo do Software Brasileiro
OPD - Organizational Process Definition
PMC - Project Monitoring and Control
PO Team – Product Owner Team

7. PP - Project Planning
PPQA - Process and Product Quality Assurance
REQM - Requirements Management
RUP - Rational Unified Process
SAM - Supplier Agreement Management
SECAM - Systems Engineering Capability Assessment Model
SECM - Systems Engineering Capability Model
SEI - Systems Engineerig Institute
SG - Specific Goal
SP - Specific Practice
SW - CMM - Capability Maturity Model for Software
TI - Tecnologia da Informação
TCC - Trabalho de Conclusão de Curso
WBS - Work Breakdown Structur

8. Sumário
1. INTRODUÇÃO........................................................................................................12
1.1 MOTIVAÇÃO................................................................................................................15
1.2 OBJETIVOS GERAIS .....................................................................................................16
1.3 OBJETIVOS ESPECÍFICOS .............................................................................................17
1.4 ESTRUTURA DO TRABALHO.........................................................................................17
2. REFERENCIAL TEÓRICO ..................................................................................................19
2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE .....................................................19
2.1.1 DEFINIÇÃO ..............................................................................................................19
2.1.2 PROCESSOS ÁGEIS ....................................................................................................20
2.1.2.1 SCRUM ..............................................................................................................20
2.2 QUALIDADE NO DESENVOLVIMENTO DE SOFTWARE....................................................23
2.2.1 QUALIDADE.............................................................................................................23
2.2.1.1 CMMI .................................................................................................................24
2.3 ESTRUTURA DO CMMI ...............................................................................................27
2.3.1 REPRESENTAÇÕES ...................................................................................................27
2.3.1.1 REPRESENTAÇÃO CONTÍNUA E POR ESTÁGIOS ......................................................27
2.3.2 NÍVEIS DE MATURIDADE .........................................................................................30
2.3.3 COMPONENTES ........................................................................................................33
2.3.3.1 COMPONENTES REQUERIDOS...............................................................................34
2.3.3.2 COMPONENTES ESPERADOS.................................................................................34
2.3.3.3 COMPONENTES INFORMATIVOS ...........................................................................35
2.3.4 ÁREAS DE PROCESSOS .............................................................................................35
2.3.5 NOTAS INTRODUTÓRIAS ..........................................................................................36

9. 2.3.6 METAS ESPECÍFICAS................................................................................................36
2.3.7 SUBPRÁTICAS ..........................................................................................................36
2.3.8 PRÁTICAS ESPECÍFICAS............................................................................................37
2.3.9 METAS GENÉRICAS .................................................................................................37
2.3.10 PRÁTICAS GENÉRICAS.............................................................................................37
2.4 ÁREAS DE PROCESSO DO NÍVEL DE MATURIDADE 2 ...................................................38
2.4.1 GESTÃO DE REQUISITOS (REQM) ...........................................................................41
2.4.2 PLANEJAMENTO DE PROJETO (PP)...........................................................................41
2.4.3 MONITORAMENTO E CONTROLE DO PROJETO (PMC)..............................................43
2.4.4 GESTÃO DE CONTRATO COM FORNECEDORES (SAM) .............................................44
2.4.5 MEDIÇÃO E ANÁLISE (MA) .....................................................................................45
2.4.6 GARANTIA DE QUALIDADE DE PROCESSO E PRODUTO (PPQA)...............................45
2.4.7 GESTÃO DE CONFIGURAÇÃO (CM)..........................................................................46
3. PROJETO PARA IMPLANTAÇÃO DO CMMI DE NIVEL DE MATURIDADE DOIS
ESCRUM NA EMPRESA REALIZE-SE............................................................................48
3.1 A EMPRESA.................................................................................................................48
3.2 RELATÓRIO .................................................................................................................49
3.2.1 REQUISITOS .............................................................................................................50
3.2.2 PLANEJAMENTO.......................................................................................................52
3.2.3 MONITORAMENTO E CONTROLE ..............................................................................55
3.2.4 FORNECEDORES .......................................................................................................56
3.2.5 MEDIÇÃO E ANÁLISE...............................................................................................57
3.2.6 GARANTIA DE QUALIDADE DE PROCESSO E PRODUTO.............................................59
3.2.7 GESTÃO DE CONFIGURAÇÃO ...................................................................................61
CONSIDERAÇÕES FINAIS ..............................................................................................63

10. REFERÊNCIAS......................................................................................................................65

11. Lista de Figuras
Capítulo 2
Figura 1: Ciclo do Scrum [8] ............................................................................ 21
Figura 2 História dos CMM's [12] ................................................................... 25
Figura 3 Estrutura da Representação: Contínua e por Estágios [12] ............... 27
Figura 4 Estruturas da área de processo [13] ................................................... 32
Capítulo 3
Figura 5: Logo da Empresa Realize-se [15] ..................................................... 44

12. Lista de Tabelas
Capítulo 2
Tabela 1: Comparação Entre Níveis de Capacidade e Maturidade [12] ............ 28
Tabela 2 Níveis de Maturidade x Categorias x Áreas de Processos [12] ......... 33
Capítulo 3
Tabela 3 Relação entre Criticidade e Complexidade ....................................... 56

13. 12
1. Introdução
Com o grande avanço da tecnologia o mundo se torna cada vez mais
informatizado e interligado. Diante disso, conhecer sistemas de informação é essencial
para os administradores, porque a maioria das organizações precisa deles para
sobreviver e prosperar. Esses sistemas podem auxiliar as empresas a estender seu
alcance a locais distantes, oferecer novos produtos e serviços, reorganizar fluxos de
tarefas e trabalho e, talvez, transformar radicalmente o modo como conduzem os
negócios. Nesse sentido em desenvolvimento de software, no entender de Oliveira
(2006), “três componentes principais determinam a qualidade de um produto: as pessoas
que desenvolvem um sistema de software, a tecnologia que é empregada por eles, e a
organização do processo de desenvolvimento” [1].
Diante desse cenário, uma grande questão se envolve na qualidade do pessoal
atribuído às atividades no desenvolvimento de software, muitos gerentes de projetos não
compreendem o que realmente os clientes buscam e na primeira conversa, antes de
realizarem o detalhamento de todos os requisitos explícitos e implícitos, propõem aos
seus clientes o que eles precisam e ainda estimam curtos prazos de entrega, sem mesmo
antes verificar projetos que se encontram em andamento. Logo, vão à busca de
profissionais que já entrem com boa produtividade de desenvolvimento, muitas vezes o
novo colaborador não sabe sobre a linguagem que se usa na empresa e terá que
aprender, diante disso, se percebe tal necessidade de experiência de mercado para
contratações.
As equipes possuem uma falta de controle do andamento do projeto, muitas
vezes procuram soluções em terceirizar o trabalho visando entrega rápida, mas pela falta
de acompanhamento na empresa prestadora, caem em um maior atraso, o que gera

14. 13
estouro em prazos, entrega de produtos incompletos, entre outros fatores prejudiciais
para a empresa. No entanto, com o aumento do número de empresas no mercado e
grande concorrência, cada vez mais organizações reconhecem a necessidade de gestão
de processos e começam a empregar modelos de processos.
Ainda no contexto de qualidade de desenvolvimento e processos de software,
diversos padrões, metodologias e guias de qualidade foram desenvolvidos para atender
as necessidades de processos consistentes. No Brasil uma metodologia nacional
conceituada é o (MPS.BR – Melhoria de Processo do Software Brasileiro) um “modelo”
utilizado para garantir que haja melhorias na qualidade do processo de desenvolvimento
de softwares para a realidade do mercado de pequenas e médias empresas que atuam
nessa área no Brasil [2].
Uma metodologia americana conceituada internacionalmente é o (CMMI -
Capability Maturity Model Integration) uma abordagem de melhoria de processo que
ajuda as organizações a melhorar o seu desempenho. CMMI pode ser usado para
orientar a melhoria do processo através de um projeto, uma divisão ou uma organização
inteira.
CMMI em engenharia de software e desenvolvimento organizacional é uma
abordagem de melhoria de processo que fornece às organizações os elementos
essenciais para a melhoria do processo eficaz. CMMI é uma marca de propriedade do
Software Engineering Institute da Carnegie Mellon University [3].
De acordo com o Instituto de Engenharia de Software (2006), CMMI ajuda a
"integrar funções organizacionais tradicionalmente separadas, as metas de melhoria de
processos definidos e prioridades, fornece orientações para processos de qualidade, e
fornece um ponto de referência para a avaliação de processos em curso" [3].

15. 14
Existem também diversos modelos de processo, no qual fornece técnicas a serem
seguidas pelos membros de desenvolvimento de software, como exemplo o SCRUM,
seu nome foi inspirado em uma jogada do esporte Rugby um esporte coletivo de intenso
contato físico originário da Inglaterra, na prática SCRUM é uma gestão baseada em
metodologia ágil [4].
Um exemplo de empresa que busca melhoria de processos é o empreendimento
Realize-se do estado de Goiás, Município de Goiânia o qual foi criada em 2011 e
registrada em 28 de junho de 2013. Sendo que atualmente trata-se de uma pequena
empresa que surgiu a partir de uma necessidade identificada onde o mercado busca cada
vez mais por serviços facilitadores que sejam intermediadores entre os noivos, os
convidados e fornecedores de produto ou serviços para este nicho, atuando em todo
processo que envolve um casamento.
Diante desse cenário, o objetivo deste trabalho de conclusão de curso é o
desenvolvimento de projeto de melhoria de processos, com base em CMMI nível de
maturidade 2, utilizando metodologia SCRUM para gerenciamento de projetos, na
empresa Realize-se.
Nesse sentido, para o desenvolvimento a equipe do presente trabalho propõe
para a empresa alcançar uma área altamente competitiva, onde as exigências do
mercado para produtos de software é muito alta e exige ciclos rápidos de
desenvolvimento com resultados imediatos e adaptabilidade rápida de acordo com as
constantes mudanças de requisitos, mas sem deixar de lado a garantia de qualidade. A
metodologia ágil SCRUM descreve “o como fazer” e o modelo CMMI descreve “o que
fazer” Alta flexibilidade é fornecida pela metodologia ágil SCRUM, e CMMI foi
escolhido como o modelo para proporcionar e avaliar a qualidade do produto
desenvolvido e os processos envolvidos no seu desenvolvimento.

16. 15
Com o desenvolvimento deste projeto haverá um ganho significativo para a
empresa Realize-se, pois, com um processo gerenciado se ganha em redução de custos,
o vendedor poderá usar como argumento de venda a qualidade assegurada do produto
que está vendendo, melhoria da qualidade e maior satisfação do cliente, melhoria na
entrega em cumprimento de prazos.
Diante desse contexto, dos benefícios para as empresas do mundo real que o
CMMI proporciona, de acordo com o Instituto CMMI em melhoria da qualidade “a
IBM da Austrália na área de Serviços de gerenciamento de aplicativos fechou 95% dos
problemas dentro do prazo especificado pelo cliente” [5].
Nos tópicos posteriores é apresentado o que foi motivado para a escolha do
tema, os objetivos do trabalho e a fundamentação teórica que faz parte do contexto da
proposta do projeto além da apresentação, da descrição/caracterização do mesmo e
apresentação da proposta para implantação.
1.1 Motivação
A fonte de inspiração à escolha deste tema é encontrada no fator do grande
aumento de empresas no ramo de TI que trabalham no desenvolvimento de software.
Tecnologia, desenvolvimento, rapidez, robustez, segurança, enfim, palavras que
representam um pouco da realidade de uma das áreas que move o mundo atualmente, a
área de TI, no qual as organizações dessa área encontram a necessidade de serem cada
vez mais competitivas, e maduras organizacionalmente.
Diante disso, justifica-se à importância desse trabalho como uma forma de
descrever CMMI, focando nas áreas de processos do nível 2 de maturidade para
empresas que desejam se adequar. Este modelo é um dos mais conhecidos, inclusive em
nível mundial. Optando pela implantação do modelo a empresa terá mais facilidade para
entregar o que realmente o cliente necessita, no prazo estimado, com aprovação de

17. 16
requisitos para entrega do orçamento, melhor comunicação em planejamento de
projetos, realizar com grande precisão medição e análise afim de evitar perdas de
capital, maior precisão ao utilizar versões com o gerenciamento de configuração, maior
monitoramento com os fornecedores, realizar garantia de qualidade, elevar o
desempenho organizacional, além de melhorar a qualidade de seus produtos.
Ainda no contexto de maturidade devido as necessidades do mercado em que
necessitam que os projetos sejam realizados em uma menor quantidade de tempo, com
recursos limitados e, mesmo com todas essas restrições, é exigido que o projeto possua
um nível de qualidade cada vez maior, optamos pela utilização do processo ágil Scrum,
no qual realiza o gerenciamento de projetos de desenvolvimento de software.
Essa pesquisa conterá informações importantes comentando sobre toda a
estrutura do CMMI e Scrum. Estamos detalhando o nível gerenciado do CMMI,
comentando suas áreas de processos, propondo medidas para que empresas consigam
satisfazer cada área a fim de se adequar ao modelo nível 2 de maturidade.
Optamos por desenvolver esta pesquisa pelo interesse de todos da equipe no
assunto, que nos foi apresentado na disciplina do 5º período, Qualidade de Software
ministrada pelo professor, Roberto Couto Lima, no curso Sistemas de Informação, do
segundo semestre do ano de 2013.
1.2 Objetivos Gerais
Pesquisar e analisar as características do CMMI um acrônimo de Capability
Model Integration (Modelo de Maturidade e Capacidade Integrado) e SCRUM uma
gestão baseada em metodologia ágil.
Caracterizar o modelo integrado de maturidade de capacitação, comentando
sobre sua estrutura, sua evolução e sua história. E por fim focar nas áreas de processos

18. 17
do nível gerenciado, desenvolvendo um projeto para implantação do CMMI nível de
maturidade 2 e Scrum na empresa Realize-se.
1.3 Objetivos Específicos
 Definir processo e qualidade no desenvolvimento de software;
 Descrever o histórico do SCRUM;
 Descrever o histórico do CMMI;
 Indicar medidas a empresas que satisfaça as áreas de processos do nível de
maturidade 2 do modelo integrado de maturidade de capacitação;
 Explicar sobre os níveis de capacidade e maturidade do CMMI;
 Evidenciar os componentes associados que o CMMI possui;
 Elaborar um guia para implantação do modelo CMMI e Scrum na empresa
Realize-se.
1.4 Estrutura do Trabalho
Este documento tem a seguinte estrutura:
 Capítulo 1 - Apresentação do projeto, expondo o objetivo do trabalho;
 Capítulo 2 - Contém as referências, apresentando conceitos de termos que foram
utilizados no documento;
 Capítulo 3 - Apresenta a proposta destinada a empresa.
O primeiro capítulo abordará a necessidade atual do mercado de software, os
problemas encontrados pela nossa equipe para essa área, a solução proposta por
institutos especializados em qualidade de software, a base escolhida pela nossa equipe
para implantação na empresa Realize-se, a descrição da empresa, o objetivo da
implantação e seus benefícios.
O segundo capítulo será dividido em quatro partes:

19. 18
A primeira parte mostrará os processos de desenvolvimento de software. Nele
será abordado os processos ágeis, que estão sendo cada vez mais utilizados devido à sua
flexibilidade.
A segunda parte do segundo capitulo irá falar sobre a qualidade no processo de
desenvolvimento de software, apresentando características de um dos mais utilizados
modelos de maturidade de processo, o CMMI.
A terceira parte irá estar apresentando a estrutura do CMMI: as representações,
os componentes, as áreas, notas, metas e as práticas e subpráticas.
A quarta parte deste capitulo irá abordar as áreas de processos do CMMI nível 2,
dando suas definições e suas metas a serem cumpridas.
O capítulo final irá falar sobre a empresa e a proposta destinada a empresa.
Nesse capitulo do trabalho serão apresentados as 7 áreas de processos que a empresa
necessita atender para conseguir alcançar no nível 2 gerenciado do CMMI e Scrum.

20. 19
2. Referencial Teórico
2.1 Processos de desenvolvimento de software
Esse tópico abordará conceitos sobre processos de desenvolvimento de software,
apresentando um processo de desenvolvimento muito utilizado atualmente, e
descrevendo os modelos de maturidade ou qualidade no processo de desenvolvimento
de acordo com as suas características.
2.1.1 Definição
Um processo de desenvolvimento pode ser definido como um conjunto de
atividades ou práticas que objetivam a produção ou manutenção de um produto ou
sistema de software; em outras palavras, passos que devem ser seguidos para o
desenvolvimento de um determinado sistema de software.
Segundo Tanaka, mesmo existindo vários processos de software, por padrão
todos possuem algumas atividades em comum tais como:
Especificação do software: responsável por descrever as funcionalidades
e restrições do que o software irá conter;
Projeto de implementação: garante que o software que será produzido irá
atender todas as especificações levantadas;
Validação do software: uma “avaliação” do software em relação às
expectativas do cliente, pois indica se o software atende ou não tais
expectativas;
Evolução do software: processo de manutenções e alterações que o
software sofre para que o mesmo atenda às “necessidades mutáveis” do
cliente [6].

21. 20
Os processos como já foram ditos fornecem um “padrão de atividades” para o
desenvolvimento de um sistema, porém, tais processos podem ser aprimorados ou
customizados afim de automatizá-lo ou economizar recursos.
O processo iterativo “divide” o projeto em pequenas e rápidas etapas (as
iterações), em que é possível avaliar os requisitos de forma mais clara, estipulando ao
final de cada iteração o nível de qualidade e confiabilidade dos requisitos em relação ao
projeto, com isso obtém-se grande produtividade e menores níveis de falha.
2.1.2 Processos ágeis
Devido às “necessidades dinâmicas” do mercado, as metodologias antigas de
desenvolvimento estão se mostrando menos “atraentes” e eficientes em relação aos
processos ágeis de desenvolvimento de software, pois é necessário que os projetos
sejam realizados em uma menor quantidade de tempo com recursos limitados e, mesmo
com todas essas restrições, é exigido que o projeto possua um nível de qualidade cada
vez maior [6].
Diante disso, surgiram os processos ágeis, que assim como qualquer outro
processo de desenvolvimento, possuem um conjunto de metodologias e propiciam uma
base conceitual para criação de um projeto de software.
2.1.2.1 SCRUM
Em 1995 o termo Scrum foi formalizado por Jeff Sutherland e Ken Schwaber.
Porém, a sua prática, que são reuniões curtas para discutir próximos passos, foi
introduzida anteriormente por empresas japonesas, conforme artigo publicado em 1986.
E também foi verificado o aumento da produtividade na Borland Corporation, por meio
da prática de reuniões diárias [7].
Teoricamente ele pode ser utilizado onde houver às necessidades de gerenciar
um grupo de pessoas que trabalham juntas a fim de atingir um objetivo comum.

22. 21
O Scrum é uma das metodologias mais dinâmicas em gerência de projetos é um
processo iterativo e incremental para o desenvolvimento de qualquer produto ou
gerenciamento de qualquer trabalho sendo dividido em três fases: planejamento
(Pregame), execução Sprint (ciclos) ou (Game) e encerramento (Post-Game). É uma
gestão baseada em metodologia ágil, compreende-se em executar reuniões, planejados
com metas de curto prazo, realizadas por toda a equipe do projeto com objetivo em
produzir um produto. Nas reuniões é preferível a presença do cliente, sendo
fundamental a troca de informações e de emoções.
A partir de uma lista de metas chamada de Product Backlog, definidas por um
responsável pelo produto objeto do desenvolvimento, dentre elas já estabelecidas em
ordem de prioridade. Cada equipe de 6 a 10 pessoas fica responsável pelo cumprimento
de metas conforme uma lista de tarefas chamadas de Sprint Backlog. O objetivo do
Scrum é realizar atividades de maneira iterativa chamadas de Sprints, que são reuniões
diárias. Estas que devem ser rápidas e objetivas, inclusive podendo ser realizadas em pé.
Este encontro tem a finalidade de reportar atividades realizadas desde o último
Sprint, identificar dificuldades, dar prioridade às tarefas a serem realizadas. O
detalhamento de uma dificuldade ou até mesmo resoluções de problemas não são
objetivos desta metodologia. Caso sejam identificadas dificuldades para executar
determinada atividade, faz-se uma reunião ao par para o estudo do problema e
levantamento de alternativas, sempre sob responsabilidade do facilitador e coordenador
dos Sprints chamado de Scrum Master.
Ao terminar o Sprint e demostrado o Sprint Review Meeting que é nada mais
que a demonstração de todas as funcionalidades implementadas no projeto de software e
assim por final é feita a Sprint Retrospective e a equipe parte para o planejamento de um
novo Sprint e o ciclo se reinicia[6], conforme figura 1.

23. 22
Figura 1 – Ciclo do Scrum [8].
 Product Backlog: É uma lista contendo todas as funcionalidades desejadas para
um produto;
 Product Owner: É a pessoa que define os itens do Product Backlog e os
prioriza nas Sprint Planning Meetings o PO Team é o diálogo para priorizar o
Product Backlog que acontece na reunião de planejamento da Sprint;
 Sprint Backlog: É uma lista de tarefas que o Scrum Team se compromete a
fazer em um Sprint;
 Sprint Planning Meeting: É uma reunião na qual estão presentes o Product
Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa
interessada que esteja representando a gerência ou o cliente;
 O Scrum Team: É a equipe de desenvolvimento;
 O Scrum Master: É o que procura assegurar que a equipe respeite e siga os
valores e as práticas do Scrum;
 Daily Scrum: É uma breve reunião diária que a equipe realiza a cada dia do
Sprint, em que cada participante fala sobre o progresso conseguido, o trabalho a
ser realizado e/ou o que impede de seguir avançando (também conhecido como:

24. 23
Standup Meeting ou Daily Meeting, já que os membros da equipe geralmente
ficam em pé para não prolongar a reunião);
 Release Burndown: Em um projeto Scrum, a equipe monitora seu progresso em
relação a um plano atualizando um Release Burndown Chart ao final de cada
Sprint (iteração). O eixo horizontal de um Release Burndown Chart mostra os
Sprints; o eixo vertical mostra a quantidade de trabalho que ainda precisa ser
feita no início de cada Sprint. O trabalho que ainda resta pode ser mostrado na
unidade preferencial da equipe: story points, dias ideais, team days e assim por
diante [8].
2.2 Qualidade no desenvolvimento de software
Para a compreensão sobre padrões de qualidade de software, esta parte do
referencial irá apresentar um dos modelos mais utilizados para garantir a qualidade no
processo de desenvolvimento de software, mostrando a forma com que ele interage no
processo e os resultados que devem ser obtidos para que seja considerado um processo
de qualidade.
2.2.1 Qualidade
Existem atualmente alguns padrões que são utilizados pelas empresas a fim de
garantir e mensurar o nível de qualidade que estas possuem em relação ao seu processo
de desenvolvimento. O resultado é obtido por meio de métricas e avaliações, e garante
maior aceitabilidade e credibilidade por parte das empresas contratantes dessa categoria
de serviços (o desenvolvimento de sistemas). Um dos principais modelos de qualidade é
o CMMI.

25. 24
2.2.1.1 CMMI
Um modelo de referência utilizado para garantir a qualidade no desenvolvimento
de softwares é o CMMI. O modelo referenciado foi desenvolvido pelo SEI da
Universidade Carnegie Mellon - EUA e patrocinado pelo Departamento de Defesa
Americano (DoD), e visa estabelecer um modelo único para o processo de melhoria
corporativo, integrando diferentes modelos e disciplinas. A versão atual do CMMI é a
1.3 e apresenta três modelos [9]:
O primeiro, que foi publicado em agosto de 2006:
 CMMI for Development (CMMI-DEV): CMMI para desenvolvimento;
 Utilizado em processo de desenvolvimento de produtos e serviços.
O segundo publicado em novembro de 2007:
 CMMI for Acquisition (CMMI-ACQ): CMMI para aquisição;
 Utilizado em processos de aquisição e terceirização de bens e serviços.
E o último publicado em fevereiro de 2009:
 CMMI for Services (CMMI-SVC): CMMI para serviços;
 Utilizado em processos de empresas prestadoras de serviços.
O CMMI é uma evolução do CMM (modelo de qualidade de software que
objetiva controlar o processo de desenvolvimento, por meio de diretivas que sugerem
meios de se obter o controle, e que são responsáveis por apresentar formas de evolução
para um padrão de excelência na gestão de software) [9].
O modelo CMMI é composto pelas melhores práticas associadas às atividades de
desenvolvimento e de manutenção de software desde a sua concepção até a entrega e
manutenção. Essas práticas genéricas e especificas, é necessária a maturidade em
disciplinas especificas como: Engenharia de Sistemas, Engenharia de Software,
Engenharia de Hardware, Desenvolvimento Integrado de Produtos, Processos,

26. 25
Aquisição e Suporte, dando uma visão estruturada da melhoria da visão de processos de
uma organização.
Através de pesquisas, o SEI encontrou três dimensões críticas que as
organizações pode focar para melhorar seus negócios: pessoas, procedimentos, métodos,
ferramentas e equipamentos. Os processos utilizados nas organizações mantêm a coesão
dessas dimensões. Os processos alinham a maneira de fazer negócio, aumentam o
desempenho, facilitam a incorporação das melhores práticas, enfim, processos permitem
a otimização de recursos e uma melhor compreensão dos negócios. Além disso, eles
auxiliam a organização a alcançar seus objetivos trabalhando de forma mais inteligente
com menos esforço e maior consistência.
Segundo o Software Engineering Institute os CMM's se originaram nos anos 30
quando Walter Shewhart começou a desenvolver um trabalho de melhoria de processos
utilizando princípios de controle estatístico de qualidade. Mais tarde esses princípios
foram melhores trabalhados por W. Edwards Deming e Joseph Juran. A partir desses
trabalhos, em 1989, Watts Humphrey e Ron Radice e outros estudiosos começaram a
aplicar esses princípios em software dentro da IBM e do SEI, seus trabalhos na época.
Alguns CMM's são baseados no trabalho de Humphrey, Managing the Software
Process, utilizando conceitos básicos. O SEI desenvolveu seu primeiro CMM para
organizações de software e em seguida publicou seu primeiro livro, The Capability
Maturity Model: Guidelines for Improving the Software Process em 1995 [3].

27. 26
Figura 2 - História dos CMM's [12].
Desde 1991 foram desenvolvidos CMM's para várias disciplinas, dentre elas as
mais conhecidas como Engenharia de Sistemas, Engenharia de Software, Aquisição de
Software, Gestão e Desenvolvimento de Força de Trabalho e Desenvolvimento
Integrado de Processo e Produto. Infelizmente o uso múltiplo desses modelos para as
organizações foi complicado. Diante dessa situação segundo a empresa Select Business
Solutions o projeto do CMM Integration foi desenvolvido a partir da combinação de três
modelos [10]:
 SW-CMM v2.0 draft C;
 SECM;
 IPD-CMM v0.98.
Esses modelos foram escolhidos pela sua popularidade nas comunidades de
Software e de Engenharia de Sistemas, e pelas suas diferentes abordagens para melhoria

28. 27
de processo na organização. O objetivo era desenvolver um framework em que as
organizações poderiam se apoiar para buscar melhorias de processos na corporação.
Ao final da integração a equipe do produto CMMI construiu um material que
acomodava múltiplas disciplinas e era flexível o suficiente para apoiar as diferentes
abordagens dos CMM anteriores.
2.3 Estrutura do CMMI
2.3.1 Representações
O CMMI possui duas representações: "contínua" ou "por estágios". Estas
representações permitem a organização utilizar diferentes caminhos para a melhoria de
acordo com seu interesse.
No entender de Groffe (2013):
A implantação do CMMI é recomendável para grandes fábricas de software.
Implementar os diversos estágios é uma tarefa árdua, não só numa fase
inicial, mas também quando se leva em conta a migração de um nível para
outro. Isto exigirá, invariavelmente, a realização de vultosos investimentos
financeiros, assim como uma mudança de postura da organização
(principalmente quando a mesma não contava com uma experiência anterior
bem-sucedida no gerenciamento de processos) [11].
2.3.1.1 Representação contínua e por estágios
Conforme apresentado na figura 3 abaixo, é ilustrada a estrutura da
representação contínua e por estágios, onde nota-se a diferença da estrutura de ambas as
representações: enquanto a representação contínua utiliza níveis de capacidade nas
metas e práticas genéricas a representação por estágios utiliza níveis de maturidade nas
áreas de processo.

29. 28
Figura 3 - Estrutura da Representação: Contínua e por Estágios [12].
Mas também há semelhanças entre elas, ambas têm os mesmos componentes
(Áreas de Processos, Metas Especificas, Metas Genéricas) e esses componentes tem a
mesma hierarquia de configuração.
Níveis de capacidade, associados à representação contínua, aplicam-se à
melhoria de processo da organização em áreas de processos individuais. Esses níveis
são um meio para melhorar, de forma incremental, os processos correspondentes a uma
determinada área de processo. Há seis níveis de capacidade, numerados de 0 a 5.

30. 29
Níveis de maturidade, associados à representação por estágios, aplicam-se à
melhoria de processo da organização em um conjunto de áreas de processo. Esses níveis
auxiliam na previsão dos resultados de futuros projetos. Há cinco níveis de maturidade,
numerados de 1 a 5.
A Tabela 1 compara os seis níveis de capacidade com os cinco níveis de
maturidade. Aonde temos quatro níveis com os mesmos nomes em ambas as
representações. Onde as diferenças são: que não tem nível de maturidade 0 para a
representação por estágios, e no nível 1, o nível de capacidade é “Executado”, ao passo
que o nível de maturidade é “Inicial”. Assim, o ponto de partida é diferente para as duas
representações.
Tabela 1 - Comparação Entre Níveis de Capacidade e Maturidade [12].
A representação contínua preocupa-se tanto com a seleção de uma determinada
área de processo para realizar melhorias quanto com a definição do nível de capacidade
desejado para aquela área de processo. Com isso, é importante saber se um processo é
“executado” ou “incompleto”. Portanto, se inicia representação contínua em
“incompleto”. Já a representação por estágios preocupa-se com a maturidade da
organização, não tendo como preocupação inicial se o processo é executado ou

31. 30
incompleto. Portanto, o ponto de partida da representação por estágios é chamado de
“inicial”.
2.3.2 Níveis de Maturidade
Para apoiar o uso da representação por estágios, todos os modelos CMMI
refletem os níveis de maturidade em seu design e conteúdo. Segundo o (CMUSEI) "Um
nível de maturidade é composto por práticas específicas e genéricas relacionadas a um
conjunto predefinido de áreas de processos que melhoram o desempenho global da
organização" [3]. O nível de maturidade de uma organização é uma indicação do
desempenho da organização em uma determinada disciplinada ou conjunto de
disciplinas. A experiência mostra que as organizações têm seu melhor desempenho
quando focam os esforços de melhoria de processo em um número gerenciável de áreas
de processos em um dado momento, e que essas áreas requerem sofisticação crescente à
medida que a organização melhora.
Um nível de maturidade é um plano evolutivo definido para melhoria de
processo da organização. Cada nível de maturidade representa o amadurecimento de um
importante subconjunto dos processos da organização, preparando-os para alcançar o
próximo nível de maturidade. Os níveis de maturidade são medidos pela satisfação das
metas específicas e genéricas associadas a cada conjunto predefinido de áreas de
processo.
Existem 5 níveis de maturidade. Cada um é uma camada que representa a base
para as atividades de melhoria contínua de processo:
1. Inicial.
2. Gerenciado.
3. Definido.
4. Gerenciado Quantitativamente.

32. 31
5. Em Otimização.
Nível de Maturidade 1 - Inicial:
No nível de maturidade 1, geralmente os processos são ad hoc (expressão latina
cuja tradução literal é “para isto”) e caóticos. Esse tipo de organização não fornece um
ambiente estável para apoiar os processos. O sucesso depende da competência e do
heroísmo das pessoas e não do uso dos processos comprovados. Apesar deste caos,
organizações no nível de maturidade 1 frequentemente produzem produtos e serviços
que funcionam. Entretanto, com frequência, eles extrapolam seus orçamentos e não
cumprem seus prazos [3].
As organizações no nível de maturidade 1 são caracterizadas pela tendência de
se comprometer além da sua capacidade, por abandonar o processo em um momento de
crise, e por serem incapazes de repetir os próprios sucessos.
Nível de Maturidade 2 – Gerenciado:
No nível de maturidade 2, os projetos da organização têm a garantia de que os
processos são planejados e executados de acordo com o planejamento; os projetos
empregam pessoas experientes que possuem recursos; envolvem partes interessadas; são
monitorados, controlados e revisados; e são avaliados para verificar sua união em
relação à descrição de processo. A disciplina de processo nível de maturidade 2
contribui para que as práticas existentes sejam mantidas durante períodos de stress.
Quando essas práticas estão em vigor, os projetos são executados e gerenciados de
acordo com seus planos documentados.
No nível de maturidade 2, o status dos produtos de trabalho e a entrega estão
definidos. Os compromissos com as partes interessadas são estabelecidos e revisados.
Os produtos de trabalho são controlados. Os produtos de trabalho e serviços satisfazem
expectativas definidas pelas partes interessadas.

33. 32
Nível de Maturidade 3 – Definido:
No nível de maturidade 3, os processos são caracterizados e definidos, são
descritos em padrões, procedimentos, ferramentas e métodos. O conjunto de processos-
padrão da organização é estabelecido e melhorado com o tempo, deste são utilizados
para estabelecer padrões à organização. Os projetos estabelecem seus processos
definidos ao adaptar o conjunto de processos-padrão da organização de acordo com as
diretrizes para adaptação.
No nível de maturidade 3, a organização deve amadurecer mais as áreas de
processo do nível de maturidade 2. As práticas genéricas associadas à meta genérica 3
que não foram tratadas no nível de maturidade 2 são aplicadas para alcançar o nível de
maturidade 3 [3].
Nível de Maturidade 4 - Gerenciado Quantitativamente:
No nível de maturidade 4, a organização e os projetos estabelecem objetivos
quantitativos para qualidade e para desempenho de processo, utilizando-os como
critérios na gestão de processos. Objetivos quantitativos baseiam-se nas necessidades
dos clientes, dos usuários finais, da organização e dos responsáveis pela implementação
de processos. A qualidade e o desempenho de processo são entendidos em termos
estatísticos e gerenciados ao longo da vida dos processos.
Para subprocessos selecionados, medidas detalhadas de desempenho de processo
são coletadas e analisadas estatisticamente. As medidas da qualidade e do desempenho
de processo são incorporadas no repositório de medições da organização para apoiar a
tomada de decisão baseada na pesquisa. Identificam-se as principais causas de variação
de processo e onde, as causas dos problemas são corrigidas, assim prevenindo que tais
erros se repitam [3].
Nível de Maturidade 5 - Em Otimização:

34. 33
No nível de maturidade 5, uma organização melhora continuamente seus
processos com base no entendimento quantitativo das causas comuns de variação
presente no processo.
O nível de maturidade 5 tem foco na melhoria contínua do desempenho de
processo por meio de melhorias incrementais e inovadoras de processo e de tecnologia.
Os objetivos quantitativos de melhoria de processo para a organização são
estabelecidos, continuamente revisados para refletir as mudanças nos objetivos
estratégicos e são utilizados como critérios na gestão de melhoria de processo. Os
efeitos das melhorias de processo implantadas são medidos e avaliados em relação aos
objetivos quantitativos de melhoria de processo. Tanto os processos definidos quanto o
conjunto de processos-padrão da organização são alvo de atividades de melhoria
mensuráveis [3].
2.3.3 Componentes
O modelo CMMI possui três diferentes componentes associados. São eles os
componentes requeridos, esperados e informativos.
A Figura 4 abaixo ilustra a estrutura da área de processo, com seus objetivos
específicos com as práticas especificas e os objetivos genéricos com as práticas
genéricas.

35. 34
Figura 4 - Estruturas da área de processo [13].
2.3.3.1 Componentes Requeridos
Os componentes requeridos descrevem o que uma organização tem que realizar
para satisfazer uma determinada área de processo. Estas realizações devem estar
implementadas nos processos da organização. Este componente corresponde às metas
especificas e as metas genéricas. O critério utilizado para decidir se uma área de
processo foi implementada de maneira adequada e a satisfação de metas.
2.3.3.2 Componentes Esperados
Os componentes esperados descrevem o que uma organização pode executar
para satisfazer um componente requerido, orientando o responsável a implantar
melhorias ou executar avaliações. Este componente corresponde às práticas especificas

36. 35
e as práticas genéricas. Para que as metas sejam consideradas satisfeitas, as práticas
devem estar presentes nos processos planejados e implementados da organização.
2.3.3.3 Componentes Informativos
Os componentes informativos auxiliam na implementação dos componentes
requeridos e esperados. São exemplos deste componente: Subpráticas, produtos de
trabalho típicos, extensões, orientações para aplicação de prática genérica, títulos de
metas e práticas, notas de metas e práticas, e referências a outras áreas de processo.
2.3.4 Áreas de Processos
Segundo o (CMUSEI) "Áreas de processos são um conjunto de práticas
relacionadas a uma área que, quando implementadas, satisfazem a um conjunto de
metas consideradas importantes para realizar melhorias significativas naquela área" [3].
Existem 22 áreas de processos relacionadas aos 5 níveis de maturidade. São elas
apresentadas na ordem na Tabela 2, agrupadas em quatro categorias de afinidade:
Tabela 2 - Níveis de maturidade X Categorias X Áreas de Processos [12].
Cada área de processo possui um objetivo específico, por exemplo, o texto da
seção Objetivo da Área de Processo Definição dos Processos da Organizacional (OPD)

37. 36
é: “fornecer subsídios para estabelecer e manter um conjunto utilizável de ativos de
processo da organização e de padrões de ambiente de trabalho” [3].
2.3.5 Notas Introdutórias
Notas Introdutórias é um componente informativo que descreve os principais
conceitos abordados nas áreas de processo. Por exemplo, o conteúdo das notas
introdutórias da área de processo Planejamento de Projeto é: “O planejamento tem
início com os requisitos que caracterizam o produto e o projeto” [3].
2.3.6 Metas Específicas
Segundo o (CMUSEI) "Uma meta específica (SG) descreve as características
que devem estar presentes para uma implementação se adequada a área de processo"
[3]. Os processos do CMMI possuem de 1 a 3 metas específicas por processo. Ela é um
componente requerido do modelo utilizada nas avaliações para determinar se uma área
de processo está implementada.
Por exemplo, uma meta específica da área de processo Gestão de Configuração
é: “A integridade dos baselines é estabelecida e mantida”. Baseline é um Conjunto de
especificações ou produtos de trabalho formalmente revisados e acordados, que servem
como base para desenvolvimentos a partir de então. Um baseline só pode ser alterado
por meio de procedimentos de controle de mudanças [3].
2.3.7 Subpráticas
Segundo o (CMUSEI) "A subprática é uma descrição detalhada que orienta a
interpretação e implementação de uma prática específica ou uma prática genérica" [3].
Podem ser expressas de forma prescritiva, mas, na verdade, são componentes
informativos que apenas visam fornecer ideias que sejam úteis para melhoria de
processo.

38. 37
Por exemplo, uma subprática para a prática específica “Implementações
corretivas para tratar as questões críticas identificadas”, na área de processo
Monitoramento e Controle de Projeto, é: “Determinar e documentar as ações
apropriadas necessárias para tratar as questões críticas identificadas” [2].
2.3.8 Práticas Específicas
A prática específica (SP) é a descrição de atividades importantes para satisfazer
uma meta específica associada. As práticas específicas são componentes esperados com
o objetivo de satisfazer metas específicas de uma área de processo.
Por exemplo, uma prática específica da área de processo Gestão de Contrato
com Fornecedores é: “Avaliar produtos de trabalho selecionados do fornecedor” [3].
2.3.9 Metas Genéricas
Metas genéricas são chamadas assim, pois valem para todas as áreas de
processos de uma forma única, de maneira que a mesma meta irá significar para todas as
outras áreas de processo. Existem metas genéricas para os níveis de capacidade de 1 a 5
e para os níveis de maturidade 2 e 3. São componentes requeridos do modelo utilizadas
nas avaliações para determinar se uma área de processo está implementada. Elas
descrevem as características necessárias para institucionalizar os processos que
implementam a área de processo [3].
Um exemplo de meta genérica é: “O processo é institucionalizado como um
processo definido”.
2.3.10 Práticas Genéricas
As práticas genéricas são componentes esperados do modelo e são denominadas
“genéricas” porque a mesma prática se aplica a várias áreas de processo. Segundo o

39. 38
(CMUSEI) "descrevem uma atividade considerada importante para a satisfação da meta
genérica associada" [3].
Por exemplo, uma prática genérica da meta genérica “O processo é
institucionalizado como um processo gerenciado” é: “Fornecer os recursos adequados
para execução do processo de monitoramento e controle de projeto, envolvendo o
desenvolvimento de produtos de trabalho e fornecimento dos serviços do processo”.
2.4 Áreas de Processo do Nível de Maturidade 2
Nesta parte do trabalho irá ser apresentado as áreas de processo do nível de
maturidade 2, onde os processos básicos de gestão são definidos. Conforme será
abordado no próximo capitulo a empresa “Realize-se” se encontra no processo inicial do
nível de maturidade, ou seja, o nível 1. Para atingir o nível de maturidade 2 a empresa
precisa criar uma base que seus processos sejam planejados e executados de acordo com
o planejado, conforme será abordado no capitulo três. O nível de maturidade 2 é
composto por sete áreas de processos, de acordo com a representação por estágios,
sendo eles:
1) Gestão de Requisitos (REQM - Requirements Management);
2) Planejamento de Processo (PP - Project Planning);
3) Monitoramento e Controle do Projeto (PMC- Project Monitoring and Control);
4) Gestão de Contrato com Fornecedores (SAM- Supplier Agreement
Management);
5) Medição e Análise (MA - Measurement and Analysis);
6) Garantia de Qualidade de Processo e Produto (PPQA - Process and Product
Quality Assurance);
7) Gestão de Configuração (CM– Configuration Manegement) [12];

40. 39
Todas as áreas de processos possuem seus objetivos específicos (SG – specific
goal), e cada um desses são subdivididos em práticas especificas (SP – specific
practice), e essas são ainda mais detalhadas nas subpráticas. Além dos objetivos
específicos o nível de maturidade 2 possui seus objetivos genéricos que tem a função de
institucionalizar um processo gerenciado. O nível gerenciado possui os seguintes
objetivos genéricos (GG – generic goal) seguidos de suas práticas genéricas (GP –
generic practices) e os objetivos de cada uma [3]:
GG 2 – Institucionalizar um Processo Gerenciado:
GP 2.1 – Estabelecer uma Política Organizacional:
1) Estabelecer e manter uma política organizacional para
planejamento e execução do processo de desenvolvimento de
requisitos;
GP 2.2 – Planejar o Processo:
2) Estabelecer e manter o plano para a execução do processo de
desenvolvimento de requisitos;
GP 2.3 – Fornecer Recursos:
3) Fornecer os recursos adequados para execução do processo de
desenvolvimento de requisitos, envolvendo o desenvolvimento de
produtos de trabalho e fornecimento dos serviços do processo;
GP 2.4 – Atribuir Responsabilidades:
4) Atribuir responsabilidade e autoridade para execução do processo
de desenvolvimento de requisitos, para desenvolvimento dos
produtos de trabalho e fornecimento dos serviços do processo;

41. 40
GP 2.5 – Treinar Pessoas:
5) Treinar pessoas para executar ou apoiar o processo de
desenvolvimento de requisitos conforme necessário;
GP 2.6 – Gerenciar Configurações:
6) Colocar produtos de trabalho selecionados do processo de
desenvolvimento de requisitos sob níveis apropriados de controle;
GP 2.7 – Gerenciar e Envolver as Partes Interessadas Relevantes:
7) Identificar e envolver as partes interessadas relevantes do
processo de desenvolvimento de requisitos conforme planejado;
GP 2.8 – Monitorar e Controlar o Processo:
8) Monitorar e controlar o processo de desenvolvimento de
requisitos em relação ao estabelecido no plano para execução do
processo, e implementar ações corretivas apropriadas;
GP 2.9 – Avaliar Objetivamente a Aderência:
9) Avaliar objetivamente a aderência do processo de
desenvolvimento de requisitos em relação a sua descrição,
padrões e procedimentos, e tratar não conformidades;
GP 2.10 – Revisar Status com Gerência de Nível Superior:
10) Revisar as atividades, o status e os resultados do processo de
desenvolvimento de requisitos com a gerência de nível superior e
tratar questões críticas.

42. 41
2.4.1 Gestão de Requisitos (REQM)
O objetivo desta área de processo é gerenciar os requisitos técnicos e não
técnicos absorvidos ou gerados por um projeto, identificando as inconsistências em
relação aos planos e produtos do projeto e tratando de forma adequada as mudanças
necessárias e seus impactos [14]. Esse ciclo é de extrema importância para as áreas do
projeto, com isso deve-se manter o controle de requisitos sempre atualizado. Alguns
exemplos na prática em que não se aplica REQM em CMMI para Desenvolvimento nas
organizações são:
 O cliente pede uma coisa e é feito outra;
 No primeiro contato com o cliente já é estipulado o valor e o prazo, sem mesmo
verificar os projetos que estão em andamento.
As metas (SG – specific goal) e práticas específicas (SP – specific practice) da
área Gestão de Requisitos são [3]:
SG 1 – Gerenciar Requisitos:
SP 1.1 – Obter Entendimento dos Requisitos;
SP 1.2 – Obter Comprometimento com os Requisitos;
SP 1.3 – Gerenciar Mudanças nos Requisitos;
SP 1.4 – Manter Rastreabilidade Bidirecional dos Requisitos;
SP 1.5 – Identificar Inconsistências entre Produtos de Trabalho, Planos de
Projeto e Requisitos.
2.4.2 Planejamento de Projeto (PP)
O objetivo desta área de processo é estabelecer e manter planos que definem as
atividades dos projetos, envolvendo a elaboração de estimativas, o estabelecimento do
nível adequado de interação com os grupos envolvidos e a obtenção de compromissos

43. 42
[10]. Alguns exemplos na prática em que não se aplica PP em CMMI nas organizações
são:
 O planejamento do projeto não chega até a equipe de desenvolvimento;
 Não é verificado pelo gerente do projeto se o programador que vai escrever os
códigos vai sair de férias durante o período de desenvolvimento do sistema;
 Não é feito plano de risco como no caso em que certos meses do ano chovem
constantemente, no qual não é verificada tal necessidade de alugar um gerador
de energia, pois caso ocorra quedas de rede elétrica durante o trabalho, irá
prejudicar o andamento do projeto.
As metas e práticas específicas da área Planejamento de Processo são [3]:
SG 1 – Estabelecer Estimativas:
SP 1.1 – Estimar o Escopo do Projeto;
SP 1.2 – Estabelecer Estimativas para Atributos de Produtos de Trabalho e de
Tarefas;
SP 1.3 – Definir Ciclo de Vida do Projeto;
SP 1.4 – Determinar Estimativas de Esforço e Custo.
SG 2 – Elaborar um Plano de Projeto:
SP 2.1 – Estabelecer Orçamento e Cronograma;
SP 2.2 – Identificar Riscos do Projeto;
SP 2.3 – Planejar Gestão de Dados;
SP 2.4 – Planejar Recursos do Projeto;
SP 2.5 – Planejar Habilidades e Conhecimento Necessários;
SP 2.6 Planejar o Envolvimento das Partes Interessadas;
SP 2.7 Estabelecer o Plano do Projeto.
SG 3 – Obter Comprometimento com o Plano:

44. 43
SP 3.1 – Revisar Planos que Afetam o Projeto;
SP 3.2 – Conciliar Carga de Trabalho e Recursos;
SP 3.3 – Obter Comprometimento com o Plano.
2.4.3 Monitoramento e Controle do Projeto (PMC)
O objetivo desta área de processo é permitir uma visibilidade adequada do
progresso do projeto, de forma que possam ser tomadas ações corretivas apropriadas
quando o seu desempenho apresentar desvios significativos em relação ao planejado
"(replanejamento, estabelecimento de novos acordos e/ou mitigação de riscos)" [10].
Um exemplo na prática em que não se aplica PMC em CMMI nas organizações é:
 O andamento do projeto pela equipe de desenvolvimento está no tempo de
conclusão pela metade, mas na visão do gerente se encontra quase finalizado.
As metas, práticas específicas e subpráticas da área Monitoramento e Controle
do Projeto são:
SG 1 – Monitorar o Projeto em Relação ao Plano:
SP 1.1 – Monitorar os Parâmetros de Planejamento do Projeto;
SP 1.2 – Monitorar Compromissos;
SP 1.3 – Monitorar Riscos do Projeto;
SP 1.4 – Monitorar a Gestão de Dados;
SP 1.5 – Monitorar o Envolvimento das Partes Interessadas;
SP 1.6 – Conduzir Revisões de Progresso;
SP 1.7 – Conduzir Revisões de Marco.
SG 2 – Gerenciar Ações Corretivas até sua Conclusão:
SP 2.1 – Analisar Questões Críticas;
SP 2.2 – Implementar Ações Corretivas;
SP 2.3 – Gerenciar Ações Corretivas.

45. 44
2.4.4 Gestão de Contrato com Fornecedores (SAM)
O objetivo desta área de processo é gerenciar a aquisição de produtos de
fornecedores externos para os quais existe um acordo formal "produtos e/ou
componentes entregáveis ao cliente, ou mesmo ferramentas e ambientes operacionais
para o projeto " [10]. Alguns exemplos na prática em que não se aplica SAM em CMMI
para desenvolvimento nas organizações são:
 A empresa não monitora o trabalho do fornecedor;
 O gerente de projeto muitas vezes procura formas de terceirizar o trabalho
visando entrega rápida, mas muitas vezes, atrasa ainda mais a entrega do
produto.
As metas e práticas específicas da área Gestão de Contrato com Fornecedores
são:
SG 1 – Estabelecer Contratos com Fornecedores:
SP 1.2 – Selecionar Fornecedores;
SP 1.3 – Estabelecer Contratos com Fornecedores.
SG 2 – Cumprir Contratos com Fornecedor:
SP 2.1 – Executar Contrato com Fornecedor;
SP 2.2 – Monitorar Processos Selecionados do Fornecedor;
SP 2.3 – Avaliar Produtos de Trabalho Selecionados do Fornecedor;
SP 2.4 – Aceitar Produto Adquirido;
SP 2.5 – Transferir Produtos.

46. 45
2.4.5 Medição e Análise (MA)
"O objetivo desta área de processo é desenvolver e manter uma capacitação de
medição para suportar as necessidades de informações gerenciais, em termos de
conceitos, técnicas e mecanismos de execução" [10].
Um exemplo na prática em que não se aplica MA em CMMI nas organizações é:
 A empresa perde dinheiro sem saber o motivo.
As metas e práticas específicas da área Medição e Análise são:
SG 1 – Alinhar Atividades de Medição e Análise:
SP 1.1 – Estabelecer Objetivos de Medição;
SP 1.2 – Especificar Medidas;
SP 1.3 – Especificar Procedimentos de Coleta e Armazenamento de Dados;
SP 1.4 – Especificar Procedimento de Análise.
SG 2 – Fornecer Resultados de Medição:
SP 2.1 – Coletar Dados Resultantes de Medição;
SP 2.2 – Analisar Dados Resultantes de Medição;
SP 2.3 – Armazenar Dados e Resultados;
SP 2.4 – Comunicar Resultados.
2.4.6 Garantia de Qualidade de Processo e Produto (PPQA)
"Objetivo desta área de processo é prover aos integrantes das equipes uma
visibilidade mais clara do andamento dos processos e dos produtos gerados, através de
avaliações objetivas em relação às especificações, da identificação de não
conformidades e do acompanhamento de ações corretivas" [10].
Um exemplo na prática em que não se aplica MA em CMMI nas organizações é:
 Antes de entregar o produto final para o usuário não são realizados testes pela
equipe para que o produto ofereça garantia de qualidade.

47. 46
As metas e práticas específicas da área Garantia de Qualidade de Processo e
Produto são [3]:
SG 1 – Avaliar Objetivamente Processos e Produtos de Trabalho:
SP 1.1 – Avaliar Objetivamente os Processos;
SP 1.2 – Avaliar Objetivamente Produtos de Trabalho e Serviços.
SG 2 – Fornece Visibilidade:
SP 2.1 – Comunicar e Assegurar a Solução de Não conformidades;
SP 2.2 – Estabelecer Registros.
2.4.7 Gestão de Configuração (CM)
O objetivo desta área de processo é estabelecer e manter a integridade dos
produtos de trabalho através da identificação, do controle, da verificação e do
monitoramento constante da situação da sua configuração [10].
Um exemplo na prática em que não se aplica CM em CMMI nas organizações é:
 Os desenvolvedores/programadores muitas vezes sem saber qual versão utilizar,
perdem o que já tinha sido codificado;
As metas e práticas específicas da área Gestão de Configuração são [3]:
SG 1 – Estabelecer Baselines:
SP 1.1 – Identificar Itens de Configuração;
SP 1.2 – Estabelecer um Sistema de Gestão de Configuração;
SP 1.3 – Criar ou Liberar Baselines.
SG 2 – Acompanhar e Controlar Mudanças:
SP 2.1 – Acompanhar Solicitações de Mudança;
SP 2.2 – Controlar Itens de Configuração.

48. 47
SG 3 – Estabelecer Integridade:
SP 3.1 – Estabelecer Registros de Gestão de Configuração;
SP 3.2 – Executar Auditorias de Configuração.

49. 48
3. PROJETO PARA IMPLANTAÇÃO DO CMMI DE
NIVEL DE MATURIDADE DOIS E SCRUM NA
EMPRESA REALIZE-SE
Após compreender a estrutura do Scrum e do CMMI no capítulo anterior, neste
capitulo nossa equipe irá demonstrar uma proposta para a implantação do modelo
CMMI na empresa Realize-se utilizando a metodologia ágil Scrum.
3.1 A Empresa
Figura 5 - Logo da Empresa Realize-se [15].
 Empreendimento: Realize-se;
 Idade: Três anos;
 Área de atuação: Site de Relacionamento de noivos;
 Produto: Website que permite a criação de uma página com o intuito facilitar
para noivos preparativos para o casamento;
 Porte: Pequeno porte, em fase de desenvolvimento;
 Clientes: Noivos e Fornecedores.
O projeto Realize-se surgiu a partir de uma necessidade identificada onde o
mercado busca cada vez mais por serviços facilitadores que sejam intermediadores

50. 49
entre os noivos, os convidados e fornecedores de produto ou serviços para este
nicho, atuando em todo processo que envolve um casamento. Propõe-se com este
projeto; a criação de um Web Site, subdividido em duas partes: uma para atender às
necessidades dos noivos, facilitando o contato com os convidados (o Site
Personalizado dos Noivos), e outra para intermediar o contato entre os fornecedores
e os canais (o Guia de Empresas). Sua viabilidade técnica é expansível para outros
Estados do Brasil [15].
A seguir nossa equipe irá apresentar o relatório orientando a organização as
mudanças que devem ser realizadas, informamos que o CMMI mostra “O QUÊ”
fazer, e não “COMO” fazer. Esse trabalho tem o intuito de ajudar tanto a empresa
Realize-se quanto outras pequenas empresas.
3.2 Relatório
A empresa Realize-se possui uma equipe pequena e se encontra desestruturada
para se adequar as áreas de processo do nível de maturidade 2 do modelo CMMI. Com
este relatório traçaremos mudanças utilizando a metodologia Scrum.
Durante o estágio realizado foi percebido que os requisitos não eram gerenciados
da maneira correta. A infraestrutura da empresa era incompleta e não usava as
ferramentas necessárias para a organização obter sucesso e ficar livre de erros. Não
havia controle durante a criação de algo novo ou durante mudanças. Antes de serem
iniciados projetos não havia um planejamento prévio, análise de riscos, gerenciamento
de requisitos, previsão de custos, previsão de tempo, alguns dos problemas relatados
com mais frequência nos projetos da organização foram:
 Falta de conhecimento técnico.
 Estimativas incorretas ou sem fundamento;
 Falta de apoio da alta administração;

51. 50
 Falta de competência para gerenciar projetos;
 Falta de definição de responsabilidades;
 Falta de uma ferramenta de apoio;
 Falta de uma metodologia de apoio;
 Mudanças de prioridade constantes;
 Problemas com fornecedores;
 Retrabalho em função da falta de qualidade do produto.
Diante desse cenário a empresa Realize-se reconhece tal necessidade em atingir
um alto nível de qualidade de produto do seu serviço, para que possa se fortalecer.
Para a empresa alcançar o nível 2 gerenciado do nível de maturidade 2 no CMMI é
necessário que ela esteja de acordo com as sete áreas de processos e nesse caso
utilizando o Scrum como auxilio, sendo:
3.2.1 Requisitos
Segundo (Leite) “Requisitos são objetivos estabelecidos por clientes e usuários
juntamente com a equipe de desenvolvimento” [16]. Esses requisitos definem as
propriedades que um software deve ter. Existem dois tipos de requisitos: funcionais e
não-funcionais. Os requisitos funcionais descrevem as funções que o usuário final
precisa ter para realizar suas tarefas. Os requisitos não-funcionais são qualidades que
um software deve ter, como desempenho, usabilidade, manutenibilidade dentre outros.
Durante a fase de levantamento de requisitos a organização avaliada não interage
diretamente com o usuário final, por se tratar de uma empresa que disponibiliza serviços
dentro do seu domínio na Internet com o objetivo de atrair clientes. É de suma
importância que a empresa tenha cuidado ao incrementar e modificar requisitos já que
são eles que basicamente atraem seus usuários.

52. 51
Os requisitos são levantados entre a equipe. Não existe uma gerência de
requisitos gerando: retrabalho, desperdício de tempo com requisitos falhos e sem
fundamentos entre outros mal-estares. Neste caso foram levantadas algumas falhas por
parte da Realize-se, como:
 Os requisitos não são analisados antes de serem implementados;
 Os requisitos e suas mudanças não são documentados;
 Algumas partes envolvidas não são contatadas quando mudanças são realizadas;
 Não existem critérios para avaliar e aceitar os requisitos e mudanças;
 Não são feitas reuniões para tratar de implementação de novos requisitos ou
mudanças de alguns já existentes.
Alguns elementos do Scrum podem ajudar a empresa a se organizar e manter um
melhor gerenciamento de requisitos. O CMMI exige que se obtenha entendimento dos
requisitos, comprometimento dos requisitos, gerencia de mudanças de requisitos,
rastreabilidade de requisitos e que se identifique inconsistências entre produtos de
trabalho, planos de projeto e requisitos. Analisando essas exigências e os elementos do
Scrum traçamos a seguinte resolução para a empresa:
1. Eleger um Product Owner:
 A empresa deve eleger uma fonte oficial para o fornecimento de
requisitos para que esta defina os itens que irão compor o Product
Backlog.
2. Apresentar a Sprint Backlog:
 A Scrum Team deve tomar conhecimento dos itens do Product Backlog,
revisá-los para que não haja mal entendimentos e aprová-los. Toda
equipe deve se comprometer com os requisitos.
3. Realizar Daily Scrum.

53. 52
 Nessas reuniões devem ser discutidas mudanças de requisitos ou
inconsistências. O Scrum Master deve intermediar a reunião e gerar um
documento de mudanças de requisitos, caso necessário, comentando sua
motivação, mantendo a relação entre os requisitos originais e todos os
requisitos de produto e de componentes de produto. Em caso de
inconsistências ele deve também implementar ações corretivas.
Fica a critério da empresa optar por uma ferramenta para ajudar na gerencia de
requisitos. Caso a Realize-se deseje usar indicamos a OSRMT (Open Source
Requirements Management Tool). É uma ferramenta CASE desenvolvida em Java por
Aron Smith. Essa ferramenta de ajuda pode ser gratuitamente baixada no link:
<http://sourceforge.net/projects/osrmt/files/>.
3.2.2 Planejamento
Nesta seção trataremos do planejamento de projeto. Esta área trata do tempo, dos
custos, do esforço, dos recursos entre outros envolvidos que serve para acompanhar o
progresso da equipe durante todo o projeto.
Identificamos vários problemas nessa fase. A empresa avaliada não possui uma
estrutura de planejamento de projeto já definida. Diante dessa situação reorganizamos
toda a parte de planejamento da empresa juntamente com os elementos Scrum.
O projeto, segundo o Scrum, tem um ciclo de vida definido em 4 fases:
Planejamento, Preparação e Escalonamento e Desenvolvimento e Entrega. O escopo e
definido na fase de planejamento [8].
Para definir o escopo todas as partes interessadas fazem o papel de Product
Owner. O Product Backlog fornece uma base para a elaboração de um plano de projeto.
Para estimar o escopo do projeto é preciso estabelecer uma estrutura analítica de
projeto (WBS) de alto nível. O WBS (work breakdown structure) deve identificar os

54. 53
riscos e suas tarefas de mitigação (eliminar riscos), tarefas relacionadas a entregáveis e a
atividades de apoio, tarefas relacionadas à aquisição de conhecimento e competência,
tarefas relacionadas a elaboração dos planos de suporte necessários e tarefas
relacionadas a integração e a gestão de itens pré-desenvolvidos. A Estrutura Analítica
ainda auxilia no cálculo do esforço do projeto em termos de tarefas e de papeis e
responsabilidades da organização. Em Scrum, o Product Backlog e os Sprints que são
pré-definidos podem ser considerados uma WBS, já que são esses que irão realizar as
estimativas para o escopo do projeto
Não existem orientações no Scrum para medir o tamanho e a complexidade dos
produtos e atividades de um projeto. Entretanto, fugindo um pouco da metodologia ágil
a Realize-se pode escolher métodos para determinar os atributos de produtos de trabalho
e de tarefas que serão utilizados para estimar os requisitos de recursos. No caso da
empresa avaliada, esse método pode ser linhas de código fonte.
A Realize-se deve selecionar os dados que ela deseja para estimar o esforço e o
custo, considerando necessidades da infraestrutura de suporte. A metodologia utilizada
não possui recomendações para estimar custos, mas o Product Owner necessita destas
informações para calcular o orçamento do projeto. Se necessário a empresa pode
recorrer a uma ferramenta para ajudar a calcular os custos, como o software MS Project,
um software para gerenciar projetos. O Scrum realiza as estimativas de esforço em 2
níveis:
 Product Backlog: são pouco precisas, e tem a finalidade de gerar uma primeira
visão para o Product Owner do esforço necessário para cada requisito;
 Sprint Backlog: são precisas, e tem a finalidade auxiliar no controle e
visibilidade do desenvolvimento das atividades.

55. 54
O orçamento e o cronograma do projeto são obtidos a partir do Product Backlog.
Ele é dividido em Sprints alocando a equipe de acordo com a sua capacidade de
produção. O cronograma é gerado nessa divisão. Este cronograma deve ser mantido
atualizado a média que o projeto desenvolve. Não existem orientações definidas para se
estabelecer o orçamento, entretanto o software citado acima, o MS Project, pode
auxiliar tanto no estabelecimento do orçamento quanto na construção do cronograma.
Segundo o CMMI devemos identificar os riscos do projeto. Utilizando o Scrum
a empresa avaliada pode fazer isso durante uma Daily Scrum. Na reunião o Scrum
Team pode levantar os riscos, documentá-los e corrigi-los. Caso novos riscos sejam
identificados eles podem ser atualizados em uma nova Daily Scrum.
Segundo a subprática na questão de planejar o gerenciamento de dados, somente
quem é autorizado deve ter acesso aos dados do projeto, é necessário estabelecer um
mecanismo para arquivamento dos dados e acesso a eles e determinar quais dados serão
coletados.
Não existe uma formalização no Scrum para a coleta de dados. Entretanto em
uma Daily Scrum é possível comunicar entre o Scrum Team e também comunicar
através de documentos. Para arquivar os dados, uma saída seria criar uma pasta e
fornecer acesso ao pessoal autorizado.
A alocação do time e a preparação da infraestrutura, segundo o Scrum, são
realizadas no início do projeto. É importante determinar requisitos de processo para que
a operação seja eficiente para a execução do projeto. A Realize-se deve também ter os
requisitos para a composição da equipe, levando em conta as habilidades e
conhecimento exigidos para cada função. Caso haja necessidade de mais recursos
durante o projeto, o Scrum Master é responsável por prover o que falta.

56. 55
É importante que a equipe da empresa Realize-se tenhas habilidades e
conhecimentos necessários para executar sua parte no projeto. Caso a equipe, ou um
indivíduo da equipe não tenha a habilidade necessária para implementar o Spring
Backlog está necessidade entra numa lista de impedimentos ou é incluída no Product
Backlog.
As práticas de Scrum garantem uma boa comunicação e colaboração entre as
partes interessadas. O envolvimento dessas partes é monitorado pelo Scrum Master.
Segundo o Scrum para iniciar um projeto o documento de visão de produto e o
Product Backlog deve estar pronto. No documento de visão está descrito porque o
projeto está sendo realizado e o esperado quando ele estiver finalizado. O Product
Backlog define os requisitos funcionais e os não funcionais que o projeto deverá
atender.
No início de um Sprint, em uma Sprint Planning Meeting, e no final, em uma
Sprint Review Meeting o Product Owner, o Scrum Master e o Scrum Team revisam os
planos e os compromissos e se necessário são realizadas adaptações de acordo com as
mudanças no projeto. Também durante o Sprint Planning Metting, as atividades a serem
desenvolvidas são estimadas e o máximo de funcionalidades que poderá ser
implementada no Sprint são definidas. Toda vez que um Sprint é iniciado há o
comprometimento do plano.
3.2.3 Monitoramento e Controle
Durante o andamento do projeto, é importante avaliar o andamento do projeto
formalmente, com o intuito de ver a real condição em que o projeto se encontra até
aquele determinado no momento. Na empresa Realize-se, o gerente de projetos
necessita sempre estar informado sobre como está o andamento da equipe para

57. 56
averiguar se estará pronto no tempo estipulado. O grande problema é a comunicação
falha, e a falta de monitoramento formal.
Utilizando o Scrum a equipe pode monitorar o projeto nas Daily Scrum e usando
o Release Burndown. Ao final de cada Sprint o time monitora seu progresso atualizando
um Release Burndown Chart. Em reuniões diárias, o Scrum Master pode monitorar o
esforço e o custo de sua equipe, analisando suas habilidades estão sendo suficientes para
realizar suas tarefas. Na falta de recursos, o Scrum Master fica responsável por remover
esses obstáculos.
Os compromissos são estabelecidos a cada Sprint, na Sprint Planning Meeting.
Eles são monitorados através do Release Burndown e são revistos na Sprint
Retrospective.
O Scrum busca monitorar qualquer risco do projeto nas Daily Scrum. Para se
adequar ao CMMI, ao invés de registrar os riscos em um quadro-branco, deve-se criar
um documento, registrando e atualizando esses impedimentos, assim como as ações
corretivas realizadas. O Scrum não determina um procedimento para monitorar a gestão
de dados, mas é possível acompanhar se os planos estão sendo cumpridos nas Daily
Scrum.
O Scrum Master é responsável por monitorar as partes interessadas mantendo-as
informadas. Na Sprint Review, ao final de cada Sprint o progresso é avaliado,
permitindo que seja possível visualizar o andamento e o cumprimento do combinado na
Sprint Planning Meeting [8].
3.2.4 Fornecedores
A Realize-se não conta com contrato de fornecedores, ficando muitas vezes
prejudicada por falta de equipamento para reposição, perda de tempo para adquirir
novos equipamentos, falta de fornecedores e vários outros impedimentos.

58. 57
O Scrum não trata da aquisição de produtos. Entretanto o CMMI orienta as
organizações a determinar que tipos de aquisição ela deseja, pode ser produtos de
prateleira, produtos por contrato, produtos por fornecedor externo e etc. Após realizar
essa escolha a empresa deve selecionar seus fornecedores, a partir de critério
estabelecidos pela própria organização.
Ao final disso a empresa deve estabelecer um contrato com os fornecedores
selecionados. A empresa deve documentar o que o fornecedor vai cumprir e ao que eles
terão acesso no projeto.
A organização deve monitorar se o fornecedor contratado está executando as
atividades conforme tratado no contrato e analisar se os processos escolhidos pelo
contratado são críticos para o sucesso do processo.
3.2.5 Medição e Análise
A empresa Realize-se desconhece essa área de processo Medição e Análise do
CMMI. Essa área fornece capacidade de medição para dar suporte ás necessidades de
informação apoiando os negócios, a organização e o projeto. Nos itens anteriores,
requisitos e planejamento, são utilizadas medições para satisfazer a área de processo.
No Scrum, os objetivos de medição podem ser documentados no Daily Scrum,
pelo Scrum Master, a fim de melhorar o projeto. Os objetivos podem ser: reduzir o
tempo de entrega, melhorar níveis de qualidade, melhorar índices de satisfação do
cliente entre outros.
Após os objetivos serem definidos devem-se especificar as medidas para
satisfazê-los. Estas podem ser medidas-base ou medidas-derivadas. Medições diretas
dão origem aos dados para as medidas-bases, já os dados das medidas-derivadas são
obtidos provenientes de outros dados. As medidas devem ser revisadas por toda a
equipe e atualizadas se necessário pois o principal objetivo da medição de software é

59. 58
permitir aos envolvidos conhecer o processo e melhorá-lo de forma contínua. Como um
dos princípios do Scrum são transparência, inspeção e adaptação, não há forma melhor
de deixarmos transparente a qualidade, efetividade e eficiência do processo de
desenvolvimento Scrum utilizado pela equipe que não seja utilizando números.
No Scrum há algumas métricas que são usadas constantemente como:
velocidade média da equipe, estimativa da história, tamanho da Sprint, número de
pontos aprovados em uma Sprint, etc.
No Scrum não há gerentes de projetos que tenha a responsabilidade de decidir
como será feito à medição do software. O certo seria que o grupo se conscientize o qão
importante é medição, para que desse modo seja aperfeiçoado o processo no Scrum.
Métricas devem somente ser escolhidas se necessária afim de responder
perguntas específicas que tenha a melhoria do processo como objetivo no Scrum.
Sem essa medição não é possível saber se algum aspecto do processo trabalhado
possui algum potencial para ser melhorado e quais ações serão utilizadas para o
aperfeiçoamento e correção. Causando problemas, pois à medida que falhas mais sérias
aparecem, o grupo fica mais frustrado percebendo que suas correções não tiveram
efeito.
Mais outro problema relacionado a medição é o “medir por medir” que acontece
ao saber que medir é importante, mas são feitas sem planejamento ou com nenhum
objetivo claro. Para resolver o problema, foi criado o GQM. Método simples para
planejar medições de maneira que sejam baseadas em objetivos específicos de medição.
Como uma das responsabilidades do Scrum Master é zelar pelo processo, a
medição deve ser um aliado importante do tralhado. Fazer análise dos pontos negativos
e positivos levantados nas retrospectivas (principalmente os recorrentes) identificando
falhos no processo.

60. 59
Assim, é possível aplicar o GQM no planejamento de processo e medição, isto
ocorre definindo:
 O objetivo da medição (GOAL). Ex: Melhorar a eficiência dos testes
automatizados.
 A questão a ser respondida (QUESTION). Ex: Qual a eficiência dos testes
automatizados?
 As métricas que respondem a questão respondida (METRIC). Ex: Intervalo entre
falhas, Número de bugs encontrados em homologação etc.
3.2.6 Garantia de Qualidade de Processo e Produto
A qualidade tem como objetivo o processo, aonde tem um tratamento contínuo
para que produza resultados “o mais rápido possível” tentando “fazer o certo da
primeira vez”.
Com propósito de fornecer à equipe e à gerência uma visão objetiva dos
processos e produtos de trabalho. Os processos devem fornecem o necessário para a
implantação de um programa de qualidade que tenha a aderência dos processos e
produtos de trabalho aos padrões, procedimentos e modelos. Afim de assegurar a
qualidade, reduzir custos e esforço com retrabalho, minimizar os problemas nas
atividades de testes e garantir a satisfação do cliente com o produto final.
A Realize-se não conta com um grupo de Gerência da Qualidade de Produto
(GQA), que tem a função de guiar um conjunto de atividades para a avaliação de
processos de modo que esteja em conformidade com os requisitos especificados. Tendo
como responsabilidade: Garantir que o "fluxo de trabalho" esteja sendo conduzido
conforme o processo e gerando produtos de trabalho que possuem "sinais externos"
conforme esperados pela documentação das auditorias. Por sua vez, o processo deve

61. 60
buscar atributos que evidenciem, em uma auditoria, sinais de integridade e qualidade
perceptíveis por um auditor leigo na tecnologia.
 Ações sobre Não Conformidades: Ao detectar uma não conformidade de
processo ou produto, entra em ação um conjunto de padrões devem ser
planejadas e realizadas.
 Registro de Pendência: Toda não conformidade detectada durante a auditoria
se torna uma pendencia, aonde há um responsável por ela. Este responsável
poderá ser alguém do Scrum Team, do PO Team, algum Product Owner ou, em
último caso, a Diretoria.
 Fechamento da Pendência: A finalização do processo de auditoria somente
ocorre quando uma eventual pendência foi fechada, o que pode ser realizado
através de uma descrição da solução pelo responsável.
As auditorias são classificadas em (Baixa, Média e Alta) com complexidade
(Baixa, Média e Alta), que se diz respeito à probabilidade do impacto na detecção de
não-conformidades e no esforço e dificuldade na solução do mesmo, respectivamente.
Essa classificação considera a média da classificação dos itens da lista de
verificação da auditoria e tem por objetivo pré-determinar o tempo máximo para a
resolução das não-conformidades encontradas pelo responsável imediato, antes que as
mesmas sejam escalonadas ao superior imediato. Com o prazo máximo em dias para a
resolução das não-conformidades:

62. 61
Tabela 3 - Relação entre Criticidade e Complexidade.
Os prazos são válidos para itens de auditoria de Pregame, Pre-Sprint, Post-
Sprint, Post-Game e itens de auditorias de Sprint a serem resolvidos dentro da sprint
onde foram relatados.
As práticas de verificação envolvem uma análise técnica dos produtos e
subprodutos produzidos pelo processo, para garantir que estejam feitos conforme o
esperado (do jeito certo), em conformidade com atributos "internamente verificáveis".
3.2.7 Gestão de Configuração
Essa área de processo é importante caso haja mudanças. Podem acontecer
mudanças de requisitos, de ambiente, entre outros. A gestão de configuração descreve
atividades para que essas modificações sejam feitas de maneira controlada, não
comprometendo a estabilidade do projeto. A empresa Realize-se, pode colocar sob
gestão de configuração os requisitos, os códigos, os dados de design e outros de sua
preferência.
Para estabelecer as baselines, linha de base do projeto, pode-se ter por base o
Backlog do produto, que contém as funcionalidades desejadas para ele. Com o Backlog
deve-se selecionar os itens de configuração. A empresa vai precisar de um sistema de
gestão de configuração para controlar os produtos de trabalho, existem ferramentas open
source, software de utilização livre. Alguns exemplos dessas ferramentas são

63. 62
Subversion, CVS, Trac, Scon, Bitten e várias outras. Existem dois tipos de baselines,
são elas:
 Baseline interna: itens de configuração técnicos e gerenciais;
 Baseline externa: itens de configuração finalizados.
Após a criação da baseline o Scrum Master vai analisar, em uma Sprint Planning
Meeting, as solicitações de alteração solicitadas e criar uma Sprint Backlog para
executar em um Sprint essas alterações. O Scrum Master deve manter um documento
com todas as diferenças entre as baselines e confirma se os itens de configuração estão
completos.

64. 63
Considerações finais
O presente trabalho faz uma abordagem sobre o cenário atual das pequenas e
médias empresas de tecnologia, aonde cada vez mais organizações reconhecem a
necessidade em atingir um alto nível de qualidade de produto ou serviço. Os clientes
atuais se tornam cada vez mais exigentes em qualidade, no qual as organizações se
preocupam em gestão de processos e à empregar modelos de processos.
Segundo Pfleeger (2004) a falta de qualidade de software pode custar caro:
Quanto mais tempo um defeito permanece sem ser detectado, mais
cara será sua correção. Estima-se que o custo para correção de um
erro cometido em um projeto durante a etapa inicial da análise seja
um décimo do custo para corrigir um erro semelhante depois que o
sistema já foi entregue ao cliente [17].
Diante disso, são vários os benefícios alcançados decorrentes da avaliação de
produtos de software:
 O produtor poderá assegurar a qualidade do produto final;
 Redução nos custos com a manutenção do software;
 Satisfação do usuário final;
 O vendedor poderá usar como argumento de venda a qualidade
assegurada do produto que está vendendo;
 Organizações poderão exigir critérios de qualificação com propósitos
específicos;
 Diminuição do esforço com retrabalhos;
 Minimizar problemas nas atividades.

65. 64
De acordo com o CMMI Institute, “a IBM da Austrália na área de Serviços de
gerenciamento de aplicativos fechou 95% dos problemas dentro do prazo especificado
pelo cliente” [5].
Desse modo, a empresa analisada neste trabalho certamente encaixa-se neste
cenário, logo a Realize-se adquire maturidade como organização tendo uma
infraestrutura planejada com objetivos específicos de satisfação ao cliente e qualidade
de produto a ser entregue graças a implantação do nível de maturidade 2 - Gerenciado
do CMMI.
Desta forma, presentes a proposta, a Empresa Realize-se poderá então tomar a
melhor decisão para aprimorar seus processos e a qualidade de seus produtos, optando
pelos processos de desenvolvimento e qualidade no processo de desenvolvimento de
software mais adequado às suas necessidades. Como possíveis trabalhos futuros, pode-
se apontar que a empresa alcance os próximos níveis de maturidade do CMMI.

66. 65
Referências
[1] OLIVEIRA, F. B. Tecnologia da informação e da comunicação: desafios e
propostas estratégicas para o desenvolvimento. São Paulo: Pearson Prentice Hall;
Fundação Getúlio Vargas, 2006.
[2] FÁCIL INFORMÁTICA. O que é MPS.BR. Disponível em:
http://www.facilinformatica.com.br/Geral/Noticias.aspx/597. Acesso em: 31 de maio.
2014.
[3] CMUSEI, Carnegie Mellon University, Software Engineering Institute. CMMI®
for Development, Version 1.2. Pensilvania: Carnegie Mellon University, 2006. 20p.
[4] WIKIPÉDIA A enciclopédia livre. Rugby. Disponível em:
http://pt.wikipedia.org/wiki/Rugby. Acesso em: 31 de maio. 2014.
[5] CMMI INSTITUTE. Benefíts of CMMI. Disponível em:
http://cmmiinstitute.com/results/benefits-of-cmmi/. Acesso em: 31 de maio. 2014.
[6] TANAKA S. S. Análise de sistemas I: São Paulo: Pearson Education, 2009.43 p.
[7] PERINI L. S. Engenharia de software São Paulo: Pearson Education, 2009.82 p.
[8] Desenvolvimento Ágil. Scrum. Disponível em:
http://desenvolvimentoagil.com.br/scrum/ . Acesso em: 31 de maio. 2014.
[9] CMMI Institute. Models. Disponível em: http://cmmiinstitute.com/cmmi-solutions/.
Acesso em: 31 de maio. 2014.
[10] SELECT Business Soluctions. What is the Capability Maturity Model?
Disponível em: http://www.selectbs.com/process-maturity/what-is-the-capability-
maturity-model. Acesso em: 31 de maio. 2014.
[11] GROFFE, J. Maturidade no desenvolvimento de software: CMMI e MPS-BR.
Sistemas de Informação. Universidade de Sorocaba, São Paulo, jan./ 2013. Disponível
em <http://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-
e-mps-br/27010>. Acesso em: 01 jum. 2014.
[12] LIMA, R. C. Capability Maturity Model Integration – CMMI para
Desenvolvimento, Versão 1.2 Ago/2013. Disponível em
<http://www.supergestor.com/qualidade/material4.pdf>. Acesso em: 01 jun. 2014.

67. 66
[13] ALMEIDA, Alessandro, Conhecendo o CMMI. In: WORKSHOP QUALITY
PROCCESS, Workshop.ConhecendoCMMI-2oEdicao-DIS. 2005, São Paulo. 151 p.
[14] KULPA, M.K., JOHNSON, K. A. Interpreting the CMMI®: A process
Improvement Approach. 2nd. ed. Florida: Auerbach, 2008. 404p.
[15] Realize-se. O site do seucasamento. Disponível em <http://www.realize-
se.com.br/ .> Acesso em: 01 jun. 2014.
[16] LEITE, J. C., Análise e Especificação de Requisitos. Disponível em
<http://www2.dem.inpe.br/ijar/EngSofAnalEspc.html> Acesso em: 01 jun. 2014.
[17] PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2º. ed. São Paulo:
Pearson Prentice Hall, 2004. p. 6-7.