Gestão de Configuração & Mudanças 1. Introdução & Conceituação Márcio Aurélio Ribeiro Moreira marcio.moreira@pitagoras.com.br http://si.lopesgazzani.com.br/docentes/marcio/

Introdução

Cenário 1 Mudança: Problema típico: Topologia: Queremos separar o campo sobrenome do campo nome existente em 3 aplicações da empresa Problema típico: As aplicações: Estão em 3 plataformas diferentes Estão em 3 localizações geográficas diferentes Elas são mantidas por 3 equipes de desenvolvimento diferentes Topologia: Pagamentos UNIX Brasília Versão 1.1 Logística Windows Uberlândia Versão 8.4 ERP Linux São Paulo Versão 6.6 Fonte: Adaptado de RAM03

Problema 1 Cada software tem no mínimo 3 projetos em andamento: Uma versão para correção de bugs Uma versão para melhorias Uma versão para adaptação a leis Além disto, cada um dos projetos tem pelo menos 5 estados: Em definição Em desenvolvimento Em teste Em produção Em mudança Tente gerenciar tudo isto sem metodologia e sem ferramentas! O mundo real é sempre mais complicado!

Cenário 2 Produção: Fabricante: Projetos: Problema 2: Temos um ERP rodando na empresa 6 anos, na implantação fizemos algumas customizações no produto original Fabricante: O fabricante já tem 2 novas versões e está começando a falar que irá descontinuar a versão que estamos utilizando Projetos: Temos 8 projetos em andamento: 4 tratando novos produtos e ofertas que devem ser concluídas para suas respectivas campanhas, os outros 4 são projetos de melhorias e mudanças menores Problema 2: O governo baixou uma resolução que entra em vigor em 4 meses que requer uma boa adequação na versão em produção ou adoção da versão mais nova do fabricante. O que é melhor fazer?

Cenário 3 Software: Suporte: Manutenção: Problema 3: Uma empresa tem um software instalado em mais de 350 clientes no pais Existem 4 versões, com 3 compilações cada uma, rodando nos clientes Suporte: A central de suporte da empresa tem a missão de recuperar o nível de serviço o mais breve possível quando um Incidente ocorre Quando vários Incidentes semelhantes ocorrem o Problema causador deles deve ser resolvido, isto requer reprodução do Incidente, identificação da causa e pelo menos uma nova compilação é gerada Manutenção: Existem 5 projetos em andamento: 4 de clientes e uma versão nova Problema 3: Como gerenciar e manter o nível de serviço de suporte e manutenção?

Principais desafios da GCM Desenvolvimento e Manutenção: Qual é o código fonte corrente? Quem será afetado por uma mudança? O que realmente está mudando? Como internalizar as mudanças internas com as novas versões do fabricante? Produção e Operação: Todos os componentes corretos vão ser migrados juntos? Tudo foi suficientemente testado? O que realmente causou o problema? Como nós recuperaremos o ambiente? Como nós permitimos uma mudança emergencial? Por que este bug antigo voltou em produção outra vez?

Necessidades Planejamento: Projeto: Desenvolvimento: Testes: Precisamos ser capazes de prever o esforço, a duração, as dependências e a análise de impacto do trabalho Projeto: Precisamos ser capazes de colher, acordar e projetar a melhor solução Desenvolvimento: Precisamos ser capazes de suportar o desenvolvimento paralelo, detectando conflitos e eliminando as regressões a problemas já resolvidos Testes: Precisamos ser capazes de simular o comportamento em produção Distribuição: Precisamos ser capazes de gerir as mudanças em projeto e em produção Precisamos ser capazes de gerar um instalador, integrando os vários componentes do software, para sermos capazes distribui-lo automaticamente Gestão: Precisamos ser capazes de suportar as versões existentes do software e, se for necessário, recriar o ambiente de uma determinada versão

Conceituação

Foco da GCM da Engenharia de Software Ciclo de Vida do Software Focos Diferentes Estratégia Projeto Transição Operação Melhoria ou Retirada GCM da ESOF (RUP/SWEBOK): A Gestão de Configuração e Mudança da Engenharia de Software está focada na etapa de Projeto GCM do ITIL: A Gestão de Configuração e Ativos de Serviços (SACM) e a Gestão de Mudanças (CM) estão focadas na Transição e tem o propósito de controlar as versões e as mudanças da DML

Principais Aspectos da GCM Cubo de GCM Dimensões da GCM Gestão de Configuração: Controlar os itens que definem a configuração do software Gestão de Mudanças: Controlar as mudanças durante o desenvolvimento do software Contabilização (medições): Controlar a correção de defeitos durante o desenvolvimento Controle de Versões: O que foi feito, por quem, quando? Seleção de Versões: Qual versão do artefato deve ser usada na implementação ou mudança Distribuição do Software: Automação da compilação, teste e compactação para distribuição Fonte: RUP

Gestão de Configuração e Mudanças Cadeia de valor de GCM Ambiente Gestão de Projetos Distribuição Testes Implementação Análise e Projeto Requisitos Modelagem de Negócios Gestão de Configuração e Mudanças As atividades dos processos de Gestão de Configuração e Mudanças se integram às demais disciplinas: Modelagem de Negócio Requisitos Análise e Projeto Implementação Testes Distribuição Gestão de Projetos Ambiente

Gestão de Configuração A configuração de um sistema é o conjunto formado pelas características funcionais e/ou físicas do software, hardware e firmware, ou uma combinação deles, que definem uma determinada versão do software. A configuração também pode ser pensada como uma coleção de versões específicas de Itens de Configuração (CIs: hardware, firmware e itens do software) combinados por procedimentos específicos para atingirem um propósito particular. Gestão de Configuração: É a disciplina que visa identificar e documentar as características físicas e funcionais dos CIs (Itens de Configuração) do sistema ao longo do ciclo de vida dele, bem como registrar, processar e controlar mudanças dessas características, e verificar a conformidade com os requisitos especificados. Fonte: Adaptado de SWEBOK

Sobre o processo de GCM Propósito: Problemas: Benefícios da GCM: Controlar e sincronizar a evolução do conjunto de Produtos de Trabalho que compõem o sistema de software Problemas: Atualização simultânea: Quando 2 ou mais pessoas trabalham concorrentemente Notificação limitada: A correção feita por uma pessoa não chega para outro Múltiplas versões: A maioria dos projetos tem “n” versões Benefícios da GCM: Suporta métodos de ESOF Mantém a integridade do produto Assegura integralidade e correção do produto configurado Fornece um ambiente estável para desenvolvimento do produto Restringe as alterações nos Produtos de Trabalho de acordo com as políticas do projeto Fornece auditoria acompanhando o porque, quando e por quem foi feita alteração nos Produtos de Trabalho

Conceitos Espaço de Trabalho: Linha de Base: Área privada que contém o código que um desenvolvedor está codificando e testando em isolamento relativo de outros desenvolvedores e de acordo com os padrões adotados para o projeto. Linha de Base: É o armazenamento da situação atual (foto ou snapshot) de uma versão dos CIs (produtos de trabalho), para fornecer um ponto de referência no qual o trabalho subsequente deve ser baseado e para o qual somente mudanças autorizadas podem ser efetuadas. Podem ser: funcional, atribuída, de desenvolvimento e de produto

Atividades do Processo de GCM Planejar e Gerir a GCM Identificar a Configuração Controlar a Configuração Contabilizar a Configuração Auditar a Configuração Gerir Versões e Distribuição

Atividade: Planejar e Gerir a GCM Tarefas: Entender o contexto organizacional Levantar restrições para definir o Guia do Processo Planejar a GCM: Responsabilidades e organização Agendas e recursos Seleção e implementação de ferramentas Controle de fornecedores e subcontratados Controle de interfaces Fazer o Plano de Gestão de Configuração Monitorar a GCM: Métricas e medidas Inspeções e auditorias

Atividade: Identificar a Configuração Tarefas: Identificar itens a serem controlados: Levantar a configuração do software (linha base) Catalogar todos os CIs (fontes, documentos, ferramentas, etc.) Catalogar as relações (todo-parte, dependências, etc.) entre os CIs (impacto de CRs e rastreabilidade) Catalogar a versão dos CIs Definir uma Linha de Base Colocar os CIs na Linha de Base ao longo do projeto (vide figura), após isto somente com CR para muda-lo Criar e manter biblioteca do software (trabalho, principal, etc.) Fonte: SWEBOK

Atividade: Controlar a Configuração Tarefas (Gestão de Mudanças): Requerer, avaliar e aprovar mudanças no software: Comitê de Controle de Configuração do Software Processo de Solicitação de Mudanças do Software Implementar mudanças no software Desviar e renunciar mudanças Conceito: Mudança é o processo de movimentação (inclusão, alteração ou exclusão) autorizada de Itens de Configuração (CI) que já tenha sido definido e/ou aprovado.

Tipos de Mudanças Melhoria (Improvement): Problema (Issue): Comportamento inadequado do software. É a classificação inicial de um bug ou melhoria. Falha (Bug): Resultado incorreto do software gerado por um erro (de programação ou requisitos), engano, defeito ou falta de conhecimento das ferramentas. Melhoria (Improvement): Requisição de uma melhoria em uma funcionalidade existente. Requisição de uma nova funcionalidade do software. Requisito (Requirement): Novas funcionalidades ou novos recursos do software Tarefa (Task): Solicitação de algo que deve ser feito (funcional ou não). Ex.: Upgrade de hardware, atualização do Sistema Operacional. Fonte: Jiří Janák - Issue Tracking Systems

Severidade e Benefícios das Mudanças Bloqueadora (show stopper): Bloqueia o desenvolvimento, os testes ou a produção inteiros Crítica (critical): Impede o funcionamento de um subsistema inteiro Maior (major): Impede o funcionamento de uma funcionalidade Menor (minor): Afeta uma funcionalidade, mas existe uma solução de contorno Trivial (cosmetic): Um problema cosmético Benefícios: Melhora a qualidade do software Aumenta a satisfação dos usuários e dos clientes Garante a responsabilização das requisições Melhora a comunicação na equipe e com os clientes Aumenta a produtividade da equipe Reduz as despesas

Processo Completo de Gestão de Mudanças Utilizado para mudanças complexas, de alto impacto e alto risco. Requer Aprovação da Análise de Impacto

Tarefas da Atividade de Controlar a Configuração Gerar ou Atualizar a Mudança: Determinar quais mudanças devem ser solicitadas Avaliar Mudança: Verificar se a mudança está bem formulada e entendida Aprovar Análise de Impacto: Decidir se a análise de impacto deve ser feita ou não Analisar Impactos da Mudança: Avaliar os impactos da mudança no projeto (escopo, prazo, custo e qualidade) e no negócio Revisar Impactos: Decidir se a mudança vai ser feita Executar a Mudança: Modificar os planos e executar a mudança no contexto do projeto Revisar Mudança: Verificar se a mudança foi corretamente implementada e fechá-la Notificar Solicitante: Notificar o solicitante que a mudança não foi aprovada

Processo Normal de Gestão de Mudanças Utilizado para mudanças simples, de médio impacto e de risco médio. Não Requer Aprovação da Análise de Impacto

Processo Pré-Aprovado de Gestão de Mudanças Utilizado para correção de erros, mudanças de baixíssimo impacto e baixo risco.

Comitê de Controle de Mudanças Projetos e/ou Empresas Pequenas: Esta responsabilidade pode ser atribuída ao Cliente ou ao Gerente de Projetos (dependendo da forma do contrato). Projetos e/ou Empresas Médias: Deve envolver os Clientes, pelo menos um representante dos usuários e o Gerente de Projetos. Projetos e/ou Empresas Grandes: Deve envolver os Patrocinadores, os Clientes, representantes dos usuários, o Gerente do Projeto, o Arquiteto de Software e outros especialistas (convidados sob demanda para o Comitê). Em mudanças que afetam a estratégia do negócio, deve envolver também o CEO (Presidente) e Chairman (Presidente do Conselho de Acionistas). Recomendação: Utilizar número ímpar de membros e ferramenta de votação e controle de mudanças.

Estados das Mudanças Fonte: Jiří Janák - Issue Tracking Systems

Questões importantes sobre as mudanças Os 7 Rs das Mudanças Estados das Mudanças Quem requisitou? Requisitante Qual a razão? Razão Qual o retorno esperado dela? Retorno Quais os riscos envolvidos? Riscos Quais os recursos necessários? Recursos Quem a executará? Responsável Quais as RFCs relacionadas? Relações Aberta Duplicidade Verificada Conselho (alocada para o Comitê) Rejeitada (pelo Comitê ou GP) Adiada: Não será avaliada agora Planejada (para execução) Atribuída (em execução) Erro Conhecido: Causa e solução de contorno conhecidos Executada (corrigida) Verificada (pelo solicitante) Fechada

Dicas sobre bugs Relatando bugs Requisitos de ferramentas Escreva um bom sumário Explique como reproduzir o problema Se duas falhas forem percebidas, abra 2 bugs Não detalhe os passos óbvios (simplifique) Se depois de relatar, variantes forem percebidas, acrescente-as no bug aberto Facilidade de instalação e configuração inicial Interface com o usuário e curva de aprendizado Sistema de submissão Gestão do projeto Monitoramento e análise Integração Acessibilidade e extensibilidade

Atividade: Contabilizar a Configuração Tarefas: Informar a situação da configuração do software Capturar e reportar informações Normalmente, requer softwares para isto Reportar a situação da configuração do software Os relatórios produzidos são utilizados por pessoas de: desenvolvimento, gestão de projetos, qualidade e manutenção Ex.: # mudanças, tempo de implementação, etc.

Atividade: Auditar a Configuração Tarefas: Auditar a configuração funcional do software: As funcionalidades estão de acordo com os requisitos de governança? Auditar a configuração física do software: O projeto e a documentação são consistentes com o produto? Auditar o processo de uma linha de base do software: O desenvolvimento está ocorrendo como previsto?

Atividade: Gerir Versões e Distribuição Tarefas: Construir o software: Combinar as versões dos diversos CIs (componentes, hardware, ferramentas, dados, etc.) para entregar uma versão do software Gerir versões do software: Empacotar uma versão do software com a documentação de instalação e o instalador Isto requer a sincronização do projeto com projetos paralelos e forte gestão de mudanças para entregar uma versão do software que seja utilizável

Ferramentas de GCM Controle de Versões Gestão de Mudanças Open Source: SVN (SubVersion) CVS (Concurrent Versions System) GIT Comerciais: ClearCase (IBM) SourceSafe/Team Foundation System (Microsoft) StarTeam (Borland) Open Source: JIRA Trac e jTrac Bugzzila Comerciais: ClearQuest (IBM) StarTeam (IBM) Team Foundation System (Microsoft) CodeBeamer (Intland) Fonte: Wiki - Comparison of Revision Control Software Fonte: Jiří Janák - Issue Tracking Systems

Referências Sigla Referência CAT11 Cataldo Basile. Policy chains: the PoSecCo approach to policy management in Future Internet. Politecnico di Torino. 2011. JGT04 Jean-Pierre Garbani, Galen Schreck & Thomas Powell. Case Study: Autonomic Software. Policy Based, Cross-Platform System Management. Forrester. 2004. JIR09 Jiří Janák. Issue Tracking Systems. Masaryk University. Faculty Of Informatics. 2009. JRS12 Jon Dowell & Roland Sabourin. Change Management Practitioners Forum. itSMF. 2012. MBA05 Markus Bäker, Bernd Zakel & Achim Grindler. IWR-3D Management Portal, a WIKI based Change- and Configuration Management Tool. HEPiX. 2005. PAW12 Paul Wasilewski. Learning from Failure: Managing Changing Requirements on the Apollo 13 Mission. UT Dallas. 2012. PTC06 Parametric Technology Corporation. Change and Configuration Management. PTC. 2006. PRO11 ProcessDox. Configuration, Change and Release Management Policies and Procedures Guide. ProcessDox. 2011. PDT11 Prodater. Política Gestão de Configuração e Mudança. Prodater. 2011. RAM03 Rama Versani (CA). An Enterprise Approach to Change & Configuration Management. BCS CMSG Conference, 2003. SOU04 Reginaldo Pereira de Souza. Práticas de Gerência de Configuração. Universidade São Francisco. 2004. SHE10 Sheheryar Muftee. Change and Configuration Management at AITS. IT Professionals Forum. 2010. WIK13 Wikepedia. Comparison of revision control software. Wiki. 2013.