SlideShare uma empresa Scribd logo
1 de 119
Baixar para ler offline
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



                    ADSON WENDEL CIRILO FERREIRA




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




                                           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



              ADSON WENDEL CIRILO FERREIRA




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




                                    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.
          Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf >

              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.
            Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf >

               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).
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE

Mais conteúdo relacionado

Mais procurados

MPS.BR Lições Aprendidas
MPS.BR Lições AprendidasMPS.BR Lições Aprendidas
MPS.BR Lições AprendidasGorio Eduardo
 
MPS.BR - Melhoria de Processo de Software Brasileiro
MPS.BR - Melhoria de Processo de Software BrasileiroMPS.BR - Melhoria de Processo de Software Brasileiro
MPS.BR - Melhoria de Processo de Software BrasileiroMERKADO DELIVERY
 
56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos
56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos
56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetosVinícius Vieira
 
12082011 tcc senac_sayuri
12082011 tcc senac_sayuri12082011 tcc senac_sayuri
12082011 tcc senac_sayuriSayurï Yamane
 
Novas Oportunidades - Francisco Lima - IST
Novas Oportunidades - Francisco Lima - ISTNovas Oportunidades - Francisco Lima - IST
Novas Oportunidades - Francisco Lima - ISTctome
 
Slide sobre o estudo do MPS.BR
Slide sobre o estudo do MPS.BRSlide sobre o estudo do MPS.BR
Slide sobre o estudo do MPS.BRlaisgrazielly
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiroingrid_fatec
 
12082011 tcc senac_sayuri
12082011 tcc senac_sayuri12082011 tcc senac_sayuri
12082011 tcc senac_sayuriSayurï Yamane
 
MPS.BR - Melhoria do processo de Software Brasileiro
MPS.BR - Melhoria do processo de Software BrasileiroMPS.BR - Melhoria do processo de Software Brasileiro
MPS.BR - Melhoria do processo de Software BrasileiroPaulo Henrique de Sousa
 
Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...
Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...
Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...Marco Coghi
 

Mais procurados (19)

MPS.BR Lições Aprendidas
MPS.BR Lições AprendidasMPS.BR Lições Aprendidas
MPS.BR Lições Aprendidas
 
MPS.BR - Melhoria de Processo de Software Brasileiro
MPS.BR - Melhoria de Processo de Software BrasileiroMPS.BR - Melhoria de Processo de Software Brasileiro
MPS.BR - Melhoria de Processo de Software Brasileiro
 
Comunidades de Prática
Comunidades de PráticaComunidades de Prática
Comunidades de Prática
 
Spin72
Spin72Spin72
Spin72
 
MPS.BR
MPS.BRMPS.BR
MPS.BR
 
PIM - Manual Geral
PIM - Manual GeralPIM - Manual Geral
PIM - Manual Geral
 
MPS.BR
MPS.BRMPS.BR
MPS.BR
 
Mps.br
Mps.brMps.br
Mps.br
 
Cronograma de palestras
Cronograma de palestras Cronograma de palestras
Cronograma de palestras
 
56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos
56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos
56600840 avaliacao-da-maturidade-em-gerenciamento-de-projetos
 
12082011 tcc senac_sayuri
12082011 tcc senac_sayuri12082011 tcc senac_sayuri
12082011 tcc senac_sayuri
 
Novas Oportunidades - Francisco Lima - IST
Novas Oportunidades - Francisco Lima - ISTNovas Oportunidades - Francisco Lima - IST
Novas Oportunidades - Francisco Lima - IST
 
Slide sobre o estudo do MPS.BR
Slide sobre o estudo do MPS.BRSlide sobre o estudo do MPS.BR
Slide sobre o estudo do MPS.BR
 
Melhoria de processos do software brasileiro
Melhoria de processos do software brasileiroMelhoria de processos do software brasileiro
Melhoria de processos do software brasileiro
 
12082011 tcc senac_sayuri
12082011 tcc senac_sayuri12082011 tcc senac_sayuri
12082011 tcc senac_sayuri
 
Artigo jad utfpr
Artigo jad utfprArtigo jad utfpr
Artigo jad utfpr
 
MPS.BR - Melhoria do processo de Software Brasileiro
MPS.BR - Melhoria do processo de Software BrasileiroMPS.BR - Melhoria do processo de Software Brasileiro
MPS.BR - Melhoria do processo de Software Brasileiro
 
Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...
Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...
Maceio ge19-gestão de projetos-implantação da manutenção autônoma (ma) nas ár...
 
Dissertacao rev Becker
Dissertacao rev BeckerDissertacao rev Becker
Dissertacao rev Becker
 

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

TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...Felipe Nascimento
 
Carta de Apresentação
Carta de ApresentaçãoCarta de Apresentação
Carta de Apresentaçãosapaixao
 
Apresentação Fabrica de Software - Senac MS
Apresentação Fabrica de Software - Senac MSApresentação Fabrica de Software - Senac MS
Apresentação Fabrica de Software - Senac MSSamuel Cavalcante
 
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...Felipe Pontes
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...Adson Wendel
 
Fases do desenvolvimento de software baseado no código de ética.
Fases do desenvolvimento de software baseado no código de ética.Fases do desenvolvimento de software baseado no código de ética.
Fases do desenvolvimento de software baseado no código de ética.Ronildo Oliveira
 
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008Claudio Cardozo
 
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...Edwagney Luz
 
Qualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa Certificada
Qualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa CertificadaQualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa Certificada
Qualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa CertificadaVinicius_Nunes
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLAnnkatlover
 
Estagio modelo relatorio
Estagio modelo relatorioEstagio modelo relatorio
Estagio modelo relatoriorenannmaia13
 
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC. ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC. Maurício Mau
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...Rogério Batista
 
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana BenedettProjeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana BenedettAnderson Nascimento
 
3 - Modelos de Processo de Software - Prof.ª Cristiane Fidelix
3 - Modelos de  Processo de Software - Prof.ª Cristiane Fidelix3 - Modelos de  Processo de Software - Prof.ª Cristiane Fidelix
3 - Modelos de Processo de Software - Prof.ª Cristiane FidelixCris Fidelix
 
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...Juliano Oliveira
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerAlan Carlos
 

Semelhante a PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE (20)

TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
 
Carta de Apresentação
Carta de ApresentaçãoCarta de Apresentação
Carta de Apresentação
 
Monografia - André Luiz Jamarino Abekawa
Monografia - André Luiz Jamarino AbekawaMonografia - André Luiz Jamarino Abekawa
Monografia - André Luiz Jamarino Abekawa
 
Apresentação Fabrica de Software - Senac MS
Apresentação Fabrica de Software - Senac MSApresentação Fabrica de Software - Senac MS
Apresentação Fabrica de Software - Senac MS
 
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
 
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O  MODELO DE QUALIDADE MPS.BR NOS N...
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O MODELO DE QUALIDADE MPS.BR NOS N...
 
Fases do desenvolvimento de software baseado no código de ética.
Fases do desenvolvimento de software baseado no código de ética.Fases do desenvolvimento de software baseado no código de ética.
Fases do desenvolvimento de software baseado no código de ética.
 
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008Trabalho Fábrica de Softwares baseado em ISO 9001:2008
Trabalho Fábrica de Softwares baseado em ISO 9001:2008
 
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...
MODELO DE ESTIMATIVA DA QUALIDADE EM PROJETO DE SOFTWARE BASEADO NA PREDIÇÃO ...
 
Qualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa Certificada
Qualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa CertificadaQualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa Certificada
Qualidade de Software e normas ISO 15504, 12207, MPS.BR e Empresa Certificada
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SL
 
Estagio modelo relatorio
Estagio modelo relatorioEstagio modelo relatorio
Estagio modelo relatorio
 
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC. ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
 
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana BenedettProjeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
 
3 - Modelos de Processo de Software - Prof.ª Cristiane Fidelix
3 - Modelos de  Processo de Software - Prof.ª Cristiane Fidelix3 - Modelos de  Processo de Software - Prof.ª Cristiane Fidelix
3 - Modelos de Processo de Software - Prof.ª Cristiane Fidelix
 
Cmmi traduzido em_portugues
Cmmi traduzido em_portuguesCmmi traduzido em_portugues
Cmmi traduzido em_portugues
 
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
 
Monografia-Devops
Monografia-DevopsMonografia-Devops
Monografia-Devops
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test Manager
 

Último

Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx2m Assessoria
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASMarcio Venturelli
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx2m Assessoria
 
Apostila e caderno de exercicios de WORD
Apostila e caderno de exercicios de  WORDApostila e caderno de exercicios de  WORD
Apostila e caderno de exercicios de WORDRONDINELLYRAMOS1
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx2m Assessoria
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfRodolpho Concurde
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
 

Último (11)

Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
Apostila e caderno de exercicios de WORD
Apostila e caderno de exercicios de  WORDApostila e caderno de exercicios de  WORD
Apostila e caderno de exercicios de WORD
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
 

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

  • 1. 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
  • 2. 1 ADSON WENDEL CIRILO FERREIRA MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE 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
  • 3. 2 ADSON WENDEL CIRILO FERREIRA MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE 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
  • 4. 3 A minha mãe, Nailda, por ser a pessoa mais importante na minha vida.
  • 5. 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.
  • 6. 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)”
  • 7. 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.
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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.
  • 16. 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.
  • 17. 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
  • 18. 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.
  • 19. 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>
  • 20. 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.
  • 21. 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
  • 22. 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
  • 23. 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.
  • 24. 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>
  • 25. 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).
  • 26. 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.
  • 27. 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.
  • 28. 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.
  • 29. 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.
  • 30. 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
  • 31. 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. Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf > 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
  • 32. 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:
  • 33. 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
  • 34. 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.
  • 35. 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.
  • 36. 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.
  • 37. 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
  • 38. 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).
  • 39. 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.
  • 40. 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. Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf > 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
  • 41. 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.
  • 42. 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.
  • 43. 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).
  • 44. 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
  • 45. 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) .
  • 46. 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.
  • 47. 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)”.
  • 48. 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)
  • 49. 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).
  • 50. 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).