| | 1 | '''Documento de Visão do Sistema''' |
| | 2 | |
| | 3 | '''1. Objetivo''' |
| | 4 | |
| | 5 | 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. |
| | 6 | 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. |
| | 7 | O Documento de Visão do Sistema documenta as necessidades e funcionalidades do sistema. |
| | 8 | |
| | 9 | '''2. Descrição do Produto''' |
| | 10 | |
| | 11 | 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. |
| | 12 | 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. |
| | 13 | |
| | 14 | O NOVO EXPRESSO procura resolver os seguintes problemas em relação a arquitetura e versão atual: |
| | 15 | |
| | 16 | - Estrutura tecnológica baseada em API idealizada em 2000, com defasagem tecnológica; |
| | 17 | - Baseado em outra realidade de internet; |
| | 18 | - Baseado fortemente no conceito de processamento no Server; |
| | 19 | - Avanço em funcionalidades que incompatibilizaram upgrade de versão em comunidade internacional; |
| | 20 | - Forte acoplamento das camadas, causando grande impacto na manutenção; |
| | 21 | - API não disponibiliza desacoplamento da Aplicação, resultando em esforço para integração; |
| | 22 | - Módulos desenvolvidos por equipes independentes sem requisitos de unidade de estruturas físicas ou reutilização de classes; |
| | 23 | - 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; |
| | 24 | - A comunidade egroupware incorporou o conceito do etemplate para tratamento das interfaces com usuários na tentativa de resolver vulnerabilidades; |
| | 25 | - Bugs, que ao passar do tempo são reintroduzidos; |
| | 26 | - Foi reimplementado do Egroupware considerando premissas antigas; |
| | 27 | - As permissões baseadas nas classes/tabela guardam permissões misturadas de difícil manipulação; |
| | 28 | - 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. |
| | 29 | - Codebase interno construído ficou muito difícil para mantê-lo e estendê-lo de um modo econômico. |
| | 30 | - Os conceitos como "testes de unidade" são possíveis, porque as classes foram atadas a muito uma a outra. |
| | 31 | - 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. |
| | 32 | - 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; |
| | 33 | - A reimplementação sempre esbarra em premissas antigas, recaindo no mesmo erro; |
| | 34 | - 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. |
| | 35 | - Falta manejo de timezone próprio. O eGroupWare não tem nenhum tratamento sobre timezones. |
| | 36 | - Toda manutenção é impactante em função da estrutura construída com o passar dos tempos; |
| | 37 | |
| | 38 | |
| | 39 | 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: |
| | 40 | |
| | 41 | - Baixo custo para desenvolvimento e manutenção. |
| | 42 | - Segurança considerada como requisito principal. |
| | 43 | - Funcionalidades continuadas da versão anterior. |
| | 44 | - Orientação a serviços. |
| | 45 | - Utilização de Framework sedimentado no mercado. |
| | 46 | - Separação absoluta das camadas MVC. |
| | 47 | - Interface padronizada de acesso para os diversos módulos. |
| | 48 | |
| | 49 | 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. |
| | 50 | |
| | 51 | 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. |
| | 52 | |
| | 53 | '''3. Envolvimento''' |
| | 54 | |
| | 55 | '''3.1. Abrangência''' |
| | 56 | 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. |
| | 57 | O projeto visa substituir a solução atual mantendo as funcionalidades existentes. |
| | 58 | |
