4.5 Methodologies associated with information technology
I recently undertook an exercise in a company that manufactures various types of agricultural machinery. I was happily using the term ‘system’ in its general sense when a senior manager stated ‘In this organization we use the word “system” to mean a computer system, for other types of procedure or activity we use “process”.’ This is a commonly encountered distinction and the evolution of computer systems, and particularly software, has been an important contributor to systems engineering.
During the period 1965–80 the first wave of mainframe-based computing swept through organisations, and associated with this came a host of new jobs. One of these was ‘systems analyst’. The work of systems analysts was to:
investigate the financial, technical and organisational feasibility of a computer application
design and agree the elements, structure and processes involved in the new system
specify the programs needed
write procedures and instructions
implement the new system.
In the ensuing years the word ‘system’ replaced earlier ideas of ‘procedure’ or ‘method’ in the lexicon of business improvement.
IBM, with its System 360 series of computers and later with the System 370 series, quickly came to dominate the market for mainframe-based computing. Confusingly, IBM called the people that it employed to help its customers with their applications ‘systems engineers’. Increasingly, the two terms ‘systems analysis’ and ‘systems engineering’ were used interchangeably in the development of information systems. Two related terms can now be distinguished: software system engineering and software engineering.
The conscious development of software engineering, as opposed to the practice of developing software as a craft, can be dated from a remark made by F.L. Bauer to a working party of the NATO Science Committee and subsequently to a conference held in Garmisch, Germany, in 1968 (Bauer, 1993). The reason for this development was statements made to the Scientific Committee by Bauer:
In a sudden mood of anger, I made the remark, ‘The whole problem comes from the fact that there is so much tinkering with software. It is not made in a clean fabrication process’, and when I found that this remark was shocking to some of my scientific colleagues, I elaborated the idea with the provocative saying, ‘what we need is software engineering.’
In an attempt at unification, a fusion of the two types of model has been proposed (Sage and Palmer, 1989; Andriole and Freeman, 1993). The argument put forward is that although information systems engineering and software engineering have existed for some time as separate methodologies, several factors have combined to make a new, common approach appropriate:
software-intensive systems are becoming more pervasive
there has been a failure to learn from past experiences, usually of an unwelcome kind
systems engineering is generic in character, being capable of application in diverse situations, but has the character of a ‘meta-methodology’ rather than being useful at a tactical, project level
software engineering is, in contrast, focused completely on the software components of a system.
Andriole and Freeman (1993) propose a system life cycle that aims to integrate four major collections of system development activities: goal-setting, planning, design and construction. They argue that these activities take on a different character or specific meaning depending on the stage of development of the project. They represent the life cycle as the ‘three-dimensional solid’ shown in Figure 43 and their explanation of the model is reprinted in Box 9.
Box 9 Andriole and Freeman's model
This life cycle bears a resemblance to Boehm's (1988) spiral model as a graphical device to represent the fact that the software systems engineer must make multiple passes through similar activities (concept development, prototyping, specification, design, implementation of the next level of technology). It also can trace some heritage back to Kerola and Freeman (1981) and others who first observed that system development involves a set of basic activities such as planning, design, implementation, and testing, all of which are in operation (to some extent) throughout the life cycle, being repeated with different emphases and contexts.
Looking down the time axis, the four quadrants represent four major collections of system development activities: goal setting, planning, design and construction. Each of these is an abstraction for a myriad of development activities, some of which span two quadrants. Depending on the position on the time axis, these activities take on different specific meanings. For example, needs analysis (labelled here as a ‘goal setting’ activity) at early stages of development is concerned with understanding the needs of the entire context in which a proposed system will be embedded (thus involving potential owners, clients, users and operators of the system). At later stages of development, however, the needs analysis activities might be concerned with determining the needs of a VDT operator (thus involving psychologists, terminal operators and medical experts).
The following definitions are intended to provide a non-exclusive outline of the activities that might be found in each quadrant.
Goal setting includes enterprise analysis, mission ‘planning’, needs analysis and most of the activities often associated with requirements engineering. Goal setting is front-end intensive and oriented to most aspects of the initial requirements analysis process.
Planning includes those activities that focus on or directly affect a large amount of development work, until the next planning phase appears in the life cycle. This includes prototyping, which provides fundamental information to help us decide how to proceed, project planning, which lays out detailed work schedules, and specification activities, which provide the detailed ‘work orders’ for future work.
Design includes those activities that devise the structures (organizational, hardware of all sorts, software, procedural) which, when implemented, will provide the suitably constrained functionality needed to meet the goals. We differentiate between high-level (architectural) and detailed design. Crossing into the construction realm are those activities concerned with individual components. In the case of software, this is the detailed programming activity.
Construction activities include the various levels of testing which range from unit or component testing to acceptance or field testing. The various activities involved in measuring a system's performance and effects are included in this quadrant.
In the three-dimensional solid described by this life cycle, different fields of expertise and different people can be seen to touch different quadrants at different levels (times). The volumes thus described are, of course, highly irregular. For example, psychology (in a broad sense) might come into play in the early stages of goal setting by providing an insight into the workings of a large organization and the potential effects of a new software-intensive way of doing business; at a later stage by providing detailed parameters for VDT formats; and during operation of a system, by providing us with the methodology for evaluating the effect of a system on its clients.
Progress over time in creating, operating and modifying a software-intensive system is represented by a spiral path downward through the solid. Although such a path can represent the ‘centroid’ of project activity over time, it is important to remember that a complex system will involve many (perhaps thousands of) people whose activities may be spread over a large volume of the model.
Operationally, software systems engineering will encompass an egg-shaped solid centred on the Z-axis of this model. On a linear scale, this volume of activities will be centred rather high up on the Z-axis as, once a system is fully operational, the involvement decreases rapidly (except when major modifications are needed). Likewise, the extent of the activities in the X-Y plane is not regular, reaching out during certain activities to include other expertise and contracting in other places. Overall, however, the extent of activities carried out by the software systems engineer is limited at the start, expands to a maximum during design and construction of the actual system, and tapers off once the system is fully operational and modifications have either ceased or decreased to a very low level.
The aim of Andriole and Freeman is to plug what they see as a gap between the generic systems engineering model illustrated in Figure 41 and the specific software engineering methodology shown in Figure 40. Do you consider that the model that they present (Figure 43) achieves this aim?
While the logic of Andriole and Freeman's argument is clear, the conceptual gap between systems and software engineering is certainly a growing problem. The solution that they present has a number of flaws.
It is true that some generic activities such as goal setting, planning, design, and construction may have to be carried out at different stages of the project, but the model does not convey clearly how this operates. Do the authors intend that each generic activity is undertaken at each stage of the life cycle? Is what they intend close to the model shown in Figure 44?
It is intended as an operational basis for software systems projects but falls far short of the requirements for such a methodology. It does not provide a stable basis for project planning since the number of ‘iterations’ within the solid are not specified. To the wary eye the model looks less sure-footed than either the systems or the software engineering models that it hopes to replace.