Of primary importance in the UK in the last twenty years has been the development of Structured Systems Analysis and Design Methodology (SSADM).

The drive for a shorter development cycle has forced the adoption of methods for Rapid Applications Development (RAD).

Close on the heels of RAD has come Dynamic Systems Design Methodology (DSDM) and the DSDM Consortium.

For the present - Time Now, the methodology debate is not completed. It is not so much a raging battle as a simmering discontent, reflecting the fact that users still do not get what they expect, when they expect it.

In the future, life will of course be all blue skies and plain sailing - or will it?

The UK Government entered the arena in 1980 when they commissioned Learmonth and Burchett Management Systems (LBMS) to work with the Central Computer and Telecommunications Agency (CCTA) to develop what became the SSADM. In so doing, a number of disparate methods were brought together to form a structured set of tools and techniques that was consistently documented and presented.

A number of tools were created to support SSADM in the workplace and SSADM accredited tools, training materials and courses were set up. Naturally, all suitable IT project work for the UK Government has required the use of SSADM and the employment of certified SSADM practitioners.

During the 1980’s SSADM was upgraded with small changes, but in July 1990 SSADM Version 4 was released. This version made some fundamental changes to the Methodology structure, not the least of which was the concept of ‘tailoring the Method’.

It had become apparent to many that earlier versions of SSADM had engendered the ‘tick list’ approach to the development of information systems, with a focus on the existence of the deliverable rather than their quality. While this is still the case in some areas of use, Version 4 permits the identification of those elements of the Methodology that are relevant to the current development.

This ‘tuning’ process is intended to permit better matching of the required tasks to the size and complexity of the project.

What happens in practice may be that the ‘easy’ techniques and methods are retained at the expense of the ‘difficult’ ones!

In the last few years two significant factors have affected the status and position of SSADM in the UK.

• Firstly, CCTA have ceased to govern the development of SSADM, which leaves the methodology without a high level champion.
• Secondly, development cycles have been pressurised to reduce the time taken to get the ‘product to market’. This has focussed the attention of industry generally on Rapid Applications Development (RAD) methods.

The jury is still out in many company IT Managers and system development houses to decide which way to go now and in the immediate future.

In order to speed the development cycle of IT systems, faster methodologies that SSADM were proposed in the late 1980’s. These initiatives were given the generic name of Rapid Applications Development (RAD) methods. Unlike SSADM, with a tick list of deliverables and a rigid structure of tasks and stages to be traversed, RAD took the approach of producing a tangible result from the outset of the project.

Each element of the project was restricted into a ‘time box’ and development proceeded until the allocated time was used up. Small teams, typically of four to eight people, operating in an isolated environment and including developers, prototypers, analysts and users were formed to tackle each task and to produce a workable element in the time available.

RAD remained as a concept rather than a defined methodology for some time - until an industrial consortium was formed from a number of like-minded companies with a view to structuring the concepts into a methodology. The result is the Dynamic Systems Design Methodology (DSDM) and the DSDM Consortium.

The Consortium has published a manual for users of DSDM, which identifies techniques and deliverables that are considered appropriate to the environment of the methodology. Also covered are the criteria, work patterns and conditions that have been found to aid successful completion of DSDM projects to date.

There exist at the present time a number of threads of belief in the Information Systems Development (ISD) arena. All have been used to a greater or lesser extent by their advocates. However, having had two decades of structured ISD, there are still a number of problems.

• Projects fail to deliver what the customer wanted
• Projects take longer to deliver than expected or promised
• Projects cost more than the estimates made at the outset
• A significant fraction of projects fail to deliver anything at all
• Maintenance of the systems once in use is often difficult

The techniques used in IT project management have moved ahead steadily over the years. We now have a number of techniques and tools to assist managers in getting a grip on what is going on at the sharp end of the system development. Pressure has mounted to make every person in the project team accountable for time spent and for deliverables produced. Techniques have come along to assist in this area also.

At the end of the day there is still the fact that IT projects fail to deliver what is wanted – either in terms of functionality or in terms of [future] flexibility. This reflects the perceived failure of the specification process, whether this is in SSADM terms or in DSDM terms. All the developers in the world will fail to deliver a successful IT system if they do not know what it is they are trying to do!

The SSADM followers believe that they deliver a statement of what is required during the Requirements Analysis and Specification stages. The DSDM camp use iterative techniques to home in on what the user representative believes is the required system. There is no pre-existing statement of requirement at the detail of the SSADM deliverables.

What is it that the IT systems developers are not providing to define their systems and thus achieve the required goal?

Why is it that these problems do not manifest themselves so consistently in other engineering disciplines?

Answers to these questions may be a little while coming.

The basic specification task is to express what is in the head of a user, in a form that the user can identify to be identical to his original idea, in a form that can be presented to a developer and will enable the required system to be crafted without further information from the user.

The problem is one of shared understanding. The user’s vision of the required system has to be transferred to become the developer’s vision of the system and the two perceptions have to be identical. Any failure along the way, any chance that the shared perceptions are not identical, any failure of the transfer technique to include the totality of the user’s vision, could and probably will result in a defective system.

Software is unique in that it is not tangible in the way that a bridge or an aircraft is tangible. Small parts of such structures can be fabricated and fitted together in isolation. Though the relevance of the partial structure may not apply to the whole, the individual parts may be tested in isolation and their functionality perceived by the user. It two mechanical parts interfere, then this will be obvious in the interactions of the two affected parts. It is rare therefore for mechanical parts in a structure to be found defective at the time that the whole structure is assembled.

What software developers are seeking is a technique that would permit the presentation of the user’s vision to the developer using an unambiguous and consistent mechanism.