Bruce’s Modeling Hints The Secrets to Effective Modeling for Systems Engineers

1. Bruce’s Modeling HintsThe Secrets to Effective Modeling for Systems Engineers Dr. Bruce Powel Douglass, Ph.D. Chief Evangelist, Global Technology Ambassador IBM Rational Bruce.Douglass@us.ibm.com Twitter: @BruceDouglass Yahoo: http://tech.groups.yahoo.com/group/RT-UML

2. 10 Forget 7+/- 2 • Rule: All diagrams should contain 7 elements +/- 2 Psychological Review 1956 • "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“ • by George A. Miller

3. 10 Forget 7+/- 2 • BUT: you don’t have to rely on short term memory • The diagram is front of you!

4. 10 Forget 7 +/- 2 – Use Mission statements instead

5. 9 All models are abstractions but some are useful Models succeed to the extent that they allow us to reason about the world Engineer- tensile strength- support strength- stability Office Designer- color- style- feng shui Models support deep reasoning QA- mapping properties to standards User- comfort- adjustability- mobility Every model should have a purpose and scope Seller- cost- color Models answer questions Manufacturer- parts list- materials- assembly

6. Mechanical Specification Functional Model Subsystems, interfaces, Subsystem use cases/ Requirements Model and text ArchitecturalModel Model-basedhandoff Executable use casesFunctional and QoS requirements SubsystemModel(s) ElectronicSpecification DependabilityModel Model and text ControlModel Safety, reliability, and security analysisFTA, FMEA, FEMCA,Asset Diagram, SAD SoftwareSpecification Control algorithms,mathematical models Model and text 9 Models are abstractions … but can be connected (Systems) Weight Stability Parametric models Power Heat Trade studyModel Trade studyModel Trade studyModel

7. 8 Napkins models are almost completely useless. Accuracy Modelvalue Precision Completeness

8. 8 Napkins models are good way to start a conversation But a terrible way to end one

9. 7 Requirements Models Avoid Early Defects Why do we care so much about getting requirements correct? $1M $10K $30

10. Systems Use Case Requirements Model

11. ABS Braking Use Case Context Bock Diagram

12. Normal Braking UC Block State Machine

13. Normal Braking Sequence Diagram

14. 6 Model-Based Handoffs Preserve Fidelity Downstream Engineering Model Systems Engineering Model

15. 6 Handoff Workflow Hand off specification elements to individual subsystems Hand off elements common to multiple subsystems to the shared model Allocate requirements to engineering disciplines

16. 5 Only 3 (+1) Diagram Types are Required 3(+1) Required diagrams UML is complex! Are all you need

17. 5 High-Fidelity Key Modeling Views State Diagram Class (“Block”) Diagram Flow Diagram Sequence Diagram

18. 4 Design Patterns Reuse Proven Solutions Are generalized solutions to common problems Allow us to leverage other’s design experience Optimize some properties at the expense of others Can be applied at multiple levels of design

19. 3 Connect Work Products with Traceability Links • We create many different work products • Safety analysis, Requirements, Architecture, Design, Source Code, Test suites, … • But they all need to tell the same story (from their own perspective and needs) • You must be able to show • Consistency • Completeness

20. 3 Traceability • Traceability serves a number of purposes • It allows impact analysis – what is the impact if I change this element? • It allows for coverage analysis – are all elements realized • It allows for consistency analysis – are these different elements in different work products consistent and compatible with each other? Unimplementedrequirement Gold plating?

21. 2 It is better to avoid defectsthan to fix defects The Plan Planned FOC The Reality “Product Stabilization” Time to IOC Not ReadyTests failWrong product

22. 2 It is better to avoid defectsthan to fix defects Year Safety, Reliability & Security Practices Verification Project Management practices month Customer Validation hour Iterative Specification Continuous Verification SE Modeling Trade Studies Nanocycle Architecting Customer Liaison Practices Iteration Quality Assurance Practices Project

23. [more requirements] [else] 2 It is better to avoid defectsthan to fix defects hour Continuous Verification SE Modeling Nanocycle Build the work product in nanocycles with continuous verification

24. 1 The ONLY WAY to ensure Quality is Continuous Verification Requirements are correct IFF they correctly represent the inputoutput control and data transformations and their performance properties Requirements don’t specify the design or means by which the transformations are accomplished

25. 1 The ONLY WAY to ensure Quality is Continuous Verification Requirements are correct IFF they correctly represent the inputoutput control and data transformations and their performance properties We want to ensure the requirements are correct before designers, implementers and testers use them so that we can avoid rework and the high cost of defects How can we do that???? Requirements don’t specify the design or means by which the transformations are accomplished

26. 1 The ONLY WAY to ensure Quality is Continuous Test High-fidelity models can be verified with testing AND formal analysis

27. References