Trabalho de Conclusão de Curso (TCC) apresentado ao Curso de Engenharia de Software do Centro Universitário da Grande Dourados (UNIGRAN) como pré-requisito para obtenção do título de Bacharel em Engenharia de Software.

1. CENTRO UNIVERSITÁRIO DA GRANDE DOURADOS
ÂNDERSON KANEGAE SOARES ROCHA
SOFTWARE PARA GERENCIAMENTO DE PROJETOS
BASEADO EM METODOLOGIAS ÁGEIS
Trabalho de Conclusão de Curso
apresentado ao Curso de Engenharia de
Software como pré-requisito para
obtenção do título de Bacharel em
Engenharia de Software.
Orientador: Prof. Msc. Antonio Pires de
Almeida Junior.
Dourados/MS
2021

2. Sumário
Contextualização
2
.......................................................................................
Glossário
3
...................................................................................................
Coleta de Requisitos
4
.................................................................................
Product Owner (PO)
4
..............................................................................
Scrum Master (SM)
4
...............................................................................
Membro do Time (MT)
4
...........................................................................
Usuário Genérico (UG)
4
..........................................................................
Definição de Requisitos
4
............................................................................
Requisitos Funcionais
5
...........................................................................
Requisitos Não Funcionais
5
....................................................................
Especificação de Requisitos
6
.....................................................................
Casos de Uso
6
........................................................................................
Descrição dos Casos de Uso
6
................................................................
Diagrama de Classes
7
............................................................................
Protótipo de Interfaces
9
..............................................................................
Tela Inicial
9
..............................................................................................
Tela de Cadastro de Usuário
9
.................................................................
Tela de Acesso
10
....................................................................................
Telas de Cadastro de Projeto
11
..............................................................
Telas de Cadastro de Tarefa
12
................................................................
Telas de Cadastro de Sprint
13
................................................................
Telas de Tarefas da Sprint
15
...................................................................
Referências Bibliográficas
17
.......................................................................

3. Contextualização
Desde a antiguidade, o ser humano vêm desenvolvendo as suas habilidades de criação e,
com o passar do tempo, têm realizado criações cada vez mais complexas que vão desde
ferramentas primitivas até grandes máquinas e construções.
Nesse contexto, cada vez mais, se faz necessário realizar algum planejamento para se
alcançar os objetivos de forma efetiva. Essa necessidade vai de encontro ao conceito de
projeto. Segundo a definição mais ampla do dicionário Michaelis (PROJETO, 2020),
projeto pode ser entendido como o “propósito de executar algo”. Ainda nesse sentido, o
PMBOK (PMI, 2017) define projeto, de forma mais específica, como “um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo”.
Com o intuito de reduzir os riscos envolvidos nos projetos, existem diversas metodologias.
O PMBOK é uma das mais completas referências que reúne as melhores práticas para a
gerência de projetos e, portanto, orienta a “aplicação de conhecimentos, habilidades,
ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos” (PMI,
2017). No entanto, a complexidade geralmente presente nessas metodologias representa
uma barreira de entrada, principalmente, para projetos de menor porte.
Insatisfeitos com os métodos tradicionais para gerência de projetos, que não atendiam
totalmente as particularidades de projetos de software, um grupo de desenvolvedores de
software criou o Manifesto Ágil (BECK et al, 2001) com princípios que revolucionaram a
gerência de projetos. Alinhadas aos princípios do Manifesto Ágil, as metodologias ágeis
surgiram com o intuito de melhorar esse cenário e acabaram sendo amplamente adotadas
não somente em projetos de software mas em projetos em geral. O Scrum é uma dessas
metodologias que mais tem se destacado devido a sua simplicidade (SCHWABER e
SUTHERLAND, 2017).
Sendo assim, entende-se que o desenvolvimento de um software para gerência de projetos
baseado em metodologias ágeis pode auxiliar na redução da complexidade envolvida nas
atividades de gerência de projeto e, consequentemente, reduzir a barreira de entrada citada
anteriormente. Ao fornecer uma estrutura básica inicial baseada nas metodologias ágeis,
pode-se presumir que os interessados enfrentarão menos dificuldades para implementar a
gerência de seus projetos e, consequentemente, conquistarão mais êxito nos mesmos.
2

4. Glossário
MT
Membro do Time
PO
Product Owner
SM
Scrum Master
UG
Usuário Genérico
3

5. Coleta de Requisitos
Para a realização da coleta inicial de informações e do levantamento dos principais
requisitos relevantes para o desenvolvimento e a implementação do software, foi realizado
um levantamento das principais atividades desempenhadas pelos potenciais tipos de
usuário do software, tendo como base a metodologia ágil Scrum (Product Owner, Scrum
Master, Membro do Time e Usuário Genérico para agrupar atividades genéricas). Essas
atividades foram transformadas em histórias de usuário e serão apresentadas a seguir:
Product Owner (PO)
1. Como Product Owner desejo registrar Histórias de Usuário para futuramente incluí-
las em uma Sprint.
2. Como Product Owner desejo priorizar Histórias de Usuário para futuramente
identificar as Histórias de Usuário de maior prioridade.
Scrum Master (SM)
1. Como Scrum Master desejo registrar Sprints para futuramente incluir Histórias de
Usuário nelas.
2. Como Scrum Master desejo adicionar Histórias de Usuário a uma Sprint para
disponibilizá-las para o desenvolvimento pelo Time.
Membro do Time (MT)
1. Como Membro do Time desejo alterar o status de Histórias de Usuário para
registrar o status de desenvolvimento das mesmas.
Usuário Genérico (UG)
1. Como Usuário Genérico desejo me cadastrar para me tornar um usuário do
software.
2. Como Usuário Genérico desejo me autenticar no software para utilizá-lo de forma
segura.
3. Como Usuário Genérico desejo visualizar o Kanban de uma Sprint.
4. Como Usuário Genérico desejo visualizar o Burndown Chart de uma Sprint.
Definição de Requisitos
A partir do levantamento realizado, optou-se por realizar algumas simplificações em
relação ao processo e a utilização de termos técnicos para melhorar o entendimento dos
usuários em geral e, consequentemente, contribuir com o objetivo deste projeto de reduzir
as barreiras de entrada para a adoção da gerência de projeto:
4

6. • Todos os potenciais tipos de usuário foram adaptados para um único tipo,
denominado como Usuário;
• História de Usuário foi adaptado para Tarefa, que por sua vez, pertence a um
Projeto;
• Kanban foi adaptado para Tarefas da Sprint;
• Burndown Chart foi adaptado para Estatísticas, que serão exibidas juntamente as
Tarefas da Sprint.
Sendo assim, foi possível elencar os seguintes requisitos:
Requisitos Funcionais
• Gerenciamento de Projetos
• Gerenciamento de Tarefas (PO-1, PO-2, MT-1)
• Gerenciamento de Sprints (SM-1, SM-2)
• Gerenciamento de Usuários (Cadastre-se) (UG-1)
• Realizar Login (Entrar) (UG-2)
• Realizar Logout (Sair) (UG-2)
• Visualizar/Executar Tarefas da Sprint (UG-3, UG-4)
Requisitos Não Funcionais
• O software deve implementar um controle de permissões, impedindo o acesso não
autorizado.
• O software deve ser disponibilizado para uso via Web e possuir alta
disponibilidade.
5

7. Especificação de Requisitos
A presente seção apresentará os requisitos e os diagramas de implementação do software.
Casos de Uso
Foram descobertos sete casos de uso: Realizar Cadastro de Usuário, Realizar Login,
Realizar Logout, Cadastrar Projetos, Cadastrar Tarefas, Cadastrar Sprints, Visualizar/
Executar Tarefas da Sprint. O diagrama final é apresentado na Figura 1.
Figura 1 – Diagrama de casos de uso para o software.
Descrição dos Casos de Uso
Caso de Uso: Realizar Cadastro de Usuário
Ator: Usuário
Descrição: Para se tornar um Usuário do software, o indivíduo interessado deve se
cadastrar no mesmo informando seus dados (nome, e-mail e senha).
Caso de Uso: Realizar Login
Ator: Usuário
Descrição: Para fazer uso das funcionalidades do software, o usuário deve se autenticar
no mesmo informando seu e-mail e senha cadastrados e o software deverá validar esses
dados para permitir ou não o acesso.
6

8. Diagrama de Classes
O diagrama presente na Figura 2, visa apresentar as classes do software a ser desenvolvido
e as suas associações.
Caso de Uso: Realizar Logout
Ator: Usuário
Descrição: Para sair do software com segurança, o usuário deverá solicitar ao software
que realize o logout e após isso deverá realizar login novamente caso deseje acessar
novamente o software.
Caso de Uso: Cadastrar Projetos
Ator: Usuário
Descrição: Para cadastrar um projeto para agrupar tarefas, o usuário deve cadastrá-lo
informando seu título e descrição.
Caso de Uso: Cadastrar Tarefas
Ator: Usuário
Descrição: Para cadastrar uma tarefa, o usuário deve cadastrá-la informando seu título,
descrição, status, prioridade, projeto e Sprint.
Caso de Uso: Cadastrar Sprints
Ator: Usuário
Descrição: Para cadastrar uma Sprint, o usuário deve cadastrá-la informando seu
objetivo, descrição, data inicial e data final.
Caso de Uso: Visualizar/Executar Tarefas da Sprint
Ator: Usuário
Descrição: Para visualizar/executar as tarefas de uma Sprint, o usuário deverá solicitar ao
sistema a partir de uma Sprint cadastrada. O software então, deverá apresentar as tarefas
associadas a essa Sprint e uma seção com estatísticas sobre a mesma. Cada tarefa, poderá
ser excluída ou ter seus dados editados seguindo a mesma lógica do caso de uso
Cadastrar Tarefas.
7

9. Figura 2 – Diagrama de classes para o software.
• Foi criada uma classe Usuário para realização do controle de acesso e identificação
do usuário no software.
• Foi criada uma classe Papel para futuras implementações de diferentes papéis para
os usuários no software.
• Foi criada uma classe Projeto para agrupar Tarefas. Além disso, cada Projeto
pertence a um Usuário.
• Foi criada uma classe Tarefa para armazenar informações individuais de cada
Tarefa. Além disso, cada Tarefa pertence a um Projeto e pode pertencer a uma
Sprint.
• Foi criado um elemento com estereótipo “enum”, denominado Prioridade, para
auxiliar e padronizar a priorização de Tarefas.
• Foi criado um elemento com estereótipo “enum”, denominado Status, para auxiliar
e padronizar a identificação do status de Tarefas.
• Foi criada uma classe Sprint para agrupar Tarefas selecionadas pelo Usuário do
software para execução durante um período. Além disso, cada Sprint pertence a um
Usuário.
• Os métodos foram ocultos para destacar os atributos e os relacionamentos entre as
entidades. No entanto, em geral, tais métodos são referentes as operações de
manutenção e seleção das entidades no software.
8

10. Protótipo de Interfaces
A presente seção apresentará os protótipos das telas do software.
Tela Inicial
A Figura 3 apresenta o protótipo da tela inicial do software, onde os potenciais usuários
podem se cadastrar ou acessar o software com seus dados já cadastrados.
Figura 3 – Protótipo da tela inicial do software.
Tela de Cadastro de Usuário
A Figura 4 apresenta o protótipo da tela do caso de uso “Cadastrar Usuário”, que serve
para fazer o cadastro de Usuário no software.
9

11. Figura 4 – Protótipo da tela “Cadastro de Usuário”.
Tela de Acesso
A Figura 5 apresenta o protótipo da tela do caso de uso “Realizar Login”, que serve para
fazer acesso ao software.
Figura 5 – Protótipo da tela “Acesso ao Software”.
10

12. Telas de Cadastro de Projeto
As Figuras 6 e 7 apresentam os protótipos das telas do caso de uso “Cadastrar Projeto”,
que servem para listar e possibilitar o gerenciamento dos Projetos.
Figura 6 – Protótipo da tela “Cadastro de Projeto (Listagem)”.
Figura 7 – Protótipo da tela “Cadastro de Projeto (Formulário)”.
11

13. Telas de Cadastro de Tarefa
As Figuras 8 e 9 apresentam os protótipos das telas do caso de uso “Cadastrar Tarefa”, que
servem para listar e possibilitar o gerenciamento das Tarefas.
Figura 8 – Protótipo da tela “Cadastro de Tarefa (Listagem)”.
12

14. Figura 9 – Protótipo da tela “Cadastro de Tarefa (Formulário)”.
Telas de Cadastro de Sprint
As Figuras 10 e 11 apresentam os protótipo das telas do caso de uso “Cadastrar Sprint”,
que servem para listar e possibilitar o gerenciamento de Sprints.
13

15. Figura 10 – Protótipo da tela “Cadastro de Sprint (Listagem)”.
Figura 11 – Protótipo da tela “Cadastro de Sprint (Formulário)”.
14

16. Telas de Tarefas da Sprint
As Figuras 12 e 13 apresentam os protótipos das telas do caso de uso “Visualizar/Executar
Tarefas da Sprint”, que servem para listar e gerenciar as Tarefas de uma Sprint, bem como
apresentar as estatísticas sobre a mesma.
Figura 12 – Protótipo da tela “Tarefas da Sprint (Listagem)”.
15

17. Figura 13 – Protótipo da tela “Tarefas da Sprint (Formulário)”.
16

18. Referências Bibliográficas
PROJETO. In: Dicionário Michaelis On-line. 2020. Disponível em: <https://
michaelis.uol.com.br/moderno-portugues/busca/portugues-brasileiro/projeto/>. Acesso em
30 set. 2020.
PMI. Project Management Body of Knowledge (PMBOK). 6 ed. Filadélfia: PMI, 2017.
BECK, K. et al. Manifesto para Desenvolvimento Ágil de Software. 2001. Disponível em:
<https://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em 30 set. 2020.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum. 2017. Disponível em: <https://
www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-
Brazilian.pdf>. Acesso em 30 set. 2020.
17