relatorioR4.md 26.6 KB

RELATÓRIO DA RELEASE 4

Ações programadas para a Release 4, de acordo com o plano de trabalho:

  • Estudos de Evolução de plataforma integrada de colaboração
  • Protótipo de Ferramenta de Redes Sociais
    • Evolução do Núcleo Portal
    • Avalia SPB
    • Mercado Público
    • Subportais
  • Estudos de Evolução de plataforma de Integração
  • Estudos sobre Proxy de integração
  • Estudos sobre o sistema de Indexação de Buscas
  • Estudos sobre sistema de Ranking (gameficação)
  • Estudos sobre a evolução de serviço de Chat
  • Estudos sobre a Evolução do Sistema de Lista de e-mails
  • Estudos sobre a evolução de PAD colaborativo
  • Estudos sobre a Evolução de camada de back end (SO, plugin, integração)
  • Estudos sobre a Evolução do Sistema de Controle de Versão
    • Evolução de ferramentas de controle de versão
    • Evolução de ferramentas forge
    • Evolução de ambiente de monitoramento de métricas de código-fonte
  • Estudos Avançados sobre Migração
  • Estudos sobre documentação e comunicação multimídia do projeto
  • Estudos Avançados sobre a Evolução do Sistema de Identidade Visual
  • Estudos Avançados sobre a Evolução da estrutura de IHC
  • Estudos Avançados sobre a Evolução da Arquitetura da Informação
  • Estudos sobre a Evolução da superfície da interface gráfica do portal
  • Estudos para validação e análise dos protótipos com usuários
  • Estudos sobre licenças de software livre

Alinhamento Estratégico

Em reunião, realizada dia 13 de maio de 2015, com o comitê estratégico do projeto, liderado pelo diretor da DEGSI, Wagner Ribeiro, foram definidas as seguintes metas estratégicas para a release:

  • Alcançar maior número de Cidadãos
  • Disseminar o Software Não Público na APF
  • Quantificar economia (em R$) por parte do Governo com o uso do SPB

Nesta reunião foi explanado pelo diretor Wagner Ribeiro que uma das principais metas para o ano de 2015, em relação ao projeto, é disseminar e disponibilizar a plataforma do portal do software público (SPB) para o maior número possível de órgãos e entidades da Administração Público Federal. Para tanto essa meta compreende, no que diz respeito a plataforma do SPB, as funcionalidades relacionadas ao software não-público, até então nominado de software de governo. Um e-mail com ata da reunião foi enviado aos participantes (e está anexo a este relatório).

Com tais metas definidas em nível estratégico, as analistas da DEGSI/SLTI, Marisa Santos e Nayanne Bonifácio, juntamente com todo o time da UnB, estiveram reunidos no dia 18 de maio, onde foi realizado o planejamento desta release. Nesse sentido, a partir das metas estratégicas foram definidas as seguintes "épicas" para organizarmos as histórias de usuários e tarefas, conforme a metodologia apresentada no plano de trabalho do projeto:

  • Negócio
    • Disponibilizar Software de Governo
    • Migrar/Desligar Portal SPB Atual
    • Relato de Uso de Software
  • Técnicas
    • Integração de Perfis de Comunidades
    • Implantação da Release 4
    • Dívida Técnica
  • Não-Técnicas
    • Realizar Estudos de Licenças (minuta de alteração da IN01)
    • Treinamento/Suporte/Governança
    • Lançamento da campanha SPB (ASCOM) [Atribuição da SLTI e DTI]

Fase de Execução

Estudos de evolução de plataforma integrada de colaboração

Esta macro atividade, em relação a release 4, esteve associada a duas épicas. A primeira épica está detalhada a seguir:

  • Disponibilizar Software de Governo para o maior número possível de entidades da Administração Pública Federal.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Criar Página de Software de Governo: proposta de Design
  • Modificar Filtro do Catálogo de Software
  • Disponibilizar o SEI na plataforma
  • Evoluir o catálogo de software para adicionar software de governo

A seguir é descrita a outra épica envolvida nesta macro atividade durante a release 4:

  • Relato de Uso de Software para proporcionar uma interação dos gestores, líderes de comunidades e usuários que poderão compartilhar suas experiências com o software, bem como estimativas de pessoas impactadas e valores economizados.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Projeto do Relato de Uso
  • Envio de Relatos
  • Criação de avaliação para comunidades
  • Visualização de Relatos Simplificado
  • Moderação de Relatos e Notificação
  • Contador de Relatos
  • Criação de bloco de estatística/métricas de software

Estudos de Evolução de plataforma de Integração

Esta macro atividade, em relação a release 4, esteve associada as seguintes épicas:

  • Disponibilizar Software de Governo para o maior número possível de entidades da Administração Pública Federal.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Definir Entidade de Comunidade:
  • Definir Mecanismo de Controle de Grupos para Plugins do Colab
  • Definir Protocolos de Comunicação entre Ferramentas
  • Implementar Modelo de Dados do Noosfero no Colab

As evoluções decorrentes dessa macro atividade foram acompanhadas pelas evoluções das ferramentas utilizadas no Portal, como Noosfero, GitLab e Mezuro, como apoiam a evolução futura da indexação de buscas na plataforma de integração, uma vez que os modelos de dados das ferramentas já estão representadas na plataforma, o que permitirá a evolução do Colab para um barramento de camada de aplicação.

Estudos Avançados sobre Migração

Durante a release 3, realizamos um estudo de avaliação, com interações para alinhamentos com as analistas da DEGSI/SLTI, que resultou em um parecer técnico enviado a DESGI/SLTI com as recomendações para migração de conteúdos, bem como os motivos para a sugestão de recadastramento por parte dos usuários do antigo portal que desejam usar a nova plataforma do SPB.

Assim, a partir do detalhamento da épica Migrar/Desligar Portal SPB Atual, decidiu-se que na release 4 seriam migrados os conteúdos de Blogs e Fóruns do antigo portal. Portanto, as seguintes atividades relacionadas à migração dos conteúdos das comunidades existentes no antigo portal do SPB foram realizadas:

  • Migrar Comunidades
  • Verificação de Migração e Templates
  • Migração de Conteúdos (Fóruns e Blogs)

Após testes realizados em ambientes de Desenvolvimento e Homologação, a migração dos conteúdos foi realizada no ambiente de produção no dia 10 de setembro de 2015 com sucesso.

Documentação e comunicação multimídia do projeto

Esta macro atividade, em relação a release 4, esteve associada a seguinte épica:

  • Lançamento da campanha SPB (via ASCOM) para aumentar a publicidade de notícias relacionadas a plataforma

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes atividades:

  • Cadastrar 70 softwares no catálogo
  • Mudar o DNS de beta para portal.softwarepublico.gov.br
  • Notificar usuários
  • Implantar R3 no ambiente de produção
  • Mudar o DNS de portal para softwarepublico.gov.br

As tarefas relacionadas a esta macro atividade, durante a Release 4, foram prioritariamente realizadas pela equipe da DEGSI/SLTI.

A equipe da UnB realizou uma atividade de mentoring executando a atividade de implantação da release 3 nos ambientes do MP, transferindo conhecimento para a equipe da DTI/MP.

Estudos Avançados sobre a Evolução do Sistema de Identidade Visual

A identidade visual do Portal evoluiu em diferentes áreas. Novos elementos gráficos e estilos foram criados, implementados e validados. Destacam-se os seguintes itens:

  • Design e estruturação do Relato de uso
  • Evolução visual e estruturação do Bloco de Métricas nas páginas de softwares
  • Reestruturação dos arquivos e regras de CSS do tema
  • Aplicação de estilos nas páginas principal e internas das Comunidades
  • Evolução visual dos Cadastros de Software e Comunidade
  • Design e estruturação de janelas “Tooltip” e “Popover” para o Portal
  • Revisão de classes e HTML para blocos do plugin SPB
  • Refatoração do CSS para plugins SPB
  • Elaboração e formatação para o Mapa do Site
  • Revisão e validação visual das áreas implementadas para versão de lançamento

Algumas funcionalidades foram adicionadas ao longo da Release 4, por solicitação do Ministério do Planejamento. São elas:

  • Criação e aplicação do design para área “notificações” localizada na página inicial do Portal
  • Criação e aplicação do design para área “Veja também” localizada na página inicial do Portal
  • Modificação visual dos filtros na página interna Catálogo de Softwares

Durante a etapa final da Release 4, foi informado a necessidade de padronização do cabeçalho e rodapé de acordo com o manual proposto pela SECOM. Ambos os elementos foram estruturados no visual padrão solicitado, levando em consideração as peculiaridades do Portal.

A evolução do Sistema de Identidade Visual foi apresentada aos gestores do Ministério do Planejamento em reuniões periódicas.

Com a solicitação de itens extras, os estudos e prototipação do AvaliaSPB foi retirada da Release 4, conforme entendimento com a DEGSI/SLTI.

Estudos Avançados sobre a Evolução da estrutura de IHC

Esta macro atividade, em relação a Release 4, esteve associada as seguintes épicas:

  • Evoluir a experiência de usuário da área aberta do portal para que os visitantes percebam o SPB como um único ambiente.
  • Disponibilizar o Software de Governo para o maior número possível de entidades da Administração Pública Federal.

A partir do detalhamento da referida épica, foram desenvolvidas as seguintes funcionalidades:

  • Evolução dos filtros na página interna Catálogo de Softwares
  • Evolução da Página de Software
  • Prototipação da Página Software de Governo
  • Prototipação das páginas associadas ao Relato de uso
  • Prototipação UX do bloco “Notificações” na página inicial
  • Prototipação UX do bloco “Veja também” na página inicial
  • Levantamento das funcionalidades atuais do portal
  • Levantamento das funcionalidades do Mezuro
  • Prototipação inicial para unificação do Painel de Controle

Estudos Avançados sobre a Evolução da Arquitetura da Informação

Durante a release 4, consolidaram-se as decisões de arquitetura da informação tomadas na release anterior, sem modificações de estrutura.

Estudos para validação e análise dos protótipos com usuários

A validação e análise ocorre por etapas, aonde membros da equipe, gestores do Ministério do Planejamento e usuários relatam suas impressões e experiências de uso no Portal.

Estudos sobre licenças de software livre

Foi empreendida análise do parecer jurídico contratado e o subsequente desenvolvimento de respostas referentes às questões jurídicas do licenciamento de software, englobando os requisitos jurídicos para licenciamento de software livre, normas e leis tocantes à contratação de softwares e ao aprimoramento de software, a existência de jurisprudência em casos de infração de direitos autorais em combinações com GPL e a possibilidade legal de duplo licenciamento de softwares.

Foi realizada também análise quantitativa das respostas objetivas e análise textual de dados provenientes de consulta à comunidade interessada por meio do participa.br, que forneceu insumo para a extração de diversas conclusões, indicando, principalmente, que a comunidade envolvida tem preferência à aceitação de mais modelos livres de licença no Portal do SPB.

Benefícios alcançados

Gerenciamento de tarefas do projeto na própria plataforma

O desenvolvimento e gerenciamento da Release 4 foi todo realizado dentro do próprio Portal do Software Público Brasileiro, onde utilizou-se o Gitlab como a principal ferramenta de gerenciamento de atividades e documentação. Utilizou-se os recursos integrados aos grupos e repositórios do Gitlab para apoiar o fluxo organizacional já estabelecido na Release 3, mantendo-se os níveis estratégico, tático e operacional.

Neste sentido, o principal meio de documentação e comunicação, tanto no nível estratégico quanto tático, se tornou a Wiki do Gitlab que está presente dentro do principal repositório de desenvolvimento do projeto. A proposta utilizada consiste de um conjunto de páginas Wiki que seguem a seguinte estrutura:

  • Release X: Página com os detalhes da release onde são apresentadas todas as épicas, suas funcionalidades e histórias de usuários. O backlog, ou seja, o escopo da release está listado nessa página.
    • Cronograma/Agenda: Página onde estão descritas as datas de reuniões e cerimônias que acontecem ao longo de uma Release.
    • Sprint N: Página com a documentação da Sprint N onde estão mapeadas todas as histórias de usuários que foram planejadas. Cada sprint possui sua própria página onde pode-se ter uma descrição dos objetivos principais da sprint, assim como a lista de links para as histórias de usuários.

Além disso, a Wiki é utilizada para documentar, entre outras coisas, os procedimentos da equipe de desenvolvimento e contribuições para os softwares envolvidos.

No nível operacional, são utilizadas as ferramentas issues (tíquetes) e milestones (marcos) do Gitlab. Para cada história de usuário criou-se uma milestone com título, descrição e pontuação (estimativa). Dentro de cada história de usuário é criado um conjunto de issues descrevendo as tarefas que devem ser feitas para o desenvolvimento completo de uma história de usuário. Desse forma, para cada história de usuário, o Gitlab fornece um kanban onde os desenvolvedores assumem tarefas e modificam seu status. Essa visualização ainda apresenta uma barra de progresso representando o quanto de um história já está finalizado.

Ambiente de monitoramento de Código-Fonte

Durante a release 4, além da correção de defeitos encontrados, foram adicionados à plataforma Mezuro novos coletores para que sejam extraídas métricas de Python e Ruby. Além disso, os principais passos já foram dados para integrar a plataforma ao Portal do SPB, através da plataforma de integração Colab.

Portanto, durante a release 4, a plataforma Mezuro foi evoluída para suportar a tecnologia de autenticação única utilizada pelo Portal do SPB, possibilitando o desenvolvimento do plugin de integração do Mezuro com o Colab. Para complementar a integração básica da plataforma, também já foi projetado e desenvolvido a integração visual inicial necessária para unificação da experiência do usuário, bem como a importação de dados inicial do Mezuro para a plataforma integradora Colab.

Os últimos passos remanescentes para a integração inicial do Mezuro no SPB estão relacionados ao processo de instalação da plataforma, como o empacotamento da ferramenta e de suas dependências. Com esses passos de instalação concluídos, o foco do desenvolvimento será no suporte à linguagem PHP que é utilizada por muitos projetos que compõe o Portal do SPB.

A integração do Mezuro no portal do SPB viabilizará a coleta, monitoramento e interpretação da qualidade interna dos produtos de softwares disponíveis na plataforma. Essas informações serão subsídios para ranqueamento e classificação dos softwares disponibilizados no portal.

Separação do catálogo de software de governo

Nesta release houve a evolução da experiência do usuário quanto a busca por software. Para possibilitar ao usuário distinguir e filtrar o resultado do software buscado no escopo de Software Público e/ou Software de Governo, separou-se o catálogo de Software Público dos demais com uma opção de filtro por tipo. Este filtro permite ao usuário obter a lista de todos os softwares ou apenas de softwares classificados como Públicos.

Os softwares conhecidos como software de governo passaram a ser encontrados a partir do bloco de destaque de software não-publico, ficando disponível na homepage do portal. Este bloco, identifica e esclarece ao usuário o que são estes softwares e direciona o usuário ao catálogo de softwares apenas não-públicos de maneira simples e direta.

Migração/Desativação da operação do antigo portal do software público

Durante a release 4, todos os softwares públicos restantes foram criados dentro da nova plataforma. Posteriormente, as permissões de escrita no portal antigo foram extintas para a realização da migração dos conteúdos de Blogs (notícias) e Fóruns (dúvidas e discussões) do antigo portal foram migrados, via scripts de automação, para as respectivas comunidades, no ambiente de produção, com sucesso.

Ao fim da release 4, na sexta-feira dia 04 de setembro de 2015, aconteceu o lançamento oficial do Novo Portal do Software Público Brasileiro que foi acompanhado de uma campanha de comunicação em revistas e rádios que fomentam a utilização da nova plataforma do sítio. O chaveamento para o novo portal foi marcado pela troca para o domínio definitivo do portal: softwarepublico.gov.br

Minuta de alteração da IN01

Desenvolveu-se a minuta da nova Instrução Normativa, concentrando esforços na flexibilização do esquema de licenciamento. A redação foi adaptada também para o tratamento adequado do "software de governo". Também visou-se facilitar e incentivar a oferta de softwares no portal, desburocratizando a disponibilização de software no SPB por meio da retirada da obrigatoriedade de registro no INPI e da flexibilização em relação à indicação de coordenador(es) para as comunidades.

Automação das rotinas de implantação nos ambientes do MP

A evolução das rotinas e procedimento de implantação da plataforma nos ambientes do Ministério do Planejamento foi um dos principais benefícios obtidos como resultado da release 4. Dada a complexidade dos serviços e softwares envolvidos no Portal do SPB, uma nova sub-equipe foi composta para evoluir e amadurecer os procedimentos de implantação do projeto através da aplicação de técnicas de DevOps.

Essa evolução consistiu do empacotamento dos softwares e suas dependências para a plataforma utilizada nos servidores do Ministério (CENTOS 7), evolução da ferramenta para gerenciamento das diferentes máquinas e ambientes existentes (chake) e das receitas chef para a configuração dos serviços em cada máquina. Adicionalmente, os manuais de instalação e manutenção do portal foram melhorados e detalhados com o objetivo de tornar os procedimentos de manutenção do portal reprodutíveis por outras equipes, como a DTI/MP.

Implantação em ambientes de Desenvolvimento, Homologação e Produção

Foram criados 3 ambientes na infraestrutura da DTI:

  • Ambiente de desenvolvimento para que a equipe de desenvolvimento realize testes de novas funcionalidades ou de correções em um ambiente gerenciado pela DTI, replicando de fato o ambiente que existe em produção;
  • Ambiente de homologação, de modo que uma vez aprovadas pela equipe de desenvolvimento, as alterações realizadas no Portal do Software Público possam então ser homologadas pela equipe do Ministério. Este ambiente é gerenciado pelo próprio ministério;
  • Ambiente de produção, onde o Portal do Software Público é entregue para os usuários finais.

Todos os ambientes acima são gerenciados pelo SERPRO e se encontram em uma mesma nuvem, de modo que os ambientes de desenvolvimento e homologação possuem, inicialmente, as mesmas configurações de software que o ambiente de produção. Isto é importante para prevenção de imprevistos relacionados a configurações diversas, como por exemplo, regras de firewall.

Para garantir que as configurações de software permaneçam as mesmas, todas as alterações realizadas em qualquer um dos servidores são feitas com o uso de técnicas de entrega contínua, através do uso de receitas Chef (técnica avançada que permite sempre replicar uma série de passos), de modo que as mesmas receitas são executadas em cada um dos ambientes.

Dificuldades encontradas

Absorção das rotinas de automação e implantação por parte do MP

Os ambientes de Desenvolvimento, Homologação e Produção configurados e mantidos no MP são de responsabilidade da Diretoria de Tecnologia da Informação-DTI. Esta por sua vez possui, atualmente, contrato de terceirização com o fornecedor Central Tecnologia, Serviços e Comercio de Informática LTDA-Central TI, que é responsável pela execução das demandas da DTI. Durante os períodos de implantação de novas versões da plataforma nesses diferentes ambientes, a equipe da UnB se deslocou ao MP, executou as instalações presencialmente, com participação dos líderes técnicos remotamente, onde os procedimentos técnicos eram acompanhados pelas equipes da DTI e Central TI. Todos os procedimentos realizados foram automatizados e documentados, de forma que o manual de instalação/operação da plataforma foi atualizado. Em que pese a equipe da UnB tenha mantido atualizado o manual de instalação/operação, além de realizar a transferência de tecnologia para realização de tais procedimentos, ainda há uma forte dependência da equipe da equipe da UnB, por parte do MP, para execução desse tipo de atividade.

Monitoramento e intervenção técnica no ambiente de produção

Como forma de viabilizar as intervenções da equipe da UnB no ambiente de produção, com vistas à investigação de defeitos materializados neste ambiente, foi definido, por parte do MP, um procedimento para tal, uma vez que a equipe da UnB só possui permissão de acesso ao ambiente de desenvolvimento.

A extração dos logs foi automatizada no repositório de gerência de configuração do SPB, mas como a equipe da UnB não tem acesso ao sistema de produção, é necessário abrir um chamado para a DTI extrair os logs e copiá-los para uma localização temporária no ambiente de desenvolvimento.

Avaliamos que este procedimento não está adequado pelos seguintes pontos:

  • O tempo de resposta da DTI para as solicitações é demasiado alto. Se os logs solicitados não estiveram corretos -- como já ocorreu, de recebermos logs do mês anteiror ao que foi solicitado -- o tempo de resposta para obtermos a informação correta é ainda pior.
  • O acesso apenas aos logs de forma estática, sem acesso a informações "ao vivo" do sistema é menos efetivo para identificação e resolução de problemas.
  • Devido à dependência com relação à equipe da UnB relatada no item anterior, na prática até o momento a mesma teve que fazer todas as intervenções necessárias para identificações de gargalos e resolução de problemas no ambiente de produção.

Tempo despendido com a atividade de empacotamento

O empacotamento é uma atividade que tem como base um pacote contendo o código-fonte original de um projeto de software e tem como objetivo preparar pacotes binários (instaladores) para que o software possa ser instalado facilmente por diversos usuários finais de um sistemas. O empacotamento inclui, mas não está limitado, às seguinte atividades:

  • integração com serviços (e.g. servidores de aplicação) do sistema para que possam ser gerenciados utilizando as ferramenta padrão do sistema operacional;
  • gerenciamento de dependências, de forma que todos os pacotes necessários para o funcionamento de plataforma sejam instalados automaticamente em conjunto com os componentes principais;
  • integração de forma sustentável de customizações específicas do Portal do Software Público Brasileiro;
  • gerenciamento de atualizações, de forma que a instalação de uma nova versão seja feita corretamente na presença de uma versão anterior, e que o processo seja executado corretamente sem intervenção manual.

Esta atividade traz grandes benefícios aos usuários finais, uma vez que ao ser finalizada torna-se muito simples a instalação. Contudo, tal descomplicação envolve um certo custo na etapa de desenvolvimento. Como na release 4 tivemos uma nova composição do time de DevOps (responsável direto por tal atividade), a equipe teve uma certa difuculdade para superar a curva de aprendizado natural que envolve está etapa.

Outro fator importante que influência em tal atividade é a dependência da mesma com as demais equipes, uma vez que o processo de empacotamento advém diretamente da finalização de todas as atividades por parte de todos os times. Além disto, ao se finalizar um pacote é preciso retornar para a equipe interessada no mesmo e realizar um ostensivo trabalho de testes visando assegurar a qualidade sobre o mesmo.

Aumento contínuo de escopo e atrasos nos feedbacks da migração

Apesar do estudo e das especificações feitas previamente com o levantamento das necessidades e viabilidades do processo de migração, em inúmeros momentos tais especificações tiveram seu escopo expandido por novas demandas. Outra falha que trouxe um impacto negativo na execução da migração foram os diversos atrasos no feedback e validação de cada etapa por parte do MP. Ambos os problemas forçaram a execução de novos desenvolvimentos e correções sem tempo hábil para os devidos testes e validações. As consequências disso foram comprometimento do cronograma e a perda da qualidade geral da entrega final.

Dificuldade de acesso aos ambientes de homologação e produção para a migração

Por conta da dificuldade de acesso aos ambientes de homologação e produção para a realização tanto da preparação como do processo de migração em si, foi necessária a implementação de mecanismos muito mais complexos que garantissem a replicação criteriosa dos ambientes reais em um ambiente externo desacoplado para contornar problemas relativos à diferença desses ambientes. Essa dificuldade de acesso também prejudicou a realização de testes de estabilidade do sistema pós-migração.

Custos Incididos na Release 4

Total dos Custos

Durante esta release só houve execução financeira da rubrica 33.90.20, bolsas à pesquisadores, representando na prática que o orçamento foi consumido apenas na categoria mão-de-obra. Como não houve sensibilização financeira nas demais rubricas, a categoria outras despesas é apresentada vem valores monetários. Na coluna valor executado, é possível obervar o custo da mão-de-obra, divido pelas equipes do projeto.

TO-DO: explicar os itens da tabela (Paulo)

Custos Diretos(Bolsas) por Módulo/Equipe

Neste gráfico é possível observar a representação do percentual do custo da mão-de-obra incidido em cada equipe do projeto.

TO-DO: explicar os itens ilustrados nos gráfico (Paulo)

Anexos

TO-DO