Equipe:
| Sobre | Sprints | Quick Start | Product Backlog | User Stories | Preview | Tecnologias | Equipe |
Em face de uma pandemia mundial instituições de ensino do mundo todo enfrentaram o grande desafio de adaptarem as atividades acadêmicas para o ensino remoto em um curto espaço de tempo. Com isso o aumento do uso de ferramentas de correios eletrônicos para comunicação dentro das instituições cresceu de forma exponencial levando a diversos problemas por perda de informações. Com o intuito de resolver esse problema, a FATEC São José dos Campos propôs aos alunos do 1° semestre do curso de Desenvolvimento de Software Multiplataforma (DSM), o desenvolvimento de um portal de informações para o Corpo Docente, Discente e Administrativo da Fatec SJC capaz de exibir e gerar de forma seletiva e controlada os avisos gerais ou específicos de cada usuário, respeitando as respectivas hierarquias dentro da universidade com o intuíto de melhorar a comunicação interna da instituição.
Sprint | Link | Início | Entrega | Status |
---|---|---|---|---|
01 | Sprint 01 | 08/09/2021 | 19/09/2021 | ✔ |
02 | Sprint 02 | 20/09/2021 | 10/10/2021 | ✔ |
03 | Sprint 03 | 18/10/2021 | 07/11/2021 | ✔ |
04 | Sprint 04 | 08/11/2021 | 28/11/2021 | ✔ |
Tendo a ferramenta Git e o Python instalados em seu computador:
- Abra o Prompt de Comando no caminho de um novo diretório e copie o seguinte comando para clonar o nosso repositório:
git clone https://github.com/Monkey-Type/API-DSM.git
- Dentro da pasta root do projeto, crie um Ambiente Virtual com o seguite comando:
python3 -m venv venv
ou caso tenha o python3 já instalado
python -m venv venv
(Obs.: caso você utilize um sistema operacional diferente do Windows, verifique comandos alternativos neste Link .)
- Isso criará o diretório
venv
. Agora ative o Ambiente Virtual com o comando:
venv\Scripts\activate
- Você deverá ver o ambiente virtual ativado antes do caminho do seu diretório, assim:
(venv) C:\...
- Agora instale as dependências do projeto:
pip install -r requirements.txt
- Agora certifique-se que está no diretório
src
e para executar a aplicação, execute o comando:
flask run
- A aplicação estará rodando por padrão na porta :5000, caso já tenha uma aplicação rodando nesta porta, certifique-se de selecionar uma porta livre na hora de rodar a aplicação:
flask run -p 9000
- Vá até o caminho indicado http://127.0.0.1:5000/ ou http://127.0.0.1:9000/ e navegue na aplicação.
- RF - Requisito Funcional
- RNF - Requisito Não Funcional
REQUISITO FUNCIONAL_ID | USER STORIES_ID | REQUISITOS | SPRINTS |
RF - 1 | #01 | Criação de um protótipo navegável | #01 ✔ |
RF - 2 | #02 | A Identidade Visual do sistema deve levar em consideração a identidade visual da Fatec SJC | #01 ✔ |
RF - 3 | #03 | Interface com navegação intuitiva | #01 ✔ |
RF - 4 | #05 #14 #15 #16 | Envio de informações para divulgação via sistema (Administrador) | #02 ✔ |
RF - 5 | #07 #11 #13 | Visualização de informações de divulgação via sistema de modo seletivo (filtro por data, interessados, curso, etc.) | #02 #03 ✔ |
RF - 6 | #08 | Acesso às informações do sistema através de perfis de usuário/papeis (adm,usuário comum, coordenador de curso, etc.) | #02 #03 ✔ |
RF - 7 | #21 | Quem criou a mensagem é o único com poder de exclusão da mesma | #02 #03 ✔ |
RF - 8 | #09 #17 | Cada Usuário deve ter o poder de enviar informes/anúncios a determinados grupos de usuários e receber mensagens de determinado grupos de usuários numa hierarquia de USERS | #02 #03 ✔ |
RF - 9 | #22 | Nas categoria de usuário onde há uma hierarquia (ex.: chefe da secretaria e assistente da secretaria), deverá haver a opção de habilitar quem pode mandar mensagem dentro desse grupo de usuário | #03 #04 ✔ |
RF - 10 | #18 #20 | O usuário deve ter a automia de marcar a mensagem como lida e não lida (arquivar). Será importante manter um histórico de mensagem. | #03 #04 ✔ |
RF - 11 | #06 #10 #12 | Possibilidade de anexar documentos (e.g.: PDFs, Docs, etc) | #03 #04 ✔ |
RNF - 1 | Utilizar HTML5 para arquitetura da informação da aplicação | #01 ✔ | |
RNF - 2 | Utilizar CSS 3 para especificação do layout e demais características de renderização da interface com o usuário | #01 ✔ | |
RNF - 3 | Utilizar JavaScript no front end (obs.: pode fazer uso de frameworks) | #01 ✔ | |
RNF - 4 | Desenvolver o back end com a linguagem Python 3+ e o microframework Flask | #02 ✔ | |
RNF - 5 | Utilizar o sistema gerenciador de banco de dados MariaDB/MySQL/PostGresSQL | #02 ✔ | |
RNF - 6 | Sistema responsivo | #02 #03 ✔ |
US__ID | RF_ID | REMETENTE | INSTRUÇÃO | FINALIDADE |
US-1 | #01 | Cliente | Como Cliente, eu quero poder testar a aplicação antes de usa-la | Para que eu simule a experiência que meus usuários terão na minha aplicação |
US-2 | #02 | Cliente | Como Cliente, eu quero que o design siga a identidade visual da Fatec São Jose dos Campos | Para que os usuários saibam que estão em um site da Fatec de São Jose dos Campos |
US-3 | #03 | Cliente | Como Cliente, eu quero que a interface seja intuitiva | Para que os usuários consigam aprender a usar a aplicação facilmente |
US-4 | RNF-6 | Cliente | Como cliente, eu quero que interface seja responsiva | Para que os usuários consigam ter facidade de acesso em qualquer dispositívo |
US-5 | #04 | Administrador/ Secretaria | Como usuário administrador, eu quero enviar as informações | Para que qualquer pessoa que possuam uma conta fatec consiga visualizar essas informações |
US-6 | #11 | Administrador/ Secretaria | Como usuário administrador, eu quero poder anexar arquivos e documentos | Para que alunos, professores e a comunidade da fatec possa vizualizar e fazer download desses arquivos/documentos |
US-7 | #05 | Administrador/ Secretaria | Como usuária administrador, eu quero poder filtrar as informações de modo seletivo (data, cursos, etc) | Para gerenciar o que cada cargo envia na plataforma |
US-8 | #06 | Administrador/ Secretaria | Como usuário administrador, eu quero que a plataforma possua cargos (adm, aluno, professor) | Para que cada cargo apenas veja o que é de seu interesse/autoridade |
US-9 | #08 | Professor | Como professor, eu quero poder enviar anúncios | Para que alunos, outros professores ou secretaria que uma conta fatec consigam visualizar essas informações |
US-10 | #11 | Professor | Como professor, eu quero poder anexar arquivos, documentos, etc | Para que alunos consigam acessar e fazer o download desses arquivos, documentos, etc |
US-11 | #05 | Professor | Como professor, eu quero poder filtrar as informações que recebo por data de modo seletivo (curso, interessados, etc) | Para que não exista conflito de informações e para que eu consiga ver apenas o necessário |
US-12 | #11 | Aluno | Como aluno, eu quero poder enviar trabalhos, provas, arquivos em geral | Para que meu professor possa visualizar e baixar esses arquivos |
US-13 | #05 | Aluno | Como aluno, eu quero poder filtrar as informações do sistema de maneira seletiva (materia, interessados, etc) | Para que eu consigo ver apenas o necessário e me organizar melhor pela plataforma |
US-14 | #04 | Coordenador | Como Coordenador, quero poder criar informes | Para que todos os Usuários da FATEC possam vê-los |
US-15 | #04 | Diretor | Como Diretor, quero poder criar informes | Para que todos os Usuários da FATEC possam vê-los |
US-16 | #04 | Secretaria Administrativa | Como Usuário da Secretaria Administrativa quero poder criar informes | Para que todo o corpo docente da FATEC possa ve-los |
US-17 | #08 | Secretaria Acadêmica | Como Usuário da Secretaria Acadêmica quero poder divulgar informes | Para que qualquer usuário que seja Aluno ou Professor possa ve-los |
US-18 | #10 | Usuário Geral | Como Usuário quero poder marcar as mensagens como lidas | Para que as mensagens lidas saiam da minha lista de mensagens |
US-20 | #10 | Administrador | Como Administrador quero que seja mantido um histórico de mensagens (arquivadas) | Para que seja possível revê-las |
US-21 | #07 | Usuário Geral | Como Usuário que pode enviar anúncios e mensagens quero que apenas eu possa excluí-las. | Para que eu possua um histórico acessível do que eu gerei |
US-22 | #09 | Secretaria | Como Usuário que possuí hierarquia interna quero poder habilitar quais Usuários podem ou não enviar mensagens dentro do meu grupo | Para que eu possa manter o controle dos Usuários dentro da hierarquia da minha categoria |
Heroku: Acesso nossa aplicação!!!!
Tecnologias links Úteis:
- HTML5
- CSS3
- JavaScript
- TailwindCSS
- Adobe XD
- GitHub
- Visual Studio Code
- Git
- Postgres
- Flask
- Python
- Slack
- Discord
Nome | Posição | GitHub | |
Rafael da Silva Peres | Product Owner | GitHub | |
Gabriel Souza Bicho Nunes | Scrum Master | GitHub | |
Gustavo Pereira | DEV | GitHub | |
Leonardo Queiróz Machado | DEV | GitHub | |
Lucas Ferreira da Costa | DEV | GitHub | |
Rafael Leonardo Lopes | DEV | GitHub | |
Vinícius Andrade B. | DEV | GitHub |
Na Primeira Sprint fizemos o levantamento dos Requisitos junto ao cliente através do Product Owner do nosso grupo. Assim tivemos uma melhor idéia do que consistiriam os Requisitos Funcionais (RF) e os Requisitos Não Funcionais (RNF) do produto, possibilitando a criação da nossa Backlog do Produto. Aqui se fez necessária a criação do Repositório GitHub para criar e manter um histórico das alterações feitas no projeto visando também a sua organização. Usando o recurso das Histórias dos Usuários junto aos requisitos levantados, conseguimos explicitar melhor qual era a necessidade do cliente e o foco principal do nosso produto. Com as Histórias dos Usuários prontas, criamos o Backlog da Sprint 01. Para o Esboço (Sketch) da nossa aplicação, utilizamos o espaço de trabalho visual colaborativo Whimsical. Então geramos as Tarefas que cada um dos membros da equipe iriam executar. A partir da criação das Tarefas foi possível estimar o tempo de entrega de cada tarefa e assim a criação da nossa ferramenta visual do Scrum, o gráfico Burndown. Criado então o Readme.MD para apresentação do nosso projeto. Usando a linguagem de marcação HTML5, a ferramenta de estilização "Folha de Estilo em Cascatas" CSS3 e JavaScript para ajudar na experiência da navegação. Assim criamos nosso Protótipo Navegável.
REQUISITO FUNCIONAL_ID | REQUISITOS DA SPRINT | TAREFA INICIADA | STATUS |
RF - 1 | Criação do Esboço referência para a aplicação considerando a representação de suas funcionalidades totais | ✔ | ✔ |
RF - 1 | Construção do corpo da aplicação | ✔ | ✔ |
RF - 1 | Disponibilização de botões funcionais que direcionem o usuário para os locais corretos dentro do site | ✔ | ✔ |
RF - 1 | Possibilitar preenchimento de texto em campos chaves, para melhorar a experiência do usuário no protótipo | ✔ | ✔ |
RF - 2 | Trazer representação visual suficiente da identidade visual da Fatec SJC tomando como referência o site oficial (ex.: cores, logotipos) | ✔ | ✔ |
RF - 3 | Dividir layout da página em seções e as seções com cores facilitando a compreensão pelo usuário | ✔ | ✔ |
RF - 3 | Cores seguem relação com suas seções mantendo a Identidade Visual do sistema | ✔ | ✔ |
RF - 3 | Evitar a adição de elementos desnecessários na interface da aplicação | ✔ | ✔ |
RF - 3 | Acesso a informação com poucos "cliques" | ✔ | ✔ |
RNF - 1 | Utilizar um sistema de Navegação Global onde o usuário sempre tenha acesso as funcionalidades da aplicação | ✔ | ✔ |
RNF - 1 | Layout limpo e simples que facilite o acesso as diversas funcionalidades da aplicação sem confusão | ✔ | ✔ |
RNF - 1 | Utlização de incones para facilitar o agrupamento de informações e facilitar a navegação na aplicação | ✔ | ✔ |
RNF - 2 | Orientação da exibição de objetos, textos, logotipo na aplicação bem definidos e agradáveis ao usuário | ✔ | ✔ |
RNF - 3 | Criar a funcionalidade de interação com os menus pelo usuário | ✔ | ✔ |
Na Segunda Sprint começamos com o uso do microframework Flask usando a linguagem Python 3 para criar a nossa aplicação. Foi escolhido a base de dados relacional SQLite para construímos um pequeno banco de dados que organize e estruture as relações lógicas das informações na nossa aplicação. Dentro do Flask utilizamos o mecânismo de template para Python, Jinja2 para conseguimos fazer toda a conversação entre back e front-end na nossa aplicação.
REQUISITO FUNCIONAL_ID | REQUISITOS DA SPRINT | TAREFA INICIADA | STATUS |
RF - 4 | Criação da funcionalidade que permite que Usuários consigam criar e enviar novos informativos na aplicação de forma funcional | ✔ | ✔ |
RF - 5 | Data e Hora das postagens sempre visíveis | ✔ | ✔ |
RF - 5 | Filtro por data | ✔ | ✔ |
RF - 6 | Funcionalidade de registro e armazenamento de novos usuários na aplicação | ✔ | ✔ |
RF - 6 | Criação de Hierarquias que identifiquem os usuários dentro da aplicação. (ex.: professor, diretor, aluno e etc) | ✔ | ✔ |
RF - 6 | Criar limitação para usuários Alunos evitando que possam enviar anúncios/informativos na aplicação e que apenas visualizem os anúncios de outros usuários | ✔ | ✔ |
RF - 7 | Quando um anúncio/informativo for criado esse deverá ser único e que outros usuários consigam visualiza-lo e não diversas cópias distribuidas entre usuários | ✔ | ✔ |
RF - 7 | Apenas o usuário que criou o informativo, terá a liberdade de excluí-lo | ✔ | ✔ |
RF - 8 | Criar lógica que permita que o direcionamento dos informativos criados pelo novo Usuário seja feito de acordo com as hierarquias | ✔ | ✔ |
RF - 8 | Criar interação funcional entre três ou mais Usuários, sendo um deles usuário Aluno | ✔ | ✔ |
RNF - 4 | Construção da API para conversação entre front e back end | ✔ | ✔ |
RNF - 5 | Utilização de SQLite para banco de dados da aplicação considerando possibilidade de troca para PostGresSQL devido facilidade com o Heroku | ✔ | ✔ |
Na Terceira Sprint, já possuindo uma aplicação minimamente funcional, focamos em adicionar novas funcionalidades essênciais a aplicação. Implementamos um método de autenticação por e-mail, filtragem dos informativos por dia organizados por ordem de mais recente ao menos recente, filtro por palavra chave também em ordem e a funcionalidade de arquivar informativos. Foram feitas melhorias em alguns aspectos visuais da aplicação, principalmente na exibição dos informativos arquivados, e também feita uma revisão no modelo lógico do banco de dados conseguindo relacionar todos os papéis na nossa aplicação de forma efetiva. Implementamos o uso da ferramenta Flask-Migrate para facilitar o versionamento do esquema do nosso banco de dados caso necessário junto a ferramenta Flask-Alembic para prover as configurações e o ambiente para migração das atualizações feitas no banco de dados sem riscos as informações contidas neste. A nossa aplicação agora permite a inserção (editar), ocultamento (arquivar) e remoção dos informativos.
REQUISITO FUNCIONAL_ID | REQUISITOS DA SPRINT | TAREFA INICIADA | STATUS |
RF - 6 | Criação da funcionalidade de autenticação do cadastro do novo usuário por e-mail | ✔ | ✔ |
RF - 7 | Informativos poderão ser excluídos apenas pelos usuários que os criarão | ✔ | ✔ |
RF - 10 | Possibilidade de arquivar informativos em um campo separado e em ordem cronológica para que seja mantido um histórico de informativos | ✔ | ✔ |
RF - 8 | Informativos são enviados a destinatários específicos e apenas os usuários com os papéis selecionados poderam visualiza-los | ✔ | ✔ |
RF - 5 | Filtragem dos informativos por papéis (ex.: Diretor, Professor, Aluno e etc) | ✔ | ✔ |
RF - 5 | Criação de um mecanismo de filtro por palavras-chave em um campo de busca de fácil acesso para pesquisas rápidas | ✔ | ✔ |
RF - 5 | Criação dos mecanismos de filtragem por data, com exibição em ordem de mais recente para menos recente | ✔ | ✔ |
RF - 9 | Funcionamento da seção adm. com acesso restrito para que seja feita a administração de papéis e funções dentro da aplicação | ✔ | ✔ |
Na Quarta Sprint tinhamos como necessidade a entrega da aplicação completa, por se tratar da Sprint de fechamento do projeto desenvolvido por nossa equipe durante esse semestre. O foco principal da nossa equipe foi no desenvolvimento de todas as demais funcionalidades necessárias para a aplicação, com base nos requisitos funcionais, assim como em testes práticos dos recursos que ela dispõe para a solução do problema de perda de informação do nosso cliente. Dentro das funcionalidades necessárias, a nossa aplicação agora dispõe da possibilidade de anexar arquivos ao criar novos informativos. Na área de cadastro, agora conseguimos fazer uma seleção inicial entre funcionários e alunos da instituição, considerando o número de Matrícula ou número RA após a validação do novo cadastro. Além dos papeis, agora temos as opções de Cursos na nossa aplicação, que podem ser adicionados de acordo com os cursos existentes e devem ser relacionados aos entes de interesse na instituição para que a organização da comunicação entre o corpo docente, discente e administrativo seja efetiva. Além dos filtros de busca por data, papel e palavra-chave agora também existe a possibilidade de filtrar informativos que possuem ou não arquivos anexados. Dentro da aplicação, os informativos agora possuem a opção "Ler mais" funcional que permite ao usuário expandir todo o conteúdo dos informativos para que sejam exibidas todas as informações escritas do informativo assim como os seus arquivos anexados. Parte importante da nossa aplicação é que o seu layout agora é responsivo. Devido ao uso de um MOR/ORM (Mapeamento objeto-relacional) para gerar o nosso banco de dados, fizemos o uso do SQLite durante todo o nosso projeto, aumentando a produtividade de forma significativa e também adicionando a possibilidade de rápida migração da aplicação para outros bancos de dados. Escolhemos o banco de dados PostGresSQL como opção de uso para nossa aplicação considerando as opções dentro dos requisitos não-funcionais da nossa aplicação.
REQUISITO FUNCIONAL_ID | REQUISITOS DA SPRINT | TAREFA INICIADA | STATUS |
RF - 9 | Página de moderação (admin) funcional | ✔ | ✔ |
RF - 6 | Página de moderação (admin) com layout responsivo | ✔ | ✔ |
RF - 11 | Adicionar funcionalidade de anexar arquivos aos informativos | ✔ | ✔ |
RF - 5 | Adicionar a opção de cursos dentro da aplicação de forma funcional | ✔ | ✔ |
RF - 10 | Fazer funcional a opção de "Ler mais" para os informativos | ✔ | ✔ |