Enhancing the soft systems methodology Polytechnic of Hong … · 2014-05-19 · their implementation carries a relatively high risk. At present, however, SSM makes no provision for

Enhancing the soft systems methodology

with risk management techniques

D.W. Bustard," D. Greer" & G. Tate&

"Department of Computing Science, University of

Ulster, Cromore Road, Coleraine, BT52 ISA, UK

^Department of Information Systems, City

Polytechnic of Hong Kong, 83 Tat Chee Avenue,

Kowloon, Hong Kong

ABSTRACT

The Soft Systems Methodology (SSM) is a general problem solving techniquethat is being used to an increasing extent in the determination of requirements forcomputing systems. SSM takes a goal driven approach to systems analysis thatinitially ignores the structure and constraints of the current situation. In practice,this means that system changes identified through SSM tend to be'revolutionary' rather than 'evolutionary' and so carry a relatively high risk. Atpresent, SSM makes no explicit provision for investigating such risk. Thepurpose of this paper is to consider how this deficiency might be addressed. Abrief overview of SSM is given, together with a summary of risk managementconcepts. Possible approaches to the use of risk management with SSM arepresented and the implications examined. The discussion is illustrated with avideo library case study.

INTRODUCTION

A hard systems engineering problem is one that is well defined and has anagreed solution [1], the role of the systems analyst in this case being todetermine how best to implement the solution. Some computing problems fallinto the 'hard' category but more commonly they are soft, in the sense that thereis a lack of agreement about the nature of the problem, its cause, or its solution.Thus initial effort is needed to investigate the problem adequately before asolution can be determined. Soft Systems Methodology (SSM) [1-4] provides astrategy for tackling soft problems. It was developed as an engineering approachto management problems [3] but it can be used as a general problem solvingtechnique for any system where a process is involved. Examples of its range ofapplication are given in [5].

Interest in the use of SSM for computing applications has grown significantlyin recent years. The Civil Service in Northern Ireland, for example, now requireeach request for new computing facilities to be accompanied by a business case,and SSM is the preferred analysis technique for this initial broad investigation of

Transactions on Information and Communications Technologies vol 9, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

146 Software Quality Management

requirements. One important benefit of using SSM for computing applications isthat it leads to a good understanding of the context for system development,which in turn improves the likelihood of satisfying the client's needs.

SSM supports a goal driven approach to computing systems analysis thatfocuses initially on the intended purpose or purposes of the system in which thecomputing facilities are to be used. Each such purpose is developed into abehavioural model of the activities necessary to achieve that purpose. Theseconceptual models are then used as the basis for evaluating the current system tohelp identify desirable changes. Because this approach ignores the structure ofthe current system initially, the changes proposed can be radical. Consequentlytheir implementation carries a relatively high risk. At present, however, SSMmakes no provision for investigating and controlling such risk. The purpose ofthis paper is to consider how this gap might be filled. The first section gives abrief overview of SSM and this is followed, in the second section, by asummary of the elements of risk management. The third section then'considerspossible approaches to introducing risk management into SSM and examines theimplications of such a change. The discussion overall is illustrated with a videolibrary case study.

SOFT SYSTEMS METHODOLOGY

Classically [1], SSM is summarised by the seven phases of activity shown(simplified) in Figure 1.

7. Action toimprove theproblemsituation

3. Root definitions ofrelevant systems

Figure 1: Soft Systems Methodology Outline

Activities above the central line are concerned with the description andanalysis of the real world while those below the line involve system thinking,dealing with the building and analysis of exploratory abstract models of theproblem situation. The abstract models are used for comparison with the realworld to identify feasible and desirable changes. Thus SSM encouragesdevelopment against desired objectives rather than a reorganisation of existingsystems. The numbering of the phases suggests that they should be pursued in


Building Quality into Software 147

sequence but, in practice, the order is not strict and the analysis is more iterativethan linear.

A problem situation can be described broadly as "a situation in which there isperceived to be a mismatch between what is and what might, or could, or shouldbe" [1]. For example, the owner of a video library (Perfect Vision, say) mightapproach an analyst with a request for assistance to install or enhance a computersystem to help improve the management of the library. Stages 1 and 2 of SSMdeal with problem expression in which an understanding of such a problemsituation is developed. These stages produce a mixture of textual description andhigh level models expressed in the form of rich pictures [6], mind maps [7] andany other non-prescriptive notation considered useful by the analyst.

Stage 3 is concerned with the definition of one or more distinct purposes ofthe system being analysed, each expressed as a root definition. For example,with the video library one definition might be:

A Perfect Vision owned system to provide home entertainment tothe 'paying public', by supplying entertainment media, whilerecognising the need for the company to make a profit.

A root definition is based on a 'world view' or Weltanshauung of the system[1]. This expresses a particular ideology or philosophy, in this case that "homeentertainment can be provided to the 'paying public' by supplying entertainmentmedia". Such a definition should also contain other standard elements such asthe identification of the system owner and the beneficiaries (or victims) of thesystem. Notice that this definition has been intentionally defined in a broad,abstract way to allow other aspects of the video library business to be explored.For example, Perfect Vision might also sell video tapes or provide differentforms of entertainment media.

Stage 4 deals with the development and testing of conceptual models. Initialtop level models are built by assembling the minimum list of verbs covering theactivities that are necessary in a system defined by each root definition. Forexample, a (simplified) top level model for the video library might take the formshown in Figure 2.

Determine entertainmentmedia that Perfect Vision

should offer

Determinecharging policyto ensure profit

tradingSupply medifor use bycustomers

Monitor theeffectivness, efficiencyand economy of the

systemDecide how to supplymedia to the paying

public

Figure 2: Sample Conceptual Model



This diagram identifies the main high level activities required for the systemdefined in the root definition to operate and also shows the logical dependenciesbetween them. The diagram is largely informal at this stage. For example, thejagged arrow means that control action is taken to influence 'most' of the otheractivities but these are not identified explicitly. Also the relationship betweenactivities is not specified and indeed the textual descriptions of the activitiesthemselves are really only indicative of what is involved. Detail is added asanalysis proceeds. Any activity can be expanded to produce a lower level model,and this process is repeated down to whatever level of detail the analystconsiders appropriate. As an example, Figure 3 shows a breakdown of thecentral activity in Figure 2: "Supply media for use by customers".

Make customersaware of available

items that may satisfytheir needs

Select itemsto satisfycustomers'needs

Figure 3: Conceptual Model for Activity "Provide Media for use by Customers"

The activities identified in Figure 3 include the selection of suitable items, thereservation of items and the lending of items to customers (External links havebeen omitted for clarity). Similarly, Figure 4 shows a further descent to examinethe "Lend items to customers" activity.

Figure 4: Conceptual Model for Activity "Lend items to customers"

In phase 5 (Figure 1) a comparison is made between the conceptual modelsand the real world to test the models for adequacy and at the same time toidentify deficiencies in the real world system. This phase is performed by theanalyst in collaboration with the client and others involved in the problemsituation. The objectives are to increase the level of understanding of the analystand to stimulate debate on possible changes to alleviate the problem situation.There are several ways in which a conceptual model can be evaluated. Onesystematic approach is to examine each activity in turn to determine its



relationship with the real world and so identify where change should occur. Thiscomparison can be performed using a table of the form shown in Figure 5,which refers to the top level model for the video library example. The firstcolumn identifies the activities concerned, the second indicates whether or notthat activity is currently performed; if so, then the third column describes themechanism involved. The fourth column defines how the performance of theactivity can be measured; the fifth column summarises any proposed changesand the final sixth column can be used to make clarifying comments.

(1)Activity

Determineentertainmentmedia to offer

Determinechargingpolicy toensure profittrading

etc....

(2)Exists

No

Yes

(3)PresentMechanism

Ownersintuition only

(4)Measure ofPerformanceSales figures

MonthlyProfit

(5)ProposedChangeInvestigateother media

Establish costof sales moreprecisely andcompetitionrates todetermineoptimumcharge.

(6)Comments

May be amarket forcomputergames & CDsPrice pervideo is £2for recent£1.50 forolder ones- based oncompetitionrates only

Figure 5: Sample Activity Table

After this examination, the root definition and conceptual model are revisedas necessary and the evaluation repeated until the model is agreed by allconcerned. The conceptual models are then integrated to give a singlehierarchical model, a consensus primary task model. Such integration includesthe resolution of the different viewpoints in the models.

Adoption and verification of system changes are performed in phases 6 and7, taking further revision cycles around the development loop as required. Themodifications involved are often too major to make all at once so incrementaldevelopment is recommended.

RISK MANAGEMENT

Risk can be defined broadly as "the possibility of loss or injury". Riskmanagement is the process of determining risks and responding to them. Boehm[8] divides risk management into two main activities: risk assessment and riskcontrol. Risk assessment involves (i) identifying the risks concerned; (ii)analysing the threat of those risks in terms of their probability of occurrence andthe magnitude of the resulting loss; and (iii) prioritising the risks accordingly.Risk control covers (i) risk management planning, to develop plans foraddressing each major risk; (ii) risk resolution, to implement the plan that willeither eliminate the threats or keeping them at an acceptable level; and (iii) riskmonitoring, to assess the effectiveness of risk resolution and take correctiveaction as necessary.

For example, with the video library one obvious risk is the possibility oflosing the rental information that records details of the tapes on loan and whohas borrowed them. This risk might be assessed as one of low probability but asthe resulting loss is substantial, the overall threat is significant, making it a high



priority consideration requiring some form of control. The risk cannot beeliminated in this case but the threat can be reduced by taking copies of the rentalinformation periodically. Having implemented such a procedure its effectivenesswould be assessed from time to time. This could be achieved by, for example,simulating the loss of the rental information and calculating the financialimplications for the business; further protective steps might then be taken, ifrequired.

Risks can be identified by several means including brainstorming, developingdisaster scenarios, following checklists of generic risks, or by a combination ofsuch techniques. Checklists are a list of potential risks built up from previousexperience. Typical examples include the risk that requirements will change, therisk that unrealistic schedules will be set and the risk that a product will be usedincorrectly. Checklists are usually structured into risk categories because of thelarge number of items involved. One obvious major division is between risksassociated with the operation of the final system and those associated with theimplementation of the changes necessary to develop that system. A checklistprovides a framework for risk identification through discussions between theanalyst and the client group, by working systematically through the list.

User oriented risk issues can, in principle, be compiled as a questionnaire forcompletion by the client group but, in practice, analyst guidance is usuallydesirable. This is partly because of the need to discuss the meaning of each riskand partly because a full checklist is often too large to be completed in itsentirety; some selection is necessary depending on the type of problem beingconsidered. A high level checklist can also be used to provide categories forseparate brainstorming sessions; typical topics might include politics, marketforces, and personnel.

Risk management techniques can be applied at all levels of systemsdevelopment down to and including the production of robust code. For thehigher levels of system description the risks identified will be mostly generic,but become progressively more specific as lower levels of the system areexamined.

Risk can be assessed symbolically, using gross measures such as 'high','medium', and 'low', or expressed in numerical terms as a probability value inthe range one to zero. In the latter case, the threat imposed by the risk, oftenreferred to as the risk exposure [8], can be calculated using the equation:

RE = P(UO) * L(UO) (1)

where RE is the risk exposure, P(UO) the probability of an unsatisfactoryoutcome and L(UO) the corresponding loss incurred. Similarly, the benefit orleverage of the implementation of a risk reduction strategy might be assessednumerically thus:

REbefore — REafterRRL =

Risk reduction cost (2)

where REbefore is the current risk exposure, REafter is the risk exposure aftertaking risk reduction action and the "risk reduction cost" is the cost of thataction.



RISK MANAGEMENT AND SOFT SYSTEMS METHODOLOGY

Texts describing the Soft Systems Methodology [1-4] make no explicit mentionof risk. They do recommend that systems changes be implemented incrementallybut more because of the impracticality of making several significant changessimultaneously than as an explicit risk reduction technique. The premise of thispaper is that SSM can be enhanced by addressing risk concerns explicitly. Theexpected outcome is the identification of system changes that are implementedmore smoothly, producing systems that are more robust.

There are three distinct areas in which risk management is relevant to SSM.They are:1. Risks in the application of the SSM process itself, for example is the SSM

consultant/analyst sufficiently experienced, has the problem, its scope andits boundaries been properly identified, have models really been validatedand accepted by all the important stakeholders?

2. Risks in the system produced by the SSM study. Given that SSM mayresult in the recommendation of a 'revolutionary' system, is it a sufficiently'safe' system, free from unacceptable operating risks?

3. Risks in the implementation of the system resulting from the SSM study.These are basically risks of acceptance, risks to budget or schedule, ortechnical risks where the system uses new technology, or uses technologyin novel ways.

In order to limit this study to the scope of one paper, we concentrate on thesecond of these three risk areas. The other two will be the subject of futureresearch.

Risk investigation is essentially a process of critical evaluation and so is bestconsidered after a creative phase of analysis in which the product or products ofanalysis have been developed and are ready for assessment and refinement. Onthat basis there are four phases of SSM (see Figure 1) where risk could beaddressed:1. when the problem situation has been described (phase 2);2. when root definitions of relevant systems have been produced (phase 3);3. when conceptual models have been derived from the root definitions (phase

4); and4. when feasible, desirable system changes have been determined (phase 6).

1. Risk and the Problem SituationOn a first consideration, it seems reasonable to examine risk implications aftercompleting an SSM analysis of the problem situation. This would allow thecurrent risk exposure to be determined, ready for subsequent comparison withthe risk exposure for any proposed system. Unfortunately, examining riskduring problem analysis is actually counter-productive, because it requires theanalyst to explore the current system in more detail than is desirable. The basicphilosophy of SSM suggests that the current system should only be consideredin sufficient depth to build up an understanding of its purpose or purposes. Inthis way the analyst is not tempted to model what exists rather than what shouldexist. By implication, therefore, the earliest practical starting point for a riskinvestigation is phase 3 of SSM, where root definitions are developed. Risksassociated with the current system can instead be considered later duringconceptual modelling in phase 4.



2. Risk and Root DefinitionsIdentifying risks at the root definition stage can help to determine systemconstraints for inclusion in each root definition. Consider, for example, the rootdefinition developed earlier for the video library, namely:

A Perfect Vision owned system to provide home entertainment tothe 'paying public', by supplying entertainment media, whilerecognising the need for the company to make a profit.

One obvious risk with this undertaking is that the service provided may not meetthe needs of its likely customers. This then leads to the constraint that local userneeds should be taken into account, giving a revised root definition of the form:

A Perfect Vision owned system to provide home entertainment tothe 'paying public', by supplying entertainment media, whiletaking account of local demand for such services and recognisingthe need for the company to make a profit.

The inclusion of this constraint in the root definition means that local needs willhave to be addressed explicitly in the derived conceptual model and insubsequent analysis phases, and so cannot be overlooked.

At this level of analysis only major threats should be included to avoidunnecessary clutter in the root definition. For example, although failure to findappropriate staff for the library is a clear risk it has (at present) such a lowprobability of occurrence that it does not impose a significant constraint on thedevelopment and operation of the system.

Overall, the recommended procedure for evaluating each root definitionwould be:1. identify risks without critical evaluation;2. use a risk exposure calculation to prioritise the risks;3. discuss with the client how many of these risks should be taken into

account; and4. derive constraints based on the selected risks and add them to the root

definition.

3. Risk and Conceptual ModelsRisk can be considered at two checkpoints in the development of conceptualmodels:1. after each conceptual model has been constructed, to ensure that it has been

adequately formed;2. when the consensus primary task model has been developed (by combining

the individual conceptual models), to ensure that the resulting model dealsadequately with the separate risks and to examine risks resulting frominteraction and conflict among the models.

In the first case, following the guidelines for the construction of conceptualmodels, it will often emerge that many risks are already being taken intoaccount. This is partly through the inclusion of constraints from the rootdefinition and partly because a viable system is required to have a monitoringand control activity to ensure its "effectiveness, efficiency and economy", asillustrated in Figure 2. The presence of this activity then forces a consideration



of planning and the setting of performance targets - actions that will help toreduce risk.

One way of addressing risk in systems described by conceptual models is toexamine each activity in turn, identify associated risks and determine whether ornot those risk are handled by one or more other activities; if not, then additionalactivities must be defined. For example, the central activity in Figure 2 is"Supply media for users", where some of the obvious risks include failure tosupply appropriate media, failure to supply media at an acceptable price, andfailure to respond to changing market conditions. Figure 2 shows that there are,in this case, activities that potentially cover all of these concerns; the lower levelmodels for each activity would, of course, have to be explored to ensure that therisks are indeed being addressed adequately.

One major general risk that is not described in the video library conceptualmodel is loss of business information. This could range from the destruction ofcustomer information, by accident or neglect, to the leakage of tradinginformation to competitors. This is a concern across the whole system and so isbest expressed explicitly in the top-level model, perhaps as an activity "managebusiness information". The introduction of a new activity will then require itsconnection to existing activities and a consideration of the knock-on effects inlower level models.

The overall process here is one of trying to identify significant threats,determining if the models cope adequately with those threats, and makingadjustments as necessary. In this way the operation of each system described bya conceptual model is made more sturdy. The next stage of the SSM analysis isto combine the models and re-assess the risk, looking in particular at theimplications of interactions among the different models and any areas of conflictthat arise. For example, it may be decided that another potential role of the videolibrary is to provide educational media, such as video manuals, tutorials,instructional courses and so on. A root definition and conceptual model for thisviewpoint would then be derived. In practice, such definitions turns out to bevery similar to those given already for the entertainment model. Thus the task ofcombining the models is relatively straightforward. However, there is oneimportant conflict to consider, namely the partition of system resources betweeneducation and entertainment. This constitutes a risk and so needs to becontrolled, which means adding an activity of the form "Determine relativeeducational /entertainment ratio" to the consensus model.

Having agreed a consensus model, it is no longer 'conceptual' and becomesthe basis of system change; from here on it can be considered the requiredsystem model [9]. The next refinement step is to examine each activity in termsof its inputs and outputs and so make the model more precise and less abstract.A tabular procedure to assist this stage has been proposed by Wilson [3]. Avariation of this approach is described in [9], in which the activities areconsidered to be a set of communicating processes, with every data source andsink named. An interaction table is used to describe the relationship betweenactivities. Figure 6 shows an example of part of the interaction table for the"Lend items to customers" conceptual model in Figure 4. It is assumed that toolsupport will be provided to assist with the construction of this table and in thenaming of the entities involved.



Al. Identify customer details: Obtain customer details (II) from the customer to produce acustomer descriptor which is then used for a registration check (12).

InteractionII. Obtain customer details12. Pass customer descriptor

Linked Process DataRl: Customer Dl: Customer details (IN)A2: Check customer is registered D2: Customer descriptor (OUT)

A2. Check customer is registered: Using a customer descriptor (12) check registration records(13) in the registration store to determine the registration status of the customer. If thecustomer is registered, allow the loan of an item to proceed (15) using his/her registrationrecord', otherwise register the customer (14) using the customer descriptor.

Interaction12. Receive customer descriptor13. Inspect registration records14. Pass customer descriptor15. Pass registration record

Linked Process

R2: Registration records storeA3: Register customerA4: Lend items

Data

D3: Registration records (IN)D2: Customer descriptor (OUT)D4: Registration record (OUT)

Figure 6: Sample Interaction Table

The activities in each model are labelled to aid their identification (Al, A2, andso on). Each activity is described briefly to indicate (i) its purpose; (ii) thesequence of interactions that occur to achieve that purpose; (iii) the datainvolved; and (iv) the processes with which it interacts. Reference numbers areassigned to each distinct component in this description: interactions (I),repositories (R) and data (D).

Each activity will typically involve one or more interactions with otherprocesses. Each interaction is explained individually by an entry in the table. Anentry comprises (i) a brief description of the interaction; (ii) the identification ofthe other process involved; and (iii) an identification of the data transmitted in theinteraction, including an indication of its direction of flow - either an input to theactivity (IN) or an output from the activity (OUT).

Building this table makes translation into other types of process-orientedmodel, such as a dataflow diagram [10], largely mechanical. It also provides thebasis for a deeper risk analysis. Using the information in the interaction table alist of risks can be identified for each activity and their predicted consequencesindicated, as shown in Figure 7.

Activity: Identify customer detailsRisk

Failure toidentify acustomer

Customerdescriptorunavailable

Consequences

No hire -Loss ofsalesHire - possibleloss of stock


Risks -CurrentSystemCustomer forgetscard;Dishonestcustomer usesfake name;Assistant doesnot checkidentityCustomer forgetscardCard isunreadable

Risks -ProposedSystem (ifdifferent)

Risk Reductiontechniques

Rule that "nocard/ ID - nohire";Assistant mustcheck address

Rule that "nocard/ ID - nohire"Replace cardperiodically



Activity: Check customer is registeredRisk

Registration datacannot be found

Illegal

Consequence


Loss of stock

Risks -CurrentSystemRegistrationbook is lost/destroyedCustomer namecannot be foundAssistant forgetsto check ID

Risks -ProposedSystem (ifdifferent)Loss/ corruptionof data

Illegal access tocomputer system

Risk Reductiontechniques

Off-site backups

Password system

Figure 7: Sample Risk Table

This table can be produced as follows:

Step 1: Identify risks and consequences for each activityThe means of identification of risks is simply to examine each interaction and thedata associated with it. In each case, conditions under which the interactionmight fail or where the input or output may be unsuccessful are considered risksand added to the list. Unsuccessful outcomes may result in partial or totalfailure. These are generic risks that are then considered more specifically for thecurrent and proposed system.

Step 2: Identify and assess risks specific to the problem situationIn step 2, the analyst finally examines risks in the current system. This can bestarted by looking at each generic risk identified in step 1 and determining how itrelates to the current system. For example, the generic risk "loss of customerdetails" can now be considered more specifically knowing how customer detailsare actually recorded. Other risks should also be identified using standardtechniques [8]. It is important to appreciate all risks in the current system even ifthey have no direct bearing on the proposed changes; if they can affect theoverall successful operation of the system they must be addressed.

Step 3: Identify and assess risks associated with the recommendationsThe proposed changes to the system involve two types of risk:1. risk associated with the proposed new system - product related risk; and2. risk associated with the process of change - development related risk.

Product related risks can be identified in a similar fashion to the identificationof risks for the current system by looking at the generic risks established fromthe interaction table and making these specific to the proposed system. Thus if acomputer based information system is to replace a manual procedure the specificrisks of computer system storage and use are introduced. The identification ofrisks can be carried out in a similar fashion to that used for the current situation.

For development related risk, many of the risk items will be generic and socan be largely examined using standard checklists described in the literature,such as [11]. Again, however, it will still be necessary to consider if there arespecial circumstances that involve additional risk.

Step 4: Refine recommendationsHaving now appreciated the risks involved in the proposed system in relation tothe current system some refinement of the proposal may be necessary at this



stage. Note that the details of the change are now sufficiently precise to allow amore exact estimate of risk exposure to be calculated.

Step 5: Develop a risk reduction planHaving made recommendations and had them accepted, the next step is to createa plan for how the risks will be controlled. Ways of resolving each risk areidentified (final column in Figure 7). For example, the risk of illegal access tothe computer system may be reduced by specifying the need for a password toaccess the system.

Such an investigation will yield a list of risk resolution techniques that may ormay not be implemented depending on their cost. These can be viewed asadditional to the recommendations for change already made.

The development risks should also have proposals for risk reduction.Techniques in this area, such as prototyping, cost benefit analysis andsimulation are described in the literature [12, 13].

Step 6: Risk controlMost risks will be not be resolved fully and require a risk monitoring plan. Theconceptual model already includes an activity for monitoring the other activitiesso this can be extended to include a monitor of the risk items identified. Taking,for example, computer system failure, the plan might include a means forrecording how often the computer system was unavailable with reports on thisfailure being made periodically. Thus, for each risk not resolved, a risk controlplan with a means of monitoring and taking possible corrective action isproduced.

CONCLUSION

This paper proposes an enhancement to the soft systems methodology, SSM, todeal with risk in the system being analysed so that any changes made produce arobust system. Risk is considered at several points in the analysis and possibleprocedures for identifying and dealing with risk are suggested. These proposalsseem practical but they have still to be applied to actual systems. This will beattempted in the near future. One important concern is to ensure that the softsystems process is not affected adversely by the additional consideration of risk.In other words, to ensure that the inclusion of risk management is indeed a trueenhancement to SSM.

ACKNOWLEDGEMENTS

We are very grateful to Raymond Oakes for his help in developing the videolibrary example and for his support generally.

This research is being undertaken as part of the RUNES project(Requirements Understanding, Negotiation, Expression and Scrutiny), fundedby the University of Ulster. RUNES, is broadly concerned with investigatingtechniques for improving the requirements definition process, and thedevelopment of tools to support that process. The work is also partly funded bythe UK/Hong Kong Joint Research Scheme of the British Council.



REFERENCES

1 Checkland PB: System Thinking, System Practice, Wiley, 19812. Checkland PB & Scholes J: Soft Systems Methodology in Action, Wiley,

19903. Wilson B: Systems: Concepts, Methodologies and Applications, 2nd

Edition, Wiley, 19904 Rosenhead J (ed): Rational Analysis For a Problematic World, Wiley, 19895. Mingers J and Taylor S: The Use of Soft Systems Methodology in Practice,

Journal of the Operational Research Society, 43(4), pp. 321-3326 Lewis, PJ: Rich Picture Building with Soft Systems Methodology, Eur. J.

Inf. Systs, Vol. 1, No. 5, pp. 351-360, 19927 Buzan, T.: Use Your Head, BBC Publications, 19868. Boehm BW: Software Risk Management, IEEE Computer Society Press,

19899. Bustard DW, Oakes R and Heslin E, Support for the Integrated Use of

Conceptual and Dataflow Models in Requirements Specification,Colloquium on Requirements for Software Intensive Systems, DRAMalvern, May 1993, pp. 37-44

10 Mingers, J.: Comparing Conceptual Models and Data Flow Diagrams,' Computer Journal, 31(4), pp. 376-378, 1988

11. Boehm, B: Improving Software Productivity, IEEE Computer, 20(9), Sept1987 ,n .

12. Wolff, JC: The Management of Risk in Software Development: ProjectSP' and the 'New Spiral Model', Software Engineering Journal, 4(3), pp.134-142, May 1989 .

13 Tate, G: Prototyping: Helping to Build the Right Software, Information and' Software Technology, 32(4), pp. 237-244


Documents

Enhancing the soft systems methodology Polytechnic of Hong … · 2014-05-19 · their implementation carries a relatively high risk. At present, however, SSM makes no provision for