Difference between revisions of "Key Points a Systems Engineer Needs to Know about Software Engineering"
| Line 1: | Line 1: | ||
| − | + | 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. | ||
| + | |||
==Adaption of SE Methods== | ==Adaption of SE Methods== | ||
| Line 16: | Line 21: | ||
| | | | ||
*Stakeholder Analysis | *Stakeholder Analysis | ||
| − | *Requirements Engineering | + | *Requirements Engineering |
| − | *Functional Decomposition | + | *Functional Decomposition |
| − | *Design Constraints | + | *Design Constraints |
| − | *Architectural Design | + | *Architectural Design |
| − | *Design Criteria | + | *Design Criteria |
| − | *Design Tradeoffs | + | *Design Tradeoffs |
*Interface Specification | *Interface Specification | ||
*Traceability | *Traceability | ||
| − | *Configuration Management | + | *Configuration Management |
*Systematic Verification And Validation | *Systematic Verification And Validation | ||
| + | |||
| | | | ||
| − | *Model-Driven Development | + | *Model-Driven Development |
| − | * | + | *UML-SysML |
| − | *Use Cases | + | *Use Cases |
| − | *Object-Oriented Design | + | *Object-Oriented Design |
| − | *Iterative Development | + | *Iterative Development |
| − | *Agile Methods | + | *Agile Methods |
| − | *Continuous Integration | + | *Continuous Integration |
| − | + | *Process Modeling | |
| − | *Process Modeling | + | *Process Improvement |
| − | *Process Improvement | + | *Incremental V&V |
|} | |} | ||
| + | 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. | ||
| − | + | #'''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. | |
| − | + | #'''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 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. | |
| − | + | #'''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 but 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. | |
| − | + | #'''Often, requirements allocated to software must be renegotiated and reprioritized.''' | |
| − | + | Software engineers often, from their point of view, 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 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. | |
| − | + | #'''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 have the goal of limiting the 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, 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). | |
| − | + | #'''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. | ||
| + | #'''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. | ||
==References== | ==References== | ||
Revision as of 17:07, 8 February 2012
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.
Adaption of SE Methods
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 |
|---|---|
|
|
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.
- 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.
- 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 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.
- 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 but 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.
- Often, requirements allocated to software must be renegotiated and reprioritized.
Software engineers often, from their point of view, 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 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.
- 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 have the goal of limiting the 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, 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).
- 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.
- 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.
References
Citations
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.5. Please provide any recommendations on additional references in your review.