wiki:NovoExpresso/dvs

Version 4 (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.
RepresentanteJosé Sarto
DS/COSCC/CCPLI

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.
RepresentanteGuilherme Funchal
DS/COSCC/CCPEV""

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.
RepresentanteGlênio Villela Pereira
SUPDE/DEPAE

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.
RepresentanteMarcos Martins Melo
DS/COSCC