OBTENÇÃO DE SOFTWARES DE QUALIDADE ATRAVÉS DE

GERENCIAMENTO DE CONFIGURAÇÃO.

Nilson Salvetti.
UNIP – Universidade Paulista

Antonio Roberto Albuquerque.

UNIP – Universidade Paulista

This paper is a study of the development of highly complex and sophisticate software with the aim of
preserving the integrity and tractability of the developed product.
It is also an objective of this paper to emphasize the importance of standards for all the development process
of software designed for the aerospace sector, while highlighting the utilization of some already consecrated
norms.
A detailed description is made of a software-configuration management plan used in the project for
development of BCVLS (Control Bank of the Satellite Launcher Vehicle), in which an adaptation to the
MIL-STD-2167-A norm is utilized.
This article contains also some definitions as far as configuration management is concerned, and presents the
setup and procedures employed in the configuration management activities.
Configuration Management, Software Quality, Standarts.
Engenharia de Produto/Processo

Introdução
O processo de Gerência de Configuração define as atividades para a aplicação de procedimentos
administrativos e técnicos, por todo o ciclo de vida do software. [1].
O termo SCM (Software Configuration Management) ou Gerência de Configuração de Software (GCS) é
aplicado a um conjunto de atividades cujo objetivo é fornecer uma abordagem sistemática e disciplinada ao
problema de gerenciar a modificação de produtos de software. Também tem como meta estabelecer e manter
a integridade dos produtos de software durante todo o ciclo de vida de um projeto, incluindo todos os itens de
configuração desenvolvidos e/ou modificados ao longo do projeto.
A comunidade mundial de informática vem criando normas para regulamentar e orientar a atividade de
produção de software., incluindo-se nesse contexto o gerenciamento da configuração.
Este artigo apresenta alguns conceitos contidos no processo de gerência de configuração de software. É
também objetivo ressaltar a importância que os padrões representam em todo o processo de desenvolvimento
de software. No caso de software desenvolvido para o setor aeroespacial, tem-se a possibilidade de utilização
de algumas normas já consagradas. Mostra-se um estudo de caso onde se faz uso de um plano de
gerenciamento de configuração de software no projeto de desenvolvimento do Banco de Controle do Veiculo
Lançador de Satélites – BCVLS, utilizando-se uma adequação à norma MIL-STD-2167 A .
4. Plano de Gerência de Configuração de Software para o desenvolvimento
do software aplicativo do Banco de Controle do Veículo Lançador de
Satélites (BCVLS)
Identificação
Este plano define a organização, referencias e procedimentos empregados nas atividades de gerenciamento de
configuração de software, durante o desenvolvimento do Banco de Controle do Veículo Lançador de
Satélites - BCVLS, para o Instituto de Aeronáutica e Espaço – IAE do Centro Técnico Aeroespacial (CTA).
Visão Geral do Sistema
O BCVLS é um sistema cujas principais finalidades são testar, ativar e desativar os subsistemas de bordo do
Veículo Lançador de Satélites - VLS, durante as fases de testes no solo e preparação para lançamento.
Visão Geral do Plano
O objetivo das atividades descritas neste plano é gerenciar a configuração dos documentos e software
desenvolvido ou incorporado no produto, visando atender os requisitos da norma DOD-STD-2167 A.
O trabalho está organizado da seguinte forma:
Objetivo.
Documentos referenciados.
Organização e recursos: descreve a organização, atividades, instalações, equipamentos e pessoal empregados
no gerenciamento de configuração de software.
Identificação da configuração: identifica os documentos que formam a configuração e métodos para
identificar os componentes e unidades de software.
Controle de configuração: descreve os procedimentos para o controle de alterações nos itens de configuração.
Acompanhamento do estado da configuração: descreve os procedimentos de acompanhamento, registro e
manutenção do estado da configuração.
Auditorias de configuração: descreve os procedimentos empregados nas auditorias e revisões de
configuração.
Ferramentas, técnicas e metodologias: define técnicas e ferramentas empregadas no gerenciamento de
configuração.
Coleta, manutenção e retenção de relatórios: define critérios para a manutenção dos registros de
configuração.
Relacionamento com Outros Planos
Este plano complementa e é complementado pelos planos de desenvolvimento - PDS [10] e de garantia de
qualidade de software – PGQ [11].
Organização
As atividades de gerenciamento de configuração de software devem ser executadas pelas equipes de
qualidade e de desenvolvimento.
A organização geral do projeto é descrita no plano de desenvolvimento – PDS.
São responsabilidades da equipe de desenvolvimento, quando atuando no gerenciamento de configuração, as
seguintes atividades:
Identificação e controle de configuração, conforme descrito neste plano. Em particular, o controle de
configuração envolve também a participação da equipe de qualidade e do cliente na aprovação de alterações.
Armazenamento de cópias de referência dos itens sob controle de configuração.
São responsabilidades da equipe de qualidade, quando atuando no gerenciamento de configuração, as
seguintes atividades:
Acompanhamento do estado e auditorias de configuração, conforme descrito neste plano.
Coleta, manutenção e retenção dos registros das atividades de gerenciamento de configuração.
Apoio ao pessoal de desenvolvimento na correta aplicação deste plano.
Verificação da correta e sistemática aplicação deste plano.
Recursos
Os seguintes recursos serão empregados nas atividades de gerenciamento de configuração de software:
Software: uso de todo o software necessário, processadores de texto, planilhas, gerenciadores de base de
dados e outros utilitários de uso geral disponíveis na empresa.
Pessoal: o pessoal empregado nas atividades está descrito no plano de desenvolvimento de software - PDS.
Identificação da Configuração
.1 Estabelecimento da Configuração
O software do BCVLS será formado por um único item de configuração de software, ou computer software
configuration item - CSCI. Sua configuração deve ser estabelecida ao longo do processo de desenvolvimento,
conforme descrito no plano de desenvolvimento - PDS. Ao final do processo, a configuração do produto deve
ser formada por todos os componentes, unidades e documentos produzidos.
É responsabilidade da equipe de desenvolvimento propor, para cada item, a sua colocação sob controle de
configuração, respeitando a seqüência definida no processo de desenvolvimento. A equipe de
desenvolvimento deve julgar que a colocação de um item sob controle de configuração muito cedo, ou seja,
com o item ainda pouco maduro, implicará num grande esforço de controle, já que ele deverá sofrer muitas
alterações antes de se tornar estável. O caso contrário, isto é, o controle tardio de um item, implica na falta de
controle sobre o mesmo e conseqüentes prejuízos ao desenvolvimento dos itens das fases posteriores, que o
usam como referência.
Métodos de Identificação
Documentos
Os documentos produzidos ao longo do projeto devem ser identificados de acordo com as regras a seguir,
que visam satisfazer os requisitos expressos no manual de documentação da empresa – MDOC [12].
Cada documento do projeto dever ser identificado por um título e um código. O título deve identificar o
documento de acordo com o processo de desenvolvimento descrito no plano de desenvolvimento de software
– PDS . O código deve seguir o formato abaixo:
015348.NNNN.TTT/RR
Onde:
015348: é o centro de custo, ou seja, o código numérico que identifica o projeto na empresa.
NNNN: é um campo numérico de quatro dígitos, representando o número seqüencial único de cada
documento no projeto, começando em 0001.
TTT: é um campo alfabético de três letras, representando o tipo do documento.
RR: é um campo numérico, representando o número de revisão seqüencial do documento, começando em
00.
A tabela 1 relaciona os documentos previstos para o projeto e suas identificações, sem o campo de revisão.
Esta tabela é elaborada a partir do plano de desenvolvimento - PDS, devendo ser atualizada periodicamente,
em função das necessidades do projeto, através de alterações neste plano.
Tabela 1: Documentos
Identificação Título do Documento
015348.0001.PDS Plano de Desenvolvimento de Software
015348.0002.PGQ Plano de Garantia de Qualidade de Software
015348.0003.PGC Plano de Gerenciamento de Configuração de Software
015348.0004.MES Modelo Essencial
015348.0005.RNE Especificação de Requisitos Não-Essenciais
015348.0006.IHM Especificação de Interface Homem-Máquina
015348.0007.PTV Procedimentos de Testes de Validação
015348.0008.MOP Manual de Operação do Banco de Controle do VLS
015348.0009.AHS Arquitetura de Hardware e Software Básico
015348.0010.IFE Interfaces Externas
015348.0011.MPO Manual de Programação e Organização
015348.0012.MPR Modelo de Processadores
015348.0013.MTA Modelo de Tarefas e de Dados
015348.0014.IFI Interfaces Internas
015348.0015.MAC Modelo de Arquitetura de Código
015348.0016.PLI Plano de Integração
015348.0017.MMS Manual de Manutenção de Software do BCVLS
015348.0018.DDV Documento de Descrição de Versão
015348.0019.PPT Padrão para os Procedimentos de Testes de Validação
015348.0020.PIH Padrão para a Interface Homem-Máquina
Os documentos, sempre que possível, devem conter as seguintes informações e formatação, baseadas no
manual de documentação – MDOC :
Tamanho da página: A4.
Cabeçalho superior direito da primeira página: código de identificação, com revisão, no formato
“015348.NNNN.TTT/RR”; e, abaixo, a data de emissão da revisão no formato “DD/MM/AAAA”.
Cabeçalho superior direito das páginas seguintes: código de identificação, sem revisão, no formato
“015348.NNNN.TTT”.
Centro da primeira página: o título seguido do texto “para o Banco de Controle do VLS”.
Rodapé esquerdo em todas as páginas: os textos “Direitos Reservados: Instituto de Aeronáutica e Espaço”; e,
abaixo, “Temática: Aeroespacial”.
Rodapé direito em todas as páginas: número da página e total de páginas no formato “página: PP/TT”; e,
abaixo, o número de revisão no formato “revisão: RR”.
Controle da Configuração
Fluxo de Controle de Configuração
O controle de configuração é o mecanismo utilizado para controlar qualquer alteração feita em itens
colocados sob controle de configuração. Cada alteração deve ser processada de acordo com o procedimento
desenvolvido pela equipe de gerencia de configuração e ilustrado na figura 1.
A alteração deve ser iniciada pela submissão de uma proposta de alteração - PAL. As PAL's têm duas classes
- 1 e 2, descritas a seguir:
Classe 1: quaisquer alterações que se enquadrem em algum dos seguintes critérios: (a) afetem a
funcionalidade do sistema (b) afetem o custo do projeto; (c) afetem o prazo do projeto; ou (d) sejam
submetidas por um membro da equipe. A aprovação de PAL’s desta classe deve ter a participação do cliente.
Classe 2: quaisquer alterações que não se enquadrem em nenhum dos critérios do item anterior.
A seguir são descritos os passos do processamento das propostas de alteração.
Submeter PAL: um membro do projeto, ao desejar a alteração de um item sob controle de configuração,
deve submeter uma proposta de alteração. Inicialmente devem ser preenchidos os campos Título, Submetida
por, Classe, Itens afetados, Motivo e Descrição. A PAL, em duas vias, deve então ser encaminhada à equipe
de garantia de qualidade.
Registrar: a equipe de qualidade deve verificar o correto preenchimento dos campos listados no item anterior,
preencher o campo PAL com o próximo número disponível, arquivar uma das vias, e encaminhar a outra à
equipe de desenvolvimento.
Analisar impacto: a equipe de desenvolvimento deve analisar os impactos da alteração, completando os
campos Itens afetados, Custo e Prazo.
Aprovar: com base nos dados levantados deve ser tomada a decisão sobre a aprovação ou rejeição da PAL.
Esta é a ocasião em que devem ser negociados os custos e prazos, realizando os ajustes necessários nos
campos Itens afetados, Descrição, Custo e Prazo.
Tomada a decisão, deve ser preenchido o campo Aprovada/Rejeitada e encaminhada a PAL, conforme o
resultado, à equipe de desenvolvimento para implementação, ou à equipe de garantia de qualidade para
arquivamento.
Implementar: a equipe de desenvolvimento deve realizar todas as alterações descritas.
Verificar: a equipe de desenvolvimento deve verificar a eficácia das alterações realizadas, registrando
também eventuais problemas encontrados ou introduzidos. Ao concluir que a implementação foi completada,
deve preencher o campo Implementada/Cancelada e encaminhar a PAL à equipe de garantia de qualidade.
Arquivar: a equipe de garantia de qualidade deve registrar a implementação da PAL e substituir a via
arquivada pela recebida da equipe de desenvolvimento. Somente a via completamente processada deve
permanecer arquivada, a outra deve ser destruída.
As propostas de alteração podem ainda ser canceladas, caso em que deve ser preenchido o campo
Implementada/Cancelada. Não é permitido o cancelamento de propostas já implementadas.

Figura 1: Controle da Configuração

Proposta de Alteração
A seguir é apresentado o modelo da proposta de alteração. Seus campos devem ser preenchidos da seguinte
forma.
PAL: deve ser preenchido o número da proposta de alteração. As PAL's devem possuir números únicos,
seqüenciais, a partir de 001.
Título: um título indicativo da alteração, cujo objetivo é permitir sua rápida identificação.
Submetida por: quem está submetendo deve preencher o nome e outros dados que permitam sua
identificação, além da data de submissão.
Classe: a classe da alteração, conforme os critérios definidos anteriormente neste plano.
Itens afetados: identificação de todos os itens que deverão ser alterados. É possível identificar itens,
componentes, unidades ou documentos. Se necessário, continuar a lista em páginas anexas.
Motivo: uma das opções: correção de defeitos, quando a alteração foi originada de um ou mais relatórios de
defeito; ou melhoria, quando a alteração foi gerada por qualquer outro motivo. Quando for correção de
defeito, devem ser anotados também os números de todos os relatórios de defeito que originaram a alteração.
Os relatórios de defeito são descritos no plano de garantia de qualidade de software - PGQ.
Descrição: uma descrição completa da alteração, além de dados que permitam sua implementação. É possível
continuar a descrição em páginas anexas.
Custo: uma estimativa de custos diretos e indiretos da implementação da alteração.
Prazo: uma estimativa do impacto da implementação da alteração no cronograma do projeto.
Aprovada/Rejeitada: o responsável pela aprovação deve marcar a aprovação ou rejeição, seu nome e a data
correspondente.
Implementada/Cancelada: deve ser assinalada a implementação ou o cancelamento, o nome de quem
implementou ou cancelou e a data correspondente.
Acompanhamento do Estado da Configuração
A equipe de qualidade deve manter sempre atualizados e disponíveis, para consulta pela administração do
projeto, equipe de desenvolvimento, os seguintes dados:
Todas as propostas de alteração submetidas.
O estado de processamento de todas as propostas de alteração submetidas.
Todas as revisões emitidas dos itens de configuração sob controle.
O histórico de alterações e revisões de todos os itens de configuração sob controle.
As revisões atuais de todos os itens de configuração sob controle.
A equipe de qualidade deve ainda, mensalmente, produzir e enviar à equipe de desenvolvimento , um
relatório com as seguintes informações:
Mapa de configuração: listagem com a identificação, revisão, título e data das versões mais recentes de todos
os itens sob controle.
Relação de propostas de alteração pendentes: listagem contendo, para cada proposta de alteração ainda não
concluída, sua identificação, itens afetados, seus estados e há quanto tempo foi submetida.
Evolução das propostas de alteração: gráficos contendo o número de propostas de alteração ao longo do
tempo, com curvas indicando o total, o número de concluídas, o número de pendentes, e o total para cada
item relevante.
Revisões de Configuração
O pessoal de garantia de qualidade deve, quando julgar necessário, realizar auditorias em itens de
configuração para verificar se:
O sistema, hardware ou software correspondem à documentação associada.
As versões mais recentes dos itens de configuração estão disponíveis.
Todas as propostas de alteração aprovadas estão implementadas.
Nenhuma alteração rejeitada ou ainda não aprovada está implementada.
Cada auditoria deve ser documentada num relatório onde devem ser listados os itens auditados, os desvios
em relação aos critérios anteriores e as respectivas justificativas, quando houver.
As auditorias devem ser documentadas na forma de relatórios de avaliação, e os desvios não justificados na
forma de relatórios de defeito. Os formatos e processamento destes relatórios estão descritos no plano de
garantia de qualidade - PGQ.
Ferramentas, Técnicas e Metodologias
Acompanhamento do Estado da Configuração
Nas atividades de gerenciamento de configuração deve ser empregada a ferramenta SISQLD , cuja operação é
descrita no seu manual do usuário – SQLD [11].
Esta ferramenta deve ser utilizada no registro das propostas de alteração, dos itens de configuração e das suas
revisões; no acompanhamento dos estados das alterações e itens; em consultas interativas; e na geração de
relatórios de situação, mapas e históricos de configuração.
Na automação da geração de relatórios e consultas, podem também ser utilizados o ambiente Informix-SQL e
a linguagem Informix-4GL, sobre a base de dados mantida pela ferramenta SISQLD.
Armazenamento dos Itens de Configuração
Todos os itens sob controle de configuração, e suas revisões, devem ser armazenados e mantidos de acordo
com as seguintes regras:
Em cada ambiente operacional , deve ser designada uma área de referência para os itens sob controle de
configuração.
Cada área deve ser organizada e protegida de modo a permitir, à equipe de desenvolvimento, apenas a leitura
das revisões mais recentes de cada item armazenado.
A equipe de qualidade deve, em caráter exclusivo, realizar qualquer inclusão ou alteração necessária nas
áreas de referência.
A equipe de desenvolvimento deve manter a integridade dos ambientes operacionais e das áreas de
referência.
A equipe de qualidade deve, a cada inclusão ou alteração, fazer uma cópia de segurança da área de
referência.
A equipe de qualidade deve fazer as cópias de segurança em meio eletrônico removível, guardando-as em
local protegido.
Coleta, Manutenção e Retenção de Relatórios
Os registros de gerenciamento de configuração são as propostas de alteração e as informações sobre a
evolução dos itens armazenadas na ferramenta SISQLD.
Estes registros devem ser coletados e mantidos pela equipe de qualidade, do início do desenvolvimento à
entrega final do sistema, devendo ainda ser armazenados por pelo menos dois anos após esta data.
5 Conclusões
O desenvolvimento de software para aplicações aeroespaciais, devido às suas características de criticalidade,
exige a adoção de padrões como elementos necessários do processo de garantia da qualidade.
Existem outros padrões internacionais também aplicáveis, provenientes de áreas distintas, como a acadêmica
ou a industrial, que podem ser usados nessa classe de software. Cita-se o caso dos padrões da série ISO-9000
e do RTCA-DO/178B usado no desenvolvimento e na avaliação de software para sistemas e equipamentos
embarcados em aeronaves civis.
O uso do padrão DOD-STD-2167 A no projeto do desenvolvimento do software do Banco de Controle do
VLS, e particularmente o Plano de Gerência de Configuração mostra-se de uma relevância impar, pois dessa
forma identifica qualquer tipo de mudança e permite a rastreabilidade durante a existência do software.
Para outros projetos, talvez o uso do padrão MIL-STD-498 seja uma boa experiência, visto que possui
alguns avanços em relação ao DOD-STD-2167 A, tais como flexibilidade quanto ao cronograma de revisões
e entrega de produtos, flexibilidade para documentação (podem ser adaptados entre desenvolvedor e cliente),
e até mesmo indicadores de gerenciamento de software (recomenda “software metrics” para auxilio na
gestão do processo de desenvolvimento).
6. Referências Bibliográficas
[1] – MACHADO, C.F et al. Processos de Ciclo de Vida de Software: Norma ISO/IEC 12207. Developers,
novembro 1998 p.22.
[2] - LEON, ALEXIS. A Guide to Software Configuration Management. Artech House
Publishers, 2000.
[3] BABICH, W.A . Software Configuration Management. Addison-Wesley, 1996.
[4] PRESSMAN, R.S. Engenharia de Software. Makron Books, SP, 1995
[5] SPINOLA, M.M, JOSÉ NETO, J. e PESSÔA, M.S.P. Gerência de Configuração de
Sistemas embutidos: estruturação e implantação de processo. WQS’2000 – Workshop
de Qualidade de Software
[6] SOUTO, F. C. R.. Uma visão de normalização. Qualitymark, RJ, 1991.
[7] Defense: system software development.. (DOD-STD-2167 A) Washington, D. C. :
U.S. Department of Defense, 1988.
[8] Software: development and documentation. (MIL-STD-498) Washington, D. C. :
U.S. Department of Defense, 1994.
[9] MACIEL, TERESA M. de MDEIROS. Garantindo a Qualidade na Especificação do
Plano de Projeto Iterativo de Software. WQS’2000 – Workshop de Qualidade de Software.
[10] 015348.0001.PDS/00 - “Plano de Desenvolvimento de Software” - 1999.
[11] 015348.0002.PGQ/00 - “Plano de Garantia de Qualidade de Software”, 1999.
[12] 013012.0003.MAN/01 - “Manual de Documentação”, 1999.
[13] “SISQLD - Manual do Usuário”, 1999.