HeaderSIS.jpg

IS480 Team wiki: 2013T1 Altitude/Final/Project Management

From IS480
Jump to navigation Jump to search
Altitude logo black.jpg
Overview Project Management Documentation

Schedule

Scope

MAIN WIKI            MID-TERM WIKI


Altitude Team.jpg


Project Progress Project Management Quality of Project Reflections


Project Management

Project Timeline

Final timeline3.png
  • As a Team, Altitude has completed :
    • 12 sprints
    • 168 days
    • 4 hours per day
    • 5 developers
    • Calculation : (Number of days) * (Hours per day) * (Number of developers)
    • Calculation : 168 * 4 * 5 = 3360
    • Total hours 3360 man hours


Project Scope (Planned Vs Final)

Final proprity circle.png


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
  • Version 4:
    • Adjust Pricing is removed
    • Integration is added
  • Altitude have developed all the core features and secondary features

Latest Scope

Prioprity circle v2.png



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
Generate Proposal 100% developed and deployed 1 Max
Download PDF 100% developed and deployed 1 Max
Design ontology 100% developed and deployed 1 Kenneth
Match Options 100% developed and deployed 1 Kenneth
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
Save Current Input 100% developed and deployed 1 Yao zong
Furnish Proposal 100% developed and deployed 1 Max
Integration 100% developed and deployed 1 Yao Zong and Kenneth
Preserve Proposal 100% developed and deployed 1 Yao Zong and Kenneth
Edit Proposal 100% developed and deployed 1 Max

Project Schedule (Planned Vs Actual till Final)

Features changes

FinalTimeline2.png




Before Mid-term presentation

Delay #1: Spring 2

Task delayed:Implementation of Take in requirements for proposal took longer than expected
Reason: The team needs more time to explore on the few unfamiliar technologies therefore the implementation was not able to complete on time

Delay #2: Spring 3

Task delayed: Delay in previous sprint
Reason: Due to the sprint delay in sprint 2, the team had a shorter period of time to finish match options.


Delay #3: Sprint 5

Task delayed: No prior knowledge on how ontology should be designed
Reason: 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.

After Mid-term presentation

Delay #4: Sprint 10

Task delayed:Affected by the change/update of Maven dependencies again
Reason: On 19th October, our client informed us that our application would break due to a maven dependencies updates and would requires a few hours to solve it. However, It was clearly not the case when we saw the changes later at night.


Project Challenges


S/N
Cause
Our Impact
Our Response
1.
Integration - Client see value in specific aspects of our project and intended for their product demo
  • More time required to re-architect and develop front-end and backend
  • Features list remains and extended (snowball)
  • Had to be done in parallel alongside our development of other functions
  • Front and Backend need to conform to their coding paradigm for integration (MVC,BODTO, $.rest)
  • Delays in our scheduled sprints
  • Reduced our scope, adjusted our schedule to accommodate
  • Reprioritised the new requirements along with our existing features and rescheduled our sprint tasks accordingly
  • Spilt into 2 development teams to work in parallel - one on integration and one on sprint functions
  • More man-hours is scheduled to complete the new requirements
3.
Platform Update - A class with 20 methods that our app was dependent on, completely removed
  • Broke our application, undid our previous work
  • Re-coding the methods that were missing
  • Resulted in 3 weeks of lowered productivity
  • Future platform updates will further disrupt our schedule, especially detrimental closer to the presentation date
  • Reprioritized our backlog
  • Rescheduling our sprint tasks
  • Sought Supervisor for his advice
  • Maintained communication with local engineers as well as senior engineer based in Germany
Project Metrics

Schedule Metric

FORMULA:

Schedule Ratio = Remaining Time ÷ Remaining Effort

Schedule Ratio Description Response
> 1.2 Project is ahead of schedule Project Manager assigns tasks from next sprint to current sprint.
Between 0.8 and 1.2 Project is within schedule No action is required for ratio of 1. Keep a look out when nearing below 1.
< 0.8 Project is behind schedule Project Manager will reschedule tasks while the team will put in additional man hours for the week. In addition, the PM will need to identify root causes of delays by end of sprint, communicate with the team about solutions to the issues and inform client about the project status.

The diagrams below show the burndown charts & schedule ratio charts of Sprint 8 - 12 since Midterms.


Burn-down Charts

Sprint8.pngSprint9.png
Sprint10.pngSprint11.png
Sprint12.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, 8, 9, 10, 11, 12

Bug Metric

FORMULA:

Bug Ratio = (2X No. of low severity bugs) + (4X No. of medium severity bugs) + (10 X No. of high severity bugs)

Severity Score Severity Level Description
2 Low Cosmetic defects. Developed functions are functional, but at a sub optimum level
4 Medium Defects that cripple a function
10 High Defects that cripple more than 1 function

Sprint Response

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.

Bugs Chart


No of Bugs Discovered (All Sprints)

All sprint bugs.png


Number of bugs (Sprints 8-12)

Sprint 8 -12 bug.png
Number Description Links
1 Bug Metric Calculation Bug Metric Calculation Link
2 Bug Log

Click here to view the bug log,

Risk Management

S/N
Issue
Elaboration
Impact
Mitigation Strategy
1.
Platform updates happening near project milestones Closer to final presentation date, we need to ensure our application is fully deployed and ready for demonstration
High
We sought out the Client’s technical leads, and we communicated with their Senior Engineer based in Germany early via email to re-configure our platform to accommodate our project schedule.
Number Description Links
1 Risk Management Calculation Risk Management Link

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

Ontology

Framework

  • About this complexity:
  • A format to describe knowledge
  • Machine Interpretable
  • Reasoning logic can be applied to an 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


Ontology

Sublime :: Instantiating Individuals (Platform schema) Sublime :: Instantiating Individuals (Application Schema)
Platform schema.png Application Schema.png
Sublime :: Instantiating Individuals (Application Integration Schema)
Application Integration Schema.png
Protege :: Creating class Protege :: Drawing relationships
Protege - 1.creating class.png Protege - 2.drawing relationships.png


Protege :: Defining Attributes Protege :: Instantiating individuals
Protege - 3.defining attributes.png Protege - 4.instantiating individuals.png