Specialising in Software Engineering

Developing a software-intensive system is engineering in the traditional sense: creating an artifact which transforms the physical world to meet some recognised need. The artifact is the hardware-software machine; the physical world is the system\´s environment; and the recognised need is the requirement. For a successful development the entailment must hold: "machine, environment, requirement". By formalising the requirement and relevant environment properties, we may hope to bring the whole development within the ambit of formal development methods, improving our ability to produce a machine that will reliably ensure satisfaction of the requirement. This hope is appealing, but too simple. The nature of software-intensive systems poses rich challenges that cannot be addressed by formal reasoning alone but demand sharply focused practical disciplines. Discrete complexity, proliferation of interacting features and interoperation between disparate systems must all be reconciled with high levels of reliability, safety and security, in the context of systems that combine formal software with a non-formal environment in a tight cooperation. They challenge us to evolve rigorous and effective treatments of their non-formal worlds and of the interactions of those worlds with the formal artifacts we build. Here there is much to be learned from the established branches of engineering. The most conspicuous characteristic of the established branches of engineering is their specialised nature. For each class of artifact, the creation and gradual enrichment of a particular specialism, over many years, has allowed engineers to address both the positive and the negative requirements of the class. Positive requirements embody desired system functionality and efficiency, and evolve by invention and improved technology. Negative requirements embody the avoidance or mitigation of defects and failures that have manifested themselves in the past or can be foreseen. The non-formal world f- - urnishes unbounded possibilities of failure. Because every formalisation is in some degree incorrect or unreliable, and its alphabet inevitably excludes phenomena that may yet prove disastrously significant, negative requirements can never be exhaustively enumerated. Dependability in addressing negative requirements is improved chiefly by the experience, recognition, and analysis of failures. To avoid repeating those failures engineers need a structure of concepts and practice that allows the lessons to be recorded, disseminated, and applied. Specialisation is the sine qua non of such a structure. For each class of artifact and system it nourishes the creation and growth of a sharply focused normal design discipline, in which the design engineer knows at the outset how the system must work at every level, what features it must have, and how its parts are to be configured. Such a standardised design explicitly satisfies the positive requirements and implicitly satisfies the currently known negative requirements. Further, practice of the design discipline directs the engineer\´s attention to specific concerns that are known or expected to merit special care if failure is to be avoided. Specialisation and normal design have enabled the established engineering branches to deal increasingly successfully with the non-formal physical world. Software engineering must similarly identify the dimensions of specialisation that will improve system dependability. Approaches based on erecting a specification firewall to isolate the formal software world of computer science from its non-formal environment cannot succeed. In a software- intensive system, interaction at the interface between the machine and its environment darts back and forth along the arcs of a dependency graph that embraces both machine and environment, and frustrates the desire for a total separation of concerns between the formal and the non-formal. This challenge to software engineering can be met only by s