Introdução à Gerência de Configuraçãoleomurta/courses/2010.1/es2/aula5.pdf · 1. Apresentar,...

Introdução àGerência de Configuração

Leonardo Gresta Paulino Murta

leomurta@ic.uff.br

Introdução

• A Engenharia de Software...

– Abordagem disciplinada para o desenvolvimento de software

– Grande diversidade de metodologias

Leonardo Murta Introdução à Gerência de Configuração 2

Introdução

• Ponto em comum nas metodologias:

– refinamentos sucessivos de artefatos

http://www.colegiosaofrancisco.com.br

Mas aonde ficam esses artefatos?

Tarefas de Engenharia de

Software

Artefato novo

Repositório

Artefato modificado

Artefato

O que são repositórios?

• Repositórios– Lugar seguro onde artefatos

são depositados

– Permitem armazenamento, busca e recuperação de artefatos

– Servem como um ponto de referência

– Apóiam no aumento da memória organizacional

Gerência de Configuração

Desenvolvimento Liberação Implantação Produção

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)

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 (MIL EIA, IEEE, ISO, etc.)

– Surgimento das primeiras normas internacionais

– Assimilação por organizações não militares

Sistema de Gerência de Configuração

Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

Artefatos

Controle de Versões

Construção e Release

Controle de Modificações

Solicitações

Sistema x Funções de GC

Ambiente de Desenvolvimento de Software

Identificação Controle Contabilização Avaliação Liberação

Gerenciamento de Construção

Sistemas:

Processos:

Espaço de

trabalho:

Perspectiva de

integração

Perspectiva

gerencial

Perspectiva de

desenvolvimento

Este curso será guiado pelos sistemas de controle de

modificações e versões!

Exercício

1. Apresentar, na próxima aula, as 5 funções de gerência de configuração, citando exemplos

2. Apresentar, na próxima aula, o sistema de gerenciamento de construção e release, dando algum exemplo usando uma ferramenta (make, ant, maven, etc.)

3. Apresentar, na próxima aula, o que é integração contínua, dando algum exemplo usando uma ferramenta (Cruise Control, Apache Continuum, Hudson, etc.)

Artefatos

Solicitações

Controle de versões

Armazenamento?

Colaboração?

Consulta?

Topologia?

Topologia

Repositório

Espaço deTrabalho

Centralizado Distribuído

ate Repositório

Espaço deTrabalhoc

Repositório

Espaço deTrabalho

Armazenamento

Completo

delta 12

Forward

delta 23

delta 32

Reverse

delta 21

In-line

v.1 v.2/3

v.1/2 v.3

Colaboração

Pessimista

junção

Otimista Misto

m.2 m.3

junção

m.1 m.2 m.3

Consulta

Repositório (versão 1)

Artefato1 (versão 1)Artefato2 (versão 1)Artefato3 (versão 1)

Artefato1 (versão 2)Artefato2 (versão 3)Artefato3 (versão 1)Artefato4 (versão 3)

Artefato1Versão 1Versão 2Versão 4

Artefato2Versão 1Versão 3

Artefato3Versão 1Versão 4

Artefato4Versão 3

Consulta por artefato

1ª modificação

2ª modificação

4ª modificação3ª modificação

Consulta

1ª modificação

2ª modificação

4ª modificação3ª modificação

1ª modificaçãoArtefato1 adicionadoArtefato2 adicionadoArtefato3 adicionado

2ª modificaçãoArtefato1 modificado

3ª modificaçãoArtefato2 modificadoArtefato4 adicionado

Consulta por modificação

4ª modificaçãoArtefato1 modificadoArtefato3 modificado

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 à 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)– permanentes (espaços de trabalho temporários)

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

Rel. 1

1.0 1.1 1.2

Rel. 2

2.0 2.1

Verif. Verif.

RC1 RC2Evolução EvoluçãoDesenv.

Correção Correção Correção

Junção

• Processo de migração de

– Espaços de trabalho

– Ramos

Linha 1Linha 2Linha 3

Linha 1’Linha 2

<Linha 1> ou <Linha 1’>?Linha 2<Linha 3> ou nada?

Linha 1Linha 2Linha 3

Linha 1’Linha 2

Linha 1’Linha 2Linha 3

Linha 1Linha 2

2-way merge 3-way merge

Introdução à Gerência de Configuração 24

Exemplo(junção no Eclipse)

Leonardo Murta

Exemplo de ferramentas de controle de versões

• Livre– Bazaar– Git– Mercurial– Subversion

• Comercial– BitKeeper (BitMover)– ClearCase (IBM Rational)– Perforce– PVCS (Serena)– StarTeam (Borland)– Synergy/CM (Telelogic)– Team Foundation Server (Microsoft)

Artefatos

Solicitações

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

Baseline (níveis de controle)

Coordenação c/ auditoria

Controle

Informal:•Pré baseline•Sem requisição•Sem aprovação•Sem verificação•Ágil•Ad-hoc

Formal:•Pós baseline•Com requisição•Com aprovação•Com verificação•Burocrático•Planejado

Nível de controle

Baseline (níveis de controle)

Req. Análise Projeto Análise Projeto Análise Projeto

1 Inform. - Formal Inform. Formal Formal

2 - - Inform. - Formal Inform.

Requisito 1 Análise ProjetoBaseline 1:

•An. Req. 1

Requisito 2 Análise Projeto

Baseline 2:•An. Req. 1•Pr. Req. 1•An. Req. 2

Controle de modificações

• 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

[Leon, 2000] Requisição de modificação

[White, 2000] Janela de criação de formulários do ClearQuest

• 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

[Leon, 2000] Análise de modificação

• 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

• 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!

• 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)

Contabilização da situação

• Tarefas

– Armazenamento das informações geradas

– Propagação dessas informações aos interessados através de relatórios

• Metáfora de conta bancária para item de configuração

• Permite que métricas sejam utilizadas com o intuito de melhoria

do processo e estimativa de custos futuros

• Fornece relatórios gerenciais ad-hoc

Resultado do relatório no modo tabular no Bugzilla

Resultado do relatório no modo de gráfico de pizza no Bugzilla

Resultado da consulta sobre séries no Bugzilla

Exemplo de ferramentas de controle de modificações

• Livre– Bugzilla– Mantis– Redmine– Trac

• Comercial– ClearQuest (IBM Rational)– JIRA (Atlassian)– StarTeam (Borland)– Synergy/Change (Telelogic)– TeamTrack (Serena)– Team Foundation Server (Microsoft)

Artefatos

Solicitações

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

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

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írculo-vicioso de

defeitos...

Gerenciamento de releases

Releases Curtas

Testes manuais

Equipe pequenaBaixa cobertura

dos testes

Defeitos no

produto final

Necessidade de

novas releases

Solicitações de

correção dos defeitos

Exemplo de ferramentas de controle de construção e liberação

• Livre– Ant– NAnt– Make– Maven– Rake

• Comercial– ClearMake (IBM Rational)– MSBuild (Microsoft)– Synergy/CM Object Make (Telelogic)

Analisando mais a fundo uma ferramenta popular...

Histórico

• Projeto iniciado em 2000

– Iniciativa da CollabNet

– Open-Source

• Intuito de substituir o CVS

– Similar no uso

– Melhor na implementação

• Auto controlado desde agosto de 2001

Características

• Versionamento de diretórios

• Copia, renomeação e movimentação com histórico

• Check-ins atômicos

• Versionamento de meta-dados

• Acesso via http/https

• Uso extensivo de deltas– Delta de binários

– Delta bidirecional na comunicação cliente/servidor

Problema da concorrência

Política pessimista

• Problemas administrativos– Bloqueios esquecidos podem atrasar o andamento do projeto

• Problemas de serialização desnecessária– Em alguns casos, as modificações atuam sobre partes

independentes dos arquivos bloqueados

• Falsa sensação de segurança– Dependências semânticas podem cruzar a fronteira de arquivos

• Bloqueios são necessários– Quando se trata de arquivos que não podem ser combinados

Política otimista (1/2)

Política otimista (2/2)

Controle de concorrência no Subversion

• Política pessimista e otimista em conjunto– Qualquer artefato pode ser sujeito a bloqueio– Artefatos podem ser demarcados com “necessita de bloqueio”

• Artefatos bloqueados por um desenvolvedor podem ser editados por outros– O commit dos outros somente ocorrerá depois do término do

bloqueio– Os outros deverão fazer merge

• Artefatos bloqueados podem ser “roubados”– Bloqueio apoia à comunicação– Bloqueio não engessa o processo

Repositório

• Sistema de arquivos versionado– Check-in equivale a uma foto do sistema de arquivos num dado

momento

• Versionamento global– Número de versão dado por commit

– Identificador implícito de conjunto de modificações

• Algoritmo “Bubble up”– Economia de espaço

– Velocidade na atualização

– Controle do histórico

Sistema de arquivos tradicional

Sistema de arquivos versionado

Dimensão TEMPO

Versionamento global

• O repositório é mais que um conjunto de arquivos independentes

– Mudança de versionamento de arquivos para versionamento do repositório

– Versão N é o estado do repositório depois do commit N

– “Versão 5 do arquivo X” passa a ser lido como “arquivo X na versão 5 do repositório”

Comando log

• Fornece um relatório sobre as versões do repositório– Por arquivo– Por commit

• Exibe, para cada versão– Identificação (número da modificação)– Quem (autor)– Quando (data)– Onde (caminhos)– Como (ação nos caminhos)– O que (mensagem)– Por que (número da solicitação de modificação)

Comando log

Exemplo

Sintaxe

svn log [-q] [-v] [-r VERSÃO] [URL]

svn log -q https://reuse.cos.ufrj.br/svn/brecho/trunk/build.xml

Comando log

Exemplo

Sintaxe

svn log [-q] [-v] [-r VERSÃO] [URL]

svn log -v -r 92 https://reuse.cos.ufrj.br/svn/brecho

r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007) | 1 lineCaminhos mudados:

M /trunk/build.xmlM /trunk/src/br/ufrj/cos/reuse/biblioteca/category/CategoryUtil.javaA /trunk/src/br/ufrj/cos/reuse/biblioteca/category/Suggestions.javaM /trunk/src/br/ufrj/cos/reuse/biblioteca/category/dao/HibernateCategoryDAO.java

Issue #234: Troca do algoritmo de sugestão de categorias

Algoritmo “Bubble up”

• Mecanismo interno do Subversion para controle do repositório– Entender esse mecanismo ajuda a entender o funcionamento

do Subversion

• Para um dado commit as ações são– Aplicadas nas folhas– Propagadas para os diretórios pais

• Arquivos e diretórios não afetados pelas modificações são preservados

• Algoritmo utilizado para armazenamento– Reverse delta

Repositório inicial

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Commit: modificação em um único arquivo

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3 Arquivo 3

Propagação para o diretório pai

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 2

Arquivo 3

Criação da nova versão

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 2

Arquivo 3

Commit: adição de um novo arquivo

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 2

Arquivo 3

Arquivo 4

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 2

Arquivo 3

Diretório 1

Arquivo 4

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 2

Arquivo 3

Diretório 1

Arquivo 4

Cópia “barata”

• O projeto interno do Subversion visa prover cópias “baratas” de diretório– Os dados não são duplicados

– Conceito semelhante a hard-link do unix

– Somente quando há mudanças, o link é quebrado

– Tempo constante gasto para cópias

• Mecanismo utilizado para– Etiquetas (tags)

– Ramos (branches)

Versão atual do repositório

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 3

Arquivo 4

Diretório 2 copiado para dentro do Diretório 1 com outro nome

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 3

Arquivo 4

Diretório 2’

Conteúdo idêntico ao original

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 3

Arquivo 4

Diretório 2’

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 1

Diretório 3

Arquivo 4

Diretório 2’

Repositório

Diretório 1

Arquivo 1

Diretório 2

Arquivo 2

Arquivo 3

Diretório 1

Diretório 3

Arquivo 4

Diretório 2’

Layout do repositório

• Layout é uma convenção– Permite mais de um projeto por repositório

– Ajuda a organizar cada projeto

• Layout sugerido– Um diretório por projeto na raiz do repositório

• Layout para cada projeto– Um diretório para o ramo principal: trunk

– Um diretório para os ramos: branches

– Um diretório para as etiquetas: tags

Layout do repositóriohttps://svn.ic.uff.br/

proj1/trunk/branches/tags/

dissertacoes/fulano/

trunk/branches/tags/

beltrano/trunk/branches/tags/

Etiquetas e Ramos

• Etiquetas (tags)– Cópias “baratas” do trunk para o diretório tags

– Troca de nome pelo nome da etiqueta

– Por convenção, nenhuma edição é feita sobre esse diretório copiado

• Ramos (branches)– Cópias “baratas” do trunk para o diretório branches

– Troca de nome pelo nome do ramo

– Edição no diretório copiado

Comando copy

• Copia um arquivo ou diretório com histórico entre caminhos no repositório ou espaço de trabalho

• Casos típicos– URL URL: cópia executada atomicamente no servidor,

utilizada usualmente para criar etiquetas e ramos– Diretório local diretório local: cópia feita no cliente e adição

(com histórico) agendada para o próximo commit

Comando copy

Exemplo

Sintaxe

svn copy ORIGEM DESTINO [-m MENSAGEM]

svn copy dir1 dir2/novo_dir_1

svn copy https://svn.ic.uff.br/proj1/trunkhttps://svn.ic.uff.br/proj1/branches/1.0.x-m “Criação do ramo 1.0.x”

svn copy https://svn.ic.uff.br/proj1/branches/1.0.xhttps://svn.ic.uff.br/proj1/tags/1.0.1-m “Criação da etiqueta 1.0.1”

Espaço de trabalho

• Diretório comum no sistema de arquivos local

• Guarda uma cópia limpa do checkout (.svn) – Permite algumas operações off-line

– Permite transmissão de diffs para o servidor

• Área isolada das modificações de outros desenvolvedores– Suas modificações podem ser publicadas com commit

– Modificações de outros podem ser incorporadas com update

• Um usuário pode ter vários espaços de trabalho para um mesmo projeto

Comando check-out

• Constrói um espaço de trabalho a partir de uma versão do repositório (ou parte dela)

Comando check-out

Exemplo

Sintaxe

svn checkout [-r VERSÃO] URL [CAMINHO]

svn checkout https://svn.ic.uff.br/proj1/trunk

svn checkout -r 15 https://svn.ic.uff.br/proj1/trunk

svn checkout https://svn.ic.uff.br/proj1/tags/1.0.3 rel1.0.3

Comando commit

• Envia modificações do espaço de trabalho para o repositório– Detecta automaticamente o que mudou

– Libera todos os bloqueios

– Aplica a modificação de forma atômica no repositório

• Pode não conseguir enviar caso algum outro usuário tenha dado commit– Necessário um update

Comando commit

Exemplo

Sintaxe

svn commit [-m MENSAGEM] [CAMINHO]

svn commit -m “Adição da versão 1.4.5 do modelo”

svn commit -m “Issue #34: Correção de erro de digitação” src

Comando update

• Atualiza o espaço de trabalho com as últimas modificações existentes no repositório

• Pode encontrar conflitos durante a atualização– É importante verificar cada um dos arquivos atualizados

• Ações sobre o espaço de trabalho– Adição de arquivos (A)– Remoção de arquivos (D)– Atualização de arquivos (U)– Arquivos com conflito (C)– Arquivos combinados (G)

Comando update

Exemplo

Sintaxe

svn update [-r VERSÃO] [CAMINHO]

svn update

svn update -r 12

svn update dir1

Comportamento dos comandos

Arquivo

modificado

localmente

Arquivo

modificado no

repositório

Comando

commit

Commando update

Não Não Nenhuma

ação

Nenhuma ação

Não Sim Nenhuma

ação

Versão local substituída

pela versão do repositório

Sim Não Publica a

versão local

no repositório

Nenhuma ação

Sim Sim Falha,

avisando que

o arquivo está

desatualizado

Versão local combinada

com a versão do repositório

Introdução à Gerência de Configuração 91Leonardo Murta

Ciclo básico de trabalho

Construção do

espaço de trabalho

svn checkout

svn update

svn switch

Implementação

svn add

svn delete

svn copy

svn move

svn lock

svn blame

svn log

Verificação

svn status

svn diff

svn revert

Integração

svn update

svn resolved

svn commit

Junção de ramos

• Deve ser feita em um espaço de trabalho limpo

– Check-out do destino da junção

• Deve ser entendida como diff & apply

• Diff é dependente de ordem

– Diff(A, B): ações necessárias para transformar o caminho A no caminho B

• O diff pode atuar tanto no espaço quanto no tempo

– Espaço: diff entre dois diretórios (copiados de um lugar comum)

– Tempo: diff entre duas versões de um mesmo diretório

Merge no tempo

• Normalmente usado para ramos

Espaço de trabalho

apply: ∆1

∆1 = diff(v4, v10)

6 8 11

124 5 7 109

13 14 15

branches/1.0.x

Merge no espaço

• Normalmente usado para etiquetas

1.0.0 1.0.1

Espaço de trabalho

apply: ∆1

∆1 = diff(1.0.0, 1.0.1)

branches/1.0.x

6 8 11

125 7 109

13 14 15

Comando merge

• Aplica a diferença entre dois caminhos no espaço de trabalho

• svn merge A B– Calcula as ações que precisam ser feitas para transformar o

caminho A no B– Aplica essas ações no espaço de trabalho

Comando merge

Exemplo

Sintaxesvn merge [-c VERSÃO | -r VERSÃO1:VERSÃO2] CAMINHOsvn merge CAMINHO1 CAMINHO2

svn merge -c 23 https://svn.ic.uff.br/proj1/branches/1.0.x

svn merge -c -23 https://svn.ic.uff.br/proj1/branches/1.0.x

svn merge -r 23:29 https://svn.ic.uff.br/proj1/branches/1.0.x

svn merge https://svn.ic.uff.br/proj1/tags/1.0.1https://svn.ic.uff.br/proj1/tags/1.0.2

Ciclo básico de junção

Construção do

espaço de trabalho

svn checkout

svn update

svn switch

Junção

svn merge

svn blame

svn log

Verificação

svn status

svn diff

svn revert

Integração

svn update

svn resolved

svn commit

Propriedades

• Cada diretório ou arquivo pode ter metadados anexados a ele

– Tuplas <nome, valor>

– Versionados

• Algumas propriedades built-in

– svn:mime-type: tipo do arquivo

– svn:ignore: elementos que não devem ser versionados em um diretório

– svn:needs-lock: indica que o arquivo precisa de política de controle de concorrência pessimista

Principais Referências Bibliográficas

• Alexis Leon, “A Guide to Software ConfigurationManagement”, Artech House Publishers, 2000.

• Anne Hass, “Configuration Management Principles andPractices”, Boston, MA, Pearson Education, Inc.

• Dart, S., 1991, “Concepts in Configuration Management Systems”, International Workshop on Software Configuration Management (SCM), Trondheim, Norway(June), pp. 1-18.

• Pressman, R. S. (1997). “Software Engineering: A Practitioner's Approach”, McGraw-Hill.

• http://svnbook.red-bean.com/en/1.4• http://subversion.tigris.org/design.html

Introdução àGerência de Configuração

Leonardo Gresta Paulino Murta

leomurta@ic.uff.br

Introdução à Gerência de Configuraçãoleomurta/courses/2010.1/es2/aula5.pdf · 1. Apresentar,...

Documents

Transcript of Introdução à Gerência de Configuraçãoleomurta/courses/2010.1/es2/aula5.pdf · 1. Apresentar,...

Gerência de Conﬁguraçãoleomurta/courses/es2/aula5.pdf · 2020-02-03 · – Redmine – Trac • Comercial – ClearQuest (IBM Raonal ) – JIRA (Atlassian) – StarTeam (Borland)

Apresentação do Curso de Engenharia de Software 2 › ~leomurta › courses › 2012.2 › es2 › aula1.pdfLeonardo Murta Apresentação do Curso de ES2 20 . Trabalho •Objetivo:

Apostila de Gerência de Investimentos - UFRRJ - 2010.1

Prova vestibular CEDERJ 2010.1

Ed Exame de Ordem 2010.1 Res Obj

CUSTOS INDUSTRIAIS UERJ 2010.1

2010.1 – Noturno

Introdução à Gerência de Configuração - ic.uff.brleomurta/courses/2009.2/es2/aula6.pdf · •A Engenharia de Software... –Abordagem disciplinada para o desenvolvimento de

GRUPO ESCOLA I, 2010.1

Convite Virtual Ecologia 2010.1 UFRN

Apostila Brandao ADM 1387 2010.1

Apresentacao PSC 2010.1

Auto-avaliação institucional 2010.1 RESULTADOS

2613_Revisao 2010.1

Apresentação do Curso de Engenharia de Software 2leomurta/courses/2011.2/es2/aula1.pdfLeonardo Murta Apresentação do Curso de ES2 20 Trabalho •Objetivo: Fazer um jogo de xadrez

Resultado Final - Lista dos Aprovados 2010.1 Técnico ......Resultado Final - Lista dos Aprovados 2010.1 Técnico Subsequente - Apodi Biocombustíveis - Matutino # Inscrição Candidato

Prova UEFS 2010.1

I-SONIC ES2 SOM QUE PREENCHE O AMBIENTE ASSIM, SÓ …

Novidades da Versão 2010.1

Gerência de Conﬁguração - ic.uff.brleomurta/courses/2015.2/es2/aula5.pdf · Sistema x Funções de GC Ambiente de Desenvolvimento de Software Identificação Controle Contabilização