• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 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

on

  • 2,650 views

PDF da Monografia apresentada por Adson Wendel (Adson_wendel@hotmail.com), como requisito final à obtenção do grau de bacharelado do Curso de Análise de Sistemas, no do Centro Universitário - ...

PDF da Monografia apresentada por Adson Wendel (Adson_wendel@hotmail.com), como requisito final à obtenção do grau de bacharelado do Curso de Análise de Sistemas, no do Centro Universitário - CESMAC - Maceió

Statistics

Views

Total Views
2,650
Views on SlideShare
2,650
Embed Views
0

Actions

Likes
0
Downloads
74
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

     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 Document Transcript

    • 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 UMAEMPRESA 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 - CESMACOrientador: 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 UMAEMPRESA 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
    • 3A 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 eeducação; A toda minha família, pela confiança e apoio moral; Ao meu orientador prof. Mozart, pelo imenso ensino e compartilhamento à realização destetrabalho; Ao meu amigo James, pela base criada, para que eu pudesse ingressar no ramo profissionalda informática; Ao meu tio Aroldo, por ter me mostrado a necessidade e realidade de fazer um cursosuperior; 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 ClaudioChaves, pelo companheirismo e amizade; Ao Sandney, gerente de medição; e ao Jonas, gerência da qualidade, os quais me cederamas 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 apeleja não é vossa, mas de Deus. (II Crônicas 20.15)”
    • 6 RESUMO Esta monografia tem como objetivo apresentar a possibilidade tangível dasempresas de software de Alagoas em busca de um patamar de qualidade, planejamento e controlepara então ficarem em um nível de organização reconhecido internacionalmente, e seu produtoaceito no mercado com aprovação, utilizando o projeto Melhoria de Processo do SoftwareBrasileiro mais conhecido pelas suas siglas MPSBR, o qual avalia a qualidade e a produtividadedo software e serviços relacionados com padrões e características semelhantes às normas dedesenvolvimento internacional, como: CMMI, baseado no ISO/IEC 12207; e ISO/IEC 15504; asquais são explanadas suas definições e estruturas. O projeto brasileiro é direcionados a realcondiçã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 adependência do modelo CMMI, o qual utiliza valor de aquisição alta e complexa naimplementação, e como foi aplicado e certificado na empresa de software alagoana KMF Análisee 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 doEstado 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 softwarecompanies from Alagoas to reach a baseline of quality, planning, management and being in alevel of organization accepted internationally and the product accepted in the market withapproval, 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 standardand features similar as the standards of software development as, CMMI based on ISO/IEC12207 and ISO/IEC 15504 that are explained, the definition and structure , the Brazilian project isdirected to the real condition of the Brazilian market, so companies from different sizes, publicand private, with more attention on micro, small and medium companies, that way removingmainly the dependency of the model CMMI that has higher cost and more installation complexityand as it was applied and certified in the alagoana software company KMF Análise eDesenvolvimento de Sistemas e Websites, on the maturity level F in the Modelo de Referência, ina cooperative contract, with three other companies, that were the first in the State to acquire thisfirst-time accomplishment, of approval on MPSBR in level F.Key-words: MPSBR. CMMI. ISO/IEC 12207. ISO/IEC 15504. Maturity
    • 8 LISTA DE FIGURASFigura 1: Logotipo da ISO e da IEC ............................................................................................ 17Figura 2: Demonstra a estrutura da ISO/IEC 12207 .................................................................... 22Figura 3: Demonstra os níveis de processo do modelo SPICE, ISO 15504. ............................... 25Figura 4: Logotipo do modelo CMM referenciando ao nível de maturidade dois....................... 28Figura 5: Demonstra os níveis de processo do modelo CMM. .................................................... 29Figura 6: Ilustra os acontecimentos em cada nível do CMM....................................................... 33Figura 7: Logotipo da norma CMMI............................................................................................ 34Figura 8: Comparação das duas representações a de Maturidade e Contínua. ............................ 35Figura 9: CMMI Representação por estágios. .............................................................................. 36Figura 10: Demonstra os níveis de processo do modelo CMM. .................................................. 38Figura 11: Logotipo do modelo MPS.BR .................................................................................... 42Figura 12: Estrutura do projeto MPS.BR ..................................................................................... 42Figura 13: Logotipo da Coordenadora do projeto MPS.BR ........................................................ 43Figura 14: Descrição dos níveis de maturidade do (MR-MPS.BR) com seus processos. ........... 45Figura 15: Descrição dos processos do Modelo de Negocio (MN-MPS.BR) ............................. 63Figura 16: Comparação dos Níveis de Maturidade do modelo MPSBR com o modelo CMMi .. 65Figura 17: Logotipo da empresa KMF. ........................................................................................ 67Figura 18: Logotipo da Instituição Implementadora II COPPE/UFRJ ........................................ 68Figura 19: Escopo do Projeto ClippingNews. .............................................................................. 70Figura 20: Logotipo do Software Estação TABA desenvolvido na COPPE/UFRJ ..................... 74Figura 21: Logotipo da Instituição Avaliadora, RIOSOFT. ........................................................ 75
    • 9 LISTA DE QUADROSQuadro 1: Visão da formação do projeto MPSBR....................................................................... 44Quadro 2: Descrição dos resultados esperados para o processo de Gerência de Projetos .......... 47Quadro 3: Descrição dos resultados esperados para o processo de Gerência de requisito .......... 49Quadro 4: Descrição dos resultados esperados para o processo de Aquisição ............................ 51Quadro 5: Descrição dos resultados esperados para o processo de Gerência de Configuração .. 52Quadro 6: Descrição dos resultados esperados para o processo de Gerência de Portfólio de . .... Projetos ....................................................................................................................... 54Quadro 7: Descrição dos resultados esperados para o processo da Garantia da Qualidade ........ 55Quadro 8: Descrição dos resultados esperados para o processo de Medição .............................. 56Quadro 9: Descrição dos processos de avaliação ........................................................................ 62Quadro 10: comparativos MPSBR e CMMI ................................................................................ 65Quadro11: Resultado da Avaliação ............................................................................................. 76
    • 10 LISTA DE ABREVIATURAS E SIGLASAQU AquisiçãoBID Banco Interamericano de DesenvolvimentoCMM Capability Maturity ModelCMMI Capability Maturity Model IntegrationCMMI-SVC CMMI for ServicesCMMI-ACQ CMMI for AcquisitionCMMI-DEV CMMI for DevelopmentFINEP Financiadora de Estudos e ProjetosFNDCT Fundo Nacional de Desenvolvimento Científico e TecnológicoGCO Gerência de ConfiguraçãoGPP Gerência de Portfólio de ProjetosGPR Gerência de ProjetosGQA Garantia da QualidadeGRE Gerência de requisitoISO Institute of Organization for StandardizationIEC International Electrotechnical CommissionKPAs Key Process AreasMA-MPS Método de avaliaçãoMED MediçãoMN-MPS Modelos de negócioMPSBR Melhoria de Processos do Software BrasileiroMR-MPS Modelo de ReferênciaMTC Ministério de Ciência e TecnologiaSEBRAE Suporte do Serviço Brasileiro de Apoio às Micro e Pequenas EmpresasSEI Software Engineering InstituteSOFTEX Associação para Promoção da Excelência do Software BrasileiroSPICE Software Process Improvement and Capability Determination
    • 11 SUMÁRIOINTRODUÇÃO ......................................................................................141 BASE HISTÓRICA DA MELHORIA DE PROCESSO DESOFTWARE ...........................................................................................181.1 ISO/IEC 12207............................................................................................... 18 1.1.1 Processos Fundamentais ......................................................................... 20 1.1.2 Processo de Apoio .................................................................................... 20 1.1.3 Processos Organizacionais ...................................................................... 221.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 ............................................................................................ 281.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 .................................................................................... 331.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
    • 122 MPS.BR ................................................................................................422.1 Conceito MPSBR ........................................................................................... 422.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 .................................................................................. 602.3 Método de Avaliação (MA-MPS).................................................................. 612.4 Modelo de Negócio (MN-MPS) ..................................................................... 642.5 Quadro comparativos entre os modelos MPSBR e CMMI ......................... 663 IMPLANTAÇÃO DO MPSBR NA KMF UMA EMPRESAALAGOANA. .........................................................................................673.1 A KMF ........................................................................................................... 673.2 A escolha do Nível ......................................................................................... 683.3 Viabilização Financeira ................................................................................. 693.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 ............................................................................................ 76CONCLUSÃO ........................................................................................78REFERÊNCIAS .....................................................................................80ANEXO ...................................................................................................86ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DOPROJETO ...............................................................................................86
    • 13ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DOPROJETO (CONTINUAÇÃO) 87ANEXO B - MODELO DE TERMO DE ABERTURA DOPROJETO ...............................................................................................88ANEXO C - MODELO DE LAUDO DE AVALIAÇÃO DADECLARAÇÃO DO ESCOPO PELO GQPP ....................................89ANEXO D - MODELO DE PLANO DE GERÊNCIA DEDOCUMENTOS E COMUNICAÇÃO ................................................90ANEXO E - MODELO DE CONTROLE DE ALTERAÇÃO DEREQUISITOS .........................................................................................91ANEXO G - PLANO DO PROCESSO DO PROJETOCLIPPINGNEWS ..................................................................................94ANEXO H - PLANO DO PROCESSO DO PROJETOCLIPPINGNEWS ..................................................................................96
    • 14INTRODUÇÃO MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa que avaliaqualidade e produtividade de software, e serviços relacionados com padrão e qualidade dasnormas de desenvolvimento internacional, como CMMI, baseado no ISO/IEC 12207, e ISO/IEC15504. Estes melhoramentos são direcionados à real condição do mercado brasileiro, para oalcance 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 serreconhecidas 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 softwarede Alagoas a buscarem um patamar de qualidade, planejamento e controle, para ficarem em umnível de organização reconhecido internacionalmente e seu produto aceito no mercado comaprovação. Desta forma, objetiva-se a amostragem de como devem ser utilizadas as normas epadrões de projetos para a melhoria de processos de qualidade de softwares, e como foi aplicadoe certificado em uma empresa de software alagoana no nível de maturidade F, mostrando ospadrões de certificações, ISO/IEC 12207 e 15504, CMM, CMMI e MPS.BR, com quadroscomparativos entre os modelos, pontuando a implantação do MPS.BR nível F na empresaalagoana KMF, demonstrando os requerimentos do guia de maturidade G e F do modelobrasileiro. A dificuldade enfrentada pelas empresas de software Alagoanas, em acompanharas mudanças que estão acontecendo nos ambientes de negócios, tem motivado tais empresas aprocurarem 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 eCMMI), mesmo nos seus níveis mais baixos dos modelos CMMI (2 e 3) e a ISO/IEC 12207dividida em classes, estão fora do alcance da micro, pequena e média empresa, especialmente noBrasil, devido ao seu custo elevado. Como melhorar os processos de uma empresadesenvolvedora de software se os padrões internacionais são muito caros e complexos deimplantar.
    • 15 Com o modelo MPS.BR, solução brasileira para a melhoria de processo desoftware que é até utilizada por países latino-americanos, as empresas de pequeno porte têmpossibilidades 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ênciade Portfólio de Projetos, Garantia da Qualidade, Aquisição, Medição e do nível “G” com osprocessos de Gerência de Projeto e Gerência de Requisitos. Com a principal solução para asempresas de Micro e Médio porte, já que a diferença orçamentária para a aquisição da normaInternacional é muito superior à brasileira, as transições de níveis de maturidade são mais suavesem 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 eserviços por ela prestados. O Ministério de Ciência e Tecnologia (MTC) divulgou uma pesquisa ainda em2001 (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 dedesempenho para as grandes organizações brasileiras. Os motivos para este largo intervalo dedesenvoltura entre os portes das empresas é um conjunto de fatores: a escassez de recursofinanceiro; uma quantidade de RH debilitado ou sem preparo para o cargo ocupado; e o maisimportante, a imaturidade dos cargos de gerência. Este, por sua vez, e deixa os processos/projetosda empresa com uma série de problemas, atraso no tempo previsto de entrega, ou a implantaçãodo software com erros de funcionamentos, retornando posteriormente para que seja feitocorreções no procedimento realizado com ineficácia, entre outras causas que acontecem por faltade 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çãopara as empresas de softwares, com a utilização do modelo de Melhoramento de processo doSoftware Brasileiro (MPS.BR), projeto proposto em 2003 e coordenado pela Associação paraPromoção da Excelência do Software Brasileiro (SOFTEX), criado para suprir as necessidades deacordo com as carências brasileiras. Assim seria retirada uma dependência ao modelo CMMI, oqual o valor de aquisição é alto e complexo na implementação de uma empresa. Neste projetointernacional, 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 resultadosesperados a serem seguidos de maneira eficiente e produtiva para a criação da estrutura dosprocessos 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); RIOSOFTem Rio de Janeiro/RJ; CenPRA em Campinas/SP; CESAR em Recife/PE e CELEPAR emCuritiba/PR. Esse comitê recebe o apoio financeiro dos seguintes órgãos: do Ministério daCiê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 deDesenvolvimento Científico e Tecnológico (FNDCT); do fundo VERDE-AMARELO; do BancoInteramericano de Desenvolvimento (BID) e do suporte do Serviço Brasileiro de Apoio às Microe Pequenas Empresas (SEBRAE). De acordo com o relatório de avaliação contida na divulgação do dia 22 de janeirode 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 nenhumaempresa com esta graduação; no C com duas; no nível D, com uma; E com seis, F com 59 e, parafinalizar, 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, quese encontra no seleto grupo das organizações que contêm o certificado do modelo MPS.BR, eestá no grau de maturidade F, pois é uma das quatros organizações de Alagoas que utiliza oprojeto brasileiro de melhoria de processo de Software, das quais no nordeste apenas seteempresas 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 desempenhocrescente da empresa, que com a melhoria de processo proporciona conseqüentemente um grandesalto na qualidade no desenvolvimento dos processos e dos produtos e serviços, possibilitandoum domínio sobre o projeto/equipe e clientes. A organização da monografia se dará em três capítulos, onde no primeiro é umavisã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
    • 17MPS.BR, o modelo brasileiro sendo aprofundado nos níveis de maturidade G e F, mostrandoquadros comparativos entre os modelos CMMI e MPSBR. O terceiro e último capítulo consisteno desenvolvimento de um estudo de caso aplicado na empresa alagoana KMF, certificada nonível de maturidade F do MPS.BR.
    • 181 BASE HISTÓRICA DA MELHORIA DE PROCESSO DESOFTWARE Neste capítulo, será feita uma abordagem sobre a base histórica da melhoria deprocesso de software, delimitando a ISO/IEC 12207 e sua evolução, a ISO/IEC 15504; o CMMcom 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 processode software.1.1 ISO/IEC 12207 A norma ISO/IEC 12207, criada pela ISO (Institute of Organization forStandardization - Organização Internacional para Padronização), juntamente com a IEC(International Electrotechnical Commission - Comissão Eletrotécnica Internacional), teve seudesenvolvimento proposto em 1988. Segundo Weber (20--b), “a norma foi publicadainternacionalmente em 1995, e no Brasil em 1998”. Posteriormente revisada em 2002, ela foicriada 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 dedesenvolvimento do softwares é o objetivo principal do modelo. Projetada a ser flexível, não temrelações com métodos, ferramentas, treinamentos, métricas e também não tem ligações comlinguagens empregadas no desenvolvimento do programa, o que possibilita um acompanhamentoda evolução da engenharia de software e de organizações com culturas distintas, flexibilidadeimportante, pois implica no “o que fazer” e não ficando refém “como fazer”, tornando o modeloatual ubíquo, modular e adaptável às necessidades fundamentadas em dois princípios, amodularidade e a responsabilidade. Modularidade se refere a processos com número reduzido deacoplamento e junções, entre (módulos ou processos) e um máximo de coesão elevada, excluindoassim falhas, e como manter e testar a dificuldade na compreensão, entre outros; contendo assimum forte relacionamento entre as partes de um processo e o número mínimo de interfaces entre osprocessos. A responsabilidade estabelece um responsável para cada processo, facilitando aaplicaçã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 umconhecimento 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 deacordo 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.
    • 201.1.1 Processos Fundamentais Em linhas gerais, são todas as atividades que a organização executa nos serviçosda 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
    • 21verificação, processo de validação, revisão conjunta, auditoria e resolução de problemas. Com oobjetivo de auxiliar os outros processos, visando à qualidade e o sucesso do projeto, o processode 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 melhoraro ciclo de vida do software. As atividades contidas nos processos organizacionais visam amelhoria 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 edescreve como foram divididos nos processos fundamentais de apoio e organizacionais, comoacima citados, a baixo quadro que mostra a estrutura da ISO/IEC12207Figura 2: Demonstra a estrutura da ISO/IEC 12207.Fonte: < http://qualidade.wdfiles.com/local--files/mpsbr-qualidade-de-software/ISO12207.png>
    • 241.2 ISO/IEC 15504 Uma evolução da ISO/IEC 12207, a ISO/IEC 15504, também conhecida comoSPICE, é 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 equivalentesao CMMI. Essa norma teve uma versão aprovada em 1998 (ISO/IEC, 2003), sendo abastecidapelas 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 doprojeto SPICE (Melhoria de Processo de software e determinação de Capacidade - SoftwareProcess 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 deprocessos considerados universais e fundamentais para que se possa ter um planejamento edesenvolvimento com qualidade, com o propósito na melhoria de processos de criação desoftware 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ísticasmanter, é utilizado avaliações de capacidades. Segundo WEBER (et al; 20--b; p6) “a organizaçãopode realizar a avaliação, gerando um perfil dos processos que será usado para a elaboração deum plano de melhorias”, das quais a empresa deve continuar sempre à procura, sem perder aqualidade 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 pontoem diante, sabendo-se o que fazer para a melhoria de processo, é aplicado o processo especificopara 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.
    • 261.2.2 Processos Para cada categoria com processos específicos, existem seis níveis numerados de 0a 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 quevenham a implementar o modelo. Segundo Lahoz e Sant’anna “este modelo visa também avaliara capacidade da organização em cada processo, permitindo assim sua melhoria, pois cada um dosprocessos deve ser classificado em níveis (incompleto, executado, gerenciado, estabelecido,previsível e otimizado)” conforme descrito a seguir.
    • 271.2.2.1 Incompleto Também conhecido como Inicial ou Não-Realizado, tem uma má performancegeneralizada no desenvolvimento dos objetivos específicos das práticas bases do processo desoftware, 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 muitoscuidados, e depende muito do esforço individual. Existem, também, produtos de trabalhofinalizados com o uso identificáveis do processo, os quais em outras versões são nomeados deRealizados ou Realizados Informalmente.1.2.2.3 Gerenciado Os processos são planejados e acompanhados. Já os procedimentos específicos sãoaveriguados, visando a qualidade, levando a organização a uma boa estimativa de direção, e umprocesso de software com qualidade bem definido.1.2.2.4 Estabelecido Com o processo estabelecido, a organização busca práticas de acordo com osprocessos definidos, usando versões de normas já trabalhadas com sucesso ganho, e trabalhandocom a mesma qualidade, as quais já estão documentadas, ajudando assim o entendimento para ospróximos projetos.
    • 281.2.2.5 Previsível Medido, previsível e controlado quantitativamente. Nesse nível, são realizadasmedidas detalhadas, onde as reais condições dos processos são recolhidas e analisadas paralevarem a uma compreensão quantitativa da capacidade do processo, e a uma melhor aptidão paraantecipar 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 comobase os objetivos de negócios na empresa, é dado partida para o aperfeiçoamento contínuo dosprocessos de desenvolvimento sobre estas metas, através do retorno quantitativo da realização doprocesso definido, e também de tecnologias inovadoras, o que resultará em melhorias sempre dealto nível.1.3 CMM O CMM-SW (Capability Maturity Model for Software - Modelo de Maturidadede capacidade para Software) ou simplesmente conhecido por CMM, é uma norma decertificação de qualidade utilizada para avaliação e melhorias na maturidade dos processos emdesenvolvimento de software e serviços correlacionados, com origem na década de 1980 nosEstados Unidos. Segundo PESSÔA (2005) “O desenvolvimento desse modelo foi financiado pelodepartamento de defesa americano, com o objetivo de se estabelecer um padrão de qualidade parasoftware desenvolvido para as forças armadas”. Com este modelo de avaliação, seria capaz demedir os processos de construção do software fabricado pelas as empresas que concorriam pelalicitação, tendo em vista a indicação pela qualidade, valor do produto e garantia de prazos deentrega completa ou por módulos dos projetos contratados. Embora o modelo tenha sido geradopara a composição de grandes corporações de desenvolvimento de software que iriam sercontratadas para projetos militares, seus princípios são válidos para vários tipos de projetos desoftwares.
    • 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, paradesenvolvimento do projeto, o SEI (Software Engeneering Estitute) sediado na Carneggie MellonUniversity na Pennsylvania, a qual até hoje é a responsável pela evolução do CMM. Atualmentecom a versão 1.2, evolução da anterior 1.1, o modelo de maturidade de capacidade CMM forneceuma 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 amaturidade de uma área de desenvolvimento de software, e como evoluir em direção a umacultura de engenharia de software e excelência de gestão. Para isso é preciso analisar ecompreender a forma de trabalho, adaptando as características de empresa por empresa, uma vezque 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, trabalhafocado em um número limitado de atividades e trabalhos a serem concluídos com êxito. Sendo
    • 30assim, a organização ganhará uma melhoria nos processos e em toda a sua estrutura, habilitando aganhos 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íveisde maturidade, são eles: inicial, repetível, definido, gerenciado e otimização que fornecemfundamentos sucessivos para a excelência do processo, dos quais os cinco níveis de maturidadetêm a finalidade de medir a atual situação da organização nos desenvolvimentos de seus projetose 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 maiormaturidade do processo que está associado a uma maior produtividade e qualidade, e a um menorrisco 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 maturidadefica 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 caminhosevolutivos que as organizações terão que passar para obterem um processo de implementação edisciplina com excelência; o outro (à direita) demonstra que os riscos e desperdícios são maiores
    • 31nos níveis inferiores; e que a qualidade, produtividade e visibilidade são supremas no nívelMá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õescaóticos, depende do esforço individual para que o sucesso aconteça e poucos processos sãodefinidos. Em uma visão ampla, a organização não fornece um ambiente estável para a estruturado desenvolvimento e a manutenção do produto. Para a evolução do trabalho diário, a prática degestão sem rumo certo, muitas vezes prejudica o desenvolvimento das boas práticas peloplanejamento ineficiente “encache” de novos projetos, tirando da ordem dos cronogramas dosprojetos os próximos processos a serem criados. Um gerente excepcional para o sucesso doprojeto e uma equipe de software madura e eficiente, é de quem depende inteiramente oprocedimento do projeto, porém ,mesmo com uma boa prática de desenvolvimento, não podesuperar a instabilidade criada pela ausência de práticas sólidas de gestão. Alteração constante noprojeto ‘ad hoc’ é geralmente imprevisível aos orçamentos, funcionalidades, cronogramas equalidades 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. Osprojetos novos são analisados com experiência de projetos similares, anteriormente produzidoscom 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 desoftware, acompanhamento no cronograma, custos, funcionalidades e armazenando os requisitos,produtos de trabalho que a integridade é rigidamente controlada. Os padrões do projeto sãocaracterizados, validados, e a organização garante que o uso dos procedimentos será seguidosempre. O nível dois de maturidade é conhecido como disciplinado, pelos seguintes motivos:
    • 32processos estáveis, reutilização de projetos com sucessos, utilização contínua de planejamentorealista, processos de Gerenciamento de requisitos, planejamento, monitoramento, controle deprojeto, gerenciamento de fornecedores, medição, análise, garantia da qualidade do processo, doproduto e da gerenciamento de configuração.1.3.1.3 Definido Os processos de desenvolvimento, a manutenção de software e a gestão deprocessos da empresa, como um todo, são documentados. Os processos são utilizados para apoiaros gerentes de software e a área técnica, através de programas de treinamentos que sãoimplantados 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 asatividades 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 bemdefinido, documentado e padrão para a empresa. O processo de software é satisfatoriamenteentendido”. No nível definido, os produtos são produzidos, desenvolvidos, a qualidade éacompanhada e o cronograma é cumprido, além das funcionalidades e custos. Seus processosabrangem o desenvolvimento de requisitos, solução técnica, integração do produto, verificação evalidaçã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 produtosdesenvolvidos e processos de software, onde acontece medição na produtividade e na qualidadedos processos de todo o projeto. Os dados disponíveis dos processos são armazenados pra quepossam ser utilizados, coletados e analisados, reduzindo a variação no desempenho com controlesobre 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 aorganização tenha uma previsão de tendências de qualidade dos produtos e processos, não
    • 33ultrapassando 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 deprocesso, os quais são fortalecidos de maneira proativa quando surgem oportunidades demelhorias com objetivo de antecedência a falhas. Com os processos armazenados, são realizadasanálises de custo, benefícios de tecnologias novas e mudanças solicitadas para o projeto. Asnovas práticas de engenharia são identificadas, armazenadas e repassadas para toda aorganizaçã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 emoutros projetos. O nível cinco de maturidade fica sendo conhecido como melhoria contínua, poisestá continuamente procurando a melhoria, expandido sua capacidade de processos juntamentecom o projeto. Avanços incrementais são adicionados aos processos com inovações que utilizamnovos métodos e tecnologias. Na figura número 6, basicamente é exibida como a gerência presencia osprocessos em cada nível de maturidade; no nível 1, o processo é uma caixa preta, o entendimentodo processo é caótico, onde acontecem inúmeras situações para que o projeto atrase e tenhaprejuízos; no nível 2, há controle sobre os requisitos e sobre o projeto; no nível 3, já é visível asatividades dentro dos processos, onde os gerentes e os engenheiros compreendem suas tarefas; nonível 4, os gerentes têm a possibilidade de medir quantitativamente os processos, facilitando asdecisõ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 totalcontrole 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 softwaresendo eles: Engenharia de Sistemas (SE-CMM); Aquisição de Software (SA-CMM) e Gestão deRecursos Humanos de Empresas de Softwares (P-CMM) entre outros. Mesmo com a utilizaçãobenéfica dos modelos, as excessivas diversificações trouxeram problemas, pois cada modelotinha que ser avaliado separadamente, gerando um aumentado custo de treinamento, ocasionandoo acontecimento de dificuldades de comunicação entre eles, já que cada modelo possuicaracterí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, foicriada 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áticaconsistente com regras de construção como seus anteriores. O CMMI não define como o processodeve ser desenvolvido, porém reúne características estruturais e como deve ser finalizadoprocesso. O CMMI, na atual versão 1.2, tem três modelos publicados: CMMI forDevelopment(CMMI-DEV), para processo de desenvolvimento de produtos e serviços; CMMIfor Acquisition (CMMI-ACQ), para a aquisição e terceirização de bens e serviços; e CMMI forServices (CMMI-SVC), para processos de empresas prestadoras de serviços publicados nasequê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 umaescolha de qual caminho deve ser percorrido à procura da melhoria de seus processos, de acordocom seus interesses. Segundo PESSÔA (2005) “para entender o significado do termo capacidadepode se pensar na capacidade que alguém possui para realizar um trabalho: quanto maior acapacidade 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 conjuntospreviamente definidos para que seja cumprido o KPAs (Key Process Areas - área chave deprocesso), mesmo modelo adotado pelo CMM. Na representação por estágios possui níveis dematuridade com conjunto de áreas de processo que caracterizam diferentes comportamentosorganizacionais, que é uma imagem para que a capacidade das organizações possa desenvolverprojetos 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 5níveis de maturidade para suportar e guiar a melhoria dos processos. As áreas de processos
    • 37podem 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 pelaorganização, por estarem no nível mais baixo do CMMI. Isso não implica dizer que o produtonã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 motivode alguma crise, provocando, assim, atraso na entrega do software, aumentando excessivamente ocusto do que foi planejado. Como a organização geralmente não fornece um ambiente estável, osprocessos 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 processosplanejados. Com o foco de gerenciamento básico, o nível dois traz uma análise nas tarefas queestão sendo desenvolvidos. Assim, encontrados os requisitos que não são compatíveis com os queforam planejados, são rapidamente corrigidos para não interferir no prazo de entrega. Caso oproblema não seja sanado, a organização tentará uma solução. Figura 9: CMMI Representação por estágios. Fonte: (RINCON, 2009).
    • 381.4.1.3 Definido A diferença em relação ao nível anterior, é que neste acontece uma padronizaçãonos processos, os quais são melhores caracterizados e entendidos, e assim sendo descritos osprocedimentos e métodos. As ferramentas são melhoradas e definidas com mais rigor, tendo ofoco na padronização do processo e nos requisitos de desenvolvimento. São eles: análise dedecisõ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 noprocesso 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 aconteceum controle de processos utilizando métodos estatísticos e outras técnicas quantitativas. Sendofácil a identificação de qualidade e o desempenho de um processo, estes são armazenados em umrepositório para que possa ter um suporte para decisões futuras. Os requisitos de desenvolvimentosã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 porestágios, os processos são continuamente melhorados com uma análise quantitativa dasalterações; e no desempenho, os processo desse nível são a inovação organizacional e análise decausas 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 umcaminho já traçado para chegar a um nível de maturidade, a representação contínua utiliza ummétodo que permite que a empresa escolha qual a área ou áreas de processos que irão utilizarpara que adquira melhoramentos nos processos selecionados para as validações. Utilizando níveisde capacidade, a Representação Contínua apresenta seis níveis de capacitação com numeraçãoiniciada no número zero e finalizada no numero cinco. As áreas de processo são agrupadas porcategorias afins. É importante ressaltar que muitos aspectos são os mesmos da Representação porEstá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 paradefinir, planejar, implantar, monitorar, controlar, medir e melhorar processos; a Gerência de
    • 40Projeto contém atividades de planejar, monitorar e controlar o projeto; a Engenharia refere-se àsvá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 oucomponentes 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 oumais objetivos específicos do processo não são convincentes e satisfatórios, quando avaliado pelaorganização.1.4.2.2 “1” Realizado Com a área escolhida pela organização, os objetivos específicos de cada processosão finalizados com eficácia. Segundo MANERA (et al ;2007) “um processo realizado satisfaztodos 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 complanejamentos gerenciados, os processos são monitorados, revisados e controlados, assim comoos produtos de software e serviços, por pessoas com habilidades adequadas para produzirem oque cada processo pede.
    • 411.4.2.4 “3” Definido Tendo os processos da organização padronizados, serão progressivamentemelhorados 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ãocontrolados e a qualidade é entendida por estatísticas sempre que melhorada. Algumas atividadesque se encontram nesse nível é a identificação de sub-processos que podem ser controladas pornormas 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 edesempenho, com a utilização de melhorias tecnológicas incrementais de inovação, visando asvá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.
    • 422 MPS.BR Neste capítulo será feita uma explanação sobre o programa de melhoria deprocessos do software brasileiro (MPS.BR), apresentando informações básicas sobre oscomponentes de método de avaliação (MA-MPS), os modelos de negócios (MN-MPS), o modelode Referência (MR-MPS) e todos seus níveis de maturidade, aprofundando os subsídios para osníveis de maturidade G e F, como previsto na delimitação do tema desta monografia, apresentadoas vantagens estabelecidas para as organizações e a certificação brasileira de melhoria processode software.2.1 Conceito MPSBR O modelo MPS.BR, Melhoria de Processo do Software Brasileiro, é um programaque tem como objetivo a melhoria de processo de software, direcionando a organização, aqualidade e a produtividade dos produtos desenvolvidos e serviços relacionados. SegundoWEBER (20--b, P3) “O Projeto MPS.Br visa a melhoria de processos de software em empresasbrasileiras a um custo acessível, especialmente na grande massa de micro, pequenas e médiasempresas”, sendo utilizado, também, para empresas públicas e privadas, no entanto com padrão equalidade 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 demelhoria de processo, o projeto MPSBR é constituído por três componentes: Modelo deReferê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 totalcompatibilidade com o CMMI e as ISO/IEC 12207 e ISO/IEC 15504, como segunda meta aimplementação e avaliação do modelo brasileiro, a um custo acessível em todo o país, com foconas 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 desustentaçã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 queformam o conjunto do projeto tem as seguinte funções: o guia geral contém informações queobjetivam o modelo de Referência (MR-MPS), seus níveis e etc; o guia de aquisição descreve osprocessos de aquisição de software e serviços correlatos; no guia de avaliação, é apresentado ométodo de avaliação (MA-MPS), contendo principalmente os passos necessários para o
    • 44entendimento dos processos avaliativos; e no documento de programa contém informações sobreo modelo de negócio (MN-MPS). Cada componente é descrito em documentos ou guias. Segundo SILVA (20--) “oprojeto tem como objetivo promover a qualificação de um grupo amplo de empresas compatívelcom os padrões de qualidade aceitos internacionalmente. Este projeto está sendo desenvolvidodesde dezembro de 2003” o qual foi criado no Brasil para a solução do melhoramento doprocesso de software, objetivando ajudar em número expressivo as micros, pequenas e médiasempresas. 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 daExcelê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; pelaCenPRA em Campinas/SP; pelo CESAR em Recife/PE e pela CELEPAR em Curitiba/PR. Essecomitê recebe apoio financeiro do Ministério da Ciência e Tecnologia (MCT), através de recursosdo Fundo Nacional de Desenvolvimento Científico e Tecnológico (FNDCT), Financiadora deEstudos 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 MPSBRFonte: 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 aresponsabilidade, Segundo a SOFTEX (2009a), coordenadora do projeto MSPBR disponibilizaque: “O Modelo de Referência MR-MPS contém os requisitos que os processos das unidadesorganizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém asdefinições dos níveis de maturidade, processos e atributos do processo” com seus requisitos emtotal 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üenciaise acumulativos. Cada nível de maturidade é uma junção entre processos e capacidade dosprocessos, ou seja, é composto por um conjunto de processos em um determinado nível decapacidade”. Tais níveis são nomeados por letras que representam o estado de maturidade quepossa atuar em uma organização. São elas de “A” até “G”, montado, assim, o perfil de processoda empresa que indica onde estão os erros para que possam ser sanados, colocando o esforço namelhoria 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ãonomeados e lidos em ordem inversa, iniciando na letra “G” e finalizando em “A”. Tais níveis sãoos seguintes: Parcialmente Gerenciado, Gerenciado, Parcialmente Definido, LargamenteDefinido, Definido, Gerenciado Quantitativamente e o grau de maturidade mais elevado. EmOtimizaçã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 Ge 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ção2.2.1 G - Parcialmente Gerenciado Nos níveis de maturidade do modelo relacional, o nível G é o primeiro a implantaras melhorias dos processos de software em uma organização. Por este motivo, deve ter cautelapara a capacidade da empresa, na Gerência de projetos, mesmo sendo parcialmente, e na gerênciade requisito, que são os dois processos que compõem o nível G. Dois pontos são crucias na formade trabalhar da organização: mudar a cultura da organização para a melhoria de processo, e adefiniçã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ídasQuadro 2: Descrição dos resultados esperados para o processo de Gerência de ProjetosFonte: SOFTEX(SOFTEX, 2009d).
    • 50 2.2.1.2 Gerência de requisito Na gerência de requisito, o objetivo do processo é o controle e a evolução dos requisitos, vindos de análise junto ao cliente ou gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, sempre documentando as mudanças dos requisitos e suas justificativas em geral, identificando inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho. Segundo a SOFTEX (2009d) “O propósito do processo e Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto, e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto”. Resultados Gerência de requisito (GRE) Esperados GRE1 Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios e objetivos, os requisitos têm que ser claro no seu objetivo, as comunicações devem ser registradas formalmente em atas, e-mails, ferramentas de comunicação ou outros meios, os requisitos podem ser registrados na forma de uma lista de requisitos, especificações de casos de uso ou outras formas, é interessante fazer reunião com o cliente para aprovação. GRE2 O comprometimento da equipe técnica com os requisitos aprovados é obtido, na forma de ata de reunião, e-mail ou outra forma, se já tinha um comprometimento marcado uma reavaliação seria feita. GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida, ter definida a rastreabilidade facilita a avaliação do impacto das mudanças de requisitos que possam ocorrer. GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas, as consistências entre os requisitos e os produtos de trabalho do projeto devem ser avaliadas e os problemas identificados devem ser corrigidos. GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto, é raro um projeto não ter mudanças. É importante ressaltar que em um projeto não é obrigatório que sempre ocorram mudanças nos requisitos estabelecidos.Quadro 3: Descrição dos resultados esperados para o processo de Gerência de requisitoFonte: SOFTEX(SOFTEX, 2009d). 2.2.2 F – Gerenciado No nível de maturidade F, os novos processos para a implantação podem ser feitos em qualquer sequência, pois os processos encontrados são para a gestão do projeto. Processo de apoio gerencia fornecendo informações de controle e qualidade aos produtos de trabalho.
    • 51Segundo a SOFTEX (2009e) o guia de implementação, parte 2, que é direcionado para o nível dematuridade F “O principal foco do nível F é agregar processos de apoio à gestão do projeto, noque diz respeito à Garantia da Qualidade (GQA) e Medição (MED), bem como aqueles referentesà organização dos artefatos de trabalho por meio da Gerência de Configuração (GCO)”. Aoadicionar novos processos na organização, não implica na contratação de mais recursos humanos,mas a definição de novas competências necessárias.2.2.2.1 Aquisição É o processo responsável em planejar uma aquisição de produto ou serviços defornecedores, tendo preocupação com: a seleção, o monitoramento do contrato, a ótima qualidadeno tempo de entrega e a redução de riscos. Para que todas essas metas sejam atingidas, énecessário um contrato que deva estar claramente definido entre as partes e responsabilidades deambos, pois se não houver algum controle, não haverá possibilidade de validações, cobranças eavaliações sobre as partes envolvidas. O processo de Aquisição é obrigatório para uma empresa desenvolvedora de software que contrata o desenvolvimento, ou adquire algum componente de software que será entregue juntamente com o produto de software ao cliente. Assim, o processo de Aquisição é definido, implantado e institucionalizado para minimizar riscos que podem comprometer os resultados esperados; tais como riscos de não cumprimento de prazos, do produto adquirido não ter a qualidade esperada, do produto adquirido não ter compatibilidade com a arquitetura tecnológica definida, dificuldades de integração, problemas de suporte etc. (SOFTEX, 2009e) Além da aquisição de componentes de terceiros, são encontradas outras obrigaçõespara as seguintes empresas: • de software que possua duas ou mais unidades; • a que desenvolve produtos de software em parceria com outras organizações; • as que subcontratem partes do produto de software; • e aquelas que estejam implantando um programa de reutilização. Não é obrigado uma empresa desenvolvedora de software, durante o processo deaquisição, adquire ferramenta ou componentes que aumentem a produtividade, ou componentesde código aberto que sejam entregues junto ao produto final, segundo a SOFTEX (2009e). Noentanto, o processo de Aquisição é recomendado, caso a aquisição de ferramentas e/ou
    • 52 componentes de software impliquem em riscos para o projeto. Por exemplo, se as ferramentas e/ou componentes de software interferirem em requisitos de qualidade, como interoperabilidade, eficácia, manutenibilidade e etc. Para as descrições dos resultados dos processos referentes ao nível de maturidade F, será detalhado no quadro número 4 até o quadro número 8, conforme publicado na guia de implementação, parte 2, da Fundamentação para Implementação do Nível F do MR-MPS, segundo a (SOFTEX, 2009e). Resultados Aquisição (AQU) Esperados AQU1 As necessidades de aquisição, as metas, os critérios de aceitação do produto, os tipos e a estratégia de aquisição são definidos, antes é feita uma análise do tipo “fazer ou comprar”, datas críticas de entrega e integração, funcionalidade e qualidade de redução. AQU2 Os critérios de seleção do fornecedor são estabelecidos e usados para avaliarem os potenciais fornecedores, através de identificações e documentação, como a localização geográfica do fornecedor, registro de desempenho do fornecedor em trabalhos similares, capacidade de engenharia, capacidade gerencial, disponibilidade. Após avaliação da empresa que pretenda a contratação é feita uma lista resultante de potenciais fornecedores. Para estes potenciais fornecedores um pedido de proposta pode ser feito, geralmente com um prazo definido para retorno. AQU3 O fornecedor é selecionado com base na avaliação das propostas e dos critérios estabelecidos AQU4 Um acordo formal que expresse claramente as expectativas, responsabilidades e obrigações de ambas as partes, cliente e fornecedor, é estabelecido e negociado entre elas, com documentação, tendo os itens bem claros de escopo, requisitos preliminares, termos e condições, principais produtos de trabalho a serem entregues, responsabilidades e as obrigações de ambas as partes. AQU5 Um produto que satisfaça a necessidade expressa pelo cliente é adquirido baseado na análise dos potenciais candidatos. A qualidade do produto adquirido é avaliada não só pelo fornecedor. AQU6 Os processos do fornecedor que são críticos para o sucesso do projeto são identificados e monitorados, gerando ações corretivas. Quando necessário, este resultado busca obter um comprometimento maior por parte do fornecedor com o componente de produto que será entregue e incorporado ao produto. Todos os processos que forem identificados como críticos devem ser monitorados em relação à conformidade com os requisitos do projeto. AQU7 A aquisição é monitorada de forma que as condições especificadas sejam atendidas, tais como custo, cronograma e qualidade, gerando ações corretivas quando necessárias. AQU8 O produto é entregue e avaliado em relação ao acordado, e os resultados são documentados para garantirem que o produto entregue seja compatível com os termos do acordo estabelecido. No entanto, é necessário que seja avaliado previamente à aceitação. AQU9 O produto adquirido é incorporado ao projeto para que esta inclusão aconteça, assegurarando que existam as facilidades apropriadas para receber, armazenar, usar e manter os produtos adquiridos, bem como assegurar que o treinamento apropriado seja provido para as pessoas envolvidas no recebimento, armazenagem, uso e manutenção dos produtos adquiridos.Quadro 4: Descrição dos resultados esperados para o processo de Aquisição.Fonte: SOFTEX(SOFTEX, 2009e).
    • 53 2.2.2.2 Gerência de Configuração Com determinação em estabelecer e manter a integridade do projeto, com seus produtos e processos, é fundamental prover o controle sobre os produtos de trabalho produzidos e modificados, para que se possa ter um acompanhamento minucioso sobre o andamento, e sobre as partes de uma configuração denominadas itens, que é a agregação de hardware, software ou ambos. Segundo a SOFTEX (2009e) “em determinados momentos do ciclo de vida do desenvolvimento e manutenção do software, esses itens de configuração são agrupados e verificados, constituindo configurações do software voltadas para propósitos específicos, denominadas baselines” assim fica delegado conjuntos de itens de configuração. Como pode ser constatado, a Gerência de Configuração não se propõe a definir quando e como devem ser executadas as modificações nos produtos de trabalho, papel este reservado ao próprio processo de desenvolvimento de software. A sua atuação ocorre como processo auxiliar de controle e acompanhamento (SOFTEX, 2009e). Resultados Gerência de Configuração (GCO) Esperados GCO1 Um Sistema de Gerência de Configuração é estabelecido e mantido, para a fácil analise o (GCO) é composto em três subsistemas: sistema de controle de versões, que é responsável por armazenar as diversas versões dos itens de configuração e assegurar que as modificações sobre esses itens ocorram de forma segura e controlada; sistema de controle de modificações, que é responsável por controlar o ciclo de vida das solicitações de modificação, desde o pedido até a incorporação da modificação na baseline; e por fim, sistema de gerenciamento de construção, que é responsável pela transformação dos itens de configuração fontes, código fonte, até o executável, procedimento de preservação dos dados backup que também é deste resultado GCO2 Os itens de configuração são identificados com base em critérios estabelecidos, caso os itens de configuração sejam muito pequenos, o número total de itens de configuração será grande e isso poderá afetar a visibilidade do produto, dificultar o gerenciamento e aumentar o custo de operação. Se os itens de configuração sejam muito grandes, o número total de itens de configuração será pequeno, e isso poderá gerar dificuldades de logística e manutenção, limitando as possibilidades de gerência. GCO3 Os itens de configuração sujeitos a um controle formal são colocados sob baseline, as atividades relacionadas à geração de uma baseline geralmente incluem: obter autorização do responsável para a criação e liberação da baseline; montar a baseline exclusivamente a partir do sistema de gerenciamento de configuração existente; documentar o conjunto de itens de configuração que estão contidos na baseline e disponibilizá-las para os grupos pertinentes envolvidos.Quadro 5: Descrição dos resultados esperados para o processo de Gerência de Configuração (Continuação)Fonte: SOFTEX(SOFTEX, 2009e).
    • 54(Continuação) GCO4 A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada, é importante que exista um mapeamento preciso entre as baselines e todas as versões dos itens de configuração que as compõem, assim como o mapeamento preciso entre as solicitações de modificação e todas as versões dos itens de configuração geradas durante sua implementação GCO5 Modificações em itens de configuração são controladas, a partir do momento que os itens de configuração passam a fazer parte de uma baseline, toda e qualquer modificação sobre esses itens de configuração deve passar por um processo formal de controle de modificações, esse processo formal de controle de modificações visa analisar o impacto das modificações e notificar aos afetados, evitando retrabalho e efeitos colaterais indesejáveis. GCO6 O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados, o acesso para os itens armazenados, é controlado com registro do que check-in, entra e check-out, sai de itens co armazenamento. GCO7 Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentesQuadro 5: Descrição dos resultados esperados para o processo de Gerência de ConfiguraçãoFonte: SOFTEX(SOFTEX, 2009e). 2.2.2.3 Gerência de Portfólio de Projetos O propósito do processo vigente é manter os projetos sustentáveis de forma a atender os objetivos estratégicos e também comerciais da organização, ficando sobre a sua responsabilidade a viabilidade da continuação ou não de algum projeto que esteja em desenvolvimento ou em análise. Neste caso fica fora da avaliação se a única atividade da unidade organizacional for evolução de produto. A SOFTEX (2009e) afirma que “Enquanto o processo de Gerência de Projetos (GPR) envolve as atividades de gerenciamento de um projeto, o processo de Gerência de Portfólio de Projetos (GPP) envolve atividades relacionadas ao gerenciamento do conjunto de projetos de uma organização”. Em seguida na quadro 6, são feitas descrições sobre os resultados esperados na gerência de portfólio de projetos.
    • 55 Resultados Gerência de Portfólio de Projetos (GPP) Esperados GPP1 As oportunidades de negócio, as necessidades e os investimentos são identificados, qualificados, priorizados e selecionados, solicitações de novos projetos podem surgir de vários meios, solicitação do cliente, oportunidade de mercado identificada, evoluções da tecnologia, mudanças no cenário econômico entre outros, são registradas para que possa ser analisadas estudar a viabilidade de transforma em um projeto ou ser descartado, uma escolha indevida de projeto podem ser maiores que os benefícios que podem ser dele advindos, retorno sobre o investimento (ROI). GPP2 Os recursos e orçamentos para cada projeto são identificados e alocados, os projetos considerados prioritários receberão recursos também de forma prioritária e isto deve ser analisado por uma perspectiva organizacional. GPP3 A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas, para cada um dos projetos que tenha sido selecionado e priorizado, deve ser identificado o profissional que será responsável pelas atividades de gerenciamento do projeto, o gerente do projeto, líder de Projeto, ou Analista Responsável varias nomenclatura podem ser utilizadas. GPP4 Os conflitos sobre recursos entre projetos são tratados e resolvidos, os processos utilizando os projetos de TI raramente são executados exatamente como o planejado, o desempenho de um projeto pode afetar outro projeto, uma nova tecnologia pode não ter o desempenho esperado etc. GPP5 Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são mantidos, e os que não atendem são redirecionados ou cancelados.Quadro 6: Descrição dos resultados esperados para o processo de Gerência de Portfólio de ProjetosFonte: SOFTEX(SOFTEX, 2009e). 2.2.2.4 Garantia da Qualidade A principal finalidade do processo de garantia de qualidade é confirmar que o produto desenvolvido ou serviços estão em conformidades com os processos traçados nos planos e recursos predefinidos para o projeto; deste modo fornece visibilidade do projeto dando um apoio à gerência, que também agrega valores à equipe de projeto nas revisões de procedimentos. A pessoa ou grupo que executa a atividade de garantir a qualidade de processos e produtos tem uma responsabilidade delicada, pois fiscaliza se as pessoas estão desempenhando adequadamente as suas tarefas e seguindo os procedimentos estabelecidos. Por isso, pode ser necessário instituir mecanismos na organização que permitam aos responsáveis pelas atividades de Garantia da qualidade executar seu trabalho com independência e autoridade (SOFTEX, 2009e). Fazem parte do objetivo de garantia da qualidade a averiguação dos processos: serviços e produtos desenvolvidos; documentar a não conformidade do projeto; itens de não- conformidades com os requisitos levantados; promover feedback da verificação realizada para a gerência e equipe de projeto; e por fim cobrar a correção das disparidades encontradas.
    • 56 Resultados Garantia da Qualidade (GQA) Esperados GQA1 A ligação dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto GQA2 A aderência, ligação, dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente, os processos que são utilizados tanto nos projetos quanto nas atividades de apoio devem ser selecionados para serem submetidos à avaliação da garantia da qualidade de forma a verificar se a sua execução está de acordo com o estabelecido. GQA3 Os problemas e as não-conformidades são identificados, registrados e comunicados, se originam quando há desvios entre o esperado e o realizado, comunicar um item significa informar a todos os interessados sobre a sua existência, de forma que possa ser tomada alguma ação para a sua resolução GQA4 Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões, se necessário, as ações corretivas são enviada para níveis superiores, de forma a garantir sua solução, as ações corretivas deverão identificar, no mínimo, a qual não-conformidade ela atende, quem é o responsável por resolvê-la, o prazo para resolução, o tipo de não- conformidade e a solução adotada.Quadro 7: Descrição dos resultados esperados para o processo da Garantia da QualidadeFonte: SOFTEX(SOFTEX, 2009e). 2.2.2.5 Medição Segundo a SOFTEX (2009e) “O propósito do processo Medição é coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais”. A medição é muito utilizada para o auxílio da tomada de decisão da gerência, porém a comparação entre os projetos ainda é prematura neste nível, pois não há ainda um bom portfólio de projetos que possam ajudar, não conseguindo levantar informações e análises para a identificação de problemas ou fatores de sucesso.
    • 57 Resultados Medição (MED) Esperados MED1 Objetivos de medição são estabelecidos e mantidos a partir dos objetivos de negócio da organização e das necessidades de informação de processos técnicos e gerenciais, existem alguns aspectos que podem ser medidos, processos como, tempo, esforço, número de incidências, dentre outros, os produtos incluem linhas de código, complexidade da estrutura, de dados e o tipo de software, comercial, científico e os recursos são as pessoas, as ferramentas e os métodos que podem ser medidos. MED2 Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e definido, priorizado, documentado, revisado e quando necessário atualizado. As medidas poder ser de relevância em relação às necessidades de informação, viabilidade de coleta dos dados, disponibilidade de recursos humanos e infra-estrutura para coletar os da facilidade para coleta dos dados, potencial resistência dos provedores de dados, número de indicadores relevantes que a medição apoiará e facilidade de interpretação. MED3 Os procedimentos para a coleta e o armazenamento de medidas são especificados, a coleta é a obtenção dos dados serão usados para medição como a horas trabalhadas por uma equipe e o tamanho do projeto. MED4 Os procedimentos para a análise das medidas são especificados, após escolha de uma métrica em MED2, têm que ser documentada atividades e responsabilidades pela análise das medições e como os resultados serão comunicados aos interessados, procedimento inclui a definição da freqüência, responsável, fase, dados de origem, ferramenta utilizada e verificações. Possibilitando um analise futura adequada. MED5 Os dados requeridos são coletados e analisados, após coletados, os dados devem ser analisados conforme o planejado pelas pessoas que têm essa responsabilidade dentro da organização, muitos erros acontecem nessa fase, com coletas tardias e dados que não refletem a realidade. MED6 Os dados e os resultados das análises são armazenados, incluindo os dados de medição, especificações de medições, resultados de análises, indicadores e interpretações, devem ser armazenadas para recuperação pelos interessados e para uso futuro, que geralmente são os planos de medições, especificações de medidas e relatórios de análises e apresentações. MED7 Os dados e os resultados das análises são comunicados aos interessados e são utilizados para apoiar decisões, as informações comunicadas podem ser quaisquer dos dados armazenados, mas preferencialmente os indicadores e a interpretação dada para eles, é importante que esses dados sejam despersonalizados para evitar qualquer uso que possa prejudicar pessoasQuadro 8: Descrição dos resultados esperados para o processo de Medição.Fonte: SOFTEX(SOFTEX, 2009e). 2.2.3 E - Parcialmente Definido A padronização dos processos da organização é o objetivo do nível E do MR- MPS. Com auxílio da definição de processos padrão, determinados a partir dos processos e melhores práticas já constituídas na empresa, os processo dos níveis G e F são acionados no nível E, com uma evolução do processo de Gerência de Projetos. Os processos do nível Parcialmente Definidos são:
    • 58 • Avaliação e Melhoria do Processo Organizacional: possui a tarefa de averiguar a real contribuição dos processos ao objetivo da organização, e também apoiar e planejar novas melhorias nos processos; • Definição do Processo Organizacional: o propósito deste processo é estabelecer e manter os processos da organização usáveis e projetos da empresa; • Gerência de Recursos Humanos: é responsável por abastecer a organização com RH suficiente para que a organização possa manter seus projetos, procurando pessoas capacitadas a diversos setores. SOFTEX (2009f apud ISO 9001:2000) afirma que “Dessa forma, as pessoas que executam atividades relacionadas aos processos devem ser competentes com base em educação, treinamentos, habilidades e experiências apropriadas”; • Gerência de Reutilização: tem o propósito de organizar os ativos que possam ser reutilizados. Segundo a SOFTEX (2009f apud KRUEGER, 1992) “A Reutilização de Software é a disciplina responsável pela criação de sistemas de software a partir de software preexistente”. Neste nível, para garantir a institucionalização dos processos e a correção no seu uso, deve se institucionalizar a gerência de recursos humanos por meio da identificação, desenvolvimento e/ou contratação de indivíduos que possuam conhecimentos e habilidades necessárias para atender os objetivos estratégicos da organização. Essa gerência de recursos humanos envolve também a identificação e realização de treinamentos que devem estar sob a responsabilidade da organização e não, apenas, sob a responsabilidade pessoal dos colaboradores ou dos projetos específicos, SOFTEX (2009f). Para que possa garantir o capital intelectual, é cobrado todo o conhecimentonecessário para executar os processos da organização, e uma nova estratégia de reutilização deprodutos é utilizada.2.2.4 D - Largamente Definido No Nível D, não são encontradas evoluções de processo do seu nível antecessor;modificações nos atributos dos processos não são encontradas; nos que já foram aplicados naorganização continua com mesma capacidade; portanto são apenas acionados novos cincoprocessos. A SOFTEX (2009g) afirma que “Desenvolvimento de Requisitos (DRE), Integração
    • 59do Produto (ITP), Projeto e Construção do Produto (PCP), Validação (VAL) e Verificação(VER), juntamente com a Gerência de Requisitos (GRE), são geralmente mencionados comosendo relacionados à engenharia do software propriamente dita”, os quais serão mencionados aseguir: • Desenvolvimento de Requisitos: com finalidade de definir os requisitos do cliente, do projeto e processo, são analisadas as necessidades e restrições do cliente. Após as informações, são filtradas e documentadas criando os requisitos funcionais e não- funcionais; • Integração do Produto: tem por finalidade apresentar os requisitos que são correspondentes ao ambiente equivalente e que façam a integração do produto; • Projeto e Construção do Produto: após os requisitos de um projeto que já esteja desenvolvido com suas mudanças controladas e gerenciado apropriadamente, entra em ação o projeto e construção com o objetivo de promover soluções entre várias, satisfazendo aos requisitos; • Validação: Visa a qualidade e segurança do produto junto ao cliente para que possa validar os itens que foram descritos no levantamento de requisitos; • Verificação: são modos de averiguar os serviços e os produtos desenvolvidos, para que garanta os requisitos.2.2.5 C – Definido Como acontecido na evolução da maturidade do nível E para o D, que não houvealteração nos atributos já implantados, também não são modificados os atributos que foramadicionados no nível D para o nível C, apenas são adicionadas novos processos. Segundo aSOFTEX (2009h) “A evolução para o nível C do MR-MPS implica, portanto, apenas nadefinição e implementação de três novos processos com a mesma capacidade dos processos jáimplantados: Gerência de Decisões (GDE); Desenvolvimento para Reutilização (DRU); eGerência de Riscos (GRI)” conforme descrito abaixo: • Desenvolvimento para Reutilização: com o propósito de identificar a reutilização em ativo reutilizável, qualquer artefato de software pronto pode ser reutilizado na organização.
    • 60 • Gerência de Decisões: tendo como intuito analisar as decisões críticas com solução de processo formal que atenda a várias demandas do envolvidos; • Gerência de Riscos: são aplicados nos projetos e na organização para controle de riscos e redução sucessiva dos mesmos. Os riscos podem ser: pessoal, insuficiente, cronograma, orçamento mal feito, mudanças nos requisitos, processos produzidos erroneamente e as telas para usuário inadequadas entre outras.2.2.6 B - Gerenciado No nível B, a organização já tem todos os seus processos definidos eimplementados. Utilizando em seus projetos a prática da engenharia de software, iniciado nestenível, a organização já consegue ter uma visão quantitativa do desempenho de seus processos,auxiliando assim para a melhor direção e para a qualidade de todo o serviço e produtodesenvolvido. É importante se ter em conta que, ao se implementar os níveis anteriores, em especial o processo Medição, já se deve preparar o caminho para a implementação do nível B, por meio de uma escolha adequada das medidas. Também se deve ter em conta a impossibilidade de realizar mudanças radicais nos processos para se poder utilizar a base histórica de medidas na análise da estabilidade dos processos. (SOFTEX, 2009i).2.2.7 A - Em Otimização No nível A, o grau Máximo da maturidade do modelo do MR-MPS tem comoprincipal foco a melhoria contínua dos processos. Para isso, utiliza os processos do nível B comoconjunto estatístico para apoiar as alterações e adaptações incrementais, inovadoras etecnológicas, para que possam atender os objetivos de projetos mais ousados e complexos que aempresa possa adquirir. Neste nível, o melhoramento é implementado de forma proativa econtínua. Os melhoramentos são adicionados no processo, de forma que os riscos de insucessossão mínimos, antes que sejam aplicadas avaliações. Com base nesses resultados, são estudadasmudanças para que possam atingir uma qualidade, e principalmente o desempenho maior emmenos tempo.
    • 61 No nível A do MR-MPS, as melhorias de processos e de tecnologias são selecionadas e implementadas nos processos selecionados para controle estatístico, como forma de contribuir para o alcance de objetivos de melhoria de processo. Nesse nível, melhorias de processo e de tecnologias devem ser identificadas de tal forma que, quando implementadas, removam causas comuns de variação de processo, causas raiz de defeitos e outros problemas. (SOFTEX, 2009j)2.3 Método de Avaliação (MA-MPS) O Método de Avaliação é a parte responsável em descrever as formas deavaliações, métodos e processos, os quais as organizações terão que se submeter para que possaverificar maturidade que os processos de desenvolvimento de software estão localizados nosníveis estabelecidos no Modelo de Referência (MR-MPS). Os requisitos do MA-MPS são baseados nos requisitos do método de avaliação definidos na norma ISO/IEC 15504-2, os requisitos definidos no ARC do CMMI e os requisitos específicos do Projeto MPS.BR. Desta forma, o método é compatível com a ISO/IEC 15504 e ARC do CMMI, e adequado às pequenas e médias empresas (WEBER, 20--b). As definições para o método é uma conjuntura a qual a organização ou umaunidade será avaliada objetivamente em relação aos processos de software produzidos. Com umaestrutura vinda da avaliação, é concedido um nível de maturidade aplicável a indústria desoftware; e o fator diferencial é a utilização de empresas de todos os tamanhos. Segundo contidono guia de avaliação da SOFTEX (2009b), para que uma avaliação seja bem conduzida eestabelecida com êxitos, é relevante os seguintes critérios: Comprometimento do patrocinador,Motivação, Fornecimento de feedback, Confidencialidade, Percepção dos benefícios,Credibilidade, os quais estão descritos: • Comprometimento do patrocinador: assegura que as metas sejam atingidas com apoio nos recursos necessários para a implementação da avaliação; • Motivação: a organização tem um papel importante para motivar seus colaboradores, de maneira a torná-los mais construtivo;
    • 62 • Fornecimento de feedback: é uma abertura que possa estimular o comentário produtivos dos resultados decorrentes durante as avaliações, para que a mesma seja convincente para a organização; • Confidencialidade: muito importante durante a avaliação da contratada, pois os entrevistados e os entrevistadores não podem comentar as informações obtidas e cedidas pelas partes integrantes, possibilitando que os entrevistados possam se sentirem à vontade para expressar suas indagações, principalmente todos os documentos cedidos pela organização que são sigilosos; • Percepção dos benefícios: diretamente ou não os benefícios irão acontecer e os membros das organizações deverão perceber; • Credibilidade: todos os que fazem parte da organização contratada devem entender que ganhará mais produtividade, qualidade e lucro sobre o resultado obtido. Para isso, a confiança nos avaliadores é crucial. Segundo a SOFTEX (2009b), O processo de avaliação é formado de quatrossubprocessos: Contratar a avaliação; Preparar a realização da avaliação; Realizar a avaliaçãofinal; e documentar os resultados da avaliação, os quais são formados por atividades descritas portarefas.
    • 63 Quadro 9: Descrição dos processos de avaliação Fonte: ULBRA < www.softex.br> O quadro 9 descreve os processos e as atividades, onde tais informações sãoencontradas no guia de avaliação (SOFTEX, 2009b), o qual contém itens e subprocessos como:Contratar a avaliação; Preparar a realização da avaliação; realizar a avaliação final; e documentaros resultados da avaliação de cada processo com suas atividades equivalentes.
    • 642.4 Modelo de Negócio (MN-MPS) O MN-MPS descreve como serão as execuções das regras de negócios do projetopara cada organização, as quais serão implantadas depois de avaliada. Segundo um documento denegócio disponibilizado pela SOFTEX(2009c) “é observado que a instituição avaliadora nãopoderá ser a mesma que implementou o Modelo MPS.BR na empresa”, ou seja (II) instituiçõesimplementadoras para o discernimento do projeto na empresa; e uma (IA) instituição avaliadora. O Modelo de Negócio MN-MPS descreve as regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras (II), avaliação seguindo o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de empresas pelas Instituições Organizadoras de Grupos de Empresas (IOGE) para implementação do MR-MPS e avaliação MA-MPS, certificação de Consultores de Aquisição (CA) e programas anuais de treinamento do MPS.BR por meio de cursos, provas e workshops(SOFTEX, 2009ª, pag. 14).Figura 15: Descrição dos processos do Modelo de Negocio (MN-MPS.BR)Fonte: SOFTEX < http://www.softex.br/portal/softexweb/uploadDocuments/MN-MPS.pdf> O modelo de negócio pode ser de duas formas: específico, quando ele édirecionado para apenas uma organização; ou Cooperado, quando ele é direcionado para umgrupo de empresas que queiram a certificação do projeto, o qual pode ser com auxilio de umAgente da SOFTEX. No Modelo de Negócio Específico para uma Empresa (MNE-MPS.BR), cada empresa interessada na implementação do Modelo MPS.BR, negocia e assina um contrato
    • 65 específico com uma das Instituições Implementadoras do Modelo MPS (II-MPS.BR); no Modelo de Negócio Cooperado em Grupo de Empresas (MNC-MPS.BR), o primeiro passo é a constituição de grupo de empresas comprometidas com a implementação e avaliação do Modelo MPS.BR (o que pode acontecer, por exemplo, por iniciativa de um Agente SOFTEX) (SOFTEX, 2009c). Para as organizações que optem na forma de grupo, o documento especifica que acontratação pode ser de duas formas, quando a empresa individualmente contrata uma IA ou ogrupo todo. A coordenação do grupo de empresas negocia e assina um outro contrato com uma IA- MPS.BR para a avaliação das empresas do grupo, observando que a instituição avaliadora não pode ser a mesma instituição que implementou o MR-MPS.BR nas empresas, nem a instituição que organizou o grupo de empresas(SOFTEX, 2009c).
    • 66 2.5 Quadro comparativos entre os modelos MPSBR e CMMI Existem medições entre os dois modelos mais utilizados no Brasil, o MPSBR e o CMMI, segundo Oliveira (OLIVEIRA, 2008) as comparações entre elas são: CMMi MPSBR O modelo de qualidade CMMi é reconhecido O MPS.BR é mais conhecido nacionalmente e na internacionalmente América latina O modelo CMMi envolve um grande custo na No MPS BR o custo da certificação é mais avaliação e certificação do modelo. accessível. No CMMI é necessário investir tempo, geralmente No MPS.BR as Avaliações é bienal nas empresas. para se chegar aos níveis de maturidade mais alto. O CMMi tem um foco global mais voltado para as MPS.BR é um modelo criado em função das empresas de maior porte médias e pequenas empresas CMMi possui cinco níveis de maturidade por MPS BR possui sete níveis de maturidade, onde a estágio e seis na Contínua implantação é mais gradual O CMMI é aceito como maturidade para licitações O MPS.BR é aceito como maturidade para licitações O CMMI torna as empresa competitiva O MPS.BR não torna as empresa competitiva internacionalmente internacionalmente O CMMI não utiliza contrato conjunto de No MPS.BR pode acontecer contrato Cooperado empresas em grupo de empresas que queiram a certificação. Implementação mais complexa Implementação mais simples Desenvolvido pelo Software Engineering Institute- Desenvolvido por algumas instituições brasileiras SEI em 1992 em 2003Quadro 10: comparativos MPSBR e CMMI Figura16: Comparação dos Níveis de Maturidade do modelo MPSBR com o modelo CMMi Fonte: SOFTEX < http://www.softex.br/portal/softexweb/uploadDocuments/MN-MPS.pdf>
    • 673 IMPLANTAÇÃO DO MPSBR NA KMF UMA EMPRESAALAGOANA. Neste capitulo, será abordado como foi a implantação do projeto de melhoria deprocesso de software brasileiro para obtenção do nível F, na empresa alagoana KMF Análise eDesenvolvimento de Sistemas e Websites, o quanto foi árdua a implantação nos seus primórdiose gratificante com sua certificação, a instituição implementadora que implantou o resultadoesperado, juntamente com a equipe de apoio, todos os processo de documentação de umprojeto padrão, mostrando suas etapas como base em um projeto aprovado no nível F, oClippingNews, o software estação TABA, a instituição implementadora a qual ficou responsávelpela avaliação da empresa, e o quadro de funcionários e diretores que forma a empresa KMF3.1 A KMF A empresa alagoana KMF, situada em Maceió, desde 1996, vem atuando nomercado nacional tendo como objetivo de trabalho a análise e desenvolvimento de sistemas,podendo até serem personalizados, contudo apreciando inovações na área de ciências detecnologia da informação. A KMF é integrante do Arranjo Produtivo Local de Tecnologia daInformação de Maceió (APL-TI). Os sistemas de internet produzidos pela organização contêmtecnologias de segurança, alta performance e navegabilidade com o foco em e-commerce, dataminning, data warehousing, e gerencia a recuperação de informações. Todo esse aparato fica adisposição para as empresas que queiram qualidade de gerência e destreza em seus trabalhoscomercias. Com foco na análise e desenvolvimento de sistemas de gerência de informação que utilizem ou venham a utilizar conceitos inovadores nas ciências de tecnologia da informação, a KMF foi inaugurada em 1996, iniciando suas atividades no mercado nacional. A empresa trabalha analisando e desenvolvendo sistemas, para empresas que buscam agilidade em seus negócios. Os sistemas da KMF têm a conectividade e convergência digital em sua análise e implementação, sendo monitorados em todas as etapas, garantindo o cumprimento de prazos e a manutenção dos requisitos sempre com foco na qualidade dos processos.(APL-TI; 200-)
    • 68 Figura 17: Logotipo da empresa KMF. Fonte: KMF < http://www.kmf.com.br/empresa.kmf> Para que possa sustentar um número amplo de clientes, a KMF tem um quadro defuncionários com capacidades para analisar, gerenciar, desenvolver e solucionar possíveisproblemas. Eles são distribuídos na seguinte ordem: cinco são programadores; um é gerente deprojetos; um estagiário; e dois sócios que formam a gerência da empresa. Todos os colaboradorespossuem níveis superiores completos, exceto o estagiário; já os administradores são mestrandosem Modelagem Computacional de Conhecimento da Universidade Federal de Alagoas (UFAL).Desta forma é distribuída a maturidade acadêmica.3.2 A escolha do Nível A procura de um grande salto para o desenvolvimento dos processos e dosprodutos, a empresa KMF iniciava em outubro de 2008 a sua implementação para a melhoria deprocesso de software (MPSBR). Mas inicialmente o plano não foi a de implementar o nível dematuridade F, e sim o nível G, o qual apenas dois processos são cobrados os seus resultados.Segundo a SOFTEX (2009m) a Instituição Implementadora II COPPE/UFRJ, naresponsabilidade do Dr. Reinaldo Cabral Silva Filho, ficou com a incumbência de esclarecer queno nível F, tem a implementação de mais três processos, sendo processos de medição, processosde Gerenciamento de Configuração e processos de garantida da qualidade, nos quais as vantagensseriam mais claras. [...] quando foi no final de 2008, Reinaldo Cabral ele veio para Maceió para pode começar o processo de implantação nas empresas, inicialmente as impressas iam para o nível G, que é o primeiro nível do MPSBR, que no caso tem a gerencia de requisitos e a gerencia de projetos mais no nível bem inicial, e essa era a proposta para as quatro
    • 69 empresas, para elas ao invés de tentarem ir para o nível G já passarem para logo para o nível F, uma das justificativas dele quando ele conversou comigo é que apesar no nível G, já trazer algum tipo de evolução para a empresa é no nível F que elas começam a ter uma percepção, mais aprofundada dos benefícios que a adoção do modelo traz para a empresa, [...] na época o modelo que eles estavam usado para avaliação era o 1.1 e agora tem o mais recente que no nível F, você já tem mais um processo de gerencia de portfólio (SANDNEY; 2010) Figura 18: Logotipo da Instituição Implementadora II COPPE/UFRJ Fonte: http://www.cos.ufrj.br/~ros/imagens/coppe.gif> Diante disso, percebe-se que a mudança do nível G, parcialmente gerenciado parao nível de maturidade F gerenciado, as organizações já conseguem medir melhor os processos.Assim o nível F cederá um apoio maior à gerência para as tomadas de decisões ficarem maisperceptíveis para as utilidades vindas da mudança de níveis.3.3 Viabilização Financeira A empresa KMF, para conseguir uma implantação e posteriormente uma avaliaçãopara, por fim, consolidar a certificação no MPSBR, fez parte do projeto da APL-TI de Maceió,que formou um conjunto de quatro empresas para viabilizar todo o processo de um contratoCooperado, que é formado com duas ou mais empresas que queiram aderir ao programa, recebeuapoio do: SEBRAE, SOFTEX, Banco Interamericano de Desenvolvimento (BID), Fapeal, SECTe a ASSESPRO, dos quais os principais foram o BID, que cedeu toda a linha de financiamento; aSOFTEX fez todo o acordo com o BID; e o SEBRAE custeou parte do projeto. Basicamentedesta forma foi criada a viabilização para a área financeira da aquisição do modelo MPS.BR.
    • 70 Um consórcio formado por 4 empresas da Assespro Alagoas: Inform Sistemas, Jetdata, KMF e NTech iniciaram o programa de certificação MPS.Br. O projeto é uma ação do APL-TI de Maceió, que conta com o apoio do Sebrae, SOFTEX, Assespro e BID (Banco Interamericano de Desenvolvimento). O MPS-Br consiste de uma certificação de qualidade voltado para o processo de produção de software, e as empresas da Assespro serão as primeiras a ter esta certificação em Alagoas. Com o MPS-Br o mercado de software alagoano passa a ter um maior nível de competitividade no mercado Nacional e Internacional(ASSEMPRO;2009). Porém para que pudessem alcançar o nível de maturidade F, foi imposto peloimplementador que as empresas compartilhassem um grupo de apoio que ficasse responsávelpelo processo de Medição, processo da garantia da Qualidade e o processo de Gerência daConfiguração.3.4 O processo de Certificação O processo de certificação envolve várias partes que formam a validação dos projetos, osquais foram submetidos à aprovação da SOFTEX. Nesse processo foram descritas as pessoas que faziamparte, o papel de cada um da equipe que foi formada para a implementação do programa, o fluxo doprocesso do escopo, quais responsáveis desenvolverão e/ou validarão os processos do inicio ao fim, aentrega ao cliente, documentações geradas de acordo com o resultado esperado pelo projeto, Termo deAbertura (Ata de Reunião), definição de escopo, entre outros, o Software de controle do projeto, EstaçãoTaba, quem conduziu a validação e o resultado da avaliação.3.4.1 Equipe e papel na certificação A equipe que passou pela experiência da implementação e certificação foram: ospatrocinadores, Mozart de Melo Alves Junior, Diretor de O&M/Analista de Sistemas, KerchennElteque de Oliveira Pereira, Diretor de Desenvolvimento/Analista de Sistemas, ambos mestrandoem Modelagem Computacional de Conhecimento na UFAL. Lívia Maria Omena da Silva, comPós-graduação em Especialização em Gestão de Projetos em Tecnologia da Informação noCESMAC, foi responsável pela Gerência de Projetos. Sandney Farias da Cunha, implementador do MPSBR, descreveu que a equipe deapoio foi criada para suprir as necessidades das quatro empresas que constituíam o projeto decontrato cooperado. Fizeram parte da equipe: SANDNEY (2010), responsável pela a criação emanutenção da equipe, também e pelo Processo de Medição; Jonas Martins de Lucena, formado
    • 71em análise de sistemas no CESMAC, com a responsabilidade no Processo de Garantia daQualidade; inicialmente Ricardo Rubens Gomes Nunes Filho, com mestrado feito em Campinagrande, devido ter passado para o concurso de docente para a Universidade Federal de Alagoasdo campus de Arapiraca na área de Engenharia de Software, foi substituído por Leonardo MarcelPorto de carvalho, formado em análise de sistemas no CESMAC, responsável com Gerência daConfiguração.3.4.2 Fluxo do processo do Escopo O escopo do projeto na KMF é divido em três fases que descreve o fluxo doprocesso de acordo com a figura 19. Na fase 1, Planejamento do projeto, na fase 2, Análise deprojeto, tendo na última fase a construção, teste e implementação, sendo que a última fase podeser feita em paralelo com a segunda fase, depois da macro-atividade elaborar modelo de análise eprojeto do Software, onde tem como uma das atividade a criação de diagramas de classes emodelo de entidade relacionamento, possibilitando a continuidade do trabalho em paralelo nasduas fases.Figura 19: Escopo do Projeto ClippingNews.
    • 72 Após a documentação produzida pelo gerente de projeto e avaliada pelo Gerentede Qualidade (ver anexo C), o escopo do projeto tem como responsável o Gerente de Projeto. Asatividades referentes ao processo de gerência de qualidade estão no Quadro 7. Se houver não-conformidade no escopo do projeto, é reenviado para gerente de projeto, reiniciando o ciclo.Mesmos procedimentos para os processos pertencentes aos níveis de maturidade G e F; nosquadros de 2 a 8 são descritas as atividades específicas de cada um processo separadamente; noAnexo H, modelo de documento que descreve detalhadamente todos processos do Plano doProcesso do Projeto ClippingNews, um dos projeto certificados pelo MPSBR na empresa KMF,processo demonstrado na figura 19.3.4.3 Documentações Geradas Seguindo o propósito do modelo MPSBR a empresa KMF utiliza váriosdocumentos de formalização com informações necessárias para aprovação do resultado esperadopara a melhoria do processo, definindo as atividades, responsabilidades, recursos, impactos ebenefícios, bem como promovendo informações sobre o andamento do projeto que permitam arealização de correções quando houver desvios significativos no desempenho do projeto. Nosanexos de A até G, serão mostrados alguns modelos de documentos usados na organização KMF,dos quais muitas estão sem dados, pois a intenção é demonstrar o modelo de resultado requeridopelo projeto brasileiro. • O documento de Declaração de Escopo do Projeto tem a finalidade de levantar todas as informações necessárias do cliente para o projeto, assim formará o escopo do projeto informando o que pertence e o que não pertence ao mesmo, importante validação de ambos os lados, pois mudanças podem implicar em impactos no cronograma e no custo do projeto. As informações contidas no documento de declaração de escopo no Anexo A são: os dados das declarações, o nome do projeto, o gerente do projeto, o cliente, o responsável pela declaração do escopo, as revisões do documento, necessidades que o Projeto deve atender, o que afeta, qual o impacto e os
    • 73 benefícios com a solução, gestores e fornecedores de requisitos, os requisitos do cliente, escopo não incluído no projeto, critérios de aceitação, ligações com outros projetos equipe de planejamento do projeto, premissas e restrições.• O Anexo B descreve o Documento do Termo de Abertura, o qual tem o objetivo de autorizar formalmente o início do projeto, contendo as informações do nome do gerente do projeto, do cliente e do responsável pela aberturado do termo. As revisões deste documento descreverão qual a modificação, a data, o responsável e se foi aprovado, apresentando os requisitos do cliente, premissas, restrições, todas as estimativas de tempo que envolvam as pessoas no projeto, que geralmente são os: gerentes de Projeto, analistas de sistema, programador, e por fim, a condução do projeto.• O Laudo de Avaliação da Declaração do Escopo pelo GQPP (ver Anexo C) é um documento padrão que é utilizado pela garantia da qualidade para as várias fases do fluxo do processo; apenas seus dados são substituídos, os quais são usados no: Laudo de Avaliação da Especificação de Requisitos, Laudo de Avaliação do Relatório de Auditoria de Gerência de Configuração, Laudo de Avaliação do Modelo de Análise e Projeto, Laudo de Avaliação do Plano do Processo, Laudo de Avaliação do Relatório de Monitoração, entre ostros; tendo a finalidade de expor as observações dos estudos sobre os processos que registram as conclusões da análise.• No anexo D, o Modelo de Plano de Gerência de Documentos e Comunicação tem o propósito de formalizar o planejamento da comunicação entre os envolvidos no projeto, sendo eles: gerência de alto nível, gerente de Configuração, gerente de Projeto, analista de sistemas, programador, webdesigner, avaliador, gerente de métricas e Cliente.• O Modelo de Controle de Alteração de Requisitos é mais um dos vários documentos gerados para o controle do projeto, apoio e gerência da organização, sendo este direcionado para o controle das mudanças que venham acontecer no projeto. Para apoiar a avaliação, é importante manter a rastreabilidade entre os artefatos produzidos, o que necessita de muita cautela nas modificações que possam ser introduzidas, visto que pode impactar em
    • 74 todo o projeto matriz de rastreabilidade e auxiliar na determinação do impacto no projeto. Segundo CALHAU, ARANTES e FALBO (2008) “Quando uma alteração é feita, deve-se garantir que ela não vai comprometer a integridade de outros artefatos. Assim, é muito importante rastrear artefatos dependentes e indicá-los como elementos a serem analisados em uma alteração”. No Anexo E, é descrito o modelo de Controle de Alteração de Requisitos que contempla as atividades de mudança nos requisitos. • O Documento Modelo de Relatório da Situação dos Processos (ver Anexo F) descreve os dados que foram inseridos no decorrer do controle da qualidade nos processos analisados, as não-conformidades e as Inadequações do processo com as possíveis causas, e quais as ações corretivas. O item do documento (ver Anexo F), que relatas os detalhamentos dos processos avaliados, utiliza a mesma estrutura para os processos de gerência de projetos, gerência de requisitos, gerência de configuração, garantia da qualidade e medição.3.4.3.1 Software Taba A implementação da melhoria do processo, com utilização da ferramenta que nãoé comercializada, utiliza processos aderentes ao CMMI e MPS.BR. A Estação TABA, que é umambiente de desenvolvimento que apóia a execução das tarefas a serem produzidas em umprocesso de software, contém dois tipos de ambientes: o a Ambiente Configurado e o AmbienteInstanciado, os quais são disponibilizados para as empresas. • Ambiente Configurado: são informações padronizadas da organização, processo padrão de desenvolvimento, análise métricas, planejamento e aquisição, entre outros; • Ambiente Instanciado: ambiente responsável em apoiar o planejamento, execução, gerência e controle do projeto do desenvolvimento do software. A Estação TABA é um meta-ambiente capaz de gerar, através de instanciação, ambientes de desenvolvimento de software (ADS) adequados às particularidades de processos de desenvolvimento e projetos específicos. Desta forma, a Estação TABA possui facilidades para a definição de processos, métodos e ferramentas CASE a serem utilizadas no processo de desenvolvimento. Estes elementos estão organizados em um
    • 75 modelo de integração do ambiente, permitindo que diferentes ambientes sejam definidos e instanciados (VILLELA et al; apud TRAVASSOS, 1994). Figura 20: Logotipo do Software Estação TABA desenvolvido na COPPE/UFRJ Fonte: <http://lens.cos.ufrj.br/es/images/stories/taba.jpg> Através do software estação TABA, o gerente de projeto adiciona os itens quefazem parte do plano do processo, registrando o escopo, as características básicas, cronograma,custo do projeto, responsáveis, o papel de cada um na organização, os riscos que possam passaros processos, entre outros. Para cada um desses processos, são utilizadas ferramentas distintas doTABA com todas as informações inseridas no software, sendo possível a geração de relatórios eoutros documentos. No Anexo G, que é um exemplo de documento (Plano do Processo doProjeto ClippingNews), o qual é gerado pelo software estação TABA, descreve os artefatosproduzidos através dos dados alimentados no software dividido por suas fases.3.4.4 Avaliação Após todo o processo de implantação do modelo esperado pela SOFTEX, jáinstalado na organização em dezembro do ano de 2009, foi feita uma avaliação, a qual GiseleVillas Bôas, da Instituição Avaliadora RIOSOFT, foi a líder que conduziu todo o processo.Participaram, também, Marcio Pecegueiro do Amaral, como avaliador adjunto; e doisrepresentantes da organização KMF: Alex Moreira Müller e Sandney Farias da Cunha, quesegundo a SOFTEX (2009L) “[...] a equipe de avaliação concluiu que a organização atendeu aosrequisitos de processos e capacidade do modelo de referência MR-MPS (Guia Geral do MPS.BR- versão 1.2) do nível F – Gerenciado”.
    • 76 A avaliação foi conduzida pela avaliadora líder Gisele Villas Bôas, da Instituição Avaliadora (IA) RIOSOFT - Sociedade Núcleo de Apoio a Produção e Exportação de Software do Rio de Janeiro, CNPJ 86.846.706/0001-94. Com base no método de avaliação MA-MPS (MPS.BR - Guia de Avaliação:2009), a equipe de avaliação concluiu que a organização atendeu aos requisitos de processos e capacidade do modelo de referência MR-MPS (Guia Geral do MPS.BR - versão 1.2) do nível F – Gerenciado (SOFTEX, 2009L) Figura 21: Logotipo da Instituição Avaliadora, RIOSOFT. Fonte: KMF < http://www.riosoft.SOFTEX.br/cgi/cgilua.exe/sys/start.htm?sid=4>3.4.4.1 Resultado A Associação para Promoção da Excelência do Software Brasileiro (SOFTEX;2009n) informou, no dia 1º de dezembro de 2009, à conclusão da avaliação, que certificava a áreade desenvolvimento de software da KMF, para o nível de maturidade F do projeto de Melhoria deProcesso do Software Brasileiro (MPSBR). Em 1º de dezembro de 2009, foi concluída a avaliação dos processos de software da empresa KMF Análise e Desenvolvimento de Sistemas, na unidade organizacional Área de Desenvolvimento de Software, em Maceió-AL, seguindo o método de avaliação MA- MPS. A conclusão da avaliação é que a empresa atende aos critérios do nível F - Gerenciado do modelo de referência MR-MPS. (SOFTEX, 2009m) Com todos os acontecidos, segundo a SOFTEX (2009m), um agradecimento pelacertificação no nível de maturidade F, foi destacado pelo patrocinador da avaliação Mozart deMelo – Sócio Gerente da empresa - o qual citou as seguintes palavras: “Gostaria de agradecer atodos que fazem parte da Instituição Implementadora II COPPE/UFRJ e da InstituiçãoAvaliadora IA RIOSOFT, pelo profissionalismo e comprometimento com todo o processo deimplementação e avaliação MPS.BR”.
    • 77Quadro11: Resultado da AvaliaçãoFonte: SOFTEX (SOFTEX, 2009n) O quadro 11 demonstra quais foram os níveis de processos que a empresa KMFconcluiu na conquista do seleto grupo das organizações certificadas no MPSBR, seguindo aordem do nível G, Parcialmente Gerenciado com os processos de Gerência de Requisitos eGerência de Projetos. O nível F é Gerenciado com os processos de Medição, Gerência deconfiguração, Garantia da Qualidade, ficando fora do escopo o processo de Aquisição.
    • 78CONCLUSÃO Essa pesquisa demonstrou a real condição para que as empresas de desenvolvimentode software de Alagoas busquem, para seus produtos, um grau de aceitação nacional einternacional, com qualidade e produtividade de software e serviços relacionados, através decertificações de produtos. Sabendo-se que o projeto brasileiro (MPSBR) foi criado visando o alcance dasempresas públicas e privadas de diferentes tamanhos, com maior atenção às micros, pequenas emédias empresas, muitas empresas continuam sem condições de implementar um modelo dequalidade de software internacional; ao passo que para a aquisição do MPSBR, os níveis dematuridades são mais suáveis, além do custo e tempo de implantação serem inferiores às normasinternacionais. Essa pesquisa buscou analisar, também, o conceito das normas já vigentes nomercado mundial, especificando as normas CMM, CMMI, ISO/IEC 12207 e a ISO/IEC 15504,descrevendo seus conceitos, suas formações, suas atividades, seus processos e suas maturidades,com o intuito de concretizar a estrutura que é formado o modelo MPSBR, tornando-a bem aceitano comércio mundial. Por fim, foi demonstrado como se realizou a implementação do modelo MPSBR nonível F, na empresa KMF Análise e Desenvolvimento de Sistemas e Websites, onde asdificuldades foram muitas principalmente com relação a incerteza da mudança de nível G paranível F, além disso o fato de mudar paradigmas é muito difícil pois todos que fazem parte doprocesso precisam acreditar que o mesmo, levaria para um caminho de sucesso que o “trabalho”inicial daria bons frutos no final. Após a cerificação do modelo, proporcionou a gerencia da empresa, administrarcom mais facilidade novos projetos, com condições de acompanhar o tempo e cronograma, deobter através da gerencia de métricas relatórios que são decisivos para tomada de decisão, alémde verificar o andamento junto a equipe de desenvolvimento. Não apenas relacionando o fato quea certificação é algum ótimo, mas, de promover a mudança de paradigma dentro da organizaçãotendo a possibilidade de um acompanhamento muito mais detalhado de todos os processos.
    • 79 Diante do exposto, podemos afirmar que é possível melhorar os processos de umaempresa desenvolvedora de software utilizando-se do padrão brasileiro com uma maneira deimplementação mais simplificada e ao mesmo tempo tão eficiente quanto os padrõesinternacionais. Portanto foi demonstrado que é possível a viabilidade para uma empresa alagoanabuscar algo que é realidade no mercado, porém pouco procurado, por medo no investimento, porfalta de estrutura e de qualidade. No entanto as empresas, em virtude do que foi mencionadoanteriormente, esquecem de todos os benefícios provindos da certificação, que propiciaria àempresa um bom retorno financeiro e uma ótima estrutura interna com qualidade e produtividade,enfatizando, assim, a possibilidade tangível para que as empresas busquem semelhantecertificação.
    • 80REFERÊNCIASALEXANDRINI, Fábio; SIEVES, Diego Adriano; MEURER, Evandro; STEINHAUSER, PauloLuis; SCHLICKMANN, Rodrigo. Perfil das Empresas de Software na Adoção do CMM –Capability Maturity Model. 2006 Disponível em <http://www.aedb.br/seget/artigos06/861CMM_seget.pdf.> Acessado em: 09 Maio. 2010.ASSESPRO, Associação das Empresas Brasileiras de Software e Serviços e Serviços deInformática, Publicação da certificação da empresas de Alagoas, 2009.Disponível em <http://www.assespro-al.org.br/portal/index.php?=com_letterman&task=view&id=84> Acessado em: 13 Mar. 2010APL-TI, Arranjo Produtivo Local de Tecnologia da Informação “Catálogo tecnologia dainformação em Maceió”, 200-, Disponível em < http://www.apltimaceio.com.br/catalogodigital/software.php?id=13> Acessado em: 03 Junho. 2010Calhau, R. F.; Arantes,L. O.; Falbo, R. A. “Uso de Gerência de Conhecimento para Apoiar aRastreabilidade e a Avaliação de Impacto de Alterações” in “XXII Simpósio Brasileiro deEngenharia de Software”. 2008, Disponível em <http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2008/016.pdf>Acessado em: 03 Junho 2010.CUNHA, Sandney F. Certificação MPSBR nível F na empresa Alagoana KMF:entrevista,[Maio 2010] Entrevistador: Adson Wendel C. Ferreira. Maceió. MP3. Entrevistaconcedida a monografia melhoria de processo de software brasileiro aplicado no nível dematuridade f em uma empresa alagoana desenvolvedora de software.GUSMÃO, Cristine Gomes de; MOURA, Hermano Perrelli. Gerencia de Risco em Processosde Qualidade de Software: Uma análise Comparativa. 2004. P.6 Disponível em<http://www.cefetrn.br/~placido/disciplina/pgp/material/sbqs05_Gusmao.pdf>Acessado em: 19de Mar 2010International Organization for Standardization (ISO). “ISO/IEC 12207:1995/Amd 1:2002:Information technology -- Software life cycle processes”. ISO/IEC International Standard,2002.ISO/IEC 15504 –1 Information Technology – Process Assessment, - Part 1:Concepts andVocabulary, 2003
    • 81JAGUARIBE, M. E. A; MARIANO, Luiz G. F. “Determinação da Maturidade de Processosem Empresas Certificadas pela NBR ISO 9001:2000, Como um Indicador da Gestão porProcessos”. Disponível em <www.aedb.br/seget/artigos06/821_art-capabilidade_de_processos-arquivo%20-seget.pdf> Acessado em: 09 Junho de 2010.LAHOZ, CARLOS; SANT’ANNA, NILSON. “Os Padrões ISO/IEC 12207 e 15504 e aModelagem de Processos da Qualidade de Software” Disponível em<http://www.scribd.com/doc/12714054/Os-Padroes-ISOIEC-12207-e-15504-e-a-Modelagem-de-Processos-da-Qualidade-de-Software> Acessado em: 13 de Maio 2010MACHADO, CRISTINA ÂNGELA FILIPAK in WEBER, KIVAL CHAVES. “Qualidade eProdutividade em Software”, São Paulo, Ed. Makron Books, 2001a.MACHADO, C.A.F; BURNETT, R.C. “Gerência de Projetos Na Engenharia de Software emRelação as Práticas ao PMBOK”, 20-- Disponível em <http://celepar7cta.pr.gov.br/portfolio.nsf/0/617e42000235b79703256c08006afbc1/$FILE/_h8tin523ecdkm2834ckg70sjfd9in8rrj8pkmsobc_.doc > Acessado em: 08 Junho. 2010.MCT ,Ministério da Ciência e Tecnologia. Produtividade Sistêmica: Resultados da pesquisa2001, 2001. Disponível em <http://www.mct.gov.br/index.php/content/view/4807.html.> Acessado em: 20 Jan. 2010.MARÇAL ,Ana Sofia C.Estendendo o SCRUM segundo as Áreas de Processo deGerenciamento de Projetos do CMMI.2007 Disponível em <http://www.cesar.org.br/files/file/SCRUMxCMMI-CLEI-2007.pdf.> Acessado em: 08 Junho de2010.MANERA, A. F;TSURUDA,S. ;ABRAHÃO,B. T. ;MODA, C. S. ;GRACIOSO,C. V.;MACEDO,D. C. ;MAROLA,L. F. P. ;ZERBINATO, M. C. ;TSURUDA,R. ;Silva, S. R.;FERREIRA,T. T.;LAZARINI, T. B. ;PETRUCCELLI,T. H. “Modelo de Qualidade – CMMI”,2007, Disponível em < http://www2.comp.ufscar.br/~bruno_abrahao/Artigos/CMMI.pdf>Acessado em: 08 Junho. 2010.OLIVEIRA, C. S. “Comparando CMMi x MPS. BR: As Vantagens e Desvantagens dosModelos de Qualidade no Brasil”, 2008. Disponível em: <http://www.camilaoliveira.net/Arquivos/Comparando%20CMMi%20x%20MPS.pdf >. Acessadoem: 25 de Maio de 2010.
    • 82PÊSSOA, Marcelo Schneck de Paula. Modelo Integrado de Maturidade daCapacidade de Processo. Lavras: UFLA/FAEPE, 2005. Disponível em <http://www.ulbra-to.br/eventos/encoinfo/2009/Anais/Qualidade_de_Software.pdf> Acessado em: 17 de Mar 2010PRIKLADNICKI , rafael. BECKER, carlos alberto. YAMAGUTI, Marcelo hideki. UmaAbordagem para a Realização de Diagnóstico Inicial em Empresas que Implementam oMPS.BR. In PROQUALITI, Qualidade na Produção de Software, 2005 Disponível em<http://www.proqualiti.org.br/revista/revista_ProQualiti_nov 2005.pdf> Acessado em: 20 Jan.2010.RINCON,ANDRÉ MESQUITA;Qualidade de Software.2009 Disponível em <http://www.ulbra-to.br/eventos/encoinfo/2009/Anais/Qualidade_de_ Software. pdf > Acessadoem: 14 de Maio 2010REZENDE, Denis Alcides. Engenharia de Software e sistemas de informação. 2. ed. Rio deJaneiro: Brasport, 2002.RESENDE, Denia Kuhn; GREGO, João Batista; PIMENTEL, Neide; GONÇALVES, CleomarAparecido; NEVES, Edson; VIEIRA, Junior; FERREIRA, Ariel Crezo; KRUEL, Fabricio;BATISTA, Paulo Roberto Júnior; CARDOSO, Olavo Terra Neto; CAVALCANTI, Walison;GODINHO, Henrique; MONTONI, Mariano; NUNES, Elaine; BARRETO, Andrea; REGINA,Ana; ROCHA, Cavalcanti da.Implementação do MPS.BR Nível F e CMMI-DEV Nível 2 naRed & White IT Solutions. In WAMPS 2009-V Workshop Anual do MPS. 2009 Disponível em<http://www.softex.br/portal/softexweb/UploadDocuments/Softex%20WAMPS%202009%20Web.pdf. > Acessado em: 14 de Mar 2010SANTANDER, V. F. A; VASCONCELOS. A. M.L “Mapeando o Processo Unificado emRelação ao CMM – Nível 2”, 20--. Disponível em <http://www.qualiti.com.br/artigos/RUPxCMM .pdf > Acessado em: 08 Junho. 2010.SILVA, DIEGO BATISTA; ANDRADE, ROBERTO A. DE FILHO; PIMENTEL, R.GUEDES.Uma análise das recomendações dos níveis G e F do MPS.BR para aimplementação do programa de qualidade, 2008. Disponível em <http://www.cci.unama.br/margalho/portaltcc/tcc20081 s/pdf /tfg1032008.> Acessado em: 09Maio. 2010.
    • 83Silva, Lívia M. O; “Aplicando MR-MPS nível F na melhoria do processo dedesenvolvimento de software segundo à perspectiva da gerência de projetos de umamicroempresa de Maceió”2009.Silva, A. C. "MR mps BR – Modelo de referência para melhoria do processo de softwarebrasileiro", 20--. Disponível em <http://www.uniplandf.edu.br/revista/vol1n4.pdf#page=4>Acessado em: 18 Maio 2010.SOFTEX, Associação para Promoção da Excelência do Software Brasileiro, Avaliações MPSPublicadas, 2010. Disponível em <http://www.softex.br/mpsbr/_avaliacoes /avaliacoes_mpsbr_total.pdf >Acessado em: 14 Fev. 2010ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia Geral”, 2009. Disponível <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf>.Acessado em 25 de Maio de 2010, 2009a.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Avaliação”, 2009. Disponível <http://www.softex.br/mpsbr/_guias/guias/MPSBR_Guia_de_Avaliacao_2009.pdf>.Acessado em 25 de Maio de 2010, 2009b.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Modelo de Negócio para Melhoria de Processo de Software(MN-MPS.BR) ResumoExecutivo”, 2009. Disponível < http://www.softex.br/portal/softexweb/upload Documents/MN-MPS.pdf>.Acessado em 21 de Maio de2010, 2009c.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias /MPS.BR_Guia_de_Implementacao_Parte_1_2009.pdf >.Acessado em 25 de Maio de 2010, 2009d.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 2: Fundamentação para Implementação do Nível F doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias /MPS.BR_Guia_de_Implementacao_Parte_2_2009.pdf >.Acessado em 25 de Maio de 2010, 2009e.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 3: Fundamentação para Implementação do Nível E doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias/ MPS.BR_Guia_de_Implementacao_Parte_3_2009.pdf >.Acessado em 25 de Maio de 2010, 2009f.
    • 84ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 4: Fundamentação para Implementação do Nível D doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias /MPS.BR_Guia_de_Implementacao_Parte_4_2009.pdf >.Acessado em 25 de Maio de 2010, 2009g.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 5: Fundamentação para Implementação do Nível C doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_5_2009.pdf >.Acessado em 25 de Maio de 2010, 2009h.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 6: Fundamentação para Implementação do Nível B doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_6_2009.pdf >.Acessado em 25 de Maio de 2010, 2009i.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Guia de Implementação – Parte 7: Fundamentação para Implementação do Nível A doMR-MPS”, 2009. Disponível < http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_7_2009.pdf >.Acessado em 25 de Maio de 2010, 2009j.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Avaliação de Processos de Software”, 2009. Disponível <http://www.softex.br/portal/softexweb/uploadDocuments/Declara%C3%A7%C3%A3o%20Avalia%C3%A7%C3%A3o%20MPS-F%20KMF%20011209.pdf>.Acessado em 06 de Junho de 2010, 2009l.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Avaliação MPS, nível F, na KMF em Maceió”, 2009. Disponível<http://www.softex.br/portal/softexweb/uploadDocuments/Press%20Release%20KMF%20MPS-F%20011209_v03fev10.pdf>.Acessado em 06 de Junho de 2010, 2009m.ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO“Resultado de Avaliação de Processos de Software”, 2009. Disponível<http://www.softex.br/portal/softexweb/uploadDocuments/Resultado_de_avaliacao%20MR%20MPS%20KMF.pdf>.Acessado em 06 de Junho de 2010, 2009n.
    • 85VILLELA,K; SANTOS,G.; GALLOTA ,C.; MIRANDA,R.; NEGRÃO ,R. ;FARIAS,L.;ZLOT,F.; BARCELOS,M.; SCHNEIDER,L.; MAFRA,S.; SALVADOR,B. G.; OLIVEIRA,K.;TRAVASSOS,G. H.; ROCHA, A. R. Estendendo a Estação TABA para a criação deAmbientes de Desenvolvimento de Software Orientados a Organização Disponível em <http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2001/022.pdf> Acessado em: 03 Junho. 2010.Weber, Kival Chaves; Araújo,Eratóstenes; Machado, Cristina A. Filipak;Scalet, Danilo;Salviano, Clênio F.; Roch, Ana Regina . “Modelo de Referência e Método de Avaliação paraMelhoria de Processo de Software - versão 1.0 (MR-MPS e MA-MPS)” in “ IV SimpósioBrasileiro de Qualidade de Software”. Disponível em < http://www.softex.br/portal/softexweb/uploadDocuments/MR_MA-MPS.pdf>Acessado em: 14 Maio 2010, 20--a.WEBER, Kival C.; ROCHA, Ana Regina; ALVES, Ângela; AYALA, Arnaldo M.;GONÇALVES, Austregésilo; PARET, Benito; SALVIANO, Clênio; MACHADO, Cristina F.;SCALET, Danilo; PETIT, Djalma; ARAÚJO, Eratóstenes; BARROSO, Márcio Girão;OLIVEIRA, Kathia;OLIVEIRA, Luiz Carlos A.; AMARAL, Márcio P.; CAMPELO, RenataEndriss C.; MACIEL,Teresa. Modelo de Referência para Melhoria de Processo de Software:uma abordagem brasileira. Disponível em < http://pos.facom.ufu.br/~willian/uniube/eng_software/arteng2.pdf.> Acessado em: 20 Jan. 2010, 20--b.Weber, K.; Araújo, E.; Rocha, A. R.; Oliveira, K.; Rouiller, A. C.; Wangenheim, hristiane G;Araújo, R.; Salviano, C.; Machado, Cristina F.; Scalet, D.; Galarraga, O.; Amaral, Márcio P.;Yoshida ,D. “Melhoria de Processo do Software Brasileiro (MPS.BR): um ProgramaMobilizador ”, 20-- .Disponivel em :< http://portalrevistas.ucb.br/index.php/teste/article/viewFile/930/818> Acessado em 25 de Maio de 2010, 20--c.
    • 86 ANEXO Anexo A - Modelo de Declaração de Escopo do Projeto DECLARAÇÃO DE ESCOPONome do Projeto: ClippingNewsGerente de Projeto: Lívia OmenaData de criação: 21/01/09Cliente: KMFResponsável: Mozart Melo Revisões deste documentoData Comentário Autor21/01/09 Criação do documento. Lívia27/01/09 Ajustes no documento devido ao laudo do GQPP. Lívia Necessidades que o Projeto deve atenderA necessidadeAfetaO seu impacto éBenefícios com a solução Objetivos do Projeto Gestores e Fornecedores de RequisitosRepresentante Mozart MeloFunção/Unidade Gerente de O&M/KMFPapel Cliente Requisitos do ClienteCódigo Requisito DescriçãoRC01 Criar e enviar newsletter para divulgação de O software disponibilizará alguns modelos para informações sobre produtos e serviços. composição de newsletter. A newsletter será composta de texto e imagem. UsuáriosTipo Descrição Atividades previstas no sistema (Continuação)
    • 87 Anexo A - Modelo de Declaração de Escopo do Projeto (Continuação) Escopo Não Incluído no ProjetoNão será feita a inclusão de áudio e vídeo na composição da newsletter. Critérios de Aceitação Ligações com outros projetosEste projeto não possui ligações com outros projetos. Equipe de Planejamento do ProjetoID Nome Papel01 Lívia Omena Gerente de Projetos02 Kerchenn Elteque Gerente de Desenvolvimento/Analista de Sistemas03 Mozart Melo Gerente de O&M/Analista de Sistemas PremissasO servidor de email e web devem estar funcionando.O cliente deve possuir conexão com a internet.O usuário deverá informar o login e senha. RestriçõesEquipe formada por 1 gerente de projetos...
    • 88Anexo B - Modelo de Termo de Abertura do Projeto TERMO DE ABERTURA DO PROJETO Nome do Projeto: Gerente de Projeto: Cliente: Responsável: Revisões deste documento Versão Modificações Data Responsável Aprovação Justificativa do Projeto A necessidade Benefícios com a solução Requisitos do Cliente Código Requisito Descrição RC01 Premissas Restrições Estimativa Tamanho do projeto Fator de Produtividade Esforço Previsto (Homem/Hora - hh) Prazo Estimado (Dias úteis) Papel Quantidade Diária de Horas Gerente de Projetos Analistas Programador Média diária de horas de trabalho da equipe Condução do Projeto A execução das atividades do projeto irá requerer a participação e o envolvimento do cliente. Durante a realização do projeto será solicitado ao cliente um aval com relação aos produtos de trabalho intermediários elaborados, onde deverá externar sua opinião informando se está ou não de acordo com o item apresentado. A seguir, os itens que o cliente deverá se comprometer: Declaração de Escopo; Plano do Projeto; Especificação de Requisitos; Registro de Aceite do Produto. Quando houver necessidade de mudanças, o líder do projeto realizará uma avaliação de impacto para subsidiar a decisão de contemplar a mudança. Modificações no projeto poderão implicar a reavaliação de alguns itens (Ex.: Plano do projeto com o cronograma alterado; Especificação de requisitos acrescida de novas funcionalidades etc.). O acompanhamento das atividades do projeto poderá ser realizado através do cronograma e as alterações relevantes no plano do projeto serão informadas para que o cliente fique ciente da situação.
    • 89 Anexo C - Modelo de Laudo de Avaliação da Declaração do Escopo pelo GQPP Laudo de Avaliação da Declaração do Escopo pelo GQPP Projeto ClippingNews Responsável Lívia Omena Empresa KMF Versão do Roteiro: 1.0 Controle de Versão do DocumentoVersão Modificação Data Responsável 0.1 Documento criado 10/02/2009Resultado:Data da avaliação 11/02/2009 Início: 11:00 Fim: 11:30 Duração: 0,50 Núm. da 2a Avaliação Resultado Aprovado com Modificações AvaliaçãoProdutos Avaliados: Produto Estrutura Analítica do Projeto Situação Plano Ação Aprovado Produto Plano da Organização Situação Plano Ação Definido Configurações: A partir daqui, as células não devem ser editadas ou impressas para o bom Observação: funcionamento da avaliação. Escala Número da Avaliação Itens 1a Avaliação 2a Avaliação 3a Avaliação 4a Avaliação Escala Resultado da Itens Aprovado Avaliação Aprovado com Modificações Rejeitado Escala Situação do Plano de Itens Definido Ação Em execução Finalizado Aprovado Cancelado Configurações Definido Script Em execução Finalizado Aprovado Cancelado
    • 90Anexo D - Modelo de Plano de Gerência de Documentos e Comunicação PLANO DE GERÊNCIA DE DOCUMENTOS E COMUNICAÇÃONome do Projeto:Gerente de Projeto:Cliente:Responsável: Modificações Data Responsável Aprovação Legenda A Avalia o produto GAN Gerência de Alto Nível P Participa GC Gerente de Configuração C Comunicado sobre o produto GP Gerente de Projeto R Responsável pela produção AS Analista de Sistemas D Destinatário do produto P Programador F Fornece informação para gerar o W Webdesigner produto GQPP Avaliador GM Gerente de Métricas Cl ClienteFreqüência Periodicidade que o produto é criado, atualizado e comunicado (Fase 1, Fase 2, Fase 3, Ao longo das fases e No final de cada fase). INTERES- Método Fre-SADOS de GAN Cl GP AS P GQPP GC GM Mídia qüên- Comuni- ciaPRODUTOS cação
    • 91Anexo E - Modelo de Controle de Alteração de Requisitos Controle de Alteração de Requisitos Nome do Projeto: Gerente de Projeto: Cliente: Responsáveis: Revisões deste documento Versão Modificações Data Responsável Controle de Alteração de Requisitos Solicitação de Alteração Solicitante: Organização do Solicitante: Registrado Por: Data: Descrição da Solicitação: Justificativa: Urgência da Solicitação: ( ) Pequena ( ) Média ( ) Alta ( ) Altíssima Análise de Impacto Responsável: Data: Impacto em Tempo, Esforço e Custo: Casos de usos que serão incluídos/alterados/excluídos Outros Impactos: Itens a serem Alterados/Criados/Excluídos Nome Versão Descrição da Alteração Avaliação de Solicitação de Alteração Responsável: Data: Decisão: ( ) Aprovado ( ) Não Aprovado ( ) Postergado Justificativa para Decisão: Itens efetivamente Alterados/Criados Nome Versão Descrição da Alteração Verificação da Implementação da Solicitação de Alteração Responsável: Data: Resultado: ( ) Aprovado ( ) Não Aprovado Observações
    • 92Anexo F - Modelo de Relatório da Situação dos Processos RELATÓRIO DA SITUAÇÃO DOS PROCESSOS Responsável: Jonas Lucena Mês de Referência: 10/2009 Controle de Versão do Documento Versão Modificações Data Responsável 0.1 Versão inicial. 21/07/2009 Jonas Lucena 1. Objetivo O objetivo do Relatório da Situação dos Processos é relatar a situação dos processos de softwareem relação à aderência e à adequação dos processos no período. 2. Resumo dos Processos Avaliados Processo Situação Gerência de Projetos Gerência de Requisitos Gerência de Configuração Garantia da Qualidade Medição Legenda: Não foram identificados problemas no processo. Foram identificados problemas no processo e estes foram solucionados. Ainda existem problemas no processo não solucionados. Não avaliado no período. 3. Projetos Avaliados Projeto Cliente Gerente de Projeto O projeto foi finalizado e suas respectivas informações se ClippingNews Lívia Omena encontram em relatórios anteriores. As não-conformidades informadas no relatório anterior foram solucionadas.
    • 934. Projetos Não-avaliados Projeto Responsável Observação5. Detalhamento dos Processos Avaliados 5.1 Gerência de Projetos Aderência ao ProcessoAs atividades da Gerência de Projetos estão sendo executadas conforme descriçãonos Planos do Processo dos Projetos. Alguns artefatos tiveram que ser avaliadosmais de uma vez, pois apresentaram não-conformidades que tiveram de sertratadas. Segue abaixo, em síntese, algumas não-conformidades encontradas nosartefatos avaliados. Todas as não-conformidades abaixo já foram solucionadas. Não-conformidades (N.C.) Análise de possíveis causas (A.P.C.) /sugestões (S.)Projeto Controle de FichasArtefato: Declaração deEscopo do Projeto e Estrutura (A.P.C.): Erros de digitação;Analítica do Projeto. (S.): Revisão do(s) documento(s) antes de enviá-lo para(N.C.): Os documentos avaliação, minimizando o número de erros possíveis;apresentaram errosortográficos e/ou gramaticais. Inadequações do processo encontradas no período Inadequações Análise de possíveis causas Não foram identificadas - Plano de Ação Problema Ação Responsável Prazo para resolução Não há. Não há. - -
    • 94Anexo G - Plano do Processo do Projeto ClippingNews ClippingNews KMF Análise e Desenvolvimento de Sistemas e Websites Plano do Processo do Projeto ClippingNewsCiclo de DesenvolvimentoFASE 3 - CONSTRUÇÃO, TESTES E IMPLANTAÇÃO Artefato Produzido Atividade Artefatos Não se Sim Não AplicaRefinar oplanejamento pararealização da fase Plano do Projeto Artefatos Produzidos:Refinar Plano do ProjetoPlanejamento • Versão 5 em 28/07/2009 (PlanoProjeto_20090209_ProjetoClippingNews.rar) Laudo da Avaliação do Plano do Projeto Artefatos Produzidos:Avaliar Plano do Laudo da Avaliação do Plano do ProjetoProjeto • Versão 1 em 27/07/2009 (LaudoAvaliacaoPlanoProjeto_20090210_ProjetoClippingNews.xls) Plano de Ação Não foram produzidos artefatos. Registro de Comprometimento Artefatos Produzidos:ObterComprometimento Registro de comprometimento com a Declaração de Escopo do Projeto.com o Plano do • Versão 1 em 27/07/2009Projeto (RegistroComprometimentoEscopo_20090127_ProjetoClippingNews.pdf)Monitorar oProjeto ao longoda Fase Plano de AçãoMonitorarAndamento do Não foram produzidos artefatos.Projeto Plano do Projeto
    • 95 Artefatos Produzidos: Plano do Projeto • Versão 5 em 28/07/2009 (PlanoProjeto_20090209_ProjetoClippingNews.rar)Gerenciar Plano Plano de Açãode Ação Não foram produzidos artefatos.Executar Plano de Plano de AçãoAção Não foram produzidos artefatos.GerenciarRequisitos aoLongo da Fase Solicitação de Mudança Artefatos Produzidos:RegistrarNecessidade de Solicitação de MudançaMudança • Versão 1 em 06/04/2009 (ControleAlteracaoRequisitos_20090406_ProjetoClippingNews.doc) Análise do Impacto Artefatos Produzidos:Analisar Impactoda Mudança Análise do Impacto • Versão 1 em 28/07/2009 (ControleAlteracaoRequisitos_20090406_ProjetoClippingNews.doc)Planejar Mudança Plano de Açãonos Requisitos Não foram produzidos artefatos. Registro de ComprometimentoObter Artefatos Produzidos:Comprometimentocom os Artefatos Registro de comprometimento com a Declaração de Escopo do Projeto.Modificados • Versão 1 em 27/07/2009 (RegistroComprometimentoEscopo_20090127_ProjetoClippingNews.pdf)Construir Software Obs.: O TABA não armazena o código do produto.Auditor:Data da avaliação:Não conformidades encontradas:Esboço dos Planos de Ação:Justificativas para os artefatos produzidos que não se aplicam ao projeto:
    • 96Anexo H - Plano do Processo do Projeto ClippingNews ClippingNews KMF Análise e Desenvolvimento de Sistemas e Websites Plano do Processo do Projeto ClippingNews 1. Escopo do projeto:O projeto deve atender a necessidade da KMF, que é disponibilizar no mercado uma ferramenta para produção de newsletter, de modo que permita enviar informações com maior velocidade, manter o sigilo dos dados dos destinatários, padronizar documentos e também diminuir custos com impressão e com serviço de correios. 2. Natureza do projeto: Desenvolvimento 3. Tipos de Software: Software para Web; 4. Paradigmas: Orientado a Objetos; 5. Organizações Clientes: KMF Análise e Desenvolvimento de Sistemas e Websites; 6. Organizações Desenvolvedoras: KMF Análise e Desenvolvimento de Sistemas e Websites; 7. Características do Projeto Critérios relacionados aos usuários Experiência dos usuários no domínio da aplicação Alta Facilidade dos usuários em expressar requisitos Alta Grau de acesso aos usuários Alto Nível de mudanças geradas no trabalho dos usuários Médio Critérios relacionados ao problema Grau de maturidade do domínio da aplicação Alto Complexidade do problema Média Freqüência de mudanças nos requisitos Baixa Grau de magnitude das mudanças nos requisitos Baixo Grau de modularidade do problema Baixo Critérios relacionados ao produto Tamanho da aplicação Pequeno Grau de complexidade da aplicação Baixo Restrição de Desempenho ou Tempo de Execução Sim Restrição de Segurança Sim Critérios relacionados aos recursos Disponibilidade de recursos humanos Adequada Disponibilidade de recursos financeiros Adequada
    • 97 Restrição de Cronograma Sim Critérios relacionados à equipe de desenvolvimento Experiência da equipe de desenvolvimento no domínio da Alta aplicação Experiência da equipe de desenvolvimento em Alta engenharia de software Experiência da equipe de desenvolvimento com a Alta plataforma de desenvolvimento Experiência da equipe de desenvolvimento com a Alta tecnologia utilizada Distribuição geográfica da equipe de desenvolvimento Centralizada Critérios relacionados à gerência do projeto Nível de experiência da gerência Médio Capacidade de gerenciamento de múltiplas equipes Sim Experiência da gerência no domínio da aplicação Média Experiência da gerência em engenharia de software Média Experiência da gerência com a plataforma de Média desenvolvimento Experiência da gerência com a tecnologia utilizada Média Critérios relacionados ao desenvolvimento Há necessidade de entrega de produtos intermediários Não Há necessidade do software ser colocado em uso Não rapidamente com funcionalidade total ou parcial Grau dos riscos técnicos Baixo Necessidade de interface com sistemas existentes Não Uso de tecnologia inovadora Sim Nível de danos Pequeno ou nenhum dano a Nível de danos ao ambiente propriedades Pequeno ou nenhum risco para Nível de danos a pessoas pessoas Nenhuma perda econômica ou perda Nível de danos à economia econômica desprezível8. Descrição do Processo Modelo de Ciclo de Vida: Cascata Ciclo de Desenvolvimento Objetivo:Execução seqüencial das atividades do processo. FASE 1 - PLANEJAMENTO DO PROJETO
    • 98Objetivo:Macro-atividades: Planejar Processo para o Projeto Descrição:O objetivo do Planejamento do Processo é definir o processo que será utilizado no projeto de desenvolvimento, identificando as atividades, subatividades e o ciclo de vida do projeto. Na primeira atividade, faz-se a definição do escopo do projeto no nível de detalhe suficiente para se planejar o projeto e o processo. A macro-atividade termina com a instanciação de um Ambiente de Desenvolvimento de Software (ADS) para o projeto. Atividades: Identificar o Escopo do Projeto Descrição:Realizar o levantamento inicial das necessidades do cliente e identificar o escopo do projeto. Neste momento é iniciada a identificação dos requisitos a serem implementados no projeto, bem como a identificação dos fornecedores e avaliadores destes requisitos. Critérios de Saída:Escopo do Projeto identificado e definido.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Produzidos:Declaração de Escopo do Projeto; Ferramentas de Software:Word; Avaliar a Declaração de Escopo do Projeto Descrição:Avaliar a declaração de escopo com o intuito de identificar imperfeições, ambigüidades e verificar se o documento está de acordo com os padrões da organização. Pré-Atividades:Identificar o Escopo do Projeto ; Critérios de Entrada:Declaração do Escopo produzida; Critérios de Saída:Declaração do Escopo avaliada; Responsáveis:Gerente de Projeto; Participantes:GQPP; Artefatos Requeridos:Declaração de Escopo do Projeto; Artefatos Produzidos:Laudo de Avaliação da Declaração de Escopo do Projeto; Ferramentas de Software:Excel; Obter comprometimento com o Escopo do Projeto Descrição:Obter a aprovação dos stakeholders para o escopo do projeto. Pré-Atividades:Avaliar a Declaração de Escopo do Projeto ; Critérios de Entrada:Declaração do Escopo produzida.; Critérios de Saída:Declaração do Escopo com assinatura indicando aceite.; Responsáveis:Gerente de Projeto; Participantes:Cliente; Artefatos Requeridos:Declaração de Escopo do Projeto; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail; Realizar Estimativas Descrição:Realizar as estimativas a partir dos requisitos do cliente identificados na declaração de escopo. Pré-Atividades:Obter comprometimento com o Escopo do Projeto ;
    • 99Critérios de Entrada:Escopo do projeto definido.;Critérios de Saída:Estimativas produzidas.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Declaração de Escopo do Projeto;Artefatos Produzidos:Planilha de Estimativas; Justificativa das Estimativas;Ferramentas de Software:Word; Excel;Elaborar Termo de Abertura de ProjetoDescrição:O Termo de Abertura de Projeto é elaborado com o objetivo decaracterizar o projeto, especialmente, em termos de escopo, esforço e prazo.Pré-Atividades:Realizar Estimativas ;Critérios de Entrada:Estimativas realizadas.;Critérios de Saída:Termo de Abertura de Projeto elaborado.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Planilha de Estimativas; Declaração de Escopo do Projeto;Artefatos Produzidos:Termo de Abertura do Projeto;Ferramentas de Software:Word;Avaliar a Viabilidade do ProjetoDescrição:Apresentar para a Gerência Administrativa o Termo de Abertura do Projetoe avaliar a viabilidade do projeto. A avaliação de viabilidade deve ser registradaatravés do Laudo de Avaliação da Viabilidade. Caso haja necessidade de adicionaralguma ressalva especial ao laudo e esta precise da ciência do cliente, o mesmodeverá ratificar o seu comprometimento com a Declaração de Escopo.Pré-Atividades:Elaborar Termo de Abertura de Projeto ;Critérios de Entrada:Termo de Abertura produzido.;Critérios de Saída:Avaliação da viabilidade do projeto realizada.;Responsáveis:Gerente de Projeto;Participantes:Gerência Administrativa;Artefatos Requeridos:Termo de Abertura do Projeto;Artefatos Produzidos:Laudo de Avaliação da Viabilidade;Ferramentas de Software:Word;Planejar ProcessoDescrição:Definir o Plano do Processo para o novo projeto, registrando o escopo e ascaracterísticas básicas do projeto de forma a dar subsídios para identificar o ciclo devida a ser utilizado no processo e todas as atividades a serem executadas noprojeto.Pré-Atividades:Avaliar a Viabilidade do Projeto ;Critérios de Entrada:Avaliar a Viabilidade do Projeto;Critérios de Saída:Viabilidade do projeto avaliada.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Declaração de Escopo do Projeto;Artefatos Produzidos:Plano do Processo; Justificativas das Alterações no ProcessoPadrão;Ferramentas de Software:AdaptPro;Avaliar Plano do ProcessoDescrição:Verificar se o processo definido está adequado às necessidades do projetoe padrões da Organização e realizar os ajustes necessários. Qualquer inadequaçãoidentificada deve ser corrigida pelo gerente do projeto para poder instanciar o plano
    • 100 do processo para o projeto. Pré-Atividades:Planejar Processo ; Critérios de Entrada:Plano do Processo elaborado.; Critérios de Saída:Plano do Processo avaliado pelo GQPP; Responsáveis:GQPP; Participantes:Gerente de Projeto; Artefatos Requeridos:Plano do Processo; Justificativas das Alterações no Processo Padrão; Artefatos Produzidos:Laudo da Avaliação do Plano do Processo; Plano de Ação; Ferramentas de Software:ActionPlanManager; Excel; Instanciar Ambiente para o projeto Descrição:Instanciar um Ambiente de Desenvolvimento de Software para a realização do projeto, a partir do processo definido e aprovado. Pré-Atividades:Avaliar Plano do Processo ; Critérios de Entrada:Plano do Processo avaliado; Critérios de Saída:Ambiente instanciado para o projeto.; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano do Processo; Artefatos Produzidos:Ambiente de Desenvolvimento de Software (ADS); Ferramentas de Software:AdaptPro;Planejar o ProjetoDescrição:O objetivo do planejamento do projeto é possibilitar que as necessidades docliente sejam atendidas dentro das restrições de prazo e recursos estabelecidos. O planodo projeto viabiliza a monitoração e controle das atividades de desenvolvimento paraidentificar e corrigir desvios ao longo do projeto.Atividades: Gerar a Estrutura Analítica do Projeto Descrição:Uma EAP é um agrupamento de componentes do projeto orientados a resultados práticos que organiza e define o escopo total do projeto. O trabalho não incluído na EAP está fora do escopo do projeto. A EAP é a base para estimar o tempo do projeto. Pré-Atividades:Instanciar Ambiente para o projeto ; Critérios de Entrada:Ambiente do projeto instanciado.; Critérios de Saída:Estrutura Analítica do Projeto elaborada; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano do Processo; Artefatos Produzidos:Estrutura Analítica do Projeto; Ferramentas de Software:AdaptPro; Estabelecer Estrutura Organizacional do Projeto Descrição:Iniciar o planejamento da estrutura organizacional do projeto, identificando para cada parte envolvida, os responsáveis, os contatos e suas funções e papéis no organograma do projeto. Apontar os envolvidos no projeto (stakeholders), identificando as funções assim como a relevância e nível de interação nas atividades do projeto. Pré-Atividades:Gerar a Estrutura Analítica do Projeto ; Critérios de Entrada:Estrutura Analítica do Projeto elaborada; Critérios de Saída:Estrutura Organizacional do Projeto estabelecida;
    • 101Responsáveis:Gerente de Projeto;Artefatos Produzidos:Plano de Organização;Ferramentas de Software:OrgPlan;Estabelecer CronogramaDescrição:Gerar o cronograma do projeto e definir os marcos/pontos de controle doprojeto no Plano de Acompanhamento e Controle. O Plano de Acompanhamento eControle deve levar em consideração a periodicidade estabelecida para elaborar osrelatórios de monitoração.Pré-Atividades:Estabelecer Estrutura Organizacional do Projeto ;Critérios de Entrada:Plano do Processo elaborado e Termo de Abertura aprovado.;Critérios de Saída:Cronograma do projeto produzido.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano do Processo; Termo de Abertura do Projeto;Artefatos Produzidos:Cronograma; Plano de Acompanhamento e Controle;Ferramentas de Software:TempManager; ControlManager;Planejar Recursos HumanosDescrição:Identificar as competências necessárias e gerar o planejamento derecursos humanos necessários para o projeto. A seleção dos recursos humanos parao projeto deve ser realizada considerando-se as habilidades, competências edisponibilidade dos colaboradores. Deve-se utilizar a ferramenta Sapiens do TABA.Pré-Atividades:Estabelecer Cronograma ;Critérios de Entrada:Cronograma do Projeto produzido.;Critérios de Saída:Recursos humanos do projeto planejados.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Cronograma;Artefatos Produzidos:Plano de Recursos Humanos;Ferramentas de Software:Sapiens; RHManager;Planejar Gerência de DocumentosDescrição:Identificar as várias formas de documentação necessárias para apoiar oprojeto em todas as suas áreas (administrativa, financeira, logística,desenvolvimento etc). Especificar formatos, mídias, formas de distribuição, público-alvo e responsabilidades pelo desenvolvimento e aprovação para todas as formas dedocumentação identificadas.Pré-Atividades:Planejar Recursos Humanos ;Critérios de Entrada:Plano de Recursos Humanos produzido.;Critérios de Saída:Plano da Gerência de Documentos produzido.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano de Recursos Humanos;Artefatos Produzidos:Plano de Gerência de Documentos;Ferramentas de Software:Word;Planejar ComunicaçãoDescrição:Planejar o envolvimento dos stakeholders, elaborando o Plano deComunicação do projeto.Pré-Atividades:Planejar Gerência de Documentos ;Critérios de Entrada:Plano de Recursos Humanos e Plano de Gerência deDocumentos produzidos.;Critérios de Saída:Plano de comunicação produzido.;
    • 102Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano de Recursos Humanos; Plano de Gerência deDocumentos; Plano de Organização;Artefatos Produzidos:Plano de Comunicação;Ferramentas de Software:Word;Planejar TreinamentosDescrição: (Opcional)Identificar os diferentes tipos de treinamento necessários parao desenvolvimento, implantação, uso e manutenção do produto. Esta atividade sóprecisa ser realizada caso alguém membro da equipe não tenha o conhecimentorequerido para executar suas tarefas no projeto.Pré-Atividades:Planejar Comunicação ;Critérios de Entrada:Plano de Recursos Humanos produzido.;Critérios de Saída:Ter-se planejado os treinamentos necessários.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano de Recursos Humanos;Artefatos Produzidos:Plano de Treinamento;Ferramentas de Software:Word;Planejar CustosDescrição:Identificar e estimar os recursos em geral (equipamentos, materiais, infra-estrutura etc) necessários ao projeto. Gerar o Plano de Custos do Projeto.Pré-Atividades:Planejar Treinamentos ;Critérios de Entrada:Ter-se planejado, tempo, recursos humanos e treinamentonecessário.;Critérios de Saída:Custos planejados.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Cronograma; Plano de Recursos Humanos; Plano deTreinamento;Artefatos Produzidos:Plano de Custos;Ferramentas de Software:CustManager;Planejar RiscosDescrição:Identificar, analisar e avaliar os riscos do projeto. Priorizar riscos eestabelecer os planos de mitigação e de contingência como parte do Controle deRisco do Projeto.Pré-Atividades:Planejar Custos ;Critérios de Entrada:Estrutura organizacional do projeto elaborada.;Critérios de Saída:Planejamento de Riscos realizado para o projeto.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano de Organização;Artefatos Produzidos:Plano de Riscos;Ferramentas de Software:RiscManager;Planejar Gerência de ConfiguraçãoDescrição:Definir as atividades do processo de gerência de configuração para oprojeto. O plano deve descrever as atividades da gerência de configuração, os itensde configuração, os procedimentos e responsáveis para executá-losPré-Atividades:Planejar Riscos ;Critérios de Entrada:Estrutura organizacional do projeto elaborada.;Critérios de Saída:Gerência de Configuração planejada para o projeto.;
    • 103Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano de Organização;Artefatos Produzidos:Plano de Gerência de Configuração;Ferramentas de Software:GConf; Word;Planejar Medição e AnáliseDescrição:A partir do Plano de Medição da Organização, estabelecer, se desejado,novas medidas de avaliação para o projeto.Pré-Atividades:Planejar Gerência de Configuração ;Critérios de Entrada:Plano de Medição Organizacional definido.;Critérios de Saída:Plano de Medição para o projeto produzido.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Plano de Medição da Organização;Artefatos Produzidos:Plano de Medição;Ferramentas de Software:MedPlan; Word;Consolidar o Plano do ProjetoDescrição:Consolidar os planos gerados de forma a constituírem o Plano do Projetocomo um todo. Itens que compõem o Plano do Projeto Interno: Estrutura Analíticado Projeto, Plano de Organização, Planilha de Estimativas, Termo de Abertura,Cronograma, Plano de Acompanhamento e Controle, Plano de Recursos Humanos,Plano de Gerência de Documentos, Plano de Comunicação, Plano de Treinamento (seelaborado), Plano de Custos, Plano de Riscos, Plano de Gerência de Configuração ePlano de Medição. Itens que compõem o Plano do Projeto do Cliente: Cronograma(apenas com as atividades que ele participa) + Plano de Comunicação (com ascomunicações de interesse) + Plano de Treinamento (se tiver treinamento para ousuário).Pré-Atividades:Planejar Medição e Análise ;Critérios de Entrada:Todos os artefatos que constituem o plano do projeto devem tersido produzidos.;Critérios de Saída:Planos do Projeto, interno e do cliente, consolidados.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Estrutura Analítica do Projeto; Plano de Organização; Planilhade Estimativas; Termo de Abertura do Projeto; Cronograma; Plano deAcompanhamento e Controle; Plano de Recursos Humanos; Plano de Gerência deDocumentos; Plano de Comunicação; Plano de Treinamento; Plano de Custos; Planode Riscos; Plano de Gerência de Configuração; Plano de Medição;Artefatos Produzidos:Plano do Projeto; Plano do Projeto Cliente;Ferramentas de Software:Word;Avaliar Plano do ProjetoDescrição:Avaliar o Plano do Projeto segundo os critérios estabelecidos.Pré-Atividades:Consolidar o Plano do Projeto ;Critérios de Entrada:Plano do Projeto consolidado e Plano do Projeto Clienteelaborado.;Critérios de Saída:Plano do Projeto avaliado pelo GQPP;Responsáveis:GQPP;Participantes:Gerente de Projeto;Artefatos Requeridos:Plano do Projeto; Plano do Projeto Cliente;Artefatos Produzidos:Laudo da Avaliação do Plano do Projeto; Plano de Ação;
    • 104 Ferramentas de Software:ActionPlanManager; Excel; Obter Comprometimento com o Plano do Projeto Descrição:Obter, de todos os envolvidos, o comprometimento com o Plano do Projeto. O registro de comprometimento não requer que seja gerado um documento assinado pelos envolvidos. Este registro pode ser apenas um e-mail de cada uma das pessoas informando que estão cientes do seu envolvimento. Nesta ocasião, qualquer impedimento por parte dos envolvidos deve ser contornado para evitar desvios no plano (renegociação do cronograma, revisão do plano de recursos humanos, revisão do plano organizacional do projeto etc.). É imprescindível obter do cliente o comprometimento com o plano do projeto. Pré-Atividades:Avaliar Plano do Projeto ; Critérios de Entrada:Plano do Projeto consolidado.; Critérios de Saída:Comprometimento registrado.; Responsáveis:Gerente de Projeto; Participantes:Stakeholder; Artefatos Requeridos:Plano do Projeto; Plano do Projeto Cliente; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail;Encerramento da FaseDescrição:Esta macro-atividade tem como objetivo realizar atividades de encerramentoda fase.Atividades: Criar Baselines e Estabelecer Registros Descrição:Criar a baseline para a fase e gerar um relatório de versões contendo a situação de cada item de configuração. Este relatório contempla todos os pedidos de alteração realizados, as alterações implementadas e as respectivas versões. Pré-Atividades:Obter Comprometimento com o Plano do Projeto ; Critérios de Entrada:Comprometimento com o Plano do Projeto registrado; Critérios de Saída:Baseline definida.; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano do Projeto; Artefatos Produzidos:Baseline; Relatório das Versões; Ferramentas de Software:GConf; Realizar Auditoria da Configuração Descrição:Esta atividade tem por objetivo realizar uma auditoria para analisar a integridade dos itens de configuração e baselines criados na fase. Em caso de não- conformidades é elaborado um Plano de Ação para correção dos problemas. Pré-Atividades:Criar Baselines e Estabelecer Registros ; Critérios de Entrada:Baseline definida.; Critérios de Saída:Auditoria da Configuração realizada.; Responsáveis:Gerente de Configuração; Artefatos Requeridos:Baseline; Relatório das Versões; Artefatos Produzidos:Relatório de Auditoria da Configuração; Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Avaliar a Aderência aos Processos na Fase Descrição:Esta atividade deve ser realizada ao final de cada fase e tem por objetivo
    • 105 avaliar, através de um check-list, a aderência ao processo definido. Caso haja não- conformidades, é elaborado um Plano de Ação para correção dos problemas. Esta atividade também visa identificar oportunidades de melhoria nos processos. Pré-Atividades:Realizar Auditoria da Configuração ; Critérios de Entrada:Ter sido realizada a auditoria de configuração.; Critérios de Saída:Check-list de aderência preenchido.; Responsáveis:GQPP; Artefatos Requeridos:Estrutura Analítica do Projeto; Artefatos Produzidos:Check-list de Avaliação da Aderência ao Processo do Projeto; Plano de Ação; Ferramentas de Software:AdaptPro; ActionPlanManager; Word;FASE 2 - ANÁLISE E PROJETOObjetivo:Macro-atividades: Monitorar o Projeto ao longo da Fase Descrição:O objetivo desta macro-atividade é monitorar o andamento do projeto ao longo da fase, com periodicidade pelo menos quinzenal. Sempre que houver alterações no Plano do Projeto deve-se notificar os envolvidos cujas as atividades foram afetadas. Atividades: Monitorar Andamento do Projeto Descrição:Acompanhar o progresso e o desempenho reais do projeto. Esta é uma atividade diária do Gerente do Projeto. Entretanto, na periodicidade estabelecida para elaboração do relatório de monitoração, deve ser elaborado um relatório contendo uma análise da situação do projeto com relação ao cronograma, custos, esforço, produtos de trabalho, tarefas e envolvimento dos participantes. Também deve-se monitorar os riscos do projeto e demais aspectos que possam representar desvios do plano. Critérios de Entrada:Ter chegado o momento de realizar monitoração do projeto de acordo com a periodicidade estabelecida.; Critérios de Saída:Ter sido produzido o Relatório de Monitoramento do Projeto.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Plano do Projeto; Artefatos Produzidos:Relatório de Monitoração do Projeto; Plano de Ação; Ferramentas de Software:RiscManager; TempManager; CustManager; RHManager; OrgPlan; GConf; MedPlan; ControlManager; ActionPlanManager; Word; Gerenciar Plano de Ação Descrição:Garantir que as devidas ações corretivas sejam executadas e gerenciar a sua realização pelos responsáveis. Caso os responsáveis pela sua execução não cumpram o estabelecido, deve-se escalonar o problema às instâncias superiores. Através da monitoração do plano de ação, a execução das ações é acompanhada até que estas sejam concluídas, quando o plano de ação passa para situação concluído. Pré-Atividades:Monitorar Andamento do Projeto ; Critérios de Entrada:Desvios identificados durante a monitoração.; Critérios de Saída:Plano de Ação executado.;
    • 106 Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano de Ação; Artefatos Produzidos:Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Executar Plano de Ação Descrição:O Plano de Ação elaborado é executado pelos responsáveis. Após a realização das atividades do Plano de Ação deve-se comunicar ao gerente para que este avalie e, caso aprove, registre a finalização. Pré-Atividades:Monitorar Andamento do Projeto ; Critérios de Entrada:Plano de Ação com responsabilidades atribuídas e responsáveis notificados.; Critérios de Saída:Atividade atribuída executada e gerente notificado.; Responsáveis:Gerente de Projeto; Participantes:Designados para executar o Plano de Ação; Artefatos Requeridos:Plano de Ação; Artefatos Produzidos:Plano de Ação; Ferramentas de Software:ActionPlanManager; Word;Gerenciar de Requisitos ao Longo da FaseDescrição:Visa incorporar mudanças no projeto de forma gerenciada.Atividades: Registrar Necessidade de Mudança Descrição:Formalizar a solicitação de mudança de requisitos para deixar explícito qual a mudança a ser realizada, quem solicitou a mudança e outras informações que forem relevantes para a avaliação de impacto. Critérios de Entrada:Solicitação de mudança realizada por algum envolvido no projeto.; Critérios de Saída:Solicitação registrada.; Responsáveis:Gerente de Projeto; Participantes:Stakeholder; Artefatos Produzidos:Solicitação de Mudança; Ferramentas de Software:Word; ADS; Analisar Impacto da Mudança Descrição:Avaliar o impacto de mudanças nos requisitos, no cronograma, no plano do projeto e demais aspectos relevantes para o projeto. A avaliação de impacto deve indicar todas as ações requeridas para implementar a solicitação de mudança. Pré-Atividades:Registrar Necessidade de Mudança ; Critérios de Entrada:Ter havido uma solicitação de mudança nos requisitos.; Critérios de Saída:Mudança nos requisitos avaliada e decisão quanto à mudança tomada.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Plano do Projeto; Especificação de Requisitos; Solicitação de Mudança; Artefatos Produzidos:Análise do Impacto; Ferramentas de Software:ReqManager; Word;
    • 107 Planejar Mudança nos Requisitos Descrição:Elaborar um plano de ação para realizar as mudanças. O plano de ação deve ser acompanhado até que todas as suas ações sejam concluídas. O plano de ação deve incluir: a atualização de todos os produtos de trabalho indicados na Análise de Impacto e a reavaliação dos produtos de trabalho relevantes que sofreram alteração (ex.: Especificação de Requisitos, Modelo de Análise e Projeto, Matriz de Rastreabilidade etc.). Pré-Atividades:Analisar Impacto da Mudança ; Critérios de Entrada:Análise de Impacto aprovada.; Critérios de Saída:Plano de Ação elaborado.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Análise do Impacto; Artefatos Produzidos:Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Obter Comprometimento com os Artefatos Modificados Descrição:Sempre que houver mudança, obter novo comprometimento com todos os artefatos relevantes modificados (ex.: especificação de requisitos, modelo de análise e projeto etc. Pré-Atividades:Planejar Mudança nos Requisitos ; Critérios de Entrada:Especificação de Requisitos alterada.; Critérios de Saída:Comprometimento com a Especificação de Requisitos registrado. Especificação de Requisitos e Matriz de Rastreabilidade sob Gerência de Configuração.; Responsáveis:Gerente de Projeto; Participantes:Stakeholder; Artefatos Requeridos:Declaração de Escopo do Projeto; Especificação de Requisitos; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail;Analisar Requisitos do SoftwareDescrição:O objetivo da Análise dos Requisitos do Software é identificar os requisitos doproduto a partir das necessidades do cliente.Atividades: Criar Matriz de Rastreabilidade Descrição:Definir o nível da matriz de rastreabilidade a partir dos requisitos do cliente. Critérios de Entrada:Comprometimento com a Especificação de Requisitos do cliente registrado.; Critérios de Saída:Primeiro nível da matriz de rastreabilidade definido.; Responsáveis:Gerente de Projeto; Participantes:Analista de Sistemas; Artefatos Requeridos:Declaração de Escopo do Projeto; Artefatos Produzidos:Matriz de Rastreabilidade; Ferramentas de Software:ReqManager; Especificar Requisitos Descrição:A partir dos fornecedores de requisitos identificar e documentar os requisitos. Formalizar o entendimento dos requisitos funcionais e de outros
    • 108requisitos não-funcionais (requisitos de qualidade, requisitos de interface, requisitostecnológicos, requisitos legais, requisitos de proteção, requisitos de segurança,definição de dados e requisitos de bases de dados, requisitos de instalação,requisitos do usuário para execução e operação, requisitos do usuário paramanutenção, dentre outros, conforme o caso). Esta atividade também pode incluir aprodução do Glossário. Nesta atividade são construídos os Casos de Uso. Osrequisitos relacionados a integração de produto devem ser identificadosexplicitamente.Pré-Atividades:Criar Matriz de Rastreabilidade ;Critérios de Entrada:Requisitos do cliente identificados.;Critérios de Saída:Requisitos especificados.;Responsáveis:Analista de Sistemas;Participantes:Fornecedores de Requisitos; Analista de Sistemas;Artefatos Requeridos:Declaração de Escopo do Projeto;Artefatos Produzidos:Glossário; Especificação de Requisitos;Ferramentas de Software:Word; Ferramenta CASE;Atualizar Matriz de RastreabilidadeDescrição:Definir o nível seguinte da Matriz de Rastreabilidade com os requisitos dosoftware, identificando os requisitos de software produzidos nesta macro-atividade eseus relacionamentos com os requisitos do cliente.Pré-Atividades:Especificar Requisitos ;Critérios de Entrada:Requisitos especificados.;Critérios de Saída:Matriz de rastreabilidade atualizada.;Responsáveis:Gerente de Projeto;Artefatos Requeridos:Especificação de Requisitos;Artefatos Produzidos:Matriz de Rastreabilidade;Ferramentas de Software:ReqManager;Avaliar a Especificação de RequisitosDescrição:Avaliar a qualidade da Especificação de Requisitos segundo os critériosestabelecidos. A Matriz de Rastreabilidade também deve ser avaliada. Deve-sedefinir o Plano de Ação para adequar os requisitos que não estiverem de acordo comos critérios estabelecidos.Pré-Atividades:Atualizar Matriz de Rastreabilidade ;Critérios de Entrada:Especificação de requisitos e matriz de rastreabilidadeelaboradas.;Critérios de Saída:Especificação de Requisitos avaliada.;Responsáveis:GQPP;Participantes:Gerente de Projeto;Artefatos Requeridos:Especificação de Requisitos;Artefatos Produzidos:Laudo de Avaliação da Especificação de Requisitos; Plano deAção;Ferramentas de Software:ActionPlanManager; Excel;Obter Comprometimento com a Especificação de RequisitosDescrição:Nesta atividade o cliente deve avaliar a especificação de requisitos e semanifestar caso identifique problemas que possam influenciar na qualidade doproduto esperado. Ao final, o comprometimento com a especificação de requisitos éobtida com todo os envolvidos (Equipe do Projeto e Cliente).Pré-Atividades:Avaliar a Especificação de Requisitos ;
    • 109 Critérios de Entrada:Especificação de Requisitos aprovada.; Critérios de Saída:Comprometimento com a Especificação de Requisitos registrado.; Responsáveis:Gerente de Projeto; Participantes:Cliente; Equipe do Projeto; Artefatos Requeridos:Especificação de Requisitos; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail;Elaborar Modelo de Análise e Projeto do SoftwareDescrição:O objetivo da macro-atividade é produzir o Modelo de Análise e Projeto.Atividades: Desenvolver Modelo de Análise e Projeto do Software Descrição:Realizar a modelagem para a construção do software. Artefatos como o diagrama de classes e modelo de entidade-relacionamento são elaborados nesta atividade. Pré-Atividades:Obter Comprometimento com a Especificação de Requisitos ; Critérios de Entrada:Especificação de Requisitos aprovada.; Critérios de Saída:Modelo de Análise e Projeto elaborado.; Responsáveis:Analista de Sistemas; Participantes:Equipe do Projeto; Artefatos Requeridos:Especificação de Requisitos; Artefatos Produzidos:Modelo de Análise e Projeto; Ferramentas de Software:Word; Enterprise Architect; Ferramenta CASE; Avaliar o Modelo de Análise e Projeto Descrição:Avaliar o Modelo de Análise e Projeto segundo os critérios estabelecidos. Deve-se definir um plano de ação para realizar adequações para aspectos que não estiverem de acordo com os critérios estabelecidos. Pré-Atividades:Desenvolver Modelo de Análise e Projeto do Software ; Critérios de Entrada:Modelo de Análise e Projeto elaborado.; Critérios de Saída:Modelo de Análise e Projeto avaliado.; Responsáveis:GQPP; Participantes:Gerente de Projeto; Artefatos Requeridos:Modelo de Análise e Projeto; Artefatos Produzidos:Laudo de Avaliação do Modelo de Análise e Projeto; Plano de Ação; Ferramentas de Software:ActionPlanManager; Excel; Identificar Cenários de Teste Descrição:Consiste em identificar os cenários que serão cobertos por casos de testes. Pré-Atividades:Avaliar o Modelo de Análise e Projeto ; Critérios de Entrada:Modelo de Análise e Projeto elaborado.; Critérios de Saída:Cenários de teste identificados e descritos.; Responsáveis:Analista de Sistemas; Participantes:Equipe do Projeto; Artefatos Requeridos:Especificação de Requisitos; Modelo de Análise e Projeto; Artefatos Produzidos:Cenários de Teste; Ferramentas de Software:Word;
    • 110 Atualizar Matriz de Rastreabilidade Descrição:Atualizar a matriz de rastreabilidade com elementos identificados durante a modelagem, inclusive os cenários. Pré-Atividades:Identificar Cenários de Teste ; Critérios de Entrada:Cenários de testes identificados.; Critérios de Saída:Matriz de rastreabilidade atualizada.; Responsáveis:Analista de Sistemas; Artefatos Requeridos:Matriz de Rastreabilidade; Modelo de Análise e Projeto; Cenários de Teste; Artefatos Produzidos:Matriz de Rastreabilidade; Ferramentas de Software:ReqManager; Avaliar a Matriz de Rastreabilidade Descrição:Avaliar a Matriz de Rastreabilidade segundo os critérios estabelecidos. A consistência entre a Especificação de Requisitos, Cenários de Teste e o Modelo de Análise e Projeto é verificada. Deve-se definir um plano de ação para realizar adequações para aspectos que não estiverem de acordo com os critérios estabelecidos. Pré-Atividades:Atualizar Matriz de Rastreabilidade ; Critérios de Entrada:Matriz de Rastreabilidade atualizada.; Critérios de Saída:Matriz de Rastreabilidade avaliada.; Responsáveis:GQPP; Participantes:Gerente de Projeto; Artefatos Requeridos:Matriz de Rastreabilidade; Modelo de Análise e Projeto; Cenários de Teste; Especificação de Requisitos; Artefatos Produzidos:Laudo de Avaliação da Matriz de Rastreabilidade; Plano de Ação; Ferramentas de Software:ActionPlanManager; Excel; Obter Comprometimento com o Modelo de Análise e Projeto Descrição:A atividade visa apresentar para a equipe os produtos da modelagem que nortearão a construção do produto. A equipe do projeto toma ciência das decisões de projeto e se comprometem em seguir a modelagem. Pré-Atividades:Avaliar a Matriz de Rastreabilidade ; Critérios de Entrada:Modelo de Análise e Projeto aprovado.; Critérios de Saída:Comprometimento com o Modelo de Análise e Projeto registrado.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Modelo de Análise e Projeto; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail;Encerramento da FaseDescrição:Esta macro-atividade tem como objetivo realizar atividades de encerramentoda fase.Atividades: Criar Baselines e Estabelecer Registros Descrição:Criar a baseline para a fase e gerar um relatório de versões contendo a situação de cada item de configuração. Este relatório contempla todos os pedidos de alteração realizados, as alterações implementadas e as respectivas versões.
    • 111 Pré-Atividades:Obter Comprometimento com o Modelo de Análise e Projeto ; Critérios de Entrada:Comprometimento com o Plano do Projeto registrado; Critérios de Saída:Baseline definida.; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano do Projeto; Artefatos Produzidos:Baseline; Relatório das Versões; Ferramentas de Software:GConf; Realizar Auditoria da Configuração Descrição:Esta atividade tem por objetivo realizar uma auditoria para analisar a integridade dos itens de configuração e baselines criados na fase. Em caso de não- conformidades é elaborado um Plano de Ação para correção dos problemas. Pré-Atividades:Criar Baselines e Estabelecer Registros ; Critérios de Entrada:Baseline definida.; Critérios de Saída:Auditoria da Configuração realizada.; Responsáveis:Gerente de Configuração; Artefatos Requeridos:Baseline; Relatório das Versões; Artefatos Produzidos:Relatório de Auditoria da Configuração; Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Avaliar a Aderência aos Processos na Fase Descrição:Esta atividade deve ser realizada ao final de cada fase e tem por objetivo avaliar, através de um check-list, a aderência ao processo definido. Caso haja não- conformidades, é elaborado um Plano de Ação para correção dos problemas. Esta atividade também visa identificar oportunidades de melhoria nos processos. Pré-Atividades:Realizar Auditoria da Configuração ; Critérios de Entrada:Ter sido realizada a auditoria de configuração.; Critérios de Saída:Check-list de aderência preenchido.; Responsáveis:Gerente da Qualidade; Artefatos Requeridos:Estrutura Analítica do Projeto; Artefatos Produzidos:Check-list de Avaliação da Aderência ao Processo do Projeto; Plano de Ação; Ferramentas de Software:AdaptPro; ActionPlanManager; Word; Excel;FASE 3 - CONSTRUÇÃO, TESTES E IMPLANTAÇÃOObjetivo:Macro-atividades: Refinar o planejamento para realização da fase Descrição:O objetivo da macro-atividade é refinar o planejamento para a realização da fase, onde pertinente. Atividades: Refinar Planejamento Descrição:Detalhar o Plano do Projeto refinando-o para a realização da fase, especialmente no que tange o cronograma e a alocação de recursos para as atividades de construção. Critérios de Entrada:Plano do Projeto sob gerência de configuração; Critérios de Saída:Plano do Projeto refinado para a fase;
    • 112 Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano do Projeto; Especificação de Requisitos; Cenários de Teste; Artefatos Produzidos:Plano do Projeto; Ferramentas de Software:RiscManager; TempManager; CustManager; RHManager; OrgPlan; GConf; ControlManager; Word; Avaliar Plano do Projeto Descrição:Avaliar o Plano do Projeto segundo os critérios estabelecidos. Pré-Atividades:Refinar Planejamento ; Critérios de Entrada:Plano do projeto consolidado.; Critérios de Saída:Plano do Projeto avaliado pelo GQPP; Responsáveis:GQPP; Participantes:Gerente de Projeto; Artefatos Requeridos:Plano do Projeto; Artefatos Produzidos:Laudo da Avaliação do Plano do Projeto; Plano de Ação; Ferramentas de Software:ActionPlanManager; Excel; Obter Comprometimento com o Plano do Projeto Descrição:Obter, de todos os envolvidos, o comprometimento com o Plano do Projeto. O registro de comprometimento não requer que seja gerado um documento assinado pelos envolvidos. Este registro pode ser apenas um e-mail de cada uma das pessoas informando que estão cientes do seu envolvimento. Nesta ocasião, qualquer impedimento por parte dos envolvidos deve ser contornado para evitar desvios no plano (renegociação do cronograma, revisão do plano de recursos humanos, revisão do plano organizacional do projeto etc.). Este comprometimento é interno, restrito à equipe do projeto. Pré-Atividades:Avaliar Plano do Projeto ; Critérios de Entrada:Plano do Projeto consolidado.; Critérios de Saída:Comprometimento registrado.; Responsáveis:Gerente de Projeto; Participantes:Stakeholder; Artefatos Requeridos:Plano do Projeto; Plano do Projeto Cliente; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail;Monitorar o Projeto ao longo da FaseDescrição:O objetivo desta macro-atividade é monitorar o andamento do projeto ao longoda fase, com periodicidade pelo menos quinzenal. Sempre que houver alterações no Planodo Projeto deve-se notificar os envolvidos cujas as atividades foram afetadas.Atividades: Monitorar Andamento do Projeto Descrição:Acompanhar o progresso e o desempenho reais do projeto. Esta é uma atividade diária do Gerente do Projeto. Entretanto, na periodicidade estabelecida no plano de acompanhamento e monitoração, deve ser elaborado um relatório contendo uma análise da situação do projeto com relação ao cronograma, custos, esforço, produtos de trabalho, tarefas e envolvimento dos participantes. Também deve-se monitorar os recursos previstos e usados, riscos do projeto e demais aspectos que possam representar desvios do plano. Critérios de Entrada:Ter chegado o momento de realizar monitoração do projeto de
    • 113 acordo com a periodicidade estabelecida.; Critérios de Saída:Ter sido produzido o Relatório de Monitoramento do Projeto.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Plano do Projeto; Artefatos Produzidos:Plano do Projeto; Relatório de Monitoração do Projeto; Plano de Ação; Ferramentas de Software:RiscManager; TempManager; CustManager; RHManager; OrgPlan; GConf; MedPlan; ControlManager; GeraDoc; ActionPlanManager; Word; Gerenciar Plano de Ação Descrição:Garantir que as devidas ações corretivas sejam executadas e gerenciar a sua realização pelos responsáveis. Caso os responsáveis pela sua execução não cumpram o estabelecido, deve-se escalonar o problema às instâncias superiores. Através da monitoração do plano de ação, a execução das ações é acompanhada até que estas sejam concluídas, quando o plano de ação passa para situação concluído. Pré-Atividades:Monitorar Andamento do Projeto ; Critérios de Entrada:Desvios identificados durante a monitoração.; Critérios de Saída:Plano de Ação executado.; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Plano de Ação; Artefatos Produzidos:Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Executar Plano de Ação Descrição:O Plano de Ação elaborado é executado pelos responsáveis. Após a realização das atividades do Plano de Ação deve-se comunicar ao gerente para que este avalie e, caso aprove, registre a finalização. Pré-Atividades:Monitorar Andamento do Projeto ; Critérios de Entrada:Plano de Ação com responsabilidades atribuídas e responsáveis notificados.; Critérios de Saída:Atividade atribuída executada e gerente notificado.; Responsáveis:Gerente de Projeto; Participantes:Designados para executar o Plano de Ação; Artefatos Requeridos:Plano de Ação; Artefatos Produzidos:Plano de Ação; Ferramentas de Software:ActionPlanManager; Word;Gerenciar de Requisitos ao Longo da FaseDescrição:Visa incorporar mudanças no projeto de forma gerenciada.Atividades: Registrar Necessidade de Mudança Descrição:Formalizar a solicitação de mudança de requisitos para deixar explícito qual a mudança a ser realizada, quem solicitou a mudança e outras informações que forem relevantes para a avaliação de impacto. Critérios de Entrada:Solicitação de mudança realizada por algum envolvido no projeto.; Critérios de Saída:Solicitação registrada.; Responsáveis:Gerente de Projeto; Participantes:Stakeholder;
    • 114 Artefatos Produzidos:Solicitação de Mudança; Ferramentas de Software:Word; ADS; Analisar Impacto da Mudança Descrição:Avaliar o impacto de mudanças nos requisitos, no cronograma, no plano do projeto e demais aspectos relevantes para o projeto. A avaliação de impacto deve indicar todas as ações requeridas para implementar a solicitação de mudança. Pré-Atividades:Registrar Necessidade de Mudança ; Critérios de Entrada:Ter havido uma solicitação de mudança nos requisitos.; Critérios de Saída:Mudança nos requisitos avaliada e decisão quanto à mudança tomada.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Plano do Projeto; Especificação de Requisitos; Solicitação de Mudança; Artefatos Produzidos:Análise do Impacto; Ferramentas de Software:ReqManager; Word; Planejar Mudança nos Requisitos Descrição:Elaborar um plano de ação para realizar as mudanças. O plano de ação deve ser acompanhado até que todas as suas ações sejam concluídas. O plano de ação deve incluir: a atualização de todos os produtos de trabalho indicados na Análise de Impacto e a reavaliação dos produtos de trabalho relevantes que sofreram alteração (ex.: Especificação de Requisitos, Modelo de Análise e Projeto, Matriz de Rastreabilidade etc.). Pré-Atividades:Analisar Impacto da Mudança ; Critérios de Entrada:Análise de Impacto aprovada.; Critérios de Saída:Plano de Ação elaborado.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Análise do Impacto; Artefatos Produzidos:Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Obter Comprometimento com os Artefatos Modificados Descrição:Sempre que houver mudança, obter novo comprometimento com todos os artefatos relevantes modificados (ex.: especificação de requisitos, modelo de análise e projeto etc. Pré-Atividades:Planejar Mudança nos Requisitos ; Critérios de Entrada:Especificação de Requisitos alterada.; Critérios de Saída:Comprometimento com a Especificação de Requisitos registrado. Especificação de Requisitos e Matriz de Rastreabilidade sob Gerência de Configuração.; Responsáveis:Gerente de Projeto; Participantes:Stakeholder; Artefatos Requeridos:Declaração de Escopo do Projeto; Especificação de Requisitos; Artefatos Produzidos:Registro de Comprometimento; Ferramentas de Software:Word; E-mail;Construir SoftwareDescrição:O objetivo da Construção do Software é produzir unidades de software
    • 115integradas para constituir um software executável, com funcionalidades devidamentetestadas, a partir da Especificação de Requisitos, do Modelo de Análise e Projeto e dosCenários de Teste.Atividades: Codificar Software Descrição:Construir as unidades de software, testando-as e integrando-as de forma contínua. Pré-Atividades:Obter Comprometimento com o Plano do Projeto ; Critérios de Entrada:Especificação de Requisitos, Modelo de Análise e Projeto e Cenários de Teste elaborados.; Critérios de Saída:Software testado.; Responsáveis:Desenvolvedor; Artefatos Requeridos:Especificação de Requisitos; Modelo de Análise e Projeto; Cenários de Teste; Artefatos Produzidos:Software; Ferramentas de Software:Java / IBM WebSphere AD (v.5.1); JUnit (Java); Ambiente de Desenvolvimento (Eclipse; Power++; VSS; etc.); Avaliar o software Descrição:Esta atividade consiste em verificar se os cenários de teste identificados foram implementados corretamente. Pré-Atividades:Codificar Software ; Critérios de Entrada:Software testado pelos desenvolvedores.; Critérios de Saída:Avaliação do software realizada.; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Cenários de Teste; Software; Artefatos Produzidos:Relatório de Avaliação do Software; Ferramentas de Software:Java / IBM WebSphere AD (v.5.1); JUnit (Java); Ambiente de Desenvolvimento (Eclipse; Power++; VSS; etc.); Elaborar Manual do Produto Descrição:Elaborar manual para apoiar o usuário durante a operação do software. Esta atividade é opcional e depende do escopo do projeto. Pré-Atividades:Avaliar o software ; Critérios de Entrada:Software testado.; Critérios de Saída:Manual do Software elaborado; Responsáveis:Desenvolvedor; Participantes:Gerente de Projeto; Artefatos Requeridos:Software; Artefatos Produzidos:Manual do Produto; Ferramentas de Software:Java / IBM WebSphere AD (v.5.1); Word; JUnit (Java); Editor de Texto;Implantação do ProdutoDescrição:Esta macro-atividade tem como objetivo promover a homologação externa doproduto, realizando a implantação da versão preliminar do produto no ambiente dousuário e provendo treinamento para uso do produto.Atividades:
    • 116 Planejar a Implantação do Produto Descrição:Definir um plano de implantação do produto, considerando as características do produto, requisitos de infraestrutura, premissas assumidas para instalação e configurações necessárias para deixá-lo pronto para uso no ambiente do cliente. O treinamento dos usuários para uso do produto também deve estar contido no plano, caso tenha sido previsto em contrato. O plano deve estabelecer a versão a ser entregue para o cliente, o agendamento das visitas para o cliente, a agenda de treinamento, bem como todos os recursos e as pessoas envolvidas com seus respectivos papéis. Pré-Atividades:Avaliar o software ; Critérios de Entrada:Software avaliado.; Critérios de Saída:Plano de implantação elaborado.; Responsáveis:Gerente de Projeto; Participantes:Equipe do Projeto; Artefatos Requeridos:Manual do Produto; Artefatos Produzidos:Plano de Implantação do Produto; Ferramentas de Software:Word; Implantar o Produto Descrição:Estabelecer uma versão do produto a ser entregue para homologação do usuário e implantar o produto no ambiente do cliente. A implantação deve seguir o plano de implantação do produto. Pré-Atividades:Planejar a Implantação do Produto ; Critérios de Entrada:Software avaliado e Plano de Implantação elaborado; Critérios de Saída:Registros de implantaçao assinado.; Responsáveis:Gerente de Projeto; Participantes:Cliente; Equipe do Projeto; Artefatos Requeridos:Software; Plano de Implantação do Produto; Artefatos Produzidos:Registro da Implantação do Produto; Registro de Versão do Software; Ferramentas de Software:Word; SubVersion; Monitorar Implantação do Produto Descrição:Interagir com o usuário no período definido para homologação do produto para retirar dúvidas e acompanhar a utilização. Caso seja identificado algum problema durante a homologação, deve-se criar um plano de ação para corrigir o produto, que pode incluir: a atualização da especificação dos requisitos, da modelagem, do código e respectivos testes, criação de uma nova tag para o produto e atualização da versão no cliente. Pré-Atividades:Planejar a Implantação do Produto ; Critérios de Entrada:Software implantado no ambiente do cliente; Critérios de Saída:Registro de homologação assinado pelo cliente; Responsáveis:Gerente de Projeto; Participantes:Cliente; Equipe do Projeto; Artefatos Requeridos:Plano de Implantação do Produto; Artefatos Produzidos:Plano de Ação; Registro de Homologação Externa; Ferramentas de Software:ActionPlanManager; Word; E-mail;Encerramento da FaseDescrição:Esta macro-atividade tem como objetivo realizar atividades de encerramentoda fase.
    • 117Atividades: Criar Baselines e Estabelecer Registros Descrição:Criar a baseline para a fase e gerar um relatório de versões contendo a situação de cada item de configuração. Este relatório contempla todos os pedidos de alteração realizados, as alterações implementadas e as respectivas versões. Pré-Atividades:Monitorar Implantação do Produto ; Critérios de Entrada:Produto Entregue; Critérios de Saída:Baseline definida.; Responsáveis:Gerente de Projeto; Artefatos Requeridos:Registro de Versão do Software; Manual do Produto; Artefatos Produzidos:Baseline; Relatório das Versões; Ferramentas de Software:GConf; Realizar Auditoria da Configuração Descrição:Esta atividade tem por objetivo realizar uma auditoria para analisar a integridade dos itens de configuração e baselines criados na fase. Em caso de não- conformidades é elaborado um Plano de Ação para correção dos problemas. Pré-Atividades:Criar Baselines e Estabelecer Registros ; Critérios de Entrada:Baseline definida.; Critérios de Saída:Auditoria da Configuração realizada.; Responsáveis:Gerente de Configuração; Artefatos Requeridos:Baseline; Relatório das Versões; Artefatos Produzidos:Relatório de Auditoria da Configuração; Plano de Ação; Ferramentas de Software:ActionPlanManager; Word; Avaliar a Aderência aos Processos na Fase Descrição:Esta atividade deve ser realizada ao final de cada fase e tem por objetivo avaliar, através de um check-list, a aderência ao processo definido. Caso haja não- conformidades, é elaborado um Plano de Ação para correção dos problemas. Esta atividade também visa identificar oportunidades de melhoria nos processos. Pré-Atividades:Realizar Auditoria da Configuração ; Critérios de Entrada:Ter sido realizada a auditoria de configuração.; Critérios de Saída:Check-list de aderência preenchido.; Responsáveis:Gerente da Qualidade; Artefatos Requeridos:Estrutura Analítica do Projeto; Artefatos Produzidos:Check-list de Avaliação da Aderência ao Processo do Projeto; Plano de Ação; Ferramentas de Software:AdaptPro; ActionPlanManager; Excel; Entregar Produto Descrição:Formalizar a entrega do produto. Pré-Atividades:Realizar Auditoria da Configuração ; Critérios de Entrada:Software homologado pelo cliente; Critérios de Saída:Produto aceito pelo cliente.; Responsáveis:Gerente de Projeto; Participantes:Cliente; Artefatos Requeridos:Software; Artefatos Produzidos:Aceite do Produto; Ferramentas de Software:Word;
    • 118Realizar Avaliação do ProjetoDescrição:Esta atividade tem como objetivo realizar uma avaliação ao final doprojeto, documentar seus resultados e lições aprendidas.Pré-Atividades:Entregar Produto ;Critérios de Entrada:Software formalmente aceito pelo usuário.;Critérios de Saída:Avaliação do projeto realizada.;Responsáveis:Gerente de Projeto;Participantes:Equipe do Projeto;Artefatos Produzidos:Registro de Avaliação do Projeto;Ferramentas de Software:Excel;