UNIFENAS UNIVERSIDADE JOS DO ROSRIO VELLANO

AMAURY CSSIO BALDIM ANDR LUZ SILVA DIEGO CAIXETA RODRIGUEZ SIMONIDES ZACARIAS ALVES JUNIOR

DESENVOLVIMENTO DE SISTEMAS ADOTANDO AS REGRAS E PRTICAS DE XP (PROGRAMAO EXTREMA) E UP (PROCESSO UNIFICADO)

Alfenas/MG 2009

AMAURY CSSIO BALDIM ANDR LUZ SILVA DIEGO CAIXETA RODRIGUEZ SIMONIDES ZACARIAS ALVES JUNIOR

DESENVOLVIMENTO DE SISTEMAS ADOTANDO AS REGRAS E PRTICAS DE XP (PROGRAMAO EXTREMA) E UP (PROCESSO UNIFICADO)

Monografia apresentada para concluso do Curso de Cincia da Computao da Universidade Jos do Rosrio Vellano. Orientador: Prof. Celso de vila Ramos

Alfenas/MG 2009

AMAURY CSSIO BALDIM ANDR LUZ SILVA DIEGO CAIXETA RODRIGUEZ SIMONIDES ZACARIAS ALVES JUNIOR

DESENVOLVIMENTO DE SISTEMAS ADOTANDO AS REGRAS E PRTICAS DE XP (PROGRAMAO EXTREMA) E UP (PROCESSO UNIFICADO)

Monografia defendida e aprovada em __/__/____ pela banca examinadora constituda pelos professores:

_____________________________________ Prof. Celso de vila Ramos Orientador

_____________________________________ Prof(a). Jaqueline Corra Silva de Carvalho Examinadora

_____________________________________ Prof. Jos Claudio Reis Examinador

Dedico este trabalho, primeiramente, a Deus, aos meus pais, meus irmos e, claro, a minha namorada, que me ajudaram incondicionalmente nesta etapa da vida. Amaury Cssio Baldim

Dedico este trabalho a Deus, a meus pais e irmo, a minha namorada e aos meus amigos pelo apoio que me deram ao longo desses anos, pois em momentos importantes de minha vida, eles sempre se fizeram presentes com palavras de encorajamento e afeto. Andr Luz Silva

Dedico este trabalho a Deus, aos meus pais, familiares e amigos que sempre apoiaram, acreditaram e me deram o auxilio fundamental em mais esta fase de minha vida. Diego Caixeta Rodriguez

Dedico este trabalho a Deus, em especial a minha av, minha me e meu pai, que me apoiaram em todas as fases dos meus estudos. Simoniades Zacarias Alves Junior

Enquanto voc no se der valor, no valorizar seu tempo. Enquanto no der valor ao tempo, no far nada de importante. (M. Scott Peck)

RESUMO O desenvolvimento a partir de metodologias e processos que ajudam a modelar e construir sistemas esto em constante crescimento, mas ainda continua sendo uma atividade complexa e demorada. Os processos abordados neste presente trabalho permitem conduzir um projeto de maneira consistente e com isso vem ganhando cada vez mais adeptos devido a esta caracterstica. Ser mostrada atravs do desenvolvimento de uma aplicao web, a comparao entre os processos XP (Extreme Programming) e UP (Unified Process). Esta aplicao em questo, desenvolvida em ambos os processos para efeitos de comparao utilizando a plataforma Microsoft Visual Studio, um simples site institucional de uma boutique. Os resultados obtidos so descritos no desenvolvimento dos projetos, e comparados para se chegar a uma concluso sobre o uso dos dois processos. Conclui-se que o processo XP se mostrou mais eficaz, gil e de custo baixo, no desenvolvimento de um projeto de pequeno porte. J o UP acaba sendo invivel devido suas prticas que suportam projetos grandiosos. Palavras-chave: XP (Extreme Programming). UP (Unified Process). Aplicao Web.

ABSTRACT The development from methodologies and processes that help shape and build systems are constantly growing, but still remains a complex and time consuming. The processes addressed in this investigation capable of leading a project in a manner consistent with that is gaining more fans because of this feature. It will be shown through the development of a web application, the comparison between the processes XP (Extreme Programming) and UP (Unified Process). This application in question, developed in both cases for comparison purposes using the Visual Studio platform, is an institutional site of a boutique. The results are described in project development, and compared to arrive at a conclusion on the use of two processes. Concluded that the XP process is more effective, flexible and low cost in developing a small project. Since the UP has been impossible due to their practices that support grand projects. Keywords: XP (Extreme Programming).UP (Unified Process). Web applications.

LISTA DE FIGURAS FIGURA 1: Prticas do Processo XP .......................................................................................24 FIGURA 2: Fases do Processo XP ...........................................................................................29 FIGURA 3: Fases do Processo Unificado ................................................................................38 FIGURA 4: Fases dos Processos XP e UP em relao s atividades genricas de desenvolvimento.......................................................................................................................43 FIGURA 5: Histrias XP escritas pelo Cliente. .......................................................................45 FIGURA 6: Cronograma ..........................................................................................................45 FIGURA 7: Modelo ER............................................................................................................46 FIGURA 8: Projeto dividido em Releases ...............................................................................47 FIGURA 9: Cadastro de Roupas ..............................................................................................49 FIGURA 10: Listagem das Roupas ..........................................................................................50 FIGURA 11: Detalhes da Roupa ..............................................................................................50 FIGURA 12: Adicionado a excluso de Roupas ......................................................................51 FIGURA 13: Adicionado a edio de Roupas .........................................................................52 FIGURA 14: Requisitos Principais ..........................................................................................53 FIGURA 15: Escopo do Projeto...............................................................................................54 FIGURA 16: Casos de Uso preliminares .................................................................................55 FIGURA 17: Requisitos No-Funcionais.................................................................................56 FIGURA 18: Cronograma da Iterao 1 ..................................................................................56 FIGURA 19: Requisitos Refinados ..........................................................................................58 FIGURA 20: Riscos .................................................................................................................59 FIGURA 21: Detalhes do Risco ...............................................................................................59 FIGURA 22: Casos de Uso Expandidos ..................................................................................60 FIGURA 23: Estrutura geral do Site ........................................................................................61 FIGURA 24: Estrutura da pgina Principal..............................................................................62 FIGURA 25: Demais Pginas do Site ......................................................................................63 FIGURA 26: Modelo ER..........................................................................................................64 FIGURA 27: Dicionrio de Dados Tabela Produtos .............................................................65 FIGURA 28: Banco de Dados Microsoft Access.....................................................................66 FIGURA 29: Estrutura criada e liberada para o cliente............................................................67 FIGURA 30: Pgina inicial do Administrador .........................................................................68 FIGURA 31: Login para a rea administrativa ........................................................................69 FIGURA 32: Tempo gasto em cada Fase do XP......................................................................73 FIGURA 33: Tempo gasto em cada Fase do UP......................................................................73

LISTA DE ABREVIATURAS XP - Extreme Programming UP - Unified Process MA - Modelagem gil FDD - Feature-Driven Development CRC - Class, Responsibility and Collaboration OMG - Object Management Group UML - Unified Modeling Language A/POO - Anlise e Projeto Orientados a Objeto SQL - Structured Query Language VB - Visual Basic CSS - Cascading Style Sheets HTML - Hyper Text Markup Language ER - Entidade Relacionamento

SUMRIO 1 INTRODUO ...................................................................................................................15

1.1 Origem e importncia do trabalho.......................................................................................... 15 1.2 Objetivo...................................................................................................................................... 15 1.3 Organizaes do trabalho......................................................................................................... 16

2 REFERENCIAL TERICO ..............................................................................................17

2.1 MODELAGEM GIL.............................................................................................................. 17
2.1.1 Valores defendidos pela MA............................................................................................................... 18 Comunicao ............................................................................................................................................... 18 Coragem....................................................................................................................................................... 19 Retorno ........................................................................................................................................................ 19 Humildade.................................................................................................................................................... 19 Simplicidade ................................................................................................................................................ 19 2.1.2 Programao Extrema (XP) ................................................................................................................ 20 Viso Geral .................................................................................................................................................. 20 Valores do XP.............................................................................................................................................. 20 Comunicao........................................................................................................................................... 20 Simplicidade............................................................................................................................................ 21 Feedback ................................................................................................................................................. 21 Coragem .................................................................................................................................................. 21 Variveis de desenvolvimento de software .................................................................................................. 22 Custo ....................................................................................................................................................... 22 Tempo ..................................................................................................................................................... 22 Qualidade ................................................................................................................................................ 22 Escopo..................................................................................................................................................... 23 As 12 prticas do XP.................................................................................................................................... 23 O jogo do planejamento .......................................................................................................................... 24 Entregas freqentes ................................................................................................................................. 24 Metfora .................................................................................................................................................. 25 Projeto simples ........................................................................................................................................ 25 Testes ...................................................................................................................................................... 25 Refatorao ............................................................................................................................................. 26 Programao em pares ............................................................................................................................ 26 Propriedade coletiva................................................................................................................................ 26 Integrao contnua ................................................................................................................................. 26 Semana de 40 horas................................................................................................................................. 27 Cliente presente....................................................................................................................................... 27 Padres de codificao............................................................................................................................ 27 Caractersticas da equipe XP........................................................................................................................ 27 Gerente de projeto ................................................................................................................................... 28 Coach ...................................................................................................................................................... 28 Analista de teste ...................................................................................................................................... 28 Redator tcnico ....................................................................................................................................... 28 Desenvolvedor ........................................................................................................................................ 28 As quatro fases............................................................................................................................................. 29 Planejamento ........................................................................................................................................... 29 Projeto ..................................................................................................................................................... 30 Codificao ............................................................................................................................................. 30 Teste........................................................................................................................................................ 31

2.2 PROCESSO UNIFICADO....................................................................................................... 32

2.2.1 Introduo ........................................................................................................................................... 32 2.2.2 Princpios fundamentais...................................................................................................................... 32 Dirigido por casos de uso............................................................................................................................. 33 Centrado na arquitetura................................................................................................................................ 33

Entendendo a viso global ...................................................................................................................... 34 Organizando o esforo de desenvolvimento............................................................................................ 35 Facilitando as possibilidades do reuso .................................................................................................... 35 Facilitando e evoluo do sistema........................................................................................................... 35 Dirigindo os casos de uso........................................................................................................................ 36 Iterativo e incremental ................................................................................................................................. 36 Benefcios................................................................................................................................................ 37 2.2.3 As quatro fases.................................................................................................................................... 37 Concepo.................................................................................................................................................... 38 Elaborao ................................................................................................................................................... 39 Construo ................................................................................................................................................... 39 Transio...................................................................................................................................................... 40

3 MATERIAL E MTODOS ................................................................................................41

3.1 Microsoft Visual Studio............................................................................................................ 41 3.2 Microsoft SQL Server............................................................................................................... 41 3.3 Microsoft Office Access ............................................................................................................ 41 3.4 Linguagem C# ........................................................................................................................... 41 3.5 Linguagem VB.NET ................................................................................................................. 42 3.6 Fireworks................................................................................................................................... 42 3.7 Etapas......................................................................................................................................... 42

4 DESENVOLVIMENTO DO SISTEMA............................................................................43
4.1 Descrio geral do sistema ....................................................................................................... 43 4.2 Desenvolvimento utilizando o XP ............................................................................................ 44
4.2.1 Comunicao ...................................................................................................................................... 44 Fase de Planejamento................................................................................................................................... 44 4.2.2 Planejamento....................................................................................................................................... 45 Fase de Planejamento................................................................................................................................... 45 4.2.3 Modelagem ......................................................................................................................................... 46 Fase de Projeto............................................................................................................................................. 46 4.2.4 Construo .......................................................................................................................................... 47 Fase de Codificao ..................................................................................................................................... 47 4.2.5 Implantao......................................................................................................................................... 52 Fase de Teste................................................................................................................................................ 52

4.3 Desenvolvimento utilizando o UP ............................................................................................ 53

4.3.1 Comunicao ...................................................................................................................................... 53 Fase de Concepo....................................................................................................................................... 53 4.3.2 Planejamento....................................................................................................................................... 54 Fase de Concepo....................................................................................................................................... 54 Fase de Elaborao ...................................................................................................................................... 57 4.3.3 Modelagem ......................................................................................................................................... 60 Fase de Elaborao ...................................................................................................................................... 60 4.3.4 Construo .......................................................................................................................................... 65 Fase de Construo ...................................................................................................................................... 65 4.3.5 Implantao......................................................................................................................................... 69 Fase de Construo ...................................................................................................................................... 69 Fase de Transio......................................................................................................................................... 69 Iteraes .................................................................................................................................................. 70

5 RESULTADO E DISCUSSES.........................................................................................71
5.1 Comunicao ............................................................................................................................. 71 5.2 Planejamento............................................................................................................................. 71

5.3 Modelagem ................................................................................................................................ 71 5.4 Construo................................................................................................................................. 72 5.5 Implantao............................................................................................................................... 72 5.6 Outras comparaes ................................................................................................................. 72

CONCLUSO.........................................................................................................................74 REFERNCIAS .....................................................................................................................75

15

1 INTRODUO
Atualmente, a cada dia aumenta a demanda por sistemas cada vez mais sofisticados em um pequeno intervalo de tempo, visando satisfazer as necessidades das mais diversas reas. Porm, desenvolver software ainda uma atividade difcil, demorada e arriscada. Dois processos de desenvolvimento de software vm ganhando cada vez mais adeptos devido as suas caractersticas que permitem conduzir um projeto de maneira consistente: Programao Extrema (Extreme Programming ou XP) e Processo Unificado (Unified Process ou UP).

1.1 Origem e importncia do trabalho

A Programao Extrema capaz de englobar valores nos quais agilizam e tornam o projeto mais dinmico, mantendo sua qualidade. Tem como objetivo superar de forma segura os principais riscos de um projeto de software. O Processo Unificado um conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de software. realizado de maneira iterativa e adaptativa e as atividades podem ser adicionadas ou removidas de acordo com as necessidades do projeto. Estes dois processos possuem maneiras diferentes de tratar o desenvolvimento de software. A grande importncia deste trabalho est nos resultados que sero alcanados ao adotarmos suas regras e prticas, que devero ser consistentes e satisfatrios para ambos.

1.2 Objetivo
Este trabalho tem como objetivo, apresentar os fundamentos bsicos de desenvolvimento de software adotando as regras e prticas dos processos Programao Extrema e Processo Unificado, bem como suas caractersticas e benefcios. Portanto, ser desenvolvido um mesmo projeto real, adotando estes dois processos, para anlise de diversos fatores.

16

1.3 Organizaes do trabalho

O Captulo I a Introduo, onde esto sendo abordadas a origem do trabalho e sua importncia. O Captulo II traz o Referencial Terico, no qual ser apresentado todo fundamento terico empregado neste trabalho, para desenvolvimento, utilizando os processos XP e UP. O Captulo III, chamado de Material Mtodos traz uma abordagem dos passos que sero seguidos para o desenvolvimento do projeto estudado. O Captulo IV o Desenvolvimento do Sistema, onde ser mostrada uma anlise prtica geral dos processos utilizados. O Captulo V traz o Resultado e Discusses, onde so apresentados os principais resultados obtidos com o estudo dos processos. O Captulo VI a Concluso, apresentando as concluses obtidas.

17

2 REFERENCIAL TERICO
2.1 MODELAGEM GIL
Analisando o cenrio atual de desenvolvimento de software observa-se uma situao um pouco desconfortvel, longe daquilo que se deseja. A grande maioria dos sistemas no satisfaz os requisitos dos clientes, quando entregues, geralmente j estouraram o oramento ou esto atrasados. Pensando em reverter esse quadro, um grupo inicial de 17 metodologistas formou a Agile Software Development Alliance em fevereiro de 2001. Um ponto interessante deste grupo que todos vieram de diferentes reas de formao e ainda assim so capazes de concordar em questes nas quais os metodologistas normalmente no concordam. Tal grupo definiu um manifesto contendo quatro declaraes de valores, visando amenizar o problema encontrado no desenvolvimento de software, encorajando melhores meios para o desenvolvimento. Os valores do Manifesto gil so: Indivduos e interaes valem mais que processos e ferramentas. Um software funcionando vale mais do que documentao extensa. A colaborao do cliente vale mais que a negociao de contrato. Responder a mudanas vale mais que seguir um planejamento.
O importante a se entender que enquanto voc deve valorizar os conceitos do lado direito, voc deve valorizar ainda mais os do lado esquerdo. Uma boa maneira de pensar sobre o manifesto que ele define preferncias, no alternativas, encorajando o enfoque de certas reas, mas sem eliminar outras [...] (AMBLER, 2004, p.23).

A MA descreve as habilidades necessrias para realizar uma modelagem eficaz como parte de projetos de software que precisam ter agilidade e oferecer qualidade aos clientes. um processo baseado na prtica que descreve como um modelador gil deve ser. Um modelo gil um modelo inteligvel, bom o suficiente, nada mais, que atende seu propsito; ele suficientemente preciso, consistente e detalhado visando prover um valor positivo e de maneira to simples quanto possvel.

18

Em outras palavras, modelagem gil no um processo prescritivo, no havendo, portanto, especificaes de como se deve elaborar um modelo para o desenvolvimento de um determinado software, uma forma efetiva de se trabalhar em conjunto para atingir as necessidades das partes interessadas no projeto. A MA uma mistura de mtodos simples de modelagem com a ordem vital de atributos de modelagem de software. A eficincia de um processo de desenvolvimento est na sua modelagem, portanto extremamente importante haver comunicao eficaz dentro de uma equipe de desenvolvimento, assim como entre os clientes do projeto. A Modelagem gil no significa menos modelagem; na verdade, muitos desenvolvedores acharo que esto fazendo mais modelagem MA do que antes. Pense na MA como uma arte, no uma cincia [...] (AMBLER, 2004, p.25). Se por um lado h casos em que a modelagem em projetos de software no existe gerando produtos mal projetados, em outros ela excessiva, tirando o foco do desenvolvimento de software, tornando-o lento ou fazendo que at mesmo pare. A MA conduz o desenvolvedor a encontrar um ponto mdio, no qual se modela o suficiente para concluir seu sistema de forma satisfatria, mas no a ponto de tornar isso uma carga e retardar o projeto. Existem vrios processos geis tais como, o XP que uma abordagem deliberada e disciplinada para desenvolvimento de software, a FDD que possui requisitos e passos mais formais que o XP, alm de possuir um mecanismo mais preciso para o acompanhamento do projeto, o SCRUM que um processo para construir software incrementalmente em ambientes complexos, onde os requisitos so vagos ou mudam com freqncia, entre outros.

2.1.1 Valores defendidos pela MA Comunicao

vital para o sucesso no desenvolvimento de software. Modela-se para ajudar na comunicao, assim desenvolvedores e usurios devem se comunicar e de preferncia frente a frente.

19

Coragem
Extremamente importante, pois, voc no apenas escolhe uma estratgia gil, mas precisa mant-la quando dificuldades aparecerem, necessitando mudar de direo quando decises se mostrarem inadequadas.

Retorno
O nico modo de determinar se o seu trabalho est correto obtendo retorno (feedback), o que tambm inclui retorno em relao aos seus modelos. (AMBLER, 2002, p.37).

Humildade
Modeladores geis tm a humildade de respeitar as pessoas com as quais trabalham, percebendo que talvez possuam outras prioridades e experincias e, portanto, tero pontos de vista diferentes. Deve-se ter a humildade de reconhecer que no se conhece ou se sabe tudo, ento explorar o conhecimento dos membros do grupo pode ser muito vantajoso para a equipe de desenvolvimento.

Simplicidade
Modele apenas para satisfazer as necessidades atuais e o faa da maneira mais simples possvel, ou seja, nunca modele demais.

20

2.1.2 Programao Extrema (XP) Viso Geral

O Extreme Programming (XP) um processo gil para equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Dentre as principais diferenas do XP em relao aos outros processos e metodologias esto: Feedback constante Abordagem incremental A comunicao entre as pessoas encorajada. Segundo Teles (2006, p.21), o XP um processo de desenvolvimento que busca assegurar que o cliente receba o mximo de valor. O XP busca sempre a qualidade junto com o cliente, por isso ele organizado de forma harmnica e coesa para assegurar que o cliente sempre receba o retorno.

Valores do XP
XP caracteriza pelo desenvolvimento rpido e visa a satisfao do cliente, alm de favorecer o cumprimento das estimativas, gerando um ambiente timo de desenvolvimento de software para seus seguidores, que so guiados por quatro valores: Comunicao, Simplicidade, Feedback e Coragem. Ns teremos xito quando tivermos um estilo que contempla um conjunto consistente de valores que servem para necessidades tanto humanas quanto comerciais: comunicao, simplicidade, feedback e coragem (BECK, 2004, p.45). Comunicao Valor mais importante do XP. A comunicao feita entre desenvolvedores/cliente e desenvolvedores entre si. Segundo Beck (2004, p.45) quando analisamos os problemas que ocorreram nos projetos, vemos que muitos deles foram provocados por algum que no conversou com outro

21

algum sobre alguma coisa importante. Essa comunicao deve ser muito bem feita para que no haja problemas futuros no desenvolvimento. A partir dessa comunicao que se obtm o retorno esperado para a soluo do problema proposto pelo cliente. De acordo com mesmo autor, a m comunicao no acontece por acaso. Existem muitas circunstncias que levam a um colapso nas comunicaes. A equipe deve trabalhar de forma intensa para que nada passe por despercebido e que informaes mal passadas no aconteam entre a equipe. Simplicidade Tratar cada problema da maneira simples possvel, a XP recomenda que os trabalhos de hoje sejam resolvidos hoje e que os desenvolvedores confiem em suas habilidades. [...] O valor da simplicidade, que nos ensina a implementar apenas aquilo que suficiente para atender a cada necessidade do cliente [...] (TELES, 2006, p.22). Feedback O feedback uma importante estratgia para que o cliente d o retorno esperado para a equipe de desenvolvimento. Segundo Beck (2004) o feedback concreto trabalha justamente com a comunicao e a simplicidade. Quanto mais feedback voc tiver, mais fcil para comunicao, pois a medida que o cliente e a equipe se comunicam obtm-se o progresso do projeto. Coragem O XP por ser nova e se basear em premissas que diferem das tradicionais, exige coragem a equipe. Beck (2004) cita que quando combinada com a comunicao, simplicidade e feedback concreto, a coragem se torna importante. Os outros valores com a combinao da coragem conseguem fazer com que os desenvolvedores sejam audaciosos em projetos simples.

22

[...] A equipe precisa ser corajosa e acreditar que utilizando as prticas e valores do XP, ser capaz de fazer o software evoluir com segurana e agilidade. (TELES, 2006, p.23).

Variveis de desenvolvimento de software

Existem quatro variveis de controle no desenvolvimento de software. Vamos controlar 4 variveis em nossos projetos: Custo, Tempo, Qualidade e Escopo. Dentre elas, o escopo nos fornece a forma mais valiosa. (BECK, 2004, p.34). Beck (2004) afirma que, foras mximas como clientes e gerentes, ficam encarregados de definir os valores de 3 dessas variveis e o time de desenvolvimento fica com o valor resultante da quarta varivel. Custo Geralmente um sistema muito caro se torna invivel para a empresa. Por outro lado, um sistema muito barato pode no atender o problema do cliente. No comeo de um projeto voc no pode gastar muito de forma alguma. O investimento precisa comear pequeno e crescer com o tempo. Mais tarde voc poder gastar cada vez mais dinheiro de forma produtiva (BECK, 2004). Tempo Normalmente o cliente que determina o prazo de entrega (tempo) do sistema, mas esta varivel pode sofrer alteraes ao longo do desenvolvimento do software. necessrio deixar o cliente sempre a par do andamento do projeto para que ele aceite a possibilidade de adiar a entrega do sistema. Qualidade O XP sempre busca a qualidade mxima do sistema. A qualidade medida de duas formas: a satisfao do cliente e cdigo otimizado.

23

Escopo Um escopo menor faz com que seja possvel fornecer maior qualidade (desde que o problema do negcio do cliente ainda seja resolvido). Tambm permite que voc entregue o produto mais cedo e mais barato. (BECK, 2004, p.34). O XP baseia o escopo na negociao entre clientes e desenvolvedores. O escopo fornece aos desenvolvedores as funcionalidades do sistema que sero desenvolvidas.

As 12 prticas do XP
Das quatro variveis: Custo, Tempo, Qualidade e Escopo, resultam em doze prticas na XP (12 mandamentos): [...] onde uma prtica fraca, os pontos fortes de outras prticas compensaro essa fraqueza [...] (BECK, 2004, p.65). A Figura 1 mostra o conjunto de atividades que as equipes do XP tm como base para seu desempenho, dando-as mais confiana em suas prticas, uma vez que os pontos fracos de uma prtica so compensados pelos pontos fortes de outra. Aplicadas em conjunto, o desenvolvimento de software funciona melhor, tornando mais eficaz.

24

Equipe (Tcnicos e Clientes)

Produtividade Coletiva Teste Unitrio Teste de Aceitao

Padro de Cdigo

Programao em Par

Refatorao

Jogo de Planejamento

Integrao Contnua

Design Simples

Rtimo Sustentvel

Metforas

Pequenas Verses

FIGURA 1: Prticas do Processo XP Fonte: http://www.devmedia.com.br/space.asp?id=153771l (2007)

O jogo do planejamento Todo o projeto em XP dividido em releases e iteraes. No incio de cada release e de cada iterao ocorre o jogo do planejamento. Trata-se de uma reunio onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que faro parte do prximo release ou da prxima iterao. Entregas freqentes Em um perodo curto de tempo o desenvolvedor entrega uma nova verso do sistema ao cliente. Beck (2004) afirma que cada verso entregue ao cliente deve ter o tamanho menor possvel, contendo os requisitos de maior valor para o negcio.

25

A verso entregue precisa atender como um todo ao negcio, [...] Voc no pode implementar meia funo e entreg-la, s para tornar mais curto o ciclo de entrega [...] (BECK, 2004, p.67). Metfora A metfora o poder de transmitir idias complexas de forma simples, atravs de uma linguagem comum que estabelecida entre a equipe de desenvolvimento e tambm para o cliente. A metfora apenas ajuda todos os envolvidos no projeto a entenderem os elementos bsicos e seus relacionamentos. (BECK, 2004, p.68). Projeto simples Segundo Beck (2004), o projeto deve ser projetado da maneira mais simples o possvel em qualquer momento. A complexidade desnecessria removida assim que for descoberta. O XP descarta projetos complexos. Entre dois projetos: um simples e outro mais complexo, mas que tenham basicamente a mesma funo, o mais simples sempre adotado. Testes Os programadores escrevem testes de unidade continuamente, os quais devem executar sem falhas para que o desenvolvimento prossiga. Os clientes escrevem testes de funcionalidade demonstrando que as funes esto terminadas. (BECK, 2004, p.66). Toda funo contida no sistema tem que passar por um teste. Segundo Beck (2004), qualquer aspecto/funo do programa que no tenha um teste automatizado, simplesmente no existe. O resultado de se testar continuamente que o sistema se torne cada vez mais confivel com o tempo.

26

Refatorao Os programadores reestruturam o sistema sem alterar seu comportamento a fim de remover duplicidade, melhorar a comunicao, simplificar e acrescentar flexibilidade. (BECK, 2004, p.66). Na refatorao, os desenvolvedores adicionam uma nova funo ao sistema de forma simples, no prejudicando a funcionalidade do sistema e tambm mantendo todos os testes em execuo aps esta adio. Programao em pares Todo cdigo de produo programado com duas pessoas olhando para uma mquina, com um teclado e um mouse (BECK, 2004, p.69). A programao em par a que mais se destaca dentre as 12 prticas da XP. Diante de cada computador existem sempre dois desenvolvedores que trabalham juntos para produzir um s cdigo. Esta prtica permite que o cdigo seja revisado continuamente na fase de construo. Propriedade coletiva No XP os cdigos no so individuais, ou seja, os cdigos no ficam de responsabilidade por apenas um desenvolvedor especfico da equipe. Segundo Beck (2004), qualquer um da equipe pode modificar qualquer cdigo, em qualquer lugar do sistema, a qualquer momento. O mesmo autor ainda afirma que, todos so responsveis pelo sistema inteiro. Integrao contnua No XP faz-se necessrio a integrao do cdigo para melhor sincronizao dos desenvolvedores. [...] o cdigo integrado e testado aps algumas horas no mximo um dia de desenvolvimento [...] (BECK, 2004, p.70). Na equipe XP, os pares trabalham de forma isolada, porm integram o que produzem com a verso mais recente do cdigo.

27

Segundo Beck (2004), Uma maneira simples de fazer isso ter uma mquina dedicada apenas integrao. [...] um par com o cdigo para ser integrado a ocupa, baixa a verso atual, baixa as modificaes (conferindo e resolvendo qualquer coliso) e executa os testes at que eles passem (100% certos). (BECK, 2004, p.70). Semana de 40 horas
Pessoas diferentes tm tolerncias diferentes para o trabalho. Uma pessoa capaz de agentar 35 horas de trabalho concentradas, outra, 45. Mas ningum consegue agentar 60 horas por semana durante muitas semanas, e ainda estar disposto, criativo, cuidadoso e confiante. No faa isso (BECK, 2004, p.71).

O XP usa a prtica de trabalho de 40 horas semanais para que a produo dos desenvolvedores da equipe seja mais evolutiva. Cliente presente O cliente tambm faz parte da equipe XP, pois ele que dir quais as funcionalidades que precisam ser implementadas. Beck (2004) afirma que um cliente real deve ficar com o time, estar disponvel para resolver questes, resolver disputas e definir prioridades de menor escala. Padres de codificao Voc ter todos esses programadores trabalhando em tantas partes diferentes do sistema, trocando de duplas vrias vezes por dia e refatorando os cdigos uns dos outros constantemente, voc no pode ter conjuntos diferentes de prticas de codificao. Com um pouco de prtica, ser impossvel dizer qual pessoa do time escreveu que cdigo (BECK, 2004, p.72). A equipe XP obtm um padro de codificar para que todos os desenvolvedores possam manipular qualquer parte do software de forma mais rpida.

Caractersticas da equipe XP
Uma equipe que utiliza o XP composta por pessoas que realizam o seguinte trabalho: Gerente de projeto, Coach, Analista de teste, Redator Tcnico e Desenvolvedor.

28

Gerente de projeto O gerente do projeto responsvel pelos assuntos administrativos do projeto. (TELES, 2006, p.29). Atividades que no esto relacionadas diretamente sobre o projeto e a administrao da relao com o cliente para assegurar que ele sempre estar ativo no projeto, so responsabilidades do gerente de projeto. Coach O coach o responsvel tcnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas prticas recomendadas pelo XP. (TELES, 2006, p.29). Analista de teste O analista de teste ajuda o cliente a escrever os testes. [...] quando estes testes no so automatizados, o analista de teste deve fazer com que eles sejam executados diversas vezes ao longo das iteraes do projeto. (TELES, 2006, p.29). Redator tcnico O redator tcnico quem faz a maior parte da documentao. Segundo Teles (2006), O redator tcnico ajuda a equipe de desenvolvimento a documentar o sistema. A sua presena permite que os desenvolvedores se concentrem, prioritariamente na implementao do software. Desenvolvedor O desenvolvedor a pessoa que analisa, projeta e codifica o sistema. (TELES, 2006, p.29). a pessoa que realmente constri o software.

29

As quatro fases
O XP adota uma abordagem orientada a objetos como seu padro de desenvolvimento predileto. Inclui um conjunto de regras e prticas que ocorrem no contexto de quatro atividades: Planejamento, Projeto, Codificao e Teste (FIGURA 2).

FIGURA 2: Fases do Processo XP Fonte: (PRESSMAN, 2006, p.64)

Planejamento As atividades de planejamento comeam com a criao de um conjunto de histrias (PRESSMAN, 2006), definindo caractersticas e funcionalidades requeridas para o software a ser construdos. As histrias so escritas pelos clientes e so anexados em um carto de indexao junto com um valor atribudo pelo prprio cliente, que vai determinar sua prioridade. De acordo com Pressman (2006), os membros da equipe XP avaliam cada histria e lhe atribuem um custo. Se a histria precisar mais do que trs semanas de desenvolvimento, pede-se ao cliente para dividir a histria em histrias menores e a atribuio de valor e custo ocorre novamente.

30

medida que o trabalho de desenvolvimento prossegue, o cliente pode adicionar histria, mudar o valor de uma histria, subdividir histrias e elimin-las (PRESSMAN, 2006). Projeto O projeto XP segue rigorosamente o princpio KIS (Keep It Simple mantenha a simplicidade) (PRESSMAN, 2006). O projeto simples sempre prefervel em relao a uma representao complexa. Nessa fase, o projeto fornece diretrizes de implementao para uma histria como ela est escrita, nada mais, nada menos. De acordo com Pressman (2006), o XP encoraja o uso de cartes CRC como mecanismo efetivo para raciocinar sobre o software no contexto orientado a objeto. Com o uso dos cartes, so identificadas e organizadas as classes orientadas a objeto que so relevantes para o incremento. O XP recomenda a criao imediata de um prottipo operacional quando um problema difcil encontrado. De acordo com o mesmo autor, o prottipo denominado solues de ponta. A inteno diminuir o risco quando a implementao verdadeira comea e validar as estimativas originais correspondentes histria que contm o problema de projeto. Codificao Pressman (2006) cita que depois que as histrias forem desenvolvidas e o trabalho preliminar de projeto for feito, a equipe no avance para o cdigo, mas, em vez disso, desenvolva uma srie de testes unitrios. Os testes unitrios exercitaro cada uma das histrias que devem ser includas na verso atual. De acordo com o mesmo autor, o XP recomenda que duas pessoas trabalhem juntas em uma estao de trabalho de computador para criar o cdigo correspondente a uma histria. A programao em pares um conceito-chave durante a atividade de codificao.

31

Teste Os testes unitrios que so criados devem ser implementados usando um arcabouo que lhes permita serem automatizados, conseqentemente, eles podem ser executados fcil e repetidamente (PRESSMAN, 2006). Conforme os testes unitrios vo sendo organizados em uma seqncia universal de testes, o teste de integrao e validao do sistema pode ocorrer diariamente. Isso fornece equipe XP uma indicao contnua de progresso e tambm pode levantar sinais de alerta se as coisas estiverem de deteriorando. Pressman (2006) diz que os testes de aceitao XP, tambm chamados de testes de cliente, so especificados pelo cliente e focalizam as caractersticas e funcionalidades do sistema global que so visveis e passveis de reviso do cliente.

32

2.2 PROCESSO UNIFICADO 2.2.1 Introduo

Segundo Scott (2003, p.19), o Processo Unificado encaixa-se na definio geral do processo, onde um conjunto de atividades executado para transformar um conjunto de requisitos do cliente em um sistema de software. Ele tambm uma estrutura genrica de processo onde se pode adicionar ou remover atividades de acordo com as necessidades do projeto. O Processo Unificado (Unified Process UP) surgiu como um processo popular para o desenvolvimento de software, visando construo de sistemas orientados a objetos. um processo iterativo e adaptativo de desenvolvimento, e vem ganhando cada vez mais adeptos devido maneira organizada e consistente que permite conduzir um projeto. Sua base esta nos componentes, o que significa o sistema ser construdo a partir de componentes de software interconectados via interfaces muito bem definidas. O Processo Unificado utiliza a Linguagem de Modelagem Unificada (Unified Modeling Language UML) no preparo de todos os artefatos do sistema. Para Pressman (2006), o UP um arcabouo de processo para a engenharia de software orientada a objetos utilizando a UML. A UML foi aprovada pelo OMG que se trata de um consrcio internacional de empresas que define e ratifica padres na rea de Orientao a Objetos desde novembro de 1997. No processo, foram baseados na UML, os diagramas de casos de uso e diagramas de classe.

2.2.2 Princpios fundamentais

O Processo Unificado possui trs princpios fundamentais: Dirigido por Casos de Uso Centrado na Arquitetura Iterativo Incremental

33

Deve-se, principalmente, a estes trs princpios, a consagrao e estabilizao deste Processo no mercado.

Dirigido por casos de uso

Para compreender o conceito Casos de Uso, importante conhecer o conceito Ator. Um ator pode ser entendido com uma pessoa ou uma entidade no-humana que interage com o sistema, mas est fora dele. O exemplo mais comum de ator o prprio usurio, porm, bancos de dados e outros sistemas tambm podem ser considerados atores. Um caso de uso uma seqncia de aes, executadas por um ou mais atores e pelo sistema, que produz resultados a fim de satisfazer metas e necessidades destes atores. Os casos de uso compem a fora condutora de todo o processo de desenvolvimento, desde a captao inicial de requisitos at a aceitao do cdigo-fonte, por vrias razes: Primeiramente, por serem expressos sob a perspectiva do usurio, em textos descritivos na lngua local do cliente. Os textos devem ser intuitivos e bvios para o leitor; Outro ponto fundamental que permitem uma compreenso direta dos requisitos do sistema. Os casos de uso no devem apresentar ambigidades, redundncias ou contradies, devem especificar um contrato a ser aceito e seguido pelos integrantes da equipe de desenvolvimento e pelos clientes, que resultaria no sistema a ser construdo; Permitem tambm, um alto grau de rastreamento de requisitos nos diversos modelos que so desenvolvidos posteriormente. Manter os casos de uso mo durante todo o processo importante por ser decisivo para a aceitao da soluo; Por fim, os casos de uso facilitam a distribuio de tarefas e a alocao de trabalho.

Centrado na arquitetura
A arquitetura uma viso de todos os modelos que juntos representam o sistema como um todo (SCOTT, 2003). O conceito de arquitetura de software engloba os aspectos estticos e dinmicos mais significantes do sistema que explicitam exatamente como cada Componente construdo e

34

como este se relaciona com os demais. [...] A arquitetura tambm se refere a questes como desempenho, escalabilidade, reuso e restries econmicas e tecnolgicas. (SCOTT, 2003, p.21). De qualquer modo, a arquitetura tambm influenciada por muitos outros fatores, como a plataforma na qual o software ser implantado, os blocos de construo reutilizveis, requisitos de desenvolvimento e requisitos no funcionais. A arquitetura uma viso do sistema como um todo, destacando suas caractersticas mais importantes, mas sem entrar em detalhes.
O que significante em um sistema depende do ponto de vista de cada desenvolvedor e que muitas vezes uma opinio sensata esta ligada experincia, o valor da arquitetura depende das pessoas que esto ligadas ao desenvolvimento do sistema (JACOBSON, 1999, p.46).

Altos graus de manutenibilidade, flexibilidade e expansibilidade, tornando-se um fator fundamental aps a adoo da internet como um principal meio de comunicao, para que a equipe de desenvolvimento possa atender as demandas que surgem em um intervalo de tempo cada vez menor. Outra idia implcita, mas central para a UP, o uso de tecnologias orientadas a objetos, incluindo a A/POO e programao orientadas a objetos (LARMAN, 2004, p.42). A descrio da arquitetura iniciada cedo com a equipe de projeto que posteriormente a expande e refina durante praticamente todas as atividades de projeto (SCOTT, 2003, p.22), assim a arquitetura deve ser projetada a ponto que o sistema evolua, no apenas durante o seu desenvolvimento, mas tambm atravs de geraes futuras. Para alcanar este objetivo, os arquitetos devem trabalhar com as funes chaves de sistema. Estes so apenas 5% a 10 % do total de casos de uso, porm, os mais significantes, aqueles que constituem o ncleo de funes do sistema. Entendendo a viso global A arquitetura tem como propsito facilitar o entendimento da arquitetura em construo.

35

[...] a modelagem rigorosa e a legibilidade dos diagramas UML, associadas ao texto de apoio, contribuiro para tornar a descrio da arquitetura o eixo central para um melhor entendimento da viso global do novo sistema. (SCOTT, 2003, p.22). Organizando o esforo de desenvolvimento
Uma arquitetura sadia define, explicitamente, pores discretas do sistema, bem como as interfaces entre as vrias partes deste. Faz uso efetivo, tambm, de um ou mais padres arquitetnicos, os quais ajudam a dar forma ao esforo de desenvolvimento em vrios nveis. [...] (SCOTT, 2003, p.22).

Facilitando as possibilidades do reuso No desenvolvimento baseado na utilizao de componentes, um dos princpios fundamentais a idia de reutilizao destes componentes, com um mnimo relativo de customizao.
[...] Uma arquitetura de software bem construda oferece "estrutura" (framework) slida na quais os componentes podem residir e trabalhar uns com os outros de modo elegante, ao mesmo tempo em que facilita s equipes que esto trabalhando na construo de outros sistemas identificar oportunidades para possvel reuso de qualquer um dos componentes ou de todos. [...] (SCOTT, 2003, p.23).

Ainda tendo em vista o grau de modularidade, uma arquitetura deve ser elaborada considerando diversos nveis de abstrao. Quanto menor a abstrao de um componente, maior ser seu potencial de reuso. Esta caracterstica fundamental pode ser alcanada atravs da utilizao de frameworks, um conjunto de classes abstratas e concretas com alto grau de especializao. [...] quanto menos tempo for necessrio construo de novos componentes, mais tempo haver para entender os problemas dos clientes e modelar as solues. (SCOTT, 2003, p.23). Facilitando e evoluo do sistema Na construo de um software gasto um determinando tempo que conseqentemente menor do que o tempo necessrio para manter e expandir o sistema. Em tempos que a tecnologia evolui rapidamente e os tempos de negocio mudam com uma grande freqncia, no h duvidas de que um sistema estar sujeito a mudanas evolucionrias de uma enorme magnitude.

36

No entanto, ter uma arquitetura slida oferece um conjunto de pontos de referncia essenciais sobre os quais o trabalho de desenvolvimento futuro poder se apoiar. Uma arquitetura construda de modo que as mudanas em uma parte do sistema quase nunca provoquem efeitos adversos sobre outras partes, tambm contribuir para a evoluo efetiva e eficiente do sistema. (SCOTT, 2003, p.23). Dirigindo os casos de uso A relao existente entre casos de uso e a arquitetura que os casos de uso esto ligados a funcionalidade de um sistema e a arquitetura, por sua vez est ligada forma deste. [...] A idia bsica, ento, focar aqueles casos de uso que agregaro valor arquitetura, o que por sua vez ajudar a dar forma ao contedo daqueles casos de uso e natureza do trabalho envolvido no desenvolvimento do sistema a partir deles. (SCOTT, 2003, p.23). A arquitetura fornece um ambiente para a realizao de todos os requisitos dos casos de uso. Os casos de uso devem ser desenvolvidos de acordo com a arquitetura, com isso funcionalidade e forma devem estar balanceadas para se alcanar um produto final de qualidade.

Iterativo e incremental
Uma das vrias prticas promovidas pelo UP que mais se destaca, o desenvolvimento iterativo e incremental. O desenvolvimento organizado em uma srie de iteraes. Cada iterao considerada um mini-projeto, que possui suas prprias atividades de anlise de requisitos, projeto, implementao e teste. O objetivo da iterao oferecer uma melhora incremental ao sistema. De acordo com Larman (2004), o ciclo de vida iterativo baseado em refinamentos e incrementos de um sistema por meio de mltimplas iteraes, com realimentao (feedback) e adaptao cclicas como principais propulsores para convergir para um sistema adequado.

37

A razo pela qual este princpio conhecido como iterativo e incremental, est no crescimento incremental ao longo do tempo, iterao por iterao. Benefcios um progresso lgico para que uma arquitetura robusta seja alcanada. Durante as iteraes iniciais, uma arquitetura candidata proposta. Sua evoluo ser uma fundao slida para o restante do sistema. Em contraste com metodologias que seguem o paradigma do Processo Cascata, onde todos os requisitos so levantados no inicio e nunca mais revisados, o UP prev a negociao progressiva de requisitos, priorizando aqueles que representam riscos mais altos ao projeto. Possibilita maior flexibilidade para que mudanas ocorram no plano de atuao da equipe de desenvolvimento. Uma avaliao ao final de uma iterao permite isolar um eventual problema identificado e lidar com ele em uma escalada reduzida, sem propagar seus efeitos. Caso o incremento de uma iterao seja um componente ou mdulo, este integrado aos demais existentes. Uma integrao muitas vezes representa a conquista de mais um requisito. A evoluo do trabalho torna-se mais evidente aos interessados. Por fim, a natureza iterativa permite que novos integrantes da equipe de desenvolvimento iniciem suas atividades sem que sejam submetidos a treinamentos extensos que cubram todo o projeto.

2.2.3 As quatro fases

O UP consiste em uma srie de ciclos durante a vida de um sistema, cada ciclo concludo com uma verso do sistema pronta para distribuio e subdividido em quatro fases: Concepo, Elaborao, Construo e Transio (FIGURA 3).

38

FIGURA 3: Fases do Processo Unificado Fonte: (PRESSMAN, 2006, p.52)

Concepo
O principal objetivo da fase de concepo estabelecer a viabilidade do sistema proposto (SCOTT, 2003, p.27), definindo como o sistema ser utilizado por cada usurio, atravs da criao de casos de uso mais relevantes. No entanto a partir deste escopo ser definido o que o projeto dever cobrir como prazos, custos, retornos de investimentos, etc. Segundo Scott (2003, p.27), o esforo empenhado na fase de concepo poder evitar o fracasso do projeto atravs da identificao previa de riscos. A causa do fracasso de muitos projetos o fato de riscos crticos serem encontrados tarde demais, geralmente ocorre durante a fase de integrao, etapa de testes, quando no se h mais tempo nem oramento para revises. [...] O principal marco associado com a fase de concepo chamado objetivos do ciclo de vida. (SCOTT, 2003, p.27), na qual devem ser analisados para decidir se o desenvolvimento deve prosseguir em plena escala.

39

Elaborao
O principal objetivo da base de elaborao estabelecer a capacidade para construo do novo sistema, dadas as restries financeiras e de cronograma [...] (SCOTT, 2003, p.28), ento, a maioria dos requisitos remanescentes so capturados e transformados em casos de uso. Para alcanar seu objetivo, o sistema deve ser estudado mais amplamente do que profundamente, ou seja, segundo Scott (2003), nesta fase deve ser concebida uma viso abrangente do sistema. Isto envolve o estudo da maior parte dos casos de uso envolvidos, cerca de 80%. No final desta fase, estaro definidos o escopo e os objetivos detalhados do sistema, a escolha da arquitetura e soluo para os principais riscos. Com isso, as informaes necessrias para a fase de construo estaro disponveis.

Construo
O principal objetivo da fase de construo construir um sistema capaz de operar bem em ambientes beta de clientes (SCOTT, 2003, p.28). O trabalho inicia com base na arquitetura executvel, produzida durante a fase de elaborao e prossegue atravs de iteraes e incrementos, com objetivo de desenvolver um produto pronto para operaes iniciais no ambiente de usurio, ou seja, a verso beta. Durante a fase de construo so detalhados os casos de usos remanescentes e a descrio arquitetural modificada quando necessrio. Esta fase se concentra em corrigir defeitos e modificar o sistema para corrigir problemas no identificados previamente. (SCOTT, 2003, p.28). Enquanto as fases de concepo e elaborao esto ligadas diretamente modelagem do sistema, a fase de construo caracterizada pelo desenvolvimento, isto , a construo de um sistema ou produto dentro dos parmetros de custos e prazos.

40

Transio
O principal objetivo da fase de transio entregar o sistema completamente funcional aos clientes (SCOTT, 2003, p.28), estabelecendo o produto no ambiente operacional do cliente. A fase de transio procura por deficincias mnimas que passaram despercebidas pela fase de construo que possam ser corrigidas dentro da arquitetura existente, outra tarefa da fase de transio a disponibilidade de treinamentos que possibilitaro o cliente utilizar o produto de forma eficiente. O principal marco associado fase de transio a chamada liberao do produto. (SCOTT, 2003, p.29).

41

3 MATERIAL E MTODOS
Para demonstrar as diferenas entre o uso dos processos XP e UP, o presente trabalho utilizar as ferramentas Microsoft Visual Studio 2005 e 2008, banco de dados Microsoft SQL Server 2005 e Microsoft Office Access 2003, linguagem de programao C# e VB.NET e Adobe Fireworks CS3.

3.1 Microsoft Visual Studio

O Microsoft Visual Studio um ambiente de desenvolvimento abrangente, elaborado para desenvolvedores individuais construrem aplicaes com multicamadas de alto desempenho. Atravs dele, pode-se tirar proveito de um ambiente muito produtivo e criar uma grande variedade de solues baseadas no Windows, na Web, em Dispositivos Mveis e no Office.

3.2 Microsoft SQL Server

uma ferramenta de gerenciamento de dados poderosa e confivel que fornece recursos robustos, proteo de dados e desempenho para clientes de aplicativos incorporados, aplicativos Web e armazenamentos de dados locais.

3.3 Microsoft Office Access

O Microsoft Office Access, tambm conhecido por MSAccess, um sistema de gerenciamento de banco de dados da Microsoft, includo no pacote do Microsoft Office. Ele permite o desenvolvimento rpido de aplicaes que envolvem tanto a modelagem e estrutura de dados como tambm a interface a ser utilizada pelos usurios.

3.4 Linguagem C#
C# (CSharp) uma linguagem de programao orientada a objetos criada pela Microsoft, que faz parte da sua plataforma .NET. A companhia baseou C# na linguagem C++ e Java.

42

3.5 Linguagem VB.NET

VB.NET (Visual Basic .NET) uma linguagem de programao totalmente orientada a objetos e com suporte total a UML, criada pela Microsoft e distribuda com o Visual Studio.

3.6 Fireworks
O Fireworks um editor de imagens desenvolvido pela Macromedia, posteriormente adquirido pela Adobe. Suas funcionalidades focam a publicao grfica na Internet, por isso inclui suporte a GIF animado, PNG e imagens fatiadas, alm de possuir tima compresso de imagens. A partir da verso MX, ganhou integrao com outros produtos da mesma linha, Dreamweaver, Flash e Freehand.

3.7 Etapas
As etapas (mtodos) que sero utilizados para o desenvolvimento da aplicao sero: Etapa 1: Levantamento bibliogrfico e estudo do assunto em foco. Etapa 2: Definies do aplicativo a ser desenvolvido. Etapa 3: Desenvolvimento do aplicativo usando as tecnologias especificadas. Etapa 4: Anlise completa do aplicativo desenvolvido. Etapa 5: Concluso do trabalho e consideraes finais.

43

4 DESENVOLVIMENTO DO SISTEMA
Neste captulo ser descrito as fases de desenvolvimento de ambos os processos. Para melhor entendimento posteriormente, sero encaixadas as fases de cada processo, nas atividades genricas de desenvolvimento que so: Comunicao, Planejamento, Modelagem, Construo e Implantao (FIGURA 4).
Programao Extrema (XP)

PLANEJAMENTO

PROJETO

CODIFICAO

TESTE

COMUNICAO

PLANEJAMENTO

MODELAGEM

CONSTRUO

IMPLANTAO

CONCEPO

ELABORAO

CONSTRUO

TRANSIO

Processo Unificado (UP)

FIGURA 4: Fases dos Processos XP e UP em relao s atividades genricas de desenvolvimento.

4.1 Descrio geral do sistema

A aplicao desenvolvida para a loja Charme Boutique, nesta primeira verso, tem a finalidade de mostrar as informaes sobre as roupas e acessrios para os clientes, atravs da Internet. Espera-se que, com a utilizao deste, as visitas a loja possa ganhar um aumento significativo. O acesso a aplicao pode ser realizado por qualquer visitante, havendo restries somente para a rea administrativa, onde o administrador efetuar o Login para operar esta pgina. O administrador poder realizar vrias atividades comuns e administrativas, como por exemplo: adicionar, excluir e editar roupas e/ou acessrios.

44

O site contm uma interface grfica (layout) simples e de fcil acesso, sendo separada a parte de folhas de estilo, o CSS, da linguagem HTML.

4.2 Desenvolvimento utilizando o XP

Todo o desenvolvimento da aplicao tomou como base o contedo terico apresentado no Captulo 2.1.2 deste trabalho. Foram aplicados todos os princpios da XP, bem como suas prticas. Grande parte do tempo do projeto foi destinada fase de planejamento de requisitos, j que a comunicao com o cliente um pouco complexa. Mas, foi um tempo til para poder entender todo o escopo do projeto. Uma vez bem compreendido por parte dos programadores e cliente, iniciou-se a codificao. A simplicidade das prticas de anlise da XP foram com certeza os fatores responsveis pela qualidade e agilidade com que o projeto foi desenvolvido. Os testes por sua vez, so executados durante todo o projeto, desde a concepo at a implantao e no em etapas distintas. A prtica do desenvolvimento em pares acelerou o processo de codificao, extinguindo dvidas tcnicas rapidamente. O ambiente todo explicativo favoreceu a rpida sintonia sobre o andamento do projeto e as prioridades dirias do desenvolvimento. Foi utilizado para tal, um cronograma, estimativas nas quais foi baseado o projeto, um quadro metlico para fixao de ms, onde foram fixadas as histrias de usurio e alguns modelos do projeto, rabiscados em folha de papel, isso demonstra que ferramentas simples realmente funcionam.

4.2.1 Comunicao Fase de Planejamento

A comunicao comeou por meio de histrias. As histrias foram escritas pelo cliente com o auxlio da equipe XP, em um carto. Cada carto possua uma histria e nela era depositada toda funcionalidade do sistema (FIGURA 5). O cliente precisa respeitar o espao do carto para que torne mais simples o trabalho dos desenvolvedores.

45

FIGURA 5: Histrias XP escritas pelo Cliente.

Com a escrita das histrias, o cliente estimulado a pensar na melhor funcionalidade do sistema, conseqentemente, um melhor levantamento de requisitos. Restante das histrias escritas se encontra no Apndice A.

4.2.2 Planejamento Fase de Planejamento

As histrias escritas foram estimadas em dias, e para facilitar a comunicao, a equipe de desenvolvimento usou pontos, marcados no carto, para estimar os dias trabalhados. No planejamento foi visto um cronograma para guiar a equipe no desenvolvimento do sistema e tambm uma estimativa para codificar e testar o projeto (FIGURA 6).
Agosto Setembro Outubro Novembro Dezembro

1
Planejamento Projeto Codificao Teste

FIGURA 6: Cronograma

46

4.2.3 Modelagem Fase de Projeto

Para modelagem de dados foi criado um diagrama do modelo de entidade e relacionamento, devido a sua simplicidade e eficincia (FIGURA 7). Com isso pode-se organizar os dados e reduzir a complexidade. As entidades estabelecidas foram: Roupas e Acessrios. Os atributos de cada entidade tambm foram definidos, e as tabelas, ento, foram normalizadas pelas trs formas normais.
CodR Descr Cor Img Marca Preco Tamanho Nome Preco CodA Descr Img Marca

ROUPAS

ACESSRIOS

FIGURA 7: Modelo ER

O dicionrio de dados foi criado para demonstrar a consistncia entre os dados nas diferentes tabelas. Com isso, buscou-se padronizao, organizao e estruturao em relao s definies do sistema. Essas definies indicam como os elementos de dados foram armazenados. Veja os detalhes no Apndice B. Foi criado tambm um diagrama de classes para usar no cdigo do projeto. Ver detalhes Apndice C.

47

4.2.4 Construo Fase de Codificao

O desenvolvimento com o XP tem como objetivo gerar valores para os clientes ao longo de todo o projeto. Para isso foi feito uma entrega incremental, conhecido tambm por releases. O release consiste na diviso do projeto em partes. Neste trabalho, o projeto foi dividido em oito partes, onde cada parte corresponde a uma semana, como mostra a Figura 8.

Releases

R1

R2

R3

R4

1 Semana

R5

R6

R7

R8

FIGURA 8: Projeto dividido em Releases

Uma iterao basicamente um pequeno espao para a implementao de um conjunto de histrias do usurio. No trabalho, as iteraes foram divididas em dias. A principal diferena entre releases e iteraes que iterao est contida em cada release. O cliente tem opo de mudar cada release, mas no tem direito de mudar a iterao, j que depois que definida a iterao, os requisitos j estariam bem entendidos e os processos de desenvolvimento comeariam.

48

O encerramento de cada iterao foi mostrado para o cliente. Com isso, o cliente fez os testes de aceitao que foram escritos em cada iterao. O release encerrado depois da ltima iterao realizada pelo cliente. As distribuies de cada release ficaram desta maneira: R1: Foi feito o cadastro de roupas, R2: Alterao das roupas, R3: Excluso das roupas, R4: Consulta das roupas, R5: Cadastro de acessrios, R6: Alterao dos acessrios, R7: Excluso dos acessrios, R8: Consulta dos acessrios. A parte de codificao do projeto foi realizada em pares. Em um projeto XP, os desenvolvedores sempre utilizam esta tcnica de programao. A programao em par uma tcnica na qual dois programadores trabalham em um mesmo problema, no mesmo computador. Enquanto um membro assume o teclado e codifica, o outro acompanha, ajudando na codificao, correo entre outros. Foi visto que com a programao em pares diminui os erros j que programando com dois programadores fica mais difcil de passar alguma coisa despercebida, foi comprovado tambm que programar em par teve um grande ganho no tempo, porque na hora que aparece algum problema o colega consegue lhe ajudar na maioria das vezes. A programao em pares muito til para se conseguir um software de qualidade podendo ser usado no s no XP, mas tambm em outros processos. Dentro dos releases foram feitas as iteraes e foram estabelecidas assim: Iterao do R1 cadastro de roupas: O Banco de dados das roupas teve os seguintes atributos (cdigo, marca, cor, preo, descrio, imagem original, imagem, imagem pequena, tamanho da roupa). Feito a escolha dos atributos foi feito a stored procedure para a insero de dados no banco e os testes. Depois disto, foram submetidos ao cliente, que verificou se a operao s quando os atributos tiveram o aval do cliente passou-se para parte de codificao. Para se criar o cadastro, foi desenvolvido uma e dentro desta foi codificado o cadastro, utilizando a programao em pares. Depois disso voltou-se novamente para o cliente. Quando o cadastro atingiu o gosto do cliente, foram feitos os testes e passou-se para o prximo release.

49

FIGURA 9: Cadastro de Roupas

Iterao do R2 consulta das roupas: Primeiramente foi criada uma stored procedure para a consulta de dados no banco juntamente com os testes necessrios para a integridade dos dados. Depois disto foi levado para o cliente verificar se ficou ao seu critrio. S quando os atributos tiveram o aval do cliente passou-se para parte de codificao. Para se criar a consulta, foi utilizada prpria pgina de cadastro. Para a codificao desta, utilizou-se a programao em pares. Depois disso voltou-se novamente para o cliente. Quando o cadastro atingiu o gosto do cliente foram feitos os testes e passou-se para o prximo release.

50

FIGURA 10: Listagem das Roupas

FIGURA 11: Detalhes da Roupa

Iterao do R3 excluso das roupas: Foi criado a stored procedure para a excluso dos dados no banco juntamente com os testes. Depois disto foi levado para o cliente verificar

51

se ficou ao critrio s quando os atributos tiveram o aval do cliente passou-se para parte de codificao. Para se criar a excluso das roupas, foi utilizada prpria pgina de cadastro, para codificar a pgina utilizou-se de programao em pares. Depois disso voltou-se novamente para o cliente quando o cadastro atingiu o gosto do cliente foram feitos os testes e passou-se para o prximo release.

FIGURA 12: Adicionado a excluso de Roupas

Iterao do R4 alterao das roupas: Foi criada uma stored procedure para a alterao de dados no banco e seus respectivos testes. Depois disto foi levado para o cliente verificar se ficou ao critrio. S quando os atributos tiveram o aval do cliente passou-se para parte de codificao. Para se criar a alterao, foi utilizada prpria pgina de cadastro. Para a codificao desta, utilizou a programao em pares. Depois disso volta-se novamente para o cliente quando o cadastro atingiu o gosto do cliente foram feitos os testes e passou-se para o prximo release.

52

FIGURA 13: Adicionado a edio de Roupas

As iteraes dos acessrios seguem o mesmo modelo feito com as iteraes das roupas, sendo desnecessrio descrev-las aqui novamente em detalhes. As histrias foram priorizadas pelo cliente e, conseqentemente, as ordens do que seria feito.

4.2.5 Implantao
A implantao do sistema foi realizada durante a fase de construo, onde a mesma entregue para o cliente durante o trmino de cada iterao no final do release. Neste, o cliente faz todos os testes de aceitao. As demais pginas que compe o site podem ser visualizadas no Apndice D.

Fase de Teste
Os testes foram realizados durante todo o projeto sendo, estes, testados no final de cada iterao.

53

4.3 Desenvolvimento utilizando o UP

Todo o desenvolvimento da aplicao tomou como base o contedo terico apresentado no Captulo 2.2 deste trabalho. Foram aplicados os principais princpios do UP, bem como suas prticas. Grande parte do tempo do projeto foi destinada fase de concepo e elaborao, aonde se pode entender melhor o escopo do sistema. A comunicao com o cliente torna-se para o UP um fator muito importante no entendimento do sistema, que definido com a ajuda de casos de uso.

4.3.1 Comunicao Fase de Concepo

Na fase de concepo, o principal foco foi destinado ao entendimento dos requisitos e a determinao do escopo do projeto, onde foi realizado o planejamento e o levantamento dos mesmos. Definiu-se, ento, quais so os principais requisitos de alto nvel (FIGURA 14). Muitas necessidades dos atores podem ser reconhecidas atravs dos mesmos, que detalharam as especificaes, onde o cliente descreveu todas as funcionalidades ou servios que se espera do sistema.

Requisitos Principais Apresentao da empresa Informaes sobre a empresa Cadastro de produtos (roupas/assessrios) Demonstrao dos produtos por categorias Informaes detalhadas sobre os produtos Informaes para contato FIGURA 14: Requisitos Principais

54

Com a declarao do escopo, definido o que est dentro e o que est fora do projeto, de maneira clara e sem ambigidades, ou seja, o que exatamente o sistema far e o que ele no far (FIGURA 15).
ESCOPO Apresentao da Empresa Cadastro de Clientes Informaes sobre a Empresa Cadastro de Produtos Vendas On-line de Produtos Demonstrao dos produtos por categorias Informaes detalhadas sobre os Produtos Controle de Estoque Informaes para Contato

FIGURA 15: Escopo do Projeto

4.3.2 Planejamento Fase de Concepo

Aps identificar os atores e algumas de suas funes bsicas com base nos requisitos, criaram-se os casos de uso preliminares que ainda vo ser alterados algumas vezes at serem estabilizados e totalmente definidos, mas serviro para iniciar o direcionamento do desenvolvimento (FIGURA 16). A melhor forma a utilizar, para identificar os casos de uso, considerar o que cada ator exigir do sistema, baseado em suas necessidades. Os atores so: Visitante e Administrador.

55

Visualizar Produtos

Gerenciar Produtos Visitante Administrador

FIGURA 16: Casos de Uso preliminares

Para estes casos de uso, a necessidade do ator Visitante visualizar os produtos e seus detalhes. J o administrador, gerenciar estes produtos, adicionando, editando ou excluindo os mesmos. O prximo passo foi definir os requisitos no-funcionais que descrevem como o sistema deve ser feito atravs da anlise de alguns padres como a portabilidade, desempenho, segurana, dentre outros (FIGURA 17). Definiu-se tambm, os atributos como restries ou a qualidade do sistema, lembrando que a qualidade afeta diretamente a satisfao do cliente.

Requisitos No-Funcionais Portabilidade Site implementado nas ferramentas Microsoft Visual Studio 2008 utilizando a linguagem de programao VB.NET. Segurana Somente pessoas cadastradas como administrador do sistema poder realizar todas as tarefas administrativas do site. Realizar controle de acesso via autenticao. A base de dados encontra-se protegida, para acesso apenas dos desenvolvedores. Desempenho O tempo de resposta do site no deve exceder 30 segundos. Ao efetuar algum tipo de cadastro, o mesmo no dever exceder 60 segundos.

56

Maturidade O site dever funcionar vinte e quatro horas por dia, sete dias por semana. Possuir Sistema de Tolerncia a Falhas/Recuperao de Falhas, sendo enviadas mensagens de ocorrncias aos desenvolvedores. Facilidade de Entendimento Possuir tutorial com informaes de detalhes para a rea administrativa do site. Realizar treinamentos com o cliente. Operabilidade O site dever ser visualizado nos browsers Internet Explorer verso 7 ou superior e Mozilla Firefox verso 2 ou superior. Comportamento de Recursos A aplicao ir rodar na Internet com no mximo um total de 50 registros dirios com um crescimento mensal em torno de 10%.

FIGURA 17: Requisitos No-Funcionais

Com a definio do cronograma foi possvel obter um melhor nvel de gerenciamento, onde so controladas todas as atividades a serem executadas durante o perodo estimado e podem-se levantar os custos do projeto. A utilizao do cronograma foi uma excelente ferramenta para controle do tempo de trabalho e do ritmo de produo (FIGURA 18).
Agosto Setembro Outubro Novembro Dezembro

1
Concepo Elaborao Construo Transio

FIGURA 18: Cronograma da Iterao 1

57

Fase de Elaborao
Na fase de elaborao obteve-se uma viso mais abrangente do sistema, onde os requisitos so refinados, os casos de uso so expandidos e uma base arquitetnica slida estabelecida para o desenvolvimento futuro. Com os requisitos refinados, estabeleceu-se uma melhor compreenso dos casos de uso mais crticos, possibilitando entender os objetivos mais detalhados do sistema, inclusive a escolha da arquitetura e a soluo para os principais riscos encontrados. Esta fase forneceu uma base estvel para o esforo da fase de construo. Primeiramente foram refinados os requisitos, detalhando todas as suas

funcionalidades (FIGURA 19).

Requisitos Refinados Apresentao da empresa Ser exibido na pgina inicial o principal foco da empresa com imagens e frases Informaes sobre a empresa Pgina Sobre a Charme ter como contedo, toda a histria da empresa. Cadastro de Roupas Permitir adicionar, alterar ou excluir roupas em uma rea restrita ao administrador do site, informando suas caractersticas principais. Cadastro de Acessrios Permitir adicionar, alterar ou excluir acessrios em uma rea restrita ao administrador do site, informando suas caractersticas principais. Demonstrao das roupas por categorias Uma pgina especfica com nome de Roupas, permitir ao visitante visualizar todas as roupas, ou por categorias. Demonstrao dos acessrios por categorias Uma pgina especfica com nome de Acessrios, permitir ao visitante visualizar todos os acessrios, ou por categorias.

58

Informaes detalhadas sobre as roupas Cada roupa ter suas informaes detalhas ao clicar sobre a mesma. Informaes detalhadas sobre os acessrios Cada acessrio ter suas informaes detalhas ao clicar sobre o mesmo. Informaes para contato Uma pgina de contato ir conter informaes para contato como: Endereo, Telefone, Email, etc. Alm de ser possvel o visitante enviar uma mensagem diretamente pela pgina que ser recebida pelo administrador em seu e-mail.

FIGURA 19: Requisitos Refinados

Definir os riscos em um projeto de software uma medida que foi tomada para um futuro evento negativo que poder afet-lo. Qualquer ameaa no andamento do projeto definido como um risco. Os riscos encontrados foram gerenciados, avaliados, controlados e solucionados para que no comprometessem o projeto (FIGURA 20).
Riscos Risco de Projeto A falta de experincia dos desenvolvedores com algumas tecnologias. Risco Especfico WebDesign para criao de imagens do site. Risco Tcnico ou Arquitetural A hospedagem para o banco de dados criado em SQL Server 2005 tem um custo desnecessrio ao cliente visto que a pgina ser somente para demonstrao de produtos, sem maiores transaes. Site destinado a browsers como Internet Explorer verso 7 ou superior e Mozilla Firefox verso 2 ou superior. A Taxa de crescimento anual em registros do banco de dados. Suporte ao projeto aps sua implantao. Os requisitos do projeto so instveis. Data de entrega muito ajustada.

59

Dificuldade de comunicao devido distribuio geogrfica da equipe e disponibilidade de horrios. Registro de Ocorrncias Mudana no escopo do projeto. Uma Pergunta foi levantada e precisa ser resolvida. Outras ocorrncias. Plano de Contingncia Cpias de segurana disponveis. Todas as informaes esto devidamente documentadas. Conhecimento adquirido atravs de cursos a equipe. Criao de tutoriais sobre a utilizao do sistema. Suporte ao projeto aps sua implantao.

FIGURA 20: Riscos

Definiu-se, tambm, para os ricos, sua probabilidade, impacto e resposta como mostrado na Figura 21. O restante dos riscos e seus detalhes esto no Apndice E.
Evento de Risco A hospedagem para o banco de dados criado em SQL Server 2005 ter um custo desnecessrio ao cliente visto que a pgina ser somente para demonstrao de produtos, sem maiores transaes. Probabilidade do Risco Mdia Necessidade de outra ferramenta para implementao do banco de dados. Impacto Resposta Mdio Gerao de custos desnecessrios ao cliente Utilizao do sistema relacional para administrao de banco de dados Microsoft Access, por tratar-se de uma ferramenta de fcil manuseio e hospedagem.

FIGURA 21: Detalhes do Risco

60

4.3.3 Modelagem Fase de Elaborao

Foram desenvolvidos os primeiros casos de uso expandidos, que fizeram um detalhamento bem completo dos casos de uso preliminares encontrados na fase de concepo (FIGURA 22).

Visualizar Roupas

<<extend>>

Visualizar Detalhes de uma Roupa

Visitante

Visualizar Acessrios

<<extend>>

Visualizar Detalhes de um Acessrio

Enviar Dvidas

Editar Roupas

<<extend>>

Cadastrar Roupas Excluir Roupas

<<extend>> <<include>>

Realizar Login

Administrador
<<include>>

Editar Acessrios

<<extend>>

Cadastrar Acessrios Excluir Acessrios

<<extend>>

FIGURA 22: Casos de Uso Expandidos

61

Foi criada uma arquitetura base que contm todos os elementos significativos do projeto, mostrando a descrio da arquitetura como um todo (FIGURA 23).

Logotipo da Empresa

Menu Principal do Site

Contedo da Pgina

Rodap

FIGURA 23: Estrutura geral do Site

62

A Figura 24 mostra a estrutura da pgina principal, definida.

Logotipo da Empresa

Menu Principal do Site

Produtos em Promoo ou Destaque Apresentao da Empresa

Rodap com informaes

FIGURA 24: Estrutura da pgina Principal

63

Definiu-se, tambm, a estrutura das demais pginas (FIGURA 25).

Logotipo da Empresa Titulo da Pgina

Menu Principal do Site

Sub-menu. Pode ou no conter.

Produtos ou Textos da pagina especfica.

Rodap com informaes

Navegadores da Pgina. Pode ou no conter.

FIGURA 25: Demais Pginas do Site

A modelagem de dados foi a primeira etapa do projeto que envolveu o banco de dados, onde pode-se ter organizao sobre os dados e uma reduo na complexidade a ponto que se pudesse compreender e manipular os dados, sendo de vital importncia para o bom resultado. As entidades estabelecidas foram: Usuarios, Produtos, Generos, Marcas e Categorias. Os atributos de cada entidade tambm foram definidos e as tabelas, ento, foram normalizadas pelas trs formas normais.

64

Para que se tivesse uma viso mais detalhada, foi criado o diagrama do modelo de entidade e relacionamento devido a sua simplicidade e eficincia (FIGURA 26).
CodigoProduto Descricao DescricaoDetalhada CodigoGenero Nome CodigoGenero CodigoMarca CodigoCategoria

GENEROS

Situacao

PRODUTOS

MARCAS
Situacao Nome

CATEGORIAS
Situacao Descricao CodigoCategoria

USUARIOS

CodigoMarca

Situacao Tipo Email Senha Login Nome CodigoUsuario

FIGURA 26: Modelo ER

O dicionrio de dados tambm foi criado e um dos benefcios encontrados atravs dele, foi a consistncia entre itens de dados dispostos em diferentes tabelas, padronizando, estruturando e envolvendo as definies adotadas pela empresa. As definies realizadas no dicionrio de dados indicaram como os elementos de dados foram armazenados em uma estrutura de computador de acordo com seu tipo. A Figura 27 ilustra o dicionrio de dados de uma das tabelas, o restante das tabelas pode ser visualizado no Apndice F.
Nome da Tabela: Produtos Campos Nome CodigoProduto Descricao Tipo Num Char Tamanho 50 Chave Primria Comentrios Cdigo do Produto Descrio do Produto

65

DescricaoDetalhada CodigoGenero CodigoMarca CodigoCategoria Situacao

Char Char Num Num Char

200 7 Relacionamentos

Estrangeira Estrangeira -

Descrio detalhada do Produto Gnero do Produto Cdigo da Marca Cdigo da Categoria Situao do Produto

Produtos oo - 1 Marcas Produtos oo - 1 Categorias FIGURA 27: Dicionrio de Dados Tabela Produtos

4.3.4 Construo Fase de Construo

Na fase de construo o sistema foi efetivamente desenvolvido com plenas condies de ser operado, mesmo que em ambiente de teste, pelos clientes. Nesta fase que foi realizado o desenvolvimento iterativo e incremental do processo. Para criao do banco de dados, foi utilizado o Sistema de Gesto de Bases de Dados (SGBD) Microsoft Access, por se tratar de uma adequada ferramenta de banco de dados para ser utilizado em pequenos projetos que no possuem maiores transaes (FIGURA 28).

66

FIGURA 28: Banco de Dados Microsoft Access

O processo iniciou-se com a arquitetura base definida e liberou-se em ambiente beta a estrutura para o cliente realizar a verificao da mesma (FIGURA 29).

67

FIGURA 29: Estrutura criada e liberada para o cliente

Com a estrutura perfeita, foi iniciada a criao das pginas da rea administrativa que acessada para o gerenciamento de todo contedo do site, possibilitando cadastrar, editar ou excluir os produtos, categorias ou marcas (FIGURA 30).

68

FIGURA 30: Pgina inicial do Administrador

Apenas o administrador do sistema poder acessar esta rea, que por medidas de segurana, protegida. O acesso a ela dever ser realizado informando o Login e Senha (FIGURA 31).

69

FIGURA 31: Login para a rea administrativa

4.3.5 Implantao Fase de Construo

Alguns tutoriais sobre a rea administrativa do site foram criados, para auxiliar o administrador a operar bem as pginas. Neles, contm imagens que ensinam passo a passo, didaticamente, todo o funcionamento do site. O documento de ajuda possui algumas caractersticas como: simplicidade, eficincia e clareza.

Fase de Transio
A fase de Transio teve como objetivo, estabelecer o software no ambiente do cliente, com a disponibilizao de uma verso operacional da aplicao.

70

A partir da avaliao realizada pelo cliente, pode-se analisar se o sistema realmente cumpriu com as necessidades do usurio, quais falhas foram apresentadas, e quais dificuldades encontradas na sua utilizao. Concluiu-se que, a fase de transio procurou por deficincias mnimas que passaram despercebidas pela fase de construo, possibilitando sua correo e assim finalizando esta etapa com a entrega do produto. As demais pginas do produto finalizado nesta primeira iterao, podem ser visualizadas no Apndice G. Iteraes Em toda a descrio realizada anteriormente sobre as fases do UP dentro das atividades genricas de processo, foi realizada sobre apenas a primeira iterao. Aps ter sido implantado o sistema e coletado com o cliente todas as informaes sobre defeitos e funcionalidades a serem adicionadas, caminha-se para a segunda iterao. Esta segunda iterao no ser detalhada aqui, pois ela seguir a mesma seqncia da primeira, que so as fases, ou seja, sero levantados os requisitos remanescentes, adicionados ao escopo, criado os casos de uso, etc. Detalhes sobre o que foi adicionado nesta segunda iterao esto no Apndice H.

71

5 RESULTADO E DISCUSSES
5.1 Comunicao
A comunicao no processo XP acontece atravs de histrias escritas pelo prprio cliente, que faz parte diretamente do projeto que tem sua definio guiada por ele. Isso torna o levantamento dos requisitos importante durante o processo. Neste projeto, a agilidade da comunicao do XP torna-se mais vivel devido pequena quantidade de requisitos que no necessitam de tanto detalhamento como realizado no processo UP de forma a obter do cliente todos os requisitos funcionais e as especificaes para que possa definir o escopo do projeto sem maiores ambigidades.

5.2 Planejamento
O UP define, com base no escopo, os casos de uso preliminares, os requisitos nofuncionais, o cronograma, o refinamento dos requisitos principais e os ricos de projeto. Todos estes itens so de suma importncia para a conduo do projeto de maneira consistente, segura e fornece uma base para a futura construo. Porm, leva um tempo maior neste perodo. No processo XP, o planejamento acontece no decorrer de toda a construo do sistema e foi criado um cronograma para facilitar o entendimento. Um exemplo prtico desta situao estaria na fase de codificao, onde, caso exista alguma dvida ou um mau entendimento, pode ser realizada a modelagem de casos de uso. Essa uma das causas que agiliza o desenvolvimento e trs uma vantagem neste projeto, mesmo o UP possuindo um planejamento mais detalhado.

5.3 Modelagem
No projeto desenvolvido utilizando XP foi definido a modelagem de dados, modelo ER e o diagrama de classes, para o entendimento, dispensando outras modelagens. O UP definiu os casos de usos expandidos, onde houve um maior detalhamento dos casos de usos preliminares j criados em sua fase de concepo. Uma arquitetura base foi criada de forma a demonstrar a estrutura do sistema como um todo, e o modelo ER, para termos uma viso mais detalhada de estrutura de dados.

72

Apesar de algumas modelagens distintas, os dois se mostraram uma semelhantes.

5.4 Construo
Na codificao o XP utiliza a programao em pares, o que facilita a programao, dvidas referente a cdigo e conseqentemente, a construo em um menor tempo. Os releases, onde so englobados os testes, simplificam ao mximo o sistema, tornando o processo gil. UP tm uma vantagem nesta etapa, pois com tudo j modelado e estruturado, a construo realizada de maneira segura e eficiente sem riscos crticos que podem afetar o andamento do projeto.

5.5 Implantao
Grande parte da implantao realizada na fase de codificao do XP, ao trmino de cada iterao que est contida em cada release, disponibilizando ao cliente a verso onde o mesmo faz o teste de aceitao e aprovao. J no UP, com entrega da verso beta ao ambiente operacional do cliente, ele poder analisar se realmente cumpriu com suas necessidades e ento, relatar se haver alguma falha, dificuldade na utilizao ou funcionalidade a ser adicionada. Para que o cliente possa entender e operar o sistema, realizados treinamentos e disponibilizado tutoriais detalhados. Esses fatores so fundamentais para o destaque do UP.

5.6 Outras comparaes

Estima-se que o custo do projeto realizado utilizando UP, seja de duas a trs vezes maiores que o custo do projeto realizado utilizando XP, devido ao trabalho despendido e ao tempo. Nas Figuras 32 e 33, mostrado o tempo gasto em cada etapa de cada processo.

73

Agosto

Setembro

Outubro

Novembro

Dezembro

1
Planejamento Projeto Codificao Teste

FIGURA 32: Tempo gasto em cada Fase do XP

Agosto

Setembro

Outubro

Novembro

Dezembro

1
Concepo Elaborao Construo Transio

Iterao 1

Agosto

Setembro

Outubro

Novembro

Dezembro

1
Concepo Elaborao Construo Transio

Iterao 2 FIGURA 33: Tempo gasto em cada Fase do UP

74

CONCLUSO
Conclui-se, com este trabalho, que o processo XP (Extreme Programming) se torna mais vivel para projetos de pequeno porte, como o caso da Loja Charme Boutique, onde apenas sero demonstrados os produtos da loja para visualizao de seus detalhes, sem maiores funcionalidades como vendas on-line, controle de estoque, etc. Neste dado projeto, no seria necessria muita documentao, tutoriais, sesses de treinamento, entre outros, que acabam sendo desnecessrios, considerando que seu manuseio e entendimento no so to complexos, por se tratar de uma simples aplicao web. No processo UP (Unified Process), estes itens so de suma importncia para o desenvolvimento de todo o projeto e torna-se indispensvel, pois eles agregam segurana e eficincia sem riscos crticos que possam afetar seu andamento.

75

REFERNCIAS
AMBLER, S. W. Modelagem gil: prticas eficazes para a programao extrema e processo unificado. Porto Alegre: Bookman, 2004. BECK, K. Programao extrema explicada: acolha as mudanas. Porto Alegre: Bookman, 2004. JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development process. Massachusetts: Addison-Wesley, 1999. LARMAN, G. Utilizando UML e padres. 2 ed. Porto Alegre: Bookman, 2004. MEDEIROS, Manoel. Implementando testes unitrios em aava. 2007. Disponvel em: http://www.devmedia.com.br/space.asp?id=1537711. Acesso em: 21 Maio. 2009. PRESSMAN, R. S. Engenharia de software. 6 ed. So Paulo: McGraw-Hill, 2006. SCOTT, K. O processo unificado explicado. Porto Alegre: Bookman, 2003. TELES, V. M. Extreme programming: aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. So Paulo: Novatec Editora, 2006.

76

APNDICE A Histrias XP

Histria: Definir Layout Definio das cores do site Definio do design do site Definio do menu do site

Histria: Definir Pgina Inicial Definir itens da pgina inicial Mostrar data e hora na pgina inicial Definir menus da paina inicial

Histria: Exibir Layout Exibir imagem de uma roupa Exibir descrio da roupa Exibir preo da roupa

Histria: Exibir Acessrios Exibir imagem de um acessrio Exibir descrio do acessrio Exibir preo do acessrio

Histria: Adicionar Roupas Adicionar uma roupa tal como marca, cor, preo e imagem No permitir marca, cor, preo e imagem em branco

Histria: Alterar Roupas Alterar marca, cor, preo e imagem de uma roupa No permitir marca, cor, preo e imagem em branco

Histria: Excluir Roupas Excluir uma roupa

77

Histria: Definir Layout Definio das cores do site Definio do design do site Definio do menu do site

Histria: Definir Pgina Inicial Definir itens da pgina inicial Mostrar data e hora na pgina inicial Definir menus da paina inicial

Histria: Exibir Layout Exibir imagem de uma roupa Exibir descrio da roupa Exibir preo da roupa

Histria: Exibir Acessrios Exibir imagem de um acessrio Exibir descrio do acessrio Exibir preo do acessrio

Histria: Adicionar Roupas Adicionar uma roupa tal como marca, cor, preo e imagem No permitir marca, cor, preo e imagem em branco

Histria: Alterar Roupas Alterar marca, cor, preo e imagem de uma roupa No permitir marca, cor, preo e imagem em branco

Histria: Excluir Roupas Excluir uma roupa

Histria: Adicionar Acessrios Adicionar um acessrio tal como imagem, descrio e preo

78

No permitir imagem, descrio e preo em branco

Histria: Alterar Acessrios Alterar imagem, descrio e preo de um acessrio No permitir imagem, descrio e preo e branco

Histria: Excluir Acessrios Excluir acessrios

79

APNDICE B - Dicionrio de Dados

Nome da Tabela: tbroupas Campos Nome codR marca cor preco descr imgoriginal img imgthumb imgsize tamanho Tipo Int Nvarchar Nvarchar Nvarchar Nvarchar Varbinary Varbinary Varbinary Nvarchar Nvarchar Tamanho 50 50 50 120 MAX MAX MAX 50 50 Relacionamentos Chave Primria Comentrios Cdigo da Roupa Marca da Roupa Cor da Roupa Preo da Roupa Descrio da Roupa Imagem Original Imagem Redimensionada Imagem Pequena Tamanho da Imagem Tamanho da Roupa

Nome da Tabela: tbacessorios Campos Nome codA descr preco imgoriginal img imgthumb imgsize marca nome Tipo Int Nvarchar Nvarchar Varbinary Varbinary Varbinary Nvarchar Nvarchar Nvarchar Tamanho 120 50 MAX MAX MAX 50 50 50 Relacionamentos Chave Primria Comentrios Cdigo do Acessrio Descrio do Acessrio Preo do Acessrio Imagem Original Imagem Redimensionada Imagem Pequena Imagem Original Marca do Acessrio Nome do Acessrio

80

APNDICE C - Diagrama de Classes

81

APNDICE D - Pginas do Site A pgina principal mostra a pgina inicial do site da Loja Charme. Contm as promoes da loja com imagens dos produtos em questo. Possui tambm o menu com opes de navegao para visualizao dos demais itens da loja, acesso a rea administrativa e informaes sobre localizao da loja real.

Pgina Principal

A pgina que contm os acessrios da loja mostra todos os acessrios disponveis na loja. Possui encontradas informaes como preo, tamanho, cor e marca.

82

Pgina que contm os acessrios da loja

A pgina que descreve o acessrio relata as descries do acessrio, bem como sua imagem.

Pgina que descreve o acessrio

83

A pgina de login da loja mostra a tela de que, onde carregar a pgina do administrador. Por ela sero realizadas as operaes de insero, excluso e alterao. Para acess-la, o usurio dever entrar com seu login e senha pr-definidos na construo do sistema. Toda parte da construo da pgina restrita foi desenvolvida usando a ferramenta ASP.NET Configuration, que realiza toda configurao de restrio da pgina, tornando muito mais rpido o desenvolvimento do site.

Pgina de login da loja

A pgina do administrador parte acessrios mostra a parte de administrao das roupas. Podendo efetuar as mesmas operaes como na pgina de acessrios.

84

Pgina do administrador parte acessrios

85

APNDICE E - Detalhes dos Riscos

Evento de Risco Probabilidade do Risco

A falta de experincia dos desenvolvedores com algumas tecnologias. Alta Necessidade de cursos e um profissional da rea para acompanhamento.

Impacto Resposta

Alto - Atraso no cronograma e software com m qualidade. Realizao de cursos on-line. Apostilas e vdeo-aula sobre as tecnologias. Auxilio de um profissional especializado na ferramenta.

Evento de Risco Probabilidade do Risco

Webdesign para criao de imagens para o site. Mdia Necessidade de um profissional da rea para criao de imagens e demais configuraes da pagina.

Impacto Resposta

Mdio Atraso no cronograma e software com m aparncia. Contratao de um profissional para devidas tarefas.

Evento de Risco

Site destinado a browsers como Internet Explorer verso 7 ou superior e Mozilla Firefox verso 2 ou superior.

Probabilidade do Risco

Baixa O Site ser visualizado de forma desconfigurada por clientes que dispem de outras verses do aplicativo ou browsers distintos.

Impacto Resposta

Baixa Reclamao do cliente informando problemas ao site. Site criado para ser visualizado nos browsers informados por possurem maiores adeptos e maior segurana.

Evento de Risco Probabilidade do Risco Impacto

A Taxa de crescimento anual em registros do banco de dados Alta - Necessidade de manutenes no banco de dados. Alta Podendo ocasionar perda de desempenho e problemas relacionados, inclusive perda de informaes.

86

Resposta

Manuteno regularmente do banco de dados, analisando todos os aspectos para maior desempenho e confiabilidade.

Evento de Risco Probabilidade do Risco Impacto

Suporte ao projeto aps sua implantao. Alta - Criao de tutoriais, e treinamento com o usurio. Alta Pode ocasionar rejeio ao sistema por no entendimento, ou manuseio inadequado.

Resposta

Criao de tutorial com informaes de detalhes do site Acompanhamento e instruo ao cliente pessoalmente.

Evento de Risco Probabilidade do Risco

Data de entrega muito ajustada. Alta - Realizao de novas implementaes fazendo com que o prazo fique mais curto.

Impacto

Alta A inaugurao do site est marcada para a decorrente data, inclusive divulgada em panfletagem.

Resposta

Ser necessrio de mais encontros presenciais para acertos, conseqentemente pensar no mximo de detalhes possveis para adiantarmos a implementao.

Evento de Risco

Dificuldade de comunicao devido distribuio geogrfica da equipe e disponibilidade de horrios.

Probabilidade do Risco Impacto Resposta

Alta - Necessidade de Reunies presenciais. Alta Atraso no cronograma devido coordenao do trabalho Reunies Presenciais e virtuais de acompanhamento do projeto. Utilizao de ferramentas para o compartilhamento de arquivos.

87

APNDICE F - Dicionrio de Dados UP

Nome da Tabela: Usuarios Campos Nome CodigoUsuario Nome Login Senha Email Tipo Situacao Tipo Num Char Char Char Char Char Char Tamanho 50 20 20 50 13 7 Chave Primria Comentrios Cdigo do Usurio Nome do Usurio Login do Usurio Senha do Usurio Email do Usurio Tipo do Usurio Situao do Usurio

Relacionamentos -

Nome da Tabela: Generos Campos Nome CodigoGenero Nome Tipo Num Char Tamanho 9 Relacionamentos Generos 1 - oo Produtos Chave Primria Comentrios Cdigo do Gnero Nome do Gnero

Nome da Tabela: Marcas Campos Nome CodigoMarca Nome Situacao Tipo Num Char Char Tamanho 50 7 Chave Primria Comentrios Cdigo da Marca Nome da Marca Situao da Marca

Relacionamentos Marcas 1 - oo Produtos

88

Nome da Tabela: Categorias Campos Nome CodigoCategoria Nome Situacao Tipo Num Char Char Tamanho 30 7 Chave Primria Comentrios Cdigo da Categoria Nome da Categoria Situao da Categoria

Relacionamentos Categorias 1 - oo Produtos

89

APNDICE G - Pginas do Site

Pgina Principal do Site

90

Pgina de Roupas

91

Pgina de Acessrios

92

Pgina Sobre a Boutique

93

Pgina Fale Conosco

94

APNDICE H - Detalhes da segunda iterao

Requisitos Principais Apresentao da empresa Informaes sobre a empresa Cadastro de produtos (roupas/assessrios) Demonstrao dos produtos por categorias Cadastro de Promoes Informaes detalhadas sobre os produtos Informaes para contato Requisitos Principais

ESCOPO Apresentao da Empresa Cadastro de Clientes

Informaes sobre a Empresa

Cadastro de Produtos

Cadastro de Promoes

Vendas On-line de Produtos

Demonstrao dos Produtos por categorias

Informaes detalhadas sobre os Produtos

Controle de Estoque

Informaes para Contato

Escopo do Projeto

95

Editar Roupas

<<extend>>

Cadastrar Roupas Excluir Roupas

<<extend>> <<include>>

Realizar Login

Administrador
<<include>>

Editar Acessrios

<<extend>>

Cadastrar Acessrios Excluir Acessrios

<<extend>> <<include>>

<<extend>>

Editar Promoes

Cadastrar Promoes
<<extend>>

Excluir Promoes

Casos de Uso expandido

Agosto

Setembro

Outubro

Novembro

Dezembro

1
Concepo Elaborao Construo Transio

Cronograma da Iterao 2

96

Requisitos Refinados Apresentao da empresa Ser exibido na pgina inicial o principal foco da empresa com imagens e frases Informaes sobre a empresa Pgina Sobre a Charme ter como contedo, toda a histria da empresa. Cadastro de Roupas Permitir adicionar, alterar ou excluir roupas em uma rea restrita ao administrador do site, informando suas caractersticas principais. Cadastro de Acessrios Permitir adicionar, alterar ou excluir acessrios em uma rea restrita ao administrador do site, informando suas caractersticas principais. Demonstrao das roupas por categorias Uma pgina especfica com nome de Roupas permitir visualizar todas as roupas, ou por categorias. Demonstrao dos acessrios por categorias Uma pgina especfica com nome de Acessrios, permitir ao visitante visualizar todos os acessrios, ou por categorias. Cadastro de Promoes O administrador poder adicionar promoes limitadas por datas de incio e fim, informando as roupas e/ou acessrios que participaro. Informaes detalhadas sobre as roupas Cada roupa ter suas informaes detalhas ao clicar sobre a mesma. Informaes detalhadas sobre os acessrios Cada acessrio ter suas informaes detalhas ao clicar sobre o mesmo. Informaes para contato Uma pgina de contato ir conter informaes para contato como: Endereo, Telefone, Email, etc. Alm de ser possvel o visitante enviar uma mensagem diretamente pela pgina que ser recebida pelo administrador em seu e-mail.

Requisitos Refinados

97

CodigoProduto Descricao DescricaoDetalhada CodigoGenero Nome CodigoGenero CodigoMarca CodigoCategoria 1

GENEROS

Situacao

PRODUTOS
1

MARCAS
Situacao Nome

CATEGORIAS
Situacao Nome CodigoCategoria

CodigoMarca

ITENS PROMOCOES
CodigoProduto CodigoPromocao CodigoItensPromocoes Situacao Tipo Email 1 Senha Login Nome CodigoUsuario Fim Inicio Descricao CodigoPromocoes

USUARIOS

PROMOCOES

Modelo ER

Nome da Tabela: Produtos Campos Nome CodigoProduto Descricao DescricaoDetalhada Genero CodigoMarca Tipo Num Char Char Char Num Tamanho 30 50 20 Chave Primria Estrangeira Comentrios Cdigo do Produto Descrio do Produto Descrio detalhada do Produto Gnero do Produto Cdigo da Marca

98

CodigoCategoria Situacao

Num Char

Estrangeira -

Cdigo da Categoria Situao do Produto

Relacionamentos Produtos oo - 1 Marcas Produtos oo - 1 Categorias Produtos 1 - oo ItensPromocao

Nome da Tabela: ItensPromocoes Campos Nome CodigoItensPromocao CodigoPromocao CodigoProduto Tipo Num Num Num Tamanho Chave Primria Estrangeira Estrangeira Comentrios Cdigo do Itens Promoo Cdigo da Promoo Cdigo do Produto

Relacionamentos ItensPromocoes oo - 1 Produtos ItensPromocoes oo - 1 Promocoes

Nome da Tabela: Promocoes Campos Nome CodigoPromocao Descricao Inicio Fim Tipo Num Char Date Date Tamanho 100 Relacionamentos Promocoes 1 - oo ItensPromocoes Chave Primria Comentrios Cdigo do Itens Promoo Descrio da Promoo Inicio da Promoo Fim da Promoo

Dicionrio de Dados das Tabelas adicionadas e alteradas

99

Banco de Dados Microsoft Access

100

Cadastro de promoes

Promoo em destaque na pgina principal