No último post afirmei que a organização da atividade gestão de configuração passa pela organização da atividade de gestão de projetos. Tal afirmação gerou algumas dúvidas. Selecionei duas delas e tentarei saná-las?
Dúvida 1 – Estou com algumas dúvidas sobre a relação entre gc e gp. Quais são reais pontos de intersecção entre elas?
Para sanar esta dúvida é importante lembrar que as tarefas ligadas à atividade de gestão de configuração têm como objetivo responder as seguintes questões:
1 – Qual artefato do processo foi mudado?
2 – Quando ocorreu tal mudança?
3 – Quem foi responsável pela mudança?
4 – Qual o impacto que a mudança irá gerar?
Ao organizar a atividade de gestão de projetos estaremos, automaticamente, respondendo algumas das questões levantadas. Para defender esse argumento vou partir das considerações efetuadas no post empinando um software ou programando uma pipa. Nele foi proposta uma organização de dados que mapeia:
Todos os projetos que foram desenvolvidos e que estão em desenvolvimento.
Cada projeto pode gerar uma ou várias ordens de serviço (os) e
Cada ordem de serviço pode gerar uma ou várias versões (vide tabela produção).
Para cada versão gerada podemos executar n atividades.
Os envolvidos com a execução das atividades também são armazenados.
Com base no mapeamento proposto em empinando um software ou programando uma pipa podemos afirmar que ao efetuar uma mudança em um determinado programa estaremos gerando uma nova versão. A data de início e a data de termino da referida versão é armazenada na tabela produção. Neste caso estamos respondendo quando ocorreu à mudança e qual programa (ou artefato) foi alterado, visto que a tabela produção está relacionada com a tabela os. Os envolvidos com a referida mudança são capturados pela tabela envolvidos com a produção, fato este que responde terceira questão.
A intersecção ocorre justamente nesses três pontos: qual artefato foi mudado, quando o artefato foi mudado e quem mudou o artefato.
Dúvida 2 – Ao ler o post sobre gestão de configuração, vi que você tocou muito pouco sobre a questão do baseline. Este artefato não é extremamente importante para a referida gestão?
Excelente questão!!! Antes de iniciar a reposta, vou tentar delinear a amplitude conceitual representada pelo termo baseline.
O termo baseline pode ser caracterizado como a linha base para o acompanhamento de qualquer tipo de projeto. Além de acompanhá-lo, a referida linha pode ser utilizada para reproduzir e rastrear todas as etapas e todos os acontecimentos delineados dentro do projeto. Neste post destaco 3 tipos de linhas de acompanhamento:
Baseline de tempo: Linha responsável por gerar um calendário do projeto. Nela são distribuídas as datas e as atividades que foram, que estão e que serão executadas pelo envolvidos com o projeto.
Baseline de custo: Linha responsável por mapear quanto se pode investir no projeto. Nela são distribuídas as atividades e o custo de cada uma delas.
Baseline de escopo: Nesta linha é mapeado tudo o que se produziu (os subprodutos) e o que se pretende produzir no projeto. Congregar todas as versões (ou alterações) geradas no produto com suas referidas justificativas configura-se como principal objetivo da referida linha.
Todas as linhas de acompanhamento citadas são geradas a partir de uma gestão eficiente e eficaz. Lembre-se que neste caso, a palavra gestão é maximizada e representa tanto a gestão de projetos como a gestão de configuração. Sob a ótica da gestão de projetos são gerados os baselines de tempo e de custo. Já o baseline de escopo está sob a ótica da gestão de configuração. Estes fatos me levaram a não inserir explicitamente a palavra baseline no referido sobre gestão de configuração.
Para finalizar esse texto, deixo duas questões em aberto:
O modelo de dados proposto no post empinando um software ou programando uma pipa não contempla quais artefatos ou componentes que serão impactos com uma mudança qualquer. Como resolver esse problema?
Qual baseline que está na faltando na figura apresentada no início do post?
Abraços a todos.
J.A.
Engenharia de Software 
Bem gente, minha opinião sobre GC é bem amplo! Os documentos que podem ser considerados baseline pode variar de empresa ou necessidade do programador.
Ao meu ver os documentos necessarios são o levantamento de requisito, a parte de analise, quaisquer documentos de aceitação do usuário que são os mais comuns.
Já os expecificos como o formulario do levantamento entre os elementos que estão envolvidos nas mudanças (quais terão de ser modificado, enfim os afetados) contanto tempo, prioridade da mudança, custo, quem irá ser responsavel e o formulario demonstrando o que esta nova versao do sistema irá ter.
Se a mudança for em um framework deve ser levando em conta também que este sofre mudanças e que necessita tb de um controle de versão e neste deve conter o que esta versão quais aplicativos fazem parte do mesmo, pois caso necessite de uma nova reengenharia do sistema ja desenvolvido, deverá levar em conta se a nova versao do framework possui as mesmas caracteristicas basicas para que nao ocorra erros.
Qualquer coisa tem artigos sobre o tempo disponivel!
obrigada,
Marliane