Gerência de configuração

5/13/2018 Gerência de configuração - slidepdf.com

http://slidepdf.com/reader/full/gerencia-de-configuracao 1/57

Gerência deconfiguração

Um das partesfundamentais no

desenvolvimento de umsoftware.



Como era antes de surgir a gestão de

configuração...} Antes de existir este processo de apoio aodesenvolvimento de software, existiam cenários quepoderiam ocorrer nas fases do projeto de software deuma empresa, que consistiam de problemasrelacionados a inconsistência de quem fez o que,onde e quando.

} Com isso, basicamente, poderiam surgir três tipos deproblemas muito comuns na falta de um elemento quecontrolava mudanças, que são:




configuração...



O da manutenção múltipla geralmenteocorre quando se tenta resolver o problemados dados compartilhados, e então osresponsáveis pelo objeto do software em

questão ficam com uma cópia docomponente em suas máquinas, nãohavendo risco de um outro colega mexer,mas mesmo assim surgem problemas no

sentido de que não se sabe como quaisfuncionalidades foram implementadas,como ele está sendo desenvolvido quase queindependentemente, as pessoas não sabem oque falta ou que ele já possui, se erros foram

consertados ou adicionados para futura

PROBLEMA

2


configuração...




configuração...O da atualização simultânea trata-se dequando o componente em questão, comumaos desenvolvedores responsáveis, ficanuma biblioteca central de arquivos

compartilhados, e então cada um quandotermina uma alteração envia para esta talbiblioteca, porém eles desconhecem asversões mais prévias e pode ser que eles

corrigem os mesmos defeitos, por nãosaberem o que o anterior fez, desperdiçandoum trabalho já feito ou um desenvolvedorenvia além da alteração que já havia sidofeita, envia uma cópia com erro. Ou seja,

desperdiça trabalho e ainda manda uma

PROBLEMA

3



Como eliminar os três problemas

anteriores:} Então resolvendo os empecilhos de

antes, foi criada a gerência deconfiguração, que é uma forma de

organizar e armazenar as alterações eversões dos itens de configuração desoftware.



Definição} Segundo Sommerville, o gerenciamento de configuração

(configuration management ² CM) é o desenvolvimento eaplicação de padrões e procedimentos para gerenciar umproduto de sistema em desenvolvimento. É necessáriogerenciar os sistemas em desenvolvimento porque, à

medida que eles se desenvolvem, são criadas muitasversões diferentes de software.

} Essas versões incorporam propostas de mudanças,correções de defeitos e adaptações para diferentes

hardwares e sistemas operacionais. É possível que hajavárias versões em desenvolvimento e em uso ao mesmotempo. É necessário manter o controle das mudanças queforam implementadas e de como essas mudanças foramincluídas no software.



Definição}Ou seja, a gerência de configuração é

um conjunto de atividadesadministrativas e técnicas que devem ser desenvolvidas para administrar as

alterações durante o ciclo de vida dosoftware.

} Para um software obter qualidade, devecumprir uma série de especificações e

normas, dentre as quais está aimplementação deste tipo degerenciamento.



Gerência de configuração e asnormas de qualidade

} Dependendo de qual a norma adotada pela empresapara realizar seus serviços apesar de a gerência deconfiguração continuar tendo os mesmos objetivosgerais, que é controlar as alterações, de forma coerentee que deixe os itens de configuração com suaintegridade, os passos para alcançar estes objetivos delasão um pouco alterados.

} Por exemplo, se for na CMMI, eles focam bastante ospassos em relação às baselines, além disso de acordocom as normas o modo de organizar as etapas do ciclode vida também mudam.



Passos da gestão de configuração

adotados e ISO 12207} A norma internacional NBR ISO/IEC 12207 ²

Tecnologia da Informação ² Processos de Ciclo deVida de Software [ISO12207: 97] é usada como

referência em muitos países, inclusive no Brasil.

} Ela tem por objetivo auxiliar os envolvidos naprodução de software a definir seus papéis, por meio de processos bem definidos, e assimproporcionar às organizações que a utilizam ummelhor entendimento das atividades a seremexecutadas nas operações que envolvem, dealguma forma, o software.



Passos da gestão de configuração

adotados e ISO 12207} A arquitetura descrita na norma é composta de:

processos, atividades e tarefas para aquisição,fornecimento, desenvolvimento, operação, emanutenção do software.

} Os processos de apoio auxiliam e contribuem para osucesso e a qualidade do projeto de software.

} Um processo de apoio é empregado e executadoquando necessário para documentação, gerênciade configuração, garantia da qualidade, processode verificação, processo de validação, revisãoconjunta, auditoria e resolução de problemas.



Estrutura e organização do software segundoa ISO 12207:



Conceitos importantes e fundamentais...

Linhas debase

referencial,versão

congelada jáaprovada

Repositóriosdos itens de

configuração

Tipos e

exemplos decada;

Vantagens edesvantagens

dos tipos;

Característicasde alguns

repositórios(CVS e GIT).

Check In eCheck Out

Saída de uma

cópia do itempara ser editada.

Entrada do itemconfigurada/alter ado após revisãoe concordância.



Linhas de base} São pontos bem definidos ao longo do processo de

desenvolvimento de software, que podem ocorrer ao final decada uma das fases do desenvolvimento de software, ou dealgum outro modo que pode ser definido pelo gerenteresponsável.

} Segundo a IEEE-STD-610, se trata de uma especificação ouproduto que foi formalmente revisado e sobre o qual foiestabelecido acordo, que serve como base para odesenvolvimento subsequente , e que pode ser mudado apenasatravés de procedimentos de controle de mudança formais.

} Ou seja, as linhas de base são uma referência que já foi analisadae aprovada, é uma base estável para futuras modificações, queauxilia na evolução contínua dos itens de configuração.Só vai ser armazenado de volta no repositório o item que tiver suasolicitação de alteração formalmente aceita pelo gerente, para evitar inconsistências.



} O repositório é um local sob controle de acesso (banco de dados)onde são armazenados os Itens de Configuração de Softwaredepois de liberados por uma linha-base.

} Ele pode ser um sistema de arquivos locais ou um servidor remoto,de qualquer forma é utilizado para controlar o acesso à arquivos,mudanças e providencia uma árvore de versão para gerenciar

versões diferentes de arquivos.} Suas principais vantagens são a possibilidade de controle do

histórico; o favorecimento do trabalho em equipe; a marcação eo resgate de versões estáveis e a possibilidade de ramificação doprojeto.

} Alguns repositórios, como o CVS, permitem integração com

ambientes de desenvolvimento diretamente, como ocorre por exemplo com o NetBeans e o Eclipse. No Eclipse, tem queadicionar um repositório na perspectiva CVS repository, e depoisconfigura colocando o nome do host do servidor o usuário e asenha, pode sincronizar os arquivos da equipe dedesenvolvimento a que pertence, etc.

Repositórios dos itens configuração



} Os repositórios podem ser de dois tipos: os centralizados eos distribuídos.







Repositórios dos itens configuração} Centralizados:

Desvantagens: São extremamente

dependentes dorepositório que contém osdados;

Necessidade de uma boa

estrutura de backup.

Vantagens: Mantém as informações

referentes aos arquivos emum repositório único

acessível a todos osdesenvolvedores de umprojeto;

Simplicidade;

Facilidade de controlar oacesso.

} Distribuídos:

Desvantagens: São mais complicados de

gerenciar;

Por poder ter vários usuáriosacessando os projetos dosrepositórios dos outros, é preciso ter maior atenção no controle do

acesso ao mesmo.

Vantagens: Cada projeto é um repositório

completo, com histórico total;

Independente de acesso à redeou servidor central;

Os commits podem ser feitos off-line;

Os commits podem ser enviadospara outro repositório assim comopodem ser recebidos de outrorepositório; ou seja, há umafacilidade de transferência entre

eles.



Características do CVS:

} O CVS utiliza uma arquitetura cliente-servidor: um servidor armazena a(s)

versão(ões) atuais do projeto e seu histórico, e os clientes se conectam aesse servidor para obter uma cópia completa do projeto, trabalhar nessacópia e então devolver suas modificações. Apesar de ele ter que ser

usado em rede para se comunicar com o servidor, pode-se trabalhar ófflineµ colocando o servidor e a máquina cliente na mesma máquina,geralmente põe-se o servidor no Unix e o cliente em qualquer outro sistemaoperacional.

} Os projetos controlados pelo CVS podem ser formado por módulos, assimsendo, o CVS permite a um usuário ou grupo de usuários que editem essesmódulos de maneira concorrente (ou seja, vários usuários podem estar alterando simultaneamente o mesmo arquivo na área de trabalho dodesenvolvedor ). Ao confirmar as alterações, o servidor faz um merge dasmesmas. Ou seja, ele une todas incrementando o código original com asalterações, colocando a data e o autor de todas elas em seus arquivos delog. Acesso Concorrente




Características do CVS:

} Os clientes também podem usar o comando "update" para manter suas cópias locais atualizadas com a última versão do servidor. Issoelimina a necessidade de se fazer diversos downloads de todo oprojeto.

} O CVS também pode manter diferentes "estados´ (momentos) doprojeto. Por exemplo, uma versão do software pode ser um dessesestados, usado para correção de possíveis erros, enquanto outraversão, que está realmente sob desenvolvimento, sofrendoalterações e tendo novas funcionalidades sendo adicionadas,forma o outro estado. Manutenção de estados

} Um servidor CVS pode gerenciar diversos módulos; ele armazenatodos os módulos administrados por ele em seu repositório. A cópiado módulo que foi baixada para um cliente é chamada cópia detrabalho. Em cada pasta do projeto o CVS cria uma pasta decontrole, com alguns arquivos dentro.




Ilustração do CVS


Envio e resgate de versões.



}

Uma das empresas que utilizam o CV S é oMoodle, na figura abaixo está a imagem daspastas do servidor remoto do CVS do Moodle,tem a pasta do banco de dados, e outras. Éclaro que é só para consultar, se for alterar temque cadastrar, ter um usuário e uma senha.




} E esta é da parte de tradução do Moodle para oportuguês. Que na raiz estava em lang, e dentrodesta foi escolhida pt_utf8.




} Esta é a parte onde aparecem as opções para osdesenvolvedores dos clientes CVS se ´divertiremµ.




Características do GIT} Foi criado por Linus Torvalds em 2005 com o objetivo inicial

de manter o kernel e o código fonte do Linux. Foi escritoem C, Bourne Shell e Perl.

}

É rápido, eficaz, acessível, multiplataforma, é usado emgrandes, médios ou pequenos projetos.

} Não precisa estar ligado a um servidor necessariamente.Você pode dar um commit parcial com o comando add epode ser offline.

} Através do GIT-SVN é possível usar o git em repositóriosSVN.




Características do GIT} Ele pode ser usado via git bash (linha de comando dele

quando instalado no windows), ou pelo terminal dolinux.




Características do GIT} Ele pode ser usado via interface gráfica, na figura

abaixo está a GUI para windows:


E xistem interfaces para outros sistemas também: gitk; GitX(Mac OSX);TortoiseGit (Windows); Git E xtensions (Windows);Qgit (Qt).



Características do GIT} Os repositórios GIT podem estar hospedados de forma pública

ou provada em alguns servidores remotos, o mais conhecido éo git hub, por ele estar aberto tanto para iniciantes quantopara desenvolvedores experientes, além disso, como elepermite tornar o repositório público ou privado, empresas

também o usam.


Hospedagem pública:

repo.or.cz -

http://repo.or.czGitorious -

Http://gitorious.org/

Hospedagem privada:codebase -

http://www.codebasehq.com/

Unfuddle -

http://unfuddle.com/

Hospedagem Privada ePública:

GitHub -

http://github.com/CodaSet -

http://codaset.com/



Aplicações do GIT




Check In e Check Out} Check In/Check Out é o método utilizado para trabalhar com itens deconfiguração que já estão no repositório, ou seja, conferência na

entrada e conferência na saída.

} Quando for desejada uma alteração em algum item de configuraçãodo repositório, uma cópia do item é colocada numa área de trabalhodo desenvolvedor (ćheck outµ). Dentro de sua área, o desenvolvedor tem total liberdade de trabalho.

} Após o final das alterações no item de configuração, ele será revisadoe recolocado no repositório (ćheck inµ).

} Uma nova linha-base deverá ser traçada, de modo que uma novaconfiguração contendo o item alterado seja formada e congelada norepositório.

} Depois do congelamento, o acesso é liberado, permitindo que outrosdesenvolvedores também executem alterações sobre esse item deconfiguração.



Check In e Check OutIlustração do sistema de conferência de entrada e saída:



Passos e tarefas da gerência de

software seguindo a ISO 12207:97

} Implementação do processo;

} Identificação da configuração;

} Controle da configuração} Relato da situação da configuração

} Avaliação da configuração

} Gerência de Liberação e distribuição



Implementação do processo...} Como várias normas de qualidade abordam sobre a

gerência de configuração, como sendo um requisitopara que uma empresa possa ter uma melhora daqualidade do processo de desenvolvimento do software,isso tem feito com que várias empresas a adotem.

} Deve ser estabelecida com uma política organizacionalbem definida;

} Para cada projeto deve-se ter um plano de gerência deconfiguração que respeite o processo da organização;

} Documentação de quaisquer desvios do processo noplano de gerência;



} Deve ser definida uma equipe para ser responsávelpelo controle da configuração do projeto. Os membrosdo grupo de gerência devem ser treinados nosobjetivos, procedimentos e métodos para desenvolver as atividades de gerência.

} É necessário também, oferecer e adequar recursospara que estas atividades possam ser realizadas assimcomo a disponibilização de ferramentas para dar suporte a elas.

} Há alguns processos dentro desta fase que são: Definição da política organizacional (DPO);

Definição de repositório (DR); Definição do grupo de gerência de configuração (DGGC);

Elaboração do plano de gerência de configuração(EPGC).

Implementação do processo...




DPO & DR

Definição de Política organizacional (DPO)} Serve para especificar as responsabilidades do analista de gerência

de configuração para os projetos de software.

} Especifica também sobre quais escopos de produtos a gerência deconfiguração vai ser implementada, pode ser produtos de softwareinternos, os que serão entregues aos clientes, ou até mesmo

ferramentas utilizadas, por exemplo, ou seja quais tipos de produtosserão controlados e em qual período do projeto.

Definição de Repositório (DR)} Estabelece um repositório (uma biblioteca)para armazenar os itens de

software do projeto, para dar apoio ao controle da gerência , em

vários aspectos, permitindo o gerenciamento de tais itens, dandosuporte à adição, atualização e recuperação.

} Também auxilia a utilização de padrões, ajudando a assegurar acriação correta de produtos de software e viabilizando arecuperação de todas as versões. Cada repositório tem sua políticade funcionamento definida.



Definição do grupo de gerência de configuração (DGGC)} Define um grupo responsável por coordenar e implementar a gerência de

configuração, com atividades definidas e consistentes, que também deveser responsável pelo desenvolvimento, manutenção e distribuição dosplanos de gerência de configuração, padrões e procedimentos. Estegrupo de ser treinado e apto para realizar tais tarefas.

} Este grupo também cria, mantém e gerencia o acesso ao repositório deitens. Identifica produtos de trabalho que serão mantidos pela gerência;define as baselines de software; cria produtos no repositório de itens.


DGGC & EPGC

Elaboração de plano de gerência de configuração (EPGC)} O plano é desenvolvido, revisado e aprovado, pelas pessoas envolvidas,

na fase de planejamento do projeto. Ele contém as atividades a seremdesenvolvidas, o cronograma das mesmas, as responsabilidadesdesignadas e os recursos que são necessários.

} Ele deve estar sempre disponível para consulta e como meio deinformação para todos os envolvidos.



Identificação da configuração

} A fase de identificação é para escolher dentredocumentos, requisitos, versões de produtos de umciclo ou qualquer outra coisa que esteja no escopo dodesenvolvimento, um conjunto ou um elemento sópara poder fazer parte do grupo que estará disponível

para ser alterado.

} Os itens de configuração podem ser produtos trabalhode softwares ou produtos de desenvolvimento dosmesmos, selecionados seguindo critérios que a equipedesejar para definir a prioridade, e o que fará parte doconjunto de configuração de software.

} Os itens de configuração são definidos em pontosespecíficos do desenvolvimento e resultantes de tarefasconstantes no plano de projeto.



} A diferença entre os dois produtos é que o enquanto o primeiro, quetambém pode ser chamado de artefato, se refere a versões quenormalmente são entregues à clientes finais, ou seja não são internos aogrupo de desenvolvimento, são releases funcionando.

} O outro pode ser descrição de processos, planos, procedimentos,programas de computador e documentos relacionados, que podem ounão ter a finalidade de ser entregue a um cliente ou usuário final.

} Normalmente e preferencialmente respeitam-se alguns critérios deescolha dos itens, como o estágio deles no ciclo de vida (a ordem emque eles precisam estar definidos); se ele é um produto de trabalhopronto para ser testado; o grau de controle necessário para um produto

de trabalho; se ele é um requisito de um cliente em avaliação;limitações de custo e cronograma.




} Cada item deve receber um identificador único e suas características e seus

responsáveis devem ser identificados.

} Esta fase serve para manter os itens sob controle de versão e mudanças;disponibiliza a descrição do item, a data em que foi colocado sob controle deversão, o responsável por ele, sua localização, informação do status em que elese encontra, e as baselines de que ele faz parte. Além disso, há a identificaçãodos registros de controle de mudanças e do próprio controle.


Item Projeto Tipo Nome Versão Nome CompletoEspecificação do

sistemaBB ES 1.1 BBES v1.1

Plano de projeto BB PP 1.1 BBPP v1.1

Especificação de

requisitos do

software

BB ER 1.1 BBER v1.1

Especificação de

projetoBB EP

Prin1.1 BBEPPrin v1.1

Programa fonte BB PF 1.1 BBPF v1.1Programa fonte (sub-

rotinas)BB PF

Rot1.1 BBPFRot v1.1

Plano e casos de

testesBB PT 1.1 BBPT v1.1

Nova versão da

especificação de

projeto

BB EP

Prin

1.2 BBEPPrin v1.2

E xemplo de descrição de itens de configuração



} Nesta fase é estabelecida uma comissão que tenha autoridade paragerenciar as baselines do projeto de software (comissão de controle demudanças).Esta comissão é responsável por autorizar o estabelecimentode uma baseline de software e a identificar os itens de configuração, deacordo com os interesses do gerente de projeto e de todos os gruposque possam ser afetados pelas alterações das baselines de software.Elas só podem ser alterados através de procedimentos documentados.

} Este procedimento deve especificar as revisões ou testes de regressãoque serão realizados para garantir que as modificações não causemefeitos inesperados nas baselines.

} Para garantir um controle sobre as solicitações de mudanças e relatos

de problemas, eles devem ser submetidos , armazenados, revisados,aprovados e rastreados para todos os itens de configuração, de acordocom um procedimento documentado.

Controle da configuração



} Os status dos itens de configuração precisam ser armazenados de acordo com umprocedimento documentado. Este procedimento deve especificar que as atividades degerência de configuração devem ser armazenadas com informações suficientes para quetorne possível saber o conteúdo e o estágio em que estão cada item de configuração epara que a versão anterior possa ser recuperada. Mantendo assim o status atual e ohistórico de cada item.

} Há alguns processos dentro desta fase que são:

Controle de mudanças(CM);

Definição de baselines (DB); Armazenamento do Status dos itens de configuração (ASIC).


Controle de mudanças (CM)

} Estabelece uma comissão com autoridade para gerenciar as mudançassolicitadas ao projeto de software. Além de permitir a abertura de solicitações demudança e melhorias para o projeto, é feito o armazenamento de todas estas

solicitações de mudanças, estas as mudanças efetuadas sã aprovadas erevisadas.

} É feito o registro os dados da alteração, tais como quem alterou, o que foialterado e quando ocorreu a alteração. Mantém a rastreabilidade entre todas asalterações efetuadas e as solicitações de mudanças que acarretaram nasalterações. Além de permitir a recuperação do histórico de controle dasmudanças.

C M



Definição de baselines (DB)} Define linhas que servirão de base para o desenvolvimento do projeto e/ou

versões de software que irão compor releases (entregas). A definição dasbaselines deve ser feita de acordo com um procedimento documentado, ondeentrarão apenas os itens de configuração que foram aprovados pela comissãoresponsável pelo controle de mudanças, após revisados e testados.

} A definição de novas baselines através das alterações das mesmas devem ser

controladas de acordo com procedimento documentado. As novas baselinesprecisam ser aprovadas pela comissão responsável pelo controle de mudanças.Os produtos podem ser criados a partir de baselines e seus releases devem ser controlados de acordo com procedimentos documentados. Apenas itens deconfiguração podem compor as baselines. As alterações nos itens deconfiguração devem garantir que as baselines mantenham-se corretas eíntegras.

D B e ASIC


Armazenamento do Status dos itens de configuração (ASIC)} Define um procedimento documentado sobre quais atividades de gerência de

configuração devem ser armazenadas. Especifica os detalhes de cada itemarmazenado para que o status possa ser recuperado. Permite a recuperação daversão anterior do status.



} Os relatórios e documentos das atividades de gerência de configuração

de software devem ser disponibilizados, assim como os conteúdos dasbaselines que devem ser colocados à disposição de todos os envolvidos.

} Para isso, nesta fase, há um processo que diz respeito à disponibilizaçãodo status da configuração. Ele serve para disponibilizar para toda aequipe envolvida o status da configuração para que todos saibam oandamento da mesma, e fiquem a par, por exemplo, de quais baselineseles devem tomar de referência a partir de um determinado momento.

} Nesta fase são gerados relatórios e documentações com todas asatividades relevantes de Gerência de configuração. Alguns exemplos derelatórios e documentações são: relato de realização de auditorias; denão conformidades encontradas e resolvidas; definições de novas

baselines; coleta de métricas; releases entregues; solicitações demudanças resolvidas, abertas ou em desenvolvimento.

} E estes relatórios são disponibilizados a todos os envolvidos, de forma quetodos saibam a situação de toda a configuração em um determinadomomento. Também há o relato do progresso da configuração nodecorrer do projeto de software.

Relato da situação da configuração



Ilustração do conteúdo dos

relatórios:



} Para avaliar as configurações do software são feitas auditorias deconfiguração, que devem ser realizados de acordo com umprocedimento documentado. Este procedimento deve especificar aexistência de uma preparação adequada para execução deauditorias, que devem assegurar a integridade das baselines dosoftware.

} As auditorias também possuem a função de verificar as estruturas efacilidades do repositório de itens incluindo se eles estão completos ecorretos. Além disso, ele verifica se realmente estão sendo respeitadose utilizados os procedimentos e padrões de gerência de acordo comsuas prévias definições.

} Os resultados das auditorias devem ser reportados ao gerente deprojeto, e planos de ação devem ser elaborados e acompanhadospara corrigir as não conformidades encontradas nas auditorias até seufechamento.

Avaliação da configuração



} O grupo responsável pela melhoria da qualidade de software também deve revisar eauditar as atividades e os produtos de trabalho do grupo de gerência deconfiguração de software e comunicar os resultados a todos os envolvidos. Asauditorias também devem verificar a ocorrência de auditorias de baseline desoftware periódicas.

} E xistem dois tipos de auditoria de configuração que são obrigatórias nas linhas dereferência do ciclo de desenvolvimento e manutenção de software, que são a

funcional e a física. A primeira preocupa-se com aspectos internos dos arquivos,compreendendo uma verificação o técnica formal nos itens de configuração. Estaverificação é uma atividade de controle de qualidade que tenta descobrir omissõesou erros na configuração, que degradam os padrões de construção do software. Asegunda complementa a primeira determinando características não consideradasdurante a revisão, como a efetuação da revisão técnica e se os padrões deengenharia de software foram cumpridos.

} Um outro jeito de avaliar a configuração é com a coleta e análise de métricas, quedevem ser coletadas e utilizadas para determinar o status das atividades degerência de configuração de software. As atividades de gerência de configuraçãodevem revisadas com o gerente sênior e pelo gerente de projeto periodicamente oueventualmente.


AGC




AGC

} Neste passo da gerência há dois processos:

Auditoria de gerência de configuração (AGC);

Coleta de métricas (CMe).

Auditoria de gerência de configuração (AGC)

} Verifica se o projeto segue as práticas e políticas definidas para gerência

de configuração para o projeto. Elas incluem desde a forma de nomear os itens de configuração até a forma como devem ser solicitadas asmudanças, e também a aprovação, geração e liberação das releases.

} Algumas atividades feitas neste processo compreendem a auditoriaregular do projeto de software de acordo com o cronograma definido naspráticas de gerência, seguindo check -lists, por exemplo; caso sejam

encontradas não conformidades nestas auditorias, planos de açãodevem ser elaborados, com datas definidas para seu fechamento e oresponsável pela correção a ser feita, para poder corrigir os problemasencontrados; os resultados devem ser comunicados ao responsável peloprojeto; o auditor deve acompanhar cada não conformidade abertapara o projeto, sendo responsável por determinar se a solução propostano pleno de ação é suficiente para resolver o problema.

C M




C Me

Coleta de métricas (CMe)

} Métricas se referem a dados numéricos extraídos do material em análiseno projeto de software, que servem para traçar metas e demonstrar graficamente e/ou em tabelas.

} Pois bem, elas devem ser coletadas para poder analisar os status daconfiguração, se estão de acordo com o planejado. Alguns exemplos demétricas são: número de solicitações de mudanças de defeitos abertaspara determinado release para verificar se estão na meta; número denão-conformidades encontradas; tempo utilizado em cada atividade, etc.

} Os dados das métricas servem para definir metas e traçar o perfil do

projeto, verificando periodicamente qual seu status em determinadomomento, buscando melhorias para chegar à meta desejada.

C M



Coleta de métricas (CMe) - continuação

} Algumas atividades deste processo são: Definição de quais métricas devem ser coletadas e as metas para

cada uma delas no projeto;

Definição de um cronograma para a coleta das mesmas para

determinado projeto de software; coleta delas de acordo com o procedimento documentado sobre

quais quando devem ser coletadas;

análise das métricas coletadas e identificação da(s) causa(s) casoalguma tenha ficado fora da faixa de tolerância da meta;

caso alguma tenha ficado fora da meta é necessário desenvolver um plano de ação para que as métricas voltem a ficar dentro da

meta determinada.


C Me

IS



} Uma das principais funções feitas por este passo é a geração de releases de

software. Para isso é necessário ter um plano de release que contenha asfuncionalidades a serem colocadas em cada release, os componentes agrupados(hardware, software , documentação, etc) e o mapeamento entre os requisitos docliente e os satisfeitos em um release separado do produto.

} Também é necessário integrar o software caso haja linhas de desenvolvimentoparalelas, para poder gerar uma única versão com todas as alterações realizadas.

} Neste passo da gerência há dois processos:

Integração do software (IS);

Pacote de release (PR).

Gerência de liberação e distribuição

Integração do software (IS)} Este processo é feito seguindo um procedimento documentado, para permitir o

desenvolvimento paralelo do software e reunir todas as linhas de desenvolvimento

paralelas em uma única versão, que ficará composta de todas as solicitações demudanças para determinado release.

} Por isso suas atividades são: identificação das linhas que farão parte da release;verificação para saber se todas as alterações feitas no software seguiram assolicitações de mudanças aprovadas e validada; verificação para saber se todas assolicitações de mudanças aprovadas foram realmente resolvidas; e então integraçãodas linhas de desenvolvimento.

IS

PR



Gerência de liberação e distribuiçãoPacote de release (PR)

} Este processo serve para gerar os componentes que fazem parte dopacote de entrega, a partir de uma baseline válida, para então poder entregar ao cliente.

} Logo suas atividades são: Geração de componentes a partir de baselines

válidas; agrupar todos os itens de configuração que fazem parte do pacotesegundo procedimento documentado; montar o pacote de release; efinalmente, entregar o pacote ao cliente.

PR



Controle de Subcontratados e fornecedores} Esta parte não está descrita na norma ISO 12207, mas é importante pois

se refere às atividades de controle de subcontratados e fornecedorescoordenam a forma como os itens que foram desenvolvidos por solicitação a outras empresas ou foram adquiridos já prontos sãotestados e incorporados ao repositório do projeto.

} Caso os itens sejam subcontratados, deve-se descrever os requisitos degerenciamento de configuração de software a serem satisfeitos pelosubcontratado; como será feito o monitoramento sobre osubcontratado; como o código, documentação e dados externos serãotestados, aceitos e adicionados ao projeto; como serão tratadas asquestões de propriedade do código produzido como direitos autorais ede propriedade (licenças).

} Caso os itens sejam adquiridos prontos, deve-se descrever como elesserão recebidos, testados e colocados sob controle de gerenciamentode configuração; como as mudanças no software do fornecedor serãotratadas; se e como o fornecedor participará no processo degerenciamento de mudança do projeto.



Algumas desvantagens

} Seu custo é muito alto, geralmente quem implanta sãoempresas de médio e grande porte.

} Mas sua implantação não é fácil, pois: Há uma grande diversidade de normas, padrões e

modelos; Não há um mesmo padrão na definição das atividades;



Por que ela é importante...} Ela se faz necessária de diversas formas, ela e

importante em todo projeto compartilhado dedesenvolvimento de software, quanto maior este for mais organizada e bem feita ela deve ser.



Importância...

} Em toda as fases do ciclo de vida, mas principalmente,na de definição de requisitos, desenvolvimento emanutenção podem surgir alterações, mudançasgrandes ou pequenas relevantes ou não muito.

} Mas se elas não forem organizadas de alguma forma, oprojeto poderá ficar fora de controle e tenderá ao caos,implicando em perda de produtividade, tempo,retrabalho desnecessário, demora na entrega do

produto final etc.



Empresas conhecidas que possuem

esta fase em seus projetos



Referências} http://www.univasf.edu.br /~ricardo.aramos/disciplinas/ESI2009_2/Aula018_Ger ConfigSof

tware.pdf

} http://www.spinsp.org.br /apresentacao/CM _ASR.pdf

} http://webcache.googleusercontent.com/search?q=cache:http://143.106.50.145:8080/Cursos/EA976/02-08/EA976-CM.pdf

} http://www.cin.ufpe.br /~gfn/qualidade/gc.html

} http://www.cin.ufpe.br /~gfn/qualidade/cgferramentas.html

} http://www.google.com.br /url?sa=t&rct=j&q=como+configurar+o+cvs+no+eclipse&sour ce=web&cd=3&ved=0CDgQFjAC&url=http%3A%2F%2Fwww.documentador.pr.gov.br%2Fdocumentador%2Fpub.do%3Faction%3Dd%26uuid%3D%40gtf-escriba%40539b3f8c-c2bc-48ae-a9d1-43f4de13e36b&ei=ur1CT7fLN8aOgwfM6-yMCA&usg=AFQjCNGEqYZ4_2pnLVapjgfCecTpSqNGIQ&sig2=jDbTfHldsIR3k95Xwu_ ImQ

} http://ccsl.ime.usp.br /wiki/images/8/8a/Repositorios.pdf

} http://reuse.cos.ufrj.br /prometeus/publicacoes/odyssey-scm.pdf

} http://www.teses.usp.br /teses/disponiveis/55/55134/tde-24082006-163201/pt-br.php

Documents

Gerência de configuração