Embed Size (px)
Citation preview
REGINALDO PEREIRA DE SOUZA
CMM
Práticas de Gerência de Configuração
Universidade São Francisco
Itatiba – 2004
ii
REGINALDO PEREIRA DE SOUZA
CMM
Práticas de Gerência de Configuração
Universidade São Francisco
Itatiba – 2004
Pesquisa desenvolvida sob orientação do professor Adalberto Nobiato Crespo para obtenção do título de graduação do curso de Análise de Sistemas da USF - Itatiba
iii
CMM
Práticas de Gerência de Configuração
REGINALDO PEREIRA DE SOUZA
Monografia defendida e aprovada em 06 de dezembro de 2004 pela Banca Examinadora assim constituída: Prof. Adalberto Nobiato Crespo (Orientador) USF – Universidade São Francisco – Itatiba – SP. Prof. Alencar de Melo Júnior (Membro Interno) USF – Universidade São Francisco – Itatiba – SP. Prof. Rodrigo Prado (Membro Interno) USF – Universidade São Francisco – Itatiba – SP.
iv
RESUMO
Esta pesquisa tem como objetivo principal, descrever as atividades de SCM –
Software Configuration Manager (Gerência de Configuração de Software), utilizando as
práticas de Nível 2 do modelo de qualidade de software CMU/SEI-CMM Carnegie Mellon
University/ Software Engineering Institute-Capability Maturity Model, também conhecido
como CMM, mostrando as vantagens do desenvolvimento paralelo, componentização e a
economia que se faz ao contemplar o modelo. Desta pesquisa, resulta um modelo contendo
os procedimentos que possam ser implementados em uma software house que queira incluir
SCM no seu processo de desenvolvimento de software.
Portanto, os passos para atingir os benefícios de SCM formam o escopo principal
desta pesquisa, mas para tais conclusões fez-se necessário estudar todo o modelo
CMU/SEI-CMM Carnegie Mellon University/ Software Engineering Institute-Capability
Maturity Model, com seus 5 (cinco) níveis de maturidade e suas áreas chaves, além do
processo de engenharia de software RUP – Rational Unified Process.
ABSTRACT
This research has as its main goal to describe the SCM - Software Configuration
Manager activities using the practices of Level 2 in the model of software quality
CMU/SEI-CMM Carnegie Mellon University/Software Engineering Institute-Capability
Maturity Model, also known as CMM, showing the advantages of the parallel development,
componentization and the economy made when contemplating the model. From this
research results a model containing the procedures that can be deployed in a software house
that would like to include SCM in its software development process.
Therefore, the steps to reach the SCM benefits make the main scope of this
research. But, for such conclusions, it was necessary to study the entire model CMU/SEI-
CMM Carnegie Mellon University/ Software Engineering Institute-Capability Maturity
Model with its five (5) levels of maturity and its key areas, besides the software engineering
process RUP - Rational Unified Process.
v
SUMÁRIO
1. INTRODUÇÃO....................................................................................................................................... 7
2. MODELOS DE REFERÊNCIA .............................................................................................................. 8
2.1. CMM – Capability Maturity Model ........................................................................................................ 8
2.1.1. Nível 1 – Inicial ................................................................................................................... 10 2.1.2. Nível 2 – Repetível .............................................................................................................. 11 2.1.3. Nível 3 – Definido ............................................................................................................... 13 2.1.4. Nível 4 – Gerenciado ........................................................................................................... 15 2.1.5. Nível 5 – Em Otimização..................................................................................................... 16
2.2. RUP - Rational Unified Process............................................................................................................ 17
3. SCM – SOFTWARE CONFIGURATION MANAGER....................................................................... 20
3.1. Conceito ................................................................................................................................................ 20
3.2. Metas (Goals)........................................................................................................................................ 21
3.3. Atividades ............................................................................................................................................. 21
3.4. Artefatos................................................................................................................................................ 23
3.4.1. Plano de Gerência de Configuração.............................................................................................. 23 3.4.2. Itens de Configuração (ICs) .......................................................................................................... 23 3.4.3. Requisição de Mudança ................................................................................................................ 24 3.4.4. Relatório de Balanço..................................................................................................................... 24 3.4.5. Release Notes ................................................................................................................................ 24
4. FERRAMENTAS.................................................................................................................................. 25
4.1. Rational ClearCase................................................................................................................................ 26
4.2. CVS - Concurrent Versions System...................................................................................................... 27
4.3. StarTeam............................................................................................................................................... 27
4.4. Microsoft Visual SourceSafe ................................................................................................................ 27
4.5. Rational ClearQuest .............................................................................................................................. 28
4.6. +1CR..................................................................................................................................................... 28
5. MODELO DE PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO E MUDANÇA........................ 28
5.1. Fluxo de Atividades .............................................................................................................................. 29
5.1.1. Estabelecer Gerência de Configuração ......................................................................................... 29 5.1.2. Criar Ambiente de Configuração .................................................................................................. 30 5.1.3. Gerenciar Mudanças ..................................................................................................................... 30 5.1.4. Gerenciar Itens de Configuração................................................................................................... 32 5.1.5. Gerenciar Baseline e Release ........................................................................................................ 32 5.1.6. Monitorar Subcontratada............................................................................................................... 33
6. CONSIDERAÇÕES FINAIS ................................................................................................................ 34
7. GLOSSÁRIO......................................................................................................................................... 35
8. REFERÊNCIAS BIBLIOGRAFICAS................................................................................................... 38
9. BIBLIOGRAFIA ................................................................................................................................... 38
vi
10. APÊNDICES........................................................................................................................................... 38
Apêndice A – Template de Plano de Gerência de Configuração ................................................................. 38
Apêndice B – Template de Relatório de Balanço de Configuração ............................................................. 38
Apêndice C – Template de Release Notes ................................................................................................... 38
Apêndice D – Template de Formulário de Requisição de Mudança............................................................ 38
7
1. INTRODUÇÃO
A necessidade de sobrevivência comercial em um mercado sem fronteiras faz com
que as empresas vivam um processo de transformação contínua. Especificamente, as
empresas de software são umas das mais afetadas por estas transformações, dada a
dinâmica dos componentes envolvidos num projeto de software. Neste contexto, a
Engenharia de Software tem por finalidade auxiliar na construção de softwares da melhor
maneira possível.
Embora vários esforços no sentido de se produzir software com maior produtividade
e qualidade tenham ocorrido em décadas anteriores, foi nos anos 90 que se iniciou um
movimento de entendimento e solução de problemas crônicos que afetam a indústria de
software, principalmente os relacionados ao não cumprimento de prazos, orçamentos e
funcionalidades requeridas em seus produtos. Foi reconhecido que vários desses problemas
estariam baseados no fato da construção de software estar sendo conduzida por métodos
improvisados e de maneira artesanal, muitas vezes, mais dependente do talento profissional
e de esforços heróicos individuais, do que de processos formais orientados ao
gerenciamento e à engenharia de software.
Com isso, os modelos de qualidade do processo de software ganharam visibilidade
mundial. Em especial, o CMU/SEI-CMM Carnegie Mellon University/ Software
Engineering Institute-Capability Maturity Model ou, simplesmente, CMM [1].
Uma das áreas-chaves desse processo é a SCM – Software Configuration Manager
(Gerência de Configuração de Software), que tem como objetivo estabelecer e manter a
integridade dos produtos do projeto de software ao longo de todo o ciclo de vida de
software do projeto.
8
2. MODELOS DE REFERÊNCIA
A seguir serão apresentados o Modelo de Capacitação de Maturidade (Capability
Maturity Model – CMM) e o Processo Unificado da Rational (Rational Unified Process –
RUP), de grande aceitação em nível internacional e que foram utilizados como referência
para a elaboração desta pesquisa.
2.1. CMM – Capability Maturity Model
O CMM é uma iniciativa do SEI para avaliar e melhorar a capacitação de empresas
que produzem software. O projeto CMM foi apoiado pelo Departamento de Defesa do
governo dos Estados Unidos (DOD), que é um grande consumidor de software e precisava
de um modelo formal que permitisse selecionar os seus fornecedores de software de forma
adequada. Embora não seja uma norma emitida por uma instituição internacional como a
ISO ou o IEEE, este modelo tem tido uma grande aceitação mundial. O CMM é um guia
designado a ajudar as organizações de software a selecionar estratégias de melhoria de
processos[2].
O objetivo deste modelo é que o processo de software possa ser repetido, controlado
e medido e estabelecer uma compreensão comum entre clientes e a equipe de
desenvolvimento de software sobre a necessidade dos clientes, o CMM leva a organização
em direção a uma visão integrada onde as necessidades técnicas devem ser mantidas
consistentes com as atividades desenvolvidas e com o planejamento do projeto[3]. Para
efetuar este processo, os requisitos do software devem ser documentados e revistos pelos
gerentes de software e grupos afetados, incluindo representantes dos clientes e da
comunidade de usuários.
O modelo auxilia as organizações a implementarem um processo de melhoria
gradativa, baseado em níveis de maturidade. O termo maturidade está associado ao grau de
conhecimento, controle e sistemática de execução de um processo de software atingido por
9
uma organização[1]. O CMM se divide em cinco níveis conforme pode se observar na
figura 2.1 apresentada abaixo:
Cada nível especifica um conjunto de processos que devem ser estabelecidos para se
atingir a maturidade correspondente ao nível. Adicionalmente, cada nível serve de base
para o estabelecimento dos processos do nível seguinte.
Os cinco níveis do CMM são organizados em áreas chave (KPA). Ao todo, o
modelo possui 18 áreas chave. Cada área chave possui 5 características comuns:
• Compromisso em realizar
• Capacidade de realizar
• Atividades realizadas
• Medição e Análise
• Verificação da Implementação
Cada área chave possui práticas chave (KP). Ao todo, o modelo possui 316 práticas-
chave.
Inicial (1)
processo disciplinado Repetível (2)
processo padronizado Definido (3)
processo previsível Gerenciado (4)
processo em melhoria contínua
Em otimização (5)
Pouco Controlado Figura 2.1
10
As áreas chave do processo constituem a primeira divisão sistemática dentro dos
níveis de maturidade de uma organização. Esses grupos de atividades, quando executadas
em conjunto, satisfazem um conjunto de metas relevantes para a melhoria da capacitação
do processo. O CMM considera cada área chave um processo particular.
Os níveis de maturidade descrevem os problemas mais predominantes daquele
nível. Uma organização migra de um nível a outro sempre que consegue operacionalizar
todas as áreas-chave específicas de um nível.
2.1.1. Nível 1 – Inicial
O processo de software é considerado como desorganizado, e ocasionalmente
também caótico. Poucos processos são definidos e as qualidades alcançadas pelo software,
os processos e o conhecimento pertencem às pessoas e não aos projetos.
No primeiro nível do modelo destacam-se as seguintes características:
• Estágios das atividades mal definidos;
• Dificuldade de visualizar e gerenciar o progresso e as atividades do projeto;
• Os requisitos fluem no processo de uma forma não controlada e há um
“produto” resultante;
• O cliente somente verifica se os seus requisitos foram atendidos na entrega do
produto.
Áreas-chave de Processo:
• Este nível não possui áreas-chave de processos.
11
2.1.2. Nível 2 – Repetível
Processos básicos de gerenciamento de projetos são estabelecidos para
monitoramento de custo, prazo e funcionalidade. A necessária disciplina do processo é
adequada para repetir sucessos anteriores em projetos com aplicações similares.
No nível de maturidade definido como repetível, as políticas de gerenciamento do
software e os procedimentos detalhados para sua implementação estão estabilizados. O
planejamento e o gerenciamento dos novos projetos são baseados na experiência adquirida
em projetos similares anteriormente executados.
Um dos objetivos a ser alcançado no CMM Nível 2 é tornar corporativos todos os
processos de gerenciamento de software, o que permitirá à organização repetir
sistematicamente as melhores práticas internas estabelecidas pelas várias experiências
adquiridas em projetos anteriores.
Um efetivo processo de gerenciamento de software deve ser praticado,
documentado, garantido, treinado, medido e constantemente melhorado.
Projetos em organizações com CMM Nível 2 têm controles básicos de
gerenciamento de software. As estimativas de tempo, recursos e custos do software são
baseadas nos históricos dos projetos anteriores e projetadas através dos requisitos
estabelecidos no atual projeto. Os gerentes de software possuem um controle de
rastreabilidade em relação aos custos, cronogramas, funcionalidades e defeitos. Os
problemas são identificados na mesma etapa em que são gerados, evitando a propagação de
erros para fases posteriores.
Os requisitos de software e todos os produtos gerados durante o desenvolvimento
são sistematicamente monitorados, possibilitando um acompanhamento da evolução do seu
tamanho e complexidade. Os padrões de desenvolvimento do software são definidos e a
organização garante que estão sendo sistematicamente seguidos.
12
As organizações CMM Nível 2 que empregam terceiros (subcontratados) para todo
ou parte dos processos de desenvolvimento de um software, devem estruturar políticas
claras e padronizadas de como estabelecer vínculos precisos e transparentes no
relacionamento cliente-fornecedor.
O processo de software de uma organização CMM Nível 2 pode ser entendido como
um processo disciplinado, pois as políticas de planejamento e rastreamento do projeto de
software estão estáveis e as práticas aplicadas a determinados projetos podem ser
convenientemente repetidas corporativamente. O processo de software está sob o controle
de um consolidado modelo de gerenciamento de projetos regido por planos objetivos e
realistas, estimados a partir das experiências de projetos anteriores.
No segundo nível do modelo destacam-se as seguintes características:
• As atividades, medições, pontos e verificação estão definidos;
• Requisitos do cliente e produtos do trabalho são controlados;
• É possível medir qualidade, custo e cronograma;
• O processo de desenvolvimento de software permite o gerenciamento entre pontos
de transição (“milestones”);
• O cliente pode analisar o produto durante o processo de software (“checkpoints”);
• Existem mecanismos formais para a correção de desvios;
• Os processos pertencem aos projetos e não às pessoas.
Áreas chave de Processo:
RM – Gerência de Requisitos
SPP – Planejamento de Projeto de Software
SPTO – Acompanhamento e Supervisão do projeto de Software
13
SSM – Gerenciamento de subcontratado de software
SQA – Garantia da qualidade de software
SCM – Gerência da configuração de software
2.1.3. Nível 3 – Definido
O processo de software para as atividades de gerenciamento e engenharia é
documentado, padronizado e integrado no âmbito da organização e todos os projetos são
adaptados deste processo.
No nível de maturidade classificado como Definido, os diversos processos
padronizados de desenvolvimento de software estão adequadamente documentados.
Os processos de gerenciamento do software estão convenientemente integrados aos
processos de engenharia de software, tornando o modelo de processos único e integrado às
diversas áreas organizacionais. Os processos estabelecidos em organizações CMM Nível 3
são usados e ajustados para auxiliar os gerentes e profissionais de software a ganharem
mais produtividade.
A organização busca as melhores práticas de engenharia de software quando
padronizam seus processos de software. Há um grupo responsável por estabelecer e
documentar as atividades do processo de software denominado SEPG (Software
Engineering Process Group). Um amplo programa de treinamento corporativo deverá ser
implementado para desenvolver gerentes e profissionais e capacitá-los a desempenhar
melhor suas funções, empregando uma política contínua de transferência do conhecimento
e adequado desenvolvimento e aprimoramento de habilidades.
As organizações CMM Nível 3 conseguem gerenciar processos dinâmicos de
desenvolvimento de software. A partir de um processo padrão desenvolvimento, essas
organizações podem acrescentar, modificar ou eliminar atividades, dependendo das
14
características e riscos envolvidos no projeto, possibilitando a criação de um processo de
desenvolvimento “customizado” a cada situação. A equipe do SEPG estabelece os pontos
de processo que possibilitam a “customização” e estabelece os critérios de flexibilização e
em quais situações serão empregadas. Um processo bem definido inclui pré-requisitos para
início das fases do projeto, artefatos obrigatórios e opcionais, padrões e modelos de
referência, procedimentos de execução dos trabalhos, mecanismos de verificação de
documentos, artefatos de saída e critérios de finalização das etapas. Nesse nível, é possível
visualizar claramente como cada projeto em execução está evoluindo.
O processo de software de uma organização CMM Nível 3 pode ser entendido como
padronizado e consistente porque ambas as atividades de engenharia e desenvolvimento
estão estáveis e replicáveis. Todos os aspectos relativos a um produto de software como
custos, atividades e funcionalidades estão sob controle e a qualidade é medida e registrada.
Existe uma visão corporativa do processo de desenvolvimento, um entendimento
claro sobre as atividades e responsabilidades estabelecidas neste processo de software.
No terceiro nível do modelo destacam-se as seguintes características:
• As atividades no processo definido de projeto de software são visíveis;
• Os processos utilizados estão estabelecidos e padronizados em toda a organização;
• Como estão estáveis, os processos podem ser medidos quantitativamente;
• Gerentes e engenheiros entendem suas atividades e responsabilidades no processo;
• Gerenciamento preparado pró-ativamente para possíveis riscos;
• O cliente pode obter status atualizado, rapidamente e corretamente, com detalhe
entre as atividades;
• Os processos pertencem agora a organização e não aos projetos.
15
Áreas chave de Processo:
OPF – Foco no processo da organização
OPD – Definição do processo da organização
TP – Programa de treinamento
ISM – Gerência Integrada de Software
SPE – Engenharia de Produto de Software
IC – Coordenação entre grupos
PR – Revisões técnicas formais
2.1.4. Nível 4 – Gerenciado
Medições detalhadas do processo de software e qualidade do produto são coletadas.
Ambos são quantitativamente entendidos e controlados. O gerenciamento quantitativo do
processo tem o seu foco no processo e a capacidade do processo é conhecida
quantitativamente. Quando o desempenho cai fora dos limites, deve-se identificar a razão e
a realizar ações corretivas adequadas.
Controle quantitativo no CMM significa qualquer técnica quantitativa ou baseada
em métodos estatísticos. As palavras “estatística” e “quantitativa” envolvem
necessariamente dados (números). Gerenciamento baseado em dados (fatos) resulta em
decisões objetivas.
No Nível 2, o foco da qualidade é “conformidade com os requisitos”, já no Nível 4,
há uma ênfase na compreensão das necessidades do cliente, do usuário final e da
organização. No Nível 4 dados são coletados e analisados nos diversos projetos da
organização, metas mensuráveis de qualidade de produto são definidas e utilizadas.
16
No quarto nível do modelo destacam-se as seguintes características:
• Medidas de qualidade e produtividade são coletadas em todos os projetos;
• Gerentes possuem uma base de dados para tomadas de decisões;
• A habilidade de prever resultados é maior e a variabilidade do processo é menor;
• O cliente pode estabelecer um entendimento quantitativo da capacidade do processo
e riscos antes do projeto iniciar;
Áreas chave de Processo:
QPM – Gestão quantitativa dos processos
SQM – Gestão da qualidade de software
2.1.5. Nível 5 – Em Otimização
Processo contínuo de melhoria é possível pela realimentação quantitativa do
processo e da condução de idéias inovadoras e tecnológicas. O processo de melhoria no
Nível 5 pode ser considerado como um “estilo de vida” da organização. Nas organizações
maduras todos estão envolvidos nas atividades de melhoria.
Uma das finalidades no Nível 5 é identificar a causa dos defeitos e evitar que eles
aconteçam novamente. Envolve analisar defeitos que foram encontrados no passado,
realizar ações específicas para evitar a ocorrência desses tipos de defeitos no futuro.
No Nível 5 existe um grande foco na analise das causas, por exemplo, verifica-se
porque o processo permitiu que o defeito ocorresse; o que no processo necessita ser
corrigido para prevenir a ocorrência do defeito no futuro.
17
Existe no Nível 5 também uma preocupação com a identificação de novas
tecnologias (ex. ferramentas, métodos e processos) e transferi-las para a organização de
uma forma disciplinada. Envolve identificar, selecionar e avaliar novas tecnologias.
Outra preocupação do Nível 5 é a de melhorar continuamente os processos de
software utilizados na organização com o objetivo de melhorar a qualidade de software,
aumentando a produtividade e diminuindo o ciclo de desenvolvimento do produto.
No quinto nível do modelo destacam-se as seguintes características:
• Melhoria contínua do processo objetivando produtividade e qualidade;
• Gerentes são aptos a estimar e monitorar a eficácia das mudanças;
• Forte relação de parceria com o cliente.
Áreas chave de Processo:
DP – Prevenção de não-conformidades
TCM – Gestão de Mudança Tecnológica
PCM – Gestão de Mudança do Processo
2.2. RUP - Rational Unified Process
O padrão CMM especifica detalhadamente “O QUÊ” deve ser feito. O mercado
muitas vezes, se perguntou “COMO” fazê-lo. Uma das empresas que se habilitou a
responder esta questão foi a Rational Software Corporation que desenvolveu, com esta
finalidade, o processo de engenharia de software Rational Unified Process (RUP).
O Rational Unified Process é um processo de engenharia de software, cujas
principais características são um desenvolvimento iterativo e incremental, orientado a
objetos, com foco na criação de uma arquitetura robusta, análise de riscos, e a utilização de
casos de uso para o desenvolvimento. O RUP foi desenvolvido para ser aplicável a uma
18
grande classe de projetos diferentes e pode ser considerado como um modelo genérico para
processos de desenvolvimento. Isso significa que ele deve ser configurado para ser usado
eficientemente [4].
Alguns conceitos do RUP definem: o ator - cujas responsabilidades e
comportamentos podem ser aplicados a diversos indivíduos - a atividade, a unidade de
trabalho de um determinado ator e os artefatos, que são elementos utilizados, criados ou
modificados pela ação do ator durante a atividade. A atuação em uma atividade ao longo do
tempo é denominada tarefa, e gera, na coletividade um workflow, isto é, uma seqüência que
produz um resultado observável.
A figura 2.1 mostra a arquitetura geral do RUP.
O RUP tem duas dimensões:
• O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do
processo à medida que se desenvolve;
• O eixo vertical representa as disciplinas, que agrupam as atividades de maneira
lógica, por natureza.
Figura 2.1
19
A primeira dimensão representa o aspecto dinâmico do processo quando ele é
aprovado e é expressa em termos de fases, iterações e marcos. A segunda dimensão
representa o aspecto estático do processo, como ele é descrito em termos de componentes,
disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo.
O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações
iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos mais
tempo com implementação.
O RUP se encontra definido em quatro fases: Concepção, Elaboração, Construção e
Transição, cada uma com objetivos específicos. Na fase de Concepção, deve-se estabelecer
o escopo e a viabilidade econômica do projeto. Na Elaboração, o objetivo é eliminar os
principais riscos e estabelecer uma arquitetura estável a partir da qual o sistema poderá
evoluir. Na fase de Construção, um produto completo é desenvolvido de maneira iterativa
até que esteja pronto para ser passado aos usuários, o que ocorre na fase de Transição, onde
uma versão beta do sistema é disponibilizada. No final da Transição pode ser iniciado um
novo ciclo de desenvolvimento para a evolução do produto, o que envolveria todas as fases
novamente. Todas as fases têm ao final um marco (milestone) de verificação de quais
objetivos da fase foram alcançados [4].
Estas fases geram, cada uma, artefatos e revisões nos requisitos de construção do
software. Dentre os vários workflows do modelo RUP, tem destaque o de Gerência de
Configuração e Mudança, representante da KPA de SCM, que mantém a integridade dos
artefatos do projeto.
Este workflow, por si próprio, gera como artefatos o plano de Gerência de
Configuração e as solicitações de alterações, além de atas de reuniões sobre a infra-
estrutura do projeto. Conforme observado na figura 2.1, este processo é continuo desde o
inicio do projeto, com um crescimento constante das atividades.
20
3. SCM – SOFTWARE CONFIGURATION MANAGER
3.1. Conceito
A área chave SCM – Software Configuration Manager (Gerência de Configuração e
Mudança) é a disciplina que gerencia e controla a evolução de um software através,
basicamente, de controle formal de versões e solicitações de mudança. Esta área chave
permite que gerentes, analistas, programadores, testadores e usuários entendam o sistema
não apenas em seu estado atual, mas também em seus estados anteriores e, devido às
mudanças em curso, em um estado futuro.
A adoção de SCM por uma empresa envolve custos e benefícios que devem ser
considerados. Os principais benefícios decorrentes da aplicação estão entre a facilidades
para acomodar mudanças, o maior controle sobre os produtos, a economia de tempo de
desenvolvimento, a facilidades na geração de versões diferentes de um mesmo produto de
software (customização), a manutenção de históricos de produtos e a facilidades de se
voltar a situações anteriores. Os principais custos, por outro lado, são o treinamento e os
investimentos para a implementação, que englobam recursos humanos e computacionais.
Entre os conceitos fundamentais de SCM está o conceito de “Itens de
Configuração”, que pode ser definido como “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”[2].
Outro importante conceito é o de baseline (Configurações-Base). Por baseline,
entende-se um conjunto bem definido de Itens de Configuração que representam um estágio
do desenvolvimento, que é passível de modificações apenas mediante um mecanismo
formal de alterações[1]. Portanto, se podem medir as quatro atividades principais de SCM
como sendo:
• Identificação de Itens de Configuração
21
• Controle de configuração das baselines
• Administração de estado das baselines (processo formal de mudanças)
• Auditagem desta configuração
Todas essas atividades levam a um objetivo final, o controle de versões, que
engloba a automatização do rastreamento de arquivos, a prevenção de conflitos entre
desenvolvedores, permitindo o desenvolvimento paralelo, a recuperação de versões prévias
para manutenção ou upgrade e a agregação de novos módulos, funcionalidades ou
requisitos.
3.2. Metas (Goals)
Meta 1 As atividades de Garantia da Qualidade de Software são planejadas.
Meta 2 A aderência dos produtos de software e das atividades aos padrões,
aos procedimentos e aos requisitos estabelecidos é verificada
objetivamente.
Meta 3 As atividades e os resultados das atividades de Garantia da
Qualidade de Software são informados às pessoas e aos grupos
afetados.
Meta 4 As questões de não conformidade, que não podem ser resolvidas
internamente ao projeto, são levadas ao conhecimento da gerência
superior.
3.3. Atividades
Atividade 1 É elaborado um plano de GCS para o projeto de software, de acordo
com procedimentos documentados.
22
Atividade 2 Um plano de GCS documentado e aprovado é utilizado como base
para a realização das atividades de GCS.
Atividade 3 Um sistema de biblioteca para gerência de configuração é
estabelecido como repositório para as configurações básicas
(baselines) de software.
Atividade 4 Os produtos de trabalho de software a serem colocados sob Gerência
de configuração são identificados.
Atividade 5 As solicitações de alterações e relatórios de problemas para todos os
itens/unidades de configuração são iniciados, revisados, aprovados e
encaminhados de acordo com um procedimento documentado.
Atividade 6 As alterações das configurações básicas (baselines) são controladas
de acordo com um procedimento documentado.
Atividade 7 Os produtos são criados a partir da biblioteca de configuração básica
do software (baseline) e suas versões são controladas de acordo com
um procedimento documentado.
Atividade 8 A situação dos itens/unidades de configuração é registrada de acordo
com um procedimento documentado.
Atividade 9 Os relatórios padrão que documentam as atividades da GCS e o
conteúdo da configuração básica (baseline) do software são
desenvolvidos e disponibilizados para as pessoas e para os grupos
afetados.
Atividade 10 As auditorias na configuração básica (baseline) do software são
conduzidas de acordo com um procedimento documentado.
23
3.4. Artefatos
Considera-se artefato todo conjunto de informações produzidas, modificadas ou
utilizadas por um processo. Um artefato pode ser um modelo, um componente de um
modelo ou um documento. Um artefato pode conter outros artefatos.
Serão apresentados a seguir os artefatos gerados durante o processo de Gerência de
Configuração.
3.4.1. Plano de Gerência de Configuração
O Plano de Gerência de Configuração deve descrever todas as atividades
relacionadas à gerência de configuração e controle de mudança do projeto a serem
realizados ao longo do ciclo de vida do produto. Deve relacionar as responsabilidades dos
membros da equipe do projeto e recursos necessários de hardware, software e humanos.
3.4.2. Itens de Configuração (ICs)
São considerados ICs todos os elementos necessários para o desenvolvimento e
geração dos produtos de software, conforme lista abaixo.
• Códigos fonte do projeto
• Documentos de especificação de requisitos
• Documentos de análise e projeto
• Documentos de testes
• Manuais do produto de software
Os ICs com características diferentes dos critérios para seleção, descritos acima,
podem ser considerados como IC do projeto usando os seguintes critérios :
• O item é entregue ao cliente e faz parte do pacote de software do projeto.
• O item é essencial para a geração do produto de software do projeto.
24
3.4.3. Requisição de Mudança
Mudanças nos artefatos desenvolvidos podem ser solicitadas através de uma
Requisição de Mudança, conforme definido explicitamente no Plano de Gerência de
Configuração do projeto. Este artefato pode ser utilizado para documentar e rastrear
defeitos encontrados no produto, solicitações de melhoria ou qualquer outro tipo de
solicitação que demande alguma alteração nos produtos do projeto.
3.4.4. Relatório de Balanço
O relatório de balanço de configuração pode ser obtido visualmente através da
ferramenta de gerência de configuração ou ser um documento gerado. O conteúdo mínimo
do relatório de balanço de configuração das baselines é o seguinte :
• Nova versão da baseline
• Versão anterior da baseline
• Lista de requisitos acordados/implementados
• Lista de solicitações de alteração acordadas/implementadas
• Diferença da baseline atual em relação à anterior
3.4.5. Release Notes
O Release Notes deve ser um documento gerado e considerado parte integrante da
release a ser entregue ao cliente.
Devem constar na Release Notes no mínimo as seguintes informações:
• nome do produto
• versão do produto
• data de liberação
25
• contato para suporte técnico
• referência para o procedimento de instalação
• lista das novas funcionalidades
• lista das solicitações implementadas
4. FERRAMENTAS
Uma vez identificadas as boas práticas e definido um processo de Gerência de
Configuração, o uso de uma ferramenta auxilia em muito o gerenciamento. Tais
ferramentas devem ter como foco facilitar o acesso às informações, garantir a integridade
dos dados, controlar versões dos artefatos e acompanhar as requisições de mudanças. Estas
ferramentas estão se tornando essenciais para agilizar o desenvolvimento, pois através delas
é que o paralelismo se torna viável e controlado, além de garantir o acompanhamento do
ciclo de vida do software através dos históricos das mudanças.
Em suma, uma boa ferramenta de Gerência de Configuração deve:
• Possuir um repositório seguro e escalonável;
• Controlar o versionamento dos itens de configuração;
• Integrar equipes de desenvolvimento;
• Permitir alterações concorrentes, garantindo a integridade do software;
• Possuir mecanismos de comparação e mesclagem de itens concorridos;
• Rastrear solicitações de mudança, bem como atividades atribuídas aos desenvolvedores;
• Controlar e auditar o acesso e mudanças realizadas pelas equipes em itens de
configuração;
26
• Permitir a retomada do projeto em qualquer momento do ciclo de vida, garantindo a
integridade de todos os seus itens naquele dado momento.
Como exemplo, serão apresentadas a seguir algumas ferramentas disponíveis
atualmente no mercado, descrevendo suas características e qual sua aplicabilidade e
contribuição para a Gerência de Configuração.
4.1. Rational ClearCase
É uma ferramenta shareware de gerência de artefatos de software, desenvolvida
pela IBM Rational Software, que oferece recursos e processos que podem ser
implementados e personalizados sob demanda. Ela unifica o processo de mudança sobre o
ciclo de vida de desenvolvimento e é escalonável a todo tamanho de empresa, sem
mudança de ferramentas ou processos. Possui as seguintes funções principais:
• Dá suporte ao desenvolvimento paralelo, mesmo em times distribuídos;
• Oferece controle de versão, gerenciamento de área de trabalho, gerenciamento de
compilação (build) e configuração do processo;
• Versiona os artefatos de software desenvolvidos;
• Provê acesso global a dados de forma transparente, podendo ser via interface Web;
• Habilita o processo baseado em atividades da Rational para UCM (Unified Change
Management);
• Integrável com algumas IDE´s, ferramentas de desenvolvimento e autoria;
• Suporta times de pessoas distribuídos;
• Oferece recurso de Checkin/checkout;
• Versionamento de diretórios, subdirectórios e todos os objetos do sistema de arquivo.
27
4.2. CVS - Concurrent Versions System
O CVS (Concurrent Versions System) é uma ferramenta open-source de apoio ao
desenvolvimento de software cuja principal função é controlar as modificações realizadas
nos arquivos de um projeto. Possui um mecanismo automatizado para identificar e
controlar as modificações realizadas nos arquivos de um projeto ao longo do tempo,
garantindo a integridade e a rastreabilidade das modificações.
O CVS é visto como uma extensão natural do processo de desenvolvimento,
permitindo que se possam realizar modificações paralelas de forma coerente e padronizada,
especialmente em se tratando de equipes geograficamente dispersas.
4.3. StarTeam
Desenvolvido pela Borland, o StarTeam é um software shareware que fornece um
sistema de gerenciamento de configuração automatizado e abrangente, para apoiar o
gerenciamento de recursos e tarefas do ciclo de vida da aplicação.
O StarTeam é um sistema de gerenciamento de alterações automatizado que coloca
nas mãos das equipes de projeto o controle do processo de desenvolvimento, fornecendo
aos usuários acesso a todos os recursos do projeto através de um repositório central apoiado
por um fluxo de trabalho customizável e gerenciamento de processo.
O StarTeam oferece um ambiente integrado para o gerenciamento de requerimentos
e alterações, rastreamento de defeitos e discussões para o gerenciamento das tarefas
necessárias para o gerenciamento efetivo do projeto.
4.4. Microsoft Visual SourceSafe
Sistema shareware de controle de versão que trabalha junto com outro produto da
Microsoft, o Visual Studio .NET, controla arquivos-fonte que podem ser classificados
como valiosos, controla o uso concorrente de arquivos, “etiquetação” de arquivos para
controle de versão, controle de mudanças ao nível de linhas de código, etc.
28
4.5. Rational ClearQuest
Ferramenta shareware desenvolvida pela IBM Rational Software, parte integrante
da Suite Rational, que tem como função controlar mudanças. Uma de suas principais
características é a flexibilidade que possibilita ser customizada de acordo com as
necessidades de cada projeto. Um outro fator importante deste software é a possibilidade de
integração com as demais ferramentas Rational, principalmente o Rational ClearCase.
4.6. +1CR
Software shareware desenvolvido pela Plus-one Software Engeneering, com o
objetivo de controlar requisições de mudanças referentes ao projeto. Armazena descrição
do problema, versão, status, prioridade, categoria, entre outros. Gera relatórios sobre
mudanças no projeto.
5. MODELO DE PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO E
MUDANÇA
Na seqüência, será apresentado um modelo de processo de Gerência de
Configuração, que se adotado num desenvolvimento de software, estará seguindo todas as
metas determinadas pela KPA de SCM – Software Configuration Manager, portanto de
acordo com as exigências do modelo CMM.
Portanto, seguindo o processo e sub-processos representados no fluxograma a seguir
(Figura 5.1), observam-se todo o fluxo de atividades necessárias para um bom
acompanhamento de projeto no ponto de vista da Gerência de Configuração e Mudança.
29
Inicialmente, deve-se elaborar o Plano de Gerência de Configuração (Atividade
Estabelecer Configuração). O ambiente de projeto definido no Plano de Gerência de
Configuração é então criado num repositório (atividade Criar Ambiente de Configuração).
Após estas atividades, pode-se tanto acompanhar uma solicitação de mudança (atividade
Gerenciar Mudanças) como evoluir o sistema (atividade Gerenciar Itens de Configuração).
5.1. Fluxo de Atividades
5.1.1. Estabelecer Gerência de Configuração
O Plano de Gerência de Configuração é elaborado nesta atividade. O Plano de
Desenvolvimento de Software descreve os artefatos a serem produzidos no projeto e
auxiliam na definição dos itens de configuração (os artefatos que são submetidos a um
Estabelecer
Configuração
Gerenciar Itens de
Configuração
Gerenciar
Mudança
Gerenciar Requisitos
Planejar Projeto
Acompanhar Projeto
Criar Ambiente de
Configuração
Monitorar Subcontratada (Se aplicável)
Gerenciar Baselines e
Releases
Figura 5.1
30
controle formal de versão e mudança). Esta atividade é usualmente feita no início do
projeto.
Compreende as seguintes atividades:
• Listar os itens de configuração a serem considerados
• Definir baselines e seu conteúdo (ICs)
• Elaborar Plano de Gerência de Configuração
• Planejamento das auditorias de configuração
5.1.2. Criar Ambiente de Configuração
Um dos papéis do Plano de Gerência de Configuração é definir a estrutura de
diretórios de um projeto e os artefatos que estarão sob um controle de versão formal. Esta
atividade apresenta a criação do ambiente definido no Plano de Gerência de Configuração
no repositório do projeto.
Compreende as seguintes atividades:
• Criar o ambiente de Configuração
• Definir ferramentas de apoio
5.1.3. Gerenciar Mudanças
Após a liberação inicial da informação de configuração de produto (baseline), todas
as alterações devem ser controladas.
O potencial de impacto de uma alteração, requisitos do cliente e da baseline afetará
o grau de controle necessário para processar uma alteração proposta ou concessão.
31
Uma requisição de mudança pode ser feita por qualquer responsável (porém,
usualmente, o usuário faz a maioria das solicitações). Um comitê analisa e avalia o impacto
da mudança e, eventualmente, aprova ou rejeita a requisição e aloca recursos para
implementá-la (em caso de aprovação). Durante a evolução do estado da mudança, outros
responsáveis (como programadores, por exemplo) atualizam o artefato Requisição de
Mudança (que registra todo o histórico de uma mudança). Os estados possíveis percorridos
por uma mudança devem ser definidos no Plano de Gerência de Configuração.
Portanto o objetivo deste sub-processo é assegurar que as mudanças na configuração
feitas em um projeto sejam consistentes com as solicitações de alterações selecionadas,
analisando o impacto gerado e informando os envolvidos.
Compreende as seguintes atividades:
• Requisitar Mudanças
• Atualizar Requisição de Mudança
• Avaliar e Aprovar Mudança
É conveniente que o processo para controlar as mudanças seja documentado e é
conveniente que inclua o seguinte:
• descrição, justificativa e registro da alteração;
• categorização da alteração em termos de complexidade, recursos e programação;
• a avaliação das conseqüências da alteração;
• detalhes de como a alteração deve ser disposta;
• detalhes de como a alteração deve ser implementada e verificada.
32
5.1.4. Gerenciar Itens de Configuração
Esta atividade descreve as diferentes etapas de manipulação de um item de
repositório. O check-out copia arquivos do repositório para a Área de Trabalho para ser
alterado. A atividade de check-in atualiza arquivos do repositório com versões mais atuais
contidas na Área de Trabalho. A atividade Atualizar Área de Trabalho copia arquivos do
repositório para a Área de Trabalho para ser consultado (read-only). Eventualmente, o
Integrador marca (rotula, aplica label) um conjunto de artefatos que compõe um baseline
ou uma Unidade de Implantação (release). Estas atividades devem ser executadas de
acordo com as políticas contidas no Plano de Gerência de Configuração.
Compreende as seguintes atividades:
• Check-out
• Check-in
• Atualizar Área de Trabalho
• Estabelecer Baseline
• Criar Unidade de Implantação (Release)
5.1.5. Gerenciar Baseline e Release
Uma baseline consiste da informação de configuração de produto aprovada que
representa a definição do produto. Configurações básicas e alterações desta configuração
básica aprovadas representam a configuração básica atual.
É conveniente que as configurações básicas sejam estabelecidas sempre que
necessário durante o ciclo de vida do produto para definir uma referência para atividades
posteriores.
O nível de detalhe em que o produto é definido numa configuração básica depende
do grau de controle requerido.
33
5.1.6. Monitorar Subcontratada
As atividades de monitoramento de gestão de configuração de software da
subcontratada são planejadas no Plano de Gestão de Configuração do Projeto e a
profundidade das monitorações deve levar em consideração o nível de maturidade da
subcontratada.
Esse planejamento define:
• Periodicidade: deve ser estabelecida em função das datas marco do projeto.
• Envolvidos: um membro do Grupo de Gerência de Configuração (GGC) do
projeto entra em contato com o responsável por gestão de configuração da
subcontratada.
• Mecanismo: pode ser troca de e-mail, relatórios solicitados, acesso remoto ao
repositório da subcontratada, áudio/vídeo conferência, reunião presencial.
• Resultado: relatório com o resultado do monitoramento, o qual será
encaminhado ao gerente de projeto.
• Responsabilidades da subcontratada em resolver os problemas: a subcontratada
é responsável por resolver os problemas encontrados.
• Atividades: revisar documentos, registros e padrões associados à gestão de
configuração da subcontratada; assegurar que os produtos entregues pela
subcontratada possam ser prontamente integrados e incorporados no ambiente
local estabelecido para Gerência de Configuração (GC) do projeto (devem ser
seguidos os critérios de aceitação de produto estabelecidos em contrato);
monitorar o repositório da subcontratada, para garantir que os padrões e
procedimentos para GC estão sendo seguidos.
34
6. CONSIDERAÇÕES FINAIS
A pesquisa buscou mostrar que quando os projetos de software são planejados e
executados com maiores níveis de previsibilidade, os riscos são mais conhecidos e
melhores gerenciados, garantindo-se assim um melhor controle dos resultados esperados.
Portanto pode-se concluir que um dos objetivos fundamentais do modelo CMM
corresponde à idéia de se prever com precisão cada vez maior os prazos e custos dos
projetos de software, assim como os níveis de qualidade e produtividade a serem obtidos,
sempre com o objetivo da melhoria contínua, ou seja, tentar aprender com as falhas e
corrigí-las nos projetos seguintes.
O CMM diz o que deve ser feito, mas não diz como fazer.
Apesar dos debates sobre vantagens e desvantagens do CMM, ele tem sido usado há
mais de 10 anos, tempo suficiente para que muitas companhias possam verificar o aumento
da qualidade de seus produtos e a diminuição de seus custos de produção. Numa era de
crescente aumento de competitividade, qualquer melhora na produtividade do software não
pode ser ignorada.
Com isso, o objetivo principal desta pesquisa é evidenciar as vantagens e melhoras
que a Gerência de Configuração proporciona no decorrer do desenvolvimento do software,
pois através do controle das alterações se possibilita um desenvolvimento totalmente
mapeado, integração entre as equipes envolvidas, maior controle do cronograma do projeto,
menos esforços em manutenção e principalmente, garante a integridade do software
aproximando-se da satisfação do cliente.
Por fim, ao seguir o modelo de processo de Gerência de Configuração apresentado,
utilizando os artefatos sugeridos na forma de templates, contando com uma equipe
motivada e ferramentas adequadas se torna viável a implantação satisfatória da Gerência de
Configuração contemplando todas as práticas de nível 2 da KPA de SCM – Software
35
Configuration Manager, resultando no aumento da produtividade dos
desenvolvedores, com a redução do retrabalho e a possibilidade de paralelismo.
7. GLOSSÁRIO
Análise (UML) Parte do processo de desenvolvimento de software
em que o principal objetivo é construir um modelo do
domínio do problema. A análise foca no “o quê” fazer. O
projeto foca no “como” fazer.
Arquitetura Organização ou estrutura dos componentes significativos de
um sistema e das interações entre eles através de interfaces.
Os componentes podem ser decompostos em componentes e
interfaces menores sucessivamente.
Artefato Conjunto de informações produzidas, modificada ou
utilizada por um processo.
Atividade Unidade de trabalho que determinado membro da equipe
pode ser solicitado a realizar.
Baseline Versão revista e provada de um artefato, constituindo uma
base estável para futuras evoluções do mesmo, que só pode
ser modificado através de um processo formal.
Build Versão operacional de um sistema ou parte dele que
demonstra um conjunto das funcionalidades a serem
oferecidas pelo produto final.
Caso de Uso (RUP) Uma seqüência de ações que um sistema deve realizar
para apresentar um resultado de valor mensurável para o
usuário. (UML) Especificações de uma seqüência de ações,
incluindo suas variações, que um sistema (ou outra entidade)
pode realizar, interagindo com seus atores.
CMM Capability Maturity Model
36
Configuração Requisitos, projeto e implementação que definem uma
versão específica de um sistema ou componente.
Controle de mudança Atividade de controlar e rastrear as modificações aos
artefatos.
Escopo do produto (PMBOK 96) Aspectos e funções que devem ser incluídas
no produto ou serviço.
Escopo do projeto (PMBOK 96) Trabalho que deve ser feito com a finalidade
de entregar um produto de acordo com os aspectos e as
funções especificados.
Fase Espaço de tempo entre dois marcos significativos do projeto,
durante o qual objetivos são atingidos, artefatos elaborados e
decisões sobre passar ou não para a próxima fase são
tomadas.
Funcionalidade (feature) (RUP) Serviço oferecido por um sistema, observável
externamente, que satisfaz uma certa necessidade do
stakeholder.
Gerência de Configuração Processo de apoio cujo objetivo é identificar, definir e
estabelecer baselines de itens de configuração.
Itens de configuração Artefato de configuração que satisfaz uma função específica
e pode ser unicamente identificado em um determinado
momento de referência.
KPA Key Process Area (Área Chave do Processo)
Modelo Descrição completa de um sistema sob determinada
perspectiva (por completa entenda-se que não é necessária
nenhuma outra informação para a compreensão daquela
perspectiva do sistema).
Papel Definição de comportamento e responsabilidades de um
indivíduo ou grupo de indivíduos trabalhando juntos como
uma equipe, no contexto de uma organização de engenharia
37
de software.
Processo Conjunto de passos relativamente ordenados executados com
a intenção de se atingir um objetivo.
Produto Software resultante do desenvolvimento de alguns dos
artefatos relacionados (documentação, material de
treinamento, etc.).
Projeto (UML) Parte do processo de desenvolvimento de software
em que o principal objetivo é decidir como o sistema será
implementado.
Release Todo ou parte do produto final, objetivo de avaliação ao
final de uma fase do processo de desenvolvimento. É
composto por uma versão estável e executável do produto,
junto com os artefatos necessários à sua utilização, podendo
ser interna ou externa.
Repositório (UML) Local de armazenamento de documentos, modelos,
interfaces e implementações.
Requisição de mudança Termo utilizado para qualquer solicitação de alteração em
um artefato por um stakeholder do projeto. As informações
de uma solicitação de mudança podem ser documentadas no
artefato Requisição de Mudança.
RUP Rational Unified Process (Processo Unificado Rational).
Stakeholder Indivíduo afetado materialmente pelo resultado do sistema.
Template Gabarito. Estrutura pré-definida para um artefato.
UML Unified Modeling Language (Linguagem de Modelagem
Unificada). Linguagem para visualizar, especificar, construir
e documentar artefatos de um sistema de software.
Visão Ponto de vista do cliente ou usuário do produto a ser
desenvolvido, especificada no nível de necessidades do
usuário e funcionalidades do sistema.
38
8. REFERÊNCIAS BIBLIOGRAFICAS
[1] PAULK, Mark C.et all. "Capability Maturity Model for Software, Version 1.1", Software Engineering Institute, CMU/SEI-93-TR-24, DTIC Number ADA263403, February 1993.
[2] PRESSMAN, R. S., Engenharia de Software, Makron Books, 1995.
[3] WESLEY Addison, The Capability Maturity Model – Guidelines for Improving the Software Process. The SEI Series in Software Engineering.
[4] KRUCHTEN, Philippe, Introdução ao RUP: Rational Unified Process, Ciência Moderna, April 2003.
9. BIBLIOGRAFIA
BURWICK Diane M., How to Implement The CMM. BPS Pubs.
FURLAN, José Davi: Melhorando a qualidade de software através do CMM. http://www.sucesusp.org.br/html/menuarti/artigos/artigo_jose_davi_furlan.html
WHITE Brian A., Software Configuration Management Strategies and Rational ClearCase. Addison-Wesley, April 2001.
10. APÊNDICES
Apêndice A – Template de Plano de Gerência de Configuração
Apêndice B – Template de Relatório de Balanço de Configuração
Apêndice C – Template de Release Notes
Apêndice D – Template de Formulário de Requisição de Mudança
