Controle de configuração … liberte as algemas!

a natureza global e cada vez mais complexa de todos os negócios entre indústrias e sectores verticais, juntamente com o fogo rápido, os modelos de Negócio “tempo da Internet”, está a dar nova ênfase à gestão da mudança. A capacidade de gerir eficazmente a mudança está a emergir como uma chave diferenciadora entre os concorrentes – permitindo que as organizações desenvolvam modelos de negócio e linhas de produtos, e mudem de engrenagem com a rapidez suficiente para enfrentar as oportunidades da economia actual – à frente da concorrência.À medida que as organizações lutam para gerir projectos neste ambiente, a gestão da configuração (CM) tornou-se um componente cada vez mais crítico, oferecendo uma estrutura para gerir a mudança.

A disciplina de CM consiste em seis áreas de conhecimento, conforme definido pelo EIA-649 (ANSI, 2004))

• CM de Planejamento e Gestão (CMPM),
• Configuração de Identificação (CI),
• Configuração Gestão de Mudanças (CCM),
• Status da Configuração de Contabilidade (CSA),
• Verificação da Configuração do & Auditorias (CVA), e
• CM de Dados Digitais.

no Entanto, ISO 10007 (ISO, 2003) grupos de CM em quatro classificações:

• CI,
• Configuração de Controle (CC),
• CSA, e
• Configuração de Revisões e Auditorias (R&A).

(a CCM e a CC são, para todos os efeitos práticos, idênticas, tal como A CVA e a R&A.)

Note que o controlo da configuração é discutido no presente artigo. Gerenciamento de mudanças de configuração e controle de mudanças também são termos usados para descrever o mesmo processo.Definições De Base:

• um problema ou bug é qualquer ocorrência de desvio em relação aos resultados esperados, onde o projeto não está executando as especificações definidas.
• uma alteração é qualquer ocorrência de desvio em relação aos resultados esperados, em que o projecto está a cumprir as especificações e as especificações estão erradas.
• um realce é qualquer condição em que um stakeholder (cliente, usuário, desenvolvedor …) encontra uma área que pode ser melhorada ou melhorada; no entanto, todas as especificações são atendidas e elas devem ser modificadas para incorporar o realce.

muitos gestores de projeto percebem o controle de configuração como restrição e confinamento-sistemas projetados para impedir o desenvolvimento do produto e que geralmente impacta a programação do projeto de uma forma negativa. Infelizmente, muitas vezes, processos CC genéricos projetados para programas grandes e complexos, como armas ou desenvolvimento de sistemas médicos, são impostos a outros tipos de projetos. Estes processos não são adaptados para satisfazer as necessidades, por exemplo, de um esforço de Desenvolvimento Web ou de uma nova implantação de produtos. Isto, em última análise, leva a uma intensa frustração com o processo CC e o efeito de “algemas” – onde processos não projetados para atender às necessidades do programa impactam negativamente o progresso.

os gestores de Projecto implementam o controlo de configuração para controlar e acompanhar as alterações. Os processos são projetados para garantir que o nível apropriado seja usado para aprovar alterações e que essas alterações se baseiem em informações melhores disponíveis. Os processos fornecem um quadro para a revisão da mudança. Isto permite que a equipe avalie se a implementação da mudança é aceitável e identifique problemas potenciais em tempo hábil. Estes processos permitem a calibração e, se necessário, uma nova revisão.

a verdadeira questão não é se deve implementar o controle de configuração, mas qual o nível de controle de configuração a implementar. Uma organização pode exigir um pacote de controle de configuração” standard da empresa ” em todos os projetos. Este tipo de sistema é muitas vezes imposto às equipes de projeto devido a uma história de falta de controle de configuração, e o impacto financeiro resultante. Os gestores de projectos, que reconhecem que uma abordagem de “tamanho único” não funcionará, devem demonstrar que existem controlos adequados para evitar a repetição dos erros do passado.

controlo de configuração na acção

o projecto de desenvolvimento típico não requer um processo de controlo de configuração ao nível de um sistema de armamento principal. É importante dotar a equipa do nível de flexibilidade adequado, garantindo simultaneamente a existência de um sistema de verificações e balanços. A chave para qualquer sistema é o esforço necessário para documentar o processo, juntamente com a documentação exigida pelo processo. O processo de amostra CC descrito abaixo é projetado para atender aos requisitos de um projeto de desenvolvimento de aplicações de pequeno a médio porte.

a equipe do projeto deve primeiro analisar o papel adequado de controle de configuração no projeto. Isto, no mínimo em um projeto de software, implicaria um tema de documentação de todos os arquivos de código internamente e algum tipo de documentação externa. Áreas adicionais para cobrir incluem a aprovação de alterações e processos de documentação de mudanças. O simples consenso dos participantes deve ser suficiente. É claro que um conselho estruturado convocado regularmente é melhor.

agora vamos entrar nos diferentes aspectos do processo de controle de configuração simples.

documentos

o plano de gestão da configuração (CMP) definirá o processo CC. Em algumas aplicações onde o processo CC é bastante detalhado, um plano de controle de configuração (CCP) é desenvolvido. Em ambos os casos, todos os processos e procedimentos são cobertos para realizar o controle de configuração.

a própria documentação de alteração (detalhada mais tarde) deve fornecer informação suficiente que seja auto-explicativa ao ponto de não exigir informação adicional do originador. Tal é exigido devido à possibilidade de o originador não estar disponível no momento em que a alteração é implementada.

processo

o processo CC é simples (prova 1). Um indivíduo tem uma ideia ou encontra um erro no sistema atual. Este indivíduo deve documentar suas conclusões sobre um pedido de mudança de empresa (ECR), um formulário utilizado para registrar todos os bugs, mudanças ou melhorias para o projeto dado. O pedido de mudança é encaminhado para pares e supervisores para revisão e, em seguida, aprovado e implementado.

exibe 1-processo simples de controlo de configuração

documentação de alteração

documentar a mudança é a parte mais crítica de um sistema de controlo de configuração. O pormenor da documentação não é tão importante como a informação que está a ser documentada. No entanto, as informações documentadas devem descrever a alteração e incluir, no mínimo, as seguintes informações. Os requisitos mínimos para a documentação são:

claro que, quanto mais informação contida na documentação, o que é mais fácil recriar, recuperar, analisar e corrigir. Além disso, isso ajudará na documentação final para a entrega de produtos.

quando um indivíduo descobre um erro ou um requisito no projeto atual, ele ou ela documenta a mudança necessária. Um pedido de mudança contém informações sobre o pedido e descreve o cenário que descobriu o erro, quem o descobriu, quando foi descoberto, e correções recomendadas. O pedido também deve identificar os itens de configuração afetados, se possível, e colocar algum tipo de gravidade ou código de prioridade para identificar quando essa alteração, se aprovada, deve ocorrer.

a aprovação de alterações

a aprovação de alterações deve provir de um supervisor de projecto designado com uma visão “global” do impacto das alterações. Uma análise interpares é um meio altamente eficaz de verificar todas as facetas da mudança e assegurar que todas as áreas afectadas pela mudança sejam abordadas. Ter o cliente de acordo com a mudança seria benéfico para melhorias. No entanto, em pequenos projetos de desenvolvimento, a maioria das mudanças são de um tipo de “correção de bugs” e o cliente não veria o impacto da mudança.

recolha de dados

a recolha de dados é vital para a recuperação de informações sobre itens similares e para a descoberta de tendências e tendências. Esta informação deve residir electronicamente, o que permite uma fácil recuperação de dados e manipulação de dados para a Contabilidade de estado e métricas. A informação pode ser usada para compilar um relatório “lições aprendidas”, que é distribuído por toda uma organização para melhoria técnica.

Implementação De Alterações.

uma vez recebidas todas as aprovações adequadas, inicia-se a tarefa de implementação. O teste em cada etapa da implementação verifica que os impactos a outros aspectos do programa são mínimos. Todos os testes são concluídos e a mudança é implementada em todo o programa.

processo de ciclo fechado

um processo de ciclo fechado no qual o originador da mudança saberá o resultado final da mudança antes de aparecer no produto final é um componente chave para o sucesso. Isto aplica-se a todos os tipos de indústrias, da construção à fabricação ao software.

este processo de ciclo fechado cria quadros de controlo com papéis diferentes no processo de mudança (prova 2). Cada conselho tem a obrigação de rever uma alteração no contexto completo da sua carta e de chegar a uma decisão definitiva para cada alteração. É claro que o conselho pode exigir informações adicionais antes de tomar essa decisão, mas isso deve ser mínimo.

o Instituto de gestão da configuração (ICMHQ) ensina a metodologia CMII (CMIIU) para a gestão da configuração e desenvolveu esta visão de um processo de mudança de ciclo fechado. Este processo começa e termina com o item final. Note que a administração de mudança de configuração aparece em três níveis diferentes dentro do loop. Cada área é definida de forma diferente e tem funções e responsabilidades específicas.

• revisão técnica — garante que todas as avaliações de detalhe e análise de viabilidade estão completas.
• the Change Review Board ( CRB) – evaluate the business impact of the change. Esta mudança é válida para o nosso ambiente de negócios? Cumpre um dos nossos objectivos estratégicos? Encaixa – se na nossa Declaração de visão? Com uma alteração aprovada, o CRB pode indicar ou não um prazo para a alteração, dependendo da previsão competitiva e do risco de Negócio.
• o Comité de implementação das alterações (CIB) – atribui o financiamento necessário e determina os prazos de execução das alterações. Isto também inclui a atribuição de efetividade para a mudança, que especifica quando a mudança é efetiva. A efetividade pode estar relacionada a uma data, Construção, número de série, ou número de lote. Isto depende do item final.

a opção de faixa rápida do loop é onde toda a dor do CC é liberado e os proprietários podem obter uma alteração aprovada em minutos versus dias. A chave para isso é, naturalmente, uma árvore de documentação adequada para cada produto. Cada documento deve ter um criador e usuário atribuído a eles. Se as alterações apenas impactarem a documentação de baixo nível, então o caminho acelerado está em ordem e a mudança grita através do processo CC.

resumo

a chave para qualquer processo de controle de configuração bem sucedido é o buy-in de toda a equipe do projeto. Os membros da equipa não devem ser convidados a renunciar a um julgamento e controlo sólidos em nome de uma infra-estrutura de gestão que não esteja concebida para satisfazer os requisitos do projecto em questão. Os processos de controle de configuração são projetados para reduzir o risco de falha e garantir que as prestações sejam cumpridas no tempo e no orçamento. Se a equipe do projeto participar no estabelecimento do quadro de controle de configuração inicial-a participação e aceitação em toda a equipe do projeto é acelerada e a infra-estrutura estabelecida irá apoiar os objetivos de Negócio.