MAIN WIKI FINAL WIKI
Mid-term Project
Progress Summary
Presentation Materials
S/N
|
Description
|
Link
|
1
|
Presentation Slide
|
Link
|
Overview
Current Project Sprint :
7
The following features will be presented for our mid term presentation:
Features
|
- Login
- Enhance Take in requirements from RFP
- Recommendation Options
- Modify Recommendation Options
- Generate Proposal
- Review and edit Proposal
- Download PDF
|
Project Status
Altitude has completed 6 sprints and there are 5 more sprints to work on.
We are in sprint 7 which started on 16 September and will end on 4th October.
Project Timeline
Project Highlights
EVENT
|
HIGHLIGHT / ISSUE
|
MITIGATION/CONTINGENCY PLAN
|
Sprint 2
|
Implementation of Take in requirements for proposal took longer than expected
The team needs more time to explore on the few unfamiliar technologies therefore the implementation was not able to complete on time
|
PM have to reschedule the sprint and every member have to work hard and completed all the uncompleted tasks by the end of sprint
|
Sprint 3
|
Delay in previous sprint
Due to the sprint delay in sprint 2, the team had a shorter period of time to finish match options.
|
After reviewing with the client, we decided to reschedule generate proposal, review and edit proposal to be implemented after acceptance. PM also have to review all the future sprint schedule for the team
|
Sprint 5
|
No prior knowledge on how ontology should be designed
The team spend long hours exploring on how ontology should be designed. After a session with our end users, we realized that we took a wrong approach to design our ontology.
|
We decided to consult prof Lim Ee Peng for better understanding on how ontology can be created. The team put on more man hours to make sure that the uncompleted tasks can finished on time.
|
Technical Complexity
The technical complexities of our tools employed are in the following descending order:
COMPLEXITY
|
DESCRIPTION
|
SAPUI5
|
- “Difficulty is compounded because of the need to generate the right type and right no. of views based on the data returned”
- Example of the Matrix Overview
- Each generated cell here is based on two things — the associated requirement and the associated option
|
Ontologies
Framework
|
|
Project Management
Project Status
Features
|
Status
|
Confidence Level (0-1)
|
Member In-Charge
|
Login
|
100% developed and deployed
|
1
|
Justin
|
Take in Requirements from RFP
|
100% developed and deployed
|
1
|
Kenneth
|
Download PDF
|
100% developed and deployed
|
1
|
Si min
|
Design ontology
|
100% developed and deployed
|
1
|
Kenneth
|
Enhance take in RFQ inputs
|
100% developed and deployed
|
1
|
Yao zong
|
Generate Proposal
|
100% developed and deployed
|
1
|
Max
|
Review and Edit Proposal
|
100% developed and deployed
|
1
|
Max
|
Recommended Options
|
100% developed and deployed
|
1
|
Yao zong
|
Modify Recommended Options
|
100% developed and deployed
|
1
|
Max and Si min
|
Dashboard
|
Not Started
|
0
|
Max and Si min
|
Adjust Pricing
|
Not Started
|
0
|
Kenneth and Yao zong
|
Enhance Edit Proposal
|
Not Started
|
0
|
Justin
|
State Save
|
Not Started
|
0
|
Max
|
Approve Proposal
|
Not Started
|
0
|
Kenneth
|
Furnish Proposal
|
Not Started
|
0
|
Yao Zong
|
Delete Proposal
|
Not Started
|
0
|
Si min
|
Project Scope (Planned Vs Mid Term)
Project Scope
Since inception, there are two changes in the priority circle:
- Version 2
- Approve Proposal, Preserve State and Save Current inputs are added
- Version 3: Analytic Based Recommendations is removed
- Altitude have to developed all the core features and secondary features by the end of IS480
- Good-to-have features will only need to be developed if the core and secondary features are completed
|
Current Scope
Schedule (Planned vs Actual till Mid Term)
Features changes
Project Metrics
Schedule Metric
The diagram below shows the burn-down charts of the 7 sprints we have completed thus far:
Key Issues
1. Sprint 2
- Implementation of Take in requirements for proposal took longer than expected
- At the initial stage, Back-end developers are still reading on ontology, they are facing difficulties on how to develop take-in RFP for the filtering portion
- Front-end developers are struggling to learn coding the interface in a new language, SAPUI5
- The sprint was extended 5 days
2. Sprint 3
- Delay in previous sprint
- Due to the previous sprint delay, PM have to communicate with the client and we decided to implement review and edit proposal and generate proposal after mid-terms.
- The team is given a shorter period of time to complete match options
- Team members have to put in extra man-hours to finish sprint 3 on the reschedule time frame
3. Sprint 5
- No prior knowledge on how ontology should be designed
- The team spend long hours exploring on how ontology should be designed. After a session with our end users, we realized that we took a wrong approach to design our ontology.
- PM have to reschedule the project schedule and the team was split into two sub-teams to work in parallel.
- One team focus on enhance RFP and design ontology while another team tried to explore on download pdf using jasper reports.
Release Burn-down Chart
Burn-down Charts
|
Bug Metric
Bug Log Chart
For sprint 6, the team have to do more vigorous testing for UT 1 preparation. However, due to the lack of time, 4 bugs was carried over from sprint 6 to 7.
The team faced the most number of bugs in sprint 7 due to the user feedback on UT1, the team spend extra man-hours to solve the difficult bugs and ensure that all usability features can function properly before mid term presentation.
Bug Metric Severity Chart
- From the bug metric severity chart, there are two sprints that has severity score over 10 points.
- Sprint 6 - the impact was 2nd highest due to the preparation of UT1
- Sprint 7 - the impact was the highest due to the post UT1 feedback, the team is trying to solve all bugs from both back-end and front-end for the mid-term presentation
Bug Score Sum
|
Response
|
6 and below
|
Bugs are to be resolved at the end of the sprint.
|
Between 7 and 9
|
Resolve bugs that are medium severity within the sprint, else schedule the bugs to be resolved in future sprints.
|
10 and above
|
Developer working on non-critical functions will assist the developer on the critical bug.
|
|
Risk Management
Prioritised Risks as at mid-term. Full entries as shown under the Project Management and Technological Implementation headings in the Risk Management Table.
S/N
|
Risk Description
|
Impact
|
Impact Level (High/Med/Low)
|
Likelihood (High/Med/Low)
|
Mitigation Strategy
|
Status
|
1
|
Project Management
|
1.1
|
- The team required longer period of time to work on the required tasks.
|
- Scope and schedule of the project affected
|
High
|
High
|
- Frequent trips to consult domain experts from IMC is needed to ensure that all requirements are clarify
|
Mitigation strategy in force
|
2
|
Client Management
|
2.1
|
- Change requests expected from client as SIS is developed from scratch
|
- Scope and schedule of the project affected
|
High
|
Medium
|
- PM have to evaluate the change request and re-adjust the project schedule accordingly
|
Mitigation strategy in force
|
3
|
Team Management
|
3.1
|
- Conflict amongst team members due to different working styles,different commitment
|
- Project progress will be affected
|
Medium
|
Medium
|
- Project Manager to organize a “Trashing Out” session for the team. Members to come to an understanding for the team to progress forward.
|
Mitigation strategy in force
|
4
|
Technological Implementation
|
4.1
|
- Version changes to technologies which our project is dependent on (e.g. SAPUI5 v1.4.2)
|
- Team’s progress will be affected and project schedule will be delayed
|
High
|
High
|
- Communicate with client to be kept updated of technological updates and go online forum for latest news
|
Mitigation strategy in force
|
|
Change Request Management
- During our client meeting, whenever there is a change request needed, it has to be recorded in the change management log
- The orange box shows an example entry. The team will have to determine the change request based on the priority and storypoint
- Priority is categorized into :
- Priority 1 - Impact completeness of process
- Priority 2 - Will not impact the completeness of process but will add significant value to our project
- Priority 3 - Cosmetic Issues which will not add significant value to project
- Story Points are issued to each new change request and the new story point will be added into each affected function
- View Change Request Log
|
Project Quality
Intermediate Deliverables
Stage
|
Specification
|
Modules
|
Project Management
|
Minutes
|
|
Metrics
|
|
Requirements
|
User Interface Mockups and Videos
|
|
Analysis
|
Use case
|
|
Design
|
Deployment Diagram
|
|
System Architecture Diagram
|
|
ER diagram
|
|
Testing
|
|
Deployment
Area
|
Details
|
Development Environment
|
- Our application has been deployed on SAP Hana cloud
|
Database
|
- Database deployed on SAP Hana cloud (In-memory)
|
Web Links
|
|
User Testing 1
Objectives
The aim of this user testing (UT) is to
- Validate the team’s approach of taking in requirements via Q&A
- Validate UI heuristics
- Ensure tested functions are working
Hypothesis
- Our approach of taking in requirements via Q&A procedure is fresh & relevant
- The questioning process must be easy enough to be understood without domain knowledge
- It will not take more than 5 seconds to find out how to answer the question
Conducted Session
Part 1
- Participants: 3 IMC staffs
- Venue : IMC Singapore
- Date: 26th Sep 2013
- Duration : 2 hours
Part 2
- Participants: 1 Germany user
- Venue: IMC Singapore
- Mode of Communication : Online call
- Date: 26th Sep 2013
- Duration : 1 hour 30 minutes
Scope of Test
No.
|
Feature Name
|
Features Description
|
1
|
Login
|
Allow the user to login to our system
|
2
|
Take in Requirements from RFP
|
Allow the user to input requirements to the system, and for the system to ask the right questions
|
3
|
Recommend Options
|
The system will rank and recommend the top 3 qualified options
|
4
|
Modify Recommended Options
|
Allows the user to configure product option to better align to requirements
|
5
|
Review and Edit Proposal
|
The system will display the proposal in an editable state
|
6
|
Download PDF
|
Allows the user to download proposal in PDF
|
User Feedback
User Testing 1 Conclusion
Overall, we found that our users are generally satisfied with our application (Chart 1: 100% satisfied or somewhat satisfied). Though most of our users (Chart 2: 75%) were able to answer the questions without product knowledge, we also received feedback that our take-in requirements is too complicated.
Upon reviewing the quality feedback that we have collected, we have since introduced some usability improvements such as the below:
|
Changes made
Requirements Gathering
During Acceptance
|
Latest version
|
|
|
Display Recommended Options
During Acceptance
|
Latest version
|
|
|
Review and Edit Proposal
During Acceptance
|
Latest version
|
|
|
|
Reflections
Team Reflection
Despite the many challenges, we managed to overcome them as a High-Performance team and build a stronger friendship between us.
|