segunda-feira, abril 23, 2007

Sobre linhas de base ( baselines ) em projetos iterativos de software

Dúvida surgida na lista CMM-Brasil:

Existe a necessidade de criar solicitações de mudança ao alterar itens de configuração que fazem parte de uma baseline ? Quando se deveria criar linhas de base ? Seria bom criar uma apenas quando o software for para homologação, para evitar as solicitações de mudançasdurante a maior parte do desenvolvimento? Vocês têm sugestões de estratégias de Gestão de Configuração de Software para desenvolvimento de novos produtos e de manutenção de software? Fazer essa grande quantidade de baselines implica em criar solicitações de mudanças para todas as alterações nas baselines? Se sim, isso não aumentaria muito a burocracia do processo? Essas solicitações sempre devem ser analisadas e aprovadas pelo comitê de controle de mudanças ( CCB ou Change Control Board )?

Minha resposta:

Você deve gerar baselines ( linhas de base ) no projeto iterativo. Você pode e deve gerar, por exemplo, um baseline ao final de cada iteração no caso do RUP.

Além disso, os projetos ágeis acham linhas de bases em GC tão boas que muitos projetos criam baselines diárias usando automação com ferramentas de gestão e automação de builds como o Luntbuild (integradas aos sistemas de controle de versões e ao sistema de gestão de mudanças). Tenho um artigo sobre ambientes de desenvolvimento de software que escrevi sobre esse tópico.

Baselines de requisitos também são fundamentais em projetos iterativos e são feitas quando ocorrem mudanças de escopo no projeto. Inclusive a ferramenta Rational RequisitePro possui um módulo só para fazer geração de baselines de requisitos. Falo em maiores detalhes sobre as funcionalidade do Rational RequisitePro Baseline Manager em um artigo sobre Linhas de Base de Requisitos com o Rational RequisitePro.

Todos os processos iterativos produzem alguma espécies de requisito (user stories, casos de uso, features, work items, etc). A diferença é que processos iterativos assumem que esse escopo inicial sofrerá muitas mudanças e poderá ser totalmente diferente do escopo inicial. Aí vêm a necessidade ainda maior de se ter um controle de baselines de requisitos em pontos específicos do projeto. Assim você pode gerar métricas (o RUP as define) de, por exemplo, quantos requisitos novos foram adicionados de uma iteração para outra, etc.

Além disso você poderá salvar essa linha de base de requisitos numa ferramenta de controle de versões, para o caso de ocorrer algum problema e você tiver que voltar para um baseline anterior.

Portanto minha recomendação seria:

- Para baselines de GC -> uma vez por dia e ao final de cada iteração.
- Para baselines de requisitos -> pelo menos ao final de cada iteração.

O próprio CMMI nível 2 na PA de Gestão de Configuração diz que o nível de controle é flexível para cada ponto do projeto onde vc está. Se você está no meio da construção de um software então pode ter controles mais "frouxos". Já no final do projeto pode ter controle mais "pesados".
Se você usar a ferramentas modernas que citei não terá trabalho de criar atividades nas ferramentas de controle de mudanças e atrelá-las aos itens de GC que foram alterados.

É claro que essas micro-atividades normalmente não precisam de aprovação de um CCB. Você pode definir que aprovações do CCB devem ocorrer para as solicitações de mudança que impactam em prazos e custos dos projetos. Estas mudanças, quando aprovadas, gerarão uma série de atividades do workflow específico de micro-atividades(estas sim não precisam de aprovação de CCB). Recomendo que você dê uma olhada no modelo UCM ( Unified Change Management ) do ClearCase/ClearQuest para entender melhor e ficar mais fácil de visualizar como isso tudo funciona.

Pode-se encontrar muitas informações nestes sites. Leia especialmente sobre "activity-based change management model":

- Leitura básica sobre o UCM

- Redbook da IBM que explica em detalhes o UCM

Não esqueçam de dar uma olhada na minha série de artigos que mostra como fazer um modelo similar (mas não tão completo como o ClearCase/ClearQuest no modelo UCM) usando ferramentas open source.

Marcadores: , ,

0 Comentários:

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas