Apresentação do PowerPoint

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?
Introdução
Cenário 1
»
Mudança:
o
»
»
Topologia:
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 RAM03
Problema 1
»
Cada software tem no mínimo 3 projetos em andamento:
o
o
o
»
Além disto, cada um dos projetos tem pelo menos 5 estados:
o
o
o
o
o
»
Uma versão para correção de bugs
Uma versão para melhorias
Uma versão para adaptação a leis
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
»
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 um ERP rodando na empresa 6 anos, na implantação fizemos algumas customizações no
produto original
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
o
»
Suporte:
o
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
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
»
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
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
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
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
»
Projeto:
o
»
Precisamos ser capazes de simular o comportamento em produção
Distribuição:
o
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 colher, acordar e projetar a melhor solução
Desenvolvimento:
o
»
Precisamos ser capazes de prever o esforço, a duração, as dependências e a análise de impacto
do trabalho
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:
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
»
o
Estratégia
Melhoria
ou
Retirada
Operação
GCM da ESOF (RUP/SWEBOK):
»
Projeto
Transição
A Gestão de Configuração e Mudança da
Engenharia de Software está focada na
etapa de Projeto
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:
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
Cadeia de valor de GCM
»
As atividades dos processos de Gestão
de Configuração e Mudanças se integram
às demais disciplinas:
o
o
o
o
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
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:
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
conjunto de Produtos de Trabalho que
compõem o sistema de software
Problemas:
o
Quando 2 ou mais pessoas trabalham
concorrentemente
Notificação limitada:

o
Benefícios da GCM:
o
o
o
o
Atualização simultânea:

o
»
A correção feita por uma pessoa não chega
para outro
Múltiplas versões:

A maioria dos projetos tem “n” versões
o
o
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:
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
É 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
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:






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
Fonte: SWEBOK
o
Criar e manter biblioteca do software
(trabalho, principal, etc.)
Atividade: Controlar a Configuração
»
Tarefas (Gestão de Mudanças):
o
Requerer, avaliar e aprovar mudanças no
software:


o
o
»
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:
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
o
»
Melhoria (Improvement):
o
Comportamento inadequado do software.
É a classificação inicial de um bug ou
melhoria.
o
»
Requisito (Requirement):
o
»
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
»
Requisição de uma melhoria em uma
funcionalidade existente.
Requisição de uma nova funcionalidade do
software.
Novas funcionalidades ou novos recursos
do software
Tarefa (Task):
o
o
Solicitação de algo que deve ser feito
(funcional ou não).
Ex.: Upgrade de hardware, atualização do
Sistema Operacional.
Severidade e Benefícios das Mudanças
»
Bloqueadora (show stopper):
o
»
Crítica (critical):
o
»
o
o
o
Maior (major):
Impede o funcionamento de uma
funcionalidade
Menor (minor):
o
»
Impede o funcionamento de um
subsistema inteiro
Benefícios:
o
o
»
Bloqueia o desenvolvimento, os testes ou
a produção inteiros
»
Afeta uma funcionalidade, mas existe uma
solução de contorno
Trivial (cosmetic):
o
Um problema cosmético
o
o
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:
o
»
»
o
»
o
»
Avaliar os impactos da mudança no
projeto (escopo, prazo, custo e qualidade)
e no negócio
Modificar os planos e executar a mudança
no contexto do projeto
Revisar Mudança:
o
»
Decidir se a mudança vai ser feita
Executar a Mudança:
Decidir se a análise de impacto deve ser
feita ou não
Analisar Impactos da Mudança:
o
Revisar Impactos:
Verificar se a mudança está bem
formulada e entendida
Aprovar Análise de Impacto:
o
»
Determinar quais mudanças devem ser
solicitadas
Avaliar Mudança:
o
»
Verificar se a mudança foi corretamente
implementada e fechá-la
Notificar Solicitante:
o
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:
o
»
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
o
»
Esta responsabilidade pode ser atribuída ao Cliente ou ao Gerente de Projetos (dependendo da
forma do contrato).
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:
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
Questões importantes sobre as mudanças
Os 7 Rs das Mudanças
Requisitante
Razão
Retorno
Riscos
• Quem requisitou?
• Qual a razão?
• Qual o retorno esperado dela?
• Quais os riscos envolvidos?
Estados das Mudanças
»
»
»
»
»
Aberta
Duplicidade Verificada
Conselho (alocada para o Comitê)
Rejeitada (pelo Comitê ou GP)
Adiada:
o
»
»
»
Planejada (para execução)
Atribuída (em execução)
Erro Conhecido:
o
Recursos
Responsável
Relações
• Quais os recursos necessários?
• Quem a executará?
• Quais as RFCs relacionadas?
»
»
»
Não será avaliada agora
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:
o
Informar a situação da configuração do
software


o
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:
o
Auditar a configuração funcional do
software:

o
Auditar a configuração física do software:

o
As funcionalidades estão de acordo com os
requisitos de governança?
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:
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
o
o
»
o
o
o
o
o
o
SVN (SubVersion)
CVS (Concurrent Versions System)
GIT
Comerciais:
ClearCase (IBM)
SourceSafe/Team Foundation System
(Microsoft)
StarTeam (Borland)
Fonte: Wiki - Comparison of Revision Control Software
Open Source:
»
JIRA
Trac e jTrac
Bugzzila
Comerciais:
o
o
o
o
ClearQuest (IBM)
StarTeam (IBM)
Team Foundation System (Microsoft)
CodeBeamer (Intland)
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.
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, vol32, NO1. 1993.
Jonathan Berk, Peter DeMarzo, Jarrad Harford. Fundamentals of Corporate Finance. 3rd 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