Investigation Of The Current Environment

Published Date: 02 Nov 2017

The SSADM method involves the application of a sequence of analysis, documentation and design tasks concerned with the following:

Stage 0 – Feasibility study

In order to determine whether or not a given project is feasible, there must be some form of investigation into the goals and implications of the project. For very small scale projects this may not be necessary at all as the scope of the project is easily understood. In larger projects, the feasibility may be done but in an informal sense, either because there is not time for a formal study or because the project is a "must-have" and will have to be done one way or the other.

Stage 1 – Investigation of the current environment

This is one of the most important stages of SSADM. The developers of SSADM understood that though the tasks and objectives of a new system may be radically different from the old system, the underlying data will probably change very little. By coming to a full understanding of the data requirements at an early stage, the remaining analysis and design stages can be built up on a firm foundation.

Stage 2 – Business system options

Having investigated the current system, the analyst must decide on the overall design of the new system. To do this, he or she, using the outputs of the previous stage, develops a set of business system options. These are different ways in which the new system could be produced varying from doing nothing to throwing out the old system entirely and building an entirely new one. The analyst may hold a brainstorming session so that as many and various ideas as possible are generated.

Stage 3 – Requirements specification

This is probably the most complex stage in SSADM. Using the requirements developed in stage 1 and working within the framework of the selected business option, the analyst must develop a full logical specification of what the new system must do. The specification must be free from error, ambiguity and inconsistency. By logical, we mean that the specification does not say how the system will be implemented but rather describes what the system will do.

Stage 4 – Technical system options

This stage is the first towards a physical implementation of the new system. Like the Business System Options, in this stage a large number of options for the implementation of the new system are generated. This is honed down to two or three to present to the user from which the final option is chosen or synthesized.

Stage 5 – Logical design

Though the previous level specifies details of the implementation, the outputs of this stage are implementation-independent and concentrate on the requirements for the human computer interface. The logical design specifies the main methods of interaction in terms of menu structures and command structures.

One area of activity is the definition of the user dialogues. These are the main interfaces with which the users will interact with the system. Other activities are concerned with analyzing both the effects of events in updating the system and the need to make inquiries about the data on the system. Both of these use the events, function descriptions and effect correspondence diagrams produced in stage 3 to determine precisely how to update and read data in a consistent and secure way.

Stage 6 – Physical design

This is the final stage where all the logical specifications of the system are converted to descriptions of the system in terms of real hardware and software. This is a very technical stage and a simple overview is presented here.

The logical data structure is converted into a physical architecture in terms of database structures. The exact structure of the functions and how they are implemented is specified. The physical data structure is optimized where necessary to meet size and performance requirements.

SSM

Stage 1 and 2

In stage 1 and 2 the analyst tries to develop the richest picture possible of the

problematic situation. The function of these 2 stages is "to display the situation so

that a range of possible and, hopefully, relevant choices [of relevant systems to be

described in the following stages] can be revealed" (SSM, 81 p. 166).

Checkland does not provide any examples or descriptions of rich pictures in

the book from 1981. Rich pictures are later (e.g. in SSM, 90) known as some

kind of informal drawings (together with describing text).

Stage 3

In stage 3 the analyst moves from the real world to systems thinking.

Following the development of rich pictures of the problem situation the analyst now chooses one or more short descriptions (typically 3-10 lines of text) of the real world to model in the succeeding stage. This is referred to as 'root definitions' of relevant systems (SSM, 81 pp. 166ff).

As a guideline for making the root definitions Checkland present the mnemonic 'CATWOE', which describes 6 elements that the root definition ought to include (SSM, 81 pp. 224ff):

- C: the Customers of the system referring to the interest groups who are the beneficiaries or victims within and/or without the system and who are affected by the systems activities.

- A: the Actors within the system who carry out or cause to be carried out the main activities of the system.

- T: the Transformation process by which the inputs to the system are transferred into defined outputs.

- W: the Weltanschauung or perspective from which the root definition is seen.

- O: the Owners of the system who have the ultimate power to cause the system to cease to exist.

- E: the Environmental constraints on the system that to a large extent has to

be taken as 'given' and difficult to influence, affect, and change.

The CATWOE guideline has a logical connection to the formal systems model in stage 4a that is used as a checklist to the model of the system.

Stage 4

For each root definition the analyst makes a conceptual model. The conceptual model "is simply the structured set of activities which logic requires in a notional system which is to be that defined in the root definition." (SSM, 81

p.170).

The description of the conceptual model takes the form of a drawing with each activity described in a few words depicted in a 'bubble' and with arrows connecting the bubbles showing logical relationships. An order of the activities may be indicated with numbers in the bubbles. As a technique it is suggested to base the activities in the conceptual model from the verbs which could be used to describe the system.

The description of the conceptual model takes the form of a drawing with each activity described in a few words depicted in a 'bubble' and with arrows connecting the bubbles showing logical relationships. An order of the activities may be indicated with numbers in the bubbles. As a technique it is suggested to base the activities in the conceptual model from the verbs which could be used to describe the system.

Stage 5

In stage 5 the analyst leaves the systems thinking and initiates the debate concerning desirable feasible changes by setting up discussions which compares

the models build in stage 4 with the problem situation expressed in stage

2.

Parts of the problem situation analysed in stage 2 are examined alongside the conceptual models: this should be done together with concerned participants in the problem situation with the object of generating a debate about possible changes which might be introduced in order to alleviate the problem condition. (SSM, 81 p. 177)

Checkland describes the comparison as an confrontation of 'whats' with 'hows'3. The system models are abstract descriptions and describes activities which logically have to be performed in the system (whats) while the real world activities always will be one way of doing things, "one particular how related to a what which is usually implicit rather than explicit." (SSM, 81 p. 228).

The purpose of the models is to question whether the activities from the models can be located in the real world, how well they are performed, if alternative ways of doing them could be suggested, etc.

Checkland presents 4 different ways of carrying out the confrontation (SSM, 81

pp. 178f):

1) Informal discussion.

2) Formal questioning.

3) Scenario writing based on 'operating' the models ("[...] reconstructing a sequence of events in the past [...] and comparing what had happened in producing it with what would have happened if the relevant conceptual models had actually been implemented").

4) Trying to model the real world in the same structure as the conceptual models (and hence compare).

Stage 6 and 7

Stage 6 and 7 concerns the implementation of the changes to improve the problem situation. In practice SSM is not as 'linear' as described here, as an ideal stage by stage process. Often iterations are done and the debate generated in stage 5 thus draws the attention back to the initial analysis and root definitions. Nevertheless the outcome of SSM should be the implementation4 of 'desirable' and 'feasible' changes.

[The defined changes] must be arguably systemically desirable as a result of the insight gained from selection of root definitions and conceptual model building, and they must also be culturally feasible given the characteristics of the situation, the people in it, their shared experiences and their prejudices. (SSM, 81 p. 181)

Checkland describes the possible changes within 3 categories: changes in (organizational) structures, in procedures (activities), and in 'attitudes' including e.g. changes in influence, expectations, roles, etc. (SSM, 81 pp. 180f).

Role and participation of the user

SSADM

One of the main features of SSADM is the intensive user involvement in the requirements analysis stage. The users are made to sign off each stage as they are completed assuring that requirements are met. The users are provided with clear, easily understandable documentation consisting of various diagrammatic representations of the system.

'Users will be involved from the earliest stage of the project. Throughout the structure of SSADM, users have opportunities to raise their requirements, walk through and review the deliverables and select the Business System Option. The common language between the users and developers means better communication and hence user requirements can be met more precisely.' [Much has been said already in this paper on user involvement. The only point to raise here is that users do not generally have a sufficient command of the language in SSADM, even after training for one or two days as in SAMS. to enhance communication with the developers. Moreover, when users were flooded with thick documents of Function Requirements (deliverables), sometimes quite technically written, they often did not know what they really had to agree with. It was only when prototypes in SAMS were available that the users could appreciate whether their requirements were met or not.

SSM

SSM concentrates on stakeholder perspectives and thus facilitates user involvement, something that was very much needed at the early stages of the project . In addition, the tools used as part of the SSM methodology (CATWOE and Rich Pictures) are easy to employ and understand: this would allow continued participation of user groups. It was thought that the overall benefit of using SSM would be the facility to move from "the problem unstructured" to "the problem structured" to "desirable changes", mirroring the stages of SSM. This approach to systems analysis is well-suited to KM issues: too often the technical platform takes precedence over social and cultural issues and the ‘solution’ is assumed without much thought given to user requirements or stakeholder perspectives (Biggam and Hogarth). SSM emphasizes the need to understand stakeholder perspectives, through participative means (e.g. Rich Pictures) to, in the end, ‘enhance the problem situation’. Users are an important group of stakeholders who have a critical role in the capture of user requirements. It ought to be emphasized that their value in the systems development process, particularly in the capture of user requirements, is not only recognized by Checkland but by researchers in other fields, e.g. computer ecurity (Adams and Sasses [14]; Rannenberg [15]).

Underlying philosophy of method

SSADM

SSM

The Philosophy of SSM

Checkland claims that systems thinking in general relies on two pairs of ideas: 'emergence and hierarchy' and 'communication and control'. Emergence and hierarchy refers to a general model of organized complexity describing the complexity as a hierarchy of levels, "each more complex than the one below, a level being characterized by emergent properties which do not exist at the lower level" (SSM, 81 p. 78). An example from biology is the levels cell organelles, cells, organs, organisms, and ecosystems. Maintenance or survival of the hierarchy entail "a set of processes in which there is communication of information for purposes of regulation or control" (SSM, 81, p. 83).

The hierarchically organized whole, having emergent properties, may in principle be able to survive in a changing environment if it has processes of communication and control which would enable it to adapt in response to shocks from the environment. (SSM, 90, p.

This makes the basic philosophy of SSM close to the functionalistic tradition in sociology. A traditional functionalistic position is that you in principle are able to study social structures by isolating or demarcating structures into systems, in which causal relations are dominating, forming some kind of boundary to the environments of the system. You can describe the function, that the system has in proportion to its environments as well as the function of the coherence within the system. The point of functionalism is that systems can be described as teleological or functional in a sense where they preserve themselves – they have a superior purpose. The superior principle of the system is its own maintenance, or survival, and events within the system can be described as having a function towards this principle.

Checkland agrees that there are similarities but opposes and strives against to be labelled "functionalist". There are similarities, certainly, as there are bound to be given the holistic framework of structural functionalism, but the aims of the social scientist and the systems-oriented problem solver are different, and this makes an application of the methodology different from a functional analysis. The social scientist wants the most accurate possible, testable account of what a social system is. The systems man using the methodology wants improvements in what is taken to be a problem situation. Given these aims, the functionalist sociologist wants the richest possible model he can get, including manifest and latent functions; the systems analyst wants his systems thinking to be as clear and coherent as possible, leading to clear-cut debate, and hence he makes his systems models of possibilities. (SSM, 81, p. 237)

Checkland's argument against SSM being classified as located in the structural functional tradition of sociology seems to be rather simple7:

1) The accusation rest on the early fact, that there was only one root definition and conceptual model. Now you can have several conflicting root definitions reflecting different weltanschauungen, and the debate is then intrinsically concerned with conflict and change (which the structural functional tradition of sociology didn't pay enough attention to). (SSM, 81,pp. 251f)

2) SSM models the real world as if it were a system but does not claim that it is a system. To view the world through system terms makes a difference from declaring that there is systems in the world. " [...] it is perfectly legitimate for an investigator to say [as an example] 'I will treat education provision as if it were a system', but that is very different from declaring that it is a system. This may seem a pedantic point, but it is an error which has dogged systems thinking and causes much confusion in the systems literature. Choosing to think about the world as if it was a system can be helpful. But this is a very different stance from arguing that the world is a system, a position which pretends to knowledge no human being can have." (SSM, 90, p. 22)

Techniques used in the information systems methodology

SSADM

The three most important techniques that are used in SSADM are:

Logical data modeling

The process of identifying, modeling and documenting the data requirements of the system being designed. The result is a data model containing entities (things about which a business needs to record information), attributes (facts about the entities) and relationships (associations between the entities).

Data Flow Modeling

The process of identifying, modeling and documenting how data moves around an information system. Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow).

Entity Event Modeling

A two-stranded process: Entity Behavior Modeling, identifying, modeling and documenting the events that affect each entity and the sequence (or life history) in which these events occur, and Event Modeling, designing for each event the process to coordinate entity life histories.

SSM

Table of Key Concepts and Techniques/Guidelines

Key Concepts Techniques

Guidelines

Hard/Soft Systems Thinking

Rich Picture

System

CATWOE

Real World - Systems Thinking

Conceptual modelling

Methodology

Activities from verbs in root definition

Structure and Process

Root Definition

4 ways of doing stage 5

Analysis/Suitability- which projects is the methodology more suitable

Ssadm

As one can see, SSADM is a comparatively old system designed for large scale projects. So, one should consider carefully if it is suitable for the system that needs to be developed in respect of the systems size and purpose.

3.1 Size of potential systems

3.1.1 SSADM for large systems, benefits of SSADM

Companies, mainly, who have information systems to manage, i.e. "several high volume business events"3, that can benefit the most from SSADM. It is assumed that in general large companies need to produce large information Systems and small or medium-sized companies produce smaller information systems. SSADM has been traditionally used for the development of medium or large systems. However, one variant of SSADM is 'Micro SSADM' which is for small systems.

SSADM specifies exactly the flows and tasks of a development project and produces a detailed documentation of the project.4The benefits that this prescribing methodology theoretically offers are mainly the following5:

3.1.1.1 Benefits of SSADM

Timelines:Theoretically, SSADM allows one to plan, manage and control a project well. These points are essential to deliver the product on time.Usability:Within SSADM special emphasis is put on the analysis of user needs. Simultaneously, the systems model is developed and a comprehensive demand analysis is carried out. Both are tried to see if they are well suited to each other.6Respond to changes in the business environment:As in SSADM documentation of the project’s progress is taken very seriously, issues like business objectives and business needs are considered while the project is being developed. This offers the possibility to tailor the planning of the project to the actual requirements of the business.

‘structuredness’ of the method