10

Captulo 2

O Processo de Gerncia de Configurao

A Gerncia de Configurao de Software uma tcnica bastante antiga na rea de Software. BUCKLE (1982) reporta que em 1973 Barry Bohem, na TRW, j publicava manuais de Desenvolvimento e Gerncia de Configurao. Em grandes projetos de sistemas da rea de defesa dos EUA sempre foi comum o uso de Gerncia de Configurao de Software, conforme relata o prprio Buckle. A origem destas tcnicas vem das engenharias mais convencionais, como a Engenharia Mecnica, a Industrial e, mais recentemente, a Engenharia Eltrica e Eletrnica, onde o controle dos componentes e de suas verses fundamental para garantir qualidade mnima aos equipamentos e sistemas construdos. No se pode imaginar um novo projeto de um parafuso para um equipamento, sem que a porca correspondente tambm no tenha sido redesenhada. Ou, em um equipamento eletrnico, haja a mudana do sinal de sada de um circuito, sem que o circuito que recebe e processa esta sada, tambm no tenha sido ajustado nova interface. Mais recentemente, na rea de Gerncia de Configurao de Software, tem surgido necessidades especiais no gerenciamento de sistemas de acesso Internet. Scripts de html, imagens, sons, vdeos e outros objetos so colocados em servidores de Web e so alterados com freqncia sem precedentes na histria dos sistemas de software. A palavra chave neste contexto mudana. Segundo BABICH (1986): ... Gerncia de Configurao a arte de identificar, organizar e controlar as
modificaes do software em construo por uma equipe de programao. O objetivo maximizar produtividade pela reduo das falhas.

11

Gerncia de Configurao no deve ser confundida com a fase de Manuteno de Sistemas. As mudanas que se pretende controlar ocorrem durante todo o ciclo de vida de um sistema, inclusive, durante a manuteno. So mudanas de diversas origens, que oportunamente sero explicitadas, mas que ocorrem desde a especificao inicial at a fase de manuteno dos produtos j prontos. No decorrer deste captulo sero formalizados os conceitos que caracterizam o que Gerncia de Configurao de Software.

2.1 O que Gerncia de Configurao

Gerncia de Configurao, segundo BUCKLE (1982), um termo usado para designar um conjunto de tcnicas que, quando aplicadas ao desenvolvimento e manuteno de software, melhorar a qualidade do produto de software, reduzir os custos do ciclo de vida e melhorar a funo gerencial no processo de desenvolvimento e produo. Gerncia de Configurao est fortemente ligado, mas diferente de tcnicas de Garantia de Qualidade e Controle de Qualidade. Podemos visualizar na Figura 2.1, usando Pressman (2001), o relacionamento macro entre as tcnicas envolvidas com qualidade.

Figura 2.1 - Obtendo Qualidade de Software

12

Segundo este modelo, a qualidade ser conseguida pela ao simultnea das seguintes tcnicas: Mtodos de Engenharia de Software Padres e Procedimentos Revises Tcnicas Formais Medies e Mtricas de Software Gerncia de Configurao de Software e Garantia de Qualidade de Software Testes Os Mtodos de Engenharia de Software provm as fundaes sobre as quais a qualidade construda. Mtodos de anlise, projeto e programao atuam na melhoria da qualidade, providenciando tcnicas uniformes e resultados previsveis. Tcnicas de reviso formal, como walkthroughs, ajudam a garantir a qualidade de cada produto produzido como resultados dos passos da engenharia de software. Padres e procedimentos ajudam a garantir uniformidade e a o processo de garantia de qualidade de software refora uma filosofia de qualidade total. Testar o software o ltimo baluarte no qual a qualidade pode ser avaliada e os erros podem ser descobertos. A Gerncia de Configurao, conforme j foi dito anteriormente, desempenha um papel central neste processo todo, porque esta gerncia permitir que cada item de configurao de software seja especificado, projetado, construdo, testado, avaliado, medido e controlado, garantindo a efetiva aplicao das demais tcnicas. Uma plataforma de Gerncia de Configurao assenta-se em quatro bases bem definidas (BUCLE, 1982): Identificao: todos os itens componentes de um produto de software devem ser adequadamente especificados e identificados. A forma destes itens pode variar ao longo das fases e da vida do projeto, desde uma ata de reunio, ou outro documento bastante informal de especificao, at o cdigo fonte implementado e formal;

13

Controle: a habilidade de obter consenso sobre os objetos de software e congelar o estado dos mesmos, s fazendo alteraes, a partir da, com a aquiescncia de uma autoridade competente; este controle de mudanas permite que todos os fatores relevantes e os efeitos possveis da mudana sejam considerados antes de autoriz-la; Acompanhamento do Status: o registro e relato dos dados atuais e histricos de um item de configurao; Verificao: a srie de revises e auditorias para garantir que existe conformidade entre um produto e sua apropriada identificao. As tcnicas bsicas so aplicveis a projetos de todos os tamanhos, e em todos os estgios do desenvolvimento e da produo de software. Entretanto, a forma na qual so aplicadas pode diferir bastante com o tipo do projeto e o tamanho da equipe e com o estgio do ciclo de vida do produto. Um programador profissional ir normalmente aplicar estas tcnicas ao seu trabalho de uma maneira quase automtica. O que queremos conseguir uma maneira de aplicar disciplina semelhante em projetos envolvendo mais de uma pessoa.

2.2 Linhas Base de Configurao de Software

O conceito de linha base (baseline) ajuda a resolver um dos problemas mais crticos do gerenciamento do desenvolvimento e manuteno de produtos de software. Devido baixa visibilidade (PRESSMAN, 2001) do software, conseqncia da falta de caractersticas fsicas como cor, peso, comprimento, largura, etc existe muita dificuldade de caracterizar o trmino do produto e a qualidade embutida no mesmo. A melhor forma que temos para contornar este problema criar linhas base ou marcos de referncia (milestones) que permitem a fixao de pontos de reviso para validao e verificao dos produtos gerados at ento. Nestes momentos, sero realizadas comparaes com os objetivos definidos e, ento, avaliado o grau de obteno dos mesmos.

14

Uma linha base um ponto de referncia no plano de trabalho, cuja obteno pode ser demonstrada satisfatoriamente. Possui as seguintes funes interligadas: Um ponto de progresso mensurvel; Uma base para o desenvolvimento e controle subseqente; Um ponto de medida para avaliar a qualidade e a obteno dos objetivos, antes de passar para a fase seguinte. De acordo com um modelo de ciclo de vida clssico, de referncia para o software a ser desenvolvido, podemos propor bases bem definidas em funo do progresso a ser obtido desde a especificao at o sistema implementado. No incio, temos quase somente documentos sendo gerados e, medida que nos aproximamos das fases finais, o produto vai se materializando em mdulos executveis. Uma lista preliminar pode ser construda, ento:

Enunciado dos requisitos do sistema Especificao total do sistema Especificao detalhada do software Esboo do projeto de software Projeto detalhado do software Verso preliminar do sistema Verso da 1a. liberao do sistema Verso da 2a. liberao do sistema etc.

} }

Documentos

Sistema atual

Para garantir que cada linha base sirva como uma plataforma sobre a qual vamos construir o sistema o final de uma fase e o incio da prxima marcado pela aceitao da linha base. A forma da aceitao pode variar ao longo das fases, mas o critrio de aceitao ser sempre o mesmo: a nova linha base comporta as restries impostas pela linha base anterior, e as linhas base subsequentes e o sistema final? Em cada fase de especificao ou projeto, a aceitao da linha base ser feita por uma reviso da documentao de projeto e, quando o projeto e implementao j se manifestarem em

15

produtos, sero feitos testes de validao. desta forma que existe uma ligao forte entre as tcnicas de revises e testes com a gerncia de configurao. A aceitao de uma linha base significa que o documento ou o cdigo gerado deva ser congelado para formar uma fundao slida para o prximo estgio de desenvolvimento ou operao, conforme apresentado esquematicamente na Figura 2.2. No entanto, como as atividades humanas no so perfeitas, existe sempre a possibilidade de mudar alguma coisa na especificao, projeto ou implementao. A sistemtica de gerncia de configurao deve permitir estas modificaes, usando os mesmos cuidados e sob a mesma autoridade de aprovao, atravs do controle de mudanas, que ser examinado mais adiante.

Figura 2.2 - Linhas base de GCS

A definio precisa e completa das linhas base vai depender de uma srie de fatores, como a metodologia, o modelo de ciclo de vida utilizado e, em ltima instncia, de cada projeto em particular. Ser uma deciso a ser definida dentro do processo de planejamento de projeto. Um aspecto a ser ressaltado a viso do processo de desenvolvimento de sistemas como uma aquisio de conhecimentos sobre o mesmo. Desde as etapas mais iniciais, em que buscamos definir o escopo e especificar as caractersticas relevantes do sistema em desenvolvimento, atravs de diversos modelos, at as fases posteriores em que estamos integrando mdulos j construdos e testados para gerar o sistema final, estamos sempre incorporando conhecimento sobre o sistema, seu ambiente de funcionamento, os usurios, etc. Dentro desta viso, podemos imaginar as linhas base

16

como plataformas que representem os nveis de conhecimento adquirido, do sistema em desenvolvimento, em relao ao grau de detalhe compatvel com a fase em que o projeto se encontra. Imaginando um desenvolvimento de cima para baixo (top-down), quanto mais cedo for a fase, mais geral e abrangente ser o conhecimento adquirido, quanto mais posterior, mais detalhado e profundo ser este conhecimento. Outra forma bastante interessante, apresentada por ARMOUR (2000), ver o desenvolvimento de sistemas como a reduo da ordem de ignorncia que temos sobre o sistema e seu uso. Ele menciona cinco ordens, sucessivas e crescentes, de ignorncia: Falta de ignorncia conheo alguma coisa e posso demonstrar que conheo; Falta de conhecimento no conheo alguma coisa e posso identificar este fato; Falta de conscincia (awareness) no sei que no conheo alguma coisa; Falta de processo eu no sei uma maneira eficiente de descobrir que eu no sei que eu no conheo alguma coisa; Meta ignorncia eu no sei que existem as cinco ordens de ignorncia (agora ningum mais, dentre eu e os leitores deste texto, possui a meta ignorncia!). Neste caso, o processo pode ser visto como a construo de plataformas sucessivas de ignorncia cada vez menor, e consequentemente conhecimento cada vez maior. Ou seja, supondo que eu j no tenha a meta ignorncia, o caminho encontrar um processo para adquirir conscincia do que eu no conheo e, finalmente, adquirir este conhecimento.

2.3 Itens de Configurao de Software

O controle de qualquer sistema de software exige que o sistema, suas verses e partes componentes sejam unicamente identificados. Isto no uma atividade burocrtica ou administrativa. Considere o problema de encontrar um erro em um sistema se existem vrias verses e no conhecido qual apresentou o erro. Este um problema eminentemente tcnico. A identificao da configurao prope um meio de isolar os componentes do sistema como uma base para o controle. Existem trs dimenses para isto: primeiro, o sistema deve ser dividido em um nmero conhecido de partes gerenciveis; segundo, as

17

partes devem nomeadas de forma nica; por ltimo, medida que estas partes mudem com o tempo, as vrias verses que aparecem tambm devem ser univocamente identificadas. A primeira dimenso est ligada diretamente ao processo de desenvolvimento: especificao, anlise e projeto. E as outras duas requerem um rigoroso cumprimento de padres. Evidentemente, o sistema como um todo deve ter uma identificao e deve ser possvel distinguir entre as diversas verses que podem existir. Estas verses podem ser passos para uma verso final, ou alternativas adaptadas para ambientes ou usurios diferentes. Ou seja, podemos ter duas verses diferentes porque a mais nova corrigiu um erro da mais antiga, ou duas verses referentes mesma especificao funcional, s que uma delas em Portugus e a outra em Ingls, por exemplo. Ser muito til que, alm da identificao geral do sistema como um todo, cada parte tambm seja identificada. Em especial quando os mdulos pertencem a bibliotecas de uso geral, compartilhadas por outros sistemas. Um problema menos bvio, mas tambm importante, se refere forma ou meio no qual cada item pode ser encontrado. Uma especificao pode estar em papel ou em arquivo de disco, num formato de texto simples ou texto formatado (Rich Text). Um mdulo pode estar no formato de programa fonte ou executvel. Devemos ser capazes de saber se estas cpias so do mesmo objeto ou so verses diferentes e identific-las corretamente. As prprias ferramentas que so usadas para editar ou modelar os objetos de configurao podem mudar ao longo do tempo. Talvez tenhamos que identificar corretamente estas ferramentas e as verses das mesmas que so utilizadas. Compiladores, editores de diagramas, editores de texto, gerenciadores de bancos de dados, etc., so ferramentas que sofrem revises ao longo do tempo. E, estando embutidos em nosso sistema, devem tambm sofrer o controle de configurao. A identificao e o controle dos itens de configurao iro exigir, devido complexidade inerente, que tenhamos um registro adequado dos itens e das interrelaes entre eles, atravs de um banco de dados dos mesmos.

18

2.4 Controle de Verses

Existem diversas formas de identificar e controlar as verses de sistemas e objetos, propostos na literatura. A Free Software Foundation (CEDERQVIST, 1993), responsvel pelo desenvolvimento da ferramenta de gerncia de configurao CVS, prope uma forma de identificar e controlar verses de acordo com os conceitos apresentados a seguir. Um arquivo, parte integrante de um produto de software, pode apresentar vrias verses. Neste sentido, a verso chamada de reviso. Um produto de software completo, por exemplo, o Windows 98 4.10.2222, chamado de um lanamento ou release, em ingls. A palavra genrica verso no formalmente usada, exatamente para no confundir com nenhum dos dois conceitos acima enunciados. A identificao do release livre e utilizar um esquema simples tipo <Verso_Principal>.<Secundria>.<Montagem> tem sido bastante utilizado. Esta a estrutura usada pela Microsoft e por quase todas as Software Houses: trs nveis hierrquicos de verses, numerados seqencialmente e separados por pontos. Por exemplo: Windows 98 verso 4.10.2222, onde Windows 98 o nome do produto, no caso, o sistema operacional; 4 a verso Principal (major); 10 a verso Secundria (minor) e 2222 a Montagem (build) do produto de software. Toda vez que houver uma mudana significativa, que implique num processo de converso de uma verso do sistema para a outra, o nmero Principal da verso ser aumentado de uma unidade e os demais sero zerados. No caso do exemplo acima, passaria de 4.10.2222 para 5.0.0. Quando a mudana for de porte mdio haver mudana no segundo nmero (minor), 4.10.2222 para 4.11.0 no exemplo acima, ou quando forem pequenas no terceiro nmero, 4.10.2222 para 4.10.2223. Este nmero da liberao de um produto controlado manualmente. Muitas vezes, pequenos acertos de um lanamento de um produto de software so qualificados por letras, como 5.0.5a.

19

Cada reviso de um arquivo possui um nmero de reviso, que constitudo por um nmero par de inteiros separados por pontos (.), como por exemplo: 1.1, 1.3, 1.2.4.8 ou mesmo 1.3.2.5.3.7. Por padro, o primeiro nmero de reviso 1.1. A Figura 2.3 mostra uma seqncia de revises de um arquivo. O ltimo nmero da cadeia cresce seqencialmente. Este nmero de reviso normalmente assinalado de forma automtica pelo sistema de controle de verses.

Figura 2.3 - Revises de um arquivo

Quando um novo arquivo includo no diretrio ele ter o prefixo igual ao maior prefixo existente e o sufixo ser igual a um. Por exemplo, se os maiores nmeros forem 1.7.3.1e 4.12, o nmero de reviso de um arquivo a ser adicionado ser 4.1. Em geral, a numerao das revises feita automaticamente pelo software (CVS ou outro similar). Mas se o usurio desejar identificar explicitamente uma determinada verso poder colocar uma etiqueta (tag) em uma configurao de arquivos. Para fazer o desenvolvimento em separado de algum arquivo, por exemplo, para corrigir um erro de um mdulo sem interromper a linha principal, podemos abrir um ramo (branch) paralelo, conforme mostrado na Figura 2.4.

Figura 2.4 - Ramo de desenvolvimento

O nmero do ramo formado pelo nmero da reviso do arquivo de onde foi derivado, concatenado com o inteiro par posterior ao ltimo usado, iniciando em 2.

20

Desta forma, podemos obter mais de um ramo de um mesmo arquivo inicial sem haver duplicaes. No exemplo acima, o nmero do ramo ser 1.2.2 e a primeira reviso 1.2.2.1. Se houvesse mais um ramo, iniciando tambm em 1.2, sua primeira reviso seria 1.2.4.1.

Figura 2.5 - Ramificao e Consolidao

Um ramo pode, aps algumas revises, voltar a se juntar ao tronco principal atravs de uma consolidao (merge), conforme ilustrado na Figura 2.5. As alteraes devero ser sincronizadas adequadamente. Mecanismos simples podem ser criados para garantir o controle sobre as verses de arquivos em desenvolvimento. Quando um mdulo retirado do controle de verses para ser editado e modificado (check out) pode ser marcado com um cadeado (lock) que inibe alteraes por outros programadores. Quando for retornado ao sistema com as alteraes, ser realizado o check in, retirando o cadeado. Este tipo de procedimento bastante burocrtico e torna o desenvolvimento enfileirado. Existem alternativas que permitem as alteraes em paralelo, por vrios programadores, mas que vo exigir controles maiores de sincronizao. O desenvolvimento de cada programador pode ser conduzido como um ramo separado e no final ser realizada a consolidao destes diversos ramos. Nesta hora surgiro conflitos, como linhas alteradas com textos diferentes por cada programador, que devero ser resolvidos explicitamente para permitir a incluso no histrico do arquivo em edio.

2.5 O Controle de Mudanas

21

O controle, ou gerenciamento, de mudanas o registro, acompanhamento e a reportagem das solicitaes de mudanas de um sistema de software (WHITE, 2000). Inclui o processo de tomada de deciso sobre que mudanas realmente devem ser realizadas e o processo para execut-las. essencial para a administrao suave de um projeto. Envolve outras disciplinas do desenvolvimento de sistemas, como: gerncia de requisitos, testes, gerenciamento da liberao de software, suporte ao usurio e gerncia de projeto. O registro de uma solicitao de mudana deve incluir informao sobre a origem e o impacto do problema, a soluo proposta, e o seu custo e efeito sobre os prazos do projeto. O processo de soluo depende de uma srie de fatores. No entanto, as solicitaes so tratadas, em geral, de acordo com duas principais categorias: solicitaes de melhoria e correo de defeitos. Uma solicitao de melhoria especifica uma nova caracterstica ou uma mudana no comportamento projetado do sistema. Defeitos so anomalias ou falhas em um produto entregue. Enquanto grande parte dos dados mantidos para o controle de melhorias ou de defeitos similar, estes dois tipos de solicitaes so tratados de forma bem diferente no processo de controle de mudanas. O processo de gerenciamento das solicitaes de mudanas pode variar bastante com a abrangncia do problema a ser tratado. Uma mudana significativa na especificao do sistema pode representar at a interrupo ou redefinio por completo do projeto. Para mudanas rotineiras, no entanto, pode ser definido um modelo de transio de estados das solicitaes de mudanas, definindo eventos e aes correspondentes a cada evento. Os estgios bsicos deste processo so: Submisso. Na submisso feito o registro da solicitao de mudana. Defeitos e melhorias normalmente diferem bastante na origem da requisio e no tipo de informao coletada. Solicitaes de melhoria chegam dos usurios, diretamente ou atravs do suporte ao usurio ou da comercializao. Os dados relevantes se referem importncia da requisio para o usurio,

22

detalhes sobre a requisio e a identidade do solicitante original, para que se possa buscar mais detalhe, se for necessrio. A maioria dos defeitos encontrada, registrada e resolvida internamente. Os dados importantes so como o defeito foi encontrado, como reproduzir o defeito, a severidade, quem descobriu o defeito e a verso que o apresentou. Avaliao. Durante a avaliao algum deve olhar para todas as novas solicitaes de mudana e definir o carter de cada uma. realmente um defeito ou pode ser definido como uma melhoria? O nvel de severidade assinalado apropriado? Os defeitos podem ser reproduzidos? Qual a prioridade comparada com outras solicitaes? uma duplicata de outras solicitaes? As solicitaes de mudana devem ser priorizadas com base na severidade, importncia, nmero de usurios afetados, importncia dos usurios que fizeram o pedido, impacto no mercado, no faturamento e na equipe de suporte, etc. Deciso. Deve ser decidido se a solicitao de mudana deve ser implementada, adiada ou descartada. Quase sempre, defeitos e melhorias so tratados diferentemente. A deciso em relao s melhorias leva em conta aspectos de mercado e competio, j os defeitos so atendidos com base na fase do ciclo de vida em que so descobertos e o esforo necessrio para implement-los. Bem no incio do desenvolvimento, os defeitos podem ser tratados de maneira informal, porque o custo de se fazer alguma alterao bem pequeno (PRESSMAN, 2000). Em fases posteriores o processo de deciso passa a ser bem mais formal incluindo mecanismos mais rgidos, como comits de aprovao, por exemplo. Implementao. Na implementao so criados e modificados mdulos do sistema para satisfazer a solicitao de mudana. Tipicamente, as solicitaes de melhorias vo exigir um esforo maior de anlise e projeto e as correes de defeitos mais depurao, programao e testes. A documentao deve ser modificada correspondentemente e, quando for correo de defeitos, deve ser tomada a deciso de corrigir a documentao de forma integral ou emitir notas de liberao (release notes) do acerto executado.

23

Verificao. Testes finais e acertos na documentao so realizados na verificao. Quando se tratar de mudanas de melhoria, verificamos se atende s especificaes da solicitao. No caso de defeitos, os testes devem garantir que os defeitos detectados tenham sido sanados e novos defeitos no foram introduzidos. Isto usualmente feito tentando reproduzir os erros originais numa nova liberao do software. Finalizao. o fechamento da solicitao de mudana. Pode ser executado quando a mudana foi implementada ou quando foi descartada, por algum motivo. Uma boa prtica sempre fechar o ciclo com o solicitante original da mudana, principalmente se for um usurio externo. As atividades componentes do processo de mudanas de software devem ser incorporadas ao ciclo de vida como um todo. Em MAIDANTCHICK (1999) apresentada uma abordagem geral, baseada no modelo CMM, para o gerenciamento de processos de software para equipes geograficamente dispersas.

2.6 Verificao e Auditoria de Configurao

O processo de verificao e auditoria de configurao inclui: A verificao da configurao inicial dos itens de configurao e a incorporao das mudanas de engenharia aprovadas, para garantir a performance e os requisitos documentados; A auditoria da configurao dos registros de verificao de configurao e dos produtos fsicos para validar que o programa de desenvolvimento obteve os seus requisitos de performance. O trmino bem sucedido das atividades de verificao e auditoria resulta em um sistema ou item de configurao e um conjunto de documentao que pode ser, com confiana, considerado uma linha base do produto.

24

A verificao de configurao um processo comum gerncia de configurao, engenharia de sistemas, engenharia de projeto, fabricao, e garantia de qualidade. a forma como o construtor verifica a sua soluo de projeto. Aspectos funcionais da verificao de configurao incluem todos os testes e demonstraes realizadas pra garantir a qualidade da implementao das especificaes. Os aspectos fsicos verificam se a configurao como construda (as-built) est de acordo com a configurao projetada (as-designed). Uma vez que a configurao inicial foi verificada, as mudanas aprovadas da configurao tambm devem ser verificadas. A verificao da mudana pode envolver uma auditoria detalhada, uma srie de testes, uma validao de operaes, manuteno, instalao, ou modificaes de instrues, ou uma simples inspeo. A escolha do mtodo adequado depende da natureza do item de configurao, da complexidade da mudana, e do conjunto de itens que a mudana afeta. A auditoria de configurao um processo complementar verificao que garante de forma mais formal a qualidade dos produtos gerados. Enquanto a verificao normalmente conduzida pela prpria equipe de projeto e construo, a auditoria deve ser conduzida por pessoas externas ao projeto, sob os auspcios do contratante. Tambm a auditoria dividida em auditoria funcional e auditoria fsica, de forma semelhante verificao. A auditoria funcional visa garantir que a performance atual dos itens de configurao atende os requisitos especificados. A auditoria fsica verifica se a configurao atual dos itens de configurao representativa da configurao do produto. Valida tambm os processos usados pelo construtor no desenvolvimento dos itens. O processo de auditoria, ao contrrio da validao, no utilizado ao longo de todo o desenvolvimento, mas conduzido quando os produtos j estejam totalmente projetados, prontos ou iniciando a produo.

25

2.7 Padres de Gerncia de Configurao de Software

O Departamento de Defesa Americano (DoD) tem tomado iniciativas para definir padres militares e governamentais para a rea de gerncia de configurao. A preocupao abrange equipamentos, software de uso geral, mas, principalmente, softwares embarcados em sistemas de armas, aeronaves, veculos militares, etc., por motivos bvios. A partir destas iniciativas, a indstria em geral tem se mobilizado para definir normas sobre a gerncia de configurao. No Brasil, a ABNT emitiu algumas normas, em especial a NBRISO 10007, relacionadas ao assunto. A Tabela 2.1 consolida informaes importantes sobre a normalizao mais relevante. A norma MIL STD 973 Gerncia de Configurao Militar, padro militar emitido pelo Departamento de Defesa dos Estados Unidos da Amrica (DoD), consolidou e tornou mais clara a informao contida em diversas normas mais antigas, como a MIL STD 480 e a MIL STD 483, na rea de identificao de configurao e controle de mudanas. Apresenta padres e recomendaes para a execuo das quatro atividades bsicas da gerncia de configurao: 1) Identificao e documentao das caractersticas fsicas e funcionais dos itens de configurao; 2) Controle de mudanas dos itens de configurao e a documentao relacionada; 3) Registro e relato das informaes necessrias para gerenciar os itens de configurao de forma efetiva; e, 4) Auditoria dos itens de configurao para verificar a conformidade com as especificaes, projetos, documentos de controle de interface e outros requisitos de contrato.

Norma
MIL-STD-973 17/04/1992 NBRISO10007 30/12/1996 MIL-STD-2549

Emissor
DoD USA ABNT/ISO DoD USA

Assunto
Military Configuration Management Gesto de qualidade Diretrizes para a gesto de configurao Military Configuration

Observaes
Cancelada em 30/09/2000 Traduo brasileira da ISO 10007 de 1995 Cancelada em 30/09/2000

26 30/07/1997 EIA-649 1998 IEEE 828-1998 DI-CMAN81588 03/11/2000 Management Data Interface National Consensus Standard Adotada como padro no For Configuration DoD em 01/02/1999 Management IEEE Standard for Software Configuration Management Plans DoD USA Configuration Management Data Interface Transactions Data Information Packets Tabela 2.1 Normas de Gerncia de Configurao ANSI/EIA

A MIL STD 2549 Gerncia de Configurao de Interface de Dados, complementa e substitui a norma MIL STD 973, no que for conflitante. Define o padro de gerncia de configurao para os dados a serem manipulados, conforme ser visto na seo 2.8. Ambas as normas, MIL STD 973 e MIL STD 2549, foram canceladas em 30/09/2000 e substitudas pela EIA 649 Padro Nacional Consensual de Gerncia de Configurao. Como o prprio nome diz, esta norma surgiu, no mbito da EIA Eletrical Industries Alliance com o aval do DoD, como o consenso entre a indstria e o governo norte-americano sobre gerncia de configurao. Define gerncia de configurao como: o processo gerencial para estabelecer e manter consistncia na performance de um produto, atributos funcionais e fsicos com relao aos requisitos, projetos e informaes operacionais ao longo de sua vida. O IEEE Institute of Eletrical and Eletronic Engineer, emitiu na mesma poca da EIA a verso atualizada de sua norma IEEE 828-1998 Standard for Software Configuration Management Plans. Esta norma define: Gerncia de configurao de software constitui-se em boas prticas de engenharia para todos os projetos de software, para qualquer fase do desenvolvimento, prototipao rpida, ou manuteno em andamento. Ela aumenta a confiabilidade e qualidade do software atravs de: Providenciar estrutura para a identificao e controle da documentao, cdigo, interfaces e bancos de dados para atender a todas as fases do ciclo de vida

27

Dar suporte metodologia de desenvolvimento e manuteno escolhida para atender os requisitos, padres, polticas, organizao e filosofia gerencial Produzir informaes gerenciais e do produto com relao ao estado das linhas base, controle de mudanas, testes, liberaes de software, auditorias, etc. A norma NBRISO10007 Gesto de Qualidade Diretrizes para gesto de Configurao, emitida em novembro de 1996, pela ABNT Associao Brasileira de Normas Tcnicas, uma traduo da Norma ISO 10007 de 1995. Esta norma trata de gesto de configurao de uma forma geral, vinculada ao CB-25 Comit Brasileiro da Qualidade. Define a gerncia de configurao como uma disciplina de gesto que aplicada ao longo do ciclo de vida de um produto, para prover visibilidade e controle de suas caractersticas fsicas e funcionais. aplicvel ao suporte de empreendimentos1, desde a concepo de produtos, passando pelo seu projeto, desenvolvimento, aquisio, produo, instalao, operao e manuteno, at a disposio aps o uso. A norma brasileira segue a orientao das normas internacionais e define o processo de gerncia de configurao com as mesmas atividades bsicas daquelas normas: identificao de configurao; controle de configurao; relato da situao de configurao e auditoria de configurao.

2.8 Gerncia de Configurao de Dados e Documentos

Conforme relatado em LYON (2000), CHAFFREY (1998) e em outras referncias sobre gerncia de configurao, administrao de documentos e trabalho em grupo, os conceitos e padres de gerncia de configurao se aplicam aos dados e documentos usados pelas organizaes. CHAFFREY (1998) relata exemplos de organizaes como o banco CERA da Blgica, que administra manuais com 18.000 pginas contendo informaes comerciais,
Empreendimento foi usado na norma como traduo de project e projeto como traduo de design.
1

28

legais e fiscais e com atualizao semanal mdia de 150 pginas. Na Inglaterra, o Abbey National Bank executa cerca de 300 alteraes por ms nas suas 2.000.000 de pginas de informaes de produtos, procedimentos e manuais. Todos estes documentos devem ser controlados com relao correo e vigncia, criando mecanismos de controle de verses e de mudanas totalmente similares aos controles de configurao de equipamentos, sistemas e softwares. Surge a necessidade de ferramentas de software especializadas nestes controles, os chamados EDMS sigla em ingls de Software de Gerncia de Documentos Eletrnicos. Estes produtos, alm de executarem as funes regulares de um editor de texto, devem permitir a um grupo de pessoas: Realizar a autoria cooperativa da documentao; Revisar e anotar detalhes de reviso; Modificar a documentao; Publicar a documentao; Distribuir a documentao na organizao; Modificar e repetir todo o ciclo. Produtos como o Interleaf (http://www.interleaf.com), Documentum

(http://www.documentum.com) e Filenet (http://www.filenet.com) permitem operar com a documentao em grande escala. Padres so apresentados tambm nesta rea, conforme j foi dito na seo anterior.

2.9 Estrutura de comparao dos ambientes de Gerncia de Configurao

Uma estrutura de anlise e comparao (framework) pode ser construda com o objetivo de explicitar os critrios mais ajustados aos objetivos deste trabalho.

29

No captulo 3 esta estrutura ser utilizada para comparar os produtos analisados e na concluso (captulo 7) servir para avaliar o quanto atingimos os objetivos propostos. A nossa proposta considerar como itens mais relevantes para avaliar e para julgar os ambientes de GCS os seguintes: Cooperao no processo de GCS Percepo (awareness) do trabalho em equipe Apoio equipe com disperso geogrfica Controle de mudanas Semntica enriquecida Amigabilidade nos controles de projeto