Metodologia de Desenvolvimento de Software Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro de Informática Universidade.

Apresentação em tema: "Metodologia de Desenvolvimento de Software Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro de Informática Universidade."— Transcrição da apresentação:

1 Metodologia de Desenvolvimento de Software Alexandre Vasconcelos, André Santos, Augusto Sampaio, Hermano Moura, Paulo Borba © Centro de Informática Universidade Federal de Pernambuco

2 Gerência de Configuração e mudança André Santos Objetivo Compreender a importância do uso de mecanismos de gerência de configuração e gerência de mudança, seus métodos, processos e ferramentas.

3 Tópicos n Introdução n A necessidade de controle do código fonte n Controle do código fonte n Builds n Controle de defeitos n Gerência de mudança

4 Introdução n SEI CMM: u Gerência de Configuração (CM) e de Solicitações de Mudança (CRM) controlam as mudanças e mantém a integridade dos artefatos de um projeto. n CM e CRM envolvem: u identificar itens de configuração u restringir as modificações nesses itens u auditar modificações nesses itens u definir e administrar configurações desses itens, ao longo do processo de desenvolvimento.

5 Introdução n Parte essencial do processo de desenvolvimento. n Visa eliminar problemas de u atualizações simultâneas u limitação de notificação u existencia de múltiplas versões do sistema (produção, desenvolvimento, teste etc.)

6 Introdução n Benefícios: u suporte a metodologias de desenvolvimento u mantém integridade do sistema u garante completude e corretude do produto configurado u provê um ambiente estável para o desenvolvimento do produto u restringe mudanças nos artefatos, baseado em uma política u provê formas de auditar porque, quando e por quem um artefato foi modificado.

7 Introdução n Principais aspectos tratados em CM: u Change Request Management (CRM) u Configuration Status Accounting (Métricas) u Configuration Management (CM) u Change Tracking u Version Selection u Software Manufacture

8 Introdução n Ao longo do ciclo de vida de um software, seus artefatos sofrem diversas alterações, causadas por u correção de defeitos no produto u melhorias de funcionalidades do produto n Estas alterações afetam todos os tipos de artefatos: u documentos de requisistos u documentos de análise e projeto u código fonte u programas e scripts de tests

9 Introdução n Vamos nos referir no texto a código fonte, que é o artefato em que mais se usa essas técnicas. n Mas elas podem e devem ser usadas para todos os artefatos, dependendo do tamanho e complexidade do projeto.

10 Tópicos n Introdução è A necessidade de controle do código fonte n Controle do código fonte n Builds n Controle de defeitos n Gerência de mudança

11 A necessidade de controle do código fonte n Software desenvolvido por uma equipe u programas precisam ser acessados e alterados por várias pessoas da equipe. u modularização do projeto normalmente não é suficiente para resolver este problema. u como controlar o acesso aos programas? u Como saber qual a versão mais atualizada dos arquivos? u Como voltar para uma versão anterior do programa?

12 A necessidade de merging n Software desenvolvido por uma equipe u serializar o acesso aos programas pode ser improdutivo. F Pequenas alterações não precisam exigir acesso exclusivo aos programas F Alterações em métodos diferentes de uma mesma classe não precisam na maioria das vezes ser feitos seqüencialmente. u como fazer para que mais de uma pessoa possa estar trabalhando em um mesmo arquivo ao mesmo tempo? n Merging automático viabiliza o desenvolvimento paralelo

13 Tópicos n Introdução n A necessidade de controle do código fonte è Controle do código fonte n Builds n Controle de defeitos n Gerência de mudança

14 Controle do Código Fonte n semelhante ao controle de integridade em um Banco de Dados moderno n Exige a instalação, configuração e manutenção de um produto especificamente para controlar o código fonte. n Possui um conjunto básico de ações de controle de código fonte a serem realizadas pelo desenvolvedor. Desenvolvedor A Desenvolvedor B Repositório

15 Check-in n Ação de inserir/atualizar o conteúdo de um arquivo no sistema de controle de código fonte. u Verifica permissão de acesso ao arquivo u verifica e incrementa identificador de versão do arquivo u guarda data, hora e autor da alteração u informação de mudança (comentário) u commit do arquivo. n Informações são guardadas no próprio arquivo ou junto com ele. DesenvolvedorRepositório

16 Check-out n Ação de ler/copiar a (última) versão de um arquivo guardada no sistema n Tipos de checkout u somente para leitura (read-only) u para edição (read/write) DesenvolvedorRepositório

17 Locking n Sistemas de controle de código fonte usam um mecanismo de locking para evitar que mudanças acidentais ou intencionais ocorram em momentos inapropriados. n Evita alterações simultâneas u permite check-out, mas somente para leitura. Desenvolvedor prog1.c prog2.c prog3.c Repositório

18 Tagging n Permite “marcar” um conjunto de arquivos com um nome (tag). n Um tag representa um ou mais arquivos em um ou mais diretórios. u Tagging de versão de projeto: controla uma dada versão do projeto, em determinada data ou com determinada funcionalidade. u Tagging de arquivo de projeto: marca um conjunto de arquivos como pertencentes a um projeto, sem associação com a versão dos arquivos.

19 Tagging Arquivos marcados com tag A representam o projeto A: topdir/file1 topdir/file2 topdir/subdir1/file6 topdir/subdir2/file8 topdir/dubdir2/file9 file2 topdir subdir1 subdir2 file1 file3 file4 file5 file6 file7file8file9

20 Branching n Branching é a mais complicada das atividades básicas de controle de código fonte u é fundamental ter estratégias de branching bem definidas. n Estratégias de branching são regras que definem como ocorrerão atividades de mudança em paralelo no código fonte. u Sem uma estratégia bem definida, pode esperar pelo caos.

21 Branching n Em um sistema sem branches, um arquivo começa com sua versão 1, e a cada check-in sua versão é incrementada. u Se a versão mais recente é 5, você não pode fazer checkout para editar a versão 2, por exemplo. n Uso de locks limita o trabalho dos programadores.

22 Branching n Branching tenta reduzir estas limitações, permitindo a criação de caminhos separados (linhas) de desenvolvimento para um mesmo arquivo ou conjunto de arquivos. u cada branch tem o seu conjunto de alterações e versões. u Um branch guarda ligação com seu nó (versão do “ramo” principal) de origem. u Extremamente poderoso, e perigoso!

23 Branching 1423 file.c 2.2 2.1

24 Merging n Merging é o processo de combinar múltiplas versões de um arquivo para criar uma nova versão. u o desafio é garantir que a funcionalidade do código antes do merge seja preservada após o merge. n 2-way merges, até 32-way merges.

25 Merging n Situações a serem tratadas: u funcionalidades diferentes, sem conflito. u funcionalidades em conflito, que podem ser combinadas. Exemplo: tamanho de array. u funcionalidades em conflito, que não podem ser combinadas. F Neste caso, os desenvolvedores tem que entrar em acordo.

26 Merging n Merging é essencial se for permitida a criação de branches. u Normalmente, os vários branches do sistema retornarão ao branch principal de desenvolvimento. u Um dos critérios para criação de branches é o tempo necessário para realizar uma alteração.

27 Política de gerência de configuração n Deve haver uma política clara sobre: u convenção de formato de nomes, extensões. u responsabilidade de mudanças. u Documentação de mudanças (comentários) u criação e nomes de diretórios

28 Gerenciamento de Branching n Estratégias de Branching u define porque e quando branches são criados u quais atividades ocorrem nos branches u como os branches morrem ou migram para o branch principal.

29 Gerenciamento de Branching n Estratégias de Merging n Objetivos conflitantes: u maximizar produtividade individual do desenvolvedor u maximizar a habilidade de um desenvolvedor se beneficiar do trabalho dos outros

30 Gerenciamento de Branching n Tipos de merge u merge no tronco principal u merge (a partir) do tronco principal n branch de merge

31 Branching 1 hello.c 234 1 hello.h 23 56 4 Jan 5Jan 10Jan 20

32 Branching 1 hello.c 234 1 hello.h 23 56 4 3.j.1 hello.c 3.j.23.j.3 2.j.1 hello.h 2.j.2 José Maria 3.m.1 hello.c 3.m.2 3.m.3 2.m.1 hello.h 2.m.2

33 Merging 3 hello.c 4 2 hello.h 3 5 4 3.j.1 hello.c 3.j.23.j.3 2.j.1 hello.h 2.j.2 José Maria 3.m.1 hello.c 3.m.2 3.m.3 2.m.1 hello.h 2.m.2 3.j.4 2.j.3

34 Tópicos n Introdução n A necessidade de controle do código fonte n Controle do código fonte è Builds n Controle de defeitos n Gerência de mudança

35 Builds n “Build” é um termo usado para identificar as atividades associadas com o processamento dos fontes para gerar um executável. n Ações u verificar dependências u compilar u linkar u gerar outros arquivos (se necesário)

36 No Unix n Makefile comando make CC = gcc OPTS = -O hello: hello.o $(CC) $(OPTS) hello.o -o hello hello.o: hello.c $(CC) ($OPTS) -c hello.c

37 Ambiente de desenvolvimento n Objetivo: reproducibilidade n Especificar ambiente de build u hardware u software u procedimentos n Verificar reproducibilidade

38 Relatório de Build n Lista u ambiente u arquivos u localização n necessários para gerar o build de uma versão específica do software

39 Seleção de ferramentas n licenças n manutenção n expectativa de vida n features n desenvolver ferramentas internamente?

40 Referências n Descrição do workflow de gerência de configuração e mudanças - CD do RUP n Configuration Management Today - http://cmtoday.com n Software Release Methodology, M.E.Bays, Prentice Hall, 1999.