Key Points a Systems Engineer Needs to Know about Software Engineering
In order to describe the methods and techniques shared by systems engineering and software engineering, it is helpful to distinguish between the engineering of software and the construction of software. Software engineers, like systems engineers, engage in analysis and design, allocation of requirements, component integration, verification and validation, re-engineering of software systems, life cycle sustainment, and system retirement. Software specialists, who are often called programmers, construct software by engaging in detailed design, writing of code, unit testing, and integration of the software components. Programmers often modify existing software or obtain software components from libraries and publicly accessible (open) sources. Software engineers, like systems engineers, work with component specialists (e.g., user interface, database, computation, 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 ways of applying the problem solving techniques listed in Table 1 and
different uses of shared terminology based on the contrasting natures of the software medium and the physical media of traditional engineering.
This article briefly highlights ten things that differentiate software engineering from systems engineering.
Note to reviewers: this is a work in progress. Your comments are invited.
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 |
|---|---|
|
Software engineers, like systems engineers, are often involved in managing the technical aspects of a project or program. Thus, both software engineers and systems engineers need to understand how project management techniques, such as those included in the Project Management Institute’s Body of Knowledge (PMBOK®) are applied to technical management of software projects (PMI 2008; SWEBOK 2004; Fairley 2009).
These commonalities would make it appear that software engineering is merely an application of systems engineering, but this is only how it appears on the surface. The differences between the two disciplines arise from two fundamental issues:
- Differences in educational backgrounds and work experiences that result in different uses of shared terminology and different ways of applying the problem solving techniques listed in Table 1.
- Differences in application of shared terminology based on the contrasting natures of the software medium and the physical media of traditional engineering.
Education and Work Experience
Systems engineers typically receive a traditional engineering education based on continuous mathematics and physics; as a result, systems engineers, being traditional engineers, are strongly oriented to metrics and models. A software engineer's education and work experiences are typically based on discrete mathematics and information theory; software engineers approach problem solving from an algorithmic point of view. However, systems engineers often think algorithmically and software engineers use metrics and models, but the predominant mindsets and approaches to problem solving of systems engineers and software engineers are observably different.
Systems engineers and software engineers use common terms to denote different concepts. For example, "performance" is used by systems engineers to denote the entire operational envelope of a system, whereas software engineers use "performance" to mean response time and throughput of a software-intensive system. "Iterative development" also has a different connotation for systems engineers and software engineers. An iteration cycle for software development may occur on a daily or weekly basis, while the physical nature of physical system components typically involves iterative cycles of longer durations (sometimes months). Configuration management and version control have different connotations between the two disciplines as well. The frequent iterations of software development result in frequent incremental versions of evolving software, often on a weekly basis, whereas baselining of physical artifacts under development typically occurs at infrequent intervals. Risk management for development of hardware components is often concerned with issues such as supply chain management, material science, and manufacturability. In software engineering, risk management often focuses on issues based on communication problems and coordination difficulties within software development teams, among software development teams, and between software developers and other team members (e.g., hardware developers, technical writers, and those who perform independent verification and validation). The term "prototyping" also creates confusion. For a systems engineer a hardware prototype is typically the first, fully functioning version of a system. In software, prototyping is primarily used as a mechanism to elicit requirements by iteratively evolving mock-ups of user interfaces and as an experimental implementation of some limited elements of a system to explore and evaluate alternative algorithms.
Better understanding of these issues will enable systems engineers and software engineers to better communicate and to coordinate their work activities.
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.