Mtricas de Desenvolvimento e Custo de Software 3

  • Slides: 37
Download presentation
Métricas de Desenvolvimento e Custo de Software 3. Gestão de Configurações & Mudanças ©

Métricas de Desenvolvimento e Custo de Software 3. Gestão de Configurações & Mudanças © Márcio Moreira – 2017 – www. teraits. com/pitagoras/marcio/

Conseguimos impedir as mudanças? O que devemos fazer para trata-las?

Conseguimos impedir as mudanças? O que devemos fazer para trata-las?

Introdução

Introdução

Cenário 1 » Mudança: » Topologia: o Queremos separar o campo sobrenome do campo

Cenário 1 » Mudança: » Topologia: o Queremos separar o campo sobrenome do campo nome existente em 3 aplicações da empresa » Pagamentos • UNIX • Brasília • Versão 1. 1 Problema típico: o 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 ERP Logística • Linux • São Paulo • Versão 6. 6 • Windows • Uberlândia • Versão 8. 4 Fonte: Adaptado de RAM 03

Problema 1 » Cada software tem no mínimo 3 projetos em andamento: o Uma

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

Cenário 2 » Produção: o Temos um ERP rodando na empresa 6 anos, na

Cenário 2 » Produção: o Temos um ERP rodando na empresa 6 anos, na implantação fizemos algumas customizações no produto original » Fabricante: o O fabricante já tem 2 novas versões e está começando a falar que irá descontinuar a versão que estamos utilizando » Projetos: o 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 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: o Uma empresa tem um software instalado em mais de

Cenário 3 » Software: o Uma empresa tem um software instalado em mais de 350 clientes no pais o Existem 4 versões, com 3 compilações cada uma, rodando nos clientes » Suporte: o 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 o 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: o Existem 5 projetos em andamento: 4 de clientes e uma versão nova » Problema 3: o Como gerenciar e manter o nível de serviço de suporte e manutenção?

Principais desafios da GCM » Desenvolvimento e Manutenção: o o » Qual é o

Principais desafios da GCM » Desenvolvimento e Manutenção: o 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: o o 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: o Precisamos ser capazes de prever o esforço, a duração, as

Necessidades » Planejamento: o Precisamos ser capazes de prever o esforço, a duração, as dependências e a análise de impacto do trabalho » Projeto: o Precisamos ser capazes de colher, acordar e projetar a melhor solução » Desenvolvimento: o Precisamos ser capazes de suportar o desenvolvimento paralelo, detectando conflitos e eliminando as regressões a problemas já resolvidos » Testes: o Precisamos ser capazes de simular o comportamento em produção » Distribuição: o Precisamos ser capazes de gerir as mudanças em projeto e em produção o Precisamos ser capazes de gerar um instalador, integrando os vários componentes do software, para sermos capazes distribui-lo automaticamente » Gestão: 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

Conceituação

Foco da GCM da Engenharia de Software Ciclo de Vida do Software Focos Diferentes

Foco da GCM da Engenharia de Software Ciclo de Vida do Software Focos Diferentes » o A Gestão de Configuração e Mudança da Engenharia de Software está focada na etapa de Projeto Estratégia Melhoria ou Retirada Operação GCM da ESOF (RUP/SWEBOK): Projeto Transição » GCM do ITIL: o 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:

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

Gestãovalor de Configuração e Mudanças Cadeia de de GCM Modelagem de Negócios Requisitos Análise

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

Gestão de Configuração Fonte: SWEBOK » Configuração: o A configuração de um sistema é

Gestão de Configuração Fonte: SWEBOK » Configuração: 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. o 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: 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.

Sobre o processo de GCM » Propósito: o Controlar e sincronizar a evolução do

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

Conceitos » Espaço de Trabalho: o Área privada que contém o código que um

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

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: o Entender o contexto organizacional o

Atividade: Planejar e Gerir a GCM » Tarefas: o Entender o contexto organizacional o Levantar restrições para definir o Guia do Processo o 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 o Fazer o Plano de Gestão de Configuração o Monitorar a GCM: § § Métricas e medidas Inspeções e auditorias

Atividade: Identificar a Configuração » Tarefas: o Identificar itens a serem controlados: § §

Atividade: Identificar a Configuração » Tarefas: o 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 o Criar e manter biblioteca do software (trabalho, principal, etc. ) Fonte: SWEBOK

Atividade: Controlar a Configuração » Tarefas (Gestão de Mudanças): o Requerer, avaliar e aprovar

Atividade: Controlar a Configuração » Tarefas (Gestão de Mudanças): o 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 o Implementar mudanças no software o Desviar e renunciar mudanças » Conceito: o 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 » Problema (Issue): » o Comportamento inadequado do software. o É

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

Severidade e Benefícios das Mudanças » Bloqueadora (show stopper): o Bloqueia o desenvolvimento, os

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

Processo Completo de Gestão de Mudanças Utilizado para mudanças complexas, de alto impacto e

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: »

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

Processo Normal de Gestão de Mudanças Não Requer Aprovação da Análise de Impacto Utilizado

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

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

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: o Esta responsabilidade pode

Comitê de Controle de Mudanças » Projetos e/ou Empresas Pequenas: o Esta responsabilidade pode ser atribuída ao Cliente ou ao Gerente de Projetos (dependendo da forma do contrato). » Projetos e/ou Empresas Médias: o Deve envolver os Clientes, pelo menos um representante dos usuários e o Gerente de Projetos. » Projetos e/ou Empresas Grandes: o 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ê). o 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: o Utilizar número ímpar de membros e ferramenta de votação e controle de mudanças.

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

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

Questões importantes sobre as mudanças Os 7 Rs das Mudanças Requisitante • Quem requisitou?

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

Dicas sobre bugs Relatando bugs Requisitos de ferramentas » » » » » »

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: o Informar a situação da configuração do software

Atividade: Contabilizar a Configuração » Tarefas: o Informar a situação da configuração do software § § Capturar e reportar informações Normalmente, requer softwares para isto o 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: o Auditar a configuração funcional do software: §

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

Atividade: Gerir Versões e Distribuição » Tarefas: o Construir o software: § Combinar as

Atividade: Gerir Versões e Distribuição » Tarefas: o Construir o software: § Combinar as versões dos diversos CIs (componentes, hardware, ferramentas, dados, etc. ) para entregar uma versão do software o 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: o

Ferramentas de GCM Controle de Versões Gestão de Mudanças » » Open Source: o SVN (Sub. Version) o CVS (Concurrent Versions System) o GIT » Comerciais: o Clear. Case (IBM) o Source. Safe/Team Foundation System (Microsoft) o Star. Team (Borland) Fonte: Wiki - Comparison of Revision Control Software Open Source: o JIRA o Trac e j. Trac o Bugzzila » Comerciais: o o Clear. Quest (IBM) Star. Team (IBM) Team Foundation System (Microsoft) Code. Beamer (Intland) Fonte: Jiří Janák - Issue Tracking Systems

Referências Sigla Referência CAT 11 Cataldo Basile. Policy chains: the Po. Sec. Co approach

Referências Sigla Referência CAT 11 Cataldo Basile. Policy chains: the Po. Sec. Co approach to policy management in Future Internet. Politecnico di Torino. 2011. JGT 04 Jean-Pierre Garbani, Galen Schreck & Thomas Powell. Case Study: Autonomic Software. Policy Based, Cross-Platform System Management. Forrester. 2004. JIR 09 Jiří Janák. Issue Tracking Systems. Masaryk University. Faculty Of Informatics. 2009. JRS 12 Jon Dowell & Roland Sabourin. Change Management Practitioners Forum. it. SMF. 2012. MBA 05 Markus Bäker, Bernd Zakel & Achim Grindler. IWR-3 D Management Portal, a WIKI based Change- and Configuration Management Tool. HEPi. X. 2005. PAW 12 Paul Wasilewski. Learning from Failure: Managing Changing Requirements on the Apollo 13 Mission. UT Dallas. 2012. PTC 06 Parametric Technology Corporation. Change and Configuration Management. PTC. 2006. PRO 11 Process. Dox. Configuration, Change and Release Management Policies and Procedures Guide. Process. Dox. 2011. PDT 11 Prodater. Política Gestão de Configuração e Mudança. Prodater. 2011. RAM 03 Rama Versani (CA). An Enterprise Approach to Change & Configuration Management. BCS CMSG Conference, 2003. SOU 04 Reginaldo Pereira de Souza. Práticas de Gerência de Configuração. Universidade São Francisco. 2004. SHE 10 Sheheryar Muftee. Change and Configuration Management at AITS. IT Professionals Forum. 2010. WIK 13 Wikepedia. Comparison of revision control software. Wiki. 2013.

Referências 2 EMEA Equity Research. Basic valuation and accounting guide. HSBC. July 2012. J.

Referências 2 EMEA Equity Research. Basic valuation and accounting guide. HSBC. July 2012. J. C. Henderson & N. Venkatraman. Strategic Alignment: Leveraging Information Technology for transforming organizations. MIT (Original). IBM (Reprint) Systems Journal, vol 32, NO 1. 1993. Jonathan Berk, Peter De. Marzo, Jarrad Harford. Fundamentals of Corporate Finance. 3 rd Edition. Perason. 2015. Márcio Moreira. GCM - Gestão de Configuração & Mudanças. Pitágoras. 2013. Márcio Moreira. GETI - Gestão Estratégica da TI Aplicada aos Negócios. Pitágoras. 2016. Márcio Moreira. GPTI - Gerência de Projetos de TI. Pitágoras. 2016. Márcio Moreira. PGP - Planejamento Estratégico & Gestão de Performance. Pitágoras. 2011. Márcio Moreira. RUP - Processo de Desenvolvimento de Software. Pitágoras. 2010. PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. Quinta Edição. Guia PMBOK®. USA. 2013. PMI. Ian Sommerville. Engenharia de software. 9ª Ed. Brasil. Pearson. 2011.

Obrigado! Siga-nos nas redes sociais Tera & Márcio Moreira

Obrigado! Siga-nos nas redes sociais Tera & Márcio Moreira