Neste capítulo será feita a discussão de resultados acerca da utilização da metodologia Scrum solo, as validações ao projeto (nomeadamente a descrição dos testes feitos à Web API e algumas das suas aplicações desenvolvidas), e as vantagens que trouxe para o cliente.
8.1. Utilização do Scrum solo
A utilização do Scrum solo durante este projeto contribuiu para o seu sucesso, apesar dos contratempos existentes e adaptações que foram necessárias. Devido à ausência de artigos científicos acerca desta metodologia, e ao interesse para contribuir para esta área, foi submetido um artigo para a edição de 2018 da conferência CAPSI que se focava na descrição da aplicação do Scrum solo e algumas adaptações necessárias para casos de alto nível de integração. Este paper, que estava em desenvolvimento, foi aceite como póster. Foi também elaborado um artigo que apresenta uma metodologia para converter código de uma aplicação para uma Web API, com base na experiência descrita neste documento.
8.2. Validações do projeto
Com o intuito de fazer a validação do projeto, foi utilizado como parte do projeto vencedor da edição de 2018 do evento TecTalks e foram criadas 3 aplicações que consumem a Web API, com finalidades diferentes:
• Aplicação para autorização de documentos de venda; • Website para criação de documentos de compra;
• Integração com o Microsoft Outlook para visualizar pagamentos pendentes.
Estas aplicações foram apresentadas e demonstradas ao público, através de eventos/trailers produzidos e organizados pela empresa para publicitar as novas funcionalidades.
A aplicação para autorização de documentos de venda (figura 29) permite ao utilizador fazer o login e ligar-se ao ERP remotamente para visualizar e autorizar documentos de venda em casos em que o montante é alto e necessita aprovação.
45
Figura 29- UI da aplicação para autorização de documentos de venda
O Website para a criação de documentos de compra possui uma página de login e uma página para a criação dos documentos, que é o resultado da simplificação da janela do ERP que tem o mesmo propósito. Esta simplificação e a utilização de ferramentas diferentes para a sua construção, resultaram num aumento da fluidez da atividade e uma redução do tempo de espera, permitindo proporcionar uma melhor experiência ao utilizador.
46
Figura 30- UI do website para criação de documentos de compra
Finalmente, foi feita uma integração com o Microsoft Outlook com o propósito de facilmente visualizar os pagamentos pendentes de qualquer um dos fornecedores (figura 31). Este add-in permite ser apenas ativado caso algumas palavras-chave sejam detetadas num email. Nos casos relevantes será adicionado no topo do email uma barra que permite abrir uma interface onde o utilizador pode fazer a sua autenticação e depois, pode verificar informações relevantes acerca dos pagamentos pendentes. Na tabela onde a informação está a ser apresentada (figura 32), a morada possui um link que direciona o utilizador para o Google Maps.
47
Figura 32- Interface de visualização de vendas pendentes
Para promover uma aplicação melhor e uma melhor experiência de utilização, é importante fazer testes à aplicação desenvolvida. A existência de testes é essencial para a manutenção e evolução das aplicações. A Web API e o gerador de código não são exceções.
Os casos de uso do gerador de código são mais limitados, pelo que, foi possível fazer diversos testes manualmente. Juntamente com a documentação, foram criados tutoriais que ajudam o utilizador passo a passo em diferentes cenários. Caso as instruções sejam rigorosamente seguidas, existe uma baixa probabilidade de um erro se suceder, e mesmo para esses casos, foram indicadas ações a tomar para conseguir identificar e retificar o problema.
Para o caso da Web API, existem muitos mais casos de uso possíveis a testar, sendo que seria praticamente impossível a sua execução manual. Face a esta impossibilidade, foi criada uma solução para Web testing e load testing, disponível no Visual Studio.
Um Web test consiste numa sequência de atividades de um utilizador, por exemplo (tal como representado na figura 33), fazer a autenticação e buscar um recurso do servidor. A vantagem destes testes é a facilidade de utilização, configuração disponível, e o facto de estarem baseados em XML. Isto permitirá no futuro adicionar ao gerador de código a funcionalidade de criar Web tests semi- automaticamente (os dados concretos, tal como identificadores, terão de ser adicionados manualmente conforme o caso).
48
Figura 33- Exemplo de um Web test
Os Web tests são importantes para a gestão individual de certos casos. No entanto é também importante fazer testes de carga, para medir o desempenho da Web API. Esta solução permite criar cenários de teste com diversas opções configuráveis tais como: nº de iterações (número de vezes que o Web test irá ser executado por cada utilizador), utilização de “think times” (simulação do tempo que o utilizador leva a fazer uma operação), utilizadores concorrentes (número de utilizadores a fazer o Web test), distribuição dos testes (baseados pela ordem sequencial ou pelo ritmo de cada utilizador), tipo de ligação à internet, e, finalmente browser.
Na figura 34, apresenta-se a lista de tempos de resposta de diversos pedidos à Web API, juntamente com os tamanhos da resposta. O pedido do token, é o pedido mais demorado, sendo que é feita a abertura da plataforma do ERP, que contém os seus motores, módulos, e submódulos. Após este podido na fase do login, pode-se utilizar o token gerado para fazer outros pedidos, tais como listar os documentos de compras existentes no ERP, ou listar os documentos de vendas pendentes. É também importante mencionar o facto que todos os pedidos que podem ser guardados em cache (pedidos do tipo GET), após o primeiro pedido, passam a ter tempo de resposta inferiores a 15 milissegundos.
49