Hard system methodology



Chapter 2

DR: saleh Al-zahrani

Faculty of Computer and Information Systems

The systems approach

According to the general system theory, a system is a set of interrelated elements (Turban et al, 2001). However, Checkland, (1999) defines a system as a set of interacting systems, some of which do not work very well and can be engineered to work better. Yet Bocij et al. (1999) consider a system as a set of elements, such as people and things that are related to achieve goals. In this sense, Imam Mohammed Bin Saud Islamic University can be viewed as a system, and the Faculty of Computer and Information Science may be seen as a subsystem of the large system with its own function. Also, we could look to United Nation (UN)as systems and Saudi Arabia as sub systems of large system.

All human actions take place within a wider context or situation. The essential aspect of understanding situation from a system perspective is to consider the system as a whole. One of the most popular descriptions of this system or the holistic view is known as the (SSM), which is generally known as the Checkland approach. A systems approach tends to be an approach to a problem that takes the broad view, which takes all aspects into account, and which concentrates on interactions between different parts of the problem. An approach is the way of tackling a problem, and obviously, a particular approach may be relevant to more than one subject (Checkland, 1981).

A system approach use systems thinking to help in understanding the world and its behaviour. System thinking involves the use of systems concepts (ideas) and system methodologies and leads to construction of models of the system. Soft system modelling is a subjective process because no two people will look at any particular aspect of the world (except hard system) in exactly the same way. A system model is a set of organised assumptions about a particular aspect of the world and the way it works which have been identified as a system. Identifying system is not a purely objective process since the purposes and interests of the researcher will be involved. The system approach is not an attempt to understand every thing about a system, rather its tries to include all factors relevant to the topic or problem under consideration. This helps to highlight requirements of the system. System approach by itself is not a methodology, but involves the use of systems methodologies. Jenkins (1969) states that systems methodology comprises stages of system analysis, systems design, implementation and operation, formulation of the problem or objective is starting point. System approach is not a method, it is a way of looking at a problem. As result of this, finding a methodology, which uses the systems approach to apply to this study was essential Checkland's soft methodology which use system approach was chosen.

SSM has stimulated much interest and also has attracted considerable academic debate regarding its use in wider management problems and information systems issues. Indeed, SSM is not a technique (a method that requires certain procedures to be followed in order in obtain a predictable outcome), but is a set of guidelines for applying system ideas. Although these guidelines help an analyst to approach investigations methodically, they still allow considerable scope for individual interpretation. Since the original group of people who developed this approach was part of the Department of Systems Engineering, much of the activity was developed using characteristics of industry. Only in recent years, has experience outside industry contributed significantly to SSM development (Checkland, 1999). However, during the past two decades since its inception, SSM has had a considerable success as a general purpose problem - solving methodology, tackling the messy or unstructured problems which managers of all kinds and at all levels have to cope within their work. The emphasis of SSM is not on finding a solution to a specified problem, it is on understanding the situation in which a perceived problem is thought to lie.

Distinction between 'hard' and 'soft' problems

In selecting a methodology for problem-solving, a distinction between hard and soft problems is very important. A hard or structured problem is one which is exclusively concerned with a 'how' type of question. This kind of problem is the domain of the design engineer who seeks effective and economic answers on 'how' to provide. For example, 'How can we transfer an objective from point A to B at a minimum cost'? Another example of a hard system is an engineering application or a computer system development. Hard problems are problems characterised by the fact that they can be well defined. It is assumed that there is a definite solution, and a number of specific goals that must be accomplished can be defined. Hard approaches to systems analysis and design have been very successful at developing computer systems that, viewed from a technical perspective, are efficient and effective information providers. However, there have been cases when new information systems have not had user acceptance or seem to be misplaced as solutions to spurious problems (Curtis, 1998). This indicates that an alternative approach is required to capture the human element of a system design. In contrast, the soft or unstructured problem is one that embodies a mixture of both ‘what’ and ‘how’ questions. Checkland (1981) believes that the main difference between the ‘hard’ and ‘soft’ approaches is that where the former can start by asking what system has to be engineered to solve this problem, or what system will meet this need and can then take the problem or the need as ‘given’, the latter has to allow completely unexpected answers to emerge at later stages. He thinks the ‘soft’ methodology is seen to be the general case of which ‘hard’ methodologies are special cases. These by definition, soft problems are difficult to define. For example, they may have a large social and political component. A good example to illustrate a soft problem is how the transfer of highly sophisticated technology from Western Countries to Saudi Arabia can be achieved. In this case, there are different stakeholders with different perspectives, and interest for example, political, economic, social, cultural issues. These several issues contribute to an unclear picture.

It is often stated that the ‘hard’ system thinking is appropriate in well-defined technical problems and ‘soft’ system thinking is more appropriate in fuzzy, ill-defined situations involving human beings and cultural considerations (Checkland, 1999). Different approaches have different strengths and weaknesses, different areas of applicability and differing objectives. The aim of this chapter is not to explore the differences between hard and soft systems, but rather to give overview of their interactions. Table 1 below shows what can be considered as the main criteria that distinguish between hard and soft problems (Harry, 1994).

|Hard problem |Soft problem |

|Defined |Undefined |

|Clearly bounded |Fuzzy-edged |

|Separable problem |What is the problem? |

|Clear who ought to be involved |Not sure who ought to be involved |

|Information needs known |Unsure what information is needed |

|Know what the solution would look like |Not sure what the solution would look like |

Table 1. Show the main criteria that distinguish hard and soft problem

.

Figure .1. A map of system ideas (adapted from Checkland, 1990)

Figure. 1 shows a map of system ideas that summarises the views taken, of hard and soft systems and their applications thus far. From a methodological perspective the research question can be formulated as:

“What kind of system model would be best suited to improve the messy and ill-structured problem situation involved in this study?”

Systems Development Methodologies

The systems development life-cycle that is described in the previous section, is a model of the systems development process. To perform, manage, and control this process, a methodology is normally used. A systems development methodology may be defined as A methodology is based on some philosophical view, and is made up of a collection of phases, procedures, rules, techniques, tools, documentation and management aids. These aids help systems developers choose the appropriate techniques for each phase of a project and also help them plan, manage, and control information systems projects.

There are hundreds of methodologies available, many of which are very similar to each other. All are based on some philosophical view (e.g. scientific – structured, functional; humanistic – participation, prototyping; object-oriented). The systems development life-cycle is similar to a methodology, according to the above definitions:

• It is split into discrete phases.

• It makes extensive use of documentation.

• It is standardised and can be applied in many circumstances.

• It uses techniques and tools.

• There is an implied philosophy (i.e. that computerisation is a good way of dealing with, for example, clerical problems).

Types of Methodology

There are a variety of methodologies available and some examples of hard and soft methods along with their main phases are listed below.

1. Hard system methodology

The hard methods consider systems that have a clear purpose and well-defined goals, and are useful for designing solutions that achieve those gaols. These methods were developed in or around the 1960s when computers were big boxes that lived in large rooms. They view an information system as an input process connected to that computational process connected to an output process. They also view the process of problem solving as being a clear linear These methods, on the whole, only concentrate on the information and computation components and they do not focus on any part of values, which provide a basis for judging and deciding on actions. Following are good examples of hard systems

A. System analysis: The decision-making sequence is tackled in 4 steps:

1. Problem analysis: 2 Generating alternative solutions: 3 Evaluation of alternative: 4. Selection of the optimal alternative:

B. Information engineering(IE) (Jenkins)Jenkins was the starting point in the evolution of SSM. This approach passes through 4 basic stages: 1. System analysis: 2. System design: 3. Implementation :4. Operation:

C) Operations research:

This approach passes through 5 major steps: Thos steps are Formulation of the problem, Constructing a mathematical, Mode, Deriving a solution to the model, Testing the model and evaluation and Implement solution.

1. Soft systems methodology

The soft methods recognise that many human activity systems are so complex that they do not have a single goal and to impose a solution that embodies a single purpose can be extremely damaging to the system under investigation. A number of methods have been developed around the theory that specifically address human issues in design,

A: Soft system approach(SSM)

SSM has been developed since the 1970s by Professor Peter Checkland at Lancaster University. SSM has stimulated much interest and also has a roused considerable academic debate regarding its use in wider management problems and information systems issues. It was developed through action research, where systems ideas are tested out in client organisations. According to SSM, the problem-solver defines the problem situation and then uses this methodology to recommend action to improve it. SSM involves a seven stage process of analysis which uses the concept of a human activity system as a means of getting from 'finding out' about the situation, to 'taking action' to improve the situation.

B: Prototyping (Also its known as rapid application development or RAD). It’s a development methodology in which the system development phases are executed at the same time, rather than in sequence like the SDLC. Its relies on prototype, working or experimental models of a system.

C: The Structured System Analysis and Design Method (SSADM)

A methodology defines the methods of analysis and that should occur in a large-scale software development project. It is used extensively in the UK, particularly in government and public organisations. It attempts to address four questions that continually arise in the process of systems development. For example: What is the system to do? When should it be done? How should it be done? Where is the information to be recorded?

SSADM focuses on the feasibility, analysis and design aspect of the systems development lifecycle. It provides fewer guidelines on changeover and maintenance aspect of an IS project. It has six stages and each stage is broken down into a set of smaller steps, which define the input, output and tasks to be performed. The SSADM methodology, as it stands, is a soft methodology, in that it recognises that for any problem there are a number of different solutions that may be appropriate, and that the appropriateness of different solutions is largely determined by the particular viewpoints of those people who have an interest in the problem and its solution. The methodology demands that a system-oriented approach to design are taken, where design is viewed as the creation of a formal system, which must have certain features in common with all other systems. Obviously, a key feature in this methodology is the ability to represent and detect conflicts of interest among the holders of various viewpoints.

D: The Object Oriented Methods

Object Oriented Analysis (OOA) methodology is considered as one of the major object-oriented approaches for system analysis. It consists of five major activities as listed below: Finding class-and-objects Identifying structure Identify subject, Defining attributes, Defining services. Furthermore, the OOA methodology does not include design and implementation phases, although the authors address design in some detail in other sources. However, the transition from analysis to design in OOA is not a question of changing, or introducing new concepts. The transition is simply a matter of extending the detail of the object-oriented models and specifications and adding components concerning human interactions .Concerning the user participation approach, OOA prescribe a passive role for the users, with the traditional view of users as a source of information and reviewers of models developed. It only allows for the identification, representation and validation of the informational and computational component and it pays no attention to any of the axiologial framework components. OOM have been applied to both business process reengineering and analysis and design organisational information systems. The methods, in general, view the system as a set of interacting objects

E: The Scandinavian Style Method

The Information Systems Work and Analysis of Changes (ISAC) method is a problem-oriented method and seeks to identify the fundamental causes of the problem. The approach taken by the ISAC methodology is designed to analyse problem owners’ business problems and to solve aspects of them where appropriate. The ISAC approach to problem solving is to educate the problem owners by helping them to understand better the nature their problems. The ISAC method is a stepwise methodology that starts with trying to understand the problems that are facing the problem owners. The key difference between ISAC and other methods is that it directly places in the problem In general, they do not excel at the identification, representation and validation of any of the components from the axiological framework. The Scandinavian style of methods can be viewed as empowering the problem owners through education and the free exchange of information. This style of method has been slowly gaining in popularity and is now used in Europe and North America

F: The Socio-Technical Methods (Ethics)

Effective Technical and Human Implementation of Computer-Based System (ETHICS) is a socio-technical system development method developed by Enid Mumford of the Manchester Business School in the late 1970s and early 1980s. Moreover, it is based on the participative approach to information system development where user participation is very crucial throughout the development lifecycle. The ETHICS methodology adopts the socio-technical approach that for the system to be effective the technology must fit with social and organisational factors and the social and technical parts of the system must be given the same amount of concern. In particular, this means that an improved quality of working life, and enhanced job satisfaction for the users must be a major objective of the system design process.

In additional, ETHICS the development of computer based systems is seen as a change process and is, therefore, likely to involve conflicts of interest between all the participants or actors in that process. These conflicts are not simply between managers and worker but often between worker and worker and manager and manager. The successful implementation of a new system, therefore, requires a process of negotiation between the affected and interested parties. These parties are probably the most knowledgeable about the current workplace situation and the future requirements.

The job satisfaction needs and the efficiency needs (workflow problems) are collected and diagnosed by means of questionnaires given to all people who work in the organisation unit. Decisions are made by involving all workers in the unit who should all support the decisions. The decision about the change option should be verified with the appropriate management authorities. ETHIC can best be viewed as a development method for organisation units, with equal emphasis on the job satisfaction aspect, the workflow aspect and the information aspect.

Alternative approaches

Most large computer information systems are now developed in a sequence of steps called the Systems Development Life Cycle (or simply the systems life cycle). The key point is that it provides system builders with a structured approach to follow. It is used to:

organise the large number of activities which are necessary in building a system.

specify an orderly way to proceed through these activities.

make it easier to solve problems as they occur in the development process.

produce reports on project status, resource usage etc. as development progresses.

A number of different kinds of life cycle are used in practice, the most common systems development process takes an essentially linear approach dividing the necessary tasks into a number of stages. No stage in the sequence can commence before the previous stage has been completed.

There is little consensus on the terminology, the subdivision or the exact content of each stage of the life cycle, but the most common approach is Problem Definition,Feasibility Study Systems (and Requirements) Analysis, Systems Design, Implementation and ,Maintenance.

Thos stages well be outlined below:

1. Problem Definition

This stage establishes the nature of the problem to be solved, and estimates the scope of the problem. The problem definition basically states the reason/idea for the new system, at a high level. The new system might be needed to:

• Solve a problem (e.g. replace a manual system with a computer system in order to increase processing speed, provide better communication, reduce costs, or enhance competitive advantage).

• Take advantage of an opportunity (e.g. to expand or improve organisational performance, improve customer service).

• Respond to a directive (e.g. new legislation).

This is often considered to be the most important stage in development because it sets the direction of the rest of the project. The project limits are set in terms of what parts of the system can be changed by the project and what parts are outside its control. The resources to be made available to the project are also specified at this stage. These three important factors - goal, bounds, and resource guidelines are referred to as terms of reference and they form the main deliverable of this stage.

At this stage too, a project committee may be established, which is made up of system analysts, users and management.

The role of the systems analyst is to bridge the communications gap between users and programmers (who will later write the programs for the new system).

The systems analyst translates user needs into the technical specifications needed by the programmer. The role of management is to control the systems development process.

2. Feasibility Study

Starting with the problem defined in the previous stage, an investigation known as the Feasibility Study is carried out to determine quickly and with little expense:

If there is a feasible solution (i.e. can the problem be solved?).

If the problem is worth solving.

If not, then time, effort, and money have not been wasted on a full project. The task of the Feasibility Study is NOT to solve the problem, but to gain a sense of its scope and determine if a problem is worth solving. The Study is important because it ensures that the right system is to be developed. The rest of the development effort concentrates on making the system work right. So, if the wrong system is defined here, all further work is pointless.

In the Feasibility Study, three aspects of feasibility need to be considered:

(i) Technical Feasibility

It must be established whether or not the organisation has the technology and skills needed to carry out the project? If it does not, can these skills be bought, through hiring extra staff or through employing an outside consultancy firm?

(ii) Operational Feasibility

The system users are shown the proposed solution and asked if it seems to satisfy their requirements.

(iii) Economic Feasibility

Management need to determine if the project can be carried out within the resource limits allocated to it. They must also decide if the benefits of the new system will outweigh the costs it will inevitably incur.

A Feasibility Study should cover the following:

• Nature of the existing system.

• Shortcomings and problem areas (bottlenecks etc.).

• Scope for improvements.

• Alternatives available. Once the problem is understood, alternative solutions are developed.

• The preferred solution.

• Preliminary estimates of cost and benefits of the preferred solution. The Feasibility Study must show that the solution will help the organisation attain its objectives, that it conforms to the organisation’s strategic plan, and that it is technically, economically, and operationally feasible.

• The recommended approach i.e. a plan plus a rough time scale.

These issues can be resolved using methods such as Fact-Finding techniques and Cost-Benefit Analysis. Through fact-finding techniques (e.g. interviews with users and managers), the analyst can find out what the existing system is like, what the problems are, and what is needed by the new system (i.e. high-level functional requirements – what the system will do; high-level non-functional requirements – resource restrictions, security isuses, number of users, equipment needed/available, retraining of employees, availability of people to develop system, etc.).

Using Cost-Benefit Analysis, the Feasibility Study can show how the preferred solution will help the organisation attain its objectives, how it conforms to the organisation’s strategic plan, and how it is technically, economically, and operationally feasible. When preparing the Cost-Benefit Analysis, the analyst will ask questions such as:

• What will be the difference in cost and profit between the old and the new system? Is a new system justified on the basis of cost alone?

• Will the cost of maintenance of the new system be greater than the old one? What are the true savings in maintenance costs in the short and long term?

• What indirect benefits will resuts from the new system? Will changing the design of one system improve the operation of another?

• Will the new system be more reliable and dependable? Can we expect less down-time from equipment breakdowns? How can we put a value on these changes?

• What improvements in personnel attributes will result? Will the new system lead to greater motivation, less absenteeism, and greater productivity?

The Feasibility Study ends with a formal presentation to users and management: a GO / NO GO decision must be made.

3. Systems (and Requirements) Analysis

The aim of analysis is to develop a model of the way the current system works, on the assumption that the existing system provides a good guide as to what is required of a new system (as opposed to how the new system will achieve the requirements). Analysis summarises and models key elements in the system to faciliate understanding of the system and to help with the System Design stage.

Analysis therefore, is about what is to be done in order to satisfy the requirements of a new system. The how comes later (in the Systems Design stage). During the analysis stage, the analyst uses the facts gathered during the Feasibility Study about the existing system and about the requirements for the new system, to model the system. Generally, the analyst will need to gather more detailed facts about the existing system and about the requirements for the new system than is available from the Feasibility Study. To do this, s/he can use the same fact-finding techniques as used Feasibility Study.

This stage consists of a detailed investigation (using the usual fact-finding techniques) of the workings of the system currently in use, whether manual or computerised. The analyst must become familiar with:

what the system is supposed to do.

whether or not, under current conditions, it actually does it.

what constraints the system operates under.

what controls are imposed on it.

what type of data is processed.

exception circumstances.

problems with present working conditions.

This stage should result in detailed models of what the existing system does (if there is one) and models of what the new system will do. This stage should also produce a list of requirements for the new system (i.e. a requirements specification).

To develop the models of the system, this stage uses techniques and aids such as Data Flow Diagrams, Entity Relationship Models, Entity Life Histories, Data Dictionaries, Structured English, Decision Tables, and Decision Tress.

4. Systems Design

Using the facts and models from the Feasibility Study and Analysis stages, a design for the new system is developed. At this stage, the models from analysis are amended to incorporate any new requirements (for the new system) and any inefficiencies or mention of physical aspects are removed. Both of these are legacies of having used an existing physical system as the basis for analysis. The result is that the design for the new system should eliminate the problems of the old system. Systems Design shows how the new system will be implemented (i.e. a design for the new system is produced).

In their design of the new system, analysts have to:

• Select the hardware will be needed to implement the new system.

• Write specifications of new programs or amendments to existing ones in terms of what they must do and what languages they should be written in. Programs can be specified using Structure Charts.

• Specify a database structure, what data should it contain, and what queries will be made of it.

• Provide details of input data, outputs, processes, security and backup provisions, implementation and testing plans, file structures, etc.

• Design user interfaces.

• Develop user procedures which will instruct the users how to make the most of their new system.

• Develop cost estimates and an implementation schedule.

5. Implementation

In this stage, individual system components are built, i.e. programs are written, the database is created etc. System components are tested individually and then linked and tested again to ensure that they hang together properly without causing the system to crash. The user interface, i.e. the screens which link the user with the system are developed. Users are introduced to the system and encouraged to voice their opinions on it. The hardware specified in Systems Design is acquired and installed. Targeted training and education are provided for staff. Historical data is loaded into the system.

6. Maintenance (and Review)

This stage is ongoing throughout the useful life of the system and involves correcting faults which are not detected during testing and making enhancements to the system in order to satisfy new requirements. This is the most expensive part of the life cycle and, in order to minimise costs, every effort should be made during earlier stages to get the requirements right first time and to trap as many errors during testing as is possible.

-----------------------

REAL-WORLD APPLICATIONS OF SYSTEMS IDEAS

‘SOFT’ SYSTEMS ANALYSIS:

Human activity-based systems analysis for ‘soft’, ‘messy’, ‘complex’ and ‘ill-structured’ problems

‘HARD’ SYSTEMS ANALYSIS:

Machine-based or hardware-dominant systems approach for ‘hard’, ‘well-structured’ problems

APPLICATIONS OF SYSTEMS IDEAS TO ACADEMIC PROBLEMS:

e.g. Planning Education Social work

Medicine Geography Ecology, etc.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download