Recomendações para o desenvolvimento de WbIS

WbIS transacionais, porém, justamente por ser um modelo de ciclo de vida, ela descreve apenas as principais fases e atividades do desenvolvimento [DORF97]. As sub-atividades e tarefas que constituem cada atividade da espiral também são fatores importantes para o sucesso do desenvolvimento e, nesse sentido, algumas das sub-atividades do desenvolvimento do CNCT revelaram um conjunto de pontos críticos, que devem ser avaliados cuidadosamente no desenvolvimento de WbIS similares.

A seguir, esses pontos de risco são descritos, em conjunto com recomendações para os problemas mais comuns, gerando uma espécie de checklist de aspectos que devem ser avaliados no desenvolvimento de WbIS.

Escolha da Tecnologia e plataforma de desenvolvimento

As tecnologias usadas no e para o desenvolvimento de WbIS ainda são muito recentes e instáveis. Assim, sejam quais forem as opções escolhidas, suas limitações devem ser exploradas no início do ciclo de vida, na fase de prototipação, quando ainda é possível trocar a tecnologia escolhida sem grandes custos adicionais para o desenvolvimento. Com relação a esse ponto, ressalta-se a importância das linguagens escolhidas e dos testes realizados com o protótipo.

Considerando o estado atual das tecnologias e padrões da Web, clientes portáveis podem ser implementados apenas com HTML, JavaScript ou Java. Porém, Java e JavaScript não são realmente portáveis, pois suas implementações apresentam pequenas diferenças de um navegador para outro e também entre diferentes versões de um mesmo navegador. Embora essas diferenças possam ser contornadas, isso não é uma tarefa fácil, como discutimos no próximo tópico. Java também apresenta problemas com relação a velocidade de acesso, não sendo indicada em sistemas que precisem ter grande facilidade de acesso para todos os usuários.

HTML foi criada para elaborar hipertextos e apresenta grandes limitações para a construção de interfaces gráficas complexas. É possível que novos desenvolvimentos, como XML [KHAR97; CONN98] ou DHTML [LIEWH] resolvam ou minorem esse problema, mas não há indícios seguros de que tal fatoocorrerá. A solução aparentemente correta ainda é usar uma linguagem de programação “verdadeira” no desenvolvimento da interface e, resolvidos os problemas de portabilidade e bandwidth, Java é a mais séria candidata a tal posto.

Enquanto isso, é preciso avaliar as características do sistema e seus usuários, pesando portabilidade e facilidade de acesso, para decidir qual a melhor opção. Nessa decisão há que se levar em conta também as ferramentas disponíveis para o desenvolvimento e a facilidade para conseguir recursos humanos com experiência no uso das tecnologias envolvidas.

É preciso, também, validar a tecnologia escolhida, verificando se ela realmente atende aos requisitos do projeto. O ideal é testar o protótipo em todas as combinações de diferentes navegadores, monitores e condições de acesso à Internet dos usuários do sistema, entretanto, dado o grande número de usuários e de opções envolvidas, essa alternativa normalmente é impossível. Assim, é preciso achar um ponto de equilíbrio entre o custo de testar a tecnologia usada e a diminuição do risco de encontrar problemas de performance e portabilidade posteriormente. É recomendável que os testes sejam feitos, pelo menos, no subconjunto de navegadores mais usados

e nas piores condições de acesso à rede – linha discada, com modem de 28.8 kbps, provedores de média velocidade e clientes (navegadores) de 640 por 480 pixels.

Custo da portabilidade

Mesmo trabalhando com as linguagens portáveis da Internet, como Java e JavaScript, não é raro encontrar pequenas diferenças nas suas implementações de navegador para navegador. Como as linguagens são muito recentes, ainda existem diferenças consideráveis entre suas últimas versões e, de acordo com a versão que um navegador implementa, ele responderá ou não aos recursos mais avançados (novas funções, novos tipos de dados, etc.) de cada linguagem. Para agravar o problema, não existe uma boa documentação sobre as particularidades dos diferentes navegadores, com relação à implementação dessas linguagens.

Durante o desenvolvimento, é preciso definir que tipo de abordagem adotar:

• privilegiar a portabilidade, optando por não usar os recursos mais avançados das linguagens e dedicando tempo e esforços para contornar as diferenças de implementação dos navegadores;

• definir uma linguagem, fabricante e versão básica de navegador e utilizá-los como padrão, o que diminui os custos de implementação e teste, mas restringe o uso do sistema.

A decisão deve levar em conta o custo do projeto, o perfil dos usuários do sistema e sua potencial expansão. A solução mais comum é adotar um subconjunto de navegadores mais usados e implementar o sistema de modo que ele funcione bem nesse subconjunto, disponibilizando para os usuários informações a respeito de quais são os navegadores “compatíveis” com o sistema e como consegui-los.

Como não existe documentação completa, correta e atual sobre as particularidades das linguagens usadas para implementar a interface do cliente em diferentes navegadores, é recomendável que a equipe mantenha um registro dos problemas encontrados (e soluções dadas) durante o desenvolvimento do sistema, como por exemplo, funções e tipos de dados não portáveis, bugs dos navegadores, etc.

Aplicações off-line

Segundo [NIEL98], pelo menos nos próximos 5 anos a grande maioria dos usuários da Web estará ligada à rede através de conexões demasiadamente lentas (modems de 28.8 kbps). Enquanto a infra-estrutura da Internet ainda está em formação, é preciso analisar se a velocidade e custo das conexões de rede não representam um empecilho ao uso de interfaces mais complexas, como as que são usadas para inserção e manipulação de muitos dados. Nesse caso, o desenvolvimento de interfaces off-line pode ser uma boa solução.

Além de contar com ambientes e ferramentas que facilitam o desenvolvimento de interfaces gráficas complexas, as aplicações off-line possibilitam rapidez e independência aos usuários, que podem inserir e modificar dados sem ter que estar conectados a Internet todo o tempo. Normalmente, a interação com interfaces off-line é bem mais rápida que a interação com interfaces on-line, porque evita os problemas inerentes ao uso da Web, como lentidão no acesso, linhas de comunicação congestionadas, servidores fora do ar, “ruído” nas linhas de comunicação telefônica, etc. Além disso, elas podem representar economia de custo para os usuários que conectam-se à Web através de um provedor de acesso, pagando pelos impulsos da ligação telefônica e pelo tempo de acesso.

Apesar das vantagens, a adoção de uma interface off-line acrescenta um certo grau de complexidade ao sistema, tanto para o seu desenvolvimento, quanto para o próprio uso do sistema.

As aplicações off-line precisam ser transferidas do servidor e instaladas na máquina cliente, o que quebra a simplicidade de uso dos WbIS e representa dificuldades para usuários leigos no uso de computadores, que estão acostumados apenas ao uso da interface relativamente padrão dos navegadores. Além disso, as aplicações off-line são dependentes de plataforma, dado que normalmente são implementadas com linguagens de programação pouco portáveis. Isso faz com que tenha que ser implementada uma versão para cada uma das plataformas de interesse ou que ela só seja implementada para uma determinada plataforma.

O processo de evolução do sistema também torna-se mais difícil, pois o controle de versões e manutenção das aplicações off-line é complexo, dado que cada vez que é realizada uma otimização ou gerada uma nova versão é preciso notificar aos usuários que, por sua vez, têm que fazer um novo download da aplicação. Isso pode ser mais comprometedor quando existem tanto versões off-line como on-line da mesma aplicação, já que se não forem criados mecanismos de

controle, a consistência dos dados pode ser afetada. Além disso, o download da interface off-line pode ser muito demorado, pois elas concentram as funcionalidades do sistema em apenas um arquivo executável. Esses problemas podem ser minimizados através da adoção de mecanismos como os descritos por [MDOC97], porém, a complexidade adicionada ao sistema ainda requer uma avaliação cuidadosa dos custos e requisitos envolvidos no projeto antes que se adote uma interface off-line.

De maneira geral, a adoção de interfaces off-line deve ser considerada quando:

• é preciso assegurar o acesso ao sistema por todos os usuários, independentemente de suas condições de acesso à Internet, como ocorreu com o CNCT;

• existe uma grande quantidade de informações a manipular nas interfaces de inserção e atualização de dados;

• a inserção e atualização de dados fica a cargo de um grupo restrito e conhecido de usuários (nesse caso, é possível que a inserção/atualização seja feita só pela interface off-

line, ficando a interface on-line responsável apenas pela consulta às informações).

Se for decidido que será implementada uma interface off-line, os critérios para a seleção da linguagem a ser utilizada envolvem a existência de ambientes de desenvolvimento que facilitem a construção de interfaces com o usuário, o fornecimento de bibliotecas que dêem suporte à interação com SGBDs e com os protocolos da Internet e a experiência da equipe de desenvolvimento.

Uma forte candidata à implementação de aplicações off-line é a linguagem Delphi, dada a facilidade que essa linguagem fornece para prototipação rápida e a grande quantidade de componentes reusáveis disponíveis no mercado. Contudo, outras linguagens como Visual Basic e Java também podem ser utilizadas.

O uso de Java pode vir a ser a melhor alternativa quando há uma interface on-line também desenvolvida nessa linguagem, dado que não seria necessário quase que duplicar o tempo investido na programação e manutenção de duas versões. Porém, na prática se percebe uma carência de ambientes de trabalho suficientemente completos para dar suporte ao desenvolvimento de aplicações em Java, em comparação com as linguagens acima mencionadas, além de um problema mais grave e já mencionado de incompatibilidade entre clientes.

Contratação de Web designers

Como mostramos na seção 6.1, a interface gráfica de WbIS não segue as mesmas regras do projeto de interface de outros sistemas de informação, requisitando o trabalho de um profissional que possua conhecimentos:

• de programação visual, sendo capaz de passar mensagens rapidamente e agradavelmente aos usuários do sistema, através dos elementos gráficos tradicionais (imagens, cores, fontes, etc.);

• de construção e compactação de imagens, de modo que possa deixá-las o mais “leve” possível e compreensíveis mesmo em monitores de baixa resolução e que suportem um conjunto pequeno de cores;

• do modelo navegacional e tecnologias da Web, para poder estruturar a informação em hipertextos de forma adequada e saber o que é e o que não é possível implementar com as tecnologias existentes atualmente.

Esse profissional tem sido chamado de Web designer e é imprescindível no desenvolvimento de grandes WbIS.

Expansão do número de usuários

As características da Web tornam possível um grande aumento do número de usuários (e consequentemente dos dados manipulados) de WbIS em espaços de tempo relativamente curtos. Assim, é recomendável que se identifique possíveis “gargalos” do sistema antecipadamente e que o projeto seja feito considerando a possibilidade de expansão do sistema. [RUDI97] apresenta algumas técnicas para construir sistemas escaláveis, que podem ser aplicadas ao desenvolvimento de WbIS.

Treinamento constante

A evolução e modificação das tecnologias e ferramentas usadas no desenvolvimento de WbIS é extremamente rápida e requer uma atualização constante de conhecimentos. Assim, é recomendável que se invista no treinamento e reciclagem da equipe, tanto para possibilitar melhorias nos produtos desenvolvidos, quanto para aumentar a produtividade do processo.