• Nenhum resultado encontrado

Gerência de Projetos e Manutenção de Software Aula 10 Gerência de Configuração e Mudanças Andréa Magalhães Magdaleno 2017.

N/A
N/A
Protected

Academic year: 2021

Share "Gerência de Projetos e Manutenção de Software Aula 10 Gerência de Configuração e Mudanças Andréa Magalhães Magdaleno 2017."

Copied!
93
0
0

Texto

(1)

Gerência de Projetos

e Manutenção de Software

Aula 10 – Gerência de Configuração e

Mudanças

Andréa Magalhães Magdaleno andrea@ic.uff.br

(2)

2 GPMS 2017.02

Agenda

O Problema

Gerência de Configuração

Conceitos Básicos

Sistema de Gerência de Configuração

Processos

• Controle de Versões • Gestão de Mudanças • Construção e Release

(3)
(4)

Problema dos Dados Compartilhados

Componente Compartilhado Desenvolvedor A Desenvolvedor B A1 A2 A3 Programa de A Programa de B B1 B2 B3

(5)

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

(6)

6

GPMS 2017.02

Problema dos Dados Compartilhados

Solução

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

• Resolve o Problema dos Dados Compartilhados, mas

(7)

Problema da Manutenção Múltipla

Componente Compartilhado

Desenvolvedor A Desenvolvedor B

A1 A2 A3 B1 B2 B3

Programa de A Componente Programa de B

Compartilhado Versão de A do Componente Componente Compartilhado Componente Compartilhado Versão de B do Componente

(8)

8

GPMS 2017.02

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

(9)

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.

(10)

Problema da Atualização Simultânea

Versão de A do Componente Compartilhado Desenvolvedor A Desenvolvedor B A1 A2 A3 B1 B2 B3

Programa de A Versão de B do Programa de B

Componente Compartilhado Biblioteca Central de Recursos Compartilhados Componente Compartilhado

(11)

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

(12)

12

GPMS 2017.02

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

(13)

Problema da Atualização Simultânea

Soluçã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

(14)
(15)

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

(16)

16

GPMS 2017.02

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

disciplina

para o

controle da evolução de sistemas de software

(17)

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

(18)

18

GPMS 2017.02

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

(19)

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

(20)
(21)

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

(22)

22

GPMS 2017.02

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ório Cliente

(23)

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

(24)

24

GPMS 2017.02

Check-In

Processo de revisão, aprovação e cópia

de um item de configuração para o

repositório

Check-in

Repositório Cliente

(25)

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)

(26)
(27)

Sistema de Gerência de Configuração

Versão 1 Versão 2 Versão 3 Versão 4 Versão 5

(28)

28

GPMS 2017.02

Sistema de Gerência de Configuração

Versão 1

Versão 2

Versão 3

Versão 4

(29)

Sistema de Gerência de Configuração

Artefatos Controle de Versões Construção e Release Controle de Modificações Solicitações

(30)
(31)

Sistema de Gerência de Configuração

Construção e Release Controle de Modificações Solicitações Artefatos Controle de Versões

(32)

32 GPMS 2017.02

Tipos de Versão

Versão

Versão

Revisão

Revisão

Variante

Variante

Cooperação

(Rascunho)

Cooperação

(Rascunho)

(33)

Revisões

(34)

34 GPMS 2017.02

Variantes

Hatchback Coupe Sedan Honda Civic

(35)

Cooperação (versões rascunho)

Espaço de trabalho da Maria

Espaço de trabalho do Pedro

(36)

36

GPMS 2017.02

Versões de rascunho podem ser

combinadas (operação de

merge

)

João Maria Pedro

(37)

Conflitos podem ocorrer durante o

merge

João Paulo

(38)

38

GPMS 2017.02

Outras duas operações importantes…

… para guardar, transferir e compreender versões.

Diff =

(39)

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

(40)

40 GPMS 2017.02

Topologia

Repositório Espaço de Trabalho Centralizado Distribuído ch ec k-in / co m m it ch ec k-o u t / u p d at e Repositório Espaço de Trabalho ch ec k-in ch ec k-o u t / u p d at e Repositório Espaço de Trabalho clo n e / p u ll p u sh

(41)

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

(42)

42 GPMS 2017.02

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

(43)

Consulta

Repositório (versão 1) Artefato1 (versão 1) Artefato2 (versão 1) Artefato3 (versão 1) Repositório (versão 2) Artefato1 (versão 2) Artefato2 (versão 1) Artefato3 (versão 1) Repositório (versão 0) Repositório (versão 3) Artefato1 (versão 2) Artefato2 (versão 3) Artefato3 (versão 1) Artefato4 (versão 3) Repositório (versão 4) Artefato1 (versão 4) Artefato2 (versão 3) Artefato3 (versão 4) Artefato4 (versão 3) Artefato1 Versão 1 Versão 2 Versão 4 Artefato2 Versão 1 Versão 3 Artefato3 Versão 1 Versão 4 Artefato4 Versão 3

Consulta por artefato 1ª modificação

2ª modificação

4ª modificação 3ª modificação

(44)

44 GPMS 2017.02

Consulta

Repositório (versão 1) Artefato1 (versão 1) Artefato2 (versão 1) Artefato3 (versão 1) Repositório (versão 2) Artefato1 (versão 2) Artefato2 (versão 1) Artefato3 (versão 1) Repositório (versão 0) 1ª modificação 2ª modificação Repositório (versão 3) Artefato1 (versão 2) Artefato2 (versão 3) Artefato3 (versão 1) Artefato4 (versão 3) Repositório (versão 4) Artefato1 (versão 4) Artefato2 (versão 3) Artefato3 (versão 4) Artefato4 (versão 3) 4ª modificação 3ª modificação 1ª modificação Artefato1 adicionado Artefato2 adicionado Artefato3 adicionado 2ª modificação Artefato1 modificado 3ª modificação Artefato2 modificado Artefato4 adicionado

Consulta por modificação

4ª modificação

Artefato1 modificado Artefato3 modificado

(45)

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)

(46)

46

GPMS 2017.02

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 backupdo item de configuração deve ser realizado? Algum membro da equipe deve ser notificado?

• Quando retornar ao fluxo principal?

• Quando pode se considerar o branchcomo encerrado?

• Se foi para remover defeitos, o branchdeve acabar assim que esses defeitos tenham sido corrigidos, ou deve ser mantido para corrigir novos defeitos que foram

(47)

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. 1.0 RC Evolução 2.0 RC Evolução Desenv.

(48)

48

GPMS 2017.02

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

ABC DEF GHI JKL DEF ABC ou JKL? DEF GHI ou nada?

(49)

Exemplo

(50)

50

GPMS 2017.02

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

(51)

Principais sistemas de controle de

versão open-source

(52)

52

GPMS 2017.02

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

(53)
(54)

54

GPMS 2017.02

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

(55)

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)

(56)

56

GPMS 2017.02

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

(57)

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

(58)

58

GPMS 2017.02

Sistema de Gerência de Configuração

Construção e Release Artefatos Controle de Versões Controle de Modificações Solicitações

(59)

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:

(60)

60

GPMS 2017.02

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

(61)

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 Baseline 1: Projeto •An. Req. 1

Requisito 2 Análise Projeto

Tempo

Baseline 2:

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

(62)

62

GPMS 2017.02

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

(63)

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

(64)

64 GPMS 2017.02

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

(65)

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,

(66)

66

GPMS 2017.02

Gestão de Mudanças

(67)

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

(68)

68

GPMS 2017.02

Gestão de Mudanças

Análise de Modificação

(69)

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

(70)

70

GPMS 2017.02

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

(71)

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

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

(72)

72

GPMS 2017.02

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

(73)
(74)

74

GPMS 2017.02

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

(75)

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

(76)

76 GPMS 2017.02

Gestão de Mudanças

Ferramentas

Livre

• Bugzilla • Mantis • Redmine • Trac

Comercial

• ClearQuest (IBM Rational) • JIRA (Atlassian)

• StarTeam (Borland)

• Synergy/Change (Telelogic) • TeamTrack (Serena)

(77)
(78)

78

GPMS 2017.02

Sistema de Gerência de Configuração

Artefatos Controle de Versões Controle de Modificações Solicitações Construção e Release

(79)

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

(80)

80

GPMS 2017.02

Terminologia

Release

:

• Conjunto de produtos que deve ser entregue ao

cliente

Releases

diferem de versões, pois versões podem

(81)

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

(82)

82

GPMS 2017.02

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

(83)

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” no

desenvolvimento de software

• A geração de builds deve ser automatizada e realizada com

frequência adequada

(84)

84

GPMS 2017.02

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

(85)

Exemplo de ferramentas de build e release

Livre

Ant

NAnt

Make

Maven

Rake

Comercial

ClearMake (IBM Rational)

MSBuild (Microsoft)

(86)

86

GPMS 2017.02

Application Lifecycle Management

(ALM)

COS 823 - Aula 6 86

(87)

Collaborative Lifecycle Management

(88)

88

GPMS 2017.02

Collaborative Lifecycle Management

(CLM)

COS 823 - Aula 6 88 Out 2013 Requisitos Planejamento de Testes Gerenciamento de Defeitos Gerência de Configuração

(89)

Exercício

Como deve funcionar o processo de

gestão de mudanças?

Descrever o passo-a-passo

Detalhar

as

principais

atividades,

(90)

90

GPMS 2017.02

Dúvidas?

(91)

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's Approach”, McGraw-Hill.

(92)

92 GPMS 2017.02

Próxima Aula

Gerência de Configuração Garantia de Qualidade Verificação, Validação e Testes Planejamento de Projetos Gerência de Riscos Monitoramento e Controle Reutilização Medição e Análise Levantamento de Requisitos Análise de

Requisitos Projeto Codificação Comunicação Atividades Gerenciais Atividades de Desenvolvimento Atividades de Apoio Aquisição

(93)

Gerência de Projetos

e Manutenção de Software

Aula 10 – Gerência de Configuração e

Mudanças

Andréa Magalhães Magdaleno andrea@ic.uff.br

Referências

Documentos relacionados

• Os municípios provavelmente não utilizam a análise dos dados para orientar o planejamento de suas ações;. • Há grande potencialidade na análise dos micro dados do Sisvan

Kulčar 40 , encontrou benefícios semelhantes (Tabela 3) e, além disso, ao acompanhar os membros permanentes do grupo por um período de 10 anos, constatou uma

A origem do nome Açaí é que nós justamente tivemos o trabalho né, foi o processo foi feito com o SEBRAE né, foi dado as aulas pra nós, aí então, lá no curso ela pediu pra

A função gerente de obras torna-se cada vez mais necessária na construção civil, pois o setor está cada vez mais desenvolvendo e aprimorando a área de coordenação

Na Nova Zelândia em sistemas pastoris as vacas produzem em média 17 litros de leite ao dia, enquanto nos produtores analisados neste estudo a média de

Além disso, a falta de esclarecimento de toda a comunidade escolar sobre sua importância para a melhoria do desempenho dos educandos também contribuiu para que os pais não o

O trabalho intitulado PROJETO DE INTERVENÇÃO SOBRE A IMPLANTAÇÃO DA SISTEMATIZAÇÃO DA ASSISTÊNCIA DE ENFERMAGEM (SAE) PARA PACIENTES COM DIABETES MELLITUS NO

Therefore, the purpose of this study was to compare the fracture strength and failure mode of two Y-TZP monolithic systems, either polished or glazed, and bi-layer veneered Y-TZP