utilização de metodologias Ágeis para adaptação de um processo de desenvolvimento de...

7/29/2019 Utilizao de Metodologias geis para Adaptao de um Processo de Desenvolvimento de Aplicaes Web

1/69

CENTRO UNIVERSITRIO LUTERANO DE SANTARMCURSO DE SISTEMAS DE INFORMAO

FELIPE DOS SANTOS NASCIMENTO

UTILIZAO DE METODOLOGIAS GEIS PARA ADAPTAO DE UMPROCESSO DE DESENVOLVIMENTO DE APLICAES WEB

SANTARM2012


2/69



Trabalho de Concluso de Cursoapresentado para obteno do Grau deBacharel em Sistemas de Informao peloCentro Universitrio Luterano de Santarm.

Orientadora: Prof. Msc. Marla TeresinhaBarbosa Geller

SANTARM2012


3/69



Trabalho de Concluso de Cursoapresentado para obteno do Grau deBacharel em Sistemas de Informao peloCentro Universitrio Luterano de Santarm.

Data de Apresentao: _____/_____/_____

_________________________________ ___________Conceito

_________________________________ ___________Conceito

_________________________________ ___________Conceito


4/69

Esta obra dedicada a toda minha famlia,

em especial aos meus pais Gilson e Luzia,

minha irm Fernanda e meus professores e

amigos que contriburam no meu

aprendizado enquanto acadmico.


5/69

AGRADECIMENTOS

Primeiramente a Deus que me deu foras, estrutura e entendimento ao longo

dessa trajetria.

A minha famlia, em especial aos meus pais e irm, que sempre me apoiaram,

dando o mximo para que eu pudesse atingir meus objetivos.

A minha orientadora professora Marla Geller pelo apoio e confiana e por ter

contribudo grandemente com sua experincia e didtica neste trabalho.

Ao Jnior Tapajs, Diretor Comercial da W3Mais Comunicao Interativa, por

ter me dado a oportunidade de alcanar um dos meus objetivos de trabalhar com

desenvolvimento web, alm de ter contribudo indiretamente com este trabalho.

A todos os meus amigos e colegas pelo incentivo e colaborao no decorrer

deste trabalho.


6/69

No devemos ter medo dos confrontos.

At os planetas se chocam e do caos

nascem as estrelas.

Charles Chaplin


7/69

RESUMO

Com a crescente demanda por aplicaes web e a dificuldade de empresas que

trabalham com esse tipo de servio, de manter um processo organizacional egerencial no decorrer do desenvolvimento de um produto, de forma a criar somenteo necessrio quando for preciso, muitas tem adotado metodologias geis. Porm,seguem o mesmo padro do desenvolvimento de software, o que ainda geratranstornos, pois muitas vezes as equipes no conseguem assimilar o que deve serfeito e nem conseguem se tornar geis. Diante do exposto problema, este trabalhotem como objetivo propor um processo gil especfico para o desenvolvimento deaplicaes web. O WAAPRO (Processo gil para Desenvolvimento de AplicaesWeb) utiliza fundamentos de metodologias geis como XP, Scrum e P@PSI, pormdirecionadas para web. Alm de utilizar princpios do Lean, que visa mudar a culturadas equipes de desenvolvimento no que diz respeito ao desenvolvimento enxuto.

Para validao do processo gil WAAPRO foi realizado um estudo de caso, atravsdo desenvolvimento do Portal Guarany, para mostrar a utilizao do processo gil.

Palavras-chave: Metodologia gil. Customizao de Processo. Aplicao Web.


8/69

ABSTRACT

With the growing demand for web applications and the difficulty of companies that

work with this type of service, to maintain an organizational and managerial processduring the development of a product, to create only what you need when you need it,many companies have adopted agile methodologies. However, follow the samepattern of software development, which still generates disorders, as teams often failto grasp what should be done and can not become agile. Considering the aboveproblem, this paper aims to propose a specific agile process for developing webapplications. The fundamentals of WAAPRO (Agile Process for Web ApplicationDevelopment) uses agile methodologies like XP, Scrum and P@PSI, but directed tothe web. In addition to using Lean principles, a way to change the culture ofdevelopment teams regarding the lean development. To validate the agile processWAAPRO was conducted a case study through the development of the Portal

Guarany to show the use of agile process.

Keywords:Agile Methodology. Process Customization. Web Application.


9/69

LISTA DE ILUSTRAES

Figura 1 - Exemplo de Diagrama de Caso de Uso .................................................... 25

Quadro 1 - Descrio dos Casos de uso mostrados na figura 1. .............................. 25Figura 2- Exemplo de Diagrama de Classes. ............................................................ 26Figura 3 - Exemplo de Diagrama ER ......................................................................... 27Figura 4 - Exemplo de Diagrama de Sequncia. ....................................................... 28Figura 5 - Wireframe da pgina inicial de um site. .................................................... 30Quadro 2 - Exemplo de uma Planilha de Requisitos ................................................. 29Figura 6 - Template da aplicao web Dinheirama Online ........................................ 31Figura 7 - Viso geral do WAAPRO .......................................................................... 41Figura 8 - Diagrama de Caso de Uso do Portal Guarany. ....................................... 44Quadro 3 - Descrio dos Casos de Uso do Portal Guarany. ................................... 44Figura 9 - Diagrama de Caso de Uso do Sistema de Administrao do Portal

Guarany..................................................................................................................... 45Quadro 4 - Descrio dos Casos de Uso do Sistema de Administrao do PortalGuarany..................................................................................................................... 46Figura 10 - Wireframe da pgina inicial do Portal Guarany. ...................................... 47Figura 11 - Template do site Portal Guarany. ............................................................ 48Figura 12 - Sistema de Administrao do Portal Guarany. ........................................ 49Figura 13 - Diagrama de Classe da funcionalidade Notcia....................................... 51Figura 14 - Diagrama de Classe da funcionalidade Rdio Interativo ......................... 52Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados ..................... 52Figura 16 - Diagrama ER - Notcia. ........................................................................... 53Figura 17 - Diagrama ER - Rdio Interativo. ............................................................. 54Figura 18 - Diagrama ER - Mural de Recados. ......................................................... 54Figura 19 - Diagrama de Sequncia da ao comentar Notcia ................................ 56Figura 20 - Diagrama de Sequncia da ao comentar Rdio Interativo .................. 57Figura 21 - Diagrama de Sequncia da ao de enviar recado atravs do Mural deRecados .................................................................................................................... 58


10/69

SUMRIO

1 INTRODUO ....................................................................................................... 12

2 VISO GERAL DO DESENVOLVIMENTO DE UMA APLICAO WEB ............. 142.1 INCIO DO PROJETO ......................................................................................... 142.2 PROGRAMAO ................................................................................................ 152.3 FINALIZAO ..................................................................................................... 152.4 MANUTENO ................................................................................................... 15

3 METODOLOGIAS GEIS UTILIZADAS NA CUSTOMIZAO DO PROCESSOWEB WAAPRO ......................................................................................................... 173.1 PROCESSOS CUSTOMIZADOS PARA APLICAES WEB ............................ 173.2 PROGRAMAO EXTREMA (XP) ..................................................................... 18

3.2.1 O Jogo do Planejamento ............................................................................... 193.2.2 Entregas Frequentes ...................................................................................... 203.2.3 Projeto Simples .............................................................................................. 203.2.4 Design Incremental ........................................................................................ 213.2.5 Programao em Pares .................................................................................. 213.2.6 Propriedade Coletiva ...................................................................................... 223.2.7 Contrato de escopo negocivel .................................................................... 223.3 SCRUM ............................................................................................................... 223.3.1 Ciclos ............................................................................................................... 233.3.2 Produto Total .................................................................................................. 243.4 P@PSI................................................................................................................. 24

3.4.1 Diagrama de Caso de Uso ............................................................................. 243.4.2 Diagrama de Classes ..................................................................................... 263.4.3 Diagrama ER ................................................................................................... 263.4.4 Diagrama de Sequncia ................................................................................. 273.5 OUTROS RECURSOS PARA DOCUMENTAO NO WAAPRO ...................... 283.4.1 Planilha de Requisitos ................................................................................... 283.4.2 Documento de Design Funcional .................................................................. 293.4.3 Template .......................................................................................................... 30

4 APLICAO DO LEAN NO PROCESSO ............................................................. 324.1 PRINCPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE ............... 33

4.1.1 Elimine o desperdcio .................................................................................... 334.1.2 Amplifique o aprendizado .............................................................................. 334.1.3 Entregue o mais rpido possvel .................................................................. 334.1.4 Respeito .......................................................................................................... 344.1.5 Construa com integridade ............................................................................. 344.1.6 Visualize o todo .............................................................................................. 344.2 OS BENEFCIOS DO LEAN ................................................................................ 34

5 MODELO DE CUSTOMIZAO DO PROCESSO GIL PARA APLICAESWEB - WAAPRO ...................................................................................................... 375.1 O QUE WAAPRO?........................................................................................... 37

5.2 PLANEJAMENTO................................................................................................ 375.3 DESENVOLVIMENTO ......................................................................................... 385.4 FINALIZAO ..................................................................................................... 39


11/69

5.5 MANUTENO ................................................................................................... 40

6 ESTUDO DE CASO ............................................................................................... 426.1 O CLIENTE ......................................................................................................... 42

6.2 O PROJETO ........................................................................................................ 426.3 PLANEJAMENTO................................................................................................ 436.3.1 Levantamento e Anlise de Requisitos ........................................................ 436.3.2 Proposta de desenvolvimento....................................................................... 466.3.3 Briefing ............................................................................................................ 476.3.4 Template .......................................................................................................... 476.4 DESENVOLVIMENTO ......................................................................................... 496.4.1 Coleta de contedo ........................................................................................ 506.4.2 Diagramao do Template ............................................................................. 506.4.3 Codificao ..................................................................................................... 506.5 FINALIZAO ..................................................................................................... 58

6.5.1 Reviso do Produto ........................................................................................ 596.5.2 Apresentao do produto ao cliente ............................................................ 596.5.3 Entrega do produto ........................................................................................ 596.5.4 Treinamento .................................................................................................... 596.6 MANUTENO ................................................................................................... 60

7 CONCLUSO ........................................................................................................ 61

REFERNCIAS ......................................................................................................... 63

ANEXOS ................................................................................................................... 65


12/69

12

1 INTRODUO

Com o crescimento do nmero de empresas que produzem negcios para seus

clientes na internet, e consequentemente, o grande envolvimento de profissionais da

rea, torna-se necessrio encontrar uma maneira de gerenciar o trabalho desses

profissionais a fim de gerar produtos de qualidade que agreguem valor ao negcio

do cliente. Lidar com pessoas, e nesse caso, clientes, uma tarefa difcil, pois as

mudanas que ocorrem no que se refere a caractersticas e requisitos do sistema,

durante o desenvolvimento de aplicaes web afetam os custos, prazos e muitas

vezes a qualidade do produto. Para acompanhar essas mudanas preciso uma

organizao. nesse aspecto que a modelagem gil ajuda os desenvolvedores e,tambm, o cliente a compreender o escopo do produto antes, durante e aps a

finalizao do mesmo. preciso entregar um produto que satisfaa as necessidades

do cliente, afinal, esse o primeiro objetivo do desenvolvimento de software.

A utilizao de metodologias geis uma proposta que vem sendo estudada

h anos no desenvolvimento de software. Basicamente, todas tentam definir um guia

de desenvolvimento, identificando quem est fazendo o qu, onde, por que, como e

quando. Jacyntho (2008), afirma que um processo de software definido com umconjunto de atividades interdependentes que visam desenvolver, manter e gerenciar

sistemas de software. Sendo que cada atividade pode ser composta de outras

atividades e so executadas por atores que desempenham um papel no processo

(programador, gerente, cliente, etc.). O resultado das atividades so artefatos

(cdigo, documentao, modelos) que servem de entrada para outras atividades

para produzir novos artefatos. Sem um processo de software, o risco de falha do

projeto se torna muito alto, em especial para as aplicaes web modernas cujacomplexidade no para de crescer.

Com a proposta de desenvolver projetos de maneira capaz de responderrpido s mudanas, com foco nas pessoas e na colaborao com o cliente,surgiram as metodologias geis que, devido s suas caractersticas,possibilitam gerar produto com maior valor agregado e ao mesmo tempomanter pessoas motivadas dentro das corporaes (AKITA, 2009 apudTANIGUCHI; CORREA, 2009).

A partir da concepo das metodologias geis possvel criar um processo gilvoltado para desenvolvimento de aplicaes web, que por sua vez, tm foco no


13/69

13

produto em si, ou seja, sendo mais importante entregar algo de qualidade sem se

prender em interminveis documentos, eliminando desperdcios e desenvolvendo

somente o necessrio e quando necessrio. Pois, assim como no desenvolvimento

de software tradicional, aplicaes web esto constantemente sofrendo mudanas

durante e aps sua implementao, trabalhando assim com releases iterativos e

incrementais de entrega.

Segundo Bohem e Turner (2004 apud JACYNTHO, 2008) no existe um

processo correto ou incorreto, tanto processos rigorosos quanto processos geis,

ambos tm suas vantagens e desvantagens. Ou seja, preciso encontrar um ponto

de equilbrio entre as duas abordagens para cada tipo de projeto, e assim definir um

processo hbrido que traga benefcios reais.Diante da necessidade de um processo de desenvolvimento voltado para

ambientes e aplicaes web, ser mostrado neste trabalho um processo gil

customizado a partir de metodologias geis j existentes, sendo elas: Programao

Extrema (XP), Scrum e P@PSI. Este trabalho tambm cita o conceito Lean, uma

metodologia voltada para o desenvolvimento de produtos de forma a eliminar

desperdcios e criar um ambiente de aprendizado constante a partir de expectativas

da equipe e feedback dos clientes, assim produzindo somente o que gera valor parao cliente.

Este trabalho est organizado em captulos, onde aps a introduo o segundo

captulo apresenta uma viso geral do desenvolvimento de uma aplicao web, o

terceiro captulo apresenta as metodologias geis utilizadas na customizao do

processo web WAAPRO, o quarto captulo mostra a aplicao do Lean no processo

proposto, o captulo cinco exemplifica o modelo de customizao do WAAPRO e o

captulo seis apresenta um estudo de caso utilizando como processo gil oWAAPRO no desenvolvimento de um site.


14/69

14

2 VISO GERAL DO DESENVOLVIMENTO DE UMA APLICAO WEB

O tpico a seguir descreve a experincia do autor no desenvolvimento de

aplicaes web e o processo utilizado desde o incio de um projeto, passando pela

finalizao at a manuteno aps entrega do produto ao cliente.

2.1 INCIO DO PROJETO

O projeto de desenvolvimento de uma aplicao web se inicia com uma reunio

preliminar com o cliente, a fim de se obter informaes sobre a real necessidade

para se criar o produto. Neste primeiro momento, decidido o tipo de produto,podendo variar desde um website informativo, apresentando informaes acerca da

empresa do cliente, por exemplo, quanto a sites de venda de produtos on-line,

conhecido como e-commerce.

No desenvolvimento web existem outros produtos como hotsites, que

geralmente so sites pequenos e especficos para um determinado evento ou ao

publicitria. E, tambm, sistemas on-line, como grandes portais de contedo que

possuem diversas funcionalidades.Definido o tipo de aplicao a ser desenvolvida, feito um levantamento de

requisitos junto ao cliente. Primeiro, para conhecer suas necessidades ao procurar

este tipo de produto e, segundo, para saber quais funcionalidades a aplicao ir

conter.

Com essas informaes em mos , ento, elaborada uma proposta de

desenvolvimento, contendo todas as informaes necessrias para iniciar o

desenvolvimento do produto. Esta proposta inclui informaes detalhadas de cadafuncionalidade, as pginas que sero criadas, custo total do projeto, tempo de

desenvolvimento e, tambm o que no ser produzido, pois aps o contrato fechado

o que for solicitado como mudana fora do escopo no far parte do valor fixado no

contrato, este sofrer um acrscimo.

Esta proposta apresentada ao cliente. Caso haja algum item em

discordncia, este tem a total liberdade de pedir a reformulao at chegar a um

ponto comum com a equipe responsvel pelo desenvolvimento da aplicao web.

Sendo a proposta aprovada, o incio do desenvolvimento d-se pela criao do

layout baseado nas informaes previamente coletadas. O layout baseia-se,


15/69

15

principalmente, na harmonia de cores e localizao das informaes. A equipe

responsvel tem total liberdade para criar algo dentro dos padres web de

usabilidade e, posteriormente, esse layout passa pela aprovao do cliente.

2.2 PROGRAMAO

Uma vez que o layout finalizado, e o cliente se satisfaa com a localizao de

cada funcionalidade e informao que a aplicao ir conter, inicia-se o processo de

programao, ou seja, a codificao dos requisitos. Durante esta etapa os requisitos

podem sofrer alteraes, fazendo-se necessrio o uso de padres web de

programao que facilitam a manuteno dos cdigos a fim de se evitar desperdciode tempo.

2.3 FINALIZAO

Aps a finalizao da programao de toda a aplicao, esta testada por

completo localmente (off-line), e depois enviada para um servidor on-line para

testes finais. Caso existam falhas, estas so corrigidas, seno, uma nova reuniocom o cliente realizada para apresentao do produto final. Se aprovada, a

aplicao fica disponvel para o pblico geral, seno volta para a etapa de

programao.

2.4 MANUTENO

No desenvolvimento web, aps a entrega da aplicao funcionandocorretamente, se inicia mais uma etapa, que a manuteno do mesmo. Esta etapa

engloba desde a atualizao do contedo, layout e at mesmo mudanas nos

requisitos iniciais, como a incluso de novas funcionalidades.

Essa fase de Manuteno deve ser especificada em contrato de forma

coerente, pois o cliente pode eventualmente achar que pode requerer qualquer

mudana aps a finalizao do projeto, o que um equvoco. O desenvolvedor ir

realizar qualquer mudana no escopo descrito em contrato, caso seja acrescentada

uma nova funcionalidade, o valor do projeto passa por um reajuste. Para isso, h

uma negociao prvia com o cliente, para que fique tudo bem claro. importante


16/69

16

ressaltar, que qualquer manuteno solicitada pelo cliente passa pelo gerente de

projetos primeiro. Ele, junto com a equipe de desenvolvimento analisa o que pode

ser feito e as consequncias de tal mudana antes de entrar em processo de

implementao. Nem todas as alteraes podero ser realizadas aps a finalizao

do projeto, pois podem comprometer muitas funes. Por isso importante uma

anlise de requisitos bem criteriosa, no incio do desenvolvimento do projeto.


17/69

17

3 METODOLOGIAS GEIS UTILIZADAS NA CUSTOMIZAO DO PROCESSO

WEB WAAPRO

Metodologias geis so vistas como as melhores alternativas s abordagens

tradicionais de desenvolvimento de software. Uma vez que mtodos tradicionais

surgiram em um contexto de desenvolvimento de software baseado apenas em um

mainframe e terminais burros (ROYCE, 1970 apud SOARES, 2004), onde no

existiam ferramentas de apoio ao desenvolvimento de software, e todo o projeto era

baseado em documentos produzidos antes de o software ser implementado.

Essas metodologias surgiram para mudar o conceito de desenvolvimento de

software baseado somente em documentos. Com isso, passou-se a se preocuparcom as pessoas que compe os projetos, principalmente, desenvolvedores e

clientes. A partir disso, houve uma melhoria no processo de codificao, passando a

ser guiado por testes e utilizando de forma mais eficiente as prticas da Engenharia

de Software.

Este captulo se divide na breve descrio de alguns processos customizados

para desenvolvimento de aplicaes web, e algumas das principais metodologias

geis utilizadas no desenvolvimento de software, sendo elas, o Scrum, XP e P@PSIcom foco na implantao em ambientes que ainda no utilizam metodologias geis

como parte do processo de desenvolvimento de software. Essas metodologias

serviram de base para a customizao do Processo gil para Desenvolvimento de

Aplicaes Web, denominado WAAPRO.

3.1 PROCESSOS CUSTOMIZADOS PARA APLICAES WEB

Existem algumas propostas de processos voltados para aplicaes web, como

o XWebProcess que foi criado adaptando elementos do XP para lidar com

importantes questes de sistemas web, tais como: interfaces com usurio

complexas, navegao, requisitos no-funcionais, testes e suporte de infraestrutura

(SAMPAIO, 2004 apud JACYNTHO, 2008). Outro processo o OPEN-Web Process,

e foi adaptado para desenvolvimento web a partir do OPEN (Object-Oriented

Process, Environment, and Notation) que um meta-processo e abrange o ciclo de

vida completo de desenvolvimento, incluindo aspectos de negcio e de software

(HAIRE et tal, 2001 apud JACYNTHO, 2008). Alm desses, tambm pode-se citar o


18/69

18

WebPraxis que como propsito ser utilizado no desenvolvimento de aplicativos que

rodem em ambientes web e no simplesmente sites estticos ou dinmicos

(LVARES, 2001). Foi proposto a partir do Praxis, por ser um processo genrico

para produo de aplicativos interativos e orientados a objetos. Assim, o WebPraxis

herda as caractersticas usadas para desenvolvimento de aplicativos comuns

desktop e insere outras para atender s necessidades do desenvolvimento web.

3.2 PROGRAMAO EXTREMA (XP)

A Programao Extrema (XP) uma metodologia para equipes de

desenvolvimento pequenas, de duas a dez pessoas, que desenvolvem softwaresonde os requisitos do usurio so vagos e que se modificam rapidamente. Segundo

Beck (2004), o desenvolvimento de software tem falhas, sendo estas na entrega e

nos valores entregues. Essas falhas geralmente so vistas quando o software j

est em produo, o que ocasiona em impactos econmicos e humanos. A XP visa

eliminar os erros durante os processos de desenvolvimento de software, por isso

encoraja o dilogo entre membros da equipe e, principalmente, com o cliente, tendo

assim feedback dirio.A XP segue quatro variveis, sendo elas: custo, tempo, qualidade e escopo.

Alm de se basear em cinco valores para conduzir o desenvolvimento, sendo:

comunicao, coragem, feedback e simplicidade. Dessa forma, ela tenta prever os

problemas antes que estes aconteam e assim achar a melhor soluo para resolv-

los de forma rpida.

Como programadores, nos habituamos a antecipar problemas. Quando eles

aparecem mais tarde, ficamos felizes. Quando no aparecem, nem notamos.(BECK, 2000 apud TELES, 2005).

Junto com essas caractersticas, foram utilizadas no WAAPRO o ciclo codificar,

testar, ouvir e projetar, que so as quatro atividades bsicas da XP. Segundo Beck

(2004), o cdigo serve como meio de comunicao que expressa intenes tticas e

descreve algoritmos; os testes servem tanto como recurso quanto a uma

responsabilidade, pois dizem quando se terminou de codificar; ouvir faz com que o

feedback do programador ajude o cliente a entender melhor seus problema; e por

final, projetar desenvolver o que foi planejado de forma organizada, ou seja, o


19/69

19

cdigo tem que ser projetado para suportar modificaes de forma que o sistema

seja impactado o mnimo possvel em outras partes.

No WAAPRO buscou-se utilizar prticas XP que pudessem ser utilizadas

tambm no desenvolvimento web como: Jogo do Planejamento, Entregas

Frequentes, Projeto Simples, Design Incremental, Programao em Pares,

Propriedade Coletiva e Contrato de escopo negocivel.

3.2.1 O Jogo do Planejamento

O Jogo do Planejamento determina brevemente o escopo do projeto

combinando prioridades de negcios e estimativas tcnicas.O desenvolvimento web, assim como o desenvolvimento de software um

dilogo evolutivo entre o possvel e o desejvel. Assim, segundo Beck (2004) as

pessoas da rea do negcio precisam decidir sobre:

Escopo o objetivo de um projeto entregar um produto que gere valor de

negcio ao cliente, porm quanto de um problema precisa ser resolvido para

que o sistema tenha valor em produo? A pessoa da rea de negcios

precisa estar apta a responder questionamentos como esse, entendendo oquanto no suficiente e o quanto demais.

Prioridade est ligado a escolhas, s vezes preciso escolher entre

funcionalidades a serem desenvolvidas primeiro. A pessoa da rea de

negcios est em posio de decidir isso, muito mais do que um

programador, por exemplo.

Composio das verses basicamente, preciso saber quanto da

aplicao web precisa ser feita para que o produto comece a entregar valorao cliente.

Datas de entrega datas so importantes, pois servem como metas.

A rea tcnica est diretamente ligada com a rea de negcios, pois fornece a

matria-prima para a tomada de deciso. Portanto, as pessoas da rea tcnica

decidem sobre:

Estimativas informao sobre quanto tempo levar para implementar umafuncionalidade, por exemplo.


20/69

20

Consequncias existem decises estratgicas de negcios que devem

ser tomadas apenas quando h informaes sobre as consequncias

tcnicas. Por exemplo, um caso de uso muda durante o desenvolvimento e

este atinge pelo menos outra funcionalidade, podendo fazer o sistema parar

por alguns instantes. A rea de desenvolvimento precisa explicar as

consequncias.

Processo a equipe de trabalho precisa ser organizada, para isso

importante programar bem a aplicao web sem se prender a uma cultura

fechada.

Cronograma detalhado os programadores precisam de liberdade para

dizer o que deve ser feito primeiro na aplicao web, a fim de reduzir o risco

total do projeto.

3.2.2 Entregas Frequentes

No desenvolvimento web as mudanas so muito rpidas e os usurios finais

esperam sempre algo novo. A prtica de Entregas Frequentes diz que se possvel,

coloque um sistema simples rapidamente em produo e depois libere novasverses em ciclos curtos.

Cada verso entregue deve ter o menor tamanho possvel, contendo os

requisitos de maior valor para o negcio. Beck (2004) ainda afirma que a entrega

precisa fazer sentido como um todo, de nada adianta entregar verses malfeitas, ou

seja, implementar meia funo e entreg-la, s para tornar mais curto o ciclo de

entrega.

3.2.3 Projeto Simples

Basicamente, a XP prope uso de mtodos que tornem o projeto de

desenvolvimento mais simples, onde programadores podem utilizar recursos como

padres de projeto e framework na codificao, por exemplo. Tufte (1992 apud

BECK, 2004) prope um exerccio para designers grficos. Desenhe um grfico da

forma que voc quiser. Ento apague todos os elementos, desde que voc no

remova nenhuma informao. O que restar quando voc no puder apagar mais

nada o design certo para o grfico.


21/69

21

Para que um projeto se torne simples necessrio ter funcionalidades ou

casos de usos bem definidos, o que nem sempre acontece, pois as mudanas fazem

parte do escopo e podem acontecer em qualquer estgio do projeto. Mas

importante fazer somente o que for preciso quando realmente precisar, ou seja,

evitar criar algo que no ser usado ou que a falta deste no ir ter grandes

impactos.

3.2.4 Design Incremental

O objetivo do Design Incremental sempre tornar o cdigo e design mais

simples, legvel e preparado para mudanas. Deve ter suporte de outras prticas,como a refatorao1 e os teste automatizados para garantir que a equipe seja capaz

de solucionar os problemas futuros com mais rapidez. Sato (2009) alerta para a

interpretao dessa prtica, seu objetivo no minimizar o investimento com design

no curto prazo, mas sim manter esse investimento proporcional s necessidades do

sistema conforme ele evolui. Para que isso funcione existe padres de

desenvolvimento web que podem ser seguidos e que melhoram a legibilidade dos

cdigos e consequentemente a performance da aplicao, como por exemplo, usode frameworks.

3.2.5 Programao em Pares

Na Programao em Pares existem dois papis em cada par. O primeiro

aquele indivduo com o teclado e o mouse que est pensando qual a melhor forma

de implementar um mtodo especfico. O segundo pensa de forma estratgica: Essa abordagem como um todo vai funcionar?

Que outros casos de testes podem no funcionar?

Existe uma maneira de simplificar todo o sistema para que o problema

simplesmente desaparea?

Isso promove o trabalho coletivo e colaborativo, une a equipe e melhora,

tambm, a comunicao e a qualidade do cdigo (SATO, 2009). O aprendizado

1 Para Beck (2004), refatorar um cdigo significa alterar seu comportamento a fim de remover

duplicidade, melhorar a comunicao, simplificar e acrescentar flexibilidade.


22/69

22

sempre repassado para toda a equipe, assim h uma maior comunicao de todos

que passam a compartilhar de tcnicas e ideias novas.

3.2.6 Propriedade Coletiva

Mesmo que um programador tenha levado dias em um cdigo, a XP sugere

que qualquer um da equipe pode modificar tal cdigo. Isso quer dizer que, no h

um dono, a qualquer momento, qualquer um que perceba uma oportunidade de

acrescentar valor a alguma parte do cdigo obrigado a faz-lo (BECK, 2004).

A XP sugere que todos sejam donos do sistema inteiro. Obviamente, nem

sempre todos da equipe iro conhecer todas as partes do cdigo, mas podem saberum pouco sobre cada parte. Isso d uma viso mais ampla do sistema, facilitando a

execuo de refatorao e espalhando conhecimento por toda a equipe. No

desenvolvimento web, onde toda a equipe est conectada diretamente ao cdigo,

isso importante, pois no se deve perder tempo solicitando mudanas quando o

prprio programador puder melhorar o cdigo.

3.2.7 Contrato de escopo negocivel

Contratos devem ter fixados tempo, custo e qualidade, deixando o escopo das

funcionalidades em aberto para negociao. Isso porque no desenvolvimento de

aplicaes web as mudanas no decorrer do projeto so frequentes, sendo que em

XP, o escopo revisado o tempo todo para garantir que a equipe esteja sempre

trabalhando no que mais importante para o cliente. Com o escopo das

funcionalidades em aberto, o cliente pode solicitar mudanas conforme a evoluoda aplicao e, tambm, do seu aprendizado.

3.3 SCRUM

O objetivo da metodologia gil Scrum definir um processo para projeto e

desenvolvimento de software orientado a objetos, que seja focado nas pessoas e

que seja indicado para ambientes em que os requisitos surgem e mudam

rapidamente. O Scrum tambm considerado um mtodo especfico para o

gerenciamento de processo de desenvolvimento de software (LUNA; COSTA; DE


23/69

23

MOURA, 2011). Surgiu a partir de um estudo feito por Takeuchi & Nonaka, no qual,

notaram que projetos de curta durao, usando equipes pequenas e

multidisciplinares, produzem melhores resultados (DE CARVALHO, 2009).

Scrum uma metodologia baseada em simplicidade e adaptabilidade. Umfundamento dessa filosofia a manuteno da base desse conceito:equipes gerenciveis. A maioria dos livros aponta equipes de no mximo 9pessoas, multidisciplinar e motivada. Mas inescapvel a existncia deprojetos onde essa fora de trabalho tem de ser multiplicada, devido aotamanho do sistema sendo desenvolvido (GOLALVES, 2011).

Tudo o que acontece sob Scrum realizado em um perodo limitado de tempo,

denominado Time Boxing. Isso fundamental para entregar software no menor

tempo possvel. Alm do mais, o Scrum busca a simplicidade. Isso se reflete nos

papis que cada pessoa tem durante o processo de desenvolvimento, so apenas

trs e no h nenhuma hierarquia entre elas: Product Owner (dono do produto),

Scrum Master (coordenador da equipe) e o Scrum Team (equipe de

desenvolvimento). Com essa simplicidade a equipe se esfora em planejar menos e

realizar mais, sendo objetivo nas atividades a serem executadas (GONALVES,

2011). O WAAPRO busca a simplicidade dos projetos web, por isso foi um princpio

utilizado na customizao deste processo, alm de imaginar como ser o produto

final.

3.3.1 Ciclos

No processo gil WAAPRO foi utilizado o elemento Ciclo da gesto iterativa e

incremental, que no Scrum chamado Sprint. Cada Sprint o perodo de tempo em

que um ou mais incrementos reais so desenvolvidos e, ao final, tais incrementosdevem ser demonstrados ao cliente. Essa uma forma de tornar o cliente presente

no desenvolvimento e diminuir o risco de mudanas nos requisitos aps a finalizao

do projeto. O importante aqui o tempo de vida de um Ciclo, que no deve

ultrapassar quatro semanas.

No desenvolvimento web a velocidade de desenvolvimento acelerada, quanto

mais rpido se desenvolve uma funcionalidade mais rpido ser o feedback da

equipe e do cliente.


24/69

24

3.3.2 Produto Total

As funcionalidades no Scrum so vistas primeiro como um todo, chamado

Product backlog, ou seja, tudo o que a aplicao ir conter. Depois disso, passa por

um processo de avalio para priorizar as funcionalidades a serem desenvolvidas

naquele Sprint, gerando assim um Sprint backlog.

No WAAPRO foi adotado a mesma ideia, necessrio visualizar a aplicao

web como um todo, no com todas as funcionalidade que pode conter, mas sim o

que necessrio para a aplicao se tornar funcional e gerar valor para o cliente. A

partir dessa ideia que as funcionalidades so priorizadas e implementadas no fluxo

de desenvolvimento.

3.4 P@PSI

Pode-se descrever o [..] P@PSI, como sendo gerenciado pelo Scrum,

adotando prticas XP e com fluxos do Processo Unificado. (GELLER; KNEBEL;

BENTES JNIOR, 2007).

O processo gil P@PSI foi criado em 2008 pelo Grupo de Trabalho gil (GTA)do Centro Universitrio Luterano de Santarm (CEULS/ULBRA), e surgiu com o

propsito de auxiliar desenvolvedores de softwares em pequenos projetos para

empresas que buscam solues personalizadas.

Por ser um processo gil customizado, o P@PSI possui algumas prticas j

testadas como o uso de modelos para representar aspectos do sistema e tambm o

ciclo iterativo oriundo do Processo Unificado. Alguns desses recursos tambm

podem ser utilizados no desenvolvimento de aplicao web e foram utilizados,principalmente, para servir de documentao dos projetos. Sero apresentados os

diagramas mais comuns que podem facilitar a documentao no processo gil

WAAPRO.

3.4.1 Diagrama de Caso de Uso

Um recurso da UML muito utilizado em desenvolvimento de software o

Diagrama de Casos de Uso (figura 1), que permite agrupar o comportamento

esperado do sistema em rotinas de limites muito bem definidos, que faro a


25/69

25

interao com os usurios (MELO, 2009). O caso de uso utilizado para representar

os requisitos do sistema, ou seja, o que a aplicao deve fazer a fim de atender as

necessidades dos interessados, principalmente os clientes.

Atravs de um caso de uso possvel descrever o funcionamento de uma

funcionalidade de maneira informal, sendo de fcil assimilao por clientes que

acompanham um projeto. Os principais conceitos associados ao Diagrama de Caso

de Uso so: atores, e casos de uso.

Figura 1 - Exemplo de Diagrama de Caso de Uso

Fonte: Arquivo pessoal, 2012.

Alm da forma visual, bom utilizar um quadro descritivo (quadro 1) para cada

caso de uso, assim, mesmo depois de muito tempo da finalizao de um projeto,

caso surja alguma alterao, o desenvolvedor saber exatamente porque aquele

caso de uso foi feito e o que ele representa na aplicao web.

Quadro 1 - Descrio dos Casos de uso mostrados na figura 1.

Fazer LoginO usurio efetuar Login para ter acesso aosistema

Fazer Cadastro O usurio faz seu cadastro no sistema.Comprar Produto O usurio efetua a compra de um produto.

Validar DadosVerificar se os dados do usurio j esto nabase de dados e se esto corretos.

Dar DescontoO sistema valida a compra e fornece para ousurio um campo para inserir seu cdigo dedesconto.



26/69


27/69

27

Principalmente no desenvolvimento web, a modelagem da base de dados

muito importante, pois a partir dela o sistema pode responder de forma rpida ou

no. Por exemplo, s vezes os desenvolvedores no se preocupam com a

quantidade de usurios que a aplicao pode suportar simultaneamente, uma

modelagem da base de dados errada junto com uma programao malfeita pode

comprometer toda a aplicao, podendo s vezes, ficar inacessvel ou lenta.

Figura 3 - Exemplo de Diagrama ER


3.4.4 Diagrama de Sequncia

Um Diagrama de Sequncia um artefato que ilustra - para um cenrio

especfico de um caso de uso, com o auxlio das classes identificadas num modelo

de classes - os eventos de entrada e sada relacionados num sistema, como troca

de mensagens, dentro de uma linha de tempo sequencial. Na modelagem do

Diagrama de Sequncia (figura 4) cada item descrito nos cenrios principais e

alternativos representado por mensagens. Essas mensagens podem ser

expressas do ator para o sistema, ou da interface para os objetos (MELO, 2009).


28/69

28

Figura 4 - Exemplo de Diagrama de Sequncia.

Fonte: GELLER, 2012.2

O P@PSI tambm possui uma herana do Processo Unificado que so os

fluxos iterativos, no qual o processo possui: Planejamento, Desenvolvimento e

Encerramento. No WAAPRO tambm foram utilizados fluxos iterativos, porm os

fluxos so Planejamento, Desenvolvimento, Finalizao e Manuteno, sendo

descritos no captulo 5.

3.5 OUTROS RECURSOS PARA DOCUMENTAO NO WAAPRO

Alguns recursos so vlidos no desenvolvimento de aplicaes web, tais como

Planilha de Requisitos, Documento de Design Funcional e Template.

3.4.1 Planilha de Requisitos

A planilha de requisitos, como mostra o quadro 2, um artefato para

armazenar as informaes feitas no levantamento de requisitos. Esse recurso

importante para orientar os desenvolvedores sobre as funcionalidades do sistema

que interagem entre si, facilitando a manuteno dos mesmos, em caso de

modificaes durante ou aps a implementao. Para isso, a planilha especifica um

cdigo nico para cada funcionalidade ou ao que a aplicao ir conter, alm de

2 Geller, Marla. (Centro Universitrio Luterano de Santarm). Comunicao pessoal. Santarm, 2012.


29/69

29

um campo descritivo, categoria que indica o tipo do requisito, prioridade, dificuldade,

status se o requisito j foi implementao ou no, e comentrios adicionais. Essa

planilha atualizada a cada iterao do projeto, assim se tem um maior controle do

que est sendo feito e principalmente quais os requisitos mais urgentes que devem

ser priorizados.

Quadro 2 - Exemplo de uma Planilha de Requisitos

Aplicao web

Cod Requisito Prioridade

Dificuld

ade Atendido Comentrios

F001 Inserir/Alterar/Excluir Enquete. Baixo Baixo No

F002Todo comentrio deve gravar o IP dousurio Alto Baixo Sim

IP no deve serexibido para usurio.

F003 Listar Notcias por Categoria Mdio Mdio No

F004

Somente usurio nvel "Master" pode

cadastrar Novos usurios Alto Alto Sim


3.4.2 Documento de Design Funcional

O Documento de Design Funcional um conjunto de Wireframes onde cada

um representa cada pgina da aplicao. O Wireframe (figura 5) representa a

arquitetura de uma pgina web com a disposio dos elementos, mas no funo

demonstrar a esttica, como conjunto de cores e fontes, por exemplo. Entretanto,

serve como esboo para o designer produzir os Templates da aplicao.


30/69

30

Figura 5 - Wireframe da pgina inicial de um site.


3.4.3 Template

O Template, tambm chamado de Prottipo de Interface, como mostra a figura

6, pode representar parte da aplicao a ser implementada, uma funcionalidade, ou

uma proposta de layout, feita pelo designer. Para isso, o designer precisa utilizar o

Documento de Design Funcional ou parte dele para ter uma base de como ser o

posicionamento de cada elemento na aplicao. Alm disso, este recurso fornece ao

cliente uma prvia, ainda que no funcional, de como ser a interface da aplicao,demonstrando principalmente o conjunto de cores. Por isso importante o cliente

aprovar o Template antes de este ser implementado.


31/69

31

Figura 6 - Template da aplicao web Dinheirama Online

Fonte: DINHEIRAMA ONLINE, 2012.

Como visto no captulo, o WAAPRO possui vrios recursos que tem origem em

processos j existentes. Outros foram inseridos para atender s caractersticas de

aplicaes web.


32/69

32

4 APLICAO DO LEAN NO PROCESSO

A maioria das empresas que querem adotar processos geis no fazem uso de

boas prticas de engenharia de software, e adotar qualquer procedimento pode ser

difcil. Por esse motivo, criou-se um conceito que tem como objetivo auxiliar as

empresas a equilibrar corretamente o uso de prticas, princpios e valores em todos

os nveis de uma organizao, promovendo assim, uma mudana segura e

sustentvel na cultura interna e nos mtodos de desenvolvimento e assim criar uma

empresa efetivamente gil e enxuta.

O suporte mudana precisa ser geral, no somente da gerncia executiva,mas tambm do cho de fbrica. Normalmente, a primeira reao daspessoas a resistncia sendo assim, imposio nunca ser o melhorcaminho. preciso abrir espao, dar as ferramentas adequadas e criar umambiente que seja propcio mudana (CRESCNDIO, 2011).

O Lean uma filosofia de negcio baseada no Sistema Toyota de Produo.

Durante 25 anos a Toyota aperfeioou seu sistema enxuto e provou que pode ser

competitiva, tornando-se a maior e mais lucrativa montadora de automveis. Atravs

desse pensamento Lean, possvel identificar o que gera valor na viso dos clientese usurios.

O ponto inicial para o pensamento Lean reconhecer que apenas uma frao

do tempo total e esforo de uma organizao adicionam, de fato, valor ao cliente.

Apesar dos princpios e conceitos gerais sobre essa abordagem j terem mais de 50

anos, s recentemente que estes passaram a ser conhecidos e terem uma devida

aceitao. Isso mostra que a economia mundial afeta muitas empresas, deixando

muitas em dificuldades para sobreviver, lutando para reduzir custos sem prejudicar a

qualidade e servio ao cliente.

A viso do Lean alm de evitar o desperdcio produzir servios ou produtos

de qualidade e que gerem valor para o cliente. De forma simplificada, valor consiste

nas caractersticas perceptveis ao cliente, que cada produto ou servio proporciona

ao seu negcio. Por exemplo: preo, qualidade, prazo de entrega, atendimento

prestado, funcionalidades de acordo com as necessidades especificadas. Ou seja, o

produto ou servio exatamente como o cliente deseja.


33/69

33

4.1 PRINCPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE

Neste tpico so mostrados os princpios do Lean direcionados para o

desenvolvimento de aplicaes web, tais como, eliminar o desperdcio, amplificar o

aprendizado, entregar o mais rpido possvel, respeitar, integrar e visualizar o todo.

4.1.1 Elimine o desperdcio

Evite fazer mais que o necessrio. Elimine qualquer coisa que no agregue

valor ao produto e que no so percebidas pela cliente. Por exemplo, se o time

entrega funcionalidades incompletas, se produz documentao de anlise apenaspara estar em concordncia com o processo, se no prioriza casos de uso e

implementa mais funcionalidade que o necessrio de imediato. Isso tudo

desperdcio.

4.1.2 Amplifique o aprendizado

importante ter um processo de desenvolvimento que encoraje a sistemticade aprendizagem ao longo do ciclo de desenvolvimento. Os desenvolvedores tm

que ter a capacidade de responder rapidamente a mudanas de requisitos por parte

do cliente. Um cdigo sofre constantes mudanas, portanto, preciso codificar de

forma simples, geralmente orientado a testes.

Desenvolvimento um exerccio de descoberta, enquanto produo umexerccio de reduo de variaes, e por essa razo, aprender a abordagem

de desenvolvimento resulta em prticas que so bastante diferentes do queaprender abordagens de prticas de produo (DAVIDSON, 2010).

4.1.3 Entregue o mais rpido possvel

Segundo Crescndio (2011), h duas grandes razes para entregar rpido:

para que o cliente no mude de ideia enquanto um projeto est em desenvolvimento

e para que o concorrente no entregue antes. Alm disso, reduzir os ciclos e

entregar rpido e de forma incremental permite feedback e aprendizado sobre o que


34/69

34

est sendo feito. Assim, que preciso descobrir como entregar uma aplicao

funcional to rpido que clientes no tenham tempo para mudar suas ideias.

4.1.4 Respeito

Respeitar as pessoas do ponto de vista do Lean no significa aplicar apenas o

bom senso e a boa educao. A forma como uma equipe se organiza influencia

profundamente no respeito s pessoas. Fazer o simples como dar visibilidade do

trabalho feito, prover e aceitar feedback, errar o quanto antes e deixar todo mundo

saber, so exemplos de respeito. Um ambiente Lean d espao para que todos

possam aprender abertamente sobre esse tipo de problema e assim resolv-los deuma forma adequada (CRESCNDIO, 2011).

4.1.5 Construa com integridade

Existem dois tipos de integridade, sendo: Conceitual aquela que s os

construtores sabem que existe. Percebida aquela que os usurios podem notar.

Para que se tenha integridade, preciso uma comunicao efetiva, criando assim,um fluxo contnuo de informaes entre desenvolvedores, usurios e clientes.

4.1.6 Visualize o todo

Este princpio valoriza o aprendizado do ambiente de desenvolvimento, todas

as pessoas precisam enxergar e compreender o todo e criar uma organizao que

contribua para a melhoria de seus processos. Por exemplo, se uma equipe temespecialistas em certas partes de um cdigo e s eles conseguem mexer l,

certamente as demais pessoas da equipe no esto vendo o todo.

4.2 OS BENEFCIOS DO LEAN

Mesmo com origem em um ambiente de produo industrial, o Lean passou a

ser aplicado em empresas de diversos setores e atividades. De modo geral,

possvel identificar os mais significativos benefcios resultantes da aplicao

pensamento Lean nas empresas, que podem ser resumidos da seguinte forma:


35/69

35

Crescimento do negcio;

Aumento da produtividade;

Aumento da satisfao do cliente;

Aumento da qualidade e do servio prestado ao cliente;

Maior envolvimento, motivao e participao das pessoas;

Reduo das reas de trabalho;

Aumento da capacidade de resposta;

Reduo do lead time(tempo em que se recebe um requisito at a entrega

da funcionalidade).

O caminho para que uma empresa ou um uma equipe de desenvolvimento se

torne Lean nem sempre fcil, requer o envolvimento e o compromisso de todos.

Nesse tempo, as empresas passam por vrios estgios de desenvolvimento, e

nessas etapas necessrio estabelecer metas e objetivos, quantificar resultados e

atuar em funo de desvios. Alguns requisitos para o sucesso so:

Envolvimento da gesto de topo;

Aderir ao conceito O cliente em primeiro lugar;

Estar consciente em relao aos problemas;

Gerenciar o processo atravs de resultados e fatos;

Criar qualidade em tudo que se faz;

Implementar as mudanas envolvendo todas as pessoas.

As metodologias geis so um processo de melhoria que uma empresa pode

adotar para desenvolver aplicaes web com melhor qualidade, seguindo um padro

para documentao do que est sendo construdo, eliminando desperdcios, erro e

at com um custo menor. A grande dificuldade como implementar essa abordagem

de forma eficiente e sem causar grande impacto na empresa. Por exemplo, a equipe

de desenvolvimento pode sentir dificuldade em aplicar muitas prticas e acabar

atrasando o cronograma de entrega do produto. preciso saber quando usar cada

recurso das metodologias geis. Uma soluo apresentada para esse problema a

prtica Lean, que surge com a finalidade de ser o caminho para a mudana do

estado atual da empresa (sem prticas geis) at o uso efetivo de uma metodologia

gil. Acredita-se que o Lean junto com o processo gil WAAPRO pode tornar uma


36/69

36

equipe mais eficiente ao produzir aplicaes web que gerem valor de negcios para

o cliente.


37/69


38/69

38

contedos a serem inseridos, o que o projeto no ir conter, ou seja, o que no faz

parte do escopo do projeto, e o custo total.

Em seguida, realizada uma nova reunio com o cliente para apresentar a

Proposta de Desenvolvimento. Neste momento, o cliente decide se dar ou no

continuidade ao projeto. Caso ele no esteja de acordo com alguma especificao

no documento, pode solicitar alterao. Sendo aprovado, o projeto segue para o

incio da criao do briefing. De acordo com Waiteman (2005 p. 38), briefing consiste

em:

[...] no mximo, duas pginas com informaes dissecadas e organizadas,que representam tudo o que o cliente deseja da agncia. O briefing explica

o problema, sugere caminhos de posicionamento e faz o pedido de trabalho.A voc, cabe transforma o problema descrito no briefing em uma soluo[...].

O briefing o documento que auxilia todos da equipe a ter conhecimento sobre

o cliente e, mais, serve para os responsveis pela criao do templateproduzirem

as interfaces com base nas informaes contidas no briefing.

Durante a criao do template necessrio, tambm, criar um modelo de

organizao, uma forma de melhor exibir as informaes para o usurio, tornando aaplicao fcil de utilizar e navegar. Aps o template finalizado, necessria a

aprovao do cliente, havendo alteraes, o processo retorna para a etapa de

Criao do templatee Modelo de Organizao, caso contrrio iniciado a etapa de

Desenvolvimento.

5.3 DESENVOLVIMENTO

Com o incio da fase de Desenvolvimento, o template passa por um

refinamento, ou seja, so coletadas e ajustadas as mdias e contedos que sero

implementados na aplicao web. o contedo solicitado previamente ao cliente,

como imagens, vdeos, produo de textos, etc.

Aps o refinamento do templatese inicia o ciclo de codificao dos casos de

uso, que est divido em trs etapas e no deve ultrapassar o perodo de quatro

semanas, sendo:

Codificar funcionalidades, propriamente dito, escrever os cdigos e toda a

logica de programao, independente das ferramentas e tecnologias utilizadas, a


39/69


40/69


41/69

40

Figura 7 - Viso geral do WAAPRO

Fonte: Arquivo Pessoal, 2012.


42/69

42

6 ESTUDO DE CASO

Este captulo apresenta um estudo de caso, onde o processo gil WAAPRO foi

utilizado na empresa W3Mais Comunicao Interativa, para o desenvolvimento de

um site interativo para a empresa Sistema Guarany de Comunicao. O site pode

ser visualizado atravs do link .

6.1 O CLIENTE

O Sistema Guarany de Comunicao um grupo formado pela Rdio Guarany

FM, TV e Portal Guarany.A Rdio Guarany FM foi inaugurada em 1981 com a ideia de expandir os

trabalhos que foram iniciados com o servio de propaganda volante Guarany e

cobertura de eventos religiosos. Atualmente a rdio opera na frequncia 100,3 Mhz

e tem ouvintes de todas as faixas etrias, sendo a mais popular na cidade de

Santarm (PORTAL GUARANY, 2012).

Retransmissora da Rede Record de Televiso, a TV Guarany, desde sua

formao proporciona entretenimento, descontrao e jornalismo opinativo decredibilidade mais perto do povo. (PORTAL GUARANY, 2012).

O Portal Guarany foi criado para suprir a necessidade de uma comunicao

mais ampla via internet com os ouvintes, telespectadores e internautas. Assim, a

Rdio Guarany FM passou a ser ouvida por pessoas do mundo todo.

6.2 O PROJETO

A finalidade do Portal Guarany ser um elo interativo entre os ouvintes da

Rdio Guarany e os apresentadores dos programas, bem como servir como portal

de contedo com notcias regionais e do territrio brasileiro. As funcionalidades

principais so: Rdio Interativo, Notcias, Mural de Recados e Programao da

Rdio. Outras funcionalidades secundrias tambm fizeram parte do projeto, como:

Galeria de fotos, Feed de posts do Twitter, Feed de notcias do Portal R7 3, sistema

3Portal de contedo da Rdio e Televiso Record S/A.


43/69

43

de Publicidade, cdigo de rastreamento do Google Analytics e tambm, o link para

ouvir a rdio on-line.

6.3 PLANEJAMENTO

A fase de Planejamento inicia-se atravs do contato com o cliente, no caso o

cliente o Sistema Guarany de Comunicao. Esta fase inclui o Levantamento e

Anlise de Requisitos para entender as necessidades do cliente e quais

funcionalidades o site ir conter; Proposta de Desenvolvimento que a elaborao

de um documento com as informaes sobre o projeto e Briefing que um recurso

til para o Designer criar um Template que se adeque a proposta do cliente.

6.3.1 Levantamento e Anlise de Requisitos

A fase inicial do projeto diz respeito avaliao da situao e das

necessidades do cliente. Na primeira reunio o cliente exps suas necessidades.

Primeiramente, o site deveria ter uma seo especfica em que o usurio pudesse

responder a questionamentos dirios, sempre uma pergunta polmica sobre aatualidade. Esses comentrios seriam lidos pelo apresentador do programa Rdio

Interativo ao vivo, portanto os dados deveriam ser validados de modo que um

usurio no se passasse por outro. Segundo, uma seo tipo mural de recados,

onde os usurios pudessem enviar mensagens para qualquer pessoa. Terceiro, uma

rea especial de notcias com quatro categorias especficas (Santarm, Par, Brasil,

Mundo). Quarto, mostrar o programa que a rdio estaria apresentando no momento

em que o usurio acessasse o site, alm de um link que ao ser clicado, o usuriopudesse ouvir a rdio ao vivo.

Outras necessidades tambm foram mencionadas, como ter uma galeria de

fotos, onde o administrador pudesse cadastrar fotos dos eventos do Sistema

Guarany de Comunicao. Uma forma de exibir as notcias do Portal R7 e as

publicaes feitas no Twitter pela conta oficial do Portal Guarany. E, um sistema de

publicidade, que empresas interessadas em anunciar no site pudessem ter seu

banner exposto de forma simples.

De posse dessas informaes foi necessrio transformar essas estrias de

usurio em funcionalidades que o site iria conter. Para isso, foi elaborado um


44/69


45/69

45

liberao pelo administrador.

Visualizar Programao ao vivo

Exibe o programa da rdio transmitidono momento e uma foto doapresentador. Tambm exibe um linkpara o usurio ouvir o programa on-line.

Ouvir Rdio on-lineLink externo para o usurio ouvir ardio on-line.

Visualizar Feed TwitterExibe postagens da conta@portalguarany no Twitter.

Visualizar Feed Portal R7 Exibe notcias do Portal R7.

Visualizar Galeria de fotosExibe fotos separadas por galerias(lbuns).


O Portal Gurany possui funcionalidades que apenas podem ser vistas pelos

administradores do site. Para no haver confuso no desenvolvimento, foi feito um

novo Diagrama de Caso de Uso, mostrado na figura 9, apresentando as

funcionalidades acessveis para os usurios da administrao do site. Como mais de

uma pessoa teria acesso, foi solicitado que os usurios tivessem nveis de acesso.

Portanto, ficou definido que o nvel Master teria acesso a todas as funcionalidades

do sistema de administrao e o nvel Web Masterteria acesso apenas liberaode contedo, no podendo cadastrar novos usurios, por exemplo.

Figura 9 - Diagrama de Caso de Uso do Sistema de Administrao do Portal Guarany.



46/69


47/69

47

6.3.3 Briefing

Aps a aprovao da Proposta de Desenvolvimento pelo cliente foi necessrio

elaborar um briefing (ver anexo B) com informaes relevantes para o

desenvolvimento do site, como informaes sobre o Sistema Guarany de

Comunicao, a identidade visual, e o que seria utilizado no design do site. Essas

informaes so teis no processo criativo do designer responsvel por criar o

Template do site e das pginas que este contm.

6.3.4 Template

Para o desenvolvimento da parte visual do site foi utilizado o recurso wireframe.

A equipe de desenvolvimento fez um rascunho do layout do site com as

funcionalidades descritas no Diagrama de Caso de Uso. O wireframes representa

a disposio do layout e pode ser visto abaixo, na figura 10.

Figura 10 - Wireframe da pgina inicial do Portal Guarany.



48/69

48

A partir do wireframeo designer comeou a trabalhar na parte esttica do site,

ou seja, o desenho com as cores e imagens dispostas no layout. Essa etapa exigiu

bastante criatividade, mas com o briefing em mos a tarefa de construir o template

ficou mais fcil, pois j se sabia que a cor principal seria um tom de verde e cores

variadas que indicassem cada seo do site, como mostra a figura 11.

Terminado o template, este precisou ser aprovado pelo cliente. Para isso, em

uma reunio o template foi apresentado e com poucos questionamentos, logo foi

aprovado, dando sequncia ao desenvolvimento.

Figura 11 - Template do site Portal Guarany.



49/69


50/69

50

6.4.1 Coleta de contedo

Antes do incio do desenvolvimento necessrio ter todo o contedo das

pginas. especificado no contrato de desenvolvimento que o cliente tem um prazo

para entregar todo o material necessrio para o desenvolvimento do site, isso inclui

textos, imagens, vdeos ou qualquer contedo que precise estar no site no ato da

entrega (alguns contedos podem ser inseridos pelo prprio usurio atravs do

sistema de administrao). Com o contedo em mos o desenvolvimento foi

passado para a fase de codificao.

6.4.2 Diagramao do Template

A primeira etapa da codificao do site transformar o Template que uma

imagem em cdigo. Isso requer o uso de alguns recursos web como a linguagem

de folhas de estilos CSS e o XHTML que uma linguagem de marcao semntica.

No CSS ficam as regras do que ser exibido das pginas, como cores, fundos,

tamanhos de divs5, posicionamento de divs, fonte do texto, etc. Cabe ao XHTML

separar o contedo semanticamente para receber os estilos do CSS.

O site fica exatamente igual ao desenho feito pelo designer, porm em forma

de cdigos prontos para serem implementados em linguagem dinmica, que

especificamente nesse projeto foi utilizado o PHP.

6.4.3 Codificao

No Portal Guarany foi utilizado alguns padres de desenvolvimento comoorientao a objetos, MVC e DAO. Isso traz alguns benefcios, como a rapidez na

manuteno do cdigo.

Para incio da codificao das funcionalidades priorizadas foi utilizado

Diagrama de Classes para modelar as classes de cada funcionalidade.

Basicamente, cada diagrama representa a classe seus atributos e uma classe

auxiliar com os mtodos de controle.

5 Elemento HTML que define uma diviso na pgina e pode ter variadas formataes.


51/69

51

A funcionalidade Notcia exemplificada pelo diagrama da figura 13 representa

que cada notcia tem apenas uma categoria, podendo ser Santarm, Par, Brasil,

Mundo. Alm disso, cada notcia pode receber comentrios.

Figura 13 - Diagrama de Classe da funcionalidade Notcia


A funcionalidade Rdio Interativo, representada na figura 14, mostra que h um

relacionamento entre uma questo e um comentrio, onde a questo pode receber

vrios comentrios, porm os comentrios possuem um status do tipo boolean, que

indica que o administrador do sistema quem publica ou no o comentrio.


52/69

52

Figura 14 - Diagrama de Classe da funcionalidade Rdio Interativo


A terceira funcionalidade priorizada foi a Mural de Recados (figura 15). Aqui

pode-se ver que apenas uma classe faz o controle dessa funcionadade. O usurio

pode enviar um comentrio para um outro usurio, porm esse comentrio s fica

visvel mediante publicao do administrador do sistema, por isso o uso do atributo

status com tipo de dado boolean.

Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados



53/69

53

Tambm foi utilizado o Diagrama ER para modelar o banco de dados e para

definir as tabelas necessrias para armazenamento de contedo. Este tipo de

artefato ajuda a entender melhor os relacionamentos entre tabelas. Como mostram

as figuras 16, 17 e 18, representando as funcionalidades Notcia, Rdio Interativo e

Mural de Recados respectivamente. A partir disso, foi possvel criar todo um

conjunto de classes que permitem manipular os dados das tabelas.

Figura 16 - Diagrama ER - Notcia.



54/69

54

Figura 17 - Diagrama ER - Rdio Interativo.


Figura 18 - Diagrama ER - Mural de Recados.


A modelagem do sistema foi realizada de forma iterativa, pois os modelos

criados foram surgindo conforme a necessidade de registrar o que se produzia. Essa

forma de trabalhar caracterstica das metodologias geis.


55/69

55

Durante o desenvolvimento do Portal Guarany algumas funcionalidades ficaram

um pouco confusas na hora da codificao, uma delas foi o caso de uso Rdio

Interativo, responsvel direto pela interao dos usurios do site com a Rdio

Guarany FM. De fato, o cliente queria que cada pessoa que comentasse na Rdio

Interativo fosse nica e esses comentrios deveriam ser moderados pela

administrao. O problema era como fazer isso da forma mais simples possvel e

que no dificultasse a forma de interao do usurio com o site. Ao se tentar fazer o

que o cliente queria, perdeu-se muito tempo desenvolvendo uma funcionalidade de

forma que no gerava valor algum para o cliente e ainda dificultava a interao como

usurio. Seguindo a ideia de processo enxuto Lean, para criar algo que realmente

trouxesse valor para o negcio do cliente foi feita uma anlise de como o RdioInterativo funcionaria. Uma forma de solucionar o problema foi visualiz-lo melhor

com diagramas de sequncia. No s para a funcionalidade Rdio Interativo, mas

nesse mdulo procurou-se fazer tambm para a funcionalidade Notcia e Mural de

Recados.

Na funcionalidade Notcia, representada pelo diagrama de sequncia na figura

19, foram discutidos quais campos seriam preenchidos pelo usurio e se o

comentrio seria moderado pelo administrador ou no. Por fim, a equipe concordouque todos os comentrios seriam moderados pelo administrador, onde este poderia

apenas excluir ou publicar o comentrio, ficando impedido de alterar qualquer

informao. Essa anlise foi fundamental para desenvolver outras funcionalidades

que teriam o mesmo princpio.


56/69

56

Figura 19 - Diagrama de Sequncia da ao comentar Notcia


Quando foi necessrio fazer a codificao da funcionalidade Rdio Interativo,

houve uma dificuldade em tentar encontrar a forma mais simples de um usurio

comentar um questionamento. O cliente queria que o sistema pudesse identificar

fraude em um comentrio, ou seja, um usurio no poderia comentar com o nome

ou outra informao pessoal igual outra pessoa. A soluo final, e mais simples, foi

que o usurio teria trs campos para inserir dados, sendo Nome, Bairro e

Comentrio, pois so as informaes que o apresentador do Programa Rdio

Interativo l ao vivo. Todos os comentrios so moderados pelo administrador do

sistema. Somente aps a publicao os comentrios ficam visveis para o usurio e

somente enquanto o questionamento estiver no ar. A representao do diagrama desequncia pode ser vista na figura 20.


57/69

57

Figura 20 - Diagrama de Sequncia da ao comentar Rdio Interativo


Quando a funcionalidade Mural de Recados foi codificada, j se tinha um

conhecimento de como ela iria se comportar, porm ainda foi representada atravs

de um diagrama de sequncia (figura 21) que mostra a ao de enviar um recado e

a publicao do mesmo pelo administrador do sistema. Aqui a funcionalidade segue

a mesma ideia das outras, o recado s fica visvel aps a permisso pelo

administrador, e este pode excluir o comentrio a qualquer momento, mesmo aps a

publicao.


58/69

58

Figura 21 - Diagrama de Sequncia da ao de enviar recado atravs do Mural de Recados


Como pde ser notado no decorrer do processo de desenvolvimento, o

WAAPRO permitiu gerar conhecimento para toda a equipe discutir sobre como uma

funcionalidade iria se comportar e assim gerar conhecimento para funcionalidades

futuras. Os diagramas foram muito importantes para esclarecer dvidas, pois muitas

vezes uma pessoa da equipe no conseguia visualizar, ou mesmo, fazer o cliente

entender como determinada ao acontecia.

6.5 FINALIZAO

Na etapa de Finalizao busca-se fazer testes de toda a funcionalidade ou do

projeto inteiro pronto a fim de encontrar erros. Tambm, caracterizada pela

entrega da aplicao para o cliente e o treinamento do mesmo.


59/69

59

6.5.1 Reviso do Produto

Cada funcionalidade foi testada a fim de localizar erros. Quando uma

funcionalidade apresentava um erro, ela voltava para a fase de Desenvolvimento at

estar pronta para ser testada com o site todo. Essa reviso do produto importante

por simular a ao do usurio ao acessar o site, bem como o administrador do

sistema no momento de gerenci-lo. O Portal Guarany tem muitas funcionalidades e

na hora de testar tudo algumas coisas no saram como planejado, como o caso de

uso Ver Programao ao Vivo. No momento do teste percebeu-se que o fuso horrio

do servidor era diferente do fuso horrio brasileiro (Braslia), assim tendo que voltar

para o Desenvolvimento at ser corrigido e pronto para apresentar ao cliente.

6.5.2 Apresentao do produto ao cliente

O Portal Guarany foi apresentado atravs de uma reunio da equipe de

desenvolvimento com o cliente. Foi demonstrada cada funcionalidade em

funcionamento. Aps o trmino da apresentao o cliente deu seu parecer sobre o

produto, no final gostou do que viu. Vale ressaltar que o site j estava em suahospedagem oficial, porm acessvel apenas para a equipe de desenvolvimento.

6.5.3 Entrega do produto

A entrega do produto foi feita a partir do momento em que o site foi liberado

para que todos pudessem acess-lo, deixando-o visvel na web.

6.5.4 Treinamento

A administrao do site possui muitas funcionalidades, tudo intuitivo, porm o

cliente queria que fosse ministrado um treinamento para duas pessoas responsveis

pela administrao do Portal Guarany. O treinamento foi feito de forma presencial e

foi realizado em dois dias.


60/69


61/69

61

7 CONCLUSO

O processo gil WAAPRO se mostrou eficiente no desenvolvimento de

aplicaes web, como pde ser constatado no desenvolvimento do Portal Guarany.

O uso de etapas permitiu melhor controle do que se estava fazendo e no deixando

a equipe se perder quando ocorriam mudanas nos requisitos.

Em algumas etapas do projeto ficou evidente que o uso de um processo gil

ajuda a minimizar desperdcios de tempo, regra fundamental de um processo Lean.

Como por exemplo, durante a codificao da funcionalidade Rdio Interativo, os

requisitos mudaram diversas vezes, a primeira vez foi produzido algo que o cliente

queria, porm no gerava valor algum. Isso foi constatado quando o site foi ao ardurante alguns dias para testes com usurios iniciais. Durante aproximadamente 1

semana, no houve nenhum comentrio na Rdio Interativo, isso significava que

algo de errado estava acontecendo. Portanto, a funcionalidade foi refeita mais duas

vezes, e somente na terceira mudana que os comentrios comearam a

aparecer. Para isso, tudo que dificultava a ao de comentar foi retirado. O usurio

simplesmente comentava e esperava o comentrio ser publicado pelo administrador.

O Lean passou a ser fundamental junto com o processo gil WAAPRO, poistoda a equipe pde aprender melhor como realizar as atividades focando no produto

e no usurio, alm de fazer somente o que gerava valor para o cliente. Entretanto a

viso do Lean foi superficial. Percebe-se que para o aprendizado de uma

metodologia gil e uma mudana de cultura numa empresa que no utiliza esse tipo

de processo de desenvolvimento leva bastante tempo, porque no incio difcil

assimilar o funcionamento do processo e mais difcil ainda abandonar alguns

vcios, como o pensar e fazer, sem planejar cada etapa do processo dedesenvolvimento.

O uso de metodologias geis como o XP e o Scrum foram de extrema

importncia para se ter uma viso mais ampla do que poderia ser utilizado como

caracterstica para a criao do WAAPRO, uma vez que essas metodologias j

foram bastante testadas. O P@PSI permitiu ter uma melhor ideia de como um

processo gil pode ser customizado e quais seus benefcios.

Procurou-se mostrar o funcionamento do WAAPRO atravs de um estudo de

caso para ter a validao do processo gil junto com uma equipe de

desenvolvedores que no utilizavam nenhum tipo de processo especfico nos


62/69


63/69

63

REFERNCIAS

LVARES, Patrcia Marques Rodrigues de Sousa. WebPraxis Um processo

personalizado para projetos de desenvolvimento para a Web. 2001. 105p.Dissertao (Ps-Graduao em Cincia da Computao). Instituto de CinciasExatas da Universidade Federal de Minas Gerais. Belo Horizonte, 2001. Disponvelem: .Acesso em 08 dez. 2011.

BECK, Kent. Programao Extrema (XP) explicada: Acolha as mudanas. PortoAlegre: Bookman, 2004.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 6ed. Rio de Janeiro: Elsevier, 2005.

CRESCNDIO, Samuel. A Pirmide Lean: O equilbrio das Foras geis. Edio38. Devmedia Group, 2011. Disponvel em: .Acesso em 28 abr. 2012. ISSN 1983127-7.

DAVIDSON, Edgard. Princpios do Pensamento Lean. Disponvel em:. Acesso em 23 nov. 2011.

DE CARVALHO, Bernardo Vasconcelos. Aplicao do mtodo gil Scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnolgica. 2009. 100p. Dissertao (Mestrado em Engenharia de Produo).Universidade Federal de Itajub, Itajub, 2009. Disponvel em:. Acesso em 25 nov. 2011.

DINHEIRAMA ONLINE. DinheiramaGerenciador de Contedo Financeiro.Disponvel em: . Acesso em: 28 abr. 2012.

GELLER, Marla; KNEBEL, Clvis; BENTES JNIOR, Joo. GTA Grupo deTrabalho gil Desenvolvimento gil de Software atravs da customizao deprocessos.III Congresso Sul Catarinense de Computao. Cricima SC, 2007.

GOLALVES, Geraldo Magela Dutra. A gerncia de projetos de software emduas perspectivas Parte 2: Scrum. Edio 38. Devmedia Group, 2011.Disponvel em: . Acesso em 28 abr. 2012.ISSN 1983127-7.

JACYNTHO, Mark Douglas de Azevedo. Processos para Desenvolvimento deAplicaes Web. 2008. 25p. Monografias em Cincia da Computao Rio deJaneiro, Pontifcia Universidade Catlica. 2008. Disponvel em:. Acesso em 02 jun.2012.

LUNA, Alexandre; COSTA, Cleyverson; DE MOURA, Hermano. A necessidade deser gil: Uma anlise crtica sobre nove mtodos geis. Edio 27. Devmedia


64/69

64

Group, 2011. Disponvel em: . Acesso em 28abr. 2012. ISSN 1983127-7.

MELO, Ana Cristina. UML Diagrama de Sequncias: Descobrindo como

modelar um diagrama de sequncias. Edio 15. Devmedia Group, 2009.Disponvel em: . Acesso em 23 abr. 2012.ISSN 1983127-7.

PORTAL GUARANY. Sistema Guarany de Comunicao. Disponvel em. Acesso em 26 mai. 2012.

SATO, Danilo. Introduo Programao Extrema (XP). Engenharia de SoftwareMagazine. Edio 10. Devmedia Group, 2009. Disponvel em:. Acesso em 22 abr. 2012. ISSN 1983127-7.

SOARES, Michel dos Santos. Comparao entre Metodologias geisTradicionais para o Desenvolvimento de Software. Infocomp: Jornal of ComputerScience. v 3, n 2, nov. 2004. Disponvel em:. Acesso em 25 nov. 2011.

TANIGUCHI, Kenji; CORREA, Fernando Eugenio. Metodologias geis e aMotivao de Pessoas em Projetos de Desenvolvimento de Software:Aplicando prticas de SCRUM e XP para promover a motivao de equipes deprojetos de desenvolvimento de software. So Paulo, v. 4, n. 4, 2009. Disponvelem: .Acesso em 02 jun. 2012.

TELES, Vincius Manhes. Um Estudo de Caso da adoo das prticas e valoresdo Extreme Programming. 2005. 179p. Dissertao (Mestrado em Informtica)Universidade Federal do Rio de Janeiro, Ncleo de Computao Eletrnica, Rio deJaneiro, 2005. Disponvel em: .Acesso 21 nov. 2011.

WAITEMAN, Flvio. Manual Prtico de Criao Publicitria: O dia-dia da Criaoem uma Agncia. So Paulo: Nobel, 2006. p 38. ISBN 85-213-1309-8.


65/69

65

ANEXOS


66/69

66

ANEXO A PROPOSTA DE DESENVOLVIMENTO PORTAL GUARANY

Agncia: W3MAIS COMUNICA O INTERATIVA

Cliente: PORTAL GUARANY

Proposta para desenvolvimento e administrao de Site

I NOSSA EMPRESA

A W3MAIS uma agncia web legalmente constituda, associada

Associao Comercial e Empresarial de Santarm (ACES).

Para conhecer um pouco mais da agncia s acessar o sitewww.w3mais.com.br e conhecer nossas solues.

II NOSSA PROPOSTA

Nossa proposta consiste no desenvolvimento de um site para o Portal Guarany,

incluindo layout personalizado. Segue abaixo as sugestes das sesses do site.

Seo FunoPrincipal Pgina inicial com chamadas para as principais sees do site.

SGCApresenta descrio da empresa incluindo misso, viso evalores.

Notcias Lista todas as notcias em ordem de publicao.

ServiosApresenta todos os servios teis para os usurios (ex: nmerodo telefone do CIOP, Hospital Regional, PSM, Bancos, etc).

Participe Lista links Mural de Recados, Rdio Interativo e Redes Sociais.

Fotos Lista as galerias de fotos dos eventos da empresa.

ComercialSeo destinada para apresentao das empresas do grupoSGC e informaes para anunciantes.

Fale conoscoExibe as formas de contato da empresa: telefones, e-mails eendereo.

RdioInterativo

Interao com os usurios atravs de uma pergunta principalcom opo para comentrios.

Mural deRecados Interao entre usurios por meio de comentrios,


67/69

67

ProgramaoExibe o programa que est sendo transmitido no momento emque usurio est acessando o site.

III

INVESTIMENTODesenvolvime

utilização de metodologias Ágeis para adaptação de um processo de desenvolvimento de...

Documents