Gerência de Configuração de Software

Prévia do material em texto

Gerência de Configuração de Software
Evolução de Software sob Controle
Tecnologia para Gerência de Configuração de Software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
2 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Gerência de Configuração de Software
Autoria: Angelina A.A. C. P. de Oliveira – angelina.oliveira@iti.br
Francisco Formoso Primo – francisco.formoso@iti.br
Jorge Luiz da Cruz – jorge.cruz@iti.br
Wagner Roberto De Martino – wagner.de-martino@iti.br
Os autores pertencem à equipe técnica do Instituto Nacional de Tecnologia da Informação –
ITI, órgão do Ministério da Ciência e Tecnologia.
Última atualização: Junho/2001
Nenhuma parte desta apostila pode ser utilizada ou reproduzida, em qualquer meio ou forma,
seja mecânico ou eletrônico, fotocópia, gravação, ou outros, sem autorização, prévia, expressa
e específica dos autores.
ITI - Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
Via D. Pedro I (SP-65), Km 143.6 – Caixa Postal 6162
Fone: (019) 3746- 6000 Fax (019) 3746-6092
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
3
ÍNDICE
1 INTRODUÇÃO ..................................................................................................................................................7
1.1 PÚBLICO ALVO E OBJETIVOS .........................................................................................................................8
1.2 VISÃO GERAL DO TEXTO ...............................................................................................................................8
2 HISTÓRICO.....................................................................................................................................................11
3 MOTIVAÇÃO ..................................................................................................................................................15
3.1 O COMPUTADOR COMO UMA MÁQUINA DE USO GERAL ...............................................................................16
3.2 O SOFTWARE..............................................................................................................................................17
3.3 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE............................................................................................21
3.3.1 GCS: Custos & Benefícios .............................................................................................................22
3.3.2 Impedimentos à adoção de GCS.....................................................................................................22
3.3.3 GCS - Estado atual..........................................................................................................................23
4 CARACTERIZAÇÃO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE..................................25
4.1 CONCEITOS FUNDAMENTAIS.......................................................................................................................26
4.2 DESENVOLVIMENTO DE SOFTWARE COM CONFIGURAÇÕES-BASE ..............................................................27
4.3 DISTRIBUIÇÕES...........................................................................................................................................34
4.4 DEFINIÇÃO FORMAL DE GCS ......................................................................................................................35
4.5 ATIVIDADES DE GCS..................................................................................................................................35
4.5.1 Identificação de configuração.........................................................................................................36
4.5.2 Controle de configuração................................................................................................................36
4.5.3 Administração de estado.................................................................................................................38
4.5.4 Auditagem de configuração ............................................................................................................39
4.6 ELEMENTOS ORGANIZACIONAIS DE GCS ....................................................................................................39
5 CONTROLE DE VERSÕES ...........................................................................................................................43
5.1 DESENVOLVIMENTO EM PARALELO ............................................................................................................45
5.2 OPERAÇÕES DE ACESSO ..............................................................................................................................46
5.3 AGREGAÇÕES .............................................................................................................................................48
5.4 DESENVOLVIMENTO DE SOFTWARE COM CONTROLE DE VERSÕES .............................................................49
5.5 CONCLUSÕES SOBRE CONTROLE DE VERSÕES ............................................................................................52
6 FERRAMENTAS DE GCS .............................................................................................................................53
6.1 CRITÉRIOS PARA AVALIAR UMA FERRAMENTA DE GERÊNCIA DE CONFIGURAÇÃO......................................53
6.1.1 Suporte a equipe de desenvolvimento.............................................................................................53
6.1.2 Suporte a desenvolvimento remoto.................................................................................................53
6.1.3 Suporte a configurações..................................................................................................................54
6.1.4 Suporte a gerência de mudanças.....................................................................................................54
6.1.5 Suporte de “build” e de distribuição de produto .............................................................................54
6.1.6 Suporte de processo ........................................................................................................................54
6.1.7 Usabilidade .....................................................................................................................................54
6.1.8 Facilidade de “set-up”.....................................................................................................................54
6.1.9 Personalização ................................................................................................................................54
6.2 CLASSIFICAÇÃO DAS FERRAMENTAS DE GCS .............................................................................................54
6.2.1 Ferramentas de controle de versões ................................................................................................55
6.2.2 Ferramentas orientadas ao desenvolvedor ......................................................................................55
6.2.3 Ferramentas orientadas a processo .................................................................................................55
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Nota
1 a 7 prova N1nullGCS
PabloHenrique
Realce
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
4 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Softwaresob Controle
6.3 ESTUDOS DE CASO ......................................................................................................................................55
6.3.1 Análise da ferramenta Source Integrity ..........................................................................................56
6.3.1.1 Suporte a equipe de desenvolvimento..............................................................................................56
6.3.1.2 Desenvolvimento remoto.................................................................................................................56
6.3.1.3 Gerenciamento de configuração ......................................................................................................57
6.3.1.4 Gerenciamento de modificação........................................................................................................57
6.3.1.5 Suporte a geração de distribuição de um produto ............................................................................57
6.3.1.6 Gerenciamento de processo .............................................................................................................57
6.3.1.7 Usabilidade ......................................................................................................................................58
6.3.1.8 Facilidade de configuração inicial ...................................................................................................58
6.3.1.9 Personalização .................................................................................................................................58
6.3.2 Análise da ferramenta Visual Source Safe ......................................................................................58
6.3.2.1 Suporte a equipe de desenvolvimento..............................................................................................58
6.3.2.2 Desenvolvimento remoto.................................................................................................................59
6.3.2.3 Gerenciamento de configuração ......................................................................................................59
6.3.2.4 Gerenciamento de modificação........................................................................................................59
6.3.2.5 Suporte a geração de distribuição de um produto ............................................................................59
6.3.2.6 Gerenciamento de processo .............................................................................................................59
6.3.2.7 Usabilidade ......................................................................................................................................59
6.3.2.8 Facilidade de configuração inicial ...................................................................................................60
6.3.2.9 Personalização .................................................................................................................................60
7 NORMAS E PADRÕES...................................................................................................................................61
7.1 IEEE...........................................................................................................................................................61
7.2 ISO/IEC .....................................................................................................................................................61
7.3 SEI-CMU...................................................................................................................................................63
7.3.1 O Processo de GCS segundo o modelo CMM................................................................................67
7.4 INICIATIVAS NO BRASIL..............................................................................................................................69
8 IMPLEMENTAÇÃO DE GCS........................................................................................................................71
9 EXEMPLO DE APLICAÇÃO: GCS PARA PEQUENAS EMPRESAS ....................................................73
9.1 INTRODUÇÃO ..............................................................................................................................................73
9.2 CARACTERIZAÇÃO DO PROBLEMA..............................................................................................................73
9.3 ESTRATÉGIA DE ABORDAGEM ....................................................................................................................73
9.4 O PLANO DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE .......................................................................74
9.5 RESULTADOS OBTIDOS ...............................................................................................................................78
10 EXEMPLO DE APLICAÇÃO: O MODELO NASA DE GCS ....................................................................79
10.1 DEFINIÇÃO..................................................................................................................................................79
10.2 FUNÇÕES DE GCS.......................................................................................................................................79
10.3 CONCEITOS BÁSICOS...................................................................................................................................79
10.4 ESTRUTURA ORGANIZACIONAL DE GCS .....................................................................................................80
10.5 CICLO DE VIDA...........................................................................................................................................81
10.5.1 Fase Conceito e Iniciação ...............................................................................................................81
10.5.2 Fase Requisitos ...............................................................................................................................82
10.5.3 Fase Arquitetura .............................................................................................................................82
10.5.4 Fase Projeto Detalhado ...................................................................................................................83
10.5.5 Fase Implementação .......................................................................................................................83
10.5.6 Fase Integração e Teste...................................................................................................................84
10.5.7 Fase Aceitação e Entrega................................................................................................................84
10.5.8 Fase Operação e Manutenção .........................................................................................................85
11 CONCLUSÃO ..................................................................................................................................................87
APÊNDICE A - PLANO DE GERÊNCIA DE CONFIGURAÇÃO DO PROJETO SW_CRIT ....................89
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
5
1 INTRODUÇÃO ................................................................................................................................................90
1.1 OBJETIVOS..................................................................................................................................................90
1.2 ESCOPO.......................................................................................................................................................901.3 DEFINIÇÕES E MNEMÔNICOS .......................................................................................................................91
1.3.1 Definições.......................................................................................................................................91
1.3.2 Mnemônicos ...................................................................................................................................91
1.4 REFERÊNCIAS ............................................................................................................................... ..............92
2 GERÊNCIA ...................................................................................................................... ................................93
2.1 ORGANIZAÇÃO ...........................................................................................................................................93
2.2 RESPONSABILIDADES DE GCS ....................................................................................................................93
2.2.1 Identificação da Configuração ........................................................................................................94
2.2.1.1 Configurações-Base .........................................................................................................................94
2.2.1.2 Liberações (Releases) ......................................................................................................................94
2.2.1.3 Documentação .................................................................................................................................95
2.2.2 Controle da Configuração...............................................................................................................95
2.2.2.1 Requisição de Modificação de Software/Sistema (RMS) ................................................................95
2.2.2.2 Autorização para Modificação de Software (AMS).........................................................................95
2.2.3 Administração de Estado ................................................................................................................95
2.2.4 Auditagens ......................................................................................................................................95
2.2.4.1 Auditagem de GQS..........................................................................................................................95
2.2.5 Comitê de Controle de Configuração (CCC)..................................................................................96
2.3 POLÍTICAS, DIRETIVAS E PROCEDIMENTOS APLICÁVEIS.............................................................................96
3 ATIVIDADES DE GCS ...................................................................................................................................97
3.1 IDENTIFICAÇÃO DE CONFIGURAÇÃO............................................................................................................97
3.1.1 Configurações-Base........................................................................................................................97
3.1.1.1 Configuração-Base Funcional..........................................................................................................97
3.1.1.2 Configuração-Base de Alocação......................................................................................................97
3.1.1.3 Configuração-Base de Projeto Básico..............................................................................................97
3.1.1.4 Configuração-Base de Projeto Detalhado ........................................................................................98
3.1.1.5 Configuração-Base de Código ............................................................................................. ............98
3.1.1.6 Configuração-Base de Produto ............................................................................................ ............98
3.1.2 Documentação ................................................................................................................................98
3.1.3 Partes do software...........................................................................................................................99
3.2 CONTROLE DE CONFIGURAÇÃO...................................................................................................................99
3.2.1 Função do Comitê de Controle da Configuração..........................................................................100
3.2.2 Requisição de Modificação de Software/Sistema (RMS).............................................................100
3.2.3 Autorização de Modificação de Software (AMS).........................................................................100
3.2.4 Ferramentas automatizadas de GCS para controle de modificações............................................101
3.3 ADMINISTRAÇÃO DE ESTADO ...................................................................................................................101
3.4 AUDITAGENS E REVISÕES DE CONFIGURAÇÃO..........................................................................................102
3.4.1 Auditagem Funcional de Configuração (FCA).............................................................................102
3.4.2 Auditagem Física de Configuração (PCA) ...................................................................................102
3.4.3 Revisões........................................................................................................................................102
3.5 CONTROLE DE INTERFACES.......................................................................................................................102
3.6 CONTROLE DE FORNECEDORES E SUBCONTRATADOS...............................................................................103
3.6.1 Software adquirido de fornecedor.................................................................................................103
3.6.2 Software subcontratado ................................................................................................................103
3.6.3 Auditagem de software de fornecedor e de subcontratado ...........................................................103
4 IMPLANTAÇÃO ...........................................................................................................................................104
4.1 COMITÊ DE CONTROLE DA CONFIGURAÇÃO .............................................................................................104
4.2 ESTABELECIMENTO DE CONFIGURAÇÕES-BASE........................................................................................104
4.3 ESCALONAMENTO E PROCEDIMENTOS PARA REVISÕES E AUDITAGENS DE GCS........................................104
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
6 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
4.4 RETENÇÃO................................................................................................................................................104
5 RECURSOS ....................................................................................................................................................105
5.1 RECURSOS HUMANOS...............................................................................................................................105
5.2 FERRAMENTAS DE GERÊNCIA DE CONFIGURAÇÃO....................................................................................105
6 MANUTENÇÃO DO PLANO.......................................................................................................................107
Anexo 1: Requisição de Modificação de Sistema/Software -RMS ..................................................................108
Anexo 2: Autorização de Modificação de Software - AMS ..............................................................................109
Anexo 3: Procedimento para controle de modificações no software/documentação......................................110
APÊNDICE B - REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................111
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
7
1 INTRODUÇÃO
Este texto trata de mudanças. Mudanças acontecem praticamente em tudo: as coisas, as
pessoas, o ambiente, tudo muda com maior ou menor freqüência. Particularmente, aqui,
estamos interessados em focalizar as mudanças que ocorrem nos produtos de software durante
todo o seu ciclo de vida.
Nos produtos de software mudanças são intrínsecas, fundamentais e inevitáveis. Este é um fato
que possui os seus aspectos positivos e negativos. É graças às modificações que o produto se
concretiza e pode ser corrigido ou melhorado e é também devido às modificações que surgem
muitos problemas do software: as mudanças, quando aplicadas sem critério, podem levar à
perda de controle do produto e, como conseqüência, comprometer sua integridade e qualidade.
Neste texto procurou-se:
• realçar a necessidade de controlar sistematicamente as mudanças nos produtos de
software;
• mostrar como acomodar e facilitar a realização de mudanças nos produtos;
• indicar como evitar que as mudanças não desviem os produtos de seus projetos originais;
• apontar como fazer com que as mudanças não comprometam a qualidade do produto
final.
Em suma, disseminar práticas para o desenvolvimento de software de forma sistemática, segura
e controlada objetivando sempre produtos da melhor qualidade.
Gerência de Configuração de Software (GCS) é uma disciplina de natureza técnica e
gerencial que objetiva facilitar o desenvolvimento de software e, ao mesmo tempo, garantir a
sua integridade. Tais objetivos são perseguidos basicamente através de controle sistemático
sobre as modificações pelas quais passa o produto desde a sua concepção até a sua desativação.
Para que se aplique GCS é fundamental:
• identificar aquilo que se pretende controlar;
• definir o controle a ser estabelecido;
• verificar que as modificações sejam implementadas de acordo com o especificado;
• manter um registro que permita aos interessados a obtenção de informações do estado em
que se encontrem os itens sob controle.
Tais tópicos são examinados com detalhes no decorrer deste texto.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
8 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
1.1 Público alvo e objetivos
Este texto é destinado às pessoas que lidam com software em geral: profissionais de
informática, desenvolvedores, gerentes, estudantes, interessados na aquisição de ferramentas de
GCS, pretendentes à certificados de qualidade, etc. Os objetivos principais do texto são:
• apresentar os conceitos básicos de GCS e difundir suas práticas;
• fornecer subsídios para a elaboração de planos de GCS;
• apresentar as principais características de algumas ferramentas de GCS encontradas no
mercado.
Dessa forma acredita-se estar contribuindo para que os interessados possam melhorar os seus
processos de produção de software ou o de suas empresas.
Ressalve-se que o desenvolvimento de software é, em geral, uma tarefa complexa e não
existem fórmulas mágicas para resolver os vários problemas a ela relacionados. A solução
apontada pela GCS implica em melhorar o processo de desenvolvimento, mesmo que para
tanto tenha-se que estabelecer e respeitar regras e que haja um aumento no formalismo. GCS
nem sempre é uma disciplina simpática. Seu objetivo é, antes de tudo, preservar a integridade e
melhorar a qualidade dos produtos de software.
1.2 Visão geral do texto
Este texto encontra-se dividido em capítulos numerados de 1 a 11 e dois apêndices.
No capítulo 1 é apresentada uma introdução ao texto e à sua organização.
No capítulo 2 é apresentado um breve histórico de GCS, sua origem dentro das engenharias,
sua aplicação ao hardware e a conseqüente migração e adaptação para o software.
No capítulo 3 são apresentados os motivos ou argumentos que justificam um estudo mais
aprofundado do tema GCS, sua atualidade e relevância.
No capítulo 4 são abordados os aspectos conceituais de GCS e detalhados os seus processos
principais.
No capítulo 5 são abordados alguns aspectos importantes da implementação prática de GCS: o
controle de versões e a incorporação de alguns conceitos de GCS a projetos já desenvolvidos
ou em desenvolvimento.
No capítulo 6 é abordado o assunto “Ferramentas de GCS”: uma classificação segundo as suas
características funcionais, alguns critérios para avaliação e estudos de caso de ferramentas
atualmente encontradas no mercado, suas características e limitações.
No capítulo 7 é feito um apanhado geral sobre o estado atual das Normas e Padrões de GCS.
No capítulo 8 são feitas algumas considerações sobre planejamento de GCS.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
9
Nos capítulos 9 e 10 são apresentados dois exemplos de aplicação de GCS, um mostrando GCS
numa empresa de pequeno porte e outro mostrando o modelo de uma grande organização, a
NASA.
No capítulo 11 é feita a conclusão do texto, uma visão critica sobre o texto e o tema abordado.
Permeando os capítulos do texto é utilizado como exemplo a implementação de GCS num
projeto de software hipotético SW_CRIT. Procurou-se focalizar as situações mais comuns e
que possam ser encontradas em projetos reais de software. O apêndice A apresenta o plano de
gerência de configuração para esse projeto hipotético que é baseado no documento ANSI/IEEE
Std 1042-1987.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
11
2 HISTÓRICO
A necessidade de uma disciplina para identificar e controlar o projeto de equipamentos
complexos e a comunicação das informações relacionadas foi mais aparente na indústria de
defesa dos EUA onde a alta qualidade do produto era um pressuposto. Assim, o histórico da
disciplina gerência de configuração muito deve aos esforços dos organismos governamentais
norte-americanos, especialmente os de defesa, e em particular aos esforços de padronização na
área de engenharia.
Até o final da 2a Guerra Mundial, os projetos de engenharia não eram muito complexos. Num
projeto, as atividades de desenvolvimento, de acompanhamento e de suporte eram todas
realizadas sem grandes problemas pelo mesmo grupo de pessoas, em geral um engenheiro e
alguns técnicos que o auxiliavam.
Após a Grande Guerra, a complexidade dos equipamentos aumentou de maneira espantosa,
como também aumentou a velocidade com que estes equipamentos eram substituídos por
outros ainda mais complexos. Como resultado, tanto a constituição das equipes de
desenvolvimento como a forma como trabalhavam não conseguiam suportar as novas
exigências dos desenvolvimentos. Equipes que costumavam ser compostas por um engenheiro
experiente e cinco técnicos, passaram a ser integradas por cinco engenheiros e um bom técnico,
todos os seis realizando o mesmo tipo de trabalho. Os produtos, por sua complexidade e
rapidez de evolução, exigiam mais atenção quanto ao controle de sua evolução.
Atividades de gerência de configuração (GC) principiaram nesta época no seio da indústria de
defesa norte-americanaagrupadas em torno de técnicas gerenciais para resolver problemas de
baixa qualidade. O termo Configuration Management (Gerência de Configuração) foi
formalmente estabelecido neste contexto, assim como vários outros conceitos tecnológicos.
O primeiro trabalho de sistematização da área aparece com a publicação, pela força aérea
americana, da norma AFSCM 375-1 Configuration Management. Este trabalho significou um
marco de mudança na forma como o desenvolvimento de projetos de engenharia eram
conduzidos, pelo menos no contexto das forças armadas americanas, pois estabeleceu de forma
clara a separação entre atividades de desenvolvimento de um produto e as atividades de
controle deste produto.
Esta norma disparou uma cascata de outros esforços de normalização nas organizações
militares norte-americanas. Estes esforços deram origem a diversas normas na década de 1960.
Em particular cinco documentos foram publicados em 1968 que definiam políticas e diretrizes
de GC e formalizavam as atividades básicas de identificação, controle e administração de
estado. Estes documentos foram: Directive 5010.19 Configuration Management, Instruction
5010.21 Configuration Mangement e as normas MIL STD 480 Engineering Changes,
Deviations, and Waivers, para as atividades de controle de configuração, MIL STD 482
Standard for Status Accounting, para as atividades de administração de estado, e MIL STD 490
Specification Practices para as atividades de identificação de configuração.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
12 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Em todos os esforços, no entanto, o desenvolvimento de software não possuía tratamento
específico. Software era considerado um apêndice do hardware.
O primeiro documento a reconhecer gerência de configuração tanto de hardware como de
software foi a norma MIL STD 483, Configuration Management Practices for Systems,
Equipment, Munitions, and Computer Programs, publicada por volta de 1971. Também neste
documento apareceu pela primeira vez um esboço de plano de GC.
Entretanto, foi com o início do desenvolvimento de normas específicas para o desenvolvimento
de software que a constituição da disciplina GCS realmente tomou impulso. No final da década
de 70 surgiu a norma MIL STD 1679 Weapon System Software Development (Dezembro de
1978) e nos anos de 1979 e 1981 foram realizadas 2 conferências de software em
Monterey/Califórnia (Monterey I e Monterey II). Uma das principais resoluções dessas
conferências foi a determinação de se criar um padrão universal para desenvolvimento de
software.
Este projeto ambicioso consolidou-se na norma DOD STD 2167 Defense System Software
Development publicada em 1985, após um período de desenvolvimento bastante turbulento.
Sua publicação foi realizada já com provisão de início de trabalho de revisão para resolver
questões abertas. Esta norma, por outro lado, significou um grande avanço nos conceitos de
GCS principalmente com a introdução do conceito de configuração-base (baseline), que
organizava GCS em termos das fases do ciclo de vida.
Por volta de 1988, o governo americano anunciou sua intenção de sair da arena de elaboração
ativa de normas e o interesse em fomentar os trabalhos de normalização das associações da
indústria, tais como IEEE, ANSI e EIA.
A partir desta época, a evolução de GCS passou para entidades ligadas a indústria e
universidade, ainda que com uma grande participação de organismos governamentais norte-
americanos, especialmente as organizações militares e de defesa.
A IEEE em seus esforços de elaboração de normas para a área de engenharia de software,
publicou duas normas enfocando especificamente a questão de elaboração de planos de GCS:
as normas IEEE Std 828-1998 Software Configurations Management Plans e IEEE Std 1042-
1987 Guide to Software Configuration Management. Estas normas, principalmente a IEEE Std
828, são bastante adotadas no cenário internacional como referência para a elaboração de
planos de GCS.
Adicionalmente, o lançamento nos anos 90 do Capability Maturity Model (CMM), pelo
Software Engineering Institute da Carnegie Mellon University, realçou ainda mais a
importância da disciplina GCS ao identificá-la como um dos processos-chave de um processo
de software de qualidade.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
13
No cenário internacional, foi formado na década de 90 o comitê conjunto JTC1 (Joint
Technical Committee 1) unificando os esforços de elaboração de normas na área de tecnologia
da informação das duas maiores entidades internacionais de padronização a ISO (International
Organization for Standardization) e a IEC (International Electrotechnical Commission). Sob a
égide do JTC1 foi produzida a norma ISO/IEC 12207:1995 Information technology -- Software
life cycle processes, que define uma estrutura de processos para o processo de software. Neste
modelo, é estabelecido o processo de GCS como um dos processos de apoio ao
desenvolvimento de software. A partir desta norma foi produzido o relatório técnico ISO/IEC
TR 15846:1998 Information technology -- Software life cycle processes -- Configuration
Management que procura desenvolver a caracterização resumida de GCS definida na ISO/IEC
12207.
Atualmente percebe-se um interesse crescente por GCS. Este interesse pode ser atribuído em
grande parte à busca por certificações de qualidade como ISO 9000 ou nível de maturidade de
acordo com o CMM, mas é também devido às necessidades colocadas pela competição do
mercado que, cada vez mais, exige qualidade.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
15
3 MOTIVAÇÃO
O desenvolvimento de software é uma das atividades mais criativas e também das mais
desafiadoras para o profissional de informática. Aplicações de software são encontradas em
todos os setores de atividade humana, desde as mais elementares até as mais complexas. De
maneira geral, desenvolver software não é uma tarefa trivial mas os resultados compensam os
esforços. A demanda continua crescente e um bom profissional de software tem seu lugar
garantido no mercado de trabalho atual.
O aumento da utilização e da demanda, no entanto, implica na necessidade de produtos mais
confiáveis, mais fáceis de usar e de melhor qualidade. Desenvolver software deixou de ser uma
tarefa de artesãos, de principiantes ou de amadores. Para atender o mercado é necessária uma
produção em larga escala, eficiente e confiável. Hoje em dia, por trás do desenvolvimento de
software, há todo um processo.
É inquestionável a presença e a importância dos computadores no nosso dia a dia. Raros são os
indivíduos cuja vida passe ao largo dessa máquina ou que não sejam influenciados pela mesma.
O envolvimento na maioria das vezes é compulsório. Não se pede, impõe-se o uso. Assim,
querendo ou não, fomos todos transformados em usuários de computador. Isso é um fato!
Para uma grande parcela de usuários não interessa nada saber detalhes técnicos sobre o
computador, o que é, como funciona. São assuntos sem relevância. O importante para esse tipo
de usuário são as funcionalidades oferecidas pelo computador e a qualidade e eficiência dos
serviços prestados.
Existe, porém, uma parcela de usuários de computador para os quais são imprescindíveis
conhecimentos técnicos sobre o assunto num grau de maior ou menor profundidade.
?
GCS
Controle de
Versões
ISO 9000
CMM
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
16 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
3.1O computador como uma máquina de uso geral
O computador é uma máquina de uso geral especializada em processamento de dados. É, sem
dúvida, um dos principais produtos tecnológicos do século XX. Surgida há cerca de 50 anos,
evoluiu de forma extraordinária e aos poucos foi se entranhando no dia a dia das pessoas.
Um sistema de computação é constituído por dois componentes principais: o hardware e o
software. Um terceiro componente, o firmware, pode aparecer também e é um misto dos outros
dois. A figura 3.1 ilustra um sistema de computação típico.
Figura 3.1 - Sistemas de Computação
Os computadores encontram-se, hoje em dia, nos mais diversos tipos e tamanhos com
aplicações em praticamente todas as áreas de atividade humana.
O hardware do computador envolve todos os componentes físicos do sistema: CPU, teclado,
mouse, vídeo, fontes de alimentação, etc. Esse hardware possui algumas habilidades especiais
tais como fazer operações lógicas e aritméticas de uma forma muito eficiente: sem errar e num
tempo muito pequeno. Tais habilidades, quando manipuladas convenientemente, podem ser
muito úteis na solução de alguns problemas. O hardware representa a capacidade de trabalho
bruto da máquina.
Também fazem parte do hardware os dispositivos periféricos utilizados na comunicação com
os usuários: pessoas ou outras máquinas. Nesta categoria encontram-se as impressoras,
modems, discos, etc. A gerência de configuração nos seus primórdios aplicava-se
principalmente ao hardware.
A parte inteligente do sistema, aquela que explora os recursos do hardware com uma finalidade
prática e específica constitui o chamado software.
Os primeiros computadores eram operados através de chaves e alavancas que dificultavam e
limitavam muito o seu uso. No final da década de 40 John Von Neumann introduziu o
conceito de programa armazenado e o computador passou a ser uma máquina controlada
através de programas o que indiscutivelmente ampliou as suas possibilidades. O software é
constituído por programas de computador e por estruturas de dados.
Sistemas de ComputaçãoSistemas de Computação
Hardware
F
i
r
m
w
a
r
e
Software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
17
Os programas são seqüências de instruções que a máquina executa com alguma finalidade
determinada pelo autor do programa. As estruturas de dados representam as informações que
devem ser processadas mapeando elementos do contexto da aplicação para o contexto da
máquina.
O terceiro componente de um sistema de computação, o firmware, é uma combinação de
dispositivos de hardware e de software residente em ROM e que não pode ser modificado por
programa.
3.2 O Software
O software é, sem dúvida, o componente mais importante do computador. É principalmente
devido ao software que o computador ganha o status de máquina de uso geral: um mesmo
hardware desempenhando funções diversas.
Durante o seu ciclo de vida o software apresenta-se sob diversos formatos ou representações.
Iniciando um processo de desenvolvimento há sempre uma necessidade ou problema
apresentado por uma pessoa ou organização e o analista ou programador propõe uma solução
que envolve o desenvolvimento de um determinado software. Nesse ponto o software é um
conceito e a partir daí evolui para diversas outras formas até tornar-se um código que,
executado pela máquina, satisfaz as necessidades do usuário.
A figura 3.2 ilustra o processo de desenvolvimento do software:
Figura 3.2 - Evolução dos Sistemas de Software
Convém notar que o software, partindo de uma idéia até chegar a um código que a máquina
entenda e execute, necessariamente deve passar por diversas representações que se efetivam
através de transformações.
Uma característica das mais importantes do software é que ele é passível de modificações. As
modificações são necessárias para o desenvolvimento propriamente dito: modificações para a
correção de erros e modificações para a melhoria ou aprimoramento do software. Apenas
quando um software é desativado ele não sofre mais modificações.
Necessidade
Idéia
Formulação
de Conceitos
SISTEMA
Construção
Necessidade
Satisfeita
Projeto
HW SW SW
 
SISTEMA
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
18 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Em muitas aplicações o software é um elemento crítico. Um erro ou defeito pode acarretar a
perda de grandes quantidades de dinheiro e, pior, pode custar a vida de pessoas. Como
exemplos desse tipo de software podemos citar programas de controle de aeronaves,
monitoramento de pacientes, controle de metrôs e trens, radares, etc. É de vital importância que
os projetistas e programadores tenham consciência do papel que desempenham.
Se é incontestável a importância do software, é imprescindível que ele atenda a um mínimo
padrão de qualidade. Diversas são as exigências do mercado atual no quesito qualidade. Com o
aumento na oferta, o consumidor de software torna-se cada vez mais exigente e os certificados
de qualidade já fazem parte dos requisitos para se adquirir, ou não, determinado produto de
software. Isso leva os fornecedores a se preocuparem cada vez mais com tais certificados para
os seus produtos.
No desenvolvimento de um software de qualidade é fundamental não descuidar de nenhum dos
seguintes aspectos:
• Técnicos: Utilização de metodologias atualizadas, bons algoritmos, estruturas de dados
adequadas, etc.
• Gerenciais: Planejamento e acompanhamento das atividades de desenvolvimento,
controle e administração dos recursos, etc.
• Suporte ao desenvolvimento: Estabelecimento de processos de apoio adequados às
atividades de desenvolvimento, tais como: documentação, gerência de configuração de
software, verificação e validação, mecanismos de revisão e outros.
No entanto, como tendência geral, observam-se uma grande ênfase nos aspectos técnicos e uma
negligência, também grande com respeito aos aspectos gerenciais e de suporte. Uma expressão
poderia resumir esta tendência: Tecnologia é tudo.
Entretanto, após algumas décadas de grande esforço e elaboração em tecnologia, de novas
linguagens de programação e de representação de conhecimento, de ambientes de
desenvolvimento cada vez mais sofisticados, de ferramentas CASE, de tecnologia de bancos de
dados cada vez mais avançada, de novos paradigmas, tais como orientação a objetos, entre
outros, o que se vê são projetos que continuam com atrasos sistemáticos e estouros de
orçamento. Continua sendo muito comum, quase a regra, a “Lei dos 90%” que pode ser
enunciada da seguinte forma:
“90% do desenvolvimento de um produto ou sistema de software é realizado nos
10% iniciais do tempo total. Os 10% restantes tomam os 90% finais do tempo”
Além do fato de a engenharia de software ser uma área nova em que a abordagem
metodológica ainda não está totalmente resolvida, como no caso das outras engenharias mais
tradicionais e maduras, este resultado frustrante, identificado em [CMM 93] vem do fato de ser
praticamente impossível obterem-se os benefícios de melhores métodos e tecnologia no
turbilhão de projetos não disciplinados e impropriamente gerenciados. O problema
fundamental é a inabilidade de se gerenciar o processo de software.
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
19
Outro ponto é que ainda hoje existem profissionais que vêem o desenvolvimentode software
como sendo uma arte em vez de uma ciência. A complexidade das aplicações, a
disponibilidade de ferramentas, os prazos estabelecidos para a entrega, a produção em larga
escala, tudo isso exige uma abordagem profissional e sistemática para o processo de produção
de software.
Devido ao software ser de natureza intangível, complexa e muito sujeita a modificações o seu
desenvolvimento não é tarefa trivial. Ela envolve riscos e a probalidade de um projeto de
software ser abandonado antes de seu término é grande, principalmente nos projetos maiores a
figura 3.3 ilustra essa afirmativa:
Figura 3.3 - Projetos de software concluídos X Complexidade
Os projetos considerados tiveram a sua complexidade medida em termos de pontos de função
(FP) e o que pode ser observado é que quanto maior a complexidade do projeto maior a sua
chance de ser concluído com atraso ou simplesmente abandonado. Levando-se em conta que o
desenvolvimento de software é uma atividade cara para as empresas o abandono de grandes
projetos acarretam grandes prejuízos.
Das realizações do ser humano, o software se destaca por três características que o colocam
num patamar de distinção: é intangível, é altamente complexo e é facilmente modificável.
Adicionalmente, este conjunto de características acarreta um fenômeno bastante conhecido
daqueles que lidam com software e que permeia todo o seu ciclo de vida: as modificações.
5
10
15
20
25
30
35
40
50
45
55
60
65
70
75
80
<100 >50001000-5000100-1000
 CANCELADOS
 ATRASOU > 12 meses
 ATRASOU > 6 meses
 NO PRAZO
 ANTES DO PRAZO
Tamanho de Software x PrazoTamanho de Software x Prazo
Capers Jones
Patterns of large software systems: Failure and success
IEEE Computer - March 1995
PabloHenrique
Realce
PabloHenrique
Realce
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
20 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
As modificações são intrínsecas ao software e diversas são suas origens: a identificação de
novos requisitos, a evolução do ambiente operacional, os avanços tecnológicos, a identificação
de novas maneiras de implementar funcionalidades, ou, ainda, uma das mais freqüentes, a
correção de defeitos. As modificações ocorrem, enfim, porque o conhecimento completo do
software, o que eqüivale a dizer do problema que ele deve resolver, raramente é obtido antes de
seu desenvolvimento. E é exatamente o conhecimento adicional, adquirido durante o
desenvolvimento, a grande força impulsionadora das mudanças no software.
Esta facilidade de modificação, em contrapartida, traz embutida o verdadeiro perigo: a
facilidade da perda de controle. Hoje em dia, com o crescimento da complexidade do software,
mais e mais percebe-se a dificuldade crescente dos produtores de software em fornecer
produtos íntegros em prazos razoáveis e com custos adequados. Se, por um lado, não se pode
atribuir a responsabilidade por este problema a um único fator, por outro, é evidente que o
controle inadequado das modificações é uma das causas mais cruciais. Todo desenvolvedor de
software já experimentou as conseqüências da perda de controle do software:
• Dificuldades imensas durante a integração dos diversos módulos para compor o produto,
por problemas de interface;
• Após uma modificação qualquer do produto de software, erros removidos anteriormente
reaparecem, ou então, funcionalidades acrescentadas desaparecem, inexplicavelmente;
• Dificuldades em se identificar a última versão do produto de software;
• Incapacidade de se reproduzir, no ambiente de desenvolvimento, um problema informado
pelo cliente;
• Perda dos arquivos-fonte que compõem o sistema distribuído a cliente.
Todas estas ocorrências, muito comuns, levam a altos custos de desenvolvimento, baixa
qualidade de produto e à insatisfação do cliente ou usuário final.
Tradicionalmente, as iniciativas de desenvolvimento de software preocupam-se quase
exclusivamente com os problemas técnicos, dedicando poucos recursos e tempo ao lado
gerencial e de suporte. Entretanto, tanto a demanda por produtos de software de complexidade
cada vez maior, como o aumento de competitividade advinda da globalização, impõem ao
desenvolvedor de software, especialmente o nacional, a necessidade de investir também nos
aspectos de controle de seus processos e produtos.
Diversos são os agentes interessados em mudanças no software:
• Clientes: interessados em modificar requisitos;
• Desenvolvedores: interessados em modificar detalhes técnicos;
• Gerentes: interessados em modificar a condução do projeto.
Ora, como quem compra, quem faz e quem administra têm interesse em modificações elas
tornam-se praticamente inevitáveis. Este fato por si só não é bom nem ruim. As modificações
são necessárias e se há alguma coisa de ruim é em decorrência da forma como as modificações
são efetuadas no software.
PabloHenrique
Realce
PabloHenrique
Nota
Conhecido também como BALBURDIA
PabloHenrique
Realce
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
21
3.3 Gerência de Configuração de Software
Gerência de Configuração de Software (GCS) é uma disciplina de apoio integrante do processo
de software que, de maneira sucinta, pode ser vista como uma abordagem sistemática ao
problema de controlar um produto de software.
Tal é a importância da gerência de configuração de software, que as principais iniciativas
internacionais de certificação de qualidade de processo de software: ISO 9000, CMM
(Capability Maturity Model) e SPICE (Software Process Improvement and Capability
Determination), exigem a implantação de um processo de gerência de configuração como
requisito indispensável para a obtenção de qualquer grau de certificação de qualidade.
GCS é, em geral, relacionada a iniciativas de desenvolvimento de software em que o processo
de desenvolvimento é bem definido, com atividades agrupadas em fases que possuem produtos
bem definidos e documentados. Neste contexto, GCS é a espinha dorsal sobre a qual as fases
do desenvolvimento são conduzidas e os produtos, tanto finais como intermediários,
controlados.
A realidade dos desenvolvedores nacionais de software, entretanto, é bem diferente. Boa parte
do software em nosso país é desenvolvido por pequenas empresas, com no máximo 10
funcionários, que lutam contra a escassez de recursos e as deficiências tecnológicas para
manter seus produtos no mercado. Por via de regra, o desenvolvimento de software é um
processo nebuloso, sem fases bem definidas. Especificação, projeto e codificação são
realizados de maneira entremeada. Testes, quando ocorrem, não são feitos de forma sistemática
e racional. A documentação é deficiente e, em geral, está sempre desatualizada. O resultado
final é um produto sempre em evolução, que passa por um processo contínuo de modificações
tanto para a incorporação de novas funcionalidades como para a correção de defeitos.
A Gerência de Configuração de Software propõe-se a minimizar os problemas surgidos durante
o ciclo de vida do software através de um controle sistemático sobre as modificações. Não é
objetivo da GCS coibir as modificações, pelo contrário, é facilitá-las. Procura-se apenas cuidar
que elas ocorram de forma sistemática e controlada para evitar, ou minimizar, as suas
decorrências negativas.
Cabe ressaltar aqui que a GCS não é uma panacéia para todos os problemas do software. É uma
disciplina de natureza técnica/gerencial que define responsabilidades e autoridades e é um
processo chave num ambiente de desenvolvimento de software de qualidade.
Um aspecto que gera uma certa confusão é estabelecer qual a diferença entre gerência de
configuração e manutenção.
Manutenção de software envolve atividadesde Engenharia de Software, desenvolvidas após a
entrega de um produto de software. A Gerência de Configuração de Software envolve
atividades de controle e de acompanhamento, desenvolvidas durante todo o ciclo de vida do
produto de software. São atividades distintas.
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Nota
Podemos notar que, GCS trata também de acompanhar o processo (ciclo de vida) auxiliando no controle de modificações do projeto em andamento... exemplo: TCC1 para TCC2 exigindo o minimo de modificação possível.
PabloHenrique
Realce
PabloHenrique
Realce
PabloHenrique
Nota
No entanto, como já discutido em sala, existe uma proposta não OFICIAL de integração da GCS a PMBOK para auxiliar o processo de continuação do software, mas isso sem ferir as 5 fases... para isso existe a ideia de criação de uma proposta de GCS onde pode ser acoplado ao projeto com proposito de diferencial
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
22 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
3.3.1 GCS: Custos & Benefícios
A adoção de GCS por uma empresa envolve, naturalmente, custos e benefícios que devem ser
considerados a priori.
Os principais benefícios decorrentes da aplicação de GCS são:
• facilidades para acomodar mudanças;
• maior controle sobre os produtos;
• economia de tempo de desenvolvimento;
• facilidades na geração de versões diferentes de um mesmo produto de software;
• manutenção de históricos de produtos;
• facilidades de se voltar a situações anteriores.
Quanto aos custos relacionados com a adoção de GCS por uma empresa serão necessários dois
tipos de investimentos:
• investimentos com a adoção, que envolvem capacitação (aquisição de informações,
consultorias, etc.) e treinamento (custos com treinamento de pessoal envolvido com a
adoção de GCS).
• investimentos para a implementação, que englobam recursos humanos (custos com
pessoal envolvido com a implementação de GCS), recursos computacionais
(computadores e dispositivos a serem utilizados pela GCS) e ferramentas de GCS
(ferramentas de software para automatizar o processo de GCS).
Investir em GCS é semelhante a se investir em seguros: custos e benefícios devem ser
avaliados criteriosamente. Não há solução ou fórmula prontas para resolver esta relação. O
quanto deve-se investir em GCS dependerá do tipo e valor do software a ser controlado e,
principalmente, de seu grau de criticalidade. Investimentos em GCS, em um software de metrô,
por exemplo, cuja falha pode causar de maneira irreversível perda de vidas ou de alguns
milhões de reais certamente será muito maior que investimento em GCS para um software de
automação de loja, ou mesmo de gestão empresarial cuja falha, ainda que danosa, pode
eventualmente ser reparada.
3.3.2 Impedimentos à adoção de GCS
A adoção de GCS sempre enfrenta impedimentos que, de uma forma ou de outra, precisam ser
superados. Dentre os motivos, podem-se destacar:
• Custos: É o principal empecilho. GCS implica em diversos gastos: com pessoal,
equipamentos, etc.;
• Cultura da empresa: Resistência das pessoas às mudanças, a falta de costume de seguir
regras ou padrões;
PabloHenrique
Realce
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
23
• Aumento na formalidade e burocracia: No geral, haverá procedimentos a serem
seguidos que podem implicar em preenchimentos de formulários, obtenção de
autorização, etc., coisas que em geral as pessoas não gostam muito de fazer;
• Falta de conhecimento do assunto: A implantação de GCS envolve todas as pessoas da
equipe do produto e nem todas possuem as mesmas informações sobre o assunto que
ainda é desconhecido para a maioria.
Entretanto, se, por um lado, fatores acima são importantes, por outro lado, o impedimento
maior, que realmente pode significar o fracasso de um empreendimento de implantação de
GCS, é ausência de comprometimento ou comprometimento insuficiente da gerência
superior da empresa. Sem comprometimento real é impossível superar as barreiras colocadas
pelos outros fatores.
3.3.3 GCS - Estado atual
A prática de GCS varia muito no cenário mundial. Em alguns países, como os Estados Unidos,
iniciativas a respeito foram tomadas principalmente por entidades governamentais (DoD,
NASA e outras). Como essas entidades são grandes compradoras de software elas impõem aos
seus fornecedores algumas regras ou normas que garantam uma certa qualidade aos produtos. É
um caso típico onde o mercado dita as regras. Tais práticas vão sendo disseminadas, com maior
ou menor rapidez para o restante do mundo.
A globalização atual faz exigências sobre os produtos comercializáveis tais como:
• facilidades para acomodar modificações;
• maior competitividade;
• maior controle de qualidade;
• obediência a normas e padrões.
Esforços consideráveis vem sendo feitos pelos países mais desenvolvidos em pesquisas e
implementação de ferramentas de GCS. Existe disponível no mercado uma grande variedade
de tais ferramentas as quais variam nos custos, potencialidades e complexidades.
No Brasil, o assunto ainda é um tanto desconhecido e não se desenvolvem ferramentas de GCS
para o mercado. Há um interesse crescente pelo assunto decorrente do aumento de
competitividade no mercado e da busca de algum certificado de qualidade como ISO 9000,
CMM, SPICE, etc.
Verifica-se também uma maior incidência do uso de GCS em empresas multinacionais ou de
grande porte.
No contexto da Engenharia de Software, GCS assume um papel de relevância, por estar
intimamente relacionada com a qualidade dos produtos de software e por facilitar:
• a comunicação sobre o estado de programas e documentos;
• a obtenção do estado das modificações;
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
24 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
• o gerenciamento corporativo em busca de uma maior produtividade por menor custo;
• o suporte de manutenção.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
25
4 CARACTERIZAÇÃO DE GERÊNCIA DE CONFIGURAÇÃO DE
SOFTWARE
O software durante o seu ciclo de vida passa por diversos estágios e representações. Quando da
sua concepção o software é um simples conceito, uma idéia de como resolver um determinado
problema. A partir daí a idéia toma forma: primeiro em especificações, projetos de estruturas,
modelos e simulações; depois evolui para programas e dados que se desenvolvem e se
modificam até um produto final que por sua vez também pode evoluir e evoluir até que seja
desativado.
O processo de desenvolvimento do software é contínuo no tempo, partindo de alguns conceitos
e mais alguns componentes iniciais que evoluem continuamente. O número de componentes,
via de regra, aumenta com o desenvolvimento. A figura 4.1 ilustra a evolução de um software.
Figura 4.1 - Evolução de um software
Na verdade, a figura acima é uma simplificação do processo, uma vez que, entre um estágio e
outro há muitos outros passos intermediários e os elementos estão sujeitos a contínuas
transformações de correção, aperfeiçoamento ou de evolução, como indica a figura 4.2.
Figura 4.2 - Evolução contínua de um software
Tempo
Tempo
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
26 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Durante o processo de desenvolvimento temos que a modificação é intrínseca, ou seja, faz
parte integrante do processo. Semmodificações o software não passaria do terreno das idéias.
Modificações são essenciais para o seu desenvolvimento. O inconveniente deste fato é que as
modificações podem acarretar a perda de controle do objeto de desenvolvimento. Isso implica
que as modificações devem ser aplicadas mediante certos critérios que permitam manter a
integridade do software.
Já que o processo de desenvolvimento de software evolui continuamente, o acompanhamento e
controle de todas as modificações é um problema complexo e de solução difícil. A questão que
se coloca é o que, quando e como controlar.
Para resolver estas questões, utiliza-se o conceito de configuração-base. Entretanto, antes de
introduzi-lo, vamos apresentar alguns conceitos fundamentais.
4.1 Conceitos Fundamentais
A seguir são apresentados alguns conceitos básicos que foram adotados neste texto.
Configuração de software: Características físicas e funcionais do software conforme
especificadas na documentação técnica ou encontradas no produto.
Itens de Configuração: Este é um dos conceitos mais importantes de GCS e também um dos
que acabam introduzindo mais confusão no entendimento do assunto. Essencialmente existem
duas definições para o termo. Numa visão simplificada de GCS, como a introduzida por
Pressman em [PRE 92], item de configuração (IC) pode ser caracterizado 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”
Nesta definição, tanto os documentos como os arquivos-fonte que compõem um produto de
software são ICs, assim como são ICs também as ferramentas de software necessárias para o
desenvolvimento do produto em questão, tal como, compiladores, ligadores, arquivos de lote
(batch), makefiles, etc.
Neste conceito, configuração pode ser vista como o conjunto de todos os documentos,
programas, itens de dados e componentes de suporte que compõem o software.
A definição mais abrangente de item de configuração é encontrada nos trabalhos de
normalização do governo norte-americano e em normas da indústria (IEEE, ANSI) que
resultaram destes esforços. Nesta visão, item de configuração é caracterizado como:
“Um agregado de hardware, software, ou ambos, que é designado para gerência de
configuração e que é tratado como uma unidade dentro do processo de gerência de
configuração.”
Se o item de configuração for composto exclusivamente de software, ele é caracterizado como
Item de Configuração de Software (ICSW).
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
27
Nesta definição, IC é uma unidade funcional que possui um ciclo de desenvolvimento e
acompanhamento de GCS próprios. Nesta visão, o sistema em desenvolvimento é particionado
em itens de configuração e o seu desenvolvimento é visto como o desenvolvimento de cada um
dos ICs. Cada IC, por sua vez pode ser particionado em outro conjunto de ICs e assim
sucessivamente, até que se resulte um conjunto de ICs não particionáveis, que são
desenvolvidos segundo um ciclo de vida propriamente definido.
Neste conceito, a configuração de um sistema de software é o conjunto das configurações dos
ICSWs integrantes do sistema.
É importante salientar que a divisão de um sistema ou produto de software em ICs e a
definição do ciclo de vida de cada IC final é uma decisão de projeto e não de GCS.
Neste curso, para simplificação da exposição, a sigla IC, exceto quando explicitamente
indicado, referir-se-á à visão simplificada do conceito, enquanto que ICSW sempre implicará a
visão mais abrangente de uma unidade funcional, integrante de um sistema maior, constituída
exclusivamente de software.
Configurações-Base (Baselines): Por configuração-base entendemos um conjunto bem
definido de itens de configuração que representam um estágio do desenvolvimento e que é
passível de modificações apenas mediante um mecanismo formal de alterações. A figura 4.3
ilustra a evolução da configuração do software.
Figura 4.3 - Evolução da Configuração do Software
4.2 Desenvolvimento de Software com Configurações-Base
Em princípio, configurações-base poderiam ser estabelecidas em qualquer ponto do
desenvolvimento. Entretanto, a grande vantagem do conceito está em se fazer coincidir o
estabelecimento de configurações-base com os finais de fase do ciclo de vida do produto.
O desenvolvimento com configurações-base pode, então, ser resumido nos seguintes pontos:
• Caracterização do ciclo de vida, identificando-se as fases por que o desenvolvimento do
software irá passar e dentro delas as atividades a serem realizadas e os produtos a serem
desenvolvidos;
Configuração-base
do Software
Documentos
Programas
Dados
Desenvolvimento de novos itens 
Documentos
Programas
Dados
Nova Configuração-base
do Software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
28 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
• Definição do conjunto de configurações-base. Para cada configuração-base planejada,
deve-se estabelecer quais serão os ICs que a irão compor e quais as condições impostas
para seu estabelecimento;
• Configurações-base representam marcos no processo de desenvolvimento: uma nova
configuração-base é estabelecida no final de cada fase do ciclo de vida do software;
• Durante cada fase, o desenvolvimento dos ICs a ela referentes está sob total controle de
seus desenvolvedores e realiza-se com ampla liberdade, podendo os ICs serem criados e
modificados com bastante facilidade;
• Durante cada fase, entretanto, a modificação de uma configuração-base anteriormente
estabelecida somente pode ser feita de forma controlada, mediante um processo bem
definido;
• Ao ser estabelecida, cada configuração-base incorpora integralmente a configuração-base
anterior. Desta forma, em qualquer instante do desenvolvimento, a última configuração-
base estabelecida representa o estado oficial da totalidade do desenvolvimento;
• O estabelecimento de cada configuração-base somente é realizado após ser aprovada por
procedimentos de consistência interna, verificação e validação.
Como ilustração, vamos aplicar o esquema acima no desenvolvimento de um produto de
software hipotético.
Em primeiro lugar, define-se um ciclo de vida convencional para o produto (“cascata”),
incluindo tanto o desenvolvimento como a manutenção, constituído das seguintes fases:
Análise de Requisitos, Projeto de Software, Codificação, Teste e Integração e
Manutenção. Este modelo será a base para a definição das configurações-base. A figura 4.4
ilustra a caracterização inicial do desenvolvimento.
Figura 4.4 - Desenvolvimento do software & Estabelecimento de configurações-base
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Estabelecimento das Configurações-Base
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
29
Em seguida, com base neste ciclo de vida, definem-se as configurações-base, que serão:
Configuração-Base de Requisitos, Configuração-Base de Projeto, Configuração-Base de
Código. Estas configurações-base serão estabelecidas, respectivamente, ao final das fases
Análise de Requisitos, Projeto de Software, Codificação e Teste e Integração. A figura 4.5
ilustra a situação do produto de software com as citadas configurações-base. Nesse ponto as
configurações-base estão definidas, bem como estão definidos os elementos que as irão
constituir e as respectivas condições para o seu estabelecimento.
Figura 4.5 - O desenvolvimento do software no seuinício
Os ICs que irão constituir a primeira configuração-base passam então a ser desenvolvidos. A
figura 4.6 ilustra essa etapa do desenvolvimento durante a qual o desenvolvedor possui total
liberdade com respeito aos ICs que estiver desenvolvendo, isto é, pode modificá-los à vontade
uma vez que configuração-base ainda não foi estabelecida.
Figura 4.6 – Desenvolvimento dos ICs da Configuração-Base de Requisitos
Uma vez concluído o desenvolvimento dos ICs da Configuração-Base de Requisitos é efetuado
o estabelecimento da mesma e, daí em diante, os seus ICs só poderão ser modificados mediante
mecanismos formais estabelecidos pelo plano de GCS. A figura 4.7 ilustra o desenvolvimento
logo após o estabelecimento da primeira configuração-base.
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
30 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Figura 4.7 – Estabelecimento da Configuração-Base de Requisitos
Uma vez estabelecida a Configuração-Base de Requisitos os ICs da Configuração-Base de
Projeto passam a ser desenvolvidos conforma ilustra a figura 4.8.
Figura 4.8- Desenvolvimento dos ICs da Configuração-Base de Projeto
Concluídos os ICs da Configuração-Base de Projeto, a mesma é estabelecida segundo ilustra a
figura 4.9.
Figura 4.9 – Estabelecimento da Configuração-Base de Projeto
Da mesma forma, as demais configurações-base são desenvolvidas e estabelecidas até que seja
atingida a situação ilustrada pela figura 4.10 onde todas as Configurações-Base já se encontram
desenvolvidas e estabelecidas.
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
31
Figura 4.10 - O Desenvolvimento de software concluído
Entre uma configuração-base e a configuração-base seguinte normalmente acontece a criação
de novos itens como conseqüência natural do desenvolvimento. Isso é o ilustrado nas figuras
anteriores. Acontece que os ICs já concluídos também são passíveis de alteração, seja para
aperfeiçoamento, seja para a correção de erros que forem detectados. Assim, a evolução das
configurações-base é devidas a dois fatores:
• Criação de novos itens;
• Alteração em itens existentes.
Nas figuras anteriores, relativas ao desenvolvimento com configurações-base, apenas o
primeiro fator foi considerado.
Na seqüência seguinte de figuras, temos um modelo mais real do desenvolvimento com
configurações-base em que são consideradas as evoluções dos ICs que já fazem parte de uma
configuração-base e que são modificados com algum objetivo.
A figura 4.11, idêntica à figura 4.7, ilustra a situação onde a primeira configuração-base acaba
de ser estabelecida.
Figura 4.11 – Estabelecimento da Configuração-Base de Requisitos
Uma vez estabelecida a Configuração-Base de Requisitos, inicia-se a fase de projeto e os ICs a
ela referentes passam a ser desenvolvidos. Os projetistas realizam as atividades da fase tendo
como referência os documentos (ICs) formalmente estabelecidos na CB de requisitos.
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
32 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Durante a fase, entretanto, pode ocorrer a necessidade de alteração dos ICs consolidados na
configuração-base de requisitos. Por exemplo, o cliente, após o estabelecimento da CB,
percebe que há requisitos que não refletem exatamente suas necessidades e precisam ser
alterados. Ou, alternativamente, os projetistas durante as atividades da fase de projeto, ao
ganharem mais entendimento do software sendo desenvolvido, identificam inconsistências
entre os requisitos.
Em situações como esta, a realização da modificação deverá seguir passos bem definidos. Em
primeiro lugar, alguém deverá solicitar, ou propor, as mudanças necessárias. Alguém deverá,
então, analisar a solicitação, verificando sua relevância, oportunidade e abrangência, bem como
o impacto que causa nos custos e no cronograma de desenvolvimento. A partir da análise da
proposta, alguém com a autoridade necessária deverá decidir se a modificação será ou não
realizada. Em caso de decisão positiva, alguém será destacado para implementar a
modificação, a qual, um vez realizada, deverá ser verificada para a constatação de que foi
corretamente elaborada e de que não cria inconsistências na configuração-base. Só então a
modificação será consolidada na CB e estabelecida uma atualização ou nova versão da
configuração-base de requisitos.
Estabelecida a nova versão da CB, os projetistas prosseguirão as atividades da fase, agora
tendo como referência a nova CB. Durante a continuação da fase, outras necessidades de
modificação da CB de requisitos podem surgir e, como conseqüência, deverá ser aplicado
novamente o procedimento detalhado nos parágrafos anteriores. As figuras 4.12 e 4.13 ilustram
este fato.
Figura 4.12 – Desenvolvimento da Configuração-Base de Projeto
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
33
Figura 4.13 – Desenvolvimento da Configuração-Base de Projeto
A figura 4.14 ilustra o estabelecimento da Configuração-Base de Projeto a partir dos ICs
desenvolvidos na fase e dos ICs pertencentes à Configuração-Base de Requisitos.
Figura 4.14 – Estabelecimento da Configuração-Base de Projeto
E assim, de maneira similar, conforme as fases seguintes são executadas, as novas
configurações-base vão sendo desenvolvidas, estabelecidas e eventualmente modificadas
conforme sugere as figuras 4.15 e 4.16.
Figura 4.15 – Desenvolvimento da Configuração-Base de Código
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
34 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Figura 4.16 – Desenvolvimento da Configuração-Base de Código
Na figura 4.17 temos o desenvolvimento concluído.
Figura 4.17 – Desenvolvimento Concluído
Os procedimentos de consistência interna, verificação e validação são aplicados quando do
estabelecimento de cada configuração-base e em cada atualização da mesma.
4.3 Distribuições
Utilizamos a palavra distribuição para denominar o conjunto de itens, arquivos e ICs, que são
entregues ao usuário ou cliente como resultado da liberação de uma dada configuração do
produto para utilização em ambiente externo ao desenvolvimento.
No final de um desenvolvimento, após o estabelecimento da última configuração-base, em
geral a configuração base de produto, ocorre a entrega do produto ao cliente. Entretanto, nem
sempre é entregue todo o conteúdo da configuração, ficando, por exemplo, os documentos de
projeto em poder do desenvolvedor. Por outro lado, muitas vezes, no que tange ao código
gerado, o controle de GCS se restringe aos arquivos-fonte, não sendo mantidos sob controleos
arquivos executáveis, já que estes sempre podem ser obtidos a partir dos fontes
correspondentes.
Assim, o conjunto de arquivos que constitui uma distribuição do produto pode não ser o
conteúdo de uma configuração, ou tampouco um subconjunto dela.
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Análise Projeto Codificação Teste/Integr. Manutenção
Início Desativação
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
35
Denominamos Estabelecimento de Distribuição o conjunto de ações que, partindo de uma
configuração gera a distribuição do produto referente a esta configuração. A configuração que
dá origem à distribuição é denominada Configuração de Distribuição.
Assim, podem-se entender distribuição e configuração como conjuntos distintos de elementos,
ainda que possuam itens em comum. Adicionalmente, esta separação permite estabelecer
espaços de nomeações independentes para distribuições e configurações, fornecendo uma
visibilidade diferenciada entre a organização de desenvolvimento e os clientes. A figura 4.18
ilustra esta diferenciação.
Figura 4.18 – Identificação de Configurações e de Distribuições
4.4 Definição formal de GCS
Gerência de Configuração de Software é o processo cujo objetivo é identificar a
configuração do software em pontos discretos no tempo e sistematicamente controlar as
modificações à configuração identificada com o objetivo de manter a integridade e
rastreabilidade do software ao longo de seu ciclo de vida.
GCS é uma disciplina de natureza técnica e gerencial que define responsabilidades e
autoridades. Suas atividades se desenvolvem durante todo o ciclo de vida do software. Num
ambiente de desenvolvimento de software de qualidade, GCS constitui um processo-chave.
Ressalve-se que a aplicação de GCS não é trivial, envolve aspectos culturais e de
comportamento. Gerência de Configuração de Software não é uma panacéia para todos os
problemas do software.
4.5 Atividades de GCS
A GCS aplica-se a um software a ser desenvolvido através de quatro atividades principais
também conhecidas como subprocessos de GCS:
• Identificação de configuração;
• Controle de configuração;
1.0 1.1 1.2 1.3 1.4
D 1.0 D 1.1
desenvolvimento
clientes
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
36 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
• Administração de estado;
• Auditagem de configuração.
Tais atividades são detalhadas nos itens seguintes deste texto.
4.5.1 Identificação de configuração
O objetivo da identificação de configuração é identificar e documentar as características físicas
e funcionais do software sendo desenvolvido, fornecendo os meios para rastreá-lo por todo o
ciclo de vida. Constituem atividades da identificação de configuração:
• Identificar a estrutura do sistema de software;
• Identificar de maneira unívoca cada item de configuração;
• Definir inter-relacionamento entre os itens de configuração;
• Identificar o conjunto de configurações-base a serem criadas e mantidas;
• Caracterizar o conteúdo de cada configuração-base, identificando os elementos básicos
que a compõem;
• Criar o mecanismo de nomeação dos Ics e configurações-base;
• Definir o mecanismo de identificação de versão dos ICs e configurações-base;
• Caracterizar os meios de acesso aos itens de configuração.
4.5.2 Controle de configuração
O objetivo do controle de configuração é coordenar o processo de geração e evolução das
configurações-base e seus ICs. Suas principais atividades são:
• Definir o processo de modificação de configurações-base;
• Estabelecer procedimentos e políticas de controle de modificação;
• Definir procedimentos e políticas de liberação de versões (distribuições);
• Desenvolver formulários/documentos de apoio;
• Realizar o processamento de modificações;
• Controlar a liberação de versões.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
37
A figura 4.19 ilustra a seqüência de passos a serem seguidos para o processamento de uma
modificação.
Figura 4.19 - Passos para processo de modificação de um IC
Iniciação da Modificação: Uma modificação deve ser iniciada por indivíduos que tenham
privilégio para tal dentro da organização e seguindo um procedimento padrão.
No plano de gerência de configuração usado como exemplo neste texto (Apêndice A), uma
modificação é iniciada com o preenchimento de uma requisição de modificação (RMS) que
deve ser apresentada ao responsável pela gerência de configuração (RGCS). A requisição
consiste no preenchimento de um formulário padrão (RMS) onde é feita uma solicitação formal
para realizar a modificação.
Classificação: As requisições de modificação recebem uma classificação que objetiva
estabelecer uma categoria para a modificação do ponto de vista dos elementos da organização
de GCS (proponente, RGCS, CCC, etc.), que serão detalhados mais à frente. No nosso
exemplo, uma RMS pode ser classificada pelo proponente e pelo CCC numa das seguintes
categorias: crítica, muito importante, importante, interessante ou inconveniente. Essa
classificação visa orientar as ações que seguem a deliberação sobre a requisição, basicamente a
prioridade de implementação.
Análise da Modificação: Análise da mudança envolvendo tanto os aspectos técnicos como os
aspectos não técnicos:
• Aspectos técnicos: ICs envolvidos, interfaces afetadas, etc.;
• Aspectos não técnicos: custos, prazos e cronograma de execução, ganhos, riscos,
utilidade, aspectos contratuais, etc.
Decisão sobre a Modificação: Uma decisão sobre a modificação obrigatoriamente deve ser
tomada pela(s) autoridade(s) competente(s). No nosso exemplo a avaliação de uma RMS é feita
por um comitê de controle de configuração (CCC) que analisa os seus méritos e delibera a
respeito: aprova, não aprova ou posterga a decisão.
As modificações não aprovadas não serão implementadas, porém todos os documentos e
informações produzidas durante o processo devem ser arquivadas para efeito de histórico.
Iniciação da Modificação
Classificação
Análise da Modificação
Decisão sobre Modificação
Implementação
Verificação
Modificação da Configuração-Base
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
38 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Implementação: Uma modificação, uma vez aprovada, passa para a fase de implementação.
Os ICs envolvidos devem ser disponibilizados para que os técnicos designados para a
implementação da modificação possam realizá-la. Durante esta fase, os itens de configuração
envolvidos devem ficar bloqueados para evitar conflitos entre modificações simultâneas de um
mesmo item.
Verificação: Uma vez realizada uma modificação ela necessita ser verificada antes de ser
considerada efetiva. Verificações devem ser feitas no sentido de averiguar que a modificação
realizada foi feita conforme a sua requisição e que não se encontraram erros na implementação.
Procedimentos de testes e verificação variam de empresa para empresa. Os tipos de
verificações a serem feitas sobre os ICs são parte integrante do plano de gerência de
configuração do produto.
Modificação da Configuração-Base: Se a modificação foi implementada, verificada e
aprovada, são, então estabelecidas as novas versões dos ICs e da configuração-base.
A figura 4.20 resume o processo de modificação de um produto de software.
Figura 4.20 - Processo de modificação
4.5.3 Administração de estado
O objetivo geral do processo de administração de estado é estabelecer mecanismosde registro
e de divulgação das ações realizadas no âmbito do processo de GCS, incluindo mecanismos de
acompanhamento das configurações-base e ICs. São atividades da administração de estado:
• Estabelecer o conjunto de instrumentos de controle para apoio ao processo de GCS;
• Estabelecer procedimentos de comunicação de mudanças;
• Definir os tipos de relatórios a serem gerados;
Preparação
Proposta de
Modificação
Análise
de
Impacto
Avaliação
da
Proposta
Aprovação ? FIM
Arquivamento
RMS
Implementação
Verificação
Incorporação
não
sim
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
39
• Acompanhar o estado das configurações-base;
• Acompanhar a evolução das modificações;
• Registrar e comunicar as atividades de GCS;
• Gerar relatórios de andamento das atividades de GCS;
• Fornecer, quando necessário, a configuração do sistema e o histórico das modificações
efetuadas e em andamento.
4.5.4 Auditagem de configuração
Estabelecer mecanismos de verificação das configurações-base e dos ICs para garantir que:
• modificações realizadas estejam de acordo com as respectivas propostas;
• o produto de software em desenvolvimento esteja em conformidade com requisitos,
padrões e acordos contratuais.
Constituem atividades da auditagem de configuração;
• Definir os tipos de auditagens que serão realizadas:
• Definir os procedimentos e cronogramas de auditagem;
• Garantir que as auditagens sejam realizadas;
• Gerar pareceres e relatórios.
Auditagens devem ser conduzidas sempre que uma configuração-base é estabelecida ou
modificada. Três enfoques devem ser abordados nas auditagens: consistência interna,
verificação e validação.
A consistência interna objetiva inspecionar se os elementos que constituem a configuração-
base são consistentes entre si, e se normas ou regras de construção destes elementos foram
seguidas corretamente, por exemplo, normas de codificação de arquivo-fonte, normas de
formato de documento, etc.
A verificação objetiva inspecionar se a configuração-base é consistente com a configuração-
base que lhe está dando origem.
Por fim, a validação objetiva inspecionar se a configuração-base sendo avaliada, que é uma
representação do software em desenvolvimento, atende às expectativas e necessidades,
eventualmente atualizadas, do software sendo desenvolvido.
4.6 Elementos organizacionais de GCS
Os elementos de um projeto envolvidos com a gerência de configuração podem variar em
número e funções dependendo de aspectos tais como tamanho do projeto, categoria do
software, etc.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
40 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
No texto iremos nos ater principalmente às responsabilidades e funções básicas que devem
estar presentes no processo, ficando os detalhes por conta do Plano de Gerência de
Configuração onde tudo deve ser explicitamente declarado.
A figura 4.21 ilustra uma organização típica de gerência de configuração de software.
Figura 4.21 – Organização típica de GCS
Na organização existem sempre elementos autorizados a solicitar modificações (SM); ou seja,
elementos que disparam o processo de modificação. No geral a solicitação de modificação
pode ser feita por qualquer elemento relacionado com o produto de software, seja ou não
pertencente ao corpo de funcionários da empresa: técnicos de desenvolvimento, gerentes,
vendedores, clientes, etc..
O Responsável pela Gerência de Configuração de Software (RGCS) é o elemento
responsável pela coordenação de todo o processo de GCS. Tem como papel maior garantir que
todas a atividades definidas sejam executadas. Basicamente o Gerente de Configuração
interage com todo o resto do sistema providenciando que as modificações sejam registradas,
avaliadas, implementadas, verificadas e armazenada na base de dados do projeto. Esta função
pode ser exercida por um ou mais indivíduos, dependendo da dimensão e complexidade do
projeto.
Na organização de GCS, a Biblioteca representa o repositório de todos os itens envolvidos no
projeto: documentos, programas, dados, etc. Este armazenamento deve apresentar
características tais como eficiência, segurança, capacidade de recuperação de diversas versões,
etc. A biblioteca é de responsabilidade de um Bibliotecário que manipula o seu conteúdo e é
responsável pelos acessos à biblioteca e pela sua integridade.
B ib lio tecá rioB ib lio tecá rioB ib lio tecá rio
R G C SR G C SR G C S
C C CC C CC C C
C o rp o
T écn ico
C o rp oC o rp o
T écn icoT écn ico
A u d ita g emA u d ita g emA u d ita g em
B ib lio tecaB ib lio teca
S M
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
41
O terceiro componente da organização é o Comitê de Controle da Configuração (CCC), que
é o elemento responsável pelas decisões a respeito das propostas de modificações. O CCC
geralmente é composto por diversos membros sendo que um deles o responsável pela decisão
final sobre as modificações. As decisões podem ser tomadas em diversos níveis dependendo do
impacto causado pela modificação sobre custos e prazos.
O Corpo Técnico é o elemento responsável pela implementação das modificações e a
Auditagem é responsável pela verificação de que as modificações foram implementadas de
acordo com o que foi proposto.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
43
5 CONTROLE DE VERSÕES
Controle de versões é um assunto intimamente relacionado com Gerência de Configuração de
Software e muitas vezes é com ela confundido. Pode-se definir Controle de Versões da maneira
seguinte:
Controle de Versões: Procedimentos e ferramentas para gerenciar diferentes versões dos
arquivos que são criados durante o desenvolvimento. São objetivos do Controle de Versões:
• Automatizar o rastreamento de arquivos;
• Prevenir conflitos entre desenvolvedores;
• Recuperar versões prévias;
• Permitir o desenvolvimento paralelo;
• Auditar desenvolvimento: quem, quando, o quê;
• Estabelecer agregações de arquivos: configurações-base e distribuições;
• Reduzir espaço de armazenamento.
Todos os arquivos passam por modificações. Isso gera diferentes versões do arquivo. Entre
duas versões consecutivas existe um conjunto de modificações. A esse conjunto de
modificações que transforma uma versão na sua versão consecutiva dá-se o nome de arquivo
delta ou simplesmente delta, conforme ilustrado na figura 5.1. Assim, versão atual = versão
imediatamente anterior + delta
Figura 5.1 - Versões e arquivos delta
Há muitas maneiras de se identificarem as versões. Um formato bastante difundido, utiliza o
seguinte padrão:
<discr-princ>.<discr-sec>
<discr-princ> é o discriminador principal de versão e é constituído por um número inteiro,
cujo valor inicial é 1. Em princípio não existe valor limite superior para este número.
<discr-sec> é o discriminador secundário de versão e é constituído por um número inteiro cujo
valor inicial é 0, não existindo também limite superior.
int func(a,b)
int a, b;{
 if ( a = 3 ) {
 ...
 }
.
.
.
}
int func(a,b)
int a, b;{
 if ( a > 3 ) {
 ...
 }
.
.
.
}
inserções
remoções
versão 1.0 versão 1.1
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
44 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Assim, a primeira versão do arquivo é a versão 1.0. Cada vez queuma nova versão é
estabelecida, o discriminador secundário é incrementado de 1. A critério da autoridade
competente, pode-se, no estabelecimento de uma versão, avançar o discriminador principal e,
nesse caso, o discriminador secundário é reiniciado com 0.
As ferramentas de controle de versões trabalham com um repositório que armazena
potencialmente todas as versões dos arquivos controlados pela ferramenta. A figura 5.2 ilustra
para um Arquivo A, o caminho percorrido entre a versão 1.0 e a versão 1.4:
Figura 5.2 - Controle de versões
Notar que a versão 1.1 foi obtida a partir da versão 1.0 na qual foram introduzidas
modificações descritas no arquivo delta 1.1. As ferramentas permitem associar à modificação
as informações relacionadas:
• quem está envolvido;
• quando foram efetuadas;
• porque foram efetuadas.
Todas estas informações armazenadas formam a base para o estabelecimento de histórico e
rastreamento das versões.
O assunto Controle de Versões surgiu essencialmente para controlar a evolução de sistemas de
software compostos por programas escritos em linguagens de programação tradicionais, tais
como C, Pascal, ADA, etc., e armazenados em arquivos-texto (textfiles). Estes arquivos-texto
são seqüências de caracteres que constituem linhas as quais, por sua vez, são separadas umas
das outras por caracteres especiais, que são os separadores de linhas.
Com base nesta estrutura simples de arquivo-texto, as ferramentas de controle de versões
estabelecem um mecanismo simples e eficiente de economia de espaço de armazenamento: a
diferença entre duas versões consecutivas de um arquivo, isto é, o delta, pode ser caracterizado
como o conjunto de linhas que deve ser removido da versão inicial e o conjunto de linhas que a
ela deve ser acrescentado para a geração da versão final. Como as linhas, em geral, são de
pequeno tamanho (média de 40 a 50 caracteres), o armazenamento de apenas uma versão do
arquivo e de todos os deltas, em vez do conteúdo de todas as versões, resulta em uma baixa
taxa de crescimento do espaço de armazenamento conforme o arquivo evolui.
1.0 1.2 1.3 1.41.1
1.1 1.2 1.3 1.4
versão
corrente
Arquivo AArquivo A
quem
quando
porque
Histórico,Histórico, Rastreamento Rastreamento, Versões prévias, Versões prévias
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
45
Adicionalmente as ferramentas de controle de versões incluem também técnicas de compressão
de arquivos, diminuindo ainda mais o espaço necessário.Por exemplo, há ferramentas que
armazenam a primeira versão do arquivo e os deltas que geram as versões subseqüentes, como
ilustrado na figura 5.3.
Figura 5.3 – Arquivos delta e versões de um arquivo
A recuperação de uma determinada versão do arquivo consiste em se partir da versão inicial,
armazenada integralmente, e na aplicação sucessiva dos deltas relativos às versões seguintes
até se chegar à versão pretendida. Este método permite uma economia de espaço no
armazenamento mas implica um processamento adicional para se atingir a versão desejada.
Quanto mais recente for a versão, mais processamento será necessário para obtê-la.
Na maioria das atuais ferramentas de GCS adota-se uma abordagem um pouco diferente,
denominada delta reverso. Nesta abordagem, em cada instante está armazenada a versão mais
recente do arquivo e os deltas necessários para a obtenção das versões anteriores, que são
denominados deltas reversos. A figura 5.4 ilustra este conceito.
Figura 5.4 – Arquivos delta reverso e versões de um arquivo
Quando se faz necessário capturar uma certa versão do arquivo, a ferramenta compõe um novo
documento baseado na versão atual e nos arquivos delta reverso gerados entre a versão
desejada e a versão mais recente. A versão mais atual estará sempre disponível de imediato e as
versões anteriores exigirão um processamento adicional para serem obtidas. Quanto mais
antigas, mais processamento.
Se o método de economia de espaço baseado no armazenamento dos deltas é excelente para
arquivos-texto, ele pode trazer um desperdício de espaço muito grande se aplicado a arquivos
binários. Assim, para este tipo de arquivo, as ferramentas de controle de versões armazenam na
íntegra todas as versões do arquivo. De qualquer forma, há sempre o benefício de técnicas de
compressão que, via de regra, são utilizadas pelas ferramentas.
5.1 Desenvolvimento em paralelo
+ +
Modificação
+
Modificação Modificação
...
Versão
Original
Versão
1
Versão
2
Versão
atual
+ +
Modificação
+
Modificação Modificação
...
Versão
Original
Versão
1
Versão
2
Versão
atual
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
46 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A maioria da ferramentas de controle de versão suportam o desenvolvimento em paralelo, ou
evolução paralela, que são derivações a partir de uma determinada versão do arquivo que
podem gerar caminhos paralelos ao caminho principal de desenvolvimento, também conhecido
como tronco principal. Isso tem utilidade quando se deseja incorporar características
particulares em determinadas versões e não em outras. Serve também para gerar versões de
teste ou de ensaio com modificações que poderão, ou não, serem integradas às demais versões.
A figura 5.5 ilustra a idéia de caminhos paralelos de evolução.
Figura 5.5 – Desenvolvimento paralelo
As versões paralelas ou variantes seguem um padrão de identificação chamado de
identificador estendido de versão.
O identificador estendido possui o formato geral:
<id-versão>.<id-caminho>.<id-seq>
onde:
<id-versão> é o identificador de versão, simples ou estendido, de uma versão existente
denominada de versão-base, da qual a versão identificada é variante;
<id-caminho> é o número de ordem de um caminho variante a partir da versão-base. É o
caminho variante ao qual pertence a versão sendo identificada. É um número inteiro maior ou
igual a 1;
<id-seq> é o número de ordem da versão sendo identificada dentro do caminho variante. É um
número inteiro maior ou igual a 0.
5.2 Operações de acesso
De maneira geral, as ferramentas de controle de versões organizam os acessos ao repositório
por meio de um conjunto de operações básicas conhecido como modelo check-in/check-out. A
grande vantagem deste método é prevenir acessos conflitantes ao repositório por
desenvolvedores trabalhando com o mesmo conjunto de arquivos. As operações que integram
este modelo, operação check-in e operação check-out, são descritas a seguir.
1 .0 1 .1 1 .2 1 .3 1 .4 1 .5
1 .3 .1 .1 1 .3 .1 .2
1 .2 .1 .1 1 .2 .1 .2 1 .2 .1 .3
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
47
check-out: obtém cópia de trabalho da versão desejada do arquivo para modificação e,
simultaneamente, impede acessos à versão por outros usuários. A figura 5.6, a seguir, ilustra a
operação.
check-out
repositóriorepositório
área de trabalhoárea de trabalho
1.01.0
1.11.1
1.21.2
repositóriorepositório
área de trabalhoárea de trabalho
1.01.0
1.11.1
1.21.2
Antes do Antes do CheckCheck--outout Após o Após o CheckCheck--outout
Figura 5.6 - Operação check-out
check-in: cria nova versão do arquivo a partir de cópia de trabalho modificada (obtida por
check-out) e libera acessos. A figura 5.7 ilustra a operação.
check-in
repositóriorepositório
área de trabalhoárea de trabalho
1.01.0
1.11.1
1.21.2
repositóriorepositório
área de trabalhoárea de trabalho
1.01.0
1.11.1
1.21.2
Antes do Antes do CheckCheck--inin Após o Após o CheckCheck--inin
1.31.3
Figura5.7 - Operação check-in
Adicionalmente a estas operações, que visam a alteração do conteúdo do repositório, as
ferramentas, de maneira geral, também fornecem uma terceira operação básica, get, cuja
funcionalidade é obter uma cópia apenas de leitura de uma versão específica do arquivo. A
operação não impede os acessos à versão do arquivo por outros usuários.
Como última observação, saliente-se que o conjunto de operações básicas descrito, check-in,
check-out e get, são operações conceituais, isto é, a forma e nome destas operações pode variar
conforme a ferramenta.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
48 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
5.3 Agregações
O conceito de controle de versões inclui, também, um mecanismo de agregação de versões de
arquivos de forma a permitir a referência e obtenção de maneira simples de um conjunto de
arquivos que possuam uma relação comum.
A forma mais simples deste mecanismo consiste da atribuição de um rótulo comum a cada
versão de arquivo que integra o conjunto que se deseja caracterizar. As operações básicas de
check-in, check-out e get, por sua vez, possuem a capacidade de aceitarem um rótulo como
referência aos objetos em que devem operar que, desta forma, se traduz na aplicação da
operação em todos os elementos do conjunto.
A figura 5.8 ilustra o mecanismo de agregação. Ela exemplifica um produto composto por
quatro arquivos: A, B, C e D. A primeira distribuição deste produto, cuja identificação é 1.0, é
composta pelo seguinte conjunto de versões de seus arquivos componentes: {A1.2, B4.6, C1.0,
D3.1}. A segunda distribuição deste produto, cuja identificação é 1.1, é composta pelo seguinte
conjunto de versões de seus arquivos componentes: {A1.5, B4.6, C1.0, D3.2}.
1.01.0
1.11.1
1.51.5
1.21.2
1.31.3
1.41.4
1.01.0
1.11.1
AA
1.01.0
2.02.0
4.24.2
3.03.0
4.04.0
4.14.1
1.01.0
1.11.1
BB
1.01.0
CC
1.01.0
1.11.1
3.23.2
2.02.0
3.03.0
3.13.1 1.01.0
1.11.1
DD
4.64.6
4.34.3
4.44.4
4.54.5
1.01.0
1.11.1
Configurações-BaseConfigurações-Base
4.64.61.01.0
1.21.2
1.01.0
3.13.1 4.64.61.11.1
1.51.5
1.01.0
3.23.2
Figura 5.8 – Agregações
Com esta idéia de agregação é possível implementar os conceitos de configurações,
configurações-base e distribuições.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
49
5.4 Desenvolvimento de Software com Controle de Versões
Para exemplificar a aplicação de controle de versões ao desenvolvimento de software, vamos
supor um sistema de software cujo código-fonte seja formado por 3 arquivos, a saber, A, B e C,
escritos numa específica linguagem de programação. O sistema em sua forma final será um
único arquivo executável, SIST, obtido pela compilação dos arquivos A, B e C e a ligação
(link) dos códigos-objeto destes fontes. Por simplicidade, vamos considerar o desenvolvimento
do sistema consistindo apenas do desenvolvimento dos arquivos-fonte que o compõem.
Conforme são criados, os arquivos são colocados sob controle de versões. Através de “check-
out” o desenvolvedor obtém cópia da versão mais recente de cada arquivo e o evolui. Toda vez
que quiser preservar um dado estado de desenvolvimento do arquivo, ele emite uma operação
“check-in”. Desejando continuar sua evolução, emite “check-out” novamente. Assim, cada
arquivo vai sendo evoluído por meio de sucessivas versões próprias, conforme a figura 5.9.
Figura 5.9 – Evolução dos arquivos integrantes do sistema SIST
Quando o sistema atinge um ponto de estabilidade em que o executável realiza corretamente
um certo conjunto de funcionalidades previstas, é estabelecida uma versão do sistema. O
executável correspondente a esta versão do sistema é enviado a um cliente, o Sr. X. Assim,
neste ponto, é considerada estabelecida a 1ª distribuição do produto, constituída pelo arquivo
executável SIST gerado a partir das versões mais recentes dos 3 arquivos.
O estabelecimento da distribuição é registrado no repositório de controle de versões rotulando-
se as versões dos arquivos-fontes A, B e C correspondentes ao executável SIST com um rótulo
apropriado, por exemplo “Distribuição 1.0”. As versões dos arquivos com este rótulo
caracterizam a configuração de distribuição da distribuição 1.0, como ilustra a figura 5.10.
Figura 5.10 – Distribuição para um cliente X
arquivo A arquivo B arquivo C
Distribuição 1.0
cliente X
arquivo A arquivo B arquivo Carquivo C
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
50 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A partir daí os arquivos A, B e C podem evoluir para novas versões, como mostrado na figura
5.11.
Figura 5.11 – Evolução dos arquivos após a distribuição
Suponhamos agora que o sistema é evoluído com a incorporação de novas funcionalidades e
atinja novo ponto de estabilidade, configurando uma nova versão do sistema, que é enviada a
um novo cliente, o Sr. Y. Esta versão será registrada com o rótulo “Distribuição 2.0”, como
mostra a figura 5.12.
Figura 5.12 – Nova distribuição
Imaginemos agora que, após o estabelecimento da distribuição 2.0, o cliente X entre em
contato com o desenvolvedor comunicando um defeito na versão do produto por ele recebida
(“Distribuição 1.0”). Suponhamos que este defeito fora corrigido na evolução da distribuição
1.0 e que, apesar de a distribuição 2.0 não apresentar o defeito, o desenvolvedor se vê impedido
de enviar esta versão ao cliente. Isto pode ocorrer por motivos comerciais, por exemplo o
cliente não pagou e nem quer pagar pelas funcionalidades presentes na distribuição 2.0, mas o
desenvolvedor está obrigado por contrato a corrigir os defeitos que o cliente constatar. Ou,
então, pode haver motivos técnicos, por exemplo, o ambiente de execução do cliente X não
suporta a distribuição 2.0. Em ambos os casos, o desenvolvedor terá de fazer a correção da
versão correspondente à distribuição 1.0.
A correção da distribuição envolverá os seguintes passos:
• Restauração do conjunto de arquivos que constituem a configuração de distribuição;
• Identificação e correção dos problemas;
• Criação das variantes necessárias;
• Construção da nova distribuição
arquivo Aarquivo A arquivo Barquivo B arquivo Carquivo C
Distribuição 2.0
cliente Y
arquivo Aarquivo A arquivo Barquivo B arquivo Carquivo C
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
51
A restauração do conjunto de arquivos que dá origem à distribuição defeituosa é realizada,
conceitualmente, através da operação: “get Distribuição 1.0”, que significa: “obtenha do
repositório cópias apenas para leitura de todas as versões de arquivos com rótulo “Distribuição
1.0”. De maneira geral, qualquer ferramenta de controle de versões é capaz de realizar tal
operação. Após a realização da operação, o desenvolvedor terá obtido num área de trabalho as
versões dos arquivos A, B e C correspondentes à distribuição 1.0.
O desenvolvedor procede, então, à identificação do problema através da análise do código-
fonte e da realização de testes utilizando o executável gerado a partir das versões obtidas dos
arquivos. Ao final deste passo, o desenvolvedor identifica o(s) arquivo(s) que necessita(m) ser
modificado(s) e quais as modificações necessárias. Neste exemplo, o desenvolvedor identifica
que o defeito está restrito à versão do arquivo B, como mostra a figura 5.13.
Figura 5.13 – Identificação de defeito em distribuição anterior
Para realizar a correção doproblema, o desenvolvedor solicita o “check-out” da versão do
arquivo B e realiza as correções necessárias. Uma vez satisfeito, solicita a operação “check-in”
da versão modificada. Como esta nova versão não corresponde a uma atualização da versão
mais recente do arquivo, a operação a criará como versão variante da que fora submetida à
operação “check-out”.
Após o “check-in”, o desenvolvedor cria o rótulo indicativo da distribuição corretiva, por
exemplo “Distribuição 1.0.1” e o associa às versões dos arquivos A e C que contêm o rótulo
“Distribuição 1.0” e à versão variante do arquivo B, estabelecendo a nova distribuição, como
ilustra a figura 5.14.
Figura 5.14 – Estabelecimento de distribuição corretiva
arquivo Aarquivo A arquivo Barquivo B arquivo Carquivo C
arquivo Aarquivo A arquivo Barquivo B arquivo Carquivo C
Distribuição 1.0.1
cliente X
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
52 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
5.5 Conclusões sobre Controle de Versões
Pode-se chegar as seguintes conclusões relativas ao Controle de Versões e Gerência de
Configuração de Software:
• Provê um mecanismo de Gerência de Configuração simplificada;
• Constitui um bom mecanismo para controlar os arquivos;
• Permite evitar acessos conflitantes;
• Constitui um bom começo para o desenvolvimento e manutenção bem controlados.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
53
6 FERRAMENTAS DE GCS
Neste capítulo são focalizados alguns aspectos relevantes de ferramentas que normalmente são
utilizadas em GCS. Existe no mercado uma grande variedade de opções, desde ferramentas
muito simples controladores de versões até as mais sofisticadas com capacidades para builds,
emissão de relatórios, etc. Não é objetivo deste texto fazer um estudo detalhado das
ferramentas de GCS, mas sim, prover uma visão geral sobre o assunto.
A seguir, serão apresentadas: uma classificação das ferramentas de GCS segundo as suas
características funcionais, algumas diretivas que visam auxiliar o usuário na escolha de uma
ferramenta que seja mais adequada ao seu processo de desenvolvimento e também as principais
características de algumas das ferramentas de GCS mais encontradas no mercado.
Os objetivos principais são: a análise das ferramentas que auxiliam a automatizar o processo de
GCS, a apresentação de métodos que são utilizados para avaliar a eficiência das ferramentas e
os critérios a serem observados de forma a se adotar o software mais apropriado à realidade de
cada empresa.
6.1 Critérios para avaliar uma ferramenta de Gerência de Configuração
Uma ferramenta de GCS pode ser avaliada segundo muitos critérios. Cabe ao avaliador adotar
aqueles critérios que julgar mais adequados a uma situação em particular e a cada critério
escolhido associar um peso relativo. Na literatura encontram-se diversas abordagens e
categorização para estes critérios, mas que, de forma geral, são equivalentes. Nos subitens
seguintes é apresentado um conjunto resumido de critérios baseado na publicação [BUR 96].
6.1.1 Suporte a equipe de desenvolvimento
Análise das funcionalidades das ferramentas aplicadas ao desenvolvimento de projetos de uma
equipe de programadores conectados a uma rede local. Deve ser observado o processo de
gerenciamento das distintas áreas de trabalho de cada desenvolvedor, o processo de
desenvolvimento paralelo, bem como a visualização gráfica do controle de versões aplicada a
projetos que possuem várias ramificações; isto é, diferentes caminhos variantes de
desenvolvimento.
6.1.2 Suporte a desenvolvimento remoto
Análise das funcionalidades aplicadas a projetos com diversos sites de acesso remoto, realidade
que se faz presente no trabalho de equipes que se distribuem em diferentes áreas geográficas,
em que cada membro realiza uma atividade, e a integração do trabalho do grupo é feita
continuamente.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
54 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
6.1.3 Suporte a configurações
Observa-se a capacidade da ferramenta ligada a identificação de distintas versões de arquivos
que compõem uma distribuição e recuperação da mesma. É analisado o impacto de uma dada
alteração, através da estrutura hierárquica do projeto que o software deve permitir exibir; além
dos aspectos de rastreabilidade, que tornam possível o estabelecimento de relações entre
distintos ICs, e seus arquivos de histórico de modificações.
6.1.4 Suporte a gerência de mudanças
A habilidade de prover o rastreamento de modificações, gerando relatórios de
acompanhamento, de forma a permitir uma visão precisa, em tempo real, do estado das
modificações.
6.1.5 Suporte de “build” e de distribuição de produto
Análise das funcionalidades ligadas ao “build”, à geração de uma determinada versão de um
produto e à recuperação de uma distribuição anterior e modificação da mesma.
6.1.6 Suporte de processo
Análise da capacidade de manter um efetivo controle do desenvolvimento, dando suporte à
aplicação de políticas, implementando o conceito de ciclo de vida, estabelecendo autoridades
de acesso a funções de acordo com os papéis dos diversos integrantes do projeto e registrando
os históricos e os estados dos diversos objetos envolvidos no desenvolvimento sob controle da
ferramenta.
6.1.7 Usabilidade
Deve ser observado se a documentação se mostra acessível e prática, além da existência de um
eficiente sistema de auxílio on-line, o nível de integração da ferramenta ao sistema operacional
em uso e a facilidade de acesso às informações controladas pela mesma.
6.1.8 Facilidade de “set-up”
Análise da facilidade de, a partir da sua aquisição, colocar a ferramenta em operação,
englobando: a instalação, a parametrização da ferramenta, a capacitação de pessoal e a
integração no processo de GCS previamente definido.
6.1.9 Personalização
Avaliação da capacidade de personalização da ferramenta, de modo a atender as necessidades
específicas de um usuário no que diz respeito a aspectos de modelos de formulários e
relatórios, políticas específicas de desenvolvimento, dentre outros.
6.2 Classificação das ferramentas de GCS
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
55
Susan Dart [DAR 96] de uma forma simplificada, classifica as ferramentas de Gerência de
Configuração em grupos de acordo com as suas características funcionais, de modo a auxiliar
no momento da aquisição de uma destas ferramentas. A figura 6.1 ilustra a classificação.
Figura 6.1 – Tipos de Ferramentas de GCS
A seguir é feita uma breve descrição das três subdivisões das ferramentas de GCS.
6.2.1 Ferramentas de controle de versões
Nesta categoria estão as ferramentas que implementam os conceitos de controle de versões,
como descritos no capítulo 5.
6.2.2 Ferramentas orientadas ao desenvolvedor
Nesta categoria encontram-se ferramentas que, além de suportarem controle de versões,
oferecem suporte ao trabalho em equipe, facilitando principalmente desenvolvimento
concorrente, isto é, desenvolvedores trabalhando ao mesmo tempo sobre o mesmo conjunto de
arquivos. Têm como característica principal integrarem-se no ambiente de desenvolvimento.
6.2.3 Ferramentas orientadas a processo
Ferramentas que suportam controle de versões e parte das funcionalidades das ferramentas
orientadas ao desenvolvedor, mas cujo ponto forte é a automatização do gerenciamento do
ciclo de vida dos objetos envolvidos no desenvolvimento. De maneira geral, as ferramentasdesta categoria também fornecem uma abordagem integrada à gerência de mudanças e ao
rastreamento de correção de defeitos.
6.3 Estudos de caso
Nesta seção, a título de exemplo são analisadas duas ferramentas de GCS que possuem alguma
penetração no Brasil. Inicialmente analisaremos a ferramenta Source Integrity versão 7.3 da
empresa Mortice Kern Systems, no ambiente Windows. Em seguida, analisaremos a ferramenta
Microsoft Visual Source Safe versão 5.0 da Microsoft Corporation Systems. A análise seguirá o
conjunto de critérios identificados no item 6.1.
Orientadas ao Processo
Orientadas ao Desenvolvedor
Controle de Versões
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
56 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
6.3.1 Análise da ferramenta Source Integrity
A ferramenta Source Integrity é uma ferramenta que pode ser classificada como de controle
de versão.
6.3.1.1 Suporte a equipe de desenvolvimento
A ferramenta utiliza-se de estruturas denominadas archives para gerenciar a modificações e
que são utilizadas para:
• Armazenamento do conteúdo dos arquivos;
• Manutenção de um registro das modificações feitas no arquivo;
• Gerenciamento de acesso aos dados do arquivo;
• Manutenção de um registro de comentários e informações pertinentes, referentes ao
histórico de modificações de um arquivo.
O produto Source Integrity introduz o conceito de sandbox, uma área de trabalho destinada a
cada elemento da equipe de desenvolvimento. Assim, cada desenvolvedor possui sua área
pessoal segura e protegida, sem interferir no estado do projeto principal, ou na atividade de
outros desenvolvedores.
Num sandbox geralmente é feita uma cópia, integral ou parcial, da estrutura do projeto versão
atual, de forma a possibilitar que cada desenvolvedor trabalhe com a versão mais recente do
projeto.
Um comando de check-out efetua a cópia de uma versão específica de um arquivo, permitindo
que esta seja modificada. O usuário que efetuou a operação de check-out tem a possibilidade de
travar o acesso a esta versão do arquivo, não permitindo que os outros desenvolvedores
trabalhem nesta mesma versão.
No comando de check-in, o arquivo e o archive correspondente são atualizados refletindo a
modificação implementada e, caso seja acionada a opção, os demais usuários do sistema
também são notificados que o arquivo principal foi modificado com a versão mais recente.
Para possibilitar o desenvolvimento de várias tarefas em paralelo a ferramenta Source Integrity
permite a criação de uma linha separada de desenvolvimento, através da criação do
denominado branch, uma espécie de versão variante do produto.
Linhas de desenvolvimento paralelo recebem nomenclaturas distintas de forma a refletir que
são versões alternativas do produto, não correspondendo ao projeto principal.
6.3.1.2 Desenvolvimento remoto
As características de desenvolvimento paralelo, também podem ser compreendidas dentro do
contexto da distribuição geográfica dos membros da equipe de desenvolvimento. O trabalho de
cada desenvolvedor é realizado de forma independente em sua sandbox, e usuários remotos
observam o status das modificações aplicadas aos arquivos.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
57
O software Web Integrity que acompanha o pacote da ferramenta Source Integrity, apresenta
uma interface similar a um browser em que é permitido aos usuários travar, destravar, realizar
check-in, check-out e solicitar outras informações de um archive específico; a partir de uma
estação de trabalho conectada a Internet.
6.3.1.3 Gerenciamento de configuração
Os dados de um projeto são gerenciados a partir de uma árvore de diretórios composta de sub-
pastas destinadas ao armazenamento dos códigos-fonte dos arquivos, da documentação dos
mesmos, bem como dos arquivos de projeto.
A forma como os projetos são identificados, permite que a partir de uma distribuição específica
seja recriado todo o projeto associado. Assim, é possível também estabelecer as denominadas
Variant SandBox, em que se cria uma sandbox associada a uma versão variante (branch) do
projeto principal, contendo uma certa distribuição de um arquivo, a partir do qual pode-se
determinar uma nova linha de desenvolvimento.
Analisando os aspectos ligados ao rastreamento de um certo IC, observa-se que o software não
permite manutenção de links ou interdependência entre itens de diferentes tipos tais como um
documento e um código fonte.
6.3.1.4 Gerenciamento de modificação
O controle de uma modificação no Source Integrity permite um certo acompanhamento do IC
ao longo do desenvolvimento de seu ciclo de vida. É possível acrescentar comentários na
realização do check-in e check-out de um arquivo, além dos relatórios de modificações,
relatórios descrevendo aspectos de uma dada modificação, tais como o autor da mesma, horário
e data de sua efetivação, itens travados para certos usuários, etc.
6.3.1.5 Suporte a geração de distribuição de um produto
A ferramenta permite a fácil construção de um IC, bem como a visualização dos arquivos
relacionados ao projeto e suas interdependências.
Uma distribuição de um produto é identificada com um número de revisão atribuído pelo
próprio Source Integrity, mas permite a inserção de um rótulo, de modo que o usuário possa
realizar a identificação da distribuição da forma que lhe for mais conveniente.
6.3.1.6 Gerenciamento de processo
O gerenciamento de processos é realizado através da análise do ciclo de vida dos diversos
archives envolvidos, observando-se os diferentes estados em que se encontram, estados estes,
que podem ser facilmente visualizados.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
58 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
6.3.1.7 Usabilidade
O Source Integrity apresenta suporte a uma interface gráfica, assim como para uma interface
através de linhas de comando. A interface gráfica é relativamente fácil de usar, com ícones
significativos e janelas com informações concisas e diretas sempre retornando um status ao
usuário.
A documentação do produto aborda as suas funcionalidades básicas. Isso também se verifica
no tutorial para os primeiros passos que acompanha o software. A descrição das características
mais avançadas da ferramenta só é acessível através do serviços de Help On-Line, fóruns de
perguntas freqüentemente realizadas por usuários, e o suporte via Web que se mostra bastante
eficiente retornando um feedback ao usuário num curto período de tempo.
6.3.1.8 Facilidade de configuração inicial
O sistema de configuração inicial pode ser descrito como rápido e direto, e consiste em
selecionar as opções referentes a distintos menus de forma adequada.
6.3.1.9 Personalização
Apesar de alguns aspectos bastante flexíveis no Source Integrity como um todo, as
possibilidades de customização são mínimas e aplicadas a algumas restritas funcionalidades de
projeto da tela.
A ferramenta em questão apresenta uma interface também bastante interativa, contudo devido a
sua vasta gama de recursos e menus de opções, a manipulação do software deixa de ser trivial.
6.3.2 Análise da ferramenta Visual Source Safe
A ferramenta Visual Source Safe, classificada como voltada ao controle de versão, atualmente
é muito difundida no mercado e seu preço é bastante inferior se comparado a outros pacotes de
GCS.
6.3.2.1 Suporte a equipe de desenvolvimento
O controle de versão utilizado pelo Visual Source Safe, baseia-se no conceito de projeto
(projects). O início do desenvolvimento de uma tarefa por uma equipe de desenvolvedores está
ligada a premissa de criação de projetos, que seorganizam de maneira hierárquica num
repositório. Existe um diretório raiz representado pelo símbolo $/, e sub-projetos são criados no
interior deste. Os arquivos são identificados por nomes e podem ser rotulados com outra
identificação atribuída pelo usuário.
Os membros da equipe de desenvolvimento trabalham com um projeto selecionado, e a cada
projeto está associado um diretório de trabalho onde são armazenados os arquivos que, para
serem editados, passam por um processo de check-out.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
59
O desenvolvimento concorrente é permitido, no momento em que mais de um usuário realiza
check-out de um determinado arquivo para edição do mesmo. Após a alteração do arquivo, é
efetuada a operação de check-in por um dos usuários, e o referido arquivo, alterado por esse
usuário, é automaticamente atualizado no projeto, criando uma nova versão do mesmo.
6.3.2.2 Desenvolvimento remoto
A ferramenta Visual Source Safe é projetada para utilização como uma ferramenta individual,
ou para pequenas redes locais; desta forma não suporta um desenvolvimento distribuído assim
como acesso de controle de dados via Internet.
6.3.2.3 Gerenciamento de configuração
A gerência de configuração permite a criação da denominada Shadow Folder, em que se torna
possível armazenar um certo estado de uma distribuição em diretório específico, que pode vir a
ser utilizado num momento futuro.
Uma das limitações da ferramenta é observada nas funcionalidades de rastreabilidade, uma vez
que não é possível links ou relações de interdependência entre os elementos de um projeto.
6.3.2.4 Gerenciamento de modificação
O controle de uma modificação não permite uma espécie de rastreamento ou acompanhamento
ao longo de todo o ciclo de vida de um IC; contudo realiza a inserção de comentários na
efetivação do check-in e check-out de um arquivo. É possível observar o registro destes
comentários, bem como o histórico de cada arquivo/projeto e relação dos itens apagados,
através dos relatórios de modificação que a ferramenta permite visualizar.
6.3.2.5 Suporte a geração de distribuição de um produto
A criação de um arquivo ou de qualquer outro elemento sob o processo de gerência de
configuração é no contexto um projeto Source Safe (project). É possível reconstruir algumas
distribuições específicas associadas a um projeto, bem como impedir a evolução de outros
arquivos através do conceito de frozen, que consiste em remover a permissão de escrita nestes
arquivos.
6.3.2.6 Gerenciamento de processo
Não existe o conceito de gerenciamento de processo no acompanhamento do ciclo de vida de
uma dada distribuição. A idéia de associar um arquivo a diferentes estados de
desenvolvimento, não é implementada no Source Safe.
6.3.2.7 Usabilidade
A ferramenta apresenta uma interface gráfica para ambiente Windows, assim como interface de
linhas de comando para ambiente DOS.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
60 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A apresentação da disposição da informação e dos menus é clara e direta, tornando a
manipulação do software bastante intuitiva até para usuários leigos.
A documentação também é apresentada de forma simples com exemplos de aplicações bastante
ilustrativos. O auxílio on-line também se mostra uma alternativa útil e funcional.
6.3.2.8 Facilidade de configuração inicial
A configuração inicial do sistema é uma tarefa extremamente simples. A existência de caixas
de diálogo que conduzem o usuário, torna a configuração direta e de fácil compreensão.
6.3.2.9 Personalização
O Source Safe não se mostra uma ferramenta com um considerável número de funcionalidades,
assim sua personalização limita-se a pequenas alterações visuais de projeto da tela.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
61
7 NORMAS E PADRÕES
Como abordado no capítulo 2 Histórico, os trabalhos de normalização trouxeram grandes
contribuições para a conceituação da área de GCS. Neste capítulo, vamos apresentar
resumidamente algumas normas, atualmente em uso, apresentadas pelas organizações
internacionais mais importantes nesta área, e que são:
• IEEE (The Institute of Electrical and Electronics Engineers);
• ISO/IEC (International Organization for Standardization / International Electrotechnical
Commission);
• SEI-CMU (The Software Engineering Institute – Carnegie Mellon University).
7.1 IEEE
As normas IEEE relativas a GCS enfocam especificamente a questão dos planos de gerência de
configuração. São duas as normas estabelecidas:
• IEEE Std 828-1998, Standard for Software Configuration Management Plans;
• IEEE Std 1042-1986, Guide for Software Configuration Management.
A primeira define uma estrutura básica, isto é, um “esqueleto”, para o plano de GCS,
estabelecendo os itens que devem ser abordados e uma sucinta explicação para cada um deles.
A segunda norma é um guia de apoio para a aplicação da norma de plano, fazendo comentários
adicionais ao seu preenchimento. Contém exemplos de planos abordando 4 tipos diferentes de
projetos de desenvolvimento.
7.2 ISO/IEC
As normas ISO/IEC têm como enfoque o estabelecimento de conceitos visando definir uma
base comum de conhecimento sobre o assunto. As normas que formalizam GCS são as
seguintes:
• ISO 10007, Quality Management – Guidelines for Configuration Management;
• ISO/IEC 12207, Information Technology – Software Life Cycle Process;
• ISO/IEC TR 15846, Information Technology–Configuration Management for Software.
A ISO 10007 é um guia geral para gerência de configuração, enfocando produtos de
engenharia, não sendo específica para software. Procura cobrir todo o ciclo de
desenvolvimento de um produto e foi concebida como forma de atender os requisitos de GCS
estabelecidos na família de normas ISO 9000.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
62 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A ISO/IEC 12207 define um estrutura básica (framework) para processos do ciclo de vida de
software. É uma norma bastante sucinta dedicando uma página para cada processo, e seu
objetivo maior é estabelecer uma base para o entendimento comum sobre software e sua
evolução. Apesar de resumida, a norma é bastante abrangente, cobrindo processos, atividades e
tarefas para adquirir, fornecer, desenvolver, operar e manter o software.
A estrutura básica de processos definidos pela norma categoriza os processos de ciclo de vida
de software em três classes:
Processos Fundamentais:
• Aquisição;
• Fornecimento;
• Desenvolvimento;
• Operação;
• Manutenção.
Processos de Apoio:
• Documentação;
• Gerência de Configuração;
• Garantia da Qualidade;
• Verificação;
• Validação;
• Revisão Conjunta;
• Auditoria;
• Resolução de Problema.
Processos Organizacionais:
• Gerência;
• Melhoria;
• Infra-estrutura;
• Treinamento.
A ISO/IEC TR 15846 é um relatório técnico que detalha o processo de GCS definido pela
ISO/IEC 12207. Este documento não possui o caráter de norma e, também, não define como
GCS deve ser realizada, isto é, estabelece um conjunto de requisitos (o quê) para a realização
de GCS.
Segundo a normas ISO/IEC 12207 e ISO/IEC TR 15846, o processo de GCS é caracterizado
pelas seguintes atividades:
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
63
• Implementação do Processo;
•Identificação da Configuração;
• Controle da Configuração;
• Relato da Situação da Configuração;
• Avaliação da Configuração;
• Gerência de Liberação e Distribuição.
7.3 SEI-CMU
O Software Engineering Institute (SEI) apesar de não ser uma organização de normalização,
definiu um modelo de processos de software, o Capability Maturity Model (CMM), que vem
sendo largamente adotado para avaliação de empresas desenvolvedoras de software, de forma
que o modelo acabou por se estabelecer como um padrão “de fato”. Este modelo é definido em
[CMM 93].
O modelo foi elaborado para avaliar o estado de maturidade de uma organização
desenvolvedora de software em termos das práticas adotadas e para oferecer um caminho geral
para a melhoria do processo de software sem, todavia, estabelecer exatamente como efetuar a
melhoria.
O modelo estabelece cinco níveis de maturidade. 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.
Novamente, o enfoque de abordagem de cada processo assim definido é em o quê deve ser
realizado e não como.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
64 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A figura 7.1 ilustra o modelo CMM apresentando os cinco níveis de maturidade e o conjunto
de processos que cada nível especifica.
Figura 7.1 – O modelo CMM
Neste modelo, o nível 1 é o ponto de partida e não pressupõe nenhum processo organizado,
englobando, inclusive, organizações desenvolvedoras totalmente caóticas.
Repeatable (2)
Optimizing (5)
Managed (4)
Defined (3)
Initial (1)
 Process Change Management
 Technology Change Management
Defect Prevention
 Software Quality Management
Quantitative Process Management
 Peer Reviews
 Intergroup Coordination
 Software Product Engineering
 Training Program
 Organization Process Definition
Organization Process Focus
 Software Configuration Management
 Software Quality Assurance
 Software Subcontract Management
 Software Project Tracking and Oversight
 Software Project Planning
 Requirements Management
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
65
O primeiro nível de maturidade é representado pelo nível 2 – Repetível que possui as seguintes
características:
• Estabelece processos para gerenciamento de projetos;
• Os processos são organizados no nível de projeto e não no nível da organização
desenvolvedora de software;
• Neste nível, espera-se da organização desenvolvedora apenas a definição de políticas
gerais para os processos.
Na estrutura do CMM os processos são definidos em termos de metas a serem atingidas e
práticas-chave a serem realizadas. Estas práticas-chave, por sua vez, são categorizadas em
grupos denominados características comuns (commom features) que organizam as práticas-
chave de acordo com seu intento. São cinco as características comuns:
Comprometimento para execução (Commitment to Perform) – agrupa as práticas que
descrevem as ações que a organização deve realizar para garantir que o processo esteja
estabelecido e seja durável. Tipicamente envolve o estabelecimento de políticas
organizacionais e as responsabilidades da gerência superior.
Habilidade para execução (Ability to Perform) – agrupa as práticas que descrevem as pré-
condicões que devem existir no projeto ou organização para implementar o processo de
software competentemente. Tipicamente envolve recursos, estruturas organizacionais e
treinamento.
Atividades executadas (Activities Performed) – agrupa as práticas que descrevem os papéis e
procedimentos necessários para implementar o processo. Tipicamente envolve o
estabelecimento de planos e procedimentos, realização do trabalho, seu acompanhamento e a
tomada de ações corretivas quando necessário.
Medição e análise (Measurement and analysis) – agrupa as práticas que descrevem a
necessidade de medir o processo e analisar as medidas. Tipicamente inclui exemplos de
medidas que podem ser tomadas para determinar o status e a efetividade das Atividades
executadas (Activities Performed).
Verificação da implementação (Verifying Implementation) – agrupa as práticas que
descrevem os passos para garantir que as atividades sejam realizadas em conformidade com o
processo que foi estabelecido. Tipicamente abrange revisões e auditagens pela gerência e pela
garantia da qualidade de software.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
66 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A figura 7.2 ilustra a estrutura do modelo CMM.
Figura 7.2 – Estrutura do CMM
Como ilustrado na figura 7.3, um dos processos em que a organização deve se concentrar
para atingir o Nível de Maturidade 2 é a Gerência de Configuração de Software.
Níveis de Maturidade
Áreas-chave de processo
Características comuns
Práticas-chave
Capacidade do processo
Metas
Implementação ou
Institucionalização
Infraestrutura
ou Atividades
contêm
organizadas por
contêm
indicam
realizam
abordam
descrevem
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
67
Figura 7.3 – O nível 2 do CMM
7.3.1 O Processo de GCS segundo o modelo CMM
GCS envolve identificação e configuração de um software (isto é, produto de trabalho do
desenvolvimento de software e sua descrição) em dados pontos no tempo, sistematicamente
controlando mudanças da configuração e mantendo a integridade e rastreabilidade da
configuração através do ciclo de vida do software. Os produtos de trabalho colocados sob
gerência de configuração de software incluem os produtos de software que são entregues ao
cliente (p. ex. documento de requisitos de software e codificação) e os itens que são
identificados ou requeridos para criar estes produtos de software (p. ex. compilador).
Uma biblioteca de referência ou repositório é estabelecida recebendo as configurações-base de
software à medida que elas são desenvolvidas. Mudanças nas configurações-base e a
distribuição dos produtos de software “construídos” a partir da biblioteca de configurações-
base de software são sistematicamente controlados via funções de GCS de controle de
mudança e de auditagem de configuração.
O processo de GCS deve atingir as seguintes metas:
• As atividades de GCS são planejadas;
Projeto de Software
Acompanhamento
de Projeto
Gerência de
Configuração
project
stand
ar
d
Planejamento
de Projeto
Gerência de
Requisitos
Gerência de
SubcontratoGarantia daQualidade
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
68 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
• Os produtos de trabalho de software são identificados, controlados e disponibilizados;
• Mudanças nos produtos de trabalho identificados são controladas;
• Pessoas e grupos envolvidos são informados do estado e conteúdo das configurações-
base.
As práticas-chave que participam da organização da GCS, agrupadas segundo as características
comuns, são:
Comprometimento para execução
1.
 
O projeto segue uma política organizacional formalizada por escrito para a
implementação de GCS.
Habilidade para execução
2.
 
Existe ou é estabelecido um comitê com a autoridade para gerenciar as configurações-
base de software do projeto (Comitê de Controle deModificação - CCM).
3.
 
Existe um grupo responsável pela coordenação e implementação de GCS para o
projeto.
4.
 
Recursos e orçamento são alocados para a realização das atividades de GCS.
5.
 
Os membros do grupo de GCS são treinados nos objetivos, procedimentos e métodos
para a realização de suas atividades de GCS.
6.
 
Os membros do grupo de engenharia de software e outros grupos relacionados a
software são treinados para realizar suas atividades de GCS.
Atividades executadas
7.
 
Um plano de GCS é preparado para cada projeto de software de acordo com um
procedimento documentado.
8.
 
Um plano de GCS documentado e aprovado é usado como base para a realização das
atividades de GCS.
9.
 
Um sistema de bibliotecas de GC é estabelecido como repositório para as
configurações-base de software.
10.
 
Os produtos de trabalho de software a serem colocados sob GC são identificados.
11.
 
Solicitações de mudança e relatos de problema para todos os itens/unidades de
configuração são iniciados, registrados, revisados, aprovados e rastreados de acordo
com um procedimento documentado.
12.
 
Mudanças nas configurações-base são controladas de acordo com um procedimento
documentado.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
69
13. Produtos “derivados” da biblioteca de referência são criados e sua distribuição é
controlada de acordo com um procedimento documentado.
14. O estado dos itens/unidades de configuração é registrado de acordo com um
procedimento documentado.
15. Relatórios padronizados documentando as atividades de GCS e o conteúdo das
configurações-base de software são preparados e disponibilizados a todos os grupos e
indivíduos envolvidos.
16. Auditagens de configurações-base de software são conduzidas de acordo com um
procedimento documentado.
Medição e análise
17. Medidas são tomadas e usadas para determinar o estado das atividades de GCS.
Verificação da implementação
18. As atividades de GCS são revisadas com a gerência superior periodicamente.
19. As atividades de GCS são revisadas com o gerente de projeto periodicamente ou
quando um evento o exigir.
20. O grupo de GCS periodicamente audita as configurações-base de software para
verificar que elas estejam em conformidade com a documentação que as define.
21. O grupo de garantia da qualidade de software revisa e/ou audita as atividades e os
produtos de trabalho para a GCS e registra os resultados.
7.4 Iniciativas no Brasil
No Brasil, a elaboração de normas para a área de Engenharia de Software é capitaneada pelo
Subcomitê de Software da ABNT (Associação Brasileira de Normas Técnicas), com sede em
Curitiba – PR.
O esforço do subcomitê é orientado para a geração de normas brasileiras de engenharia de
software tomando por base os esforços realizados no comitê conjunto ISO/IEC JTC1.
Como resultado deste esforço nacional, já foi publicada a norma NBR 12207 [ABN 97], que é
tradução da norma ISO/IEC 12207, e está sendo encaminhada a criação de uma norma
brasileira correspondente à ISO/IEC TR 15846, cuja tradução encontra-se em processo de
aprovação pela ABNT.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
71
8 IMPLEMENTAÇÃO DE GCS
Implementar GCS implica adotar procedimentos que afetam todos os setores de uma
organização, pois ela é um processo complexo que envolve aspectos técnicos, gerenciais e
culturais. Seu sucesso depende mais de fatores culturais que de fatores técnicos e gerenciais.
Seus conceitos são fáceis de serem entendidos mas difíceis de serem colocados em prática.
Muitas empresas julgam, equivocadamente, que a simples compra de uma ferramenta adequada
de GCS irá resolver os seus problemas. Pesquisas conduzidas pelo Gartner Group [SAT 95]
revelam que o custo da ferramenta representa apenas 10% no custo total de adoção de GCS. Os
restantes 90% relacionam-se com gastos com pessoal, equipamentos e etc.
Para assegurar uma solução efetiva de GCS uma organização deve ater-se às complexidades
que surgem quando da implementação de uma modificação. Essas complexidades incluem:
Aspectos Técnicos: qual ferramenta adotar, como configurá-la, usabilidade, etc.
Aspectos Gerenciais: como planejar o processo, acompanhar modificações, estabelecer
prioridades, cronogramas, etc.
Aspectos Organizacionais: infra-estrutura da organização, autoridades e responsabilidades.
Aspectos Culturais: como as pessoas agem em busca dos seus objetivos, qual a cultura
existente na organização e qual a maneira mais adequada de se fazer mudanças em tal cultura.
Além dos aspectos acima mencionados deve-se considerar aspectos políticos, aspectos de risco,
processos relacionados e aspectos pessoais relacionados com as modificações. A maior barreira
a ser transposta pela organização é mudar a maneira como as pessoas vêm a GCS.
A implementação de Gerência de Configuração inicia-se com a elaboração de um Plano de
Gerência de Configuração, cujo objetivo básico é delinear como será aplicada a Gerência de
Configuração. Ele pode abranger um projeto específico ou toda uma organização, devendo ser
elaborado, de preferência, antes do início do desenvolvimento, constituindo uma peça chave na
implantação de GCS. O Plano de GCS deve abordar os seguintes tópicos principais:
• Atividades de GCS a serem realizadas e seu relacionamento com o ciclo de vida;
• Organização de GCS;
• Autoridades e responsabilidades de GCS;
• Recursos necessários para realizar as atividades de GCS;
• Inferfaceamento com outras organizações;
• Papéis, políticas e procedimentos de GCS;
• O processo de controle de modificações;
• Níveis de controle de GCS;
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
72 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
• Requisitos para a biblioteca de GCS;
• Composição do comitê de Controle de Configuração.
São relacionadas a seguir, algumas regras básicas para elaborar um Plano de Gerência de
Configuração:
1.
 
Buscar e revisar padrões;
2.
 
Criar um esqueleto do plano;
3.
 
Usar o esqueleto como guia para escrever seus próprios processos e procedimentos;
4.
 
Documentar o processo em seu plano.
A estrutura geral de plano de GCS definida pelas normas IEEE Std: 828-1998 e ANSI/IEEE
Std 1042-1987, e exibida a seguir, constitui um excelente ponto de partida para a elaboração de
um plano. Como um exemplo de aplicação, o Apêndice A apresenta um plano de GCS
elaborado com base nesta estrutura.
1 Introdução
2 Gerência
2.1 Organização
2.2 Responsabilidades de GCS
2.3 Políticas, Diretivas e Procedimentos Aplicáveis
3 Atividades de GCS
3.1 Identificação de Configuração
3.2 Controle de Configuração
3.3 Administração de Estado
3.4 Auditagens e Revisões de Configuração
3.5 Controle de Interfaces
3.6 Controle de Fornecedores e Subcontratados
4 Implantação
5 Recursos
6 Manutenção do Plano
A importância maior de um Plano de Gerência de Configuração é significar que, na concepção
do projeto ou da organização, houve a preocupação com o controle das modificações e com a
qualidade dos produtos. O fato do plano ter sido elaborado, por si só, denota um fato positivo.
O Plano de Gerência de Configuração valoriza o projeto.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
73
9 EXEMPLO DE APLICAÇÃO: GCS PARA PEQUENAS EMPRESAS
9.1 Introdução
Este capítulo apresenta uma experiência de implantação de processo de gerênciade
configuração de software num pequena empresa, realizada pelo Grupo de Tecnologia para
Gerência de Configuração de Software do ITI. O objetivo é mostrar uma maneira de implantar
GCS numa empresa de pequeno porte com poucos recursos, principalmente de pessoal.
9.2 Caracterização do Problema
No primeiro semestre de 1997, o GTGCS foi procurado por um pequeno desenvolvedor de
software, a empresa DIGIARTE Ltda. de Campinas, SP, que estava enfrentando problemas de
controle de seus produtos.
O produto principal da empresa era um sistema de software de automação comercial
denominado gerenteMaster, desenvolvido através do Microsoft FoxPro e composto por 1.500
arquivos-fonte. Estava com 4,5 anos de existência e base instalada de 100 clientes. Possuía
duas características marcantes: não havia passado por um processo de desenvolvimento bem
definido e estava em permanente evolução, sendo freqüentemente modificado para corrigir
defeitos e para incorporar novas funcionalidades.
O principal problema sendo experimentado pela empresa era o engessamento da evolução do
gerenteMaster: grande número de modificações enfileiradas, dificuldades para priorizar a
aplicação das modificações, serialização estrita das modificações e incapacidade de conduzir
caminhos paralelos de evolução para testar novas funcionalidades antes de aplicá-las ao
produto. Além disso, havia ainda incapacidade de recuperação de versões anteriores do produto
e incapacidade de rastrear as modificações realizadas.
9.3 Estratégia de Abordagem
Visando melhorar, através do controle, a evolução do produto gerenteMaster, iniciou-se um
projeto cuja meta era estabelecer um conjunto mínimo de práticas de GCS na DIGIARTE. O
projeto foi estruturado em cinco fases:
(a) Levantamento da Empresa;
(b) Levantamento dos requisitos de GCS;
(c) Elaboração do plano de GCS;
(d) Implantação do plano;
(e) Monitorização, acompanhamento evolução do plano.*
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
74 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
9.4 O Plano de Gerência de Configuração de Software
No que diz respeito à utilização de práticas de Engenharia de Software pela DIGIARTE, na
fase de levantamento de informações, foram constatadas:
• Inexistência de processo bem definido de desenvolvimento;
• Documentação deficiente e desatualizada;
• Inexistência de atividades sistemáticas de teste, sejam testes de unidade ou testes
funcionais;
• Inexistência de controle das modificações, não havendo responsabilidades ou autoridades
bem definidas;
• Inexistência de práticas de controle de versões, sendo armazenada apenas a versão mais
recente do produto;
• Modificações realizadas diretamente na versão mais recente, que se fundem a ela de
maneira indistinguível.
Para abordar estas questões, foi definido um plano de GCS estabelecendo:
• Estrutura organizacional para administrar o produto;
• Processo de modificação;
• Estrutura de Armazenamento e ferramenta de controle de versões;
• Processo de verificação do produto;
• Política de liberação de versões do produto.
Estrutura Organizacional
A estrutura organizacional de GCS foi baseada no padrão genérico de organização descrito no
item 4.7, compondo-se de quatro elementos organizacionais:
• Responsável pela GCS (RGCS), encarregado da operação geral do processo;
• Conselho de Controle de Modificações (CCM), responsável pela aprovação ou não de
mudanças propostas;
• Equipe Técnica (ET), responsável pela implementação das modificações aprovadas pelo
CCM;
• Responsável pela Verificação (RV), encarregado de verificar se as modificações
realmente foram implementadas apropriadamente através de inspeção da documentação e
testes funcionais.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
75
A figura 9.1 ilustra a estrutura organizacional estabelecida. O relacionamento entre os
elementos ficará mais claro na descrição do processo que é feito em seguida.
Figura 9.1 – Estrutura Organizacional de GCS
Processo de Modificação
O processo de modificação estabelece um procedimento bem definido e documentado para o
encaminhamento, registro e implementação de modificações do produto. De maneira sucinta,
os pontos a seguir descrevem o processo:
• Toda modificação inicia-se com a geração de uma Proposta de Modificação (PM). Uma
PM descreve uma modificação desejada para a evolução do sistema ou para resolver um
problema detectado pela equipe ou informado por cliente. Qualquer membro da equipe
técnica da DIGIARTE tem autoridade para gerar uma PM e isto é feito através de um
formulário apropriado. O objetivo de uma PM não é descrever como uma modificação
deve ser realizada, mas qual alteração se deseja, ou qual problema deve ser resolvido.
• As PMs geradas são encaminhadas ao RGCS que, por sua vez, após verificar seu correto
preenchimento, agenda-as para deliberação na próxima reunião do CCM.
• Na reunião de CCM, as PMs agendadas são avaliadas, deliberando-se quanto à
oportunidade de serem incorporadas ao gerenteMaster.
• As PMs aprovadas para implementação são transformadas em Solicitações de
Modificação (SM), que são basicamente ordens de serviço para a implementação das
modificações. Uma SM pode corresponder a uma única PM ou então aglutinar um
conjunto de PMs. De qualquer forma, uma SM é uma unidade de modificações, ainda
que tenha sido gerada a partir de várias PMs. Cada SM estabelece o escopo da
modificação a ser realizada, para isto anexando as PMs que lhe deram origem, e é
atribuída explicitamente a um conjunto de elementos da equipe técnica que passam a ser
os responsáveis pela implementação da modificação.
ETET RGCSRGCS
CCMCCM
RVRV
Conselho de
Controle de Modificações
Responsável pela
Verificação
Repositório
Responsável
pela GCS
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
76 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
• A partir da SM, os técnicos responsáveis preparam uma Descrição de Projeto de
Modificação (DPM) que descreve como a modificação será implementada, identificando
os objetos básicos que serão modificados. A DPM elaborada é encaminhada ao RGCS
que a envia ao CCM para aprovação final de implementação.
• Obtida a aprovação, o RGCS prepara área de trabalho exclusiva para a realização da
modificação e torna disponíveis nesta área todos os objetos do gerenteMaster: os que
serão modificados com permissão de escrita e os que serão utilizados como apoio a testes
com permissão de leitura apenas.
• A equipe técnica responsável realiza a modificação, efetua os testes necessários, gerando
um relatório de testes, e gera para cada módulo modificado uma Descrição de
Modificação (DM) que, como o próprio nome indica, descreve as mudanças realizadas.
• Terminada a modificação, os técnicos responsáveis encaminham para auditagem de
modificação, por intermédio do RGCS, as DMs, o relatório de testes e a área de trabalho
contendo o gerenteMaster modificado.
• Se as modificações forem aprovadas pela auditagem de modificação os módulos
modificados são incorporados aos repositórios do gerenteMaster, gerando uma versão
interna do produto, que não é oficial e, portanto, não é distribuída aos clientes. Se a
modificação não for aprovada pela auditagem de modificação, a equipe técnica recebe de
volta a área de trabalho e toda a documentação para as correções necessárias.
A figura 9.2 ilustra o processo de modificação definido
Figura 9.2 – Processo de Modificação
CCMCCM
SMSM
SMSM
SMSM
equipeequipe
CCMCCM
DPMDPM
auditagemauditagem repositóriorepositórioPMPM
PMPM
PMPM
modificaçãomodificação
++
DMDM
++testestestes
aprova
aprova
Solicita revisão
PMPM
PMPM
PMPM
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
77
Estrutura de Armazenamento
A estrutura de armazenamento estabelece os repositórios para as versões oficiais do produto e
as áreas de trabalho para a implementação e teste de modificações de maneira isolada. Para
suporte ao gerenciamento dos repositórios, foi escolhida a ferramenta de controle de versões
"MKS Source Integrity".
Processo de Verificação
O processo de verificação de produto objetiva preservar a integridade do produto e a correta
aplicação de modificações. É formado por dois tipos de verificações ou auditagens: auditagens
de modificação, que são realizadas como critério para aceitação de uma modificação ao
produto, e auditagens de distribuição, que são testes funcionais realizados como critério para a
liberação de versões do produto aos clientes.
Política de Liberação
A política de liberação define dois tipos de distribuições do produto: distribuições regulares e
distribuições excepcionais.
Distribuições regulares são liberações periódicas do produto em que cada distribuição
incorpora as modificações realizadas no produto desde a distribuição regular anterior.
Distribuições excepcionais são liberações que visam acomodar correções urgentes de erros
que não podem aguardar a próxima distribuição regular, modificações em versões anteriores à
versão mais recente ou versões especiais contendo funcionalidades experimentais para clientes
escolhidos (ß-testes). As distribuições excepcionais podem ser de dois tipos: intermediárias e
variantes.
Distribuição excepcional intermediária é uma distribuição estabelecida antes do prazo previsto
para a próxima distribuição regular, e que incorpora todas as modificações realizadas na
distribuição regular mais recente até o momento de sua geração.
Distribuição excepcional variante é uma distribuição gerada como resultado da aplicação de
uma modificação específica à distribuição regular mais recente, e que não incorpora outras
modificações já aplicadas ao gerenteMaster no momento de sua geração.
De maneira geral, é remetida aos clientes apenas a distribuição regular mais recente do
gerenteMaster. As distribuições excepcionais são enviadas de maneira restrita apenas a
clientes específicos.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
78 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A figura 9.3 ilustra a política de liberação adotada.
Figura 9.3 – Política de Liberação & Distribuições
9.5 Resultados Obtidos
O projeto de implantação de GCS foi iniciado em julho de 1997 e o processo de GCS entrou
formalmente em operação em janeiro de 1998.
A partir de informações prestadas pelos responsáveis da DIGIARTE, identificam-se as
seguintes melhorias no controle do gerenteMaster: evolução do produto mais racional; maior
rapidez em incorporações de novas funcionalidades; capacidade de condução de linhas
paralelas de evolução para testar novas idéias; capacidade de atender a pedidos de modificação
de clientes com versões mais antigas e redução de custos de modificações.
Do ponto de vista de práticas de engenharia de software, constatam-se: melhora na
documentação do produto, pois toda modificação tem de ser documentada; introdução de
práticas de verificação de documentação, exigidas nas auditagens de modificação, e introdução
de práticas de teste, tanto de testes de unidade, exigidos nas auditagens de modificação, como
de testes funcionais, presentes em ambos os tipos de auditagens.
Adicionalmente, outro resultado bastante importante do trabalho foi mostrar que é possível
estabelecer práticas de GCS em pequenas empresas desenvolvedoras de software e que estas
práticas não apenas propiciam produtos de software melhor controlados, como também
permitem a introdução de outras práticas de engenharia de software importantes para processos
e produtos de software de melhor qualidade.
m3
m2
m1
Distribuição Regular
Auditagem de modificação
+
Auditagem de distribuiçãoAuditagens de modificação
Distribuição Regular
m5m2
Distribuição
Variante
Distribuição
Variante
m4
2.4.12.4.1
2.42.4
2.52.5
2.4.12.4.1 2.4.22.4.2
m6
m5
Distribuição
Intermediária
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
79
10 EXEMPLO DE APLICAÇÃO: O MODELO NASA DE GCS
O aumento dos custos e da importância do software para a NASA – National Aeronautics and
Space Administration – fez com que ela procurasse melhorar o processo de desenvolvimento.
Um dos produtos desse empenho foi a publicação de uma série de textos que definem o
conceito da NASA a respeito de “processos seguros” a serem usados no desenvolvimento de
software.
O documento NASA SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK
(NASA-GB-9503) editado pela NASA-Software Assurance Technology Center (SATC) em
agosto de1995 é um guia que descreve um modelo de Gerência de Configuração de Software a
ser usado nos centros NASA e pelos seus fornecedores de software. Este capítulo descreve em
linhas gerais o modelo adotado.
10.1 Definição
Gerência de Configuração de Software: processo cujo objetivo é a identificação da
configuração do software em pontos discretos no tempo, e o controle sistemático das
modificações de cada configuração identificada com o propósito de manter a integridade e a
rastreabilidade do software por todo o seu ciclo de vida.
10.2 Funções de GCS
As principais funções da Gerência de Configuração de Software são:
• Identificação de Configuração (Configuration Identification): identificação dos
componentes que constituem o sistema de software e que definem suas características
funcionais;
• Controle de Configuração (Configuration Control): controle das mudanças nos
componentes;
• Administração de Estado (Configuration Status Accounting): relato do estado de
mudanças propostas, dos componentes e do sistema de software;
• Auditagem de Configuração (Configuration Authentication): autenticação de que os
itens sob controle atendem a seus requisitos.
10.3 Conceitos básicos
Configuração: conjunto das características físicas e funcionais definidas em documentação
técnica e concretizadas num produto.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
80 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Item de Configuração de Software (ICSW): conjunto de elementos logicamente inter-
relacionados que constitui um elemento discreto de software, parte constituinte da configuração
do produto.
A figura 10.1 ilustra os dois conceitos acima.
Figura 10.1- Configuração e Itens de Configuração de Software
Configuração-Base: configuração do software no término de cada fase do ciclo de vida. Ao
ser estabelecida uma configuração-base incorpora a configuração-base anterior e os produtos
da fase corrente. São estabelecidas configurações-base do adquirente e do fornecedor.
10.4 Estrutura organizacional de GCS
São os seguintes os elementos que formam a organização de GCS:
RGCS: Responsável pela Gerência de Configuração de Software. Responde pelas atividades:
• elaboração do Plano de Gerência de Configuração de Software;
• operação geral do sistema de GCS.
Bibliotecário: Responsável pela manutenção das bibliotecas de GCS. É responsável por:
• acesso aos repositórios;
• integridade dos repositórios.
CCM: Comitê de Controle de Modificações. Responde pelas atividades de deliberação sobre
modificações:
• disposição final sobre modificações;
• múltiplos níveis.Configuração
Item de
configuração
de software
Configuração
Item de
configuração
de software
Configuração
Item de
configuração
de software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
81
10.5 Ciclo de Vida
O ciclo de vida de um produto é na verdade, como caracteriza o documento, um ciclo de
aquisição, isto é, engloba as atividades que devem ser realizadas pelo adquirente do software e
as atividades do desenvolvedor. A figura 10.2 ilustra o ciclo de vida de um software e os
subitens a seguir descreverão sucintamente cada uma das fases.
Figura 10.2- Ciclo de Vida do Software
10.5.1 Fase Conceito e Iniciação
Durante a fase “Conceito e Iniciação”, o conceito inicial do software é desenvolvido, estudos
de viabilidade são conduzidos e os requisitos do sistema alocados ao software são identificados
e estabelecidos. O plano de gerência de software do adquirente é, então, redigido e aprovado e
uma estratégia de aquisição é elaborada que, em geral, é baseada num processo de
concorrência.
O RGCS do adquirente é responsável por elaborar o plano de GCS relativo ao adquirente, isto
é, relativo ao projeto de aquisição e, paralelamente, por redigir os requisitos de GCS que
deverão ser satisfeitos pelo fornecedor. Estes requisitos farão parte dos editais de concorrência.
Durante a avaliação das propostas dos concorrentes, o RGCS participa do processo de escolha,
avaliando a parte das propostas referentes às atividades de GCS.
A fase termina com a seleção do fornecedor e com a revisão do plano de gerência de software
do projeto, do plano de GCS do projeto e dos requisitos de sistema estabelecidos. Como
resultado, é estabelecida a Configuração-Base Inicial do Adquirente, contendo:
• Plano de Gerência de Software
• Plano de Gerência de Configuração de Software (adquirente)
• Requisitos de sistema alocados ao software
C-B de CódigoC-B de Código
C-B de ProdutoC-B de Produto
C-B de Produto AceitoC-B de Produto Aceito
C-B Inicial do AdquirenteC-B Inicial do Adquirente
Operação e Manutenção
Aceitação e Entrega
Integração e Teste
Implementação
Projeto Detalhado
Arquitetura
Requisitos
Conceito e Iniciação
C-B de RequisitosC-B de Requisitos
C-B de AlocaçãoC-B de Alocação
C-B de ProjetoC-B de Projeto
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
82 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
10.5.2 Fase Requisitos
Durante a fase “Requisitos”, o conceito do software e os requisitos do sistema alocados ao
software são analisados, reelaborados e documentados como os requisitos do software.
Planejamento de testes é iniciado com a definição de um método para verificar cada requisito e
a elaboração de um plano preliminar de testes. Riscos são identificados e mecanismos de
controle e gerência de riscos são estabelecidos. Adicionalmente, o tamanho e a abrangência do
restante do projeto são reavaliados e alterações de cronograma e recursos, realizadas.
Durante a fase, o RGCS do fornecedor deve finalizar o plano de GCS e submetê-lo ao
adquirente para revisão. O RGCS do adquirente, por sua vez, fará uma avaliação do plano de
GCS do fornecedor para se certificar de que todos os requisitos de GCS definidos na fase
anterior foram satisfeitos e de que o plano está completo. O plano, uma vez acordado entre as
duas partes, será colocado sob o controle de GCS do fornecedor. Muitas vezes é também
colocado sob controle de GCS do adquirente, sendo, nesse caso, incluído na configuração-base
inicial do adquirente.
A Configuração-Base de Requisitos é estabelecida após o término da fase e a resolução
satisfatória das questões e pontos levantados na Revisão de Requisitos de Software (SSR –
Software Requirements Review), que é o critério de terminação da fase. O conteúdo da
configuração-base será:
• Especificação de Requisitos de Software
• Documento de requisitos de interface
• Plano de desenvolvimento de Software
• Plano de GCS (fornecedor)
O conteúdo da Configuração-Base de Requisitos será parte permanente de todas as
configurações-base posteriores e referência para a verificação de todo o esforço de
desenvolvimento subseqüente. Quaisquer mudanças propostas desta configuração-base deverão
seguir o processo de controle de modificações definido pelo plano de GCS.
10.5.3 Fase Arquitetura
O objetivo da fase “Arquitetura” é desenvolver o projeto básico do software, alocando todos os
requisitos a componentes de software. Os requisitos são mantidos sob controle e o conteúdo da
configuração-base de requisitos é somente alterado mediante um processo formal. Em adição, é
dada continuidade ao planejamento de testes, que fora iniciado na fase anterior. A fase termina
com uma revisão preliminar do projeto que estabelece a concordância entre adquirente e
fornecedor sobre a arquitetura do sistema que será produzido. Retrabalho e itens de ação
resultantes da revisão são acompanhados e concluídos.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
83
A Configuração-Base de Alocação é estabelecida após o término da fase e a resolução
satisfatória das questões e pontos levantados na Revisão Preliminar de Projeto (PDR –
Preliminary Design Review). Esta configuração-base é assim denominada porque basicamente
contém o projeto arquitetural do sistema e documentos mostrando como os requisitos são
alocados, isto é, distribuídos, no projeto (design). O conteúdo da configuração-base será:
• Conteúdo da Configuração-Base de Requisitos
• Especificação de Projeto Básico
• Documentos descrevendo como os requisitos foram alocados
• Plano de Testes (alto nível)
O conteúdo da Configuração-Base de Alocação será parte permanente de todas as
configurações-base posteriores e referência para a verificação de todo o esforço de
desenvolvimento subseqüente. Quaisquer mudanças propostas desta configuração-base deverão
seguir o processo de controle de modificações definido pelo plano de GCS.
10.5.4 Fase Projeto Detalhado
Durante a fase “Projeto Detalhado”, o projeto arquitetural, ou projeto básico, é refinado até o
nível de unidades de software. Documentos de controle de interface e planos de teste são
revisados e completados. Durante a fase, tanto os requisitos como o projeto básico estão sob o
controle de GCS do fornecedor, pois fazem parte da configuração-base de alocação, e somente
podem ser modificados mediante um processo formal.
A Configuração-Base de Projeto é estabelecida após o término desta fase e a resolução
satisfatória das questões e pontos levantados na Revisão Crítica de Projeto (CDR – Critical
Design Review). O conteúdo da configuração-base será:
• Conteúdo da Configuração-Base de Alocação
• Especificação de Projeto Detalhado
• Plano de Testes (final)
O conteúdo da Configuração-Base de Projeto será parte permanente de todas as configurações-
base posteriores e referência para a verificação de todo o esforço de desenvolvimento
subseqüente. Quaisquer mudanças propostas desta configuração-base deverão seguir o
processo de controle de modificações definido pelo plano de GCS.
10.5.5 Fase Implementação
Durante a fase “Implementação”, o software é codificado e submetido a testes de unidade. A
elaboração da documentação do produto é iniciada e evoluída até uma forma quase final,
incluindo a documentação interna do código.
Os componentes de software (unidades), após terem sido codificados, aprovados nos teste de
unidade e aprovados em inspeções de código (peer reviews) são transferidos do controle dos
desenvolvedores para uma biblioteca de programas sob o controle de GCS do fornecedor.Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
84 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
A Configuração-Base de Código consolida os resultados desta fase. Entretanto, diferentemente
das demais configurações-base, ela não é estabelecida como um evento único, ao final da fase.
A configuração-base tem seu estabelecimento iniciado com o encaminhamento ao RGCS da
primeira unidade de código testada e aprovada na revisão de código, e é sucessivamente
atualizada, conforme cada uma das demais unidades de código é terminada e encaminhada ao
controle de GCS. Após o encaminhamento ao RGCS de todas as unidades de código e de todos
os demais documentos elaborados e revisados na fase, a configuração-base incorpora a
Configuração-Base de Projeto e é considerada estabelecida. Assim, o conteúdo da
configuração-base será:
• Conteúdo da Configuração-Base de Projeto
• Código-fonte
• Manuais de usuário
• Documentação de código
A Configuração-Base de Código é normalmente uma configuração-base interna, isto é, seu
conteúdo não é distribuído ao adquirente, nem para revisão. Ela será utilizada como referência
para os testes de integração que serão realizados na próxima fase. Depois de seu
estabelecimento, quaisquer mudanças propostas desta configuração-base deverão seguir o
processo de controle de modificações definido pelo plano de GCS.
10.5.6 Fase Integração e Teste
Os objetivos da fase “Integração e Teste” são integrar as unidades de software num sistema
completo, identificar e corrigir quaisquer não-conformidades e realizar as preparações para a
aceitação formal do sistema. Durante a fase, o plano de teste é executado, a documentação é
atualizada e completada e os produtos são finalizados para distribuição.
Depois que os componentes de software foram integrados e testados, o software integrado é
colocado na biblioteca de programas, sob controle de GCS. Uma vez na biblioteca, o software
testado somente pode ser alterado mediante o processo formal de modificação.
A fase termina com a Revisão de “Prontidão” para Teste (TRR – Test Readiness Review). Após
a resolução dos problemas apontados durante a TRR, a Configuração-Base de Produto é
estabelecida. O conteúdo da configuração-base será:
• Configuração-Base de Código
• Código Testado
10.5.7 Fase Aceitação e Entrega
Durante a fase “Aceitação e Entrega”, procedimentos formais de aceitação são conduzidos. No
mínimo, deverá haver uma demonstração orientada pelos requisitos para comprovar que o
software de fato os satisfaz. O processo pode incluir também testes específicos do adquirente,
testes de campo ou outros tipos de arranjos que têm como objetivo garantir que o software
funcionará corretamente em seu ambiente destino.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
85
São realizadas também, sob coordenação da GCS, duas auditagens formais antes do término da
fase: a Auditagem Funcional de Configuração (FCA – Functional Configuration Audit) e
Auditagem Física de Configuração (PCA – Physical Configuration Audit). A primeira é
realizada para autenticar que a funcionalidade do software obedece aos requisitos de software
definidos na Configuração-Base de Produto. A segunda é realizada para examinar os itens que
constituem os produtos a serem entregues ao adquirente para verificar se estão em
conformidade com os itens esperados descritos na Lista de Itens a serem entregues definida no
contrato.
Durante esta fase, o software e toda a sua documentação permanece sob o controle do
fornecedor e qualquer alteração somente pode ser realizada de acordo com o processo formal
de modificação definido no plano de GCS.
Por fim, é realizada a Revisão de Aceitação de Software, que é constituída pela revisão dos
relatórios dos testes e verificações realizadas. Sendo concluída a revisão de forma satisfatória,
o software e toda a sua documentação, que constituem a Configuração-Base de Produto
atualizada, são transferidos para o adquirente e é, então, estabelecida, sob o âmbito da GCS do
adquirente, a Configuração-Base de Produto Aceito.
10.5.8 Fase Operação e Manutenção
Durante esta fase o software é utilizado para cumprir os objetivos pelos quais foi adquirido.
Correções e modificações são realizadas para garantir a continuidade de sua operação e para
atualizá-lo de acordo com a evolução das necessidades de seus usuários. Mudanças no software
podem variar de pequenas ações corretivas até alterações funcionais maiores que requeiram um
processo de ciclo de desenvolvimento completo para serem implementadas.
Durante esta fase, que termina somente com a desativação final do produto, o software e toda a
sua documentação, consolidados na Configuração-Base de Produto Aceito, estão sob estrito
controle da GCS do adquirente e nenhuma modificação pode ser realizada sem um processo
formal de modificação.
A figura 10.3 ilustra o ciclo de vida de software.
Figura 10.3 - Ciclo de Vida de Software
ConceitoConceito
ee
IniciaçãoIniciação
RequisitosRequisitos ArquiteturaArquitetura ProjProj. . DetDet.. ImplemImplem.. IntInt. e . e TestTest.. AceitAceit..ee
EntregaEntrega
OperOper..
ee
ManutManut..
Inicial do AdquirenteInicial do Adquirente
RequisitosRequisitos AlocaçãoAlocação ProjetoProjeto CódigoCódigo ProdutoProduto
Produto AceitoProduto Aceito
A
dq
u
ire
n
te
Fo
rn
e
ce
do
r
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
87
11 CONCLUSÃO
Software tornou-se uma tecnologia essencial em todos os setores da sociedade, tanto em
aplicações de alto risco envolvendo vidas humanas quanto em aplicações puramente
financeiras, ao favorecer a otimização de todos os processos implícitos a estas áreas.
A produção deste bem econômico da nova Economia Digital, dada a sua natureza lógica e
intelectual, independe de toda e qualquer dependência tecnológica anterior, inclusive em
termos de hardware. Neste sentido, a indústria de software no Brasil é uma ótima oportunidade
para incrementar o desenvolvimento do país, revestindo-se de importância estratégica ao
contribuir para o desenvolvimento social e econômico da nação.
A inserção competitiva do software brasileiro no mercado externo é fundamental, uma vez que
o mercado mundial para este tipo de produto movimenta bilhões de dólares anualmente.
Entretanto, isso não se dará somente por critérios subjetivos, como criatividade por exemplo,
mas também por apresentar inovação, qualidade, e adequação a padrões de qualidade e de
produtividade internacionais.
Uma vez que a atividade de produção de software está inserida no contexto de um mercado
internacional extremamente competitivo e rentável, que exige tempos de produção menores
(um concorrente pode lançar um produto antes e ganhar espaço no mercado) e altos níveis de
qualidade, o produto de software deve se adequar a esta realidade, ao reduzir seu tempo de
ciclo de vida e aumentar seu nível de qualidade. Isto, entretanto, não é simples, pois segundo
Pressman [PRE 95], "o software tem se tornado cada vez mais complexo e o tamanho dos
programas resultantes aumenta proporcionalmente". Esse ganho de tempo, qualidade e
confiabilidade depende do aperfeiçoamento contínuo dos processos envolvidos na produção do
software.
Esses processos devem abranger aspectos técnicos, gerenciais e culturais envolvidos na
produção de software.
Neste texto abordamos o processo de Gerência de Configuração de Software, que por envolver
aspectos gerenciais e culturais da empresa não é de aplicação trivial.
Sua adoção envolve custos que não devem ser ignorados, pois exige investimentoscom
pessoal, materiais, equipamentos e ferramentas de software. Além disso a Gerência de
Configuração precisa ser adaptada para cada projeto ou organização. Não existe padrão geral
de GCS. Cada desenvolvimento ou organização é um caso e como tal deve ser considerado.
Via de regra, acarreta um acréscimo no formalismo no controle e isso deve ser levado em
conta.
O objetivo principal da GCS é o controle dos produtos de software. Portanto as modificações
nos produtos devem ser vistas como naturais e a sua realização deve ser efetuada de forma
segura e controlada. A resistência a mudança, geralmente presente na cultura das empresas, é
um dos grandes impedimentos à adoção de GCS, mas o maior entrave é, via de regra, o
comprometimento insuficiente dos escalões superiores das organizações.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
88 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Custos e benefícios devem ser analisados antes da adoção de um plano de GCS que deve ser
criteriosamente elaborado e colocado em prática com a consciência de sua finalidade, que é
melhorar a qualidade e integridade do produto.
Finalmente, convém enfatizar que a GCS não é um remédio milagroso que cura todos os males
do software mas sim uma disciplina que adequadamente planejada e seguida, propicia produtos
mais confiáveis e de melhor qualidade, ou seja mais competitivos no mercado.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
89
APÊNDICE A - PLANO DE GERÊNCIA DE CONFIGURAÇÃO DO
PROJETO SW_CRIT
Neste apêndice encontra-se um plano de gerência de configuração para um projeto hipotético
SW_CRIT. Tal plano foi baseado no modelo apresentado na norma ANSI/IEEE Std 1042-1987
(Apêndice A: Software Configuration Management Plan for Critical Software for Embedded
Systems). Tal plano é usado como referência no texto deste documento.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
90 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
1 INTRODUÇÃO
Este documento é o Plano de Gerência de Configuração para o SW_CRIT, um sistema que
executa funções críticas que envolvem a vida e segurança de pessoas. A gerência de
configuração desse software durante o seu desenvolvimento é essencial para que o mesmo seja
livre de erros e para a confiabilidade dos itens de configuração.
1.1 Objetivos
Este plano contêm informações sobre os requisitos e procedimentos necessários para as
atividades de gerência de configuração do projeto SW_CRIT. Nele são especificados os
requisitos de gerência de configuração do software e são estabelecidas metodologias para gerar
identificadores de configuração, controlar modificações, manter o acompanhamento de estado,
tanto dos itens de configuração como de suas modificações, e executar auditorias e revisões
durante o projeto e o desenvolvimento dos itens de configuração de software.
1.2 Escopo
Este plano aplica-se a todo o software do sistema SW_CRIT e a sua respectiva documentação.
Ele inclui os arquivos fontes e objetos e os arquivos contendo executáveis. Os itens de
configuração de software referidos no contrato e controlados neste plano incluem:
SW_CRIT- Sistema Operacional
SW_CRIT - Programa de Treinamento
SW_CRIT - Programa de Teste
SW_CRIT - Programas de Aceitação do Hardware
SW_CRIT - Software de Diagnóstico
SW_CRIT - Sistema de Suporte de Software
SW_CRIT - Sistema de Simulação
SW_CRIT - Utilitários
Os elementos da organização envolvida nesse projeto são identificados na figura A-1.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
91
Figura A-1: Organização do projeto SW_CRIT
Este plano aplica-se a todas as fases do ciclo de vida do produto de software até que ele seja
liberado para o cliente. A manutenção do software, após a liberação, será coberta por outro
contrato.
1.3 Definições e mnemônicos
1.3.1 Definições
As definições usadas neste plano estão em conformidade com os padrões da empresa (Vide
<Nome de Documento>). Outras definições estão em conformidade com a norma ANSI/IEEE
Std 729-1983. Ver especificamente: configuração-base, item de configuração, gerência de
configuração, controle de configuração, comitê de controle da configuração, auditoria de
configuração, identificação da configuração, acompanhamento de estado da configuração e
biblioteca de software. As Definições específicas usadas neste documento são:
controle de interface:
processo de:
(1) Identificação de todas as características físicas e funcionais que sejam relevantes para
a interface entre dois ou mais itens de configuração fornecidos por uma ou mais
organizações;
(2) Garantia de que propostas de modificação destas características sejam avaliadas e
aprovadas antes da implementação.
1.3.2 Mnemônicos
Os mnemônicos seguintes são utilizados no texto deste plano:
Gerência do Projeto
Gerência do
 Software
Controle Controle e Qualidade
do Software
Administração Integração
GQS
Garantia de Qualidade
de Software
GCS
Gerência de Configuração
de Software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
92 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
AMS: Autorização para Modificação de Software
CCC: Comitê de Controle de Configuração
FCA: Auditagem Funcional de Configuração (Functional Configuration Audit)
GC: Gerência de Configuração
GCS: Gerência de Configuração de Software
GQS: Garantia de Qualidade de Software
IC: Item de Configuração
ICSW: Item de Configuração de Software
I&T: Integração e Teste
PCA: Auditagem Física de Configuração (Physical Configuration Audit)
PGCS: Plano de Gerência de Configuração de Software
PGQS: Plano de Garantia de Qualidade de Software
RC: Revisão de Código
RCP: Revisão Crítica de Projeto
RES: Revisão de Especificação de Software
RGCS: Responsável pela Gerência de Configuração de Software
RMS: Requisição de Modificação de Software/Sistema
RPP: Revisão Preliminar de Projeto
RRS: Revisão de Requisitos do Sistema
SW_CRIT: Software Crítico
1.4 Referências
[1] ANSI/IEEE Std 729-1983, IEEE Standard Glossary of Software Engineering
Terminology.
[2] ANSI/IEEE Std 730-1984, IEEE Standard for Software Quality Assurance Plans.
[3] ANSI/IEEE Std 828-1998, IEEE Standard for Software Configuration Magement Plans
[4] ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.
[5] <Nome de Documento> (Nome do manual de práticas de GCS da empresa)
[6] PDS SW_CRIT: Plano de Desenvolvimento do Software do projeto SW_CRIT.
Os referidos documentos encontram-se disponíveis para o uso na biblioteca da empresa.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
93
2 GERÊNCIA
2.1 Organização
A organização do sistema SW_CRIT foi idealizada para definir de forma clara as autoridades e
as responsabilidades e, também, para fornecer uma estrutura na qual os controles técnicos e
administrativos das atividades de software possam ser efetivamente integradas à qualidade do
produto.
As responsabilidades principais para as várias tarefas de gerência de configuração são
atribuídas conforme ilustra a Tabela 1:
Responsabilidades Gerente de
Projeto
Engenharia
de Software
Autoridade de
GCS
GQS
Identificação de configuração Origina
Aprovação/Liberação da documentação
técnica
Aprova Origina Revisa Revisa
Preparação da modificaçãoOrigina
Controle da modificação Aprova
Implementação da modificação Elabora Revisa
Manutenção da documentação Aprova
Acompanhamento de estado Origina Revisa
Auditagem formal de GCS Aprova Origina Revisa
Definição de configuração-base Aprova Origina Revisa Revisa
Tabela 1- Atribuição de responsabilidades
Dentro da organização do projeto SW_CRIT o gerente de projeto tem responsabilidade total
pelo projeto. No SW_CRIT caberá ao gerente toda a responsabilidade pela gerência de
configuração. O gerente de projeto será o presidente do CCC. O RGCS assessora o CCC. O
RGCS assessora o gerente de projeto no planejamento e elaboração do plano de gerência de
configuração (PGCS) e dos procedimentos relacionados à gerência de configuração e é
responsável por supervisionar sua implementação. Funcionalmente, no que diz respeito à
implementação deste plano, o RGCS subordina-se ao gerente de projeto. Administrativamente,
o RGCS subordina-se ao Departamento de Gerência de Configuração de Software.
2.2 Responsabilidades de GCS
O RGCS detém a autoridade para requerer modificações em práticas e procedimentos que não
atendam aos requisitos contratuais. As responsabilidades gerais do RGCS encontram-se
delineadas na Tabela 1. Elas incluem:
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
94 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
(1) controle da configuração;
(2) administração de estado;
(3) identificação da configuração;
(4) implementação e manutenção do plano de gerência de configuração;
(5) assessoramento do CCC;
(6) estabelecimento e manutenção das configurações-base;
(7) coordenação das auditagens formais;
(8) participação de revisões.
2.2.1 Identificação da Configuração
Identificação da configuração aplica-se a todo o software: código e documentação associada
(especificações, documentos de projeto, listagens de programas/procedimentos, etc.). Cada IC
é constituído do software desenvolvido e da documentação associada. O esquema de
identificação é preparado pelo RGCS com a aprovação do gerente de projeto.
Durante o desenvolvimento a identificação de configuração atua no estabelecimento de
configurações-base e nas liberações, que estão sincronizadas com o cronograma de
desenvolvimento, conforme descrito no plano de desenvolvimento de software.
2.2.1.1 Configurações-Base
Configurações-base são estabelecidas para o controle dos produtos e de suas modificações e
estão sincronizadas como esforço de desenvolvimento. As configurações-base são
estabelecidas sob autoridade do gerente de projeto. O RGCS administra as configurações-base.
No projeto SW_CRIT as configurações-base são:
(1) Configuração-Base Funcional
(2) Configuração-Base de Alocação
(3) Configuração-Base de Projeto Básico
(4) Configuração-Base de Projeto Detalhado
(5) Configuração-Base de Código
(6) Configuração-Base de Produto
Maiores detalhes sobre configurações-base são apresentadas no item 3.1.1.
2.2.1.2 Liberações (Releases)
No decorrer do ciclo de vida de desenvolvimento, segundo a determinação do gerente de
projeto, do gerente de software e do RGCS são realizadas as liberações das configurações-base.
As liberações pertencem a uma das três categorias:
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
95
(1) liberação do desenvolvedor (Liberação pela engenharia)
(2) liberação para GCS (Distribuição preliminar)
(3) liberação final (Distribuição formal para o cliente)
É da responsabilidade do RGCS estabelecer e atualizar os identificadores das
Liberações/Versões.
2.2.1.3 Documentação
A toda documentação ou especificação relevante é atribuída, pelo RGCS, uma identificação.
2.2.2 Controle da Configuração
Todo o software e a respectiva documentação são mantidos numa biblioteca controlada pela
gerência de configuração de software que administra o processo de modificação.
2.2.2.1 Requisição de Modificação de Software/Sistema (RMS)
A RMS é o mecanismo pelo qual as requisições de modificação são apresentadas ao CCC. Esta
ação permite a um desenvolvedor retirar para modificação elemento de software ou documento
da biblioteca sob controle da GCS. O mecanismo para requerer a autorização consiste em
apresentar uma RMS ao CCC requerendo uma aprovação formal para iniciar o trabalho. O
formulário RMS é apresentado no anexo A1;
2.2.2.2 Autorização para Modificação de Software (AMS)
A AMS é usada para requerer a GCS que uma nova versão do software/documentação seja
colocada na biblioteca controlada. Para tal são necessárias as aprovações do gerente de
software, GQS e RGCS. O formulário AMS é apresentado no anexo A2;
2.2.3 Administração de Estado
Uma base de dados das autorizações para modificação de software é usada para gerar relatórios
que rastreiam as modificações sobre todas as configurações-base controladas. Atendendo
solicitações, o RGCS gera relatórios que capturam o estado da documentação e do software.
2.2.4 Auditagens
O RGCS é responsável por coordenar, juntamente com o cliente, todas as auditagens formais.
2.2.4.1 Auditagem de GQS
É da responsabilidade do RGCS auxiliar o GQS nos esforços de auditagem do esforço de
desenvolvimento. O RGCS fornece todo o software e documentos sob controle para minimizar
o esforço requerido pelo GQS para executar a sua função.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
96 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
2.2.5 Comitê de Controle de Configuração (CCC)
O CCC do projeto SW_CRIT é constituída pelo gerente de projeto e pelo RGCS.
O gerente de projeto é o presidente do CCC e tem a responsabilidade final pelas ações do CCC
relativamente a políticas, planos, procedimentos e interfaces de GCS. O RGCS atua como
secretário do CCC. Adicionalmente o CCC poderá incluir pessoal do desenvolvimento,
representante de hardware, representante de testes, clientes e sempre irá incluir um
representante da GQS. As reuniões do CCC serão efetuadas numa periodicidade determinada
pelo gerente do projeto. Quando for necessário, o presidente da CCC poderá convocar reuniões
extraordinárias. Quando uma RMS é analisada pelo CCC, uma das seguintes deliberações a
respeito dela deve ser tomada: aprovada, rejeitada ou deixada pendente (deliberação postergada
para uma próxima reunião).
2.3 Políticas, Diretivas e Procedimentos Aplicáveis
As políticas, diretivas e procedimentos de gerência de configuração que se aplicam a este
projeto estão incluídas como parte da seção de procedimentos deste documento ou são parte de
documentos referenciados em um dos apêndices.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
97
3 ATIVIDADES DE GCS
3.1 Identificação de configuração
3.1.1 Configurações-Base
Configurações-base são estabelecidas como marcos no ciclo de desenvolvimento do projeto
SW_CRIT. São estabelecidas configurações-base referentes ao sistema SW-CRIT e
configurações-base que se referem aos ICSWs de SW_CRIT A figura A-2 ilustra as
configurações-base do projeto as quais são descritas nos próximos subitens.
Figura A-2: Configurações-base do projeto SW_CRIT
3.1.1.1 Configuração-Base Funcional
A configuração-base funcional é estabelecida e identificada quando da aceitação ou aprovação
da Especificação do Sistema do SW_CRIT pelo cliente. Normalmente isso ocorre quando se
completa a revisão dos requisitos do sistema.
3.1.1.2 Configuração-Base de Alocação
A configuração-base de alocação é estabelecida e identificada com a aprovação da
Especificação dos Requisitos de Software dos ICSWs pelocliente. Normalmente isso
corresponde ao término da revisão dos Requisitos de Software. As especificações de requisitos
dos ICSWs e os documentos associados constituem a configuração-base de alocação.
3.1.1.3 Configuração-Base de Projeto Básico
A configuração-base de projeto básico é estabelecida e identificada com a aprovação da
documentação técnica do projeto básico do ICSW correspondente. Normalmente, isso
corresponde à Revisão Preliminar de Projeto. É estabelecida uma configuração-base de projeto
básico para cada ICSW que integra SW_CRIT.
.
.
.
.
.
.
.
.
.
.
.
.
C o n f ig u ra ç ã o -b a s e
F u n c io n a l
C o n f ig u ra ç ã o -b a s e
d e A lo c a ç ã o
C o n f ig u ra ç ã o -b a s e
d e P ro je to B á s ic o
C o n f ig u ra ç ã o -b a s e
d e P ro je to D e ta lh .
C o n f ig u ra ç ã o -b a s e
d e C ó d ig o .
C o n f ig u ra ç ã o -b a s e
d e P ro d u to .
IC S W 1
IC S W 2
IC S W 3
IC S W n
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
98 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
3.1.1.4 Configuração-Base de Projeto Detalhado
A configuração-base de projeto detalhado é estabelecida e identificada com a aprovação da
documentação técnica do projeto detalhado do ICSW correspondente. Normalmente, isso
corresponde à Revisão Crítica de Projeto. É estabelecida uma configuração-base de projeto
detalhado para cada ICSW que integra SW_CRIT.
3.1.1.5 Configuração-Base de Código
A configuração-base de código é estabelecida após a codificação, teste de unidade e revisão de
código (peer-review) das unidades de software que compõe o ICSW a que esta configuração-
base se refere. Esta configuração-base é constituída por todas as unidades de código do ICSW
bem como os relatórios de teste de unidade e os relatórios de revisão de código. É estabelecida
uma configuração-base de código para cada ICSW que integra SW_CRIT.
3.1.1.6 Configuração-Base de Produto
A configuração-base de produto é estabelecida após a aprovação, pelo cliente, do Teste de
Aceitação do Produto em seguida ao término da última Auditagem Funcional de Configuração
(FCA).
3.1.2 Documentação
Toda a documentação de suporte gerada para este projeto é identificada pelo uso da convenção
seguinte: <Sigla do Projeto>, uma abreviação para a nomenclatura do documento, um número
único de quatro dígitos atribuído pelo responsável pela gerência de configuração e o número da
versão/revisão/atualização do produto. Exemplo: SW_CRIT-PDSW-0024-1.2.1. A Tabela 3
relaciona os documentos que são produzidos durante o projeto.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
99
Configuração-Base Propósito Revisão/Auditagem
Funcional Estabelecimento de funções RRS
de Alocação Definição de requisitos RES
de Projeto Básico Projeto em alto nível completo RPP
de Projeto Detalhado Projeto detalhado completo RCP
de Código Codificação da unidades de software Testes de unidade e RC
de Produto Aprovação conforme Teste de
Aceitação do Produto
FCA/PCA
Tabela 2: Objetivos das Configurações-Base
Nomenclatura de Documento Mnemônico
Plano de Gerência de Configuração do Software PGCS
Projeto Detalhado de Software PDSW
Plano de Desenvolvimento de Software PDS
Procedimentos de Teste de Software PRTS
Especificação de Produto de Software EPS
Plano de Garantia de Qualidade do Software PGQS
Especificação de Requisitos de Software ERS
Especificação do Sistema de Software ESS
Projeto Básico de Software PBS
Plano de Teste do Software PLTS
Relatório de Teste de Software RTS
Tabela 3: Documentos de SW_CRIT
3.1.3 Partes do software
Os itens de configuração de software, componentes e unidades são identificados por rótulos de
identificação únicos.
3.2 Controle de configuração
Controle de configuração é aplicado a todos os documentos e código, incluindo software
operacional e de suporte do projeto SW_CRIT.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
100 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
3.2.1 Função do Comitê de Controle da Configuração
O Comitê de Controle da Configuração revê as propostas de modificação para assegurar a
concordância com as especificações aprovadas, e avalia impactos sobre o software existente.
Cada modificação de engenharia ou relato de problema que for iniciado envolvendo um item
de configuração formalmente identificado é avaliada pela CCC para determinar sua
necessidade e seu impacto. Os membros da CCC assinam eletronicamente um documento para
indicar que eles revisaram as modificações e forneceram as suas recomendações ao presidente
da CCC. A CCC aprova, desaprova ou posterga a decisão sobre todas as modificações. O
instrumento para submeter modificações de software ou documentação é a Requisição de
Modificação de Software/Sistema.
3.2.2 Requisição de Modificação de Software/Sistema (RMS)
O formulário RMS (anexo A1) contém uma descrição da modificação desejada ou do problema
detectado, informações identificando a origem da requisição e mais algumas informações
básicas que auxiliam a avaliar a requisição. A RMS relaciona-se apenas a software ou
documento que está em configuração-base. A RMS pode ser submetida por qualquer pessoa
associada ao esforço de projeto ou aos seus produtos. Usualmente a RMS é submetida por um
elemento da equipe de desenvolvimento de software. O responsável pela gerência de
configuração de software constitui o ponto único de recepção e processamento da RMS. Uma
RMS é fechada quando:
(1) testes de integração mostrarem que as modificações foram efetuadas corretamente;
(2) não aparecerem efeitos colaterais resultantes da realização de uma modificação;
(3) a documentação tiver sido atualizada e revisada.
3.2.3 Autorização de Modificação de Software (AMS)
O formulário de autorização de modificação de software (AMS) (anexo A2) é usado para
controlar modificações em todo o software e documentos sob controle da GCS. O AMS é um
formulário on line que os desenvolvedores de software usam para submeter modificações no
software e documentos ao RGCS. As aprovações requeridas para estabelecimento de
configuração-base ou atualização de software de uma configuração-base são as seguintes: da
gerência do projeto, do responsável pela Integração e Testes e do RGCS. As aprovações podem
ser ou por escrito, ou obtidas eletronicamente. A assinatura do RGCS testemunha que a ação
ocorreu. A assinatura do GQS significa que foi verificada a incorporação da modificação. O
RGCS notifica o desenvolvedor através do sistema de correio eletrônico que a modificação
ocorreu para que o desenvolvedor possa apagar as cópias extras das partes modificadas. A base
de dados de AMS e a base de dados RMS são utilizadas para as necessidades de administração
de estado. O processo pelo qual são feitas as modificações é mostrado no anexo A3
(Procedimento para Controle de Modificações no Software/Documentação).
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
101
3.2.4 Ferramentas automatizadas de GCS para controle de modificações
As bibliotecas do sistema SW_CRIT são utilizadas para controlar todos os arquivos contendo
as especificações, a documentação, os planos de teste, os procedimentos e o código-fonte. O
software de suporte (listado abaixo) é mantido, também, sob gerência de configuração. A
estrutura da biblioteca é a seguinte:
(1) biblioteca principal do projeto SW_CRIT
(2) biblioteca de programas
(3) biblioteca de desenvolvimento
Neste projeto as ferramentasde controle das modificações são as seguintes:
(1) Sistema de Gerenciamento de Fontes: Mecanismos para criação e manutenção de
arquivos delta (modificações apenas) na biblioteca principal do SW_CRIT. Apenas o
RGCS possui acesso à biblioteca principal. A biblioteca principal do projeto
SW_CRIT é acessível através do sistema de administração de estado.
(2) Sistema de Gerenciamento de Pacote: É usado para automatizar o processo de
construção (build) e é também usado para auxiliar o RGCS na geração do software.
(3) GCS Get: É uma função invocada pelos desenvolvedores de software para obter os
módulos de software ou parte de programas da biblioteca de programas.
(4) GCS Send: É uma função invocada pelos desenvolvedores de software para introduzir
um módulo de software na biblioteca de programas. O uso desta função
automaticamente gera uma AMS.
3.3 Administração de Estado
O sistema de Administração de Estado é capaz de gerar os relatórios seguintes:
(1) Relatório 1: Lista de todas as requisições de modificação que estiverem no estado não
fechada (isto é, aberta).
(2) Relatório 2: Resumo mensal das bases de dados RMS e AMS .
(3) Relatório 3: Total de todas as RMS submetidas dentro de uma faixa de datas
selecionada pelo usuário, organizadas por ICSW.
(4) Relatório 4: Lista de todas as RMS que estão abertas, fechadas, ou todas (selecionado
pelo usuário).
(5) Relatório 5: Resumo de todas as RMS submetidas por ICSW.
(6) Relatório 6: Resumo das atuais RMS no estado não fechada.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
102 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
(7) Relatório 7: Um pequeno resumo de todas as RMS relativas a um componente de
software em particular no estado aberta, fechada ou todas.Relatório 8: Um
documento de descrição de versão.
(8) Relatório 9: Relatório que fornece o estado de todos os documentos sob gerência de
configuração.
3.4 Auditagens e Revisões de Configuração
O RGCS coordena, juntamente com o cliente, todas as auditagens formais: Auditagem
Funcional de Configuração (FCA) e a Auditagem Física de Configuração (PCA).
3.4.1 Auditagem Funcional de Configuração (FCA)
A auditagem funcional de configuração é executada sobre os itens de configuração de software
quando os testes de aceitação estiverem concluídos. A configuração-base funcional e a
configuração-base de alocação já foram previamente aprovadas pelo cliente.
A auditagem é feita sobre os planos formais de teste, descrições e procedimentos e comparados
com os dados de testes oficiais. Nos resultados busca-se se estão completos e a sua precisão.
Deficiências são documentadas e fazem parte das minutas da AFC.
São estabelecidas e registradas datas para resolver todas as discrepâncias.
3.4.2 Auditagem Física de Configuração (PCA)
Um exame físico é feito em cada ICSW e no produto final para verificar se ele foi construído
de acordo com a sua documentação técnica, isto é, se todos os itens que constituem fisicamente
o ICSW ou produto estão presentes e em conformidade com as especificações. O RGCS é
responsável por providenciar e disponibilizar para a equipe de PCA todas as informações
descrevendo o produto para que possa ser realizada a auditagem.
3.4.3 Revisões
O RGCS participa, com o cliente, de todas as revisões formais. Além disso, a gerência de
configuração conduz duas auditorias informais sobre cada item de configuração durante o seu
ciclo de desenvolvimento. A primeira auditagem informal é exatamente antes do RCP (Revisão
Crítica de Projeto). A segunda auditagem é realizada segundo disposição da autoridade de GCS
no ponto médio entre a RCP e o final do Teste de Aceitação.
3.5 Controle de Interfaces
O controle da interface é realizado da mesma maneira que o hardware, software ou
documentação. Qualquer diferença entre PGQS e o PGCS deve ser resolvida antes do
estabelecimento de qualquer configuração-base.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
103
3.6 Controle de Fornecedores e Subcontratados
3.6.1 Software adquirido de fornecedor
O software adquirido de fornecedor a ser usado no projeto deve estar em conformidade com as
boas práticas de GCS. O fornecedor deve disponibilizar para este projeto uma cópia de seu
próprio plano de gerência de configuração para ser avaliado. O projeto deve assegurar-se de
que a gerência de configuração do fornecedor é adequada. Se o sistema de GCS do fornecedor
for considerado inadequado, ou se não possuir nenhum plano de gerência de configuração
disponível, então, a critério do gerente do projeto, o fornecedor pode ser desqualificado para
fornecer software para esse projeto.
3.6.2 Software subcontratado
Qualquer subcontratado que desejar fazer negócios com este projeto deve fornecer uma cópia
de seu plano de gerência de configuração para avaliação pelo RGCS ou concordar em seguir
este plano de gerência de configuração. Se o plano de gerência de configuração do fornecedor
for julgado inadequado, todas as outras provisões deste plano são aplicáveis. Qualquer
subcontratado que não concorde com essa disposição pode ser desqualificado a critério do
gerente de projeto.
3.6.3 Auditagem de software de fornecedor e de subcontratado
Todos os fornecedores e subcontratados são auditados de acordo com as boas práticas de GCS.
A freqüência e métodos das auditorias são determinadas pelo tamanho, preço e a natureza
crítica do software.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
104 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
4 IMPLANTAÇÃO
O plano de gerência de configuração (PGCS) começa a ser implementado assim que aprovado
pelo gerente de projeto, antes de qualquer revisão formal com o cliente. Qualquer pendência
que for encontrada, uma vez escrito o PGCS, deve ser resolvida o mais cedo possível durante o
período de desenvolvimento e antes do estabelecimento de qualquer configuração-base.
4.1 Comitê de Controle da Configuração
O CCC é estabelecido quando da aprovação do plano de gerência de configuração e antes do
estabelecimento de qualquer configuração-base.
4.2 Estabelecimento de Configurações-Base
As Configurações-base são estabelecidas com as ocorrências de determinados eventos dentro
do ciclo de desenvolvimento de SW_CRIT. O item 3.1.1 descreve a ordem com que as
configurações-base estabelecidas.
4.3 Escalonamento e procedimentos para revisões e auditagens de GCS
Revisões e auditagens serão feitas conforme o que foi estabelecido no plano de
desenvolvimento de software.
4.4 Retenção
Toda a documentação formal produzida para e por este projeto é retida e salva por 20 anos.
Uma segunda cópia de todo o software e documentação é armazenada em um local remoto a,
pelo menos, 30 Km do local de armazenamento principal.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
105
5 RECURSOS
5.1 Recursos Humanos
Exclusivamente para a realização das atividades estabelecidas neste plano de GCS, deverão
estar garantidos durante todo o tempo do projeto os seguintes recursos humanos:
(a) Um projetista de software sênior com experiência em gerência de projeto e treinamento
em gerência de configuração de software para atuar como RGCS. Carga de trabalho: 40
horas semanais.
(b) Um técnico de suporte computacional, com experiência tanto no ambiente
computacional de suporte do projeto como nas atividades de administração das
ferramentas de GCS a serem utilizadas (vide item 5.2). Carga de trabalho: 20 horas
semanais.
(c) 8 horas semanais do gerente de projetopara as atividades de controle de configuração.
(d) 5 horas semanais de cada engenheiro de software alocado ao projeto, para atividades
relacionadas a GCS.
5.2 Ferramentas de Gerência de Configuração
Um conjunto integrado de ferramentas de Gerência de Configuração será utilizado para o
controle da configuração e para administração de estado do projeto. As ferramentas são:
(1) Sistema de Gerenciamento de Fontes (SGS): Essa ferramenta é um sistema de
arquivos para realização dos acessos às bibliotecas do sistema SW_CRIT. Uma
licença é fornecida pelo fornecedor da ferramenta para utilização no projeto.
(2) Sistema de Gerenciamento de Pacote (PGS): Esta ferramenta fornecida por um
fornecedor é utilizada para gerar software automaticamente. Uma licença é
disponibilizada pelo fornecedor para utilização no projeto.
(3) Ferramenta de Requisição de Modificação de Software/Sistema: É uma peça de
software de propriedade do SW_CRIT e possui duas partes: o formulário de entrada e
sua base de dados.
(4) Ferramenta de Autorização de Modificação de Software: É uma peça de software
de propriedade do SW_CRIT e possui duas partes: o formulário de entrada e sua base
de dados.
(5) Ferramenta de Geração de Relatórios da Administração de Estado: É uma peça
de software de propriedade do SW_CRIT. É uma ferramenta de geração de relatórios
que aceita entradas dos seguintes subsistemas:
(a) Sistema de Gerenciamento de Fontes
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
106 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
(b) Sistema de Gerenciamento de Pacotes
(c) Ferramenta de Gerenciamento de Requisições de Modificações de
Software/Sistema
(d) Ferramenta de Gerenciamento de Autorização de Modificação de Software
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
107
6 MANUTENÇÃO DO PLANO
Este plano deverá ser revisto pelo gerente de projeto e RGCS no encerramento de cada fase do
ciclo de vida de desenvolvimento do projeto SW_CRIT. Sempre que necessário, propostas de
modificação deverão ser elaboradas pelo RGCS e aprovadas pelo gerente de projeto. Sendo
realizadas e aprovadas as modificações, o plano modificado passará a vigorar no início da
próxima fase do desenvolvimento.
O RGCS é responsável por manter um registro de evolução do plano contendo data, motivo e
descrição das modificações realizadas.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
108 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Anexo 1: Requisição de Modificação de Sistema/Software - RMS
 RMS No _______________
1. Submetida por:__________________________________________ Data: ___/___/____
Nome do Projeto: _________________________________________________________
2. Nome do Projeto/Documento: _______________________________________________
Versão/Revisão:_________________
3. Tipo da RMS: ( ) Desenvolvimento ( ) Problema ( ) Melhoria/Aperfeiçoamento
4. Descrição Resumida da Tarefa: _______________________________________________
___________________________________________________________________________
5. Descrição Detalhada: _______________________________________________________
___________________________________________________________________________
6. Prioridade do Proponente: [ ] 1 = Crítica 2 = Muito Importante 3 = Importante
 4 = Interessante 5 = Inconveniente
7. Ação CCB:______________________ Prioridade CCB [ ]
8. Atribuída para: ______________________ Data Alvo de Liberação: ___/___/____
9. Comentários sobre a Solução: ________________________________________________
___________________________________________________________________________
10. Programas Afetados:_______________________________________________________
11. Aprovação I&T:________________________________________________ Data: ___/___/____
 Aprovação RGCS:_______________________________________________ Data: ___/___/____
12. Distribuição Efetiva:_____________________________________________ Data: ___/___/____
13. Fechada por: ___________________________________________________ Data: ___/___/____
 AMS de Referência: _____________________
14. Aprovação GQS:________________________________________________ Data: ___/___/____
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
109
Anexo 2: Autorização de Modificação de Software - AMS
 AMS No.:_______________
 Folha No _______________
Submetida por:_______________________ Sistema: __________ Data: ___/___/____ Hora: ___/___/____
ID Versão do Produto: ___________________ Nome do Computador : ______________________________
Nomes de
Entradas
Nomes
Distribuições
Tipos Módulo L
N
A
C
Números de
RMS
Comentários: ____________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
Aprovações I&T GCS SQA
Assinatura:
Data:
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
110 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
Anexo 3: Procedimento para controle de modificações no software/documentação
Desenvolvedor SW
 Passados os Testes
de unidade
Edição de texto,
Compilação, Link Edição
das bibliotecas de trabalho
Atribuição Engenheiro
SW
Aprovação
Desenvolvedor SW
Chefe Equipe
CCC
Chefe de Projeto
Desenvolvedor SW
GCS
GCS
Revisão
Emite RMS
Início
Copia arquivo AMS
Retorna cópia AMS
Atualiza RMS
Compila código
GCS
A
A
Compara Código do
Objeto Capturado com
Objeto Recompilado
Chefe Projeto
Desenvolvedor SW
I&T
Revisa Entrada,
Captura Fonte,
Objeto, Doc’s
Completa AMS,
Anexa RMS
Aprovação
GCS
Aprovação
FIM
 Interessado
Necessidade de Modificação
Identificada
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
111
APÊNDICE B - REFERÊNCIAS BIBLIOGRÁFICAS
[ABN 97] NBR ISO/IEC 12207/1997 Tecnologia de Informação – Processos de ciclo de vida
de software – 1997 – ABNT.
[BAB 86] Babich, W. A.. “Software Configuration Management: Coordination for Team
Productivity”, Addison Wesley Publishing Company–1986–ISBN 0-201-10161-0.
[BER 92] Berlack, R. H. “Software Configuration Management”, John Wiley & Sons, Inc.
New York, 1992.
[BRS 80] Bersoff, E. H.; Henderson, V. D.; Siegel, S. G. “Software Configuration
Management – An Investment in Product Integrity”, Prentice-Hall, N. J. 1980.
[BRS 84] Bersoff, E. H.; “Elements of Software Configuration Management”, IEEE
Transactions on Software Engineering; vol. SE-10, No. 1, January 1984.
[BUC 96] Buckley, F. J. “Implementing configuration management: hardware, software, and
firmware”, Second Edition, IEEE Computer Society Press, 1996.
[BUR 96] Burrows, C.;George, G. W; Dart S. “OVUM Evaluates: Configuration
Management”, OVUM Ltd. 1994.
[CMM 93] Paulk, M. C.; Curtis B.; Chrissis, M.B.; Weber, C.V.; “Capability Maturity Model
for Software, Version 1.1”; CMU/SEI-93-TR-24; FEB/93.
[DAR 96] Dart, S.; “Not All Tools Are Equal”;
http://www.spgnet.com/ADT/oct96/fe1002.htm 1996.
[IEE 98] IEEE, IEEE Standard for Software Configuration Management Plans, IEEE Std
828-1998.
[IEE 87] IEEE, IEEE Guide to Software Configuration Management, ANSI/IEEE Std 1042-
1987.
[ISO 95] ISO/IEC, ISO/IEC 10007:1995 “Quality Management – Guidelines for
Configuration Management”.
[ISO 95] ISO/IEC, ISO/IEC 12207:1995 “Information Technology – Software Life Cycle
Process.
[ISO 98] ISO/IEC, ISO/IEC TR 15846:1998 “Information Technology – Software Life Cycle
Process – Configuration Management for Software.
[PRE 92] Pressman, R. S. “Software Engineering: A Practitioner’s Approach ”, McGraw-Hill,
1992.
[PRE 95] Pressman, R. S. “Engenharia de Software”, Makron Books, 1995.
Instituto Nacional de Tecnologia da Informação
Laboratório de Avaliação e Melhoria de Processos de Software
112 GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE
Evolução de Software sob Controle
[SAT 95] Software Assurance Technology Center – SATC, “Software Configuration
Management Guidebook”, NASA, http://satc.gsfc.nasa.gov/ August 1995.
[STS 94] STSC – Software Technology Support Center, “Software Configuration
Management Technology Report”, Technical Report, Ogden ALC/TISE, Hill AFB,
UT 84056, SEPT/94.