Introdução

Os conceitos utilizados no projeto foram aqueles aprendidos na cadeira de Engenharia de Software do curso Sistemas de Informação da Universidade Federal de Pernambuco. Dessa forma, nesta seção vamos abordar um pouco do que foi pensado e usado na hora da escolha e construção da arquitetura, bem como os conceitos aplicados no desenvolvimento.

Testes de Software

• Utilizamos testes para executar um programa com um conjunto finito de casos, com o objetivo de verificar se ele possui o comportamento esperado. Dessa forma, os testes aplicados no projeto foram testes de unidade, quando se testa uma pequena unidade do código, como uma classe. Dessa forma, os testes foram aplicados em todas as funções criadas no back-end para verificar seu comportamento e então realizar sua validação. Portanto, testes podem ser usados tanto para verificação quanto para validação de sistemas, pois verificamos se estavam atendendo à especificação, bem como se atendiam às necessidades de nossos clientes.
• Realizamos também testes de validação e aceitação com nossos clientes, isto é, tanto Marlos quando Vinícius da SEGEL realizaram ações no protótipo do sistema, garantindo que houvesse a validação inicial. Dessa forma, foi possível consertar os erros apresentados e também realizar melhorias para garantir um desenvolvimento melhor da aplicação.
• O teste de usabilidade também foi feito por todos os integrantes do grupo para garantir que a interface fosse intuituiva, os tipos de dados aceitáveis e também fosse rápido na navegação para realizar a reserva.

Vale ressaltar que os testes feitos para a aplicação em si, ou seja, os testes de unidade seguem os princípios FIRST, além de testar cada função do CRUD, com mais ênfase nas reservas, isto é, verificar o choque de horário, a criação, a listagem, possíveis erros e bugs dos usuários, entre outros. Ademais, também há testes simples para usuários e áreas, como a atualização de um usuário, a remoção do usuário para apenas desativá-lo e não apagar do banco; já no caso das áreas temos a verificação de acesso para que somente um admin consiga criar, atualizar ou deletar, bem como o resultado de cada operação em si. Para saber mais sobre os nossos testes basta acessar a seção testes.

Gerência de Projetos

Como qualquer projeto, é necessário o uso de práticas e atividades de gerência de projetos, por exemplo, para negociação com os clientes, gerência de recursos humanos, gerência de riscos, cumprimento do prazo, dificuldades, etc. Dessa forma, o projeto como um todo foi bastante monitorado e envolveu diversos stakeholders, com foco em Marlos do STI e os gerentes da SEGEL, como Vinícius. Além disso, inúmeros artefatos foram criados, em que todos podem ser verificados e analisados na seção "Artefatos do Projeto" no canto direito de nossa wiki.

Processo de Desenvolvimento de Software

A metodologia adotado pelo grupo seguiu os conceitos de uma metodologia híbrida, levando alguns conceitos das metodologias tradicionais e também das metodologias ágeis. Embora a entrega fosse constante e em pequenas partes para revisão, outras atividades só eram feitas após o término da anterior, como os testes. Decidimos seguir esse padrão para garantir maior estabilidade e também avançar em nosso próprio ritmo. Assim, ao mesmo tempo que a aplicação ia sendo entregue de pouco em pouco e melhorando, os testes só vieram na etapa final para garantir que tudo fosse testado. Da mesma forma, a validação com o cliente se seguiu ao término do prótipo e também ao término da aplicação. É possível saber mais sobre ao acessar nossas práticas ágeis.

Modelo de Software

O grupo adotou o modelo de "Forward Engineering", isto é, Engenharia Avante, em que focamos primeiro na criação de um modelo, no entendimento do problema, para desenvolver o protótipo e só depois partir para a implementação do código, seguindo o nosso modelo criado. Dessa forma, ficou muito mais simples o desenvolvimento por já termos um guia ao nosso lado, acelerando a construção e otimizando o processo.

Classificação de Sistema

Nossa aplicação atualmente se encaixa na classificação de um Sistema C (Casual), pois ele não é feito para sofrer uma pressão tão alta de qualidade, isto é, ele não foi criado para ser um sistema perfeito que põe vidas em risco, ou que acaba por movimentar toda a rede de negócios de uma empresa. Por outro lado, é um sistema de gerenciamento de reservas para facilitar a reserva de usuários e fornecer informações com maior transparência, além de garantir uma melhor visibilidade para os gestores da SEGEL ao analisar a movimentação das reservas. No entanto, vale ressaltar que nosso sistema atual ele é entregue como Sistema C, porém, há possíveis ideias futuras para integrá-lo ao FADE e gerar captação de recursos, podendo vir gerar lucro para a SEGEL e então permitir novas melhorias. Nesse cenário adiante, o sistema deverá sofrer melhorias para esta adaptação e então se classificará como um Sistema B, focando em negócio ao mesmo tempo que também atende aos requisitos casuais.

Princípios do Projeto

• Nosso projeto adotou bastante a integridade conceitual, isto é, focando apenas em funções e funcionalidades que fazem sentido e agreguem valor. Logo, não há nenhuma desconectada ou um grande amontoado de funções que não façam sentido para nosso propósito, a gestão dos recursos esportivos da SEGEL. Temos apenas funções e funcionalidades simples de criação, atualização, listagem e remoção de usuários, espaços e reservas. Ou seja, o CRUD padrão para cada entidade envolvida.
• Outro princípio básico é o de coesão, logo, garantimos que para cada etapa do CRUD seja apenas uma única função. Uma função para criar usuário, outra para atualizar, outra para listar e outra para deletar. Seguindo essa mesma lógica, vamos ter esse passo a passo para espaços e também para reservas. Vemos então que todo o projeto foi criado e já pensado para garantir um fácil entendimento e também manter a organização tanto no desenvolvimento quanto na explicação.
• O princípio de acoplamento foi utilizado na criação dos nossos Schemas, em que temos um acoplamento de uma estrutua de cada entidade sendo herdada para outras estruturas menores para a utilização em sua respectiva função. Dessa forma, podemos garantir que tenhamos um modelo geral para cada entidade e a depender da função utilizada nós possamos ocultar ou não determinadas informações, garantindo que certos campos se mantenham fixos, como o CPF de um usuário ou o criador de um determinado espaço da SEGEL.

Podemos ver então que o projeto segue alguns princípios SOLID de modo geral e busca sempre usar as boas práticas aprendidas em Engenharia de Software. Além disso, a organização de pastas foi algo bastante trabalhado então dentro do back-end ou do front-end podemos encontrar facilmente o que queremos, uma vez que cada pasta possui o nome de sua entidade e cada arquivo dentro segue a mesma lógica para os outros. Por exemplo, o manager.py é onde vamos armazenar as funções de modo geral e o router.py é onde vamos ter as chamadas para nosso CRUD executar a rota.

Arquitetura de Software

Nosso grupo escolheu adotar uma arquitetura de camadas em que fosse possível trabalhar com cada uma separadamente. Dessa forma, temos a divisão entre o front-end, o back-end e nosso banco de dados. Assim, podemos dizer que trata-se de uma arquitetura de 3 camadas pela existência da nossa interface gráfica, a parte do cliente; temos também nossa aplicação, onde vão as lógicas do negócio; e por fim o banco de dados operando separadamente. Dessa forma, nós integramos cada um deles para fazer a aplicação funcionar, fazendo com que o front-end se comunique com o back-end e então possa armazenar e consultar valores do banco de dados.

Vale ressaltar também que no front-end a arquitetura MVC facilitou bastante na criação, de modo que temos classes responsáveis pelos botões, rolagens janelas, entre outros, ou seja, representam as visões da arquitetura; e as controladoras seriam o tratamento e interpretação dos eventos que ocorrem em cada uma delas, isto é, definir o que aconteceria ao clicar em um botão específico, determinando as ações futuras.