IS480 Team wiki: 2016T2 LickiLicky Midterm Wiki

From IS480
Jump to navigation Jump to search

LickiLicky Logo v2.png

Main Wiki Midterm Wiki Final Wiki

Project Progress Summary

Midterm Slides: Download here

Current Iteration: 12
Total Iterations: 16
Iteration Dates: 20 February 2016 to 4 March 2016

  • Overall Project Progress: 90%
  • Modules To-Be Done - Tertiary: Backup Module (Cloud backup)
  • Modules To-Be Done - Good to Have: Analytical Module (Visualisation of Statistics)
  • Modules Completed: User, Note Taking, Search, Reminder, Group, Social, Multimedia, Scheduling
  • LickiLicky is confident of completing all modules up till tertiary functions with an additional good to have function
  • Android Mobile Application deployed on Google Play Store

Project Highlights

  • Changing project unique selling point
    • During Acceptance, our app main focus is on taking notes and reminders for individual, as well as "auto-grouping" (now called suggest group) contacts together. After more customer interviews, we realised that the grouping feature is not as popular as we thought. Now, the focus incorporates not only notes and reminders, but also attaching media to notes, filter search, and an enhanced reminder notification which allow direct calling / SMS.

Project Management

Project Scope


Project Timeline

Timeline Acceptance.PNG
Timeline Midterm.V2.png

Project Status

Module Status Confident Level (0-1) Comment
User 100% 1 Fully deployed and tested.
Note Taking 100% 1 Fully deployed and tested.
Search 80% 0.8 Tag Contacts in Notes and Hashtags functions to be improved.
Reminder 100% 1 Fully deployed and tested.
Group 100% 1 Fully deployed and tested.
Social 80% 0.8 Link Contacts to be improved.
Multimedia Module 90% 0.9 Attach Media to Notes to be improved.
Scheduling Module 100% 1 Fully deployed and tested.
Backup Module 50% 0.5 Cloud backup to be developed after Midterm.

View our Project Timeline Here!

Schedule Highlights The following changes has been made to our project scope and reflected in our schedule.

  • Secondary Functions – Google Analytics, Birthday Reminder, and Create Event were added to scope and scheduled to be developed on iteration 7, 8 and 10 respectively.
  • Tertiary Functions – Hashtags was shifted from secondary function. Data Migration was added to scope and scheduled to be developed on iteration 11.
  • Added in Good to Have functions. These are functions which we may consider to develop during IS480.
    • Good to Have – OTP registration and login was shifted from secondary function. Visualization of Statistics and Premium / Freemium Access Control were shifted from tertiary function. Best time to contact was added to scope.

Refer to our Change Management for more!

Project Metrics

Schedule Metrics

Schedule Metrics Overview.png

Iteration Planned Duration (Days) Actual Duration (Days) Schedule Metric Score Action Taken Status
3 14 16 0.88 More time needed to complete suggest group function.

Follow up action: Schedule slip was presented during Acceptance presentation. No delay to overall schedule as there are no major function to be developed in Iteration 4, which was scheduled to be preparation for Acceptance. Supervisor was informed of the slip after project was Accepted.

7 14 16 0.88 More time needed to develop filter search function.

Follow up action: Supervisor informed about delay. More hours was put into developing the function. No major delay in overall schedule.

11 14 17 0.82 More time needed to develop Hashtags.

Follow up action: Supervisor informed about delay. More hours was put into developing the functions. No major delay in overall schedule.


View our Schedule Metrics Here!

Bug Metrics

Bug Metrics.png

Iteration Bug Score Bug Summary Action Taken
5 42
7 Low
3 High
2 Critical
A major regression testing was perform after acceptance which causes the spike in bug count. The 2 critical bugs are "new contacts added not reflected under suggest group" and "reminders and notes not backup upon app updates". Resolve bugs immediately. No major delay was caused as iteration 5 was scheduled for post acceptance debugging.
6 30
5 Low
3 High
1 Critical
1 critical bug was due to app crash when reminder was set for a non-existing group and there is a notification for this reminder. Resolve bugs immediately. No major delay was caused as iteration 6 was scheduled for post acceptance debugging.
8 10
2 High
2 high bugs were "expired reminders continue to remain in reminder list" and "recurring reminders did not take on new date/time" Resolve bugs immediately. No major delay was caused as iteration 8 was scheduled for post acceptance debugging and development of only 1 function, birthday reminder.
9 122
7 Low
11 High
6 Critical
The spike in bug count were bugs that were reported during User Test 2. The critical bugs were mainly due to app crashes after a series of actions were performed using different phone models. Resolve bugs immediately. UT2 took place over a week period and it was design to have participants to submit a daily feedback form. Participants would also report bugs to us which allows the developers to resolve the bugs on a daily basis. PM scheduled a "debugging (backlog)" task and allocated the Lead Developer to resolve these bugs while having 2 Backend Developers to develop the functions that were scheduled for Iteration 9.
10 30
4 High
1 Critical
The critical bug was an app crash while performing a series of actions using Note 3. Resolve bugs immediately. Critical bug did not occur again after new APK was released. Similar action was performed but bug did not replicate.
11 72
8 Low
3 High
1 Critical
The critical bugs were app crashed such as when user tried to upload video to his note, filter search caused app crashed searched for a wide range for age / income, and when user select the "call" option when a reminder notification was sent to the user but it was not assigned for any particular contact. Resolve bugs immediately. PM scheduled a "debugging (backlog)" task prior to UT3 and allocated the Lead Developer to resolve them while having 2 Backend Developers to develop the remaining functions. The crashes did not occur during UT3. However, UT3 participants reported several UI bugs (low) which include keyboard blocking what user is typing, "attach" icon blocking their screen.

Viewed our Bug Metrics Here!

Task Metrics

Task Metrics.png

Iteration Task Score Description Action Taken
9 0.87 Underestimated the hours needed to develop link contact (0.67) Underestimated the hours needed for debugging (0.6) Underestimated the hours needed to analyse user test result (0.5) Allocate more hours for future development tasks with similar level of complexity.

Allocate more hours to analyse user test result for future user test.

Project Risks

Risk Description Category Impact Mitigation Strategy
Team is unfamiliar with android development. Low Project may be potentially delayed due to time spent on learning. Quality of product may be affected. This risk has been lowered from High (during Acceptance stage) to Low. The developers are now more familiar with android development. However, this remain as a risk. Developers will share their knowledge with each other whenever a problem arise.
Mismatch of product against market. Medium Developed product may not be what our target users or anyone in the market wants. The risk has been lowered from High (during Acceptance stage) to Medium. More interviews have been conducted to validate market needs against project idea.
Quick rise of direct competition Medium Google can easily integrate its contacts app with notes (i.e. Google Keep), reminders (e.g. Google Tasks) and even calendars. The risk has been lowered from High (during Acceptance stage) to Medium. By targeting a niche market like FCs, and possibly patenting certain novel features of the app in the near future, we will remain competitive against bigger software companies. Furthermore, the team has enhanced knowledge about the Singapore market which also allow us to remain competitive.
Limited variety of Android phone models to perform testing Medium There may be compatibility issues with less popular Android phone models. We stretch our user testing period which will allow us to continuously recruit participants and allow testing on more variety of phones.
Risk of not having sufficient actual testers (Financial Consultant) Medium Not recruiting enough Financial Consultants to test the product may result in mismatch of product against market. The team recruited actual user during User Tests but the eventual number does not count as a sufficient sample size. PM has schedule a UAT in Iteration 14, where the product, projected to be developed up to all tertiary functions with an additional good to have function, will be tested on the real market. The team will be working closely with our mentor for this and our BA is constantly in touch with our target market.

Technical Complexity

Alarms and Notification.png

Lickilicky Attach Media To Notes Tech.png

Quality of Product

Intermediate Deliverables

Stage Specification Modules
Project Requirements Market Research Market Research
Project Management Minutes Minutes
Metrics Schedule Metrics
Task Metrics
Bug Metrics
Risk Risks
Change Management Change Management
Diagrams Class Diagram
Workflow Model
Logical Diagram
Design Low-Fi Prototype
High-Fi Prototype
UI Prototype
Testing User Testing 1 User Test 1
User Testing 2 User Test 2
User Testing 3 User Test 3


User Testing

User Testing Date Venue Users Link
User Testing 1 30 Oct 2015 SMU SIS GSR2.1 2 User Testing 1
User Testing 2 6 Jan 2016 - 12 Jan 2016 On-site at SMU SIS Lift Lobby Bench and off-site 32 User Testing 2
User Testing 3 11 Feb 2016 - 16 Feb 2016 On-site at SMU SIS SR 2.1 / GSR 2.1 on 12 Feb 2016. Off-site for rest of the days 28 User Testing 3


Team Reflection As a self-proposed project, the most challenging aspect of this project is that we do not have a sponsor to give us specific project scope, which means that we have to take full ownership of business and functional requirements. We have realised huge amount of efforts and hours are spent not only in developing the product, but also doing market research to ensure the final product solves the real world problem

Individual Reflection

Name Reflections
LickiLicky alvin.png

Alvin Neo

As the PM, I learnt most about managing expectations from various stakeholders such as Supervisor, Mentor, and most importantly, my teammates. I also learnt about managing changes to the project scope and scheduling it to fit into the timeline according to their priority.

LickiLicky dandan.png

Dan Dan Thio

Through this project, I developed the skill to write  clear business requirements and to be able to communicate requirements to stakeholders and development team effectively. I learnt about the flaws in my original idea through customer interviews, and better engagement of my customers through their views.

LickiLicky stanley.png

Stanley Soh

I have actively participate in the coding of our app and this has hone my Android development skills greatly. I have also realised that it is important that we keep testing and figuring out what we don’t know. I need to constantly analyse the feedbacks from our testers/customers and improve our application to the best of my abilities.

LickiLicky sebas.png

Sebastian Hadinata

Through IS480 project, I have learned that in order to create a good UI, we need to understand what is the standard for contacts UI. Frequently, I also need to explore existing apps in the market to gain ideas on the UI. Lastly, I have also learned that what we perceived as a good might not be well accepted by the market. As such, thorough market research shall be conducted to validate functional requirements.

LickiLicky yazhi.png

Zhao Yazhi

There is a huge learning curve for new programming functions as well as the technical knowledge about android. Through user testing, I understand the importance of having a proper test plan so we can ensure the quality of our application.

LickiLicky mengxi.png

Ren Mengxi

Understanding user preference is of great importance before moving to development stage. I need to make sure the integration of UI design and backend logic fits the conventional way people interacting with their contacts, to provide best user experience as we can.