Difference between revisions of "Guidance for Engineers"

From SEBoK
Jump to navigation Jump to search
 
(84 intermediate revisions by 10 users not shown)
Line 1: Line 1:
The SEBoK is useful to engineers in other areas.  Their backgrounds may be in biomedical, civil, electronics, chemical, civil, materials, mechanical, software, or many other specialties. By studying the SEBoK they will appreciate a broader view of systems beyond their specialty, and why good systems engineering practice must involve multiple disciplines.  Successful complex systems require bringing specialties together.
+
The realization of successful complex {{Term|System (glossary)|systems}} requires experts from many disciplines to work together. This makes the SEBoK useful to engineers with backgrounds in biomedical, civil, electrical, chemical, civil, materials, mechanical, software, and many other engineering disciplines.  
  
The body of knowledge helps other engineers to better understand how their contributions fit into the larger systems picture.  They become prepared to solve more difficult and encompassing problems. In many cases, they will find that additional study of systems engineering will enhance their professional value when they put it into practice.
+
Studying the SEBoK enables engineers from disciplines other than {{Term|Systems Engineering (glossary)|systems engineering}} (SE) to:
 +
*see why good systems engineering practice must involve multiple disciplines,
 +
*appreciate a broader view of systems beyond their specialties,
 +
*understand how their contributions fit into the larger systems picture, and
 +
*prepare to solve more difficult and encompassing problems.
 +
 
 +
In many cases, engineers who study systems engineering as a supplement to their area of specialization find their professional value enhanced when they put the new knowledge into practice.
  
 
==Use of Topics==
 
==Use of Topics==
  
 +
For engineers from non-SE backgrounds, each part of the SEBoK contributes something to the experience of learning about systems engineering.
  
Other kinds of engineers will find the following knowledge areas of the SEBoK to be relevant to their interests and needs:
+
*[[SEBoK Introduction|Part 1: SEBoK Introduction]] provides an overview both of systems engineering and of the SEBoK itself   
 
+
*[[Foundations of Systems Engineering|Part 2: Foundations of Systems Engineering]] highlights the areas of systems knowledge most relevant to systems engineering, providing a foundation for the theory and practice of systems engineering as explained in Parts 3, 4 and 5
[[SEBoK 1.0 Introduction|Part 1 of the SEBoK]], provides an orientation and overview of systems engineering for other kinds of engineers who have an interest in systems engineering.  The extensive lists of references in Part 1 and throughout the SEBoK provide a basis for further readings on selected topics in systems engineering.
+
*[[Systems Engineering and Management|Part 3: Systems Engineering and Management]] includes the knowledge areas of [[Life Cycle Models]], [[System Definition]], [[System Realization]], and [[System Deployment and Use]], all highly important when approaching the study of SE from another discipline
 
+
**Also in Part 3, [[Systems Engineering Management]] includes such relevant topics as [[Risk Management|risk management]], [[Measurement|measurement]], [[Configuration Management|configuration management]], and [[Quality Management|quality management]]
[[Systems|Part 2 of the SEBoK]] provides a guide to those areas of systems knowledge particularly relevant to systems engineering. This provides a foundation for the subsequent elements of the theory and practice of systems engineering in Parts 3, 4 and 5.
+
*[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]] identifies the SE activities for four kinds of engineered systems, namely [[Product Systems Engineering|products]], [[Service Systems Engineering|services]], [[Enterprise Systems Engineering|enterprises]], and [[Systems of Systems|systems of systems]] (SoS)
 +
**The primary references and glossary terms — not just the content — for a given type of system are essential reading for an engineer developing or modifying a system of that kind
 +
*[[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]], especially [[Team Capability]], explains how systems engineers and other types of engineers fit into the larger picture of enabling individuals and teams to perform systems engineering activities, and into the larger picture of systems engineering organizational strategies
 +
*[[Systems Engineering and Other Disciplines|Part 6: Systems Engineering and Other Disciplines]] is key for engineers from non-SE backgrounds
 +
**Within Part 6, [[Systems Engineering and Project Management]] should be of interest to almost all readers, while [[Systems Engineering and Software Engineering]] and [[Systems Engineering and Quality Attributes]] are naturally most essential for engineers in the respective disciplines
 +
*[[Systems Engineering Implementation Examples|Part 7: Systems Engineering Implementation Examples]] illustrates how systems engineering practices, principles, and concepts are applied in real settings and contain universally useful insights
  
In [[Systems Engineering and Management|Part 3 of the SEBoK]], other engineers will find most of the subjects to be of interest.  In particular, the knowledge areas of [[Life Cycle Models]], [[System Definition]], [[System Realization]], and [[System Deployment and Use]] will be of value. Although many engineers may be tempted to skip over [[Systems Engineering Management]], most of the topics are relevant for other engineers (e.g., risk management, measurement, configuration management, and quality management).
+
Engineers may be tempted to skip over knowledge areas or topics that sound more like management than engineering stories, for example [[Systems Engineering Management]] in Part 3 or [[Enabling Systems Engineering|Part 5]]. This temptation should be resisted, because these topics are actually about how SE orchestrates the efforts of multiple disciplines, not management in the administrative sense.
  
Reading  [[Applications of Systems Engineering| Part 4]] ([[Product Systems Engineering|product]], [[Service Systems Engineering|service]], [[Enterprise Systems Engineering|enterprise]], and [[Systems of Systems|systems of systems]] engineering) will provide other kinds of engineers with an overview of the distinctions among SE activities for these different kinds of engineered systems.  Other engineers involved in development or modification of one of these types of systems will benefit from reading the content, primary references, and glossary terms for the engineering of that type of system.
+
Finally, the extensive lists of references throughout the SEBoK provide a basis for further readings.
 
 
Other kinds of engineers may be tempted to bypass the knowledge areas in [[Enabling Systems Engineering|Part 5 of the SEBoK]].  However, other engineers will benefit from understanding how they and systems engineers fit into the larger picture of enabling individuals and teams to perform systems engineering activities, and how systems engineers fit into the larger picture of systems engineering organizational strategies.  In particular, the topic of [[Organizing Teams to Perform Systems Engineering]] will be of interest.
 
 
 
Software engineers would benefit from reading the [[Systems Engineering and Software Engineering]] knowledge area.  Individuals involved in one of the specialty disciplines will benefit from reading the [[Systems Engineering and Specialty Engineering]] knowledge area.  See the example Software Engineering Vignette.
 
 
 
The [[Systems Engineering and Other Disciplines|Part 6]] knowledge area [[Systems Engineering and Project Management]] will be of interest to most other kinds of engineers.  Finally, [[Systems Engineering Implementation Examples|Part 7 of the SEBoK]], provides implementation examples that illustrate the application of systems engineering practices, principles, and concepts in real settings.  Some of these may be of direct applicability for engineers who have backgrounds and experiences in those kinds of systems; all of the examples provide concrete examples of the role of systems engineering in various kinds of projects and programs.
 
  
 
==Vignette: Software Engineer==
 
==Vignette: Software Engineer==
 +
José Wilks is an entrepreneurial software engineer who wants to learn more about systems engineering principles applied to embedded systems for advanced document identification and verification. He wants to implement best practices in developing highly secure systems for real-time image processing and forensic verification of documents. His company provides a rapid, secure and cost-effective solution for verifying the authenticity of identification, travel, and financial documents, with technology that runs on proprietary tablet computers for portable and fixed locations. 
  
Jose Wilks is an entrepreneurial software engineer wanting to learn more about systems engineering principles applied to embedded systems for advanced document identification and verification. He wants to implement best practices in developing highly secure systems for real-time image processing and forensic verification of documents.  His company's technology runs on proprietary tablet computers for portable and fixed locations.  It provides a rapid, secure and cost effective solution for verifying the authenticity of identity, travel and financial documents.  
+
José is knowledgeable about computer hardware engineering, low-level interfaces between hardware and software, and the related tradeoffs in embedded devices. His company has developed research prototypes, but without the stringent security requirements for actual field usage linked to government identification databases. The few experimental units which have been sold have fared well in limited testing, but José wants to expand into markets for government agencies, law enforcement departments and the private sector. To make headway into those diverse markets, he will need to confront abundant new constraints and challenges.
  
He is already knowledgeable about computer hardware engineering, interfaces at the lowest level with software, and their tradeoffs in embedded devices.  His company has experience developing research prototypes, but without the stringent security requirements for actual field usage linked to government identification databases. His sales have only been a few individual experimental units, which have fared well in limited testing, but he wants to expand into markets for government agencies, law enforcement departments and the private sector.  New constraints and challenges abound.
+
José begins his study of SE by skimming the [[SEBoK Introduction]] and the [[Scope and Context of the SEBoK]] to get an overview of the SEBoK contents. As he reads, he sometimes refers to the ''Software Engineering Body of Knowledge (SWEBoK)'' (Bourque and Fairley 2014), which José already knows from his many years of experience on software projects. In the SEBoK, José is looking for nuggets of knowledge and pointers that can help his enterprise expand. Here are his notes:
  
With 20 years of technical and management experience on software projects he already is familiar with concepts in the SWEBoKSo he starts skimming [[SEBoK 1.0 Introduction]] and the [[Scope and Context of the SEBoK]] to get an overview of the SEBoK contents. Most of the parts have nuggets of knowledge with pointers to help his enterprise operate at an expanded level, as described below.
+
*[[Systems Engineering and Management|Part 3: Systems Engineering and Management]] has concepts that are new to us and that may work. Extra system-level verification and validation (V&V) gates identified in [[Life_Cycle_Models|Life Cycle Models]] can be incorporated in company processes, and the references can help with implementation details. There is also material about system-wide procedures beyond software V&V, and about where to find testing and regulation standards used by various government entities. Together with the traditional software testing already in place, these processes could ensure conformity to the regulations and expedite the product's approval for use.
 +
*Though the system concept is proven, the company must still convince potential buyers of the system's financial benefits while demonstrating that all security criteria are satisfied. To do that, we must better understand the needs of the {{Term|Stakeholder (glossary)|stakeholders}}. In expressing system requirements and benefits, we need to start using the terminology of users, corporate/government purchasers, and regulatory agencies. [[Stakeholder Needs and Requirements]] is relevant here. The company needs to quantify expected return on investment (ROI) for its products.   
 +
*[[System Realization]] addresses our broader V&V concerns. We need to demonstrate the measures we are taking to boost reliability of system performance. The standard models and measures for system reliability described in the SEBoK are new to us — now staff must develop tests to quantify important attributes. We may want to model reliability and system adherence to regulations using a form of {{Term|Model-Based Systems Engineering (MBSE) (glossary)|model-based systems engineering}} (MBSE). We can learn more about this from the references.
 +
*[[Systems Engineering Management]] makes it clear that new configuration management (CM) and information management (IM) procedures need to be adopted for federal database controls and integrity. We can use the references in [[Systems Engineering Standards]] to learn how to define  processes and develop test cases.
 +
*[[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] makes a convincing case that having the right people for a new systems engineering culture is critical. We should probably hire a systems engineer or two to augment our engineering department expertise.
 +
*Our application must deal with private data concerns, and [[Systems Engineering Implementation Examples|Part 7: Systems Engineering Implementation Examples]], particularly the [[FBI Virtual Case File System Case Study]], could help us avoid pitfalls that have hurt others in similar situations. We can put this in context based on [[Security Engineering]] in [[Related Disciplines|Part 6: Related Disciplines]], and then follow up with further study based on the references.  
  
[[Systems Engineering and Management|Part 3: SE and Management]] has some new concepts that may work.  Reading [[Life_Cycle_Models|Life Cycle Models]] he identifies some extra system-level V&V gates to incorporate in their  processes with references for implementation details.  He is enlightened about system-wide procedures beyond software V&V, and where to find testing and regulation standards used by various government entities.  These processes will ensure conformity to the regulations on top of traditional software testing and expedite being approved for use.
+
Now José feels that he is better prepared to adapt his processes for new system lifecycles and environments, and that he can see a clear path through the morass of agencies and regulations. His priorities are to quantify the value proposition for his technology innovations, make inroads into new markets, and strengthen his staff for the long-term enterprise.
 
 
Though he has a proven system concept, somehow he has to convince potential buyers on the financial benefits of his system  while also assuring that all security criteria are satisfied.  He needs to better understand the needs of the [[Stakeholder (glossary)|stakeholders (glossary)]] including users, corporate/government purchasers, regulatory agencies and start using their terminology in expressing system requirements and benefits.  This leads him directly to [[Stakeholder Needs and Requirements]]. His company will need to quantify the expected ROI for investing in his products. 
 
 
 
[[System Realization]] is important to understand the broader V&V concerns.  Reliability measures on his system performance will need to be demonstrated.  He wasn't aware of standard models and measures for system reliability, so he will now ask his staff to develop tests to quantify important attributes.  A form of [[Model-Based Systems Engineering (MBSE) (glossary)|Model-Based Systems Engineering (MBSE)]] may also be useful for modeling reliability and the system adherence to regulations.  They will check the references for more details.
 
 
 
In [[Systems Engineering Management]] he recognizes new CM and IM procedures need to be adopted for federal database controls and integrity.  [[Systems Engineering Standards]] provides important references that will be used for process definition and test case development.
 
 
 
Studying [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]], he realizes it is critically important to have the right people for a new systems engineering culture.  He should probably hire a systems engineer or two to expand his current engineering department expertise.
 
 
 
The topic of [[Security Engineering]] in [[Related Disciplines|Part 6: Related Disciplines]] stands out.  There he finds references for further study in this burgeoning area.  In [[Systems Engineering Implementation Examples|Part 7: Systems Engineering Implementation Examples]], he identifies the [[FBI Virtual Case File System Case Study]] being relevant to avoid pitfalls experienced in a application related to private data concerns.
 
 
 
Jose is now better prepared to adapt his processes for new system lifecycles and environments.  He can quantify the business case to potential clients for his technology innovations, the initial morass of agencies and regulations is now finite, he can make inroads into new markets, and simultaneously strengthen his staff for the long term enterprise.
 
  
 
==Vignette: Mechanical Engineer==
 
==Vignette: Mechanical Engineer==
 +
Cindy Glass is a mechanical engineer whose experience in the petroleum industry has focused on large-scale oil extraction equipment in the field. Now Cindy is tasked with helping to manage the development of new offshore oil platforms featuring robotic technology and computer networks. This calls for incorporating SE principles from day one to cope with the systems considerations, which are broader than anything in Cindy's previous experience.
  
Cindy Glass is a mechanical engineer with experience in the petroleum industry, primarily working with large oil extraction equipment in the field. Now she is tasked to help manage the development of new offshore oil platforms with robotic technology, computer networks and broader systems considerations. This calls for incorporating systems engineering principles from day one.
+
Some of the drilling is to be done with remote-controlled, unmanned underwater vehicles (UUVs). Along with safety, which was always a major concern, cybersecurity now takes center stage. Hostile state actors, “hacktivists,” or others could cause havoc if they succeed in taking control of the remote vehicles or other infrastructure. Unfortunately, software system implementation is completely new to Cindy, who realizes that this entails dealing with many more engineering disciplines and dimensions of system constraints than she previously encountered.
  
Some of the drilling operations will be done remotely with unmanned underwater vehicles (UUVs). Safety has always been a major concern but now cyber security also is.  Environmentalist hackers, opposing nations or others may try to cause havoc by taking control of the remote vehicles and other operations. Unfortunately she is completely new to software system implementation. Cindy realizes there are many more dimensions of system constraints and engineering disciplines to deal with.
+
Cindy is accustomed to implementing minor design changes in existing equipment, with automation and safety guidelines already in place. Now she is starting from scratch with the earliest stages of the platform lifecycle. While Cindy understands tradeoffs involving mechanical sub-systems like rigs and drilling materials, she must now broaden her system analysis to include new environmental constraints and system security.  
  
Previously she implemented minor design changes in existing equipment with automation and safety guidelines already in place.  Now she is dealing with the earliest stages of the platform lifecycle starting from scratch.  She already understands mechanical tradeoffs between different types of rigs and drilling materials, but now has to incorporate system security and new environmental constraints in her system analysis.  [[System Realization]] gives her references for system design with many ilities.
+
Cindy consults the SEBoK and discovers that for her effort to understand system design with many "-ilities," [[System Realization]] is a good starting point and its references should provide the in-depth information she needs.  
  
The project lifecycle will require concurrent engineering of platform sub-components while evaluating technology [[Opportunity (glossary)|opportunities]], understanding the needs of all [[Stakeholder (glossary)|stakeholders]] inside and outside the company, and progressing through increasingly detailed [[Prototype (glossary)|prototypes]], working slices of software, system specifications, designs, [[Plan (glossary)|plans]], business cases, security and safety analyses of the platform architecture and its operations.
+
The project lifecycle requires pursuing several major activities concurrently:
 +
*engineering platform sub-components
 +
*evaluating technology {{Term|Opportunity (glossary)|opportunities}}
 +
*understanding the needs of all {{Term|Stakeholder (glossary)|stakeholders}} inside and outside the company
 +
*progressing through increasingly detailed prototypes, working slices of software, system specifications, designs, plans, business cases, and security and safety analyses of the platform architecture and its operations.
  
[[Systems_Engineering_and_Management|Part 3: SE and Management]] also describes how her management activities will have to be rigorous and consider the interfaces between the engineering specialties. The section on [[Planning]] gives her detailed advice for starting out. The full project plan will call for a broad set of [[Planning#Integration|integrated management and technical plans]]. Conception through Operations will have to involve all the disciplines. 
+
To understand how to manage such a project lifecycle, Cindy turns to [[Systems_Engineering_and_Management|Part 3: Systems Engineering and Management]]. The [[Planning|planning]] section provides detailed advice for starting out. Cindy expects to conduct her management activities on a rigorous basis, to consider the interfaces between the engineering specialties, and to produce a project plan that calls for a broad set of [[Planning#Integration|integrated management and technical plans]].  
  
Since she is new to working on software projects and with software engineers, she reads [[The_Nature_of_Software|The Nature of Software]] and [[Ten Things a Systems Engineer Needs to Know about Software Engineering]]. She also knows now about the SWEBoK for references on software engineering. She needs some guidance on managing a software team and studies [[Ten Things a Systems Engineer Needs to Know about Managing a Software Team]].
+
Being new to the software development world, Cindy reads [[The_Nature_of_Software|The Nature of Software]] and [[Key Points a Systems Engineer Needs to Know about Software Engineering]], and consults the [http://www.computer.org/portal/web/swebok SWEBoK] for references on software engineering.
  
It is clear that [[Systems Engineering and Software Engineering]] will be particularly intertwined. Among other things she is reminded to include security specialists at both the software level and the systems level from the beginning.
+
These readings show Cindy how closely systems engineering and software engineering are intertwined. For example, they remind her to include security specialists at both the software level and the systems level from the beginning.
  
Cindy now appreciates the broader range of system constraints and thus engineering disciplines she needs to work with.   The references in the SEBoK will be consulted throughout the architecting, design, development and deployment of the new platforms.
+
From her initial plunge into study of the SEBoK, Cindy has gained an appreciation of the wide range of system constraints for which she must account, and the many engineering disciplines she must work with as a result. She plans to consult the references in the SEBoK on each unfamiliar subject that she encounters throughout the architecting, design, development and deployment of the new platforms.
  
 
==Summary==
 
==Summary==
The SEBoK provides insights and guidance concerning systems engineering principles for other kinds of engineers and related technical disciplines. These engineers will benefit from the knowledge areas highlighted in this use case.  The SEBoK gives pointers to major references for other engineers to become more interdisciplinary and consider additional aspects in their job.  Thus they become more valuable to their employers and society.
+
Engineers from disciplines other than systems engineering benefit from the insights about SE principles that the SEBoK provides. Studying the knowledge areas highlighted in this use case and the sources to which their references point can help such engineers become more interdisciplinary. Ultimately, they can consider broadening their work responsibilities, rendering them more valuable to their employers and society.
  
 
==References==  
 
==References==  
  
 
===Works Cited===
 
===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.  
+
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
  
 
===Primary References===
 
===Primary References===
No primary references have been identified for version 0.75.  Please provide any recommendations on primary references in your review.
+
None.
  
 
===Additional References===
 
===Additional References===
No additional references have been identified for version 0.75.  Please provide any recommendations on additional references in your review.
+
None.
  
 
----
 
----
  
 
<center>[[Use Case 1: Practicing Systems Engineers|< Previous Article]] | [[SEBoK Users and Uses|Parent Article]] | [[Use Case 3: Customers of Systems Engineering|Next Article >]]</center>
 
<center>[[Use Case 1: Practicing Systems Engineers|< Previous Article]] | [[SEBoK Users and Uses|Parent Article]] | [[Use Case 3: Customers of Systems Engineering|Next Article >]]</center>
 +
 +
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
  
 
[[Category:Part 1]][[Category:Use Case]]
 
[[Category:Part 1]][[Category:Use Case]]
 
[[Category:SEBoK Users and Uses]]
 
[[Category:SEBoK Users and Uses]]
{{DISQUS}}
 

Latest revision as of 19:34, 19 November 2023

The realization of successful complex systemssystems requires experts from many disciplines to work together. This makes the SEBoK useful to engineers with backgrounds in biomedical, civil, electrical, chemical, civil, materials, mechanical, software, and many other engineering disciplines.

Studying the SEBoK enables engineers from disciplines other than systems engineeringsystems engineering (SE) to:

  • see why good systems engineering practice must involve multiple disciplines,
  • appreciate a broader view of systems beyond their specialties,
  • understand how their contributions fit into the larger systems picture, and
  • prepare to solve more difficult and encompassing problems.

In many cases, engineers who study systems engineering as a supplement to their area of specialization find their professional value enhanced when they put the new knowledge into practice.

Use of Topics

For engineers from non-SE backgrounds, each part of the SEBoK contributes something to the experience of learning about systems engineering.

Engineers may be tempted to skip over knowledge areas or topics that sound more like management than engineering stories, for example Systems Engineering Management in Part 3 or Part 5. This temptation should be resisted, because these topics are actually about how SE orchestrates the efforts of multiple disciplines, not management in the administrative sense.

Finally, the extensive lists of references throughout the SEBoK provide a basis for further readings.

Vignette: Software Engineer

José Wilks is an entrepreneurial software engineer who wants to learn more about systems engineering principles applied to embedded systems for advanced document identification and verification. He wants to implement best practices in developing highly secure systems for real-time image processing and forensic verification of documents. His company provides a rapid, secure and cost-effective solution for verifying the authenticity of identification, travel, and financial documents, with technology that runs on proprietary tablet computers for portable and fixed locations.

José is knowledgeable about computer hardware engineering, low-level interfaces between hardware and software, and the related tradeoffs in embedded devices. His company has developed research prototypes, but without the stringent security requirements for actual field usage linked to government identification databases. The few experimental units which have been sold have fared well in limited testing, but José wants to expand into markets for government agencies, law enforcement departments and the private sector. To make headway into those diverse markets, he will need to confront abundant new constraints and challenges.

José begins his study of SE by skimming the SEBoK Introduction and the Scope and Context of the SEBoK to get an overview of the SEBoK contents. As he reads, he sometimes refers to the Software Engineering Body of Knowledge (SWEBoK) (Bourque and Fairley 2014), which José already knows from his many years of experience on software projects. In the SEBoK, José is looking for nuggets of knowledge and pointers that can help his enterprise expand. Here are his notes:

  • Part 3: Systems Engineering and Management has concepts that are new to us and that may work. Extra system-level verification and validation (V&V) gates identified in Life Cycle Models can be incorporated in company processes, and the references can help with implementation details. There is also material about system-wide procedures beyond software V&V, and about where to find testing and regulation standards used by various government entities. Together with the traditional software testing already in place, these processes could ensure conformity to the regulations and expedite the product's approval for use.
  • Though the system concept is proven, the company must still convince potential buyers of the system's financial benefits while demonstrating that all security criteria are satisfied. To do that, we must better understand the needs of the stakeholdersstakeholders. In expressing system requirements and benefits, we need to start using the terminology of users, corporate/government purchasers, and regulatory agencies. Stakeholder Needs and Requirements is relevant here. The company needs to quantify expected return on investment (ROI) for its products.
  • System Realization addresses our broader V&V concerns. We need to demonstrate the measures we are taking to boost reliability of system performance. The standard models and measures for system reliability described in the SEBoK are new to us — now staff must develop tests to quantify important attributes. We may want to model reliability and system adherence to regulations using a form of model-based systems engineeringmodel-based systems engineering (MBSE). We can learn more about this from the references.
  • Systems Engineering Management makes it clear that new configuration management (CM) and information management (IM) procedures need to be adopted for federal database controls and integrity. We can use the references in Systems Engineering Standards to learn how to define processes and develop test cases.
  • Part 5: Enabling Systems Engineering makes a convincing case that having the right people for a new systems engineering culture is critical. We should probably hire a systems engineer or two to augment our engineering department expertise.
  • Our application must deal with private data concerns, and Part 7: Systems Engineering Implementation Examples, particularly the FBI Virtual Case File System Case Study, could help us avoid pitfalls that have hurt others in similar situations. We can put this in context based on Security Engineering in Part 6: Related Disciplines, and then follow up with further study based on the references.

Now José feels that he is better prepared to adapt his processes for new system lifecycles and environments, and that he can see a clear path through the morass of agencies and regulations. His priorities are to quantify the value proposition for his technology innovations, make inroads into new markets, and strengthen his staff for the long-term enterprise.

Vignette: Mechanical Engineer

Cindy Glass is a mechanical engineer whose experience in the petroleum industry has focused on large-scale oil extraction equipment in the field. Now Cindy is tasked with helping to manage the development of new offshore oil platforms featuring robotic technology and computer networks. This calls for incorporating SE principles from day one to cope with the systems considerations, which are broader than anything in Cindy's previous experience.

Some of the drilling is to be done with remote-controlled, unmanned underwater vehicles (UUVs). Along with safety, which was always a major concern, cybersecurity now takes center stage. Hostile state actors, “hacktivists,” or others could cause havoc if they succeed in taking control of the remote vehicles or other infrastructure. Unfortunately, software system implementation is completely new to Cindy, who realizes that this entails dealing with many more engineering disciplines and dimensions of system constraints than she previously encountered.

Cindy is accustomed to implementing minor design changes in existing equipment, with automation and safety guidelines already in place. Now she is starting from scratch with the earliest stages of the platform lifecycle. While Cindy understands tradeoffs involving mechanical sub-systems like rigs and drilling materials, she must now broaden her system analysis to include new environmental constraints and system security.

Cindy consults the SEBoK and discovers that for her effort to understand system design with many "-ilities," System Realization is a good starting point and its references should provide the in-depth information she needs.

The project lifecycle requires pursuing several major activities concurrently:

  • engineering platform sub-components
  • evaluating technology opportunitiesopportunities
  • understanding the needs of all stakeholdersstakeholders inside and outside the company
  • progressing through increasingly detailed prototypes, working slices of software, system specifications, designs, plans, business cases, and security and safety analyses of the platform architecture and its operations.

To understand how to manage such a project lifecycle, Cindy turns to Part 3: Systems Engineering and Management. The planning section provides detailed advice for starting out. Cindy expects to conduct her management activities on a rigorous basis, to consider the interfaces between the engineering specialties, and to produce a project plan that calls for a broad set of integrated management and technical plans.

Being new to the software development world, Cindy reads The Nature of Software and Key Points a Systems Engineer Needs to Know about Software Engineering, and consults the SWEBoK for references on software engineering.

These readings show Cindy how closely systems engineering and software engineering are intertwined. For example, they remind her to include security specialists at both the software level and the systems level from the beginning.

From her initial plunge into study of the SEBoK, Cindy has gained an appreciation of the wide range of system constraints for which she must account, and the many engineering disciplines she must work with as a result. She plans to consult the references in the SEBoK on each unfamiliar subject that she encounters throughout the architecting, design, development and deployment of the new platforms.

Summary

Engineers from disciplines other than systems engineering benefit from the insights about SE principles that the SEBoK provides. Studying the knowledge areas highlighted in this use case and the sources to which their references point can help such engineers become more interdisciplinary. Ultimately, they can consider broadening their work responsibilities, rendering them more valuable to their employers and society.

References

Works Cited

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

Primary References

None.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023