Evaluation

Bug List

Our team utilises GitHub issue tracker to keep track of bugs and fixing progress. We did not use JIRA issue tracker as its isolated from the code base on Github.

Upon completion, we are proud to say we have fixed all known bugs and there is none left in our issue tracker.

On the right, we provide a snapshot of issue list on 5 Apr, 2020. All 3 of them being documentation related issues.

Achievements - MosCow List Status

ID	Description	Priority	State	Contributors
1	View all types of OER	Must	☑️	Patrick
2	Suggest relevant OERs and show them below the OER that is currently on display	Must	☑️	Patrick
3	Play or pause an OER video	Must	☑️	Patrick
4	View a specific OER and its details when users press it	Must	☑️	Patrick
5	Bookmark a specific OER	Must	☑️	Patrick
6	Add notes to the OER when they are on display	Must	☑️	Patrick / Felix
7	Show the person or organisation who uploads the OER material	Must	☑️	Patrick
8	Search X5GON OER collections for keywords	Must	☑️	Patrick
9	View their browsing history	Must	☑️	Patrick
10	Full screen (focus) mode to view OERs	Must	☑️	Patrick
11	Rate an OER by pressing the like and dislike button	Must	☑️	Patrick
12	Login and logout of their accounts.	Should	☑️	Patrick
13	Buffer users’ notes for a specific OER and send them to the backend of X5GON.	Should	☑️	Patrick
14	Preload the video shown on the lists for responsiveness.	Should	☑️	Patrick
15	Provide different main pages, including trending, subscribed contents.	Should	☑️	Patrick / Felix
16	Create a simulated backend to pre-develop certain features	Should	☑️	Patrick
17	Deploy this software on different platforms, e.g. iPhone, iPad	Could	☑️	Patrick
18	Allow users to report inappropriate content	Could	☑️	Patrick
19	Continuous Integration with Travis	Could	☑️	Patrick
20	Introduce unit testing to the Application	Could	☑️	Felix / Patrick
21	Have captions or translations for captions	Won’t
22	Allow users to upload OER from our app	Won’t
23	Allow users to collaborative edit notes	Won’t
24	Allow commenting on OER	Won’t
25	Show users’ note to other users	Won’t
26	Keep suggesting the same OER to same user	Won’t
Key Functionalities:			100 %
Optional Functionalities:			100 %

^{*Certain modifications are made to the MoSCoW list upon mutual agreement with the client during the project.}

We are happy to present our product with 100% completed MosCoW requirement. We recognise the hard work and dedication our team has made throughout the development process.

Achievements - Individual Contributions

Part Of Project	Patrick Wu	Yinrui Hu
Client Liaison	80%	20%
Requirement Analysis	60%	40%
Research	90%	10%
UI Design	50%	50%
Prototyping	30%	70%
Programming	80%	20%
Documentation	10%	90%
Presentation	50%	50%
Blog	70%	30%
Testing	10%	90%
Bi-Weekly Reports	70%	30%
Project Website	80%	20%
Poster Design	80%	20%
Video Editing	80%	20%
Overall Contribution	60%	40%
Main Roles	Lead Developer, Lead Researcher	Tester, UI Designer, Video Editor

As a team lead, I am very delighted to see Yinrui made a solid 40% of contribution to the project.

Critical Evaluation of the project

We conduct thorough investigation of the work we have done, and evaluate them for continuous improvements in future projects.

User Interface and Experience

We adopted a similar feed based UI from other video service providers instead of education providers. This yields better results from our perspective, as this hides tedious information from users and presents key information in a feed way. It was generally praised that this type of UI gives user much familiarity to what they have used before, and they are getting used to using it really quick. However, some does point out there should probably be bits of innovation which differentiate our app to the biggest video provider. We put a lot of work into making UI responsive, and user-friendly with custom animations and effects in our application. For more information, checkout User Acceptance Testing.

In all, We give ourselves Good for our UI work.

Functionality

With our backend in active development, we made our best attempt to mock up APIs and write our own backend to develop features that were intended to have in the MoSCoW requirement list. The application we are delivering covers 100% of all MoSCoW requirements and with extendable and easy-to-develop backend API support modules. Within our team, we have hand tested and presented every functionality in the technical video to make sure they are working as intended.

We give ourselves Very Good for our functionality completion.

Stability

Our team followed rigorous and extensive testing procedure throughout our development cycle. We are happy to archive 90%+ code coverage including all UI components and 85%+ documentation coverage as a client-based application. Not to mention, we also have CI/CD, automated document generation, formatter and linter on Git hook setup to ensure the stability of our application. With such measures, we are able to deliver to good confidence on the stability of our product.

We evaluate ourselves to be Very Good from a Stability perspective.

Efficiency

Performance and efficiency has been a key part of our concerns throughout the project cycle. This is a major reason why we adopted Swift as our main development language. Throughout our development process, we used Instrument, a profiler made for iOS applications to keep track of the network and CPU load of our application. When there is an improvement can be made, as stated in the Multi-Threading and Task Queueing section, we made our best effort to utilise technologies we have to make it faster. We also adopted predictive pre-fetching and pre-loading techniques to flatten the network curve. All these measures are worthwhile as we present you our performance testing results, which is 100% faster than similar applications, taking half its time to perform most actions.

We think we have done a good job and give ourselves Very Good for these optimisations done due to efficiency concerns.

Compatibility

As this project started with Swift 5, we considered certain aspects of backwards compatibility to make sure we can run our application on relatively older devices. For newer features, we used #available tag provided in Swift to optionally activate some of them when they are supported. However, due to design, implementation and time frame concerns, we were not able to rewrite some parts of our application to make it backwards compatible to iOS 11.0-. We conducted testing with past 3 OS images on our CI platform, Travis. However, it slows down our deployment process significant if we conduct tests on all platforms. Therefore, we can only limit it to 3. There are definitely work can be done to enhance support for much older devices, e.g. iPhone 6, iPod Touch 6 and iPad 4. Given the fact we don't have these devices and the simulator doesn't support older OSes, we would have to limit our support devices to those compatible with iOS 12.0+ and ideal ones to iOS 13.0+.

There are definitely rooms for improvement on this aspect and we give ourselves Good for backwards compatibility.

Maintainability

The code base overall is well-documented and can be extended easily as long as it conforms to our interface. We utilised multiple Design Patterns to make sure our code is highly cohesive and loosely coupled. Each module is thoroughly unit-tested and guaranteed to work on its own. Our client has been well informed of the code base from a technical perspective and fully understands how each module work together as an application.

Given the code being well-maintained, we recognise our work as Very Good from a maintainability point of view.

Project Management

We only have 2 members in the team. This has both its advantage and disadvantages. Although we have one less person to work with, our teams saves a lot of communication and synchronising effort. We were able to communicate easily and quickly without having schedule a specific time to meet up. As mentioned earlier, we utilised GitHub's issue tracker for this type of basic project management and archived good result. Every team member is clear when it comes up what to do and what are the next steps. Eventually, we are able to finish ahead of our schedule and put some extra effort into optimisations, as well as licensing issues. Retrospectively, we could have used Jira which makes the management process clearer yet more complicated. We are not sure if Jira would make the process better overall.

Our team had a well managed project and we give ourselves Very Good for project management.