Gerenciar mudanças nos diferentes artefatos produzidos ao longo do ciclo de vida de uma aplicação é algo tão importante para aquelas organizações que vêem o desenvolvimento de software como um processo de negócio, que não há necessidade de convencê-lo(a) sobre a importâncua da adoção de processos e práticas que atendam a essa finalidade (gerenciar mudanças).
Somado a importância em si da adoção de processos e práticas de gerência de mudanças, em muitos casos, organizações tem a necessidade em estabelecer o controle daquilo que esta sendo alterado, imposto através normas regulatórias, tais como ITIL, CMMi, SOX, entre outras.
Dez entre dez profissionais da área de desenvolvimento de software são capazes de identificar processos e algumas das melhores práticas ligadas à gerência de mudanças, dada a maturidade que esse assunto atingiu no que tange ao controle daquilo que esta sendo alterado por desenvolvedores, analistas, testadores, etc.
A adoção de tais práticas, não só possibilitam o respeito a normas regulatórias, mas também auxiliam na redução erros, minimizam retrabalho, além de contribuem para aumento de produtividade, num momento em que TI necessita entregar resultados cada vais mais rápidos ao seus clientes (sejam eles internos e externos).
Para atingir os objetivos de nosso artigo em Desvendar os Mistérios do Gerênciamento Unificado de Mudanças, permita-nos apresentar uma síntese de algumas das melhores práticas ligadas ao gerenciamento de mudanças, pois elas serão a base das discussões relacionadas a forma pela qual as ferramentas IBM Rational ClearCase e IBM Rational ClearQuest as implementam. Melhores práticas recomendam que:
- O desenvolvimento de uma nova funcionalidade deve ser realizada de tal forma que não impacte a versão da aplicação que, hoje, se encontra em produção
- Ofereçam mecanismos que permitam acessar versões mais antigas da aplicação, possibilitando a reprodução de erros ou situações reportadas por usuários em uma dada versão da aplicação
- Combinar os diferentes esforços de desenvolvimento (criados por diferentes membros do time) no momento em que entregamos um produto final aos clientes, usuários, sendo todo que todo esse processo seja passível de auditoria
- Estimular o reuso de versões, módulos ou componentes objetivando agilizar o processo de desenvolvimento, possibilitando um retorno mais rápido do investimento (Return Over Investment)
Ao analisarmos algumas das melhores práticas ligadas ao gerenciamento de mudanças não conseguimos imaginar sua adoção sem o auxílo de ferramentas. Também não é segredo que muitas são as opções disponíveis no mercado que implementam, total ou parcialmente, funcionalidades que as suportem.
A família de produtos IBM Rational ClearCase e IBM Rational ClearQuest implementam as melhores práticas através de um framework automatizado denominado Gerênciamento Unificado de Mudanças (Unified Change Managment, ou simplesmente, UCM).
É comum, no momento em que discutimos com profissionais da área de desenvolvimento de software, encontrarmos uma certa resistência (ou ceticismo quanto aos benefícios) ao apresentarmos os conceitos que estão presentes no UCM, contudo nosso objetivo, a partir de agora, é desvendar os mitos e mistérios associados a ele.
Vale citar desde já, que a adoção do UCM não é a única forma para implementação das melhores práticas de gerência de mudanças utilizando as ferramentas IBM Rational (as diferentes opções de implementação, por si só, produziriam diversos artigos).
O UCM, como citado anterioremente, é um framework que automatiza, através de operações reunidas numa rica interface gráfica, as melhores práticas ligadas a gerência de mudanças, diminuindo a complexidade de colocá-las em prática rapidamente. Criado pela Rational (até então uma empresa independente) a partir da identificação de padrões em gerência de mudanças junto aos seus clientes, parceiros e pesquisadores, ele foi oficialmente inserido na família de produtos IBM Rational em 2001 (ao longo dos anos sua evolução tem sido constante). Passaremos a analizar os elementos que compõe o UCM e o primeiro deles é denominado componente.
O resultado de um projeto de desenvolvimento de software sera, entre outros, a produção ou alteração de códigos fonte (obviamente outros artefatos, como requisitos, planos de projeto, planos de teste, etc., serão produzidos ao longo do projeto). A forma pela qual organizamos esse conjunto de artefatos é através dos Componentes. Assim, podemos definir componentes como o conjunto de artefatos agrupados, que se relacionam de alguma forma, e representam uma unidade independente de uma aplicação ou software. Componentes, muitas vezes devem ser vistos, como algo que pode ser reutilizado em diferentes projetos (dado sua independência) e residem, fisicamente, em repositórios do ClearCase (demoninados base de objetos versionados, ou VOBs).
Se um componente representa um conjunto de artefatos, a baseline (mais um dos elementos do UCM) representa uma única versão dos artefatos num componente. No decorrer deste artigo, voltaremos a abordar a aplicabilidade da baseline com mais ênfase.
Objetivando coordenar a relação entre componentes, baselines e os demais elementos do UCM, vê-se a necessidade de apresentar o conceito do Projeto UCM. É o Projeto o responsável por articular a forma pela qual os elementos do UCM se relacionam.
Ao criarmos um Projeto UCM identificamos, entre outras coisas, se o Projeto permitirá o desenvolvimento paralelo ou serial, quais são os componentes que serão associados a ele, se os artefatos daqueles componentes estarão disponíveis para alteração naquele Projeto, qual Baseline constituirá a primeira versão da aplicação, entre outras informações.
O Projeto UCM determina também, as linhas de desenvolvimento que serão aplicadas a ele. Essas linhas são divididas entre Integração (principal linha de desenvolvimento de um Projeto UCM) e Desenvolvimento (linhas de desenvolvimento em paralelo a Integração). Tais linhas são denominadas Streams e, para cada Projeto UCM, há uma linha de Integração e muitas linhas de desenvolvimento (desenvolvimento paralelo) ou apenas uma linha de Integração (desenvolvimento serial).
A Stream de Integração concentra a versão “final” da aplicação que será entregue aos clientes ou usuários e, por isso, o acesso a ela deve ser restrito. Já as Streams de desenvolvimento mantém a versão da aplicação que se encontra em desenvolvimento, e, é onde os esforços de desenvolvimento, representados pela adição de novas funcionalidades ou a correção de erros, ocorrem primariamente.
Diferentes Streams de desenvolvimento permitem que desenvolvedores tenham a liberdade de fazerem quaisquer alterações sem impactar o produto final do Projeto. Note a relação com as melhores práticas citadas no início do artigo (desenvolvimento paralelo).
Num dado momento, os esforços de desenvolvimento realizados nas Streams de desenvolvimento deverão ser transportados para a Stream de Integração (abordaremos os detalhes dessa operação mais tarde), para que possam ser disponibilizados aos clientes (após compilação, testes, etc.).
Ao adicionarem novas funcionalidades (ou corrigindo erros), desenvolvedores, utilizando suas Streams de desenvolvimento, alteram os artefatos (documentos, código fonte, etc.) utilizando o conceito da atividade (mais um elemento do UCM).
A atividade é o esforço despendido para a criação de um resultado em particular, como por exemplo a criação de um documento contento novos requisitos, um novo código fonte, a correção de um defeito, a implementação de uma nova funcionalidade, etc.
No que diz respeito a aplicação da atividade ao UCM, a medida em que um desenvolvedor necessita alterar um ou mais artefatos, é necessário especificar qual a atividade que esta sendo associada a tal esforço. Não é possível alterar ou criar novos artefatos sem que uma atividade seja específicada. Fisicamente, as atividades residem num banco de dados, gerenciadas pela ferramenta IBM Rational ClearQuest.
Uma vez que as alterações nos artefatos ocorrem apenas no contexto da atividade, temos a habilidade de recuperar seu histórico, identificando por exemplo quem foi responsável por sua implementação ou sua aprovação, qual o esforço dispendido, quais os artefatos alterados, qual o resultado dos testes, em qual versão da aplicação (Baseline) a atividade foi concluída, etc. possibilitando que rastreabilidade seja aplicada, atendendo assim requisitos de auditoria, por exemplo. Mais uma vez, podemos relacionar os conceitos vistos até então com as melhores práticas.
É, também, no contexto da atividade que um desenvolvedor transporta as alterações, realizadas em sua Stream de desenvolvimento para a Stream de Integração, quando identifica que seu trabalho (a atividade) esteja concluído. O transporte das atividades, que representam o conjunto de alterações em artefatos nas Streams de desenvolvimento para a Stream de Integração é doniminada entrega (ou deliver).
Uma vantangem de se trabalhar no contexto de uma atividade é a de que, uma vez que um desenvolvedor altera artefatos no contexto daquela atividade, não sera mais necessário identificar se um ou outro código foi ou não entregue para ser colocado em produção ou enviado para testes, compilação, etc. Todos os artefatos alterados ou criados foram, obrigatóriamente, associados a atividade no momento de sua alteração ou criação.
Quando atingimos um número significativo de atividades entregues por diversos desenvolvedores, é necessário agruparmos as atividades entregues num elemento que represente um marco do projeto (milestone). Nesse instante, voltamos a discutir o conceito da baseline (trazendo a discussão para o contexto do Rational Unified Process, ao final de uma iteração temos uma Baseline).
Além dos conceitos abordados anteriormente relacionados a Baseline, ela caracteriza-se ainda, pela representação de todas as alterações que foram realizadas na Stream de Integração, resultantes da entrega das atividades pelas Streams de desenvolvimento.
A combinação de atividades entregues por diversos desenvolvedores (agora representadas/agrupadas numa Baseline) podem ser utilizadas como a base para a criação de novos Projetos (que passam a ser desenvolvidos de maneira independente do atual), assim como base para a criação de novas Streams de desenvolvimento. Mais importante ainda, possibilitar o acesso a uma versão mais “antiga” da aplicação (Baselines criadas anteriormente).
Uma vez que diferentes desenvolvedores contribuiram para a criação de uma Baseline (resultado da entrega de suas atividades), é necessário transportar as alterações que se encontram na Stream de Integração de volta para as diversas Streams de desenvolvimento (lembre-se que o acesso as informações na Stream de Integração é restrito), de tal forma que os desenvolvedores tenham acesso a última Baseline do Projeto em suas Streams (desta forma as Streams de desenvolvimento estejam em sincronia com a Stream de Integração, pois lembre-se que as alterações ocorrem somente no contexto das Streams de Desenvolvimento).
Dá-se o nome de Rebase a operação que sincroniza as Streams de desenvolvimento com uma Baseline criada na Stream de Integração (permitindo que os desenvolvedores continuem os esforços de desenvolvimento em suas Streams utlizando a versão mais recente da aplicação).
Em síntese, a essência do framework UCM pode ser resumida no ciclo: alteração ou criação de artefatos (associados a uma atividade), entrega (deliver) de atividades, criação de Baseline e rebase (sincronização das Streams de Desenvolvimento com a Stream de Integração).
Respeitando a natureza e particularidade de cada organização, o UCM pode ser implementado em diferentes níveis de complexidade, já que muitos outros conceitos associados ao Gerenciamento Unificado de Mudanças, como, por exemplo, diferentes níveis de promoção aplicados a Baselines, Deliver e Rebase entre diferentes Projetos UCM, estratégia para organização de Streams, entre outros, não foram abordados neste artigo.
Adotar ou não o UCM é uma decisão de cada organização de desenvolvimento de software, a recomendação é que você avalie sua adoção com o auxílio de literatura especializada, experiências vividas por outros usuários, prática e experimento, ou mesmo, com o auxílo da IBM.
Temos a certeza de que seu time se beneficiará (e muito) com os resultados que serão obtidos com a adoção do UCM. As discussões relacionadas ao “tequiniques” (ou mitos) se tornam irrelevantes, já que os benefícios de sua adoção são tangíveis e, devido a sua flexibilidade e rapidez de adoção, oferecem um grande salto de produtividade para gerentes de configuração, líderes de desenvolvimento, integradores, testadores e desenvolvedores em geral.
Bacharel em Ciência da Computação, com especialização em Engenharia de Software pela Universidade da British Columbia, tem mais de 15 anos de experiência na área de tecnologia da informação, trabalhando como especialista técnico, consultor e/ou gerente de projetos. Possui experiência na implementação do IBM Rational Unified Process (RUP) e metodologias de desenvolvimento de software ágeis em empresas de diversos segmentos; Incluindo a implementação de ferramentas para o suporte ao ciclo de desenvolvimento de software, entre elas ferramentas para Análise & Desenho, Gerenciamento de Ativos, Requisitos, Mudanças, Construção & Distribuição, Testes, entre outras. Atualmente trabalha como Especialista Sênior em Rational na área de Serviços de Software.
Marcas Registradas | Termos e condições do My developerWorks
