Key Points a Systems Engineer Needs to Know about Software Engineering
The field of software engineering is extensive and specialized. Its importance to modern systems means that systems engineers must be knowledgeable about software engineering and its relationship to systems engineering.
Ten Things a Systems Engineer Needs to Know
The following ten items are significant aspects that systems engineers need to know about software and software engineering (Fairley and Willshire 2011):
- 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 found even in small programs The number of decision paths through a large program is often astronomical. There are several detailed references on software complexity. Chapter 4 of the SWEBOK (Abran and Moore, 2004) discusses minimizing complexity as part of the software construction fundamentals. Zuse (1991) has a highly cited article on software complexity measures and methods.
- Software testing and reviews are sampling processes. In all but the simplest cases, exhaustive testing of software is impossible because of the large number of decision paths through most programs. Also, 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 significant effort required limits 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, reviews, and the resulting assurance provided, more challenging. Other points include:
- All software testing approaches and techniques are heuristic. Hence, there is no universal best approach, practice, or technique for testing, since these must be selected based on the software context;
- Exhaustive testing is not possible;
- Errors in software tend to cluster within the software structures. Therefore, any one specific approach or a random approach to testing is not advised;
- Pesticide paradox exists. As a result, running the same test over and over on the same software-system provides no new information;
- Testing can reveal the presence of defects but cannot guarantee no errors, except under the specific conditions of a given test;
- Testing, including verification and validation (V&V), must be performed early and continually throughout the lifecycle (end to end); and
- Even after extensive testing and V&V, errors are likely to remain after long term use of the software.
- 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.
- 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.
- 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.
- Software requirements are prone to frequent change. Software is the most frequently changed component in complex systems, especially late in the development process and during system sustainment. This is 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 without undesired side effects.
- 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 the safety, security, or reliability of those systems. Applying techniques such as traceability, impact analysis, object-oriented software development and regression testing limits undesired side effects of changes to software code. These approaches reduce but do not eliminate this problem.
- 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, systems have been rejected 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.
- The term 'prototyping' has different connotations for systems engineers and software engineers. For a systems engineer, a prototype is typically the first functioning version of a hardware. For software engineers, 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.
- 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 the Systems Engineering and Specialty Engineering KA.
References
Works Cited
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.
Zuse, Horst. 1991. Software Complexity: measures and methods. Hawthorne, NJ, USA: Walter de Gruyter and Co.
Primary References
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. Guide to the Software Engineering Body of Knowledge (SWEBOK). 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 (PMBOK® Guide), 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
Additional References
Pyster, A., M. Ardis, D. Frailey, D. Olwell, A. Squires. 2010. "Global workforce development projects in software engineering". Crosstalk- The Journal of Defense Software Engineering, Nov/Dec, 36-41. Available at: http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA535633
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