4. 4
Team HandSimDroid
Justin Anar Peter Ishwinder
Killian Huseynov Foldes Singh
Team Lead Support Process Planning
Manager Manager Manager
5. 5
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
7. 7
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
8. 8
Project Goals
• Show simulations running on
the handheld
• Enable UI customization by
model and per user
• Create demonstrations that
showcase usefulness to
engineers
10. 10
Known Constraints
• Must use the Android Platform
• Must run simulations on a
handheld device
• Must not use any GPL code
within solution
• Must use Ptolemy
12. 12
Process: Why Scrum?
• Team wanted to learn it
• Research project with unknowns
▫ Agile project management framework
• Evaluated TSP and OpenUP
13. 13
Operational Challenges
Challenge Mitigation
Nobody knew Scrum Scrum Master learns and coaches
COTS Scrum tools had problems Excel ScrumSheet
Little affordance for long-term WBS, Wideband Delphi and
planning and tracking tracking charts
Long team meetings Standard meeting agenda
template with time boxing
Not done with all tasks per sprint, • Track actual hours worked for
while everyone puts in the hours better estimations & priority
• Established common time
Ambiguous tasks Add task descriptions and
definition of exit criteria
16. 16
Plan – Fall 2010
2010 Fall
September October November December
Process
Selection Tools Setup
Role Assignment SRE
Management
WBS Project Plan EOSP
Team
Estimation
Building
Proposals
Paper prototypes
Contextual
Design
Experiment-2 QAW
Requirement & Notional
Use Cases Experiment-1 Architecture
Design
SOW
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Milestone EOSP
Ad hoc Scrum
17. 17
Long Term Plan
2010 Fall (732 hours) 2011 Spring (720 hours) 2011 Summer (2304 hours)
Sep. Oct. Nov. Dec. Jan. Feb. March April May June July Aug.
SOW
Training
Planning
SRS
Done
Design Proposals
SRE Tool Setup
Planning
Todo
Proposals High level
Design Implementation
Requirements
• Ptolemy on
• Contextual design
Implementation Android
• Use cases
proposal • UI Layout Tool
• Paper prototypes Experiments
• Actor Framework
Design
Detailed Design Integration
• Notional
and testing
Architecture
• Experiment 1
• Experiment 2
User Guide
QAW
Milestone
EOSP MOSP EOSP EOSP
25. 25
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
26. 26
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
28. 28
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
35. 35
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
36. 36
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
37. 37
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
38. 38
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
39. 39
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
45. 45
Prototypes
• Helped eliminate design alternative
• Shaped architecture
• Do early and often
• Size it correctly
▫ Don’t spend too much time on them
49. 49
Risk Statements
# Risk Statement TF Impact Probability
R7 The Ptolemy repository and NT Catastrophic Very Likely
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
R17 Roles are not clearly specified NT Marginal Very Likely
and followed;
• Work may not get done on time
• The team might end up duplicating
work
51. 51
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
53. 53
Quality Attribute Scenarios
RTC gives a demo with the sound spectrum model to the
Schwieberding teams using the Android device and providing a sound
1 HIGH
(file). The tool shows an analysis and suggests correctly the plausible
cause.
The Ptolemy interface designer creates an interface using the desktop
2 tool. The end user uses the handheld device, downloads the interface, HIGH
and the interface looks exactly like the desktop preview.
The handheld end user, untrained, unfamiliar with the Ptolemy tool
3 but familiar with handheld devices, runs the demo with minimal HIGH
interactions and gets the results without making any mistakes.
The handheld user, untrained, unfamiliar with the ptolemy tool but
4 familar with handheld devices, explores the demo with no further HIGH
instruction for 15 minutes and the demo does not crash.
A Ptolemy developer adds an existing graphical actor to be used for
the handheld application, its incorporated into the desktop interface
5 HIGH
design and its displayable on the handheld within two (2) person
weeks.
54. 54
Quality Attribute Scenarios (cont.)
A Ptolemy develop add an existing input actor to be used for the
handheld application and incorporated into desktop interface
6 HIGH
designer, and the handheld connects datasource to the model
within two (2) person weeks.
RTC ports the system from Android to iPhone once Android
7 version exists. RTC implements iPhone specific parts with zero MEDIUM
changes changes to the systems architecture.
An interface designer is building a layout for a new android device
8 with different dimensions and capabilities once the initial android MEDIUM
version exits; user can design a layout with no code changes.
Version 3.0 of Android comes out and layout builder and handheld
9 MEDIUM
application supports it without any code changes.
Version 3.0 of Android comes out with new features, RTC can
10 MEDIUM
implement these features with no change to the architecture.
55. 55
Quality Attribute Scenarios (cont.)
A Ptolemy developer needs to maintain this system by making a change to the
11 code and effort to understand and identify where the change needs to be made MEDIUM
is 0 person/days.
The handheld user runs the sound spectrum model, the visualization feedback
12 MEDIUM
is not more than 20% slower than the desktop application.
The handheld user runs the sound spectrum model, the sensor data is captured
13 HIGH
at the correct rate and fed into the simulation with the order preserved.
The handheld user runs a model that requires a wifi input and there is trouble
14 connecting and/or data loss, the handheld notifies the user about the error and MEDIUM
the user understands the problem.
The handheld user is running a model that experience an error that stops the
15 normal execution, the handheld provides the user a way to cancel execution HIGH
and return a default state and logs the error for future debugging.
A Ptolemy developer modifies either handheld application or layout interface
16 designer code. Any new defects that affect current code are caught by the MEDIUM
existing tests.
56. 56
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
57. 57
Team Roles
• Justin
▫ Team Lead
▫ Client Liaison
▫ Product Owner
• Anar
▫ Support Manager
• Peter
▫ Process Manager
▫ Scrum Master
• Ishwinder
▫ Planning Manager
