The projects of methods integration

The papers presented at the workshop represent a wide range of perspectives on methods integration, but most of the contributors acknowledge the formative role played by the work done at Leeds Metropolitan University since 1989. This introduction offers an overview of this early work, together with a summary of the presentations and discussions at the workshop itself. Methods Integration The idea of a method for software development only emerged once people’s conceptions of the activity grew from programming pure-and-simple to a wider view encompassing a range of activities other than the coding itself. From this, the idea of a procedure and range of practices for software development began to evolve. This is not to say that such practices were not undertaken by software developers prior to that; but it is to note that at some point people saw the necessity to start unravelling, explaining and formulating the craft of the software developer. By the mid-1960s programming started to develop a formal, mathematical basis with the publication of work by, for instance, Bohm and Jacopini [1]. This afforded a foundation for assessing and guiding the process of developing software; and hence the possibility of developing methods for producing code. From this foundation there emerged both the languages oriented to modular development and implementation, and the possibility of designing in a modular fashion prior to coding itself. This meant that software development could be described both in terms of what the code should look like, and how it should be produced. The former idea is concerned with models of program structure, the latter with the procedures required to arrive at adequate and correct structures. The combination of the two gives rise to methods. Early methods were often focused around a single model or abstraction; concentrated on detailed design and the transition from the design abstraction to the implementation. Thus Yourdon and Constantine’s text on Structured Design [2] was concerned with the procedure for designing code in a modular fashion: Assessing the modular structure in terms of control, coupling and cohesion; then moving from this language-independent model to an implementation. To some extent such methods were an embodiment of existing practice and craft wisdom, allied with some of the mathematical models then available. They achieved popularity since they could be used in the training of programmers on a large scale: And general design skills could be imparted in addition to the syntax of specific languages. By the late 1970s and early 1980s, however, the motivation to develop standard approaches to software development had expanded, to include wider aspects of the target domain and earlier activities in the development cycle. This meant that transitions other than that from design to coding were involved, and that these concerned more than one abstraction or model. Furthermore the models were meant to be accessible to an audience outside the specialized domain of software developers. A system specification could no longer be seen purely in terms of an engineering blueprint, but had also to serve as a scale model or partial representation for examination and assessment by clients and/or potential users. This resulted in a number of graphical models being introduced, whose main feature was that they were comprehensible by clients who had domain expertise but no software expertise. (The key test of comprehensibility being that clients could indicate errors and omissions in the models presented to them, rather than simply giving nodding assent.) The most ubiquitous of these early models was the dataflow diagram (DFD), developed from the pre-computer systems analysis and O&M (organization and methods) use of document flow diagrams or bubble charts. The earliest efforts at extending the method of design into analysis concentrated almost exclusively on producing DFDs (e.g. DeMarco [3]) as a basis for the structured design of the program modules themselves. But eventually the idea of a method for developing an entire system, as opposed to the software for a single program or suite of programs, demanded a range of models each concerned with a key aspect of the system. Once this idea took root, methods such as Yourdon Structured Analysis, Information Engineering, SSADM and many others gained in popularity. These methods were promoted as all-encompassing solutions to development problems, but this was an overly optimistic view of the power of such methods, and a severe underestimate of the complexity of most of the systems under consideration. In fact there were literally hundreds of systems development methods (SDMs) in the 1980s. Many