HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2016T1 GeneSIS Final"

From IS480
Jump to navigation Jump to search
Line 86: Line 86:
  
 
<b>X-factors delivered. </b>  
 
<b>X-factors delivered. </b>  
<br>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</br>
+
<br>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
<br>Finals: 20% Reduction time in sales process. 25 Sales. 100% Employee adoption. Status: 100% Employee adoption.</br>
+
<br>Finals: 20% Reduction time in sales process. 25 Sales. 100% Employee adoption. Status: 100% Employee adoption.
 
==<div style="background:#F9BF3B; padding: 10px; font-weight: bold; line-height: 1em; text-indent: 10px; border-left: #000000  solid 32px; font-size: 18px"><font face="helvetica" color="#000000"> Project Management </font></div> ==
 
==<div style="background:#F9BF3B; padding: 10px; font-weight: bold; line-height: 1em; text-indent: 10px; border-left: #000000  solid 32px; font-size: 18px"><font face="helvetica" color="#000000"> Project Management </font></div> ==
 
<center>
 
<center>

Revision as of 02:44, 12 November 2016

TronEffect.png




Genesis home button.png
Genesis aboutus button.png
Genesis projectoverview button.png
Genesis projectmanagement button.png
Genesis document button.png
Home
About Us
Project Overview
Project Management
Documentation


Midterm Final

Project Progress Summary

Presentation icon.png Deployedsite icon.png GPoster icon.png Video icon.png
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 straightfoward 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.

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

What have we promised our sponsor? Delivery status?

Midterm vs Final Scope

midterm scope here || Final scope here
Midterm Final

scope description, what we have achieved, exactly as promised? dropped modules? changes made? sponsor happy or not

See our Project Scope page for more details on previous changes

Midterm vs Final Project Schedule


midterm schedule
final schedule description of midterm and final schedule. differences, notable changes.

Project Metrics

Team Velocity

Formula: Average of accepted stories points of _ sprints
sprint velocity chart here
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

<insert picture to describe what happens each sprint>
Explanation: what happens when stories are not accepted? 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.

Deployment

Deployed site: deployed site

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

product owner's testimonial


Individual Reflection

Khairul:

Pamela:

Yu Sheng:

Xue Ning:

Qing Wan: