Com o fim da Sprint da semana passada, os integrantes da equipe repararam que houve uma maior produtividade usando os horários fixos de trabalho no projeto para a semana, porém esta produtividade ainda não é o suficiente para recuperar o atraso.
Mudanças no menu tiveram que ter sido feitas por conta da descontinuação do método setDrawerListener que estava sendo utilizado na construção da tela. O problema que a equipe teve com a captação de imagens, que ficavam pixeladas ou não eram desenhadas, foi resolvido nesta semana tendo como resolução não atribui-la diretamente a um bitmap, mas sim a uma variável Uri para que então seja feita a conversão para evitar a perda de qualidade.
No decorrer dos últimos dias, a equipe percebeu a necessidade de atualizar nosso banco de dados (e seus diagramas) por conta de mudanças que ocorreram desde o planejamento da implementação do aplicativo. Além disso, grande parte do que foi implementado no aplicativo começou a sofrer mudanças para se adaptar ao novo funcionamento da API, que precisou ser modificada para se adequar à arquitetura RESTful. Após revisar o sistema, foi averiguado que a modelagem atual do sistema não cumpria os requisitos de segurança, ou seja, haviam muitas brechas de segurança que a criptografia implementada e a modelagem implementada não asseguravam. O sistema, então, foi remodelado, descartando a criptografia, já que, na nova modelagem, ela não é mais necessária.
A grande brecha de segurança foi a desconsideração de que todo o código disponibilizado no aplicativo pode ser descompilado e visualizado, sendo assim, a criptografia não fazia efeito algum para a segurança do sistema. Outros problemas envolviam escolhas errôneas na modelagem do sistema, como por exemplo, não associar o token a um usuário, permitindo que um mesmo token possa acessar os recursos do sistema inteiro, inclusive os recursos de todos os outros usuários. Outra escolha errada para o desenvolvimento da API foi a criação de status próprios do sistema, sendo que isso acaba fazendo com que a API deixe de ser da arquitetura REST, além de vários outros erros que distanciavam o sistema cada vez mais da arquitetura base almejada. Em uma arquitetura REST, os status do próprio HTTP devem ser respeitados e utilizados, assim como os vários padrões de criação dos requests HTTP, como por exemplo, utilizar-se dos métodos corretos para os pedidos, utilizar-se dos headers corretos para a autenticação etc.
Após revisar o capitulo “Tecnologias e ferramentas”, percebemos que não foram documentadas as ferramentas que estão sendo utilizadas para a comunicação entre a equipe, os professores e representantes de ONGs, além disso, a introdução para as ferramentas de desenvolvimento estava confusa, por isso foram refeitas.
De: Isabelle Neves
Nenhum comentário:
Postar um comentário