das boas pr ticas de colabora o para a governa a do...
TRANSCRIPT
Universidade de Brasília - UnB
Faculdade UnB Gama - FGA
Engenharia de Software
Das boas práticas de colaboração para aGovernaça do Software Público Brasileiro
Autor: Camila Ferreira Pereira SIlva
Orientador: Prof. Dr. Paulo Roberto Miranda Meirelles
Brasília, DF
2014
Camila Ferreira Pereira SIlva
Das boas práticas de colaboração para a Governaça do
Software Público Brasileiro
Monografia submetida ao curso de graduaçãoem Engenharia de Softwareda Universidadede Brasília, como requisito parcial para ob-tenção do Título de Bacharel em Engenhariade Software.
Universidade de Brasília - UnB
Faculdade UnB Gama - FGA
Orientador: Prof. Dr. Paulo Roberto Miranda Meirelles
Brasília, DF
2014
Camila Ferreira Pereira SIlvaDas boas práticas de colaboração para a Governaça do Software Público Bra-
sileiro/ Camila Ferreira Pereira SIlva. – Brasília, DF, 2014-38 p. : il. (algumas color.) ; 30 cm.
Orientador: Prof. Dr. Paulo Roberto Miranda Meirelles
Trabalho de Conclusão de Curso – Universidade de Brasília - UnBFaculdade UnB Gama - FGA , 2014.
1. Software livre. 2. Software público. I. Prof. Dr. Paulo Roberto Mi-randa Meirelles. II. Universidade de Brasília. III. Faculdade UnB Gama. IV.Das boas práticas de colaboração para a Governaça do Software Público Brasileiro
CDU 02:141:005.6
Camila Ferreira Pereira SIlva
Das boas práticas de colaboração para a Governaça doSoftware Público Brasileiro
Monografia submetida ao curso de graduaçãoem Engenharia de Softwareda Universidadede Brasília, como requisito parcial para ob-tenção do Título de Bacharel em Engenhariade Software.
Trabalho aprovado. Brasília, DF, 26 de novembro de 2014:
Prof. Dr. Paulo Roberto Miranda
Meirelles
Orientador
Titulação e Nome do Professor
Convidado 01
Convidado 1
Titulação e Nome do Professor
Convidado 02
Convidado 2
Brasília, DF2014
Resumo
Softwares livres e públicos já estão consolidados como um tipo de software confiável devido
ao nível de segurança proporcionado pelo seu uso, eliminação das mudanças impostas pelo
modelo proprietário, independência tecnológica, possibilidade de auditabilidade além da
gratuidade de suas licenças entre outras características. Neste trabalho procuramos en-
tender as dificuldades do governo em utilizar software livre/público abordando o efeito de
suas licenças e restrições de uso e como são tratado os direitos autorais desses softwares
no Brasil. O objetivo deste trabalho é adequar o modelo de desenvolvimento utilizado
pelo governo brasileiro para que possa ser utilizados softwares livre e públicos levando
em consideração suas boas práticas de desenvolvimento. Para tanto será realizada uma
pesquisa bibliográfica onde estudaremos os software livre e público bem como as licenças
utilizadas por esses softwares e a maneira com que são aplicadas. Passaremos também
pelo processos de desenvolvimento de software PSW-SISP e suas origens na teoria ge-
ral da administração buscando pontos de intersecção entre esse processo e o método de
desenvolvimento das comunidades de software livre e público.
Palavras-chaves: software livre. software público. governança.
Abstract
Free and public software are already established as a type of reliable software due to
the level of security provided by its use, eliminating changes imposed by the proprietary
model, technological independence, ability to auditability beyond their gratuity allowances
among other features. In this work we try to understand the government’s difficulties in
using software free/public addressing the effect of its licenses and restrictions on use and
how they are treated the copyright of these software in Brazil. The objective of this work
is to adapt the model of development used by Brazilian government so that free software
can be used and public taking into account their good development practices. To do
a literature study will be conducted where the software free and the public as well as
the licenses used by these softwares and the way with which they are applied. We will
also software development processes PSW-SISP and its origins in the theory of general
administration looking for points of intersection between this process and the method of
community development and open source public.
Key-words: free software. public software. governance.
Lista de ilustrações
Figura 1 – Processo de software para o SISP(PSW-SISP) . . . . . . . . . . . . . . 28
Figura 2 – Ciclo de desenvolvimento da pesquisa-ação . . . . . . . . . . . . . . . . 32
Lista de tabelas
Tabela 1 – Características das abordagens qualitativa e quantitativa (TERENCE; FILHO, 2006). 33
Tabela 2 – Cronograma para o TCC2 . . . . . . . . . . . . . . . . . . . . . . . . . 35
Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Software Livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Lei de direitos autorais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Licenças de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Software Público . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Governança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Teoria Geral da Administração . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Conceito de Governança . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Processo de Software para o SISP (PSW-SISP) . . . . . . . . . . . . . . . 27
4 Considerações Preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Pesquisa-ação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 Abordagem Quantitativa versus Qualitativa . . . . . . . . . . . . . 32
4.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Resultados preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Próximos passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15
1 Introdução
Para o presente trabalho foi feito um estudo teórico para descobrirmos as origens
de dois tipos diferentes de processos de desenvolvimento, o desenvolvido pelo SISP e o que
é utilizado por comunidades de software livre para podermos diferenciá-los e encontrarmos
os postos de intercessão e assim propor um modelo que atenda estes dois processos.
O processo do SISP citado pede ser fortemente comparado à obra de Taylor, pois
tem em comum a preocupação em racionalizar, padronizar e prescrever normas que devem
ser seguidas para se chegar em um resultado de valor. Se observa que os 4 princípios que
o Taylor defende são vistos no processo do SISP da seguinte maneira:
• Princípio do Planejamento: no processo do SISP são planejados todos as fases e do
projeto antes mesmo de seu início.
• Princípio do Preparo: No início do projeto já são escolhidas as pessoas ou empresa
que irá desenvolver o projeto.
• Princípio do Controle: O processo cria mecanismos para controlar o desenvolvimento
ao longo de todo o projeto.
• Princípio da Execução: São distribuídas responsabilidades aos executores do projeto.
Este tipo de processo não dá a devida importância aos aspectos humanos de uma
organização se preocupando mais com os cargos ou funções daqueles que irão executar o
processo.
O desenvolvimento de software livre possui características distintas do modelo
restrito. Portanto, a relação com o mercado, o processo de desenvolvimento e o produto
a ser oferecido devem ser abordados de maneiras distintas (MEIRELLES, 2013).
Com o surgimento da Internet, a facilidade de comunicação e distribuição de
softwares possibilitou o surgimento de novas formas de trabalho colaborativo. Aliando esse
avanço na comunicação ao uso da modularidade (isto é, a possibilidade de divisão do soft-
ware em componentes desenvolvíveis independentemente) e de integradores automáticos
das contribuições individuais, passou a ser possível envolver colaboradores extremamente
diversos em torno de uma grande tarefa. As barreiras de entrada para participação dimi-
nuíram (pois cada colaborador podia selecionar onde ia trabalhar, e a granularidade —
tamanho e complexidade — do módulo em que iria contribuir), e a qualidade do esforço
coletivo pôde aumentar, dada a diversidade dos colaboradores. Trata-se do movimento do
software livre; a construção coletiva de uma ampla gama de softwares de qualidade, em
constante atualização e evolução (SIMON; VIEIRA, 2010).
16 Capítulo 1. Introdução
Sabendo que o processo de desenvolvimento de software livre é colaborativo, este
está mais relacionado com a teoria humanística onde é deixado de lado a preocupação
com os cargos ou máquinas e é dada a preocupação às pessoas que são o que realmente
importa no desenvolvimento do software.
Pode-se notar que existe uma grande divergência entre a maneira com que o SISP
trata o desenvolvimento de software e como a comunidade de software livre o trata, dessa
forma vamos por meio deste trabalho investigar como estes modelos de desenvolvimento
podem se adequar a fim de o governo também desenvolva e utilize software livre.
1.1 Objetivos
O objetivo geral deste trabalho é definir boas práticas de desenvolvimento de
software livre que sejam aderentes ao processo de desenvolvimento do governo.
Os objetivos específicos são:
• Mapear o processo de desenvolvimento utilizado pelo governo;
• Especificar problemas do software livre no governo;
• Propor um modelo de colaboração equilibrando as características dos processos
de governo com as características empíricas do desenvolvimento do Software li-
vre/público.
1.2 Justificativa
A Administração Pública, em sentido amplo, pode ser entendida como um con-
junto de entidades e de órgãos incumbidos de realizar a atividade administrativa vi-
sando à satisfação das necessidades coletivas e segundo os fins desejados pelo Estado.
(COUTINHO; TEMPONI; RODRIGUES, 2012)
A constituição federal estabelece princípios que devem ser adotados pela admi-
nistração pública no exercício de suas funções, quais sejam: legalidade, impessoalidade,
moralidade, publicidade, e eficiência, portanto “Não há “espaço jurídico vazio” dentro do
qual a Administração possa escolher livremente os fins a perseguir e os meios para alcançá-
los” Com efeito, a escolha de softwares a serem utilizados nos serviços públicos deve, obri-
gatoriamente, ser pautada por esses princípios (COUTINHO; TEMPONI; RODRIGUES,
2012).
Como será explicado no capítulo Software livre, este tipo de software pode ser
disponibilizado gratuitamente. Além disso, pode ser modificado para prover melhorias
ao programa e ser redistribuído e copiado. Essa liberdade de melhorias, modificações e
1.2. Justificativa 17
redistribuições desses softwares é o principal diferencial entre softwares livres e softwares
proprietários, já que esses últimos não podem ser nem modificados, nem redistribuídos.
Sendo assim podemos apontar algumas razões para o uso de software livre na
administração pública
• Nível de segurança proporcionado pelo Software Livre;
• Eliminação de mudanças compulsórias que os modelos proprietários impõem peri-
odicamente a seus usuários, em face da descontinuidade de suporte a versões ou
soluções;
• Independência tecnológica;
• Desenvolvimento de conhecimento local;
• Possibilidade de auditabilidade dos sistemas;
• Independência de fornecedor único;
• Gratuidade das licenças de software livre.
Dessa forma este trabalho vem discutir os motivos pelos quais a administração
federal não contrata software livre para uso nas entidades públicas mesmo citando os
motivos acima.
Na Seção 2 discutirei a respeito do software livre no brasil e no governo brasileiro
bem como as licenças utilizadas nesses software e sobre o software público brasileiro, na
Seção 3 abordarei o conceito de governança e a teoria geral da administração juntamente
com o processo utilizado pelo SISP1 para desenvolvimento de software, terminando com
a Seção 4 onde esclarecerei a metodologia utilizada para desenvolvimento deste trabalho,
a hipótese levantada a partir do problema e as considerações e resultados preliminares
deste trabalho além de um cronograma com os próximos passos.
1 http://www.sisp.gov.br/
19
2 Software Livre
Neste capítulo iniciaremos introduzindo o assunto sobre software livre e como ele é
tratado no governo brasileiro pela lei de direitos autorais, licensas de software e a solução
proposta pelo governo chamada software público brasileiro.
O software livre muitas vezes é considerado um fenômeno recente que veio à tona
rapidamente nos últimos anos. No entanto, desde o início da Computação a maior parte
dos desenvolvedores trabalhava da forma que hoje identificamos com o software livre:
Compartilhando código de forma aberta (KON et al., 2012).
Software expressa uma solução abstrata dos problemas computacionais. O soft-
ware, em um sistema computacional, é o componente que contém o conhecimento relacio-
nado aos problemas a que a computação se aplica. Por isso, o software é algo de interesse
geral, uma vez que vários aspectos relacionados a ele ultrapassam as questões técnicas,
como por exemplo:
• O processo de desenvolvimento do software;
• Os mecanismos econômicos (gerenciais, competitivos, sociais, cognitivos etc.) que
regem esse desenvolvimento e seu uso;
• O relacionamento entre desenvolvedores, fornecedores e usuários do software;
• Os aspectos éticos e legais relacionados ao software.
O que define e diferencia o software livre do que podemos denominar de software
restrito passa pelo entendimento desses quatro pontos dentro do que é conhecido como o
ecossistema do software livre. O princípio básico desse ecossistema é promover a liberdade
do usuário, sem discriminar quem tem permissão para usar um software e seus limites
de uso, baseado na colaboração e num processo de desenvolvimento aberto. Software
livre é aquele que permite aos usuários usá-lo, estudá-lo, modificá-lo e redistribui-lo, em
geral, sem restrições para tal e prevenindo que não sejam impostas restrições aos futuros
usuários (MEIRELLES, 2013).
Estima-se que hoje há centenas de milhões de usuários de software livre no mundo.
Se considerarmos também usuários indiretos, que usam serviços baseados em software
livre, como Google, Amazon ou eBay, esse número é ainda maior (SABINO; KON, 2009).
O governo vêm adotando um conjunto de iniciativas para implementação de soft-
ware livre no Brasil como reação aos enormes custos gerados à Administração com licen-
ças de softwares, o Decreto presidencial 18/00 instituiu o Comitê Executivo do Governo
20 Capítulo 2. Software Livre
Eletrônico, no intuito de racionalizar gastos com softwares. Para efetivar esse objetivo,
instituiu o Comitê Técnico para Implementação de Software Livre, por meio do Decreto
no 29/03.
A lei que rege sobre o software no Brasil é a Lei de Direitos Autorais e será explicada
em detalhes a seguir.
2.1 Lei de direitos autorais
Boa parte do software atualmente usado e desenvolvido, seja para computadores
pessoais ou servidores, seja para uso geral ou específico, é disponibilizado sob licenças
restritivas. Essas licenças, em maior ou menor grau, impõem restrições ao seu uso, distri-
buição ou acesso ao código-fonte. Esse tipo de licenciamento é possível porque o software
está sujeito à proteção da lei a respeito dos direitos de autor, que garante ao criador o di-
reito exclusivo de exploração de sua obra. Isso lhe permite autorizar ou não determinadas
formas de uso do software por parte dos usuários.
A legislação brasileira vê o software menos como produto e mais como expressão
intelectual, prevendo que os direitos de autor são o mecanismo próprio de proteção ao
software e excluindo explicitamente patentes como opção (Lei 9609/98 e Lei 9279/98,
art. 10). Segundo o instituto nacional de tecnologia da informação1 , os direitos autorais
sobre software, assim como sobre as obras literárias, são independentes de registro. A Lei
do Software estabelece, no entanto, que o INPI2 é o órgão governamental encarregado do
registro do software. O registro serve como comprovação de anterioridade de autoria sobre
o software caso esta venha em algum momento a ser questionada judicialmente.
A legislação autoral e de Propriedade Intelectual reconhece o software como objeto
de direito do autor, com regime específico dado pela lei do software (Lei no 9609/98)
subsidiada naquilo que for omissa pela Lei do Direito Autoral (Lei no 9610/98). Assim,
cabe ao titular do direito autoral a definição da forma como disporá desse direito, se em
regime proprietário, ou em regime livre. Essa decisão, certamente, situa-se fora do âmbito
de atuação do estado (JÚNIOR; SAMPAIO; MARANHÃO, 2005).
Segundo estudo sobre o software livre, comissionado pelo instituto nacional da
tecnologia da informação (ITI), o software no Brasil é regido pelo direito autoral. Na sua
maioria das vezes, essa proteção decorrente da lei segue aliada aos termos conferidos por
um contrato atinente a determinado software. Esse contrato é denominado “licença”. A
licença de um software estabelece um rol de direitos e deveres que se projetam sobre um
determinado usuário do software.
1 http://www.iti.gov.br/2 http://www.inpi.gov.br
2.2. Licenças de Software 21
2.2 Licenças de Software
Programas de software livre, em geral, são de fácil acesso. Porém, a simples obten-
ção de um programa não significa que a pessoa pode fazer o que quiser com ele. As licenças
de software livre são documentos através dos quais os detentores dos direitos sobre um
programa de computador autorizam usos de seu trabalho que, de outra forma, estariam
protegidos pelas leis vigentes no local (SABINO; KON, 2009).
Para que um software seja dito livre "o detentor dos direitos patrimoniais sobre
um software, deve escolher os termos em que seu trabalho será distribuído, ou seja, os
direitos que ele estará transferindo para as outras pessoas e quais as condições que serão
aplicadas. O documento que formaliza esse ato é a licença, que normalmente é distribuída
junto com o código fonte" (SABINO; KON, 2009).
Software aberto pode ser distribuído em uma grande variedade de licenças. A mais
famosa é a GNU General Public License (GPL), usada pela maior parte do software
desenvolvido pela Free Software Foundation 3.
As licenças de software são separadas em permissivas, recíprocas totais e recíprocas
parciais.
As licenças permissivas impõe poucas restrições ao uso e compartilhamento do
software, não é feita nenhuma restrição ao licenciamento de trabalhos derivados, estes
podendo inclusive serem distribuídos sob uma licença fechada. Licenças permissivas são
uma ótima opção para projetos cujo objetivo é atingir o maior número de pessoas, não
importando se na forma de software livre ou de software fechado. As principais licenças
dessa categoria são: BSD4, MIT/X115 e Apache6. (SABINO; KON, 2009)
As licenças recíprocas totais determinam que qualquer trabalho derivado precisa
ser distribuído sob os mesmos termos da licença original. Isso também é chamado de copy-
left, um termo criado pela Free Software Foundation7. A idéia do copyleft é dar permissão
a todos para executar, copiar, modificar e distribuir versões modificadas do programa,
mas impedir que sejam adicionadas restrições a essas versões redistribuídas. A licença que
deu origem à idéia de copyleft foi a General Public License, ou GPL8, da Free Software
Foundation. As principais licensas dassa categoria são as devivadas da GPL: GPL2.09,
GPLv310 e a AGPL11,que foi desenvolvida pela empresa Affero12. (SABINO; KON, 2009)
3 https://www.fsf.org/pt-br4 www.creativecommons.org/licenses/BSD/legalcode5 www.opensource.org/licenses/mit-license.php6 www.apache.org/licenses/LICENSE-2.0.html7 www.gnu.org/copyleft8 www.gnu.org/licenses/gpl.html9 http://www.gnu.org/licenses/old-licenses/gpl-1.0.html10 www.gnu.org/licenses/gpl-3.0-standalone.html11 www.affero.org/oagpl.html12 www.affero.org
22 Capítulo 2. Software Livre
Licenças recíprocas parciais, também chamadas de copyleft fraco, determinam que
modificações do trabalho coberto por elas devem ser disponibilizadas sob a mesma licença.
Porém, quando o trabalho é utilizado apenas como um componente de outro projeto, esse
projeto não precisa estar sob a mesma licença. As principais licenças dessa categoria são:
LGPL13 e a Licença Mozilla (SABINO; KON, 2009).
Para que um software se torne software público hoje, entre outras coisas, ele deve
possuir licença GPL2.0, conforme Instrução Normativa no 01 de 17 de janeiro de 2011.
2.3 Software Público
O Portal do Software Público Brasileiro - SPB, inaugurado em 2007, na prática,
é um sistema web que se consolidou como um ambiente de compartilhamento de proje-
tos de software. Oferece um espaço (comunidade) para cada software. A comunidade é
composta por fórum, notícias, chat, armazenamento de arquivos e downloads, wiki, lista
de prestadores de serviços, usuários, coordenadores, entre outros recursos. Teve um cres-
cimento expressivo contando, hoje, com mais de 60 comunidades de desenvolvimento e
mais de 200.000 usuários cadastrados. O SPB abrange também, o 4CMBr que é o grupo
de interesse voltado para soluções de tecnologia para municípios, o 5CQualiBr que é um
grupo que trabalha para evoluir a qualidade do Software Público Brasileiro, o 4CTecBr,
um portal destinado a colaboração no desenvolvimento de Tecnologias Livres, o Mercado
Público Virtual que é um grupo de empresas e pessoas que prestam serviço nos softwares
ofertados no Portal e o AvaliaSPB que avalia a entrada dos softwares candidatos à software
público. O ambiente do SPB não proporciona a integração com ambientes colaborativos
externos, especialmente com redes sociais. A plataforma escolhida na ocasião da criação
foi o framework OpenACS, que continua sendo utilizada na atual versão.
Inicialmente, o propósito do Portal compartilhar os softwares desenvolvidos no
governo visando diminuir os custos de contratação de software, mas se observou que ao
disponibilizar os softwares rapidamente se formavam comunidades em torno daquele soft-
ware com diversas pessoas colaborando e compartilhando os resultados obtidos através do
uso daquelas soluções. Desta forma algumas cooperativas de desenvolvimento de software
e empresas privados demonstraram o interesse em publicar seus softwares na plataforma
que estava sendo criada.
O Governo Federal criou em 2005 o modelo do Software Público Brasileiro (SPB),
que entre os usuários estão ofertantes e demandantes de soluções, organizados em comuni-
dades, criadas em torno de cada solução de software. A intensidade de participação varia
desde um observador interessado no software até líderes de comunidades. Essa diversidade
13 www.fsf.org/licensing/licenses/lgpl.html
2.3. Software Público 23
é derivada do modelo de produção do software livre, no qual baseou-se o SPB para sua
formação (ALVES et al., 2009).
A percepção do potencial que representava a participação da sociedade no desen-
volvimento do software e o conceito de bem público foram adaptadas do ponto de vista
jurídico, assim levando o Ministério do Planejamento, Orçamento e Gestão (MP) a for-
mular o conceito de software público. Essa base jurídico-institucional permitiu a criação
de um ambiente virtual (um portal) para a disponibilização de software como software
público. Esse modelo é definido por uma rede que se auto-organiza e cuja produção se
caracteriza pela intensa participação colaborativa entre indivíduos, empresa ou prestado-
res de serviço, universidades e instituições interessadas na evolução de um determinado
projeto de software (ALVES et al., 2009).
O conceito de software público diferencia-se do de software livre em alguns as-
pectos, destacando-se a atribuição de bem público ao software. Embora haja algumas
diferenças entre o que é um software livre e um software público brasileiro, há princí-
pios comuns, como a tendência da descentralização na tomada de decisões, o intenso
compartilhamento de informações e os processos de retroalimentação decorrentes do uso
dos artefatos produzidos. Em outras palavras, todo software público é um software livre
também.
Para se disponibilizar um software no Portal do Software Público a equipe do
Portal oferece um documento chamado Manual do Ofertante onde estão contidas todas
as informações e procedimentos para disponibilizar um software. neste manual é citada
qual licença de software deve ser aplicada e sobre o registro do software no INPI.
O modelo atual de disponibilização de um software como público é regido pela
Instrução Normativa No 01 de 17 de janeiro de 2011. Segundo esta IN ao se disponibilizar
um software público o mesmo estará se tornando um bem público que pode ser usado por
todos.
A contratação de software no governo é controlada pelo SISP que possui um pro-
cesso de contratação de software que será explicado em detalhes no Capítuto 3.
25
3 Governança
Neste capítulo iremos abordar a teoria geral da administração que deu origem ao
modo de administrar que conhecemos hoje, conceitos de governança e o modo como a
governo federal desenvolve software embasado no Processo de Software do SISP.
3.1 Teoria Geral da Administração
A preocupação em racionalizar, padronizar e prescrever normas é estudada desde
a Administração Científica proposta por Taylor. Segundo essa proposta a gerência deve
seguir 4 princípios (CHIAVENATO, 2001):
1. Princípio de planejamento. Substituir no trabalho o critério individual do operário,
a improvisação e a atuação empírico-prática, por métodos baseados em procedimen-
tos científicos. Substituir a improvisação pela ciência através do planejamento do
método de trabalho.
2. Princípio de preparo. Selecionar científicamente os trabalhadores de acordo com
suas aptidões e prepará-los e treiná-los para produzirem mais e melhor, de acordo
com o método planejado. Preparar máquinas e equipamentos em um arranjo físico
e disposição racional.
3. Princípio do controle. Controlar o trabalho para se certificar de que está sendo
executado de acordo com os métodos estabelecidos e segundo o plano previsto. A
gerência deve cooperar com os trabalhadores para que a execução seja a melhor
possível.
4. Princípio da execução. Distribuir atribuições e responsabilidades para que a execu-
ção do trabalho seja disciplinada.
A Administração científica deu pouca importância para os aspectos humanos de
uma organização, restringindo-se apenas a fatores relacionados diretamente com o cargo
ou função do operário, embora saibamos que uma organização é constituída por pessoas.
Paralelamente ao surgimento da Administração Científica de Taylor surgia a Administra-
ção Clássica, que diferentemente da teoria de Taylor que se caracterizava pela ênfase na
tarefa realizada pelo operário, se caracterizava pela ênfase na estrutura da organização
com o mesmo objetivo de buscar a eficiência das organizações (CHIAVENATO, 2001).
Na Teoria Clássica, preconizada por Fayol, ao contrário, partia-se do todo organi-
zacional e da sua estrutura para garantir eficiência a todas as partes envolvidas, fossem
26 Capítulo 3. Governança
elas órgãos (como seções, departamentos etc.) ou pessoas (como ocupantes de cargos e exe-
cutores de tarefas). Fayol define o ato de administrar como: prever, organizar, comandar,
coordenar e controlar. As funções administrativas envolvem os elementos da Administra-
ção, isto é, as funções do administrador (CHIAVENATO, 2001):
1. Prever. Visualizar o futuro e traçar o programa de ação.
2. Organizar. Constituir o duplo organismo material e social da empresa.
3. Comandar. Dirigir e orientar o pessoal.
4. Coordenar. Ligar, unir, harmonizar todos os atos e esforços coletivos.
5. Controlar. Verificar que tudo ocorra de acordo com as regras estabelecidas e as
ordens dadas.
Com o surgimento da Abordagem humanística e a Teoria das Relações Humanas,
a teoria Administrativa passa por uma revolução conceitual: a transferência da ênfase
antes colocada na tarefa (pela Administração Científica) e na estrutura organizacional
(pela Teoria Clássica) para a ênfase nas pessoas que trabalham ou que participam nas
organizações. A Abordagem Humanística faz com que a preocupação com a máquina e
com o método de trabalho e a preocupação com a organização formal e os princípios de
Administração cedam prioridade para a preocupação com as pessoas e os grupos sociais.
3.2 Conceito de Governança
Governança pode ser definida como o sistema pelo qual as organizações são monito-
radas envolvendo o relacionamento entre todos os integrantes, são recomendações objetivas
alinhando interesses na intenção de preservar e otimizar o valor da organização, em outras
palavras é um conjunto de processos que regulam a maneira como uma organização é diri-
gida e estuda as relações entre os diferentes atores que a compõe.(MOLINARO; RAMOS,
)
Mais especificamente para tecnologia da informação um sistema de governança es-
tabelece mecanismos, estruturas e incentivos, que compõem o sistema de controle de gestão
da empresa e direciona o comportamento dos administradores para o cumprimento dos
objetivos estipulados pelos acionistas/proprietários.(MARTIN; SANTOS; FILHO, 2004)
Segundo a Ministry of international trade and industry do MIT1 Além de "Capacidade
organizacional de controlar a formulação e implementação da estratégia de TI e guiar
a mesma na direção adequada com o propósito de gerar vantagens competitivas para a
corporação”1 http://www.mti.gov.bw/content/international-trade
3.3. Processo de Software para o SISP (PSW-SISP) 27
Governança de TI quando implantada de forma efetiva contribui para a melhora
da performance, que oir sua vez contribui para a melhora da organização como um todo
(JR, 2014).
Os conjuntos de processos definidos pela governança visam além de organizar, dar
transparência ao trabalho a ser realizado. Processo é um conjunto seqüencial de ações
baseado em estratégia para alcançar um objetivo. Para definir uma estratégia são neces-
sários 3 passos, identificar a situação do ambiente, identificar a situação da organização
e por fim é comparada a situação do ambiente e da organização e identificados os cursos
alternativos de ação e escolhida a melhor alternativa (MOLINARO; RAMOS, ).
Trazendo para a realidade do Novo Portal do Software público, a governança pode
ser usada para definir um processo que auxilie na gestão do Portal como um todo, e
mais especificamente, das comunidades que nele estão contidas, imprimindo organização
e controle para atender a demanda não somente do governo mas também dos usuários da
nova plataforma.
Para que este desenho faça sentido é necessário que seja colocado no processo
somente o que realmente tem valor de negócio para o usuário e para os gestores.
A definição da governaça dará subsídios para sejam notados os padrões de uso e
colaboração na nova plataforma, podendo assim ser geradas algumas "boas práticas"para
uso e colaboração visando a manutenebilidade da plataforma.
3.3 Processo de Software para o SISP (PSW-SISP)
O Sistema de Administração dos Recursos de Tecnologia da Informação – SISP, foi
instituído pelo Decreto n 1.048 de 21 de janeiro de 19942 e atualizado pelo Decreto n 7.579
de 11 de outubro de 20113, com o objetivo de organizar a operação, controle, supervisão e
coordenação dos recursos de informação e informática da administração direta, autárquica
e fundacional do Poder Executivo Federal, sendo facultada às empresas públicas e às
sociedades de economia mista a participação no SISP, cujas condições devem constar de
termo próprio a ser firmado entre os dirigentes das entidades e o titular do Órgão Central
do SISP4.
O processo de software para o SISP aborda as atividades ligadas ao desenvolvi-
mento e as atividades ligadas ao planejamento de recursos para o ambiente necessário
para o software.
2 http://www.planalto.gov.br/ccivil_03/decreto/1990-1994/D1048.htm3 http://www.planalto.gov.br/ccivil_03/_Ato2011-2014/2011/Decreto/D7579.htm4 http://www.sisp.gov.br/
28 Capítulo 3. Governança
Figura 1 – Processo de software para o SISP(PSW-SISP)
O processo é dividido em 6 fases:
• Concepção e Alinhamento estratégico: Esta fase inicia com o envio do documento
de oficialização da demanda (DOD) da Área Requisitante para a Área de TI, que
irá verificar o alinhamento estratégico da demanda com os instrumentos estratégicos
do órgão e, caso não esteja alinhada, irá devolver o DOD à Área Requisitante para
que, após a estimativa de custo preliminar do projeto de software realizado pela
Área de TI, a mesma solicite a mudança do PDTI ao Comitê de TI. O comitê de TI
irá analisar a possibilidade de incluir a demanda não planejada e, caso seja viável,
atualizará o PDTI. Caso esteja alinhado estrategicamente, a Área de TI irá elaborar
o termo de abertura e iniciar o projeto;(PSW-SISP)
• Especificação e dimensionamento: Esta fase destina-se ao entendimento e dimensi-
onamento da demanda de software através da definição do escopo do produto, da
modelagem de negócio e do levantamento dos requisitos funcionais e não funcionais;
(PSW-SISP)
• Estratégia de desenvolvimento:Essa fase destina-se a escolher a estratégia de desen-
volvimento (desenvolvimento interno, produção colaborativa ou contratação) mais
adequada para o desenvolvimento e/ou manutenção do software (evolutiva, corre-
tiva e adaptativa). Após escolhida a estratégia de desenvolvimento, será avaliado
qual a melhor metodologia de desenvolvimento de sistemas e qual a infraestrutura e
sustentação necessários para que o software funcione corretamente no ambiente de
produção; (PSW-SISP)
3.3. Processo de Software para o SISP (PSW-SISP) 29
• Desenvolvimento: É a fase onde é iniciada a execução do projeto de acordo com o
que foi planejado nas fases anteriores. O planejamento será atualizado sempre que
necessário para se adequar às novas realidades de tempo, escopo, custo, qualidade
e negócio; (PSW-SISP)
• Implantação e Estabilização: Implantação do software (adequado ou desenvolvido)
em seu ambiente de produção, para o seu uso efetivo, estabilizando a solução de
acordo com o ambiente de execução e o retorno dos usuários; (PSW-SISP)
• Sustentação e Evolução: manutenção da saúde do sistema (incluindo, mas não li-
mitado à processos de backup de dados, segurança de acesso e outros), o suporte
continuado aos usuários e o atendimento de novos requisitos que surgem do próprio
uso e mudanças de processos no negócio. (PSW-SISP)
O processo possui ainda, oito eixos de trabalho que permeiam todas as fases:
• Alinhamento estratégico: Alinhamento da necessidade do software com as necessi-
dades de negócio do órgão descritas nos seus instrumentos estratégicos;
• Gestão de projetos: Os processos de gestão de projetos serão mapeados tendo como
referência a Metodologia de Gerenciamento de Projetos do SISP (MGP-SISP);
• Produção Colaborativa: Desenvolvimento conjunto de software, ou seja, processos
que promovam o levantamento de requisitos comuns a mais de um órgão para que
possam desenvolver ou contratar um software colaborativamente;
• Gestão de Contratação: Conjunto de boas práticas para contratações de soluções
de TI. Os processos da gestão de contratação serão baseados e alinhados com a
instrução normativa IN MP/SLTI no 04/2010 e no Manual de Contratações de
Soluções de Tecnologia da Informação;
• Engenharia de Software: Desenvolvimento e manutenção de sistemas baseado nas
melhores práticas difundidas no mercado e na literatura, e em metodologias utiliza-
das por órgãos e entidades da Administração Pública Federal;
• Gestão da Segurança: Desenvolvimento seguro de software que envolve tanto a se-
gurança do ambiente de desenvolvimento quanto da aplicação desenvolvida;
• Gestão da Infraestrutura: Construir um ambiente que tenha a capacidade necessária
para prover serviços e uma estrutura adequada ao desenvolvimento de software;
• Gestão da Sustentação: Planejamento das condições necessárias para que o software
desenvolvido seja mantido, operado e evoluído de forma sustentável e viável.
30 Capítulo 3. Governança
Segundo o PSW-SISP, o intuito do processo é que ele seja usado conforme as
necessidades e maturidade do órgão. Ficará a cargo dos órgãos decidir quais as atividades
são adequadas à maturidade e ao projeto em desenvolvimento ou manutenção (corretiva,
adaptativa e corretiva), sendo que algumas atividades mínimas são consideradas essenciais
para a qualidade do software.
31
4 Considerações Preliminares
Software livre/público já está consolidado como um tipo de software confiável de-
vido ao nível de segurança proporcionado pelo seu uso, eliminação das mudanças impostas
pelo modelo proprietário, independência tecnológica, possibilidade de auditabilidade além
da gratuidade de suas licenças entre outras características. Neste trabalho procuramos en-
tender as dificuldades do governo em utilizar software livre/público abordando o efeito de
suas licenças e restrições de uso e como são tratado os direitos autorais desses softwares
no Brasil.
Para investigar a hipótese levantada neste trabalho, a pesquisa bibliográfica apre-
sentada estudou o processo de desenvolvimento utilizado pelo governo, também foi es-
tudada a administração e suas teorias para entendermos a origem das metodologias de
desenvolvimento do governo e do software livre/público bem como o conceito de gover-
nança.
Com este trabalho foi possível notar a que a diferenciação das metodologias estão
na origem das mesmas tendo como base a teoria geral da administração, onde pude reparar
que a teoria humanística utilizada no desenvolvimento de software livre/público se opõe
a teoria de Taylor que tem suas bases nos processos e é utilizada pelo governo.
Para o desenvolvimento deste trabalho será utilizada a metodologia de pesquisa
chamada pesquisa-ação, onde primeiramente é feita uma pesquisa bibliográfica para en-
tender o problema para a partir desse ponto gerar uma ação. Entenda em detalhes na
próxima sessão.
4.1 Pesquisa-ação
A pesquisa-ação ou action-research surgiu na década de 1940, no contexto de
críticas ao uso de procedimentos clássicos de ciências naturais na pesquisa social por razões
de ordem prática (conhecimento teórico gerado teria pouca aplicabilidade na prática) ou
ideológica (pesquisas estariam sendo realizadas como uma forma de controle social)(GIL,
2010).
O pesquisador na pesquisa-ação assume como premissa que processos sociais com-
plexos, como a interação entre organizações e seus sistemas de informação, são melhor
investigados quando se introduzem mudanças nestes processos e se observa os efeitos des-
tas mudanças. Outra premissa é que estes processos devem ser investigados como uma
entidade completa, não sendo possível extrair o objeto de investigação do seu contexto.
Desta forma, na pesquisa-ação busca-se avançar na teoria atuando na prática, o que é feito
32 Capítulo 4. Considerações Preliminares
através de ações no contexto de uma organização específica. O foco do pesquisador é na
compreensão do problema e das ações realizadas para solucioná-lo dentro de um ambiente
real particular e não na verificação de uma hipótese de caráter geral num ambiente de
laboratório (FUKS, 2008).
Figura 2 – Ciclo de desenvolvimento da pesquisa-ação
Segundo Ana Paula (SANTOS, 2012) "O pesquisador pode ter uma visão de insider
ou outsider, na realização de uma pesquisa-ação. A visão de um insider ocorre quando
o pesquisador vivencia o problema e o traz para a pesquisa, ou seja leva seus problemas
para realizar a pesquisa, já a visão de outsider é quando a instituição tem um problema
e chama um pesquisador ou o pesquisador vai atrás de uma empresa ou cenário real que
tenha o problema".
No caso desta pesquisa, estarei dentro de um contexto de desenvolvimento para
o governo por participar do Projeto do Novo Portal do Software Público, desta forma a
pesquisa pode ser classificada como insider.
4.1.1 Abordagem Quantitativa versus Qualitativa
As pesquisas, conforme as abordagens metodológicas que englobam, são classifi-
cadas em dois grupos distintos – o quantitativo e o qualitativo. O primeiro obedece ao
paradigma clássico (positivismo) enquanto o outro segue o paradigma chamado alterna-
tivo (TERENCE; FILHO, 2006).
4.2. Problema 33
Pesquisa quantitativa Pesquisa qualitativa
Inferência Dedutivo IndutivoObjetivo Comprovação InterpretaçãoFinalidade Teste de teorias, predição, esta-
belecimento de fatos, e teste dehipóteses
Descrição e entendimento de rea-lidades variadas, captura da vidacotidiana e perspectivas huma-nas
Realidade investigada Objetiva Subjetiva e complexaFoco Quantidade Natureza do objetoAmostra Determinada por critério estatís-
ticoDeterminada por critérios diver-sos
Característica da amostra Grande PequenaCaracterística do instru-mento de coleta de dados
Questões objetivas, aplicaçõesem um curto espaço de tempo
Questões abertas e flexíveis
Procedimentos Isolamento de variáveis. Anô-nima aos participantes
Examina todo o contexto, inte-rage com os participantes
Análise dos dados Estatística e numérica Interpretativa e descritiva. Ên-fase na análise do conteúdo
Plano de pesquisa Desenvolvido antes do estudo seriniciado
Evolução de uma idéia comoaprendizado
Resultados Comprovação de hipóteses Proposições e especulaçõesConfiabilidade e validade Pode ser determinada depen-
dendo do tempo e do recursoDifícil determinação, dada a na-tureza subjetiva da pesquisa
Tabela 1 – Características das abordagens qualitativa e quantita-tiva (TERENCE; FILHO, 2006).
Considerando as características apresentadas, a pesquisa desenvolvida neste tra-
balho terá uma abordagem qualitativa por sua natureza indutiva, subjetiva e complexa,
que será determinada por critérios diversos.
4.2 Problema
O Software Livre possui um mecanismo de produção colaborativo e dinâmico e
possui uma organização composta por um conjunto de pessoas que usa e desenvolve
um único software livre, contribuindo para uma base comum de código-fonte e conhe-
cimento (REIS; FORTES, 2003).
Este modelo típico do Software livre se diferencia em muitos aspectos com a forma
que o governo brasileiro desenvolve software, onde se estabelece um rígido processo.
Apesar disso, por fatores sociais e econômicos o governo brasileiro vem criando
políticas de incentivo a software livre, mas a dificuldade está em como fazer a governança
de dois mecanismos de gestão da produção de software antagônicos.
4.3 Hipótese
As boas práticas de desenvolvimento a serem utilizadas em um projeto de software
dependem do contexto, uma equipe que desenvolve software livre utiliza meios diferentes
34 Capítulo 4. Considerações Preliminares
para gerenciar o próprio projeto, que pode conter especificidades que impedem o uso de
determinadas práticas impostas pelo governo federal para controle do desenvolvimento de
software.
Dessa forma, com base no problema proposto, elaboramos a seguinte hipótese:
• Com algumas adaptações o processo do SISP pode se adequar ao processo de de-
senvolvimento do software livre/público, a partir das boas práticas de colaboração
dos mesmos.
Discutimos no Capítulo 2 o tratamento que o governo tem dado para o desenvolvi-
mento de software livre/público mas ainda existem procedimentos impostos pelo processo
de desenvolvimento utilizado pelo governo, mostrados no Capítulo 3, que não aproveitam
o ecossistema de desenvolvimento de software livre/público. A partir de boas práticas de
colaboração com o software livre/público será possível adaptar o processo de desenvolvi-
mento PSW-SISP para suportar estes tipos de software e dessa forma dar oportunidade
para que as comunidades de software livre possam desenvolver para o governo.
4.4 Resultados preliminares
O foco deste trabalho é adequar a metodologia de desenvolvimento do governo
com a metodologia utilizada pelas grandes comunidades de software livre a partir de boas
práticas utilizadas por essas comunidades. Está em desenvolvimento um documento com
boas práticas operacionais do novo portal do software público e sua primeira versão está
disponível no repositório do projeto 1.
No documento apresentado como governança operacional do Novo Portal do Soft-
ware Público são destacadas as interações dos usuários nos ambientes e a partir desta
interação é possível extrair boas práticas de desenvolvimento de software livre/público.
No documento o Novo Portal é dividido em ambientes onde os usuários podem ter
diferentes tipos de interação. O primeiro ambiente, chamado ambiente de comunicação,
estão contidas as listas de e-mails das comunidades, esta prática é muito adotada pelas
comunidades de desenvolvimento de software para abrir discussões técnicas e de negócio
a respeito do software a ser desenvolvido.
O segundo ambiente é o chamado ambiente de colaboração, neste ambiente serão
disponibilizados os códigos-fonte dos software que estão no portal e faz uso das boas
práticas adotadas pelas comunidades de desenvolvimento de software para versionamento
e controle do desenvolvimento.
1 https://gitlab.com/softwarepublico/workflow
4.5. Próximos passos 35
O terceiro ambiente é uma rede social para os usuários do portal, onde será possível
participar das comunidades dos softwares, ler notícias, baixar os softwares entre outras
funcionalidades.
4.5 Próximos passos
Para alcançar os objetivos deste trabalho, serão realizadas as seguinte macro-
atividades na segunda etapa deste trabalho. Seguindo a metodologia proposta utilizarei
os conhecimentos adquiridos na pesquisa desta etapa do trabalho para apresentar uma
ação para resolver o problema segundo a tabela 2.
Atividade Início Fim
Aprofundar estudo de metodologia de desenvolvi-mento do governo
01/02/2015 01/03/2015
Aprofundar estudo de metodologia de desenvolvi-mento software livre/público
01/02/2015 01/03/2015
Caracterizar os processos de desenvolvimento bus-cando pontos de intersecção
02/03/2015 15/03/2015
Coletar experiência e boas práticas dos usuários dasmetodologias
16/03/2015 01/04/2015
Analisar dados coletados 02/04/2015 15/04/2015Discutir resultados encontrados 16/04/2015 01/05/2015Montar governança adequada com base nos resulta-dos
02/05/2015 01/06/2015
Discutir governança proposta 02/06/2015 20/06/2015Entrega do TCC2 20/06/2015 30/06/2015
Tabela 2 – Cronograma para o TCC2
As primeiras atividades de aprofundamento de estudo das metodologias serão ne-
cessárias que ocorram paralelamente para que já seja buscada uma comparação entre as
mesmas e estas atividades darão subsídios para que sejam caracterizados os dois processos
de desenvolvimento. Coletar experiência dos usuários será uma maneira de observar as
boas práticas de cada metodologia e com a análise das experiência poderei distinguir o
que fica e o que é necessário que seja repensado em cada processo. A metodologia proposta
será montada a partir dessas experiências e estudos relacionados trazendo embasamento
para a metodologia proposta.
37
Referências
ALVES, A. M. et al. Software público brasileiro: muito além do compartilhamento desoftware. A2 Comunicação, 2009. Citado na página 23.
CHIAVENATO, I. Teoria geral da administração. [S.l.]: Elsevier Brasil, 2001. Citado 2vezes nas páginas 25 e 26.
COUTINHO, C. E.; TEMPONI, Í. R.; RODRIGUES, J. E. O uso de softwars livres naadministração: Possibilidades e desafios. In: Anais do Congresso Nacional Universidade,EAD e Software Livre. [S.l.: s.n.], 2012. v. 1, n. 2. Citado na página 16.
FUKS, H. Suporte à coordenação em sistemas colaborativos: uma pesquisa-ação comaprendizes e mediadores atuando em. 2008. Citado na página 32.
GIL, A. C. Métodos e técnicas de pesquisa social. In: Métodos e técnicas de pesquisasocial. [S.l.]: Atlas, 2010. Citado na página 31.
JR, G. H. C. D. S. Information technology governance in public organizations: Howperceived effectiveness relates to three classical mechanisms. Revista de Gestão daTecnologia e Sistemas de Informação, v. 11, n. 2, p. 297–326, 2014. Citado na página 27.
JÚNIOR, F.; SAMPAIO, T.; MARANHÃO, J. S. d. A. Software livre: a administraçãopública ea comunhão do conhecimento informático. Revista de direito público daeconomia, 2005. Citado na página 20.
KON, F. et al. Software livre e propriedade intelectual: Aspectos jurídicos, licenças emodelos de negócios. http://ccsl. ime. usp. br/files/slpi. pdf>. Acesso em, v. 2, p. 12,2012. Citado na página 19.
MARTIN, N. C.; SANTOS, L. R. d.; FILHO, J. M. D. Governança empresarial,riscos e controles internos: a emergência de um novo modelo de controladoria. RevistaContabilidade & Finanças, SciELO Brasil, v. 15, n. 34, p. 07–22, 2004. Citado na página26.
MEIRELLES, P. R. M. Monitoramento de métricas de código-fonte em projetos desoftware livre. Tese (Doutorado) — Instituto de Matemática e Estátistica – Universidadede São Paulo (IME/USP), 2013. Citado 2 vezes nas páginas 15 e 19.
MOLINARO, L.; RAMOS, K. GESTAO DE TECNOLOGIA DA INFORMAÇAO.LTC. ISBN 9788521617723. Disponível em: <http://books.google.com.br/books?id=pQuXuAAACAAJ>. Citado 2 vezes nas páginas 26 e 27.
REIS, C. R.; FORTES, R. P. de M. Caracterizaç ao de um Processo de Software paraProjetos de Software Livre. Tese (Doutorado) — PhD thesis, University of Sao Paulo,Brazil, 2003. Citado na página 33.
SABINO, V.; KON, F. Licenças de software livre história e caracterısticas. 2009. Citado3 vezes nas páginas 19, 21 e 22.
38 Referências
SANTOS, A. P. O. dos. Aplicação de práticas de usabilidade ágil em software livre. Tese(Doutorado) — Universidade de São Paulo, 2012. Citado na página 32.
SIMON, I.; VIEIRA, M. S. O rossio não rival. Revista USP, n. 86, p. 66–77, 2010.Citado na página 15.
TERENCE, A. C. F.; FILHO, E. E. Abordagem quantitativa, qualitativa ea utilizaçãoda pesquisa-ação nos estudos organizacionais. XXVI ENCONTRO NACIONAL DEENGENHARIA DE PRODUÇÃO-ENEGEP, v. 9, 2006. Citado 3 vezes nas páginas 11,32 e 33.