ISSN 0103-9741 Monografias em Cincia da Computao n 23/09

Processos para Desenvolvimento de Aplicaes Web

Mark Douglas de Azevedo Jacyntho

Departamento de Informtica

PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO RUA MARQUS DE SO VICENTE, 225 - CEP 22453-900 RIO DE JANEIRO - BRASIL

Monografias em Cincia da Computao, No. 23/09 Editor: Prof. Carlos Jos Pereira de Lucena

ISSN: 0103-9741 Julho, 2008

Processos para Desenvolvimento de Aplicaes Web

Mark Douglas de Azevedo Jacyntho
mjacyntho@inf.puc-rio.br

Abstract. Web application development presents significant differences from conventional application development. The spectrum varies from technical to organizational differences. Technical means the specific architectures and technologies employed and the impacts involved. Organizational is related to the strategic use of these applications aiming at improving the business. Among other issues, uncertainty, volatility and high competitiveness are innate characteristics which must be carefully addressed. Therefore, the nature of web engineering suggests the need of specialized software processes that cover, in a systematic way, the complete life cycle of hypermedia web applications, in contrast to adopting ad-hoc approaches to comply with the constraints imposed by this application domain. This essay presents an abridge discussion concerned with the impact of these differences on development process for web applications, analyzing some proposals, indentifying the requirements and challenges. This work intends to be an initial step towards the definition of a process suitable to web development, in dimensions such as requirements gathering, user interface, testing and navigation design. Keywords: web process, web engineering, web development, software process, software engineering, software development. Resumo. Desenvolvimento de aplicaes web apresenta diferenas significativas com relao ao desenvolvimento de aplicaes convencionais. O espectro varia desde diferenas tcnicas at organizacionais. Diferenas tcnicas significam as arquiteturas e tecnologias especficas empregadas e os impactos envolvidos. J as organizacionais so relacionadas ao uso estratgico destas aplicaes visando melhorar o negcio. Dentre outros fatores, incerteza, volatilidade e alta competitividade so caractersticas inerentes que precisam ser consideradas. Por conseguinte, a natureza da engenharia para web sugere a necessidade de processos de software especializados que atendam, de forma sistemtica, o ciclo de vida completo de aplicaes web hipermdia, em contraste com a adoo de abordagens ad-hoc para lidar com as restries impostas por este domnio de aplicaes. Esta monografia apresenta uma breve discusso sobre o impacto destas diferenas em processos de desenvolvimento para aplicaes web, analisando algumas propostas, identificando os requisitos e desafios. Este trabalho pretende ser um passo inicial rumo definio de um processo apropriado para o desenvolvimento web, em dimenses como levantamento de requisitos, interface com o usurio, testes e projeto de navegao. Palavras-chave: processo web, engenharia para web, desenvolvimento web, processo de software, engenharia de software, desenvolvimento de software. ___________________
Trabalho patrocinado pelo Ministrio de Cincia e Tecnologia da Presidncia da Repblica Federativa do Brasil (e CNPq, processo: 142192/2007-4).

Responsvel por publicaes: Rosane Teles Lins Castilho Assessoria de Biblioteca, Documentao e Informao PUC-Rio Departamento de Informtica Rua Marqus de So Vicente, 225 - Gvea 22451-900 Rio de Janeiro RJ Brasil Tel. +55 21 3527-1516 Fax: +55 21 3527-1530 E-mail: bib-di@inf.puc-rio.br Web site: http://bib-di.inf.puc-rio.br/techreports/

ii

Sumrio
1 Introduo 1.1 Processos Orientados a Plano versus Processos geis 1.2 Organizao da Monografia 2 Diferenas entre Aplicaes Web e Aplicaes Convencionais 2.1 Diferenas Tcnicas 2.2 Diferenas Organizacionais 3 Requisitos de um Processo de Desenvolvimento Web 4 Duas Propostas Existentes 4.1 XWebProcess 4.2 OPEN-Web Process 5 Avaliao das Propostas Apresentadas 6 Consideraes Finais 1 2 3 3 3 5 6 7 7 14 19 23

ndice de Figuras
Figura 1. Passos de criao do XWebProcess [Sampaio et al, 2004a] ................................... 9 Figura 2. Viso dinmica do XWebProcess [Sampaio et al, 2004a]..................................... 10 Figura 3. Explorao no XWebProcess [Sampaio et al, 2004a] ............................................ 12 Figura 4. Requisitos no XWebProcess [Sampaio et al, 2004a].............................................. 12 Figura 5. Anlise e Design no XWebProcess [Sampaio et al, 2004a] .................................. 13 Figura 6. Navegao e Apresentao no XWebProcess [Sampaio et al, 2004a] ................ 13 Figura 7. Testes Web no XWebProcess [Sampaio et al, 2004a]............................................ 13 Figura 8. Suporte Web no XWebProcess [Sampaio et al, 2004a] ......................................... 13 Figura 9. Componentes do meta-processo OPEN [OPEN] ................................................ 15 Figura 10. Work Units do meta-processo OPEN [Lowe e Henderson-Sellers, 2001] ..... 15 Figura 11. Exemplo de Stages do OPEN [OPEN]................................................................. 16 Figura 12. Instanciao do framework OPEN [OPEN]....................................................... 16

ii

1 Introduo
Vrios processos de software tm sido propostos ao longo dos anos. Essencialmente todos tentam definir um roadmap que guie o desenvolvimento, identificando quem est fazendo o qu, onde, por que, como e quando. Um processo de software definido com um conjunto de atividades interdependentes que visam desenvolver, manter e gerenciar sistemas de software. Estas atividades podem ser compostas de outras atividades e so executadas por atores que desempenham um papel no processo (programador, gerente, cliente, etc.). Como resultado das atividades, so produzidos artefatos (cdigo, documentao, modelos) que servem de entrada para outras atividades para produzir novos artefatos. Sem um processo de software, o risco de falha do projeto se torna muito alto, em especial para as aplicaes web modernas cuja complexidade no pra de crescer. Com o passar dos anos, as aplicaes web evoluram rapidamente de simples web sites cujo propsito era apenas navegao sobre a informao para verdadeiros sistemas de informao altamente complexos, repletos de dados e transaes, voltados para a implementao de processos de negcio intra- e inter-organizao. Diante deste quadro, a necessidade de um processo de software sistemtico que ajude a gerenciar o ciclo de vida de tais aplicaes surge naturalmente. Poder-se-ia argumentar que sistemas web no so diferentes, sob o ponto de vista de processo de software, de sistemas de software convencionais. No obstante, existe um crescente reconhecimento que sistemas web possuem caractersticas particulares que no so apropriadamente consideradas pelos processos de software tradicionais. O desenvolvimento de aplicaes web realizado por equipes multidisciplinares, com diferentes habilidades, em prazos curtssimos ditados pela voraz concorrncia e em um contexto extremamente volvel, marcado por incertezas. Para completar, sistemas web so tecnologicamente muito abstrusos, reunindo padres, protocolos e tecnologias diversas na definio de uma arquitetura que encapsule em um front-end amigvel um back-end que pode ser por demasiado complexo e heterogneo. Em muitos casos, as equipes de desenvolvimento, acometidas pelas severas restries de tempo, adotam solues ad-hoc para construir tais aplicaes. Neste cenrio, o sucesso do projeto depende muito da habilidade e conhecimento dos membros da equipe, com os usuais efeitos colaterais negativos em flexibilidade, qualidade e robustez da aplicao [Sampaio et al, 2004a]. Como de se esperar, paralelamente s diferenas, tambm co-existem pontos em comum entre aplicaes web e convencionais. Portanto, um caminho interessante seria delinear as peculiaridades deste domnio de aplicao e adaptar ou enriquecer processos de software j existentes de forma a contemplar mais claramente as necessidades especficas da web. Sob a tica deste trabalho, importante ressaltar a diferena entre aplicao na web e aplicao web. Aplicao na web qualquer tipo de aplicao que utiliza a web como ambiente de execuo. Um simples repositrio de arquivos ou uma aplicao com estilo tradicional desktop, composta apenas por buscas e formulrios, so exemplos de aplicao na web. J aplicaes web so aquelas que, necessariamente, exploram o paradigma hipermdia. Em outras palavras, no contexto deste trabalho, somente so consideradas aplicaes web aquelas que possuem uma estrutura navegacional bem defini-

da, fazendo jus ao elemento fundamental da web que a noo de hiperlink. O grande desafio das aplicaes web modernas integrar, elegantemente, dois paradigmas capitais: hipermdia e transao. Sendo assim, este trabalho procurar evidenciar os requisitos que um processo de desenvolvimento de software precisa atender de modo a ser, efetivamente til, nesta integrao. Esta monografia considera as diferenas entre aplicaes web e convencionais, destacando as implicaes na definio de um processo de software para web. Para tal, definida uma lista de requisitos que um processo web deve atender e, com base nesta, so analisadas duas propostas existentes.

1.1 Processos Orientados a Plano versus Processos geis

Mais recentemente os processos de software passaram a ser classificados em duas categorias: orientados a plano e geis. Processos orientados a planos so processos mais rigorosos, preditivos por natureza, onde existe um plano que procura antever problemas e as respectivas solues. Ao longo do desenvolvimento todas as decises de projeto so documentadas e controladas, antes de serem implementadas. O foco no processo, ou seja, institucionalizar um processo de software e segui-lo a risca. Este processo deve ser continuamente aprimorado. So exemplos: CMMI - Capability Maturity Model Integration [Chrissis et al, 2003], TSP - Team Software Process [Humphrey, 2000], PSP Personal Software Process [Humphrey, 1995], SPICE - Software Process Improvement and Capability dEtermination [SPICE]. Por outro lado, processos geis tm o foco no produto em si, ou seja, o mais importante entregar software em detrimento de documentao. So reativos por natureza, onde atitudes so tomadas sob demanda e desenvolvido somente o necessrio e quando necessrio. Trata-se de um desenvolvimento iterativo e incremental onde, constantemente, so entregues novos releases do produto ao cliente. As idias podem ser encontradas no Agile Manifesto [Agile Manifesto]. Os elementos centrais do manifesto so: Pessoas e interaes so mais importantes do que processos e ferramentas; Software executvel mais importante do que documentao; Colaborao do cliente mais importante do que negociao por contrato; Reao a mudanas mais importante do que plano pr-definido.

Processos rigorosos e processos geis, ambos tm suas vantagens e desvantagens. No existe processo correto ou incorreto, existe processo adequado e inadequado, ou seja, para cada tipo de projeto necessrio encontrar um ponto de equilbrio entre as duas abordagens e definir um processo hbrido que traga benefcios reais [Bohem e Turner, 2004]. Independentemente de quo rigoroso ou gil seja o processo, o fato que temos que levar em considerao como contemplar os requisitos presentes no desenvolvimento web, discutidos ao longo deste trabalho. No entanto, o carter altamente mutvel das aplicaes web nos leva a crer que uma abordagem mais gil venha mais ao encontro deste domnio de aplicaes do que um processo mais rigoroso.

1.2 Organizao da Monografia

A seco 2 explora as diferenas entre sistemas web e sistemas convencionais. Em seguida, na seco 3, so enumerados os requisitos que devem ser levados em considerao quando da elaborao de um processo de desenvolvimento para web. Para tornar a discusso mais concreta, a seco 4 apresenta duas propostas de processo web existentes. Seguindo na mesma linha, na seco 5, as propostas apresentadas so analisadas de acordo com os requisitos descritos anteriormente. Encerrando, a seco 6 delineia as consideraes finais.

2 Diferenas entre Convencionais

Aplicaes

Web

Aplicaes

Existe um conjunto de diferenas que justificam a necessidade de uma ateno especial ao desenvolvimento de aplicaes web. Algumas caractersticas so nicas de sistemas web, outras tambm esto presentes nos sistemas convencionais, mas so mais pronunciadas na web. Com base em [Lowe e Henderson-Sellers, 2001] e [Kappel et al, 2004], esto seco destaca tais diferenas que servem como base para a definirmos os requisitos necessrios para a definio de um processo de desenvolvimento para web. A distino feita primeiramente sob um enfoque tcnico e, em seguido, questes organizacionais so discutidas.

2.1 Diferenas Tcnicas

Claramente existem diferenas tcnicas entre sistemas web e convencionais. As mais significantes so: Diferenas relativas aplicao: o Contedo: a web essencialmente um meio de informao. Alm da funcionalidade, uma aplicao web orientada a contedo. Contedo compreende dados estruturados (banco de dados, por exemplo) e no estruturados (arquivos textos, vdeos, etc.). Alm disso, o contedo dinmico, precisa ser continuamente atualizado e de qualidade em termos de consistncia e confiabilidade. Isto implica em um efetivo projeto de informao, bem como gerenciamento de contedo apropriado. Hipertexto: na web o paradigma fundamental para estruturar a informao noo de hipertexto, onde os elementos bsicos so: ns, elos (links) e ncoras que ativam estes elos. Os ns exibem informaes e os elos nos permitem navegar entre os ns. Isto requer um projeto cuidadoso e estratgico de navegao que preserve a qualidade de acesso e evite desorientao e sobrecarga cognitiva. Apresentao: o look and feel da aplicao web um fator de qualidade essencial uma vez que usurios podem facilmente abandonar o site e ir para outro concorrente. No existe um manual de usurio, portanto a interface tem que ser auto-explicativa, intuitiva e consistente com o estilo de interao. Alm disso, a aparncia visual est sujeita a modismo, tendncias e novas caractersticas tcnicas que surgem todos os dias.

Requisitos no-funcionais de qualidade: requisitos de qualidade como disponibilidade 24/7, performance, usabilidade, escalabilidade, robustez e segurana se tornam ainda mais crticos quando expostos externamente ao pblico.

Diferenas relativas ao uso: o Ubiqidade: medida que a necessidade de ubiqidade (ou seja, a possibilidade de acessar a aplicao por diferentes tipos de dispositivos, em diferentes contextos de uso) das aplicaes cresce, torna-se necessrio projetar diferentes vises da aplicao, uma para cada contexto de uso. Infra-estrutura tecnolgica imprevisvel: juntamente com o crescente carter ubquo, surge uma enorme variedade de dispositivos de usurio final, com diferentes capacidades de hardware e software, diferentes tamanhos e verses de navegadores. Conexes de rede diferem com respeito largura de banda, confiabilidade, estabilidade e disponibilidade, afetando a questo de QoS (qualidade de servio). Por fim, usurios configuram livremente seus navegadores, podendo desabilitar importantes funcionalidades. Ambiente de desenvolvimento: a infra-estrutura tcnica usada para desenvolver sistemas web caracterizada por exacerbada volatilidade e heterogeneidade. As aplicaes so freqentemente construdas a partir de componente COTS (commercial off-the-shelf) que so adaptados e integrados, particularmente para as camadas internas de middleware. Dentre estes componentes se destacam servidores de aplicao e frameworks de aplicao e persistncia. Isto aumenta a importncia de criar solues flexveis que possam migrar para novas tecnologias com pouco esforo. Outra conseqncia o domnio restrito destas tecnologias por parte da equipe, aumentando o risco do projeto e demandando um constante aprimoramento do conhecimento. Integrao com sistemas legados: aplicaes web costumeiramente precisam se integrar com sistema legados. So sistemas com interfaces antigas e inapropriadas que, portanto, precisam ser encapsuladas e adaptadas (wrapping). Este encapsulamento trabalhoso e existe o risco de no ser feito de forma correta e completa. Sistemas legados raramente so documentados e freqentemente so modificados sem notificao, afetando a execuo do sistema web. Alm disso, as tecnologias para encapsulamento so vrias e esto sempre mudando (por exemplo, encapsulamento via web services).

Diferenas relativas ao desenvolvimento: o

2.2 Diferenas Organizacionais

Sob o ponto de vista organizacional, as diferenas mais proeminentes so: Diferenas relativas ao desenvolvimento: o Incerteza do cliente: devido alta dinamicidade da web, este domnio de aplicaes no bem compreendido pelos interessados (tambm chamados de stakeholders). Freqentemente o cliente tem problemas em articular suas necessidades, bem como em compreender se um determinado design satisfaz suas expectativas. Alm disso, muito comum a existncia de projetos orientados por uma idia visionria ao invs de uma necessidade bem definida. Isto aumenta a necessidade de desenvolvimento incremental baseado em prottipos. Alta volatilidade dos requisitos de negcio: fortemente relacionada questo anterior est a falta de clareza, por parte do cliente, sobre os reais impactos que a aplicao web traz para o negcio. Sendo assim, no surpresa esperar que o escopo e foco do projeto mudem consideravelmente ao longo do desenvolvimento. medida que a empresa vai aumentando sua participao na web, o prprio modelo de negcio da empresa pode mudar diante de novas oportunidades outrora desconhecidas. Ciclos de desenvolvimento muito curtos: projetos web, em geral, tm prazos mais curtos do que projetos convencionais, comumente de um a trs meses. Alta competitividade: a concorrncia na web muito mais intensificada pela facilidade do usurio final visitar vrios sites em um curto espao de tempo. Portanto, a aplicao precisa estar sempre atualizada e atraente de acordo com as tendncias atuais. Equipes multidisciplinares: o desenvolvimento de uma aplicao web um esforo multidisciplinar, envolvendo profissionais das mais diversas reas, com habilidades bem dspares. So designers grficos, autores, engenheiros de software, programadores, publicitrios, consultores de negcio, entre outros. Em geral, h muito jovens inexperientes inclinados a empregar tecnologias novas de forma ad-hoc. Evoluo e manuteno de granularidade fina: aplicaes web esto sujeitas a mudanas dirias e permanente evoluo. Tipicamente temos um processo contnuo de atualizao de contedo, mudanas editoriais, ajustes de interface, etc. Sem falar nas mudanas tecnolgicas mais radicais. Diversidade de tipos de usurio: na web os usurios variam em idade, conhecimento scio-cultural, objetivos, intenes, habilidades e capacidades. Esta heterogeneidade, diferentes perfis de usurio, precisa ser considerada, dado que na web os usurios so inteiramente livres para escolherem as aplicaes que lhe forem mais convenientes.

Diferenas relativas ao uso: o

Sazonalidade (ou caractersticas temporrias): aplicaes possuem requisitos que so sazonais ou temporrios, ou seja, informaes e/ou funcionalidades que so oferecidas, estrategicamente, por uma faixa de tempo, que pode se repetir ou no. Um exemplo so os contextos navegacionais relacionados ao perodo natalino.

Analisando o que foi exposto nesta seco, percebe-se que um processo de desenvolvimento voltado para aplicaes web caracterizado por freqentes mudanas e ajustes, que so necessrias devido rpida evoluo tecnolgica, ao surgimento de novas tendncias, volatilidade dos requisitos e aos cronogramas apertados. Um processo para web precisa ser altamente iterativo, flexvel e orientado a prottipos.

3 Requisitos de um Processo de Desenvolvimento Web

Sob a luz das diferenas descritas anteriormente e do trabalho exposto em [McDonald e Welland, 2004], foram identificados dezessete requisitos que um processo de desenvolvimento de aplicaes web deve ponderar. Como era de se esperar, estes requisitos se confundem com os requisitos que um mtodo de especificao de aplicaes web (por exemplo, OOHDM [Rossi, 1996]) deve contemplar, reforando a importncia do emprego de um mtodo desta natureza ao longo do processo. Sendo assim, um processo web deve dar suporte para: 1. Autoria (ou engenharia) de contedo; 2. Autoria (ou engenharia) de navegao sobre o contedo; 3. Autoria (ou engenharia) de apresentao (interface); 4. Ubiqidade; 5. Definio de arquitetura multicamadas 5.1. Escolha, adaptao e utilizao de frameworks e componentes; 5.2. Integrao com sistemas legados; 5.3. Distribuio das camadas entre servidores; 5.4. Definio do que roda no navegador e do que roda no servidor; 6. Ciclos de vida de desenvolvimento curtos; 7. Equipes multidisciplinares; 8. Desenvolvimento concorrente de pequenas equipes em tarefas interdependentes; 9. Pesquisa de mercado; 10. Incerteza do cliente e volatilidade dos requisitos; 11. Reengenharia de modelos de negcio a partir de modelos da aplicao; 12. Anlise de negcio e avaliao junto ao usurio final; 13. Diferentes perfis de usurio (personalizao); 14. Requisitos explcitos (funcionais e no-funcionais); 15. Testes rigorosos com relao aos requisitos; 15.1. Teste de performance, escalabilidade e resilincia;

16. Autoria (engenharia) de Segurana 16.1. Autorizao por papis de usurio (user role); 16.2. Definio de quais transaes so crticas (precisam de criptografia) e no-crticas; 17. Manuteno e evoluo em granularidade fina.

4 Duas Propostas Existentes

Diante da crescente necessidade de um processo de desenvolvimento voltado para aplicaes web, ao longo dos ltimos anos, alguns processos especficos e evolues de processos de software tradicionais foram propostos para web. A seguir, sero brevemente descritos dois processos. Uma proposta gil chamada XWebProcess e uma proposta mais rigorosa chamada OPEN-Web Process.

4.1 XWebProcess
XWebProcess [Sampaio, 2004] [Sampaio et al, 2004a] [Sampaio et al, 2004b] um processo gil para desenvolvimento de aplicaes web baseado nos princpios do XP (Extreme Programming) [Beck, 2000]. O XWebProcess resultado da adaptao do XP para lidar melhor com importantes questes de sistemas web: interfaces com usurio complexas, navegao, requisitos no-funcionais (distribuio, concorrncia, balanceamento de carga), testes e suporte de infra-estrutura. Uma vez que o XWebProcess deriva do XP, interessante, em primeiro lugar, apresentar uma breve descrio do XP. O processo gil XP confia em cinco pilares de valor: Comunicao: significa que os membros da equipe devem interagir constantemente para discutir os problemas e propor solues. Alm disso, o cliente, o algum que o represente, deve ser um membro ativo da equipe para elucidar os requisitos e regras de negcio envolvidos; Feedback: implica que cada membro da equipe (programador, gerente, cliente, etc.) deve fornecer feedback constante sobre os problemas encontrados para resolv-los o quanto antes; Simplicidade: consiste em escolher a soluo mais simples que funcione, ou seja, evitar complexidade e trabalho desnecessrio. Fazer estritamente o necessrio e com o design mais simples. Possveis problemas que surjam em funo desta deciso so minimizados com prticas como refactoring e testes automatizados; Coragem: preciso ter coragem para substituir o que est ruim ou errado por algo que esteja melhor ou correto. Ou seja, no tenha medo de fazer refactoring em grandes partes do cdigo quando necessrio, bem como descartar requisitos que se tornem obsoletos. Respeito: os membros da equipe tm que respeitar uns aos outros. No XP, programadores nunca devem confirmar modificaes que faam o programa parar de compilar, que faam os testes falharem, ou caso contrrio atrasam o trabalho de seus companheiros. Devem sempre primar pela qualidade. Sob

outra tica, nenhum membro da equipe deve se sentir rejeitado ou ignorado, de forma a manter a equipe sempre feliz e motivada. Para subsidiar os quatro pilares acima, XP prope algumas prticas que so, resumidamente, descritas a seguir: Planning game (Jogo de Planejamento): um release deve ser o menor possvel (dois a trs meses). Cada release dividido em iteraes semanais (duas a trs semanas), onde historietas (pequenos casos de uso) so implementados. No incio da semana, desenvolvedores e cliente renem-se para analisar as funcionalidades. O esforo estimado para implementar cada historieta definido pelos programadores e o cliente define a prioridade da historieta. Small Releases (Pequenas Verses): um release deve ser pequeno de forma a facilitar o desenvolvimento, bem como o processo de aceitao e satisfao por parte do cliente. Metaphor (Metfora): metfora do sistema uma histria que todos (clientes, programadores, gerentes, etc.) podem contar sobre como o sistema funciona. Enfim, uma histria que facilite o entendimento comum sobre os conceitos (abstraes) envolvidos. Simple Design (Projeto Simples): projetar, de forma simples, estritamente o necessrio sob demanda. Whole Team (Equipe Coesa): o cliente deve ser um membro efetivo da equipe, disponvel para esclarecer eventuais questionamentos. Customer Tests (Testes de Aceitao): testes construdos pelo cliente, em conjunto com analistas e testadores, para validar um ou mais requisitos do sistema. Tambm chamados de testes funcionais. Sustainable Pace (Ritmo Sustentvel): a equipe deve trabalhar em um ambiente adequado e agradvel, sempre motivada e sob um ritmo de trabalho saudvel (40 horas/semana, 8 horas/dia) sem horas extras. Horas extras somente se forem impreterivelmente necessrias. Stand-up Meeting (Reunies em P): reunies em p (por exemplo, no incio do dia) para no perder o foco, somente abordando o que foi realizado e prximas tarefas a realizar. Estas reunies devem ser de curta durao. Collective Ownership (Posse Coletiva): o cdigo fonte um bem comum, ou seja, qualquer membro da equipe pode alterar qualquer parte do cdigo sem precisar pedir permisso. Todos devem ter conhecimento de todas as partes do cdigo. Pair Programming (Programao em Par): todo cdigo produzido por um par de programadores. Um programador codifica e outro analisa, sugerindo melhoramentos e prevenindo erros. Os pares so freqentemente modificados, fazendo com que os programadores participem do desenvolvimento de diferentes historietas, obtendo, desta forma, um conhecimento geral de todo o sistema; Coding Standards (Padres de codificao): devem ser definidos padres (regras) de estruturao do cdigo. Estas regras devem ser seguidas, garantindo assim uma homogeneidade em todo cdigo, facilitando o entendimento.

Test Driven Development (Desenvolvimento Orientado a Testes): primeiro crie os testes unitrios e, somente depois, crie cdigo que passe nos testes. Tal prtica ajuda a manter a qualidade do projeto. Refactoring (Refatorao): o cdigo deve ser, sempre que necessrio, melhorado, sem alterar a funcionalidade. Juntamente com testes automatizados (automated testing) ajuda a manter a qualidade do cdigo, dado que toda vez que ocorre uma alterao todos os testes, na ntegra, tm que ser passados com sucesso. Toda funcionalidade pode ser alterada por qualquer membro da equipe. Continuous Integration (Integrao Contnua): a equipe de desenvolvimento deve trabalhar sempre na ltima verso do projeto. Sempre que uma nova funcionalidade for produzida e passar nos testes, esta deve ser integrada a verso atual do sistema, no repositrio de cdigo. Isto evita atrasos mais tarde devido a problemas de integrao.

O processo XWebProcess foi criado adaptando elementos do XP e adicionado novos elementos de forma a customizar o XP para o domnio web. Primeiramente o XP foi modelado usando o meta-modelo SPEM [SPEM] para melhor entendimento. Em seguida, com base nas caractersticas das aplicaes web, o modelo SPEM do XP foi enriquecido gerando o modelo SPEM do XWebProcess. Sendo assim o XWebProcess pode ser visto como uma extenso do XP, como mostra a figura 1.

Figura 1. Passos de criao do XWebProcess [Sampaio et al, 2004a]

O XWebProcess descrito, em SPEM, usando duas vises: viso dinmica e estrutural. A viso dinmica mostra como as disciplinas1 esto relacionadas entre si durante a execuo do processo, ao longo do tempo. J a viso estrutural descreve a estrutura interna de cada disciplina, destacando atividades, artefatos produzidos e atores envolvidos, bem como os relacionamentos entre eles. A figura 2 ilustra a viso dinmica do XWebProcess. Nesta figura, as disciplinas em destaque so disciplinas inseridas ou modificadas no XP.

1 Uma disciplina em SPEM representa um conjunto de elementos de processo relacionados (atividades, artefatos, atores) agrupados por um tema comum. Exemplos de disciplinas so: anlise, design, testes, etc.

Figura 2. Viso dinmica do XWebProcess [Sampaio et al, 2004a]

O processo comea com uma disciplina exploratria que foi modificada para incluir sesses de prottipo. O objetivo avaliar, junto ao cliente e analistas de negcio, tecnologias, arquiteturas e prottipos para verificar a viabilidade do projeto e definir os requisitos iniciais. Em seguida, temos a disciplina de definio e reviso dos requisitos. Nesta, clientes e programadores definem as historietas para o prximo release. Programadores estimam o esforo necessrio para cada historieta e os clientes definem as prioridades das historietas. Esta disciplina foi modificada para incluir uma atividade de design de arquitetura, visando definir uma estrutura flexvel que permita, mais facilmente, integrao com outros sistemas e adio de novas tecnologias. Com as historietas em mos, clientes e programadores planejam o prximo release, selecionando as historietas a serem implementadas. Dentro de cada release, vrias interaes ocorrem. Em cada iterao, historietas so implementadas e testadas. Para cada iterao ocorrem as seguintes disciplinas: planejamento de iterao, design, escrita de teste de unidade, codificao, teste e integrao. A disciplina de design foi modificada para incluir a atividade de design da camada de dados. Durante uma iterao, pode haver mudanas nos requisitos e estimativas anteriores precisam ser reavaliadas. Escrita de testes funcionais, bem como design de na-

10

vegao e apresentao so feitos em paralelo com as atividades anteriores. A disciplina de design de navegao e apresentao foi inserida devido inquestionvel importncia que estes dois aspectos tm em uma aplicao web. Quando a iterao termina, necessrio verificar se o que foi implementado esta em conformidade com o que se esperava. Portanto, so executados testes funcionais para tal propsito. Alm disso, foi inserida a disciplina de testes web para verificar se os requisitos no funcionais foram atendidos. Se for a ltima iterao do release, a verso corrente do sistema posta em produo. Depois do primeiro release do sistema, entre em cena a disciplina de suporte web que foi inserida com o propsito de lidar com a organizao de componentes de hardware e software que fazem parte do web site. O processo termina quando todas as historietas tiverem sido implementadas e postas em produo. Tendo descrito a dinmica do processo, a seguir ser apresentada a estrutura interna de cada disciplina modificada ou inserida no XP, ou seja, as disciplinas em destaque da figura 2. Para cada disciplina ser apresentada um modelo, similar a um diagrama de classes, usando esteretipos do SPEM. Novamente, em cada figura, sero destacados os elementos que foram modificados ou inseridos no XP. As disciplinas de explorao e definio de requisitos so expostas pelas figuras 3 e 4, respectivamente. Na disciplina de explorao foram includas sesses de prottipo. O web designer responsvel pela atividade de prototipagem cuja sada um prottipo, criado com ajuda de tcnicas de prototipagem. J a disciplina de requisitos foi modificada para incluir a definio da arquitetura geral da aplicao. Esta arquitetura muito importante, pois usada em todas as atividades subseqentes. Quem define o modelo de arquitetura um desenvolvedor experiente que entenda de reuso, manuteno, flexibilidade e performance.

11

Figura 3. Explorao no XWebProcess [Sampaio et al, 2004a]

Figura 4. Requisitos no XWebProcess [Sampaio et al, 2004a]

A disciplina de anlise e design, apresentada na figura 5, foi modificada para incluir a atividade de design de camada de dados, executada pelo DBA. Esta atividade pode ser to simples quanto definir o esquema de um nico banco de dados relacional ou to complexa quanto fazer a mediao entre vrias fontes de dados heterogneas. A figura 6 apresenta uma das mais importantes disciplinas inseridas: navegao e apresentao. O web designer elabora o design de navegao, assistido pelo programador e arquiteto. Para projetar a navegao, mtodos como OOHDM [Schwabe e Rossi, 1995] [Schwabe e Rossi, 1998] so muito bem vindos, pois possuem primitivas com este propsito especfico. O web designer tambm responsvel por projetar a interface abstrata e, com base nesta, a interface fsica.

12

Figura 5. Anlise e Design no XWebProcess [Sampaio et al, 2004a]

Figura 6. Navegao e Apresentao no XWebProcess [Sampaio et al, 2004a]

Para finalizar, as disciplinas de testes web e suporte web so mostradas na figuras 7 e 8, respectivamente. Na disciplina de teste, um programador executa os testes, podendo ser assistido pelo cliente, que os valida, e pelo analista de suporte que configura todo o ambiente para que os testes possam ser realizados. J na disciplina de suporte, o administrador do web site realiza duas atividades: gerenciamento de contedo e gerenciamento de infra-estrutura (scripts, pginas, componentes, vdeos, udio, etc.).

Figura 7. Testes Web no XWebProcess [Sampaio et al, 2004a]

Figura 8. Suporte Web no XWebProcess [Sampaio et al, 2004a]

13

4.2 OPEN-Web Process

OPEN-Web Process [Haire et al, 2001] [Lowe e Henderson-Sellers, 2001] uma extenso do processo OPEN [OPEN] [Graham et al, 1997] [Henderson-Sellers et al, 1998] para desenvolvimento de aplicaes web. OPEN (Object-Oriented Process, Environment, and Notation) um framework de processo, conhecido por OPF (OPEN Process Framework) que abrange o ciclo de vida completo de desenvolvimento, incluindo aspectos de negcio e de software. Trata-se de um meta-processo, a partir do qual pode ser gerado um processo especfico (instncia) para uma dada organizao. OPEN foi desenvolvido e mantido por um consrcio, sem fins lucrativos, composto por pesquisadores, acadmicos, desenvolvedores e empresas. Como pode ser visto na figuras 9 e 10, os maiores componentes deste meta-modelo so: Work Products (artefatos): os componentes que so desenvolvidos no projeto (documento, diagrama, modelo, mdulo, classe, etc.); Languages (linguagens): os componentes usados para documentar os work products (linguagem natural, UML, Java, etc.); Producers (produtores): os componentes que desenvolvem os work products (programador, analista, designer, gerente, cliente, etc.); Work Units (unidades de trabalho): os componentes que modelam as operaes executadas pelos producers ao desenvolver work products. H trs tipos de work unit: o o Activity (atividade): objetivo maior. Define o qu, no como. composto por tasks; Task (tarefa): objetivo menor, ou seja, metas para atingir o objetivo maior. Ainda define o qu, no como. Resultam na criao, modificao ou avaliao de um ou mais work products; Technique (tcnica): define como perfazer uma dada task (casos de uso, cartes CRC, design patterns, entrevista, etc.).

Stages (estgios): os intervalos de tempos que provem uma macroorganizao para as work units. Podem ter durao (Cycle, Phase, Workflow, Project, Build, Release, Deployment) ou no (milestone). Milestone um ponto no tempo que indica que uma meta foi atingida. A figura 11 mostra um exemplo de stages.

14

Figura 9. Componentes do meta-processo OPEN [OPEN]

Figura 10. Work Units do meta-processo OPEN [Lowe e Henderson-Sellers, 2001]

15

Figura 11. Exemplo de Stages do OPEN [OPEN]

Cada processo, instncia do meta-processo, criado escolhendo atividades, tarefas e tcnicas especficas, com configuraes especficas, como descrito na figura 12. Portanto, OPEN prov um alto grau de flexibilidade para as organizaes.

Figura 12. Instanciao do framework OPEN [OPEN]

16

A natureza baseada em componentes do OPEN permite criar extenses apropriadas para domnios especficos. Desta forma, surgiu o OPEN-Web Process com uma extenso voltada para o domnio de aplicaes web. Esta extenso foi criada analisando as diferenas entre sistemas web e convencionais e validada usando estudos de casos de projetos comerciais para web. Apesar das diferenas, certas atividades, tarefas e tcnicas do framework OPEN se mantm relevantes para o desenvolvimento web, sem precisar de alterao. Por exemplo, as tarefas ligadas s atividades de Iniciao de Projeto, Planejamento de Implementao e Planejamento de Projeto permaneceram relativamente inalteradas. Estas atividades so as mesmas para qualquer tipo de projeto, ou seja, necessrio obter aprovao, fazer estudos de viabilidade, etc. J atividades como Engenharia de Requisitos e Implementao so mais volveis de acordo com o tipo de projeto. A fim de criar o OPEN-Web Process, foram propostas as seguintes adies e modificaes para o framework OPEN: Atividade: o Gerenciamento de web site. Tratar todas as questes relacionadas ao desenvolvimento, manuteno e gerenciamento de um web site corporativo, que inclua ou no acesso a sistemas de processamento de transao no back-end.

Tarefas: o o Construir White Sites (prottipos); Criar contedo o o o o o Selecionar e preparar todo contedo (imagens, vdeos, layout de texto, reuso de templates, etc.).

Criar mapa de navegao pelo contedo; Definir critrio de aceitao para o web site; Definir estratgias de teste para o web site; Projetar e implementar estratgia de gerenciamento de contedo; Projetar e implementar estratgia de personalizao Customizar contedo, apresentao e navegao por perfis de usurio, ou at mesmo fornecer meios para que o prprio usurio possa customizar a aplicao em tempo de execuo.

o o

Projetar arquitetura do web site; Projetar padres de web site Fazer uso de padres para garantir consistncia, quer seja sob a perspectiva de usabilidade, quer seja sob a perspectiva de desenvolvimento. O World Wide Web Consortium [W3C] tem feito considerveis contribuies neste sentido. Desenvolver um estilo prprio do site que esteja estrategicamente ligado com a misso do site e que seja marcante para o pblico.

Desenvolver uma identidade para o web site

17

Desenvolver um padro de dados; Facilita o inter-cmbio de dados entre componentes de um mesmo sistema e, em especial, em interaes B2B. Novamente o World Wide Web Consortium tem trabalhado muito na concepo de padres XML para a indstria que podem ser muito teis.

o o o o

Integrar contedo com interface com usurio; Criar prottipos de interface com usurio; Realizar gerenciamento de contedo; Realizar anlise de mercado; Procurar conhecer o pblico alvo para definir a viabilidade do projeto e tambm para oferecer um servio mais apropriado. Em especial requisitos no funcionais de qualidade como performance e concorrncia.

Testar o web site

Sub-tarefas: o Escolher um padro arquitetural para o web site o o o Sub-tarefa de Definir uma arquitetura. Sub-tarefa de Projetar Interface do Usurio. Sub-tarefa de Projetar Interface do Usurio. Sub-tarefa de Projetar Interface do Usurio. Criar o modelo de papis ou atores (UCD2 role model) Criar o modelo de tarefas (UCD task model) Criar o modelo de contedo (UCD content model)

Tarefas relacionadas ao desenvolvimento baseado em componentes: o o o o Escolher um framework apropriado; Avaliar o potencial de frameworks; Integrar componentes; Enumerar uma lista de frameworks candidatos.

2 UCD Usage Centered Design. Diferentemente de design baseado no usurio, trata-se de design baseado no trabalho que o usurio ir realizar e no que o software precisa fornecer, via interface com o usurio, para ajud-lo a realizar.

18

5 Avaliao das Propostas Apresentadas

Esta seco apresenta uma avaliao das duas propostas apresentadas de acordo com os requisitos que um processo de software para desenvolvimento de aplicaes deve atender. Cada proposta avaliada com relao a cada requisito, indicando o quo completo a proposta contempla tal requisito, sob o seguinte esquema: no (no contempla), parcial (contempla parcialmente), total (contempla totalmente). Avaliao do XWebProcess: 1. Autoria (ou engenharia) de contedo: no. No possui uma atividade explcita para preparao do contedo. Presume-se que seja realizado algo neste sentido ao fazer o design de classes, ou seja, modelo conceitual de domnio. Atividade de Design de Navegao dentro da disciplina Navegao e Apresentao. Atividade de Design de Interface com o Usurio dentro da disciplina Navegao e Apresentao

2. Autoria (ou engenharia) de navegao sobre o contedo: total.

3. Autoria (ou engenharia) de apresentao (interface): total.

4. Ubiqidade: no. 5. Definio de arquitetura multicamadas: parcial. Atividade Definir Arquitetura dentro da disciplina Definio e Reviso de Requisitos. Todavia, deveria possuir sub-atividades mais especficas relacionadas ao uso de padres arquiteturais, frameworks, sistema legados, distribuio entre camadas e separao entre o que roda no navegador cliente e o que roda no servidor web. Esta caracterstica foi herdada do XP. Inclui o cliente e os outros papis relacionados ao desenvolvimento, bem como menciona a figura de analista de negcio e expert de domnio.

6. Ciclos de vida de desenvolvimento curtos: total. 7. Equipes multidisciplinares: total.

8. Desenvolvimento concorrente de pequenas equipes em tarefas interdependentes: no. No menciona atividades em paralelo e coordenao de vrias pequenas equipes. No alude. Na disciplina de Explorao foram includas sesses de prottipo para lidar com a incerteza. Tambm mencionada, na disciplina Definio e

9. Pesquisa de mercado: no. 10. Incerteza do cliente e volatilidade dos requisitos: parcial.

19

Reviso de Requisitos, a necessidade de definio de uma arquitetura flexvel que admita mudanas com mais facilidade. No entanto, no fica claro como tratar mudanas nos requisitos medida que o sistema evolui. 11. Reengenharia de modelos de negcio a partir de modelos da aplicao: no. No oferece suporte para anlise de impactos de modelos de software no negcio. Anlise de negcio pode ser vista na disciplina de Explorao e de Definio e Reviso de Requisitos, no entanto no faz referncia ao envolvimento do usurio final ao longo do ciclo de desenvolvimento antes de colocar a aplicao em produo. No faz referncia. Na disciplina Definio e Reviso de Requisitos. Na disciplina Testes Web. No alude. Na disciplina Suporte para Web, por meio da atividade gerenciamento de contedo e de componentes. Entretanto, no deixa explcito como fazer, quais os passos a serem seguidos.

12. Anlise de negcio e avaliao junto ao usurio final: parcial.

13. Diferentes perfis de usurio (personalizao): no. 14. Requisitos explcitos (funcionais e no-funcionais): total. 15. Testes rigorosos com relao aos requisitos: total. 16. Autoria (engenharia) de Segurana: no. 17. Manuteno e evoluo em granularidade fina: parcial.

Avaliao do OPEN-Web Process: 1. Autoria (ou engenharia) de contedo: total. Tarefa Criar contedo. Tarefa Criar mapa de navegao pelo contedo. Tarefa Projetar Interface do Usurio e suas sub-tarefas. Alm destas, as tarefas Integrar contedo com interface com usurio e Criar prottipos de interface com usurio. 2. Autoria (ou engenharia) de navegao sobre o contedo: total. 3. Autoria (ou engenharia) de apresentao (interface): total.

4. Ubiqidade: no. 5. Definio de arquitetura multicamadas: parcial. Atividade Projetar arquitetura do web site e sua sub-tarefa Escolher um padro arquitetural, bem como as tarefas relacionadas ao uso de componentes e frameworks. No obstante, deveria possuir sub-atividades mais

20

especficas relacionadas ao uso de sistema legados, distribuio entre camadas e separao entre o que roda no navegador cliente e o que roda no servidor web. 6. Ciclos de vida de desenvolvimento curtos: no. O meta-processo OPEN requer um engenheiro de software muito bom que conduza sua instanciao para um processo de software particular. Desta forma, existe uma dependncia muito grande na capacidade do engenheiro de software em definir um processo que atenda aos prazos curtos exigidos por uma aplicao web. Inclui o cliente e os outros papis relacionados ao desenvolvimento, mas no menciona a figura de analista de negcio e expert de domnio.

7. Equipes multidisciplinares: parcial.

8. Desenvolvimento concorrente de pequenas equipes em tarefas interdependentes: no. No menciona atividades em paralelo e coordenao de vrias pequenas equipes. Tarefa Realizar anlise de mercado. Nas tarefas Construir White Sites e Criar prottipos de interface com usurio so criados prottipos para lidar com a incerteza. Tambm mencionado, na tarefa Projetar uma arquitetura e suas sub-tarefas, a necessidade de definio de uma arquitetura flexvel que admita mudanas com mais facilidade. Tambm esto previstas duas tcnicas: Development spikes e Field trips. A primeira utilizada para ajudar aos clientes a compreenderem a tecnologia e o domnio do problema atravs de pequenos prottipos. A segunda consiste em analisar o ambiente do negcio e o lugar final onde ser instalada a aplicao. No entanto, no fica claro como tratar mudanas nos requisitos medida que o sistema evolui. No oferece suporte para anlise de impactos de modelos de software no negcio. No entanto o framework OPEN prev uma fase (phase) chamada Reengenharia do Negcio. O framework OPEN inclui modelagem de negcio, mas no deixa claro como isto se relaciona com anlise de negcio. O OPEN-Web Process no menciona uma tarefa de avaliao ou o envolvimento do usurio final ao longo do desenvolvimento. No entanto, possui vrias tarefas baseadas em UCD. Tarefa Projetar e implementar estratgia de personalizao.

9. Pesquisa de mercado: total. 10. Incerteza do cliente e volatilidade dos requisitos: parcial.

11. Reengenharia de modelos de negcio a partir de modelos da aplicao: no.

12. Anlise de negcio e avaliao junto ao usurio final: parcial.

13. Diferentes perfis de usurio (personalizao): total. 14. Requisitos explcitos (funcionais e no-funcionais): total.

21

Na atividade Engenharia de Requisitos, bem como na tarefa Definir critrio de aceitao para o web site. Nas tarefas Definir critrio de aceitao para o web site, Definir estratgias de teste para o web site e Testar o web site. No faz meno. Na atividade Gerenciamento do web site, por meio da atividade gerenciamento de contedo e de componentes. Entretanto, no deixa explcito como fazer, quais os passos a serem seguidos.

15. Testes rigorosos com relao aos requisitos: total.

16. Autoria (engenharia) de Segurana: no. 17. Manuteno e evoluo em granularidade fina: parcial.

Os resultados da avaliao esto sumarizados na tabela 1. Percebe-se que nenhum dos dois processos atende plenamente a todos os requisitos. Isto uma evidncia que ainda h a necessidade de criao ou aprimoramento de processos que apiem a elaborao de aplicaes web, sendo, portanto, uma ampla avenida para projetos de pesquisa. Requisito \ Processo 01 Autoria de contedo 02 Autoria de navegao 03 Autoria de interface 04 Ubiqidade 05 Arquitetura multicamadas 06 Desenvolvimentos curtos 07 Equipes multidisciplinares 08 Desenvolvimento concorrente 09 Pesquisa de mercado 10 Incerteza dos requisitos 11 Reengenharia do negcio 12 Anlise do negcio 13 Personalizao 14 Requisitos explcitos 15 Testes 16 Autoria de Segurana 17 Manuteno XWebPrcess no total total no parcial total total no no parcial no parcial no total total no parcial OPEN-Web Process total total total no parcial no parcial no total parcial no parcial total total total no parcial

Tabela 1: Sumrio da avaliao dos processos de acordo a lista de requisitos

22

6 Consideraes Finais
Ao longo da histria da engenharia de software vrios processos de software foram propostos e certamente muito outros esto por vir. Todos os processos definem de alguma forma um conjunto organizado de prticas a ser seguido de maneira a aumentar o controle durante todo o ciclo de vida do software e, por conseguinte, elevar a qualidade do produto. No entanto, determinados domnio de aplicao, como aplicaes web, possui suas especificidades, demandando um processo de desenvolvimento mais especializado. Este trabalho apresentou as diferenas relevantes entre sistema web e sistemas convencionais a fim de chamar a ateno para a necessidade de criao de um processo de software voltado para aplicaes web. Com base nestas diferenas, foi identificada uma srie de requisitos que precisam ser levados em considerao. Com base nos requisitos levantados, foram analisados dois processos existentes direcionados para web. Ambos os processos tm sua importante dose de contribuio, mas nenhum deles prev integralmente os requisitos identificados. Esta constatao refora o fato que, embora as aplicaes web sejam reconhecidamente um domnio de suma importncia em nossos dias, ainda existem muitas prticas ad-hoc de desenvolvimento para suprir a falta de um processo sistemtico que preveja certas peculiaridades da engenharia para web. Como foi visto, uma aplicao web marcada por incerteza e volatilidade. O cliente no sabe ao certo aonde quer chegar. Ele vai adquirindo este discernimento medida que a aplicao evolui. Alm disso, a tecnologia est em constante evoluo fazendo com que a soluo projetada precise ser flexvel o bastante para absorver estas mudanas. Outro fato importante o treinamento da equipe que precisa estar sempre reciclando seu conhecimento. Diante de todas estas diferenas e desafios, envolvendo vrias reas, desde o nvel de negcio at o nvel tcnico, fica claro que aplicaes web merecem uma ateno especial. Definir um processo de software para web certamente no uma tarefa fcil. Na verdade, trata-se de uma composio de sub-processos, cada processo cobrindo questes particulares de cada rea envolvida. A motivao deste trabalho foi justamente chamar a ateno para esta necessidade e prover um conjunto de requisitos que possa servir como passo inicial para uma iniciativa de definio de processo de software para sistemas web.

23

Referncias [Agile Manifesto] [Beck, 2000] [Bohem e Turner, 2004] [Chrissis et al, 2003] [Graham et al, 1997] [Haire et al, 2001]

Agile Manifesto Web Site. http://www.agilemanifesto.org Beck, Kent. Extreme Programming Explained, Addison Wesley, 2000. Boehm, B.W.; Turner, R. Balancing Agility and Discipline: A guide for the Perplexed, Reading, Massachusetts: Addison-Wesley, 2004. Chrissis, M.B.; Konrad, M.; Shrum, S. CMMI: Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003. Graham, I.; Henderson-Sellers, B.; Younessi, H. The OPEN Process Specification, Addison-Wesley, 1997. Haire, B.; Henderson-Sellers, B.; Lowe, D. Supporting web development in the open process: additional tasks, in COMPSAC2001: International Computer Software and Applications Conference, Chicago, Illinois, USA, Submitted, IEEE Computer Society. B. Henderson-Sellers, A. Simons, and H. Younessi, The OPEN Toolbox of Techniques, Addison-Wesley, UK, 1998. Humphrey, W.S. Personal Software Process, Addison Wesley, 1995. Humphrey, W.S. Introduction to the Team Software Process, New York, Addison-Wesley, 2000. Kappel, Gerti; Michlmayr, Elke; Prll, Birgit; Reich, Siegfried; Retschitzegger, Werner. Web Engineering Old wine in new bottles? International Conference on Web Engineering (ICWE), Munich 2004. Lowe, David B.; Henderson-Sellers, Brian. Characteristics of Web Development Processes, presented at SSGRR 2001, L'Aquila, Italy, 2001. A. McDonald and R. Welland. Evaluation of Commercial Web Engineering Processes. in Fourth International Conference on Web Engineering, ICWE 2004. OPEN web site: http://www.open.org.au

[HendersonSellers et al, 1998] [Humphrey, 1995] [Humphrey, 2000] [Kappel et al, 2004]

[Lowe e Henderson-Sellers, 2001] [McDonald e Welland, 2004]

[OPEN]

24

[Rossi, 1996]

Rossi, Gustavo; Schwabe, Daniel. Um mtodo orientado a objetos para o projeto de Aplicaes Hipermdia, Tese de Doutorado, Departamento de Informtica PUC-Rio, 1996. Sampaio, Amrico; Vasconcelos, Alexandre; Sampaio, Pedro R. Falcone. Design and Empirical Evaluation of na Agile Web Engineering Process. In 18th Simpsio Brasileiro de Engenharia de Software, SBES 2004. Sampaio, Amrico; Vasconcelos, Alexandre; Sampaio, Pedro R. Falcone. XWebProcess: Agile Software Development for Web Applications, Accepted Poster Presentation to appear in International Conference on Web Engineering ICWE04, Munich Germany, 2004. Sampaio, Amrico. XWebProcess: Um processo gil para o desenvolvimento de aplicaes Web. MSc Thesis, Universidade Federal de Pernambuco, Brazil, March 2004. Schwabe, Daniel; Rossi, Gustavo. The Object-Oriented Hypermedia Design Model. In Communications of the ACM, volume 38(8), pages 45-46, 1995. Schwabe, Daniel; Rossi, Gustavo: An object-oriented approach to web-based application design. Theory and Practice of Object Systems (TAPOS), Special Issue on the Internet, v. 4#4, pp.207-225, October, 1998. Object Management Group. Software Process Engineering Metamodel Specification. Version 2.0 http://www.omg.org/technology/documents/formal/spe m.htm Software Process Improvement and Capability dEtermination. http://www.sqi.gu.edu.au/spice/ World Wide Web Consortium web site: http://www.w3.org

[Sampaio et al, 2004a]

[Sampaio et al, 2004b]

[Sampaio, 2004]

[Schwabe e Rossi, 1995] [Schwabe e Rossi, 1998]

[SPEM]

[SPICE] [W3C]

25