ing natural forces and a dizzying array of non-technical economic, statutory, societal, and logical constraints. Software engineering is similar except that fewer forces involve the natural world.

˲ Adapting to changing environments. Most environments that use computing constantly change and expand. With drawn-out acquisition processes for complex software systems, it is not unusual for the system to be obsolete by the time of delivery. What waste! Mastering evolutionary development is the new challenge. ²

the system

The problems surrounding the six issues listed here are in large measure the consequence of an overly narrow view of the system for which the software engineer is responsible. Although controlled by software, the system is usually a complex combination of software, hardware, and environment.

Platform independence is an ideal of many software systems. It means that the software should work under a choice of operating systems and computing hardware. To achieve this, all the platform-dependent functions are gathered into a platform interface module; then, porting the system to another platform entails only the building of that module for the new platform. Examples of this are the Basic Input-Output System (BIOS) component of operating systems and the Java Virtual Machine (JVM). When this can be achieved, the software engineer is justified in a software-centric view of the system.

But not all software systems are platform independent. A prominent example is the control system for advanced aircraft. The control system is implemented as a distributed system across many processors throughout the structure where they can be close to sensors and control surfaces. Another example is software in any large system that must constantly adapt in a rapidly changing environment. In these cases the characteristics of the hardware, the interconnections, and the environment continually influence the software design. The software engineer must either know the system well, or must interact well with someone who does. In such cases adding

We need to encourage
system thinking that
embraces hardware
and user environment
as well as software.

a system engineer to the team will be very important.

engineering team

No matter what process engineers use to achieve their system objectives, they must form and manage an engineering team. Much has been written on this topic. Software engineering curricula are getting better at teaching students how to form and work on effective teams, but many have a long way to go.

Every software team has four important roles to fill. These roles can be spread out among several people.

The software architect gathers the requirements and turns them into specifications, seeks an understanding of the entire system and its trade-offs, and develops an architecture plan for the system and its user interfaces.

The software engineer creates a system that best meets the architecture plan. The engineer identifies and addresses conflicts and constraints missed by the architect, and designs controls and feedbacks to address them. The engineer also designs and oversees tests. The engineer must have the experience and knowledge to design an economical and effective solution with a predictable outcome.

The programmer converts the engineering designs into working, tested code. Programmers are problem-solv-ers in their own right because they must develop efficient, dependable programs for the design. Moreover, anyone who has been a programmer knows how easy it is to make mistakes and how much time and effort are needed to detect and remove mistakes from code. When the software engineer has provided a good specification, with known exceptions predefined and controls clearly delineated, the pro-

grammer can work within a model that makes the job of implementation less error-prone.

The project manager is responsible for coordinating all the parts of the team, meeting the schedules, getting the resources, and staying within budgets. The project manager interfaces with the stakeholders, architects, engineers, and programmers to ensure the project produces value for the stakeholders.

In some cases, as noted previously, a systems engineer will also be needed on the team.

conclusion

We have not arrived at that point in software engineering practice where we can satisfy all the engineering criteria described in this column. We still need more effective tools, better software engineering education, and wider adoption of the most effective practices. Even more, we need to encourage system thinking that embraces hardware and user environment as well as software.

By understanding the fundamental ideas that link all engineering disciplines, we can recognize how those ideas can contribute to better software production. This will help us construct the engineering reference discipline that Glass tells us is missing from our profession. Let us put this controversy to rest.

 

References

1. denning, P. computing is a natural science. Commun.

ACM 50, 7 (July 2007), 13–18.

2. denning, P., gunderson, c., and hayes-roth, r. evolutionary system development. Commun. ACM 51, 12 (dec. 2008), 29–31.

3. denning, P. et al. computing as a discipline. Commun. ACM 32, 1 (Jan. 1989), 9–23.

4. glass, r., Vessey, i., and ramesh, V. research in software engineering: an analysis of the literature. Information and Software Technology 44, 8 (2002), 491–506.

5. riehle, r. an engineering context for software engineering. Ph.d. thesis, 2008; theses.nps.navy. mil/08sep_riehle_Phd.pdf.

6. riehle, r. engineering on the surprise continuum: as applied to software practice. ACM SIGSOF T Software Engineering News 30, 5 (sept 2005), 1–6.

7. sangwan, r., lin, l-P, and neill, c. structural complexity in architecture-centric software. IEEE Computer (mar. 2008), 96–99.

8. tichy, W. should computer scientists experiment more? IEEE Computer (may 1998), 32–40.

Peter J. Denning ( [e-mail]) is the director of the cebrowski institute for information innovation and superiority at the naval Postgraduate school in monterey, ca, and is a past president of acm.

Richard Riehle ( [e-mail]) is a visiting professor at naval Postgraduate school in monterey, ca, and is author of numerous articles on software engineering and the popular textbook Ada Distilled.