Implantacao Nivel G MPS BR Na Auspex - 2009

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ
MBA EM GESTÃO DE PROJETO DE SOFTWARE
Luiz Gustavo Rissmann
Marcelo Jundy Kimura
Fábio Maia do Prado
Implantação do nível G do MPS.BR na
Auspex Desenvolvimento de Negócios em
Tecnologia Ltda.
Curitiba
2009
Implantação do nível G do MPS.BR na Auspex

Desenvolvimento de Negócios em Tecnologia Ltda.
Monografia apresentada ao
curso de pós graduação MBA em
Gestão de projetos de software da
Pontifícia Universidade Católica do
Paraná como requisito de obtenção do
título de especialista.
Orientadora: Sheila Reinehr
Curitiba
2009
FICHA CATALOGRÁFI
CA
0000 Sobrenome, Prenome do autor.

Título / Autor. – Local : Instituição, ano.
n.º de folhas : ilustração (se houver)
Monografia – Pontifícia Universidade Católica

do Paraná, Curitiba, 2008
1. Assunto do trabalho, deve ser retirado com

um bibliotecário de referência. I. Autor. II. Título.
Implantação do nível G do MPS.BR na Auspex

Desenvolvimento de Negócios e Tecnologia Ltda.
Monografia apresentada ao curso de pós graduação MBA em Gestão de

projetos de software da Pontifícia Universidade Católica do Paraná como
requisito de obtenção do título de especialista
COMISSÃO EXAMINADORA
___________________________________________________
Prof. Dr.
Pontifícia Universidade Católica do Paraná
___________________________________________________
Prof. Dr.
___________________________________________________
Prof. Dr.
i
RESUMO
Visando a melhoria da qualidade de software através da melhoria dos

processos de produção e manutenção, alcançando competitividade no
mercado brasileiro, viu-se a oportunidade de aplicar o modelo MPS.BR
proposto pela Softex. Este modelo de melhoria e avaliação de processo
de desenvolvimento de software é compatível com padrões de qualidade
aceitos internacionalmente. Este trabalho foi desenvolvido para servir
de manual para a implantação de processos aderentes ao nível G do
MPS.BR e posteriormente a obtenção desta avaliação na Auspex
Desenvolvimento de Tecnologia em Negócios Ltda. Para isso é
apresentado um resumo do cenário atual da indústria de desenvolvimento
de software no Brasil, um estudo aprofundado da avaliação nível G do
MPS.BR e um trabalho aplicado na empresa onde foi estudado o estado
atual da organização e definido processos de desenvolvimento aderentes
ao modelo proposto pela avaliação desejada. Os processos foram
baseados no RUP (Rational Unified Process) e adaptado para a realidade
da organização em questão com as fases, processos e papéis necessários
sendo moldados de acordo com a cultura da empresa. Também foram
definidos os documentos que devem ser gerados em cada fase do processo
e o modelo que cada documento deve seguir. Além disso, todo o
planejamento para a implantação dos processos propostos e os
mecanismos de acompanhamento e controle são colocados objetivamente.
Palavras chave: MPS.BR. CMMi. Gerenciamento de Projetos. Qualidade de

software. Melhoria de Processos.
ii
ABSTRACT
Aiming at increasing the quality of software through the improvement of the

development and maintenance processes, pursuing the improvement of
competitiveness in Brazilian market, it was identified the opportunity to apply
the MPS.BR model proposed by Softex. This model of improvement and
evaluation process of software development is compatible with standards of
quality internationally accepted. This paper was written to be used as a guide
for the deployment of processes at Auspex Business Technology Development
Ltd. in accordance to MPS.BR level G and its further certification. It is presented
a summary of the brazilian scenario of software development industry, a study
of the MPS.BR level G requirements and a presentation of Auspex current
situation and evaluation within the scope MPS.BR level G, defining changes in
its processes in order to fit the specified scope. Development processes were
based on RUP (Rational Unified Process) and adapted in order to attend the
needs and culture of the company. The documents that must be generated at
each stage of the process were also defined, as well as the template that each
document must follow. Moreover, the whole planning for the deployment of the
proposed procedures and mechanisms for monitoring and controlling, are
defined objectively.
Keywords: MPS.BR. CMMi. Project Manager. Software quality.

iii
LISTA DE FIGURAS
Figura 1 – Mercado brasileiro de software em 2006 (ABES, 2007) ....... 12
Figura 2 – Evolução do mercado brasileiro de software em 2006 (ABES,

2007) ................................................................................................................ 12
Figura 3 – EAP da implantação da metodologia – adaptado de (XAVIER

et al., 2005) ...................................................................................................... 17
Figura 4 - Componentes principais da MPS.BR (SOFTEX, 2007) ......... 20
Figura 5 – Níveis de maturidade do CMMI ............................................ 23
Figura 6 – Processo de avaliação do MPS.BR (SOFTEX, 2007c)......... 36
Figura 7: Ciclo de vida de desenvolvimento na Auspex (SZIMANSKI;

ROUILLER; SOUZA, 2009) .............................................................................. 59
Figura 8: Ciclo de vida: Concepção (SZIMANSKI; ROUILLER; SOUZA,

2009) ................................................................................................................ 60
Figura 9: Ciclo de vida: Elaboração (SZIMANSKI; ROUILLER; SOUZA,

2009) ................................................................................................................ 61
Figura 10: Ciclo de vida: Construção (SZIMANSKI; ROUILLER; SOUZA,

2009) ................................................................................................................ 63
Figura 11: Ciclo de vida: Transição (SZIMANSKI; ROUILLER; SOUZA,

2009) ................................................................................................................ 64
iv
LISTA DE TABELAS
Tabela 1 – Média de melhoria por categoria.......................................... 14
Tabela 2 - Níveis de maturidade Fonte: SOFTEX (2007) ...................... 30
Tabela 3 - Fonte: SOFTEX (2007) ......................................................... 32
Tabela 4 – Relação entre os níveis do MPS.BR e CMMi....................... 38
Tabela 5 - Graus de implementação do MPS-BR ................................. 54
Tabela 6: GPR no processo da Auspex ................................................. 75
Tabela 7: GRE no processo da Auspex ................................................. 75

v
SUMÁRIO
1. INTRODUÇÃO _______________________________________________ 9
1.1. O mercado de software _______________________________________ 11
1.2. A Auspex ___________________________________________________ 15
2. Método de Pesquisa_________________________________________ 16
2.1. Objetivos Específicos__________________________________________ 16
2.2. Implementação ______________________________________________ 16
3. Revisão da Literatura ________________________________________ 19
3.1. MPS.BR ____________________________________________________ 19

3.1.1. O ISO/IEC 12207 __________________________________________________ 20
3.1.2. O ISSO/IEC 15504 _________________________________________________ 21
3.1.3. O CMMI (Capability Maturity Model Integration) ________________________ 22
3.1.4. O Modelo de referência (MR-MPS) ___________________________________ 23
3.1.5. Nível de maturidade G (Parcialmente Gerenciado) _______________________ 32
3.1.6. Processo: Gerência de Projetos – GPR _________________________________ 33
3.1.7. Processo: Gerência de Requisitos – GRE _______________________________ 35
3.1.8. Capacidade do processo para o nível de maturidade _____________________ 35
3.1.9. Processo de Avaliação _____________________________________________ 35
3.2. MPS.BR x CMMi______________________________________________ 37
3.3. Rational Unified Process _______________________________________ 38

3.3.1. Desenvolvimento Iterativo __________________________________________ 38
3.3.2. Gerenciamento de requisitos ________________________________________ 39
3.3.3. Arquitetura baseada em componentes ________________________________ 40
3.3.4. Modelagem visual do software ______________________________________ 40
3.3.5. Verificação constante da qualidade ___________________________________ 40
3.3.6. Controle de mudanças _____________________________________________ 41
4. Implementação ____________________________________________ 42
4.1. Diagnóstico da situação atual ___________________________________ 42

4.1.1. Processo: Gerencia de projetos (GPR) _________________________________ 42
vi
4.1.2. Processo: Gerência de Requisitos (GRE) _______________________________ 50

4.1.3. Acompanhamento da Implantação ___________________________________ 52
4.2. Estruturar o gerenciamento de projetos __________________________ 54

4.2.1. Modelo de Escritório de Projetos _____________________________________ 54
4.2.2. Metodologia de gerenciamento de projetos ____________________________ 55
4.2.3. Software de gerenciamento de projetos _______________________________ 55
4.2.4. Política de gerenciamento de projetos ________________________________ 55
4.3. Treinamento ________________________________________________ 55

4.3.1. Treinamento na metodologia ________________________________________ 55
4.3.2. Treinamento no software de gerenciamento ___________________________ 56
4.3.3. Treinamento para os executivos no acesso às informações ________________ 56
4.4. Aplicação e acompanhamento __________________________________ 56

4.4.1. Definição de um projeto piloto ______________________________________ 56
4.4.2. Reuniões de acompanhamento da aplicação do modelo __________________ 57
4.4.3. Avaliações periódicas dos resultados__________________________________ 57
4.5. Encerramento _______________________________________________ 57

4.5.1. Diagnóstico da nova situação atual ___________________________________ 57
4.5.2. Institucionalização da metodologia ___________________________________ 57
5. Processos Definidos para a Auspex _____________________________ 58
5.1. Fases do ciclo de vida _________________________________________ 58

5.1.1. Concepção _______________________________________________________ 59
5.1.2. Elaboração_______________________________________________________ 60
5.1.3. Construção ______________________________________________________ 61
5.1.4. Transição ________________________________________________________ 63
5.2. Papéis _____________________________________________________ 64

5.2.1. Atendimento _____________________________________________________ 64
5.2.2. Escritório de projetos ______________________________________________ 65
5.2.3. Gerente de projeto ________________________________________________ 65
5.2.4. Analista de negócios _______________________________________________ 65
5.2.5. Analista de sistema ________________________________________________ 66
5.2.6. Analista de teste __________________________________________________ 66
5.2.7. Analista de segurança ______________________________________________ 66
5.2.8. Desenhista de interface ____________________________________________ 67
5.2.9. Controlador de versão _____________________________________________ 67
vii
5.2.10. Programador ____________________________________________________ 67

5.2.11. Projetista de banco de dados _______________________________________ 68
5.2.12. Testador ________________________________________________________ 68
5.2.13. Técnico de infra-estrutura __________________________________________ 68
5.3. Artefatos ___________________________________________________ 69

5.3.1. Solicitação de serviço ______________________________________________ 69
5.3.2. Documento de Visão_______________________________________________ 69
5.3.3. Proposta de projeto _______________________________________________ 69
5.3.4. Documento de requisitos ___________________________________________ 70
5.3.5. Plano do Projeto __________________________________________________ 70
5.3.6. Protótipo ________________________________________________________ 70
5.3.7. Diagrama ER _____________________________________________________ 71
5.3.8. Banco de dados ___________________________________________________ 71
5.3.9. Código fonte _____________________________________________________ 71
5.3.10. Plano de teste ___________________________________________________ 72
5.3.11. Registro de bugs __________________________________________________ 72
5.3.12. Controle de mudança _____________________________________________ 72
5.3.13. Documento de aceite______________________________________________ 72
5.4. Relação do processo proposto aos processos do MPS.BR_____________ 73
6. Resultados e Validação ______________________________________ 77
6.1. Conscientização ______________________________________________ 77
6.2. Diagnóstico da situação atual ___________________________________ 78
6.3. Estruturar gerenciamento de projetos ____________________________ 78
6.4. Treinamento ________________________________________________ 79
6.5. Aplicação e acompanhamento __________________________________ 80
6.6. Encerramento _______________________________________________ 82
7. Conclusão _________________________________________________ 83
REFERÊNCIAS __________________________________________________ 84
APÊNDICES ____________________________________________________ 86
APÊNDICE A - MODELO DE SOLICITAÇÃO DE SERVIÇO __________________ 87

viii
APÊNDICE B - MODELO DE DOCUMENTO DE VISÃO ____________________ 89
APÊNDICE C - MODELO DE PROPOSTA DE PROJETO ____________________ 94
APÊNDICE D - MODELO DE DOCUMENTO DE REQUISITOS _______________ 98
APÊNDICE E - MODELO DE PLANO DO PROJETO ______________________ 100
APÊNDICE F - MODELO DE CONTROLE DE MUDANÇA _________________ 104

9
1. INTRODUÇÃO
Foi-se o tempo em que as empresas eram escolhidas pelo preço de

seus produtos frente aos seus concorrentes. É claro que este ainda é um fator
de grande importância na hora de tomar uma decisão, porém, quanto maior a
oferta em cada nicho do mercado, maior a necessidade das empresas se
mostrarem diferentes e capacitadas frente aos demais concorrentes que
prezam apenas pelo preço baixo em detrimento da qualidade do produto final.
Com isso, se torna indispensável que uma empresa tenha algum diferencial
que no mínimo a ponha um degrau acima das demais.
No ramo de desenvolvimento de software, além do preço, outros fatores

são levados em consideração, como capacidade e maturidade da empresa.
Uma empresa que possa garantir a qualidade do serviço a ser prestado já sai
na frente da maioria das demais e a deixa numa posição mais confortável para
se preocupar com os concorrentes que também prezam a qualidade e não se
preocupam apenas em entregar um produto barato, mas sim um produto que
supra as reais necessidades do cliente.
“Uma empresa de software bem sucedida é aquela que fornece

software de qualidade e capaz de atender às necessidades dos
respectivos usuários. Uma empresa que consiga desenvolver esse
software de maneira previsível e em determinado período, com
utilização eficiente e eficaz de recursos, será uma empresa com um
negócio viável.” (BOOCH; RUMBAUGH; JACOBSON, 2005)
Um software de qualidade é definido por satisfazer os requisitos

funcionais e de desempenho declarados inicialmente em seu escopo. Tais
softwares devem seguir normas de desenvolvimento, podendo assim obter um
produto com as especificações desejadas. (PRESSMANN, 2006, pg. 349)
Empresas com nome consolidado no mercado já possuem a confiança

necessária para que um cliente compre um produto novo com a certeza de que
está pagando por um software com a mesma qualidade dos demais produtos
desta empresa. Já empresas emergentes, ou mesmo as completamente
desconhecidas, necessitam de algum mediador que possa assegurar as
empresas contratantes que o serviço prestado pela contratada será de
10
qualidade e que o produto final será no mínimo tão bom quanto o produto de
uma empresa conhecida. Assim é muito difícil para um contratante comparar a
qualidade das diversas empresas, sejam elas grandes, médias ou pequenas,
quando precisa contratar o serviço de desenvolvimento. Mesmo que uma
empresa pequena tenha obtido um grande sucesso com um produto específico,
nada garante que seu próximo desenvolvimento terá a qualidade do anterior, a
não ser que esta empresa tenha um processo bem definido, com etapas de
controle e garantia de qualidade muito bem definidos.
Neste caso, para que o software possa ser tido como um software de
qualidade antes do mesmo ser implementado, a única informação que uma
empresa contratante pode ter são as informações do processo no qual o
software será desenvolvido.
Segundo SOFTEX (2007, pg. 5-6), “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”.
Assim se pode notar que a única forma de garantir um bom software é

garantir que o processo de desenvolvimento é adequado, controlado, medido e
revisto freqüentemente para que os bons resultados obtidos anteriormente
sejam não só repetidos como superados nos projetos subseqüentes. É com
este objetivo que muitas organizações têm investido grandes somas de
dinheiro na melhoria de seus processos de desenvolvimento de software. A
melhoria de processo de software assume que uma organização bem
gerenciada com processos definidos tem mais possibilidades de produzir
produtos que atendem adequadamente aos requisitos dos clientes, no prazo e
no orçamento do que organizações mal gerenciadas e sem processos. Padrões
internacionais como a ISO/IEC 12207 (1998), ISO/IEC 15504 (2003) e modelos
de qualidade de processo de software como o CMMI-DEV (Capability Maturity
Model Integration for Development) e o MPS.BR (Modelo de Melhoria de
Processo do Software Brasileiro) foram desenvolvidos para servir como
modelos de referência para guiar as organizações no que tange o aumento da
11
maturidade organizacional, bem como o aumento da sua capacidade de

desenvolver software. (VARGAS et al., 2008)
1.1. O MERCADO DE SOFTWARE
A pesquisa Mercado Brasileiro de Software – Panorama e Tendências,

realizada anualmente pela consultoria IDC e encomendado pela ABES
(Associação Brasileira das Empresas de Software), na sua edição 2007,
mostrou um claro crescimento do setor apesar de perder uma posição em
relação ao mercado mundial (caiu de 12o. em 2006 para 13o. Em 2007).
Apesar da queda no ranking, houve um aumento de U$1,68 bilhão em relação
à movimentação financeira destinada ao setor de desenvolvimento de software.
Como podemos observar na Figura 2, em 2007 a pesquisa mostrou que o
Brasil havia movimentado em 2006 aproximadamente 9,09 bilhões de dólares,
equivalente a 0,97% do PIB naquele ano. Desse total, US$ 3,26 bilhões
referem-se a softwares propriamente ditos e U$ 1.064 bilhões a softwares
desenvolvidos no país, aumentando a participação da produção nacional para
32,5% contra 29% no ano anterior. A mesma pesquisa indica ainda uma
previsão de crescimento anual superior a 12% até 2010. O seguimento de
software no Brasil contava com aproximadamente oito mil companhias em
2006, das quais 78% dedicam-se ao desenvolvimento, produção e distribuição
de softwares e 22% à prestação de serviços. Outro dado relevante do estudo é
que 94% das empresas que compõem o setor eram de micro e pequeno porte.
(ABES, 2006, 2007)
12
Figura 1 – Mercado brasileiro

brasileiro de software em 2006 (ABES, 2007)
Figura 2 – Evolução do mercado brasileiro de software em 2006 (ABES, 2007)

13
Analisando a evolução do mercado demonstrada nas figuras 1 e
Figura 22,, os números ilustram um mercado que está em franca expansão,

porém a produção nacional ainda é muito pequena em relação ao número de
software que importamos de fora. Isso é ainda agravado pelo fato de que, ao
contrário da Índia, por exemplo, praticamente toda a produção nacional (cerca
de 95%) é destinada ao mercado interno.
Outro estudo importante feito pelo Standish Group International,

International
divulgado em 2002, apresentava o seguinte cenário: (XAVIER et al, 2005)
31% de todos os projetos são cancelados entes de seu término;
88% dos projetos ultrapassam seu prazo, orçamento, ou ambos;
Os projetos ultrapassam, em média, 189% dos custos originalmente

estimados; e
Os projetos ultrapassam, em média, 222% do prazo originalmente

estimado.
Diante deste cenário, é fácil observar que uma empresa para conseguir
ganhar notoriedade no setor, precisa investir em processos que possam
reconhecer a qualidade do produto desenvolvido frente à concorrência
internacional. Para suprir
rir esta necessidade, as empresas estão cada vez mais
investindo em processos de melhoria de software através de certificações
nesta área. Porém, o custo de uma certificação internacional, como a CMMi,
14
pode ser de até US$ 400 mil, tornando o MPS.BR uma alternativa muito mais
atrativa para pequenas e médias empresas. Além disso, os níveis do MPS.BR
estão alinhados com os níveis do CMMI, como podemos ver na Tabela 4.
Além disso, os ganhos para a organização são comprovados através de

pesquisas em empresas que já obtiveram alguma avaliação. A Tabela 1 ilustra
os ganhos conseguidos através da implementação dos processos sugeridos
pelo CMMi (SEI, 2006):
Categoria Média de ganho

Custo 34%
Prazo 50%
Produtividade 61%
Qualidade 48%
Satisfação do cliente 14%
Retorno do investimento (ROI) 4.0: 1
Tabela 1 – Média de melhoria por categoria
15
1.2. A AUSPEX
A Auspex é uma empresa de desenvolvimento de software, que iniciou

suas atividades no início de 2007 com muito trabalho e uma pequena equipe.
Nesta etapa, as preocupações não iam além de cumprir os cronogramas de
entregas dos projetos. Não existiam processos formais estabelecidos e
conseqüentemente havia pouca documentação e controle. Entretanto, com o
aumento dos projetos e o crescimento da equipe começaram a surgir
problemas como:
• Elevado número de alterações no escopo original durante o

desenvolvimento;
• Grande número de requisitos não implementados ou implementados

de maneira incorreta;
• Elevado número de horas extras;
• Aumento no número de bugs;
À medida que os problemas iam aparecendo eram definidos novos

processos para mitigá-los. Entretanto, logo se percebeu que esta não era a
melhor estratégia. Era preciso fazer um planejamento de implantação da
melhoria da qualidade dos processos.
Buscou-se então um modelo de melhoria que pudesse ser aplicado à

realidade da empresa. Por ser uma metodologia incremental, compatível com o
CMMi, que tem como foco principal as pequenas e médias empresas, decidiu-
se pela adoção do MPS.BR.
16
2. MÉTODO DE PESQUISA
O objetivo deste trabalho é levantar a situação da Auspex em relação às

competências necessárias à obtenção da avaliação do nível G do MPS.BR e
definir um planejamento para alcançá-la. Para atingir este objetivo, será
proposto também um processo a ser adotada nos projetos de desenvolvimento
de software da empresa.
2.1. OBJETIVOS ESPECÍFICOS
Identificar as deficiências da empresa em relação aos critérios

utilizados na avaliação Nível G do MPS.BR;
Definir um processo para a implantação das melhorias necessárias

para a obtenção da avaliação desejada;
Definir um processo aderente aos requisitos do nível G do MPS.BR a

ser adotado nos projetos de desenvolvimento de software da
empresa.
2.2. IMPLEMENTAÇÃO
A fim de implementar o modelo e conseguir futuramente a avaliação,

primeiramente deve-se formalizar o projeto e definir a equipe responsável pela
identificação, análise e execução das ações que deverão ser implementadas
para garantir a melhoria contínua do processo de software da organização, o
Software Engineering Process Groupou simplesmente SEPG. Apesar de não
ser obrigatória a presença de um SEPG na organização para a obtenção da
avaliação do nível G do MPS.BR, a existência formal do grupo responsável
ajuda na institucionalização das decisões e das ações, e facilita o
acompanhamento da diretoria que pode participar das reuniões que são
realizadas em dias e horários fixos.
17
Para o tamanho da empresa em questão, O SEPG poderá ser formado

por apenas 2 pessoas (ou até mesmo apenas uma caso seja necessário) e
entre estas devem estar preferencialmente gerentes de projetos, analistas de
sistemas, líderes, coordenadores técnicos ou integrantes da área de qualidade.
É muito importante que o grupo se reúna ao menos uma vez por semana e em
horário determinado.
Um fator crítico para o sucesso da implantação de uma metodologia que

visa uma certificação é conseguir o apoio e a aceitação de todos os envolvidos.
Assim, o SEPG deve tomar as medidas necessárias para explicar aos demais
profissionais da empresa o que é um modelo de melhoria de processos,
especificamente o MPS.BR, o motivo pelo qual ele está sendo adotado e,
principalmente, quais as vantagens que serão vistas com esta implementação
logo no início dos trabalhos. (XAVIER et al., 2005)
As atividades da SEPG devem incluir os itens demonstrados na Figura

3.
Figura 3 – EAP da implantação da metodologia – adaptado de (XAVIER et al.,

2005)
Um dos principais fatores apontados como barreira à implementação da

melhoria é que muitos dos envolvidos vêm isso como um obstáculo imposto ao
“trabalho real”, seja pela burocracia acrescentada ou pela imposição de
18
padrões que talvez não estejam de acordo com a realidade enfrentada no dia a
dia da empresa.
19
3. REVISÃO DA LITERATURA
3.1. MPS.BR
O MPS.BR é um modelo de melhoria e avaliação de processo de

software desenvolvido por entidades brasileiras visando à melhoria no
processo de desenvolvimento de software nacional, visando assim obter um
produto de confiável e com qualidade. O modelo MPS.BR pode ser
implementado em empresas de diferentes tamanhos e características, porém
seu principal objetivo é a aplicação em empresas de pequeno a médio porte.
(SOFTEX, 2007)
O modelo MPS.BR é compatível com padrões de qualidade aceitos

internacionalmente, pois todo o modelo se baseia em padrões e modelos de
melhoria de processo já existentes. Sendo assim o modelo MPS.BR tem como
base requisitos de processos definidos nos modelos de melhoria de processo e
também define como premissa os princípios de engenharia de software,
utilizada nos moldes da realidade brasileira. (SOFTEX, 2007)
Conforme SOFTEX (2007), a base técnica utilizada para a construção do

MPS.BR é composta pelas normas NBR ISO/IEC 12207 – Processo de Ciclo
de Vida de Software e suas emendas 1 e 2 e a ISO/IEC 15504 – Avaliação de
Processo e seu Modelo de Avaliação de Processo de Software ISO/IEC 15504-
5, portanto o modelo está totalmente aderente a essas normas. O MPS.BR
também cobre o conteúdo do CMMI-SE/SWSM, através da inclusão de
processos e resultados de processos em relação aos processos da Norma
NBR ISO/IEC 12207.
Segundo a SOFTEX (2007) modelo MPS.BR possui três componentes

principais como podemos observar na
20
Figura 4, Modelo de Referência (MR-MPS3), Método de Avaliação (MA-MPS4)

e Modelo de Negocio (MN-MPS4), onde estes se baseiam nos conceitos de
maturidade e capacidade de processo para a avaliação e melhoria de
qualidade de produtos.
Figura 4 - Componentes principais da MPS.BR (SOFTEX, 2007)
3.1.1. O ISO/IEC 12207
A Norma ISSO/IEC NBR 12207 foi elaborada e publicada em sua

primeira versão em agosto de 1995, porém apenas em 1998 foi publicada sua
versão brasileira. Durante os anos de 2002 e 2004 ocorreram atualizações em
21
seu escopo gerando assim as ementas 1 e 2 respectivamente. A norma foi

criada em um esforço comum das organizações ISO (Institute of Ornanization
for Standardization) e o IEC (International Eletrotechnical Commission)
(MACHADO, 2006).
O objetivo da norma ISSO/IEC 12207 é fornecer uma estrutura única

para que todos os envolvidos com o desenvolvimento do software possam
utilizar uma linguagem única, sendo estabelecida na forma de processos bem
definidos. O escopo da norma abrange todo o processo de desenvolvimento de
software e seus envolvidos. Sua estrutura foi fundamentada em dois itens:
modularidade e responsabilidade. Com o intuito de possuir uma grande
flexibilidade e ser adaptável a cada necessidade sua modularidade passa a
possuir um mínimo acoplamento e uma máxima coesão entre os processos. O
fato de que cada processo possui apenas um responsável facilita a aplicação
da norma em projetos onde várias pessoas podem estar envolvidas (NBR
ISO/IEC 12207, 1998).
A norma possui 3 classes de processos: processos fundamentais,

processos de apoio e processos organizacionais. Os processos fundamentais
atendem à execução do desenvolvimento, operação ou manutenção dos
produtos de software, durante seu ciclo de vida. Os processos de apoio visam
auxiliar e contribuir para o sucesso e qualidade do projeto. Os processos
organizacionais são empregados por uma organização para estabelecer e
implementar uma estrutura constituída pelos processos do ciclo de vida e pelos
integrantes no desenvolvimento.
Cada processo é divido em um conjunto de atividades, e cada atividade

em um conjunto de tarefas. Os processos de apoio e organizacionais devem
existir independentemente da organização e do projeto que está sendo
executado. Os processos fundamentais são instanciados de acordo com a
situação. Estes processos, atividades e tarefas podem ser adaptados de
acordo com as características de um projeto de software.
3.1.2. O ISSO/IEC 15504

22
A norma ISSO/IEC 15504, também conhecida como SPICE foi publicada

pela ISO em outubro de 2003 para a avaliação de processos de software. A
norma define um modelo bi-dimensional que tem como objetivo avaliar os
processos de software tendo como foco a melhoria dos processos e seus
níveis de capacidade. Cada uma das categorias de processo é detalhada como
específicos ou subcategorias. Este modelo visa avaliar a capacidade da
organização processo por processo, permitindo assim sua melhoria, onde cada
um dos processos deve ser classificado por níveis (incompleto, executado,
gerenciado, estabelecido, previsível e otimizado).
A norma ISO/IEC 15504 define um modelo de referência de processo

onde identifica e descreve um conjunto de processos considerados
fundamentais para a boa prática da engenharia de software. São definidos 6
níveis de capacidade, sequencias e cumulativos onde são utilizados como
métrica para analisar e avaliar um processo. A norma também define um guia
de referência e orientação sobre um modelo de processo sendo uma das
etapas a avaliação do processo.
3.1.3. O CMMI (Capability Maturity Model Integration)
O CMMI (Capability Maturity Model Integration) é um modelo de

melhoria de processos que prove as organizações alguns elementos essenciais
à implementação efetiva de processos (SEI, 2008).
Existem duas representações disponíveis para o modelo CMMI

disponíveis: (a) contínua ou (b) por estágio (SEI, 2001).
(a) Representação Continua
A organização pode escolher a ordem em que as melhorias serão

implementadas para melhor atender os objetivos da empresa. Esta
representação é caracterizada por Níveis de Capacidade (Capability Levels):
• Nível 0: Incompleto
23
• Nível 1: Executado
• Nível 2: Gerenciado
• Nível 3: Definido
• Nível 4: Quantitativamente gerenciado
• Nível 5: Em otimização
(b) Representação Por Estágios
Como representado
do na Figura 5 a organização segue um caminho pré-
pré
determinado para melhoria baseada em estágios. Cada estágio serve de base
para o próximo. É caracterizado por Níveis de Maturidade (Maturity
(Maturity Levels).
Levels
Figura 5 – Níveis de maturidade do CMMI
3.1.4. O Modelo de referência (MR-MPS)

(MR
Segundo a SOFTEX o modelo de referência define níveis de maturidade

onde são apresentados como uma combinação entre processos e sua
24
capacidade. Os processos são definidos seguindo os requisitos para um

modelo de referência de processos definidos na ISO/IEC 15504-2. Assim pode-
se atribuir graus de efetividade na execução dos processos, como o MPS.BR é
apenas um guia de referência ele não apresenta as atividade e tarefas
necessárias para atingir os objetivos do projeto, ficando essa a cargo do
usuário.
“A capacidade do processo é a caracterização da habilidade do

processo para alcançar os objetivos de negócio, atuais e futuros;
estando relacionada com o atendimento aos atributos de processo
associados aos processos de cada nível de maturidade”. (SOFTEX,
2007)
3.1.4.1. Níveis de Maturidade
Os níveis de maturidade são como degraus na evolução da

implementação dos processos da 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.
O MR-MPS define sete níveis de maturidade, começando-se pelo G e

progredindo até o A:
Nível A: Em Otimização;
Nível B: Gerenciado Quantitativamente;
Nível C: Definido;
Nível D: Largamente Definido;
Nível E: Parcialmente Definido;
Nível F: Gerenciado;
Nível G: Parcialmente Gerenciado;

25
A evolução da empresa com relação a seu nível de maturidade é

definida conforme os o processo alcançam os resultados e propósitos do
processo e seus atributos relacionados a níveis anteriores.
3.1.4.2. Capacidade do processo
A SOFTEX define que a capacidade do processo é constituída por um

conjunto de atributos de processo descrito em termos de resultados esperados.
Sendo que o grau de refinamento e institucionalização com que o processo é
executado, expressa sua capacidade do processo. No modelo MPS.BR sempre
que uma organização evolui seu nível de maturidade conseqüentemente um
maior nível de capacidade para desempenhar o processo deve ser alcançado.
O atendimento dos atributos do processo (AP), pelo atendimento

segundo os resultados esperados dos atributos do processo (RAP) é requerido
para todos os processos correspondentes ao nível de maturidade, sendo a sua
execução acumulativa. Sendo assim uma organização que atingiu o nível de
maturidade F deve possuir todos os processos do nível F e também do nível G
obrigatoriamente. A capacidade do processo possui nove atributos de
processos (AP) que são: AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP
4.2, AP 5.1 e AP 5.2.
A seguir são listados os atributos de processo, de acordo com o Guia de

Implementação. (SOFTEX, 2007)
AP 1.1 - O processo é executado
RAP1 - O processo atinge seus resultados definidos;
AP 2.1 - O processo é gerenciado
RAP2 - Existe uma política organizacional estabelecida e mantida

para o processo;
RAP3 - A execução do processo é planejada;

26
RAP4 - A execução do processo é monitorada e ajustes são

realizados para atender aos planos;
RAP5 - Os recursos necessários para a execução do processo são

identificados e disponibilizados;
RAP6 - As pessoas que executam o processo são competentes em

termos de formação, treinamento e experiência;
RAP7 - A comunicação entre as partes interessadas no processo é

gerenciada de forma a garantir o seu envolvimento no projeto;
RAP8 - O estado, atividades e resultados do processo são revistos

com os níveis adequados de gerência (incluindo a gerência de alto
nível) e problemas pertinentes são tratados.
AP 2.2 - Os produtos de trabalho do processo são gerenciados
RAP 10 - Requisitos para documentação e controle dos produtos de

trabalho são estabelecidos;
RAP 11 - Os produtos de trabalho são documentados e colocados

em níveis apropriados de controle;
RAP 12 - Os produtos de trabalho são avaliados objetivamente com

relação aos padrões, procedimentos e requisitos aplicáveis e são
tratadas as não conformidades.
AP 3.1 - O processo é definido
RAP 13 - Um processo padrão é definido, incluindo diretrizes para

sua adaptação para o processo definido;
RAP 14 - A seqüência e interação do processo padrão com outros

processos são determinadas.
AP 3.2 - O processo está implementado

27
RAP 15 - Dados apropriados são coletados e analisados,

constituindo uma base para o entendimento do comportamento do
processo, para demonstrar a adequação e a eficácia do processo, e
avaliar onde pode ser feita a melhoria contínua do processo.
AP 4.1 - O processo é medido
RAP 16 - As necessidades de informação requeridas para apoiar

objetivos de negócio relevantes da organização e dos projetos são
identificadas;
RAP 17 - A partir do conjunto de processos padrão da organização e

das necessidades de informação são selecionados os processos
e/ou elementos do processo que serão objeto de análise de
desempenho;
RAP 18 - Objetivos de medição do processo e/ou sub-processo são

derivados das necessidades de informação;
RAP 19 - Objetivos quantitativos de qualidade e de desempenho dos

processos e/ou sub-processos são derivados das necessidades de
informação;
RAP 20 - Medidas e a freqüência de realização das medições são

identificadas e definidas de acordo com os objetivos de medição do
processo/sub-processo e os objetivos quantitativos de qualidade e de
desempenho do processo;
RAP 21 - Resultados das medições são coletados, analisados e

reportados para monitorar o atendimento dos objetivos quantitativos
de qualidade e de desempenho do processo/sub-processo;
RAP 22 - Resultados de medição são utilizados para caracterizar o

desempenho do processo/sub-processo.
AP 4.2 - O processo é controlado

28
RAP 23 - Técnicas de análise e de controle de desempenho são

identificadas e aplicadas quando necessário;
RAP 24 - Limites de controle de variação são estabelecidos para o

desempenho normal do processo;
RAP 25 - Dados de medição são analisados com relação a causas

especiais de variação;
RAP 26 - Ações corretivas são realizadas para tratar causas

especiais de variação;
RAP 27 - Limites de controle são redefinidos, quando necessário,

seguindo as ações corretivas;
RAP 28 - Modelos de desempenho do processo são estabelecidos e

mantidos.
AP 5.1 - O processo é objeto de inovações
RAP 29 - Objetivos de melhoria do processo são definidos de forma

a apoiar os objetivos de negócio relevantes;
RAP 30 - Dados adequados são analisados para identificar causas

comuns de variação no desempenho do processo;
RAP 31 - Dados adequados são analisados para identificar

oportunidades para aplicar melhores práticas e inovações;
RAP 32 - Oportunidades de melhoria derivadas de novas tecnologias

e conceitos de processo são identificadas;
RAP 33 - Uma estratégia de implementação é estabelecida para

alcançar os objetivos de melhoria do processo.
AP 5.2 - O processo é otimizado continuamente
RAP 34 - O impacto de todas as mudanças propostas é avaliado com

relação aos objetivos do processo definido e do processo padrão;
29
RAP 35 - A implementação de todas as mudanças acordadas é

gerenciada para assegurar que qualquer alteração no desempenho
do processo seja entendida e sejam tomadas as ações pertinentes;
RAP 36 - A efetividade das mudanças, levando em conta o seu

desempenho resultante, é avaliada com relação aos requisitos do
produto e objetivos do processo, para determinar se os resultados
são devidos a causas comuns ou a causas especiais.
A Tabela 2 mostra os níveis de maturidade, seus processos e atributos

definidos no MR-MPS.
30
Tabela 2 - Níveis de maturidade Fonte: SOFTEX (2007)

31
3.1.4.3. O MA-MPS
Segundo SOFTEX (2005) o Método de Avaliação considera a aderência

aos processos estabelecidos para cada nível e a adequação dos atributos de
processo (AP) que implementam os processos. O grau de implementação dos
resultados dos atributos de processo (RAP), relacionados a um processo e a
um dos sete níveis estabelecidos, deve ser avaliado a partir de Indicadores.
Estes indicadores podem ser: direto (D) onde documentos que comprovem que
uma atividade foi realizada, indireto (I) sendo que os artefatos intermediários
resultante de alguma atividade e afirmação (A) onde é realizado uma entrevista
com os membros do projeto avaliado, onde será questionado como o projeto foi
implementado.
O grau de implementação dos indicadores deve ser avaliado de acordo

com as quatro situações a seguir: Totalmente Implementada (T); Largamente
Implementada (L); Parcialmente Implementada (P); e Não Implementada (N),
conforme Tabela 3.
32
Grau de Implementação Caracterização Grau de Alcance
Totalmente • O indicador direto está presente e > 85% a 100%

Implementado julgado adequado.
• Existe pelo menos um indicador

indireto e/ou afirmação para confirmar
a implementação.
• Não foi notada nenhuma fraqueza

substancial
Largamente > 50% a 85%

Implementado
• O indicador direto está presente e
julgado adequado.
• Existe pelo menos um indicador

indireto e/ou afirmação para confirmar
a implementação.
• Foi notada uma ou mais fraquezas
Parcialmente • O indicador direto não está presente > 15% a 50%

Implementado ou é julgado inadequado.
• Artefatos ou afirmações sugerem que

alguns aspectos da prática estão
implementados.
• Fraquezas foram documentadas.
Não Implementado • Qualquer situação diferente das 0 a 15%

acima.
Tabela 3 - Fonte: SOFTEX (2007)
3.1.5. Nível de maturidade G (Parcialmente Gerenciado)
Devido esse trabalho ter como principal objetivo implementar o modelo

MPS.BR em seu nível G, não trataremos dos outros níveis de maturidade
nesse documento.
O nível de maturidade G é composto pelos processos Gerência de

Projetos e Gerência de Requisitos. Neste nível os processos devem satisfazer
os atributos de processo AP 1.1 e AP 2.1.(SOFTEX, 2007)
33
3.1.6. 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. O propósito deste processo evolui à medida que a organização
cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e
outros são incorporados, de forma que a gerência de projetos passe a ser
realizada com base no processo definido para o projeto e nos planos
integrados. No nível B, a gerência de projetos passa a ter um enfoque
quantitativo, refletindo a alta maturidade que se espera da organização.
(SOFTEX, 2007)
Resultados esperados deste processo:
GPR1 - O escopo do trabalho para o projeto é definido;
GPR2 - As tarefas e os produtos de trabalho do projeto são

dimensionados utilizando métodos apropriados;
GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos;
GPR4 - (Até o nível F) 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 ;
GPR5 - O orçamento e o cronograma do projeto, incluindo marcos e/ou

pontos de controle, são estabelecidos e mantidos;
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;
GPR7 - Os recursos humanos para o projeto são planejados

considerando o perfil e o conhecimento necessários para executá-lo;
34
GPR8 - As tarefas, os recursos e o ambiente de trabalho necessário

para executar o projeto são planejados;
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;
GPR10 - (Até o nível F) Planos para a execução do projeto são

estabelecidos e reunidos no Plano do Projeto;
GPR11 - A viabilidade de atingir as metas do projeto, considerando as

restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes
são realizados;
GPR12 - O Plano do Projeto é revisado com todos os interessados e o

compromisso com ele é obtido;
GPR13 - (Até o nível F) O progresso do projeto é monitorado com

relação ao estabelecido no Plano do Projeto e os resultados são
documentados;
GPR14 - O envolvimento das partes interessadas no projeto é

gerenciado;
GPR15 - Revisões são realizadas em marcos do projeto e conforme

estabelecido no planejamento;
GPR16 - 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;
GPR17 - 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.
35
3.1.7. Processo: Gerência de Requisitos – GRE
O propósito do processo Gerência de Requisitos é gerenciar os

requisitos dos produtos e componentes do produto do projeto e identificar
inconsistências entre os requisitos, os planos do projeto e os produtos de
trabalho do projeto. (SOFTEX, 2007)
Resultados esperados deste processo:
GRE1 - O entendimento dos requisitos é obtido junto aos fornecedores

de requisitos;
GRE2 - Os requisitos de software são aprovados utilizando critérios

objetivos;
GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos

de trabalho é estabelecida e mantida;
GRE4 - Revisões em planos e produtos de trabalho do projeto são

realizadas visando identificar e corrigir inconsistências em relação aos
requisitos;
GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto.
3.1.8. Capacidade do processo para o nível de maturidade
Para se considerar que o processo é “ADERENTE” ao Nível G do MR-

MPS, a organização deve atender aos resultados esperados RAP1 a RAP8,
sendo necessário que os atributos do processo sejam caracterizados como T
(totalmente implementado) ou L (largamente implementado).
3.1.9. Processo de Avaliação
A avaliação proposta pelo MA-MPS tem como propósito verificar a

maturidade da unidade organizacional na execução de seus processos de
36
software. Nele é descrito o conjunto mínimo de atividades e tarefas a serem

realizadas para atingir a certificação desejada.
Uma avaliação seguindo o MA-MPS tem validade de 3 (três) anos a

contar da data em que a avaliação final foi concluída na unidade organizacional
avaliada conforme a Figura 6.
Figura 6 – Processo de avaliação do MPS.BR (SOFTEX, 2007c)
Segundo o próprio guia, para que uma avaliação seja conduzida com
sucesso, é necessário (SOFTEX, 2006):
Comprometimento do patrocinador: o comprometimento do

patrocinador é essencial para assegurar que os objetivos da
avaliação sejam atingidos. [...]
• Motivação: a atitude da gerência da unidade organizacional tem
forte impacto nos resultados de uma avaliação.[...]
• Fornecimento de feedback: o fornecimento de feedback e o
estabelecimento de uma atmosfera que encoraje a discussão aberta
sobre os resultados preliminares, durante a avaliação, ajudam a
assegurar que a avaliação seja significativa para a unidade
organizacional.
• Confidencialidade: o respeito à confidencialidade das fontes de
informação e documentação recolhidas durante a avaliação é
essencial para que se obtenha as informações necessárias.[...]
• Percepção dos benefícios: os membros da unidade organizacional
devem perceber que a avaliação resultará em benefícios que os
ajudarão direta ou indiretamente a realizar o seu trabalho.
• Credibilidade: o patrocinador, o gerente e os colaboradores da
unidade organizacional devem acreditar que a avaliação chegará a
um resultado representativo da organização/unidade
organizacional.[...]
37
3.2. MPS.BR X CMMI
Como o modelo MPS.BR é baseado nas normas ISO/IEC 12207 e

ISO/IEC 15504 ou seja, mesmas normas onde se baseia o CMMi (Capability
Maturity Model integration) eles possuem equivalência.
Os dois modelos possuem níveis de maturidade onde são definidos os

processos e suas capacidades. Os níveis de maturidade do CMMi variam de 1
ao 5 em contrapartida os níveis do MPS.BR variam da letra G a letra A, tendo o
nível A como maior nível e como principal diferença do CMMi o primeiro nível
do MPS.BR já exige que a empresa utilize determinados processos.
Por o modelo MPS.BR possuir mais níveis, ele possibilita a implantação

dos processos de uma forma gradual, diminuindo muito impacto de mudanças
de paradigmas da empresa e também reduzindo o custo de sua implantação.
Tendo como base as características de processos e implementação hoje

os modelos MPS.BR e CMMi se equivalem em níveis de qualidade de software,
porém para a implementação em pequenas e médias empresas o MPS.BR é
uma alternativa pelo seu custo reduzido, tanto na implementação quanto em
sua certificação.
CMMi MPS.BR
5 Análise Causal e Resolução – CAR A Análise de Causas de Problemas e
Inovação e Melhoria Organizacional – OID Resolução – ACP
Desempenho do Proc. Organizacional – OPP
4 B
Gerência Quantitativa de Projeto – QPM Gerência Quantitativa do Projeto
Análise de Decisão e Resolução – ADR
Desenvolvimento para Reutilização –
C
DRU
Foco no Processo da Organização – OPF Gerência de Riscos – GRI
Definição do Processo da Organização – Desenvolvimento de Requisitos – DRE
OPD Integração do Produto – ITP
Treinamento Organizacional – OT D Projeto e Construção do Produto – PCP
3 Gerência Integrada de Projeto – IPM Validação – VAL
Gerência de Risco – RSKM Verificação – VER
Desenvolvimento de Requisitos – RD Avaliação e Melhoria do Processo
Solução Técnica – TS Organizacional – AMP
Integração de Produto – PI Definição do Processo Organizacional –
E
Verificação – VER DFP
Validação – VAL Gerência de Recursos Humanos – GRH
Análise de Decisão e Resolução – DAR Gerência de Reutilização – GRU
38
Gerência de Requisitos – REQM Aquisição – AQU

Planejamento de Projeto – PP Gerência de Configuração – GCO
F
Acompanhamento e Control. de Projeto – Garantia da Qualidade – GQA
PMC Medição – MED
Gerência de Acordos com Fornecedores –
2
SAM
Garantia da Qualidade de Processo e
G
Produto – PPQA
Gerência de Configuração – CM Gerência de Projetos – GPR
Medição e análise – MA Gerência de Requisitos – GRE
Tabela 4 – Relação entre os níveis do MPS.BR e CMMi
3.3. RATIONAL UNIFIED PROCESS
O RUP é uma metodologia muito abrangente e que possui extensa

documentação e de fácil acesso a qualquer pessoa interessada. Aqui será
apresentada apenas uma introdução ao assunto, com alguns pontos principais
que tornaram esta a escolha para metodologia de referência ao modelo a ser
proposto para a Auspex.
O Rational Unified Process é um processo de engenharia de software

desenvolvido originalmente pela Rational Software, hoje pertencente a IBM
(KRUTCHEN, 2003, pg.17). O RUP, como é conhecido, é composto por um
conjunto de disciplinas que fornecem diretrizes para a definição das tarefas e
para a atribuição das responsabilidades. Seu objetivo é garantir a criação de
softwares de alta qualidade, que atenda às necessidades expressas pelo
cliente e pelos usuários, e às restrições de prazo e custo. O RUP segue as
melhores práticas de desenvolvimento de software: desenvolvimento iterativo,
gerenciamento de requisitos, arquitetura baseada em componentes,
modelagem visual do software, verificação constante da qualidade e controle
de mudanças (MARTINS, 2007, pg. 192).
3.3.1. Desenvolvimento Iterativo
No modelo proposto pelo RUP de desenvolvimento iterativo, o objetivo é

conduzir o projeto em pequenos trechos, ou ondas. Em cada iteração, um
trecho do sistema é analisado, alguns requisitos e riscos são abordados,
39
analisados, implementados, testados e implantados. Em seguida outra iteração

tem início com as mesmas etapas, levando em consideração outros requisitos
e riscos. Assim sucessivamente até que o sistema seja completamente
implementado. Desta forma é possível ter um melhor gerenciamento dos
requisitos a medida que as necessidades são analisadas mais a fundo dentro
de cada iteração. Outra vantagem é a facilidade para incluir novas idéias e
requisitos ao projeto que podem ser analisados na próxima iteração. Este
mecanismo permite aumentar significativamente as chances de sucesso.
(KRUTCHEN, 2003, pg. 5-7).
3.3.2. Gerenciamento de requisitos
Segundo Leffingwell e Widrig (2003, pg. 15), um requisito pode ser

definido por:
• Uma capacidade necessária pelo usuário para resolver um problema

e alcançar um objetivo.
• Uma capacidade que deve ser encontrada ou possuída por um

sistema ou componente do sistema para satisfazer um contrato,
norma, especificação ou outro documento formal imposto.
O maior desafio do gerenciamento de requisitos está no fato dos

requisitos mudarem constantemente durante a vida do projeto. Com o
andamento do projeto e vários motivos podem acarretar nas mudanças dos
requisitos (KRUTCHEN, 2003, pg. 7). Alguns destes motivos, de acordo com
Martins (2007, pg. 194), são:
1. Usuário muda de idéia;
2. O problema muda;
3. Mudanças técnicas;
4. Mudanças no mercado.
40
3.3.3. Arquitetura baseada em componentes
Um componente é um pedaço de software, que pode ser um módulo, um

pacote ou um subsistema, cuja a finalidade é executar uma função específica e
coesa. Os vários componentes juntos formam a arquitetura do sistema.
(MARTINS, 2007, pg 194).
A abordagem baseada em componentes serve para viabilizar a

reutilização e personalização dos componentes em larga escala. O objetivo
final é que cada componente seja o mais próximo possível de uma peça de
Lego, onde várias peças possam ser juntadas para formar um sistema maior
completo, sem que seja necessário produzir todas as peças individualmente
(KRUTCHEN, 2003, pg. 8).
3.3.4. Modelagem visual do software
O modelo é a simplificação da realidade e descreve completamente o

sistema a ser desenvolvido a partir de um certo ponto de vista. O RUP utiliza-
se extensivamente dos modelos providos pelo UML. O uso de modelos ajuda a
equipe a especificar, construir e documentar a estrutura e os comportamentos
esperados do software. Através dos modelos, a complexidade geral do sistema
pode ser dividida em vários níveis de abstração, facilitando seu entendimento.
(MARTINS, 2009, pg. 196)
3.3.5. Verificação constante da qualidade
A correção de problemas de software no início do projeto pode chegar a

ser 1000 vezes mais barata do que quando feita após a sua implantação . Com
os testes sendo realizados a cada iteração, a avaliação da qualidade é feita de
forma contínua, sendo possível identificar de forma mais eficaz quais os
cenários que apresentaram falha. Além das falhas serem detectadas mais cedo
41
no ciclo de vida, os custos de correção também são diminuídos drásticamente

(KRUTCHEN, 2003, pg. 11-12).
3.3.6. Controle de mudanças
O objetivo do controle de mudanças é de controlar as versões dos

artefatos produzidos, isolando os efeitos das mudanças entre os grupos de
trabalho que trabalham em paralelo (KRUTCHEN, 2003, pg. 12).
42
4. IMPLEMENTAÇÃO
4.1. DIAGNÓSTICO DA SITUAÇÃO ATUAL
4.1.1. Processo: Gerencia de projetos (GPR)
GPR1 - O escopo do trabalho para o projeto é definido
- Processo em prática
Para todo o projeto é elaborado a declaração de escopo, que contém:

objetivo, descrição, requisitos, serviços não incluídos, organização da equipe,
EAP (Estrutura Analítica de Projeto), cronograma e assinatura do gerente de
projetos e dos patrocinadores.
- Ação para desenvolver a competência
O escopo passará a ser definido no documento “proposta” que deverá

ser formalizado com a assinatura dos patrocinadores e do gerente de projetos.
GPR2 – As tarefas e os produtos de trabalho do projeto são

dimensionados utilizando métodos apropriados
A estimativa do projeto é feita através do número de requisitos e do

levantamento da EAP (Estrutura Analítica do Projeto) que é baseado na
experiência de outros projetos.
A EAP (estrutura analítica de projeto) passará a constar no item 5 do

documento “plano de projeto”.
GPR3 – O modelo e as fases do ciclo de vida do projeto são definidos;
43
As fases do ciclo de vida são: Iniciação, Protótipo, Planejamento,

Construção, Testes, Transição.
As fases do ciclo de vida do projeto foram redefinidas e serão:

concepção, elaboração, construção, transição conforme podemos observar na
Figura 7.
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
Quando existem projetos semelhantes, o histórico é utilizado.
Será mantido o processo existente.
GPR5 – O orçamento e o cronograma do projeto, incluindo marcos e/ou

pontos de controle, são estabelecidos e mantidos
O cronograma e o orçamento são estabelecidos de modo a serem

cumpridos e o seu acompanhamento é feito através de reuniões periódicas.

44
O orçamento passará a constar no item 8 do documento “proposta”.
O cronograma passará a constar no item 7 do documento “plano de

projeto”.
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
Não existe gerenciamento de riscos.
Será implantada a análise de riscos onde constará a relação dos riscos,

os seus impactos, prioridades e ações. A análise de riscos constará no item 3
do documento “plano de projeto”.
Segundo Sommerville, existem pelo menos seis tipos de risco:
1. Risco de tecnologia: São aqueles que derivam de tecnologias de

software ou hardware usadas para desenvolver o sistema.
2. Risco de pessoal: São aqueles associados às pessoas da equipe de

desenvolvimento.
3. Riscos organizacionais: São aqueles que derivam do ambiente

organizacional no qual o software está sendo desenvolvido.
4. Riscos de ferramentas: São aqueles que derivam de ferramentas CASE

e outros softwares de apoio, usados para desenvolver o sistema.
5. Riscos de requisitos: São aqueles que derivam de mudanças de

requisitos de cliente e do processo de gerenciamento de mudança de
requisitos.
45
6. Riscos de estimativas: São aqueles que derivam de estimativas de

gerenciamento das características de sistema e estimativa de recursos
necessários para construir o sistema. (SOMMERVILLE, 2007, p.71)
Os riscos devem ser considerados segundo a sua probabilidade de

ocorrência e a gravidade dos seus efeitos. Sommerville sugere:
1. Probabilidade:
Muito baixa: < 10%
Baixa: 10 – 15%
Média: 25 – 50%
Alta: 50 – 75%
Muito alta: > 75%
2. Efeitos:
Catastrófico, sérios, toleráveis e insignificantes.
GPR7 – Os recursos humanos para o projeto são planejados

considerando o perfil e o conhecimento necessários para executá-lo
De acordo com as características do projeto e o conhecimento dos

profissionais, é que a equipe de trabalho é definida. Não existe registro formal
das competências de cada profissional.
Uma consultoria em gestão de pessoas foi contratada para a

estruturação de um plano de carreiras. Deverá ser implantado também um
sistema de gestão de competências, que permitirá gerenciar os conhecimentos
e as habilidades dos colaboradores.
46
GPR8 – As tarefas, os recursos e o ambiente de trabalho necessários

para executar o projeto são planejados
Na fase de planejamento são definidos os recursos, a tecnologia e a

infra-estrutura necessários.
Os recursos, a tecnologia e a infra-estrutura necessários são definidos

na fase de Elaboração onde pode ser visto na
Figura 9.
47
As tarefas e os recursos constarão no item 2 do documento "plano de

projeto".
O ambiente de trabalho constará no item 4 do documento "plano de

projeto".
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
Toda a documentação relevante é disponibilizada eletronicamente

através de um sistema WIKI (intranet). Inclusive com restrições de acesso a
determinadas informações.
GPR10 – Planos para a execução do projeto são estabelecidos e

reunidos no Plano do Projeto
É utilizada uma nomenclatura padrão para definir todos os documentos

de um projeto. Nesta nomenclatura constam o nome do cliente, o número do
projeto ou módulo, o tipo de documento, a seqüência e a versão.
Será implantado o documento “plano de projeto”
GPR11 – A viabilidade atingir as metas do projeto, considerando as

restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são
realizados
48
Ao longo do projeto são realizadas reuniões de acompanhamento e caso

sejam identificados problemas são definidos planos de ação.
GPR12 – O Plano do Projeto é revisado com todos os interessados e o

compromisso com ele é obtido
No início de cada projeto é realizada uma reunião de apresentação com

todos os colaboradores envolvidos.
GPR13 – O processo do projeto é monitorado com relação ao

estabelecido no Plano do Projeto e os resultados são documentados
Os projetos são monitorados através de um software de gestão de

projetos. Todo o cronograma de atividades e seus responsáveis são
cadastrados. Cada colaborador atualiza suas atividades e tem acesso ao
andamento do projeto como um todo.
A atualização ainda não é diária, e em algumas situações não reflete o

real andamento do projeto.
São realizadas reuniões de acompanhamento, mas não existem

registros formais.
O processo de monitoramento e documentação será definido no item 7

do documento “plano de projeto”.
49
GPR14 – O envolvimento das partes interessadas no projeto é

gerenciado
A comunicação com as partes interessadas é constante, mas não nem

sempre está definida no planejamento.
Definir como deverá ser efetuada o gerenciamento da comunicação

entre as partes no item 7 do documento “plano de projeto”.
GPR15 – Revisões são realizadas em marcos do projeto e conforme

estabelecido no planejamento
As revisões acontecem nas reuniões de acompanhamento, mas não

estão definidas nos marcos do projeto.
As revisões deverão constar nos marcos do projeto definidos na EAP.
GPR16 – 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
Quando os problemas são pequenos o registro é realizado através de e-

mail e para problemas mais críticos, são gerados documentos de mudança e
posterior assinatura das partes interessadas.
Em diversos casos estes documentos não são assinados, e os e-mails

não são anexados à documentação.

50
Formalizar as alterações com a assinatura do patrocinador.
GPR17 – 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
A solução do problema é definida no documento de mudanças e

acompanhada até a sua conclusão. Entretanto quando se trata de um “bug”,
em muitos casos não é feito um gerenciamento formal.
Para o gerenciamento de bugs será implantado um software de controle.
4.1.2. Processo: Gerência de Requisitos (GRE)
4.1.2.1. GRE1 - O entendimento dos requisitos é obtido junto aos fornecedores

de requisitos
Os fornecedores de requisitos são identificados e aprovados pelo

patrocinador, mas não consta em documento formal.
Após o levantamento preliminar de requisitos efetuado com o(s)

fornecedor (es) de requisitos, são realizadas reuniões internas com a equipe
envolvida. O objetivo destas reuniões é clarificar e analisar a viabilidade dos
requisitos levantados.
Os fornecedores de requisitos, os patrocinadores, bem como os

procedimentos de comunicação entre as partes devem constar no item 7 do
documento "plano de projeto".
51
Os requisitos levantados junto aos fornecedores de requisitos deverão

constar no "documento de requisitos".
GRE2 - Os requisitos de software são aprovados utilizando critérios

objetivos
Não são utilizados critérios objetivos para aprovação dos requisitos.
Será implantada a estrutura de escritório de projetos, que será

responsável pela aprovação interna dos documentos de requisitos. A
aprovação dos requisitos deverá seguir critérios objetivos definidos pelo
escritório de projetos.
GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos

de trabalho é estabelecida e mantida
Não existe rastreabilidade de requisitos.
O escritório de projetos será responsável pela definição da política de

rastreabilidade. Segundo Sommerville, as políticas de rastreabilidade definem
os relacionamentos entre os requisitos e o projeto do sistema, que devem ser
registrados, e como esses registros devem ser mantidos. (SOMMERVILLE,
2007)
GRE4 - Revisões em planos e produtos de trabalho do projeto são

realizadas visando identificar e corrigir inconsistências em relação aos
requisitos
Revisões em planos e produtos de trabalho não são realizadas.

52
Implantação de planos de testes para cada requisito do sistema. Um

projeto somente será aprovado caso passe pelos testes integrados definidos
pelo plano de testes. Caso haja mudanças nos requisitos, o plano de testes
também deverá alterado e novos testes deverão ser realizados de modo a
garantir a consistência dos requisitos do projeto.
GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto
Quando ocorre mudanças nos requisitos são realizadas reuniões com a

equipe envolvida para identificar os seus impactos no projeto. É gerado um
documento de mudanças onde são descritas as alterações, as justificativas, os
impactos na qualidade, cronograma e riscos. Este documento é assinado pelo
solicitante, pelo aprovador e pelo gerente do projeto.
4.1.3. Acompanhamento da Implantação
Para cada prática relacionada a uma área de processo serão definidos

indicadores. Segundo o MPS.BR-Guia de Avaliação, os indicadores de
implementação podem ser de três tipos:
Indicadores diretos: são os objetivos de uma tarefa, ou seja, o produto

principal da realização de uma tarefa.
Indicadores indiretos: são artefatos que são conseqüência da realização

de uma tarefa e que referendam a implementação de um resultado, mas que
não são o objetivo da realização da tarefa.
Afirmações: são obtidas em entrevistas e/ou apresentações e confirmam

a implementação do processo, seus resultados e atributos.
53
A partir da definição dos indicadores, os projetos piloto, serão avaliados

quanto ao grau de implementação dos resultados esperados. O MPS.BR-Guia
de Avaliação define uma escala para caracterização do grau de implementação
de um resultado esperado do processo e de um resultado esperado do atributo
do processo nos projetos, conforme visto na Tabela 5.
Após cada avaliação, será elaborado um relatório com os pontos fortes,

pontos fracos e oportunidades de melhoria, buscando otimizar os processos
existentes.
Grau de implementação Caracterização
Totalmente implementado - O indicador direto está presente e é julgado

adequado;
(T)
- Existe pelo menos um indicador indireto e/ou
afirmação confirmando a implementação;
- Não foi notado nenhum ponto fraco substancial;
Largamente implementado - O indicador direto está presente e é julgado

adequado;
(L)
- Existe pelo menos um indicador indireto e/ou
afirmação confirmando a implementação;
- Foi notado um ou mais pontos fracos

substanciais;
Parcialmente implementado - O indicador direto não está presente ou é

julgado
(P)
inadequado;
- Artefatos/afirmações sugerem que alguns

aspectos do resultado esperado estão
implementados;
- Pontos fracos foram documentados;
Não implementado - Qualquer situação diferente das acima;

54
(N)
Não avaliado - O projeto não está na fase de desenvolvimento

que permite atender ao resultado ou não faz
(NA)
parte do escopo do projeto atender ao resultado;
Fora do escopo - O resultado esperado está fora do escopo da

avaliação, conforme documentado no plano da
(F)
avaliação;
Tabela 5 - Graus de implementação do MPS-BR
4.2. ESTRUTURAR O GERENCIAMENTO DE PROJETOS
4.2.1. Modelo de Escritório de Projetos
O escritório de projetos é o departamento da organização responsável

por determinar as políticas e metodologias para o gerenciamento de projetos. É
dele que saem os modelos de documentos a serem usados na documentação
orientada principalmente aos gerentes, executivos e clientes. Documentação
técnica, como guia de programação, devem ser delegados ao departamento de
qualidade. É responsabilidade do escritório de projetos também, a guarda dos
documentos dos projetos a fim de prover informações de registros históricos e
lições aprendidas em projetos anteriores. Além disso, é dele a responsabilidade
pelas auditorias em projetos em andamento ou finalizados. Acima de tudo, o
escritório de projetos é responsável pelo treinamento e suporte para os
gerentes de projetos (MONTEIRO, 2008). No capítulo 5.2.2 será abordado sua
função no processo proposto.
55
4.2.2. Metodologia de gerenciamento de projetos
Devido à grande quantidade de assunto a ser abordada neste tópico, ele

será discutido posteriormente no capítulo 5, que tratará exclusivamente do
processo de desenvolvimento e gerenciamento de projetos proposto para a
Auspex.
4.2.3. Software de gerenciamento de projetos
A empresa deve adquirir, ou desenvolver, o software que será utilizado

para o gerenciamento dos projetos. Existem várias opções no mercado, como o
largamente difundido Microsoft Project, e algumas gratuitas como o dotProject.
4.2.4. Política de gerenciamento de projetos
Por se tratar de uma mudança na cultura organizacional e operacional

da empresa, muita resistência pode ser enfrentada na implantação da nova
metodologia. Desta forma, a implantação deve ser acompanhada de um
documento formal da diretoria que estabeleça, para os gerentes de projetos e
suas equipes, a política que passará a ser adotada em relação ao
gerenciamento. A política de gerenciamento de projetos deve conter os prazos
para o alinhamento dos projetos as novas práticas estabelecidas na nova
metodologia em implantação. (XAVIER et al., 2005)
4.3. TREINAMENTO
4.3.1. Treinamento na metodologia
O treinamento deve ser planejado dependendo do impacto causado pela

nova metodologia adotada. Quanto mais aderente aos processos já em prática
anteriormente, menor o tempo perdido no treinamento, bem como o custo do
56
mesmo. Porém, um treinamento criterioso deve ser aplicado mesmo que a

mudança seja mínima.
4.3.2. Treinamento no software de gerenciamento
Da mesma forma que o treinamento na metodologia é necessário, um

treinamento para a aplicação da metodologia utilizando a ferramenta escolhida
não pode ser esquecido. (XAVIER et al., 2005)
4.3.3. Treinamento para os executivos no acesso às informações
"É impossível ter sucesso na condução da guerra sem informações

recentes e de boa qualidade", escreveu o grande duque de
Marlborough. George Washington concordava: "A necessidade de
obter informações de qualidade é evidente e não precisa ser objeto
de debate". (KEEGAN, 2006)
Gerentes, diretores e demais executivos da organização devem estar

aptos a conseguirem extrair as informações a respeito dos projetos. (XAVIER
et al., 2005)
4.4. APLICAÇÃO E ACOMPANHAMENTO
4.4.1. Definição de um projeto piloto
Para verificar a real aderência a nova metodologia e poder mensurar a

aplicabilidade da nova metodologia, um ou mais projetos pilotos devem ser
definidos.
57
4.4.2. Reuniões de acompanhamento da aplicação do modelo
O escritório de projetos deverá fazer um acompanhamento rigoroso

do(s) projeto(s) piloto(s), cobrando e indicando quais os processos e
documentos previstos na metodologia devem ser entregues pelos gerentes de
projetos (XAVIER et al., 2005).
4.4.3. Avaliações periódicas dos resultados
As reuniões de acompanhamento também servem para avaliar os

resultados obtidos. Durante a implantação do novo modelo, é muito importante
detectar os desvios o mais cedo possível para que o projeto não acabe sendo
feito como “antigamente”. Da mesma forma que as correções precisam ser
feitas prontamente, as conquistam também devem ser divulgadas. Pequenas
conquistas matem a equipe motivada a seguir adiante.
4.5. ENCERRAMENTO
4.5.1. Diagnóstico da nova situação atual
Ao final do projeto, ou de cada fase, uma análise do estágio de

maturidade do gerenciamento de projetos deve indicar a evolução da empresa.
Deve ser registrado, através de um relatório, todas as lições aprendidas, as
práticas que deram certo e os problemas encontrados. (XAVIER et al., 2005)
4.5.2. Institucionalização da metodologia
Estando o processo aprovado e documentado, já tendo sido aplicado em

ao menos um projeto piloto, a metodologia está pronta para ser difundida em
todos os outros projetos em andamento na empresa, bem como nos que
futuramente se iniciarem.
58
5. PROCESSOS DEFINIDOS PARA A AUSPEX
O planejamento estratégico para gestão de projetos é o

desenvolvimento de uma metodologia padrão que se possa utilizar
repetidamente com alta probabilidade de atingir os objetivos do
projeto (KEZNER, 2006, pg 161).
Este capítulo descreverá o processo proposto para ser utilizado na

empresa Auspex Desenvolvimento de Negócios em Tecnologia. Para chegar a
este processo, foram analisados os processos já utilizados na empresa, suas
virtudes e suas deficiências. Com base nesta análise, e no estudo do Rational
Unified Process (RUP 2001), pode-se propor as melhorias que resultaram no
processo a seguir.
5.1. FASES DO CICLO DE VIDA
O ciclo de vida do processo de desenvolvimento de software foi dividido

em quatro fases como demonstrada na
Figura 7, Ciclo de vida de desenvolvimento na Auspex (SZIMANSKI;

ROUILLER; SOUZA, 2009).
59
Figura 7: Ciclo de vida de desenvolvimento na Auspex (SZIMANSKI; ROUILLER; SOUZA,

2009)
5.1.1. Concepção
O objetivo da fase de concepção é analisar os riscos e verificar a

viabilidade do projeto. Esta fase tem a atuação intensiva nas áreas de
modelagem de processos de negócio. Nesta fase são identificados os
problemas que necessitam ser resolvidos e a elaboração de uma proposta de
um sistema computacional para solucioná-los (KRUTCHEN, 2003, pg. 56-58).
De acordo com (MARTINS, 2007, pg. 243), os principais objetivos desta fase
são:
• Visão do produto final e definir a metodologia a ser adotada no

projeto.
• Aprovação dos stakeholders quanto aos escopo do projeto.
• Conseguir apoio econômico para a execução do projeto.
• Garantir que as funcionalidades principais do sistema estejam

claras para todos, discriminando os casos de uso críticos, que
irão guiar as decisões mais relevantes do projeto.
• Explorar as arquiteturas candidatas de acordo com os principais

cenários.
60
• Estimar o custo e prazo globais e estimativas detalhadas para a

fase de elaboração.
• Levantar os principais riscos de insucesso do projeto.
Figura 8: Ciclo de vida: Concepção (SZIMANSKI; ROUILLER; SOUZA, 2009)
5.1.2. Elaboração
Segundo Martins (2007, pg. 244), nesta fase se faz uma análise mais
criteriosa dos requisitos, ampliando a lista e formalizando-os em um documento
específico. Assim pode-se gerar um orçamento e um cronograma mais
detalhado, planejando os trabalhos a serem realizados. Nesta fase as
disciplinas de análise de requisitos e análise de sistemas são as mais
61
requisitadas (KRUTCHEN, 2003, pg. 58-60). Nesta fase também pode ser
necessária a atuação de um designer gráfico na criação de um protótipo inicial.
1. Os objetivos desta fase são:
2. Descrição do trabalho a ser realizado;
3. Cronograma e orçamento detalhados;
4. Planejamento da fase de construção.
Figura 9: Ciclo de vida: Elaboração (SZIMANSKI; ROUILLER; SOUZA, 2009)
5.1.3. Construção
62
Nesta fase é que o produto propriamente dito é implementado. Enquanto

as fases anteriores possuem um caráter de exploração e pesquisa, esta fase é
focada na produção do software que é o produto final do projeto (KRUTCHEN,
2003, pg. 60-62). De acordo com Martins (2007, pg. 245), os objetivos desta
fase são:
• Produzir o software dentro do planejado nas fases anteriores;
Aqui é importante ressaltar que o objetivo não é reduzir custos ou

entregar mais rápido o produto do projeto. O importante é seguir o
planejamento das fases anteriores com controle suficiente para que as
melhorias possam ser posteriormente integradas ao processo (MARTINS,
2007, pg. 245).
63
Figura 10: Ciclo de vida: Construção (SZIMANSKI; ROUILLER; SOUZA, 2009)
5.1.4. Transição
Nesta fase, também conhecida como “Distribuição”, o produto é

instalado no ambiente final onde será utilizado pelo usuário ou a entrega do
software empacotado e pronto para a instalação. Esta fase se inicia quando o
produto está pronto o suficiente para ser colocado em produção (KRUTCHEN,
2003, pg. 62-63). Os objetivos desta fase são (MARTINS, 2007, pg. 246):
• Teste de homologação;
64
• Treinamento de usuários;
• Instalação em ambiente de produção;
• Fechamento do projeto.
Figura 11: Ciclo de vida: Transição (SZIMANSKI; ROUILLER; SOUZA, 2009)
5.2. PAPÉIS
O papel é a definição do comportamento de um indivíduo quando ele

está inserido no processo. Nada impede que um mesmo profissional assuma
mais de um papel num mesmo projeto ou em projetos diferentes (MARTINS,
2007, pg. 197). Os papéis são definidos a seguir.
5.2.1. Atendimento
65
Responsável pelo primeiro contato com o cliente e responsável por

responder pelo cliente dentro da empresa. Cria uma solicitação de serviço de
acordo com as necessidades levantadas junto ao cliente.
5.2.2. Escritório de projetos
Este papel têm a função de validar os documentos e auxiliar o gerente

do projeto. No caso da Auspex, este papel não será exercido por uma pessoa,
mas por um comitê formado por analistas de sistemas sênior e pelo diretor de
desenvolvimento (MONTEIRO, 2007, pg. 14)
5.2.3. Gerente de projeto
Executa as funções de gerenciamento, planejamento e controle,

alocando recursos, ajustando as prioridades, coordenando as interações com
os clientes e usuários e mantém a equipe do projeto concentrada na meta
(MARTINS, 2007, pg. 8). O gerente de projeto também estabelece um conjunto
de práticas que garantem a integridade e a qualidade dos artefatos do projeto
(KRUTCHEN, 2003, pg. 95-198).
5.2.4. Analista de negócios
Coordena a modelagem de casos de uso de negócios, delimitando o

sistema a ser desenvolvido e estabelecendo os atores envolvidos e como estes
interagem com os casos de uso. Analisa a viabilidade do sistema e presta
consultoria ao cliente a respeito das regras de negócio necessárias ao mesmo
tempo que formaliza estas regras junto à equipe de desenvolvimento
(KRUTCHEN, 2003, pg. 95-198).
66
5.2.5. Analista de sistema
Refina as características técnicas do sistema definido pelo cliente junto

com o analista de negócios. Lidera e coordena a identificação de requisitos e a
modelagem de casos de uso, delimitando o sistema e definindo sua
funcionalidade; por exemplo, estabelecendo quais são os atores e casos de
uso existentes e como eles interagem (KRUTCHEN, 2003, pg. 95-198).
5.2.6. Analista de teste
Responsável por definir os testes a serem realizados no a fim de garantir

a qualidade geral do sistema desenvolvido. Também é responsável por
especificar os dados que devem ser utilizados nos testes e avaliar os
resultados obtidos na execução dos mesmos. É auxiliado pelo Analista de
Segurança na especificação dos testes para garantir também a integridade do
sistema após este ser colocado em ambiente de produção (KRUTCHEN, 2003,
pg. 95-198).
Esse papel é responsável por:
• Identificar os Itens de Teste-alvo a serem avaliados pelo esforço

de teste;
• Definir os testes apropriados necessários e quaisquer Dados de

Teste associados;
• Coletar e gerenciar os Dados de Teste;
• Avaliar o resultado de cada ciclo de teste.
5.2.7. Analista de segurança
Enquanto o analista de teste se preocupa com as funcionalidades do

sistema com relação ao atendimento dos requisitos especificados, o analista de
67
segurança define um conjunto de testes necessários para assegurar a

integridade das informações inseridas, geradas ou disponibilizadas pelo
sistema. Recomenda medidas de segurança tanto no desenvolvimento dos
sistemas quanto na configuração de hardware e software a serem utilizados no
desenvolvimento e na implantação do sistema no cliente (KRUTCHEN, 2003,
pg. 95-198).
5.2.8. Desenhista de interface
Lidera e coordena a construção do protótipo e o design da interface do

usuário da seguinte forma (KRUTCHEN, 2003, pg. 95-198):
• Capturando os requisitos da interface do usuário, incluindo

requisitos de usabilidade;
• Construindo protótipos de interface do usuário;
• Incluindo outros envolvidos da interface de usuário, como

usuários, nas revisões de usabilidade e nas sessões de teste de
uso;
• Revisando e fornecendo o feedback apropriado sobre a

implementação final da interface do usuário, se criada por outros
desenvolvedores, ou seja, designers e implementadores;
5.2.9. Controlador de versão
Gerencia as versões do código, documentando os releases, e

executando o deploy da aplicação (KRUTCHEN, 2003, pg. 95-198).
5.2.10. Programador
Responsável por desenvolver e testar componentes de acordo com os

padrões adotados para o projeto, para fins de integração com subsistemas
68
maiores. Quando é necessário criar componentes de teste, como drivers ou

stubs, para possibilitar a realização dos testes, o implementador também é
responsável por desenvolver e testar esses componentes e os subsistemas
correspondentes (KRUTCHEN, 2003, pg. 95-198).
5.2.11. Projetista de banco de dados
Define tabelas, índices, visões, restrições, triggers, procedimentos

armazenados, parâmetros de armazenamento e outras construções específicas
de um banco de dados necessárias para armazenar, recuperar e excluir
objetos persistentes (KRUTCHEN, 2003, pg. 95-198).
5.2.12. Testador
Responsável pelas atividades centrais do esforço de teste, que envolve

conduzir os testes necessários e registrar os resultados desses testes. Isso
inclui (KRUTCHEN, 2003, pg. 95-198):
• Identificar a abordagem de implementação mais apropriada para um

dado teste;
• Implementar testes individuais;
• Configurar e executar os testes;
• Registrar os resultados e verificar a execução dos testes;
• Analisar erros de execução e recuperar-se deles.
5.2.13. Técnico de infra-estrutura
Prestar suporte aos usuários da rede de computadores, envolvendo a

montagem, reparos e configurações de equipamentos e na utilização do
hardware e software disponíveis. Disponibilizar o ambiente para o
69
desenvolvimento de software de acordo com as definições do gerente do

projeto, bem como configurar o ambiente de produção para o sistema
desenvolvido caso necessário (MARTINS, 2007, pg. 203-243).
5.3. ARTEFATOS
5.3.1. Solicitação de serviço
Descrição geral do produto a ser desenvolvido, contendo no mínimo

informações a respeito das necessidades do negócio que o produto deverá
atender e características do produto que será produzido. Além disso, quando
possível, deve incluir informações a respeito do prazo para desenvolvimento e
orçamento disponível. A solicitação de serviço serve como marco inicial ou
termo de abertura do projeto e é a base para o Documento de Visão
Responsável: Atendimento
Aprovador: Analista de negócios
5.3.2. Documento de Visão
No documento de Visão é definida a visão que os envolvidos têm do

produto final a ser desenvolvido, suas necessidades e características mais
importantes (KRUTCHEN, 2003, pg. 135-136). Por conter uma descrição dos
principais requisitos, ela é a base para os requisitos mais detalhados e para os
documentos mais específicos.
Responsável: Gerente de projetos
Aprovador: Analista de negócios
5.3.3. Proposta de projeto

70
Proposta comercial contendo o objetivo, a necessidade de negócio,

escopo do trabalho a ser realizado, prazo, preço (orçamento), condições e
termos para a realização do desenvolvimento. A proposta é feita com base nos
documentos Solicitação de serviço e Visão. (XAVIER et al., 2005)
Responsável: Gerente de projeto.
Aprovador: Escritório de projetos, diretor comercial.
5.3.4. Documento de requisitos
Planilha contendo todos os requisitos, identificados e classificados de

acordo com a prioridade, estabilidade e impacto. No decorrer do
desenvolvimento e após os testes eles são atualizados de acordo com o estado
de satisfação do mesmo dentro do sistema (totalmente satisfeito, parcialmente
satisfeito ou insatisfeito) (KRUTCHEN, 2003, 140-142).
Responsável: Gerente de projetos, analista de sistemas
Aprovador: Escritório de projetos
5.3.5. Plano do Projeto
O Plano do Projeto é um artefato composto e abrangente que reúne

todas as informações necessárias ao gerenciamento do projeto (MONTEIRO,
2008). Pode ser considerado o principal documento e deve ser mantido durante
todo o desenvolvimento.
Responsável: Analista de sistemas, gerente de projeto
5.3.6. Protótipo
71
Artefato opcional onde o propósito é ajudar no levantamento dos

requisitos ou provar um conceito através da demonstração empírica
(KRUTCHEN, 2003, pg. 58-59).
Responsável: Projetista de interface
5.3.7. Diagrama ER
Modelo entidade-relacionamento descreve o relacionamento entre

tabelas de um banco de dados, no qual as relações são construídas através da
associação de um ou mais atributos destas tabelas refletindo uma percepção
do mundo real (OLIVEIRA, 2000).
Responsável: Projetista de banco de dados
5.3.8. Banco de dados
Subconjunto do modelo de implementação que descreve a

representação lógica e física dos dados persistentes no sistema. Também
abrange qualquer comportamento definido no banco de dados, como
procedimentos armazenados, triggers, restrições etc.
Responsável: Projetista de banco de dados
5.3.9. Código fonte
Conjunto de palavras ou símbolos escritos de forma ordenada, contendo

instruções em uma linguagem de programação, que deve seguir as regras
descritas no Guia de Programação da Auspex.
Responsável: Programador
72
5.3.10. Plano de teste
Roteiro dos testes a serem executados, referenciando os requisitos do

sistema, o procedimento a ser tomado e os resultados esperados. Para facilitar
os testes, o plano é cadastro diretamente no software específico para este
procedimento (KRUTCHEN, 2003, pg. 169).
Responsável: Analista de teste
5.3.11. Registro de bugs
Registro dos bugs encontrados no sistema, cadastrados em software

específico para correção, controle da qualidade do produto e futuras melhorias
no processo de desenvolvimento.
Responsável: Testador
5.3.12. Controle de mudança
Descreve as mudanças solicitadas, os impactos no projeto quanto ao

cronograma, custo e qualidade. As mudanças podem ser solicitadas para
corrigir defeitos, implementar melhorias ou mudanças de regras de negócios
que podem acarretar mudanças em requisitos ou mesmo no escopo do projeto
(MONTEIRO, pg 42-44).
Responsável: Atendimento, Gerente de projeto.
Aprovador: Diretor comercial caso acarrete mudanças no orçamento.
5.3.13. Documento de aceite
Descreve os produtos e serviços que foram entregues pelo projeto,

referenciando os requisitos solicitados na Solicitação de serviço, Proposta de
73
projeto e possíveis requisitos gerados por solicitações de mudança durante o

andamento do projeto. (XAVIER et al., 2005, pg. 286)
Responsável: Gerente de projeto
5.4. RELAÇÃO DO PROCESSO PROPOSTO AOS PROCESSOS DO MPS.BR
Este capítulo é um complemento ao capítulo 4.1 (Diagnóstico da

situação atual) com o intuito de facilitar a identificação dos resultados
esperados do MPS.BR dentro do processo proposto para a Auspex. A Tabela 6:
GPR no processo da Auspex e a Tabela 7: GRE no processo da Auspex, ilustram o
grau de implementação de cada resultado esperado de atributo de processo
através dos indicadores diretos. Os números dos processos indicados são
referentes aos diagramas apresentados nos capítulos 5.1.1, 5.1.2, 5.1.3 e
5.1.4. A ressalva fica no item GPR13 onde, apesar de não estar explícito no
diagrama, a tarefa é feita com o auxílio do software de gerenciamento de
projetos dotProject.
74
GPR – Gerência de Projetos

Esperado Processo Documento: TÓPICO
GPR1 - O escopo do trabalho para o projeto é 1.7 Proposta: ESCOPO DA
definido 1.8 PROPOSTA
Proposta: ESCOPO NÃO

INCLUÍDO NO PROJETO
GPR2 – As tarefas e os produtos de trabalho 2.5 Plano de Projeto: ESTRUTURA
do projeto são dimensionados utilizando ANALÍTICA
métodos apropriados
GPR3 – O modelo e as fases do ciclo de vida 2.5 Plano de Projeto: ESTRUTURA
do projeto são definidos 2.8 ANALÍTICA
GPR4 – O esforço e o custo para a execução 2.6 Plano de Projeto: CRONOGRAMA
das tarefas e dos produtos de trabalho são E ORÇAMENTO DO PROJETO
estimados com base em dados históricos ou
referências técnicas
GPR5 – O orçamento e o cronograma do 1.8 Plano de Projeto: MECANISMOS
projeto, incluindo marcos e/ou pontos de 2.6 DE MONITORAÇÃO E
controle, são estabelecidos e mantidos 2.8 ELABORAÇÃO DE RELATÓRIOS
GPR6 – Os riscos do projeto são identificados 2.4 Plano de Projeto: ANÁLISE DE
e o seu impacto, probabilidade de ocorrência RISCOS
e prioridade de tratamento são determinados
e documentados
GPR7 – Os recursos humanos para o projeto 2.7 Plano de Projeto: ORGANIZAÇÃO
são planejados considerando o perfil e o DO PROJETO
conhecimento necessários para executá-lo
GPR8 – As tarefas, os recursos e o ambiente 2.3 Plano do Projeto: ORGANIZAÇÃO
de trabalho necessários para executar o DO PROJETO
projeto são planejados
Plano de Projeto: REQUISITOS DE
RECURSOS DE HARDWARE E
DE SOFTWARE
GPR9 – Os dados relevantes do projeto são 2.3 Plano de Projeto: REQUISITOS DE
identificados e planejados quanto à forma de RECURSOS DE HARDWARE E
coleta, armazenamento e distribuição. Um DE SOFTWARE
mecanismo é estabelecido para acessá-los,
incluindo, se pertinente, questões de
privacidade e segurança
GPR10 – Planos para a execução do projeto 2.3 ao 2.9 Plano de Projeto
são estabelecidos e reunidos no Plano do
Projeto
GPR11 – A viabilidade atingir as metas do 1.8 Proposta
projeto, considerando as restrições e os 1.9
recursos disponíveis, é avaliada. Se Plano de Projeto: ANÁLISE DE
necessário, ajustes são realizados RISCO
GPR12 – O Plano do Projeto é revisado com 2.9 Plano de Projeto: APROVAÇÃO
todos os interessados e o compromisso com
ele é obtido
GPR13 – O processo do projeto é monitorado *dotProje Plano de Projeto: MECANISMOS
com relação ao estabelecido no Plano do ct DE MONITORAÇÃO E
Projeto e os resultados são documentados ELABORAÇÃO DE RELATÓRIOS
75
GPR14 – O envolvimento das partes 2.3 Plano de Projeto: ORGANIZAÇÃO

interessadas no projeto é gerenciado DO PROJETO
GPR15 – Revisões são realizadas em marcos 1.5 Plano de Projeto: MECANISMOS
do projeto e conforme estabelecido no DE MONITORAÇÃO E
planejamento ELABORAÇÃO DE RELATÓRIOS
GPR16 – Registros de problemas 3.1 Solicitação de Mudança:
identificados e o resultado da análise de 3.2 PARECER DO GERENTE DE
questões pertinentes, incluindo dependências PROJETO
críticas, são estabelecidos e tratados com as
partes interessadas Solicitação de Mudança:
PARECER DO AUTORIZADOR
GPR17 – Ações para corrigir desvios em 3.1 Solicitação de Mudança
relação ao planejado e para prevenir a 3.2
repetição dos problemas identificados são 3.3
estabelecidas, implementadas e
acompanhadas até a sua conclusão
Tabela 6: GPR no processo da Auspex
GRE - Gerência de Requisitos

Esperado Processo Documento
GRE1 - O entendimento dos requisitos é 1.6 Declaração de Requisitos
obtido junto aos fornecedores de requisitos 2.1
2.2
GRE2 - Os requisitos de software são 2.1 Declaração de Requisitos
aprovados utilizando critérios objetivos 2.2 (Aprovação do Escritório de
Projetos e do Cliente)
GRE3 - A rastreabilidade bidirecional entre os 2.1 Declaração de Requisitos
requisitos e os produtos de trabalho é 3.7
estabelecida e mantida 3.8 Código Fonte
3.9
Plano de Teste
GRE4 - Revisões em planos e produtos de 3.7 Código Fonte
trabalho do projeto são realizadas visando 3.8
identificar e corrigir inconsistências em 3.9 Plano de Teste
relação aos requisitos
GRE5 - Mudanças nos requisitos são 3.1 Solicitação de Mudança
gerenciadas ao longo do projeto 3.2
3.3
Tabela 7: GRE no processo da Auspex
Como dito anteriormente no capítulo 3.1.8, a organização deve atender

aos resultados esperados RAP1 a RAP8 e estes devem ser caracterizados
como T (totalmente implementado) ou L (largamente implementado). Seguindo
o esperado nas tabelas 6 e 7, espera-se que todos os resultados esperados
76
dos processos necessários a avaliação sejam caracterizados como T

(totalmente implementado).
77
6. RESULTADOS E VALIDAÇÃO
O estudo do modelo MPS.BR proposto pela SOFTEX foi o ponto de

início para um aperfeiçoamento de vários aspectos gerenciais e técnicos. No
início dos trabalhos pensou-se em buscar a avaliação nível F do
MPS.BR, porém durante o andamento dos trabalhos e da análise da
situação da empresa viu-se que a meta seria dificilmente atingida e
optou-se por limitar-se ao nível G e à definição dos processos de
desenvolvimento.
Após decidido que o trabalho seria limitado ao nível G, ocorreu a

formalização do projeto e em seguida, foi definido que o SEPG (Software
Engineering Process Group) seria formado por apenas um gerente de projetos.
O SEPG ficou responsável pela identificação das deficiências da

empresa em relação aos critérios utilizados na avaliação nível G do MPS.Br,
definindo um novo processo de desenvolvimento de software aderente aos
requisitos do nível G do MPS.BR.
Para a implantação das melhorias necessárias o SEPG definiu um

processo de implantação que foi aplicado em um projeto piloto. O resultado
deste processo de implantação é descrito em seguida.
6.1. CONSCIENTIZAÇÃO
A conscientização dos colaboradores foi feita com o envolvimento da

diretoria ratificando a importância da implantação do processo de melhoria.
Como algumas pessoas estão acostumadas a trabalhar de uma outra

maneira, é importante que em diversas oportunidades sejam ressaltados os
progressos obtidos.
Como todas as etapas do processo estão sendo seguidas no projeto

piloto, pode-se concluir que a equipe está consciente da importância
da implementação do processo.
78
6.2. DIAGNÓSTICO DA SITUAÇÃO ATUAL
O diagnóstico da situação atual foi feito segundo cada etapa da gerência

de projetos (GPR) e da Gerência de requisitos (GRE), identificando os
processos em prática e ações para desenvolver a competência.
Para buscar a avaliação desejada, várias deficiências foram sendo

identificadas. Apesar do MPS.BR ser bem claro a respeito dos
resultados esperados ele não define uma metodologia ou um método para
se conseguir o resultado. Este foi justamente um dos grande desafios
na definição dos processos, já que mudanças radicais não eram aceitas
pela diretoria da empresa. O desafio foi definir um processo aderente
ao MPS.BR com base em metodologias difundidas no mercado mas que não
introduzissem mudanças radicais nos processos já em prática na Auspex.
Este processo levou à pesquisa e análise não só do modelo (MPS.BR),
mas também dos processos e das ferramentas que poderiam ser utilizadas
para facilitar o controle dos projetos. Algumas destas ferramentas e
melhorias nos processos foram sendo absorvidos naturalmente pela
equipe de desenvolvimento sem a necessidade de treinamento específico
e antes mesmo da formalização de um projeto piloto. Isso se deveu
a preocupação em propor um modelo que se adaptasse aos
processos que já eram utilizados e a ação inicial nos pontos mais
deficientes, obtendo resultados positivos de forma gradual em todas as
mudanças que foram propostas.
6.3. ESTRUTURAR GERENCIAMENTO DE PROJETOS

79
Um dos primeiros passos para a implementação do processo de

melhoria, foi a estruturação do escritório de projetos, que foi responsável pela
determinação das políticas e metodologias para o gerenciamento de projetos
apresentadas neste trabalho. Além da escolha dos softwares e da definição de
todos os modelos de documentos utilizados no gerenciamento dos projetos.
Muito embora a empresa já trabalhasse orientada a projetos, não havia

uma centralização ou uma coordenação formal. Com o escritório de projetos,
houve a necessidade de se alterar o organograma das equipes dos projetos
sendo definido um novo papel, o de líder de projeto.
Instituiu-se uma reunião semanal com todos os líderes dos projetos,

coordenada pelo escritório de projetos que tem como objetivo fazer o
acompanhamento de cada projeto.
Uma das preocupações na atribuição de um líder do projeto foi com

relação à desmotivação dos outros colaboradores. Entretanto foram utilizados
alguns critérios objetivos, como a experiência e conhecimento do projeto como
um todo. Outra questão colocada é que o fato de ser líder em um projeto não
implicaria em ser líder sempre e que haveria oportunidades para todos.
Outro risco identificado seria se o líder seria aceito e respeitado pelo

grupo, já que os outros colaboradores apresentam o mesmo nível hierárquico.
Antes do ser criado o papel de líder de projeto, os colaboradores respondiam
diretamente a um gerente de projetos, que muitas vezes estava
sobrecarregado gerenciando outros projetos. Com o líder, eles passaram a ter
mais atenção e passou a solução de problemas e dúvidas passou a ser mais
ágil. Este ganho foi bastante perceptível e esta nova estrutura foi naturalmente
incorporada.
6.4. TREINAMENTO
80
O treinamento na metodologia foi restrito aos participantes do projeto

piloto, entretanto, o treinamento no software de gerenciamento foi aplicado a
todos os colaboradores da Auspex, inclusive seus executivos.
Como vários processos foram alterados e ou criados, resultando em

uma mudança cultural significativa, percebeu-se a necessidade de se efetuar o
treinamento de uma forma mais efetiva e prática, com o escritório de projetos
dando suporte sempre que necessário.
As dúvidas freqüentes foram com relação aos processos como a quem

se reportar e com relação aos modelos de documentos. Como a clareza da
metodologia é fator determinante na implantação dos processos, deveria ter
sido investido mais tempo nesta etapa de implantação.
6.5. APLICAÇÃO E ACOMPANHAMENTO
A partir da definição dos processos aderente ao nível G do MPS.BR, foi

escolhido um projeto piloto para a análise e avaliação dos resultados práticos.
Para que todos os processos fossem avaliados, optou-se por um projeto

novo, a fim de acompanhá-lo desde o seu início e que tivesse um porte
razoável que permitisse a implantação do processo em sua complitude.
Projeto piloto:
Sistema web de comparação de produtos.
Cliente:
Auspex – cliente interno
Equipe do projeto:
- 1 Líder de projeto;
- 1 Analista de sistemas;
- 1 DBA;
81
- 1 Analista de segurança;
- 3 desenvolvedores;
- 1 Analista de testes;
Prazo:
9 meses
Por se tratar de um projeto de longa duração, este trabalho de conclusão

de curso se encerrou antes que se desse o término do projeto. Ao final deste
trabalho, o projeto se encontrava em processo de construção, faltando ainda as
etapas de transição e finalização.
Muito embora o projeto piloto ainda estivesse em fase de construção,

todos os processos e artefatos resultantes de cada etapa acompanhada até a
finalização deste trabalho, haviam sido implementados.
O papel o escritório de projetos na aplicação e acompanhamento do

modelo foi decisivo para a implantação do projeto piloto.
O principal risco encontrado foi na resistência de alguns colaboradores.

Por atuar diretamente na cultura da empresa e consequentemente na questão
comportamental dos seus colaboradores, o escritório de projetos teve como
uma de suas principais características a habilidade de negociar e encontrar
caminhos para alcançar os objetivos do projeto.
Durante a implantação do projeto piloto, por diversas vezes os

processos não foram seguidos, principalmente com relação ao papel do líder
de projeto, com os colaboradores se reportando diretamente ao gerente de
projetos. Nestas situações houve a necessidade da intervenção do escritório de
projetos que através de reuniões procurou explicar e conscientizar sobre a
importância de se respeitar os processos. Sendo necessário, em alguns
momentos, cobrar da diretoria o comprometimento assumido em relação ao
projeto.
82
6.6. ENCERRAMENTO
Como o projeto piloto não foi finalizado na conclusão deste trabalho,

esta etapa não foi implantada.
Apesar de o projeto piloto não haver sido finalizado, pode-se perceber

que ainda há muito trabalho a ser feito antes de se submeter a uma avaliação
final do MPS.BR. Para que os processos funcionem adequadamente em toda a
empresa, será necessário uma reestruturação formal do seu organograma,
definindo melhor as funções de cada papel adotado informalmente, como o de
líder de projeto e escritório de projetos.
Estas dificuldades encontradas, que dizem respeito principalmente à

cultura da empresa, devem ser vista com atenção. Em um primeiro momento, a
implantação dos processos descritos neste trabalho parece aplicável para
qualquer empresa similar, isso é verdade para algumas etapas do processo,
mas mais como uma referência do que propriamente um modelo a ser seguido,
porque cada empresa tem suas características que devem ser respeitadas.
83
7. CONCLUSÃO
Apesar de nem todos os resultados obtidos terem sido os esperados no

início do trabalho, podemos concluir que o objetivo de melhoria no controle e
na qualidade dos processos foi alcançado. Na data do término deste trabalho a
Auspex ainda não havia se submetido à avaliação do MPS.BR para poder
certificar os procedimentos aqui descritos.
Para trabalhos futuros seria interessante definir uma ferramenta, ou

conjunto delas, que pudessem auxiliar e facilitar os processos de controle.
Formas de conscientização e de treinamento também são um campo aberto
para pesquisas futuras. Uma análise mais aprofundada nos modelos de
desenvolvimento como o próprio RUP, descrito superficialmente neste
documento, podem facilitar neste caso.
Outra área muito promissora para um próximo trabalho, pode ser o

estudo da validade dos processos aqui propostos quando aplicados às
metodologias ágeis de desenvolvimento. Como estas metodologias se baseiam
no conceito de focar mais nos resultados que nos processos, grande parte da
burocracia é descartada, tornando muito diferente as formas de controle dos
processos necessários à avaliação do MPS.BR.
84
8. REFERÊNCIAS
ABES - Associação Brasileira das Empresas de Software. Mercado Brasileiro

de Software – Panorama e Tendências, edição 2006.
ABES - Associação Brasileira das Empresas de Software. Mercado Brasileiro

de Software – Panorama e Tendências, edição 2007.
ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ISO/IEC

12207 – Tecnologia da Informação – Processos de ciclo de vida de
software. Rio de Janeiro: ABNT, 1998.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do Usuário.

Tradução 2a. ed.:Campus, 2005.
GIBSON, D. L.; GOLDENSON, D. R.; KOST, K. Performance Results of

CMMI®-Based Process Improvement . Agosto de 2006. Disponível em
<http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html>.
Acesso em: maio de 2008.
KEEGAN, J. Inteligência na guerra. Companhia das Letras, 2006.
KERZNER, H. Gestão de Projetos: as melhores práticas. Tradução Lene

Belon Ribeiro. 2. ed., Porto Alegre: Bookman, 2006.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software. Novatec Editora,

2007
KRUTCHEN, P. INTRODUÇÃO AO RUP: RATIONAL UNIFIED PROCESS.

1a. ed., Rio de Janeiro: Editora Ciência Moderna Ltda, 2003.
LEFFINGWELL, D.; WIDRIG, D. Managing software sequirements: a use

case approach. 2a. ed., Boston, MA: Addison Wesley, 2003.
MARTINS, J. C. C. Gerenciando Projetos de Desenvolvimento de Software

com PMI, RUP e UML. 4a. ed., Rio de Janeiro: Brasport, 2007.
MONTEIRO, A. Certificação PMP. 2a. ed. rev., Rio de Janeiro: Brasport, 2008.
OLIVEIRA, A. R.; FERNANDES, L. M. P.; TAVEIRA, G. A. Modelagem de

Dados. Rio de Janeiro: Editora Senac Nacional, 2000.
PRESSMANN, R. S. Engenharia de software. 6a. ed., São Paulo: Mc Graw

Hill, 2006, pg. 349.
85
SEI – Software Engeneering Institute. What is CMMI?. Disponível em:

<http://www.sei.cmu.edu/cmmi/general>. Acesso em: maio de 2008.
SEI – Software Engeneering Institute. CMMI/SM for Systems Engineering

and Software Engineering (CMMI-SE/SW, V1.1) Staged Representation,
2001. Disponível em
<http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr002.pdf>. Acesso
em: abril de 2008.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro.

MPS.BR – Melhoria de Processo de Software Brasileiro, Guia Geral
(Versão 1.2). SOFTEX, 2007.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro.

MPS.BR – Melhoria de Processo de Software Brasileiro, Guia de
Implementação - Parte 1: Nível G (Versão 1.1). SOFTEX
SZIMANSKI, F.; ROUILLER, A. C.; SOUZA, A. D. Aplicando MPS.BR nível G

na melhoria do processo de desenvolvimento de software numa pequena
empresa. Disponível em :
<http://www.unibratec.com.br/jornadacientifica/diretorio/NOVOAPLIC.pdf>.
Acesso em abril de 2009.
VARGAS, D.; NIGRI, M.; KRIEGER, M.; et al., Melhoria de Processos na

Marlin. Disponível em:
<http://www.softex.br/portal/softexweb/uploadDocuments/_mpsbr/T9-Marlin-
WE.pdf>. Acesso em: março de 2008.
XAVIER, C. M. S; VIVACQUA, F. R.; MACEDO, O. S.; XAVIER, L. F. S.

Metodologia de gerenciamento de projetos - METHODWARE. Rio de
Janeiro: Brasport, 2005
86
APÊNDICES
87
APÊNDICE A - MODELO DE SOLICITAÇÃO DE SERVIÇO

88
<nome do cliente>
Projeto: <nome>
Solicitação de Serviço <código do documento>
Elaborado por: <nome e função> Aprovado por: <nome e função>
Assinatura: Assinatura:
Data de Elaboração: ___/___/______ Data da aprovação: ___/___/______
Dados do cliente:
[Apresenta informações gerais da empresa solicitante, site, telefone, pessoa de contato]
Justificativa:
[Apresentar as razões pelas quais o projeto se faz necessário, o objetivo e uma visão geral do projeto.]
Requisitos:
[Apresentar os requisitos preliminares do projeto]
Prazo de entrega:
[Citar o prazo desejado para a entrega]
Orçamento:
[ Caso seja possível, levantar o orçamento esperado]
Data da entrega da proposta: ___ / ___ / ______.

89
APÊNDICE B - MODELO DE DOCUMENTO DE VISÃO

90
<nome da empresa
patrocinadora>
<nome do projeto>
<código do documento>
Documento de Visão
<local e data de elaboração do documento>
<Autor do documento>
91
INTRODUÇÃO
[A introdução do documento Visão fornece uma visão geral de todo o

seu conteúdo. Ela deve incluir a finalidade, o escopo, as definições, os
acrônimos, as abreviações, as referências e a visão geral deste documento
Visão.]
POSICIONAMENTO
OPORTUNIDADE DE NEGÓCIOS
[Faça uma breve descrição da oportunidade de negócios atendida por

este projeto.]
DESCRIÇÃO DO PROBLEMA
[Forneça uma descrição resumindo o problema que está sendo resolvido

pelo projeto. Poderá ser usado este formato:]
O Problema de [descreva o problema]
Afeta [os envolvidos afetados pelo problema]
Cujo impacto é [qual é o impacto do
problema?]
Uma boa solução seria [liste alguns dos principais
benefícios de uma boa solução]

92
DESCRIÇÕES DOS ENVOLVIDOS E DOS USUÁRIOS
[Para fornecer, de maneira eficiente, produtos e serviços que atendam

às reais necessidades dos usuários e dos envolvidos, é necessário identificar e
considerar todos os envolvidos como parte do processo de Modelagem de
Requisitos. É necessário também identificar os usuários do sistema e
assegurar que a comunidade de envolvidos os represente adequadamente.
Esta seção fornece um perfil dos envolvidos e dos usuários que integram o
projeto, e dos principais problemas que, de acordo com o ponto de vista deles,
poderão ser abordados pela solução proposta. Ela não descreve as
solicitações ou os requisitos específicos dos usuários e dos envolvidos, já que
eles são capturados em um artefato individual de solicitações dos evolvidos.
Em vez disso, ela fornece a base e a justificativa que explicam por que os
requisitos são necessários.]
VISÃO GERAL DO PRODUTO
[Esta seção fornece uma visão de nível superior dos recursos, interfaces
com outros aplicativos e configurações de sistemas do produto]
RECURSOS DO PRODUTO
[Liste e descreva brevemente os recursos do produto. Trata-se dos

recursos de nível superior do sistema que são necessários para propiciar
benefícios aos usuários. Cada recurso é um serviço desejado externamente
que normalmente exige uma série de entradas para alcançar os resultados
desejados.]
RESTRIÇÕES
[Mencione quaisquer restrições de design, restrições externas ou outras

dependências.]
INTERVALOS DE QUALIDADE
93
[Defina os intervalos de qualidade para desempenho, robustez,

tolerância a erros, usabilidade e características semelhantes que não
são capturadas no Conjunto de Recursos.]
PRECEDÊNCIA E PRIORIDADE
[Defina a prioridade dos diferentes recursos do sistema.]
OUTROS REQUISITOS DO PRODUTO
[Em um nível superior, liste padrões aplicáveis, requisitos de hardware

ou de plataforma, requisitos de desempenho e requisitos ambientais.]
REQUISITOS DE DOCUMENTAÇÃO
[Esta seção descreve a documentação que deverá ser desenvolvida

para suportar a implantação bem-sucedida de aplicativos.]
APROVAÇÃO
Relação dos aprovadores e assinatura formal.
Aprovador Assinatura Data
Nome do(a) gerente de

projetos
Escritório de projetos
94
APÊNDICE C - MODELO DE PROPOSTA DE PROJETO

95
<nome da empresa patrocinadora>
<nome do projeto>
Proposta
<Autor do documento>
OBJETIVO
O objetivo desta proposta é descrever os produtos e serviços a serem

entregues, os prazos, as condições para realização do trabalho, as
responsabilidades e as condições comerciais para realização do projeto.
DESCRIÇÃO
[ Descreve brevemente os objetivos do projeto e estabelece as restrições (por

exemplo, orçamento, prazo, etc.) que afetam o gerenciamento do projeto. ]
ESCOPO DA PROPOSTA
[ Descreve os serviços a serem prestados no escopo da proposta. O

documento de requisitos, caso tenha sido elaborado, deve ser anexado como
parte do escopo da proposta.]
ESCOPO NÃO INCLUÍDO NO PROJETO
[ Descreve os serviços que não fazem parte do escopo da proposta. ]
ORGANIZAÇÃO DA EQUIPE
[ Descreve o modo como a equipe de desenvolvimento está organizada, as

pessoas envolvidas e seus papéis na equipe. ]
RESPONSABILIDADES
RESPONSABILIDADES DO < nome do cliente>
[ Apresenta as responsabilidades do cliente na execução do projeto ]

RESPONSABILIDADES DA AUSPEX
[ Apresenta as responsabilidades da Auspex na execução do projeto ]
PRAZO E CRONOGRAMA
[ Apresenta as dependências entre as atividades, o prazo estimado

necessário para atingir cada marco, a alocação de pessoas nas atividades e
o orçamento. ]
ORÇAMENTO
[ Apresenta o orçamento, a validade da proposta e as condições comerciais

de pagamento. ]
APOIO DA ORGANIZAÇÃO
O patrocinador deverá estar disponível para quaisquer esclarecimentos que

surjam no decorrer do projeto, é de responsabilidade do patrocinador
disponibilizar pessoas com conhecimento nas regras de negócio para que,
juntamente com a equipe de projeto, os requisitos sejam detalhados.
APROVAÇÃO
Nome do(a) patrocinador(a)
Nome do(a) responsável da

Auspex
APÊNDICE D - MODELO DE DOCUMENTO DE REQUISITOS
PROJETO
Lista de Requisitos
Elaborado por: Módulo:
Aprovado por: Data de aprovação:
[ID_REQ1] – [Requisito 1]
PRIORIDADE Alta/Media/Baixa ESTABILIDADE Alta/Media/Baixa
SOLICITANTE REQ. ORIGEM
TIPO IMPACTO Alto/Medio/Baixo
DESCRIÇÃO
[ID_REQ2] – [Requisito 2]
PRIORIDADE Alta/Media/Baixa ESTABILIDADE Alta/Media/Baixa
SOLICITANTE REQ. ORIGEM

[ ID_REQ1]
TIPO IMPACTO Alto/Medio/Baixo
DESCRIÇÃO
APÊNDICE E - MODELO DE PLANO DO PROJETO
<nome da empresa
patrocinadora>
<nome do projeto>
Plano do Projeto

102
INTRODUÇÃO
[ Descreve brevemente os objetivos do projeto e estabelece as restrições (por

exemplo, orçamento, prazo, etc.) que afetam o gerenciamento do projeto. ]
ORGANIZAÇÃO DO PROJETO
[ Descreve o modo como a equipe de desenvolvimento está organizada, as

pessoas envolvidas e seus papéis na equipe. ]
ANÁLISE DE RISCOS
[ Descreve os possíveis riscos do projeto, a probabilidade da ocorrência

desses riscos e as propostas de estratégias de redução de riscos. ]
REQUISITOS DE RECURSOS DE HARDWARE E DE SOFTWARE
[ Especificam o hardware e o software de apoio necessários para realizar o

desenvolvimento. Se o hardware precisar ser comprado, podem ser incluídas
as estimativas de preços e o prazo de entrega. ]
ESTRUTURA ANALÍTICA
[ Estabelece a estrutura analítica do projeto em atividades e identifica os

marcos e os produtos a serem entregues com cada atividade. ]
CRONOGRAMA E ORÇAMENTO DO PROJETO

103
[ Apresenta as dependências entre as atividades, o prazo estimado

necessário para atingir cada marco, a alocação de pessoas nas atividades e
o orçamento. ]
MECANISMOS DE MONITORAÇÃO E ELABORAÇÃO DE RELATÓRIOS
[ Definem os relatórios de gerenciamento que devem ser produzidos, quando

eles devem ser produzidos e os mecanismos de monitoração de projeto
usados. ]
APROVAÇÃO

104
APÊNDICE F - MODELO DE CONTROLE DE MUDANÇA

105
PROJETO
Solicitação de mudança nº
Elaborado por: Módulo:
Aprovado por: Data de aprovação:
Solicitado por: Fone Contato:

Descrição da mudança solicitada:
Justificativa:
Data: Nome: Assinatura:

PARECER DO GERENTE DO PROJETO
Impactos identificados:
Observações:

PARECER DO AUTORIZADOR
Aprovação ( ) Rejeição ( )
Observações:

Implantacao Nivel G MPS BR Na Auspex - 2009

Enviado por

Dados do documento

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Implantacao Nivel G MPS BR Na Auspex - 2009

Enviado por

Direitos autorais:

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ

MBA EM GESTÃO DE PROJETO DE SOFTWARE

Luiz Gustavo Rissmann

Marcelo Jundy Kimura

Fábio Maia do Prado

Implantação do nível G do MPS.BR na

Auspex Desenvolvimento de Negócios em

Implantação do nível G do MPS.BR na Auspex

curso de pós graduação MBA em

Gestão de projetos de software da

Pontifícia Universidade Católica do

Paraná como requisito de obtenção do

Orientadora: Sheila Reinehr

0000 Sobrenome, Prenome do autor.

Monografia – Pontifícia Universidade Católica

1. Assunto do trabalho, deve ser retirado com

Implantação do nível G do MPS.BR na Auspex

Monografia apresentada ao curso de pós graduação MBA em Gestão de

Visando a melhoria da qualidade de software através da melhoria dos

Palavras chave: MPS.BR. CMMi. Gerenciamento de Projetos. Qualidade de

Aiming at increasing the quality of software through the improvement of the

Keywords: MPS.BR. CMMi. Project Manager. Software quality.

Figura 1 – Mercado brasileiro de software em 2006 (ABES, 2007) ....... 12

Figura 2 – Evolução do mercado brasileiro de software em 2006 (ABES,

Figura 3 – EAP da implantação da metodologia – adaptado de (XAVIER

Figura 4 - Componentes principais da MPS.BR (SOFTEX, 2007) ......... 20

Figura 5 – Níveis de maturidade do CMMI ............................................ 23

Figura 6 – Processo de avaliação do MPS.BR (SOFTEX, 2007c)......... 36

Figura 7: Ciclo de vida de desenvolvimento na Auspex (SZIMANSKI;

Figura 8: Ciclo de vida: Concepção (SZIMANSKI; ROUILLER; SOUZA,

Figura 9: Ciclo de vida: Elaboração (SZIMANSKI; ROUILLER; SOUZA,

Figura 10: Ciclo de vida: Construção (SZIMANSKI; ROUILLER; SOUZA,

Figura 11: Ciclo de vida: Transição (SZIMANSKI; ROUILLER; SOUZA,

Tabela 1 – Média de melhoria por categoria.......................................... 14

Tabela 2 - Níveis de maturidade Fonte: SOFTEX (2007) ...................... 30

Tabela 3 - Fonte: SOFTEX (2007) ......................................................... 32

Tabela 4 – Relação entre os níveis do MPS.BR e CMMi....................... 38

Tabela 5 - Graus de implementação do MPS-BR ................................. 54

Tabela 6: GPR no processo da Auspex ................................................. 75

Tabela 7: GRE no processo da Auspex ................................................. 75

1.1. O mercado de software _______________________________________ 11

1.2. A Auspex ___________________________________________________ 15

2.1. Objetivos Específicos__________________________________________ 16

2.2. Implementação ______________________________________________ 16

3. Revisão da Literatura ________________________________________ 19

3.1. MPS.BR ____________________________________________________ 19

3.2. MPS.BR x CMMi______________________________________________ 37

3.3. Rational Unified Process _______________________________________ 38

4.1. Diagnóstico da situação atual ___________________________________ 42

4.1.2. Processo: Gerência de Requisitos (GRE) _______________________________ 50

4.2. Estruturar o gerenciamento de projetos __________________________ 54

4.3. Treinamento ________________________________________________ 55

4.4. Aplicação e acompanhamento __________________________________ 56

4.5. Encerramento _______________________________________________ 57

5. Processos Definidos para a Auspex _____________________________ 58

5.1. Fases do ciclo de vida _________________________________________ 58

5.2. Papéis _____________________________________________________ 64

5.2.10. Programador ____________________________________________________ 67

5.3. Artefatos ___________________________________________________ 69

5.4. Relação do processo proposto aos processos do MPS.BR_____________ 73

6. Resultados e Validação ______________________________________ 77

6.1. Conscientização ______________________________________________ 77

6.2. Diagnóstico da situação atual ___________________________________ 78

6.3. Estruturar gerenciamento de projetos ____________________________ 78

6.4. Treinamento ________________________________________________ 79

6.5. Aplicação e acompanhamento __________________________________ 80

6.6. Encerramento _______________________________________________ 82