Gerência de Projetos e Manutenção de Software Aula 9 Gerência de Configuração e Mudanças Andréa Magalhães Magdaleno andrea@ic.uff.

Transcrição

1 Gerência de Projetos e Manutenção de Software Aula 9 Gerência de Configuração e Mudanças Andréa Magalhães Magdaleno andrea@ic.uff.br

2 Agenda Rebobinando... Análise de Valor Agregado Gerência de Configuração Controle de Versões Gestão de Mudanças Construção e Release 2

3 ANÁLISE DE VALOR AGREGADO

4 Análise de valor agregado Medidas Custo orçado do trabalho programado (BCWS - Budgeted Cost of Work Scheduled): Custo do trabalho previsto no cronograma para ser realizado em um determinado período Quanto de trabalho deveria ter sido feito até agora Custo real do trabalho realizado (ACWP - Actual Cost of Work Performed): Custo efetivamente incorrido ao executar o trabalho dentro do intervalo de tempo sendo analisado Custo orçado do trabalho realizado (BCWP - Budgeted Cost of Work Performed): Valor monetário do trabalho realizado no intervalo de tempo (valor agregado) 4

5 Análise de valor agregado Medidas Custo Orçado (BC Budget Cost) Trabalho Programado (WS Work Scheduled) BCWS Trabalho Realizado (WP Work Performed) BCWP Custo Incorrido (AC Actual Cost) ACWS ACWP 5

6 Análise de valor agregado Imagine o cenário do projeto abaixo Valor-Hora de R$ 100,00 dos recursos = custo diário de R$ 800,00 Data: Day0 (início do projeto) = 15/02/2016 6

7 Análise de valor agregado Imagine o cenário do projeto abaixo Valor-Hora de R$ 100,00 dos recursos = custo diário de R$ 800,00 Data: Day0 (início do projeto) = 15/02/ OBS: Para trabalhar com EVM no Microsoft Project precisamos salvar uma baseline antes de realizar os cálculos.

8 Análise de valor agregado Considere que 2 dias se passaram Nenhum trabalho foi realizado (%Concluído = 0%) BCWS indica o custo do trabalho que havia sido agendado. ACWP indica o custo do trabalho efetivamente realizado. 8 Comparação antiga: Se ACWP < BCWS, o projeto está custando menos do que o planejado, mas isto pode significar atraso.

9 Análise de valor agregado Considere que 2 dias se passaram Algum trabalho foi realizado (ainda que não exatamente como o previsto) Subtarefa 1.1 atrasada (BCWS = custo e BCWP < BCWS) 9 Subtarefa 1.2 em dia e em andamento (ACWP = BCWS = BCWP)

10 Análise de valor agregado Mais um dia se passa (já são 3 dias) A tarefa 1.1. não evolui e o gerente aumenta a duração para 3 dias 10 BCWS continua igual ao anterior, pois se baseia na baseline (2 dias) ACWP aumenta (3 dias de trabalho) BCWP se mantém (80% do trabalho, considerando o tempo original) ACWP > BCWP, então temos aumento de custo no projeto BCWP < BCWS, então temos um projeto atrasado

11 Análise de valor agregado BCWP > BCWS Projeto Adiantado BCWP < BCWS Projeto Atrasado BCWP > ACWP Projeto custando menos BCWP < ACWP Projeto custando mais 11

12 Análise de valor agregado Day 0 Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP A 4 = 0,5 dia R$ 80,00 R$ 320,00 0% R$ 0,0 R$ 0,0 R$ 0,0 B 4 = 0,5 dia R$ 150,00 R$ 600,00 0% R$ 0,0 R$ 0,0 R$ 0,0 C 12 = 1,5 dia R$ 100,00 R$ 1.200,00 0% R$ 0,0 R$ 0,0 R$ 0,0 Day 2 (sem replanejamento) Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP A 4 = 0,5 dia R$ 80,00 R$ 320,00 100% R$ 320 R$ 320 R$ 320 B 4 = 0,5 dia R$ 150,00 R$ 600,00 0% R$ 600 R$ 0,0 R$ 0,0 C 12 = 1,5 dia R$ 100,00 R$ 1.200,00 50% R$ 1200 R$ 600 R$

13 Análise de valor agregado Day 2 (com replanejamento da tarefa C) Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP A 4 = 0,5 dia R$ 80,00 R$ 320,00 100% R$ 320 R$ 320 R$ 320 B 4 = 0,5 dia R$ 150,00 R$ 600,00 0% R$ 600 R$ 0,0 R$ 0,0 C 12 = 1,5 dia 24= 3 dias R$ 100,00 R$ 1.200,00 50% R$ 1200 R$ 600 R$ 1200 ACWP > BCWP, então temos aumento de custo no projeto BCWP < BCWS, então temos um projeto atrasado 13

14 Análise de valor agregado Day 0 Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP A 16 = 2 dias R$ 50,00 R$ 800,00 0% R$ 0,0 R$ 0,0 R$ 0,0 B 24 = 3 dias R$ 150,00 R$ 3.600,00 0% R$ 0,0 R$ 0,0 R$ 0,0 C 20 = 2,5 dias R$ 100,00 R$ 2.000,00 0% R$ 0,0 R$ 0,0 R$ 0,0 Day 1 Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP A 16 = 2 dias R$ 50,00 R$ 800,00 50% R$ 400 R$ 400 R$ 400 B 24 = 3 dias R$ 150,00 R$ 3.600,00 50% R$ R$ R$ C 20 = 2,5 dias R$ 100,00 R$ 2.000,00 40% R$ 800 R$ 800 R$ Tarefa B adiantada (BCWP > BCWS) Tarefas A e C em dia e em andamento (ACWP = BCWS = BCWP)

15 Análise de valor agregado Day 1 (com replanejamento) Tarefa HH Valor-Hora Baseline Custo %Realiz BCWS BCWP ACWP A 16 = 2 dias R$ 50,00 R$ 800,00 50% R$ 400 R$ 400 R$ 400 B 24 = 3 dias 16 = 2 dias R$ 150,00 R$ 3.600,00 50% R$ R$ R$ C 20 = 2,5 dias R$ 100,00 R$ 2.000,00 40% R$ 800 R$ 800 R$ Tarefa B adiantada (BCWP > BCWS) e custando menos (BCWP > ACWP) Tarefas A e C em dia e em andamento (ACWP = BCWS = BCWP)

16 Dever de Casa Faça a análise de valor agregado do momento atual do trabalho do curso 16

17 O PROBLEMA

18 Problema da Quebra de Comunicação Falhas de comunicação em equipes Ocorre pelas mais diversas razões: Vocabulários incompatíveis Culturas de desenvolvimento diferentes Distância geográfica Dificuldade de expressão Quando este problema acontece: Os sistemas produzidos não atendem aos requisitos Força de trabalho é desperdiçada Desenvolvedor A Desenvolvedor B Desenvolvedor C 18

19 Problema dos Dados Compartilhados Desenvolvedor A Desenvolvedor B Programa de A A1 A2 A3 Componente Compartilhado Programa de B B1 B2 B3

20 Problema dos Dados Compartilhados Cenário O desenvolvedor A modifica o componente compartilhado Mais tarde, o desenvolvedor B realiza algumas alterações no mesmo Ao tentar compilar o componente, erros são apontados pelo compilador, mas nenhum deles ocorre na parte que B alterou O desenvolvedor B não tem a menor ideia sobre a causa do problema 20

21 Problema dos Dados Compartilhados - Solução simplista Solução simplista: Cada desenvolvedor trabalha em uma cópia local do componente Resolve o Problema dos Dados Compartilhados, mas cria um novo problema 21

22 Problema da Manutenção Múltipla Desenvolvedor A Desenvolvedor B Programa de A Componente Componente Compartilhado Compartilhado Programa de B A1 A2 A3 B1 B2 B3 Versão de A do Componente Compartilhado Versão de B do Componente Compartilhado

23 Problema da Manutenção Múltipla (continuação) Ocorre quando cada desenvolvedor trabalha com uma cópia local do que seria o mesmo componente Dificuldade para saber: Que funcionalidades foram implementadas em quais versões do componente Que defeitos foram corrigidos Evitado através de uma biblioteca central de componentes compartilhados Nesse esquema, cada componente é copiado para a biblioteca sempre que alterado Resolve o Problema da Manutenção Múltipla, mas... 23

24 Problema da Atualização Simultânea Biblioteca Central de Recursos Compartilhados Desenvolvedor A Desenvolvedor B Componente Compartilhado Programa de A Versão de A do Componente A1 A2 A3 B1 B2 B3 Compartilhado Versão de B do Componente Compartilhado Programa de B

25 Problema da Atualização Simultânea Cenário 1 O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado Uma vez corrigido, o componente modificado é copiado para a biblioteca central O desenvolvedor B encontra e corrige o mesmo defeito em sua versão do componente por não saber que A já tinha feito isso O trabalho de A é desperdiçado 25

26 Problema da Atualização Simultânea Cenário 2 O desenvolvedor A encontra e corrige um defeito em sua versão do componente compartilhado Uma vez corrigido, o componente modificado é copiado para a biblioteca central O desenvolvedor B encontra e corrige um outro defeito em sua versão do componente, sem saber do defeito corrigido por A O desenvolvedor B copia sua versão do componente para a biblioteca central Além de o trabalho de A ser desperdiçado, a versão do componente que se encontra na biblioteca central continua apresentando um defeito O desenvolvedor A julga o problema como resolvido 26

27 Como Resolver? O problema da atualização simultânea não pode ser resolvido simplesmente copiando componentes compartilhados para uma biblioteca central Algum mecanismo de controle é necessário para gerenciar a entrada e saída dos componentes 27

28 GERÊNCIA DE CONFIGURAÇÃO

29 Introdução A Engenharia de Software... Abordagem disciplinada para o desenvolvimento de software Grande diversidade de metodologias Ponto em comum nas metodologias: refinamentos sucessivos de artefatos 29

30 Mas onde ficam esses artefatos? Tarefas de Engenharia de Software Artefato Artefato novo Artefato modificado Repositório 30

31 O que são repositórios? Repositórios Lugar seguro onde versões de artefatos são depositadas Permitem armazenamento, busca e recuperação Servem como um ponto de referência Apoiam no aumento da memória organizacional 31

32 Gerência de Configuração Gerência de configuração de software é uma disciplina para o controle da evolução de sistemas de software (Susan Dart, 1991) Desenvolvimento Liberação Implantação Produção Gerência de Configuração 32

33 Objetivos de GC Definir o ambiente de desenvolvimento Definir políticas para controle de versões, garantindo a consistência dos artefatos produzidos Definir procedimentos para solicitações de mudanças Administrar o ambiente e auditar mudanças Facilitar a integração das partes do sistema 33

34 Histórico Anos 50 GC para produção de aviões de guerra e naves espaciais Anos 60 e 70 Surgimento de GCS (S = Software) Foco ainda em aplicações militares e aeroespaciais Anos 80 e 90 Mudança de foco Surgimento das primeiras normas internacionais Assimilação por organizações não militares 34

35 Sistema de Gerência de Configuração Solicitações Controle de Modificações Artefatos 35 Controle de Versões Construção e Release

36 Problemas pela falta de GC Perda de código-fonte Impossibilidade de determinar o que aconteceu com um programa, ou parte dele Impossibilidade de determinar quem, porque e quando foram efetuadas modificações Requisitos já documentados desaparecem Requisitos implementados desaparecem do código O programa em execução e o seu código fonte estão em diferentes versões 36

37 CONTROLE DE VERSÃO

38 Tipos de Versão Versão Revisão Variante Cooperação (Rascunho) 38 (Conradi e Westfechtel 1998)

39 Revisões Gerações do imac ( ) 39

40 Variantes Honda Civic Hatchback Sedan Coupe 40

41 Cooperação (versões rascunho) Versão base Espaço de trabalho do Pedro Espaço de trabalho da Maria 41 Espaço de trabalho do João

42 Versões de rascunho podem ser combinadas (operação de merge) João Maria Pedro Revisões 42

43 Conflitos podem ocorrer durante o merge João Paulo Revisões 43

44 Outras duas operações importantes Diff = Patch = para guardar, transferir e compreender versões. 44

45 Mas afinal, para que servem versões? Sincronizar equipes Reproduzir configurações passadas Explorar possibilidades Segregar desenvolvedores Customizar produtos (LPS) Rastrear a introdução de bugs Entender a evolução de software Auditar mudanças 45

46 Tratamento de variantes em ramos (branches) Versões que não seguem a linha principal de desenvolvimento Fornecem isolamento para o processo de desenvolvimento Ramos usualmente são migrados para a linha principal de desenvolvimento A migração pode ser complicada no caso de isolamento longo Características dos ramos se comparados a espaços de trabalho compartilhados por outras pessoas (espaços de trabalho são isolados) residem no servidor (espaços de trabalho residem no cliente) históricos (espaços de trabalho são momentâneos) 46

47 Tratamento de variantes em ramos (branches) Recurso muito poderoso Devem existir regras bem definidas para criação de branches Por que e quando devem ser criados? Quais os passos? Quando retornar ao fluxo principal? Branches normalmente se originam de correções em versões anteriores 47

48 Estratégia básica de Ramificação Manutenção em série Ramo principal: evolução Ramos auxiliares: correções Foco Desenvolvimento in-house Cliente único (e.g.: aplicações Web) Dificuldade de manutenção de várias liberações em paralelo Sistema Desenv. 1.0 RC 2.0 RC Evolução Evolução Rel. 1 Verif. Correção Correção Rel. 2 Verif. Correção

49 Merge Unificação de diferentes versões de um mesmo item de configuração Integração dos itens de configuração de um branch com os itens de configuração do fluxo principal Checkout atualizando a área local Algumas ferramentas fornecem um mecanismo automático para realização de merges Mesmo com o uso de ferramentas, em vários casos há necessidade de intervenção humana 49

50 Exemplo (merge no Eclipse) 50

51 Terminologia Check-in: processo de revisão, aprovação e cópia de um item de configuração para o repositório Check-out: processo de requisição de modificações, aprovação e cópia de um item de configuração do repositório A atualização de uma baseline consiste em check-out seguido de modificações e check-in 51

52 Check-Out Check-out cliente Repositório

53 Check-Out Recupera a (última) versão de um item de configuração guardada no repositório Escrita Verifica que ninguém detém o lock do item de configuração Obtém o lock do item Cria uma cópia, para edição, no cliente Leitura Verifica que alguém já detém o lock Cria uma cópia, apenas para leitura, no cliente 53

54 Check-In Check-in cliente Repositório

55 Check-In Ação de inserir/atualizar um item de configuração no repositório Verifica o lock do item de configuração, caso o mesmo já exista Verifica e incrementa a versão do item Registra informações das mudanças (autor, data, hora, comentários) Inclui/atualiza o item 55

56 Baseline Configuração revisada e aprovada que serve como base para uma próxima etapa de desenvolvimento e que somente pode ser modificada via processo formal de GCS São estabelecidas ao final de cada fase de desenvolvimento Análise (functional) Projeto (allocated) Implementação (product) Momento de criar: Balanceamento entre controle e burocracia 56

57 Baseline (níveis de controle) Coordenação c/ auditoria Nível de controle Controle Pré baseline: Informal Sem requisição Sem aprovação Sem verificação Ágil Ad-hoc Pós baseline: Formal Com requisição Com aprovação Com verificação Burocrático Planejado e Controlado 57

58 Baseline (níveis de controle) Baseline 1: Requisito 1 Análise Projeto An. Req. 1 Baseline 2: An. Req. 1 Pr. Req. 1 An. Req. 2 Requisito 2 Análise Projeto Tempo Req. Análise Projeto Análise Projeto Análise Projeto 1 Inform. - Formal Inform. Formal Formal Inform. - Formal Inform. 58

59 Plano de GC O plano de gerência de configuração de software é o documento utilizado para descrever como será utilizada a disciplina de gerencia de configuração no projeto em questão Pode ser definido um plano padrão para a organização Esse plano padrão deverá ser adaptado para cada novo projeto, levando em consideração as suas peculiaridades 59

60 Plano de GC - Exemplo Sist. ID Item Ext. Título Resp. Resp. Implantação BASELINE: Dt PREVISTA: Dt REAL: BASELINE: Dt PREVISTA: Dt REAL: BASELINES BASELINE: Dt PREVISTA: Dt REAL: BASELINE: Dt PREVISTA: Dt REAL: Incluído Versão Incluído Versão Incluído Versão Incluído Versão 60

61 Principais sistemas de controle de versão open-source 61

62 GESTÃO DE MUDANÇAS

63 Motivação Mudança é inevitável Mudar é fácil controlar diversas mudanças simultâneas é difícil A gerência de mudanças introduz controle sobre as mudanças de maior relevância Todas as mudanças são analisadas Apenas as aprovadas são realizadas Sempre se sabe quem modificou o que, onde e quando 63

64 Problemas Controle do escopo do projeto Modificações podem ampliar o leque de funcionalidades e aumentar significativamente o custo do projeto Atrasos em entregas planejadas Controle de consistência dos artefatos Uma mudança aparentemente localizada pode causar muito mais impacto do que o previsto Degradação da qualidade do software (ex: abandono dos testes automatizados devido à inconsistência dos dados de teste) Retrabalho 64

65 O que é Gestão de Mudanças? Gestão de Mudanças é o processo de avaliar, coordenar e decidir sobre a realização de mudanças propostas a itens de configuração (ICs) Mudanças aprovadas são implementadas nos itens de configuração e nos dados e documentos relacionados 65

66 Objetivos da Gestão de Mudanças Garantir que os artefatos do sistema alcançam e mantêm uma estrutura definida através do seu ciclo de vida Definir procedimentos e documentação necessários para realizar modificações nos itens de configuração Prover os mecanismos necessários para conduzir mudanças de uma maneira controlada 66

67 Change Control Board (CCB) Analisar as solicitações de mudança Controlar o escopo do projeto Reuniões com frequência adequada ao ritmo das solicitações de mudança Envolver stakeholders no processo de priorização no processo de decisão Balanço entre o nível de controle desejado e overhead suportado Questões menores devem ser resolvidas pelo líder do projeto junto à equipe, reduzindo o overhead do CCB Composição multidisciplinar SQA, gerente, cliente, arquiteto Profissionais com grande capacidade de comunicação e negociação 67

68 Análise de impacto Mudanças de grande impacto devem ser comunicadas aos stakeholders envolvidos Análises de custo x benefício produzidas pelos stakeholders Priorização de mudanças Mudança pode ser rejeitada se o CCB perceber que o custo será mais caro que o benefício percebido Por questões de eficiência, algumas solicitações de mudança podem ser agrupadas por tema, subsistema ou área de negócio 68

69 Gestão de Mudanças Tarefas Solicitação de modificação Classificação da modificação Análise da modificação Avaliação da modificação Implementação da modificação Verificação da modificação Geração de baseline 69

70 Gestão de Mudanças Solicitação de Modificação Identificação única Solicitante Sistema/Projeto Item a ser modificado Classificação (melhoria, correção de defeito, outra) Prioridade Descrição Situação (nova, atribuída, finalizada, verificada, fechada) 70

71 Gestão de Mudanças O critério de classificação da modificação deve estar explicitado no plano de GC A classificação visa priorizar modificações mais importantes (críticas, fatais, não fatais, cosméticas) A análise visa relatar os impactos em custo, cronograma, funcionalidades, etc. da implementação da modificação Caso a análise conclua que não existe chance de aprovar a modificação (casos extremos), pode ocorrer rejeição antes da avaliação para poupar custos no processo 71

72 Gestão de Mudanças Análise de Modificação 72 (Leon, 2000)

73 Gestão de Mudanças A avaliação utilizará a requisição de modificação e o laudo da análise para tomar a decisão A requisição pode ser aceita, rejeitada ou adiada A implementação deve ser seguida por testes de unidade Durante a verificação, devem ser aplicados testes de sistema Após a geração da nova baseline, deve ser decidido se ela será considerada uma nova liberação 73

74 Gestão de Mudanças Caso especial: Correções emergenciais No caso de correções emergenciais, podem ser criados ramos sem a necessidade do processo formal Em algum momento esses ramos deverão sofrer junção para a linha principal de desenvolvimento Esse procedimento deve estar explicitado no processo! Defeitos não são normalmente processados pelo CCB Mesmo nessas situações, porém, é muito importante que seja criada uma solicitação de mudança 74

75 Gestão de Mudanças Caso especial: Defeitos Alguns sistemas tratam defeitos de forma diferente das demais requisições A correção de defeitos é um tratamento sintomático É importante descobrir o real motivo para o acontecimento do defeito para possibilitar a prevenção de defeitos futuros A análise de causa é útil para descobrir falhas no processo de desenvolvimento (e.g. falta de treinamento, padrões inadequados, ferramentas inadequadas) 75

76 Gestão de Mudanças Acompanhamento - Tarefas Armazenamento das informações geradas Propagação dessas informações aos interessados através de relatórios Permite que métricas sejam utilizadas com o intuito de melhoria do processo e estimativa de custos futuros Fornece relatórios gerenciais ad-hoc 76

77 Gestão de Mudanças 77 Resultado do relatório no modo tabular no Bugzilla

78 Auditoria da configuração Deve ocorrer ao menos antes de uma liberação (release) Tarefas Verificação funcional, assegurando que a baseline cumpre o que foi especificado Verificação física, assegurando que a baseline é completa (todos os itens de configuração especificados) Auditorias servem para garantir que os procedimentos e padrões foram aplicados 78

79 Auditoria da configuração A auditoria funcional ocorre através da revisão dos planos, dados, metodologia e resultado dos teste, para verificar se são satisfatórios A auditoria física examina a estrutura de todos os itens de configuração que compõem a baseline A auditoria física é efetuada após a auditoria funcional Podem ocorrer auditorias no próprio sistema de GC pelos mantenedores do plano de GC, para verificar se as políticas e procedimentos estão sendo cumpridos 79

80 Gestão de Mudanças Ferramentas Livre Bugzilla Mantis Redmine Trac Comercial ClearQuest (IBM Rational) JIRA (Atlassian) StarTeam (Borland) Synergy/Change (Telelogic) TeamTrack (Serena) Team Foundation Server (Microsoft) 80

81 CONSTRUÇÃO E RELEASE

82 Terminologia Construção (Building): processo de compilação do sistema a partir dos itens fonte para uma configuração alvo; Utiliza arquivo de comandos que descreve como deve ocorrer a construção Exemplo: makefile Os arquivos de comandos também devem ser considerados itens de configuração 82

83 Terminologia Release: Conjunto de produtos que deve ser entregue ao cliente Releases diferem de versões pois versões podem ser somente para uso interno ao projeto 83

84 Os Problemas na Geração de Builds Fazer os builds do sistema manualmente é muito demorado Pode ser difícil saber qual a versão correta de um arquivo Os pedaços do sistema podem estar em diversos locais diferentes Alguns arquivos podem ser esquecidos 84

85 Os Problemas na Geração de Builds A integração das partes de um sistema em desenvolvimento normalmente é: Realizada poucas vezes, apenas perto de sua implantação Feita em frequência inversamente proporcional à complexidade do sistema Integrar as partes de um sistema é uma tarefa trabalhosa e sujeita a erros Quanto maior o sistema, mais difícil 85

86 Os Problemas na Geração de Builds Consequência: problemas de integração tornam-se difíceis de detectar cedo no desenvolvimento Costumam ser encontrados muito depois de sua introdução É muito difícil rastrear suas causas 86

87 Geração de Builds através da Integração Contínua Geração frequente (pelo menos diária) de builds do sistema As partes do sistema são integradas constantemente Problemas de integração passam a ser encontrados logo que introduzidos, na maioria dos casos Considerada uma das melhores práticas no desenvolvimento de software A geração de builds deve ser automatizada e realizada com frequência adequada 87

88 Gerenciamento de releases Descrição de como construir, liberar e entregar o sistema Linguagem natural (conhecimento) Linguagem computacional (automação) Manter os descritores e documentos sob gerência de configuração! Definição das situações onde o processo pode ser temporariamente desviado Cuidado: Releases muito curtas podem levar a círculovicioso de defeitos... 88

89 Exemplo de ferramentas de construção e release Livre Ant NAnt Make Maven Rake Comercial ClearMake (IBM Rational) MSBuild (Microsoft) Synergy/CM Object Make (Telelogic) 89

90 Application Lifecycle Management (ALM) 90 Out 2013 COS Aula 6 90

91 Collaborative Lifecycle Management (CLM) 91 Out 2013 COS Aula 6 91

92 Collaborative Lifecycle Management (CLM) Requisitos Planejamento de Testes Gerenciamento de Defeitos Gerência de Configuração 92 Out 2013 COS Aula 6 92

93 Exercício Elaborar o plano de configuração do projeto informando no mínimo: Quais artefatos serão colocados sob gerência de configuração? Quais baselines serão estabelecidas e quais os itens de configuração de cada uma dela? Como deve funcionar o processo de gestão de mudanças? 93

94 94 Dúvidas?

95 Principais Referências Bibliográficas Alexis Leon, A Guide to Software Configuration Management, Artech House Publishers, Anne Hass, Configuration Management Principles and Practices, Boston, MA, Pearson Education, Inc. Conradi, R. and Westfechtel, B. Version Models for Software Configuration Management. ACM Computing Surveys, v.30, n.2, p , Dart, S., 1991, Concepts in Configuration Management Systems, International Workshop on Software Configuration Management (SCM), Trondheim, Norway (June), pp Pressman, R. S. (1997). Software Engineering: A Practitioner's Approach, McGraw-Hill. 95

96 Gerência de Projetos e Manutenção de Software Aula 9 Gerência de Configuração e Mudanças Andréa Magalhães Magdaleno andrea@ic.uff.br