Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
TASKBOARDDEV: FERRAMENTA PARA
MONITORAMENTO E RASTREABILIDADE DE
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
TASKBOARDDEV: FERRAMENTA PARA
MONITORAMENTO E RASTREABILIDADE DE
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
1. Realiza os passos de 1 a 2 do Fluxo principal;
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.
Ator Desenvolvedor, Usuário Externo (Stakeholder)
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.
Cenário – Visualização
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.
Cenário – Exclusão
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.
Cenário – Visualização
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.
Cenário – Edição
1. Realiza os passos de 1 a 2 do Fluxo principal;
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.
Cenário – Apresentação
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.
Cenário – Visualização
Sistema mostra todas as TasksViews cadastradas.
Cenário – Edição
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.
Cenário – Exclusão
1. Realiza os passos de 1 a 2 do Fluxo principal;
2. Admin seleciona um item para exclusão; 3. Admin clica em Excluir;
4. Sistema excluí o item selecionado e mostra os restantes.
Cenário – Apresentação
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.
Ator Desenvolvedor, Usuário Externo (Stakeholder)
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.
Campo Descrição Tipo Tamanho Chave primária
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)
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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
CD_CELULA Código da célula Integer X
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.
Campo Descrição Tipo Tamanho Chave primária
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
CD_FUNCIONARIO Código do funcionário
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.
Campo Descrição Tipo Tamanho Chave primária
Chave estrangeira
CD_KANBAN Código do Kanban Integer X
NM_KANBAN Nome do Kanban Varchar 255
CD_CELULA Código da célula Integer X
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
Chave estrangeira
KANBAN_CD_KANBAN Código do Kanban
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
Chave estrangeira
CD_VIEW Código da View Integer X
CD_FUNCIONARIO Código do funcionário
Integer X
No Quadro 32, apresenta-se a tabela de raia.
Quadro 32 – Tabela de raia
RAIA
Armazena as raias dos quadros Kanban.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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
CD_CELULA Código da célula Integer X
KANBAN_CD_KANBAN Código do Kanban
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.
Campo Descrição Tipo Tamanho Chave primária
Chave estrangeira
CD_STATUS Código do status Integer X
DS_STATUS Descrição do status Varchar 255
CD_FUNCIONARIO Código do funcionário
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.
Campo Descrição Tipo Tamanho Chave primária
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
CD_FUNCIONARIO Código do funcionário
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.
Campo Descrição Tipo Tamanho Chave primária
Chave estrangeira
DTYPE Tipo da TaskKanban
Varchar 31
CD_TASK Código da TaskKanban
Integer X
DS_MOTIVO Descrição do motivo
Varchar 255
KANBAN_CD_KANBAN Código do Kanban
Integer X
CD_FUNCIONARIO Código do funcionário
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.
Campo Descrição Tipo Tamanho Chave primária
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.
Campo Descrição Tipo Tamanho Chave primária
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