Utilização de Metodologias Ágeis para Adaptação de Um Processo de Desenvolvimento de Aplicações Web

CENTRO UNIVERSITRIO LUTERANO DE SANTARM CURSO DE SISTEMAS DE INFORMAO FELIPE DOS SANTOS NASCIMENTO
UTILIZAO DE METODOLOGIAS GEIS PARA ADAPTAO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAES WEB
SANTARM 2012
FELIPE DOS SANTOS NASCIMENTO
Trabalho de Concluso de Curso apresentado para obteno do Grau de Bacharel em Sistemas de Informao pelo Centro Universitrio Luterano de Santarm. Orientadora: Prof. Msc. Marla Teresinha Barbosa Geller
SANTARM 2012
FELIPE DOS SANTOS NASCIMENTO
Trabalho de Concluso de Curso apresentado para obteno do Grau de Bacharel em Sistemas de Informao pelo Centro Universitrio Luterano de Santarm.
Data de Apresentao: _____/_____/_____
_________________________________
___________ Conceito
_________________________________
_________________________________
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 enquanto no meu
aprendizado
acadmico.
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.
No devemos ter medo dos confrontos. At os planetas se chocam e do caos nascem as estrelas. Charles Chaplin
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 e gerencial no decorrer do desenvolvimento de um produto, de forma a criar somente o necessrio quando for preciso, muitas tem adotado metodologias geis. Porm, seguem o mesmo padro do desenvolvimento de software, o que ainda gera transtornos, pois muitas vezes as equipes no conseguem assimilar o que deve ser feito e nem conseguem se tornar geis. Diante do exposto problema, este trabalho tem como objetivo propor um processo gil especfico para o desenvolvimento de aplicaes web. O WAAPRO (Processo gil para Desenvolvimento de Aplicaes Web) utiliza fundamentos de metodologias geis como XP, Scrum e P@PSI, porm direcionadas para web. Alm de utilizar princpios do Lean, que visa mudar a cultura das equipes de desenvolvimento no que diz respeito ao desenvolvimento enxuto. Para validao do processo gil WAAPRO foi realizado um estudo de caso, atravs do desenvolvimento do Portal Guarany, para mostrar a utilizao do processo gil. Palavras-chave: Metodologia gil. Customizao de Processo. Aplicao Web.
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 process during the development of a product, to create only what you need when you need it, many companies have adopted agile methodologies. However, follow the same pattern of software development, which still generates disorders, as teams often fail to grasp what should be done and can not become agile. Considering the above problem, this paper aims to propose a specific agile process for developing web applications. The fundamentals of WAAPRO (Agile Process for Web Application Development) uses agile methodologies like XP, Scrum and P@PSI, but directed to the web. In addition to using Lean principles, a way to change the culture of development teams regarding the lean development. To validate the agile process WAAPRO 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.
LISTA DE ILUSTRAES
Figura 1 - Exemplo de Diagrama de Caso de Uso .................................................... 25 Quadro 1 - Descrio dos Casos de uso mostrados na figura 1. .............................. 25 Figura 2- Exemplo de Diagrama de Classes. ............................................................ 26 Figura 3 - Exemplo de Diagrama ER ......................................................................... 27 Figura 4 - Exemplo de Diagrama de Sequncia. ....................................................... 28 Figura 5 - Wireframe da pgina inicial de um site. .................................................... 30 Quadro 2 - Exemplo de uma Planilha de Requisitos ................................................. 29 Figura 6 - Template da aplicao web Dinheirama Online ........................................ 31 Figura 7 - Viso geral do WAAPRO .......................................................................... 41 Figura 8 - Diagrama de Caso de Uso do Portal Guarany. ....................................... 44 Quadro 3 - Descrio dos Casos de Uso do Portal Guarany. ................................... 44 Figura 9 - Diagrama de Caso de Uso do Sistema de Administrao do Portal Guarany..................................................................................................................... 45 Quadro 4 - Descrio dos Casos de Uso do Sistema de Administrao do Portal Guarany..................................................................................................................... 46 Figura 10 - Wireframe da pgina inicial do Portal Guarany. ...................................... 47 Figura 11 - Template do site Portal Guarany............................................................. 48 Figura 12 - Sistema de Administrao do Portal Guarany......................................... 49 Figura 13 - Diagrama de Classe da funcionalidade Notcia....................................... 51 Figura 14 - Diagrama de Classe da funcionalidade Rdio Interativo ......................... 52 Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados ..................... 52 Figura 16 - Diagrama ER - Notcia. ........................................................................... 53 Figura 17 - Diagrama ER - Rdio Interativo. ............................................................. 54 Figura 18 - Diagrama ER - Mural de Recados. ......................................................... 54 Figura 19 - Diagrama de Sequncia da ao comentar Notcia ................................ 56 Figura 20 - Diagrama de Sequncia da ao comentar Rdio Interativo .................. 57 Figura 21 - Diagrama de Sequncia da ao de enviar recado atravs do Mural de Recados .................................................................................................................... 58
SUMRIO
1 INTRODUO ....................................................................................................... 12 2 VISO GERAL DO DESENVOLVIMENTO DE UMA APLICAO WEB ............. 14 2.1 INCIO DO PROJETO ......................................................................................... 14 2.2 PROGRAMAO ................................................................................................ 15 2.3 FINALIZAO ..................................................................................................... 15 2.4 MANUTENO ................................................................................................... 15 3 METODOLOGIAS GEIS UTILIZADAS NA CUSTOMIZAO DO PROCESSO WEB WAAPRO ......................................................................................................... 17 3.1 PROCESSOS CUSTOMIZADOS PARA APLICAES WEB ............................ 17 3.2 PROGRAMAO EXTREMA (XP) ..................................................................... 18 3.2.1 O Jogo do Planejamento ............................................................................... 19 3.2.2 Entregas Frequentes ...................................................................................... 20 3.2.3 Projeto Simples .............................................................................................. 20 3.2.4 Design Incremental ........................................................................................ 21 3.2.5 Programao em Pares .................................................................................. 21 3.2.6 Propriedade Coletiva...................................................................................... 22 3.2.7 Contrato de escopo negocivel .................................................................... 22 3.3 SCRUM ............................................................................................................... 22 3.3.1 Ciclos............................................................................................................... 23 3.3.2 Produto Total .................................................................................................. 24 3.4 P@PSI................................................................................................................. 24 3.4.1 Diagrama de Caso de Uso ............................................................................. 24 3.4.2 Diagrama de Classes ..................................................................................... 26 3.4.3 Diagrama ER ................................................................................................... 26 3.4.4 Diagrama de Sequncia ................................................................................. 27 3.5 OUTROS RECURSOS PARA DOCUMENTAO NO WAAPRO ...................... 28 3.4.1 Planilha de Requisitos ................................................................................... 28 3.4.2 Documento de Design Funcional .................................................................. 29 3.4.3 Template.......................................................................................................... 30 4 APLICAO DO LEAN NO PROCESSO ............................................................. 32 4.1 PRINCPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE ............... 33 4.1.1 Elimine o desperdcio .................................................................................... 33 4.1.2 Amplifique o aprendizado .............................................................................. 33 4.1.3 Entregue o mais rpido possvel .................................................................. 33 4.1.4 Respeito .......................................................................................................... 34 4.1.5 Construa com integridade ............................................................................. 34 4.1.6 Visualize o todo .............................................................................................. 34 4.2 OS BENEFCIOS DO LEAN ................................................................................ 34 5 MODELO DE CUSTOMIZAO DO PROCESSO GIL PARA APLICAES WEB - WAAPRO ...................................................................................................... 37 5.1 O QUE WAAPRO?........................................................................................... 37 5.2 PLANEJAMENTO................................................................................................ 37 5.3 DESENVOLVIMENTO ......................................................................................... 38 5.4 FINALIZAO ..................................................................................................... 39
5.5 MANUTENO ................................................................................................... 40 6 ESTUDO DE CASO ............................................................................................... 42 6.1 O CLIENTE ......................................................................................................... 42 6.2 O PROJETO........................................................................................................ 42 6.3 PLANEJAMENTO................................................................................................ 43 6.3.1 Levantamento e Anlise de Requisitos ........................................................ 43 6.3.2 Proposta de desenvolvimento....................................................................... 46 6.3.3 Briefing ............................................................................................................ 47 6.3.4 Template.......................................................................................................... 47 6.4 DESENVOLVIMENTO ......................................................................................... 49 6.4.1 Coleta de contedo ........................................................................................ 50 6.4.2 Diagramao do Template ............................................................................. 50 6.4.3 Codificao ..................................................................................................... 50 6.5 FINALIZAO ..................................................................................................... 58 6.5.1 Reviso do Produto........................................................................................ 59 6.5.2 Apresentao do produto ao cliente ............................................................ 59 6.5.3 Entrega do produto ........................................................................................ 59 6.5.4 Treinamento .................................................................................................... 59 6.6 MANUTENO ................................................................................................... 60 7 CONCLUSO ........................................................................................................ 61 REFERNCIAS ......................................................................................................... 63 ANEXOS ................................................................................................................... 65
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 um conjunto 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 cuja complexidade no para de crescer.
Com a proposta de desenvolver projetos de maneira capaz de responder rpido 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 tempo manter pessoas motivadas dentro das corporaes (AKITA, 2009 apud TANIGUCHI; CORREA, 2009).
A partir da concepo das metodologias geis possvel criar um processo gil voltado para desenvolvimento de aplicaes web, que por sua vez, tm foco no
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 para o 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 o WAAPRO no desenvolvimento de um site.
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 cada funcionalidade, 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
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 desperdcio de 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 reunio com 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 funcionando corretamente, 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
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
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 preocupar com 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@PSI com 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
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 softwares onde 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 resolvlos 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
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 o quanto 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 valor ao 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 uma funcionalidade, por exemplo.
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 novas verses 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
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, uso de 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
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 saber um 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 evoluo da 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
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. Um fundamento dessa filosofia a manuteno da base desse conceito: equipes gerenciveis. A maioria dos livros aponta equipes de no mximo 9 pessoas, multidisciplinar e motivada. Mas inescapvel a existncia de projetos onde essa fora de trabalho tem de ser multiplicada, devido ao tamanho 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 incrementos devem 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
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
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 Login Fazer Cadastro Comprar Produto Validar Dados Dar Desconto
O usurio efetuar Login para ter acesso ao sistema O usurio faz seu cadastro no sistema. O usurio efetua a compra de um produto. Verificar se os dados do usurio j esto na base de dados e se esto corretos. O sistema valida a compra e fornece para o usurio um campo para inserir seu cdigo de desconto.
26
3.4.2 Diagrama de Classes
O Diagrama de Classes (figura 2) utilizado para modelar a viso esttica do projeto de um sistema. Nele mostra-se um conjunto de classes, interfaces e colaboraes e seus relacionamentos de dependncia, generalizao e associao (BOOCH; RUMBAUGH; JACOBSON, 2005). Tambm ajuda a visualizar a estrutura de classes antes de implement-las, e assim, corrigir eventuais erros. Cada classe funciona em colaborao com outras e no sozinhas, a fim de se fazer sentido.
Figura 2- Exemplo de Diagrama de Classes.
3.4.3 Diagrama ER
A partir do Diagrama de Classes (figura 2) pode ser feito um mapeamento das classes em tabelas atravs do Diagrama ER (figura 3), em que este representa o modelo relacional das tabelas. Dependendo do padro de codificao, com a base de dados pronta, fica mais simples codificar as classes do projeto. Porm, so necessrios ambos os diagramas para modelar as aplicaes web antes de qualquer codificao.
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
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
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 F001 Inserir/Alterar/Excluir Enquete. Todo comentrio deve gravar o IP do F002 usurio F003 Listar Notcias por Categoria Somente usurio nvel "Master" pode F004 cadastrar Novos usurios
Dificuld Prioridade ade Atendido Baixo Baixo No Alto Mdio Alto Baixo Mdio Alto Sim No Sim
Comentrios IP no deve ser exibido para usurio.
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
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
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
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 das pessoas a resistncia sendo assim, imposio nunca ser o melhor caminho. preciso abrir espao, dar as ferramentas adequadas e criar um ambiente 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 clientes e 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
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 apenas para 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 sistemtica de 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 um exerccio de reduo de variaes, e por essa razo, aprender a abordagem de desenvolvimento resulta em prticas que so bastante diferentes do que aprender 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
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 de uma 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 tem especialistas 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
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
equipe mais eficiente ao produzir aplicaes web que gerem valor de negcios para o cliente.
37
5 MODELO DE CUSTOMIZAO DO PROCESSO GIL PARA APLICAES WEB - WAAPRO
Diante da crescente necessidade de um processo de desenvolvimento gil voltado para aplicaes web, foi proposto um modelo capaz de suprir os objetivos dos desenvolvedores, no que diz respeito a uma melhor organizao dos projetos. A seguir, ser descrito o processo WAAPRO (Processo gil para
Desenvolvimento Aplicaes Web) e as caractersticas utilizadas do XP, SCRUM e P@PSI.
5.1 O QUE WAAPRO?
WAAPRO um processo gil customizado com o objetivo de tornar projetos de aplicaes web organizados, no que diz respeito aos ciclos de desenvolvimento e documentao utilizada, e ser de fcil aceitao para desenvolvedores com pouca ou nenhuma experincia no desenvolvimento de projetos utilizando metodologias geis. O WAAPRO dividido em quatro fases, Planejamento, Desenvolvimento, Finalizao e Manuteno, como mostra a figura 7. A seguir sero explicadas as fases do processo.
5.2 PLANEJAMENTO
A fase de Planejamento se inicia com o Levantamento e Anlise de Requisitos. Neste momento, ocorre a primeira entrevista com o cliente, onde este expe suas necessidades e seus objetivos com o desenvolvimento de uma aplicao web. extremamente importante a equipe levantar todas as informaes que possam ser utilizadas no decorrer do projeto. Com as informaes coletadas, a equipe comea a trabalhar nas estrias de usurio, ou seja, analisam cada situao proposta pelo cliente e as transformam em uma funcionalidade como, por exemplo, Cadastrar Notcia, representando atravs de um diagrama de caso de uso. Esse o incio da documentao do projeto. Com base nesses dados, elaborada uma Proposta de Desenvolvimento, que um documento que expressa todas as informaes do projeto, no que diz respeito ao tempo de desenvolvimento, funcionalidades a serem desenvolvidas, mdias e
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 template produzirem 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 a aplicao 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 template e 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 template se 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
codificao tem que ser simples e de fcil manuteno. Para isso, so utilizados alguns padres de desenvolvimento, como programao orientada a objetos, frameworks de desenvolvimento gil, padres de programao para uso de banco de dados, entre outros. Para cada cdigo escrito, so feitos testes, a fim de se certificar, que alm de estar funcionando devidamente, no possui problemas quando for relacionado com outros elementos da aplicao. Com a funcionalidade devidamente codificada, segue-se para a fase de implementao. Nesse momento, o cdigo vai ser integrado a outros, podendo ser, ao cdigo principal da aplicao. Em caso de erros, estes so corrigidos e vrios testes so feitos para que ao final do ciclo, a aplicao no apresente problemas. Para que no haja nenhuma falha, a funcionalidade ainda passa por mais testes, so os Testes de Funcionalidade. Nesse momento, a funcionalidade j est ativa na aplicao, mas necessrio certificar que tudo est em perfeita ordem para uso pelos usurios. Os testes servem para encontrar falhas, assim so simuladas as aes do usurio, caso seja encontrado algum erro, o ciclo no finalizado e retorna para a implementao, ou se necessrio, para a codificao da funcionalidade. Para finalizar o processo de Desenvolvimento, preciso fazer a integrao das mdias e contedo s funcionalidades. Por exemplo, seguindo o exemplo dado anteriormente com a funcionalidade Cadastrar notcia, os itens necessrios para cadastrar uma notcia seriam: texto, imagens, vdeos. Feito a insero desse material, a funcionalidade est concluda e o ciclo continua at que todos os casos de uso sejam concludos.
5.4 FINALIZAO
Na fase de Finalizao entende-se que o produto j est completo, necessitando apenas de reviso. Nesse primeiro momento, so realizados testes em todo o produto, testando cada funcionalidade e revisando todos os textos, bem como reviso ortogrfica nas palavras. Se tudo estiver pronto, o produto ento apresentado para o cliente. Caso, o cliente no esteja satisfeito com algum detalhe, o produto ento retorna para o Refinamento do Template (fase de Desenvolvimento), para que os detalhes possam ser reavaliados e as alteraes sejam feitas. No havendo nenhum questionamento por
40
parte do cliente, o produto ento entregue, sendo necessrio apenas o treinamento para utilizao da plataforma de administrao da aplicao web, quando necessrio.
5.5 MANUTENO
No modelo tradicional de desenvolvimento de software, o produto geralmente finalizado na fase de encerramento, no tendo uma fase que contemple a manuteno do mesmo. Porm, no desenvolvimento web, as mudanas so contnuas, e no se pode dizer que o produto est finalizado aps a entrega ao cliente e ao seu treinamento. Pois mesmo aps essas etapas, a aplicao pode sofrer mudanas. Para solucionar esse problema necessria uma fase de Manuteno. Nessa fase solicitada pelo cliente a alterao em alguma funcionalidade. Quando isso acontece, a funcionalidade volta para fase de Desenvolvimento, mais especificadamente para a etapa Refinar Template, passando pelo ciclo de desenvolvimento completo, depois para reviso da alterao, na fase de Finalizao, at a apresentao da alterao para o cliente. Assim, pode-se dizer que a manuteno uma consequncia da entrega do produto, porm cada mudana solicitada termina na fase de Finalizao, porque passa por todas as etapas dessa fase em um ciclo contnuo.
Figura 7 - Viso geral do WAAPRO
Fonte: Arquivo Pessoal, 2012.
40
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 <http://www.portalguarany.com.br>.
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 de credibilidade 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
Portal de contedo da Rdio e Televiso Record S/A.
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 a atualidade. 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 usurio pudesse 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
Diagrama de Caso de Uso, que serviu para melhorar a visualizao de todos os recursos que o site poderia oferecer. A figura 8 mostra as funcionalidades exibidas para os usurios, ou seja, o front-end4 do site.
Figura 8 - Diagrama de Caso de Uso do Portal Guarany.
Para que o diagrama fique mais bem explicado, esto descritos todos os casos de uso (quadro 3).
Quadro 3 - Descrio dos Casos de Uso do Portal Guarany.
Comentar Mural de Recados
Visualizar Notcias
Comentar Rdio Interativo
Apresenta as mensagens enviadas de um usurio para outro. Exibe as notcias de todas as categorias em ordem de postagem. Todas as notcias tem formulrio para postagem de comentrios com moderao pelo administrador. Uma pergunta com opo para o usurio comentar com os campos: nome, bairro e comentrio. O comentrio s fica visvel aps a
rea pblica visualizada pelo usurio de um site.
45
liberao pelo administrador. Exibe o programa da rdio transmitido no momento e uma foto do apresentador. Tambm exibe um link para o usurio ouvir o programa on-line. Link externo para o usurio ouvir a rdio on-line. Exibe postagens da conta @portalguarany no Twitter. Exibe notcias do Portal R7. Exibe fotos separadas por galerias (lbuns).
Visualizar Programao ao vivo
Ouvir Rdio on-line Visualizar Feed Twitter Visualizar Feed Portal R7 Visualizar Galeria de fotos
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 Master teria acesso apenas liberao de contedo, no podendo cadastrar novos usurios, por exemplo.
Figura 9 - Diagrama de Caso de Uso do Sistema de Administrao do Portal Guarany.
46
Quadro 4 - Descrio dos Casos de Uso do Sistema de Administrao do Portal Guarany.
Manter Notcias Manter Administrador Manter Destaque
Manter Programao ao vivo
Manter Galeria de fotos
Manter Rdio Interativo
Manter Publicidade Manter Mural de recados Fazer Login

Possibilita inserir, alterar, excluir e consultar notcias publicadas. Possibilita inserir, alterar, excluir os administradores do site. Possibilita inserir, alterar e excluir imagens em destaque na pgina inicial (slideshow) do site. Possibilita inserir, alterar, excluir e consultar os programas da Rdio Gurany FM. Possibilita inserir, alterar, excluir e consultar galerias de fotos publicadas no site. Possibilita consultar, publicar e excluir comentrios publicados pelos ouvintes. Alm de poder inserir, alterar status e excluir as perguntas. Possibilita inserir e excluir as publicidades do site. Possibilita publicar e excluir comentrios feitos pelos internautas do site. atravs desta funcionalidade que o administrador pode ser acesso ao sistema administrativo.
6.3.2 Proposta de desenvolvimento
Nesta etapa foi elaborada uma proposta de desenvolvimento (ver anexo A), que visa mostrar para o cliente quais funcionalidades seriam desenvolvidas e o que elas fariam (como exemplificado no Quadro 4), alm de tempo e custo total de desenvolvimento. Sabendo que o site iria ter pginas informativas e estticas, como contedo sobre a empresa, servios, rea comercial e formulrio de contato, esses itens foram inseridos na proposta. Algo muito importante a verificao de disponibilidade do domnio do site. O domnio deveria ser portalguarany.com.br, que foi verificado e comprado junto ao site Registro.br, responsvel pelo registro de domnios brasileiros.
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 wireframe s representa a disposio do layout e pode ser visto abaixo, na figura 10.
Figura 10 - Wireframe da pgina inicial do Portal Guarany.
48
A partir do wireframe o 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
Tambm necessrio criar o layout para o sistema de administrao do site, como mostra a figura 12. Nesse caso, no foi necessrio passar pela aprovao do cliente, pois essa parte do sistema apenas foi adaptada para o site Portal Guarany, uma vez que a tecnologia licenciada pela W3Mais Comunicao Interativa mediante contrato. Isso gera um ganho de tempo na incluso e excluso de funcionalidades no desenvolvimento de novas aplicaes.
Figura 12 - Sistema de Administrao do Portal Guarany.
6.4 DESENVOLVIMENTO
O projeto Portal Guarany possui muitas funcionalidades, portanto foi necessrio priorizar algumas para iniciar a fase de desenvolvimento. O WAAPRO permitiu ao projeto ser feito em mdulos. Neste trabalho apresentado, na etapa de codificao, o mdulo que consiste em trs funcionalidades, sendo elas: Mural de Recados, Notcias e Rdio Interativo. Na etapa de desenvolvimento foi testado um princpio do Lean que adotar medidas preventivas em tudo o que feito, como um ciclo onde se planeja, executa, verifica e faz algo funcionar, seja um cdigo ou uma funcionalidade inteira.
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 como orientao 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.
Elemento HTML que define uma diviso na pgina e pode ter variadas formataes.
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
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
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
Figura 17 - Diagrama ER - Rdio Interativo.
Fonte: Arquivo pessoal, 2012. 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
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 Rdio Interativo 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 concordou que 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
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 de sequncia pode ser vista na figura 20.
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
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
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 sua hospedagem 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
6.6 MANUTENO
A fase de Manuteno existiu nesse projeto apenas para edio de alguns textos em pginas estticas e manuteno de funcionalidades e do banco de dados que vez ou outra ocorria erros. Dessa forma, qualquer item a ser mudado no site passava por todo o processo de Desenvolvimento at a Finalizao.
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 ar durante 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, pois toda 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 de desenvolvimento. 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 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 como um
62
projetos, assim pde-se ter um feedback quanto s vantagens do processo gil junto com o processo enxuto Lean em uma empresa. O resultado foi positivo, a equipe conseguiu assimilar a ideia, porm levou bastante tempo. No foi possvel verificar o lead time6 em todas as etapas, pois no tinha como comparar com outro estudo de caso ou outro projeto feito a partir do WAAPRO. Assim, o WAAPRO foi customizado para ser um processo simples de ser utilizado por equipes inexperientes, mas que tenham interesse por um processo para organizar e gerenciar melhor o desenvolvimento de uma aplicao web. importante ressaltar que para que um processo gil se torne eficiente precisa partir de uma mudana de cultura numa empresa ou na equipe de desenvolvimento. O Lean sugere principalmente para empresas pequenas, uma srie de princpios e recursos para que desenvolvedores possam adquirir conhecimento para aplicar junto com um processo gil no decorrer de um projeto. Portanto, a fim de evitar desperdcios, fazer somente o necessrio quando for necessrio e ter uma organizao e gerenciamento melhor dos projeto web, o WAAPRO surge com essa alternativa. Mesmo tendo sido visto superficialmente como forma de introduzir o processo e gerar conhecimento para a equipe, com o Lean pde-se comprovar uma melhora no dilogo e na percepo de erros antes da implementao ou mudana de requisito. Ainda necessrio um aprofundamento na viso Lean para verificar as reais mudanas dentro de uma empresa que utiliza um processo gil como o WAAPRO, a fim de verificar em que pontos ela se torna realmente enxuta. Neste trabalho a nica etapa testada foi o Desenvolvimento, tendo resultados positivos. So necessrios mais testes com WAAPRO no desenvolvimento de aplicaes web, para se ter uma ideia se todas as etapas funcionam e o que precisa ser melhorado, a partir da viso de outros desenvolvedores. Espera-se, que a partir deste trabalho apresentado sobre a utilizao de metodologias geis na customizao do processo web WAAPRO, possam surgir projetos relacionados com o tema. Pois o mesmo oferece muitos benefcios para os desenvolvedores que queiram manter seus projetos enxutos.
Tempo em que se recebe um requisito at a entrega da funcionalidade.
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 Cincias Exatas da Universidade Federal de Minas Gerais. Belo Horizonte, 2001. Disponvel em: <http://homepages.dcc.ufmg.br/~wilson/pesquisa/DissertacaoPatricia.pdf>. Acesso em 08 dez. 2011. BECK, Kent. Programao Extrema (XP) explicada: Acolha as mudanas. Porto Alegre: Bookman, 2004. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. 6 ed. Rio de Janeiro: Elsevier, 2005. CRESCNDIO, Samuel. A Pirmide Lean: O equilbrio das Foras geis. Edio 38. Devmedia Group, 2011. Disponvel em: <http://www.devmedia.com.br/esmag>. Acesso em 28 abr. 2012. ISSN 1983127-7. DAVIDSON, Edgard. Princpios do Pensamento Lean. Disponvel em: <http://edgarddavidson.com/?p=1070>. Acesso em 23 nov. 2011. DE CARVALHO, Bernardo Vasconcelos. Aplicao do mtodo gil Scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnolgica. 2009. 100p. Dissertao (Mestrado em Engenharia de Produo). Universidade Federal de Itajub, Itajub, 2009. Disponvel em: <http://adm-net-a.unifei.edu.br/phl/pdf/0034997.pdf>. Acesso em 25 nov. 2011. DINHEIRAMA ONLINE. Dinheirama Gerenciador de Contedo Financeiro. Disponvel em: <https://www.dinheiramaonline.com.br>. Acesso em: 28 abr. 2012. GELLER, Marla; KNEBEL, Clvis; BENTES JNIOR, Joo. GTA Grupo de Trabalho gil Desenvolvimento gil de Software atravs da customizao de processos. III Congresso Sul Catarinense de Computao. Cricima SC, 2007. GOLALVES, Geraldo Magela Dutra. A gerncia de projetos de software em duas perspectivas Parte 2: Scrum. Edio 38. Devmedia Group, 2011. Disponvel em: <http://www.devmedia.com.br/esmag>. Acesso em 28 abr. 2012. ISSN 1983127-7. JACYNTHO, Mark Douglas de Azevedo. Processos para Desenvolvimento de Aplicaes Web. 2008. 25p. Monografias em Cincia da Computao Rio de Janeiro, Pontifcia Universidade Catlica. 2008. Disponvel em: <ftp://ftp.inf.puc-rio.br/pub/docs/techreports/09_23_jacyntho.pdf>. Acesso em 02 jun. 2012. LUNA, Alexandre; COSTA, Cleyverson; DE MOURA, Hermano. A necessidade de ser gil: Uma anlise crtica sobre nove mtodos geis. Edio 27. Devmedia
64
Group, 2011. Disponvel em: <http://www.devmedia.com.br/esmag>. Acesso em 28 abr. 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: <http://www.devmedia.com.br/esmag>. Acesso em 23 abr. 2012. ISSN 1983127-7. PORTAL GUARANY. Sistema Guarany de Comunicao. Disponvel em <http://portalguarany.com.br/sgc.php>. Acesso em 26 mai. 2012. SATO, Danilo. Introduo Programao Extrema (XP). Engenharia de Software Magazine. Edio 10. Devmedia Group, 2009. Disponvel em: <http://www.devmedia.com.br/esmag>. Acesso em 22 abr. 2012. ISSN 1983127-7. SOARES, Michel dos Santos. Comparao entre Metodologias geis Tradicionais para o Desenvolvimento de Software. Infocomp: Jornal of Computer Science. v 3, n 2, nov. 2004. Disponvel em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em 25 nov. 2011. TANIGUCHI, Kenji; CORREA, Fernando Eugenio. Metodologias geis e a Motivao de Pessoas em Projetos de Desenvolvimento de Software: Aplicando prticas de SCRUM e XP para promover a motivao de equipes de projetos de desenvolvimento de software. So Paulo, v. 4, n. 4, 2009. Disponvel em: <http://sare.unianhanguera.edu.br/index.php/rcext/article/viewFile/1612/953>. Acesso em 02 jun. 2012. TELES, Vincius Manhes. Um Estudo de Caso da adoo das prticas e valores do Extreme Programming. 2005. 179p. Dissertao (Mestrado em Informtica) Universidade Federal do Rio de Janeiro, Ncleo de Computao Eletrnica, Rio de Janeiro, 2005. Disponvel em: <http://www.improveit.com.br/xp/dissertacaoXP.pdf>. Acesso 21 nov. 2011. WAITEMAN, Flvio. Manual Prtico de Criao Publicitria: O dia-dia da Criao em uma Agncia. So Paulo: Nobel, 2006. p 38. ISBN 85-213-1309-8.
65
ANEXOS
66
ANEXO A PROPOSTA DE DESENVOLVIMENTO PORTAL GUARANY
Agncia: Cliente:
W3MAIS COMUNICAO INTERATIVA 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 site www.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 Principal SGC Notcias Servios Participe Fotos Comercial Fale conosco Rdio Interativo Mural de Recados Funo Pgina inicial com chamadas para as principais sees do site. Apresenta descrio da empresa incluindo misso, viso e valores. Lista todas as notcias em ordem de publicao. Apresenta todos os servios teis para os usurios (ex: nmero do telefone do CIOP, Hospital Regional, PSM, Bancos, etc). Lista links Mural de Recados, Rdio Interativo e Redes Sociais. Lista as galerias de fotos dos eventos da empresa. Seo destinada para apresentao das empresas do grupo SGC e informaes para anunciantes. Exibe as formas de contato da empresa: telefones, e-mails e endereo. Interao com os usurios atravs de uma pergunta principal com opo para comentrios. Interao entre usurios por meio de comentrios,
67
Programao
Exibe o programa que est sendo transmitido no momento em que usurio est acessando o site.
III INVESTIMENTO
Desenvolvimento Opes de parcelamento R$
Valor Total R$
Administrao (valor) mensal com os seguintes servios inclusos: Painel administrativo para cadastro, excluso ou edio de contedo; Hospedagem do site; Relatrio de visitas; Monitoramento do site; 05 Contas de e-mail personalizado (nome@nomedosite.com.br); Suporte tcnico em horrio comercial sempre que solicitado;
O prazo para desenvolvimento e publicao do site de 45 (quarenta e cinco) dias. Santarm PA, 17 de Novembro de 2011 W3mais Comunicao Interativa Ltda. E-mail: atendimento@w3mais.com.br Telefones: (93) 3522.5689 / 9131.1989
Obs.: Esta proposta vlida por 10 (dez) dias
68
ANEXO B BRIEFING PARA CRIAO DO TEMPLATE DO PORTAL GUARANY
Agncia: Cliente:
W3MAIS COMUNICAO INTERATIVA PORTAL GUARANY
Briefing para criao do template do Portal Guarany.
1. Sobre o cliente O Portal Guarany o terceiro elemento do Sistema Guarany de Comunicao que envolve Rdio, TV e Portal. 2. Servios oferecidos Notcias das cidades, Programao da TV Guarany e Interatividade com a rdio. 3. Referncia de sites (outras empresas) http://www.baladain.com.br/ (ver formato como os parceiros so exibidos). http://www.baladacerta.com.br/ 4. Pblico alvo Todas as idades 5. O site vai ter os seguintes itens no menu Principal, SGC, Notcias, Servios, Participe, Fotos, Comercial, Fale Conosco. 6. Informaes importantes sobre a pgina inicial do site - No topo do site deve ter um boto Oua ao Vivo a Rdio Guarany - Banner com revezamento do mesmo tamanho de http://rederecord.r7.com/ e com o mesmo formato: Foto + Ttulo dentro da foto. - Notcias: Lista as ltimas 5 notcias com foto. - 1 Banner Publicitrio do tipo retngulo. - Mural de Recados: Exibe os ltimos dois recados do mural. - Rdio Interativo: uma enquete com perguntas. Ex: O que voc acha da situao das ruas de Santarm? Voc acha que est faltando mais ateno dos governantes?. E em seguida coloca dos botes. 1- D sua opinio 2- Leia os comentrios. - Fotos: Exibe uma galeria de fotos.
69
- Twitter: Exibe os dois ltimos posts do twitter parecido com o que tem em www.saoraimundo.com.br - No rodap deve ter os logotipos do Sistema Guarany de Comunicao, da TV Guarany (afiliada a Rede Record Logotipo), Rdio Guarany. 7. Cores Pode manter as cores do site anterior. Background: #F9F9FC; Menu: #667E00; Ttulos: cores sortidas em cada seo. 8. Imagem a ser transmitida para os usurios Jovialidade e alegria (sem ser infantil).

Utilização de Metodologias Ágeis para Adaptação de Um Processo de Desenvolvimento de Aplicações Web

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Utilização de Metodologias Ágeis para Adaptação de Um Processo de Desenvolvimento de Aplicações Web

Загружено:

Авторское право:

Доступные форматы

CENTRO UNIVERSITRIO LUTERANO DE SANTARM CURSO DE SISTEMAS DE INFORMAO FELIPE DOS SANTOS NASCIMENTO

UTILIZAO DE METODOLOGIAS GEIS PARA ADAPTAO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAES WEB

FELIPE DOS SANTOS NASCIMENTO

UTILIZAO DE METODOLOGIAS GEIS PARA ADAPTAO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAES WEB

FELIPE DOS SANTOS NASCIMENTO

UTILIZAO DE METODOLOGIAS GEIS PARA ADAPTAO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAES WEB

Data de Apresentao: _____/_____/_____

2 VISO GERAL DO DESENVOLVIMENTO DE UMA APLICAO WEB

2.1 INCIO DO PROJETO

3 METODOLOGIAS GEIS UTILIZADAS NA CUSTOMIZAO DO PROCESSO WEB WAAPRO

3.1 PROCESSOS CUSTOMIZADOS PARA APLICAES WEB

3.2 PROGRAMAO EXTREMA (XP)

3.2.2 Entregas Frequentes

3.2.3 Projeto Simples

3.2.7 Contrato de escopo negocivel

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

3.3.2 Produto Total

Fonte: Arquivo pessoal, 2012.

3.4.2 Diagrama de Classes

Fonte: Arquivo pessoal, 2012.

Fonte: Arquivo pessoal, 2012.

3.4.4 Diagrama de Sequncia

Figura 4 - Exemplo de Diagrama de Sequncia.

Fonte: GELLER, 2012.2

3.5 OUTROS RECURSOS PARA DOCUMENTAO NO WAAPRO

Comentrios IP no deve ser exibido para usurio.

3.4.2 Documento de Design Funcional

Figura 5 - Wireframe da pgina inicial de um site.

Fonte: Arquivo pessoal, 2012.

Figura 6 - Template da aplicao web Dinheirama Online

Fonte: DINHEIRAMA ONLINE, 2012.

4 APLICAO DO LEAN NO PROCESSO

4.1 PRINCPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE

4.1.1 Elimine o desperdcio

4.1.3 Entregue o mais rpido possvel

4.1.5 Construa com integridade

4.2 OS BENEFCIOS DO LEAN

5 MODELO DE CUSTOMIZAO DO PROCESSO GIL PARA APLICAES WEB - WAAPRO

Desenvolvimento Aplicaes Web) e as caractersticas utilizadas do XP, SCRUM e P@PSI.

5.1 O QUE WAAPRO?

Figura 7 - Viso geral do WAAPRO

Fonte: Arquivo Pessoal, 2012.

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

Fonte: Arquivo pessoal, 2012.

Comentar Mural de Recados

Comentar Rdio Interativo

rea pblica visualizada pelo usurio de um site.

Visualizar Programao ao vivo

Fonte: Arquivo pessoal, 2012.

Quadro 4 - Descrio dos Casos de Uso do Sistema de Administrao do Portal Guarany.

Manter Notcias Manter Administrador Manter Destaque

Manter Programao ao vivo

Manter Galeria de fotos

Manter Rdio Interativo

Manter Publicidade Manter Mural de recados Fazer Login

6.3.2 Proposta de desenvolvimento

Fonte: Arquivo pessoal, 2012.

Fonte: Arquivo pessoal, 2012.

Fonte: Arquivo pessoal, 2012.

6.4.1 Coleta de contedo

Fonte: Arquivo pessoal, 2012.

Figura 14 - Diagrama de Classe da funcionalidade Rdio Interativo

Fonte: Arquivo pessoal, 2012.

Data de Apresentao: ___/_/___