mps.br guia de implementação nível f

MPS.BR - Melhoria de Processo do Software Brasileiro

Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS-SW:2012

Este guia contm orientaes para a implementao do nvel F do Modelo de Referncia MR-MPS-SW:2012.

Setembro de 2013

Copyright 2013 - SOFTEX Direitos desta edio reservados pela Sociedade SOFTEX A distribuio ilimitada desse documento est sujeita a copyright ISBN (Solicitado Biblioteca Nacional)

MPS.BR Guia de Implementao Parte 2:2013 2/70

Sumrio

1 Prefcio ............................................................................................................. 3

2 Introduo .......................................................................................................... 5

3 Objetivo ............................................................................................................. 6

4 Evoluindo do nvel G para o nvel F ................................................................... 7

5 Comeando a implementao do MR-MPS-SW pelo nvel F ............................. 8

6 Aquisio (AQU) ................................................................................................ 9 6.1 Propsito ........................................................................................................ 9 6.2 Fundamentao terica ................................................................................ 12 6.3 Resultados esperados .................................................................................. 13

7 Gerncia de Configurao (GCO) .................................................................... 18 7.1 Propsito ...................................................................................................... 18 7.2 Fundamentao terica ................................................................................ 20 7.3 Resultados esperados .................................................................................. 22

8 Gerncia de Portflio de Projetos (GPP).......................................................... 32 8.1 Propsito ...................................................................................................... 32 8.2 Fundamentao terica ................................................................................ 33 8.3 Resultados esperados .................................................................................. 34

9 Garantia da Qualidade (GQA) .......................................................................... 38 9.1 Propsito ...................................................................................................... 38 9.2 Fundamentao terica ................................................................................ 40 9.3 Resultados esperados .................................................................................. 41

10 Medio (MED) ............................................................................................ 46 10.1 Propsito ...................................................................................................... 46 10.2 Fundamentao terica ................................................................................ 48 10.3 Resultados esperados .................................................................................. 50

11 Os atributos de processo no nvel F ............................................................. 57 11.1 AP 2.1 - O processo gerenciado ................................................................ 58 11.2 AP 2.2 - Os produtos de trabalho do processo so gerenciados .................. 60

Referncias bibliogrficas ....................................................................................... 63

Lista de colaboradores do Guia de Implementao Parte 2:2011 ........................ 67

Lista de colaboradores do Guia de Implementao Parte 2:2009 ........................ 68

Lista de colaboradores do Guia de Implementao Parte 2 verso 1.1 - Julho/2007 ............................................................................................................................... 69

Lista de colaboradores do Guia de Implementao Parte 2 verso 1.0 Dezembro/2006 ...................................................................................................... 70


1 Prefcio

O MPS.BR1 um programa mobilizador, de longo prazo, criado em dezembro de

2003, coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que conta com apoio do Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Servio Brasileiro de Apoio s Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID).

O objetivo do Programa MPR.BR (acrnimo) a Melhoria de Processo de Software e de Servios no Brasil, com duas metas a alcanar a mdio e longo prazos:

a) meta tcnica, visando criao e aprimoramento dos modelos MPS, com resultados esperados tais como: (i) guias dos modelos MPS; (ii) Instituies Implementadoras (II) credenciadas para prestar servios de consultoria de implementao dos modelos de referncia MR-MPS-SW e MR-MPS-SV; (iii) Instituies Avaliadoras (IA) credenciadas para prestar servios de avaliao seguindo o Mtodo de Avaliao MA-MPS; (iv) Consultores de Aquisio (CA) certificados para prestar servios de consultoria de aquisio de software e servios relacionados;

b) meta de mercado, visando disseminao e adoo dos modelos MPS-SW e MPS-SV, em todas as regies do pas, em um intervalo de tempo adequado, a um custo razovel, tanto em PME (foco principal) quanto em grandes organizaes pblicas e privadas, com resultados esperados tais como: (i) criao e aprimoramento do modelo de negcio MN-MPS; (ii) cursos, provas e workshops; (iii) organizaes que implementaram os modelos MPS; (iv) organizaes com avaliao MPS publicada (prazo de validade de trs anos).

O Programa MPR.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Frum de Credenciamento e Controle (FCC) e a Equipe Tcnica do Modelo (ETM). Por meio destas estruturas, o MPS.BR obtm a participao de representantes de universidades, instituies governamentais, centros de pesquisa e de organizaes privadas, os quais contribuem com suas vises complementares que agregam qualidade ao empreendimento. Cabe ao FCC: (i) emitir parecer que subsidie deciso da SOFTEX sobre o credenciamento de Instituies Implementadoras (II) e Instituies Avaliadoras (IA); (ii) monitorar os resultados das Instituies Implementadoras (II) e Instituies Avaliadoras (IA), emitindo parecer propondo SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS.

Cabe ETM apoiar a SOFTEX sobre os aspectos tcnicos relacionados aos Modelos de Referncia (MR-MPS) e Mtodo de Avaliao (MA-MPS), para: (i)

1 MPS.BR, MR-MPS-SW, MR-MPS-SV, MA-MPS e MN-MPS so marcas da SOFTEX. A sigla

MPS.BR est associada ao Programa MPR.BR Melhoria do Processo de Software Brasileiro, a sigla MPS-SW est associada ao modelo MPS para software Melhoria do Processo de Software e a sigla MPS-SV est associada o modelo MPS para Servios Melhoria do Processo de Servios.


criao e aprimoramento contnuo do MR-MPS-SW, MR-MPS-SV, MA-MPS e seus guias especficos; (ii) capacitao de pessoas por meio de cursos, provas e workshops.

A criao e o aprimoramento do Guia Geral de Software e do Guia Geral de Servios so tambm atribuies da ETM, sendo que este guia faz parte do seguinte conjunto de documentos do modelo MPS:

Guia Geral MPS de Software:2012 [SOFTEX, 2012a];

Guia Geral MPS de Servios:2012 [SOFTEX, 2012b];

Guia de Avaliao:2013 [SOFTEX, 2013i];

Guia de Aquisio de Software:2013 [SOFTEX, 2013a];

Guia de Implementao Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS-SW:2012 [SOFTEX, 2013b];

Guia de Implementao Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS-SW:2012 [SOFTEX, 2013c];

Guia de Implementao Parte 3: Fundamentao para Implementao do Nvel E do MR-MPS-SW:2012 [SOFTEX, 2013d];

Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS-SW:2012 [SOFTEX, 2013e];

Guia de Implementao Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS-SW:2012 [SOFTEX, 2013f];

Guia de Implementao Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS-SW:2012 [SOFTEX, 2013g];

Guia de Implementao Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS-SW:2012 [SOFTEX, 2013h];

Guia de Implementao Parte 8: Implementao do MR-MPS:2011 (Nveis G a A) em organizaes que adquirem software [SOFTEX, 2011a];

Guia de Implementao Parte 9: Implementao do MR-MPS:2011 (Nveis G a A) em organizaes do tipo Fbrica de Software [SOFTEX, 2011b];

Guia de Implementao Parte 10: Implementao do MR-MPS:2011 (Nveis G a A) em organizaes do tipo Fbrica de Teste [SOFTEX, 2011c];

Guia de Implementao Parte 11: Implementao e Avaliao do MR-MPS-SW:2012 (Nveis G a A) em conjunto com o CMMI-DEV v1.3 [SOFTEX, 2012c];

Parte 12 o MR- - /IEC 29110-4-1:2012 - Engenharia de Software - Perfis de ciclo de vida para micro- - - [SOFTEX, 2012d];

Guia de Implementao Parte 13: Mapeamento e sistema de equivalncias entre o MR-MPS-SW:2012 e o MoProSoft:2005 [SOFTEX, 2012e].


As alteraes deste Guia de Implementao em relao verso 2012 so decorrentes de:

incluso do Modelo de Referncia para Servios (MR-MPS-SV); e

alterao do logo da SOFTEX.

As alteraes deste Guia de Implementao em relao verso 2009 so decorrentes de:

mudanas realizadas na verso 2009 do Guia Geral;

correo ortogrfica e gramatical;

adequao das referncias bibliogrficas;

incluso de notas explicativas contidas nas partes 8, 9 e 10 do Guia de Implementao;

incluso de comentrio sobre monitorao dos processos crticos do fornecedor na explicao sobre o resultado esperado AQU6.

reviso dos comentrios e detalhamento das explicaes dos resultados esperados do processo Gerncia de Portflio de Projetos (GPP);

incluso de comentrio sobre o nmero de medidas que devem ser definidas no escopo do resultado esperado MED2;

incluso de comentrio sobre o nmero de medidas que devem ser definidas no contexto da implementao do RAP4, alm de comentrios sobre medidas que podem ser consideradas e a importncia deste resultado esperado para os nveis B e A do MR-MPS-SW;

incluso de exemplos de requisitos de documentao de produtos de trabalho relacionados implementao do RAP11.

2 Introduo

As mudanas que esto ocorrendo nos ambientes de negcios tm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da viso tradicional baseada em reas funcionais em direo a redes de processos centrados no cliente. A competitividade depende, cada vez mais, do estabelecimento de conexes nestas redes, criando elos essenciais nas cadeias produtivas. Alcanar competitividade pela qualidade, para as empresas de software e servios, implica tanto na melhoria da qualidade dos produtos de software e servios correlatos, como dos processos de produo e distribuio.

Desta forma, assim como para outros setores, qualidade fator crtico de sucesso para a indstria de software e servios. Para que se tenha um setor de software e servios competitivo, nacional e internacionalmente, essencial que os empreendedores do setor coloquem a eficincia e a eficcia dos seus processos em foco nas empresas, visando oferta de produtos de software e servios correlatos conforme padres internacionais de qualidade.


Busca-se que os modelos MPS-SW e MPS-SV sejam adequados ao perfil de empresas com diferentes tamanhos e caractersticas, pblicas e privadas, embora com especial ateno s micro, pequenas e mdias empresas. Tambm se espera que os modelos MPS sejam compatveis com os padres de qualidade aceitos internacionalmente e que tenham como pressuposto o aproveitamento de toda a competncia existente nos padres e modelos de melhoria de processo j disponveis. Dessa forma, o MR-MPS-SW tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princpios de engenharia de software de forma adequada ao contexto das empresas, estando em consonncia com as principais abordagens internacionais para definio, avaliao e melhoria de processos de software. Da mesma forma, o modelo MR-MPS-SV est em consonncia com as principais abordagens internacionais para servios.

Os modelos MPS baseiam-se nos conceitos de maturidade e capacidade de processo. Dentro desse contexto, o modelo MPS possui quatro componentes: Modelo de Referncia para Software (MR-MPS-SW), Modelo de Referncia para Servios (MR-MPS-SV), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MN-MPS).

Os modelos MPS esto descritos por meio de documentos em formato de guias:

Guia Geral para Software: contm a descrio geral dos modelos MPS e detalha o Modelo de Referncia para Software (MR-MPS-SW), seus componentes e as definies comuns necessrias para seu entendimento e aplicao [SOFTEX, 2012a];

Guia Geral para Servios: contm a descrio geral dos modelos MPS e detalha o Modelo de Referncia para Servios (MR-MPS-SV), seus componentes e as definies comuns necessrias para seu entendimento e aplicao [SOFTEX, 2012b];

Guia de Aquisio: descreve um processo de aquisio de software e servios correlatos. descrito como forma de apoiar as instituies que queiram adquirir produtos de software e servios correlatos apoiando-se no MR-MPS-SW [SOFTEX, 2013a];

Guia de Avaliao: descreve o processo e o Mtodo de Avaliao MA-MPS, os requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA) [SOFTEX, 2013i];

Guia de Implementao: srie de treze documentos que fornecem orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS-SW [SOFTEX, 2013b], [SOFTEX, 2013c], [SOFTEX, 2013d], [SOFTEX, 2013e], [SOFTEX, 2013f], [SOFTEX, 2013g], [SOFTEX, 2013h], [SOFTEX, 2011a], [SOFTEX, 2011b], [SOFTEX, 2011c], [SOFTEX, 2012c], [SOFTEX, 2012d], [SOFTEX, 2012e].


3 Objetivo

O Guia de Implementao fornece orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS-SW, detalhando os processos contemplados nos respectivos nveis de maturidade e os resultados esperados com a implementao dos processos. Este documento corresponde parte 2 do Guia de Implementao e aborda a implementao do nvel de maturidade F.

Este documento destinado, mas no est limitado, a organizaes interessadas em utilizar o MR-MPS-SW para melhoria de seus processos de software e a Instituies Implementadoras (II). O contedo deste documento informativo, ou seja, no se espera que uma organizao implementando o MR-MPS-SW atenda a todos os itens citados na explicao referente aos resultados esperados. As observaes presentes neste documento procuram apenas explicitar elementos importantes na interpretao dos resultados esperados. Durante uma avaliao MPS, s requerido o atendimento aos resultados esperados definidos no Guia Geral. Os avaliadores MPS devem analisar se a implementao dos processos na organizao atende a cada resultado, com abertura a mltiplas formas vlidas de implementao.

4 Evoluindo do nvel G para o nvel F

No nvel G, a organizao est estruturando seus projetos com base na viso conceitual de projeto e de suas principais fases como planejamento e controle da sua evoluo. Nesse nvel o papel fundamental para a melhoria de processos do gerente de projeto, pois ele quem tem a responsabilidade por atender aos objetivos do projeto em relao ao prazo, custo, esforo e requisitos.

O principal foco do nvel F agregar processos de apoio gesto do projeto no que diz respeito Garantia da Qualidade (GQA) e Medio (MED), bem como aqueles referentes organizao dos artefatos de trabalho por meio da Gerncia de Configurao (GCO). Esses processos adicionais possibilitam uma maior visibilidade de como os artefatos so produzidos nas vrias etapas do projeto e do processo. Essa visibilidade tem como foco analisar se os artefatos produzidos no processo e no projeto esto de acordo com os padres e procedimentos estabelecidos, o que ajuda muito na implantao do programa de melhoria de processo sob o ponto de vista de institucionalizao. Como muitas organizaes subcontratam etapas do processo de desenvolvimento ou componentes especficos do produto, essa atividade tambm dever ser controlada com o mesmo rigor que as questes internas, mas respeitando o modo com que outras organizaes trabalham. Os requisitos teis para que esse controle seja feito de forma adequada definido no processo Aquisio (AQU). Alm disso, implantao do processo Gerncia de Portflio de Projetos (GPP) possibilita s organizaes uma gerncia mais efetiva dos recursos disponveis e investimentos realizados visando atender os objetivos estratgicos da organizao.


No nvel G e no nvel F, o projeto pode usar os seus prprios padres e procedimentos, no sendo necessrio que se tenha padres em nvel organizacional. Se, porventura, a organizao possuir processos j definidos e os projetos necessitarem adaptar os processos existentes, esse fato dever ser declarado durante o planejamento do projeto. Essas adaptaes podem incluir alterao em processos, atividades, ferramentas, tcnicas, procedimentos, padres, medidas, dentre outras.

5 Comeando a implementao do MR-MPS-SW pelo nvel F

A implementao dos processos para o nvel F pode ser feita em qualquer sequncia, visto que os processos desse nvel so de apoio gesto do projeto, fornecendo maior qualidade e controle aos produtos de trabalho. Uma vez que necessitam de processos de apoio, as organizaes podem ter a necessidade de incorporar sua equipe alguns novos perfis para realizar atividades de garantia da qualidade, gerncia de configurao, medio, gerncia do portflio de projetos e aquisio de produtos. Note, no entanto, que a existncia de um novo perfil no obriga necessariamente a contratao de novas pessoas, mas a definio de novas competncias necessrias e delimitao de novas responsabilidades.

Existem organizaes que iniciam a implementao dos nveis G e F simultaneamente. O impacto dessa deciso se reflete no aumento do esforo e tempo para a implementao dos processos. Diferentes abordagens podem ser utilizadas para a implementao dos processos e no h uma que seja adequada a todas as empresas.

A deciso sobre a necessidade de implementao do processo Aquisio um ponto a ser considerado logo no incio do planejamento do programa de melhoria para atendimento ao nvel F. A execuo desse processo no obrigatria para todas as organizaes, mas sua excluso de uma avaliao deve ser justificada. H, no entanto, situaes em que uma excluso no possvel. De forma geral, esse processo deve ser executado e, portanto, implementado na organizao/unidade organizacional quando se tem algum componente do produto de software entregue para o cliente e que esteja sendo desenvolvido por profissionais externos unidade organizacional. Outras situaes so descritas na Seo 6.1.

Comentrios adicionais para implementao em diferentes tipos de organizao

Adquirentes de Software

(Parte 8)

Para organizaes Adquirentes de Software, conforme definidas na Parte 8 do Guia de Implementao, a implementao deste processo obrigatria.

Fbrica de Software

(Parte 9)

Sem comentrio adicional para este resultado.


Fbrica de Teste

(Parte 10)


6 Aquisio (AQU)

6.1 Propsito

O propsito do processo Aquisio gerenciar a aquisio de produtos que satisfaam s necessidades expressas pelo adquirente.

No contexto do MR-MPS-SW, considera-se que o termo produto pode incluir tambm servios, desde que estes sejam entregues como parte do produto final ao cliente.

O processo Aquisio (AQU) tem como foco o planejamento ou preparao para aquisio, a seleo do fornecedor e a monitorao do contrato, processos e produtos com o objetivo de assegurar a qualidade do produto que est sendo subcontratado quando este for integrado ao produto que ser entregue para o cliente. Todos os aspectos resultantes da Aquisio devero estar claramente definidos no contrato entre as partes, pois se no estiverem, alguns controles e avaliaes necessrios no podero ser aplicados. Esse contrato pode variar no grau de formalismo, dependendo da complexidade dos requisitos, dos produtos a serem gerados e do tipo de empresa contratante. No caso de rgo pblico, por exemplo, h uma srie de exigncias legais a serem observadas.

A implementao do processo Aquisio assegura a qualidade do componente ou produto que est sendo contratado. Assim, torna-se importante ressaltar algumas das situaes nas quais esse processo utilizado:

O processo Aquisio obrigatrio 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 Aquisio definido, implantado e institucionalizado para minimizar riscos que podem comprometer os resultados esperados, tais como riscos de no cumprimento de prazos, do produto adquirido no ter a qualidade esperada, do produto adquirido no ter compatibilidade com a arquitetura tecnolgica definida, dificuldades de integrao, problemas de suporte etc. No entanto, se a aquisio ocorrer antes do incio do desenvolvimento do produto de software, ento o processo Aquisio recomendado, mas no obrigatrio.

O processo Aquisio obrigatrio para uma empresa desenvolvedora de software que possui duas ou mais unidades organizacionais com processos diferentes e uma contrata a outra para o desenvolvimento de uma parte do software. Esse processo tambm obrigatrio se ambas as unidades organizacionais tiverem passado por avaliaes MA-MPS oficiais. Os relacionamentos entre as divises e colegas de trabalho, geralmente, so informais e isto pode trazer altos riscos para o projeto, principalmente se a aquisio no for planejada e gerenciada de forma adequada e visando garantir


os resultados esperados pelo projeto de software. No caso de as unidades organizacionais terem passado por avaliaes MA-MPS oficiais, o processo Aquisio tambm deve ser utilizado para gerenciar as atividades relevantes do ciclo de desenvolvimento do software que permitiro assegurar a qualidade do produto resultante. No entanto, se uma organizao necessita de mais mo-de-obra a ser alocada diretamente ao projeto, no necessria a utilizao desse processo, pois as pessoas alocadas seguiro o processo da organizao.

O processo Aquisio obrigatrio para uma empresa que desenvolve produtos de software em parceria (estratgicas e/ou tecnolgicas) com outras empresas. O processo Aquisio deve ser utilizado para garantir que os componentes de software desenvolvidos pela empresa parceira sejam avaliados de acordo com os critrios estabelecidos, bem como sua incorporao ao produto entregue ao cliente seja planejada e gerenciada de forma adequada. Para tanto, recomendado, tambm, que sejam analisados, declarados e gerenciados os acordos, estratgias, responsabilidades, obrigaes e restries das empresas parceiras no desenvolvimento de um produto de software.

O processo Aquisio obrigatrio para uma empresa desenvolvedora de software que contratar terceiros para desenvolver partes do produto de software, mesmo que a empresa terceirizada tenha passado por uma avaliao MA-MPS oficial. Se a empresa terceirizada seguir o mesmo processo definido pela empresa que a contratou, este processo dever ser auditado pela empresa contratante para garantir o correto fornecimento. Se a empresa terceirizada seguir um novo processo, as atividades crticas para a qualidade do produto resultante devero ser identificadas e acompanhadas durante todo o fornecimento. Os riscos de contratar terceiros para desenvolver partes do produto de software que ser entregue ao cliente so os mesmos riscos relacionados q w C T Commercial off the shelf software).

O processo Aquisio obrigatrio para uma empresa que estiver implantando um programa de reutilizao conforme previsto pelo processo Desenvolvimento para Reutilizao (DRU) e precisar adquirir ativos de domnio.

Alm disso, em algumas situaes, a obrigatoriedade do processo Aquisio depende do foco que dado na aquisio dos produtos. Por exemplo, o processo Aquisio pode ou no ser obrigatrio para uma empresa desenvolvedora de software que utilizar um banco de dados (por exemplo, Oracle ou MS SQL Server) no fornecimento de um produto e/ou servio de software. Se a responsabilidade pela aquisio das licenas de uso do banco de dados for da empresa fornecedora do produto de software ao cliente, ento existem riscos envolvidos para o cliente e importante a definio e institucionalizao do processo Aquisio para minimizar esses riscos. No entanto, se a responsabilidade pela aquisio das licenas de uso do banco de dados for do cliente, ento o processo Aquisio no necessita ser executado pelo fornecedor do produto de software, mas poderia ser executado pelo cliente.

O processo Aquisio no obrigatrio para uma empresa desenvolvedora de software que adquirir uma ferramenta e/ou componente de software para aumentar


a sua produtividade, por exemplo, bibliotecas com padres e componentes para reutilizao no desenvolvimento de software ou ferramentas de automatizao de testes de software. No entanto, o processo Aquisio recomendado caso a aquisio de ferramentas e/ou componentes de software implicar em riscos para o projeto, por exemplo, as ferramentas e/ou componentes de software interferirem em requisitos de qualidade como interoperabilidade, eficcia, manutenibilidade etc.

O processo Aquisio tambm no obrigatrio para uma empresa desenvolvedora w q q w v b que ser entregue juntamente com o produto de software ao cliente. No entanto, os w v b q podem ser gerenciados por meio dos mecanismos previstos pelo processo Gerncia de Reutilizao.

Independente da situao, se o processo Aquisio for excludo da avaliao MA-MPS, o Plano de Avaliao deve conter a justificativa da excluso.

Mecanismos definidos e estabelecidos pela aplicao de determinados resultados esperados do processo Gerncia de Projetos tambm podem ser aproveitados e utilizados no escopo da aquisio, por exemplo, a identificao de problemas e as aes gerenciais a serem tomadas at a concluso. Alm disso, a interseco com o processo Gerncia de Projetos est presente pela necessidade de se planejar e acompanhar as atividades do projeto de aquisio, como forma de se ter visibilidade sobre a execuo das atividades do projeto. O fornecedor pode ter o seu prprio planejamento, mas de se esperar que este planejamento esteja compatibilizado com o planejamento do projeto de aquisio para no impact-lo.

Interseces com o processo Gerncia de Requisitos podem estar presentes no estabelecimento dos critrios de aceitao, seja como base para a seleo dos fornecedores de solues ou para a aquisio de produtos de prateleira (COTS Commercial off the shelf software).



(Parte 8)

No so permitidas excluses de resultados deste processo.

Fbrica de Software

(Parte 9)

A Fbrica de Software est sujeita s mesmas regras de excluso do processo de Aquisio (AQU) que as demais organizaes. permitida a excluso de todos os resultados esperados do processo em organizaes do tipo Fbrica de Software.

A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de processos devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao.

Como no existem especificidades para organizaes do tipo Fbrica de Software, no foram includos comentrios nos resultados esperados.


Fbrica de Teste

(Parte 10)

A Fbrica de Teste est sujeita s mesmas regras para excluso do processo de Aquisio que as demais organizaes.

So permitidas excluses de todos os resultados esperados do processo em organizaes do tipo Fbrica de Teste.

A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao.

Como no existem especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.

6.2 Fundamentao terica

A aquisio do projeto inclui os processos necessrios obteno de bens e servios externos organizao executora. Segundo a ISO/IEC 12207 [ISO/IEC, 2008], o propsito do processo Aquisio obter um produto e/ou servio que satisfaa as necessidades expressas pelo cliente. O processo inicia com a identificao de uma necessidade do cliente e encerra com a aceitao do produto e/ou servio [ISO/IEC, 2008]. O adquirente pode subcontratar a execuo de alguma atividade ou produto, mas sempre dele a responsabilidade principal pelo produto final. durante a aquisio que o contrato estabelecido com o fornecedor, o qual pode ter vrios nveis de formalidade.

O processo Aquisio tem como objetivo selecionar um fornecedor e garantir que o fornecedor entregue o produto conforme definido no contrato. A ISO/IEC 12207 [ISO/IEC, 2008] tem foco no acordo estabelecido entre as partes como ponto fundamental para o sucesso da aquisio, pois parte do princpio de que se o contrato estiver incorreto, incompleto ou inconsistente, existiro dificuldades para que ele seja executado com sucesso. Outra fonte potencial de problemas a seleo de fornecedores, pois quando se contrata uma organizao que no est preparada para entregar o produto, muito difcil que esse processo seja executado de forma satisfatria.

A execuo do processo Aquisio pode ser feita para produtos de prateleira, produtos sob encomenda, componentes de produtos de software ou servios.

A identificao e seleo de produtos de prateleira podem ser inicialmente realizadas de modo menos formal, assegurando que eles satisfazem os requisitos especificados em um relatrio de aquisio de produto. Caso a aquisio inclua produtos de prateleira, pode ser necessrio desenvolver critrios para avaliar os produtos candidatos em relao aos requisitos e critrios associados, que podem incluir: funcionalidades; desempenho; confiabilidade; outras caractersticas de qualidade; termos e condies de garantia dos produtos; riscos; responsabilidades dos fornecedores para a manuteno e suporte dos produtos. A deciso pela aquisio pode estar baseada em estudos de mercado, listas de preos, critrios de avaliao e relatrios de desempenho dos fornecedores e sua habilidade de


entrega. Uma vez definida a aquisio, pode ser necessrio avaliar o impacto dos produtos candidatos nos planos e compromissos do projeto, incluindo: custos dos produtos; custos e esforos para incorporar os produtos dentro do projeto; requisitos de segurana; benefcios e impactos que podem resultar em verses futuras do produto; riscos envolvidos; suporte (respostas s questes e relatrios de problemas); manuteno. O PMBOK [PMI, 2008a] subdivide a rea de gerncia de aquisio do projeto em:

Planejamento da aquisio determinao do que contratar e quando;

Preparao da aquisio documentao dos requisitos do produto e identificao dos fornecedores potenciais;

Obteno de propostas obteno de propostas de fornecimento, conforme apropriado a cada caso (cotaes de preo, cartas-convite, licitao);

Seleo de fornecedores escolha entre os possveis fornecedores;

Administrao de contratos gerenciamento dos relacionamentos com os fornecedores;

Encerramento do contrato concluso e liquidao do contrato, incluindo a resoluo de qualquer item pendente.

A aquisio discutida sob o ponto de vista do adquirente na relao adquirente-fornecedor. Esta relao pode existir em muitos nveis do projeto. Dependendo da rea de aplicao, o fornecedor pode ser chamado de subcontratado ou de vendedor. Dentro do contexto do processo Aquisio, so considerados no somente o produto de software propriamente dito, mas tambm os servios tipicamente relacionados ao desenvolvimento, implantao, suporte operao e manuteno do software, tais como treinamento, configurao do software e do ambiente de operao, manutenes corretivas, evolutivas e adaptativas, entre outros.

Alguns problemas na aquisio de software so originados por prticas de gerenciamento ineficazes. Os problemas so caracterizados pela falha contnua na aquisio de grandes sistemas de software e pelo crescimento dos esforos para manter o custo, o prazo e para atingir os objetivos definidos. Um projeto pode fracassar devido imaturidade de seus processos de aquisio ou quando se contrata uma organizao com processo de desenvolvimento de software imaturo.

6.3 Resultados esperados

6.3.1 AQU1 As necessidades de aquisio, as metas, os critrios de aceitao do produto, os tipos e a estratgia de aquisio so definidos

Este resultado visa fundamentar a aquisio de produtos, fornecendo um melhor entendimento do que deve ser adquirido e planejando como esta aquisio dever ocorrer.

A identificao da necessidade de aquisio pode ocorrer de vrias maneiras. Pode surgir, por exemplo, durante um levantamento de requisitos, derivar de uma


oportunidade de negcio ou resultar de objetivos estratgicos da organizao, dentre outros.

Independentemente da sua origem, pode ser necessrio analisar esta necessidade em relao possibilidade de se adquirir, desenvolver internamente ou melhorar algum produto. Riscos e problemas futuros podem ser minimizados se as decises forem amadurecidas, melhor definidas, formalizadas e planejadas.

Para uma anlise do tipo fazer ou comprar, iderados fatores como: funes que o produto prover e como essas se encaixaro no projeto; disponibilidade dos recursos do projeto e perfis; custo para adquirir versus custo de desenvolvimento interno; datas crticas de entrega e integrao; estratgia de alianas, incluindo requisitos de negcio de alto nvel; pesquisa de produtos disponveis no mercado, incluindo produtos de prateleira; funcionalidade e qualidade dos produtos disponveis; impacto na concorrncia; licenas, responsabilidades, permisses e limitaes associadas aos produtos que esto sendo adquiridos; disponibilidade do produto; assuntos relacionados propriedade; reduo de risco.

Uma vez que se decida pela aquisio, torna-se necessrio analisar as necessidades levantadas, definir objetivos e identificar os requisitos a serem satisfeitos. Estes requisitos devem ser analisados e validados em relao s necessidades e objetivos definidos, visando reduzir os riscos de insucesso ao final do projeto.

Com os requisitos estabelecidos, revisados e validados, possvel definir e acordar com as partes interessadas os critrios de aceitao do produto, bem como a forma de avaliao a ser aplicada, que podem incluir: tempo de resposta, arquitetura do produto, usabilidade, acessibilidade, portabilidade etc.

O entendimento obtido possibilita definir o tipo (pacote, terceirizao do servio) e a estratgia para aquisio, cujas opes podem incluir: adquirir pacotes a serem possivelmente configurados ou adaptados; obter produtos e servios por meio de acordo contratual; obter produtos e servios de outra parte da organizao, por exemplo, outra parte da corporao, agncia do governo etc., ou ainda a combinao de algumas destas estratgias.

A partir dos critrios de aceitao e da estratgia de aquisio definida, caso apropriado, tambm pode ser gerado um plano de teste de aceitao, especificando condies, atividades e responsabilidades pela execuo dos testes necessrios para o produto a ser adquirido.

6.3.2 AQU2 Os critrios de seleo do fornecedor so estabelecidos e usados para avaliar os potenciais fornecedores

Este resultado requer a identificao e documentao dos critrios a serem utilizados para julgamento do perfil e capacidade requeridos do fornecedor para atender ao contrato pretendido, bem como a forma de avaliao a ser aplicada. Exemplos de critrios de seleo podem incluir: localizao geogrfica do fornecedor; registro de desempenho do fornecedor em trabalhos similares; habilidade para trabalhar com o fornecedor proposto; capacidade de engenharia; capacidade gerencial; experincia anterior em aplicaes similares; disponibilidade de pessoal para executar o trabalho; facilidades e recursos a serem


disponibilizados; nvel mnimo de maturidade esperado da organizao; entre outros.

Com base nos critrios estabelecidos, pode-se gerar um conjunto de potenciais fornecedores, bem como um relatrio de avaliao desses fornecedores (aplicando os critrios definidos) e uma lista resultante de potenciais fornecedores. Para estes potenciais fornecedores um pedido de proposta pode ser feito, geralmente com um prazo definido para retorno.

6.3.3 AQU3 O fornecedor selecionado com base na avaliao das propostas e dos critrios estabelecidos

Um pedido de proposta geralmente caracteriza o produto requerido e as condies de entrega, alm das condies gerais esperadas da aquisio, prazos e valores envolvidos, critrios de seleo e outras questes formais a serem seguidas. As propostas dos fornecedores geralmente contm o entendimento do problema pelo fornecedor, sua abordagem e suas sugestes de soluo tcnica, alm de um plano de entrega do produto e as condies financeiras da proposta.

Aps o recebimento das propostas, estas devem ser avaliadas considerando-se os critrios de seleo anteriormente estabelecidos. Tambm uma boa estratgia avaliar a habilidade e capacidade do fornecedor para atender aos requisitos especificados e os riscos associados a cada fornecedor e sua proposta. A seleo do fornecedor deve ser formalizada, por exemplo, pelo uso de laudo, relatrio ou ata.

6.3.4 AQU4 - Um acordo que expresse claramente as expectativas, responsabilidades e obrigaes de ambas as partes (cliente e fornecedor) estabelecido e negociado entre elas

Antes de estabelecer um acordo, uma boa prtica revisar os requisitos a serem atendidos pelo fornecedor para verificar se refletem as negociaes realizadas, de modo que todos possuam um entendimento comum do que deve ser feito e das condies necessrias para que seja executado.

O acordo com o fornecedor deve ser preparado, negociado e documentado. Em geral, inclui: expectativas (declarao do trabalho a ser executado em termos de escopo, requisitos preliminares, termos e condies, principais produtos de trabalho a serem entregues, se aplicvel) e as responsabilidades e as obrigaes de ambas as partes (cliente e fornecedor). Para garantir mais segurana a ambas as partes, pode-se definir tambm um cronograma e/ou um processo de aceitao definido; um plano de comunicao; o que o projeto dever prover para o fornecedor; facilidades disponveis para construo do projeto (documentao, ferramentas, servios); identificao das pessoas responsveis pelo acordo e das autorizadas para alter-lo, de ambas as partes; identificao de como as mudanas de requisitos e mudanas no acordo com os fornecedores so determinadas, comunicadas e tratadas; identificao dos padres e procedimentos do cliente que sero seguidos; identificao das dependncias crticas entre o projeto e o fornecedor; identificao do tipo e profundidade da superviso do projeto com o fornecedor; procedimentos e critrios de avaliao a serem usados para monitorar o desempenho do fornecedor; identificao das responsabilidades do fornecedor para


manuteno e suporte dos produtos adquiridos; identificao das garantias, propriedades e direitos de uso para os produtos adquiridos etc.

Para a celebrao do acordo, importante que as partes revisem seu contedo, negociem seus termos e condies, bem como concordem com todos os requisitos, antes que seja firmado.

Quando necessrio, o acordo com o fornecedor poder ser revisto. Medidas legais podem ser tomadas, se pertinente. Devido a isso, as modificaes requeridas por qualquer uma das partes devem ser registradas.

6.3.5 AQU5 Um produto que satisfaa a necessidade expressa pelo cliente adquirido baseado na anlise dos potenciais candidatos

A partir da anlise dos fornecedores identificados como potenciais candidatos, o produto adquirido utilizando-se um conjunto de critrios pr-estabelecidos.

Em geral, o produto adquirido com base no s na anlise do fornecedor, mas tambm na existncia de uma avaliao da qualidade do produto baseada em todos os requisitos, critrios e padres definidos. Esta anlise pode variar de acordo com o tipo de aquisio sendo feita, por exemplo, aquisio de produto pronto, customizvel, sob encomenda ou de escopo aberto (no caso de contratao de fbrica ou servios correlatos: desenvolvimento, manuteno etc.).

No caso de servios, todos os artefatos so comumente avaliados durante o desenvolvimento do projeto de acordo com critrios de aceitao definidos para cada um e com os padres estabelecidos.

Em qualquer situao, o acordo formal definido entre o adquirente e o fornecedor deve ser executado conforme definido.

6.3.6 AQU6 A aquisio monitorada de forma que as condies especificadas sejam atendidas, tais como custo, cronograma e qualidade, gerando aes corretivas quando necessrio

Visando garantir o desempenho esperado, necessrio que se monitore a aquisio, o que pode ser feito a partir dos termos definidos no acordo estabelecido ou, por exemplo, pela troca de informaes sobre o progresso tcnico, inspeo do desenvolvimento, solicitaes de mudana, acompanhamento de problemas etc..

As atividades de monitorao podem envolver: preparar, conduzir e comunicar revises (com participao dos principais envolvidos); monitorar o progresso e o desempenho do fornecedor, em termos de cronograma, esforo, custo e desempenho tcnico; acompanhar processos de garantia da qualidade e gerncia de configurao. Alm disso, tambm pode-se monitorar riscos envolvendo o fornecedor e, quando necessrio, tomar aes corretivas, identificando, documentando e acompanhando o fechamento de todos os itens de ao.

Existem alguns processos do fornecedor que podem ser considerados crticos para o sucesso do projeto e, portanto, podem interferir na qualidade final do produto adquirido. Por exemplo, ao se contratar o desenvolvimento de um produto, requisitos especiais de qualidade e testes podem ser necessrios ou, ento, pode ser necessrio o controle mais efetivo das configuraes e verses do produto


adquirido. Em geral, processos que forem identificados como crticos deveriam ser monitorados em relao conformidade com os requisitos do projeto. A anlise dos resultados do monitoramento destes processos pode detectar questes e problemas que possivelmente afetem a habilidade do fornecedor em satisfazer o acordo estabelecido.

Como em toda monitorao, pode ser preciso replanejamento, renegociao ou rever o acordo com o fornecedor, o que pode levar reviso dos planos do projeto, cronogramas e compromissos, de forma a refletir os novos termos do acordo.

Tipicamente, este monitoramento resulta em relatrios de progresso e desempenho do fornecedor e, quando aplicvel, registro de acompanhamento de problemas e aes corretivas at a sua concluso.

6.3.7 AQU7 O produto entregue e avaliado em relao ao acordado e os resultados so documentados

Para garantir que o produto entregue seja compatvel com os termos do acordo estabelecido necessrio que seja avaliado previamente aceitao. Para isso, pode-se: revisar e obter acordo com os principais envolvidos sobre os procedimentos de aceitao; conduzir e documentar testes de aceitao do produto, conforme critrios estabelecidos, gerando relatrios com os resultados obtidos; assegurar que os produtos adquiridos satisfazem os requisitos acordados; assegurar que o acordo com o fornecedor foi satisfeito, por meio de revises, trmino e aceitao dos procedimentos de teste e auditorias de configurao. Tambm pode ser necessrio confirmar que os compromissos no tcnicos associados aos produtos de trabalho adquiridos esto satisfeitos, o que pode incluir verificar se: foram disponibilizadas a licena apropriada, a garantia e a propriedade de uso; os acordos de suporte ou manuteno foram definidos (ou executados); todos os materiais de suporte foram recebidos.

Para encerramento da aquisio, pode ser necessrio estabelecer e obter acordo com o fornecedor em relao a um plano de ao para qualquer produto de trabalho adquirido que no passe pela reviso ou teste de aceitao. Neste caso, importante que se identifique, documente e acompanhe os itens de ao para encerramento.

6.3.8 AQU8 O produto adquirido incorporado ao projeto, caso pertinente

Aps o produto ser entregue e aceito, pode ser necessrio incorpor-lo ao projeto. As condies para que essa incorporao acontea de forma adequada podem assegurar 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 manuteno dos produtos adquiridos. Outros aspectos relacionados ao armazenamento, distribuio e uso dos produtos adquiridos podem ser necessrios de forma a respeitar as condies e os termos especificados no acordo ou licena do fornecedor. Assim sendo, poder ser necessrio definir, executar e registrar um plano de incorporao do produto ao projeto, contendo os cuidados necessrios com a transferncia do produto para o projeto, referncia a testes de integrao a serem realizados, treinamentos necessrios, manuteno e suporte, dentre outros.


7 Gerncia de Configurao (GCO)

7.1 Propsito

O propsito do processo Gerncia de Configurao estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibiliz-los a todos os envolvidos.

A Gerncia de Configurao a disciplina responsvel por controlar a evoluo de sistemas de software [DART, 1991]. Apesar de existir um forte apelo para o uso da Gerncia de Configurao durante a etapa de manuteno, a sua aplicao no se restringe somente a essa etapa do ciclo de vida do software [IEEE, 1987]. Durante o desenvolvimento, o sistema de Gerncia de Configurao fundamental para prover controle sobre os produtos de trabalho produzidos e modificados por diferentes engenheiros de software. Alm disso, esse sistema possibilita um acompanhamento minucioso do andamento das tarefas de desenvolvimento.

A Gerncia de Configurao usualmente se inicia na identificao das partes que constituem o software. Essas partes, denominadas itens de configurao, representam a agregao de hardware, software ou ambos, tratados pela Gerncia de Configurao como um elemento nico [IEEE, 1990]. Em funo da granularidade utilizada em um contexto de software, um item de configurao pode ser formado por um conjunto de produtos de trabalho, bem como um nico produto de trabalho pode ser formado por vrios itens de configurao.

Em determinados momentos do ciclo de vida de desenvolvimento e manuteno do software, esses itens de configurao so agrupados e verificados, constituindo configuraes do software voltadas para propsitos especficos, denominadas baselines. Essas configuraes representam conjuntos de itens de configurao formalmente aprovados que servem de base para as etapas seguintes de desenvolvimento [IEEE, 1990]. Desta forma, com a utilizao de processos formais de controle de modificaes sobre as baselines, o processo Gerncia de Configurao (GCO) atinge o seu propsito de manter a integridade dos produtos de trabalho. Finalmente, esses produtos de trabalho so submetidos a um processo de liberao (release), que representa a notificao formal e distribuio de uma verso aprovada do software [IEEE, 2005].

Como pode ser constatado, a Gerncia de Configurao no se prope a definir quando e como devem ser executadas as modificaes nos produtos de trabalho, papel este reservado ao prprio processo de desenvolvimento de software. A sua atuao ocorre como processo auxiliar de controle e acompanhamento.

O escopo do processo Gerncia de Configurao no se aplica unicamente aos produtos de trabalho dos processos de um determinado nvel do MR-MPS-SW. Todos os produtos de trabalho dos processos de software em uso pela organizao - sejam eles de desenvolvimento, manuteno ou apoio - so considerados. importante notar que a Gerncia de Configurao um importante mecanismo para aumentar o controle sobre os produtos de trabalho.

O processo Gerncia de Configurao tem uma interseo com todos os demais processos do MR-MPS-SW por meio do atributo de processo RAP13, que


b os produtos de trabalho so colocados em nveis apropriados de controle. Os nveis de controle podem variar de acordo com a importncia ou criticidade dos produtos de trabalho, mas devem ser adequados a cada caso especfico. Assim, para produtos de trabalho que requerem um controle mais formal, a Gerncia de Configurao aplicvel, tanto no contexto de projetos como no contexto organizacional. Alguns documentos, no entanto, podem ser armazenados com um simples controle de acesso ou, ento, serem versionados sem necessidade de um controle formal de mudana. Definir quais produtos de trabalho sero sujeitos a quais nveis de controle parte da execuo do processo de Gerncia de Configurao.

O processo Gerncia de Configurao est intimamente relacionado com outros processos do MR-MPS-SW. Por exemplo: o processo Gerncia de Projetos (GPR) pode apoiar no planejamento do processo Gerncia de Configurao; o processo Gerncia de Decises (GDE) pode apoiar na atividade de avaliao de solicitaes de modificao do processo Gerncia de Configurao.

O processo Gerncia de Configurao pode tambm apoiar o processo Gerncia de Requisitos (GRE) no que diz respeito ao controle de modificaes sobre os requisitos e o processo Integrao do Produto (ITP) no que diz respeito ao controle da evoluo de interfaces.



(Parte 8)


Fbrica de Software

(Parte 9)



Fbrica de Teste

(Parte 10)


A Gerncia de Configurao na Fbrica de Teste deve abranger os produtos de trabalho e artefatos relacionados ao escopo definido para o projeto da Fbrica de Teste. Mecanismos para correlao com a configurao do produto de software que est sendo testado devem ser providos para que os resultados do processo de teste sejam gerenciados e controlados.

Como no existem outras especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.



A Gerncia de Configurao pode ser tratada sob diferentes perspectivas em funo do papel exercido pelo participante do processo de desenvolvimento de software [ASKLUND e BENDIX, 2002]. Na perspectiva gerencial, a Gerncia de Configurao dividida em cinco funes [IEEE, 2005]: identificao da configurao, controle da configurao, contabilizao da situao da configurao, avaliao e reviso da configurao e gerenciamento de liberao e entrega.

A funo de identificao da configurao tem por objetivo possibilitar: (1) a seleo dos itens de configurao, que so os elementos passveis de Gerncia de Configurao; (2) a definio do esquema de nomes e nmeros, que possibilite a identificao inequvoca dos itens de configurao no grafo de verses e variantes; e (3) a descrio dos itens de configurao, tanto fsica quanto funcionalmente.

A funo de controle da configurao designada para o acompanhamento da evoluo dos itens de configurao selecionados e descritos pela funo de identificao. Para que os itens de configurao possam evoluir de forma controlada, esta funo estabelece as seguintes atividades: (1) solicitao de modificao, iniciando um ciclo da funo de controle para uma dada manuteno, que pode ser corretiva, evolutiva, adaptativa ou preventiva [PRESSMAN, 2005]; (2) classificao da modificao, que estabelece a prioridade da solicitao em relao s demais solicitaes efetuadas anteriormente; (3) anlise de impacto, que visa relatar os impactos em esforo, cronograma e custo, bem como definir uma proposta de implementao da manuteno; (4) avaliao da modificao pelo Comit de Controle da Configurao (CCC), que estabelece se a modificao ser implementada, rejeitada ou postergada, em funo do laudo fornecido pela anlise de impacto da modificao; (5) implementao da modificao, caso a solicitao tenha sido aprovada pela avaliao da modificao; (6) verificao da modificao com relao proposta de implementao levantada na anlise de impacto; e (7) atualizao da baseline, que pode ou no ser liberada para o cliente em funo da sua importncia e questes de marketing associadas. importante notar que o CCC pode ser composto por uma nica pessoa, desde que tenha as competncias e mecanismos suficientes para a execuo das tarefas associadas. Numa implementao convencional, a ao do CCC realizada antes de a mudana ser efetuada e no apenas para referend-la.

A funo de contabilizao da situao da configurao visa: (1) armazenar as informaes geradas pelas demais funes; e (2) permitir que essas informaes possam ser acessadas em funo de necessidades especficas. Essas necessidades especficas abrangem o uso de medies para a melhoria do processo, a estimativa de custos futuros e a gerao de relatrios gerenciais.

A funo de avaliao e reviso da configurao ocorre quando a baseline, gerada na funo de controle da configurao, selecionada para ser liberada para o cliente. Suas atividades compreendem: (1) auditoria funcional da baseline, via reviso dos planos, dados, metodologia e resultados dos testes, assegurando que ela cumpra corretamente o que foi especificado; e (2) auditoria fsica da baseline, com o objetivo de certificar que ela completa em relao ao que foi acertado em clusulas contratuais.


A funo de gerenciamento de liberao e entrega descreve o processo formal de: (1) construo, produzindo itens de configurao derivados a partir de itens de configurao fonte, (2) liberao, identificando as verses particulares de cada item de configurao que sero disponibilizadas e (3) entrega, implantando o produto no ambiente final de produo. Vale ressaltar que essas auditorias atuam de forma complementar s verificaes executadas na funo de controle da configurao, discutidas anteriormente. As verificaes apresentadas na funo de controle da configurao (tambm conhecidas como revises tcnicas formais) ocorrem ao trmino da implementao de cada modificao individual, com o intuito de assegurar que a modificao cumpre o que foi solicitado e aprovado. Por outro lado, as auditorias da configurao, apresentadas nesta funo, visam verificar se a baseline como um todo, possivelmente englobando diversas modificaes, est correta e completa para ser liberada. A auditoria de Gerncia de Configurao usualmente realizada por um profissional com bom conhecimento tcnico em Gerncia de Configurao. O auditor de gerncia de configurao pode assumir a responsabilidade pela execuo de outras atividades no projeto, por exemplo, implantao do produto. No entanto, no pode participar diretamente do desenvolvimento de produtos de trabalho identificados como itens de configurao ou de outros produtos que compem uma baseline do produto de software.

importante salientar que a auditoria de Gerncia de Configurao no deve ser confundida com a auditoria de Garantia da Qualidade, uma das atividades do processo Garantia da Qualidade (GQA). Em algumas situaes, pode ser til haver uma colaborao entre a equipe de Gerncia de Configurao e de Garantia da Qualidade para fazer, por exemplo, auditorias funcionais conjuntas sobre os outros processos e projetos [IEEE, 1987].

Sob a perspectiva de desenvolvimento, a Gerncia de Configurao dividida em trs sistemas principais: controle de modificaes, controle de verses e gerenciamento de construo.

O sistema de controle de modificaes tem a funo de executar a funo de controle da configurao de forma sistemtica, armazenando todas as informaes geradas durante o andamento das solicitaes de modificao e relatando essas informaes aos envolvidos, assim como estabelecido pela funo de contabilizao da situao da configurao.

O sistema de controle de verses permite que os itens de configurao sejam identificados, segundo estabelecido pela funo de identificao da configurao e que eles evoluam de forma distribuda e concorrente, porm disciplinada. Essa caracterstica necessria para que diversas solicitaes de modificao efetuadas na funo de controle da configurao possam ser tratadas em paralelo, sem corromper o sistema de Gerncia de Configurao como um todo.

O sistema de gerenciamento de construo automatiza o processo de transformao dos diversos produtos de trabalho que compem um projeto no sistema executvel propriamente dito, de forma aderente funo de gerenciamento de liberao e entrega. Alm disso, esse sistema estrutura as baselines selecionadas para liberao, conforme necessrio, para a execuo da funo de avaliao e reviso da configurao.


Apesar de existirem essas diferentes perspectivas para abordar a Gerncia de Configurao, elas no se relacionam de forma complementar, mas sim, de forma sobreposta. As cinco funes descritas na perspectiva gerencial podem ser implementadas pelos trs sistemas descritos na perspectiva de desenvolvimento, acrescidos de procedimentos manuais, quando necessrio. Cada sistema descrito na perspectiva de desenvolvimento pode fazer uso de procedimentos prprios para atender s funes descritas na perspectiva gerencial. Por exemplo: solicitaes de modificao podem seguir fluxos dspares em diferentes projetos, numeraes e rotulao de verses podem ocorrer de diversas formas em funo das necessidades especficas de cada organizao e a liberao de verses de produo pode depender de fatores como decises de marketing e grau de qualidade desejada [LEON, 2000]. Esses procedimentos podem ser definidos no mbito da organizao como um todo ou no mbito de projetos especficos.

Para auxiliar e garantir a execuo das atividades do processo Gerncia de Configurao, uma organizao pode definir uma equipe de Gerncia de Configurao, normalmente nica, abrangendo toda a organizao. Alm dessa equipe, pode ser definido o Comit de Controle da Configurao (CCC), que um grupo de pessoas responsvel por avaliar e aprovar ou rejeitar modificaes propostas em itens de configurao, e certificar que as modificaes aprovadas foram implementadas. Esse grupo pode ser definido por projeto e ter tamanho variado, dependendo de suas necessidades. Possveis membros desse grupo so: lder e alguns membros chave da equipe de Gerncia de Configurao, lder do projeto, representantes da equipe de Garantia da Qualidade, representantes da equipe de marketing e representantes do cliente.

7.3 Resultados esperados

7.3.1 GCO1 - Um Sistema de Gerncia de Configurao estabelecido e mantido

Para que a Gerncia de Configurao ocorra de forma sistemtica, necessrio que seja estabelecido um sistema de Gerncia de Configurao. Esse sistema pode ser decomposto em trs subsistemas: sistema de controle de verses, sistema de controle de modificaes e sistema de gerenciamento de construo.

O sistema de controle de verses responsvel por armazenar as diversas verses dos itens de configurao e assegurar que as modificaes sobre esses itens ocorram de forma segura e controlada. Desta forma, est no mbito desse sistema a definio de polticas de controle de acesso (autenticao, autorizao e auditoria), polticas de controle de concorrncia, por exemplo, pessimista, otimista, hbrida etc., e procedimentos que viabilizem a definio de nveis de controle diferenciados para os itens de configurao, por exemplo, pr e ps baseline.

O sistema de controle de modificaes responsvel por controlar o ciclo de vida das solicitaes de modificao, desde o pedido at a incorporao da modificao na baseline. Esse sistema fundamental para dar visibilidade ao processo Gerncia de Configurao, pois a diferena entre baselines pode ser apresentada em termos das solicitaes de modificaes aprovadas e implementadas. Vale ressaltar que


essa visibilidade s passvel de auditoria caso exista integrao entre o sistema de controle de verses e o sistema de controle de modificaes.

Finalmente, o sistema de gerenciamento de construo responsvel pela transformao dos itens de configurao fontes, por exemplo, cdigo fonte em um paradigma convencional ou modelos no paradigma Model Driven Architecture, em itens de configurao derivados, por exemplo, executvel, que representam o produto propriamente dito. Alm disso, esse sistema pode exercer um papel importante nas atividades subsequentes, de liberao e implantao do produto.

O sistema estabelecido usualmente possui mecanismos para: manter uma estrutura de pastas com controle de acesso e manuseio; armazenar e recuperar itens em suas diversas verses, de forma a preservar e atualizar seu contedo; gerenciar mltiplos nveis de controle de configurao; compartilhar e transferir itens entre os nveis de controle estabelecidos; manter registros sobre a manipulao destes itens; gerar relatrios gerenciais que possibilitem fazer um balano da configurao existente (ou seja, contabilizar a situao da configurao). Alm disso, um aspecto importante a definio de uma estratgia que permita desenvolvimento em paralelo sobre uma base nica de programas fontes, como, por exemplo, o gerenciamento de ramos (branches).

Vale ressaltar que o sistema de Gerncia de Configurao no , necessariamente, estabelecido via ferramentas automatizadas. Contudo, a execuo manual do sistema de Gerncia de Configurao pode se tornar invivel em projetos grandes devido complexidade envolvida. Alm disso, importante notar que a existncia de um sistema de Gerncia de Configurao no dispensa procedimentos de preservao dos dados, ou seja, backup.



(Parte 8)

Qualquer que seja a estratgia de aquisio, a organizao adquirente deve estabelecer e manter o seu sistema de gerncia de configurao. Caso o fornecedor tambm utilize este sistema, o acordo deve definir as responsabilidades, bem como os procedimentos de segurana, controle de acesso e backup [HOFMANN et al., 2007].

Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)



7.3.2 GCO2 - Os itens de configurao so identificados com base em critrios estabelecidos

A identificao dos itens de configurao constitui em um momento crtico para o sucesso do processo Gerncia de Configurao na organizao. A seleo do que ser considerado um item de configurao usualmente baseada em critrios previamente estabelecidos, descritos no plano de Gerncia de Configurao. Por exemplo, um critrio possvel para identificao dos itens de configurao o uso de princpios de acoplamento e coeso. Itens de configurao com alto acoplamento tornam complexo o processo de construo devido ao nmero excessivo de dependncias. Por outro lado, itens de configurao com baixa coeso dificultam o processo de desenvolvimento, devido ao aumento de modificaes concorrentes.

Alm disso, caso os itens de configurao sejam muito pequenos, o nmero total de itens de configurao ser grande e isso poder afetar a visibilidade do produto, dificultar o gerenciamento e aumentar o custo de operao. Por outro lado, caso os itens de configurao sejam muito grandes, o nmero total de itens de configurao ser pequeno e isso poder gerar dificuldades de logstica e manuteno, limitando as possibilidades de gerncia.

Desta forma, uma identificao de itens de configurao bem sucedida est intimamente relacionada com a definio da arquitetura do sistema em questo. Em geral, os itens de configurao so projetados, implementados e testados independentemente, so identificados unicamente pelo seu nome e a sua numerao de verso retrata seu posicionamento na hierarquia e os documentos ou parte de documentos que descrevem o item de configurao fazem parte do item. Para cada item de configurao, identificado no plano de Gerncia de Configurao, so usualmente definidos: um identificador nico; o nvel de controle pretendido, por exemplo, apenas armazenar no repositrio, tambm controlar a verso e ainda incluir em baseline; o momento de se aplicar este controle; um responsvel. Diferentes nveis de controle podem ser apropriados para diferentes produtos de trabalho em diferentes momentos do projeto, bem como um mesmo item de configurao pode possuir diferentes nveis de controle ao longo do projeto.

A gerncia de configurao se aplica tanto para os produtos de trabalho dos projetos quanto para os produtos de trabalho organizacionais, em nvel tcnico, por exemplo, especificao de requisitos, projetos de arquitetura, cdigo; gerencial, por exemplo, planos, laudos, controles; e de processos, por exemplo, padres, procedimentos, guias, templates.



(Parte 8)

A organizao adquirente deve identificar os itens de configurao cuja produo sua responsabilidade e, tambm, os que so responsabilidade do fornecedor e so de seu interesse. Caso delegue esta responsabilidade ao fornecedor, deve avaliar e aprovar as decises feitas pelo fornecedor.


Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)


7.3.3 GCO3 - Os itens de configurao sujeitos a um controle formal so colocados sob baseline

No decorrer da execuo do projeto, os itens de configurao identificados no resultado esperado GCO2 sero produzidos de acordo com os momentos previamente estabelecidos. Durante a produo desses itens de configurao, o sistema de Gerncia de Configurao usualmente atua em um baixo nvel de controle, permitindo maior produtividade. Contudo, quando esses itens de configurao passam a servir como insumo para demais atividades do processo de desenvolvimento, o nvel de controle pode ter que ser aumentado, evitando que modificaes sejam feitas sem a devida aprovao e notificao aos interessados, minimizando o retrabalho.

Para aumentar o nvel de controle sobre os itens de configurao que necessitam de um controle formal, so estabelecidas baselines em diferentes estgios do ciclo de vida do software. O formalismo aplicado s baselines pode variar em funo da flexibilidade que determinados processos de desenvolvimento de software necessitam. A baseline pode ser promovida internamente pelos nveis de anlise (baseline funcional), de projeto (baseline alocada) e implementao (baseline de produto). O mecanismo de rtulo (tag) nas verses de um conjunto de itens de configurao, existente em diversos sistemas de controle de verses, pode ser utilizado para implementar o conceito de baseline.

As atividades relacionadas gerao de uma baseline geralmente incluem: obter autorizao do responsvel (muitas vezes o Comit de Controle de Configurao - CCC) para a criao e liberao da baseline; montar a baseline exclusivamente a partir do sistema de gerenciamento de configurao existente; documentar o conjunto de itens de configurao que esto contidos na baseline e disponibiliz-la para os grupos pertinentes envolvidos.

Alm dos itens de configurao produzidos por projetos, importante que os itens organizacionais (diretrizes, polticas, planos organizacionais etc.) relacionados aos processos do nvel considerado tambm sejam colocados em baselines organizacionais. Isso pode acontecer em qualquer nvel, mesmo quando no h ainda obrigatoriedade da definio de processos. No caso de j haver um processo padro recomendvel que ele esteja sob gerncia de configurao. Sem isso, pode no ser possvel identificar, para cada processo definido de projeto, qual verso especfica do processo padro ele se baseia (algumas organizaes, por exemplo, deixam no processo padro conhecimentos importantes e indicam o processo definido para o projeto apenas com um ponteiro para o processo padro).


Sem gerncia de configurao, se o processo padro mudar, ele automaticamente afeta todos os processos definidos que esto em execuo.



(Parte 8)

A organizao adquirente responsvel pelas baselines dos itens de configurao que produz. Para os itens de configurao de responsabilidade do fornecedor, caso a responsabilidade de criar as baselines seja do prprio fornecedor, o adquirente responsvel por avaliar e aprovar a release das baselines [HOFMANN et al., 2007].

Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)


7.3.4 GCO4 - A situao dos itens de configurao e das baselines registrada ao longo do tempo e disponibilizada

As aes de gerenciamento de configurao como a incluso e alterao de itens no repositrio, a gerao e liberao de baselines precisam ser registradas e disponibilizadas em um nvel de detalhe suficiente para que o contedo e a situao de cada item de configurao sejam conhecidos e que verses anteriores possam ser recuperadas. Com isso so estabelecidos registros do contedo, situao e verso dos itens de configurao e baseline, tanto no contexto de projetos como no contexto organizacional, quando pertinente. Isto importante para assegurar que os grupos interessados em itens especficos tenham acesso e conhecimento sobre o histrico e a situao especfica de cada item ao longo do tempo, bem como para que consigam identificar, diferenciar e recuperar o contedo das baselines geradas.

importante que exista um mapeamento preciso entre as baselines e todas as verses dos itens de configurao que as compem, assim como o mapeamento preciso entre as solicitaes de modificao e todas as verses dos itens de configurao geradas durante sua implementao. Esses mapeamentos facilitam a identificao em diferentes nveis de abstrao do impacto das modificaes no sistema como um todo. Assim, o sistema de Gerncia de Configurao capaz de registrar todas as informaes referentes ao ciclo de vida dos itens de configurao, possibilita gerar relatrios tanto no nvel de desenvolvimento quanto no nvel gerencial.

No nvel de desenvolvimento, possvel identificar as diferenas entre duas verses de um mesmo item de configurao. Alm disso, possvel diferenciar o estado de um item de configurao, por exemplo, em desenvolvimento, em testes, aprovado, em baseline, liberado etc. O mecanismo de ramo (branch), existente em diversos


sistemas de controle de verses, pode ser utilizado para implementar a separao de estados dos itens de configurao.

No nvel gerencial, possvel visualizar precisamente o andamento das modificaes realizadas, assim como as diferenas entre baselines em termos das solicitaes de modificao implementadas.

Uma discusso mais profunda sobre a disponibilizao de baselines em forma de liberaes (releases) apresentada em GCO6 (seo 7.3.6).



(Parte 8)

A organizao adquirente deve registrar e disponibilizar a situao dos itens de configurao e das baselines sob sua responsabilidade. Alm

disso, deve garantir que o acordo especifique como o fornecedor deve registrar e disponibilizar a situao dos itens de configurao que esto sob sua responsabilidade. Ao longo do projeto, responsabilidade do adquirente avaliar e aprovar como o fornecedor executou esta atividade.

Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)


7.3.5 GCO5 - Modificaes em itens de configurao so controladas

A partir do momento que os itens de configurao passam a fazer parte de uma baseline, toda e qualquer modificao sobre esses itens de configurao deve passar por um processo formal de controle de modificaes. Esse processo formal de controle de modificaes visa analisar o impacto das modificaes e notificar aos afetados, evitando retrabalho e efeitos colaterais indesejveis. O ciclo de vida das solicitaes de modificao, assim como os critrios estabelecidos para sua aprovao pelo Comit de Controle da Configurao (CCC), so previamente estabelecidos no plano de Gerncia de Configurao.

Dependendo da etapa do processo de desenvolvimento, determinados itens de configurao tero maior importncia e constituiro diferentes baselines. Por exemplo, no momento da codificao, os itens de configurao de projeto que constituem a baseline alocada so os de maior importncia e recebem maior ateno por parte da Gerncia de Configurao. Isso ocorre porque o cdigo fonte que est sendo criado em funo do projeto pode ficar inconsistente caso alguma modificao no relatada ocorra nesses itens de configurao de projeto.

Para que uma solicitao de modificao possa ser implementada, ao menos os seguintes passos so usualmente registrados [IEEE, 2005]: (1) Documentao da


necessidade de modificao; (2) Anlise de impacto da modificao; e (3) Avaliao da modificao (aprovao ou reprovao). Aps a implementao de uma modificao, ao menos os seguintes passos so usualmente registrados: (1) Verificao da implementao; e (2) Atualizao da baseline com a modificao. Caso seja decidido pelo CCC, tambm pode ser feita a liberao da baseline. Nos momentos pertinentes desse processo, os interessados e autorizados so comunicados sobre o andamento da solicitao. Esta comunicao pode ser feita de forma direta, por exemplo, por meio do envio de e-mail, ou indireta, por exemplo, disponibilizando de um rtulo (tag) no sistema de controle de verso.

A anlise de impacto descreve quais itens de configurao sero afetados pela modificao e quais so as correes propostas. Tambm indica uma estimativa do esforo necessrio para realizar a modificao em termos de custo, tempo ou outra medida adequada. Para auxiliar na realizao dessa anlise, aconselha-se o uso de algum mecanismo que indique a rastreabilidade entre os itens de configurao, como, por exemplo, uma matriz de rastreabilidade.

O controle das modificaes realizadas nos itens geralmente inclui: atribuir solicitaes aos responsveis pela mudana; retirar (check-out) e registrar (check-in) itens no sistema de Gerenciamento de Configurao, documentando as mudanas realizadas e seu motivo, de forma a preservar sua correo e integridade; realizar revises para assegurar que as mudanas no causaram efeitos colaterais; obter autorizao antes de incorporar itens a uma nova verso; acompanhar as solicitaes de mudana at a concluso; definir junto aos responsveis e registrar as solicitaes de mudana que sero atendidas e disponibilizadas nas baselines; e disponibilizar mudanas aos interessados e autorizados.

O sistema de Gerncia de Configurao usualmente registra e mantm um controle do andamento de todas as solicitaes de modificao, possibilitando gerar relatrios tanto no nvel de desenvolvimento quanto no nvel gerencial.



(Parte 8)

Solicitaes de mudana podem ter origem tanto na organizao adquirente, quanto no fornecedor. Entretanto, a responsabilidade por aprovar e controlar as mudanas nos itens de configurao da organizao adquirente. , tambm, responsabilidade do adquirente analisar o impacto das mudanas no acordo com o fornecedor [HOFMANN et al., 2007].

Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)



7.3.6 GCO6 - O armazenamento, o manuseio e a liberao de itens de configurao e baselines so controlados

Todos os produtos de trabalho que forem itens de configurao, tanto de projetos quanto de processos, so armazenados no sistema de Gerncia de Configurao, seguindo as especificaes definidas para cada tipo de item de configurao. Alm disso, o acesso a esses produtos de trabalho controlado, tanto sob o ponto de vista de concorrncia quanto sob o ponto de vista de autorizao, evitando que acontea retrabalho ou que informaes sensveis sejam acessadas por pessoas no autorizadas. Assim, controles so estabelecidos para registrar (por exemplo, fazer check-in) e retirar (por exemplo, fazer check-out) itens do sistema de Gerncia de Configurao, bem como para gerenciar a concorrncia no uso/manuseio (por exemplo, estabelecer ramos (branches)).

Em situaes onde existem informaes sensveis armazenadas no sistema de Gerncia de Configurao e em que esse sistema acessado por meios inseguros, por exemplo, Internet, necessrio que canais de segurana sejam estabelecidos, por exemplo, SSL (Secure Sockets Layer), evitando que pessoas externas ao processo tenham acesso a essas informaes. Vale ressaltar que o mero estabelecimento de mecanismos de autorizao no suficiente para fornecer nveis adequados de segurana nesses cenrios.

necessrio, ainda, estabelecer um controle para a liberao de baseline aos interessados e autorizados contendo tanto verses para a produo quanto produtos de trabalho fechados, incluindo o empacotamento e a entrega.

A liberao de baselines contendo verses para a produo ocorre o quanto antes, de forma a minimizar o retrabalho necessrio para adaptar as modificaes ao restante do software. Idealmente, essas liberaes ocorrem de forma incremental e contnua, visando aumentar a transparncia do processo Gerncia de Configurao como um todo. Por exemplo, aps uma solicitao de modificao, o solicitante passa a ser um interessado direto na liberao futura do software. Contudo, cada estado intermedirio dessa solicitao tambm de interesse do solicitante e pode afetar suas possveis tomadas de deciso. Por outro lado, uma solicitao de modificao pode adiar a previso da prxima liberao do software, gerando efeitos colaterais na equipe responsvel pela divulgao do produto.

A liberao de uma baseline para o cliente s ocorre aps autorizao do CCC e execuo dos procedimentos de auditoria. Alm disso, importante o estabelecimento de rastreabilidade entre a baseline que originou a liberao, a liberao propriamente dita e o cliente que recebeu a liberao. S assim ser possvel identificar, inequivocamente, a verso dos itens de configurao que foram utilizados para construir uma determinada verso do software que est em produo no ambiente do cliente.




(Parte 8)

No que se refere ao controle do armazenamento, o manuseio e a liberao de itens de configurao e baselines, a responsabilidade

pode ser parte do adquirente e parte do fornecedor. Entretanto responsabilidade do adquirente avaliar e controlar como o fornecedor executa estas atividades.

Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)


7.3.7 GCO7 - Auditorias de configurao so realizadas objetivamente para assegurar que as baselines e os itens de configurao estejam ntegros, completos e consistentes

Auditorias sobre o sistema de Gerncia de Configurao so realizadas objetivamente, com o objetivo de verificar se os procedimentos e diretrizes esto sendo seguidos de forma correta e adequada, bem como se os itens de configurao e as baselines esto ntegras, corretas e consistentes. A periodicidade das auditorias previamente estabelecida no plano de Gerncia de Configurao, por exemplo, auditorias pr-liberao, auditorias mensais etc.

So realizadas auditorias tanto no contexto de projetos quanto no contexto organizacional. Ambas confirmam se os registros de gerncia de configurao identificam corretamente os itens de configurao e as baselines.

A objetividade da auditoria de configurao obtida pela execuo da auditoria por um auditor que no esteve envolvido diretamente na execuo das atividades do processo sendo auditadas com base em critrios que minimizem a subjetividade e o vis. O auditor de gerncia de configurao pode assumir a responsabilidade pela execuo de outras atividades no projeto, por exemplo, implantao do produto. No entanto, o auditor de gerncia de configurao no pode participar diretamente do desenvolvimento de produtos de trabalho identificados como itens de configurao ou de outros produtos que compem uma baseline do produto de software. importante notar que normalmente se audita tambm o prprio sistema de gerncia de configurao. Ou seja, se o gerente de configurao fosse desenvolvedor do projeto, ele auditaria as prprias aes de gerncia de configurao que ele deveria estar fazendo no dia a dia de trabalho.

Em relao aos itens de configurao, necessrio verificar sua estrutura e integridade, bem como confirmar se esto completos, corretos e conformes com padres e procedimentos de gerncia de configurao aplicveis.


Usualmente, dois tipos de auditorias so executados sobre as baselines: auditoria funcional e auditoria fsica. A auditoria funcional ocorre por meio da reviso dos planos, dados, metodologia e resultado de testes, para verificar se estes so satisfatrios. Desta forma, o seu objetivo verificar a corretude da baseline, ou seja, se ela cumpre o que foi especificado. Por outro lado, a auditoria fsica examina a estrutura de todos os itens de configurao que compem a baseline. Desta forma, o seu foco principal est na completude da baseline, ou seja, se ela contm todos os itens de configurao especificados. De qualquer forma, todos os problemas detectados em uma auditoria de configurao so tratados como itens de ao da auditoria e acompanhados at a concluso.

As verificaes previstas nestes dois tipos de auditorias, no entanto, no precisam ser executadas necessariamente por uma nica pessoa ou ser de atribuio de um nico papel no processo. Tarefas usualmente executadas em uma auditoria funcional, por exemplo, a verificao se todos os requisitos foram implementados ou se os resultados de testes foram satisfatrios para assegurar a qualidade do produto podem ser asseguradas por reviso por pares ou pelo Grupo de Qualidade. Dessa forma, por exemplo, uma possvel parceria entre as equipes de gerncia de configurao e garantia da qualidade para realizao de auditorias pode diminuir a presso em empresas pequenas.



(Parte 8)

A organizao adquirente responsvel por realizar a gerncia de configurao e, consequentemente, as auditorias de configurao relacionadas s atividades que executa.

Nas situaes onde for estabelecido no acordo que a responsabilidade por realizar as auditorias do fornecedor, a organizao adquirente deve verificar se estas foram realizadas de forma adequada.

Fbrica de Software

(Parte 9)


Fbrica de Teste

(Parte 10)



8 Gerncia de Portflio de Projetos (GPP)

8.1 Propsito

O propsito do processo Gerncia de Portflio de Projetos iniciar e manter projetos que sejam necessrios, suficientes e sustentveis, de forma a atender os objetivos estratgicos da organizao. Este processo compromete o investimento e os recursos organizacionais adequados e estabelece a autoridade necessria para executar os projetos selecionados. Ele executa a qualificao contnua de projetos para confirmar que eles justificam a continuidade dos investimentos, ou podem ser redirecionados para justificar.

Enquanto o processo Gerncia de Projetos (GPR) envolve as atividades de gerenciamento de um projeto, o processo Gerncia de Portflio de Projetos (GPP) envolve atividades relacionadas ao gerenciamento do conjunto de projetos de uma organizao, ou seja, atividades relacionadas com o gerenciamento da carteira de projetos. Isto engloba as atividades de seleo dos projetos que comporo a carteira, bem como anlise, ao longo de sua execuo, para determinar se continuam viveis e adequados em relao aos motivos pelos quais foram aprovados.

O processo Gerncia de Portflio de Projetos obrigatrio, exceto quando a nica atividade da unidade organizacional for evoluo de produto. Neste nico caso, poder ser considerado fora do escopo da avaliao.



(Parte 8)

Como no existem especificidades para organizaes adquirentes, no foram includos comentrios aos resultados esperados.

Caso o processo Gerncia de Portflio de Projetos esteja no escopo da avaliao, no so permitidas excluses de resultados deste processo.

Fbrica de Software

(Parte 9)



Fbrica de Teste

(Parte 10)

Como no existem especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.




O PMI (Project Management Institute), reconhecida associao profissional na rea de gerenciamento de projetos, conhecido mundialmente pela publicao, atualizao e disseminao do PMBOK [PMI, 2008a]. O PMBOK um guia que contm as melhores prticas de gerenciamento de projetos e descreve os processos necessrios para iniciar, planejar, executar, controlar e encerrar um projeto. O seu foco o gerenciamento de um projeto individualmente.

Paralelamente a esta iniciativa, o PMI tambm o responsvel pela publicao, atualizao e disseminao do Padro para o Gerenciamento de Portflio (Standard for Portfolio Management) [PMI, 2008b]. O foco deste guia, como o prprio nome sugere, est nas atividades envolvidas no gerenciamento da carteira de projetos da organizao, e no apenas sobre um projeto individualmente.

Pode-se entender um portflio como sendo (...) um conjunto de projetos, programas e outros trabalhos que so agrupados para facilitar o gerenciamento efetivo da

mps.br guia de implementação nível f

Documents