Difference between revisions of "Systems Engineering and Other Disciplines"

From SEBoK
Jump to navigation Jump to search
m (moved SE and Other Engineering Disciplines to Systems Engineering and Other Disciplines: Renamed as part of the restructuring of Part 1)
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 [[SEBoK 0.5 Scope]] article, there are many touchpoints and overlaps between systems engineering (SE) and other disciplines.  It is important for systems engineers to have a basic understanding of the nature of these other disciplines and often there are specific aspects of another discipline that systems engineers need to be aware of.  The discussion below provides an overview of the landscape of intertwined disciplines; for more specific information, please see [[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.
+
==Other Engineering Disciplines==
 +
The intellectual content of most engineering disciplines is largely component-oriented and value-neutral.  (Boehm and Jain 2006)  The underlying laws and equations of engineering 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 [www.incose.org International Council on Systems Engineering] [[Acronyms|INCOSE]] definition of systems engineering, the intellectual content of realizing successful systems requires 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. (INCOSE 2011) Thus, compared to other engineering disciplines, the intellectual content of SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral performance-oriented.  
  
−
==References==
+
Many interesting systems today have significant software content.  In fact, most of the functionality of commercial and government systems is now implemented in software, and software plays a prominent, often dominant, role in differentiating competing systems in the marketplace.  Software engineering [[Acronyms|(SwE)]] is not just an allied discipline; SwE and SE are intimately intertwined. Software is usually prominent in modern systems architectures and is often the “glue” for integrating complex system components. As discussed in the figure “System Boundaries of Systems Engineering, System Implementation, and Project/Systems Management” in [[Scope of the SEBoK]], 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.
−
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.
 
  
 +
The SEBoK explicitly recognizes and embraces the intertwining between SE and SwE, which includes defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge [[Acronyms|(SWEBOK)]], which is published by the IEEE  (Abran et al. 2004) and is currently under revision.  For more information, please see the article on [[Systems Engineering and Software Engineering]].
 +
 +
==Non-Engineering Disciplines==
 +
As discussed in [[Systems Engineering History and Future Challenges]], the SE field initially focused on the engineering of physical systems, but systems engineers increasingly found that enabling the realization of successful engineered systems also involved integrating physical SE with the intertwined disciplines of software engineering, human factors engineering, and project management.
 +
 +
Similarly, the SEBoK explicitly recognizes and embraces the intertwining between SE and human factors engineering, from micro-ergonomics to macro-ergonomics (Booher 2003; Pew-Mavor 2007).  These relationships are developed more completely in [[Systems Engineering and Other Disciplines|Part 6]].
 +
 +
Technical management [[Acronyms|(TM)) is often within the purview of a systems engineer.  It is very common for SE textbooks, competency models, and university programs to include significant content on TM.  SE is intimately intertwined with TM, which itself is a specialization of project management (PM).  The SEBoK explicitly defines its relationship to the Guide to the Project Management Body of Knowledge [[Acronyms|(PMBOK)]], which is published by the Project Management Institute [[Acronyms|PMI)]] (PMI 2008).  Again as seen in the figure "System Boundaries of Systems Engineering, System Implementation, and Project/Systems Management" in [[Scope of the SEBoK]], SE and PM have significant common content in technical management, but neither is a subset of the other. In version 0.5, this relationship is also developed more completely in [[Systems Engineering and Other Disciplines|Part 6]] within the [[Systems Engineering and Project Management]] knowledge area.
 +
 +
Finally, there are many specialty fields in engineering, e.g., security, safety, or quality engineering.  Most of these are considered professional disciplines in their own right and many have their own bodies of knowledge.  However, these disciplines are still critical to the fielding of successful systems.  The SEBoK addresses these by providing an overview of and references for the specialty disciplines, and specifically focuses on how each discipline relates to SE. [[Systems Engineering and Other Disciplines|Part 6]] is intended to provide an overview for what most systems engineers will need to know about the discipline with pointers to the references within disciplines’ own bodies of knowledge.
 +
 +
==References==
 
===Citations===
 
===Citations===
−
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.
+
Abran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. SWEBOK: Guide to the software engineering body of knowledge: 2004 version. Los Alamitos, CA; Tokyo, Japan: IEEE Computer Society Press.
 +
 
 +
Boehm, B. and A. Jain. 2006. ‘’A Value-Based Theory of Systems Engineering.’’ A Technical Report. Los Angeles, CA, USA: Computer Science Department, University of Southern California. Available at: http://sunset.usc.edu/csse/TECHRPTS/2006/usccse2006-619/usccse2006-619.pdf.
 +
 
 +
Booher, H. 2003. Handbook of Human-Systems Integration.  John Wiley & Sons Inc.
 +
 
 +
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 Mavor, A. 2007.  Human-System Integration in the System Development Process. The National Academies Press.
 +
 
 +
PMI 2008. A guide to the project management body of knowledge (PMBOK guide). 4th 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.
+
No primary references have been identified for version 0.5.  Please provide any recommendations on primary references in your review.
 +
 
 +
===Additional References===
 +
No additional references have been identified for version 0.5.  Please provide any recommendations on additional references in your review.
  
−
====Additional References====
+
==Article Discussion==
−
All additional references should be listed in alphabetical order.
+
 
−
----
+
==Article Discussion==
−
====Article Discussion====
 
  
 
[[{{TALKPAGENAME}}|[Go to discussion page]]]
 
[[{{TALKPAGENAME}}|[Go to discussion page]]]
  
 
<center>[[Scope of the SEBoK|<- Previous Article]] | [[SEBoK 0.5 Introduction|Parent Article]] | [[A Short History of SE: Challenge and Response|Next Article ->]]</center>
 
<center>[[Scope of the SEBoK|<- Previous Article]] | [[SEBoK 0.5 Introduction|Parent Article]] | [[A Short History of SE: Challenge and Response|Next Article ->]]</center>
 +
 
==Signatures==
 
==Signatures==
 
--[[User:Nicole.hutchison|Nicole.hutchison]] 20:44, 16 August 2011 (UTC) (on behalf of Barry Boehm)
 
--[[User:Nicole.hutchison|Nicole.hutchison]] 20:44, 16 August 2011 (UTC) (on behalf of Barry Boehm)
  
 
[[Category:Part 1]]
 
[[Category:Part 1]]

Revision as of 15:40, 8 September 2011

As discussed in the SEBoK 0.5 Scope article, there are many touchpoints and overlaps between systems engineering (SE) and other disciplines. It is important for systems engineers to have a basic understanding of the nature of these other disciplines and often there are specific aspects of another discipline that systems engineers need to be aware of. The discussion below provides an overview of the landscape of intertwined disciplines; for more specific information, please see Part 6.

Other Engineering Disciplines

The intellectual content of most engineering disciplines is largely component-oriented and value-neutral. (Boehm and Jain 2006) The underlying laws and equations of engineering 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 [www.incose.org International Council on Systems Engineering] INCOSE definition of systems engineering, the intellectual content of realizing successful systems requires 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. (INCOSE 2011) Thus, compared to other engineering disciplines, the intellectual content of SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral performance-oriented.

Many interesting systems today have significant software content. In fact, most of the functionality of commercial and government systems is now implemented in software, and software plays a prominent, often dominant, role in differentiating competing systems in the marketplace. Software engineering (SwE) is not just an allied discipline; SwE and SE are intimately intertwined. Software is usually prominent in modern systems architectures and is often the “glue” for integrating complex system components. As discussed in the figure “System Boundaries of Systems Engineering, System Implementation, and Project/Systems Management” in Scope of the SEBoK, 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.

The SEBoK explicitly recognizes and embraces the intertwining between SE and SwE, which includes defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK), which is published by the IEEE (Abran et al. 2004) and is currently under revision. For more information, please see the article on Systems Engineering and Software Engineering.

Non-Engineering Disciplines

As discussed in Systems Engineering History and Future Challenges, the SE field initially focused on the engineering of physical systems, but systems engineers increasingly found that enabling the realization of successful engineered systems also involved integrating physical SE with the intertwined disciplines of software engineering, human factors engineering, and project management.

Similarly, the SEBoK explicitly recognizes and embraces the intertwining between SE and human factors engineering, from micro-ergonomics to macro-ergonomics (Booher 2003; Pew-Mavor 2007). These relationships are developed more completely in Part 6.

Technical management [[Acronyms|(TM)) is often within the purview of a systems engineer. It is very common for SE textbooks, competency models, and university programs to include significant content on TM. SE is intimately intertwined with TM, which itself is a specialization of project management (PM). The SEBoK explicitly defines its relationship to the Guide to the Project Management Body of Knowledge (PMBOK), which is published by the Project Management Institute PMI) (PMI 2008). Again as seen in the figure "System Boundaries of Systems Engineering, System Implementation, and Project/Systems Management" in Scope of the SEBoK, SE and PM have significant common content in technical management, but neither is a subset of the other. In version 0.5, this relationship is also developed more completely in Part 6 within the Systems Engineering and Project Management knowledge area.

Finally, there are many specialty fields in engineering, e.g., security, safety, or quality engineering. Most of these are considered professional disciplines in their own right and many have their own bodies of knowledge. However, these disciplines are still critical to the fielding of successful systems. The SEBoK addresses these by providing an overview of and references for the specialty disciplines, and specifically focuses on how each discipline relates to SE. Part 6 is intended to provide an overview for what most systems engineers will need to know about the discipline with pointers to the references within disciplines’ own bodies of knowledge.

References

Citations

Abran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. SWEBOK: Guide to the software engineering body of knowledge: 2004 version. Los Alamitos, CA; Tokyo, Japan: IEEE Computer Society Press.

Boehm, B. and A. Jain. 2006. ‘’A Value-Based Theory of Systems Engineering.’’ A Technical Report. Los Angeles, CA, USA: Computer Science Department, University of Southern California. Available at: http://sunset.usc.edu/csse/TECHRPTS/2006/usccse2006-619/usccse2006-619.pdf.

Booher, H. 2003. Handbook of Human-Systems Integration. John Wiley & Sons Inc.

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 Mavor, A. 2007. Human-System Integration in the System Development Process. The National Academies Press.

PMI 2008. A guide to the project management body of knowledge (PMBOK guide). 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Primary References

No primary references have been identified for version 0.5. Please provide any recommendations on primary references in your review.

Additional References

No additional references have been identified for version 0.5. Please provide any recommendations on additional references in your review.

Article Discussion

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Nicole.hutchison 20:44, 16 August 2011 (UTC) (on behalf of Barry Boehm)

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Systems_Engineering_and_Other_Disciplines&oldid=17391"