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):

1. complexity;
2. conformity;
3. changeability; and
4. 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. A seemingly “small” change in requirements is one of the many ways that the complexity of the product may affect the management of a project. Complexity within the parts, and in the connections among parts, may result in a large amount of rework for a “small” change in requirements, thus upsetting the ability to 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 immediately and thus require additional, unplanned rework later.

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 in 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 and types of parameters and kinds of couplings. 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 unplanned allocation of resources and can delay product 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. This does not, however, mean that software is easy to change; complexity and the need for conformity in software 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; our five human senses are incapable of directly sensing software; thus, software is an intangible entity. 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 (complexity, conformity, changeability, and invisibility), 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 and 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 because it is unlikely that one individual would possess the necessary range of skills. It has 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;
• the 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;
• risk management for software projects is predominantly process-oriented;
• software alone is useless as software is always a part of a larger system; and
• software is the most frequently changed element of systems that incorporate software.

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, NJ, USA: John Wiley and Sons.

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

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.]

---

< 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