ESTUDO PARA ADOÇÃO E IMPLANTAÇÃO DO NÍVEL G
DO MODELO MPS.BR NAS GERÊNCIAS DE SISTEMAS DE INFORMAÇÃO DAS IFES.
Área temática: Gestão pela Qualidade
Sérgio Luís Lima Corrêa
Mírian Picinini Méxas
Resumo: Currently, much has been discussed and studied ways to improve the software development process aimed
mainly quality. MPS.BR stands for Brazilian Software Process Improvement, proposed and developed by SOFTEX
which aims the improvement of software process and national services model. The MPS.BR is an adaptation of the
maturity of software development process model internationally known as CMMI. This article aims to study the
MPS.BR reference model and propose ways to implement the initial level of this model in G Managements Information
Systems of IFES. The methodology used was a literature review resulting in the identification of the main advantages
and difficulties in implementing the MPS.BR. As a contribution of this research proposes suggestions to minimize the
difficulties identified in order to achieve successful implementation of the model.
Palavras-chaves:
ISSN 1984-9354
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
2
1 - Introdução
Os ambientes de negócios têm sofrido constantes mudanças devido à globalização e acirrada
competição por espaço no mercado. A sustentabilidade e competitividade de determinada empresa
(pública ou privada) depende também da qualidade de seus produtos ou serviços.
Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na
melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção
e distribuição de software. (SOFTEX, 2012b, p. 5).
Segundo Fonseca (2011, p. 56), a implantação de um modelo internacional como CMMI, por
exemplo, demanda alto investimento. E o propósito do modelo MPS.BR é promover a melhoria do
software por meio do aprendizado das melhores práticas de desenvolvimento, a um custo acessível, em
menos tempo, de acordo com a realidade brasileira.
Embora, a atividade fim da IFES não seja a produção de software e sua missão seja
completamente adversa a isso, ainda assim, existe toda uma complexa estrutura tecnológica que visa
manter e disponibilizar a TI (Tecnologia da Informação) como ferramenta estratégica. Neste sentido,
toda IFES possui algum órgão ou setor dentro de seu organograma responsável pela mobilização de
recursos de TI em seu âmbito. Assim, suas práticas envolvem além da manutenção e disponibilização
de todo arcabouço tecnológico, a análise, modelagem, desenvolvimento, gerenciamento e atualização
dos Sistemas de Informação; o gerenciamento lógico da rede de dados, e ainda, o estudo e a
implementação de novas soluções tecnológicas na IFES.
Neste contexto, uma importante área é a Gerência de Sistemas de Informação, que atua
coordenando o desenvolvimento e a manutenção dos Sistemas de Informação da IFES e que necessita
da adoção constante de “boas práticas” que refletirão na melhoria na prestação de serviços de TI aos
seus clientes. Dentre as determinações que visam essa melhoria, está a adoção do modelo MPS.BR
como processo de melhoria de software, que é composto de sete níveis. Além disso, a instituição não
necessitará implementar todos os níveis de uma vez, pois este esforço pode ser realizado gradualmente
através dos níveis de maturidade do modelo.
Logo, este artigo tem por objetivo o estudo do modelo de referência para melhoria do processo
de software MPS.BR, apontando as principais vantagens e as dificuldades encontradas na sua
implementação, visando propor caminhos para a adoção deste modelo e sua implantação gradual nas
Gerências de Sistemas de Informação das IFES.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
3
Além da introdução, este artigo contém mais quatro capítulos. No capítulo 2, o referencial
teórico a respeito do modelo MR-MPS-BR é apresentado, focando principalmente o modelo de
referência para software MR-MPS-SW. No capítulo 3, a metodologia aplicada. O capítulo 4 contém as
considerações finais do artigo e o capítulo 5 as referências bibliográficas.
2 - Referencial Teórico
2.1) Processos de Software
Pressman (2011, p. 40) conceitua processo como um conjunto de atividades, ações e tarefas
realizadas na criação de algum produto de trabalho. No contexto da engenharia de software, um
processo é uma abordagem adaptável que possibilita realizar o trabalho de selecionar o conjunto
apropriado de ações e tarefas com intenção de entregar software dentro do prazo e com qualidade. No
entanto, Pressman (2011, p. 58) adverte que a existência de um processo de software não garante que o
software será entregue no prazo, que estará de acordo com a necessidade do cliente ou que terá
qualidade; e que devem ser combinados com uma prática de engenharia de software consistente.
Segundo Pressman (2011, p. 41), uma metodologia de processo genérica para engenharia de
software compreende cinco atividades: comunicação, planejamento, modelagem, construção e
emprego. Os detalhes do processo de software serão bem diferentes em cada caso de criação de
pequenos programas ou grandes aplicações, mas as atividades metodológicas serão as mesmas.
Ainda segundo Pressman (2011, p. 55), um padrão de processo descreve um problema de
processo encontrado durante o trabalho de engenharia de software, identificando o ambiente onde foi
encontrado e sugerindo uma ou mais soluções comprovadas para o problema. Em termos genéricos,
um padrão de processo fornece um modelo (template).
Sommerville (2011, p. 18) define um processo de software como um conjunto de atividades
relacionadas que levam à produção de software. Ainda segundo Sommerville (2011, p. 18), existem
muitos processos de software diferentes, mas todos incluem quatro atividades fundamentais para a
engenharia de software: 1) especificação de software; 2) projeto e implementação de software; 3)
validação de software e 4) evolução de software.
Sommerville (2011, p. 19), afirma ainda que os processos de software são complexos, que não
existe um processo ideal, e que podem ser melhorados pela padronização.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
4
Cunha; et al. (2011, p. 26) afirma que a busca pela padronização de um processo garante a
documentação concisa, facilitando a implementação dos modelos de maturidade. Assim, os processos
de software podem ser aprimorados por meio da padronização de processos.
Os negócios são dinâmicos, as regras de negócio mudam com o passar do tempo. Assim, além
das mudanças oriundas por força do negócio, os processos de software também demandam melhoria
contínua tanto para atender ao negócio da instituição quanto para melhor representarem a realidade.
2.2) O Modelo de Referência MR-MPS
O MPS.BR visa basicamente a melhoria da qualidade do software desenvolvido em instituições
públicas ou privadas segundo a realidade brasileira. Softex (2012b, p. 6) afirma que qualidade é fator
crítico de sucesso para a indústria de software; e que empresas produtoras de software visam alcançar
competitividade pela qualidade implicando na melhoria da qualidade dos produtos de software e
serviços correlatos. Outro objetivo do modelo é promover um setor de software competitivo
nacionalmente e internacionalmente.
Atualmente tem se dado muita importância ao processo como garantia de se obter um software
de qualidade e mais robusto quanto a falhas. A qualidade do software está diretamente ligada à
qualidade do processo utilizado no seu desenvolvimento. Além disso, a manutenção do software para
corrigir uma provável falha em sua execução, será mais facilmente corrigida quando houver um
processo formalizado, ou seja, documentado e gerenciado (planejado, monitorado e ajustado
(SOFTEX, 2012a, p.10)).
De acordo com Fernandes e Abreu (2012, p. 313), fica cada vez mais evidente que os processos
de software precisam ser tratados de forma integrada e interdisciplinar; e que abordagens integradas
desta natureza estão presentes nos modelos de maturidade criados para avaliar e acreditar nas
organizações de software.
Ainda segundo Fernandes e Abreu (2012, p. 330), em dezembro de 2003, a Softex lançou o
programa MPS.BR, baseado no modelo CMMI for Development (CMMI-DEV) (SEI, 2010a), no
modelo de avaliação de software ISO 15504 e nas melhores práticas de engenharia de software; e uma
de suas metas é disseminar o modelo por todo país, com custo e prazos razoáveis, tanto para o mercado
de pequenas empresas quanto para as grandes corporações.
Softex (2012, p. 4) define o Modelo MPS.BR como um programa mobilizador, de longo prazo,
criado em dezembro de 2003, coordenado pela Associação para Promoção da Excelência do Software
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
5
Brasileiro (SOFTEX), que conta com apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI),
Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas
Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID/FUMIN).
Segundo Softex (2012a, p. 12), uma das metas do Programa MPS-BR foi definir um modelo de
melhoria de processo de software e serviços, visando preferencialmente micro, pequenas e médias
empresas de forma a atender suas necessidades e ser reconhecido nacional e internacionalmente como
um modelo aplicável à indústria de software e serviços.
O modelo MPS é definido em consonância com a Norma Internacional ISO/IEC 12207:2008
(ISO/IEC, 2008a) e ISO/IEC 20000:2011 (ISO/IEC, 2011b), adaptando-a as necessidades da
comunidade de interesse. O MR-MPS-SW (Modelo de Referência MPS para Software) é compatível
com o CMMI-DEV (SEI, 2010a) e o MR-MPS-SV (Modelo de Referência MPS para Serviços) é
compatível com o CMMI-SVC (SEI, 2010b) (SOFTEX, 2012a, p. 13).
Boria; et al. (2013, p. 7) orienta que o MPS é um modelo de desenvolvimento organizacional
por níveis, que define os processos que a organização deve implementar e os resultados esperados
dessa ação, para ir avançando de nível em nível.
De acordo com Boria; et al. (2013, p. 33), o modelo MR-MPS é uma valiosa ferramenta que
permite à empresa interessada na melhoria de seus processos entender o que já tem implementado e o
que falta, além de sugerir os próximos passos. A desvantagem de um modelo é que os caminhos de
implementação são múltiplos e dependem da empresa em questão.
Ainda segundo Boria; et al. (2013, p. 35), no MR-MPS, à medida que a organização evolui
pelos níveis de maturidade, a capacidade para realizar os processos deve melhorar da mesma forma.
No entanto, os benefícios em termos de desempenho não surgem do rigor com que estes são
implementados, mas da cultura que é gerada por sua aplicação correta e consistente. A capacidade para
realizar os processos é manifestada pela implementação dos Atributos de Processo (AP), que por sua
vez é manifestada pela implementação dos Resultados esperados dos Atributos de Processo (RAP).
Kalinowski; et al., (2010, p. 12) afirma que o modelo MPS.BR é um mecanismo para
estabelecer um caminho economicamente viável para que organizações brasileiras alcancem os
benefícios da implementação de boas práticas da engenharia de software.
2.2.1) A estrutura do Modelo MR-MPS
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
6
Softex (2012a, p. 6) afirma que o modelo MPS baseia-se nos conceitos de maturidade e
capacidade de processo para a avaliação e melhoria da qualidade e produtividade de software e
serviços correlatos e que possui 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 (MN-MPS). Cada componente é descrito por meio de guias e/ou
documentos do programa MPS.BR:
Guia Geral MPS de Software: contém a descrição geral do modelo MPS e detalha o Modelo de
Referência MPS para Software (MR-MPS-SW), seus componentes e as definições comuns
necessárias para seu entendimento e aplicação;
Guia Geral MPS de Serviços: contém a descrição geral do modelo MPS e detalha o Modelo de
Referência MPS para Serviços (MR-MPS-SV), seus componentes e as definições comuns
necessárias para seu entendimento e aplicação;
Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É
descrito como forma de apoiar as instituições que queiram adquirir produtos de software e
serviços correlatos apoiando-se no MR-MPS-SW;
Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para
avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA);
Guia de Implementação: série de documentos que fornecem orientações para implementar nas
organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS-SW.
Softex (2012a, p. 13 e 14) descreve resumidamente o papel dos modelos e guias assim:
O Modelo de Referência MPS para Software MR-MPS-SW e para Serviços MR-MPS-SV
contém os requisitos que os processos das unidades organizacionais devem atender para estar
em conformidade com o MR-MPS-SW e MR-MPS-SV respectivamente;
O Guia de Aquisição é um documento complementar destinado a organizações que pretendam
adquirir software e serviços. O Guia de Aquisição não contém requisitos do MR-MPS-SW e
MR-MPS-SV, mas boas práticas para a aquisição de software e serviços;
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
7
O Guia de Implementação nas partes 1 a 7 sugere formas de implementar cada um dos níveis
do MR-MPS-SW. A parte 8 sugere formas de como uma unidade organizacional que faz
Aquisição de produtos pode implementar o MR-MPS-SW. As partes 9 e 10 sugerem formas
com que Fábricas de Software e Fábricas de Testes, respectivamente, podem implementar o
MR-MPS-SW. A parte 11 apresenta um mapeamento do MR-MPS-SW e o CMMI-DEV que
auxilia as organizações nas iniciativas de melhoria de processos de software multimodelos. As
explicações presentes no Guia de Implementação não constituem requisitos do modelo e devem
ser consideradas apenas em caráter informativo;
O Guia de Avaliação contém o processo e o método de avaliação MA-MPS;
O Modelo de Negócio MN-MPS descreve regras de negócio para implementação do MR-MPS-
SW e MR-MPS-SV pelas Instituições Implementadoras.
A seguir, a Figura 1 apresenta os componentes do Modelo MPS.
Figura 1: Componentes do Modelo MPS
Fonte: (SOFTEX, 2012a, p. 14)
Kalinowski; et al. (2010, p. 12) ressalta que o modelo MPS contém apenas resultados exigidos
para processos e para atributos de processo, não determinando os métodos, técnicas e ferramentas que
devem ser empregados para alcançar estes resultados.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
8
2.3) O Modelo de Referência MPS para Software (MR-MPS-SW)
Segundo Fernandes e Abreu (2012, p. 332), todos os guias são focados em cada um dos seus
sete níveis de maturidade e também em organizações específicas (que adquirem software, fábricas de
software e instituições avaliadoras).
O modelo MR-MPS-SW possui (3) guias: Guia Geral MPS de Software, Guia de Aquisição e
Guia de Implementação.
O Guia Geral MPS de Software contém as definições dos níveis de maturidade, processos e
atributos do processo; o Guia de Aquisição é um documento complementar para a aquisição de
software e o Guia de Implementação é uma série de treze documentos que fornecem orientações para
implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS-
SW.
2.3.1) Os Níveis de Maturidade
O Modelo de Referência MPS para Software (MR-MPS-SW) define níveis de maturidade que
são uma combinação entre processos e sua capacidade (SOFTEX, 2012a, p. 17).
De acordo com Fernandes e Abreu (2012, p. 333), corroborado por Softex (2012a, p. 17), os
níveis de maturidade do modelo MPS estabelecem patamares de evolução dos processos e representam
estágios de melhoria para a implementação de processos em uma organização. O nível de maturidade
em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais
processos.
Segundo Softex (2012a, p. 17), no modelo de referência para software MR-MPS-SW, a escala
de maturidade se inicia no nível G e progride até o nível A.
Ainda de acordo com Softex (2012a, p. 18), o progresso e o alcance de um determinado nível de
maturidade do MR-MPS-SW se obtêm quando são atendidos os propósitos e todos os resultados
esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos
para aquele nível. Esclarece ainda que o objetivo da divisão em 7 estágios é possibilitar uma
implementação e avaliação adequada às micros, pequenas e médias empresas. A possibilidade de se
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
9
realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de
melhoria de processos em prazos mais curtos.
Assim, o modelo MR-MPS-SW define (7) níveis de maturidade, mostrados a seguir no quadro
1.
Quadro 1 – Níveis de Maturidade do MR-MPS
A Em Otimização
B Gerenciado Quantitativamente
C Definido
D Largamente Definido
E Parcialmente Definido
F Gerenciado
G Parcialmente Gerenciado
Fonte: (FERNANDES e ABREU, 2012, p. 333)
No modelo MPS.BR, a instituição inicia no nível G (primeiro estágio de maturidade) e vai
progredindo gradualmente até o nível A (mais maduro). A seguir, o quadro 2 apresenta uma
comparação entre os níveis dos modelos CMMI e MPS.BR.
Quadro 2 – Comparação entre os níveis dos modelos CMMI e MPS.BR.
Níveis de Maturidade do CMMI Níveis de Maturidade do MPS.BR
5 A (Em Otimização)
4 B (Gerenciado Quantitativamente)
3,5 C (Definido)
3 D (Largamente Definido)
2,5 E (Parcialmente Definido)
2 F (Gerenciado)
1 G (Parcialmente Gerenciado
Fonte: Adaptado de (COUTO, 2007) apud (FONSECA, 2011, p. 60)
Segundo Kalinowski; et al. (2010, p. 6), cada um dos níveis de maturidade apresenta um
conjunto de processos e atributos de processos que indicam onde a instituição tem que investir esforço
para melhoria, de forma a atender aos seus objetivos de negócio e ao MR-MPS.
Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de
capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos
relacionados no nível de maturidade F (que também inclui os processos de nível G) (SOFTEX, 2012a,
p. 18).
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
10
2.3.2) Os Atributos de Processo do MR-MPS
Os processos no MR-MPS-SW são descritos em termos de propósito e resultados. O propósito
descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do
processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo
(SOFTEX, 2012a, p. 18). Ainda segundo Softex (2012a, p. 18), a capacidade do processo é
representada por um conjunto de atributos de processo (AP) descrito em termos de resultados
esperados.
Fernandes e Abreu (2012, p. 333) afirma que o MPS-BR possui dezenove processos,
distribuídos entre os níveis de maturidade. Fernandes e Abreu (2012, p. 336) afirma que o MPS-BR
possui nove atributos de processos (AP).
A seguir, o quadro 3 apresenta os Atributos de Processo do modelo MR-MPS.
Quadro 3 – Atributos de Processo do modelo MR-MPS
Atributos de Processo (AP) Mede o quanto ..
AP 1.1 (o processo é executado) O processo atinge seu propósito.
AP 2.1 (o processo é gerenciado) A execução do processo é gerenciada.
AP 2.2 (os produtos de trabalho do processo são
gerenciados)
Produtos de trabalho produzidos pelo processo são gerenciados
apropriadamente.
AP 3.1 (o processo é definido) Um processo padrão é mantido para apoiar a implementação do
processo definido.
AP 3.2 (o processo está implementado) O processo padrão é efetivamente implementado como um processo
definido para atingir seus resultados.
AP 4.1 (o processo é medido)
Os resultados de medição são usados para assegurar que a execução
do processo atinja os seus objetivos de desempenho e apoie o
alcance dos objetivos de negócio definidos.
AP 4.2 (o processo é controlado) O processo é controlado estatisticamente para produzir um processo
estável, capaz e previsível dentro de limites estabelecidos.
AP 5.1 (o processo é objeto de inovações)
As mudanças no processo são identificadas a partir da análise de
defeitos, problemas, causas comuns de variação de desempenho e
da investigação de enfoques inovadores para a definição e
implementação do processo.
AP 5.2 (o processo é otimizado continuamente)
As mudanças na definição, gerência e desempenho do processo têm
impacto efetivo para o alcance dos objetivos relevantes de melhoria
do processo.
Fonte: (FERNANDES e ABREU; 2012, p. 336)
Cada AP contém um conjunto de resultados de atributo de processo (RAP) utilizados para
avaliar a implementação de um AP (KALINOWSKI; et al., 2010, p. 6).
A seguir, o quadro 4 apresenta os Níveis de Maturidade, Processos e Atributos de Processo
correspondentes.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
11
Quadro 4 – Níveis de Maturidade, Processos e Atributos de Processo correspondentes
Nível Processos Capacidades (AP)
A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*, 5.1*, 5.2*
B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*
C Gerência de Riscos, Desenvolvimento para
Reutilização, Gerência de Decisões 1.1, 2.1, 2.2, 3.1, 3.2
D Desenvolvimento de Requisitos, Integração do
Produto, Projeto e Construção do Produto, Validação,
Verificação 1.1, 2.1, 2.2, 3.1, 3.2
E
Avaliação e Melhoria do Processo Organizacional,
Gerência de Projetos (evolução), Gerência de Recursos
Humanos, Gerência de Reutilização, Definição do
Processo Organizacional
1.1, 2.1, 2.2, 3.1, 3.2
F Aquisição, Garantia da Qualidade, Gerência de
Configuração, Gerência de Portfólio de Projetos,
Medição
1.1, 2.1, 2.2
G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1
Fonte: (KALINOWSKI; et al., 2010, p. 7)
Softex (2012a, p. 24) ressalta que alguns processos podem ser excluídos, total ou parcialmente,
do escopo de uma avaliação MPS por não serem pertinentes ao negócio da unidade organizacional que
está sendo avaliada. Cada exclusão deve ser justificada no Plano de Avaliação.
2.4) A implementação do MR-MPS-SW iniciando pelo nível G
O nível G é o primeiro nível de maturidade do MR-MPS-SW e o objetivo da implantação deste
nível é nortear a organização para que ela seja capaz de gerenciar parcialmente seus projetos de
desenvolvimento de software (CUNHA; et al., 2011, p. 23).
Dois pontos são desafiadores na implantação do nível G: (1) mudança de cultura
organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software; (2)
definição do conceito acerca do que é “projeto” para a organização (SOFTEX, 2012b, p. 7).
Boria; et al. (2013, p. 36) orienta que para uma empresa que não tem processos bem definidos e
que amadureça por meio dos níveis do MPS, começando pelo nível G: a empresa precisa, primeiro, ter
o controle das tarefas, a partir dos requisitos, para poder cumprir seus compromissos. Ao invés de
correr para implementar o que o cliente quer, a equipe faz uma pausa para planejar e entre as tarefas
planejadas está o monitoramento. Surge a cultura básica de projetos. Os benefícios do Nível G se
manifestam em um melhor foco no negócio, porque os compromissos assumidos são compreendidos e
honrados. Há entendimento suficiente do estado do projeto para administrar as expectativas dos
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
12
clientes e existe, da mesma maneira, uma maior transparência. O estado do projeto é comunicado e
compartilhado. As expectativas são documentadas, explicadas e a alta gerência trabalha com
informação verídica. O outro resultado importante deste nível é a instituição de uma nova disciplina,
pela qual as equipes revisam e atualizam os compromissos. Estes são respeitados e todos os esforços
são feitos para que isso seja realizado com transparência.
Como resultado da adoção dessas práticas espera-se que a Gerência de Sistemas melhore seu
desempenho, o que pode vir a ser um indicativo cumprido no PDTI (Plano Diretor de Tecnologia da
Informação) da instituição.
Segundo Cunha; et al. (2011, p. 25) os benefícios adquiridos pela implementação do nível G
são:
• Obtenção de base histórica dos projetos devido às atividades de documentação;
• Estabelecimento de plano de gerenciamento e acompanhamento dos projetos;
• Capacidade de gerenciar mudança de requisitos;
• Capacidade de medir de forma padronizada os esforços, prazos e custos dos projetos;
• Reconhecimento da organização no mercado de TI;
• Início da busca de padronização do processo.
A padronização do processo não é obrigatória para certificação do nível G do MPS.BR, apenas
para certificação do nível E. Conforme estudos de caso foi verificado que a maioria das empresas
busca a padronização do seu processo logo no início da implementação do nível G (CUNHA; et al.,
2011, p. 26).
A implementação dos níveis G e F é um passo significativo em uma organização de
desenvolvimento de software (KALINOWSKI; et al., 2010, p. 7).
2.4.1) O processo Gerência de Projetos (GPR)
O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as
atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento
do projeto que permitam a realização de correções quando houver desvios significativos no
desempenho do projeto (SOFTEX, 2012b, p. 7).
Softex (2012b, p. 9) recomenda ser conveniente definir o que é um projeto antes de entrar no
processo de Gerência de Projetos. No MPS.BR, a definição de projeto é “um empreendimento
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
13
realizado para criar um produto. O projeto se caracteriza por temporalidade e resultado, produto único
e elaboração progressiva”.
Softex (2012b, p. 10) tece comentários adicionais para implementação em diferentes tipos de
organização: adquirentes de software, fábrica de software e fábrica de teste; tecendo comentários
também para cada resultado esperado.
A Gerência de Projetos possui dezenove resultados esperados no nível G. A seguir, o quadro 5
apresenta os resultados esperados do processo de Gerência de Projetos no nível G.
Quadro 5 – Resultados esperados do processo de Gerência de Projetos no nível G
Sigla Resultados Esperados Comentários
GPR1 O escopo do trabalho para o projeto é definido O escopo do projeto define todo o trabalho necessário, e
somente ele, para entregar um produto que satisfaça as
necessidades, características e funções especificadas para o
projeto, de forma a concluí-lo com sucesso.
GPR2 As tarefas e os produtos de trabalho do projeto são
dimensionados utilizando métodos apropriados
O escopo do projeto, identificado na forma dos seus
principais produtos de trabalho e das tarefas do projeto, deve
agora ser decomposto em componentes menores, mais
facilmente gerenciáveis e possíveis de serem dimensionados.
GPR3 O modelo e as fases do ciclo de vida do projeto
são definidos
O ciclo de vida de um projeto consiste de fases e atividades
que são definidas de acordo com o escopo dos requisitos, as
estimativas para os recursos e a natureza do projeto, visando
oferecer maior controle gerencial.
GPR4 O esforço e o custo para a execução das tarefas e
dos produtos de trabalho são estimados com base
em dados históricos ou referências técnicas
As estimativas de esforço e custo são, normalmente,
baseadas nos resultados de análises utilizando modelos e/ou
dados históricos aplicados ao tamanho, atividades e outros
parâmetros de planejamento.
GPR5 O orçamento e o cronograma do projeto, incluindo
a definição de marcos e pontos de controle, são
estabelecidos e mantidos
As dependências entre tarefas são estabelecidas e potenciais
gargalos são identificados utilizando métodos apropriados
(por exemplo, análise de caminho crítico).
GPR6 Os riscos do projeto são identificados e o seu
impacto, probabilidade de ocorrência e prioridade
de tratamento são determinados e documentados
Projetos têm riscos e estes precisam ser dentificados,
analisados e priorizados.
GPR7 Os recursos humanos para o projeto são
planejados considerando o perfil e o conhecimento
necessários para executá-lo
O planejamento de recursos humanos determina funções,
responsabilidades e relações hierárquicas do projeto. As
funções do projeto podem ser designadas para pessoas ou
grupos, os quais podem ser internos ou externos à
organização.
GPR8 Os recursos e o ambiente de trabalho necessários
para executar o projeto são planejados
Faz referência à necessidade de se planejar, com base na
EAP (ou estrutura equivalente), as tarefas e prever os
recursos e o ambiente necessários, incluindo, por exemplo,
equipamentos, ferramentas, serviços, componentes, viagens e
requisitos de processo.
GPR9 Os dados relevantes do projeto são identificados e
planejados quanto à forma de coleta,
armazenamento e distribuição. Um mecanismo é
estabelecido para acessá-los, incluindo, se
pertinente, questões de privacidade e segurança
Os dados do projeto são as várias formas de documentação
exigidas para sua execução, por exemplo: relatórios; dados
informais; estudos e análises; atas de reuniões;
documentação; lições aprendidas; artefatos gerados; itens de
ação; e indicadores.
GPR10 Um plano geral para a execução do projeto é
estabelecido com a integração de planos
específicos
O objetivo deste resultado esperado é garantir que todos os
planos que afetam o projeto estejam integrados e que a
dependência entre estes planos tenha sido identificada e
levada em consideração durante o planejamento, conciliando
o trabalho a ser realizado aos recursos e condições
existentes.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
14
GPR11 A viabilidade de atingir as metas do projeto é
explicitamente avaliada considerando restrições e
recursos disponíveis. Se necessário, ajustes são
realizados
O estudo de viabilidade considera o escopo do projeto e
examina aspectos técnicos (requisitos e recursos), financeiros
(capacidade da organização) e humanos
(disponibilidade de pessoas com a capacitação necessária).
GPR12 O Plano do Projeto é revisado com todos os
interessados e o compromisso com ele é obtido e
mantido
Para obter compromissos dos interessados relevantes, é
importante revisar o planejamento com eles e conciliar as
diferenças existentes entre os recursos estimados e
disponíveis.
GPR13 O escopo, as tarefas, as estimativas, o orçamento e
o cronograma do projeto são monitorados em
relação ao planejado
A aderência aos diversos planos deve ser avaliada
continuamente durante todo o ciclo de vida do projeto.
GPR14 Os recursos materiais e humanos bem como os
dados relevantes do projeto são monitorados em
relação ao planejado
O objetivo deste resultado esperado é garantir que o projeto
seja monitorado em relação aos itens planejados referentes a
recursos materiais e recursos humanos (ver GPR7 e GPR8).
GPR15 Os riscos são monitorados em relação ao
planejado
No decorrer do projeto novos riscos podem ser identificados
para o projeto e os parâmetros dos riscos já identificados
podem ser alterados (ver GPR6).
GPR16 O envolvimento das partes interessadas no projeto
é planejado, monitorado e mantido
Devem ser identificados os interessados relevantes no
projeto, em que fases eles são importantes e como eles serão
envolvidos (comunicações, revisões em marcos de projeto,
comprometimentos, entre outros).
GPR17 Revisões são realizadas em marcos do projeto e
conforme estabelecido no planejamento
Revisões em marcos do projeto não devem ser confundidas
com o acompanhamento descrito em GPR13, GPR14 e
GPR15, que é derivado do acompanhamento do dia-a-dia do
projeto. Os marcos do projeto precisam, portanto, ser
previamente definidos ao se realizar o planejamento do
projeto.
GPR18 Registros de problemas identificados e o resultado
da análise de questões pertinentes, incluindo
dependências críticas, são estabelecidos e tratados
com as partes interessadas
As atividades de revisão em marcos (GPR17) e de
monitoramento (GPR13, GPR14 e GPR15) do projeto
possibilitam a identificação de problemas que estejam
ocorrendo nos projetos. É natural que problemas e desvios
em relação ao planejamento aconteçam durante a execução
dos projetos. Estes problemas e desvios devem ser analisados
e registrados, por exemplo, por meio de ferramentas
específicas, planilhas ou outros tipos de mecanismos de
gerenciamento de problemas.
GPR19 Ações para corrigir desvios em relação ao
planejado e para prevenir a repetição dos
problemas identificados são estabelecidas,
implementadas e acompanhadas até a sua
conclusão
Como resultado do acompanhamento do projeto (GPR13,
GPR14 e GPR15) e das revisões em marcos (GPR17),
problemas são identificados, analisados e registrados
(GPR18). Ações corretivas devem ser estabelecidas para
resolver problemas que possam impedir o projeto de atingir
seus objetivos se não forem resolvidos de forma adequada.
Fonte: Adaptado de (SOFTEX, 2012b, p. 11-29)
2.4.2) O processo Gerência de Requisitos (GRE)
O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos
componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do
projeto e os produtos de trabalho do projeto. (SOFTEX, 2012b, p. 30).
Softex (2012b, p. 30) orienta que esse processo gerencia todos os requisitos recebidos ou
gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, bem como os requisitos
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
15
impostos ao projeto pela organização. Outra atribuição do processo é documentar as mudanças nos
requisitos e suas justificativas.
Softex (2012b, p. 31) orienta que é fundamental para assegurar um bom entendimento das
necessidades do cliente e dos requisitos do projeto e, consequentemente, aumentar as chances de
sucesso do projeto. E ainda, que cabe á Gerência de Requisitos identificar os requisitos do produto e
dos componentes do produto do projeto, bem como estabelecer e manter um acordo entre o cliente e a
equipe de projeto sobre esses requisitos; também é objetivo da Gerência de Requisitos controlar e
tratar as mudanças nos requisitos ao longo do desenvolvimento.
Softex (2012b, p. 30) tece comentários adicionais para implementação em diferentes tipos de
organização: adquirentes de software, fábrica de software e fábrica de teste; tecendo comentários
também para cada resultado esperado.
A Gerência de Requisitos possui cinco resultados esperados no nível G. A seguir, o quadro 6
apresenta os resultados esperados do processo de Gerência de Requisitos no nível G.
Quadro 6 – Resultados esperados do processo de Gerência de Requisitos no nível G
Sigla Resultados Esperados Comentários
GRE1 O entendimento dos requisitos é obtido junto aos
fornecedores de requisitos
O objetivo deste resultado é garantir que os requisitos
estejam claramente definidos a partir do entendimento dos
requisitos realizado junto aos fornecedores de requisitos.
Informações sobre esses fornecedores podem ser
identificadas no plano
do projeto, bem como informações sobre como será a
comunicação com eles. Essas comunicações devem ser
registradas formalmente em atas, e-mails, ferramentas de
comunicação ou outros meios.
GRE2 Os requisitos são avaliados com base em critérios
objetivos e um comprometimento da equipe técnica
com estes requisitos é obtido
A avaliação e aprovação por parte do cliente após o
entendimento dos requisitos por si só não é suficiente para
que os requisitos sejam refinados e refletidos em modelos
de análise e projeto para a codificação. A avaliação dos
requisitos deve envolver, além do cliente, também, a
equipe técnica da organização, podendo ser realizada de
diversas formas.
GRE3 A rastreabilidade bidirecional entre os requisitos e os
produtos de trabalho é estabelecida e mantida
Este resultado indica a necessidade de se estabelecer um
mecanismo que permita rastrear a dependência entre os
requisitos e os produtos de trabalho. Ter definida a
rastreabilidade facilita a avaliação do impacto das
mudanças de requisitos que possam ocorrer, por exemplo,
nas estimativas do escopo, nos produtos de trabalho ou nas
tarefas do projeto descritas no cronograma.
GRE4 Revisões em planos e produtos de trabalho do
projeto são realizadas visando a identificar e corrigir
inconsistências em relação aos requisitos
A consistência entre os requisitos e os produtos de
trabalho do projeto deve ser avaliada e os problemas
identificados devem ser corrigidos.
GRE5 Mudanças nos requisitos são gerenciadas ao longo
do projeto
Durante o projeto, os requisitos podem mudar por uma
série de motivos. Destaforma, requisitos adicionais podem
ser incorporados no projeto, requisitos podem ser retirados
do projeto e/ou mudanças podem ser feitas nos requisitos
já existentes.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
16
Fonte: Adaptado de (SOFTEX, 2012b, p. 32-37)
2.4.3) Os Atributos de Processo do nível G
Softex (2012a, p. 18) orienta que no modelo MR-MPS-SW, à medida que a organização evolui
nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser
atingido. E que o atendimento aos atributos do processo (AP), pelo atendimento aos resultados
esperados dos atributos do processo (RAP), é requerido para todos os processos no nível
correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo.
Numa avaliação, segundo o MA-MPS, é exigido, para se considerar um processo
“SATISFEITO” no nível G, que o atributo de processo AP 1.1 seja caracterizado como T (Totalmente
implementado) e que o atributo de processo AP 2.1 seja caracterizado como T (Totalmente
implementado) ou L (Largamente implementado) (SOFTEX, 2012b, p. 38).
A seguir no quadro 7, os atributos de processo AP 1.1 e AP 2.1, aplicáveis no nível G, são
descritos com detalhes.
Quadro 7 – Atributos de Processo AP 1.1 e AP 2.1 no nível G
Atributo de Processo Comentário Resultado Esperado
AP 1.1 - O processo é
executado
Este atributo evidencia o
quanto o processo atinge o
seu propósito.
RAP1 - O processo atinge seus resultados definidos
AP 2.1 - O processo é
gerenciado
Este atributo evidencia o
quanto a execução do
processo é gerenciada.
RAP2 - Existe uma política organizacional estabelecida e
mantida para o processo
RAP3 - A execução do processo é planejada
RAP4 - (Para o nível G) A execução do processo é
monitorada e ajustes são realizados
RAP5 - As informações e os recursos necessários para a
execução do processo são identificados e
disponibilizados
RAP6 - (Até o nível F) As responsabilidades e a
autoridade para executar o processo são definidas,
atribuídas e comunicadas
RAP7 - As pessoas que executam o processo são
competentes em termos de formação, treinamento e
experiência
RAP8 - A comunicação entre as partes interessadas no
processo é planejada e executada de forma a garantir o
seu envolvimento
RAP9 - (Até o nível F) Os resultados do processo são
revistos com a gerência de alto nível para fornecer
visibilidade sobre a sua situação na organização
RAP10 - (Para o nível G) O processo planejado para o
projeto é executado
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
17
Fonte: Adaptado de (SOFTEX, 2012b, p. 39-42)
2.5) Vantagens e dificuldades na implementação do MR-MPS-SW
Segundo Rodrigues; Kirner (2010, p. 43), as principais vantagens ou benefícios adquiridos com
a implementação do modelo, destacados na literatura, são: melhoria no gerenciamento de projetos de
desenvolvimento; redução de custos; menor tempo de resposta; aumento de produtividade; melhoria no
cumprimento de prazos e custos; entre outras.
Segundo Rodrigues; Kirner (2010, p. 44), as dificuldades enfrentadas com a implementação do
modelo, destacados na literatura, são: limitação de recursos humanos; limitação de recursos
financeiros; falta de comprometimento gerencial; resistência a mudanças por parte dos colaboradores;
treinamentos inadequados ou insuficientes; falta de consultoria adequada; entre outras.
2.6) Sugestões para implementação do MR-MPS-SW
Em média, as empresas gastaram 1 (um) ano e 6 (seis) meses para implementar o modelo de
melhoria de processo MPS.BR Nível G (CUNHA; et al., 2011, p. 28).
Nas conclusões do trabalho de Cunha; et al. (2011, p. 28-29), onde foram realizados estudos de
caso em quatro empresas que passaram pelo processo de implementação e que também obtiveram a
certificação no nível G, foi possível detectar algumas experiências ou recomendações importantes para
implementação do nível G do modelo MPS.BR tais como:
A padronização dos processos pode permitir maior definição de uma metodologia de
desenvolvimento para orientar os colaboradores no desenvolvimento de suas atividades;
A necessidade da formação de uma equipe de implementação estimulando a participação
integral de todos colaboradores;
A necessidade que a equipe de implementação tenha pelo menos 2 (dois) integrantes
consultores de instituições implementadoras. Com o auxílio desses consultores, a
instituição pode criar uma nova metodologia de desenvolvimento durante a implementação
do modelo de melhoria de software;
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
18
A produção de artefatos exigidos pela implementação do modelo exige mais tempo de
trabalho tornando o processo pouco produtivo; e isso pode criar uma resistência dos
colaboradores em relação às mudanças ocorridas em suas atividades diárias;
O tempo disponibilizado para a auditoria do processo é insuficiente para apresentar todos
os resultados esperados, aumentando a possibilidade de erros de interpretação das
evidências;
A qualidade do serviço prestado pela consultoria é melhor, quando as instituições são da
mesma região;
As orientações apresentadas no Guia de Implementação do modelo MPS.BR trazem
informações “do que deve ser feito”, mas não ofereceram sugestões suficientes e objetivas
de “como devem ser feito”;
Basear somente na documentação disponibilizada pela Softex não foi suficiente para
implementar o processo proposto pelo modelo MPS.BR, tornando as empresas
dependentes de consultorias externas.
Ainda segundo as conclusões do trabalho de Cunha; et al. (2011, p. 29), a implementação do
modelo MPS.BR foi relevante pela identificação de melhoria dos processos e pelos benefícios obtidos
pelas empresas participantes, embora essas mesmas empresas apontem dificuldades significativas para
a efetiva implementação do modelo.
3 – Metodologia
A metodologia deste artigo de natureza qualitativa, iniciou-se com uma pesquisa bibliográfica
para a compreensão de conceitos sobre melhoria de processo de software e em seguida do modelo de
referência MPS.BR. Este tipo de pesquisa é desenvolvido a partir de material já elaborado, constituído
principalmente de livros e artigos científicos (GIL, 2008, p. 50).
Baseado na revisão da literatura foi possível também entender o modelo MPS.BR e identificar
sugestões e recomendações visando a implementação do nível G do modelo MR-MPS para a melhoria
de processo de software nas Gerências de Sistemas de Informação das IFES.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
19
Segundo Moresi (2003, p. 9), a natureza da pesquisa qualitativa é descritiva e não requer o uso
de métodos e técnicas estatísticas. Quanto aos fins, essa pesquisa pode ser considerada descritiva e
explicativa. Segundo Gil (2008, p. 28), as pesquisas descritivas têm como objetivo a descrição das
características de determinada população ou fenômeno ou o estabelecimento de relações entre
variáveis; as pesquisas explicativas têm como objetivo identificar os fatores que determinam ou que
contribuem para a ocorrência dos fenômenos.
4 – Considerações Finais
O objetivo desse estudo do modelo para melhoria do processo de software MPS.BR foi
bastante elucidador, visto que foram observadas as principais vantagens e as principais dificuldades
encontradas na literatura sobre a implementação do modelo. As sugestões apresentadas por Cunha; et
al. (2011, p. 29), foram elencadas e, de certa forma, tem por objetivo minimizar as dificuldades
relatadas em trabalhos de outros autores.
Então, através da revisão da literatura e de experiências relatadas nesse trabalho, sugere-se que
as implementações em outras empresas sejam levadas em consideração para se evitar procedimentos
equivocados e colocar ênfase nos procedimentos corretos. Logicamente, devem ser guardadas as
proporções das particularidades inerentes a cada instituição que busquem passar pelo processo de
implementação do modelo MPS.BR.
Conclui-se, portanto, que para se atingir o objetivo da adoção, implementação e a respectiva
avaliação no nível G do modelo MPS.BR na Gerência de Sistemas de Informação das IFES, além das
experiências ou recomendações relatadas nessa pesquisa, outros fatores bastante importantes também
devem ser levados em consideração:
(1) apoio irrestrito da administração superior;
(2) estabelecimento de metas claras;
(3) capacitação prévia dos colaboradores envolvidos na implementação do modelo MPS.BR;
(4) minimização da causa de resistência à mudanças por parte dos colaboradores através da
conscientização dos benefícios a serem alcançados;
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
20
(5) IFES são instituições públicas onde existe certa burocracia regulatória, tornando-se
necessário licitar previamente o serviço externo de consultoria e avaliação para evitar
atrasos ou insucesso da implementação do modelo MPS.BR.
5 – Referências Bibliográficas:
BORIA, Jorge Luiz; RUBINSTEIN, Viviana L.; RUBINSTEIN, Andrés. A História da Tahini-
Tahini: Melhoria de Processos de Software com Métodos Ágeis e Modelo MPS. 9. ed. Brasília:
Ministério da Ciência, Tecnologia e Inovação, 2013. 201 p.
CUNHA, Izabella B. A.; DIAS, Kesia J.A.N.; RESENDE JUNIOR, Humberto C. Dificuldades
encontradas na implementação MPS.BR Nível G: Estudo de Caso. 2011. Disponível em: <
http://revistas.unibh.br/index.php/dcet/article/view/330>. Acesso em: 22 dez. 2014.
FERNANDES, Aguinaldo A.; ABREU, Vladimir F. Implantando a GOVERNANÇA DE TI: da
Estratégia à Gestão de Processos e Serviços. – 3. ed. – Rio de Janeiro: Brasport, 2012. 615 p.
FLICK, Uwe. Introdução à Metodologia de Pesquisa: um guia para iniciantes. – 1. ed. – São Paulo:
Penso Editora, 2012. 256 p.
FONSECA, Letícia R. Um Caso de Simbiose entre o Modelo “Melhoria de Processos do Software
Brasileiro” (MpsBr) e Aprendizagem Organizacional: um Estudo em uma Organização de
Desenvolvimento de Software. 2011. Disponível em: <http://revistagt.fpl.edu.br/get/article/view/282>.
Acesso em: 22 dez. 2014.
GIL, Antônio Carlos. Métodos e técnicas de pesquisa social. – 6. ed. – São Paulo: Atlas, 2008. 206 p.
ISO/IEC (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL
ELECTROTECHNICAL COMISSION). ISO/IEC 12207 Systems and software engineering–Software
life cycle processes, Geneve: ISO, 2008a.
ISO/IEC (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL
ELECTROTECHNICAL COMISSION). ISO/IEC 20000 Information Technology–Service
Management, Geneve: ISO, 2011b.
KALINOWSKI, Marcos et al. MPS.BR: Promovendo a Adoção de Boas Práticas de Engenharia
de Software pela Indústria Brasileira. In: CIBSE – XIII CONGRESO IBEROAMERICANO EN
“SOFTWARE ENGINEERING”, 13., 2010, Cuenca. Rio de Janeiro: Softex, 2010. p. 12 - 16.
Disponível em: <http://www.softex.br/wp-
content/uploads/2013/09/CIBSE2010_MPSBR_CameraReady.pdf>. Acesso em: 27 nov. 2014.
MORESI, Eduardo (Organizador). Pró-reitoria de Pós-graduação – PRPG (Org.). Metodologia da
Pesquisa. Brasília: Universidade Católica de Brasília – UCB, 2003. 108 p. Disponível em:
<http://www.inf.ufes.br/~falbo/files/MetodologiaPesquisa-Moresi2003.pdf>. Acesso em: 27 jun. 2014.
XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015
21
PMI. A guide to the Project Management Body of Knowledge (PMBOK) – Fifth edition –
Newtown Square, 2013. Disponível em:
<http://quantfinancenotes.files.wordpress.com/2013/09/project-management-body-of-knowledge-
pmbok-guide-5th-ed.pdf>. Acesso em: 30 mai. 2014.
PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. – 7. ed. – Porto
Alegre: AMGH, 2011. 780 p.
RODRIGUES, Juliana França; KIRNER, Teresa Gonçalves. Benefícios, Fatores de Sucesso e
Dificuldades da Implantação do Modelo MPS.BR. Disponível em:
<http://www.lbd.dcc.ufmg.br/colecoes/sbqs/2010/TT3_rodrigues.pdf>. Acesso em: 09 jan. 2012.
SEI (SOFTWARE ENGINEERING INSTITUTE). CMMI for Development (CMMI-DEV), Version
1.3, Technical Report CMU/SEI-2010-TR-033.Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 2010a. Disponível em: <http://www.sei.cmu.edu/reports/10tr033.pdf>.
Acesso em: 22 jan. 2013.
SEI (SOFTWARE ENGINEERING INSTITUTE). CMMI for Services, Version 1.3, Technical
Report CMU/SEI-2010-TR-034.Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon
University, 2010b.
SOFTEX (ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO). MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral MPS de
Software. São Paulo, 2012a. Disponível em: <http://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012.pdf>. Acesso em: 22 jan. 2013.
SOFTEX (ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO). MPS.BR - Melhoria de Processo do Software Brasileiro: Guia de Implementação –
Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW:2012. São Paulo, 2012b.
Disponível em: < http://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_de_Implementacao_Parte_1_2013.1.pdf>. Acesso em: 22
jan. 2013.
SOMMERVILLE, Ian. Engenharia de Software. – 9. ed. – São Paulo: Pearson Prentice Hall, 2011.
529 p.
WIKIDOT. MPS.BR Qualidade de Software: Melhoria de Processos do Software Brasileiro -
MPS.BR. Disponível em: <http://qualidade.wikidot.com/mpsbr-qualidade-de-software>. Acesso em:
28 nov. 2013.