Difference between revisions of "IS480 Team wiki: 2016T1 GeneSIS Final"
Qwkuah.2014 (talk | contribs) |
Qwkuah.2014 (talk | contribs) |
||
Line 122: | Line 122: | ||
<br/><br/> | <br/><br/> | ||
[[File:Genesis final proj schedule.jpg|700px]] | [[File:Genesis final proj schedule.jpg|700px]] | ||
− | <span style="color: # | + | <span style="color: #000000; font-size:16px; font-family:Arial;"><br>In Sprint 8, inability to complete the notification module resulted in a spillover to Sprint 9. As such, the email module which was originally in Sprint 9 was pushed back to Sprint 10 and 11. In the interest of time, we discussed with our sponsor and decided to drop the tertiary functions altogether.</span> |
===Project Metrics=== | ===Project Metrics=== |
Revision as of 16:05, 12 November 2016
Midterm | Final |
Project Progress Summary
Final Slides | VMIS - test ver. | Poster | Pitch Video |
Project Progress
- Current sprint: Sprint 12
- Sprint period: 17 Nov - 30 Nov
- Major milestone: Final Presentation
Project Highlights
Prior to undertaking this project, the description we received from the sponsor appeared simple and straightforward which led us to believe that every module was achievable. However, once we took on the project and began pseudo-coding and functionality planning, we realized that the project was not as we thought. The difficulty lies in integrating the various modules together, ensuring information is properly stored in order for each module to correctly retrieve and display for the end user.
After countless meetings - both internal, external as well as consultation sessions with our supervisor, we are proud to have completed VMIS, an internal system tailored to suit the Vimbox's operational needs. It allows the various departments to effortlessly share data with one another, eradicating miscommunication, missing information and delayed transition that is prevalent in their workplace.
Project Challenges
Mailbox Module
Project Achievements
Following the scrum methodology allowed better project management. Regular feedback from our sponsor ensured we delivered artefacts according to sponsor's needs and helped us to identify problems and rectify them early. Usage of metrics such as burndown and velocity charts enabled us to measure productivity, ensuring team efficiency. Overall, the increased communication between scrum master, team, and product owner has facilitated the progress of our project and better manage our sprints.
X-factors delivered.
Midterm: 50 Leads, 10 Accounts, 10 Sales. System to go live by Midterm. Status: 58 Leads, 9 Accounts, 6 Sales. System went live on 23rd September
Finals: 20% Reduction time in sales process. 25 Sales. 100% Employee adoption. Status: 100% Employee adoption.
Project Management
Project Status
Team GeneSIS has delivered 100% of the agreed-upon project scope to our sponsor.
Midterm vs Final Scope
Midterm | Final |
---|---|
Team GeneSIS has completed all primary functionalities promised to our sponsor. The sponsor is pleased with the final product. However, we were unable to complete our tertiary functions, which is the google map and calculator widget. After discussion with our sponsor, we have come to an agreement that focus should be placed on ensuring that the core functionalities are bug-free and reliable.
See our Project Scope page for more details on previous changes
Midterm vs Final Project Schedule
In Sprint 8, inability to complete the notification module resulted in a spillover to Sprint 9. As such, the email module which was originally in Sprint 9 was pushed back to Sprint 10 and 11. In the interest of time, we discussed with our sponsor and decided to drop the tertiary functions altogether.
Project Metrics
Team Velocity
Formula: Average of accepted stories points of 3 sprints
Explanation:
explanation for sprint
Sprint Burndown
Formula:
- Planned: Total planned story points over number of days in a sprint
- Actual: Actual story points completed each day in a sprint
Burndown charts from some sprints since Midterm are highlighted here.
See our Midterm Wiki page for more details on sprints prior to Midterm.
burndown sprint 9
Explanation: explanation here
burndown sprint 10
Explanation: explanation here
Risk Management
Risk Type | Risk Event | Likelihood | Impact | Mitigation |
---|---|---|---|---|
- | - | - | - | - |
Explanation: -
See our Risks page for the full list of potential risks
Unaccepted Stories of Each Sprint
Explanation: At the end of each sprint, the product is shown to our sponsor where functionalities that were implemented during that sprint is demonstrated. If bugs are found or functionality is incorrectly implemented i.e. unaccepted, the product is left inside the product backlog. If the functionality hinders the development of the next function, the user story will be edited accordingly and moved to the next sprint. If the functionality is non-consequential, it will be rescheduled to a later date for fixing. See our Stories page for each sprint's user stories.
Technical Complexity
1. Complexity 1
description here
2. Complexity 2
description here
Quality of Project
Project Deliverables
Stage | Specification | Modules |
Project Management | Meeting Minutes | Internal, Supervisor & Sponsor Meeting Minutes |
Project Schedule | Project Schedule | |
Metrics | Project Metrics | |
Risk Management | Risk Management | |
Requirements | Project Scope | Project Scope |
User Stories | User Stories | |
Analysis | Market Research | Market Research |
Architectural Design | Architectural Design | |
Design | Prototypes | Mid & High Fidelity Prototypes |
Testing | User Test Plan & Results | User Test Plan & Results |
Project Handover | Introduction Slides | Delivered via private folder on Google Drive |
User Manual | [<we shld do a user manual> User Manual] | |
Source Code | Delivered via private folder on Google Drive |
Quality
Performance:
1. By having a single point system for Vimbox employees to use, we streamlined the process of transferring information from paper to excel or vice-versa. With VMIS, employees only need key in the information once, and this information is shared across relevant departments.
2. Our system allows the Site Surveyor to generate a quotation on the spot for client to review the moving fee. This speeds up the decision-making process in comparison to the past where a lot of time was wasted on returning back to the Vimbox office in order to draft out a quotation before notifying the customer.
Maintainability:
1. To ensure that our code is maintainable after the handover, we adhered to the standard Java and Javascript coding conventions and minimized deviation.
2. For slightly more complex codes, we included comments that explained the logic flow. We also ensured that our Git commit messages were always meaningful and consistent with the industry accepted standards.
Usability:
Even though our application is an internal system for Vimbox, we tried our best to cater to their business needs as closely as possible. In order to make VMIS more usable, multiple user testings were conducted and valuable feedback was given. Through the understanding our users' behavior, we ensured that our team was within contact whenever users were uncertain of functionalities. We have also included a User Manual during the handover for the client to view when necessary.
Testing
User Testing 1
Venue: Vimbox Office @ Tradehub 21
Date: 11 Aug 2016, Thursday
Time: 10:00am
Duration: ~35 minutes
Number of Participant(s): 4
User Test: Instuction here
User Test Results: Click here to view
User Testing 2
Venue: Vimbox Office @ Tradehub 21
Date: 21 Sep 2016, Wednesday
Time: 6:30pm
Duration: ~45 minutes
Number of Participant(s): 5
User Test: Instruction here
User Test Results: Click here to view
User Test 3
Venue:
Date:
Time:
Duration:
Number of Participants:
User Test:
User Test Results:
UI Fixes based on User Test 3
Reflection
Team Reflection
team reflection
Supervisor Testimonial
Professor Tang Qian:
Prof Tang's Photo
Her testimonial
Sponsor Testimonial
product owner's testimonial
Individual Reflection
Khairul:
Pamela:
Yu Sheng:
Xue Ning:
Qing Wan: