HeaderSIS.jpg

IS480 Team wiki: 2012T1 One-hit Wonder MT Project Metrics Bug

From IS480
Revision as of 04:55, 8 October 2012 by Kaili.tee.2009 (talk | contribs) (New page: <!--Navigation--> {| style="background-color:none; color:#ffffff; border-bottom:3px dotted #000000; border-top:3px dotted #000000; border-left:3px dotted #000000; border-right:3px dotted #...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Undo-icon.png Main Wiki

HomeOHW.png Home

Calendar 2 icon&48.png Project Management

Chart line icon&24 white.png Project Metrics

18px‎ Technical Complexity

Users24.png Usability Studies

TeamRef.png Team Reflection


Schedule Metric

Bug Metric

Risk Management

Schedule Metric

Combined.jpg

Summary

In actual fact, from Iteration 0 – 3, the team managed to accomplish the planned tasks within the estimated duration allocated for each iteration.
In Iteration 4, the team took 2 days longer than the expected planned duration due to the delay in implementing all amendments gathered from Acceptance’s feedback. Although the implementation of amendments caused a delay but it is beneficial for the project in the long run, as we can ensure that all changes suggested by our stakeholders (Clients & Supervisor) have been met.
In Iteration 5, the team took 3 days longer as the team discovered that the scope of the project was too broad. This is largely attributed to the fact that we need to amend changes upon User Testing and also to implement new functions in every iteration. Hence, the team decided to prioritise the tasks by implementing the most important function – collaborative reviews to bridge the gap as well as improve the communication between the Hiring department and HR Manager directly after Mid-term presentation.
So far, the schedule metric for each individual iteration had served the team well as it gave us a better visual representation on the planned versus actual duration taken to implement each function. This also allowed us to better estimate the duration required for similar functions in the future iterations. In addition, PM is able to revise the project schedule more clearly at the end of each iteration.

Phase Iteration

Inception

Iteration 0
Elaboration Iteration 1
Iteration 2
Iteration 3
Construction Iteration 4
Iteration 5
Iteration 6
Bug Metric

OHW Bug Metric.jpg

Summary

In general, our bug metric falls below 6 except for the two peaks that we saw in Iteration 3 and 6. According to our bug index, most of the time we will solve these bugs during our debugging session.
For iteration 3, we had a spike due to a critical error that prevented user from logging into the application. This is a critical issue that required immediate fixation, as the entire application was not accessible.
For iteration 6, the critical error that we faced was when the company tried to navigate to the Interview page, s/he got redirected to the Interview page that was designed for job seeker. This is a critical error as it disrupted the entire workflow of our application.


Risk Management

Summary

After the acceptance, our team realised that some of the risks which were previously identified during the acceptance phase were successfully mitigated, while others still remain relevant, although there is a change in the likelihood of them happening. In addition, our team has also identified potential risks which might arise due to the complexity of the upcoming core functionalities.

As the semester progresses, our team starts to experience the heavy workload of juggling FYP with other assignments and modules, for instance, midterms and other project deadlines. Hence, we included this as a risk that has both high likelihood and impact.


Resolved Risks:

No. Type of Risk Risk Statement Likelihood (H/M/L) Impact Mitigation Strategy / Contingency Plan Status
1 Technical Difficulty in implementing customizable template for job seekers to drag and drop content into the template Low Low Team already tried Jquery Drag & Drop feature & implemented it under Resume function. (Not a huge risk to the team for late implementation) Mitigated
2 External Due to similar applications launch in the market, there might be unexpected change of requirements by sponsor Medium Low Fortnightly update/meeting with sponsor – Kris Kong & Wong Cheok Lup Controlled
3 Technical Team is unfamiliar with the new framework - Play! Framework Low Low
Medium
Set aside more time to code Mitigated


Potential Risks Ahead:

No. Type of Risk Risk Statement Likelihood (H/M/L) Impact Mitigation Strategy / Contingency Plan
Schedule Risk
1 Technical Schedule. Team members are busy with school work High
Low
High
Medium
Plan ahead and make sure that all team members are comfortable with the work load and free to meet on the dates scheduled. Team members to encourage each other and make extra effort to accommodate to each other and keep in pace with the schedule. Set weekly compulsory meeting dates.
Scope Risk
2 Internal Project scope is too big Medium High
  • Discuss with clients and supervisor on our scope
  • Priortise the more important functions that can value-add our application
Technical Risk
3 Technical Search function. Team is unfamiliar with the implementation techniques. Medium High
  • Set aside time for exploration of techniques
  • Insert buffer for this implementation
4 Technical Instant resume template. Difficult and time-consuming to implement because need to create CSS from scratch. Medium Medium
  • Scheduled for early implementation to prevent delay
  • Include buffer time for this implementation
5 Technical Deployment. Deploying to client server may affect the functioning of certain parts of the application. Medium High Always deploy in advance (1 week before) & test run the application.