Mestrado Karine So CmFinal 20070815

Ps-graduao em Cincia da Computao
Um processo de Gerncia de Configurao baseado no nvel 2 do CMMI estagiado para Fbricas de Software Orientadas a Produto
Por
Karine Coelho de Amorim Oliveira

Dissertao de mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br
http://www.cin.ufpe.br/~posgraduacao
Agosto/2007
Karine Coelho de Amorim Oliveira
Um processo de Gerncia de Configurao baseado no nvel 2 do CMMI estagiado para Fbricas de Software Orientadas a Produto
Dissertao apresentada coordenao da psgraduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para a obteno do ttulo de Mestre em Cincia da Computao.
Orientador:
Alexandre Marcos Lins Vasconcelos
Agradecimentos
Primeiramente, gostaria de agradecer a Deus por ter me dado sade, sabedoria e perseverana para concluir o mestrado, por me iluminar em todos os momentos deste trabalho, por me dar foras para no desistir de um sonho antigo. Agradeo a meus pais, Joo Bosco e Joselita, por tudo o que sou, por sempre me incentivarem, mesmo distncia, a traar e concluir meus objetivos, e por sempre se orgulharem de minhas conquistas, sejam elas pessoais ou profissionais. Agradeo ao meu marido George (meu preto), por todo o amor, apoio e compreenso durante essa jornada longa de trabalho, onde muitas vezes o privei de minha companhia para poder trabalhar no mestrado. Agradeo aos meus irmos Dora, Quel e Lo, por serem meus companheiros para toda a vida e por estarem sempre unidos a mim nesta batalha, minha cunhada Luciana e aos meus cunhados Lo e Geovani, pelas palavras amigas de apoio e torcida, aos meus sobrinhos Isabela, Manuella, Leonardo e Joo Pedro, por trazerem a alegria tia Kaki, estando perto ou longe. Agradeo ao meu orientador Alexandre, por ter me aceito como sua aluna, e por toda dedicao, pacincia e perseverana no meu trabalho, por no ter desistido de mim. Agradeo CSI, por ter me proporcionado a dedicao e alocao necessrias para a construo deste trabalho. Em especial, aos meus amigos do ncleo TEF, por terem compartilhado comigo durante esses anos a preocupao com a melhoria de processos dentro da fbrica. Agradeo a Tibrio e Carlos Augusto, por terem me colocado na rea de qualidade da CSI, por terem me ensinado muito do que sou hoje como profissional, por serem meus padrinhos em diversos momentos de minha vida. Agradeo a Cibele e Renata, pelo apoio e orientao nas consultorias do CMMI, por sempre me incentivarem a buscar a melhoria da qualidade dos processos na CSI. Agradeo aos meus poucos (mas grandes) amigos, minhas joinhas, por simplesmente serem meus amigos. A todas estas pessoas, muito obrigada por sempre me fazerem acreditar que sou capaz.
Resumo
A busca pela melhoria da qualidade de produtos e servios oferecidos pelas empresas de software vem aumentando continuamente nos ltimos anos. O mercado de produtos e servios de software tem se tornado cada vez mais ativo e exigente. Assim, para se adquirir um produto ou servio, so levadas em considerao as variveis prazo, custo, caractersticas e qualidade, entre outras. Para atender presso exercida pelo mercado, as empresas de software tm investido na profissionalizao de suas operaes, como, por exemplo, na reestruturao da organizao em fbricas de software - orientadas a produto e a projetos, e na melhoria dos processos de desenvolvimento de software, usando modelos conceituados, como o CMMI Capability Maturity Model Integration. Neste contexto, a gerncia de configurao uma atividade de extrema importncia para o desenvolvimento de projetos e produtos em uma organizao. A cada dia surgem novas ferramentas, novos padres e procedimentos para apoiar o desenvolvimento e garantir o controle de verses e a gesto de mudanas dentro da organizao. Quando inclumos as novas estruturas organizacionais, como as fbricas de software orientadas a produto, este cenrio se torna ainda mais complexo, pois lana o desafio de conciliar as necessidades dos projetos da fbrica com a gesto do produto em si, conflito que afeta por completo a gerncia de configurao. Este trabalho apresenta a proposta de um processo de gerncia de configurao alinhado ao nvel 2 de maturidade e capacidade do CMMI, destinado a fbricas de software orientadas a produto. Atravs de um estudo de caso aplicado em uma fbrica de software orientada a produto, foi possvel evidenciar os principais benefcios trazidos pelo processo organizao: maior controle sobre os itens de configurao, atravs da documentao dos mesmos em um plano de gerncia de configurao e monitoramento realizado pelo gerente de configurao; padronizao do controle de mudanas, atravs da utilizao de ferramentas automatizadas para apoiar o processo; acesso facilitado s verses do produto ao longo do tempo, obtido atravs do estabelecimento de baselines e liberao de verses e patches pelo gerente de configurao, conforme definido no processo. Palavras-chave: Qualidade de Software, Fbricas de Software Orientadas a Produto; Gerncia de Configurao.
ii
Abstract
The search for services and products quality improvement has increased in the last few years. The market of services and products has become more demanding and active. So, when choosing a product or service, it is necessary to analyze some aspects such as time, cost, features and quality, like others. To take care of the pressure exerted by the market, the software companies have invested in the professionalization of its operations, using product and project-oriented software factory concepts, and software development and process improvement, using quality models like CMMI Capability maturity Model. In this context, configuration management is a very important activity in project and product development in a company. Every day, new tools, patterns and procedures are published to support development activities and guarantee version control and change requests. Analyzing new organizational structures, such as product and project-oriented software factories, this scenario becomes more complex, because it tries to overcome conflicts between factory projects and product management. This research work presents a configuration management process proposal, which is compliant with maturity and capability level 2 of CMMI Configuration Management process area, applied to product-oriented software factories. The case study showed many benefits of this proposal, such as higher configuration items control, through the use of a product configuration management plan, change control standardization, through the use of automated tools for process support; better access to product releases, through baselines establishment and version/patches releases by configuration manager. Keywords: Management. Software Quality; Product-Oriented Software Factory; Configuration
iii
ndice
1. INTRODUO ............................................................................................................................. 1
1.1. GERNCIA DE CONFIGURAO DE SOFTWARE .................................................................................... 3 1.2. PROPOSTA DE TRABALHO ..................................................................................................................... 6 1.3. ESTRUTURA DO TRABALHO .................................................................................................................. 7
2. FBRICAS DE SOFTWARE ...................................................................................................... 9

2.1. CONTEXTO DAS FBRICAS DE SOFTWARE DENTRO DA ORGANIZAO ............................................. 14 2.2. ESTRUTURAO ORGANIZACIONAL DAS FBRICAS: PRODUTOS VERSUS PROJETOS ........................ 16 2.3. CICLO DE DESENVOLVIMENTO EM FBRICAS DE SOFTWARE ............................................................ 19 2.4. LINHAS DE PRODUTO DE SOFTWARE................................................................................................... 19 2.5. CONSIDERAES FINAIS ..................................................................................................................... 20
3. VISO GERAL DO CMMI ....................................................................................................... 21

3.1. REPRESENTAES DO CMMI ............................................................................................................ 22 3.2. NVEIS DE MATURIDADE E CAPACIDADE DO CMMI ......................................................................... 24 3.3. EVOLUO DO CMMI NO MUNDO ..................................................................................................... 26 3.4. EVOLUO DO CMMI NO BRASIL ..................................................................................................... 29 3.5. AVALIAES DO CMMI ..................................................................................................................... 31 3.6. RELACIONAMENTO ENTRE O NVEL 2 DE MATURIDADE E CAPACIDADE DO CMMI ......................... 34 3.7. CONSIDERAES FINAIS ..................................................................................................................... 36
4. ANLISE CRTICA DA GERNCIA DE CONFIGURAO DO NVEL 2 DO CMMI . 37

4.1. PRTICAS ESPECFICAS ....................................................................................................................... 39 4.2. PRTICAS GENRICAS ......................................................................................................................... 43 4.3. CONSIDERAES FINAIS ..................................................................................................................... 47
5. PROPOSTA DO PROCESSO DE GERNCIA DE CONFIGURAO.............................. 48

5.1. APRESENTAO DO CONTEXTO .......................................................................................................... 49 5.2. ESTRUTURA DO PROCESSO .................................................................................................................. 49 5.3. DESCRIO DO PROCESSO .................................................................................................................. 50 5.4. INSTITUCIONALIZAO DO PROCESSO ............................................................................................... 74 5.5. CONSIDERAES FINAIS ..................................................................................................................... 78
6. ANLISE CRTICA DO PROCESSO PROPOSTO .............................................................. 80
iv
6.1. MAPEAMENTO DO PROCESSO DE GERNCIA DE CONFIGURAO X CMMI ..................................... 81 6.2. CONSIDERAES FINAIS ..................................................................................................................... 95
7. ESTUDO DE CASO .................................................................................................................... 96

7.1. ESCOPO DE REALIZAO DO ESTUDO DE CASO .................................................................................. 97 7.2. METODOLOGIA DE TRABALHO ........................................................................................................... 99 7.3. RELATO DO ESTUDO DE CASO .......................................................................................................... 100 7.4. CONSIDERAES FINAIS ................................................................................................................... 114
8. CONCLUSES ......................................................................................................................... 116

8.1. PRINCIPAIS CONTRIBUIES............................................................................................................. 117 8.2. DIFICULDADES ENCONTRADAS ......................................................................................................... 118 8.3. TRABALHOS RELACIONADOS ............................................................................................................ 119 8.4. TRABALHOS FUTUROS ....................................................................................................................... 120 8.5. CONSIDERAES FINAIS ................................................................................................................... 120
REFERNCIAS ............................................................................................................................ 122
ANEXOS ........................................................................................................................................ 126

ANEXO A - CHECKLIST DE AUDITORIA DE ESTABELECIMENTO DE BASELINE ..................................... 127 ANEXO B - CHECKLIST DE AUDITORIA DE LIBERAO DE VERSO OU PATCH ................................... 128 ANEXO C MODELO DE RELEASE NOTES DE VERSO ......................................................................... 129 ANEXO D MODELO DE RELEASE NOTES DE PATCH............................................................................ 130 ANEXO E - CHECKLIST DE AUDITORIA PERIDICA DE GERNCIA DE CONFIGURAO...................... 131 ANEXO F DEFINIO OPERACIONAL DAS MTRICAS DO PROCESSO PROPOSTO ............................ 132
Lista de Figuras
Figura 1-1 Histrico de resoluo de projetos de empresas americanas ................................ 2 Figura 1-2 Presses exercidas para a melhoria de gerncia de configurao .......................... 5 Figura 2-1 Contexto de fbrica de software como rea de uma organizao ........................ 14 Figura 2-2 Contexto de fbrica de software como a organizao ......................................... 15 Figura 2-3 Representao de desenvolvimento orientado a produto ..................................... 16 Figura 2-4 Representao de desenvolvimento orientado a projeto ...................................... 17 Figura 3-1 Estrutura do modelo CMMI para a representao contnua ................................ 24 Figura 3-2 Estrutura do modelo CMMI para a representao por estgios ........................... 24 Figura 3-3 Distribuio das avaliaes entre organizaes americanas e no americanas ... 27 Figura 3-4 - Perfil de Maturidade em organizaes americanas e no-americanas ................. 27 Figura 3-5 Perfil de Maturidade de Processos segundo o CMMI ......................................... 28 Figura 3-6 Organizaes brasileiras com qualificao CMMI entre 1997 e 2006)............... 30 Figura 3-7 Equivalncia entre os nveis de capacidade e maturidade do CMMI .................. 35 Figura 5-1 Viso grfica do processo proposto de gerncia de configurao ....................... 50 Figura 5-2 Viso grfica do subprocesso 1: Planejar Gerncia de Configurao ................. 54 Figura 5-3 Viso grfica do subprocesso 2: Estabelecer Baseline ........................................ 61 Figura 5-4 Viso grfica do subprocesso 3: Liberar Verses ou Patches ............................. 65 Figura 5-5 Viso grfica do subprocesso 4: Controlar Mudanas ........................................ 68 Figura 5-6 Viso grfica do subprocesso 5: Acompanhar Gerncia de Configurao .......... 72 Figura 7-1 Viso geral da fbrica de software do estudo de caso ......................................... 98 Figura 7-2 Apresentao da mtrica Releases planejados x liberados............................. 109 Figura 7-3 Apresentao da mtrica Esforo planejado x realizado de CM.................... 110 Figura 7-4 Apresentao da mtrica Backlog de CM/ms .............................................. 111 Figura 7-5 Resultado da 1 auditoria externa do processo de Gerncia de Configurao ... 113 Figura 7-6 Resultado da 2 auditoria externa do Processo de Gerncia de Configurao... 114
vi
Lista de Tabelas
Tabela 3-1 Nveis de capacidade do CMMI .......................................................................... 25 Tabela 3-2 Nveis de maturidade do CMMI.......................................................................... 26 Tabela 3-3 Resultado de desempenho de organizaes avaliadas no CMMI........................ 29 Tabela 3-4 Caractersticas das classes de avaliao CMMI .................................................. 31 Tabela 3-5 Caracterizao da implementao das prticas ................................................... 34 Tabela 5-1 Representao grfica do processo...................................................................... 50 Tabela 5-2 Papis e responsabilidades do processo proposto ............................................... 52 Tabela 5-3 Resumo do subprocesso 1: Planejar Gerncia de Configurao ......................... 53 Tabela 5-4 Sugestes de critrios de seleo de itens de configurao................................. 55 Tabela 5-5 Exemplo de critrios para entrada de um item de configurao na baseline ...... 57 Tabela 5-6 Exemplos de Tipos de Baselines ......................................................................... 58 Tabela 5-7 Resumo do subprocesso 2: Estabelecer Baselines .............................................. 61 Tabela 5-8 Solicitantes de estabelecimento de baseline x tipo de baseline .......................... 62 Tabela 5-9 Resumo do subprocesso 3: Liberar verses ou patches ...................................... 64 Tabela 5-10 Resumo do subprocesso 4: Controlar Mudanas .............................................. 67 Tabela 5-11 Sugesto de Informaes de uma solicitao de mudana ................................ 69 Tabela 5-12 Resumo do subprocesso 5: Acompanhar Gerncia de Configurao................ 72 Tabela 5-13 Sugestes de itens da poltica organizacional para a gerncia de configurao 74 Tabela 5-14 Lista de treinamentos para o processo proposto................................................ 76 Tabela 5-15 Nvel de controle dos artefatos do processo ...................................................... 77 Tabela 7-1 comparao entre os produtos do estudo de caso ................................................ 99 Tabela 7-2 Resumo das baselines definidas para o produto 1 ............................................. 104
vii
Captulo 1- Introduo
Captulo 1. Introduo
Este captulo apresenta as motivaes para esta dissertao, atravs da contextualizao do cenrio atual do mercado sob a tica da qualidade de software, evidenciando a importncia da gerncia de configurao no processo de desenvolvimento de software, identificando a necessidade de utilizao de processos como uma das sadas para melhorar a qualidade dos softwares produzidos, com o direcionamento para a rea de gerncia de configurao. Por fim, apresentada a estrutura desta dissertao.
Captulo 1- Introduo
A busca pela melhoria da qualidade de produtos e servios fornecidos pelas empresas de software vem aumentando continuamente nos ltimos anos. O mercado dos produtos e servios de software, antes passivo s tecnologias e aos processos das empresas de software, tem-se tornado cada vez mais ativo e exigente: para adquirir um produto ou servio, so levadas em considerao, entre outras, as variveis prazo, custo, caractersticas e qualidade do produto ou servio, as quais podem ser consideradas como as quatro dimenses mais significativas do gerenciamento de projetos [Junk-00]. Analisando estas quatro dimenses, no podemos deixar de mencionar o artigo Extreme Chaos [Standish-01], do Standish Group [Standish-07], onde feito um resumo do histrico da evoluo dos projetos desde o artigo Chaos Report [Standish-95] at o ano de 2000, como apresenta a Figura 1-1.
Histrico de Resoluo de Projetos (1994 - 2000)
28% 2000 26% 1998 27% 1996 16% 1994 31% 53% 40% 33% 28% 46% 23% 49%
Bem-sucedidos Desafiadores Falhos
0%
20%
40%
60%
80%
100%
Figura 1-1 Histrico de resoluo de projetos de empresas americanas 1
Apesar de notarmos uma melhoria no percentual de projetos bem-sucedidos (aqueles que foram concludos no prazo, custo, caractersticas e qualidade esperados), este grupo ainda uma minoria diante dos projetos desafiadores (que violaram prazo e custo, com caractersticas e qualidade aqum do esperado) e os falhos (que foram cancelados ou nem comearam a ser implementados). Alm dos fatores mencionados no artigo como os 10 ingredientes de um projeto bem-sucedido, no podemos deixar de considerar que as caractersticas dos clientes vm mudando ao longo do tempo. O mercado tem demandado a
Fonte: Standish Group international. Extreme Chaos. [Standish-01]
Captulo 1- Introduo
melhoria dos projetos para as empresas, e a organizao interna do desenvolvimento dos projetos teve que ser revisada para identificar o que pode ser modificado para reverter o quadro apresentado na figura 1-1. Para atender presso exercida pelo mercado, as empresas de desenvolvimento de software tm investido na profissionalizao de suas operaes atravs de vrias iniciativas, como a reestruturao da organizao e a melhoria dos processos de desenvolvimento de software. Na rea organizacional, os modelos de fbrica de software tm sido vistos como um meio de aperfeioar a produo de software, atravs da especializao das equipes e da padronizao da forma de trabalho [Aaen-97]. Na rea de processos, as empresas tm seguido diversos modelos de processo para melhorar a qualidade do seu desenvolvimento, integrando a rea de desenvolvimento de software com outras reas do negcio, como aquisio de servios, manuteno de software e integrao entre produtos. Esta proposta tem sido a base para a evoluo de diversos modelos de processo, como o CMMI Capability Maturity Model Integration [Chrissis-03]. Esses dois grupos de iniciativas envolvem mudanas em todas as reas relacionadas ao desenvolvimento de software, como as reas de gesto de projetos e requisitos, engenharia e de suporte, como a gerncia de configurao. necessrio analisar cuidadosamente cada uma delas para que as mudanas reflitam em uma melhoria de qualidade do produto e servio prestado pela organizao.
1.1. Gerncia de Configurao de Software
A gerncia de configurao de software pode ser entendida como uma disciplina que permite manter a evoluo de produtos de software sobre controle e, dessa forma, contribuir para satisfazer as restries de qualidade e prazo [Estublier-00]. Esta disciplina passou a ser considerada como tal a partir da chamada crise de software, quando se constatou que o processo de desenvolvimento de software estava incompleto, e que seria necessrio analisar outros aspectos para melhorar a qualidade dos softwares produzidos. Ao longo dos anos a gerncia de configurao tem evoludo, e atualmente pode ser vista com trs grandes objetivos: Gerenciar componentes em repositrio, que envolvem o gerenciamento de verses, a modelagem de produtos e o gerenciamento de objetos complexos.
Captulo 1- Introduo
Ajudar os engenheiros em suas atividades rotineiras, orientando-os quanto ao acesso correto no repositrio, procedimentos de atualizao de itens de configurao e controle de seus espaos de trabalho (workspaces).
Fornecer suporte e controle ao processo de desenvolvimento, atravs do controle de mudanas no software ao longo do tempo.
Segundo [Kasse-00] atividades de suporte, como gerncia de configurao e garantia da qualidade, nem sempre so vistas como valor agregado pelos gerentes de projeto e desenvolvedores de software. Muitas vezes, so vistas como overhead de trabalho para se atingir o objetivo do projeto, entregar o software desenvolvido. Segundo [Guess-98], a gerncia de configurao vista, como uma fora invisvel: quando funciona, ningum sabe que ela est presente. Porm, quando no funciona, as conseqncias podem ser desastrosas. Esta afirmao bastante interessante, visto que a gerncia de configurao vista com uma rea de suporte ao desenvolvimento, mas no percebida por todos. Em uma empresa de desenvolvimento de software, a verso correta de um produto liberada para o mercado fruto de uma gerncia de configurao eficiente. Se esta verso apresenta problemas de configurao (componentes em verses erradas, componentes ausentes, por exemplo), ocorreu uma falha grave de gerncia de configurao. Uma pesquisa recente do Aberdeen Group [Aberdeen-07] realizada com 200 empresas do setor industrial (aeroespacial, manufatura e alta tecnologia), mostrou que a melhoria de qualidade, o time to market (tempo de lanamento de um produto no mercado) e a reduo dos custos de desenvolvimento do produto so as principais razes para o crescente investimento das empresas em gerncia de configurao, como mostra a Figura 1-2. Os custos associados ao produto so sensivelmente afetados por problemas de configurao do produto, e podem comprometer a margem de lucro da empresa.
Captulo 1- Introduo
Reduzir custos de produo
27%
reduzir custos do ciclo de vida do produto
28%
Reduzir custos de desenvolvimento do produto
29%
Melhorar o time to market
33%
Melhorar a qualidade do produto 0% 5% 10% 15% 20% 25% 30% 35% 40%
41% 45%
Todos os que responderam pesquisa
Figura 1-2 Presses exercidas para a melhoria de gerncia de configurao2
Para as empresas de software, este cenrio bastante familiar. Acompanhando o pensamento de [Guess-98], [Kasse-00] e [Aberdeen-07], podemos citar alguns aspectos envolvidos em uma gerncia de configurao pobre: A ltima verso do cdigo-fonte no est sendo encontrada Um defeito que foi corrigido anteriormente (com um alto custo) voltou a ocorrer de repente. Uma funcionalidade implementada e testada desapareceu. Os testes foram realizados na verso errada do cdigo-fonte. Os programadores esto trabalhando com a verso errada do cdigo-fonte. A baseline estabelecida contm as verses erradas dos itens de configurao.
Alm dos problemas citados, um problema de gerncia de configurao no software normalmente percebido externamente (pelos clientes finais da empresa), afetando a relao cliente-fornecedor, visto que o cliente questiona claramente o processo de desenvolvimento da empresa, onde a ausncia de qualidade fica evidenciada pelos problemas de configurao
Fonte: Aberdeen Group. The Configuration Management Benchmark Report [Aberdeen-07]
Captulo 1- Introduo
do software. Alm disso, o retrabalho causado por um problema de configurao aumenta ainda mais os custos da empresa no desenvolvimento do software em questo, pois ser necessrio recuperar a configurao correta do software para disponibiliz-la ao cliente, ou corrigir novamente um defeito que j tinha sido corrigido, o que, se a gerncia de configurao no estiver bem definida, tomar tempo da equipe de desenvolvimento, que deveria estar trabalhando em outras atividades. Da a necessidade de inserir a gerncia de configurao no mbito de uma organizao, fazendo com que todos os projetos sejam beneficiados por esta disciplina. A gerncia de configurao pode estar disseminada em uma organizao sob duas perspectivas: de projetos e de produtos [Farah-04]. A gerncia de configurao de um projeto inicia com o estabelecimento de uma baseline dos requisitos, entradas necessrias para o planejamento e execuo das atividades do projeto. Atravs destes requisitos, sero programados os releases do produto que atendero a estes requisitos. A gerncia de configurao do produto, por sua vez, lida com a gesto de todos os releases dos produtos, que contemplam todos os seus itens de configurao e deliverables, atendendo s evolues solicitadas e correes de erros detectados. Enquanto a primeira perspectiva (de projeto) aplicvel em organizaes orientadas a projeto ou a produtos, a segunda s faz sentido quando a organizao orientada a produto. Quando uma empresa possui estas duas perspectivas, a gerncia de configurao do produto passa a administrar tambm os impactos que os projetos geram nos produtos da empresa, aumentando a complexidade da atividade de gerncia de configurao.
1.2. Proposta de Trabalho
Este trabalho apresenta a proposta de um processo alinhado ao nvel 2 de maturidade e capacidade do CMMI para a rea de processo de gerncia de configurao, destinado a fbricas de software orientadas a produto. A escolha da gerncia de configurao vem da necessidade de estruturar esta rea de suporte to critica para o funcionamento de uma fbrica de software orientada a produtos, onde a gesto de verses e o controle de mudanas so to crticos quanto a gesto de operaes. O processo tem o propsito de definir as atividades da gerncia de configurao desde o planejamento do projeto (para novos desenvolvimentos) e do produto (para as manutenes evolutivas e corretivas) at a disponibilizao de uma verso para o cliente, permeada pelas auditorias peridicas de configurao. O processo uma instncia da rea de processo de
Captulo 1- Introduo
gerncia de configurao, procurando orientar as fbricas de software orientadas a produto na definio desta rea na organizao. No entanto, o processo no est preso a ferramentas especficas, visto que isso restringiria a sua implantao em fbricas que usassem outras ferramentas. Alm disso, so sugeridos templates e mtricas de acompanhamento do desempenho do processo, que podem ser facilmente adaptados pela fbrica em sua implantao.
1.3. Estrutura do Trabalho
Alm deste captulo introdutrio, esta dissertao est organizada da seguinte forma: O captulo 2 apresenta os conceitos associados a Fbricas de Software, mostrando sua evoluo histrica e as variaes de estrutura vinculadas estratgia de negcio da organizao, onde sero tratadas as estruturas orientadas a projeto e a produto. O captulo 3 apresenta uma viso geral do modelo CMMI, atravs da descrio de seus princpios-chave e principais conceitos. Sero abordadas as representaes contnua e por estgios e a equivalncia entre elas, com o direcionamento para a rea de processo Gerncia de Configurao. Ser apresentada tambm uma viso geral sobre o CMMI no mundo e no Brasil. O captulo 4 apresenta o detalhamento da rea de processo Gerncia de Configurao, atravs da interpretao de suas prticas genricas e especficas, evidenciando as dificuldades em fbricas orientadas a projeto e produto na execuo destas atividades e ressaltando as oportunidades de melhoria com a implantao deste modelo nas organizaes. O captulo 5 apresenta uma proposta de processo de Gerncia de Configurao alinhado aos nveis 2 de maturidade e capacidade do CMMI para esta rea de processo, detalhando seus subprocessos, atividades, papis e responsabilidades, no contexto direcionado s fbricas de software orientadas a produto. O captulo 6 apresenta uma anlise crtica do processo proposto no captulo 5 em relao rea de processo Gerncia de Configurao, apresentada no captulo 4, atravs da simulao de uma avaliao SCAMPI [SEI-01], evidenciando os artefatos diretos, indiretos e sugestes de entrevistas para corroborao de informaes em uma avaliao do processo.
Captulo 1- Introduo
O captulo 7 apresenta um estudo de caso da aplicao do processo proposto no captulo 5 em uma fbrica de software real, orientada a produto. Neste captulo ser detalhada a execuo do processo em 02 projetos vinculados a um produto de uma fbrica de software, atentando para os benefcios e dificuldades encontradas durante a implantao do processo.
O captulo 8 apresenta a concluso deste trabalho, atravs da apresentao das principais contribuies realizadas pelo trabalho, dificuldades encontradas, trabalhos relacionados ao tema abordado na dissertao e trabalhos a serem realizados para evoluir o resultado deste.
Alm dos captulos supracitados, esta dissertao contm dois anexos, que apresentam templates e checklists de apoio ao processo definido proposto no captulo 5.
Captulo 2- Fbricas de Software
Captulo 2. Fbricas de Software

Neste captulo apresentado o histrico das estruturas organizacionais fabris, que motivaram a criao das fbricas de software, alm das diferentes maneiras de estruturao destas fbricas, do ponto de vista organizacional e do ponto de vista de foco de mercado.
O conceito de Fbrica de software envolve um ambiente de produo de software que suporta a produo de software de maneira mais industrializada, adotando as prticas da indstria e engenharia [Lim-99]. Embora o conceito de fbrica de software exista h pelo menos 30 anos, a adoo e aplicao deste modelo so recentes e ainda no atingiram grandes escalas. Desde a descoberta desse novo modelo de trabalho para o desenvolvimento de software, surgiram diversas adaptaes do mesmo, com diferentes abordagens, focando ora em ferramentas, ora em processos. Dentre muitos modelos, podemos citar trs em destaque: o modelo japons, com foco em alta produtividade e qualidade; o modelo europeu, com foco na integrao de ambientes de desenvolvimento de software; e o modelo norte-americano, com as abordagens baseadas na experincia e na maturidade da organizao [Aaen-97]. A abordagem japonesa para o conceito de fbrica se baseia na juno de idias, tcnicas e ferramentas, todas alinhadas sob a tecnologia e a organizao. Nesse modelo, o foco principal da organizao tornar a rotina de trabalho simples e repetitiva, e padronizar os processos de trabalho. As diferentes experincias das organizaes japonesas culminaram no levantamento de nove elementos bsicos comuns s organizaes de desenvolvimento de software [Cusumano-04]: Comprometimento com a melhoria de processos: os gerentes das empresas que criaram suas estruturas de fbrica acreditavam que o novo processo traria frutos positivos, como a maior previsibilidade de prazos e qualidade para os produtos e servios oferecidos pelas empresas. Havia tambm o entendimento de que, para se atingir os objetivos desejados, seria necessrio investimento, e que a produtividade da equipe sofreria uma queda inicial devido ao aprendizado do novo processo. Graas ao comprometimento da alta gerncia, as dificuldades encontradas foram superadas, pois havia a crena da melhoria dos processos. Segmentao e foco em produto-processo: algumas abordagens bem sucedidas de fbricas de software foram: a segmentao dos produtos da fbrica e a adoo de processos padronizados para estes segmentos. Isso garantiu s fbricas o foco no conhecimento das regras de negcio do produto (ou do segmento de mercado dos clientes) entre as equipes e permitiu a terceirizao de atividades no relacionadas s regras de negcio dos produtos, viabilizando alternativas de alocao de recursos para
10
a fbrica sempre que necessrio. Os processos padronizados garantiram a uniformizao de trabalho entre os segmentos. Anlise e controle da qualidade e do processo: a implantao de processos nas organizaes veio acompanhada das auditorias, cujo objetivo era monitorar e garantir a execuo correta dos processos, e do controle de qualidade dos produtos e servios prestados, passando a ter uma maior previsibilidade de defeitos e custos com retrabalho dentro da empresa. Processo centralizado de pesquisa e desenvolvimento: os processos de uma organizao devem servir como base para todos os projetos executados por ela, podendo ser instanciados de acordo com a natureza tecnolgica ou requisitos associados ao projeto. Para tal, em vez de construir processos individuais (direcionados apenas para um projeto), com seus guias e ferramentas, as organizaes passaram a compartilhar as experincias entre si, tendo uma rea de pesquisa e desenvolvimento de processos e ferramentas que possam ser reutilizados dentro da empresa, evitando gastos com estudos similares e gerao de redundncias de processos, ferramentas e guias dentro da empresa. Nivelamento e padronizao do conhecimento: a disseminao do conhecimento entre os membros das fbricas de software se mostrou um grande benefcio para as empresas, pois alm de possuir um nivelamento de conhecimento interno, a empresa minimiza a cada momento a dependncia de indivduos especficos da fbrica, ou seja, as pessoas que se tornam concentradoras de conhecimento dentro da empresa, e que passam a ser objeto de dependncia pelos projetos da fbrica. Padronizao dinmica: alm da definio de processos padronizados e disseminao do conhecimento (vistos acima), as fbricas passaram a definir a reviso sistemtica de seus processos, padres, guias e ferramentas, para avaliar os benefcios trazidos para a organizao e melhorar o ambiente de trabalho da fbrica, evoluindo seus processos sempre que necessrio. Esta prtica se torna extremamente importante quando ligada anlise e controle do processo, pois os processos precisam ser revistos periodicamente para garantir a melhoria do desenvolvimento na fbrica. Reusabilidade sistemtica: as fbricas de software tm investido cada vez mais na disseminao da cultura do reuso, criando componentes e ferramentas que possam ser
11
utilizadas no desenvolvimento de vrios projetos da empresa. O benefcio do reuso a centralizao do desenvolvimento e evoluo de determinados componentes e a replicao rpida deste benefcio nos projetos que usam estes componentes. Alm disso, a empresa passa a ter equipes dedicadas a este tipo de atividade, sendo fornecedoras dos projetos internos da fbrica. Integrao de ferramentas CASE ao ambiente de fbrica: a utilizao de ferramentas aderentes ao processo definido para a fbrica integradas no ambiente de desenvolvimento contribuiu positivamente para institucionalizao do processo entre as equipes, pois facilitou a absoro do processo dentro da organizao, inserindo o mesmo na rotina de trabalho das equipes. Melhoria dos processos de maneira incremental: as fbricas se concentraram em implantar em suas organizaes os processos definidos e o controle da qualidade de seus produtos para depois iniciar um novo processo de melhoria destes processos implantados. Desta forma, foi possvel estabilizar os processos e avaliar objetivamente os benefcios e as oportunidades de melhoria dos mesmos para cada organizao. A simultaneidade entre implantao e melhoria de um processo tende a comprometer as duas atividades, pois a empresa passa a no ter um objetivo definido em relao qualidade na organizao.
J o modelo europeu foca na criao de uma arquitetura e um framework para ISDEs Integrated Software Development Environments, atravs da criao de um modelo genrico de fbrica de software constitudo de ferramentas, componentes e ambientes que suportem diversas reas de negcio [Aaen-97]. Dessa forma, possvel instanciar um ambiente de fbrica a partir do modelo genrico e adapt-lo organizao para apoiar a execuo de um determinado projeto. No entanto, a busca pela generalizao envolve o desafio de manter um processo de trabalho dentro de uma organizao montada a partir de um modelo genrico, onde, independente dos componentes utilizados para montar um ambiente de fbrica, o processo deve fluir com sucesso entre estes componentes. Para tal, o modelo genrico busca embutir o processo de software nas ferramentas de suporte ao ambiente de fbrica, de modo a automatizar a padronizao do trabalho. Usando como base os nove elementos descritos anteriormente, esta abordagem trata apenas poucos elementos: o foco em produto e em
12
processo, pesquisa e desenvolvimento centralizados de processos, reusabilidade sistemtica e integrao de ferramentas computadorizadas ao ambiente de fbrica. A abordagem norte-americana baseada em experincias, tambm conhecida por Fbrica de Experincias, suportada pelo paradigma de melhoria da qualidade [Basili-92] resumido atravs dos seguintes passos: Plan: os projetos so planejados, onde seus objetivos so estabelecidos utilizando experincias de projetos anteriores. Execute: aps o planejamento, os projetos so executados e controlados atravs de medies. Analyze: as experincias dos projetos so avaliadas e comparadas com seus planejamentos Synthesize: os resultados so armazenados para utilizao em projetos futuros.
Nesta abordagem, o foco o aprendizado atravs das experincias, onde possvel errar, desde que sejam extradas lies para as prximas etapas. A partir desse aprendizado, torna-se possvel o entendimento das relaes entre aspectos qualitativos de produtos e caractersticas dos processos aplicados na fbrica, o que facilita a tomada de aes para novas melhorias na organizao. Neste modelo, o esforo para a implementao da melhoria dos processos atravs da experincia intenso, pois exige da fbrica um controle mais preciso sobre a execuo de suas atividades, atravs da utilizao de mtricas. Partindo desta abordagem, surge o modelo de uma organizao madura, cujo objetivo atingir um processo de desenvolvimento previsvel, confivel, e passvel de evolues, capaz de suportar a produo de softwares de alta qualidade [Paulk-93]. Associando o conceito de maturidade pregado por este modelo realidade de uma fbrica de software, isto pode ser entendido como a possibilidade de a fbrica ter maior controle sobre sua capacidade de produo. E isso significa realizar planejamentos pouco mutveis, com estimativas mais precisas de custo, esforo e tamanho para os projetos, executar o desenvolvimento de forma monitorada e controlada, sem desvios significativos do planejamento, ser capaz de corrigir os desvios do processo sem comprometer os custos de desenvolvimento, e, por fim, gerar um produto de alta qualidade. As abordagens apresentadas nesta seo mostram que o objetivo dos modelos de fabrica tem evoludo atravs dos tempos buscando a melhoria de processos na organizao,
13
para que a fabrica seja capaz de absorver toda a demanda de servios e produtos sem prejudicar seu funcionamento, e conseqentemente, a qualidade de seus produtos. Alm disso, os processos de uma fbrica devem ser capazes de suportar tambm os conceitos tpicos de fbricas, como a padronizao e o controle da produo. Embora a abordagem da melhoria de processos faa parecer simples a sua execuo, preciso evoluir gradativamente a maturidade da organizao, para que ela aos poucos consiga entender sua capacidade, e passe a responder melhor s demandas solicitadas. Neste contexto, a fbrica pode ser um ponto de incio da melhoria, e propagar esse processo pelos demais setores da organizao onde a fbrica est inserida.
2.1. Contexto das fbricas de software dentro da organizao
Segundo [Fernandes-04], as fbricas de software podem estar organizadas de duas formas: Uma rea da organizao, subordinada a outras reas da prpria empresa. A prpria organizao.
No primeiro cenrio, conforme exemplifica a Figura 2-1, a fbrica de software considerada uma rea da organizao, que deve possuir metas internas alinhadas ao planejamento estratgico da empresa, e que deve gerar lucro para a organizao.
Figura 2-1 Contexto de fbrica de software como rea de uma organizao
14
Neste cenrio, alguns pontos se tornam crticos: Deve haver uma definio clara do escopo de trabalho da fbrica, ou seja, as entradas e as sadas esperadas para a realizao bem sucedida das atividades da fbrica dentro da organizao. Devem ser estabelecidos os canais de comunicao com a fbrica, para que no haja a banalizao da produo. A fbrica deve possuir um programa de atendimento s demandas geradas pelos seus clientes, sejam eles internos ou externos.
J no segundo cenrio, como exemplifica a Figura 2-2, a fbrica pode ser a prpria organizao, com metas estabelecidas, e composta por diversas reas, desde a administrao da organizao at os setores de produo propriamente ditos, como a codificao e especificao de requisitos.
Figura 2-2 Contexto de fbrica de software como a organizao
Neste cenrio, a fbrica passa a estar diretamente ligada aos seus clientes, que so sempre externos, pois ela a prpria organizao. O processo de desenvolvimento da fbrica passa a ser composto pelos processos de suas reas, que devem possuir canais de comunicao.
15
2.2. Estruturao organizacional das Fbricas: produtos versus projetos
Alm dos modelos de estruturao de uma fbrica de software, importante ressaltar tambm a abordagem de negcio das mesmas, que pode facilitar ou dificultar o processo de melhoria de processos na organizao. Podemos citar duas estruturaes organizacionais: fbrica orientada a produtos e fbrica orientada a projetos [Tachizawa-97]. No contexto da orientao a produtos, o desenvolvimento da fbrica funciona em torno dos produtos produzidos por ela (Figura 2-3). Neste caso, a fbrica deve conciliar a rotina de manuteno de seus produtos, seja ela evolutiva ou corretiva, com as demandas geradas por diferentes projetos, que culminam no surgimento ou evoluo de funcionalidades no produto. Dessa forma, o produto sempre preservado dentro da fbrica, podendo ser customizado ou parametrizado para os clientes demandadores de projetos.
Figura 2-3 Representao de desenvolvimento orientado a produto
Dentro dessa estrutura de fbrica, importante citar o papel do gerente de produto, que comanda no apenas o desenvolvimento demandado pelos projetos, mas que garante a integridade do produto que est sendo modificado constantemente.
16
Na orientao a projetos, a rotina da fbrica funciona atravs da execuo de diversos projetos em paralelo (Figura 2-4), podendo estes ser interdependentes ou reusarem componentes entre si, mas todos com comeo, meio e fim planejados. Neste caso, no h um produto que deve ser atualizado pelos projetos executados. A sada da fbrica varia de acordo com a demanda de projetos existentes. Nesta estrutura, a responsabilidade por cada projeto pode ser acumulada por um nico gerente de projeto ou distribuda entre um grupo de gerentes.
Figura 2-4 Representao de desenvolvimento orientado a projeto
importante avaliar estas duas abordagens sob trs importantes pontos de vista: esforo de gerncia, produo de dados histricos e gerncia de configurao. Do ponto de vista de esforo gerencial, existe uma grande variao entre as abordagens. Na fbrica orientada a produtos, existe a preocupao constante em relao aos impactos de uma demanda gerada por um projeto no afetar os projetos em andamento e o produto existente, ou seja, o rastreamento entre solicitaes e as funcionalidades existentes torna-se um fator crtico de sucesso da fbrica que segue esta abordagem. Alm disso, o gerenciamento das atividades de desenvolvimento para atender s demandas especificadas torna-se bastante complexo, pois o gerente da fbrica deve alinhar as expectativas de entrega
17
dos projetos existentes ao planejamento de liberao das verses do produto, sem comprometer os clientes que j possuem o mesmo em produo. J nas fbricas orientadas a projeto, a preocupao relativa a impactos entre projetos s acontece quando os mesmos so interdependentes. Alm disso, a configurao e o planejamento de liberao de verses dos produtos gerados pelos projetos, independente de sua complexidade, so gerenciados apenas no mbito de cada projeto, possibilitando que cada projeto possa ter um comportamento completamente diferente dos outros. Analisando sob o ponto de vista de produo de dados histricos para os dois estilos de fbricas, o comportamento se inverte quando comparado ao esforo gerencial. Em uma fbrica orientada a projeto, enquanto o esforo gerencial menor em relao a uma fbrica orientada a produto, a produo de dados histricos para gerao de estimativas em projetos futuros mais complexa. Os projetos da fbrica nem sempre possuem caractersticas comuns, de modo que o processo de estimativas leva em considerao quesitos tcnicos, como domnio de linguagem de programao, arquitetura, produtividade da equipe, entre outros. Porm, o entendimento do domnio, vinculado ao negcio no qual o projeto est inserido, nem sempre passvel de estimativa, pois no h garantia de vnculo da fbrica a um nico ramo de negcio. Essa questo passa a ser um risco embutido nas estimativas da fbrica que culminaro no desenvolvimento do projeto. A realidade das fbricas orientadas a produto em relao produo de dados histricos diferente: apesar de existirem vrios projetos em paralelo, todos eles trabalham sob a tica de um mesmo produto. Por causa disso, os dados histricos produzidos ao longo da execuo de projetos podem ser realmente utilizados como base para estimativas futuras, pois o entendimento do domnio no varia a cada novo projeto (j que a equipe de desenvolvimento passa a ser formada por especialistas no negcio). Assim, o fator entendimento do negcio passa a ter um peso menor quando avaliando os riscos associados aos projetos e ao produto. importante analisarmos as duas estruturas de fbrica do ponto de vista da gerncia de configurao. Esta rea, que fornece suporte ao desenvolvimento de projetos, demanda caractersticas especficas em cada estrutura organizacional da fbrica. Em uma fbrica orientada a projetos, o planejamento e a execuo das atividades da gerncia de configurao podem variar completamente entre os projetos executados dentro da fbrica, pois cada um
18
possui caractersticas especficas demandadas pelos clientes, causando um trabalho adicional para os gerentes de configurao da fbrica. No entanto, esta caracterstica das fbricas orientadas a projeto possibilita facilmente a paralelizao dos recursos de gerncia de configurao, ou seja, possvel ter em cada projeto um gerente de configurao dedicado, visto que todas as caractersticas do projeto interferem apenas no prprio projeto. J nas fbricas orientadas a produto, a realidade um pouco diferente. Como o foco da fbrica o produto, a gerncia de configurao est orientada totalmente ao produto da empresa. Os projetos que geram novas funcionalidades e as manutenes evolutivas e corretivas possuem uma gerncia de configurao que complementa a do produto. O controle da configurao do produto deve ser acirrado, para que os projetos no criem conflitos dentro do produto que est sendo modificado e a gerao de verses do produto agrega os resultados dos projetos e das manutenes. Diante deste painel, o gerente de configurao passa a ter um papel imprescindvel dentro da fbrica, tendo que manter sincronizada a configurao do produto e a configurao de cada projeto dentro da fbrica.
2.3. Ciclo de desenvolvimento em fbricas de software
Independente da abordagem adotada para a estruturao de uma fabrica de software, o ciclo de vida do software desenvolvido geralmente possuir como base as seguintes fases [Fernandes-04]: (1) planejamento; (2) especificao de requisitos; (3) anlise e projeto de requisitos; (4) construo; (5) implantao; e (6) transio. No contexto de fbricas orientadas a projetos, estas fases sero distribudas de acordo com o ciclo de desenvolvimento adotado pela empresa para cada projeto. Para as fbricas orientadas a produto, essas fases devero tratar no apenas o desenvolvimento de novas funcionalidades para o produto, como tambm a sua manuteno (evolutiva ou corretiva). Por exemplo, na etapa de planejamento, devem ser considerados no apenas os projetos de novos desenvolvimentos, como tambm as solicitaes de mudana para o produto, fruto dos projetos de manuteno.
2.4. Linhas de produto de software
As linhas de produto de software, tambm conhecidas como Software Product Lines (SPL), podem ser vistas como uma evoluo do conceito de fbricas de software orientadas a produto, onde os produtos fazem parte de uma famlia, compartilhando caractersticas,
19
arquitetura, componentes e artefatos em seu desenvolvimento. Segundo [Cohen-02], uma definio adequada para SPL seria um conjunto de sistemas de software que compartilham um conjunto de caractersticas comuns e gerenciados que satisfazem s necessidades de um determinado segmento de mercado ou misso, e que so desenvolvidos a partir de um conjunto comum de ativos principais em uma maneira pr-estabelecida. [Clements-02]. Entendendo melhor esta definio, a chave para os produtos de uma SPL so os ativos, considerados o core da linha de produto. A arquitetura dos produtos segue uma definio feita para a SPL, os componentes compartilhados entre os produtos so mantidos em paralelo ao desenvolvimento, demandando uma gerncia de configurao especializada. So estes aspectos que tornam a SPL uma especializao das fbricas orientadas a produto. A complexidade da gesto dos produtos se torna maior exatamente por causa dos ativos, j que eles viabilizam a integrao entre os produtos da mesma famlia. O foco em um segmento de mercado, por sua vez, torna mais fcil o desenvolvimento de uma SPL, visto que o conhecimento necessrio para este mercado se torna cada vez mais especializado dentro da organizao com SPL, permitindo uma evoluo maior dos produtos para atender s demandas do mercado, alm da disseminao do conhecimento dentro da empresa, um dos elementos propostos por [Cusumano-04].
2.5. Consideraes Finais
Este captulo apresentou os principais conceitos relacionados a fbricas de software, abordando sua evoluo histrica e as variaes de estrutura vinculadas estratgia de negcio da organizao, onde foram citadas as estruturas orientadas a projeto e a produto, e as linhas de produto de software. importante ressaltar que independente da estrutura de negcio adotada, necessrio criar processos aderentes a cada uma delas, com o objetivo de extrair dessas organizaes o seu melhor desempenho e, conseqentemente, beneficiar os clientes que recebem os produtos gerados por estas estruturas de fbrica. Para tal, a utilizao de modelos de processo existentes e conceituados no mercado fundamental para orientar a organizao em seu processo de melhoria de qualidade.
20
Captulo 3- Viso Geral do CMMI
Captulo 3. Viso Geral do CMMI

Este captulo apresenta uma viso geral do CMMI, passando pela motivao de sua criao, seus nveis de capacidade e maturidade. mostrado ainda o contexto atual do mercado em relao aos nveis de maturidade.
21
A produo de software ou servios de maneira mais rpida, mais barata e com melhor qualidade tem sido o objetivo de todas as organizaes que desejam sobreviver no mercado atual, cada vez mais competitivo e globalizado. Nesse ambiente, equilibrar estas variveis e a satisfao do cliente torna-se uma tarefa de difcil execuo, mas que, uma vez realizada com sucesso, traz benefcios completos organizao. Uma das abordagens adotadas por muitas organizaes a melhoria de seus processos, movida pela premissa do gerenciamento de processos, onde a qualidade de um sistema ou produto fortemente influenciada pela qualidade do processo usado para desenvolv-lo e mant-lo [Ibrahim-95]. Atualmente, a maioria das organizaes ainda gerencia apenas seus produtos, em vez de gerenciar tambm seus processos. Realizar esta ltima atividade implica fornecer um ambiente monitorado e controlado para a produo de software ou servios com maior visibilidade, levando identificao dos problemas na organizao, e criando oportunidades de melhoria contnua da organizao, em nvel de produto e, principalmente, de processo. A partir desta necessidade, o SEI Software Engineering Institute, criou os modelos de capacidade e maturidade. Os CMMs, como so comumente chamados, surgiram com o foco na melhoria dos processos de uma organizao, de maneira evolucionria e gradativa, provendo um caminho para a migrao de uma organizao com processos imaturos e no controlados para processos maduros, com qualidade e eficincia [Chrissis-03]. No entanto, estes modelos, que abordavam disciplinas especficas, como Engenharia de Software, Engenharia de Sistemas e Desenvolvimento Integrado de Produtos, ofereciam dificuldades na integrao de suas disciplinas, o que levou o SEI a criar um framework nico para a melhoria de processos, cujo foco, alm dos objetivos destes CMMs, era prover um ambiente de integrao entre as disciplinas antes abordadas isoladamente. Surgiu ento o CMMI, que aborda no s o desenvolvimento e manuteno de produtos/servios, como tambm permite a integrao destas reas com outras reas de conhecimento. Como foco do estudo deste trabalho, abordaremos o CMMI direcionado para a Engenharia de Software [SEI029-02].
3.1. Representaes do CMMI
O CMMI est estruturado inicialmente em reas de processo, que agrupam prticas comuns para uma determinada rea do processo, e que, uma vez implementadas em conjunto
22
na organizao, contribuiro para a melhoria daquela rea. Cada rea de processo, por sua vez, composta por dois elementos [Chrissis-03]: metas especficas: objetivos restritos a uma determinada rea de processos, que devem estar evidenciados na organizao para que a rea de processo seja atendida. As metas especficas so de requerimento obrigatrio em uma avaliao CMMI. As metas especficas so compostas por prticas especficas, que representam atividades importantes para atingir a meta. metas genricas: objetivos comuns a vrias reas abordadas no CMMI, que representam aspectos da institucionalizao de uma rea de processo, ou seja, esto relacionados execuo diria do processo dentro da organizao, e, assim como as metas especficas, so obrigatrias em uma avaliao CMMI. Uma meta genrica composta por prticas genricas, que, assim como as prticas especficas, representam atividades importantes para se atingir a meta genrica.
Atualmente, o CMMI compreende 25 reas de processo,
que
abordam
diferentes
elementos essenciais do processo a ser melhorado. No entanto, o CMMI buscou atender dois perfis de organizaes: As que desejam melhorar seus processos abordando determinadas reas do mesmo (como gerncia de processo, gerncia de projeto, engenharia ou suporte), aumentando a capacidade do processo a cada rea implementada. As que desejam melhorar a maturidade de seu processo, abordando um conjunto de reas do mesmo que representam a maturidade a ser alcanada.
Baseado nestes perfis, o CMMI apresenta duas representaes: contnua [SEI028-02], direcionada para o aumento da capacidade da organizao (Figura 3-1), e por estgios [SEI029-02], para quem deseja melhorar a maturidade da organizao (Figura 3-2). Cada representao apresenta seus nveis de dependncia e rigor de cada elemento que compe a estrutura do modelo, alm dos elementos que determinam a evoluo da maturidade e capacidade da organizao. Neste trabalho, ser abordada a representao contnua como base para a melhoria de processos nas fbricas de software.
23
Figura 3-1 Estrutura do modelo CMMI para a representao contnua
Figura 3-2 Estrutura do modelo CMMI para a representao por estgios
3.2. Nveis de Maturidade e Capacidade do CMMI
Para poder avaliar a melhoria dos processos, o CMMI precisa categorizar o atendimento s 25 reas de processo abordadas por ele. No entanto, por possuir duas representaes, contnua e por estgios, foram elaborados nveis associados a cada uma delas:
24
Nveis de capacidade (Tabela 3-1 Nveis de capacidade do CMMI) que abordam a melhoria dos processos em reas de processo individualmente.
Nvel de Capacidade 0 Incompleto
Caracterizao
Processo no realizado, ou parcialmente realizado. Uma ou mais metas especficas no so satisfeitas pelo processo.
1 Realizado
O processo atende s metas especficas de uma determinada rea de processo.
2 Gerenciado
O processo realizado (nvel 1) planejado, controlado e sua aderncia organizao avaliada.
3 Definido
O processo gerenciado (nvel 2) concebido a partir de processos padres da organizao.
4 Gerenciado
O processo definido (nvel 3) controlado atravs de tcnicas
Quantitativamente estatsticas. 5 Em Otimizao O processo gerenciado quantitativamente (nvel 4) continuamente melhorado atravs do entendimento das causas dos desvios encontrados no processo.
Tabela 3-1 Nveis de capacidade do CMMI
Nveis de maturidade (Tabela 3-2), que abordam a melhoria dos processos atravs de um conjunto de reas de processo.
Nvel de Maturidade 1 Inicial
Descrio
O processo catico ou ad hoc. Seu sucesso depende de esforos individuais dentro da organizao.
2 Gerenciado
Os processos de cada projeto so planejados, realizados, medidos e controlados.
3 Definido
Os processos so organizacionais e adaptados para cada projeto, quando necessrio.
Gerenciado A qualidade e o desempenho dos processos definidos so medidos quantitativamente atravs de tcnicas estatsticas. Os processos gerenciados quantitativamente so continuamente
Quantitativamente 5 Em Otimizao
25
Nvel de Maturidade
Descrio
melhorados atravs do entendimento das causas dos desvios encontrados nos processos.
Tabela 3-2 Nveis de maturidade do CMMI
Adotando uma dessas abordagens, uma organizao passa a compreender claramente a evoluo dos seus processos, independente da representao do CMMI adotada.
3.3. Evoluo do CMMI no mundo
O CMMI, sendo uma evoluo do modelo CMM, surgiu a partir da necessidade do Departamento de Defesa Americano em possuir um mecanismo confivel de avaliao e seleo dos fornecedores de sistemas para este departamento [Phillips-07]. Esse mecanismo gerou um conjunto de melhores prticas, que levaram criao do CMM e sua evoluo ao CMMI. Para o Departamento de Defesa Americano, uma empresa fornecedora deveria possuir minimamente o nvel 3 de maturidade, o que geraria um alto ndice de confiabilidade dos produtos gerados por estas empresas. Esta preocupao com a qualidade dos produtos e servios passou a extrapolar os limites do governo e se tornou motivo de qualificao das empresas do mercado comercial, que passaram a estudar e implantar o CMM(CMMI) em suas organizaes para atingir um nvel de qualidade dos seus produtos e servios suficiente para torn-las cada vez mais competitivas no mercado. De acordo como o ltimo Process Maturity Profile realizado em 2006 [SEI-06], o nmero de organizaes comerciais est comeando a sobrepor o nmero de organizaes contratadas pelo governo, sendo que esta nova maioria est concentrada fora dos Estados Unidos (Figura 3-3 e Figura 3-4). Isso mostra que a preocupao com a melhoria de processos, agora alinhada ao CMMI, est se propagando por todo o mundo, inserindo no contexto da melhoria da qualidade empresas de diversos pases, e contribuindo para o benefcio de mais clientes que passam a adquirir produtos de maior qualidade desenvolvidos por estas empresas.
26
Figura 3-3 Distribuio das avaliaes entre organizaes americanas e no americanas
Figura 3-4 - Perfil de Maturidade em organizaes americanas e no-americanas
27
Analisando o grfico da figura 3-5, podemos identificar tambm que a maioria das avaliaes se concentraram nos nveis 2 e 3 de maturidade. importante analisarmos este dado do seguinte ponto de vista: muitas empresas esto optando por implantar processos bem definidos em suas organizaes, garantindo que os mesmos sejam planejados e controlados para cada projeto, o que nos leva ao nvel 2 de maturidade. Isso significa que as empresas esto cada vez mais preocupadas em ter processos definidos, que guiem o desenvolvimento dos produtos e servios dentro da organizao, e que a qualidade de sua produo seja conseqncia da implantao bem sucedida destes processos. Alm disso, vimos que h a preocupao com a evoluo destes processos j implantados, para torn-los padronizados para toda a organizao (foco do nvel 3 de maturidade), ou seja, a melhoria contnua passa a ser lema das organizaes, pois elas j vivenciaram os benefcios trazidos pela implantao de processos.
Figura 3-5 Perfil de Maturidade de Processos segundo o CMMI
Resultados de desempenho reportados por organizaes j avaliadas em diversos nveis de maturidade (Tabela 3-3) mostram o poder de melhoria real de processos de organizaes que adotaram o CMMI como modelo de qualidade [SEI-07].
28
Nmero de Categoria de Desempenho Custo Cronograma Produtividade Qualidade Satisfao do Cliente Retorno de Investimento Mdia 20% 37% 62% 50% 14% 4.7:1 Organizaes 21 19 17 20 06 16 Mnimo Mximo 3% 2% 9% 7% -4% 2:1 87% 90% 255% 132% 55% 27.7:1
Tabela 3-3 Resultado de desempenho de organizaes avaliadas no CMMI3
3.4. Evoluo do CMMI no Brasil
Com a globalizao, a possibilidade de atender demandas externas e concorrer com empresas que possuem em sua maioria processos bem definidos e, em alguns casos, nveis de maturidade estabelecidos, torna obrigatria a busca pela melhoria de processos pelas empresas brasileiras. E as avaliaes dos processos so um caminho importante para atingir estes objetivos, pois por trs de uma declarao de nvel de maturidade est a estruturao e melhoria dos processos internos da organizao. Segundo o relatrio publicado pelo MCT em agosto de 2006 [MCT-06], o mercado brasileiro ainda est iniciante no contexto de melhoria da qualidade dos processos. Segundo a figura 3-6, o nmero de organizaes qualificadas em SW-CMM/CMMI evoluiu bastante ao longo dos anos, mas ainda pouco quando comparado com os nmeros mundiais. Isto refora a necessidade de buscar a melhoria atravs da implantao de processos, para que as empresas brasileiras se tornem cada vez mais competitivas no mercado mundial.
Baseado nas informaes quantitativas de 25 organizaes que reportaram resultados que podem ser
considerados como mudanas de performance ao longo do tempo.
29
Figura 3-6 Organizaes brasileiras com qualificao CMMI entre 1997 e 2006)4
importante ressaltar que as empresas podem obter a melhoria de processos tanto atravs do nvel de maturidade investindo na melhoria simultnea de vrias reas de processo, como tambm pode adotar a estratgia de aumentar a capacidade de cada processo aos poucos, iniciando pelos processos considerados mais crticos dentro da organizao. Este trabalho baseia-se nesta necessidade, com a proposta de um processo de gerncia de configurao alinhado ao nvel 2 de maturidade e capacidade, pois, independente da abordagem adotada pela empresa, a implantao de um processo o pontap inicial para um
Fonte: ISD Brasil, Procesix, empresas qualificadas e imprensa especializada, compilado por MCT/SEPIN/DIA
Situao em Agosto de 2006.
30
longo caminho de aprimoramento de processos de qualidade baseado no CMMI, e que causa uma mudana de paradigmas do ponto de vista da melhoria da organizao, onde a qualidade dos produtos e servios produzidos uma conseqncia natural da melhoria da prpria organizao.
3.5. Avaliaes do CMMI
Como dito na seo anterior, a avaliao do nvel de maturidade ou capacidade de uma organizao em relao ao CMMI visa averiguar a real melhoria de processos dentro da organizao, evidenciando o desenvolvimento estruturado e organizado na empresa, com procedimentos e ferramentas adequadas e que contribuem para a melhoria da organizao. Para a realizao de uma avaliao CMMI, O SEI estabeleceu o ARC (Appraisal Requirements for CMMI), que contm os critrios para desenvolver, definir e usar os mtodos de avaliao baseados nos modelos do CMMI [SEI034-01]. Para atender a diversos nveis de rigor de avaliao, foram definidas 03 classes de avaliao, como apresenta a Tabela 3-4, com suas respectivas caractersticas. Caractersticas Quantidade de evidncias objetivas coletadas (Relativo) Classificao em um nvel de maturidade ou capacidade Necessidade de recursos (Relativo) Tamanho da equipe (Relativo) Requisitos para o lder da avaliao Grande Avaliador lder oficial Mdio Avaliador lder oficial ou uma pessoa treinada e experiente
Tabela 3-4 Caractersticas das classes de avaliao CMMI
Classe A Alto
Classe B Mdio
Classe C Pouco
Sim
No
No
Sim
No
No
Pequeno Uma pessoa treinada e experiente
Os mtodos de avaliao Classe A devem atender a todos os requisitos do ARC, e so usados para realizar as avaliaes oficiais do CMMI, que geram o reconhecimento do mercado em relao maturidade ou capacidade da empresa. J os mtodos de avaliao
31
Classe B envolvem um subconjunto dos mtodos Classe A, no produzem uma classificao da empresa. So bastante teis para avaliar previamente a empresa, antes da realizao de uma avaliao oficial, pois j apresenta um painel muito prximo da avaliao classe A. Os mtodos Classe C, por sua vez, devem atender a um subconjunto dos mtodos Classe B. Eles devem ser usados para avaliaes simuladas internamente pela empresa, pois ajudam a acompanhar o progresso da implantao de processos na organizao, mas, assim como os mtodos Classe B, no classificam a empresa em um nvel de maturidade ou capacidade, apenas mostram um painel do status da institucionalizao dos processos na empresa. Dentro deste contexto, a prxima seo apresentar uma viso geral do SCAMPI [SEI01], um mtodo Classe A de avaliao CMMI. 3.5.1. Viso geral do SCAMPI O SCAMPI (Standard CMMI Appraisal Method for Process Improvement) foi criado para avaliar as organizaes em relao aos nveis de maturidade ou capacidade do CMMI e utilizado como base para diversos mtodos de avaliao usados no processo de melhoria interna de uma organizao. Este mtodo ser usado posteriormente para a realizao de uma anlise crtica do processo proposto de gerncia de configurao em relao ao nvel 2 de maturidade e capacidade do CMMI. Para tal, faz-se necessrio apresentar alguns conceitos referentes ao modelo, seguindo as definies realizadas por [Feitosa-04]: Unidade organizacional: o escopo da empresa que far parte da avaliao. Ela pode operar utilizando um conjunto de processos relacionados aos objetivos de negcio da empresa. Em grandes empresas, uma unidade organizacional funciona como um subconjunto da empresa, mas pode ser a prpria empresa, no caso de empresas de pequeno porte. Avaliao das metas: durante uma avaliao CMMI, o nvel de maturidade ou capacidade definido se todas as metas dos modelos avaliados foram satisfeitas. E estas metas s so consideradas satisfeitas quando as suas prticas so atendidas durante uma avaliao. Uma meta define muito genericamente um objetivo do modelo, mas o entendimento claro acontece atravs de suas prticas. Evidncias objetivas: so informaes quantitativas ou qualitativas, registros ou evidncias de fatos gerados por determinadas prticas de processos. Estas evidncias so implementadas e baseadas em medies, observaes, e testes, os quais so
32
passveis de verificaes. Segundo o SCAMPI, fontes de evidncias objetivas so apresentaes, ferramentas, documentos e entrevistas da avaliao. Indicadores de implementao das Prticas: so atributos ou caractersticas usados durante a avaliao para indicar se as prticas do modelo esto sendo implementadas pela unidade organizacional. So exemplos desses indicadores: Artefatos diretos: so sadas tangveis diretamente ligadas implementao de uma prtica especfica ou genrica. Geralmente, so artefatos explcitos no processo como sadas de atividades, mas podem ser implicitamente deduzidos durante a avaliao. Exemplos: para o processo de gerncia de configurao, um artefato direto da prtica especfica Planejar o processo o plano de gerncia de configurao. Artefatos indiretos: artefatos que so conseqncia da realizao de uma prtica genrica ou especfica, ou que apiam a sua implementao, mas que no so o objetivo direto daquela prtica. Durante uma avaliao, quando h dvidas quanto implementao da prtica, recorre-se aos artefatos indiretos como objeto de validao. Afirmaes: so declaraes orais ou escritas referentes implementao da prtica genrica ou especfica. Geralmente so obtidas atravs das entrevistas realizadas durante a avaliao, onde possvel corroborar as afirmaes com os artefatos diretos e indiretos e demais evidncias de implementao da prtica. Caracterizao da implementao das Prticas: a atribuio de um valor relacionado ao quanto a prtica est implementada na organizao. A partir destes atributos a organizao classificada em um nvel de maturidade ou capacidade (para as avaliaes Classe A). Da a necessidade de se ter minimamente pessoas experientes e treinadas para uma avaliao, pois so elas que definiro o atendimento ou no dos processos implantados ao modelo CMMI. A caracterizao abordados no SCAMPI. Tabela 3-5 apresenta os tipos de
33
Caracterizao Completamente Implementada (FI - Fully Implemented)
Requisitos Artefatos diretos apropriados existem Artefatos indiretos e/ou afirmaes existem para confirmar a implementao Nenhum ponto fraco detectado na
implementao Largamente Implementada (LI - Largely Implemented) Artefatos diretos apropriados existem Artefatos indiretos e/ou afirmaes existem para confirmar a implementao Existncia de um ou mais pontos fracos detectados na implementao Parcialmente Implementada (PI - Partially Implemented) Artefatos diretos no existem ou so julgados inadequados Artefatos indiretos e/ou afirmaes indicam a implementao de alguns aspectos da prtica Existncia de um ou mais pontos fracos detectados na implementao No Implementada (NI - Not Implemented)
Tabela 3-5 Caracterizao da implementao das prticas
Qualquer situao no coberta anteriormente
Corroborao das informaes: a realizao do cruzamento de todas as informaes levantadas durante a avaliao. So confrontados os artefatos diretos com as afirmaes e artefatos indiretos para que seja possvel estabelecer a caracterizao da implementao da prtica.
3.6. Relacionamento entre o nvel 2 de maturidade e capacidade do CMMI
Como dito anteriormente, uma organizao possui um nvel 2 de maturidade quando seus processos so planejados e controlados para cada projeto. E isso atingido atravs do atendimento s metas especficas e genricas deste nvel. Por sua vez, para atender ao nvel 2
34
de capacidade, a organizao deve atender a determinadas metas genricas e especificas de das reas de processo do CMMI escolhidas para a melhoria de capacidade. Nesta seo, ser apresentada a equivalncia das duas abordagens, ou seja, como possvel evoluir os processos de uma empresa usando uma abordagem mista entre contnua e estagiada. A Figura 3-7 apresenta a equivalncia entre os nveis de maturidade e capacidade do CMMI.
Figura 3-7 Equivalncia entre os nveis de capacidade e maturidade do CMMI
Analisando a figura acima, podemos perceber a seguinte relao entre os nveis de capacidade e maturidade [Chrissis-03]: Para atingir o nvel 2 de maturidade, as reas de processo deste nvel devem atender ao nvel 2 ou superior de capacidade. Para atingir o nvel 3 de maturidade, as reas de processo deste nvel e do nvel 2 de maturidade devem atender ao nvel 3 ou superior de capacidade. Para atingir o nvel 4 de maturidade, as reas de processo deste nvel e dos nveis 2 e 3 de maturidade devem atender ao nvel 3 ou superior de capacidade.
35
Para atingir o nvel 5 de maturidade, todas as reas de processo devem atender ao nvel 3 ou superior de capacidade.
Este trabalho est direcionado rea de processo Gerncia de Configurao, com o foco na equivalncia entre os nveis 2 de maturidade e capacidade para esta rea., que tem o objetivo de estabelecer e manter a integridade de todos os produtos de trabalho dos projetos, alm de controlar as mudanas na configurao do sistema.
Este captulo apresentou uma viso geral do CMMI - Capability Maturity Model Integration, incluindo seu histrico, suas representaes contnua e por estgios (e suas equivalncias), direcionando o foco para a equivalncia entre os nveis 2 de maturidade e capacidade para a rea de processo Gerncia de Configurao. importante ressaltar que antes mesmo de se iniciar a definio de um processo na organizao, necessrio realizar uma anlise crtica da rea de processo no nvel de maturidade ou capacidade do CMMI estabelecido como alvo e confront-la com o contexto atual da organizao onde este processo ser institucionalizado. Sem esse alinhamento, no ser possvel definir processos visivelmente aderentes rotina da organizao, comprometendo a iniciativa de melhoria da qualidade.
36
Captulo 4 - Anlise crtica da Gerncia de Configurao do nvel 2 do CMMI
Captulo 4. Anlise crtica da Gerncia de Configurao do nvel 2 do CMMI

Este captulo apresenta uma anlise detalhada da rea de processo gerncia de configurao, vinculada ao nvel 2 de maturidade do CMMI, identificando as possveis dificuldades associadas nas fbricas de software orientadas a produto.
37
De acordo com [IEEE-90], gerncia de configurao compreende as atividades necessrias para (1) identificar e documentar as caractersticas fsicas e funcionais dos itens de configurao, (2) controlar as mudanas nestes itens, (3) reportar e armazenar o status do processamento e da implementao das mudanas nos itens, e (4) verificar a conformidade com os requisitos. Quando falamos em gerncia de configurao, no podemos esquecer trs termos visivelmente ligados a esta rea: Item de configurao (IC): cada um dos elementos de informao que so criados durante o desenvolvimento de um produto de software, ou que para este desenvolvimento sejam necessrios, que so identificados de maneira nica e cuja evoluo passvel de rastreamento [Pressman-01]. Baseline: o conjunto de itens de configurao estveis (revisados e aprovados formalmente) e que serve de base para a execuo de atividades futuras dentro do projeto. Change Control Board (CCB): um comit responsvel por analisar e aprovar as solicitaes de mudana submetidas ao projeto e as solicitaes de criao e liberao de baselines. Em um projeto podem existir vrios CCBs, responsveis por analisar e aprovar determinados tipos de solicitaes.
Para uma fbrica de software, a disciplina de gerncia de configurao extremamente importante tanto para a gesto dos projetos da empresa, como para os desenvolvedores. Do ponto de vista de gesto, a disciplina de gerncia de configurao surge como um apoio ao planejamento do projeto, atravs da identificao de todos os itens de configurao do projeto, que devero ter sua criao e sua evoluo controladas. Do ponto de vista dos desenvolvedores, a existncia de um controle efetivo sobre o trabalho produzido por eles, permitindo a consulta do histrico da evoluo dos itens gerados, e a facilidade de acesso a qualquer verso do item de configurao. O CMMI trata a gerncia de configurao como uma rea de processo de suporte, pois seu objetivo estabelecer e manter a integridade dos produtos de trabalhos gerados pelas reas de processo de gerenciamento de projetos e engenharia. Esta rea de processo envolve trs metas especificas: Estabelecimento de baselines, para garantir um conjunto de itens de configurao estveis o suficiente para servirem como base para o trabalho da equipe do projeto.
38
Controle e rastreamento de mudanas, atravs do registro e anlise das solicitaes de mudana para um projeto, e o acompanhamento de sua resoluo.
Estabelecimento de integridade das baselines, onde, atravs das auditorias de configurao, seja possvel monitorar as baselines estabelecidas e evitar que elas sejam violadas e tornem-se inconsistentes com o planejamento feito para o projeto.
As prximas subsees detalham o propsito das metas especficas supracitadas, fazendo aluso realidade das fbricas de software.
4.1. Prticas especficas
4.1.1. SP1.1 Identificar itens de configurao Os itens de configurao de um projeto devem ser identificados para que seja possvel planejar adequadamente as baselines do projeto. Cada item de configurao representa um artefato do projeto, que dever ter sua evoluo controlada. Os itens de configurao devem ser identificados unicamente, e terem suas caractersticas definidas e responsveis atribudos. Esta prtica especifica aborda tambm a necessidade de, durante a identificao dos itens de configurao, levantar o momento em que cada item colocado sob a gerncia de configurao, pois cada item possui um momento adequado para entrar na baseline do projeto, passando a ser controlado formalmente a partir desse momento. No contexto de fbricas orientadas a produto, existe uma linha tnue entre o conceito de item de configurao de um produto e item de configurao de um projeto. Em um projeto, existem artefatos que precisam ser controlados formalmente durante a sua execuo, como os documentos de requisitos, onde esto especificadas as funcionalidades. Porm, ao trmino do projeto, ou aps a entrega de uma verso do produto que atenda parcialmente ao projeto, as funcionalidades incorporadas na verso deixam de pertencer ao projeto e passam ao produto. Por isso, difcil discernir quando um item de configurao pertence ao projeto ou ao produto. 4.1.2. SP1.2 Estabelecer o sistema de configurao Esta prtica especfica aborda a preparao e ajuste da infra-estrutura necessria para a realizao das atividades de gerncia de configurao. Isso engloba:
39
Repositrio: sistema necessrio para armazenar a recuperar facilmente os itens de configurao e suas verses, com a definio clara de controle de acesso aos itens.
Sistema de controle de mudanas: atravs do qual possvel registrar a acompanhar tas mudanas solicitadas durante o projeto.
A utilizao de repositrios em uma fbrica orientada a produtos um ponto crtico, pois como as linhas de novos desenvolvimentos (projetos) e manuteno dos produtos acontecem geralmente em paralelo, pode haver conflito dentro da equipe para a realizao de mudanas em um mesmo item de configurao, de modo que as mudanas aconteam sem desfazer mudanas anteriores. Alm disso, pode ser necessrio fazer correes em uma verso j entregue ao cliente, mas que j est sendo evoluda com novas demandas de clientes. Por isso, os repositrios passam a ter um papel fundamental no controle das verses dos produtos, em funo do controle de seus itens de configurao, para viabilizar a flexibilidade requerida pela organizao. Quando falamos em sistema de controle de mudanas, importante ressaltar que para o CMMI a visibilidade das mudanas nos itens de configurao imprescindvel, ou seja, deve existir uma sistemtica dentro da organizao que possibilite acompanhar cada passo das mudanas requeridas em um item de configurao, alm da formalizao da anlise de impacto de uma solicitao de mudana ou registro de erros no sistema. 4.1.3. SP1.3 Criar e liberar baselines A criao das baselines de um projeto est diretamente relacionada ao planejamento do projeto. durante esta fase que realizado tambm o planejamento da gerncia de configurao, pois os itens de configurao so extrados a partir dos produtos de trabalho identificados durante o planejamento do projeto, e a composio da baseline feita de acordo com os itens levantados. Existem diversas estratgias de composio de baseline: Baseline de planejamento: contm todos os artefatos produzidos pela etapa, como os planos de projeto, gerncia de configurao e garantia da qualidade. Baseline de requisitos: contempla todos os requisitos funcionais, casos de uso e demas documentos vinculados s funcionalidades demandadas pelo projeto.
40
Baseline de cdigo: contempla todo o cdigo-fonte produzido para o projeto, que atenda a uma determinada baseline de requisitos, para manter a rastreabilidade.
A deciso de qual estratgia de criao de baselines varia de acordo com a organizao, sendo que, independente da estratgia, deve haver uma formalizao para a criao das baselines, onde o CCB dever aprovar os artefatos que estaro na baseline, j que ela servir como base para o desenvolvimento futuro dentro do projeto. A liberao da baseline funciona como a entrega do cdigo-fonte e gerao dos executveis para o projeto, e pode ser realizada para homologaes internas (build) ou para entrega ao cliente final (release). A liberao da baseline deve seguir os mesmos passos da criao, obtendo aprovao do CCB, e marca o cumprimento de um conjunto de atividades planejadas para o projeto, geralmente associadas a marcos definidos durante o planejamento. Para as fbricas orientadas a produto, a criao e liberao de baselines uma tarefa complexa, pois, partindo do prprio conceito de baseline, algumas questes podem ser levantadas: Como discernir entre uma baseline de projeto e de produto? Como manter o relacionamento entre a baseline de um projeto e a do produto? Como manter a consistncia entre baselines?
Essas so perguntas de difcil resposta quando o contexto da organizao possibilita a execuo de vrios projetos em paralelo evoluindo ou corrigindo o mesmo produto. 4.1.4. SP2.1 Rastrear solicitaes de mudana Durante a execuo das atividades de um projeto surgem solicitaes de mudana tambm conhecidas como Change Request (CR), em requisitos j implementados e entregues ao cliente, ou a reportagem de erros detectados durante testes ou utilizao do software gerado para o projeto. Essas atividades so muito comuns aos projetos e podem demandar alteraes em diversos artefatos do projeto, no apenas no cdigo-fonte do mesmo. Por isso, o CMMI definiu esta prtica especfica para alertar a necessidade de formalizar todos os procedimentos vinculados a uma CR, que podem ser divididos nos grupos abaixo: Registro da CR: devem ser registradas todas as informaes necessrias para uma anlise completa da solicitao. Isso pode ser feito atravs de documentos formatados
41
pela organizao, ou atravs da utilizao de sistemas de controle de mudanas, que automatizam esta prtica especfica, e facilitam a rastreabilidade das solicitaes de mudana dentro do projeto. Anlise da solicitao registrada: cada CR deve ser analisada pelo CCB responsvel para que sejam identificadas as alteraes necessrias para atender a CR registrada. Neste momento, a matriz de rastreabilidade do projeto pode ser consultada, para que seja possvel analisar o impacto da solicitao. As decises do CCB devem ser registradas, para que seja possvel rastre-las posteriormente. Alterao nos artefatos necessrios: a partir da analise realizada, os artefatos identificados devem ser alterados para atender CR. Quando alterados itens de configurao que pertencem a uma baseline, deve-se realizar todos os procedimentos vinculados SP1.3. Verificao das alteraes: todas as atividades vinculadas CR devem ser verificadas, seja a aprovao de um artefato modificado, seja o teste de um cdigo-fonte corrigido. Fechamento do registro da solicitao: uma vez realizadas as verificaes, o registro de CR considerado fechado, ou seja, atendido pela organizao. 4.1.5. SP2.2 Controlar itens de configurao Como visto na subseo anterior, durante uma solicitao de mudana os itens de configurao de um projeto podem ser modificados para atender CR registrada. necessrio ter o controle de todas as alteraes feitas nos itens de configurao, para que seja possvel rastre-las a qualquer momento durante e aps o projeto. Estas atividades envolvem o registro do histrico de alteraes do item, contendo o responsvel, a data e o contedo da alterao, que podem ser feitos atravs da utilizao do repositrio, onde possvel identificar e recuperar facilmente os itens de configurao e todas as suas verses, e, para os documentos, atravs do registro do histrico dentro do prprio documento. 4.1.6. SP3.1 Estabelecer registros da gerncia de configurao Esta prtica especfica levanta a necessidade de documentao das atividades vinculadas gerncia de configurao, de forma que seja possvel: Acessar facilmente as caractersticas e o status dos itens de configurao do projeto.
42
Identificar se o controle de acesso aos itens de configurao est adequado Identificar o contedo das baselines do projeto Identificar diferenas entre baselines Acessar o histrico de mudanas de cada item de configurao.
importante ressaltar que esta prtica especfica permeia toda a rea de processo da Gerncia de Configurao, visto que os registros supracitados esto evidenciados nas prticas especficas do processo. Em uma fbrica orientada a produto, fica evidenciada a necessidade desta prtica especfica, pois a demanda de novos projetos em paralelo com as manutenes evolutivas e corretivas do produto geram uma complexidade alta na gesto dos itens de configurao dentro da fbrica, necessitando de uma documentao clara em torno destes itens e das baselines geradas, alm das verses dos produtos liberadas para os clientes da fbrica, de modo que seja possvel rastrear as funcionalidades entregues pela fbrica com as baselines e verses dos itens de configurao do produto. 4.1.7. SP3.2 Realizar auditorias de configurao Esta prtica especfica identifica a necessidade de realizao de auditorias peridicas no sistema de configurao da empresa, como forma de garantir a execuo correta das atividades de gerncia de configurao, assim como a integridade do ambiente de configurao montado na organizao. Podemos citar como itens de uma auditoria: Anlise da integridade das baselines estabelecidas Anlise dos padres definidos para uso no projeto Anlise da integridade dos itens de configurao
4.2. Prticas genricas
Como visto no captulo 3, as prticas genricas representam as atividades necessrias para se atender s metas de institucionalizao de uma rea de processo. No mbito da Gerncia de Configurao, a meta genrica associada ao nvel 2 de maturidade possui o seguinte objetivo: garantir que o processo est institucionalizado e gerenciado, ou seja, existe
43
uma poltica da empresa que define os princpios de execuo do processo, existe um plano vinculado ao processo de gerncia de configurao, os recursos foram treinados e executam as atividades do processo conforme previsto, a performance do processo est sendo medida e controlada. Nas prximas subsees estaremos detalhando estes aspectos de institucionalizao direcionados para a gerncia de configurao, analisando criticamente os pontos relacionados s fbricas orientadas a produto. 4.2.1. GP2.1 Estabelecer uma poltica organizacional Segundo [Chrissis-03], o propsito desta prtica genrica definir as expectativas da organizao em relao ao cumprimento das atividades do processo e torn-las claras e visveis a todos os que as executaro dentro da organizao. E isto feito atravs da definio de polticas que guiem os membros da empresa em relao s atividades do processo. Em relao gerncia de configurao, importante a definio de polticas claras sobre a execuo das atividades de planejamento da configurao dos projetos, sobre o controle de mudanas e acompanhamento das atividades de gerncia de configurao. importante a elaborao de guias e normas para orientar todos os membros da empresa sobre o processo a ser executado. Vale a pena ressaltar que esta prtica exige muito da gerncia snior da empresa, ou seja, as pessoas que acreditam na execuo do processo, nos benefcios trazidos por ele, e, acima de tudo, nos custos necessrios para se atingir o sucesso com o processo definido. 4.2.2. GP2.2 Planejar o processo O planejamento do processo compreende o levantamento e a manuteno de todas as atividades necessrias para se executar o processo proposto: necessrio identificar e documentar o planejamento do processo, e modific-lo quando necessrio, medida que as atividades so executadas no projeto [Chrissis-03]. Para a Gerncia de Configurao, o planejamento est associado ao prprio processo que implementa a rea de processo, como tambm elaborao do plano de gerncia de configurao, que pode estar sob a forma de um plano isolado ou fazer parte do plano de um projeto. No entanto, no planejamento das atividades de configurao que devem constar toda a infra-estrutura necessria para garantir a boa execuo o processo proposto.
44
4.2.3. GP2.3 Prover recursos Como o prprio nome da prtica sugere, seu objetivo garantir que todos os recursos necessrios execuo do processo (que foram identificados e documentados no plano de gerncia de configurao) estejam disponveis. Ferramentas, softwares, pessoas, hardware, tudo isto se configura como recurso imprescindvel para a execuo das atividades de gerncia de configurao. Quando atividades do processo deixam de ser executadas por questes de disponibilidade de mquinas ou softwares, ou por causa de alocao insuficiente de pessoas ao processo, esta prtica genrica deixa de ser atendida, pois isto indica a falta do comprometimento da gerncia snior em garantir a infra-estrutura necessria para o cumprimento do processo. 4.2.4. GP2.4 Atribuir responsabilidades Esta prtica genrica possui o objetivo de garantir que os papis e responsabilidades definidos para o processo de gerncia de configurao e implementados no planejamento estejam bem definidos e de claro conhecimento dentro da organizao, para que todos saibam as suas atribuies dentro da execuo do processo, para que atividades no deixem de ser executadas por falta de entendimento dos papis e responsabilidades de cada um no processo. 4.2.5. GP2.5 Treinar pessoas Associada prtica genrica GP2.4, da subseo anterior, os treinamentos planejados para a institucionalizao do processo de gerncia de configurao visam garantir no apenas o entendimento claro dos papis e responsabilidades de cada membro da organizao no processo, objetivo da GP2.4, como tambm disseminar o conhecimento da execuo diria das atividades de Gerncia de Configurao. Os treinamentos variam desde os ensinamentos sobre o processo criado at os treinamentos nas ferramentas de repositrio e controle de mudanas, que sero usadas diariamente pela equipe de desenvolvimento. 4.2.6. GP2.6 Gerenciar Configurao Esta prtica genrica se confunde bastante com o prprio processo de gerncia de configurao, pois seu objetivo manter sobre gerncia de configurao os produtos de trabalho gerados pelo processo.
45
4.2.7. GP2.7 Identificar e envolver os stakeholders relevantes Segundo [SEI029-02], entende-se por stakeholder um grupo ou indivduo que afetado direta ou indiretamente pelos resultados de uma iniciativa. E stakeholder relevante considerado um subconjunto dos stakeholders e que constam no planejamento de execuo do processo. No processo de gerncia de configurao, importante que todos os stakeholders previstos no plano estejam atribudos a pessoas da organizao (ou fora dela), e que suas participaes estejam sendo realizadas conforme o previsto. 4.2.8. GP2.8 Monitorar e controlar o processo Esta prtica genrica se refere ao acompanhamento dirio da execuo do processo, para garantir que as atividades estejam sendo executadas como o planejado, e, em caso negativo, as aes necessrias para corrigir os problemas sejam tomadas. atravs desta prtica genrica que se deve medir a performance do processo, sendo feita geralmente atravs da coleta e anlise de mtricas definida no planejamento do processo. Para a gerncia de configurao, devem ser definidos alguns indicadores de desempenho do processo, como atividades planejadas e realizadas da gerncia de configurao, backlogs de auditorias de configurao, entre outras. 4.2.9. GP2.9 Avaliar aderncia objetivamente Quando se trata de avaliar a aderncia de um processo em uma organizao, tem-se como objetivo determinar se o processo est funcionando corretamente na organizao baseado em padres e normas definidos previamente com o processo, ou seja, sem depender da subjetividade de quem est avaliando. Por isso, importante que o avaliador da aderncia do processo organizao seja algum externo execuo das atividades do processo em avaliao. Geralmente, esta tarefa est entre as atribuies do engenheiro de qualidade da empresa, quando ela o possuir. Independente disso, o mais importante identificar os pontos positivos e os desvios da execuo do processo na organizao, para que aes corretivas sejam tomadas e que o processo possa ser executado novamente sem os desvios encontrados. 4.2.10. GP2.10 Revisar status com gerncia snior Nesta prtica, o objetivo revisar o status da gerncia de configurao da empresa com a gerncia snior vinculada ao processo. durante esta atividade que so avaliadas as mtricas do processo, discutida a efetividade do processo na organizao e quais as aes a serem tomadas em casos de desvios do processo identificados pela GP2.9 e pelas auditorias
46
do gerente de configurao (SP3.2). Como a gerncia snior tem o poder de garantir recursos para a execuo adequada do processo, atravs dessas reunies que so renovados os compromissos para a continuidade da institucionalizao do processo na organizao.
Este captulo apresentou uma anlise crtica da rea de processo de Gerncia de Configurao do nvel 2 de maturidade do CMMI sob a tica das fbricas de software orientadas a produto. Foram identificados diversos pontos problemticos associados a esta rea, para que sejam posteriormente discutidas oportunidades de melhorias dentro da fbrica. importante observar cuidadosamente que a rea de gerncia de configurao considerada uma rea de suporte do CMMI, ou seja, ela est integrada s demais reas para garantir a o desenvolvimento e a manuteno das demais atividades geradas pelas reas de processo do CMMI, tornando-se um fator-chave para o sucesso da institucionalizao dos processos do nvel 2 de maturidade em fbricas de software. importante ressaltar tambm que a empresa deve se preocupar em definir um processo de gerncia de configurao que reflita primeiramente o contexto real da organizao e depois o nvel de maturidade ou capacidade do CMMI, para que este processo se torne exeqvel, e realmente traga benefcios organizao.
47
Captulo 5 - Proposta do Processo de Gerncia de Configurao
Captulo 5. Proposta do Processo de
Gerncia de Configurao
Neste captulo apresentada uma proposta de customizao do processo de Gerncia de Configurao do nvel 2 do CMMI para as fbricas de software orientadas a produto, com o foco na melhoria de gesto de projetos, requisitos e configurao, que so reas crticas nestas organizaes.
48
A partir da avaliao crtica da rea de processo de Gerncia de Configurao realizada no captulo 5, este captulo apresenta um processo de Gerncia de Configurao para as fbricas de software orientadas a produto, com o objetivo de sanar os problemas identificados durante o captulo anterior e oferecendo uma alternativa de gesto de configurao para este cenrio de fbricas de software, onde muito complexo o gerenciamento de tantas demandas paralelas e a manuteno da integridade do produto, bem maior da organizao.
5.1. Apresentao do contexto
O processo de gerncia de configurao proposto baseou-se na experincia da autora na definio e implantao de processos alinhados ao nvel 2 de maturidade do CMMI em uma fbrica de software orientada a produto durante o perodo entre 2004 e 2006. importante lembrar que o processo pode ser aplicado em fbricas de software independente de elas serem parte da organizao ou serem a prpria organizao, como explicado no captulo 2. Porm, o contexto da fbrica vai determinar o nvel das responsabilidades no processo, o que ser abordado durante a explicao detalhada do processo proposto.
5.2. Estrutura do processo
A estrutura do processo proposto est alinhada ao nvel 2 de capacidade e baseia-se nas definies usadas pela rea de processo de Definio de Processos Organizacionais (OPD), descrita em detalhes no modelo CMMI [Chrissis-03]. So elementos do processo: objetivos, papis e responsabilidades, entradas, sadas, subprocessos, treinamentos e mtricas. Cada subprocesso possui os seguintes atributos: objetivos, aes, entradas, sadas e papis envolvidos. 5.2.1. Representao grfica Para facilitar a visualizao do processo e seus subprocessos, foram definidos diagramas que usam a notao definida na Tabela 5-1.
49
Smbolo
Descrio Subprocesso ou atividade executada obrigatoriamente durante a gerncia de configurao
Subprocesso ou atividade executada opcionalmente durante a gerncia de configurao. Ator (papel ou setor) responsvel por realizar uma atividade.
Ator (papel ou setor) que pode auxiliar o ator responsvel na realizao de uma atividade. Indica a seqncia de realizao entre duas atividades. Quando a seta no indicada, significa que no existe uma seqncia obrigatria para realizao das atividades.
Tabela 5-1 Representao grfica do processo
5.3. Descrio do processo
O processo proposto de Gerncia de Configurao composto de 5 subprocessos, conforme apresentado na figura 6-1.
Figura 5-1 Viso grfica do processo proposto de gerncia de configurao
O subprocesso Planejar Gerncia de Configurao engloba todas as atividades necessrias para realizar o planejamento da gesto da configurao dentro da fbrica, valendo
50
tanto para os projetos de novos desenvolvimentos como para a manuteno do produto. O subprocesso Estabelecer Baselines trata das atividades necessrias para a criao e atualizao das baselines dos projetos e do produto. O subprocesso Liberar Verses/Patches aborda as atividades necessrias para liberao de um release do produto, tanto sob a forma de uma verso completa, como atravs dos patches, que contemplam correes de uma verso completa liberada anteriormente. J o subprocesso Controlar Mudanas aborda atividades ligadas gesto de mudanas para o produto, mostrando os passos necessrios para obter o controle dos impactos causados por uma solicitao de mudana demandada fbrica. Por fim, o subprocesso Acompanhar Gerncia de Configurao aborda as atividades de acompanhamento de status e realizao de auditorias de configurao, necessrias para a manuteno das atividades da fbrica em consonncia com o processo proposto. 5.3.1. Papis e responsabilidades no processo Esta seo detalha os papis apresentados na Figura 5-1, com as suas responsabilidades no processo proposto de Gerncia de Configurao. So eles: Papel Gerente de Configurao Responsabilidade Controlar as baselines dos produtos Gerar as verses do produto que contemplem demandas de projetos e de solicitaes de mudana. Realizar auditorias para garantir o cumprimento das atividades de CM pela equipe de trabalho. Gerente de Produto Solicitar estabelecimento de baselines Participar do CCB, tendo poder de aprovao nas solicitaes de mudana que no impactam custo, prazo e outros compromissos externos. Gerente de Projeto Participar do CCB nas decises de solicitaes de mudanas de requisitos que impactam custos, prazos e outros compromissos externos (com o cliente final) Relator Reportar solicitaes de mudana (erros ou melhorias) para a fbrica analisar e executar as atividades relacionadas solicitao, quando aprovada.
51
Papel Gerncia Snior
Responsabilidade Analisar os relatrios de status da Gerncia de Configurao e tomar aes para resoluo de possveis conflitos encontrados.
Analista Lder
Liderar equipe de desenvolvimento vinculada a projetos, respondendo ao gerente de produto e ao gerente do projeto vinculado equipe quanto ao andamento das atividades da equipe dentro da fbrica
Equipe de desenvolvimento
Realizar suas atividades que envolvem gerncia de configurao, cumprindo as definies do processo de CM.
Tabela 5-2 Papis e responsabilidades do processo proposto
5.3.2. Subprocesso 1: Planejar Gerncia de Configurao O objetivo deste subprocesso englobar todas as atividades de elaborao do planejamento das atividades de gerncia de configurao da fbrica de software, tanto para o produto em si como para os projetos que esto vinculados ao produto. durante o planejamento que os itens de configurao do produto e dos projetos so identificados e as atividades de trabalho das equipes vinculadas gerncia de configurao so definidas. importante ressaltar que a maioria das informaes do planejamento, para uma fbrica de software orientada a produto, perene, estando relacionada ao produto, tendo apenas algumas particularidades variando por projeto. Sendo assim, o maior trabalho de planejamento identificar, em um primeiro momento, todos os elementos de configurao nicos para o produto um trabalho que exige esforo e dedicao do gerente de configurao e do gerente do produto. A Tabela 5-3 apresenta um resumo deste subprocesso.
52
Objetivos Planejar a gerncia de configurao para o projeto, ajustando ou criando os Planos de Gerncia de Configurao do Produto e do Projeto para as demandas geradas para o projeto. Aes Selecionar os itens de configurao Definir o CCB do projeto Planejar baselines Configurar ferramentas de gerncia de configurao Conciliar os Planos de Gerncia de Configurao Sadas Itens de configurao selecionados para o projeto Plano de Gerncia de Configurao do Produto elaborado/atualizado Plano de Gerncia de Configurao do Projeto elaborado/atualizado. Papis Envolvidos Gerente de Configurao, Analista Lder, Gerente de Produto, Gerente de Projeto
Tabela 5-3 Resumo do subprocesso 1: Planejar Gerncia de Configurao
Entradas Plano de Projeto Plano de Produto
Plano de Gerncia de Configurao do Produto aprovado (se existir)
A Figura 5-2 apresenta a viso grfica deste subprocesso.
53
Figura 5-2 Viso grfica do subprocesso 1: Planejar Gerncia de Configurao
5.3.2.1. Atividade: Selecionar os itens de configurao A seleo dos itens de configurao do projeto deve complementar os itens de configurao do produto. Estes itens devem ser identificados antes mesmo de se iniciar um projeto, pois eles sero usados como base para os projetos a serem executados dentro da fbrica de software. Podem ser considerados itens de configurao de um produto: Cdigo-fonte; Arquivos de configurao; Documento funcional do produto; Documento tcnico do produto; Manual do usurio
Os itens de configurao do produto devem estar descritos no Plano de Gerncia de Configurao do Produto (a ser explicado com mais detalhes na seo 5.3.2.4), que dever ser alterado apenas quando algum aspecto da configurao do produto for modificado. Segundo [SEI029-02], os itens de configurao de um projeto devem ser identificados com base em critrios objetivos, ou seja, que no estejam vinculados interpretao de quem est escolhendo os itens de configurao. A Tabela 5-4 apresenta algumas sugestes de critrios.
54
Critrio Artefatos compartilhados
Detalhamento entre Um projeto pode estar demandando alteraes em funcionalidades do produto que vo impactar outros projetos em execuo. As alteraes nestes projetos precisam ser controladas para no
equipes de projetos diferentes
impactarem negativamente outros projetos. Artefatos de alta criticidade para a Existem artefatos vinculados ao produto que devem equipe do projeto estar sempre consistentes e atualizados para que as equipes que os utilizam no trabalhem sob uma verso errada do artefato.
Tabela 5-4 Sugestes de critrios de seleo de itens de configurao
Baseando-se nestes critrios, podem ser considerados itens de configurao: Documento de requisitos Documento de casos de uso (quando utilizado pela organizao) Modelos de dados Cdigo-fonte
Cada item de configurao deve possuir as seguintes informaes a seu respeito: Identificao nica Tipo do arquivo do item (texto, binrio, entre outros)
Os itens de configurao do projeto devem estar documentados no plano do projeto, para facilitar tanto a aprovao do planejamento como o acompanhamento das atividades de gerncia de configurao. A empresa pode, se desejar, criar um plano de gerncia de configurao parte, e referenci-lo no plano de projeto. importante ressaltar a necessidade de se ter o plano de gerncia de configurao do produto e do projeto: Os itens de configurao do produto so itens de configurao de cada projeto, visto que na estrutura de uma fbrica de software orientada a produto os projetos modificam
55
um mesmo produto, e, portanto, dependem dos artefatos vinculados ao produto para serem executados com sucesso. Dentro de uma organizao, mesmo possuindo equipes trabalhando em projetos distintos, todos precisam ter conhecimento do sistema de configurao vinculado ao produto. Concentrando estas informaes em um s lugar, a empresa viabiliza o acesso centralizado ao sistema de configurao do produto, deixando para o projeto apenas as suas especificidades.
Como dito anteriormente, os itens de configurao de um produto e dos projetos devem ser identificados unicamente, para facilitar o seu acesso e referncia. A identificao destes itens pode se basear em um padro de nomenclaturas de itens definidos pela prpria empresa. Este padro guiar todas as atividades do projeto, e deve estar documentado no plano de gerncia de configurao, ou no plano de projeto. 5.3.2.2. Atividade: Definir o CCB do projeto Como visto no capitulo 4, o papel do CCB dentro de uma empresa muito crtico, pois ele o responsvel por analisar as solicitaes de mudana no produto demandadas pelos clientes internos e/ou externos. No contexto de uma fbrica orientada a produto, o CCB deve ser composto minimamente pelo Gerente de Produto e pelos analistas responsveis de cada equipe de projeto, podendo ser o Gerente do Projeto ou um analista da equipe. O importante que a equipe formada seja capaz de avaliar as solicitaes de mudana, observando os impactos na configurao do produto (ou seja, nos itens de configurao do produto) e do projeto, cabendo ao CCB aprov-las ou no. Um ponto importante que no precisa ser formado um novo CCB a cada projeto. A empresa pode manter um CCB nico para o produto, e todos os projetos deste produto passam a contar com este grupo para a avaliao de impacto das solicitaes de mudana. 5.3.2.3. Atividade: Planejar baselines Uma baseline representa um conjunto de itens de configurao estveis, ou seja, itens que possam ser utilizados como referncia pela equipe para um trabalho posterior. Durante o planejamento de uma baseline, importante definir quais os itens de configurao que faro parte dela. Cada item possui um momento adequado de entrar na baseline. A Tabela 5-5 apresenta sugestes de critrios para entrada de itens de configurao em uma baseline.
56
Item de Configurao Documento de requisitos
Momento de entrada na baseline Aps aprovao pelo cliente Aps reviso da equipe de desenvolvimento Aps reviso da equipe quanto consistncia com o documento de requisitos
Documento de casos de uso
Cdigo-fonte
Aps testes integrados Aps certificao Aps reviso da equipe quanto consistncia com o documento de requisitos e casos de uso.
Modelo de dados
Tabela 5-5 Exemplo de critrios para entrada de um item de configurao na baseline
Nas fbricas de software orientadas a produto, as baselines devem estar alinhadas verso do produto a ser liberada para o cliente (interno ou externo). Isso ocorre porque cada projeto, mesmo possuindo suas funcionalidades consideradas especficas para o cliente contratante, est evoluindo um produto nico, de modo que estas funcionalidades precisam co-existir, sem prejudicar nem o conceito de produto nem o projeto demandador de cada funcionalidade. Alm disso, existem as demandas de correo de erros que so enviadas empresa, e que precisam ser realizadas simultaneamente com a evoluo do produto. Por isso, o planejamento da verso do produto o momento mais adequado para que sejam definidas as funcionalidades de cada projeto e as correes e melhorias que sero disponibilizadas ao cliente em um determinado perodo de tempo. A partir de um escopo bem definido, possvel identificar quais os itens de configurao que sero impactados pela verso e quando cada um deles entrar na baseline. Existem diversos tipos de baselines a serem estabelecidas pela fbrica. A Tabela 5-6 apresenta alguns tipos de baselines que podem ser adotadas durante o processo.
57
Tipo de Baseline Baseline de Planejamento
Objetivo Contempla os artefatos do planejamento de cada projeto dentro da fbrica. Pode ser criada uma baseline de
planejamento por projeto ou uma baseline de planejamento em torno do escopo da verso. Baseline de Requisitos Contempla os artefatos vinculados gesto de requisitos, como documentos de
requisitos, casos de usos e afins. Deve estar vinculada baseline de
planejamento da verso. Baseline de Cdigo Contempla todo o cdigo-fonte e parmetros do produto que atendem baseline de planejamento da verso e baseline de requisitos
Tabela 5-6 Exemplos de Tipos de Baselines
O planejamento das baselines deve ser feito em conjunto pelo Gerente do Produto e Gerente de Configurao, alinhados aos objetivos de cada Gerente de Projetos vinculados ao produto. O planejamento deve estar registrado no plano de Gerncia de Configurao ou no Plano de Projeto. 5.3.2.4. Atividade: Configurar ferramentas de Gerncia de Configurao O Gerente de Configurao deve criar (quando no existir) e configurar a infraestrutura necessria para a correta utilizao dos itens de configurao pela equipe. Devem ser consideradas a configurao e disponibilizao do repositrio de configurao e da ferramenta, bem como dos mecanismos de controle de mudanas a serem usados pela equipe. A configurao do repositrio para os itens de configurao do projeto e do produto deve ser realizada com cuidado, definindo-se claramente a localizao e as permisses de acesso de cada item. Esta atividade compreende:
58
Criao da estrutura de diretrios Criao de contas dos usurios Definio de permisses de cada usurio
O Gerente de Configurao deve definir os procedimentos de utilizao do repositrio para posterior treinamento da equipe. Alm disso, ele deve se preocupar em planejar o backup do repositrio, visto que o repositrio ser o local onde estaro armazenados os itens de configurao e o objeto de trabalho do Gerente de Configurao. Caso a empresa j possua uma poltica organizacional de backup, cabe ao Gerente de Configurao a passagem das informaes para incluso na rotina de backup, e verificao da realizao do mesmo. Alm do repositrio, o Gerente de Configurao deve configurar a ferramenta de controle de mudanas. Assim como na configurao do repositrio, devem ser criadas as contas dos usurios e seus nveis de acesso. Deve ser definido tambm o fluxo de transio de estados de uma solicitao de mudana e seu mapeamento para a ferramenta de controle de mudanas. Este fluxo ser usado no suprocesso 2, a ser visto mas adiante. importante ressaltar que o fluxo de transio de estados deve ser o mesmo para projetos e para as demandas do produto, pois cria uma cultura nica de trabalho dentro da organizao independente do foco da equipe no momento. Por isso, todas as informaes sobre a ferramenta de controle de mudanas e o fluxo de transies devem estar documentadas no Plano de Gerncia de Configurao do Produto. 5.3.2.5. Atividade: Conciliar os Planos de Gerncia de Configurao Nesta atividade, deve ser feita uma reviso das informaes sobre gerncia de configurao em relao ao planejamento dos projetos e do produto. Devem participar desta atividade, alm do Gerente de Configurao, o Gerente do Produto e os Gerentes de Projetos envolvidos. Deve ser feita a conciliao dos planos, para que sejam verificadas e corrigidas inconsistncias entre eles. Alguns pontos a serem verificados: Alinhamento do planejamento das baselines ao cronograma de liberao das verses do produto e aos cronogramas de cada projeto Informaes sobre os itens de configurao do produto e a estrutura do repositrio, concentradas no plano de produto
59
Informaes especficas de cada projeto documentadas no Plano do Projeto ou em um Plano de Gerncia de Configurao especfico do projeto.
Uma vez conciliados, os planos devem ser divulgados a cada equipe, pois eles sero usados como referncia pela equipe no dia-a-dia. Esta divulgao deve ser feita atravs de uma reunio para que sejam apresentados os planos e esclarecidas as dvidas da equipe. Caso haja alguma divergncia, deve-se voltar ao incio deste subprocesso para que seja corrigida a inconsistncia detectada. 5.3.3. Subprocesso 2: Estabelecer Baselines Este subprocesso apresenta as atividades relacionadas ao estabelecimento e manuteno das baselines planejadas no subprocesso 1. Para as fbricas de software orientadas a produto, as baselines podem estar orientadas verso do produto, visto que ela o resultado do trabalho das equipes que trabalham na fbrica, independente do projeto no qual elas esto alocadas. Por isso, importante definir claramente os passos e critrios para entrada dos itens de configurao em uma baseline, para evitar a inconsistncia entre as baselines programadas e os itens de configurao previstos em cada uma delas. A Tabela 5-7 apresenta um resumo deste subprocesso.
Objetivos Acompanhar as baselines planejadas, atravs do estabelecimento das baselines para uso interno. Aes Solicitar o estabelecimento de baseline Avaliar solicitao Executar atividades de estabelecimento de baseline Sadas Baseline estabelecida Membros das equipes dos projetos
Entradas Plano de Projeto Plano de Produto Plano de Gerncia de Configurao do Produto aprovado Plano de Gerncia de Configurao dos
notificados do estabelecimento baseline. Build do produto gerado e disponibilizado (quando aplicvel)
60
projetos (se as informaes no estiverem no plano de projeto) Itens de configurao estveis (conforme explicado no captulo 4) Papis Envolvidos Gerente de Configurao, Analista Lder, Gerente de Produto, Gerente de Projeto
Tabela 5-7 Resumo do subprocesso 2: Estabelecer Baselines
Figura 5-3 Viso grfica do subprocesso 2: Estabelecer Baseline
5.3.3.1. Atividade: Solicitar o estabelecimento de baseline A solicitao de estabelecimento da baseline pode variar de acordo com os tipos de baselines planejados pela fbrica, conforme apresentado na Tabela 5-6 da seo 5.3.2.3. A Tabela 5-8 apresenta a relao de possveis solicitantes para cada baseline citada anteriormente. Tipo de Baseline Baseline de Planejamento Possveis Solicitantes Gerente de Projeto ou Analista Lder (quando a baseline variar por projeto) Gerente de Produto (quando a baseline estiver vinculada verso do produto) Baseline de Requisitos Baseline de Cdigo Analista Lder Analista Lder
61
Tabela 5-8 Solicitantes de estabelecimento de baseline x tipo de baseline
A solicitao de estabelecimento de baseline pode ser feita atravs de e-mail ou do uso de uma ferramenta de controle de mudanas. No registro da solicitao, devem ser informados quais os itens de configurao que esto sendo enviados para a baseline com suas respectivas verses e projetos, de acordo com o planejamento feito no subprocesso 1. Desta forma, possvel avaliar quem est demandando o maior nmero de baselines, projetos de novas funcionalidades ou manutenes do produto. 5.3.3.2. Atividade: Avaliar solicitao O Gerente de Configurao deve avaliar se a solicitao de estabelecimento da baseline pode ser atendida ou no. Para isso, ele deve fazer uma auditoria de estabelecimento de baseline para garantir a sua integridade (vide ANEXO A - Checklist de Auditoria de Estabelecimento de Baseline). Para cada tipo de baseline a ser estabelecida, sugere-se escolher um subconjunto dos itens do checklist para realizar a auditoria. As inconsistncias encontradas durante a checagem devem ser tratadas com o solicitante para resoluo. Ele dever delegar, aos reais responsveis pelos problemas detectados na auditoria, as atividades para corrigi-los. O Gerente de Configurao, por sua vez, dever refazer a auditoria para aferir se os problemas detectados foram realmente corrigidos ou no. O Gerente de Configurao dever manter este checklist armazenado no repositrio, para que seja possvel rastrear as atividades relacionadas ao estabelecimento da baseline. 5.3.3.3. Atividade: Executar atividades de estabelecimento de baseline O Gerente de Configurao deve criar a baseline solicitada, vinculando a ela todos os itens de configurao solicitados, com suas respectivas verses estveis. Ele deve identificar a baseline estabelecida, para que ela possa ser recuperada facilmente em outro momento. Assim como os itens de configurao, o padro de nomenclatura de uma baseline pode ser definido no prprio plano de gerncia de configurao. Durante o estabelecimento de uma baseline de cdigo-fonte, pode ser requisitada a gerao de uma build interno do produto, para fins de certificao ou testes integrados. O Gerente de Configurao deve, por sua vez, disponibilizar o build gerado em uma rea de acesso pela equipe de desenvolvimento.
62
Uma vez estabelecida a baseline, o Gerente de Configurao deve comunicar a todas as equipes interessadas que a baseline foi estabelecida, e, no caso de baselines de cdigo que demandaram gerao de builds, onde esta se encontra. 5.3.4. Subprocesso 3: Liberar verses ou patches A liberao de uma verso ou de um patch est vinculada ao estabelecimento prvio de uma baseline de cdigo para a verso a ser liberada. Este subprocesso prope as seguintes premissas para liberao de verses ou patches: A liberao de uma verso ou patch deve estar condicionada minimamente ao retorno dos testes de certificao do produto. Todas as implementaes contidas na verso a ser liberada devem ser testadas para que haja uma garantia mnima da qualidade do produto que est sendo entregue, ou seja, mesmo no havendo na fbrica uma estrutura formal de certificao de produtos, com planos e projetos de teste elaborados, preciso definir um conjunto mnimo de evidncias que garantam que o produto foi testado. Mais adiante, ser explicado com mais detalhes quais as evidncias de teste necessrias para atender s condies de liberao de uma verso ou patch. A liberao de uma verso ou patch do produto deve se basear em uma baseline estabelecida. Quando autorizada a liberao de uma verso ou patch, o cdigo-fonte que gerou os executveis, sendo um item de configurao, deve estar em uma baseline estabelecida previamente, ou seja, assim como as baselines esto vinculadas ao planejamento de escopo de uma verso ou patch, a liberao desta verso (ou patch) necessita do estabelecimento de uma baseline contendo os cdigos-fontes do produto. A Tabela 5-9 apresenta um resumo das atividades deste subprocesso.
63
Objetivos Liberar as verses e patches do produto. Aes Solicitar a liberao de verso ou patch. Avaliar solicitao Elaborar Release Notes da verso ou patch Executar atividades de liberao de verso ou patch Sadas Release Notes criado e armazenado no repositrio. Verso/patch liberada(o). Membros das equipes dos projetos
Entradas
Evidncias de testes na verso ou patch do produto. Baseline de cdigo estabelecida para a verso/patch testado.
notificados da liberao da verso ou patch. Baselines estabelecidas vinculadas
verso liberada. Papis Envolvidos Gerente de Configurao, Gerente de Produto, Gerente de Projeto
Tabela 5-9 Resumo do subprocesso 3: Liberar verses ou patches
64
Figura 5-4 Viso grfica do subprocesso 3: Liberar Verses ou Patches
5.3.4.1. Atividade: Solicitar liberao de verso ou patch O Gerente de Produto deve solicitar ao Gerente de Configurao a liberao de uma verso ou patch, informando qual a baseline associada liberao. Esta solicitao pode ser feita por e-mail ou atravs de uma ferramenta de controle de mudanas. Devem ser passadas as seguintes informaes: Identificao da baseline estabelecida para a verso ou patch a ser liberada(o). Relao dos testes realizados na baseline estabelecida para garantir a sua liberao.
5.3.4.2. Atividade: Avaliar solicitao O Gerente de Configurao deve realizar uma auditoria de liberao da verso ou patch para garantir a rastreabilidade e consistncia entre a verso ou patch que est sendo liberada e a baseline estabelecida para o produto no ambiente da fbrica (vide ANEXO B Checklist de Auditoria de Liberao de Verso ou Patch). As inconsistncias encontradas durante a checagem devem ser tratadas com o solicitante para resoluo. Ele deve delegar, aos reais responsveis pelos problemas detectados na auditoria, as atividades para corrigi-los. O Gerente de Configurao, por sua vez, deve refazer a auditoria para aferir se os problemas detectados foram realmente corrigidos ou no.
65
O Gerente de Configurao deve manter este checklist preenchido armazenado no repositrio, para que seja possvel rastrear as atividades relacionadas liberao da verso ou do patch. 5.3.4.3. Atividade: Elaborar Release Notes da verso ou patch O Gerente de Configurao deve criar o Release Notes da verso ou do patch, informando aos clientes o contedo da verso/patch que est sendo liberada e as instrues de atualizao do produto. Quando elaborar o Release Notes de um patch (vide ANEXO D Modelo de Release Notes de Patch), o Gerente de Configurao deve informar adicionalmente a verso do produto na qual as implementaes do patch estaro disponveis. J na elaborao do Release Notes de uma verso (vide ANEXO C Modelo de Release Notes de Verso), devem ser informados os patches incorporados na verso desde a ltima verso gerada. Estas informaes vo ajudar a medir a qualidade de uma verso liberada a partir do nmero de patches gerados entre as verses. O Release Notes gerado pelo Gerente de Configurao deve ser armazenado no repositrio, para que seja possvel recuper-lo posteriormente e ajudar na rastreabilidade de uma correo ou nova implementao no produto. 5.3.4.4. Atividade: Executar atividades de liberao de verso ou patch O Gerente de Configurao deve criar um link entre a verso ou patch que est sendo liberada(o) e as baselines estabelecidas. Esta relao pode ser feita atravs do uso de rtulos no repositrio ou atravs da criao de um documento que relacione para cada verso ou patch as baselines envolvidas. Alm disso, o Gerente de Configurao deve realizar as atividades de empacotamento da verso ou patch e disponibilizar o pacote gerado juntamente com o Release Notes. Toda a equipe deve ser notificada da liberao da verso ou patch, contendo a verso que est sendo liberada e a localizao do pacote e respectivo Release Notes. 5.3.5. Subprocesso 4: Controlar Mudanas Este subprocesso pode ser considerado um dos mais crticos dentro do processo proposto, porque, em uma fbrica orientada a produto, as solicitaes de mudana para o produto so constantes, tanto para melhorias solicitadas pelos clientes, como os erros
66
encontrados em ambientes de produo, sendo que estes, para este tipo de organizao, possuem uma alta prioridade em relao s demais solicitaes de mudana. Por isso, preciso conciliar na fbrica os ciclos de atendimento das melhorias com as correes de erro e os projetos em andamento, visto que todos estes trs tipos de atividades so finalizados atravs das liberaes de verses e patches pela fbrica. A Tabela 5-10 apresenta um resumo deste subprocesso.
Objetivos Gerenciar as mudanas na configurao do produto e dos projetos, atravs das atividades de registro, anlise, execuo e acompanhamento das solicitaes de mudana no produto e nos projetos. Aes Submeter solicitao de mudana Avaliar solicitao Realizar alterao Acompanhar status das solicitaes Sadas Solicitao de mudana analisada e resolvida Itens de configurao modificados
Entradas Solicitao de mudana Itens de configurao estveis
(quando aplicvel) Solicitao de baseline realizada (quando itens de configurao forem alterados) Notificao do status das solicitaes de mudana realizada Papis Envolvidos CCB Solicitante Analista
Tabela 5-10 Resumo do subprocesso 4: Controlar Mudanas
67
Figura 5-5 Viso grfica do subprocesso 4: Controlar Mudanas
5.3.5.1. Atividade: Submeter solicitao de mudana Uma solicitao de mudana pode ser reportada por qualquer pessoa da organizao, alm dos clientes da organizao, visto que o registro de uma solicitao de mudana o nico caminho para que erros e melhorias sejam submetidos anlise e execuo da fbrica. Neste processo, sugerido o uso de uma ferramenta de controle de mudanas, para facilitar no s a reportagem em si, como tambm acelerar a comunicao destas solicitaes dentro da organizao, visto que a maioria das ferramentas de controle de mudanas do mercado possui mecanismos de notificao de reportagem por e-mail. Durante a reportagem de uma solicitao de mudana, o relator deve informar alguns dados para que a fbrica possa analisar corretamente e decidir se a solicitao ser atendida ou no. A Tabela 5-11 apresenta um conjunto mnimo de informaes a serem passadas pelo relator durante o registro da solicitao de mudana.
68
Informao\Tipo de Solicitao Resumo da solicitao Produto associado solicitao Verso do Produto Gravidade Descrio detalhada da solicitao Passos para reproduo Logs de ocorrncia (quando existirem) Justificativa da solicitao
Erro X X X X X X X
Melhoria X X X
Tabela 5-11 Sugesto de Informaes de uma solicitao de mudana
importante que a fbrica defina um padro de reportagem de solicitaes, pois a partir delas sero extradas algumas mtricas da Gerncia de Configurao, e quanto mais padronizadas estiverem as informaes, mais fcil ser a coleta e anlise das mesmas, para que a fbrica tome aes em funo das mtricas apresentadas. 5.3.5.2. Atividade: Avaliar solicitao Uma vez registradas as solicitaes de mudana, o CCB deve avaliar cuidadosamente cada solicitao, observando os impactos das mudanas solicitadas. Devem ser minimamente considerados os seguintes fatores na avaliao das solicitaes: Classificao da solicitao: nem sempre as solicitaes esto classificadas corretamente (erros que no existem, melhorias que so erros). Isso acaba criando uma falsa visibilidade dos ndices de erros e melhorias recebidos pela fbrica. Antes de qualquer anlise, preciso esclarecer se a solicitao est categorizada corretamente. Consistncia com os requisitos do produto: algumas solicitaes de mudana podem propor alteraes em funcionalidades do produto que j esto sendo utilizadas no mercado. preciso avaliar se a solicitao no compromete o funcionamento atual do produto e se vai contribuir para sua evoluo, sem descaracterizar a funcionalidade. Consistncia com requisitos de projetos em desenvolvimento: o CCB deve avaliar as solicitaes de mudana no apenas em relao aos requisitos do produto, mas tambm deve considerar os requisitos que esto sendo desenvolvidos nos projetos em
69
andamento na fbrica. Esta avaliao bastante crtica, pois uma solicitao pode gerar desdobramentos srios nos cronogramas dos projetos impactados. Cabe ao CCB, portanto, decidir se a solicitao ser executada e negociar os impactos com os gerentes dos projetos afetados pelas mudanas demandadas. Criticidade da solicitao: Normalmente, uma solicitao de mudana reportada por um cliente posta sempre como de alta criticidade, pois para o cliente o produto no deveria possuir erros e as melhorias devem ser atendidas imediatamente. No entanto, preciso avaliar se a solicitao realmente possui o nvel de criticidade informado, para que no comprometa desnecessariamente o planejamento de baselines j feito pela fbrica. Em caso de discordncia em relao criticidade da solicitao, o CCB deve mudar este atributo para o valor que achar adequado e notificar o relator da solicitao sobre a mudana. Impacto na alocao da equipe: o CCB deve avaliar se h recursos na fbrica suficientes para atender demanda solicitada. Apesar de a gesto de recursos fazer parte da gesto de projetos, outra rea de processos do CMMI, durante este subprocesso haver uma integrao entre estas reas, para que a anlise de impacto seja completa.
O CCB pode solicitar equipe de desenvolvimento apoio para a avaliao do impacto da solicitao ou quaisquer outras iniciativas com o objetivo de clarear o entendimento antes de aprovar ou no a solicitao. Uma vez analisados os impactos de cada solicitao de mudana, o CCB deve revislos para garantir que a anlise de impacto foi bem feita e decidir sobre a prioridade das solicitaes: Solicitaes que sero atendidas imediatamente Solicitaes que sero atendidas na prxima verso do produto Solicitaes que no sero atendidas.
As decises do CCB devem ser registradas na ferramenta de controle de mudanas. Para cada solicitao de mudana analisada pelo CCB, deve-se registrar, minimamente: Deciso do CCB. No caso de rejeio, apresentar justificativa.
70
A anlise de impacto Itens de configurao a serem alterados.
Cada solicitao de mudana aceita pela fbrica deve ser encaminhada equipe de desenvolvimento para posterior tratamento. 5.3.5.3. Atividade: Realizar alterao A equipe de desenvolvimento deve realizar as alteraes no produto a partir da solicitao de mudana aprovada pelo CCB. Todos os itens de configurao afetados pela solicitao de mudana devem ser alterados, assim como o histrico de alteraes dos documentos. Os itens de configurao a serem alterados devem ser requisitados (checked-out) e atualizados (checked-in) no repositrio de maneira a manter sua integridade. O responsvel pela alterao, ao realizar o check-in, deve informar o nmero da solicitao de mudana realizada, para que o Gerente de Configurao possa rastrear as modificaes realizadas no produto para atender s solicitaes de mudana. O responsvel pelas atividades da solicitao de mudana deve alterar o status da solicitao de mudana, conforme definido na atividade 5.3.2.4. 5.3.5.4. Atividade: Acompanhar status das solicitaes O CCB deve acompanhar o status de todas as solicitaes de mudana aprovadas pelo grupo e encaminhadas equipe de desenvolvimento. Apesar de o acompanhamento de atividades tambm fazer parte do processo de Gerenciamento de Projetos, importante citar que o CCB deve ter visibilidade do andamento das atividades que atendem s solicitaes de mudana. Atravs da ferramenta de controle de mudanas, possvel realizar o acompanhamento atravs das notificaes de mudana de status das solicitaes por e-mail. 5.3.6. Subprocesso 5: Acompanhar Gerncia de Configurao Este subprocesso engloba as atividades de acompanhamento de status das atividades de gerncia de configurao e das auditorias peridicas de configurao que devem ser realizadas dentro da fbrica. A importncia deste subprocesso se deve ao fato de que necessrio monitorar periodicamente se o processo est sendo executado corretamente na rotina diria das equipes da fbrica, para evitar que as atividades sejam executadas de forma
71
incorreta, prejudicando o sistema de configurao estabelecido na empresa. A Tabela 5-12 apresenta um resumo deste subprocesso.
Objetivos Realizar o acompanhamento da Gerncia de Configurao, atravs da visualizao de resultados das auditorias de Gerncia de Configurao e divulgao do status das atividades de Gerncia de Configurao. Aes Realizar auditorias de Configurao Acompanhar Status da Gerncia de Configurao Sadas Relatrio de Status da Gerncia de Configurao Relatrio de Auditoria Peridica de Configurao Papis Envolvidos Gerente de Configurao Diretoria
Tabela 5-12 Resumo do subprocesso 5: Acompanhar Gerncia de Configurao
Entradas Atividades de Gerncia de Configurao
Figura 5-6 Viso grfica do subprocesso 5: Acompanhar Gerncia de Configurao
72
5.3.6.1. Atividade: Realizar auditorias de configurao O Gerente de Configurao deve realizar auditorias peridicas na fbrica para identificar desvios da equipe na execuo diria das atividades de Gerncia de Configurao. Nos momentos de estabelecimento de baseline e liberao de verso ou patch, ele consegue filtrar diversos desvios, mas o re-trabalho causado nestes momentos mais caro para a fbrica, por causa da presso existente em seguir com as atividades vinculadas ao estabelecimento de uma baseline e a liberao de uma verso ou patch. medida que os desvios so identificados nas auditorias peridicas do Gerente de Configurao, os desvios nos demais momentos de auditoria tendem a ser minimizados. As auditorias peridicas devem ser feitas mensalmente, e, se necessrio, o Gerente de Configurao pode diminuir o intervalo entre as auditorias. Durante esta atividade, devem ser investigados todos os aspectos fsicos relacionados a repositrio e ferramentas de controle de mudanas, o controle de acesso s ferramentas de configurao definidos para a fbrica, sempre com o apoio de checklists, que devem ser armazenados no repositrio para uma auditoria de qualidade (vide ANEXO E - Checklist de Auditoria Peridica de Gerncia de Configurao). Todos os desvios encontrados pelo Gerente de Configurao devem ser reportados da mesma maneira que so feitas as reportagens de desvios no estabelecimento de baseline e na liberao de verses ou patches. O Gerente de Configurao deve acompanhar a resoluo dos desvios junto aos responsveis, e escalar diretoria qualquer dificuldade por parte da fbrica na resoluo dos desvios. 5.3.6.2. Atividade: Acompanhar status da Gerncia de Configurao O acompanhamento das atividades de Gerncia de Configurao deve ser feito junto direo da fbrica, para que seja possvel avaliar o desempenho da rea, alm de identificar e resolver qualquer conflito encontrado nas auditorias de configurao. Este acompanhamento deve ser feito atravs de reunies peridicas, preferencialmente mensais, e devem ser apresentadas as mtricas coletadas durante o perodo, alm das informaes sobre infraestrutura, recursos e qualidade do atendimento da rea. importante ressaltar que o objetivo deste acompanhamento no olhar detalhadamente as atividades da Gerncia de Configurao, e sim discutir aspectos mais gerais da rea. O acompanhamento dirio feito nas reunies de acompanhamento de
73
projetos, visto que o trabalho da gerncia de configurao est distribudo entre os projetos da fbrica.
5.4. Institucionalizao do processo
Nesta seo, sero apresentadas as atividades relacionadas institucionalizao do processo proposto em uma fbrica de software, atendendo s prticas genricas do nvel 2 de maturidade de capacidade do CMMI para a Gerncia de Configurao. 5.4.1. Poltica Organizacional para a Gerncia de Configurao Segundo o CMMI, uma empresa deve estabelecer uma poltica organizacional para as reas de processo que pretende institucionalizar, pois nesta poltica esto descritos todos os princpios, direcionamentos, normas e procedimentos que guiaro as equipes na execuo das atividades do processo institucionalizado. No que se refere ao processo proposto, a poltica deve abordar princpios baseados na realidade da fbrica orientada a produtos, onde a gerncia de configurao est focada primeiro no produto e depois nos projetos. A Tabela 5-13 apresenta sugestes de itens da poltica organizacional para a gerncia de configurao. Itens da poltica organizacional Todos os produtos da empresa devem possuir um gerente de configurao, independente da quantidade de projetos existentes para cada produto. Todo produto e seus projetos devem possuir um plano de gerncia de configurao, que deve ser de responsabilidade do gerente de configurao. A gerncia de configurao deve ser implementada ao longo do ciclo de vida dos produtos, devendo ser revisada durante o planejamento dos projetos que agregam funcionalidades aos produtos. Todos os produtos de trabalho que esto sob a gerncia de configurao devem estar armazenados no repositrio da organizao, que deve ter uma estrutura mnima padronizada para todos os produtos da empresa.
Tabela 5-13 Sugestes de itens da poltica organizacional para a gerncia de configurao
5.4.2. Ferramentas de apoio ao processo Neste processo, foram abordadas a necessidade de existncia de dois tipos de ferramentas:
74
Repositrio: a ferramenta de controle de verses, usada para armazenar os itens de configurao e gerenciar suas mudanas de verses.
Ferramenta de controle de mudanas: para gerenciar as solicitaes de mudana demandadas pelos produtos e projetos.
importante ressaltar que essa foi uma premissa adotada por este processo, visto que um dos objetivos otimizar as atividades de gerncia de configurao na fbrica. Segundo [Dart-91], pode-se considerar um sistema de configurao aquele que oferece de alguma forma o controle de verses, a identificao da configurao, a estruturao e modelagem do sistema e a gerncia de sua configurao. E as ferramentas de gerncia de configurao fornecem apoio implementao do sistema de configurao. As atividades da gerncia de configurao englobam atividades automatizadas (com o apoio de ferramentas) e atividades manuais. possvel realizar as atividades de gerncia de configurao sem o apoio de ferramentas, mas isto muito ineficiente, pois a necessidade de gerenciar as verses de cada artefato da organizao, registrar e manter cada histrico de mudanas das solicitaes dos clientes, entre outros aspectos, exige muito tempo, gera um nmero excessivo de arquivos para controle por parte do gerente de configurao, o que acaba tornando o processo lento e centralizado. Da a necessidade de se utilizar ferramentas para apoiar o processo de gerncia de configurao. Existe atualmente um conjunto vasto de ferramentas de apoio gerncia de configurao, principalmente no mbito de softwares open source. importante que a organizao que vai implantar o processo escolha suas ferramentas de acordo com a sua realidade e expectativa de utilizao do processo na organizao. Alguns aspectos que devem ser considerados so a integridade das informaes manipuladas pelos repositrios, visto que nele onde sero armazenados os itens de configurao dos produtos da empresa, e a facilidade de uso e flexibilidade das ferramentas de controle de mudanas, para permitir empresa a definio dos fluxos de controle de mudanas de maneira rpida e fcil. 5.4.3. Treinamentos para o processo Este processo prope a realizao dos seguintes treinamentos na organizao para a execuo bem sucedida das atividades de Gerncia de Configurao (Tabela 5-14):
75
Treinamento
Pblico-alvo Equipes da fbrica Clientes da fbrica
Objetivo Entender o seu papel dentro do
Processo de Gerncia de Configurao
internos processo, aprendendo sobre cada atividade existente, para que sejam capazes de execut-las corretamente.
Atividades de Gerncia de Configurao
Gerente Configurao
de Entender o papel do Gerente de Configurao no processo, detalhando cada atividade que ele dever desempenhar para garantir o cumprimento do processo dentro da organizao.
Administrao Repositrio
do
Gerente Configurao
de Entender gerenci-lo,
funcionamento
do
repositrio da organizao, e como tendo poderes de
criao, alterao e remoo de pastas, usurios e permisses dentro do repositrio. Administrao da Gerente Configurao de Entender o funcionamento da
ferramenta de controle de mudanas
ferramenta de controle de mudanas, para que possa controlar os usurios, projetos e solicitaes de mudana geradas na ferramenta.
Utilizao do repositrio
Equipes da fbrica
Aprender a utilizar o repositrio, para que possam inserir e recuperar os itens de configurao e outros artefatos.
Utilizao da ferramenta de controle de mudanas
Equipes da fbrica Clientes da fbrica
Aprender a utilizar a ferramenta de
internos controle de mudanas, alm dos padres de reportagem de
Clientes externos solicitaes de mudana. da organizao
Tabela 5-14 Lista de treinamentos para o processo proposto
76
Todos os treinamentos devero possuir uma evidncia de sua realizao, atravs das atas de presena nos treinamentos e das avaliaes dos treinamentos, para que a organizao possa sempre melhorar a capacitao das equipes no processo. 5.4.4. Gerncia de configurao do processo Devem ser definidos procedimentos para controle dos artefatos produzidos pelo processo, para evitar o acesso indevido a estes produtos de trabalho. A Tabela 5-15 apresenta o nvel de controle para os artefatos deste processo. Artefato Nvel de controle
Plano de gerncia de configurao do Deve estar armazenado no repositrio, com o produto histrico de revises sempre preenchido a cada mudana de verso. Plano de gerncia de configurao do Deve estar armazenado no repositrio, com o projeto histrico de revises sempre preenchido a cada mudana de verso. Material de treinamento, atas e Deve estar armazenado no repositrio, em uma rea especifica para os treinamentos.
avaliaes de treinamento
Dados usados para gerar as informaes As ferramentas que contm estes dados devem das mtricas do processo estar sob a rotina de backup da organizao, para que eles possam ser recuperados sempre que desejado.
Tabela 5-15 Nvel de controle dos artefatos do processo
5.4.5. Mtricas do processo Para o acompanhamento da eficincia do processo implantado e das atividades de gerncia de configurao executadas, este processo prope o uso das seguintes mtricas, cujas definies operacionais esto detalhadas no ANEXO F Definio Operacional das Mtricas do Processo Proposto: Nmero de desvios de auditoria por baseline Objetivo geral: identificar o ndice de erros cometidos pela equipe antes de solicitar um estabelecimento de baseline. Nmero de erros e melhorias no produto por verso
77
Objetivo geral: identificar a proporo entre os erros reportados e as melhorias solicitadas por verso do sistema.
Nmero de auditorias planejadas x realizadas Objetivo geral: realizar a comparao entre o planejamento das auditorias de configurao e a sua realizao, para acompanhar a alocao do gerente de configurao em suas atividades.
5.4.6. Auditorias do processo As atividades do processo devem ser avaliadas pelo engenheiro de qualidade da fbrica, ou por algum membro da fbrica que no esteja envolvido no processo proposto. Ele deve criar um checklist com o mapeamento do processo com os artefatos produzidos por cada subprocesso e atividades. Devem ser identificadas todas as evidncias de execuo do processo, atravs de: Realizao de entrevistas com as equipes da fbrica Avaliao dos artefatos produzidos pelo processo Avaliao das baselines estabelecidas (e meios para chegar ao estabelecimento) Avaliao das verses liberadas (e meios para chegar liberao) Avaliao do repositrio usado Avaliao da ferramenta de controle de mudanas Avaliao das guias e padres definidos pelo processo.
O responsvel pela auditoria deve construir um relatrio de avaliao do processo, identificando os pontos positivos da execuo do processo e as oportunidades de melhoria do processo na organizao, que podem implicar em mudanas na organizao ou no prprio processo.
5.5. Consideraes finais
Este captulo apresentou o detalhamento do processo proposto para Gerncia de Configurao em Fbricas Orientadas a Produto alinhado ao nvel 2 de capacidade e maturidade do CMMI. O foco principal deste processo proposto apresentar o produto como
78
ponto central da fbrica, com o planejamento da gerncia de configurao dos projetos levando sempre em considerao a configurao do produto. Alm disso, importante ressaltar que neste processo o planejamento das baselines est baseado na verso ou patch do produto a ser liberado. Desta forma, a organizao permanece mantendo o foco no produto a ser desenvolvido e evoludo dentro da fbrica. importante ressaltar que a eficincia de um processo s pode ser avaliada aps sua institucionalizao, pois durante esta etapa que so identificados os gargalos de execuo do processo, alm dos benefcios que o mesmo traz organizao. Vale a pena tambm avaliar a aderncia do processo ao nvel 2 do CMMI, para que seja possvel identificar oportunidades de melhorias e possveis desvios do processo em relao ao nvel avaliado.
79
Captulo 6 - Anlise crtica do processo proposto
Captulo 6. Anlise proposto

Neste captulo apresentada uma anlise crtica do processo proposto atravs do mapeamento entre ele e as prticas da rea de processo de Gerncia de Configurao do nvel 2 do CMMI.
crtica
do
processo
80
No captulo 5 foi apresentado o processo proposto de Gerncia de Configurao alinhado ao nvel 2 de capacidade e maturidade do CMMI. Neste captulo ser realizado um mapeamento entre o processo proposto e a rea de processo de Gerncia de Configurao, atravs de uma simulao de avaliao baseada no SCAMPI (seo 2.3). A estratgia desta anlise crtica baseou-se no trabalho realizado por [Feitosa-04]. Nela sero identificados os artefatos diretos e indiretos que o processo proposto possui, atravs da avaliao junto s prticas especficas e genricas. importante ressaltar que, assim como mencionado por [Feitosa-04], o mapeamento realizado neste captulo, apesar de seguir as orientaes providas pelo SCAMPI, baseia-se na interpretao da autora em relao a informaes contidas no processo, e pode ser diferente de outras interpretaes.
6.1. Mapeamento do processo de Gerncia de Configurao x CMMI
6.1.1. SG1 Estabelecer baselines Baselines dos produtos de trabalho identificados so estabelecidas. 6.1.1.1. SP1.1-1 Identificar itens de configurao Subprticas 1. Selecionar itens de configurao e produtos de trabalho que os compem baseado em critrio documentado. 2. 3. 4. Atribuir identificadores nicos aos itens de configurao. Especificar as caractersticas importantes de cada item de configurao. Especificar quando cada item de configurao colocado sob gerncia de configurao. 5. Identificar o responsvel pelo item de configurao.
Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Selecionar os itens de configurao (impacto direto nas subprticas 1 e 2).
Artefatos diretos
81
Plano de Gerncia de Configurao do Produto, Plano de Gerncia de Configurao do Projeto
Artefatos indiretos Atas de reunio do planejamento.
Sugestes de entrevista Membros da equipe de desenvolvimento: para verificar se eles sabem quais so os itens e qual a fonte de informao, Gerente de produto: para identificar se ele participou do levantamento dos itens de configurao Gerente de projeto: para identificar se ele sabe quais os itens de configurao do projeto e se participou da identificao dos itens. Gerente de configurao: para identificar qual a sua participao na elaborao dos planos de configurao e na divulgao do plano junto equipe de desenvolvimento.
6.1.1.2. SP1.2-1 Estabelecer um sistema de gerncia de configurao Subprticas 1. Estabelecer um mecanismo de gerenciar mltiplos nveis controle de gerncia de configurao. 2. Armazenar e recuperar itens de configurao no sistema de gerncia de configurao. 3. Compartilhar e transferir itens de configurao entre nveis de controle dentro do sistema de gerncia de configurao 4. 5. 6. Armazenar e recuperar verses arquivadas de itens de configurao. Armazenar, atualizar e recuperar registros de gerncia de configurao. Criar relatrios de gerncia de configurao a partir do sistema de gerncia de configurao. 7. Preservar o contedo do sistema de gerncia de configurao
82
8.
Rever a estrutura da gerncia de configurao quando necessrio.
Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Configurar ferramentas de Gerncia de Configurao. Subprocesso 5: Acompanhar Gerncia de Configurao: Atividade: Realizar
auditorias de configurao. Artefatos diretos Registros de controle de mudanas, repositrio dos itens de configurao, procedimentos de backup e restore do repositrio e da ferramenta de controle de mudanas, relatrio de auditoria de configurao. Artefatos indiretos Registros de check-in e check-out dos itens de configurao no repositrio, histrico de mudana de status das solicitaes de mudana na ferramenta de controle de mudanas. Sugestes de entrevista Gerente de configurao, membros da equipe de desenvolvimento, pessoa responsvel pela realizao de backup, quando o mesmo for um procedimento j definido na fbrica. 6.1.1.3. SP1.3-1 Criar ou liberar baselines Subprticas 1. Obter autorizao do CCB antes de criar ou liberar baselines de itens de configurao 2. Criar ou liberar baselines apenas a partir de itens de configurao que esto no sistema de gerncia de configurao. 3. 4. Documentar o conjunto de itens de configurao que esto na baseline Tornar a baseline atual disponvel
83
Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Definir o CCB do projeto, Atividade: Planejar baselines, Subprocesso 2: Estabelecer Baselines: Atividade: Solicitar o estabelecimento de baseline, Atividade: Avaliar solicitao, Atividade: Executar atividades de estabelecimento de baseline. Subprocesso 3: Liberar verses ou patches: Atividade: Solicitar liberao de verso ou patch, Atividade: Avaliar solicitao, Atividade: Elaborar Release Notes da verso ou patch, Atividade: Executar atividades de liberao de verso ou patch
Artefatos diretos Plano de Gerncia de Configurao do Produto, Plano de Gerncia de Configurao do Projeto, Release notes de verso, Release notes de patch, checklist de auditoria de estabelecimento de baseline preenchido, checklist de auditoria de liberao de verso ou patch preenchido.
Artefatos indiretos E-mails de solicitao de estabelecimento de baseline, e-mails de solicitao de liberao de verso ou patch, e-mail de notificao de baseline estabelecida, emails de notificao de liberao de verso ou patch, registros de avaliao de impacto, checklists de auditoria de estabelecimento de baseline e de liberao de verso ou patch.
Sugestes de entrevista Membros da equipe de desenvolvimento: para verificar se sabem quem o CCB da fbrica, como so feitos os estabelecimentos de baseline e as liberaes de verso ou patch, como eles so notificados destas atividades. Gerente de configurao: para avaliar como feito o estabelecimento das baselines e a liberao de verses ou patches. Gerente de Produto e Gerente de Projeto: para identificar qual a sua participao no estabelecimento de baselines e na liberao de verses ou patches.
84
6.1.2. SG2 Rastrear e controlar mudanas Mudanas nos produtos de trabalho sob gerncia de configurao so rastreadas e controladas. 6.1.2.1. SP2.1-1 Rastrear solicitaes de mudana Subprticas 1. Iniciar e registrar solicitaes de mudana em um banco de dados de solicitao de mudanas. 2. Analisar o impacto das mudanas e correes propostas na solicitao de mudana. 3. Revisar as solicitaes de mudana que sero atendidas na prxima baseline junto com as que sero afetadas pelas mudanas e obter a sua concordncia. 4. Acompanhar o status das solicitaes de mudana at o fechamento.
Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Planejar baselines. Subprocesso 4: Controlar Mudanas: Atividade: Submeter solicitao de mudana, Atividade: Avaliar solicitao, Atividade: Realizar alterao, Atividade: Acompanhar status das solicitaes.
Artefatos diretos Registro das solicitaes de mudana na ferramenta de controle de mudanas, registro da anlise de impacto do CCB na ferramenta de controle de mudanas, histrico de mudana de status das solicitaes de mudana.
Artefatos indiretos E-mails de definio de escopo da verso ou patch do produto, release notes da verso contendo as CRs atendidas pela verso, e-mail de divulgao de estabelecimento de baseline que atende as CRs avaliadas.
Sugestes de entrevista
85
Membros da equipe de desenvolvimento: para identificar o entendimento de como funciona o processo de gesto de mudanas.
Gerente de configurao: para identificar se ele acompanha as CRs analisadas Membros do CCB: para identificar como realizada a anlise de impacto das CRs reportadas.
6.1.2.2. SP2.2-1 Controlar itens de configurao Subprticas 1. 2. Controlar mudanas nos itens de configurao durante o ciclo de vida do produto. Obter autorizao apropriada antes de colocar no sistema de gerncia de configurao itens de configurao modificados. 3. Realizar check-in e check-out dos itens de configurao no sistema de gerncia de configurao para incorporar mudanas de modo que mantenha a integridade e corretude dos itens de configurao. 4. Realizar revises para garantir que as mudanas no causaram efeitos colaterais nas baselines (ou seja, garantir que as mudanas no comprometeram a segurana e estabilidade do sistema). 5. Registrar mudanas nos itens de configurao e a razo pela qual a mudana foi realizada quando apropriado. Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Selecionar os itens de configurao: Atividade: Planejar baselines. Subprocesso 2: Estabelecer Baselines: Atividade: Solicitar o estabelecimento de baseline, Atividade: Avaliar solicitao. Subprocesso 3: Liberar verses ou patches: Atividade: Solicitar liberao de verso ou patch
86
Subprocesso 4: Controlar Mudanas: Atividade: Submeter solicitao de mudana, Atividade: Avaliar solicitao, Atividade: Realizar alterao, Atividade: Acompanhar status das solicitaes.
Artefatos diretos Histrico de revises dos itens de configurao no repositrio (para o caso de alteraes devido a solicitaes de mudana, o nmero da solicitao de mudana deve estar registrado minimamente no histrico de revises do item), registro das solicitaes de mudana.
Artefatos indiretos E-mails de notificao do registro das solicitaes e mudanas de status.
Sugestes de entrevista Membros da equipe de desenvolvimento: para identificar se os registros de configurao esto sendo realizados da maneira correta.
6.1.3. SG3 Estabelecer integridade Integridade das baselines estabelecida e mantida. 6.1.3.1. SP3.1-1 Estabelecer registros da gerncia de configurao Subprticas 1. Registrar aes de gerncia de configurao em detalhes suficientes de modo que o status de cada item de configurao seja conhecido e verses antigas recuperadas. 2. Garantir que os stakeholders relevantes tenham acesso e conhecimento sobre os status da configurao dos itens de configurao. 3. 4. Especificar as ltimas verses das baselines. Identificar a verso dos itens de configurao que constituem uma determinada baseline. 5. 6. Descrever as diferenas entre sucessivas baselines. Rever o status e o histrico de cada item de configurao quando necessrio.
87
Atividades do processo relacionadas: Subprocesso 2: Estabelecer Baselines: Atividade: Solicitar o estabelecimento de baseline, Atividade: Avaliar solicitao, Atividade: Executar atividades de estabelecimento de baseline Subprocesso 3: Liberar verses ou patches: Atividade: Solicitar liberao de verso ou patch, Atividade: Elaborar Release Notes da verso ou patch, Atividade: Executar atividades de liberao de verso ou patch Subprocesso 4: Controlar Mudanas: Atividade: Submeter solicitao de mudana, Atividade: Realizar alterao
Artefatos diretos Registros das solicitaes de mudana, release notes de verso ou patch, histrico de verses dos itens de configurao no repositrio.
Artefatos indiretos E-mails de notificao das liberaes de verses ou patches.
Sugestes de entrevista Gerente de Configurao: para identificar como as baselines so estabelecidas, se ele elabora os Release Notes conforme solicitado pelo processo, para verificar os momentos em que estas atividades esto sendo executadas. Lder de produto e membros da equipe de desenvolvimento, para identificar como eles conseguem ter acesso s diferenas entre baselines, ao histrico de revises dos itens de configurao.
6.1.3.2. SP3.2-1 Realizar auditorias de configurao Subprticas 1. 2. Avaliar a integridade das baselines Confirmar que os registros de configurao identificam corretamente a configurao dos itens de configurao.
88
3.
Revisar a estrutura e a integridade dos itens no sistema de ger6encia de configurao.
4.
Confirmar a completude e corretude dos itens no sistema de gerncia de configurao.
5.
Confirmar aderncia aos padres e procedimentos de gerncia de configurao aplicveis.
6.
Rastrear itens de ao de auditoria at o fechamento.
Atividades do processo relacionadas: Subprocesso 2: Estabelecer Baselines: Atividade: Avaliar solicitao Subprocesso 3: Liberar verses ou patches: Atividade: Avaliar solicitao Subprocesso 5: Acompanhar Gerncia de Configurao: Atividade: Realizar
auditorias de configurao. Artefatos diretos Relatrio de Auditoria Peridica de Configurao, checklist preenchido de auditoria de estabelecimento de baseline, checklist preenchido de auditoria de liberao de verso ou patch. Artefatos indiretos Registro das atividades de auditoria de configurao, registros de negociao dos desvios com os responsveis. Sugestes de entrevista Gerente de Configurao: para identificar como ele executa as auditorias, se ele armazena os checklists no repositrio, como ele negocia os desvios encontrados. 6.1.4. GG2 Institucionalizar um processo gerenciado O processo est institucionalizado como um processo gerenciado. 6.1.4.1. GP2.1 Estabelecer uma poltica organizacional Descrio
89
Estabelecer e manter uma poltica organizacional para planejar e executar o processo de gerncia de configurao.
Atividades do processo relacionadas: As atividades do processo devem seguir a poltica organizacional da empresa.
Artefatos diretos: Poltica organizacional da empresa contendo as aes relacionadas gerncia de configurao.
Sugestes de entrevistas: Membros da fbrica, para verificar se eles conhecem a poltica e se h o cumprimento das definies escritas na poltica Alta direo, para verificar se houve a participao dela na definio da poltica.
6.1.4.2. GP2.2 Planejar o processo Descrio Estabelecer e manter o plano para executar o processo de gerncia de configurao. Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao (todas as atividades)
Artefatos diretos: Plano de gerncia de configurao do produto, plano de gerncia de configurao do projeto.
Sugestes de entrevistas: Gerente de configurao, para verificar as atividades necessrias para a elaborao do planejamento. Gerentes (de projeto e de produto), para verificar a participao deles na elaborao do planejamento da gerncia de configurao.
90
Equipe de desenvolvimento, para verificar se eles tiveram acesso ao planejamento elaborado.
6.1.4.3. GP2.3 Prover recursos Descrio Prover recursos apropriados para executar o processo de gerncia de configurao, desenvolvendo os produtos de trabalho e provendo os servios do processo. Atividades do processo relacionadas: Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Configurar ferramentas de Gerncia de Configurao, Atividade: Conciliar os Planos de Gerncia de Configurao. Artefatos diretos: Plano de gerncia de configurao
Artefatos indiretos Ferramentas de apoio ao processo
Sugestes de entrevistas: Equipe de desenvolvimento, para verificar se as ferramentas esto disponveis para uso e como elas esto sendo utilizadas pelos projetos.
6.1.4.4. GP2.4 Atribuir responsabilidades Descrio Atribuir responsabilidades e autoridade para executar o processo, desenvolvendo os produtos de trabalho e provendo os servios do processo de gerncia de configurao. Atividades do processo relacionadas: Papis e responsabilidades no processo Subprocesso 1: Planejar Gerncia de Configurao: Atividade: Conciliar os Planos de Gerncia de Configurao.
91
Artefatos diretos: Plano de gerncia de configurao do produto, plano de gerncia de configurao do projeto.
Sugestes de entrevistas: Membros da fbrica, para verificar se todos sabem quais so os papis e responsabilidades definidos pelo processo, e se as atividades destes papis esto sendo executadas conforme o planejamento.
6.1.4.5. GP2.5 Treinar pessoas Descrio: Treinar pessoas que realizam ou suportam o processo de gerncia de configurao quando necessrio. Atividades do processo relacionadas: Treinamentos para o processo
Artefatos diretos: Atas de realizao e avaliao dos treinamentos.
Sugestes de entrevistas: Membros da fbrica, para verificar se eles foram treinados, e se esto capacitados para executar as atividades de gerncia de configurao conforme previsto.
6.1.4.6. GP2.6 Gerenciar configurao Descrio Colocar os produtos de trabalho do processo de gerencia de configurao sob nveis de gerncia de configurao apropriados. Atividades do processo relacionadas: Gerncia de configurao do processo
Artefatos diretos:
92
Repositrio, contendo os produtos de trabalho do processo, como planos de gerncia de configurao e treinamentos executados.
Sugestes de entrevistas: Responsveis pela realizao dos backups do repositrio e demais ferramentas de gerencia de configurao. Gerente de configurao, para verificar a localizao dos artefatos do processo e se ele est realizando as auditorias de configurao adequadamente.
6.1.4.7. GP2.7 Identificar e envolver stakeholders relevantes Descrio: Identificar e envolver os stakeholders relevantes do processo de gerncia de configurao como planejado. Atividades do processo relacionadas: Todas as atividades do processo proposto fazem referncia aos papis definidos para o processo. Artefatos diretos: Histrico de revises dos planos de gerncia de configurao do produto e dos projetos, evidenciando se a pessoa responsvel pelas mudanas nos artefatos possua esta responsabilidade. Atas de reunio de planejamento, para evidenciar a participao dos papis previstos pelo processo. Registros de avaliao de impacto nas ferramentas de controle de mudanas,
Sugestes de entrevistas: Pessoas que esto atribudas aos papis definidos no processo, para verificar se elas esto desempenhando os papis conforme definido no processo.
6.1.4.8. GP2.8 Monitorar e controlar o processo Descrio
93
Monitorar e controlar o processo de gerncia de configurao de acordo com o plano para executar o processo e realizar aes corretivas apropriadas.
Atividades do processo relacionadas: Subprocesso 5: Acompanhar Gerncia de Configurao: Atividade: Acompanhar status da Gerncia de Configurao
Artefatos diretos: Relatrios de status da gerncia de configurao, mtricas coletadas para o processo. Mtricas do processo
Sugestes de entrevistas: Gerente de configurao, para verificar se ele est realizando as coletas de mtricas conforme planejado.
6.1.4.9. GP2.9 Avaliar objetivamente a aderncia Descrio Avaliar objetivamente a aderncia do processo de gerncia de configurao com a descrio, padres e procedimentos do processo, e identificar as noconformidades. Atividades do processo relacionadas: Auditorias do processo
Artefatos diretos: Checklists de auditoria preenchidos, relatrios de auditoria do processo de gerncia de configurao.
Sugestes de entrevistas: Gerente de configurao, para identificar se est ocorrendo avaliaes de qualidade no processo de gerncia de configurao.
94
6.1.4.10. GP2.11 Revisar status com a alta gerncia Descrio Revisar as atividades, o status e os resultados do processo de gerncia de configurao com a alta gerncia e resolver as no-conformidades. Atividades do processo relacionadas: Subprocesso 5: Acompanhar Gerncia de Configurao: Atividade: Acompanhar status da Gerncia de Configurao Artefatos diretos: Atas de reunies de status com a alta direo, relatrio de status de configurao.
Sugestes de entrevistas: Alta direo, para verificar se as reunies de status da gerncia de configurao esto acontecendo conforme previsto e com a sua participao. Gerente de configurao, para verificar se as reunies de status com a alta direo esto acontecendo e se os assuntos previstos para estas reunies esto sendo abordados.
Este captulo apresentou a anlise crtica do processo proposto no captulo 5 em relao ao nvel 2 de capacidade e maturidade do CMMI para a rea de gerncia de configurao. Para tal, foi realizada uma simulao dos resultados de uma avaliao, atravs do mapeamento do processo proposto ao modelo, onde foi explicitada a aderncia do processo ao nvel 2 do CMMI. No prximo captulo ser apresentado estudo de caso, que visa instanciao do processo proposto em uma fbrica de software real, evidenciando as possveis deficincias e qualidades do processo realidade proposta, abrindo o leque de oportunidades de melhoria para este processo.
95
Captulo 7 - Estudo de caso
Captulo 7. Estudo de caso

Neste captulo so apresentados os resultados da aplicao do processo proposto para uma fbrica orientada a produtos, identificando os principais benefcios e obstculos enfrentados com a implantao de processos na organizao.
96
O objetivo principal do estudo de caso evidenciar a aplicao prtica do processo de Gerncia de Configurao proposto em um ambiente de fbrica de software orientada a produtos, de forma que seja possvel identificar os benefcios trazidos pela implantao do processo e as melhorias observadas na organizao de acordo com a avaliao crtica realizada do processo de Gerncia de Configurao realizada no captulo 6. Neste estudo de caso, sero analisados tambm os custos e as dificuldades de implantao do processo na organizao, o que evidenciar oportunidades de melhoria do processo proposto.
7.1. Escopo de realizao do estudo de caso
A organizao onde foi realizado o estudo de caso foi uma empresa de desenvolvimento de software de So Paulo, com filiais em Recife e Rio de Janeiro. O mercado de atuao desta empresa o mercado de varejo, atravs do fornecimento de solues de automao comercial. A estrutura da organizao contempla, dentre outras reas, uma fbrica de software situada em Recife, que ser o objeto de estudo da autora. A fbrica de software desta organizao vista como uma rea da organizao, que deve interagir com outros setores da empresa, conforme apresentado no captulo 2 (Seo2.1). A Figura 7-1 apresenta uma viso geral da estrutura da fbrica e seus relacionamentos com algumas reas da organizao. Isto importante para evidenciar os ajustes necessrios no processo proposto durante a execuo do estudo de caso para se adequar realidade desta organizao.
97
Figura 7-1 Viso geral da fbrica de software do estudo de caso
A organizao possui diversos produtos de software, que so mantidos pela sua fbrica de software em Recife. Para o estudo de caso, foi escolhido 01 produto desenvolvido pela empresa (chamaremos de produto 1), que destinado s operaes de conciliao eletrnica. Este produto foi desenvolvido em Visual Basic e est instalado em 24 clientes, possuindo atualmente 03 verses em ambiente de produo. A Tabela 7-1 apresenta alguns aspectos importantes sobre a organizao do trabalho na fbrica para este produto. Aspectos Organizao da Equipe Produto 1 Existe uma equipe que compartilha os projetos de novos desenvolvimentos e as manutenes evolutivas e corretivas no produto Tamanho da equipe Gerente de Configurao A equipe conta com 1 lder de produto e 2 analistas. O gerente de configurao compartilhado com os demais produtos da empresa.
98
Aspectos Arquitetura dos produtos
Produto 1 Baixa complexidade. O produto composto por 3 tipos de componentes, com a parametrizao realizada em banco de dados.
Gesto do produto Certificao
O lder de produto dedicado equipe, que nica. No conta com uma equipe de certificao dedicada. A prpria equipe de desenvolvimento certifica a implementao.
Gesto de projetos
Possui muitos projetos de curta durao (mdia de 1 a 3 meses). Possui poucos projetos de mdia e longa durao. Possui mais de 25 projetos de manuteno contratados pelos clientes.
Tabela 7-1 comparao entre os produtos do estudo de caso
Para o produto 1, foram escolhidos dois projetos: Projeto 1-A: projeto de novo desenvolvimento, demandado por um cliente da empresa, que iniciou em 2004 e j est finalizado. Projeto 1-B: projeto de manuteno do produto para um cliente da empresa, que iniciou em 2006 e est em andamento.
Ao longo do relato do estudo de caso, estes projetos sero mencionados para mostrar o comportamento de determinadas atividades do processo para cada um deles, mas o relato est focado diretamente no produto 1, j que a fbrica orientada a produtos.
7.2. Metodologia de trabalho
A empresa vem investindo em qualidade desde o ano de 2003, e durante o perodo de 2004 a 2006 participou de um projeto para obteno do nvel 2 de maturidade do CMMI em um grupo de empresas de Pernambuco. Este projeto compreendia as atividades de avaliao de escopo da organizao, definio e institucionalizao dos processos do nvel 2, e contou com a participao dedicada da autora em todas as fases. Apesar deste esforo, a empresa no atingiu o nvel 2 de maturidade, pois apresentava muitas deficincias de institucionalizao nas reas de processo, exceto a gerncia de configurao, que foi a rea de processo melhor institucionalizada na organizao.
99
Durante o perodo de abril/2004 a janeiro/2005 foi realizada a definio dos processos, incluindo o processo de gerncia de configurao, que foi baseado no processo proposto. Como o processo no estava descrito em sua verso final, o estudo de caso serviu como o meio de otimizao do processo, visto que foi necessrio realizar diversos ajustes no processo de gerncia de configurao, de acordo com os resultados providos pelo acompanhamento realizado junto s equipes. Durante a definio e implantao do processo, a autora atuou como engenheira de qualidade, e, junto com a equipe do projeto de melhoria de qualidade da empresa, foi responsvel por: Definir o processo de gerncia de configurao Planejar e acompanhar a implantao do processo na organizao Definir os templates dos artefatos necessrios para a execuo do processo. Acompanhar os resultados do processo atravs de auditorias de qualidade e atuar nos problemas detectados pelas auditorias.
7.3. Relato do Estudo de Caso
Esta seo apresenta o relato do estudo de caso para o produto mencionado na seo anterior. Aqui sero descritas as atividades realizadas durante a institucionalizao do processo para o produto 1, apresentando as dificuldades encontradas durante este perodo de institucionalizao e os benefcios adquiridos pela fbrica com a utilizao do processo. 7.3.1. Estudo de caso - Produto 1 Antes de iniciar a institucionalizao do processo de gerncia de configurao na fbrica, foi necessrio definir uma poltica de qualidade para esta rea de processo. A alta direo, com a ajuda da equipe de melhoria de processos, seguiu as recomendaes do processo proposto e criou um conjunto de diretrizes que deveriam valer para todos os projetos da fbrica. Esta poltica foi aprovada e publicada para as equipes envolvidas no processo de melhoria, o que inclui a equipe do produto 1. Durante a execuo do processo de gerncia de configurao, toda a equipe de desenvolvimento, incluindo o gerente de produto, recebeu treinamento sobre o CMMI e todas as reas de processo, incluindo a gerncia de configurao foco desta dissertao. Alm
100
disso, foi necessrio realizar o treinamento sobre o processo de gerncia de configurao definido para a fbrica, com nfase nas atividades de desenvolvimento que seriam impactadas pela gerncia de configurao. A autora, alm de desempenhar o papel de engenheira de qualidade da fbrica, atuava como gerente de configurao deste produto, o que no demandou a realizao de treinamento especifico para gerentes de configurao, visto que a autora participou da definio dos processos da fbrica. Aps 6 meses de compartilhamento de papis, a fbrica contratou um gerente de configurao, que, aps os treinamentos previstos no processo, passou a responder pelas atividades de gerncia de configurao para o produto 1 e seus projetos. Durante a institucionalizao do processo de gerncia de configurao, a fbrica contou com a realizao de auditorias externas de qualidade, que contriburam significativamente para a identificao dos problemas no processo e sua constante evoluo. Este assunto ser tratado na seo 7.3.1.6. Nas prximas sees, sero apresentados os resultados obtidos com a aplicao do processo nos projetos do produto 1, atravs de cada subprocesso definido no captulo 5. 7.3.1.1. Subprocesso 1: Planejar gerncia de configurao A elaborao do plano de gerncia de configurao se deu gradativamente com a implantao do prprio processo na fbrica, visto que a fbrica no possua experincia no planejamento da configurao de seus produtos. Isso foi feito tanto para o projeto 1A como para o projeto 1B. Como explicado no captulo 5, para este subprocesso necessrio: identificar os itens de configurao, planejar as baselines e configurar as ferramentas de gerncia de configurao. A identificao dos itens de configurao obedeceu aos critrios definidos no processo, e foram considerados inicialmente como itens de configurao: Cdigo-fonte Parmetros do sistema Scripts de banco de dados Documentos de requisitos dos projetos Release notes da verso do produto Release notes do patch do produto (quando a baseline se referir a um patch) Documento funcional do produto
101
Este ltimo foi criado pela fbrica para documentar todas as evolues funcionais do produto, e contribuir para a montagem da rastreabilidade do produto. Como era necessrio definir um padro de nomenclaturas para os itens de configurao, a equipe do processo de melhorias definiu um guia de nomenclaturas para todos os artefatos a serem usados pela fbrica, sejam eles itens de configurao ou no. Desta forma, todos os produtos e projetos da empresa passaram a usar este guia como referncia na elaborao de seus artefatos. Neste guia tambm foi definido o padro de nomenclatura das verses dos produtos da organizao, pois a organizao no seguia um padro de mercado nem possua um padro nico de versionamento para todos os produtos da empresa. Aps diversas pesquisas, foi definido que o versionamento dos produtos obedeceria ao seguinte padro: <XX>.<YY>.<ZZ> Onde: <XX> = Major Release Number: Verso do software a ser entregue ao cliente com modificaes estruturais do sistema, alm de mudanas substanciais nas
funcionalidades do sistema. Este nmero tem prioridade sobre todos os demais nmeros da verso (YY e ZZZ). Quando ele for incrementado, os demais devem ser zerados.
<YY> = Feature Release Number: Nmero a ser incrementado quando um release for produzido com uma nova funcionalidade includa no sistema ou quando funcionalidades existentes foram evoludas. Este nmero tem prioridade sobre o Defect repair number (ZZ). Quando ele for incrementado, o Defect repair number deve ser zerado.
<ZZ> = Defect repair number: Nmero a ser incrementado quando um novo release for produzido para correo de um release XX.YY. Usado apenas para liberao de patches do sistema. Devem estar em vinculados aos branches da verso principal (gerenciada pelo Major Release Number e pelo Feature Release Number).
Uma vez identificados os itens de configurao, foram definidos dois tipos de baselines:
102
Baseline de desenvolvimento: contm os itens de configurao modificados desde a ltima baseline de produo e deve ser usada para gerao de testes internos e certificao. Este tipo de baseline usa o seguinte padro de nomenclatura:
PROD1_DES_XXYYZZ_BB, onde: i) XXYYZZ: representao da verso do produto sem os pontos (.). ii) BB: nmero do build a ser gerado para aquela baseline, que deve ser incrementado sempre que for necessrio alterar a baseline com novas verses de itens de configurao. Baseline de produo: baseline de desenvolvimento que foi testada e que pode ser liberada para o cliente. Esta baseline conta adicionalmente com o documento funcional do produto atualizado com as funcionalidades testadas na baseline de
desenvolvimento. Este tipo de baseline usa o seguinte padro de nomenclatura:
PROD1_PRD_XXYYZZ, onde: i) XXYYZZ: representao da verso do produto sem os pontos (.).
A Tabela 7-2 apresenta um resumo das baselines definidas para este produto. Baseline Desenvolvimento Item de configurao Critrio de entrada na baseline Cdigo-fonte Aps testes unitrios e integrados Aps testes unitrios e integrados Aps testes unitrios e integrados de Aps aprovado pela fbrica
PROD1_DES_XXYYZZ_BB Scripts de banco Parmetros Documento
requisitos dos projetos Release notes da Aps testes unitrios e integrados
verso do produto Release notes do Aps testes unitrios e integrados
patch do produto Produo PROD1_PRD_XXYYZZ Todos os itens da Aps testes da verso (realizados baseline desenvolvimento de pela prpria equipe de
desenvolvimento)
103
Baseline
Item de configurao Critrio de entrada na baseline Documento funcional Aps testes da verso (realizados pela prpria equipe de
desenvolvimento)
Tabela 7-2 Resumo das baselines definidas para o produto 1
A configurao das ferramentas de gerncia de configurao foi uma atividade bastante complexa para a fbrica, pois durante a implantao do processo sentiu-se a necessidade de migrao da ferramenta de controle de verses para o produto 1. A fbrica utilizava o Microsoft Visual Source Safe (VSS), e, devido dificuldade de se gerenciar branches e realizar merges atividades vitais para a implantao do processo junto equipe de desenvolvimento, a fbrica optou pelo uso do Concurrent Version System (CVS) com a interface-cliente WinCVS, que supriam as necessidades da organizao. Juntamente com esta mudana de ferramenta, veio a necessidade de reorganizar a estrutura de diretrios dos itens de configurao do produto, visto que no VSS no havia uma estruturao clara destes itens. Juntamente com a estruturao de diretrios, foi definida a sistemtica de trabalho no repositrio, que ficou assim: Todas as evolues do produto (projetos de novos desenvolvimentos) seriam realizadas na linha principal do produto (chamada de main line). A cada verso liberada para o cliente (mudana no Major Release Number ou no Feature Release Number), era criado um branch para a realizao das correes e liberao de patches (mudana no Minor Release Number).
A fbrica j usava a ferramenta Eztrack para o controle de mudanas. Nela eram reportados todas as solicitaes de mudana, tanto pela prpria organizao como tambm pelos clientes da empresa. Durante a implantao do processo, a ferramenta foi mantida e foi definido para a fbrica que, nos procedimentos de check-in dos itens de configurao no repositrio, os comentrios deveriam sempre conter o nmero e nome do requisito funcional que estava sendo atendido ou o nmero da CR do Eztrack que estava sendo corrigida pelo item. Nos casos de correes para liberao de patches, era obrigatria a realizao de merge da correo realizada no branch para a main line e a documentao desse merge fazendo referncia CR.
104
Como o produto 1 j possua 3 verses distribudas em clientes at o momento da implantao do processo, foi necessrio recriar no CVS as baselines de produo de todas as verses e seus patches mais recentes, adequando-os nova estrutura de diretrios definida durante a institucionalizao. Desta forma, a fbrica ficou pronta para atender os clientes de verses antigas e gerar novas verses do produto 1 da mesma maneira. Outra ferramenta de gerncia de configurao que sofreu reestruturao foi a de controle de mudanas. At a implantao do processo, no havia um fluxo de controle de mudanas bem definido na fbrica, alm de no haver uma distino clara sobre melhorias e erros reportados pelos clientes. A ferramenta EzTrack, apesar de permitir a configurao dos possveis status de uma solicitao de mudana (CR), no possua restries quanto s mudanas de status, dando liberdade total aos usurios da ferramenta para definirem seus prprios fluxos. Como at o momento da implantao no se cogitou a mudana desta ferramenta, o fluxo de controle de mudanas foi definido (ser detalhado na seo 7.3.1.5) e foi ministrado um treinamento para os usurios da ferramenta na organizao sobre como e quando mudar o status de uma CR. Foram definidos templates de preenchimento da CR em todos os status, para serem avaliados pelo gerente de configurao em suas auditorias de baselines. Esta ferramenta est em processo de descontinuao na empresa, e est sendo substituda pelo Mantis. Como este processo no est concludo ainda, no entrar no detalhamento do estudo de caso para este produto. Para a elaborao do plano de gerncia de configurao, foi criado um template em Excel para o produto, contendo as informaes dos itens de configurao, das baselines, das ferramentas, e uma aba para cada projeto de novo desenvolvimento do produto. Desta maneira, as informaes ficavam concentradas em um nico lugar, visto que o plano no era alterado com freqncia dentro da fbrica. Para o projeto 1-A, como ele j tinha sido iniciado em 2004, antes mesmo das definies dos processos para a fbrica, foi definido em reunio com a gerncia snior que apenas as duas ltimas fases deste projeto seguiriam o processo definido. Desta forma, foi criada uma aba para o projeto 1-A, contemplando apenas os artefatos que fariam parte destas fases. J o projeto 1-B, por ser de manuteno do produto, no demandou a criao de uma aba no plano de gerncia de configurao, pois todas as informaes sobre as manutenes evolutivas e corretivas do produto seriam tratadas de uma mesma maneira para todos os projetos de manuteno da fbrica, sempre orientados ao planejamento de escopo da verso, responsabilidade do gerente de produto.
105
O plano de gerncia de configurao no foi conciliado com os demais planos previstos para a fbrica, pois a deficincia na execuo das prticas de planejamento de projetos comprometeu a aprovao formal do plano de gerncia de configurao. Os planos de projeto e de produto no estavam finalizados, o que comprometia a consistncia com o plano de gerncia de configurao. Tanto o plano de gerncia de configurao como os treinamentos, templates e guias foram armazenados no repositrio. 7.3.1.2. Subprocesso 2: Estabelecer baselines Para formalizar o estabelecimento das baselines definidas para o produto 1, foi criada na ferramenta de controle de mudanas uma rea chamada CM para submisso de CRs de estabelecimento de baseline e liberao de baselines, que so as verses ou patches (a serem discutidos na prxima seo). Desta forma, a fbrica concentrou as evidncias das solicitaes de estabelecimento de baseline em um s lugar. Para o projeto 1-A ser atendido, foram necessrias 3 solicitaes de estabelecimento de baseline. Porm, nem todas foram feitas pelo gerente do produto, por causa de sua sobrecarga gerenciando outros 2 produtos da empresa. Isto ficou evidenciado nas auditorias de qualidade, ficando definido que haveria flexibilidade na solicitao de estabelecimento de baseline, podendo ser feita pelo analista snior da equipe alocada no produto. J o projeto 1B, por ser de manuteno, foi atendido atravs de 07 solicitaes de estabelecimento de baseline ao longo do ano de 2006 at o momento atual. Durante o estabelecimento de cada baseline, foram realizadas auditorias conforme previsto no processo. Foram realizadas 31 auditorias de estabelecimento de baseline desde 2005, sendo 28 para liberao posterior de patches e 03 para liberao de verses. O maior problema identificado nas auditorias era a falta de aprovao formal dos documentos de requisitos pela fbrica, critrio definido para sua entrada na baseline de desenvolvimento. Devido aos problemas de gesto de requisitos enfrentados pela fbrica, no momento das auditorias de estabelecimento de baseline, os documentos de requisitos no estavam aprovados, mas o cdigo-fonte j atendia a estes artefatos, ou seja, a implementao dos requisitos j estava realizada, mesmo como os documentos ainda no aprovados formalmente. Era necessrio resgatar e-mails de aprovao informal do artefato para que a baseline pudesse ser estabelecida, pois deveria haver a evidncia de que os responsveis pela aprovao tinham lido os documentos e, mesmo sem seguir o processo de gerncia de requisitos definido para a
106
organizao, tinham autorizado a implementao do requisito. Mas este problema persistiu em praticamente todas as auditorias de estabelecimento de baseline. Quando uma baseline a ser estabelecida continha tambm solicitaes de mudana, a auditoria verificava se as CRs continham a anlise de impacto registrada como solicitado pelo processo, e se possuam sempre um responsvel para test-las, mesmo que fosse algum da equipe de desenvolvimento, pois o produto 1 no possua uma equipe de certificao. Alm disso, se a baseline a ser estabelecida estivesse relacionada a um patch do produto 1, o gerente de configurao verificava se o desenvolvedor realizou o merge da correo na linha principal. Todas as no-conformidades detectadas durante a auditoria foram registradas como desvios de gerncia de configurao na rea CM do Eztrack, e as baselines s eram estabelecidas quando todos os desvios estivessem sanados. Para o estabelecimento da baseline no repositrio, o gerente de configurao utilizou as tags (tambm conhecidas como rtulos) para identificar as baselines de desenvolvimento estabelecidas. Ele passava a tag com o nome da baseline (seguindo o padro definido) em todos os artefatos que faziam parte desta baseline. Dessa forma, os desenvolvedores poderiam recuperar facilmente uma baseline a partir da nomenclatura definida como padro e usada nas tags. Os checklists do processo proposto foram adaptados para o tipo de baseline definido pela fbrica, e foram armazenados no repositrio do produto a cada auditoria realizada. A notificao do estabelecimento de baseline era realizada por e-mail para a equipe de desenvolvimento, o gerente do produto e os gerentes dos projetos atendidos pela baseline. Durante o estabelecimento das baselines, foram criados e armazenados no repositrio os release notes das verses e patches que seriam testados at sua liberao definitiva. Cada release notes continha os requisitos atendidos pela verso ou patch e as solicitaes de mudana atendidas. 7.3.1.3. Subprocesso 3: Liberar Verses ou patches A liberao de verses ou patches seguiu a mesma linha do estabelecimento de baselines, possuindo na rea CM um tipo de solicitao de mudana chamado Liberao de baseline. Assim como no estabelecimento de baseline, o gerente do produto nem sempre solicitou a liberao das baselines, compartilhando esta atividade com o analista snior da equipe. Nas primeiras auditorias de liberao de baseline, o gerente de configurao identificou problemas na atualizao do documento funcional, o que gerou a abertura de diversas CRs de desvio de gerncia de configurao. Esses problemas foram bastante
107
reduzidos ao longo da implantao do processo para a equipe do produto 1, acontecendo raramente desvios relacionados ao documento funcional. Outro problema identificado nas auditorias era a falta de feedback em relao aos testes da verso ou patch. Nem sempre os responsveis por testar a verso enviavam e-mails comunicando o resultado dos testes realizados, nem alteravam o status das CRs atendidas pela verso ou patch, o que atrasava bastante o trabalho de gerente de configurao na liberao da baseline. Da mesma forma que no estabelecimento das baselines, o gerente de configurao usou as tags como meio de delimitar a baseline liberada para o cliente e enviou e-mails para divulgar a liberao da verso aos membros da equipe de desenvolvimento, ao gerente de produto e aos gerentes de projeto interessados na verso. 7.3.1.4. Subprocesso 4: Controlar Mudanas O registro das solicitaes de mudana eram realizados principalmente pela equipe de suporte da empresa, fora da fbrica, e pelos clientes do produto 1, que tinham acesso ao Eztrack. No Eztrack, havia um template para orient-los no preenchimento das informaes que serviriam como subsdio CR registrada. A maior dificuldade enfrentada pela fbrica durante a execuo deste subprocesso foi a concentrao das atividades de anlise de impacto sobre o gerente do produto. Mais uma vez foi detectada a sobrecarga do gerente de produto, o que levou fbrica a flexibilizar novamente a anlise de impacto. Isso beneficiou bastante a equipe do produto 1, pois os analistas da equipe detinham o mesmo nvel de conhecimento que o gerente de produto, e como eram tcnicos, podiam muitas vezes realizar uma anlise de impacto mais detalhada sobre cada solicitao de mudana. Para o projeto 1-A, o gerente do projeto era acionado sempre que necessrio durante as avaliaes de impacto. Para o projeto 1-B, a equipe comandada pelo analista snior realizava esta atividade. As anlises de impacto eram todas registradas no prprio Eztrack para facilitar o rastreamento da CR, e a auditoria do gerente de configurao. Nela eram informados os participantes da anlise de impacto e a deciso tomada, e a CR era atribuda ao desenvolvedor responsvel pela correo. Se a CR estivesse relacionada a um erro de uma verso anterior, as correes eram realizadas em um branch da verso, conforme definido no planejamento da gerncia de configurao. Aps o trmino das correes, o analista snior procedia com a solicitao de estabelecimento de baseline, desencadeando as atividades do subprocesso 2. Durante as auditorias de qualidade realizadas com a equipe do produto 1, foi citado que a definio de um fluxo de controle de mudanas foi uma melhoria perceptvel trazida
108
pelo processo de gerncia de configurao, visto que antes da institucionalizao no havia uma formalizao dos papis e responsabilidades dentro do fluxo de controle de mudanas dentro da fbrica. 7.3.1.5. Subprocesso 5: Acompanhar gerncia de configurao Ao longo da implantao do processo de gerncia de configurao na fbrica, principalmente nos seis primeiros meses da implantao do processo, a atuao do gerente de configurao foi bastante incisiva na equipe do produto 1, tanto em relao orientao do uso do sistema de configurao, como na execuo do processo implantado. Para o acompanhamento das atividades de gerncia de configurao, as mtricas sugeridas no processo foram adaptadas para a fbrica, ajustando os procedimentos de coleta para a infra-estrutura montada. No entanto, ao longo da execuo do processo, apenas uma mtrica foi coletada como previsto: backlog de gerncia de configurao/ms. A utilizao da mtrica de nmero de verses e patches planejados x liberados/por ms no foi bem sucedida, pois no havia a base do planejamento para confrontar com a execuo. A Figura 7-2 mostra os dados coletados apenas para os releases liberados pela fbrica ao longo dos meses, sem exibir o planejamento, que no existia formalmente dentro da fbrica.
Releases planejados x liberados
Nmero de releases 8 6 4 2 0
ou t/0 5 no v/ 05 de z/ 05 ja n/ 06 fe v/ 06 m ar /0 6 ab r /0 6 m ai /0 6 ju n/ 06 ju l/0 6 ag o/ 06 se t/0 6 ou t/0 no 6 v/ 06 de z/ 06
releases planejados releases liberados
Ms
Figura 7-2 Apresentao da mtrica Releases planejados x liberados
A coleta da mtrica de esforo planejado x realizado das atividades de gerncia de configurao tambm no foi bem sucedida, pois a fbrica no possua at o fim de 2006 uma sistemtica formal de reportagem de atividades, o que possibilitava o no registro de
109
atividades do gerente de configurao, como apresenta a Figura 7-3. Nos dois primeiros meses, a alocao prevista de gerente de configurao esteve bastante reduzida porque este papel era compartilhado com o de engenheiro de qualidade, atividade principal da autora. Nas reunies realizadas com a gerncia snior, foi exposta a necessidade urgente de contratao de um gerente de configurao dedicado, o que aconteceu ainda em novembro de 2005.
Esforo planejado x realizado de CM
200,00 150,00 Horas 100,00 50,00 0,00
ou t/0 no 5 v/ 05 de z/ 05 ja n/ 06 fe v/ 06 m ar /0 6 ab r /0 6 m ai /0 6 ju n/ 06 ju l/0 6 ag o/ 06 se t/0 6 ou t/0 6 no v/ 06 de z/ 06
Esforo Planejado Esforo Realizado
ms
Figura 7-3 Apresentao da mtrica Esforo planejado x realizado de CM
Analisando o grfico da Figura 7-3, verificou-se que a visibilidade sobre as atividades do gerente de configurao era praticamente inexistente, no podendo haver uma avaliao por parte da gerncia snior sobre o esforo do gerente de configurao. Isso ocorria por no haver uma sistemtica de reportagem de atividades na fbrica. Entre outubro e novembro de 2005 os dados eram passiveis de anlise por causa do compartilhamento do engenheiro de qualidade, mas a partir de dezembro, por no haver um procedimento formalizado de reportagem nem a cobrana pelo registro das atividades, o esforo do gerente de configurao no poderia ser medido e nenhuma ao em torno disso poderia ser tomada. Com a percepo da necessidade desta sistemtica, foi institucionalizada na organizao inteira (incluindo a fbrica) a obrigatoriedade de reportagem de atividades, visto que a empresa passou a sentir necessidade de entender seus custos, no qual estavam includos os custos com a gerncia de configurao. Assim, em setembro de 2006 foi oficializado o Sistema de Gerenciamento de Projetos (SGP), uma ferramenta desenvolvida internamente, como o meio de reportagem das atividades, e o rigor para as reportagens foi crescendo desde ento. Pelo grfico apresentado, a partir de setembro foi possvel visualizar novamente a relao entre esforo previsto e realizado do gerente de configurao.
110
Os resultados apresentados pela mtrica de backlog de gerncia de configurao/ms, conforme apresentado na Figura 7-4, apresentaram as seguintes informaes: Durante os dois primeiros meses, houve uma alta incidncia de issues, porque foi o incio da implantao do processo de gerncia de configurao na fbrica, onde a equipe estava lidando com uma nova ferramenta de controle de verses e uma nova maneira de usar a ferramenta de controle de mudanas. Durante o ms de dezembro, houve apenas 2 liberaes de verso para o produto 1, mas que no geraram nenhuma abertura de issues de auditoria. Porm, as issues pendentes no foram fechadas. Entre fevereiro e abril de 2006, o ndice de CRs aumentou, porque coincidiu com a mudana da ferramenta de controle de verses, o que demandou novo treinamento para a equipe e mudanas na forma de trabalho de todos. Algumas CRs antigas foram fechadas e outras permaneceram abertas ao longo do ano.
Backlog de CM / ms
14 12 10 8 6 4 2 0
out/05 nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06 out/06 nov/06 dez/06
Nmero de CR's
CR's abertas CR's fechadas backlog
Ms
Figura 7-4 Apresentao da mtrica Backlog de CM/ms
importante ressaltar que a no cobrana do fechamento das issues pendentes fez com que o backlog permanecesse constante durante o ano. Ao analisar as issues pendentes, foi verificado que elas poderiam ser fechadas por estarem vencidas, ou seja, j no havia mais necessidade de se realizar a ao corretiva do desvio encontrado, pois no agregaria mais valor fbrica.
111
7.3.1.6. Auditorias de qualidade no processo Ao longo da institucionalizao do processo de gerncia de configurao, a fbrica contou com a realizao das auditorias peridicas de qualidade, executadas pelo engenheiro de qualidade, e das auditorias externas, realizadas por consultores de qualidade do Centro de Estudos Avanados do Recife (CESAR) e pela Integrated System Diagnostics Brasil (ISD Brasil). Ao todo, foram realizadas ao longo da institucionalizao 02 auditorias externas, que avaliaram o escopo da melhoria de processos, no qual o produto 1 estava includo. Como a fbrica estava trabalhando com a institucionalizao dos processos do nvel 2 de maturidade, todas as reas de processo foram avaliadas. Apesar de o escopo ser maior que o objeto deste estudo de caso, o mesmo processo foi implantado em todos os produtos, e o resultado apresentado mostra um painel de aderncia do processo organizao. Na 1 avaliao externa, realizada no segundo semestre de 2005, o foco foi identificar a definio dos processos e o incio de sua institucionalizao. A avaliao no possuiu um nvel de detalhamento requerido em avaliaes oficiais do CMMI. Foram definidos os seguintes critrios para avaliao do processo: Definio de Processos: o quanto a prtica est documentada em relao a como deve ser realizada. Possveis valores: TD (Totalmente Definido), LD (Largamente Definido), PD (Parcialmente Definido) e ND (No Definido) Institucionalizao: o quanto a prtica est em uso na organizao. Possveis valores: TI (Totalmente Implementado), LI (Largamente Implementado), PI (Parcialmente Implementado) e NI (No Implementado).
Conforme apresenta a Figura 7-5, foi observado que a definio do processo estava bastante alinhada ao nvel 2 do CMMI, mas que a fbrica precisaria despender mais esforos para a institucionalizao. De fato, ainda no incio da institucionalizao, o processo estava com muitas falhas de implantao, mas com a ajuda da consultoria foi possvel realizar os ajustes necessrios e obter um processo eficiente a alinhado ao nvel 2 do CMMI.
112
Avaliao Externa do Processo de CM
100% 80%
TD / TI LD / LI
60%
PD / PI
40%
ND /NI
20% 0%
Definio de processos Institucionalizacao prticas genricas Institucionalizacao prticas especficas
Figura 7-5 Resultado da 1 auditoria externa do processo de Gerncia de Configurao
A 2 auditoria externa foi realizada em abril de 2006, ainda durante o processo de consultoria externa. Desta vez, os consultores definiram outros critrios de avaliao: Baixo risco: Artefatos diretos presentes para os projetos avaliados, sem gaps aparentes Risco mdio: Existncia de gaps nos artefatos para um ou mais projetos, desalinhamento com as entrevistas, prticas implementadas recentemente ou ainda no executadas Alto risco: Artefatos no existentes ou no adequados para todos os projetos. Informao Necessria: No foi possvel analisar a prtica por falta de informaes ou por falta de tempo. Nesta auditoria, nem todas as prticas genricas foram avaliadas, da a necessidade de se criar a categoria Informao necessria. A prioridade dada em funo do tempo de auditoria foi para as prticas genricas GP 2.2, 2.5, 2.8, 2.9 e 2.10. Alm disso, os processos no foram avaliados em relao definio.
113
Avaliao Externa do Processo de CM
100% 80% 60% 40% 20% 0%

Institucionalizao prticas genricas Institucionalizao prticas especficas
IN AR MR BR
Figura 7-6 Resultado da 2 auditoria externa do Processo de Gerncia de Configurao
Na 2 auditoria, as questes vinculadas s prticas genricas pesaram no diagnstico final do processo de gerncia de configurao. Mesmo havendo um conjunto de prticas genricas no avaliadas, a institucionalizao do processo ainda estava muito aqum de uma avaliao formal. Durante as avaliaes internas de qualidade, realizadas pela autora, muitos itens evidenciados nas avaliaes externas j eram de conhecimento da alta direo, pois foram identificados anteriormente. Porm, as pessoas entrevistadas durante as avaliaes sempre relatavam os benefcios trazidos pelo processo, mesmo possuindo ainda muitas deficincias de institucionalizao, pois a existncia do controle dos itens de configurao, que antes no era visualizado por eles, trazia uma maior tranqilidade ao desenvolvimento do produto 1 e demais produtos avaliados. A equipe evidenciou os benefcios trazidos pelo controle de mudanas, que passou a ser padronizado com a utilizao adequada do Eztrack, alm da criao das baselines, que permitiram equipe obter um acesso rpido a qualquer verso do sistema sob a gerncia de configurao definida para os produtos.
Esta seo apresentou o relato do estudo de caso da aplicao do processo proposto de gerncia de configurao em uma fbrica orientada a produto. Atravs do estudo de caso foi possvel observar que os benefcios trazidos pela implantao do processo foram percebidos pela organizao. Porm, os problemas na gesto dos produtos e projetos afetaram o
114
desempenho do processo na fbrica, pois muitas atividades previstas no foram realizadas devido gesto ineficiente na fbrica. O estudo de caso foi apoiado pela alta direo da empresa, e contou com o empenho e dedicao de todos na fbrica, mesmo concorrendo muitas vezes com prazos j definidos e atividades consideradas em alguns momentos prioritrias em relao s atividades de institucionalizao do processo. Ao longo da execuo do estudo de caso, foi necessrio realizar diversos ajustes no processo proposto, gerando diversas verses do processo ao longo da sua implantao. importante ressaltar que o processo proposto pode e deve ser evoludo, visto que ainda existiam pontos em aberto nas avaliaes de qualidade realizadas.
115
Captulo 8 - Concluses
Captulo
8. Concluses
Este captulo apresenta as concluses sobre o trabalho realizado para esta dissertao. Nele so identificados trabalhos relacionados, e oportunidades de desenvolvimento futuro em relao ao processo proposto.
116
Este trabalho apresentou uma proposta de processo de gerncia de configurao alinhado ao nvel 2 de maturidade de capacidade do CMMI, com o foco direcionado s fbricas de software orientadas a produto. A motivao para a execuo deste trabalho foi a dificuldade encontrada em conciliar a gerncia de configurao de um produto e as necessidades especficas de configurao para os projetos que manipulam o produto. Este conflito uma caracterstica presente nas fbricas de software orientadas a produto, que possuem tambm as dificuldades relacionadas gesto de requisitos e de projetos. Nesta estrutura organizacional, a gerncia de configurao torna-se imprescindvel, pois a gesto das baselines de projeto e de produtos, assim como o controle de mudanas, so aspectos crticos para o funcionamento eficiente da fabrica e para a garantia de um controle da configurao dos produtos gerados por este tipo de fabrica de software.
8.1. Principais contribuies
O processo proposto foi desenhado com o objetivo de promover uma maior integrao entre os projetos que afetam um produto dentro de uma fbrica de software, tanto os de novo desenvolvimento como os de manuteno. Atravs de uma gesto direcionada ao escopo do produto, a gesto de configurao na fbrica passa a conciliar os itens de configurao dos projetos e do produto, e os integra atravs das baselines do produto. importante ressaltar a importncia do alinhamento do processo proposto ao nvel 2 de maturidade e capacidade CMMI para a rea de processo Gerncia de Configurao. A incorporao das prticas genricas e especficas do CMMI tornou o processo proposto mais robusto, com a formalizao de atividades crticas da gerncia de configurao, como o controle de verses e mudanas. O estudo de caso realizado por este trabalho funcionou tambm como um relato de experincia, pois a autora j atuou como gerente de configurao e h 03 anos atua diretamente na definio e implantao de processos em uma fbrica de software. Atravs do estudo de caso aplicado em uma fbrica de software orientada a produto, foi possvel evidenciar os principais benefcios trazidos pelo processo organizao: Maior controle sobre os itens de configurao, atravs da documentao dos mesmos em um plano de gerncia de configurao e monitoramento realizado pelo gerente de configurao.
117
Padronizao do controle de mudanas, atravs da utilizao de ferramentas automatizadas para apoiar o processo, auxiliadas pelos procedimentos operacionais de gesto de mudanas definidos para a organizao.
Acesso facilitado s verses do produto ao longo do tempo, obtido atravs do estabelecimento de baselines e liberao de verses e patches pelo gerente de configurao, conforme definido no processo.
8.2. Dificuldades encontradas
Nesta seo sero apresentadas as principais dificuldades encontradas durante a realizao deste trabalho e seus impactos no resultado final. 8.2.1. Complexidade do processo inicial A definio de um processo de desenvolvimento para uma organizao no uma tarefa de fcil execuo. Envolve o levantamento do contexto atual da organizao e das suas necessidades, para que seja possvel adaptar um modelo de processos realidade da organizao. O escopo inicial deste trabalho envolvia a definio de processos para todas as reas de processo do nvel 2 de maturidade do CMMI para fbricas de software orientadas a produto, excetuando a Gerncia de Subcontratao. Porm, devido ao alto volume de trabalho e complexidade inerente definio de processos, no foi possvel contemplar todas as reas de processo. Em virtude deste cenrio, o fato de fbricas orientadas a produto demandarem um alto suporte de gerncia de configurao, a experincia da autora nas atividades de gerncia de configurao em fbricas orientadas a produto, esta rea de processo foi escolhida como foco do trabalho, o que resultou no processo proposto e resultados apresentados no estudo de caso. 8.2.2. Bibliografia escassa sobe fbricas orientadas a produto Apesar de o tema fbricas de software possuir uma vasta bibliografia disponvel para estudo e pesquisa, a especializao deste tema, ou seja, a orientao a produtos, no possui muito material acessvel. Variaes do tema, como linhas de produto de softwares, possuem uma literatura vasta para pesquisa, mas nem sempre associada ao tema das fbricas de software, pois uma SPL no precisa estar vinculada a uma fbrica. Autores como [Fernandes-04] e [Tachizawa-97] abordam esta estrutura de fbrica, o que serviu como ponto
118
de partida para o entendimento dos conceitos de fbrica de software e suas diversas formas de estruturao. 8.2.3. Estudo de caso aplicado em uma fbrica de software real O estudo de caso deste trabalho foi realizado em uma fbrica de software real, com a estrutura organizacional orientada a produto, o que tornou mais enriquecedora a experincia de definio do processo proposto. No entanto, os conflitos entre as atividades vinculadas ao processo e os compromissos assumidos pela fbrica perante os seus clientes internos (gerentes de projeto), muitas vezes comprometeram a execuo correta do processo, visto que os compromissos tinham prioridade alta dentro da organizao. A introduo do processo na fbrica trouxe para estes clientes a sensao de demora no cumprimento de atividades antes de rpida execuo. Nem sempre a explicao de que antigamente as atividades eram executadas ad-hoc e que durante a implantao do processo passaram a ser executadas de forma estruturada e controlada era aceita com facilidade para justificar algum atraso no projeto.
8.3. Trabalhos relacionados
Ao longo destes anos, diversos trabalhos tm sido realizados com o propsito de melhorar processos nas organizaes, passando por todas as reas de processo abordadas no CMMI. [Feitosa-03] props um processo de medio e anlise para alinhado ao nvel 3 de capacidade do CMMI. Este trabalho auxiliou a autora na concepo das atividades de verificao do processo proposto e das auditorias de qualidade, atravs das definies das mtricas para o processo de gerncia de configurao. O artigo publicado por [Neto-03] aborda a definio de processos enxutos para uma fbrica de software com produo em larga escala, propondo a automatizao de todo o processo produtivo da fbrica, usando os conceitos de fbricas japonesas (Sistema Toyota de Produo) e de produo enxuta. Este artigo bastante interessante, pois aborda as fbricas de software orientadas a produto e abre o leque de possibilidade de otimizao do processo atual usando os dois princpios mencionados acima, visto que o processo proposto no est direcionado a um ciclo de desenvolvimento de software especfico.
119
8.4. Trabalhos futuros
A evoluo deste trabalho prev a integrao do processo proposto com as demais reas de processo do nvel 2 de maturidade do CMMI, permanecendo com o foco nas fbricas de software orientadas a produto. A definio e implantao dos processos restantes so fundamentais para uma comprovao maior da eficincia do processo proposto, visto que algumas atividades no foram bem executadas no estudo de caso devido deficincia de gesto da fbrica. Outro trabalho importante de evoluo seria a insero definitiva de ferramentas de apoio ao processo nas atividades do processo, o que facilitaria ainda mais a implantao do mesmo em uma fbrica de software. Hoje o processo sugere o uso de ferramentas, mas no obrigatrio us-las. Dependendo de como o processo seja implantado, ele pode se tornar lento, o que comprometeria o sucesso da implantao. Se passarmos a inserir obrigatoriamente o uso de algumas ferramentas de apoio ao processo, a lentido no ser mais uma possibilidade durante a implantao do processo. O ajuste do processo proposto para as linhas de produto de software um passo importante para a evoluo deste trabalho, visto que essa rea de trabalho demanda uma gerncia de configurao ainda mais detalhada que a deste trabalho, pois alm de controlar os produtos com suas manutenes e novos desenvolvimentos, o gerente de configurao deve se preocupar com os ativos, ou seja, os componentes que so considerados o core da famlia de produtos e que precisam ser evoludos e corrigidos assim como feito com os produtos.
A gerncia de configurao uma atividade de extrema importncia para o desenvolvimento de projetos e produtos em uma organizao. A cada dia surgem novas ferramentas, novos padres e procedimentos para apoiar o desenvolvimento e garantir o controle de verses e a gesto de mudanas dentro da organizao. Quando inclumos as novas estruturas organizacionais, como as fbricas de software orientadas a produto, este cenrio se torna ainda mais complexo, porm interessante, pois lana o desafio de conciliar as necessidades dos projetos da fbrica com a gesto do produto em si, o que afeta por completo a gerncia de configurao. Novas estruturas organizacionais surgiro, e com elas o aprimoramento da gerncia de configurao, vinculada a modelos de qualidade, procurando garantir o controle da
120
configurao dos projetos e produtos das empresas com o menor impacto possvel nos compromissos da organizao junto aos clientes.
121
Referncias
Referncias
Aaen-97
Aaen, Ivan; Botcher, Peter; Mathiassen, Lars. The Software Factory: Contributions and Illusions. In: Proceedings of the Twentieth Information Systems Research Seminar in Scandinavia, Oslo, 1997.
Aberdeen-07
Aberdeen Group, Inc. The Configuration Management Benchmark Report Formalizing and Extending CM to Drive Quality. Massachusetts, February 2007.
Albuquerque-05
Carlos A. M. Qualidade gil de Software. Centro de Informtica, Universidade Federal de Pernambuco, dissertao de mestrado, 2005.
Basili-92
Basili, Victor R. The Experimental Paradigm in Software Engineering. Institute for Advance Computer Studies and Department of Computer Science, University of Maryland, 1992.
Chrissis-03
Chrissis, Maty B.; Konrad, Mike; Shrum, Sandy. CMMI: Guidelines for Process Integration and Product Improvement. Pearson Education, 2003.
Clements-02
Clements, Paul; Northrop, Linda. Software Product Lines: Practices and Patterns. Reading, MA: Addison Wesley, 2002.
Cohen-02
Cohen, Sholom. Product Line State of the Practice Report. (CMU/SEI2002-TN-017). Software Engineering Institute, Carnegie Mellon
University, September 2002.

Cusumano-04
Cusumano, Michael. The Factory Approach to Software Development: A Strategic Overview. Sloan School of Management, Massachusetts Institute of Technology, 1989. http://hdl.handle.net/1721.1/2281, ltimo acesso agosto/2004.
Dart-91
Dart, Susan. Concepts in configuration management systems. In: Proceedings of the 3rd international workshop on Software configuration management in Trondheim, Norway, 1991.
Estublier-00
Esublier, Jacky. Software Configuration Management: A Roadmap. In: Proceedings of the Conference of The Future of Software Engineering, p.279-289, June 04-11. Limerick, Ireland, 2000. http://doi.acm.org/10.1145/336512.336576, ltimo acesso junho/2007.
Farah-04
Farah, Joe. Changes: The Crossroads Between Project CM and Product CM. CM Crossroads, October, 2004.
122
Referncias
http://www.cmcrossroads.com/content/view/6727/238/, ltimo acesso abril/2007.

Feitosa-04
Feitosa, Cibele. Definio de um Processo de Medio e Anlise com base nos Requisitos do CMMI. Centro de Informtica, Universidade Federal de Pernambuco, dissertao de mestrado, 2004.
Fernandes-04
Fernandes, Aguinaldo A.; Teixeira, Descartes de S.. Fbricas de Software: Implantao e Gesto de Operaes. So Paulo Atlas, 2004.
Guess-98
Guess, Vince. Whats New in CM? Institute of Configuration Management Scottsdale, 1998. http://www.icmhq.com/newsviews/Whats%20New%20in%20CM.html, ltimo acesso - junho/2007.
Ibrahim-95
Ibrahim, Rosalind L.; Hirmanpour, Iraj. The Subject Matter of Process Improvement: A Topic and Reference Source for Software Engineering Educators and Trainers (CMU/SEI-95TR-003). Software Engineering Institute, Carnegie Mellon University, May, 1995.
IEEE-90
IEEE Standard Glossary for Software Engineering,IEEE-STD-610.12, 1990.
Junk-00
Junk, William S.. The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects. Moscow, 2000.
Kasse-00
Kasse, Tim; McQuaid, Patricia A. In: Software Quality Professional. American Society for Quality. September, 2000.
http://www.asq.org/pub/sqp/past/vol2_issue4/mcquaid.html, ltimo acesso junho/2007.

Kotonya-98
Kotonya, Gerals; Sommerville, Ian. Requirements Engineering: process and techniques. John Wiley & Sons Ltd, 1998.
MCT-06
MCT Ministrio da Cincia e Tecnologia. Qualificao CMM e CMMI no Brasil. Agosto 2006
Lim-99
Lim, Ngang-Kwang, Ang, S. K. James, and Pavri, F.N. Diffusing Softwarebased Technologies with a Software Factory Approach for Software Development: A Theoretical Framework. Department of Decision Sciences, Faculty of Business Administration, National University of Singapore, Republic of Singapore, 1999.
Neto-03
Neto, Antnio A, SantAnna, Nilson. A Gesto de Processos na Fbrica de
123
Referncias
Software. Instituto Tecnolgico de Aeronutica, 2003.

Paulk-93
Paulk, Mark C.; Curtis, Bill; Chrissis, Mary Beth; and Weber, Charles V. Capability Maturity Model for Software, Version 1.1 (CMU/SEI-93-TR-24, ADA 263403). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, February 1993.
Phillips-07
Phillips, Mike. Using CMMI with Suppliers The Acquirers Concern. 2005. http://www.sei.cmu.edu/news-at-sei/columns/cmmi-infocus/2005/2/cmmi-in-focus-2005-2.htm, ultimo acesso abril/2007.
Pressman-01
Pressman, Roger. Software Engineering: a practitioners Approach. 6 edio. McGraw-Hill 2001.
SEI028-02
SEI. Capability Maturity Model Integration, Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1) Continuous Representation (CMU/SEI-2002-TR-028). Software Engineering Institute, Carnegie
Mellon University, August 2002.

SEI029-02
SEI. Capability Maturity Model Integration, Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1) Staged Representation Carnegie
(CMU/SEI-2002-TR-029).
Software Engineering
Institute,
Mellon University, August 2002.

SEI034-01
SEI. Appraisal Requirements for CMMI, Version 1.1 (ARC, V1.1). (CMU/SEI-2001-TR-034). Software Engineering Institute, Carnegie
Mellon University, December, 2001.

SEI-01
Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method Definition Document (CMU/SEI-2001-HB-001). Software Engineering Institute, Carnegie Mellon University, December, 2001.
SEI-06
SEI.Process Maturity Profile. CMMI v1.1 SCAMPI v1.1 Class A Appraisal Results. Software Engineering Institute, Carnegie Mellon University, September 2006. http://www.sei.cmu.edu/appraisal-
program/profile/profile.html, ultimo acesso dezembro/2006.

SEI-07
SEI. CMMI Performance Results. Software Engineering Institute, Carnegie Mellon University, September 2005.
http://www.sei.cmu.edu/cmmi/results.html, ltimo acesso abril/2007.

Sommerville-97
Sommerville, Ian; Sawyer, Pete. Requirements Engineering: a good
124
Referncias
practice guide. John Wiley & Sons Ltd, 1997.

Standish-01
The Standish Group International. Extreme CHAOS 2001 February 2001. http://www.vertexlogic.com/processOnline/processData/documents/pdf/ext reme_chaos.pdf, ltimo acesso junho/2006.
Standish-07
Web Site The Standish Group, http://www.standishgroup.com/, ltimo acesso junho/2007.
Standish-95
The
Standish
Group
International.
Chaos
Report
(1994).
http://www.standishgroup.com/sample_research/chaos_1994_1.php, ltimo acesso junho/2007.

Tachizawa-97
Tachizawa, Takeshy; Scaico, Oswaldo. Organizao Flexvel: Qualidade na gesto por processos. So Paulo Atlas, 1997.
125
Anexos
ANEXOS
Aqui so apresentados os anexos da dissertao de mestrado, que servem como material de apoio ao processo proposto nesta dissertao.
126
Anexos
ANEXO A - Checklist de Auditoria de Estabelecimento de Baseline
Responsvel: Baseline: Item Os itens de
<Nome do responsvel> <identificao da baseline>
Data: Status: S/N
<dd/mm/aaaa> APROVADA / REPROVADA Observaes
configurao
esto
sendo
mencionados na solicitao? As nomenclaturas dos itens de configurao esto de acordo com a definio no plano? O documento de requisitos que vai entrar na baseline foi revisado/aprovado? As Solicitaes de Mudana associadas baseline esto com a avaliao de impacto registrada? O cdigo-fonte est compilando? O cdigo-fonte possui nos comentrios de check-in/check-out do repositrio os nmeros das solicitaes de mudana ou documentos de requisitos atendidos? O item de configurao que vai entrar na baseline consta no planejamento de escopo da verso?
127
Anexos
ANEXO B - Checklist de Auditoria de Liberao de Verso ou Patch
Responsvel: Baseline: Item
<Nome do responsvel> <identificao da baseline>
Data: Status: S/N
<dd/mm/aaaa> APROVADA / REPROVADA Observaes
Todos os requisitos implementados foram testados? Ver evidncias Todas as solicitaes de mudana planejadas foram atendidas na verso/patch? Todas as implementaes realizadas constam no planejamento da verso/patch? Todas as Solicitaes de Mudana registradas foram testadas? Esto com o status indicando sucesso nos testes A verso est baseada na ltima baseline de cdigo estabelecida? Para patches: Todas as implementaes realizadas possuem os respectivos merges para a prxima verso do produto?
128
Anexos
ANEXO C Modelo de Release Notes de Verso
Dados da Verso
Nmero: Patches incorporados: Composio: Responsvel:
Caractersticas
Novas funcionalidades: Item
Problemas solucionados:
Item
CR
Solicitaes mudanas atendidas:
de Item
CR
Informaes de Instalao
129
Anexos
ANEXO D Modelo de Release Notes de Patch
Dados do Patch
Nmero: Verso Base:
Patch para:
Responsvel: Prxima Verso:

Solucionar problemas de verses anteriores Atender a solicitao de mudanas em funcionalidades do produto
Composio:
Caractersticas
Evolues sistema: no Item
Problemas solucionados:
Item
CR
Solicitaes mudanas atendidas:
de Item
CR
Informaes de Instalao
130
Anexos
ANEXO E - Checklist de Auditoria Peridica de Gerncia de Configurao
Responsvel: Item
<Nome do responsvel>
Data: S/N Observaes
<dd/mm/aaaa>
O backup do repositrio est sendo feito? O backup do repositrio est sendo testado? O restore do repositrio est funcionando? O repositrio est acessvel? O arquivo do repositrio est ntegro? O espao em disco para o repositrio est suficiente? O backup dos arquivos de dados da ferramenta de controle de mudana est sendo realizado? O restore dos arquivos de dados da ferramenta de controle de mudana est funcionando? A ferramenta de controle de mudana est acessvel? Os arquivos de dados da ferramenta de controle de mudana esto ntegros? As baselines esto ntegras? Existe algum arquivo que no esteja vinculado a um release passado/futuro? As solicitaes de mudana j atendidas esto fechadas e verificadas? Os fluxos das solicitaes de mudana esto sendo seguidos?
131
Anexos
ANEXO F Definio Operacional das Mtricas do Processo Proposto
Mtrica: Descrio:
Verses / patches previstos x liberados / ms Mtrica que recupera o nmero de releases entregues e previstos por ms
Tipo Pblico-alvo: Responsvel pela coleta: Procedimento de coleta:
Por produto Gerente de produto, gerncia snior Gerente de configurao Somar nmero de verses + nmero de patches liberados no ms. (ver nas solicitaes de liberao de verso e patches). Somar nmero de verses + nmero de patches previstos para o ms. (ver nos planejamentos das verses).
Periodicidade da coleta: Armazenamento:
Mensal Armazenar dados em uma planilha excel no repositrio, em cm/metricas/VersoesPatchesPrevistosLiberadosMes.xls
Apresentao resultados:
dos Grfico de 2 colunas onde na linha est cada ms e na coluna est um nmero inteiro. Verificar o desvio entre o planejado e o realizado. Acompanhar o desvio at o limite de 20%. Se ultrapassar, acionar a organizao do planejamento das verses, atentar para a qualidade das entregas.
Procedimento de anlise:
Exemplo de grfico
Nmero de verses/patches 7 6 5 4 3 2 1 0
m ai /0 6 m ar /0 6 no v/ 05 de z/ 05 ag o/ 06 ju n/ 06 ou t/0 5 ja n/ 06 ju l/0 6 ab r/0 6 fe v/ 06 se t/0 6
Verses/patches planejados Verses/patches liberados
Ms
132
Anexos
Mtrica: Descrio:
Backlog de Gerncia de Configurao por ms Nmero de issues de gerncia de configurao abertas e fechadas durante o ms
Pblico-alvo: Tipo Responsvel pela coleta: Procedimento de coleta:
Gerente de Produto Por produto Gerente de configurao Contar o nmero de issues de gerncia de configurao registradas pelo gerente de configurao durante as auditorias de estabelecimento de baseline, liberao de verso e auditorias peridicas de configurao realizadas durante o ms. Contar o nmero de issues de auditorias resolvidas durante o ms.
Critrio de Contagem:
Considerar como issues resolvidas apenas aquelas que foram revisadas pelo gerente de configurao.
Mensal Armazenar dados em uma planilha excel no repositrio, em cm/mtricas/BacklogCMPorMes.xls
dos Grfico de 2 colunas e uma linha onde no eixo X est cada ms e no eixo Y um nmero inteiro. A linha deve ser calculada da seguinte forma: (issues abertas do ms issues fechadas do ms) + (issues abertas do ms anterior issues fechadas do ms anterior).
Verificar o nmero de issues encontradas ao longo de cada ms, e se elas esto sendo fechadas.
Exemplo de grfico
12 N de Issues o. 10 8 6 4 2 0
m ar /0 6 m ai /0 6 n/ 06 n/ 06 de z/ 05 ag o/ 06 no v/ 05 ju l/0 6 5 ab r/0 6 fe v/ 06 se t/0 6 ou t/0 ja ju
Issues abertas Issues fechadas Backlog
Ms
133
Anexos
Mtrica: Descrio:
Atividades de CM planejadas x realizadas Diferena entre o planejamento e execuo das atividades de CM
Tipo Pblico-alvo: Responsvel pela coleta: Procedimento de coleta:
Corporativo Gerncia snior Gerente de configurao Recuperar o total de horas previstas para as atividades de gerncia de configurao nos projetos no ms. Somar o total de horas gastas com a atividade de gerncia de configurao no ms.
Critrio de Contagem:
Considerar apenas as atividades realizadas pelo gerente de configurao na rea. Outros tipos de atividades no devem ser contados.
Mensal Armazenar dados em uma planilha excel no repositrio, em cm/metricas/AtividadesPlanejadasRealizadasCM.xls
dos Grfico de 2 colunas onde no eixo X est cada ms e no eixo Y est o total de horas. Verificar se a diferena entre o esforo planejado e realizado vai alm de 15%. Verificar se o CM no est desempenhando outras atividades que esto tirando tempo de sua alocao de CM.
Exemplo de grfico
300 250 Horas 200 150 100 50 0
m ai /0 6 ja n/ 06 ju n/ 06 m ar /0 6 ju l/0 6 ag o/ 06 ou t/0 5 no v/ 05 de z/ 05 ab r/0 6 fe v/ 06 se t/0 6
Esforo Planejado Esforo Realizado
Ms
134

Mestrado Karine So CmFinal 20070815

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mestrado Karine So CmFinal 20070815

Загружено:

Авторское право:

Доступные форматы

Ps-graduao em Cincia da Computao

Karine Coelho de Amorim Oliveira

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br

Karine Coelho de Amorim Oliveira

Alexandre Marcos Lins Vasconcelos

2. FBRICAS DE SOFTWARE ...................................................................................................... 9

3. VISO GERAL DO CMMI ....................................................................................................... 21

4. ANLISE CRTICA DA GERNCIA DE CONFIGURAO DO NVEL 2 DO CMMI . 37

5. PROPOSTA DO PROCESSO DE GERNCIA DE CONFIGURAO.............................. 48

6. ANLISE CRTICA DO PROCESSO PROPOSTO .............................................................. 80

7. ESTUDO DE CASO .................................................................................................................... 96

8. CONCLUSES ......................................................................................................................... 116

REFERNCIAS ............................................................................................................................ 122

ANEXOS ........................................................................................................................................ 126

Bem-sucedidos Desafiadores Falhos

Figura 1-1 Histrico de resoluo de projetos de empresas americanas 1

Fonte: Standish Group international. Extreme Chaos. [Standish-01]

Reduzir custos de produo

reduzir custos do ciclo de vida do produto

Reduzir custos de desenvolvimento do produto

Melhorar o time to market

Todos os que responderam pesquisa

Figura 1-2 Presses exercidas para a melhoria de gerncia de configurao2

Fonte: Aberdeen Group. The Configuration Management Benchmark Report [Aberdeen-07]

Captulo 2- Fbricas de Software

Captulo 2. Fbricas de Software

Captulo 2- Fbricas de Software

Captulo 2- Fbricas de Software

Captulo 2- Fbricas de Software

Captulo 2- Fbricas de Software

Captulo 2- Fbricas de Software

Figura 2-1 Contexto de fbrica de software como rea de uma organizao

Captulo 2- Fbricas de Software

Figura 2-2 Contexto de fbrica de software como a organizao

Captulo 2- Fbricas de Software

2.2. Estruturao organizacional das Fbricas: produtos versus projetos

Figura 2-3 Representao de desenvolvimento orientado a produto

Captulo 2- Fbricas de Software

Figura 2-4 Representao de desenvolvimento orientado a projeto

Captulo 2- Fbricas de Software

Captulo 2- Fbricas de Software

Captulo 2- Fbricas de Software

Captulo 3- Viso Geral do CMMI

Captulo 3. Viso Geral do CMMI

Captulo 3- Viso Geral do CMMI

Captulo 3- Viso Geral do CMMI

Atualmente, o CMMI compreende 25 reas de processo,

Captulo 3- Viso Geral do CMMI

Figura 3-1 Estrutura do modelo CMMI para a representao contnua

Figura 3-2 Estrutura do modelo CMMI para a representao por estgios

3.2. Nveis de Maturidade e Capacidade do CMMI

Captulo 3- Viso Geral do CMMI

Nvel de Capacidade 0 Incompleto

O processo atende s metas especficas de uma determinada rea de processo.

O processo realizado (nvel 1) planejado, controlado e sua aderncia organizao avaliada.

O processo gerenciado (nvel 2) concebido a partir de processos padres da organizao.

O processo definido (nvel 3) controlado atravs de tcnicas

Nvel de Maturidade 1 Inicial

Os processos de cada projeto so planejados, realizados, medidos e controlados.

Os processos so organizacionais e adaptados para cada projeto, quando necessrio.

Captulo 3- Viso Geral do CMMI

3.3. Evoluo do CMMI no mundo

Captulo 3- Viso Geral do CMMI

Figura 3-3 Distribuio das avaliaes entre organizaes americanas e no americanas