Developing the next iteration of Qs

Abstract

Qs er et køsystem laget for å lette prosessen med å godkjenne og få hjelp til øvinger. Det har røtter tilbake så SKS (Smart Køsystem). Og dette vil være den andre iterasjonen av systemet kjent som Qs. Qs er et todelt program med en front-end webklient og back-end-server. Den gamle iterasjonen av Qs bruker NodeJS back-end og AngularJS front-end. Vi arvet et prosjekt som hadde blitt jobbet med av tre tidligere grupper, som bruker Java back-end og React front-end. Vår jobb var å rette opp eventuelle feil, og gjøre systemet klart for produksjon. Målet for produkteieren, 3D Motion Technologies, er å gjøre Qs kommersielt levedyktig. I løpet av startfasen skjønte vi raskt at den nye bakenden hadde arvet noen alvorlige designfeil fra det gamle systemet. I tillegg var implementeringen svak og trengte betydelig arbeid. Vi utformet derfor en ny backend-database, en ny RESTful HTTP-API, implementerte et rammeverk for tilkoblingssamling, utvidet WebSocket-tjeneste og drastisk forbedret ytelse. For å velge det riktige rammeverket for tilkoblingssamlinger til databasen, gjennomførte vi omfattende undersøkelser og kjørte referanser for å verifisere ytelseskrav. Resultatet av vårt arbeid på baksiden resulterte i at gjennomsnittlige svartider ble redusert til 1/10 av det opprinnelige prosjektet. Den forrige gruppen som jobbet med dette prosjektet gjennomførte brukertester som ga klare forbedringspunkter. Klienten måtte også oppdateres for å møte funksjonaliteten som tilbys av den nye back-enden. Stilarkene på klienten er re-implementert ved hjelp av moderne CSS-Grid for å forbedre bærbarheten og for å gjøre systemet lettere å vedlikeholde. Nye funksjoner som chat, innebyd romtegner, profilbilder og muligheten for å ringe en gruppe for videochat er lagt til. Covid-19 gjorde testing av systemet til en utfordring. Imidlertid klarte vi å gjennomføre to brukertester i stor skala med rundt 80 deltakere. Dette ble gjort for å verifisere både ytelsen til back-enden under en moderat og realistisk belastning, og for å få tilbakemelding på endringene som ble gjort i brukergrensesnittet. Systemet vi leverer er fortsatt litt grovt rundt kantene. Spesielt bør WebSocket-tjenesten re-faktoreres for å være vert for flere endepunkter, noe som vil føre til mindre minnebruk. I tillegg har redigering av øvinger potensielle problemer som bør fikses. Vi tror imidlertid at dette systemet er i en tilstand der det er klart til å erstatte den gamle versjonen av Qs. Den har flere funksjoner, bedre ytelse, og vi tror den tilbyr en overlegen mobilopplevelse.

Qs is a Queue System made to ease the process of approving and getting help for exercises. It has roots back so SKS (Smart Køsystem - Smart Queue System). And this will be the second iteration of the system known as Qs. Qs is a two-part application with a front-end web client and back-end server. The old iteration of Qs uses NodeJS back-end and AngularJS front-end. We inherited a project which had been worked on by three previous groups, which uses Java back-end and React front-end.

Our job was to rectify any bugs, and make the system ready for production. The end goal for the product owner, 3D Motion Technologies, is to make Qs commercially viable.

During the exploration phase we quickly realized that the new back-end had inherited some severe design flaws from the old system. Additionally the implementation was lackluster and needed significant work. We therefore designed a new back-end database, a new RESTful HTTP-API, implemented a connection pooling framework, extended WebSocket service and drastically improved runtime performance. In order to choose the correct connection pooling framework we conducted extensive research as well as running benchmarks to verify performance claims. The result of our work on the back-end resulted in average response times being reduced to 1/10 of the inherited project.

The previous group who worked on this project conducted user tests which stated clear points of improvement. The client also had to be updated to meet the functionality offered by the new back-end. The style sheets on the client has been re-written using modern CSS grid to improve portability and to make the system easier to maintain. New features such as chat, room editor, user photos and the possibility of calling a group for video chat have been added.

Covid-19 made testing the system a challenge. However, we managed to conduct two large scale user test with around 80 participants. This was done to verify both the performance of the back-end during a moderate and realistic load, and to get feedback on the changes made to the user interface.

The system we are delivering is still somewhat rough around the edges. Specifically the WebSocket service should be re-factored to host multiple endpoints to reduce memory strain. Additionally, editing exercises has potential issues that needs to be sorted out.

However, we believe that this system is in a state where it is ready to replace the old version of Qs. It has more features, better performance and we believe it offers a superior mobile experience.