Evaluation

1. Client Feedback

"The builds are a complete success and all applications are ready to ship to to windows store. The compilation pathway is incredibly impressive and brings together all of the teams works. Congratulations to the Compiler team and all of the teams."

- Dean Mohamedally

We were able to deliver a successful final product that met our project goals and expectations and received positive feedback from our clients. The successful compilation and integration of all the teams' work into the final product was a significant accomplishment, and we are proud of our contributions to this effort.

2. Critical Evaluation

User Experience

Throughout the project, we focused on improving the user experience of the MotionInput software and the MFC applications that integrate with it. By creating intuitive and user-friendly interfaces, we aimed to make it easy for users to interact with the software and achieve their desired goals. We believe that our efforts in this area were successful, and the positive feedback we received from our clients supports this conclusion.

Functionality

Our team was responsible for creating MFC applications that integrate with the MotionInput software, and we worked closely with other teams to ensure that the software as a whole was functional and met the needs of users. We carefully tested and debugged our applications to ensure that they worked as intended and were reliable for users.

Stability

Our team was responsible for creating MFC applications that integrate with the MotionInput software, and we worked closely with other teams to ensure that the software as a whole was functional and met the needs of users. We carefully tested and debugged our applications to ensure that they worked as intended and were reliable for users.

We also conducted rigorous testing and quality assurance checks on the software before deployment. We employed a variety of testing methods, including functional testing, integration testing, and user acceptance testing. Our client was involved in the user acceptance testing, which allowed them to confirm the stability and functionality of the software. Any issues or bugs that were identified during testing were promptly addressed and resolved.

Overall, our approach to testing and feedback allowed us to ensure that the software was stable and met our client's needs. We were able to deliver final products that received positive feedback from our client and was ready for deployment to the Windows Store.

Efficiency

We worked to optimize the performance of the motion detection algorithms and the MFC applications to ensure that they were efficient and responsive by taking on client feedback. By carefully managing system resources and optimizing the software's algorithms and data structures, we aimed to create a fast and responsive user experience.

Compatibility

We made sure that the software was compatible with a wide range of hardware and software configurations, and we tested the software on multiple platforms to ensure that it worked as intended. By ensuring that the software was compatible with a wide range of configurations, we aimed to maximize its usability and reach.

Maintainability

We implemented a flexible and modular architecture for the software, which we believe will make it easier to maintain and modify in the future. By using JSON to store configuration information and helper functions to launch MFC settings and help text files, we aimed to create a more flexible and maintainable software system.

Project Management

Throughout the project, we worked closely with other teams to ensure that the project was well-managed and that everyone was on track to meet their goals. We held regular meetings and provided clear communication to ensure that everyone was on the same page and that any issues were quickly identified and addressed. Overall, we believe that the project was well-managed, and we are proud of our contributions to its success.

Since each teams project was based on implementing a particular solution and function to MotionInput, the teams focused on coding their specific functionality without much code commonality between each other's work. With different coding styles, this could have resulted in an inconsistent codebase. That being said, each team worked off of common MFC templates and common MotionInput repository so changes could be implemented as each team needed them which served to largely reduce this problem

[1] “Improve the front end to make full use of the backends configurability. Dynamically creating new events based on the users desired - mapping events and gestures to handlers as per users request.” A previous cohorts team had evaluated the front end of MotionInput to be lacking in dynamic creation based on user desire, by bringing together the Custom Gesture Recording team with the Compatability Layer team and providing help in the MFCs, we were able to create custom hotkey settings for multiple projects

References: [1] https://students.cs.ucl.ac.uk/2021/group32/evaluation.html#final-moscow

3. List of Known Bugs or Problems for Future works

Even though we finished all our tasks successfully, we continued to investigate the code and found areas where we could make further improvements. Although we had completed everything we set out to do, we recognized that there was still room for future enhancements. We identified potential areas for improvement and made plans for addressing them in future iterations or updates.

  • For future work, MotionInput 3.2 functionality is currently split among many different projects, merging projects to a central backend is a future project to undertake. The top priority for future branch merging is PseudoVR and Team 24 branch.
  • Similarly, MFC projects that are currently deployed have a console bug that means a terminal window briefly flashes on screen when launching MotionInput from an MFC.
  • MotionInput hardcodes both its own name and the name of the MFC accessing it.
  • MotionInput currently uses lengthy if, elif blocks to identify which MFC should be in use and to open the correct one, a solution that utilises a JSON version has been created in a recent patch but has yet to be rolled out to every MFC and build of MotionInput.
  • MotionInput is capable of opening multiple instances of itself for some builds, an MFC side preventative measure to this has been implemented for some MFCs but is yet to be rolled out for all.
  • All the bugs mentioned above has been fixed in motioninput main branch and FacialNavigation MFC main branch but has yet to be rolled out to every motioninput branch and MFC.

  • There is yet to be written error handling for the new MFC JSON naming format that fixes the problem of hardcoding. This has not been a problem till now as the error has yet to be encountered in any build but the error handling code should still be included and space for it to be included has been detailed in the FacialNavigation MFC code.

4. MoSCoW Revisited

5. Individual Contributions