TASKBOARDDEV: FERRAMENTA PARA MONITORAMENTO E RASTREABILIDADE DE ATIVIDADES DE ...dsc.inf.furb.br/arquivos/tccs/monografias/2014_2_pedro... · 2015. 8. 25. · A fase de manutenção

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO

TASKBOARDDEV: FERRAMENTA PARA

MONITORAMENTO E RASTREABILIDADE DE

ATIVIDADES DE MANUTENÇÃO DE SOFTWARE BASEADA

EM CONCEITOS ÁGEIS

PEDRO ANSELMO WEBER

BLUMENAU 2014

2014/2-13

PEDRO ANSELMO WEBER



ATIVIDADES DE MANUTENÇÃO DE SOFTWARE BASEADA

EM CONCEITOS ÁGEIS

Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação— Bacharelado.

Prof. Mauro Marcelo Mattos, Doutor - Orientador

BLUMENAU 2014

2014/2-13



ATIVIDADES DE MANUNTEÇÃO DE SOFTWARE BASEADA

EM CONCEITOS ÁGEIS

Por

PEDRO ANSELMO WEBER

Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Mauro Marcelo Mattos, Doutor – Orientador, FURB

______________________________________________________ Membro: Prof. Jhony Alceu Pereira, Especialista – FURB

______________________________________________________ Membro: Prof. Wilson Pedro Carli, Mestre – FURB

Blumenau, 09 de Dezembro de 2014.

Dedico este trabalho aos familiares, amigos,

professores, colegas de trabalho e

especialmente aqueles que me ajudaram

diretamente na realização deste.

AGRADECIMENTOS

À minha mãe, que aonde quer que esteja, sei que sempre estará torcendo e cuidando de

mim.

À minha madrinha Idair Rover Plotegher e ao meu tio Antônio Plotegher, por terem

me auxiliado no início e no decorrer dos quatros anos de graduação e por aturarem o meu mau

humor.

A Deus, pelo seu imenso amor e graça.

À minha família, que sempre esteve presente.

Aos meus amigos, pelos empurrões e cobranças.

Ao meu orientador, professor Mauro Marcelo Mattos, por ter acreditado e auxiliado na

conclusão deste trabalho.

Aos colegas de trabalho, que acreditaram, contribuíram e colaboraram com as

mudanças realizadas por este trabalho.

Aos membros da banca, que contribuíram com sugestões e melhorias.

Aos professores do Departamento de Sistemas e Computação da Universidade

Regional de Blumenau por suas contribuições durante os semestres letivos.

Sonhos determinam o que você quer. Ação

determina o que você conquista.

Aldo Novak

RESUMO

Com a constante evolução e as mudanças que estão acontecendo nos dias atuais em um

movimento acelerado, para se manter presente no mercado as empresas tem de adaptar-se,

tornando mais comum a adoção de estratégias “ágeis”. As empresas prestadoras de soluções

de software também tem que acompanhar esta aceleração, provendo subsídios para as

necessidades dos clientes com rapidez e eficiência. Para possibilitar isto, é cada vez mais

comum, se utilizar de metodologias ágeis para a construção de software, afim de agilizar o

processo e aumentar a produtividade. Além da construção, a manutenção de sistemas

existentes demanda desta mesma agilidade, pois nesta fase o sistema já afeta diretamente o

negócio dos clientes. A fim de melhorar a produtividade da manutenção do framework da

empresa Senior Sistemas S/A, foi modificado o processo aplicando alguns conceitos de

metodologias ágeis. O presente trabalho é uma solução, com o propósito de prover as

necessidades deste processo visando uma maior agilidade, produtividade e visibilidade. Para

isto, foi desenvolvido uma aplicação Web, que possibilita o monitoramento das atividades,

utilizando os sprints do Scrum para melhorar a comunicação e as entregas e o Kanban para o

acompanhamento. Os resultados obtidos com este trabalho possibilitaram a utilização dos

conceitos ágeis sem muito impacto à equipe, aumentando a comunicação e provendo

visibilidade do andamento das atividades.

Palavras-chave: Processo de Desenvolvimento de Software. Manutenção de Software. Processos Ágeis.

ABSTRACT

With the constant evolution and changes that are happening today in accelerated motion, to

stay on the market companies have to adapt, becoming more common to adopt “agile"

strategies. The software providers of solutions also have to follow this acceleration, providing

subsidies to the needs of customers quickly and efficiently. To enable this, it is increasingly

common to use agile methodologies for building software in order to streamline the process

and increase productivity. Besides building, the maintaining of existing systems requires this

same agility, because at this stage the system already directly affects the customers business.

In order to improve the productivity of maintaining of the framework of the company Senior

Sistemas S/A was modified the process, by applying some concepts of agile methodologies.

This work has created one solution in order to provide for the needs of this process towards

greater efficiency, productivity and visibility. For this, a web application has been developed,

which enables the monitoring of activities, using of the Scrum sprints to improve

communication and deliveries and the Kanban for monitoring. The results of this study

allowed the use of agile concepts without much impact to the team, improving

communication and providing visibility of the progress of activities.

Key-words: Software Development Process. Software Maintenance. Agile processes.

LISTA DE FIGURAS

Figura 1 – Quadro Kanban Digital ........................................................................................... 18

Figura 2 – Tela do sistema ....................................................................................................... 21

Figura 3 – Tela do sistema desenvolvido ................................................................................. 22

Figura 4 – Arquitetura do Sistema ........................................................................................... 24

Figura 5 – Diagrama de casos de uso ....................................................................................... 27

Figura 6 – Modelo de entidade e relacionamento .................................................................... 28

Figura 7 – Código com anotações de persistência ................................................................... 31

Figura 8 – Código de conexão com o banco de dados externo ................................................ 31

Figura 9 – Tela principal .......................................................................................................... 32

Figura 10 – Tela de login ......................................................................................................... 33

Figura 11 – Código fonte do PhaseListener ............................................................................ 33

Figura 12 – Módulo Administrador - TaskBoard .................................................................... 34

Figura 13 – Módulo Administrador - Cadastro ........................................................................ 35

Figura 14 – Cadastro de quadro Kanban .................................................................................. 35

Figura 15 – Cadastro de raias do Kanban ................................................................................ 36

Figura 16 – Módulo Administrador - Settings ......................................................................... 37

Figura 17 – Trecho do código fonte responsável por popular as tarefas no sistema ................ 38

Figura 18 – Módulo Administrador - Select Critical Tasks ..................................................... 38

Figura 19 – Cadastro de External View .................................................................................... 39

Figura 20 – Módulo Desenvolvedor - My Views ..................................................................... 40

Figura 21 – Cadastro de Sprint ................................................................................................. 40

Figura 22 – Tela de configuração do Kanban do Sprint .......................................................... 41

Figura 23 – Cadastro Daily Meeting ........................................................................................ 42

Figura 24 – Cadastro de Status da Daily Meeting .................................................................... 42

Figura 25 – Cadastro de Impedimentos da Daily Meeting ....................................................... 43

Figura 26 – Módulo Desenvolvedor - Settings - My Views ...................................................... 44

Figura 27 – Módulo Desenvolvedor - Settings - Troca de Senha ............................................ 44

Figura 28 – Módulo Monitor – Template Monitor ................................................................... 45

Figura 29 – Módulo Monitor – Critical Tasks ......................................................................... 46

LISTA DE QUADROS

Quadro 1 – Requisitos funcionais ............................................................................................ 25

Quadro 2 – Requisitos não funcionais ..................................................................................... 26

Quadro 3 – Regras de negócio ................................................................................................. 26

Quadro 4 – Descrição do caso de uso registro de impedimentos ............................................. 52

Quadro 5 – Descrição do caso de uso Manter MyTaskView .................................................... 52

Quadro 6 – Descrição do caso de uso Atualizar o Quadro de Tarefas ..................................... 53

Quadro 7 – Descrição do caso de uso Consultar Ranking das Tarefas .................................... 53

Quadro 8 – Descrição do caso de uso Consultar Tarefas ......................................................... 54

Quadro 9 – Descrição do caso de uso Cadastro de Reunião Diária ......................................... 54

Quadro 10 – Descrição do caso de uso Relatório de impedimentos da equipe ........................ 54

Quadro 11 – Descrição do caso de uso Definição do Quadro de Tarefas ................................ 54

Quadro 12 – Descrição do caso de uso Manter equipe ............................................................ 55

Quadro 13 – Descrição do caso de uso Manter acesso de banco de dados externo ................. 55

Quadro 14 – Descrição do caso de uso Manter consulta de Critical Tasks ............................. 56

Quadro 15 – Descrição do caso de uso Manter TaskView ....................................................... 56

Quadro 16 – Descrição do caso de uso Manter ExternalView ................................................. 57

Quadro 17 – Descrição do caso de uso Consultar Quadro de Tarefas ..................................... 58

Quadro 18 – Tabela de acesso a banco .................................................................................... 59

Quadro 19 – Tabela de célula ................................................................................................... 59

Quadro 20 – Tabela de Daily Meeting ..................................................................................... 60

Quadro 21 – Tabela de ligação entre Daily Meeting e Impedimento ....................................... 60

Quadro 22 – Tabela de ligação entre Daily Meeting e status ................................................... 60

Quadro 23 – Tabela de ExternalView ...................................................................................... 61

Quadro 24 – Tabela de funcionário .......................................................................................... 61

Quadro 25 – Tabela de impedimento ....................................................................................... 62

Quadro 26 – Tabela de Kanban ................................................................................................ 62

Quadro 27 – Tabela de ligação entre Kanban e célula ............................................................. 63

Quadro 28 – Tabela de ligação entre Kanban e raia ................................................................ 63

Quadro 29 – Tabela de KanbanSprint ...................................................................................... 63

Quadro 30 – Tabela de ligação entre KanbanSprint e TaskKanban ........................................ 64

Quadro 31 – Tabela de MyViewTask ........................................................................................ 64

Quadro 32 – Tabela de raia ...................................................................................................... 64

Quadro 33 – Tabela de SelectCriticalTask ............................................................................... 65

Quadro 34 – Tabela de SelectView ........................................................................................... 66

Quadro 35 – Tabela de Sprint .................................................................................................. 68

Quadro 36 – Tabela de Status .................................................................................................. 68

Quadro 37 – Tabela de TaskComment ..................................................................................... 69

Quadro 38 – Tabela de TaskKanban ........................................................................................ 69

Quadro 39 – Tabela de ligação entre TaskKanban e TaskComment ........................................ 70

Quadro 40 – Tabela de ViewTask ............................................................................................. 70

LISTA DE SIGLAS

AQM - Active Qualilty Management

BI - Business Intelligence

CASE – Computer-Aided Software Engineering

DSDM - Dynamic Systems Development Method

EA – Enterprise Archictect

IDE - Integrated Development Environment

JDBC - Java Database Connectivity

JPA - Java Persistence API

JSF - JavaServer Faces

JSP – JavaServer Page

MER – Modelo de Entidade e Relacionamento

SQL - Structured Query Language

TCC – Trabalho de Conclusão de Curso

URL - Uniform Resource Locator

XP – Extreme Programming

SUMÁRIO

1 INTRODUÇÃO ................................................................................................................. 12

1.1 OBJETIVOS DO TRABALHO ........................................................................................ 13

1.2 ESTRUTURA DO TRABALHO ...................................................................................... 13

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14

2.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ........................................... 14

2.2 MANUTENÇÃO DE SOFTWARE ................................................................................. 15

2.3 PROCESSOS ÁGEIS ........................................................................................................ 15

2.3.1 Scrum .............................................................................................................................. 16

2.3.2 Kanban ............................................................................................................................ 18

2.4 SISTEMA ATUAL ........................................................................................................... 19

2.5 TRABALHOS CORRELATOS ........................................................................................ 20

3 DESENVOLVIMENTO DA FERRAMENTA ............................................................... 23

3.1 LEVANTAMENTO DE INFORMAÇÕES ...................................................................... 23

3.2 ESPECIFICAÇÃO ............................................................................................................ 24

3.2.1 Requisitos do Sistema ..................................................................................................... 25

3.2.2 Diagrama de Casos de Uso ............................................................................................. 26

3.2.3 Modelo de Entidade e Relacionamento .......................................................................... 27

3.3 IMPLEMENTAÇÃO ........................................................................................................ 30

3.3.1 Técnicas e ferramentas utilizadas ................................................................................... 30

3.3.2 Operacionalidade da implementação .............................................................................. 31

3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 46

4 CONCLUSÕES .................................................................................................................. 48

4.1 EXTENSÕES .................................................................................................................... 48

REFERÊNCIAS ..................................................................................................................... 49

APÊNDICE A – Descrição dos Casos de Uso ...................................................................... 52

APÊNDICE B – Descrição do Dicionário de Dados ............................................................ 59

12

1 INTRODUÇÃO

A fase de manutenção no ciclo de desenvolvimento de software é responsável por

correções, adaptações e evoluções no produto implantado. É uma fase que não tem um tempo

fixo para ser realizada, podendo se estender por anos, dependendo da complexidade e do

tamanho do software desenvolvido. Pode tornar-se a fase mais cara do projeto, geralmente

representando 90% do custo total do projeto, sem ter um valor máximo (MAGELA, 2006).

Este alto custo, segundo Magela (2006), está ligado principalmente a falhas na fase de

elucidação de requisitos.

A Senior Sistemas S/A, é uma empresa desenvolvedora de software que possui alguns

produtos que estão a mais de 15 anos no mercado. Por serem softwares voltados à gestão

empresarial e gestão de pessoas, eles têm grande dependência legal e alto nível de

complexidade em relação ao domínio do problema em que estão inseridos (SENIOR, 2014).

Como os negócios atualmente estão constantemente sujeitos a mudanças repentinas

que ocorrem em um ritmo acelerado, para adequar-se às novas oportunidades de mercado,

mudanças de condições econômicas e ao surgimento de novos produtos e serviços e ainda

conseguir manter o negócio em crescimento, as empresas devem responder de forma rápida às

mudanças. Como o software está a cada dia mais ligado ao negócio, ele também deve estar

preparado para suprir as demandas oriundas destas mudanças e entregas rápidas são

fundamentais (SOMMERVILLE, 2007).

Além da criação de novos produtos, a manutenção de produtos existentes demanda a

mesma agilidade. Como atividade de melhoria nos processos de manutenção de software a

Senior Sistemas S/A (SENIOR, 2014) vem adotando conceitos de processos ágeis e, neste

contexto, uma experiência vem sendo realizada utilizando-se as seguintes tecnologias:

a) utilização de Scrum como princípio de operação;

b) utilização de Kanban para o monitoramentos das atividades e entregas, e;

c) utilização de sprints para melhoria da comunicação entre os membros da equipe.

O suporte a estas atividades é realizado através de duas ferramentas: 0800net

(D’AVILA, 2007; ELLEVO, 2014) e Trello (TRELLO, 2014) as quais não possuem interface

de integração nem suporte a sprints. Como o foco da utilização destas novas tecnologias é

agilizar o processo, a fase de integração das duas ferramentas, é algo que demanda tempo e

consome recursos desnecessários. Além do que, estas duas ferramentas não possuem o

suporte a sprints. Assim, surgiu a necessidade de uma ferramenta que contemplasse as

13

necessidades existentes afim de prover e auxiliar a utilização dos conceitos ágeis na

manutenção de software, o qual é o foco deste trabalho.

1.11.1 OBJETIVOS DO TRABALHOBJETIVOS DO TRABALHOO

O objetivo deste trabalho é disponibilizar uma ferramenta para monitoramento e

rastreabilidade de atividades de manutenção de software para as equipes de manutenção da

empresa Senior Sistemas S/A, com a aplicação de conceitos ágeis.

Os objetivos específicos do trabalho são:

a) permitir a centralização e unificação de indicadores e monitoramento de atividades

de manutenção;

b) permitir o gerenciamento das reuniões de definição de entregas (sprints) e

acompanhamento das tarefas de manutenção (Kanban);

c) permitir o gerenciamento das reuniões diárias para verificar o andamento das

entregas planejadas.

1.21.2 ESTRUTURA DO TRABALHESTRUTURA DO TRABALH OO

No primeiro capítulo tem-se a introdução ao tema principal deste trabalho com a

apresentação da justificativa e dos objetivos.

No segundo capítulo apresenta-se a fundamentação teórica pesquisada sobre processo

de desenvolvimento de software, manutenção de software, processos ágeis, Scrum, Kanban,

sistema atual, além da apresentação de trabalhos correlatos.

O terceiro capítulo apresenta o desenvolvimento do sistema iniciando-se com o

levantamento de informações, tendo na sequência a especificação, implementação e por fim

resultados e discussões.

No quarto capítulo têm-se as conclusões deste trabalho bem como se apresentam

sugestões para trabalhos futuros.

14

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo aborda os seguintes assuntos: processo de desenvolvimento de software,

manutenção de software, processos ágeis, sistema atual, além da apresentação de trabalhos

correlatos.

2.12.1 PROCESSO DE DESENVOLPROCESSO DE DESENVOLVIMENTO DE SOFTWAREVIMENTO DE SOFTWARE

O processo de desenvolvimento de software pode ser definido como um conjunto de

atividades e resultados associados que tem como produto final um software

(SOMMERVILLE, 2003). Como todos os processos intelectuais, os processos de software

são complexos e dependem do julgamento humano.

As tentativas de automatização do processo de desenvolvimento software não tem

obtido sucesso, pois dependem do julgamento e da criatividade dos desenvolvedores

(SOMMERVILLE, 2003). Existem ferramentas Computer-Aided Software Engineering

(CASE), as quais são desenvolvidas com o objetivo de auxiliar e apoiar as atividades voltadas

para o processo de software (SOMMERVILLE, 2003).

Segundo Magela (2006), “a Engenharia de Software visa garantir que o processo

empregado seja suficiente e garanta que o software em todo o seu ciclo de vida seja passível

de gerência e controle e que possua a qualidade esperada”.

O ciclo de vida do software envolve desde o início da ideia de sua criação até a sua

desativação. Como o processo de software deve atender todo o ciclo de vida de um software,

ele estará presente em todas as etapas de desenvolvimento propriamente ditas, chegando ao

conceito de modelo de Ciclo de Vida de um Processo (MAGELA, 2006).

Ainda segundo Magela (2006), o modelo de Ciclo de Vida de um processo, engloba os

seguintes ciclos do desenvolvimento:

a) ciclo de especificação, etapa responsável pela análise do problema;

b) ciclo de construção, etapa responsável pela construção do projeto de sistemas,

implementação e testes;

c) ciclo de implantação, etapa responsável pelas atividades de implantação e

Avaliação, Qualidade e Melhoria (AQM);

15

d) ciclo de manutenção, etapa responsável pela manutenção e evolução dos artefatos

gerados nos ciclos anteriores.

2.22.2 MANUTENÇÃO DE SOFTWAMANUTENÇÃO DE SOFTWARERE

Durante o desenvolvimento de um software são realizadas diversas atividades que em

si, produzem uma série de documentos e artefatos que permitem a construção de um sistema

de computador. A entrega de um software ao mercado promove o início da fase de

manutenção do ciclo de vida (PETERS; PEDRYCS, 2001).

O ciclo de vida da manutenção de software é um processo de mudanças, as quais

podem ser mudanças simples, que tem como finalidade corrigir erros de codificação,

mudanças para correção de falhas de projeto e especificação, ou até mesmo mudanças

necessárias para entregar novas funcionalidades (SOMMERVILLE, 2007).

A etapa de manutenção de software tem uma semântica diferente das demais

engenharias que utilizam o termo “manutenção” para se referir a uma atualização de um

produto devido à sua deterioração. Para a área de Engenharia de Software a manutenção é

vista como evolução ou aperfeiçoamento do produto ou software (MAGELA, 2006).

Segundo Magela (2006), a manutenção de software custa no mínimo 90% do valor

original do projeto, sem ter um limite para o valor máximo. O autor destaca as falhas nas

especificações como maior responsável pelo alto custo. Outro fator que influencia no valor e

no tempo em que é realizada a manutenção de um determinado software está no tamanho e a

sua complexidade (SOMMERVILLE, 2008). O ciclo de manutenção de software engloba as

etapas de correção, adaptação e evolução (MAGELA, 2006).

2.32.3 PROCESSOSPROCESSOS ÁGEISÁGEIS

Em 2001, dezessete especialistas em processos de desenvolvimento de software se

reuniram nos Estados Unidos, para criar a hoje conhecida Aliança Ágil que deu origem e

estabeleceu o “Manifesto Ágil” (AGILEMANIFESTO, 2014).

16

O “Manifesto Ágil” estabelece os seguinte conceitos:

a) indivíduos e interações ao invés de processos e ferramentas;

b) software executável ao invés de documentação;

c) colaboração do cliente ao invés de negociação de contratos;

d) respostas rápidas a mudanças ao invés de seguir planos.

Segundo Soares (2004), o “Manifesto Ágil” não descarta os processos, ferramentas e

documentação, ele apenas demonstra que os mesmos têm uma importância secundária quando

comparada aos indivíduos e interações seguindo o mesmo raciocínio para os demais conceitos

apresentados. Assim a equipe de desenvolvimento fica concentrada apenas no software, ao

invés do projeto e documentação.

O “Manifesto Ágil” deu origem aos processos ágeis, que se baseiam em especificações

interativas para o desenvolvimento e entrega de software. Com o objetivo principal de apoiar

o desenvolvimento de software para negócios onde ocorrem mudanças rápidas e constantes os

modelos ágeis são voltados para entregarem de forma rápida as necessidades e modificações

solicitadas pelo cliente (SOMMERVILLE, 2007).

Um dos processos ágeis que tiveram origem no “Manifesto Ágil” foi o Scrum. Além

dele foram apresentados os processos XP, Crystal, Adpative Software Development, DSDM,

entre outros.

2.3.1 Scrum

O processo Scrum, surgiu com a necessidade de Jeff Sutherland e Ken Schwaber de

encontrar uma forma não tradicional para o desenvolvimento de software. Baseando-se nos

trabalhos de Hirotaka Takeuchi e Ikujiru Nonaka, eles tiveram a idéia de utilizar o conceito de

times de Rugby, onde as equipes de projetos têm um objetivo comum e juntos buscam

alcançá-lo, ressaltando a importância da multidisciplinaridade e do autogerenciamento

(PHAM; PHAM, 2011).

Uma equipe Scrum é composta por um ScrumMaster, um Product Owner (Dono do

Produto) e de uma equipe de desenvolvimento multifuncional, que possua as habilidades

necessárias para a construção do software (PHAM; PHAM, 2011). Segundo Pham e Pham

(2011), o ScrumMaster é responsável pelo gerenciamento do projeto, o Product Owner é

responsável por obter as informações dos stakeholders, por elaborar a lista de requisitos e por

criar uma lista de tarefas denominada Backlog do Produto.

17

O Scrum apresenta o desenvolvimento dividido em iterações semanais, chamadas de

sprints. Os sprints definem um período de desenvolvimento de um projeto ou de determinada

funcionalidade, que não devem ultrapassar o prazo máximo de 30 dias, ou quatro iterações

(KNIBERG; SKARIN, 2009).

Para realizar o planejamento das atividades para a construção de um software, são

adotadas na concepção do projeto, as reuniões de Planejamento de Releases. Estas são

compostas pelas reuniões de planejamento de sprints. Estas reuniões são divididas em duas

etapas, onde na primeira etapa, o Product Owner juntamente com a equipe, de posse dos

requisitos apresentados pelos stakeholders, define o que será realizado em cada sprint. Na

segunda etapa, a equipe de desenvolvimento tem o foco de definir como as necessidades serão

desenvolvidas, identificando as tarefas a partir dos requisitos que foram apresentados na

primeira etapa, além de deduzir o tempo necessário para o desenvolvimento da tarefa. Neste

momento já são definidos os responsáveis pelo desenvolvimento de cada tarefa (PHAM;

PHAM, 2011).

O Planning Poker é um método bastante utilizado para realizar as estimativas das

atividades dentro do Scrum. A estimativa é realizada com um baralho de 13 cartas, onde a

atividade a ser estimada é apresentada e os membros devem escolher uma carta que contém a

sua visão da estimativa da tarefa levando em consideração todas as etapas do processo de

desenvolvimento.

Caso, as estimativas tenham uma grande divergência, é feita uma ponderação onde os

membros da equipe expõem as suas convicções referentes ao motivo de cada estimativa. Após

esta etapa, é realizado novamente o processo de escolha da carta com o valor referente a sua

estimativa. Se novamente houver uma grande divergência o processo é repetido (KNIBERG,

2007).

Para realizar o acompanhamento e andamento dos sprints, o Scrum adota o método de

Reunião Diária (Daily Scrum), a qual tem como objetivo ser rápida (tendo o tempo máximo

de realização de 15 minutos), e na maioria das vezes é realizada em pé, para que não se

alongue. Na reunião diária são levantadas as dificuldades para a realização das tarefas

programadas, além de identificar-se o seu andamento, para que, caso necessário, seja possível

tomar uma decisão para que não ocorra o não cumprimento do que foi planejado (KNIBERG;

SKARIN, 2009).

Por ser uma reunião que busca e valoriza a auto-organização, onde os membros da

equipe são responsáveis pela entrega, esta reunião tende a unir a equipe e fortalecer o

engajamento para entrega das atividades.

18

Antes do final de cada sprint são realizadas reuniões de revisão de sprint, que tem o

objetivo de identificar o que foi e o que não foi realizado. Esta etapa recebe o feedback

referente às entregas pelo Product Owner e obtém atualizações do Product Owner referentes

às mudanças de mercado ou do produto.

Logo após a etapa de revisão de sprint, é realizada a reunião de retrospectiva de sprint,

com o objetivo de identificar o que funcionou e o que não funcionou tendo em vista verificar

como os participantes podem contribuir para tornar a sua participação ainda mais eficaz para

o próximo sprint (PHAM; PHAM, 2011).

Todas as tarefas planejadas para determinado sprint, geralmente são registradas em um

Quadro de Tarefas (Task Board), representado normalmente por um quadro-branco em uma

parede (PHAM; PHAM, 2011).

2.3.2 Kanban

O Kanban é uma ferramenta para acompanhamento e monitoramento de tempo de

execução de tarefas. O Kanban é representado em um quadro que pode ser digital ou físico o

qual contém colunas, que representam cada etapa do processo de desenvolvimento de uma

atividade. Nestas colunas são adicionadas as tarefas em suas respectivas etapas e registrados

os movimentos de acordo com o progresso das mesmas (KNIBERG; SKARIN, 2009).

As principais colunas utilizadas no Kanban são: “A Fazer” (To Do), “Fazendo”

(Doing) e “Feito” (Done), conforme pode ser observado na Figura 1. Podem haver mais

colunas dependendo da realidade da equipe e do escopo do projeto.

Figura 1 – Quadro Kanban Digital

Fonte: Trello (2014).

O Kanban não define papéis dentro da equipe que o utiliza, apenas recomenda que a

equipe deve ser multidisciplinar, ou que a equipe seja dividida para atender determinadas

etapas do ciclo. O modelo baseia-se no conceito de fila de tarefas, onde são registradas as

tarefas e os membros das equipes responsáveis pela execução das mesmas. Para evitar e

19

mapear gargalos em etapas do ciclo, o Kanban utiliza limitadores de tarefas em andamento

(Work In Progress – WIP), que podem ser utilizados em cada estágio (KNIBERG; SKARIN,

2009).

2.42.4 SISTEMA ATUALSISTEMA ATUAL

A Senior Sistemas S/A é uma das maiores desenvolvedoras de sistemas de gestão no

Brasil. Além de desenvolver uma das mais completas soluções para gestão de pessoas do

mercado, disponibiliza produtos e serviços integrados para gestão empresarial, gestão de

acesso e segurança e um pacote completo de implantação, consultoria e suporte em TI.

Fundada em 1988 em Blumenau (SC), possui 6 filiais (São Paulo, Rio de Janeiro, Rio Grande

do Sul, Mato Grosso do Sul e Pernambuco) e cerca de 100 canais de distribuição em todo o

Brasil, totalizando 3 mil pessoas envolvidas – entre colaboradores, parceiros comerciais e

canais de distribuição (SENIOR, 2014).

Atualmente a equipe de manutenção do setor de Tecnologia da Senior Sistemas S/A,

utiliza para o monitoramento das tarefas planilhas que recupera informações da base de dados

de tarefas mantidas pela ferramenta de gestão de chamados e tarefas denominada 0800net.

Existem 3 planilhas que registram as seguintes informações:

a) tarefas do ciclo de versão;

b) tarefas de erros e dúvidas de clientes;

c) tarefas de backlog.

Para manter os dados atualizados, é necessário que as planilhas sejam atualizadas

constantemente, gerando uma sobrecarga ao gestor da equipe, pois somente os gestores

possuem permissão de acesso à base de dados.

No tratamento das tarefas existem prioridades e prazos para as resoluções. A única

forma de visualização de tarefas novas é viabilizada através de consultas a estas planilhas. Por

exemplo, uma tarefa reportando um erro que ocorreu em um cliente e que foi classificada

como sendo de prioridade alta, tem o prazo de um dia para o seu tratamento. Se a planilha não

for visualizada ou atualizada constantemente, pode ocorrer atraso no início de agendamento

da tarefa, o que ocasionará um problema no cumprimento do prazo. Isto afetará diretamente o

indicador de qualidade do produto, fazendo com que a meta do indicador não seja atingida.

Outro problema que a equipe de manutenção enfrenta está relacionada ao

gerenciamento das atividades da equipe, pois a ferramenta utilizada para esta tarefa apenas

20

oferece a utilização de um campo de sequência que serve para definir a ordem de tratamento

da tarefa. Sempre que houver uma alteração na ordem das tarefas, esse item deve ser alterado.

Além disso, no processo adotado anteriormente não existiam reuniões de planejamento

de atividades, o que em algumas situações resultava em ociosidade ou sobrecarga na equipe

de manutenção. Em função desta realidade, foi realizado um experimento adotando alguns

conceitos de Scrum e Kanban no sentido de melhorar a qualidade do serviço realizado e

ajustar os prazos de entrega para os clientes.

Do método Scrum optou-se por utilizar a definição de sprints semanais visando a

realização de reuniões diárias com o objetivo de verificar o andamento das atividades e

identificar desvios e impedimentos que ocorreram no dia anterior e verificar o status das

atividades que estão sendo executadas. A cada semana, com o fechamento do sprint, é

realizada uma reunião para verificar como foi o andamento das atividades, verificar as

entregas e planejar a próxima semana, levando em consideração as lições aprendidas nas

semanas anteriores.

Além dos sprints, optou-se pelo modelo de Planning Poker para a realização de

estimativas de prazos para a conclusão de tarefas em função do conhecimento da equipe. As

estimativas são verificadas no final de cada sprint, para que, desta forma fortaleça-se e

aprimore-se a capacidade da equipe em estimar os prazos levando em consideração as lições

aprendidas.

Para o acompanhamento do processo optou-se pelo quadro Kanban digital suportado

pela ferramenta Trello. Deve-se destacar que uma das dificuldades encontradas com este

encaminhamento está relacionada ao fato de que esta ferramenta não possui integração com o

software gestor de chamados e tarefas utilizado pela empresa. Isto gera retrabalho na medida

em que os líderes de equipe necessitem cadastrar as tarefas nesta segunda ferramenta.

2.52.5 TRABALHOS CORRELATOSTRABALHOS CORRELATOS

A utilização de conceitos de processos ágeis na manutenção de software, não é uma

prática comum o que tornou o processo de identificação de trabalhos correlatos uma tarefa

difícil. Neste contexto, foram relacionados o trabalho de Mello (2010), o trabalho de Santos,

Souza e Nascimento, (2011) e utilizado a ferramenta de quadro Kanban Trello (2014).

21

Mello (2010), descreve a implementação de uma ferramenta web para prover o

gerenciamento de projetos para equipes Scrum. A ferramenta possibilita o gerenciamento do

projeto desde a sua concepção, gerenciando o product backlog, os sprints, as reuniões diárias,

as reuniões de retrospectiva e as reuniões de revisão, além de prover relatórios de tarefas

pendentes e relatórios estatísticos. O projeto não contemplou a utilização do quadro de tarefas.

O projeto foi desenvolvido em C#, utilizando as tecnologias, Silverlight, Microsoft Blend e

MySql. Umas das telas principais do sistema, pode ser observada na Figura 2.

Figura 2 – Tela do sistema

Fonte: Mello (2010)

Para embasar o desenvolvimento do quadro Kanban digital, optou-se pela ferramenta

Trello. Como citado anteriormente, o Trello é um ferramenta web, de propriedade da empresa

Fog Creek Software, que contempla as funcionalidades de criação de quadro de tarefas

(boards) além de possibilitar a edição das colunas, conforme a necessidade, a tela do Trello

pode ser observada na Figura 1, presente na seção 2.3.2.

Dentro do quadro de tarefas é possível cadastrar tarefas e atribuir responsáveis pelo

tratamento das mesmas. Nas tarefas é permitido a utilização de tags representadas no software

22

como cores que são associadas as mesmas, além de ser possível a colocação de comentários e

a atribuição de procedimentos (check list).

O usuário criador dos quadros pode adicionar pessoas, desde que previamente

cadastradas na ferramenta, as quais irão compor a equipe que será alocada a uma tarefa.

Santos, Souza e Nascimento (2011) apresentam o conceito de aplicação do quadro

Kanban associado a conceitos do Scrum. A ferramenta, liberada como open source,

disponibiliza as funcionalidades de criação de sprints, histórias e tarefas além de possibilitar a

geração de gráficos e estatísticas. A ferramenta web, foi construída utilizando-se as

tecnologias JSP, Google Web Toolkit para os Gráficos, TomCat como Container Web,

Hibernate para consistência dos dados, e HyperSQL como banco de dados. A principal tela do

sistema, pode ser observada na Figura 3.

Figura 3 – Tela do sistema desenvolvido

Fonte: Santos, Souza e Nascimento (2011)

23

3 DESENVOLVIMENTO DA FERRAMENTA

Neste capítulo estão descritos os aspectos técnicos utilizados no desenvolvimento do

sistema, como o levantamento de informações, os requisitos funcionais, os não funcionais e as

regras de negócio. Além dos diagramas utilizados no desenvolvimento, como o diagrama de

casos de uso e modelo de entidade e relacionamento. Estão descritas também as técnicas e

ferramentas utilizadas, a operacionalidade da implementação e os resultados obtidos.

3.13.1 LEVANTAMENTO DE INFOLEVANTAMENTO DE INFO RMAÇÕESRMAÇÕES

Para o desenvolvimento deste trabalho foram utilizadas informações, feedbacks e um

protótipo de processo que foi implantado na equipe de manutenção do framework de

desenvolvimento da empresa Senior Sistemas S/A. Este processo utilizado continha algumas

etapas manuais que dependiam de usuários, e como o tempo gasto nestas etapas era um tempo

desnecessário, foi concebida a ideia de automatizar e torná-lo mais simples, afim de obter

ganhos em produtividade.

Para suprir esta necessidade, foi desenvolvido um sistema denominado TaskBoardDev,

que utiliza as informações provenientes do software gerenciador de atividades utilizado pela

empresa, disponibilizando o acompanhamento e monitoramento das atividades em tempo real,

utilizando conceitos do Scrum e Kanban. Para desempenhar as suas funcionalidades, optou-se

por utilizar a arquitetura web, disponibilizando o acesso ao mesmo na intranet da empresa,

como pode ser observado na Figura 4, onde está presente o diagrama da arquitetura do

sistema desenvolvido.

24

Figura 4 – Arquitetura do Sistema

Para contemplar as necessidades em relação a aplicação, foram desenvolvidos quatro

módulos:

a) módulo geral: que está disponível para qualquer indivíduo que tenha acesso na

intranet da empresa;

b) módulo desenvolvedor: que está disponível para os membros da equipe através de

controle de acesso;

c) módulo administrador: que está disponível apenas ao administrador do sistema,

através de controle de acesso;

d) módulo monitor: que está disponível através de uma URL específica e conta com a

visualização de todas as views cadastrada pelo administrador, com a transição das

mesmas realizadas de maneira automática, indicado para ser utilizado em um tela

que fique no meio da equipe para facilitar a visualização.

3.23.2 ESPECIFICAÇÃOESPECIFICAÇÃO

A seguir é apresentada a especificação do sistema, contemplando os requisitos

funcionais, requisitos não funcionais e regras de negócio, além dos diagramas de casos de uso

e o modelo de entidade relacionamento (MER). Para criar o diagrama de caso de uso foi

utilizada a ferramenta Enterprise Architect (EA) da Sparx Systems, já para a criação do MER

foi utilizado a ferramenta DBDesigner.

25

3.2.1 Requisitos do Sistema

Nesta subseção são apresentadas as principais características e funcionalidades do

sistema. Com base na seção 2.4 e no protótipo do processo, foram elaborados os requisitos

para atender as principais necessidades encontradas atualmente.

No Quadro 1, são apresentados os requisitos funcionais do sistema relacionados com

os seus respectivos casos de uso.

Quadro 1 – Requisitos funcionais

Requisitos Funcionais Caso de Uso

RF01 – O sistema deverá buscar as informações das tarefas de um gerenciador de tarefas.

UC02, UC10 , UC11 e UC12

RF02 – O sistema deverá realizar o ranking das tarefas conforme retornado na extração realizada na fonte de dados.

UC04

RF03 – O sistema deverá manter equipes de desenvolvimento. UC09

RF04 – O sistema deverá permitir a consulta de tarefas. UC05

RF05 – O sistema deverá manter o acesso à base de dados dos gerenciadores de tarefas.

UC10

RF06 – O sistema deverá permitir o cadastro de verificação de tarefas críticas (Critical Tasks).

UC11

RF07 – O sistema deverá permitir manter as TaskViews. UC12

RF08 – O sistema deverá permitir manter as ExternalViews. UC13

RF09 – O sistema deverá permitir manter as MyTaskViews. UC02

RF10 – O sistema deverá permitir manter o Quadro de Tarefas (Kanban). UC08

RF11 – O sistema deverá permitir manter as Reuniões Diárias. UC06

RF12 – O sistema deverá permitir manter o gerenciamento das tarefas no Quadro de Tarefas.

UC03

RF13 – O sistema deverá permitir o registro de impedimentos. UC01

RF14 – O sistema deverá permitir a consulta ao ranking de tarefas. UC04

RF15 – O sistema deverá permitir a consulta ao Quadro de Tarefas. UC14

RF16 – O sistema deverá gerar o relatório dos impedimentos da equipe para o Daily Meeting.

UC07

No Quadro 2, são apresentados os requisitos não funcionais utilizados no

desenvolvimento do sistema.

26

Quadro 2 – Requisitos não funcionais

Requisitos Não Funcionais

RNF01 – O sistema deverá integrar com o Oracle 10g e SQL Server 2008R2.

RNF02 – O sistema será implementado em JSF 2.2.

RNF03 – O sistema deverá ser compatível com o navegador Web Chrome em versões superiores a 35.

RNF04 – O sistema deverá utilizar o servidor web – Oracle GlassFish Server 4.1.

No Quadro 3, são apresentadas as regras de negócios utilizadas no desenvolvimento do

sistema.

Quadro 3 – Regras de negócio

Regras de Negócio

RN01 – O sistema deve buscar as informações das tarefas de uma base de dado externa.

RN02 – Um funcionário só pode pertencer a uma célula de desenvolvimento.

RN03 – O administrador deve cadastrar os templates dos quadros Kanban, onde será definido as raias e as condições para que a tarefa seja movimentada.

RN04 – Uma célula pode ter um ou mais quadros Kanban configurados.

RN05 – Só pode ser realizada apenas uma daily meeting por dia de um determinado sprint.

3.2.2 Diagrama de Casos de Uso

Na Figura 5, é apresentado o diagrama de casos de uso desenvolvido. Os casos de uso

de UC 01, UC 02, UC 03, UC 04, UC 05, UC 06, UC 07, UC 08 e UC 14 são acionados pelos

principais usuários (desenvolvedor, analista e coordenador), além destes, os usuários externos,

também chamados de stakeholders, possuem acesso ao UC 04 e UC 05. Os casos de uso UC

09, UC 10, UC 11, UC 12 e UC 13 são de acesso exclusivo do usuário admin do sistema.

O detalhamento dos casos de usos estão no Apêndice A.

27

Figura 5 – Diagrama de casos de uso

3.2.3 Modelo de Entidade e Relacionamento

Na Figura 6 é apresentado o modelo de entidade e relacionamento do sistema. O

dicionário de dados está descrito no Apêndice B.

28

Figura 6 – Modelo de entidade e relacionamento

A seguir é apresentada uma breve descrição das entidades criadas para o

desenvolvimento do sistema:

29

a) ACESSOBANCO: entidade que armazena as informações de acesso aos bancos

externos para consulta das atividades que serão monitoradas e rastreadas pelo

sistema;

b) CELULA: entidade que armazena as células de trabalho;

c) DAILYMEETING: entidade que armazena as informações das reuniões

diárias(Daily Meeting);

d) DAILYMEETING_IMPEDIMENTO: entidade intermediária que armazena o

relacionamento entre as Daily Meetings e os Impedimentos;

e) DAILYMEETING_STATUS: entidade intermediária que armazena o

relacionamento entre as Daily Meetings e os Status;

f) EXTERNAL_VIEW: entidade que armazena os dados das views externas que

podem ser configuradas para serem apresentadas pelo sistema.

g) FUNCIONARIO: entidade responsável por armazenar os dados dos funcionários;

h) IMPEDIMENTO: entidade que armazena os dados dos impedimentos que são

relatados nas Daily Meetings;

i) KANBAN: entidade que armazena os dados dos quadros Kanban;

j) KANBAN_RAIA: entidade intermediária que armazena o relacionamento entre o

Kanban e as Raias;

k) KANBANSPRINT: entidade que armazena o quadro Kanban de determinado

Sprint;

l) KANBANSPRINT_TASKKANBAN: entidade intermediária que armazena a

relação entre o quadro Kanban de um Sprint e as tarefas/atividades que compõe o

mesmo;

m) MYVIEWTASK: entidade que armazena a configuração das views configuradas

pelos usuários;

n) RAIA: entidade que armazena as raias dos quadros Kanban;

o) SELECTCRITICALTASK: entidade que armazena a query responsável por

verificar se existem tarefas/atividades com urgência de tratamento;

p) SELECTVIEW: entidade que armazena as query das views;

q) SPRINT: entidade que armazena os dados dos Sprints;

r) STATUS: entidade que armazena os status dos membros das equipes nas Daily

Meetings;

30

s) TASKCOMMENT: entidade que armazena os comentários das tarefas dos quadros

Kanban;

t) TASKKANBAN: entidade que armazena os dados das tarefa são acompanhadas

pelo quadro Kanban;

u) TASKKANBAN_TASKCOMMENT: entidade intermediária que armazena a

ligação entre as tarefas do quadro Kanban e os comentários;

v) VIEWTASK: entidade que armazena as informações das views que são

configuradas pelo Administrador do sistema, e que ficam disponíveis para todos.

3.33.3 IMPLEMENTAÇÃOIMPLEMENTAÇÃO

A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da

implementação.

3.3.1 Técnicas e ferramentas utilizadas

Para o desenvolvimento do sistema foi utilizada a IDE NetBeans 8.0.1 e o banco de

dados Oracle XE para a persistência dos dados do sistema. Por se tratar de uma aplicação web

optou-se por utilizar o framework JSF 2.2 (Java Server Faces), juntamente com o PrimeFaces

5.0 para o front-end da aplicação, no server é utilizado a linguagem de programação Java.

Para a persistência dos dados foi utilizado o Hibernate 4.3, juntamente com o JPA 2.1 (Java

Persistence API), que possibilita através de anotações nas classes Java, o controle da estrutura

das tabelas, relacionando-as aos objetos. Na Figura 7, pode-se observar o trecho do código

fonte, onde está declarado o objeto referente ao sprint, com as anotações para a persistência

dos dados.

31

Figura 7 – Código com anotações de persistência

Para a consulta dos dados do banco de dados externo foi utilizado os recursos padrão

do Java, onde utiliza-se os drivers de conexão com o banco de dados, para que seja possível

executar as buscas, como pode ser observado no trecho de código presente na Figura 8.

Figura 8 – Código de conexão com o banco de dados externo

3.3.2 Operacionalidade da implementação

Nesta subseção são apresentadas as funcionalidades de cada módulo desenvolvido,

juntamente com as suas principais telas, ainda contendo alguns trechos de código fonte das

rotinas desenvolvidas.

O sistema é composto por quatro módulos: o módulo geral, o módulo desenvolvedor, o

módulo administrador e o modulo monitor.

32

O módulo geral está disponível a qualquer indivíduo que tenha acesso a intranet da

empresa. Em sua página principal conta com as views cadastradas pelo administrador do

sistema, conforme pode ser observado na Figura 9.

Figura 9 – Tela principal

Nesta tela principal, são apresentadas as views, onde as tarefas são agrupadas conforme

status. Ainda nesta tela, tem-se a opção “Atualizar”, que atualiza os dados das views

apresentadas. Além da opção de login, que redireciona para a página de login do sistema, que

possibilita a entrada no Módulo Desenvolvedor ou Administrador, dependendo do usuário

informado.

A tela de login, habilita o acesso aos módulos Desenvolvedor e Administrador,

conforme o seu nível de acesso. A tela pode ser observada na Figura 10.

33

Figura 10 – Tela de login

Além do acesso através do Módulo Geral, a tela de login será apresentada sempre que

forem realizadas tentativas de acessar telas que não são correspondentes a sua devida

permissão. Isto é feito através do PhaseListener que permite interceptar as tentativas de

acesso e verificar se é realmente procedente e se o acesso deve ser liberado. Uma parte do

código fonte responsável por isto, pode ser verificado na Figura 11.

Figura 11 – Código fonte do PhaseListener

O Módulo administrador possui um menu principal com as seguintes funcionalidades:

a) taskBoard;

b) cadastros;

34

c) settings.

Na opção TaskBoard, são apresentadas todas as views cadastradas no sistema, para que

no momento da inserção ou alteração de uma view o Administrador tenha acesso para

verificar o resultado, conforme pode ser observado na Figura 12.

Figura 12 – Módulo Administrador - TaskBoard

Na opção de Cadastros, estão disponíveis as opções de cadastros oferecidas pelo

sistema, quais sejam:

a) cadastro de funcionários;

b) cadastro de células;

c) cadastro de quadros Kanban, e;

d) cadastro de acesso a banco de dados.

Na Figura 13, é apresentada a tela de cadastro de funcionários que permite que os

colaboradores sejam cadastrados na aplicação e inseridos em suas devidas células de trabalho.

35

Figura 13 – Módulo Administrador - Cadastro

Além do cadastro de funcionários, nesta opção é possível realizar o cadastro dos

quadros Kanban, que servem de apoio para o Sprint. Onde ao realizar o Sprint são definidas

as entregas para o ciclo, estas entregas são monitoradas através do quadro Kanban. Para

utilizar o quadro Kanban integrado com o software de controle das tarefas, algumas

configurações são necessárias. O cadastro de quadros são realizados por célula de trabalho,

onde células podem ter filtros e listas de tarefas diferentes. O cadastro do quadro Kanban

pode ser observado na Figura 14.

Figura 14 – Cadastro de quadro Kanban

Em todo quadro Kanban existem raias, que representam estágios de determinada

tarefa. Estes estágios são cadastrados, contendo um select, que é uma consulta que será

realizada na base de dados referente ao Pool de tarefas selecionado, contendo uma condição,

onde as tarefas pertencentes ao quadro são filtradas e agrupadas em cada raia conforme o

36

cadastro. Com isto, o sistema irá apresentar o estágio da tarefa conforme a mesma for

atualizada no software de gerenciamento das atividades. O cadastro de raias, pode ser

observado na Figura 15.

Figura 15 – Cadastro de raias do Kanban

Na opção Seetings, há três funcionalidades:

a) Views;

b) Select Critical Task;

c) External View.

Em Views, está disponível a configuração e edição das views disponíveis no sistema,

que serão visualizadas por todos os usuários, conforme pode ser observado na Figura 16.

37

Figura 16 – Módulo Administrador - Settings

O cadastro das views devem conter os seguintes campos principais:

a) número;

b) título;

c) vencimento;

d) responsável;

e) localização;

f) prioridade;

g) status.

Há uma restrição associada ao banco de dados utilizado onde a consulta não pode

conter mais de 4000 caracteres.

Além de informar os identificadores dos campos que serão recuperados do select

informado, é também selecionado o banco de dados em que será realizado a extração destas

informações. Os dados resultantes da extração alimentam os objetos do sistema referente as

tarefas, conforme pode ser observado na Figura 17.

38

Figura 17 – Trecho do código fonte responsável por popular as tarefas no sistema

A opção Select Critical Tasks, permite que os membros da equipe de desenvolvimento

sejam avisados que existe alguma tarefa crítica e que deve ser verificada o mais rápido

possível. A tela de configuração pode ser observada na Figura 18.

Figura 18 – Módulo Administrador - Select Critical Tasks

39

Quando uma busca retornar algum dado no sistema isto irá acionar o “Giroflex” na tela

de monitoramento, buscando chamar a atenção da equipe, uma vez que esta opção é utilizada

em tarefas que tem prazos curtos e necessitam de atenção. Segue o mesmo padrão do cadastro

das views em relação aos campos necessários.

As External Views possibilitam que seja adicionada ao monitor de tarefas o acesso a

conteúdos externos, onde possam conter qualquer tipo de informação, por exemplo, pode ser

adicionado os dados de uma view de um BI sobre indicadores, além de gráficos que sejam

necessários para o monitoramento. A tela de cadastro das External Views pode ser observado

na Figura 19.

Figura 19 – Cadastro de External View

O Módulo Desenvolvedor possui as seguintes opções no menu principal:

a) taskboard;

b) my views;

c) kanban;

d) sprint;

e) settings.

Na opção TaskBoard, como no Módulo de Administrador, estão disponíveis as views

que foram cadastradas no sistema.

Na opção My Views, são apresentadas as views que foram cadastradas pelo usuário no

menu Settings, conforme pode ser observado na Figura 20. Segue o estilo das views que são

cadastradas pelo Administrador, mas permite que os colaboradores tenham suas próprias

40

views para realizar o autogerenciamento dos respectivos trabalhos.

Figura 20 – Módulo Desenvolvedor - My Views

Na opção Kanban, estão disponíveis os quadros Kanban dos sprints em andamento.

A opção Sprint, conta com o cadastro de acompanhamento das entregas das atividades

de determinado ciclo, chamado de Sprint, conforme pode ser observado na Figura 21.

Figura 21 – Cadastro de Sprint

41

No Sprint são definidas as entregas que se espera sejam finalizadas no término

do período. Estas entregas serão monitoradas através do quadro Kanban que é

configurado pelo botão de lupa presente na tela. No Kanban será definido o quadro de

modelo que será utilizado, e nele serão definidas as entregas. Esta opção de definição

só estará disponível em quando o mesmo estiver com o Status “Em planejamento”,

após isto, as informações do Kanban estarao disponíveis somente pra consulta,

impossibilitando a sua edição. A tela da configuração do Kanban pode ser observada

na Figura 22.

Figura 22 – Tela de configuração do Kanban do Sprint

Ainda nesta tela, pode-se observar os desvios da entrega, que são as tarefas que

entraram após a definição do Sprint. Estes desvios são comuns na manutenção, pois, nesta

fase do desenvolvimento de software o produto está no cliente e caso pare de funcionar pode

interromper o negócio do mesmo o que gera demanda à equipe de manutenção.

Uma prática do Scrum é a realização de reuniões diárias para monitoramento das

atividades de um determinado Sprint, dentro desta opção, é disponibilizado o cadastro das

daily meetings, conforme pode ser observado na Figura 23.

42

Figura 23 – Cadastro Daily Meeting

Em cada reunião está disponível, para ser registrado os status de todos os

colaboradores da célula pertencente ao Sprint, conforme pode ser observado na Figura 24.

Figura 24 – Cadastro de Status da Daily Meeting

43

Além do Status das atividades, ainda está disponível o cadastro de impedimentos,

conforme pode ser observado na Figura 25.

Figura 25 – Cadastro de Impedimentos da Daily Meeting

Na opção Settings do menu principal, estão disponíveis a configuração das My Views e

a troca de senha.

Em My Views, é possível que o usuário crie suas próprias visões das tarefas, podendo

filtrar e buscar qualquer tarefa conforme sua necessidade, buscando maior controle e

autogerenciamento. A tela pode ser observada na Figura 26.

44

Figura 26 – Módulo Desenvolvedor - Settings - My Views

A tela segue os mesmos padrões de campos necessários do cadastro de views do

Administrador.

Este módulo, ainda conta com a opção da troca de senha, conforme pode ser observado

na Figura 27.

Figura 27 – Módulo Desenvolvedor - Settings - Troca de Senha

45

O Módulo Monitor foi criado para apresentar as tarefas/atividades e disponibilizar o

monitoramento para a equipe. Devido a questões de infra estrutura o seu link deve ser restrito

ao monitor de TV, pois este módulo conta com o refresh automático dos dados, e realiza a

cada 60 segundos os selects cadastrados no sistema pelo Administrador.

O módulo foi desenvolvido para monitores de TV de no mínimo 21 polegadas, com

resolução 1920x1280.

Para acessar este módulo, é necessário adicionar na URL principal da aplicação o

endereço: TemplateTaskMonitor.jsf. A tela principal pode ser visualizada na Figura 28.

Figura 28 – Módulo Monitor – Template Monitor

Esta é a visão que toda a equipe tem referente às tarefas, que são apresentadas em um

monitor de TV estrategicamente posicionado no local de trabalho.

Esta visão realiza de forma automática a atualização dos dados e a troca entre as views

cadastradas no sistema, possibilitando o acompanhamento de todas as views, inclusive as

External Views.

Se durante o processo de atualização é verificado que existe alguma tarefa crítica, o

sistema redireciona para uma página que contem as tarefas críticas e um “Giroflex”, buscando

alertar a equipe, conforme pode ser observado na Figura 29.

46

Figura 29 – Módulo Monitor – Critical Tasks

3.43.4 RESULTADOS E DISCUSSRESULTADOS E DISCUSS ÃOÃO

O objetivo principal proposto por este trabalho foi atingido uma vez que foi

desenvolvido um sistema que contempla os requisitos identificados. O objetivo específico

que tinha por necessidade permitir a centralização e unificação de indicadores e

monitoramento de atividades de manutenção, foi atingido, pois o sistema desenvolvido

possibilita a integração com sistemas gerenciadores de tarefas existentes, através da base de

dados, e expões os dados através de views, que podem ser views genéricas apresentadas para

todos, ou as “My Views”, que são views cadastradas pelos usuários do sistema, afim de prover

um melhor auto gerenciamento. Além disto, o sistema ainda possibilita a utilização de

External Views que permite que sejam apresentadas no monitor de TV, outras informações,

como por exemplo, o status de indicadores extraídos de um BI.

O segundo objetivo específico que tinha como necessidade permitir o gerenciamento

das reuniões de definição de entregas (sprints) e acompanhamento das tarefas de manutenção

(Kanban), foi atingido, pois, o sistema permite que sejam cadastrados os sprints, onde no

mesmo, são definidas as entregas que são acompanhadas através do quadro Kanban. O último

objetivo específico que tinha como necessidade permitir o gerenciamento das reuniões diárias

para verificar o andamento das entregas planejadas, foi atingido, pois o sistema possibilita o

47

controle das reuniões diárias, onde são informados os status e impedimentos das atividades

em relação ao dia anterior.

Em relação aos trabalhos correlatos, a ferramenta descrita em Mello (2010) serviu

como base à utilização do Scrum. A ferramenta Trello, que já é utilizada na empresa, serviu

para embasar a construção do quadro de tarefas (ou task board) além de contribuir para a

validação de usabilidade do projeto a ser construído. O trabalho de Santos, Souza e

Nascimento (2011), também foi utilizado na fundamentação teórica do presente projeto, e

como todos os trabalhos correlatos a ferramenta desenvolvida é web. O diferencial da

ferramenta desenvolvida está na integração com os sistemas de gerenciamento de atividades.

Com a utilização do sistema, esperasse uma facilidade na visibilidade do andamento

das atividades, além de um acompanhamento mais simples e fácil. Buscando prover uma

agilidade no processo utilizado atualmente, e assim, conseguir um ganho significativo de

tempo, que poderá ser utilizado para aumentar a produtividade. Inicialmente o sistema

desenvolvido será utilizado apenas pela equipe de manutenção do framework de

desenvolvimento, mas está para ser implantada nas demais equipes de manutenção e até em

algumas equipes de desenvolvimento de novos produtos.

48

4 CONCLUSÕES

Neste trabalho é apresentado um sistema para automatizar o monitoramento e

acompanhamento das atividades de manutenção de software, bem como possibilitar a

utilização de alguns conceitos ágeis, como os sprints e as daily meetings do Scrum e o quadro

Kanban. O sistema desenvolvido possibilita a integração com os softwares de gerenciamento

de atividades através de consultas direto na base, evitando o trabalho manual.

A utilização do JSF e do PrimeFaces ocorreu em função da experiência anterior do

autor com estas tecnologias. A utilização do Hibernate e do JPA, viabilizou o

desenvolvimento mais ágil, permitindo um maior grau de abstração em relação as estruturas

de dados utilizadas. Como pretende-se validar a ferramenta desenvolvida no ambiente da

empresa foi utilizado o banco de dados Oracle e o Glassfish como container de aplicações.

O desenvolvimento e a conclusão deste trabalho propiciaram ao autor a aplicação do

conhecimento adquirido durante o decorrer do curso, desde a realização do levantamento e

análise dos requisitos, até a preocupação com a usabilidade da interface, atendendo desta

forma às necessidades e objetivos da empresa e os objetivos propostos.

A maior contribuição deste trabalho está associada a adoção de conceitos de métodos

ágeis no ambiente de manutenção de software. Esta é uma iniciativa incipiente e a expectativa

que existe é que com a adoção em ambiente de produção a ferramenta adquira maturidade

suficiente para ser adotada formalmente nos processos da empresa.

4.14.1 EXTENSÕESEXTENSÕES

Como proposta de futuras extensões sugere-se:

a) desenvolver um mecanismo capaz de identificar o colaborador mais adequado para

o tratamento de determinada atividade, utilizando como base os conhecimento de

cada um e o tempo para a resolução de problemas anteriores;

b) possibilitar o acompanhamento dos tempos investidos nas tarefas;

c) desenvolver e aplicar novos conceitos de outras metodologias ágeis, e;

d) desenvolver um sistema de gerenciamento de atividades interno do sistema.

49

REFERÊNCIAS

AGILEMANIFESTO. Agile Manifesto. [S.l.], 2011. Disponível em:

<http://www.agilemanifesto.org>. Acesso em: 1 dez. 2014.

D’ÁVILA,Roberta Koehler. Sistema para gestão de chamados do 0800net utilizando

indicadores de desempenho baseado na técnica de regressão linear. 2007. 46. Trabalho de

Conclusão de Curso (Bacharelado em Sistemas de Informação), Universidade Regional de

Blumenau, Blumenau.

ELLEVO. Ferramenta de Gerenciamento de chamados e tarefas – 0800net. [S.l.], 2014.

Disponível em <http://www.ellevo.com.br>. Acesso em: 1 dez. 2014.

KNIBERG, Henrik. Scrum e XP direto das Trincheiras: Como fazemos Scrum. [S.l.],

2007. C4Media, 2007. Disponível em: <http://www.cti.ufu.br/sites/cti.ufu.br/files/scrum-e-

xp-direto-das-trincheiras.pdf>. Acesso em: 1 dez. 2014.

KNIBERG, Henrik; SKARIN, Mattias. Kaban e Scrum: Obtendo o melhor de ambos. [S.l.],

2009. C4Media, 2009. Disponível em: <http://www.infoq.com/br/minibooks/kanban-scrum-

minibook>. Acesso em: 1 dez. 2014.

MAGELA, Rogério. Engenharia de Software Aplicada - Princípios. Rio de Janeiro: Alta

Books, 2006. 337p.

50

MELLO, Vanessa de. Ferramenta Web para Gerenciamento de Projetos de Software

baseado no Scrum. 2010. 66p. Trabalho de Conclusão de Curso (Bacharelado em Ciências

da Computação), Universidade Regional de Blumenau, Blumenau.

PETERS, James; PEDRYCZ, Witold. Engenharia de software. Rio de Janeiro: Campus,

2001. 575p.

PHAM, Andrew; PHAM, Phuong-Van. Scrum em Ação: Gerenciamento e Desenvolvimento

Ágil de Projetos de Software. São Paulo: Novatec, 2011. 287p.

SANTOS, André Onuki dos; SOUZA, Cleumir dos Santos de; NASCIMENTO, Tiago Luiz

do. Taskboard Digital para Equipes Scrum. 2011. 64f. Trabalho de Conclusão de Curso

(Bacharelado em Ciências da Computação), Universidade Anhembi Morumbi, São Paulo.

SENIOR. Senior Sistemas S/A. [S.l.], 2014. Disponível em

<http://www.senior.com.br/senior >. Acesso em: 1 dez. 2014.

SOARES, Michel dos Santos, Comparação entre Metodologias Ágeis e Tradicionais para

o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos,

Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete, 2004. 6p.

SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Pearson Education do

Brasil, 2003. 592p.

SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson Education do

Brasil, 2007. 552p.

51

TRELLO. Ferramenta de Quadro Kanban. [S.l.], 2014. Disponível em

<https://trello.com>. Acesso em: 1 dez. 2014.

52

APÊNDICE A – Descrição dos Casos de Uso

A seguir estão descritos os casos de uso do sistema apresentado. No Quadro 4

apresenta-se o caso de uso “Cadastro de Impedimentos”.

Quadro 4 – Descrição do caso de uso registro de impedimentos

UC01 O sistema deverá permitir ao desenvolvedor realizar o registro de impedimentos.

Descrição Permite que o usuário cadastrado no sistema, relate um impedimento em determinada tarefa que o mesmo estiver envolvido no tratamento.

Ator Desenvolvedor

No Quadro 5, apresenta-se o caso de uso “Manter MyTaskView”.

Quadro 5 – Descrição do caso de uso Manter MyTaskView

UC02 O sistema deverá permitir ao desenvolvedor manter das MyTaskView.

Descrição Permite que o usuário crie, edite e delete suas próprias TaskViews, podendo realizar filtros conforme a sua necessidade.

Ator Desenvolvedor

Pré-condição Usuário autenticado no sistema; Acesso a Banco de Dados Externo cadastrado.

Fluxo principal

1. Usuário vai no menu Settings; 2. Usuário vai na aba MyTaskView;

3. Usuário informa o nome da MyTaskView; 4. Usuário informa os alias de extração de informação (Numero, Titulo,

Prioridade, Vencimento, Responsável, Localização, Status etc.);

5. Usuário informa uma consulta SQL que deve retornar as informações da tarefa e a ordem em que serão apresentadas;

6. Usuário informa o banco de onde será realizada a consulta;

7. Usuário clica em gravar.

Cenário – Visualização

Sistema mostra todas as MyTasksViews cadastradas.

Cenário – Edição

1. Realiza os passos de 1 a 2 do Fluxo principal;

2. Usuário seleciona um item para edição;

53

3. Usuário clica em Editar;

4. Sistema mostra os dados do item selecionado para edição; 5. Usuário realiza as modificações;

6. Usuário clica em Gravar; 7. Sistema mostra o item cadastrado com o registro alterado.

Cenário – Exclusão


2. Usuário seleciona um item para exclusão; 3. Usuário clica em Excluir;

4. Sistema excluí o item selecionado e mostra os restantes.

Cenário – Apresentação

1. Usuário vai no menu MyTaskViews;

2. O sistema irá apresentar todas as MyTaskViews cadastrados pelo usuário, apresentando em cada visão as tarefas que foram retornadas conforme a consulta/query cadastrada.

Pós-condição Usuário visualizou, editou, incluiu ou excluiu um item e verificou a apresentação da MyTaskView.

No Quadro 6, apresenta-se o caso de uso “Atualizar o Quadro de Tarefas”.

Quadro 6 – Descrição do caso de uso Atualizar o Quadro de Tarefas

UC03 O sistema deverá permitir ao desenvolvedor a atualização do quadro de tarefas.

Descrição Permite que os usuários cadastrados no sistema, realizem a manipulação do quadro de tarefas, mudando as etapas, atribuindo responsáveis, removendo e adicionando novas tarefas.

Ator Desenvolvedor

No Quadro 7, apresenta-se o caso de uso “Consultar Ranking das Tarefas”.

Quadro 7 – Descrição do caso de uso Consultar Ranking das Tarefas

UC04 O sistema deverá permitir ao desenvolvedor e ao usuário externo (Stakeholder) a consulta ao ranking de tarefas.

Descrição Permite que os usuários cadastrados no sistema, e os usuários externos (Stakeholder) tenham acesso a visão de ranking das tarefas.

Ator Desenvolvedor, Usuário Externo (Stakeholder)

No Quadro 8, apresenta-se o caso de uso “Consultar Tarefas”.

54

Quadro 8 – Descrição do caso de uso Consultar Tarefas

UC05 O sistema deverá permitir ao desenvolvedor e ao usuário externo (Stakeholder) a consulta de tarefas.

Descrição Permite que os usuários cadastrados no sistema, e os usuários externos (Stakeholder) tenham acesso a visão de consulta das tarefas.


No Quadro 9, apresenta-se o caso de uso “Cadastro de Reunião Diária”.

Quadro 9 – Descrição do caso de uso Cadastro de Reunião Diária

UC06 O sistema deverá permitir ao analista o cadastro de reunião diária.

Descrição Permite que o analista realize o cadastro da reunião diária (dailly meeting).

Ator Analista

No Quadro 10, apresenta-se o caso de uso “Relatório de impedimentos da equipe”.

Quadro 10 – Descrição do caso de uso Relatório de impedimentos da equipe

UC07 O sistema deverá permitir ao analista a emissão de relatório dos impedimentos da equipe.

Descrição Permite que o analista tenha acesso ao relatório dos impedimentos da equipe, para que seja possível identificar os impedimentos e tomar decisões na reunião diária.

Ator Analista

No Quadro 11, apresenta-se o caso de uso “Definição do Quadro de Tarefas”.

Quadro 11 – Descrição do caso de uso Definição do Quadro de Tarefas

UC08 O sistema deverá permitir ao analista a possibilidade de definir o quadro de tarefas.

Descrição Permite que o analista possa cadastrar o quadro de tarefas da semana, adicionando tarefas, atribuindo responsável para as mesmas, e ainda cadastrar as colunas de etapas do tratamento da tarefa.

Ator Analista

No Quadro 12, apresenta-se o caso de uso “Manter equipe”.

55

Quadro 12 – Descrição do caso de uso Manter equipe

UC09 O sistema deverá permitir ao Admin o cadastro de equipe.

Descrição Permite que o usuário Admin cadastre a equipe pertencente ao projeto.

Ator Admin

No Quadro 13, apresenta-se o caso de uso “Manter acesso de banco de dados externo”.

Quadro 13 – Descrição do caso de uso Manter acesso de banco de dados externo

UC10 O sistema deverá permitir ao Admin manter de acesso de banco de dados externo.

Descrição Permite que o usuário Admin crie, visualize, edite e delete os acessos aos bancos de dados externos.

Ator Admin

Pré-condição Usuário autenticado deve ter perfil “Admin”.

Fluxo principal 3. Admin vai no menu Cadastros; 4. Admin vai na aba Acesso Banco; 5. Admin seleciona o Banco de Dados (Oracle ou SQL Server);

6. Admin informa a JDBC de comunicação com o Banco de Dados; 7. Admin informa o usuário de acesso ao banco;

8. Admin informa a senha de acesso ao banco; 9. Admin clica em gravar.


Sistema mostra todos os Acessos de Banco de Dados cadastrados.

Cenário – Edição 8. Realiza os passos de 1 a 2 do Fluxo principal;

9. Admin seleciona um item para edição; 10. Admin clica em Editar;

11. Sistema mostra os dados do item selecionado para edição; 12. Admin realiza as modificações;

13. Admin clica em Gravar; 14. Sistema mostra o item cadastrado com o registro alterado.


5. Realiza os passos de 1 a 2 do Fluxo principal; 6. Admin seleciona um item para exclusão;

7. Admin clica em Excluir; 8. Sistema excluí o item selecionado e mostra os restantes.

Pós-condição Admin visualizou, editou, incluiu ou excluiu um item.

56

No Quadro 14, apresenta-se o caso de uso “Manter consulta de Critical Tasks”.

Quadro 14 – Descrição do caso de uso Manter consulta de Critical Tasks

UC11 O sistema deverá permitir ao Admin o cadastro de consulta de Critical Tasks

Descrição Após o usuário Admin ter o acesso ao banco de dados configurado, o mesmo pode informar um comando SQL que resultará na carga de informações das tarefas e o ranqueamento das mesmas, sendo apresentadas juntamente com um giroflex de atenção.

Ator Admin

Pré-condição Usuário autenticado deve ter perfil “Admin”; Deve ter cadastrado o acesso ao banco de dados externo.

Fluxo principal

1. Admin vai no menu Settings; 2. Admin vai na aba Select Critical Tasks;

3. Admin informa os alias de extração de informação (Numero, Titulo, Prioridade, Vencimento, Responsável, Localização, Status etc.)

4. Admin informa uma consulta/query SQL que deve retornar as informações da tarefa;

5. Admin informa o banco de onde será realizada a consulta; 6. Admin clica em gravar.


Sistema mostra as informações da consulta de Critical Tasks, apresentados os alias de extração, o “select” e o banco de dados de onde a consulta é realizada.



2. Sistema mostra os dados para edição; 3. Admin realiza as modificações;

4. Admin clica em Gravar; 5. Sistema mostra o item cadastrado com o registro alterado.


Se a consulta cadastrada retornar algum dado, o sistema irá apresentar na visualização “Monitor” as informações da(s) tarefa(s) juntamente com um giroflex para chamar a atenção da equipe.

Pós-condição Admin visualizou, editou ou incluiu uma consulta de Critical Tasks.

No Quadro 15, apresenta-se o caso de uso “Manter TaskView”.

Quadro 15 – Descrição do caso de uso Manter TaskView

UC12 O sistema deverá permitir ao Admin manter as TaskView.

Descrição Permite que o usuário Admin consiga criar, editar e excluir as TaskViews do sistema.

57

Ator Admin

Pré-condição Usuário autenticado deve ter perfil “Admin”;

Acesso a Banco de Dados Externo cadastrado.

Fluxo principal

1. Admin vai no menu Settings;

2. Admin vai na aba Views; 3. Admin informa o nome da TaskView;

4. Admin informa os alias de extração de informação (Numero, Titulo, Prioridade, Vencimento, Responsável, Localização, Status etc.);

5. Admin informa uma consulta/query SQL que deve retornar as informações da tarefa e a ordem em que serão apresentadas;

6. Admin informa o banco de onde será realizada a consulta; 7. Admin clica em gravar.


Sistema mostra todas as TasksViews cadastradas.


1. Realiza os passos de 1 a 2 do Fluxo principal; 2. Admin seleciona um item para edição;

3. Admin clica em Editar; 4. Sistema mostra os dados do item selecionado para edição;

5. Admin realiza as modificações; 6. Admin clica em Gravar;

7. Sistema mostra o item cadastrado com o registro alterado.



2. Admin seleciona um item para exclusão; 3. Admin clica em Excluir;

4. Sistema excluí o item selecionado e mostra os restantes.


1. Admin vai no menu DashBoard;

2. O sistema irá apresentar todas as TaskViews cadastrados pelo Admin, apresentando em cada visão as tarefas que foram retornadas conforme o “select” cadastrado.

Pós-condição Admin visualizou, editou, incluiu ou excluiu um item e verificou a apresentação da TaskView.

No Quadro 16, apresenta-se o caso de uso “Manter ExternalView”.

Quadro 16 – Descrição do caso de uso Manter ExternalView

UC13 O sistema deverá permitir ao Admin a configuração de ExternalView.

58

Descrição Permite que o usuário Admin consiga configurar a exibição de um conteúdo externo, exemplo, uma view de um BI, que pode ser apresentado no monitor, configurando também o período de exibição.

Ator Admin

No Quadro 17, apresenta-se o caso de uso “Consultar Quadro de Tarefas”.

Quadro 17 – Descrição do caso de uso Consultar Quadro de Tarefas

UC14 O sistema deverá permitir ao desenvolvedor e ao usuário externo (Stakeholder) a consulta ao quadro de tarefas.

Descrição Permite que seja possível a visualização do andamento das tarefas, sendo acompanhado pelo quadro de tarefas pelos usuários externos e os usuários cadastrados no sistema.


59

APÊNDICE B – Descrição do Dicionário de Dados

Este Apêndice apresenta a descrição das tabelas do banco de dados apresentadas na

seção de especificação deste trabalho. Os tipos de dados utilizados nos atributos são:

a) integer: armazena números inteiros;

b) varchar: armazena caracteres alfanuméricos;

c) date: armazena data.

No Quadro 18, apresenta-se a tabela de acesso a banco.

Quadro 18 – Tabela de acesso a banco

ACESSOBANCO

Armazena as informações de acesso aos bancos externos para consulta das atividades que serão monitoradas e rastreadas pelo sistema.

Campo Descrição Tipo Tamanho Chave primária

Chave estrangeira

CD_ACESSO Código acesso Integer X

CD_BANCO Código do banco Integer

DS_JDBC Descrição da jdbc Varchar 100

DS_PASSWORD Senha Varchar 50

DS_USER Usuário Varchar 50

No Quadro 19, apresenta-se a tabela de célula.

Quadro 19 – Tabela de célula

CELULA

Armazena as células de trabalho.


Chave estrangeira

CD_CELULA Código da célula Integer X

NM_CELULA Nome da célula Varchar 100

No Quadro 20, apresenta-se a tabela de Daily Meeting.

60

Quadro 20 – Tabela de Daily Meeting

DAILYMEETING Armazena as informações das reuniões diárias(Daily Meeting)


Chave estrangeira

CD_MEETING Código da reunião Integer X

DT_MEETING Data da reunião Date

DS_OBS Observações da reunião

Varchar 255

CD_CELULA Código da célula da reunião

Integer X

CD_SPRINT Código do sprint da reunião

Integer X

No Quadro 21, apresenta-se a tabela de ligação entre Daily Meeting e Impedimento.

Quadro 21 – Tabela de ligação entre Daily Meeting e Impedimento

DAILYMEETING_IMPEDIMENTO

Armazena o relacionamento entre as Daily Meetings e os Impedimentos.


Chave estrangeira

DAILYMEETING_CD_MEETING Código da reunião

Integer X

IMPEDIMENTO_CD_IMPEDIMENTO Código do impedimento

Integer X

No Quadro 22, apresenta-se a tabela de ligação entre Daily Meeting e status.

Quadro 22 – Tabela de ligação entre Daily Meeting e status

DAILYMEETING_STATUS

Armazena o relacionamento entre as Daily Meetings e os Status.


Chave estrangeira

DAILYMEETING_CD_MEETING Código da reunião

Integer X

STATUS_CD_STATUS Código do status

Integer X

61

No Quadro 23, apresenta-se a tabela de ExternalView.

Quadro 23 – Tabela de ExternalView

EXTERNAL_VIEW

Armazena os dados das views externas que podem ser configuradas para serem apresentadas pelo sistema.


Chave estrangeira

CD_VIEW Código da view

Integer X

DS_NOME Nome da view Varchar 255

TM_TIMERPRESENTATION Tempo de apresentação

Integer

DS_URL Url de acesso Varchar 255

No Quadro 24, apresenta-se a tabela de funcionário.

Quadro 24 – Tabela de funcionário

FUNCIONARIO

Armazena os dados dos funcionários.


Chave estrangeira

CD_FUNCIONARIO Código do funcionário

Integer X

CD_CARGO Código do cargo Integer

DS_EMAIL E-mail Varchar 100

DS_LOGIN Login Varchar 100

CD_NIVELACESSO Código de nível de acesso

Integer

NM_FUNCIONARIO Nome Varchar 100

DS_SENHA Senha Varchar 50


No Quadro 25, apresenta-se a tabela de impedimento.

62

Quadro 25 – Tabela de impedimento

IMPEDIMENTO

Armazena os dados dos impedimentos que são relatados nas Daily Meetings.


Chave estrangeira

CD_IMPEDIMENTO Código do impedimento

Integer X

DS_IMPEDIMENTO Descrição do impedimento

Varchar 255

NR_TAREFA Número da tarefa Integer


Integer X

CD_MEETING Código da reunião Integer X

No Quadro 26, apresenta-se a tabela de Kanban.

Quadro 26 – Tabela de Kanban

KANBAN

Armazena os dados dos quadros Kanban.


Chave estrangeira

CD_KANBAN Código do Kanban Integer X

NM_KANBAN Nome do Kanban Varchar 255


CD_VIEW Código da view Integer X

No Quadro 27, apresenta-se a tabela de ligação entre Kanban e célula.

63

Quadro 27 – Tabela de ligação entre Kanban e célula

KANBAN_CELULA

Armazena o relacionamento entre o Kanban e as Células.


Chave estrangeira

KANBAN_CD_KANBAN Código do Kanban

Integer X

CELS_CD_CELULA Código da célula Integer X

No Quadro 28, apresenta-se a tabela de ligação entre Kanban e raia.

Quadro 28 – Tabela de ligação entre Kanban e raia

KANBAN_RAIA

Armazena o relacionamento entre o Kanban e as Raias.


Chave estrangeira


Integer X

RAIAS_CD_RAIA Código da raia Integer X

No Quadro 29, apresenta-se a tabela de KanbanSprint.

Quadro 29 – Tabela de KanbanSprint

KANBANSPRINT

Armazena o quadro Kanban de determinado Sprint.


Chave estrangeira

CD_KANBANSPRINT Código do KanbanSprint

Integer X

DS_KANBAN Descrição do Kanban

Varchar 255

CD_KANBAN Código do Kanban base

Integer X

CD_SPRINT Código do Sprint Integer X

No Quadro 30, apresenta-se a tabela de ligação entre KanbanSprint e TaskKanban.

64

Quadro 30 – Tabela de ligação entre KanbanSprint e TaskKanban

KANBANSPRINT_TASKKANBAN

Armazena a relação entre o quadro Kanban de um Sprint e as tarefas/atividades que compõe o mesmo.


Chave estrangeira

KANBANSPRINT_CD_KANBANSPRINT Código do KanbanSprint

Integer X

TASKOUT_CD_TASK Código da tarefa de desvio

Integer X

TASKS_CD_TASK Código da tarefa

Integer X

No Quadro 31, apresenta-se a tabela de MyViewTask.

Quadro 31 – Tabela de MyViewTask

MYVIEWTASK

Armazena a configuração das views configuradas pelos usuários.


Chave estrangeira

CD_VIEW Código da View Integer X


Integer X

No Quadro 32, apresenta-se a tabela de raia.

Quadro 32 – Tabela de raia

RAIA

Armazena as raias dos quadros Kanban.


Chave estrangeira

CD_RAIA Código da raia Integer X

NM_RAIA Nome da raia Varchar 255

CD_POSITION Posição da raia Integer

DS_SELECTCONDICTION Select de busca da condição

Varchar 255

65

No Quadro 33, apresenta-se a tabela de SelectCriticalTask.

Quadro 33 – Tabela de SelectCriticalTask

SELECTCRITICALTASK

Armazena a query responsável por verificar se existem tarefas/atividades com urgência de tratamento.


Chave estrangeira

CD_SELECTCRITICALTASK Código do SelectCriticalTask

Integer X

DS_ASNRO Descrição do identificador de

número

Varchar 50

DS_ASCELL Descrição do identificador de

célula

Varchar 50

DS_ASCLIENT Descrição do identificador de

cliente

Varchar 50

DS_ASLOCATION Descrição do identificador de

localização

Varchar 50

DS_ASMATURITYTASK Descrição do identificador de

maturidade

Varchar 50

DS_ASNATURE Descrição do identificador de

natureza

Varchar 50

DS_ASPATH Descrição do identificador do

caminho

Varchar 50

DS_ASPRIORITY Descrição do identificador de

prioridade

Varchar 50

DS_ASPRODUCT Descrição do identificador de

produto

Varchar 50

DS_ASRELEASEVERSION Descrição do identificador de

versão de liberação

Varchar 50

66

DS_ASREQUEST Descrição do identificador de

solicitante

Varchar 50

DS_ASRESPONSIBLE Descrição do identificador de

responsável

Varchar 50

DS_ASSISORI Descrição do identificador de

sistema de origem

Varchar 50

DS_ASSTATUS Descrição do identificador de

status

Varchar 50

DS_ASTASKOPENIN Descrição do identificador de

abertura de tarefa

Varchar 50

DS_ASTASKORIVERSION Descrição do identificador de verão de origem

Varchar 50

DS_ASTITLE Descrição do identificador de

titulo

Varchar 50

DS_SELECT Select da busca no banco

Varchar 255

CD_BANCO Código do banco Integer X

No Quadro 34, apresenta-se a tabela de SelectView.

Quadro 34 – Tabela de SelectView

SELECTVIEW

Armazena as query das views.


Chave estrangeira

CD_SELECTCRITICALTASK Código do SelectCriticalTask

Integer X

DS_ASNRO Descrição do identificador de

número

Varchar 50

DS_ASCELL Descrição do identificador de

célula

Varchar 50

67

DS_ASCLIENT Descrição do identificador de

cliente

Varchar 50

DS_ASLOCATION Descrição do identificador de

localização

Varchar 50

DS_ASMATURITYTASK Descrição do identificador de

maturidade

Varchar 50

DS_ASNATURE Descrição do identificador de

natureza

Varchar 50

DS_ASPATH Descrição do identificador do

caminho

Varchar 50

DS_ASPRIORITY Descrição do identificador de

prioridade

Varchar 50

DS_ASPRODUCT Descrição do identificador de

produto

Varchar 50

DS_ASRELEASEVERSION Descrição do identificador de

versão de liberação

Varchar 50

DS_ASREQUEST Descrição do identificador de

solicitante

Varchar 50

DS_ASRESPONSIBLE Descrição do identificador de

responsável

Varchar 50

DS_ASSISORI Descrição do identificador de

sistema de origem

Varchar 50

DS_ASSTATUS Descrição do identificador de

status

Varchar 50

DS_ASTASKOPENIN Descrição do identificador de

abertura de tarefa

Varchar 50

DS_ASTASKORIVERSION Descrição do identificador de verão de origem

Varchar 50

68

DS_ASTITLE Descrição do identificador de

titulo

Varchar 50

DS_SELECT Select da busca no banco

Varchar 255

CD_VIEW Código da view Integer X

CD_BANCO Código do banco Integer X

No Quadro 35, apresenta-se a tabela de Sprint.

Quadro 35 – Tabela de Sprint

SPRINT

Armazena os dados dos Sprints.


Chave estrangeira

CD_SPRINT Código do Sprint

Integer X

CD_STATUS Código do status Integer

DT_SPRINT Data de início Date

DT_ENDSPRINT Data de fim Date



Integer X

No Quadro 36, apresenta-se a tabela de Status.

Quadro 36 – Tabela de Status

STATUS

Armazena os status dos membros das equipes nas Daily Meetings.


Chave estrangeira

CD_STATUS Código do status Integer X

DS_STATUS Descrição do status Varchar 255


Integer X

69

No Quadro 37, apresenta-se a tabela de TaskComment.

Quadro 37 – Tabela de TaskComment

TASKCOMMENT

Armazena os comentários das tarefas dos quadros Kanban.


Chave estrangeira

CD_COMMENT Código do comentário

Integer X

DS_COMMENT Descrição do comentário

Varchar 255

DT_COMMENT Data do comentário Date


Integer X

No Quadro 38, apresenta-se a tabela de TaskKanban.

Quadro 38 – Tabela de TaskKanban

TASKKANBAN

Armazena os comentários das tarefas dos quadros Kanban.


Chave estrangeira

DTYPE Tipo da TaskKanban

Varchar 31

CD_TASK Código da TaskKanban

Integer X

DS_MOTIVO Descrição do motivo

Varchar 255


Integer X


Integer X

No Quadro 39, apresenta-se a tabela de ligação entre TaskKanban e TaskComment.

70

Quadro 39 – Tabela de ligação entre TaskKanban e TaskComment

TASKKANBAN_TASKCOMMENT

Armazena a ligação entre as tarefas do quadro Kanban e os comentários.


Chave estrangeira

TASKKANBAN_CD_TASKKANBAN Código da TaskKanban

Integer X

COMMENTS_CD_COMMENTS Código do comentário

Integer X

No Quadro 40, apresenta-se a tabela de ViewTask.

Quadro 40 – Tabela de ViewTask

VIEWTASK

Armazena as informações das views que são configuradas pelo Administrador do sistema, e que ficam disponíveis para todos.


Chave estrangeira

CD_VIEW Código da view Integer

NM_VIEW Nome da view Varchar 50

CD_SELECTVIEW Código do Select da view

Integer

Documents

TASKBOARDDEV: FERRAMENTA PARA MONITORAMENTO E RASTREABILIDADE DE ATIVIDADES DE ...dsc.inf.furb.br/arquivos/tccs/monografias/2014_2_pedro... · 2015. 8. 25. · A fase de manutenção