HeaderSIS.jpg

IS480 Team wiki: 2015T2 Team Hei Midterm Wiki

From IS480
Jump to navigation Jump to search

Team Hei Home.png   HOME

 

Team Hei About.png   ABOUT US

 

Team Hei Overview.png   PROJECT OVERVIEW

 

Team Hei Mgmt.png   PROJECT MANAGEMENT

 

Team Hei Doc.png   DOCUMENTATION

Team Hei's Midterm.png

Project Progress Summary

Team Hei's Overview.png
Midterm Slides Deployed Site
Team Hei's Presentation Deck.png Team Hei's Deployed Site.png
Project Highlights
  • Took 4 weeks to be fully familiarized with ASP.NET MVC Framework and SQL Server
  • Took 2 weeks to be fully familiarized with the Highcharts Library
  • Develop part of the application using Java as the team was worried that the clients might not be able to provide team with a .Net server before Acceptance
  • After Acceptance, took 1 week to convert the Java codes to C#
  • Took 2 weeks to Redesign and restructure the UI after the Acceptance
  • Completed 3 User Testing thus far:
    • User Testing 1: Testers reflected that the project, if fully actualized would be useful. But the current system lacks functionality and the UX leaves more to be desired
    • User Testing 2: Testers felt that the system has potential. However, felt that the Dashboard could be more intuitive and better thought-out
    • User Testing 3: Testers felt that the system would be useful in helping users glean useful insights. On the whole, received extremely positive feedbacks for User Testing 3 (from a team of 16x IDA developers)
  • Demonstrating the system to the Ministry of Manpower on 6th March 2015

Project Management

Project Status
Team Hei's Progress Summary.png
Project Schedule (Plan Vs Actual)


Planned Project Timeline
Team Hei's Planned Project Timeline.png
Actual Project Timeline
Team Hei's Project Schedule.png
Project Metrics


Team Hei Bug Mgmt.png


Project Risks

Previously in the acceptance, our team surfaced our 5 most probable project risks: (1) client management risk, (2) project management risk, (3) technical risk, (4) resource risk and (5) human risk. However, at this juncture (Midterms), our team only flags out client management as a risk, and have identified that the remaining 4 risks no longer pose as high risks to our team.

Team Hei's Project Risks.png


Risk Type Risk Event Likelihood Impact Mitigation Learning Points & Remarks
Client Management Risk There may be major changes in our client requirements that requires drastic changes to our schedule Medium High Our team will meet our client regularly to ensure that we are always on top of our client’s requirements to lower the risk and impact of future changes to requirements Client Management Risk - We felt that this continues to be a risk because the Client requirements would continue to change regardless of the stage of project / phase we are in. The only consolation is that the changes would be less major and less frequent as the project draws closer to the end. However this means that changes should still be anticipated, and hence the team’s mitigation strategy is to continue meeting the clients regularly to ensure that we are always on top of our client’s requirements, and consistently demonstrate to the clients our developed product to ascertain that our interpretation of the requirements are aligned.
Project Management Risk Team is unsure of the time required to complete each task/functionality Low Medium Constantly review and re-estimate project schedule and the time required to complete each task/functionality Project Management Risk – At the start of the project, it was determined to be a risk because most of the functions in the project requires new technology, and the Scrum Master was still not as proficient in the estimation of the tasks due to the lack of experience. But this is no longer the case now. However, we felt that this no longer poses as a risk because as we are already at the midpoint of the project and the scrum master has as a result of that developed an uncanny ability to accurately estimate the hours required for each function after iterations of estimation.
Technical Risk Team is not proficient in the technology used such as: ASP.NET MVC, D3JS Medium Medium Team to research on technology and designate proficient team members to share knowledge Technical Risk – At the start of the project, this was determined to be a risk because the project required many new technologies, and the team have never dabbled in the required technologies before. Hence, there was a possibility that the development might not go as well as we planned. However, this is no longer a risk because the developers have already built up on their proficiency in the technologies required after the many iterations of development.
Resource Risk Unexpected technology issues (laptop/repository crashes) Low High Ensure that the latest documentation and codes are backed up in the repository and in other cloud storage as backup copy Resource Risk - At the start of the project, this was a risk because the team was using tools (visual studio) and repositories (Stash) and hence were not confident about the stability of the tools and whether it would give up on us. Moreover, one of the developer was developing on an old laptop that would shut off on its own every now and then. However, having been through many iterations, the team have developed a certain level of confidence within the tools. Also, the member with the old laptop have just replaced it. Hence, the risk of resource related problem occurring is greatly reduced.
Human Risk Team member is not available due to illness or unforeseen circumstances Low Medium Each member to have dual roles so that the backup member is able to take over the role if such circumstances arise Human Risk – At the start of the project, there were no redundancies in the skillsets of the members. The team had no suitable replacement for certain tasks if the member in charge of that were to fall sick given the gap in our skills. However, the team has now significantly built on up redundancies given that each member had also been working in their secondary role in the past few iterations. Hence, even if certain members were to be unavailable, the team would still be able to function properly.

All in all, the team would continue to closely monitor the project to circumvent any Client Management problems that might occur while also stay on the lookup for any other possible problems that the team did not anticipate.

Technical Complexity
Team Hei's Technical Complexity.png

Quality of Product

Intermediate Deliverables
Stage Date
Project Management Project Timeline
Project Scope
Risk & Mitigation
Project Overview Description
Market Research
Design & Prototype
Testing User Testing
Documentation Meeting Minutes


Testing
Team Hei's Testing.png

For more information of our User Test, click to learn more:

Team Hei UT1 btn.png       Team Hei UT2 btn.png       Team Hei UT3 btn.png

Reflection

Team Reflection
Team Hei's Reflection.png


Sponsor Comment


Team Hei's Sponsor Comment.png