TCC - V8 18122012
58
UNIVERSIDADE TIRADENTES SISTEMAS DE INFORMAÇÃO BRUNO IGOR FRANÇA DIAS UTILIZANDO O TEAM FOUNDATION SERVER PARA APOIO À GERÊNCIA DE CONFIGURAÇÃO
-
Upload
brunoigordias -
Category
Documents
-
view
68 -
download
2
Transcript of TCC - V8 18122012
UNIVERSIDADE TIRADENTES
SISTEMAS DE INFORMAÇÃO
BRUNO IGOR FRANÇA DIAS
UTILIZANDO O TEAM FOUNDATION SERVER PARA APOIO
À GERÊNCIA DE CONFIGURAÇÃO
Aracaju
2012
BRUNO IGOR FRANÇA DIAS
UTILIZANDO O TEAM FOUNDATION SERVER PARA
APOIO À GERÊNCIA DE CONFIGURAÇÃO
Aracaju
2012
Monografia apresentada à Universidade Tiradentes como requisito parcial do título de bacharel em Sistemas de Informação
Me. THIERS SOUSA
Bruno Igor França Dias
UTILIZANDO O TEAM FOUNDATION SERVER PARA APOIO
À GERÊNCIA DE CONFIGURAÇÃO
Aprovado em dezessete de dezembro de 2012
BANCA EXAMINADORA
_____________________________________________
Thiers Garretti Ramos Sousa – Universidade Tiradentes
_____________________________________________
Vana Hilma Veloso Carvalho – Universidade Tiradentes
_____________________________________________
Gilson Pereira dos Santos Junior – Universidade Tiradentes
Monografia apresentada à Universidade Tiradentes como requisito parcial do título de bacharel em Sistemas de Informação
RESUMO
Realizar mudanças durante o desenvolvimento de softwares é inevitável, o
meio em que o software é produzido é dinâmico, seus fatores influenciadores estão
em constante evolução e quando há mudança no ambiente, nos requisitos ou nas
necessidades se fazem necessárias alterações e para que elas não se tornem um
problema é necessária alguma forma de gerenciamento [Molinari, 2007]. Surge
então a necessidade de controlar estas modificações, por meio de ferramentas e
métodos para maximizar a produtividade e minimizar os erros cometidos durante a
evolução do desenvolvimento dos softwares. A Gerência de Configuração de
Software é uma disciplina que controla as mudanças que aconteceram no sistema,
permitindo responder por que estas mudanças ocorreram e se o sistema continua
íntegro depois destas mudanças e ainda identificar em certo momento qual era a
configuração do software com a finalidade de controlar as mudanças e manter a
rastreabilidade do ciclo de vida do sistema. Para auxiliar o gerenciamento destas
configurações criaram-se ferramentas de apoio que controlam as mudanças durante
o ciclo de vida do projeto. O Team Foundation Server (TFS) é uma plataforma de
colaboração de projetos de software que integra pessoas, processos e tecnologias
dando apoio à gestão, qualidade e integridade ao ciclo de vida do software. Este
trabalho realizará um estudo prático de como o TFS trabalha de forma integrada à
gerência de configuração.
PALAVRAS CHAVE: TFS, MPS.BR, GCS, Gerência de Configuração
ABSTRACT
Making changes during software development is inevitable, the way in which
software is produced is dynamic, its influencing factors are constantly evolving and
when there is change in the environment, the requirements or the needs and
changes are needed so that they do not become a problem is somehow necessary
management [Molinari, 2007]. Then comes the need to monitor these changes, using
tools and methods to maximize productivity and minimize errors committed during
the evolution of software development. The Software Configuration Management is a
discipline that controls the changes that occurred in the system, allowing to answer
why these changes occurred and whether the system remains intact after these
changes and identify which at one point was the configuration software for the
purpose of controlling changes and keep track of the life cycle of the system. To help
manage these settings were created support tools that control changes during the life
cycle of the project. Team Foundation Server (TFS) is a platform for project
collaboration software that integrates people, processes and technologies supporting
the management, quality and integrity of the software lifecycle. This work will carry
out a practical study of how TFS works seamlessly with configuration management.
KEYWORDS: TFS, MPS.BR, GCS, Configuration
LISTA DE ILUSTRAÇÕES
Figura 1 - Modelo de Referência para Melhoria do Processo de Software (MR MPS) - 11
Figura 2 - Fluxo do processo de avaliação (SOFTEX, 2005) - 13
Figura 3 - Criação de uma tarefa - 25
Figura 4 - Operação de Check In - 26
Figura 5 - Associação de um Check In a uma tarefa - 26
Figura 6 - Relacionamento de uma tarefa com os itens modificados/adicionados - 27
Figura 7 - Exemplo de aplicação com versões definidas - 29
Figura 8 - Criação de uma Baseline - 30
Figura 9 - Criação de uma baseline parcial - 31
Figura 10 - Descrição de uma baseline parcial - 32
Figura 11 - Processo de bloqueio de uma baseline - 33
Figura 12 - Acesso físico das baselines – 34
Figura 13 - Criação de um Registro de Mudança no TFS - 35
Figura 14 - Análise de registro de um evento - 36
Figura 15 - Estado de um registro de mudança - 36
Figura 16 - Criação de um novo item de configuração (Requirement) - 37
Figura 17 - Associação de um pedido de mudança a um novo IC. - 38
Figura 18 - Fechamento de um pedido de mudança - 38
Figura 19 - Fechamento de um registro de evento - 39
LISTA DE ABREVIATURAS E SIGLAS
IC – Item de Configuração
CMMI - Capability Maturity Model Integration
GCC - Comitê de Controle de Configuração
GCS – Gerência de Configuração de Software
MA-MPS – Método de Avaliação do MPS.BR
MN-MPS – Modelo de Negócios do MPS.BR
MPS.BR – Modelo de Melhoria do Processo de Software Brasileiro
MR-MPS – Modelo de Referência do MPS.BR
PGS – Plano de Gerência de Configuração
SPICE - Simulated Program with Integrated Circuits Emphasis
TFS – Team Foundation Server
SUMÁRIO
1 INTRODUÇÃO....................................................................................................10
2 MODELO DE MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO (MPS.BR)...................................................................................................................11
2.1 Modelo de Referência...................................................................................12
2.2 Método de Avaliação....................................................................................13
2.3 Modelo de Negócio.......................................................................................15
2.4 O Nível F do MPS.BR...................................................................................16
3 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE.........................................17
3.1 Metadados....................................................................................................18
3.2 Item de Configuração...................................................................................18
3.3 Identificação..................................................................................................18
3.4 Armazenamento...........................................................................................19
3.5 Controle de Versão.......................................................................................19
3.6 Baseline........................................................................................................20
3.7 Plano de Gerência de Configuração.............................................................20
4 OBJETIVOS DA GERÊNCIA DE CONFIGURAÇÃO NO MPS.BR.....................21
4.1 Requisito 1: Um Sistema de Gerência de Configuração é estabelecido e mantido..................................................................................................................21
4.2 Requisito 2: Os itens de configuração são identificados com base em critérios estabelecidos............................................................................................21
4.3 Requisito 3: Os itens de configuração sujeitos a um controle formal estão colocados sob baseline..........................................................................................23
4.4 Requisito 4: A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada.....................................................23
4.5 Requisito 5: Modificações em itens de configuração são controladas (Controle de Mudanças).........................................................................................23
4.6 Requisito 6: O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados.............................................................24
4.7 Requisito 7: Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes.......................................................................................25
5 APLICAÇÃO DE EXEMPLO...............................................................................26
5.1 Requisito 1: Um Sistema de Gerência de Configuração é estabelecido e mantido..................................................................................................................26
5.2 Requisito 2: Os itens de configuração são identificados com base em critérios estabelecidos............................................................................................27
5.3 Requisito 3: Os itens de configuração sujeitos a um controle formal são colocados sob baseline..........................................................................................29
5.4 Requisito 4: A situação dos itens de configuração e das baselines é registrada ao longo do tempo e disponibilizada.....................................................34
5.5 Requisito 5: Modificações em itens de configuração são controladas.........34
5.5.1 1º Requisito: Criação de um registro de evento - o registro é criado e descrito em detalhes...........................................................................................34
5.5.2 2º Requisito: Análise de registro de um evento - é preciso avaliar o impacto da mudança em todos os itens correlacionados...................................35
5.5.3 3º Requisito: Rejeição ou aceitação de registro de mudança de um evento - Se um registro é aceito deve ser criado um pedido de mudança para cada item afetado...............................................................................................36
5.5.4 4º Requisito: Pedido de mudança inicia um novo item de configuração - Um novo item de configuração é estabelecido, criado e uma mudança é implementada.....................................................................................................37
5.5.5 5º Requisito: Fechamento de um pedido de mudança: o pedido de mudança deve ser fechado quando estiver implementado e aceito...................38
5.5.6 6º Requisito: Fechamento de um registro de evento: o registro de evento pode ser fechado quando todos os pedidos de mudanças relacionados à ele forem fechados...................................................................................................38
5.6 Requisito 6: O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados.............................................................39
5.7 Auditorias de configuração são realizadas objetivamente para assegurar que as baselines e os itens de configuração estejam íntegros, completos e consistentes...........................................................................................................39
6 CONCLUSÃO.....................................................................................................40
7 REFERÊNCIAS..................................................................................................41
1 INTRODUÇÃO
Atingir os objetivos e satisfazer as necessidades e expectativas do cliente
torna uma empresa competitiva no mercado. Alcançar competitividade pela
qualidade implica em melhoria de qualidade dos produtos de software, em serviços
correlatos, processos de produção e distribuição de software (Softex, 2005).
Em 2004, o Projeto MPS.BR foi desenvolvido com recursos próprios das
seguintes instituições-âncora, integrantes do Comitê Gestor MPS: SOFTEX
(coordenadora do projeto), COPPE/UFRJ (coordenadora da ETM – Equipe Técnica
do Modelo) e RIOSOFT no Rio de Janeiro/RJ, CenPRA e Agente SOFTEX em
Campinas/SP, CESAR em Recife/PE e CELEPAR em Curitiba/PR em Curitiba/PR.
(Softex 2005).
Segundo MOLINARI (2007), “Não importa se a mudança é grande ou
pequena, esta sempre causará um impacto em uma ou mais “coisas”, seja de forma
direta ou indireta. Saber delimitar o escopo ou as fronteiras da mudança é
fundamental para que se possa gerenciar de forma eficiente e eficaz a mudança em
si”.
O TFS é um servidor de colaboração de projetos de desenvolvimento que
será utilizado para satisfazer parcialmente os requisitos do nível F do MPS.BR onde
está definida a Gerência de Configuração.
Segundo PRESSMAN (2001), uma boa alternativa para ajudar na solução do
problema da integração é a utilização de uma estrutura em que o principal
mecanismo de integração de ferramentas é a Gerência de Configuração de Software
(GCS).
10
2 MODELO DE MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO
(MPS.BR)
Pesquisas realizadas periodicamente sobre a qualidade de software mostram
que é necessário mais empenho para melhorar os processos de software no Brasil.
A partir 1993, com a criação do PBQP (Subcomitê de Software do Programa
Brasileiro da Qualidade e Produtividade), o Brasil iniciou o investimento em melhoria
da Qualidade de Software (Weber, 1995). No entanto, um estudo comparativo do
MIT (Massachussetts Institute of Technology) constatou que houve realmente
interesse na melhoria de processos de software no Brasil nos últimos anos, mas que
a empresa local favoreceu a ISO 9000 (ISO, 2000) em detrimento de outros modelos
e padrões voltados especificamente para software.
O MPS.BR é um modelo que é desenvolvido desde dezembro de 2003 por
uma iniciativa que envolve grupos de pesquisas, universidades, governo e empresas
que estão sob a coordenação da sociedade SOFTEX (Sociedade para Promoção da
Excelência do Software Brasileiro) em alternativa ao modelo CMMI – Compability
Maturity Model Integration.
O projeto MPS.BR visa qualificar o maior grupo de empresas possível,
seguindo padrões de qualidade que são aceitos internacionalmente pela
comunidade de software, a custos acessíveis para as empresas brasileiras
(MCT,2012, SOFTEX,2012). Faz parte dos seus objetivos definir e aprimorar um
modelo de melhoria e avaliação de processo de software, objetivando as micro,
pequenas e médias empresas brasileira.
O MPS.BR orienta-se nos conceitos de maturidade e capacidade de processo
para a avaliação e melhoria da qualidade e produtividade dos produtos de software.
Neste contexto, o MPS.BR possui três componentes: Modelo de Referência (MR-
MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS)
(SOFTEX,2012).
11
2.1 Modelo de Referência
O Modelo de Referência do Modelo de Melhoria do Processo de Software
inclui níveis de maturidade e um método de avaliação (Figura 1).
A norma correspondente para os processos de ciclo de vida de software do
Modelo de Referência do MPS.BR é a ISSO/IEC 12207. Esta norma contém de
forma transparente a definição da arquitetura, terminologia e responsabilidades
ligadas aos processos (SOFTEX, 2004). Desta forma ela ajuda as organizações à
definirem seus processos, permitindo que a implementação do MPS.BR possa ter
soluções distintas dependendo das características, necessidades e desejo das
organizações.
“Um modelo, que compreende definições de processos no ciclo de vida, descrito em
termos de propósitos e resultados, junto com uma arquitetura que descreve as
relações entre os processos [ISO/IEC, 2004a].”
O modelo é definido por níveis de maturidade, que são sequenciais e
acumulativos. Cada nível de maturidade é composto por um conjunto de processos
12
Figura 1 – Modelo de Referência para Melhoria do Processo de Software (SOFTEX, 2004)
em um determinado nível de capacidade. Estes níveis determinam a evolução,
caracterizando estágio de melhoria da implementação de processos na organização.
Os níveis de maturidade do MPS.BR são:
Nível A – Em Otimização (mais maduro);
Nível B – Gerenciado Quantitativamente;
Nível C – Definido;
Nível D – Largamente Definido;
Nível E – Parcialmente Definido;
Nível F – Gerenciado;
Nível G – Parcialmente Gerenciado (inicial).
Os níveis de maturidade do MPS.BR seguem uma característica similar à dos
quatro níveis de maturidade dos estágios do CMMI (níveis 2 a 5), sendo que os
níveis F, C, B e A do MPS.BR correspondentes respectivamente aos níveis 2, 3, 4 e
5 do CMMI. O nível G é um intermediário entre os níveis 1 e 2, os níveis E e D são
intermediários entres os níveis 2 e 3.
Esta divisão tem por objetivo facilitar sua implantação às pequenas e médias
empresas visando resultados em curto prazo (SOFTEX, 2012). A correspondência
entre os níveis do MPS.BR e o CMMI permite que o mesmo trabalho para a melhoria
do processo possa ser reconhecido pelos dois modelos, utilizando avaliações
específicas.
2.2 Método de Avaliação
O Guia de Avaliação relata o Método de Avaliação para Melhoria de Processo
de Software (MA-MPS), sendo formado pelos requisitos do método, atividades do
método, indicadores para avaliação e características da qualificação dos
avaliadores, permitindo a execução de avaliações em unidades organizacionais
segundo o MPS.BR.
13
“Os requisitos do MA-MPS são baseados nos requisitos do método de avaliação
definidos na norma ISSO/IEC 15504-2, os requisitos definidos no ARC do CMMI e
os requisitos específicos do Projeto MPS.BR (SOFTEX, 2005).”
As atividades do MA-MPS são baseadas principalmente no método Standard
CMMI Appraisal Method for Process Improvement (SCAMPI) (SEI,2001). O SCAMPI
é o método de avaliação modelo para criar classificação semelhante para as
representações por estágio e contínua do CMMI.
O processo de avaliação é constituído por quatro fases: preparação e planejamento;
condução da avaliação; resultados; certificação.
A Figura 2 mostra o fluxo destas fases, os principais produtos de entrada e saída
e o mapeamento das fases não atividades requeridas pela ISSO/IEC 15504 e nas
fases do SCAMPI.
14
2.3 Modelo de Negócio
O Modelo de Negócio do MPS.BR define as regras de negócio para
(SOFTEX, 2010): A implementação do Modelo de Referência do MPS.BR pelas
Instituições Implementadoras (II); A avaliação de acordo com o Método de Avaliação
do MPS.BR pelas Instituições Avaliadoras (IA);Organização de grupos de empresas
para a implementação dos modelos de referência e avaliação do MPS.BR pelas
Instituições Organizadoras de Grupos de Empresas (IOGE);Habilitação de
Consultores de Aquisição (CA) de software e serviços correspondentes e
credenciamento de Instituições de Consultoria de Aquisição (ICA);Realização de
cursos, provas oficiais e workshops anuis do MPS, para treinamento de pessoas do
Modelo MPS; Curso de Pós-Graduação em Engenharia e Qualidade de Software
com o modelo MPS.
2.4 O Nível F do MPS.BR
O nível F está combinado com os processos do nível precedente (G)
acrescentado pelos processos de Aquisição, Garantia de Qualidade, Gerência de
Configuração, Gerência de Portfólio de Projetos e Medição.
O principal foco do nível F é agregar processos de apoio à gestão do
projeto no que diz respeito à Garantia da Qualidade (GQA) e
Medição (MED), bem como aquele referente à organização dos
artefatos de trabalho por meio da Gerência de Configuração
(SOFTEX, 2011)
15
3 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
A Gerência de Configuração de Software (GCS) é o:
“(...) conjunto de atividades projetadas para controlar as mudanças pela identificação
dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles,
definindo o mecanismo para o gerenciamento de diferentes versões destes produtos,
controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.
(PRESSMAN, 2001)”
A GCS é muito útil e importante, por isso faz partes de modelos de
maturidade como o CMMI, SPICE e MPS.BR. O seu papel no MPS.BR, é sobretudo,
de suporte e apoio a processos e normas (MOLINARI, 2007).
“O propósito do processo de Gerência de Configuração é estabelecer e manter a
integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a
todos os envolvidos (MPS.BR, 2012)”
O MPS.BR espera resultados de seus processos, para a GCS estes resultados são:
1. Os itens de configuração são identificados
2. Os itens de configuração gerados pelo projeto são definidos e colocados sob
uma linha base.
3. É estabelecido e mantido um Sistema de Gerência de Configuração.
4. As modificações e liberações dos itens de configuração são controladas.
5. As modificações e liberações são disponibilizadas para todos os envolvidos.
6. A situação dos itens de configuração e as solicitações de mudanças são
registradas, relatadas e o seu impacto é analisado.
7. A completeza e a consistência dos itens de configuração são asseguradas.
8. O armazenamento, manuseio e entrega dos produtos de trabalho são
controlados.
9. A integridade das linhas-base (baselines) é estabelecida e mantida através de
auditoria da configuração e de registros da Gerência de Configuração.
16
3.1 Metadados
As informações relativas ao item de configuração são chamadas de
metadados, tais como: a data de criação, a data de entrada em produção, quem
criou e o mais importante, o relacionamento com outros itens de configuração.
3.2 Item de Configuração
Podemos definir item de configuração (IC) como o menor item de controle
num processe de GCS, podendo ser qualquer coisa, desde um executável, um
arquivo, um documento ou até mesmo uma parte deste.
Ainda segundo Pressman:
“Cada um dos elementos de informação que são criados durante o desenvolvimento
de um produto de software, ou que para este desenvolvimento sejam necessários, que são
identificados de maneira única e cuja evolução é passível de rastreamento” (Pressman,2001)
No decorrer do desenvolvimento do software o IC sofre várias modificações,
um “ciclo” que se repete e a cada ciclo o IC será identificado, produzido,
armazenado e liberado para uso, este é o seu “ciclo de vida”.
“O fato é que cada nova versão é diferente da anterior. Isto faz com que, se tivermos
a necessidade de “voltar” à versão anterior de um item, podemos fazê-lo de forma clara
utilizando o GCS.” (Molinari, 2007).
3.3 Identificação
O objetivo da identificação é determinar que um IC qualquer possa ser
identificado e especificado dentre vários outros IC. As atividades da identificação são
descritas a seguir:
Entradas (inputs): O primeiro momento sobre o qual o IC é posto sobre o
GCS; Quando há a necessidade de mudança, onde um pedido de mudança – mais
conhecido como change request – é feito;
Saídas (outputs): A identificação do IC resulta no registro do metadado
junto à GCS.
17
3.4 Armazenamento
A finalidade do armazenamento é garantir que um IC não irá “desaparecer” ou
será danificado, de forma que possa ser localizado a qualquer momento e seja
entregue no estado em que se espera encontrar.
Armazenamento é algo físico (Molinari, 2007), os itens que são armazenados
estão fisicamente presentes em algum local. Este local pode ser chamado de
“biblioteca” – comumente chamada de library.
As bibliotecas podem ser:
Controladas: Os IC estão armazenados de forma controlada, atendendo a
alguma característica ou funcionalidade envolvida, podendo estar divididos em
várias bibliotecas, principalmente quando existem diferentes tipos de IC para serem
armazenados. (Ex.: documentos, códigos-fonte, etc.).
Dinâmicas: Também conhecidas como bibliotecas de desenvolvimento, pois
são nelas onde os IC são armazenados enquanto são produzidos, geralmente ficam
sobre responsabilidade do gerente de desenvolvimento e são gerenciadas por algum
software de gerência de configuração servindo de backup para quem está
produzindo algo para “entregar”.
Estáticas: Conhecida também como “biblioteca do usuário”. Contém
integralmente os IC independentemente de estar ou não sobre controle do usuário
final. Quando esta contém código-fonte, em geral é acompanhada por uma
biblioteca dinâmica. Esta biblioteca não faz parte da GCS e poder estar sobre os
cuidados de um desenvolvedor, gerente de teste ou mesmo o cliente.
3.5 Controle de Versão
O controle de versão permite que IC sejam armazenados, controlados e
restaurados. Ele é extremamente útil quando várias pessoas trabalham em um
mesmo projeto.
As principais vantagens são descritas a seguir:
18
Trabalho em equipe: permite o gerenciamento de acesso para usuários e
grupos de usuários e ainda que várias pessoas trabalhem no mesmo projeto
sem que isso cause conflitos em suas modificações.
Controle de histórico: permite o controle de alterações em cada item como
quem alterou, o que foi alterado e quando foi realizado, dando a possibilidade
de que uma versão anterior possa voltar a ser a atual no caso de uma
modificação mal sucedida.
3.6 Baseline
Os conceitos de controle de versão e baseline são facilmente confundidos
entre as organizações. Uma baseline segundo (Molinari, 2007) é um conjunto de um
ou mais itens de configuração identificados e liberados para uso independente de
suas versões. Representa a demarcação do estado do projeto antes e depois de sua
geração, registrando o estado de toda a aplicação. Portanto, controle de versão
refere-se a um IC e uma baseline ao conjunto de IC que são liberados para uma
publicação.
3.7 Plano de Gerência de Configuração
O Plano de Gerencia de Configuração (PGC) é um documento que descreve
todas as atividades da GCS que serão executadas durante o ciclo de vida do projeto
(Molinari, 2007). Neste documento deve estar definido as responsabilidades
atribuídas a cada membro da equipe, quais recursos serão necessários – equipes,
infraestrutura, ferramentas - e as atividades a serem executadas e o seu
cronograma.
Um dos itens do PGC define as convenções de termos e abreviações que
serão utilizadas, muito importante na criação da nomenclatura das baselines e dos
IC.
19
4 OBJETIVOS DA GERÊNCIA DE CONFIGURAÇÃO NO MPS.BR
4.1 Requisito 1: Um Sistema de Gerência de Configuração é estabelecido e
mantido.
Para atender este requisito deve ser implementado um sistema de GC para
apoiar todo o projeto e o seu ciclo de vida de desenvolvimento e manutenção,
referente tanto ao controle de versões e modificações quanto ao gerenciamento de
todos os IC (RENAPI, 2009).
A fim de obter este requisito deve-se fazer
1. Preparar um plano de gerência de configuração
2. Estabelecer um Comitê de Controle de Configuração (CCC)
3. Estabelecer um Sistema de Controle de Versões
4. Estabelecer um Sistema de Controle de Modificações, integrado ao sistema
de controle de versões
5. Estabelecer um Sistema de Gerenciamento de Construção
Para o escopo deste trabalho somente será tratado os itens 3, 4 e 5.
4.2 Requisito 2: Os itens de configuração são identificados com base em critérios
estabelecidos.
Este requisito trata da gerência da empresa perante ao requisitos dos clientes
e não do software em si. É de competência da empresa identificar quais IC
passaram pelo versionamento e que serão mantidos pelo sistema de GC, para tanto
alguns critérios são sugeridos (RENAPI, 2009):
Verificar:
Se a requisição é crítica para o projeto
20
Se existe a dependência entre itens
O impacto que a modificação em um item tem no produto
Se é frequentemente alterado devido a sua complexidade
Como boa prática, é importante também que seja estabelecido:
Regra de nomes para a formação dos itens
Regra de versionamento
Definição de atributos: responsável, descrição, data de criação, etc. (Estas
formalidades devem estar descritas no plano de gerência de configuração)
Ainda como sugestão (RENAPI, 2009) os IC devem conter:
Escopo da proposta técnica
Especificação da arquitetura
Requisitos
Modelos
Casos de Usos
Documentos técnicos
Matrizes de rastreabilidade
Notas de entrega
Casos de testes
Resultados dos testes
Código-fonte
Executáveis
21
4.3 Requisito 3: Os itens de configuração sujeitos a um controle formal estão
colocados sob baseline.
A baseline deverá ser criada de acordo com à conclusão dos ciclos do projeto
ou em determinadas fases definidas do seu plano. Este processo só deve ser
realizado após os procedimentos de consistência interna, verificação e validação
serem aprovados. Ao ser criada, ela incorpora integralmente a anterior, desta forma
a última baseline criada representa o estado atual do projeto (Macorati, 2007).
4.4 Requisito 4: A situação dos itens de configuração e das baselines é registrada
ao longo do tempo e disponibilizada
O acesso às baselines criadas anteriormente deve ser permitido, assim,
quando for necessário voltar a uma versão anterior do software sabe-se onde
encontrar os fontes. Deve-se definir um local para o armazenamento destas
baselines e realizar o controle do status de cada uma delas.
No capítulo 5 será tratado como o TFS realiza as operações definidas nos
requisitos 3 e 4.
4.5 Requisito 5: Modificações em itens de configuração são controladas (Controle
de Mudanças)
Realizar mudanças durante o desenvolvimento de aplicações é algo comum
em TI, elas sempre aparecem e de alguma forma causam um impacto no que antes
era considerado pronto.
“Não importa de a mudança é grande ou pequena, esta sempre causará um impacto
em uma ou mais “coisas”, seja de forma direta ou indireta. Saber delimitar o escopo ou as
fronteiras da mudança é fundamental para que se possa gerenciar de forma eficiente e eficaz
a mudança em si. (Molinari, 2007)”.
Segundo Molinari (2007, p.51): “Mudar é uma constante: pessoas cometem
erros, clientes necessitam de mudanças no produto para seu uso e o próprio
ambiente no qual está inserido o produto precisa de algum ajuste. É comum dizer
22
que uma nova solução trará no futuro novos problemas, que por sua vez, trarão
novas mudanças”.
É necessário que as mudanças que ocorram sejam supervisionadas para que
no futuro - caso estas alterações necessitem de novas intervenções assim gerando
novas mudanças – possam ser controladas e rastreadas.
Para Molinari (2007, p.51), o propósito do Controle de Mudanças é que: “Para
cada item de configuração será necessário saber quem, quando, por que e o que
mudou, de modo que se possa ter uma rastreabilidade completa entre cada versão
modificada ou criada, da antecessora à predecessora”.
As principais atividades no controle de mudanças são:
Criação de um registro de evento
Análise de registro de um evento
Rejeição ou aceitação de registro de mudança de um evento
Pedido de mudança inicia um novo item de configuração
Fechamento de um pedido de mudança
Fechamento de um registro de evento
Uma requisição de mudança não deve ser imposta, deve haver uma avaliação
da sua justificativa e do impacto que causará na aplicação. Esses procedimentos
devem ser catalogados para que exista a rastreabilidade.
4.6 Requisito 6: O armazenamento, o manuseio e a liberação de itens de
configuração e baselines são controlados.
Este requisito tem por objetivo manter os envolvidos no projeto cientes das
alterações ocorridas nos IC. Portanto, as informações de quem modificou um certo
item, quem está modificando, quando ocorreu uma alteração, quais itens serão
afetados por uma alteração, porque de uma alteração ser necessária, entre outras
coisas, devem ser mantidas e estar disponível para consulta (FIGUEIREDO, 2004).
23
4.7 Requisito 7: Auditorias de configuração são realizadas objetivamente para
assegurar que as baselines e os itens de configuração estejam íntegros,
completos e consistentes.
O objetivo deste requisito é certificar que o produto está integro, assegurando
que as alterações tenham sido implementadas corretamente. Estas auditorias
devem ser executadas utilizando processos bem definidos – junto ao PGC – e
documentados.
Existem dois tipos de avaliação que podem serem feitas: física e funcional.
Avaliação Física: Consiste em verificar se a baseline a ser criada é composta
da versão mais recente dos IC.
Avaliação Funcional: Compreende a avaliação de desempenho e requisitos
funcionais do IC.
24
5 APLICAÇÃO DE EXEMPLO
Este capitulo destina-se a mostrar como o TFS cumpre os requisitos da
Gerência de Configuração no MPS.BR. Os itens que não correspondem ao controle
formal do software não serão tratados.
5.1 Requisito 1: Um Sistema de Gerência de Configuração é estabelecido e
mantido
Processos:
Preparar um Plano de Gerência de Configuração: O cumprimento deste item
refere-se a criação de um plano onde é descrito todas as atividades do
Gerenciamento de Controle de Configuração e Mudanças, este item está fora do
escopo deste trabalho.
Estabelecer um Comitê de Controle de Configuração (GCC): O GCC é um
grupo de pessoas que são responsáveis pela avaliação e posteriormente aprovação
ou reprovação das alterações propostas para os itens de configuração (Controle de
Mudanças).
Estabelecer um Sistema de Controle de Versões: Este processo refere-se a
implantação de um software capaz de gerenciar o controle de versões dos IC. Este
software deverá armazenar os itens produzidos durante o desenvolvimento do
software, permitir o acesso controlado de qualquer versão do IC e armazenar
histórico de modificações.
Estabelecer um Sistema de Controle de Modificações, integrado ao sistema
de Controle de Versões: É necessário que exista um software capaz de controlar as
modificações feitas no software no que diz respeito aos detalhes das solicitações de
mudanças, o impacto causado por uma mudança, os itens associados, dentre
outros.
Estabelecer um Sistema de Gerenciamento de Construção (Baselines): Deve
ser implantado um sistema capaz de criar e gerenciar as baselines do projeto.
25
5.2 Requisito 2: Os itens de configuração são identificados com base em critérios
estabelecidos.
Neste passo será mostrado a associação de uma Task (Tarefa) com o código
fonte da aplicação, que é extremamente importante para que posteriormente através
de uma baseline seja identificado quais itens a compõe e a que tarefas estão
relacionado.
A figura 3 mostra a criação de uma tarefa, onde deve conter todas as
informações que estão relacionadas no requisito 2.
Figura 3 – Criação de uma tarefa
Ao realizar um Check In (operação de salvar um ou mais itens no repositório)
o usuário deve informar uma breve descrição do que foi realizado e associar a
operação a uma tarefa.
A figura 4 mostra quais itens que foram modificados/adicionados e o local
ondem estão armazenados.
26
Figura 4 – Operação de Check In
Após selecionar os itens pertinentes a operação, deve-se associa-los com a
tarefa correspondente, processo que pode ser visualizado na figura 5.
Figura 5 – Associação de um Check In a uma tarefa
27
Com esses passos realizados é possível identificar quais itens estão
relacionados a uma tarefa e através do seu Changeset poderá facilmente ser
identificado nas futuras baselines criadas durante o ciclo de vida do projeto.
Figura 6 – Relacionamento de uma tarefa com os itens modificados/adicionados
5.3 Requisito 3: Os itens de configuração sujeitos a um controle formal são
colocados sob baseline
Para atender este requisito devem ser criadas baselines a cada ciclo do projeto
ou quando em fases determinadas no seu plano. Quando uma baseline é criada ela
deve estar em um caminho físico acessível às pessoas que são encarregadas de
gerencia-la. O TFS chama a criação de uma baseline de Branch, que nada mais é
que uma cópia dos fontes de um projeto em seu estado atual. Ao ser criada deve se
levar em conta a padronização da nomenclatura – que deve estar definido no PGC –
e o local onde será armazenada, este último é muito importante, já que se o local
escolhido não for seguro e protegido do acesso de pessoas não autorizadas todo o
projeto corre o risco de ser perdido.
28
Nos próximos passos será mostrado como o TFS cria uma Branch e como
podemos gerenciá-las durante o ciclo de vida do projeto.
A figura 7 mostra um projeto com algumas baselines criadas, sua
nomenclatura está definida da seguinte forma:
O prefixo V é definido como caractere inicial
Posteriormente temos três campos numéricos separados por ponto (Exemplo:
V0.0.1). A cada versão criada o numeral deve ser acrescido em uma unidade,
versões que possuem poucas modificações ou apenas correções de erros
devem alterar o decimal à direita, quando incluídas muitas modificações o
numeral do meio deve ser alterado e por fim, quando uma versão possui
muitas modificações – algo entre 30% da aplicação – dever ser alteado o
numeral à esquerda.
Note que a nomenclatura adotada para este exemplo é única e
exclusivamente para demonstrar o projeto de exemplo, cada empresa deve
definir a nomenclatura a ser adotada de acordo com suas necessidades e
padrões.
Figura 7 – Exemplo de aplicação com versões definidas
A figura 8 mostra o processo de criação de uma baseline, o campo By indica
quais itens deve ser adicionados, neste caso para não ferir o conceito de baseline
29
que diz que sempre deve ser criada com a última versão do software e incluindo as
anteriores escolhemos a opção Latest Version (Última Versão).
Um ponto importante a ser lembrado é que antes de ser gerada deve-se
tomar o cuidado de verificar se o projeto está íntegro e não apresenta erros de
compilação.
Figura 8 – Criação de uma Baseline
O campo Target Branch Name corresponde ao nome de baseline a ser criada
e o campo Description corresponde a uma breve descrição das modificações
realizadas no projeto.
É possível que se crie baselines que são um meio termo entre outras duas,
por exemplo quando a última versão contém várias modificações e itens incluídos e
a empresa tem o cuidado de não colocar em produção uma versão tão drástica. Este
procedimento deve ser encarado como a última versão do software que pode entrar
30
em produção, em alguns casos é possível que existam novos itens adicionados mais
ainda precisam de validação para que entrem em produção.
A figura 9 mostra a criação de uma baseline que contém apenas os itens da
modificação (Changeset) 5863 que não é a última modificação. É possível criar uma
versão por um período de datas entre as modificações, ficando a critério do
responsável pelo procedimento.
Figura 9 – Criação de uma baseline parcial
31
Note que na figura 10 há a informação de que a baseline criada corresponde
até a modificação 5683 no campo Changeset.
Figura 10 – Descrição de uma baseline parcial
Após a criação, deve-se tomar o cuidado de não permitir que alterações
sejam feitas na baseline, para isso é preciso que se realize o bloqueio (Lock) dos
itens para não permitir que os desenvolvedores alterem o seu conteúdo, ficando a
critério do responsável pela criação as alterações – como boa prática alterar
somente a descrição e/ou a nomenclatura quando necessário.
A figura 11 mostra o processo de bloqueio, ele pode ocorrer de duas formas:
Check Out: Impede que outros usuários modifiquem a versão e a atualizem a
biblioteca
Check In: Permite que outros usuários modifiquem a versão mas impede que a
atualizem na biblioteca
32
Figura 11 – Processo de bloqueio de uma baseline
5.4 Requisito 4: A situação dos itens de configuração e das baselines é registrada
ao longo do tempo e disponibilizada
O controle de status de cada baseline deverá estar no PCG bem como o local
para armazenamento. Quando uma baseline é criada – processo realizado no
requisito 3 – automaticamente é criado um diretório com o mesmo nome contendo
todos seus arquivos físicos. O acesso físico destes itens é mostrado na figura 12.
Figura 12 – Acesso físico das baselines
33
5.5 Requisito 5: Modificações em itens de configuração são controladas
5.5.1 1º Requisito: Criação de um registro de evento - o registro é criado e descrito em detalhes.
No TFS todo registro de mudança é iniciado como Proposed (Proposto). Uma
vez que a equipe se compromete a aceitar esta mudança o seu status é alterado
para Active (Ativo). Caso este venha a ser um defeito o seu conteúdo deve ser
movido para um novo item (bug).
Figura 13 - Criação de um Registro de Mudança no TFS
A figura 13 mostra como um registro de mudança é criado, observe que nele
estão informações como:
O responsável pelo registro de mudança
A situação
Os detalhes da mudança
34
Com estas informações, o requisito de criação de um registro de evento é
cumprido.
5.5.2 2º Requisito: Análise de registro de um evento - é preciso avaliar o impacto da mudança em todos os itens correlacionados.
Após a equipe avaliar o impacto que o requisito de mudança causará na
aplicação esta informação deve ser mantida junto ao registro do evento
correspondente. A figura 14 mostra onde as informações referentes à análise é
guardada.
Figura 14 - Análise de registro de um evento
Assim, o requisito de análise de registro de um evento é parcialmente
cumprido, já que a análise em si não é competência do software, mas sim da equipe,
este somente deve guardar as informações referentes ao registro.
5.5.3 3º Requisito: Rejeição ou aceitação de registro de mudança de um evento - Se um registro é aceito deve ser criado um pedido de mudança para cada item afetado.
Após a proposição do registro mudança este em algum momento deverá ser
aceito ou rejeitado pela equipe, o estado do registro passará para Active (ativo) caso
ele seja aceito ou para Closed (fechado) caso ele seja rejeitado, este por sua vez
encerra o ciclo de vida do registro.35
A figura 15 mostra onde a informação do estado do registro é alterada, desta
forma o requisito de rejeição ou aceitação de registro de mudança de um evento é
satisfeito.
Figura 15 - Estado de um registro de mudança
5.5.4 4º Requisito: Pedido de mudança inicia um novo item de configuração - Um novo item de configuração é estabelecido, criado e uma mudança é implementada.
Quando o pedido de mudança é aceito, este deve iniciar um novo item de
configuração que será implementado pela equipe. Este novo item é chamado de
Requirement (Requerimento) e deve estar associado ao pedido de mudança -
mantendo sua rastreabilidade.
Figura 16 - Criação de um novo item de configuração (Requirement)
36
A figura 17 mostra como se dá a associação de um pedido de mudança a um
novo IC - que foi criado no passo anterior. Com estas informações é possível
identificar quais alterações foram necessárias para implementar uma mudança,
neste caso apenas um IC foi criado mas é possível associar vários IC à um pedido
de mudança.
Figura 17 - Associação de um pedido de mudança a um novo IC.
5.5.5 5º Requisito: Fechamento de um pedido de mudança: o pedido de mudança deve ser fechado quando estiver implementado e aceito.
A figura 18 mostra um pedido de mudança fechado, este procedimento só
deve ser realizado após todas as alterações relacionadas forem concluídas.
37
Figura 18 - Fechamento de um pedido de mudança
5.5.6 6º Requisito: Fechamento de um registro de evento: o registro de evento pode ser fechado quando todos os pedidos de mudanças relacionados à ele forem fechados.
A figura 19 mostra o fechamento de um registro de evento.
Figura 19 - Fechamento de um registro de evento
5.6 Requisito 6: O armazenamento, o manuseio e a liberação de itens de
configuração e baselines são controlados.
Este requisito corresponde a definição dos IC que serão controlados, suas
dependências e permissões de acesso que devem estar no PGC.
5.7 Auditorias de configuração são realizadas objetivamente para assegurar que as
baselines e os itens de configuração estejam íntegros, completos e
consistentes.
É de responsabilidade do gerente de projeto fornecer informações que permitam a
auditoria do projeto, este relatório deve ser disponibilizado contendo as seguintes
informações (RENAPI, 2012):
Identificação da Revisão
Período que compreende a revisão
Itens de configuração que compõe a revisão
38
Motivo da inclusão
39
6 CONCLUSÃO
A Gerência de Configuração surgiu da necessidade de controlar as modificações
que aconteciam durante o ciclo de vida de um projeto para que estas posteriormente
não se tornassem um problema, a partir dela foi possível responder perguntas que
antes eram incógnitas para os gerentes de projeto.
Tendo como foco o cumprimento parcial do nível F do MPS.BR onde a Gerência
de Configuração está inserida e utilizando o TFS, através deste trabalho foi
identificado e exemplificado como o software atende os requisitos necessários para
uma posterior avaliação visando a obtenção de tal nível de qualidade.
Dentre algumas dificuldades encontradas, posso citar a falta de literaturas
nacionais que tratam da Gerência de Configuração, a difícil implantação do TFS e o
curto espaço de tempo para demonstrar o grande potencial deste software.
O TFS permite não só controlar e identificar IC, como também oferece um portal
de gerenciamento e diversas ferramentas que podem integrá-lo permitindo
centralizar todas as funções em um único repositório de dados.
Recomendo a todos que utilizem este material como fonte de dados que
explorem ainda mais os potenciais desta ferramenta e os benefícios adquiridos na
qualidade de software através do modelo MPS.BR.
40
7 REFERÊNCIAS
DURÕES, RAMON. Team Foudation Server não é Source Safe. Disponível em:
http://www.ramonduraes.net/2009/06/15/team-foundation-server-nao-e-source-safe/
Acesso em: out. 2012.
FIGUEIREDO, SÁVIO; SANTOS, GLEISON; ROCHA, ANA REGINA. Gerência de
Configuração em Ambientes de Desenvolvimento de Software Orientados a
Organização, Rio de Janeiro, p. 5-14, 2004.
(ISO, 2000) ISO 9001:2000 - Sistemas de Gestão da Qualidade – Requisitos, 2000
MCT. Ministério da Ciência e Tecnologia (2001) Secretaria de Política de
Informática. Qualidade e Produtividade no Setor de Software Brasileiro. Brasília, DF.
Acesso em abr. 2012. Disponível em:
http://www.mct.gov.br/index.php/content/view/2867
MOLINARI, LEONARDO. Gerência de Configuração: Técnicas e Práticas no
Desenvolvimento de Software. 2007. Edição 1.
MPS.BR – Melhoria de Processo de Software Brasileiro. Acesso em abr. 2012.
Disponível em: http://www.softex.br/mpsbr/_guias/default.asp
PRESSMAN, R.S. Software Engineering: A Practitioner's Approach. 5th Edition, New
York: McGraw-Hill, 2001.
RENAPI. Resultados esperados da Gerência de Configuração, 2009. Disponível em: http://www.renapi.gov.br Acesso em nov. 2012.
SEI – Software Engineering Institue, Carnegie Mellon University. Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.1: Method Definition Document, CMU/SEI-2001-HB-001, 2001.
SOFTEX, 2010 - Associação para Promoção da Excelência do Software Brasileiro.
Acesso em mai. 2012. Disponível em: http://www.softex.br/mpsbr/_home/default.asp
SOFTEX, 2005. Modelo de Referência e Método de Avaliação para Melhoria de Processo de Software – Versão 1.0.
41
VELOSO, F. Botelho, A. J. J., Tschang, T., Amsden, A. Slicing the Knowledge-
based Economy in Brazil, China and India: A Tale of 3 Software Industries.
Report.Massachussetts Institute of Technology (MIT), setembro 2003.
WEBER, K. C., Pinheiro, M. Software Quality in Brazil. Quality World Magazine, vol.
21, issue 1.1. The Institute of Quality Assurance (IQA). London, UK, novembro l995.
WEBER, K.C., Almeida, R.A.R., Amaral, H.G., Gunther, P.S., Xavier, J.H.F.,Loures,
R. “ISO 9001/TickIT Certification in Brazilian Software Companies”. 5th International
Conference on Software Quality Management (SQM’97). Bath, UK, março 1997.
42
