Difference between revisions of "Systems Engineering and Other Disciplines"

From SEBoK
Jump to navigation Jump to search
Line 27: Line 27:
 
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.
 
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, DC, USA: The National Academies Press.
+
Pew, R. and A. Mavor. 2007.  ''Human-System Integration in the System Development Process''. Washington, DC, USA: The National Academies Press.
  
 
PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK)''. 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
 
PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK)''. 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Revision as of 00:43, 13 September 2011

As discussed in the Scope of the SEBoK 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 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: Historic 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 (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, USA and 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. New York, NY, USA: 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 A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, DC, USA: The National Academies Press.

PMI. 2008. A Guide to the Project Management Body of Knowledge (PMBOK). 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)