ANEXO 8 DO PROJETO BÁSICO DA FERRAMENTA/PLATAFORMA DE PORTAL WEB

ANEXO 8 DO PROJETO BÁSICO DA FERRAMENTA/PLATAFORMA DE PORTAL WEB Sumário 1. Finalidade... 2 2. Justificativa... 2 3. Premissas para a execução dos serviços... 2 4. Demonstração e Validação da Ferramenta/Plataforma... 4 5. Instalação e configuração dos servidores... 5 6. Requisitos para a Ferramenta/Plataforma... 7 6.1. Ferramenta/Plataforma... 7 6.2. Desenvolvimento de componentes:... 9 6.3. Gerenciamento de páginas:... 10 6.4. Escalabilidade:... 12 6.5. Gerenciamento de múltiplos ambientes:... 14 6.6. Administração da Ferramenta/Plataforma... 14 6.7. Gerenciamento de usuários, grupos e segurança:... 15 6.8. Estrutura, Interface Visual e Personalização:... 16 6.9. Gerenciamento de Conteúdo:... 17 6.10. Colaboração:... 23 6.11. Busca:... 25 Página 1

ANEXO 8 DO PROJETO BÁSICO DA FERRAMENTA/PLATAFORMA DE PORTAL WEB 1. FINALIDADE O presente ANEXO tem por finalidade apresentar os requisitos mínimos obrigatórios da ferramenta/plataforma de CMS para desenvolvimento e manutenção de sistemas/portais WEB da TERRACAP, visando o aperfeiçoamento e agilidade da interação do cidadão/usuários via internet e intranet. 2. JUSTIFICATIVA Os serviços de disponibilização de informações prestados hoje pela TERRACAP carecem de tecnologias ágeis e modernas para atendimento à carência de informação do público externo e usuários internos. Essa necessidade decorre dos processos atualmente utilizados para a criação e publicação de conteúdos na internet, suportados por uma tecnologia ultrapassada, que remete a um processo lento e burocratizado para a divulgação das informações. Esses processos dificultam a publicação pelas áreas geradoras de conteúdo, que deveriam ser as próprias gestoras do conteúdo que produzem. Para que os serviços de publicação de informações tornem-se ágeis, faz-se necessária a utilização de um sistema/plataforma de Portal WEB que proporcionará: Agilidade para o cumprimento das metas institucionais quanto à disponibilização da informação; Eficiência no processo de categorização e classificação das informações; Descentralização do processo de gestão da publicação conteúdos; Organização adequada das informações; Aprimoramento da experiência do usuário na busca de informações; Controle apurado de segurança da informação; Processo de publicação de conteúdo que garanta confiabilidade e precisão. 3. PREMISSAS PARA A EXECUÇÃO DOS SERVIÇOS 3.1. Toda comunicação e documentação deverão apresentar-se integralmente no idioma Português-Brasil. Página 2

3.2. A licitante será responsável por oferecer métodos de suporte técnico no idioma Português-Brasil de forma direta ou a partir de parceiros especializados e certificados. 3.3. Os requisitos funcionais e as qualidades sistêmicas obrigatórias da plataforma do portal estão definidos neste ANEXO. 3.4. Todos os requisitos definidos devem ser atendidos plenamente pela Ferramenta/Plataforma e devem integrar a mesma, não sendo aceitas implementações externas, devendo todos os módulos serem nativos da Ferramenta/Plataforma e desenvolvidos pelo fabricante. 3.5. Deverá ser apresentada a identificação dos produtos ofertados para cumprimento dos requisitos técnicos obrigatórios. 3.6. A licitante deverá disponibilizar, os softwares e demais componentes da ferramenta que atendam os requisitos obrigatórios definidos neste Anexo; instalar; configurar; treinar; e garantir suporte técnico durante o período de vigência do contrato. 3.7. A Ferramenta deverá contemplar os seguintes ambientes: Produção, Homologação e Desenvolvimento. 3.7.1. A Ferramenta deverá suportar número ilimitado de usuários. Considerando a configuração descrita para hardware constante neste ANEXO. 3.7.2. Os servidores deverão ser instalados e configurados de forma a oferecer redundância e balanceamento de carga entre os equipamentos (Cluster ativo-ativo). 3.8. A Ferramenta/Plataforma deverá ser baseada em arquitetura web. 3.9. Nenhuma ferramenta desktop e nenhum software adicional ao navegador deverão ter sua instalação requerida aos usuários para realizar as operações de administração e configuração, disponibilização, publicação, edição e aprovação de conteúdo, salvo ferramentas de administração de banco de dados e ferramentas de programação nos casos de pontos de extensão que venham a ser disponibilizados. 3.10. A Ferramenta/Plataforma adotada deverá ser compatível, sem quaisquer restrições de usabilidade e funcionalidade, com os navegadores Microsoft Internet Explorer (Versão 7 ou superior), Mozilla FireFox (Versão 3.0 ou superior) e Google Chrome (Versão 10.0 ou superior) e ter suporte a protocolos móveis, permitindo o acesso a partir de smartphones e tablets. Página 3

4. DEMONSTRAÇÃO E VALIDAÇÃO DA FERRAMENTA/PLATAFORMA 4.1. Após a fase de apresentação das propostas, a empresa vencedora deverá, no prazo de 3 (três) dias úteis, realizar Prova de Conceito, que consiste na instalação da Ferramenta/Plataforma ofertada e comprovação das funcionalidades descritas neste ANEXO, através de: 4.1.1. Instalação da Ferramenta/Plataforma para demonstração das funcionalidades e análise da plataforma do portal corporativo; 4.1.2. Entrega de documentação técnica, contendo os manuais e guias de instalação, configuração e utilização, nos quais deverão ser identificadas pela empresa as páginas e/ou sessões onde se encontram a descrição das funcionalidades da Ferramenta/Plataforma para o atendimento a cada um dos requisitos previstos no item 6 (seis) deste ANEXO; 4.1.3. Apresentação de proposta de cronograma para implantação da Ferramenta/Plataforma licitada, incluindo todos os itens contratados. 4.2. O licitante deverá agendar a data para demonstração da Ferramenta/Plataforma junto a TERRACAP, trazendo todos os itens que forem necessários para demonstração. 4.3. Para a avaliação, a Ferramenta/Plataforma deverá ser instalada em ambiente temporário na TERRACAP junto a área responsável da Terracap. 4.4. A empresa deverá indicar um profissional capaz de executar procedimentos de teste, dirimir dúvidas e acompanhar a homologação da Ferramenta/Plataforma. 4.5. Será solicitada demonstração para fins de comprovação da compatibilidade da Ferramenta/Plataforma com as especificações técnicas deste ANEXO, bem como todas as outras exigências descritas neste ANEXO; 4.6. A Prova de Conceito deverá ser avaliada pela área responsável da Terracap e concluída no prazo de 3 (Três) dias úteis, a contar da data da entrega da amostra, por meio da checagem de todos os itens obrigatórios, sem a possibilidade de nova apresentação. 4.7. O resultado da avaliação será divulgado pela TERRACAP que publicará a data do prosseguimento do certame. 4.8. A licitante deverá comprovar que o software utilizado no cumprimento do requisito solicitado faz parte do escopo ofertado na sua proposta técnica, apresentando na data da sua comprovação, a lista dos requisitos técnicos exigidos, referenciando no manual técnico sua comprovação. Página 4

5. INSTALAÇÃO E CONFIGURAÇÃO DOS SERVIDORES 5.1. Entende-se por configuração, a necessidade de definir, ferramenta/plataforma, as opções de preferência ou uso que atendam as especificações do hardware e do sistema operacional em que ele está instalado. Essa atividade não implica no desenvolvimento de código. 5.2. Os processos de instalação, configuração e implantação da Ferramenta/Plataforma, deverão ser documentados junto a TERRACAP, dentro dos padrões e metodologias indicados e aprovados pelo mesmo. 5.3. Juntamente com as mídias de software, a empresa licitante deverá fornecer toda a documentação técnica original, completa e atualizada, contendo os manuais e guias de instalação, configuração e utilização, não sendo aceitas cópias de qualquer tipo. 5.4. Antes da instalação dos programas deverá ser colocado à disposição relatório de impacto no ambiente da TERRACAP e plano de operação assistida, que deverá ser aprovado pela TERRACAP. 5.5. A instalação deverá ser realizada em data e hora agendada pela TERRACAP, podendo inclusive ser realizada nos finais de semana. 5.6. A instalação e a configuração deverão ser realizadas, obrigatoriamente, por técnico devidamente capacitado, certificado pelo fabricante e com experiência em projetos de implantação da ferramenta apresentada, comprovada por declaração fornecida pela licitante. 5.7. A TERRACAP poderá solicitar a substituição de técnicos, devendo a empresa alocar substituto com grau equivalente ou superior de qualificação técnica; 5.8. A instalação e configuração deverão ser acompanhadas e monitoradas pelos técnicos da TERRACAP. 5.9. Compreende o processo de instalação e configuração a ser executado pela empresa licitante: 5.9.1. Instalar, configurar e ajustar o desempenho, em todos os servidores, da máquina virtual JAVA e do servidor de aplicações JEE nos ambientes de produção, homologação e desenvolvimento da TERRACAP. 5.9.2. Configurar Cluster e Session Replication nos ambientes de produção e homologação; 5.9.3. Configurar balanceamento de carga (load balancer) nos ambientes de produção e homologação; 5.9.4. Integrar a Ferramenta/Plataforma com os aplicativos de infra-estrutura da TERRACAP. Página 5

5.9.5. Integrar a Ferramenta/Plataforma com o banco de dados Oracle; 5.9.6. Integrar a Ferramenta/Plataforma com o LDAP (Lightweight Directory AccessProtocol); 5.9.7. Integrar a Ferramenta/Plataforma com o servidor http Apache e ou Tomcat. 5.9.8. Realizar a homologação final da Ferramenta/Plataforma juntamente com os técnicos da TERRACAP, depois de concluída a fase de operação assistida. 5.10. Especificação dos Servidores 5.10.1. O ambiente proposto pela licitante deverá estar ajustado à infraestrutura existente na TERRACAP conforme requisitos estabelecidos no ANEXO V Ambiente Tecnológico. 5.10.2. Serão utilizadas as seguintes configurações de hardware e software para instalação do ambiente de produção (servidores): 5.10.2.1. Configuração de Hardware: Processador: Memória RAM: 16 Gb Servidores: HP ProLiant BL460c G6 Server com 2 proces. Quad Intel(R) Xeon(R) CPU E5540 @ 2.53GHz 02 dedicados em regime de cluster ativoativo 5.10.2.2. Configurações de Software: Sistema Operacional: Linux Red Hat Enterprise ES 6.0 ou superior Servidor de aplicação: Servidor de banco de dados: JBOSS Application Server 7 ou superior Oracle 10g Servidor de web: Apache 2.0 ou superior Página 6

5.10.3. Devem ser consideradas semelhantes as configurações de hardware e software para os ambientes de Homologação e Desenvolvimento que será definida posteriormente pela TERRACAP. 6. REQUISITOS PARA A FERRAMENTA/PLATAFORMA Um dos principais objetivos da Ferramenta/Plataforma é simplificar e facilitar todo o processo de publicação de conteúdo de forma que possa ser executado por usuários com habilidades e conhecimentos equivalentes aos necessários para a operação de um simples editor de texto. As interfaces necessárias para a implementação do processo de gestão de conteúdo, que incluem interfaces de criação, edição, aprovação e publicação de conteúdo deverão ser simples e intuitivas, acessíveis totalmente por navegadores web, de modo a reduzir ao máximo os esforços dos usuários para interagir com a ferramenta. Abaixo são apresentados os requisitos mínimos obrigatórios a serem atendidos quanto aos seguintes critérios: 6.1. Ferramenta/Plataforma I. Permitir a criação e gestão de diversos sites ou portais em uma mesma instalação, de modo que: II. III. a) Cada site possa ter uma URL (Uniform Resource Locator ou Localizador Padrão de Recursos) independente. b) Todos os sites possam ser administrados em um mesmo ambiente. c) Seja possível definir grupos de usuários diferentes como administradores de cada site. d) Ao acessar e utilizar a área de administração, cada administrador veja apenas a estrutura dos sites que estão sob sua administração. Permitir adicionar um componente de um site a outro site, de modo que: a) O componente apresente exatamente as mesmas informações nos dois sites onde está sendo exibido. b) Não seja necessário ao administrador especificar quais conteúdos específicos devem estar presentes nos dois sites. c) Os dois sites onde o componente está publicado possam apresentar as mesmas informações, porém em uma camada de apresentação visual de layout diferente. Permitir que sites ou portais tenham subáreas que formem uma estrutura hierárquica, sendo possível criar tantos níveis de hierarquia quantos forem necessários. Página 7

IV. Oferecer um ambiente onde os administradores possam gerenciar de forma unificada todos os portais, áreas, componentes e demais recursos onde tenham permissões para administrar. V. Ter uma interface gráfica onde toda a estrutura de áreas, subáreas e páginas dos portais sejam gerenciadas sem exigir programação, permitindo: VI. VII. VIII. IX. a) Criar, editar e excluir áreas do portal. b) Criar, editar e excluir páginas do portal. c) Refletir imediatamente na navegação do usuário as mudanças realizadas. Gerar logs de navegação no formato padrão definido pelo padrão W3C (The World Wide Web Consortium). Possuir recurso que permita transformar uma área do portal em um modelo para criação de novas áreas, de modo que: a) Áreas criadas a partir de um modelo de área herdem do modelo sua estrutura de subáreas, páginas, regras de autorização e outras propriedades chave. b) Seja possível especificar quais conteúdos serão compartilhados entre as áreas criadas a partir do modelo, e quais serão específicos de cada área. c) Áreas criadas possam permanecer relacionadas ao modelo, de modo que fazendo uma alteração na estrutura do modelo esta alteração possa ser aplicada a todas as áreas relacionadas a este. d) Seja permitido ao administrador especificar quais áreas criadas a partir de um modelo devem ser atualizadas com a última alteração neste. Gerar automaticamente o mapa do site a partir da hierarquia das páginas. Permitir que as URLs que representam os endereços das páginas do portal tenham nomes amigáveis, formados por palavras da língua portuguesa, sendo possível: a) Que o caminho representado na URL seja criado a partir da estrutura de navegação do portal. b) Que o caminho representado na URL seja internacionalizado de acordo com a língua selecionada pelo usuário. c) Que o nome da página acessada possa ser criado a partir do conteúdo sendo acessado na página. Página 8

d) Que regras específicas para geração da URL possam ser definidas caso necessário. e) Que a URL não inclua qualquer tipo de código ou número gerado de forma automática pelo software que não tenha significado para um leitor. X. Permitir ao administrador mudar a estrutura do portal, incluindo a hierarquia de áreas e subáreas, através da interface gráfica sem que seja necessário consertar links entre os componentes do portal. XI. Permitir ao administrador mover componentes entre páginas do portal sem que seja necessário manualmente corrigir os links de outros componentes para o componente movido. 6.2. Desenvolvimento de componentes: I. Permitir o desenvolvimento de aplicações em JAVA que possam ser registradas como um novo componente do portal, tornando-se disponíveis para serem acrescentadas a uma área por um administrador. II. Oferecer um mecanismo através do qual novos componentes, desenvolvidos pela equipe da TERRACAP, possam definir perfis de usuários para que um administrador possa associar usuários aos perfis do componente através da interface da solução de portal. III. IV. Permitir que aplicações em outras linguagens, como.net, PHP, ASP, possam ser acrescentadas a páginas do portal. Oferecer componente que permita a integração com outros sistemas da TERRACAP por meio de Web Services no padrão SOAP (Simple Object Access Protocol), sem que seja necessária qualquer programação de código JAVA. V. Ser compatível com o padrão de portlet JSR-168. Portlet é um componente web independente que pode ser reutilizado. VI. VII. VIII. IX. Produzir portlets no padrão de interoperabilidade WSRP (Web Services for Remote Portlets), que possam ser consumidos por outros servidores do portal. Consumir portlets no padrão de interoperabilidade WSRP, produzidos por outros servidores do portal ou da Internet. Disponibilizar uma API (Application Programming Interface) em JAVA que permita a criação de programas para automatizar as tarefas de criação e gestão dos objetos do portal. Utilizar XML (Extensible Markup Language) como representação dos dados recuperados e manipulados por intermédio de suas APIs. Página 9

6.3. Gerenciamento de páginas: i. Permitir a criação e edição de páginas que definem a posição, diagramação e o visual dos componentes nas páginas que o usuário irá navegar nos portais criados. ii. Permitir que a diagramação dos componentes em uma página seja definida através de interface gráfica, com o uso do recurso drag-and-drop, sem que o diagramador necessite ter conhecimentos de programação web. iii. Possibilitar a geração automática de código HTML (HyperText Markup Language) sem tabelas (tableless) mesmo quando a página é criada e diagramada inteiramente com o uso do recurso drag-and-drop. Deve ser possível configurar se o código deve ou não ser tableless. iv. Permitir que as características de apresentação de informações de cada componente da página (por exemplo, o layout do componente, filtros de apresentação e critérios de ordenação) sejam editadas através de interface gráfica. v. Permitir a detecção automática de dispositivos móveis (famílias de smartphones, tablets e aparelhos celulares com menos recursos de navegação) e a pré-visualização dos conteúdos a serem publicados em cada um dos dispositivos previamente configurados para a disponibilização de informações. Essas funcionalidades darão maior produtividade no desenvolvimento de versões de sites e/ou páginas a serem expostas em dispositivos móveis, explorando os recursos e limitações de cada um deles. vi. Para facilitar a manutenção de páginas e reaproveitar diagramações, permitir que uma página possa servir de modelo para criação de outras páginas de modo que: a) As páginas criadas a partir de um modelo herdem do modelo, regiões com diagramação, layout e características de apresentação já definidos. b) As características de apresentação das regiões herdadas do modelo só possam ser alteradas no modelo. c) Uma vez alterada uma página que serve de modelo, seja possível definir quais páginas criadas a partir deste modelo devem ser atualizadas com as últimas alterações. vii. Permitir a associação de uma página a um arquivo HTML que, junto com CSS (Cascading Style Sheets), imagens e Javascripts referenciados por este, defina o layout e a diagramação padrão de uma página. viii. Permitir ainda que qualquer layout HTML seja utilizado como modelo visual para uma página do portal. Página 10

ix. Para páginas criadas desta forma, deve ainda ser possível ao administrador, com o uso do recurso drag-and-drop, associar os componentes do portal às regiões do layout definido pelo arquivo HTML estático. x. Permitir ao administrador graficamente determinar quais componentes de uma página devem ser exibidos quando o usuário solicitar uma versão da página para impressão. xi. Permitir ao administrador associar um layout diferente para cada componente da página quando o usuário solicitar uma versão da página para impressão. xii. Permitir que o HTML gerado para as páginas do portal seja compatível com os padrões de acessibilidade e sigam as recomendações do padrão W3C com relação ao uso de HTML e XHTML (Extensible Hypertext Markup Language). xiii. Possuir recurso de verificação das regras de acessibilidade que deve ser executado automaticamente quando o usuário altera o layout da página, alertando-o caso a alteração que está sendo promovida, seja conflitante com alguma recomendação dos padrões de acessibilidade. xiv. Permitir a um administrador especificar que áreas de quais portais, devem ter as suas páginas verificadas de acordo com as regras de acessibilidade. xv. Permitir que administradores realizem uma verificação de compatibilidade com as recomendações de acessibilidade a qualquer momento, gerando um relatório com resultados da verificação. xvi. O layout de todos os componentes da solução deve ser totalmente alterado com uso de XML e XSL (Extensible Stylesheet Language), sem que seja necessário alterar o código JAVA ou JSP (JavaServer Pages). a) O mesmo componente em páginas diferentes deve permitir layouts diferentes. b) Qualquer mudança no HTML gerado por qualquer componente deve ser feito da mesma forma. c) Deve se possível mudar qualquer elemento no HTML do componente acima. xvii. Permitir a definição de páginas com layouts específicos para visualização em dispositivos móveis. xviii. Permitir que usuários finais alterem a diagramação dos componentes em uma página, através do recurso drag-and-drop na própria página (WYSIWYG - What You See Is What You Get), de modo que: Página 11

a) Após um usuário alterar a diagramação de uma página, apenas este usuário visualiza a página com a nova diagramação. b) Um administrador possa definir previamente quais regiões de cada página poderão ter sua diagramação alterada. c) Uma página possa ter mais de uma região com possibilidade de ter sua diagramação alterada pelo usuário final. xix. Permitir que os administradores definam quais os componentes e instâncias destes componentes podem ser acrescentadas a uma página pelo usuário final. Ao diagramar uma página, permitir que o usuário final possa acrescentar componentes novos ou retirar componentes da diagramação. xx. Permitir que determinados usuários tenham permissão para definir a diagramação de uma página que será visualizada como padrão pelos demais usuários. 6.4. Escalabilidade: I. Oferecer suporte para funcionamento em ambiente cluster para balanceamento de carga em todas as camadas da plataforma tecnológica garantindo que não exista pontos de falha que possam causar indisponibilidade da solução, sejam elas camadas de banco de dados, servidor de aplicação, cache e quaisquer outras camadas necessárias ao funcionamento da solução. II. III. IV. Possuir sistema nativo que replique todos os arquivos e dados necessários entre os servidores do ambiente. Caso um servidor do ambiente torne-se indisponível, seus dados deverão ser sincronizados com o restante do ambiente automaticamente, sem a necessidade de intervenção de um administrador, assim que seja restabelecida sua disponibilidade. Oferecer suporte para o funcionamento das camadas da plataforma tecnológica (banco de dados, servidores de aplicação, cache, etc) em servidores com sistemas operacionais distintos. V. Oferecer suporte para a implementação de ambiente cluster em servidores com capacidades, configurações e sistemas operacionais distintos. VI. VII. Oferecer mecanismos de controle, distribuição e balanceamento de carga entre os servidores que compõem o ambiente cluster da ferramenta. Oferecer recursos de redistribuição automática de carga no entre os servidores no caso de falha ou pane de qualquer componente do Página 12

VIII. IX. ambiente cluster, sem necessidade de intervenções manuais e sem perda de disponibilidade da ferramenta. Oferecer suporte a processos de geração e recuperação de backups integrais, parciais e incrementais da solução. Possuir sistema para otimização de acesso (como cache, por exemplo) que permita gerar páginas do portal como arquivos HTML estáticos que são acessados diretamente pelos usuários ao navegar. O mecanismo deve: a) Poder gerar todas as páginas do portal, com todos os seus conteúdos, se necessário. b) Armazenar as versões em HTML das páginas como arquivos físicos nos servidores web. c) Permitir que usuários finais acessem as páginas com extensão HTML. d) Permitir que o nome dos arquivos HTML acessados pelo usuário sejam gerados a partir dos títulos de conteúdos das referidas páginas. e) Criar uma estrutura de pastas para organização dos arquivos HTML que represente a estrutura das URL s de acesso às páginas. f) Permitir que o usuário navegue pelo portal, sendo servido pelos arquivos HTML estáticos sem que seja efetuado nenhum acesso ao banco de dados no caso de páginas para visualização de conteúdo. g) Gerar os links entre as páginas em HTML usando referências para os arquivos HTML diretamente, sem que seja necessário acesso ao Application Server para processamento do link e usando inclusive nomes amigáveis destes arquivos, se existirem. h) Permitir que os arquivos HTML de algumas páginas sejam gerados previamente, antes que usuários façam o primeiro acesso. i) Permitir a configuração de quais servidores de um cluster devem ser utilizados. j) Permitir que os arquivos HTML de algumas páginas só sejam gerados quando algum usuário acessar a página pela primeira vez. k) Permitir que quando conteúdos novos são publicados com o gestor de conteúdo, os arquivos HTML estáticos correspondentes às páginas onde esses conteúdos aparecem sejam imediatamente gerados novamente. X. Permitir que qualquer componente de uma página possa ser configurado, via interface gráfica da Ferramenta/Plataforma, para que o cache do seu Página 13

resultado seja armazenado em um arquivo HTML separado e incluído no HTML da página via Server Side Include. 6.5. Gerenciamento de múltiplos ambientes: I. Permitir a definição de ambientes diferentes para desenvolvimento, homologação e produção. II. III. a) Oferecer recurso que permita passar alterações feitas a um destes ambientes para os demais. b) Permitir que apenas mudanças feitas na estrutura dos portais sejam passadas de um ambiente para outro, sem que para isso seja necessário passar também o conteúdo. c) Permitir que apenas mudanças em algumas áreas sejam transferidas entre ambientes, sem que para isso seja necessário passar todas as áreas de todos os portais. Permitir a exportação das características de um portal, ou de uma área de um portal, para uma base em arquivos que possa posteriormente ser utilizada para importar o mesmo portal em outra instalação. Permitir que o conteúdo possa ou não ser exportado para posterior importação. IV. Permitir automaticamente replicar arquivos gerados pela Ferramenta/Plataforma (como por exemplo: HTML, imagens e CSS) para servidores remotos através de FTP (File Transfer Protocol), tornando possível, por exemplo, a atualização de sites em servidores remotos em tempo real, no momento em que algum de seus conteúdos seja atualizado. 6.6. Administração da Ferramenta/Plataforma I. Permitir múltiplos administradores. II. III. IV. Permitir o gerenciamento de múltiplos sítios com usuários e grupos de usuários distintos. Permitir a delegação e distribuição de privilégios de determinados recursos e tarefas de administração aos outros usuários. Oferecer assistentes de migração e "clonagem" entre ambientes distintos de homologação e produção. V. Oferecer mecanismo de coleta e registro de eventos da plataforma através de logs do sistema. VI. VII. Possuir log das alterações efetuadas no conteúdo da Ferramenta. Suportar o envio de notificações de eventos via e-mail, utilizando o SMTP (Simple Mail Transfer Protocol). Página 14

VIII. IX. Oferecer mecanismos de extração de relatórios para o monitoramento da utilização dos recursos e conteúdo disponibilizados no portal. Prover informações de estatísticas de acesso, permitindo saber quais conteúdos são mais acessados. 6.7. Gerenciamento de usuários, grupos e segurança: I. Possuir um repositório nativo de usuários, que não dependa da utilização de nenhum sistema externo de diretório de usuários. II. III. IV. Permitir a sincronização de forma agendada com o repositório de usuários e grupos de usuários o LDAP (Lightweight Directory Access Protocol). Utilizar o mesmo repositório de usuários para todos os seus módulos, incluindo gerenciamento de portais, gestão de conteúdo e colaboração. Permitir a criação de uma forma adicional de novos grupos de usuários, onde os atributos dos mesmos definam regras a serem aplicadas para classificá-los conforme as seguintes características: a) Permite a definição das regras via interfaces gráficas, sem a necessidade de programação. b) Os membros dos grupos são calculados automaticamente na medida em que mudam os atributos dos usuários. c) Grupos com membros automáticos podem ser utilizados no restante da Ferramenta/Plataforma da mesma forma que grupos com membros explícitos. V. Possibilitar, por meio de interface gráfica, a definição de políticas de acesso distintas por usuários e/ou grupos de usuários no que diz respeito aos recursos e informações da ferramenta. VI. VII. Possibilitar, por meio de interface gráfica, a definição de políticas de acesso distintas por recursos do Portal, tais como áreas de conteúdo, páginas, componentes, ferramentas de publicação e funcionalidades específicas. Permitir que usuários e grupos recebam permissões: a) Para visualizar ou administrar conjuntos de atributos específicos de cada página dos portais. b) Para visualizar ou administrar conjuntos de atributos específicos de cada área dos portais. Página 15

VIII. IX. Permitir que permissões configuradas em uma área sejam herdadas ou não pelas subáreas ou páginas que pertencem àquela área. Permitir que através do ambiente de administração central, os administradores possam associar usuários e grupos aos perfis específicos de cada componente integrado à Ferramenta/Plataforma. X. Suportar o uso ilimitado de usuários não nomeados. XI. XII. XIII. XIV. XV. Possuir um mecanismo nativo de autenticação de usuários, que possa ser utilizado para: a) Autenticar usuários que possuem acesso ao ambiente de administração. b) Autenticar usuários dos portais desenvolvidos para acesso a áreas ou recursos restritos. Permitir inclusão de CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) em páginas e serviços que necessitam de bloquear acessos automatizados. Permitir que usuários possam ser autenticados por Single Sign-On (SSO), por sistemas de autenticação externos à Ferramenta/Plataforma, dando suporte, no mínimo, ao padrão JAAS (Java Authentication and Authorization Service) para esse fim. Permitir autenticação por meio de certificados digitais. Permitir ao administrador especificar via interface gráfica quais áreas do portal devem ser acessadas via protocolo HTTPS (Hypertext Transfer Protocol Secure). 6.8. Estrutura, Interface Visual e Personalização: I. Oferecer recursos de personalização de páginas e apresentação de conteúdo baseados em perfis de usuário. II. III. IV. Possibilitar a interação e comunicação entre portlets, permitindo que a alteração de parâmetros em um portlet possa gerar atualizações em outro portlet de forma automática. Permitir a atualização (refresh) de um portlet sem exigir a atualização de toda a página. Oferecer portlet para visualização de página e/ou fragmentos de página Web externa. V. Oferecer portlet que possibilite incorporar (consumir) serviços externos e recurso/mecanismo que possibilite disponibilizar (exportar) conteúdo via interfaces de comunicação amplamente aceitas como padrão de mercado, suportando obrigatoriamente: Página 16

a) Feeds em formato RSS (Really Simple Syndication) e/ou Atom; b) Web Services WSRP; c) Web Services WSDL e SOAP. 6.9. Gerenciamento de Conteúdo: I. Permitir que usuários publiquem conteúdos no portal, sem que para isso precisem ter qualquer conhecimento de HTML ou outra linguagem de programação web. II. III. IV. Permitir a criação de páginas com código HTML ou XHTML que atendam às recomendações do W3C e a associação de metadados de caracterização e classificação aos conteúdos de acordo com a arquitetura de informações definida, facilitando a indexação por sistemas de busca externos à Ferramenta/Plataforma. Oferecer um editor de textos WYSIWYG que permita ao usuário formatar o conteúdo com facilidade, sem que seja necessário inserir código de formatação em HTML. a) Deve ser possível mudar a fonte, cores do texto, inserir tabelas, formatar o texto como negrito, itálico, sublinhado, etc. b) Deve ser possível configurar quais das formatações devem estar disponíveis para os usuários. c) Deve ser possível inserir imagens no texto. Permitir que o visual do conteúdo em cada página do portal seja diferente. V. Utilizar modelos (templates) de apresentação distintos para a exibição de cada tipo de conteúdo e suportar a reutilização dos modelos (templates) de apresentação repetidamente em vários locais do Portal. VI. VII. VIII. IX. Oferecer tratamento distinto de conteúdo e modelo de apresentação, garantindo que um mesmo conteúdo possa ser apresentado em páginas e formatos distintos. Possibilitar a visualização prévia do conteúdo a ser publicado. Oferecer recursos para o desenvolvimento e manutenção de fluxos de criação, aprovação, publicação e remoção de conteúdo do portal. Permitir que administradores criem tipos de conteúdo diferentes, sendo parte da definição de um novo tipo de conteúdo: a) Os campos que compõem o conteúdo e os tipos de cada campo. b) O suporte ou não a várias seções de conteúdo. Página 17

c) Os recursos de publicação disponíveis para os gestores daquele tipo de conteúdo. d) A definição do fluxo de aprovação que deve ser aplicado como padrão. X. Permitir que a criação de tipos de conteúdo customizados possa ser feita via interface gráfica, sem a necessidade de desenvolvimento em JAVA. XI. XII. XIII. XIV. XV. XVI. XVII. Permitir que conteúdos de qualquer tipo sejam agrupados em seções, de modo que: a) Seja possível criar diversas seções para o mesmo tipo de conteúdo. b) Cada seção de um mesmo tipo de conteúdo possa ter publicadores, aprovadores e administradores diferentes. c) Cada seção de um mesmo tipo de conteúdo possa ter um fluxo de aprovação diferente. Permitir que seções sejam associadas a áreas do portal para sua publicação, de modo que: a) A hierarquia de seções corresponda à estrutura de áreas do portal. b) Ao copiar uma área do portal que possui uma seção de conteúdo, uma nova seção do mesmo tipo de conteúdo seja criada automaticamente e associada à nova área. c) Ao remover uma área do portal, as seções de conteúdo associadas possam ser removidas automaticamente. d) Seja possível mover as seções de conteúdo entre áreas do portal. e) Seja possível visualizar em uma área do portal seções de conteúdo associadas a outras áreas. Permitir que o publicador selecione no próprio formulário de publicação em quais seções o conteúdo deve ser publicado. Para selecionar as seções, o usuário deve poder visualizar as áreas do portal a que cada seção está associada. Permitir o agendamento de publicação e definição de período e/ou data de expiração do conteúdo. Permitir o upload de arquivos em lote. Permitir a definição de marcadores em conteúdo HTML de modo a tornar dinâmica a atualização de informações estáticas. Página 18

XVIII. XIX. XX. XXI. XXII. Possuir mecanismo de conversão automática de arquivos publicados (imagens, vídeos, áudio, etc.) para formatos de conteúdo padronizados garantindo sua correta apresentação nos diferentes dispositivos de consulta. Oferecer recursos para implementação dos seguintes mecanismos de navegação: a) Menu Estático: Posicionam-se nas partes superior e/ou laterais de forma estática e podem conter um ou mais links para áreas específicas do portal. b) Menu Dinâmico: posicionam-se nas partes superior e/ou laterais e podem alterar de acordo com a área específica que está sendo mostrada. c) Links Rápidos: posicionam-se em todas as paginas do portal é são utilizados para possibilitar acesso rápido em recursos como busca, login/logoff, contato, ajuda e página inicial. d) Menu Mouse-over: recurso aplicado em menu estático e dinâmico que possibilita a navegação em hierarquia de menu somente através do movimento do mouse sobre os itens. e) Combo-Box: caixas de seleção de itens para acesso rápido à áreas específicas e/ou informações disponibilizadas no portal. f) Caminho de Páginas ( menu de migalhas ): usuários podem localizar-se e navegar dentro das páginas do portal, através da exibição do caminho percorrido ate determinado ponto. g) Mapa do Site: visualização da estrutura de páginas / funcionalidades / informações disponibilizadas pelo portal. Permitir a criação de uma área do portal para administração de conteúdo, que seja acessível apenas aos usuários que têm permissões para gerenciar conteúdo. Permitir que da área de administração de conteúdo, seja definida de forma totalmente customizada de modo que: a) A navegação da área de administração possa ser definida de acordo com os requisitos dos publicadores. b) O layout da área de administração possa ser criado de acordo com o padrão visual dos portais gerenciados. Permitir que conteúdos de qualquer tipo possam ser associados a um determinado conteúdo para que apareçam como uma lista do tipo veja também quando o usuário final visualiza este conteúdo. Página 19

XXIII. XXIV. XXV. XXVI. XXVII. XXVIII. XXIX. XXX. XXXI. XXXII. XXXIII. XXXIV. Oferecer capacidade de versionamento de conteúdo, permitindo retornar a uma versão anterior. Permitir a edição de conteúdos que já estejam publicados e sua posterior visualização, gerando uma nova versão que somente estará disponível para consulta no portal após a publicação da nova versão. Permitir que conteúdos em arquivos possam ser anexados a conteúdos publicados na ferramenta. Possuir repositórios de imagens que permitam aos usuários publicadores gerenciarem e organizarem as imagens que podem ser acrescentadas aos conteúdos: a) Imagens a ser acrescentadas a um conteúdo são carregadas para o repositório diretamente do computador do usuário publicador. b) Imagens podem ser organizadas no repositório em pastas. Mais de um repositório de imagens pode ser definido, sendo que cada repositório pode ter permissões de leitura e escrita diferentes. Possuir recurso de fluxo de aprovação para que determinados perfis de usuários tenham que aprovar um conteúdo publicado por outros usuários antes que este seja efetivamente publicado. O sistema de fluxo de aprovação deve: Permitir que o número de passos de aprovação seja definido para cada fluxo. Permitir a definição dos perfis de usuários que podem aprovar em cada passo. Poder enviar notificações por e-mail automaticamente quando um usuário recebe um conteúdo para aprovar ou fazer outra ação no fluxo e aprovação. Permitir a definição de um tempo máximo que um conteúdo deve ficar em um determinado estágio antes que o sistema faça alguma ação automática. Permitir a associação de um fluxo de aprovação diferente a cada seção de cada tipo de conteúdo. Possuir recursos para publicação dos seguintes tipos de conteúdo, sem que seja necessário criar tipos de conteúdo novos ou fazer novos desenvolvimentos: a. Notícias: cadastro de notícias por assunto que poderão ser disponibilizadas no portal e também permitirá a formatação e envio de newsletter aos endereços de e-mail previamente Página 20

XXXV. cadastrados para determinados assuntos. Disponibilizar interface para as pessoas cadastrarem seus e-mails em determinado assunto. b. Calendário de Eventos: cadastro de eventos (incluir, alterar e excluir). Os eventos cadastrados serão disponibilizados ao público permitindo navegação pelos meses e anos e mostrando os dias destacados em calendários. Também deverá haver chamada para a sugestão de eventos: Para os usuários da Intranet, deverá ser disponibilizado um formulário para sugerir inclusão de eventos cujas informações preenchidas deverão ser remetidas para um endereço de e-mail previamente informado. c. Links: cadastro de URL s com título e descrição. d. Documentos: cadastro de documentos para serem disponibilizados para download com título e descrição. e. Perguntas mais frequêntes: cadastro de perguntas e respostas por assunto. f. Mural de recados: manutenção e exibição de mensagens enviadas pelos usuários. Permite que usuários enviem comentários em determinadas páginas. Os comentários devem ser aprovados por um moderador antes de serem publicados. g. Clipping: disponibilizar notícias coletadas em mídia impressa. Contém um cadastro de notícias (incluir, alterar e excluir). Cada notícia possui data e imagem (imagem escaneada de jornais, revistas e outras mídias impressas). As notícias cadastradas serão disponibilizadas ao público permitindo navegação pelas datas. Ao acessar as notícias, a imagem associada deve ser mostrada na própria página (sem necessidade de dowload / abrir). h. Formulários com armazenamento e envio por e-mail: disponibilizar formulários em determinadas páginas contendo campos de diversos tipos para preenchimento e envio. Após o envio, de acordo com sua configuração, as informações devem ser armazenadas para consulta posterior e/ou enviadas por e- mail para um ou mais endereços associados ao formulário. A consulta às informações armazenadas deverá ser restrita a um usuário ou grupo de usuários associados ao formulário. Permitir a publicação de conteúdos em diferentes idiomas de modo que: Página 21

XXXVI. XXXVII. XXXVIII. XXXIX. XL. XLI. XLII. XLIII. a) O usuário final possa escolher o idioma no qual deseja navegar e o portal apresente os conteúdos no idioma apropriado. b) Não seja necessário gerenciar várias estruturas dos portais para cada idioma. c) Seja possível ao administrador definir previamente quais conteúdos são suportados por seus portais. Permitir que os administradores de conteúdo possam visualizar como os conteúdos aparecem nas páginas do portal antes da sua efetiva publicação. O recurso deve permitir ao usuário visualizar o conteúdo da forma que irá aparecer em cada página do portal onde possa ser publicado, com o layout específico daquela página. A visualização deve incluir todos os elementos de cada página onde o conteúdo é apresentado de forma a permitir uma avaliação completa do contexto em que o conteúdo será incluído. Caso hajam páginas com layout criado para dispositivos móveis, simular a visualização do conteúdo neste tipo de dispositivo. Possuir uma etapa de verificação automática da adequação do conteúdo publicado a requisitos de acessibilidade sempre que um conteúdo é criado ou alterado. Permitir a publicação de seções de conteúdo no formato RSS. Oferecer recursos para que os usuários colaborarem em torno dos conteúdos publicados, permitindo: a) Usuários comentarem conteúdos publicados, caso habilitado. b) Usuários atribuírem notas ou conceitos aos conteúdos publicados (classificação de relevância). Permitir a definição de modelos de malas diretas por e-mail a ser enviadas regularmente aos usuários de modo que: a) Todo o padrão visual do e-mail possa ser previamente definido da mesma forma que é definido o layout das páginas do portal. b) A cada envio, os administradores do sistema podem criar os conteúdos otimizando os recursos disponíveis para publicação de conteúdos no portal. c) A cada envio, os administradores podem escolher os perfis de usuários para quem o e-mail será enviado. Página 22

XLIV. XLV. Possuir solução para envio de e-mails automáticos que notifiquem usuários sobre novos conteúdos disponíveis, permitindo que: a) Usuários finais possam definir quais assuntos de conteúdo gostariam de acompanhar. b) A ferramenta envie um e-mail periodicamente com os novos conteúdos publicados dentro dos interesses indicados pelo usuário. c) A periodicidade deste envio seja configurável. Possuir recurso capaz de importar conteúdos externos, tais como MS Office, PDF e XML e demais que existam na arquitetura tecnológica da TERRACAP, para a publicação através da solução de gestão de conteúdo, permitindo: 6.10. Colaboração: a) Definir as regras de conversão do formato original para o formato padrão da Ferramenta/Plataforma. b) Suporte a múltiplos formatos de conteúdos externos. c) Definir mais de um mecanismo para acesso ao conteúdo externo, oferecendo suporte a, no mínimo, dois mecanismos: FTP e acesso a Web Services. d) Que o conteúdo externo seja publicado automaticamente. e) Que o conteúdo externo seja inserido em um fluxo de aprovação. f) Que o conteúdo externo seja acrescentado a uma lista de conteúdos para que um administrador possa decidir sobre sua publicação ou não. I. Permitir a criação de comunidades virtuais para a disseminação e compartilhamento de informações entre os colaboradores internos por meio do uso dos recursos da ferramenta, como a disponibilização de arquivos (biblioteca de documentos), fóruns de discussão, blogs, wikis, etc. II. a) Deve haver uma configuração que defina se a criação das comunidades deverá ser uma prerrogativa apenas dos usuários administradores ou aberta para criação por qualquer usuário interno. b) As comunidades poderão ter o conteúdo publicado disponibilizado livremente ou ser moderada por um grupo de usuários.. Possuir Perfil de usuário: recurso que ofereça a possibilidade da livre criação de perfis dos usuários na área restrita, que deverá dispor de Página 23

III. IV. recursos para armazenar, administrar e compartilhar informações pessoais, tais como: Nome, foto, formação acadêmica, interesses, habilidades, entre outros. Possuir Fórum de discussão que permita: a) Ser utilizado por usuários autenticados. b) Ter ou não um moderador que aprove cada post antes deste ser publicado. c) A criação de diversos assuntos e categorias de mensagens. d) Permitir ao moderador ou administrador fechar uma discussão definindo uma resposta indicada como a correta ou inserindo uma conclusão. Possuir recurso de Chat corporativo que permita: a) Realizar reuniões online em tempo real. b) Armazenar as mensagens publicadas gravando um histórico da conversa para que seja possível consultar posteriormente. c) Ser utilizado por usuários autenticados. d) Agendar uma data e hora em que uma sala de chat estará disponível para uma reunião ou evento. e) Agendar uma data de término de uma reunião online. V. Possuir recurso de Questionário (exames/provas) que permita: a) Ser utilizado por usuários autenticados. b) Poder definir o percentual mínimo de acerto de questões para aprovação no exame. c) Poder cadastrar número ilimitado de questões para cada exame. d) As questões poderão ser de respostas subjetivas (abertas) com campo texto para descrição da resposta, ou objetiva (fechadas) com campos para de múltipla escolha ou de escolha única. e) Os exames podem ser apresentados como Exercício sem persistir as respostas do usuário, ou como Prova persistindo as respostas do usuário. f) Exames apresentados como Exercício devem poder ser utilizados em páginas com cache html sem necessidade de acessar o banco de dados. g) O usuário poderá conferir seu boletim pessoal para cada exame realizado, mesmo que o usuário seja um visitante. Página 24

VI. VII. VIII. IX. h) O Boletim do Exame deverá trazer pelo menos o percentual mínimo para aprovação, número de questões do exame, o número de questões respondidas, o número de respostas corretas, e se o usuário foi aprovado ou não no exame seguido do percentual de acerto. Possuir recurso para criação e administração de Enquetes, sem que seja necessária qualquer programação para utilizá-lo. Possuir recurso para criação e administração de Blogs, sem que seja necessária qualquer programação para utilizá-lo. Possuir recurso para criação e administração de Wikis, sem que seja necessária qualquer programação para utilizá-lo. Possuir recurso para criação e administração de recursos Multimídias, que deverá compreender pelo menos fotos, vídeos e áudio, sem que seja necessária qualquer programação para utilizá-lo. 6.11. Busca: a) Deverá existir a possibilidade de agrupamento dos conteúdos por assunto (pastas) e inserir legendas e comentários. b) Deve ser possível visualizar as fotos em miniaturas. I. Permitir que o mecanismo de busca nativo da Ferramenta/Plataforma possa ser substituído por um mecanismo de busca appliance externo de propriedade e uso da TERRACAP sem perda das capacidades da busca. II. Permitir ao administrador configurar, sem a necessidade de conhecimentos de programação, que a Ferramenta/Plataforma deve gerar automaticamente arquivos que auxiliem as ferramentas de busca externas a indexação dos conteúdos do portal. III. Permitir ao administrador configurar, sem a necessidade de conhecimentos de programação, que a Ferramenta/Plataforma deve gerar automaticamente arquivo que indique aos mecanismos de busca externos quais áreas e subáreas podem ser indexadas e com qual periodicidade. Restringir a busca aos conteúdos que estejam áreas e suas subáreas indicadas para não serem indexadas pelo mecanismo de busca externo à Ferramenta/Plataforma. IV. Permitir que administradores especifiquem quais componentes do portal devem ter seus conteúdos indexados pelo mecanismo de busca. V. Permitir o armazenamento e a publicação de qualquer tipo de conteúdo digital (imagens, arquivos textos, planilhas de cálculos, áudio, vídeo etc.) e indexar documentos publicados com anexos. Página 25