 | Nível: Intermediário Rodrigo Orzari de Carvalho
, Bacharel em Ciência da Computação, IBM
01/Out/2009 Mudanças, invariavelmente, ocorrerão! É com essa afirmação que iniciamos as
discussões nosse artigo. Sem dúvida, ela reflete a realidade dos inúmeros projetos de
desenvolvimento que estão em curso nesse exato instante em sua organização. Imaginamos que, a
lista de novos requisitos ou funcionalidades a serem implementados, ou mesmo defeitos que
precisam ser corrigidos nas aplicações das quais sua organização é responsável por manter,
desenvolver ou criar, seja extensa.
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.
Sobre o autor | | | 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. |
Avalie esta página
| |
