Gestão de mudança (engenharia)

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.

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. É 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, Hinley 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. 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.

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ção
Cliente	O 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 projeto	O 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ça	O 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ça	O 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ção
Identificar possíveis mudanças	Requer nova funcionalidade	Um cliente deseja uma nova funcionalidade e formula um REQUERIMENTO.
	Problema encontrado	Um cliente encontra um problema (ex. um bug no sistema sistema e isto leva a REPORTAR PROBLEMA.
	Requisitar mudança	Um cliente propoe uma mudança através da criação de REQUISIÇÃO DE MUDANÇA
Analisar requisição de mudança	Determinar viabilidade técnica	O 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ícios	O 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ça		Baseado 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ça	Analisar impacto da mudança	A 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 planejamento	Um 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ças	Executar mudanças	A 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ça	As 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ças	O 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ção	A DOCUMENTAÇÃO é atualizada para refletir a mudanças aplicadas.
	Liberação das mudanças	Uma nova RELEASE DO SISTEMA, a qual foi aplicada tal mudança, vem a público.
Rever e encerrar mudanças	Verificar mudança	A 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ça	Este 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, 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ção
REQUERIMENTO	Uma funcionalidade requirida de algum componente (ou item; NASA, 2005).
REPORTAR PROBLEMA	Documento 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ÇA	Documento 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ÉCNICA	Conceito 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ÍCIO	O 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 IMPACTO	Uma 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ÇÃO	De 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ÇÃO	A determinação de que se o resultado da implementação da mudança cumpre os requisitos estabelecidos anteriormente (Rigby, 2003).

Além de somente ‘mudanças’, também é possível distinguir desvio ou renuncia. Um desvio é uma autorização (ou requisição) para poder desviar do requerimento de um item, antes da criação do mesmo. Uma renuncia é basicamente o mesmo, porem ocorrendo durante ou depois da criação de um item. Essas duas abordagens podem ser vistas como gestão de mudanças minimalísticas (isto é, sem solução real para o problema em mãos).

Exemplos

Um bom exemplo do processo de gestão da mudança em ação pode ser encontrado no desenvolvimento de software. Frequentemente os usuários reportam bugs ou o desejo de uma nova funcionalidade nos seus programas de software, o que leva a uma solicitação de alteração. A empresa de software do produto, então olha para a viabilidade técnica e econômica de implementar essa mudança e, consequentemente, decide se a mudança será realmente realizada. Se isso de fato for o caso, a mudança tem que ser planejada, por exemplo através da utilização de pontos de função. A execução real da mudança leva à criação e/ou alteração de código do software e quando esta mudança é propagada ela provavelmente faz com que outros fragmentos de código mudem também. Após os resultados dos testes iniciais parecerem satisfatórios, a documentação pode ser atualizada e liberada, em conjunto com o software. Finalmente, o gerente de projeto verifica a mudança e fecha esta entrada no log de alterações.

Outra área típica de gerenciamento de mudanças na forma como ele é tratado aqui é o domínio de fabricação. Tomemos por exemplo a concepção e produção de um carro. Se, por exemplo, os air bags do veículo são feitos para se encherem automaticamente depois de dirigir longas distâncias, isso vai sem dúvidas levar a reclamações dos clientes (ou pelo menos a relatórios de problemas durante a fase de testes). Por sua vez, estas produzem uma solicitação de alteração (ver figura 2 à direita), o que provavelmente irá justificar uma mudança. No entanto, a - muito provavelmente simplista - análise de custo e benefício tem de ser feito, após a qual o pedido de alteração pode ser aprovado. Seguindo uma análise do impacto sobre a concepção do automóvel e a agenda de produção, o planejamento para a implementação da mudança pode ser criado. De acordo com esse planejamento, a mudança pode realmente ser realizada, após a qual a nova versão do carro deveria ser exaustivamente testada antes de ser liberada para o público.

Em plantas industriais

Uma vez que os processos complexos podem ser muito sensíveis até mesmo a pequenas alterações, uma boa gestão da mudança para instalações industriais e processos é reconhecida como crítica para a segurança. Nos Estados Unidos, a OSHA tem normas que regem como as mudanças devem ser feitas e documentadas. O principal requisito é que uma revisão completa de uma alteração proposta deve ser realizada por uma equipe multidisciplinar para garantir que o maior número de pontos de vista possíveis são utilizados para minimizar as chances de não identificar uma ameaça. Nesse contexto, a gestão da mudança é conhecida como Gestão da Mudança, ou GDM. É apenas um dos muitos componentes da Gestão de Segurança de Processo, seção 1910.119(l).1

Ligações externas

• Crnković I., Asklund, U. & Persson-Dahlqvist, A. (2003). Implementing and Integrating Product Data Management and Software Configuration Management. London: Artech House.
• Dennis, A., Wixom, B.H. & Tegarden, D. (2002). System Analysis & Design: An Object-Oriented Approach with UML. Hoboken, New York: John Wiley & Sons, Inc.
• Georgetown University (n.d.). Data Warehouse: Glossary. Retrieved April 13, 2006 from: https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html.
• Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730.
• Huang, G.H. & Mak, K.L. (1999). Current practices of engineering change management in UK manufacturing industries. International Journal of Operations & Production Management, 19(1), 21-37.
• IEEE (1991). Standard Glossary of Software Engineering Terminology (ANSI). The Institute of Electrical and Electronics Engineers Inc. Retrieved April 13, 2006 from: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6.
• Mäkäräinen, M. (2000). Software change management processes in the development of embedded software. PhD dissertation. Espoo: VTT Publications. Available online: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf.
• NASA (2005). NASA IV&V Facility Metrics Data Program - Glossary and Definitions. Retrieved March 4, 2006 from: https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html.
• Pennsylvania State University Libraries (2004). CCL Manual: Glossary of Terms and Acronyms. Retrieved April 13, 2006 from: https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/ cataloging/ccl/glossary.htm.
• Princeton University (2003). WordNet 2.0. Retrieved April 13, 2006 from: http://dictionary.reference.com/search?q=release.
• Rajlich, V. (1999). Software Change and Evolution. In Pavelka, J., Tel, G. & Bartošek, M. (Eds.), SOFSEM'99, Lecture Notes in Computer Science 1725, 189-202.
• Rigby, K. (2003). Managing Standards: Glossary of Terms. Retrieved April 1, 2006 from: https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm.
• Scott, J.A. & Nisse, D. (2001). Software Configuration Management, Guide to Software Engineering Body of Knowledge, Chapter 7, IEEE Computer Society Press.
• Vogl, G. (2004). Management Information Systems: Glossary of Terms. Retrieved April 13, 2006 from Uganda Martyrs University website: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm.
• Weerd, I. van de (2006). Meta-modeling Technique: Draft for the course Method Engineering 05/06. Retrieved March 1, 2006 from: https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions for^{[ligação inativa]} the process-data diagram.pdf [restricted access].