Soft Systems Methodology

History

Soft Systems Methodology (SSM for short) was developed by Peter Checkland and colleagues at the University of Lancaster. It is based upon systems theory, which provides an antidote to conventional, 'reductionist' scientific enquiry - with its tendency to 'reduce' phenomena into smaller and smaller components in order to study and understand them. Systems theory attempts to study the whole picture; the relation of component parts to each other, and to the wider picture - it is 'holistic.' Biology and environmental science use its principles widely, as do other disciplines including systems analysis. SSM is not, contrary to popular supposition, an information systems design methodology - it is rather a general problem solving tool. Brian Wilson, a colleague of Checkland's at Lancaster, has adapted the methodology for business information analysis, and various attempts (Avison's 'Multiview,' for instance) have been made to incorporate it into systems design work.

What do we mean by 'system?'

We use the word 'system' quite a lot in everyday language ('computer system,' 'the educational system', 'systematic;'); we even talk about 'the system' - a  vague, sinister officialdom. Three uses of the word must be distinguished:

1.         a way of doing things, an organisation of resources and procedures.

2.         a computer, or information system

3.         (a specialised SSM use) - a conceptual organisation of resources and procedures defined according to systems theory - more about this later.

It will be a useful discipline to check that you understand which of these three senses of the word is being used every time the word occurs in this handout.

Why 'soft?'

System thinking has come to be characterised as either 'hard' or 'soft.' There are fundamental differences between a man-made ('designed physical' system), such as a nuclear reactor, and an organisational system - a 'human activity' system. Where mechanical components are involved, their behaviour can usually be predicted with reasonable accuracy - these are 'hard' systems; where human beings are involved this is not necessarily the case. Because human behaviour is unpredictable, organisational and management problems are seldom clear cut and well-defined; they are normally complex, with many indeterminable variables - 'soft' systems. At first glance, information systems would seem to be 'hard' - designed physical - systems, but experience shows that they seldom add value unless they are closely married to their organisational context, and the people who use them. There are therefore many softer issues which are important in information system planning, design, and implementation. 'Soft' has another, more specialist meaning - depending on the type of person you are, and your training and experience, you may understand 'systems' as tangible things which are really present in the world. You may, however, understand systems ideas as a series of intellectual constructs that we use to help us deal with the enormous complexity of the real world. This is an interesting, but un-resolvable argument; SSM tends strongly to the latter position.

Overview

SSM helps formulate and structure thinking about problems in complex, human situations. Its core is the construction of conceptual models (based on the understanding of human activity systems outlined above) and the comparison of those models with the real world. This process can greatly clarify those multi-faceted problems with many conflicting potential solutions, or no obvious way forward. Conceptual models are not representations of the real world, like a data-flow diagram - they are constructs which embody potential real world systems, but, more importantly, follow rigorously the systems principles already discussed, and their own well-defined internal logic. SSM is not, therefore, about analysing systems found in the world, but about applying systems principles to structure thinking about things that happen in the world - a difficult, but crucial distinction to grasp. It is most usefully carried out by people involved in the problem situation, with expert help available to guide and facilitate.

Rich pictures

Purpose

Rich pictures were particularly developed as part of Peter  Checkland’s Soft Systems Methodology for gathering information about a complex situation (Checkland, 1981; Checkland and Scholes, 1990). The idea of using drawings or pictures to think about issues is common to several problem solving or creative thinking methods (including therapy) because our intuitive consciousness communicates more easily in impressions and symbols than in words. Drawings can both evoke and record insight into a situation, and different visualization techniques such as visual brainstorming, imagery manipulation and creative dreaming have been developed emphasizing one of these two purposes over the other (Garfield, 1976; McKim, 1980; Shone, 1984; Parker, 1990).

Rich pictures are drawn at the pre-analysis stage, before you know clearly which parts of the situation should best be regarded as process and which as structure.

Part of a rich picture of a telephone helpline situation

Rich pictures (situation summaries) are used to depict complicated situations. They are an attempt to encapsulate the real situation through a no- holds-barred, cartoon representation of all the ideas covered already layout, connections, relationships, influences, cause-and-effect, and so on. As well as these objective notions, rich pictures should depict subjective elements such as character and characteristics, points of view and prejudices, spirit and human nature. If you are working with a client you should try to draw these from the actors themselves, at least initially, rather than focusing on your own interpretation of the situation.

Elements:

• pictorial symbols;
• keywords;
• cartoons;
• sketches;
• symbols;
• title.

Conventions

1. To help interpret a situation, choose symbols, scenes or images that represent the situation. Use as many colours as necessary and draw the symbols on a large piece of paper. Try not to get too carried away with the fun and challenge to your ingenuity in finding pictorial symbols.
2. Put in whatever connections you see between your pictorial symbols: avoid producing merely an unconnected set. Places where connections are lacking may later prove significant.
3. Avoid too much writing, either as commentary or as ‘word bubbles’ coming from people’s mouths (but a brief summary can help explain the diagram to other people).
4. Don’t include systems boundaries or specific references to systems in any way (see below).

Guidelines

1. A rich picture is an attempt to assemble everything that might be relevant to a complex situation. You should somehow represent every observation that occurs to you or that you gleaned from your initial survey.
2. Fall back on words only where ideas fail you for a sketch that encapsulates your meaning.
3. You should not seek to impose any style or structure on your picture. Place the elements on your sheet wherever your instinct prompts. At a later stage you may find that the placement itself has a message for you.
4. If you ‘don’t know where to begin’, then the following sequence may help to get you started:
   
   
   1. first look for the elements of structure in the situation (these are the parts of the situation that change relatively slowly over time and are relatively stable, the people, the set-ups, the command hierarchy, perhaps);
   2. next look for elements of process within the situation (these are the things that are in a state of change: the activities that are going on);
   3. then look for the ways in which the structure and the processes interact. Doing this will give you an idea of the climate of the situation. That is, the ways in which the structure and the processes relate to each other.
5. Avoid thinking in systems terms. That is, using ideas like: ‘Well, the situation is made up of a marketing system and a production system and a quality control system’. There are two reasons for this. The first is that the word ‘system’ implies organized interconnections and it may be precisely the absence of such organized interconnectedness that lies at the heart of the matter: therefore, by assuming its existence (by the use of the word system) you may be missing the point. Note, however, that this does not mean that there won’t be some sort of link or connection between your graphics, as mentioned above. The second reason is that doing so will channel you down a particular line of thought, namely the search for ways of making these systems more efficient.
6. Make sure that your picture includes not only the factual data about the situation, but also the subjective information.
7. Look at the social roles that are regarded within the situation as meaningful by those involved, and look at the kinds of behaviour expected from people in those roles. If you see any conflicts, indicate them.
8. Finally, include yourself in the picture. Make sure that your roles and relationships in the situation are clear. Remember that you are not an objective observer, but someone with a set of values, beliefs and norms that colour your perceptions.

The main principle of a rich picture is to assist us the analyst to gain an admiration of the problem situation. As it is understood in Soft Systems Methodology (SSM), rich pictures are used as a means to signify the situation of anxiety and include elements which influence the problem for organisation, but which would not perhaps be picked up using more formal methods.

Soft systems methodology emphasizes the value of rich pictures. Rich Pictures is an innovative way of turning complex systems, thoughts and everyday business issues into a neat format that everyone can understand easily. These seek to explore and summarise issues much more pictorially and graphically than the methods like documenting, reporting. They can be extremely intuitive and can also compress a lot of information into a single picture.

Rich pictures can be very useful in forming a backdrop to subsequent analysis, acting as an aide memoire to allow the group continually to refer back and check they are addressing all the relevant issues. The rich picture of our Problem Scenario shows the many interacting systems and issues that relate to the organisation which has developed over particular location. Within a solitary image all the mean points and concerns have been detained and may be corresponded to those apprehensive in choosing what action to take.

The above rich picture includes the struc­ture of  Environment. This Struc­ture refers to those parts of the sit­u­a­tion which are slow to change and rel­a­tively sta­ble. They may include things like organ­i­sa­tional struc­ture, phys­i­cal lay­out and all the peo­ple who are affected by the sit­u­a­tion. And also it includes only enough struc­ture to allow you to record the process and concerns. At the same time it embraces the concerns or issues which capture a particular actor’s motivations for participating in the situation. The different motivations give rise to the various perspectives each actor has.

It also includes the process of Organisation which refers to the transformation that go on within the structure. These transformations might be part of a flow of goods which are being utilised in that firm, existing documents which are already there in that problem organisation or data of that particular organisation. But the rich picture will not capture all aspects of process. The above Rich picture represents structure, processes and issues of the environment, which could be relevant to the problem definition, and try giving an impression of the charity organisational climate. Although they can often contain imprecise or confusing illustration between their processes and correspond the problem situation clearly or not very clearly.

Many analysts are scared of using rich pictures, because they feel their artistic skills are not adequate. However, with modern drawing tools in Office tools and inventive use of clip art, this is now much less of a problem. The act of drawing a rich picture is functional in itself because:  lack of space on the paper forces decisions on what is really important (and what are side issues or points of detail for further layers of rich pictures); It helps people to visualize and discuss their own role in the organisation; It can be used to define the aspects of the organisation which are intended to be covered, by the information system; It can be used to show up the worries of individuals, potential conflicts, and political issues.

Once the rich picture has been drawn, it is useful in identifying two main aspects of the human activity system. The first is to identify the primary tasks. Searching for primary tasks is a way of posing and answering the question: 'What is really central to the problem situation?' For example, it could be argued that the organisation aims to give an excellent service to its customers (the public) (which might be implied by the diagram) or increase standards in its profession (which is not implied by the diagram). Everything else is carried out to achieve that end. Primary tasks are central to the creation of this information system, because the information system is normally set up to achieve or support that primary task of the organisation environment. 

The second way that the rich picture is of particular value is in identifying issues of that problem area. These are topics or matters which are of concern. They may be the subject of dispute. They represent the (often unstated) question marks hanging over the 4/5 situation. This process of identifying the issues will lead to some debate on potential changes. It might be possible for these issues to be resolved at this stage, but it is essential that they are understood. Issues are important features, as the behaviour resulting from them could cause the formal information system to fail. Unless at least some of them have been resolved, the information system will have little chance of success. In some situations, the issues can be more important than the tasks.

The rich picture can help the owners of the problem sort out the fundamentals of situation, both to clarify their own thinking and decision making and also to explain these fundamentals to all the concerned parties. The rich picture becomes an abstract of all that significant in the circumstance. An analysis of the rich picture will help in the process of from 'thinking about the problem situation' to 'thinking about what can be done about"' problem situation'.

The above description of Richpicture is taken from my own Assignment task on my Bsc Final Year ISE Coursework.

Traditional SDLC

What is meant by Traditional System Development Life Cycle?

Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. There are several Systems Development Life Cycle Models in existence. The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seems to vary between 4 and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and divided in several steps.

Phase1.Initiation/Planning

To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team. The MIS is also a complement of those phases. This phase is also called the analysis phase.

As software is always of a large system (or business), work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when the software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.

Phase2.Requirements Gatherings and Analysis

The goal of systems analysis is to determine where the problem is in attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation. Analysts project goals, breaking down functions that need to be created, and attempt to engage users so that definite requirements can be defined.This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system.

It also includes the personnel assignments, costs, project schedule, target dates etc.... The requirement gathering process is intensified and focused specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved.

Phase3.Design

In systems design functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems.In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc... Are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Phase4.Build or Coding

Modular and subsystem programming code will be accomplished during this stage. This stage is intermingled with the next in that individual modules will need testing before integration to the main project. Planning in software life cycle involves setting goals, defining targets, establishing schedules, and estimating budgets for an entire software project.

The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... Are used to generate the code. Different high level programming languages like C, C++, Pascal, and Java are used for coding. With respect to the type of application, the right programming language is chosen.

Phase5.Testing

The code is tested at various levels in software testing. Unit, system and user acceptance testing are often performed. This is a grey area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs. Iteration is not generally part of the waterfall model, but usually some occurs at this stage. These are the types of testing:

· Data set testing

· Unit testing

· System testing

· Integration testing

· Black box testing

· White box testing

· Module testing

· Regression testing

· Automation testing

· User acceptance testing

Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations.

Phase6.Operations and Maintenance

The deployment of the system includes changes and enhancements before the decommissioning or sunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel change positions in the organization, new changes will be implemented, which will require system updates.The software will definitely undergo change once it is delivered to the customer. There can be many reasons for this change to occur. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.

Features of the Traditional SDLC.

· Consulting in all phases of SDLC: Requirements Definition, Analysis, Design, Construction, Testing, Training, and Implementation

· Provide advice on certain methods and approaches to systems development (e.g. Waterfall, Iterative, Rapid Application Development, Structured, Object-Oriented, etc.)

· Teach how and when to integrate techniques to minimize risk

· Make best use of modeling and diagramming techniques

· Integration of project management techniques

· Increase likelihood that end-product matches requirements and meets goals

· Help establish SDLC best practices

· Help select software tools that fit in with practices and methods

What Are criticisms with the Traditional SDLC?

There are many criticisms put forward against SDLC, and those criticisms are being given in point forms.

· The SDLC Waterfall: Due to the waterfall nature of the SDLC, on some projects, the team has to go back and forth between requirements and design so many times that the project seems to be out of control.

· Increased development time in the whole system.

· Increased development cost in the whole system.

· Systems must be defined up front.

· Rigidity (Inflexibility).

· Hard to estimate costs, project overruns.

· User input is sometimes limited.

· Requirements Documentation Difficulty: Another problem, especially on complicated systems, is the difficulty of documentation requirements in a usable way.

· Scheduling and budgeting difficulties: For large-scale system, schedule and budgeting estimates are so approximate as to become nearly laughable.

· In the SDLC Model, while we are in the process of the system, we cannot go to the previous stage or phase.

· The main drawback that we can find in this type of SDLC, Lacking of time. In the sense, until the previous stage completes, the balance entire team has to wait for the completion of current stage. This will cause a waste in human resource.

· This type of SDLC is not flexible as in completion of a stage if we need we cannot come to a completed stage.

· Real projects rarely follow the sequential flow that the model proposes.

· At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model doesn’t accommodate this natural uncertainty very well.

· Assumptions made in the early phases no longer hold.

· Some of the early work is incomplete

· Something was overlooked or not completely understood.

· The customer satisfaction will get less as the competitive organizations outputs will be in high standards and when this organization cannot compete. Due to this the customers will lose the trust which they had on this organization and this will damage the organization’s reputation.

· If an organization has to invest money to create a System in the SDLC by borrowing or by using the money they had to invest in another firm they will be loosing that income or they will be paying interest without getting the output from this system due to the time frame.

· To overcome these problems we can use alternative methods on the development of a particular system.