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