The document discusses a project at Bosch Research and Technology Center that aims to reduce the cost of calibrating embedded systems in automobiles by exploring modeling, simulation, and design of concurrent systems using technologies that could be incorporated into their commercial tools. It also mentions that the Ptolemy Project at UC Berkeley explores similar concepts for rapid prototyping, which are approaches used by Bosch. The document includes notes from meetings reviewing processes like SCRUM and TSP and lessons learned around team dynamics, requirements gathering, and integration of new resources.

1. Team HandSimDroid Context
Wants to reduce the cost of With mobile technologies that could
The Bosch Research and Technology
calibrating embedded system in be incorporated into their commercial
Center
automobiles tools.
Peter Anar Justin Ishwinder
Foldes Huseynov Killian Singh
Explores the modeling, simulation,
Which are used by Bosch for rapid
The Ptolemy Project @ UC Berkeley and design of concurrent, real-time,
prototyping.
embedded systems
SCRUM TSP
Client Meetings
48 hrs, 10 reqs
 Key Takeaways
• SCRUM relies on trust and being proactive
and is risky with unfamiliar teams
QAW
Use Cases • SCRUM allowed us to adjust plan while
• 50 hrs
 • 17 hrs • 16 hrs

requirements were unclear and provided quick
• 3 reqs • 30 hrs
 • 7 reqs  • 16 reqs
SRS Experiments client feedback
• 9 reqs
Contextual Paper • Clearly stating assumptions may sound like
Design Prototypes common sense, but most people forget about
it
• Knowledge of platforms and technology
should influence estimation process
TSP
Notional Architecture Lattix DSM Detailed WBS
Iterate Diagrams are
Perform
over your living
experiments
design documents
Key Takeaways
How is it going to work? Will the system meet performance and reliability goals? Do we all have the same understanding? • Assess team morale early and often – even
Performance subjective things are measurable (i.e.
Codebase Growth Final Architecture
Identify Analysis scoreboard)
challenges & Apply analysis Re-estimate &
• Informal CMMI assessments and SREs can be
unknowns techniques validate insightful, but costly for small teams
Are we making too • Integrating new resources can be tricky
Can we port 500 kLOC to Android within schedule? Is our design good enough to start implementation?
many assumptions? • Always define and confirm clear exit criteria
Period of Uncertainty Period of certainty
• Let risks and difficult QAs drive experiments
TSP
Post-mortem Define goals
• Identify • Measurable at Key Takeaways
problems the end • Not everything should earn value –
• Improve • Clear to all
timeboxed tasks like “debugging” do not give a
process members
• Server component on top of
ptdroid • Desktop tool clear indication of progress
QA Planning Ptolemy • Used to create customized
• Android client component
• Continuous • Define and • Spawns computation user interface for Android • Use of tools can both help and inhibit you
• Provides inputs and displays
integration estimate tasks threads client per model per user
• Allocate outputs
• Static analysis • Timeout and • Provides interface to change • Shows what the user will
• Code reviews resources
communication monitoring simulation parameters see on the client • Architecture helped identify issues and acted
as communication tool with stakeholders
Coding
• Unit tests
Design
• Integration
ptserver Homer
• Coding points • Defining a fault model would have helped
convention • Reviews
identify concurrency/state design defects
• Continuous integration was able to provide a
quality snapshot and refocus on problem areas