Upload
ishwinder-brar
View
356
Download
0
Tags:
Embed Size (px)
Citation preview
Team HandSimDroid Justin Killian
Peter Foldes
Anar Huseynov
Ishwinder Singh
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
2
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
3
Team HandSimDroid
Justin Killian
Team Lead
Anar Huseynov
Support Manager
Peter Foldes
Process Manager
Ishwinder Singh
Planning Manager
4
Stakeholders
• Bosch Research & Technology (Client)
▫ Automotive calibration and embedded systems design
▫ Model-driven development
• Ptolemy Project (Collaborators)
▫ Developers at University of California Berkeley
• Mentors
▫ Phil Bianco
▫ Dave Root
5
Ptolemy Desktop Application
6
Model
Output
Business Drivers
• Act as a proof of concept for ASCET tool
▫ Inspire innovation at Bosch
• Improve operations & reduce cost of calibration
▫ Running simulation on the handheld on the go
▫ Customizable UI for different purposes & different users
• Freely extend open source software
7
Project Goals
8
• Show simulations running on the handheld
• Enable UI customization by model and per user
• Create demonstrations that showcase usefulness to engineers
Paper Prototypes
9
UI Layout Designer
Handheld Ptolemy
Known Constraints
10
• Must use the Android Platform
• Must run simulations on a handheld device
• Must not use any GPL code within solution
• Must use Ptolemy
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
11
Process: Why Scrum?
• Team wanted to learn it
• Research project with unknowns
▫ Agile project management framework
• Evaluated TSP and OpenUP
12
Operational Challenges
13
Challenge Mitigation
Nobody knew Scrum Scrum Master learns and coaches
COTS Scrum tools had problems Excel ScrumSheet
Little affordance for long-term planning and tracking
WBS, Wideband Delphi and tracking charts
Long team meetings Standard meeting agenda template with time boxing
Not done with all tasks per sprint, while everyone puts in the hours
• Track actual hours worked for better estimations & priority
• Established common time
Ambiguous tasks Add task descriptions and definition of exit criteria
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
14
Work Breakdown Structure
15
Plan – Fall 2010
Sprint 2 Sprint 4 Sprint 3 Sprint 5 Milestone
Tools Setup
Process
Selection
Team
Building Proposals
Project Plan
SRE
Management
Role Assignment
WBS
Use Cases
SOW
Estimation
Notional
Architecture
Requirement &
Design
Contextual
Design
Paper prototypes
Experiment-1
September October November December
2010 Fall
EOSP
16
Experiment-2 QAW
EOSP
Sprint 1
Ad hoc Scrum
Long Term Plan
17
Milestone
Sep. Oct. Nov. Dec.
2010 Fall (732 hours) 2011 Spring (720 hours)
Jan. Feb. March April
2011 Summer (2304 hours)
May June July Aug.
EOSP
SOW
SRE
Planning
High level
Design
Detailed Design Integration
and testing
EOSP EOSP MOSP
SRS
Proposals
Requirements
Design
Implementation
proposal
QAW
Planning
Implementation
User Guide
Tool Setup Design Proposals
Training
Done
Todo
Experiments
• Ptolemy on Android
• UI Layout Tool • Actor Framework
• Notional Architecture • Experiment 1 • Experiment 2
• Contextual design • Use cases • Paper prototypes
Semester Progress
18
0
5
10
15
20
25
30
35
40
45
50
Pe
rs
on
Ho
ur
s
Remaining
Complete
Product Burndown
19
Bad Time Tracking
SRE & Experiment
Added Thanksgiving
Estimated vs. Actual
20
0
10
20
30
40
50
60
70
Pe
rs
on
Ho
ur
s
Estimated
Actual
Time Breakdown
21
Requirements 45%
Documentation 24%
Design 19%
Configuration 8%
Training 4%
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
22
Requirements Elicitation
23
Elicitation Method Time (hrs)
# Reqs Grade
Contextual Design 50 3
Use Cases 30 9
Paper Prototypes 17 7
Client Meetings 48 10
Quality Attribute Workshop
16 16
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
24
Major Risks
• Desktop Ptolemy is heavy on resources and handheld has limited resources; ▫ We may not be able to meet quality attribute
benchmarks
• We don’t know underlying complexities and dependencies of Ptolemy; ▫ the learning curve can be steep and may delay our
schedule ▫ core modifications may cause undesired effects in
other portions of the system and result in schedule delays
25
Major Risks (cont.)
• Historically the team does not finish every task that is defined in a sprint
▫ We don’t finish some important tasks that affect project milestones
26
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
27
Quality Attributes
• Wow-ability
▫ Client demonstrates the system in front of executives and inspire them
• Usability
▫ Handheld user can operate it without training
• Reliability
▫ Demonstration does not crash for 15 minutes
• Extensibility
▫ New actors could be added within 2 weeks
• Performance
▫ Real time data is processed at correct rate
28
Notional Architecture
• Context Diagram
• Component & Connector Diagram
• Sequence Diagram
29
Context Diagram
30
Dynamic View
31
Sequence Diagram
32
Decision Backlog
• UI Layout Designer
▫ COTS component (Eclipse framework)
▫ Self developed
• Network communications
▫ Sockets
▫ Jabber Protocol
33
Agenda
• Project Overview
• Operations
• Planning & Tracking
• Requirements Elicitation
• Project Risks
• Notional Architecture
• Reflections & Next Semester
34
Positives
• Daily Scrums ▫ Easy way to track daily progress and be on the same
page
• Short term iterations were effective ▫ Allowed to re-plan easily ▫ Tailor the process ▫ Easy to react to unknowns
• Software Experiments
▫ Removed unknowns
• Notional Architecture ▫ Got out of period of uncertainty
35
Less Positives
• Scrum is not prescriptive enough for a new team ▫ We don’t have enough trust to rely on volunteered work
• Scrum is short-sighted ▫ Had to come up with our own method for long term
tracking
• Must have a good description and exit criteria for each task ▫ People have different understanding what task is and when
it is done
• Need to have deadlines for tasks within sprint ▫ Student syndrome pushed all tasks completion to the sprint
end
36
Lessons Learned
• Do experiments to minimize unknowns
• Do create notional architecture early to get out period of uncertainty and gain common understanding of the project
• Do identify, manage, and control your risks
• Do more team building activities
• Don’t use contextual design for greenfield project • Don’t start with agile process with unknown team in
plan-driven development
37
Next Semester
• TSP
▫ Want to learn it – Another point of view on PM
▫ Well prescribed process
Don’t need to tailor it as much as Scrum
• ACDM
▫ Want to learn it
▫ Approach architecture with an iterative process
38
Next Semester
• Requirements ▫ Approve SRS
• Architecture ▫ High-level by MOSP ▫ Refined by EOSP
• Experiments ▫ Communication Protocols ▫ UI Tool
• Domain knowledge ▫ Explore Ptolemy in depth - Analysis course will help
• Implementation ▫ Setup development tools by middle of semester
39
Accomplishments
Notional Architecture ✔
Software Experiments ✔
QAW ✔
SRE ✔
SoW ✔
Use Cases ✔
Paper Prototypes ✔
Contextual Design ✔
SRS ✗
40
Accomplishments
GOT GADGETS ✔
41
Questions and Comments
42
Backups
43
Wideband Delphi
44
Prototypes
• Helped eliminate design alternative
• Shaped architecture
• Do early and often
• Size it correctly
▫ Don’t spend too much time on them
45
Sprint Burndowns
46
0
20
40
60
80
100
120
10/2
/10
10/4
/10
10/6
/10
10/8
/10
10/1
0/1
0
10/1
2/1
0
10/1
4/1
0
10/1
6/1
0
10/1
8/1
0
10/2
0/1
0
10/2
2/1
0
10/2
4/1
0
10/2
6/1
0
10/2
8/1
0
10/3
0/1
0
11/1
/10
11/3
/10
11/5
/10
11/7
/10
11/9
/10
11/1
1/10
11/1
3/1
0
11/1
5/1
0
11/1
7/1
0
11/1
9/1
0
11/2
1/10
11/2
3/1
0
11/2
5/1
0
11/2
7/1
0
11/2
9/1
0
12/1
/10
12/3
/10
12/5
/10
12/7
/10
Eff
or
t L
eft
Date
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Project Burndown
47
-500
0
500
1000
1500
2000
2500
3000
3500
To
tal
Eff
or
t L
eft
Date
Ideal burndown
Velocity
Modified Velocity
Risk Exposure
Very Likely Likely Unlikely
Catastrophic 3 1 1
Critical 6 3 1
Marginal 8 5 7
Negligible 1 1 3
48
Risk Statements
49
# Risk Statement TF Impact Probability
R7 The Ptolemy repository and structure is large in size; • the learning curve can be steep and
may delay our schedule • core modifications may cause
undesired effects in other portions of the system
NT Catastrophic Very Likely
R17 Roles are not clearly specified and followed; • Work may not get done on time • The team might end up duplicating
work
NT Marginal Very Likely
Use Case Diagrams
50
Product Backlog
• How did we use Scrum?
▫ Held sprint kickoff meetings
▫ Held daily scrums (standup meetings)
▫ Reviewed weekly/project burndown charts
▫ Maintained product backlog
▫ Planned according to sprints and milestones
51
Scrum Sheet
52
Quality Attribute Scenarios
53
1
RTC gives a demo with the sound spectrum model to the Schwieberding teams using the Android device and providing a sound (file). The tool shows an analysis and suggests correctly the plausible cause.
HIGH
2
The Ptolemy interface designer creates an interface using the desktop tool. The end user uses the handheld device, downloads the interface, and the interface looks exactly like the desktop preview.
HIGH
3
The handheld end user, untrained, unfamiliar with the Ptolemy tool but familiar with handheld devices, runs the demo with minimal interactions and gets the results without making any mistakes.
HIGH
4
The handheld user, untrained, unfamiliar with the ptolemy tool but familar with handheld devices, explores the demo with no further instruction for 15 minutes and the demo does not crash.
HIGH
5
A Ptolemy developer adds an existing graphical actor to be used for the handheld application, its incorporated into the desktop interface design and its displayable on the handheld within two (2) person weeks.
HIGH
Quality Attribute Scenarios (cont.)
54
6
A Ptolemy develop add an existing input actor to be used for the handheld application and incorporated into desktop interface designer, and the handheld connects datasource to the model within two (2) person weeks.
HIGH
7
RTC ports the system from Android to iPhone once Android version exists. RTC implements iPhone specific parts with zero changes changes to the systems architecture.
MEDIUM
8
An interface designer is building a layout for a new android device with different dimensions and capabilities once the initial android version exits; user can design a layout with no code changes.
MEDIUM
9 Version 3.0 of Android comes out and layout builder and handheld application supports it without any code changes.
MEDIUM
10 Version 3.0 of Android comes out with new features, RTC can implement these features with no change to the architecture.
MEDIUM
Quality Attribute Scenarios (cont.)
55
11
A Ptolemy developer needs to maintain this system by making a change to the code and effort to understand and identify where the change needs to be made is 0 person/days.
MEDIUM
12 The handheld user runs the sound spectrum model, the visualization feedback is not more than 20% slower than the desktop application.
MEDIUM
13 The handheld user runs the sound spectrum model, the sensor data is captured at the correct rate and fed into the simulation with the order preserved.
HIGH
14
The handheld user runs a model that requires a wifi input and there is trouble connecting and/or data loss, the handheld notifies the user about the error and the user understands the problem.
MEDIUM
15
The handheld user is running a model that experience an error that stops the normal execution, the handheld provides the user a way to cancel execution and return a default state and logs the error for future debugging.
HIGH
16
A Ptolemy developer modifies either handheld application or layout interface designer code. Any new defects that affect current code are caught by the existing tests.
MEDIUM
Software Experiments
• Code Generation
▫ Proposed by client and collaborator
• Porting complete Ptolemy to Android
▫ Too slow on handheld
▫ Switched to Client / Server based on the results
56
Team Roles
• Justin
▫ Team Lead
▫ Client Liaison
▫ Product Owner
• Anar
▫ Support Manager
• Peter
▫ Process Manager
▫ Scrum Master
• Ishwinder
▫ Planning Manager
57