Why Model?

From SEBoK
Revision as of 16:00, 6 June 2011 by Bkcase (talk | contribs) (moved Why model? to Why Model?: CM-corrective change request approved 6/6/11)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Jump to navigation Jump to search

Introductory Paragraph(s)

Purpose of a Model

Models are representations that can aid in defining, analyzing, and communicating a set of concepts. System models are specifically developed to support analysis, specification, design, and verification of a system. One of the first principles of modeling is to clearly define the purpose for the model. Some of the purposes that models can serve throughout the system life cycle are highlighted below.

  • Characterizing an existing system. Many existing systems may be poorly documented, and modeling the system can provide a concise way to capture the existing system design. This information can then be used to facilitate maintaining the system, or be used to assess the system with the goal of improving the system. This is analogous to creating an architectural model of an old building with overlays for electrical, plumbing, and structure, before proceeding to upgrade it to withstand new earthquake standards.
  • Mission and system concept formulation and evaluation. Models can be applied early in the system life cycle to synthesize and evaluate alternative mission and system concepts to determine system design and cost feasibility. Models can be used to explore a trade-space by modeling alternative system designs, and assessing the impact of critical system parameters such as weight, speed, accuracy, and reliability on the overall measures of merit (glossary). In addition to bounding the system design parameters, the models can also be used to validate that the mission and system requirements are the right requirements to meet the stakeholder needs, before proceeding with synthesizing detailed system designs.
  • System design synthesis and requirements flowdown. Models can be applied to support architecting system solutions, and flow the mission and system requirements down to the components of the system. Different models may be required to specify different aspects of the system design and address the broad range of system requirements. This may include models to specify functional, interface, performance, and physical requirements, and other non functional requirements such as reliability, maintainability, safety, and security.
  • Support for system integration and verification. Models can be applied to support integration of the hardware and software components into a system, and verify that the system satisfies its requirements. This often involves integrating lower level hardware and software design models with the system level design models to verify the system requirements are satisfied. This may also include replacing selected hardware and design models with actual hardware and software products, to incrementally verify that the system requirements are satisfied. This is referred to as hardware and software in the loop testing (glossary). The models can also be used to define the test cases (glossary) and the other aspects of the test program to assist in test planning and execution.
  • Support for Training. Models can be used to simulate various aspects of the system to help train users on how to interact with the system. The users may be operators, maintainers, or potentially other stakeholders. The models may be a basis for developing simulators (glossary) of the system that provide very high fidelity representation of the user interaction.
  • System Design Evolution. Models can provide an effective means for capturing knowledge about the system, which can be reused and evolved to support changing requirements and changing technologies for new applications and new customers.

Indicators of an Effective Model

A model is intended to support a purpose as described above. The value of a model can be assessed in terms of how effectively it supports its purpose. The following are some indicators of an effective model taken in part from A Practical Guide to SysML.

Does the model scope address its intended purpose?

The model must be scoped to address the intended purpose. In particular, the type of models and associated modeling languages must be selected to support the specific needs. For example, a system architecture model may be required to describe the interconnection among the airplane parts, a trajectory analysis model is required to analyze the airplane trajectory, and a fault tree analysis model is required to assess the potential causes of airplane failure.

For each type of model, the appropriate breadth, depth, and fidelity of the model should be determined to address the intended purpose. The model breadth reflects the system requirements coverage in terms of the degree to which the model must address the functional, interface, performance, and physical requirements and other non functional requirements (e.g. reliability, safety). For an airplane functional model, the model breadth may be required to address some or all of the functional requirements to power up, takeoff, fly, land, power down, and maintain the aircraft environment.

The model depth indicates the coverage of system decomposition from the system context down to the system components. For the airplane example, the model scope may be required to model the system context that includes the aircraft, the control tower and the physical environment, down to the navigation subsystem, its components, such as the inertial measurement unit, and perhaps down to lower level part of the inertial measurement unit. The model fidelity indicates the level of detail the model must represent for any given part of the model. For example, the model of system interfaces may be fairly abstract and represent the logical information content alone, such as aircraft status data, or need to support higher fidelity information that includes the encoding of a message in terms of bits, bytes, and signal characteristics. Fidelity can also refer to the precision of a computational model, such as the time step required for a simulation.

Indicators of model quality

The quality of a model should not be confused with the quality of the design that the model represents. For example, one may have a high quality computer aided design model of a chair, which accurately represents the design of the chair. However, the design may be flawed, such that when one sits in the chair, it falls apart. A high quality model should assist the design team in assessing the quality of the design and uncovering design issues.

The indicators of model quality (glossary) often are associated with adherence to modeling guidelines that support effective modeling practices. Typical examples of modeling guidelines may include naming conventions, application of appropriate model annotations, proper use of modeling constructs, and applying model reuse considerations. Specific guidelines are different for different types of models. For example, the guidelines for developing a geometric model using a computer aided design tool may include conventions for defining coordinate systems, dimensioning and tolerances.

Model-based metrics

Models can provide a wealth of information that can be used for both technical and management metrics (glossary) to assess the modeling effort and in some cases, the overall systems engineering effort. Different types of models will provide different information. In general, models can provide information to:

  • Assess progress
  • Estimate effort and cost
  • Assess technical quality and risk
  • Assess model quality

The models can be used to capture similar metrics that are captured in a traditional document based approach to systems engineering, but potentially more precisely due to the more precise nature of models over documents. Progress can be assessed in terms of the completeness of the modeling effort relative to the defined scope of the model. Models may also be used to assess progress in terms of the extent to which requirements have been satisfied by the design or verified through test. When augmented with productivity metrics, the model can be used to estimate the cost to perform the systems engineering effort or the estimate to complete the effort.

The models can be used to identify critical system parameters, and assess technical risk in terms of uncertainty in those parameters. In addition, the models may be used to provide additional metrics that are associated with its purpose. For example, when the modeling purpose is to support mission and system concept formulation and evaluation, then a key metric may be the number of alternative concepts that are explored over a specified period of time.

Primary References

Friedenthal, S., A. Moore, and R. Steiner. 2009. A practical guide to SysML: The systems modeling language. Morgan Kaufman. Needham, MA, USA: OMG Press. (Chapter 2)

Additional Reading

| Wilbur, A., Towers, G., Sherman, T., Yasukawa, D. and Sue Shreve. 2005. Metrics Guidebook for Integrated Systems and Product Development. INCOSE-TP-1995-002-01.

Article Discussion

[Go to discussion page]