Adaptando o RUP para o Desenvolvimento de Sistemas de Informação Web

Adaptando o RUP para o Desenvolvimento de Sistemas de Informação Web

Alessandro Cruvinel Machado de Araujo Alexandre Marcos Lins de Vasconcelos Centro de Informática Universidade Federal de Pernambuco Caixa Postal 7851, 50732-970, Recife, PE, Brasil {acma, amlv}@di.ufpe.br

Abstract This paper proposes an adaptation of the Rational Unified Process (RUP) to be used in the development of Web Information Systems (WIS). We analyze the activities which must be included or instantiated in the Process’ workflows, so that it can be properly used in the development of this kind of systems. PALAVRAS-CHAVE: Engenharia de Software para a Web; RUP (Rational Unified Process); Metodologia de Desenvolvimento de Software.

1. Introdução O novo cenário econômico mundial tem pressionado as organizações em busca de competitividade, seja baixando os custos, seja em produtos mais bem acabados e sem erros. Algumas empresas esperam pelas crises para efetuarem as mudanças necessárias, já outras antecipam-se ao futuro. A indústria de produção de software não difere das demais, acompanhando e, muitas vezes, guiando as tendências deste novo cenário econômico mundial. Mesmo assim, ela tem passado por diversas crises [1], justamente por não se antecipar ao futuro, ou seja, por não prever sua própria expansão e não se preparar para essa nova realidade. A crise do software [1], que se iniciou com o aumento da complexidade técnica e da natureza dos problemas a serem resolvidos, e que permanece até hoje, foi causada principalmente pela falta de processos sistemáticos e metodológicos de produção de software e também de organização do ambiente de produção (pessoas envolvidas, conhecimento técnico necessário, ambiente físico ideal, qualidade, gerenciamento, planejamento, etc.). Esta crise está sendo amenizada com a introdução de processos que organizam e qualificam a produção de software, tornado-a uma tarefa mais sistemática e mensurável, permitindo que passos realizados com sucesso possam ser repetidos com a mesma eficácia. Diante da necessidade de competitividade imposta pelo cenário econômico mundial, as organizações têm buscado novas formas de expansão para que seus negócios possam ser realizados com sucesso. Dentro desta busca, a Internet tem se mostrado como o mais novo meio de comunicação e de realização de negócios, integrando pessoas, países e organizações em uma única teia de interatividade. A alta popularidade e, conseqüentemente, o uso da Internet tem provocado profundas alterações na estrutura da indústria de software. O cenário de produção de software

tem sido revolucionado, exigindo sistemas com novas características [2] para que possam ser usados através da Internet. Dentro do mundo Internet temos a Web, um dos principais meios de comunicação e que tem atraído muita atenção por parte das organizações. A Web tem tido um impacto significante sobre os setores de negócios, comércio, indústria, bancário e finanças, bem como nas áreas de educação, governo, entretenimento e sobre nossa vida pessoal e profissional. Ela tem sido muito usada como ambiente de suporte e meio para a realização de negócios e também para a disseminação de informações. Por esta razão softwares com novas características [3], que funcionem sobre a Web têm sido exigidos, culminando na adaptação e no desenvolvimento de uma grande quantidade de sistemas. Contudo, na maioria dos casos, as técnicas de desenvolvimento usadas para produzir sistemas baseados na Web têm sido ad hoc [3]. Dificilmente qualquer atenção é dada para metodologias de desenvolvimento, técnicas de medição e avaliação e para o gerenciamento de projeto e qualidade de aplicação. A maioria das tentativas de desenvolvimento de aplicações atuais e das práticas de gerenciamento têm se baseado no conhecimento e experiência dos desenvolvedores e de suas próprias práticas de trabalho. Na ausência de um processo disciplinado para o construção de software para a Web, podemos acabar face a face com sérios problemas no processo de desenvolvimento, implantação, operação e manutenção destes sistemas. Aplicações desenvolvidas na ausência de técnicas mais rigorosas têm uma alta probabilidade de falhar. Pior, como sistemas baseados na Web estão crescendo em complexidade, uma falha em um sistema pode se propagar através de muitos outros. Caso isto aconteça, a confiança na Web pode ser irreparavelmente abalada, causando uma grave crise [4] de fronteiras indeterminadas. Uma potencial crise na Web seria mais séria e difundida do que a crise do software, com a qual estamos face a face [1]. No momento, para evitar uma possível crise na Web [4] e alcançar maior sucesso no desenvolvimento de aplicações complexas baseadas na mesma, há uma pressão por técnicas disciplinadas e novos métodos e ferramentas para o desenvolvimento, implantação e avaliação de sistemas baseado na Web. Tais técnicas devem levar em consideração as características especiais da nova mídia, os ambientes operacionais, os cenários e multiplicidade de perfis de usuários e o tipo, experiência e conhecimento das pessoas envolvidas no processo de construção de sistemas baseado na Web. O Rational Unified Process [5] – RUP – apresenta características adequadas ao desenvolvimento de software para a Web, com a definição de atividades que abragem todo o ciclo de desenvolvimento de software. Apesar disso, percebemos a necessidade da inserção ou instanciamento de algumas das suas atividades para que possam contemplar características específicas [3] do novo ambiente. Inserido neste contexto, este trabalho fornece uma análise da adequação do RUP ao desenvolvimento de software para a Web. Em particular, são descritas as atividades que necessitam ser incluídas ou instanciadas para alguns de seus workflows de processo, no sentido de auxiliar a implantação de sistemas baseados na Web de qualidade em organizações de base tecnológica. Este trabalho faz parte de minha pesquisa de dissertação de mestrado. O objetivo desta pesquisa e o estudo de metodologias de desenvolvimento de software para a Web e do RUP, visando altera-lo para que se adeque ao desenvolvimento desse tipo de software. Além desta seção introdutória, o artigo apresenta outras quatro seções. A seção 2 introduz a engenharia de software para a Web. A seção 3 descreve o RUP

em suas linhas geras, apresentando suas principais características. A seção 4 apresenta a análise que é o ponto central deste artigo. Finalmente, a seção 5 apresenta as considerações finais e perspectivas futuras em relação ao trabalho de instanciamento de uma metodologia de desenvolvimento de software para a Web, baseada no RUP. 2. Engenharia de Software para a Web Nas seções que se seguem serão apresentados as características da Web (seção 2.1), os sistemas e tecnologias Web (seção 2.2) e a necessidade de uma metodologia de desenvolvimento de software para a Web (seção 2.3). 2.1. A Web A Web pode simplesmente ser definida como um universo de informação globalmente acessível através da rede [6]. É um espaço abstrato dentro do qual pessoas podem interagir. Ela marca o fim de uma era de frustração e incompatibilidade entre sistemas de computação, criando uma explosão de acessibilidade, com muitos impactos sociais e econômicos. A Web oferece um sistema para distribuição global de informação hipermídia e para processamento de transações de negócios [6]. O uso intensivo da tecnologia Web leva a uma transformação dos modelos de negócios e processos [7]. Essa mudança geralmente é a chave para a competitividade e requer habilidade para manipular uma variedade de modelos de negócios, frameworks de aplicação e estratégias de adoção de tecnologias. A combinação correta de novos modelos, frameworks e tecnologias, sustentada por um infra-estrutura de comunicação moderna, eficiente, robusta e confiável, somada a interatividade proporcionada pelo ambiente Web, torna a Web um dos principais meios de comunicação e negócios, praticamente sem barreiras de crescimento. O limite será sempre sobreposto pelo surgimento de novas tecnologias. 2.2. Sistemas Baseado na Web Um Sistema baseado na Web pode ser visto como um exemplo de um sistema híbrido [6]. Desenvolver um Sistema baseado na Web não é somente uma questão tecnológica, mas também uma questão organizacional, política e cultural. O desenvolvimento de tais sistemas envolve uma mudança radical na estruturação e apresentação da informação [6]. As tendências indicam alto interesse da maioria das organizações em utilizar a tecnologia e desenvolver sistemas baseados na Web. Há três razões principais para isto: a alta popularidade da tecnologia entre clientes em potencial, o relativo baixo custo de investimento necessário e a alta possibilidade de alcance dos objetivos pretendidos. Explorar a Web à procura de benefícios comerciais tem tornado-se um ponto chave para os CIOs (Chief Information Officer) em muitas organizações. Apesar da tremenda penetração da Web em uma variedade de mercados, está se tornando claro que a estrutura atual não está bem projetada para o acesso customizado à informação. Rein em [8] declara que "as tecnologias Web devem suportar os processos de trabalho existentes, bem como as práticas de trabalho necessárias para se adaptar às novas tecnologias emergentes". 2.2.1. Sistemas Web versus Sistemas Tradicionais Podemos identificar características que diferenciam os sistemas tradicionais dos sistemas baseados na Web. Schwabe [9] classifica estas diferenças em três

categorias: navegação, organização da interface e implementação. Volker [10] fala sobre as diferenças entre projetos para Web na universidade, na indústria e no comércio, mostrando que há diferenças mesmo entre os sistemas baseados na Web. Apesar das diferenças, muitos dos problemas relacionados a sistemas baseados na Web seguem estratégias de sistemas tradicionais [11]. Como Lederer, Mirchadani e Sims declaram: "Se um sistema baseado na Web melhora a competitividade, então ele deve suportar os meios através dos quais organizações competem: reduzindo custos, focando grupos de consumidores ... ou diferenciando produtos e serviços". 2.3. A Necessidade de uma Metodologia Na maioria dos casos, as técnicas de desenvolvimento usadas para produzir sistemas baseados na Web têm sido ad hoc [6]. Dificilmente qualquer atenção é dada para metodologias de desenvolvimento, técnicas de medição e avaliação, bem como para o gerenciamento de projeto e qualidade de aplicação. A maioria dos desenvolvimentos de aplicações atuais e das práticas de gerenciamento têm se baseado no conhecimento e experiência dos desenvolvedores e de suas próprias práticas de desenvolvimento. A Engenharia de Software para a Web deve se preocupar com o estabelecimento e uso de princípios de engenharia e gerenciamento e de técnicas sistemáticas e disciplinadas para o desenvolvimento, implantação e manutenção de sistemas e aplicações Web de alta qualidade. Ela deve incorporar alguns dos princípios bem sucedidos da engenharia de software tradicional, adaptando-os para a natureza mais aberta e flexível da Web e de suas aplicações. A engenharia de software para a Web deve, também, considerar outros elementos que são específicos do ambiente Web. Ela não deve ser uma atividade ou tarefa única, pois deve lidar com todos os aspectos do desenvolvimento de software para a Web, desde a concepção e desenvolvimento até a implementação, avaliação de qualidade e manutenção contínua. O núcleo da engenharia para a Web deve incluir: • Especificação e análise de requisitos; • Metodologias e técnicas de desenvolvimento; • Integração com sistemas legados; • Migração de sistemas legados para ambientes Web; • Desenvolvimento de aplicações de tempo real para a Web; • Teste, verificação e validação; • Avaliação, controle e garantia de qualidade; • Configuração e gerenciamento de projetos; • Métricas para estimação dos esforços de desenvolvimento Web; • Especificação e avaliação de performance; • Atualização e manutenção; • Modelos de desenvolvimento, equipes e pessoal; • Aspectos humanos e culturais; • Desenvolvimento centrado no usuário, incluindo modelagem, envolvimento e feedback para/de o usuário; • Desenvolvimento de aplicações para o usuário final; • Educação e treinamento. Apesar do exagero associado com a tecnologia Web, tem se tornado claro que a mesma não é tão fácil de se usar quanto algumas organizações supunham. Muitas organizações ainda têm encontrado dificuldade em resolver algumas

questões básicas relacionadas à adoção da tecnologia Web [12]. Nambisan [7] identifica três níveis de tecnologia Web: (nível 1) acesso à informação, (nível 2) trabalho colaborativo e (nível 3) transações de negócio. Ele também identifica as barreiras associadas à adoção desta tecnologia: barreira relacionada à tecnologia, ao projeto e a aplicação. 3. Rational Unified Process - RUP O RUP (Rational Unified Process) é mais do que um simples processo de desenvolvimento de software: ele é um framework de processo genérico que pode ser especializado para várias classes de sistemas de software, para diferentes áreas de aplicação, diferentes tipos de organizações, diferentes níveis de competência e diferentes tamanhos de projeto. O RUP é baseado em componentes e usa a Unified Modeling Language (UML) [13] para denotar a modelagem. Contudo, suas principais características são: •

•

•

Dirigido a use-case: O processo de desenvolvimento segue um fluxo de ações para realização de use-cases - isto procede através da execução dos workflows. Assim os use cases são especificados, projetados e no fim, são a fonte a partir da qual os engenheiros de teste constróem os casos de teste. Eles dirigem o processo de desenvolvimento. Centrado na arquitetura: O conceito de arquitetura de software engloba os aspectos estáticos e dinâmicos mais significantes do sistema. A arquitetura é tanto percebida pelos usuários e outros stakeholders como refletida nos usecases. Contudo, ela também é influenciada por muitos outros fatores, tais como a plataforma de software, blocos de construção reusáveis disponíveis, considerações de implantação, sistemas legados e requisitos não-funcionais. A arquitetura é uma visão do projeto como um todo, que torna visível as características mais importantes do mesmo. Ela funde o sistema em uma fôrma. Portanto deve ser projetada para permitir que o sistema possa evoluir. Iterativo e incremental: O desenvolvimento de um produto de software comercial pode continuar por vários e vários anos. Por isso é prático que o trabalho seja dividido em pequenos ciclos ou mini-projetos. Cada mini-projeto é uma iteração que resulta em um incremento. Iterações referem-se a passos no workflow, e incrementos a evoluções do produto.

O RUP repete uma série de ciclos durante a vida de um sistema. Cada ciclo termina com uma versão do produto, e consiste de quatro fases (figura 1): •

• • •

Concepção: Durante a fase de concepção, uma idéia do sistema a ser produzido é desenvolvida para uma visão do produto final e os casos de negócio do produto, ou seja, a forma como o sistema poderá ser aplicado é apresentada. Nesta fase, a maioria dos riscos são identificados e priorizados. Elaboração: Durante a fase de elaboração o objetivo é eliminar os principais riscos e estabelecer uma arquitetura estável a partir da qual o sistema poderá evoluir. O resultado desta fase é uma linha base para a arquitetura. Construção: Durante a fase de construção o produto é construído - o músculo do software é adicionado ao seu esqueleto (arquitetura). Nesta fase a linha base da arquitetura cresce e torna-se o sistema. Transição: A fase de transição cobre o período durante o qual o produto se move em beta versões. Nas beta versões, um pequeno número de usuários

experientes testam o produto e indicam defeitos e deficiências. A fase envolve atividades tais como treinamento de pessoal do cliente, assistência e correção de defeitos encontrados antes da entrega do produto. Cada fase é adicionalmente dividida em iterações (figura 1) e finalizada com um milestone que verifica se seus objetivos foram alcançados. Toda iteração é organizada em termos de workflows (figura 1), que são conjuntos de atividades, realizadas por responsáveis que produzem artefatos. Fases Fluxos de Processo Concepção Elaboração Construção Transição Modelagem de Negócios................ Requisitos....................................... Análise & Projeto............................ Implementação............................... Testes............................................. Implantação....................................

Fluxos de Suporte Gerenc. de Config. & Mudanças.... Gerenciamento de Projeto.............. Ambiente......................................... Iteração Preliminar

Iter. #1

Iter. #2

Iter. #i

Iter. #i+1

Iter. #i+2

Iter. #n

Iter. #n+1

Iterações Figura 1. Fases, interações e workflows do RUP. (Extraída do Rational Unified Process 5.0 (build 33), da Rational Software Corporation)

Basicamente há dois tipos de workflows: workflows de processo e workflows de suporte (figura 1). Os workflows de processo são descritos a seguir: •

•

• •

Modelagem de Negócios: Permite o entendimento da estrutura e dinâmica da organização, garantindo que clientes, usuários finais e desenvolvedores tenham um entendimento comum da mesma e possam derivar os requisitos dos sistemas que a suportam. Requisitos: Direciona o desenvolvimento rumo ao sistema certo. Isto é alcançado através da descrição dos requisitos do sistema, de forma que um acordo sobre o que o sistema deve ou não fazer possa ser alcançado entre o cliente (incluindo usuários) e os desenvolvedores do sistema. O maior desafio é representar a captura de requisitos de forma que o cliente, que assumimos não ser um especialista em computadores, possa entender. O resultado também ajuda o gerente do projeto a planejar as iterações e as versões para o cliente. Análise e Projeto: Possibilita a transformação dos requisitos em um projeto do sistema, sugerindo uma arquitetura robusta e adaptando o projeto para o ambiente de implementação. Implementação: Define a organização do código, em termos de implementação de subsistemas dispostos em camadas, implementa as classes e objetos em termos de componentes, testa os componentes desenvolvidos como unidades e integra os resultados produzidos por implementadores individuais ou equipes em um sistema executável.

•

•

Teste: Verifica a integração entre objetos, a integração formal de todos os componentes de software, se todos os requisitos foram corretamente implementados e identifica e garante que defeitos serão resolvidos antes da implantação do software. Implantação: Produz versões do produto e disponibiliza essas versões para o usuário. O workflow cobre uma grande variedade de atividades, incluindo: produzir versões, empacotar, distribuir e instalar o software, produzir assistência/ajuda ao usuário e em muitos casos, planejar e conduzir os beta testes e realizar a migração de softwares ou dados existentes.

Os worklows de suporte possibilitam a execução dos workflows de processo. Eles são descritos a seguir: •

•

•

Configuração e Gerenciamento de Mudanças: Este workflow é essencial para controlar os diversos artefatos produzidos pela pessoas que trabalham em um mesmo projeto. O controle ajuda a evitar confusões e garante que os artefatos resultantes não são conflitantes. Gerenciamento de Projeto: Fornece um framework para o gerenciamento de projetos de software, guidelines para planejamento, contratação de pessoal, execução e monitoração de projetos e um framework para gerenciamento de riscos. Ambiente: Provê a organização com o ambiente de desenvolvimento de software (processos e ferramentas). Não cobre alguns aspectos como seleção, aquisição e utilização de ferramentas e manutenção do ambiente. O workflow enfatiza as atividades para configurar o processo no contexto de um projeto.

4. Instaciando o RUP para o Desenvolvimento de Software para a Web O RUP, conforme especificado em [5], é um framework de processo genérico que pode ser especializado para várias classes de sistemas de software, diferentes áreas de aplicação, diferentes tipos de organizações, diferentes níveis de competência e diferentes tamanhos de projeto. Portanto, para considerar o desenvolvimento de WIS (Web Information System) necessitamos instancia-lo para que as características específicas de tal categoria de sistemas sejam consideradas. Nos tópicos que se seguem, estaremos preocupados em apresentar algumas questões que devem ser consideradas no instanciamento do RUP para o desenvolvimento de WIS. As questões serão apresentadas conforme as etapas de desenvolvimento, estando classificadas em modelagem de negócios (seção 4.1), requisitos (seção 4.2), análise e projeto (seção 4.3), implementação (seção 4.4) e testes (seção 4.5). 4.1. Modelagem de Negócios Considerando-se a modelagem de negócios de WIS e as características desse domínio de aplicação, seria necessário um maior detalhamento na especificação dos processos de negócios, para uma melhor definição de suas propriedades. Esse detalhamento deve ser em termos de definição de atributos e propriedades, restrições, dados esperados para a realização do negócio (realizados pelas atividades de suporte) e dados produzidos pela execução dos negócios (realizados pelas atividades fins). O objetivo da modelagem de negócios é definir um subconjunto de requisitos de automação, e não todos os requisitos da aplicação. Porém, diante da dificuldade para elicitação de requisitos, inerente a WIS, através das técnicas tradicionais, esse

detalhamento proposto pode aproximar o subconjunto de requisitos, levantado nessa fase, do conjunto total dos requisitos da aplicação. Essa tarefa pode ser auxiliada pelo estudo minuncioso de sistemas tradicionais e/ou WIS, ou até mesmo práticas de trabalho não informatizadas, dentro ou fora da organização, que executam atividades similares e já são bem definidas. O tempo para desenvolvimento de um WIS deve ser recorde, sendo comumente denominado Web Time. Por isso, na maioria dos casos, a modelagem de negócios realizada deve se ater ao processo que se deseja automatizar e não à análise de toda a organização. De qualquer forma a modelagem da organização como um todo deve ser realizada, provavelmente em algum momento anterior ao do desenvolvimento do WIS, pois ela é de fundamental importância para a identificação de sistemas legados, práticas de trabalho que se devem considerar e interfaces com outros processos de negócios aos quais se deve integrar, oferecendo suporte a um maior entendimento do contexto organizacional e do processo de manutenção. Para uma melhor especificação dessa versão mais detalhada do modelo de negócios, protótipos iniciais de GUI (Graphic User Interface) poderiam ser sugeridos pelos analistas de negócios. Estes protótipos representariam uma versão não técnica da GUI, e seus componentes poderiam ser reusados em protótipos posteriores ou mesmo na versão final da GUI. 4.2. Requisitos A etapa de requisitos é crítica para o desenvolvimento de sistemas de software, em especial para WIS. O desenvolvimento de um bom sistema depende da definição correta de um conjunto completo de requisitos. No caso de WIS a elicitação desse conjunto de requisitos se torna uma tarefa bastante complexa [14], devido à quantidade e variedade de usuários e à sua distribuição geográfica. Pessoas de todo o mundo e com experiências e habilidades das mais variadas poderão fazer parte do conjunto dos usuários do sistema e, portanto, devem ter seus objetivos realizados. Há, então, a necessidade de se ater a um grupo base de tipos de usuário. A variedade e distribuição geográfica desses usuários exigem novas técnicas de elicitação e interação [14], possibilitando que os mesmos façam parte do processo de desenvolvimento e tenham suas necessidades alcançadas. A participação do grupo de marketing pode ser de grande ajuda na definição do grupo base de usuários e de técnicas especiais de elicitação. A própria Web enquanto meio de comunicação e disseminação de informação pode ser usada para solucionar alguns desses problemas [14]. Pode-se estudar o uso de alguns tipos de questionários on-line, fóruns de discussão e até mesmo "chats" para resolução dos problemas de elicitação e interação. Questões como resolução de conflitos quando da atividade de análise e negociação (devido ao distanciamento dos usuários) e produção de um documento de requisitos mais formal (uma vez que provavelmente os usuários não terão acesso a esse documento devido a sua distribuição pela rede) também devem ser analisadas. Um WIS geralmente é composto de aplicação em si (transações de negócio) e apresentação de informações e mídias (páginas de informação) [9]. Para tanto, deve haver a identificação dos limites entre ambas as partes [9] para separação dos requisitos referentes às mesmas. Os requisitos de informação podem ser vistos como dados adicionais para questões de apresentação e não como dados fundamentais. Adicionalmente, surgem novas características e restrições que devem ser consideradas e elicitadas de alguma forma, como:

• • • •

Localização dos possíveis usuários na rede (análise de backbone e gateway); Plataforma padrão (browsers); Restrições de resistência da aplicação; Consideração do protótipo da modelagem de negócios, etc.

4.3. Análise e Projeto Como já observamos anteriormente, um WIS é composto de transações de negócio e apresentação de informações e mídias (páginas de informação). A etapa de análise e projeto necessita ser modificada para considerar, também, a análise e projeto das páginas de informações. O projeto destas páginas deve realizar atividades similares às do projeto de aplicação, como por exemplo, definição da arquitetura, análise de conteúdo e revisões. Devemos considerar a possibilidade e utilidade de prototipação e até mesmo de implementação definitiva do projeto das páginas de informação nesta fase. Pode-se, também, estudar a viabilidade de implantação de uma versão do WIS, que já possua as páginas de informação construídas, para questões de marketing, por exemplo. O projeto de páginas de informação é importante pois influencia na definição da arquitetura e na divisão da aplicação em componentes. Do ponto de vista da aplicação, várias questões devem ser observadas durante a etapa de análise e projeto. A arquitetura em qualquer sistema de software intensivo possui grande importância. Em um WIS a arquitetura possui um impacto ainda maior, pois passa a ter dois níveis [15]: macro arquitetura e arquitetura de aplicação. A nível de macro arquitetura deve-se definir atividades para projeto da mesma, que considerem questões de backbone, largura de banda passante, espelhamento e distribuição geográfica do núcleo base de usuários. Estas questões impactam a performance da aplicação como um todo. A definição da macro arquitetura é importante pois influencia na definição da arquitetura de aplicação. Do ponto de vista da arquitetura da aplicação as atividades de análise e projeto devem ser modificadas para contemplar questões como desenvolvimento multi-camadas (encapsulando lógica de negócios e integrando múltiplos sistemas legados), escalabilidade, performance sobre carga de volume variável, volume de transações alto e imprevisível, resistência, distribuição, divisão em componentes e adaptabilidade. Atividades que levam em consideração esse tipo de arquitetura são de fundamental importância. A arquitetura construída através das novas atividades deve ser testada o quanto antes [16], para evitar que o sistema projetado seja considerado ineficiente e depois de implementado tenha que ser alterado ou mesmo descartado. Mudanças na arquitetura, após a implementação do sistema, possuem um custo elevado. Para tanto, seria suficiente uma atividade de prototipação para avaliação das questões arquiteturais (macro arquitetura e arquitetura de aplicação) já citadas. Esses protótipos deveriam ser executados em um ambiente similar ao real para obtenção de dados realísticos. Componentes desses protótipos podem ser utilizados, posteriormente, na implementação. Outro ponto importante e que precisa ser considerado mais a miúdo é a análise e projeto de mecanismos de segurança. Em um WIS, a segurança é de fundamental importância devido a disponibilidade dos serviços através da Internet e ao caráter dos negócios geralmente realizados nesses serviços. A segurança deve ser considerada tanto a nível de macro arquitetura (firewalls) quanto a nível de aplicação (mecanismos de autenticação de usuário e segurança de transações e dados).

4.4. Implementação Na etapa de implementação algumas questões devem ser consideradas. A implementação da aplicação em si e a construção das páginas de informação podem ser realizadas em paralelo. A construção das páginas de informação poderia ser realizada na primeira iteração da fase de construção, podendo ser disponibilizada na Web tão logo fique pronta, por questões de marketing, como já observado. A construção da páginas HTML pode ser vista mais como um problema de autoria do que de implementação. A realização dessa atividade é mais apropriada para artistas, designers gráficos e outros, do que para o pessoal técnico. Esse tipo de profissional deve ser incorporado ao projeto de um WIS [3,16]. Em termos de implementação de aplicação, restrições relevantes à tecnologia de implementação, devido a plataforma a ser utilizada, devem ser consideradas. Devido ao Web Time para desenvolvimento de WIS, deve-se analisar incessantemente a possibilidade de reuso de componentes [16] já implementados por terceiros e até mesmo componentes de protótipos desenvolvidos durante o projeto. Do ponto de vista de implementação dos componentes identificados no projeto, deve-se priorizar a implementação de componentes de maior importância, principalmente os que impactam a arquitetura, pois possuem maior risco associado e devem ser rapidamente testados. 4.5. Testes Como já dito, WIS são sistemas de software intensivos (são executados praticamente sem interrupção sob um grande volume de acessos) que, entre outros atributos, devem possuir performance aceitável sobre uma carga de trabalho variável, mecanismos de segurança confiáveis e resistência. As atividades de teste devem se preocupar não somente com os testes de requisitos funcionais, mas também de requisitos não funcionais, principalmente os que tenham impacto sobre os atributos supracitados [16]. Estes testes devem ser realizados em um ambiente similar ao real, para que os resultados obtidos sejam realísticos. Para tanto e tendo a Web como ambiente, devem ser consideradas questões como testes de acesso a partir de outras redes(preocupações com backbone; testes de macro arquitetura), testes em vários horários (principalmente horários de pico) e testes sobre carga diferenciada (principalmente sobre carga pesada). Devemos considerar, também, testes de navegabilidade, usabilidade e consistência de links e conteúdo para a parte de apresentação de informações e mídias (páginas de informação), pois estes são de fundamental importância. Testes de WIS, devido ao seu ambiente de execução (Web), requerem novas técnicas e estratégias [3] para a sua realização. Pode-se pensar em mecanismos de monitoração e acompanhamento de execução on-line, capitando tendências de uso e erros através de logs. A análise destes logs pode ser útil para a proposta de mudanças. 5. Conclusões A análise das características de alguns dos workflows de processo do RUP mostra que algumas atividades necessitam ser instanciadas e algumas ações complementares inseridas para consideramos o desenvolvimento de sistemas baseados na Web. A tabela 1 sumariza o suporte do processo ao desenvolvimento de software para a Web.

Características do Desenvolvimento de Suporte do RUP Sistemas Baseados na Web Modelagem de Negócios Definição e detalhamento dos processos de negócio. Protótipos iniciais de GUI (Graphic User Interface)

Suporta parcialmente – não especifica a importân-cia do detalhamento dos processos de negócio. Não suporta.

Requisitos Novas técnicas de elicitação.

Não suporta - fornece alguns "guidelines" e técnicas de elicitação, mas nenhum especifico para sistemas baseados na Web.

Formas alternativas para interação permitindo que o usuário possa participar do desenvolvimento.

Não suporta. Não suporta - não específica a participação do pessoal de marketing em alguma atividade. Não suporta. Suporta parcialmente - o documento de requisitos não deve ser de todo formal, pois deve ser entendido pelo usuário. Não suporta - não considera a divisão aplicação X páginas de aplicação. Não suporta - não especifica que características e restrições específicas de sistemas baseados na Web devem ser consideradas.

Participação do grupo de marketing Novas formas para negociação de conflitos. Documento de requisitos mais formal. Separação dos requisitos da aplicação e das páginas de informação. Elicitação de novas características e restrições.

Análise e Projeto Separação da análise e projeto da aplicação da analise e projeto das páginas de informação. Prototipação ou implementação das páginas de informação. Divisão da arquitetura em arquitetura de aplicação e macro arquitetura.

Não suporta - não considera a divisão aplicação X páginas de aplicação. Não suporta – normalmente esta atividade seria realizada durante a etapa de implementação. Suporta parcialmente – suporta análise e projeto de arquitetura e descrição da distribuição, mas não específica a macro arquitetura.

Prototipação e teste da arquitetura de aplicação e da macro arquitetura.

Não suporta.

Análise e projeto de mecanismos de segurança.

Não suporta - não considera atividades específicas para este fim.

Implementação Separação da implementação da aplicação e das páginas de informação. Incorporação de pessoal não técnico (artistas, designers gráficos, etc.). Restrições relevantes à tecnologia de implementação.

Não suporta - não considera a divisão aplicação X páginas de aplicação. Não suporta - não prevê a incorporação de pessoal não técnico no projeto do sistema. Suporta parcialmente.

Suporta parcialmente – não específica a importância do reuso no caso de sistemas Web. Suporta - a priorização dos primeiros requisitos a Consideração de priorização na implementação de serem analisados, projetados e consequentemencomponentes. te implementados é feita na fase de requisitos. Consideração de reuso de componentes.

Testes Testes de requisitos não funcionais, principalmente performance sobre carga variável, mecanismos de segurança e resistência.

Suporta parcialmente – não específica quais requisitos não-funcionais devem ser testados no caso de sistemas baseados na Web. Suporta parcialmente – não específica quais são Utilização de um ambiente real e em situações as situações reais padrões para a realização dos reais para a realização dos testes. testes. Testes específicos para as páginas de informação Não suporta. Novas técnicas e estratégias para a realização dos Não suporta - não prevê testes especiais para testes. sistemas baseados na Web. Tabela 1. Suporte do RUP ao desenvolvimento de software para a Web

A partir da analise realizada pela identificação das atividades que necessitam ser instanciadas e das ações complementares que necessitam ser inseridas, para adaptarmos o RUP ao desenvolvimento de sistemas baseados na Web, verificamos a necessidade de propostas concretas para a implementação dessas alterações ou passos de instanciamento. A implementação dessas alterações é de fundamental importância para o uso adequado deste processo no desenvolvimento deste tipo de sistema. Como trabalhos futuros podemos citar a adequação do fluxo de análise e projeto do RUP ao desenvolvimento de WIS e a realização de um estudo de caso para a avaliação das propostas feitas e do trabalho de adequação realizado. 6. Referências [1] W. Gibbs. "Software's chronic crisis". Scientific American, September, 1994. [2] R. S. Pressman. Software Engineering: A Practitioner's Approach. McGraw-Hill, 3ª ed., 1992. [3] S. Hansen, Y. Deshpande, S. Murugusan and A. Ginige. Web Engineering: A New Discipline for Development of Web-based Systems. First ICSE Workshop on Web EngineeringI, Los Angeles, USA, May, 1999. [4] N. Zelnick. Nifty Technology and Nonconformance: The Web in Crisis. Computer, pp. 115-116 and 119, October, 1998. [5] I. Jacobson, G. Booch and J. Rumbaugh. The Unified Software Development Process. Addison Wesley, ISBN 0-201-57169-2, 1998. [6] T. Berners-Lee. WWW: Past, Present and Future. IEEE Computer, Vol. 29, No. 10, pp. 69-77, October, 1996. [7] S. Nambisan and Y. Wang. Roadblocks to Web Technology. Communications of the ACM, pp. 98-101, January, 1999. [8] G. L. Rein, D. L. McCue and J. A. Stein. A case for document manegement function on the Web. Communications of the ACM, pp. 81-89, September, 1997. [9] D. Schwabe, G. Rossi. A. Garrido, Designing Web Information Systems. [10] V. Turau. What Pratices Are Being Adopted on the Web. IEEE Computer, pp. 106-108, May, 1998. [11] E. K. Clemons and M. C. Row. Information Technology at Rosenbluth Travel: Competitive advantage in a rapidly growing global service company. J. Manage, Info. 8, 2(1991), pp. 53-79. [12] O. Kirter. Security issues delay Internet use in health care. Commmunication News 34, 5, May, 1997. [13] Booch G., Jacobson I., Rumbaugh J., Unified Modeling Language -User's Guide, Addison-Wesley, 1999. [14] K. S. Norton. Applying cross-functional evolutionary methodologies to Web development. First ICSE Workshop on Web EngineeringI, Los Angeles, USA, May, 1999. [15] J. Conallen. Modeling Web Application Architectures with UML. Communications of the ACM, Vol. 42, No. 10, pp. 63-70, October, 1999. [16] D. Seibert, J. Robbins, K. Vollert and J. Schuster. Building Web Solutions with the Rational Unified Process: Tuning Your Architecture Through Load-Testing. Rational Software white paper (http://www.rational.com).