Key Points a Systems Engineer Needs to Know about Software Engineering

Software engineers, like systems engineers, engage in analysis and design, allocation of requirements, oversight of component development, component integration, verification and validation, life cycle sustainment, and system retirement. Software engineers, like systems engineers, work with component specialists (for example, user interface, database, computation, and communication specialists) who construct or otherwise obtain the needed software components. Software engineers, like systems engineers, may be component specialists for certain kinds of components; they engage with other kinds of software component specialists as necessary. Sometimes software engineers, like systems engineers, adapt existing components and incorporate components supplied by customers and affiliated organizations. These commonalities would make it appear that software engineering is merely an application of systems engineering, but this is only a surface appearance. The differences between the two disciplines arise from two fundamental issues:

• Differences in educational backgrounds and work experiences that result in different approaches to problem solving, and
• Different ways of applying shared concepts based on the contrasting natures of the software medium and the physical media of traditional engineering. Table 1 itemizes some of the shared concepts that are applied in different ways by systems engineers and software engineers.

Each discipline has made contributions to the other. Table 1 indicates the methods and techniques developed by systems engineers adapted for use by software engineers, and conversely those that have been adapted for use by systems engineers.

Table 1. Adaptation of Methods Across Systems Engineering and Software Engineering (Fairley and Willshire 2011) Reprinted with permission of Dick Fairley and Mary Jane Willshire.

Systems Engineering Methods Adapted to Software Engineering	Software Engineering Methods Adapted to Systems Engineering
Stakeholder Analysis Requirements Engineering Functional Decomposition Design Constraints Architectural Design Design Criteria Design Tradeoffs Interface Specification Traceability Configuration Management Systematic Verification And Validation	Model-Driven Development UML-SysML Use Cases Object-Oriented Design Iterative Development Agile Methods Continuous Integration Process Modeling Process Improvement Incremental V&V

Ten Things a Systems Engineer Needs to Know

The following ten items are some of the significant things that systems engineers who are not familiar with software should know about software and software engineering.

Note to reviewers: this list is a work in progress. Your comments are welcomed.

1. For the time, effort, and expense devoted to developing it, software is more complex than most other system components. Software complexity arises because few elements in a software program (even down to the statement level) are identical and because of the large number of possible decision paths in (even) small programs. The number of decision paths through a large program is often astronomical.
2. Software testing and reviews are sampling processes.In all but the simplest cases the exhaustive testing of software is impossible because of the large number of decision paths through most programs and because the combined values of the input variables selected from a wide combinatorial range may reveal defects that other combinations of the variables would not detect. Software test cases and test scenarios are chosen in an attempt to gain confidence that the testing samples are representative of the ways the software will be used in practice. Structured reviews of software are an effective mechanism for finding defects but the effort that would be required prevents exhaustive reviewing; criteria must be established to determine which components (or sub-components) should be reviewed. Although there are similar concerns about exhaustive testing and reviewing of physical products, the complexity of software makes software testing and reviews and the resulting assurance (or lack of assurance) provided different in kind.
3. Software often provides the interfaces that interconnect other system components. Software is often referred to as the “glue” that holds a system together because the interfaces among components, as well as the interfaces to the environment and other systems, are often provided by digital sensors and controllers that operate via software. Because software interfaces are behavioral rather than physical, the interactions that occur among software components often exhibit emergent behaviors that cannot always be predicted in advance. In addition to component interfaces, software usually provides the computational and decision algorithms needed to generate command and control signals.
4. Every software product is unique. The goal of manufacturing physical products is to produce replicated copies that are as nearly identical as possible, given the constraints of material sciences and manufacturing tools and techniques. Because replication of existing software is a trivial process (as compared to manufacturing of physical products), the goal of software development is to produce one perfect copy (or as nearly perfect as can be achieved given the constraints on schedule, budget, resources, and technology). Much of software development involves modifying existing software. The resulting product, whether new or modified, is uniquely different from all other software products known to the software developers; otherwise, they would use existing software.
5. Often, requirements allocated to software must be renegotiated and reprioritized. Software engineers often see more efficient and effective ways to restate and prioritize requirements allocated to software; sometimes the renegotiated requirements have system-wide impacts that must be taken into account. One or more senior software engineers should be, and often are, involved in analysis of system-level requirements.
6. Software requirements are prone to frequent change. Software is the most frequently changed component in most complex systems. Especially late in the development process and during system sustainment because software is perceived to be the most easily changed component of a complex system. This is not to imply that changes to software requirements, and the resulting changes to the impacted software, can be easily done while avoiding undesired side effects of the changes.
7. Small changes to software can have large negative effects. A corollary to frequently changing software requirements: “there are no small software changes.” In several well-known cases, modifying a few lines of code in very large systems that incorporated software negatively impacted safety, security, or reliability of those systems. Applying techniques such as traceability, impact analysis, object-oriented software development, and regression testing limit undesired side effects of changes to software code; these approaches reduce but do not eliminate this problem.
8. Some quality attributes for software are subjectively evaluated. Software typically provides the interfaces to systems that have human users and operators. The intended users and operators of these systems often subjectively evaluate quality attributes such as ease of use, adaptability, robustness, and integrity. These quality attributes determine the acceptance of a system by its intended users and operators. In some cases, users have rejected systems because they were not judged to be suitable for use by the intended users in the intended environment even though those systems satisfied their technical requirements (i.e., they were verified but not validated).
9. The term “prototyping” has different connotations for systems engineers and software engineers. For a systems engineer, a hardware prototype is typically the first functioning version of the hardware. In software prototyping is primarily used for two purposes: 1) as a mechanism to elicit user requirements by iteratively evolving mock-ups of user interfaces and 2) as an experimental implementation of some limited element of a proposed system to explore and evaluate alternative algorithms.
10. Cyber security is a present and growing concern for systems that incorporate software. In addition to the traditional specialty disciplines of safety, reliability, and maintainability, systems engineering teams increasingly include security specialists at both the software level and the systems level in an attempt to cope with the cyber attacks that may be encountered by systems that incorporate software. Additional information about Security Engineering can be found in Systems Engineering and Specialty Engineering.

References

Works Cited

Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. SWEBOK: Guide to the Software Engineering Body of Knowledge. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok

Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley and Sons.

Fairley, R.E. and M.J. Willshire. 2011. "Teaching software engineering to undergraduate systems engineering students." Proceedings of the 2011 American Society for Engineering Education (ASEE)  Annual Conference and Exposition. 26-29 June 2011. Vancouver, BC, Canada.

PMI. 2008. A Guide to the Project Management Body of Knowledge, 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Primary References

Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. SWEBOK: Guide to the Software Engineering Body of Knowledge. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok

Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley and Sons.

PMI. 2008. A Guide to the Project Management Body of Knowledge, 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).

Additional References

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

---

< Previous Article | Parent Article | Next Article >

Comments from SEBoK 0.5 Wiki

Please note that in version 0.5, this article was titled “Systems Engineering and Software Engineering: Similarities and Differences”.

<html> <iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Software_Engineering_and_Systems_Engineering:_Similarities_and_Differences&printable=yes" width=825 height=200 frameborder=1 scrolling=auto> </iframe> </html>

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