SlideShare uma empresa Scribd logo
1 de 69
Baixar para ler offline
CENTRO UNIVERSITÁRIO LUTERANO DE SANTARÉM
          CURSO DE SISTEMAS DE INFORMAÇÃO

            FELIPE DOS SANTOS NASCIMENTO




UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM
    PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB




                      SANTARÉM
                        2012
FELIPE DOS SANTOS NASCIMENTO




UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM
    PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB




                        Trabalho    de     Conclusão     de   Curso
                        apresentado para obtenção do Grau de
                        Bacharel em Sistemas de Informação pelo
                        Centro Universitário Luterano de Santarém.

                        Orientadora: Profª. Msc. Marla Teresinha
                        Barbosa Geller




                      SANTARÉM
                        2012
FELIPE DOS SANTOS NASCIMENTO




UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM
    PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB




                            Trabalho    de     Conclusão     de   Curso
                            apresentado para obtenção do Grau de
                            Bacharel em Sistemas de Informação pelo
                            Centro Universitário Luterano de Santarém.




           Data de Apresentação: _____/_____/_____




    _________________________________         ___________
                                                Conceito


    _________________________________         ___________
                                                Conceito


    _________________________________         ___________
                                                Conceito
Esta obra é dedicada a toda minha família,
em especial aos meus pais Gilson e Luzia,
minha irmã Fernanda e meus professores e
amigos    que    contribuíram   no    meu
aprendizado      enquanto       acadêmico.
AGRADECIMENTOS


     Primeiramente a Deus que me deu forças, estrutura e entendimento ao longo
dessa trajetória.


     A minha família, em especial aos meus pais e irmã, que sempre me apoiaram,
dando o máximo para que eu pudesse atingir meus objetivos.


     A minha orientadora professora Marla Geller pelo apoio e confiança e por ter
contribuído grandemente com sua experiência e didática neste trabalho.


     Ao Júnior Tapajós, Diretor Comercial da W3Mais Comunicação Interativa, por
ter me dado a oportunidade de alcançar um dos meus objetivos de trabalhar com
desenvolvimento web, além de ter contribuído indiretamente com este trabalho.


     A todos os meus amigos e colegas pelo incentivo e colaboração no decorrer
deste trabalho.
Não devemos ter medo dos confrontos.
Até os planetas se chocam e do caos
nascem as estrelas.
                          Charles Chaplin
RESUMO


Com a crescente demanda por aplicações web e a dificuldade de empresas que
trabalham com esse tipo de serviço, de manter um processo organizacional e
gerencial no decorrer do desenvolvimento de um produto, de forma a criar somente
o necessário quando for preciso, muitas tem adotado metodologias ágeis. Porém,
seguem o mesmo padrão do desenvolvimento de software, o que ainda gera
transtornos, pois muitas vezes as equipes não 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 específico para o desenvolvimento de
aplicações web. O WAAPRO (Processo Ágil para Desenvolvimento de Aplicações
Web) utiliza fundamentos de metodologias ágeis como XP, Scrum e P@PSI, porém
direcionadas para web. Além de utilizar princípios do Lean, que visa mudar a cultura
das equipes de desenvolvimento no que diz respeito ao desenvolvimento enxuto.
Para validação do processo ágil WAAPRO foi realizado um estudo de caso, através
do desenvolvimento do Portal Guarany, para mostrar a utilização do processo ágil.

Palavras-chave: Metodologia Ágil. Customização de Processo. Aplicação 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 ILUSTRAÇÕES


Figura 1 - Exemplo de Diagrama de Caso de Uso .................................................... 25
Quadro 1 - Descrição 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 Sequência. ....................................................... 28
Figura 5 - Wireframe da página inicial de um site. .................................................... 30
Quadro 2 - Exemplo de uma Planilha de Requisitos ................................................. 29
Figura 6 - Template da aplicação web Dinheirama Online ........................................ 31
Figura 7 - Visão geral do WAAPRO .......................................................................... 41
Figura 8 - Diagrama de Caso de Uso do Portal Guarany. ....................................... 44
Quadro 3 - Descrição dos Casos de Uso do Portal Guarany. ................................... 44
Figura 9 - Diagrama de Caso de Uso do Sistema de Administração do Portal
Guarany..................................................................................................................... 45
Quadro 4 - Descrição dos Casos de Uso do Sistema de Administração do Portal
Guarany..................................................................................................................... 46
Figura 10 - Wireframe da página inicial do Portal Guarany. ...................................... 47
Figura 11 - Template do site Portal Guarany............................................................. 48
Figura 12 - Sistema de Administração do Portal Guarany......................................... 49
Figura 13 - Diagrama de Classe da funcionalidade Notícia....................................... 51
Figura 14 - Diagrama de Classe da funcionalidade Rádio Interativo ......................... 52
Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados ..................... 52
Figura 16 - Diagrama ER - Notícia. ........................................................................... 53
Figura 17 - Diagrama ER - Rádio Interativo. ............................................................. 54
Figura 18 - Diagrama ER - Mural de Recados. ......................................................... 54
Figura 19 - Diagrama de Sequência da ação comentar Notícia ................................ 56
Figura 20 - Diagrama de Sequência da ação comentar Rádio Interativo .................. 57
Figura 21 - Diagrama de Sequência da ação de enviar recado através do Mural de
Recados .................................................................................................................... 58
SUMÁRIO


1 INTRODUÇÃO ....................................................................................................... 12
2 VISÃO GERAL DO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB ............. 14
2.1 INÍCIO DO PROJETO ......................................................................................... 14
2.2 PROGRAMAÇÃO ................................................................................................ 15
2.3 FINALIZAÇÃO ..................................................................................................... 15
2.4 MANUTENÇÃO ................................................................................................... 15
3 METODOLOGIAS ÁGEIS UTILIZADAS NA CUSTOMIZAÇÃO DO PROCESSO
WEB WAAPRO ......................................................................................................... 17
3.1 PROCESSOS CUSTOMIZADOS PARA APLICAÇÕES WEB ............................ 17
3.2 PROGRAMAÇÃO 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 Programação em Pares .................................................................................. 21
3.2.6 Propriedade Coletiva...................................................................................... 22
3.2.7 Contrato de escopo negociável .................................................................... 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 Sequência ................................................................................. 27
3.5 OUTROS RECURSOS PARA DOCUMENTAÇÃO NO WAAPRO ...................... 28
3.4.1 Planilha de Requisitos ................................................................................... 28
3.4.2 Documento de Design Funcional .................................................................. 29
3.4.3 Template.......................................................................................................... 30
4 APLICAÇÃO DO LEAN NO PROCESSO ............................................................. 32
4.1 PRINCÍPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE ............... 33
4.1.1 Elimine o desperdício .................................................................................... 33
4.1.2 Amplifique o aprendizado .............................................................................. 33
4.1.3 Entregue o mais rápido possível .................................................................. 33
4.1.4 Respeito .......................................................................................................... 34
4.1.5 Construa com integridade ............................................................................. 34
4.1.6 Visualize o todo .............................................................................................. 34
4.2 OS BENEFÍCIOS DO LEAN ................................................................................ 34
5 MODELO DE CUSTOMIZAÇÃO DO PROCESSO ÁGIL PARA APLICAÇÕES
WEB - WAAPRO ...................................................................................................... 37
5.1 O QUE É WAAPRO?........................................................................................... 37
5.2 PLANEJAMENTO................................................................................................ 37
5.3 DESENVOLVIMENTO ......................................................................................... 38
5.4 FINALIZAÇÃO ..................................................................................................... 39
5.5 MANUTENÇÃO ................................................................................................... 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 Análise 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 conteúdo ........................................................................................ 50
6.4.2 Diagramação do Template ............................................................................. 50
6.4.3 Codificação ..................................................................................................... 50
6.5 FINALIZAÇÃO ..................................................................................................... 58
6.5.1 Revisão do Produto........................................................................................ 59
6.5.2 Apresentação do produto ao cliente ............................................................ 59
6.5.3 Entrega do produto ........................................................................................ 59
6.5.4 Treinamento .................................................................................................... 59
6.6 MANUTENÇÃO ................................................................................................... 60
7 CONCLUSÃO ........................................................................................................ 61
REFERÊNCIAS ......................................................................................................... 63

ANEXOS ................................................................................................................... 65
12



1 INTRODUÇÃO


     Com o crescimento do número de empresas que produzem negócios para seus
clientes na internet, e consequentemente, o grande envolvimento de profissionais da
área, torna-se necessário encontrar uma maneira de gerenciar o trabalho desses
profissionais a fim de gerar produtos de qualidade que agreguem valor ao negócio
do cliente. Lidar com pessoas, e nesse caso, clientes, é uma tarefa difícil, pois as
mudanças que ocorrem no que se refere a características e requisitos do sistema,
durante o desenvolvimento de aplicações web afetam os custos, prazos e muitas
vezes a qualidade do produto. Para acompanhar essas mudanças é preciso uma
organização. É nesse aspecto que a modelagem ágil ajuda os desenvolvedores e,
também, o cliente a compreender o escopo do produto antes, durante e após a
finalização do mesmo. É preciso entregar um produto que satisfaça as necessidades
do cliente, afinal, esse é o primeiro objetivo do desenvolvimento de software.
     A utilização 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 são executadas por atores que desempenham um papel no processo
(programador, gerente, cliente, etc.). O resultado das atividades são artefatos
(código, documentação, 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 aplicações web modernas cuja
complexidade não para de crescer.


                     Com a proposta de desenvolver projetos de maneira capaz de responder
                     rápido às mudanças, com foco nas pessoas e na colaboração com o cliente,
                     surgiram as metodologias ágeis que, devido às suas características,
                     possibilitam gerar produto com maior valor agregado e ao mesmo tempo
                     manter pessoas motivadas dentro das corporações (AKITA, 2009 apud
                     TANIGUCHI; CORREA, 2009).


     A partir da concepção das metodologias ágeis é possível criar um processo ágil
voltado para desenvolvimento de aplicações web, que por sua vez, têm foco no
13



produto em si, ou seja, sendo mais importante entregar algo de qualidade sem se
prender em intermináveis documentos, eliminando desperdícios e desenvolvendo
somente o necessário e quando necessário. Pois, assim como no desenvolvimento
de software tradicional, aplicações web estão constantemente sofrendo mudanças
durante e após sua implementação, trabalhando assim com releases iterativos e
incrementais de entrega.
     Segundo Bohem e Turner (2004 apud JACYNTHO, 2008) não existe um
processo correto ou incorreto, tanto processos rigorosos quanto processos ágeis,
ambos têm suas vantagens e desvantagens. Ou seja, é preciso encontrar um ponto
de equilíbrio entre as duas abordagens para cada tipo de projeto, e assim definir um
processo híbrido que traga benefícios reais.
     Diante da necessidade de um processo de desenvolvimento voltado para
ambientes e aplicações web, será mostrado neste trabalho um processo ágil
customizado a partir de metodologias ágeis já existentes, sendo elas: Programação
Extrema (XP), Scrum e P@PSI. Este trabalho também cita o conceito Lean, uma
metodologia voltada para o desenvolvimento de produtos de forma a eliminar
desperdícios 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 capítulos, onde após a introdução o segundo
capítulo apresenta uma visão geral do desenvolvimento de uma aplicação web, o
terceiro capítulo apresenta as metodologias ágeis utilizadas na customização do
processo web WAAPRO, o quarto capítulo mostra a aplicação do Lean no processo
proposto, o capítulo cinco exemplifica o modelo de customização do WAAPRO e o
capítulo seis apresenta um estudo de caso utilizando como processo ágil o
WAAPRO no desenvolvimento de um site.
14



2 VISÃO GERAL DO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB


     O tópico a seguir descreve a experiência do autor no desenvolvimento de
aplicações web e o processo utilizado desde o início de um projeto, passando pela
finalização até a manutenção após entrega do produto ao cliente.


2.1 INÍCIO DO PROJETO


     O projeto de desenvolvimento de uma aplicação web se inicia com uma reunião
preliminar com o cliente, a fim de se obter informações sobre a real necessidade
para se criar o produto. Neste primeiro momento, é decidido o tipo de produto,
podendo variar desde um website informativo, apresentando informações 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 são sites pequenos e específicos para um determinado evento ou ação
publicitária. E, também, sistemas on-line, como grandes portais de conteúdo que
possuem diversas funcionalidades.
     Definido o tipo de aplicação 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 aplicação irá
conter.
     Com essas informações em mãos é, então, elaborada uma proposta de
desenvolvimento, contendo todas as informações necessárias para iniciar o
desenvolvimento do produto. Esta proposta inclui informações detalhadas de cada
funcionalidade, as páginas que serão criadas, custo total do projeto, tempo de
desenvolvimento e, também o que não será produzido, pois após o contrato fechado
o que for solicitado como mudança fora do escopo não fará parte do valor fixado no
contrato, este sofrerá um acréscimo.
     Esta proposta é apresentada ao cliente. Caso haja algum item em
discordância, este tem a total liberdade de pedir a reformulação até chegar a um
ponto comum com a equipe responsável pelo desenvolvimento da aplicação web.
Sendo a proposta aprovada, o início do desenvolvimento dá-se pela criação do
layout baseado nas informações previamente coletadas. O layout baseia-se,
15



principalmente, na harmonia de cores e localização das informações. A equipe
responsável tem total liberdade para criar algo dentro dos padrões web de
usabilidade e, posteriormente, esse layout passa pela aprovação do cliente.


2.2 PROGRAMAÇÃO


     Uma vez que o layout é finalizado, e o cliente se satisfaça com a localização de
cada funcionalidade e informação que a aplicação irá conter, inicia-se o processo de
programação, ou seja, a codificação dos requisitos. Durante esta etapa os requisitos
podem sofrer alterações, fazendo-se necessário o uso de padrões web de
programação que facilitam a manutenção dos códigos a fim de se evitar desperdício
de tempo.


2.3 FINALIZAÇÃO


     Após a finalização da programação de toda a aplicação, esta é testada por
completo localmente (off-line), e depois é enviada para um servidor on-line para
testes finais. Caso existam falhas, estas são corrigidas, senão, uma nova reunião
com o cliente é realizada para apresentação do produto final. Se aprovada, a
aplicação fica disponível para o público geral, senão volta para a etapa de
programação.


2.4 MANUTENÇÃO


     No desenvolvimento web, após a entrega da aplicação funcionando
corretamente, se inicia mais uma etapa, que é a manutenção do mesmo. Esta etapa
engloba desde a atualização do conteúdo, layout e até mesmo mudanças nos
requisitos iniciais, como a inclusão de novas funcionalidades.
     Essa fase de Manutenção deve ser especificada em contrato de forma
coerente, pois o cliente pode eventualmente achar que pode requerer qualquer
mudança após a finalização do projeto, o que é um equívoco. O desenvolvedor irá
realizar qualquer mudança no escopo descrito em contrato, caso seja acrescentada
uma nova funcionalidade, o valor do projeto passa por um reajuste. Para isso, há
uma negociação prévia com o cliente, para que fique tudo bem claro. É importante
16



ressaltar, que qualquer manutenção solicitada pelo cliente passa pelo gerente de
projetos primeiro. Ele, junto com a equipe de desenvolvimento analisa o que pode
ser feito e as consequências de tal mudança antes de entrar em processo de
implementação. Nem todas as alterações poderão ser realizadas após a finalização
do projeto, pois podem comprometer muitas funções. Por isso é importante uma
análise de requisitos bem criteriosa, no início do desenvolvimento do projeto.
17



3 METODOLOGIAS ÁGEIS UTILIZADAS NA CUSTOMIZAÇÃO DO PROCESSO
WEB WAAPRO


     Metodologias ágeis são vistas como as melhores alternativas às abordagens
tradicionais de desenvolvimento de software. Uma vez que métodos tradicionais
surgiram em um contexto de desenvolvimento de software baseado apenas em um
mainframe e terminais burros (ROYCE, 1970 apud SOARES, 2004), onde não
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 compõe os projetos, principalmente, desenvolvedores e
clientes. A partir disso, houve uma melhoria no processo de codificação, passando a
ser guiado por testes e utilizando de forma mais eficiente as práticas da Engenharia
de Software.
     Este capítulo se divide na breve descrição de alguns processos customizados
para desenvolvimento de aplicações web, e algumas das principais metodologias
ágeis utilizadas no desenvolvimento de software, sendo elas, o Scrum, XP e P@PSI
com foco na implantação em ambientes que ainda não utilizam metodologias ágeis
como parte do processo de desenvolvimento de software. Essas metodologias
serviram de base para a customização do Processo Ágil para Desenvolvimento de
Aplicações Web, denominado WAAPRO.


3.1 PROCESSOS CUSTOMIZADOS PARA APLICAÇÕES WEB


     Existem algumas propostas de processos voltados para aplicações web, como
o XWebProcess que foi criado adaptando elementos do XP para lidar com
importantes questões de sistemas web, tais como: interfaces com usuário
complexas, navegação, requisitos não-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 negócio e de software
(HAIRE et tal, 2001 apud JACYNTHO, 2008). Além desses, também pode-se citar o
18



WebPraxis que como propósito ser utilizado no desenvolvimento de aplicativos que
rodem em ambientes web e não simplesmente sites estáticos ou dinâmicos
(ÁLVARES, 2001). Foi proposto a partir do Praxis, por ser um processo genérico
para produção de aplicativos interativos e orientados a objetos. Assim, o WebPraxis
herda as características usadas para desenvolvimento de aplicativos comuns
desktop e insere outras para atender às necessidades do desenvolvimento web.


3.2 PROGRAMAÇÃO EXTREMA (XP)


     A Programação Extrema (XP) é uma metodologia para equipes de
desenvolvimento pequenas, de duas a dez pessoas, que desenvolvem softwares
onde os requisitos do usuário são 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 são vistas quando o software já
está em produção, o que ocasiona em impactos econômicos e humanos. A XP visa
eliminar os erros durante os processos de desenvolvimento de software, por isso
encoraja o diálogo entre membros da equipe e, principalmente, com o cliente, tendo
assim feedback diário.
     A XP segue quatro variáveis, sendo elas: custo, tempo, qualidade e escopo.
Além de se basear em cinco valores para conduzir o desenvolvimento, sendo:
comunicação, coragem, feedback e simplicidade. Dessa forma, ela tenta prever os
problemas antes que estes aconteçam e assim achar a melhor solução para resolvê-
los de forma rápida.
     “Como programadores, nos habituamos a antecipar problemas. Quando eles
aparecem mais tarde, ficamos felizes. Quando não aparecem, nem notamos.”
(BECK, 2000 apud TELES, 2005).
     Junto com essas características, foram utilizadas no WAAPRO o ciclo codificar,
testar, ouvir e projetar, que são as quatro atividades básicas da XP. Segundo Beck
(2004), o código serve como meio de comunicação que expressa intenções táticas 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



código tem que ser projetado para suportar modificações de forma que o sistema
seja impactado o mínimo possível em outras partes.
     No WAAPRO buscou-se utilizar práticas XP que pudessem ser utilizadas
também no desenvolvimento web como: Jogo do Planejamento, Entregas
Frequentes, Projeto Simples, Design Incremental, Programação em Pares,
Propriedade Coletiva e Contrato de escopo negociável.


3.2.1 O Jogo do Planejamento


     O Jogo do Planejamento determina brevemente o escopo do projeto
combinando prioridades de negócios e estimativas técnicas.
     O desenvolvimento web, assim como o desenvolvimento de software é um
diálogo evolutivo entre o possível e o desejável. Assim, segundo Beck (2004) as
pessoas da área do negócio precisam decidir sobre:
      Escopo – o objetivo de um projeto é entregar um produto que gere valor de
       negócio ao cliente, porém quanto de um problema precisa ser resolvido para
       que o sistema tenha valor em produção? A pessoa da área de negócios
       precisa estar apta a responder questionamentos como esse, entendendo o
       quanto não é 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
       negócios está em posição de decidir isso, muito mais do que um
       programador, por exemplo.
      Composição das versões – basicamente, é preciso saber quanto da
       aplicação web precisa ser feita para que o produto comece a entregar valor
       ao cliente.
      Datas de entrega – datas são importantes, pois servem como metas.


     A área técnica está diretamente ligada com a área de negócios, pois fornece a
matéria-prima para a tomada de decisão. Portanto, as pessoas da área técnica
decidem sobre:
      Estimativas – informação sobre quanto tempo levará para implementar uma
       funcionalidade, por exemplo.
20



      Consequências – existem decisões estratégicas de negócios que devem
        ser tomadas apenas quando há informações sobre as consequências
        técnicas. 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
        consequências.
      Processo – a equipe de trabalho precisa ser organizada, para isso é
        importante programar bem a aplicação web sem se prender a uma cultura
        fechada.
      Cronograma detalhado – os programadores precisam de liberdade para
        dizer o que deve ser feito primeiro na aplicação web, a fim de reduzir o risco
        total do projeto.


3.2.2 Entregas Frequentes


     No desenvolvimento web as mudanças são muito rápidas e os usuários finais
esperam sempre algo novo. A prática de Entregas Frequentes diz que se possível,
coloque um sistema simples rapidamente em produção e depois libere novas
versões em ciclos curtos.
     Cada versão entregue deve ter o menor tamanho possível, contendo os
requisitos de maior valor para o negócio. Beck (2004) ainda afirma que a entrega
precisa fazer sentido como um todo, de nada adianta entregar versões malfeitas, ou
seja, implementar meia função e entregá-la, só para tornar mais curto o ciclo de
entrega.


3.2.3 Projeto Simples


     Basicamente, a XP propõe uso de métodos que tornem o projeto de
desenvolvimento mais simples, onde programadores podem utilizar recursos como
padrões de projeto e framework na codificação, por exemplo. Tufte (1992 apud
BECK, 2004) propõe um exercício para designers gráficos. “Desenhe um gráfico da
forma que você quiser. Então apague todos os elementos, desde que você não
remova nenhuma informação. O que restar quando você não puder apagar mais
nada é o design certo para o gráfico”.
21



     Para que um projeto se torne simples é necessário ter funcionalidades ou
casos de usos bem definidos, o que nem sempre acontece, pois as mudanças fazem
parte do escopo e podem acontecer em qualquer estágio do projeto. Mas é
importante fazer somente o que for preciso quando realmente precisar, ou seja,
evitar criar algo que não será usado ou que a falta deste não irá ter grandes
impactos.


3.2.4 Design Incremental


     O objetivo do Design Incremental é sempre tornar o código e design mais
simples, legível e preparado para mudanças. Deve ter suporte de outras práticas,
como a refatoração1 e os teste automatizados para garantir que a equipe seja capaz
de solucionar os problemas futuros com mais rapidez. Sato (2009) alerta para a
interpretação dessa prática, “seu objetivo não é 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 padrões de
desenvolvimento web que podem ser seguidos e que melhoram a legibilidade dos
códigos e consequentemente a performance da aplicação, como por exemplo, uso
de frameworks.


3.2.5 Programação em Pares


     Na Programação em Pares existem dois papéis em cada par. O primeiro é
aquele indivíduo com o teclado e o mouse que está pensando qual a melhor forma
de implementar um método específico. O segundo pensa de forma estratégica:
        Essa abordagem como um todo vai funcionar?
        Que outros casos de testes podem não funcionar?
        Existe uma maneira de simplificar todo o sistema para que o problema
         simplesmente desapareça?


     Isso promove o trabalho coletivo e colaborativo, une a equipe e melhora,
também, a comunicação e a qualidade do código (SATO, 2009). O aprendizado é

1
  Para Beck (2004), refatorar um código significa alterar seu comportamento a fim de remover
duplicidade, melhorar a comunicação, simplificar e acrescentar flexibilidade.
22



sempre repassado para toda a equipe, assim há uma maior comunicação de todos
que passam a compartilhar de técnicas e ideias novas.


3.2.6 Propriedade Coletiva


     Mesmo que um programador tenha levado dias em um código, a XP sugere
que qualquer um da equipe pode modificar tal código. Isso quer dizer que, não há
um dono, “a qualquer momento, qualquer um que perceba uma oportunidade de
acrescentar valor a alguma parte do código é obrigado a fazê-lo” (BECK, 2004).
     A XP sugere que todos sejam donos do sistema inteiro. Obviamente, nem
sempre todos da equipe irão conhecer todas as partes do código, mas podem saber
um pouco sobre cada parte. Isso dá uma visão mais ampla do sistema, facilitando a
execução de refatoração e espalhando conhecimento por toda a equipe. No
desenvolvimento web, onde toda a equipe está conectada diretamente ao código,
isso é importante, pois não se deve perder tempo solicitando mudanças quando o
próprio programador puder melhorar o código.


3.2.7 Contrato de escopo negociável


     Contratos devem ter fixados tempo, custo e qualidade, deixando o escopo das
funcionalidades em aberto para negociação. Isso porque no desenvolvimento de
aplicações web as mudanças no decorrer do projeto são 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 mudanças conforme a evolução
da aplicação e, também, 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 também é considerado um método específico 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    duração,     usando    equipes     pequenas      e
multidisciplinares, produzem melhores resultados (DE CARVALHO, 2009).


                         Scrum é uma metodologia baseada em simplicidade e adaptabilidade. Um
                         fundamento dessa filosofia é a manutenção da base desse conceito:
                         equipes gerenciáveis. A maioria dos livros aponta equipes de no máximo 9
                         pessoas, multidisciplinar e motivada. Mas é inescapável a existência de
                         projetos onde essa força de trabalho tem de ser multiplicada, devido ao
                         tamanho do sistema sendo desenvolvido (GOLÇALVES, 2011).


         Tudo o que acontece sob Scrum é realizado em um período limitado de tempo,
denominado Time Boxing. Isso é fundamental para entregar software no menor
tempo possível. Além do mais, o Scrum busca a simplicidade. Isso se reflete nos
papéis que cada pessoa tem durante o processo de desenvolvimento, são apenas
três e não 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 esforça em planejar menos e
realizar mais, sendo objetivo nas atividades a serem executadas (GONÇALVES,
2011). O WAAPRO busca a simplicidade dos projetos web, por isso foi um princípio
utilizado na customização deste processo, além de imaginar como será o produto
final.


3.3.1 Ciclos


         No processo ágil WAAPRO foi utilizado o elemento Ciclo da gestão iterativa e
incremental, que no Scrum é chamado Sprint. Cada Sprint é o período de tempo em
que um ou mais incrementos reais são 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 mudanças nos requisitos após a finalização
do projeto. O importante aqui é o tempo de vida de um Ciclo, que não deve
ultrapassar quatro semanas.
         No desenvolvimento web a velocidade de desenvolvimento é acelerada, quanto
mais rápido se desenvolve uma funcionalidade mais rápido será o feedback da
equipe e do cliente.
24



3.3.2 Produto Total


     As funcionalidades no Scrum são vistas primeiro como um todo, chamado
Product backlog, ou seja, tudo o que a aplicação irá conter. Depois disso, passa por
um processo de avalição para priorizar as funcionalidades a serem desenvolvidas
naquele Sprint, gerando assim um Sprint backlog.
     No WAAPRO foi adotado a mesma ideia, é necessário visualizar a aplicação
web como um todo, não com todas as funcionalidade que pode conter, mas sim o
que é necessário para a aplicação se tornar funcional e gerar valor para o cliente. A
partir dessa ideia é que as funcionalidades são priorizadas e implementadas no fluxo
de desenvolvimento.


3.4 P@PSI


     “Pode-se descrever o [..] P@PSI, como sendo gerenciado pelo Scrum,
adotando práticas XP e com fluxos do Processo Unificado.” (GELLER; KNEBEL;
BENTES JÚNIOR, 2007).
     O processo ágil P@PSI foi criado em 2008 pelo Grupo de Trabalho Ágil (GTA)
do Centro Universitário Luterano de Santarém (CEULS/ULBRA), e surgiu com o
propósito de auxiliar desenvolvedores de softwares em pequenos projetos para
empresas que buscam soluções personalizadas.
     Por ser um processo ágil customizado, o P@PSI possui algumas práticas já
testadas como o uso de modelos para representar aspectos do sistema e também o
ciclo iterativo oriundo do Processo Unificado. Alguns desses recursos também
podem ser utilizados no desenvolvimento de aplicação web e foram utilizados,
principalmente, para servir de documentação dos projetos. Serão apresentados os
diagramas mais comuns que podem facilitar a documentação 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 farão a
25



interação com os usuários (MELO, 2009). O caso de uso é utilizado para representar
os requisitos do sistema, ou seja, o que a aplicação deve fazer a fim de atender as
necessidades dos interessados, principalmente os clientes.
      Através de um caso de uso é possível descrever o funcionamento de uma
funcionalidade de maneira informal, sendo de fácil assimilação por clientes que
acompanham um projeto. Os principais conceitos associados ao Diagrama de Caso
de Uso são: atores, e casos de uso.


                         Figura 1 - Exemplo de Diagrama de Caso de Uso




                 Fonte: Arquivo pessoal, 2012.


      Além da forma visual, é bom utilizar um quadro descritivo (quadro 1) para cada
caso de uso, assim, mesmo depois de muito tempo da finalização de um projeto,
caso surja alguma alteração, o desenvolvedor saberá exatamente porque aquele
caso de uso foi feito e o que ele representa na aplicação web.


                  Quadro 1 - Descrição dos Casos de uso mostrados na figura 1.
                                                 O usuário efetuará Login para ter acesso ao
      Fazer Login
                                                 sistema
      Fazer Cadastro                             O usuário faz seu cadastro no sistema.
      Comprar Produto                            O usuário efetua a compra de um produto.
                                                 Verificar se os dados do usuário já estão na
      Validar Dados
                                                 base de dados e se estão corretos.
                                                 O sistema valida a compra e fornece para o
      Dar Desconto                               usuário um campo para inserir seu código de
                                                 desconto.
Fonte: Arquivo pessoal, 2012.
26




3.4.2 Diagrama de Classes


     O Diagrama de Classes (figura 2) é utilizado para modelar a visão estática do
projeto de um sistema. Nele mostra-se um conjunto de classes, interfaces e
colaborações e seus relacionamentos de dependência, generalização e associação
(BOOCH; RUMBAUGH; JACOBSON, 2005). Também ajuda a visualizar a estrutura
de classes antes de implementá-las, e assim, corrigir eventuais erros. Cada classe
funciona em colaboração com outras e não sozinhas, a fim de se fazer sentido.


                        Figura 2- Exemplo de Diagrama de Classes.




                  Fonte: Arquivo pessoal, 2012.



3.4.3 Diagrama ER


     A partir do Diagrama de Classes (figura 2) pode ser feito um mapeamento das
classes em tabelas através do Diagrama ER (figura 3), em que este representa o
modelo relacional das tabelas. Dependendo do padrão de codificação, com a base
de dados pronta, fica mais simples codificar as classes do projeto. Porém, são
necessários ambos os diagramas para modelar as aplicações web antes de
qualquer codificação.
27



       Principalmente no desenvolvimento web, a modelagem da base de dados é
muito importante, pois a partir dela o sistema pode responder de forma rápida ou
não.    Por exemplo, às vezes os desenvolvedores não se preocupam com a
quantidade de usuários que a aplicação pode suportar simultaneamente, uma
modelagem da base de dados errada junto com uma programação malfeita pode
comprometer toda a aplicação, podendo às vezes, ficar inacessível ou lenta.


                                Figura 3 - Exemplo de Diagrama ER




Fonte: Arquivo pessoal, 2012.


3.4.4 Diagrama de Sequência


       Um Diagrama de Sequência é um artefato que ilustra - para um cenário
específico de um caso de uso, com o auxílio das classes identificadas num modelo
de classes - os eventos de entrada e saída relacionados num sistema, como troca
de mensagens, dentro de uma linha de tempo sequencial. Na modelagem do
Diagrama de Sequência (figura 4) cada item descrito nos cenários 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 Sequência.




Fonte: GELLER, 2012.2


        O P@PSI também possui uma herança do Processo Unificado que são os
fluxos iterativos, no qual o processo possui: Planejamento, Desenvolvimento e
Encerramento. No WAAPRO também foram utilizados fluxos iterativos, porém os
fluxos são Planejamento, Desenvolvimento, Finalização e Manutenção, sendo
descritos no capítulo 5.


3.5 OUTROS RECURSOS PARA DOCUMENTAÇÃO NO WAAPRO


        Alguns recursos são válidos no desenvolvimento de aplicações 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 informações feitas no levantamento de requisitos. Esse recurso é
importante para orientar os desenvolvedores sobre as funcionalidades do sistema
que interagem entre si, facilitando a manutenção dos mesmos, em caso de
modificações durante ou após a implementação. Para isso, a planilha especifica um
código único para cada funcionalidade ou ação que a aplicação irá conter, além de

2
    Geller, Marla. (Centro Universitário Luterano de Santarém). Comunicação pessoal. Santarém, 2012.
29



um campo descritivo, categoria que indica o tipo do requisito, prioridade, dificuldade,
status se o requisito já foi implementação ou não, e comentários adicionais. Essa
planilha é atualizada a cada iteração 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

Aplicação web
                                                       Dificuld
Cod                 Requisito               Prioridade   ade Atendido          Comentários
F001 Inserir/Alterar/Excluir Enquete.          Baixo    Baixo   Não
     Todo comentário deve gravar o IP do                                   IP não deve ser
F002 usuário                                   Alto     Baixo      Sim     exibido para usuário.
F003 Listar Notícias por Categoria            Médio     Médio      Não
     Somente usuário nível "Master" pode
F004 cadastrar Novos usuários                  Alto       Alto     Sim
Fonte: Arquivo pessoal, 2012.


3.4.2 Documento de Design Funcional


      O Documento de Design Funcional é um conjunto de Wireframes onde cada
um representa cada página da aplicação. O Wireframe (figura 5) representa a
arquitetura de uma página web com a disposição dos elementos, mas não é função
demonstrar a estética, como conjunto de cores e fontes, por exemplo. Entretanto,
serve como esboço para o designer produzir os Templates da aplicação.
30


                       Figura 5 - Wireframe da página inicial de um site.




         Fonte: Arquivo pessoal, 2012.


3.4.3 Template


     O Template, também chamado de Protótipo de Interface, como mostra a figura
6, pode representar parte da aplicação 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 aplicação. Além disso, este recurso fornece ao
cliente uma prévia, ainda que não funcional, de como será a interface da aplicação,
demonstrando principalmente o conjunto de cores. Por isso é importante o cliente
aprovar o Template antes de este ser implementado.
31


                  Figura 6 - Template da aplicação web Dinheirama Online




   Fonte: DINHEIRAMA ONLINE, 2012.


     Como visto no capítulo, o WAAPRO possui vários recursos que tem origem em
processos já existentes. Outros foram inseridos para atender às características de
aplicações web.
32



4 APLICAÇÃO DO LEAN NO PROCESSO


     A maioria das empresas que querem adotar processos ágeis não fazem uso de
boas práticas de engenharia de software, e adotar qualquer procedimento pode ser
difícil. Por esse motivo, criou-se um conceito que tem como objetivo auxiliar as
empresas a equilibrar corretamente o uso de práticas, princípios e valores em todos
os níveis de uma organização, promovendo assim, uma mudança segura e
sustentável na cultura interna e nos métodos de desenvolvimento e assim criar uma
empresa efetivamente ágil e enxuta.


                     O suporte à mudança precisa ser geral, não somente da gerência executiva,
                     mas também do chão de fábrica. Normalmente, a primeira reação das
                     pessoas é a resistência – sendo assim, imposição nunca será o melhor
                     caminho. É preciso abrir espaço, dar as ferramentas adequadas e criar um
                     ambiente que seja propício à mudança (CRESCÊNDIO, 2011).


     O Lean é uma filosofia de negócio baseada no Sistema Toyota de Produção.
Durante 25 anos a Toyota aperfeiçoou seu sistema enxuto e provou que pode ser
competitiva, tornando-se a maior e mais lucrativa montadora de automóveis. Através
desse pensamento Lean, é possível identificar o que gera valor na visão dos clientes
e usuários.
     O ponto inicial para o pensamento Lean é reconhecer que apenas uma fração
do tempo total e esforço de uma organização adicionam, de fato, valor ao cliente.
Apesar dos princípios e conceitos gerais sobre essa abordagem já terem mais de 50
anos, só recentemente é que estes passaram a ser conhecidos e terem uma devida
aceitação. Isso mostra que a economia mundial afeta muitas empresas, deixando
muitas em dificuldades para sobreviver, lutando para reduzir custos sem prejudicar a
qualidade e serviço ao cliente.
     A visão do Lean além de evitar o desperdício é produzir serviços ou produtos
de qualidade e que gerem valor para o cliente. De forma simplificada, valor consiste
nas características perceptíveis ao cliente, que cada produto ou serviço proporciona
ao seu negócio. Por exemplo: preço, qualidade, prazo de entrega, atendimento
prestado, funcionalidades de acordo com as necessidades especificadas. Ou seja, o
produto ou serviço exatamente como o cliente deseja.
33



4.1 PRINCÍPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE


     Neste tópico são mostrados os princípios do Lean direcionados para o
desenvolvimento de aplicações web, tais como, eliminar o desperdício, amplificar o
aprendizado, entregar o mais rápido possível, respeitar, integrar e visualizar o todo.


4.1.1 Elimine o desperdício


     Evite fazer mais que o necessário. Elimine qualquer coisa que não agregue
valor ao produto e que não são percebidas pela cliente. Por exemplo, se o time
entrega funcionalidades incompletas, se produz documentação de análise apenas
para estar em concordância com o processo, se não prioriza casos de uso e
implementa mais funcionalidade que o necessário de imediato. Isso tudo é
desperdício.


4.1.2 Amplifique o aprendizado


     É importante ter um processo de desenvolvimento que encoraje a sistemática
de aprendizagem ao longo do ciclo de desenvolvimento. Os desenvolvedores têm
que ter a capacidade de responder rapidamente a mudanças de requisitos por parte
do cliente. Um código sofre constantes mudanças, portanto, é preciso codificar de
forma simples, geralmente orientado a testes.


                     Desenvolvimento é um exercício de descoberta, enquanto produção é um
                     exercício de redução de variações, e por essa razão, aprender a abordagem
                     de desenvolvimento resulta em práticas que são bastante diferentes do que
                     aprender abordagens de práticas de produção (DAVIDSON, 2010).


4.1.3 Entregue o mais rápido possível


     Segundo Crescêndio (2011), há duas grandes razões para entregar rápido:
para que o cliente não mude de ideia enquanto um projeto está em desenvolvimento
e para que o concorrente não entregue antes. Além disso, reduzir os ciclos e
entregar rápido e de forma incremental permite feedback e aprendizado sobre o que
34



está sendo feito. Assim, é que preciso descobrir como entregar uma aplicação
funcional tão rápido que clientes não tenham tempo para mudar suas ideias.


4.1.4 Respeito


     Respeitar as pessoas do ponto de vista do Lean não significa aplicar apenas o
bom senso e a boa educação. 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, são exemplos de respeito. “Um ambiente Lean dá espaço para que todos
possam aprender abertamente sobre esse tipo de problema e assim resolvê-los de
uma forma adequada” (CRESCÊNDIO, 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 usuários podem notar.
Para que se tenha integridade, é preciso uma comunicação efetiva, criando assim,
um fluxo contínuo de informações entre desenvolvedores, usuários e clientes.


4.1.6 Visualize o todo


     Este princípio valoriza o aprendizado do ambiente de desenvolvimento, todas
as pessoas precisam enxergar e compreender o todo e criar uma organização que
contribua para a melhoria de seus processos. Por exemplo, se uma equipe tem
especialistas em certas partes de um código e só eles conseguem mexer lá,
certamente as demais pessoas da equipe não estão vendo o todo.


4.2 OS BENEFÍCIOS DO LEAN


     Mesmo com origem em um ambiente de produção industrial, o Lean passou a
ser aplicado em empresas de diversos setores e atividades. De modo geral, é
possível identificar os mais significativos benefícios resultantes da aplicação
“pensamento Lean” nas empresas, que podem ser resumidos da seguinte forma:
35



        Crescimento do negócio;
        Aumento da produtividade;
        Aumento da satisfação do cliente;
        Aumento da qualidade e do serviço prestado ao cliente;
        Maior envolvimento, motivação e participação das pessoas;
        Redução das áreas de trabalho;
        Aumento da capacidade de resposta;
        Redução 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 é fácil, requer o envolvimento e o compromisso de todos.
Nesse tempo, as empresas passam por vários estágios de desenvolvimento, e
nessas etapas é necessário estabelecer metas e objetivos, quantificar resultados e
atuar em função de desvios. Alguns requisitos para o sucesso são:
        Envolvimento da gestão de topo;
        Aderir ao conceito “O cliente em primeiro lugar”;
        Estar consciente em relação aos problemas;
        Gerenciar o processo através de resultados e fatos;
        Criar qualidade em tudo que se faz;
        Implementar as mudanças envolvendo todas as pessoas.


     As metodologias ágeis são um processo de melhoria que uma empresa pode
adotar para desenvolver aplicações web com melhor qualidade, seguindo um padrão
para documentação do que está sendo construído, eliminando desperdícios, 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 práticas e acabar
atrasando o cronograma de entrega do produto. É preciso saber quando usar cada
recurso das metodologias ágeis. Uma solução apresentada para esse problema é a
prática Lean, que surge com a finalidade de ser o caminho para a mudança do
estado atual da empresa (sem práticas á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 aplicações web que gerem valor de negócios para
o cliente.
37



5 MODELO DE CUSTOMIZAÇÃO DO PROCESSO ÁGIL PARA APLICAÇÕES
WEB - WAAPRO


     Diante da crescente necessidade de um processo de desenvolvimento ágil
voltado para aplicações web, foi proposto um modelo capaz de suprir os objetivos
dos desenvolvedores, no que diz respeito a uma melhor organização dos projetos.
     A seguir,    será   descrito    o   processo WAAPRO (Processo     Ágil   para
Desenvolvimento Aplicações Web) e as características utilizadas do XP, SCRUM e
P@PSI.


5.1 O QUE É WAAPRO?


     WAAPRO é um processo ágil customizado com o objetivo de tornar projetos de
aplicações web organizados, no que diz respeito aos ciclos de desenvolvimento e
documentação utilizada, e ser de fácil aceitação para desenvolvedores com pouca
ou nenhuma experiência no desenvolvimento de projetos utilizando metodologias
ágeis. O WAAPRO é dividido em quatro fases, Planejamento, Desenvolvimento,
Finalização e Manutenção, como mostra a figura 7. A seguir serão explicadas as
fases do processo.


5.2 PLANEJAMENTO


     A fase de Planejamento se inicia com o Levantamento e Análise de Requisitos.
Neste momento, ocorre a primeira entrevista com o cliente, onde este expõe suas
necessidades e seus objetivos com o desenvolvimento de uma aplicação web. É
extremamente importante a equipe levantar todas as informações que possam ser
utilizadas no decorrer do projeto.
     Com as informações coletadas, a equipe começa a trabalhar nas estórias de
usuário, ou seja, analisam cada situação proposta pelo cliente e as transformam em
uma funcionalidade como, por exemplo, “Cadastrar Notícia”, representando através
de um diagrama de caso de uso. Esse é o início da documentação do projeto.
     Com base nesses dados, é elaborada uma Proposta de Desenvolvimento, que
é um documento que expressa todas as informações do projeto, no que diz respeito
ao tempo de desenvolvimento, funcionalidades a serem desenvolvidas, mídias e
38



conteúdos a serem inseridos, o que o projeto não irá conter, ou seja, o que não faz
parte do escopo do projeto, e o custo total.
      Em seguida, é realizada uma nova reunião com o cliente para apresentar a
Proposta de Desenvolvimento. Neste momento, o cliente decide se dará ou não
continuidade ao projeto. Caso ele não esteja de acordo com alguma especificação
no documento, pode solicitar alteração. Sendo aprovado, o projeto segue para o
início da criação do briefing. De acordo com Waiteman (2005 p. 38), briefing consiste
em:


                     [...] no máximo, duas páginas com informações dissecadas e organizadas,
                     que representam tudo o que o cliente deseja da agência. 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 solução
                     [...].


      O briefing é o documento que auxilia todos da equipe a ter conhecimento sobre
o cliente e, mais, serve para os responsáveis pela criação do template produzirem
as interfaces com base nas informações contidas no briefing.
      Durante a criação do template é necessário, também, criar um modelo de
organização, uma forma de melhor exibir as informações para o usuário, tornando a
aplicação fácil de utilizar e navegar. Após o template finalizado, é necessária a
aprovação do cliente, havendo alterações, o processo retorna para a etapa de
Criação do template e Modelo de Organização, caso contrário é iniciado a etapa de
Desenvolvimento.


5.3 DESENVOLVIMENTO


      Com o início da fase de Desenvolvimento, o template passa por um
refinamento, ou seja, são coletadas e ajustadas as mídias e conteúdos que serão
implementados na aplicação web. É o conteúdo solicitado previamente ao cliente,
como imagens, vídeos, produção de textos, etc.
      Após o refinamento do template se inicia o ciclo de codificação dos casos de
uso, que está divido em três etapas e não deve ultrapassar o período de quatro
semanas, sendo:
      Codificar funcionalidades, propriamente dito, escrever os códigos e toda a
logica de programação, independente das ferramentas e tecnologias utilizadas, a
39



codificação tem que ser simples e de fácil manutenção. Para isso, são utilizados
alguns padrões de desenvolvimento, como programação orientada a objetos,
frameworks de desenvolvimento ágil, padrões de programação para uso de banco
de dados, entre outros. Para cada código escrito, são feitos testes, a fim de se
certificar, que além de estar funcionando devidamente, não possui problemas
quando for relacionado com outros elementos da aplicação.
     Com a funcionalidade devidamente codificada, segue-se para a fase de
implementação. Nesse momento, o código vai ser integrado a outros, podendo ser,
ao código principal da aplicação. Em caso de erros, estes são corrigidos e vários
testes são feitos para que ao final do ciclo, a aplicação não apresente problemas.
Para que não haja nenhuma falha, a funcionalidade ainda passa por mais testes,
são os Testes de Funcionalidade.
     Nesse momento, a funcionalidade já está ativa na aplicação, mas é necessário
certificar que tudo está em perfeita ordem para uso pelos usuários. Os testes servem
para encontrar falhas, assim são simuladas as ações do usuário, caso seja
encontrado algum erro, o ciclo não é finalizado e retorna para a implementação, ou
se necessário, para a codificação da funcionalidade.
     Para finalizar o processo de Desenvolvimento, é preciso fazer a integração das
mídias e conteúdo às funcionalidades. Por exemplo, seguindo o exemplo dado
anteriormente com a funcionalidade “Cadastrar notícia”, os itens necessários para
cadastrar uma notícia seriam: texto, imagens, vídeos. Feito a inserção desse
material, a funcionalidade está concluída e o ciclo continua até que todos os casos
de uso sejam concluídos.


5.4 FINALIZAÇÃO


     Na fase de Finalização entende-se que o produto já está completo,
necessitando apenas de revisão. Nesse primeiro momento, são realizados testes em
todo o produto, testando cada funcionalidade e revisando todos os textos, bem como
revisão ortográfica nas palavras.
Se tudo estiver pronto, o produto é então apresentado para o cliente. Caso, o cliente
não esteja satisfeito com algum detalhe, o produto então retorna para o Refinamento
do Template (fase de Desenvolvimento), para que os detalhes possam ser
reavaliados e as alterações sejam feitas. Não havendo nenhum questionamento por
40



parte do cliente, o produto é então entregue, sendo necessário apenas o
treinamento para utilização da plataforma de administração da aplicação web,
quando necessário.


5.5 MANUTENÇÃO


     No modelo tradicional de desenvolvimento de software, o produto geralmente é
finalizado na fase de encerramento, não tendo uma fase que contemple a
manutenção do mesmo. Porém, no desenvolvimento web, as mudanças são
contínuas, e não se pode dizer que o produto está finalizado após a entrega ao
cliente e ao seu treinamento. Pois mesmo após essas etapas, a aplicação pode
sofrer mudanças. Para solucionar esse problema é necessária uma fase de
Manutenção.
     Nessa fase é solicitada pelo cliente a alteração 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 revisão da alteração, na fase de Finalização,
até a apresentação da alteração para o cliente.
     Assim, pode-se dizer que a manutenção é uma consequência da entrega do
produto, porém cada mudança solicitada termina na fase de Finalização, porque
passa por todas as etapas dessa fase em um ciclo contínuo.
Figura 7 - Visão geral do WAAPRO




Fonte: Arquivo Pessoal, 2012.
                                                                   40
42



6 ESTUDO DE CASO


        Este capítulo apresenta um estudo de caso, onde o processo ágil WAAPRO foi
utilizado na empresa W3Mais Comunicação Interativa, para o desenvolvimento de
um site interativo para a empresa Sistema Guarany de Comunicação. O site pode
ser visualizado através do link <http://www.portalguarany.com.br>.


6.1 O CLIENTE


        O Sistema Guarany de Comunicação é um grupo formado pela Rádio Guarany
FM, TV e Portal Guarany.
        A Rádio Guarany FM foi inaugurada em 1981 com a ideia de expandir os
trabalhos que foram iniciados com o serviço de propaganda volante Guarany e
cobertura de eventos religiosos. Atualmente a rádio opera na frequência 100,3 Mhz
e tem ouvintes de todas as faixas etárias, sendo a mais popular na cidade de
Santarém (PORTAL GUARANY, 2012).
        Retransmissora da Rede Record de Televisão, a TV Guarany, “desde sua
formação proporciona entretenimento, descontração e jornalismo opinativo de
credibilidade mais perto do povo.” (PORTAL GUARANY, 2012).
        O Portal Guarany foi criado para suprir a necessidade de uma comunicação
mais ampla via internet com os ouvintes, telespectadores e internautas. Assim, a
Rádio 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
Rádio Guarany e os apresentadores dos programas, bem como servir como portal
de conteúdo com notícias regionais e do território brasileiro. As funcionalidades
principais são: Rádio Interativo, Notícias, Mural de Recados e Programação da
Rádio. Outras funcionalidades secundárias também fizeram parte do projeto, como:
Galeria de fotos, Feed de posts do Twitter, Feed de notícias do Portal R7 3, sistema




3
    Portal de conteúdo da Rádio e Televisão Record S/A.
43



de Publicidade, código de rastreamento do Google Analytics e também, o link para
ouvir a rádio on-line.


6.3 PLANEJAMENTO


     A fase de Planejamento inicia-se através do contato com o cliente, no caso o
cliente é o Sistema Guarany de Comunicação. Esta fase inclui o Levantamento e
Análise de Requisitos para entender as necessidades do cliente e quais
funcionalidades o site irá conter; Proposta de Desenvolvimento que é a elaboração
de um documento com as informações 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 Análise de Requisitos


     A fase inicial do projeto diz respeito à avaliação da situação e das
necessidades do cliente. Na primeira reunião o cliente expôs suas necessidades.
Primeiramente, o site deveria ter uma seção específica em que o usuário pudesse
responder a questionamentos diários, sempre uma pergunta polêmica sobre a
atualidade. Esses comentários seriam lidos pelo apresentador do programa Rádio
Interativo ao vivo, portanto os dados deveriam ser validados de modo que um
usuário não se passasse por outro. Segundo, uma seção tipo mural de recados,
onde os usuários pudessem enviar mensagens para qualquer pessoa. Terceiro, uma
área especial de notícias com quatro categorias específicas (Santarém, Pará, Brasil,
Mundo). Quarto, mostrar o programa que a rádio estaria apresentando no momento
em que o usuário acessasse o site, além de um link que ao ser clicado, o usuário
pudesse ouvir a rádio ao vivo.
     Outras necessidades também foram mencionadas, como ter uma galeria de
fotos, onde o administrador pudesse cadastrar fotos dos eventos do Sistema
Guarany de Comunicação. Uma forma de exibir as notícias do Portal R7 e as
publicações 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 informações foi necessário transformar essas estórias de
usuário em funcionalidades que o site iria conter. Para isso, foi elaborado um
44



Diagrama de Caso de Uso, que serviu para melhorar a visualização de todos os
recursos que o site poderia oferecer. A figura 8 mostra as funcionalidades exibidas
para os usuários, ou seja, o front-end4 do site.


                         Figura 8 - Diagrama de Caso de Uso do Portal Guarany.




    Fonte: Arquivo pessoal, 2012.


        Para que o diagrama fique mais bem explicado, estão descritos todos os casos
de uso (quadro 3).


                       Quadro 3 - Descrição dos Casos de Uso do Portal Guarany.
                                                        Apresenta as mensagens enviadas de
    Comentar Mural de Recados
                                                        um usuário para outro.
                                                        Exibe as notícias de todas as
                                                        categorias em ordem de postagem.
    Visualizar Notícias                                 Todas as notícias tem formulário para
                                                        postagem    de     comentários   com
                                                        moderação pelo administrador.
                                                        Uma pergunta com opção para o
                                                        usuário comentar com os campos:
    Comentar Rádio Interativo
                                                        nome, bairro e comentário. O
                                                        comentário só fica visível após a

4
    Área pública visualizada pelo usuário de um site.
45



                                                 liberação pelo administrador.
                                                 Exibe o programa da rádio transmitido
                                                 no momento e uma foto do
 Visualizar Programação ao vivo
                                                 apresentador. Também exibe um link
                                                 para o usuário ouvir o programa on-line.
                                                 Link externo para o usuário ouvir a
 Ouvir Rádio on-line
                                                 rádio on-line.
                                                 Exibe       postagens      da     conta
 Visualizar Feed Twitter
                                                 @portalguarany no Twitter.
 Visualizar Feed Portal R7                       Exibe notícias do Portal R7.
                                                 Exibe fotos separadas por galerias
 Visualizar Galeria de fotos
                                                 (álbuns).
Fonte: Arquivo pessoal, 2012.


      O Portal Gurany possui funcionalidades que apenas podem ser vistas pelos
administradores do site. Para não haver confusão no desenvolvimento, foi feito um
novo Diagrama de Caso de Uso, mostrado na figura 9, apresentando as
funcionalidades acessíveis para os usuários da administração do site. Como mais de
uma pessoa teria acesso, foi solicitado que os usuários tivessem níveis de acesso.
Portanto, ficou definido que o nível Master teria acesso a todas as funcionalidades
do sistema de administração e o nível Web Master teria acesso apenas à liberação
de conteúdo, não podendo cadastrar novos usuários, por exemplo.


       Figura 9 - Diagrama de Caso de Uso do Sistema de Administração do Portal Guarany.




      Fonte: Arquivo pessoal, 2012.
46


     Quadro 4 - Descrição dos Casos de Uso do Sistema de Administração do Portal Guarany.
                                               Possibilita inserir, alterar, excluir e
Manter Notícias
                                               consultar notícias publicadas.
                                               Possibilita inserir, alterar, excluir os
Manter Administrador
                                               administradores do site.
                                               Possibilita inserir, alterar e excluir
Manter Destaque                                imagens em destaque na página inicial
                                               (slideshow) do site.
                                               Possibilita inserir, alterar, excluir e
Manter Programação ao vivo                     consultar os programas da Rádio Gurany
                                               FM.
                                               Possibilita inserir, alterar, excluir e
Manter Galeria de fotos                        consultar galerias de fotos publicadas no
                                               site.
                                               Possibilita consultar, publicar e excluir
                                               comentários publicados pelos ouvintes.
Manter Rádio Interativo
                                               Além de poder inserir, alterar status e
                                               excluir as perguntas.
                                               Possibilita inserir e excluir as
Manter Publicidade
                                               publicidades do site.
                                               Possibilita publicar e excluir comentários
Manter Mural de recados
                                               feitos pelos internautas do site.
                                               É através desta funcionalidade que o
Fazer Login                                    administrador pode ser acesso ao
                                               sistema administrativo.
Fonte: Arquivo pessoal, 2012.


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), além de tempo e custo total de
desenvolvimento.
      Sabendo que o site iria ter páginas informativas e estáticas, como conteúdo
sobre a empresa, serviços, área comercial e formulário de contato, esses itens foram
inseridos na proposta.
      Algo muito importante é a verificação de disponibilidade do domínio do site. O
domínio deveria ser portalguarany.com.br, que foi verificado e comprado junto ao
site Registro.br, responsável pelo registro de domínios brasileiros.
47



6.3.3 Briefing


     Após a aprovação da Proposta de Desenvolvimento pelo cliente foi necessário
elaborar um briefing (ver anexo B) com informações relevantes para o
desenvolvimento do site, como informações sobre o Sistema Guarany de
Comunicação, a identidade visual, e o que seria utilizado no design do site. Essas
informações são úteis no processo criativo do designer responsável por criar o
Template do site e das páginas que este contém.


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 disposição do layout e pode ser visto abaixo, na figura 10.


                   Figura 10 - Wireframe da página inicial do Portal Guarany.




                 Fonte: Arquivo pessoal, 2012.
48




      A partir do wireframe o designer começou a trabalhar na parte estética do site,
ou seja, o desenho com as cores e imagens dispostas no layout. Essa etapa exigiu
bastante criatividade, mas com o briefing em mãos a tarefa de construir o template
ficou mais fácil, pois já se sabia que a cor principal seria um tom de verde e cores
variadas que indicassem cada seção do site, como mostra a figura 11.
      Terminado o template, este precisou ser aprovado pelo cliente. Para isso, em
uma reunião o template foi apresentado e com poucos questionamentos, logo foi
aprovado, dando sequência ao desenvolvimento.


                           Figura 11 - Template do site Portal Guarany.




Fonte: Arquivo pessoal, 2012.
49




      Também é necessário criar o layout para o sistema de administração do site,
como mostra a figura 12. Nesse caso, não foi necessário passar pela aprovação do
cliente, pois essa parte do sistema apenas foi adaptada para o site Portal Guarany,
uma vez que a tecnologia é licenciada pela W3Mais Comunicação Interativa
mediante contrato. Isso gera um ganho de tempo na inclusão e exclusão de
funcionalidades no desenvolvimento de novas aplicações.


                     Figura 12 - Sistema de Administração do Portal Guarany.




Fonte: Arquivo pessoal, 2012.


6.4 DESENVOLVIMENTO


      O projeto Portal Guarany possui muitas funcionalidades, portanto foi necessário
priorizar algumas para iniciar a fase de desenvolvimento. O WAAPRO permitiu ao
projeto ser feito em módulos. Neste trabalho é apresentado, na etapa de codificação,
o módulo que consiste em três funcionalidades, sendo elas: Mural de Recados,
Notícias e Rádio Interativo.
      Na etapa de desenvolvimento foi testado um princípio 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 código ou uma funcionalidade inteira.
50



6.4.1 Coleta de conteúdo


        Antes do início do desenvolvimento é necessário ter todo o conteúdo das
páginas. É especificado no contrato de desenvolvimento que o cliente tem um prazo
para entregar todo o material necessário para o desenvolvimento do site, isso inclui
textos, imagens, vídeos ou qualquer conteúdo que precise estar no site no ato da
entrega (alguns conteúdos podem ser inseridos pelo próprio usuário através do
sistema de administração). Com o conteúdo em mãos o desenvolvimento foi
passado para a fase de codificação.


6.4.2 Diagramação do Template


        A primeira etapa da codificação do site é transformar o Template – que é uma
imagem – em código. Isso requer o uso de alguns recursos web como a linguagem
de folhas de estilos CSS e o XHTML que é uma linguagem de marcação semântica.
        No CSS ficam as regras do que será exibido das páginas, como cores, fundos,
tamanhos de divs5, posicionamento de divs, fonte do texto, etc. Cabe ao XHTML
separar o conteúdo semanticamente para receber os estilos do CSS.
        O site fica exatamente igual ao desenho feito pelo designer, porém em forma
de códigos prontos para serem implementados em linguagem dinâmica, que
especificamente nesse projeto foi utilizado o PHP.


6.4.3 Codificação


        No Portal Guarany foi utilizado alguns padrões de desenvolvimento como
orientação a objetos, MVC e DAO. Isso traz alguns benefícios, como a rapidez na
manutenção do código.
        Para início da codificação 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 métodos de controle.



5
    Elemento HTML que define uma divisão na página e pode ter variadas formatações.
51



     A funcionalidade Notícia exemplificada pelo diagrama da figura 13 representa
que cada notícia tem apenas uma categoria, podendo ser Santarém, Pará, Brasil,
Mundo. Além disso, cada notícia pode receber comentários.


                   Figura 13 - Diagrama de Classe da funcionalidade Notícia




         Fonte: Arquivo pessoal, 2012.


     A funcionalidade Rádio Interativo, representada na figura 14, mostra que há um
relacionamento entre uma questão e um comentário, onde a questão pode receber
vários comentários, porém os comentários possuem um status do tipo boolean, que
indica que o administrador do sistema é quem publica ou não o comentário.
52


                Figura 14 - Diagrama de Classe da funcionalidade Rádio Interativo




 Fonte: Arquivo pessoal, 2012.


     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 usuário
pode enviar um comentário para um outro usuário, porém esse comentário só fica
visível mediante publicação 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




        Fonte: Arquivo pessoal, 2012.
53




     Também foi utilizado o Diagrama ER para modelar o banco de dados e para
definir as tabelas necessárias para armazenamento de conteúdo. Este tipo de
artefato ajuda a entender melhor os relacionamentos entre tabelas. Como mostram
as figuras 16, 17 e 18, representando as funcionalidades Notícia, Rádio Interativo e
Mural de Recados respectivamente. A partir disso, foi possível criar todo um
conjunto de classes que permitem manipular os dados das tabelas.


                             Figura 16 - Diagrama ER - Notícia.




              Fonte: Arquivo pessoal, 2012.
54


                          Figura 17 - Diagrama ER - Rádio Interativo.




      Fonte: Arquivo pessoal, 2012.

                         Figura 18 - Diagrama ER - Mural de Recados.




                          Fonte: Arquivo pessoal, 2012.


     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 é característica das metodologias ágeis.
55



     Durante o desenvolvimento do Portal Guarany algumas funcionalidades ficaram
um pouco confusas na hora da codificação, uma delas foi o caso de uso Rádio
Interativo, responsável direto pela interação dos usuários do site com a Rádio
Guarany FM. De fato, o cliente queria que cada pessoa que comentasse na Rádio
Interativo fosse única e esses comentários deveriam ser moderados pela
administração. O problema era como fazer isso da forma mais simples possível e
que não dificultasse a forma de interação do usuário com o site. Ao se tentar fazer o
que o cliente queria, perdeu-se muito tempo desenvolvendo uma funcionalidade de
forma que não gerava valor algum para o cliente e ainda dificultava a interação como
usuário. Seguindo a ideia de processo enxuto Lean, para criar algo que realmente
trouxesse valor para o negócio do cliente foi feita uma análise de como o Rádio
Interativo funcionaria. Uma forma de solucionar o problema foi visualizá-lo melhor
com diagramas de sequência. Não só para a funcionalidade Rádio Interativo, mas
nesse módulo procurou-se fazer também para a funcionalidade Notícia e Mural de
Recados.
     Na funcionalidade Notícia, representada pelo diagrama de sequência na figura
19, foram discutidos quais campos seriam preenchidos pelo usuário e se o
comentário seria moderado pelo administrador ou não. Por fim, a equipe concordou
que todos os comentários seriam moderados pelo administrador, onde este poderia
apenas excluir ou publicar o comentário, ficando impedido de alterar qualquer
informação. Essa análise foi fundamental para desenvolver outras funcionalidades
que teriam o mesmo princípio.
56


                   Figura 19 - Diagrama de Sequência da ação comentar Notícia




Fonte: Arquivo pessoal, 2012.


      Quando foi necessário fazer a codificação da funcionalidade Rádio Interativo,
houve uma dificuldade em tentar encontrar a forma mais simples de um usuário
comentar um questionamento. O cliente queria que o sistema pudesse identificar
fraude em um comentário, ou seja, um usuário não poderia comentar com o nome
ou outra informação pessoal igual à outra pessoa. A solução final, e mais simples, foi
que o usuário teria três campos para inserir dados, sendo Nome, Bairro e
Comentário, pois são as informações que o apresentador do Programa Rádio
Interativo lê ao vivo. Todos os comentários são moderados pelo administrador do
sistema. Somente após a publicação os comentários ficam visíveis para o usuário e
somente enquanto o questionamento estiver no ar. A representação do diagrama de
sequência pode ser vista na figura 20.
57


               Figura 20 - Diagrama de Sequência da ação comentar Rádio Interativo




Fonte: Arquivo pessoal, 2012.


      Quando a funcionalidade Mural de Recados foi codificada, já se tinha um
conhecimento de como ela iria se comportar, porém ainda foi representada através
de um diagrama de sequência (figura 21) que mostra a ação de enviar um recado e
a publicação do mesmo pelo administrador do sistema. Aqui a funcionalidade segue
a mesma ideia das outras, o recado só fica visível após a permissão pelo
administrador, e este pode excluir o comentário a qualquer momento, mesmo após a
publicação.
58


     Figura 21 - Diagrama de Sequência da ação de enviar recado através do Mural de Recados




Fonte: Arquivo pessoal, 2012.


      Como pôde 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 dúvidas, pois muitas
vezes uma pessoa da equipe não conseguia visualizar, ou mesmo, fazer o cliente
entender como determinada ação acontecia.


6.5 FINALIZAÇÃO


      Na etapa de Finalização busca-se fazer testes de toda a funcionalidade ou do
projeto inteiro pronto a fim de encontrar erros. Também, é caracterizada pela
entrega da aplicação para o cliente e o treinamento do mesmo.
59



6.5.1 Revisão 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 revisão do produto é importante
por simular a ação do usuário 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 não saíram como planejado, como o caso de
uso Ver Programação ao Vivo. No momento do teste percebeu-se que o fuso horário
do servidor era diferente do fuso horário brasileiro (Brasília), assim tendo que voltar
para o Desenvolvimento até ser corrigido e pronto para apresentar ao cliente.


6.5.2 Apresentação do produto ao cliente


     O Portal Guarany foi apresentado através de uma reunião da equipe de
desenvolvimento com o cliente. Foi demonstrada cada funcionalidade em
funcionamento. Após o término da apresentação 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, porém acessível 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 visível na web.


6.5.4 Treinamento


     A administração do site possui muitas funcionalidades, tudo intuitivo, porém o
cliente queria que fosse ministrado um treinamento para duas pessoas responsáveis
pela administração do Portal Guarany. O treinamento foi feito de forma presencial e
foi realizado em dois dias.
60



6.6 MANUTENÇÃO


     A fase de Manutenção existiu nesse projeto apenas para edição de alguns
textos em páginas estáticas e manutenção 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 Finalização.
61



7 CONCLUSÃO


     O processo ágil WAAPRO se mostrou eficiente no desenvolvimento de
aplicações web, como pôde ser constatado no desenvolvimento do Portal Guarany.
O uso de etapas permitiu melhor controle do que se estava fazendo e não deixando
a equipe se perder quando ocorriam mudanças nos requisitos.
     Em algumas etapas do projeto ficou evidente que o uso de um processo ágil
ajuda a minimizar desperdícios de tempo, regra fundamental de um processo Lean.
Como por exemplo, durante a codificação da funcionalidade Rádio Interativo, os
requisitos mudaram diversas vezes, a primeira vez foi produzido algo que o cliente
queria, porém não gerava valor algum. Isso foi constatado quando o site foi ao ar
durante alguns dias para testes com usuários iniciais. Durante aproximadamente 1
semana, não houve nenhum comentário na Rádio Interativo, isso significava que
algo de errado estava acontecendo. Portanto, a funcionalidade foi refeita mais duas
vezes, e somente na terceira mudança é que os comentários começaram a
aparecer. Para isso, tudo que dificultava a ação de comentar foi retirado. O usuário
simplesmente comentava e esperava o comentário ser publicado pelo administrador.
     O Lean passou a ser fundamental junto com o processo ágil WAAPRO, pois
toda a equipe pôde aprender melhor como realizar as atividades focando no produto
e no usuário, além de fazer somente o que gerava valor para o cliente. Entretanto a
visão do Lean foi superficial. Percebe-se que para o aprendizado de uma
metodologia ágil e uma mudança de cultura numa empresa que não utiliza esse tipo
de processo de desenvolvimento leva bastante tempo, porque no início é difícil
assimilar o funcionamento do processo e mais difícil ainda é abandonar alguns
vícios, 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
importância para se ter uma visão mais ampla do que poderia ser utilizado como
característica para a criação do WAAPRO, uma vez que essas metodologias já
foram bastante testadas. O P@PSI permitiu ter uma melhor ideia de         como um
processo ágil pode ser customizado e quais seus benefícios.
     Procurou-se mostrar o funcionamento do WAAPRO através de um estudo de
caso para ter a validação do processo ágil junto com uma equipe de
desenvolvedores que não utilizavam nenhum tipo de processo específico nos
62



projetos, assim pôde-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, porém levou bastante tempo. Não foi possível verificar o
lead time6 em todas as etapas, pois não 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 aplicação web. É
importante ressaltar que para que um processo ágil se torne eficiente precisa partir
de uma mudança de cultura numa empresa ou na equipe de desenvolvimento. O
Lean sugere principalmente para empresas pequenas, uma série de princípios 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
desperdícios, fazer somente o necessário quando for necessário e ter uma
organização 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 pôde-se comprovar uma melhora no
diálogo e na percepção de erros antes da implementação ou mudança de requisito.
Ainda é necessário um aprofundamento na visão Lean para verificar as reais
mudanças 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. São necessários
mais testes com WAAPRO no desenvolvimento de aplicações web, para se ter uma
ideia se todas as etapas funcionam e o que precisa ser melhorado, a partir da visão
de outros desenvolvedores.
        Espera-se, que a partir deste trabalho apresentado sobre a utilização de
metodologias ágeis na customização do processo web WAAPRO, possam surgir
projetos relacionados com o tema. Pois o mesmo oferece muitos benefícios para os
desenvolvedores que queiram manter seus projetos enxutos.




6
    Tempo em que se recebe um requisito até a entrega da funcionalidade.
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web

Mais conteúdo relacionado

Mais procurados

Aula 4 - Teste de mesa
Aula 4 - Teste de mesaAula 4 - Teste de mesa
Aula 4 - Teste de mesa
Pacc UAB
 
Aula 4.a. fluxograma.pptm
Aula 4.a.   fluxograma.pptmAula 4.a.   fluxograma.pptm
Aula 4.a. fluxograma.pptm
Claudio Parra
 
Informatica - Aula10 - Excel - Exercicios
Informatica - Aula10 - Excel - ExerciciosInformatica - Aula10 - Excel - Exercicios
Informatica - Aula10 - Excel - Exercicios
Arthur Emanuel
 
Aula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação IAula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação I
Paolo Passeri
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
jwainer
 

Mais procurados (20)

Introdução a programação para a Internet
Introdução a programação para a InternetIntrodução a programação para a Internet
Introdução a programação para a Internet
 
Os 7 processos da Arquitetura da Informação
Os 7 processos da Arquitetura da InformaçãoOs 7 processos da Arquitetura da Informação
Os 7 processos da Arquitetura da Informação
 
Aula 1 - Introdução a POO
Aula 1 -  Introdução a POOAula 1 -  Introdução a POO
Aula 1 - Introdução a POO
 
Caderno de exercícios excel 2010
Caderno de exercícios excel 2010Caderno de exercícios excel 2010
Caderno de exercícios excel 2010
 
[Curso Java Basico] Exercicios Aulas 44 a 46
[Curso Java Basico] Exercicios Aulas 44 a 46[Curso Java Basico] Exercicios Aulas 44 a 46
[Curso Java Basico] Exercicios Aulas 44 a 46
 
Algoritmos - Matrizes
Algoritmos - MatrizesAlgoritmos - Matrizes
Algoritmos - Matrizes
 
Introdução à Programação Web com Angular
Introdução à Programação Web com AngularIntrodução à Programação Web com Angular
Introdução à Programação Web com Angular
 
Aula 4 - Teste de mesa
Aula 4 - Teste de mesaAula 4 - Teste de mesa
Aula 4 - Teste de mesa
 
Algoritmos - Aula 07 B - Exercicios Vetores - Enunciado
Algoritmos - Aula 07 B - Exercicios Vetores - EnunciadoAlgoritmos - Aula 07 B - Exercicios Vetores - Enunciado
Algoritmos - Aula 07 B - Exercicios Vetores - Enunciado
 
Pseudocódigo ou Portugol (Lógica de Programação)
Pseudocódigo ou Portugol (Lógica de Programação)Pseudocódigo ou Portugol (Lógica de Programação)
Pseudocódigo ou Portugol (Lógica de Programação)
 
Aula 4.a. fluxograma.pptm
Aula 4.a.   fluxograma.pptmAula 4.a.   fluxograma.pptm
Aula 4.a. fluxograma.pptm
 
Informatica - Aula10 - Excel - Exercicios
Informatica - Aula10 - Excel - ExerciciosInformatica - Aula10 - Excel - Exercicios
Informatica - Aula10 - Excel - Exercicios
 
Introdução ao desenvolvimento da web.pptx
Introdução ao desenvolvimento da web.pptxIntrodução ao desenvolvimento da web.pptx
Introdução ao desenvolvimento da web.pptx
 
Lógica de programação em ppt
Lógica de programação em pptLógica de programação em ppt
Lógica de programação em ppt
 
Aula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação IAula 2 - Técnicas de Prototipação I
Aula 2 - Técnicas de Prototipação I
 
Interface Homem Computador - Aula01- Introdução a IHC
Interface Homem Computador - Aula01- Introdução a IHCInterface Homem Computador - Aula01- Introdução a IHC
Interface Homem Computador - Aula01- Introdução a IHC
 
[Curso Java Basico] Exercicios Aula 20
[Curso Java Basico] Exercicios Aula 20[Curso Java Basico] Exercicios Aula 20
[Curso Java Basico] Exercicios Aula 20
 
Exercicios java básico
Exercicios java básicoExercicios java básico
Exercicios java básico
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
 

Destaque

7028018 metodologia-trabalho-academico-1-fichamentos
7028018 metodologia-trabalho-academico-1-fichamentos7028018 metodologia-trabalho-academico-1-fichamentos
7028018 metodologia-trabalho-academico-1-fichamentos
Ju Ribeiro
 
Escrita Magnética
Escrita MagnéticaEscrita Magnética
Escrita Magnética
RENATO PORTO SANTOS
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Neubio Ferreira
 
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Gabriel Rubens
 

Destaque (20)

A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
A UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA A ENTREGA DE SERVIÇOS DE INFRAESTRUTU...
 
REST – Desmistificando A Implementação De Web Services REST Em Java Monografia
REST – Desmistificando A Implementação De Web Services REST Em Java MonografiaREST – Desmistificando A Implementação De Web Services REST Em Java Monografia
REST – Desmistificando A Implementação De Web Services REST Em Java Monografia
 
7028018 metodologia-trabalho-academico-1-fichamentos
7028018 metodologia-trabalho-academico-1-fichamentos7028018 metodologia-trabalho-academico-1-fichamentos
7028018 metodologia-trabalho-academico-1-fichamentos
 
Escrita Magnética
Escrita MagnéticaEscrita Magnética
Escrita Magnética
 
Artigo livia
Artigo liviaArtigo livia
Artigo livia
 
Criterios para correção textual
Criterios para correção textualCriterios para correção textual
Criterios para correção textual
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
 
Diário Oficial: 26-11-2015
Diário Oficial: 26-11-2015Diário Oficial: 26-11-2015
Diário Oficial: 26-11-2015
 
Guia%20de%20 fi is%20xp_janeiro.2013
Guia%20de%20 fi is%20xp_janeiro.2013Guia%20de%20 fi is%20xp_janeiro.2013
Guia%20de%20 fi is%20xp_janeiro.2013
 
Guia de sustentabilidade para o turismo, santander
Guia de sustentabilidade para o turismo, santanderGuia de sustentabilidade para o turismo, santander
Guia de sustentabilidade para o turismo, santander
 
Macrosolutions Consultoria: Estruturação dos Processos de Comunicação em Proj...
Macrosolutions Consultoria: Estruturação dos Processos de Comunicação em Proj...Macrosolutions Consultoria: Estruturação dos Processos de Comunicação em Proj...
Macrosolutions Consultoria: Estruturação dos Processos de Comunicação em Proj...
 
Fii apresentacao brasil-plural
Fii apresentacao brasil-pluralFii apresentacao brasil-plural
Fii apresentacao brasil-plural
 
Projetos em Assessoria de Comunicação - Aula 02
Projetos em Assessoria de Comunicação - Aula 02Projetos em Assessoria de Comunicação - Aula 02
Projetos em Assessoria de Comunicação - Aula 02
 
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
Profissao-programador-praticas-para-melhoria-continua-unimonte-outubro-2013
 
O que vi na QCon 2012 São Paulo
O que vi na QCon 2012 São PauloO que vi na QCon 2012 São Paulo
O que vi na QCon 2012 São Paulo
 
Ufg2dia2014
Ufg2dia2014Ufg2dia2014
Ufg2dia2014
 
Gestão e Processos para Desenvolvimento de Software
Gestão e Processos para Desenvolvimento de SoftwareGestão e Processos para Desenvolvimento de Software
Gestão e Processos para Desenvolvimento de Software
 
Princípios Ágeis
Princípios ÁgeisPrincípios Ágeis
Princípios Ágeis
 
Prova apmbb 2010
Prova apmbb 2010Prova apmbb 2010
Prova apmbb 2010
 
Inovação Tecnológica e Empreendedorismo
Inovação Tecnológica e EmpreendedorismoInovação Tecnológica e Empreendedorismo
Inovação Tecnológica e Empreendedorismo
 

Semelhante a TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web

SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
João Gabriel Lima
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
Rogério Batista
 
Monografia - André Luiz Jamarino Abekawa
Monografia - André Luiz Jamarino AbekawaMonografia - André Luiz Jamarino Abekawa
Monografia - André Luiz Jamarino Abekawa
André Luiz Jamarino Abekawa
 
TCC ANDRE ABEKAWA - Fatec (Primeira Versão)
TCC ANDRE ABEKAWA - Fatec (Primeira Versão)TCC ANDRE ABEKAWA - Fatec (Primeira Versão)
TCC ANDRE ABEKAWA - Fatec (Primeira Versão)
André Luiz Jamarino Abekawa
 
UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...
UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...
UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...
Marcelo Linhares
 

Semelhante a TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desenvolvimento de Aplicações Web (20)

SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
 
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
AMAO - DESENVOLVIMENTO DE UM AMBIENTE ONLINE DE AUXÍLIO À CORREÇÃO E RESOLUÇÃ...
 
Arca Sistema Gerencial
Arca Sistema GerencialArca Sistema Gerencial
Arca Sistema Gerencial
 
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana BenedettProjeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
Projeto de Conclusão de Curso - Anderson Nascimento / Mariana Benedett
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
 
Monografia - André Luiz Jamarino Abekawa
Monografia - André Luiz Jamarino AbekawaMonografia - André Luiz Jamarino Abekawa
Monografia - André Luiz Jamarino Abekawa
 
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
 
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
E-OBRAS: Proposta de Desenvolvimento do Protótipo de Sistema para Secretarias...
 
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
TCC - METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E DESENVOLVIMENTO ...
 
MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F...
MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F...MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F...
MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F...
 
PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATUR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATUR... PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATUR...
PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATUR...
 
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenhari...
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenhari...Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenhari...
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenhari...
 
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOSMÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
MÓDULO DE GERENCIAMENTO DE BOLSAS DO SISTEMA CONTROLE DE PROCESSOS
 
SisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo FinanceiroSisEdu – Sistema Educacional - Módulo Financeiro
SisEdu – Sistema Educacional - Módulo Financeiro
 
Automação de Testes de Regressão - Selenium
Automação de Testes de Regressão - SeleniumAutomação de Testes de Regressão - Selenium
Automação de Testes de Regressão - Selenium
 
TCC ANDRE ABEKAWA - Fatec (Primeira Versão)
TCC ANDRE ABEKAWA - Fatec (Primeira Versão)TCC ANDRE ABEKAWA - Fatec (Primeira Versão)
TCC ANDRE ABEKAWA - Fatec (Primeira Versão)
 
Monografia sobre crowdsourcing + crowd testing + processo de teste de software
Monografia sobre crowdsourcing + crowd testing + processo de teste de softwareMonografia sobre crowdsourcing + crowd testing + processo de teste de software
Monografia sobre crowdsourcing + crowd testing + processo de teste de software
 
Gestao contexto qos_qoe
Gestao contexto qos_qoeGestao contexto qos_qoe
Gestao contexto qos_qoe
 
UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...
UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...
UTILIZAÇÃO DA METODOLOGIA LEAN STARTUP PARA CRIAÇÃO DE UMA STARTUP: Anál...
 
Dissertacao rev Becker
Dissertacao rev BeckerDissertacao rev Becker
Dissertacao rev Becker
 

Último

Regulamento do Festival de Teatro Negro - FESTIAFRO 2024 - 10ª edição - CEI...
Regulamento do Festival de Teatro Negro -  FESTIAFRO 2024 - 10ª edição -  CEI...Regulamento do Festival de Teatro Negro -  FESTIAFRO 2024 - 10ª edição -  CEI...
Regulamento do Festival de Teatro Negro - FESTIAFRO 2024 - 10ª edição - CEI...
Eró Cunha
 
Filosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestre
Filosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestreFilosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestre
Filosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestre
LeandroLima265595
 
atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...
atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...
atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...
WelitaDiaz1
 

Último (20)

Missa catequese para o dia da mãe 2025.pdf
Missa catequese para o dia da mãe 2025.pdfMissa catequese para o dia da mãe 2025.pdf
Missa catequese para o dia da mãe 2025.pdf
 
Sequência didática Carona 1º Encontro.pptx
Sequência didática Carona 1º Encontro.pptxSequência didática Carona 1º Encontro.pptx
Sequência didática Carona 1º Encontro.pptx
 
VIDA E OBRA , PRINCIPAIS ESTUDOS ARISTOTELES.pdf
VIDA E OBRA , PRINCIPAIS ESTUDOS ARISTOTELES.pdfVIDA E OBRA , PRINCIPAIS ESTUDOS ARISTOTELES.pdf
VIDA E OBRA , PRINCIPAIS ESTUDOS ARISTOTELES.pdf
 
Regulamento do Festival de Teatro Negro - FESTIAFRO 2024 - 10ª edição - CEI...
Regulamento do Festival de Teatro Negro -  FESTIAFRO 2024 - 10ª edição -  CEI...Regulamento do Festival de Teatro Negro -  FESTIAFRO 2024 - 10ª edição -  CEI...
Regulamento do Festival de Teatro Negro - FESTIAFRO 2024 - 10ª edição - CEI...
 
SQL Parte 1 - Criação de Banco de Dados.pdf
SQL Parte 1 - Criação de Banco de Dados.pdfSQL Parte 1 - Criação de Banco de Dados.pdf
SQL Parte 1 - Criação de Banco de Dados.pdf
 
Prova nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptx
Prova nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptxProva nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptx
Prova nivel 3 da XXII OBA DE 2019 - GABARITO POWER POINT.pptx
 
Slides Lição 7, Betel, Ordenança para uma vida de fidelidade e lealdade, 2Tr2...
Slides Lição 7, Betel, Ordenança para uma vida de fidelidade e lealdade, 2Tr2...Slides Lição 7, Betel, Ordenança para uma vida de fidelidade e lealdade, 2Tr2...
Slides Lição 7, Betel, Ordenança para uma vida de fidelidade e lealdade, 2Tr2...
 
Filosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestre
Filosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestreFilosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestre
Filosofia - 1º ano - Ensino Médio do ensino médio para primeiro bimestre
 
QUESTÃO 4 Os estudos das competências pessoais é de extrema importância, pr...
QUESTÃO 4   Os estudos das competências pessoais é de extrema importância, pr...QUESTÃO 4   Os estudos das competências pessoais é de extrema importância, pr...
QUESTÃO 4 Os estudos das competências pessoais é de extrema importância, pr...
 
Slides Lição 06, Central Gospel, O Anticristo, 1Tr24.pptx
Slides Lição 06, Central Gospel, O Anticristo, 1Tr24.pptxSlides Lição 06, Central Gospel, O Anticristo, 1Tr24.pptx
Slides Lição 06, Central Gospel, O Anticristo, 1Tr24.pptx
 
Poema - Maio Laranja
Poema - Maio Laranja Poema - Maio Laranja
Poema - Maio Laranja
 
atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...
atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...
atividade para 3ª serie do ensino medi sobrw biotecnologia( transgenicos, clo...
 
13_mch9_hormonal.pptx............................
13_mch9_hormonal.pptx............................13_mch9_hormonal.pptx............................
13_mch9_hormonal.pptx............................
 
12_mch9_nervoso.pptx...........................
12_mch9_nervoso.pptx...........................12_mch9_nervoso.pptx...........................
12_mch9_nervoso.pptx...........................
 
Tema de redação - A prática do catfish e seus perigos.pdf
Tema de redação - A prática do catfish e seus perigos.pdfTema de redação - A prática do catfish e seus perigos.pdf
Tema de redação - A prática do catfish e seus perigos.pdf
 
Química-ensino médio ESTEQUIOMETRIA.pptx
Química-ensino médio ESTEQUIOMETRIA.pptxQuímica-ensino médio ESTEQUIOMETRIA.pptx
Química-ensino médio ESTEQUIOMETRIA.pptx
 
Currículo Professor Pablo Ortellado - Universidade de São Paulo
Currículo Professor Pablo Ortellado - Universidade de São PauloCurrículo Professor Pablo Ortellado - Universidade de São Paulo
Currículo Professor Pablo Ortellado - Universidade de São Paulo
 
Formação T.2 do Modulo I da Formação HTML & CSS
Formação T.2 do Modulo I da Formação HTML & CSSFormação T.2 do Modulo I da Formação HTML & CSS
Formação T.2 do Modulo I da Formação HTML & CSS
 
Histogramas.pptx...............................
Histogramas.pptx...............................Histogramas.pptx...............................
Histogramas.pptx...............................
 
5. EJEMPLOS DE ESTRUCTURASQUINTO GRADO.pptx
5. EJEMPLOS DE ESTRUCTURASQUINTO GRADO.pptx5. EJEMPLOS DE ESTRUCTURASQUINTO GRADO.pptx
5. EJEMPLOS DE ESTRUCTURASQUINTO GRADO.pptx
 

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

  • 1. CENTRO UNIVERSITÁRIO LUTERANO DE SANTARÉM CURSO DE SISTEMAS DE INFORMAÇÃO FELIPE DOS SANTOS NASCIMENTO UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB SANTARÉM 2012
  • 2. FELIPE DOS SANTOS NASCIMENTO UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB Trabalho de Conclusão de Curso apresentado para obtenção do Grau de Bacharel em Sistemas de Informação pelo Centro Universitário Luterano de Santarém. Orientadora: Profª. Msc. Marla Teresinha Barbosa Geller SANTARÉM 2012
  • 3. FELIPE DOS SANTOS NASCIMENTO UTILIZAÇÃO DE METODOLOGIAS ÁGEIS PARA ADAPTAÇÃO DE UM PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES WEB Trabalho de Conclusão de Curso apresentado para obtenção do Grau de Bacharel em Sistemas de Informação pelo Centro Universitário Luterano de Santarém. Data de Apresentação: _____/_____/_____ _________________________________ ___________ Conceito _________________________________ ___________ Conceito _________________________________ ___________ Conceito
  • 4. Esta obra é dedicada a toda minha família, em especial aos meus pais Gilson e Luzia, minha irmã Fernanda e meus professores e amigos que contribuíram no meu aprendizado enquanto acadêmico.
  • 5. AGRADECIMENTOS Primeiramente a Deus que me deu forças, estrutura e entendimento ao longo dessa trajetória. A minha família, em especial aos meus pais e irmã, que sempre me apoiaram, dando o máximo para que eu pudesse atingir meus objetivos. A minha orientadora professora Marla Geller pelo apoio e confiança e por ter contribuído grandemente com sua experiência e didática neste trabalho. Ao Júnior Tapajós, Diretor Comercial da W3Mais Comunicação Interativa, por ter me dado a oportunidade de alcançar um dos meus objetivos de trabalhar com desenvolvimento web, além de ter contribuído indiretamente com este trabalho. A todos os meus amigos e colegas pelo incentivo e colaboração no decorrer deste trabalho.
  • 6. Não devemos ter medo dos confrontos. Até os planetas se chocam e do caos nascem as estrelas. Charles Chaplin
  • 7. RESUMO Com a crescente demanda por aplicações web e a dificuldade de empresas que trabalham com esse tipo de serviço, de manter um processo organizacional e gerencial no decorrer do desenvolvimento de um produto, de forma a criar somente o necessário quando for preciso, muitas tem adotado metodologias ágeis. Porém, seguem o mesmo padrão do desenvolvimento de software, o que ainda gera transtornos, pois muitas vezes as equipes não 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 específico para o desenvolvimento de aplicações web. O WAAPRO (Processo Ágil para Desenvolvimento de Aplicações Web) utiliza fundamentos de metodologias ágeis como XP, Scrum e P@PSI, porém direcionadas para web. Além de utilizar princípios do Lean, que visa mudar a cultura das equipes de desenvolvimento no que diz respeito ao desenvolvimento enxuto. Para validação do processo ágil WAAPRO foi realizado um estudo de caso, através do desenvolvimento do Portal Guarany, para mostrar a utilização do processo ágil. Palavras-chave: Metodologia Ágil. Customização de Processo. Aplicação Web.
  • 8. 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.
  • 9. LISTA DE ILUSTRAÇÕES Figura 1 - Exemplo de Diagrama de Caso de Uso .................................................... 25 Quadro 1 - Descrição 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 Sequência. ....................................................... 28 Figura 5 - Wireframe da página inicial de um site. .................................................... 30 Quadro 2 - Exemplo de uma Planilha de Requisitos ................................................. 29 Figura 6 - Template da aplicação web Dinheirama Online ........................................ 31 Figura 7 - Visão geral do WAAPRO .......................................................................... 41 Figura 8 - Diagrama de Caso de Uso do Portal Guarany. ....................................... 44 Quadro 3 - Descrição dos Casos de Uso do Portal Guarany. ................................... 44 Figura 9 - Diagrama de Caso de Uso do Sistema de Administração do Portal Guarany..................................................................................................................... 45 Quadro 4 - Descrição dos Casos de Uso do Sistema de Administração do Portal Guarany..................................................................................................................... 46 Figura 10 - Wireframe da página inicial do Portal Guarany. ...................................... 47 Figura 11 - Template do site Portal Guarany............................................................. 48 Figura 12 - Sistema de Administração do Portal Guarany......................................... 49 Figura 13 - Diagrama de Classe da funcionalidade Notícia....................................... 51 Figura 14 - Diagrama de Classe da funcionalidade Rádio Interativo ......................... 52 Figura 15 - Diagrama de Classe da funcionalidade Mural de Recados ..................... 52 Figura 16 - Diagrama ER - Notícia. ........................................................................... 53 Figura 17 - Diagrama ER - Rádio Interativo. ............................................................. 54 Figura 18 - Diagrama ER - Mural de Recados. ......................................................... 54 Figura 19 - Diagrama de Sequência da ação comentar Notícia ................................ 56 Figura 20 - Diagrama de Sequência da ação comentar Rádio Interativo .................. 57 Figura 21 - Diagrama de Sequência da ação de enviar recado através do Mural de Recados .................................................................................................................... 58
  • 10. SUMÁRIO 1 INTRODUÇÃO ....................................................................................................... 12 2 VISÃO GERAL DO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB ............. 14 2.1 INÍCIO DO PROJETO ......................................................................................... 14 2.2 PROGRAMAÇÃO ................................................................................................ 15 2.3 FINALIZAÇÃO ..................................................................................................... 15 2.4 MANUTENÇÃO ................................................................................................... 15 3 METODOLOGIAS ÁGEIS UTILIZADAS NA CUSTOMIZAÇÃO DO PROCESSO WEB WAAPRO ......................................................................................................... 17 3.1 PROCESSOS CUSTOMIZADOS PARA APLICAÇÕES WEB ............................ 17 3.2 PROGRAMAÇÃO 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 Programação em Pares .................................................................................. 21 3.2.6 Propriedade Coletiva...................................................................................... 22 3.2.7 Contrato de escopo negociável .................................................................... 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 Sequência ................................................................................. 27 3.5 OUTROS RECURSOS PARA DOCUMENTAÇÃO NO WAAPRO ...................... 28 3.4.1 Planilha de Requisitos ................................................................................... 28 3.4.2 Documento de Design Funcional .................................................................. 29 3.4.3 Template.......................................................................................................... 30 4 APLICAÇÃO DO LEAN NO PROCESSO ............................................................. 32 4.1 PRINCÍPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE ............... 33 4.1.1 Elimine o desperdício .................................................................................... 33 4.1.2 Amplifique o aprendizado .............................................................................. 33 4.1.3 Entregue o mais rápido possível .................................................................. 33 4.1.4 Respeito .......................................................................................................... 34 4.1.5 Construa com integridade ............................................................................. 34 4.1.6 Visualize o todo .............................................................................................. 34 4.2 OS BENEFÍCIOS DO LEAN ................................................................................ 34 5 MODELO DE CUSTOMIZAÇÃO DO PROCESSO ÁGIL PARA APLICAÇÕES WEB - WAAPRO ...................................................................................................... 37 5.1 O QUE É WAAPRO?........................................................................................... 37 5.2 PLANEJAMENTO................................................................................................ 37 5.3 DESENVOLVIMENTO ......................................................................................... 38 5.4 FINALIZAÇÃO ..................................................................................................... 39
  • 11. 5.5 MANUTENÇÃO ................................................................................................... 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 Análise 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 conteúdo ........................................................................................ 50 6.4.2 Diagramação do Template ............................................................................. 50 6.4.3 Codificação ..................................................................................................... 50 6.5 FINALIZAÇÃO ..................................................................................................... 58 6.5.1 Revisão do Produto........................................................................................ 59 6.5.2 Apresentação do produto ao cliente ............................................................ 59 6.5.3 Entrega do produto ........................................................................................ 59 6.5.4 Treinamento .................................................................................................... 59 6.6 MANUTENÇÃO ................................................................................................... 60 7 CONCLUSÃO ........................................................................................................ 61 REFERÊNCIAS ......................................................................................................... 63 ANEXOS ................................................................................................................... 65
  • 12. 12 1 INTRODUÇÃO Com o crescimento do número de empresas que produzem negócios para seus clientes na internet, e consequentemente, o grande envolvimento de profissionais da área, torna-se necessário encontrar uma maneira de gerenciar o trabalho desses profissionais a fim de gerar produtos de qualidade que agreguem valor ao negócio do cliente. Lidar com pessoas, e nesse caso, clientes, é uma tarefa difícil, pois as mudanças que ocorrem no que se refere a características e requisitos do sistema, durante o desenvolvimento de aplicações web afetam os custos, prazos e muitas vezes a qualidade do produto. Para acompanhar essas mudanças é preciso uma organização. É nesse aspecto que a modelagem ágil ajuda os desenvolvedores e, também, o cliente a compreender o escopo do produto antes, durante e após a finalização do mesmo. É preciso entregar um produto que satisfaça as necessidades do cliente, afinal, esse é o primeiro objetivo do desenvolvimento de software. A utilização 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 são executadas por atores que desempenham um papel no processo (programador, gerente, cliente, etc.). O resultado das atividades são artefatos (código, documentação, 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 aplicações web modernas cuja complexidade não para de crescer. Com a proposta de desenvolver projetos de maneira capaz de responder rápido às mudanças, com foco nas pessoas e na colaboração com o cliente, surgiram as metodologias ágeis que, devido às suas características, possibilitam gerar produto com maior valor agregado e ao mesmo tempo manter pessoas motivadas dentro das corporações (AKITA, 2009 apud TANIGUCHI; CORREA, 2009). A partir da concepção das metodologias ágeis é possível criar um processo ágil voltado para desenvolvimento de aplicações web, que por sua vez, têm foco no
  • 13. 13 produto em si, ou seja, sendo mais importante entregar algo de qualidade sem se prender em intermináveis documentos, eliminando desperdícios e desenvolvendo somente o necessário e quando necessário. Pois, assim como no desenvolvimento de software tradicional, aplicações web estão constantemente sofrendo mudanças durante e após sua implementação, trabalhando assim com releases iterativos e incrementais de entrega. Segundo Bohem e Turner (2004 apud JACYNTHO, 2008) não existe um processo correto ou incorreto, tanto processos rigorosos quanto processos ágeis, ambos têm suas vantagens e desvantagens. Ou seja, é preciso encontrar um ponto de equilíbrio entre as duas abordagens para cada tipo de projeto, e assim definir um processo híbrido que traga benefícios reais. Diante da necessidade de um processo de desenvolvimento voltado para ambientes e aplicações web, será mostrado neste trabalho um processo ágil customizado a partir de metodologias ágeis já existentes, sendo elas: Programação Extrema (XP), Scrum e P@PSI. Este trabalho também cita o conceito Lean, uma metodologia voltada para o desenvolvimento de produtos de forma a eliminar desperdícios 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 capítulos, onde após a introdução o segundo capítulo apresenta uma visão geral do desenvolvimento de uma aplicação web, o terceiro capítulo apresenta as metodologias ágeis utilizadas na customização do processo web WAAPRO, o quarto capítulo mostra a aplicação do Lean no processo proposto, o capítulo cinco exemplifica o modelo de customização do WAAPRO e o capítulo seis apresenta um estudo de caso utilizando como processo ágil o WAAPRO no desenvolvimento de um site.
  • 14. 14 2 VISÃO GERAL DO DESENVOLVIMENTO DE UMA APLICAÇÃO WEB O tópico a seguir descreve a experiência do autor no desenvolvimento de aplicações web e o processo utilizado desde o início de um projeto, passando pela finalização até a manutenção após entrega do produto ao cliente. 2.1 INÍCIO DO PROJETO O projeto de desenvolvimento de uma aplicação web se inicia com uma reunião preliminar com o cliente, a fim de se obter informações sobre a real necessidade para se criar o produto. Neste primeiro momento, é decidido o tipo de produto, podendo variar desde um website informativo, apresentando informações 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 são sites pequenos e específicos para um determinado evento ou ação publicitária. E, também, sistemas on-line, como grandes portais de conteúdo que possuem diversas funcionalidades. Definido o tipo de aplicação 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 aplicação irá conter. Com essas informações em mãos é, então, elaborada uma proposta de desenvolvimento, contendo todas as informações necessárias para iniciar o desenvolvimento do produto. Esta proposta inclui informações detalhadas de cada funcionalidade, as páginas que serão criadas, custo total do projeto, tempo de desenvolvimento e, também o que não será produzido, pois após o contrato fechado o que for solicitado como mudança fora do escopo não fará parte do valor fixado no contrato, este sofrerá um acréscimo. Esta proposta é apresentada ao cliente. Caso haja algum item em discordância, este tem a total liberdade de pedir a reformulação até chegar a um ponto comum com a equipe responsável pelo desenvolvimento da aplicação web. Sendo a proposta aprovada, o início do desenvolvimento dá-se pela criação do layout baseado nas informações previamente coletadas. O layout baseia-se,
  • 15. 15 principalmente, na harmonia de cores e localização das informações. A equipe responsável tem total liberdade para criar algo dentro dos padrões web de usabilidade e, posteriormente, esse layout passa pela aprovação do cliente. 2.2 PROGRAMAÇÃO Uma vez que o layout é finalizado, e o cliente se satisfaça com a localização de cada funcionalidade e informação que a aplicação irá conter, inicia-se o processo de programação, ou seja, a codificação dos requisitos. Durante esta etapa os requisitos podem sofrer alterações, fazendo-se necessário o uso de padrões web de programação que facilitam a manutenção dos códigos a fim de se evitar desperdício de tempo. 2.3 FINALIZAÇÃO Após a finalização da programação de toda a aplicação, esta é testada por completo localmente (off-line), e depois é enviada para um servidor on-line para testes finais. Caso existam falhas, estas são corrigidas, senão, uma nova reunião com o cliente é realizada para apresentação do produto final. Se aprovada, a aplicação fica disponível para o público geral, senão volta para a etapa de programação. 2.4 MANUTENÇÃO No desenvolvimento web, após a entrega da aplicação funcionando corretamente, se inicia mais uma etapa, que é a manutenção do mesmo. Esta etapa engloba desde a atualização do conteúdo, layout e até mesmo mudanças nos requisitos iniciais, como a inclusão de novas funcionalidades. Essa fase de Manutenção deve ser especificada em contrato de forma coerente, pois o cliente pode eventualmente achar que pode requerer qualquer mudança após a finalização do projeto, o que é um equívoco. O desenvolvedor irá realizar qualquer mudança no escopo descrito em contrato, caso seja acrescentada uma nova funcionalidade, o valor do projeto passa por um reajuste. Para isso, há uma negociação prévia com o cliente, para que fique tudo bem claro. É importante
  • 16. 16 ressaltar, que qualquer manutenção solicitada pelo cliente passa pelo gerente de projetos primeiro. Ele, junto com a equipe de desenvolvimento analisa o que pode ser feito e as consequências de tal mudança antes de entrar em processo de implementação. Nem todas as alterações poderão ser realizadas após a finalização do projeto, pois podem comprometer muitas funções. Por isso é importante uma análise de requisitos bem criteriosa, no início do desenvolvimento do projeto.
  • 17. 17 3 METODOLOGIAS ÁGEIS UTILIZADAS NA CUSTOMIZAÇÃO DO PROCESSO WEB WAAPRO Metodologias ágeis são vistas como as melhores alternativas às abordagens tradicionais de desenvolvimento de software. Uma vez que métodos tradicionais surgiram em um contexto de desenvolvimento de software baseado apenas em um mainframe e terminais burros (ROYCE, 1970 apud SOARES, 2004), onde não 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 compõe os projetos, principalmente, desenvolvedores e clientes. A partir disso, houve uma melhoria no processo de codificação, passando a ser guiado por testes e utilizando de forma mais eficiente as práticas da Engenharia de Software. Este capítulo se divide na breve descrição de alguns processos customizados para desenvolvimento de aplicações web, e algumas das principais metodologias ágeis utilizadas no desenvolvimento de software, sendo elas, o Scrum, XP e P@PSI com foco na implantação em ambientes que ainda não utilizam metodologias ágeis como parte do processo de desenvolvimento de software. Essas metodologias serviram de base para a customização do Processo Ágil para Desenvolvimento de Aplicações Web, denominado WAAPRO. 3.1 PROCESSOS CUSTOMIZADOS PARA APLICAÇÕES WEB Existem algumas propostas de processos voltados para aplicações web, como o XWebProcess que foi criado adaptando elementos do XP para lidar com importantes questões de sistemas web, tais como: interfaces com usuário complexas, navegação, requisitos não-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 negócio e de software (HAIRE et tal, 2001 apud JACYNTHO, 2008). Além desses, também pode-se citar o
  • 18. 18 WebPraxis que como propósito ser utilizado no desenvolvimento de aplicativos que rodem em ambientes web e não simplesmente sites estáticos ou dinâmicos (ÁLVARES, 2001). Foi proposto a partir do Praxis, por ser um processo genérico para produção de aplicativos interativos e orientados a objetos. Assim, o WebPraxis herda as características usadas para desenvolvimento de aplicativos comuns desktop e insere outras para atender às necessidades do desenvolvimento web. 3.2 PROGRAMAÇÃO EXTREMA (XP) A Programação Extrema (XP) é uma metodologia para equipes de desenvolvimento pequenas, de duas a dez pessoas, que desenvolvem softwares onde os requisitos do usuário são 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 são vistas quando o software já está em produção, o que ocasiona em impactos econômicos e humanos. A XP visa eliminar os erros durante os processos de desenvolvimento de software, por isso encoraja o diálogo entre membros da equipe e, principalmente, com o cliente, tendo assim feedback diário. A XP segue quatro variáveis, sendo elas: custo, tempo, qualidade e escopo. Além de se basear em cinco valores para conduzir o desenvolvimento, sendo: comunicação, coragem, feedback e simplicidade. Dessa forma, ela tenta prever os problemas antes que estes aconteçam e assim achar a melhor solução para resolvê- los de forma rápida. “Como programadores, nos habituamos a antecipar problemas. Quando eles aparecem mais tarde, ficamos felizes. Quando não aparecem, nem notamos.” (BECK, 2000 apud TELES, 2005). Junto com essas características, foram utilizadas no WAAPRO o ciclo codificar, testar, ouvir e projetar, que são as quatro atividades básicas da XP. Segundo Beck (2004), o código serve como meio de comunicação que expressa intenções táticas 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. 19 código tem que ser projetado para suportar modificações de forma que o sistema seja impactado o mínimo possível em outras partes. No WAAPRO buscou-se utilizar práticas XP que pudessem ser utilizadas também no desenvolvimento web como: Jogo do Planejamento, Entregas Frequentes, Projeto Simples, Design Incremental, Programação em Pares, Propriedade Coletiva e Contrato de escopo negociável. 3.2.1 O Jogo do Planejamento O Jogo do Planejamento determina brevemente o escopo do projeto combinando prioridades de negócios e estimativas técnicas. O desenvolvimento web, assim como o desenvolvimento de software é um diálogo evolutivo entre o possível e o desejável. Assim, segundo Beck (2004) as pessoas da área do negócio precisam decidir sobre:  Escopo – o objetivo de um projeto é entregar um produto que gere valor de negócio ao cliente, porém quanto de um problema precisa ser resolvido para que o sistema tenha valor em produção? A pessoa da área de negócios precisa estar apta a responder questionamentos como esse, entendendo o quanto não é 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 negócios está em posição de decidir isso, muito mais do que um programador, por exemplo.  Composição das versões – basicamente, é preciso saber quanto da aplicação web precisa ser feita para que o produto comece a entregar valor ao cliente.  Datas de entrega – datas são importantes, pois servem como metas. A área técnica está diretamente ligada com a área de negócios, pois fornece a matéria-prima para a tomada de decisão. Portanto, as pessoas da área técnica decidem sobre:  Estimativas – informação sobre quanto tempo levará para implementar uma funcionalidade, por exemplo.
  • 20. 20  Consequências – existem decisões estratégicas de negócios que devem ser tomadas apenas quando há informações sobre as consequências técnicas. 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 consequências.  Processo – a equipe de trabalho precisa ser organizada, para isso é importante programar bem a aplicação web sem se prender a uma cultura fechada.  Cronograma detalhado – os programadores precisam de liberdade para dizer o que deve ser feito primeiro na aplicação web, a fim de reduzir o risco total do projeto. 3.2.2 Entregas Frequentes No desenvolvimento web as mudanças são muito rápidas e os usuários finais esperam sempre algo novo. A prática de Entregas Frequentes diz que se possível, coloque um sistema simples rapidamente em produção e depois libere novas versões em ciclos curtos. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Beck (2004) ainda afirma que a entrega precisa fazer sentido como um todo, de nada adianta entregar versões malfeitas, ou seja, implementar meia função e entregá-la, só para tornar mais curto o ciclo de entrega. 3.2.3 Projeto Simples Basicamente, a XP propõe uso de métodos que tornem o projeto de desenvolvimento mais simples, onde programadores podem utilizar recursos como padrões de projeto e framework na codificação, por exemplo. Tufte (1992 apud BECK, 2004) propõe um exercício para designers gráficos. “Desenhe um gráfico da forma que você quiser. Então apague todos os elementos, desde que você não remova nenhuma informação. O que restar quando você não puder apagar mais nada é o design certo para o gráfico”.
  • 21. 21 Para que um projeto se torne simples é necessário ter funcionalidades ou casos de usos bem definidos, o que nem sempre acontece, pois as mudanças fazem parte do escopo e podem acontecer em qualquer estágio do projeto. Mas é importante fazer somente o que for preciso quando realmente precisar, ou seja, evitar criar algo que não será usado ou que a falta deste não irá ter grandes impactos. 3.2.4 Design Incremental O objetivo do Design Incremental é sempre tornar o código e design mais simples, legível e preparado para mudanças. Deve ter suporte de outras práticas, como a refatoração1 e os teste automatizados para garantir que a equipe seja capaz de solucionar os problemas futuros com mais rapidez. Sato (2009) alerta para a interpretação dessa prática, “seu objetivo não é 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 padrões de desenvolvimento web que podem ser seguidos e que melhoram a legibilidade dos códigos e consequentemente a performance da aplicação, como por exemplo, uso de frameworks. 3.2.5 Programação em Pares Na Programação em Pares existem dois papéis em cada par. O primeiro é aquele indivíduo com o teclado e o mouse que está pensando qual a melhor forma de implementar um método específico. O segundo pensa de forma estratégica:  Essa abordagem como um todo vai funcionar?  Que outros casos de testes podem não funcionar?  Existe uma maneira de simplificar todo o sistema para que o problema simplesmente desapareça? Isso promove o trabalho coletivo e colaborativo, une a equipe e melhora, também, a comunicação e a qualidade do código (SATO, 2009). O aprendizado é 1 Para Beck (2004), refatorar um código significa alterar seu comportamento a fim de remover duplicidade, melhorar a comunicação, simplificar e acrescentar flexibilidade.
  • 22. 22 sempre repassado para toda a equipe, assim há uma maior comunicação de todos que passam a compartilhar de técnicas e ideias novas. 3.2.6 Propriedade Coletiva Mesmo que um programador tenha levado dias em um código, a XP sugere que qualquer um da equipe pode modificar tal código. Isso quer dizer que, não há um dono, “a qualquer momento, qualquer um que perceba uma oportunidade de acrescentar valor a alguma parte do código é obrigado a fazê-lo” (BECK, 2004). A XP sugere que todos sejam donos do sistema inteiro. Obviamente, nem sempre todos da equipe irão conhecer todas as partes do código, mas podem saber um pouco sobre cada parte. Isso dá uma visão mais ampla do sistema, facilitando a execução de refatoração e espalhando conhecimento por toda a equipe. No desenvolvimento web, onde toda a equipe está conectada diretamente ao código, isso é importante, pois não se deve perder tempo solicitando mudanças quando o próprio programador puder melhorar o código. 3.2.7 Contrato de escopo negociável Contratos devem ter fixados tempo, custo e qualidade, deixando o escopo das funcionalidades em aberto para negociação. Isso porque no desenvolvimento de aplicações web as mudanças no decorrer do projeto são 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 mudanças conforme a evolução da aplicação e, também, 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 também é considerado um método específico para o gerenciamento de processo de desenvolvimento de software (LUNA; COSTA; DE
  • 23. 23 MOURA, 2011). Surgiu a partir de um estudo feito por Takeuchi & Nonaka, no qual, notaram que projetos de curta duração, usando equipes pequenas e multidisciplinares, produzem melhores resultados (DE CARVALHO, 2009). Scrum é uma metodologia baseada em simplicidade e adaptabilidade. Um fundamento dessa filosofia é a manutenção da base desse conceito: equipes gerenciáveis. A maioria dos livros aponta equipes de no máximo 9 pessoas, multidisciplinar e motivada. Mas é inescapável a existência de projetos onde essa força de trabalho tem de ser multiplicada, devido ao tamanho do sistema sendo desenvolvido (GOLÇALVES, 2011). Tudo o que acontece sob Scrum é realizado em um período limitado de tempo, denominado Time Boxing. Isso é fundamental para entregar software no menor tempo possível. Além do mais, o Scrum busca a simplicidade. Isso se reflete nos papéis que cada pessoa tem durante o processo de desenvolvimento, são apenas três e não 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 esforça em planejar menos e realizar mais, sendo objetivo nas atividades a serem executadas (GONÇALVES, 2011). O WAAPRO busca a simplicidade dos projetos web, por isso foi um princípio utilizado na customização deste processo, além de imaginar como será o produto final. 3.3.1 Ciclos No processo ágil WAAPRO foi utilizado o elemento Ciclo da gestão iterativa e incremental, que no Scrum é chamado Sprint. Cada Sprint é o período de tempo em que um ou mais incrementos reais são 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 mudanças nos requisitos após a finalização do projeto. O importante aqui é o tempo de vida de um Ciclo, que não deve ultrapassar quatro semanas. No desenvolvimento web a velocidade de desenvolvimento é acelerada, quanto mais rápido se desenvolve uma funcionalidade mais rápido será o feedback da equipe e do cliente.
  • 24. 24 3.3.2 Produto Total As funcionalidades no Scrum são vistas primeiro como um todo, chamado Product backlog, ou seja, tudo o que a aplicação irá conter. Depois disso, passa por um processo de avalição para priorizar as funcionalidades a serem desenvolvidas naquele Sprint, gerando assim um Sprint backlog. No WAAPRO foi adotado a mesma ideia, é necessário visualizar a aplicação web como um todo, não com todas as funcionalidade que pode conter, mas sim o que é necessário para a aplicação se tornar funcional e gerar valor para o cliente. A partir dessa ideia é que as funcionalidades são priorizadas e implementadas no fluxo de desenvolvimento. 3.4 P@PSI “Pode-se descrever o [..] P@PSI, como sendo gerenciado pelo Scrum, adotando práticas XP e com fluxos do Processo Unificado.” (GELLER; KNEBEL; BENTES JÚNIOR, 2007). O processo ágil P@PSI foi criado em 2008 pelo Grupo de Trabalho Ágil (GTA) do Centro Universitário Luterano de Santarém (CEULS/ULBRA), e surgiu com o propósito de auxiliar desenvolvedores de softwares em pequenos projetos para empresas que buscam soluções personalizadas. Por ser um processo ágil customizado, o P@PSI possui algumas práticas já testadas como o uso de modelos para representar aspectos do sistema e também o ciclo iterativo oriundo do Processo Unificado. Alguns desses recursos também podem ser utilizados no desenvolvimento de aplicação web e foram utilizados, principalmente, para servir de documentação dos projetos. Serão apresentados os diagramas mais comuns que podem facilitar a documentação 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 farão a
  • 25. 25 interação com os usuários (MELO, 2009). O caso de uso é utilizado para representar os requisitos do sistema, ou seja, o que a aplicação deve fazer a fim de atender as necessidades dos interessados, principalmente os clientes. Através de um caso de uso é possível descrever o funcionamento de uma funcionalidade de maneira informal, sendo de fácil assimilação por clientes que acompanham um projeto. Os principais conceitos associados ao Diagrama de Caso de Uso são: atores, e casos de uso. Figura 1 - Exemplo de Diagrama de Caso de Uso Fonte: Arquivo pessoal, 2012. Além da forma visual, é bom utilizar um quadro descritivo (quadro 1) para cada caso de uso, assim, mesmo depois de muito tempo da finalização de um projeto, caso surja alguma alteração, o desenvolvedor saberá exatamente porque aquele caso de uso foi feito e o que ele representa na aplicação web. Quadro 1 - Descrição dos Casos de uso mostrados na figura 1. O usuário efetuará Login para ter acesso ao Fazer Login sistema Fazer Cadastro O usuário faz seu cadastro no sistema. Comprar Produto O usuário efetua a compra de um produto. Verificar se os dados do usuário já estão na Validar Dados base de dados e se estão corretos. O sistema valida a compra e fornece para o Dar Desconto usuário um campo para inserir seu código de desconto. Fonte: Arquivo pessoal, 2012.
  • 26. 26 3.4.2 Diagrama de Classes O Diagrama de Classes (figura 2) é utilizado para modelar a visão estática do projeto de um sistema. Nele mostra-se um conjunto de classes, interfaces e colaborações e seus relacionamentos de dependência, generalização e associação (BOOCH; RUMBAUGH; JACOBSON, 2005). Também ajuda a visualizar a estrutura de classes antes de implementá-las, e assim, corrigir eventuais erros. Cada classe funciona em colaboração com outras e não sozinhas, a fim de se fazer sentido. Figura 2- Exemplo de Diagrama de Classes. Fonte: Arquivo pessoal, 2012. 3.4.3 Diagrama ER A partir do Diagrama de Classes (figura 2) pode ser feito um mapeamento das classes em tabelas através do Diagrama ER (figura 3), em que este representa o modelo relacional das tabelas. Dependendo do padrão de codificação, com a base de dados pronta, fica mais simples codificar as classes do projeto. Porém, são necessários ambos os diagramas para modelar as aplicações web antes de qualquer codificação.
  • 27. 27 Principalmente no desenvolvimento web, a modelagem da base de dados é muito importante, pois a partir dela o sistema pode responder de forma rápida ou não. Por exemplo, às vezes os desenvolvedores não se preocupam com a quantidade de usuários que a aplicação pode suportar simultaneamente, uma modelagem da base de dados errada junto com uma programação malfeita pode comprometer toda a aplicação, podendo às vezes, ficar inacessível ou lenta. Figura 3 - Exemplo de Diagrama ER Fonte: Arquivo pessoal, 2012. 3.4.4 Diagrama de Sequência Um Diagrama de Sequência é um artefato que ilustra - para um cenário específico de um caso de uso, com o auxílio das classes identificadas num modelo de classes - os eventos de entrada e saída relacionados num sistema, como troca de mensagens, dentro de uma linha de tempo sequencial. Na modelagem do Diagrama de Sequência (figura 4) cada item descrito nos cenários 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. 28 Figura 4 - Exemplo de Diagrama de Sequência. Fonte: GELLER, 2012.2 O P@PSI também possui uma herança do Processo Unificado que são os fluxos iterativos, no qual o processo possui: Planejamento, Desenvolvimento e Encerramento. No WAAPRO também foram utilizados fluxos iterativos, porém os fluxos são Planejamento, Desenvolvimento, Finalização e Manutenção, sendo descritos no capítulo 5. 3.5 OUTROS RECURSOS PARA DOCUMENTAÇÃO NO WAAPRO Alguns recursos são válidos no desenvolvimento de aplicações 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 informações feitas no levantamento de requisitos. Esse recurso é importante para orientar os desenvolvedores sobre as funcionalidades do sistema que interagem entre si, facilitando a manutenção dos mesmos, em caso de modificações durante ou após a implementação. Para isso, a planilha especifica um código único para cada funcionalidade ou ação que a aplicação irá conter, além de 2 Geller, Marla. (Centro Universitário Luterano de Santarém). Comunicação pessoal. Santarém, 2012.
  • 29. 29 um campo descritivo, categoria que indica o tipo do requisito, prioridade, dificuldade, status se o requisito já foi implementação ou não, e comentários adicionais. Essa planilha é atualizada a cada iteração 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 Aplicação web Dificuld Cod Requisito Prioridade ade Atendido Comentários F001 Inserir/Alterar/Excluir Enquete. Baixo Baixo Não Todo comentário deve gravar o IP do IP não deve ser F002 usuário Alto Baixo Sim exibido para usuário. F003 Listar Notícias por Categoria Médio Médio Não Somente usuário nível "Master" pode F004 cadastrar Novos usuários Alto Alto Sim Fonte: Arquivo pessoal, 2012. 3.4.2 Documento de Design Funcional O Documento de Design Funcional é um conjunto de Wireframes onde cada um representa cada página da aplicação. O Wireframe (figura 5) representa a arquitetura de uma página web com a disposição dos elementos, mas não é função demonstrar a estética, como conjunto de cores e fontes, por exemplo. Entretanto, serve como esboço para o designer produzir os Templates da aplicação.
  • 30. 30 Figura 5 - Wireframe da página inicial de um site. Fonte: Arquivo pessoal, 2012. 3.4.3 Template O Template, também chamado de Protótipo de Interface, como mostra a figura 6, pode representar parte da aplicação 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 aplicação. Além disso, este recurso fornece ao cliente uma prévia, ainda que não funcional, de como será a interface da aplicação, demonstrando principalmente o conjunto de cores. Por isso é importante o cliente aprovar o Template antes de este ser implementado.
  • 31. 31 Figura 6 - Template da aplicação web Dinheirama Online Fonte: DINHEIRAMA ONLINE, 2012. Como visto no capítulo, o WAAPRO possui vários recursos que tem origem em processos já existentes. Outros foram inseridos para atender às características de aplicações web.
  • 32. 32 4 APLICAÇÃO DO LEAN NO PROCESSO A maioria das empresas que querem adotar processos ágeis não fazem uso de boas práticas de engenharia de software, e adotar qualquer procedimento pode ser difícil. Por esse motivo, criou-se um conceito que tem como objetivo auxiliar as empresas a equilibrar corretamente o uso de práticas, princípios e valores em todos os níveis de uma organização, promovendo assim, uma mudança segura e sustentável na cultura interna e nos métodos de desenvolvimento e assim criar uma empresa efetivamente ágil e enxuta. O suporte à mudança precisa ser geral, não somente da gerência executiva, mas também do chão de fábrica. Normalmente, a primeira reação das pessoas é a resistência – sendo assim, imposição nunca será o melhor caminho. É preciso abrir espaço, dar as ferramentas adequadas e criar um ambiente que seja propício à mudança (CRESCÊNDIO, 2011). O Lean é uma filosofia de negócio baseada no Sistema Toyota de Produção. Durante 25 anos a Toyota aperfeiçoou seu sistema enxuto e provou que pode ser competitiva, tornando-se a maior e mais lucrativa montadora de automóveis. Através desse pensamento Lean, é possível identificar o que gera valor na visão dos clientes e usuários. O ponto inicial para o pensamento Lean é reconhecer que apenas uma fração do tempo total e esforço de uma organização adicionam, de fato, valor ao cliente. Apesar dos princípios e conceitos gerais sobre essa abordagem já terem mais de 50 anos, só recentemente é que estes passaram a ser conhecidos e terem uma devida aceitação. Isso mostra que a economia mundial afeta muitas empresas, deixando muitas em dificuldades para sobreviver, lutando para reduzir custos sem prejudicar a qualidade e serviço ao cliente. A visão do Lean além de evitar o desperdício é produzir serviços ou produtos de qualidade e que gerem valor para o cliente. De forma simplificada, valor consiste nas características perceptíveis ao cliente, que cada produto ou serviço proporciona ao seu negócio. Por exemplo: preço, qualidade, prazo de entrega, atendimento prestado, funcionalidades de acordo com as necessidades especificadas. Ou seja, o produto ou serviço exatamente como o cliente deseja.
  • 33. 33 4.1 PRINCÍPIOS LEAN PARA O DESENVOLVIMENTO DE SOFTWARE Neste tópico são mostrados os princípios do Lean direcionados para o desenvolvimento de aplicações web, tais como, eliminar o desperdício, amplificar o aprendizado, entregar o mais rápido possível, respeitar, integrar e visualizar o todo. 4.1.1 Elimine o desperdício Evite fazer mais que o necessário. Elimine qualquer coisa que não agregue valor ao produto e que não são percebidas pela cliente. Por exemplo, se o time entrega funcionalidades incompletas, se produz documentação de análise apenas para estar em concordância com o processo, se não prioriza casos de uso e implementa mais funcionalidade que o necessário de imediato. Isso tudo é desperdício. 4.1.2 Amplifique o aprendizado É importante ter um processo de desenvolvimento que encoraje a sistemática de aprendizagem ao longo do ciclo de desenvolvimento. Os desenvolvedores têm que ter a capacidade de responder rapidamente a mudanças de requisitos por parte do cliente. Um código sofre constantes mudanças, portanto, é preciso codificar de forma simples, geralmente orientado a testes. Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de redução de variações, e por essa razão, aprender a abordagem de desenvolvimento resulta em práticas que são bastante diferentes do que aprender abordagens de práticas de produção (DAVIDSON, 2010). 4.1.3 Entregue o mais rápido possível Segundo Crescêndio (2011), há duas grandes razões para entregar rápido: para que o cliente não mude de ideia enquanto um projeto está em desenvolvimento e para que o concorrente não entregue antes. Além disso, reduzir os ciclos e entregar rápido e de forma incremental permite feedback e aprendizado sobre o que
  • 34. 34 está sendo feito. Assim, é que preciso descobrir como entregar uma aplicação funcional tão rápido que clientes não tenham tempo para mudar suas ideias. 4.1.4 Respeito Respeitar as pessoas do ponto de vista do Lean não significa aplicar apenas o bom senso e a boa educação. 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, são exemplos de respeito. “Um ambiente Lean dá espaço para que todos possam aprender abertamente sobre esse tipo de problema e assim resolvê-los de uma forma adequada” (CRESCÊNDIO, 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 usuários podem notar. Para que se tenha integridade, é preciso uma comunicação efetiva, criando assim, um fluxo contínuo de informações entre desenvolvedores, usuários e clientes. 4.1.6 Visualize o todo Este princípio valoriza o aprendizado do ambiente de desenvolvimento, todas as pessoas precisam enxergar e compreender o todo e criar uma organização que contribua para a melhoria de seus processos. Por exemplo, se uma equipe tem especialistas em certas partes de um código e só eles conseguem mexer lá, certamente as demais pessoas da equipe não estão vendo o todo. 4.2 OS BENEFÍCIOS DO LEAN Mesmo com origem em um ambiente de produção industrial, o Lean passou a ser aplicado em empresas de diversos setores e atividades. De modo geral, é possível identificar os mais significativos benefícios resultantes da aplicação “pensamento Lean” nas empresas, que podem ser resumidos da seguinte forma:
  • 35. 35  Crescimento do negócio;  Aumento da produtividade;  Aumento da satisfação do cliente;  Aumento da qualidade e do serviço prestado ao cliente;  Maior envolvimento, motivação e participação das pessoas;  Redução das áreas de trabalho;  Aumento da capacidade de resposta;  Redução 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 é fácil, requer o envolvimento e o compromisso de todos. Nesse tempo, as empresas passam por vários estágios de desenvolvimento, e nessas etapas é necessário estabelecer metas e objetivos, quantificar resultados e atuar em função de desvios. Alguns requisitos para o sucesso são:  Envolvimento da gestão de topo;  Aderir ao conceito “O cliente em primeiro lugar”;  Estar consciente em relação aos problemas;  Gerenciar o processo através de resultados e fatos;  Criar qualidade em tudo que se faz;  Implementar as mudanças envolvendo todas as pessoas. As metodologias ágeis são um processo de melhoria que uma empresa pode adotar para desenvolver aplicações web com melhor qualidade, seguindo um padrão para documentação do que está sendo construído, eliminando desperdícios, 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 práticas e acabar atrasando o cronograma de entrega do produto. É preciso saber quando usar cada recurso das metodologias ágeis. Uma solução apresentada para esse problema é a prática Lean, que surge com a finalidade de ser o caminho para a mudança do estado atual da empresa (sem práticas ágeis) até o uso efetivo de uma metodologia ágil. Acredita-se que o Lean junto com o processo ágil WAAPRO pode tornar uma
  • 36. 36 equipe mais eficiente ao produzir aplicações web que gerem valor de negócios para o cliente.
  • 37. 37 5 MODELO DE CUSTOMIZAÇÃO DO PROCESSO ÁGIL PARA APLICAÇÕES WEB - WAAPRO Diante da crescente necessidade de um processo de desenvolvimento ágil voltado para aplicações web, foi proposto um modelo capaz de suprir os objetivos dos desenvolvedores, no que diz respeito a uma melhor organização dos projetos. A seguir, será descrito o processo WAAPRO (Processo Ágil para Desenvolvimento Aplicações Web) e as características utilizadas do XP, SCRUM e P@PSI. 5.1 O QUE É WAAPRO? WAAPRO é um processo ágil customizado com o objetivo de tornar projetos de aplicações web organizados, no que diz respeito aos ciclos de desenvolvimento e documentação utilizada, e ser de fácil aceitação para desenvolvedores com pouca ou nenhuma experiência no desenvolvimento de projetos utilizando metodologias ágeis. O WAAPRO é dividido em quatro fases, Planejamento, Desenvolvimento, Finalização e Manutenção, como mostra a figura 7. A seguir serão explicadas as fases do processo. 5.2 PLANEJAMENTO A fase de Planejamento se inicia com o Levantamento e Análise de Requisitos. Neste momento, ocorre a primeira entrevista com o cliente, onde este expõe suas necessidades e seus objetivos com o desenvolvimento de uma aplicação web. É extremamente importante a equipe levantar todas as informações que possam ser utilizadas no decorrer do projeto. Com as informações coletadas, a equipe começa a trabalhar nas estórias de usuário, ou seja, analisam cada situação proposta pelo cliente e as transformam em uma funcionalidade como, por exemplo, “Cadastrar Notícia”, representando através de um diagrama de caso de uso. Esse é o início da documentação do projeto. Com base nesses dados, é elaborada uma Proposta de Desenvolvimento, que é um documento que expressa todas as informações do projeto, no que diz respeito ao tempo de desenvolvimento, funcionalidades a serem desenvolvidas, mídias e
  • 38. 38 conteúdos a serem inseridos, o que o projeto não irá conter, ou seja, o que não faz parte do escopo do projeto, e o custo total. Em seguida, é realizada uma nova reunião com o cliente para apresentar a Proposta de Desenvolvimento. Neste momento, o cliente decide se dará ou não continuidade ao projeto. Caso ele não esteja de acordo com alguma especificação no documento, pode solicitar alteração. Sendo aprovado, o projeto segue para o início da criação do briefing. De acordo com Waiteman (2005 p. 38), briefing consiste em: [...] no máximo, duas páginas com informações dissecadas e organizadas, que representam tudo o que o cliente deseja da agência. 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 solução [...]. O briefing é o documento que auxilia todos da equipe a ter conhecimento sobre o cliente e, mais, serve para os responsáveis pela criação do template produzirem as interfaces com base nas informações contidas no briefing. Durante a criação do template é necessário, também, criar um modelo de organização, uma forma de melhor exibir as informações para o usuário, tornando a aplicação fácil de utilizar e navegar. Após o template finalizado, é necessária a aprovação do cliente, havendo alterações, o processo retorna para a etapa de Criação do template e Modelo de Organização, caso contrário é iniciado a etapa de Desenvolvimento. 5.3 DESENVOLVIMENTO Com o início da fase de Desenvolvimento, o template passa por um refinamento, ou seja, são coletadas e ajustadas as mídias e conteúdos que serão implementados na aplicação web. É o conteúdo solicitado previamente ao cliente, como imagens, vídeos, produção de textos, etc. Após o refinamento do template se inicia o ciclo de codificação dos casos de uso, que está divido em três etapas e não deve ultrapassar o período de quatro semanas, sendo: Codificar funcionalidades, propriamente dito, escrever os códigos e toda a logica de programação, independente das ferramentas e tecnologias utilizadas, a
  • 39. 39 codificação tem que ser simples e de fácil manutenção. Para isso, são utilizados alguns padrões de desenvolvimento, como programação orientada a objetos, frameworks de desenvolvimento ágil, padrões de programação para uso de banco de dados, entre outros. Para cada código escrito, são feitos testes, a fim de se certificar, que além de estar funcionando devidamente, não possui problemas quando for relacionado com outros elementos da aplicação. Com a funcionalidade devidamente codificada, segue-se para a fase de implementação. Nesse momento, o código vai ser integrado a outros, podendo ser, ao código principal da aplicação. Em caso de erros, estes são corrigidos e vários testes são feitos para que ao final do ciclo, a aplicação não apresente problemas. Para que não haja nenhuma falha, a funcionalidade ainda passa por mais testes, são os Testes de Funcionalidade. Nesse momento, a funcionalidade já está ativa na aplicação, mas é necessário certificar que tudo está em perfeita ordem para uso pelos usuários. Os testes servem para encontrar falhas, assim são simuladas as ações do usuário, caso seja encontrado algum erro, o ciclo não é finalizado e retorna para a implementação, ou se necessário, para a codificação da funcionalidade. Para finalizar o processo de Desenvolvimento, é preciso fazer a integração das mídias e conteúdo às funcionalidades. Por exemplo, seguindo o exemplo dado anteriormente com a funcionalidade “Cadastrar notícia”, os itens necessários para cadastrar uma notícia seriam: texto, imagens, vídeos. Feito a inserção desse material, a funcionalidade está concluída e o ciclo continua até que todos os casos de uso sejam concluídos. 5.4 FINALIZAÇÃO Na fase de Finalização entende-se que o produto já está completo, necessitando apenas de revisão. Nesse primeiro momento, são realizados testes em todo o produto, testando cada funcionalidade e revisando todos os textos, bem como revisão ortográfica nas palavras. Se tudo estiver pronto, o produto é então apresentado para o cliente. Caso, o cliente não esteja satisfeito com algum detalhe, o produto então retorna para o Refinamento do Template (fase de Desenvolvimento), para que os detalhes possam ser reavaliados e as alterações sejam feitas. Não havendo nenhum questionamento por
  • 40. 40 parte do cliente, o produto é então entregue, sendo necessário apenas o treinamento para utilização da plataforma de administração da aplicação web, quando necessário. 5.5 MANUTENÇÃO No modelo tradicional de desenvolvimento de software, o produto geralmente é finalizado na fase de encerramento, não tendo uma fase que contemple a manutenção do mesmo. Porém, no desenvolvimento web, as mudanças são contínuas, e não se pode dizer que o produto está finalizado após a entrega ao cliente e ao seu treinamento. Pois mesmo após essas etapas, a aplicação pode sofrer mudanças. Para solucionar esse problema é necessária uma fase de Manutenção. Nessa fase é solicitada pelo cliente a alteração 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 revisão da alteração, na fase de Finalização, até a apresentação da alteração para o cliente. Assim, pode-se dizer que a manutenção é uma consequência da entrega do produto, porém cada mudança solicitada termina na fase de Finalização, porque passa por todas as etapas dessa fase em um ciclo contínuo.
  • 41. Figura 7 - Visão geral do WAAPRO Fonte: Arquivo Pessoal, 2012. 40
  • 42. 42 6 ESTUDO DE CASO Este capítulo apresenta um estudo de caso, onde o processo ágil WAAPRO foi utilizado na empresa W3Mais Comunicação Interativa, para o desenvolvimento de um site interativo para a empresa Sistema Guarany de Comunicação. O site pode ser visualizado através do link <http://www.portalguarany.com.br>. 6.1 O CLIENTE O Sistema Guarany de Comunicação é um grupo formado pela Rádio Guarany FM, TV e Portal Guarany. A Rádio Guarany FM foi inaugurada em 1981 com a ideia de expandir os trabalhos que foram iniciados com o serviço de propaganda volante Guarany e cobertura de eventos religiosos. Atualmente a rádio opera na frequência 100,3 Mhz e tem ouvintes de todas as faixas etárias, sendo a mais popular na cidade de Santarém (PORTAL GUARANY, 2012). Retransmissora da Rede Record de Televisão, a TV Guarany, “desde sua formação proporciona entretenimento, descontração e jornalismo opinativo de credibilidade mais perto do povo.” (PORTAL GUARANY, 2012). O Portal Guarany foi criado para suprir a necessidade de uma comunicação mais ampla via internet com os ouvintes, telespectadores e internautas. Assim, a Rádio 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 Rádio Guarany e os apresentadores dos programas, bem como servir como portal de conteúdo com notícias regionais e do território brasileiro. As funcionalidades principais são: Rádio Interativo, Notícias, Mural de Recados e Programação da Rádio. Outras funcionalidades secundárias também fizeram parte do projeto, como: Galeria de fotos, Feed de posts do Twitter, Feed de notícias do Portal R7 3, sistema 3 Portal de conteúdo da Rádio e Televisão Record S/A.
  • 43. 43 de Publicidade, código de rastreamento do Google Analytics e também, o link para ouvir a rádio on-line. 6.3 PLANEJAMENTO A fase de Planejamento inicia-se através do contato com o cliente, no caso o cliente é o Sistema Guarany de Comunicação. Esta fase inclui o Levantamento e Análise de Requisitos para entender as necessidades do cliente e quais funcionalidades o site irá conter; Proposta de Desenvolvimento que é a elaboração de um documento com as informações 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 Análise de Requisitos A fase inicial do projeto diz respeito à avaliação da situação e das necessidades do cliente. Na primeira reunião o cliente expôs suas necessidades. Primeiramente, o site deveria ter uma seção específica em que o usuário pudesse responder a questionamentos diários, sempre uma pergunta polêmica sobre a atualidade. Esses comentários seriam lidos pelo apresentador do programa Rádio Interativo ao vivo, portanto os dados deveriam ser validados de modo que um usuário não se passasse por outro. Segundo, uma seção tipo mural de recados, onde os usuários pudessem enviar mensagens para qualquer pessoa. Terceiro, uma área especial de notícias com quatro categorias específicas (Santarém, Pará, Brasil, Mundo). Quarto, mostrar o programa que a rádio estaria apresentando no momento em que o usuário acessasse o site, além de um link que ao ser clicado, o usuário pudesse ouvir a rádio ao vivo. Outras necessidades também foram mencionadas, como ter uma galeria de fotos, onde o administrador pudesse cadastrar fotos dos eventos do Sistema Guarany de Comunicação. Uma forma de exibir as notícias do Portal R7 e as publicações 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 informações foi necessário transformar essas estórias de usuário em funcionalidades que o site iria conter. Para isso, foi elaborado um
  • 44. 44 Diagrama de Caso de Uso, que serviu para melhorar a visualização de todos os recursos que o site poderia oferecer. A figura 8 mostra as funcionalidades exibidas para os usuários, ou seja, o front-end4 do site. Figura 8 - Diagrama de Caso de Uso do Portal Guarany. Fonte: Arquivo pessoal, 2012. Para que o diagrama fique mais bem explicado, estão descritos todos os casos de uso (quadro 3). Quadro 3 - Descrição dos Casos de Uso do Portal Guarany. Apresenta as mensagens enviadas de Comentar Mural de Recados um usuário para outro. Exibe as notícias de todas as categorias em ordem de postagem. Visualizar Notícias Todas as notícias tem formulário para postagem de comentários com moderação pelo administrador. Uma pergunta com opção para o usuário comentar com os campos: Comentar Rádio Interativo nome, bairro e comentário. O comentário só fica visível após a 4 Área pública visualizada pelo usuário de um site.
  • 45. 45 liberação pelo administrador. Exibe o programa da rádio transmitido no momento e uma foto do Visualizar Programação ao vivo apresentador. Também exibe um link para o usuário ouvir o programa on-line. Link externo para o usuário ouvir a Ouvir Rádio on-line rádio on-line. Exibe postagens da conta Visualizar Feed Twitter @portalguarany no Twitter. Visualizar Feed Portal R7 Exibe notícias do Portal R7. Exibe fotos separadas por galerias Visualizar Galeria de fotos (álbuns). Fonte: Arquivo pessoal, 2012. O Portal Gurany possui funcionalidades que apenas podem ser vistas pelos administradores do site. Para não haver confusão no desenvolvimento, foi feito um novo Diagrama de Caso de Uso, mostrado na figura 9, apresentando as funcionalidades acessíveis para os usuários da administração do site. Como mais de uma pessoa teria acesso, foi solicitado que os usuários tivessem níveis de acesso. Portanto, ficou definido que o nível Master teria acesso a todas as funcionalidades do sistema de administração e o nível Web Master teria acesso apenas à liberação de conteúdo, não podendo cadastrar novos usuários, por exemplo. Figura 9 - Diagrama de Caso de Uso do Sistema de Administração do Portal Guarany. Fonte: Arquivo pessoal, 2012.
  • 46. 46 Quadro 4 - Descrição dos Casos de Uso do Sistema de Administração do Portal Guarany. Possibilita inserir, alterar, excluir e Manter Notícias consultar notícias publicadas. Possibilita inserir, alterar, excluir os Manter Administrador administradores do site. Possibilita inserir, alterar e excluir Manter Destaque imagens em destaque na página inicial (slideshow) do site. Possibilita inserir, alterar, excluir e Manter Programação ao vivo consultar os programas da Rádio Gurany FM. Possibilita inserir, alterar, excluir e Manter Galeria de fotos consultar galerias de fotos publicadas no site. Possibilita consultar, publicar e excluir comentários publicados pelos ouvintes. Manter Rádio Interativo Além de poder inserir, alterar status e excluir as perguntas. Possibilita inserir e excluir as Manter Publicidade publicidades do site. Possibilita publicar e excluir comentários Manter Mural de recados feitos pelos internautas do site. É através desta funcionalidade que o Fazer Login administrador pode ser acesso ao sistema administrativo. Fonte: Arquivo pessoal, 2012. 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), além de tempo e custo total de desenvolvimento. Sabendo que o site iria ter páginas informativas e estáticas, como conteúdo sobre a empresa, serviços, área comercial e formulário de contato, esses itens foram inseridos na proposta. Algo muito importante é a verificação de disponibilidade do domínio do site. O domínio deveria ser portalguarany.com.br, que foi verificado e comprado junto ao site Registro.br, responsável pelo registro de domínios brasileiros.
  • 47. 47 6.3.3 Briefing Após a aprovação da Proposta de Desenvolvimento pelo cliente foi necessário elaborar um briefing (ver anexo B) com informações relevantes para o desenvolvimento do site, como informações sobre o Sistema Guarany de Comunicação, a identidade visual, e o que seria utilizado no design do site. Essas informações são úteis no processo criativo do designer responsável por criar o Template do site e das páginas que este contém. 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 disposição do layout e pode ser visto abaixo, na figura 10. Figura 10 - Wireframe da página inicial do Portal Guarany. Fonte: Arquivo pessoal, 2012.
  • 48. 48 A partir do wireframe o designer começou a trabalhar na parte estética do site, ou seja, o desenho com as cores e imagens dispostas no layout. Essa etapa exigiu bastante criatividade, mas com o briefing em mãos a tarefa de construir o template ficou mais fácil, pois já se sabia que a cor principal seria um tom de verde e cores variadas que indicassem cada seção do site, como mostra a figura 11. Terminado o template, este precisou ser aprovado pelo cliente. Para isso, em uma reunião o template foi apresentado e com poucos questionamentos, logo foi aprovado, dando sequência ao desenvolvimento. Figura 11 - Template do site Portal Guarany. Fonte: Arquivo pessoal, 2012.
  • 49. 49 Também é necessário criar o layout para o sistema de administração do site, como mostra a figura 12. Nesse caso, não foi necessário passar pela aprovação do cliente, pois essa parte do sistema apenas foi adaptada para o site Portal Guarany, uma vez que a tecnologia é licenciada pela W3Mais Comunicação Interativa mediante contrato. Isso gera um ganho de tempo na inclusão e exclusão de funcionalidades no desenvolvimento de novas aplicações. Figura 12 - Sistema de Administração do Portal Guarany. Fonte: Arquivo pessoal, 2012. 6.4 DESENVOLVIMENTO O projeto Portal Guarany possui muitas funcionalidades, portanto foi necessário priorizar algumas para iniciar a fase de desenvolvimento. O WAAPRO permitiu ao projeto ser feito em módulos. Neste trabalho é apresentado, na etapa de codificação, o módulo que consiste em três funcionalidades, sendo elas: Mural de Recados, Notícias e Rádio Interativo. Na etapa de desenvolvimento foi testado um princípio 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 código ou uma funcionalidade inteira.
  • 50. 50 6.4.1 Coleta de conteúdo Antes do início do desenvolvimento é necessário ter todo o conteúdo das páginas. É especificado no contrato de desenvolvimento que o cliente tem um prazo para entregar todo o material necessário para o desenvolvimento do site, isso inclui textos, imagens, vídeos ou qualquer conteúdo que precise estar no site no ato da entrega (alguns conteúdos podem ser inseridos pelo próprio usuário através do sistema de administração). Com o conteúdo em mãos o desenvolvimento foi passado para a fase de codificação. 6.4.2 Diagramação do Template A primeira etapa da codificação do site é transformar o Template – que é uma imagem – em código. Isso requer o uso de alguns recursos web como a linguagem de folhas de estilos CSS e o XHTML que é uma linguagem de marcação semântica. No CSS ficam as regras do que será exibido das páginas, como cores, fundos, tamanhos de divs5, posicionamento de divs, fonte do texto, etc. Cabe ao XHTML separar o conteúdo semanticamente para receber os estilos do CSS. O site fica exatamente igual ao desenho feito pelo designer, porém em forma de códigos prontos para serem implementados em linguagem dinâmica, que especificamente nesse projeto foi utilizado o PHP. 6.4.3 Codificação No Portal Guarany foi utilizado alguns padrões de desenvolvimento como orientação a objetos, MVC e DAO. Isso traz alguns benefícios, como a rapidez na manutenção do código. Para início da codificação 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 métodos de controle. 5 Elemento HTML que define uma divisão na página e pode ter variadas formatações.
  • 51. 51 A funcionalidade Notícia exemplificada pelo diagrama da figura 13 representa que cada notícia tem apenas uma categoria, podendo ser Santarém, Pará, Brasil, Mundo. Além disso, cada notícia pode receber comentários. Figura 13 - Diagrama de Classe da funcionalidade Notícia Fonte: Arquivo pessoal, 2012. A funcionalidade Rádio Interativo, representada na figura 14, mostra que há um relacionamento entre uma questão e um comentário, onde a questão pode receber vários comentários, porém os comentários possuem um status do tipo boolean, que indica que o administrador do sistema é quem publica ou não o comentário.
  • 52. 52 Figura 14 - Diagrama de Classe da funcionalidade Rádio Interativo Fonte: Arquivo pessoal, 2012. 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 usuário pode enviar um comentário para um outro usuário, porém esse comentário só fica visível mediante publicação 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 Fonte: Arquivo pessoal, 2012.
  • 53. 53 Também foi utilizado o Diagrama ER para modelar o banco de dados e para definir as tabelas necessárias para armazenamento de conteúdo. Este tipo de artefato ajuda a entender melhor os relacionamentos entre tabelas. Como mostram as figuras 16, 17 e 18, representando as funcionalidades Notícia, Rádio Interativo e Mural de Recados respectivamente. A partir disso, foi possível criar todo um conjunto de classes que permitem manipular os dados das tabelas. Figura 16 - Diagrama ER - Notícia. Fonte: Arquivo pessoal, 2012.
  • 54. 54 Figura 17 - Diagrama ER - Rádio Interativo. Fonte: Arquivo pessoal, 2012. Figura 18 - Diagrama ER - Mural de Recados. Fonte: Arquivo pessoal, 2012. 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 é característica das metodologias ágeis.
  • 55. 55 Durante o desenvolvimento do Portal Guarany algumas funcionalidades ficaram um pouco confusas na hora da codificação, uma delas foi o caso de uso Rádio Interativo, responsável direto pela interação dos usuários do site com a Rádio Guarany FM. De fato, o cliente queria que cada pessoa que comentasse na Rádio Interativo fosse única e esses comentários deveriam ser moderados pela administração. O problema era como fazer isso da forma mais simples possível e que não dificultasse a forma de interação do usuário com o site. Ao se tentar fazer o que o cliente queria, perdeu-se muito tempo desenvolvendo uma funcionalidade de forma que não gerava valor algum para o cliente e ainda dificultava a interação como usuário. Seguindo a ideia de processo enxuto Lean, para criar algo que realmente trouxesse valor para o negócio do cliente foi feita uma análise de como o Rádio Interativo funcionaria. Uma forma de solucionar o problema foi visualizá-lo melhor com diagramas de sequência. Não só para a funcionalidade Rádio Interativo, mas nesse módulo procurou-se fazer também para a funcionalidade Notícia e Mural de Recados. Na funcionalidade Notícia, representada pelo diagrama de sequência na figura 19, foram discutidos quais campos seriam preenchidos pelo usuário e se o comentário seria moderado pelo administrador ou não. Por fim, a equipe concordou que todos os comentários seriam moderados pelo administrador, onde este poderia apenas excluir ou publicar o comentário, ficando impedido de alterar qualquer informação. Essa análise foi fundamental para desenvolver outras funcionalidades que teriam o mesmo princípio.
  • 56. 56 Figura 19 - Diagrama de Sequência da ação comentar Notícia Fonte: Arquivo pessoal, 2012. Quando foi necessário fazer a codificação da funcionalidade Rádio Interativo, houve uma dificuldade em tentar encontrar a forma mais simples de um usuário comentar um questionamento. O cliente queria que o sistema pudesse identificar fraude em um comentário, ou seja, um usuário não poderia comentar com o nome ou outra informação pessoal igual à outra pessoa. A solução final, e mais simples, foi que o usuário teria três campos para inserir dados, sendo Nome, Bairro e Comentário, pois são as informações que o apresentador do Programa Rádio Interativo lê ao vivo. Todos os comentários são moderados pelo administrador do sistema. Somente após a publicação os comentários ficam visíveis para o usuário e somente enquanto o questionamento estiver no ar. A representação do diagrama de sequência pode ser vista na figura 20.
  • 57. 57 Figura 20 - Diagrama de Sequência da ação comentar Rádio Interativo Fonte: Arquivo pessoal, 2012. Quando a funcionalidade Mural de Recados foi codificada, já se tinha um conhecimento de como ela iria se comportar, porém ainda foi representada através de um diagrama de sequência (figura 21) que mostra a ação de enviar um recado e a publicação do mesmo pelo administrador do sistema. Aqui a funcionalidade segue a mesma ideia das outras, o recado só fica visível após a permissão pelo administrador, e este pode excluir o comentário a qualquer momento, mesmo após a publicação.
  • 58. 58 Figura 21 - Diagrama de Sequência da ação de enviar recado através do Mural de Recados Fonte: Arquivo pessoal, 2012. Como pôde 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 dúvidas, pois muitas vezes uma pessoa da equipe não conseguia visualizar, ou mesmo, fazer o cliente entender como determinada ação acontecia. 6.5 FINALIZAÇÃO Na etapa de Finalização busca-se fazer testes de toda a funcionalidade ou do projeto inteiro pronto a fim de encontrar erros. Também, é caracterizada pela entrega da aplicação para o cliente e o treinamento do mesmo.
  • 59. 59 6.5.1 Revisão 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 revisão do produto é importante por simular a ação do usuário 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 não saíram como planejado, como o caso de uso Ver Programação ao Vivo. No momento do teste percebeu-se que o fuso horário do servidor era diferente do fuso horário brasileiro (Brasília), assim tendo que voltar para o Desenvolvimento até ser corrigido e pronto para apresentar ao cliente. 6.5.2 Apresentação do produto ao cliente O Portal Guarany foi apresentado através de uma reunião da equipe de desenvolvimento com o cliente. Foi demonstrada cada funcionalidade em funcionamento. Após o término da apresentação 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, porém acessível 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 visível na web. 6.5.4 Treinamento A administração do site possui muitas funcionalidades, tudo intuitivo, porém o cliente queria que fosse ministrado um treinamento para duas pessoas responsáveis pela administração do Portal Guarany. O treinamento foi feito de forma presencial e foi realizado em dois dias.
  • 60. 60 6.6 MANUTENÇÃO A fase de Manutenção existiu nesse projeto apenas para edição de alguns textos em páginas estáticas e manutenção 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 Finalização.
  • 61. 61 7 CONCLUSÃO O processo ágil WAAPRO se mostrou eficiente no desenvolvimento de aplicações web, como pôde ser constatado no desenvolvimento do Portal Guarany. O uso de etapas permitiu melhor controle do que se estava fazendo e não deixando a equipe se perder quando ocorriam mudanças nos requisitos. Em algumas etapas do projeto ficou evidente que o uso de um processo ágil ajuda a minimizar desperdícios de tempo, regra fundamental de um processo Lean. Como por exemplo, durante a codificação da funcionalidade Rádio Interativo, os requisitos mudaram diversas vezes, a primeira vez foi produzido algo que o cliente queria, porém não gerava valor algum. Isso foi constatado quando o site foi ao ar durante alguns dias para testes com usuários iniciais. Durante aproximadamente 1 semana, não houve nenhum comentário na Rádio Interativo, isso significava que algo de errado estava acontecendo. Portanto, a funcionalidade foi refeita mais duas vezes, e somente na terceira mudança é que os comentários começaram a aparecer. Para isso, tudo que dificultava a ação de comentar foi retirado. O usuário simplesmente comentava e esperava o comentário ser publicado pelo administrador. O Lean passou a ser fundamental junto com o processo ágil WAAPRO, pois toda a equipe pôde aprender melhor como realizar as atividades focando no produto e no usuário, além de fazer somente o que gerava valor para o cliente. Entretanto a visão do Lean foi superficial. Percebe-se que para o aprendizado de uma metodologia ágil e uma mudança de cultura numa empresa que não utiliza esse tipo de processo de desenvolvimento leva bastante tempo, porque no início é difícil assimilar o funcionamento do processo e mais difícil ainda é abandonar alguns vícios, 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 importância para se ter uma visão mais ampla do que poderia ser utilizado como característica para a criação do WAAPRO, uma vez que essas metodologias já foram bastante testadas. O P@PSI permitiu ter uma melhor ideia de como um processo ágil pode ser customizado e quais seus benefícios. Procurou-se mostrar o funcionamento do WAAPRO através de um estudo de caso para ter a validação do processo ágil junto com uma equipe de desenvolvedores que não utilizavam nenhum tipo de processo específico nos
  • 62. 62 projetos, assim pôde-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, porém levou bastante tempo. Não foi possível verificar o lead time6 em todas as etapas, pois não 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 aplicação web. É importante ressaltar que para que um processo ágil se torne eficiente precisa partir de uma mudança de cultura numa empresa ou na equipe de desenvolvimento. O Lean sugere principalmente para empresas pequenas, uma série de princípios 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 desperdícios, fazer somente o necessário quando for necessário e ter uma organização 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 pôde-se comprovar uma melhora no diálogo e na percepção de erros antes da implementação ou mudança de requisito. Ainda é necessário um aprofundamento na visão Lean para verificar as reais mudanças 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. São necessários mais testes com WAAPRO no desenvolvimento de aplicações web, para se ter uma ideia se todas as etapas funcionam e o que precisa ser melhorado, a partir da visão de outros desenvolvedores. Espera-se, que a partir deste trabalho apresentado sobre a utilização de metodologias ágeis na customização do processo web WAAPRO, possam surgir projetos relacionados com o tema. Pois o mesmo oferece muitos benefícios para os desenvolvedores que queiram manter seus projetos enxutos. 6 Tempo em que se recebe um requisito até a entrega da funcionalidade.