apostila curso gcs

Gerncia de Configurao de SoftwareEvoluo de Software sob Controle

Tecnologia para Gerncia de Configurao de SoftwareInstituto Nacional de Tecnologia da InformaoLaboratrio de Avaliao e Melhoria de Processos de Software

Instituto Nacional de Tecnologia da InformaoLaboratrio de Avaliao e Melhoria de Processos de Software

2 GERNCIA DE CONFIGURAO DE SOFTWAREEvoluo de Software sob Controle

Gerncia de Configurao de Software

Autoria: Angelina A.A. C. P. de Oliveira [email protected] Formoso Primo [email protected] Luiz da Cruz [email protected] Roberto De Martino [email protected]

Os autores pertencem equipe tcnica do Instituto Nacional de Tecnologia da Informao ITI, rgo do Ministrio da Cincia e Tecnologia.

ltima atualizao: Junho/2001

Nenhuma parte desta apostila pode ser utilizada ou reproduzida, em qualquer meio ou forma,seja mecnico ou eletrnico, fotocpia, gravao, ou outros, sem autorizao, prvia, expressae especfica dos autores.

ITI - Instituto Nacional de Tecnologia da InformaoLaboratrio de Avaliao e Melhoria de Processos de Software

Via D. Pedro I (SP-65), Km 143.6 Caixa Postal 6162Fone: (019) 3746- 6000 Fax (019) 3746-6092


GERNCIA DE CONFIGURAO DE SOFTWAREEvoluo de Software sob Controle

3

NDICE

1 INTRODUO ..................................................................................................................................................71.1 PBLICO ALVO E OBJETIVOS .........................................................................................................................81.2 VISO GERAL DO TEXTO ...............................................................................................................................8

2 HISTRICO.....................................................................................................................................................11

3 MOTIVAO ..................................................................................................................................................153.1 O COMPUTADOR COMO UMA MQUINA DE USO GERAL ...............................................................................163.2 O SOFTWARE..............................................................................................................................................173.3 GERNCIA DE CONFIGURAO DE SOFTWARE............................................................................................21

3.3.1 GCS: Custos & Benefcios .............................................................................................................223.3.2 Impedimentos adoo de GCS.....................................................................................................223.3.3 GCS - Estado atual..........................................................................................................................23

4 CARACTERIZAO DE GERNCIA DE CONFIGURAO DE SOFTWARE..................................254.1 CONCEITOS FUNDAMENTAIS.......................................................................................................................264.2 DESENVOLVIMENTO DE SOFTWARE COM CONFIGURAES-BASE ..............................................................274.3 DISTRIBUIES...........................................................................................................................................344.4 DEFINIO FORMAL DE GCS ......................................................................................................................354.5 ATIVIDADES DE GCS..................................................................................................................................35

4.5.1 Identificao de configurao.........................................................................................................364.5.2 Controle de configurao................................................................................................................364.5.3 Administrao de estado.................................................................................................................384.5.4 Auditagem de configurao ............................................................................................................39

4.6 ELEMENTOS ORGANIZACIONAIS DE GCS ....................................................................................................39

5 CONTROLE DE VERSES ...........................................................................................................................435.1 DESENVOLVIMENTO EM PARALELO ............................................................................................................455.2 OPERAES DE ACESSO ..............................................................................................................................465.3 AGREGAES .............................................................................................................................................485.4 DESENVOLVIMENTO DE SOFTWARE COM CONTROLE DE VERSES .............................................................495.5 CONCLUSES SOBRE CONTROLE DE VERSES ............................................................................................52

6 FERRAMENTAS DE GCS .............................................................................................................................536.1 CRITRIOS PARA AVALIAR UMA FERRAMENTA DE GERNCIA DE CONFIGURAO......................................53

6.1.1 Suporte a equipe de desenvolvimento.............................................................................................536.1.2 Suporte a desenvolvimento remoto.................................................................................................536.1.3 Suporte a configuraes..................................................................................................................546.1.4 Suporte a gerncia de mudanas.....................................................................................................546.1.5 Suporte de build e de distribuio de produto .............................................................................546.1.6 Suporte de processo ........................................................................................................................546.1.7 Usabilidade .....................................................................................................................................546.1.8 Facilidade de set-up.....................................................................................................................546.1.9 Personalizao ................................................................................................................................54

6.2 CLASSIFICAO DAS FERRAMENTAS DE GCS .............................................................................................546.2.1 Ferramentas de controle de verses ................................................................................................556.2.2 Ferramentas orientadas ao desenvolvedor ......................................................................................556.2.3 Ferramentas orientadas a processo .................................................................................................55



6.3 ESTUDOS DE CASO ......................................................................................................................................556.3.1 Anlise da ferramenta Source Integrity ..........................................................................................56

6.3.1.1 Suporte a equipe de desenvolvimento..............................................................................................566.3.1.2 Desenvolvimento remoto.................................................................................................................566.3.1.3 Gerenciamento de configurao ......................................................................................................576.3.1.4 Gerenciamento de modificao........................................................................................................576.3.1.5 Suporte a gerao de distribuio de um produto ............................................................................576.3.1.6 Gerenciamento de processo .............................................................................................................576.3.1.7 Usabilidade ......................................................................................................................................586.3.1.8 Facilidade de configurao inicial ...................................................................................................586.3.1.9 Personalizao .................................................................................................................................58

6.3.2 Anlise da ferramenta Visual Source Safe ......................................................................................586.3.2.1 Suporte a equipe de desenvolvimento..............................................................................................586.3.2.2 Desenvolvimento remoto.................................................................................................................596.3.2.3 Gerenciamento de configurao ......................................................................................................596.3.2.4 Gerenciamento de modificao........................................................................................................596.3.2.5 Suporte a gerao de distribuio de um produto ............................................................................596.3.2.6 Gerenciamento de processo .............................................................................................................596.3.2.7 Usabilidade ......................................................................................................................................596.3.2.8 Facilidade de configurao inicial ...................................................................................................606.3.2.9 Personalizao .................................................................................................................................60

7 NORMAS E PADRES...................................................................................................................................617.1 IEEE...........................................................................................................................................................617.2 ISO/IEC .....................................................................................................................................................617.3 SEI-CMU...................................................................................................................................................63

7.3.1 O Processo de GCS segundo o modelo CMM................................................................................677.4 INICIATIVAS NO BRASIL..............................................................................................................................69

8 IMPLEMENTAO DE GCS........................................................................................................................71

9 EXEMPLO DE APLICAO: GCS PARA PEQUENAS EMPRESAS ....................................................739.1 INTRODUO ..............................................................................................................................................739.2 CARACTERIZAO DO PROBLEMA..............................................................................................................739.3 ESTRATGIA DE ABORDAGEM ....................................................................................................................739.4 O PLANO DE GERNCIA DE CONFIGURAO DE SOFTWARE .......................................................................749.5 RESULTADOS OBTIDOS ...............................................................................................................................78

10 EXEMPLO DE APLICAO: O MODELO NASA DE GCS ....................................................................7910.1 DEFINIO..................................................................................................................................................7910.2 FUNES DE GCS.......................................................................................................................................7910.3 CONCEITOS BSICOS...................................................................................................................................7910.4 ESTRUTURA ORGANIZACIONAL DE GCS .....................................................................................................8010.5 CICLO DE VIDA...........................................................................................................................................81

10.5.1 Fase Conceito e Iniciao ...............................................................................................................8110.5.2 Fase Requisitos ...............................................................................................................................8210.5.3 Fase Arquitetura .............................................................................................................................8210.5.4 Fase Projeto Detalhado ...................................................................................................................8310.5.5 Fase Implementao .......................................................................................................................8310.5.6 Fase Integrao e Teste...................................................................................................................8410.5.7 Fase Aceitao e Entrega................................................................................................................8410.5.8 Fase Operao e Manuteno .........................................................................................................85

11 CONCLUSO ..................................................................................................................................................87

APNDICE A - PLANO DE GERNCIA DE CONFIGURAO DO PROJETO SW_CRIT ....................89



5

1 INTRODUO ................................................................................................................................................901.1 OBJETIVOS..................................................................................................................................................901.2 ESCOPO.......................................................................................................................................................901.3 DEFINIES E MNEMNICOS .......................................................................................................................91

1.3.1 Definies.......................................................................................................................................911.3.2 Mnemnicos ...................................................................................................................................91

1.4 REFERNCIAS ............................................................................................................................... ..............92

2 GERNCIA ...................................................................................................................... ................................932.1 ORGANIZAO ...........................................................................................................................................932.2 RESPONSABILIDADES DE GCS ....................................................................................................................93

2.2.1 Identificao da Configurao ........................................................................................................942.2.1.1 Configuraes-Base .........................................................................................................................942.2.1.2 Liberaes (Releases) ......................................................................................................................942.2.1.3 Documentao .................................................................................................................................95

2.2.2 Controle da Configurao...............................................................................................................952.2.2.1 Requisio de Modificao de Software/Sistema (RMS) ................................................................952.2.2.2 Autorizao para Modificao de Software (AMS).........................................................................95

2.2.3 Administrao de Estado ................................................................................................................952.2.4 Auditagens ......................................................................................................................................95

2.2.4.1 Auditagem de GQS..........................................................................................................................952.2.5 Comit de Controle de Configurao (CCC)..................................................................................96

2.3 POLTICAS, DIRETIVAS E PROCEDIMENTOS APLICVEIS.............................................................................963 ATIVIDADES DE GCS ...................................................................................................................................97

3.1 IDENTIFICAO DE CONFIGURAO............................................................................................................973.1.1 Configuraes-Base........................................................................................................................97

3.1.1.1 Configurao-Base Funcional..........................................................................................................973.1.1.2 Configurao-Base de Alocao......................................................................................................973.1.1.3 Configurao-Base de Projeto Bsico..............................................................................................973.1.1.4 Configurao-Base de Projeto Detalhado ........................................................................................983.1.1.5 Configurao-Base de Cdigo ............................................................................................. ............983.1.1.6 Configurao-Base de Produto ............................................................................................ ............98

3.1.2 Documentao ................................................................................................................................983.1.3 Partes do software...........................................................................................................................99

3.2 CONTROLE DE CONFIGURAO...................................................................................................................993.2.1 Funo do Comit de Controle da Configurao..........................................................................1003.2.2 Requisio de Modificao de Software/Sistema (RMS).............................................................1003.2.3 Autorizao de Modificao de Software (AMS).........................................................................1003.2.4 Ferramentas automatizadas de GCS para controle de modificaes............................................101

3.3 ADMINISTRAO DE ESTADO ...................................................................................................................1013.4 AUDITAGENS E REVISES DE CONFIGURAO..........................................................................................102

3.4.1 Auditagem Funcional de Configurao (FCA).............................................................................1023.4.2 Auditagem Fsica de Configurao (PCA) ...................................................................................1023.4.3 Revises........................................................................................................................................102

3.5 CONTROLE DE INTERFACES.......................................................................................................................1023.6 CONTROLE DE FORNECEDORES E SUBCONTRATADOS...............................................................................103

3.6.1 Software adquirido de fornecedor.................................................................................................1033.6.2 Software subcontratado ................................................................................................................1033.6.3 Auditagem de software de fornecedor e de subcontratado ...........................................................103

4 IMPLANTAO ...........................................................................................................................................1044.1 COMIT DE CONTROLE DA CONFIGURAO .............................................................................................1044.2 ESTABELECIMENTO DE CONFIGURAES-BASE........................................................................................1044.3 ESCALONAMENTO E PROCEDIMENTOS PARA REVISES E AUDITAGENS DE GCS........................................104



4.4 RETENO................................................................................................................................................1045 RECURSOS ....................................................................................................................................................105

5.1 RECURSOS HUMANOS...............................................................................................................................1055.2 FERRAMENTAS DE GERNCIA DE CONFIGURAO....................................................................................105

6 MANUTENO DO PLANO.......................................................................................................................107

Anexo 1: Requisio de Modificao de Sistema/Software - RMS ..................................................................108

Anexo 2: Autorizao de Modificao de Software - AMS ..............................................................................109

Anexo 3: Procedimento para controle de modificaes no software/documentao......................................110

APNDICE B - REFERNCIAS BIBLIOGRFICAS ...................................................................................111



7

1 INTRODUOEste texto trata de mudanas. Mudanas acontecem praticamente em tudo: as coisas, aspessoas, o ambiente, tudo muda com maior ou menor freqncia. Particularmente, aqui,estamos interessados em focalizar as mudanas que ocorrem nos produtos de software durantetodo o seu ciclo de vida.

Nos produtos de software mudanas so intrnsecas, fundamentais e inevitveis. Este um fatoque possui os seus aspectos positivos e negativos. graas s modificaes que o produto seconcretiza e pode ser corrigido ou melhorado e tambm devido s modificaes que surgemmuitos problemas do software: as mudanas, quando aplicadas sem critrio, podem levar perda de controle do produto e, como conseqncia, comprometer sua integridade e qualidade.

Neste texto procurou-se:

realar a necessidade de controlar sistematicamente as mudanas nos produtos desoftware;

mostrar como acomodar e facilitar a realizao de mudanas nos produtos; indicar como evitar que as mudanas no desviem os produtos de seus projetos originais; apontar como fazer com que as mudanas no comprometam a qualidade do produto

final.Em suma, disseminar prticas para o desenvolvimento de software de forma sistemtica, segurae controlada objetivando sempre produtos da melhor qualidade.Gerncia de Configurao de Software (GCS) uma disciplina de natureza tcnica egerencial que objetiva facilitar o desenvolvimento de software e, ao mesmo tempo, garantir asua integridade. Tais objetivos so perseguidos basicamente atravs de controle sistemticosobre as modificaes pelas quais passa o produto desde a sua concepo at a sua desativao.

Para que se aplique GCS fundamental: identificar aquilo que se pretende controlar; definir o controle a ser estabelecido; verificar que as modificaes sejam implementadas de acordo com o especificado; manter um registro que permita aos interessados a obteno de informaes do estado em

que se encontrem os itens sob controle.Tais tpicos so examinados com detalhes no decorrer deste texto.



1.1 Pblico alvo e objetivosEste texto destinado s pessoas que lidam com software em geral: profissionais deinformtica, desenvolvedores, gerentes, estudantes, interessados na aquisio de ferramentas deGCS, pretendentes certificados de qualidade, etc. Os objetivos principais do texto so:

apresentar os conceitos bsicos de GCS e difundir suas prticas; fornecer subsdios para a elaborao de planos de GCS; apresentar as principais caractersticas de algumas ferramentas de GCS encontradas no

mercado.Dessa forma acredita-se estar contribuindo para que os interessados possam melhorar os seusprocessos de produo de software ou o de suas empresas.Ressalve-se que o desenvolvimento de software , em geral, uma tarefa complexa e noexistem frmulas mgicas para resolver os vrios problemas a ela relacionados. A soluoapontada pela GCS implica em melhorar o processo de desenvolvimento, mesmo que paratanto tenha-se que estabelecer e respeitar regras e que haja um aumento no formalismo. GCSnem sempre uma disciplina simptica. Seu objetivo , antes de tudo, preservar a integridade emelhorar a qualidade dos produtos de software.

1.2 Viso geral do textoEste texto encontra-se dividido em captulos numerados de 1 a 11 e dois apndices.

No captulo 1 apresentada uma introduo ao texto e sua organizao.

No captulo 2 apresentado um breve histrico de GCS, sua origem dentro das engenharias,sua aplicao ao hardware e a conseqente migrao e adaptao para o software.

No captulo 3 so apresentados os motivos ou argumentos que justificam um estudo maisaprofundado do tema GCS, sua atualidade e relevncia.

No captulo 4 so abordados os aspectos conceituais de GCS e detalhados os seus processosprincipais.

No captulo 5 so abordados alguns aspectos importantes da implementao prtica de GCS: ocontrole de verses e a incorporao de alguns conceitos de GCS a projetos j desenvolvidosou em desenvolvimento.

No captulo 6 abordado o assunto Ferramentas de GCS: uma classificao segundo as suascaractersticas funcionais, alguns critrios para avaliao e estudos de caso de ferramentasatualmente encontradas no mercado, suas caractersticas e limitaes.

No captulo 7 feito um apanhado geral sobre o estado atual das Normas e Padres de GCS.

No captulo 8 so feitas algumas consideraes sobre planejamento de GCS.



9

Nos captulos 9 e 10 so apresentados dois exemplos de aplicao de GCS, um mostrando GCSnuma empresa de pequeno porte e outro mostrando o modelo de uma grande organizao, aNASA.

No captulo 11 feita a concluso do texto, uma viso critica sobre o texto e o tema abordado.

Permeando os captulos do texto utilizado como exemplo a implementao de GCS numprojeto de software hipottico SW_CRIT. Procurou-se focalizar as situaes mais comuns eque possam ser encontradas em projetos reais de software. O apndice A apresenta o plano degerncia de configurao para esse projeto hipottico que baseado no documento ANSI/IEEEStd 1042-1987.



11

2 HISTRICOA necessidade de uma disciplina para identificar e controlar o projeto de equipamentoscomplexos e a comunicao das informaes relacionadas foi mais aparente na indstria dedefesa dos EUA onde a alta qualidade do produto era um pressuposto. Assim, o histrico dadisciplina gerncia de configurao muito deve aos esforos dos organismos governamentaisnorte-americanos, especialmente os de defesa, e em particular aos esforos de padronizao narea de engenharia.

At o final da 2a Guerra Mundial, os projetos de engenharia no eram muito complexos. Numprojeto, as atividades de desenvolvimento, de acompanhamento e de suporte eram todasrealizadas sem grandes problemas pelo mesmo grupo de pessoas, em geral um engenheiro ealguns tcnicos que o auxiliavam.

Aps a Grande Guerra, a complexidade dos equipamentos aumentou de maneira espantosa,como tambm aumentou a velocidade com que estes equipamentos eram substitudos poroutros ainda mais complexos. Como resultado, tanto a constituio das equipes dedesenvolvimento como a forma como trabalhavam no conseguiam suportar as novasexigncias dos desenvolvimentos. Equipes que costumavam ser compostas por um engenheiroexperiente e cinco tcnicos, passaram a ser integradas por cinco engenheiros e um bom tcnico,todos os seis realizando o mesmo tipo de trabalho. Os produtos, por sua complexidade erapidez de evoluo, exigiam mais ateno quanto ao controle de sua evoluo.

Atividades de gerncia de configurao (GC) principiaram nesta poca no seio da indstria dedefesa norte-americana agrupadas em torno de tcnicas gerenciais para resolver problemas debaixa qualidade. O termo Configuration Management (Gerncia de Configurao) foiformalmente estabelecido neste contexto, assim como vrios outros conceitos tecnolgicos.

O primeiro trabalho de sistematizao da rea aparece com a publicao, pela fora areaamericana, da norma AFSCM 375-1 Configuration Management. Este trabalho significou ummarco de mudana na forma como o desenvolvimento de projetos de engenharia eramconduzidos, pelo menos no contexto das foras armadas americanas, pois estabeleceu de formaclara a separao entre atividades de desenvolvimento de um produto e as atividades decontrole deste produto.

Esta norma disparou uma cascata de outros esforos de normalizao nas organizaesmilitares norte-americanas. Estes esforos deram origem a diversas normas na dcada de 1960.Em particular cinco documentos foram publicados em 1968 que definiam polticas e diretrizesde GC e formalizavam as atividades bsicas de identificao, controle e administrao deestado. Estes documentos foram: Directive 5010.19 Configuration Management, Instruction5010.21 Configuration Mangement e as normas MIL STD 480 Engineering Changes,Deviations, and Waivers, para as atividades de controle de configurao, MIL STD 482Standard for Status Accounting, para as atividades de administrao de estado, e MIL STD 490Specification Practices para as atividades de identificao de configurao.



Em todos os esforos, no entanto, o desenvolvimento de software no possua tratamentoespecfico. Software era considerado um apndice do hardware.

O primeiro documento a reconhecer gerncia de configurao tanto de hardware como desoftware foi a norma MIL STD 483, Configuration Management Practices for Systems,Equipment, Munitions, and Computer Programs, publicada por volta de 1971. Tambm nestedocumento apareceu pela primeira vez um esboo de plano de GC.

Entretanto, foi com o incio do desenvolvimento de normas especficas para o desenvolvimentode software que a constituio da disciplina GCS realmente tomou impulso. No final da dcadade 70 surgiu a norma MIL STD 1679 Weapon System Software Development (Dezembro de1978) e nos anos de 1979 e 1981 foram realizadas 2 conferncias de software emMonterey/Califrnia (Monterey I e Monterey II). Uma das principais resolues dessasconferncias foi a determinao de se criar um padro universal para desenvolvimento desoftware.

Este projeto ambicioso consolidou-se na norma DOD STD 2167 Defense System SoftwareDevelopment publicada em 1985, aps um perodo de desenvolvimento bastante turbulento.Sua publicao foi realizada j com proviso de incio de trabalho de reviso para resolverquestes abertas. Esta norma, por outro lado, significou um grande avano nos conceitos deGCS principalmente com a introduo do conceito de configurao-base (baseline), queorganizava GCS em termos das fases do ciclo de vida.

Por volta de 1988, o governo americano anunciou sua inteno de sair da arena de elaboraoativa de normas e o interesse em fomentar os trabalhos de normalizao das associaes daindstria, tais como IEEE, ANSI e EIA.

A partir desta poca, a evoluo de GCS passou para entidades ligadas a indstria euniversidade, ainda que com uma grande participao de organismos governamentais norte-americanos, especialmente as organizaes militares e de defesa.

A IEEE em seus esforos de elaborao de normas para a rea de engenharia de software,publicou duas normas enfocando especificamente a questo de elaborao 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 Std828, so bastante adotadas no cenrio internacional como referncia para a elaborao deplanos de GCS.

Adicionalmente, o lanamento nos anos 90 do Capability Maturity Model (CMM), peloSoftware Engineering Institute da Carnegie Mellon University, realou ainda mais aimportncia da disciplina GCS ao identific-la como um dos processos-chave de um processode software de qualidade.



13

No cenrio internacional, foi formado na dcada de 90 o comit conjunto JTC1 (JointTechnical Committee 1) unificando os esforos de elaborao de normas na rea de tecnologiada informao das duas maiores entidades internacionais de padronizao a ISO (InternationalOrganization for Standardization) e a IEC (International Electrotechnical Commission). Sob agide do JTC1 foi produzida a norma ISO/IEC 12207:1995 Information technology -- Softwarelife cycle processes, que define uma estrutura de processos para o processo de software. Nestemodelo, estabelecido o processo de GCS como um dos processos de apoio aodesenvolvimento de software. A partir desta norma foi produzido o relatrio tcnico ISO/IECTR 15846:1998 Information technology -- Software life cycle processes -- ConfigurationManagement que procura desenvolver a caracterizao resumida de GCS definida na ISO/IEC12207.

Atualmente percebe-se um interesse crescente por GCS. Este interesse pode ser atribudo emgrande parte busca por certificaes de qualidade como ISO 9000 ou nvel de maturidade deacordo com o CMM, mas tambm devido s necessidades colocadas pela competio domercado que, cada vez mais, exige qualidade.



15

3 MOTIVAOO desenvolvimento de software uma das atividades mais criativas e tambm das maisdesafiadoras para o profissional de informtica. Aplicaes de software so encontradas emtodos os setores de atividade humana, desde as mais elementares at as mais complexas. Demaneira geral, desenvolver software no uma tarefa trivial mas os resultados compensam osesforos. A demanda continua crescente e um bom profissional de software tem seu lugargarantido no mercado de trabalho atual.

O aumento da utilizao e da demanda, no entanto, implica na necessidade de produtos maisconfiveis, mais fceis de usar e de melhor qualidade. Desenvolver software deixou de ser umatarefa de artesos, de principiantes ou de amadores. Para atender o mercado necessria umaproduo em larga escala, eficiente e confivel. Hoje em dia, por trs do desenvolvimento desoftware, h todo um processo.

inquestionvel a presena e a importncia dos computadores no nosso dia a dia. Raros so osindivduos cuja vida passe ao largo dessa mquina ou que no sejam influenciados pela mesma.O envolvimento na maioria das vezes compulsrio. No se pede, impe-se o uso. Assim,querendo ou no, fomos todos transformados em usurios de computador. Isso um fato!

Para uma grande parcela de usurios no interessa nada saber detalhes tcnicos sobre ocomputador, o que , como funciona. So assuntos sem relevncia. O importante para esse tipode usurio so as funcionalidades oferecidas pelo computador e a qualidade e eficincia dosservios prestados.

Existe, porm, uma parcela de usurios de computador para os quais so imprescindveisconhecimentos tcnicos sobre o assunto num grau de maior ou menor profundidade.

?GCS

Controle deVerses

ISO 9000CMM



3.1 O computador como uma mquina de uso geralO computador uma mquina de uso geral especializada em processamento de dados. , semdvida, um dos principais produtos tecnolgicos do sculo XX. Surgida h cerca de 50 anos,evoluiu de forma extraordinria e aos poucos foi se entranhando no dia a dia das pessoas.

Um sistema de computao constitudo por dois componentes principais: o hardware e osoftware. Um terceiro componente, o firmware, pode aparecer tambm e um misto dos outrosdois. A figura 3.1 ilustra um sistema de computao tpico.

Figura 3.1 - Sistemas de Computao

Os computadores encontram-se, hoje em dia, nos mais diversos tipos e tamanhos comaplicaes em praticamente todas as reas de atividade humana.

O hardware do computador envolve todos os componentes fsicos do sistema: CPU, teclado,mouse, vdeo, fontes de alimentao, etc. Esse hardware possui algumas habilidades especiaistais como fazer operaes lgicas e aritmticas de uma forma muito eficiente: sem errar e numtempo muito pequeno. Tais habilidades, quando manipuladas convenientemente, podem sermuito teis na soluo de alguns problemas. O hardware representa a capacidade de trabalhobruto da mquina.

Tambm fazem parte do hardware os dispositivos perifricos utilizados na comunicao comos usurios: pessoas ou outras mquinas. Nesta categoria encontram-se as impressoras,modems, discos, etc. A gerncia de configurao nos seus primrdios aplicava-seprincipalmente ao hardware.

A parte inteligente do sistema, aquela que explora os recursos do hardware com uma finalidadeprtica e especfica constitui o chamado software.

Os primeiros computadores eram operados atravs de chaves e alavancas que dificultavam elimitavam muito o seu uso. No final da dcada de 40 John Von Neumann introduziu oconceito de programa armazenado e o computador passou a ser uma mquina controladaatravs de programas o que indiscutivelmente ampliou as suas possibilidades. O software constitudo por programas de computador e por estruturas de dados.

Sistemas de ComputaoSistemas de Computao

Hardware

Firmware

Software



17

Os programas so seqncias de instrues que a mquina executa com alguma finalidadedeterminada pelo autor do programa. As estruturas de dados representam as informaes quedevem ser processadas mapeando elementos do contexto da aplicao para o contexto damquina.

O terceiro componente de um sistema de computao, o firmware, uma combinao dedispositivos de hardware e de software residente em ROM e que no pode ser modificado porprograma.

3.2 O SoftwareO software , sem dvida, o componente mais importante do computador. principalmentedevido ao software que o computador ganha o status de mquina de uso geral: um mesmohardware desempenhando funes diversas.

Durante o seu ciclo de vida o software apresenta-se sob diversos formatos ou representaes.Iniciando um processo de desenvolvimento h sempre uma necessidade ou problemaapresentado por uma pessoa ou organizao e o analista ou programador prope uma soluoque envolve o desenvolvimento de um determinado software. Nesse ponto o software umconceito e a partir da evolui para diversas outras formas at tornar-se um cdigo que,executado pela mquina, satisfaz as necessidades do usurio.

A figura 3.2 ilustra o processo de desenvolvimento do software:

Figura 3.2 - Evoluo dos Sistemas de Software

Convm notar que o software, partindo de uma idia at chegar a um cdigo que a mquinaentenda e execute, necessariamente deve passar por diversas representaes que se efetivamatravs de transformaes.

Uma caracterstica das mais importantes do software que ele passvel de modificaes. Asmodificaes so necessrias para o desenvolvimento propriamente dito: modificaes para acorreo de erros e modificaes para a melhoria ou aprimoramento do software. Apenasquando um software desativado ele no sofre mais modificaes.

NecessidadeIdia

Formulaode Conceitos

SISTEMA

Construo

NecessidadeSatisfeita

Projeto

HW SW SW

SISTEMA



Em muitas aplicaes o software um elemento crtico. Um erro ou defeito pode acarretar aperda de grandes quantidades de dinheiro e, pior, pode custar a vida de pessoas. Comoexemplos desse tipo de software podemos citar programas de controle de aeronaves,monitoramento de pacientes, controle de metrs e trens, radares, etc. de vital importncia queos projetistas e programadores tenham conscincia do papel que desempenham.Se incontestvel a importncia do software, imprescindvel que ele atenda a um mnimopadro de qualidade. Diversas so as exigncias do mercado atual no quesito qualidade. Com oaumento na oferta, o consumidor de software torna-se cada vez mais exigente e os certificadosde qualidade j fazem parte dos requisitos para se adquirir, ou no, determinado produto desoftware. Isso leva os fornecedores a se preocuparem cada vez mais com tais certificados paraos seus produtos.

No desenvolvimento de um software de qualidade fundamental no descuidar de nenhum dosseguintes aspectos:

Tcnicos: Utilizao de metodologias atualizadas, bons algoritmos, estruturas de dadosadequadas, etc.

Gerenciais: Planejamento e acompanhamento das atividades de desenvolvimento,controle e administrao dos recursos, etc.

Suporte ao desenvolvimento: Estabelecimento de processos de apoio adequados satividades de desenvolvimento, tais como: documentao, gerncia de configurao desoftware, verificao e validao, mecanismos de reviso e outros.

No entanto, como tendncia geral, observam-se uma grande nfase nos aspectos tcnicos e umanegligncia, tambm grande com respeito aos aspectos gerenciais e de suporte. Uma expressopoderia resumir esta tendncia: Tecnologia tudo.

Entretanto, aps algumas dcadas de grande esforo e elaborao em tecnologia, de novaslinguagens de programao e de representao de conhecimento, de ambientes dedesenvolvimento cada vez mais sofisticados, de ferramentas CASE, de tecnologia de bancos dedados cada vez mais avanada, de novos paradigmas, tais como orientao a objetos, entreoutros, o que se v so projetos que continuam com atrasos sistemticos e estouros deoramento. Continua sendo muito comum, quase a regra, a Lei dos 90% que pode serenunciada da seguinte forma:

90% do desenvolvimento de um produto ou sistema de software realizado nos10% iniciais do tempo total. Os 10% restantes tomam os 90% finais do tempo

Alm do fato de a engenharia de software ser uma rea nova em que a abordagemmetodolgica ainda no est totalmente resolvida, como no caso das outras engenharias maistradicionais e maduras, este resultado frustrante, identificado em [CMM 93] vem do fato de serpraticamente impossvel obterem-se os benefcios de melhores mtodos e tecnologia noturbilho de projetos no disciplinados e impropriamente gerenciados. O problemafundamental a inabilidade de se gerenciar o processo de software.



19

Outro ponto que ainda hoje existem profissionais que vem o desenvolvimento de softwarecomo sendo uma arte em vez de uma cincia. A complexidade das aplicaes, adisponibilidade de ferramentas, os prazos estabelecidos para a entrega, a produo em largaescala, tudo isso exige uma abordagem profissional e sistemtica para o processo de produode software.

Devido ao software ser de natureza intangvel, complexa e muito sujeita a modificaes o seudesenvolvimento no tarefa trivial. Ela envolve riscos e a probalidade de um projeto desoftware ser abandonado antes de seu trmino grande, principalmente nos projetos maiores afigura 3.3 ilustra essa afirmativa:

Figura 3.3 - Projetos de software concludos X ComplexidadeOs projetos considerados tiveram a sua complexidade medida em termos de pontos de funo(FP) e o que pode ser observado que quanto maior a complexidade do projeto maior a suachance de ser concludo com atraso ou simplesmente abandonado. Levando-se em conta que odesenvolvimento de software uma atividade cara para as empresas o abandono de grandesprojetos acarretam grandes prejuzos.Das realizaes do ser humano, o software se destaca por trs caractersticas que o colocamnum patamar de distino: intangvel, altamente complexo e facilmente modificvel.Adicionalmente, este conjunto de caractersticas acarreta um fenmeno bastante conhecidodaqueles que lidam com software e que permeia todo o seu ciclo de vida: as modificaes.

5

10152025303540

5045

55

60657075

80

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 JonesPatterns of large software systems: Failure and successIEEE Computer - March 1995



As modificaes so intrnsecas ao software e diversas so suas origens: a identificao denovos requisitos, a evoluo do ambiente operacional, os avanos tecnolgicos, a identificaode novas maneiras de implementar funcionalidades, ou, ainda, uma das mais freqentes, acorreo de defeitos. As modificaes ocorrem, enfim, porque o conhecimento completo dosoftware, o que eqivale a dizer do problema que ele deve resolver, raramente obtido antes deseu desenvolvimento. E exatamente o conhecimento adicional, adquirido durante odesenvolvimento, a grande fora impulsionadora das mudanas no software.

Esta facilidade de modificao, em contrapartida, traz embutida o verdadeiro perigo: afacilidade 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 fornecerprodutos ntegros em prazos razoveis e com custos adequados. Se, por um lado, no se podeatribuir a responsabilidade por este problema a um nico fator, por outro, evidente que ocontrole inadequado das modificaes uma das causas mais cruciais. Todo desenvolvedor desoftware j experimentou as conseqncias da perda de controle do software:

Dificuldades imensas durante a integrao dos diversos mdulos para compor o produto,por problemas de interface;

Aps uma modificao qualquer do produto de software, erros removidos anteriormentereaparecem, ou ento, funcionalidades acrescentadas desaparecem, inexplicavelmente;

Dificuldades em se identificar a ltima verso do produto de software; Incapacidade de se reproduzir, no ambiente de desenvolvimento, um problema informado

pelo cliente; Perda dos arquivos-fonte que compem o sistema distribudo a cliente.

Todas estas ocorrncias, muito comuns, levam a altos custos de desenvolvimento, baixaqualidade de produto e insatisfao do cliente ou usurio final.

Tradicionalmente, as iniciativas de desenvolvimento de software preocupam-se quaseexclusivamente com os problemas tcnicos, dedicando poucos recursos e tempo ao ladogerencial e de suporte. Entretanto, tanto a demanda por produtos de software de complexidadecada vez maior, como o aumento de competitividade advinda da globalizao, impem aodesenvolvedor de software, especialmente o nacional, a necessidade de investir tambm nosaspectos de controle de seus processos e produtos.

Diversos so os agentes interessados em mudanas no software:

Clientes: interessados em modificar requisitos; Desenvolvedores: interessados em modificar detalhes tcnicos; Gerentes: interessados em modificar a conduo do projeto.

Ora, como quem compra, quem faz e quem administra tm interesse em modificaes elastornam-se praticamente inevitveis. Este fato por si s no bom nem ruim. As modificaesso necessrias e se h alguma coisa de ruim em decorrncia da forma como as modificaesso efetuadas no software.



21

3.3 Gerncia de Configurao de SoftwareGerncia de Configurao de Software (GCS) uma disciplina de apoio integrante do processode software que, de maneira sucinta, pode ser vista como uma abordagem sistemtica aoproblema de controlar um produto de software.

Tal a importncia da gerncia de configurao de software, que as principais iniciativasinternacionais de certificao de qualidade de processo de software: ISO 9000, CMM(Capability Maturity Model) e SPICE (Software Process Improvement and CapabilityDetermination), exigem a implantao de um processo de gerncia de configurao comorequisito indispensvel para a obteno de qualquer grau de certificao de qualidade.

GCS , em geral, relacionada a iniciativas de desenvolvimento de software em que o processode desenvolvimento bem definido, com atividades agrupadas em fases que possuem produtosbem definidos e documentados. Neste contexto, GCS a espinha dorsal sobre a qual as fasesdo desenvolvimento so conduzidas e os produtos, tanto finais como intermedirios,controlados.

A realidade dos desenvolvedores nacionais de software, entretanto, bem diferente. Boa partedo software em nosso pas desenvolvido por pequenas empresas, com no mximo 10funcionrios, que lutam contra a escassez de recursos e as deficincias tecnolgicas paramanter seus produtos no mercado. Por via de regra, o desenvolvimento de software umprocesso nebuloso, sem fases bem definidas. Especificao, projeto e codificao sorealizados de maneira entremeada. Testes, quando ocorrem, no so feitos de forma sistemticae racional. A documentao deficiente e, em geral, est sempre desatualizada. O resultadofinal um produto sempre em evoluo, que passa por um processo contnuo de modificaestanto para a incorporao de novas funcionalidades como para a correo de defeitos.

A Gerncia de Configurao de Software prope-se a minimizar os problemas surgidos duranteo ciclo de vida do software atravs de um controle sistemtico sobre as modificaes. No objetivo da GCS coibir as modificaes, pelo contrrio, facilit-las. Procura-se apenas cuidarque elas ocorram de forma sistemtica e controlada para evitar, ou minimizar, as suasdecorrncias negativas.

Cabe ressaltar aqui que a GCS no uma panacia para todos os problemas do software. umadisciplina de natureza tcnica/gerencial que define responsabilidades e autoridades e umprocesso chave num ambiente de desenvolvimento de software de qualidade.

Um aspecto que gera uma certa confuso estabelecer qual a diferena entre gerncia deconfigurao e manuteno.

Manuteno de software envolve atividades de Engenharia de Software, desenvolvidas aps aentrega de um produto de software. A Gerncia de Configurao de Software envolveatividades de controle e de acompanhamento, desenvolvidas durante todo o ciclo de vida doproduto de software. So atividades distintas.



3.3.1 GCS: Custos & Benefcios

A adoo de GCS por uma empresa envolve, naturalmente, custos e benefcios que devem serconsiderados a priori.

Os principais benefcios decorrentes da aplicao de GCS so:

facilidades para acomodar mudanas; maior controle sobre os produtos; economia de tempo de desenvolvimento; facilidades na gerao de verses diferentes de um mesmo produto de software; manuteno de histricos de produtos; facilidades de se voltar a situaes anteriores.

Quanto aos custos relacionados com a adoo de GCS por uma empresa sero necessrios doistipos de investimentos:

investimentos com a adoo, que envolvem capacitao (aquisio de informaes,consultorias, etc.) e treinamento (custos com treinamento de pessoal envolvido com aadoo de GCS).

investimentos para a implementao, que englobam recursos humanos (custos compessoal envolvido com a implementao 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 benefcios devem seravaliados criteriosamente. No h soluo ou frmula prontas para resolver esta relao. Oquanto 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 irreversvel perda de vidas ou de algunsmilhes de reais certamente ser muito maior que investimento em GCS para um software deautomao de loja, ou mesmo de gesto empresarial cuja falha, ainda que danosa, podeeventualmente ser reparada.

3.3.2 Impedimentos adoo de GCS

A adoo de GCS sempre enfrenta impedimentos que, de uma forma ou de outra, precisam sersuperados. Dentre os motivos, podem-se destacar:

Custos: o principal empecilho. GCS implica em diversos gastos: com pessoal,equipamentos, etc.;

Cultura da empresa: Resistncia das pessoas s mudanas, a falta de costume de seguirregras ou padres;



23

Aumento na formalidade e burocracia: No geral, haver procedimentos a seremseguidos que podem implicar em preenchimentos de formulrios, obteno deautorizao, etc., coisas que em geral as pessoas no gostam muito de fazer;

Falta de conhecimento do assunto: A implantao de GCS envolve todas as pessoas daequipe do produto e nem todas possuem as mesmas informaes sobre o assunto queainda desconhecido para a maioria.

Entretanto, se, por um lado, fatores acima so importantes, por outro lado, o impedimentomaior, que realmente pode significar o fracasso de um empreendimento de implantao deGCS, ausncia de comprometimento ou comprometimento insuficiente da gernciasuperior da empresa. Sem comprometimento real impossvel superar as barreiras colocadaspelos outros fatores.

3.3.3 GCS - Estado atual

A prtica de GCS varia muito no cenrio mundial. Em alguns pases, como os Estados Unidos,iniciativas a respeito foram tomadas principalmente por entidades governamentais (DoD,NASA e outras). Como essas entidades so grandes compradoras de software elas impem aosseus fornecedores algumas regras ou normas que garantam uma certa qualidade aos produtos. um caso tpico onde o mercado dita as regras. Tais prticas vo sendo disseminadas, com maiorou menor rapidez para o restante do mundo.

A globalizao atual faz exigncias sobre os produtos comercializveis tais como:

facilidades para acomodar modificaes; maior competitividade; maior controle de qualidade; obedincia a normas e padres.

Esforos considerveis vem sendo feitos pelos pases mais desenvolvidos em pesquisas eimplementao de ferramentas de GCS. Existe disponvel no mercado uma grande variedadede tais ferramentas as quais variam nos custos, potencialidades e complexidades.

No Brasil, o assunto ainda um tanto desconhecido e no se desenvolvem ferramentas de GCSpara o mercado. H um interesse crescente pelo assunto decorrente do aumento decompetitividade no mercado e da busca de algum certificado de qualidade como ISO 9000,CMM, SPICE, etc.

Verifica-se tambm uma maior incidncia do uso de GCS em empresas multinacionais ou degrande porte.

No contexto da Engenharia de Software, GCS assume um papel de relevncia, por estarintimamente relacionada com a qualidade dos produtos de software e por facilitar:

a comunicao sobre o estado de programas e documentos; a obteno do estado das modificaes;



o gerenciamento corporativo em busca de uma maior produtividade por menor custo; o suporte de manuteno.



25

4 CARACTERIZAO DE GERNCIA DE CONFIGURAO DESOFTWARE

O software durante o seu ciclo de vida passa por diversos estgios e representaes. Quando dasua concepo o software um simples conceito, uma idia de como resolver um determinadoproblema. A partir da a idia toma forma: primeiro em especificaes, projetos de estruturas,modelos e simulaes; depois evolui para programas e dados que se desenvolvem e semodificam at um produto final que por sua vez tambm pode evoluir e evoluir at que sejadesativado.

O processo de desenvolvimento do software contnuo no tempo, partindo de alguns conceitose mais alguns componentes iniciais que evoluem continuamente. O nmero de componentes,via de regra, aumenta com o desenvolvimento. A figura 4.1 ilustra a evoluo de um software.

Figura 4.1 - Evoluo de um software

Na verdade, a figura acima uma simplificao do processo, uma vez que, entre um estgio eoutro h muitos outros passos intermedirios e os elementos esto sujeitos a contnuastransformaes de correo, aperfeioamento ou de evoluo, como indica a figura 4.2.

Figura 4.2 - Evoluo contnua de um software

Tempo

Tempo



Durante o processo de desenvolvimento temos que a modificao intrnseca, ou seja, fazparte integrante do processo. Sem modificaes o software no passaria do terreno das idias.Modificaes so essenciais para o seu desenvolvimento. O inconveniente deste fato que asmodificaes podem acarretar a perda de controle do objeto de desenvolvimento. Isso implicaque as modificaes devem ser aplicadas mediante certos critrios que permitam manter aintegridade do software.

J que o processo de desenvolvimento de software evolui continuamente, o acompanhamento econtrole de todas as modificaes um problema complexo e de soluo difcil. A questo quese coloca o que, quando e como controlar.

Para resolver estas questes, utiliza-se o conceito de configurao-base. Entretanto, antes deintroduzi-lo, vamos apresentar alguns conceitos fundamentais.

4.1 Conceitos FundamentaisA seguir so apresentados alguns conceitos bsicos que foram adotados neste texto.

Configurao de software: Caractersticas fsicas e funcionais do software conformeespecificadas na documentao tcnica ou encontradas no produto.

Itens de Configurao: Este um dos conceitos mais importantes de GCS e tambm um dosque acabam introduzindo mais confuso no entendimento do assunto. Essencialmente existemduas definies para o termo. Numa viso simplificada de GCS, como a introduzida porPressman em [PRE 92], item de configurao (IC) pode ser caracterizado como:

Cada um dos elementos de informao que so criados durante o desenvolvimento deum produto de software, ou que para este desenvolvimento sejam necessrios, que soidentificados de maneira nica e cuja evoluo passvel de rastreamento

Nesta definio, tanto os documentos como os arquivos-fonte que compem um produto desoftware so ICs, assim como so ICs tambm as ferramentas de software necessrias para odesenvolvimento do produto em questo, tal como, compiladores, ligadores, arquivos de lote(batch), makefiles, etc.Neste conceito, configurao pode ser vista como o conjunto de todos os documentos,programas, itens de dados e componentes de suporte que compem o software.

A definio mais abrangente de item de configurao encontrada nos trabalhos denormalizao do governo norte-americano e em normas da indstria (IEEE, ANSI) queresultaram destes esforos. Nesta viso, item de configurao caracterizado como:

Um agregado de hardware, software, ou ambos, que designado para gerncia deconfigurao e que tratado como uma unidade dentro do processo de gerncia deconfigurao.

Se o item de configurao for composto exclusivamente de software, ele caracterizado comoItem de Configurao de Software (ICSW).



27

Nesta definio, IC uma unidade funcional que possui um ciclo de desenvolvimento eacompanhamento de GCS prprios. Nesta viso, o sistema em desenvolvimento particionadoem itens de configurao e o seu desenvolvimento visto como o desenvolvimento de cada umdos ICs. Cada IC, por sua vez pode ser particionado em outro conjunto de ICs e assimsucessivamente, at que se resulte um conjunto de ICs no particionveis, que sodesenvolvidos segundo um ciclo de vida propriamente definido.

Neste conceito, a configurao de um sistema de software o conjunto das configuraes dosICSWs integrantes do sistema.

importante salientar que a diviso de um sistema ou produto de software em ICs e adefinio do ciclo de vida de cada IC final uma deciso de projeto e no de GCS.Neste curso, para simplificao da exposio, a sigla IC, exceto quando explicitamenteindicado, referir-se- viso simplificada do conceito, enquanto que ICSW sempre implicar aviso mais abrangente de uma unidade funcional, integrante de um sistema maior, constitudaexclusivamente de software.

Configuraes-Base (Baselines): Por configurao-base entendemos um conjunto bemdefinido de itens de configurao que representam um estgio do desenvolvimento e que passvel de modificaes apenas mediante um mecanismo formal de alteraes. A figura 4.3ilustra a evoluo da configurao do software.

Figura 4.3 - Evoluo da Configurao do Software

4.2 Desenvolvimento de Software com Configuraes-BaseEm princpio, configuraes-base poderiam ser estabelecidas em qualquer ponto dodesenvolvimento. Entretanto, a grande vantagem do conceito est em se fazer coincidir oestabelecimento de configuraes-base com os finais de fase do ciclo de vida do produto.

O desenvolvimento com configuraes-base pode, ento, ser resumido nos seguintes pontos:

Caracterizao do ciclo de vida, identificando-se as fases por que o desenvolvimento dosoftware ir passar e dentro delas as atividades a serem realizadas e os produtos a seremdesenvolvidos;

Configurao-basedo Software

Documentos

ProgramasDados

Desenvolvimento de novos itens

Documentos

Programas

Dados

Nova Configurao-basedo Software



Definio do conjunto de configuraes-base. Para cada configurao-base planejada,deve-se estabelecer quais sero os ICs que a iro compor e quais as condies impostaspara seu estabelecimento;

Configuraes-base representam marcos no processo de desenvolvimento: uma novaconfigurao-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 deseus desenvolvedores e realiza-se com ampla liberdade, podendo os ICs serem criados emodificados com bastante facilidade;

Durante cada fase, entretanto, a modificao de uma configurao-base anteriormenteestabelecida somente pode ser feita de forma controlada, mediante um processo bemdefinido;

Ao ser estabelecida, cada configurao-base incorpora integralmente a configurao-baseanterior. Desta forma, em qualquer instante do desenvolvimento, a ltima configurao-base estabelecida representa o estado oficial da totalidade do desenvolvimento;

O estabelecimento de cada configurao-base somente realizado aps ser aprovada porprocedimentos de consistncia interna, verificao e validao.

Como ilustrao, vamos aplicar o esquema acima no desenvolvimento de um produto desoftware hipottico.

Em primeiro lugar, define-se um ciclo de vida convencional para o produto (cascata),incluindo tanto o desenvolvimento como a manuteno, constitudo das seguintes fases:Anlise de Requisitos, Projeto de Software, Codificao, Teste e Integrao eManuteno. Este modelo ser a base para a definio das configuraes-base. A figura 4.4ilustra a caracterizao inicial do desenvolvimento.

Figura 4.4 - Desenvolvimento do software & Estabelecimento de configuraes-base

Anlise Projeto Codificao Teste/Integr. Manuteno

Incio DesativaoEstabelecimento das Configuraes-Base



29

Em seguida, com base neste ciclo de vida, definem-se as configuraes-base, que sero:Configurao-Base de Requisitos, Configurao-Base de Projeto, Configurao-Base deCdigo. Estas configuraes-base sero estabelecidas, respectivamente, ao final das fasesAnlise de Requisitos, Projeto de Software, Codificao e Teste e Integrao. A figura 4.5ilustra a situao do produto de software com as citadas configuraes-base. Nesse ponto asconfiguraes-base esto definidas, bem como esto definidos os elementos que as iroconstituir e as respectivas condies para o seu estabelecimento.

Figura 4.5 - O desenvolvimento do software no seu incio

Os ICs que iro constituir a primeira configurao-base passam ento a ser desenvolvidos. Afigura 4.6 ilustra essa etapa do desenvolvimento durante a qual o desenvolvedor possui totalliberdade com respeito aos ICs que estiver desenvolvendo, isto , pode modific-los vontadeuma vez que configurao-base ainda no foi estabelecida.

Figura 4.6 Desenvolvimento dos ICs da Configurao-Base de Requisitos

Uma vez concludo o desenvolvimento dos ICs da Configurao-Base de Requisitos efetuadoo estabelecimento da mesma e, da em diante, os seus ICs s podero ser modificados mediantemecanismos formais estabelecidos pelo plano de GCS. A figura 4.7 ilustra o desenvolvimentologo aps o estabelecimento da primeira configurao-base.


Incio Desativao


Incio Desativao



Figura 4.7 Estabelecimento da Configurao-Base de Requisitos

Uma vez estabelecida a Configurao-Base de Requisitos os ICs da Configurao-Base deProjeto passam a ser desenvolvidos conforma ilustra a figura 4.8.

Figura 4.8- Desenvolvimento dos ICs da Configurao-Base de ProjetoConcludos os ICs da Configurao-Base de Projeto, a mesma estabelecida segundo ilustra afigura 4.9.

Figura 4.9 Estabelecimento da Configurao-Base de ProjetoDa mesma forma, as demais configuraes-base so desenvolvidas e estabelecidas at que sejaatingida a situao ilustrada pela figura 4.10 onde todas as Configuraes-Base j se encontramdesenvolvidas e estabelecidas.


Incio Desativao


Incio Desativao


Incio Desativao



31

Figura 4.10 - O Desenvolvimento de software concludo

Entre uma configurao-base e a configurao-base seguinte normalmente acontece a criaode novos itens como conseqncia natural do desenvolvimento. Isso o ilustrado nas figurasanteriores. Acontece que os ICs j concludos tambm so passveis de alterao, seja paraaperfeioamento, seja para a correo de erros que forem detectados. Assim, a evoluo dasconfiguraes-base devidas a dois fatores:

Criao de novos itens; Alterao em itens existentes.

Nas figuras anteriores, relativas ao desenvolvimento com configuraes-base, apenas oprimeiro fator foi considerado.

Na seqncia seguinte de figuras, temos um modelo mais real do desenvolvimento comconfiguraes-base em que so consideradas as evolues dos ICs que j fazem parte de umaconfigurao-base e que so modificados com algum objetivo.A figura 4.11, idntica figura 4.7, ilustra a situao onde a primeira configurao-base acabade ser estabelecida.

Figura 4.11 Estabelecimento da Configurao-Base de Requisitos

Uma vez estabelecida a Configurao-Base de Requisitos, inicia-se a fase de projeto e os ICs aela referentes passam a ser desenvolvidos. Os projetistas realizam as atividades da fase tendocomo referncia os documentos (ICs) formalmente estabelecidos na CB de requisitos.


Incio Desativao


Incio Desativao



Durante a fase, entretanto, pode ocorrer a necessidade de alterao dos ICs consolidados naconfigurao-base de requisitos. Por exemplo, o cliente, aps o estabelecimento da CB,percebe que h requisitos que no refletem exatamente suas necessidades e precisam seralterados. Ou, alternativamente, os projetistas durante as atividades da fase de projeto, aoganharem mais entendimento do software sendo desenvolvido, identificam inconsistnciasentre os requisitos.

Em situaes como esta, a realizao da modificao dever seguir passos bem definidos. Emprimeiro lugar, algum dever solicitar, ou propor, as mudanas necessrias. Algum dever,ento, analisar a solicitao, verificando sua relevncia, oportunidade e abrangncia, bem comoo impacto que causa nos custos e no cronograma de desenvolvimento. A partir da anlise daproposta, algum com a autoridade necessria dever decidir se a modificao ser ou norealizada. Em caso de deciso positiva, algum ser destacado para implementar amodificao, a qual, um vez realizada, dever ser verificada para a constatao de que foicorretamente elaborada e de que no cria inconsistncias na configurao-base. S ento amodificao ser consolidada na CB e estabelecida uma atualizao ou nova verso daconfigurao-base de requisitos.

Estabelecida a nova verso da CB, os projetistas prosseguiro as atividades da fase, agoratendo como referncia a nova CB. Durante a continuao da fase, outras necessidades demodificao da CB de requisitos podem surgir e, como conseqncia, dever ser aplicadonovamente o procedimento detalhado nos pargrafos anteriores. As figuras 4.12 e 4.13 ilustrameste fato.

Figura 4.12 Desenvolvimento da Configurao-Base de Projeto


Incio Desativao



33

Figura 4.13 Desenvolvimento da Configurao-Base de ProjetoA figura 4.14 ilustra o estabelecimento da Configurao-Base de Projeto a partir dos ICsdesenvolvidos na fase e dos ICs pertencentes Configurao-Base de Requisitos.

Figura 4.14 Estabelecimento da Configurao-Base de ProjetoE assim, de maneira similar, conforme as fases seguintes so executadas, as novasconfiguraes-base vo sendo desenvolvidas, estabelecidas e eventualmente modificadasconforme sugere as figuras 4.15 e 4.16.

Figura 4.15 Desenvolvimento da Configurao-Base de Cdigo


Incio Desativao


Incio Desativao


Incio Desativao



Figura 4.16 Desenvolvimento da Configurao-Base de Cdigo

Na figura 4.17 temos o desenvolvimento concludo.

Figura 4.17 Desenvolvimento Concludo

Os procedimentos de consistncia interna, verificao e validao so aplicados quando doestabelecimento de cada configurao-base e em cada atualizao da mesma.

4.3 DistribuiesUtilizamos a palavra distribuio para denominar o conjunto de itens, arquivos e ICs, que soentregues ao usurio ou cliente como resultado da liberao de uma dada configurao doproduto para utilizao em ambiente externo ao desenvolvimento.

No final de um desenvolvimento, aps o estabelecimento da ltima configurao-base, emgeral a configurao base de produto, ocorre a entrega do produto ao cliente. Entretanto, nemsempre entregue todo o contedo da configurao, ficando, por exemplo, os documentos deprojeto em poder do desenvolvedor. Por outro lado, muitas vezes, no que tange ao cdigogerado, o controle de GCS se restringe aos arquivos-fonte, no sendo mantidos sob controle osarquivos executveis, j que estes sempre podem ser obtidos a partir dos fontescorrespondentes.

Assim, o conjunto de arquivos que constitui uma distribuio do produto pode no ser ocontedo de uma configurao, ou tampouco um subconjunto dela.


Incio Desativao


Incio Desativao



35

Denominamos Estabelecimento de Distribuio o conjunto de aes que, partindo de umaconfigurao gera a distribuio do produto referente a esta configurao. A configurao qued origem distribuio denominada Configurao de Distribuio.

Assim, podem-se entender distribuio e configurao como conjuntos distintos de elementos,ainda que possuam itens em comum. Adicionalmente, esta separao permite estabelecerespaos de nomeaes independentes para distribuies e configuraes, fornecendo umavisibilidade diferenciada entre a organizao de desenvolvimento e os clientes. A figura 4.18ilustra esta diferenciao.

Figura 4.18 Identificao de Configuraes e de Distribuies

4.4 Definio formal de GCSGerncia de Configurao de Software o processo cujo objetivo identificar aconfigurao do software em pontos discretos no tempo e sistematicamente controlar asmodificaes configurao identificada com o objetivo de manter a integridade erastreabilidade do software ao longo de seu ciclo de vida.

GCS uma disciplina de natureza tcnica e gerencial que define responsabilidades eautoridades. Suas atividades se desenvolvem durante todo o ciclo de vida do software. Numambiente de desenvolvimento de software de qualidade, GCS constitui um processo-chave.

Ressalve-se que a aplicao de GCS no trivial, envolve aspectos culturais e decomportamento. Gerncia de Configurao de Software no uma panacia para todos osproblemas do software.

4.5 Atividades de GCSA GCS aplica-se a um software a ser desenvolvido atravs de quatro atividades principaistambm conhecidas como subprocessos de GCS:

Identificao de configurao; Controle de configurao;

1.0 1.1 1.2 1.3 1.4

D 1.0 D 1.1

desenvolvimento

clientes



Administrao de estado; Auditagem de configurao.

Tais atividades so detalhadas nos itens seguintes deste texto.

4.5.1 Identificao de configurao

O objetivo da identificao de configurao identificar e documentar as caractersticas fsicase funcionais do software sendo desenvolvido, fornecendo os meios para rastre-lo por todo ociclo de vida. Constituem atividades da identificao de configurao:

Identificar a estrutura do sistema de software; Identificar de maneira unvoca cada item de configurao; Definir inter-relacionamento entre os itens de configurao; Identificar o conjunto de configuraes-base a serem criadas e mantidas; Caracterizar o contedo de cada configurao-base, identificando os elementos bsicos

que a compem; Criar o mecanismo de nomeao dos Ics e configuraes-base; Definir o mecanismo de identificao de verso dos ICs e configuraes-base; Caracterizar os meios de acesso aos itens de configurao.

4.5.2 Controle de configurao

O objetivo do controle de configurao coordenar o processo de gerao e evoluo dasconfiguraes-base e seus ICs. Suas principais atividades so:

Definir o processo de modificao de configuraes-base; Estabelecer procedimentos e polticas de controle de modificao; Definir procedimentos e polticas de liberao de verses (distribuies); Desenvolver formulrios/documentos de apoio; Realizar o processamento de modificaes; Controlar a liberao de verses.



37

A figura 4.19 ilustra a seqncia de passos a serem seguidos para o processamento de umamodificao.

Figura 4.19 - Passos para processo de modificao de um IC

Iniciao da Modificao: Uma modificao deve ser iniciada por indivduos que tenhamprivilgio para tal dentro da organizao e seguindo um procedimento padro.

No plano de gerncia de configurao usado como exemplo neste texto (Apndice A), umamodificao iniciada com o preenchimento de uma requisio de modificao (RMS) quedeve ser apresentada ao responsvel pela gerncia de configurao (RGCS). A requisioconsiste no preenchimento de um formulrio padro (RMS) onde feita uma solicitao formalpara realizar a modificao.

Classificao: As requisies de modificao recebem uma classificao que objetivaestabelecer uma categoria para a modificao do ponto de vista dos elementos da organizaode GCS (proponente, RGCS, CCC, etc.), que sero detalhados mais frente. No nossoexemplo, uma RMS pode ser classificada pelo proponente e pelo CCC numa das seguintescategorias: crtica, muito importante, importante, interessante ou inconveniente. Essaclassificao visa orientar as aes que seguem a deliberao sobre a requisio, basicamente aprioridade de implementao.

Anlise da Modificao: Anlise da mudana envolvendo tanto os aspectos tcnicos como osaspectos no tcnicos:

Aspectos tcnicos: ICs envolvidos, interfaces afetadas, etc.; Aspectos no tcnicos: custos, prazos e cronograma de execuo, ganhos, riscos,

utilidade, aspectos contratuais, etc.Deciso sobre a Modificao: Uma deciso sobre a modificao obrigatoriamente deve sertomada pela(s) autoridade(s) competente(s). No nosso exemplo a avaliao de uma RMS feitapor um comit de controle de configurao (CCC) que analisa os seus mritos e delibera arespeito: aprova, no aprova ou posterga a deciso.

As modificaes no aprovadas no sero implementadas, porm todos os documentos einformaes produzidas durante o processo devem ser arquivadas para efeito de histrico.

Iniciao da Modificao

Classificao

Anlise da Modificao

Deciso sobre Modificao

Implementao

Verificao

Modificao da Configurao-Base



Implementao: Uma modificao, uma vez aprovada, passa para a fase de implementao.Os ICs envolvidos devem ser disponibilizados para que os tcnicos designados para aimplementao da modificao possam realiz-la. Durante esta fase, os itens de configuraoenvolvidos devem ficar bloqueados para evitar conflitos entre modificaes simultneas de ummesmo item.

Verificao: Uma vez realizada uma modificao ela necessita ser verificada antes de serconsiderada efetiva. Verificaes devem ser feitas no sentido de averiguar que a modificaorealizada foi feita conforme a sua requisio e que no se encontraram erros na implementao.Procedimentos de testes e verificao variam de empresa para empresa. Os tipos deverificaes a serem feitas sobre os ICs so parte integrante do plano de gerncia deconfigurao do produto.

Modificao da Configurao-Base: Se a modificao foi implementada, verificada eaprovada, so, ento estabelecidas as novas verses dos ICs e da configurao-base.

A figura 4.20 resume o processo de modificao de um produto de software.

Figura 4.20 - Processo de modificao

4.5.3 Administrao de estado

O objetivo geral do processo de administrao de estado estabelecer mecanismos de registroe de divulgao das aes realizadas no mbito do processo de GCS, incluindo mecanismos deacompanhamento das configuraes-base e ICs. So atividades da administrao de estado:

Estabelecer o conjunto de instrumentos de controle para apoio ao processo de GCS; Estabelecer procedimentos de comunicao de mudanas; Definir os tipos de relatrios a serem gerados;

PreparaoProposta deModificao

Anlisede

Impacto

Avaliaoda

PropostaAprovao ? FIM

Arquivamento

RMS

Implementao

Verificao

Incorporao

no

sim



39

Acompanhar o estado das configuraes-base; Acompanhar a evoluo das modificaes; Registrar e comunicar as atividades de GCS; Gerar relatrios de andamento das atividades de GCS; Fornecer, quando necessrio, a configurao do sistema e o histrico das modificaes

efetuadas e em andamento.

4.5.4 Auditagem de configurao

Estabelecer mecanismos de verificao das configuraes-base e dos ICs para garantir que:

modificaes realizadas estejam de acordo com as respectivas propostas; o produto de software em desenvolvimento esteja em conformidade com requisitos,

padres e acordos contratuais.Constituem atividades da auditagem de configurao;

Definir os tipos de auditagens que sero realizadas: Definir os procedimentos e cronogramas de auditagem; Garantir que as auditagens sejam realizadas; Gerar pareceres e relatrios.

Auditagens devem ser conduzidas sempre que uma configurao-base estabelecida oumodificada. Trs enfoques devem ser abordados nas auditagens: consistncia interna,verificao e validao.

A consistncia interna objetiva inspecionar se os elementos que constituem a configurao-base so consistentes entre si, e se normas ou regras de construo destes elementos foramseguidas corretamente, por exemplo, normas de codificao de arquivo-fonte, normas deformato de documento, etc.

A verificao objetiva inspecionar se a configurao-base consistente com a configurao-base que lhe est dando origem.

Por fim, a validao objetiva inspecionar se a configurao-base sendo avaliada, que umarepresentao do software em desenvolvimento, atende s expectativas e necessidades,eventualmente atualizadas, do software sendo desenvolvido.

4.6 Elementos organizacionais de GCSOs elementos de um projeto envolvidos com a gerncia de configurao podem variar emnmero e funes dependendo de aspectos tais como tamanho do projeto, categoria dosoftware, etc.



No texto iremos nos ater principalmente s responsabilidades e funes bsicas que devemestar presentes no processo, ficando os detalhes por conta do Plano de Gerncia deConfigurao onde tudo deve ser explicitamente declarado.

A figura 4.21 ilustra uma organizao tpica de gerncia de configurao de software.

Figura 4.21 Organizao tpica de GCS

Na organizao existem sempre elementos autorizados a solicitar modificaes (SM); ou seja,elementos que disparam o processo de modificao. No geral a solicitao de modificaopode ser feita por qualquer elemento relacionado com o produto de software, seja ou nopertencente ao corpo de funcionrios da empresa: tcnicos de desenvolvimento, gerentes,vendedores, clientes, etc..

O Responsvel pela Gerncia de Configurao de Software (RGCS) o elementoresponsvel pela coordenao de todo o processo de GCS. Tem como papel maior garantir quetodas a atividades definidas sejam executadas. Basicamente o Gerente de Configuraointerage com todo o resto do sistema providenciando que as modificaes sejam registradas,avaliadas, implementadas, verificadas e armazenada na base de dados do projeto. Esta funopode ser exercida por um ou mais indivduos, dependendo da dimenso e complexidade doprojeto.Na organizao de GCS, a Biblioteca representa o repositrio de todos os itens envolvidos noprojeto: documentos, programas, dados, etc. Este armazenamento deve apresentarcaractersticas tais como eficincia, segurana, capacidade de recuperao de diversas verses,etc. A biblioteca de responsabilidade de um Bibliotecrio que manipula o seu contedo e responsvel pelos acessos biblioteca e pela sua integridade.

B ib lio tec rioB ib lio tec rioB ib lio tec rio

R G C SR G C SR G C S

C C CC C CC C CC o rp o

T cn icoC o rp oC o rp o

T cn icoT cn ico

A u d ita g emA u d ita g emA u d ita g em

B ib lio tecaB ib lio teca

S M



41

O terceiro componente da organizao o Comit de Controle da Configurao (CCC), que o elemento responsvel pelas decises a respeito das propostas de modificaes. O CCCgeralmente composto por diversos membros sendo que um deles o responsvel pela decisofinal sobre as modificaes. As decises podem ser tomadas em diversos nveis dependendo doimpacto causado pela modif

apostila curso gcs

Documents