1 / 27

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

Bruce’s Modeling Hints The 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. 10.

elia
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related