Modelação SCRUM sistema informação acadêmico

SCRUM
Modelação de Sistemas Informáticos
Autores
Rafael Baltazar 20171051
William Fonte 20191579
Guilherme Pires 20221834
Professor
Luís Barata
Dezembro de 2022
I
Resumo
O presente documento trata a modelação de um sistema de informação

académico do Ensino Superior, que tem como base o framework SCRUM. O SCRUM
tem como principal objetivo realizar um sistema de informação para a concretização
de ações para a formação, a fim de permitir a gestão e controlo das suas atividades
letivas. O Scrum é um framework utilizado na gestão de projetos, na organização de
desenvolvimento ágil de produtos complexos e adaptados ao valor mais alto possível,
através de várias técnicas. De acordo com a Wikipédia este framework é utilizado
desde o início de 1990 e, presentemente, é utilizado em mais de 60% dos projetos
ágeis em todo o mundo. Prestar toda a documentação de um projeto é fundamental
para o desenvolvimento do mesmo e, deste modo, iremos expor neste documento
todos os artefactos do Scrum, assim como, a aplicação da metodologia para um
sistema de informação académico do ensino superior, com o objetivo de concretizar
as ações de formação por parte do tutor e tutorando, na qual se possa gerir e
controlar as atividades letivas. Este trabalho foi realizado em grupo e apresentou-nos
um grande desafio, no qual foi possível adquirir novos conhecimentos sobre a
modelação e a modelação com base no processo do Scrum, sendo o seu resultado
extremamente positivo.
Palavra-chave
Scrum, Sprint Planning, Sprint Review, Sprint Backloge, Sprint Execution, Sprint
Retrospective ,Product Backlog, Daily Scrum, User Story, Burndown Chart
II
Índice
1.Introdução ........................................................................................................................................V
2. O que é o SCRUM? ........................................................................................................................V
3. Sprint ............................................................................................................................................. VII
4. Modelação SCRUM “ESC Tutoriais” ............................................................................... 1
5. Product Backlog / Sprint Backlog ................................................................................. 2
5.1 Sprint 1 ............................................................................................................................... 3
5.2 Sprint 2 ............................................................................................................................ 14
5.3 Sprint 3 ............................................................................................................................ 18
5.4 Sprint 4 ............................................................................................................................ 22
5.5 Sprint 5 ............................................................................................................................ 27
5.6 Sprint 6 ............................................................................................................................ 32
5.7 Sprint 7 ............................................................................................................................ 36
5.8 Sprint 8 ............................................................................................................................ 40
5.9 Sprint 9 ............................................................................................................................ 43
................................................................................................................................................................. 46
6. Conclusão ................................................................................................................................ 47
7. Referências Bibliográficas ............................................................................................. 47
III
Índice de Figuras
Figura 1 - Reunião Diária .............................................................................................................. VII

Figura 2- Etapas Sprint ................................................................................................................ VIII
Figura 3- Gráfico Burndown Chart..............................................................................................XI
Figura 4- Caso de Uso ........................................................................................................................ 1
Figura 5 - Product Backlog/Sprint Backlog ............................................................................. 2
Lista de abreviaturas, siglas e acrónimos
ESC – Escalos de Cima

UML – Unified Modeling Language
GUI – Graphical User Interface
ESC Tutoriais- Escalos de Cima Tutoriais
IV
1.Introdução
O presente trabalho apresenta a modelação de um sistema de informação

académico do Ensino Superior, nomeadamente o framework SCRUM. Este tem como
principal objetivo a realização de um sistema de informação para a concretização de
ações para a formação, que permitam a gestão e o controlo das suas atividades letivas.
O Scrum é utilizado sobretudo em equipas de desenvolvimento de software.
Contudo, os seus princípios e as suas lições podem ser aplicados a todos os tipos de
trabalhos em equipa, o que faz com que o Scrum seja uma das estruturas ágeis para
gerir projetos que sejam os mais importantes do mundo. Este trabalho encontra-se
organizado em dois capítulos nos quais se irá tratar a aplicação da metodologia para
um sistema de informação académico do ensino superior.
Primeiramente, iremos fazer uma breve abordagem a nível teórico sobre o
SCRUM, referindo os seus conceitos associados. Seguidamente, o capítulo 2 vai
apresentar uma demonstração de 9 sprints, nos quais, um deles será ao detalhe e os
restantes terão o estado inicial e final do Sprint Backloge do Product Backlog.
Durante os sprints iram decorrer varias situações positivas e negativas para a
equipa que ira criar momentos de tensão e consequentemente falhas nas entregas dos
sprint´s ( 3 sprints ) e os restantes sprints iram ocorrer situações de entregas na
deadline e outras situações que correu tudo bem.
2. O que é o SCRUM?
O Scrum é uma metodologia ágil para gestão e planeamento de projetos de Software,
por outras palavras, é um Framework de gestão dinâmica de projetos que é
habitualmente aplicada no desenvolvimento ágil de software.
Assim o Scrum é um Framework simples que se destina a resolver o problema de
longos ciclos de desenvolvimento de projetos e a incompatibilidade entre os
requisitos do cliente e o produto final.
Os projetos são divididos em ciclos chamados Sprints, as funcionalidades que vão ser
implementadas em cada projeto são guardadas no Product Backlog,
No Scrum são definidas as responsabilidades dos Developers, que são a junção de
todos os profissionais da equipa de programação multidisciplinar e que são
responsáveis pela conceção, construção e testes do produto.
A responsabilidade de um projeto do Scrum é dividida em três papéis que compõem
uma equipa de Scrum:
V
➢ Product Owner
▪ É normalmente o acionista/cliente do projeto e/ou representante de
uma companhia ou empresa.
▪ Tem como principal responsabilidade fornecer à equipa de Scrum os
requisitos, objetivos e metas que ele mesmo pretende.
▪ Entre as suas responsabilidades, está a definição do esboço do produto
que será criado, e definir a priorização do que deve ser feito primeiro.
▪ Outra função é maximizar o valor do produto que está sendo elaborado
pela equipa de desenvolvimento, para que atinja o maior grau de
satisfação com as entregas de cada funcionalidade para seus clientes ou
usuários.
➢ Scrum Master
▪ É o elemento da equipa responsável pela gestão do projeto e
liderar as Scrum Meetings.
▪ Na prática, é a pessoa que assume um papel misto de líder e de
gestor/ mentor da equipa. Ele precisa apresentar características de
liderança, para garantir que a equipa está no caminho certo, ou seja,
está seguindo os sprints de acordo com a sua capacidade e as
prioridades do projeto.
▪ Também organizar as reuniões, monitoriza o trabalho a ser feito e
facilita o planeamento do lançamento.
➢ Development Team
▪ O Development Team, ou Equipa de Desenvolvimento, são os responsáveis por

executar as ações definidas para os Sprints Backlog. Uma de suas principais
características é a multidisciplinaridade e autónomos.
▪ São responsáveis por transformar o Product Backlog em um produto
funcional. São eles que desenvolvem as versões incrementais do produto
“Pronto” que são entregues ao final de cada Sprint
▪ Assim os Development Team são a equipa responsável pela implementação e
entrega do produto. Esta normalmente é composta por 5 a 10 elementos, entre
eles analistas, programadores, gestores, etc.
VI
3. Sprint
Figura 1 - Reunião Diária
Durante a realização de um Sprint, por cada dia que esse Sprint durar, a equipa
convoca reuniões e falam entre si para tomarem conhecimento sobre o que foi feito
no dia anterior e o que se comprometem a realizar no dia apos a reunião.
Quando um Sprint acaba, a equipa convoca nova reunião e reúne-se novamente no

sentido de apresentar as funcionalidades implementadas, verificar a qualidade das
funcionalidades e se estas estão corretamente feitas.
Estas reuniões também servem para ouvir todos os membros da equipa e tomar
notas de todos os problemas que possam ser resolvidos futuramente e receber
propostas de implementações futuras que possam contribuir para melhoria de
projetos futuros.
VII
Figura 2- Etapas Sprint
➢ Product Backlog
▪ O Product Backlog é uma lista ordenada de tudo o que é necessário para

chegar ao produto final de um projeto de desenvolvimento de software.
Em outras palavras, são as “coisas” que devem ser desenvolvidas para chegar
àquilo que foi acordado entre todos os envolvidos no projeto.
▪ Esta lista contém todas as funcionalidades essenciais para o produto, lista essa
que é criada pelo Product Owner.
▪ A lista é alvo de uma constante atualização, atualização essa que acompanha o
desenvolvimento do produto.
▪ Cada requisito e cada mudança no projeto serão refletidos no Product Backlog,
que está sempre mudando e melhorando dinamicamente.
▪ As funcionalidades são ordenadas tendo em conta a prioridade das mesmas,
sendo que as mais relevantes ficam no topo da lista por serem as mais
importantes.
➢ Sprint Planning
▪ Sprint Planning é uma prática desenvolvida para ser aplicada como uma
reunião de definição de rota antes de cada período de trabalho.
▪ Nesses encontros que antecedem os ciclos, são definidas questões importantes
em relação às próximas semanas de trabalho. Estrategicamente, o Sprint
Planning tem grande peso na agilidade dos projetos.
▪ O trabalho a ser desenvolvido em cada Sprint é projetado no Sprint Planning
normalmente, no Sprint Planning estão presentes o Product Owner, o Scrum
VIII
Master e todo o Scrum Team, bem como qualquer pessoa interessada que
esteja representando a gerência ou o cliente.
▪ Durante o Sprint Planning, o Product Owner descreve as funcionalidades de
maior prioridade para a equipa. A equipa faz perguntas durante a reunião de
modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a
reunião. Essas tarefas irão dar origem ao Sprint Backlog.
➢ Sprint Backlog
▪ O Sprint Backlog consiste no trabalho a ser desenvolvido num Sprint de modo

a criar um produto a apresentar ao utilizador.
▪ O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a
fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product
Backlog, pela equipe, com base nas prioridades definidas pelo Product
Owner e a perceção da equipa sobre o tempo que será necessário para
completar as várias funcionalidades.
▪ A equipa Scrum deve adicionar detalhes e estimativas, e encomendar os itens
de Backlog do Produto durante todo o projeto. Essa rotina é chamada de
“preparação do Backlog”, e isso não deve consumir mais do que 10% do tempo
dos envolvidos no projeto.
▪ Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizado para
refletir que tarefas foram completadas e quanto tempo a equipa acredita que
será necessário para completar aquelas que ainda não estão prontas.
➢ Sprint Execution
▪ Durante a execução do Sprint cada Sprint pode ter períodos temporais

diferentes entre si, sendo que nem todos os Sprints levam o mesmo tempo a
serem concluídos e que no final de cada Sprint origina-se um novo aumento
das funcionalidades.
▪ Nesta execução do Sprint o Sprint divide se por diferentes etapas de
desenvolvimento, como convocar reuniões para debater problemas, revisões
dos sprints, rever o planeamento e gerir os sprints
➢ Daily Scrum
▪ A Daily Scrum é uma reunião que é feita diariamente pela equipa de
desenvolvimento e o Scrum Master, que tem como objetivo determinar o
que se pretende realizar nas próximas 24 horas.
▪ É feita então uma reunião diária feita pelos membros da equipa de
tecnologia responsável pelo projeto em andamento.
IX
▪ Esta reunião deve ser feita, preferencialmente, na parte da manhã, para
poder dar a todos os profissionais da equipe um panorama real e
atualizado sobre o avanço de cada uma das áreas deste projeto.
▪ Essa reunião só pode ter no máximo uma duração de 15 minutos e deve ser
realizada no mesmo local e á mesma hora, sendo que é necessário a
presença regular de cada elemento para promover um maior foco no
progresso e evitar falhas no processo.
▪ Serve para fornecer à equipe envolvida maior previsibilidade, controle de
riscos e um conhecimento geral sobre o que foi feito no dia anterior, o que
será feito com prioridade no dia em que a daily ocorre e quais são os
possíveis impedimentos que estão atravancando o progresso de alguma
atividade.
➢ Sprint Review
▪ A Sprint Review, também conhecida como a “Sprint Demo”, é uma reunião

que ocorre no final da Sprint, em que a equipa de desenvolvimento mostra
o seu "produto potencialmente utilizável".
▪ É o penúltimo evento da Sprint, e geralmente acontece no seu último dia e
tem por objetivo a inspeção do Incremento do Produto desenvolvido
naquela Sprint e adaptação do Product Backlog caso necessário.
▪ No final de cada Sprint vai ser realizada uma reunião onde um dos
objetivos é inspecionar o incremento do Produckt Backlog e adaptá-lo se
necessário.
▪ Trata-se de uma reunião de caracter informal destinando-se a obter os
vários feedbacks por parte de todos os elementos.
➢ Sprint Retrospective
▪ A Sprint Retrospective é uma retrospetiva que é realizada no final de cada

Sprint e tem como objetivo:
• Identificar no último Sprint o que foi completo e o que foi prolongado/adiado
para outros Sprints.
• Verificar o que correu de melhor no desenvolvimento do Sprint e em casos de
erro ou obstáculos identificar possíveis melhorias.
X
➢ Burndown Chart
▪ Também conhecido como gráfico de burndown, em resumo, o burndown

chart é um indicador que ajuda a medir o progresso da sprint, demonstrando
como está o progresso da equipa e a velocidade das entregas.
▪ Ou seja, após cada dia de trabalho o gráfico apresenta a porção de trabalho
finalizada em comparação com o trabalho total planeado.
▪ O burndown é um dos gráficos mais simples utilizados no Scrum e oferece uma
visão importante para as decisões estratégicas da equipa. Por isso, é o mais
utilizado pelas empresas que adotaram essa metodologia.
Figura 3- Gráfico Burndown Chart
XI
ICONIX
4. Modelação SCRUM “ESC Tutoriais”
Para este projeto “ESC Tutoriais” foi considerada uma equipa de 5 elementos:
A equipa é composta pelo António, Bruno, Joana, Eduardo e Raquel, durante o
projeto iram ser mencionados pelas suas abreviaturas:
1. António- A
2. Bruno-B
3. Eduardo – E
4. Joana –J
5. Raquel -L
No decorrer do projeto ire mos apresentar a demostração dos sprints e detalhar
ao dia 25% de todos os sprints que iram ser realizados, para isso vamos simular o dia
a dia desses sprints como se fosse na vida real de uma empresa que adotou o Scrum
para realizar este projeto.
Figura 4- Caso de Uso
1
ICONIX
5. Product Backlog / Sprint Backlog
Figura 5 - Product Backlog/Sprint Backlog
2
ICONIX
5.1 Sprint 1
1ºDia – Daily Scrum

➢ Atualização da Tabela
Revisão do que foi feito nas últimas 24h
• Visto ser o primeiro dia de Daily Scrum do sprint não houve qualquer tipo de
trabalho realizado no dia anterior
O que se pretende para o dia de hoje

1. Convocar uma reunião com os seguintes temas a debater com a equipa:
2. Discussão do Story Board que iria ser implementado na etapa de
autenticação da página.
3. Verificação do design.
3
ICONIX
Progresso do decorrer do dia
▪ Durante o dia o elemento B começa o seu trabalho na tentativa de implementação

do design da página que irá servir de Login
▪ A restante equipa concentra se no desenvolvimento das interfases das
funcionalidades e nos storyboards.
Anotação dos obstáculos que foram surgindo no decorrer do dia
➢ Como este foi o primeiro dia e o dia foi maioritariamente dedicado a

reuniões a equipa não teve dificuldades nem foram encontrados obstáculos
que coloquem em causa a continuidade do projeto.
• O dia de ontem foi dedicado às reuniões onde foi concretizado metade do

planeamento gráfico posposto para este sprint.
• O elemento B da equipa já começou a implementar algumas interfases da
tarefa de implementação do login da página
• De notar que a equipa esteve varias vezes com ele no auxilio de qualquer coisa
que ele precisasse de ajuda e foi também encorajado pelo progresso que já
tinha feito,
4
ICONIX
6. Que o elemento B acabe a sua parte e passe o seu trabalho para que o
elemento A possa trabalhar nele e continuar na implementação
7. Continuação das interfases e storyboards.
• O elemento B apos algum tempo conseguiu acabar a sua parte e enviou o que tinha
feito ao elemento A para que pudesse continuar o trabalho
• O elemento B apos estar livre, juntou se á restante equipa para poder os ajudar visto
terem perdido o elemento A.
• No final do dia houve atrasos, mas foram acabado os storyBoards e as interfases que
começaram no dia 1.
➢ Surgiram alguns obstáculos principalmente com a troca de elementos, visto

o elemento B ter demorado um pouco mais a compreender o que já se tinha
feito e o que precisava de fazer.
➢ O elemento J teve problemas de concentração devido a problemas pessoais
e esteve durante o dia um pouco desmotivado.
o Em suma não foi posta em causa a finalização do trabalho.
▪ As tarefas atribuídas ontem foram todas concluídas com sucesso apesar de

ter sido concluído um pouco fora do prazo previsto
▪ A equipa foi para casa contente e pronta para o começo de novas tarefas
▪ Para hoje está previsto que as interações com as bases de dados comecem a
ser trabalhadas pelos elementos B e A.
▪ A segunda equipa vai se virar para a tarefa de processamento da página de
login.
5
ICONIX
▪ Os elementos A e B sentam se e começam a discutir a estrutura que a base de

dados deve ter, após chegarem a acordo do que cada um vai fazer, começam a
trabalhar com as interações da base de dados
▪ A restante equipa seguiu -o guião que lhes foi proposto para o processamento da
página login
o Sem qualquer problema a anotar
▪ Nas últimas 24h a equipa teve em mãos várias tarefas que foram
progressivamente trabalhadas sem qualquer atrasos nem limitações.
▪ A equipa composta pelos 3 elementos concluiu o processamento da página
login.
▪ A equipa que estava encarregue de realizar as interações com a base de
dados conseguiu fazer o esboço do que pretendem implementar
▪ Acabar as tarefas relacionadas com a base de dados

▪ Começar com a implementação da página do coordenador
▪ A quipá decidiu que era melhor que mais um elemento da equipa reforça se os
elementos A e B para que em conjunto possam acelerar as tarefas de interações da
base de dados.
▪ O elemento E pediu para ser ele a integrar a equipa.
▪ Os elementos J e R começam a progredir na implementação da página do
coordenador
6
ICONIX
o Sem qualquer problema a anotar apesar de que a implementação da

pagina do coordenador ter sofrido ligeiros atrasos devido á falta de
elementos da equipa.
▪ A equipa conseguiu finalizar as interações com a base de dados e já

entregaram a tarefa feita.
▪ A equipa “feminina” já avançou na implementação da página do
coordenador.
▪ Progredir na implementação da página do coordenador.

▪ Começar com a implementação da página dos docentes.
O elemento E retorna ao grupo dos elementos J e R para poderem acelerar a

implementação da página do coordenador para que não sofra atrasos excessivos.
Os elementos A e B viram se então para a construção da página dos docentes.
o Sem qualquer obstáculo que possam atrasar o sprint
▪ Desde a última reunião, a equipa conseguiu finalizar a implementação da

página do coordenador.
7
ICONIX
▪ Sendo que a implementação da página dos docentes ainda está em

progresso.
▪ Conclusão da implementação da página dos docentes.

▪ Começar com a implementação da página do aluno.
▪ Com a subtarefa concluída no último dia, o elemento A ajudará os elementos A e B,

com a conclusão da implementação da página dos docentes.
▪ Já os elementos J e R começam a trabalhar na modelação da página dos alunos.
o Sem qualquer obstáculo que possam atrasar o sprint
▪ No último dia, a equipa conseguiu completar a subtarefa correspondente à

implementação da página dos docentes.
▪ Enquanto a implementação da página dos alunos não foi totalmente
acabada mas esta com um bom progresso para ser finalizada hoje.
▪ Conclusão da implementação da página dos alunos
▪ Após o 7ºdia a equipa decidiu dar o dia de folga aos elementos A e B porque
acharam que eles já mereciam descansar um pouco dado ao trabalho exaustivo
que tiveram com as interfases das bases de dados.
▪ O elemento E junta se á equipa J e R para que em conjunto possam concluir a
página dos alunos.
8
ICONIX
o Pequenos atrasos devido á limitação da equipa por esta estar

reduzida.
▪ Desde o último Daily Scrum, a equipa terminou de implementar a página

dos alunos.
▪ A implementação do processo de recuperação da palavra-passe por parte

do sistema
▪ Com o retorno dos elementos A e B estes juntam se á equipa e em conjunto

começam pela primeira vez a trabalhar todos na mesma tarefa durante o dia
▪ Os elementos da equipa não previram nenhuns obstáculos que se possam

antecipar.
▪ No último dia, a equipa conseguiu adiantar quase finalizando a tarefa

pretendida
▪ Acabar com a tarefa da implementação de recuperação da palavra-passe
9
ICONIX
▪ Começar com o algoritmo de hiperligação com a página principal.
▪ A equipa decide deixar apenas o elemento J finalizar a implementação da

recuperação da palavra-passe.
▪ Os restantes 4 elementos focam se na construção do algoritmo de hiperligação
com a página inicial.
▪ No decorrer do dia a equipa vai criando vários tipos de algoritmos até ter um
esboço de um algoritmo fiável e que possa ser implementado na página

antecipar.

▪ Desde o último Daily Scrum, o elemento J terminou a implementação do

processo de recuperação da palavra passe.
▪ Os restantes elementos, contribuíram uma grande parte para o
desenvolvimento do algoritmo de hiperligação com a página inicial estando
praticamente finalizada.
▪ Finalização da ultima tarefa que esta relacionada com o algoritmo de

hiperligação.
10
ICONIX
▪ Reunir uma equipa e começar a fazer uma revisão profunda a tudo o que
foi feito no ambito de poder encontrar falhar em alguma das tarefas e
selecionar caso seja o caso interfases que possa ser melhorado.
A equipa decide se juntar e finalizar o algoritmo de hiperligação.

Apos a conclusão da ultima tarefa, cada elemento decide pegar em uma tarefa
passada e fazer um check-up de falhas/melhoramentos de códigos para que o
sprint esteja pronto sem qualquer deficiência.

antecipar.
➢ User Story Login
@Login
• Funcionalidade: Login
Ação:
1. Utilizador do sistema ESC Tutoriais
2. O utilizador X pretende fazer o login no sistema
3. O elemento X pretende aceder as funcionalidades de utilizador apos ter o
login feito.
❖ Contexto
Pré-requisitos: O utilizador X já tem conta no sistema ESC Tutoriais
11
ICONIX
-Existem 3 cenários possíveis dentro desta ação:

1. Login mas com senha incorreta
2. Login mas com nome de utilizador incorreto
3. Login com senha e nome de utilizador corretos/validos
Cenário 1:
• O utilizador acede á página de Login
• Apos aceder á pagina o utilizador começa a preencher os seus dados
pessoais com senha incorreta
• O utilizador conclui o preenchimento das credenciais
• O utilizador prime a opção aceder á página ESC Tutoriais
• A base de dados da página verifica os dados
• Deteta falha nas credenciais (senha incorreta)
• Envio de uma mensagem para o utilizador a notifica lo de senha
incorreta
Cenário 2:
pessoais com o nome de utilizador incorreto
• Deteta falha nas credenciais (nome de utilizador incorreto)
• Envio de uma mensagem para o utilizador a notifica lo de nome de
utilizador incorreta
Cenário 3:
pessoais validos e corretos
• Dados corretos
• Redireciona o utilizador para a página principal da ESC Tutoriais
12
ICONIX
➢ Revisão do Sprint
• No decorrer deste Sprint, a equipa esteve focada na autenticação de todos

os utilizadores menos o utilizador não registado, para dar prioridade aos
utilizadores mais importantes do sistema.
• Depois de realizado o login, a equipa implementou com sucesso as páginas
do coordenador UTC as paginas dos Docentes e as paginas dos Alunos.
• Foi também criado um algoritmo específico que tem a funcionalidade de
hiperligação entre páginas.
• Em suma o sistema que foi trabalhado neste sprint foi feito com sucesso e
as tarefas foram entregues por completo ao Product Owner.
➢ Retrospetiva do Sprint
• A equipa não teve problemas de maior a anotar

• O Sprint foi realizado de forma tranquila e bastante eficaz
• A equipa apenas apontou a baixa forma de um dos elementos durante
espaço temporal pequeno, mas que não afetou muito a fluidez da
velocidade de entrega de tarefas
• Todos os obstáculos foram ultrapassados e o print foi entregue a tempo
➢ Burndown Chart
13
ICONIX
5.2 Sprint 2

➢ Sprint Backlog Tabela
1. Definir os dados do formulário

2. Definir que tipos de interceções vao ser criados com o utilizador
3. Começar a verificar o tratamento de dados
4. Esboço da interfase da página de pré-inscrição
14
ICONIX
▪ Durante a manha, esta foi dedicada e preenchida por uma reunião entre os
elementos da equipa para garantir a distribuição de tarefas.
▪ O elemento A e B passaram a tarde a definir os dados a serem utilizados, para isso
criaram uma lista de todas as interações possíveis entre o utilizador e o
preenchimento de dados.
▪ O elemento E ficou com a verificação e tratamento de dados, mas só começou a
sua tarefa assim que os elementos A e B lhe transmitiram a folha onde estava
definida os dados que iriam ser utilizados.
▪ Os restantes 2 elementos, J e R começaram a desenhar os esboços das interfases
da página de pré-inscrição.
▪ Ao final do dia os elementos A e B facultaram aos elementos J e R a lista das
definições de interceções entre o utilizador e a página para o preenchimento de
dados.
➢ Como este foi o primeiro dia e o dia foi marcado por reuniões da parte da
manha e inícios muito superficiais das tarefas a serem trabalhadas por
partes de todos os elementos da equipa, não ocorreram quaisquer
obstáculos.
15
ICONIX

• O dia de ontem foi dedicado á revisão de códigos e verificação de bugs e
implementações de melhorias.
Testagem individual de cada sub-tarefa

Simulações e testagem final das funcionalidades
• Visto ser o último dia deste Sprint os elementos A e E passaram a manha a fazer
testes finais e aplicarem as encriptações necessários para entregar o produto
final.
• O elemento B passou o dia a documentar os códigos e algoritmos utilizados
• Os restantes elementos auxiliaram no que fosse preciso e fizeram uma pequena
arrumação no departamento.
• Nenhum obstáculo surgiu neste dia.
16
ICONIX
➢ Revisão Sprint
• A equipa neste sprint focou-se nas pré-inscrições dos alunos no sistema

por parte do coordenador, deixou esta tarefa completa, testada e com os
dados encriptados.
• Nesta página é possível preencher os dados do aluno, criar um número de
aluno e atribuir-lhe um tutor.
• A base de dados foi criada com sucesso e aceitou todas as modificações que
sofreram
• A página funcionou na perfeição e as tarefas foram entregues sem qualquer
tipo de obstáculos
•
• A equipa sentiu que o sprint correu bem e que não ocorreram obstáculos que
impedissem a continuidade das tarefas. Houve uma boa cordialidade e muita
comunicação entre a equipa.
• Apenas houve uma ligeira demora na parte final do sprint relacionada com a
encriptação de dados e a desencriptação, no penúltimo dia de sprint, mas foi
facilmente arranjada uma solução para o problema.
• A equipa também anotou que deveria não demorar tanto nas reuniões já que
consumia muito tempo.
➢ Burndown Chart
17
ICONIX
5.3 Sprint 3

18
ICONIX
1. Definir quais são os dados do formulário

2. Implementar as interfases da página do formulário
3. Implementar importação de dados já preenchidos
▪ Os Elementos E, A e B, foram destacados para definir quais os dados que

vão compor o formulário e iniciar a fase de implementações.
➢ Após serem definidos os campos que o formulário vai conter os elementos J
e R vão começar a implementar a interface da página do formulário
➢ O elemento E saiu do grupo a meio da tarde para poder se focar na
implementação das importações dos dados já preenchidos.
▪ Sendo este o primeiro dia do Sprint ainda não surgiram obstáculos, apesar
de se notar na equipa algum desconforto devido ao elevado número de
tarefas que terão de ser feitas.
19
ICONIX
➢ Todos os elementos trabalharam na parte da encriptação dos dados, para

depois em conjunto fazerem o desenvolvimento das mensagens de erro.

➢ Finalização das 2 últimas sub-tarefa a tempo de ser entregue dentro do
prazo estipulado pelo sprint.
• Visto ser o ultimo dia deste Sprint a equipa convocou uma reunião de emergência
para delinear o que cada elemento deve focar se para poder acabar e entregar as
funcionalidades a funcionar sem erros e a tempo da deadline.
• Os elementos A e B vão focar se na encriptação dos dados, e os elementos E e J vão
repartir forças para desenvolver as mensagens de erro que iram ser acionadas por
parte do sistema caso algo não esteja correto.
• O elemento R vai tratar de rever toda a documentação para não atrasar na entrega
das tarefas.
• A sub-tarefa de encriptação dos dados foi construída com sucesso,

infelizmente os elementos E e J não conseguiram finalizar o
desenvolvimento de mensagens de erro, ao algoritmo que utilizaram estar
a apresentar bugs e que comprometia o bom funcionamento do sistema no
envio de alertas.
20
ICONIX
➢ Revisão Sprint
• A equipa neste sprint pegou em 2 funcionalidades e decidiu uni las no

mesmo sprint, visto que uma estava relacionada com a outra por isso
podiam ser desenvolvidas em conjunto.
• O sprint correu maioritariamente bem no decorrer do sprint pecando por
escassez na ultima sub-tarefa da tarefa relacionada com o preenchimento
do formulário devido a já estarem sem qualquer tempo de avanço e esta
ultima ter tido problemas graves que impediram a entrega do sprint
completo.
➢ A equipa sentiu que deu o máximo apesar de não ter finalizado a

construção de todas as sub-tarefa.
➢ E equipa reportou o sucedido ao Product Owner e foi autorizado a
enviarem o sprint final ao cliente fora da deadline estipulada.
➢ Apesar desta falha nos prazos, a equipa continua unida e confia em cada
membro da equipa para poderem “atacar” os próximos sprints.
21
ICONIX
➢ Burndown Chart
5.4 Sprint 4
22
ICONIX
• As últimas 24h foram marcadas pela conclusão do sprint anterior, visto não o
terem concluído a tempo.
1. Dar início á implementação da interface da página da ficha de frequência

2. Implementar as hiperligações para a ficha de frequência e para a página
principal
▪ Os elementos A e B começaram com a implementação da pagina da ficha de

frequência, enquanto os restantes elementos auxiliaram-nos nas
ferramentas e códigos que precisassem para concluir a sub-tarefa ainda
durante o dia.
23
ICONIX
▪ Após estar concluída a interface da ficha de frequência, os elementos A e B

vão implementar a hiperligação da página inicial até à ficha de frequência,
enquanto os elementos E e J implementam a hiperligação da ficha de
frequência até à página inicial.
▪ O elemento R ficou a testar as hiperligações para ver se tudo estava a
funcionar.
▪ Sendo este o primeiro dia do Sprint ainda não surgiram obstáculos.
24
ICONIX
➢ Todos os elementos trabalharam na parte da encriptação dos dados, para

depois em conjunto fazerem o desenvolvimento das mensagens de erro.
➢ Finalização da última sub-tarefa.

➢ Revisão de códigos e testagens finais
• Todos os elementos juntaram se e em conjunto procederam ao desenfiamento da

hiperligação com o docente para poderem acelerar o trabalho e ser entregue desta
vez a tempo e a horas.
• A meio da tarde a equipa já tinha tudo concluído, documentaram tudo e
entregaram antes da deadline.
▪ Não surgiram obstáculos neste sprint.
25
ICONIX
➢ Revisão Sprint
▪ Como o sprint anterior não ficou finalizado a equipa demorou mais tempo
a começar este para poder finalizar as tarefas anteriores.
▪ Apesar do atraso no início a equipa recuperou bem e consegui
complementar o sprint sem qualquer problema e entregou tudo a tempo
▪ A equipa sentiu que o sprint fluiu com bastante facilidade e que todos
deram o máximo de si para cumprir o prazo tendo ficado um sentimento de
dever cumprido em toda a equipa.
▪ A equipa tem novamente os indicies de motivação em alta e sentem que
estão aptos a continuar os próximos sprints sem quebras de rendimento
26
ICONIX
➢ Burndown Chart
5.5 Sprint 5
27
ICONIX

5.2 Realizar interfaces e Storyboards

5.3 Definição dos dados que serão necessários
▪ Dado ser um sprint com 3 tarefas embutidas, a equipa de linha um plano

estratégico antecipadamente para que não surja imprevistos nem atrasos.
▪ Todos os elementos do grupo concordaram em juntarem-se e discutirem o
design e o storyboard que o programa posteriormente formaria na página
de solicitação de reunião.
Apos os designs já estarem bem encaminhados, os elementos A e B
separam se daquela sub-tarefa e começam a definir os dados que iram ser
necessários usar.
28
ICONIX
29
ICONIX
Desde o último Daily Scrum, os elementos A, B e E terminaram a revisão a

todos os dados enviados pelos tutorados e tutores para poderem registar a
reunião. Fizeram os testes ao servidor para ver se estava tudo a funcionar
corretamente na transmissão de dados
Os elementos J e R, trabalharam afincadamente para terminar o envio da
mensagem e confirmar o registo da reunião.
1. Codificar o algoritmo que envie as mensagens de confirmação ou de

erro
2. Desenvolver os mecanismos que aceitem registar a reunião
3. Encriptar todos os dados
4. Revisão da tarefa
Com a verificação de todos os dados enviados pelos alunos e tutores elementos A

e B, focam se na fase em que o sistema tem de proceder ao envio das mensagem
consoante a validação ao não do sistema para aquela data
Já os elementos J e E trabalham na funcionalidade que permite registar as
reuniões
O elemento R está a tratar da encriptação dos dados.
A meio do dia a equipa deparou se com um grande problema nas interações com a
base de dados, visto que o sistema estava a confundir o envio de mensagem entre
os alunos e tutores.
As últimas sub-tarefa tiveram de parar ate que a equipa pudesse resolver o
problema
▪ Houve um obstáculo grande na parte final do sprint por causa de um erro

no desenvolvimento de uma funcionalidade que só foi detetada na parte
final do sprint
▪ O trabalho não pode ser entregue dentro do prazo.
30
ICONIX
➢ Revisão Sprint
No decorrer deste sprint a equipa teve em mãos um sprint que não era difícil, mas
que tinha muitas sub-tarefa a fazer.
O Sprint decorreu de forma tranquila na maioria do tempo, apesar de no final a
quipá ter-se deparado com um erro de desenvolvimento e por estar muito próximo
da deadline fez com que impedisse a entrega do trabalho
▪ A equipa sente se muito cansada e esgotada psicologicamente por mais

uma vez não ter conseguido entregar um sprint a tempo
▪ Houve uma reunião onde estiveram presentes o Product owner, Scrum
master, onde foi decidido que o erro foi geral por terem calculado mal a
quantidade de horas que este sprint iria precisar a mais .
31
ICONIX
➢ Burndown Chart
5.6 Sprint 6
32
ICONIX

▪ As últimas 24h foram marcadas pela conclusão do sprint anterior, visto não
o terem concluído a tempo.
1. Realizar interfaces e Storyboards

2. Criação das hiperligações que serviram de ponte ente a base de dados e os
dados do tutorando
▪ A equipa teve uma reunião matinal onde foi revista as funções de cada um
durante o dia.
▪ Todos os elementos do grupo concordaram em juntar-se e discutirem o
design da interface e o storyboard.
▪ De seguida os elementos R e J irão mudar o tópico para decidir quais os
dados que o tutor irá ter acesso na consulta de dados do tutorando.
33
ICONIX
Desde o último Daily Scrum, os elementos A, B e E terminaram os testes

relativos ao novo algoritmo que criaram para as mensagens de erro.
E notificaram o elemento J que já poderia começar a construir o esboço do
design das caixas de mensagem de erro
1. Design das caixas das mensagens de erro

2. Implementação da confirmação da alteração de dados
➢ O elemento J ira terminar o design das caixas de mensagens de erro.

➢ Os elementos A e B irão trabalhar na implementação da confirmação da
alteração de dados.
34
ICONIX
➢ Os elementos E e R, passaram o dia a rever os documentos e a realizar

simulações no servidor para verificar se as funcionalidades estão a
desempenhar corretamente as suas funções.
▪ Os elementos da equipa sentem- se nervosos pois em cima do deadline

ainda não tinham o sprint pronto, este nervosismo poderá ser um
obstáculo.
▪ O sprint foi entregue algumas horas fora do prazo
➢ Revisão Sprint
▪ Neste sprint a equipa criou a funcionalidade de consultar e editar dados,

tendo conseguido concluir o sprint mesmo em cima do deadline, apesar do
sprint ter sido cumprido, sente se algum desgaste na equipa devido ao
stress associado a uma entrega tão em cima da hora.
▪ A equipa sente se muito cansada, e começa se a notar alguma fadiga tanto

física como psicológica.
▪ Apesar de tudo a equipa sabe que está a dar o máximo e preparada para
mais um sprint.
35
ICONIX
➢ Burndown Chart
5.7 Sprint 7
36
ICONIX

▪ Sendo este o primeiro Daily Scrum não foi discutido o que já tinha sido
feito.
1. Definir as matérias a ter tutoriais

2. Iniciar a fase de criação dos tutoriais
3. Definir o que será mostrado na página dos tutoriais
• Toda a equipa vai definir quais vão ser as matérias de cada UC que irão ter
tutoriais. Como este é uns passos trabalhosos, pois existem várias UCs, a
equipa quisemos fazer este passo juntos pois quantos mais a debater o assunto
melhor.
• Foi elaborado um esboço para cada UCs para evitar que aconteçam falhas
futuramente.
• Após serem definidas as matérias de cada UC a ter tutorial, os elementos A e B
vão começar a definir o que irá aparecer na página dos tutoriais.
• Os elementos E e J vão começar a criar os tutoriais, já o elemento R vai auxiliar
ambas as tarefas.
37
ICONIX
• Os elementos J e E realizaram a hiperligação da página dos tutoriais para a

página inicial.
• Os elementos A e B começaram a desenvolver a encriptação do acesso á
página dos tutoriais.
1. Finalização da encriptação do acesso á página
➢ Dado que apenas existe uma sub-tarefa por fazer, a equipa resolver dar
folga aos elementos J , E e R .
➢ Os elementos A e B a meio da tarde terminaram a sub-tarefa e concluíram a
documentação toda dos códigos envolvidos nesta tarefa.

38
ICONIX
➢ Revisão Sprint
▪ A equipa neste sprint focou-se numa nova funcionalidade do sistema, a

criação de uma página de tutoriais com a matéria de cada UC que o aluno
frequenta.
▪ Nesta página é possível o aluno consultar os tutoriais sobre as UC que o
mesmo frequenta.
▪ O aluno pode escolher diferentes tutoriais para diferentes UC´s
▪ A equipa sentiu que o Sprint correu bem.

▪ Houve oportunidade de dar folga no último dia a vários elementos para
que pudessem descomprimir um pouco antes de começar uma nova etapa
➢ Burndown Chart
39
ICONIX
5.8 Sprint 8
▪ Sendo este o primeiro Daily Scrum não foi discutido o que já tinha sido
feito.
1. Implementar as interfaces da página

2. Implementar a hiperligação para a página
• Os elementos A e J vão começar com a implementação da página e esta

previsto que esta sub-tarefa demore o dia todo.
• Os elementos B e E vão começar a estudar e começar com as primeiras
tentativas de hiperligações que direcionem para a página.
• O elemento R vai ficar a procurar códigos que possam ser usados nestas sub-
tarefas
40
ICONIX
• Os elementos A e B finalizaram as encriptações do acesso á pagina.

1. Rever os códigos
2. Documentar o trabalho
3. Fazer uma revisão a fundo no nível de segurança da encriptação
➢ Sendo este o último dia do Sprint e tudo está terminado, os elementos

decidiram reunir se e simular um ataque á base de dados para poder
avaliar o nível de segurança que implementaram
➢ Apos a revisão estar feita, a equipa documentou tudo e entregou as tarefas

41
ICONIX
➢ Revisão Sprint
A equipa neste sprint focou-se na criação de uma página onde irá ser possível
visualizar as notas que um aluno teve.
Foi criada a funcionalidade com sucesso utilizando algoritmos passados, e foi
assegurada a segurança e proteção de dados dos alunos.
▪ A equipa sentiu que o Sprint correu bem.

A equipa gostou deste Sprint pois foi algo que a equipa conseguiu fazer com
alguma facilidade, e teve tempo de garantir com testes o nível de
segurança, não surgindo problemas pelo meio.
➢ Burndown Chart
42
ICONIX
5.9 Sprint 9

▪ Sendo este o primeiro Daily Scrum não foi revisto nada que ser tenha feito
1. Definir e esboçar a estrutura do fórum

2. Definir e começar a implementar a interface da página do fórum
• Durante o dia foi criado um esboço de como seria a estrutura do fórum, apos
todos estarem de acordo, os elementos A e E começaram a documentar e a
definir a estrutura do mesmo.
• Já os restantes elementos começaram a definir e a implementar as interfaces
da página do utilizador.
43
ICONIX
• Tentativa de finalização das sub-tarefa 5,6 e 7

1. Conceber acesso ao fórum por parte dos utilizadores
2. Definir quem são os utilizadores
3. Habilitar os utilizadores a criar salas de chat
4. Desenvolver Tutoriais para ajudar os utilizadores
5. Encriptação do acesso á pagina
➢ Sendo este o último dia do Sprint e como a equipa esta reduzida a apenas 3
elementos presenciais e 2 em teletrabalho devido a estarem com o covid-
19, a equipa viu se obrigada a que cada elemento esteja sozinho na
44
ICONIX
tentativa de cada um entregar uma das funcionalidades que estão em

atraso.
➢ A equipa desistiu ao final do dia devido á exaustão do trabalho e á fraca
eficácia da equipa
• Não ocorreram obstáculos em relação a códigos e algoritmos, apenas houve

escassez de tempo, eficácia e muito trabalho que teve de ser realizado
sobre muito stress e bastante limitado.
➢ Revisão Sprint
A equipa neste sprint deu o seu máximo para entregar o projeto, apesar de
estar bastante limitada, houve várias sub-tarefas por finalizar.
A equipa sente se desgastada, mas ao mesmo contente por este ser o último
sprint.
A equipa sentiu que o sprint foi um pouco atribulado devido a um surto de

covid-19 que afastou 2 membros por 3 dias do projeto o que fez com que os
outros 3 elementos fossem obrigados a dar muito mais de si e sentissem
mais dificuldade na tentativa de finalizar todas as funcionalidades a tempo
da entrega.
45
ICONIX
➢ Burndown Chart
46
ICONIX
6. Conclusão
O relatório apresentado teve como objetivo a implementação com base no

framework SCRUM, para um sistema de acompanhamento de alunos e de tutoriais do
ESC para tal foi efetuado a demonstração de 9 sprints, que envolviam 13
funcionalidades.
Nos sprints um deles foi ao detalhe e os restantes tiveram apenas o estado inicial e
final do Sprint Backloge do Product Backlog.
Durante os 9 sprints garanti mos que pelos menos 25% o sprint iria apresentar
problemas na sua finalização, neste caso aconteceu 3 vezes.
Com a realização deste trabalho tivemos a oportunidade de adquirir novos
conhecimentos em termos de modelação de sistemas com base no SCRUM pondo em
prática todo o conhecimento adquirido nas aulas teóricas e práticas.
Foi possível concluir que o SCRUM é um framework de gerenciamento de projetos,

da organização ao desenvolvimento ágil, que se mostra focado em resultados, na
comunicação da equipa e na interação com clientes sem desrespeitar as restrições
enfrentadas pelo projeto, ou seja, o SCRUM não é um processo padronizado onde
sistematicamente é possível seguir uma série de etapas sequenciais que irão garantir
a produção, no prazo e no orçamento, um produto de alta qualidade que irá encantar
o cliente. O SCRUM organiza e gerência trabalhos complexos.
Com este trabalho consegui mos simular uma empresa informática e o trabalho que
foram desenvolvendo durante 4 meses e meio (9*10 dias uteis).
Sentimos alguma dificuldade na perceção de alguns valores do SCRUM tal como o

burndown chart e na extensão do trabalho no entanto, com a ajuda do docente
conseguimos ultrapassar essas dificuldades.
7. Referências Bibliográficas
“Iconix,” [Online]. Available: http://siiconix.blogspot.com/p/fases.html.
“Trabalhos de Sistemas de Informação,” [Online]. Available:

http://trabalhosdesistemasdeinformacao.wikidot.com/blog:1.
47

Modelação SCRUM sistema informação acadêmico

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelação SCRUM sistema informação acadêmico

Enviado por

Direitos autorais:

Formatos disponíveis

SCRUM

Modelação de Sistemas Informáticos

O presente documento trata a modelação de um sistema de informação

Figura 1 - Reunião Diária .............................................................................................................. VII

Lista de abreviaturas, siglas e acrónimos

ESC – Escalos de Cima

O presente trabalho apresenta a modelação de um sistema de informação

▪ O Development Team, ou Equipa de Desenvolvimento, são os responsáveis por

Figura 1 - Reunião Diária

Quando um Sprint acaba, a equipa convoca nova reunião e reúne-se novamente no

▪ O Product Backlog é uma lista ordenada de tudo o que é necessário para

▪ O Sprint Backlog consiste no trabalho a ser desenvolvido num Sprint de modo

▪ Durante a execução do Sprint cada Sprint pode ter períodos temporais

▪ A Sprint Review, também conhecida como a “Sprint Demo”, é uma reunião

▪ A Sprint Retrospective é uma retrospetiva que é realizada no final de cada

▪ Também conhecido como gráfico de burndown, em resumo, o burndown

Figura 3- Gráfico Burndown Chart

4. Modelação SCRUM “ESC Tutoriais”

Figura 4- Caso de Uso

5. Product Backlog / Sprint Backlog

Figura 5 - Product Backlog/Sprint Backlog

1ºDia – Daily Scrum

Revisão do que foi feito nas últimas 24h

O que se pretende para o dia de hoje

Progresso do decorrer do dia

▪ Durante o dia o elemento B começa o seu trabalho na tentativa de implementação

Anotação dos obstáculos que foram surgindo no decorrer do dia

➢ Como este foi o primeiro dia e o dia foi maioritariamente dedicado a

2ºDia – Daily Scrum

Revisão do que foi feito nas últimas 24h

• O dia de ontem foi dedicado às reuniões onde foi concretizado metade do

O que se pretende para o dia de hoje

Progresso do decorrer do dia

Anotação dos obstáculos que foram surgindo no decorrer do dia

➢ Surgiram alguns obstáculos principalmente com a troca de elementos, visto

3ºDia – Daily Scrum

Revisão do que foi feito nas últimas 24h

▪ As tarefas atribuídas ontem foram todas concluídas com sucesso apesar de

O que se pretende para o dia de hoje

Progresso do decorrer do dia

▪ Os elementos A e B sentam se e começam a discutir a estrutura que a base de

o Sem qualquer problema a anotar

4ºDia – Daily Scrum

Revisão do que foi feito nas últimas 24h

O que se pretende para o dia de hoje

▪ Acabar as tarefas relacionadas com a base de dados

Progresso do decorrer do dia

Anotação dos obstáculos que foram surgindo no decorrer do dia

o Sem qualquer problema a anotar apesar de que a implementação da

5ºDia – Daily Scrum

Revisão do que foi feito nas últimas 24h

▪ A equipa conseguiu finalizar as interações com a base de dados e já

O que se pretende para o dia de hoje

▪ Progredir na implementação da página do coordenador.

Progresso do decorrer do dia

O elemento E retorna ao grupo dos elementos J e R para poderem acelerar a

Anotação dos obstáculos que foram surgindo no decorrer do dia

o Sem qualquer obstáculo que possam atrasar o sprint

6ºDia – Daily Scrum

Revisão do que foi feito nas últimas 24h

▪ Desde a última reunião, a equipa conseguiu finalizar a implementação da

▪ Sendo que a implementação da página dos docentes ainda está em