Difference between revisions of "Guidance for Engineers"
Line 51: | Line 51: | ||
==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 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-control 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 has until now. | |
− | + | 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 now must now broaden her system analysis to include new environmental constraints and system security. . [[System Realization]] gives her references for system design with many ''ilities''. | |
− | |||
− | |||
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 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. |
Revision as of 20:15, 26 August 2012
Successful complex systems require bringing specialties together. This makes the SEBoK useful to engineers with backgrounds in biomedical, civil, electronics, chemical, civil, materials, mechanical, software, and many other specialties.
Studying the SEBoK enables engineers from disciplines other than systems engineering 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
- prepare to solve more difficult and encompassing problems
In many cases, engineers who study systems engineering as a supplement to their non-SE specialities 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:
- Part 1 provides an overview both of systems engineering and of the SEBoK itself
- Part 2 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
- Part 3 includes the knowledge areas of Life Cycle Models, System Definition, System Realization, and System Deployment and Use, all highly important when approaching study of SE from another discipline
- Also in Part 3, Systems Engineering Management includes such relevant topics as risk management, measurement, configuration management, and quality management
- Part 4 identifies the SE activities for four kinds of engineered systems, namely product, service, enterprise, and systems of systems
- 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
- Part 5, and especially Organizing Teams to Perform Systems Engineering, explains how systems and other types of engineers fit into the larger picture of enabling individuals and teams to perform systems engineering activities, and how SEs fit into the larger picture of systems engineering organizational strategies
- Part 6, 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 Specialty Engineering are naturally most essential for engineers in the respective disciplines
- Part 7 illustrates how systems engineering practices, principles, and concepts are applied in real settings, and contains much universally-useful insight
Engineers may be tempted to skip over knowledge areas or topics which sound more like management than engineering stories, for example 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
Jose 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 identity, travel and financial documents, with technology that runs on proprietary tablet computers for portable and fixed locations.
Jose 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 Jose 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.
Jose begins his study of SE by skimming the SEBoK 1.0 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), which Jose already knows from his many years of experience on software projects. In the SEBoK, Jose is looking for nuggets of knowledge and pointers that can help his enterprise expand. Here are his notes:
- Part 3: SE and Management has concepts that are new to us and that may work. Extra system-level 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 understand the needs of the stakeholders better. 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 ROI for investing in 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 Engineering (MBSE). We can learn more about this from the references.
- Systems Engineering Management makes it clear that new CM and 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, 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 Jose 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 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-control 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 has until now.
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 now must now broaden her system analysis to include new environmental constraints and system security. . System Realization gives her references for system design with many ilities.
The project lifecycle will require concurrent engineering of platform sub-components while evaluating technology opportunities, understanding the needs of all stakeholders inside and outside the company, and progressing through increasingly detailed prototypes, working slices of software, system specifications, designs, plans, business cases, security and safety analyses of the platform architecture and its operations.
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 integrated management and technical plans. Conception through Operations will have to involve all the disciplines.
Since she is new to working on software projects and with software engineers, she reads 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.
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.
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.
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.
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.
Primary References
None.
Additional References
None.
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