Pós-Graduação Engenharia de Software

Transcrição

1 Pós-Graduação Engenharia de Software Gerenciamento de Mudanças, Configuração & Distribuição de Software Parte 01 Apresentação do Curso, Contextualização e Fundamentos Prof. Msc Rogério Augusto Rondini rarondini.paradygma@gmail.com 1

2 Apresentação Prof. MsC Rogério Augusto Rondini Doutorando em Engenharia Elétrica na Escola Politécnica da USP (área de Engenharia da Computação e Sistemas Digitais); Mestre em Ciência da Computação pela Universidade Católica de Santos (UNISANTOS); Especialização em Orientação a Objetos no Laboratório A-Hand e Instituto de Computação (UNICAMP). Professor junto à Faculdade de Tecnologia e Ciências Exatas da Universidade São Judas Tadeu. Atua profissionalmente na área de sistemas há mais de dez anos. Atualmente é consultor Arquiteto de Software Senior com experiência no desenvolvimento e implatanção de sistemas de missão críticas. Interesses incluem arquitetura de sistemas distribuídos, middleware e servidores de aplicação e métodos ágeis de desenvolvimento de software. Currículo Lattes: 2

3 Estrutura do Curso Gestão de Configuração Gestão de Mudança CMMi ITIL RUP Agile Distribuição de Software Dependências Releases Features Testes Integração Contínua 3

4 Conteúdo (1) Introdução e Visão Geral de SCM (2) Gestão de Configuração (3) Gestão de Mudança (4) Distribuição de Software (5) Padrões para SCM (6) SCM e RUP (7) SCM e Agile (8) SCM e CMMi (9) SCM e ITIL (10) Laboratório de Ferramentas 4

5 Referências MOLINARI, Eduardo; Gerência de Configuração: Técnicas e práticas no Desenvolvimento de Software FERNANDES, A. Aguinaldo; Gerência de Software Através de Métricas PRESSMAN, Roger; Engenharia de Software Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Steve Berczuk with Brad Appleton. COLLINS-SUSSMAN, Ben; et.el. Version Control with Subversion for SVN 1.6 (Compiled from r3781) doc-book Software Engineering Institute, CMMI for Development, Version 1.2 5

6 Links RUP - SCM for Agile Team Agile SCM: build management for an Agile Team Continuous Integration Introdução ao processo de gerência de configuração de software BROOKS, Fred; No Silver Bullet: Essence and Accidents of Software Engineering. 6

7 Metodologia Aulas expositivas Laboratório de ferramentas Ferramentas de GC Ambiente de Integração Contínua Ferramentas p/ distrib. de Software Resumo e discussão de Artigos 7

8 Avaliação (T) Trabalho final da disciplina composto de documento impresso e apresentação de 15 minutos (R) Resumo e discussão de artigos NF = (6 * T) + (4 * (média(r)) 10 8

9 Apresentação Quem é você? 9

10 10

11 Go Ahead # 01 Problemas com desenvolvimento de software Por que Gestão de Configuração? Conceitos de Qualidade de Software Conceitos Fundamentais de SCM 11

12 Brainstorm #01 Como é o desenvolvimento de software na sua empresa em relação a processos de desenvolvimento? Quais os problemas mais comuns no desenvolvimento de software? O que você entende por Gestão de Configuração de Software (SCM) e qual a finalidade de SCM? O que SCM tem a ver com Qualidade de Software (QoS)? 12

13 13

14 Desenv. Software Principais problemas (Yourdon ) Produtividade Confiabilidade Manutenibilidade 14

15 Desenv. Software Problemas Essenciais (Brooks,1987) Complexidade Dificuldade de compreender uma entidade abstrata Conformidade Mudanças Invisibilidade Atender necessidades do cliente Semelhante à constatação de Yourdon em relação à manutenção Software como entidade abstrata (não paupável) 15

16 Mudanças Nada é permanente, exceto a mudança (Heráclito, 500 a.c) Mudança é algo totalmente comum no desenvolvimento de software. Ao invés de combatê-la, é preciso ter mecanismos para gerenciá-las da melhor maneira possível. 16

17 Mudanças Origens das mudanças Requisitos não muito bem definidos Restrição de prazos de entrega, corte de escopo, mudança nas prioridades Correção de defeitos Novas necessidades do cliente Alguns processos de desenvolvimento são totalmente abertos às mudanças ao longo do ciclo de desenvolvimento 17

18 Mudanças Cenários de ambientes sem controle Imagine que após um dia inteiro de trabalho de manutenção de código, você descobre que alterou a versão errada. Imagine se você descobre que não tem guardado os fontes da versão anterior, ou que estavam no seu pen-drive, aquele mesmo que você usou no dia anterior p/ guardar as fotos do último churrasco!!! 18

19 Mudanças Cenários de ambientes sem controle Sim, fui eu que alterei o código, mas já faz tanto tempo que nem me lembro o motivo. Eu alterei este programa, mas esta já era a vigésima alteração no mesmo programa, e este erro que apareceu não é meu. Eu alterei ontem, mas não sabia que você também estava alterando. Qual a última versão? 19

20 Problemas Comuns Problemas com objetos compartilhados Desenvolvedor A Desenvolvedor B Prog. A Linha do tempo 20

21 Problemas Comuns Problemas com objetos compartilhados Desenvolvedor A modifica o Prog. A Mais tarde, desenvolvedor B também faz alterações no Prog. A, sem saber que o código já foi alterado Ao tentar compilar, o Prog.A apresenta erros, nenhum deles causado pela alteração feita pelo desenvolvedor B. 21

22 Problemas Comuns Problemas com objetos compartilhados Solução simplista Cada desenvolvedor trabalhar com uma cópia do objeto Resolve um problemas, mas cria outros... 22

23 Problemas Comuns Problema da manutenção múltipla Desenvolvedor A Desenvolvedor B Versão de A do Componente Compartilhado Versão de B do Componente Compartilhado 23

24 Problemas Comuns Problema da manutenção múltipla Ocorre quando cada desenvolvedor trabalha com uma cópia local do objeto Dificuldade para saber quais funcionalidades foram implementadas em quais versões Dificuldades para saber que defeitos foram corrigidos 24

25 Problemas Comuns Problema da atualização simultânea Desenvolvedor A Biblioteca Central de Recursos Compartilhados Desenvolvedor B Componente Compartilhado Versão de A do Componente Compartilhado Versão de B do Componente Compartilhado 25

26 Problemas Comuns Problema da atualização simultânea Desenv. A corrige um problema em sua versão de componente, e então promove o componente para uma biblioteca central Desenv. B corrige outro problema, e também promove para uma biblioteca cental, sem se importar se Desenv. A promoveu algum componente... 26

27 Efeitos da Mudança O aspecto fundamental da mudança é o efeito dominó Muido difícil uma mudança causar um impácto único. Na grande maioria das vezes, a mudança afeta vários objetos 27

28 Efeitos da Mudança Uma mudança simples Mudança Impácto Todos os campos Nome de Sistema cujo tamanho é de 20 caracteres, passaria a ser de 30 devido a constantes reclamações dos usuários. Colunas de tabelas, campos de diversas telas, interface com outros sistemas, manuais... 28

29 Efeitos da Mudança Uma mudança simples Afeta Equipe de banco de dados Usuários Equipe de testes Uma mudança simples pode levar a outras mudanças. 29

30 Efeitos da Mudança Uma mudança complexa Um fornecedor online tem recebido diversas reclamações dos consumidores e dos supervisores internos a respeito do site. Os executivos resolveram revisar seus processos internos para atender as reclamações. Foram detectadas algumas mudanças principais: 30

31 Efeitos da Mudança Uma mudança complexa Mudanças identificadas: Os códigos dos produtos devem coincidir com os códigos entregues Cadastro não pode mais ser cancelado após 30 dias O sistema permitirá alteração do tipo de produto Cada usuário interno deverá ser autenticado 31

32 Efeitos da Mudança Uma mudança complexa Alguns problemas Mudanças afetam código e processos internos Em geral, as regras de negócio estão espalhadas em várias aplicações, muitas delas sem documentação Identificação dos artefatos a serem alterados torna-se difícil 32

33 Dificuldades sem SCM Falta de gerenciamento nas alterações Qualquer um pode fazer alterações Dificuldade na rastreabilidade Muito tempo gasto com retrabalho Mudanças tendem a ser um problema, quando deveriam ser situação natural no des. de software. 33

34 Dificuldades sem SCM Os cenários apresentados anteriormente refletem a realidade de muitas empresas Mesmo com tantos avanços, muitos ainda ignoram processos e procedimentos de gestão Existem soluções complexas e simples, porém, não existe bala de prata É preciso entender o problema, conhecer as possíveis soluções e saber escolher a mais adequada para um determinado contexto... 34

35 35

36 SCM Processo para organizar e controlar (gerenciar) modificações ao software, bem como estabelecer e manter a integridade dos produtos do projeto de software ao longo do seu ciclo de vida com objetivo principal de maximizar produtividade e minimizar os enganos. 36

37 Por que SCM? Dinâmica dos negócios aumentou em função da demanda de TI A Internet forçou que TI acompanhasse os negócios Outros aspectos, tais como, globalização, avanço tecnológico, pressão competitiva, mostram que as empresas tem que operar de forma mais eficiente em todos os níveis. 37

38 Por que SCM? A área de TI e o desenvolvimento de software vêm criando novos processos, metodologias e ferramentas Mudanças na forma de trabalho Leis e normas de regulamentação Novos Processos de desenvolvimento Modelos de gestão e qualidade 38

39 Por que SCM? Desenvolvimento Iterativo e Incremental Avanço em relação aos modelos anteriores (ex. Cascata) Tolerância às mudanças de requisitos Elementos integrados progressivamente Riscos Identificados mais cedo 39

40 Por que SCM? Desenvolvimento Iterativo e Incremental 40

41 Por que SCM? Desenvolvimento Iterativo e Incremental Gerenciamento de risco 41

42 Por que SCM? Desenvolvimento Iterativo e Incremental As vantagens tem um preço... Equipes trabalhando no mesmo projeto em funcionalidades e/ou componentes distintos que compartilham objetos Muitas vezes, equipes distribuídas geograficamente Complexidade de organização e controle 42

43 Por que SCM? PCI-DSS desenvolvimento seguro O PCI-DSS (Payment Card Industry Data Security Standard) é um fórum para contínuo desenv. de padrões de segurança p/ proteção de dados de conta Desenvolver e manter aplicativos seguros é um dos itens definidos pelo PCI-DSS que trata do processo de desenvolvimento de software 43

44 Por que SCM? PCI-DSS desenvolvimento seguro Garantia de rastreabilidade das alterações e correções de código Análise de código deve ser executada, revisada e aprovada antes da liberação Documentação de impácto no cliente deve estar incluída na documentação de controle de alterações 44

45 Por que SCM? Lei Sarbanes-Oxley (SoX) Lei criada nos EUA em 2002 com objetivo de aperfeiçoar os controles financeiros das empresas e apresentar eficiência na governança corporativa. Visa garantir a transparência na gestão financeira das organizações Impácto total em TI 45

46 Por que SCM? Lei Sarbanes-Oxley (SoX) Alguns requisitos... Controlar a criação, edição e versionamento de documentos Cadastrar riscos associados a processos de negócio e armazenar o desenho dos processos Gerenciar todos os documentos, controlando período de retenção e distribuição... 46

47 Por que SCM? Lei Sarbanes-Oxley (SoX) A política de controle deve ser aplicada também durante o ciclo de desenvolvimento e liberação de software TI é a área responsável por esse controle, por tanto, deverá estar alinhada na adequação desta lei Uso de padrões (ex. ITIL e CMMi) são importantes nesse processo. 47

48 Por que SCM? Qualidade de Software Qualidade é a conformidade com os requisitos (Philip B. Crosby) Quem determina a qualidade é o cliente... mas... a que custo?! A satisfação do cliente é importante, mas não pode ser o único fator a ser considerado 48

49 Por que SCM? Qualidade de Software Para empresa que desenvolve, vários fatores podem afetar a qualidade Baixa produtividade Retrabalho Esforço além do estimado Custo além do previsto... 49

50 Por que SCM? Qualidade de Software Controle de Qualidade Atividades operacionais para monitoramento de processos e eliminação de desempenho insatisfatório No desenvolvimento de software, monitoramento dos processos de gestão, desenvolvimento e manutenção 50

51 Por que SCM? Qualidade de Software Pilares da qualidade de software 51

52 Por que SCM? Qualidade de Software Medições para processos de desenvolvimento Visa fundamentalmente a remoção de defeitos nos produtos gerados ao longo do processo Relatórios gerados por ferramentas de GCS servem de insumos para estas medições 52

53 Por que SCM? Qualidade de Software Medições importantes Progresso na remoção de defeitos No. cumulativo de defeitos identificados Defeitos restantes Pode ser um número púro, ou seja, quantidade de defeitos ainda abertos Pode ser um número estimado baseado em cálculos estatísticos 53

54 Por que SCM? Qualidade de Software Medições importantes Composição de tipos de defeitos Composição de defeitos por fase Distribuição por modulos Tempo médio para correção de defeitos... 54

55 Por que SCM? Motivos apresentados anteriormente impulsionaram a utilização de processos de SCM nos últimos anos Muitas ferramentas de apoio vem sendo desenvolvidas SCM não é a bala de prata, mas contribui muito para minimizar problemas no desenvolvimento de software. 55

56 56

57 Fundamentos SCM é uma área bastante abrangente. Iremos tratar neste curso como três macro-processos Gestão de Configuração Gestão de Mudança Gestão de Distribuição de Software 57

58 Gestão de Configuração Definições Processo para organizar e controlar modificações ao software Estabelecer e manter a integridade dos produtos do projeto de software ao longo do seu ciclo de vida Maximizar produtividade e minimizar os enganos 58

59 Gestão de Configuração Definições Jacobson, Booch e Rumbaugh Tarefa de definir e manter configurações e versões dos artefatos. Isto inclui linhas de base, versionamento, status e armazenamento de artefatos. 59

60 Gestão de Configuração Definições SEI (Software Engineering Institute) 'Envolve identificar a configuração de um software em certos pontos do tempo, controlando as mudanças e mantendo a integridade e rastreabilidade da configuração durante o ciclo de vida do software. Os produtos contralados incluem os entregue ao cliente e os necessários para a criação do software' 60

61 Gestão de Configuração Definições IEEE-Std 'Processo de identificar e definir os itens de um sistema, controlando as modificações durante o seu ciclo de vida, gravando e relatando o status dos itens e das solicitações de mudanças, verificando a completudo, corretudo e consistência nos mesmos. 61

62 Gestão de Configuração Definições Buckle (1982) Termo usado para designar um conjunto de técnicas que, quando aplicadas ao desenvolvimento e manutenção de software, melhorará a qualidade do produto de software, reduzirá os custos do ciclo de vida e melhorará a função gerencial no processo de desenvolvimento e produção. 62

63 Gestão de Configuração Atividades Definir ambiente de desenvolvimento Definir políticas de controle Definir procedimentos p/ mudanças Identificar e controlar mudanças Manter rastreabilidade Garantir a implementação da mudança Registrar e relatar mudanças 63

64 Gestão de Configuração GC e Qualidade de Software Qualidade de Software, pontos de vistas diferentes Para um diretor, se o software funciona, tem qualidade Para o desenvolvedor, código-fonte deve ser organizado e de fácil manutenção. Se este é assim, então o código tem qualidade 64

65 Gestão de Configuração GC e Qualidade de Software Técnicas ligadas à qualidade de Software Pressmann,

66 Gestão de Configuração GC e Qualidade de Software A GCS desempenha um papel central neste processo, permitirá que cada item de configuração de software seja especificado, projetado, construído, testado, avaliado, medido e controlado garante a efetiva aplicação das demais técnicas. 66

67 Gestão de Mudança Relacionamento direto com Gestão de Configuração Processo para avaliar, coordenar e decidir sobre a realização de mudanças em itens de configuração Mudanças aprovadas são implementadas em todos os artefatos relacionados 67

68 Gestão de Mudança Benefícios Controle sobre escopo do projeto Controle sobre o planejamento do que deve ser feito Qualidade no desenvolvimento, visto que toda mudança passa por análise de impácto Geração de dados para acompanhamento (ex. métricas) 68

69 Distribuição de Software Processo para empacotamento de aplicações (geração de build) Controle de liberação, ou seja, quais artefatos/componentes foram liberados e em que versões 69

70 SCM - posicionamento Engenharia de Software RUP ISO Métodos Ágeis GC, GM e Distribuição Cobit CMMi ITIL 70

71 SCM - Abrangência Começa quando o projeto tem início Continua durante todo o desenvolvimento e versões posteriores Só termina quando o software sai de produção 71

72 SCM QA QA Como garantir que uma mudança foi adequadamente implementada Dependendo do grau de formalismo exigidos Revisão técnica formal Auditoria 72

73 SCM - QA Revisão Técnica Formal Foco na exatidão técnica dos objetos de configuração Normalmente onde existe a maior probabilidade de falha Avalia-se consistência, omissões e efeitos colaterais 73

74 SCM QA Auditoria Deve responder: A mudanças especificada foi feita? Padrões foram seguidos? A mudança foi registrada? Todos os itens de configuração foram atualizados? Mudanças adicionais necessárias forma feitas e devidamente documentadas? 74

75 SCM - Benefícios Maior rapidez na identificação e correção de problemas Garante rastreabilidade entre produtos de software e suas partes (artefatos) Permite controle de versões Maior visibilidade do sistema Estabelece padrões (padronização) 75