HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2013T1 Altitude/Midterm"

From IS480
Jump to navigation Jump to search
 
Line 427: Line 427:
 
|scope="row"  width="1200" style="text-align: left; background: #F5F5F5"|
 
|scope="row"  width="1200" style="text-align: left; background: #F5F5F5"|
  
Prioritised Risks as at mid-term. Full entries as shown under the Project Management and Technological Implementation headings in the https://wiki.smu.edu.sg/is480/Altitude_Project_Risk_Management
+
Prioritised Risks as at mid-term. Full entries as shown under the Project Management and Technological Implementation headings in the [https://wiki.smu.edu.sg/is480/Altitude_Project_Risk_Management Risk Management Table]
 +
 
  
 
{| class="wikitable" style="text-align: center; height:80px"
 
{| class="wikitable" style="text-align: center; height:80px"

Latest revision as of 21:37, 5 November 2013

Altitude logo black.jpg
Overview Project Management Documentation

Schedule

Scope

MAIN WIKI            FINAL WIKI


Coverphoto.jpg
Mid-term Project Progress Summary

Presentation Materials

S/N Description Link
1 Presentation Slide Click here

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

Milestone(midterm)v1.png


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

Timeline(midTerm).png


Project Highlights

Schedule v3.png
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
  • About this complexity:
  • JavaScript errors are vague
  • Different development paradigm
    • Client-side rendering
    • JS-based vs Traditional Declarative HTML
  • Why is it complex?:
  • “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

  • About this complexity:
  • an Ontology is a framework for storing domain knowledge
  • Requires Jena Library for java applications to read and manipulate the ontology domain knowledge about the company's products are stored in the ontology
  • Why is it complex?:
  • Requires a good design to ensure application can use it
  • Database
    • Our database stores the ontology
    • Data to be stored must be in the ontology


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)

PlannedVSactual3.jpg

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

Projectscope.png

Schedule (Planned vs Actual till Mid Term)

Features changes

PlannedVSActualDiagram1.jpg


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
    • The backend developers are not adept at ontologies and we faced difficulties at developing the requirements input for the filtering stage.
    • Front-end developers are not minimally adept at using SAPUI5
    • The sprint was extended 5 days


2. Sprint 3

  • Delay in previous sprint
    • Due to the previous sprint delay, PM communicated with the client and we agreed 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 rescheduled time frame


3. Sprint 5

  • No prior knowledge on how ontology should be designed
    • The team spent hours exploring on how ontology should be designed. After a session with our end users, we realized the errors in our design of the ontology.
    • PM have to readjust the project schedule and the team reorganized into two core development teams to work in parallel, with one team focusing on Enhancing RFP and Design Ontology while the other team works on Download PDF using JasperReports.


Release Burn-down Chart

Midterm release burndown chart.png



















Burn-down Charts

Sprint1to4v3(midterm).png Sprint5to7v3(midterm).png



Number Description Links
1 Schedule Metric Calculation Schedule Metric Calculation Link
2 Schedule Metric Documentation Schedule Metric Documentation for Sprint Number:

1, 2, 3, 4, 5, 6, 7


Bug Metric


Number bugs found(midterm).jpg

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.


Bugs Metric Severity Chart(midTerm).jpg

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.



Number Description Links
1 Bug Metric Calculation Bug Metric Calculation Link
2 Bug Metric Documentation Bug Log





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



Changelog(midterm).png





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

UTChart1.png
UTChart2.png
UTChart3.png

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:



















Before UT VS After UT

Create New Proposal

During UT After UT
1b4UT.png
1aftUT.png


Gathering Requirement

During UT After UT
2b4UT.png
2aftUT.png

Review and Edit Proposal

During UT After UT
3b4UT.png
3aftUT.png


Changes made

Requirements Gathering

During Acceptance Latest version
Requirementsbefore.png
Requirementsafter.png


Display Recommended Options

During Acceptance Latest version
Displaybefore.png
Displayafter.png

Review and Edit Proposal

During Acceptance Latest version
Reviewbefore.png
Reviewafter.png




Reflections


IMG 1047.JPG


Team Reflection


Despite the many challenges, we managed to overcome them as a High-Performance team and build a stronger friendship between us.


Reflection1.jpg
Reflection2.jpg
Reflection3A.jpg