ANÁLISE DE RISCOS NA IMPLANTAÇÃO DO MPS.BR VIVIANE ALEIXO DE PAULA XAVIER

Prévia do material em texto

Análise de riscos na implementação do MPS.BR em um setor de 
desenvolvimento de software de uma indústria. 
 
 
Viviane Aleixo de Paula Xavier (Instituto Döll de Tecnologia e Educação) mmsalei@gmail.com 
 Renato Ferraz Machado (QualityFocus – Consultoria e Serviços) renato@qualityfocus.com.br 
 
 
Resumo: 
A melhoria de processos de software é um dos principais objetivos da indústria de desenvolvimento de 
software brasileira. As organizações de desenvolvimento de software estão cada vez mais preocupadas 
em adotar programas de melhoria a fim de obter maior competitividade e garantir sua sobrevivência no 
mercado [Chaves et al. 2011]. No entanto, diversos fatores podem dificultar a implantação destes 
programas de melhoria devido à complexidade desta atividade. Por isso é relevante uma análise 
profunda dos fatores críticos de sucesso que podem ocorrer durante o processo. 
Este artigo apresenta os principais fatores críticos de sucesso na Implementação do MPS.BR sob o ponto 
de vista de um setor de desenvolvimento de software em uma indústria. 
Palavras chave: MPS.BR, Fatores Críticos de Sucesso, Melhoria de Processos de Software. 
 
 
Risk analysis in the implementation of the MPS.BR in a sector of 
software development of an industry. 
 
 
Abstract 
Software process improvement is one of the main goals of the Brazilian software development industry. 
Software development organizations are increasingly concerned with the adoption of improvement 
programs in order to achieve greater competitiveness and ensure their survival in the market [Chaves et 
al. 2011]. However, several factors may hinder the implementation of these programs improvement due 
to the complexity of this activity. That is why important a deep analysis of critical success factors that 
can occur during the process. 
 
 
This paper presents the main critical success factors in implementing the MPS.BR from the point of 
view of a software development sector in an industry. 
Key-words: MPS.BR, Critical Success Factors, Software Process Improvement. 
 
 
 
1. Introdução 
Na implementação de Melhoria de Processos de Software é preciso compreender quais os 
possíveis Fatores críticos de sucesso (FCS). Com o conhecimento dos FCS é possível as 
organizações conhecerem as possíveis dificuldades que serão encontradas no programa de 
Melhoria de Processos de Software, bem como manter esse processo após a avaliação não 
somente no processo de desenvolvimento, mas na manutenção dos processos de softwares. A 
compreensão e o entendimento dos fatores críticos de sucesso em iniciativas de melhoria de 
processos de software é tão fundamental quanto a questão da implementação com sucesso 
dessas melhorias [MONTONI E ROCHA, 2011]. 
Para as organizações conseguirem obter um bom resultado no programa de Melhoria de 
Processos de Software é preciso investigar a percepção das pessoas envolvidas no programa 
sobre os FCS que levam as organizações de desenvolvimento de softwares a dar continuidade 
ou não nas iniciativas de melhoria de processos. 
Com a implementação de um programa de melhoria de processos de software é possível obter 
muitos benefícios para as organizações, como maior competitividade em relação a empresas do 
mesmo segmento, diminuir os custos dos projetos, bem como a diminuição dos esforços 
dedicados na vida útil de cada projeto, além desses detalhes as organizações precisam se 
preocupar com a qualidade do processo para então conseguir uma maior produtividade [Rocha 
et al., 2005]. Porém, o sucesso de programas de melhoria de processos de software depende de 
muitos fatores. Levando em consideração que a empresa não passou pela avaliação do processo, 
no artigo será feita uma análise de riscos que podem ocorrer durante a implantação. 
Este artigo está estruturado da seguinte forma: seção 1 apresenta a Introdução, seção 2 apresenta 
os estudos relacionados aos fatores críticos de sucesso, seção 3 apresenta uma breve descrição 
do perfil da empresa, objetivo do projeto e a pesquisa de campo realizada, a seção 4 apresenta 
os resultados e discussões que ocorreram durante a pesquisa. Por fim a seção 5 apresenta as 
conclusões finais deste artigo 
 
 
2. Estudos relacionados 
Uma lista abrangente e bem fundamentada e que pode ser aplicável para implementações de TI 
em geral, segundo Cater-Steel e Pollard (2008), foi desenvolvida na pesquisa de Somers e 
Nelson (2001). Essa lista mostra os Fatores Críticos de Sucesso baseados em implementações 
de TI, reengenharia de processos de negócio e gerenciamento de projetos durante 
implementações de sistemas de gestão (ERP) em 86 empresas americanas. O resultado dessa 
pesquisa gerou uma sequência de 22 FCS, como: suporte da alta gerência; competência da 
equipe de projetos; cooperação e comunicação interdepartamental; suporte de fornecedores, 
entre outros. 
A pesquisa de Santos et al. (2011), explora a influência dos aspectos humanos nos programas 
de melhoria de processos de software. Muitos dos FCS encontrados pelos autores são 
coincidentes com aqueles levantados na pesquisa de Somers e Nelson (2001). 
 
Fatores Críticos de Sucesso 
Caeter-
Steel e 
Pollard 
(2008) 
Somers e 
Nelson 
(2001) 
Hochstein, 
Tamm e 
Brenner 
(2005) 
Tan et 
al. 
(2007) 
Montoni 
e Rocha 
(2011) 
Santos 
et al. 
(2011) 
Suporte da alta gerência x x x x x x 
Treinamento/desenvolvimento pessoal x x x x x x 
Equipes virtuais de projetos x x x x 
Seleção criteriosa de software x x x x 
Uso de consultores x x x x 
Comunicação e colaboração 
interdepartamental x 
 
x 
 
x x 
Pequenos ganhos x x 
Melhoria contínua x x 
Campanhas de Marketing x 
Parceria com fornecedores x x x x 
Uso de comitê diretivo x x x x 
Plano de benefícios para realizações x x 
Sucesso nas mudanças x x x 
Planejar e reforçar os objetivos do projeto x x 
Disponibilização de recursos x x 
Prioridade em processos x x x 
Cultura amigável dos modelos x x x 
Métricas focadas no cliente x x 
 
 
Tabela 1 - Comparação de FCS com outros estudos, adaptado de Cater-Steel e Pollard (2008) 
3. Implantação na Empresa A 
3.1 Perfil da Empresa 
A empresa terá sua identidade preservada e será identificada como Empresa A. 
Desde 1995 a Empresa A, dedica-se a satisfazer com eficiência e qualidade todas as 
necessidades de seus clientes, desenvolvendo toda uma gama de produtos e equipamentos com 
soluções integradas, gerando um novo conceito em logística, dedicando-se à soluções 
inteligentes em logística e movimentação de cargas garantindo como resultado, alta eficiência 
e qualidade em seus produtos (transelevadores com garfo simples e dupla profundidade, carro 
satélite, roletes e correia, miniloads, transportadores horizontais de roletes e correntes, mesas 
elevatórias hidráulicas, mesas giratórias, carros de transferência, elevadores monta-cargas, 
distribuição de produtos utilizando pick-to-light e projetos especiais). 
Os projetos desenvolvidos pela Empresa A atendem os mais diversos segmentos, como 
equipamentos para a indústria automotiva, indústria alimentícia, indústria farmacêutica entre 
outras. 
A empresa A não é uma fábrica de software, apenas possui um setor de TI o qual tem a 
responsabilidade do desenvolvimento dos softwares que fazem parte de alguns produtos 
oferecidos juntamente com as soluções de seus projetos. O setor é composto por um gerente de 
TI, um analista de sistemas e sete desenvolvedores os quais são responsáveis por todas as tarefas 
designadas ao desenvolvimento de softwares. 
O setor de TI recebe do setor comercial a proposta técnica, e com esse documento em mãos é 
realizado uma reunião de abertura do projeto com todos os setores envolvidos no novo projeto 
que podem ser os setoresde elétrica, mecânica e automação. Após a reunião o setor de TI pode 
dar início em algumas atividades como, análise preliminar do projeto, alinhamento técnico com 
o cliente, plano do projeto, análise de requisitos, testes com equipamentos desconhecidos, 
criação de cenários, definição da arquitetura que deverá ser utilizada, prototipação de Interfaces 
Gráficas com o Usuário, desenvolvimento do MER (Modelo Entidade Relacionamento) e todas 
as atividades para então dar início à construção do software. 
Com o software pronto e todos os testes realizados em bancada as atividades do setor de TI 
ainda continuam na implantação do software no cliente, onde são realizados todos os testes com 
os equipamentos reais, garantindo assim a comunicação do software com todos os 
 
 
equipamentos de responsabilidade do setor de automação e o real atendimento de todas as 
funcionalidades do software requeridas pelo cliente. 
3.2 Objetivo do Projeto 
Para manter a qualidade no quesito desenvolvimento de softwares, a Empresa A resolveu inovar 
e com isso decidiu implantar um modelo para auxiliar esse processo. Visando essa melhoria 
foram realizadas algumas pesquisas e comparações entre alguns modelos de maturidade de 
processos os quais fornecem informações capazes de orientar a empresa para a definição de seu 
plano de melhoria da qualidade e produtividade. 
Entre os escolhidos foram os modelos CMMI® (Capability Maturity Model® Integration – 
Modelo Integrado de Maturidade e de Capacidade) que é um modelo de maturidade para 
melhoria de processo, destinado ao desenvolvimento de produtos e serviços, e composto pelas 
melhores práticas associadas a atividades de desenvolvimento e de manutenção que cobrem o 
ciclo de vida do produto desde a concepção até a entrega e manutenção [Equipe do Produto 
CMMI], e MPS.BR que é um movimento de melhoria do software brasileiro e um modelo de 
qualidade de processos voltados para a realidade brasileira. O programa é coordenado pela 
Associação para Promoção do Software Brasileiro (SOFTEX) e começou a ser desenvolvido 
em 2003, como uma forma de auxiliar as empresas brasileiras a alcançar a qualidade no 
desenvolvimento de software [SOFTEX 2012]. 
O gerente do setor de TI realizou três reuniões com toda a equipe. Foram realizadas duas visitas 
em empresas parceiras que passaram pelo processo de implantação do CMMI ou MPS.BR. 
Com as reuniões e visitas realizadas foi possível o setor de TI avaliar as possibilidades de 
implantação de um dos processos, e levando em consideração que a empresa possui uma equipe 
relativamente pequena e que não possui seus processos documentados, foi decidido que se 
optaria pela implementação do MPS.BR, considerando que a empresa possa atingir os níveis 
de maturidade mais rápidos em função do MPS.BR possuir mais níveis de maturidade onde a 
implantação é mais gradativa e se adequa ao porte da empresa. 
Com o objetivo de manter todos os colaboradores do setor de Tecnologia da Informação com a 
mesma capacitação, o mesmo entendimento de todo o processo e obter êxito no 
desenvolvimento de seus projetos, a empresa A decidiu implementar um modelo de melhoria 
contínua para seu processo de desenvolvimento e implementação de softwares. 
A organização acreditava que com o programa seria possível garantir que os produtos possam 
sempre ser entregues no prazo atendendo todas as expectativas dos clientes, além de conseguir 
 
 
sempre proporcionar a toda equipe benefícios motivacionais que impliquem em diferencial 
competitivo e eficiência produtiva, visto que a garantia da Qualidade de Software é um item 
que não se trata somente de um diferencial de mercado que a empresa precisa ter, mas sim um 
pré-requisito que deve ser conquistado para conseguir manter um produto com qualidade no 
mercado. 
3.3 A Pesquisa de Campo 
A pesquisa foi realizada com um analista de sistemas, quatro desenvolvedores e com o gerente 
do setor de TI. 
A pesquisa realizada com a equipe técnica e com o gestor do setor tem o objetivo de identificar 
quais as dificuldades encontradas no decorrer da implantação do programa de melhoria do 
processo de software, e quais os fatores críticos levaram o setor a não dar continuidade nas 
atividades para então conseguir realizar a avaliação e obter o certificado nível G do MPS.BR. 
Levando em consideração que a equipe envolvida no processo de melhoria de processo de 
software é bem reduzida, e por ser considerado apenas um setor de desenvolvimento de 
software, e não como uma fábrica de softwares, a pesquisa foi realizada com a equipe técnica 
e com o gestor do setor. 
Ao término de todas as atividades da implantação do projeto de melhoria contínua foi enviado 
por e-mail um questionário com algumas perguntas a todos os colaboradores que participaram 
do processo. A Tabela 2 mostra um exemplo do questionário 
 
Questionário de pesquisa 
As atividades desenvolvidas para a implantação foram fáceis ou difíceis? Por quê? 
Em relação ao programa de MPS, como você vê o programa de melhoria? 
Quais os fatores que mais influenciaram positivamente na implantação do programa MPS? 
Quais os fatores que mais influenciaram negativamente na implantação do programa MPS? 
No seu ponto de vista o que poderia ter sido diferente na implantação do MPS.BR na organização? 
Quais os motivos os quais dificultaram a continuidade do programa de melhoria? 
No seu ponto de vista todos os envolvidos no programa de melhoria tinham o entendimento 
necessário das atividades a serem feitas? 
Quais as dificuldades encontradas durante a implantação do programa de melhoria? 
O que você acredita que poderia ter sido diferente no programa de melhoria para incentivar a todos os 
colaboradores? 
O fato de a implantação estar ocorrendo somente em um setor da empresa possui fatores negativos? 
 
 
 
 
Tabela 2 - Exemplo de perguntas do questionário de pesquisa 
Entre os colaboradores, quatro deles não consideraram difíceis as atividades desenvolvidas na 
implementação por se tratarem de atividades conhecidas, mas foram consideradas atividades 
trabalhosas, já que as mesmas demandam muito tempo para a execução. 
Grande parte dos colaboradores responderam que o fator que mais influenciou negativamente 
na implantação do programa MPS.BR foi a falta de definição de papéis e a sobrecarga de tarefas 
a serem realizadas durante a implantação, e em contrapartida o fator que mais influenciou 
positivamente foi ter conhecimento do que realmente precisava ser melhorado no processo já 
executado pelo setor além da padronização de processos e documentos a serem utilizados, visto 
que o maior objetivo dessa padronização é aperfeiçoar o planejamento, execução e o 
acompanhamento de todas as atividades realizadas no setor de TI. 
Uma das grandes dificuldades encontrada em todo o processo de implementação, o que foi de 
comum acordo entre os participantes que responderam o questionário, foi o comprometimento 
da equipe como um todo, visto que todos os envolvidos tinham o entendimento necessário das 
atividades a serem feitas, mas por algumas vezes faltou o comprometimento necessário de 
alguns dos colaboradores, os quais não tiveram o mesmo nível de interesse dos demais 
envolvidos no processo. Como a equipe de colaboradores é relativamente pequena, foram 
fatores críticos os quais levaram o desânimo para o restante da equipe, e o que dificultou a 
continuidade do processo. 
O fato da implantação ter ocorrido somente em um setor foi visto como um fator negativo para 
os colaboradores, visto que o número de colaboradores envolvidos no processo foi bem 
reduzido e acabou sobrecarregando a todos, já que as tarefas de implantação eram realizadas 
paralelamente as tarefas diárias do setor. 
4. Resultados e Discussões 
A implantação do MPS.BR na empresa foi tratada como um novo projeto para o setor de TI, o 
qual deveriaser implementado paralelamente com os projetos já existentes, inclusive com um 
cronograma onde foram definidas as datas e marcos de projetos para que os mesmos também 
fossem monitorados. 
 
 
A Empresa A contratou o serviço de uma consultoria externa que prestou auxílio em todo o 
processo de desenvolvimento do projeto de melhoria. Mesmo com o apoio da consultoria 
externa os colaboradores responsáveis pelo projeto ainda tiveram dificuldades na definição de 
tarefas por necessitar da aprovação dos demais colaboradores que nem sempre estavam 
presentes e tão comprometidos quanto deveriam estar. A ausência dos colaboradores ocorriam 
por motivos de viagens para implantação de softwares dos projetos em andamento ou 
assistências técnicas para os softwares já existentes, e os poucos colaboradores que estavam 
envolvidos sempre estavam sobrecarregados com as tarefas diárias do setor. 
A alta gerência apoiou financeiramente o setor de desenvolvimento de software no projeto de 
melhoria, enquanto o gerente do setor deu seu apoio com incentivos motivacionais, se 
mostrando sempre solicito e presente em todas as tomadas de decisões e fazendo o 
acompanhamento da implementação das melhorias, sempre envolvendo discussões com os 
colaboradores da organização e fazendo o possível para que a execução das tarefas e processos 
fosse realizada conforme o planejado. 
O projeto teve início em meados de agosto de 2013 quando foi realizada a primeira reunião 
com a consultoria externa. No decorrer dos meses até dezembro foram realizadas as tarefas e 
atividades propostas pela consultoria. 
Além de todo o desenvolvimento o colaborador também é responsável pelos testes e 
implantação do software no ambiente do cliente, atividade essa onde o colaborador se ausenta 
do setor por um período ocasionando uma sobrecarga de funções tanto para os colaboradores 
que continuam no setor como aos colaboradores que se ausentam, sobrecarregando a todos e 
forçando com que os mesmos exerçam mais de uma atividade e tenham mais responsabilidades 
no mesmo projeto. Mesmo com essa dificuldade, os colaboradores responsáveis pelas tarefas 
de implementação de melhoria conseguiram realizar as reuniões necessárias com o consultor e 
definirem um diagrama de processos, de acordo com as etapas definidas no RUP, onde segundo 
Kroll e Kruchten (2003) explicam que o ciclo de desenvolvimento no RUP possui quatro fases: 
iniciação, elaboração, construção e transição. Cada uma delas é concluída por um marco 
principal e em cada fase existem as iterações e cada iteração possui seus documentos e 
atividades, que sem o preenchimento correto dos dados não será possível passar para uma nova 
fase. Logo, constata-se que o RUP prima pela qualidade do produto de software que vai ser 
gerado dando, inicialmente, maior importância a garantia da qualidade de processos e a garantia 
da qualidade do produto de software gerado. 
 
 
Após a definição do diagrama de processos, foi feito um trabalho com toda a equipe para 
descrever cada processo e seus sub processos, identificando quais eram os documentos 
necessários para cada fase, além de definir todos os templates a serem utilizados, visando um 
aproveitamento dos documentos já existentes os quais apenas passaram por ajustes e correções 
para mantê-los no padrão definido na implantação. 
Com a definição do diagrama de processos foi possível visualizar todas as etapas desde a fase 
de concepção até a transição de um projeto, facilitando assim a todos os colaboradores, 
inclusive da gerencia geral, o entendimento do novo modelo de maturidade proposto. 
No decorrer da implantação foi detectado pelos colaboradores que, umas das dificuldades na 
implantação do projeto de melhoria foi a quantidade de evidências necessárias para a avaliação 
do nível almejado, o que se tornou um fator de dificuldade. Percebeu-se que os colaboradores 
tiveram dificuldades em elaborar a documentação por fatores como o de não ter a experiência 
em elaborar a documentação, o tempo determinado para as tarefas eram reduzidos, as tarefas 
de implementação eram desenvolvidas juntamente com as demais tarefas do setor, e nem 
sempre as tarefas eram realizadas por falta de tempo e determinação de alguns colaboradores 
envolvidos. Mesmo ressaltando as dificuldades associadas à documentação, os colaboradores 
responsáveis pelo compromisso de estarem participando do projeto de melhoria se mostraram 
cientes da importância da mesma para um controle mais eficiente dos projetos. Após a definição 
de todos os documentos padrões, os colaboradores perceberam que a documentação é um 
grande facilitador para compreender todas as atividades do projeto, uma vez que o controle 
dessas informações se faz necessário. Com a definição dos documentos padrões algumas tarefas 
passaram a ser realizadas com maior facilidade e maior agilidade pelos colaboradores. 
Houve um consenso entre os colaboradores entrevistados que, quando há um comprometimento 
de todos, o programa tende a ser executado com mais facilidade. Sendo assim, a motivação faz 
com que todos os colaboradores se envolvam mais, e esta motivação tende a gerar um grupo 
empenhado e consequentemente comprometido. Devido a existência de diferentes níveis de 
interesse dos colaboradores envolvidos na implantação do programa, foram gerados conflitos 
internos, o que acabou gerando a falta de motivação dos demais colaboradores. 
Um dos grandes desafios da equipe envolvida no projeto foi repassar todos os processos já 
existentes, e verificar o que deveria ser adaptado ao MPS.BR ou o que deveria ser criado para 
atender as necessidades exigidas pelo nível G. Considerando que todas as tarefas de definição 
de um processo padrão organizacional precisam levar em conta as características da 
 
 
organização, e como a organização em questão, possui muitos clientes com projetos específicos, 
foi preciso avaliar os processos e adequá-los para que o processo definido pudesse contemplar 
a todos. Foi notado que muitos dos processos existentes poderiam ser reutilizados na 
implantação e deveriam apenas sofrer alguns ajustes, mas a maioria dos processos já existentes 
não eram documentados e por isso precisariam ser criados templates e uma padronização para 
todos os processos. 
Um fator importante que influenciou negativamente na implantação da Melhoria do Processo 
de Software da Empresa A, foi que esse processo estava sendo desenvolvido apenas no setor 
de Tecnologia da Informação, o setor onde ocorre o desenvolvimento do software e não na 
empresa como um todo, motivo esse que não existiam colaboradores suficientes para criar um 
comitê diretivo para o programa, sendo assim não foi dada a atenção necessária. 
Conforme houve relatos dos colaboradores, outra dificuldade encontrada na implantação das 
melhorias foi em relação a resistência às mudanças e padronizações de atividades, a resistência 
a padronização de processos por parte de alguns colaboradores e a resistência à mudança 
organizacional para customizar os processos padrões definidos no modelo escolhido pela 
organização quando já existia uma cultura a qual precisava ser melhorada sobre os 
procedimentos de engenharia de software. E devido a essas resistências, alguns colaboradores 
simplesmente se isolaram e não participaram ativamente do programa de Melhoria do Processo 
de Softwares, o que ocasionou desmotivação dos demais colaboradores. 
O gestor reconheceu que a relação do colaborador da organização com o programa de melhoria 
depende muito da maneira que o mesmo se dedica as atividades delegadas e da possibilidade 
de mudança de função nos projetos. Com isso, não foi possível realizar a definição de papéis, 
visto que a equipe é bastante reduzida e vários projetos acontecem paralelamente. 
A última tarefa realizada com todos os colaboradores que participaram da implantação foram 
os treinamentos de Gerência deProjetos (GPR) e Gerência de Requisitos (GRE), que foram 
ministrados pela consultoria externa contratada pela empresa A. 
Os resultados dos dados, apresentados na Tabela 3, mostram que alguns dos FCS identificados 
na literatura também se confirmaram nesta pesquisa. Entre eles os fatores que mais foram 
positivos foram o suporte da alta gerência e o uso de consultorias. Os fatores assinalados nas 
tabelas 3 e 4 são os FCS que mais se destacaram e que tiveram maior relevância no decorrer do 
processo. 
 
 
 
ID FCS Empresa A 
1 Suporte da alta gerência X 
2 Treinamento /desenvolvimento pessoal X 
3 Equipes virtuais de projeto 
4 Seleção criteriosa de software X 
5 Uso de consultores X 
6 Comunicação e colaboração interdepartamental 
7 Pequenos ganhos X 
8 Melhoria contínua 
9 Campanhas de Marketing 
10 Parceria com fornecedores 
11 Uso de comitê diretivo 
12 Plano de benefícios para realizações 
13 Sucesso nas mudanças 
14 Planejar e reforçar os objetivos do projeto X 
15 Disponibilização de recursos X 
16 Prioridade em processos 
17 Cultura amigável dos modelos 
18 Métricas focadas no cliente 
Tabela 3 - FCS previsamente levantados na pesquisa de campo 
Durante a implantação a equipe envolvida identificou alguns novos FCS, que seguem na tabela 
abaixo: 
 
ID FCS Empresa A 
1 Resistência a mudanças de colaboradores X 
2 Definição de papéis X 
3 Comprometimento da equipe X 
4 Implantação realizada em apenas um setor da 
empresa X 
5 Empresa não ser uma fábrica de softwares X 
6 Padronização de Processos X 
Tabela 4 - Novos FCS levantados na pesquisa de campo 
No grupo dos novos FCS identificados na pesquisa de campo, apresentados na Tabela 4 os 
fatores identificados na pesquisa que mais afetaram a implantação foram à resistência a 
mudanças de colaboradores, definição de papéis e o comprometimento da equipe, visto que 
existiam diferentes níveis de interesse dos colaboradores referente à implantação do programa 
 
 
de melhoria. 
Todos os novos FCS identificados foram considerados muito importantes para o entendimento 
do que é preciso melhorar e quais as adequações precisam ser feitas no processo de melhoria 
de software, mesmo considerando que a implementação estava sendo feita em apenas um setor 
da empresa, motivo esse o qual a equipe considerou de grande valia para o entendimento de 
que, independente do setor o qual está sendo implementado, a empresa como um todo precisa 
estar ciente das reais necessidades de melhoria para oferecer um produto com qualidade. 
Apesar de não ser uma fábrica de software, todos os colaboradores precisam estar 
comprometidos e entenderem o real valor de um processo bem definido, para então 
conseguirem colocar em prática o que foi aprendido na implementação, e conseguir utilizar 
todos os processos os quais foram padronizados. 
Com os processos bem definidos e padronizados é possível que todas as fases dos projetos 
sejam documentadas, sendo assim, pode-se manter uma base histórica do andamento dos 
projetos, envolvendo tempo de desenvolvimento, colaboradores que participaram e o tempo 
gasto para o desenvolvimento dos mesmos. Com base nestes dados a empresa consegue 
elaborar novos projetos diminuindo assim a margem de erros, tanto financeiros quanto de 
prazos. 
Com a implementação do MPS.BR é possível adotar mecanismos efetivos de controle e 
padronização dos processos de desenvolvimento de software, em busca do incremento da 
qualidade e da profissionalização dos serviços prestados pela empresa A. 
Algumas das principais dificuldades apontadas em (ROCHA et al., 2005), estão relacionadas 
às competências da equipe da empresa, a cultura da organização e a estratégia de 
implementação do MPS. Nesse trabalho, também foram apontadas algumas questões de caráter 
tecnológico que podem influenciar a adoção do modelo MPS, como o apoio de ferramentas, 
questões relacionadas à disponibilidade de recursos financeiros e de pessoal. 
As dificuldades na adoção do modelo MPS, identificadas no caso de uso são relacionadas as 
questões de disponibilidade de recursos, dificuldade em compreender os benefícios com a 
implementação dos processos e expectativas divergentes da realidade. Essas e outras 
dificuldades, têm motivado as organizações a adotarem outras abordagens para melhoria de 
processos, como a ISO 9000 (STAPLES et al., 2007). 
 
 
5. Conclusão 
Este trabalho apresentou a experiência de uma implementação a qual não chegou até a 
avaliação, mas que continua realizando alguns dos processos definidos durante a 
implementação e que apoia os colaboradores a conseguirem realizar um trabalho mais eficiente. 
Os FCS sugeridos na literatura foram comparados com os FCS encontrados na pesquisa. Alguns 
FCS previamente identificados foram comprovados, como: suporte da alta gerência, 
treinamento e desenvolvimento de pessoal e gestão de mudanças. Seis novos fatores foram 
identificados, como: resistência a mudanças de colaboradores; definição de papeis; 
comprometimento da equipe; implementação realizada em apenas um setor da empresa e a 
padronização de processos. 
Algumas limitações desta pesquisa devem ser destacadas, visto que os FCS foram pesquisados 
em apenas um setor da empresa. As entrevistas foram feitas com o gerente e com os 
colaboradores do setor de TI os quais estavam envolvidos nos processos de melhoria da 
empresa. Uma pesquisa mais abrangente e com empresas que façam a implementação na 
organização como um todo poderia gerar resultados diferentes e outros FCS poderiam ser 
identificados. 
Como continuidade deste trabalho poderia ser realizada uma pesquisa quantitativa e mais 
abrangente com questões fixas, usando a escala Likert em uma escala de intervalo para permitir 
avaliações intermediárias ou comparação entre itens. 
Mesmo com todas as dificuldades encontradas, os colaboradores que realmente estavam 
comprometidos com o programa de melhoria conseguiram realizar todas as tarefas delegadas. 
A Empresa A não passou pela avaliação e por isso o projeto não foi concluído, mas os 
colaboradores utilizam parte do que foi proposto na implementação, e podem notar a vantagem 
de passar por um processo de melhoria contínua, como o processo de Melhoria de Processo do 
Software Brasileiro (MPS.BR), visando a facilidade de gerenciamento centralizado do projeto, 
sinergia do trabalho em grupo e compartilhamento de experiências. 
Referências 
CATER-STEEL, A. P., POLLARD, C.E.C. Conflicting views on ITIL implementation: managed as a project – 
or business as usual 2008. 
[CHAVES ET AL] CHAVES, N.L.S, SANTOS, G., CERDEIRAL, C., CABRAL, M.L., CABRAL, R., 
SCHOTS, M., NUNEW, E., ROCHA, A.R. Lições Aprendidas em Implementações de Melhoria de Processos 
 
 
em Organizações com Diferentes Características, COPPE/UFRJ – Universidade Federal do Rio de Janeiro - 
Programa de Pós-Graduação em Informática, Universidade Federal do Estado do Rio de Janeiro (UNIRIO), 2011. 
[EQUIPE DO PRODUTO CMMI] Equipe do Produto CMMI, (2006). CMMI para Desenvolvimento – Versão 
1.2. 
HOCHSTEIN, A., TAMM, G., BRENNER, W. Service oriented IT management: benefit cost an success 
factors., 2005. Disponível em: 
<http://itservicetoday.blogs.com/itil/files/Service_Orientated_IT_Management_ITIL.pdf>. Acesso em: 10 mai. 
2015. 
KROLL, P E KRUCHTEN P. (2003). The rational unified process made easy: a practitioner’s guide to the RUP. 
Addison Wesley. 
[MONTONI E ROCHA, 2011] MONTONI, M.A., ROCHA, A.R.C (2011). Uma investigação sobre fatores 
críticos de Sucesso em Iniciativas de Melhoria de Processos de Software. Tese de Doutorado do Programa de Pós-
graduação em Engenharia de Sistemas e Computação, COPRE, da Universidade Federal do Rio de Janeiro. 
[ROCHA ET AL., 2005] ROCHA, A.R., MONTONI, M., SANTOS, G., OLIVEIRA, K., NATALI, A.C., 
MIAN, P., CONTE,T., MAFRA, S.BARRETO, A., ALBUQUERQUE, A., FIGUEIREDO, S., SOARES, A., 
BIANCHI, F., CABRAL, R., DIAS, A. Dificuldades e Fatores de Sucesso na Implementação de Processos de 
Software Utilizando o MR-MPS e o CMMI. PROQUALITI, Lavras, 2005. 
[SANTOS ET AL] SANTOS, D., VILELA, D., SOUZA, C., CONTE, T. (2011) Programas de Melhoria de 
Processo de Software – Uma Pesquisa sobre a influência dos aspectos humanos. In: X SBQS 2011. Curitiba, PR 
– Brasil. 
[SOFTEX 2012]. MPS.BR- Melhoria de Processo do Software Brasileiro. Guia Geral MPS de Software 2012. 
SOMMERS, T.M., NELSON, K. The impacto of criticial success factors across the stages of enterprise resource 
planning implementations. In Hawaii International Conference on System Sciences, 34, 2001, Havaí. 
[STAPLES ET AL., 2007] STAPLES, M., NIAZI, M., JEFFERY, R. An exploratory study if why organizations 
do not adopt CMMI. Journal of Systems and Software, v.80, n.6, app.883-895.