wiki:NovoExpresso/dvs

Version 5 (modified by cesar.vianna, 13 years ago) (diff)

--

Documento de Visão do Sistema

1. Objetivo

O propósito deste documento é coletar, analisar e definir as necessidades de alto-nível e características do sistema, focando nas potencialidades requeridas pelos afetados e usuários-alvo, e como estes requisitos foram abordados no sistema. A visão do sistema documenta o ambiente geral de processos desenvolvidos para o sistema, fornecendo a todos os envolvidos uma descrição compreensível deste e suas macro-funcionalidades. O Documento de Visão do Sistema documenta as necessidades e funcionalidades do sistema.

2. Descrição do Produto

O NOVO EXPRESSO será um sistema de comunicação contemplando os principais elementos para comunicação corporativa, baseado nas funcionalidades existentes no atual expresso, porém baseado em nova estrutura tecnológica, novo design gráfico e nova arquitetura baseada na orientação a serviços, voltando-se para suportar ambientes de nuvem. O NOVO EXPRESSO combinará em uma única interface todas as características essenciais para uma colaboração eficaz e no desenvolvimento de processos de negócios. Para as empresas, instituições públicas, associações ou particulares o NOVO EXPRESSO simplificará a comunicação interna e a coordenação e gestão de tarefas, compromissos, contatos e recursos incorporando requisitos fundamentais como facilidade de uso, estabilidade e segurança são indispensáveis. Um processo de desenvolvimento orientado a testes com extensa auditoria de código deve ser utilizado para que qualidade do trabalho transpareça.

O NOVO EXPRESSO procura resolver os seguintes problemas em relação a arquitetura e versão atual:

  • Estrutura tecnológica baseada em API idealizada em 2000, com defasagem tecnológica;
  • Baseado em outra realidade de internet;
  • Baseado fortemente no conceito de processamento no Server;
  • Avanço em funcionalidades que incompatibilizaram upgrade de versão em comunidade internacional;
  • Forte acoplamento das camadas, causando grande impacto na manutenção;
  • API não disponibiliza desacoplamento da Aplicação, resultando em esforço para integração;
  • Módulos desenvolvidos por equipes independentes sem requisitos de unidade de estruturas físicas ou reutilização de classes;
  • Segurança ficou gravemente prejudicada em função do não acompanhamento da comunidade maior ou de framework que absorvesse na época estas correções;
  • A comunidade egroupware incorporou o conceito do etemplate para tratamento das interfaces com usuários na tentativa de resolver vulnerabilidades;
  • Bugs, que ao passar do tempo são reintroduzidos;
  • Foi reimplementado do Egroupware considerando premissas antigas;
  • As permissões baseadas nas classes/tabela guardam permissões misturadas de difícil manipulação;
  • Seu Framework é desconhecido pela maioria dos desenvolvedores PHP, assim como o seu criador Egroupware, em consequencia há necessidade de especialização para domínio da API que suporta a solução.
  • Codebase interno construído ficou muito difícil para mantê-lo e estendê-lo de um modo econômico.
  • Os conceitos como "testes de unidade" são possíveis, porque as classes foram atadas a muito uma a outra.
  • O eTemplate inspeciona qualquer dado recebido do lado de cliente. Ele sabe que dados ele envia ao cliente e ele sabe que dados esperar de volta do cliente.
  • 90% do tempo gasto para gerar o conteúdo de HTML necessário pelo framework eGroupWare e eTemplate. A lógica de aplicação , toma só 10 % do tempo gasto;
  • A reimplementação sempre esbarra em premissas antigas, recaindo no mesmo erro;
  • A mesma classe/tabela guarda os direitos que o usuário pode usar que aplicações, que membro de usuário do qual grupo e que usuários realmente compartilham que dados.
  • Falta manejo de timezone próprio. O eGroupWare não tem nenhum tratamento sobre timezones.
  • Toda manutenção é impactante em função da estrutura construída com o passar dos tempos;

Para análise e construção deste novo sistema, houve prospecção no sentido de solucionar as questões mencionadas acima. Dentre as várias alternativas de evolução os seguintes fatores básicos foram requeridos:

  • Baixo custo para desenvolvimento e manutenção.
  • Segurança considerada como requisito principal.
  • Funcionalidades continuadas da versão anterior.
  • Orientação a serviços.
  • Utilização de Framework sedimentado no mercado.
  • Separação absoluta das camadas MVC.
  • Interface padronizada de acesso para os diversos módulos.

Após uma etapa de prospecção optou-se pela utilização do codebase do software TINE20(www.tine.org), em função deste cobrir todos os requisitos enumerados e elencados junto a Comunidade Expresso.

Portanto este documento prevê a utilização do codebase TINE20, agregando-se as funcionalidades existentes no expresso bem como características adicionais com suporte a ambientes em nuvem.

3. Envolvimento

3.1. Abrangência O expresso hoje tem sua maior representação na comunidade expresso (www.expressolivre.org), sua difusão engloba não somente o Serpro e seus clientes, mas uma gama enorme de empresas e entidades públicas espalhadas em todo o território nacional com a diferença que para seus clientes o Serpro provê a manutenção do produto contratualmente enquanto que para os demais a comunidade disponibiliza o software sob licença livre. O projeto visa substituir a solução atual mantendo as funcionalidades existentes.

3.2. Papel das Partes Interessadas

3.2.1. Cliente

DescriçãoParte interessada que demandará as necessidados do projeto.
Papel no desenvolvimentoDefinir o serviço que essa solução busca satisfazer.
Fornecer informações quanto ao uso e suas necessidades com relação ao sistema.
Insumos ao projeto de softwareRequisitos do sistema para atender a necessidade dos clientes internos e da comunidade.
Requisitos não-funcionais, como performance, usabilidade da interface gráfica, etc.
Representante

3.2.2. Gestor

DescriçãoParte interessada responsável pelo sistema no SERPRO
Papel no desenvolvimentoDefinir as necessidades a serem atendidas pelo sistema.
Definir o escopo das entregas.
Estabelecer as funcionalidades requeridas e restrições operacionais.
Identificar juntamente com o analista os requisitos do sistema, funcionais e não-funcionais.
Homologação das implementações
Insumos ao projeto de softwareNecessidades dos usuários (incluindo os externos).
Solicitação de Alteração de Requisitos.
Requisitos Funcionais.
Restrições de negócio.
Representante

3.2.3. Gestor de Desenvolvimento

DescriçãoPapel responsável pela liderança e supervisão do projeto no nível alto da organização
Papel no desenvolvimentoProver recursos para viabilizar e garantir a melhoria contínua do projeto. Gerenciamento técnico / administrativo e acompanhamento do projeto como um todo.
Insumos ao projeto de softwareRecursos humanos e tecnológicos.
Representante

3.2.4. Gestor Sênior

DescriçãoPapel responsável pela liderança e supervisão do projeto no nível alto da organização
Papel no desenvolvimentoContratar do serviço que essa solução busca satisfazer.
Determinar direcionarmento estratégico do projeto.
Insumos ao projeto de softwareDiretrizes organizacionais e estratégicas.
Representante