Gestão de Configuração & Mudanças 1. Introdução & Conceituação

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

2. Introdução

3. Cenário 1 • Mudança: • 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: Fonte: Adaptado de RAM03

4. 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!

5. Cenário 2 • Produção: • 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?

6. Cenário 3 • Software: • 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?

7. 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?

8. Necessidades • Planejamento: • 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

9. Conceituação

10. Foco da GCM da Engenharia de Software Ciclo de Vida do Software Focos Diferentes 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

11. 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

12. Cadeia de valor de GCM • 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

13. Gestão de Configuração • 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

14. Sobre o processo de GCM • Propósito: • 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

15. Conceitos • Espaço de Trabalho: • Á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

16. Atividades do Processo de GCM

17. 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

18. 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

19. 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.

20. Tipos de Mudanças • 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 - IssueTracking Systems

21. 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

22. 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

23. 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

24. 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

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

26. 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.

27. Estados das Mudanças Fonte: JiříJanák - IssueTracking Systems

28. Questões importantes sobre as mudanças Os 7 Rs das Mudanças Estados das Mudanças 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

29. Dicas sobre bugs Relatando bugs Requisitos de ferramentas 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 • 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

30. 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.

31. 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?

32. 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

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

34. Referências