Gerência de Projetos e Manutenção de Software Aula 10 ...andrea/teaching/201801/gpms/GPMS-Aula10... · • O plano de gerência de configuração de software é o documento utilizado

Gerência de Projetos e Manutenção de Software

Aula 10 – Gerência de Configuração e Mudanças + ReutilizaçãoAndréa Magalhães Magdaleno

[email protected]

2018.01

2GPMS 2018.01

Agenda

• Gerência de Configuração

• Processos• Controle de Versões

• Gestão de Mudanças

• Construção e Release

• Reutilização

• Exercícios

O PROBLEMA

Problema dos Dados Compartilhados

ComponenteCompartilhado

Desenvolvedor A Desenvolvedor B

A1 A2 A3

Programa de A Programa de B

B1 B2 B3

5GPMS 2018.01

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

6GPMS 2018.01

Problema dos Dados Compartilhados Solução

• Cada desenvolvedor trabalha em uma cópia “local” do componente

• Resolve o Problema dos Dados Compartilhados, mas cria um novo problema...

Problema da Manutenção Múltipla



A1 A2 A3 B1 B2 B3

Programa de A Programa de BComponenteCompartilhado

Versão de A do Componente

Compartilhado



Versão de B do Componente

Compartilhado

8GPMS 2018.01

Problema da Manutenção Múltipla Cenário• Ocorre quando cada desenvolvedor trabalha com uma

cópia “local” do que seria o mesmo componente

• Dificuldade para saber:• Qual a versão mais “atualizada” do componente?• Que funcionalidades foram implementadas em quais

versões do componente?• Que defeitos foram corrigidos?• Qual versão do componente deve ser utilizada?

• A situação torna-se mais crítica, quão maior for o tamanho da equipe.

9GPMS 2018.01

Problema da Manutenção Múltipla Solução

• Criação de uma biblioteca central de componentes compartilhados• Nesse esquema, cada componente é copiado para a

biblioteca sempre que alterado

• Nessa biblioteca deve sempre estar disponível a versão mais nova do componente.

• Resolve o Problema da Manutenção Múltipla, mas...

Problema da Atualização Simultânea

Versão de A do Componente

Compartilhado


A1 A2 A3 B1 B2 B3

Programa de A Programa de BVersão de B do Componente

Compartilhado

Biblioteca Central de Recursos Compartilhados


11GPMS 2018.01

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

12GPMS 2018.01

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

13GPMS 2018.01

Problema da Atualização SimultâneaSolução

• 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

GERÊNCIA DE CONFIGURAÇÃO

15GPMS 2018.01

Gerência de Configuração (GC)

• Engenharia de Software envolve refinamentos sucessivos de artefatos

Tarefas de Engenharia de

Software

Artefato novo

Repositório

Artefato modificado

Artefato

16GPMS 2018.01

Gerência de Configuração (GC)

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

Gerência de Configuração

Gerência de Configuração de Software (GCS) é uma disciplinapara o controle da evolução de sistemas de software

(Susan Dart, 1991)

17GPMS 2018.01

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

18GPMS 2018.01

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

19GPMS 2018.01

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

CONCEITOS BÁSICOS

21GPMS 2018.01

Conceitos Básicos

• 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

22GPMS 2018.01

Check-Out

• Processo de requisição de modificações, aprovação e cópia de um item de configuração do repositório

Check-out

RepositórioCliente

23GPMS 2018.01

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

24GPMS 2018.01

Check-In

• Processo de revisão, aprovação e cópia de um item de configuração para o repositório

Check-in

RepositórioCliente

25GPMS 2018.01

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

SISTEMA DE GERÊNCIA DE CONFIGURAÇÃO

27GPMS 2018.01

Sistema de Gerência de Configuração

Artefatos

Controle de Versões

Construção e Release

Controle de Modificações

Solicitações

28GPMS 2018.01


Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

29GPMS 2018.01


Versão 1

Versão 2

Versão 3

Versão 4

Versão 5

CONTROLE DE VERSÃO

31GPMS 2018.01




Solicitações

Artefatos


32GPMS 2018.01

Tipos de Versão

VersãoVersão

RevisãoRevisão VarianteVarianteCooperação (Rascunho)Cooperação (Rascunho)

(Conradi e Westfechtel 1998)

33GPMS 2018.01

Revisões

Gerações do iMac (1998 – 2013)

34GPMS 2018.01

Variantes

Hatchback

Coupe

Sedan

Honda Civic

35GPMS 2018.01

Cooperação (versões rascunho)

Espaço de trabalho do João

Espaço de trabalho da Maria

Espaço de trabalho do Pedro

Versão base

36GPMS 2018.01

Versões de rascunho podem ser combinadas (operação de merge)

João Maria Pedro

Revisões

37GPMS 2018.01

Conflitos podem ocorrer durante o merge

João Paulo

Revisões

38GPMS 2018.01

Outras duas operações importantes…

… para guardar, transferir e compreender versões.

Diff =

Patch =

39GPMS 2018.01

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

40GPMS 2018.01

Topologia

Repositório

Espaço deTrabalho

Centralizado Distribuído

chec

k-in

/ co

mm

it

check-o

ut

/ up

date

Repositório

Espaço deTrabalhoch

eck-

in

check-o

ut

/ up

date

Repositório

Espaço deTrabalho

clon

e / pu

ll

pu

sh

41GPMS 2018.01

Armazenamento

v.3

v.2

v.1

Completo

delta 1�2

v.1

Forward

delta 2�3

delta 3�2

v.3

Reverse

delta 2�1

42GPMS 2018.01

Colaboração

m.3

m.2

m.1

Pessimista

junção

m.1

Otimista Misto

m.2 m.3

junção

m.1 m.2 m.3

43GPMS 2018.01

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

44GPMS 2018.01

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

45GPMS 2018.01

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 detrabalho– 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)

46GPMS 2018.01

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?

• Em que circunstâncias é justificável criar um novo branch? Apenas para correção de

bugs? Para realizar melhorias solicitadas pelos usuários?

• Quais os passos?

• Que procedimentos devem ser seguidos para criar um branch? Deve ser feita uma

solicitação formal? Um backup do item de configuração deve ser realizado? Algum

membro da equipe deve ser notificado?

• Quando retornar ao fluxo principal?

• Quando pode se considerar o branch como encerrado?

• Se foi para remover defeitos, o branch deve acabar assim que esses defeitos tenham

sido corrigidos, ou deve ser mantido para corrigir novos defeitos que foram

descobertos?

47GPMS 2018.01

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. 11.0 1.1 1.2

Rel. 22.0 2.1

Verif. Verif.

1.0 RC 2.0 RCEvolução EvoluçãoDesenv.

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

48GPMS 2018.01

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

ABCDEFGHI

JKLDEF

ABC ou JKL?DEFGHI ou nada?

49GPMS 2018.01

Exemplo(merge no Eclipse)

50GPMS 2018.01

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

51GPMS 2018.01

Principais sistemas de controle de versão open-source

52GPMS 2018.01

Exercício

• Definir um template e 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 as criações e junções de branches?

GESTÃO DE MUDANÇAS

54GPMS 2018.01

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

55GPMS 2018.01

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

56GPMS 2018.01

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

57GPMS 2018.01

Objetivos da Gestão de Mudanças

• Garantir que os artefatos do sistema alcançam emantêm uma estrutura definida através do seu ciclo devida

• Definir procedimentos e documentação necessáriospara realizar modificações nos itens de configuração

• Prover os mecanismos necessários para conduzirmudanças de uma maneira controlada

58GPMS 2018.01



Artefatos



Solicitações

59GPMS 2018.01

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

• A atualização de uma baseline consiste em check-out seguido de modificações e check-in

• 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

60GPMS 2018.01

Baseline (níveis de controle)

Coordenação c/ auditoria

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

Nível de controle

61GPMS 2018.01

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

Tempo

Baseline 2:

•An. Req. 1•Pr. Req. 1•An. Req. 2

62GPMS 2018.01

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 e 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

63GPMS 2018.01

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

64GPMS 2018.01

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

65GPMS 2018.01


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

66GPMS 2018.01


• Solicitação de Modificação

67GPMS 2018.01


• 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

68GPMS 2018.01


• Análise de Modificação

(Leon, 2000)

69GPMS 2018.01


• 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

70GPMS 2018.01


• 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

71GPMS 2018.01


• 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

– Falta de treinamento, padrões inadequados, ferramentas inadequadas

72GPMS 2018.01


• 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

73GPMS 2018.01


Resultado do relatório no modo tabular no Bugzilla

74GPMS 2018.01

Auditoria da configuração

• Deve ocorrer ao menos antes de uma liberação

(release)

• Tarefas

• Verificação funcional, assegurando que a baselinecumpre 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

75GPMS 2018.01

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

76GPMS 2018.01

Gestão de MudançasFerramentas• Livre

• Bugzilla• Mantis• Redmine• Trac

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

CONSTRUÇÃO E RELEASE

78GPMS 2018.01


Artefatos



Solicitações


79GPMS 2018.01

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

80GPMS 2018.01

Terminologia

• Release: • Conjunto de produtos que deve ser entregue ao

cliente

• Releases diferem de versões, pois versões podemser somente para uso interno ao projeto

81GPMS 2018.01

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

• 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

82GPMS 2018.01

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

83GPMS 2018.01

Geração de Builds através da Integração Contínua• Geração frequente 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” nodesenvolvimento de software

• A geração de builds deve ser automatizada e realizada comfrequência adequada

• DevOps x NoOps

84GPMS 2018.01

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...

85GPMS 2018.01

Exemplo de ferramentas de build e release

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

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

86GPMS 2018.01

Application Lifecycle Management(ALM)

COS 823 - Aula 6 86Out 2013

87GPMS 2018.01

Collaborative Lifecycle Management(CLM)

COS 823 - Aula 6 87Out 2013

88GPMS 2018.01

Collaborative Lifecycle Management(CLM)

COS 823 - Aula 6 88Out 2013

RequisitosPlanejamento de Testes

Gerenciamento de Defeitos

Gerência de Configuração

89GPMS 2018.01

Exercício

• Como deve funcionar o processo degestão de mudanças?• Descrever o passo-a-passo

• Detalhar as principais atividades,responsáveis e artefatos

REUTILIZAÇÃO DE SOFTWARE

Curso de Reutilização 9001/04/2011

91GPMS 2018.01

Motivação

• A Reutilização é inerente ao processo de solução deproblemas utilizado pelos seres humanos

• A medida em que soluções são encontradas, estassão utilizadas em problemas similares

• Nossa capacidade de abstração garante a adaptaçãonecessária ao novo contexto

• O problema, portanto, não é a falta de reutilização naEngenharia de Software, mas a falta de umasistemática ampla e formal para realizá-la

92GPMS 2018.01

Motivação

• Como?• Aplicando técnicas de engenharia de domínio para

definir o escopo, especificar a estrutura e construir

ativos reutilizáveis para uma classe de sistemas,

subsistemas ou aplicações

A Reutilização de Software visa sistematizar e difundir práticas de reutilização na organização

93GPMS 2018.01

Reutilização de Software

• A Reutilização de Software é a disciplina responsável

pela criação de sistemas de software a partir de

software preexistente [KRUEGER, 1992]

• Consiste na incorporação de software existente ou

conhecimento referente a esse software para construir

um novo

94GPMS 2018.01

Benefícios

• Melhores índices de produtividade

• Produtos de melhor qualidade, mais confiáveis, consistentes

e padronizados

• Redução dos custos e tempo envolvidos no desenvolvimento

de software

• Maior flexibilidade na estrutura do software produzido,

facilitando sua manutenção e evolução

95GPMS 2018.01

Desafios

• Identificação, recuperação e modificação de artefatos

reutilizáveis

• Compreensão dos artefatos recuperados

• Qualidade de artefatos reutilizáveis

• Composição de aplicações a partir de componentes

• Barreiras psicológicas, legais e econômicas

• Necessidade da criação de incentivos à reutilização

96GPMS 2018.01

Desenvolvimento baseado em reutilização• O processo de Reutilização de Software é composto por

dois processos principais

• Desenvolvimento para Reutilização

• Produção de ativos reutilizáveis para um domínio específico

através de técnicas de Engenharia de Domínio (ED)

• Desenvolvimento com Reutilização

• Construção de aplicações com base na instanciação dos

artefatos gerados através de técnicas de Engenharia de

Aplicação (EA)

ENGENHARIA DE DOMÍNIO


98GPMS 2018.01

� Domínio:

� Área de conhecimento ou atividade caracterizada por um conjunto de conceitos conhecidos dos profissionais dessa área (RUP, 1998).

� Exemplos:

Engenharia de Domínio

01/04/2011 98Curso de Reutilização

Óleo e Gás Seguros Telefonia móvel

99GPMS 2018.01

� Componentes? Arquitetura? Reuso?



100GPMS 2018.01

� Uma abordagem baseada em reutilização paradefinição do escopo, especificação da estrutura, econstrução de recursos para uma classe desistemas, subsistemas ou aplicações (ISO/IEC12207).

� Processo de identificação e organização doconhecimento sobre uma classe de problemas, odomínio do problema, para suportar sua descriçãoe solução (ARANGO, PRIETO-DIAZ, 1991)



101GPMS 2018.01

� Objetivos:

� Originar meta-sistemas, ou seja, sistemas que sãoreutilizados na construção de aplicações específicas

� Descobrir e definir modelos de domínio e arquiteturascomuns às famílias de aplicações para suportar reutilizaçãopré-planejada

� Tornar explícito e formalizar as teorias específicas aodomínio que permitem aos projetistas e especialistas dodomínio raciocinar sobre problemas e sistemas no domínioda aplicação



102GPMS 2018.01

� Etapas:

� Análise de Domínio: o conhecimento existente sobre odomínio é estudado e formalizado através de um modelo dedomínio

� Projeto de Domínio: arquiteturas de software sãoconstruídas para atender aos requisitos identificados nomodelo de domínio

� Implementação do Domínio: artefatos reutilizáveis são implementados para compor as arquiteturas



103GPMS 2018.01

� Profissionais envolvidos:

� Fontes: usuários finais que utilizam aplicações no domínio e especialistas de domínio que provêm informações a respeito de conceitos e funcionalidades relevantes no domínio

� Produtores: analistas e projetistas do domínio que capturam as informações do domínio das fontes e aplicações existentes e realizam a análise, projeto e implementação dos artefatos reutilizáveis (i.e. Engenheiros de Domínio)

� Consumidores: desenvolvedores de aplicações e interessados no entendimento do domínio


01/04/2011 103Curso de Reutilização(SIMOS, 1996; WERNER e BRAGA, 2005)

104GPMS 2018.01

� Produtos:

� Modelos conceituais que capturam os principais conceitos e funcionalidades do domínio

� Estrutura arquitetural a ser seguida pelas aplicações� Artefatos implementacionais� Documentação associada

Obs. Servem como fonte unificada de referência (repositório de conhecimento)



105GPMS 2018.01

Modelagem de características

• Característica

• Um aspecto, uma qualidade, ou uma característica visível ao

usuário, proeminente ou distinta, de um sistema de software

(KANG et al., 1990)

• Objetivo: capturar e gerenciar as similaridades e diferenças, deforma a facilitar o entendimento de clientes e desenvolvedores noque se refere às capacidades gerais de um domínio, que sãoexpressas através de características (KANG et al., 1990)


106GPMS 2018.01


• Variabilidade:• Habilidade que um sistema ou artefato de software possui de ser

alterado, customizado, ou configurado para um contexto em particular(BOSCH, 2004).

• Ponto de variação: característica que reflete a parametrização nodomínio de uma maneira abstrata. Um ponto de variação é configurávelatravés das variantes

• Variantes: características que atuam como alternativas para seconfigurar um ponto de variação

• Invariantes: características fixas, que representam elementos nãoconfiguráveis em um domínio


107GPMS 2018.01


• Opcionalidade:• Elementos opcionais: podem ou não estar presentes nos produtos

derivados a partir da linha de produtos

• Elementos mandatórios: devem obrigatoriamente estar presentesem todos os produtos derivados a partir da linha de produtos

• Relações:• Dependência: relação que representa a necessidade de seleção de

elementos em conjunto

• Mútua exclusividade: relação que representa a incompatibilidadeda seleção conjunto de determinados elementos


108GPMS 2018.01

� Primeiras abordagens:

� Draco (NEIGHBORS, 1989)� FODA (Feature Oriented Domain Analysis) (KANG et al., 1990)� Facetas (PRIETO, 1991)� EDLC (Evolutionary Domain Life Cycle) (GOMMA, 1992)� ODM (Organization Domain Modeling) (SIMOS, 1996)� FODACom (GRISS, 1998)

� Abordagens mais recentes:

� FORM (Feature-Oriented Reuse Method) (KANG, 2002)� Odyssey-FEX (OLIVEIRA, 2006)� ...

� Abordagens que mesclam outras técnicas:

� DBC, ontologias, CSCW, gestão do conhecimento, agentes, aspectos, etc

Abordagens Existentes


(WERNER e BRAGA, 2005)

109GPMS 2018.01

� Exemplo Notação FODA:



(KANG et al., 1990; OLIVEIRA, 2006)

110GPMS 2018.01

� Exemplo Notação Czarnecki:



111GPMS 2018.01


• Exemplo Notação Odyssey-FEX:


(OLIVEIRA, 2006)

ENGENHARIA DE APLICAÇÃO


113GPMS 2018.01

Engenharia de Aplicação

• Estudo e uso de técnicas, processos e métodos para a produção de aplicações baseadas em reutilização (SIMOS, 1998)

• Desenvolve produtos de software baseado nos artefatos gerados pelo processo de Engenharia de Domínio (SEI, 2005)


114GPMS 2018.01


• Atividade de “recorte”

• Seleção dos componentes necessários à aplicação em um alto

nível de abstração, por meio do modelo do domínio, descendo

gradualmente em níveis de abstração até conseguir atingir os

componentes implementados ou semidesenvolvidos do

domínio (MILER, 2000)

• Fortemente influenciada pela variabilidade modelada no

domínio

• Características variáveis em artefatos do domínio determinam o

tipo de aplicação que será instanciada

115GPMS 2018.01


• Possibilidade de utilização de um método dedesenvolvimento conhecido pela organização, porémincorporando atividades de reutilização.• Ex.:

• Desenvolvimento baseado em componentes (DIGRE, 1998)• Arquitetura de Software (ARPA, 1994)

• Na EA os componentes são efetivamente reutilizados ecombinados entre si para a construção de aplicaçõesreais.

Curso de Reutilização 11501/04/2011(MILER, 2000)

116GPMS 2018.01


• Etapas:• Análise da Aplicação: seleção do conhecimento e artefatos do

domínio que são necessários para construir uma aplicação a partir de requisitos iniciais.

• Projeto da Aplicação: identificação na arquitetura de software dos artefatos que serão combinados na construção da aplicação.

• Implementação da Aplicação: os artefatos reutilizáveis selecionados são implementados para compor a aplicação.


LINHA DE PRODUTOS


118GPMS 2018.01

Linha de Produtos

• Definição• Conjunto de sistemas de software que compartilham

um conjunto de características comuns econtroladas, que satisfazem necessidades de umsegmento de mercado em particular, e sãodesenvolvidas a partir de artefatos (core assets), deforma predefinida (NORTHROP, 2002).


119GPMS 2018.01

Linha de Produtos

• Etapas (NORTHROP, 2002)


120GPMS 2018.01

Linha de Produtos

• Desenvolvimento de núcleo de artefatos• Escopo da linha de produtos• Artefatos do núcleo• Plano de Produção


121GPMS 2018.01

Linha de Produtos

• Desenvolvimento do Produto

• Análise do domínio da aplicação

• Possibilidade de evolução da LP !

• Instanciação da arquitetura do produto

• Povoamento da arquitetura


122GPMS 2018.01

Dúvidas?

123GPMS 2018.01

Principais Referências Bibliográficas

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

• 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. 232-282, 1998.

• 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'sApproach”, McGraw-Hill.

Gerência de Projetos e Manutenção de Software

Aula 10 – Gerência de Configuração e Mudanças + ReutilizaçãoAndréa Magalhães Magdaleno

[email protected]

2018.01

Documents

Gerência de Projetos e Manutenção de Software Aula 10 ...andrea/teaching/201801/gpms/GPMS-Aula10... · • O plano de gerência de configuração de software é o documento utilizado