Gerência de Configuração de Software
1
Gerência de Configuração de
Software
Gerência de Configuração de Software, Gerência de Configuração ou ainda Gestão
de Configuração de Software é uma área da engenharia de software cuja equipe é
responsável por fornecer o apoio para o desenvolvimento de software. Suas principais
atribuições são o controle de versão, o controle de mudança e a auditoria das
configurações.
Roger Pressman, em seu livro Software Engineering: A Practitioner's Approach, afirma que
a gerência de configuração de software (GCS) é o:
conjunto de atividades projetadas para controlar as mudanças pela
identificação dos produtos do trabalho que serão alterados, estabelecendo
um relacionamento entre eles, definindo o mecanismo para o
gerenciamento de diferentes versões destes produtos, controlando as
mudanças impostas, e auditando e relatando as mudanças realizadas.
— Roger Pressman
Em outras palavras, a Gerência de Configuração de Software tem como objetivo responder
as seguintes perguntas:
•
•
•
•
O que mudou e quando?
Por que mudou?
Quem fez a mudança?
Podemos reproduzir esta mudança?
Cada uma dessas perguntas corresponde a uma das atividades realizadas pela Gerência de
Configuração de Software. O controle de versão é capaz de dizer o que mudou e quando
mudou. O controle de mudanças é capaz de atribuir os motivos a cada uma das mudanças.
A Auditoria por sua vez responde as duas últimas perguntas: Quem fez a mudança e
podemos reproduzir a mudança?
Histórico
A história da Gerência de Configuração de Software surge em meados da década de 1970,
quando os microprocessadores se tornaram populares e o software deixou de ser
considerado parte integrante do hardware para se tornar um produto independente. Nesta
época, os sistemas se tornaram cada vez maiores e sofisticados, ficando claro que seriam
necessárias metodologias próprias, diferentes das usadas no desenvolvimento de hardware,
para controlar o desenvolvimento desses sistemas.
O Departamento de Defesa (DoD) dos EUA foi um dos pioneiros nessa área, criando o
padrão DoD-STD-2167 que abordava o desenvolvimento de software. A abordagem do DoD
para controlar isto consistia da adoção de uma linguagem padronizada -- Ada -- e de
práticas padrão para desenvolvimento de software e Gerência de Configuração.
Outras organizações estavam por sua vez adotando práticas e métodos de Gerência de
Configuração de Software, algumas das quais envolvidas também com o desenvolvimento
de sistemas para o DoD e outros órgãos do governo Americano. Isto levou o próprio DoD a
adotar algumas práticas comerciais e eventualmente uni-las com seus padrões, gerando
assim o padrão IEEE/IEA 12207. Um outro padrão a respeito é o IEEE 828-1983.
Gerência de Configuração de Software
Funções
A Gerência de Configuração de Software é definida por quatro funções básicas[1] :
•
•
•
•
Identificação
Documentação
Controle
Auditoria
No início do desenvolvimento, a GCS permite à equipe de desenvolvimento identificar as
unidades que compõem o sistema de acordo com as funcionalidades que elas deverão
desempenhar, e as interfaces entre estas unidades, documentando assim a interação entre
elas. O controle contínuo da evolução destas funcionalidades e interfaces permite que a
integração entre estas unidades tenha sucesso continuado, com as mudanças devidamente
gerenciadas e documentadas. Por fim, a auditoria das funcionalidades identificadas,
documentadas e controladas garante a confiabilidade do sistema.
Conceitos e Terminologia
A terminologia especifica da GCS, como também sua história, tem dado origem a
controvérsias, de freqüentes variações. Ferramentas vendidas como também acadêmicas
tiraram vantagem disto para deliberadamente mudar a terminologia ou procedimentos para
reduzir a possibilidade dos clientes para mudanças, algumas vezes tentando desta maneira
redefinir o estabelecimento de acrônimos.
Em particular, o vendedor conhecido como Atria (depois Rational Software), agora uma
parte da IBM, usava SCM como padrão para Software Configuration Management (em
português: "Gerência de Configuração de Software") enquanto o Gartner Group usa o termo
SCCM ou Software Change and Configuration Management (em português: "Gerência de
Mudanças e Configuração de Software").
Entretanto, os conceitos básicos da GCS descritos abaixo são bem aceitos, divergindo de
um autor ou fornecedor para o outro meramente nos termos utilizados.
Configuração de software
Configuração é o estado em que um sistema se encontra em um determinado momento.
Este sistema pode ser composto de todo tipo de elementos, como peças de hardware,
artefatos eletrônicos ou não (i.e. documentos em papel), etc. A Configuração de Software
trata apenas dos elementos que se encontram em formato eletrônico e fazem parte dessa
configuração. Isso inclui todos os arquivos fontes, todos os documentos eletrônicos, as
ferramentas de software utilizadas para construir ou mesmo ler estes arquivos, o sistema
operacional utilizado, as bibliotecas de software, etc.
Essa configuração varia com o tempo, pois novos arquivos são incluídos, e arquivos
existentes são alterados ou removidos. O objetivo da Gerência de Configuração como um
todo é organizar todos estes elementos de forma a saber em qual estado o sistema se
encontrava nos momentos chave do desenvolvimento (por exemplo, quando o sistema foi
entregue ao cliente, quando o sistema passou por uma mudança de versão, quando o
sistema foi enviado para auditoria, etc). A Gerência de Configuração como um todo trata
dos elementos, incluindo hardware, necessários para a manutenção apropriada do sistema.
a Gestão de Configuração de Software trata especificamente dos elementos necessários a
construção de sistemas de software, e em geral, controla apenas os elementos em formato
2
Gerência de Configuração de Software
computadorizado.
Em Sistemas de controle de versão as configurações específicas são geralmente
identificadas pelo uso de tags ou labels (placas ou etiquetas, em inglês).
Linha-base
Linhas-base ou Baseline é um conceito de gerenciamento de configuração de software que
nos ajuda a controlar as mudanças, sem impedir seriamente as mudanças justificáveis.
Segundo PRESSMAN no contexto de engenharia de software, definimos uma linha básica
como um marco de referência no desenvolvimento de um software, que é caracterizado pela
entrega de um ou mais itens de configuração (em inglês, Software Configuration Items SCIs) e pela aprovação desses SCIs, obtida por meio de uma revisão técnica formal.
Exemplos de linhas-base:
• Versão 1.0
• Versão de correção de erros 1.1
• Versão personalizada do sistema para o governo americano
Em Sistemas de controle de versão uma linha-base é geralmente identificada pelo uso de
branches (galhos, em inglês).
Item de configuração de software
Durante o desenvolvimento de software, uma grande quantidade de informações é
produzida e cada um desses documentos produzidos que precisam sofrer controle de
versões e de mudanças é chamado de item de configuração de software O Item de
configuração é um elemento unitário que será gerenciado: um arquivo de código fonte, um
documento de texto, um projeto de uma placa eletrônica, uma planta feita em papel, um
CD-ROM de instalação de um sistema operacional, etc. A configuração de um sistema é
basicamente a lista de todos os itens de configuração necessários para reproduzir um
determinado estado de um sistema. Em geral números de versão são associados aos itens
de configuração de forma a podermos identificar também a evolução destes itens.
Exemplos de itens de configuração podem ser:
• Item A: CD de instalação do sistema operacional, versão 1.0
• Item B: Documento de ajuda do sistema em formato eletrônico, versão 2.0
• Item C: Processador de texto usado para imprimir o documento de ajuda, versão 5.0
e assim por diante.
Segundo Pressman os seguintes SCIs tornam-se alvos das técnicas de GCS e formam um
conjunto de linhas básicas (Baselines):
1. Especificação do Sistema.
2. Plano de Projeto do Software.
3. a) Especificação dos Requisitos de Software; b) Protótipo executável ou “em papel”.
4. Manual Preliminar do Usuário.
5. Especificação de Projeto: a) Descrição do projeto de dados; b) Descrições do projeto
arquitetural; c) Descrições do projeto modular; d) Descrições do projeto de interfaces; e)
Descrições de objetos (no caso do uso da metodologia OO).
6. Listagem do código-fonte.
3
Gerência de Configuração de Software
7. Teste de Software/Sistema: a) Plano e Procedimentos de Testes; b) Casos de teste e
resultados registrados.
8. Manuais Operacionais e de Instalação.
9. Programa Executável: a) Módulos; b) Módulos interligados.
10. Descrição do Banco de Dados: a) Esquema e estrutura de arquivo; b) Conteúdo inicial.
11. Manual Feito de Acordo com o Usuário.
12. Documentos de Manutenção: a) Relatórios de problemas de software; b) Solicitações de
manutenção; c) Pedidos de mudança de engenharia.
13. Padrões e procedimentos para engenharia de software.
Identificação de objetos
Definimos SCI, no mecanismo de identificação de gerenciamento de configurações, como
sendo a sua entidade mais elementar.
Segundo PRESSMAN dois tipos de objetos podem ser identificados:
• Objeto básico: uma “unidade de texto” que foi criada pelo engenheiro de software
durante a análise, o projeto, a codificação ou o teste.
• Objeto composto: coleção de objetos básicos e outros objetos compostos.
Cada objeto tem um conjunto distinto de características que o identifica unicamente: um
nome, uma descrição, uma lista de recursos e uma realização.
• Nome: cadeia de caracteres que identifica o objeto claramente.
• Descrição: é uma lista de itens de dados que identifica: - O tipo de SCI (ex.: documento,
programa, dados) que é representado pelo objeto; - Um identificador do projeto; Informações sobre mudanças e/ou versão
• Recursos: entidades fornecidas, processadas, consultadas ou, por outro lado, exigidas
pelo objeto.
Para um objeto básico, a realização é um indicador para a “unidade texto” e para o objeto
composto a realização é nula.
Controle de versões
Ocorrem muitos problemas durante o desenvolvimento de software que são causados por
falta de controle sobre os arquivos do projeto. Vamos a uma avaliação:
• Você já perdeu alguma versão anterior do arquivo do projeto?
• Já teve problemas em manter diferentes versões do sistema rodando ao mesmo tempo?
• Alguém já sobrescreveu o seu código por acidente e você acabou perdendo seu arquivo?
• Você tem dificuldades em saber quais as alterações que foram efetuadas e quando foram
feitas e quem fez?
Se você respondeu que sim para as perguntas acima, então você precisa de um sistema
para controle de versão para o seu projeto. Controle de versão deve ser utilizado em todo o
andamento do projeto de desenvolvimento de software.
O Controle de versão rastreia e controla todos os artefatos do projeto (código-fonte,
arquivos de configuração, documentação etc.) e assim consegue coordenar o trabalho
paralelo de desenvolvedores através das seguintes funcionalidades:
• Mantém e disponibiliza cada versão já produzida de cada item do projeto
4
Gerência de Configuração de Software
• Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a
existência de diferentes versões ao mesmo tempo (concorrência)
• Estabelece uma política de sincronização de mudanças que evita a sobreposição de
mudanças
• Fornece um histórico completo de alterações sobre cada item do projeto
Controle de Versão resolve diversos problemas básicos de desenvolvimento tais como uso
de diferentes versões de código, sincronização do trabalho paralelo de desenvolvedores no
mesmo projeto, recuperação de versões anteriores e registro do histórico de alterações.
A finalidade do Controle de versão é dar um controle maior sobre tudo que você altera no
seu projeto de software. Ele permite que você tenha um histórico de tudo o que você mudar
no seu projeto. Se você modificou aquela rotina para otimizar uma consulta, se você inseriu
uma nova função e retirou outra, se você modificou a imagem que era exibida em
determinada página html, tudo fica guardado neste histórico. Pra que isso ? Para o caso de
sua alteração causar algum problema! Se deu você nem precisa se preocupar em relembrar
o que foi que tinha alterado, se fez tudo correto, basta um simples comando e você
recupera o estado anterior.
Controle de versões dos itens do projeto
Todos os arquivos e diretórios que compõem o projeto ficam sob a responsabilidade do
sistema de controle de versão num local denominado de repositório, lugar onde se guarda,
arquiva, coleciona alguma coisa. É o local onde você vai guardar o seu projeto. Na prática,
é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu pendrive. O
repositório registra cada alteração realizada em cada arquivo e diretório controlado. À
medida que o projeto evolui, o repositório passa a guardar múltiplas versões dos arquivos
que compõem o projeto. Essas múltiplas versões são organizadas em revisões. Uma revisão
funciona como um clone de todos os arquivos do projeto em um determinado momento do
tempo. Os clone antigos são mantidos e podem ser recuperados e analisados a qualquer
momento. Para economizar espaço, apenas as diferenças entre as revisões costumam ser
armazenadas no repositório. Quando se deseja recuperar determinado arquivo, as
diferenças são analisadas e o arquivo é remontado de acordo com a revisão desejada.
Mesmo que não haja alteração em um arquivo entre uma revisão e outra, o número da
revisão do arquivo acompanha o número da revisão global, de modo a manter sempre um
grupo coeso e coerente de arquivos.
Diferentes versões de projeto
Alguns projetos precisam de variações específicas, conforme as necessidades específicas de
cada cliente, ou criação de um ramo para experimentações no projeto, sem comprometer a
linha principal de desenvolvimento. O sistema de controle de versão oferece
funcionalidades que facilitam a coordenação de ramos diferentes de desenvolvimento em
um mesmo projeto. As alterações feitas em um ramo muitas vezes precisam ser mescladas
em outro ramo. Essa operação é bastante delicada e é facilitada em muito com o sistema de
controle de versão, que permite bastante controle e automação no processo. Mesmo em
caso de uma fusão mal-sucedida, o sistema de controle de versão permite voltar ao estado
anterior, o que traz bastante segurança aos desenvolvedores.
5
Gerência de Configuração de Software
Sincronização de Mudanças Concorrentes
Como os desenvolvedores trabalham em paralelo e concorrentemente nos mesmos arquivos
do projeto, é necessária uma política para ordenar e integrar todas essas alterações, de
modo a evitar que um desenvolvedor sobrescreva as alterações de outro desenvolvedor. O
controle de versão além de rastrear e controlar alterações, também coordena a edição
colaborativa e o compartilhamento de dados entre os vários desenvolvedores de uma
equipe.
Problema do Compartilhamento de Arquivos
Cópia de Trabalho
Os desenvolvedores não trabalham diretamente nos arquivos do repositório. Cada
desenvolvedor possui uma cópia de trabalho que espelha os arquivos do repositório para
trabalhar com liberdade enquanto termina suas tarefas, isolado dos outros
desenvolvedores.
Política TRAVA-MODIFICA-DESTRAVA
Nessa política, o sistema de controle de versão permite que apenas um desenvolvedor por
vez altere um determinado arquivo do projeto. Ela é restritiva e frequentemente atrapalha o
trabalho dos usuários. O travamento pode causar alguns problemas administrativos e forçar
a uma serialização desnecessária.
Política COPIA-MODIFICA-RESOLVE
Nessa política, não existe travamento de arquivos. Cada desenvolvedor trabalha livremente
em qualquer arquivo da sua cópia de trabalho. Ao final, as alterações de cada
desenvolvedor são mescladas no repositório formando a versão final. A solução
"copia-modifica-resolve" parece um pouco estranha e bagunçada a princípio, mas funciona
bem na prática. Conflitos são raros e são causados basicamente pela falta de comunicação
entre desenvolvedores. Na grande maioria dos casos, as alterações não se sobrepõe e são
mescladas automaticamente pelo sistema de controle de versão.
Conjunto de mudanças
É o conjunto de todas as alterações que ocorreram no sistema para atender um
determinado fim, ou num determinado período de tempo. Fazendo um mapeamento dos
itens que foram mudados para uma dada versão do sistema com os motivos das mudanças.
Um exemplo de conjunto de mudanças:
Mudanças da versão 1.0 para a versão 1.1
•
•
•
•
•
Item
Item
Item
Item
Item
A mudou da revisão 1.0 para a revisão 1.1
B mudou da revisão 4.5 para a revisão 5.0
C foi eliminado
D foi acrescentado na revisão 5.5
E mudou de nome para item F.
6
Gerência de Configuração de Software
Gerência de mudanças
A Gerência de mudanças é uma parte geralmente negligenciada da Gerência de
configuração. Como ela não tem resultados imediatos para os desenvolvedores e
engenheiros de software envolvidos no projeto, estes acabam por não perceber sua
importância. Gerência de mudanças entretanto é uma parte importante da Gerência de
configuração, pois é a atividade que permite se saber o motivo de uma configuração ter
sido mudada para outra configuração. Esta atividade também pode ser parcialmente
automatizada, e diversos Sistemas de controle de versão já são integrados com sistemas de
gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada
mudança efetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos
em sistemas de software arquivos que listam as melhorias e mudanças entre duas versões.
Estes arquivos são resultado da gerência de mudanças, identificando o que mudou entre
uma versão e outra.
Exemplos
• mudança da versão 1.0 para 1.1 inclui:
• correção do problema 355
• correção do problema 356
• correção do problema 358
• nova funcionalidade de impressão de relatórios
• pendências para a versão 1.2:
• correção das mudanças 357 e 359.
• impressão de relatórios coloridos.
Histórico de Alterações
Como o repositório registra todas as alterações que foram efetuadas, o sistema de controle
de versão pode informar com facilidade quais as alterações que foram realizadas entre uma
revisão e outra, quando isso ocorreu e quem fez as alterações. Essas informações permitem
um controle maior sobre mudanças no projeto.
Auditoria de configuração
Executar Auditoria de Configuração Física
Uma Auditoria de Configuração Física (PCA) identifica os componentes de um produto que
serão implantados do Repositório do Projeto. Os passos são:
• Identificar a baseline a ser implantada (geralmente é apenas um nome e/ou número, mas
também pode ser uma lista completa de todos os componentes e suas respectivas
versões).
• Confirmar que todos os artefatos necessários, conforme especificado pelo Caso de
Desenvolvimento, estão presentes na baseline. Liste os artefatos ausentes em
Descobertas da Auditoria de Configuração.
7
Gerência de Configuração de Software
Outros Níveis da Auditoria de Configuração Física
Algumas organizações usam uma Auditoria de Configuração Física para confirmar a
consistência do design e/ou documentação do usuário com o código. O Rational Unified
Process recomenda que a verificação dessa consistência seja executada como parte da
atividade de revisão no decorrer do processo de desenvolvimento. No último estágio, as
auditorias devem se limitar a verificar os produtos liberados necessários que estão
presentes, sem se preocupar em revisar o conteúdo.
Executar Auditoria de Configuração Funcional
Uma Auditoria de Configuração Funcional (FCA) confirma que uma baseline atende aos
requisitos estabelecidos para ela. Os passos para a execução dessa auditoria são:
• Preparar um relatório que liste cada requisito estabelecido para a baseline, seu
procedimento de teste correspondente e o resultado de teste (aprovado/reprovado) da
baseline.
• Confirmar que cada requisito passou por um ou mais testes e que o resultado de todos
esses testes foi 'aprovado'. Em Descobertas da Auditoria de Configuração, liste quaisquer
requisitos que não tenham passado por procedimentos de teste e os requisitos que estão
com teste incompleto ou que foram reprovados.
• Gerar uma lista das CRs estabelecidas para essa baseline. Confirme que cada CR foi
fechada. Em Descobertas da Auditoria de Configuração, liste quaisquer CRs que não
estão fechadas.
Reportar Descobertas
Se houver alguma discrepância, ela será capturada em Descobertas da Auditoria de
Configuração conforme descrito anteriormente. Além disso, os seguintes passos deverão
ser executados:
• Identificar ações corretivas. Talvez, isso requeira a entrevista de vários membros da
equipe do projeto para que a origem da discrepância e as ações apropriadas sejam
identificadas.
• Para artefatos ausentes, a ação apropriada é geralmente controlar a configuração do
artefato ou criar uma CR ou tarefa que produzirá o artefato ausente.
• No caso de requisitos não testados ou reprovados no teste, o requisito pode ser
estabelecido para uma baseline posterior ou negociado para ser removido do conjunto de
requisitos.
• Para CRs em aberto, a CR pode ser simplesmente fechada, testada ou adiada para uma
baseline posterior.
• Para cada ação corretiva, atribua uma responsabilidade e determine uma data de
conclusão.
Política de Gerência de Configuração de Software
A finalidade da política de Gerência de Configuração de Software consiste em definir a
maneira como as atividades de Gerência de Configuração de Software serão executadas, o
momento adequado, os responsáveis em executa-las e os conceitos envolvidos no processo.
Entre as definições que devem contar nas políticas de Gerência de configuração de
software podemos citar:
8
Gerência de Configuração de Software
• Ferramentas para automatização do controle de revisões (Sistema de controle de versão)
caso seja usada.
• Caso não seja usada ferramenta, deve se definir o procedimento manual para o
controle de revisões.
• Caso existam elementos que não estejam em formato eletrônico (ferramentas de
hardware por exemplo), os procedimentos de controle de revisões para estes
elementos deve também ser definido.
• Ferramentas para o controle de mudanças
• Caso não seja usada ferramenta, deve também ser definido o procedimento manual.
• Controle de acesso às ferramentas de controle de revisão e controle de mudanças
• Nível de integração entre as ferramentas caso sejam ferramentas distintas
• Alguns fabricantes fornecem ferramentas que já desempenham os papeis de controle
de revisão e controle de mudanças num único sistema, enquanto outros fabricantes as
fornecem em separado.
• Periodicidade e granularidade do controle de revisões
• Recomenda-se um controle diário para elementos em formato eletrônico. A
granularidade em geral depende do tipo de item e da ferramenta utilizada.
• Papeis a serem desempenhados pelos membros da equipe dentro do contexto de
Gerência de Configuração de Software.
• Freqüência e forma de realização das auditorias de configuração.
• Em geral apenas a primeira auditoria de configuração de uma linha-base precisa de
intervenção humana, sendo que as auditorias subseqüentes apenas verificam se houve
quebra da integridade dos arquivos auditados.
Papéis
Uma das principais definições da política de Gerência de Configuração de Software são os
papeis a serem desempenhados. A política não determina quais pessoas desempenharão
quais papeis, cabendo isso a gerência de projeto. Alguns papeis necessários numa política
são:
• Gestor de configuração do projeto. Ele é o responsável por acompanhar as alterações dos
itens de configurações de um determinado projeto. Em geral este papel cabe ao
integrador.
• Gestor de ferramentas de Gerência de configuração. Ele é o responsável pela
manutenção da infra-estrutura necessária para o bom funcionamento da Gerência de
configuração no conjunto dos projetos da organização, ou no contexto do projeto, se for o
caso. Em geral é uma pessoa da área de infra-estrutura com bons conhecimentos da
plataforma operacional e das ferramentas usadas.
• Gestor de Configuração de Software, ou Responsável de Gerência de Configuração de
Software. Ele é o responsável por aprovar e gerenciar as atividades relativas a Gerência
de Configuração de Software, coordenar a equipe de Gerência de Configuração de
Software e algumas vezes, coordenar o trabalho de integração de sistemas.
• Auditor de Configuração de Software. Ele é o responsável pela realização das auditorias
de configuração nos projetos.
• Desenvolvedor. Ele é o principal usuário da Gerência de configuração de software, sendo
quem produz os itens de configuração que serão gerenciados.
9
Gerência de Configuração de Software
Bibliografia
• BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration
Management. Nova Iorque: Wiley computer publishing, 1999. 0-471-32929-0
• MIKKELSEN, Tim, PHERIGO, Suzanne. Parctical Software Configuration Management:
The Latenight Developer's Handbook. Upper Saddle River, NJ, EUA: Prentice Hall PTR,
1997. 0-13-240854-6
• MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no
Desenvolvimento do Software. Florianópolis: Visual Books, 2007. 85-7502-210-5
• PRESSMAN, Roger S.. Engenharia de Software. São Paulo: Pearson Makron Books, 1995.
85-346-0237-9
[1] BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration Management. Nova
Iorque: Wiley computer publishing, 1999. 0-471-32929-0
Ver também
• Sistema de controle de versão
• Engenharia de software
Ligações externas
• Gerência de Configuração (http:/ / www. pronus. eng. br/ artigos_tutoriais/
gerencia_configuracao/ gerencia_configuracao. php?pagNum=0)
10
Fontes e editores do artigo
Article Sources and Contributors
Gerência de Configuração de Software Source: http://pt.wikipedia.org/w/index.php?oldid=15531098 Contributors: Adailton, Alessandro70, Bisbis,
Bjverde, Brunosl, Cledermr, Girino, Leonardo.stabile, OS2Warp, Profvalente, Ricardo.bernardes, 30 edições anónimas
Image Sources, Licenses and
Contributors
Imagem:cquote1.svg Source: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote1.svg License: Public Domain Contributors: Adambro, Editor
at Large, Infrogmation, 1 edições anónimas
Imagem:cquote2.svg Source: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote2.svg License: Public Domain Contributors: Editor at Large,
Infrogmation
Licença
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/
11