Processos para Desenvolvimento de Aplicações Web

Transcrição

1 ISSN Mngrafias em Ciência da Cmputaçã n 23/09 Prcesss para Desenvlviment de Aplicações Web Mark Duglas de Azeved Jacynth Departament de Infrmática PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO RUA MARQUÊS DE SÃO VICENTE, CEP RIO DE JANEIRO - BRASIL

2 Mngrafias em Ciência da Cmputaçã, N. 23/09 ISSN: Editr: Prf. Carls Jsé Pereira de Lucena Julh, 2008 Prcesss para Desenvlviment de Aplicações Web Mark Duglas de Azeved Jacynth Abstract. Web applicatin develpment presents significant differences frm cnventinal applicatin develpment. The spectrum varies frm technical t rganizatinal differences. Technical means the specific architectures and technlgies emplyed and the impacts invlved. Organizatinal is related t the strategic use f these applicatins aiming at imprving the business. Amng ther issues, uncertainty, vlatility and high cmpetitiveness are innate characteristics which must be carefully addressed. Therefre, the nature f web engineering suggests the need f specialized sftware prcesses that cver, in a systematic way, the cmplete life cycle f hypermedia web applicatins, in cntrast t adpting ad-hc appraches t cmply with the cnstraints impsed by this applicatin dmain. This essay presents an abridge discussin cncerned with the impact f these differences n develpment prcess fr web applicatins, analyzing sme prpsals, indentifying the requirements and challenges. This wrk intends t be an initial step twards the definitin f a prcess suitable t web develpment, in dimensins such as requirements gathering, user interface, testing and navigatin design. Keywrds: web prcess, web engineering, web develpment, sftware prcess, sftware engineering, sftware develpment. Resum. Desenvlviment de aplicações web apresenta diferenças significativas cm relaçã a desenvlviment de aplicações cnvencinais. O espectr varia desde diferenças técnicas até rganizacinais. Diferenças técnicas significam as arquiteturas e tecnlgias específicas empregadas e s impacts envlvids. Já as rganizacinais sã relacinadas a us estratégic destas aplicações visand melhrar negóci. Dentre utrs fatres, incerteza, vlatilidade e alta cmpetitividade sã características inerentes que precisam ser cnsideradas. Pr cnseguinte, a natureza da engenharia para web sugere a necessidade de prcesss de sftware especializads que atendam, de frma sistemática, cicl de vida cmplet de aplicações web hipermídia, em cntraste cm a adçã de abrdagens ad-hc para lidar cm as restrições impstas pr este dmíni de aplicações. Esta mngrafia apresenta uma breve discussã sbre impact destas diferenças em prcesss de desenvlviment para aplicações web, analisand algumas prpstas, identificand s requisits e desafis. Este trabalh pretende ser um pass inicial rum à definiçã de um prcess aprpriad para desenvlviment web, em dimensões cm levantament de requisits, interface cm usuári, testes e prjet de navegaçã. Palavras-chave: prcess web, engenharia para web, desenvlviment web, prcess de sftware, engenharia de sftware, desenvlviment de sftware. Trabalh patrcinad pel Ministéri de Ciência e Tecnlgia da Presidência da República Federativa d Brasil (e CNPq, prcess: /2007-4).

3 Respnsável pr publicações: Rsane Teles Lins Castilh Assessria de Bibliteca, Dcumentaçã e Infrmaçã PUC-Ri Departament de Infrmática Rua Marquês de Sã Vicente, Gávea Ri de Janeir RJ Brasil Tel Fax: bib-di@inf.puc-ri.br Web site: ii

4 Sumári 1 Intrduçã Prcesss Orientads a Plan versus Prcesss Ágeis Organizaçã da Mngrafia 3 2 Diferenças entre Aplicações Web e Aplicações Cnvencinais Diferenças Técnicas Diferenças Organizacinais 5 3 Requisits de um Prcess de Desenvlviment Web 6 4 Duas Prpstas Existentes XWebPrcess OPEN-Web Prcess 14 5 Avaliaçã das Prpstas Apresentadas 19 6 Cnsiderações Finais 23 i

5 Índice de Figuras Figura 1. Passs de criaçã d XWebPrcess [Sampai et al, 2004a]... 9 Figura 2. Visã dinâmica d XWebPrcess [Sampai et al, 2004a] Figura 3. Explraçã n XWebPrcess [Sampai et al, 2004a] Figura 4. Requisits n XWebPrcess [Sampai et al, 2004a] Figura 5. Análise e Design n XWebPrcess [Sampai et al, 2004a] Figura 6. Navegaçã e Apresentaçã n XWebPrcess [Sampai et al, 2004a] Figura 7. Testes Web n XWebPrcess [Sampai et al, 2004a] Figura 8. Suprte Web n XWebPrcess [Sampai et al, 2004a] Figura 9. Cmpnentes d meta-prcess OPEN [OPEN] Figura 10. Wrk Units d meta-prcess OPEN [Lwe e Hendersn-Sellers, 2001] Figura 11. Exempl de Stages d OPEN [OPEN] Figura 12. Instanciaçã d framewrk OPEN [OPEN] ii

6 1 Intrduçã Váris prcesss de sftware têm sid prpsts a lng ds ans. Essencialmente tds tentam definir um radmap que guie desenvlviment, identificand quem está fazend quê, nde, pr que, cm e quand. Um prcess de sftware é definid cm um cnjunt de atividades interdependentes que visam desenvlver, manter e gerenciar sistemas de sftware. Estas atividades pdem ser cmpstas de utras atividades e sã executadas pr atres que desempenham um papel n prcess (prgramadr, gerente, cliente, etc.). Cm resultad das atividades, sã prduzids artefats (códig, dcumentaçã, mdels) que servem de entrada para utras atividades para prduzir nvs artefats. Sem um prcess de sftware, risc de falha d prjet se trna muit alt, em especial para as aplicações web mdernas cuja cmplexidade nã pára de crescer. Cm passar ds ans, as aplicações web evluíram rapidamente de simples web sites cuj prpósit era apenas navegaçã sbre a infrmaçã para verdadeirs sistemas de infrmaçã altamente cmplexs, replets de dads e transações, vltads para a implementaçã de prcesss de negóci intra- e inter-rganizaçã. Diante deste quadr, a necessidade de um prcess de sftware sistemátic que ajude a gerenciar cicl de vida de tais aplicações surge naturalmente. Pder-se-ia argumentar que sistemas web nã sã diferentes, sb pnt de vista de prcess de sftware, de sistemas de sftware cnvencinais. Nã bstante, existe um crescente recnheciment que sistemas web pssuem características particulares que nã sã aprpriadamente cnsideradas pels prcesss de sftware tradicinais. O desenvlviment de aplicações web é realizad pr equipes multidisciplinares, cm diferentes habilidades, em prazs curtíssims ditads pela vraz cncrrência e em um cntext extremamente vlúvel, marcad pr incertezas. Para cmpletar, sistemas web sã tecnlgicamente muit abstruss, reunind padrões, prtcls e tecnlgias diversas na definiçã de uma arquitetura que encapsule em um frnt-end amigável um back-end que pde ser pr demasiad cmplex e hetergêne. Em muits cass, as equipes de desenvlviment, acmetidas pelas severas restrições de temp, adtam sluções ad-hc para cnstruir tais aplicações. Neste cenári, sucess d prjet depende muit da habilidade e cnheciment ds membrs da e- quipe, cm s usuais efeits claterais negativs em flexibilidade, qualidade e rbustez da aplicaçã [Sampai et al, 2004a]. Cm é de se esperar, paralelamente às diferenças, também c-existem pnts em cmum entre aplicações web e cnvencinais. Prtant, um caminh interessante seria delinear as peculiaridades deste dmíni de aplicaçã e adaptar u enriquecer prcesss de sftware já existentes de frma a cntemplar mais claramente as necessidades específicas da web. Sb a ótica deste trabalh, é imprtante ressaltar a diferença entre aplicaçã na web e aplicaçã web. Aplicaçã na web é qualquer tip de aplicaçã que utiliza a web cm ambiente de execuçã. Um simples repsitóri de arquivs u uma aplicaçã cm estil tradicinal desktp, cmpsta apenas pr buscas e frmuláris, sã exempls de aplicaçã na web. Já aplicações web sã aquelas que, necessariamente, explram paradigma hipermídia. Em utras palavras, n cntext deste trabalh, smente sã cnsideradas aplicações web aquelas que pssuem uma estrutura navegacinal bem defini- 1

7 da, fazend jus a element fundamental da web que é a nçã de hiperlink. O grande desafi das aplicações web mdernas é integrar, elegantemente, dis paradigmas capitais: hipermídia e transaçã. Send assim, este trabalh prcurar evidenciar s requisits que um prcess de desenvlviment de sftware precisa atender de md a ser, efetivamente útil, nesta integraçã. Esta mngrafia cnsidera as diferenças entre aplicações web e cnvencinais, destacand as implicações na definiçã de um prcess de sftware para web. Para tal, é definida uma lista de requisits que um prcess web deve atender e, cm base nesta, sã analisadas duas prpstas existentes. 1.1 Prcesss Orientads a Plan versus Prcesss Ágeis Mais recentemente s prcesss de sftware passaram a ser classificads em duas categrias: rientads a plan e ágeis. Prcesss rientads a plans sã prcesss mais rigrss, preditivs pr natureza, nde existe um plan que prcura antever prblemas e as respectivas sluções. A lng d desenvlviment tdas as decisões de prjet sã dcumentadas e cntrladas, antes de serem implementadas. O fc é n prcess, u seja, institucinalizar um prcess de sftware e segui-l a risca. Este prcess deve ser cntinuamente aprimrad. Sã exempls: CMMI - Capability Maturity Mdel Integratin [Chrissis et al, 2003], TSP - Team Sftware Prcess [Humphrey, 2000], PSP - Persnal Sftware Prcess [Humphrey, 1995], SPICE - Sftware Prcess Imprvement and Capability determinatin [SPICE]. Pr utr lad, prcesss ágeis têm fc n prdut em si, u seja, mais imprtante é entregar sftware em detriment de dcumentaçã. Sã reativs pr natureza, nde atitudes sã tmadas sb demanda e é desenvlvid smente necessári e quand necessári. Trata-se de um desenvlviment iterativ e incremental nde, cnstantemente, sã entregues nvs releases d prdut a cliente. As idéias pdem ser encntradas n Agile Manifest [Agile Manifest]. Os elements centrais d manifest sã: Pessas e interações sã mais imprtantes d que prcesss e ferramentas; Sftware executável é mais imprtante d que dcumentaçã; Clabraçã d cliente é mais imprtante d que negciaçã pr cntrat; Reaçã a mudanças é mais imprtante d que plan pré-definid. Prcesss rigrss e prcesss ágeis, ambs têm suas vantagens e desvantagens. Nã existe prcess crret u incrret, existe prcess adequad e inadequad, u seja, para cada tip de prjet é necessári encntrar um pnt de equilíbri entre as duas abrdagens e definir um prcess híbrid que traga benefícis reais [Bhem e Turner, 2004]. Independentemente de quã rigrs u ágil seja prcess, fat é que tems que levar em cnsideraçã cm cntemplar s requisits presentes n desenvlviment web, discutids a lng deste trabalh. N entant, caráter altamente mutável das aplicações web ns leva a crer que uma abrdagem mais ágil venha mais a encntr deste dmíni de aplicações d que um prcess mais rigrs. 2

8 1.2 Organizaçã da Mngrafia A secçã 2 explra as diferenças entre sistemas web e sistemas cnvencinais. Em seguida, na secçã 3, sã enumerads s requisits que devem ser levads em cnsideraçã quand da elabraçã de um prcess de desenvlviment para web. Para trnar a discussã mais cncreta, a secçã 4 apresenta duas prpstas de prcess web existentes. Seguind na mesma linha, na secçã 5, as prpstas apresentadas sã analisadas de acrd cm s requisits descrits anterirmente. Encerrand, a secçã 6 delineia as cnsiderações finais. 2 Diferenças entre Aplicações Web e Aplicações Cnvencinais Existe um cnjunt de diferenças que justificam a necessidade de uma atençã especial a desenvlviment de aplicações web. Algumas características sã únicas de sistemas web, utras também estã presentes ns sistemas cnvencinais, mas sã mais prnunciadas na web. Cm base em [Lwe e Hendersn-Sellers, 2001] e [Kappel et al, 2004], estã secçã destaca tais diferenças que servem cm base para a definirms s requisits necessáris para a definiçã de um prcess de desenvlviment para web. A distinçã é feita primeiramente sb um enfque técnic e, em seguid, questões rganizacinais sã discutidas. 2.1 Diferenças Técnicas Claramente existem diferenças técnicas entre sistemas web e cnvencinais. As mais significantes sã: Diferenças relativas à aplicaçã: Cnteúd: a web é essencialmente um mei de infrmaçã. Além da funcinalidade, uma aplicaçã web é rientada a cnteúd. Cnteúd cmpreende dads estruturads (banc de dads, pr exempl) e nã estruturads (arquivs texts, vídes, etc.). Além diss, cnteúd é dinâmic, precisa ser cntinuamente atualizad e de qualidade em terms de cnsistência e cnfiabilidade. Ist implica em um efetiv prjet de infrmaçã, bem cm gerenciament de cnteúd a- prpriad. Hipertext: na web paradigma fundamental para estruturar a infrmaçã é nçã de hipertext, nde s elements básics sã: nós, els (links) e âncras que ativam estes els. Os nós exibem infrmações e s els ns permitem navegar entre s nós. Ist requer um prjet cuidads e estratégic de navegaçã que preserve a qualidade de acess e evite desrientaçã e sbrecarga cgnitiva. Apresentaçã: lk and feel da aplicaçã web é um fatr de qualidade essencial uma vez que usuáris pdem facilmente abandnar site e ir para utr cncrrente. Nã existe um manual de usuári, prtant a interface tem que ser aut-explicativa, intuitiva e cnsistente cm estil de interaçã. Além diss, a aparência visual está sujeita a mdism, tendências e nvas características técnicas que surgem tds s dias. 3

9 Requisits nã-funcinais de qualidade: requisits de qualidade cm dispnibilidade 24/7, perfrmance, usabilidade, escalabilidade, rbustez e segurança se trnam ainda mais crítics quand expsts externamente a públic. Diferenças relativas a us: Ubiqüidade: à medida que a necessidade de ubiqüidade (u seja, a pssibilidade de acessar a aplicaçã pr diferentes tips de dispsitivs, em diferentes cntexts de us) das aplicações cresce, trna-se necessári prjetar diferentes visões da aplicaçã, uma para cada cntext de us. Infra-estrutura tecnlógica imprevisível: juntamente cm crescente caráter ubíqu, surge uma enrme variedade de dispsitivs de usuári final, cm diferentes capacidades de hardware e sftware, diferentes tamanhs e versões de navegadres. Cnexões de rede diferem cm respeit à largura de banda, cnfiabilidade, estabilidade e dispnibilidade, afetand a questã de QS (qualidade de serviç). Pr fim, usuáris cnfiguram livremente seus navegadres, pdend desabilitar imprtantes funcinalidades. Diferenças relativas a desenvlviment: Ambiente de desenvlviment: a infra-estrutura técnica usada para desenvlver sistemas web é caracterizada pr exacerbada vlatilidade e hetergeneidade. As aplicações sã freqüentemente cnstruídas a partir de cmpnente COTS (cmmercial ff-the-shelf) que sã adaptads e integrads, particularmente para as camadas internas de middleware. Dentre estes cmpnentes se destacam servidres de aplicaçã e framewrks de aplicaçã e persistência. Ist aumenta a imprtância de criar sluções flexíveis que pssam migrar para nvas tecnlgias cm puc esfrç. Outra cnseqüência é dmíni restrit destas tecnlgias pr parte da equipe, aumentand risc d prjet e demandand um cnstante aprimrament d cnheciment. Integraçã cm sistemas legads: aplicações web cstumeiramente precisam se integrar cm sistema legads. Sã sistemas cm interfaces antigas e inaprpriadas que, prtant, precisam ser encapsuladas e adaptadas (wrapping). Este encapsulament é trabalhs e existe risc de nã ser feit de frma crreta e cmpleta. Sistemas legads raramente sã dcumentads e freqüentemente sã mdificads sem ntificaçã, afetand a execuçã d sistema web. Além diss, as tecnlgias para encapsulament sã várias e estã sempre mudand (pr exempl, encapsulament via web services). 4

10 2.2 Diferenças Organizacinais Sb pnt de vista rganizacinal, as diferenças mais preminentes sã: Diferenças relativas a desenvlviment: Incerteza d cliente: devid à alta dinamicidade da web, este dmíni de aplicações nã é bem cmpreendid pels interessads (também chamads de stakehlders). Freqüentemente cliente tem prblemas em articular suas necessidades, bem cm em cmpreender se um determinad design satisfaz suas expectativas. Além diss, é muit cmum a existência de prjets rientads pr uma idéia visinária a invés de uma necessidade bem definida. Ist aumenta a necessidade de desenvlviment incremental basead em prtótips. Alta vlatilidade ds requisits de negóci: frtemente relacinada à questã anterir está a falta de clareza, pr parte d cliente, sbre s reais impacts que a aplicaçã web traz para negóci. Send assim, nã é surpresa esperar que escp e fc d prjet mudem cnsideravelmente a lng d desenvlviment. À medida que a empresa vai aumentand sua participaçã na web, própri mdel de negóci da empresa pde mudar diante de nvas prtunidades utrra descnhecidas. Cicls de desenvlviment muit curts: prjets web, em geral, têm prazs mais curts d que prjets cnvencinais, cmumente de um a três meses. Alta cmpetitividade: a cncrrência na web é muit mais intensificada pela facilidade d usuári final visitar váris sites em um curt espaç de temp. Prtant, a aplicaçã precisa estar sempre atualizada e atraente de acrd cm as tendências atuais. Equipes multidisciplinares: desenvlviment de uma aplicaçã web é um esfrç multidisciplinar, envlvend prfissinais das mais diversas áreas, cm habilidades bem díspares. Sã designers gráfics, autres, engenheirs de sftware, prgramadres, publicitáris, cnsultres de negóci, entre utrs. Em geral, há muit jvens inexperientes inclinads a empregar tecnlgias nvas de frma ad-hc. Evluçã e manutençã de granularidade fina: aplicações web estã sujeitas a mudanças diárias e permanente evluçã. Tipicamente tems um prcess cntínu de atualizaçã de cnteúd, mudanças editriais, ajustes de interface, etc. Sem falar nas mudanças tecnlógicas mais radicais. Diferenças relativas a us: Diversidade de tips de usuári: na web s usuáris variam em i- dade, cnheciment sóci-cultural, bjetivs, intenções, habilidades e capacidades. Esta hetergeneidade, diferentes perfis de usuári, precisa ser cnsiderada, dad que na web s usuáris sã inteiramente livres para esclherem as aplicações que lhe frem mais cnvenientes. 5

11 Saznalidade (u características temprárias): aplicações pssuem requisits que sã saznais u tempráris, u seja, infrmações e/u funcinalidades que sã ferecidas, estrategicamente, pr uma faixa de temp, que pde se repetir u nã. Um exempl sã s cntexts navegacinais relacinads a períd natalin. Analisand que fi expst nesta secçã, percebe-se que um prcess de desenvlviment vltad para aplicações web é caracterizad pr freqüentes mudanças e ajustes, que sã necessárias devid à rápida evluçã tecnlógica, a surgiment de nvas tendências, à vlatilidade ds requisits e as crngramas apertads. Um prcess para web precisa ser altamente iterativ, flexível e rientad a prtótips. 3 Requisits de um Prcess de Desenvlviment Web Sb a luz das diferenças descritas anterirmente e d trabalh expst em [McDnald e Welland, 2004], fram identificads dezessete requisits que um prcess de desenvlviment de aplicações web deve pnderar. Cm era de se esperar, estes requisits se cnfundem cm s requisits que um métd de especificaçã de aplicações web (pr exempl, OOHDM [Rssi, 1996]) deve cntemplar, refrçand a imprtância d empreg de um métd desta natureza a lng d prcess. Send assim, um prcess web deve dar suprte para: 1. Autria (u engenharia) de cnteúd; 2. Autria (u engenharia) de navegaçã sbre cnteúd; 3. Autria (u engenharia) de apresentaçã (interface); 4. Ubiqüidade; 5. Definiçã de arquitetura multicamadas 5.1. Esclha, adaptaçã e utilizaçã de framewrks e cmpnentes; 5.2. Integraçã cm sistemas legads; 5.3. Distribuiçã das camadas entre servidres; 5.4. Definiçã d que rda n navegadr e d que rda n servidr; 6. Cicls de vida de desenvlviment curts; 7. Equipes multidisciplinares; 8. Desenvlviment cncrrente de pequenas equipes em tarefas interdependentes; 9. Pesquisa de mercad; 10. Incerteza d cliente e vlatilidade ds requisits; 11. Reengenharia de mdels de negóci a partir de mdels da aplicaçã; 12. Análise de negóci e avaliaçã junt a usuári final; 13. Diferentes perfis de usuári (persnalizaçã); 14. Requisits explícits (funcinais e nã-funcinais); 15. Testes rigrss cm relaçã as requisits; Teste de perfrmance, escalabilidade e resiliência; 6

12 16. Autria (engenharia) de Segurança Autrizaçã pr papéis de usuári (user rle); Definiçã de quais transações sã críticas (precisam de criptgrafia) e nã-críticas; 17. Manutençã e evluçã em granularidade fina. 4 Duas Prpstas Existentes Diante da crescente necessidade de um prcess de desenvlviment vltad para a- plicações web, a lng ds últims ans, alguns prcesss específics e evluções de prcesss de sftware tradicinais fram prpsts para web. A seguir, serã brevemente descrits dis prcesss. Uma prpsta ágil chamada XWebPrcess e uma prpsta mais rigrsa chamada OPEN-Web Prcess. 4.1 XWebPrcess XWebPrcess [Sampai, 2004] [Sampai et al, 2004a] [Sampai et al, 2004b] é um prcess ágil para desenvlviment de aplicações web basead ns princípis d XP (Extreme Prgramming) [Beck, 2000]. O XWebPrcess é resultad da adaptaçã d XP para lidar melhr cm imprtantes questões de sistemas web: interfaces cm usuári cmplexas, navegaçã, requisits nã-funcinais (distribuiçã, cncrrência, balanceament de carga), testes e suprte de infra-estrutura. Uma vez que XWebPrcess deriva d XP, é interessante, em primeir lugar, apresentar uma breve descriçã d XP. O prcess ágil XP cnfia em cinc pilares de valr: Cmunicaçã: significa que s membrs da equipe devem interagir cnstantemente para discutir s prblemas e prpr sluções. Além diss, cliente, alguém que represente, deve ser um membr ativ da equipe para elucidar s requisits e regras de negóci envlvids; Feedback: implica que cada membr da equipe (prgramadr, gerente, cliente, etc.) deve frnecer feedback cnstante sbre s prblemas encntrads para reslvê-ls quant antes; Simplicidade: cnsiste em esclher a sluçã mais simples que funcine, u seja, evitar cmplexidade e trabalh desnecessári. Fazer estritamente necessári e cm design mais simples. Pssíveis prblemas que surjam em funçã desta decisã sã minimizads cm práticas cm refactring e testes autmatizads; Cragem: é precis ter cragem para substituir que está ruim u errad pr alg que esteja melhr u crret. Ou seja, nã tenha med de fazer refactring em grandes partes d códig quand necessári, bem cm descartar requisits que se trnem bslets. Respeit: s membrs da equipe têm que respeitar uns as utrs. N XP, prgramadres nunca devem cnfirmar mdificações que façam prgrama parar de cmpilar, que façam s testes falharem, u cas cntrári atrasam trabalh de seus cmpanheirs. Devem sempre primar pela qualidade. Sb 7

13 utra ótica, nenhum membr da equipe deve se sentir rejeitad u ignrad, de frma a manter a equipe sempre feliz e mtivada. Para subsidiar s quatr pilares acima, XP prpõe algumas práticas que sã, resumidamente, descritas a seguir: Planning game (Jg de Planejament): um release deve ser menr pssível (dis a três meses). Cada release é dividid em iterações semanais (duas a três semanas), nde histrietas (pequens cass de us) sã implementads. N iníci da semana, desenvlvedres e cliente reúnem-se para analisar as funcinalidades. O esfrç estimad para implementar cada histrieta é definid pels prgramadres e cliente define a priridade da histrieta. Small Releases (Pequenas Versões): um release deve ser pequen de frma a facilitar desenvlviment, bem cm prcess de aceitaçã e satisfaçã pr parte d cliente. Metaphr (Metáfra): metáfra d sistema é uma história que tds (clientes, prgramadres, gerentes, etc.) pdem cntar sbre cm sistema funcina. Enfim, uma história que facilite entendiment cmum sbre s cnceits (abstrações) envlvids. Simple Design (Prjet Simples): prjetar, de frma simples, estritamente necessári sb demanda. Whle Team (Equipe Cesa): cliente deve ser um membr efetiv da e- quipe, dispnível para esclarecer eventuais questinaments. Custmer Tests (Testes de Aceitaçã): testes cnstruíds pel cliente, em cnjunt cm analistas e testadres, para validar um u mais requisits d sistema. Também chamads de testes funcinais. Sustainable Pace (Ritm Sustentável): a equipe deve trabalhar em um ambiente adequad e agradável, sempre mtivada e sb um ritm de trabalh saudável (40 hras/semana, 8 hras/dia) sem hras extras. Hras extras smente se frem impreterivelmente necessárias. Stand-up Meeting (Reuniões em Pé): reuniões em pé (pr exempl, n iníci d dia) para nã perder fc, smente abrdand que fi realizad e próximas tarefas a realizar. Estas reuniões devem ser de curta duraçã. Cllective Ownership (Psse Cletiva): códig fnte é um bem cmum, u seja, qualquer membr da equipe pde alterar qualquer parte d códig sem precisar pedir permissã. Tds devem ter cnheciment de tdas as partes d códig. Pair Prgramming (Prgramaçã em Par): td códig é prduzid pr um par de prgramadres. Um prgramadr cdifica e utr analisa, sugerind melhraments e prevenind errs. Os pares sã freqüentemente mdificads, fazend cm que s prgramadres participem d desenvlviment de diferentes histrietas, btend, desta frma, um cnheciment geral de td sistema; Cding Standards (Padrões de cdificaçã): devem ser definids padrões (regras) de estruturaçã d códig. Estas regras devem ser seguidas, garantind assim uma hmgeneidade em td códig, facilitand entendiment. 8

14 Test Driven Develpment (Desenvlviment Orientad a Testes): primeir crie s testes unitáris e, smente depis, crie códig que passe ns testes. Tal prática ajuda a manter a qualidade d prjet. Refactring (Refatraçã): códig deve ser, sempre que necessári, melhrad, sem alterar a funcinalidade. Juntamente cm testes autmatizads (autmated testing) ajuda a manter a qualidade d códig, dad que tda vez que crre uma alteraçã tds s testes, na íntegra, têm que ser passads cm sucess. Tda funcinalidade pde ser alterada pr qualquer membr da equipe. Cntinuus Integratin (Integraçã Cntínua): a equipe de desenvlviment deve trabalhar sempre na última versã d prjet. Sempre que uma nva funcinalidade fr prduzida e passar ns testes, esta deve ser integrada a versã atual d sistema, n repsitóri de códig. Ist evita atrass mais tarde devid a prblemas de integraçã. O prcess XWebPrcess fi criad adaptand elements d XP e adicinad nvs elements de frma a custmizar XP para dmíni web. Primeiramente XP fi mdelad usand meta-mdel SPEM [SPEM] para melhr entendiment. Em seguida, cm base nas características das aplicações web, mdel SPEM d XP fi enriquecid gerand mdel SPEM d XWebPrcess. Send assim XWebPrcess pde ser vist cm uma extensã d XP, cm mstra a figura 1. Figura 1. Passs de criaçã d XWebPrcess [Sampai et al, 2004a] O XWebPrcess é descrit, em SPEM, usand duas visões: visã dinâmica e estrutural. A visã dinâmica mstra cm as disciplinas 1 estã relacinadas entre si durante a execuçã d prcess, a lng d temp. Já a visã estrutural descreve a estrutura interna de cada disciplina, destacand atividades, artefats prduzids e atres envlvids, bem cm s relacinaments entre eles. A figura 2 ilustra a visã dinâmica d XWebPrcess. Nesta figura, as disciplinas em destaque sã disciplinas inseridas u mdificadas n XP. 1 Uma disciplina em SPEM representa um cnjunt de elements de prcess relacinads (atividades, artefats, atres) agrupads pr um tema cmum. Exempls de disciplinas sã: análise, design, testes, etc. 9

15 Figura 2. Visã dinâmica d XWebPrcess [Sampai et al, 2004a] O prcess cmeça cm uma disciplina explratória que fi mdificada para incluir sessões de prtótip. O bjetiv é avaliar, junt a cliente e analistas de negóci, tecnlgias, arquiteturas e prtótips para verificar a viabilidade d prjet e definir s requisits iniciais. Em seguida, tems a disciplina de definiçã e revisã ds requisits. Nesta, clientes e prgramadres definem as histrietas para próxim release. Prgramadres estimam esfrç necessári para cada histrieta e s clientes definem as priridades das histrietas. Esta disciplina fi mdificada para incluir uma atividade de design de arquitetura, visand definir uma estrutura flexível que permita, mais facilmente, integraçã cm utrs sistemas e adiçã de nvas tecnlgias. Cm as histrietas em mãs, clientes e prgramadres planejam próxim release, selecinand as histrietas a serem implementadas. Dentr de cada release, várias interações crrem. Em cada iteraçã, histrietas sã implementadas e testadas. Para cada iteraçã crrem as seguintes disciplinas: planejament de iteraçã, design, escrita de teste de unidade, cdificaçã, teste e integraçã. A disciplina de design fi mdificada para incluir a atividade de design da camada de dads. Durante uma iteraçã, pde haver mudanças ns requisits e estimativas anterires precisam ser reavaliadas. Escrita de testes funcinais, bem cm design de na- 10

16 vegaçã e apresentaçã sã feits em paralel cm as atividades anterires. A disciplina de design de navegaçã e apresentaçã fi inserida devid à inquestinável imprtância que estes dis aspects têm em uma aplicaçã web. Quand a iteraçã termina, é necessári verificar se que fi implementad esta em cnfrmidade cm que se esperava. Prtant, sã executads testes funcinais para tal prpósit. Além diss, fi inserida a disciplina de testes web para verificar se s requisits nã funcinais fram atendids. Se fr a última iteraçã d release, a versã crrente d sistema é psta em prduçã. Depis d primeir release d sistema, entre em cena a disciplina de suprte web que fi inserida cm prpósit de lidar cm a rganizaçã de cmpnentes de hardware e sftware que fazem parte d web site. O prcess termina quand tdas as histrietas tiverem sid implementadas e pstas em prduçã. Tend descrit a dinâmica d prcess, a seguir será apresentada a estrutura interna de cada disciplina mdificada u inserida n XP, u seja, as disciplinas em destaque da figura 2. Para cada disciplina será apresentada um mdel, similar a um diagrama de classes, usand estereótips d SPEM. Nvamente, em cada figura, serã destacads s elements que fram mdificads u inserids n XP. As disciplinas de explraçã e definiçã de requisits sã expstas pelas figuras 3 e 4, respectivamente. Na disciplina de explraçã fram incluídas sessões de prtótip. O web designer é respnsável pela atividade de prttipagem cuja saída é um prtótip, criad cm ajuda de técnicas de prttipagem. Já a disciplina de requisits fi mdificada para incluir a definiçã da arquitetura geral da aplicaçã. Esta arquitetura é muit imprtante, pis é usada em tdas as atividades subseqüentes. Quem define mdel de arquitetura é um desenvlvedr experiente que entenda de reus, manutençã, flexibilidade e perfrmance. 11

17 Figura 3. Explraçã n XWebPrcess [Sampai et al, 2004a] Figura 4. Requisits n XWebPrcess [Sampai et al, 2004a] A disciplina de análise e design, apresentada na figura 5, fi mdificada para incluir a atividade de design de camada de dads, executada pel DBA. Esta atividade pde ser tã simples quant definir esquema de um únic banc de dads relacinal u tã cmplexa quant fazer a mediaçã entre várias fntes de dads hetergêneas. A figura 6 apresenta uma das mais imprtantes disciplinas inseridas: navegaçã e apresentaçã. O web designer elabra design de navegaçã, assistid pel prgramadr e arquitet. Para prjetar a navegaçã, métds cm OOHDM [Schwabe e Rssi, 1995] [Schwabe e Rssi, 1998] sã muit bem vinds, pis pssuem primitivas cm este prpósit específic. O web designer também é respnsável pr prjetar a interface abstrata e, cm base nesta, a interface física. 12

18 Figura 5. Análise e Design n XWebPrcess [Sampai et al, 2004a] Figura 6. Navegaçã e Apresentaçã n XWebPrcess [Sampai et al, 2004a] Para finalizar, as disciplinas de testes web e suprte web sã mstradas na figuras 7 e 8, respectivamente. Na disciplina de teste, um prgramadr executa s testes, pdend ser assistid pel cliente, que s valida, e pel analista de suprte que cnfigura td ambiente para que s testes pssam ser realizads. Já na disciplina de suprte, administradr d web site realiza duas atividades: gerenciament de cnteúd e gerenciament de infra-estrutura (scripts, páginas, cmpnentes, vídes, áudi, etc.). Figura 7. Testes Web n XWebPrcess [Sampai et al, 2004a] Figura 8. Suprte Web n XWebPrcess [Sampai et al, 2004a] 13

19 4.2 OPEN-Web Prcess OPEN-Web Prcess [Haire et al, 2001] [Lwe e Hendersn-Sellers, 2001] é uma extensã d prcess OPEN [OPEN] [Graham et al, 1997] [Hendersn-Sellers et al, 1998] para desenvlviment de aplicações web. OPEN (Object-Oriented Prcess, Envirnment, and Ntatin) é um framewrk de prcess, cnhecid pr OPF (OPEN Prcess Framewrk) que abrange cicl de vida cmplet de desenvlviment, incluind aspects de negóci e de sftware. Trata-se de um meta-prcess, a partir d qual pde ser gerad um prcess específic (instância) para uma dada rganizaçã. OPEN fi desenvlvid e é mantid pr um cnsórci, sem fins lucrativs, cmpst pr pesquisadres, acadêmics, desenvlvedres e empresas. Cm pde ser vist na figuras 9 e 10, s maires cmpnentes deste meta-mdel sã: Wrk Prducts (artefats): s cmpnentes que sã desenvlvids n prjet (dcument, diagrama, mdel, módul, classe, etc.); Languages (linguagens): s cmpnentes usads para dcumentar s wrk prducts (linguagem natural, UML, Java, etc.); Prducers (prdutres): s cmpnentes que desenvlvem s wrk prducts (prgramadr, analista, designer, gerente, cliente, etc.); Wrk Units (unidades de trabalh): s cmpnentes que mdelam as perações executadas pels prducers a desenvlver wrk prducts. Há três tips de wrk unit: Activity (atividade): bjetiv mair. Define quê, nã cm. É cmpst pr tasks; Task (tarefa): bjetiv menr, u seja, metas para atingir bjetiv mair. Ainda define quê, nã cm. Resultam na criaçã, mdificaçã u avaliaçã de um u mais wrk prducts; Technique (técnica): define cm perfazer uma dada task (cass de us, cartões CRC, design patterns, entrevista, etc.). Stages (estágis): s intervals de temps que prvêem uma macrrganizaçã para as wrk units. Pdem ter duraçã (Cycle, Phase, Wrkflw, Prject, Build, Release, Deplyment) u nã (milestne). Milestne é um pnt n temp que indica que uma meta fi atingida. A figura 11 mstra um e- xempl de stages. 14

20 Figura 9. Cmpnentes d meta-prcess OPEN [OPEN] Figura 10. Wrk Units d meta-prcess OPEN [Lwe e Hendersn-Sellers, 2001] 15