• 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?
Mse team hand simdroid poster
Jun 11, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
• 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?
Related Documents
