Você está na página 1de 17

MINISTÉRIO DO PLANEJAMENTO, ORÇAMENTO E GESTÃO

SECRETÁRIO DE LOGÍSTICA E TECNOLOGIA


INSTRUÇÃO NORMATIVA N° X, DE XX DE XX DE 2009

Dispõe sobre o Software Público Brasileiro.

O SECRETÁRIO DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO, no uso de suas atribuições


que lhe conferem o Decreto n° 6.081, de 12 de abril de 2007, revigorado pelo Decreto n° 6.222, de 4 de
outubro de 2007, e tendo em vista o disposto na Lei n° 8.666, de 21 de junho de 1993, na Lei n° 10.520, de
17 de junho de 2002, na Lei n° 9.609, de 19 de fevereiro de 1998, na Lei n° 9.610, de 19 de fevereiro de
1998, na Lei n° 9.279, de 14 de maio de 1996, no Decreto n° 1.048, de 21 de janeiro de 1994, no Decreto
n° 2.271, de 7 de julho de 1997, no Decreto n° 3.555, de 8 de agosto de 2000, no Decreto n° 3.931, de 19
de setembro de 2001, e no Decreto n° 5.450, de 31 de maio de 2005, resolve que:

Art. 1° O desenvolvimento, o uso e a disponibilização do Software Público Brasileiro (SPB), bem


como a definição do escopo de serviços relacionados ao mesmo, obedecerá o disposto nesta Instrução
Normativa.

Art. 2 ° O software público é uma categorização do bem software que adota um modelo de licença
livre, a proteção da licença pública de marca e é disponibilizado em ambiente virtual público, sendo tratado
como um benefício para a sociedade e o cidadão.

CAPÍTULO I
DAS DISPOSIÇÕES GERAIS

Art. 3° Para fins desta Instrução Normativa, considera-se:

I – Software: sistema ou componente constituído por um conjunto de programas, procedimentos e


documentação, desenvolvido para atendimento de necessidades específicas do órgão ou entidade, bem
como aqueles previamente desenvolvidos e disponíveis no mercado para utilização na forma em que se
encontram ou com modificações;

II – Software livre: software cujo modelo de licença atende aos quatro tipos de liberdade definidas
pela Free Software Foundation, sendo elas:
a) a liberdade para executar o programa, para qualquer propósito (liberdade nº 0);
b) a liberdade de estudar como o programa funciona, e adaptá-lo para as suas necessidades
(liberdade nº 1). Acesso ao código-fonte é um pré-requisito para esta liberdade;
c) a liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo (liberdade nº 2);
d) a liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo que toda a
comunidade se beneficie (liberdade nº 3). Acesso ao código-fonte é um pré-requisito para esta liberdade;

III – Tecnologia proprietária: aquela cuja cópia, uso, redistribuição, ou modificação são em alguma
medida restringidas ou liberadas mediante contrato ou relações de troca pecuniária;

IV – SISP: Sistema de Administração dos Recursos de Informação e Informática da Administração


Pública Federal, instituído pelo Decreto de lei n° 1.048, de 21 de janeiro de 1994;

V – Comunidade virtual: é uma comunidade que se caracteriza pela aglutinação de um grupo de


indivíduos com interesses comuns que trocam experiências e informações no ambiente virtual;

VI – Comunidade aberta no Portal SPB: é uma comunidade virtual acessível a quaisquer


interessado, mediante cadastramento prévio, sem restrições de acesso;

VII – Entidade ofertante: pessoa física ou jurídica, de direito público ou privado, que oferta uma
solução de software para que a mesma se torne SPB. A entidade ofertante é a que detém a propriedade
patrimonial do software;

VIII – Marca: representação simbólica de um objeto, qualquer que ela seja, que permite identificá-la
de modo imediato e ao mesmo tempo cria um conjunto sólido e unitário de tal identificação para a(s)
comunidade(s).
CAPÍTULO II
DO SOFTWARE PÚBLICO BRASILEIRO

Art. 4° O fundamento para tratar software como objeto de compartilhamento pode ser obtido na
Teoria dos Bens Públicos: bem público como aquele que apresenta características de indivisibilidade e de
não rivalidade. Ou seja, pode ser usado por todos sem que com isto se estabeleça competição entre os
usuários pelo bem.

Art. 5° A iniciativa de publicizar software é justificada pelo caráter cada vez mais estratégico do
software para governos e sociedade, pela similaridade de demandas entre os entes públicos, pela
racionalização dos recursos humanos, materiais e de tecnologia da informação para seu atendimento e pelo
acervo de soluções desenvolvidas pelos diferentes poderes e esferas.

Art 6° O conceito de SPB ampara-se na tese de bem público e imputa responsabilidades para os
entes governamentais e sua rede de parceiros, no seu processo de disponibilização, de manutenção e
evolução.

Art 7° O SPB não é um tipo diferente de software e nem uma espécie distinta dentro do gênero
software, o que difere são as garantias oferecidas à sociedade e ao cidadão, bem como os serviços
prestados, que encontram-se descritos no Anexo II.

Art 8° O SPB atende a um interesse público, preconizado por uma demanda da sociedade, em
especial, do setor público e somente será disponibilizado com anuência total da entidade ofertante.

Art 9° A parceria com as instituições de direito privado tem amparo no Artigo 3° do Decreto 1048,
que institui o SISP.
Parágrafo único: as instituições de direito privado que aderirem ao modelo terão as mesmas
obrigações que as instituições de direito público, sendo o órgão central do SISP o articulador, o
definidor e o homologador do cumprimento de tais obrigações.

CAPÍTULO III
DA DISPONIBILIZAÇÃO DO SOFTWARE PÚBLICO BRASILEIRO

Art 10° O procedimento de disponibilização do SPB, bem como os requisitos técnicos que devem
ser atendidos pelo software, para que o mesmo se torne público, são descritos no Anexo II – Modelo de
Gestão, Disponibilização e Desenvolvimento do Software Público Brasileiro.

Art 11° A entidade ofertante do software deve disponibilizar um ou mais profissionais para exercer o
papel de coordenador técnico e um ou mais profissionais para exercer o papel de coordenador institucional,
conforme descrito no Anexo II que trata do Modelo de Gestão, Disponibilização e Desenvolvimento do
Software Público Brasileiro.
§ 1° Os profissionais devem permanecer disponíveis pelo período que a solução estiver em
atividade, a contar da data de lançamento do software no Portal SPB.
§ 2° A entidade ofertante do software deve fornecer o nome completo e as informações de contato
dos profissionais que exercerão os papéis de coordenador institucional e de coordenador técnico.
§ 3° Caso a entidade ofertante não deseje manter os profissionais responsáveis pelas atividades de
coordenação, ela deve comunicar o fato à coordenação do Portal para que esta tome as providências
cabíveis para a substituição dos representantes e garantir o pleno funcionamento da comunidade virtual.
§ 4° O coordenador técnico e o coordenador institucional podem ser a mesma pessoa.

CAPÍTULO IV
DO USO DO SOFTWARE PÚBLICO BRASILEIRO

Art 12° O SPB é disponibilizado como um pacote, com arquivos de instalação e documentação
suficientes para sua utilização em ambiente de produção. Porém, o desenvolvimento de melhorias para
atendimento de necessidades específicas de pessoas físicas ou jurídicas, de direito público ou privado, é
uma característica intrínseca ao bem software. As melhorias necessárias não são de responsabilidade do
órgão central do SISP. Da mesma forma, se o SPB se mostrar defeituoso, os custos de manutenções,
reparos e correções não serão do órgão central do SISP.

Art 13° O órgão central do SISP é responsável por disponibilizar gratuitamente alguns dos serviços
associados ao SPB. Tais serviços estão descritos na seção 2.1 do Anexo II que trata do Modelo de Gestão,
Disponibilização e Desenvolvimento do Software Público Brasileiro. Estes serviços são disponibilizados com
o propósito de facilitar a evolução do software e a comunicação das diversas partes interessadas, provendo
um ecossistema que permita a colaboração universal em prol de um interesse público.

Art 14° Serviços de instalação, configuração, implantação, desenvolvimento, manutenção e suporte


diferenciado ao SPB não são de responsabilidade do órgão central do SISP.

Art 15° A responsabilidade por qualquer dano geral, direto, especial, acidental, indireto ou
conseqüencial (incluindo, mas não limitado a perda de lucros, perda de dados, interrupção nos negócios,
danos pessoais ou perda de privacidade) de alguma forma relacionado ao uso ou à inabilidade para usar o
SPB é de quem utiliza o software.

Art 15° O risco total com a qualidade e o desempenho do SPB é de quem o utiliza.

Art 16° O uso do SPB deve primar pelos princípios éticos, não podendo contrariar os princípios
Constitucionais e os Direitos Universais.

CAPÍTULO V
DO USO DO PORTAL SOFTWARE PÚBLICO BRASILEIRO

Art 17° O acesso ao conteúdo do Portal SPB é aberto a todos os interessados, mediante
cadastramento no próprio Portal.

Art 18° O Portal SPB distribui o SPB gratuitamente, na intenção de que possa ser útil, mas sem
nenhuma garantia de adequação a qualquer mercado ou aplicação em particular.

Art 19° É considerada a versão oficial do SPB aquela disponibilizada no Portal SPB.

CAPÍTULO VI
DO DESENVOLVIMENTO DO SOFTWARE PÚBLICO BRASILEIRO

Art 20° O coordenador técnico da comunidade deverá manter, no Portal do SPB, a última versão
estável do SPB pelo qual é responsável.

Art 21° A documentação do SPB, disponível no Portal SPB, devem ser atualizadas, sempre que
necessário, para refletir as alterações realizadas no software.

Art 22° Para cada nova versão do software, deve ser disponibilizado um documento de versão,
contendo a descrição das correções e melhorias implementadas naquela versão do software.

Art 23° As novas versões do software, seu código-fonte e documentação devem ser disponibilizados
no ambiente de gerência de configuração, fornecido no Portal SPB.

Art 24° Caso um órgão ou entidade da Administração Pública Federal desenvolva melhorias em um
SPB, ela fica obrigada a oferecer estas melhorias para o Portal do SPB.

Art 25° Caberá sempre ao coordenador institucional (ou a quem ele delegar) analisar, homologar,
aprovar ou rejeitar qualquer contribuição para uma nova versão do SPB.

CAPÍTULO VII
DA MARCA

Art 26° No que se refere ao nome e a marca serão adotados os regimes de Marcas Coletivas e de
Certificação previstas na legislação específica para Marcas e Patentes, a Lei n° 9.279/96.

Art. 27° A marca e nome do software estão associados diretamente ao código-fonte e a


documentação desenvolvidos pela entidade ofertante e para tanto devem ser tratadas em conjunto com o
software liberado, criando uma identidade única entre a marca, o nome, o código e a documentação.
Art. 28° A marca associada ao software e demais componentes deverá, obrigatoriamente, seguir o
modelo da Licença Pública de Marca-LPM.

Art. 29° Deve ser providenciado o pedido de registro de marca do software disponibilizado, contendo
o regulamento de utilização, de acordo com a LPM.

Art. 30° No pedido de registro da marca, no que se refere à certificação, devem estar evidentes: (i)
as características do produto ou serviço objeto de certificação; e (ii) as medidas de controle que serão
adotadas pelo titular.

Art. 31° O uso da marca deverá seguir os princípios descritos na LPM, onde constam todas as
características da autorização de utilização e distribuição.

CAPÍTULO VIII
DA COMISSÃO DE COORDENAÇÃO DO SPB

Art. 32° Integram a Comissão de Coordenação do SPB:

I – a SLTI, como Órgão Central do Sistema de Administração dos Recursos de Informação e


Informática - SISP;
II – a Secretaria de Política de Informática (SEPIN) do Ministério da Ciência e Tecnologia (MCT);
III – a Secretaria de Inovação Industrial do Ministério do Desenvolvimento, Indústria e Comércio
Exterior(MDIC);
IV – cada coordenador institucional de comunidade no Portal SPB;
V – a Associação Brasileira de Empresas Estaduais de Processamento de Dados (ABEP);
Parágrafo único: A comissão de coordenação do SPB será presidida por um representante da SLTI.

Art. 33° Compete à Comissão de Coordenação do SPB:


I - participar da elaboração e implementação das políticas, diretrizes e normas relativas ao SPB;
II – garantir a estabilidade e confiabilidade do Portal SPB;
III - promover o intercâmbio de conhecimento entre os participantes do Portal SPB e homogeneizar
o entendimento das políticas, diretrizes e normas;
IV - acompanhar e avaliar os resultados da implantação de softwares públicos em órgãos e
entidades governamentais;
V – apoiar as atividades relacionadas aos grupos de interesse;
VI – divulgar trabalhos e ações em prol do SPB;
VII – atuar como câmara de arbitragem;
VIII – destituir coordenadores de comunidade, quando julgar necessário;
Parágrafo único: posteriormente, será regulamentado as condições que podem levar à destituição
de um coordenador, seja ele técnico ou institucional.

CAPÍTULO IX
DAS DISPOSIÇÕES FINAIS

Art. 34° Aplica-se subsidiariamente ao bem software de que trata esta norma o disposto na Lei n°
9.609 e na Lei n° 9.610, ambas de 19 de Fevereiro de 1998, bem como o disposto na Lei n° 9.279, de 14
de Maio de 1996.

Art. 35° A Secretaria de Logística e Tecnologia da Informação poderá expedir instrumentos


complementares a esta Instrução Normativa, de acordo com atribuições previstas no Decreto 1.048/94.

Art. 36° Será criada uma agenda de trabalho para adequação dos softwares já disponibilizados no
Portal SPB, considerando caso a caso.
Art. 37° Esta Instrução Normativa entra em vigor a partir da data de sua publicação.

Anexo I

•Licença CC GPL (Licença Pública Geral), versão 2.0, em português.

O Instituto Nacional de Tecnologia da Informação (ITI) encomendou um estudo sobre a constitucionalidade


da CC GPL, em sua versão 2.0, em português. O resultado do estudo sinalizou de que esta licença, além de
não afetar a Constituição, também não fere o ordenamento jurídico brasileiro, podendo ser utilizada com o
devido amparo legal – inclusive para a liberação de softwares desenvolvidos pelo setor público.

A GNU General Public License é a licença com maior utilização por parte de projetos de software
livre e se baseia nas quatro liberdades dos usuário de software, definidas pela Free Software
Foundation. A Creative Commons, publica e gerencia a Licença Pública Creative Commons e tem
por finalidade a criação de uma universalidade de bens culturais, incluindo software, que se tornem
patrimônio criativo comum, acessível a todos. A licença CC GPL é uma união da licença GNU GPL
com a CC GPL. Os trabalhos derivados de artefatos licenciados sob GPL, devem ser licenciados
também sob GPL.

A estrutura da licença pode ser acessada no endereço


http://creativecommons.org/licenses/GPL/2.0/legalcode.pt
Anexo II

Modelo de Gestão, Disponibilização e Desenvolvimento do Software Público Brasileiro

1. Requisitos Técnicos

Esta seção trata dos requisitos técnicos que devem ser atendidos por todo SPB:

1.1) Produto pronto para uso

Todo SPB deve ser disponibilizado como um produto pronto para ser instalado e utilizado. A versão
do software disponibilizada deve estar estável e madura o suficiente para ser instalada e utilizada em um
ambiente de produção.

1.2) Documentação

1.2.1) Manual de Instalação

Todo SPB deve ser disponibilizado com manual de instalação. O manual de instalação deve
possibilitar que o usuário seja capaz de instalar o software, sem o auxílio do órgão ou entidade responsável
pelo desenvolvimento original do software (entidade ofertante). Caso haja variação no procedimento de
instalação do software, a depender das diversas plataformas suportadas pelo mesmo (sistema operacional,
banco de dados, servidor de aplicação,...), estas diferenças devem ser explicitadas no manual de
instalação.
O manual de instalação é um documento obrigatório e deve conter, no mínimo, as informações
identificadas no Anexo IV.

1.2.2) Manual do Usuário/ Manual de Uso

É desejável que todo SPB seja disponibilizado com o manual de uso.


O manual de uso deve descrever todas as funções disponibilizadas pelo software.
Preferencialmente, o manual de uso deve conter, no mínimo, as informações identificadas no Anexo V.

1.2.3) Documentação de Desenvolvimento

É desejável que todo SPB seja disponibilizado com a documentação de desenvolvimento. A


documentação de desenvolvimento deve possibilitar que terceiros entendam a arquitetura/estrutura do
software e possam contribuir para a sua evolução.
A documentação de desenvolvimento deve conter informações sobre as tecnologias, frameworks e
padrões utilizados; além de descrever os principais componentes e entidades do sistema, bem como as
regras de negócio implementadas.

1.3) Componentes do SPB

1.3.1) Código Fonte

Todo SPB deve ser disponibilizado com o seu código fonte. Adicionalmente, é obrigatório que o
criador do software escreva no cabeçalho de cada arquivo fonte o tipo de licença que utiliza, conforme
descrito no Anexo I.

1.3.2) Scripts de Banco de Dados

Se o SPB fizer uso de banco de dados, devem ser disponibilizados os scripts de banco, para cada
banco de dados suportado, necessários para a correta instalação e utilização do software, além de manter
as garantias de independência de banco.

1.4) Proibições

É vedado ao SPB:
I – utilizar bibliotecas, componentes, ferramentas, fontes e utilitários proprietários;
II – depender somente de plataformas proprietárias;
III – depender de um único fornecedor.

2.  Disponibilização do Software Público Brasileiro

2.1) Serviços associados ao SPB

O SPB deve ser disponibilizado com serviços associados. Por serviços associados entende-se:
página na internet; wiki; fórum ou listas de discussão e ferramenta de controle de configuração/versão. Os
fóruns e listas de discussão são utilizadas para facilitar o desenvolvimento colaborativo, além de prover
suporte no uso do SPB e possibilitar novos projetos relacionados ao mesmo.

Para cada SPB, o governo deve disponibilizar uma comunidade virtual aberta, que simplifique os
procedimentos na relação do governo com o usuário, para que este conheça como pode resolver as
questões relacionadas ao software e os responsáveis por cada serviço.

2.2) Restrições Legais do SPB

Todo SPB deve ser licenciado pelo rol de licenças constantes no Anexo I.

Todo SPB deve ter seu registro no INPI (Instituto Nacional de Patrimônio Intelectual), nos princípios
da Lei n° 9.609. Tal registro é competência da instituição que oferta a solução.

Toda Marca de um SPB deve adotar a Licença Pública de Marca e seguir a Lei de Marcas e
Patentes.

2.3) Portal do Software Público Brasileiro

O Portal SPB é o ambiente público oficial para liberação, compartilhamento e desenvolvimento de


SPB. Desta forma, todo SPB deve ser disponibilizado no Portal SPB ( http://www.softwarepublico.gov.br/).

No Portal SPB são disponibilizados, além do software, a comunidade virtual relacionada ao software
e os serviços a ele associados, tais como fórum, wiki, lista de discussão, chat, etc.

Embora todo SPB seja disponibilizado no Portal SPB, a recíproca não é verdadeira. Ou seja,
existem softwares que não adotam o modelo público de disponibilização no Portal SPB. Isto ocorre devido a
necessidade de se compartilhar soluções de software da Administração Pública Federal que não satisfazem
a todos os requisitos técnicos necessários para que se torne SPB. Tais soluções são compartilhadas por
meio de comunidades fechadas (acessíveis a um conjunto restrito de usuários, adicionados a critério do
administrador da comunidade e de regras de acesso previamente definidas).

2.4) Oferta de software para o Portal do Software Público Brasileiro

Softwares públicos podem ser ofertados tanto por órgãos e entidades do Poder Público quanto da
iniciativa privada, ou mesmo por pessoas físicas interessadas no desenvolvimento de projetos de interesse
comum.

O procedimento de disponibilização do software é descrito pelos passos enumerados abaixo:

1) Uma solução de software é ofertada para que a mesma se torne um SPB. A manifestação de
interesse em ofertar o software pode ocorrer mediante a tomada de qualquer das ações descritas no Anexo
III.
2) O órgão central do SISP avalia, tecnicamente, a solução ofertada. Para tal ação, a entidade
ofertante deve ceder o código-fonte da solução, os componentes da solução e toda a documentação
disponível. O órgão central do SISP será responsável por avaliar a solução, considerando os requisitos
técnicos elencados na seção 1 do presente documento.
3) O órgão central do SISP emitirá um parecer técnico aprovando a disponibilização ou não da
solução como SPB. O parecer técnico deve atestar se a solução satisfaz ou não os requisitos técnicos
necessários. Opcionalmente, podem ser fornecidas diretrizes para que o software e/ou sua documentação
sejam alterados com o intuito de atender aos requisitos técnicos necessários.
Caso a solução de software não satisfaça alguns dos requisitos técnicos obrigatórios, descritos na
seção 1 deste documento, havendo interesse do órgão central do SISP e/ou da entidade ofertante, as
partes podem entrar em acordo sobre a realização de adequações da solução para que a mesma satisfaça
os requisitos técnicos.
4) Após a aprovação técnica da solução, caso a mesma não possua registro no Instituto Nacional de
Patrimônio Intelectual (INPI), ela deve ser registrada no INPI, nos princípios da Lei n° 9.609. O registro do
software é responsabilidade da entidade ofertante.
5) O órgão central do SISP cria a comunidade virtual para o novo SPB e disponibiliza a solução no
Portal do Software Público Brasileiro.

O procedimento de oferta de solução de software para o SPB é ilustrado pela Figura 1: Oferta de
Solução para o SPB.

Oferta de Solução para o SPB

Entidade Ofertante Órgão Central do SISP

Oferecer  Avaliar 
Solução Solução

Emitir Parecer 
Técnico

Existe  Solução  Sim


Não Não satisfaz 
interesse 
em ajustar a requisitos 
 solução? SPB?

Sim

Adequar
Solução

Solução  Sim
possui registro 
no INPI?

Não

Registrar
Disponibilizar 
Solução
Solução no 
no INPI
Portal SPB
Figura 1: Oferta de Solução para o SPB.
2.5) Solicitação de software para o Portal do Software Público Brasileiro

O órgão central do SISP poderá solicitar a disponibilização do software, ao órgão ou entidade da


Administração Pública Federal, responsável pelo desenvolvimento original, conforme disposto na Instrução
Normativa n° 4, de 19 de maio de 2008, com uma das licenças descritas no Anexo I.

O procedimento de solicitação do software é descrito pelos passos enumerados abaixo:

1) O órgão central do SISP solicita uma solução de software à um órgão ou entidade da


Administração Pública Federal, para que a mesma se torne um SPB.
2) O órgão central do SISP avalia, tecnicamente, a solução ofertada. Para tal ação, o órgão ou
entidade da Administração Pública Federal deve ceder o código-fonte da solução, os componentes da
solução e toda a documentação disponível. O órgão central do SISP será responsável por avaliar a solução,
considerando os requisitos técnicos elencados na seção 1 do presente documento.
3) O órgão central do SISP emitirá um parecer técnico aprovando a disponibilização ou não da
solução como SPB. O parecer técnico deve atestar se a solução satisfaz ou não os requisitos técnicos
necessários. Opcionalmente, podem ser fornecidas diretrizes para que o software e/ou sua documentação
sejam alterados com o intuito de atender aos requisitos técnicos necessários.
Caso a solução de software não satisfaça alguns dos requisitos técnicos obrigatórios, descritos na
seção 1 deste documento, havendo interesse do órgão central do SISP, ele pode entrar em acordo com o
órgão ou entidade da Administração Pública Federal, requerendo a realização de adequações da solução
para que a mesma satisfaça os requisitos técnicos.
4) Após a aprovação técnica da solução, caso a mesma não possua registro no Instituto Nacional de
Patrimônio Intelectual (INPI), ela deve ser registrada no INPI, nos princípios da Lei n° 9.609. O registro do
software é responsabilidade do órgão ou entidade da Administração Pública Federal, responsável pelo
desenvolvimento da solução.
5) O órgão central do SISP cria a comunidade virtual para o novo SPB e disponibiliza a solução no
Portal do Software Público Brasileiro.

O procedimento de oferta de solução de software para o SPB é ilustrado pela Figura 2: Solicitação
de Solução para o SPB.
Solicitação de Solução para o SPB

Órgão Central do SISP Órgão/Entidade da


Administração Pública Federal

Ceder
Solicitar
Solução p/
Solução
Avaliação

Avaliar
Solução

Emitir Parecer
Técnico

Solução Não Existe Não


Sim
satisfaz interesse
requisitos em ajustar a
SPB? solução?

Sim

Adequar
Solução

Solução
possui registro
no INPI?
Não

Disponibilizar Registrar
Solução no Solução
Portal SPB no INPI

Figura 2: Solicitação de Solução para o SPB.


2.6) Problemas com a disponibilização do software para o Portal do Software Público Brasileiro

Se os requisitos técnicos não atendidos pelo software solicitado forem referentes à deficiências no
manual de instalação, o órgão ou entidade da Administração Pública Federal responsável pelo
desenvolvimento original do software, fica obrigada a sanar as falhas de documentação, no prazo máximo
de sessenta (60) dias.
Caso os requisitos técnicos não atendidos pelo software solicitado forem referentes à deficiências
no manual de uso, o órgão ou entidade da Administração Pública Federal responsável pelo desenvolvimento
original do software, fica obrigada a sanar as falhas de documentação, no prazo máximo de cento e vinte
(120) dias.
Qualquer item que inviabilize a disponibilização do software no Portal SPB será tratado em comum
acordo entre as partes.

3. Coordenação de Comunidade

3.1) Responsabilidades dos Coordenadores de Comunidade


Preferencialmente, a comunidade de cada software disponibilizada no Portal SPB deve contar com,
no mínimo, um coordenador institucional e um ou mais coordenadores técnicos, que representam a
entidade ofertante.

São responsabilidades do coordenador institucional:


 comparecer as reuniões de coordenação do Portal SPB;
 publicar notícias relacionadas ao software na comunidade virtual do software no Portal SPB,
inclusive informações sobre a liberação de nova versão do software;

São responsabilidades do coordenador técnico:


 responder mensagens no fórum de discussão da comunidade virtual do software;
 moderar as mensagens do fórum de discussão da comunidade virtual do software;
 atualizar o código-fonte do software no Portal SPB;
 manter a documentação do software atualizada no Portal SPB;
 manter uma versão estável do software no Portal SPB.

3.2) Responsabilidade da entidade ofertante do software

Inicialmente, os profissionais que exercerão os papéis de coordenador técnico e de coordenador


institucional serão fornecidos pela entidade responsável pelo desenvolvimento original do software. Caso o
profissional designado para a exercer um ou mais dos papéis acima venha a se desligar da entidade
ofertante ou deixe de ser o responsável pela execução de uma ou mais das atividades descritas na seção
3.1, a entidade ofertante deve, prontamente, fornecer um substituto e notificar ao órgão central do SISP.

3.3) Substituição de Coordenadores da Comunidade

Por tratar-se de um ambiente dinâmico e colaborativo, a comunidade poderá eleger seus próprios
coordenadores, não necessariamente vinculados ao órgão/entidade/instituição responsável pelo
desenvolvimento original.
Caso a comunidade eleja novos coordenadores, a entidade ofertante do software fica isenta de
fornecer seus profissionais, ainda que não tenha findado o prazo de 6 meses, a contar do lançamento do
software.
Se a comunidade vier a ficar sem coordenadores, a coordenação do Portal SPB estudará caso a
caso e tomará as providências cabíveis.
Anexo III

A oferta de uma solução de software para o Portal do SPB, deve ser realizada pela tomada de uma das
ações abaixo descritas:

 Ação 1
 Mediante ofício, contendo nome e descrição do software, enviado para o
Secretário de Logística e Tecnologia da Informação
Ministério do Planejamento, Orçamento e Gestão
Esplanada dos Ministérios, Bloco C - 3° andar
Brasília - DF - CEP: 70046-900
Anexo IV
Modelo para Manual de Instalação do Software Público

<Este modelo dispõe das informações mínimas que devem constar no manual de instalação do SPB.
Havendo outras informações significativas para a correta instalação do software, elas devem ser incluídas
no manual de instalação, ainda que não tenham sido previstas neste modelo.>

Nome do Software: [NOME]


Versão do Software: [DESCRIÇÃO DA VERSÃO]

1. Visão Geral

<Nesta seção deve ser fornecida:


 uma breve descrição do manual de instalação, dispondo acerca de sua
organização(capítulos, seções, subseções, etc)
 uma descrição dos softwares, módulos ou componentes que precisam ser instalados>

2. Requisitos de Instalação

2.1. Requisitos de Hardware

<Nesta seção deve ser fornecida uma descrição do hardware recomendado para a instalação do
software. Caso o software seja distribuído ou possua arquitetura cliente-servidor, devem ser fornecidos os
requisitos recomendados para cada dispositivo/máquina requerida.

Para cada máquina requisitada para a instalação, fornecer as seguintes informações:

Hardware Requisito
Processador <informar o modelo e a velocidade do
processador, destacando se é a velocidade
mínima ou a recomendada.
Ex: Intel Core 2 Duo, 3 Ghz, 32 bits>
Memória <informar a quantidade de memória RAM ,
destacando se é a quantidade mínima ou a
recomendada>
Espaço em disco <informar a quantidade de espaço em disco
necessário para adequada instalação e uso do
software, destacando se é a quantidade
mínima ou a recomendada>
Resolução de vídeo <descrever a resolução recomendada para a
correta visualização do software, bem como a
quantidade de cores requeridas. Ex:
Resolução mínima de 1024 x 768 pixels com
256 cores>
Outro hardware: <inserir hardwares indispensáveis ao uso do
sistema, por exemplo: mouse, microfone, web
cam, teclado, fone, etc.>

A tabela acima pode ser expandida, de forma a descrever características pertinentes não
previstas.>

2.2. Requisitos de Software

<Para cada máquina requisitada para a instalação, fornecer as seguintes informações:>

Sistema Operacional Versão Service Pack ou outra


restrição
<incluir uma linha para cada
sistema operacional
suportado>

Banco de Dados Versão


<incluir uma linha para cada banco de dados suportado.
Esta tabela pode ser suprimida, caso o software não
requisite banco de dados>

Servidor de Aplicação Versão


<incluir uma linha para cada servidor de aplicação
suportado. Esta tabela pode ser suprimida, caso o
software não requisite servidor de aplicação>

Navegador Web Versão


<incluir uma linha para cada navegador suportado. Esta
tabela pode ser suprimida, caso o software não requisite
de navegador>

Biblioteca/ Componente Versão Onde pode ser obtido?


<incluir uma linha para cada
biblioteca, componente ou
código requisitado para a
correta instalação e utilização
do software. Esta tabela pode
ser suprimida, caso o software
não requisite de
bibliotecas/componentes de
terceiros. Observe que o
componente/biblioteca
requisitado deve ser gratuito,
de código livre e/ou aberto>

2.3. Outros Requisitos

<nesta seção devem ser incluídos os requisitos não hardware e não software para a correta instalação do
software. Exemplos: privilégios do usuário no sistema operacional, banco de dados,...>

3. Instalação

<Nesta seção deve ser descrito um passo-a-passo do processo de instalação do software, com
screen shots. O conteúdo deve ser organizado de forma a descrever todos os itens que devem ser
instalados, em todas as plataformas suportadas.
Exemplo:
3. Instalação

3.1. Instalação do Banco de Dados


...
3.1.1. PostgreSQL
...
3.1.2. MySQL
...
3.2. Implantação no Servidor de Aplicação
...
3.2.1. Implantação no Tomcat
...
3.3. Instalação no Sistema Operacional
...
3.3.1. Windows
...
3.3.2. Linux
...
etc.>

4. Contato

<informações do contato responsável pela manutenção da documentação de instalação>


Anexo V
Modelo para Manual do Usuário do Software Público

<Este modelo dispõe das informações mínimas que devem constar no manual de utilização do SPB.
Havendo outras informações significativas para a correta utilização do software, elas devem ser incluídas
no manual de uso, ainda que não tenham sido previstas neste modelo.>

Nome do Software: [NOME]


Versão do Software: [DESCRIÇÃO DA VERSÃO]

1. Visão Geral

<Nesta seção deve ser fornecida:


 uma descrição do software, contendo: seu objetivo principal, seus objetivos secundários e
necessidades que visam ser atendidas.
 uma breve descrição do manual do usuário, dispondo acerca de sua organização(capítulos,
seções, subseções, etc)>

1. Iniciando no <nome do software>

<Nesta seção deve ser fornecida um passo-a-passo de como o usuário faz para começar a utilizar o
software. O passo-a-passo deve possuir um exemplo completo (do início ao fim), que possibilite ao usuário
entender como utilizar as principais funcionalidades do sistema.>

2. Atividades e Tarefas

<Para cada atividade e/ou tarefa que possa ser realizada no sistema, deve ser fornecido uma seção
descrevendo como realizá-la.

Exemplo:

Considerando um software para gerenciamento de projetos, algumas tarefas poderiam ser

3.1. Como criar um Projeto


...
3.2. Alocação de Recurso em uma Tarefa do Projeto
...
3.3. Registro de trabalho de um profissional na planilha de horas
...
etc.>

3. Relatórios

<Apresentar os principais relatórios gerados pelo Sistema>.

4. Telas e Consultas

<Apresentar as principais telas de navegação e as consultas geradoa pelo Sistema>.