Desenvolvimento Global de Software

1
Desenvolvimento Global de Software

• Mestrado de Informática / UFPB
• Francilene Procópio Garcia, D.Sc.
• francilene_at_ieee.org

Gestão de Configuração Mudanças - Parte VI
2
Introdução

• A gestão de configuração e de mudanças tem como
  metas
• o controle de mudanças ao longo do ciclo de vida
  do produto
• a manutenção de integridade dos artefatos do
  projeto de software

Gestão da Solicitação de Mudanças (CRM)
Medições
Gestão de Configuração (CM)
3
Gestão de Configuração e Mudanças

• A gestão de configuração e de solicitação de
  mudanças envolvem
• a identificação de itens configuráveis
• a restrição de mudanças sobres esses itens
• a auditagem de mudanças sobre esses itens
• a definição e a gestão de configuração sobre
  esses itens
• As organizações virtuais devem definir quais
  métodos, processos e ferramentas serão usados
  para CM e CRM, incluindo
• informações chaves sobre o desenvolvimento do
  produto
• método de promoção (nível de qualidade e
  estabilidade do produto)
• processos de manutenção e disponibilização
• definição de um conjunto básico de artefatos
  potencialmente reutilizáveis resultantes do
  processo
• CM e CRM são partes essenciais e integradas ao
  processo de desenvolvimento em uso pelas
  organizações parceiras

4
Relevância

• A gestão de configuração e de solicitação de
  mudanças é essencial para controlar os inúmeros
  artefatos produzidos por diferentes pessoas (ou
  organizações) que atuam de forma cooperativa num
  mesmo projeto
• O fato de se controlar tais artefatos gerados
  evita a disseminação de conflitos, em geral,
  causados por
• updates simultâneos (dois ou mais membros do
  grupo trabalham num mesmo artefato, o último a
  faser mudanças destrói o trabalho dos demais. Por
  outro lado, o update serial pode retardar o
  desenvolvimento. O desafio é fazer o update
  simultâneo de forma integrada.)
• notificação limitada (ao se resolver algum
  problema num dado artefato compartilhado, a
  mudança deve ser notificada)
• múltiplas versões (a obtenção evolutiva de
  releases pode implicar na seguinte situação uma
  release no cliente outra release em teste ou
  ainda outra em desenvolvimento.
  Problemas/soluções em alguma das versões devem
  ser propagados entre elas de forma controlada)

5
Benefícios de Sistemas de Gestão de Configuração

• Sistemas de CM são indicados em todo processo de
  desenvolvimento, porém são críticos em projetos
  virtuais onde percebe-se o uso de políticas
  específicas de desenvolvimento em diferentes
  ambientes
• Alguns dos benefícios possíveis
• suporte aos métodos de desenvolvimento
• manutenção da integridade do produto
• garantia da correticidade e completude do produto
  configurado
• provimento de uma ambiente estável para
  desenvolvimento do produto
• definição de restrições acerca de mudanças
  possíveis sobre os artefatos
• provimento de formas de auditagem de mudanças
  efetivadas (quem, quando, onde)
• De forma única, o sistema de CM contabiliza as
  versões criadas, quem fez parte do processo,
  quais versões anteriores foram usadas, entre
  outras informações relevantes

6
Métodos de Promoção

• Na medida que um projeto avança, a qualidade e a
  estabilidade do produto tende a melhorar. O
  método de promoção tem como objetivo a indicação
  do nível de melhoria alcançado na forma de um
  atributo do processo
• Os níveis de promoção e seus atributos podem ser
  definidos para cada projeto, incluindo por
  exemplo
• Integração testada
• Sistema testado
• Aceitação testada
• Produção
• Os níveis de promoção devem ser ordenados de
  forma a refletir uma escala crescente de qualidade

7
Métodos de Promoção Um exemplo

• Suponha que o gerente de configuração necessite
  promover um certo produto para um nível abaixo do
  atual
• A razão poderia ser a descoberta de um bug
  crítico na versão recém obtida em comparação com
  as anteriores
• Neste caso, o nível de promoção do produto
  (versão) deve ser visivelmente menor ou até mesmo
  algo como rejeitada
• O método de promoção também pode definir um
  conjunto mínimo de critérios para promoção de
  nível de uma nova versão produzida - tais
  critérios poderão auxiliar a colocar um dado
  programa de testes em prática por todos os
  envolvidos no desenvolvimento

8
Estrutura de Diretório do Produto

• As organizações envolvidas no projeto vão
  demandar um local ou repositório para
  armazenamento dos códigos fontes, artefatos de
  projeto e implementação que definem cada versão
  obtida ou os componentes do sistema
• Uma estrutura de diretório de produto pode servir
  como uma forma de organizar logicamente todos os
  artefatos envolvidos com uma dada versão do
  produto

Os sub-sistemas e seus componentes podem estar
localizados em servidores remotos
9
Estrutura de Diretório do Produto Workspace

• Um conceito importante na gestão da estrutura do
  produto, em projetos virtuais, é a idéia do
  workspace
• Um workspace define um local privado, onde
  desenvolvedores podem criar e testar artefatos e
  código segundo um conjunto de padrões acordados
  entre os participantes
• Em cada organização virtual, o gerente de
  configurações deve criar o respectivo workspace

Integração de workspaces
Integração de workspaces
Workspaces privados
10
Visões do Workspace

• Existem dois tipos de visões em uso nos
  workspaces
• Snapshots apresenta ao desenvolvedor um ambiente
  de trabalho estável e isento de mudanças. Os
  snapshots são populados com visões de vários
  repositórios do projeto. Quando um desenvolvedor
  deseja enxergar mudanças realizadas por outros
  grupos, ele pode atualizar sua visão. Este
  formato de trabalho é conhecido por modelo
  pull, orientando sempre pela busca da informação
  desejada, ao invés de empurrar as mudanças
• Visões dinâmicas não armazenam nada localmente,
  dependem de atualizações imediatas realizadas
  através da rede. São recomendadas nas seguintes
  situações
• espaço restrito no ambiente do desenvolvedor
• necessidade de compartilhamento de certos objetos
  (componentes reutilizáveis, por exemplo)
• membros de grupos virtuais necessitam trabalhar
  com as últimas versões d eum código (ao
  realizarem testes de integração, por exemplo)

11
Gestão de Solicitação de Mudanças (CRM)

• Traz recomendações acerca da infraestrutura
  necessária na organização para avaliar o custo,
  cronograma e o impacto de mudanças solicitadas
  num dado produto
• Basicamente, a gestão de mudanças envolve o
  trabalho de dois grupos
• o grupo de revisão de mudanças - determinam se
  uma dada solicitação é válida. Em seguida,
  encaminham um conjunto de informações que envolve
  o escopo da mudança, nível de prioridade,
  cronograma, risco, recursos necessários, entre
  outras. Em geral, os membros são gerentes de
  testes, gerentes de desenvolvimento e membros do
  grupo de marketing
• o grupo de controle de mudanças (CCB) - funciona
  como um comitê, onde representantes de todos os
  parceiros têm assento (desenvolvedores, clientes
  e usuários)

12
Fluxo típico de atividades em CRM
13
Estágios e transições típicos em CRM
14
Estágios em CRM Estatísticas
Os atributos dos estágios auxiliam na geração de
estatísticas chaves (tempo, distribuição, riscos)
sobre as mudanças
15
Medição do Processo

• É muito importante em projetos virtuais para
  descrever o status do produto com base em algum
  formato como tipo, número, taxa e categorias de
  falhas encontradas e corrigidas no decorrer do
  desenvolvimento do produto
• Existem quatro tipos básicos de relatórios
  gerados
• Mudanças solicitadas
• Software gerado
• Descrição de versões e
• Auditagens realizadas

Relatórios baseados em tempo
Relatórios baseados em métricas
1. Quanto tempo leva para que uma solicitação de
mudanças seja aberta? 2. Quantas solicitações de
mudanças existem por categoria de prioridade? 3.
Qual é o número acumulado de falhas achadas e
corrigidas até o momento?
Relatórios baseados em tempo e métricas
16
Descrição de Versões

• Cada versão deve conter alguns detalhes sobre o
  software
• lista de itens entregues (mídia e documentos)
• lista do conteúdo do software (arquivos)
• instruções para instalação
• erros conhecidos prováveis
• dados únicos do desenvolvimento críticos para
  evolução do produto

17
Gestão Unificada de Mudanças

• No ambiente da Rational, usa-se um add-on do
  Clear Case - o ClearCase MultiSite para CM e CRM
  no desenvolvimento de produtos em múltiplos
  locais distribuídos geograficamente
• Busque na URL http//www.rational.com/products/cc_
  multisite/index.jtmpl as principais
  características do ClearCase MultiSite, indicando
  os mecanismos e facilidades de como se gerencia
  um processo de desenvolvimento distribuído
  geograficamente
• Em seguida responda, alguma funcionalidade
  crítica estaria faltando? Se sim, o que você
  sugere?