2014DanielLuizCeratti

Prévia do material em texto

CENTRO UNIVERSITÁRIO UNIVATES 
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS 
CURSO DE SISTEMAS DE INFORMAÇÃO 
 
 
 
 
 
 
 
UM ESTUDO DE CASO SOBRE A IMPLANTAÇÃO DO NÍVEL G DO 
MODELO MPS.BR NA EMPRESA RETTA TECNOLOGIA DA 
INFORMAÇÃO 
 
 
Daniel Luiz Ceratti 
 
 
 
 
 
 
 
 
 
 
 
 
Lajeado, Novembro de 2014
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
Daniel Luiz Ceratti 
 
 
 
 
 
 
 
 
 
 
 
UM ESTUDO DE CASO SOBRE A IMPLANTAÇÃO DO NÍVEL G DO 
MODELO MPS.BR NA EMPRESA RETTA TECNOLOGIA DA 
INFORMAÇÃO 
 
 
Monografia apresentada ao Centro de Ciências Exatas 
e Tecnológicas do Centro Universitário UNIVATES, 
como parte da exigência para a obtenção do título de 
bacharel em Sistemas de Informação. 
 
Área de concentração: GERÊNCIA DE PROJETOS 
 Orientador: Prof. Ms. Pablo Dall’Oglio 
 
 
 
 
 
 
 
 
 
Lajeado, Novembro de 2014
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
Daniel Luiz Ceratti 
 
 
 
 
 
 
 
 
UM ESTUDO DE CASO SOBRE A IMPLANTAÇÃO DO NÍVEL G DO 
MODELO MPS.BR NA EMPRESA RETTA TECNOLOGIA DA 
INFORMAÇÃO 
 
UM ESTUDO DE CASO 
 
 
 
Este trabalho foi julgado adequado para a obtenção do 
título de bacharel em Sistemas de Informação do 
CETEC e aprovado em sua forma final pelo Orientador 
e pela Banca Examinadora abaixo: 
 
 
Prof. Ms. Pablo Dall’Oglio – orientador 
Centro Universitário UNIVATES 
 
Prof. Ms. 
Centro Universitário UNIVATES 
 
Prof. Ms. 
Centro Universitário UNIVATES 
 
 
 
 
Lajeado, Novembro de 2014
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
 
Dedico este trabalho aos meus pais e a todos que me apoiaram em todos os momentos. 
 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
AGRADECIMENTOS 
Agradeço a minha família que sempre me apoiou e incentivou no que fosse necessário. 
Aos meus amigos e colegas de trabalho, que estiveram presentes, incentivaram e 
deram conselhos que contribuíram para a melhoria deste trabalho. 
A Retta Tecnologia da Informação, empresa na qual trabalho, pela oportunidade de 
realizar meu trabalho com base na implantação do modelo de melhoria de processos MR-
MPS-SW. 
Ao orientador Pablo Dall’Oglio, por me auxiliar e incentivar em todos os momentos 
do desenvolvimento deste trabalho. 
A Engsoft, em especial ao Cristiano e a Lilian, pelos auxílios e conselhos prestados. 
Agradeço também a todas outras pessoas que de alguma forma contribuíram para que 
eu pudesse desenvolver este trabalho. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
RESUMO 
Devido à exigência do mercado para a criação de produtos de qualidade, é necessário que as 
empresas busquem formas de melhorar continuamente o processo de desenvolvimento dos 
mesmos, para atender as expectativas dos clientes e não comprometer o projeto. Além de 
buscar a qualidade do produto, fator importante para obter um bom desempenho e tentar 
eliminar erros, é importante gerenciar custos e prazos, dentre outras variáveis. Desta forma, as 
empresas desenvolvedoras de software vêm buscando aperfeiçoamento de sua equipe ao 
utilizar metodologias para auxiliar nas melhorias destes processos de desenvolvimento, como 
o Scrum, Capability Maturity Model Integration (CMMI) e Melhoria de Processos do 
Software Brasileiro (MPS.BR). O Modelo MPS.BR busca garantir que os produtos e a 
execução dos processos da empresa sejam realizados conforme os planos inicialmente 
definidos pela empresa. Dentro desta área de pesquisa, este trabalho apresenta um estudo de 
caso sobre a implantação do nível G (Parcialmente Gerenciado) do modelo MPS.BR, na 
empresa Retta Tecnologia da Informação. Serão relatadas as atividades realizadas, melhorias 
obtidas durante a implantação e entrevistas com colaboradores. Além disso, será apresentado 
um comparativo entre o antes e depois da implantação do nível G do modelo MPS.BR. 
Palavras-chave: Processo de Software, Qualidade de Software, Gerenciamento de Projetos, 
Gerenciamento de Requisitos, MPS.BR. 
 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
ABSTRACT 
Due to market demand for the creation of quality products, it is necessary for companies to 
search ways to continuously improve the process of their software development, to meet the 
expectations of customers and not harm the project. Besides searching product quality, that is 
an important factor to get a good performance and try to eliminate errors, it is important to 
manage costs and deadlines, among other variables. So, software companies are looking for 
the perfectioning of its staff by using methodologies to assist in the improvement of these 
developmental processes, such as Scrum, Capability Maturity Model Integration (CMMI) and 
Melhoria de Processos de Software Brasileiro (MPS.BR). The MPS.BR Model look for 
ensure that products and the execution of business processes are carried out as planned 
initially by the company. Within this area of research, this work presents a case study on the 
deployment of level G (Partially Managed) of MPS.BR model, in the company Retta 
Tecnologia da Informação. All the activities, improvements made during deployment and 
interviews with employees, will be reported. Also, it will be presented a comparative analysis 
of the process before, and after the implementation of the level G of MPS.BR model. 
Keywords: Software Process, Software Quality, Project Management, Requirements 
Management, MPS.BR.
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
LISTA DE FIGURAS 
Figura 1 – Exemplificação da coleta de requisito .................................................................... 16 
Figura 2 – Modelo MR-MPS-SW em relação ao modelo CMMI ............................................ 17 
Figura 3 – Engenharia de Software em camadas ...................................................................... 23 
Figura 4 – Processos de engenharia de Software ..................................................................... 27 
Figura 5 – Visão em espiral do processo de engenharia de software ....................................... 29 
Figura 6 – Gerenciamento de mudança de requisitos ............................................................... 31 
Figura 7 – Nível típico de custo e pessoal ao logo do ciclo de vida ......................................... 33 
Figura 8 – Processos de Gerenciamento de Projetos ................................................................ 33 
Figura 9 – História do CMM .................................................................................................... 37 
Figura 10 – Componentes do modelo MPS .............................................................................. 42 
Figura 11 – Organograma de desenvolvimento ........................................................................63 
Figura 12 – Organograma da empresa ...................................................................................... 65 
Figura 13 – Diagrama do processo de desenvolvimento de software antes do MPS.BR ......... 68 
Figura 14 – Tela de listagem de tópicos do sistema “Gdev” .................................................... 69 
Figura 15 – Figura da planilha de estimativa utilizada anteriormente à implantação do modelo 
MR-MPS-SW ........................................................................................................................... 70 
Figura 16 – Tela do registro de hora do desenvolvedor no sistema “Gdev”. ........................... 71 
Figura 17 – Atividades dos papéis no processo de Gerência de Projetos antes da implantação 
do MR-MPS-SW ...................................................................................................................... 71 
Figura 18 – Atividades dos papéis no processo de Gerência de Requisitos antes da 
implantação do MR-MPS-SW .................................................................................................. 72 
Figura 19 – Backlog do Demander ........................................................................................... 78 
Figura 20 – Diagrama dos processos que precedem o início do projeto e fase de iniciação .... 80 
Figura 21 – Exemplo de EAP de projeto .................................................................................. 81 
Figura 22 – Exemplo Especificação Funcional ........................................................................ 82 
Figura 23 – Imagem da parte principal da Planilha de Estimativas após implantação do MR-
MPS-SW ................................................................................................................................... 83 
Figura 24 – Diagrama dos processos da fase de planejamento ................................................ 84 
Figura 25 – Modelo de Ciclo de Vida Incremental .................................................................. 85 
Figura 26 – Exemplo de tarefa de implementação ................................................................... 86 
Figura 27 – Tela com exemplo de registro de atividade do desenvolvedor ............................. 87 
Figura 28 – Exemplo de Burndown .......................................................................................... 88 
Figura 29 – Exemplo de Status Report ..................................................................................... 88 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
Figura 30 – Exemplo de gestão de mudança. ........................................................................... 89 
Figura 31 – Exemplo de tarefa de bug ...................................................................................... 90 
Figura 32 – Diagrama dos processos da fase de execução ....................................................... 92 
Figura 33 – Diagrama dos processos da fase de encerramento ................................................ 93 
Figura 34 – Exemplo de planilha de encerramento de projetos ............................................... 94 
Figura 35 – Atividades dos papéis da equipe no processo de Gerência de Projetos após a 
implantação do modelo MR-MPS-SW ..................................................................................... 97 
Figura 36 – Rastreabilidade Horizontal .................................................................................... 99 
Figura 37 – Rastreabilidade Vertical ...................................................................................... 100 
Figura 38 – Relacionamento entre Rastreabilidade Horizontal e Vertical ............................. 101 
Figura 39 – Atividades dos papéis da equipe no processo de Gerência de Requisitos após a 
implantação do modelo MR-MPS-SW ................................................................................... 102 
Figura 40 – Cronologia de Implantação do nível G ............................................................... 108 
Figura 41 – Resultados dos Processos de Gerência de Projetos ............................................. 118 
Figura 42 – Resultados dos Processos de Gerência de Requisitos ......................................... 119 
Figura 43 – Orçamento total para participação no projeto ..................................................... 122 
 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
LISTA DE TABELAS 
Tabela 1 – Atributos de qualidade de software ........................................................................ 36 
Tabela 2 – Níveis de maturidade do MR-MPS-SW ................................................................. 52 
Tabela 3 – Papéis da equipe ..................................................................................................... 73 
Tabela 4 – Membros da equipe................................................................................................. 73 
Tabela 5 – Papéis e responsabilidades .................................................................................... 102 
Tabela 6 – Membros da equipe para Produtos Retta .............................................................. 103 
Tabela 7 – Membros da equipe para Fábrica de Software ..................................................... 103 
Tabela 8 – Exemplo de apontamentos realizados pelo avaliador no marco de 50% .............. 114 
Tabela 9 – Total de horas de implementação utilizadas até o marco de 50% ........................ 114 
Tabela 10 – Total de horas de implementação utilizadas ....................................................... 119 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
LISTA DE ABREVIATURAS 
AMP – Avaliação e Melhoria do Processo Organizacional 
AP – Atributos de Processo 
APS – Análise de Processos de Software 
AQU – Aquisição 
CMMI – Capability Maturity Model Integration 
DFP – Definição do Processo Organizacional 
DRE – Desenvolvimento de Requisitos 
DRU – Desenvolvimento para Reutilização 
EAP – Estrutura Analítica das Atividades do Projeto 
GCO – Gerência de Configuração 
GDE – Gerência de Decisões 
GPP – Gerência de Portfólio de Projetos 
GPR – Gerência de Projeto 
GQA – Qualidade 
GRE – Gerência de Requisitos 
GRH – Gerência de Recursos Humanos 
GRI – Gerência de Riscos 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
GRU – Gerência de Reutilização 
ITP – Integração do Produto 
MA-MPS – Método de Avaliação 
MED – Medição 
MNMPS – Modelo de Negócio 
MPS.BR – Melhoria de Processos do Software Brasileiro 
MR-MPS-SV – Modelo de Referência MPS para Serviços 
MR-MPS-SW – Modelo de Referência MPS para Software 
PCP – Projeto e Construção do Produto 
PMBOK – Project Management Body of Knowledge (PMBOK) 
PMI – Project Management Institute 
RAI – Relatórios de Atividades de Implementação 
RAP – Resultados esperados dos Atributos de Processo 
RMI – Relatório Mensal de Implementação 
SEI – Software Engineering Institute 
SVN – Subversion 
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro 
SWEBOK – Software Engineering Body of Knowledge 
TI – Tecnologia da Informação 
VAL – Validação 
VER – Verificação
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)SUMÁRIO 
1 INTRODUÇÃO .......................................................................................................... 14 
1.1 Motivação .................................................................................................................... 18 
1.2 Objetivo ....................................................................................................................... 19 
1.3 Organização do Trabalho .......................................................................................... 19 
2 REFERENCIAL TEÓRICO ..................................................................................... 21 
2.1 Engenharia de Software ............................................................................................. 21 
2.1.1 Áreas da Engenharia de Software ............................................................................. 23 
2.2 Engenharia de Requisitos .......................................................................................... 26 
2.2.1 Estudo de viabilidade ................................................................................................. 27 
2.2.2 Elicitação e análise de requisitos ............................................................................... 28 
2.2.3 Validação de requisitos .............................................................................................. 29 
2.2.4 Gerenciamento de requisitos ..................................................................................... 30 
2.3 Gerência de Projetos .................................................................................................. 31 
2.3.1 Ciclo de vida e processos de gerenciamento do projeto .......................................... 32 
2.3.2 Áreas da Gerência de Projetos .................................................................................. 34 
2.4 Qualidade de Software ............................................................................................... 35 
2.5 CMMI .......................................................................................................................... 37 
2.6 MPS.BR ....................................................................................................................... 40 
2.6.1 Histórico ...................................................................................................................... 40 
2.6.2 Objetivos ...................................................................................................................... 40 
2.6.3 Estrutura ..................................................................................................................... 41 
2.6.4 Níveis de Maturidade ................................................................................................. 42 
2.6.5 Processos ...................................................................................................................... 44 
2.6.6 Capacidade de Processo ............................................................................................. 53 
3 METODOLOGIA ....................................................................................................... 57 
4 O AMBIENTE DO ESTUDO DE CASO ................................................................. 61 
4.1 Caracterização ............................................................................................................ 61 
4.2 A empresa .................................................................................................................... 61 
4.3 Produtos e Serviços ..................................................................................................... 63 
4.4 As linhas de trabalhos ................................................................................................ 65 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
5 O PROCESSO ANTES DA IMPLANTAÇÃO DO MPS.BR ................................. 66 
5.1 Gestão de Projetos antes da implantação do MPS.BR ............................................ 69 
5.2 Gestão de Requisitos antes da implantação do MPS.BR ........................................ 72 
5.3 Configuração da equipe antes da implantação do MPS.BR ................................... 72 
6 O PROCESSO APÓS A IMPLANTAÇÃO DO MPS.BR ...................................... 75 
6.1 Diretrizes internas após a implantação do MPS.BR ............................................... 75 
6.2 O processo de desenvolvimento após a implantação do MR-MPS-SW ................. 77 
6.3 Gestão de Projetos após a implantação do MPS.BR ............................................... 94 
6.4 Gestão de Requisitos após a implantação do MPS.BR ........................................... 98 
6.5 Configuração da equipe após a implantação do MPS.BR .................................... 102 
6.6 Ferramentas utilizadas ............................................................................................. 104 
7 O PROCESSO DE IMPLANTAÇÃO DO MPS.BR ............................................. 106 
7.1 Conscientização ......................................................................................................... 106 
7.2 Diagnóstico da Situação Inicial ............................................................................... 107 
7.3 Treinamento dos processos ...................................................................................... 108 
7.4 Implementação dos processos .................................................................................. 109 
7.5 Plano de Verificação - Marco de 50% .................................................................... 113 
7.6 Processo de institucionalização................................................................................ 114 
7.7 Avaliação de 100% ................................................................................................... 116 
7.8 Dificuldades enfrentadas .......................................................................................... 120 
7.9 Benefícios apresentados ........................................................................................... 121 
7.10 Investimento para a implantação do nível G ......................................................... 122 
8 AVALIAÇÃO DA APLICAÇÃO E CONSIDERAÇÕES FINAIS ..................... 124 
8.1 Avaliação dos colaboradores ................................................................................... 124 
8.2 Considerações finais da implantação ...................................................................... 127 
9 CONSIDERAÇÕES FINAIS ................................................................................... 128 
REFERÊNCIAS ................................................................................................................... 130 
APÊNDICES ......................................................................................................................... 132 
ANEXOS ............................................................................................................................... 146 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
14 
1 INTRODUÇÃO 
Devido ao aumento da concorrência no mercado de Tecnologia da Informação (TI) e o 
consequente aumento da competitividade, a qualidade empregada nos produtos e serviços 
passou a ser um dos fatores determinantes para a diferenciação no mercado. Entretanto, para 
obter sucesso, é necessário aliar qualidade ao gerenciamento de prazos, custos e aos requisitos 
definidos. Para buscar a excelência na qualidade dos produtos, é necessário realizar 
continuamente melhoriasnos processos de criação desses produtos e serviços. “A qualidade é 
hoje o grande motivador em todas as áreas de atividade humana, todos querem oferecer e 
receber produtos e serviços com qualidades” (RODRIGUES et al., 2013). 
Muitas vezes, para aumentar a qualidade dos produtos de software, aumenta-se 
também a complexidade para desenvolvê-lo, e por consequência surgem problemas de 
gerenciamento. Desta forma, empresas que não possuem um controle adequado do 
gerenciamento dos projetos que estão em desenvolvimento, tendem a ter os problemas 
agravados. 
Segundo a Associação para Promoção da Excelência do Software Brasileiro (Softex, 
2012), as empresas estão tendo que mudar as estruturas organizacionais e processos 
produtivos devido às mudanças que estão ocorrendo nos ambientes de negócios, isso implica 
em deixar de ter uma visão tradicional baseada em áreas funcionais e direcionar para redes de 
processos centrados no cliente. Ainda segundo a Softex, para ser competitivo através da 
qualidade, é necessário melhorar a qualidade dos produtos de software e serviços correlatos, e 
também os processos de produção e distribuição de software. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
15 
Segundo a Softex (2012): 
Para que se tenha um setor de software competitivo, nacional e internacionalmente, 
é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos 
seus processos em foco nas empresas, visando à oferta de produtos de software e 
serviços correlatos conforme padrões internacionais de qualidade. 
A Gerência de Projetos, bem como a Gerência de Requisitos, são áreas essenciais que 
colaboram para o sucesso dos projetos de software. Segundo Sommerville (2011), o gerente 
de projetos tem a tarefa de garantir que o projeto de software consiga atender as estimativas 
de cronograma, orçamentos e consiga fornecer um software de qualidade, mesmo que os 
projetos estejam sujeitos a alterações e restrições. Porém, o fato de gerenciar um projeto não é 
garantia que o mesmo será bem sucedido, “no entanto, o mau gerenciamento costuma resultar 
em falha do projeto” (SOMMERVILLE, 2011). 
Para Sommerville (2011), os critérios de sucesso podem ser diferentes para cada 
projeto, mas na sua maioria, os pontos mais importantes são: 
 Fornecer o software ao cliente no prazo estabelecido; 
 Manter os custos gerais dentro do orçamento; 
 Entregar software que atenda às expectativas do cliente; 
 Manter uma equipe de desenvolvimento que trabalhe bem e feliz. 
É importante que o gerente de projetos, considere a possibilidade de imprevistos ao 
logo do projeto, desta forma, segundo Sommerville (2011), “uma boa regra é estimar como se 
nada fosse dar errado e aumentar sua estimativa para cobrir os problemas previstos”. 
 “A qualidade de um software depende em grande parte dos requisitos.” 
(KOSCIANSKI e SOARES, 2006). O levantamento de requisitos é uma parte importante da 
construção de um software. Requisitos com dupla interpretação, especificações incompletas, 
erros lógicos, dentre outros fatores tendem a resultar em um software de baixa qualidade. 
De acordo com Koscianski e Soares (2006), os requisitos de software são as definições 
do que o software deve fazer, seu comportamento, detalhando como as operações devem ser 
feitas. Ainda segundo Koscianski e Soares (2006), um dos grandes problemas relacionado à 
especificação de requisitos é a comunicação entre o cliente e a equipe técnica. “Os usuários 
podem estar empolgados em saber como o novo sistema vai funcionar ou o que pode fazer e 
acabam por esquecer-se de explicar aspectos fundamentais de seu trabalho. Em particular, as 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
16 
atividades realizadas podem frequentemente passar despercebidas” (KOSCIANSKI e 
SOARES, 2006). A Figura 1 retrata este apontamento. 
Figura 1 – Exemplificação da coleta de requisito 
 
Fonte: Adaptada pelo autor com base em Project Cartoon (2010, texto digital). 
Além disso, de acordo com Pressman (2006), os projetos de software dificilmente 
seguem o fluxo inicialmente definidos. Muitas vezes o cliente não consegue levantar todas as 
necessidades que ele precisa, desta forma mudanças quase sempre ocorrem e trazem 
problemas ao cronograma. Em modelos sequenciais, principalmente, é exigido ao cliente 
declarar todas as necessidades no início do projeto, uma vez que o software sofrerá alterações 
ao longo de seu desenvolvimento e somente serão percebidas na próxima entrega ao cliente. 
Para atender de forma adequada os processos de um projeto de software, é importante 
seguir um conjunto de normas e regras existentes na Engenharia de Software. O conceito 
Engenharia de Software foi criado para aumentar a qualidade dos produtos de software 
construídos, através da organização dos processos e do fornecimento de uma estrutura. 
Segundo Sommerville (2011), Engenharia de Software é uma disciplina da engenharia focada 
em todos os aspectos da criação do produto de software, desde seu estágio inicial até que o 
sistema esteja em uso, considerando questões práticas de custo, prazo para o desenvolvimento 
e confiança, assim como as necessidades dos clientes e dos produtos do software. 
Existem modelos de qualidade que visam obter a melhoria dos processos de software 
nas empresas. Estes modelos possuem um conjunto de boas práticas que, quando aplicados, 
permitem aumentar a chance de se obter produtos de qualidade. Dentre estes modelos estão o 
Capability Maturity Model Integration (CMMI) e o Melhoria de Processos do Software 
Brasileiro (MPS.BR), que será estudado neste trabalho. Ambos os modelos cobrem uma série 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
17 
de disciplinas da Engenharia de Software, dentre elas a Gerência de Requisitos e a Gerência 
de Projetos, já citadas anteriormente. 
O modelo MPS.BR visa melhorar o processo de desenvolvimento do software (MR-
MPS-SW) e serviços (MR-MPS-SV) em empresas brasileiras, implantando os princípios de 
Engenharia de Software alinhados com as principais normas internacionais. O modelo é 
totalmente compatível com o CMMI, e com as Normas Internacionais ISO/IEC 12207:2008 e 
ISO/IEC 15504. “A norma 15504 apresenta uma estrutura para a realização de avaliações de 
processos em organizações” (KOSCIANSKI e SOARES, 2006). O modelo MR-MPS-SW é 
dividido em sete níveis de maturidade, iniciando pelo menor, nível G, até o maior, nível A. O 
modelo CMMI por sua vez, possui 5 níveis de maturidade, iniciando pelo nível 2 até o nível 
5. É possível ver na Figura 2, uma relação entre os níveis dos dois modelos. 
Figura 2 – Modelo MR-MPS-SW em relação ao modelo CMMI 
 
Fonte: Coutinho (2011, texto digital) 
De acordo com a Softex (2012), espera-se que o modelo MPS.BR seja compatível com 
o perfil de todas as empresas que irão implementá-lo, especialmente as micro, pequenas e 
médias empresas. Existe a expectativa de que o modelo tenha intenção de aproveitar toda a 
eficiência já existente em outros padrões e modelos disponíveis, e que seja compatível com os 
padrões aceitos internacionalmente. Sendo assim: 
[...] ele tem como base os requisitos de processos definidos nos modelos de melhoria 
de processo e atende a necessidade de implantar os princípios de Engenharia de 
Software de forma adequada ao contexto das empresas, estando em consonância 
com as principaisabordagens internacionais para definição, avaliação e melhoria de 
processos de software. (SOFTEX, 2012). 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
18 
A intenção da Softex é proporcionar para as empresas brasileiras, a implementação de 
forma gradual, em especial às micro, pequenas e médias empresas, de um processo de 
melhoria no gerenciamento dos processos de desenvolvimento e gerenciamento de produtos. 
1.1 Motivação 
Conforme Koscianski e Soares (2006), “poucas empresas de pequeno e médio porte 
podem arcar com os custos de implementação dos modelos do SEI [Software Engineering 
Institute].” Assim, a Softex, em conjunto com o Governo, disponibiliza um aporte financeiro 
às empresas. Apesar disto, ainda assim é necessário que as empresas invistam dinheiro e 
tempo de seus colaboradores na implementação do modelo proposto pelo MPS.BR. 
O modelo MPS.BR busca ser adequado ao perfil de empresas de diferentes tamanhos, 
ou seja, independente do porte da empresa, este modelo visa melhorar a qualidade dos 
processos de desenvolvimento de software das empresas brasileiras. Um fator importante 
deste modelo é que ele não impõe um formato para sua empresa trabalhar, a empresa deve 
encontrar uma forma que seja adequada a ela, tendo em vista a equipe, a estrutura e os 
objetivos. Assim, ao final da implantação, os resultados devem atender o que o modelo espera 
como satisfatório. 
Como se pode perceber, como o modelo não impõe um formato de implementação dos 
processos, a implantação varia bastante de empresa para empresa, devido a diferentes 
configurações de equipes e formas de trabalho. Apesar de existirem muitos trabalhos e 
matérias sobre o modelo MPS.BR, são escassos os materiais que explicam na prática como 
implantar o modelo, destacando as suas principais etapas, dificuldades e melhorias obtidas. 
Em virtude disto, o intuito deste trabalho é apresentar o processo de implantação do nível G 
(que trata das áreas de Gerência de Projetos e Gerência de Requisitos) do modelo MR-MPS-
SW em uma pequena empresa, relatar como eram realizados os processos antes da 
implantação do modelo, e retratar estes após a implantação. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
19 
1.2 Objetivo 
O objetivo deste trabalho é analisar a implantação do nível G do modelo MR-MPS-
SW em uma empresa de desenvolvimento de software, verificando a utilização das técnicas 
existentes para gerenciar os projetos de software. 
O trabalho propõe os seguintes objetivos específicos: 
 Realizar o levantamento dos procedimentos de gerência de projeto e de requisitos 
de software antes e após a implantação do modelo MR-MPS-SW; 
 Verificar e validar a aplicação do modelo; 
 Documentar as atividades realizadas na implantação do modelo; 
 Relatar as principais dificuldades e melhorias na implantação do modelo; 
 Avaliar o processo antes e o depois da implantação do modelo na empresa através 
do questionário aplicado aos colaboradores. 
1.3 Organização do Trabalho 
A organização deste trabalho se dá pela seguinte forma: 
 Capítulo 1 – Introdução: descrição resumida sobre o trabalho, contemplando 
também a motivação, os objetivos e a estrutura do trabalho; 
 Capítulo 2 – Referencial Teórico: apresentação do referencial teórico sobre o 
MPS.BR, dando ênfase a gerência de projetos e de requisitos; 
 Capítulo 3 – Metodologia: definição da metodologia de pesquisa, como foram 
realizadas as coletas de dados, etapas a serem desenvolvidas, implantação do 
modelo; 
 Capítulo 4 – O Ambiente do Estudo de Caso: apresenta as informações sobre a 
empresa, produtos e serviços; 
 Capítulo 5 – O Processo antes da implantação do modelo MPS.BR: apresenta o 
levantamento e a descrição das informações colhidas antes do processo de 
implantação do modelo MR-MPS-SW; 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
20 
 Capítulo 6 – O Processo após a implantação do modelo MPS.BR: apresenta o 
levantamento e a descrição das informações colhidas após o processo de 
implantação do modelo MR-MPS-SW 
 Capítulo 7 – O Processo de implantação do modelo MPS.BR: apresenta o 
levantamento e a descrição das atividades realizadas durante o processo de 
implantação do modelo MR-MPS-SW; 
 Capítulo 8 – Avaliação da implantação e considerações finais: apresenta a 
análise e o levantamento das informações colhidas durante o processo de pesquisa 
deste trabalho, sendo os mesmos apresentados de forma qualitativa; 
 Capítulo 9 – Conclusões finais: o último capítulo apresenta os resultados parciais 
do presente trabalho. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
21 
2 REFERENCIAL TEÓRICO 
Neste capítulo serão apresentados os principais conceitos sobre Engenharia de 
Software e suas áreas, modelos de processos de software, qualidade de software, engenharia 
de requisitos, gerência de projetos, CMMI e MPS.BR, a fim de fornecer o embasamento 
teórico sobre os mesmos. 
2.1 Engenharia de Software 
Pressman (2006) define software como: 
Software de computador é o produto que os profissionais de software constroem e, 
depois, mantêm ao longo do tempo. Abrange programas que executem em 
computadores de qualquer tamanho e arquitetura, conteúdo que é apresentado ao 
programa a ser executado e documentos tanto em forma impressa quanto virtual que 
combinam todas as formas de mídia eletrônica. 
Nos dias atuais, a utilização de software é indispensável para a maioria das coisas. 
Produtos elétricos, sistemas financeiros, áreas como entretenimento, jogos, músicas, cinema, 
militar, industrial, dentre outras, são, na maioria das vezes, controladas por software. 
“Portanto, a Engenharia de Software é essencial para o funcionamento de sociedades 
nacionais e internacionais” (SOMMERVILLE, 2011). 
De acordo com Sommerville (2011), software são abstratos e intangíveis, por não 
possuírem propriedades físicas não há limite natural para sua construção, podendo se 
transformar em um sistema muito complexo de forma muito rápida, dificultando seu 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
22 
entendimento e sua manutenção. Pressman (2006) afirma que o software possui características 
que o diferenciam de outros produtos fabricados pelos homens, são elas: 
 O software é desenvolvido e não fabricado em máquinas. Ambas buscam construir 
um produto de qualidade através de um bom projeto, mas as formas de construções 
são diferentes; 
 O software não se desgasta, ou seja, ele não sobre influência do tempo e da 
natureza. Com o passar do tempo, e com as correções de eventuais falhas, o 
software tende a se estabilizar. Novas falhas podem acontecer caso houver 
desenvolvimento de melhorias ou acréscimo de funcionalidades ao sistema; 
 A maioria dos softwares continuam a serem construídos por encomenda. Os 
engenheiros desenvolvem os componentes para que possam ser reutilizados em 
outros sistemas, desta forma é possível ganhar agilidade ao apenas fazer 
adaptações no componente para o novo software. 
De acordo com Sommerville (2011), a Engenharia de Software é uma disciplina da 
engenharia centrada nos processos daprodução de software, passando pela preparação inicial 
até manutenção do sistema já implantado. Pressman (2006) destaca que a importância da 
Engenharia de Software se dá ao fato de que ela oferece formas de controlar e organizar 
atividades que poderiam se tornar confusas. Porém, uma abordagem moderna de Engenharia 
de Software deve ser ágil, de forma a exigir apenas as atividades adequadas à equipe do 
projeto e ao produto que será produzido. 
No entendimento de Pressman (2006), é possível ver na Figura 3 que a Engenharia de 
Software é uma tecnologia dividida em quatro camadas responsáveis por um conjunto de 
processos que tem como objetivo a construção de um produto. A camada inferior foca na 
qualidade, buscando levantamentos cada vez mais eficientes para um processo de melhoria 
contínua do produto. 
A camada de Processo define o conjunto de atividades necessárias para gerenciar a 
utilização da Engenharia de Software nos projetos. Nesta camada documentos, dados, 
relatórios, entre outros, são produzidos, marcos são definidos, as mudanças são gerenciadas e 
busca-se manter a qualidade. 
A terceira camada, chamada Métodos, define os métodos de construção do software, 
abordando tarefas como comunicação, análise, modelagem de projeto, desenvolvimento, 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
23 
testes e manutenção. A última camada, Ferramentas, fornece o apoio automatizado ou semi 
automatizado para os processos e os métodos, desta forma, quando há integração entre 
ferramentas de modo que as informações geradas em uma ferramenta serão utilizadas em 
outra, um sistema de apoio ao desenvolvimento de software é estabelecido. 
Figura 3 – Engenharia de Software em camadas 
 
Fonte: PRESSMAN (2006, p.17). 
Devido à abrangência da Engenharia de Software, foi criado o Software Engineering 
Body of Knowledge (SWEBOK). Segundo o SWEBOK (2004), o livro é um guia de uso e 
aplicação das melhores práticas de Engenharia de Software, dividindo a Engenharia de 
Software em dez áreas, conforme pode ser visto a seguir. 
2.1.1 Áreas da Engenharia de Software 
Segundo o SWEBOK (2004), a Engenharia de Software é uma área que está em 
processo de evolução contínua, por este motivo, a IEEE Computer Society Software 
Engineering Standards Committee ajudou a estabelecer o guia SWEBOK para promover o 
avanço da teoria e prática nesta área. Desde sua criação, o guia foi revisado por mais de 500 
pessoas de mais de 42 países. 
Conforme dito anteriormente, a Engenharia de Software está em processo contínuo de 
evolução, em virtude disto, novas tecnologias e novas práticas são agregadas ao guia e as 
mais antigas são descartadas. O guia SWEBOK busca fornecer as melhores práticas da 
Engenharia de Software, com base em cinco objetivos: 
 Promover uma visão mundialmente consolidada da Engenharia de Software; 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
24 
 Esclarecer o local e definir a divisa entre Engenharia de Software em relação a 
outras disciplinas, como ciência da computação, engenharia da computação e 
matemática; 
 Caracterizar o conteúdo da disciplina de Engenharia de Software; 
 Permitir acesso ao atual guia SWEBOK; 
 Fornecer uma base para o desenvolvimento curricular e para a certificação 
individual e material de licenciamento. 
De acordo com o guia SWEBOK (2004), a Engenharia de Software está organizada 
em dez áreas: 
 Requisito de Software: os requisitos de software explicam quais são as 
necessidades, restrições e as descrições do funcionamento de um sistema de 
software, segundo Sommerville (2011). De acordo com o SWEBOK (2004), esta 
área envolve a elicitação (levantamento), análise, especificação e a validação dos 
requisitos; 
 Design de Software: segundo o SWEBOK (2004), o conceito de design definido 
pela [IEEE610.12-90] é “o processo de definição da arquitetura, componentes, 
interfaces e outras características de um sistema ou componente”. Baseado nisto, é 
possível dizer que o design de software é a área onde será modelada a estrutura do 
software que será construído; 
 Construção de Software: segundo o SWEBOK (2004), esta área se refere à 
construção do software por meio de codificação, verificação, testes de unidade, 
testes de integração e debugging (depuração do software). Esta área está ligada a 
todas as áreas da Engenharia de Software, porém, está mais ligada às áreas de 
Design e Teste de Software, pelo fato do processo de construção do software 
envolvê-las significativamente; 
 Testes de Software: “O teste é destinado a mostrar que um programa faz o que é 
proposto fazer e para descobrir os defeitos do programa antes do uso”. 
(SOMMERVILLE, 2011). Isto quer dizer que, os testes são realizados para avaliar 
a qualidade do produto e através dos resultados, identificar os defeitos e problemas 
para que sejam corrigidos. Segundo SWEOK (2004), ao realizar testes de software, 
devem ser verificados os mais variados comportamentos do sistema, por que o 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
25 
sistema pode se comportar de forma diferente dependendo das informações que 
forem inseridas; 
 Manutenção de Software: segundo Sommerville (2011), o processo de 
manutenção do software ocorre quando são solicitadas mudanças no sistema após 
a sua publicação para uso. Existem três diferentes tipos de manutenção de 
software: Correção de defeitos; Adaptação ambiental; Adição de funcionalidade; 
 Gerenciamento de Configuração de Software: segundo Pressman (2006), o 
Gerenciamento de Configuração de Software é uma atividade aplicada durante 
todo o processo de construção de um software. É necessário identificar, organizar e 
controlar as modificações durante todo o ciclo de vida do software para melhorar a 
produtividade e diminuir os erros; 
 Gerenciamento de Engenharia de Software: o guia SWEBOK (2004) define 
Gerenciamento de Engenharia de Software como a administração das atividades de 
planejamento, coordenação, medição, monitoramento, controle e emissão de 
relatórios, a fim de assegurar que a construção e manutenção do sistema sejam 
organizadas, disciplinadas e quantificadas; 
 Processo de Engenharia de Software: segundo o SWEBOK (2004), o processo 
de Engenharia de Software esclarece as questões relacionadas aos processos de 
Engenharia de Software, envolvendo definição, implementação, avaliação, 
mensuração, gerenciamento, mudanças e melhorias do ciclo de vida de um 
software. O objetivo do processo de Engenharia de Software é colocar em prática, 
novos e melhores processos, sejam eles individuais, projetos ou organizacionais; 
 Ferramentas e Métodos de Engenharia de Software: de acordo com o 
SWEBOK (2004), as ferramentas de desenvolvimento têm como objetivo auxiliar 
nos processos de ciclo de vida do software. Estas ferramentas, quando bem 
aplicadas, reduzem a carga sobre os engenheiros de software permitindo que se 
concentrem em outras atividades. Os métodos de Engenharia de Software 
determinam uma estrutura sobre a atividade de Engenharia de Software com o 
objetivo de tornar as atividades organizadas e com maiores chances de obter 
sucesso; 
 Qualidade de Software: de acordo com o SWEBOK (2004), é uma área da 
Engenharia de Software que define as características de qualidade requeridas de 
um software e influencia os métodos de medição e os critériosde aceitação para 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
26 
avaliar essas características. Segundo Sommerville (2011), o processo de 
gerenciamento de qualidade busca garantir que o software a ser entregue atenda 
aos padrões e objetivos propostos. 
2.2 Engenharia de Requisitos 
Pressman (2006) define requisitos de sistema como o conjunto de descrições que 
auxiliam os engenheiros de software a entenderem o que o sistema deverá fazer, e como os 
usuários irão interagir com o sistema. 
Segundo Sommerville (2011), muitas vezes o requisito é apenas uma informação 
muito vaga sobre um determinado serviço, desta forma, Sommerville os divide entre 
requisitos de usuário, onde as informações são descritas em uma linguagem natural, sem 
muito detalhe e requisitos de sistema, onde as informações são descritas de forma mais 
detalhada sobre o comportamento do sistema. 
De acordo com Sommerville (2011), os requisitos de software são classificados em 
requisitos funcionais e requisitos não funcionais, onde: 
 Requisitos funcionais: São informações ligadas à funcionalidade do software, o 
que ele deve fornecer e como ele deve reagir a determinadas situações; 
 Requisitos não funcionais: São informações que explicam restrições que o 
software necessita atender ou qualidades que ele deve possuir. Incluem aspectos de 
desempenho, interfaces, segurança, confiabilidade, padrões, políticos e sociais. 
"O objetivo do processo de engenharia de requisitos é criar e manter um documento de 
requisitos de sistema." (SOMMERVILLE, 2007). A esse respeito, Sommerville (2011) atribui 
que os processos podem incluir quatro atividades com o intuito de estimar se o sistema é 
benéfico para a empresa (estudo de viabilidade), obtendo os requisitos (elicitação e análise), 
convertendo estes requisitos em um formato padrão (especificação), e validando se os 
requisitos estabelecem o sistema que o cliente deseja (validação). A Figura 4 ilustra estes 
processos e também a documentação gerada em cada um. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
27 
Figura 4 – Processos de engenharia de Software 
 
Fonte: SOMMERVILE (2007, p. 96). 
Sommerville (2011) cita que em quase todos os sistemas existem mudanças de 
requisitos, devido ao melhor entendimento do objetivo do sistema por parte do cliente, 
alterações no hardware, no software e na organização do sistema, para todas estas alterações 
de requisitos, é necessário que haja o chamado gerenciamento de requisitos. 
2.2.1 Estudo de viabilidade 
De acordo com Sommerville (2011), na construção ou na modificação de um sistema, 
é importante que seja feito um estudo de viabilidade para saber se serão atendidas as 
necessidades dos usuários, se o sistema será lucrativo caso seu objetivo seja a 
comercialização, se ele se enquadrará dentro da estimativa orçamentária prevista. Este 
processo deve ser rápido e barato em comparação ao sistema e seu resultado serve como base 
para dar continuidade ou não ao sistema. 
A esse respeito, Sommerville (2007) declara que, “a entrada para o estudo de 
viabilidade consiste de um conjunto preliminar de requisitos de negócios, um esboço da 
descrição do sistema e como o sistema pretende apoiar os processos de negócios”. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
28 
2.2.2 Elicitação e análise de requisitos 
De acordo com Sommerville (2011), neste processo os engenheiros de software 
reúnem junto às pessoas envolvidas no sistema (stakeholders
1
), os requisitos do sistema, 
sendo eles características que o sistema deve comtemplar, como ele deve se comportar, o 
desempenho que o sistema deve possuir, dentre outras. Conforme a Figura 5, o ciclo do 
processo de elicitação e análise iniciam na descoberta dos requisitos e termina na sua 
documentação. As atividades deste processo são: 
 Descoberta de requisitos: nesta atividade são descobertos com os stakeholders os 
requisitos do sistema; 
 Classificação e organização de requisitos: nesta atividade são classificados e 
organizados em grupos os requisitos levantados, normalmente nesta organização 
são identificados subsistemas e associados os requisitos a eles; 
 Priorização e negociação de requisitos: quando várias pessoas são envolvidas no 
levantamento de requisitos, a chance de existir conflitos em relação a priorização 
dos requisitos aumenta. Nesta atividade as divergências são encontradas, 
negociadas e os requisitos priorizados; 
 Especificação de requisitos: durante esta atividade, os requisitos que já foram 
descobertos são documentados e colocados no próximo ciclo de forma a auxiliar 
na descoberta de novos requisitos. 
 
1
 “Stakeholders do sistema é quem tem alguma influência direta ou indireta sobre os requisitos do sistema” 
(SOMMERVILLE, 2011). 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
29 
Figura 5 – Visão em espiral do processo de engenharia de software 
 
Fonte: SOMMERVILLE (2011, p. 70). 
Sommerville (2011) afirma que “elicitar e compreender os requisitos dos stakeholders 
do sistema é um processo difícil por várias razões”. Os stakeholders não costumam possuir o 
entendimento do que eles precisam de um sistema, explicam os requisitos em termos muito 
técnicos dificultando o entendimento do engenheiro de requisitos. Além das dificuldades 
envolvendo os stakeholders, mudanças organizacionais podem ocorrer durante a fase de 
análise, podendo surgir novos requisitos ou até mesmo alterações nos requisitos existentes. 
2.2.3 Validação de requisitos 
Segundo Pressmann (2006), a atividade de avaliação consiste em inspecionar os 
documentos de todos os requisitos a fim de garantir se os mesmos definem o sistema que o 
cliente deseja, avalia a consistência, completeza, precisão e que os erros tenham sido 
corrigidos. Sommerville (2011) complementa dizendo que se os erros não forem encontrados 
durante a fase de documentação, o custo para corrigi-los durante o desenvolvimento é muito 
maior. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
30 
De acordo com Sommerville (2011), diferentes tipos de verificações devem ser 
efetuados com os requisitos, são elas: Verificações de validade (o sistema deve disponibilizar 
funções que melhor suportam necessidades do cliente); Verificações de consistência (não 
deve haver conflitos entre requisitos); Verificações de completude (devem-se incluir todas as 
funções e restrições requeridas pelo cliente); Verificações de realismo (requisitos devem ser 
verificados considerando o orçamento e o cronograma); e Verificabilidade (os requisitos 
devem ser verificáveis para evitar conflito entre o cliente e o contratante). 
Sommerville (2011) ainda cita três técnicas de validação de requisitos: Revisões de 
requisitos (análise metódica dos requisitos em busca de erros e inconsistência); Prototipação 
(técnica usada para validar se o sistema atende as necessidades do cliente usando um modelo 
executável do sistema); Geração de casos de teste (desenvolvimento de testes para validar os 
requisitos). 
2.2.4 Gerenciamento de requisitos 
Pressman (2006) definegerenciamento de requisitos como “[...] um conjunto de 
atividades que ajudam a equipe de projeto a identificar, controlar e rastrear requisitos e 
modificações de requisitos em qualquer época, à medida que o projeto segue”. 
Segundo Sommerville (2011), em sistemas maiores é preciso automatizar com 
ferramentas de software para gerenciamento dos requisitos. Com o apoio destas ferramentas, 
será necessário manter os requisitos armazenados em um local seguro e de fácil acesso por 
parte dos envolvidos no processo, quando as ferramentas estiverem disponíveis, 
proporcionarão uma maior simplificação do processo de gerenciamento de requisitos e 
permitirão que seja possível descobrir a relação de requisitos relacionados. 
De acordo com Sommerville (2011), toda mudança solicitada após a aprovação dos 
requisitos devem ser gerenciadas no processo de gerenciamento de mudanças, pois é através 
dele que serão avaliados se irão ser desenvolvidas ou não. Conforme pode ser visto na Figura 
6, existem três estágios principais em um processo de gerenciamento de mudança: 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
31 
 Análise de problema e especificação de mudança: analisa-se o problema, ou a 
mudança para verificar sua validade; 
 Análise de mudanças e custos: verificar os efeitos da mudança por meio da 
rastreabilidade em outros requisitos para estimar o custo da mudança e decidir se 
dará continuidade a solicitação de mudança; 
 Implementação de mudanças: modificar o documento de requisitos e outros 
documentos para contemplar a mudança. 
Figura 6 – Gerenciamento de mudança de requisitos 
 
Fonte: SOMMERVILLE (2011, p. 79). 
2.3 Gerência de Projetos 
O guia Project Management Body of Knowledge (PMBOK) é considerado pelo 
Project Management Institute (PMI, 2008) como uma referência no processo de gerência de 
projetos para a construção de programas e certificações. O guia reúne informações que 
auxiliam os gerentes de projetos a aplicar nos gerenciamentos de projetos. 
PMBOK (PMI, 2008) define projeto como “[...] um esforço temporário empreendido 
para criar um produto, serviço ou resultado exclusivo”. Kerzner (2006) por sua vez, define 
projeto como “um empreendimento com objetivo bem definido, que consome recursos e 
opera sob pressões de prazos, custos e qualidade”. 
Segundo Sommerville (2011), é necessário que os projetos sejam gerenciados devido 
às mudanças que podem acontecer no decorrer de um projeto de software, sendo o gerente de 
projetos o responsável em assegurar que o projeto atenda e supere as mudanças no 
cronograma. Já para Kerzner (2006), “[...] gestão de projetos pode ser definida como o 
planejamento, a programação e o controle de uma série de tarefas integradas de forma a 
atingir seus objetivos com êxito, para benefício dos participantes do projeto”. O guia PMBOK 
(PMI, 2008), por sua vez, diz que “o gerenciamento de projetos é a aplicação de 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
32 
conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de entender 
os seus requisitos”. 
De acordo com Sommerville (2011), os projetos de Engenharia de Software são 
diferentes de outros projetos de engenharia por não serem passíveis de medição, ou seja, não é 
possível medir o andamento simplesmente olhando para o produto, outra diferença é que na 
maioria das vezes os projetos de software são projetos únicos, e diferentes das versões 
anteriores, tornando difícil até mesmo para gerentes mais experientes. Sommerville (2011) 
ainda cita quatro metas importantes necessárias para o sucesso no gerenciamento de projetos: 
 Fornecer o software ao cliente no prazo estabelecido; 
 Manter os custos gerais dentro do orçamento; 
 Entregar software que atenda às expectativas do cliente; 
 Manter uma equipe de desenvolvimento que trabalhe bem e feliz. 
2.3.1 Ciclo de vida e processos de gerenciamento do projeto 
O ciclo de vida de um projeto, conforme PMBOK (PMI, 2008), baseia-se em um 
conjunto de etapas que o projeto passa ao longo de sua vida, enquanto que os projetos 
possuem o início, meio e fim definidos. 
A Figura 7 apresenta o ciclo de vida de um projeto que segundo PMBOK (PMI, 2008), 
independente do tamanho e complexidade do projeto, todos podem ter seu ciclo de vida 
mapeado. Com base na figura, é possível visualizar as fases do ciclo de vida de um projeto: 
início do projeto, organização e preparação, execução do trabalho do projeto e por fim, 
encerramento do projeto. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
33 
Figura 7 – Nível típico de custo e pessoal ao logo do ciclo de vida 
 
Fonte: PMBOK (2008, p. 16). 
Através da Figura 7 é possível verificar que no início e no encerramento do projeto, os 
níveis de custos e de pessoal são mais baixos, e durante a sua execução, é atingido o valor 
mais alto. 
Segundo o PMBOK (PMI, 2008), os processos de gerenciamento de projetos são 
reunidos em cinco grupos: Grupo de processos de iniciação (autorizam o início de um novo 
projeto ou nova fase de um projeto); Grupo de processos de planejamento (definir o escopo 
do projeto a fim de criar uma estratégia para atingir os objetivos do projeto; Grupo de 
processos de execução (executam as ações definidas no plano de gerenciamento); Grupo de 
processos de monitoramento e controle (monitoram o andamento do projeto a fim de 
identificar e iniciar as mudanças); Grupo de processos de encerramento (finalizam 
formalmente o projeto através do encerramento das atividades), conforme pode ser visto na 
Figura 8. 
Figura 8 – Processos de Gerenciamento de Projetos 
 
Fonte:PMBOK (2008, p. 16). 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
34 
2.3.2 Áreas da Gerência de Projetos 
De acordo com o PMBOK (PMI, 2008), o gerenciamento de projetos é dividido em 
nove áreas de conhecimento, sendo: 
 Gerenciamento da Integração do Projeto: descreve as atividades e os processos 
que fazem parte do gerenciamento do projeto as quais são identificados, definidos, 
combinados, unificados e coordenados dentro do grupo de processos de 
gerenciamento de projetos; 
 Gerenciamento de Escopo do Projeto: descreve os processos utilizados para 
garantir que o projeto englobe todo o trabalho necessário para que seja finalizado 
com sucesso. O gerenciamento de escopo inclui processos de coleta de requisitos, 
onde é levantada a necessidade do cliente, a definição do escopo, a criação da 
Estrutura Analítica do Projeto (EAP), a verificação e o controle do escopo; 
 Gerenciamento do Tempo do Projeto: descreve os processos utilizados para 
administrar o andamento do projeto e garantir que o mesmo termine no prazo 
estabelecido. É necessário identificar as atividades, relacioná-las com outras 
atividades, estimar o quanto de recursos e prazos será necessário para realizá-las, 
desenvolver e controlar o cronograma para a realização das atividades; 
 Gerenciamento dos Custos do Projeto: descreve os processos utilizados para 
estimar os custos de um projeto, para garantir que o projeto seja concluído dentro 
do orçamento planejado. Neste processo é necessário estimar os custos dos 
recursos necessários para realizar as atividades, estabelecer um orçamento para 
custos e controlaros custos durante o andamento do projeto para que fique dentro 
do orçamento; 
 Gerenciamento da Qualidade do Projeto: descreve os processos utilizados para 
garantir, através de um monitoramento contínuo durante todo o projeto, a 
qualidade, os objetivos e as responsabilidades necessárias para atingir o propósito 
pelo qual o projeto foi construído; 
 Gerenciamento dos Recursos Humanos do Projeto: descreve os processos 
utilizados para organizar e gerenciar as pessoas envolvidas no projeto. Neste 
processo é necessário estabelecer um plano de recursos humanos, identificando e 
documentado as funções, responsabilidades e habilidades de cada membro, 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
35 
mobilizar e treinar a equipe, monitorar o desempenho dos membros durante o 
projeto; 
 Gerenciamento das Comunicações do Projeto: descreve os processos utilizados 
para garantir a coleta, registros e distribuição das informações do projeto. Neste 
processo é preciso identificar as pessoas envolvidas, determinar as necessidades de 
informação dos interessados, disponibilizar as informações aos envolvidos no 
projeto; 
 Gerenciamento dos Riscos do Projeto: descreve os processos utilizados para 
identificar, analisar e responder aos riscos de um projeto. Este gerenciamento tem 
como objetivo diminuir as chances de algo dar errado e por consequência, 
aumentar a possibilidade do projeto ser finalizado com sucesso; 
 Gerenciamento de Aquisições do Projeto: descreve os processos utilizados para 
comprar ou adquirir produtos, serviços externos ao projeto. Neste processo é 
preciso planejar as aquisições, fazendo o levantamento das necessidades, conduzir 
as negociações com os fornecedores e administrar as aquisições, avaliando o 
desempenho do contrato e realizando mudanças quando for preciso. 
2.4 Qualidade de Software 
De acordo com Pressman (2006), a qualidade de um software é o cumprimento dos 
requisitos, do desempenho, dos padrões e normas de desenvolvimento documentadas, que são 
desejadas no software que será desenvolvido. 
Segundo Sommerville (2011), é importante possuir e descrever um plano de qualidade 
que defina as qualidades desejadas para o software. Este plano não deve ser extenso, a fim de 
evitar que as pessoas não o leiam, podendo variar de um software para outro, dependendo do 
tipo de sistema, do tamanho, dentre outros. Possuir um documento que formalize o padrão 
esperado do software é importante, mas segundo Sommerville (2011), algumas pessoas 
acreditam que seguindo o padrão, terão um produto de alta qualidade, porém, o 
gerenciamento de qualidade é muito mais do que apenas um descritivo que deva ser seguido, 
é preciso criar uma cultura de qualidade em que toda equipe esteja comprometida em atingir 
um alto nível de qualidade. 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
36 
Em algumas empresas a equipe da qualidade é a mesma que realiza os testes, mas em 
outras, são equipes separadas, desta maneira, é necessário que a equipe de qualidade analise 
todos os registros dos testes para saber se foram realizados corretamente. Segundo Pressman 
(2006), para saber se atende ou não aos níveis estabelecidos, uma série de testes, revisões e 
inspeções são realizadas no decorrer do processo de criação do software. 
 Para Sommerville (2011), em pequenas empresas o gerenciamento de qualidade 
também é importante, porém não são necessários muitos padrões descritos para evitar a 
burocracia. Como as equipes normalmente são pequenas, é possível que haja uma 
comunicação informal entre elas, mas é importante que seja estabelecido uma cultura de 
qualidade para garantir que todos mantenham uma abordagem positiva da qualidade do 
software. 
Além de analisar se o software foi desenvolvido corretamente, é importante também 
observar os atributos não funcionais do sistema. “Boehm et al. (1978) sugeriam que havia 
quinze atributos importantes para a qualidade de software” (SOMMERVILLE, 2011), 
conforme Tabela 1. Ainda segundo Sommerville (2011), a confiança que um sistema passa, e 
o desempenho, são alguns dos fatores mais importantes na qualidade de um sistema. 
Tabela 1 – Atributos de qualidade de software 
Segurança Compreensibilidade Portabilidade 
Proteção Testabilidade Usabilidade 
Confiabilidade Adaptabilidade Reusabilidade 
Resiliência Modularidade Eficiência 
Robustez Complexidade Capacidade de aprendizado 
Fonte: Sommerville (2011, p. 458). 
Segundo Pressman (2006), revisar um software durante o seu processo de criação, 
serve como uma forma de descobrir e corrigir falhas. O objetivo de encontrar essas falhas 
durante o processo de criação é evitar que estas sejam descobertas após a entrega do software, 
reduzindo assim custos desnecessários. 
Segundo Koscianski e Soares (2006), os problemas mais comuns que surgem durante 
a criação de um software relatados em 1968 pelo Comitê de Ciência da NATO (North 
Atlantic Treaty Organization) são os mesmos de hoje em dia: cronogramas mal elaborados, 
projetos são abandonados em virtude de sua complexidade, diferentes módulos ao serem 
interligados não funcionam corretamente, softwares que não fazem o que era proposto fazer, 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
37 
sistemas com usabilidade complexa que não são mais utilizados e softwares que param de 
funcionar. 
2.5 CMMI 
De acordo com Chrissis, Konrad e Shrum (2007), o modelo CMMI é um modelo de 
maturidade para melhoria de processos designado para o desenvolvimento de produtos e 
serviços, composto pelas melhores práticas relacionadas às atividades de desenvolvimento e 
manutenção do ciclo de vida de um produto, desde sua iniciação, passando pela entrega e sua 
manutenção. O objetivo é auxiliar às organizações a melhorar os processos de 
desenvolvimento e manutenção de produtos e serviços. 
Conforme Chrissis, Konrad e Shrum (2007), o projeto CMMI foi criado para resolver 
o problema utilizando múltiplos CMMs. A missão inicial da Equipe do CMMI foi combinar 
três modelos em um modelo único que visa permitir a melhoria dos processos nas 
organizações através da sua implantação, conforme a Figura 9. 
 O Capability Maturity Model for Software (SW-CMM) v2.0 draft C [SEI 1997b]; 
 O Systems Engineering Capability Model (SECM) [EIA 1988]; 
 O Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 
[SEI 1997a]. 
Figura 9 – História do CMM 
 
Fonte: Adaptado pelo autor com base no livro CMMI for Development (Chrissis, Konrad e Shrum 2007, p. 15). 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
38 
De acordo com Chrissis, Konrad e Shrum (2007), o modelo CMMI utiliza níveis de 
classificação para determinar em que estágio a organização se encontra, para isto, o CMMI 
apresenta dois caminhos para melhoria. Um caminho que permite a melhoria de forma 
contínua dos processos a uma ou mais áreas da organização, chamado de “nível de 
capacidade”, e o outro caminho permite a melhoria de um conjunto de processos de um 
conjunto de áreas de processo, chamado “nível de maturidade”. 
Níveis de capacidade auxiliam na melhoria de forma contínua dos processos, bem 
como define o nível de capacidade desejado para determinada área da organização. Neste caso 
é importantesaber se o processo é “1 - Executado” ou “0 - Incompleto”. Existem seis níveis 
de capacidade numerados de 0 a 5, são eles: 
 0 (Incompleto): “[...] é um processo que não é executado ou é parcialmente 
executado. Um ou mais metas específicas da área de processo não são satisfeitas, e 
não existem metas genéricas para este nível, já que não há razão para 
institucionalizar um processo executado parcialmente” (Chrissis, Konrad e Shrum, 
2007, tradução nossa); 
 1 (Executado): “[...] é um processo que satisfaz metas específicas de uma área de 
processo. Ele suporta e habilita o trabalho necessário para produzir um produto de 
trabalho” (Chrissis, Konrad e Shrum, 2007, tradução nossa); 
 2 (Gerenciado): “É um processo executado que tem uma infraestrutura básica para 
suportar o processo. É planejado e executado de acordo com uma política 
(Chrissis, Konrad e Shrum, 2007, tradução nossa); 
 3 (Definido): “É um processo gerenciado e adaptado conforme os conjuntos de 
processos padrão da organização, contribuindo com os produtos de trabalho, 
medidas e outras informações de melhorias de processos.” (Chrissis, Konrad e 
Shrum, 2007, tradução nossa); 
 4 (Gerenciado Quantitativamente): é um processo definido controlado por meio 
de técnicas estatísticas e quantitativas. Objetivos quantitativos de qualidade e de 
desempenho do processo são aplicados como método de administração dos 
processos. Qualidade e desempenho são compreendidos em termos estatísticos e 
administrados ao logo da vida do processo (Chrissis, Konrad e Shrum, 2007); 
 5 (Em Otimização): é um processo gerenciado quantitativamente aperfeiçoado 
com apoio no entendimento das causas comuns de variação ligadas ao processo. O 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
39 
foco do processo otimizado é o aperfeiçoamento contínuo do desempenho do 
processo através de melhoria crescente e inovação (Chrissis, Konrad e Shrum, 
2007). 
Níveis de maturidade são associados à representação por estágio, auxilia na melhoria 
dos processos de um conjunto de áreas da organização, auxiliando na previsão dos resultados 
de futuros projetos. Como o foco principal não são os processos individuais, mas sim a 
organização em geral, o nível de maturidade parte de “1 – Inicial”. Existem cinco níveis de 
maturidade numerados de 1 a 5, são eles: 
 1 (Inicial): os processos normalmente são confusos, as organizações não possuem 
ambientes para auxiliar nos processos. Apesar destes problemas, as organizações 
do nível inicial normalmente desenvolvem produtos e serviços que funcionam, 
mas costumam exceder orçamentos e prazos (Chrissis, Konrad e Shrum, 2007); 
 2 (Gerenciado): os projetos possuem garantia que os processos que foram 
planejados, controlados, executados e revisados por pessoas experientes, com 
recursos adequados parar gerar o resultado esperado de acordo com o planejado 
(Chrissis, Konrad e Shrum, 2007); 
 3 (Definido): os processos são descritos em padrões, procedimentos, ferramentas e 
métodos, sendo bem caracterizados e entendidos. Os processos padrão utilizados 
para estabelecer padrões na organização e são melhorados no decorrer do tempo 
(Chrissis, Konrad e Shrum, 2007); 
 4 (Gerenciado Quantitativamente): a organização utiliza, como critério 
previamente estabelecido para gestão de processos, objetivos quantitativos para 
qualidade e para desempenho do processo. Os objetivos quantitativos são 
aplicados baseados nas necessidades dos usuários, e a qualidade e o desempenho 
são compreendidos em termos estatísticos e administrados ao longo da vida do 
processo (Chrissis, Konrad e Shrum, 2007); 
 5 (Em Otimização): “A organização melhora constantemente seus processos com 
base no entendimento quantitativo das causas de variação relativa ao processo” 
(Chrissis, Konrad e Shrum, 2007, tradução nossa). 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
40 
2.6 MPS.BR 
Conforme dito anteriormente de acordo com a Softex (2012), o intuito do programa 
MPS.BR é: 
 [...] definir e aprimorar um modelo de melhoria e avaliação de processo de software 
e serviços, visando preferencialmente às micro, pequenas e médias empresas 
(mPME), de forma a atender as suas necessidades de negócio e ser reconhecido 
nacional e internacionalmente como um modelo aplicável à indústria de software e 
serviços. 
2.6.1 Histórico 
Segundo a Softex (2012), o MPS.BR foi criado em 2003 com o intuito de melhorar os 
processos de desenvolvimento de software em empresas brasileiras, com base em normas e 
modelos internacionais, boas práticas da engenharia de software e as necessidades de 
negócios das empresas nacionais desenvolvedoras de software. O modelo é coordenado pela 
Softex e possui o apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI), Serviço 
Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE), Financiadora de Estudos e 
Projetos (FINEP) e Banco Interamericano de Desenvolvimento (BID). 
A Softex (2012) complementa que o MPS.BR possui a contribuição de representantes 
de universidades, centros de pesquisas, instituições governamentais e privadas para melhorias 
na qualidade do modelo através do apoio de duas estruturas para realização de suas atividades, 
o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica do Modelo (ETM). 
2.6.2 Objetivos 
O objetivo proposto pelo MPS.BR, segundo a Softex (2012), é melhorar o processo de 
software e serviços através de duas metas a serem atingidas a médio e longo prazo: 
 Meta técnica: visa criar e aprimorar o modelo para desenvolver o guia do modelo, 
possuir instituições credenciadas para implantar e avaliar os processos de melhoria 
B
D
U
 –
 B
ib
lio
te
ca
 D
ig
ita
l d
a 
U
N
IV
AT
E
S 
(h
tt
p:
//w
w
w
.u
ni
va
te
s.b
r/
bd
u)
 
 
41 
proposto pelo modelo e instituições credenciadas que prestam consultoria no 
processo de aquisição de software e/ou serviços; 
 Meta de negócio: visa espalhar e utilizar o modelo MPS em empresas de pequeno 
e médio porte, tendo estas como foco principal, e grandes organizações privadas e 
governamentais de todo o país. 
2.6.3 Estrutura 
O modelo MPS.BR, de acordo com a Softex (2012), está fundamentado nos conceitos 
de maturidade e capacidade de processo para a melhoria da qualidade dos produtos de 
software e serviços através de quatro componentes: Modelo de Referência MPS para Software 
(MR-MPS-SW), Modelo de Referência MPS para Serviços (MR-MPS-SV), Método de 
Avaliação (MA-MPS) e Modelo de Negócio (MNMPS). O modelo também está documentado 
em formato de guias, são eles: 
 Guia Geral para Software: o guia possui a descrição geral do modelo MPS e 
detalhada do modelo MR-MPS-SW, seus componentes e as definições essenciais 
para entendê-lo e aplicá-lo; 
 Guia Geral para Serviços: o guia possui a descrição geral do modelo MPS e 
detalhada do modelo MR-MPS-SV, seus componentes e as definições essenciais 
para entendê-lo e aplicá-lo; 
 Guia de Aquisição: o guia possui a descrição do processo necessário para auxiliar 
as organizações na aquisição de software e serviços com base no MR-MPS-SW; 
 Guia de Avaliação: o guia possui a descrição do processo e método de avaliação 
MA-MPS, e as ações necessárias para os avaliadores e instituições avaliadoras; 
 Guia de Implementação: o guia possui os documentos que contém as orientações 
para implementar nas organizações os níveis de maturidade descritos no modelo 
MR-MPS-SW.