Difference between revisions of "Systems Engineering and Other Disciplines"

From SEBoK
Jump to navigation Jump to search
 
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
(121 intermediate revisions by 17 users not shown)
Line 1: Line 1:
−
The intellectual content of most engineering disciplines is largely component-oriented and value-neutral. The level of the components will vary by discipline.  For example, aircraft engineers will need to need to know how to integrate various mechanical, electrical, and informational components, and to address human operator concerns, but they will generally consider the aircraft as their system of interest, and will consider the baggage handling, airport layout, and ground traffic management systems to be part of their environment. They may consider various tradeoffs such as range vs. payload, but their criteria will primarily be on various aspects of aircraft performance or robustness, and less likely to involve aspects of stakeholder value other than technical proxies such as fuel efficiency.
+
As discussed in the [[Scope of the SEBoK]] article, there are many touch points and overlaps between {{Term|Systems Engineering (glossary)|systems engineering}} (SE) and other disciplines. {{Term|Systems Engineer (glossary)|Systems engineers}} should have a basic understanding of the nature of these other disciplines, and often need to understand aspects of another discipline in detail. This article describes the landscape of disciplines that are intertwined with SE. For a closer view of the individual disciplines, see [[Related Disciplines|Part 6]].
  
−
The underlying laws and equations of these disciplines, such as Ohm’s Law, Hooke’s Law, Newton’s Laws, Maxwell’s equations, or the Navier-Stokes equations, deal with aspects of their system of interest’s performance.  But they generally do not address the contributions of this performance to the value propositions of the aircraft’s owners, passengers, operators, maintainers, manufacturers, and safety and pollution regulators.  As implicit in the INCOSE definition of systems engineering, the intellectual content of realizing successful systems involves reasoning about the relative value of alternative system realizations to success-critical stakeholders, and about the organization of components and people into a system that satisfies the often-conflicting value propositions of the success-critical stakeholders. Thus, compared to other engineering disciplines, the intellectual content of SE is more holistic vs. component-oriented, and more stakeholder value-oriented vs. value-neutral performance-oriented.
+
==Engineering Disciplines Other than Systems Engineering==
−
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
+
Engineering disciplines are mostly component-oriented and value-neutral in their intellectual content (Boehm and Jain 2006). Their underlying laws and equations, such as Ohm’s Law, Hooke’s Law, Newton’s Laws, Maxwell’s equations, the Navier-Stokes equations, Knuth’s compendia of sorting and searching algorithms, and Fitts’s Law of human movement, pertain to performance in a {{Term|System-of-Interest (glossary)|system-of-interest}}. They do not address how that performance contributes to the value propositions of {{Term|Stakeholder (glossary)|stakeholders}}.
  
−
==References==
+
In contrast, SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral, performance-oriented in its intellectual content. Realizing successful systems requires reasoning with stakeholders about the relative value of alternative realizations, and about the organization of components and people into a system that satisfies the often-conflicting value propositions of stakeholders. Stakeholders who are critical to the system’s success include funders, owners, users, operators, maintainers, manufacturers, and safety and pollution regulators.
−
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
 
  
−
===Citations===
+
In some disciplines, the engineer evaluates and integrates design elements into a system that satisfies proxies of value. The wider the scope of the SoI, the broader the set of SE skills the engineer needs.
−
List all references cited in the article. Note:  SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
+
 
 +
For example, an aeronautical engineer might integrate mechanical, electrical, fluid, combustion-chemical, software, and cockpit design elements into a system that satisfies proxies of value like flight range, payload capacity, fuel consumption, maneuverability, and cost of production and maintenance. In so doing, the engineer operates partly as a systems engineer. The SoI is the aircraft itself and the engineer applies aircraft-domain expertise.
 +
 
 +
However, the same engineer could participate in the engineering of passenger services, airport configurations, baggage handling, and local surface transportation options. All of these contribute to the value propositions of success-critical stakeholders. The SoIs are wider, and the engineer needs broader SE knowledge, skills, and abilities to operate as a systems engineer.  The aircraft-domain expertise remains needed for effective engineering of the wider systems. As discussed in (Guest 1991), most good systems engineers are “T-shaped” people, with both a working knowledge of wider-system considerations, and a deep expertise in a relevant domain, such as aeronautical, manufacturing, software, or human factors engineering.
 +
 
 +
Engineering disciplines that are intertwined with SE include software engineering (SwE), human factors engineering, and industrial engineering. SwE and SE are not just allied disciplines, they are intimately intertwined (Boehm 1994). Most functionality of commercial and government systems is now implemented in software, and software plays a prominent or dominant role in differentiating competing systems in the marketplace.  Software is usually prominent in modern systems architectures and is often the “glue” for integrating complex system components.
 +
 
 +
The scope of SwE includes both software SE and software construction, but does not include hardware SE. Thus, neither SwE nor SE is a subset of the other. See Figure 1 in [[Scope of the SEBoK]]. For a definition of the relationship between the SEBoK and the ''Guide to the Software Engineering Body of Knowledge (SWEBOK)'', which is published by the Institute of Electrical and Electronics Engineers (IEEE) (Bourque and Fairley 2014), see [[Systems Engineering and Software Engineering]].
 +
 
 +
Human factors engineering, from micro-ergonomics to macro-ergonomics, is intertwined with SE (Booher 2003; Pew and Mavor 2007). See [[Human Systems Integration]] in Part 6.
 +
 
 +
Industrial engineering overlaps significantly with SE in the industrial domain, but also includes manufacturing and other implementation activities outside of SE. See [[Systems Engineering and Industrial Engineering]] in Part 6.
 +
 
 +
Finally, to field a successful system, a systems engineer may need to know one or more of the many specialty fields in engineering, e.g., security, safety, reliability, availability, and maintainability engineering. Most of these are considered professional disciplines in their own right and many have their own bodies of knowledge. For explanations of how these disciplines relate to SE, overviews of what most systems engineers need to know about them, and references within their bodies of knowledge, see [[Systems Engineering and Specialty Engineering]] in Part 6.
 +
 
 +
==Non-Engineering Disciplines==
 +
SE is intimately intertwined with two non-technical disciplines: technical management (TM), and procurement and acquisition (also known as acquisition and procurement). TM often falls within the purview of a systems engineer. Many SE textbooks, competency models, and university programs include material about TM. TM is a specialization of project management (PM). SE and PM have significant common content in TM, but neither is a subset of the other. See Figure 1 in the article [[Scope of the SEBoK]]. For a definition of the relationship between the SEBoK and the ''Guide to the Project Management Body of Knowledge (PMBOK)'', which is published by the Project Management Institute (PMI) (PMI 2013), see [[Systems Engineering and Project Management]] in Part 6.
 +
 
 +
Procurement and acquisition practitioners draw upon SE to determine the scope and overall requirements of the system to be procured or acquired. They then prepare requests for proposals and statements of work, determine evaluation criteria, and design source selection processes. Once a leading source is selected, they decide upon contracting options that encompass payments, reviews, audits, incentive fees, acceptance criteria, procedures, and the nature of deliverables. Finally, they monitor progress with respect to plans (including those for SE), and negotiate and execute changes and corrective actions. Many of these activities amount to specialty disciplines within procurement and acquisition. See the article [[Related Disciplines]] in Part 6.
 +
 
 +
==References==
 +
===Works Cited===
 +
Boehm, B. W. "Integrating Software Engineering and Systems Engineering." The Journal of NCOSE Vol. 1 (No. 1): pp. 147-151. 1994
 +
 
 +
Boehm, B. and A. Jain. 2006. "A value-based theory of systems engineering," Proceedings, INCOSE IS 2006. Also available at: http://sunset.usc.edu/csse/TECHRPTS/2006/usccse2006-619/usccse2006-619.pdf.
 +
 
 +
Booher, H. 2003. ''Handbook of Human-Systems Integration''.  New York, NY, USA: John Wiley & Sons Inc.
 +
 
 +
Bourque, P. and R.E. Fairley. Eds. 2014. ''[[Guide to the Software Engineering Body of Knowledge (SWEBOK)]]''. Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org.
 +
 
 +
Guest, D. 1991.  "The hunt is on for the Renaissance Man of computing." ''The Independent.'' London, England: September 17, 1991.
 +
 
 +
INCOSE. 2011.  ''Systems Engineering Handbook,'' version 3.2.1.  San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
 +
 
 +
Pew, R. and A. Mavor. 2007.  ''Human-System Integration in the System Development Process''. Washington, D.C., USA: The National Academies Press.
 +
 
 +
PMI. 2013. ''[[A Guide to the Project Management Body of Knowledge|A Guide to the Project Management Body of Knowledge (PMBOK® Guide)]]'', 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
  
 
===Primary References===
 
===Primary References===
−
All primary references should be listed in alphabetical order.  Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ ([[title]]).  Please do not include version numbers in the links.
+
Booher, H. 2003. ''[[Handbook of Human-Systems Integration]]''.  New York, NY, USA: John Wiley & Sons Inc.
 +
 
 +
Bourque, P. and R.E. Fairley Eds. 2014. ''[[Guide to the Software Engineering Body of Knowledge (SWEBOK)]]''. Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org.
 +
 
 +
Gallagher, B., M. Phillips, K. Richter, and S. Shrum.  2011.  ''[[CMMI For Acquisition]]: Guidelines for Improving the Acquisition of Products and Services,'' second ed. Upper Saddle River, NJ, USA: Addison Wesley.
 +
 
 +
Paulk, M., C. Weber, B. Curtis, and M. Chrissis.  1995.  ''[[The Capability Maturity Model]]:  Guidelines for Improving the Software Process.''  Upper Saddle River, NJ, USA: Addison Wesley.
 +
 
 +
Pyster, A. Ed. 2009. ''[[Graduate Software Engineering 2009 (GSwE2009)]]: Curriculum Guidelines for Graduate Degree Programs in Software Engineering.'' Integrated Software & Systems Engineering Curriculum Project. Hoboken, NJ, USA: Stevens Institute of Technology, September 30, 2009.
 +
 
 +
Pew, R. and A. Mavor. 2007.  ''[[Human-System Integration in the System Development Process]]''. Washington, D.C., USA: The National Academies Press.
  
−
====Additional References====
+
PMI. 2013. ''[[A Guide to the Project Management Body of Knowledge|A Guide to the Project Management Body of Knowledge (PMBOK® Guide)]]'', 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
−
All additional references should be listed in alphabetical order.
 
−
----
 
−
====Article Discussion====
 
  
−
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
===Additional References===
 +
None.
  
−
<center>[[Scope of the SEBoK|<- Previous Article]] | [[SEBoK 0.5 Introduction|Parent Article]] | [[A Short History of SE: Challenge and Response|Next Article ->]]
+
----
 +
<center>[[Systems Engineering: Historic and Future Challenges|< Previous Article]] | [[Introduction to Systems Engineering |Parent Article]] | [[Fundamentals for Future Systems Engineering|Next Article >]]</center>
  
 
[[Category:Part 1]]
 
[[Category:Part 1]]
 +
[[Category:Introduction to Systems Engineering]]
 +
 +
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>

Revision as of 22:01, 18 November 2023

As discussed in the Scope of the SEBoK article, there are many touch points and overlaps between systems engineeringsystems engineering (SE) and other disciplines. Systems engineersSystems engineers should have a basic understanding of the nature of these other disciplines, and often need to understand aspects of another discipline in detail. This article describes the landscape of disciplines that are intertwined with SE. For a closer view of the individual disciplines, see Part 6.

Engineering Disciplines Other than Systems Engineering

Engineering disciplines are mostly component-oriented and value-neutral in their intellectual content (Boehm and Jain 2006). Their underlying laws and equations, such as Ohm’s Law, Hooke’s Law, Newton’s Laws, Maxwell’s equations, the Navier-Stokes equations, Knuth’s compendia of sorting and searching algorithms, and Fitts’s Law of human movement, pertain to performance in a system-of-interestsystem-of-interest. They do not address how that performance contributes to the value propositions of stakeholdersstakeholders.

In contrast, SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral, performance-oriented in its intellectual content. Realizing successful systems requires reasoning with stakeholders about the relative value of alternative realizations, and about the organization of components and people into a system that satisfies the often-conflicting value propositions of stakeholders. Stakeholders who are critical to the system’s success include funders, owners, users, operators, maintainers, manufacturers, and safety and pollution regulators.

In some disciplines, the engineer evaluates and integrates design elements into a system that satisfies proxies of value. The wider the scope of the SoI, the broader the set of SE skills the engineer needs.

For example, an aeronautical engineer might integrate mechanical, electrical, fluid, combustion-chemical, software, and cockpit design elements into a system that satisfies proxies of value like flight range, payload capacity, fuel consumption, maneuverability, and cost of production and maintenance. In so doing, the engineer operates partly as a systems engineer. The SoI is the aircraft itself and the engineer applies aircraft-domain expertise.

However, the same engineer could participate in the engineering of passenger services, airport configurations, baggage handling, and local surface transportation options. All of these contribute to the value propositions of success-critical stakeholders. The SoIs are wider, and the engineer needs broader SE knowledge, skills, and abilities to operate as a systems engineer. The aircraft-domain expertise remains needed for effective engineering of the wider systems. As discussed in (Guest 1991), most good systems engineers are “T-shaped” people, with both a working knowledge of wider-system considerations, and a deep expertise in a relevant domain, such as aeronautical, manufacturing, software, or human factors engineering.

Engineering disciplines that are intertwined with SE include software engineering (SwE), human factors engineering, and industrial engineering. SwE and SE are not just allied disciplines, they are intimately intertwined (Boehm 1994). Most functionality of commercial and government systems is now implemented in software, and software plays a prominent or dominant role in differentiating competing systems in the marketplace. Software is usually prominent in modern systems architectures and is often the “glue” for integrating complex system components.

The scope of SwE includes both software SE and software construction, but does not include hardware SE. Thus, neither SwE nor SE is a subset of the other. See Figure 1 in Scope of the SEBoK. For a definition of the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK), which is published by the Institute of Electrical and Electronics Engineers (IEEE) (Bourque and Fairley 2014), see Systems Engineering and Software Engineering.

Human factors engineering, from micro-ergonomics to macro-ergonomics, is intertwined with SE (Booher 2003; Pew and Mavor 2007). See Human Systems Integration in Part 6.

Industrial engineering overlaps significantly with SE in the industrial domain, but also includes manufacturing and other implementation activities outside of SE. See Systems Engineering and Industrial Engineering in Part 6.

Finally, to field a successful system, a systems engineer may need to know one or more of the many specialty fields in engineering, e.g., security, safety, reliability, availability, and maintainability engineering. Most of these are considered professional disciplines in their own right and many have their own bodies of knowledge. For explanations of how these disciplines relate to SE, overviews of what most systems engineers need to know about them, and references within their bodies of knowledge, see Systems Engineering and Specialty Engineering in Part 6.

Non-Engineering Disciplines

SE is intimately intertwined with two non-technical disciplines: technical management (TM), and procurement and acquisition (also known as acquisition and procurement). TM often falls within the purview of a systems engineer. Many SE textbooks, competency models, and university programs include material about TM. TM is a specialization of project management (PM). SE and PM have significant common content in TM, but neither is a subset of the other. See Figure 1 in the article Scope of the SEBoK. For a definition of the relationship between the SEBoK and the Guide to the Project Management Body of Knowledge (PMBOK), which is published by the Project Management Institute (PMI) (PMI 2013), see Systems Engineering and Project Management in Part 6.

Procurement and acquisition practitioners draw upon SE to determine the scope and overall requirements of the system to be procured or acquired. They then prepare requests for proposals and statements of work, determine evaluation criteria, and design source selection processes. Once a leading source is selected, they decide upon contracting options that encompass payments, reviews, audits, incentive fees, acceptance criteria, procedures, and the nature of deliverables. Finally, they monitor progress with respect to plans (including those for SE), and negotiate and execute changes and corrective actions. Many of these activities amount to specialty disciplines within procurement and acquisition. See the article Related Disciplines in Part 6.

References

Works Cited

Boehm, B. W. "Integrating Software Engineering and Systems Engineering." The Journal of NCOSE Vol. 1 (No. 1): pp. 147-151. 1994

Boehm, B. and A. Jain. 2006. "A value-based theory of systems engineering," Proceedings, INCOSE IS 2006. Also available at: http://sunset.usc.edu/csse/TECHRPTS/2006/usccse2006-619/usccse2006-619.pdf.

Booher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.

Bourque, P. and R.E. Fairley. Eds. 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org.

Guest, D. 1991. "The hunt is on for the Renaissance Man of computing." The Independent. London, England: September 17, 1991.

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, D.C., USA: The National Academies Press.

PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Primary References

Booher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.

Bourque, P. and R.E. Fairley Eds. 2014. Guide to the Software Engineering Body of Knowledge (SWEBOK). Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org.

Gallagher, B., M. Phillips, K. Richter, and S. Shrum. 2011. CMMI For Acquisition: Guidelines for Improving the Acquisition of Products and Services, second ed. Upper Saddle River, NJ, USA: Addison Wesley.

Paulk, M., C. Weber, B. Curtis, and M. Chrissis. 1995. The Capability Maturity Model: Guidelines for Improving the Software Process. Upper Saddle River, NJ, USA: Addison Wesley.

Pyster, A. Ed. 2009. Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines for Graduate Degree Programs in Software Engineering. Integrated Software & Systems Engineering Curriculum Project. Hoboken, NJ, USA: Stevens Institute of Technology, September 30, 2009.

Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, D.C., USA: The National Academies Press.

PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Additional References

None.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Systems_Engineering_and_Other_Disciplines&oldid=69403"