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 controle