IS480 Team wiki: 2016T1 FitNexx6 Midterm Wiki
Mid Term Wiki
- 1 Project Progress Summary
- 2 Project Management
- 3 Quality of Product
- 4 Reflection
Project Progress Summary
- Successfully implement MapBox into FitNexx Mobile App.
- Completed User Testing 1 with encouraging results. Almost all key featured yielded no major bugs.
- Republic Polytechnic (RP), St Joseph Institude (SJI) expressed interest in the application.
- Held preliminary talks with RP to know more about their needs as well as to gain feedback about our current app
- Pitched project to Red Hat.
|#||Task Description||Status||Confidence Level||Remarks|
|1||User Module||Development 100% Completed & Tested. Published on Google Play Store (Beta)||1.0||-|
|2||Fitness Module||Development 100% Completed & Tested. Published on Google Play Store (Beta)||1.0||-|
|3||Reward Module||Development 100% Completed & Tested. Published on Google Play Store (Beta)||1.0||-|
|4||Monitoring Module||Development 100% Completed & Tested. Published on Google Play Store (Beta)||1.0||-|
|5||View Redemption History (Admin Module)||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|6||Create/Modify Checkpoints + Generate Checkpoint QR Code (Admin Module)||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|7||Staff Account Management (Admin Module)||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|8||Manage Rewards + Inventory (Admin Module)||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|9||Missions (Gamification Module)||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|10||Mission Management (Gamification/Admin Module)||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|11||Clan 'Adventure' (Gamification Module)||90%||1.0||Newly added feature|
|13||News Module||Development 100% Completed & Tested. Deployed on staging server.||1.0||-|
|14||User Onboarding Tutorial (Misc Feature)||To be developed||1.0||-|
Project Schedule (Planned Vs. Actual)
Original Project Timeline (Acceptance)
Current Project Timeline
|Point||Description||Reason for Change|
|A||Redeem Rewards and Admin Login/Logout brought forward from Iteration 4. Manage rewards brought forward from Iteration 6||Separate developer for developing Admin Portal, hence task brought forward. Team decided that having different developers on different platform would help increase pace of development as long as there was constant communication.|
|B||Addition of User Tiering & Viewing Reward Redemption History & Manage checkpoints||Previously not added in old timeline, but is part of client's requirements.|
|C||Addition of Activeness Tracking & Bringing forward of Edit Users||Activeness Tracking added in as part of Change Request #2. View change requests here.|
|D||Bringing forward development of Gamification Module||Upon recommendation of our supervisor as this is one of our secondary modules and one of our key features, we should do it before Analytics.|
|E||Monitoring Module pushed back. Previously from Iteration 6.||Development still at early stage, not enough data to properly design the dashboard.|
|F||Analytics Module pushed back. Previously form Iteration 8.||See Point D. In addition, additional use cases were added for analytics.|
|G||Addition of an new feature in the Gamification Module||'Adventure' added in as part of Change Request #3. View change requests here.|
|H||Date of User Testing 2 pushed back to 26th Sep. Previously 5th Sep.||Delay in getting iOS Developer Program Account as well as in development of iOS features.|
- Iteration 2 was the first coding iteration. Members were still learning the technologies required. Planning of tasks were still unrefined.
- Subsequent iterations were more stable
- Iteration 7 went slightly below the mark as it was the start of the development on the iOS platform and due to limited resources (Mac OS with Xcode), the development was slower than expected.
Addition of Project Risks. Original set of project risk can be found here.
|#||Risk Type||Risk Event||Likelihood||Impact||Mitigation|
|1||Resource Risks||Client unable to get accounts for publishing in time (E.g Apple Developer Program), which can result in a delay in deployment||High||Medium||For User Testing purposes, we will make do with other methods of publishing apps to testers, such as sideloading.|
|2||Resource Risks||App approval process by Apple may take longer than expected time.||High||Medium||To put in buffer days for the publishing of app on iOS App Store.|
|3||Resource Risks||Unable to secure enought student testers at Ngee Ann Polytechnic.||Medium||Medium||For the first 2 user testing, we can include some non-NP students, in order to test basic functionalities. However, we should still attempt to get as many testers from NP as possible.|
|4||Project Management Risks||Client and supervisor may have different viewpoints regarding various aspects of the project such as function or timeline.||Medium||Medium||We ensure that any change requests is discussed thoroughly with both Supervisor and Sponsor, this is to ensure all decisions made are made known to all stakeholders.|
|#||Complexity||Why we do/use it?||Reason for Complexity||How we overcame it?|
|1||Using Ionic framework||Allows hybrid mobile development so to increase our development speed on dual platforms||Mostly uses AngularJS and HTML5, both of which our team had not much expertise in. We also have to learn the structure and the capabilities provided by Ionic. In addition, to AngularJS & HTML5, our team also picked up SCSS to help us better manage the many different styles provided by the Ionic Framework.||Team member spent much time at the start of the project to learn and experiment with Ionic|
|2||Developing plugins for Ionic framework||We needed to use HealthKit and GoogleFit, on iOS and Android respectively, to access the pedometer and retrieve the step count of users||Ionic does not have support for GoogleFit or HealthKit||We developed natively using Java and Objective-C for GoogleFit and HealthKit respectively and configure it to become a ionic- compatible plugin|
|4||Integration of Map features with Mission & The need to empower an Admin user to make changes to App Maps via admin portal||This is important as integration is the key to make it intuitive for both the Admin users to add locations (checkpoints) to the in-app map, and for students to easily identify the checkpoints and missions on the map||It is difficult to manipulate the map via inputs from a Web Portal or from another page dynamically and in real time||Team members from backend and frontend sat together and analysed our code and database schemas and how we can format the output using JSON for the map|
|5||Calculating the distance between 2 coordinates||This is to ensure students are within a certain distance from the checkpoints when performing the distance and do not abuse the system||Team did not have knowledge on how to correlate distance and coordinate||We used the Haversine formula which allows to calculate distance between 2 coordinates on a sphere|
|6||Automating the creation of an adventure as much as possible||We want to make this an effortless process for the Admin||We need to create tasks that would run on a given date without any conflicts||We created Scheduled Tasks that would be activated on the given dates. Additional checks are in place to ensure no conflicts|
Quality of Product
|Project Management||Minutes||Minutes for Sponsor, Supervisor & Internal Meetings|
|Metrics||Task & Bug Metrics|
|Risk Management||Risk Management Table|
|Change Management||Change Management Process & Record|
|Requirements & System Design||Use Cases||Use Case Diagram|
|Access Controls||Access Control Diagram|
|System Architecture||System Diagram|
|ER Diagram||ER Diagram|
Google Play Store
The app is currently only published on the Google Play Store in beta (Will move out of beta after our final UAT.)
Download it here
Apple App Store
Currently pending sponsor to provide us with the Apple Developer Program Account. Will update as soon as it is published.
In total there are 3 User Testings that have been planned in the project timeline.
|Testing||Tester Profile||Number of Testers||Objectives||Scope|
|User Testing 1||Staff of Ngee Ann, Ngee Ann Polytechnic Students and other public testers||1 Staff (Sponsor), 8 Ngee Ann Polytechnic Students, 6 public testers||
||Android Platform Only
|User Testing 2 (In-progress from 26th Sep to 30th Sep)||Staff of Ngee Ann, Ngee Ann Polytechnic Students and Tertiary Students(Sponsor request).||3 Staff, 24 Ngee Ann Polytechnic Students||
||Both iOS and Android Platform
|Final User Acceptance Test (To be conducted on 17th Oct)||Staff of Ngee Ann, Ngee Ann Polytechnic Students and Tertiary Students(Sponsor request).||To be updated||
||Both iOS and Android Platform
After working together for almost 5 months, our team has indeed grew even more bonded and stronger. Team members are now more familiar with their roles and are able to execute tasks with far greater efficiency than before. The team has grown to become more than just a FYP team, team members often help each in other modules as well as provide each other with psychological support. On the technical side of things, members have grown more adept in their tasks. For example, front-end developers are now more familiar with using Sass in Ionic, whereas Backend developers are more familiar with the various plugins, such as HealthKit & GoogleFit, required for the application. Moving forward, our team hopes to grow even more and to deliver a successful project.