Backlog da Sprint | Tarefas | Burndown | Evolução do Backlog | Histórias de Usuários
Status da Sprint: Concluída ✔️
Na segunda sprint buscou-se aprimorar o produto através da criação e consolidação de um banco de dados relacional utilizando-se MySQL e Flask-SQLAlchemy. Para atingir um maior valor do produto, foram adicionadas diversas funcionalidades no produto na perspectiva da utilização do técnico. A versão sintética e funcional do um sistema foi acrescida primeiro da modelagem de um banco de dados relacional com duas entidades, relacionando as Ordens de Serviço aos Usuários cadastrados, ou seja, os técnicos que atenderão cada ordem. Através dessa atualização, o técnico será cadastrados com usuário e senha e terá uma visão diferenciada dos chamados, podendo atualizar e deletar os registros de ordens de serviço criados no banco de dados.
Outra mudança que vale destacar é a implementação e atualização de soluções visuais que visam facilitar a utilização do sistema pelos usuários que desejarem abrir uma ordem de serviço de reclamação de problemas. O wireframe foi pensando para criar um uso mais fluido e intuitivo para os usuários. Para isso, foram utilizados ícones, paletas de cores, bem como botões para preenchimento de algumas informações, ao invés dos formulários por escrito.
Para visualizar o Wireframe em PDF, acesse o link 🔗.
| Tarefa | Descrição | Histórias de Usuários | Prioridade | Sprint | Estimativa de Esforço | Status |
|---|---|---|---|---|---|---|
| Levantamento dos tipos de danos | Listagem dos hardware integrantes das máquinas dos laboratórios passíveis de erros e má funcionamento. | US07 | Baixa | 2 | 3h | ✅ |
| Inserção dos principais tipos de danos de hardware no sistema | Inserção dos principais tipos de danos no sistema contendo os problemas de hardware com maior probabilidade de ocorrência. | US07 | Alta | 2 | 9h | ✅ |
| Criação da Modelagem Conceitual do Banco de Dados | Criação da Modelagem Conceitual através da descrição de como os dados serão armazenados no banco e também seus relacionamentos. | US08 | Alta | 2 | 8h | ✅ |
| Criação do Esquema Conceitual através do Diagrama Estrutural de Entidade Relacional (DEER) | Criação de um modelo de mais alto nível, ou seja, que esta mais próximo da realidade dos usuários. Esse modelo pode é elaborado por meio Diagrama Estrutural de Entidade e Relacionamento (DEER). | US08 | Alta | 2 | 1h | ✅ |
| Criação do Banco de Dados SQL | Criação do Banco de Dados relacional e funcional baseado na modelagem e no esquema aprovados. | US20 | Alta | 2 | 13h | ✅ |
| Funções de ligação da aplicação com o banco de dados | Criação de funções em Python que levem os dados preenchidos pelos usuários nos campos de abertura de chamado até o banco de dados, e assim salvem esses dados de uma maneira persistida. | US21 | Alta | 2 | 12h | ✅ |
| Criação da área do Técnico | Criar uma área para o técnico administrar esses chamados recebidos com a entrada em ordem cronológica. | US09 | Alta | 2 | 12h | ✅ |
| Login simplificado para o técnico e diferenciação da interface dependendo de quem está utilizando | Possibilidade de criar usuários para o sistema de ordem de serviço para que os técnicos tenham uma maneira segura e privada de visualizar, deletar, procurar, filtrar e atualizar os chamados criados pelos usuários. | US09 | Alta | 2 | 9h | ✅ |
| Implementar facilitações visuais | Utilização de cores, ícones e outras soluções gráficas que facilitem o entendimento das informações dos sistemas para os usuários que desejem utilizá-lo. | US17 | Baixa | 2 | 3h | ✅ |
-
A partir de pesquisa com funcionários responsáveis pela manutenção dos computadores e visita aos laboratórios, foi feita uma listagem dos hardware integrantes das máquinas dos laboratórios passíveis de erros e má funcionamento. Essa tarefa teve como saída a lista de problemas de hardware que deu insumo para a tarefa seguinte, de inserção dos principais problemas no sistema.
-
Para esta etapa, foram utilizadas as informações coletadas na tarefa de levantamento dos tipos de dano para, então, inseri-los no sistema. Criou-se uma listagem de botões com opções previamente preenchidas contendo os problemas de hardware com maior probabilidade de ocorrência. Assim, os usuários têm maior facilidade ao cadastrar um desses problemas mais recorrentes. A listagem de botões contendo os danos de hardware mais comuns ficou como mostra a imagem a seguir:
-
Através da descrição de como os dados serão armazenados no banco e também seus relacionamentos, bem como com diversas discussões com o cliente sobre as suas necessidades, foi feita a criação da modelagem conceitual do banco de dados relacional. Chegou-se à conclusão que, para essa atual etapa do projeto, eram necessárias apenas duas tabelas: uma para os chamados, outra para os usuários. Essa tabelas teriam cardinalidade de 1 para N, com a chave primária da tabela de usuários sendo usada como a chave estrangeira na tabela de chamados. A partir desse conceito foi esboçado o Diagrama Estrutural de Entidade Relacional que pode ser visto na próxima tarefa.
-
Com as informações levantadas na tarefa anterior, começou-se a criação de um modelo de mais alto nível, ou seja, que esta mais próximo da realidade dos usuários. Esse modelo pode é elaborado por meio Diagrama Estrutural de Entidade e Relacionamento (DEER) e tem como objetivo estruturar de maneira visual como ficará o Esquema do Banco de Dados quando este estiver implementado na linguagem escolhida, no nosso caso, o MySQL. A seguir, como ficou o DEER após criado na ferramenta Workbench do MySQL:
-
Após a modelagem conceitual e a criação do DEER, o passo seguinte foi a criação do Banco de Dados relacional e funcional baseado na modelagem e no esquema aprovados. Para tanto, foi utilizado a linguagem MySQL para seguir o planejamento das tabelas de usuários e chamados. Vale ressaltar que etapa foi imensamente facilitada e ganhou em eficiência por contar com as informações bem fundamentadas das duas tarefas anteriores.
-
Nesta tarefa foram criadas as funções em linguagem Python para conectar o frontend ao banco de dados. Através dessas funçõesos, os dados preenchidos pelos usuários nos campos de abertura de chamado são traduzidos para comandos que persistem essas informações na tabela de chamados do banco de dados. O mesmo foi feito para a criação de login e para a área do técnico, onde ao alterar os dados interface gráfica do sistema, o mesmo é alterado no banco de dados.
-
Com as funções para conectar a interface gráfica com o banco de dados, foi possível criar uma área para o técnico na qual ele possa administrar os chamados recebidos, visualizando eles em ordem cronológica, bem como interagindo com esses dados. Dois botões permitem que o técnico ou edite as informações de um chamado, ou exclua o registro se assim desejar. A seguir, uma imagem de como ficou essa área após implementada:
-
Com a criação de uma tabela de usuários no nosso banco de dados, ficou possível criar usuários para o sistema de ordem de serviço para que os técnicos tenham uma maneira segura e privada de visualizar, deletar, procurar, filtrar e atualizar os chamados criados pelos usuários. Logo, uma das tarefas foi criar uma tela simplificada para criação dos usuários, bem como para o login. Para este, foi criado um modal que, a partir de qualquer página do sistema, é possível realizar o login. A seguir, como ficaram essas duas telas:
-
Como requisito do produto, é necessário a utilização de cores, ícones e outras soluções gráficas que facilitem o entendimento das informações dos sistemas para os usuários que desejem utilizá-lo. Neste sentido, nós criamos ícones que tornam a utilização mais intuitiva tanto para o técnico, quanto para quem for abrir um chamado no sistema. Na parte do técnico, utilizamos divisórias nas tabelas que facilitam a leitura dos registros, bem como dois ícones com cores e ícones intuitivos, sendo o verde com um uma seta circular para editar, e o vermelho com uma lixeira para apagar o registro.
Já nas páginas de abertura de chamado, foram feitas implementações gráficas desde o começo do processo. Com a escolha dos laboratórios e computadores através de ícones em formatos de portas, até a escolha dos computadores com ícones em formato de monitores.
Como a metodologia ágil Scrum tem como princípios a adaptabilidade e o processo iteraitvo, mudanças ocorrem para que o produto chegue ao final da Sprint com o maior valor possível. Para isto, foram necessárias alterações de tarefas que geraram 4 atualizações de versão do Backlog do Produto:
| Backlog 3.0 10% █▒▒▒▒▒▒▒▒▒ |
|---|
| Levantamento e listagem dos tipos de danos |
| Criação da Modelagem Conceitual do Banco de Dados |
| Criação do Esquema Conceitual através do Diagrama Estrutural de Entidade Relacionamento (DEER) |
| Início da Criação do Banco de Dados |
| Criação da área do Técnico para diferenciar a interface dependendo de quem está utilizando |
| Backlog 3.22 99% ██████████] |
|---|
| Levantamento e listagem dos tipos de danos |
| Inserção dos principais tipos de danos no sistema em lista hardware, software, rede |
| Criação da Modelagem Conceitual do Banco de Dados |
| Criação do Esquema Conceitual através do Diagrama Estrutural de Entidade Relacional (DEER) |
| Criação do Banco de Dados SQL |
| Funções de ligação da aplicação com o banco de dados |
| Criação da área do Técnico |
| Login simplista para o técnico com diferenciação da interface dependendo de quem está utilizando |
| Implementar algumas facilitações visuais (hard, software, rede, mouse, monitor etc) |