Difference between revisions of "Systems Engineering and Other Disciplines"

Revision as of 12:40, 7 June 2012

This navigational tool is a prototype under development SEBoK 1.0. Comments are welcome for improvement.
Use [+] to expand and [-] to collapse. Clicking on a title will open that article.

{{#star:

}}

As discussed in the Scope and Context of the SEBoK topic, there are many touch points 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, Related Disciplines.

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, the Navier-Stokes equations, Knuth’s compendia of sorting and searching algorithms, and Fitts’s Law of human movement, 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 system’s success-critical stakeholders , such as funders, owners, users , operators, maintainers, manufacturers, and safety and pollution regulators.

In some cases, such as aeronautical engineering, the engineer is concerned with evaluating and integrating various mechanical, electrical, fluid, combustion-chemical, software, and cockpit design elements into a system that satisfies various proxies of value, such as flight range, payload capacity, fuel consumption, maneuverability, and cost of production and maintenance . If the system of interest is the aircraft itself, aeronautical engineers are clearly operating as systems engineers as well. However, if aeronautical engineers participate in the engineering of wider systems of interest, such as the various passenger services , airport configurations, baggage handling, and local surface transportation options and their contribution to the value propositions of the success-critical stakeholders, then they are operating more as systems engineers. Overall, this is to be desired, as they possess key aircraft-domain expertise needed for effective engineering of the wider systems. As discussed in (Guest 1991), most good systems engineers are “T-shaped” people, who have a working knowledge of the wider-system considerations, but who have deep expertise in a relevant domain , such as aeronautical, manufacturing, software, or human factors engineering.

As implicit in the International Council on Systems Engineering (INCOSE) [1] definition of SE, 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 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 (Boehm 1994). 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 and Context 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) [2], which is published by the Institute of Electrical and Electronics Engineers (IEEE) (Abran et al. 2004) and is currently under revision. For more information, please see the topic on Systems Engineering and Software Engineering.

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 the topic Human Systems Integration within Systems Engineering and Specialty Engineering in Part 6, Related Disciplines. A further intertwined engineering discipline addressed in Part 6 is Industrial Engineering, which overlaps significantly with SE in the industrial domain, but also includes manufacturing and other implementation activities outside of SE. For more information, please see Systems Engineering and Industrial Engineering.

Finally, there are 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. 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 Specialty Engineering KA in Part 6 provides an overview for what most systems engineers will need to know about each specialty field, with pointers to the references within each discipline’s own body of knowledge .

Non-Engineering Disciplines

Technical management (TM) is often within the purview of a systems engineer. It is very common for SE textbooks, competency (model) 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) [[3], 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 and Context of the SEBoK, SE and PM have significant common content in TM, but neither is a subset of the other. This relationship is developed more completely in Part 6 in Systems Engineering and Project Management.

procurement and acquisition is another non-engineering discipline intertwined with SE. It draws upon SE to determine the scope and overall requirements of the system to be procured or acquired. It then comprises several specialty disciplines such as preparation of requests for proposals, statements of work, evaluation criteria, and source selection processes . Once a leading source is selected, it involves various contracting options such as the nature of deliverables, payments, reviews and audits, incentive fees, and acceptance criteria and procedures. Subsequently, it involves monitoring of progress with respect to plans (including those for SE), and negotiation and execution of changes and corrective actions. Again, further details are provided in Part 6, Related Disciplines.

References

Works Cited

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." 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.

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, 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

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.

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

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, 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).

Additional References

No additional references have been identified for version 0.75. However, the references of Part 6 may be helpful in exploring some of the related disciplines. Please provide any recommendations on additional references in your review.

< Previous Article | Parent Article | Next Article >

Comments from SEBok 0.5 Wiki

No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.

SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus

@@ Line 65: / Line 65: @@
 No comments were logged for this article in the SEBoK 0.5 wiki.  Because of this, it is especially important for reviewers to provide feedback on this article.  Please see the discussion prompts below.
-{{DISQUS}}
 {{DISQUS}}