Version 11 (modified by iolaneandrade, 7 meses atrás) (diff)

--

ATENÇÃO: Fora de uso

Avaliação - Saal

Pasta de Projeto do Sistema de Apoio a Administração Legislativa - Artefatos Gerenciais

TODO LIST SAAL

TarefaResponsávelData Lim.Status
Delimitar escopoMorale, Rodolfo......
Avaliar arquiteturasCiciliati, Jean, Wilton06/08...
Relacionar possíveis formas de contrataçãoRodolfo, Morale......

DELIMITAR ESCOPO

Definição:

  • A partir da especificação elaborada, selecionar o menor conjunto possível de funcionalidades que farão parte da versão 1.0 do SAAL.

Observações:

AVALIAR ARQUITETURAS

Definição:

  • Avaliar as arquiteturas: Archetypes, ERP5 e ZPT+PythonScript??+SGDB (estilo SAPL), Zope3, visando selecionar a mais adequada para implementação do SAAL.

Observações:

Deve ser escolhida uma rotina simples que consta da especificação para benchmark das arquiteturas.

  • Considerar arquiteruras que privilegiem a manutenção do sistema pelas comunidades Interlegis e Software Livre.
  • Sugestão do Jean para análise posterior - codificar em língua inglesa - facilita a integração com comunidades de outros países

Resultados:

CaracteristicasFuncionaisDoSaal

CriteriosParaAvaliacaoDasArquiteturasSaal

RELACIONAR POSSÍVEIS FORMAS DE CONTRATAÇÃO

Definição:

  • Definição: Elaborar um relatório demonstrativo das possíveis formas de contratação do serviço de implementação do SAAL.

Observações:

  • Pesquisar com possíveis fornecedores (empresas, comunidade, CEFET, UFMG, Async, ...)
  • Qual o objeto da contratação para cada forma?

CARACTERISTICAS FUNCIONAIS DO SAAL

Dados:Dados:

  • Além de dados cadastrais, grande necessidade de tratamento de dados numéricos em operações de consolidação de valores;
  • Em dados não cadastrais, necessidade de efetuar controle de transações;
  • Existem dados confidenciais;

Segurança:

  • Controlar acesso ao sistema, via interface, por perfil de usuário;
  • Realizar segmentação horizontal de dados para controle de diferentes níveis de acesso;
  • Impedir acesso direto às bases de dados;
  • Manter logs de acesso e de transações;
  • Dedicar especial atenção à prevenção de fraudes;

Interface com o usuário:

  • Via web, rodando em browsers para Windows e Linux;
  • Capacidade de edição em tabelas e/ou telas com múltiplos registros;

Relatórios:

  • Emissão de relatórios pré-formatados de grande volume;
  • Facilidade para a criação e a customização de relatórios adicionais.

Back-end:

  • Rotina de upgrade pela rede
  • Alguns módulos são de missão crítica.
  • Além de dados cadastrais, grande necessidade de tratamento de dados numé...

Critérios para Avaliação das Arquiteturas

Critérios:

1. Interface WEB:

  • Archetypes: sim. Funcionalidade nativa.
  • Zope Puro: sim. Funcionalidade nativa.
  • ERP5: sim. Funcionalidade nativa.
  • Zope 3: sim. Funcionalidade nativa.

2. Facilidade de criação/geração de interfaces:

  • Archetypes: sim. Todas as interfaces são geradas dinamicamente de acordo com as definições do schema de cada classe.
  • Zope Puro: +/-. Para a geração automática é necessário o uso de produtos Zope adicionais, como o Formulator (apenas framework), o ZetaDB? (framework e gerador), e outros geradores e frameworks. No entanto, todos os geradores encontrados estão em versão alfa ou beta.
  • ERP5: não. Interfaces não são geradas automaticamente, o formulator é usado para produção rápida. Existe um módulo de RAD ainda em avaliação.
  • Zope 3: sim. As interfaces são geradas automaticamente com base no schema ou customizadas.

3. Possibilidade de interoperabilidade entre os módulos, e com outros sistemas:

  • Archetypes: sim. Possui forte enlace com o CMF/Plone, mas tudo é desenvolvido em FS e os dados são armazenados no ZODB ou em BDR através de mapeamento de campos.
  • Zope Puro: sim. A interoperabilidade pode se dar por diversos meios: SGBD, XML-RPC, chamada de métodos via HTTP, e por todos os outros meios nativos do Zope.
  • ERP5: sim. Construído sobre o CMF, possivelmente integrável com Plone.
  • Zope 3: não. Ainda está em fase experimental e ainda existem funcionalidades indisponíveis.

4. Facilidade para a criação e a customização de relatórios:

  • Archetypes: +/-. Os relatórios poderão ser gerados através módulos ou aplicações que extraem dados diretamente do BDR ou do catálogo do Plone, mas não possui funcionalidade nativa de geração de relatórios.
  • Zope Puro: vide Archetypes.
  • ERP5: não.
  • Zope 3: +/-. Da mesma maneira que o AT, o Zope 3 traz SQLStorage? integrado ao mecanismo de schemas. Nativamente ainda não possui softwares para geração de relatórios.

5. Workflow-aware:

  • Archetypes: sim. Funcionalidade nativa através do workflow que o Plone usar, normalmente o DCWorkflow?.
  • Zope Puro: +/-. A implementação de WF é possível com o uso do DCWorkflow?, do Openflow ou de outros produtos Zope. No entanto, a aplicação resultante terá que conter código específico para a operação do engine de WF.
  • ERP5: sim. DCWorkflow?.
  • Zope 3: sim. Possui workflow nativo, mas suas regras devem ser definidas.

6. Tolerância a uma arquitetura híbrida:

  • Archetypes: sim. Possibilita a escolha individual de cada campo que é armazenado em BDR ou no ZODB, permite a catalogação desses campos, independente de base de dados. Pode interagir com outras aplicações ou módulos através de FS ou outros Produtos para Zope/CMF.
  • Zope Puro: sim.
  • ERP5: sim. Veja avaliação Archetypes.
  • Zope 3: sim. O mesmo que Archetypes.

7. Tipo de repositório de dados (SGBDR, OO, etc...). Considerar segurança, integridade e performance:

  • Archetypes: sim. Os objetos ficam persistidos no ZODB, com a possibilidade de armazenamento de cada campo, ou campos escolhidos aleatoriamente, em BDR. Utiliza a máquina de segurança do Zope para cada objeto. Cada objeto fica linkado com sua tupla relativa no BDR, quando apagar o objeto, a tupla é apagada. A performance é um pouco prejudicada em decorrência das várias camadas, AT->Plone->CMF->Zope->Python.
  • Zope Puro: flexivel. Diversas arquiteturas são possíveis: Desde soluções tradicionais, com todos os dados em BDR, até soluções totalmente orientadas a objeto. Existem diversas opções de produtos para a persistência de objetos em BDRs?.
  • ERP5: sim. Objetos ficam armazenados no ZODB e se desejado também no BDR.
  • Zope 3: sim. Objetos são persistidos no ZODB com seus campos armazenados em BDR. Mecanismo de segurança nativo. Incremento considerável de performance.

8. Controle de acesso / segurança:

  • Archetypes: sim. Funcionalidade nativa do Zope e conseqüentemente do AT. As regras de acessos são ditadas pelo workflow atrelado ao objeto.
  • Zope Puro: sim. Mecanismo nativo.
  • ERP5: sim. Mecanismo do Zope.
  • Zope 3: sim. Mecanismo nativo.

9. Plataforma: Estabilidade / Evolução / Envolvimento da Comunidade:

  • Archetypes: sim. Quase inevitavelmente utilizará a plataforma Plone, que está em estado bastante estável, o AT 1.2.5, que acompanha atualmente o Plone não está muito estável, e sua versão 1.3, já bastante modificada, ainda não está em release final, mas já está bem mais robusta e recebendo em massa o esforço da comunidade. O novo Plone 2.1 utilizará o AT 1.3 como base de todos os seus objetos nativos, fato que atesta a evolução do framework e o comprometimento da comunidade.
  • Zope Puro: +/-. A plataforma Zope é bastante estável e madura. No entanto, para melhor produtividade no desenvolvimento, seria necessário o uso de produtos e de add-ons que não teriam o mesmo grau de maturidade.
  • ERP5: +/-. A plataforma não está estável ainda, possui problemas de instalação e de operações básicas. Está evoluindo lentamente, porque possui uma comunidade bastante restrita. A comunidade brasileira está envolvida no desenvolvimento de ferramentas para o ERP5 e não na codificação do núcleo do sistema, e almejam a partir de 2005 ter condições de implantar um projeto piloto no Brasil.
  • Zope 3: sim. A plataforma está em versão experimental beta, a comunidade acredita que chegará à versão final em um ano. Até lá haverá um esforço de compatibilização entre Zope 2 e Zope 3, começando agora pelo Five e encurtando caminho com as próximas versões do Zope 2, que deverão rumar ao Zope 3. Existe uma aplicação conhecida rodando em Zope 3 hoje, assunto que é polêmico entre a comunidade pois os módulos desenvolvidos são poucos perto da grande quantidade de módulos existentes hoje para Zope 2.

10. Nível de complexidade da arquitetura para a absorção pela equipe e pela comunidade:

  • Archetypes: sim. A proposta do AT é justamente abstrair complexidade de desenvolvimento e maximizar a produtividade. Seu modelo baseado em schemas proporciona rápido aprendizado mesmo tendo o desenvolvimento baseado em FS, o que é poderoso por não oferecer limitações.
  • Zope Puro: Complexidade baixa, se a arquitetura da aplicação for bem definida.
  • ERP5: +/-. Utiliza como base o CMF que já é um framework conhecido, mas implementa algumas ferramentas e conceitos novos, usa schema como base, mas o schema não é tão funcional como o Archetypes ou Zope 3, mas mais maleável, o módulo desenvolvido fica com mais cara de Python. O framework é poderoso, mas um pouco bagunçado, e existe pouca documentação.
  • Zope 3: sim. A proposta é evoluir o Zope 2 com as funcionalidades do Zope 3, para que os desenvolvedos absorvam os novos conceitos sem muito trauma. O novo Z3 é muito mais organizado, personalizável, poderoso, e sua API proporciona mais facilidade para o desenvolvimento de novos conteúdos ou módulos.

11. Internacionalização: de Interface (externa) / de Código (interna):

  • Archetypes: sim. Funcionalidade nativa utilizando o mecanismo de internacionalização do Plone. No código pode-se pendurar tags de tradução i18n para cada string do schema e nos templates de interface são usados atributos de tag i18n para traduzir qualquer elemento.
  • Zope Puro:
  • ERP5: sim. Usando Localizer, possivelmente com novas versões do CMF passe a utilizar PlaceLessTranslationService??.
  • Zope 3:sim. Suporte nativo. O processo é parecido com o Archetypes pendurando tags i18n em ZPT, DTML, ZCML e em código Python, mais organizado.

12. Impacto / sobrevivência com a chegada do Zope3:

  • Archetypes: +/-. O Zope 3 é um misto de Zope 2+CMF+Plone+AT. O Plone vai ser adaptado transparentemente à plataforma Zope 3, mas sobre o AT a comunidade ainda não conhece a resposta. Possivelmente as funcionalidades do AT serão absorvidas pelo Z3+Plone e o AT somente mascarará um nível de funcionalidade que o Z3 não apresentará perante o AT. Uma alternativa, pensando-se em futuro e evolução, é o desenvolvimento utilizando-se integrado Five+AT+Plone, e no futuro fazer alguma migração (explorando o máximo do Five, de forma a ficar quase transparente). O Five é um produto Zope que permite usar tecnologias Zope 3 no Zope 2.
  • Zope Puro: ??? É difícil fazer algum prognóstico.
  • ERP5: +/-. Será afetado como o Plone+AT, pois o CMF, que é sua base, deixará de existir. A adaptação talvez seja mais lenta devido a sua comunidade ser bastante reduzida em relação a comunidade AT+Plone.
  • Zope 3: sim. Migração das aplicações atuais para a nova plataforma. Muitas não serão compatíveis.

13. Ferramentas para apoio ao desenvolvimento:

  • Archetypes: sim. ArchGenXML?, geração automática de código Archetypes a partir de um modelo UML XMI (.xmi, .zargo, .zuml) ou XSD, gerado com ferramentas como ArgoUML?, Poseidon, Object Domain?, Power Designer?.
  • Zope Puro:
  • ERP5: +/-. Não existe o conceito de ferramenta e sim um gerador de código (RAD) onde diversos componentes de código são gerados pelo ERP, automaticamente na inicialização do novo tipo de conteúdo.
  • Zope 3: não. Ainda não há esforço de desenvolvimento dessas ferramentas.

14. Capacidade de automação do desenvolvimento:

  • Archetypes: sim. Pode ser gerado automaticamente a maior parte do código fonte da aplicação, restando apenas os refinamentos do sistema manualmente.
  • Zope Puro: sim. Depende da arquitetura definida. Seria necessário o desenvolvimento de ferramentas/scripts para essa automação.
  • ERP5: sim. Parte do código pode ser gerado automaticamente.
  • Zope 3: não. Hoje ainda não.

15. Capacidade de customização:

  • Archetypes: +/-. Nativamente está bastante entrelaçado com o Plone, que é extensivamente customizável, mas suas interfaces geradas automaticamente possuem particularidades de customização limitadas.
  • Zope Puro: sim. Capacidade de customização plena.
  • ERP5: sim. Por ser um framework montado a partir do CMF puro, a capacidade de customização é bastante alta.
  • Zope 3: sim. Altamente customizável, inclusive com sua interface mais adequada para ser usada pelo usuário final e tb pode ser adaptada.

16. Facilidade para a especificação e para o controle da terceirização:

  • Archetypes: +/-. Como os módulos do sistema podem ser gerados a partir da especificação, esta deve ser minunciosa, além de ter que prever os relacionamentos no BDR e a estrutura de objetos no ZODB. A especificação tanto para terceirização quanto para desenvolvimento interno deve ser rigorosa e criteriosa.
  • Zope Puro: +/-. Depende da arquitetura da aplicação.
  • ERP5: +/-. A especificação passa por características comuns a aplicações Zope/CMF, onde esta arquitetura exerce certa influência defido a organização de objetos, mas o armazenamento em BDR é padrão. Está sendo treinada uma equipe da Campos Developer para fornecer suporte comercial para futuras implantações. O suporte comercial é condição para que o ERP5 acompanhe a distribuição Conectiva Linux, o que é almejado pelo projeto.
  • Zope 3: não. Especificar um sistema para o Zope 3 é bastante parecido com especificar para Zope 2, e ainda mais fácil devido a sua API muito mais organizada e rica, mas a terceirização hoje é limitadíssima, não existem empresas hoje no país que comportariam isso.

Veja ProjetoSaal

 

The contents and data of this website are published under license:
Creative Commons 4.0 Brasil - Atribuir Fonte - Compartilhar Igual.