UNIVERSIDADE ANHEMBI MORUMBI ANDRÉ ONUKI DOS SANTOS CLEUMIR DOS SANTOS DE SOUZA TIAGO LUIZ DO NASCIMENTO TASKBOARD DIGITAL PARA EQUIPES SCRUM

Transcrição

1 UNIVERSIDADE ANHEMBI MORUMBI ANDRÉ ONUKI DOS SANTOS CLEUMIR DOS SANTOS DE SOUZA TIAGO LUIZ DO NASCIMENTO TASKBOARD DIGITAL PARA EQUIPES SCRUM São Paulo 2011

2 ANDRÉ ONUKI DOS SANTOS CLEUMIR DOS SANTOS DE SOUZA TIAGO LUIZ DO NASCIMENTO TASKBOARD DIGITAL PARA EQUIPES SCRUM Trabalho de Conclusão de Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Ciências da Computação da Universidade Anhembi Morumbi. Orientador: Luís Fernando Aires Branco Menegueti São Paulo 2011

3 ANDRÉ ONUKI DOS SANTOS CLEUMIR DOS SANTOS DE SOUZA TIAGO LUIZ DO NASCIMENTO TASKBOARD DIGITAL PARA EQUIPES SCRUM Trabalho de Conclusão Curso apresentado como exigência parcial para a obtenção do título de Bacharel em Ciência da Computação da Universidade Anhembi Morumbi, sob a orientação do Prof. Luís Fernando Aires. Aprovado em Prof. Universidade Anhembi Morumbi Prof. Universidade Anhembi Morumbi Prof. Universidade Anhembi Morumbi

4 RESUMO O taskboard pode fornecer diversas informações sobre o andamento de um sprint para a equipe Scrum. Entretanto essas informações nem sempre são fáceis de serem retiradas do taskboard. E requerem que algum membro da equipe fique constantemente verificando o taskboard para poder anotar as informações e trabalhá-las. O objetivo deste trabalho é criar uma ferramenta digital para substituir o taskboard convencional do Scrum. As principais vantagens de um taskboard digital sobre outro comum são a possibilidade de integração com outras ferramentas e a automatização da coleta de dados sobre o sprint. Os dados coletados podem fornecer muitas informações sobre o progresso do sprint e/ou gargalos no processo. Estes dados podem auxiliar o Scrum master a tomar decisões para melhoria do processo ou mostrar com maior antecedência que os prazos do sprint possam estar comprometidos. Outra vantagem do taskboard digital é a possibilidade de pessoas que trabalham em outra localidade utilizarem o mesmo taskboard. PALAVRAS-CHAVE: Scrum. Metodologias ágeis. taskboard.

5 ABSTRACT A taskboard may offer many information about the sprint s progress for a Scrum team. However, these information are not easily taken directly from the taskboard and require that a member of the team is constantly checking the taskboard to collect the data and take the information from it. The goal of this project is to develop a digital tool to replace the conventional taskboard. The main advantages of the digital taskboard over the conventional are the possibility of integration with other tools and data collection automation. The data collected this way may provide information about the sprint s progress and/or bottlenecks on the process. The data may help the Scrum Master to make decisions to improve the process or show in advance that the sprint s deadline may not be reached. Another advantage of the digital taskboard is the possibility of people who work remotely to share the same taskboard the other team members use. KEY WORDS: Scrum. Agile Methodologies. taskboard.

6 LISTA DE FIGURAS Figura 1: O processo scrum Figura 2: Burn down chart Figura 3: Burn up chart Figura 4: Cumulative flow diagram Figura 5: Scrum Ninja Figura 6: Green Hopper Figura 7: Vip Task Manager Figura 8: Padrão MVC Figura 9: Casos de uso Figura 10: Diagrama de classes das entidades Figura 11: Diagrama de classes de controle Figura 12: Diagrama de classes Modelo Figura 13: Tela de login Figura 14: Barra de ferramentas Figura 15: Tela do projeto Figura 16: Diagrama de classes dos diálogos Figura 17: Diagrama de classes interface com o usuário Figura 18: Diagrama de classes criadoras de gráficos Figura 19: Diagrama de classes DAO Figura 20: Diagrama de classes controlador Figura 21: Utilização do sistema

7 LISTA DE TABELAS Tabela 1: Características das Ferramentas Existentes Tabela 2: Requisitos Funcionais Tabela 3: Requisitos Não Funcionais Tabela 4: Casos de Uso... 33

8 LISTA DE SIGLAS CSS3 DAO HTTP JAVA JSP RF RNF SQL UML XML Cascading Style Sheets - Folhas de Estilo em Cascata Data Access Object Objeto de Acesso Dados HyperText Transfer Protocol - Protocolo de Transferência HiperTexto Linguagem de Programação Orientada a Objetos Java Server Pages - Páginas de Servidor Java Requisitos Funcionais Requisitos Não Funcionais Structured Query Language - Linguagem de Consulta Estruturada Unified Modeling Language - Linguagem de Modelagem Unificado Extensible Markup Language - Linguagem de Marcação Extensível

9 SUMÁRIO 1 INTRODUÇÃO Objetivos Justificativa Abrangência Estrutura do Trabalho METODOLOGIAS ÁGEIS Scrum Equipe Scrum Reuniões Artefatos Taskboard Monitoramento Burn Down Chart Burn Up Chart Cumulative Flow Diagram FERRAMENTAS EXISTENTES ScrumNinja GreenHopper Vip Task Manager Comparações de Ferramentas Existentes TECNOLOGIAS E PADRÕES DE DESENVOLVIMENTO Padrão MVC Google Web Toolkit PHP Struts Ruby On Rails HTML Hibernate METODOLOGIA... 28

10 5.1 Framework de Desenvolvimento Web Persistência de Dados Banco De Dados Ambiente de Desenvolvimento Ferramenta para Geração de Gráficos MODELAGEM DO SOFTWARE Requisitos Funcionais e Não Funcionais Casos de Uso Diagramas de Classe Diagramas de Sequência IMPLEMENTAÇÃO DO PROJETO Modelo Visualização Controlador TESTES CONCLUSÃO Trabalhos Futuros REFERÊNCIAS APÊNDICE A CASOS DE USO APÊNDICE B DIAGRAMAS DE SEQUÊNCIA ANEXO A - MANIFESTO ÁGIL... 64

11 11 1 INTRODUÇÃO O Scrum é utilizado para o desenvolvimento de produtos complexos, desde o início da década de [...] Scrum não é um processo ou técnica para criação de produtos, mas uma estrutura na qual você pode empregar vários processos e técnicas. O papel do Scrum é trazer à tona a eficácia relativa de suas práticas de desenvolvimento de modo que você possa melhorá-las enquanto fornece uma estrutura na qual produtos complexos possam ser desenvolvidos (SCHWABER; SUTHERLAND, 2010). O coração e esqueleto do Scrum é o processo interativo e incremental. A saída de cada interação é um incremento no produto e durante cada interação há uma inspeção diária onde os indivíduos inspecionam o trabalho dos outros membros da equipe e fazem as adaptações necessárias. (SCHWABER, 2004). A cada interação, são adicionadas ao produto novas funcionalidades, provenientes do backlog do projeto. Um modo de visualizar tanto as funcionalidades futuras quanto as que estão em desenvolvimento é o taskboard. O SCRUM, nome originário do jogo de rúgbi, teve suas raízes em indústrias japonesas no início de 1986 por Takeuchi e Nonaka, mas começou a ser usado nos moldes atuais apenas em 1996 por Jeff Sutherland e Ken Schwaber. Suas técnicas enfatizam a realização de reuniões diárias, o aumento da autonomia dos membros do time, foco nas entregas e a flexibilidade no seguimento de processos pré-definidos (LARMAN, 2003). Um projeto é caracterizado por possuir objetivo e requisitos claramente definidos (Escopo), obedecer ao orçamento aprovado (Custo) e deve ser finalizado no prazo especificado (Tempo) (SCHWALBE, 2002). Segundo HIGHSMITH(2002) fundador da Agile Alliance e criador do método Adaptative Software Evelopment, define os princípios básicos do gerenciamento ágil de projeto como: Entregar sempre algo útil ao cliente; Manter a equipe sempre comprometida; Construir um ambiente de liderança e colaboração; Construir times competentes e colaborativos;

12 12 Aumentar a autonomia da equipe na tomada de decisões; Usar um processo iterativo com iterações curtas para que seja possível a entrega rápida de novas funcionalidades; Encorajar a adaptabilidade; Buscar sempre a excelência técnica; Focar nas atividades de entrega e não no seguimento de processos pré-definidos. 1.1 Objetivos Este trabalho tem como objetivo criar um software de taskboard para equipe Scrum, chamado dtaskboard, que prevê a retirada de estatísticas a partir do uso do software e respectivos relatórios e terá seu código aberto. 1.2 Justificativa Existem vários softwares para gerenciamento de projetos ágeis ou que utilizam Scrum. Muitos são gratuitos e ou livres. Entretanto, poucos possuem uma interface que possa substituir o taskboard de maneira satisfatória. Alguns softwares comerciais substituem o taskboard, entretanto são softwares proprietários. Em geral, eles possuem licenças caras ou oferecem licenças restritas a projetos de software livre. Entretanto, o mais importante do projeto é a retirada das estatísticas de uso do taskboard. Esses números podem ser bastante importantes para diagnosticar possíveis problemas no projeto. 1.3 Abrangência O software poderá ser utilizado pela internet, para que pessoas mesmo que em locais geograficamente separados possam compartilhar o mesmo taskboard. O software fará autenticação e autorização de usuários, para o controle do executor de cada tarefa.

13 13 Serão possíveis modificações simultâneas por diferentes usuários. A interface com o usuário se dará exclusivamente por meio de um navegador da internet. Haverá uma interface de visualização de relatórios onde serão mostradas as estatísticas disponíveis. Não serão criadas interfaces para taskboards diferentes do Scrum, como o taskboard do Kanban. 1.4 Estrutura do Trabalho Este trabalho é composto de 9 capítulos, que explicam sobre o Scrum e seu taskboard, as ferramentas já existentes para substituir o taskboard convencional e as ferramentas para desenvolvimento de aplicações web. Então são discutidas as decisões de ferramentas utilizadas no projeto, a modelagem do mesmo e a fase de testes. O capítulo 2 é uma descrição dos métodos ágeis. Neste capítulo é descrito o Scrum, sua teoria, seus participantes e componentes. Nele também é descrito o uso do taskboard. No capítulo 3 é feito um levantamento das ferramentas já existentes. Suas funcionalidades. No capítulo 4 apresentam-se várias ferramentas e frameworks para desenvolvimento de aplicações para web. O capítulo 5 é dedicado à metodologia do projeto, ou seja, será apresentado as ferramentas usadas para a elaboração do trabalho. O capítulo 6 é destinado à modelagem do sistema, incluindo o levantamento dos requisitos funcionais e não funcionais do sistema, os casos de uso, diagramas de classes e de sequências. O capítulo 7 apresenta a implementação do projeto, o qual segue o padrão MVC. No capítulo 8 é descrito o teste realizado na empresa Touch Tecnologia. O capítulo 9 destina-se à conclusão do trabalho.

14 14 2 METODOLOGIAS ÁGEIS Nos dias 11 a 13 de fevereiro de 2001, nas montanhas Wasatch de Utah, Estados Unidos, 17 pessoas reuniram-se para discutir sobre a necessidade de um processo de desenvolvimento de software alternativo aos processos da época. Entre eles estavam representantes de Programação Extrema, Scrum, DSDM, Desenvolvimento Adaptativo de Software, Crystal, Desenvolvimento Dirigido por Característica, Programação Pragmática, entre outros simpatizantes da causa. Desta reunião, emergiu o Manifesto Ágil de Desenvolvimento de Software. (HIGHSMITH, 2001). Segundo Abrahamsson (2002), o aspecto focal dos métodos ágeis são a simplicidade e a velocidade. Durante o desenvolvimento, os desenvolvedores concentram-se em entregar as funcionalidades mais necessárias. Entregues estas funcionalidades, são coletados comentários sobre o que foi entregue e reage-se à essa informação recebida. Um processo ágil é: incremental (ciclos rápidos onde são entregues softwares funcionais), cooperativo (clientes e desenvolvedores comunicam-se constantemente), simples (o método é fácil de aprender, modificar e é bem documentado) e adaptativo (capaz de fazer mudanças em último momento). ABRAHAMSSON (2002). 2.1 Scrum Na década de 90, Ken Schwaber e Jeff Sutherland em busca de uma solução mais simples, ágil e eficaz para a gerência de projetos, baseando-se em suas próprias experiências, desenvolveram um novo método para gerenciar projetos e o chamaram de Scrum. Esta nova metodologia trouxe ao mercado a inovação para manter a consistência, respeitar os prazos determinados e o maior ganho de desempenho da equipe envolvida no projeto sem perder o foco da entrega no menor tempo possível (SCHWABER; BEEDLE, 2001). O processo Scrum define a equipe, artefatos e encontros. No Scrum, cada iteração, chamada de sprint, dura 30 dias e no final de cada sprint é feita uma entrega de um software funcional (SCHWABER; BEEDLE, 2001).

15 Equipe Scrum A equipe Scrum é composta de 5 a 7 desenvolvedores que cuidam de todo o desenvolvimento, análise, documentação e testes. Além dos desenvolvedores, existe o Scrum master, cujas atividades incluem auxiliar os desenvolvedores a manter seus níveis de produtividade no máximo, manter os artefatos e conduzir as reuniões. Há ainda o product owner, que é o único que prioriza os requerimentos no product backlog (SCHWABER; BEEDLE, 2001) Reuniões O Scrum define dois tipos de reuniões: a daily Scrum e o planning meeting (SCHWABER; BEEDLE, 2001). A daily Scrum é uma reunião de, no máximo, quinze minutos, realizada diariamente preferencialmente no mesmo local e na mesma hora. Essa reunião serve para proporcionar visibilidade do trabalho entre os membros da equipe, promover sua comunicação, levantar quais obstáculos atrapalharam o desenvolvimento desde a última daily scrum e servir de oportunidade para decisões rápidas com relação ao progresso do sprint. Nessa reunião, cada membro da equipe detalha o que ele completou desde a última daily Scrum, o que ele pretende fazer até a próxima daily Scrum e quais obstáculos estiveram em seu caminho (SCHWABER, 2004). O planning meeting consiste de duas partes. Na primeira, a equipe e o product owner reúnem-se para definir quais requerimentos serão entregues no final do sprint. Na segunda, a equipe define como desenvolverá esses requerimentos (SCHWABER; BEEDLE, 2001). Na segunda etapa do planning meeting, os requerimentos são transformados em tarefas menores e é estimado o tempo necessário para executar cada tarefa. Os membros da equipe se voluntariam para fazer cada tarefa. Deve-se levar em conta o tempo disponível de cada membro da equipe para não sobrecarregá-los (SUTHERLAND; SCHWABER, 2011).

16 Artefatos Product backlog é a lista priorizada de todos os requerimentos do produto. Estes requerimentos podem ser funcionalidades, recursos ou tecnologias. Sempre que uma nova funcionalidade é necessária, ela é adicionada ao product backlog, e do mesmo modo, quando uma funcionalidade é entregue, ela é removida do backlog (SCHWABER; BEEDLE, 2001). Sprint backlog são os requerimentos que a equipe concorda em entregar no sprint atual. O sprint backlog é definido durante o planning meeting (SCHWABER; BEEDLE, 2001). Sprint backlog graph, ou burn down chart, é um gráfico que mostra a quantidade de trabalho necessário para terminar o sprint backlog por dias trabalhados. Este gráfico é atualizado diariamente e ajuda a visualizar o progresso do sprint (SCHWABER; BEEDLE, 2001). A figura 1 representa o processo Scrum, desde a fase inicial até a fase de incremento. Figura 1: O processo scrum. Fonte: SUTHERLAND, SCHWABER (2011) (traduzida pelos autores).

17 Taskboard Muitas equipes fazem uso de uma ferramenta visual para monitorar as tarefas durante o sprint. Em geral utiliza-se um taskboard onde as tarefas, escritas em notas auto-adesivas, migram entre as colunas: Não Iniciada, Em Progresso, Verificar e Completa (SUTHERLAND; SCHWABER, 2010). O taskboard provê muitas informações por mostrar os requerimentos distribuídos em tarefas menores. Cada nota de tarefa pode fornecer outras informações como tipo de trabalho (codificação, testes, etc) e o número de horas estimadas para sua execução. O taskboard também ajuda a verificar a quantidade de horas remanescentes para o término das tarefas e com isso produzir o burn down chart (MIRANDA; BOURQUE, 2010). No taskboard, como o número de tarefas que estão em codificação ou quantas estão em testes, não são exploradas sob a assunção de que o importante é o trabalho completo e o trabalho remanescente (MIRANDA; BOURQUE, 2010). 2.3 Monitoramento O taskboard pode fornecer muitas informações visuais. Mas se os dados de cada tarefa que nele consta forem colhidos, ele pode oferecer ainda mais informações. Seguem alguns dados de monitoramento que podem ser retirados do taskboard Burn Down Chart O burn down chart de iteração é um gráfico derivado dos dados do taskboard. Seu público alvo são os próprios membros da equipe. Ele mostra o número de horas de trabalho restantes ante o número de dias remanescentes na iteração atual. Essa informação é utilizada para prever se o trabalho pode ser concluído, ou se será necessário remanejar parte do trabalho, ou ainda realizar horas-extras (MIRANDA; BOURQUE, 2010).

18 18 A figura 2 abaixo mostra o progresso geral do projeto em relação aos sprints do mesmo. Esta informação pode ser usada tanto pelos desenvolvedores quanto pelos product owners para estimar em quanto tempo o projeto pode ser terminado (MIRANDA; BOURQUE, 2010). Figura 2: Burn down chart. Fonte: SUTHERLAND, SCHWABER (2011) Burn Up Chart O burn up chart é um gráfico parecido com o burn down chart. Entretanto ele mostra a quantidade de trabalho realizado ante o dia da iteração atual. Ele também tem as mesmas duas variedades do burn down chart, iteração e versão. Phil Goodwin e Russ Rufer propuseram um modelo para o burn up chart de iteração que permite que aconteçam mudanças no escopo do projeto. Neste modelo, há uma linha que representa o teto, ou a marca de 100%, do progresso do projeto. Quando há alguma alteração no escopo, esta linha sobe, ou desce, de acordo com a expectativa de aumento, ou diminuição, do trabalho (COCKBURN, 2004).

19 19 A figura 3 mostra um burn up chart de iteração de acordo com o modelo Goodwin-Rufer. Figura 3: Burn up chart. Fonte: GREENHOPPER (2011) Cumulative Flow Diagram Cumulative flow diagram é outra representação para o acompanhamento de progresso em um projeto ágil de software, baseado no burn up chart. Como o burn up chart, o cumulative flow diagram retrata o número de recursos concluídos ao longo do tempo. O cumulative flow diagram proporciona uma visão mais detalhada do status do projeto em qualquer ponto no tempo. Ele também permite a detecção precoce de problemas que pode facilitar a correção dos mesmos (CABRI; GRIFFITHS, 2006). Na Figura 4, são mostradas a parte do trabalho Iniciado e uma pequena parte no estado Em Progresso. Em seguida aparecem os trabalhos em fase de Verificação e Completo. No final do último sprint todo o trabalho deve aparecer no estado Completo.

20 20 Figura 4: Cumulative flow diagram. Fonte: REINERTSEN (traduzido). O cumulative flow diagram pode também ser utilizado para medir o andamento de um sprint. Neste caso o eixo horizontal fará referência aos dias e o eixo vertical à quantidade de trabalho realizada.

21 21 3 FERRAMENTAS EXISTENTES O desenvolvimento de software envolve muitas técnicas como requisitos, recursos e tecnologia, que podem mudar durante o processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo flexibilidade para acompanhar as mudanças. O resultado do processo deve ser um software que é realmente útil para o cliente (SCHWABER, 1996). Para auxiliar a equipe SRUM na fase de produção de um software utiliza-se o taskboard físico ou digial. Os taskboard mais aceitos no mercado devido sua praticidade, usabilidade, outros recursos que serão apresentados são: SrumNinja, GreenHopper e Vip Task Manager. 3.1 ScrumNinja O ScrumNinja foi desenvolvida por dois especialistas de Sênior de tecnologia e Certificados como Scrum Masters que são eles: Rodney Carvalho e Lowenfels David. Como principal objetivo o software foi projetado com total integridade conceitual, ele mantém a simplicidade intuitiva do quadro de tarefa comum, fornecendo o benefício de atualizações em tempo real, grande variedade de cores, armazenamento de dados (comentários, observações e imagens) e reforça as melhores práticas para novas equipes para Scrum (SCRUMNINJA, 2011). Figura 5: Screenshot da ferramenta ScrumNinja Fonte: (SCRUMNINJA SCREENSHOT, 2011).

22 GreenHopper Este taskboard foi desenvolvido pela Atlassian uma empresa australiana que atua no ramo de desenvolvimento de software para gerenciamento de projetos. O GreenHopper é uma ferramenta ideal para auxiliar o scrum master no gerenciamento de tarefas, planejamentos de sprints, compartilhamento dos dados e acompanhamento de processos do projeto. É um software que tem como característica: edição online, tela de gráficos e fácil usabilidade (GREENHOPPER, 2011). Figura 6: Screenshot da ferramenta GreenHopper Fonte: (GREENHOPPER SCREENSHOT, 2011). 3.3 Vip Task Manager O Vip Task Manager está entre os softwares de taskboard mais completo para gerenciamento de tarefas para equipes Scrum. Ele viabiliza o aumento do desempenho da empresa, a eficácia e a maior produtividade. Dispões de recursos para planejar, programar, compartilhar, controlar tarefas, agendar compromissos da equipe, e exibir fase do processo entre outras funcionalidades (VIP QUALITY SOFTWARE, 2010).

23 23 Figura 7: Screenshot da ferramenta Vip Task Manager Fonte: (VIP TASK MANAGER SCREENSHOT, 2011). 3.4 Comparações de Ferramentas Existentes A figura abaixo aborda os nomes das ferramentas e suas características mais importantes e também contém as funcionalidades contidas em cada ferramenta existente. Tabela1: Características das Ferramentas Existentes Fonte: Os Autores (2011).

24 24 4 TECNOLOGIAS E PADRÕES DE DESENVOLVIMENTO Das páginas estáticas do passado, aos sistemas dinâmicos atuais, a programação para a Web vem avançando em ritmo acelerado. Com este crescimento, cada vez mais é necessário à utilização de ferramentas para aumentar a produtividade. Tanto as ferramentas de desenvolvimento quanto as linguagens de programação vêm sendo aprimoradas para atender essa nova demanda (LOVATTO, 2007). A seguir são apresentadas algumas ferramentas para programação para web que embasaram na escolha da ferramenta escolhida para o trabalho. 4.1 Padrão MVC Segundo MAGELA (2006), o padrão MVC foi implementado por Jim Althoff. Onde se descreve da seguinte maneira: Modelo: Camada responsável pelos dados que contém a lógica dos negócios de forma separada. Visão: Responsável pela a saída dos dados, lógica de apresentação dos dados ao usuário. Controle: Responsável por fazer o elo entre o Modelo e a Visão, recebe e interpreta as entradas de dados dos usuários. A figura abaixo exemplifica a ligação entre as camadas do padrão MVC. Figura 8: Padrão MVC fonte: REENSKAUG(2003, traduzida)

25 Google Web Toolkit Durante a conferência JavaOne de 2006, o Google apresentou sua nova ferramenta para desenvolvimento de aplicações web, o Google Web Toolkit (GWT). Com o GWT, pode-se programar tanto a parte cliente da aplicação, quanto a parte servidor, utilizando-se a linguagem Java e um mínimo de HTML. Todo código JavaScript é gerado a partir do código Java, e o GWT cuida das diferenças entres os diferentes navegadores (OLSON, 2007). Com o GWT pode-se escrever toda a aplicação utilizando conceitos de orientação a objetos mesmo que o Javascript não possua todos os recursos de orientação a objetos, pois o código é escrito em Java. Outra vantagem são as bibliotecas que são adicionadas ao GWT tanto pelo Google quanto por terceiros (PERRY, 2006). 4.3 PHP Concebido em 1994 por Rasmus Lerdorf, o PHP é uma linguagem de script orientada a objetos utilizada para a programação de páginas da web. O PHP permite que coloquem programas dentro de uma página HTML. O código do programa será executado toda vez que alguém pedir para ver essa página. O PHP é gratuito e tem seu código aberto. Em janeiro de 2001, aproximadamente 5 milhões de domínios por todo o mundo utilizavam PHP (WELLING; THOMSON, 2008). O PHP possui bom desempenho, um único servidor pode responder a milhões de pedidos por dia. Se for necessário ainda mais performance, o PHP é facilmente escalável adicionando outros servidores em estrutura horizontal. Ele possui integração com tipos de bancos de dados e possui numerosas bibliotecas para tarefas relacionadas à internet, como envio de s, criação dinâmica de imagens, geração de PDF, e análise de arquivos XML (WELLING; THOMSON, 2008).

26 Struts O objetivo do Struts2 é facilitar o desenvolvimento web para os programadores. Para tal, ele automatiza muitas tarefas comuns, como converter dados de formulários para serem utilizados nas classes Java. Também utiliza convenção sobre configuração e anotações do Java para diminuir a quantidade de arquivos de configuração (BROWN, DAVIS, STANLICK, 2008). O Struts2 segue o padrão MVC. No Struts2 não há necessidade de se implementar o controller, mas ele pode ser configurado por arquivos XML. O model, onde fica toda a lógica de domínio da aplicação é implementado pelo programador em Java. O view pode ser implementado com páginas JSP ou ferramentas de template como Velocity e FreeMarker (BROWN; DAVIS; STANLICK, 2008). 4.5 Ruby On Rails Ruby on Rails (Rails) é um framework para facilitar o desenvolvimento, construção e manutenção de aplicações web. O Rails extende Ruby de uma maneira para facilitar o trabalho dos desenvolvedores e diminuir o tamanho dos programas e aumentar sua legibilidade (RUBY; THOMAS; HANSSON, 2011). As aplicações Rails são escritas em Ruby, que é uma linguagem de script orientada a objetos. O Rails segue o padrão MVC e também utiliza o conceito de convenção sobre configuração (RUBY; THOMAS; HANSSON, 2011). Todas as aplicações Rails têm suporte a testes embutido no próprio framework. Sempre que uma nova funcionalidade é adicionada, o Rails cria um método para que o desenvolvedor escreva o teste para esta funcionalidade (RUBY; THOMAS; HANSSON, 2011). 4.6 HTML5 HTML5 é a nova geração do HTML. Ele provê novos recursos necessários para aplicações web modernas. Também padroniza recursos

27 27 utilizados por anos, mas que nunca foram formalmente documentados. Ele foi concebido para ser multi-plataforma, necessitando apenas de um navegador moderno para utilizar seus recursos (PILGRIM, 2010). O HTML5 traz melhorias para as interfaces, utilizando CSS3 para customizar o estilo dos elementos das páginas, e melhorias para os formulários, como os novos componentes de seleção de datas (HOGAN, 2010). 4.7 Hibernate Persistência de dados é um requisito comum de muitas aplicações. Essa persistência na maior parte das vezes envolve o uso de SQL e sistemas gerenciadores de bancos de dados relacionais. Entretanto, a representação tabular dos dados é bem diferente da representação utilizada na orientação a objetos (BAUER; KING, 2005). O mapeamento objeto relacional é o nome dado às soluções de automação do trabalho de converter entre essas duas representações. O Hibernate é uma dessas ferramentas, desenvolvida desde 2001, e enfatiza produtividade e liderança técnica. O Hibernate já é utilizado em milhares de aplicações, por dezenas de milhares de usuários (Bauer; King, 2005).

28 28 5 METODOLOGIA O sistema será desenvolvido para substituir os taskboards convencionais. Ele terá uma interface que se assemelhará a um taskboard convencional. Além de mostrar os dados como um taskboard convencional, ele também gerará os gráficos de monitoramento vistos no capítulo 2. O sistema deve possibilitar a utilização de múltiplos usuários simultaneamente pela internet. Haverá diferenciação dos usuários por papéis que cada usuário pode assumir. Todos os dados serão salvos em um banco de dados relacional. Para desenvolver o projeto, serão utilizadas algumas das tecnologias apresentadas no capítulo 4. Segue uma breve discussão sobre os motivos da seleção das ferramentas. 5.1 Framework de Desenvolvimento Web A maior parte das linguagens e frameworks para programação para web utilizam o padrão MVC. E na maior parte das vezes, a parte de view é feita em um arquivo de formato diferente dos outros utilizados para as outras partes do sistema, e este arquivo quase nunca é compilado. Por este motivo é muitas vezes difícil encontrar erros nestes arquivos, como uma variável que não foi declarada, e estes erros se manifestam apenas quando o programa está sendo executado. No GWT todos os arquivos são compilados, inclusive os que fazem parte da View. Portanto erros deste tipo podem ser encontrados em tempo de compilação. Os principais editores gratuitos, Eclipse e Netbeans, têm plugins para Ruby, PHP. Entretanto o nível de maturidade desses plugins é inferior ao tratamento nativo que esses editores dão ao Java. Como o GWT utiliza apenas código Java, é mais fácil escrever os programas em GWT nesses editores do que nas outras linguagens. Os criadores do GWT também disponibilizam um plugin para a IDE Eclipse. Este plugin se encarrega de compilar a aplicação e de implantar em

29 29 um servidor de testes Tomcat. O plugin para Eclipse pode também implantar a aplicação num servidor do Google, para que esta fique disponível na Internet. Os criadores do GWT disponibilizam a configuração para Ant# para auxiliar a compilação e instalação da aplicação. Também há um plugin para Maven# com o mesmo intuito. Entretanto esse plugin para Maven não tem suporte oficial. O GWT foi feito para rodar no servidor Tomcat, que é uma implementação das tecnologias JavaServer Pages (JSP) e Java Servlets. O Tomcat é gratuito e tem seu código fonte aberto. Para hospedagem remota existem hospedeiros que fornecem o Tomcat, entretanto, eles em geral cobram mais caro que os outros servidores de HTTP. Existe também a hospedagem no Google em seu Appengine. Neste caso, a hospedagem é gratuita até que se utilize sua quota de processamento e/ou banda. Quando a quota é estourada, ou o site é desligado, ou é cobrada uma taxa. Foi decidido utilizar o framework GWT para fazer a parte prática do projeto. Todos os frameworks possuem boas ferramentas para desenvolvimento e instalação das aplicações. O fato de o GWT ter interoperabilidade entre navegadores, as vantagens de se utilizar o Java tanto para o desenvolvimento da parte servidor quanto da parte cliente são grandes vantagens sobre os outros frameworks. O projeto não utilizará o HTML5 por ser uma tecnologia muito nova que não está disponível em todos os navegadores. 5.2 Persistência de Dados Para realizar a persistência dos dados, e respectiva busca, será utilizado o Hibernate. O Hibernate é uma das mais antigas e mais estabelecidas ferramentas de mapeamento objeto relacional para Java.

30 Banco de Dados Para facilitar o trabalho de instalar um sistema gerenciador de banco de dados, foi decidido utilizar o HyperSQL, que é uma implementação de um banco de dados feita em Java, ele suporta a maior parte do padrão SQL (HSQL, 2011). Outra vantagem do HyperSQL é que ele pode ser embutido na aplicação. Deste modo, o banco de dados sobe automaticamente com a aplicação, sem a necessidade de se instalar outro servidor externo. 5.4 Ambiente de Desenvolvimento Para facilitar a programação do aplicativo será utilizado o IDE Eclipse, pois já existe um plugin específico do GWT para este IDE. 5.5 Ferramenta para Geração de Gráficos Para gerar os gráficos foi utilizada a ferramenta Google Chart Tools e seu plugin Google API Libraries for Google Web Toolkit. Ambos desenvolvidos pelo próprio Google fazem que seja extremamente fácil adicionar gráficos a um projeto que utiliza o GWT.

31 31 6 MODELAGEM DO SOFTWARE Ao iniciar a modelagem foram analisados todos os requisitos funcionais e não funcionais do software de acordo com a proposta do trabalho. A partir disso, foram criados os casos de uso, diagrama de classe e os diagramas de sequência. Os diagramas foram criados na ferramenta Astah-UML. Através das definições dos diagramas será possível ter uma visão geral da implementação do software. 6.1 Requisitos Funcionais e Não Funcionais Com o intuito de criar uma ferramenta consistente e funcional, foram feitas as análises e as especificações das funcionalidades do dtaskboard, onde, foram definidos os requisitos funcionais e não funcionais da ferramenta. Requisitos Funcionais são declarações detalhadas das funções que o sistema deve executar e como deve ser seu comportamento diante de entradas e situações específicas (SOMMERVILLE, 2003) A tabela 2 representa os requisitos funcionais, ou seja, representa as atividades que poderão ser executadas no dtaskboard. Tabela 2: Requisitos Funcionais Fonte: Os Atores (2011)

32 32 Requisitos não Funcionais são as restrições sobre as funções que serão oferecidas pelo sistema. Eles também podem ser a respeito de requisitos relacionados ao processo utilizado para o desenvolvimento do software, como especificações dos padrões de qualidade. Os Requisitos não Funcionais surgem em razão do usuário, do orçamento disponível, das políticas organizacionais ou até mesmo de necessidades externas, como necessidades legais ou de segurança (SOMMERVILLE, 2003) A tabela 3 representa os Requisitos não Funcionais do sistema. Tabela 3: Requisitos Não Funcionais Fonte: Os Atores (2011) 6.2 Casos de Uso Para ajudar a determinar as funcionalidades que devem ser implementadas no sistema, foram feitos os casos de uso indicando os principais fluxos de trabalho dos usuários do sistema. O sistema possuirá quatro tipos de atores, o administrador que poderá criar projetos; os gerentes de projetos que poderão criar sprints, histórias e também poderão dar permissão de acesso aos seus projetos a outros usuários. Existem os usuários que têm permissão de utilizar pelo menos um dos projetos e modificar as tarefas desse projeto, e temos ainda os visitantes, que podem apenas ver os projetos. A tabela 4 mostra uma listagem dos atores e dos requisitos que compõem o sistema.

33 33 Tabela 4: Casos de Uso Fonte: Os Autores (2011) Na Figura 9 é possível visualizar a maneira que cada ator (Usuário, Gerente de projeto e Administrador) interage com o sistema. Figura 9: Casos de uso. Fonte: Os Autores (2011). Para melhor visualização, a descrição dos casos de uso encontra-se no APÊNDICE A.

34 Diagramas de Classes Nos diagramas de classe é possível visualizar as diferentes classes que compõem o sistema e a maneira de como elas se relacionam. As classes são representadas com seus respectivos nomes e atributos. A Figura 10 mostra o diagrama das classes que serão persistidas no sistema e através da imagem é possível analisar a maneira que elas se relacionam. Figura 10: Diagrama de classes das entidades. Fonte: Os autores (2011). A Figura 11 mostra as classes que tem acesso às informações contidas no banco de dados. Essas classes compõem o modelo e nelas estão contidas todas as lógicas de negócio da aplicação.

35 35 Figura 11: Diagrama de classes de controle. Fonte: Os autores (2011). 6.4 Diagramas de Sequência Devido à complexidade de um determinado sistema com diferentes métodos e classes é difícil determinar a sequência de eventos do sistema. A criação do diagrama de sequência é feita para minimizar esta complexidade. Os diagramas são feitos com base nos casos de usos e nos diagramas de classe. Os diagramas de sequência foram criados de acordo com o escopo do trabalho. Para melhor visualização os diagramas encontram-se no APÊNDICE B.

36 36 7 IMPLEMENTAÇÃO DO PROJETO A implementação do projeto segue o padrão MVC. O projeto foi então dividido entre três pacotes: dtaskboard.client representado a visualização da aplicação, dtaskboard.server representando a de lógica de negócios e o pacote dtaskboard.entities representando o modelo. A seguir são descritas cada uma dessas partes da aplicação. 7.1 Modelo O relacionamento entre as classes do modelo pode ser verificado na Figura 12. O pacote dtaskboard.entities possui todas as classes que são as entidades do mundo real, o model, e que são persistidas no banco de dados. As classes Project, Sprint, History e Task representam as respectivas entidades de um taskboard. Tanto o Sprint quanto o Task possuem seus estados, definidos respectivamente pelas enumerações SprintStatus e TaskStatus. Estas enumerações se encontram em outro pacote para serem utilizados também pela visualização. As classes Project, Sprint e Task guardam dados de horas previstas e cumpridas para o cálculo das métricas e confecção dos gráficos de burndown e burnup. Para realizar a autenticação, foram criadas as classes User, Role e a enumeração RoleClass. Cada usuário possui um respectivo objeto da classe User que possui os dados do login e senha do usuário. A enumeração RoleClass possui os diferentes tipos de papéis que um usuário pode ter no sistema: administrador, gerente de um projeto ou usuário de um projeto. Finalizando as classes de autenticação, a classe Role faz o relacionamento dos dados do usuário e quais papéis ele tem em cada projeto. Conforme a Figura 12 abaixo.

37 37 Figura 12: Diagrama de classes Modelo. Fonte: Os Autores (2011). 7.2 Visualização O pacote dtaskboard.client possui todas as classes que fazem parte da view, todas as telas, formulários e pontos de interação com o usuário ficam nele. Este pacote possui diversos outros sub pacotes para melhor organizar o projeto. A tela de autenticação é representada pela classe dtaskboar.client.login.loginpage. Esta página mostra o formulário de autenticação, como na Figura 13. Figura 13: Tela de login. Fonte: Os Autores (2011). Depois de se autenticar, o usuário entra na tela que mostra a barra de ferramentas desse usuário, e de administrador caso esse usuário seja um

38 38 administrador. Essa barra de ferramentas é representada pela classe dtaskboard.client.toolbar.toolbar. Esta tela pode ser vista na figura 14. Na barra de ferramentas do usuário, ao se clicar em qualquer uma das entradas, aparece um Menu onde o usuário pode realizar algumas funções. Clicando em seu nome de usuário (admin no caso da figura 14) aparecem as ações: Trocar Senha e Sair do sistema. Em projetos o usuário pode selecionar o projeto que deseja ver. Figura 14: Barra de ferramentas. Fonte: Os Autores (2011). Em Administração pode-se criar um novo usuário, adicionar um papel a um usuário e criar um novo projeto. O item administração só aparece para administradores. Estas ações, com a exceção de sair do sistema, abrem caixas de diálogo modal onde o usuário deve preencher dados para executar a ação. Esses diálogos são implementados pelas classes AddRoleToUserDialog, ChangePasswordDialog, CreateProjectDialog e CreateUserDialog, que estão no mesmo pacote da classe Toolbar. Quando um usuário seleciona o projeto que deseja ver, abre-se a barra de ferramentas do projeto logo abaixo da barra de ferramentas do usuário e também o taskboard com o sprint atual do projeto, como na figura 15. Figura 15: Tela do projeto. Fonte: Os Autores (2011).

39 39 Na barra de ferramentas do projeto, se o usuário for um gerente do projeto ele pode editar o projeto, criar um novo sprint e encerrar o sprint atual. Estas ações também abrem diálogos e são implementadas pelas respectivas classes de diálogo. As classes que geram a barra de ferramentas do projeto e a tabela do projeto encontram-se no pacote dtaskboard.client.project. As classes dos diálogos estão no pacote dtaskboard.client.project.dialog. No taskboard o usuário pode criar tarefas e histórias, se for o gerente, e pode mover as tarefas entre as colunas. Todos os diálogos são subclasses de Dialog, a classe de diálogos fornecida pelo GWT, como pode ser visto na figura 16. A classe Toolbar e ProjectToolbar são subclasses de MenuBar, que é a classe fornecida pelo GWT para fornecer barras de menu. Além dessas classes existem também a LoginPage e a ProjectPage que podem ser vistas na figura 17. Figura 16: Diagrama de classes dos diálogos. Fonte: Os Autores (2011). Figura 17: Diagrama de classes interface com o usuário. Fonte: Os Autores (2011). A figura 18 mostra as classes que foram implementadas para mostrar os gráficos no sistema. Elas implementam um método e devolvem um componente que pode ser adicionado diretamente na tela e renderiza um gráfico. Para isso estas classes utilizam a biblioteca Google Chart Tools.

40 40 Figura 18: Diagrama de classes criadoras de gráficos. Fonte: Os Autores (2011). 7.3 Controlador Por último o pacote dtaskboard.server possui todas as lógicas de negócio e manipulação das entidades, o controlador. Quando o usuário executa uma ação na view, ela é enviada para o controlador e então processada. Para tratar a persistência e recuperação dos dados foi utilizado o padrão DAO (Data Access Object), onde uma classe é responsável por fazer a persistência dos dados sem expor as especificidades do banco de dados. Os DAOs estão no pacote dtaskboard.server.dao e há uma classe GenericDao que implementa os métodos de criação, remoção, recuperação e listagem de entidades. Existem subclasses de GenericDao para cada entidade e cada subclasse precisa apenas implementar os métodos que são necessários para essa entidade. O diagrama de classes do pacote dtaskboard.server.dao pode ser visto na figura 19. Figura 19: Diagrama de classes DAO. Fonte: Os Autores (2011).

41 41 A figura 20 mostra as classes com as lógicas de negócio. O ProjectServiceImpl possui todas as lógicas que tratam do projeto, criar e atualizar projetos, sprints e tarefas além de tratar das mudanças de estados das tarefas. O LoginServiceImpl trata das funções administrativas de criar usuários e papéis para eles, e também da autenticação. Figura 20: Diagrama de classes controlador. Fonte: Os Autores (2011).