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 makes it necessary for systems engineers to be knowledgeable about software engineering and its relationship to systems engineering.

Key Concepts a Systems Engineer Needs to Know about Software Engineering

The following items are significant aspects that systems engineers need to know about software and software engineering. Most are documented in (Fairley and Willshire 2011):

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 as well as because of the large number of possible decision paths found even in small programs, with the number of decision paths through a large program often being astronomical. There are several detailed references on software complexity. The SWEBOK (Bourque and Fairley 2014) discusses minimizing complexity as part of software construction fundamentals. Zuse (1991) has a highly cited article on software complexity measures and methods. Chapters 2 and 3 of the SWEBOK also have further references.
2. 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:
   1. 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.
   2. Exhaustive testing is not possible.
   3. Errors in software tend to cluster within the software structures; therefore, any one specific approach or a random approach to testing is not advised.
   4. Pesticide paradox exists. As a result, running the same test over and over on the same software-system provides no new information.
   5. Testing can reveal the presence of defects but cannot guarantee that there will be no errors, except under the specific conditions of a given test.
   6. Testing, including verification and validation (V&V), must be performed early and continually throughout the lifecycle (end to end.
   7. Even after extensive testing and V&V, errors are likely to remain after long term use of the software.
   8. Chapter 4 of the SWEBOK discusses software testing and provides a bibliography.
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. The SWEBOK has multiple discussions of interfaces: Chapter 2 on Software Design is a good starting point and includes a bibliography.
4. Every software product is unique - The goal of manufacturing physical products is to produce replicated copies that are as nearly identical as much 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 altering existing software. The resulting product, whether new or modified, is uniquely different from all other software products known to the software developers. Chapter 4 of the SWEBOK provides additional references.
5. In many cases, 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. This topic is addressed in the SWEBOK in Chapter 1, with topics on the iterative nature of software and change management.
6. 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 due to the fact that 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. Careful software configuration management is necessary, as discussed in Chapter 6 of the SWEBOK, which has extensive references.
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 the safety, security, and/or reliability of those systems. Applying techniques such as traceability, impact analysis, object-oriented software development, and regression testing reduces undesired side effects of changes to software code. These approaches limit 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, 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. Chapter 10 of the SWEBOK provides an overview of software quality, with references.
9. 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. Chapter 1 of the SWEBOK discusses this and provides excellent references.
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 the Systems Engineering and Specialty Engineering KA.
11. Software growth requires spare capacity - Moore’s Law no longer fully comes to the rescue. As systems adapt to changing circumstances, the modifications can most easily be performed and upgraded in the software, requiring additional computer execution cycles and memory capacity (Belady and Lehman 1979). For several decades, this growth was accommodated by Moore’s Law (Moore, 1965), but recent limits that have occurred as a result of heat dissipation have influenced manufacturers to promote potential computing power growth by slowing down the processors and putting more of them on a chip. This requires software developers to revise their programs to perform more in parallel, which is often an extremely difficult problem (Patterson 2010). This problem is exacerbated by the growth in mobile computing and limited battery power.
12. Several Pareto 80-20 distributions apply to software - These refers to the 80% of the avoidable rework that comes from 20% of the defects, that 80% of the defects come from 20% of the modules, and 90% of the downtime comes from at most 10% of the defects (Boehm and Basili 2001). These, along with recent data indicating that 80% of the testing business value comes from 20% of the test cases (Bullock 2000), indicate that much more cost-effective software development and testing can come from determining which 20% need the most attention.

References

Works Cited

Belady, L. and M. Lehman. 1979. "Characteristics of Large Systems." In P. Wegner (ed.), Research Directions in Software Technology. Cambridge, MA, USA: MIT Press.

Boehm, B. and V. Basili. 2001. "Software defect reduction Top 10 List." Computer. 34(1):135-137.

Bullock, J. 2000. "Calculating the Value of Testing." Software Testing and Quality Engineering, May-June, 56-62.

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.

Moore, G.E. 1965. "Cramming more components onto integrated circuits," Electronics Magazine, April 19, 4.

Patterson, D. 2010. "The Trouble With Multicore." IEEE Spectrum, July, 28-32, 52-53.

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. Bourque 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 & Sons.

PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 5th 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.

---

< Previous Article | Parent Article | Next Article >

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