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 ISSN: 0103-9741
Editor: Prof. Carlos J os Pereira de Lucena J ulho, 2008
Processos para Desenvolvimento de Aplicaes Web
Mark Douglas de Azevedo J acyntho
mjacyntho@inf.puc-rio.br
Abstract. Web application development presents significant differences from conven-
tional 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 applica-
tions 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 con-
cerned with the impact of these differences on development process for web applica-
tions, 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, soft-
ware engineering, software development.
Resumo. Desenvolvimento de aplicaes web apresenta diferenas significativas com
relao ao desenvolvimento de aplicaes convencionais. O espectro varia desde dife-
renas 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 ineren-
tes 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 contras-
te com a adoo de abordagens ad-hoc para lidar com as restries impostas por este
domnio de aplicaes. Esta monografia apresenta uma breve discusso sobreo impac-
to 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 Fede-
rativa do Brasil (e CNPq, processo: 142192/ 2007-4).
ii
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 J aneiro 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/
i
Sumrio
1 Introduo 1
1.1 Processos Orientados a Plano versus Processos geis 2
1.2 Organizao da Monografia 3
2 Diferenas entre Aplicaes Web e Aplicaes Convencionais 3
2.1 Diferenas Tcnicas 3
2.2 Diferenas Organizacionais 5
3 Requisitos de um Processo de Desenvolvimento Web 6
4 Duas Propostas Existentes 7
4.1 XWebProcess 7
4.2 OPEN-Web Process 14
5 Avaliao das Propostas Apresentadas 19
6 Consideraes Finais 23
ii
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 Stagesdo OPEN [OPEN]................................................................. 16
Figura 12. Instanciao do framework OPEN [OPEN]....................................................... 16
1
1 Introduo
Vrios processos de software tm sido propostos ao longo dos anos. Essencialmente
todos tentam definir um roadmapque 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 ativi-
dades e so executadas por atores que desempenham um papel no processo (progra-
mador, 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 siste-
mas de informao altamente complexos, repletos de dados e transaes, voltados para
a implementao de processos de negcio intra- e inter-organizao. Diante deste qua-
dro, a necessidade de um processo de software sistemtico que ajude a gerenciar o ci-
clo 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 consideradaspelos 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 arquiteturaque encapsuleem um front-endamigvel um
back-endque pode ser por demasiadocomplexo e heterogneo.
Em muitos casos, as equipes de desenvolvimento, acometidas pelas severas restri-
es 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 e-
quipe, com os usuais efeitos colaterais negativos emflexibilidade, 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 proces-
sos de software j existentes de forma a contemplar mais claramente as necessidades
especficasda 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 esti-
lo tradicional desktop, composta apenas por buscas e formulrios, so exemplos de apli-
cao na web. J aplicaes web so aquelas que, necessariamente, exploram o para-
digma hipermdia. Em outras palavras, no contexto deste trabalho, somente so consi-
deradas aplicaes web aquelas que possuem uma estrutura navegacional bem defini-
2
da, fazendo jus ao elemento fundamental da web que a noo de hiperlink. O grande
desafio das aplicaes web modernas integrar, elegantemente, dois paradigmas capi-
tais: hipermdia e transao. Sendo assim, este trabalho procurar evidenciar os requisi-
tos 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, des-
tacando 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 duaspropostasexistentes.
1.1 Processos Orientados a Plano versus Processos geis
Mais recentemente os processos de software passarama ser classificados em duas ca-
tegorias: 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 tmo foco no produto em si, ou seja, o mais impor-
tante entregar software em detrimento dedocumentao. 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 mani-
festo so:
Pessoas e interaes so mais importantesdo queprocessos e ferramentas;
Software executvel mais importante do quedocumentao;
Colaborao do cliente mais importante do quenegociao 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 [Boheme 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 aplicaesdo que um processo maisrigoroso.
3
1.2 Organizao da Monografia
A seco 2 explora as diferenas entre sistemas web e sistemas convencionais. Em se-
guida, na seco 3, so enumerados os requisitos que devem ser levados em considera-
o quando da elaborao de um processo de desenvolvimento para web. Para tornar a
discusso mais concreta, a seco 4 apresentaduas propostas de processo web existen-
tes. Seguindo na mesma linha, na seco 5, as propostas apresentadas so analisadas
de acordo com os requisitos descritos anteriormente. Encerrando, a seco 6delineiaas
consideraes finais.
2 Diferenas entre Aplicaes Web e Aplicaes
Convencionais
Existe um conjunto de diferenas que justificam a necessidade de umaateno especial
ao desenvolvimento de aplicaes web. Algumas caractersticas so nicas de sistemas
web, outras tambm esto presentes nos sistemas convencionais, mas so mais pro-
nunciadas 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 adefinirmos 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 or-
ganizacionais so discutidas.
2.1 Diferenas Tcnicas
Claramente existem diferenas tcnicas entre sistemas web e convencionais. As
mais significantes so:
Diferenas relativas aplicao:
o Contedo: aweb essencialmente um meio de informao. Alm da
funcionalidade, uma aplicao web orientada a contedo. Conte-
do compreende dados estruturados (banco de dados, por exemplo) e
no estruturados (arquivos textos, vdeos, etc.). Alm disso, o conte-
do dinmico, precisa ser continuamente atualizado e de qualidade
em termos de consistncia e confiabilidade. Isto implica emumefeti-
vo projeto de informao, bem como gerenciamento de contedo a-
propriado.
o Hipertexto: na web o paradigma fundamental para estruturar a in-
formao noo de hipertexto, onde os elementos bsicos so: ns,
elos (links) e ncoras que ativam estes elos. Os ns exibem informa-
es e os elos nos permitemnavegar entre os ns. Isto requer um pro-
jeto cuidadoso e estratgico de navegao que preserve a qualidade
de acesso e evite desorientao e sobrecarga cognitiva.
o Apresentao: o look and feel da aplicao web um fator de quali-
dade 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 consis-
tente com o estilo de interao. Alm disso, a aparncia visual est
sujeita a modismo, tendncias e novas caractersticas tcnicas que
surgem todos os dias.
4
o Requisitos no-funcionais de qualidade: requisitos de qualidade
como disponibilidade 24/ 7, performance, usabilidade, escalabilida-
de, robustez e segurana se tornam ainda mais crticos quando ex-
postos 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 dispositi-
vos, em diferentes contextos de uso) das aplicaes cresce, torna-se
necessrio projetar diferentes vises da aplicao, uma para cada
contexto de uso.
o Infra-estrutura tecnolgica imprevisvel: juntamente como crescen-
te carter ubquo, surge uma enorme variedade de dispositivos de
usurio final, com diferentes capacidadesde hardware e software, di-
ferentes tamanhos e verses de navegadores. Conexes de rede dife-
rem 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.
Diferenas relativas ao desenvolvimento:
o 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 importnciade 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.
o Integrao com sistemas legados: aplicaes web costumeiramente
precisam se integrar com sistema legados. So sistemas com interfa-
ces 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
raramenteso documentados e freqentementeso modificados sem
notificao, afetando a execuo do sistema web. Alm disso, as tec-
nologias para encapsulamento so vrias e esto sempre mudando
(por exemplo, encapsulamento viaweb services).
5
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 dom-
nio de aplicaes no bem compreendido pelos interessados (tam-
bm chamados de stakeholders). Freqentemente o cliente tem pro-
blemas 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 vi-
sionria ao invs de uma necessidade bem definida. Isto aumenta a
necessidade de desenvolvimento incremental baseado em protti-
pos.
o 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 as-
sim, 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 mode-
lo de negcio da empresa podemudar diante de novas oportunida-
des outrora desconhecidas.
o Ciclos de desenvolvimento muito curtos: projetos web, em geral,
tmprazos mais curtos do que projetos convencionais, comumente
de um a trs meses.
o Alta competitividade: aconcorrncia na web muito mais intensifi-
cada pela facilidade do usurio final visitar vrios sites em um curto
espao de tempo. Portanto, a aplicao precisa estar sempre atuali-
zada e atraente de acordo com as tendncias atuais.
o 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, publici-
trios, consultores de negcio, entre outros. Em geral, h muito jo-
vens inexperientes inclinados a empregar tecnologias novas de for-
ma ad-hoc.
o Evoluo e manuteno de granularidade fina: aplicaes web es-
to sujeitas amudanas dirias e permanente evoluo. Tipicamente
temos um processo contnuo de atualizao de contedo, mudanas
editoriais, ajustes de interface, etc. Sem falar nas mudanas tecnol-
gicas mais radicais.
Diferenas relativas ao uso:
o Diversidade de tipos de usurio: na web os usurios variam em i-
dade, conhecimento scio-cultural, objetivos, intenes, habilidades
e capacidades. Esta heterogeneidade, diferentes perfis de usurio,
precisa ser considerada, dado que na web os usurios so inteira-
mente livres para escolherem as aplicaes que lhe forem mais con-
venientes.
6
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 podese repetir ou no. Um exemplo so os con-
textos navegacionais relacionados ao perodo natalino.
Analisando o que foi exposto nesta seco, percebe-se que um processo de desenvol-
vimento voltado para aplicaes web caracterizado por freqentes mudanas e ajus-
tes, 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 anteriormentee do trabalho exposto em [McDonald
e Welland, 2004], foram identificados dezessete requisitos que umprocesso de desen-
volvimento 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 proces-
so 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 arquiteturamulticamadas
5.1. Escolha, adaptao e utilizao de frameworks e componentes;
5.2. Integrao com sistemas legados;
5.3. Distribuio das camadasentre 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 inter-
dependentes;
9. Pesquisa de mercado;
10. Incerteza do cliente e volatilidade dos requisitos;
11. Reengenharia de modelos de negcio a partir demodelos 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. Testesrigorososcom relao aos requisitos;
15.1. Teste de performance, escalabilidade e resilincia;
7
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 a-
plicaes 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
XWebProcesse uma proposta mais rigorosa chamada OPEN-Web Process.
4.1 XWebProcess
XWebProcess [Sampaio, 2004] [Sampaio et al, 2004a] [Sampaio et al, 2004b] um pro-
cesso gil para desenvolvimento de aplicaes web baseado nos princpios do XP (Ex-
treme Programming) [Beck, 2000]. O XWebProcess resultado da adaptao do XP para
lidar melhor com importantes questes de sistemas web: interfaces com usurio com-
plexas, navegao, requisitos no-funcionais (distribuio, concorrncia, balanceamen-
to de carga), testes e suporte de infra-estrutura.
Uma vez que o XWebProcess deriva do XP, interessante, em primeiro lugar, apre-
sentar uma breve descrio do XP. O processo gil XP confia em cinco pilares de valor:
Comunicao: significa que os membros da equipe devem interagir constan-
temente para discutir os problemas e propor solues. Alm disso, o cliente,
o algum que o represente, deve ser um membro ativo da equipe para eluci-
dar os requisitos e regras de negcio envolvidos;
Feedback: implicaque cada membro da equipe (programador, gerente, clien-
te, etc.) devefornecer feedbackconstante sobre os problemas encontrados pa-
ra 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 ne-
cessrio e com o design mais simples. Possveis problemas que surjam em
funo desta deciso so minimizados com prticas como refactoringe 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 tornemobsoletos.
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
8
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, resu-
midamente, descritas a seguir:
Planning game(Jogo de Planejamento): um releasedeve ser o menor poss-
vel (dois a trs meses). Cada release dividido em iteraes semanais (duas
a trs semanas), onde historietas (pequenos casos de uso) so implementa-
dos. No incio da semana, desenvolvedores e cliente renem-se para anali-
sar as funcionalidades. O esforo estimado para implementar cada historie-
ta definido pelos programadores e o cliente define a prioridadeda histori-
eta.
Small Releases (Pequenas Verses): um releasedeveser 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 (clien-
tes, programadores, gerentes, etc.) podem contar sobre como o sistema fun-
ciona. 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(EquipeCoesa): o cliente deve ser um membro efetivo da e-
quipe, disponvel para esclarecer eventuais questionamentos.
Customer Tests (Testes de Aceitao): testes construdos pelo cliente, em
conjunto com analistas e testadores, para validar umou mais requisitos do
sistema. Tambm chamados de testes funcionais.
Sustainable Pace(Ritmo Sustentvel): a equipe deve trabalhar em um am-
biente 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 impreterivelmentenecessrias.
Stand-up Meeting(Reuniesem P): reunies em p (por exemplo, no in-
cio do dia) para no perder o foco, somente abordando o que foi realizado e
prximas tarefas a realizar. Estasreunies 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 modifica-
dos, 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, garan-
tindo assim uma homogeneidade em todo cdigo, facilitando o entendi-
mento.
9
Test Driven Development (Desenvolvimento Orientadoa 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, me-
lhorado, sem alterar a funcionalidade. Juntamente com testes automatiza-
dos (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 I ntegration(Integrao Contnua): a equipe de desenvolvimen-
to deve trabalhar sempre na ltima verso do projeto. Semprequeuma no-
va 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 se-
guida, com base nas caractersticas das aplicaes web, o modelo SPEM do XP foi enri-
quecido gerando o modelo SPEM do XWebProcess. Sendo assim o XWebProcess pode
ser visto comouma 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 estrutu-
ral. A viso dinmica mostra como as disciplinas
1
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 envol-
vidos, 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 (ativida-
des, artefatos, atores) agrupados por um tema comum. Exemplos de disciplinas so: anlise, design,
testes, etc.
10
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, tecno-
logias, arquiteturas e prottipos para verificar a viabilidade do projeto e definir os re-
quisitos iniciais.
Em seguida, temos a disciplina de definio e reviso dos requisitos. Nesta, clientes
e programadores definem as historietas para o prximo release. Programadores esti-
mam o esforo necessrio para cada historieta e os clientes definem as prioridades das
historietas. Esta disciplina foi modificadapara incluir uma atividade de design de ar-
quitetura, visando definir uma estrutura flexvel que permita, mais facilmente, integra-
o 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 ocorremas seguintes disciplinas: plane-
jamento de iterao, design, escrita de teste de unidade, codificao, teste e integrao.
A disciplina de design foi modificadapara incluir a atividade de design da camada de
dados. Durante uma iterao, pode haver mudanas nos requisitos e estimativas ante-
riores precisam ser reavaliadas. Escrita de testes funcionais, bem como design de na-
11
vegao e apresentao so feitos em paralelo com as atividades anteriores. A discipli-
na de design de navegao e apresentao foi inseridadevido inquestionvel impor-
tncia 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 inseridaa 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 releasedo sistema, entre em cena a disciplina de suporte web que
foi inseridacom o propsito delidar com a organizao de componentes de hardware
e software que fazem parte do website.
O processo termina quando todas as historietas tiverem sido implementadas e pos-
tas em produo.
Tendo descrito a dinmica do processo, a seguir ser apresentada a estrutura inter-
na 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, emcada figura, sero destaca-
dos 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 pelaatividade de prototipagem cuja sada um prottipo,
criado com ajuda de tcnicas de prototipagem. J a disciplina de requisitos foi modifi-
cada 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, fle-
xibilidade e performance.
12
Figura 3. Explorao no XWebProcess
[Sampaio et al, 2004a]
Figura 4. Requisitos no XWebProcess
[Sampaio et al, 2004a]
A disciplina deanlise 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 umnico 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 programa-
dor e arquiteto. Para projetar a navegao, mtodos como OOHDM [Schwabe e Rossi,
1995] [Schwabe e Rossi, 1998] so muito bem vindos, poispossuem primitivas com este
propsito especfico. O web designer tambm responsvel por projetar a interfaceabs-
trata e, com base nesta, a interface fsica.
13
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 admi-
nistrador do web siterealiza duas atividades: gerenciamento de contedo e gerencia-
mento 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]
14
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 pro-
cesso, conhecido por OPF (OPEN Process Framework) que abrangeo ciclo de vida com-
pleto 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 em-
presas.
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 proje-
to (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 ope-
raes executadas pelos producersao desenvolver work products. H trs tipos
de work unit:
o Activity (atividade): objetivo maior. Define o qu, no como.
composto por tasks;
o Task (tarefa): objetivo menor, ou seja, metas para atingir o objetivo
maior. Ainda define o qu, no como. Resultam na criao, mo-
dificao ou avaliao de um ou mais work products;
o 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 macro-
organizao 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 e-
xemplo de stages.
15
Figura 9. Componentes do meta-processo OPEN [OPEN]
Figura 10. Work Units do meta-processo OPEN [Lowe e Henderson-Sellers, 2001]
16
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. Portan-
to, OPEN prov um alto grau de flexibilidade para as organizaes.
Figura 12. Instanciao do framework OPEN [OPEN]
17
A natureza baseada em componentes do OPEN permite criar extenses apropriadas
para domnios especficos. Desta forma, surgiu o OPEN-Web Processcom uma extenso
voltada para o domnio de aplicaes web. Esta extenso foi criada analisando as dife-
renas entre sistemas web e convencionais e validadausando estudos de casos de pro-
jetos comerciais para web.
Apesar das diferenas, certas atividades, tarefas e tcnicas do framework OPEN se
mantmrelevantes para o desenvolvimento web, sem precisar de alterao. Por exem-
plo, as tarefas ligadas s atividades de Iniciao de Projeto, Planejamento de Im-
plementao e Planejamento de Projeto permaneceram relativamente inalteradas.
Estas atividades so as mesmas para qualquer tipo de projeto, ou seja, necessrio ob-
ter aprovao, fazer estudos de viabilidade, etc. J atividades como Engenharia de
Requisitos e Implementao so mais volveisde acordo com o tipo de projeto.
A fim de criar o OPEN-Web Process, foram propostas as seguintes adies e modifi-
caes 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 transa-
o no back-end.
Tarefas:
o Construir White Sites (prottipos);
o Criar contedo
Selecionar e preparar todo contedo (imagens, vdeos, layout
de texto, reuso de templates, etc.).
o Criar mapa de navegaopelo contedo;
o Definir critrio de aceitao para o website;
o Definir estratgias de teste para o website;
o Projetar e implementar estratgia de gerenciamento de contedo;
o Projetar e implementar estratgia de personalizao
Customizar contedo, apresentao e navegao por perfis de
usurio, ou at mesmo fornecer meios para que o prprio u-
surio possa customizar a aplicao em tempo de execuo.
o Projetar arquitetura do website;
o Projetar padres de website
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.
o Desenvolver uma identidade para o web site
Desenvolver um estilo prprio do site que esteja estrategica-
mente ligado com a misso do site e que seja marcante para o
pblico.
18
o 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 Consortiumtem trabalhado muito na con-
cepo de padres XML para a indstria que podem ser mui-
to teis.
o Integrar contedo com interface com usurio;
o Criar prottipos de interface com usurio;
o Realizar gerenciamento de contedo;
o Realizar anlise de mercado;
Procurar conhecer o pblico alvo para definir a viabilidade
do projeto e tambm para oferecer um servio mais apropria-
do.
o Testar o web site
Em especial requisitos no funcionais de qualidade como per-
formance e concorrncia.
Sub-tarefas:
o Escolher um padro arquitetural para oweb site
Sub-tarefa de Definir uma arquitetura.
o Criar o modelo de papis ou atores (UCD
2
role model)
Sub-tarefa de Projetar Interface do Usurio.
o Criar o modelo de tarefas (UCD task model)
Sub-tarefa de Projetar Interface do Usurio.
o Criar o modelo de contedo (UCD content model)
Sub-tarefa de Projetar Interface do Usurio.
Tarefas relacionadas ao desenvolvimento baseado em componentes:
o Escolher um framework apropriado;
o Avaliar o potencial de frameworks;
o Integrar componentes;
o Enumerar uma lista de frameworks candidatos.

2UCD UsageCentered Design. Diferentemente de design baseado no usurio, trata-se de design base-
ado no trabalho que o usurio ir realizar e no que o software precisa fornecer, via interface com o
usurio, para ajud-lo a realizar.
19
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 con-
templa), 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. Presu-
me-se que seja realizado algo neste sentido ao fazer o design de classes, ou
seja, modelo conceitual de domnio.
2. Autoria (ou engenharia) de navegao sobre o contedo: total.
Atividade de Design de Navegao dentro da disciplina Navegao e
Apresentao.
3. Autoria (ou engenharia) de apresentao (interface): total.
Atividade de Design de Interface com o Usurio dentro da disciplina
Navegao e Apresentao
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 cli-
ente e o que roda no servidor web.
6. Ciclos de vida de desenvolvimento curtos: total.
Esta caracterstica foi herdada do XP.
7. Equipes multidisciplinares: total.
Inclui o cliente e os outros papis relacionados ao desenvolvimento, bem
como menciona a figura de analista de negcio e expert de domnio.
8. Desenvolvimento concorrente de pequenas equipes em tarefas inter-
dependentes: no.
No menciona atividades em paralelo e coordenao de vrias pequenas
equipes.
9. Pesquisa de mercado: no.
No alude.
10. Incerteza do cliente e volatilidade dos requisitos: parcial.
Na disciplina de Explorao foram includas sesses de prottipo para
lidar com a incerteza. Tambm mencionada, na disciplina Definio e
20
Reviso de Requisitos, a necessidade de definio de uma arquiteturafle-
xvel que admita mudanas com mais facilidade. No entanto, no fica claro
como tratar mudanas nos requisitos medida que o sistema evolui.
11. Reengenharia demodelos de negcio a partir demodelos da aplicao: no.
No oferece suporte para anlise de impactos de modelos de software no
negcio.
12. Anlise de negcio e avaliao junto ao usurio final: parcial.
Anlise de negcio pode ser vista na disciplina de Explorao e de De-
finio e Reviso de Requisitos, no entanto no faz referncia ao envolvi-
mento do usurio final ao longo do ciclo de desenvolvimento antes de co-
locar a aplicao em produo.
13. Diferentes perfis de usurio (personalizao): no.
No faz referncia.
14. Requisitos explcitos(funcionais e no-funcionais): total.
Na disciplina Definio e Reviso de Requisitos.
15. Testesrigorososcom relao aos requisitos: total.
Na disciplina Testes Web.
16. Autoria (engenharia) de Segurana: no.
No alude.
17. Manuteno e evoluo em granularidade fina: parcial.
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.
Avaliao do OPEN-Web Process:
1. Autoria (ou engenharia) de contedo: total.
Tarefa Criar contedo.
2. Autoria (ou engenharia) de navegao sobre o contedo: total.
Tarefa Criar mapa de navegaopelo contedo.
3. Autoria (ou engenharia) de apresentao (interface): total.
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.
4. Ubiqidade: no.
5. Definio de arquitetura multicamadas: parcial.
Atividade Projetar arquitetura do website e sua sub-tarefa Escolher um
padro arquitetural, bem como as tarefas relacionadas ao uso de compo-
nentes e frameworks. No obstante, deveria possuir sub-atividades mais
21
especficas relacionadas ao uso de sistema legados, distribuio entre ca-
madas 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.
7. Equipes multidisciplinares: parcial.
Inclui o cliente e os outros papis relacionados ao desenvolvimento, mas
no menciona a figura de analista de negcio e expert de domnio.
8. Desenvolvimento concorrente de pequenas equipes em tarefas inter-
dependentes: no.
No menciona atividades em paralelo e coordenao de vrias pequenas
equipes.
9. Pesquisa de mercado: total.
Tarefa Realizar anlise de mercado.
10. Incerteza do cliente e volatilidade dos requisitos: parcial.
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 ne-
cessidade 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 peque-
nos 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.
11. Reengenharia de modelos de negcio a partir demodelos da aplicao: no.
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.
12. Anlise de negcio e avaliao junto ao usurio final: parcial.
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.
13. Diferentes perfis de usurio (personalizao): total.
Tarefa Projetar e implementar estratgia de personalizao.
14. Requisitos explcitos(funcionais e no-funcionais): total.
22
Na atividadeEngenhariade Requisitos, bem como na tarefaDefinir cri-
trio de aceitao para o website.
15. Testesrigorososcom relao aos requisitos: total.
Nas tarefas Definir critrio de aceitao para o website, Definir estrat-
gias de teste para o website e Testar o web site.
16. Autoria (engenharia) de Segurana: no.
No faz meno.
17. Manuteno e evoluo em granularidade fina: parcial.
Na atividadeGerenciamento do website, por meio da atividade gerenci-
amento de contedo e de componentes. Entretanto, no deixa explcito
como fazer, quais os passos a serem seguidos.
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 decriao ou aprimoramento de processos que apiem a elabo-
rao de aplicaes web, sendo, portanto, uma amplaavenida para projetos de pesqui-
sa.
Requisito \ Processo XWebPrcess OPEN-Web Process
01Autoria de contedo no total
02Autoria de navegao total total
03Autoria de interface total total
04Ubiqidade no no
05Arquiteturamulticamadas parcial parcial
06Desenvolvimentoscurtos total no
07Equipes multidisciplinares total parcial
08Desenvolvimento concorrente no no
09Pesquisade mercado no total
10Incerteza dos requisitos parcial parcial
11Reengenharia donegcio no no
12Anlisedonegcio parcial parcial
13Personalizao no total
14Requisitosexplcitos total total
15Testes total total
16Autoria de Segurana no no
17Manuteno parcial parcial
Tabela 1: Sumrio da avaliao dos processosde acordoa lista de requisitos
23
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 al-
guma 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 quali-
dade 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 con-
vencionais 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 di-
recionados 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 desenvol-
vimento para suprir a falta de um processo sistemtico que preveja certas peculiarida-
des da engenharia para web.
Como foi visto, uma aplicao web marcada por incerteza e volatilidade. O cliente
no sabe ao certo aondequer chegar. Elevai 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 mudan-
as. Outro fato importante o treinamento da equipe que precisa estar sempre reci-
clando 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 es-
pecial. 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 inicia-
tiva de definio de processo de software para sistemasweb.
24
Referncias
[Agile Manifesto]
Agile Manifesto Web Site.
http://www.agilemanifesto.org
[Beck, 2000]
Beck, Kent. Extreme Programming Explained, Addison
Wesley, 2000.
[Bohem e Turner,
2004]
Boehm, B.W.; Turner, R. Balancing Agility and
Discipline: A guide for the Perplexed, Reading,
Massachusetts: Addison-Wesley, 2004.
[Chrissis et al,
2003]
Chrissis, M.B.; Konrad, M.; Shrum, S. CMMI:
Guidelines for Process Integration and Product
Improvement, Addison-Wesley, 2003.
[Graham et al,
1997]
Graham, I.; Henderson-Sellers, B.; Younessi, H. The
OPEN Process Specification, Addison-Wesley, 1997.
[Haire et al, 2001]
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.
[Henderson-
Sellers et al, 1998]
B. Henderson-Sellers, A. Simons, and H. Younessi,
The OPEN Toolbox of Techniques, Addison-Wesley,
UK, 1998.
[Humphrey, 1995]
Humphrey, W.S. Personal Software Process, Addison
Wesley, 1995.
[Humphrey, 2000]
Humphrey, W.S. Introduction to the Team Software
Process, New York, Addison-Wesley, 2000.
[Kappel et al,
2004]
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 e
Henderson-Sellers,
2001]
Lowe, David B.; Henderson-Sellers, Brian.
Characteristics of Web Development Processes,
presented at SSGRR 2001, L'Aquila, Italy, 2001.
[McDonald e
Welland, 2004]
A. McDonald and R. Welland. Evaluation of
Commercial Web Engineering Processes. in Fourth
International Conference on Web Engineering, ICWE
2004.
[OPEN]
OPEN web site: http://www.open.org.au
25
[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 et al,
2004a]
Sampaio, Amrico; Vasconcelos, Alexandre; Sampaio,
Pedro R. Falcone. Design and Empirical Evaluation of
na Agile Web Engineering Process. In 18
th
Simpsio
Brasileiro de Engenharia de Software, SBES 2004.
[Sampaio et al,
2004b]
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, 2004]
Sampaio, Amrico. XWebProcess: Um processo gil
para o desenvolvimento de aplicaes Web. MSc
Thesis, Universidade Federal de Pernambuco, Brazil,
March 2004.
[Schwabe e Rossi,
1995]
Schwabe, Daniel; Rossi, Gustavo. The Object-Oriented
Hypermedia Design Model. In Communications of the
ACM, volume 38(8), pages 45-46, 1995.
[Schwabe e Rossi,
1998]
Schwabe, Daniel; Rossi, Gustavo: An object-oriented
approach to web-based application design. Theory and
Practiceof Object Systems (TAPOS), Special Issue on
the Internet, v. 4#4, pp.207-225, October, 1998.
[SPEM]
Object Management Group. Software Process
Engineering Metamodel Specification. Version 2.0
http://www.omg.org/technology/documents/formal/spe
m.htm
[SPICE]
Software Process Improvement and Capability
dEtermination. http://www.sqi.gu.edu.au/spice/
[W3C]
World Wide Web Consortium web site:
http://www.w3.org