sábado, 18 de julho de 2009

Automa Framework - ASP.NET 1.1

Automa Framework ASP.NET 1.1







De Março até Julho de 2009 coordenei uma equipe de desenvolvimento Web que estava com problemas sérios de produtividade utilizando um Framework Web da empresa Automa Ltda.







O Diretor da empresa Automa, desenvolveu um framework baseado no Framework ASP.NET 1.1 que rodava em cima do Visual Studio 2003 com SP1.

Introdução






Para criar um aplicativo, era necessário:







1) criar todas as tabelas no banco de dados.



2) Abrir um editor de propriedades e cadastrar "Entidades" que deveriam ser mapeadas em Tabelas físicas do banco de dados.


Abaixo uma imagem do editor de propriedades.


3) Vincular cada coluna do banco de dados a estas propriedades (o processo era ágil utilizando uma ferramente de importação)


4) Apos este processo, o sistema possui um cadastro de menus onde eram adicionadas item navegáveis.






Após feito este processo era só rodar a aplicação web, e vc tinha todos as telas de cadastros para iniciar o processo de cadastros simples, cadastros mestre detalhe.


Este processo super rápido atendia perfeitamente o processo de cadastros de seus aplicativos internos.


Customização de Regras de Negócio

O controle do Layout da tela era feito via ferramenta chamada "Project Designer" que se trata de um editor de propriedades básicas para construção de sistemas.

Neste editor você podia Definir:

Nome da Entidade = Nome da Entidade (Tabela do Banco de Dados)
Fonte de dados para Consultas = Informações para Tela de Lista
Consultas Especiais = Pesquisa especiais, com parâmetros filtros, ordenação
Edição de Registros = Tela de Edição do Registro do banco de Dados
Botões Customizados = Botões Customizados de tela de Edição (não funcionava)
Eventos Form consulta = Eventos para customizar a tela de consulta
Eventos Form Edição = Eventos para customizar a tela de edição.

Falta de documentação

Apenas de ser uma ferramenta altamente customizável, por falta de documentação e exemplos os programadores menos experientes sentiam-se desconfortáveis em realizar muita customização visual e gráfica de telas via código C#.

Eu trabalhei construindo um módulo de Controle Estatístico de Processo (C.E.P) onde atravessei muitos problemas técnicos esbarrando em limites técnicos da ferramenta, onde a mesma se mostrou incabada em alguns pontos.

Mesmo assim utilizando a experiência que tenho, entreguei o módulo extendendo partes da Framework em .NET 3.5 e usando um componentes de Relatorios Report Server que venho construído a alguns anos.

Deixei minha contrubuição para este framework concertando muitos problemas de segurança e erros internos e deixando exemplos maduros de códigos profissionais.

Baixa produtividade

Apesar do framework ser voltado para cadastros e consultas, a solução de relatórios não existia. Os programadores ficavam horas e horas utilizando uma integração com Office usando Macros no Word e Excel e indicadores para exportar dados. (péssimo)

A baixa produtividade dava-se porque 80% do tempo era gasto em requisitos não estáveis, não havia escopo nos relatorios levantados e a falta de entendimento da regra de negócio era evidente.

A falta de documentação de análise envolveu muito o processo. Não havia como paralalelizar as atividades e nem estimar prazos pois e escopo do projetos era muito "aberto".

Resumindo: Apenas o programadores Analistas se sobressaiam graças ao seu esforço pessoal.

Deploy em produção, controle de versão

Os aplicativos eram compilados em modo DEBUG e os fontes eram enviados para produção.

Desta forma exposta todos os fontes da empresa.

Atualização da Framework

A framework não se baseava em objetos e sim em eventos e querys SQL construídas nas proprias customizações. A solução era razoável para utilizar na construção de aplicativos e protótipos simples. Mas sistemas complexos exigiram maior esforço.

Sugestão.

Migrar a plataforma para DevExpress com XPO e XAF, pois a solução da Dev atenderia a empresa, além da sua vasta documentação. A Automa é uma empresa que comercializa o AutoLab e não consegue acompanhar a tecnologia Web na velocidade que ela exige.

Lições aprendidas:

Todos framework exige uma documentação

Todo framework exige exemplos reais

Todo framework exige casos de sucesso.

Todo framework exige treinamento

Custa menos comprar um framework estável , renovável do que desenvolver um.

Utilizar soluções de mercado são melhores que do que "improvisar uma"

Postar um comentário