Responsabilidades e Riscos PDF

Universidade do Sul de Santa Catarina
Responsabilidades e Riscos
Disciplina na modalidade a distância
Palhoça
UnisulVirtual
2007
responsabilidades_e_riscos.indb 1 7/2/2007 17:16:20

Apresentação
Este livro didático corresponde à disciplina Responsabilidades e

Riscos.
O material foi elaborado visando a uma aprendizagem autônoma,

abordando conteúdos especialmente selecionados e adotando uma
linguagem que facilite seu estudo a distância.
Por falar em distância, isso não significa que você estará

sozinho. Não esqueça que sua caminhada nesta disciplina
será acompanhada constantemente pelo Sistema Tutorial da
UnisulVirtual. Entre em contato sempre que sentir necessidade,
seja por email ou Espaço UnisulVirtual de Aprendizagem. Nossa
equipe terá o maior prazer em atendê-lo, pois sua aprendizagem é
nosso principal objetivo.
Bom estudo e sucesso!
Equipe UnisulVirtual.

Luiz Otávio Botelho Lento
Livro didático
Design instrucional
Flavia Lumi Matuzawa
2ª edição revista e atualizada
Palhoça
UnisulVirtual
2007

Copyright © UnisulVirtual 2007
Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.
005.3
L59 Lento, Luiz Otávio Botelho
Responsabilidades e riscos : livro didático / Luiz Otávio Botelho
Lento ; design instrucional Flavia Lumi Matuzawa [Viviane Bastos] .
2. ed. rev. e atual. – Palhoça : UnisulVirtual, 2007.
100 p. : il. ; 28 cm.
Inclui bibliografia.
ISBN 978-85-60694-98-3
1. Software gratuito. 2. Software gratuito – Processo decisório.

I. Matuzawa, Flavia Lumi. II. Bastos, Viviane. III. Título.
Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul
Créditos
Unisul - Universidade do Sul de Santa Catarina
UnisulVirtual - Educação Superior a Distância
Campus UnisulVirtual Bibliotecária Rafael Pessi Monitoria e Suporte Secretária Executiva
Rua João Pereira dos Santos, 303 Soraya Arruda Waltrick Vilson Martins Filho Rafael da Cunha Lara Viviane Schalata Martins
Palhoça - SC - 88130-475 (coordenador)
Fone/fax: (48) 3279-1541 e Cerimonial de Formatura Equipe Didático-Pedagógica Adriana Silveira Tecnologia
3279-1542 Jackson Schuelter Wiggers Angelita Marçal Flores Caroline Mendonça Osmar de Oliveira Braz Júnior
E-mail: cursovirtual@unisul.br Carmen Maria Cipriani Pandini Dyego Rachadel (coordenador)
Site: www.virtual.unisul.br Coordenação dos Cursos Caroline Batista Edison Rodrigo Valim Ricardo Alexandre Bianchini
Adriano Sérgio da Cunha Carolina Hoeller da Silva Boeing Francielle Arruda Rodrigo de Barcelos Martins
Reitor Unisul Aloísio José Rodrigues Cristina Klipp de Oliveira Gabriela Malinverni Barbieri
Gerson Luiz Joner da Silveira Ana Luisa Mülbert Daniela Erani Monteiro Will Josiane Conceição Leal
Ana Paula Reusing Pacheco Dênia Falcão de Bittencourt Maria Eugênia Ferreira Celeghin Edição – Livro Didático
Vice-Reitor e Pró-Reitor Cátia Melissa S. Rodrigues Enzo de Oliveira Moreira Rachel Lopes C. Pinto
Acadêmico (Auxiliar) Flávia Lumi Matuzawa Simone Andréa de Castilho Professor Conteudista
Sebastião Salésio Heerdt Charles Cesconetto Karla Leonora Dahse Nunes Tatiane Silva Luiz Otávio Botelho Lento
Diva Marília Flemming Leandro Kingeski Pacheco Vinícius Maycot Serafim
Chefe de gabinete da Itamar Pedro Bevilaqua Ligia Maria Soufen Tumolo Design Instrucional
Reitoria Janete Elza Felisbino Márcia Loch Produção Industrial e Flávia Lumi Matuzawa
Fabian Martins de Castro Jucimara Roesler Patrícia Meneghel Suporte Viviane Bastos
Lilian Cristina Pettres (Auxiliar) Silvana Denise Guimarães Arthur Emmanuel F. Silveira (2ª edição revista e atualizada)
Lauro José Ballock Tade-Ane de Amorim (coordenador)
Pró-Reitor Administrativo
Luiz Guilherme Buchmann Vanessa de Andrade Manuel Francisco Asp
Marcus Vinícius Anátoles da Silva Projeto Gráfico e Capa
Figueiredo Vanessa Francine Corrêa
Ferreira Equipe UnisulVirtual
Luiz Otávio Botelho Lento Viviane Bastos Projetos Corporativos
Marcelo Cavalcanti Viviani Poyer Diane Dal Mago
Campus Sul Diagramação
Mauri Luiz Heerdt Vanderlei Brasil
Diretor: Valter Alves Schmitz Vilson Martins Filho
Mauro Faccioni Filho Gerência de Relacionamento
Neto Adriana Ferreira dos Santos
Michelle Denise Durieux Lopes com o Mercado Secretaria de Ensino a
Diretora adjunta: Alexandra (atualização 2ª edição)
Destri Walter Félix Cardoso Júnior Distância
Orsoni
Moacir Heerdt Karine Augusta Zanoni
Nélio Herzmann Revisão Ortográfica
Campus Norte Logística de Encontros (secretária de ensino) Simone Rejane Ma
Onei Tadeu Dutra Ana Luísa Mittelztatt
Diretor: Ailton Nazareno Soares Presenciais
Patrícia Alberton Ana Paula Pereira
Diretora adjunta: Cibele Marcia Luz de Oliveira
Patrícia Pozza Djeime Sammer Bortolotti
Schuelter (Coordenadora)
Raulino Jacó Brüning Carla Cristina Sbardella
Aracelli Araldi
Rose Clér E. Beche Franciele da Silva Bruchado
Campus UnisulVirtual Graciele Marinês Lindenmayr
Diretor: João Vianney Guilherme M. B. Pereira Grasiela Martins
Design Gráfico José Carlos Teixeira James Marcel Silva Ribeiro
Diretora adjunta: Jucimara Cristiano Neri Gonçalves Ribeiro
Roesler Letícia Cristina Barbosa Lamuniê Souza
(coordenador) Kênia Alexandra Costa Hermann Liana Pamplona
Adriana Ferreira dos Santos Priscila Santos Alves Marcelo Pereira
Alex Sandro Xavier Marcos Alcides Medeiros Junior
Equipe UnisulVirtual Evandro Guedes Machado Maria Isabel Aragon
Logística de Materiais
Fernando Roberto Dias Olavo Lajús
Jeferson Cassiano Almeida da
Administração Zimmermann Priscilla Geovana Pagani
Costa (coordenador)
Renato André Luz Higor Ghisi Luciano Silvana Henrique Silva
Eduardo Kraus
Valmir Venício Inácio Pedro Paulo Alves Teixeira Vilmar Isaurino Vidal
Sumário
Palavras do professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
UNIDADE 1 – Responsabilidades e riscos no uso dos sofwares livres . . 17

UNIDADE 2 – Responsabilidades e riscos no desenvolvimento,
manutenção e distribuição de sofware livre . . . . . . . . . . . . 39
UNIDADE 3 – Responsabilidades para implantação do sofware livre . . 63
Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Respostas e comentários das atividades de auto-avaliação . . . . . . . . . . . . . 97

Palavras do professor
Caro aluno, seja bem-vindo à disciplina

Responsabilidades e Riscos.
Esta disciplina o colocará a par das responsabilidades

e riscos que você terá pela frente no uso, implantação e
manutenção do software livre. O objetivo não é esgotar
todo assunto, isso porque ele ainda é “embrionário” e
várias questões estão sendo levantadas a todo instante.
O desenho do mundo atual se resume em um grande

bloco de pessoas e culturas. A globalização é o novo
cenário no qual a internet e as tecnologias da informação
e comunicação assumem um papel de vanguarda.
Surgem assim novas possibilidades de relações
socioeconômicas. Essas relações forçam cada vez mais
as empresas no Brasil e no mundo buscarem soluções
eficientes, eficazes e com o menor custo; a criação de
espaços democráticos, práticas educativas, espaços para
os desenvolvimentos tecnológico, científico e econômico;
e a criação de políticas públicas e práticas alternativas.
Entre essas políticas públicas e práticas alternativas

surgiu o movimento mundial do software livre. Países
como a França e a Alemanha são pioneiros nessa
política. No Brasil, esse movimento também cresce
exponencialmente tendo o Governo um dos seus maiores
incentivadores.
Projetos realizados em equipes, utilizando a internet

como ferramenta de comunicação, vêm sendo
desenvolvidos em todo o país. Pode-se citar como
exemplo as Forças Armadas, o Poder Executivo,
prefeituras como a de Porto Alegre, universidades
federais, estaduais, particulares e empresas.

Além dessas organizações existem milhares de anônimos que
colaboram direta ou indiretamente para o sucesso do software
livre, analisando os seus bugs, desenvolvendo e melhorando
produtos e buscando soluções de adequação ao mundo real.
O custo é um dos maiores fatores que influenciam o

desenvolvimento do software livre. Os gastos com licenças de
uso de softwares proprietários, que inviabilizam o acesso ao seu
código-fonte, vêm sendo cada vez mais reduzidos. Esses recursos
são transferidos para setores de investimento, tornando a inclusão
digital mais acessível e adequada à realidade, movimentando
a economia, aproveitando o conhecimento oriundo de
universidades e escolas, e compartilhando os conhecimentos
tecnológicos com os demais países do mundo.
Portanto, a grande virtude do software livre é a independência

tecnológica. O software livre transpira liberdade de expressão,
possibilitando que milhares de programas alternativos sejam
construídos e utilizados sem que exista a cobrança direta pelo seu
desenvolvimento ou segredo do seu código.
Como já visto, para que um software possa ser considerado livre,

quatro aspectos são fundamentais:
liberdade para utilizar o programa, com qualquer

propósito;
liberdade para modificar o programa e adaptá-lo às suas
necessidades, tendo sempre o acesso ao código-fonte;
liberdade de distribuição de cópias, tanto grátis como
com taxa;
liberdade para distribuir versões modificadas do
programa, de tal modo que a comunidade possa
beneficiar-se com as sua melhorias.
Você viu também que o projeto GNU/Linux é um exemplo
de software livre mais divulgado hoje. Ele vem como uma
alternativa ao ambiente Windows (software proprietário), com
milhares de colaboradores e várias instituições governamentais,
privadas e de ensino para o desenvolvimento e manutenção de
produtos.

Software proprietário Software livre
É um modelo que restringe as liberdades do usuário: Garante a todos os usuários:

limita a finalidade do uso do software; a execução do software para qualquer uso;
limita o número de cópias que podem ser instaladas; a possibilidade de estudar o funcionamento de um programa
e a adaptação às suas necessidades;
nega o acesso ao código-fonte.
a possibilidade de redistribuir cópias;
tornar as modificações públicas de modo que a comunidade
inteira se beneficie da melhoria.
São normalmente distribuídos gratuitamente, apesar de não

Alto custo para o consumidor final. necessariamente serem gratuitos.
O programador abdica da liberdade de controlar sua obra, O programador abdica de um dos canais de receita pelo seu
em troca de salário e compromisso de sigilo. O distribuidor trabalho, em troca da preservação do controle dos termos de uso
torna-se proprietário de tudo. da sua obra.
Fonte: Nex Generation Center – Software Livre Módulo 1, Conceito - 2005
Logo, sob um ponto de vista genérico, a principal diferença entre

software fechado e software de código aberto está no fato de que
a produção de código aberto é mais eficiente. Essa afirmação
deve-se ao fato de que o software livre converte, de uma melhor
forma, trabalho e capital em produto.
Saiba mais sobre outras “vertentes” do software livre

em: <www.dwheeler.com/oss_fs_why.html> - Why
Open Source Software / Free Software (OSS/FS, FLOSS,
or FOSS)? Look at the Numbers!
Com os conceitos de software livre e software proprietário

relembrados, as unidades que seguem irão abordar os aspectos
das suas responsabilidades e riscos tanto no seu uso, implantação
e manutenção. Aproveitem ao máximo os conhecimentos que
serão apresentados, e faça desta publicação uma referência inicial
para aprofundar os seus conhecimentos.

Plano de estudo
O plano de estudos visa a orientá-lo/a no

desenvolvimento da Disciplina. Nele, você encontrará
elementos que esclarecerão o contexto da Disciplina e
sugerirão formas de organizar o seu tempo de estudos.
O processo de ensino e aprendizagem na UnisulVirtual

leva em conta instrumentos que se articulam e se
complementam. Assim, a construção de competências
se dá sobre a articulação de metodologias e por meio das
diversas formas de ação/mediação.
São elementos desse processo:
o livro didático;
o Espaço UnisulVirtual de Aprendizagem -
EVA;
as atividades de avaliação (complementares, a
distância e presenciais).
Ementa da disciplina
O contexto da responsabilidade e risco associada aos
produtos de softwares proprietários e livres. Abordagem
pela ótica de desenvolvimento, manutenção e distribuição
de software. Abordagem pela ótica de implantação e
uso. Comparação de responsabilidades e riscos para
softwares proprietário e livre. Implicações no contexto
organizacional.
Carga horária
A carga horária total da disciplina é de 30 horas-aula.

Objetivos
Geral
Estudar as responsabilidades e riscos do software livre, formando
uma base de conhecimento para as futuras tomadas de decisão
nos projetos de software livre.
Específicos
Identificar o modelo de responsabilidades associado aos
produtos de software.
Identificar os riscos pertinentes ao uso de produtos de
software.
Reconhecer prós e contras da aplicação de software livre
no contexto organizacional.
Despertar a necessidade do planejamento estratégico na
adoção de soluções.
Agenda de atividades/ cronograma

Verifique com atenção o Espaço UnisulVirtual de
Aprendizagem – EVA e se organize para acessar
periodicamente o ambiente da disciplina. O sucesso
nos seus estudos depende da priorização do tempo
para a leitura, da realização de análises e sínteses
do conteúdo e da interação com os seus colegas e
tutor.
Não perca os prazos das atividades. Registre no
espaço a seguir as datas com base no cronograma
da disciplina disponibilizado no EVA.
Use o quadro para agendar e programar as
atividades relativas ao desenvolvimento da
disciplina.

Atividades Datas-chave
Avaliação a Distância
Avaliação Presencial
Avaliação Final (caso necessário)
Demais atividades (registro pessoal)

1
UNIDADE 1
Responsabilidades e riscos no
uso de softwares livres
Objetivos de aprendizagem
Conceituar o que é responsabilidade em software livre.
Apresentar algumas responsabilidades do software livre

em diferentes situações.
Conceituar e apresentar como um modelo de

responsabilidade pode ser estabelecido.
Conceituar o que é risco em software livre.
Apresentar alguns dos diversos riscos que estão

presentes no mundo digital.
Seções de estudo
Seção 1 Responsabilidades do software livre.
Seção 2 Riscos do software livre.

Para início de conversa

A unidade está dividida em duas seções, as quais apresentam uma
ampla visão conceitual das responsabilidades e riscos do software
livre. Os conceitos apresentados são parte de toda a vivência
já comprovada no software proprietário, com as respectivas
características inerentes ao software livre.
Como você viu na disciplina anterior,
software livre são programas de Além dos conceitos, serão apresentados alguns exemplos que
computadores construídos de forma fazem parte do dia–a-dia do mercado.
colaborativa, via internet, por
uma comunidade internacional de Busque aprofundar seus conhecimentos nesse assunto. Será de
desenvolvedores independentes. grande valia no futuro do curso.
SEÇÃO 1 – Responsabilidades do software livre
“Responsabilidade”, segundo o dicionário Houaiss

de Língua Portuguesa, pode ser definida como
obrigação de responder pelas ações próprias
ou dos outros; caráter ou estado do que é
responsável.
Como na definição acima, todo software, proprietário ou não,

tem como obrigação atender as expectativas dos seus usuários,
oferecendo uma quantidade de recursos compatíveis com as suas
necessidades. Porém não se pode esquecer que a responsabilidade
de atender de forma adequada é distribuída a todo um conjunto
de organizações e colaboradores, que buscam responder, por
meio do software, a todas as expectativas e necessidades de seus
usuários.
No Brasil, o software livre possui algumas responsabilidades perante

a sociedade, o Governo, a comunidade acadêmica, empresas, entre
outros. Vamos ver algumas delas. (BRANCO, 2004)
18

Aspectos econômicos
Uma das responsabilidades diz respeito aos
aspectos econômicos quanto ao uso do software
livre. Apenas com o pagamento de royalties, o
Brasil transfere para o exterior, anualmente,
mais de um bilhão de dólares em pagamento de
licenças de software, em um mercado interno
que move por ano três bilhões de dólares. Isso
significa que um terço do que move a indústria
de software no Brasil é transferido, na forma
de royalties, às megaempresas monopolistas de
software norte-americanas.
Apenas 8,6% da população brasileira está

conectada à internet e, segundo dados oficiais, mais de 53%
desses usuários utilizam software ilegal sem autorização dos Segundo Marcelo D’Elia
proprietários. Portanto, são considerados criminosos pelas leis de Branco no paper Software
propriedade intelectual. Se formos oficializar toda essa população Livre na Administração
Pública Brasileira.
“fora da lei”, dobraríamos o envio de royalties para o exterior.
O uso do software livre tem como responsabilidade

minimizar ou acabar com o envio de royalties para o
exterior e acabar com a sensação de ser um criminoso
em relação à propriedade intelectual.
Pode-se definir software

proprietário como
Segurança programas de computador
com todos os direitos
O aspecto de segurança é amplamente abordado em listas de reservados ao dono do
discussão. O uso do software livre possibilitará o acesso ao copyright. O código-
fonte é secreto e sua
código-fonte, um dos aspectos primordiais para a segurança. Isso reprodução, bem como sua
é importante porque o usuário sabe, ao menos, as falhas e com modificação, é proibida
isso tem condições de tentar reduzi-las. e considerada crime.
Para usar legalmente
Afirma-se que um software fechado não pode ser usado e esse tipo de software, é
encarado como um software seguro, porque não se tem acesso preciso pagar taxas de
licenciamento.
ao seu código-fonte. O modelo de desenvolvimento do software
proprietário, na área de segurança, é muito desgastado. A
maior prova disso é que a própria Microsoft, para se manter no
mercado, abre parcialmente os códigos para o Governo.
Unidade 1 19

A responsabilidade do software livre é garantir aos

desenvolvedores o acesso ao seu código-fonte e
com isso possibilitar que esses possam de uma forma
minimizar as questões segurança, alterando o seu
conteúdo e/ou introduzindo novos módulos ao
sistema.
Independência tecnológica
Quando se domina a tecnologia existe a possibilidade de tornar-
se independente de fornecedores. Essa independência fortalece
a concorrência, aumenta a qualidade e gera novos recursos para
investimento.
O software livre tem como responsabilidade, contribuir para

o país ter condições de criar a sua independência tecnológica
quanto ao desenvolvimento de novas tecnologias de informação.
Quanto mais se usa o software livre, mais condições o usuário
tem para se tornar um desenvolvedor. Desse modo, permite
que o país participe na criação de soluções na comunidade de
informação e deixe de ser apenas consumidor de produtos e
tecnologias proprietárias.
Compartilhamento do conhecimento
A proteção da propriedade intelectual tem como
objetivo favorecer a liberdade de criação, mas hoje é
tratada como uma reserva de mercado. O software
livre veio com a responsabilidade de acabar com
esse aspecto possessivo do mercado. A democracia é
parte integrante dessa tecnologia, constatada pelo
compartilhamento do conhecimento entre os seus
desenvolvedores e usuários.
Comunidades de software livre espalham-se pelo

Brasil e pelo mundo. Essas comunidades procuram,
dentro do possível, compartilhar o conhecimento
adquirido no seu desenvolvimento. Esta característica, o
compartilhamento, é que ajuda na obtenção das grandes soluções
de software.
20

Modelo de responsabilidade
Estabelecer um modelo de responsabilidade para um software,
seja ele livre ou não, é uma questão muito filosófica e complexa.
É possível dizer que cada organização pode possuir o seu modelo
conforme o contexto em que vive.
Um modelo de responsabilidade pode ser visto

como um modelo que estabelece um conjunto de
obrigações (responsabilidades) que um software
deve ter em relação aos seus usuários. Ele terá como
objetivo servir de padrão para verificação de todas as
obrigações que um software deve cumprir.
Você deve estar se perguntando: qual seria o modelo de

responsabilidade do software livre?
Anteriormente citou-se um conjunto global

de responsabilidades que o software livre
possui. Estabelecer esse modelo pode ser
um grande desafio, mas não deverá fugir às
responsabilidades citadas. Não é possível ter
um padrão de modelo de responsabilidade.
Cada organização pode criar o seu padrão
conforme o seu projeto de implantação. Todavia,
um modelo de responsabilidade de software
livre, independente de organização ou objetivo
tecnológico, poderá seguir alguns aspectos.
a) Suportar a maioria dos recursos/tecnologias de hardware e

software encontrados no mercado.
Isso implica que o ambiente deve ser versátil, modular, portável

e robusto o suficiente para suportar a demanda existente no
mercado. Essa questão implica que o software livre deverá:
ser portável para a maioria das plataformas de hardware

disponíveis;
possibilitar a adequação às diversas arquiteturas de redes
de computadores;
Unidade 1 21

suportar diversas linguagens de programação;

ser compatível com as diversas versões de software livre;
e
suportar uma grande quantidade de periféricos
existentes.
b) Manter uma política contínua de desenvolvimento e

manutenção de produtos necessários aos seus usuários.
Essa questão é extremamente importante porque sem ela

acontecerá a descontinuidade de toda uma solução. Pode-se citar
como tarefas:
a manutenção e correção de bugs de programação e

segurança;
a atualização de versões do sistema.; e
o projeto, desenvolvimento e validação de novos
produtos.
O desenvolvimento de novos produtos e as atualizações de

versões seguem o modelo de desenvolvimento aberto. Portanto,
O software de código aberto pode cada nova versão liberada aos usuários é considerada um produto
ser modificado e copiado sem de qualidade. Entretanto, para informar se eles estão obtendo
pagamento de licença, e resulta uma versão estável ou não, normalmente utiliza-se o esquema que
de contribuições voluntárias de
se segue (FERREIRA, 2003).
milhares de programadores em todo
o mundo.
Versões r.x.y nas quais x é um número par. São versões
estáveis e o y é incrementado apenas quando correções de
bugs são efetuadas.
Ex: a versão 2.0.1 para 2.0.2 ocorreu apenas uma
correção de bugs.
Versões r.x.y nas quais x é um número ímpar. São

versões beta, destinadas somente a desenvolvedores.
Essas versões podem ser instáveis e falhar, estando
sujeitas a alterações por um período indeterminado de
tempo.
As diversas distribuições de software livre devem ser compatíveis

entre si e manter as mesmas características do projeto (ex: código
aberto e livre).
22

Saiba um pouco mais sobre código aberto em

<www.opensource.org>.
Estudo de caso
Veja a seguir a análise de um estudo de caso de Silveira sobre a
importância do combate à exclusão digital. Inclusão Digital, Software
Livre e Globalização
Contra-Hegemônica -
Sérgio Amadeu da Silveira
– <www.softwarelivre.
O combate à exclusão digital gov.br/artigos>.
“Temos de saciar a fome de conhecimento. Temos urgência em

promover a inclusão digital”.
Considero de grande importância o debate sobre as
potencialidades e desafios das novas tecnologias de
informação e comunicações. Elas oferecem oportunidades
para aprofundarmos a comunicação, o diálogo e o
progresso entre nossos países. (...) Tudo depende de
nossa solidariedade e vontade coletiva. Todos os povos
têm o direito aos avanços da inteligência e da criatividade
humanas para promover seu progresso e bem-estar. (....)
Vamos fazer da inclusão digital uma poderosa arma de
inclusão social.
O diálogo do Estado com a sociedade civil é decisivo. (...)
Temos de saciar a fome de conhecimento. O acesso aos
avanços tecnológicos deve ser o direito de todos - e não o
privilégio de poucos.
Temos urgência em promover a inclusão digital.
A velocidade das transformações tecnológicas pode nos
fazer perder oportunidades.
Por isso, tomei a iniciativa de transformar a inclusão
digital em política pública. (...) O software livre responde
a esses imperativos. Seu grande mérito está em favorecer
a transferência de tecnologia entre indivíduos e nações,
contribuindo para que todos possam ingressar na
Sociedade da Informação. [1]
Luiz Inácio Lula da Silva
Presidente do Brasil
Unidade 1 23

Como o presidente Lula cita, a inclusão digital é um fator de

desenvolvimento socioeconômico para o país. Combater a exclusão
digital requer um modelo de responsabilidade compatível com as suas
necessidades.
Veja artigo completo em Inclusão
Digital, Software Livre e Globalização A idéia do Governo de transformar a inclusão digital em política
Contra-Hegemônica www. pública leva em consideração quatro aspectos fundamentais
softwarelivre.gov.br/artigos. segundo Silveira:
a) o reconhecimento que a exclusão digital amplia a

miséria e dificulta o desenvolvimento humano local e
nacional. A exclusão digital não se trata de uma mera
conseqüência da pobreza crônica, mas torna-se fator
de congelamento da condição de miséria e de grande
distanciamento das sociedades ricas;
b) a constatação que o mercado não irá incluir na Era da

informação os extratos pobres e desprovidos de dinheiro.
A própria alfabetização e escolarização da população
Em poucas palavras, cibercultura não seriam massivas se não fosse pela transformação da
consiste em todo o conhecimento educação em política pública e gratuita. A alfabetização
adquirido via internet. digital e a formação básica para viver na cibercultura
também dependerão da ação do Estado para serem
amplas ou universalistas;
c) a velocidade da inclusão é decisiva para que a

sociedade tenha pessoas em número suficiente para
aproveitar as brechas de desenvolvimento no contexto da
globalização de trocas desiguais e, também, para adquirir
capacidade de gerar inovações;
d) a aceitação de que a liberdade de expressão e o direito

de se comunicar seria uma falácia se fosse apenas para
a minoria que tem acesso à comunicação em rede.
Hoje, o direito à comunicação é sinônimo de direito à
comunicação mediada por computador. Portanto, trata-se
de uma questão de cidadania.
Desse modo, uma política pública não é de responsabilidade

somente do Estado. Ele irá arcar com a maior parte dos recursos,
mas a formulação, a execução e a avaliação devem envolver as
comunidades locais, os movimentos sociais e as organizações
não-governamentais.
24

Nesse sentido, o mercado será atraído tanto para acrescentar

recursos quanto para colaborar com novas soluções tecnológicas.
As universidades também devem contribuir no processo,
buscando e disseminando soluções, contribuindo na formação dos
segmentos mais carentes da sociedade.
Análise
Para se estabelecer um modelo de responsabilidade específico
para esta situação, inicialmente necessita-se estabelecer quais são
os objetivos a serem alcançados. Sob esse prisma, as seguintes
questões foram levantadas:
acesso à rede mundial de computadores;

acesso aos conteúdos da rede (pesquisa e navegação em
sites de governos, notícias, bens culturais, diversão, etc.);
acesso à caixa postal eletrônica e a modos de
armazenamento de informações;
acesso às linguagens básicas e instrumentos para usar a
rede (MP3, chat, fóruns, editores, etc.);
acesso às técnicas de produção de conteúdo (html, xml,
técnicas para a produção de hipertexto, etc.); e
acesso à construção de ferramentas e sistemas voltados
às comunidades (linguagem de programação, design,
formação para desenhar sistemas, etc.).
As necessidades citas estão em sintonia com as responsabilidades

apresentadas do software livre. Pode-se afirmar, portanto,
Veja artigo completo em
que a responsabilidade do software livre na inclusão digital é Inclusão Digital, Software
primordial. Livre e Globalização
Contra-Hegemônica
Veja a seguir algumas responsabilidades atribuídas ao software www.softwarelivre.gov.
livre na inclusão digital segundo Silveira: br/artigos.
1) possibilidade de se ter acesso a informações de forma

eficiente e eficaz a um custo adequado à realidade da
maioria da população;
2) a utilização cada vez maior do uso do software livre

habilitando os usuários a serem novos desenvolvedores;
Unidade 1 25

3) compartilhamento do conhecimento, usando como

meio a internet, na busca de soluções que atendam as
necessidades da população brasileira e mundial;
4) a integração socioeconômica democratizando o

conhecimento tecnológico entre todos.
Estabelecidas algumas das responsabilidades, o modelo está

praticamente estruturado. É claro que outras responsabilidades
podem ser citadas, como aspectos referentes à fase de projeto e
implementação que devem ser levados em consideração.
O modelo de responsabilidade também deve abranger essas

questões, possibilitando uma verificação da correta execução de
todas as fases do processo de implantação do projeto de software
livre na organização.
É claro que este pequeno estudo de caso está incompleto. Faltam

ser analisadas as demais fases do processo de implantação de
software livre, que serão apresentadas nas demais disciplinas do
curso.
Na seção a seguir será abordada a questão de riscos do uso de

software livre. Você verá como as responsabilidades do software
livre podem influenciar nos riscos de seu uso.
SEÇÃO 2 – Riscos do software livre

Os riscos fazem parte da vida. Todos nós corremos riscos, basta
somente estarmos vivos. Com os softwares não é diferente.
Quando uma empresa adota uma solução de software, seja ela

baseada em software livre ou proprietário, ela está correndo
uma série de riscos. É claro que esses riscos, pelo menos na sua
maioria, são de conhecimento do gerente de TI da empresa,
pois é realizado um amplo estudo sobre as diversas tecnologias
existentes, adequação às necessidades da empresa, entre outros
aspectos relevantes, a uma tomada de decisão.
Nesta seção trataremos alguns riscos de lidar com software livre e

software proprietário.
26

Realize alguns questionamentos na escolha em relação ao

risco
Você sabe por que um usuário ou um gerente de TI

prefere adquirir um programa de computador mais
caro, teoricamente mais vulnerável aos ataques de
vírus e com um sistema de segurança não tão seguro?
Como resposta ao questionamento, de acordo com André

Gardini, alguns defensores do software livre citam que é Segurança é maior
simplesmente pela força da marca que um produto tem e outro em sistemas livres
não. - http://www.
comciencia.br/200406/
reportagens/04.shtml
Contudo, essa não é a única razão. Pode-se citar o aspecto de
domínio da tecnologia ou o oposto – desconhecimento total/
parcial da tecnologia de software livre. Apesar da questão do
software livre estar sendo divulgada com amplo domínio no
Brasil e no mundo, existe ainda uma grande resistência de
governos, empresas desenvolvedoras, usuários, entre outros que
lutam contra a nova realidade.
Reflita sobre essas duas questões. Essa reflexão pode

levar a algumas colocações como: apesar da crescente
aceitação do software livre por diversos países no
mundo, inclusive o Brasil, até que ponto pode-se
afirmar que esses softwares são seguros e imunes a
ataques de vírus? Aproveite esse espaço para inserir
seus comentários. Compartilhe-os com seus colegas
no Espaço UnisulVirtual de Aprendizagem!
Unidade 1 27

Ouve-se muito que o software livre é mais seguro que um

software proprietário. Essa afirmação deve-se ao fato de que no
software livre tem-se a capacidade de modificar o sistema de
acordo com as necessidades de cada ambiente (acesso ao código-
fonte), enquanto que em softwares proprietários essa capacidade
não existe. Somente se tem acesso às informações do sistema para
que se possa realizar as configurações liberadas pelo fabricante.
Não se pode esquecer que essa segurança está diretamente ligada

à capacidade do administrador/gerente de rede de minimizar os
problemas de segurança realizando as configurações adequadas
ao sistema.
Existe uma frase muito interessante, que serve como

exemplo: O Linux é um grande “queijo suíço”.
Essa frase retrata a capacidade do sistema operacional.

Sua segurança está diretamente ligada à capacidade
de operacionalidade do gerente da rede, isto é, o seu
conhecimento, a sua dedicação na manutenção e atualização de
patchs, por exemplo. Sendo assim, um sistema mal configurado e
desatualizado nas suas configurações possuirá um grande número
de vulnerabilidades.
É claro que não se deseja dizer que o ambiente Windows seja

mais seguro que o Linux. Não tem como garantir que ele não
possua um backdoor, ou que não possa ser atacado por um tipo de
Uma falha de segurança que vírus desenvolvido pelo fabricante, tornando-o inoperante. Em
permite o controle da máquina. algumas situações ele pode ser mais adequado.
Sendo ele uma grande “caixa preta” – na qual não se tem acesso a
nada a não ser ao que o fabricante oferece, junto com a facilidade
de visualização – ele torna-se mais adequado a administradores
e gerentes de rede que não possuem um grande conhecimento de
TI e necessitam em curto espaço de tempo assumirem funções
de gerência de redes. Além disso, há necessidade de se ter um
sistema com as suas manutenções e atualizações patchs em dia.
28

Grupos de software livre afirmam que problemas de

“backdoor” ou ataques de vírus podem ser evitados,
porque, como código está aberto, as falha podem ser
identificadas.
Esse é um aspecto relevante, reforçado pela razão de existirem

milhares de pessoas realizando uma verificação, quase que
constante, do código-fonte em busca de bugs de segurança.
Contudo, existe o outro lado.
Fabricantes de software proprietário e gerentes de TI questionam Pesquise em:

o fato de um software ter seu código-fonte aberto ser um bom <www.comciencia.
parâmetro para se avaliar segurança. Existe um estudo com o br/200406/
Linux e Windows feito pelo Instituto Forrester Research que reportagens/04.shtml>
analisou as vulnerabilidades dos dois sistemas durante o período

de junho de 2002 a maio de 2003:
A Microsoft mostrou um melhor trabalho na atualização

de vulnerabilidades, ficando com 25 dias de risco,
enquanto Linux Red Hat e Debian empataram em
segundo, com 57 dias vulneráveis. O Windows liderou
em vulnerabilidades que receberam atualizações: todos os
128 problemas sérios encontrados mereceram consertos.
A Red Hat veio em segundo, com 99,6% de atualizações
em falhas graves. (Instituto Forrester Research)
Abrir o código de um software proprietário é possível, mas

somente com o fabricante. Empresas que necessitem de alto nível
de segurança podem solicitar a abertura do código para uma
auditoria ou até mesmo para embutir uma solução compatível
com as necessidades da empresa.
A questão de ataques de vírus pode ser resumida em duas

abordagens interessantes.
Os softwares livres têm sua arquitetura para evitar que

outros softwares comprometam o seu funcionamento.
Os vírus que atacam a internet não infectam as
máquinas com GNU/Linux. Essa afirmativa se deve
simplesmente ao fato de que demandaria um enorme
trabalho para realizá-lo.
Unidade 1 29

Os vírus normalmente são implantados pela ação

humana. Pode-se dizer que a sua implantação de forma
automática, como acontece no Windows, ainda é um
pouco de “fantasia”. As falhas de segurança nos diversos
ambientes Unix, na sua maioria, baseiam-se na falta de
atenção ou no desconhecimento do ambiente em que se
está trabalhando.
O Windows hoje é um grande “ímã” de vírus. A

capacidade de se instalar e propagar é extremamente
eficaz. Pela sua grandeza de alcance entre usuários,
essa característica tornou-se mais evidente. Apesar dos
constantes esforços das empresas fabricantes de software,
para cada “vacina” criada, mais um vírus é criado.
Conclui-se que essa discussão não tem um final ainda. Ela

engloba vários aspectos de diferentes interesses.
Os riscos de trabalhar com grupos de software livre

Qualquer empresa, ao tomar a decisão de utilizar software livre,
fica automaticamente ligada a um grupo tanto na escolha de uma
distribuição Linux, quanto ao desenvolvimento de soluções.
Será que essa questão é um risco?
Acredita-se que sim. Pense em todo o investimento necessário

para se adquirir cultura em uma determina distribuição Linux;
em até quando existirá uma continuidade de trabalhos dessa
distribuição realizando a manutenção constante do seu código-
fonte, informando essas atualizações via o envio de patchs; e
na continuidade do desenvolvimento de novos produtos para
manter sempre o ambiente operacional compatível com as novas
tecnologias emergentes.
Tudo isso é um risco. Por isso, analise bem o histórico e as

futuras perspectivas dos grupos de software livre a que for se
“associar”. A descontinuidade de um trabalho, uma tecnologia,
um investimento pode levar uma empresa à falência ou ao
descontrole das informações de uma organização.
30

O outro lado da moeda é o uso de softwares

proprietários. Seria essa a melhor solução?
Se pensar que da mesma forma que um grupo pode descontinuar

um trabalho, um fabricante de software pode descontinuar um
produto com o objetivo de lançar outro. Um exemplo simples
disso é a migração do Windows 95/98 da Microsoft para o
Windows 2000, por exemplo, problemas de migração podem
ocorrer por incompatibilidade de software.
Outra questão também interessante para se refletir é qual

a melhor solução e por que escolher software livre e não
proprietário. Fica com você a decisão.
O risco da propriedade intelectual do software

A questão da propriedade intelectual vem sendo discutida
abertamente nas diversas comunidades do software livre.
Aspectos como cobrança de valores financeiros, entrega de
código às empresas, disponibilização de produtos desenvolvidos
para determinados grupos para outros são algumas questões em
pauta.
O sigilo das informações, como código-fonte, pode

vir a ser um problema caso não seja bem tratado.
A escolha de grupos de desenvolvimento de

soluções de software livre envolve não somente
a questão da sua continuidade, mas também
aspectos como confiabilidade.
Outras questões importantes são as constantes

desavenças entre empresas fabricantes
de softwares proprietários e grupos de
desenvolvimento de software livre. Estss
desavenças chegam a grandes litígios.
Unidade 1 31

SCO x software livre

No artigo, SCO e o futuro: litígios em software livre e
Leia o artigo em www.sco.com proprietário (WEINBERG, 2003), o autor manifesta a oposição
às tentativas do Grupo SCO de intimidar e extrair dinheiro dos
usuários e desenvolvedores de Linux. Vários comentários são
citados, os quais você deve ter conhecimento por completo e não
há condições de prever se o Linux e o software livre sofrerão
outras ameaças legais no futuro.
Veja a seguir alguns cenários apresentados.
Anteriormente ao caso SCO versus IBM, e SCO versus

a Comunidade Linux, o pior cenário legal para Linux
e software livre era o seguinte: o que poderia acontecer
se alguém contribuísse com uma porção de código ao
Linux e mais tarde, o empregador desse contribuidor,
ou terceiros com interesse na questão, alegassem que o
código não pertencesse ao software livre e sim a uma
companhia em particular – e que eles quisessem o código
de volta.
O artigo aborda esse cenário como uma situação plausível de

várias discussões. Porém fatos como esse poderão causar danos
financeiros substanciais a uma empresa.
O artigo cita uma lista mais abrangente de litígios que poderia

preencher volumes e mais volumes, concluindo que:
Enquanto a situação com SCO abre a questão do risco

relacionado à propriedade intelectual com o uso de Linux
e outro software livre, uma análise casual da história do
software proprietário revela a certeza e a vasta gama de
litígio em torno ao software tradicional, sua engenharia,
seu marketing e seu uso. (...) e (...) Com a finalidade de
comprovar suas reivindicações contra o Linux em juízo,
e responder a processos da parte de Red Hat e de IBM
e dos queixosos alemães LinuxTag and Tarent GmbH,
a SCO terá de demonstrar exatamente onde reside sua
propriedade intelectual no código-fonte Linux, e provar
como ela chegou lá.
32

A questão de litígios no software livre é um fator que sempre

aparecerá quando uma empresa de software proprietária sentir a
perda de mercado. O artigo por si exibe uma série de fatos, e cabe
à comunidade de software livre responder à altura para que ele se
torne ainda mais aberto.
Uma questão para refletir é: livre ou proprietário

– qual deles, provavelmente, irá manter você e seus
clientes fora dos tribunais?
Nesta seção você viu alguns riscos que se tem ao usar o software
livre. Esses riscos fazem parte de um projeto de implantação de
software livre. Eles devem ser tratados sempre com cuidado, de
forma a minimizar danos ao sucesso do projeto. Software Livre – Módulo 3
– Regulamentação – Next
Generation Center.
Questões de responsabilidade e risco referentes à Legislação
Com o crescente aumento da utilização do software livre, novas
necessidades no campo jurídico em relação ao usuário e prestador
de serviço apareceram. Com a criação da Creative Commons (São
Paulo), as definições de software aberto (Open Source) e software Projeto que tem por
livre são bastante semelhantes. objetivo expandir a
quantidade de obras
Para o movimento Open Source, o fato do programa de criativas disponíveis
ao público. Ele cria
computador ser de fonte aberta é uma questão de cunho prático
instrumentos legais para
e, para o software livre é de cunho ético. que um autor ou titular
de direitos possa dizer ao
Isso significa que as licenças de fonte aberta variam em relação mundo que não se opõe
à utilização do uso do código-fonte, e as licenças de software à utilização de sua obra,
livre necessitam compatibilizar com a GNU GPL ou com as no que diz respeito à
chamadas “quatro liberdades”: executar, estudar, redistribuir e distribuição, cópia e outros
tipos de uso.
aperfeiçoar o programa.
Portanto, independente da terminologia utilizada, as

responsabilidades do software livre quanto à abertura do código
para melhorias e auditorias, por exemplo, são mantidas. Para lembrar esse conceito
consulte a Unidade 1 da
Pode-se dizer que o crescimento do software livre vem sofrendo disciplina “Conceitos de
críticas pelo mercado de software proprietário, podendo ocasionar software livre, legislação
e uso”.
um risco no seu crescente desenvolvimento.
Unidade 1 33

Exemplo disso é a legislação atual quanto ao software

livre que vem sofrendo críticas pela ABES (Associação
Brasileira de Empresas de Software), que entende
que está sendo criada uma proteção que leva a uma
reserva de mercado.
A obrigatoriedade do Governo em usar preferencialmente

o software aberto, elimina a participação de diversos
desenvolvedores de software proprietários existentes
no território brasileiro. Uma das razões é a vontade de
reduzir custos não somente no Governo, mas também nas
organizações em geral.
O termo reserva de mercado vem causando preocupações

em empresas que estão ou já trabalham com software
livre, pois elas pensam que isso poderá causar uma
instabilidade do mercado.
Por outro lado, acredita-se que essa questão é passageira, que

o mercado irá se estabilizar e que cada um, software livre e
proprietário, possuirá a sua fatia bem definida.
Outro aspecto importante é a questão do fornecimento da

propriedade intelectual. É exatamente a exploração dessa
propriedade que gera a receita da empresa, movimento
econômico, empregos e arrecadação de tributos. A legislação
protege esse tipo de informação, e vale lembrar que é um dos
princípios do software livre.
Porém litígios vêm ocorrendo quanto a essa questão. Empresas

desenvolvedoras lutam para não abrir o seu código. Essa ainda é
uma discussão que irá causar grandes desafios para os usuários de
software livre.
34

Síntese
Durante toda a unidade você pôde observar quantas

responsabilidades o software livre possui perante as diversas
organizações, e também os riscos e cuidados que se deve ter para
a sua boa e adequada utilização.
Além dessas questões levantadas, existem várias discussões

ocorrendo no país e no mundo. No Brasil, o Governo, de uma
forma geral, vem coordenando essas discussões.
Pesquise em:
Normalmente, pode-se encontrar, no site do Governo, artigos <www.softwarelivre.gov.br>
ou discussões sobre o assunto. Quanto aos riscos de utilização do
software livre, principalmente no que tange à segurança, várias
outras referências que abordam discussões e soluções (parciais
ou totais) podem ser buscadas. Basta entrar no <www.google.
com.br> e digitar segurança de software, por exemplo. Vários
sites serão apresentados para você ler e buscar as informações
necessárias ao complemento do seu estudo.
É necessário que você aprofunde seus estudos sobre as

responsabilidades do software livre, pois será a base
do conhecimento para a implantação de modelos de
responsabilidades nos diversos projetos de implantação de
software livre que você poderá vir a trabalhar.
É importante ressaltar que sempre que for tomar alguma decisão

sobre a utilização de uma determinada tecnologia que faça uso do
software livre, tenha em mente que o sucesso do projeto estará
baseado sempre na análise que você realizará. Nunca se esqueça
dos riscos que terá que verificar e pesar na sua decisão. Também
não esqueça de determinar quais as responsabilidades você deseja
que essa tecnologia possua, isto é, pesquise, leia, teste, esgote
todas as possibilidades de conhecimento antes de tomar uma
decisão.
Espero que você tenha conseguido desenvolver o conhecimento

dos conceitos apresentados nesta unidade. Busque ter um
conhecimento mais aprofundado, pois você está dando os
primeiros passos ao encontro da independência tecnológica.
Unidade 1 35

Atividades de auto-avaliação
1) Qual ou quais os aspectos relevantes quanto à responsabilidade do

software livre na inclusão da população no mundo digital?
36

2) Quais parâmetros que seriam estabelecidos por você para minimizar os

riscos de uma descontinuidade de solução de software utilizada pela a
sua empresa?
Saiba mais
Para aprofundar os conhecimentos sobre o assunto tratado nesta

unidade pesquise mos sites mencionados ao longo desta, que
seguem a seguir:
<http: //www.softwarelivre.gov.br>
<http: //www.opensource.org>
<http: //www.comciencia.br>
Unidade 1 37

2
UNIDADE 2
Responsabilidades e riscos no
desenvolvimento, manutenção
e distribuição de software livre
Apresentar o que é desenvolvimento e manutenção de
software.
Conceituar desenvolvimento e manutenção do

software livre.
Definir as responsabilidades básicas do
desenvolvimento, manutenção e distribuição do
software livre.
Apresentar os principais riscos referentes ao
desenvolvimento, manutenção e distribuição do
software livre.
Seções de estudo
Seção 1 Desenvolvimento e manutenção de
software.
Seção 2 Aspectos básicos para o desenvolvimento e

manutenção de software livre.
Seção 3 Responsabilidades de desenvolvimento,

manutenção e distribuição de software
livre.
Seção 4 Riscos de desenvolvimento, manutenção e
distribuição de software livre.


A unidade está dividida em quatro seções, nas quais são
apresentadas as tarefas de desenvolver, realizar a manutenção
e a distribuição do software livre, apresentando também as
responsabilidades e os riscos de executá-las.
Procurou-se mostrar, além dos aspectos conceituais do

desenvolvimento, a manutenção e distribuição do software livre,
e as diferenças em relação ao software proprietário. Buscou-
se também alguns exemplos que fazem parte do dia-a-dia do
mercado.
Estude com atenção esta unidade e não se esqueça de aprofundar

seus conhecimentos nesse assunto, porque ele não se esgotará
nesta unidade.
SEÇÃO 1 – Desenvolvimento e manutenção de

software
Hoje os softwares de modo geral estão presentes em quase tudo
que nos cerca, desde um forno de microondas até um carro
de passeio. Milhares de investimentos vêm sendo realizados
no processo de desenvolvimento de softwares, aumentando a
produtividade e minimizando os aspectos de retrabalho.
Esta seção apresentará uma breve abordagem conceitual do

desenvolvimento e manutenção de software e de como as
organizações buscam solucionar os seus problemas.
O processo de desenvolvimento de software consiste

na sua construção, implantação e manutenção com
base em uma metodologia de modelagem do mundo
real, intrinsecamente moldado a um processo de
transmissão de troca de informações entre os seus
diversos colaboradores (MAFFEO, 1992, p.8).
Desenvolver um software é uma atividade que não pode ser

confundida com escrever programas para computador. Ela
possui características tecnológica e gerencial, envolvendo
procedimentos que exigem a abordagem simultânea e integrada
40

de aspectos técnicos e gerenciais. Esses aspectos não vivem de

forma harmônica, necessitando no processo de desenvolvimento
do software de um modelo de implantação de alto nível no qual
possam coexistir. Esse modelo é chamado de ciclo de vida do
software. De acordo com Maffeo (1992) sua construção segue as
seguintes especificações:
uma linguagem de representação com sintaxe e

semântica adequadas ao modelo com a formalidade
suficiente para evitar ambigüidades de comunicação;
hipóteses simplificadoras, ou seja, critérios utilizados
para realizar a segmentação de um sistema de grande
porte e complexo;
determinação de todas as entidades, especificando
todos os elementos referentes aos aspectos gerenciais
(pessoas, tarefas, etapas, documentos, etc.) e tecnológicos
(ferramentas e métodos) do processo de desenvolvimento;
todas as interações existentes entre as entidades do
modelo necessárias à sua construção;
leis básicas que manipulam o comportamento do
software.
O ciclo de vida do software proporciona

várias visões distintas de como se
deve concretizar o seu processo de
desenvolvimento. É um sistema complexo
e abrangente, possibilitando uma grande
flexibilidade nesse processo.
Atualmente, as organizações fazem uso da

norma ISO 12207 (Tecnologia da informação
– Processos de ciclo de vida de software),
que estabelece uma estrutura comum para
os processos de ciclo de vida de software,
cobrindo desde a concepção até a retirada do software do
mercado. A norma também provê um processo que pode ser
utilizado para definir, controlar e melhorar os processos de ciclo Saiba mais em: <www.
de vida de software. De acordo com o International Standard abelia.com/docs/12207cpt.
ISO/IEC 12207, as atividades, que podem ser executadas pdf>.
durante o ciclo de vida de software, estão agrupadas em cinco

processos fundamentais, oito processos de apoio e quatro
processos organizacionais.
Unidade 2 41

Processos fundamentais: aquisição, fornecimento,

desenvolvimento, operação e manutenção.
Processos de apoio: documentação, gerência de
configuração, garantia da qualidade, verificação,
validação, revisão conjunta, auditoria e resolução de
problema.
Processos organizacionais: gerência, infra-estrutura,
melhoria e treinamento.
As organizações procuram melhorar, a cada dia, o seu processo

de desenvolver ou adquirir software, minimizando as possíveis
manutenções que normalmente aconteciam. Os seguintes
modelos são as suas referências.
a) Capability Maturity Model (CMM). É um modelo

Saiba mais em: <http://www.sei. desenvolvido pelo Software Engineering Institute (SEI) para
cmu.edu/cmm/cmm.html>. melhorar os processos de desenvolvimento de software. Esse
modelo avalia a maturidade dos processos de software de uma
organização e identifica as práticas-chave que são requeridas
para aumentar a maturidade desses processos. Ele prevê cinco
níveis de maturidade: inicial, repetível, definido, gerenciado e
otimizado.
Quanto maior o nível, maior é a maturidade dos processos de

desenvolvimento de software de uma organização. No último
relatório do SEI/CMU, publicado em setembro de 2005 com
dados até junho do mesmo ano, o Brasil encontra-se em 14º
lugar dentre os países com maior número de avaliações CMM
realizadas por esse instituto (após ter permanecido na 13ª posição
desde dezembro de 2001), sendo o único país da América Sul
que aparece com mais de 20 avaliações (29); o Chile possui 20
avaliações; a Argentina, Colômbia, Peru, Uruguai e Venezuela
aparecem com menos de 10 avaliações.
b) ISO 15504 (SPICE) (Tecnologia da informação - Avaliação

de processos). Norma em desenvolvimento pela ISO/IEC em
Saiba mais em: <www.sei.cmu. conjunto com o projeto SPICE para avaliação de processos.
edu/iso-15504/resources/symp-se- Atualmente está publicada como um relatório técnico (ISO/
98.pdf>.
IEC TR 15504), com previsão de ser publicada como norma
(JOMORI; VOLPE; ZABEU, 2004).
42

c) Capability Maturity Model Integration (CMMI). É um

modelo desenvolvido pelo Software Engineering Institute (SEI) Saiba mais em: <http://
para melhoria da maturidade dos processos de uma organização. www.sei.cmu.edu/cmm/
Foi desenvolvido a partir de três modelos: SW-CMM (Capability cmm.html>.
Maturity Model for Sofìware), EIA/IS (Electronic Inte-rim
Alliance Interim Standard) 731 e IPD-CMM (Integrated Product
Develo-pment Capability Maturity Model). (JOMORI; VOLPE;
ZABEU, 2004).
SEÇÃO 2 – Aspectos básicos para o desenvolvimento e

manutenção de software livre
Como visto na seção anterior, o processo de desenvolvimento
de software envolve um conjunto de processos que vão desde a
sua construção até a sua manutenção. No software livre isso não
é diferente, o seu desenvolvimento necessita também de uma
metodologia e aplicação de critérios. Com o amadurecimento dos
usuários junto com o aumento da concorrência, a metodologia
e os critérios para o seu desenvolvimento irão garantir um
diferencial no mercado e resguardar o desenvolvedor dos reflexos
de um sistema mal concedido.
Um projeto de software livre pode surgir de uma

necessidade pessoal, com o objetivo de resolver
um problema. Os modelos de desenvolvimento de
software livre fazem dos seus usuários os seus grandes
colaboradores (BARAHONA; PASCUAL; ROBLES, 2003).
Portanto, a engenharia de software, por meio da utilização de um

conjunto de processos durante o desenvolvimento, apresenta-se
como uma provável solução para se obter uma boa qualidade no É o processo que engloba
resultado final no software livre. vários momentos do
software, indo desde o
seu desenvolvimento até
a sua manutenção, que se
preocupa com os eventos
O ciclo de vida do software livre que ocorrem após o seu
Cada projeto de software livre implementa uma instância do lançamento.
processo de software influenciado pela cultura interna, pelo
histórico e seus objetivos.
Unidade 2 43

O ciclo de vida de um projeto de software livre pode ser

descontinuado a qualquer instante, sendo sustentado somente
pela motivação da sua equipe de desenvolvimento (REIS, 2003).
Segundo Reis (2003) o ciclo de vida do software livre é baseado

em fatores. Para cada fator a ser considerado, existem aspectos
referentes ao ciclo de vida. Veja a seguir algumas fases do ciclo de
vida apresentadas pelo autor e que devem ser consideradas.
1 – Criação
A maioria dos projetos inicia com um único autor e motivado
por uma necessidade, sem o apoio necessário para o seu
desenvolvimento. No caso de grandes projetos, passa-se a ter
o apoio da organização, possibilitando o seu crescimento e o
seu sucesso. Nessa fase é difícil estabelecer uma seqüência de
atividades bem definidas, porque varia de projeto para projeto.
A maioria dos projetos é desenvolvida de modo informal, e o seu
tempo de desenvolvimento, que deve ser variável, tem que ser
adequado às expectativas do mercado.
2 – Lançamento ao público
É possível que ocorram lançamentos de versões para grupos
específicos, normalmente usuários que participaram diretamente
do desenvolvimento ou que são usuários diretamente interessados
no seu uso. Normalmente esses lançamentos (como visto na
Unidade 1) estão disponíveis via sites (como http://freshmeat.net),
ou em listas de discussão.
Após a fase de lançamento, inicia-se automaticamente

a fase de manutenção. Às vezes não se tem
condições de saber quantos usuários
estão fazendo uso da versão. Cada um
desses usuários classificados em níveis de
colaboradores pode informar ou realizar
modificações no código-fonte do software.
Vale a pena lembrar que existe a necessidade
de se ter uma gerência centralizada dessas
possíveis modificações.
44

3 – Evolução do software
É nessa fase que a maioria das atividades ocorre. Após o
lançamento do software novas versões são trabalhadas até chegar
a uma versão estável. A Figura 1 mostra uma idéia da seqüência
desde o lançamento do software até a sua versão final.
Figura 1- lançamento de um software
Seqüência de atividades realizadas para o lançamento de uma

nova versão:
I - lança uma versão;
II - essa versão está disponível para download para a

comunidade utilizar, realizar as sua próprias análises
e passar à equipe de desenvolvimento os problemas
encontrados durante o seu uso, como também as
sugestões para resolvê-los e/ou melhorar a sua utilização;
III - a equipe de desenvolvimento recebe essas

informações, e de posse das mesmas realiza uma
filtragem e análise, realizando as modificações
necessárias;
IV - após todas essas atividades, uma versão mais estável

é lançada;
V - essas atividades são repetidas até que uma versão

final estável seja alcançada.
A Figura 2 mostra a seqüência de atividades que são realizadas

entre a equipe de desenvolvimento e os colaboradores quando
lançada uma versão até o lançamento de uma versão mais estável
que a anterior.
Unidade 2 45

Figura 2 - Lançamento de uma nova versão do software
4 – Maturidade
Existem projetos de software livre que alcançam a sua
maturidade, isto é, produzidas as suas versões finais estáveis, a
continuação do seu desenvolvimento fica a critério da equipe de
desenvolvimento.
Em grandes projetos de software, a necessidade de continuar

o seu desenvolvimento é clara. Problemas de segurança, por
exemplo, podem ocorrer conforme vão sendo descobertos pelos
seus usuários. Esses problemas têm que ser informados, tratados
pela equipe de desenvolvimento para então gerar as correções. A
Figura 3 mostra como essa seqüência de atividades é executada.
46

Figura 3 - maturidade de um software
Após estudar o ciclo de vida do software livre, constatou-se que

consiste em um processo contínuo de atividades, procurando
sempre manter a estabilidade do produto. Esse processo, na
maioria das vezes iniciado por uma fonte, é mantido sempre
por um grupo de desenvolvedores em conjunto com vários
colaboradores.
Portanto, o desenvolvimento do software livre é um trabalho

de equipe, buscando não a perfeição, mas alcançar as metas
estabelecidas durante a fase de criação.
Um modelo de estudo do processo de desenvolvimento de

software livre
Segundo Maurício Pires Augusto em sua dissertação de
mestrado (2003), Feller e Fitzgerald (2002) apresentam um
modelo que busca estudar o processo de desenvolvimento do
software livre. O modelo é composto por cinco categorias.
Unidade 2 47

Qualificação. Tem como objetivo explicitar o que define

ou qualifica um sistema como sendo software livre e
quais são as suas características.
Transformação. A segunda categoria explora como
o processo de desenvolvimento dos programas é
organizado e realizado. Estuda como os colaboradores e
as organizações que os suportam ajudam na obtenção de
versões mais estáveis dos programas.
Stakeholders (desenvolvedores, usuários, empresas e
organizações). Usado para analisar os vários stakeholders
e os papéis desempenhados no movimento, sejam como
clientes, atores ou donos.
Ambiente. Avalia os aspectos geográficos e temporais
do desenvolvimento do software livre. São abordados os
locais onde as interações ocorrem entre desenvolvedores,
usuários e organizações e os eventos que ocorrem durante
o ciclo de vida dos programas.
Visão de mundo. Possui como objetivo entender
as motivações que permeiam as contribuições,
freqüentemente sem contrapartida, de talentosos
desenvolvedores. Existem algumas visões que pretendem
explicar o porquê dessa participação:
baseada em termos estritamente tecnológicos;
uma visão econômica, fundada em perspectivas
futuras para a carreira;
uma visão social e política que deve ser analisada tanto
em função dos indivíduos, quanto das comunidades de
que fazem parte.
Este modelo torna-se plenamente aplicável a grandes projetos

porque possibilita uma análise do comportamento que o
desenvolvimento do software poderá possuir.
48

Exemplos de áreas de aplicação do software livre

Com o objetivo de exemplificar o amplo desenvolvimento do
software livre com qualidade, algumas áreas de grande utilização
são citadas a seguir.
Sistemas estatísticos. Uma das principais ferramentas de

um profissional da área de saúde, mais especificamente
a epidemiologia, são os softwares estatísticos. A maioria
dos profissionais utiliza softwares proprietários. Porém
a Fundação Software Livre possui um software com as
mesmas características dos softwares proprietários.
Geoprocessamento. Trabalha o espaço geográfico.
Como exemplo, existe um projeto chamado Geolivre que
oferece informações básicas, confiáveis e permanentes
sobre o espaço geográfico do Estado do Rio Grande do
Sul.
Processamento digital de imagens. Consiste em uma
tecnologia que pode contribuir para diversas áreas
existentes no mercado. Um exemplo é a área de saúde,
reduzindo os custos de armazenamento e distribuição de
exames clínicos.
Telemedicina. O software livre é utilizado na
composição da estrutura necessária para compor a infra-
estrutura de telemedicina.
Nesta seção pôde-se conhecer os direcionamentos básicas do

desenvolvimento e manutenção do software livre. A seção que
segue apresentará quais as responsabilidades que se tem ao
desenvolver, manter e distribuir software livre.
Unidade 2 49

SEÇÃO 3 – Responsabilidades de desenvolvimento,

manutenção e distribuição de software livre
Consulte o Guia livre: referência O desenvolvimento do software livre é um processo contínuo.
de migração para software livre Algumas diretivas para o sucesso do software devem ser pensadas
do Governo Federal - <www.
desde o seu desenvolvimento até a sua implementação/
governoeletronico.gov.br/
governoeletronico/publicação/>.
migração. Essas diretivas serão primordiais para estabelecer as
responsabilidades do desenvolvimento e distribuição do software
livre:
antes de começar qualquer desenvolvimento, deve-se ter

um claro entendimento das razões para a criação;
assegurar-se de que exista apoio ativo da equipe de
desenvolvimento e dos seus usuários;
formar peritos e construir relacionamentos com a
comunidade do movimento software livre;
iniciar a migração com sistemas não-críticos;
garantir que cada passo da migração seja administrável;
criar canais de comunicação e bases de conhecimentos
internos na instituição.
As responsabilidades do software livre no processo de migração

em uma organização são primordiais para o seu sucesso. A
mudança para o software não deve ser um processo traumático. É
claro que esse processo é cercado de novos desafios, mas possíveis
de serem superados desde que haja toda uma preparação,
isto é, que diretivas para esse processo sejam estabelecidas
adequadamente, como citado anteriormente. Portanto, o sucesso
depende de algumas obrigações (responsabilidades) que o
software livre deve possuir no seu desenvolvimento:
ter a preocupação de inter operar com os sistemas

existentes. Essa característica possibilita que o software
livre possa conviver com os demais softwares da
organização. Tal preocupação inicia-se na fase de criação,
durante o desenvolvimento, na qual são levantadas as
necessidades, e entre essas encontra-se os aspectos dos
softwares existentes com os quais o software livre irá
conviver. Apesar de existirem diretrizes no país e no
50

mundo que pretendem uma mudança completa para

o software livre, a possibilidade é que um ambiente
heterogêneo seja mantido, temporariamente, tendo em
vista a necessidade de uma migração completa de todos
os dispositivos computacionais de uma organização.
Logo, a mistura de aplicativos software livre e
proprietários será mantida ainda por um longo período
de tempo;
ter condições de evoluir conforme as necessidades
de seus usuários. A responsabilidade de não ser
um software estático, isto é, evoluir conforme novas
necessidades apareçam, é primordial para a continuidade
do projeto. Mesmo em produção na fase da maturidade,
novos questionamentos podem ser levantados. Esses
questionamentos devem ser tratados pela equipe de
desenvolvimento que possui a responsabilidade junto com
os seus usuários de chegar a um produto que atenda aos
questionamentos;
possuir um código consistente e estável que execute
todas as atividades ao qual foi projetado. A consistência
e a estabilidade do código garantem que todas as
suas funcionalidades estão de acordo com o projeto.
A fase de lançamento é primordial para o sucesso
dessas responsabilidades, porque o software estará à
disposição, desde a sua versão inicial, para um grupo
de desenvolvedores e usuários que testarão todas as
suas funcionalidades. Os problemas e sugestões são
informados e novas versões mais estáveis são lançadas
até uma versão final. Relembra-se que a utilização
de software livre em servidor é uma questão básica,
porque parte-se da premissa que esse software encontra-
se na fase de maturidade, isto é, estável e com alta
probabilidade de continuidade;
Unidade 2 51

garantir um código com certo grau de segurança em

relação às diversas ameaças em que o software irá
operar. Inicialmente, deve-se certificar que a segurança
seja planejada desde o início, e não acrescentada como
uma questão posterior. Níveis de acesso devem ser
estabelecidos, de forma a garantir a compartimentação
das informações e funcionalidades oferecidas pelo
software. Aspectos de controle de acesso devem ser
previstos, de maneira que usuários não acessem o que
não possuem direito (“Need to know”);
prover interfaces de fácil operação para os seus
usuários. Além de prover funcionalidades, segurança,
entre outras obrigatoriedades, o software desenvolvido
tem que possibilitar que seus usuários acessem as
suas funções de forma fácil e agradável. Atualmente,
os sistemas operacionais oferecem APIs (Application
Program Interface) que possibilitam o desenvolvimento de
softwares com interfaces visuais, as mais fáceis, se bem
projetadas, dando aos seus usuários uma maior facilidade
de acesso aos recursos oferecidos pelo software;
possibilitar um fácil acesso e gerenciamento das
atividades do software. Essa responsabilidade está
atrelada não somente à segurança, mas também às
questões de como as suas funções foram projetadas.
Desenvolver um software com essas responsabilidades
corresponde a dar ao responsável pelo software dentro da
organização capacidade de ter acesso a funcionalidades
que viabilizem toda a sua administração.
O desenvolvimento de software livre com essas responsabilidades

é uma questão de prover um produto com qualidade e capacidade
de atender as necessidades e dificuldades que os usuários
apresentam aos seus desenvolvedores.
Distribuição do software livre

O propósito do software livre é torná-lo amplamente utilizado, e
a licença que o software carrega é projetada para encorajar o seu
uso.
52

Como exatamente isso é realizado?
A licença que acompanha o produto deixa claro a forma como

ele pode ser usado. O mais importante é que ela também deixa
claro o efeito da incorporação do software livre como produto. As
licenças espelharão a vontade do criador do software quanto à sua
utilização (GOLDEN, 2004).
A distribuição do software livre tem a responsabilidade de

garantir que as licenças sejam respeitadas durante a utilização do
software. Questões como alterações de código, aproveitamento de
código, entre outras, estão claras nas licenças, e durante a fase de
distribuição, elas têm que ser mantidas para que as características
do software livre sejam mantidas.
Para você saber sobre os tipos de licença e como elas

trabalham, consulte a disciplina anterior. Não se pode
esquecer que cada licença de software livre possui um conjunto
de responsabilidades, e cabe a quem for distribuí-las ter a
responsabilidade garantir que elas sejam cumpridas de forma
adequada.
Seção 4 – Riscos de desenvolvimento, manutenção e

distribuição de software livre
A segurança da informação passou a
ser hoje um fator crítico nas diversas
organizações mundiais. Especialistas
de defesa e de segurança de sistemas
de informações no mundo vêm
desenvolvendo técnicas de guerra
de informações. Um exemplo seria
adquirir o controle das redes públicas de
comunicação (LENTO, 2004).
A segurança é caracterizada pela

preservação de:
Unidade 2 53

confidencialidade – a segurança de um sistema

computacional não deve admitir que informações sejam
descobertas por qualquer pessoa não autorizada. A
confidencialidade garante a privacidade das informações
sensíveis em ambientes computacionais;
integridade – a segurança de informação deve sempre
manter a integridade da informação armazenada. Logo,
manter a integridade dos dados de um sistema significa
que esses não terão as suas informações corrompidas,
sejam de forma acidental ou intencional via pessoas
não autorizadas. A autenticação consiste numa forma
de verificar a origem do dado (quem enviou ou quem
introduziu o dado no sistema);
disponibilidade – consiste na capacidade de manter
disponível para os usuários do sistema os dispositivos de
software e hardware. O oposto da disponibilidade é o
DoS (Denial of Service).
O sucesso da segurança da informação se dá na implementação

de um conjunto adequado de processos (ex: políticas, práticas,
procedimentos, estruturas organizacionais e funções de
software), que garantem que os objetivos específicos de segurança
de uma organização sejam obtidos. O software livre faz parte
desse processo, porque no caso de ser mal planejado, projetado
e implementado, ele afetará diretamente as necessidades de
segurança da organização.
O risco representa a probabilidade de alguma coisa indesejada

acontecer em uma dada situação. Os departamentos de TI
tratam o risco como um dos fatores-chave para as tomadas de
decisões. Existe um grande esforço das organizações em reduzir
ao máximo os riscos que possam vir a sofrer durante as suas
transações.
Para minimizar os possíveis riscos de uma organização, técnicas

de análise de risco são utilizadas em sistemas de informação
corporativos ou individuais, verificando:
a) os danos prováveis ao negócio resultantes de uma falha de

segurança, levando em conta as potenciais conseqüências de
perda de confidencialidade, integridade ou disponibilidade da
informação ou outros bens; e
54

b) a probabilidade real de tal falha ocorrer na luz das

prevalecentes ameaças e vulnerabilidades, e os controles
atualmente implementados.
O resultado dessa análise ajudará a guiar e determinar as ações

gerenciais apropriadas para o gerenciamento dos riscos da
segurança da informação, e para implementação dos controles
selecionados para a proteção contra esses riscos.
É necessário realizar as revisões periódicas dos riscos de

segurança e controles implementados para:
considerar as mudanças nos requisitos do negócio e suas

prioridades;
considerar novas ameaças e vulnerabilidades; e
confirmar os controles que continuam eficientes e
apropriados à nova situação.
As organizações que lidam com TI consideram hoje o software

livre uma solução para reduzir os riscos e torná-los mensuráveis.
Para que isso seja possível deve-se entender quais são esses riscos.
A seguir serão apresentados alguns aspectos que podem vir

a oferecer algum risco no desenvolvimento, manutenção e
distribuição do software livre.
A integração entre a empresa e os desenvolvedores

O primeiro risco a ser levado em consideração é a relação que
deve existir entre uma empresa e os seus desenvolvedores de
software. Há pouco tempo surgiu um novo campo de atuação
profissional, a consultoria em software livre. Normalmente, o
profissional que atua nesse segmento tem
o perfil de analista de negócios e conhece
profundamente os melhores produtos, sites
e grupos que tratam do assunto.
Unidade 2 55

A implantação do software livre não é uma questão tão simples

assim, e com a finalidade de minimizar o risco durante o seu
desenvolvimento e manutenção, alguns aspectos devem ser
levados em consideração quanto à qualificação do profissional.
Conhecimento técnico. Possuir um excelente

conhecimento técnico sobre as tecnologias disponíveis
no mercado, o tamanho da comunidade relacionada e a
disponibilidade de mão-de-obra qualificada.
Conhecimento de negócio. Conhecer os processos da
organização que o software livre será implantado, sendo
capaz de avaliar a aceitação do produto.
Conhecimento financeiro. Capacidade de lidar com
os métodos de avaliação de risco e de investimento
disponíveis.
Risco de segurança e qualidade

Embora riscos de segurança e qualidade sejam diferentes, eles
podem ser tratados no mesmo pacote. Isso porque o risco para
uma organização que faz uso de software livre é conhecer o
código e a sua origem (GOLDEN,2004).
Essencialmente, o risco existe para qualquer usuário do produto.

Poderia se dizer que esse risco é minimizado quando se conhece
a empresa que desenvolveu o software e todos da sua equipe de
desenvolvimento são seus empregados. Os riscos que podem
acontecer por causa dos problemas com o código-fonte são:
o produto pode apresentar baixos níveis de qualidade

– esse problema pode ocorrer pelo baixo nível da equipe
que o desenvolveu. Um exemplo é a contribuição de
um desenvolvedor poder limitar a escalabilidade das
funcionalidades do software. Porém o problema pode ser
mais complicado ainda, com vários erros no código, o
que poderá ocasionar a queda do sistema;
o software pode ser vulnerável a ataques devido
aos bugs de segurança nele existentes – essas
vulnerabilidades são provenientes de um código de baixa
56

qualidade ou por ações deliberadas para que ele se torne

vulnerável. Um desenvolvedor malicioso pode inserir um
código para executar uma tarefa não compatível com o
projeto do software.
Os problemas resultantes desses riscos afetarão os aspectos

financeiros e operacionais. Por exemplo, suponha um software
com uma baixa qualidade no seu código, os seguintes problemas
aconteceriam:
necessidade de uma maior atenção dos seus operadores

para evitar possíveis quedas no sistema;
as quedas do sistema, caso aconteçam, poderão causar
perdas financeiras para uma empresa que dependa do seu
ambiente computacional para obter lucros (ex: comércio
eletrônico).
Risco de compromisso prematuro

Esse tipo de risco está ligado à escolha. Uma escolha realizada
de forma precipitada, sem analisar todos os aspectos relacionados
ao software, poderá ocasionar riscos à organização. Para que esse
tipo de risco seja minimizado, algumas providências podem ser
tomadas (GOLDEN, 2004):
verifique a origem da empresa desenvolvedora, a quanto

tempo está operando e quais projetos já foram realizados;
verifique se toda a equipe de desenvolvimento é
empregada da empresa, qual a sua experiência quanto
a desenvolvimento, qual a sua formação, se não possui
nenhum antecedente que o comprometa;
no caso de utilizar produtos prontos, verifique a origem
do software, faça uma auditoria do código do software
para verificar se não existe algum problema, faça
laboratório testando todas as suas funcionalidades e
vulnerabilidades;
verifique a portabilidade para as diversas plataformas de
hardware existentes;
Unidade 2 57

verifique a compatibilidade com os demais softwares

existentes; e
não esqueça de verificar se o fornecedor do software
terá condições de fornecer patchs de atualização para os
diversos problemas que apareçam ou novas versões mais
estáveis.
Risco do processo não mudar

As organizações tiveram cerca de 40 anos para acertar o seu
processo de escolha, procura e implementação de software
comercial. Elas gastaram centenas de bilhões de dólares
para otimizar as suas organizações para utilizarem software
comercial. Elas são peritas em escrever requisições de proposta
formal, negociações, contratos, SLA (service level agreements),
gerenciamento de atualizações e semelhantes. Cada uma dessas
táticas é projetada para a redução dos riscos que existe em relação
à dependência do fornecedor (GOLDEN, 2004).
Os produtos de software livre são criados e distribuídos de forma

diferente do software proprietário. Novos modelos de negócio
foram criados para atender as novas regras de propriedade
intelectual e menores expectativas de lucro. As organizações
que fazem uso de TI devem reconhecer as implicações do
software livre e desenvolver novos métodos para escolha, acesso
e implementação do mesmo. Elas devem ficar atentas à aplicação
de processos formais para não se expor aos riscos que possam vir
a ocorrer. Os processos devem estabelecer como proceder com
o software livre tanto quanto como no software proprietário,
guardada as devidas características.
Não existe fórmula para ser aplicada ao software livre. Somente

a avaliação completa do produto, assegurando que todas
as necessidades da organização estão sendo vislumbradas,
possibilitarão o sucesso da implementação do software livre. Os
benefícios desse processo são significantes:
redução de custos;
redirecionamento de investimentos para outras áreas; e
58

maior flexibilidade na resposta ao mundo dos negócios

da mudança de tecnologia.
Risco de distribuição de software livre

A primeira forma de endereçar esse risco é esclarecer qual será
o uso do produto resultante. Sem conhecer qual será o uso fica
difícil determinar qual a exposição do risco. Como parte do
plano do projeto do software, o entendimento do seu propósito é
primordial, e deve estar bem documentado.
O responsável pela distribuição do software tem que fazer tudo

atentamente na organização, de forma que as questões citadas
nas licenças sejam cumpridas. Deve existir uma política que
define o processo de distribuição e quando o software livre é
incorporado como produto. Questões como o risco de se infringir
a propriedade intelectual do software devem ser tratadas na
política.
O risco da propriedade intelectual do software livre

desenvolvido ser infringida é a maior preocupação do comitê
de desenvolvimento do software. Questões como contratos de
amarração, garantias de que qualquer alteração seja informada
são aspectos que minimizam essa preocupação. Mas como
garantir que isso aconteça? Essa questão vem sendo aperfeiçoada
pelos comitês de desenvolvimento no país e no mundo. Como
você acha que essa questão pode ser resolvida ou minimizada?
Unidade 2 59

Síntese
Durante toda a unidade você pôde observar algumas diferenças

existentes no processo do desenvolvimento do software livre e
proprietário. Percebeu que existe a necessidade de se estabelecer
novas regras de negócio para escolher e adquirir software livre.
Verificou também que os riscos de desenvolver e distribuir o

software livre são bem claros, tendo a maior preocupação a
origem e a qualidade do código-fonte.
Portanto, espera-se que você tenha conseguido desenvolver o

conhecimento dos conceitos apresentados. Nunca se esqueça o
assunto não foi esgotado nesta unidade, seja curioso, sedento por
conhecimento, pesquise e leia mais sobre o assunto.
1) Explique o processo de desenvolvimento e manutenção do software

livre no lançamento de uma nova versão.
60

2) Quais são as responsabilidades básicas que se deve ter no

desenvolvimento do software livre?
3) Quais as preocupações que se deve ter para minimizar o risco de uma

escolha precipitada de uma solução de software livre?
Unidade 2 61

Saiba mais
Consulte release management within open source projects.– No

“Proceedings of the 3rd Works-hop on Open Source Software
Engineering at the 25th International Conference on Software
Engineering USA: Portland – Justin R. Ehrenkrantz – 2003; e
Modularity in action: GNU/Linux and Free/open source

software development model unleashed. Alessandro Narduzzo
(2003)
<URL: //opensource.mit.edu/papers/narduzzorossi.pdf>
62

3
UNIDADE 3
Responsabilidades para
implantação de software livre
Conceituar o que é implantar software.
Conhecer algumas responsabilidades necessárias à

implantação de software livre.
Apresentar modelos necessários a se verificar na
implantação de software livre.
Identificar alguns riscos que podem aparecer durante a
implantação do software livre.
Conhecer uma situação real que descreve os aspectos
básicos para a implantação de software livre.
Seções de estudo
Seção 1 Implantação de software.
Seção 2 Responsabilidades de implantação de

software livre.
Seção 3 Riscos de implantação de software livre.


A unidade está dividida em três seções, as quais apresentam uma
visão conceitual da implantação de software em organizações. Os
conceitos apresentados são parte de uma pesquisa de engenharia
de software livre em paralelo com as diversas experiências vividas
pelos órgãos governamentais.
Você verá nesta unidade um modelo de projeto de implantação do

Governo Federal, que cita as diretivas e os objetivos que devem
ser alcançados com o projeto.
Vale lembrar, mais uma vez, que este material não supre todas as
informações sobre o assunto. Busque sempre aprofundar mais os
seus conhecimentos!
SEÇÃO 1 – Implantação de software
“Implantar” segundo o dicionário Houaiss da língua

portuguesa, pode ser: plantar algo; inserir; iniciar e
promover o desenvolvimento de algo ou de si mesmo.
“Implantar software” pode ser visto como um processo que

envolve várias etapas para inserir uma nova solução de tecnologia
atendendo uma série de necessidades de seus clientes. “Implantar”
um software exige um conjunto de diretrizes e procedimentos
Para saber mais consulte o site: básicos:
<www.allianceconsultoria.com.
br/content.asp>. ter conhecimento abrangente das particularidades da
empresa;
o desenho de soluções e planejamento estratégico deve
ser compatível e adequado às particularidades do seu
negócio;
direcionar os esforços para uma melhor conveniência do
custo/benefício;
interfaces amigáveis e totalmente adaptáveis a quaisquer
sistemas;
64

total assistência aos processos de carga e auditoria;

É o processo que consiste
capacitação de todos os usuários para o melhor
da carga das informações
aproveitamento das funções e recursos do software; e em banco de dados.
prestação de assistência aos clientes no caso de
treinamento e sugestões.
Podem existir várias metodologias para implantar software,

mas elas têm que estar comprometidas com todos os níveis
organizacionais, de forma que a solução implantada seja
duradoura e eficiente quanto a resolver as necessidades solicitadas.
Para isso, necessita-se rigor técnico na validação dos processos
de implantação, exigindo especialistas e tornando a formação da
equipe um fator decisivo no sucesso da metodologia utilizada.
A implantação de software sob um ponto de vista da

engenharia de software
No ciclo de vida do software, a implantação do software
vem logo após a sua implementação e trabalha em
conjunto com a fase de manutenção. Enquanto a
manutenção costuma consumir uma quantidade
grande dos recursos alocados ao processo de
desenvolvimento, a implantação está longe
de constituir um processo trivial tendo
em vista que, em geral, provoca impacto
significativo na cultura do sistema
(MAFFEO, 1992).
Existem tendências que procuram abordar o problema

da implantação de forma preventiva, utilizando o modelo
de ciclo de vida do software implementado por metodologia
de desenvolvimento que assegure a necessidade de esforços
mínimos de manutenção para o produto implantado e que
procure atender as necessidades de treinamento e minimizar o
impacto da implantação.
Na verdade, não existem modelos suficientemente testados

e eficientes que tratam da questão do software implantado.
Entretanto, vários esforços vêm sendo realizados no sentido
de criar um modelo de desenvolvimento de software com
processos que possibilitem uma implantação tranqüila a qualquer
organização.
Unidade 3 65

Vale a pena lembra que o usuário é parte

fundamental no processo de implantação do
software, porque é dele que todas as informações
necessárias (ao planejamento e ao controle da
informação) são originárias.
SEÇÃO 2 – Responsabilidades de implantação de

software livre
Motivações não faltam ao Governo brasileiro para implantar o
software livre. Nas unidades anteriores foram citadas algumas
das principais motivações para desenvolver um programa de
implantação de software livre como (BRANCO, 2004):
a questão macroeconômica brasileira – quanto o país

paga por licenças de uso de software;
garantir uma maior segurança das informações do
Governo – acesso ao código-fonte;
a ampliação da autonomia e capacidade tecnológica do
país – a aquisição e evolução do conhecimento;
maior independência de fornecedores – flexibilidade de
fornecedores e produtos; e
a defesa do compartilhamento do conhecimento
tecnológico como alternativa para os países em
desenvolvimento.
Estas motivações irão atenuar os diversos questionamentos ou

problemas que possam vir a acontecer durante o processo de
implantação. A seguir, é mostrado o processo de implantação
do software livre em empresas, o que não implica que possa ser
aplicado a organizações governamentais.
66

A implantação do software livre sob o ponto de vista da

empresa
A implantação do software livre pode ser um processo simples ou
traumático, dependendo de como ele for planejado e como será
aplicado. Com a finalidade de tornar esse processo “agradável”
alguns aspectos podem ser verificados (GOLDEN, 2004).
1 - Planejamento
Realizar o levantamento das regras de negócio.
Confeccionar o desenho mínimo dos processos afetados
pela implantação, de forma que seja capaz de estimar o
quanto será aceito com uma pequena margem de erro.
Estudar o parque tecnológico. Identificar os recursos
disponíveis na organização na qual será implantado.
Pesquisar para obter as ferramentas adequadas para
a implantação (ex: escolha da plataforma operacional,
aplicativos para suportar os serviços necessários).
Conhecer a comunidade de desenvolvedores locais.
Ser capaz de recomendar a alocação de mão-de-obra apta
a realizar as personalizações necessárias para tornar o
software livre adequado às necessidades da organização.
A definição da equipe deve ser baseada nas necessidades
do projeto da organização. Veja a seguir algumas
responsabilidades que as pessoas envolvidas podem
assumir (BRITO et al., 2004):
Papel Responsabilidades
Levantar os requisitos com o cliente e garantir que o sistema seja
Analista de negócios implementado de acordo como foi especificado.
Definir a arquitetura do sistema de maneira adequada e acompanhar os
Arquiteto de software programadores nas suas atividades.
Implementar o que foi especificado pelo analista de negócios, de
Programador acordo com a arquitetura definida
Gerenciar e acompanhar todas as fases do projeto e negociar prazos e
Gerente de projeto entregas com o cliente.
Gerente de configuração Confi gurar o ambiente de desenvolvimento do projeto, por meio da

nomenclatura e localização dos artefatos gerados.
Assegurar que o processo está sendo seguido e criar meios para
Gerente de qualidade garantir a qualidade dos artefatos gerados.
Unidade 3 67

O número de profissionais por função vai de

acordo com o escopo do projeto. Normalmente,
com a exceção do programador, as demais funções
são ocupadas por um profissional somente. Para
saber mais sobre composições de equipe, utilize a
ferramenta de busca Google e digite “projeto de
software livre”.
Segundo Christoph (2004), para o levantamento de requisitos

em um projeto de software livre existem três grandes fontes:
a) os próprios autores do projeto se encarregam de elaborar

os requisitos – essa prática não é muito comum em sistemas
comerciais (é normal ter uma pessoa ou equipe, que não faz
parte do grupo de desenvolvedores, como responsável pelo
levantamento dos requisitos). Em um projeto de software livre,
o autor normalmente levanta os requisitos e consegue fazer um
projeto de software. Entretanto, sempre existirá o problema dos
requisitos levantados por uma pessoa ou um grupo pequeno de
pessoas nem sempre estar de acordo com as necessidades de toda
comunidade do projeto;
b) a comunidade de usuários do projeto – quanto maior for a

base de usuários, maior será o retorno obtido. Esse retorno vem
das experiências dos usuários com o projeto, e pode vir na forma
de comunicação de erros, sugestão de melhorias e dúvidas. Com
isso é possível complementar os requisitos iniciais do sistema de
forma que reflita em um código mais robusto que o original;
c) padrões – essa forma de se levantar requisitos é, em muitos

casos, ignorada por projetos comerciais, que preferem criar
padrões próprios que possam ser patenteados, a usar um já
existente no mercado. Um exemplo seria a tecnologia JDO (Java
Data objects). JDO é uma especificação feita com ajuda do Java
Community Process que serve para transformar modelos de
domínio Java em dados persistentes. Apesar de existirem alguns
São dados que podem ser poucos projetos comerciais que implementam essa tecnologia,
recuperados em caso de falhas na ela ainda é ignorada por muitos outros que preferem fazer uso de
transação, no sistema ou no meio.
uma especificação própria para esse fim.
68

2 - Suporte técnico
O suporte técnico é uma questão primordial
para uma boa implementação do software
livre. Ele é formado por equipes de
desenvolvedores e voluntários, às vezes
com nenhuma estrutura organizacional.
O software livre é na sua maioria livre e
disponível, mas apesar de ser uma grande
vantagem, nem sempre é claro a quem
recorrer quando tiver algum problema.
O termo suporte técnico abrange dois tipos

diferentes de serviços. O primeiro tipo
corresponde às questões referentes ao uso do
produto. O segundo tipo referente aos problemas de falhas.
Empresas que desenvolvem software livre devem estar atentas a
esses dois tipos de suporte, pois são fundamentais para os seus
usuários.
O fato de ter o conhecimento do código-fonte

significa que a organização é responsável pelo
suporte?
Essa questão é simples de ser respondida. O conhecimento do

código-fonte possibilita a detecção do erro, o que não significa
que o cliente irá resolver o problema. Embora o fato de saber
detectar o problema facilite e agilize a sua solução, no software
proprietário isso não é possível. Por exemplo, as mensagens
de erro na sua maioria não informam realmente o que está
acontecendo.
Definindo as necessidades de suporte técnico

Existem basicamente três opções para suporte técnico disponíveis
para os usuários de software livre: comunidade, pago e próprio.
Para determinar qual é a melhor escolha, é importante para a
empresa saber como ela escolhe o produto. Cada uma das opções
de suporte técnico possui as suas fraquezas e os seus valores.
Unidade 3 69

Comunidade de suporte: no software livre existem

vários tipos de comunidade que provêem suporte aos seus
usuários. Listas de discussão por e-mail são populares
para a discussão de problemas e busca de soluções.
A escolha da lista pode ser realizada com base em
estatísticas. Cada lista normalmente traz quantos
membros fazem parte, número de postagens, entre outros
itens.
Pago: esse tipo de suporte é semelhante ao realizado nos
softwares proprietários. O suporte pode ser obtido por
e-mails, atendimento telefônicos, entre outros. O acesso
a esse tipo de suporte está limitado a um conjunto de
pessoas responsáveis em realizar a tarefa, interpretar as
soluções e implementá-las.
Próprio: esse tipo de suporte está ligado à capacidade
da equipe que manipula o software livre dentro das
empresas.
Para determinar as necessidades de suporte para a empresa,
é necessário conhecer a capacidade da equipe e o grau de
experiência. Alguns direcionamentos são vistos nesse processo.
Avaliar o quanto a empresa é familiarizada com o

produto ou seu similar. Se o produto é novo para a
organização, será necessária uma quantidade maior de
mecanismos de suporte, mas se existe uma cultura com
produto similar, essa necessidade de suporte é menor.
Avaliar como o produto será utilizado. O produto que
é usado com propósitos de produção, necessita que o
suporte esteja disponível de forma rápida. é preciso saber
que o tipo de suporte utilizado vai ao encontro com a
forma que o produto será utilizado. O tipo de suporte
a ser utilizado pode mudar conforme a evolução do
produto dentro da empresa. Enquanto o produto está
dentro de um plano piloto, o suporte vai de acordo com
a sua evolução até se tornar um produto, onde então o
suporte passa a ser direto com o seu usuário.
70

Avaliar os níveis de habilidade e atributos dos

indivíduos que usam o produto. Os níveis de habilidade
variam bastante. O nível de suporte será de acordo com
a capacidade de cada usuário, como também o nível de
responsabilidade de cada um dentro da empresa.
Necessidades de documentação. Baseadas em uma
avaliação de desempenho, as necessidades de suporte
devem ser documentadas para comparação com os
recursos identificados na próxima fase do processo.
Documentar os resultados da sua avaliação possibilita à
organização examinar explicitamente as suas suposições e
práticas, evitando problemas de suporte necessários e não
disponíveis.
Documentação
A documentação é um recurso importante quando trabalha-se
com software. A complexidade do software necessita de uma
documentação detalhada e que forneça dados para ajuda estejam
disponíveis. A falta de uma boa documentação para um produto
do software livre pode parar o projeto ou a sua implantação de
forma adequada aos requisitos da organização.
A qualidade da documentação está ligada ao grau de maturidade

do produto. Quanto maior o estágio de maturidade, maiores são
as condições de escrever uma documentação.
Por que precisamos de documentação?
Veja a seguir o que leva uma organização a contar com alguns

tipos de documentação.
Definindo as necessidades da documentação

O tipo de documentação em uma organização depende de como
o produto é utilizado e do grau de experiência dos seus usuários
e equipe de suporte. Se a organização está iniciando uma
cultura no produto, os documentos do tipo tutorial e manual de
referência são fundamentais.
Unidade 3 71

De outra forma, se as funcionalidades avançadas do produto

estão sendo utilizadas, ou se são necessários altos níveis de
desempenho, uma documentação com todas as funcionalidades
avançadas torna-se necessária.
Existem três origens da documentação do software

livre: equipe de desenvolvimento, comunidade de
usuários e fornecedores comerciais.
Cada uma possui os seus aspectos positivos e negativos, e

ocorrem em diferentes estágios do ciclo de vida do software livre.
Cada origem pode liberar uma documentação de alta qualidade,
enquanto que no software comercial isso não acontece.
Se a origem da documentação for a equipe de desenvolvimento,

a documentação de referência básica está disponível no momento
que o software é liberado. Normalmente, desenvolvedores
experientes e/ou administradores capazes de utilizar o produto
fazem uso desse tipo de documentação, não sendo recomendada
a usuários comuns. Esse tipo de documento é, de forma geral,
bem detalhado, mas a sua qualidade pode variar bastante de
acordo com os desenvolvedores. Com múltiplos autores e nenhum
revisor para garantir a consistência e completude, pode-se achar
inconsistência na documentação, dependendo de qual membro da
equipe preparou o documento.
Na fase de maturidade da documentação, normalmente existem

três tipos de documentos: referência, tutorial e uso.
O documento de referência trata todos os aspectos básicos de

desenvolvimento e funcionalidade do software. A qualidade do
documento pode ser garantida durante e/ou após a conclusão
da fase do programa piloto, isto é, existe a necessidade que o
documento de referência seja totalmente explorado durante esta
fase.
Os diversos cenários já desenvolvidos devem estar em

conformidade com as funcionalidades existentes no documento
de referência. Cenários não previstos devem ser desenvolvidos
durante a fase de implantação do plano piloto e constituem um
bom teste para a qualidade do documento de referência.
72

O tutorial deve preparar o usuário para utilizar o

produto. Os tutoriais não criam usuários experientes,
mas os ensinam a fazerem uso do produto. Eles têm
como objetivo encurtar o tempo de aprendizado
do usuário. Logo, a melhor forma de se avaliar a
qualidade de um tutorial é distribuí-lo a um ou
mais usuários e verificar se os mesmos conseguem
executar todas as tarefas oferecidas pelo produto.
O documento de uso, pela sua natureza, visa as

funcionalidades avançadas e específicas do produto
e os usuários avançados. Por essa razão torna-se
complicado avaliar esse tipo de documentação durante o projeto
piloto. A melhor época para realizar tal avaliação é durante a fase
de produção do produto, na qual os diversos cenários já foram
implementados e os usuários já fizeram uso do produto.
Para refletir: além dos tipos de documentação, é

importante ter a clareza das necessidades. Por que
precisamos das documentações?
Treinamento
Durante a implantação do produto, a questão de treinamento
é fundamental para o sucesso do projeto. Existem algumas
opções de treinamento disponíveis para produtos de software
livre. A comunidade de usuários pode ser bastante generosa
compartilhando as informações do produto com novos usuários
e os desenvolvedores de produto podem criar tutoriais e torná-
los disponíveis via ambiente web, por exemplo. Existem outras
opções de treinamento:
treinamento em salas de aula organizadas por entidades

comerciais;
treinamento em salas de aula organizadas por equipes de
desenvolvimento;
tutoriais publicados comercialmente; e
tutorias on-line criados por desenvolvedores.
Unidade 3 73

Portanto, a natureza descentralizada do software livre significa

que a equipe de desenvolvimento possui pouco controle sobre o
material de treinamento.
Definindo as necessidades de treinamento

O grau de experiência dos empregados da organização define
a necessidade de treinamento. Existem outros aspectos que
podem ser observados. Um deles é o escopo de abrangência
do uso do produto. Caso o produto seja amplamente utilizado,
existe a necessidade de uma estratégia ampla de treinamento.
Outro aspecto, o tempo, também é um fator decisivo para
o treinamento. Existem situações nas quais a implantação é
realizada de forma rápida, com a necessidade de que os usuários
estejam qualificados para utilizarem o produto em curto espaço
Conforme você viu na unidade de tempo.
anterior, o modelo de maturidade
consiste no modelo obtido quando Como citado, existem várias formas de realizar o treinamento
se alcança as versões finais do de um produto de software livre. A tabela a seguir mostra uma
software.
verificação da realização de treinamento.
Modelo de maturidade de software livre
Lista de verificação de controle de treinamento
Nome do produto: Lotavio
Método Observações
Minitutoriais no ambiente web
Realizada a pesquisa de três diferentes aspectos do produto: Foi achado um número significante de minitutoriais sobre o
descritores de desenvolvimento, containers de gerenciamento assunto.
e serviço de mensagens.
Tutoriais criados pelos desenvolvedores
Revisada a documentação. A documentação cobre todas as áreas relevantes do produto.
Tutoriais comerciais
Pesquisa em sites como Amazon.com. Não existem versões comerciais.
Salas de aula organizadas pela equipe de desenvolvimento
Contatado três clientes para se obter referências. Obtido um feedback positivo.
74

Integração
Outro quesito importante na implantação de software livre é
a integração do produto com os demais produtos existentes. A
integração de produtos de software livre é sempre um grande
desafio devido a diversidade de características existentes.
A pilha de software (stack software) é um termo que

descreve o modelo conceitual que algumas pessoas
utilizam para a sua infra-estrutura de software. Ele
retrata uma coleção em camadas de software, na
qual cada uma representa um ou mais pedaços de
software.
Cada pedaço na pilha consome serviços do software abaixo e

libera serviços para o software de cima. Isso significa que todo
o software tem que trabalhar de forma cooperativa com outro.
Esse trabalho em conjunto é chamado de integração, refletindo a
infra-estrutura de software moderno das empresas. Veja a seguir
uma ilustração da pilha de software.
Figura 4 - Pilha de software
Unidade 3 75

A motivação inicial do uso de software livre é substituir as

aplicações existentes na pilha de software, reduzindo o custo da
infra-estrutura e liberando capital para outros investimentos.
Normalmente as organizações de TI executam vários softwares

simultaneamente, cada um provendo um ou mais serviços. Essa é
uma questão extremamente complexa. A escolha de um produto
para ser implementado em uma infra-estrutura de software
não envolve somente as suas funcionalidades, mas também tem
que ser levado em consideração se ele pode ser integrado com
os componentes da infra-estrutura existente. Os desafios da
integração de software têm aumentado conforme a complexidade
e grandeza das infra-estruturas existentes.
Desafios da integração
Mesmo com um bom planejamento, ainda existem alguns
problemas com o processo de integração:
a documentação do sistema pode estar desatualizada.

Novos módulos do software podem ter sido incluídos e
não documentados. Logo, no calor da batalha algumas
questões não serão possíveis de serem resolvidas porque a
documentação não está atualizada;
o pessoal-chave pode não estar familiarizado com o
produto. Isso pode causar grandes problemas durante a
integração; e
integrações de software podem ter sido realizadas sem a
ciência da organização. Consultores podem ter instalado
software adicional sem avisar ao pessoal de TI.
Cada uma dessas razões pode fazer com que o planejamento

do processo de integração venha a falhar. Portanto, durante o
planejamento verifique os aspectos acima citados.
A integração entre software livre e proprietário é talvez a questão

mais complexa, porque o software proprietário não está motivado
a realizar essa integração.
76

Imagine que uma organização de TI deseje implementar

OpenLDAP na sua pilha de software, como um mecanismo de
acesso a sua estrutura de diretórios (autenticação/autorização).
Para a organização implementar o produto com sucesso, ela
deve ser capaz de integrar todos os produtos que consomem
esses serviços de segurança com OpenLDAP. Se alguma das
aplicações existentes não tem como integrar com o OpenLDAP,
passa-se a ter um problema.
A figura que se segue mostra a inserção do produto na pilha de

software e a integração deste com os demais componentes da
pilha.
Figura 5 - Integração de software livre
Projeto de integração
Todo produto que precisa compartilhar dados com outro
necessita de uma análise da sua estrutura de dados, oferecer
algumas APIs e então o plano de ataque para criar um método
para recuperar os dados do produto.
Esse é um lado do programa de integração. Naturalmente, existe

o outro lado que requer um planejamento similar. Ainda existe a
necessidade de se criar um terceiro plano para identificar como o
dado pode ser transportado e quais as necessidades para realizar a
integração do produto.
Unidade 3 77

Com a finalidade de resolver esses problemas, o projeto de

integração de um produto é semelhante a:
I. identificar o dado necessário do produto 1.

Desenvolver uma estratégia para recuperar o dado, uma
API de um produto específico ou via banco de dados
nativo. Recuperar os dados do banco de dados nativo é
perigoso porque pode não se ter garantia de integridade,
mas em algumas situações essa é a única solução. Criar
uma interface para o produto para recuperar o dado
necessário à integração;
II - repetir a fase 1 para o produto 2;
III - escrever a especificação de transporte do produto

1 para o 2 usando um dos produtos de integração
oferecendo interfaces públicas ou não; e
IV - “reze” para nenhum dos produtos mudar. Caso isso

aconteça, repita as fases de 1 a 3.
A tabela a seguir mostra um exemplo de verificação da realização

de integração.
78

Modelo de maturidade de software livre

Lista de verificação de integração
Nome do produto: Lotavio
Método Observações
Integrações identificadas
Duas integrações documentadas:

Revisada toda a documentação do sistema. - JMS usado para troca de dados com o sistema existente;
- EJB chama o banco de dados comercial.
Entrevista com o pessoal de desenvolvimento e

operacional do produto para cobrir alguma integração não Uso adicional do JMS para empurrar os dados para o portal.
documentada.
Entrevista com membros do produto para determinar Nada identificado além das duas listadas na documentação
necessidades para integração. do sistema.
Integrações necessárias disponíveis via desenvolvimento próprio
Identificar as integrações que faltam. Nada falta.
Avaliar possíveis mecanismos de integração que podem ser Aplicações e-commerce oferecem interfaces de serviços web
que podem ser usados para substituir chamadas de banco de
utilizados para criar integrações necessárias. dados. Será explorado como poderá ser viável.
Integrações necessárias desenvolvidas pelos vendedores comerciais
O portal comercial oferece interfaces de serviço web. Poderá

Identificar as integrações que faltam. ser realizado o acesso às funcionalidades e desempenho
durante a fase de teste.
Determinar as integrações comerciais que estão Nenhum problema.

disponíveis.
Integrações necessárias que não estão disponíveis
Identificar alguma integração que não pode ser criada via Nenhum problema.
os quatro mecanismos citados anteriormente.
Para todo problema de integração decidir se o projeto Não aplicável para esta situação.
pode ir adiante sem integração.
Unidade 3 79

SEÇÃO 3 – Riscos de implantação de software livre
Desafios
Software Livre Módulo 1 - Next
Generation Center O software livre pode causar sérios transtornos nas empresas
extremamente dependentes de softwares proprietários em seus
modelos de negócio. Um novo cenário de negócios causado por
uma nova tecnologia atua diretamente na faixa de mercado da
corporação. Além disso, torna o seu crescimento mais árduo
gerando, por parte dessa empresa, reações bastante agressivas
para evitar eventual percepção negativa dos investidores.
Entretanto, os impactos do novo contexto afetam de maneira
diferente as corporações do setor.
O primeiro grande desafio para a implantação de um projeto de

software livre em uma empresa está na questão das mudanças
das regras de negócio. Essas mudanças vão desde a análise das
novas perspectivas de mercado que estão sendo criadas com a
nova tecnologia até em como saber redirecionar o investimento
para outras áreas de negócio, conforme as novas regras.
Fator cultural
Em todas as esferas, seja pública ou privada, uma das maiores
barreiras para a implantação do software livre ainda é o
aspecto cultural. O desconhecimento dos aplicativos existentes
em software livre e as suas potencialidades, além do hábito
de utilizar os programas já conhecidos, podem levar a uma
resistência à mudança. Portanto, não bastam investimentos nas
tecnologias, é preciso uma capacitação para essa mudança.
Existe a necessidade de uma grande “propaganda” maciça do

projeto de software livre na empresa, mostrando como será
implantado, os benefícios que serão obtidos, os programas de
treinamento que serão criados para dar cultura aos seus usuários,
entre outros aspectos.
80

Mão-de-obra
A questão da mão-de-obra é um dos fatores, às

vezes, limitador para se implantar um projeto
de software livre em uma empresa.
Distribuições
Software Livre Módulo 1
Um grande desafio da implantação de projetos de software livre é - Next Generation Center
a tendência das empresas de distribuição do Linux, por exemplo,
adicionarem software não-livre ao GNU/Linux, em nome da
conveniência e do poder. Alguns desenvolvedores de distribuição
fazem isso, oferecendo um CD completamente livre e os demais
somente comprando-os.
As pessoas justificam a adição de software não-livre com

o argumento da “popularidade do Linux”, valorizando a
popularidade acima da liberdade. Por vezes isso é admitido
abertamente. O futuro do software livre está ligado à ganância
das pessoas. Empresas vislumbram no futuro que a tendência é
transformar a questão do software livre em software “comercial”,
visando o lucro.
Alguns cuidados durante a implantação

Os sistemas operacionais possuem scripts ou programas que têm
por objetivo instalar os sistemas tão rapidamente quanto possível,
com a máxima funcionalidade e com o mínimo de esforço por
parte do administrador.
Para atingir esse objetivo, os programas normalmente instalam

mais componentes do que a maioria dos usuários necessita. O
fabricante tem como filosofia que é melhor habilitar funções que
não são necessárias do que o usuário ter que instalar funções
adicionais na medida em que for preciso.
Unidade 3 81

Essa visão, embora seja conveniente para o usuário,

origina a existência de muitas das mais críticas
vulnerabilidades de segurança, pois os usuários não
mantêm, nem corrigem componentes de software
não usados.
Além disso, muitos usuários desconhecem o que realmente

é instalado, deixando programas perigosos no sistema,
simplesmente porque eles não sabem que estão lá. Esses serviços
vulneráveis fornecem meios para os atacantes invadirem
seus sistemas. Nos sistemas operacionais, as instalações
default comumente incluem serviços adicionais, abrindo
conseqüentemente as portas associadas a eles. É justamente por
estas portas que os atacantes costumam invadir. Quanto menos
portas abertas, menor a probabilidade do sistema ser invadido
(RUSSELL, GANGEMI, Site Security Handbook, Norma BS
7799).
Determine se está vulnerável

Após a instalação de qualquer produto, averigúe se o mesmo está
de acordo com as normas de segurança. No caso de sistemas
operacionais, verifique se utilizou um programa para instalar um
sistema ou serviço. Verifique também se não foram removidos os
serviços desnecessários. Se não foram instalados todos os patches
de atualização do sistema, então esse é passível de ataques.
Mesmo que se tenha seguido os procedimentos adicionais de

configuração, o produto ainda estará vulnerável. É preciso
que seja executada uma ferramenta de scan de portas e de
vulnerabilidades contra qualquer sistema que irá ser conectado na
internet.
Ao analisar os resultados, tenha em mente o princípio de que

os sistemas devem funcionar com o menor número de serviços
e de pacotes de software necessários para executar as tarefas
requeridas pelo sistema computacional. Qualquer serviço
adicional constitui-se em uma ferramenta para o atacante,
especialmente porque a maioria dos administradores de rede não
corrige os serviços que efetivamente não estão sendo usados.
82

Inicialmente, desabilite serviços desnecessários e feche portas

não usadas. Devido ao fato que essa pode ser uma tarefa longa e
árdua, muitas das grandes organizações desenvolveram, para cada
sistema operacional e conjunto de aplicativos usados, diretrizes de
instalação padronizadas.
Essas diretrizes incluem a instalação das funcionalidades

mínimas necessárias para que o sistema funcione de maneira
eficaz. O CIS – Center for
Internet Security
O uso de ferramentas para testar o nível de segurança e comparar desenvolveu um
a segurança de sistemas entre as várias divisões de uma empresa benchmark para avaliar
a configuração mínima de
melhora o nível de segurança dos serviços oferecidos pela
segurança em sistemas
empresa. Solaris.
Backups
Quando um incidente ocorrer (e ocorrerá em quase todas
as organizações), a recuperação do incidente requer backups
atualizados e métodos de recuperação dos dados previamente
testados.
Algumas organizações fazem backups diários, mas nunca

verificam se eles estão realmente funcionando. Outras criam
políticas e procedimentos de backup, mas não de restauração.
Freqüentemente, tais erros são descobertos somente depois
que um hacker invade os sistemas e os dados são destruídos, ou
arruinados de alguma outra maneira.
Toda a empresa, conforme a sua política de segurança,

calcada na BS7799 (12), deve possuir uma política de
backup que seja compatível com o seu negócio.
Para isso, um inventário deve ser feito identificando todos os

serviços críticos e, para cada um deles, deve ser executada uma
análise identificando o risco e a ameaça correspondente. As
políticas e os procedimentos de backup devem remeter claramente
a esses sistemas.
Uma vez identificados os serviços críticos, deve ser validado o

seguinte:
Unidade 3 83

I. Existem procedimentos de backup para tais serviços?
II. O intervalo dos backups é adequado?
III. Os backups estão sendo realizados de acordo com os

procedimentos?
IV. É verificada a mídia usada nos backup para certificar-

se que os dados estão sendo armazenados corretamente?
V. A mídia de backup está corretamente protegida, seja

ela mantida dentro ou fora da empresa?
VI. Existem cópias do sistema operacional e de

aplicativos de restauração que sejam armazenadas fora da
empresa?
VII. Os procedimentos de restauração foram validados e

testados?
Projeto de implantação do software livre no Governo

brasileiro
Planejamento Estratégico para O Governo brasileiro possui algumas diretrizes para a
Implementação de Software Livre implantação do software livre no país. Essas diretrizes servem
– <www.softwarelivre.gov.br>.
não somente como direcionamento para o projeto de software
livre, mas também como uma referência para os demais governos
estaduais, empresas, etc. Seguem algumas dessas diretivas:
priorizar soluções, programas e serviços baseados em

software livre que promovam a otimização de recursos e
investimentos em tecnologia da informação;
priorizar a plataforma web no desenvolvimento de
sistemas e interfaces de usuários;
adotar padrões abertos no desenvolvimento de tecnologia
da informação e comunicação e o desenvolvimento
multiplataforma de serviços e aplicativos;
popularizar o uso do software livre;
ampliar a malha de serviços prestados ao cidadão por
meio de software livre;
84

garantir ao cidadão o direito de acesso aos serviços

públicos sem obrigá-lo a usar plataformas específicas;
utilizar o software livre como base dos programas de
inclusão digital;
garantir a auditabilidade plena e a segurança dos
sistemas, respeitando a legislação de sigilo e segurança;
buscar a interoperabilidade com os sistemas legados;
restringir o crescimento do legado baseado em tecnologia
proprietária;
realizar a migração gradativa dos sistemas proprietários;
priorizar a aquisição de hardware compatível às
plataformas livres;
garantir a livre distribuição dos sistemas em software
livre de forma colaborativa e voluntária;
fortalecer e compartilhar as ações existentes de software
livre dentro e fora do Governo;
incentivar e fomentar o mercado nacional a adotar novos
modelos de negócios em tecnologia da informação e
comunicação baseados em software livre;
promover as condições para a mudança da cultura
organizacional para adoção do software livre;
promover capacitação/formação de servidores públicos
para utilização de software livre;
formular uma política nacional para o software livre.
As diretivas de software do Governo Federal os aspectos

principais para a implantação do software livre: planejamento,
Planejamento Estratégico
suporte técnico, documentação, treinamento e integração. Cada para Implementação de
uma das diretivas se encaixa em um desses aspectos, tornando o Software Livre – <www.
processo de implantação uma tarefa mais fácil do que ela aparenta softwarelivre.gov.br>.
ser. Essas diretivas são fundamentais para o Governo, porque
existem objetivos que devem ser alcançados. Alguns desses
objetivos podem ser vistos a seguir:
Unidade 3 85

I. Aumentar a capacitação dos técnicos e servidores

públicos para a utilização de software livre.
II. Motivar os servidores públicos a aderirem ao software

livre.
III. Desenvolver um ambiente de colaboração para

permitir a expansão do software livre.
IV. Definir e implantar padrões de interoperabilidade.
V. Efetivar o software livre como ferramenta corporativa

padrão do Governo Federal.
VI. Disseminar a cultura de software livre nas escolas e

universidades.
VII. Elaborar e por em vigência a regulamentação

técnico-legal do software livre.
VIII. Promover migração e adaptação do máximo de

aplicativos e serviços para plataforma aberta e software
livre.
IX. Elaborar e iniciar implantação de política nacional de

software livre.
X. Articular a política de software livre a uma política

de fomento à indústria – quantidade e relevância dos
projetos apoiados.
XI. Ampliar significativamente a oferta de serviços aos

cidadãos em plataforma aberta.
XII. Envolver a alta hierarquia do Governo na adoção do

software livre – avaliação.
86

Síntese
A unidade apresentou algumas responsabilidades e riscos de se

implantar software livre dentro de uma organização. Toda essa
questão baseia-se na implantação de uma nova cultura, inclusive
ocasionando possíveis alterações das regras de negócio. São novos
desafios, e várias barreiras para implantação irão aparecer durante
todo o processo. Tenham em mente que não será uma tarefa
simples, mas poderá ser simplificada com um bom planejamento
e uma equipe qualificada.
Portanto, espera-se que você tenha conseguido entender essa idéia

e que o conhecimento dos conceitos apresentados nesta unidade o
ajude num futuro próximo.
1) Cite quais os principais aspectos que devem ser verificados para a

implantação de software livre em uma organização.
2) Quais problemas podem acontecer em um processo de integração de

software livre com a pilha de software de uma organização?
Unidade 3 87

3) No decorrer do texto alguns cuidados durante a implantação do

software livre foram citados, entre eles a política de backup. Como é
possível validar uma política de backup adotada por uma organização?
Existem procedimentos de backup para tais serviços?
O intervalo dos backups é adequado?
Os backups estão sendo realizados de acordo com os procedimentos?
É verificada a mídia usada nos backup para certificar-se que os dados

estão sendo armazenados corretamente?
A mídia de backup está corretamente protegida, seja ela mantida dentro

ou fora da empresa?
88

Existem cópias do sistema operacional e de aplicativos de restauração

que sejam armazenadas fora da empresa?
Os procedimentos de restauração foram validados e testados?
Saiba mais
Saiba mais sobre o projeto de implantação de software livre no

Governo Brasileiro em: <www.softwarelivre.gov.br>.
Para analisar outros projetos de implantação do software livre,

basta pesquisar com a frase “implantação de software livre” no
site <www.google.com.br>.
Unidade 3 89

Para concluir o estudo
Ao término dessa disciplina pode-se formar uma

base de conhecimento por meio da apresentação de
conceitos e alguns aspectos básicos e necessários para o
estabelecimento das responsabilidades e risco quanto ao
uso, desenvolvimento e implantação do software livre.
Todo o conteúdo apresentado na disciplina não esgota

o assunto, a busca sem fim pelo conhecimento se faz
necessária. Além das referências apresentadas, a internet
é uma fonte inesgotável do assunto.
As práticas de utilização, desenvolvimento e implantação

de software proprietário estão bem definidas, mas
quanto ao software livre elas ainda são primárias. Várias
questões carecem de estudos mais amplos, amadurecendo
as práticas existentes e desenvolvendo novas práticas.
Na continuidade do curso, vocês terão condições em

sedimentar os conhecimentos aqui adquiridos. A sua
capacitação intelectual nessa modalidade de software é
fundamental para futuros projetos a serem implantados
por você.
Que bons ventos os leve a portos seguros nesta nova rota

de desenvolvimento de tecnologia voltada a um mercado
livre e saudável.
Boa sorte,
Prof. Msc. Luiz Otávio B. Lento

Referências
AUGUSTO, M. P. Um estudo sobre as motivações e orientações

de usuários e programadores brasileiros de software livre.
Dissertação de Mestrado - Universidade Federal do Rio de Janeiro,
2003.
BARAHONA, J. G.; PACUAL, J. S.; ROBLES, G. Introducción al

software libre. Fundació per a la Universitat Oberta de Catalunya,
2003.
BRANCO, M. D. Software livre na administração pública

brasileira. 2004.
BRITO, R. et al. Uma experiência na implantação de processo

em uma fábrica de software livre. Universidade Federal de
Pernambuco, 2004.
CHRISTOPH, R. de H. Engenharia de software para software

livre. 2004.
FELLER, J., FITZGERALD, B. Understanding open source software

development. Ed. Addison-Wesley, 2002.
FERREIRA, R. E. Linux guia do administrador do sistema. Ed.

Novatec, 2003.
GARDINI, A. Segurança é maior em sistemas livres. Disponível

em: <http://www.comciencia.br/200406/reportagens/04.shtml>.
GOLDEN, B. Succeeding with open source. Ed. Addison Wesley,

2004.
Guia Livre – Referência de migração para software livre do Governo

Federal - www.governoeletronico.gov.br/governoeletronico/
publicação/
Implantação de Software. Disponível em: <www.

allianceconsultoria.com.br/content.asp>.
JOMORI, S. M.; VOLPE, R. L. D.; ZABEU, A. C. P. Qualidade de

software. Revista Banas Qualidade, Ano XIII, fevereiro de 2004,
n.141.

LENTO, L. O.. B. Estudo sobre segurança da informação. 2004.
MAFFEO, B. Engenharia de software e especificação de sistemas Ed.

Campus, 1992.
Nex Generation Center. Software Livre Módulo 3: Regulamentação. 2005.
Nex Generation Center. Software Livre Módulo 1: Conceito. 2005.
Norma BS 7799. Normatização de prática para gerenciamento da segurança

da informação.
Planejamento estratégico para implementação de software livre. Disponível

em: <www.softwarelivre.gov.br>.
Qualificação CMM no Brasil - Tecnologia da Informação - www.mct.gov.br/

Temas/info/Dsi/qualidad/CMM.htm
REIS, C. R.; FORTES, R. P. de M. Caracterização de um processo de software

para projetos de software livre. Dissertação de Mestrado - Universidade
de São Carlos, 2003.
RUSSELL, D.; GANGEMI, G. T. Computer security basics. Ed: O Reilly.
RFC 2196. Site Security Handbook.
SILVEIRA, S. Amadeu. Inclusão digital, software livre e globalização

contra-hegemônica. Disponível em: <www.softwarelivre.gov.br/artigos>.
SINGH, R. International standard ISO/IEC 12207 - software life cycle

processes -, Federal Aviation Administration Washington, DC, USA.
Software Livre Módulo 1: Next Generation Center, 2005.
Software Livre Módulo 5: Aplicações - Next Generation Center, 2005.
WEINBERG, B. SCO e o futuro: litígios em software livre e proprietário.

MontaVista Software, Inc. Disponível em: <www.magnet.com.br/bits/
mercado/2003/10/0017>.
Where Do Open Source Requirements Come From (And What Should We Do

About It)? In: Proc. 2nd Workshop On Open-Source Software Engineering,
Orlando. Bart Massey, 2002.
94

Sobre o professor conteudista
Luiz Otávio Botelho Lento é oficial da Marinha

da reserva; mestre em Ciência da Computação pela
UNICAMP (Sistemas Distribuídos); doutorando na
UFSC na Engenharia Elétrica, no Departamento de
Automação de Sistemas, com concentração na área
de segurança, atuou no Governo na área de gerência
de redes, segurança da informação e software livre;
consultor de treinamento da Aker Security Solutions;
consultor na área de redes e segurança da Empresa
Immerson; gerente de rede e de segurança da Rede
Acadêmica do UNICEUB; professor de disciplinas nas
áreas de rede de computadores, segurança da informação
e programação na Graduação do UNICEUB, bem como
orientações de projetos finais. Foi professor de graduação
e pós-graduação na área de redes de computadores,
segurança, programação e modelagem na Universidade
Católica de Brasília (UCB), bem como orientações de
projetos finais; coordenador de cursos de pós-graduação
na UCB. Atualmente é professor de graduação e pós-
graduação da Unisul na área de redes, segurança da
informação e software livre; consultor na área de redes,
projetos de sistemas distribuídos e segurança da empresa
TruelT Tecnologia da Informação.

Respostas e comentários das
atividades de auto-avaliação
Unidade 1
1) Qual ou quais os aspectos relevantes quanto à
responsabilidade do software livre na inclusão da
população no mundo digital?
Resposta: A responsabilidade do software livre na inclusão
digital é primordial.
Possibilidade de se ter acesso a informações de forma
eficiente e eficaz a um custo adequado à realidade da maioria
da população.
A utilização cada vez maior do uso do software livre

habilitando os usuários a serem novos desenvolvedores.
Compartilhamento do conhecimento, usando como meio a

internet, na busca de soluções que atendam as necessidades
da população brasileira e mundial.
A integração socioeconômica democratizando o

conhecimento tecnológico entre todos.
2) Quais parâmetros que seriam estabelecidos por você para

minimizar os riscos de uma descontinuidade de solução
de software utilizada pela a sua empresa?
Resposta: Basicamente, duas questões são primordiais para
minimizar os riscos:
analisar quanto tempo a empresa desenvolvedora está no
mercado; e
analisar qual a periodicidade de atualização da distribuição
escolhida, possibilitando que novos recursos sejam incluídos.

Unidade 2
1) Explique o processo de desenvolvimento e manutenção do
software livre no lançamento de uma nova versão.
Resposta: Ao lançar uma versão ela estará disponível para download
para a comunidade utilizar, realizar as suas próprias análises e passar à
equipe de desenvolvimento os problemas encontrados durante o seu
uso, como também as sugestões para resolvê-los e/ou melhorar a sua
utilização. A equipe de desenvolvimento recebe essas informações,
e de posse das mesmas realiza uma filtragem e análise, realizando as
modificações necessárias. Após todas essas atividades, uma versão mais
estável é lançada. Essas atividades são repetidas até que uma versão
final estável seja alcançada.
2) Quais são as responsabilidades básicas que se deve ter no

desenvolvimento do software livre?
Resposta: Ter a preocupação de interoperar com os sistemas existentes
para que o software livre possa conviver com os demais softwares da
organização. Outras responsabilidades são de evoluir conforme as
necessidades de seus usuários, possuir um código consistente e estável
que execute todas as atividades ao qual foi projetado, garantir um
código com certo grau de segurança em relação às diversas ameaças
em que o software irá operar, prover interfaces de fácil operação para
os seus usuários e possibilitar um fácil acesso e gerenciamento das
atividades do software.
3) Quais as preocupações que se deve ter para minimizar o risco de

uma escolha precipitada de uma solução de software livre?
Resposta: Verificar a origem e a experiência da empresa desenvolvedora,
verificar se toda a equipe de desenvolvimento é empregada da
empresa, se não possui nenhum antecedente que o comprometa.
No caso de utilizar produtos prontos, verificar a origem do software,
fazer uma auditoria do código do software para verificar se não existe
algum problema, fazer laboratório de teste das funcionalidades e
vulnerabilidades. Verificar a portabilidade para as diversas plataformas
de hardware existentes e verificar a compatibilidade com os demais
softwares existentes. Por fim, não esqueça de verificar se o fornecedor
do software terá condições de fornecer patchs de atualização para os
diversos problemas que apareçam ou novas versões mais estáveis
98

Unidade 3
1) Cite quais os principais aspectos que devem ser verificados para a
implantação de software livre em uma organização.
Resposta: Planejamento, suporte técnico, documentação, treinamento e
integração.
2) Quais problemas podem acontecer em um processo de integração

de software livre com a pilha de software de uma organização?
Resposta:
A documentação do sistema pode estar desatualizada. Novos módulos
do software podem ter sido incluídos e não documentados. Logo, no
calor da batalha algumas questões não poderão ser resolvidas porque a
documentação não está atualizada.
O pessoal-chave pode não estar familiarizado com o produto. Isso pode
causar grandes problemas durante a integração.
Integrações de software podem ter sido realizadas sem o
conhecimento da organização. Consultores podem ter instalado
software adicional sem avisar ao pessoal de TI.
3) No decorrer do texto alguns cuidados durante a implantação

do software livre foram citados, entre eles a política de backup.
Como é possível validar uma política de backup adotada por uma
organização?
a) Existem procedimentos de backup para tais serviços?
Resposta: Estabelecer os procedimentos de backup para os serviços de
software livre.
b) O intervalo dos backups é adequado?

Resposta: Estabelecer um intervalo entre backups compatível com o grau
de sensibilidade das informações.
c) Os backups estão sendo realizados de acordo com os

procedimentos?
Resposta: verificar se os procedimentos de backup estão sendo
realizados em conformidade com a política de segurança da
organização.
99

d) É verificada a mídia usada nos backup para certificar-se que os

dados estão sendo armazenados corretamente?
Resposta: verificar a mídia usada no backup para certificar-se que os
dados estão sendo armazenados corretamente.
e) A mídia de backup está corretamente protegida, seja ela mantida

dentro ou fora da empresa?
Resposta: garantir que a mídia esteja corretamente protegida dentro ou
fora da empresa.
f) Existem cópias do sistema operacional e de aplicativos de

restauração que sejam armazenadas fora da empresa?
Resposta: manter cópias do sistema operacional e de aplicativos de
restauração armazenadas fora da empresa.
g) Os procedimentos de restauração foram validados e testados?

Resposta: testar e validar os procedimentos de restauração das mídias
utilizadas no backup.
100

Responsabilidades e Riscos PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Responsabilidades e Riscos PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Universidade do Sul de Santa Catarina

responsabilidades_e_riscos.indb 1 7/2/2007 17:16:20

Este livro didático corresponde à disciplina Responsabilidades e

O material foi elaborado visando a uma aprendizagem autônoma,

Por falar em distância, isso não signiﬁca que você estará

Bom estudo e sucesso!

responsabilidades_e_riscos.indb 3 7/2/2007 17:16:56

2ª edição revista e atualizada

responsabilidades_e_riscos.indb 5 7/2/2007 17:16:57

1. Software gratuito. 2. Software gratuito – Processo decisório.

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

UNIDADE 1 – Responsabilidades e riscos no uso dos sofwares livres . . 17

Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

responsabilidades_e_riscos.indb 7 7/2/2007 17:16:57

Caro aluno, seja bem-vindo à disciplina

Esta disciplina o colocará a par das responsabilidades

O desenho do mundo atual se resume em um grande

Entre essas políticas públicas e práticas alternativas

Projetos realizados em equipes, utilizando a internet

responsabilidades_e_riscos.indb 9 7/2/2007 17:16:57

O custo é um dos maiores fatores que inﬂuenciam o

Portanto, a grande virtude do software livre é a independência

Como já visto, para que um software possa ser considerado livre,

 liberdade para utilizar o programa, com qualquer

responsabilidades_e_riscos.indb 10 7/2/2007 17:16:57

É um modelo que restringe as liberdades do usuário: Garante a todos os usuários:

São normalmente distribuídos gratuitamente, apesar de não

Fonte: Nex Generation Center – Software Livre Módulo 1, Conceito - 2005

Logo, sob um ponto de vista genérico, a principal diferença entre

Saiba mais sobre outras “vertentes” do software livre

Com os conceitos de software livre e software proprietário

responsabilidades_e_riscos.indb 11 7/2/2007 17:16:58

O plano de estudos visa a orientá-lo/a no

O processo de ensino e aprendizagem na UnisulVirtual

São elementos desse processo:

responsabilidades_e_riscos.indb 13 7/2/2007 17:16:58

Agenda de atividades/ cronograma

responsabilidades_e_riscos.indb 14 7/2/2007 17:16:58

Avaliação Final (caso necessário)

Demais atividades (registro pessoal)

responsabilidades_e_riscos.indb 15 7/2/2007 17:16:58

 Conceituar o que é responsabilidade em software livre.

 Apresentar algumas responsabilidades do software livre

 Conceituar e apresentar como um modelo de

 Conceituar o que é risco em software livre.

 Apresentar alguns dos diversos riscos que estão

Seção 1 Responsabilidades do software livre.

Seção 2 Riscos do software livre.

responsabilidades_e_riscos.indb 17 7/2/2007 17:16:58

Para início de conversa

SEÇÃO 1 – Responsabilidades do software livre

“Responsabilidade”, segundo o dicionário Houaiss

Como na deﬁnição acima, todo software, proprietário ou não,

No Brasil, o software livre possui algumas responsabilidades perante

responsabilidades_e_riscos.indb 18 7/2/2007 17:16:59

Apenas 8,6% da população brasileira está

O uso do software livre tem como responsabilidade

Pode-se deﬁnir software

responsabilidades_e_riscos.indb 19 7/2/2007 17:16:59

A responsabilidade do software livre é garantir aos

O software livre tem como responsabilidade, contribuir para

Comunidades de software livre espalham-se pelo

responsabilidades_e_riscos.indb 20 7/2/2007 17:16:59

liberdade para utilizar o programa, com qualquer

Conceituar o que é responsabilidade em software livre.

Apresentar algumas responsabilidades do software livre

Conceituar e apresentar como um modelo de

Conceituar o que é risco em software livre.

Apresentar alguns dos diversos riscos que estão

ser portável para a maioria das plataformas de hardware

suportar diversas linguagens de programação;

a manutenção e correção de bugs de programação e

Versões r.x.y nas quais x é um número ímpar. São

acesso à rede mundial de computadores;

Os softwares livres têm sua arquitetura para evitar que

O Windows hoje é um grande “ímã” de vírus. A