The Nature of Software
The nature of the software medium has many consequences for systems engineering (SE) of software-intensive systems. Fred Brooks has famously observed that four properties of software, taken together, differentiate it from other kinds of engineering artifacts (Brooks 1995):
- complexity;
- conformity;
- changeability; and
- invisibility.
Brooks states:
Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine — open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound. (Brooks 1987; Brooks 1995, 182)
Complexity
The complexity of software arises from the large number of unique interacting parts in a software system. The parts are unique because they are encapsulated as functions, subroutines, or objects, and invoked as needed rather than being replicated. Software parts have several different kinds of interactions, including serial and concurrent invocations, state transitions, data couplings, and interfaces to databases and external systems. Depiction of a software entity often requires several different design representations to portray the numerous static structures, dynamic couplings, and modes of interaction that exist in computer software. Complexity within the parts, and in the connections among parts, may result in a large amount of rework for a seemingly small change in requirements, thus hindering progress according to plan. For this reason, many experienced software engineers say there are no small requirements changes. Complexity can also hide defects that may not be discovered easily, thus requiring significant additional and unplanned rework later on.
Conformity
Software must conform to exacting specifications in the representation of each part, in the interfaces to other internal parts, and in the connections to the environment in which it operates. A missing semicolon or other syntactic error can be detected by a compiler. But, a defect in the program logic or a timing error may be difficult to detect when encountered during operation. Unlike software, tolerance among the interfaces of physical entities is the foundation of manufacturing and assembly; no two physical parts that are joined together have, or are required to have, exact matches. There are no corresponding tolerances in the interfaces among software entities or between software entities and their environments. Interfaces among software parts must agree exactly in numbers, types of parameters and kinds of couplings. For example, there are no interface specifications for software stating that a parameter can be an integer plus or minus 2%.
Lack of conformity can cause problems when an existing software component cannot be reused as planned, because it does not conform to the needs of the product under development. Lack of conformity might not be discovered until late in a project, thus necessitating the development and integration of an acceptable component to replace the one that cannot be reused. This requires an (usually) unplanned allocation of resources and can delay project completion. Complexity may have made it difficult to determine that the reused component lacked the necessary conformity until the components it would interact with were already completed.
Changeability
Changeability is the third of Brooks’ factors that make software development difficult. Software coordinates the operation of physical components and provides most of the functionality in software-intensive systems. Because software is the most easily changed element (i.e., the most malleable) in a software-intensive system, it is the most frequently changed element, particularly in the late stages of a development project or during system sustainment. However, this does not mean that software is easy to change. Complexity and the need for conformity can make changes to software an extremely difficult task. Changing one part of a software system often results in undesired side effects in other parts of the system that must then be changed.
Invisibility
The fourth of Brooks’ factors is invisibility. Software is said to be invisible because it has no physical properties. While the effects of executing software on a digital computer are observable, software itself cannot be seen, tasted, smelled, touched, or heard. Software is an intangible entity because our five human senses are incapable of directly sensing it. Work products such as requirements specifications, design documents, source code, and object code, are representations of software but they are not the software. At the most elemental level, software resides in the magnetization and current flow in an enormous number of electronic elements within a digital device. Because software has no physical presence, software engineers use different representations at different levels of abstraction in an attempt to visualize the inherently invisible entity.
Teams
In addition to the four essential properties of software identified by Brooks, one additional factor distinguishes software from other kinds of engineering artifacts. This factor is that software projects are team-oriented, intellect-intensive endeavors (Fairley 2009, 6).
Clearly, other kinds of engineers (including systems engineers) engage in team-oriented problem solving. Yet, unlike other engineering artifacts, there is no fabrication phase for software. Software is composed from the thoughts of software engineers that flows through their fingers onto a keyboard and into a computer. Software teams are necessary because it would take too much time for one person to develop a modern software system and also because it is unlikely that a single individual would possess the full range of skills required for this task. It has also been observed that the issues of team-oriented software development are similar to the issues that would be encountered if a team of authors were to write a novel as a collaborative project (Fairley 2009).
Uniqueness
Software and software projects are unique for the following reasons:
- software has no physical properties;
- software is the product of intellect-intensive teamwork;
- productivity of software developers varies more widely than the productivity of other engineering disciplines;
- estimation and planning for software projects is characterized by a high degree of uncertainty, which can be at best partially mitigated by best practices;
- risk management for software projects is predominantly process-oriented;
- software alone is useless as it is always a part of a larger system; and
- software is the most frequently changed element of software intensive systems.
References
Works Cited
Brooks, F. P. 1987. "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computer. 20(4) (April 1987): 10-19.
Brooks, F. 1995. The Mythical Man-Month, Anniversary Edition. Boston, MA, USA: Addison Wesley Longman Inc.
Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, New Jersey: John Wiley and Sons.
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
Brooks, F. 1995. The Mythical Man-Month, Anniversary Edition. Boston, MA, USA: Addison Wesley Longman Inc.
Fairley, R.E. 2009. Managing and Leading Software Projects. Hoboken, New Jersey: John Wiley and Sons.
Additional References
MITRE. 2011. "Design Patterns." Systems Engineering Guide. Accessed 6 March 2012 at [the MITRE site.]
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