Evaluation



Summary of Achievements

Requirements

ID Requirement Priority State Contributors
1 Time machine shall have users logon to connect to the system using their current credentials (i.e. email) Must Ryan, Jay
2 Time machine shall have a database which stores these user’s accounts with their passwords hashed in order to access stored data related to them Must Giorgio, Jay
3 Time machine shall be able to assign different level of permission to users limiting which features they can access depending on what role they have in the company Must Giorgio, Jay
4 Time machine shall have a page for creating a new account upon a user’s first time using the site Must Ryan, Jay
5 Time machine shall have a page to reset the password if the user has forgotten by utilising their ATOS email Should Ryan, Giorgio
6 Time machine shall be able to give the user of form to fill in when they want to submit an overtime request making use of textboxes and combo lists, and store these in a database Must Ryan, Giorgio
7 Time machine shall have the feature of adding favourite WBS codes which can be used when submitting an overtime request, which can be chosen from a list Should Ryan, Giorgio
ID Requirement Priority State Contributors
8 Time machine shall have the feature of being able to edit a user profile where they can submit a request to change their name, address and email which can overseen by a user with a high level of permissions Must Ryan, Giorgio
9 Time machine shall email users once the pre-approved overtime has been completed informing them of the need to go on Time Machine and confirm the anticipated overtime specifics matches up to what happened Should Ryan, Giorgio
10 Time machine shall have a tab which shows a summary of their overtime request and then for each request a link to page which enables them to enter the details of what actually and a textbox to supply a comment explaining any difference in time Must Ryan, Giorgio
11 Time machine shall have a tab which shows all of the overtime requests that have been approved and confirmed by the user Should Ryan, Giorgio
12 Time machine will be able to allocate certain users with the correct permissions as an approved for a selection of other users Must Ryan, Giorgio
13 Time machine shall have a tab for approvers to see the overtime requests of the users they’re overseeing with a button to begin Must Ryan, Giorgio
14 Time machine shall have a page for the approvers which show a summary of other users overtime request and then radio buttons to decide whether or not to approve the request with space to add comment before they submit Must Ryan, Giorgio
ID Requirement Priority State Contributors
15 Time machine shall allow approvers to generate overtime reports based on the information selected by users using simple filters specifically the date, and the ability to send these monthly to users on request Should Ryan, Giorgio
16 Time machine will be able to allocate certain users with the correct permissions as an administrator. Must Giorgio, Jay
17 Time machine will have a page for administrators to view and edit all users, as well as the ability to create new users specify emails which can be used when creating accounts and what roles these users will have as well as their personal information Should Ryan, Giorgio
18 Time machine will allow administrators to transfer users from one group i.e the supervision of one approver (team leader) to another Must Ryan, Giorgio
19 Time machine will allow administrators to control the payment options for roles and if need be individual users Should Ryan, Giorgio
20 Time machine will allow administrators to see an overview of all the team/groups will the ability to edit it Must Ryan, Giorgio
21 Time machine will be able to link approved overtime requests to ESS with the payment changes by administrators noted as well Must Ryan, Giorgio

Challenges

Incomplete Features

  • We did not manage to provide a mobile version of our application due to time constraints and further security concerns.
  • We were not able to set up regular meetings with our client(s) due to their busy workloads and ended having to switch to a different ATOS employee to act as our client.
  • We additionally had a problem in being able to ensure that all team members were doing an even amount of work.

Work Packages

  • Version Control (Git via Github)
    This was used to store the codebase for our frontend, backend, and project website. This was done to make it easier to collaborate on the codebase.
  • Voice over IP (Discord)
    This was used to communicate with each other when we were not at university so that we could still have meetings and discuss important topics.

Critical Evaluation

  • Architecture Design
    The architecture of our project follows the standards that have been set by many other web applications with separate backends and frontends with an API to be used by other external applications and therefore it enabled to create an application that was fit for purpose and easy to set up for our client’s use.
  • User interface design and user experience
    The user interface of the front end of our application was designed to be an improved version of the time machine application. This was a success as we made it more aesthetically pleasing and we made it even more usable as we made more of the elements have increased visibility making easy to figure out what to do without having to look at a user guide
  • Functionality
    Our version of time machine was able to offer all of the same functionality as the previous version of time machine (to our knowledge) as well as additional functionality as requested by our user such as the various spreadsheet generation options. These functionalities can also be accessed from outside of the application due to the fact that the backend is coupled with an API.
  • Stability
    The web application has been deployed in a complete status for several weeks now and has not been taken down even when multiple ATOS employees were using it concurrently. To our knowledge there are no methods a user can employ that could cause our server to crash from using our user interface or API either.
  • Efficiency
    Extensive manual testing was done on the Google Chrome web browser so we can confirm that all functionalities work on it. We additionally did some testing on Mozilla Firefox and Opera and all functionality appeared to be operational too. However we know that there will be a lot of problems on Internet Explorer as the MaterializeCSS library that we used does not support Internet Explorer itself.
  • Compatibility
    The architecture of our project follows the standards that have been set by many other web applications with separate backends and frontends with an API to be used by other external applications and therefore it enabled to create an application that was fit for purpose and easy to set up for our client’s use.
  • Maintainability
    The method used to deploy our web application sets up all packages that are required and sets up the backend as its own service so that it is easy to restart if necessary (such as deployment). Deployment is also done automatically when a commit is pushed to the production branch so that nothing on the server needs to be changed with the exception of updating packages if necessary for any new features.
  • Evaluation of Testing
    For our application we made use of unit tests which are applied to the backend test to make sure that all of the functions still work as intended by creating an artificial connection to the database. This does mean that we don’t test for any faults with the database and the connection to it, but we do have the tests being automated when a commit is pushed to the testing branch.
  • Project management
    We feel as though the project has fairly well managed throughout the whole process. All of the members have consistently had tasks to do, and after they had finished they were quick to be provided with their next task. However the time taken for each task was underestimated quite a bit which resulted in some additional unnecessary pressure.

Future Work