Uma proposta de processo de produção de aplicações Web

A proposal for Web application production process

Uma proposta de processo de produção de aplicações Web

A proposal for Web application production process

Rodrigo Franco Gonçalves; Vagner Luiz Gava; Marcelo Schneck de Paula Pessôa; Mauro de Mesquita Spinola

Escola Politécnica da USP

RESUMO

Este artigo investiga aspectos característicos da produção de software para ambiente Web. É feito um estudo de caso visando entender como se dá a produção de aplicações Web com elevado grau de interatividade com o usuário e funcionalidade complexa. Os resultados do estudo de caso são confrontados com aspectos identificados na literatura, resultando em um modelo de processo, no qual se verifica a necessidade de desenvolvimento multidisciplinar integrado e a participação ativa dos usuários. Por fim, são discutidas limitações do modelo apresentado em relação a diferentes domínios de aplicações Web.

Palavras-chave: Processo de software, engenharia de software, web, intranet, design.

ABSTRACT

This paper analyzes typical aspects of Web based software production. A case study is carried out to identify how Web applications with high user interactivity and complex functionality must be produced. The results of the case study are confronted with literature's identified aspects, resulting in a process model which shows the need of the integrated multidisciplinary development and intensive user participation. Finally, limitations of this model are discussed in relation to differents Web application domains.

Key words: Software process, software engineering, web, intranet, design.

INTRODUÇÃO

Aplicações Web estão cada dia mais presentes e seu desenvolvimento representa boa parte da produção de organizações desenvolvedoras de software bem como de mídia em geral. Este artigo apresenta uma proposta de processo que integra os aspectos multidisciplinares em um contexto ordenado e interativo, com a participação dos usuários.

De acordo com o Ministério de Ciência e Tecnologia do Governo Federal, em pesquisa realizada em âmbito nacional em 2001, foi constatado que de um total de 433 empresas desenvolvedoras de software pesquisadas, 133 (31,6%) desenvolvem páginas para a Web, 123 (28,4%) desenvolvem aplicações E-business e 111 (25,6%) desenvolvem aplicações de comércio eletrônico (MCT, 2002). Embora a pesquisa não deixe claro o que se entende especificamente por E-business e Comércio Eletrônico, estas podem ser consideradas como típicas aplicações que envolvem software em ambiente Web.

Por outro lado, verifica-se também um grande número de aplicações Web sendo desenvolvidas em agências de publicidade, agências de design e de mídia em geral. Em 2003, a ABRAWEB (Associação Brasileira de Web Designers e Web Masters) estimava entre 70 e 80 mil o número de profissionais na área (ABRAWEB, 2003). Segundo esta entidade, estes profissionais possuem as mais variadas formações, indo da área gráfica e de comunicação à programação e à análise de sistemas, entre outras.

Neste contexto, verifica-se que aplicações Web são tipicamente produzidas em um ambiente de trabalho multidisciplinar. Entretanto, é difícil encontrar na literatura alguma abordagem da produção de aplicações Web que considere de forma sistêmica o aspecto multidisciplinar do desenvolvimento. Muitos trabalhos enfocam somente o aspecto de desenvolvimento de software; outros enfocam o aspecto de design, com foco em estética e mídia; outros enfocam a produção de conteúdo informativo, arquitetura da informação e redação de texto para Web. São deixados de lado aspectos fundamentais: Como equipes multidisciplinares trabalham de forma coordenada? Quais os papéis desempenhados pelos profissionais no desenvolvimento? Quais são as competências, técnicas e ferramentas necessárias? Como as atividades são organizadas em paralelo? Qual o processo seguido? E, por fim, como o resultado do trabalho de cada profissional é integrado em um único produto?

Este artigo faz uma revisão bibliográfica do estado-da-arte sobre processos para a produção de software em ambiente Web, buscando obter um conjunto coerente de atividades e artefatos tipicamente encontrados neste tipo de desenvolvimento. Para preencher as lacunas referentes ao aspecto multidisciplinar do desenvolvimento opta-se pela realização de estudo de caso, uma vez que a pergunta fundamental que motiva este trabalho relaciona-se a como é feito o desenvolvimento multidisciplinar de uma aplicação Web. Segundo Yin (2001), a metodologia de pesquisa de estudo de caso é adequada ao tipo de questionamento que procura investigar em profundidade como um certo trabalho é realizado.

Neste artigo, o termo aplicação Web é utilizado para descrever o software em ambiente Web. Para Pressman, uma aplicação Web pode ser desde uma simples página até um Web site completo (PRESSMAN, 2002). Esta definição atende apenas parcialmente aos objetivos aqui pretendidos, uma vez que um certo grau de complexidade é necessário para que as dificuldades inerentes ao processo de desenvolvimento de software apareçam e sejam consideradas.

Conallen (1999), considera que aplicação Web é um Web Site no qual é implementada uma lógica de negócio e cujo uso altera o estado do negócio. Segundo Paula Filho (2003), Aplicações Web são "produtos de software ou sistemas de informática que utilizam uma arquitetura distribuída, pelo menos parcialmente sob protocolo http. Em conseqüência, pelo menos parte das interfaces com o usuário é acessível através de um navegador (browser)". Ambas as definições são adotadas neste trabalho, acrescentando que aplicações Web são também baseadas em estrutura de hipertexto e/ou hipermídia. Este trabalho enfoca aplicações Web interativas e com funcionalidade complexa.

Por sua vez, o termo design é entendido aqui não como na acepção da palavra em inglês projeto ou desenho (nomenclatura normalmente empregada na Engenharia de Software), mas como a atividade de projeto de um produto que busca conciliar e integrar os aspectos técnicos – tanto de produção como do produto em si – com os aspectos estéticos e socioculturais que o produto deve atender. Web Design é o design de páginas Web e Web Sites. Segundo Hauffe (1996), "o trabalho do designer (profissional de design) tem diversos pontos de foco: o artístico/estético, o técnico/funcional, a orientação mercadológica (marketing), o teórico/científico e o organizacional/administrativo".

Este trabalho está organizado da seguinte forma: primeiramente é feita a revisão bibliográfica do processo de desenvolvimento de aplicações Web. Em seguida é apresentado o estudo de caso realizado, bem como uma discussão acerca deste estudo. É feita, então, a proposta de processo de desenvolvimento para Web, através da análise dos aspectos encontrados no estudo de caso frente aos aspectos obtidos na revisão bibliográfica, buscando encontrar elementos em comum e elementos discordantes em relação ao escopo de abrangência do caso analisado. Por fim, é feita a discussão final, onde se procura mostrar as vantagens do uso deste processo, assim como futuras pesquisas visando complementá-lo.

DESENVOLVIMENTO PARA WEB

Nesta seção é feita uma revisão bibliográfica das principais propostas de processo para desenvolvimento na Web. Inicialmente, dá-se uma visão geral dos processos para Web centralizados em suas principais atividades. Em seguida, aborda-se a questão do uso de prototipagem no processo. Mostra-se então, um quadro resumo com os principais artefatos discutidos e finalmente, discute-se o uso de padrões de projeto (design patterns) para Web.

Processos (visão geral)

Para Isakowitz et al. (1995), o projeto de sistemas hipermídia difere do processo de desenvolvimento de software tradicional em vários pontos críticos: envolve pessoas com os mais variados perfis, como autores, designers, artistas, músicos e programadores; envolve captura e organização de uma estrutura complexa do domínio da aplicação, a hipermídia. Os autores consideram ainda que os aspectos de multimídia são intrinsecamente difíceis.

A metodologia RMM (Relationship Management Methodology) define sete passos para o processo de desenvolvimento de aplicações Web: Etapa 1: Modelagem das entidades do sistema e do relacionamento semântico entre elas; resulta em um diagrama Entidade-Relacionamento (E-R) do sistema. Etapa 2: Representa como os atributos ("fatias") de cada entidade são apresentados e acessados pelo usuário; produz um diagrama E-R aprimorado (E-R+). Etapa 3: Representa o diagrama de navegação entre as entidades mapeadas no diagrama E-R+. Etapa 4: Apresenta um protocolo de conversão de projeto, que especifica como cada elemento do modelo deverá corresponder com o elemento do sistema final. Etapa 5: Projeto das interfaces. Etapa 6: Projeto do comportamento dinâmico do sistema. Etapa 7: Construção e teste (ISAKOWITZ et al., 1995).

Para Gorshkova e Norikov (2002), como sistemas Web são sistemas hipermídia, é necessário modelar quais páginas são usadas, como elas estão vinculadas ("linkadas") entre si e quais dados exibirão. O projeto do sistema deve seguir as seguintes fases: 1) aquisição de requisitos; 2) projeto dos aspectos do servidor; 3) projeto de hipertexto e 4) projeto do conteúdo das páginas Web. Os diagramas de UML (Unified Modeling Language) utilizados para modelar o sistema devem incluir os seguintes aspectos: modelo conceitual da aplicação, diagramas de navegação e diagramas de composição.

Ceri et al. (2000) definem quatro perspectivas ortogonais para a representação de uma aplicação Web: 1) Modelo estrutural: modela o conteúdo de dados do site em termos de entidades e relacionamentos; 2) Modelo de Hipertexto, descreve a estrutura de hipertexto do site e consiste em dois submodelos: 2a) Modelo de composição: especifica quais páginas compõem a estrutura de hipertexto e quais unidades de conteúdo compõem uma página; 2b) Modelo de navegação: expressa como as páginas e unidades de conteúdo estão vinculadas entre si para compor a estrutura de hipertexto; 3) Modelo de apresentação: expressa o layout e aparência das páginas; 4) Modelo de personalização: permite modelar personalizações da aplicação criadas para algum usuário ou grupos de usuários.

Conallen (1999) ressalta a importância da representação dos elementos de página e da estrutura de navegação das aplicações Web. Li et al. (2000) enfatizam a importância de representar a semântica da aplicação (modelo de negócio), a estrutura de navegação e composição e a implementação das páginas.

A proposta OOHDM (Object-Oriented Hypermidia Design Method) considera quatro diferentes atividades no desenvolvimento de aplicações Web: projeto conceitual, projeto navegacional, projeto abstrato de interfaces e implementação (SCHWABE et al., 1999).

Para Rodriguez et al. (2002), o processo de desenvolvimento para Web pode ser decomposto em dois sub-processos: 1) o subprocesso de autoria (auth), o qual cria a estrutura de hipermídia; e 2) o subprocesso de desenvolvimento de infra-estrutura (inf), o qual providencia a integração com base de dados, desenvolvimento em linguagem de programação (ASP, applets, servlets, scripts, etc.), integração com outros sistemas, etc. Ambos os subprocessos são compostos pelas atividades encontradas no processo de desenvolvimento de software convencional, conforme mostra a Figura 1. Os elementos do processo são descritos nas Tabelas 1 e 2.

O termo autoria é utilizado para referenciar o trabalho criativo de produção e organização do conteúdo estético e informativo. Segundo Pressman (2002), as aplicações Web são inerentemente guiadas por conteúdo. Os provedores de conteúdo são projetistas gráficos, redatores, produtores de mídia, entre outros. Conforme Pereira dos Santos (2001), o termo autoria está relacionado a tudo que pode ser caracterizado como propriedade intelectual e resultante de trabalho criativo.

Embora Rodriguez et al. não tenham definido explicitamente os fluxos de trabalho para o subprocesso de infra-estrutura, considera-se aqui que podem ser entendidos como as atividades tipicamente encontradas no processo de desenvolvimento de software.

O aspecto a ser ressaltado no modelo apresentado na Figura 1 é a separação do processo de desenvolvimento nos dois subprocessos, o que permite o desenvolvimento em paralelo das atividades de autoria e infra-estrutura. Embora os autores tenham incluído um elemento de interface entre os subprocessos, não há detalhes de como isto é realizado. Nota-se também que no subprocesso de infra-estrutura, na fase de análise, não é necessário o uso da estrutura de navegação, uma vez que o mesmo é desenvolvido no subprocesso de autoria.

Na proposta de Engenharia da Web de Pressman (2002), destaca-se o projeto do conteúdo (textos, mídias, etc.) juntamente com a arquitetura da aplicação, o projeto gráfico das interfaces e a utilização de gabaritos (templates).

Ward e Kroll (1999) apresentam uma proposta para o desenvolvimento de aplicações Web buscando unificar o processo criativo de design com o processo de engenharia de software proposto pelo Rational Unified Process (RUP), conforme mostra a Figura 2. Os elementos da proposta são: uma especificação inicial de requisitos, desempenhada pelo engenheiro de software do projeto e usando modelo de Casos de Uso; a definição dos requisitos não-funcionais; briefing de design; criação do diagrama de navegação inicial; composição gráfica (layout); criação dos elementos de Web design (menus, fundos, elementos gráficos, etc.); protótipo inicial de interfaces, focando os aspectos funcionais destas (formulários, janelas, mensagens, links); linhas-mestras de interface, definindo os gabaritos (templates); protótipo completo das interfaces; diagrama completo de navegação.

Embora a proposta de Ward e Kroll (1999) mencione a integração entre o processo de design, tipicamente de autoria, e o processo de engenharia de software, verifica-se que o enfoque real da proposta é basicamente no aspecto de autoria; pouco enfoque é dado ao aspecto de infra-estrutura. Outra característica da proposta é o desenvolvimento seqüencial e não em paralelo. Entretanto, esta proposta identifica a produção de artefatos relevantes, que devem ser considerados no processo.

Prototipagem e Storyboarding

Storyboarding basicamente corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Esta técnica foi utilizada inicialmente no cinema e desenhos animados, representando um esboço dos personagens e da história.

Geralmente, storyboards podem ser categorizados em três tipos (LEFFINGWELL & WIDRIG, 2003):

• Passivo: São constituídos de quadros, fotos, esboços, etc. Neste caso são apresentadas ao usuário as regras do sistema em sua seqüência, com uma explanação do tipo "Quando você faz isto, acontece isto";

• Ativo: Corresponde a uma seqüência de figuras que mostram uma descrição automatizada do modo como o sistema se comporta em um uso típico ou em um cenário operacional, por exemplo, em uma apresentação automática de slides;

• Interativo: Permite ao usuário interagir sobre o sistema de um modo mais realístico, exigindo sua participação. Pode ser uma simulação dos possíveis cenários (protótipo não-funcional), ou mesmo um protótipo funcional simplificado do sistema.

A prototipagem funcional implementa parte dos requisitos do sistema através da construção de um protótipo que executa o comportamento real deste sistema (com a implementação de algoritmos e banco de dados), podendo valer-se de ferramentas especialmente construídas para a confecção deste tipo de protótipo (BOAR, 1984). Posteriormente este protótipo é descartado, passando-se para o efetivo desenvolvimento do sistema pela seqüência tradicional (análise, projeto, implementação e testes), de posse de um conjunto de requisitos bem refinados.

Já a prototipagem não-funcional obtém o comportamento dos usuários, stakeholders e do sistema através de interações com estes, por meio de um conjunto de interfaces gráficas simulando o comportamento real do sistema, sem a implementação de algoritmos e banco de dados.

O uso de storyboards interativos, que na realidade são protótipos do sistema (funcionais ou não) permite uma série de vantagens (BOAR,1984; LEFFINGWELL & WIDRIG, 2003):

• Redução da distância entre os participantes do projeto: a comunicação é um problema fundamental no desenvolvimento. Mesmo quando uma pessoa sabe o que quer, sempre ocorrem mudanças quando estas necessidades se transformam em requisitos;

• Aumento da participação e interesse dos atores: sistemas complexos que envolvem várias áreas de uma empresa requerem um compromisso, concordância e consenso entre vários atores para poderem operar corretamente;

• Validação de requisitos;

• Testar as interfaces desde o início.

Artefatos Utilizados

Em todas as propostas apresentadas aparecem artefatos produzidos e consumidos nas diferentes atividades do processo de desenvolvimento. Alguns destes artefatos são comuns a muitas propostas e ilustram um aspecto importante do processo de desenvolvimento. Artefatos são modelos, diagramas e/ou documentos resultantes de uma atividade (fluxo de trabalho) do processo (PAULA FILHO, 2003). Uma lista dos artefatos apresentados nas propostas analisadas é mostrada na Tabela 3.

Alguns artefatos são mencionados em mais de uma proposta. A Tabela 4 relaciona cada artefato com a(s) proposta(s) que o(s) menciona(m), permitindo verificar quais artefatos são mais utilizados.

Verifica-se na Tabela 4 que o diagrama de navegação é utilizado em todas as propostas analisadas, enquanto que, por outro lado, o uso de storyboard não é mencionado em nenhuma. O uso de briefing e prototipagem é mencionado somente na proposta de Ward e Kroll.

Padrões de Projeto para Aplicações Web

O conceito de padrões de projeto (design patterns) surgiu como uma solução para um problema em um determinado contexto, relacionado a estruturas que resolvem problemas similares. Este conceito tem sido utilizado em projetos de software, e particularmente em sistemas orientados a objetos (SHALLOWAY & TROTT, 2004).

Bolchini (2000) propõe alguns padrões de projeto para aplicações Web tomando como base os elementos definidos na metodologia RMM (ISAKOWITZ et al., 1995) entre outras. Segundo Bolchini (2000), uma taxonomia de padrões de projeto baseada em domínio de aplicação não é adequada, uma vez que pode-se encontrar mais de trinta tipos de aplicações Web, como comércio eletrônico, mecanismos de busca, catálogos de produtos, Web Sites corporativos, portais, etc. Além disto, na medida em que formas completas de negócio são portadas para a Web (categorias de e-Business), novos tipos surgem constantantemente. O autor sugere uma taxonomia de padrões de projeto para a Web a partir das seguintes categorias:

• Padrões de projeto de estrutura;

• Padrões de projeto de navegação;

• Padrões de projeto de interface;

• Padrões de projeto funcionais.

Os padrões de projeto de estrutura focam o modelo estrutural da aplicação, em termos de sua estrutura de informação. Os padrões deste tipo são: Centro de Coleção e Entidade Complexa.

Os padrões de projeto de navegação focam a forma como o usuário navega na aplicação, ou seja, a arquitetura de navegação desta. Os padrões desta categoria são: Tour Guiado e Navegação Indexada.

A categoria de Padrões de Projeto de Interface possui os padrões Layout e Interação. Nos padrões de Projeto de Layout foca-se a representação gráfica do conteúdo e dos elementos de html (hypertext markup language). Nos padrões de Projeto de Interação foca-se a interação humano-computador e questões ergonômicas.

O padrão de Projeto Funcional pode ser avaliado a partir de duas perspectivas: do usuário e do sistema. Na perspectiva do usuário tem-se, essencialmente, o comportamento interativo pelo lado do cliente da aplicação, ou seja, como a interface da aplicação é utilizada e quais funções o usuário executa. Na perspectiva do sistema tem-se as funções globais exercidas por este, sem considerar usuários em particular, ou seja, as funções do sistema que são comuns a todos os usuários.

As características dos padrões de projeto propostos por Bolchini (2000) são mostradas na Tabela 5. É importante considerar que esta classificação de padrões de projetos não é excludente, ou seja, o enquadramento de uma aplicação em um padrão de projeto não impede que esta se enquadre também em outro padrão.

O conceito de padrões de projeto para Web é importante no contexto deste trabalho para verificar as limitações do processo proposto e das condições do caso estudado. Os elementos identificados podem ser significativos para um padrão e não o ser para outro.

ESTUDO DE CASO

O estudo de caso foi realizado em um departamento responsável pelo desenvolvimento de aplicações Web em uma instituição de pesquisa de grande porte em tecnologia. As aplicações desenvolvidas neste departamento são de uso interno da instituição e visam a automação de processos internos em um ambiente Web, sobre rede corporativa privada (intranet). Os clientes são os responsáveis de cada departamento e os usuários são os funcionários destes departamentos.

Foram entrevistados coletivamente os três funcionários do departamento que trabalham diretamente no desenvolvimento das aplicações. A entrevista foi orientada a partir dos seguintes tópicos:

a) As características gerais das aplicações desenvolvidas;

b) Os papéis envolvidos;

c) O processo (as atividades, a ordem na qual foram feitas, como foram feitas e as ferramentas e artefatos utilizados);

d) Quais os pontos de dificuldade e o que pode melhorar em termos de processo de desenvolvimento.

Posteriormente, o texto gerado da entrevista foi validado pelo responsável do departamento e algumas lacunas foram preenchidas.

Características gerais

Foi relatado o desenvolvimento de quatro aplicações Web desenvolvidas e uma quinta em andamento, com prazo médio de oito meses por aplicação. As aplicações automatizam processos da instituição, como acompanhamento de solicitações de serviços feitas por clientes internos e externos, geração automática de orçamentos, aplicações para disponibilização de informações gerenciais, entre outras.

Algumas destas aplicações são utilizadas pela maioria dos funcionários da empresa, fazendo com que os sistemas desenvolvidos atendam a uma ampla gama de usuários (desde debutantes até experientes). Os sistemas são desenvolvidos em três camadas: de interface, de lógica/regra de negócio e de banco de dados.

As aplicações são desenvolvidas sobre plataforma Microsoft, que consiste em: banco de dados o SQL Server 2000, servidor Web Internet Information Services (IIS), páginas Active Server Pages (ASP) e ambiente Windows 2000 Server.

Papéis

Em todos os projetos foram adotados os seguintes papéis, com as respectivas atribuições e qualificações:

• Projetista Web: profissional sênior, responsável pelo planejamento da aplicação como um todo e gerenciamento do trabalho da equipe (camadas de: interface, negócio e banco de dados). Faz a ponte entre os aspectos funcionais e estéticos e o planejamento da arquitetura de informação, navegabilidade, usabilidade, interatividade e conteúdo. Responsável também pela programação das páginas ASP (Active Server Pages) e integração destas com o banco de dados e componentes;

• Web designer: faz a concepção visual da aplicação, planejamento e criação de mídias, definição de cores, tipografia e aplicação de logomarca. Cria os elementos html das páginas, ícones e imagens de fundo (menus, fundos, elementos gráficos, etc.) e expressa o layout e aparência das páginas. Profissional sênior;

• Analista de Banco de Dados (BD): Faz a concepção lógica e física da estrutura de dados da aplicação, implementa o banco de dados (camada de banco de dados), define e implementa os procedimentos armazenados (stored procedures – camada de negócio) que encapsulam as funcionalidades de interação da aplicação com a camada de dados. Profissional sênior.

Processo

O processo de desenvolvimento descrito consiste basicamente em quatro fases:

Levantamento de requisitos preliminar

Na primeira fase é feito o levantamento de requisitos com o cliente (departamento interessado da instituição e seus responsáveis) e conta com a participação ativa dos interessados e usuários-chave do departamento-cliente. Os requisitos são documentados através da gravação das entrevistas e documentos textuais.

A partir dos requisitos é montado um protótipo não-funcional, contendo as interfaces e a estrutura inicial de navegação. Este protótipo é construído por etapas, onde primeiro faz-se um storyboard de navegação, layout das páginas em papel, uma primeira visão da estrutura de dados (E-R – Entidade-Relacionamento) e, posteriormente, uma versão correspondente em html, construindo-se assim o protótipo inicial do sistema.

Protótipo não-funcional

A segunda etapa é realizada por toda a equipe e conta com a participação ativa dos interessados e usuários-chave do departamento-cliente e de todos os usuários. São feitas várias iterações/interações para refinamento do protótipo não-funcional desenvolvido na fase inicial de levantamento através de várias sessões. Utiliza-se para tanto uma técnica baseada em JAD (Joint Application Design), ACT (Análise Coletiva do Trabalho) e prototipagem através da ergonomia de interfaces e usabilidade.

Durante este processo de sessões com os usuários, o trabalho é dividido de modo que o Web designer faz a criação dos elementos gráficos em ferramenta de produtividade e mantém uma interação constante com o projetista Web e com os usuários, para adequar a estrutura visual com a estrutura funcional pretendida, sendo que a interface é utilizada para guiar o trabalho de interação com os participantes das sessões.

Também nesta fase são verificadas as diferenças entre os diversos usuários, assim como suas preferências e necessidades de informações para ajuda (help). No final desta fase é feita a validação do protótipo junto aos mesmos (páginas em html, sem código de programação).

Implementação

Na terceira fase, o analista de BD gera os procedimentos armazenados (camada de negócio), de acordo com as funcionalidades levantadas conjuntamente com o projetista Web. É gerado, então, um protótipo funcional da aplicação. Para isto, o projetista Web recebe o código html das páginas feito pelo Web designer e, usando programação em ASP (Active Server Pages), faz a integração funcional com o banco de dados a partir dos procedimentos armazenados, criados pelo Analista de BD.

Refinamento

Na quarta fase é feito o refinamento final do protótipo funcional, com a participação ativa de todos os usuários e da equipe, utilizando-se para tanto o conceito de análise ergonômica do trabalho, onde a operação do sistema é acompanhada no efetivo ambiente de trabalho. Esta fase corresponde a um ajuste fino, pois, em geral, as principais funcionalidades já foram implementadas nas fases anteriores.

Dificuldades encontradas e melhorias discutidas

Foram discutidas as dificuldades encontradas no processo de desenvolvimento utilizado e as possibilidades de melhoria. Os seguintes aspectos foram relatados:

• Necessidade de treinamento e capacitação constante;

• O processo é bastante estável e claro para a equipe de trabalho, mas não está formalmente documentado;

• A documentação gerada no processo de desenvolvimento deve ser disponibilizada para toda a equipe de forma clara e facilmente acessível.

Em relação aos artefatos produzidos no processo, verifica-se a necessidade de elaboração de diagramas de navegação com fluxos de informação entre páginas. O analista de BD relatou a necessidade de identificar quais páginas no diagrama de navegação utilizam quais procedimentos armazenados do banco de dados. Foi relatada também a necessidade de representação dos diagramas gerenciais do projeto.

Um aspecto importante relatado é que o processo funciona bem porque as pessoas estão próximas e podem se comunicar constantemente. Para um desenvolvimento com equipe dispersa, o processo teria que ser melhor documentado e formalizado, utilizando-se para tanto ferramentas especializadas para este objetivo.

Outro aspecto levantado é a característica eminentemente funcional das aplicações desenvolvidas. Para aplicações de outra natureza, onde o aspecto visual é mais predominante que o funcional, como sites institucionais, de marketing de produtos, etc., o processo deveria ser adaptado, visando o foco no processo de design e não de negócio (transacional).

PROPOSTA DE PROCESSO DE PRODUÇÃO DE APLICAÇÕES WEB

Aqui é feita a confrontação dos aspectos identificados no estudo de caso com a revisão bibliográfica no sentido de posicionar particularidades observadas em um contexto mais amplo. Nos aspectos em que há uma correspondência entre o caso estudado e a literatura, considera-se que o estudo de caso revela um aspecto que pode ser geral na produção de aplicações Web. Nos aspectos onde não há correspondência, considera-se uma particularidade do caso estudado, para a qual se tenta encontrar uma explicação. A partir desta análise é apresentada a proposta de processo deste trabalho.

No estudo de caso realizado são identificados três papéis desempenhados pelos três profissionais do departamento, mas, confrontando-se com a revisão bibliográfica, verifica-se que o projetista Web desempenha a função de programador, que poderia ser exercida por um profissional dedicado. Observa-se também que o projetista Web é o responsável pelo projeto de navegação e usabilidade de interfaces, o que poderia ser desempenhado pelo Web designer. Conforme as propostas RMM, OOHDM e de Pressman, o processo de desenvolvimento envolve um papel relacionado ao projeto conceitual da aplicação e à arquitetura da informação. No caso estudado, este papel é desempenhado por toda a equipe e resulta na criação do storyboard e diagrama E-R inicial. Não se constata no caso estudado a utilização intensiva de mídias, como sons, animações vetoriais e filmes.

No caso estudado há uma diferença em relação à literatura quanto à utilização de um profissional exclusivo para banco de dados, o que pode ser decorrente do uso intensivo de dados e do ambiente transacional das aplicações desenvolvidas, ou seja, aplicações para funções departamentais em ambiente de intranet.

Em relação aos artefatos produzidos, verifica-se uma correspondência com a literatura no levantamento de requisitos, diagrama de navegação, modelo conceitual, modelo E-R e criação de elementos de HTML. A Tabela 6 mostra a correspondência.

Observa-se na Tabela 6 que no caso estudado há uma produção intensa de artefatos, cobrindo praticamente toda a gama de artefatos identificados na literatura. Em particular, nota-se uma correspondência com a proposta de Ward e Kroll, o que pode ser resultado da participação do Web designer no processo.

Tomando como referência o modelo de subprocessos da Figura 1, os artefatos sugeridos nas diferentes propostas da literatura (Tabelas 3 e 4) e incorporando as melhorias discutidas, é proposto o modelo de processo representado na Figura 3. Faz-se uso dos artefatos (diagramas, documentos, produto material de atividade de trabalho) para documentar e registrar as etapas do processo, a fim de facilitar a comunicação da equipe de trabalho e tornar mais independente o trabalho de cada profissional. As atividades de trabalho para cada papel desempenhado pela equipe são sobrepostas aos subprocessos de autoria e infra-estrutura; o trabalho do projetista Web é integrador e faz a interface entre os subprocessos. A participação dos usuários é representada em uma faixa cuja densidade para o escuro é proporcional ao grau de participação: quanto mais escura a faixa, mais intensa a participação dos usuários no processo.

No documento de requisitos são definidos os requisitos funcionais e não-funcionais da aplicação, o briefing de design e o modelo conceitual. Os demais artefatos são descritos na Tabela 3, com exceção do mapa de páginas e procedimentos armazenados do banco de dados, que é um artefato específico, proposto a partir de uma necessidade identificada no caso estudado, não sendo mencionado na literatura. Este artefato deve representar as páginas no diagrama de navegação e identificar quais procedimentos armazenados do banco de dados são chamados por quais páginas.

Análise da proposta

O processo proposto, conforme representado na Figura 3, apresenta as seguintes características:

• O trabalho de desenvolvimento de aplicações Web pode ser feito em paralelo, adotando-se um processo que separa as atividades relacionadas aos aspectos de autoria e de infra-estrutura em subprocessos paralelos, o que está de acordo com a literatura;

• A proposta representa explicitamente os papéis envolvidos, dando espaço para a inclusão ou exclusão de papéis conforme as características da aplicação a ser desenvolvida. Vale ressaltar que a colocação das atividades desempenhadas pelo projetista Web, posicionadas em ambos os subprocessos, servem para coordenar e integrar todas as atividades. Embora encontrada no caso estudado, esta característica pode ser generalizada;

• No processo proposto adota-se um modelo baseado em prototipagem, com quatro fases e altamente interativo com os usuários e clientes, ao contrário dos modelos mais formais e restritivos (requisitos, análise, projeto, etc.) da literatura. A deficiência na formalização de artefatos e documentos de projeto, identificada no estudo de caso, pode ser superada com a utilização de artefatos, de acordo com o modelo da Figura 3.

Para a generalização deste processo alguns aspectos devem ser considerados em sua aplicação:

• O desenvolvimento para cliente interno (departamentos da instituição) e uso em ambiente restrito permite a interatividade com os usuários no desenvolvimento por prototipagem e refinamento iterativo, o que é essencial neste processo. Para o desenvolvimento de uma aplicação para o público em geral, como uma loja virtual, por exemplo, deve-se tentar uma abordagem por amostragem de usuários (NIELSEN, 2000);

• O processo em questão aplica-se melhor para projetos onde a equipe não esteja distribuída;

• Considerando uma classificação de padrões de projeto para Web (BOLCHINI, 2000), conclui-se que para padrões de projeto onde a concepção visual e de conteúdo (padrões de estrutura, navegação e interface) predomina sobre o aspecto funcional, a distribuição de atribuições dos papéis no processo aqui estudado pode não ser plenamente satisfatória: o designer pode ganhar maior liberdade de criação na fase inicial do projeto;

• A técnica baseada em prototipagem pode não ser a mais adequada para o caso de sistemas onde haja predominância de processamento em lote (batch) ou grande conteúdo algorítmico (BOAR, 1984).

DISCUSSÃO FINAL

A utilização do processo proposto permite rápida convergência às necessidades e expectativas do usuário, agilidade no desenvolvimento e documentação consistente. Isto é garantido através da participação ativa dos usuários no processo, da atividade de desenvolvimento em paralelo – com intermediação do Projetista Web – e da utilização dos artefatos relacionados na Figura 3. A ausência de um profissional como intermediário às atividades dos subdomínios de infra-estrutura e autoria pode levar a uma maior dificuldade na integração das mesmas, ou a um desenvolvimento conflitante.

O estudo aqui realizado permite verificar que o desenvolvimento de aplicações Web ocorre em regime tipicamente multidisciplinar, envolvendo atividades e competências genéricas, tanto em domínio criativo-artístico como em domínio técnico. Verifica-se também a necessidade de integração das funções e da formalização do processo e sua documentação.

Por fim, em relação às questões levantadas sobre competências profissionais específicas, ferramentas e técnicas, nada é possível concluir com o estudo de caso realizado, uma vez que alguns aspectos, como o uso de mídias e concepção visual complexa, não são utilizados de forma intensiva nas aplicações desenvolvidas, que focam um domínio de aplicação bastante específico. Entretanto, ficam claros os papéis desempenhados e de acordo com o identificado na literatura, embora o projetista Web execute atividades – como projeto navegacional e de usabilidade – que, de acordo com a literatura, estão mais próximos às atribuições do Web designer. Em relação à questão quais são as competências profissionais, as ferramentas e as técnicas específicas utilizadas, uma pesquisa exploratória (survey) deve ser realizada. Para maior validade das conclusões inferidas, pode ser conduzido um segundo estudo de caso, focando o desenvolvimento de aplicações Web onde concepção visual, de mídia e conteúdo sejam predominantes.

Artigo recebido em 30/06/2005

Aprovado para publicação em 24/11/2005

Sobre os autores

Rodrigo Franco Gonçalves

Aluno de doutorado do Depto. de Engenharia de Produção – GTI

Escola Politécnica da USP

Endereço: Av. Prof. Almeida Prado, travessa 2, nº128 – CEP 05508-900 – São Paulo, SP

Telefone: (11) 3091-5363/5195

E-mail: [e-mail]

Vagner Luiz Gava

Gerente de desenvolvimento de sistemas

Escola Politécnica da USP/ Inst. de Pesq. Tecnológicas de São Paulo (IPT)

Endereço: Av. Prof. Almeida Prado, travessa 2, 128 – CEP 05508-900 – São Paulo – SP

Telefone: (11) 3767-4500 – Fax: [phone]

e-mail: [e-mail]

Marcelo Schneck de Paula Pessôa

Prof. Dr. do Depto. de Engenharia de Produção – GTI

Escola Politécnica da USP

Endereço: Av. Prof. Almeida Prado, travessa 2, 128 – CEP 05508-900 – São Paulo, SP

Telefone: (11) 3091-5363/5195 – Fax: [phone]

E-mail: [e-mail]

Mauro de Mesquita Spinola

Prof. Dr. do Depto. de Engenharia de Produção – GTI

Escola Politécnica da USP

Endereço: Av. Prof. Almeida Prado, travessa 2, 128 CEP 05508-900 – São Paulo SP

Telefone: (11) 3091-5363/5195 – Fax: [phone]

E-mail: [e-mail]

• ABRAWEB Associação Brasileira de Web Designers e Web Masters. Web Designer: saiba quem é este profissional. Março 2003. Disponível em <http://www.abraweb.com.br/imprensa/nube.html>. Acesso em: 10/2/2005.
• BOAR, B.H. Application Prototyping. 1ed. New York: John Wiley & Sons, 1984.
• BOLCHINI, Davide. Web Design Patterns: improving quality and performance in Web Application design. Universit della Svizzera Italiana USI, Communication Sciences Thesis. Lugano, 2000.
• CERI, S.; FRATERNALI, P.; BONGIO, A. Web Modeling Language (WebML): a modeling language for designing Web sites. Computer Networks, 33(1-6): 137-157, 2000.
• CONALLEN, Jim, Modeling Web Application Architetures with UML, Communications of ACM, v. 42, n. 10, October 1999. (1999a).
• GORSHKOVA, E.; NORIKOV, B., Exploiting UML Extensibility in the Design of Web Information System, 11ş International World Wide Web Conference, Hawaii, USA, may 2002, disponível em <http://www2002.org>.
• HAUFFE, Thomas. Design: An illustrated historical overview Barron's. 1996.
• ISAKOWITZ, T.; STOHR E.; BALASUBRAMANIAN P. RMM: A Methodology for Strutured Hypermidia Design, Communications of ACM, v. 38, n. 8, August 1995.
• LEFFINGWELL, D; WIDRIG, D. Managing Software Requirements. A Use Case Approach 2 ed. Boston: Addison-Wesley, 2003.
• LI, Jingfeng; CHENG, Jian; CHENG, Ping. Modeling Web Application Architecture with UML. Proc. of the 36th Int. Conference on Technology of Object-Oriented Languages and Systems. IEEE Computer Society, 2000.
• MCT Ministério de Ciência e Tecnologia. Qualidade e Produtividade no Setor de Software. 2002. Disponível em <www.mct.gov.br/temas/info/dsi/software/menu_ qualidade.htm>. Acesso em: 10/4/2004.
• NIELSEN, J. Projetando Web Sites: designing Web usability, Rio de Janeiro: Campus, 2000.
• PAULA FILHO, Wilson de Pádua. Engenharia de Software Rio de Janeiro: LTC, 2003.
• PEREIRA DOS SANTOS, Manoel J. Considerações Iniciais sobre Proteção Jurídica das Bases de Dados. In LUCCA, Newton de. Direito e Internet: aspectos juridicos relevantes Ed. Edipro. 2001.
• PRESSMAN, R. Engenharia de Software, Rio de Janeiro: McGraw Hill, 2002.
• RODRIGUEZ, D.; HARRISON, R.; SATPATHY, M. A Generic Model and Tool Support for Assessing and Improving Web Processes. Proceedings of the Eighth IEEE Symposium on Software Metrics. IEEE, 2002.
• SCHWABE, D.; PONTES, R.; MOURA, I. OOHDM-Web: An Environment for Implementation of Hypermedia Applications in the WWW, ACM SigWEB Newsletter, v. 8, n. 2, June 1999.
• SHALLOWAY, Alan; TROTT, James R. Explicando Padrões de Projeto: uma nova perspectiva em projeto orientado a objeto Porto alegre. Bookman. 2004.
• WARD, Stan; KROLL, Per. Building Web Solutions with the Rational Unified Process: Unifying the creative design process and the software engineering process. Context Integration Inc and Rational Software. 1999. Disponível em <www.rational.com/mediawhitepapers /76.pdf> Acesso em: 6/10/2003.
• YIN, Robert K. Estudo de Caso: planejamento e métodos Porto Alegre: Bookman, 2001.

Datas de Publicação

• Publicação nesta coleção
  27 Mar 2006
• Data do Fascículo
  Dez 2005

Histórico

• Aceito
  24 Nov 2005
• Recebido
  30 Jun 2005