O processo de gestão de mudança na engenharia de sistemas é o processo de requisitar, determinar o alcançável, planejar, implementar, e avaliar as mudanças para um sistema, seu objetivo principal é prestar apoio ao processamento e rastreabilidade de mudanças para um conjunto de fatores interconectados.Crnkovic, Asklund & Persson-Dahlqvist, 2003

Introdução Há uma considerável similaridade e confusão entre a gestão de mudança, a gestão de controle, e a gerência de configuração de software; a definição abaixo não integra essas áreas. Gestão de mudança foi adotada pela sua capacidade de fornecer benefícios através da melhoria do sistema afetado e assim satisfazendo as "necessidades do cliente", porem ainda é criticado pelo potencial em confundir e complicar de forma desnecessária a gestão de administração. Em alguns casos, perceptível principalmente na area de tecnologia da informação, mais fundos e mais trabalho são alocados na manutenção de sistemas (e na gestão de mudança) em relação para com a criação do sistema.Dennis, Wixom & Tegarden, 2002. É investido tipicamente por organizações durante a implementação inicial de grandes sistemas ERP cerca de 15% à 20% da verba total.

Seguindo o mesmo raciocínio, HinleyHinley 1996. descreve duas das leis de Lehman sobre a evolução do software. A lei da mudança continua: Sistemas utilizados devem mudar, ou então automaticamente se tornar menos útil. A lei da complexidade crescente: Através de mudanças, a estrutura do sistema se torna mais complexa, e mais recursos são necessários para simplifica-las. A gestão de mudança é também de grande importância no campo da manufatura, o qual é confrontado com muitas mudanças devido a crescente competição mundial, avanços tecnológicos e a demanda de clientes.Huang & Mak, 1999. Já que muitos sistemas tendem a mudar e evoluir conforme são usados, os problemas dessas indústrias são sentidos de alguma forma em muitas outras.

O processo e os resultados Para a descrição do processo de gestão da mudança, a técnica de meta-modelagem é utilizada. A Figura 1 representa o diagrama de processo de dados, que é explicado nessa seção. 1071x1071px|Figura 1: Modelo de processo de dados para o processo de gestão de mudança

Atividades

Há seis atividades principais, as quais formam em conjunto o processo de gestão de mudança. Eles são: Identificar possíveis mudanças, Avaliar mudanças, Planejar mudança, Implementar mudanças e Rever e encerrar mudanças. Essas atividades são executadas por quatro papéis diferentes, os quais são discutidos na Tabela 1. As atividades (ou suas sub-atividades, se aplicável) são descritas em si na Tabela 2.

+ Tabela 1: Descrição de papéis para o processo de gestão de mudança Papel DescriçãoClienteO cliente é o papel o qual requisita a mudança devido a problemas encontrados ou requirimento para alguma nova funcionalidade; podendo ser esse papel uma pessoa ou uma entidade organizacional e pode ser interno ou externo à companhia a qual é solicitada para implementar a mudança.Gerente de projetoO gerente de projeto é o dono do projeto que a REQUISIÇÃO DE MUDANÇA interessa. Em alguns casos a de ter um gestor de mudança distinto, o qual neste caso assume este papel.Comitê de mudançaO comitê de mudança decide se a REQUISIÇÃO DE MUDANÇA ira ou não ser implementada. Algumas vezes essa tarefa é executada também pelo gerente de projeto.Construtor de mudançaO construtor de mudança é a pessoa que planeja e implementa a mudança; pode ser argumentado que o componente de planejamento é (parcialmente) tomado pelo gerente de projeto.

+ Tabela 2: Descrição de atividades para o processo de gestão de mudanças Atividade Sub-atividade DescriçãoIdentificar possíveis mudançasRequer nova funcionalidade Na realidade, ambos Requer nova funcionalidade e Problema encontrado não tem de ocorrer em ordem para se REQUISITAR MUNDANÇA; usualmente somente um dos dois ira. Modelando eles como atividades desordenadas aproximadamente aborda esse significado; uma alternativa seria criar dois ‘pontos iniciais’ separados, ambos apontandos para Requisitar mudança.Um cliente deseja uma nova funcionalidade e formula um REQUERIMENTO.Problema encontradoUm cliente encontra um problema (ex. um bug no sistema sistema e isto leva a REPORTAR PROBLEMA.Requisitar mudançaUm cliente propoe uma mudança através da criação de REQUISIÇÃO DE MUDANÇAAnalisar requisição de mudançaDeterminar viabilidade técnicaO gerente de projeto determina a viabilidade técnica da REQUISIÇÃO DE MUDANÇA proposta, levando então à GESTÃO DE VIABILIDADE TÉCNICA.Determinar custos e benefíciosO gerente de projeto determina os custos e benefícios da REQUISIÇÃO DE MUDANÇA proposta, resultando na GESTÃO DE CUSTO-BENEFÍCIO. Isso e a sub-atividade acima podem ser feitos em qualquer ordem, e são implementados independentes um do outro, e por consequência a modelagem como atividade desordenada.Avaliar mudançaBaseado na REQUISIÇÃO DE MUDANÇA, e suas GESTÃO DE VIABILIDADE TÉCNICA e GESTÃO DE CUSTOS-BENEFÍCIO, o comitê de mudança faz a decisão de aprovar ou não a mudança. Isso é modelado como atividade separada, já que é um processo de passo importante e há outros papéis atuando nele. É modelado como sub-atividade (sem nenhuma atividade contendo-o) como recomendado por Remko Helms (comunicação pessoal).Planejar mudançaAnalisar impacto da mudançaA extensão da mudança (isto é, qual outros items a mudança afeta) é determinado na GESTÃO DE ANALISE DE IMPACTO. Pode ser argumentado que esta atividade se dirige para outra decisão de aprovar ou não, ou que isso ainda forme alguma parte da Analisar requisição de mudança. É modelado aqui como uma tarefa de planejamento para o gestor de construção, já que por sua causa a relação com a atividade Propagar mudança.Criar planejamentoUm PLANEJAMENTO DE MUDANÇA é criado para a implementação da mudança. Algumas descrições de processos (ex. Mäkäräinen, 2000) afirma que também é possível ‘salvar’ mudanças e processos para depois em um lote. Essa atividade pode ser vista como uma boa maneira de fazer isso.Aplicar mudançasExecutar mudançasA mudança é ‘programada’; essa atividade tem um relação forte para com o Propagar mudança, já que algumas vezes a mudança tem de ser adaptada para outras partes do sistema (ou até outros sistema).Propagar mudançaAs mudanças resultantes do Executar mudanças tem de ser propagadas para outras partes do sistema que são influenciados por ela. Já que essa sub-atividade e acima são altamente dependentes uma da outra, elas foram modeladas como atividades concorrentes.Teste de mudançasO construtor de mudanças testa se o que ele construiu funciona e se satisfaz o REQUISITAR MUDANÇA. Como descrito no diagrama, isso pode em um processo iterativo junto com ambas as sub-atividades acima.Atualizar documentaçãoA DOCUMENTAÇÃO é atualizada para refletir a mudanças aplicadas.Liberação das mudançasUma nova RELEASE DO SISTEMA, a qual foi aplicada tal mudança, vem a público.Rever e encerrar mudançasVerificar mudançaA implementação da mudança na nova RELEASE DO SISTEMA é verificada uma última vez, agora pelo gerente de projeto. Talvez isso a de acontecer antes da liberação, porem devido ao conflito de fontes bibliográficas e diagramas de considerável complexidade, foi escolhido em modelar isso dessa maneira e incluir este pensamento.Encerrar mudançaEste ciclo de mudanças esta completo, isto é, o LOG DE ENTRADA DE MUDANÇAS esta envolto.

Entregas Além das atividades, o diagrama de processo de dados (Figura 1) mostra também as entregas de cada atividade, ou seja, seus dados. Essas entregas ou conceitos são descritos na Tabela 3; nesse contexto, os conceitos mais importantes são: REQUISIÇÃO DE MUDANÇA e o LOG DE ENTRADA DE MUDANÇA.

Que fique claro, alguns desses conceitos foram definidos pelo author (pela falta de referência), porque (boas) definições não foram encontradas, ou elas eram o resultado obvio de alguma atividade. Esses conceitos então marcados com um asterisco (‘*’). Conceitos de propriedade foram deixados de fora do modelo, já que muitos eram triviais e o diagrama poderia, de outra forma, rapidamente se tornar complexo demais. Além disso, alguns conceitos (ex: REQUISIÇÃO DE MUDANÇA, RELEASE DO SISTEMA) se dirigiam guiados pelo sistema de controle de versão como proposto por Weerd,Weerd 2006 porem isso também foi deixado de fora devido a restringir a complexidade do diagrama.

+ Tabela 3: Descrições de conceitos para o processo de gestão de mudança Conceito DescriçãoREQUERIMENTOUma funcionalidade requirida de algum componente (ou item; NASA, 2005).REPORTAR PROBLEMADocumento descrevendo um problema o qual não pode ser resolvido pelo auxilio de empregados de mesa de nível 1; contem itens como data, informação de contato da pessoa reportando o problema, o que esta causando o problema, localização e descrição do problema, ação tomada e disposição, mas isso não esta retratado no diagrama (Dennis, et al., 2002).REQUISITAR MUDANÇADocumento que descreve a mudança necessária e o por que dela ser importante; pode se originar do REPORTAR PROBLEMA, melhorias do sistema, outros projetos, mudanças nos sistemas subjacentes e da alta administração, aqui é sumarizado os REQUIRIMENTOS (Dennis, et al., 2002). Atributos importantes são definidos pela decisão de aprovar ou não, ou seja, as mudanças irão ser feitas, sim ou não?LOG DE ENTRADA DE MUDANÇAS*Entrada distinta no conjunto de todas as alterações (ex: para algum projeto); consiste de uma REQUISIÇÃO DE MUDANÇA, GESTÃO DE VIABILIDADE TÉCNICA, GESTÃO DE CUSTO-BENEFÍCIO, GESTÃO DE ANALISE DE IMPACTO, RELATÓRIO DE TESTE e GESTÃO DE VERIFICAÇÃO. Nem todos esse são necessários incluir no processo se ele for encerrado antes (ex: se mudança não for implementada).GESTÃO DE VIABILIDADE TÉCNICAConceito que indica se "software e hardware confiáveis, recursos técnicos capazes de satisfazer as necessidades proposta pelo sistema (isto é, a mudança requisitada) podem ser adquiridas ou desenvolvidas por alguma organização no tempo necessário" (Vogl, 2004).GESTÃO DE CUSTO-BENEFÍCIOO esforço esperado necessário para implementar e as vantagens (ex: redução de custos, aumento de lucros) ganhas pela implementação de tal mudança. Conhecido também como viabilidade econômica (Vogl, 2004).GESTÃO DE ANALISE DE IMPACTOUma avaliação da extensão da mudança (Rajlich, 1999).GESTÃO DE PLANEJAMENTO“Um esquema, método ou projeto para a realização de algum objetivo ou conquistar algo” (Georgetown University, s.d.), nesse caso, a mudança.ITEM“Um termo não especifico usado para denotar qualquer produto, incluindo sistemas, sub-sistemas, unidades, conjuntos, acessórios, programas de computador, software de computador ou partes” (Rigby, 2003); há dois subtipos ITEM ADICIONADO e ITEM ALTERADO.ITEM ADICIONADO*Auto-explicativo: um ITEM recém criado, subtipo de ITEM.ITEM ALTERADO*Auto-explicativo: um ITEM que já existe, mas que foi alterado; subtipo de ITEM.RELATÓRIO DE TESTE“Um documento que descreve a conduta e os resultados do teste realizado no sistema ou componente. [afetado pela mudança]” (IEEE, 1991).DOCUMENTAÇÃODe acordo com as Bibliotecas da Universidade do Estado da Pensilvânia (2004), uma DOCUMENTAÇÃO é “material impresso o qual acompanha outros materiais (normalmente algo que não seja um livro), o qual explica, fornece instruções para uso, aso contrário, funciona como um guia para os materiais principais.” Nesse contexto, ele também pode ser para materiais digitais ou até treinamentos, contanto que ele relacione para com (pedaços do) o sistema.RELEASE DO SISTEMA“Mercadoria emitida para a vendo ou demostração publica” (Princeton University, 2003). Consiste de um ou mais ITENS e o acompanhamento da DOCUMENTAÇÃO.GESTÃO DE VERIFICAÇÃOA determinação de que se o resultado da implementação da mudança cumpre os requisitos estabelecidos anteriormente (Rigby, 2003).