IS480 Team wiki: 2013T2 SixDotz Midterm Project Management

From IS480
Jump to navigation Jump to search
Midterm Wiki

Project Scope   Project Management   Documentation   Back to Main Wiki

Project Timeline version 3


Buffer Days

  • 1 day buffer (2 Mar) between iteration 5 and 6
  • 1 day buffer (20 Mar) between iteration 6 and 7

Changes made from version 2 to 3

Reasons for schedule changes

Need to shift Database Log-in Forward

For the 2nd release, the sponsor is concerned that some residents at SMU Prinsep Hostel may not own a Facebook account. It will be inconvenient for the user to have to create a Facebook account just to Log-in, thus the sponsor propose that the database Log-in to be implemented before the 2nd release.

All changes made

Database Log-in function was shifted from iteration 7 to iteration 4. To account for it, the floor-plan function under manage resident was shifted from iteration 4 to iteration 6. The Appraisal function under the RS application was shifted from iteration 6 to iteration 7, making include the floor-plan function while filling up the space initially occupied by database Log-in. Other tasks are swapped around iterations 4, 5, 6, and 7 to accommodate to the changes in development skill sets available and for balancing the work load.

Project Timeline version 2


Buffer Days

  • 1 day buffer (2 Mar) between iteration 5 and 6
  • 1 day buffer (20 Mar) between iteration 6 and 7

Changes made from version 1 to 2

Reasons for schedule changes

Delay from Iteration 2

We took longer than expected to learn how to do responsive UI. Some screen resolutions did not display as expected, and some pages are experiencing flickering in terms of the UI experience, thus we took longer than expected to research and resolve the issues. Other than the responsive UI, it is also our first time using Hibernate as well. We had a little issue getting use to using the Hibernate methods to call the database. Out of the 9 days delay in iteration 2, 4 days were resolved by using buffer days. The other 5 days was resolved by dropping the good-to-have Auto-checking function, after which some tasks was rescheduled.

Added function: Carousel custom content

During out sponsor meeting, our sponsor proposed an extra function to be implemented in the Carousel. The initial idea for the carousel is to allow the HMTs to choose from the existing pool of hostel event to be displayed. The new custom content feature will enable the HMTs to upload a picture for display on the Carousel. In addition, when user click on the "see more" link, a pop-up will display more details of that particular content clicked.

Added function: News feed content selection

The current news feed pulls out and display only the main Facebook newsfeed from the Prinsep page. The new content selection function will display 3 items instead of 1 item, and enable HMTs to disable 1 of them if they do not want it to show. The three items are:

  1. Facebook newsfeed from main Prinsep page (NO ability to disable)
  2. Facebook newsfeed from Prinsep page “posted by others” (YES, able to ability to disable)
  3. Others - allow HMTs to do custom content similar to the carousel

Changed SSO Log-in to a Database Log-in

This is due to technical difficulty and additional costs that may incur. Our application is using a server that is outside of SMU, we therefore would have to call an external web service that we are completely unfamiliar with. We could not sought help from SMU IITS as they have never done it before as well. Moreover, there are additional costs that will incur from purchasing the required security tools. This change also indirectly helped to create a little additional time to account for feedback.

Changes made

Postponed user test 1 and first release

  • Shifted user test 1 from 20-23Jan to 27-19 Jan
  • Shifted first release from 28 Jan to 4th Feb

Two additional functions (see above) was added after the sponsor feedback, and one of the function needed to be in before the first release. As development was slower than expected, we did not have additional time to do the extra functions. Thus, in order to not compromise on the quality of the application, the user test and 1st release was postponed by 1 week.

Dropped Photo sharing function

After a discussion with the sponsor, we came to the consensus that dropping the photo sharing function is the best resort to make space for new functions such as the custom carousel and news feed content.

Dropped Auto-checking function

Auto-sharing function was a good-to-have proposed by our team. The sponsor felt that the new changes are definitely more important than this and should be given priority. This is also to create more space to account for the delay in iteration 2.

Scheduling the 2 new functions and the database log-in

Carousel custom content had to be in before the 1st release and thus thus it was scheduled into iteration 3. News feed content selection need not be included in the 1st release but had to be in for the 2nd release, thus it is scheduled in iteration 4. Database log-in is to replace the implementation of SSO log-in in iteration 4. However as we had to make space for News feed content selection in iteration 4, we shifted the database Log-in to iteration 7 since we already have the Facebook Log-in implemented.

Reschedule tasks for iteration 3 and onward

Iteration 3 shrank from 17 days to 14 days and had an additional function added (Carousel Custom Content). To account for it, The compose email function under the Organizing tool was shifted to iteration 4. While, iteration 4 had two additional function added (News feed content selection and compose email). To account for it, the controller for floor-plan display and List view of residents in iteration 4 was shifted to iteration 5. Open evaluation and reminders in iteration 4 was shifted to iteration 6. Tasks for other iterations was reschedule to account for the changes in iteration 3 and 4. All shifting of tasks backwards is accounted for from the dropping of the Photo-sharing and Auto-checking function.

Project Timeline version 1


Buffer Days

  • 3 days buffer between iteration 2 and 3
  • 1 day buffer between iteration 3 and 4
  • 1 day buffer between iteration 4 and 5
  • 2 days buffer between iteration 5 and 6

Schedule Metrics

Schedule will be tracked on a per iteration basis using the following formula.

Formula: Estimated time/ Actual Time * 100

Score(%) Action

score <= 50%

Team is way too slow!

  1. Reflect on why production was so slow.
  2. Consider dropping task or scaling down some functions

50 < score <= 90

Team is too slow

  1. Review on possible under-estimation for future iterations.
  2. Use buffer days.
  3. If no buffer days, consider dropping task or scaling down some functions

90 < score <= 110

Our estimates are fairly accurate, and team is roughly on track

110 < score <= 150

Team is too fast

  1. Reflect on why production was so fast
  2. Add days gained as buffer days

150 < score

Team is way too fast! Use the same mitigation actions as the category 110 < SM < 150.

Schedule Tracking

SixDotz Schedule metric.png
Iteration Summary Planned Start Planned End Actual Start Actual End Score Reason Actions taken


Functions to code:

  1. Let's Go Outing (non-responsive)
  2. Carousel display

Other Tasks:

  1. Basic SQL Database


  1. Proposal
  2. Acceptance






The application was done with the module Interactive, Design and Prototyping (IDP). Deadlines from IDP help to keep the project on track.



Functions to code:

  1. Let's Go Outing (RESPONSIVE)
  2. Facebook Log-in
  3. Newsfeed (Integrate with Facebook)

Other Tasks:

  1. Convert Database to use Hibernate






Team is too slow. Team took longer than expected to learn responsive UI and Hibernate.

Used up 4 buffer days in the schedule. Iteration 2 is shifted back by 5 days as Hostel Events is similar to Let's Go Outing, thus it is crucial for us to get Let's Go Outing to be working first. To account for it, team dropped Auto-checking function and postponed user test and first release by 1 week.


Functions to code:

  1. Hostel Events
  2. Event Organising Tool (Drafts and Repository)
  3. Basic Registration
  4. Carousel (Custom Content)






Estimation is accurate

No action taken


Functions to code:

  1. Newsfeed (content selection)
  2. Manage Evaluations (UI)
  3. Database Log-in
  4. Manage Residents (View Profile, edit, delete and List View)

Other Tasks:

  1. Set up Google Analytics
  2. Live Feedback collection


  1. User Test 1

Functions Release to HMT & RS:

  1. Let's Go Outing
  2. Hostel Events
  3. Basic Registration
  4. Event Organising tool
  5. Carousel
  6. Newsfeed (Partial)
  7. Facebook Log-in






Estimation is accurate

No action taken

Schedule Tracking Tool

We used a Google excel spreadsheet to break down tasks, assign responsibilities and deadlines for each one of us. This spreadsheet also provided visibility for each member to know what tasks other members have completed, are in the process of developing or still yet to do.

Bug Metrics

SixDotz Bug metric.png

Bug Tracking

Bug Metric by points

SixDotz Bug metric by Points.png

Bug Metric by number of bugs

SixDotz Bug metric by Number.png

How did the bug metric help us?

The aim to have as little bugs found after development as possible. In iteration 2, the bugs severity points was a lot higher than iteration 1, it was mainly because of the unfamilarity with the technologies used causing us to not be able to identify possible loopholes in our code during development.

Bugs in iteration 3 was also higher than iteration 1, we reflected that there was a lot of corner cases not identified during development. Hence we sought to identify corner cases for functions for future iterations

Iteration 4 is better but may be because of the tasks being relatively easier.

Risk Metric

SixDotz Risk.png


Risk Impact Risk
Mitigation Strategy Status
Project Management Risk

Most of us will be away for a few days in Dec, with 2 member of the team being away for 1 week or more, causing a potential delay in the Community Life Module

We will not be able to make it for the first user testing and subsequently deployment


Have a detailed plan for the winter iteration that will ensure that all tasks are completed while taking into account that for some days team strength is lower


As Project Manager will be overseas for 12 days during the winter break iteration, there will be no proper Project Management procedures in place

Project progress may be delayed


Another member of the team will take over the Project Manager role. Proper hand-over of documentation will be done before PM goes overseas


Overwhelming feedbacks from the live system which may cause a sudden change in requirements or too much additional tasks.

With the sudden large increase in tasks, schedule will be delayed


Before the deployment of each module, it should undergo user testing with the real users of the system such that feedback from the user tests will ensure that the eventual deployed system have as little usability issues as possible.

Did not post a risk (Monitoring)

Modules are not ready to be deployed causing the deployment date to be postponed

Schedule will be delayed, affecting the progress of future iterations


The dates in between user tests and actual deployment are sufficiently spaced-out to ensure that there is enough time to re-fine the application and make it ready for deployment

Did not post a risk (Monitoring)

The unrelated 4 modules may compete with each other for resources

May result in 4 mediocre applications with unsatisfactory quality


As the quality of the primary modules is the most important, we allocated more resources for it in the schedule and also aim to complete it in the earlier iterations

Eliminated (By reducing scope)

Client-related Risks

Final outlook and interaction of the application may be different from what the client expects

Project schedule will be delayed as there will be a need to allocate days to modify the UI


Before starting each of the 4 modules, a low-fidelity prototype will be created and communicate to the client to gather feedback before diving into the backend and logic codes. Application will be reviewed with the client regularly.

Did not post a risk (Monitoring)

Client may request for a change in certain requirement in the middle of the semester

Project schedule will be delayed with the addition or modification of tasks


Define the project scope in detail and go through it with the client during meetings. Ensure that the client and team are on the same page before proceeding

Was a challenge in Iteration 3 & 4

Client could not do the relevant maintenance after the hand-over of the project

Inconvenience to end-users


A member of the team (Zui Young) will ensure proper documentation of the system and hand-over it to the client.

N.A for now

Technical risk

Patching of live system takes too long due to unfamiliar bugs appearing or unfamiliarity of the technicalities involved

System will be down for a longer period than planned causing inconvenience to the end-users


Plan for buffer hours for the patching sessions and ensure that end-users are informed before-hand the period of time which the system will be down. Also ensure that all required preparations are done fully before the actual patching starts

Did not post a risk (Monitoring)

3 out of 5 members of the team are unfamiliar with the Stripes Java Framework

Project schedule will be delayed if team members could not be up to speed with their coding task


Conduct lessons on the Stripes framework. Guide and make sure that team members understand the framework during their coding tasks for acceptance.

Eliminated (Team learned well during December)

All members never used Responsive UI or Hibernate before

Project schedule will be delayed if team members took too long to learn and could not be up to speed with their coding task


Sought help from friends who are familiar. Meet regularly in Dec to learn diligently.

Was a challenge in Iteration 2

Sever is located in China

May cause difficulties trying to connect applications that the China network banned


Communicate with client to have a back-up server

A challenge in Iteration 5

SMU SSO Log-in and Facebook Log-in is down or under maintenance at the same time causing users to be unable to Log-in to system

Inconvenience to end-users


Database is designed in such a way that will allow a conversion to manual Log-in

Eliminated (Dropped SSO & implement database log-in)