Melhoria do Processo de Software Brasileiro no Nível F

0

Centro Universitário - CESMAC
Faculdade de Ciências Exatas e Tecnológicas – FACET
Curso de Análise de Sistemas

ADSON WENDEL CIRILO FERREIRA

MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO
APLICADO NO NÍVEL DE MATURIDADE F EM UMA
EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE

Maceió/AL
2010

1



Monografia apresentada como requisito final à
obtenção do grau de bacharelado do Curso de Análise
de Sistemas, orientada pelo Prof. Alexandre Paes dos
Santos, do Centro Universitário - CESMAC

Orientador: Prof. Esp. Mozart de Melo Alves Jr.

Maceió/AL
2010

2



Indicação da natureza acadêmica do trabalho (trabalho
final de graduação), o objetivo (aprovação na
disciplina, grau pretendido), e outras informações
como o nome do professor da disciplina e da
instituição.

Data de Aprovação: ____ / ____ / ________

COMISSÃO EXAMINADORA

_________________________________________
Orientador – Prof. Esp. Mozart de Melo Alves Jr.

_________________________________________
Avaliador 1 – Prof. Esp. Sandney Farias da Cunha

_________________________________________
Avaliador 2 – Prof. Esp. Marcelo Tenório Malta

Maceió/AL
2010

3

A minha mãe, Nailda, por ser a pessoa mais importante na minha vida.

4

AGRADECIMENTOS

Em primeiro lugar, a Deus, por todas as bênçãos e vitórias acontecidas em minha vida;
A minha mãe, Nailda, por todo apoio e amor;
A minha avó, Nair, pelo suporte que sempre me deu;
Ao meu avô, Naziozeno, hoje descansa no Senhor, o qual ajudou na minha criação e
educação;
A toda minha família, pela confiança e apoio moral;
Ao meu orientador prof. Mozart, pelo imenso ensino e compartilhamento à realização deste
trabalho;
Ao meu amigo James, pela base criada, para que eu pudesse ingressar no ramo profissional
da informática;
Ao meu tio Aroldo, por ter me mostrado a necessidade e realidade de fazer um curso
superior;
Ao meu prof. Alexandre Paes, na orientação e na validação este trabalho;
Aos meus amigos da faculdade, em especial, Antonio Pascoal, Josenildo Paixão e Claudio
Chaves, pelo companheirismo e amizade;
Ao Sandney, gerente de medição; e ao Jonas, gerência da qualidade, os quais me cederam
as entrevistas, sobre a certificação da empresa KMF no MPSBR;
Aos professores do CESMAC, os quais me transmitiram parte de seus conhecimentos.

5

“Não temais, nem vos assusteis
por causa desta grande multidão, porque a
peleja não é vossa, mas de Deus. (II Crônicas 20.15)”

6

RESUMO

Esta monografia tem como objetivo apresentar a possibilidade tangível das
empresas de software de Alagoas em busca de um patamar de qualidade, planejamento e controle
para então ficarem em um nível de organização reconhecido internacionalmente, e seu produto
aceito no mercado com aprovação, utilizando o projeto Melhoria de Processo do Software
Brasileiro mais conhecido pelas suas siglas MPSBR, o qual avalia a qualidade e a produtividade
do software e serviços relacionados com padrões e características semelhantes às normas de
desenvolvimento internacional, como: CMMI, baseado no ISO/IEC 12207; e ISO/IEC 15504; as
quais são explanadas suas definições e estruturas. O projeto brasileiro é direcionados a real
condição de mercado, para o alcance das empresas públicas e privadas de diferentes tamanhos,
com maior atenção as micros, pequenas e médias empresas, retirando principalmente a
dependência do modelo CMMI, o qual utiliza valor de aquisição alta e complexa na
implementação, e como foi aplicado e certificado na empresa de software alagoana KMF Análise
e Desenvolvimento de Sistemas e Websites, no nível de maturidade F do Modelo de Referência,
em um contrato cooperado, juntamente com mais três empresas, as quais foram as primeiras do
Estado a adquirir este feito inédito de aprovação no MPSBR no nível F.

Palavras-chaves: MPSBR. CMMI. ISO/IEC 12207. ISO/IEC 15504. Maturidade.

7

ABSTRACT

The goal of this monograph is to present the tangible possibility of software
companies from Alagoas to reach a baseline of quality, planning, management and being in a
level of organization accepted internationally and the product accepted in the market with
approval, using the project Melhoria de Processo do Software Brasileiro known as MPSBR,
which evaluates the quality and productivity of the software and services related, with standard
and features similar as the standards of software development as, CMMI based on ISO/IEC
12207 and ISO/IEC 15504 that are explained, the definition and structure , the Brazilian project is
directed to the real condition of the Brazilian market, so companies from different sizes, public
and private, with more attention on micro, small and medium companies, that way removing
mainly the dependency of the model CMMI that has higher cost and more installation complexity
and as it was applied and certified in the alagoana software company KMF Análise e
Desenvolvimento de Sistemas e Websites, on the maturity level F in the Modelo de Referência, in
a cooperative contract, with three other companies, that were the first in the State to acquire this
first-time accomplishment, of approval on MPSBR in level F.

Key-words: MPSBR. CMMI. ISO/IEC 12207. ISO/IEC 15504. Maturity

8

LISTA DE FIGURAS

Figura 1: Logotipo da ISO e da IEC ............................................................................................ 17
Figura 2: Demonstra a estrutura da ISO/IEC 12207 .................................................................... 22
Figura 3: Demonstra os níveis de processo do modelo SPICE, ISO 15504. ............................... 25
Figura 4: Logotipo do modelo CMM referenciando ao nível de maturidade dois....................... 28
Figura 5: Demonstra os níveis de processo do modelo CMM. .................................................... 29
Figura 6: Ilustra os acontecimentos em cada nível do CMM....................................................... 33
Figura 7: Logotipo da norma CMMI............................................................................................ 34
Figura 8: Comparação das duas representações a de Maturidade e Contínua. ............................ 35
Figura 9: CMMI Representação por estágios. .............................................................................. 36
Figura 10: Demonstra os níveis de processo do modelo CMM. .................................................. 38
Figura 11: Logotipo do modelo MPS.BR .................................................................................... 42
Figura 12: Estrutura do projeto MPS.BR ..................................................................................... 42
Figura 13: Logotipo da Coordenadora do projeto MPS.BR ........................................................ 43
Figura 14: Descrição dos níveis de maturidade do (MR-MPS.BR) com seus processos. ........... 45
Figura 15: Descrição dos processos do Modelo de Negocio (MN-MPS.BR) ............................. 63
Figura 16: Comparação dos Níveis de Maturidade do modelo MPSBR com o modelo CMMi .. 65
Figura 17: Logotipo da empresa KMF. ........................................................................................ 67
Figura 18: Logotipo da Instituição Implementadora II COPPE/UFRJ ........................................ 68
Figura 19: Escopo do Projeto ClippingNews. .............................................................................. 70
Figura 20: Logotipo do Software Estação TABA desenvolvido na COPPE/UFRJ ..................... 74
Figura 21: Logotipo da Instituição Avaliadora, RIOSOFT. ........................................................ 75

9

LISTA DE QUADROS

Quadro 1: Visão da formação do projeto MPSBR....................................................................... 44
Quadro 2: Descrição dos resultados esperados para o processo de Gerência de Projetos .......... 47
Quadro 3: Descrição dos resultados esperados para o processo de Gerência de requisito .......... 49
Quadro 4: Descrição dos resultados esperados para o processo de Aquisição ............................ 51
Quadro 5: Descrição dos resultados esperados para o processo de Gerência de Configuração .. 52
Quadro 6: Descrição dos resultados esperados para o processo de Gerência de Portfólio de . .
... Projetos ....................................................................................................................... 54
Quadro 7: Descrição dos resultados esperados para o processo da Garantia da Qualidade ........ 55
Quadro 8: Descrição dos resultados esperados para o processo de Medição .............................. 56
Quadro 9: Descrição dos processos de avaliação ........................................................................ 62
Quadro 10: comparativos MPSBR e CMMI ................................................................................ 65
Quadro11: Resultado da Avaliação ............................................................................................. 76

10

LISTA DE ABREVIATURAS E SIGLAS

AQU Aquisição
BID Banco Interamericano de Desenvolvimento
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
CMMI-SVC CMMI for Services
CMMI-ACQ CMMI for Acquisition
CMMI-DEV CMMI for Development
FINEP Financiadora de Estudos e Projetos
FNDCT Fundo Nacional de Desenvolvimento Científico e Tecnológico
GCO Gerência de Configuração
GPP Gerência de Portfólio de Projetos
GPR Gerência de Projetos
GQA Garantia da Qualidade
GRE Gerência de requisito
ISO Institute of Organization for Standardization
IEC International Electrotechnical Commission
KPAs Key Process Areas
MA-MPS Método de avaliação
MED Medição
MN-MPS Modelos de negócio
MPSBR Melhoria de Processos do Software Brasileiro
MR-MPS Modelo de Referência
MTC Ministério de Ciência e Tecnologia
SEBRAE Suporte do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas
SEI Software Engineering Institute
SOFTEX Associação para Promoção da Excelência do Software Brasileiro
SPICE Software Process Improvement and Capability Determination

11

SUMÁRIO

INTRODUÇÃO ......................................................................................14
1 BASE HISTÓRICA DA MELHORIA DE PROCESSO DE
SOFTWARE ...........................................................................................18
1.1 ISO/IEC 12207............................................................................................... 18
1.1.1 Processos Fundamentais ......................................................................... 20
1.1.2 Processo de Apoio .................................................................................... 20
1.1.3 Processos Organizacionais ...................................................................... 22
1.2 ISO/IEC 15504............................................................................................... 24
1.2.1Categoria................................................................................................... 24
1.2.2.1 Incompleto........................................................................................... 27
1.2.2.2 Executado ............................................................................................ 27
1.2.2.3 Gerenciado .......................................................................................... 27
1.2.2.4 Estabelecido ........................................................................................ 27
1.2.2.5 Previsível............................................................................................. 28
1.2.2.6 Otimizado ............................................................................................ 28
1.3 CMM .............................................................................................................. 28
1.3.1 Níveis de Maturidade .............................................................................. 30
1.3.1.1 Inicial .................................................................................................. 31
1.3.1.2 Repetível.............................................................................................. 31
1.3.1.3 Definido............................................................................................... 32
1.3.1.4 Gerenciado .......................................................................................... 32
1.3.1.5 Em Otimização .................................................................................... 33
1.4 CMMI ............................................................................................................ 34
1.4.1 CMMI - Representação Por estágios ...................................................... 36
1.4.1.1 Inicial .................................................................................................. 37
1.4.1.2 Gerenciado .......................................................................................... 37
1.4.1.3 Definido............................................................................................... 38
1.4.1.4 Gerenciado Quantitativamente ............................................................ 38
1.4.1.5 Otimizado ............................................................................................ 38
1.4.2 CMMI - Representação Contínua .......................................................... 39
1.4.2.1 “0” Incompleto ................................................................................... 40
1.4.2.2 “1” Realizado ..................................................................................... 40
1.4.2.3 “2” Gerenciado................................................................................... 40
1.4.2.4 “3” Definido ....................................................................................... 41
1.4.2.5 “4” Gerenciado quantitativamente ..................................................... 41
1.4.2.6 “5” Otimizado ..................................................................................... 41

12

2 MPS.BR ................................................................................................42
2.1 Conceito MPSBR ........................................................................................... 42
2.2 Modelo de Referência (MR-MPS) ................................................................ 45
2.2.1 G - Parcialmente Gerenciado.................................................................. 47
2.2.1.1 Gerência de Projetos ........................................................................... 48
2.2.1.2 Gerência de requisito .......................................................................... 50
2.2.2 F – Gerenciado......................................................................................... 50
2.2.2.1 Aquisição............................................................................................. 51
2.2.2.2 Gerência de Configuração .................................................................. 53
2.2.2.3 Gerência de Portfólio de Projetos ....................................................... 54
2.2.2.4 Garantia da Qualidade........................................................................ 55
2.2.2.5 Medição............................................................................................... 56
2.2.3 E - Parcialmente Definido ....................................................................... 57
2.2.4 D - Largamente Definido ........................................................................ 58
2.2.5 C – Definido ............................................................................................. 59
2.2.6 B - Gerenciado ......................................................................................... 60
2.2.7 A - Em Otimização .................................................................................. 60
2.3 Método de Avaliação (MA-MPS).................................................................. 61
2.4 Modelo de Negócio (MN-MPS) ..................................................................... 64
2.5 Quadro comparativos entre os modelos MPSBR e CMMI ......................... 66
3 IMPLANTAÇÃO DO MPSBR NA KMF UMA EMPRESA
ALAGOANA. .........................................................................................67
3.1 A KMF ........................................................................................................... 67
3.2 A escolha do Nível ......................................................................................... 68
3.3 Viabilização Financeira ................................................................................. 69
3.4 O processo de Certificação ............................................................................ 70
3.4.1 Equipe e papel na certificação ................................................................ 70
3.4.2 Fluxo do processo do Escopo .................................................................. 71
3.4.3 Documentações Geradas ......................................................................... 72
3.4.3.1 Software Taba ..................................................................................... 74
3.4.4 Avaliação.................................................................................................. 75
3.4.4.1 Resultado ............................................................................................ 76
CONCLUSÃO ........................................................................................78
REFERÊNCIAS .....................................................................................80
ANEXO ...................................................................................................86
ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DO
PROJETO ...............................................................................................86

13

ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DO
PROJETO
(CONT
INUAÇÃO) 87
ANEXO B - MODELO DE TERMO DE ABERTURA DO
PROJETO ...............................................................................................88
ANEXO C - MODELO DE LAUDO DE AVALIAÇÃO DA
DECLARAÇÃO DO ESCOPO PELO GQPP ....................................89
ANEXO D - MODELO DE PLANO DE GERÊNCIA DE
DOCUMENTOS E COMUNICAÇÃO ................................................90
ANEXO E - MODELO DE CONTROLE DE ALTERAÇÃO DE
REQUISITOS .........................................................................................91
ANEXO G - PLANO DO PROCESSO DO PROJETO
CLIPPINGNEWS ..................................................................................94
ANEXO H - PLANO DO PROCESSO DO PROJETO
CLIPPINGNEWS ..................................................................................96

14

INTRODUÇÃO

MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa que avalia
qualidade e produtividade de software, e serviços relacionados com padrão e qualidade das
normas de desenvolvimento internacional, como CMMI, baseado no ISO/IEC 12207, e ISO/IEC
15504. Estes melhoramentos são direcionados à real condição do mercado brasileiro, para o
alcance das empresas públicas e privadas de diferentes tamanhos, com maior atenção as micros,
pequenas e médias empresas, pois atenderá as suas necessidades de negócio, para que possam ser
reconhecidas nacional e internacionalmente por um modelo de maturidade MPS.BR. Para isso,
esta monografia tem como propósito mostrar a possibilidade tangível das empresas de software
de Alagoas a buscarem um patamar de qualidade, planejamento e controle, para ficarem em um
nível de organização reconhecido internacionalmente e seu produto aceito no mercado com
aprovação.
Desta forma, objetiva-se a amostragem de como devem ser utilizadas as normas e
padrões de projetos para a melhoria de processos de qualidade de softwares, e como foi aplicado
e certificado em uma empresa de software alagoana no nível de maturidade F, mostrando os
padrões de certificações, ISO/IEC 12207 e 15504, CMM, CMMI e MPS.BR, com quadros
comparativos entre os modelos, pontuando a implantação do MPS.BR nível F na empresa
alagoana KMF, demonstrando os requerimentos do guia de maturidade G e F do modelo
brasileiro.
A dificuldade enfrentada pelas empresas de software Alagoanas, em acompanhar
as mudanças que estão acontecendo nos ambientes de negócios, tem motivado tais empresas a
procurarem e estabelecerem uma estrutura organizacional, visando processos de produção,
produtos e serviços com padrão internacional de qualidade. Os padrões (ISO/IEC 15504 e
CMMI), mesmo nos seus níveis mais baixos dos modelos CMMI (2 e 3) e a ISO/IEC 12207
dividida em classes, estão fora do alcance da micro, pequena e média empresa, especialmente no
Brasil, devido ao seu custo elevado. Como melhorar os processos de uma empresa
desenvolvedora de software se os padrões internacionais são muito caros e complexos de
implantar.

15

Com o modelo MPS.BR, solução brasileira para a melhoria de processo de
software que é até utilizada por países latino-americanos, as empresas de pequeno porte têm
possibilidades de atuarem no mercado com certificação de qualidade, com o Grau de Maturidade
“F”, onde a organização tem que passar pelos processos de: Gerência de Configuração, Gerência
de Portfólio de Projetos, Garantia da Qualidade, Aquisição, Medição e do nível “G” com os
processos de Gerência de Projeto e Gerência de Requisitos. Com a principal solução para as
empresas de Micro e Médio porte, já que a diferença orçamentária para a aquisição da norma
Internacional é muito superior à brasileira, as transições de níveis de maturidade são mais suaves
em comparação ao CMMI. Com a implantação do modelo MPS.BR, a organização ganhará
visibilidade nacional e internacional e terá uma cobrança maior na qualidade dos seus produtos e
serviços por ela prestados.
O Ministério de Ciência e Tecnologia (MTC) divulgou uma pesquisa ainda em
2001 (MCT, 2001), que relacionou indicadores de produtividades sistêmicas para as micros,
pequenas e médias empresas, e a partir dos resultados, pode se constatar a real diferença de
desempenho para as grandes organizações brasileiras. Os motivos para este largo intervalo de
desenvoltura entre os portes das empresas é um conjunto de fatores: a escassez de recurso
financeiro; uma quantidade de RH debilitado ou sem preparo para o cargo ocupado; e o mais
importante, a imaturidade dos cargos de gerência. Este, por sua vez, e deixa os processos/projetos
da empresa com uma série de problemas, atraso no tempo previsto de entrega, ou a implantação
do software com erros de funcionamentos, retornando posteriormente para que seja feito
correções no procedimento realizado com ineficácia, entre outras causas que acontecem por falta
de um planejamento. Com isso, pode comprometer sua competitividade no mercado e até a vida
útil da empresa.
O desenvolvimento desta monografia partiu do interesse de mostrar uma solução
para as empresas de softwares, com a utilização do modelo de Melhoramento de processo do
Software Brasileiro (MPS.BR), projeto proposto em 2003 e coordenado pela Associação para
Promoção da Excelência do Software Brasileiro (SOFTEX), criado para suprir as necessidades de
acordo com as carências brasileiras. Assim seria retirada uma dependência ao modelo CMMI, o
qual o valor de aquisição é alto e complexo na implementação de uma empresa. Neste projeto
internacional, poucas empresas eram certificadas por este conjunto de fatores.

16

O MPS.BR compatível com o modelo de referência internacional CMMI
(Capability Maturity Model Integration), desenvolvido pelo SEI (Software Engineering Institute),
conciliável às normas ISO/IEC 12207 e a ISO/IEC 15504, tem como objetivo traçar os resultados
esperados a serem seguidos de maneira eficiente e produtiva para a criação da estrutura dos
processos e o ciclo de vida do Software. O comitê gestor do MPS é formado pela SOFTEX
(Coordenadora); COPPE/UFRJ (coordenadora da ETM - Equipe Técnica do Modelo); RIOSOFT
em Rio de Janeiro/RJ; CenPRA em Campinas/SP; CESAR em Recife/PE e CELEPAR em
Curitiba/PR. Esse comitê recebe o apoio financeiro dos seguintes órgãos: do Ministério da
Ciência e Tecnologia (MCT); do Fundo Nacional de Desenvolvimento Científico e Tecnológico
(FNDCT); da Financiadora de Estudos e Projetos (FINEP); do Fundo Nacional de
Desenvolvimento Científico e Tecnológico (FNDCT); do fundo VERDE-AMARELO; do Banco
Interamericano de Desenvolvimento (BID) e do suporte do Serviço Brasileiro de Apoio às Micro
e Pequenas Empresas (SEBRAE).
De acordo com o relatório de avaliação contida na divulgação do dia 22 de janeiro
de 2010 da SOFTEX, existem hoje 205 empresas vigentes, certificadas no modelo de MPS.BR,
divididas pelo Grau de maturidade. No nível A, com seis empresas; no nível B não tem nenhuma
empresa com esta graduação; no C com duas; no nível D, com uma; E com seis, F com 59 e, para
finalizar, 131 com o grau de maturidade G, da qual quatro empresas de softwares Alagoanas,
participa do seleto grupo, avaliadas no nível F do MPS.BR (SOFTEX, 2010). Esta monografia irá
explanar a certificação da empresa alagoana KMF Análise e Desenvolvimento de Sistemas, que
se encontra no seleto grupo das organizações que contêm o certificado do modelo MPS.BR, e
está no grau de maturidade F, pois é uma das quatros organizações de Alagoas que utiliza o
projeto brasileiro de melhoria de processo de Software, das quais no nordeste apenas sete
empresas são certificadas (ASSESPRO, 2009). Com os padrões instalados na organização,
estabelece uma comunicação formal e uma documentação que assim possibilita um desempenho
crescente da empresa, que com a melhoria de processo proporciona conseqüentemente um grande
salto na qualidade no desenvolvimento dos processos e dos produtos e serviços, possibilitando
um domínio sobre o projeto/equipe e clientes.
A organização da monografia se dará em três capítulos, onde no primeiro é uma
visão geral sobre melhoria de processo de software com ISO 12207/15504 e CMM/CMMI,
abordando definição, Características, tempo de implantação. No segundo capítulo é detalhado o

17

MPS.BR, o modelo brasileiro sendo aprofundado nos níveis de maturidade G e F, mostrando
quadros comparativos entre os modelos CMMI e MPSBR. O terceiro e último capítulo consiste
no desenvolvimento de um estudo de caso aplicado na empresa alagoana KMF, certificada no
nível de maturidade F do MPS.BR.

18

1 BASE HISTÓRICA DA MELHORIA DE PROCESSO DE
SOFTWARE

Neste capítulo, será feita uma abordagem sobre a base histórica da melhoria de
processo de software, delimitando a ISO/IEC 12207 e sua evolução, a ISO/IEC 15504; o CMM
com seu melhoramento o CMMI, descrevendo sua origem e seus desenvolvedores. Será
apresentado, também, o conceito com as características de cada norma de melhoria de processo
de software.

1.1 ISO/IEC 12207
A norma ISO/IEC 12207, criada pela ISO (Institute of Organization for
Standardization - Organização Internacional para Padronização), juntamente com a IEC
(International Electrotechnical Commission - Comissão Eletrotécnica Internacional), teve seu
desenvolvimento proposto em 1988. Segundo Weber (20--b), “a norma foi publicada
internacionalmente em 1995, e no Brasil em 1998”. Posteriormente revisada em 2002, ela foi
criada para sanar uma preocupação de modelagem e melhoria no processo de software, tornado-
se uma das mais antigas normas que definem os processos de desenvolvimento da área abordada.

Figura 1: Logotipo da ISO e da IEC
Fonte: MIT < http://www.techshout.com/images/iso-iec-logos.jpg>

19

A ISO/IEC 12207 é a primeira norma internacional que descreve em detalhes os
processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento,
operação e manutenção de produtos de software. A principal finalidade desta norma é
servir de referência para os demais padrões que venham surgir. Lançada em agosto de
1995, ela é citada em quase todos os trabalhos relacionados à engenharia de software
desde então, inclusive aqueles relativos à qualidade (GUSMÃO; MOURA; 2004).

Estabelecer uma estrutura comum para os processos de ciclo de vida e de
desenvolvimento do softwares é o objetivo principal do modelo. Projetada a ser flexível, não tem
relações com métodos, ferramentas, treinamentos, métricas e também não tem ligações com
linguagens empregadas no desenvolvimento do programa, o que possibilita um acompanhamento
da evolução da engenharia de software e de organizações com culturas distintas, flexibilidade
importante, pois implica no “o que fazer” e não ficando refém “como fazer”, tornando o modelo
atual ubíquo, modular e adaptável às necessidades fundamentadas em dois princípios, a
modularidade e a responsabilidade. Modularidade se refere a processos com número reduzido de
acoplamento e junções, entre (módulos ou processos) e um máximo de coesão elevada, excluindo
assim falhas, e como manter e testar a dificuldade na compreensão, entre outros; contendo assim
um forte relacionamento entre as partes de um processo e o número mínimo de interfaces entre os
processos. A responsabilidade estabelece um responsável para cada processo, facilitando a
aplicação da norma, onde várias organizações ou parte dela podem estar legalmente envolvidas.
Com a utilização correta do modelo de melhoramento de software, as empresas adquirem um
conhecimento na área de processos.

A ISO/IEC 12207 tem sido amplamente utilizada em muitos países como referência
para contratação de serviços de desenvolvimento e manutenção de software. No Brasil,
muitas organizações têm tomado conhecimento da existência da norma e algumas já as
utilizam para definição de processos de desenvolvimento de software. Muitos trabalhos
de pesquisa têm utilizado a norma, o que vislumbra uma ampla utilização da mesma no
futuro (WEBER et al; 20--b; p6).

Os Processos padrões que abrangem o desenvolvimento são classificados de
acordo com suas características similares no ciclo de vida de software. Segundo Gusmão e Moura
(2004) “Esta norma divide os processos em três grandes classes: Processos Fundamentais,
Processos de Apoio e Processos Organizacionais”, cada classe com suas atividades.

20

1.1.1 Processos Fundamentais

Em linhas gerais, são todas as atividades que a organização executa nos serviços
da criação, desenvolvimento, manutenção ou operação do software. Segundo Weber ( et al; 20--b)
os processos fundamentais são formados pelos processos de aquisição, fornecimento,
desenvolvimento, operação e manutenção, os quais são descritos abaixo.
• Processo de Aquisição: define as atividades para a organização que vier a adquirir um
produto ou serviço de software que satisfaça as necessidades do cliente, incluindo seleção
de fornecedores e emissão de pedido de proposta.
• Processo de Fornecimento: define as atividades da empresa de software, com o
comprometimento na execução dos processos de desenvolvimento, manutenção do
produto ou serviço, determinando os procedimentos e recursos necessários para gerenciar
e garantir o projeto, até a entrega do software ou serviço.
• Processo de Desenvolvimento: define as atividades e tarefas do processo de
desenvolvimento do produto seguindo a seguinte sequência: análise de requisitos, projeto,
construção “codificação”, integração, testes, instalação e o recebimento do software ao
adquirente, sabendo que o propósito do desenvolvimento é a transformação de um
conjunto de requisitos pré-analisados em um produto de software, que satisfaça as
necessidades explícitas do cliente.
• Processo de Operação: define as atividades e tarefas para a operação do software e
suporte operacional aos usuários, para que possa utilizar o software produzido.
• Processo de Manutenção: é ativado quando há necessidade de modificações no código
fonte do sistema produzido, para que possa ser feito melhorias, correção de erros, ou
mesmo adaptação do software para que assim possa haver uma integridade do software
existente.

1.1.2 Processo de Apoio

Segundo Machado (2001), o processo de apoio é empregado e executado quando é
necessário para documentação, gerência de configuração, garantia da qualidade, processo de

21

verificação, processo de validação, revisão conjunta, auditoria e resolução de problemas. Com o
objetivo de auxiliar os outros processos, visando à qualidade e o sucesso do projeto, o processo
de apoio é constituído pelos seguintes itens:

• Processo de Documentação: tem a tarefa de registrar as informações dos processos e
atividades provenientes do ciclo de vida do projeto. Nesse processo, são planejados,
projetados, desenvolvidos, produzidos, editados e distribuídos os documentos necessários
a todos os interessados.
• Processo de Gerência de configuração: contém atividade administrativa, define itens
para o desenvolvimento do software apontando linhas básicas, controlando modificações
e liberações, registrando as codificações para total compreensão da consistência nas
correções dos itens modificados, garantindo seu funcionamento.
• Processo de Garantia da qualidade: com o principal intuito de promover a seus clientes
um importantíssimo produto, o alvo é o funcionamento com êxito do software, de acordo
com os requisitos, padrões e normas pré-estabelecidas e documentadas para o
desenvolvimento dos processos
• Processo de Verificação: tem o propósito de averiguar se o produto ou serviço de
software está de acordo com os requisitos previamente impostos.
• Processo de Validação: é a atividade que confirma se os serviços realizados atendem aos
requisitos proposto ao ciclo de vida do Software.
• Processo de Revisão conjunta: avalia a situação de uma atividade e dos produtos, para
manter um entendimento geral dos requisitos realizados, ou não, no nível de
gerenciamento técnico.
• Processo de Auditoria: tem o propósito de determinar a total validação entre as
comparações, entre os requisitos e o produto.
• Processo de Resolução de problemas: tem a finalidade de assegurar a solução de
problemas levantados, com uma análise adequada e documentada.
• Processo de Usabilidade: é voltado para a otimização do suporte e do treinamento, cujo
objetivo é garantir que sejam considerados os interesses e necessidades dos funcionários
e, principalmente, do usuário. Assim tendo uma grande possibilidade de aumento da

22

produtividade e da qualidade do trabalho, há uma aceitação do usuário do sistema
proporcionando ótimas condições de trabalho sem rejeição.

A norma de referência para os processos de ciclo de vida de software no MR mps é a
ISO/IEC 12207, conforme sua atualização publicada em 2002. Esta norma pode ajudar
as organizações na definição de seus processos, pois ela contém uma clara definição da
arquitetura, terminologia e responsabilidades inerentes a processos. Essa atualização
inseriu processos e acrescentou na sua descrição propósito e resultados de
implementação, o que possibilita a avaliação da capacidade do processo. (WEBER et al;
20--b)

1.1.3 Processos Organizacionais

São utilizados para auxiliar e gerenciar a organização, com o objetivo de melhorar
o ciclo de vida do software. As atividades contidas nos processos organizacionais visam a
melhoria da empresa, apresenta os processos de gerência, infra-estrutura e treinamento.

• Processo de Gerência: tem o propósito de definir as atividades para a área do
gerenciamento do projeto, produto, atividades dos processos, aquisição, fornecimento,
desenvolvimento, operação, manutenção e processos de apoio, objetivando ter um
controle e organização sobre o que está acontecendo do inicio ao fim do processo em
desenvolvimento.
• Processo de Infra-estrutura: é a atividade responsável em manter as necessidades de
infra-estrutura da organização em um nível que possa ser usado como hardware, software,
condições de trabalho, ferramentas especiais de desenvolvimento, suporte e implantação
de todos os setores da organização.
• Processo de Melhoria: é a atividade que estabelece melhoria no ciclo de vida do
software, com avaliações e medições, tendo controle sobre o produto desenvolvido.
• Processo de Recursos Humanos: segundo MACHADO (20--), o objetivo principal do
processo de recursos humanos é “garantir o melhor aproveitamento das pessoas
envolvidas no projeto, o que consiste em planejamento organizacional, alocação de
pessoal e desenvolvimento de equipe”.
• Processo de Treinamento: define as atividades de treinamento para os funcionários da
empresa que adquiriram o software, entre elas, melhorias e mudanças no sistema, o que
necessita de uma instrução sobre a forma de usar o produto.
• Processo de Gestão de ativos: utilizáveis desde de seu desenvolvimento até o desuso,
sendo introduzido em 2002.

23

Em 2002, foi feita uma atualização na norma ISO/IEC 12207 (ISO/IEC PDAM 12207,
2002) em forma de anexo que visava representar a evolução da engenharia de software,
as necessidades vivenciadas pelos usuários da norma e a harmonização com a série de
normas ISO/IEC 15504 – Avaliação de Processos de Software. (WEBER et al; 20--b)

• Processo de Gestão de programa de reuso: na gestão de reuso há um planejamento para
gerenciar, estabelecer, controlar e monitorar. Esse objetivo específico em uma
organização é sistematicamente explorar as oportunidades de reuso, não perdendo tempo
e, com certeza, aumentado os lucros.
• Processo de Engenharia de domínio: na engenharia de domínio são desenvolvidos e
mantidos os modelos, arquiteturas e ativos de domínio.

Weber (et al; 20--b; p6) afirma a atualização em 2002 de novos processos e
descreve como foram divididos nos processos fundamentais de apoio e organizacionais, como
acima citados, a baixo quadro que mostra a estrutura da ISO/IEC12207

Figura 2: Demonstra a estrutura da ISO/IEC 12207.
Fonte: < http://qualidade.wdfiles.com/local--files/mpsbr-qualidade-de-software/ISO12207.png>

24

1.2 ISO/IEC 15504

Uma evolução da ISO/IEC 12207, a ISO/IEC 15504, também conhecida como
SPICE, é uma norma de processos de desenvolvimento de software criado pela ISO e pela IEC,
tendo diferença em sua versão de origem, pois trabalha com níveis de capacidades equivalentes
ao CMMI. Essa norma teve uma versão aprovada em 1998 (ISO/IEC, 2003), sendo abastecida
pelas necessidades de requisitos de padrão internacional para avaliação de processos de software,
a qual foi publicada em 2003 pela ISO em união com a comunidade internacional, através do
projeto SPICE (Melhoria de Processo de software e determinação de Capacidade - Software
Process Improvement and Capability Determination). Tendo como estrutura as normas já
existentes, a ISO 9001 e o CMM, juntamente com a ISO/IEC 12207, descreve um conjunto de
processos considerados universais e fundamentais para que se possa ter um planejamento e
desenvolvimento com qualidade, com o propósito na melhoria de processos de criação de
software e serviços relacionados com execução de avaliações específicas na área determinada.
Sabendo assim quais partes da organização terão que ser feitas melhorias, e quais características
manter, é utilizado avaliações de capacidades. Segundo WEBER (et al; 20--b; p6) “a organização
pode realizar a avaliação, gerando um perfil dos processos que será usado para a elaboração de
um plano de melhorias”, das quais a empresa deve continuar sempre à procura, sem perder a
qualidade e o foco no cliente.

1.2.1Categoria

Os processos da norma SPICE são agrupados em cinco grandes categorias de processo:
cliente/fornecedor, engenharia, suporte e organização.

Cada uma das categorias de processo é detalhada em processos mais específicos, ou
subcategorias (Cliente-fornecedor, Engenharia, Projeto, Suporte e Organização). Este
modelo visa também avaliar a capacidade da organização em cada processo, permitindo
assim sua melhoria. Cada um dos processos deve ser classificado em níveis (incompleto,
executado, gerenciado, estabelecido, previsível e otimizado) (LAHOZ, SANT’ANNA).

25

De cada processo a ser usado, é analisada a situação do problema, e deste ponto
em diante, sabendo-se o que fazer para a melhoria de processo, é aplicado o processo especifico
para a solução do entrave.

A dimensão de processos do modelo de avaliação apresenta os processos relevantes
dentro de um determinado contexto. Ela é baseada em um subconjunto de processos os
quais são descritos em um modelo de referência de processo. O modelo de referência,
voltado para o setor de software, utilizado pela 15504, define um conjunto universal de
processos de software com base na norma ISO 12207 (ISO; 2002).

• Cliente/fornecedor: a dimensão do processo de Cliente fornecedor, segundo Bernardo e
Becerra (2005) “São processos que impactam diretamente os produtos e serviços de
software na entrega do fornecedor para o cliente”.
• Engenharia: na categoria Engenharia, são encontrados os processos que guiam a
implementação e manutenção do produto ou serviço de software, com sua documentação
formal dos requisitos necessários para a sequência do desenvolvimento.
• Projeto: tem como objetivo organizar, monitorar e controlar a execução de qualquer
processo na empresa.
• Suporte: é a atividade responsável em documentar e interagir com o usuário do sistema
de software produzido. Segundo Bernardo e Becerra (2005) “são processos que podem ser
empregados por quaisquer um dos outros processos, por tratarem da documentação,
configuração e revisões”.
• Organização: é a empresa que cria focos de empreendimentos para que possam ser
alcançados e superados.

26

1.2.2 Processos
Para cada categoria com processos específicos, existem seis níveis numerados de 0
a 5 para cada processo incompleto, executado, gerenciado, estabelecido, previsível e otimizado.

A segunda dimensão é a de capacidade do processo. Essa dimensão apresenta uma
estrutura de medição composta por seis níveis de capacidade, os quais definem uma
escala ordinal de capacidade que são aplicáveis a qualquer processo do modelo de
referência de processos. Cada nível de capacidade é composto por atributos de processo,
que definem um aspecto particular da capacidade do processo. Assim, a partir das
observações resultantes de uma avaliação, é atribuída uma das seguintes quatro notas a
cada atributo: N-não atingido, P-parcialmente atingido, L-largamente atingido ou F-
completamente atingido. Para estar em um nível de capacidade, um processo tem que ter
notas L ou F nos atributos do nível, e F em todos os atributos dos níveis anteriores
(ANACLETO, WANGENHEIM, SALVIANO, 2004)

Figura 3: Demonstra os níveis de processo do modelo SPICE, ISO 15504.
Fonte: < http://www.bcs.org/upload/img_400/cmmi_spice_fig1.gif>

A figura 3 retrata os níveis de processos pertencentes à norma ISO 15504,
demonstrando os graus de maturidade dos processos estabelecidos para as organizações que
venham a implementar o modelo. Segundo Lahoz e Sant’anna “este modelo visa também avaliar
a capacidade da organização em cada processo, permitindo assim sua melhoria, pois cada um dos
processos deve ser classificado em níveis (incompleto, executado, gerenciado, estabelecido,
previsível e otimizado)” conforme descrito a seguir.

27

1.2.2.1 Incompleto

Também conhecido como Inicial ou Não-Realizado, tem uma má performance
generalizada no desenvolvimento dos objetivos específicos das práticas bases do processo de
software, o qual, não encontra o produto final ou resultados vindos dos processos realizados.

1.2.2.2 Executado

Os processos são finalizados com um básico acompanhamento e sem muitos
cuidados, e depende muito do esforço individual. Existem, também, produtos de trabalho
finalizados com o uso identificáveis do processo, os quais em outras versões são nomeados de
Realizados ou Realizados Informalmente.

1.2.2.3 Gerenciado

Os processos são planejados e acompanhados. Já os procedimentos específicos são
averiguados, visando a qualidade, levando a organização a uma boa estimativa de direção, e um
processo de software com qualidade bem definido.

1.2.2.4 Estabelecido

Com o processo estabelecido, a organização busca práticas de acordo com os
processos definidos, usando versões de normas já trabalhadas com sucesso ganho, e trabalhando
com a mesma qualidade, as quais já estão documentadas, ajudando assim o entendimento para os
próximos projetos.

28

1.2.2.5 Previsível

Medido, previsível e controlado quantitativamente. Nesse nível, são realizadas
medidas detalhadas, onde as reais condições dos processos são recolhidas e analisadas para
levarem a uma compreensão quantitativa da capacidade do processo, e a uma melhor aptidão para
antecipar a realização. O processo definido é entendido e controlado quantitativamente.

1.2.2.6 Otimizado

Metas de eficiência são estabelecidas para a realização do processo. Tendo como
base os objetivos de negócios na empresa, é dado partida para o aperfeiçoamento contínuo dos
processos de desenvolvimento sobre estas metas, através do retorno quantitativo da realização do
processo definido, e também de tecnologias inovadoras, o que resultará em melhorias sempre de
alto nível.

1.3 CMM

O CMM-SW (Capability Maturity Model for Software - Modelo de Maturidade
de capacidade para Software) ou simplesmente conhecido por CMM, é uma norma de
certificação de qualidade utilizada para avaliação e melhorias na maturidade dos processos em
desenvolvimento de software e serviços correlacionados, com origem na década de 1980 nos
Estados Unidos. Segundo PESSÔA (2005) “O desenvolvimento desse modelo foi financiado pelo
departamento de defesa americano, com o objetivo de se estabelecer um padrão de qualidade para
software desenvolvido para as forças armadas”. Com este modelo de avaliação, seria capaz de
medir os processos de construção do software fabricado pelas as empresas que concorriam pela
licitação, tendo em vista a indicação pela qualidade, valor do produto e garantia de prazos de
entrega completa ou por módulos dos projetos contratados. Embora o modelo tenha sido gerado
para a composição de grandes corporações de desenvolvimento de software que iriam ser
contratadas para projetos militares, seus princípios são válidos para vários tipos de projetos de
softwares.

29

Figura 4: Logotipo do modelo CMM referenciando ao nível de maturidade dois.
Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf >

Embora, historicamente, o CMM tenha surgido no contexto de grandes empresas de
desenvolvimento de software contratadas pelas Forças Armadas dos EUA para
projetos militares, tem-se verificado que seus princípios são válidos para todo tipo
de projetos de software. Isto não é de se estranhar, já que o CMM nada mais é que a
aplicação dos princípios da Qualidade Total e do Gerenciamento de Projetos ao mundo
do software. Assim, o CMM tem sido usado com sucesso, na íntegra ou adaptado,
nos mais variados tipos de empresas grandes e pequenas, em várias áreas de atuação.
Entre as citadas por Belloquim (2006) estão Pequenas softwarehouses (10 a 20
desenvolvedores); Grandes Bancos e Seguradoras; Empresas de Telecomunicações;
Fabricantes de hardware com software embarcado (pagers, aviônicos, componentes
automobilísticos, telefones celulares); Empresas de consultoria em desenvolvimento
de sistemas (ALEXANDRINI et al; 2006).
.

Para a implantação do projeto CMM, as forças aéreas instituíram, para
desenvolvimento do projeto, o SEI (Software Engeneering Estitute) sediado na Carneggie Mellon
University na Pennsylvania, a qual até hoje é a responsável pela evolução do CMM. Atualmente
com a versão 1.2, evolução da anterior 1.1, o modelo de maturidade de capacidade CMM fornece
uma guia de como obter controle nas execuções de construções de softwares, que quando é
seguido, as suas práticas garantem a qualidade do produto, com o propósito principal de medir a
maturidade de uma área de desenvolvimento de software, e como evoluir em direção a uma
cultura de engenharia de software e excelência de gestão. Para isso é preciso analisar e
compreender a forma de trabalho, adaptando as características de empresa por empresa, uma vez
que cada uma tem formas diferentes de trabalho.

Os principais objetivos do CMM são auxiliar as empresas a conhecerem e melhorarem
seus processos de desenvolvimento e manutenção de software; Fornecer uma
estrutura conceitual para guiar as empresas para obterem controles de seus
processos, com melhoria continua de seus produtos de software (REZENDE, 2002,
p. 155).

Projetado para a garantia da melhor seleção das estratégias de melhorias, trabalha
focado em um número limitado de atividades e trabalhos a serem concluídos com êxito. Sendo

30

assim, a organização ganhará uma melhoria nos processos e em toda a sua estrutura, habilitando a
ganhos consecutivos e longos na capacidade do processo de software da empresa.

1.3.1 Níveis de Maturidade

Para o uso continuo e progressivo, o CMM fornece uma estrutura de cinco níveis
de maturidade, são eles: inicial, repetível, definido, gerenciado e otimização que fornecem
fundamentos sucessivos para a excelência do processo, dos quais os cinco níveis de maturidade
têm a finalidade de medir a atual situação da organização nos desenvolvimentos de seus projetos
e ajudar a priorizar o foco de seus esforços de melhoria. Segundo Gusmão e Moura (2004)
afirma que O SW-CMM foi o primeiro modelo desenvolvido na área de maturidade e capacidade,
o qual tem cinco níveis de maturidade onde o nível mais avançado corresponde a uma maior
maturidade do processo que está associado a uma maior produtividade e qualidade, e a um menor
risco organizacional, na área de desenvolvimento de software. A busca por processo maduro,
evolutivo em estágios, definido em fundamentos para a melhoria, e que cada nível de maturidade
fica responsável, compreende um conjunto de objetivos de processos há serem seguidos.

Figura 5: Demonstra os níveis de processo do modelo CMM.

Na Figura 5, há uma exibição de dois gráficos: um (à esquerda) são os caminhos
evolutivos que as organizações terão que passar para obterem um processo de implementação e
disciplina com excelência; o outro (à direita) demonstra que os riscos e desperdícios são maiores

31

nos níveis inferiores; e que a qualidade, produtividade e visibilidade são supremas no nível
Máximo, tendo variações de risco versos qualidade ao ganhar maturidade.

1.3.1.1 Inicial

É um processo comumente chamado de “ad hoc” ou, em algumas ocasiões
caóticos, depende do esforço individual para que o sucesso aconteça e poucos processos são
definidos. Em uma visão ampla, a organização não fornece um ambiente estável para a estrutura
do desenvolvimento e a manutenção do produto. Para a evolução do trabalho diário, a prática de
gestão sem rumo certo, muitas vezes prejudica o desenvolvimento das boas práticas pelo
planejamento ineficiente “encache” de novos projetos, tirando da ordem dos cronogramas dos
projetos os próximos processos a serem criados. Um gerente excepcional para o sucesso do
projeto e uma equipe de software madura e eficiente, é de quem depende inteiramente o
procedimento do projeto, porém ,mesmo com uma boa prática de desenvolvimento, não pode
superar a instabilidade criada pela ausência de práticas sólidas de gestão. Alteração constante no
projeto ‘ad hoc’ é geralmente imprevisível aos orçamentos, funcionalidades, cronogramas e
qualidades do produto, com um momento casual de estabilidade.
Grande parte das organizações que enquadram-se neste nível, o qual caracteriza-se
pelo desenvolvimento de software sendo visualizado como uma caixa preta, onde
apenas as entradas e saídas são vistas com clareza. O sucesso e a qualidade do
produto dependem de esforços individuais sem qualquer nível de gerenciamento ou
controle definido explicitamente (SANTANDER; VASCONCELOS; 20--).

1.3.1.2 Repetível

A estabilidade rege os procedimentos para a gestão de projeto do software. Os
projetos novos são analisados com experiência de projetos similares, anteriormente produzidos
com práticas bem sucedidas de desenvolvimento, com atuação de processos documentados,
medidos, testados e com condições de melhoramentos, com controle básico de gestão de
software, acompanhamento no cronograma, custos, funcionalidades e armazenando os requisitos,
produtos de trabalho que a integridade é rigidamente controlada. Os padrões do projeto são
caracterizados, validados, e a organização garante que o uso dos procedimentos será seguido
sempre. O nível dois de maturidade é conhecido como disciplinado, pelos seguintes motivos:

32

processos estáveis, reutilização de projetos com sucessos, utilização contínua de planejamento
realista, processos de Gerenciamento de requisitos, planejamento, monitoramento, controle de
projeto, gerenciamento de fornecedores, medição, análise, garantia da qualidade do processo, do
produto e da gerenciamento de configuração.

1.3.1.3 Definido

Os processos de desenvolvimento, a manutenção de software e a gestão de
processos da empresa, como um todo, são documentados. Os processos são utilizados para apoiar
os gerentes de software e a área técnica, através de programas de treinamentos que são
implantados para que os gerentes e funcionários tenham conhecimentos e controle nas funções,
resumidamente conhecida como padronizada e consistente, pois a engenharia de software e as
atividades de gestão são estáveis e repetíveis, que segundo Santander e Vasconcelos (20--), “é
caracterizado principalmente pela existência de um processo de engenharia de software bem
definido, documentado e padrão para a empresa. O processo de software é satisfatoriamente
entendido”. No nível definido, os produtos são produzidos, desenvolvidos, a qualidade é
acompanhada e o cronograma é cumprido, além das funcionalidades e custos. Seus processos
abrangem o desenvolvimento de requisitos, solução técnica, integração do produto, verificação e
validação, foco e definição no processo organizacional, treinamento organizacional,
gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução.

1.3.1.4 Gerenciado

Com o nível gerenciado, a organização cria metas de qualidade para os produtos
desenvolvidos e processos de software, onde acontece medição na produtividade e na qualidade
dos processos de todo o projeto. Os dados disponíveis dos processos são armazenados pra que
possam ser utilizados, coletados e analisados, reduzindo a variação no desempenho com controle
sobre seus produtos e processos. Nível de maturidade gerenciado, é conhecido como previsível,
pois os processos e operações são feitos sobre os limites mensuráveis, prevendo que a
organização tenha uma previsão de tendências de qualidade dos produtos e processos, não

33

ultrapassando limites. Caso aconteça, rapidamente são tomadas providências para corrigi-las,
mantendo assim um produto de software com alta qualidade.

1.3.1.5 Em Otimização

A organização é totalmente madura e entra em um círculo de melhoria contínua de
processo, os quais são fortalecidos de maneira proativa quando surgem oportunidades de
melhorias com objetivo de antecedência a falhas. Com os processos armazenados, são realizadas
análises de custo, benefícios de tecnologias novas e mudanças solicitadas para o projeto. As
novas práticas de engenharia são identificadas, armazenadas e repassadas para toda a
organização, onde os processos são revistos periodicamente para prevenir os tipos de falhas já
conhecidos que geralmente se repetem, e os erros são catalogados para que não aconteça em
outros projetos. O nível cinco de maturidade fica sendo conhecido como melhoria contínua, pois
está continuamente procurando a melhoria, expandido sua capacidade de processos juntamente
com o projeto. Avanços incrementais são adicionados aos processos com inovações que utilizam
novos métodos e tecnologias.

Na figura número 6, basicamente é exibida como a gerência presencia os
processos em cada nível de maturidade; no nível 1, o processo é uma caixa preta, o entendimento
do processo é caótico, onde acontecem inúmeras situações para que o projeto atrase e tenha
prejuízos; no nível 2, há controle sobre os requisitos e sobre o projeto; no nível 3, já é visível as
atividades dentro dos processos, onde os gerentes e os engenheiros compreendem suas tarefas; no
nível 4, os gerentes têm a possibilidade de medir quantitativamente os processos, facilitando as
decisões futuras; e no último nível 5, novas tecnologias são adicionadas aos processos,
substituindo as antigas, no intuito de melhorar a produtividade, tempo e qualidade com total
controle nas mudanças.

34

Figura 6: Ilustra os acontecimentos em cada nível do CMM.
Fonte: CQPD < http://www.gaea.com.br/pdf/CMM-TR24_.V1.2.pdf>

1.4 CMMI

Com a existência de vários CMM e com objetivo em desenvolvimento de software
sendo eles: Engenharia de Sistemas (SE-CMM); Aquisição de Software (SA-CMM) e Gestão de
Recursos Humanos de Empresas de Softwares (P-CMM) entre outros. Mesmo com a utilização
benéfica dos modelos, as excessivas diversificações trouxeram problemas, pois cada modelo
tinha que ser avaliado separadamente, gerando um aumentado custo de treinamento, ocasionando
o acontecimento de dificuldades de comunicação entre eles, já que cada modelo possui
características específicas.

35

Figura 7: Logotipo da norma CMMI.
Fonte: < http://www.pucrs.campus2.br/~jiani/es2/cmmi-logo.gif>.

CMMI ajuda a integrar tradicionalmente funções organizacionais separadas, definir
processo de melhoria, metas e prioridades, bem como fornecer orientações para
processos de qualidade, e proporcionar um ponto de referência para avaliar processos
atuais. Muitas organizações no mundo todo têm adotado este modelo com o objetivo de
possibilitar a elevação da maturidade da capacidade de suas equipes nas atividades
relacionadas ao software (Silva, Andrade, Pimentel,2008).

Para sanar esse entrave de diversidade de modelos e com o intuito de unificar, foi
criada uma integração das práticas em conflito, o SEI criou o CMMI, que é a evolução do CMM
(Capability Maturity Model Integration - Modelo de Maturidade da Capacitação Integrado).
segundo WEBER(20--b) “O CMMI surgiu para resolver o problema de se usar vários modelos e
é o resultado da evolução do SW-CMM, SECM (System Engineering Capability Model) e IPD-
CMM (Integrated Product Development Capability Maturity Model)”.
CMMI É um modelo de referência para desenvolvimento de processo de software,
e tem como objetivo eliminar suas inconsistências no projeto como um todo, fornecer uma prática
consistente com regras de construção como seus anteriores. O CMMI não define como o processo
deve ser desenvolvido, porém reúne características estruturais e como deve ser finalizado
processo. O CMMI, na atual versão 1.2, tem três modelos publicados: CMMI for
Development(CMMI-DEV), para processo de desenvolvimento de produtos e serviços; CMMI
for Acquisition (CMMI-ACQ), para a aquisição e terceirização de bens e serviços; e CMMI for
Services (CMMI-SVC), para processos de empresas prestadoras de serviços publicados na
sequência 2006, 2007 e 2009. O CMMI possui duas representações: a por estágios e Contínua.

36

Figura 8: Comparação das duas representações a de Maturidade e Contínua.
Fonte: (RINCON; 2009).

[...] para que uma organização possa evoluir de um nível para o outro no CMMI, ela
deve implementar um conjunto de processos pré-definidos. Para isso, ela deve cumprir o
que é descrito nas metas e práticas genéricas e nas metas e práticas específicas de cada
Área de processo. O documento oficial do modelo, o CMMI-DEV, traz detalhadamente
quais são as metas e práticas específicas de cada Área de Processo (RINCON,2009).

Estas duas formas de sequência fazem com que as organizações possam ter uma
escolha de qual caminho deve ser percorrido à procura da melhoria de seus processos, de acordo
com seus interesses. Segundo PESSÔA (2005) “para entender o significado do termo capacidade
pode se pensar na capacidade que alguém possui para realizar um trabalho: quanto maior a
capacidade do processo, melhor deve ser o resultado obtido”.

1.4.1 CMMI - Representação Por estágios

A organização busca uma avaliação por nível de maturidade com conjuntos
previamente definidos para que seja cumprido o KPAs (Key Process Areas - área chave de
processo), mesmo modelo adotado pelo CMM. Na representação por estágios possui níveis de
maturidade com conjunto de áreas de processo que caracterizam diferentes comportamentos
organizacionais, que é uma imagem para que a capacidade das organizações possa desenvolver
projetos complexos e grandes, dependendo dos níveis que tenha adquirido. Segundo MARÇAL
(2007) “a representação em estágios, por sua vez, organiza as áreas de processo em 5
níveis de maturidade para suportar e guiar a melhoria dos processos. As áreas de processos

37

podem ser agrupadas também em quatro categorias: Gerenciamento de Processos,
Gerenciamento de Projetos, Engenharia e Suporte” como descrito a seguir.

1.4.1.1 Inicial

Neste nível, os processos são caóticos, os padrões não são seguidos pela
organização, por estarem no nível mais baixo do CMMI. Isso não implica dizer que o produto
não seja bom, porém o êxito do projeto fica por conta de algumas pessoas que, por esforços,
conseguem entregar o software, às vezes sendo obrigadas a abandonarem o processo por motivo
de alguma crise, provocando, assim, atraso na entrega do software, aumentando excessivamente o
custo do que foi planejado. Como a organização geralmente não fornece um ambiente estável, os
processos a serem cumpridos, neste nível não são encontrados.

1.4.1.2 Gerenciado

Os projetos têm a garantia de que seus requisitos são gerenciados e os processos
planejados. Com o foco de gerenciamento básico, o nível dois traz uma análise nas tarefas que
estão sendo desenvolvidos. Assim, encontrados os requisitos que não são compatíveis com os que
foram planejados, são rapidamente corrigidos para não interferir no prazo de entrega. Caso o
problema não seja sanado, a organização tentará uma solução.

Figura 9: CMMI Representação por estágios.
Fonte: (RINCON, 2009).

38

1.4.1.3 Definido

A diferença em relação ao nível anterior, é que neste acontece uma padronização
nos processos, os quais são melhores caracterizados e entendidos, e assim sendo descritos os
procedimentos e métodos. As ferramentas são melhoradas e definidas com mais rigor, tendo o
foco na padronização do processo e nos requisitos de desenvolvimento. São eles: análise de
decisões, soluções técnicas, integração da equipe de trabalho, integração de produtos,
gerenciamento de projeto integrado, verificação, validação, treinamento organizacional, foco no
processo organizacional, definição do processo organizacional, gerenciamento de riscos,
gerenciamento integrado de suprimentos e ambiente organizacional para integração.

1.4.1.4 Gerenciado Quantitativamente

Os processos no nível quatro são gerenciados quantitativamente, onde acontece
um controle de processos utilizando métodos estatísticos e outras técnicas quantitativas. Sendo
fácil a identificação de qualidade e o desempenho de um processo, estes são armazenados em um
repositório para que possa ter um suporte para decisões futuras. Os requisitos de desenvolvimento
são: performance organizacional do processo e gerenciamento quantitativo de projetos.

Neste nível de maturidade são definidos objetivos quantitativos da qualidade e
performance dos processos, estes estão baseados nas necessidades dos clientes, usuários
finais do produto. A qualidade e a performance dos processos são analisadas com base
em dados estatísticos e são gerenciados conforme estes resultados por toda a extensão do
processo (JAGUARIBE; MARIANO; 20--).

1.4.1.5 Otimizado

No ultimo nível do processo de maturidade do CMMI, na representação por
estágios, os processos são continuamente melhorados com uma análise quantitativa das
alterações; e no desempenho, os processo desse nível são a inovação organizacional e análise de
causas e resoluções.

39

Neste nível de maturidade o foco é a melhoria contínua da performance do processo
através de melhorias incrementais e de inovações, objetivos quantitativos de
melhoria são estabelecidos e continuamente revisados para refletir as atualizações dos
objetivos do negócio. (JAGUARIBE; MARIANO; 20--)

1.4.2 CMMI - Representação Contínua

Em movimento contrário do processo por estágio, onde a organização tem um
caminho já traçado para chegar a um nível de maturidade, a representação contínua utiliza um
método que permite que a empresa escolha qual a área ou áreas de processos que irão utilizar
para que adquira melhoramentos nos processos selecionados para as validações. Utilizando níveis
de capacidade, a Representação Contínua apresenta seis níveis de capacitação com numeração
iniciada no número zero e finalizada no numero cinco. As áreas de processo são agrupadas por
categorias afins. É importante ressaltar que muitos aspectos são os mesmos da Representação por
Estágios.

Figura 10: Demonstra os níveis de processo do modelo CMM.

As áreas de processos são agrupadas em quatro categorias: Gerência de Processos,
Gerência de Projeto, Engenharia e Suporte. Analisando um pouco mais a fundo essas áreas,
temos o seguinte cenário: a categoria Gerência de Processos contém atividades relacionadas para
definir, planejar, implantar, monitorar, controlar, medir e melhorar processos; a Gerência de

40

Projeto contém atividades de planejar, monitorar e controlar o projeto; a Engenharia refere-se às
várias engenharias; e o Suporte fornece suporte ao desenvolvimento e à manutenção de produtos.
Segundo MANERA (et al ;2007) “na representação contínua, o enfoque ou
componentes principais são as áreas de processo, pois existem metas e práticas de dois tipos:
específicas a uma determinada área de processo e genéricas aplicáveis indistintamente a todas as
áreas de processo”, e são classificadas na ordem a seguir.

1.4.2.1 “0” Incompleto

O nível incompleto se refere a não finalização de um processo, ou quando um ou
mais objetivos específicos do processo não são convincentes e satisfatórios, quando avaliado pela
organização.

1.4.2.2 “1” Realizado

Com a área escolhida pela organização, os objetivos específicos de cada processo
são finalizados com eficácia. Segundo MANERA (et al ;2007) “um processo realizado satisfaz
todos os objetivos específicos da área de processo e produz algum trabalho”.

1.4.2.3 “2” Gerenciado

Herdando a característica do nível anterior, contendo processos realizados com
planejamentos gerenciados, os processos são monitorados, revisados e controlados, assim como
os produtos de software e serviços, por pessoas com habilidades adequadas para produzirem o
que cada processo pede.

41

1.4.2.4 “3” Definido

Tendo os processos da organização padronizados, serão progressivamente
melhorados com mais rigor nas descrições dos processos provindos do nível dois.

1.4.2.5 “4” Gerenciado quantitativamente

Com utilização de técnicas quantitativas e estatísticas, os processos são
controlados e a qualidade é entendida por estatísticas sempre que melhorada. Algumas atividades
que se encontram nesse nível é a identificação de sub-processos que podem ser controladas por
normas estatísticas; e a identificação das causas de alterações de desempenho.

1.4.2.6 “5” Otimizado

O processo otimizado é a visão objetiva em melhoramentos contínuos e
desempenho, com a utilização de melhorias tecnológicas incrementais de inovação, visando as
várias modificações, de maneira a estabilizar as variações e a obtenção de melhoria de processos,
em busca de um funcionamento próximo da perfeição.

42

2 MPS.BR

Neste capítulo será feita uma explanação sobre o programa de melhoria de
processos do software brasileiro (MPS.BR), apresentando informações básicas sobre os
componentes de método de avaliação (MA-MPS), os modelos de negócios (MN-MPS), o modelo
de Referência (MR-MPS) e todos seus níveis de maturidade, aprofundando os subsídios para os
níveis de maturidade G e F, como previsto na delimitação do tema desta monografia, apresentado
as vantagens estabelecidas para as organizações e a certificação brasileira de melhoria processo
de software.

2.1 Conceito MPSBR

O modelo MPS.BR, Melhoria de Processo do Software Brasileiro, é um programa
que tem como objetivo a melhoria de processo de software, direcionando a organização, a
qualidade e a produtividade dos produtos desenvolvidos e serviços relacionados. Segundo
WEBER (20--b, P3) “O Projeto MPS.Br visa a melhoria de processos de software em empresas
brasileiras a um custo acessível, especialmente na grande massa de micro, pequenas e médias
empresas”, sendo utilizado, também, para empresas públicas e privadas, no entanto com padrão e
qualidade das normas de desenvolvimento internacional, como CMMI desenvolvido pelo SEI,
baseado no modelo ISO/IEC 12207 e ISO/IEC 15504. Referente à composição do modelo de
melhoria de processo, o projeto MPSBR é constituído por três componentes: Modelo de
Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS).

[...] desenvolvimento e aprimoramento do Modelo MPS, compatível com o
CMMI e em conformidade com as normas ISO/IEC 12207 e ISO/IEC 15504; e a
implementação e avaliação do Modelo MPS, a um custo acessível em todas as
regiões do país, com foco em grupos de pequenas e médias empresas (PMEs)
(WEBER, 20--a).

43

Figura 11: Logotipo do modelo MPS.BR
Fonte: < http://www.swprocess.com.br/uploadImagens/Logo_MPS.BR.JPG>

As duas metas que compreendem o projeto MPS.BR, segundo publicou WEBER
(20--a) é justamente o desenvolvimento e aprimoramento do Modelo MPS com total
compatibilidade com o CMMI e as ISO/IEC 12207 e ISO/IEC 15504, como segunda meta a
implementação e avaliação do modelo brasileiro, a um custo acessível em todo o país, com foco
nas pequenas e médias empresas.

Figura 12: Estrutura do projeto MPS.BR
Fonte: ULBRA < http://www.garcia.pro.br/Qualidade/Qualidade%20de%20Software %20-
%20Aula%207%20-%20MPS-BR.pdf>

A figura 12 demonstra a estrutura do projeto MPS.BR, as suas bases de
sustentação nas normas internacionais da ISO/IEC 12207, da ISO/IEC 15504, e do CMMI, esta é
a mais utilizada em relação à melhoria de processos de software. Já os demais componentes que
formam o conjunto do projeto tem as seguinte funções: o guia geral contém informações que
objetivam o modelo de Referência (MR-MPS), seus níveis e etc; o guia de aquisição descreve os
processos de aquisição de software e serviços correlatos; no guia de avaliação, é apresentado o
método de avaliação (MA-MPS), contendo principalmente os passos necessários para o

44

entendimento dos processos avaliativos; e no documento de programa contém informações sobre
o modelo de negócio (MN-MPS).

Cada componente é descrito em documentos ou guias. Segundo SILVA (20--) “o
projeto tem como objetivo promover a qualificação de um grupo amplo de empresas compatível
com os padrões de qualidade aceitos internacionalmente. Este projeto está sendo desenvolvido
desde dezembro de 2003” o qual foi criado no Brasil para a solução do melhoramento do
processo de software, objetivando ajudar em número expressivo as micros, pequenas e médias
empresas.

Estudos sobre a qualidade de software brasileiro realizados pela SOFTEX mostram a
necessidade de um esforço significativo das empresas e governos, no sentido de
aumentar a maturidade dos processos de software. A partir dessa necessidade, surgiu o
projeto MPS.BR - melhoria de processo do software.(PRIKLADNICKI, BECKER,
YAMAGUTI, 2005, p 39).

Figura 13: Logotipo da Coordenadora do projeto MPS.BR
Fonte: < http://www.estrategia.eti.br/images/logo_softex.jpg >

O comitê gestor do projeto MPS.BR é formado pela Associação para Promoção da
Excelência do Software Brasileiro (SOFTEX) que a é a Coordenadora, pela COPPE/UFRJ
(coordenadora da ETM - Equipe Técnica do Modelo); pela RIOSOFT no Rio de Janeiro/RJ; pela
CenPRA em Campinas/SP; pelo CESAR em Recife/PE e pela CELEPAR em Curitiba/PR. Esse
comitê recebe apoio financeiro do Ministério da Ciência e Tecnologia (MCT), através de recursos
do Fundo Nacional de Desenvolvimento Científico e Tecnológico (FNDCT), Financiadora de
Estudos e Projetos (FINEP); do Fundo Nacional de Desenvolvimento Científico e Tecnológico
(FNDCT) com fundo do VERDE-AMARELO; do Banco Interamericano de Desenvolvimento
(BID) e do suporte do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) .

45

O Projeto MPs.Br é uma iniciativa envolvendo universidades (Universidade Católica de
Brasília – UCB e Coppe/UFRJ), grupos de pesquisa (Coppe/UFRJ, Cesar, CenPRA) e
empresas (Celepar, Riosoft e Núcleo Softex Campinas), sob a coordenação da SOFTEX
(Sociedade para Promoção da Excelência do Software Brasileiro (Silva, 20--).

Quadro 1: Visão da formação do projeto MPSBR
Fonte: Weber (WEBER, 20--b).

2.2 Modelo de Referência (MR-MPS)

No modelo de referência, é o componente do programa brasileiro que fica com a
responsabilidade, Segundo a SOFTEX (2009a), coordenadora do projeto MSPBR disponibiliza
que: “O Modelo de Referência MR-MPS contém os requisitos que os processos das unidades
organizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém as
definições dos níveis de maturidade, processos e atributos do processo” com seus requisitos em
total conformidade com as normas internacionais ISO/IEC 12207, ISO/IEC 15504 e o CMMI.
Segundo Weber (20--c) “O MR-MPS é definido através de sete níveis de maturidade seqüenciais
e acumulativos. Cada nível de maturidade é uma junção entre processos e capacidade dos
processos, ou seja, é composto por um conjunto de processos em um determinado nível de
capacidade”. Tais níveis são nomeados por letras que representam o estado de maturidade que
possa atuar em uma organização. São elas de “A” até “G”, montado, assim, o perfil de processo
da empresa que indica onde estão os erros para que possam ser sanados, colocando o esforço na
melhoria do processo.

46

Os níveis de maturidade são definidos pelo MR-MPS, que são uma combinação entre
processos e sua capacidade. A evolução de processos, que caracterizam estágios de
melhoria da implementação de processos na organização, estabelecem os níveis de
maturidade. O desempenho futuro de uma organização, ao executar um ou mais
processos, pode ser previsto através do seu nível de maturidade (Silva, 2009).

Figura 14: Descrição dos níveis de maturidade do (MR-MPS.BR) com seus processos.
Fonte: SOFTEX < http://api.ning.com/files/x2oO-xyZI57WUT8fq2NZoRlmGFJ-
NNKXmkSe7OsLi2E9Ji1tryAd3YcySP9pHhtMwywGwAt3xpw*NkTf*NJnYI4oa7zDqPMJ/niveis2009.png>

A figura 14 mostra Os níveis de maturidade do modelo de referência, os quais são
nomeados e lidos em ordem inversa, iniciando na letra “G” e finalizando em “A”. Tais níveis são
os seguintes: Parcialmente Gerenciado, Gerenciado, Parcialmente Definido, Largamente
Definido, Definido, Gerenciado Quantitativamente e o grau de maturidade mais elevado. Em
Otimização, cada nível tem seus processos receptivos. Segundo a SOFTEX (2b009a) “O MR-
MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C
(Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G
(Parcialmente Gerenciado)”.

47

A organização para atingir o nível E deve executar os processos do nível G e F, e mais
os processos: Gerência de Projetos – Evolução, Gerência de Reutilização, Gerência de
Recursos Humanos, Definição do Processo Organizacional e Avaliação, Melhoria do
Processo Organizacional. No nível D, os processos dos níveis G, F e E são executados e
mais os processos: Verificação, Validação, Integração do Produto, Projeto e Construção
do Produto, e Desenvolvimento de Requisitos. Para alcançar o nível C de maturidade, a
organização deve executar os processos dos níveis G, F, E e D, e mais os processos:
Gerência de Riscos, Análise de Decisão e Resolução, Desenvolvimento para
Reutilização e Gerência de Reutilização – Evolução. No nível B, os processos dos níveis
G, F, E, D e C devem ser executados e mais o processo: Gerência de Projetos –
Evolução. Por fim, para alcançar o nível A, os níveis G, F, E, D, C e B devem ser
executados e mais o processo: Análise de Causas de Problemas e Resolução. Portanto,
os níveis de maturidade no MR-MPS são acumulativos (Silva, 2009)

Nos níveis de maturidades que compõem o Modelo de Referência (MR-MPS), o G
e F serão mais detalhados, porém as atividades pertencentes ao nível G são dois processos:
Gerência de Projetos e Gerência de Requisitos. no nível F, onde os processos são acumulativos,
vindos do nível inferior, os processos do nível Gerenciado são: Medição, Garantia da Qualidade,
Gerência de Portfólio de Projetos, Gerência da Configuração e Aquisição

2.2.1 G - Parcialmente Gerenciado

Nos níveis de maturidade do modelo relacional, o nível G é o primeiro a implantar
as melhorias dos processos de software em uma organização. Por este motivo, deve ter cautela
para a capacidade da empresa, na Gerência de projetos, mesmo sendo parcialmente, e na gerência
de requisito, que são os dois processos que compõem o nível G. Dois pontos são crucias na forma
de trabalhar da organização: mudar a cultura da organização para a melhoria de processo, e a
definição de projeto para a organização

No nível G, o projeto pode usar os seus próprios padrões e procedimentos, não sendo
necessário que se tenha padrões em nível organizacional. Se, porventura a organização
possuir processos já definidos e os projetos necessitarem adaptar os processos existentes,
esse fato deverá ser declarado durante o planejamento do projeto. Essas adaptações
podem incluir alteração em processos, atividades, ferramentas, técnicas, procedimentos,
padrões, medidas, dentre outras. (SOFTEX, 2009d, pag. 6)

48

Para que uma empresa adapte sua forma de desenvolver software, que é evolução
de produtos para tornarem em orientação projetos, terá de redefinir algumas operações, como o
próprio projeto e seu escopo, foco especifico no objetivo e no prazo de desenvolvimento.

2.2.1.1 Gerência de Projetos

Segundo o guia específico do nível de maturidade G da SOFTEX (2009d) “O
propósito do processo de Gerência de Projetos é estabelecer e manter planos que definam 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”. Ao crescimento dos níveis de maturidades, muitos
resultados são incorporados e outros sofrem evoluções. O nível G envolve, ainda, algumas
atividades, tendo que desenvolver um plano geral de controle do projeto e obter garantia na
manutenção do projeto até sua execução e conhecimento sobre o projeto, para quando for
necessário tomar providencias nas ações de correção sem desviar o planejamento nem o
cronograma. De acordo com o guia de implementação, a parte 1 que é a Fundamentação para
Implementação do Nível G do MR-MPS (SOFTEX, 2009d), detalha os resultados esperados
semelhante a quadro 2 abaixo.

Resultados Gerência de Projetos (GPR)
Esperados
GPR1 O escopo do projeto é definido, determinando o que está e o que não está incluído, limitando as
restrições e os produtos que serão entregues.
GPR2 As tarefas e Produtos são dimensionados, resultado de estimativa de tamanho, a dimensão das
funcionalidades são contadas, classes, objetos, relatórios, telas, consultas a banco de dados,
transações, atores dos casos de uso e linhas de código etc. uma das técnicas mais utilizadas é a
Ponto de Função
GPR3 As fases do ciclo de vida do projeto são definidas, que podem ser modelos sequenciais, cascatas ou
modelos incrementais e modelos evolutivos das fases, importante desenvolvimento de fases
posteriores.
GPR4 O esforço e o custo para a execução do projeto são estimados com base em dados históricos onde
são recuperadas informações de tempo e complexidade, para equilibrar a comparação de riscos e
mudanças que vão ser feitas, incluído viagens, nível de competência dos colaboradores e equipes de
projeto.
GPR5 O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são
estabelecidos e mantidos, dependência entre tarefas são estipuladas, gargalos são resolvidos e o
cronograma das atividades com início, duração e término é estabelecido.
Quadro 2: Descrição dos resultados esperados para o processo Gerência de Projetos (Continuação)
Fonte: SOFTEX(SOFTEX, 2009d).

49

(Continuação)
GPR6 Os riscos do projeto são identificados e o seu impacto, é documentado, os riscos são analisados e
priorizados, é interessante elaborar uma lista de riscos mais comuns para que possa facilitar a analise
da gerencia do projeto.
GPR7 Os recursos humanos para o projeto são planejados considerando o conhecimento, habilidades e
experiências possuídas e nas competências requeridas para desempenhar as tarefas no projeto, casos
pessoas sejam alocada ao projeto sem preparo necessárias pode ser um risco, porem pode ser feito
treinamentos para minimizar os riscos até sua extinção.
GPR8 Os recursos e o ambiente de trabalho necessário para executar o projeto são planejados os recursos
são geralmente equipamentos, ferramentas, serviços, componentes, viagens e requisitos de processo.
GPR9 Os dados do projeto são identificados e planejados quanto à forma de coleta, armazenamento e
distribuição, pode ser documentação exigidas para sua execução: relatórios, dados informais, estudos
e análises, atas de reuniões, documentação, lições aprendidas, artefatos gerados, itens de ação e etc.
GPR10 Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos,
prevendo, a criação do cronograma de atividades, o planejamento de RH, custos, riscos, dados etc.
Reunião destes documentos é entendida como sendo o Plano de Projeto.
GPR11 A viabilidade do projeto, considerando as restrições e os recursos disponíveis, é avaliada, se
necessário, ajustes são realizados, muitas vezes é preferível não iniciar ou parar um projeto já
iniciado do que prosseguir com um projeto inviável, uma avaliação preliminar é conduzida para
resultados requeridos, recursos financeiros, técnicos e humanos, restrições pelo cliente, as mudanças
de requisitos, eventos que levar à necessidade de reavaliar a viabilidade do projeto.
GPR12 O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido, é
importante revisar o planejamento para conciliar as diferenças existentes entre os recursos estimados
e disponíveis, negociações devem ser realizadas quando existirem conflitos entre as diversas
variáveis do projeto, como requisitos, custos e prazos, (ligação ao GPR11).
GPR13 O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os
resultados são documentados, o cronograma e o desperdício de esforços são examinados,
acompanhamento pode ser feito por meio de reuniões e comunicação pessoal, contudo, é importante
ressaltar que devem existir registros desses acompanhamentos.
GPR14 O envolvimento das partes interessadas no projeto é gerenciado informando em que fases eles são
importantes e como eles serão envolvidos, uma vez identificados e planejado o envolvimento, este
deverá ser seguido.
GPR15 Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento, não
confundir com GPR13 que é o acompanhamento diário, e neste resultado é importante porque as
revisões em marcos são oportunidades para verificar, de forma ampla, o andamento de todo o projeto.
GPR16 Registros de problemas identificados, incluindo dependências críticas, são estabelecidos e tratados
com as partes interessadas, para completar o trabalho de monitoramento do projeto, os problemas
precisam ser corrigidos e gerenciados até a sua resolução, com base em planos de ações,
estabelecidos especificamente para resolver os problemas levantados e registrados.
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, falhas nos
resultados 13, 15 e 16 são feitas ações corretivas devem ser estabelecidas para resolver problemas
que possam impedir o projeto de atingir seus objetivos, as ações corretivas devem ser gerenciadas até
serem concluídas

Quadro 2: Descrição dos resultados esperados para o processo de Gerência de Projetos
Fonte: SOFTEX(SOFTEX, 2009d).

Melhoria do Processo de Software Brasileiro no Nível F

Melhoria do Processo de Software Brasileiro no Nível F

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Similar a Melhoria do Processo de Software Brasileiro no Nível F

Similar a Melhoria do Processo de Software Brasileiro no Nível F (20)

Melhoria do Processo de Software Brasileiro no Nível F