critical_systems_analysis_and_design__a_personal_framework_approach.pdf

As systems analysis and design is becoming increasingly concerned with the organization as awhole, systems analysts need to concern themselves with organization design as well as systemsdesign.

This book takes a unique look at systems analysis and design by using an approach that pro-vides learners with a critical personal framework. This enables the reader to develop a personalmethod for critically considering and developing a knowledge and practice of systems analysis anddesign by contrasting the real world with the systems world, thus differentiating it from existingsystems analysis books.

Each chapter of this book begins by highlighting what can be learned by completion of the chapter and ends with a critical skills development section that contains activities, tasks anddiscussion questions. Chapters include:

• systems analysis and design in concept and action;

• structured data modelling;

• making systems analysis and design inclusive.

Although the discussion and examples in this text are drawn primarily from business informa-tion systems, the lessons apply to both government and healthcare information systems and tosystems development in general.

Critical Systems Analysis and Design makes a complex area of study accessible and relevant and assuch is an indispensable textbook for both advanced students and professionals concerned withthe innovation of information systems.

Nandish V. Patel is Deputy Director of Studies on The Brunel MBA programme at BrunelUniversity, Uxbridge.

0

0

0

0

Critical Systems Analysis and Design

Critical Systems Analysis and Design

A persona l f ramework approach

Nandish V. Patel

111

0

11

0111

0

0

11p

First published 2005by Routledge2 Park Square, Milton Park, Abingdon, Oxon OX14 4RN

Simultaneously published in the USA and Canadaby Routledge270 Madison Ave, New York, NY 10016

Routledge is an imprint of the Taylor & Francis Group

© 2005 Nandish V. Patel

All rights reserved. No part of this book may be reprinted or reproduced orutilized in any form or by any electronic, mechanical, or other means, nowknown or hereafter invented, including photocopying and recording, or in anyinformation storage or retrieval system, without permission in writing from thepublishers.

British Library Cataloguing in Publication DataA catalogue record for this book is available from the British Library

Library of Congress Cataloging in Publication DataPatel, Nandish V., 1959–

Critical systems analysis and design: a personal framework approach/Nandish V. Patel.

p. cm.Includes bibliographical references and index.

1. Management information systems. 2. Knowledge management.3. Systems analysis. 4. System design. 5. Problem solving.6. Critical thinking. I. Title.HD30.213.P383 2005658.4′038′011–dc22 2004011363

ISBN 0–415–33215–X (hbk)ISBN 0–415–33216–8 (pbk)

4149P CRITICAL-PT final/gk 27/10/04 4:19 pm Page iv

This edition published in the Taylor & Francis e-Library, 2005.

ISBN 0-203-40097-6 Master e-book ISBN

ISBN 0-203-67097-3 (Adobe eReader Format)

"To purchase your own copy of this or any of Taylor & Francis or Routledge'scollection of thousands of eBooks please go to www.eBookstore.tandf.co.uk.”

My darling daughter Risha(which means knowledgeable)for a brighter future

111

0

11

0111

0

0

11p

List of illustrations viii

Preface xi

Abbreviations xv

Introduction xvi

Part IFoundations for critical learning and teaching 1

1 The PAC cycle 3

2 Critical knowledge and practice

framework 28

Part IIIS, projects and application domains 53

3 Systems analysis and design in concept

and action 55

4 Systems project management 93

5 Systems analyst 118

Part IIISystems analysis 135

6 Requirements: the system to be (or not) 137

7 Structured data modelling 154

8 Structured process modelling 171

9 Object modelling 195

Part IVSystems design 215

10 Interface, input and output design 217

11 Systems design 225

Part VCriticality, paradigms and IS development 241

12 Social action 243

13 Critical reflection 252

14 Ways of thinking and acting 263

Part VIThe future of IS development 273

15 Making systems analysis and design

inclusive 275

Glossary 283

Index 288

111

0

11

0111

0

0

11p

vii

Contents

Figures

0.1 Chapter map in the context of criticality xx

1.1 The PAC cycle 42.1 Critical knowledge and

practice framework 302.2 The system concept 402.3 The SDLC – an example of a

populated critical framework 473.1 Data, information and

knowledge in technological and business contexts 57

3.2 Systems development life cycle in the context of businessorganizations 60

3.3 Structured IS modelling techniques within SDLC phases 71

3.4 Object-oriented techniques within SDLC phases 73

3.5 SSADM phases, techniques and tools, and deliverables 76

3.6 Critical framework: the ontology of the SDLC 80

4.1 The precedence network 1044.2 Capability Maturity Model for

software 1074.3 Critical framework: systems

project management 110

5.1 Role of the systems analyst 1225.2 Critical framework: systems

analyst and the SDLC 1286.1 Critical framework: peoples’

knowledge of systems requirements in the real world 145

7.1 Naming entity type relationships 161

7.2 Critical framework: systems ontology based on logical datamodelling 165

7.3 Teaching allocation relationship 1698.1 DFD notation 1738.2 DFD context diagram for a PC

inventory system 1758.3 Level 1 DFD for PC inventory

system 1768.4 Entity life history form 1778.5 Decision tables 1808.6 Schematic decision tree 1818.7 Student module condonement

logic 1818.8 Action diagram 1818.9 SSADM data flow diagram

notation 1828.10 Critical framework: systems

ontology and process capture 183

viii

Illustrations

8.11 Critical framework: perfect andunambiguous logical modelling 186

8.12 Critical framework: whose process models? 189

8.13 Critical framework: ambiguity and imperfection in the real world of human problems 191

9.1 Generalization–specialization pattern 197

9.2 Gen–spec example for insurance policy 198

9.3 A diagrammatic representation of an object 199

9.4 An example object for car insurance 199

9.5 Insurance policy object 1999.6 Class template 2009.7 Home contents insurance

policy class 2009.8 Polymorphic class and

subclasses 2019.9 UML notation for use case

diagram 2039.10 Use case example for

processing an insurance policy 2039.11 Use case script for online

purchase 2049.12 Description of a service in

structured English 2049.13 UML diagram types and

diagrams 2059.14 Components of a class model 2079.15 Critical framework: object-

orientation 20910.1 An interface class 22010.2 Critical framework: human

machine interaction systems ontology 221

11.1 Structured systems design documents 227

11.2 Nassi-Schneiderman diagrams 22911.3 Collaboration diagram for

insurance claim 231

11.4 Package diagram 23111.5 Deployment diagram 23311.6 Critical framework: ontology

and systems design 23512.1 Technical factors, social

action and IS 24412.2 Critical framework: social

action 24813.1 Improving the critical

framework 25614.1 Paradigmatic critical

framework 26814.2 Critical thinking and

paradigms 26915.1 Deferred systems and

organization 27815.2 Critical framework: inclusive

systems analysis and design 280

Tables

1.1 An objectivist PCF 151.2 A subjectivist PCF 161.3 A praxis PCF 171.4 Critical thinking skills 181.5 Repertory grid technique 221.6 An assumed analyst’s repertory

grid 231.7 Visual focusing (A) 231.8 Visual focusing (B) 231.9 Agreement scores 231.10 Similar elements 241.11 Similar-dissimilar personal

constructs 243.1 Structured systems analysis and

design techniques 703.2 Constituents of the application

domain 883.3 Personal constructs for

systems 894.1 Drivers for IT/IS investment 964.2 System project roles and

responsibilities 97

111

0

11

0111

0

0

11p

ix

............................................................................................................................................Illustrations

4.3 Project planning techniques 1014.4 Elements of a precedence

network 1054.5 Personal constructs for

project management 1135.1 Qualities of systems analysts 1195.2 Systems analysis techniques 1245.3 Systems analyst skills 1305.4 Personal constructs for systems

analysts 1326.1 Issues in requirements

analysis 1476.2 Database model types used in

Information Systems 1496.3 Personal constructs for system

requirements 1507.1 Entity type, attributes,

values 1607.2 Entity relationship types 1617.3 Relational data structure

normalization 1627.4 Logical database records based

on entity definitions 1637.5 Personal constructs for

data, information and knowledge 167

8.1 Definitions of DFD symbol notations and DFD drawing rules 174

8.2 Structured English 1798.3 SSADM technical products 1828.4 Personal constructs for process

modelling 1929.1 Personal constructs for object

modelling 21210.1 Personal constructs for

human–computer interaction 22311.1 Personal constructs for system

design 23812.1 Personal constructs for

organization 25013.1 Personal constructs for

criticality 25913.2 Questioning structured systems 26013.3 Questioning object-oriented

systems 26113.4 Comparative analysis of

systems ontology with the messy world 261

14.1 Personal constructs for praxis 27015.1 Personal constructs for future-

orientation 281

x

Illustrations............................................................................................................................................

The purpose of this book is to redress the gap ofcriticality in systems analysis and design. Thedevelopmentofcriticality in learners is the ration-ale that underpins programme specifications atuniversities, and increasingly it is the preferredattribute of professional employees in com-panies. Criticality is important in systems analy-sis because its scope has vastly increased since the 1960s. Then, it was concerned with thedesign of Information Systems (IS) for local ordepartmental functions. It now covers the wholeorganization in system projects involving busi-ness process redesign, eCommerce, eBusiness,and knowledge management systems. Systemsanalysts are now not just systems designers, theyare part of a team involved in organizationdesign too.

IS is an important subject in academic cur-ricula in undergraduate and postgraduate pro-grammes at universities. Learners are exposedto how technical analysis is conducted, how touse formal notations to develop systems modelsand designs, and how developed systems modelsand designs are implemented using InformationTechnology (IT). The emphasis is on providingcomprehensive knowledge and the develop-ment of necessary problem-solving skills forlearners to become practitioners. This empha-sis has resulted in an absence of criticality in thesubject, which for university degree pro-

grammes in business schools and computingdepartments is probably a significant weakness.Learners and practitioners need to reflect criti-cally on the problem of IS development encom-passing organization design, in particularsystems analysis and design. Such criticality isnecessary in postgraduate programmes and inworkplaces where critical thinking is often theimpetus for innovation.

Teachers are concerned about the divergencebetween textbook knowledge of IS and systemsanalysis and design and its practice in organ-izations. The formal approaches that constituteknowledge seem at odds with the domains inwhich they are applied, namely organizationsand people. Organizations, and the people whowork in them, make it difficult for practitionersto deploy formal IS methodologies or systemsanalysis and design techniques and tools asintended by their authors and inventors. Oftenpractitioners resign themselves to the fact andstop using formal methodologies, techniques and tools. This is regrettable because formalismand ontological knowledge of systems can makereal contributions to practice. Teachers areaware that what they teach their learners in theclassroom seems to lack relevance to actual prac-tice in software development companies and inbusiness organizations that develop and use IS.Yet the problem remains. Teaching knowledge

111

0

11

0111

0

0

11p

xi

Preface

is fundamental to understand the vitally revolu-tionary phenomenon that IS and IT constitutesin the twenty-first-century organization.

To bridge the relevance gap between know-ledge and practice it is possible to present know-ledge to learners in a stimulating and interestingmanner. A Personal Critical Framework (PCF )approach will incite learners, and practitioners,to think critically about how they internalize thetaught knowledge and how they would put itinto practice. The author’s ten years of reflec-tive teaching practice and innovations in peda-gogy has resulted in an exciting way of teachingthat appeals to learners. Taking a HolisticApproach to Learning and Teaching Inter-action (Patel, 2003) can make the subject mater-ial interesting and relevant to learners’ personaland professional development, and most impor-tantly to their notions of the self and theirappreciation of the role of knowledge in per-sonal and working lives. The Holistic Approachhas been shared with colleagues and nationallyat conferences on learning and teaching.Learners and colleagues have applauded it, and learners are satisfied with their levels ofperformance and knowledge insights achieved.

In the Holistic Approach, learning andteaching interaction is defined as the socialcontext in which a learner, who is seeking toimprove the self, is taught specific disciplineknowledge by a knowledgeable teacher whoseaim is to disseminate discipline knowledge andimprove the quality of life of the learner bydeveloping him or her into a critical learner.The Holistic Approach seeks to develop critical,confident, and independent learners capable ofaction in their professions, and in society gen-erally. The task of the holistic teacher is toenable critical learners to direct themselves andto devise ways of enabling learners to do that.

The purpose of the Holistic Approach is todevelop critical thinking skills in learners andpractitioners. Cognitive critical thinking skills

are difficult to develop in a practical subject like systems analysis and design. The HolisticApproach makes use of PCF to enable learnersto relate taught material to the actions they per-form or would perform. The Holistic Approach,PCF and a Critical Framework for studyingand analysing the taught material are combinedto provide a set of cognitive tools for learnersand teachers that engender critical thinking.

The pedagogy of this textbook is termedcritical learning in which the learner is regardedas a critical learner. The traits of a critical learnerare criticality, confidence, and independence.The critical learner is an individual who has toact eventually in real situations. Such purpose-ful action requires critical faculties that enableindividuals to make decisions about the action,based on knowledge that they learn to assess forits validity in practice. Confidence is requiredto act. The holistic teacher’s task is to providesuch confidence by developing independentlearners. This independent trait of the criticallearner reflects that the individual is responsiblefor their action. A critical learner can only beindependent if they are confident, and confi-dence only develops if learners are taught to bereflexive. This textbook introduces the devel-opment of a PCF as a device to structure know-ledge and purposeful action that is based oncritical thought. The development of a PCF andits critical evaluation can lead to confidence andindependence in action.

As Barnett argues:

The challenges facing the university in developingcritique-in-action are, in part, concerned with theontological questions of what it means to be a self inthe world, and about the relationship of the self tothe world of work.

(Barnett, 1997: 129)

Barnett’s comments have a resonance with thenotion of praxis. Praxis is the art of acting in

xii

Preface..................................................................................................................................................

given conditions in order to change them. It isprecisely this kind of situation that systemsanalysts and developers of IS encounter. Action in existing situations with given condi-tions requires critical thinking. The HolisticApproach is intended to develop critical learn-ers who will be capable of such critical praxis. Ithas been conceptualized as a result of the suc-cess of the author’s teaching of IS with thisapproach and appreciative learners’ favourablecomments.

This textbook is aimed at postgraduatelearners undertaking a Master of Science orMaster of Business Administration degree. Itspurpose is to develop critical learners capableof making judgements on how to use the exist-ing knowledge on IS development in practicalwork. It can also be used at level three of undergraduate programmes. The traits of criti-cality, confidence, and independence of a critical learner enable an individual to act inreal situations in relation to the discipline know-ledge taught. The basis of the teachingapproach is praxis – our body of knowledgearises from the very problems that we need tosolve to make progress. Knowledge that arisesfrom practice is in turn used to improve per-sonal effectiveness. The discussion and exam-ples in the text are from business IS, though thelessons apply to both government and health-care IS and to systems development in general.

I am grateful to all my learners who havebeen exposed to my pedagogical approach to

learning critically about IS and practice. Theyhave been, and continue to be, learners on postgraduate programmes in IS and SystemsProject Management. Many masters and MBA candidates have taken my modules on IS development. They encouraged me to con-tinue using the Holistic Approach because of the benefits they have derived as practitioners.In particular, graduate trainees on a day-releasecompany-based programme in InformationManagement have encouraged me to continuedeveloping the approach. All my learners have contributed to my learning on how toteach an essentially problem-solving subjectfrom a critical perspective, and I am pleased and gratified that I have been able to contributeto even highly experienced practitioners too:

Nandish,

May I just say that I enjoyed your lectures a greatdeal, having worked in IT for 30 years, I understoodand appreciated what you were saying and alsolearned a lot, it was a lecture that I always lookedforward to attending!

Best regards

Acknowledgements

I am grateful to Jacqueline Curthoys, FrancescaPoynter and Rachel Crookes at Routledge. Iwould like to thank them especially for theirkind consideration.

111

0

11

0111

0

0

11p

xiii

..................................................................................................................................................Preface

111

0

11

0111

0

0

11p

xv

ASD Agile Software DevelopmentBPR Business Process Re-engineeringCASE Computer-Aided Software

EngineeringCMM Capability Maturity Model for

software developmentCoCoMo Constructive Cost ModelCOTS Commercial-Off-The-Shelf

SoftwareDBMS Database Management SystemETHICS Ethical and Technical

Implementation of ComputerSystems

IS Information SystemIT Information TechnologyJAD Joint Application DevelopmentJSD Jackson Systems DevelopmentJSP Jackson Structured Programming

NCC National Computing CentreNIMSAD Normative Information Model-

Based Systems analysis and Design

OSS Open Source SoftwarePCF Personal Critical FrameworkRAD Rapid Application DevelopmentSDLC Systems Development Life CycleSPICE Software Process Improvement

and Capability DeterminationsSSADM Structured Systems Analysis and

Design MethodologySSM Soft Systems MethodologySTRADIS Structured Analysis, Design and

Implementation of Information System

UML Unified Modelling LanguageXP eXtreme Programming

Abbreviations

How to use the book

The aim of this book is to admit learners andpractitioners into systems analysis and design.Admission into a subject is called vishay prevasha

in the Indian Sanskrit language. It means toprovide learners themselves with critical facul-ties for acquiring and developing knowledge ina discipline. The book is not a technically com-plete text on how to undertake systems analysisand design. Rather, only material sufficient to form the basis for developing criticality isintroduced.

Criticality is explored in this textbookthrough: transformatory critique, refashioningof traditions, reflexive criticality and criticalskills, after Barnett (1997). It is to be distin-guished from the notion of simply being taughtknowledge. The central theme of the textbookis the development of a PCF, either for learn-ers or practitioners. Learners and practitionerscan think critically about knowledge and per-sonal action and develop personal constructsbased on critical thought. The PCF is to bedeveloped on the basis of critical understandingof knowledge and practice. It should form a setof related cognitive constructs derived throughreflective study or reflective practical experi-ence, or both. The value of a PCF is to antici-pate or determine future action and, based on

personal experience, it is to be continuallyrevised. It serves to enable learners to developindividually methods for critical reflection onknowledge and practice.

The PCF and the Critical Knowledge andPractice Framework provide the lenses for crit-ically studying systems analysis and design.They provide the critical focus. These frame-works serve to encourage learners and practi-tioners to reflect critically on the notion ofsystems, methods, techniques and tools andengender reflective and critical discussionaimed at the development of a PCF.

To develop a PCF each chapter serves three purposes. It presents sufficient material tobegin thinking on a specific topic. The materialis then related to the Critical Knowledge andPractice Framework designed to enable reflec-tion. The PCF is then developed through ques-tions, exercises, and activities on the basis of thereflective study of the material presented andother readings. This section in each chapter is onhow the Critical Knowledge and PracticeFramework can be used to develop the concep-tual and praxis elements of a PCF. Systemsanalysis and design concepts and analysts’ prac-tice based on conceptual and technical know-ledge need to be subjected to criticality. Thesection enables critical evaluation and develop-ment of professionalism. Analysts can assess its

xvi

Introduction

value in individual and professional terms. Inparticular, they can consider the impact of know-ledge on practice.

Student-centred learning

This textbook can be used in conjunction withthe student-centred approach to learning andteaching. As with criticality, student-centredlearning requires learners to take responsibilityfor learning, but it also requires them to beinvolved in its delivery. It reinforces the trans-fer of ownership of knowledge from the teacherto learners. It is particularly relevant to post-graduate learning and teaching, where it candraw on learners’ experiential knowledge.

The Systems Development Life Cycle(SDLC) is introduced. Learners should beencouraged to do simple, uncomplicated exer-cises to familiarize themselves with the tech-niques, tools and methods. Readings of relevantresearch papers and cases then lead learners torecognize and question premises and assump-tions made by the various approaches, SDLC,methodologies, techniques and tools. Question-ing leads to the development of a critical per-spective on the various problems in structuredand object-oriented analyses. Learners can thenbe encouraged to think how improvements inknowledge and practice can be made in thelight of the critical reflection.

Teachers’ own seminar exercises, cases,research papers, and seminar discussions can beused to involve learners in the delivery. Theteacher can introduce topics via a short inter-active lecture and then facilitate seminar dis-cussion. The discussion can be based on casesand research papers. Learners should beencouraged to lead discussions in small groups,which then report to the plenary. The plenarydiscussion itself will result in a synthesis oflearners’ contribution to the delivery.

After reading the Delphi Report’s definitionof critical thinking, self-examination and self-correction, learners should attempt the PCFdevelopment section in each chapter. Its pur-pose is to encourage critical reflection. It con-tains questions encouraging critical reflection,individual and group discussion exercises, andactivities that lead to the development, and sub-sequent enhancement, of personal constructs.The PCF is thus progressively developed in eachchapter.

As there are no right or wrong answers for aparticular systems analysis problem no solutionsare provided. The teacher can determine whento make use of the student-centred material andprovide guidelines to learners on acceptable res-olutions. References to research publications inthe textbook are not reproduced but a full refer-ence is provided in the further reading sections.

The teacher is encouraged to think of similaractivities to those presented in the PCF devel-opment sections. Given the interpretive natureof many of the questions and activities in thePCF development sections no model answersare provided. Teachers should use their discre-tion to judge what constitutes an appropriateresponse by learners. The author is available todiscuss the development of teachers’ initiativesand learners’ responses via the textbook’sassociated website.

Supporting web resources

Additional material on the holistic approach to teaching and learning is available at www.routledge.com/textbooks/0415332168.Teachers’ activities in developing PCF are:

• Introduce concepts of systems analysis anddesign and present methods, techniques andtools.

• Use the Critical Framework to developcritical thinking. Relate real and practical

111

0

11

0111

0

0

11p

xvii

............................................................................................................................................Introduction

problems in applying systems analysis anddesign in the real world, and seek pragmaticresolution of the problems.

• Encourage learners to develop a PCF con-sisting of personal constructs. Personal con-structs may be derived from practice ortaught material, or from both sources. APCF should include a list of problems andissues in systems analysis and design, com-piled by individuals, groups or the teacher.

• Formulate questions designed to make learn-ers think about clients, systemic problems,social factors, organizational problems, com-munications problems, knowledge gaps, andother problems and issues. Relate these tolearners’ PCF by using exercises, discussionsand activities in the PCF development sections, thus progressively enhancing PCF.

• Develop their own activities for learners thatencourage them to think of how to resolvepractical problems in systems analysis anddesign, ranging from assumptions aboutorganizations, people, IT and IS, coveringconceptual deficiencies, difficulties withimplementing techniques, and using tools inreal contexts.

• Develop activities that encourage learners torelate their resolutions of practical problemsto PCF development and to question theeffectiveness of their resolutions in terms ofthe PCF.

Selective chapter readings

A chapter map is given in Figure 0.1. ExceptingPart I, the remainder of the book is organizedto reflect the phases of the SDLC. This doesnot justify the SDLC but recognizes the clearconceptual distinctions prevalent in researchand practice.

Chapters in Part I are essential readingbecause they provide the foundation for devel-

oping skills in critical thinking and the devel-opment of a PCF. Once the notions of a PCFand the Critical Framework are understood,other chapters may be read as required. Theselective reading of other chapters can then leadto the development of certain elements of aPCF. Teachers are encouraged to read the sup-plementary account of the Holistic Approach,available at www.routledge.com/textbooks/0415332168 because it explains the pedagogyunderpinning the approach to learning andteaching adopted in this book.

Chapter 1 explains the PAC cycle. Teachersand learners should read it. It details the com-ponents of a PCF and discusses how it shouldbe developed. It relates a PCF to action and dis-cusses the development of critical selves throughaction.

Chapter 2 explains the Critical Framework.Teachers and learners should read it. It detailsthe components of the Critical Framework andexplains how to apply them to study criticallytopics in systems analysis and design. TheCritical Framework is a set of constructs toenable criticality.

Part II covers conceptual foundations,project management and systems analysts. Areading of the chapters will develop the intel-lectual and conceptual elements of a PCF. Thiscoverage is required because criticality assumesconceptual understanding and argument.

Chapter 3 introduces fundamental conceptsand discusses their effect on analysts’ actions.The SDLC, structured and object-orientedsystems analysis and design, and methodologiesare covered. A reading of this chapter will leadto the development of fundamental and essen-tial personal constructs in analysis and designfor a PCF.

Chapter 4 examines systems project man-agement. It covers how an IS is selected fordevelopment, formulating a business case for its development, and project management

xviii

Introduction............................................................................................................................................

issues and techniques. Project management asplanned action is elaborated. A reading of thischapter will provide the basis for developingreflexive critical thinking and critical skills, andenhancement of the elements in a PCF.

Chapter 5 discusses the role of systems ana-lysts. The qualities and skills required, theirtasks, and the techniques and tools available tothem are covered. The working relationshipbetween systems analysts and stakeholders anddevelopers is discussed. A reading of this chap-ter will enable systems analysts to think criticallyof ‘the self’, and contribute to considering all theelements in a PCF.

Part III focuses on systems analysis. A read-ing of the chapters will enable a critical consider-ation of the instrument elements of PCF. Thesechapters are included because the developmentof reflexive criticality and critical skills assumesfamiliarity with the instruments of practice.

Chapter 6 explains the importance of under-standing and developing knowledge of what a new IS is required to do, or system require-ments. Structured and object-oriented tech-niques and alternatives are presented and criti-cally discussed. Chapter 7 introduces structureddata modelling techniques. It focuses on logicaldata modelling, entities, relationships, normal-ization and documentation. Chapter 8 intro-duces structured process modelling, coveringdata flow diagrams and business logic modellingtechniques. It also details SSADM technicalproducts. Chapter 9 introduces object-orientedanalysis, covering object modelling and UMLdiagrams.

Part IV focuses on systems design. A readingof the chapters in this part will enable a criticalconsideration of the design instrumental ele-ments of a PCF. Similar to the previous part,the chapters in this part contribute to reflexivecriticality and critical skills.

Chapter 10 examines user interface, inputand output design. Chapter 11 considers system

and data design, and covers change manage-ment because of its importance in introducingIS in an organization. A reading of these chap-ters will enable an appreciation of the systemlevel design issues and contribute to the per-sonal constructs and instrument elements ofPCF.

Part V relates the social context of systemsanalysis and design. It develops a critical per-spective through critical reflection of the previ-ous chapters and paradigmatic analysis. Areading of the chapters in this part will enablecritical consideration of the intellectual andconceptual elements of PCF. The developmentof transformatory critique and the possibility ofrefashioning traditions assume knowledge ofwhat constitutes knowledge and how it isacquired.

Chapter 12 considers social theory, organi-zational and political factors that are notcovered in structured and object-orientedanalyses. Chapter 13 is a critical reflection ofthe previous chapters in terms of human andorganizational factors. A reading of these chap-ters will contribute significantly to the ethics,assumptions of reality, personal constructs andinstrument elements of PCF.

Chapter 14 synthesizes knowledge andaction to deepen the knowledge element andenable reflection on praxis in PCF. It considerscriticality in terms of refashioning traditions. Itprovides a paradigmatic analysis of alternativeand emerging knowledge on systems analysisand design. A reading of this chapter will con-tribute to acquiring knowledge of assumptionsof reality, personal constructs and instrumentelements of PCF.

Chapter 15 takes a future-oriented perspec-tive. A reading of this chapter will provideknowledge of how emerging approaches aremaking paradigmatic shifts to make systemsanalysis and design inclusive of social and orga-nizational factors. It gives brief accounts of new

111

0

11

0111

0

0

11p

xix

............................................................................................................................................Introduction

Cha

pte

r 2:

Crit

ical

kno

wle

dge

and

pra

ctic

efr

amew

ork

Cha

pte

r 15

:M

akin

g sy

stem

san

alys

is a

ndd

esig

n in

clus

ive

Cha

pte

r 3:

Sys

tem

s an

alys

isan

d d

esig

n in

conc

ept

and

act

ion

Cha

pte

r 6:

Req

uire

men

ts:

the

syst

em t

o b

e(o

r no

t)

Cha

pte

r 7:

Str

uctu

red

dat

a m

odel

ling

Cha

pte

r 4:

Sys

tem

sm

anag

emen

t

Cha

pte

r 14

:W

ays

of t

hink

ing

and

act

ing

Cha

pte

r 10

:In

terf

ace,

inp

utan

d o

utp

ut d

esig

n

Cha

pte

r 5:

Sys

tem

san

alys

t

Cha

pte

r 1:

The

PAC

cycl

e

Cha

pte

r 9:

Ob

ject

mod

ellin

g

Cha

pte

r 12

:S

ocia

lac

tion

Cha

pte

r 13

:C

ritic

alre

flect

ion

Cha

pte

r 11

:S

yste

ms

des

ign

Cha

pte

r 8:

Str

uctu

red

pro

cess

mod

ellin

g

Ref

ashi

oni

ngo

f Tr

adit

ion

Tran

sfo

rmat

ory

Cri

tiq

ue

Ref

lexi

veC

riti

calit

y

Cri

tica

l Ski

lls

PR

AC

TIC

E—K

NO

WLE

DG

E

Figu

re 0

.1C

hapt

er m

ap i

n th

e co

ntex

t of

cri

tica

lity

and emerging approaches. Since a PCF isdesigned to facilitate how learners and practi-tioners anticipate action, this chapter is import-ant for anticipating future developments inknowledge and practice of systems analysis anddesign.

Each chapter has a section for the develop-ment of a PCF. It contains activities, questions,and tasks that will help to objectify and definepersonal constructs related to the three majorthemes and six sub-themes of the CriticalFramework. They will help start thinking on aPCF. It can be used to evaluate personal con-structs related to knowledge and practice forinclusion into a PCF. Where the questions oractivities require reference to an organization,it may be the university where you study or thecompany where you work. Some activities arealternatives and so do not need to be repeated,though using alternative methods to objectify aPCF can lead to more clarity. For all the activ-ities in the PCF development in each chapterrefer to the illustrative PCF in section 1.7 anduse the Delphi Report cognitive skills given inTable 1.4 in section 1.8.1.

The Critical Framework figures in eachchapter contain much critical information. It isnot all discussed or commented upon butselectively addressed. Teachers, learners, andpractitioners should study each figure andinvestigate and critically discuss the points rele-vant to their interests. The pragmatic resolutioncomponent is left with question marks in somechapters to prompt learners to think about theirown solutions to the problems depicted.

The chapters are mapped in Figure 0.1 in thecontext of the critical themes explored. Eachconcentric circle names the type of criticalitycovered in the relevant chapters placed in therelevant concentric circle. In accordance withthe purpose of this textbook, the chapters areevenly distributed around the themes of trans-formatory critique and refashioning of traditions

for critiques of knowledge, and reflexivity andcritical skills for critiques of praxis.

The placing of the chapters within the criti-cal themes is not exact. For instance, all thechapters contain a PCF development sectionthat spans all the critical themes. Chapter 5 onsystems analysts should actually be rooted in thecore transformatory critique and stretch outthrough refashioning of traditions and reflexiv-ity to the development of critical skills in thediscipline knowledge.

The ‘practice–knowledge’ bi-directionalarrow indicates that praxis is informed byknowledge and that knowledge is informed by praxis. Deep transformatory critique, theinner concentric circle, can have radical effectson practice, the outer concentric circle. Deepcritical skills, the outer concentric circle, canhave radical effects on knowledge, the inner concentric circle. In the outward direction,transformatory critique and refashioning of traditions in knowledge inform practice, and inthe inward direction critical skills and reflexivityin practice inform knowledge.

Learning outcomes

The outcomes of working through the chaptersshould be critically aware learners and reflexivepractitioners. They will be able to:

• Appreciate transformatory critique, refash-ioning of traditions, reflexive criticality andcritical skills as kinds of criticality of know-ledge and practice.

• Develop cognitive critical skills in inter-pretation, analysis, evaluation, inference,explanation and self-regulation.

• Deploy the Critical Framework to identify,question, and critically think of premises andassumptions in systems ontology – structuredand object-oriented analyses and design, andother approaches.

111

0

11

0111

0

0

11p

xxi

............................................................................................................................................Introduction

• Apply cognitive critical skills to develop,amend and revise continually a PCF.

• Deploy the Critical Framework to considercritically the application of methods, tech-niques, and tools in real situations anddevelop pragmatic resolution for practicalapplication problems.

These learning outcomes will lead to the devel-opment of a PCF underpinned by critical thinking and criticality of knowledge and prac-tice. They specify the prerequisite cognitiveskills required to develop critical thinking andseek to develop deeper and different kinds ofcriticality.

xxii

Introduction............................................................................................................................................

Part I provides the foundational development for a PCF perspective. It is the pedagogical basis for developing criticality. The contents of a PCF determine how it is used to anticipateaction, and how critical thinking is applied to studied and experiential knowledge. This is calledthe PAC cycle and it is elaborated in Chapters 1 and 2. The PAC cycle enables the structuringof critical thought.

Criticality is only possible if a suitable framework for analysis and evaluation is devised.Criticality requires a critical lens through which systems analysis and design can be examined.Chapter 2 sets out such a Critical Framework used throughout the textbook. In it systemsanalysis and design is interpreted as human action that can be improved through critical thought. The framework suggests cognitive processes for acquiring, understanding, and assim-ilating knowledge and its application. It is the requisite lens for developing critical thought andalso the basis for insights into how to develop and sustain a PCF for personal effectiveness.

The value of a PCF is its criticality. It is the critical consideration of systems analysis anddesign and subsequent inclusion in PCF that provides substance. Chapter 2 also explains whata PCF is, how to develop one, and why a PCF is necessary for improving understanding andpractice. The question of how to understand something, and assimilate it into a PCF, isaddressed in terms of personal cognition and personal constructs.

111

0

11

0111

0

0

11p

1

Part I

Foundations for critical learning and teaching

1.2 Introduction

Critical systems ontology is the interpretation,analysis, evaluation, inference, explanation,questioning and critical study of systems. It isthe notion that current ontological knowledgeof systems can be improved, and that it can be‘other than it is’ to be practically effective. It isenabled through a Personal Critical Frame-work, Action, and Criticality or the PAC cycle.The PAC cycle is proposed as a method for systems analysts to develop criticality andcritical thought. It is termed a ‘cycle’ becausecriticality is a continuous activity. Practitionersneed to develop the habit of reflecting on whatthey do, how they do it, and crucially, why they do it in order to improve practice. These are the preconditions for developing criticality,and require cognitive skills in interpretation, analysis, evaluation, inference, explanation and

self-regulation. Learners too need to developthese cognitive skills. They can benefit fromlearning to reflect on knowledge and developdeeper understanding of systems analysis, sys-tems design, its techniques, tools and methods.

The PAC cycle is illustrated in Figure 1.1.Readers are encouraged to develop a PCFmarked as (1) in the figure, enactment of thePCF (2), and reflect critically on the effect of theenactment on achieving desired aims (3). A PCFis a qualitative approach to knowledge forma-tion in which personal constructs areunique to an individual. The cycle is completedwhen criticality leads to the revision or amend-ment of personal constructs and the PCF.

An initial PCF can be formed either throughcritical study or reflective practice. It is com-posed of personal constructs on systems analysisand design and the relations between them that

111

0

11

0111

0

0

11p

3

Chapter 1

The PAC cycle

1.1 Learning outcomes

To engage in the PAC cycle, after completing this chapter you should be able to:

• Develop, revise and amend a PCF based on criticality.• Apply critical cognitive skills to a PCF.• Relate a PCF to personal action and effectiveness.• Interpret formal and practical knowledge in terms of transformatory critique,

refashioning of traditions, reflexive practice and critical skills.

a systems analyst deems relevant to anticipate real-

ity. It is this focus on anticipating reality thatmakes a PCF relevant for analysts because thedevelopment of an IS is such an anticipation ofreality. Systems analysis and design is practicaland the analysts’ actions shape actual IS. ThePCF is then enacted in actual IS developmentsituations. The analyst critically considers theeffects of the actions in the actual situation toenhance or revise the PCF. The process of form-ing personal constructs, using them to anticipateevents, and revising them is continuous.

The PAC cycle is a cognitive device to assessand improve personal effectiveness and success.Personal effectiveness is the basis for develop-ing professionalism. Assessing personal effec-tiveness itself requires an objectified process.Objectification is the basis for improving know-ledge and understanding practice. Objectifiedexperiential and learnt knowledge is an import-

ant part of the PAC cycle. It is necessary for thedevelopment of personal constructs and a PCF,reflection on ones actions to develop knowledgefurther, and the application of criticality to aPCF.

1.3 Personal Critical Framework

A PCF is a significant element of knowledgeand professional development. It brings train-ing and education in systems analysis anddesign together on the basis of the self and theself’s need for knowledge to anticipate experi-ence. A framework is: ‘typically a mixture ofpre-suppositions of correctness, of what is valu-able, and of validity. The framework is notpurely cognitive; it is not even mainly cognitive.It is invested with values, emotion, commit-ment, and professional and social identity’(Barnett, 1997).

4

Part I Foundations for critical learning and teaching............................................................................

Server Workstation

Data

Personal Critical Framework

Executive stakeholder Project manager

Systems analyst

Organizationand people

Actual start Actual finish

17/06/0318/05/03Requirements analysis

Company missionstatement

The real world ofhuman problems

FuzzyMessy

UnpredictableComplex

OrganizationPeople

Crit

ical

stu

dy

Ref

lexi

vep

ract

ice

The PAC cycle

Develop initial Personal Critical Framework through

Enactment ofpersonal framework

KNOWLEDGEACTION

CRITICALITY

Transformatory critiqueRefashioning of

traditionsReflexivity

Critical skills

Information SystemsInformation Technology

Thin

king

ski

lls,

cogn

itive

crit

ical

Personal constructs

(1)

(3)

(2)

PlansContingencies

PhenomenologyMeaning

SocialPolitical

Techniques and tools

ProblemProblem resolution

Figure 1.1 The PAC cycle

A PCF is an objectified tool for critical reflec-tion on the self, knowledge, and practice, andit is open to revision, amendment and update.While training in systems analysis and designleads to specific and prescribed behaviour, edu-cation results in an awareness of the processesthat lead to acquiring knowledge, and cognitiveand practical skills. Education engenderspersonal reflection on these processes.

The practice-orientation of systems analysisand design requires learners themselves to dis-cover ownership of knowledge. Generatingownership is the major aim of a PCF. As indi-viduals have selves, the self is central in thedevelopment of a PCF. It is vital for makinglearning and knowledge relevant and meaning-ful. Knowledge is gathered and interpreted bythe self. Learning that is divorced from the selfusually lacks relevance when action is required.

A PCF enables criticality in systems analysisand design. An analyst develops a PCF toimprove understanding of knowledge and prac-tice. Its purpose is to improve the self throughknowledge and individual action. Knowledgethat is devoid of the self creates a vacuity. Theself provides ownership and responsibility. In theabsence of the self, learnt or experiential know-ledge lacks meaning. Such insipid knowledgethen bares no relation to actual practice.

1.3.1 Objectifying a Personal CriticalFramework

Objectification results in reflection on howknowledge is acquired and used by the self inpractice. The process of objectifying knowledgeto develop a PCF requires making personalconstructs explicit on what constitutes know-ledge, how it is acquired, and how it is acceptedas valid. Cognitive skills are needed to objectifya PCF and for critically evaluating objectifiedknowledge. Interpretation, analysis, evaluation,inference, explanation and self-regulation pro-

pounded by the Delphi Report (Facione, 1990)serve as requisite cognitive skills to develop aPCF and engage in the PAC cycle.

Objectifying personal knowledge is initiallydifficult, especially for practitioners immersed inpractice. Difficulties in objectifying a PCF arisebecause of unfamiliarity with reflection. Theprocess of objectifying personal constructs andthe relationships between them includes action,reflection, writing, diagramming and discussion.An individual can begin to identify personalconstructs through these activities. Objectifica-tion may be individual and then discussed witha mentor or trusted colleague, or it may be donein a group. Objectified personal constructs andtheir relations can then form the foundation for a PCF.

Action Practice is the deployment of know-ledge to achieve specific goals. It results in expe-riential knowledge. Analysts gather and userelevant knowledge for practice. For example,an analyst acquires knowledge of techniques touse to determine system requirements for a newIS. Chosen techniques will be enacted toanalyse system requirements.

Reflection Reflection is the process of crit-ical thinking on practice to improve profession-alism, and the self. Analysts evaluate andcritically assess practice to determine its effec-tiveness. Practice is scrutinized to understandwhat was done, how it was done, and whetherit achieved predetermined objectives. Forexample, an analyst reflecting on the effective-ness of interviewing clients for functionalrequirements may assess how the interview was conducted and whether it was suitable forestablishing functional requirements.

Writing Making a record or writing is amethod for externalizing knowledge and experi-ence. It can be recorded as notes or critical eval-uations of practice. For instance, an analystreflecting on a project to develop a decisionsupport system can record personal activities in

111

0

11

0111

0

0

11p

5

......................................................................................................................Chapter 1 The PAC cycle

the project. The objectified writing can serve asa record for critical analysis of practice and itseffectiveness.

Diagramming Drawing diagrams is amethod for making a graphical representationof knowledge, concepts, techniques and activi-ties. A diagram provides an overall perspectiveon knowledge and action. The objectifieddiagram can be used to further reflect onpractice and how to make it more effective.

Discussion The reflection, written recordsand diagrams can be discussed with trusted col-leagues or teachers. They constitute objectifiedmaterial for further critical understanding ofpractice through other peoples’ perspectives.Other peoples’ perspectives help to criticallyassess, question and evaluate practice andknowledge.

1.3.2 Knowledge and practice elements

A PCF has knowledge and practice elements.Knowledge and practice is conceptually demar-cated in the PCF but in practice they can beaccumulated separately or jointly. A learnerwith no practical experience will initially accu-mulate only knowledge. A practitioner canaccumulate knowledge through practical ex-perience and contribute to the development ofpractice simultaneously.

The knowledge element is required to under-stand theory and relate it to practice. Theory isan account or explanation of observed phe-nomena. A theoretical explanation improvesunderstanding, provides explanatory knowledgeand informs practice. It consists of ideas thatexplain the nature of something, its causes thatmade it possible and how it functions.

It is difficult to find theory in systems analy-sis and design, but there are paradigms of think-ing and acting that seek to explain systemsanalysis and design, and how it should be performed. Such knowledge is accumulated

through formal learning or from practicalexperience. Such paradigms can contribute topersonal explanations of why and how thingswork. On a personal level a paradigm consistsof objectified ideas, concepts, techniques andmethods that form personal understanding ofsystems analysis and design. Theoretical andparadigmatic understanding can be used toenhance and improve personal constructs orredefine relations between elements in a PCF.

Praxis is the practical side of a discipline orprofession and it provides practical knowledge.Practice can be conducted in the absence of clear knowledge or understanding of thereasons for acting in a particular manner. It canbenefit from clear explanations for acting in aparticular manner. Reflexive praxis or reflexivepractice can lead to practical knowledge basedon critical thinking. Analysts who reflectcritically on practice and knowledge can reviseand amend personal constructs accordingly.Reflexive practice can be combined with theor-etical or paradigmatic explanations to developdeeper knowledge and understanding.

Professionalism, though, needs to combinethe knowledge and practice elements in a PCF.Objectifying knowledge and practice personalconstructs can improve understanding of prac-tice. Practice can be developed with clearexplanations for acting in a particular manner.Most practitioners are content doing their workand do not attempt to explain or understandwhat underpins practice. A practitioner mayfind that object modelling does not work wellbut be unable to explain why it does not workin practice. Reflexive practice can help toexplain the method’s shortcomings by under-standing systems ontology. An analyst maybe trained to elicit system requirements usingstructured techniques and may unquestioninglydeploy them. The analyst’s understanding ofthe effectiveness of the techniques wouldimprove with knowledge of assumptions made

6


about actual situations, explanation for con-ducting requirements in the first place, and whystructured techniques should be used.

Learners especially need to develop the prac-tice element of a PCF. They are best placed tobenefit from the knowledge element and use it toconsider how they might act in actual situations.They can be encouraged to develop practice per-sonal constructs through scenarios or cases to determine how they would act. A learner’s ini-tial PCF can be used as a guide to praxis when they begin practice, which should be revisedsubsequently on the basis of reflexive practice.

1.4 Personal effectiveness througha Personal Critical Framework

A PCF is useful for determining the success oreffectiveness of practice. The achievement of anobjective is a practical measure of success. APCF can be used to improve personal effec-tiveness and to determine, through criticalreflection, which personal constructs and rela-tions lead to effective practice. It enables prac-titioners to know how to do things better andlearners to understand the reasons for particularaction. It can be used to:

• decide how to act in actual situations;• determine knowledge and critical areas for

its improvement;• explore strengths, develop them further, and

exploit them;• identify weaknesses and take action to

improve them.

An objectified PCF can improve the effective-ness of practice. It can be used to determine theefficacy of one’s action. It can be the basis forcritically reflecting on and understanding one’saction, resulting in some personal constructsbeing revised, others replaced, or new onesintroduced.

1.4.1 Reinforcing and stopping action

A PCF can be used to explain why certainactions should be repeated and why othersshould be stopped. Action that leads to successcan obviously be repeated. An explanation ofwhy it is successful can be deduced from a PCF.The explanation will enhance knowledge ofpractice and deepen understanding. For exam-ple, when a method or technique works well inpractice it is beneficial to know and understandwhy and how it works. Developing an under-standing of how it works in theory can providedeeper knowledge of its value in practice.

Practice that results in lack of desired levelsof success or even failure needs to be stopped.The problems with personal constructs can beidentified and amended or entire personal con-structs replaced. Simply stopping the action willnot improve knowledge or practice. It is vital forprofessional development to know why certainactions should not be repeated. Stopping actionwithout understanding the reasons for failuremay lead to future similar failures.

Explaining practice is important for develop-ing a PCF that contains relevant personal con-structs. Actual practice consists of implicit orexplicit rules, procedures and assumptions ofwhich a practitioner may not be cognizant.Explaining successful practice will objectify themand develop knowledge that will contribute tobetter understanding of practice.

Practice of systems analysis and design is animportant source for developing criticality.Reflecting on learnt knowledge and practice isimportant, but reflecting critically adds value.The relation between a PCF and practice isprocessual and interpretive rather than staticand prescriptive. An analyst constructs a PCFprocessually, as they engage in actual situations.Taking action on the basis of a PCF will eitherlead to success or not. Successful action shouldreinforce a PCF and unsuccessful action shouldlead to revisions.

111

0

11

0111

0

0

11p

7


1.4.2 Understanding human action

Analysts’ action underpin PCF development.Objectification of personal constructs related tohuman action in a PCF, and its use to reflecton action, can improve effectiveness. The utilityof knowledge for particular action determinesthe level of success achievable. Effective actionis determined by knowledge of how to act. Tounderstand human action and its effectiveness,researchers and practitioners probe questionsconcerning the combination of knowledge andpractice that leads to effective action and howeffectiveness can be improved.

There are two significant strands of researchthat develop knowledge of human action:planned action and situated action.Planned action is based on human rationalityand its capability for achieving desired objec-tives. It is closely linked to developments in sci-entific knowledge and the scientific method. Aplan epitomizes human action as rational action(Simon, 1957). A plan is an instrument forachieving desired aims and it explicates activi-ties, rules and procedures to achieve objectives.It assumes that it is possible to control events inactual situations.

Planned action is crystallized as ‘methodol-ogy’ in IS development. An IS developmentmethodology is a detailed plan of how todevelop IS. It prescribes systems analysis anddesign activities for analysts, project managers,and software programmers. Systems projectmanagement too epitomizes the planned man-agement of IS development. Systems analysisand design methods and techniques are simi-larly based on planned action. A plan prescribesactions but is incapable of dealing with anom-alies not accounted for in the plan in the realsituation. Individuals and groups need torespond to the situations they encounter notaccounted for in plans. It is proposed here thatthey do so as situated action in context.

Situated action is human intention andaction informed by context and utilizes embod-ied skills (Suchman, 1994). It is characterized as the setting of objectives and seeking toachieve them. The process of achieving objec-tives and the actions taken, depend on and aredetermined by the context and situationalfactors.

Situated action has had no influence onsystems analysis and design, but analysts needto be aware of it when objectifying personalconstructs. Situated action raises questions con-cerning structured and object-oriented systemsontology. If the ontological assumptions under-pinning situated action are valid, then actionthat is informed by context and utilizes embod-ied skills, logically cannot be extracted from itscontext, as required in structured and object-oriented systems ontology. Systems ontologyneeds to account for such action. Analysts needto be aware of situated action when developingpersonal constructs, and when resolving systemsmodelling problems pragmatically. Recentdevelopments in Agile Software Development(ASD) seem to be taking account of situatedaction.

1.5 Components of PersonalCritical Frameworks

A PCF should include the knowledge and prac-tice elements detailed above, and the five essen-tial components explained in this section. Theyare required to ensure that a PCF reflects the knowledge and practice elements. The fivecomponents are: ethics, assumptions of reality,personal constructs, instruments, and relationsbetween components. Other components spe-cific to individuals or organizations may alsobe included. For example, an analyst workingfor a charitable organization may want toinclude morality as a component, or one

8


working for the government may want toinclude public service as a component.

1.5.1 Ethics

Ethics is the values component of a PCF.Ethical practice is concerned with makingjudgements concerning right and wrong behav-iour. The purpose of professionalism is toachieve formal objectives, but professionalismthat is void of ethical practice often leads toundesirable, illegal, and even immoral practice.Professional bodies in computing and ISprovide an ethical code for their members.

IS change the way people work and affectpeoples’ working lives. Analysts’ systems designdecisions bind people into working in certainways, for instance they determine whetherpeople have rewarding working relations. Suchdesign decisions are particularly sensitive inorganizations that deal with human healthcare.Researchers have considered the effect of ana-lysts’ design decisions on people. The Ethicaland Technical Implementation of ComputerSystems (ETHICS) methodology was devel-oped to encourage ethical behaviour. TheBritish Computing Society have specialist inter-est groups on ethics. Its Ethics Expert Panel: ‘isresponsible for providing advice and guidanceon ethical issues associated with the develop-ment, operation and use of computerisedInformation Systems (IS).’

The Panel is linked to the InternationalFederation of Information Processing (IFIP)interest group on ethics. IFIP ensures thatclients are assured of the professional standardof work of IS professionals. It seeks to providea code of ethics that: ‘acknowledges the profes-sional responsibilities of practitioners to societyat large, members of the public, employers,contracting parties and fellow practitioners’.

Analysts need to ethicize personal action andobjectify a personal code of ethical behaviour.

Analysts’ systems design decisions will affect theaims of the organization and the peopleworking in it. Potentially compromised designdecisions need to be ethically resolved. Theyhave conflicting demands on them that need tobe resolved ethically. These include:

• The tension between thinking in technicalterms to comply with the constraints of ITand the needs of the organization and people.

• Potential conflict of interests of paymasterswith personal ethics.

• Client contact that may compromise per-sonal ethics and professionalism.

• Behaving as qualified experts who haveknowledge of designing IS.

1.5.2 Assumptions of reality

Analysts’ assumptions of actual situations theywork in constitute the ontological component ofa PCF. Ontology is knowledge of the nature of a thing, for example organization, people, ISand IT. Such knowledge is based on assump-tions, which will be reflected in analysts’ per-sonal constructs of these things, and underpinpersonal practice. As a PCF consists of personalconstructs of reality, practitioners and learnersneed to objectify personal assumptions of reality– which include ideas, notions, concepts andexpected behaviours – and relate them topersonal constructs.

Analysts make assumptions about organiza-tion and people and combine them with actualknowledge to enable practice. As it is not possi-ble for analysts to know the nature of somethingin its totality, any action will be underpinned by assumptions and the expected effect of theaction. Objectifying and understanding theseassumptions and expectations results in betterknowledge and effective practice. Ironically,assumptions that underpin practice form thepractical basis of a PCF.

111

0

11

0111

0

0

11p

9


Objectivism

There are two distinct and mutually exclusivefundamental assumptions an analyst can make.One, that a thing is a fact independent of theanalyst’s experience and that it exists separatelyof him- or herself. This is called objectivism.Such an analyst would be called an objectivist.Objectivists make the assumption that realitycan be known and that methods for studyingreality result in objective knowledge, or know-ledge that is independent of human bias. Theprocess of acquiring objective knowledge is the scientific method used by natural scien-tists. Objectivists in social science are called positivists.

Objectivist analysts assume that system ‘facts’can be established and that factual knowledgecan be used to design systems and ‘control’events. They assume that systems analysis anddesign can result in an objective and factualunderstanding of current IS and the objectivedesign of new IS. Structured and object-orientedsystems ontology assumes this kind of objectivistview of people, organization, IS and IT.

Subjectivism

The other assumption is that a thing is insepa-rable from the analyst’s experience. Such an analyst would be called a subjectivist. Sub-jectivists in social science are called interpretivists.Interpretivists assume that knowledge is sociallyconstructed. They make the assumption thatpeople socially construct reality, and thatmethods for studying reality should lead toknowledge that includes an account of peoples’experience of reality.

An analyst’s decision on one of these assump-tions about reality has implications for the kindsof personal constructs of knowledge and practicedeveloped. An analyst who assumes there are‘facts out there’ has to develop practice that isdetached and objective. The analyst will be

detached from the organization and peoplewanting a system, and make design decisionsobjectively. Such an analyst cannot becomeinvolved in the internal politics of the organiza-tion or be biased towards particular stakehold-ers. In contrast, an analyst who assumes realityto be subjective has to behave as an involvedmember of an organization. The analyst willinfluence the politics of a new IS development,and possibly be biased towards particular stake-holders, or even pursue personal goals.

Researchers are divided into those whobelieve IS to be objective and those who believeit to be subjective. Objectivists dominate insystems analysis and design, in particular prac-titioners. Much of the critique on IS develop-ment practice stems from the premise of objectivity. For example, Multiview is a frame-work rather than a methodology, but it acknow-ledges subjectivism by including Soft SystemsMethodology (SSM) analysis techniques.

1.5.3 Personal constructs

The individual basis for a PCF is PersonalConstruct Theory, in which a construct is a wayof perceiving, construing, or interpreting events(Kelly, 2000a). Individuals seek to anticipateexperience or events, and significantly have the‘freedom to choose’ what meaning they attachto their experiences. To do so, they develop acoherent set of personal constructs that are usedto interpret and explain events. The theory isbased on the principle of ‘constructive alterna-tivism’, the view that reality does not directlyreveal itself to individuals and that each indi-vidual construes reality as personal inventions.So, individual analysts will construct images oforganization, people, IS, and IT that differ fromother analysts’ constructions. A personal con-struct system is a set of personal constructs andthe relations between them that provides theunity in the experience of individuals.

10


Personal constructs are necessary becausereality cannot be directly known. Individualsexperience reality and then develop construc-tions to help them anticipate it. This view is notthe same as the subjectivists’ view of reality, aspersonal constructs are open to measurementswhereas interpretive knowledge is not. Personalconstructs can be elicited and relations betweenthem assessed using the repertory gridtechnique. Personal constructs are:

• Created as interpretations of personalexperience and then used as a model ofreality.

• Used to understand personal and otherpeoples’ action (understand or make sense ofreality).

• Used to repeat, anticipate or predict futurepersonal experience.

• A personal method of acquiring knowledgeof reality (a personal epistemology).

• Used to assess the effectiveness of personalaction (based on trial and error).

Examples of personal construct types are:social, institutional, knowledge and belief con-structs. Knowledge and belief constructs areespecially important, because analysts’ ownunderstanding of what they regard as knowledgeand how it is applied to practical problems arecentral. By surfacing personal constructs ana-lysts’ can begin to see themselves in the processof knowledge formation, questioning, learning,and critical thinking.

Personal constructs in turn determine action.Personal constructs are subject to revision andpersonal construct systems change over time. Soanalysts’ experience can be construed differ-ently. Examples of personal constructs are‘structure’ from structured systems ontology and ‘class’ or ‘object’ from object-orientation.Another is the notion that system requirementscan be elicited from clients or that IS can be

modelled. A recent example is ‘agile’ from agileprogramming. Analysts trained in structuredmethods create personal constructs that supportthe ‘structured’ perspective. They may learnobject-oriented analysis in time and so will needto revise their personal constructs to support the‘object’ perspective.

Personal constructs underpin PCF becausethey enable an analyst to elicit a personal con-struction system or identity (self-character-ization). Analysts should objectify personal constructs or a personal construct system todevelop a PCF. Personal constructs create pro-fessional and personal identity. Objectifiedpersonal constructs help analysts to understandknowledge and how it underpins personalaction. Analysts experience formal education,training and practice, which is the source forconstruing personal constructs on systemsanalysis and design, data, information, know-ledge, organization, people, IS and IT.Experience from these sources leads to personalconstructs designed to anticipate further experi-ence – practice.

The objectification of personal constructswill enable practitioners, learners, and theteacher, to relate them to systems analysis and design. It leads to deeper knowledge andunderstanding of human action and reality.Importantly, the objectification process is a wayof enabling learners to take ownership of learn-ing and development of a PCF based on know-ledge through experience (including practicalknowledge) and knowledge acquired throughthe intellect. The result is the development of a personal critical systems ontologythrough increased complexity and definition ofconstruction systems.

1.5.4 Instruments

Analysts need to objectify the knowledge under-pinning the instruments of choice to accomplish

111

0

11

0111

0

0

11p

11


objectives in practice. Instruments determinewhether the practice is successful or not. Themethods, techniques and tools of systems analy-sis and design form the technical or instrumentalcomponent of a PCF. Authors differentiate theterms ‘method’, ‘technique’ and ‘tool’ variously.They are collectively termed ‘instruments’ here.An instrument is an agency in the achievementof an objective. It embodies the individual’s,community of practice, and society’s knowledgeregarding particular problems and how thoseproblems can be resolved. Structured andobject-oriented analyses consist of such instru-ments to address the problem of developing IS.

Analysts need to explain why certain instru-ments are preferred and how the choseninstruments address the problem. Assumptionsunderpinning instruments need to be uncoveredand justified in terms of the problem. Experi-enced analysts will draw on practical knowledgeto explain choices. Learners or novices will base explanations on learnt knowledge. Suchexplanations will enable informed evaluation of personal effectiveness in practice and clarifyassumptions made about particular instrumentsto assess the relevance of those assumptions.

Objectification will further knowledge ofhow to improve the instruments, their use andselection. Instrument design and choices aredetermined fundamentally by assumptionsanalysts make. If an analyst assumes thatorganization and people exist as independentreality then structured systems analysis anddesign methods, techniques, and tools will bechosen. If it is assumed that reality is sociallyconstructed, and that the analyst is part of it,then other suitable techniques will be required.

1.5.5 Relations between components

A PCF is only effective when relations betweenits components are defined. Analysts need toobjectify the relations between PCF compo-

nents to define how personal constructs areapplied in practice or how they are used toanticipate experience – deliver required IS.Relations between components integrate theminto a practical PCF for developing knowledgeand practice. Relationships between compo-nents, and how components are affected byother components, need to be explained andjustified to ensure the effectiveness of a PCF andsubsequent practice based on it.

Objectification may be difficult because theactual relations may not be apparent. Oftenpraxis consists of assumed relations that arehidden and enacted automatically in actual sit-uations. Practitioners interested in deliveringresults do not reflect on what they do and howthey behave in actual situations. Objectifyingthe validity of particular practice, for exampleconsulting people whose jobs may be threat-ened by a new IS, is difficult for practitionersbecause such acts are secondary to the actualtask of developing an IS.

The integrative basis of a PCF is clear defi-nitions of relations between components.Relational definitions are essential to improveunderstanding and the further development ofpersonal constructs in a PCF. They enablefurther critical thought on whether the relationsare appropriate in terms of ethics or assump-tions of reality. For example, an analyst needsto define how personal ethical code relates toorganization and people, to personal constructs,or to instruments. The analyst may consider itunethical to impose on clients a way of work-ing required in a new IS. The system design would then need to be discussed with clients todetermine their preferences.

1.6 Logical and reasonable personalframeworks

The validity of a PCF depends on its content.It needs to be appropriate for making sense

12


of systems analysis and design and practising it. Appropriate content can be assured bychecking personal constructs for logicality andreasonableness. Personal constructs need to be reasonable and corroborated by evidence.An analyst cannot expect to determine what a new IS is required to do through observa-tion alone for example. It is unreasonable to expect observation alone to provide anunambiguous and complete set of system requirements.

1.6.1 Evidence-based reasoning andaction

Reasoning requires thinking rationally and log-ically about a problem, and involves rationalargument and deductive or inductive logic. Italone is not sufficient to develop a practicalPCF, evidence is necessary. Evidence-basedreasoning results in a valid and practical PCF.Evidence is the experiences that analystsacquire from learnt knowledge and practice.Learners or novices should draw on learntknowledge as authority or evidence. Such evi-dence can be objectified in personal constructsand critically appraised for both.

Evidence-based reasoning leads to evidence-based practice. Evidence-based reasoning ispossible whether analysts decide on objectivistor subjectivist systems ontology. Both rely onthe experiences of the individual to developknowledge of reality. The reason for includingcertain instruments or particular ethics shouldbe traceable to evidence in practice or a bodyof knowledge for validity. Personal constructsderive their validity from the experiences ofindividuals, and how these experiences are con-strued to anticipate further experiences.Developing a PCF on the basis of evidence-based reasoning ensures that further practice isitself based on evidence.

1.6.2 Think and act or act and think?

Action to resolve organizational problems canbe interpreted in two ways. One, think ratio-nally first about a problem to decide how to actand then follow it through into action, coinedhere as ‘think and act’. A plan is a goodexample of this kind of action. It draws on ratio-nal thinking to detail prescribed action. TheSDLC and structured systems analysis anddesign are examples. An IS methodology is aparticular example of such a plan. The use ofsystems analysis and design instruments alsorequires first thinking through what to do andthen implementing them.

The other interpretation is to engage withthe problem first and then think during its res-olution, and afterwards, about how it wassolved, coined here as ‘act and think’. Theaction and thinking of the action can be simul-taneous. Many inventors state that they solveproblems by engaging with them and thinkthrough the difficulties as they arise. Analyststoo recognize that IS problems are resolved iter-atively. ASD is an emerging pertinent exampleof the act and think strategy.

The think and act strategy is dominant in IS development. In actual practice system project plans are developed or a methodologyespoused, but implementing them proves prob-lematical in actual situations. The result is prac-titioners continually adjusting plans to reflectactuality. The act and think strategy has theadvantage of making sense of the real situationin actual time and basing decisions on how toact on such an understanding. It is less likely tobe used in practice, especially in a businesscontext, because it does not afford knowledgeof what needs to be done and how it should bedone.

Analysts need to reflect on how they resolveproblems. The choice of the think and act or actand think strategy for resolving problems should

111

0

11

0111

0

0

11p

13


be based on evidence. It will determine personalconstructs associated with problem resolutionand determine what other personal constructsare used and how they are related in a PCF.Models for resolving difficult, complex, real-lifeproblems exist to help individuals to move fromthe individual level to the organizational level.Action Science for example is the study of suchcomplex problem-solving in organizations.

1.7 Example Personal CriticalFrameworks

Analysts should endeavour to begin building aPCF. Three are illustrated in this section. Theillustrations serve to show how components ina PCF might be composed and related. Theyshould not form the basis for composing yourPCF. They are not meant to be actual exem-plars. In actuality, a practitioner’s PCF willconsist of experiential and studied knowledgeand will probably include a richer and widervariety of experiential personal constructs. Alearner or novice analyst’s PCF will contain for-mally learnt personal constructs, whetherthrough training or educational programmes.

The form of a PCF can be text, tables, dia-grams or a combination. The author’s PCF forteaching practice is a combination of a diagramand related text to describe and explain theprocess of learning and teaching (Patel, 2003).Its five main personal constructs are: learningand teaching instruments, discipline knowledge,personal and professional development, the self,and knowledge. The learning and teaching con-struct concurs with professional teachingbodies. The constructs were objectified as partof reflective and critical practice spanning tenyears. The relations between these personalconstructs are explained in text form. Theauthor makes use of this PCF to inform prac-tice and to improve it on the basis of evidencefrom learners of its effectiveness. It is continu-

ously checked in practice with learners to assessits efficacy, and new ways of teaching devisedto develop each of the elements in learners.

Three ideal-type PCF are illustrated intabular form for brevity. The illustrations are in‘pure’ form, meaning that actual PCF will havemany ‘grey’ areas where practice and know-ledge cannot be neatly compartmentalized asobjectivist or subjectivist. One ideal-type isbased on an objectivist view of reality, thesecond is based on a subjectivist view, and thethird is simply a personal framework, it is basedon an imagined analyst who is unaware ofobjectivism or subjectivism. The PCF is pre-sented in the first person to make the process ofobjectification easier.

1.7.1 Objectivist Personal CriticalFramework

For an analyst who regards reality as objectiveentities, a PCF may be objectified as Table 1.1.It consists of the five components of a PCF anda textual description of each component.

The description column in Table 1.1 con-tains the relation sub-element in each compo-nent to describe how components relate to eachother. The overall relation component is stillrequired to provide a rationale for the wholePCF. The descriptions are minimal and therelations need further elaboration. The PCFreflects practical and theoretical knowledge ofsystems analysis and design based on objectivesystems ontology.

1.7.2 Subjectivist Personal CriticalFramework

For an analyst who regards reality as subjectiveentities, a PCF may be objectified as Table 1.2.It consists of the five components and a textualdescription of each component. The analyst will

14


regard organization and people as meaningsand IS and IT as interpretations that aresocially constructed, and the analyst personallyas involved in that social construction.

Table 1.2 contains brief descriptions. ThePCF reflects practical and theoretical know-ledge of an interpreted reality. The PCF reflectspractical and theoretical knowledge of systems

analysis and design based on subjective systemsontology.

1.7.3 A Personal Critical Framework

For an analyst with no awareness of objectivismor subjectivism, a PCF may be objectified asTable 1.3. It contains the five components of a

111

0

11

0111

0

0

11p

15


Table 1.1 An objectivist Personal Critical Framework

PCF component Description

Ethics As I am detached from the organization and people for whom I develop IS, I amnot concerned with judgements about what is appropriate or inappropriate action. Ileave ethical decisions to managers who tell me what to do.

Relations: As I am detached, my personal ethics does not affect the way I interactwith people. I am a professional. Ethics is based on how I personally see reality.

Assumptions I can give an accurate account of organizations, people, IS amd IT andof reality record this knowledge as facts. Reality can be decomposed to determine elemental

facts, which I can use to decide what action I should take. I am detached from theorganization and people, which exist separately from me. Knowledge is objective.

Relations: Instruments can be designed to extract objective system requirements. Iam a detached professional. An IS is objective.

Personal I can identify and objectify these personal constructs: professionalism; constructs problem-solving; Information System; Information Technology; organization;

workers; organizational work; organizational politics; rationalism; perfectknowledge.

I am detached from the problems I solve and I am a rational person, capable ofsolving organizational and IS problems rationally. I am not affected byorganizational politics. System requirements can be known and elicited, people inthe organization should be able to tell me what they require the system to do. I ama professional person with expertise and I know what systems can do better thanworkers.

Relations: My personal constructs are based on how I see reality. I can applyinstruments to organizations to achieve goals. I can use them to extract systemrequirements and design systems.

Instruments I can use my objective knowledge of reality to design and use instruments to solveorganizational, informational and knowledge problems. Structured systems analysistechniques can be used to elicit, analyse and model systems.

Relations: The design and use of my instruments is based on my detached andobjective perception of reality.

Relations My view of reality enables me to remain detached. My ethics is detached from between the problem domain – organization and people. My view of organizations components is that they can be ‘engineered’ using instruments designed on the basis of an

objective knowledge of organizations and people. I am capable of objectivelydeploying instruments. My personal constructs reflect objective reality.

PCF and a textual description of each compo-nent. The analyst’s view of reality will probablybe based on personal experience and knowledgegleaned from it.

The PCF reflects mostly practical know-ledge. There is a paucity of theoretical or con-ceptual knowledge. The ‘family’ personalconstruct appears in Table 1.3. Given the holis-tic approach of PCFs this is normal.

1.7.4 Your personal framework

The reader should develop progressively a PCFby completing the PCF development section ineach chapter. Your PCF should be continuouslyrevised as you learn and begin to objectify per-sonal constructs. The sources for your personalconstructs will be knowledge or experience fromtraining, formal education and practice.

16


Table 1.2 A subjectivist Personal Critical Framework


Ethics As I am part of the organization, I should behave ethically. I am attached to theorganization and am concerned about what is good and bad behaviour. I wantto design IS in agreement with people. I am sensitive to design decisions thatlead to job loss or reducing skills.

Relations: My ethical code is related to my personal constructs aboutorganization and people, and other personal constructs.

Assumptions of I alone am unable to account for reality as it is socially constructed. Reality reality is holistic and cannot be compartmentalized or decomposed. I am part of the

organization and one of the people in it. I help to create the meaningsunderpinning the organization. I can help people to identify their informationand knowledge problems and facilitate them to determine what they need froman IS.

Relations: Instruments can be designed to elicit agreed requirements. Mypersonal constructs are affected by my experiences.

Personal constructs I can identify and objectify these personal constructs: professionalism; problem-solving; Information System; Information Technology; organization; workers;organizational work; organizational politics; personal involvement andattachment; meaning; interpretation; imperfect knowledge; limitations; socialchange; collaboration.

I have limited rationality and knowledge, as do other people in the organization.People cannot know exactly what they require a system to do. Requirements aresocially constructed and I, as a professional, act as a facilitator.

Relations: My personal constructs are based on my view of reality. I caninteract with people to understand what they want through instruments.

Instruments I can design methods, techniques and tools to help people design appropriate IS.The instruments should be accessible to people and they should be involved inusing them to design IS.

Relations: The instruments I use are based on my view of reality. I apply themin agreement with people.

Relations between I am part of reality or organization and people. My ethics shape my components personal constructs and determine the use of instruments.

A PCF is to be revised. It should grow inknowledge and understanding. You shouldrevise and amend your personal constructs bycritically evaluating your knowledge. As youapply your PCF or reflect on it you will developbetter understanding of how your knowledgeand practice are related, and amend your PCFaccordingly.

You should use your PCF to reflect deeplyon the efficacy of personal action and its effec-tiveness. As an example, an analyst who hasestablished a set of requirements from clients fora new IS may find that the interviewing tech-niques used failed to capture some functionalrequirements that only arise in the context ofclients’ work. The analyst should question theefficacy of the interviewing technique for con-

textual requirements capture, and think of alter-native ways of capturing such requirements.You should base your reflection of knowledgeand practice on criticality.

1.8 Criticality

Criticality is concerned with making judge-ments on the basis of critical thought. In prag-matic terms, criticality requires questioning andassessing or interpreting a current situation andreflecting on how it could be better. It resultsin doing something differently. It is not suffi-cient for practitioners to simply reflect on whatthey do, how they do it, and on the results oftheir actions. Reflective thinking supposes crit-icality. Reflective and critical analysts make

111

0

11

0111

0

0

11p

17


Table 1.3 A praxis Personal Critical Framework


Ethics I simply do my job. The organization is too big for me to do any harm to it. Iwill stay out of harm’s way. I can give value to the business by doing good work.

Relations: My personal constructs inform my ethics and I can only do the workthat my instruments allow.

Assumptions of I believe I can create IS to help people do their work and business to be reality effective. As I am unable to understand the whole organization, I only focus on

a particular problem. I work in a team but the team seems disjointed, and I amonly responsible for what I do. I believe the idea of teams does not work for me.

Relations: The instruments I use enable me to do my work. My personalexperience helps me to understand what I can do.

Personal I can identify and objectify these personal constructs: professionalism; constructs value-added; problem-solving; Information System; Information Technology;

organization; workers; organizational work; organizational politics; personalinvolvement and attachment; knowledge; limitations; family.

Relations: I can use my technical skills to give value to the business. I useinstruments as intended.

Instruments I use instruments to help me solve problems with which I am concerned. Theysuffice, they could be improved but I don’t know how.

Relations: The instruments are sufficient for me to do my work. They need toreflect the constraints of the work I do.

Relations between I am one person in the organization. I cannot know everything that happens.components Others provide the instruments I use. My personal constructs are light, I am

only concerned with doing my job.

judgements on what constitutes appropriateknowledge and practice to achieve objectives.Such reflection requires criticality to make adifference to practice and the accumulation ofrelevant knowledge.

Systems analysts should reflect deeply onknowledge and practice and analytically evalu-ate the efficacy of concepts and instruments.Such evaluation should lead to improvementsin knowledge and practice. Criticality can bedeveloped from formal learning or throughreflexive practice.

A PCF should be based on being critical. Beingcritical of personal knowledge and actions shouldprovide relevance to objectified components of a PCF. The objectified components should besubjected to further critical thinking.

1.8.1 Critical thinking

Critical thinking is essentially a cognitive actthat benefits individuals and organizations.Understanding and developing critical thinkingrequires personal effort aided by formal educa-tion. The Delphi Report provides a list of cog-nitive skills and sub-skills needed to developcritical thinking (Facione, 1990). PCF develop-ment requires these cognitive skills elaboratedin Table 1.4. They will enable analysts to reflectcritically on knowledge and practice.

Critical cognitive skills are required to ini-tially compose, and enable continuous revisionof, a PCF. To compose a PCF initial reflec-tive thinking is required to determine rele-vant assumptions about reality, ethical issues,

18


Table 1.4 Critical thinking skills

Cognitive skill Description

Interpretation To comprehend and express the meaning or significance of a wide variety ofexperiences, situations, data, events, judgements, conventions, beliefs, rules,procedures or criteria.

Analysis To identify the intended and actual inferential relationships among statements,questions, concepts, descriptions or other forms of representation intended toexpress belief, judgements, experiences, reasons, information or opinions.

Evaluation To assess the credibility of statements or other representations which are accountsor descriptions of a person’s perception, experience, situation, judgement, belief oropinion; and to assess the logical strength of the actual or intend inferentialrelationships among statements, descriptions, questions or other forms ofrepresentations.

Inference To identify and secure elements needed to draw reasonable conclusions; to formconjectures and hypotheses; to consider relevant information and to educe theconsequences flowing from data, statements, principles, evidence, judgements,beliefs, opinions, concepts, descriptions, questions or other forms of representation.

Explanation To state the results of one’s reasoning; to justify that reasoning in terms of theevidential, conceptual, methodological, criteriological and contextual considerationsupon which one’s results were based; and to present one’s reasoning in the form ofcogent arguments.

Self-regulation Self-consciously to monitor one’s cognitive activities, the elements used in thoseactivities, and the results educed, particularly by applying skills in analysis andevaluation to one’s own inferential judgements with a view toward questioning,confirming, validating or correcting either one’s reasoning or one’s results.

instruments for practice, personal constructsand relationships between constructs. Once aPCF is composed, it needs to be continuouslyrevised to reflect advances in knowledge insystems analysis, development of new tech-niques, and experiences from practice. Suchrevisions require critical thinking to justify newpersonal constructs or to justify retention oramendment of existing ones.

The Delphi Report defines a critical thinker:

To the experts, a good critical thinker, the paradigmcase, is habitually disposed to engage in, and toencourage others to engage in, critical judgement.She is able to make such judgements in a wide rangeof contexts and for a wide variety of purposes.Although perhaps not always uppermost in mind, therational justification for cultivating those affective dis-positions which characterise the paradigm criticalthinker are soundly grounded in CT’s personal andcivic value. CT is known to contribute to the fair-minded analysis and resolution of questions. CT is apowerful tool in the search for knowledge. CT canhelp people overcome the blind, sophistic, or irra-tional defence of intellectually defective or biasedopinions. CT promotes rational autonomy, intellec-tual freedom and the objective, reasoned and evi-dence based investigation of a very wide range ofpersonal and social issues and concerns.

( p. 13)

Self-regulation is crucial for developing andcontinuously revising a PCF. The DelphiReport states two associated sub-skills: self-examination and self-correction (Facione,1990). Self-examination entails activities likereflecting on ‘one’s own reasoning’ or ‘motiva-tions, values, attitudes and interests’, being‘objective’, judge ‘deficiencies in one’s know-ledge’, being ‘unbiased and fair-minded’, and‘respectful of the truth’.

Barnett (1997) defines criticality as: ‘a humandisposition of engagement where it is recognised

that the object of attention could be other thanit is.’ There are three forms of criticality in rela-tion to its three domains of expression: ‘critical

reason, critical self-reflection, and critical action’ (p. 179 italics in the original). He provides waysof being critical in the form of a schema for crit-ical being and identifies four levels of criticality:

Transformatory critique At the know-ledge dimension, in transformatory critiqueknowledge itself is reframed. For example,practitioners in the field collectively developedand accepted knowledge of structured systemsanalysis that departed from traditional systemsanalysis. Recently, there has been collectivereconstruction of knowledge as object-orientedsystems analysis and design, as deficiencies inknowledge of the structured approach areidentified.

Refashioning of traditions In refashion-ing of traditions critical thought is applied to‘malleable traditions of thought’. For example,practitioners and professional bodies in the fielddeveloped mutual understanding of the roles ofdevelopers as central in IS development.Gradually the role of ‘users’ as participants inIS development was recognized. Transforma-tory critique and refashioning of traditions maybe considered as higher levels of criticalityrequiring intellectual insights aimed at redefin-ing accepted knowledge.

Reflexivity Reflexivity is critical thinkingbased on one’s experience and understandingof situations. It is reflective practice. Forexample, experience of structured systems mod-elling may reveal weaknesses in separating dataand process models. The analyst may adaptpractice by using object-oriented systems mod-elling to create integrated or encapsulated dataand process models. Here criticality results inadaptations to and flexibility in practice.

Critical skills Critical skill is the fourthform where ‘discipline-specific critical skills’ are

111

0

11

0111

0

0

11p

19


developed. For example, analysts need todevelop systemic problem-solving or modellingskills. The development of discipline-specificcritical skills is termed ‘means-end instrumen-talism’. Reflexivity and critical skills areregarded as personal-oriented criticality. This istermed ‘critical reason’.

The four levels of criticality are applied tothree dimensions: knowledge, the self and theworld. The need for criticality arises fromdoubting the effectiveness of certain systemsanalysis and design concepts, instruments, orfrom reflecting on ineffective practice. It mayarise from making an assessment of personalpractice that leads to critical observations ofapplied knowledge or professionalism. Thereare various ways of being critical of praxis.Question the efficacy of certain instruments ordoubt the usefulness of a particular approach tosystems analysis. Trying different approachesand instruments leads to critical observa-tions about their effectiveness. While theseforms of criticality are important for the development of a PCF, Barnett’s three forms of criticality provide the foundations for itsdevelopment. Critical reason, critical action,and critical self-reflection are necessary todevelop a PCF.

1.9 A critical learning journey

The analogy of a journey is used in learning toindicate what knowledge the learner willacquire. Learning can be likened to a journeythat has a starting point and an end point. Thelearner begins with a starting state of mind andthrough the study of the discipline gains andappreciates knowledge that will create a differ-ent state of mind. In this textbook the learner’sstarting state of mind is the desire to acquireknowledge of systems analysis and design thatleads to personal effectiveness. The end point isthe development of criticality and critical think-ing cognitive skills and their application to

knowledge and practice to develop a PCF forpersonal effectiveness.

The journey’s fundamental milestone will betransformatory critique in the self-dimensionthat leads to the ‘reconstruction of self’. Thetask of the actual reconstruction of the self is leftto learners and practitioners as they develop aPCF to objectify personal knowledge and toreconstruct it on the basis of criticality. Analystscan reconstruct the self by understanding therole of the self in learning, objectifying personalknowledge and reflecting on practice.

The journey’s practical prominent milestonewill be transformatory critique in the world-dimension that leads to ‘critique in action’ or‘collective reconstruction’. Chapter 2 is a frame-work for critically appraising systemic know-ledge and practice. Analysts can draw on it to develop the components of a PCF. The col-lective reconstruction of knowledge is exempli-fied in Part V in terms of critique of systemsanalysis and design. This critique will enableanalysts to understand deeply assumptions ofreality and personal constructs. An alternativeterm paradigm shift for transformatory critiquein Chapter 14 is illustrated in terms of IS devel-opment knowledge. A cursory example oftransformatory critique here is the creation of knowledge in ‘agile’ IS development andassociated agile systems analysis techniques.

During the journey, analysts will tread trad-itions to draw on refashioning of traditions inthe self-dimension to develop the self within traditions, as covered in Parts II, III and IV.This coverage will include reflexivity in the self-dimension that leads to ‘reflection on one’s ownprojects’. It will also include critical skills in theself-dimension that leads to ‘self-monitoring togiven standards’, termed ‘critical self-reflection’.This coverage will enable analysts to developtheir assumptions of reality, personal constructsand instrumental elements of a PCF.

20


The learning journey will expose analysts tothe problem of developing IS, in particular to systems analysis and design. It will show howstructured and object-oriented methods areused to analyse and design IS, and how they presume and make assumptions aboutwhat constitutes knowledge of the problemdomain – the workplace, the organization,people – where IT is to be applied.

The end point of the journey is developedcriticality. The critical perspective on structuredand object-oriented systems ontology will focuson the assumptions they make about organiza-tion, people, and the work they do, and on whatanalysts and designers can know about them.The adequacy and efficacy of the instrumentsused to analyse and design IS will be ques-tioned. This critical perspective will reveal thatsome assumptions of the problem domain andthe efficacy of instruments used are debatable.It will reveal the limits of knowledge thatanalysts can establish about the design domainand raise awareness of what is still problema-tical in IS.

At the end of the journey your PCF shouldcontain understanding and appreciation thatknowledge and practice is progressive, and thatyour PCF should be similarly progressive. Afinal PCF is a dead PCF. Your PCF should bericher for understanding that some researchersand analysts regard the problem domain as‘objective facts’ that can be established and usedto develop IS. Others regard it as a complexmix of subjective, social and organizationalissues that need to be understood and incorpo-rated in systems analysis and design. It shouldrecognize that the methods, techniques andtools in structured and object-oriented analyseshave limits, and that there are political, organi-zational and cultural obstacles for analysts toovercome if they are to deliver relevant systemsmodels and designs.

1.10 Personal Critical Frameworkdevelopment

1.10.1 Repertory grid technique

Personal constructs should be elicited using therepertory grid, a technique to make learningmore relevant to individual needs. The tech-nique is used to elicit and analyse knowledge,and can be used for self-help as in a PCF devel-opment. Its use should challenge beliefs andself-images of the self that are not tested butheld to be ‘true’. True learning happens whenthe self is somehow affected.

The repertory grid technique consists of com-piling a table with a left-hand column and aright-hand column that contain polar oppositeconcepts, and up to 21 other columns containingthe concepts, ideas or objects related to systemsanalysis and systems design. It is not necessary tohave 21 columns. Use a word processor table orspreadsheet for marking out the grid.

The personal constructs on the horizontalbar are suggestions only. You may add more orchange them to suit your ideas on systemsanalysis and design. Compile your own ele-ments and polar opposites to make it personallyrelevant. The right and left bars show the twoends of a pole. Make out cards for each of theconcepts, ideas and objects that make up thecolumns – personal constructs. Table 1.5 illus-trates the technique and an elaborate grid isshown in section 5.9.1, Table 5.4.

Each concept, idea and object that makes upthe 21 columns is also written on a separatecard. Working with a peer (the tester), completethe grid to reveal your personal constructs.Groups of three cards are shown by the testerto the individual whose personal constructs areto be elicited, and the tester asks the same ques-tion each time: ‘How are two of these similarand the third different?’ For example, for therational–emergent polar dimension in the first

111

0

11

0111

0

0

11p

21


row, the three cards shown are organization,project team and interviewing. Mark a strokefor each card dealt and for the odd one out (theone identified as different) mark with a cross-stroke.

Your answers will be your personal ‘con-structs’ for systems analysis, or a dimensionalong which you have divided up knowledgeand experience. Once the grid is complete it isto be analysed using one of many rankingmethods to reveal which are the core personalconstructs that you use to construct and antici-pate events in the real world. The personal con-structs will indicate how you have divided upyour knowledge and experiences of systemsanalysis and design.

You can then evaluate the usefulness andvalidity of these objectified personal constructsfor your PCF. You can decide whether thepersonal constructs you identified form thefoundation for professionalism, or whichsystems ontology you prefer, or help you decidewhich instruments to use.

Types of repertory grid are available. Theone used in this book is visual. It can beanalysed using a visual technique. Table 1.5 isreproduced in Table 1.6 to demonstrate how toanalyse the content of a completed repertorygrid. Table 1.6 shows the elements (in columns)and constructs (in rows) and the completedtick/cross by an assumed analyst.

To analyse the completed grid the methodof visual focusing is used. In a separate newtable of three columns, the pattern in the first element ‘systems analysis’ from the com-pleted grid is copied into the first column of the new table. This column is then comparedin turn with each other element. For example,the ‘Systems analyst’ element is compared with the ‘users’ element first, then with the‘Organization’ element, and so on, in turn.Each time there is an agreement, defined aseither two ticks matching or two crosses match-ing, ‘1’ is recorded in the third total column.The column-by-column comparison results invarious strips as shown in Tables 1.7 and 1.8.The maximum agreement score is 5, which isthe number of constructs in the grid and theminimum is zero.

When all the possible pairs of elements havebeen so analysed they are then drawn as amatrix. (All the pairs are not reproduced here.)It is not necessary to use the original elementnames, they can be coded as E1, E2, etc. forease. The pattern that emerges is the significantunderstanding of personal constructs. Thematrix with the agreement scores for all thepairs might look like Table 1.9.

This analysis reveals elements and their asso-ciated meaning for a person. To discover thesignificant elements, Table 1.9 is then initiallyanalysed along the rows to find the matching

22


Table 1.5 Repertory grid technique

Pole 1 Systems Organization Workers Project Interviewing Pole 2analyst team

Rational � ✗ � Emergent

Efficient � ✗ Problematic

Objective � ✗ Subjective

Diplomatic ✗ � Authoritative

Ethical ✗ ✗ Unethical

higher numbers. The project team and userselements are in agreement, with each scoring 5.Where elements are in agreement they sharesignificant meaning for the supposed analyst. Itmeans that 5 out of 5 times the supposed analystagrees on these two elements as equally valid orimportant. The analyst sees no difference.

The significance of these numbers becomesapparent when they are considered in thecontext of an actual or supposed problem.Suppose that the analyst is engaged in gather-ing system requirements information in anorganization. He or she does not differentiatebetween the project team and users, because

111

0

11

0111

0

0

11p

23


Table 1.9 Agreement scores

Systems analyst Organization Users Project team Interviewing

Systems analyst ✗ 3 2 5 3

Organization ✗ 3 2 4

Users ✗ 5 3

Project team ✗ 2

Interviewing ✗

Table 1.6 An assumed analyst’s repertory grid

Pole 1 Systems Organization Users Project Interviewing Pole 2analyst team

Rational � � � ✗ � Emergent

Efficient ✗ ✗ ✗ � � Problematic

Objective � � � ✗ � Subjective

Diplomatic ✗ ✗ � � � Authoritative

Ethical � � ✗ � ✗ Unethical

Table 1.7 Visual focusing (A)

Systems analyst Users Total

� � = 1

✗ ✗ = 1

� � = 1

✗ ✗ = 1

� � = 1

Total 5

Table 1.8 Visual focusing (B)

Systems analyst Organization Total

� � = 1

✗ ✗ = 1

� � = 1

✗ � = 0

� ✗ = 0

Total 3

5 out of 5 times they are given the same rat-ing by the analyst. There is also an agreementscore of 3 out of 6 between users and inter-viewing.

The analyst can use the repertory grid resultsto evaluate the impact of these meaning onpractice. The analyst can assess whether theequivalence afforded to users and project teamis practical. The analyst’s project team andusers elements is significant because in practicethe analyst will behave equally towards usersand the project team, which may cause diffi-culties when system project priorities clash withusers’ priorities. Such reflection will result inadditional personal constructs, which can beadded to the repertory grid and scored.

To decipher the significance of elements theyare rearranged with similar elements replacedtogether in a different matrix, as shown inTable 1.10. This grid shows the similaritybetween elements and constructs in terms ofhow near they are in physical space – placedadjacent to each other.

The users and project team are placedtogether (first two columns) because they are intotal agreement. The systems analyst and

organization elements are nearly in agreementso they are placed together. The interviewingand instruments elements are similarly placedtogether because they are nearly in total agree-ment. The significance of the precise re-sortingdepends on the analyst’s concern. If only simi-larities are sought rather then exact matches there-sorting does not have to be exact. If exactmatches between particular elements are soughtthen only those need to be placed togetherexactly.

A similar ordering of constructs can bearranged. For example, the diplomatic–authoritative and ethical–unethical constructscan be compared as in Table 1.11

This shows that there is lack of agreementbetween diplomacy and ethical behaviourbecause on three scores they do not match. This result suggests that the supposed systemsanalyst is influenced in diplomacy by ethics. Amatrix for all the personal constructs can be constructed and analysed. Further referencesfor understanding and compiling a personalconstruct system are given in section 1.10.3.Use the references to seek further guidance onanalysing a repertory grid.

24


Table 1.10 Similar elements

Pole 1 Users Project Interviewing Instruments Systems Organization Pole 2team analyst

Rational � � � � � � Emergent

Objective � � ✗ � ✗ � Subjective

Efficient ✗ ✗ � � ✗ ✗ Problematic

Diplomatic � � � � � � Authoritative

Ethical ✗ ✗ ✗ � � � Unethical

Table 1.11 Similar–dissimilar personal constructs

Diplomatic � � � � � � Authoritative

Ethical ✗ ✗ ✗ � � � Unethical

It is assumed that readers will attempt somekind of personal construct elicitation. If therepertory grid technique is not used the per-sonal constructs can be ‘conceptual’ and a PCFcan still be developed using any of the activitiesA to E below, and similar activities in otherchapters. It is the PCF that is more importantthan a correct method for eliciting personalconstructs.

Activity A

For this activity refer to the internet sources forpersonal construct theory detailed in section1.10.3 and further reading in section 1.10.4.Copy Table 1.5 onto a spreadsheet and addyour own ideas for personal constructs(columns) and polar opposites (rows). Using therepertory grid technique determine your per-sonal constructs. Work with someone to helpyou deal the cards and fill in the grid. Discusswith your colleague or peer whether the resultssurprise you or confirm your understanding ofsystems analysis. Evaluate whether the personalconstructs you identified are appropriate for thesuccessful achievement of the work you do?

Activity B

This activity provides a staged approach tostarting to think about a PCF. It makes use ofwriting and diagramming as expression. Youmay want to complete the following:

• Identify and write down concepts, phrases,words and things you do in practice.

• If you have not yet practised systems analysis,identify and write down concepts, phrases,words and things you would do in practice.

• Draw a diagram placing these items intoboxes, rectangles and triangles, etc.

• Draw arrows, lines and other connectors toshow how these items are related to eachother.

• Analyse the diagram to assess whether itaccurately describes what you do or whatyou would do.

Activity C

Develop a tabular PCF similar to the illustra-tions in section 1.7 to describe your approachto systems analysis. Use the Delphi Report cog-nitive skills to think about your ethics, assump-tions of reality, personal constructs, and theinstruments you use to achieve goals. Describethe relations between these elements.

Activity D

Find a trusted colleague or peer and discussyour ideas on the five components of the PCF.Make notes of your ideas as you discuss them.Elaborate your ideas in textual prose.

Activity E

Either draw a diagram of how you act to com-plete an assignment or draw a diagram of howyou acted in an IS development project. Beginby jotting down words that come to your mind.Organize these words into a logical order todescribe your knowledge and practice and thenillustrate them in a diagram.

1.10.2 Experiences, evidence andcriticality

Activity A

Barnett’s schema for criticality consists of trans-formatory critique, refashioning of traditions,reflexivity and critical skills.

• Describe one example either from personallife experience or practice for each type.

• Describe an example of reflexivity in yourpractice.

• Make a list of critical skills an analyst wouldneed to develop to improve practice.

111

0

11

0111

0

0

11p

25


Activity B

In groups of two or more, individually write 300words on your interpretation of systems analy-sis and design. Share your text with the groupand discuss how they interpret your views. Isyour interpretation a shared view or different?In either case discuss the importance of inter-pretation and shared knowledge in understand-ing and establishing knowledge.

Activity C

For all the activities in the previous section andthis section, identify the elements that are basedon evidence of systems analysis and design.What kind of problems might arise from non-evidence-based reasoning in practice? How isthe validity of critical observation improvedwith evidence?

26


1.10.3 Internet sources

Critical thinking

Definitions of critical thinking can be found at: http://www.philosophy.unimelb.edu.au/reason/critical/pages/definitions.html (accessed 24 April 2003).

The Education for Thinking Project examines the development of thinking and learning skills asa goal of education. This site contains a series of short ‘meditations’ on thinking, knowledge, argu-ment, etc. from one of the world’s leading psychologists of critical thinking. http://www.tc.edu/centers/eft/ (accessed 24 April 2003).

To explore software for critical thinking see: http://www.philosophy.unimelb.edu.au/reason/critical/pages/software.html (accessed 24 April 2003).

Ethics

Search www.bcs.org for the ethical code it prescribes for its members. Think about how you wouldinclude it into your ethical practice.

For an internationally accepted source for ethics and professionalism surf IFIP’s SIG 9.2.2 ‘Framework on the Ethics of Computing’ http://www.ifip.or.at/ (accessed 21 May 2003).

Personal constructs

Surf http://www.brint.com/PCT.htm for an easy to read overview of personal constructs(accessed 21 May 2003).

For a brief overview of how personal constructs are established using the repertory grid techniquesee: Atherton, J. S. (2002) Learning and Teaching: Personal Construct Psychology [Online] UK: Availableat http://www.dmu.ac.uk/~jamesa/learning/personal.htm (accessed 21 May 2003).

For a business application of the repertory grid technique see: http://www.enquirewithin.co.nz/BUS_APP/business.htm (accessed 21 May 2003).

For an elaboration of the role of criticality in education see: Barnett, R. (1997) Higher Education: a

Critical Business, Buckingham: Oxford University Press.

For the development of critical thinking in learners see the Delphi Report: Facione, P. A. (1990)Critical Thinking: a Statement of Expert Consensus for Purposes of Educational Assessment and Instruction,Millbrae: Santa Clara University, pp. 1–19.

An elaboration of the holistic approach to learning and teaching, upon which this book is based,can be found in: Patel, N. V. (2003) ‘A Holistic Approach to Learning and Teaching Interaction:Factors in the Development of Critical Learners’, International Journal of Educational Management,17(6): 243–247.

A rather old edition but the original contains a fuller elaboration of the repertory grid techniqueand how to interpret the hidden meanings within it, is: Thomas, L. F. and Harri-Augstein, E. S.(1985) Self-Organised Learning, Foundations of a Conversational Science of Psychology, London: Routledge& Kegan Paul.

111

0

11

0111

0

0

11p

27


1.10.4 Further reading

2.2 Introduction

Structured systems analysis and design is heretermed ‘structured systems ontology’ and object-oriented systems analysis and design is termed‘object systems ontology’. They are two currentdominant strands in systems analysis and design.They seem partial and unsatisfactory becauseorganizations and analysts experience a varietyof problems applying them in practice. Largeorganizations experience problems in develop-ing and managing inflexible IT and IS that posea significant overhead cost to business opera-tions. Problems arise in determining what IS to

select for development and how to developthem, determining system functionality, orkeeping developed IS relevant to organizationalneeds. Consequently, analysts need to approachknowledge and practice with a reflexive per-spective. They work in an environment wherethe complexity of IS is increasing but improve-ments in knowledge and practice is laggingsignificantly.

Professional analysts can be trained to applyinstruments to develop IS. Trained analysts’ suc-cesses will be limited to smaller IS and may notbe scalable to larger IS and organizations. Whiletraining provides knowledge of how to apply

28

Chapter 2

Critical knowledge and practice framework


To engage in the PAC cycle, after completing this chapter you should be able to:

• Interpret the Critical Knowledge and Practice Framework (Critical Framework forshort) to critique, evaluate and analyse knowledge of systems analysis and design.

• Apply the Critical Framework to interpret the application of formalism in systemsanalysis and design to actual IS problems.

• Interpret the major themes and sub-themes in the Critical Framework to evaluatecritically knowledge and practice.

• Explain how the Critical Framework relates to the development of the components ofa PCF.

• Use the Critical Framework for ‘self-regulation’ in terms of the Delphi Report’scognitive critical thinking skills.

instruments, it is incapable of engendering criti-cality. The ever-increasing complex problem ofdeveloping IS in organizations requires trainedand educated professionals. Analysts interact withprofessional accountants, marketers, businessexecutives and other business professionals, sothey need to learn to understand business prob-lems such as ‘efficiency drives’, ‘quality improve-ment’ and ‘competitiveness’. Simple training isinsufficient in this kind of environment.

A Critical Framework is elaborated in thischapter to engender a critical perspective. Acritical perspective means to learn to regard(personal) knowledge and practice as progressiverather than established. It is used throughout thechapters to develop criticality. Criticality is nec-essary to understand systems ontology, instru-ments, the business context, and determine howto proceed within it. It is an important attributeof a reflective practitioner who has to deal withever-increasing IS problems.

2.3 Human action and criticality

Computer-based IS are required to managedata, information and knowledge in modernbusiness organizations. The development of ISis a human activity that encompasses organ-ization, people, IS and IT.

The quality and delivery of a developed IS islikely to improve if analysts develop a criticalperspective. Systems analysis and systems designare key activities that determine the success ofthe development. Analysts’ actions are centraland critical in the development process. Their knowledge and understanding of systemsanalysis and design and the organizational prob-lem to be solved determine the actions theythemselves take.

Such human action is based on knowledgeand understanding of the actual situation andknowledge of systems analysis and design. Bothdepend on ontological knowledge. Such onto-logical knowledge contains an explanation of

the actual situation that determines what actionis taken. For example, if human intelligence isunderstood and explained as genetic inheri-tance, then there would be an absence of edu-cational policy actions designed to developintelligence in children. If the genetic inheri-tance explanation for intelligence is accepteduncritically then it can lead to major disadvan-tages for people who do not have the ‘intelli-gent’ genes. Similarly, if systems analysis anddesign is accepted as objective it will determinehow an analyst acts.

Analysts need to think critically about know-ledge and how it informs practice. Unquestionedacceptance of systems ontology will result in rotepractice, and lead to developed IS lacking qual-ity and relevance. Critical evaluation of know-ledge and its practical validity to achieve desiredobjectives will improve action and lead to thedesign of the most appropriate IS.

2.3.1 Systems analysts, knowledge andpractice

The Critical Framework is formulated to enablecriticality. Analysts need to develop cognitiveskills to evaluate a variety of issues and developcritique. Issues range from deficiencies in know-ledge, grey areas in practice, and adequacy ofinstruments. Such issues can be evaluated bydeveloping critical thinking skills.

Critique is developed by uncovering andquestioning assumptions about reality made inmethodologies and systems ontology. TheCritical Framework is a point of reference todevelop significant critique. Its purpose is to:

• contribute to the development of PCF;• enable the development of critique;• engender reflexivity;• improve knowledge, practice and under-

standing of context and instruments;• critically understand and critically apply

instruments.

111

0

11

0111

0

0

11p

29

..........................................................................Chapter 2 Critical knowledge and practice framework

2.3.2 The critical knowledge andpractice framework

The Critical Framework, shown in Figure 2.1,is thematic. Analysts can use the themes to crit-ically scrutinize knowledge, conceptual under-pinnings, methods, instruments and practice.The Critical Framework is a set of themes,ideas, concepts, and learning tools arranged inthree layers to develop critical thinking. Thethick arrows indicate the logical moves fromone theme to the next and what is required tomake the move.

The first layer of the Critical Frameworkconsists of three major themes and six sub-themes through which knowledge and practicecan be explored. The major themes are systemsontology, the real world of human problems,and pragmatic resolution, and the six sub-themes provide analytic foci for criticallyexploring the major themes. The major themesdepict the object of study (real world of humanproblems), the nature of the object and how itis studied (systems ontology), and pragmaticactions required to analyse and design IS (prag-matic resolution). The combined major themes

30


Apply formalmethods

Real world ofhuman problems

(Messy world)

Organizations,people,

data, information,knowledge,

Information Systems,Information Technology

Systemsontology

Formalism

Pragmaticresolution

???

Interpret formalismsin practice

Develop knowledgeDetermine a pragmaticresolution to problemswith formal methods

Resolveproblems

Transformation oftraditions reflexivityTransformatory critique Critical skills

Figure 2.1 Critical knowledge and practice framework

and the sub-themes provide a critical lens foranalysts to examine knowledge and practice.They enable analysts to think critically andshould be referred to in enacting the PAC cycleto interpret and analytically evaluate knowledgeand practice to include in a PCF.

The second layer explains the rational foreach major theme. The systems ontology themeis to develop formal knowledge of systems orformalism, including theory. Such knowledgemay be objective or subjective. This theme isknowledge oriented. The real world of humanproblems theme is to understand the applica-tion of formalism and its effectiveness in orga-nizational context. The pragmatic resolutiontheme is to resolve contextual problems with theapplication of formalism to real problems. Thehuman problems and pragmatic resolutionthemes are practice-oriented.

The third layer correlates the type of criti-cality that might normally be associated witheach of the three major themes. Transformatorycritique is associated with the development ofknowledge of systems ontology. Reflexivity andrefashioning of traditions criticality is associatedwith practice, the human problems theme.Critical skills are associated with resolving prac-tical problems with applying formalism, thepragmatic resolution theme. The critical think-ing skills in Table 1.4 (section 1.8.1) are requiredin, and common to, all three themes.

The first layer of the Critical Framework isunderpinned with six sub-themes. They providethe foci for analysts to interpret and evaluateknowledge, practice, and know-how. The sub-themes are:

• Reality and knowledge, of organization andpeople, and IS and IT.

• Theoretical, conceptual, and formal know-ledge of systems.

• Pragmatism, or practical knowledge ofsystems analysis and design.

• Planned action and plans.• Situated action, and situations and context.• Methods for acquiring knowledge.

Reality and knowledge IS researchersseek to develop knowledge of IT and IS and itsuse in organization and society. Their aim is todevelop valid knowledge that is establishedthrough agreed methods of inquiry. Knowledgefrom research is referred to as ‘knowledgeclaim’. Knowledge is also established throughpraxis or practical experience.

Analysts need to evaluate this kind of know-ledge. As they work in or for organizations, theyneed to understand them, develop knowledgeof people who work in them, and how theywant to use IS and IT. Analysts should inter-pret and evaluate knowledge claims concerningthese issues, and uncover assumptions under-pinning the knowledge claims to assess reliabil-ity and validity.

Knowledge needs to be critically examinedto uncover assumptions that may not be valid. Researchers and practitioners makecertain assumptions when developing know-ledge because the subject of study cannot beknown in its totality. These assumptions mayweaken the reliability of the knowledge claim or its effectiveness for practical purposes.

Theoretical and conceptual know-ledge Theory is concerned with providingexplanations of observed phenomena. Theexplanations can be conjectural and abstract orbased on empirical data gathered by research.Sometimes theoretical explanations can bespeculative. For example, organization theory isconcerned with describing and explaining whatorganizations are and how they work, it seeksto understand and explain people in organizedactivity.

There is no substantive theory of systemsanalysis and design pertinent to IS. There isconceptual knowledge and formalism, but

111

0

11

0111

0

0

11p

31


formalism does not provide explanation. Soresearchers draw on organization theory,systems theory, social theory, communicationtheory, and information and situation theory.They do so to understand the role of informa-tion, knowledge, IS and IT in organizations andits effect on people.

This is a fundamental sub-theme for devel-oping critical thinking. Concepts and instru-ments in systems analysis and thinking stemfrom theoretic explanations of organization,people, IS and IT. As practice is affected bysuch knowledge it is necessary to consider con-ceptual knowledge and formalism critically.

Pragmatism The actual achievement ofan objective is a pragmatic process focusing onthe practical rather than the conceptual or for-malism. IS development is a pragmatic activityand systems analysis and design is concernedwith practical action – the analysis of humanproblems, development of systems models andtheir implementation.

The actual application of formalism incontext requires critical thinking. This sub-theme is related to actual practice of systemsanalysis and design. Pragmatic behaviour is con-textually rich. Analysts come to know detailsabout work, workflows, processes, business data,information and knowledge, people and com-munications, and many other elements of organ-ization in context. They need such detailedknowledge because they have to develop systemsanalysis and design systems models in such acontextually rich setting. Contextual, pragmaticknowledge helps analyst to find ways of resolv-ing problems with formalism, or practical know-ledge, when applied in context.

Planned action A plan is a rational, con-ceptual construct detailing and prescribinghuman behaviour designed to achieve objec-tives. Plans epitomize human action as rationalaction. They contain predetermined activitiesthat specifically prescribe behaviour and

describe desired outcomes. Planned action isclosely linked to developments in science andthe scientific method. It is crystallized as‘methodology’ in IS development. This sub-theme covers IS methodologies, methods, techniques and tools.

Planned action is contextually poor becauseit cannot foresee the actual situation in whichthe plan will be implemented. The SDLC,structured systems analysis and design(SSADM), and IS methodologies are examplesof planned action. They are together heretermed the structured systems ontology. Object-orientation and object-oriented analysis is not entirely planned action because it is flexiblein how it is carried out. It is termed here asobject-oriented systems ontology. This sub-theme is a central source for critically analysingthe efficacy of systems analysis and design basedon planned action.

Situated action Situated action is humanintention that cannot be explicated in terms of rules and procedures. It is informed by con-text and utilizes ‘embodied skills’ (Suchman,1994). Unlike planned action, situated actioncannot be detailed or described in advance ofaction.

Situated action is a comparative criticalthinking sub-theme. It can be compared withplanned action to understand how analystscould act. Situated action makes use of contex-tual and situational information and draws onembodied skills. Arguably, systems ontologyneeds to incorporate situated action.

Knowledge of action as situated action is not discussed much in IS methodologies andsystems analysis and design. It can be said to beemerging in methodologies, and in some ISdevelopment approaches like ASD and JAD.

Methods of knowing This sub-theme is toevaluate analytically methods for acquiringknowledge on the nature of organizations andpeople, IS and IT, and how to analyse and

32


design IS. Deciding what IS to build, deter-mining system functionality, deciding on user interfaces design, determining data inputs,process and outputs, is all dependent on themethods used to acquire knowledge. Knowledgeto develop a new IS can be regarded as ‘objec-tive fact’ or as ‘interpretation’. Analysts shouldunderstand both forms of knowledge, and interpret and evaluate a personal position.

This sub-theme is important for the develop-ment of criticality in analysts. Analysts are con-cerned with the systematic attempt to shape thefuture in a coherent way – ‘praxeology’. Toshape the future it is necessary to acquire know-ledge about the nature of the subject acted upon.The nature of something is called its ‘ontology’.How we know something, such as how organ-izations work or the relation between informa-tion and people, is called ‘epistemology’ – or howto acquire knowledge. Analysts are particularlyconcerned with pragmatic action and how theyact is based on the kinds of epistemology andontology they accept as valid and reliable.

This sub-theme is difficult to relate specifi-cally to systems analysis and design or ISmethodologies because their inventors do notexplicitly state how they acquire knowledge orthe nature of their subject. SSM, which is advo-cated for systems analysis, is based on ‘systemsthinking’. Its underlying method of knowing isinterpretation based on ‘holism’. To establish‘objective facts’ for systems models othermethodologies use ‘reductionism’.

2.3.3 The ontology of systems

Transformatory critique is applied to systemsontology. Systems ontology is the knowledgetheme in the Critical Framework. Systemsontology is knowledge of the nature of systems.System ontological knowledge covers the prob-lem of defining, describing and explaining IS in terms of the capacity and limits of IT, and

how humans interact with it. Ontologicalsystem knowledge underpins how the IS devel-opment problem is framed and resolved, andunderpins pragmatic response. This theme canbe extended to cover practical knowledge onhow an IS is selected for development, whatsystems analysis and design conceptual know-ledge is generated, and what approach andinstruments to use.

Systems analysis and design can beexplained in terms of systems ontology. The dif-ferent approaches, methods, techniques andtools are based on various explicit or implicitontological assumptions. This theme is to makeexplicit the systems ontology, its assumptions,account for how it is constructed and formal-ized, enable comparative analysis of systemsontology and facilitate the inclusion of anappropriate systems ontology in a PCF.

Ontology is the philosophical study of thenature of being. It has implications for know-ledge and practice of systems analysis and design. The systems ontology theme is con-cerned with the nature or knowledge of systems.The nature of systems can be regarded as purely technological or a combination of the social and technological. Whichever systems ontologyis accepted it contains assumptions about organizations, people, IT, and IS and the interrelations between them.

Philosophy is an important issue in systemsontology. Software programming methods andIS methodologies, including systems analysis anddesign approaches, have ‘philosophical’ basis,which may not be obvious to analysts. It needs tobe made explicit. Philosophical underpinningsare important because of implications for prac-tice in real situations. For instance, object-ori-ented programming is based on a philosophy thatcharacterizes organizations and people in termsof ‘classes’ or ‘objects’ that have ‘attributes’ andprovide ‘services’ to other related objects. It influ-ences analysts’ perceptions of reality.

111

0

11

0111

0

0

11p

33


Ontological knowledge is acquired withformal research methods and from the reflec-tions of experienced practitioners. Formalmethods of inquiry are termed epistemology.Some formal methods of inquiry describe andexplain systems ontology as objective. Thesemethods lead to practice that makes analystsdetached and independent of the human prob-lems they seek to resolve. Other formal methodslead to knowledge that makes analysts inclusiveand subjected to the human problems they seekto resolve.

Epistemology in social science that leads toobjective knowledge is termed positivism.Positivism acquires knowledge about organ-izations and society by reducing the problemdown into manageable, observable and measur-able elements. Reducing the problem intomanageable elements is called reductionism.Scientists use it to develop scientific knowledge.Reductionism as a problem-solving strategy is also used in systems analysis and design,particularly in structured systems ontology.

Epistemology in social science that leads tosubjective knowledge is termed phenomenol-ogy. It acquires knowledge about organizationsand people by understanding peoples’ interpre-tations and perceptions of their actions.Understanding the problem in terms of people’sexperiences and their interpretations is calledinterpretivism. There is marginal recognitionof interpretivism as a problem-solving strategy in systems analysis and design, though NIMSADis normative, and Open Source Software (OSS)and ASD may be construed as interpretivism.Interpretivism is an accepted method forresearch in IS. Positivism and interpretivism areused to acquire IS knowledge and instrumentsfor IS development. These epistemologies haveresulted in knowledge of the problems in, andinvestigation of, IS development.

Structured systems ontology is based onhuman rational capability. Rationality is the use

of reason and logic to think on a problem andits resolution. It has resulted in formalism insystems analysis and design. One form of ratio-nality is planned action. In organizations plansunderpin IS strategy, systems analysis, systemsdesign, governance and management mechan-isms. Planners and plans assume an organiza-tion is a rational and optimizing entity, and thatonce developed, plans can be implemented toachieve stated objectives. Structured systemsontology assumes objective knowledge andrelies on rational planning. Rationalism under-pins its instruments, but they pose practicalproblems in practice and are insufficient fordeveloping complex organizational IS. TheSDLC and systems project managementsimilarly rely on rational behaviour.

Systems ontology based on interpretivismviews reality as humans’ interpretations. It cen-tralizes individuals and the meanings theyattach to their actions. Reality is socially con-structed in interpretive systems ontology. SSMand situated action are examples of interpretivesystems ontology. The use of stories in ASDacknowledges interpretive systems ontology.

Systems ontology is a representation of realsituations. It develops knowledge of and struc-tures problems in IS, but the actual problemsexist in the real world of human problems.

2.3.4 Real world of human problems

Refashioning of traditions and reflexivity criti-cally is applied to the real world of human problems. The real world of human problemsis the first practice theme in the CriticalFramework. A human problem is any organ-ized effort to achieve an objective. Business andtechnical problems combined constitute actualhuman problems. Business problems rangefrom strategic issues on competitiveness to oper-ational issues on business process efficiencies or cost reduction.

34


The application of IT to resolve businessproblems is a separate technical problem. IT isapplied on the basis of ontological system know-ledge. Systems ontology provides the formalismand instrumental means to apply IT. The actualapplication of IT underpinned with systemontological knowledge is problematic. Actualorganizational business context and technicalproblems differ from an assumed systems ontol-ogy or formalism. For example, in contrast tooptimum solutions based on complete informa-tion proposed in structured systems ontology, inactual situations organizations seek non-optimum solutions to problems and do so withlimited available information. People haveintentions and are capable of influencing plans.Organization and organizing do not easilysuccumb to the application of formalism.Uncertainty in real situations and decision-making affect the application of formalism.

Analysts’ apply systems analysis and systemsdesign formalism in practice. They are con-cerned with determining how to respond toactual problems by applying ontological andtechnical system knowledge. Interpretation issignificant in the application of knowledgebecause of varying perceptions of individual orgroups of analysts. Formalism encounters prob-lems when applied to actual situations, which inturn necessitates understanding organizationsontologically, and leads to revisions in systemsontology or partial deployment of formalism.

Similarly, the resolution of the technicalproblem necessitates analysts to understand thebusiness and organizational context. Analystshave to interact with people and appreciateissues in business strategy, competition andbusiness process improvement. They have tounderstand organizational interaction andcommunication designed to achieve tasks andobjectives. People pose particular problemswhen applying instruments and require under-standing:

• How human purpose is established and itsdynamism.

• Organization and communication and itsdynamism.

• Human interpretation and meaning attachedto actions and the results of actions.

• Social aspects of human interaction andcommunication.

• Political aspects of human interaction andpower relationships in organizations.

Real situations are referred to as the ‘messyworld’ in the Critical Framework. The descrip-tion of real situations as ‘untidy’ or ‘messy’ is used to compare actual human problems with how they are characterized, and the solutions proffered, in systems ontology, or for-malism. This messy world is not susceptible to the direct translation of rational formalism of systems analysis and design. The applica-tion of structured and object-oriented systemsanalysis and design in the messy world is problematical.

The messy world theme enables critical eval-uation of formalism in the context of actualproblems in organizations and in relation topeople. For example, the use of questionnairesto elicit requirements for a new IS may raisesuspicion in people who are required to com-plete them. The suspicion may lead to refusalto comply or at worst result in sabotage. Thedevelopment of a PCF requires an understand-ing of these organizational, people and appli-cation problems. Novice analysts need to beaware of them and experienced analysts needto reflect critically on them to develop relevantpersonal constructs.

2.3.5 The pragmatic resolution

The development of critical skills is realized inpragmatic situations to enable critical thinkingon praxis. The pragmatic resolution theme is

111

0

11

0111

0

0

11p

35


concerned with developing practical knowledgeof applying formalism in real situations. It is thesecond practice theme. Its purpose is to encour-age analysts to overcome practically the prob-lems with applying formalism in organizationsand in relation to people, and to develop criticalskills.

Adjustments to system ontological know-ledge and the application of instruments areoften necessary in practice. Changes to instru-ments or prescribed application processes needto be made to achieve required objectives.Innovative ways have to be found to interactwith people to apply the prescribed formalism.Ironically, the changes and innovations made to apply formalism in actual context may becharacterized as situated action.

Practical knowledge is a prerequisite of pro-fessionalism. Analysts need to make decisions onhow to resolve problems with applying formal-ism practically in actual situations. Pragmaticsolutions to application problems are necessaryand may result in amending or adjusting for-malism and how it is applied. Changes to howinstruments are applied can be based on clearerunderstanding of the problems in the messyworld.

Critical understanding of formalism, plannedaction and situated action sub-themes can resultfrom the pragmatic context. For example, thequestionnaire technique may be part of an ana-lyst’s plan to elicit requirements. Its actualimplementation may create anxiety in peoplefor fear of change. So the analyst should be prepared to think of an alternative that does not cause anxiety to people who’s work is beinganalysed. Another example is an analyst com-municating gathered system requirements asE–R or DFD diagrams to ‘users’, who fail toprovide intelligible comments because they donot understand the diagrams. The analyst canresolve the problem pragmatically by develop-ing prototype user interfaces to show to users.

‘Seeing’ the system will help users to make useful comments.

2.3.6 Comments on the CriticalFramework

The Critical Framework is necessarily ladenwith the author’s subjective values phenomeno-logical ontological position. The choice ofthemes and sub-themes is personal, but they doreflect the discourse in the wider literature onsystems analysis and design and IS. The issuesthey raise are pertinent to knowledge and prac-tice. It is assumed that the major themes andsub-themes in the Critical Framework will besufficient to develop criticality.

The Critical Framework is to be used toimprove personal knowledge and practice. It isnot proposed (at present) as a model for criticalsystems ontology in the field. It offers scope anda framework for criticality because it is arguablewhether systems analysis and design can bepractised objectively. It is plausible to argue thatit is phenomenological, as many analysts makechoices based on familiarity or successful prioruse of formalism or instruments. Such epistemo-logical positions and counter positions pose avalidity issue for positivist researchers.

The Critical Framework will enable criticalanalysis and evaluation of various issues. Itenables fundamental assumptions made insystems ontology to be revealed, analysed andevaluated in terms of actual situations and prag-matic application. Systems analysis and designderives its system formalism from systems theory,systems thinking, and positivism. The majorthemes will enable critical consideration of the knowledge value and practicality of notions like ‘structured’, ‘objects’, and ‘engineeringsystems’. In particular, the Critical Frameworkwill enable interpretation, analysis, explanationand evaluation of:

36


• Philosophies and assumptions underpinningstructured and object-oriented systems ontol-ogy.

• Formalisms like the SDLC and its applica-tion.

• Structured and object-oriented systemsanalysis and design (and other approacheslike prototyping and JAD).

It will also enable:

• Personal inferences to be drawn for devel-oping a PCF.

• ‘Self-Regulation’ because the CriticalFramework acts as a device to ‘monitor cog-nitive activities, the elements used in thoseactivities, and the results educed’ (Facione,1990).

The primary purpose of the Critical Frame-work is to develop critical learners and practi-tioners. It facilitates criticality in two ways. One,it will enable a critique of ontological systemknowledge. It is an aid for making critical observations on knowledge and practice, pre-paring project managers and analysts, anddeveloping reflective and critical skills in themwhen selecting and implementing formalism in practice. Two, it will enable critical thinkingon IS projects, requirements analysis and sys-tem specification, data and process model-ling, object modelling, user interface and datadesign, system interfaces. Both these levels of criticality will inform the development of a PCF.

2.3.7 From the particular to the general

Human action in actual situations is unique andparticular. Ideally, each situation requires itsown particular response suitable to it only. Insmall system projects a unique response is fea-sible, but in larger projects practitioners draw

on established generalized knowledge. Thesystems ontology theme constitutes such gener-alized knowledge to facilitate criticality. It ispossible to be critical of individual situations,but not of all particular situations and experi-ences. The latter is possible with generalizedknowledge.

Though human action is particular, it isinformed by, and often predicated on, general-ized knowledge. Analysts infer generalizedknowledge from particular instances. Similarly,IS researchers draw general inferences fromsamples of empirical data. Generalized know-ledge of human action, social factors, organiza-tion, people, systems, IS and IT should beinterpreted and analytically evaluated in termsof the Critical Framework. The following three sections is an outline of such generalizedknowledge.

2.4 Social and technical factors

Knowledge of organization itself is complex.Knowledge of organizational application of ITfor IS to achieve objectives is a higher order ofcomplexity. Organizational application of IT isthe context for systems analysis and design.Analysts need to appreciate and understand thiscomplexity.

The combination of organizational socialfactors and technological technical factorsmakes systems analysis and design uniquelyproblematical. The social factors require ana-lysts to consider how humans organize them-selves in a collective to determine purpose andstrive to achieve it, how people communicate,cooperate, and interpret their actions in organ-izations, and what meanings people attach toinformation and knowledge. The technicalfactors include systemic knowledge, IS method-ologies, formal methods, instruments, choice ofsoftware and hardware, problem-solving andother skills of analysts, programmers and

111

0

11

0111

0

0

11p

37


project managers. A significant element of thetechnical decisions made concern assessment ofthe suitability and capability of the available ITto produce required IS.

The dichotomy between social and technicalfactors is useful when analytically evaluating formalism. Some formalisms account for onlysocial or technical factors, others consider both.For example, Information Engineering andearly versions of SSADM are orientatedtowards developing technically optimal systemsmodels. Others have developed a socio-technical perspective. The ETHICS method-ology is the seminal socio-technical perspective.It is based on the notion that both social andtechnical factors need to be understood todevelop effective, socially responsible IS.

2.5 Human action

Human action can be categorized and ex-plained as the planned action and situatedaction ideal types. Both types provide theoreti-cal, conceptual and generalized knowledge ofhuman action. IS methodologies and formalismin systems analysis and design is interpretedhere as planned action. In contrast, situatedaction emphasizes the context and situation,and explains how humans use certain ‘embod-ied’ knowledge that arises in situations. It canbe used to counter-argue planned action andexplain many of the problems that arise inapplying formalism in practice.

Planned action and situated action sub-themes are intellectual traditions to explainhuman action. They need to be critically con-sidered in systems analysis and design and canbe analytically evaluated in terms of the systemsontology theme. They proffer descriptions andexplanations of human action, which need tobe analysed and their basic assumptions raisedand discussed.

2.5.1 Planned action

In planned action people and organizations arecharacterized as rational and goal-oriented.Planned action is action that is predeterminedwith expected outcomes to achieve knownobjectives and enacted in actual situations torealize the expected outcomes. A plan is aformal instrument of organizational systemsstrategy that details what IT to apply and howIS should be developed. Formal plans arecentral in business organizations. Their scope iswide, covering plans of business strategy, IS andIT strategy, and systems project management.Planned action assumes it is possible to plan and control organized human activity, and doso rationally.

Systems analysis and design draws onplanned action. IS methodologies are detailedplans of how to define and develop IS. Systemsproject management epitomize planned man-agement of IS development. Planned action ofthis kind characterizes organization, people,information and knowledge, as entities that canbe analysed, objectified and modelled with pre-cision rationally. Structured and object-orientedinstruments attempt precisely such planned,rational systems modelling and design.

The generic structured SDLC is character-ized here as planned action. It supports the view that planning IS development will resultin successful and relevant IS. It prescribesplanned stages for systems developers to followsystematically and is composed of staged activ-ities and detailed activities in each stage. Thefocus of the activities is the completion of the technical tasks of systems analysis, systemsdesign, testing and implementation. Structured,and to some extent object-oriented, systemsontology assume that planned action can leadto successful IS development, and relevant andrequired IS.

38


2.5.2 Situated action

Situated action is not explicit in any formalismin systems analysis and design or methodology.Nevertheless, it is a significant sub-theme withinsystems ontology and human problem themesthat can be the basis of action and explanation.eXtreme Programming (XP) may be inter-preted as drawing on situated action to elicitsystem requirements. It uses ‘stories’ recountedby people to understand system requirements.Such stories are necessarily situated.

In situated action, organization and peopleare characterized as goal-oriented, but contex-tual, and situated. They draw on situationalknowledge and embodied skills to achieve goals.When problems arise in pursuing goals, theydraw on any relevant knowledge, situatedfactors, and embodied skills to overcome them.

Systems analysis and design can be inter-preted in terms of situated action. The inter-pretation can explain problems with applyingformalism or lead to better formalism sensitiveto context. Analysts can draw on embodied skillsand situated knowledge to resolve problems withapplying formalism to actual situations.

2.6 Systems theory

Systems theory is used to inform human action.The system concept is an intellectual tool forrigorous and thorough problem definition andproblem resolution. It enables human problemsfrom actual situations to be abstracted in systemterms for reasoning and resolution. Systemicfeatures facilitate such problem framing andresolution. They are:

• Purposeful activity or goals.• The whole is greater than the sum of the

parts.• Predictability of systems processes and rela-

tions between the subsystems.

• The distinction system enables between thesystem and its environment.

• Related to the latter, is the notion of openand closed system.

A system consists of a set of interrelated ele-ments or components that has a purpose andthe system is greater than the sum total of itsparts. It has a boundary that defines and dis-tinguishes the system from its environment withwhich it communicates inputs and outputs.Processes in the system transform inputs intooutputs. A system can have subsystems with thesame characteristics. The system is coherentbecause it has structure and processes, whichare maintained by feedback and control. Asystem can be open, meaning that its elementsinteract freely with its environment, or closed if the interaction with the environment iscontrolled by the set boundary.

An example system is shown in Figure 2.2.The system is set in the environment with whichit communicates inputs and outputs. Its purposeis determined by events in the environment. Itcontains subsystems that communicate witheach other, and the subsystems and the com-munication compose the processes that trans-form the inputs into the required outputs.Feedback from the environment on the effec-tiveness of the outputs is used to adjust theinputs and processes to ensure the requiredoutputs are produced. Control, shown as echowaves, pervades the whole system and is usedto direct the processes towards the goal.

Systems theory has influenced how theproblem of IS development is defined, struc-tured and resolved. As in Figure 2.2, in its mostfundamental form it informs the view of IS asa systemic entity with inputs, subsystems, rela-tions, processes, outputs, a system boundary,and a system environment. Earliest applicationsof computers to business organization mirrorthese system elements. Structured systems

111

0

11

0111

0

0

11p

39


analysis with its focus on data processing isstrongly informed by systems theory.

2.6.1 Systems thinking

Systems thinking draws on systems theory. It isapplied to characterize organizational problemsin systemic terms. An organizational prob-lem, for instance improving the managementefficiency of a NHS Trust, can be interpreted in systemic terms as consisting of purposefulbehaviour, with elements that communicatewith each other and with the environment toachieve specific purpose. This type of system istermed a human activity system. A human activ-ity system has purposeful control where decisionmakers make choices about the system.

The systemic attribute of the whole beinggreater than the sum of the parts is signifi-cant. The combination of the elements and subsystems produces an ontologically differententity, the system. This is termed the emer-gent property of system. This means that the whole cannot be understood simply byexplaining its parts. The emergent property of systems is significant for understandinghuman activity. Systems thinking has severaluses:

Method of enquiry Systems thinking is amethod for acquiring knowledge. It is a formalinterpretive method for understanding, prob-lematizing, and solving human problems.Systems thinking is used to develop knowledge

40


Subsystem A

Subsystem C

Subsystem D

Subsystem E

SystemInputs Outputs

Processes

Feedback

ControlC

ontrol

Control

ControlSubsystem BSubsystem BSubsystem B

System environment

System boundary

Figure 2.2 The system concept

and understanding of organizations and people,and its proponents recommend its use in con-ceptualizing IS and in IS development.

Conceptualize real world problemsSystems thinking can be used to think aboutreal situations and human problems. Complexorganization problems can be interpreted insystemic terms that would otherwise be impos-sible to conceptualize. They can be conceptu-alized as wholes with interrelated subsystemsthat have emergent properties, and purposesthat are achieved through feedback and controlmechanisms.

Analysis technique It can also be used asa method or technique to analyse organiza-tional problems that would otherwise be diffi-cult to do. Systems thinking is used to developan appreciation of real world problems and toconduct an analysis of subsystems, constraints,and explore solutions.

Management method Systems thinkingcan be used as a method to inform manage-ment practice. It can be used to conceptualizeand analyse quite complex organizational prob-lems, and through systemic analysis providemanagement with clearer understanding ofproblems and possible solution actions.

Systems thinking is normally used to struc-ture problems in organizations and bring to the surface how people perceive these problems.It can be applied to IS to structure thinking. The emergent property of systems is clear in IS,since the combination of the constituent partsof an IS produce an Information System that isdifferent in nature from its compositional parts.It is ontologically different. Modelling thesecomponents in systemic terms will depict theelements, interrelations, the boundary and the system’s environment. The various compo-nents that constitute an IS can then be inter-preted in systemic terms to organize ideas andconcepts about organization and people, data,information, IT and IS.

The descriptive and analytical capability ofsystems thinking is useful for systems analysisand design. It can be used to describe the actualsituation and perform an analysis of it in sys-temic terms. Various systems analysis anddesign formalism in IS methodologies make useof systems thinking. For example, in Multiviewthe SSM ‘rich picture’ technique is used. A richpicture is used to develop an appreciation of theproblem as perceived by people in the organ-ization. In Multiview it is proposed as a systemsanalysis technique to help determine systemrequirements.

2.6.2 Organization, people and systemsthinking

Organizations use IT to process business datato produce information and knowledge. Theycapture, process, store and manage data forseveral reasons:

• Legal requirements: compile statutoryaccounts, reports for shareholders.

• Improve organizational efficiency and effec-tiveness: reduce costs or improve businessprocesses.

• Determine business strategy: executivesdevelop business strategies to compete withother businesses.

• Provide information for decision-making:increase or decrease production, make aninvestment in capital machinery.

• Organizational knowledge: manageorganizational knowledge and build know-ledge bases for innovative product design.

Analysts need to appreciate organizationsand what IT and IS can contribute. Organ-izations exist in business, government, health-care and other human interests like charities. An organization is defined as having goals, aboundary and human activity. It is composed of

111

0

11

0111

0

0

11p

41


people collaborating, sharing and communicat-ing to achieve set goals. The goal may be to pro-duce an aircraft or car, or to provide a financialservice, or to retail goods.

IT is used to ‘transform’ organization, inparticular business processes. Productionprocesses or management processes can beimproved to produce better products or servicesby applying IT innovatively. Transformingbusiness processes with IT though is a complextask. Systems thinking can be used to describeand analyse organizational uses of IS. It can beused to understand conceptually:

• How people in organizations communicatewith each other, what information theyshare, process or exchange.

• How various departments, sections, groups(elements in systems thinking) communicateinformation to achieve organizational goals.

• How to demarcate a particular area of theorganization (draw a boundary in systemsthinking).

• How to determine what external factorsaffect the organization (determine how theelements interact with the environment insystem terms).

The conceptual knowledge can then be used tomanage the actual problem. Understanding thenature of organizations is an element of the sys-tems ontology theme and a significant factor inapplying systems analysis and design formalism.

Systems theory and systems thinking has fun-damental implications for the systems ontologytheme. Systems theory regards people as thesource of problems in the system and it is con-cerned with responsibility, or moral and ethicalissues. It creates a systemic view of organization,people, information, and IS. It separates know-ledge about work from the subject or individ-ual and it is concerned with how we gain

knowledge, or epistemological issues. This isregarded as valuable in systems thinkingbecause such knowledge can then be stored andprocessed and used to improve organizationalefficiency and effectiveness.

2.7 Focus on criticality in systemsanalysis and design

Analysts need to develop a critical dispositionbecause of the centrality of their role. Theyhave an important multi-purpose role. The coreof their work is the creation of systems modelsfor which they communicate with people forwhom the system is to be developed. Analystscommunicate the systems models to systemsdesigners and software programmers.

This core work of investigation and creationof systems models constitutes systems analysisand design. Their design decisions affect people,workflow patterns, business processes andinformation provided to managers. The ideasfor these creative systems models come frominvestigation of organization and people andthe resultant understanding of system require-ments. The purpose of the Critical Frameworkis to engender criticality and adduction of per-sonal constructs. The emphasis on the personalapproach is to enable knowledge and practiceto be developed for practical application.

Criticality in the field of systems analysis anddesign has lead to improvements in conceptualknowledge and instruments. It has progressedsystems analysis from ‘art’ to ‘structured’ and from ‘object-orientation’ to ‘eXtreme Pro-gramming’. Critical thinking resulted in system-atic ‘problem-solving’ and produced methods tostructure an IS problem and solve it. It resultedin the concept of systems analysis and design as a rational process, where perfect knowledge is assumed, and depicted the role of analysts asrational problem-solver.

42


2.7.1 Systems analysts, problem-solvingand creativity

A critical disposition is important because ana-lysts’ work is future-oriented. Analysts examinecurrent problem situations to determine a betterfuture organization. A critical disposition isrequired to:

• think of innovative strategic and operationalsystems;

• use IT creatively;• improve approaches, methods and tech-

niques;• improve problem-solving techniques.

IT is a fundamental prerequisite for moderninformation and knowledge management inorganizations. It has created the modern notionsof ‘data’ and ‘information’, and it is import-ant for organizational knowledge management.Computer network technology, especially theinternet, enables knowledge to be managed elec-tronically and enables eCommerce. So analystsneed to develop methods to think of innovativestrategic and operational systems. A critical dis-position can engender creative uses of IT. Theirwork requires creatively addressing business andtechnical problems. At a strategic level com-panies now expect IT to deliver innovative busi-ness processes and eCommerce. IT has enabledradical innovations in strategic IS, and recentlyin BPR and knowledge management. A strate-gic IS is difficult to innovate because it shouldbe inimitable, and its precursor is often an operational system that has the potential to bestrategically important.

Analysts require two types of problem-solving skills: business problem resolution andtechnical problem-solving. Criticality is import-ant in both types. It is required to define thebusiness problem because it affects the organ-ization. It determines how the available

resources will be deployed and whether theresultant IS will benefit the organization.Analysts work with business analysts to definethe business problem. Strategic business prob-lems concerning competition require IT to beapplied creatively. IT, the internet and commu-nication technologies are combined to enablecompanies to create new business models.A business model is a set of interrelated busi-ness ideas on how to produce products or services better than competitors to the satisfac-tion of customers. To create business modelsexisting ways of working and organizing needto be analysed and radical new designs created.Systems analysts need to base systems modelson business models that give an organization acompetitive advantage or improve efficiency.

Analysts need to ensure that IS complementinnovation policies. Business organizations haveinnovation policies for products, services,organization of the production of goods andprovision of services. Analysts should criticallyassess whether structured and object-orientedsystems ontology engenders innovative think-ing. Significantly, they should evaluate whetherthe systems ontology they assume is relevant inpractice.

Technical problem-solving requires system-atic or logical thinking. To solve systemic prob-lems analysts first need to define or structureproblems as clearly as possible. They need toconsider issues internal to the organization andexternal issues, like competitors and techno-logical know-how. If definition of the problemis inappropriate or completely misses real busi-ness needs the resultant IS will be of little use,resulting in obsolete investment. Analystsshould evaluate available problem-solvingstrategies to choose the most appropriate. Onestrategy is breaking the problem down intomanageable components and solving the com-ponents separately. Another is holism in which

111

0

11

0111

0

0

11p

43


the problem is modelled as a whole. These skillsare needed for systems modelling.

Problem-solving has an element of creativ-ity. Analysts need to develop lateral thinkingskills. What can be done with IT and how ISproblems can be solved should not be con-strained by existing knowledge and practice.Creativity in problem definition and its resolu-tion may involve brainstorming and role-playwhich may result in radically different ideas.Electronic devices and other tools can be usedin the creative process. For example, videorecordings can be made of system requirementselicitation to facilitate better analysis.

2.8 Relating the Critical Frameworkto Personal Critical Framework

The Critical Framework is the basis for devel-oping a PCF. The three major themes and sixsub-themes in the Critical Framework providesubstance for the PAC cycle activities that leadto the development of personal constructs andtheir continuous revision.

2.8.1 Objectification of personalconstructs

The Critical Framework themes enable analyststo objectify relevant personal constructs and toevaluate them critically. The themes enable ana-lysts to explain personal constructs in the contextof knowledge and practice. Personal constructsare shaped by systems ontology knowledge andpractical application of formalism in actual situ-ations, or human problems theme.

Personal constructs need to be objectifiedand relations between them explained toimprove understanding and personal effective-ness. Implicit personal constructs will not beunderstood and may lead to personal actionthat is ineffective. Such action is neverexplained. The Critical Framework provides

the basis for the objectification of relevant per-sonal constructs by exploration of its themescritically in relation to knowledge and practice.

2.8.2 Critical evaluation of personalconstructs

Critical thinking needs to be applied to theCritical Framework themes. Objectified per-sonal constructs can be reflected upon and deci-sions regarding inclusion in a PCF can be madeon the basis of the themes. This process can aidanalysts to objectify and evaluate personalconstructs critically rather than accept themuncritically and implicitly.

The process of objectifying personal con-structs and assessing their relevance once objec-tified requires critical thinking. The CriticalFramework is a cognitive device to aid analyststo analytically evaluate personal constructs. Itcombines cognitive critical thinking skills, thethree major themes and the six sub-themes, andBarnett’s (1997) three criticality types to providea framework to develop criticality.

The Critical Framework and PCF comple-ment one another. The Critical Framework is tobe used to develop personal constructs on struc-tured and object-oriented analyses and systemsontology generally. It will develop analysts’reflexivity skills to:

• Bring to the surface problem definitions,premises and assumptions made in struc-tured and object-oriented analyses.

• Enable critical reflection that leads to a per-sonal interpretation of structured and object-oriented analyses.

• Enable analysis of structured and object-oriented analyses through the three majorthemes and six sub-themes.

• Provide a basis to evaluate the validity andreliability of structured and object-oriented

44


analyses, its instruments, and analysts’related personal constructs.

• Facilitate discussion and provide a context,especially in terms of human problems, inwhich to compare structured and object-oriented analyses and other approaches.

• Support the development of evidence-basedcritical thought and reasoned comments andopinions based on experiences and readings.

The Critical Framework enables thematic crit-ical thinking on practical IS developmentproblems. Its critical perspective is required to improve effectiveness of project teammembers, especially analysts and project man-agers, and gives them the confidence to evalu-ate approaches and techniques for particular ISprojects.

2.8.3 Requirements: an exampleobjectification

An example of the process of objectifying per-sonal constructs is an analyst who uses ques-tionnaires to elicit system requirements. Theanalyst diligently prepares a questionnaire byreading widely to gain knowledge on question-naires, and identifies the right people to probeby examining the organization chart and speak-ing to managers of departments. The question-naire is then administered to these people withequal diligence. The resulting system require-ments information is disappointing because the analyst is unable to clearly identify the newIS functions.

In this situation the Critical Framework canbe used for reflexive questioning and develop-ment of personal constructs. The followingquestions and sub-themes may be explored: (a)What assumptions are made about peoples’knowledge of requirements and the practicalapplication of the questionnaire? This coversthe three major themes. (b) Is the questionnaire

an appropriate method to capture what peopleknow? This covers the method of inquiry sub-theme. (c) Are there situational factors that needto be investigated too? This covers the situatedaction sub-theme.

The analyst can use knowledge from thepractical experience to probe these themes torevise personal constructs and determine anappropriate pragmatic resolution. The analystshould begin the objectification process byasking questions:

• Why did I choose questionnaires to elicitrequirements?

• What evidence is there that questionnairesare successful?

• Can people relate to questionnaires or did itdistance people?

• How do questionnaires relate to my otherpersonal constructs about people’s knowledgeand their ability to communicate it?

2.9 Applying the CriticalFramework

An example application of the CriticalFramework will illustrate its relevance. It willdemonstrate how it can be used to think criti-cally of knowledge and practice, and how it isrelated to developing a PCF.

The example application is on ‘data’ and‘information’. They form a significant contri-bution to knowledge and practice in IS devel-opment. They are investigated during systemsanalysis and systems design. To enable analyststo understand how to objectify personal con-structs related to data and information, theCritical Framework needs to be populated withknowledge and practice on data and informa-tion. An outline example of data and informa-tion in terms of the Critical Framework isshown in Figure 2.3. Performing the followingactivities populates the Critical Framework:

111

0

11

0111

0

0

11p

45


• Examine the knowledge base of the concept,method, technique, tool or methodology.

• Explore its practical relevance for humanproblem resolution.

• Determine a pragmatic resolution to practi-cal application problems.

• Underpin the above with criticality.

2.9.1 Considering major themes

The first layer of the Critical Framework inFigure 2.3 illustrates how the systems ontologytheme is populated with ontological knowledgeof data and information. Following the arrowacross, they are an interpretation of organiza-tion and communication issues in the real worldof human problems. Formalism related to dataand information is applied in an actual situa-tion. Following the second arrow across, prob-lems with application of formalism are resolvedpragmatically.

The second layer is the rationale, assump-tions and knowledge on data and information.An example in the second layer, first column,shows data is transformed into information byprocessing. Through application to practice orreflective study, the second column of thesecond layer, analysts can evaluate validity ofinformation as processed data and assesswhether it confirms their interpretation, know-ledge or experiences. The validity of theassumption and practicality of instrumentsbased on it are then resolved pragmatically, asshown in the third column.

The third layer engenders the three types ofcriticality. The first column in the third layer isthen used to develop a critique of systems ontol-ogy by asking relevant questions based on extantknowledge and practical experience. For exam-ple, is information objective, or is it interpreted.This is transformatory critique. The second col-umn in the third layer is populated with ques-tions concerning practice to engender reflexive

criticality. For example, what is the role of‘meaning’ in information, or does an analystneed to be objective, and how can this be realized in the messy world. This is reflexivity.The third column in the third layer is populatedwith questions concerning the pragmatic reso-lution of application problems. It engenders critical skills to enable the task to be accom-plished. For example, to resolve the problem ofinterpreted information, develop ways of help-ing people to objectify what they already knowand incorporate into requirements analysis.

2.9.2 Other issues

Analysts can use the Critical Framework tointerpret other issues:

• the term ‘Information System’;• the idea of ‘system’;• information flows in organization.

The term ‘Information System’ itself is debatedacademically. Many monologues on what itmeans have been written. Some focus on thesub-term ‘information’ and others on ‘system’.An Information System may be regarded as anobjective or interpreted entity. As structuredand object-oriented analyses assumes an objec-tivist ontology, an IS may be accepted as anobjective entity. An analyst’s personal constructmay assume either ontology, but the choice ofthe one will negate the other, and the choicecan be made by critically evaluating boththrough the themes of the Critical Framework.

Similarly, the use of the term ‘system’generates much academic debate. Someresearchers in systems thinking argue thatsystems need to be central to research and prac-tice in IS development. Other researchers focus on the human and social factors in IS.The social context, namely organization andpeople, of IS development has resulted in

46


111

0

11

0111

0

0

11p

47


Apply formalmethods


(Messy world)

Organizations, people,Information Systems,

Information Technology

Systemsontology

SDLC

SDLC assumes thathuman behaviour is

rational and informationis available

Formalism,system,

sub-systems,control,

coordinatedbehaviour,

‘user’

Fixed,optimal,

predictable,efficient,effective,

measurable,engineered

(systems andinformation)

Pragmaticresolution

Problems with optimumand change

???

Interpret formalisms inpractice

Apply assumption ofrational humans and

organizations –does it work?

Develop knowledge

Objective epistemologyassumes human and

organizational behaviouris rational or economic

perfect knowledge

Determine a pragmaticresolution to problemswith formal methods

Resolveproblems

Transformation oftraditions reflexivity

What is rationality?Objectivity is important,

but how can it be realizedin the messy world?

Can ‘users’ be involvedin development?

Transformatory critique

Is the world objective?Are humans rational?

Is organizationalbehaviour rational?

Is perfect knowledgeavailable?

Critical skills

Use the Delphi techniqueto be objective, helppeople to objectify

requirements

Figure 2.3 The SDLC – an example of a populated critical framework

socio-technical methodology. The human ele-ment of IS has resulted in researchers exam-ining information as phenomenological orinterpreted.

Structured and object-oriented systemsanalyses are used commercially to develop IS,though some business organizations do notmake use of methodologies. For these organ-izations, the lack of contextual analysis in struc-tured techniques makes them unsuitable. Thecontext of IS development is important andanalysts need to consider appropriate personalconstructs to account for it.


2.10.1 Education and training

Questions

1 How often do you reflect on knowledge thatyou possess or you practice? What is thetopic of your reflection? What mechanismsdo you use to reflect? How does reflectionimprove your knowledge or professionalpractice?

2 Define training. Why is training not suitedfor reflection? How does it differ from edu-cation?

3 How can the Delphi Report’s set of cogni-tive skills be used to think critically aboutsystems analysis and design?

Activity A

To paraphrase the education psychologistSkinner, education is what survives after whathas been learnt has been forgotten. Make a listof facts or themes you remember from your firstuniversity degree or earlier formal study toascertain what you remember. You may findyou have forgotten the details. If memory is nota good measure of education, then what do you

think should be used? Address this question andthen revisit the Delphi Report’s cognitive skillsfor critical thinking. Now make a list of cogni-tive capabilities that you think are the benefitsof an education. What kind of critical cognitivecapabilities have you identified?

Activity B

• Write down the attributes that you thinkdescribe you as ‘educated’.

• Make a list of the attributes that someonetrained in systems analysis and design mightposses.

• Compare (1) with (2). Select your preferenceand explain why.

2.10.2 Fundamental elements ofInformation Technology

Question

Discuss how IT can be used to develop IS that:(a) improve operational efficiency, (b) provideinformation for decision-making and (c) giveorganizations a strategic advantage.

Activity A

Identify an IS in your organization. What datadoes it require as inputs to produce informa-tion as outputs? Who in the organization uses theinformation and for what organizational purposeis it used? How do you think the IS helps peoplewho use it to interpret events in the organization?How does the IS contribute to making their workmore efficient or productive?

Tasks

• Differentiate between data, information, andknowledge in terms of IT.

• In a group, determine a code of ethicalbehaviour for systems analysts.

48


2.10.3 Systems thinking

Questions

1 Evaluate the theoretic view of organization asconsisting of a purpose, boundary and activ-ities. Discuss its value for systems analysis.

2 Critically discuss whether the system conceptmakes unique human problem situationshomogenous.

Activity A

Choose an organization you are familiar with,your place of study or work:

• What is its boundary?• What is its purpose?• What are its main activities?• How did you ascertain each of the above?

Discuss whether a formal method wouldimprove the process?

Activity B

Suppose you were required to develop an IS for supply chain management for a wholesalerof pharmaceutical products. Make whateverassumptions you think necessary:

• What is the purpose of the IS?• Define its boundary?• What inputs would be required from its

environment?• What outputs would the system generate?• What would be the main activities (processes)

required to generate the outputs?

Activity C

Systems theory has influenced approaches to ISdevelopment. In its most fundamental form ithas led to the view of an IS as a systemic entitywith a boundary, environment, inputs, sub-

systems, relations, processes, control, feedbackand outputs.

• Choose an IS you are familiar with, forexample a student record system or a payrollsystem. Describe it in systemic terms as inFigure 2.2.

• Discuss whether a systemic ontology is suffi-cient. What other factors do analysts need toconsider.

• What aspects of the organization and peopleare not present in the systemic model? Howwould the success of the IS be affected ifthese aspects were absent?

2.10.4 Problem solving and reasoning

Questions

1 What particular interfaces between an ISand its application domain are difficult todesign and implement?

2 Critically evaluate the interpretation ofsystems analysis and design as a problem-solving activity in system theoretical terms.

3 Explain what you understand by the term‘problem-solving’. What is the role of logicin it?

4 Explain the differences between data,information and knowledge in your organ-ization. Make a list of data, information andknowledge that your organization requires toconduct its business.

5 Explain what is meant by ‘description’,‘analysis’, and ‘criticality’. Which adds morevalue to problem-solving?

6 What is your understanding of the followingterms used in problem-solving:• task definition• information-seeking strategies• location and access• use of information

111

0

11

0111

0

0

11p

49


• synthesis• evaluation.

Activity A

Identify an information management issue inyour organization. Define it as an IS problem.Think creatively about how IT can be used tomanage the problem.

Activity B

How would you characterize the problem of ISdevelopment? Apply systems theory to charac-terize the problem. Evaluate whether systemtheoretic characterization adds value to under-standing the problem. Does systems theoryenable making inferences on the role of IT inorganization?

Activity C

Various techniques can be used for problem-solving. Brainstorming and role-play are twoexamples. Brainstorming is used to do someinitial thinking on a problem. It consists of agroup of people objectifying whatever comesinto their minds, despite its relevance, andsomeone recording the ideas on a whiteboard.Apply the brainstorming technique to theproblem of developing a website for an organ-ization. Analyse the feasibility of the resultantideas.

Activity D

Compare ‘trial and error’ problem-solving, alsocalled ‘exponential learning’ with formalproblem-solving (for example top-down decom-position in systems analysis). Why might trailand error be more appropriate in a socialcontext? How can formal problem-solvingsupport trail and error?

2.10.5 Systems ontology

Activity A

Identify a management information need, forexample information on students at a universityor information on customer purchasing habitsin a company.

Characterize the information need in systemterms.

• Identify the activities in the system.• Determine the inputs and outputs.• Determine the control mechanism.• Describe feedback mechanisms.• What is the value added by characterizing

the information need problem in systemterms?

• What elements of the real situation aremissing in the system interpretation? Whatmight be the effect on the information needif the problem is resolved in their absence?

2.10.6 Plans and situated action

Activity A

Identify any task you were required to complete.Describe the task and how you completed it.Include in your description your approach and:

• Any previous knowledge that you brought tobear on the task.

• Gaps in your knowledge to complete the tasksuccessfully.

• New knowledge that you had to develop inthe situation.

• Discuss whether you would categorize youraction to complete the task as planned actionor situated action.

Activity B

Based on the result from Activity A, if you onlyused planned action, make a list of activities that

50


you did to complete the task that might be con-strued as situated action. If your activities weredominated with planned action or situatedaction explain why it is so.

2.10.7 Applying the critical framework

Question

Discuss ‘criticality’ in systems analysis anddesign in terms of transformatory critique,

refashioning of traditions, reflexive criticalityand critical skills.

Activity A

Using the three major themes and six-subthemes of the Critical Framework, describe whatyou understand by the term ‘system’. Use thethree columns and three-layer layout in Figure2.3 to plot your knowledge of system. How mightyou use the system concept in your PCF?

111

0

11

0111

0

0

11p

51



Checkland’s work is seminal in systems thinking. See: Checkland, P. (1999) Systems Thinking, Systems

Practice, Chichester: Wiley.

For the relevance of systems thinking for IS see: Checkland, P. and Hollwell, S. (1998) Information,

Systems, and Information Systems, Chichester: Wiley.

The seminal work on situated action is by Suchman, L. (1994) Plans and Situated Actions, Cambridge:Cambridge University Press.

For recent developments in situated contextual factors in software development see the insightfulwork by Dourish, P. (2001) Where the Action Is: Foundations for Embodied Interaction, Cambridge, MA:Bradford Book, MIT Press.


The Journal of Vocational Education and Training at http://www.triangle.co.uk/vae/ publishes researchon the development of practice and theory in work-related education (accessed 25 March 2004).

For tutors and learners the Information Technology Fundamentals site at http://elearning.asu.edu/itf is a valuable resource covering computer hardware and networking (accessed 25 March2004).

The Thinking Page at http://www.thinking.net covers systems thinking, creativity and otherpsychological aspects (accessed 25 March 2004).

Pegasus Communication inc. at http://pegasuscom.com/aboutst.html provides purchasableresources on systems thinking (accessed 25 March 2005).

Three vital issues in IS development are considered in Part II on the basis of the PCF andCritical Framework developed in Part I. They are:

• The conceptual basis for systems analysis and design.• The use of system projects to develop IS.• The IS application or problem domain.

The first two issues are important because they form the knowledge and basis for practice.The third issue is important because the application domain determines what a new IS willbecome and affects how the system project is managed. These issues need to be criticallyconsidered because they contribute to the success of an IS.

The SDLC, making a business case for a new IS, and the role of analysts will be coveredin Part II. The focus of formalism in the SDLC is on the structured expression of informa-tion. The SDLC, role of analysts and development of business cases are formalisms in IS devel-opment. Understanding the role of formalism in IS development will enhance the developmentof PCF. Analysts can determine the value of formalism in a PCF through critical evaluation.Validity and effectiveness issues in formalism will be explored.

The conceptual basis of systems analysis and design is covered in Chapter 3. In terms ofcriticality, it contributes to the development of reflexive criticality. The SDLC, structured andobject-orientation concepts, instruments and IS methodologies, are covered in Chapter 4. Interms of the Critical Framework, analysts need to evaluate the effectiveness of current know-ledge for practice. They need to interpret and analytically evaluate current knowledge so thatit can be incorporated into a PCF.

An IS is usually developed as a project. Project management concepts and techniques arecovered in Chapter 4. Systems project management is analysed in terms of planned action.Making a business case for an IS is covered in Chapter 4. In terms of criticality, it contributesto the development of reflexive criticality. Business organizations invest in IT and IS becauseit can reduce operating costs and improve organizational effectiveness. Significantly, IT canprovide strategic advantages over rival companies. Making a business case is a fundamentalpractical element of IS development.

111

0

11

0111

0

0

11p

53

Part II

IS, projects and application domains

The important role of analysts is covered in Chapter 5. In terms of criticality it contributesto the development of refashioning of traditions and critical skills. Systems analysts have acentral role in IS development. They conduct three vital stages in the SDLC: the feasibilitystudy, systems analysis, and systems design, and contribute to making the business case too.

54

Part II IS, projects and application domains........................................................................................

111

0

11

0111

0

0

11p

55

Chapter 3

Systems analysis and design in concept and action


After completing this chapter you should be able to:

• Explain the SDLC, evaluate its generalizability and describe the role of systemsanalysis and design in it.

• Interpret and evaluate structured and object-oriented systems analysis concepts andinstruments.

• Interpret and analyse problem-solving strategies used in systems analysis and design.• Describe ontological characteristics of IS methodologies.• Apply reflexive criticality to the conceptual basis of personal practice in systems

analysis and design.

Knowledge and practice arise from practitioners’ experiences and investigations byresearchers. Practitioners codify their knowledge and disseminate it as practical know-ledge. IS researchers conduct empirical research to discover ontological and appliedknowledge and disseminate it as generalizable knowledge. Interpretive IS researchers donot seek generalizable knowledge.

IS is a complex socio-technical phenomenon because it encompasses social and technicalfactors. Whether it can be theoretically explained challenges researchers. They debatewhether IS can be called a discipline and the possibility of formal theory is keenly discussed.Presently, there are no formal theories of IS, though some researchers attempt to developtheory. Whether theories of systems analysis and design are possible is also open to question.

In the absence of theories, systems analysis and design has concepts, methods, tech-niques and tools, methodologies and frameworks that constitute knowledge. They are theresult of reflective practice and research to develop knowledge, especially generalizableknowledge. In this chapter the SDLC, structured and object-orientation concepts,methods, techniques and tools, and IS methodologies are introduced and critically dis-cussed. They underpin and constitute knowledge of systems analysis and design, whichtranslates into practice in whole or in parts.

3.2 Introduction

Systems analysis and design is central in ISdevelopment, eCommerce systems, eBusinessand knowledge management systems. Its primeaim is to develop systems models to inform thedesign and implementation of suites of softwareprograms that constitute a system. Systemsanalysis focuses on determining what a new ISis required to do. Analysts investigate, under-stand, and develop organizational knowledgeabout business areas where IT is to be appliedand develop systems models. Systems modelsare used to determine appropriate suites of soft-ware programs to write and their functions.

Systems analysis and design knowledge andpractice has evolved. Practitioners have intro-duced new ideas, concepts and instruments toresolve pragmatic problems as they haveencountered them. Researchers have studied ISdevelopment and the IS field and contributedepistemological and ontological knowledge.Early knowledge and practice may be describedas traditional or informal, where the aim ofpractitioners was to produce an IS but themeans were not clearly articulated, objectifiedor codified.

The prevalent current ideas and concepts arestructured systems analysis and struc-tured systems design and object-orientedanalysis and design. Structured analysis anddesign was introduced in the early 1970s becausetraditional knowledge and practice did not meetbusiness needs, and IS were more expensive thanbudgeted and took longer to develop thenexpected. Some reflective practitioners began tothink that structure in the process was needed toimprove the quality and success of IS. Theyintroduced structured systems analysis and struc-tured systems design methods, techniques andtools. They defined clearly roles for organiza-tional employees, project managers, systems

analysts and designers, and software program-mers. This added structure to the process, butdespite structuring the process, the quality andsuccess of IS remained problematical.

The concept of object-orientation in soft-ware programming appeared around 1990. Itaddressed the problems of quality and pro-duction of software programs. The idea logi-cally spread to systems analysis and design.Consequently, object-oriented systems analysisand design emerged as an alternative tostructured analysis and design.

3.2.1 Data, information and knowledge

Organizations generate data, informationand knowledge from their activities. IT is now asignificant means to make them into resourcesand assets. Its algorithmic processing capacitycontributes to the notion of information assets.Figure 3.1 depicts the roles of IT and humansin transforming data into information, andinformation into knowledge. IT is used to cap-ture, store, process, analyse, structure and sortdata to produce information. Organizations canregard information and knowledge as assetsbecause they can be stored and retrieved fromdatabases and knowledge bases.

IT enables the creation of information assetsand knowledge assets. An asset in business isnormally used to produce a product or service.Data on customers can be processed to yieldinformation assets for marketing products orservices. It can be processed to generate know-ledge on customers’ purchasing habits. Theirvalue is reflected in their status as resources orassets, similar to human or capital resources.Organizations use them to become more effi-cient and effective, and to create competitiveadvantage over rivals. Information resource isnow as equally important as human or capitalresources.

56


Data and information is distinguishable inIT terms. In IS data is converted into informa-tion by software algorithms that process thedata for specific purposes, shown by the firsthorizontal arrow in Figure 3.1. Data isunprocessed information. Data is captured,stored, and processed by digital computers and information is the result of processed data.A software algorithm is the sequence in acomputer program for processing data. Dataprocessing involves the analysis, structuring andsorting of data to provide information.

In human terms data becomes informationwhen a human interprets data for a specificpurpose, shown as the second column in Figure3.1. For example, railway companies produce

train timetables detailing the routes and timesfor trains. Train timetables are data. Whensomeone wants to travel to a specific place theywould use the timetable to plan a journey. Aperson processes the timetable for informationabout their journey. After determining theirdestination they would look-up their startingpoint and trace it to the destination to provideinformation about the departure and arrivaltimes of the trains.

Figure 3.1 illustrates the case of improvingcustomer service, shown in the third layer, thebusiness rational for using IT. In the firstcolumn, data on customers is collected. It isthen used to develop models of customer behav-iour, the second column. This is information.

111

0

11

0111

0

0

11p

57

................................................................Chapter 3 Systems analysis and design in concept and action

Information and internettechnology

InformationData KnowledgeProcess, analyse,

structure, sort,store

Process, analyse,structure, sort,

store

Humanrole

Managers,businessanalysts,systemsanalysts

Businessrational

Customerservice

Addmeaning,interpret

Apply(use for specific

purpose, predict)

Generate,collect

Develop modelsof customerbehaviour

Generateknowledge about

the customer

Apply knowledgeof customerbehaviour to

improve productor service

Figure 3.1 Data, information and knowledge in technological and business contexts

The third column shows that knowledge is thenapplied to improve products or services toprovide better customer service. When informa-tion is applied in a certain way to achieve a goalit constitutes knowledge. For example, apply-ing information about customer behaviour in terms of customer relationship management isknowledge.

The role of humans, managers, businessanalysts and systems analysts in organizations isshown in the first column in the second layer inFigure 3.1. They address the significantproblem of determining what IS are required.They determine what data to collect to produceinformation for organizational processes, tasksand decision-making relevant to improve cus-tomer service. In the second column humans,business people, interpret the information toadd meaning to it. In the third column theyapply information to the specific purpose ofimproving customer service.

Analysts aid managers to determine whatdata to collect and how it should be processedto provide relevant information. The processingcapacity of IT enables organizations to re-design organization and business processes toproduce quality products and services, andtransform organizations, through computernetworks, into networked organizations.

The role of IT is shown in the top layer. Itcan capture the required data and process it to produce information on customer serviceimprovement. This is shown as a process of con-verting data into information and, throughapplication, to knowledge. An IS is the combi-nation of all three layers. The role of IT formanaging organizational knowledge is similarto managing information. The same functionsof collection, storage, processing, analysis, struc-turing and sorting are applied to knowledgepossessed by individuals or groups to produce,store and retrieve organizational knowledge.

3.2.2 Application domains, problemdomains and Information Systems

In IS development a specific business areatargeted for the application of IT is called an application domain. The applicationdomain consists of people, peoples’ intentionand purpose, the work they do and the con-straints of their work, how and who they col-laborate and communicate with, the business ortask objectives they need to fulfil, products orservices they seek to make or provide and thephysical resources like documents and files.

The range of application domains or busi-ness problems for which IT is used to create IS is wide. Organizations apply IT to specificbusiness problems, business decision-making,business processes or whole organization. It isapplied to major business functions rangingfrom customer billing, payroll, stock control,accounting and financial planning to humanresource management and knowledge manage-ment. It is vital to business marketing and isused to enable electronic customer relationshipsmanagement and enterprise resource planning.In eBusiness, IT and the internet are combinedto design networked organization.

Analysts investigate the application domain.The information needs of people in the appli-cation domain are called system requirements.System requirements are rooted in the applica-tion domain and new IS need to be designed tosatisfy the requirements. Analysts’ task is toacquire knowledge and understanding of theapplication domain to establish the systemrequirements, which are passed to software pro-grammers who write the actual programs forthe IS.

The application domain seen from the per-spective of systems analysts and IS developersis called a problem domain. It is so calledbecause systems developers seek to define it inorder to provide a computer-based ‘solution’. It

58


is the specific articulation or framing of aproblem in the application domain for which anew IS is required. Framing the IS problem isa critical task for analysts and it affects the selec-tion of instruments for IS development. Theframed problem provides project managerswith information to determine what resourceswill be required and to develop work break-down and product breakdown structures.

Various systems ontology characterize theproblem domain differently. The adequacy ofthis characterization is the issue criticallyexplored in the systems ontology theme of theCritical Framework. The very characterizationof the application domain as the ‘problemdomain’, for which a ‘solution’ is needed, isaccepted system ontological knowledge by prac-titioners. It is part of structured and object-oriented systems ontology. Such a characteri-zation in turn affects how an IS is conceptual-ized and developed.

3.3 Systems development life cycle

A new IS is the product of articulating the busi-ness problem, understanding the applicationdomain and framing the IS problem. Thegeneric SDLC is applied to understand appli-cation domains and define IS problems anddevelop IS. The ‘life’ metaphor is to indicatethat a computer system has a beginning, middleand an end. Each of the stages in the SDLCconsists of the ‘life’ of IS development. Once anIS is developed, people will normally want dif-ferent information, and the process of develop-ment would begin again. Hence the term‘cycle’.

The SDLC influences thinking on how todevelop IS and consists of phases of IS devel-opment, shown in Figure 3.2. It is a systematicmethod to solve the problem of IS develop-ment, consisting of the following phases:

• feasibility study• systems investigation• systems analysis• systems design• implementation• post-implementation review, evaluation and

maintenance.

The SDLC seeks to address the problem of ful-filling the system requirements of the applica-tion domain. The SDLC is shown in Figure 3.2in the context of an example business problem,namely improving customer service, the toplayer. The phases of the SDLC are shown asrectangle boxes below it and demarcated interms of the business problem.

The feasibility study and systems investiga-tion phases identify and define the businessproblem and provide alternative IT or non-IT solutions. The systems analysis and systemsdesign phases are concerned with makingimprovements to the business problem. Theimplementation and maintenance phase is con-cerned with developing a new IS. The finalreview and evaluation stage is concerned withassessing whether a new IS adds value. Activi-ties in the SDLC phases and some deliverablesof each phase are shown as rounded rectanglesbelow the SDLC phase.

The SDLC is regarded as generalizable to allorganizations. It was designed as a general solu-tion for any organization intending to developIS. It is supposed to work even when analystsmay be unfamiliar with the organization andlack experience of its processes, culture and peo-ple. All the SDLC phases are normally requiredto develop an IS. A system project normallyencompasses the SDLC phases. IS developmentmethodologies reflect the SDLC phases in vary-ing degrees. Some methodologies emphasizecertain phases more than other phases.

The SDLC contains systems analysis, systemsdesign and implementation as major phases.

111

0

11

0111

0

0

11p

59


Feas

ibili

tyst

udy:

det

aile

d s

tud

yof

the

bus

ines

sp

rob

lem

and

pot

entia

lso

lutio

ns

Sys

tem

sd

esig

nS

yste

ms

anal

ysis

Imp

lem

enta

tion

mai

nten

ance

Pos

t-im

ple

men

tatio

nre

view

Sys

tem

sin

vest

igat

ion

Feas

ibili

ty r

epo

rtE

xam

ine

exis

ting

syst

em r

equi

rem

ents

;id

entif

ies

new

req

uire

men

ts;

sugg

ests

alte

rnat

ive

solu

tions

;re

com

men

ds

aso

lutio

n

New

sys

tem

Writ

e an

d t

est

new

com

put

er p

rogr

amsu

ites;

pur

chas

eha

rdw

are/

sof

twar

e;en

sure

qua

lity

stan

dar

ds;

writ

esy

stem

doc

umen

tatio

n; in

stal

lan

d r

un n

ew s

yste

m(p

ilot,

cut

over

,p

aral

lel r

un)

Dev

elo

p in

itia

lsy

stem

des

igns

inco

rpor

ate

man

ual

asp

ects

of s

yste

m;

des

ign

inte

rfac

es;

des

ign

dat

a in

put

san

d o

utp

uts;

des

ign

pro

cess

es

Inve

stig

ate

curr

ent

pro

ble

ms

esta

blis

h re

ason

s fo

rp

rob

lem

s; e

stab

lish

req

uire

men

ts fo

rim

pro

ved

sys

tem

;d

evel

op c

urre

ntlo

gica

l mod

els

and

new

logi

cal m

odel

sof

new

sys

tem

;d

esig

n in

form

atio

nre

qui

rem

ents

Rev

iew

and

eval

uate

rep

ort

Det

erm

ine

chan

ges

req

uire

d; a

sses

sw

heth

erre

qui

rem

ents

are

met

: is

the

bus

ines

sp

rob

lem

ad

dre

ssed

?

Det

aile

din

vest

igat

ion

of

req

uire

men

tsE

xam

ine

bus

ines

sp

rob

lem

; exa

min

eex

istin

g sy

stem

;es

tab

lish

new

req

uire

men

ts;

iden

tify

cons

trai

nts

and

exc

eptio

nco

nditi

ons;

exa

min

eor

gani

zatio

n ch

arts

,gr

id c

hart

s,d

iscu

ssio

n re

cord

s

Bus

ines

s op

por

tuni

ty o

r p

rob

lem

:d

issa

tisfie

d c

usto

mer

sIm

pro

ve c

usto

mer

ser

vice

New

cus

tom

erse

rvic

e sy

stem

Ad

ded

val

ueto

bus

ines

s?B

usin

ess

pro

ble

m

SD

LC

SD

LCac

tivi

ties

and

del

iver

able

s

Figu

re 3

.2S

yste

ms

deve

lopm

ent

life

cycl

e in

the

con

text

of

busi

ness

org

anis

atio

ns

The activity of systems analysis and design, andconsequently the role of analysts, is an import-ant and central feature in it. Although thesephases are shown as part of the SDLC, they can be practised using various systems analysisand design methods. Among them are the traditional, structured and object-orientedmethods.

3.3.1 Feasibility study

Analysts conduct the feasibility study. Theproblem domains vary from operational issuesto matters concerning business strategy.Operational issues include poor customerservice, such as complaints from customers thattheir orders are not fulfilled, or the costs of pro-ducing an item are too high. They may be todo with improving efficiency of business ormanagement processes or ensuring the effec-tiveness of certain activities. Strategic issuesinclude the re-design of business processes tomake greater and better use of IT, the devel-opment of knowledge management systems tomanage organizational knowledge, or net-working collaborative work, all to improvecompetitiveness.

Analysts assess the problem domain – thework people do, whether manually or withcurrent IS – with respect to the current busi-ness problem to produce a feasibility report.The assessment is to define and understandcurrent problems and whether the current situation is acceptable or requires improving.The report contains a statement of the new needs, whether IT-based or manual, of theorganization, people and the business.

The feasibility study is to determine whetherit is both feasible and beneficial to produce a computer-based IS for a particular businessproblem. Activities to produce the feasibilitystudy are to determine and define the businessproblem and assess the contribution that a

computer-based system, or other alternative,would make. Analysts interact and communi-cate with managers and other employees toinvestigate the problem domain. Existing work-flows and processes, associated decisions andthe information available is analysed. An initialassessment of system requirements is made.

The problem domain is investigated with the aid of systems analysis instruments. Systemsanalysts use interviews, document and processanalysis and observation. Managers may beinterviewed and the documents they use ana-lysed. People whose work will be affected by anew IS may be observed and records of theobservation made. Analysts would normallywish to include senior managers, supervisors,clerks and systems developers.

Analysts investigate alternatives available,the costs to resolve the current business prob-lems, and determine the benefits that can beobtained from each of the alternatives. Basedon this evaluation, they would recommend asolution to management decision-makers. Thenext phase would ensue if senior managementdecides to proceed with the project.

3.3.2 Systems investigation

The purpose of the systems investigation phaseis to determine requirements of the current andnew IS. It is a systematic and detailed investi-gation of the problem domain. The analystwould normally use probing and searchingtechniques to establish the requirements. Theseinclude interviews, observation and examina-tion of documents used in the feasibility studyphase.

Analysts interview and record the responsesof people in the problem domain who perceivethe business problem and who will use a newIS. Organizational issues that impinge on theproblem domain would be examined too, forexample re-designing workflows or processes.

111

0

11

0111

0

0

11p

61


3.3.3 Systems analysis

In the systems analysis phase, analysts conducta thorough and detailed investigation of thecurrent system and the new IS based on theprevious two phases. Analysis is concerned withproviding a set of system requirements. This isachieved by developing systems models to:

• understand how business tasks are done andhow current work is organized;

• define the data to be captured;• determine the functions of the new IS to

produce required information.

Systems modelling activities focus on under-standing the present way work is done to developnew systems models. The systems models are often very different from existing workflowpatterns. If there is an existing IS, applied models are identified and an assessment is madeof how they are used. Analysts would need toconsult people whose work and processes are tobe modelled. Managers would also be consultedto help verify the systems models.

Systems models are developed with a mod-elling notation or language. A modelling nota-tion is a formal set of symbols with precisemeanings to represent the current and new IS. Modelling notations help to objectify theproblem domain and facilitate communicationbetween analysts themselves, and with clientsand software programmers.

3.3.4 Systems design

Analysts design a new IS based on the informa-tion gathered in the previous phases. Systemsdesign activities are concerned with the designof user interfaces, inputs, outputs and interfaceswith other systems. The designs may beimprovements in existing IS or radically newdesigns that redefine organization workflowsand processes. The computer hardware equip-

ment required to implement a new IS is iden-tified and evaluated. Relevant software needslike databases are determined.

System security and integrity issues would beforemost in the minds of designers. The designswould be in the form of diagrammatic models.Systems design models would be developedusing a modelling notation or language torepresent the inputs, functionality and outputs.The notation would normally be consistent withthat used in the systems analysis phase.

The systems models would be normallyshown to relevant people affected by a new IS.Their comments would be considered, thoughmajor changes to the designed systems modelswould be resisted because of time and costconsiderations.

3.3.5 Implementation

The implementation stage is concerned withactivities to implement the systems designmodels from the analysis and design phases.They are implemented using IT identified inthe systems design phase. Analysts are involvedin determining the computer hardware andsoftware required to implement the designedsystem. They work closely with the projectmanager, software programmers, databaseadministrators and people in the organization.They are a conduit between software program-mers and people, and work with softwareprogrammers to implement the systems models.

In addition to computer hardware and soft-ware considerations in the previous phase, data-base software and programming languages,where necessary, need to be evaluated, pur-chased and installed. Software programs needto be written and tested, and suites of programsneed to be integrated to check the integrity ofthe system. Documentation on how to operatethe new IS and guide maintenance would haveto be written, normally by technical writers.

62


3.3.6 Post implementation evaluation

Once the IS has been developed and is opera-tional, analysts normally conduct an evaluationof it to assess whether it meets the predeterminedbusiness needs. The evaluation is to ensure thatthe specified requirements of the problemdomain are being fulfilled by the new IS.

The length of time it takes to develop an IS isusually problematical. As business organizationsneed to respond to competitors and markets, it ispossible that the evaluation would reveal theneed for changes or enhancements to the devel-oped system, which the analyst would have tosuggest and for which revised systems design be developed. The project manager would need to ensure appropriate staffing to perform cor-rective or enhancement maintenance, and thatongoing maintenance is adequately resourced.

3.4 The traditional approach

Practical IS development and systems analysis isconcerned with solving problems: how to selectan IS project for development, how businessinformation needs can be established, findingways of designing proposed IS or developingdata and process models, and then convertingthe designed models into implementations.

The traditional approach preceded theSDLC. Systems analysis had no clear concep-tual basis or a central concept on which prac-tice was based. It relied on the knowledge andskills of experienced and competent practition-ers. The business problem and the IS problemwere investigated and studied simultaneously.There was no clear temporal or phased progressbetween analysis, design and implementationdemarcated.

Systems analysis and design consisted of adhoc use of techniques and entailed the designof a suite of computer programs and data struc-tures. There was no, or limited, involvement of

people with the result that requirements gath-ering was inadequate. The analyst’s task was tospecify the data structures and detail how theywere to be manipulated and stored on magneticmedia. Programs were designed and imple-mented as and when they were specified, andanalysis conducted concurrently.

Practitioners would make no distinctionbetween the analysis of the problem domainand the design of the system. Though it doesnot contain phases similar to the SDLC, the tra-ditional approach normally included require-ments analysis, requirements specification, andhigh-level design. It does not include many ofthe other phases in the SDLC nor does itproduce the deliverables shown in the SDLCFigure 3.2.

3.5 The structured concept

Since the first application of a computer to busi-ness in the 1950s, researchers and practitionershave addressed the knowledge and practiceelements differently. Early practitioners in thetraditional approach conceptualized IS devel-opment as writing computer software programs.It was seen as a ‘craft’, and software program-mers were thought to be creative, introvertedprofessionals. The analyst would provide asystem design and specification and the softwareprogrammer would write the required systemsprograms.

The resultant software products in the tradi-tional approach lacked quality, failed to meetuser requirements, cost more than was expectedand were delivered later than required.Reflective practitioners began to question the‘craft’ analogy, and proposed a ‘systematic’approach. Craft-based programming practicessuch as the ‘GoTo’ statements were challenged.‘The software crises’ was coined to depict theseproblems, and researchers and practitioners col-laborated to improve the process of developing

111

0

11

0111

0

0

11p

63


software. The debate was broadened to includethe engineering metaphor to improve soft-ware production. The major outcome of thisdebate was the idea of formulating and usingsystematic and structured methods to developsoftware culminating in the SDLC.

Structure is the central concept on whichpractice is based in structured systems analysisand structured design. It complements theSDLC. In the structured approach the termusers refers to people who will use the devel-oped IS. The structured concept emerged from software programmers’ search to improvethe quality of software for IS, which led to the notion of structure in software programs.Practitioners who wanted to improve the successof IS development introduced the structuredconcept in systems analysis and systems design. Its purpose is to organize or ‘structure’ know-ledge of system requirements through functionaldecomposition, rather than trust the processsolely to experienced and knowledgeable prac-titioners, as in the traditional approach.

3.5.1 The structured concept

The central premise in structured systemsanalysis and design is that greater structure andformalism based on the scientific method or theengineering metaphor improves the success ofIS. The structured knowledge is then used toinform practitioners’ action. It aims to produceconcise, unambiguous system specification andreduce data redundancy. This is achieved bymaking the IS development process thorough,formal and precise. Software programmers canthen use the system specification to implementrequired system functionality.

Concise system specification Systemspecifications were produced in the traditionalapproach. The difference in the structuredapproach is that the system specification isbased on a formal notation language. A

notation language enables precise and concisedefinition of the current and new IS in terms ofnotation that is common and communicable. Itis used to make systems models and draw updesigns.

Unambiguous specification The tradi-tional approach would often result in unclear orambiguous system specification. Ambiguous sys-tem specification meant that software program-mers often misinterpreted system requirementsand implemented unwanted system functionalityor missed required functionality. A prime causeof ambiguity in system specification is lack ofcommunication between analysts and users.Formal notation languages are intended to facil-itate the communication and so enable the production of unambiguous system specification.

Nonredundant The traditional approachwould often lead to systems design and imple-mentation that had much redundant data that produced inefficient use of computers.Inefficient use of computer processing and data storage made it costly to use computers.Formalism was introduced to reduce dataredundancy by objectifying data, data stores,dataflows and processes, usually in diagram-matic systems models. Analysis of the objecti-fied data reveals data duplications that can thenbe removed.

Thorough As the traditional approachrelied on the experience and knowledge of ISpractitioners, they made decisions about whento seek further information on the businessproblem and how to design and write the code.This practice led to arbitrary decisions aboutthe problem domain and system functionality.Through formal notation languages and theirsystematic usage, the structured approach aimsto reduce arbitrary systems design decisions andmake systems analysis and design a thoroughprocess.

The benefits claimed of structured analy-sis are that it produces a nonredundant,

64


unambiguous and complete specification, and aspecification that is maintainable. Its aim is toproduce a formal document normally called thesystem requirement document. This documentconsists of clients’ requirements, alternativesolutions available and costs, and the analyst’srecommendation for the most appropriatesolution.

Formalism underpins structured systemsanalysis and design. Formalism in structuredsystems analysis makes analysts’ tasks formal,prescribed and official. It is based on notationlanguages to develop systems models of a newIS. Structured analysis makes use of diagram-matic notations, and structured English, toprovide a common communication medium be-tween analysts and users, and between users andsoftware programmers and database admin-istrators. To develop systems models analystshave to consult people whose work is to bemodelled, so formalism ‘forces’ communicationbetween analysts and people.

As structured systems analysis and designclosely reflects the SDLC, it seeks to determinewhat the current organizational processes orsystems do and specify what a new IS shoulddo, and who will benefit from it.

Logical and physical systems modelsof the current system and a new IS are drawn instructured systems analysis and design. A logicalsystems model is a description of the actual situ-ation – problem domain – in terms of data andprocesses. Logical models are separated from thephysical computer implementation because theycontain no references to the means (physicalthings) for achieving the result. A physical sys-tems model is a description of the means forachieving the required result – computer imple-mented data and processes in a system.

The problem domain in structured analysisis characterized as business transactions data,dataflows, relations between data, processes andbusiness logic. These form the basic units of

analysis. Analysts develop current systems andnew system logical and physical models of theseunits. Logical and physical models are pro-duced of:

• data in entity-relationship diagrams;• process flows in data flow diagrams;• logic processes in process descriptions.

The purpose of structured systems design is tocreate a blueprint for a new IS that satisfies therequirements recorded in the system require-ments document, resulting from the systemsanalysis phase. Structured systems design willresult in systematic documentation of inputs,outputs, interfaces and systems processes. Thesystems design models are used as a communi-cation tool between analysts and software programmers.

Roles are created for people in structuredanalysis and design. It demarcates roles forpeople and describes the responsibilities foreach role as part of structuring the process ofIS development. The formalism in structuredanalysis encourages people in the problemdomain to be recognized during systems analy-sis. The important roles are:

• project manager• systems analyst• user.

The project manager is responsible for planningthe development of the IS, allocating humanresources to the planned tasks and for monitor-ing and controlling the system project. The pro-ject manager allocates appropriate resources,including analysts, to enable users and analyststo work together to determine system require-ments and specification. The project mana-ger is the main communication channel withsponsors of the project and senior businessmanagers.

111

0

11

0111

0

0

11p

65


The analyst’s task is to investigate the prob-lem domain to establish system requirements.They work closely with users to understand whatcurrent IS do and what a new IS is required todo. Both current IS and a new IS are docu-mented. Analysts develop a complete specifica-tion of a new IS by keeping a catalogue of data,its flow, and the transformations that happen todata, as data and process models. These analy-sis systems models are used as a communicationtool between the analyst and users to check correct requirements are recorded. Analystsmake use of instruments based on structured formalism to establish a system specification,which is then converted to modular structurecharts during systems design. These structurecharts are then transformed into structured programs in the implementation phase.

Users are involved during systems analysis toenable analysts to gather knowledge on theproblem domain. They are encouraged to takean active interest in changing the currentsystem, and it is assumed they are open tochange. They are also assumed to be accessibleand available to analysts for interviews anddiscussions to ascertain system requirementsand discuss developed systems models. Users are involved because it is assumed that theyknow, and can communicate, system require-ments and details of the business problem to beanalysed. It is further assumed that they canhelp to define clear and objective goals for anew IS.

3.6 The object-oriented concept

Structure certainly improved IS development,but critical practitioners recognized that it couldbe better. Object-orientation in systems analysisand design emerged from efforts to improve software programming in the early 1980s. Itsinitial focus was on the design of software pro-gramming languages to resolve coding or

programming inefficiencies. So object-orientedsystems analysis and design has links with object-oriented programming languages like Smalltalk.

Object-orientation is a set of concepts andideas on how to develop complex softwaresystems and IS, it is collectively called objecttechnology. Software objects are a representa-tion of things, actual or conceptual, in realsituations – human problems. The things orobjects may be conceptual or actual – businessinvoices or product orders, files, records,processes, suppliers, products or customers.

Object-orientation has spread to all theSDLC stages. Object technology is significantfor IS development and it is now a promin-ent approach to systems analysis and design.‘Object’ is the central concept on which prac-tice is based and encompasses the systemsanalysis, systems design and systems implemen-tation phases of the SDLC. Practitioners havedeveloped object-oriented systems analysis and design methodologies and instruments. Theseinclude Object-Oriented Analysis (OOA),Object Modelling Technology (OMT), Objec-tory, and Booch and Coad’s object-orientedmethodology. Object-oriented systems analysisand design is practised using instruments devel-oped by many practitioners. Among them aredynamic and static object-oriented models,state-transition diagrams, case scenarios andUnified Modelling Language (UML).

3.6.1 Object-oriented systems analysis

An object-oriented system is a set of related andinteracting objects organized into classes.Object-oriented systems analysis involves thedevelopment of integrated systems models that encompass functional, informational andbehavioural views of a new IS.

In object-oriented systems analysis and designthe problem domain is characterized as consist-ing of objects, relations, patterns, responsibilities

66


and scenarios. The data, relationships and pro-cesses in the problem domain are integrated intoone class model. Analysts’ tasks are to:

• find class-and-object• identify structures• identify subjects• define attributes• define services.

Analysts’ investigate the problem domain toidentify relevant objects, patterns, responsibili-ties and scenarios descriptive of a required newIS. Analysts identify and name relevant objectsand their responsibilities. An object’s responsi-bility is its attributes, relationships with otherobjects and the services it provides to otherobjects. An object can be business transactions,data or things that are relevant to completingbusiness objectives. It is an item for which dataneeds to be processed in a new IS. Analystsconsult with people, or users, to define dataobjects, their attributes, and the way in whichthe objects need to be interrogated or changed.Objects do not have to be created anew. Skilledanalysts are capable of software reuse, makinguse of existing objects from a library of objects.

Encapsulation is an important concept inobject systems ontology. Encapsulation is gath-ering of data and operations in an object. Anobject contains both the data and instructionson what needs to be done to process the data,or its operations. Analysts conduct an objectstructure analysis to analyse the structure of theobject types and an object behaviour analysis ofthe object types to define operations for objects.

As in structured analysis, project managers,users and analysts are involved in object-oriented analysis. Formalism is central inobject-oriented analysis too. Object systemsmodels are created with object notation lan-guages and these models are used to communi-cate with users and systems designers. As one

integrated systems class model is created, whichcontains analysis and design models, it makescommunication between analysts, users andsoftware programmers simpler. The same classmodel is progressively built through analysis,design, coding, testing and implementation.

3.7 Methods, techniques and tools

Methods, techniques, and tools – or instruments– are embodiments of system knowledge.Knowledge of organizations, people, applica-tion domains, IT, IS and design is representedin the instruments used to develop IS. Instru-ments available to investigate problem domainsand to create systems models depend on know-ledge and understanding of what constitutes IS.Automation, decision support and BPR exem-plify such knowledge, which has progressivelydetermined how IT is applied to organizations.Recent applications are eCommerce, eBusinessand the internet.

Practical system knowledge is acquired bydeveloping conceptual and theoretical know-ledge. In the absence of substantive theory insystems analysis and design, conceptual expla-nations determine practice. Concepts for phe-nomena like organizations and IS determinehow managers or analysts act. They also deter-mine the kinds of instruments devised to enablepractice. Concepts like hierarchical or flat struc-ture in organization theory and automation ordecision support in IS have influenced thedesign of organization and IS with appropriateinstruments.

An example of the relation between concep-tual knowledge and its practical embodiment insystems analysis and design is systems theory(section 2.6). The ideas of interrelated elements,communication and boundaries in systemstheory have influenced systems modelling tech-niques in structured and object-orientedsystems analyses.

111

0

11

0111

0

0

11p

67


3.7.1 Problem solving strategies

Behaviourist theories use previous experiencesas the unit of analysis to explain how peopleframe and solve problems, such theories areclassified as reproductive. It proposes thatpeople draw on previous experience to solve aproblem. The weakness in this explanation isthat previous experience can be a hindrance tofinding a solution in certain situations andpeople could ‘fixate’ around such experience.

The Gestalt theory of problem solving arosebecause of weaknesses in behaviourist theories.Gestalt theorists argue that people solve prob-lems through insight and structuring. Theproblem is first structured or framed and insightis important in the process. Such theories areclassified as productive.

Another problem-solving strategy is theGeneral Problem Solver Model. It is based onthe argument that there is a ‘space’ of problemsolving, in which a problem has various states.The problem-solver uses heuristics to frame theproblem and explore a solution.

IS problems can be divided into the two cat-egories of business problems and systems prob-lems. The various problem-solving strategiesare used to address both types of problems.Systems analysts help organizations and peopleto identify, describe, understand and definebusiness problems related to the application ofIT. They work with business analysts whose jobis to identify, investigate and resolve businessproblems. An example business problem is dis-satisfied customers or poor quality products.Often the initial business problem is experi-enced or identified by people in the businessarea and analysts work with business analysts toimprove the situation.

IS problems are concerned with how IT canbe applied to business problems. A businessorganization can benefit from supporting orintegrated IS. For example, IT can be applied

to the problem of improving customer service.Databases and relevant systems models can bedesigned to capture and process data on cus-tomer behaviour, and information on customerbehaviour can be provided to business decisionmakers.

Problem-solving is systems analysts’ majortask. Problem-solving is rooted in systems theoryand science. In science and systems theory aboundary is drawn around the problem andseparate elements identified to solve the prob-lem. Separating out elements makes it easier to solve individual elements, which are thencombined to solve the problem. This process is called reductionism, a process of isolating aproblem and breaking it down into simpler ele-ments that can each be analysed separately.

IS development is a problem-solving activ-ity. At a high level, the SDLC is an IS problem-solving method and methodologies are detailedplanned approaches to solving the problem ofdeveloping an IS. The SDLC phases can becompared with reductionism because the prob-lem is broken down into separate phases andeach phase is progressively resolved.

Different systems ontology advocates partic-ular problem-solving strategies. Structured sys-tems ontology emphasizes the functions a new IS needs to perform, and consequently focusesproblem-solving on identifying functions fromthe problem domain. Object-oriented systemsontology focuses on identifying classes, objectsand patterns. The Information Engineeringmethodology focuses on the information re-quired by business people, and so the focus is on the information or data in the problem domain.

The details of IS problems are addressed inthe phases of the SDCL. They concern decid-ing what systems models to design and how todesign them. Formalism is used to solve systemlevel problems. A formal problem-solvingstrategy may be distinguished from an ad hoc

68


approach that may lack a structure and varyeach time a similar problem arises. Mostformalism consists of diagramming techniquesthat express and structure knowledge about theproblem domain as graphical systems models.

The formal problem-solving strategy used instructured systems ontology is functional decom-position. It is based on scientific reductionism.Functional decomposition requires breaking aproblem down into smaller manageable prob-lems or components and solving each compo-nent of the problem separately. The separatesolutions are then combined to provide a com-plete solution for the whole problem. Functionaldecomposition results in treating business trans-action data and business processes separately todevelop data and process systems models.

The formal problem-solving strategy used in object systems ontology is classificationtheory. It regards the problem domain as con-sisting of human experience that can be classi-fied as objects and relations identified betweenthe set of objects or classes. The objects haveattributes and provide services to other objects,both of which need to be identified. This is aholistic view of the problem domain that treatsbusiness transaction data and business processesas integrated and leads to the development of an integrated systems class model. In object-oriented analysis classes, their definitions andattributes are relatively stable over time. A classonce identified usually remains constant insystems class model.

3.7.2 Notation languages

Problem-solving strategies rely on notation lan-guages to express, structure and manage theprocess of solving problems. Notations are for-malism and are used in systems analysis anddesign to develop systems models. A notationlanguage is a set of defined symbols to describe

and represent an IS problem. Some notationscover both business and IS problems. Problem-solving in systems analysis depends on thepower of notation languages to represent busi-ness problems.

The development of an IS involves organ-izations, people and IT. These elements cannotbe described precisely in a natural language likeEnglish. A notation language is used to repre-sent the problem domain as systems models. Itsprime purpose is to describe and represent theproblem domain and to enable manipulation ofthe notation symbols to determine an appro-priate resolution of the problem. Analysts canmanipulate the symbols until a desired solutionor required systems models are found.

The utility of a notation language is deter-mined by how well it can express (describe) theproblem domain and how accurately it can rep-resent it. Its power is in its notation symbols andin how they can be manipulated to resolve aproblem. The symbols should be sufficientenough to capture or represent elements of realsituations that interest the analyst and simple touse. The manipulability of symbols also shouldbe sufficient to arrange the symbols to achievea desired solution.

Notation symbols and their manipulabilitydetermine the kinds of IS problems that can beaddressed. Improvements in notation languagesenable more complex IS problems to be solved.An example early notation is a flowchart, usedto design computer programs and extended tosystems analysis. Flowcharts are limited to solv-ing logically sequential problems. In IS relianton databases the entity relationship notation isused to develop database models.

Data flow diagrams and process models instructured analysis separate out the elements ofa problem according to functional decompos-ition, whereas a problem domain is treatedholistically in object-oriented notations. In

111

0

11

0111

0

0

11p

69


object-oriented analysis notation languagesfocus on an integrated or holistic problem-solving strategy. The data and process in theproblem domain are viewed as a whole, and the problem is resolved holistically by develop-ing an integrated systems class model. The UMLis an example of an object-oriented notation.

3.7.3 Techniques and tools

Instruments make it possible to develop systemsmodels. Techniques are used to develop systemsmodels and tools are used to support theprocess. Prior to computer-based tools becom-ing available systems models were developedmanually with pencil, paper and notationtemplates. Both structured and object-orientedsystems analyses provide techniques to developsystems models and computer-based tools tosupport the process.

Structured techniques and tools

The practitioner-originators of structuredanalysis aimed to provide a systematic andstructured method for developing IS. Theydeveloped diagramming techniques for IS mod-elling and tools to support the development ofstipulated systems models. Figure 3.3 shows thedeployment of techniques within the SDLC.Many of the structured techniques are incor-porated into the SDLC. It provides structuredsystems modelling techniques across its majorphases.

Cost benefit analysis used during feasibilitystudy addresses business problems that assessthe benefits of investing in IT and developmentof IS, though it originates in financial account-ing practices. The entity relationship modellingtechnique is significant during the requirementsanalysis phase. It is used to identify things in theproblem domain for which data needs to be

captured, stored and processed. Consequently,related techniques like entity/event modellingand entity life histories are used to check forcompleteness and correctness of entities.

SSADM modules are feasibility study,requirements analysis, requirements specifica-tion, logical system specification and physicaldesign. Each module contains a number ofstages. The components of SSADM are: struc-tures, techniques and documentation. Structureis concerned with systematic and staged activ-ities, and the inputs and outputs required toperform them. Techniques is concerned withhow the staged activities are to be performed.Documentation is concerned with presentingthe products of the activities. SSADM makesuse of three techniques, logical data model-ling, data flow modelling and entity/eventmodelling. The systems models produced pro-vide three interdependent views of the problemdomain. The different systems models arechecked to ensure consistency, accuracy andcompleteness.

There are other structured techniques, listedin Table 3.1, that can be used to executeSSADM phases or used as part of other ISmethodologies.

70


Table 3.1 Structured systems analysis and designtechniques

Structured techniques

Data dictionaries

Decision tables/trees

Structured English

User/user role modelling

Function definition

Relational data analysis

Logical database process design

Update and enquiry update process models

111

0

11

0111

0

0

11p

Feas

ibili

tyst

udy:

det

aile

dst

udy

of t

heb

usin

ess

pro

ble

m a

ndp

oten

tial

solu

tions

Sys

tem

san

alys

isS

yste

ms

des

ign

Imp

lem

enta

tion

and

mai

nten

ance

Sys

tem

sin

vest

igat

ion

Bus

ines

s m

odel

s;m

anua

l sys

tem

sflo

wch

arts

; cos

tb

enef

it an

alys

is

Thes

e te

chni

que

ssu

pp

ort

seni

orb

usin

ess

man

ager

’sd

ecis

ion-

mak

ing

on a

pro

pos

edne

w IS

.

Inte

rfac

es; l

ogic

ald

ialo

gue

des

ign;

stru

ctur

e ch

arts

Thes

e te

chni

que

ssp

ecify

how

the

dat

a ne

eds

to b

ep

roce

ssed

by

the

new

IS.T

hey

det

ail t

he p

hysi

cal

mea

ns fo

rp

roce

ssin

g th

eca

ptu

red

dat

a.

Ent

ity-r

elat

ions

hip

mod

ellin

g;en

tity/

even

t m

odel

ling;

ent

ity li

fehi

stor

ies;

dat

aflo

w d

iagr

ams

Thes

e te

chni

que

s id

entif

y th

ings

in t

hep

rob

lem

dom

ain

for

whi

ch d

ata

need

sto

be

cap

ture

d, s

tore

d a

nd p

roce

ssed

.

Bus

ines

s op

por

tuni

ty o

r p

rob

lem

:d

issa

tisfie

d c

usto

mer

sIm

pro

ve c

usto

mer

ser

vice

New

cus

tom

erse

rvic

e sy

stem

Ad

ded

val

ue t

ob

usin

ess?

Bus

ines

s p

rob

lem

SD

LC

Str

uctu

red

tech

niq

ues

and

to

ols

Pos

t-im

ple

men

tatio

nre

view

Figu

re 3

.3S

truc

ture

d IS

mod

ellin

g te

chni

ques

wit

hin

SD

LC

pha

ses

71

Structured tools

Computer-Aided Software Engineering (CASE)tools are used to support the development ofsoftware. They were designed either to supportspecific steps in software programming or to actas generic support tools that could be chosen asrequired. They support analysts to build correctand integrated systems models. Correctnesshere refers to complying with the technicalstipulations of structured notations for systemsmodelling. They are mostly used for require-ments specification.

Horizontal integration CASE tools are usedto integrate the use of tools within the sameSDLC phase, for example within systems analy-sis or systems design. Such integration enablesmodels to share data and to be validated foraccuracy. Horizontally integrated CASE toolsare available for entity relationship modellingand dataflow diagramming. Database designand business process design tools are examplesof vertical integration CASE tools. Vertical inte-gration is the use of CASE tools to integrateadjacent SDLC phases, for example analysisand design.

A data dictionary is a fundamental conceptin structured analysis. It records all textual andnumeric information about a system thatcannot be captured in system diagrams. SomeCASE tools integrate data dictionaries with dia-grams to make checks for consistency easier.The quality of CASE tools to support SSADMhas been questioned, but there are diagrameditors and consistency checkers to improvequality of systems models.

Object-oriented techniques and tools

Object-oriented analysis and design providestechniques or strategies for finding objects in theproblem domain. Object-oriented techniquesare provided for many of the SDLC phases, asshown in Figure 3.4. The use case technique is

used to develop a high level model of the systemand its functional uses. The object class diagramis developed for both the existing system andnew IS.

Two techniques that are easy to understandintuitively make use of nouns and verbs insystems modelling. Analysts’ search for nounsor noun phrases in the Noun Phrase Strategy.Nouns or noun phrases identify an object forwhich data needs to be processed and opera-tions need to be coded. Example objects usingnouns are ‘invoice’, ‘department’ or ‘manager’.Analysts’ search for verbs or verb phrases in theClass-Responsibility-Collaboration (CRC) strat-egy. Verbs or verb phrases describe what theobject does, for example ‘compute’, ‘dispensecash’ or ‘print statement’.

There are other object-oriented techniquesthat can be used to execute SSADM phases or used as part of other IS methodologies.These are: sequence diagrams, transition dia-grams, event flow diagrams and collaborationdiagrams.

Object-oriented tools

Object-oriented tools are fundamentally differ-ent because they need to reflect a richer onto-logical knowledge of the problem domain.Compared with structured tools, object-orientedtools need to be capable of modelling semanticsin the problem domain. Object-oriented con-cepts such as object, attributes and servicesenable detailed semantics to be captured, so tools need to be capable of facilitating it.

There are horizontal integration and verti-cal integration CASE tools for object-orientedanalysis. They range from tools for browsers,debugging, configuration management andGUI builders. Comments about CASE toolsmade in the section on structured CASE toolsalso apply to object-orientation. The utility ofall tools is reduced after a certain point.

72


111

0

11

0111

0

0

11p

Feas

ibili

tyst

udy:

Det

aile

dst

udy

ofth

e b

usin

ess

pro

ble

m a

ndp

oten

tial

solu

tions

Sys

tem

san

alys

isS

yste

ms

des

ign

Imp

lem

enta

tion

and

mai

nten

ance

Pos

t-im

ple

men

tatio

nre

view

Sys

tem

sin

vest

igat

ion

Ob

ject

cla

ssd

iagr

am o

f new

syst

em

CA

SE

too

ls:

Rat

iona

l Ros

e,p

acka

ges,

sub

syst

ems,

mod

els

Cla

ss d

iagr

am a

nd o

bje

ct d

iagr

am,

obje

ct c

lass

dia

gram

of

exis

ting

syst

em, c

omp

onen

t d

iagr

am,

dep

loym

ent

dia

gram

Use

cas

e m

odel

, sce

nario

, and

use

cas

esc

ripts

; heu

ristic

ob

ject

iden

tific

atio

n

Seq

uenc

e d

iagr

am, a

ctiv

ity d

iagr

am,

colla

bor

atio

n d

iagr

am, s

tate

char

td

iagr

am

Str

uctu

red

Eng

lish,

dec

isio

nta

ble

s, d

ecis

ion

tree

s, s

tate

-tra

nsiti

ond

iagr

ams

Bus

ines

s op

por

tuni

ty o

r p

rob

lem

:d

issa

tisfie

d c

usto

mer

sIm

pro

ve c

usto

mer

ser

vice

New

cus

tom

erse

rvic

e sy

stem

Ad

ded

val

ue t

ob

usin

ess?

Bus

ines

sp

rob

lem

SD

LC

Ob

ject

-ori

ente

dte

chni

que

san

d t

oo

ls

Figu

re 3

.4O

bjec

t-or

ient

ed t

echn

ique

s w

ithi

n S

DL

C p

hase

s

Rational Rose is a CASE tool to support objectsystems modelling. It is used within UML.

CASE tools do not necessarily produce goodsystems models. The tools do improve the accu-racy and validity of systems models produced.Good systems models depend on the thorough-ness of the problem domain investigation.

3.8 IS methodologies

An IS methodology enables the articulation ofan IS problem and provides a staged process forIS development. A basic premise of methodolo-gies is that by following the stipulated stages theproblem domain system requirements can befulfilled. There are numerous methodologiesavailable all seeking to achieve this goal. Theauthors of methodologies are the government orits agencies, practising consultants or companieswho develop bespoke methodologies.

The British government’s use of IT led it to sponsor the development of SSADM in conjunction with the National ComputingCentre (NCC). Practising consultants devel-oped various methodologies including JacksonSystem Development ( JSD), Structured Ana-lysis, Design and Implementation of Inform-ation System (STRADIS), Yourdon SystemMethod, Information Engineering, and Coad’sobject-oriented methodology. STRADIS andYourdon System Method use the functionaldecomposition problem-solving method, thelatter focuses on data structures.

A methodology is underpinned by certainbeliefs and knowledge held by the methodologyauthors about human problems and systemsontology. A consideration of these beliefs isimportant for criticality and practical use of amethodology. Project managers need to under-stand the systems ontology of a methodology anddecide whether it is appropriate for the project.Analysts need to evaluate whether they agreewith the assumptions made and the consequent

systems ontology, and whether it is appropriatefor undertaking analysis.

A methodology normally contains all theSDLC phases, though some methodologiesomit the implementation phase and others donot make stringent demarcations. The charac-teristics of a methodology are similar to a plan,hence methodologies are referred to as detailedplans for developing IS. The significant formalpart of a methodology is that it contains sys-tematic, often sequential, phases and that eachphase delivers specific documents for the nextphase and the overall successful development ofa new IS. The result of each phase or output isreferred to as a deliverable.

All methodologies have a systems analysis andsystems design element. This may be a concretephase such as in SSADM or a quick process inte-grated with actual coding of computer programsas in ASD. In practical terms a methodology is acollection or package of techniques and tools forsystems analysis and systems design, and it alsoprescribes systems implementation.

Methodologies may be categorized as data-centric, process-centric, or object-oriented.Some methodologies focus systems analysis on data. Other methodologies focus systemsanalysis on processes and information. Object-oriented methodologies focus systems analysison identifying objects and their attributes, espe-cially relationships. Systems models in data-centric and process-centric methodologies needto be checked and integrated to provide a con-sistent systems model. The systems class modelin object-oriented methodologies is inherentlyintegrated.

Methodologies are normally executed withinsystems projects. In business a project is thepooling of required resources to achieve pre-determined objectives within predefined finan-cial resource and time constraints. Thedevelopment of an IS is referred to as a systemsdevelopment project or simply system project.

74


A system project provides a structure for boththe work to be done and the products to bedelivered. Project management techniques andtools are useful for organizing the workrequired. The structure in projects is the resultof plans formulated to identify work to be done,provide a schedule of the work, and to monitorand control the progress of the project.

3.8.1 Structured systems analysis anddesign method

SSADM is the UK government’s preferredmethodology. It was developed as a govern-ment initiative to seek efficiencies in IS projectsin the public sector, particularly to control costoverruns. Software vendors are required to useit when tendering for government contracts.SSADM focuses on data in the problem domainand the requirements of a new IS to developdata models and databases. It contains elabo-rate standards to which systems documentationmust comply.

The SSADM life cycle is shown in Figure3.5, techniques and tools used to produce deliv-erables are shown below the phases. SSADMepitomizes the structured approach. Its mainphases closely follow the SDLC phases andmake use of structured techniques and tools forsystems analysis and design. Both contain thefeasibility study, systems analysis and systemsdesign phases, but SSADM does not have theimplementation of the designed system and itspost-implementation evaluation phases.

SSADM is based on the structure concept.It stipulates tight rules and guidelines to whichproject managers have to adhere. It does notprovide systems project management tech-niques, so project managers use techniquesdrawn from the Project Management InChanging Environments (PRINCE) method.

SSADM concentrates on systems analysisand design. It focuses on the analysts’ activities

required to complete a feasibility study, require-ments analysis, requirements specification andlogical systems design. Systems analysis anddesign in SSADM is achieved with the aid offormalism and CASE tools.

A thorough or rigorous systems analysis anddesign is achieved on the basis of the ‘three-views’ of the system propounded in SSADM.The three views are: (a) the data in the system,(b) the business events to which the system mustrespond and (c) user defined functions of thesystem. Systems analysts are required to cross-reference analysis and design between thesethree views of the system to check the integrityof systems models. A significant criticism ofSSADM is that it produces much documenta-tion, and configuration management of docu-ments becomes problematic.

3.8.2 Jackson System Development

Many companies use JSD. It is a structuredsystems analysis and design methodology thatcomplements Jackson Structured Programming(JSP). JSP is widely used in practice too. Theproblem-solving strategy used in JSD is the top-down decomposition of the problem intosub-problems that are individually and sepa-rately solvable. Companies have adopted ver-sions of JSD that include the main phases of the SDLC.

The notion of an entity is important in JSD.An entity is something that exists in the realworld, which needs to be reflected in a new IS.In JSD an entity is defined as something that isunique and performs an action or it is affectedby action over time. For example, a customeris an entity that places an order at a certaintime, or an invoice is generated when an orderhas been fulfilled. JSD contain six steps:

• entity action• entity structure

111

0

11

0111

0

0

11p

75


Feas

ibili

tyS

tud

y:D

etai

led

stu

dy

of t

heb

usin

ess

pro

ble

m a

ndp

oten

tial

solu

tions

Sel

ecte

db

usin

ess

syst

em o

ptio

nre

qui

rem

ent

spec

ifica

tion

Logi

cal a

ndp

hysi

cal

syst

ems

des

ign

Req

uire

men

tsan

alys

is

Term

s of

refe

renc

e; d

efin

ep

rob

lem

; sel

ect

and

rev

iew

optio

ns; f

easi

bili

tyre

por

t

Def

ine

and

sel

ect

tech

nica

l sys

tem

optio

n; d

efin

ep

hysi

cal s

yste

m;

def

ine

user

inte

rfac

es; d

efin

eup

dat

e an

den

qui

ry;

pro

cess

es; l

ogic

ald

esig

n

Def

ine

scop

e;in

vest

igat

e cu

rren

tsy

stem

s; d

evel

oplo

gica

l mod

el;

def

ine

and

sel

ect

IS o

ptio

ns; d

efin

ere

qui

rem

ents

;us

ers

chec

kan

alys

is

Bus

ines

s op

por

tuni

ty o

r p

rob

lem

:d

issa

tisfie

d c

usto

mer

sIm

pro

ve c

usto

mer

ser

vice

New

cus

tom

erse

rvic

e sy

stem

Ad

ded

val

ue t

ob

usin

ess?

SS

AD

M d

oes

not

cont

ain

imp

lem

enta

tion

and

eva

luat

ion

pha

ses

Def

ine

syst

emp

roce

ssin

g;d

evel

op d

ata

mod

el; d

evel

opsp

ecifi

catio

n;p

roto

typ

e;es

tab

lish

syst

emob

ject

ives

;re

qui

rem

ents

spec

ifica

tion;

user

s ch

eck

spec

ifica

tion

Bus

ines

sp

rob

lem

SS

AD

M

Tec

hniq

ues

and

to

ols

Figu

re 3

.5S

SA

DM

pha

ses,

tec

hniq

ues

and

tool

s, a

nd d

eliv

erab

les

• initial model• function• system timing• implementation.

The development of systems models issignificant in JSD. Entities are identified andmodelled to show how they affect other entitiesor how they themselves are affected. The focuson entities is claimed to produce a flexible ISthat can be readily enhanced or amended tomeet changing business needs. Systems analysisand design is regarded as an extension of soft-ware development that leads onto JSP.

Project managers do not have a significantrole in JSD because of its emphasis on systemlevel analysis and design. The identification ofentities and development of models is under-taken by analysts who use formal structureddiagramming techniques to develop systemsmodels. The diagramming techniques are: JSD structure diagram, JSD system specifica-tion diagram, JSD structure text and systemsimplementation diagram.

3.8.3 Open Source Software

OSS is not a methodology like SSADM or JSD.It is included here because it is being recognizedas an acceptable method for developing soft-ware, both for government and commercialcompanies.

OSS is software whose source code is opento the public. It is often developed by voluntaryefforts and is usually available at no charge. Itis used under a licence defined by the OpenSource Initiative (OSI), which prevents theopen source produced software from beingredistributed under licenses that contravene theOSI ethos. OSS is now a significant source forindustrial-strength software for many kinds ofsoftware applications ranging from the Linus

operating system to the Oracle and Informixdatabase systems, and Word Perfect and Corelword-processing package and office suite.

It is not clear whether OSS is a methodology.The importance of OSS is recognized by theUK government that initially encouraged thedevelopment of SSADM, which subsequentlybecome a benchmark. The UK government’s e-Government Interoperability Framework (e-GIF) mandates open standards and specifica-tions. The UK government’s policy on OSSincludes the use of OSS solutions in IT pro-curements. It will only use products for inter-operable systems that support the OSI in futuresystems applications. Government supportedresearch and development will also make use ofOSS as the default software. OSS is a funda-mental change in the way software is developedand the UK government is developing policiesto recognize its importance in the marketplaceand for government contracts. The EuropeanCommission (EC) too promotes the use of OSSin the public sector and e-government bestpractice.

The role of project managers and systemsanalysts in OSS is unclear. Though the roles ofproject managers and systems analysts in OSSwill not be redundant, it is unclear what pre-cisely they would do. Software programmersdevelop most open source software. Theybecome intensely interested in the actual pro-gramming problem, sometimes because theythemselves make use of the software productand would like to make improvements to it forpersonal use. The use of OSS in an organiza-tion would certainly require analysis of theproblem domain.

3.8.4 Coad’s object-orientedmethodology

Coad’s object-oriented methodology focuses ondata, behaviour and functions of objects. The

111

0

11

0111

0

0

11p

77


aim is to develop one integrated class systemsmodel of function, information and behaviour.A single integrated class systems model does notrequire ‘balancing’ or other elaborate checkingacross models, as required in structured analy-sis. The purpose of the integrated class modelis to develop consistent and accurate systemsmodels. Coad’s object-oriented methodologyconsists of four activities:

• Identify system purpose and features.• Identify model component’s objects and pat-

terns, for each of the model components:– problem domain;– human interaction;– data management;– system interaction.

• Establish object responsibilities.• Define service scenarios.

The purpose of identifying objects and patternsin the problem domain and the system is to finddata objects and define the behaviour of theobjects. The purpose of the third activity is toestablish object responsibilities by identifyingthe functions required of the system and thedata objects that need to be captured, processedor stored, and the behaviour needed to com-plete the responsibilities and services of theidentified objects. The purpose of the fourthactivity is to determine the services to beprovided by the objects.

Project managers have flexibility to deter-mine how the methodology should be prac-ticed. It allows parallelism, substitution andomission. A project manager can perform theactivities in parallel if the problem domainpermits. The sequence in which activities areperformed may be changed or substituted bythe project manager when the problem domainpermits. The project manager may decide toomit one or more of the activities if the problemdomain permits.

Analysts’ task is to execute the four activities.Whether the activities are completed in thesequence stated in the methodology depends onthe project manager’s decisions concerning par-allelism, substitution and omission. An analystusing an object-oriented methodology needs tobe able to understand how to identify objectsand the role of the one integrated class systemsmodel.

3.8.5 Prototyping

Prototyping is a popular Rapid ApplicationDevelopment (RAD) approach. Prototyping isa methodology but it does not make stringentdemarcations in the process of IS development.It does not divide the process into discretephases based on the SDLC. The aim of proto-typing is to reduce the phases and the time ittakes to develop an IS, and to involve closelyclients in development. By not demarcating theprocess into phases prototyping seeks to reducethe time it takes to develop a system.

Prototyping actively involves clients in theproblem domain to elicit system requirements.A system is developed quickly and installed foruse in the problem domain. People’s usage ofthe system generates evaluation and feedbackon the system’s functionality, user interfaces andinformation for developers. Developers use thisfeedback to enhance the prototype system.

Prototyping varies the SDLC phases movingfrom analysis, to building, and seeking clientscomments on developed prototypes. There area variety of prototyping strategies:

• Incremental prototyping where the proto-type eventually becomes the operationalsystem.

• Throwaway prototyping where the system isa mock-up to obtain feedback.

• Cooperative prototyping involves clientsactively in the design of the prototype.

78


The role of systems analysts is to determine aninitial set of system requirements and work withsoftware programmers to develop a prototype.Clients are not usually consulted on the initialrequirements and are not involved in the designof the initial prototype. Analysts then work withclients to evaluate the system by performingcertain tasks with the prototype system. Theresults of the evaluation are recorded as part ofthe requirements document and used toenhance the prototype.

The role of project managers in prototypingvaries depending on the size of the prototypeand type of prototyping strategy adopted. Theyperform the normal systems project manage-ment tasks if the prototype is organization-wide.

3.9 Interpreting concept and actionin the Critical Framework

IS knowledge and IS development knowledgeare continuously progressing. There is no formaltheoretical knowledge on IS development. TheSDLC is the fundamental conceptual andformal body of knowledge. It prescribes how todevelop an IS. It constitutes a formalisticapproach to IS development. Notions of opti-mality and the universal application of instru-ments underpin its systems ontology. The SLDCis the basis for most research and practice in ISdevelopment. SSADM, and other methodolo-gies, are based on the SDLC.

The Critical Framework can be used toanalyse critically concepts and practice insystems analysis and design. Fundamental con-cepts like the SDLC, structured analysis andobject-orientation, and methodologies, consti-tute knowledge. The actual practice or imple-mentation of this knowledge can be analyticallyevaluated with the Critical Framework.

Figure 3.6 is the Critical Framework popu-lated with critical reflection on the conceptualbasis and practice of systems analysis and design.As the bottom layer shows, many questions con-

cerning the four themes of criticality arise fromassumptions of objective and rational humanbehaviour in systems ontology. These questionsrelate to transformatory critique, refashioning oftraditions, reflexivity and critical skills.

For example, in terms of reflexivity, analystsuse the term ‘users’ or ‘user organization’. Theterm has implications for knowledge and prac-tice. Some researchers do not consider it to bean appropriate term to describe people inorganizations. For many decades the term fore-closed ‘users’ to participate in IS development.It also had to be qualified because of techno-logical development in ‘end-user computing’that enables people in organizations to developIS themselves. Patel (2003) has coined the term ‘action developers’ to describe people inorganizations capable of tailoring IS to theirparticular needs.

The SDLC seeks optimal solutions. Criticalevaluation of the SDLC systems ontologyreveals that optimality assumes perfect informa-tion will be available to make decisions aboutthe human problem. Such information is rarelyavailable in practice. Similarly, instruments areunderpinned by ontological assumptions. TheSDLC assumption of rational organization andhumans leads to instruments that producesystems models that are optimal and measur-able. An optimum situation is where the bestpossible results are achieved, which is usuallydeflected by other factors in the ‘messy world’.

To internalize knowledge and develop prac-tice of the SDLC, analysts would need to acceptcertain kinds of personal constructs. Based onknowledge from the systems ontology theme,they need personal constructs that fit the objec-tivist ontology of the SDLC. For example, ananalyst would need to develop an ‘objective’ pre-disposition given the SDLC’s assumption that theworld is objective. So, an analyst would need tobe detached and impartial, and analyse an actualsituation with detachment and impartiality.

111

0

11

0111

0

0

11p

79


The actual inclusion of the objectivity per-sonal construct in a PCF should be based oncritically evaluating its relevance for practice.The actual situation will reveal that people haveself-interest and egos that will make them

behave in a subjective and partisan manner.Analysts too need to question their self-interestsand biases. A series of questions will arise thatwill lead to evaluating critically the objectiv-ity personal construct and its validity in real

80


Apply formalmethods


(Messy world)

Organizations, people;information systems,

information technology

Systemsontology

SDLC

SDLC assumes thathuman behaviour is

rational and informationis available

Formalism, system,sub-systems, control,

coordinated behaviour,‘user’

Fixed, optimal,predictable, efficient,effective, measurable,

engineered (systems andinformation)

Pragmaticresolution

Problems with optimumand change

???


Apply assumption ofrational humans and

organizations –does it work?

Develop knowledge

Objective epistemologyassumes human and

organizational behaviouris rational or economic

perfect knowledge


Resolveproblems


What is rationality?Objectivity is important,

but how can it be realizedin the messy world?

Can ‘users’ be involvedin development?


Is the world objective?Are humans rational?

Is organizationalbehaviour rational?

Is perfect knowledgeavailable?

Critical skills

Use the Delphi techniqueto be objective; helppeople to objectivity

Figure 3.6 Critical framework: the ontology of the SDLC

situations. These may include: How is theanalyst to be objective in such a situation? If asystems analyst makes a design decision that isnot favoured by some people, will they loseinterest in the IS development? The analystwould then evaluate whether to include theobjectivity personal construct in a PCF, orwhether it should be practiced selectively.

3.9.1 Considering sub-themes

The SDLC can be further analysed and evalu-ated in terms of planned action and situatedaction sub-themes. Objectification of personalconstructs can be made clearer by consideringthese sub-themes to understand the SDLCsystems ontology and its relevance in real situ-ations. The analyst can then consider whetherto develop personal constructs based onplanned action or situated action.

Systems ontology knowledge is often couchedin planning terminology in IS development.Knowledge about IS development problems andof how to overcome them is devised as appro-priate instruments deployed in the context ofplans or methodologies. The SDLC may becharacterized as planned action, since it has sys-tematic phases: requirements analysis, data andprocess modelling, and data and interfacedesigns, determining system functionality, andactually implementing the designs using IT.

The requirement for an analyst to be objec-tive necessitates planning, for example wheneliciting requirements. The analyst’s plan ofactivities may not be possible to implement inan actual situation. There may be limits on howmuch time people can give or required docu-ments may not be available. The analyst’s planwould then need to be changed, however re-planning may result in a similar situation.Alternatively, the analyst could choose to takesituated action. People who are accessible canbe interviewed and documents that areavailable can be studied.

3.9.2 Objectivity and modelling

The SDLC, structured and object-orientedsystems ontology assumes an objective problemdomain in which analysts themselves canbehave rationally. Objectivity is a problemat-ical assumption in systems ontology. It hasimplications for both knowledge developmentand praxis. The premise that humans behaverationally leads to the expectation that analystsare capable of applying rational instruments inan objective and detached manner.

Analysts expect people in organizations tobehave rationally because of their training instructured or object-oriented methods. Theyoften find that people do not meet their expec-tation, which ironically leads them to seek short-comings in the people or application domainrather than reflect on and evaluate theirassumed knowledge.

Analysts can analytically evaluate the SDLCsystems ontology to develop personal constructson objectivity, and the design of objective,unambiguous and complete systems modelsrequired in structured analysis. Analysts wouldthen evaluate whether to include objective sys-tems modelling personal construct in their PCF.

A model is an abstract representation todescribe and explain reality – organization,people, IS and IT. It is used to understandactual human problem situations. The devel-opment of systems models is central in theSDLC, in which the tenet of objectivity affectsthe type of systems models developed. Its objec-tive systems ontology assumes that an analystcan create objective, unambiguous and com-plete systems models. Analysts are expected toremain detached and impartial in the processof designing systems models.

The fundamental premise of the SDLC,structured, and object-oriented analyses is thathuman behaviour in organizations is economicor rational. This basic premise encounters prob-lems when it is applied in real human problems.

111

0

11

0111

0

0

11p

81


Human behaviour normally, but especially inan organizational setting, is influenced by socialand political factors that question the premiseof rational behaviour. Such analytical evalua-tion and interpretation of knowledge and prac-tice in terms of the Critical Framework willenable an appreciation that the actual practiceof IS development is not a wholly rational,objective phenomenon.

3.9.3 Pragmatism

During the 1990s the new IS conceptions werebased on Business Process Re-engineering(BPR). Analysts in consultation with peopledeveloped systems models of existing organiza-tion, processes and workflows. They were thenanalysed to create alternative, radically differ-ent process models that took advantage of IT.Analysts and business analysts questioned andanalysed business processes to seek out ineffi-ciencies and improve effectiveness. The newsystems models aimed to redesign or ‘re-engi-neer’ organization and improve productivity.

Systems models are created with formalnotations and diagramming techniques. Theassertion that notations provide a common lan-guage with which analysts can communicatewith each other, and with project managers,software programmers or database administra-tors. The models created with formal notationsare also used to communicate with people.These assertions can be evaluated. In structuredsystems analysis the models are of data andprocesses, and in object-oriented analysis themodels depict classes and relations. Complexsystems models are difficult for users to under-stand, and even analysts find them difficult tointerpret. Such confused models are subse-quently implemented using IT.

Authors of methodologies do not attempt toexplain and elaborate assumed systems ontologyor epistemology. Analysts can learn much aboutpraxis from them, but little on how to develop

criticality. The questions that arise in develop-ing a new IS require critical thinking. TheSDLC, structured methods, and object-orientedmethods and IS methodologies are someresponses to these questions but they are mostlyprescriptive. Though the knowledge may betechnically sound, its usefulness in practicedepends on its application limits in real humanproblem situations, where organizations andpeople matter the most.

There is a close relation between writingcomputer programs and performing systemsanalysis and design. Problems in software devel-opment have led to solutions that have foundrelevance in systems ontology. Knowledge onhow to develop computer programs has influ-enced knowledge on how to conduct systemsanalysis and design. Structured programmingknow-how resulted in structured analysis anddesign. The emergence of object-oriented pro-gramming has led to object-oriented systemsanalysis and design. The recent interest in agileor eXtreme programming is driving a method-ological systems analysis and design. Thissynergy may be regarded as inherent becausesystems analysis and design is conducted toinform software development.

Structured methods, techniques and toolsarose from the problems that the US militaryand space exploration organizations encoun-tered in applying digital computers to achievetheir aims. Military and space software devel-opers looked to engineers to learn how toproduce robust software, of good quality andreliability and acceptable to clients. Adoptingthe engineering analogy lead to the term soft-ware engineering to describe the disciplineddevelopment of software. The engineeringanalogy has persisted ever since in softwaredevelopment and was extended to developers ofcommercial software applications.

Knowledge of systems analysis and designhas to be enacted in real situations. Despite the

82


progress in IS concepts, instruments andmethodologies, the perennial IS developmentproblems of unmet requirements and cost over-runs still persist. Reflective analysts need toexplain why the problems still exist. Argumentsfor further progress or better adherence to stan-dards do not resolve or explain the problems.Better knowledge and understanding of organ-ization and people, IT and IS, and how theserelate in the application domain is needed.Better elaboration of systems ontology isneeded. An explanation of how these relate toontological understanding of organizations andpeople is required. Inclusive epistemologies,capable of investigating organization andpeople, need to be accepted.

Mechanistic conceptions and definitions ofdata and information are simplistic for devel-oping appropriate systems ontology for IS.Human experience of data and information is phenomenological, which IT is presentlyunable to reflect. Organizational knowledgeand knowledge management in particular posesignificant problems. Knowledge managementsystems based on algorithmic conceptions ofknowledge have been unable to facilitate orimprove knowledge generation and sharing.The notion of semantic data and information,particularly reflected in XML for the web,provide the necessary human dimensionrequired to contextualize information. Similarconceptions are necessary in systems analysisand design.

3.9.4 Planned action and situated action

The planned action and situated action sub-themes are particularly relevant for criticallyevaluating concepts and practice. It is informa-tive to consider analytically the SDLC, struc-tured and object-oriented systems ontology,methodologies and problem-solving in terms ofplanned action and situated action.

Figure 3.6 illustrates the practical problemswhen objectivity underpins systems ontology.Objectivity and rationality suggests a plannedand predictable reality. Planned action is thebasis of structured systems analysis and designand in some versions of object-oriented systemsanalysis and design. Entities in structured analy-sis and objects in object-oriented analysis arepresumed to exist, and analysts’ task is to dis-cover them to develop systems models.Characterizing systems analysis and design assuch objective, planned action is questionablebecause it negates contexts, and it negatesemergent organization – things organizationsand people have to respond to that cannot beplanned or predicted.

Project managers deploy methodologies asproject plans that detail the resources requiredand the work to be done. So it is possible tolabel IS development as planned action. Todevelop a critical perspective planned actionand situated action will be differentiated in thecontext of knowledge and practice.

The SDLC

The SDLC is structured IS development. Itconsists of conceptions of IS and instruments for systems modelling. Its basic premise is thathumans and organizations behave rationally.This premise translates into a planning per-spective, with systematic phases in the SDLCcharacterized as a form of planned action.Project managers develop sophisticated plansdetailing systems analysis, design and program-ming work packages and the resources requiredto complete them.

Though the SDLC is shown in Figure 3.2 assequential, phased activities, it has various ver-sions. These versions have resulted fromaddressing gaps in a prevalent version. The‘waterfall model’ version was added because inpractice developers need to go back to previousphases. An ‘iterative’ version was developed to

111

0

11

0111

0

0

11p

83


enable developers to work across two or morephases to fill informational gaps in previousphases. A ‘spiral’ version was developed todiffuse risk analysis and enable verification andtesting throughout the phases. In previous ver-sions risk was not considered or verification andtesting were carried out too late to contributeto successful completion.

Analysts are expected to deploy the SDLCobjectively and systematically within projectplans. The premise of objectivity has led to thedesign of instruments that fail to recognize thenon-rational aspects of human and organiza-tional behaviour – namely, politics, culture,limits on knowledge and communication gaps.The actual practice of systems analysis requiresanalysts to consider situated factors. Analystshave to account for the limitations of people’sability to state system requirements. They haveto consider whether people are capable of envi-sioning a new IS or how it might relate to thework they do. These are situated factors thatcannot be accounted for in plans.

Techniques and tools

It is assumed in structured and object-orientedsystems ontology that instruments enable thedevelopment of correct systems models. Proponentsof structured techniques and tools make variousclaims. For example, that instruments providebetter project control and communication, theymeet people’s requirements and can cater forchanging requirements.

CASE tools are used to document systemsanalysis and design activity and function as com-munication aids. They are used to communicatesystems models between analysts and program-mers and project managers. Contentiously, it isalso claimed that CASE tools are useful to com-municate between analysts and user too. Thereis no verification of this claim.

Though CASE tools are meant to achievecorrectness of systems models, the consistency

and accuracy of integrated models has not beenachieved. Use of vertical CASE tools in struc-tured methodologies that separate data and func-tion modelling has not led to successful technicalvalidation of integrated models. Object-orientedCASE tools have not matched developments instructured methods and techniques.

Instruments alone are not sufficient for devel-oping appropriate systems models. The formal-ism in structured analysis and design encouragespeople in the problem domain to be acknow-ledged in systems analysis. They are encouragedto participate in the development process butthey have severe technical limitations. Primeamong them is lack of knowledge to read tech-nical systems diagrams or systems models.

Appropriate systems design is the result ofthorough investigation and the validity of theassumptions made of the problem domain.Limitations can be determined by examiningontological assumptions. Structured and object-oriented analyses have techniques and tools thatassume an objective problem domain that canbe impartially investigated. Often analysts findpeople have interests and attach subjectivemeaning to the work they do which makes theinstruments ineffective.

Methodologies

A methodology is normally more than simplepackaging of instruments for developing IS.Critical analysis reveals that methodologiescontain philosophical assumptions and ontolog-ical beliefs that influence the type of IS andinstruments developed. Methodologies harbourassumptions about the nature of systems, instru-ments, IS, people and organizations that heavilyinfluences conceptions of IS and how IS aredeveloped. They prescribe the role of potentialusers. Significantly, they embody hidden epis-temological method which affects the contribu-tions the IS makes to the achievement of humanand organizational purpose.

84


Structured and object-oriented methodolo-gies assume ‘things of interest’ pre-exist. Ana-lysts have to simply identify them for systemsmodelling. JSD and Coad’s object-orientedmethodology presume that entities and objectsexist in human problems. The analysts’ task isto establish objectively what these entities areand develop systems models. They are requiredto identify entities and objects from people,business processes, and documents and to estab-lish their importance and relevance for systemsmodelling. The actual process though is moreinvolved. Analysts have to rely on people, whohave subjective interests, in the organization toname entities and objects and to establish theirimportance and relevance. This reliance revealsthe social dimension of IS, and necessitates con-sideration of power relations in organizations,and in IS development.

A methodology is packaged as a set of instruc-tions for practitioners. JSD or Coad’s object-orientation methods prescribe to IS developershow to develop IS. The phases of SSADM pre-scribe what project managers and systems ana-lysts should do. Significantly, methodologicalprescriptions cause analysts to expect organ-izations and people to behave in prescribedways. Actual implementation of methodologicalprescriptions tests the objectivity and planningassumptions and the prescribed expectations.Consequently, most practitioners do not deploya methodology because it binds them to plannedaction that contradicts the problem domain.They find that the actual behaviour of peopleand events in the organization are not suscepti-ble to objective and systematic analysis, and theexpectations raised by methodology remainunfulfilled.

At the core of a methodology is the beliefthat the required or intended future can becreated. Systems analysis and design is con-cerned with creating a socio-technological

future, where work and organization depend onor are integrated with IT and IS. The future isoften concerned with strategic thinking.Consequently, systems analysis has strategic sig-nificance. Most thinking and action on thefuture is based on planning.

Planning itself is problematical, but theassumptions underpinning development of afuture with plans are more problematical to rec-oncile with actual situations – human problems.Planning assumes it is possible to predict thefuture in that the planned future can be real-ized. There are obvious limitations to humancapability to predict. Another assumption inplanning is that the actual conditions underwhich the plan is to be executed will remainconstant, or as explicitly or implicitly assumedin the plan, to be successfully implemented.Actual conditions invariably do not complywith assumptions of the plan. So project man-agers have to continually adjust budgets,resources and timescales accordingly.

Some methodologists propose methodologyas a form of inquiry or epistemology. For thema methodology is a method for investigating theproblem domain to discover knowledge. Thetechniques and tools used for modelling act asinstruments for investigating the problemdomain and recording findings. Analysts shouldcritically evaluate epistemological assumptionsin systems ontology to understand their effecton knowledge and practice. Structured analysisand design affects organization by delivering ISbased on objectivity. A new IS affects the veryorganization for which it is developed. Thefuture and the present organization are intri-cately tied. This effect is most prominent inBPR and eCommerce.

Problem-solving

Both structured and object-oriented systemsontology assume that IS development problems

111

0

11

0111

0

0

11p

85


can be addressed objectively. Consequently,they characterize problem-solving as reduc-tionism – the decomposition of a problem intosmaller, manageable elements. The decomposi-tion of a problem leads to compartmentaliza-tion of organization and people’s work, whereasorganization is designed to function as a whole.

Objective systems ontology separates outpeople from the actual problem domain. Mean-ings that people attach to their actions are notmodelled in structured or object-oriented sys-tem ontology. In structured systems ontologydetached analysts carry out the identification ofentities, and though entities can be people, as incustomer or employee, the actual customer oremployee is not consulted for their subjectiveperception. Similarly, in object-oriented analysisobjects can be customers or employees but theactual people are not consulted for their views.The development of use case models in object-oriented analysis, though modelling the users,does not involve the actual people, or considerthe meanings they attach to information.

Problem-solving in IS development largelyignores the social context. IS may be defined asa medium of social communication in organ-ization. People rely on information to attachimportance to their action. Trial and error typeof problem-solving, also called ‘exponentiallearning’, is often used in social contexts. It issupported by prior formal analysis. Structuredand object-oriented systems ontology does notrecognize such social contexts and problem-solving strategies.

Problem-solving cannot be de-contextualizedfrom politics. Project managers, analysts, pro-grammers and users’ roles depicted in structuredsystems ontology are simplistic. Stakeholderresearch in organizational initiatives and inno-vations reveals political factors in IS develop-ment. Stakeholders are individuals or groupswho have a particular interest in what happensin the organization. Structured and object-

oriented systems ontology do not explicitlyrecognize stakeholder politics in IS develop-ment. Critical theory assumes politics and con-flict in systems ontology, but it is not recognizedin dominant problem-solving strategies used inpractice.

When the above issues are factored into ISdevelopment, objective problem-solving orplanned action becomes problematical in prac-tice. Structured and object-oriented systemsontology make assumptions about organizationand people that need to be critically evaluated.In structured systems ontology terminology,‘users’ are involved so that systems analysts canestablish knowledge about the ‘problemdomain’. Users are needed to define clear andobjective goals for a new IS. They assume thata clear communication channel is open betweenusers and IS developers. Assumptions on users capability to be objective, have completeknowledge of their situations, and be able toarticulate it are not tested.

Structured and object-oriented systemsontology assume that users know and can communicate details of the business problem. In structured systems ontology, users are en-couraged to take an active interest in changingthe current system and are assumed to be opento change. They are also assumed to be accessi-ble and available to systems analysts for inter-views and discussions on developed systemsmodels. Peoples’ interest, resistance or fear is not explicitly considered in structured or object-oriented systems modelling.

3.9.5 Information Systems and theapplication domain

System ontological knowledge lacks both under-standing and formal knowledge on how to dealwith complex application domains. Analystsneed personal constructs and techniques tounderstand the application domain. Such

86


knowledge will supplement analysts’ technicalknowledge, design relevant IS, and devise effective instruments.

A system-centric perspective on systemsanalysis and design fails to acknowledge organ-ization and people – the application domain. Its systems ontology focuses on the ‘system’ tobe developed, rather than the human, social,political and organizational factors. Con-sequently, its instruments are designed to model systemic knowledge only. Structured and object-oriented systems ontology are bothsystem-centric because prescribed instrumentsfocus on the functionality of a new IS.

Analysts need to consider personal con-structs to account for socially constructed real-ities and evaluate whether structured andobject-oriented systems ontology are capable ofdealing with it. Structured and object-orientedanalyses define IS in systemic, technical terms.They assumed that such definitions are not onlytechnically correct, but presume that they aresocially relevant. These assumptions are onlyinternally validated in systems ontology becauseof the assumption of an objective reality.Technical definitions based on an assumedobjective reality do not consider what an ISmeans to people and organizations from a socialor individual perspective. There is no attemptat externally validating correctness or relevance.

A technical definition is different from asocial perspective. Objective technical defini-tions do not admit a socially constructed reality.They do not allow that reality, or IS, can beconstructed subjectively by people. In sociallyconstructed realities, definitions of data, infor-mation and knowledge depend on what peoplemake of them. Structured systems ontology does not allow for subjective meaning in IS.Object systems ontology implicitly is capable ofenabling subjectively constructed realities, butmethodologies like Coad’s object-orientedmethod do not provide explicit instruments to

develop systems models of socially constructedrealities.

The systems ontology for both structured andobject-oriented analyses does not sufficientlyaccount for the multifarious application domain.Its assumptions need to be analytically evaluated.The term ‘problem domain’ itself indicates a sys-tem-centric perspective of IS. It is the label todescribe individuals, groups, human collabora-tion and communication, and information, orga-nizational knowledge, and much more, where IT is to be applied. A system-centric perspectiveneglects the relation between the computer-based IS and the human organization. Many ofthe limitations and problems with structured systems ontology arise because the rich applica-tion domain is not sufficiently reflected in theavailable systems analysis instruments.

The application domain is composed ofmany factors that make it difficult for analyststo deploy systemic instruments. Table 3.2 showssome of the constituents of the applicationdomain. Each of these factors, and others, poseproblems for system-centric analysis and design.

Understanding the relationship between anew IS and its environment is critical for its suc-cessful development. It is more critical for ISusage. The complex application domaindepicted in Table 3.2 is not adequately factoredinto systems project management, the softwaredevelopment process, the project plan and itsexecution or the type of system required.Analysts should conduct an analytical assess-ment of why IS may lack relevance for ‘users’in terms of systems ontology and its applicationin real situations.

People in organizations work and communi-cate with each other in a social context, inwhich information is exchanged to enable organ-izational tasks to be completed. Politics, powerand informal dealings are characteristic of the work and communication. These factors are not accounted for in structured and

111

0

11

0111

0

0

11p

87


objected-oriented systems ontology. Power, pol-itics and informal dealings are not consideredin the planning phase of systems project man-agement, which assumes a sanitized problemdomain. The application domain is composedof stakeholders who have an interest in a newIS. They range from high-ranking senior

managers to departmental managers whoseprocesses are affected by a new IS development.

An analyst is also a constituent of the appli-cation domain. The premise of analysts’ ratio-nal behaviour in objective systems ontologybecomes weaker when it is realized that systemsanalysts’ have a powerful role relative to the role

88


Table 3.2 Constituents of the application domain

Constituents of the Description Effect on Information Systemapplication domain

Individuals People in the organization Individuals use IS to complete employed to work to achieve work tasks and organizational business objectives. processes.

Groups People in the organization who Groups use IS to coordinate work together to achieve business collaborative work and to objectives. communicate information.

Business Individuals or groups who make Demands on IS for information decision-making decisions concerning strategy or and knowledge to enable

resources. decision-making.

Business processes Sets of activities that combine IS transform, enable and individuals, groups and IS designed support business processes.to achieve business objectives.

Organization Individuals, groups, goals and There is a bi-directional boundary within which business relationship between organization processes are designed to achieve and IS. Organization affects business objectives. types of IS and their functionality

and IS affect organization design.

Social context Social, cultural and political IS (system) is expected to factors in the organization. The function in the social context.human element of IS.

Business The postures and moves of rival New demands on information competition firms to gain larger share of the and knowledge, and IT

market. support for business processes and radical strategic change.

Stakeholders Individuals or groups with an Powerful stakeholders can interest in a new IS development influence IS development. If project. neglected they can reduce its

chances of success.

Systems analysts Individuals and groups who Analysts determine the scope investigate all the above to design and functionality of IS.IS that add value.

IT infrastructure Other IS that process data, Necessitate interfaces and (computer systems, information and knowledge. interoperability with other IS.internet)

of potential users in IS development based onthe SDLC and related methodologies. Theirpower stems from their technical knowledge.Potential users of IS are not capable of under-standing technical knowledge and cannot enterinto a meaningful dialogue, perhaps arisingfrom conflict with analysts.

There is no attempt at formal modelling instructured systems analysis of the applicationdomain as discussed above. It focuses on dataand processes. In object-oriented analysis, mod-elling notation is available to model potentialusers of a new IS. Use case models are devel-oped to show potential users and their func-tional interaction with the IS, but the socialdepth of such modelling is superficial.


3.10.1 Personal constructs for systems

Activity A

Table 3.3 is a sample repertory grid for systemsontology. Reproduce the grid on a spreadsheetand add further columns and their polar oppo-sites that you consider relevant. To objectifypersonal constructs in systems, complete the

grid by following the details on how to use arepertory grid in section 1.10.1.

3.10.2 Planned and situated action

Questions

1 Discuss whether the SDLC can be charac-terized as planned action.

2 Evaluate the value that the situated actionconcept can add to systems analysis anddesign.

3.10.3 IS development

Questions

1 Appraise the role of standards in IS devel-opment. What practical relevance do stan-dards have, as provided in SSADM forexample?

2 Critically discuss whether adding ‘structure’to the IS development process bridges theknowledge and communications gap betweenanalysts and users.

3 Select a methodology and critically evaluateits future enhancement strategy – how it canbe adapted for future needs. Do systemsmodels based on the methodology providefor flexibility once implemented?

111

0

11

0111

0

0

11p

89

Table 3.3 Personal constructs for systems

Pole 1 Method Technique Tools Methodology Problem Problem- Pole 2domain solving

Formal Informal

Boundary No boundary

Control No control

Structure Unstructured

Problem Solution

Practical Unpractical


Activity A

• Consider the systems ontology and realworld of human problems components of theCritical Framework.

• Identify an IS familiar to you and examineits systems ontology.

• Describe the actual situation in which it isused. What aspects of the actual situation arenot reflected in the systems ontology?

• How is the effectiveness of the systemaffected by lacking factors you identified inthe actual situation?

3.10.4 Conceptual basis of systemsanalysis and design

Questions

1 Discuss whether the assertion that structuredtechniques tend to lack context is valid.Detail reasons why you think they are preva-lent in practice.

2 Evaluate the relevance for practitioners ofalternative methodologies, for exampleETHICS, that cater for the social context of IS.

3 Appraise the relevance of the concept of‘structure’ in SSADM and ‘object’ in Coad’sobject-oriented methodology for real humanproblem situations.

Activity A

Work with your peers to compare the tradi-tional, structured and object-orientation con-cepts for IS development. Discuss whichapproach you would include in your PCF.What assumptions of organization, people, andIS developers, including analysts, does theapproach you select make?


Question

You may want to read Chapter 9. Comparestructured system and object-oriented tech-niques and tools and analyse how they:

• characterize the problem domain;• differ on what they consider of interest in the

problem domain;• apply, effectively, the techniques;• explain which set of techniques you would

use.

Activity A

Structured systems ontology. In structuredsystems analysis and design the problemdomain is assumed to be composed of businesstransactions data, dataflows, relations betweendata, and processes. These form the basic unitsof analysis. Either individually or in groups:

• Select a system that is familiar to you – astudent records system or a mobile-phonebilling system.

• Make a list of factors in the applicationdomain of the system you have chosen thatwould not be accounted for by structuredsystems ontology.

• In developing systems models how wouldyou cater for these factors?

Activity B

Object-oriented systems ontology. In object-oriented systems analysis and design, an ana-lyst’s task is to identify relevant objects, patterns,responsibilities and scenarios for a new IS.Objects can be transactions data, things andpeople for which data needs to be processed.Individually or in groups:

90


• Select a system that is familiar to you – abank personal current account system oronline shopping system.

• Make a list of factors in the applicationdomain of the system that would not beaccounted for by object-oriented analysis.

• How would you account for these factors ina class systems model?

3.10.6 Notation languages

For this sub-section you may want to refer toChapters 7, 8 and 9.

Questions

1 Detail three critical flaws that you think existin a structured notation language of yourchoice. How would you overcome thesewhen developing systems models?

2 Detail three critical flaws that you think existin an object-oriented notation language ofyour choice. How would you overcome thesewhen developing systems models?

Activity A

Choose either an object-oriented or structurednotation language you would use to conductsystems analysis. How did you decide whichnotation language to use? Make a list with twocolumns, one for aspects of the notation lan-guage that are sufficient for describing theproblem domain and the other for aspects ofthe problem domain that the notation languagedoes not cater. Identify and discuss the assump-tions of the notation language in terms of itssystems ontology.

Activity B

Individually or in groups, choose a structured orobject-oriented notation language (you may usethe selection from Activity A). Discuss among

yourselves whether the notation language is suf-ficient to describe a problem domain. Make alist of its limitations and discuss how you wouldovercome them in practice.

Activity C

Notation languages are problem-solving devices.How important is it to enable refinement of thenotation language for effective systems analysisand design? Individually or in groups, choose astructured or object-oriented notation language(you may use the selection from Activity A) andrecommend at least three refinements to make itmore effective in practice.

3.10.7 IS methodologies

Questions

Choose one or more from the selection belowand discuss:

1 JSD is oriented towards software systems andnot organization and people.

2 The author of JSD regards systems analysisand design as an extension of JSP.

3 JSD is highly structured which means thatorganization and people issues are not con-sidered.

4 JSD does not consider project selection, costjustification, requirements analysis, projectmanagement, user interface and proceduredesign or user participation.

Activity A

Choose a methodology to include in your PCF.Make a list with two columns, one for aspectsof the methodology that are sufficient for devel-oping an IS and the other for aspects of theproblem domain that the methodology does notcater. Discuss the systems ontology it assumes.

111

0

11

0111

0

0

11p

91


Activity B

A methodology may be regarded as a tool forgathering knowledge for IS development.Methodologies like JSD and Coad’s object-oriented methodology assume objective know-

ledge. In groups, choose one methodology anddiscuss how it develops knowledge about IS andthe problem domain that analysts can use todevelop systems models. Discuss whether it isnecessary to make the distinction betweenobjective and subjective system knowledge.

92



For seminal work of socio-technical approaches to Information System development see:Mumford, E. (1983) Designing Human Information Computer Systems for New Technology, The ETHICS

Method, Manchester: Manchester Business School.

A revised and updated edition is: Mumford, E. (1993) ‘The Participation of User in IS Design:an Account of the Origin, Evolution, and Use of the ETHICS Method’, in Douglas, S. andNamoka, A. (eds) Participatory Design, Principles and Practice, London: Lawrence Erlbaum Associates,pp. 257–270.

Eva, M. (1994) SSADM Version 4: a User’s Guide (2nd edn), London: MacGrawHill.

For the original work on combining Soft System Methodology and the SDLC to account for theapplication domain see: Wood-Harper, A. T. and Avison, D. E. (1990) Multiview: an Exploration in

Information System Development, Oxford: Blackwell Scientific.


Details of the object-oriented CASE tool Rational Rose can be found at http://www.rational.com.

Search the web for CASE tools for structured and object-oriented analyses. Choose CASE toolsfor systems analysis and justify your choice in terms of IS development, systems ontology, problem-solving and fit with methodologies. The Oracle site at http://www.oracle.com is a good sourcefor information on CASE tools.

4.2 Introduction

Systems project management is the systematicmanagement of a process of technological andorganizational change. It is central in IS devel-opment because it brings together the people,process and technology required for IS devel-

opment. A system project has predeterminedobjectives, limited monetary budget, finitehuman resources and predetermined comple-tion date. Consequently, project managersrequire broad knowledge in project manage-ment techniques and tools, the psychology ofteams and organizational change management.

111

0

11

0111

0

0

11p

93

Chapter 4

Systems project management



• Explain the key elements of a system project and the ways in which projects can beorganized to relate to business objectives and strategy.

• Evaluate and select appropriate systems project management techniques for eachphase of a project, justify their appropriateness, and apply them to practicalsituations.

• Evaluate and critique the limitations of traditional systems project management inthe context of modern business organization and emerging approaches to ISdevelopment.

• Critique the major assumptions of systems project management and explain (a) whythey may be inappropriate in the context of IS development and (b) how the state-of-the-art might be improved.

• Formulate a business case for a new IS development project.

These learning outcomes will provide knowledge of systems project management andenable you to be critical of system projects and project management. Practitioners developan IS as systems project management in business contexts, in which systems analysis,design and systems analysts have a significant role.

This chapter will cover the phases and basictechniques of project management. It willpresent knowledge of project management anddiscuss the issues and challenges that projectmanagers encounter in practice. The manage-ment aspect covers planning, monitoring andcontrolling the process of software develop-ment. An understanding of traditional systemsproject management provides basic knowledgeof the phases of project management. Whetherprojects should form the foundation of IS devel-opment will be critically considered in terms ofthe Critical Framework. Assumptions on plan-ning that underpin systems project manage-ment will be critically considered to contributeto PCF development.

4.3 IS development project

A business project is a programme of businessor organizational change management. It is adevice used to innovate a product or service, ormake significant change to organizational struc-ture and processes. A project is used to organ-ize and coordinate human effort to achievespecific objectives that the business thinks willresult in a superior product or service to com-pete with other firms. The innovation and intro-duction of a new product to the market, themerger of two companies and restructuring acompany are examples of business projects.Businesses often need to change strategic direc-tion or operational organization, usually inresponse to markets or competitors. This in-volves large expenditure of time and human andmonetary resources that need to be managedefficiently to ensure successful completion.

A system project encompasses the conceptu-alization, analysis, design, implementation anddelivery of an IS. It assumes an objective realityand rational human behaviour. An IS is nor-mally developed as a business-cum-softwaredevelopment project, drawing on business

project management knowledge. Softwaredevelopers use the business project concept, itstechniques and tools, to develop IS because theprocess of developing software can be disci-plined and standardized. System projectsprovide the discipline required to conceive andmanage IS development within financial andtemporal limits, and usually as part of a businesschange programme.

A system project is used to define and man-age business and organizational change involv-ing IT and IS. A system project has specificobjectives that define the required system out-come. A timescale is determined in which thespecific objectives need to be completed, this isknown as the start date and end date of the pro-ject. Project managers, systems analysts and pro-grammer resources are allocated to make theplanned change happen. The elements andcharacteristics of a system project are:

• Setting of specific objectives to define aproject.

• A specific timescale that defines start dateand end date for a project.

• Specific and finite resources allocated toachieve project objectives.

• No significant prior experience of similarprojects.

• Management of allocated resources toachieve project objectives.

A system project enables a business through dis-ciplined management to complete major orga-nizational change programmes involving ITand development of IS within allocated timeand resource constraints. System projects areused to plan, monitor and control systematicallythe activities of analysts, programmers andothers involved. Time and monetary resourceconstraints, including human resources, can beorganized better and managed as a systemproject. System projects can be small with one

94


to two people and lasting less than one personyear, medium with four to ten people andlasting one to twenty person years, anythingmore than that is a large system project.

As a significant element of an IS is software,its quality determines the efficiency and effec-tiveness of the delivered IS. System projects areused to meet and improve quality standards.Software needs to be of a certain standard toensure it is fit for purpose and meets therequirements of its users. Standards are nor-mally set by formal bodies to ensure superiorquality is achieved. Examples of standards andstandards bodies for software development are Constructive Cost Model (CoCoMo),Capability Maturity Model (CMM) andSPICE. These standards are designed toimprove the software development process andconsequently the resultant software system.

Systems project managers need sophisticatedtechnical and management skills. Softwaredevelopment skills need to be complementedwith knowledge and the skilful practice ofproject management. They need to put intopractice interpersonal and communication skillsin the context of organization, organizationculture, stakeholders and politics to realizeproject objectives successfully. Systems projectmanagers are required to produce systematicand detailed plans of how software will be pro-duced. They are responsible for monitoring the successful completion of planned activities,and taking appropriate action to control anydeviances from the project plan. These aremanagement activities in the project and con-stitute a significant part of project managers’work involving the allocation of financial andhuman resources.

4.3.1 Plans and projects

In systems project management, planning is theformal basis for decision-making, organizing

and allocating resources. The resources used inIS development are systematically planned andallocated to predetermined tasks or work pack-ages designed to achieve project objectives.Techniques are available to plan the work to bedone, estimate and schedule budgets and work,monitor and control the work in progress, assessand manage risk and ensure quality standardsare met.

Objective systems ontology, for example theSDLC and SSADM, has a natural synergy withprojects and rational planning. The phases ofthe SDLC or SSADM are executed within thebounds of a project’s time and resources limi-tations. Project management techniques andtools enable actual planning of tasks to deter-mine software requirements and development.Start-to-end or end-to-end work planningtechniques are used to organize and manageavailable resources.

4.4 The business case

Monetary investment in IT and IS is determinedon the basis of the value it will add to a company.A proposal for a new IS is normally assessed as abusiness case, focusing on its contribution toachieving business strategy and objectives.Senior management are interested in determin-ing benefits of investing. Some considerationsinclude reducing operating costs, improvingquality of goods or services, better customer relationship management and improving in-formation and knowledge for operational anddecision-making purposes. These considerationsand others are shown in Table 4.1.

In the SDLC a business case for an IS is madein the feasibility phase. Analysts are involved inidentifying and selecting IS to develop. Theyhave a significant role in formulating a businesscase and work with project managers to identifybusiness areas that would benefit from the application of IT. They determine strategies

111

0

11

0111

0

0

11p

95

................................................................................................Chapter 4 Systems project management

and frameworks for identifying candidate sys-tem projects and evaluate them by selectingappropriate techniques.

4.4.1 Types of Information Systems

The type of system project is determined by thetype of IS to be developed. Analysts work ondifferent types of IS development projects. Thetypes are based on what they contribute toimprovements in managerial decisions, automa-tion of operations and procedures, or definitionof new business models. The types in businessorganizations include:

• eCommerce systems;• Knowledge Management systems;• Enterprise Resource Planning systems;• Supply Chain Management systems;• Customer Relationship Management systems.• Decisions Support systems (including Execu-

tive IS);• Accounting and Financial Management

systems;• Expert systems.

Analysts involvement in formulating a busi-ness case will normally depend on particulartypes of IS. They may work alone or in groups

to make a business case for decision supportsystems or functional accounting systems. Theywould normally work with managers and seniorexecutives to make a business case for customerrelationship management systems or knowledgemanagement systems.

eCommerce systems require a special busi-ness case, which is normally supported with abusiness model. Business analysts, executivesand analysts work together to define a businessmodel, often radically different from existingoperations and business processes. Business ana-lysts contribute knowledge of business and oper-ational issues and systems analysts contributeknowledge of IT to the business modellingprocess.

4.5 Project management

Project management is the planning and organ-ization of resources to achieve project objec-tives. A typical system project requires the management of scope, timescales and resources.They are related because an increase in work –scope – necessitates more resources and time.Project managers plan and organize resourcesand work into distinct phases. Each phase makesa particular contribution to the completion of a project.

96


Table 4.1 Drivers for IT/IS investment

Reasons for IT/IS investment

Reduce operating costs

Improve operational efficiency and productivity

Modernize or innovate operations

Improve competitiveness

Provide superior quality information for operational and executive decision making

Introduce a new business model, for example the internet and eCommerce

Improve knowledge management

4.5.1 Prime project roles andresponsibilities

A project has roles and responsibilities, exam-ples are shown in Table 4.2. A project manageris responsible for all the resources available tothe project, including human and financialresources, and works closely with senior systemsanalysts and senior systems designers to deter-mine allocation of budget, systems analysts,designers and software programmers.

The role of users and stakeholders is signifi-cant because it affects the success of a new IS.They are not responsible for determiningsystem requirements, but for analysts they arethe prime source for gathering system require-ments. Their representatives on a systemproject form part of the user groups that workclosely with the project manager and analysts.

Project managers need a variety of skills. Theability to plan, monitor and control a projectare basic necessary skills. Beyond basic skills, aproject manager needs to be aware of thecontext of the project and how people and

events in it affect the project. For example, acontextual factor like additional system require-ments will have an impact on the availableresources. A skilled project manager developsan awareness of how the context affects aproject and is capable of negotiating andmanaging resources accordingly.

Additional skills are required dependent onthe uniqueness or originality of the project, itssize, complexity and how it relates to the busi-ness and the market in which the business oper-ates. An IS that has not been developed beforewill necessarily be more difficult to developbecause it is not possible to rely on prior know-ledge. A large IS compared with a small onewill be more difficult to develop because theplanned change will be more widespread, andit will require the skilful management of greaterresources. The type of IS will determine howcomplex it is to develop. IS that are integratedinto the business will require additional systemsdesign features. Each of these factors also has asignificant impact on whether a project isregarded a success or a failure.

111

0

11

0111

0

0

11p

97

Table 4.2 System project roles and responsibilities

Project role Responsibility

Sponsor or project champion The person or group who want the project to proceed. Theyprovide the project aims and objectives, and organize othernecessary organizational support.

Project manager The person or group responsible for managing the availableproject resources.

Potential users and stakeholders People who will make use of the developed system. They will beinvolved in determining what the system is required to do and intesting modules of the system.

Senior systems analyst An experienced systems analyst who works closely with theproject manager to ensure the systems analysis work is completedto the required quality standard.

Senior systems designer An experienced software designer who works closely with theproject manager and senior systems analyst to ensure thatsystems designs are implemented.


4.5.2 Project stakeholders andstakeholder analysis

A stakeholder is any person, group or organ-ization, internal or external to the organization,that has an interest in the IS to be developed.Example stakeholders are the project sponsor,banks providing capital, suppliers and contractorganizations, the client organization, analysisand design groups and individuals.

Obvious stakeholders can be identified rela-tively easily depending on the type of IS to bedeveloped. A project sponsor or groups whosework will be affected by the system are obviousstakeholders. For more complex IS other stake-holders may not be so obvious. A project man-ager needs to conduct careful and detailed stake-holder analysis to ensure success. Stakeholderanalysis is particularly significant for projects thatare important for achieving business strategy and objectives. It involves the identification ofstakeholders and stakeholder mapping.

To identify stakeholders, who may be criti-cal for the success of a project, a projectmanager needs to conduct a formal stakeholderanalysis. It will reveal the relative importance,influence, power and impact of stakeholders.This will involve examining values, beliefs andassumptions held by various stakeholders andhow they attempt to influence each other todetermine project outcomes.

Formal matrices for stakeholder analysis areavailable. Some of these metrics measure vari-ables such as the power, predictability or inter-est of stakeholders. A project manager would usethe metrics to understand key stakeholders andassess their importance for the success of a pro-ject. This can help project managers to deter-mine what management approach to deploy anddecide where to focus political effort.

People whose work will be affected by a newIS will be interested in knowing how their jobswill change. They may be fearful that a new IS

will make their jobs redundant or that job rolemay be made trivial or uninteresting. Managersof departments or sections will be interested inknowing how a new IS will help them achievedepartmental objectives. They will want toknow whether it will produce efficiency gainsand cost reductions.

A project manager and other IS developersare also stakeholders. An unsuccessful projectwill mar a project manager’s record, so projectmanagers will be interested in achieving suc-cessful completion of a project. Software pro-grammers will be interested in developingworking computer programs from given systemrequirements.

Systems analysts themselves will be inter-ested in developing relevant systems modelsthat meet the approval of managers and peoplewhose work will be affected. Analysts work withdifferent project stakeholders on various aspectsof a project. They work closely with managersand people whose work will be affected by anew IS to elicit requirements. They communi-cate developed systems models to software programmers.

4.5.3 Human factors and teams

Human factors in the project team are theproject manager, senior analysts, senior design-ers, software programmers, systems analysts,and systems designers and other technical andmanagerial people. (For their roles and respon-sibilities see section 4.5.1.) Human factorsinclude relationships with project sponsors andchampions and their psychological character-istics. These aspects are important because they determine how individuals work in aproject team and the effectiveness of teams.Appropriate individual and group or socialpsychological characteristics are important foran effective team. Human factors encompassleadership, motivation, and teams.

98


Leadership

A project manager’s role as manager and leaderis critical in determining success. A projectmanager has to manage both the resourcesavailable and lead a project team to achieveproject objectives. Management involves plan-ning, monitoring and controlling of resources,but leadership requires motivating and inspir-ing team members to want to complete aproject successfully. The ability to influenceteam members and stakeholders is a criticalskill. Combined with competence in manage-ment, leadership ability and political skills arefactors that influence others to respect theproject manager and commit themselves tosuccess.

The action-centred leadership model andthe situational model of leadership are formalmodels of leadership. The action-centred modelproposes that a leader’s effectiveness in a teamdepends on three factors: the need to achievethe task, the need for team maintenance, andthe individual needs of team members. Ratherthan make the distinction between managementand leadership, the action-centred modelfocuses on the interrelationships between thethree functions of task, team coherence, andindividual needs, and the project manager’sability to satisfy them.

The situational model of leadership focuseson the tasks to be completed and relationshipsto be formed and maintained. It is a behav-ioural model that integrates well the manage-ment and leadership behaviour of a projectmanager. Task behaviour is concerned withhow well a project manager (the leader) is ableto set goals and define roles for team members,and provide direction to individuals and groups.Direction is critical for success. Relationshipbehaviour is concerned with how well theleader communicates, listens and providessupport for the team and individual members.

Encouraging individuals and the team is asignificant aspect of relationship behaviour. Themodel defines four levels of individual and teamdevelopment based on the permutations of indi-vidual team members’ competence and willing-ness to complete tasks. These permutationsaffect the kind of leadership styles that theleader would need to deploy, spanning over theparent, coach, developer and driver types ofmanagement.

Motivation

Motivating individual team members and theteam is a significant issue in systems projectmanagement. A project manager would norm-ally be aware of motivational issues and attemptto address deficiencies in individuals’ and teammotivation. An effective leader with effectivemanagement skills will be aware of how torecognize motivation levels and take action to raise motivation.

Theories of motivation explain how willingan individual or a group is to increase theireffort to take part in and complete a task. Theyrelate to organization and how they lead toimprove the performance of individuals andgroups. They focus on how such involvementsatisfies particular needs of individuals andteams. A distinction is made between motivesand needs in the theories, both of which areinternal to an individual. An individual’smotives affect their needs and the actions theytake to achieve them.

Theories of motivation explain the level ofmotivation in terms of content, process or re-inforcement. Maslow’s hierarchy of needs andHertzberg’s dual-factor theory are content the-ories. They take the individual as the subject andfocus on the relationship between individualneeds and the reward individuals get for doingwork. Their basic premise is that individualsgenerate needs that increase their motivation to

111

0

11

0111

0

0

11p

99


satisfy the needs. In system project terms, a pro-ject manager then provides monetary or in-kindrewards or offers challenging tasks that eitherincrease or decrease job satisfaction, which inturn is a motivational factor.

Process theories are concerned with how theprocess of motivation can be developed. It canbe based on either individual’s consideration ofequitable return for the effort they put intowork, or a consideration of the expected returnfor effort put into work. Equity theories arebased on how individuals compare their workand reward with others. The comparison ofwork and the return they get determines theirlevel of motivation based on how equitable theyperceive the reward. In theoretical terms, indi-viduals generate a ratio of work done andreward received and compare this ratio withothers’ ratio. An equitable ratio will lead to jobsatisfaction and increased motivation and aninequitable ratio will lead to dissatisfaction anddemotivation.

The expectancy theory of work is based onthe premise that individuals make informed andrational decisions about how much work effortthey should make. The decision to do work isbased on whether the individual possesses theability to do the task and whether the expectedeffort will be noticed and rewarded or not.

While no single theory of motivation willsuffice there are likely to be elements of truthin each one. A project manager can pick ele-ments to design job roles, work and rewardstructures that lead to increased motivation inindividual team members and the team.

Project team

Project teams consist of project managers,systems analysts, business analysts, softwareprogrammers, database administrators andsystems professionals, and representatives ofuser groups. A system project is normally

regarded as work done in a team. Individualmembers of a team need to be able to work witheach other and individually. Working in a teamrequires interpersonal and communicationskills. An individual’s self perception is animportant aspect of team and project success.

There are various metrics that can be usedto assess the predisposition of an individual andtheir ability to work in teams. A questionnairedesigned by Belbin is often used by projectmanagers to determine characteristics of indi-vidual project members. It focuses on how anindividual would describe himself or herself inteam situations and provides a self-perceptioninventory analysis sheet that records individualself-perception in team situations. It also classi-fies the types of individual who could be part ofa team according to the potential contributions.These types are:

• coordinator (chair)• shaper• innovator (plant)• monitor/evaluator• resource investigator• implementer (company worker)• team worker• completer/finisher• specialist.

A project manager may not rely solely on suchan assessment, but it does help to provide onemeasure to base decisions on whether to includean individual in a project team.

4.5.4 Techniques and tools

A project manager relies on planning tech-niques and tools to determine what work needsto be done, when it should be done by and whatresources will be required to do it. They enablea project manager to conduct an analysis of thework to be done and an analysis of the nature

100


of the product that will result from a project.Objectifying the work to be done and theproduct are both critically important forsuccess. Some examples of project planningtechniques available to project managers arelisted in Table 4.3.

The tools to support the techniques includesoftware packages for project planning.Software support tools are available for plan-ning precedence networks and activity-on-arrow networks, though the former are morepopular and widely available. Some projectplanning tool examples are WBS Chart Pro forplanning work breakdown structure and PERTChart Expert.

4.5.5 Quality and risk management

Quality and risk management are necessaryand important. Rather than being discreteproject management activity, they are a con-tinuous activity with overall responsibility

resting with a project manager. The standardof IS developed and the process of softwaredevelopment are incorporated in quality assur-ance. Quality assurance can be based on one ofmany approaches and frameworks available.

Quality may be regarded as an absolute orrelative measure in software system. Unlike cer-tain consumer products, the quality of IS is dif-ficult to define in absolute terms. A softwaresystem is considered to be of quality if it con-forms to client’s requirements. This measure ofquality is problematic because it assumes thatclient requirements can be completely captured.There are problems with establishing require-ments that the conformance measure of qualitydoes not address. The concept of ‘client’ is vagueas various stakeholders within an organizationcan be said to be clients too. The determinationof actual requirements is also difficult in practicebecause clients often add new requirements.

The definition of quality is importantbecause the agreed measure will determine

111

0

11

0111

0

0

11p

101

Table 4.3 Project planning techniques

Technique Description

Work breakdown structure A project planning technique to define work packages required tocomplete a project. Also known as the means necessary to achieveproject objectives.

Product breakdown structure A project planning technique to define the results of work done. Alsoknown as the results or ends.

Precedence networks Precedence networks are used to schedule work packages asactivities and resources. The technique is used to manage the limitedtime available on a project.

Activity-on-arrow networks Activity-on-arrow networks can also be used to schedule workpackages. They depict the work packages in a different form toprecedence networks.

PERT Program evaluation and review technique (PERT) produces chartsthat depict task, duration and dependency information. A network isproduced to show connecting nodes, lines and floats.

Gantt Chart Gantt Charts are a visual graphical form for depicting workpackages against a timescale. They show the sequence of the workpackages, important milestones and floats.


whether a project is deemed successful or not.A project manager needs to be aware of differ-ing measures. Quality defined in absolute terms,such as executable software performance orpercentage downtime, will be easier to quantifyand measure. However, the subjective elementof IS is often a significant block in regarding itas successful or as a quality product. Clientsmay raise objections concerning the ‘quality ofinformation’ or lack of its timeliness. Such sub-jective objections make it difficult to identifyand measure quality in IS.

There are approaches for improving the soft-ware development process. Though CoCoMo is a technique for estimating resources requiredto complete work packages and cost estima-tion, it may also be used to improve quality of the software development process. CMM isspecifically designed to improve the softwareprocess. The Software Engineering Institute(SEI) at Carnegie Mellon University originatedthe model with the aim of improving the soft-ware process in organizations. It is shown inFigure 4.2 section 4.6.1 with its five stages ofsoftware process improvement.

Risk management

Risk is the gap between what is the expectedresult of effort and the actual outcome in thefuture. Undesirable events that may happen ina system project which require action to betaken to prevent them from happening. Riskmanagement is the management of such uncer-tainty in a system project. It is effort spent toavoid undesirable outcomes. Uncertainties needto be identified and managed to mitigate theirimpact on the successful completion of a project.Risk management is associated with the idea ofcontingency measures or planning for unfore-seen or unpredictable events. Contingency plan-ning is an integrated aspect of project planningand is derived from the main planning effort.

Critically, work breakdown structure andestimation can be used to identify and managehigh-risk parts of a system project. An exampleof risk is unrealistic or poor estimation ofresources and time required to complete workpackages. The judgement on risk is based onmeasurable quantities and the level of confi-dence a project manager has of them. If confi-dence is low then there is a high risk, if it is highthen there is low risk.

A risk management plan is drawn by identi-fying risks, assessing their impact on the projectand its objectives, planning responses andtaking action to reduce the risk from occurring.The identification of risk results in compiling arisk register for the project that shows the cat-egories of risks. The risk register contains all theidentified risks. The project objectives are com-pared with identified risks in the risk register toassess impact and deploy appropriate response.

A project manager needs to be able to judgethe likelihood of a particular risk occurring. Itis the ability to judge occurrence of risk and itsimpact on project objectives that is importantin risk management. This assessment is thenused to draw the risk management plan thatcontains the necessary action required to reducethe impact of the risk on a project. The riskmanagement plan will contain action to eitheravoid risk or mitigate risk. For some types ofrisk, action can be taken to avoid it. Forexample, a known shortage of programmingskills can be avoided by hiring the right people.Other types of risk cannot be avoided, so actionis taken to mitigate its impact on the projectobjectives. For example, a particular systemsanalysis work package overrunning its allocatedtime.

The actual assessment of risk can be basedon a basic scale, or more sophisticated and com-prehensive methods. At a basic level the occur-rence of risk may be assessed as simplecategories of ‘high’, ‘medium’ or ‘low’. The

102


consequent impact would be ‘small’, ‘moder-ate’, or ‘large’. This kind of measure is subjec-tive and open to wide interpretation. Detailedmetrics are more comprehensive and provide amore objective measure, including probabilities.

4.5.6 Work and product breakdownstructures

A system project needs to be managed to ensureefficient and effective use of limited availableresources. A project manager has to determinesystem requirements and organize humanresources and work. The relation between dif-ferent packages of work needs to be determinedand scheduled. This is achieved by using thework breakdown and product breakdown planning techniques.

Work and product breakdown structures areanalyses techniques to plan, monitor andcontrol work. Breakdown structures enabledetailed definition of necessary work to be doneand its management in well-defined packages.In terms of resource allocation, breakdownstructures enable more accurate estimation ofresources required to complete work packages.

Work breakdown structure and productbreakdown structure are related in terms ofmeans–ends analysis. Work breakdown struc-ture is an analysis of the work required or themeans, and product breakdown structure is ananalysis of the results or the ends. Work break-down structure enables a project manager todefine what work needs to be done and deter-mine how the required work packages arerelated. Product breakdown structure enables aproject manager to determine what tangibleproducts will result from the work packages.

The relation between work packages result-ing from work breakdown structure is termeddependencies. Work packages can be logicallylinked to determine whether a particular workpackage is dependent on one or more other

work package. For example, during systemsanalysis system requirements specification de-pends on requirements determination and can-not begin until requirements determination iscompleted. When one activity can only beginwhen another is completed a dependency exists.There are various types of dependencies:

End-to-start exists when one activity cannotbegin until one or more other activities arecompleted. For example, process modelling instructured systems analysis cannot begin untildata modelling is completed.

End-to-end exists when one or more activi-ties can overlap. For example, in object-orientedsystems analysis investigation of classes forsystems design, user interfaces for instance, can begin before systems analysis is completed.Start-to-start exists when one or more activitiescan overlap. The same example for end-to-startapplies. Start-to-end completes the logical possi-bilities but is rarely evident in practice.

Project networks

Work packages, dependencies and schedule oftime and work can be depicted graphically inproject networks. Two examples of project net-works are precedence networks (also calledactivity-on-node) and activity-on-arrow net-works. Precedence networks are popular in soft-ware tools for planning project networks. Theyare also simpler than activity-on-arrow net-works. An example precedence network isshown in Figure 4.1.

The precedence network is an example ofrequirements analysis. It shows interviews, doc-ument analysis, and current IS analysis. It alsoshows the development of mock-up user inter-faces to help ‘users’ visualize the envisaged IS.Analysts would show the prototypes to users and record comments they make. These would then be used when consolidating the gatheredrequirements before writing the requirements

111

0

11

0111

0

0

11p

103


report. The precedence network shows severalimportant elements for drawing a project net-work. These elements are listed and describedin Table 4.4.

4.5.7 Estimation and schedules

A pragmatic management activity is to estimatethe time and resources and to schedule the work required to meet project objectives. Aproject manager uses the time and resource esti-mates and work schedules to plan the projectactivities using project networks. Estimation isused to derive resource and time parameters for the project, often called ‘baseline’ estimates.These estimates are useful for developing work breakdown structure, ensuring quality

standards, monitoring and controlling a project.Estimation is done using generic human-basedor non-human techniques or techniques thathave been developed specially for systemsproject management.

The Delphi method for estimation is basedon human judgement. It is composed of experthumans in their particular sub-fields like projectmanagement, systems analysis, or programmingwho are brought together to form a panel.Panellists need to be open to sharing theirexperiences and willing to reach a consensus of opinion. A project manager would set theagenda to avoid a particular panellist, someonewith higher status or more success, from dom-inating the proceedings. The panellists gothrough various rounds making judgements on

104


Conduct interviews Develop prototypeuser interfaces

Examine document

Examine current IS

Compilerequirements report

1

2 2

1 5 5

33

5

88

5

1

4

2

5

8 9

9 9

Earliest start time(EST)

Latest starttime (LST)

Activity-on-node(name andduration)

00

1

0

0 3

2

2

3 1

Duration

Earliest finishtime (EFT)

Latest finishtime (LFT)

Float/slack

Figure 4.1 The precedence network

particular project objectives and resourcesrequired to complete them. They would makewritten responses to such issues. These responseswould then be used for making actual estima-tion decisions.

Other estimation techniques based on humanjudgement include: the analogy method, analysiseffort method, programming method, and directestimation. The analogy method is used whenthe experiences of a previous similar project are available to a project manager or organiza-tion. The previous project is used as an analogy for current project to determine estimates ofrequired time and resources.

Non-human estimation techniques are gener-ally called estimation models. They involvemeticulous calculation using statistical tech-niques. CoCoMo and Function Point Analysis

are examples of estimation models. In FunctionPoint Analysis the aim is to measure the size of acomputer program based on the number andcomplexity of inputs, outputs, queries, files andprogram interfaces. The number and complex-ity of each component of the system is recordedon a predefined worksheet, these are then usedto calculate the Total Unadjusted FunctionPoints (TUFP). Data entry screens, reports ordatabases are examples of a component. A pro-ject manager makes a subjective assessment ofthe complexity of each of these components. The TUFP is then assessed according to 14 factors that have an impact on complexity todetermine the Adjusted Project Complexity(PCA). Examples of these factors are reusability,data communications and end-user efficiency.The TUFP value is then multiplied by the PCA

111

0

11

0111

0

0

11p

105

Table 4.4 Elements of a precedence network

Element Description

Activities An activity is a work package derived from analysis of work breakdown.In systems analysis, examples are user case analysis or user interfacedesign.

Earliest start time (EST) This the earliest time that a particular activity can begin. For example,user interface design may begin before other systems analysis tasks arecompleted.

Duration (D) This is the time duration of a particular scheduled activity.

Earliest finish time (EFT) This is the earliest time that a particular activity can finish. Forexample, physical database design cannot finish until requirementsspecification is complete.

Latest start time (LST) This is the latest time that a particular activity can start. For example,examining current IS can be delayed but must finish before the nextactivity on the critical path.

Float/slack (F) This is the spare time available before a particular activity must start.Often this time is useful when an activity overruns.

Latest finish time (LFT) This is the latest time that a particular activity must finish. Forexample, in structured analysis the feasibility study must finish beforesystems analysis can begin, or testing must finish before compiling thefinal report.

Critical path The set of activities that has the longest time path is the critical path.The activities on the critical path must all be completed on time for aproject to be successfully completed.


value to arrive at the Total Adjusted FunctionPoints (TAFP).

In the CoCoMo estimation model the aim isto measure the effort required to completeproject objectives by converting the lines-of-code effort into a person–month estimate.Measuring effort requires knowledge of the sizeof the project and the software production ratesof project staff. The formula to calculate theperson–month effort is:

Effort (in person–month) = 1.4 * thousands of linesof code

For example, for a project with 20,000 lines ofcode the project would take 28 person–monthsto complete. This kind of simple model inpractice will be complicated by other factors like the complexity of the algorithms, experi-ences of programmers and the type of softwarebeing developed. Source lines of codes can bereplaced with function points at this stage.

The complexity of the software and experi-ence of the programmers are examples of con-tingency that need to be incorporated in projectplans. The actual complexity of software may be more than its estimated complexity. A pro-ject manager needs to think ahead and ensurethat appropriately qualified and experienceddevelopment staff is included in the project.

4.5.8 Checking progress

Once a project begins, its actual managementrequires monitoring and controlling the projectplan, with its associated work and productbreakdown, estimates and schedules. A projectmanager has to check progress and makeadjustments to time and work allocation whererequired. The project plan when implementedwill require adjustments and actual resourceand time allocations to be revised.

There are various techniques for checkingprogress and taking action. Project evaluationtechniques focus on gathering quantitative datato monitor progress and are categorized interms of backward-looking and forward-look-ing. They provide quantitative data to comparewith baselines estimates. Backward-looking is acomparison of forecast or baseline costs withactual costs incurred. This focus on costs alonefails to measure how much work is actually com-pleted. Forward-looking monitoring overcomesthis problem by measuring both costs and thework done. This requires determining budgetedcost of work scheduled (BCWS), actual cost ofwork performed (ACWP) and budgeted cost of work performed (BCWP). These quantitiesenable comparison of scheduled cost of workwith actual cost of work or other combinationsto determine variances.

A project manager combines monitoringwith control to ensure the attainment of projectobjectives. Monitoring provides information onvariances from the project plan and control isused to take action to ensure the project plan issuccessful. Project managers have a choice ofaction they may take to check variances, whichincludes aborting if the project looses credibil-ity with the sponsor and influential stakehold-ers. The other actions used in practice includereallocating resources to recover the project orcompromise cost and time. If some projectobjectives can be jettisoned without compro-mising main required system functionality thenthe scope is redefined. There may be situationswhere taking no action is viable, where theactual cost or work variance has no significantimpact on other activities.

4.6 Planned action

Planning is a significant activity in project man-agement. Planning activities in the previous

106


section and the consequent action required toimplement it is characterized here as as plannedaction. This kind of planned action is reflected inmany project management methods. PRINCEis one example. Planned action is crystallized inthe CMM.

4.6.1 Capability Maturity Model forsoftware

CMM is a process or process-centric model ofsoftware development, illustrated in Figure 4.2.It was conceived to improve the production ofsoftware through carefully planned activitieswith well-defined inputs and outputs. It is a

process method of systems project managementthat is defined, managed and repeatable.

CMM depicts software development as aplanned process which can be progressivelyimproved. The various improved processes aredefined as levels of development of the softwareprocess. Software houses and organizations mayseek accreditation from CMM and be classifiedaccording to the level their particular processhas reached. The process levels are:

• continuously improving process;• predictable process;• standard consistent process;• disciplined process.

111

0

11

0111

0

0

11p

107

Initial

Defined

Managed

Optimizing

Disciplinedprocess

Planningcontrol

Standard consistentprocess

Predictable process

Continuously improvingprocess

Repeatable

Ad hoc,sporadic

Consistent

Defined process,objective metrics

Focus onquality

Figure 4.2 Capability Maturity Model for software


The lowest process is the disciplined processand the highest is the continuously improvingprocess. These processes are associated with aparticular hierarchy of stages or levels.

Initial level is where an organization hasno clear and objective process and no effort ismade to have precise work schedules andcosting. The process is ad-hoc and even spo-radic.

Repeatable level is reached when theorganization has a disciplined process. Theprocess is characterized as having managementcontrol, planned work schedules and costing,and careful control of changes.

Defined level is reached when the softwareprocess forms the basis for developing IS. Thesoftware process is defined and consistentlyimplemented.

Managed level is reached when thedefined process is improved by adding processmetrics to measure the quality of the process.Systems project management is conducted onthe basis of identified process elements and theircareful analyses to inform decisions that lead toimproving the quality of both the product andthe process.

Optimizing level is reached when theprocess is developed to continuously improveand optimums are continuously sought. Theoptimum process is characterized with innova-tion in the software development process thatleads to improvements in quality and produc-tivity.

Planning is a critical feature in CMM andthe highest optimizing level requires meticulousplanning. CMM is important for systemsproject management because it sets a standardfor others. In practice though, few organizationsseek CMM accreditation because of the strin-gent process improvements required. Thoughthe impact of CMM on systems project man-agement is significant, its actual implementationby organizations is sparse.

4.7 Systems analysis and design

Significant components of a system project aresystems analysis and systems design. They arework packages in terms of work breakdown and product breakdown structures. A projectmanager, senior analysts and designers, wouldneed to describe them in detail for analysts anddesigners. Analysis and design activities andoutcomes are identified in the work breakdownstructure and product breakdown structure. Assystems models produced by analysts form thebasis for software programming and imple-mentation work packages, dependencies wouldneed to be carefully plotted on project networks.

Senior systems analysts and systems design-ers each manage a team of systems analysts anddesigners. The senior systems analyst organizesthe team to conduct interviews with stakehold-ers and employees, analyse relevant businessdocuments, and shadow relevant people. Theseactivities are to gather information on the func-tions required of a new IS. The senior systemsdesigner and the design team use the systemrequirements to produce systems designs and asystem specification.

Structured systems analysis and design com-plements systems project management. It isused to manage effectively the software processby identifying roles, work and modelling tech-niques to construct systems models. Systemsproject management is similarly structured, asreflected in planning techniques and activities.

4.8 Project management and theCritical Framework

The Critical Framework provides a critical orientation for considering the role of systemsproject management in IS development and therole of systems analysis and design within systemprojects. It can be the basis of reasoned under-standing of the uses and limits of establishedsystems project management knowledge and the

108


need to keep an open perspective on practice.There are various theories underpinning prac-tice in systems project management, some areconflicting. Practitioners need to focus on thepragmatic resolution of problems that arise inthe situation while benefiting from theoreticalknowledge.

Figure 4.3 is the Critical Framework popu-lated with critical reflection on systems pro-ject management and the practice of systemsanalysis and design within it. As the bottomlayer shows, many questions concerning thefour themes of criticality arise from the assump-tion of planned action, rational human behav-iour and stable system project environment.

A critical analysis of the role and assumptionsof systems project management will contributeto improving a PCF. Further enhancement of a PCF will result from a critical considerationof alternative conceptions of IS projects, tech-niques and measures of success. Overall, criticalreflection will enable practice to be improved byconsidering how alternatives can be used andhow they can be enhanced.

4.8.1 Introduction

The conceptual basis of systems project man-agement and its instruments need to be analyt-ically evaluated because the underpinningphilosophical and conceptual thinking posespractical difficulties. Developing an IS using theSDLC within a project assumes formalism, anobjective epistemology and rationalism. Theselead to the expectation that:

1 System requirements for a new IS can beestablished (predicted and remain constant).

2 Formalism and formal instruments can beused to frame and solve an IS problem.

3 Project plans can be developed and effectivelyimplemented.

These assumptions underpin systems project formalism. Systems project management in turn

assume that universalistic principles operate,and that attainment of an ‘optimal’ is possiblein every case, for example, as in CMM. Theassumption that universalistic principles can beapplied in all cases is based on the objectivistepistemology, which in turn leads to standard-ization and transfer of knowledge. Combinedwith rationalism and economics, it is assumedthat economies of scale and specialization arepossible.

Systems project management is based on thediscipline of project management reflected inplanned or projected activities, but there aredifferences between the two that a projectmanager needs to appreciate. The differencesconcern the nature of software and IS develop-ment. Unlike a physical product or other busi-ness project, the development of social software– for human informational and knowledge use – does not succumb to planned action.

An allied problem is the conceptualization of IS development as a distinct project ratherthan a business operational activity. This is asignificant problem since the flow of informa-tion is part and parcel of organized activity. Itsseparation into a systems development projectassumes that organized activity will be stableduring the development process. Actual prac-tice is quite different, where change is the norm.Such change affects project scope and estim-ates, which need to be revised to reflect actualconditions.

Managing risk requires understanding theparameters of risk, namely constraints and un-certainty in a project. Constraints may includehuman resources or time limits. Uncertainty can arise internally in the organization and project or externally from competitors or mar-ket forces. A prime problem in managing risk is the assumption that constraints and uncer-tainty can be identified and understood toenable risk management. The available tech-niques for risk management seem plausible, butare arguably only guesstimates.

111

0

11

0111

0

0

11p

109


110


Apply formalmethods


(Messy world)

Information technology,changing objectives,

‘creeping requirements’,system project separatedfrom business operations,

stakeholders, conflictestimation problems,changing businessoperations, failure

Systemsontology

Project management

Business case,planned software

development systems,management,set objectives,

plan,monitor,control,criticalpath,

time-boxing,estimates,

workpackages/products

team,stable system project,

environment

Pragmaticresolution

???


Develop knowledge

Determine a pragmaticresolution to problemswith formal techniques

and tools

Resolveproblems


Can rolling planscontribute to better

project managment?Why is a business

case needed?


Is a system projectnecessary?

Can softwaredevelopment activities be

planned?Why is systems

development separatedfrom businessoperations?

Critical skills

What can be learnt fromteam-building?

Can users be part of theproject team?

Figure 4.3 Critical framework: systems project management

There is an operational barrier betweenplanning and the implementation of a plan.Associated with this is the idea of allocating timeperiods to planned activities or time boxing.Planning itself is directed by business strategyand can be the product of rational processes,but the actual plan in practice is difficult toimplement as intended. The actual situationoften does not reflect the plan and timed activities are often not realized as required.

4.8.2 Problems with rationalism andplanned action

The systems ontology component of the CriticalFramework in Figure 4.3 has the subtitle ‘pro-ject management’. The basis of systems projectmanagement is rational thinking. The rationalpresumption is clear. A project is an entity thathas specific and clear objectives, a beginning,duration and an end, and it is required to pro-duce an explicit prescribed outcome. It is bro-ken down into work packages that are known inadvance, predictable and assumed to be con-trollable. It is assumed they can be containedwithin available resources. The risks associatedwith the project can be predicted, measured andmanaged, and avoided or mitigated. Above all,a project can be optimized.

IS development is normally regarded as aspecial planned project. The basic premise ofthe planning is that humans behave rationallyor economically. IS projects are selected ratio-nally for development. The rational selectionassumes objectivity that is free of bias or preju-dice and is normally based on financial methodssuch as cost-benefit analysis.

IS development in actual situations does notreflect planned action – the human problemcomponent.

A business case is made in terms of costsavings, efficiency and production benefit. Thiskind of justification though has proved to be dif-ficult to measure and evaluate, as information

economists have found no specific correlationbetween investment in IT and business gain.The claims that the use of computers and IT isintegral to business are even more difficult toquantify. Nevertheless IT and IS are significantin modern organization.

Often organizational change programmesare unique with no prior experience in anorganization to manage a project. An IS projectis unique in the sense that no exact same pre-vious experience can be called upon. So evenexperienced project managers have to be opento learning. While they can draw on previousexperience of using project management tech-niques, they will not have relevant experienceof the particular current project. Ironically, noprior experience of similar projects reinforcesthe need to plan to prevent costly mistakes.

Consideration of complexity, change and thelack of requisite knowledge for the developmentof effective plans raise the issue of the tensionbetween planned action and situated action.Project managers invariably need to take cor-rective action to ensure that the work andresources are being done according to theproject plan. This type of action-in-the-situationundermines assumptions of rationality andobjectivity in planned action. The situation andsituated action rather than plans seem to dictatehow project managers act.

Project managers’ knowledge of planningtechniques needs to be combined with know-ledge of organizational work. The rationallyderived techniques and tools of structured analy-sis and design and project management do notreflect adequately human aspects of softwaredevelopment, IS development and organiza-tions. The effective use of planning techniquesrequires knowledge of organizations and humanbehaviour. Stakeholder analysis seeks to redressthe gap, but has low profile in practice.

While planning is necessary, plans are diffi-cult to implement in organizations. Planning

111

0

11

0111

0

0

11p

111


and the implementation of a plan is difficultbecause of complexity, change and lack ofknowledge. Complexity and change in particu-lar pose practical software development prob-lems. While change is considered in contin-gency planning, project managers need to takecorrective action when these or other factorsimpinge on the plan. In doing so they need to understand the cause of the problem andwhat effect the corrective action will have onthe project. It is necessary to understand thereasons for delay and overspend to improve theeffectiveness of the project team. Managingchange often involves project managers seekingsupport and commitment from the sponsor andrelevant stakeholders.

4.8.3 Success and failure

Success and failure in IS development is evalu-ated and understood from different perspectives.Systems analysts believe that objectivity andrationality is possible in practice. A project men-tality is expected to bring discipline and effec-tiveness to IS development and success, but thishas largely failed to materialize. IS projects havefailed incurring hefty costs to companies andpublic sector organizations. Executives’ expec-tations of IT have not been fulfilled, generatinga debate among researchers and practitionerson what constitutes a ‘successful project’.

While a project is useful for organizing workpackages, it has limitations. They have oftenresulted in ‘disappointed users’ or unuseddeveloped IS. Costly projects have tended to beunsuccessful in project terms, for instancekeeping to the set budget or time. The flaws areexemplified by failures like the London StockExchange’s Taurus system and the LondonAmbulance’s dispatch system. These projectseach had budgets of several hundred millions.The Taurus project was abandoned and theLondon Ambulance system had operational

failures leading to tragic consequences forhuman life. Alternative approaches to systemsdevelopment based on similar assumptions aresusceptible to similar problems.

It is problematic to measure success in ISdevelopment because of the nature of informa-tion and knowledge. IT is used to process databut the actual consumption of information andknowledge is by humans individually and inorganizational contexts. Developed IS remainunused because executives, managers or otheremployees regard the information produced asirrelevant to their needs.

From a different perspective practitioners arequestioning absolute measures of project success.This perspective raises doubts on the rationalassumptions in systems ontology. They arguethat the measures relevant to non-systems pro-jects like meeting project objectives, budgetedcosts and time targets cannot be simply trans-lated into IS projects. Some practitioners arguethat the learning experience is more importantthan the actual achievement of project objec-tives. They reason that the experience gainedfrom being involved in a project can be reflectedupon and used in other projects.

4.8.4 Alternatives

Real situations provide contrary observations ofproject behaviour, organizational factors,information needs and definitions, which leadto alternative perspectives on software and ISdevelopment. There continues to be progressand development in projects and IS develop-ment process. New and emerging approachescater for gaps in traditional project manage-ment and issues in IS development such as:

• Who is a systems developer?• How is a system selected for development?• How is a system developed?

112


• Why separate a system project from businessoperations?

Structured and object-oriented systems ontol-ogy assumes that a systems developer is a qual-ified professional. The systems ontology doesnot admit so-called ‘users’ to be regarded asdevelopers. New approaches are breaking thetraditional boundary between the ‘developer’and the ‘user’.

The major issue in identifying and selectingan IS project is who should do it. The SDLCand SSADM make business executives, businessmanagers and IT managers responsible. Thishas been challenged for some time in End-UserComputing technology, making it possible foremployees of an organization to make the selec-tion decision and themselves develop a system.

RAD and Component-Based System Devel-opment (CBD) are two alternatives to tradi-

tional systems project management. They seekeffective use of limited resources. Both alterna-tives reduce reliance on meticulous plannedaction. RAD removes stringent discipline orplanned action of projects. It replaces theSDLC with an alternative that is designed to beflexible in practice and true to context. Thisalternative is based on involving users in ISdevelopment.

CBD is the development of components ofsoftware that can be reused and composed intoIS. This is possible using object-oriented tech-nology, though components can be developedin procedural languages too. CBD aims to buildsoftware assets and generic models that can becommonly used. Software that is reusable istermed a ‘component’. The task for a systemsproject manager developing IS based on CBDis to identify relevant components and composethem to produce the required IS configuration.

111

0

11

0111

0

0

11p

113

Table 4.5 Personal constructs for project management

Pole 1 Pole 2

Plan Unplanned

Set objectives No objectives

Control Uncontrolled

Resourced Under-resourced

Expected Unexpected

Team cooperate Team conflict

Motivated Motiveless

Manageable Unmanageable

Consensus Conflict

Agreement Disagreement

Ris

k m

anag

emen

t

Hum

an r

esou

rce

skill

s

Qua

lity

Tim

e

Sch

edul

ing

Est

imat

ion

Act

ual

situ

atio

n



4.9.1 Personal constructs for systemsproject management

Table 4.5 is a sample repertory grid for projectmanagement. Reproduce the grid on a spread-sheet and add further columns and their polaropposites that you consider relevant. To objec-tify personal constructs in project management,complete the grid by following the details onhow to use a repertory grid in section 1.10.1.

4.9.2 Systems project selection

Questions

1 Evaluate whether the notion of a project isappropriate for developing IS.

2 Evaluate the utility of generic competitivestrategies for selection of strategic systemsprojects. Some examples of generic competi-tive strategies are: low cost producer, productdifferentiation, product focus or niche. Howrelevant are these for your organization?

3 Systems project management provides tech-niques for planning and executing soft-ware development. What practical issues and problems can you identify with the useof projects and project management in ISdevelopment?

4 Discuss whether senior management orpeople who do the everyday work in organ-izations should select systems projects.

Activity A

Identify an IS in your organization. Determinehow it was selected for development. Was itselected on the basis of a formal methodologysimilar to the SDLC using feasibility study orsome other in-house method?

Activity B

The first airline reservation system is consideredto be a strategic IS. Strategic IS provide com-petitive advantage to companies who developthem. Individually or in groups, investigate anddescribe the process and methods used in yourorganization to identify and develop strategicIS. Consider the following points:

• What assumptions can you identify?• What systems ontology model informs the

system?• What evaluation criteria were used to select

the system for development? Some examplesare value chain analysis, strategic alignment,potential benefits, resource availability,project size and duration, and technical dif-ficulty and risk.

• Did the IS development proceed accordingto plan? If not, explain why it did not.

Activity C

Identify an area of your organization that youthink might benefit from the application of IT.It may be a business function like sales or pro-duction, or a core business process. Develop abusiness case for its selection as a system project.Consider the following points:

• What value or benefit will be derived fromthe new IS for the business?

• What monetary or other resource savingswill it provide?

• Does it have the potential to be a strategicIS that provides the organization with com-petitive advantage?

• Why should it be selected and not someother system?

114


4.9.3 Planning

Question

Critically compare Agile Software Develop-ment (read section 15.5) with systems projectmanagement. Justify which method you wouldchoose to develop IS.

Activity A

IT and IS planning are done in conjunctionwith business planning and strategy. Plannershave to deal with actual situations that do notreflect the assumptions, ethos and techniques of project management. In groups, discuss thefollowing issues found in real situations andsuggest how you as a project management teamwould deal with them:

• Lack of complete knowledge and informa-tion, both internal to the organization andexternal regarding competitors and markets.

• The validity of the assumptions made in theplans.

• Issues surrounding the scope of the projectand difficulties in defining the scope.

• Identifying and catering for contingencies incase the plan falters.

• Authority and power issues. Will people inthe organization accept the planners and theplan?

Activity B

Refer to Activity C in 4.9.2. Bearing in mindthat project plans are not absolute right orwrong ways of doing work:

• Construct a work breakdown structure forthe identified system.

• Construct a product breakdown structure forthe identified system.

• Develop a project network.

4.9.4 Project management and businessmodels

Questions

1 Business planners use the value chain or busi-ness processes, or other business concept, todevelop business models. Discuss how ana-lyst’s systems models would be affected by theneed to consider business models?

2 Systems project management is used toimplement business models that containsignificant investment in IT and IS. Discusswhether systems project management tech-niques are sufficient to cater for a majororganizational change involving a new busi-ness model.

3 Discuss the personal skills and competenciesa project manager requires. How would youdevelop such skills and competencies?

Activity A

Think of a situation where you wanted toachieve something that required others’ help.Briefly describe the situation in text form.Describe how you motivated others to help you.Discuss how you would motivate people in ateam.

Activity B

Based on Activity C in 4.9.2, was the systemdeveloped on the basis of a business model? If so, describe the business model and how it translated into the developed system. If a business model was not used, define an appro-priate business model for the application areafor the system identified and discuss theexpected benefits.

Activity C

Dell.com operates on a successful businessmodel based on IT and internet technology.

111

0

11

0111

0

0

11p

115


Surf the company’s website. Describe thebusiness model you can adduce. Identify par-ticular technology that enables Dell.com to besuccessful.

4.9.5 Stakeholder analysis

Activity A

Based on Activity C in 4.9.2, compile a list ofthe main stakeholders. What is the particularinterest of each type of stakeholder? If thesystem were to be developed anew how wouldyou as a project manager balance their partic-ular interests and manage power relationships?You can use any method for doing the stakeholder analysis, for example see: http://www.scenarioplus.org.uk/stakeholders/stakeholders_template.doc.

4.9.6 Project failure

Activity A

The London Stock Exchange’s Taurus systemand the London Ambulance Service’s dispatchsystem are highly publicized IS failures. Indi-vidually or in groups, identify an IS project thathas failed in your organization. You may inter-

pret ‘failure’ to suit your organization’s needs.Consider the following:

• Why did the project fail?• Is ‘failure’ a relative measure? Do IS devel-

opers consider it a success or something fromwhich they have learnt valuable lessons?

• What knowledge can be learnt from thefailure to ensure better project managementin the future?

• Might the use of the CMM produce a dif-ferent outcome?

• Define your personal construct on ‘failure’and ‘success’ for your PCF.

Activity B

Identify an IS familiar to you:

• Determine how quality was defined duringits development.

• Solicit the views of its current users to deter-mine whether they agree with the originaldefinition of quality.

• Determine with the current users what maybe regarded as an appropriate definition ofquality for the system.

• Discuss whether you agree with the users’ def-inition. Is an objective definition appropriate?

116



CMM is systems project management that is highly standardized and regulated. You can exploreits details at http://www.sei.cmu.edu/cmm/cmms/transition.html.

For information on team and group roles, see Belbin’s work at http://www.belbin.com/.

For information on project management see www.fek.umu.se/irnop/projweb.

Information on SSADM and project management is available at www.comp.glam.ac.uk/pages/staff/dwfarthi.

111

0

11

0111

0

0

11p

117

PRINCE is a project management methodology. For information on PRINCE see www.ccta.gov.uk.

For risk management see http://mijuno.larc.nasa.gov/dfc/rsk.html. It contains an overview anda bibliography. Also, http://www.rspa.com has a list of references.

For information and method details for CoCoMo see http://sunset.usc.edu/COCOMOII/cocomo.html.


A standard textbook on project management techniques is Yeates, D. and Cadle, J. (2001) ProjectManagement for Information System, London: Pitman Publishing.

For a reading of alternative perspectives on software see: Truex, D., Baskerville, R. and Klein,H. (1999) ‘Growing IS in Emergent Organizations’, Communications of the ACM, 42(9): 117–123.

For a critique of planning read Mintzberg, H. (1994) ‘Fall and Rise of Strategic Planning’, HarvardBusiness Review, January–February 1994: 107–114.

To construct activity-on-arrow networks see: Yeates, Y. and Cadle, J. (1996) Project Managementfor Information Systems, Harlow: Prentice Hall. Chapter 6 provides an overview of activity-on-arrow networks and work breakdown.

For an alternative perspective on software development read Chapter 1 by Patel in: Patel, N. V.(2003) (ed.) Evolutionary Adaptive Information Systems, Hershey, PA: Idea Group Publishing.

An alternative model of IT governance is in Patel, N. V. (2002) ‘Emergent Forms of ITGovernance to Support Global eBusiness Models’, Journal of Information Technology Theoryand Applications, 4(2): 33–48.


5.2 Introduction

Systems analysts are arguably important mem-bers of a systems project team because of theirsystems analysis and systems modelling skills.The term ‘analyst’ emphasizes the ability tothink logically, analytically, critically and cre-atively. An analyst is the person who communi-cates between the needs of the business and thecapability of IT, and other related communica-tions digital technology, to meet those needs.

Systems analysis has a long tradition inorganized human activity. It is an important andvital technique to understand and develop

knowledge of human problems, define humangoals as problems, and to organize knowledgeand understanding to resolve defined problemsin systemic terms. It has been applied to mili-tary, government and business problems, and itis the prime form of problem definition and res-olution for IS.

Though a specialist in IS, an analyst needs topossess other skills. Their work is vital in orga-nizational information and knowledge manage-ment. Systems analysis and design has broaderimplications for how an organization defines its information and knowledge systems, andmanagement systems for executives. In addition

118

Chapter 5

Systems analyst



• Analyse the organizational problems systems analysts face in applying their skills andsuggest strategies they can use to overcome them.

• Identify and propose solutions to the problems of (dis)communication betweenanalysts and their clients and stakeholders, and propose pragmatic solutions forsystems modelling problems.

• Critically evaluate the problem-solving, analytical and critical skills required of asystems analyst.

• Determine appropriate personal construct for ‘systems analyst’ for a PCF.• Apply transformatory critique, refashioning of traditions, reflexivity and critical skills

to the ‘self’ as systems analyst.

to contributing modelling skills, analysts needknowledge of business models, business pro-cesses, organization, management systems anddecision-making processes. For these reasons,analysts can make a better contribution if theyare capable of critical investigation.

5.3 Qualities and skills of systemsanalysts

Systems analysts need to develop various quali-ties to become systems modellers. An interest inhow organizations work is a prime qualitybecause analysts’ work is to understand peopleand work and how these are organized toachieve specific goals in systemic terms. Analystscontribute knowledge of IT, IS and systems todefine IS. They work in a systems project teamto redesign organizations and systems radically.Table 5.1 is a summary of the non-technicalqualities of an analyst.

Analysts require a broad range of knowledgeand skills to investigate and model organiza-tional work and systems. Major knowledge and

skill area is systems modelling, but other areasinclude IT, business modelling, organizationand people. They cover an understanding oforganization, communicating with people, con-struction of systems models and the innovativeapplication of IT.

5.3.1 Organization and peopleknowledge and skills

Though all organizations have common attrib-utes like business processes and functions, eachcompany’s organization is unique. Businessunderstanding is required to underpin theprocess of systems modelling and systemsmodels. Knowledge of organization and howorganizations work is necessary for analysts toundertake informed systems analysis. A genuineinterest in the business, manufacturing cars orretailing food, is necessary to develop under-standing. The business of the organization willdetermine the kind of data it produces that couldbe processed by IS to provide information formanagers or enable business processes.

111

0

11

0111

0

0

11p

119

....................................................................................................................Chapter 5 Systems analyst

Table 5.1 Qualities of systems analysts

Analysts’ qualities Qualities in practice

Investigative interest Ability to investigate organizations, organizational situations, people,workflows and business processes.

Innovative attitude Ability to create new organization with IT and IS. Improve or replaceexisting organization.

Conceptual thinking Ability to make observations and convert them into concepts and generatenew concepts from them to address business and IS problems.

Critical thinking Ability to ask searching questions based on interpreted data, facts,perceptions or opinions. Think differently and uniquely.

Diplomacy and tact Ability to keep good relations with a project team and stakeholders.Competing and politicking groups should not be alienated in favour of one,so that modelling information can be extracted.

Objectivity Ability to remain impartial to develop effective systems models based on allthe sources of information equally. (This quality may be replaced withsubjectivity, depending on analysts’ predisposition.)

An important quality is diplomacy and tact.Much of analysts’ work requires communicatingwith people who make use of the informationfrom an IS. As analysts need to communicatewith competing and politicking groups or stake-holders they need to be diplomatic and tactful.They have to keep themselves in a position toextract required information from all relevantgroups and individuals. People and groups oftenhave interests that vary from others’. Analystsneed to ensure that they have access to conflict-ing stakeholders, and that they are impartial inhow they deal with conflicting interests.

In organizational terms it is the informa-tion and knowledge in organization that is important for the technical systems design.Analysts need to consider all the sources ofinformation impartially. Partial informationwill result in poor or ineffective systems models,and consequently poor usage of the resultantIS. Diplomacy and tact are needed not to alien-ate individuals or groups from the modellingprocess. Interpersonal skills are important inthis process.

Analysts’ knowledge of organizations isenhanced by an investigative interest and howIS can be used to improve business processes orachieve strategic objectives. Business problemscan be resolved with IT and IS but the organ-ization needs to be systematically and systemi-cally investigated. Improvements in customerservice or product quality can be obtained byapplying IT and the development of appropri-ate IS, only if analysts’ investigation is thoroughand informed.

An innovative attitude is necessary to resolvebusiness problems involving IT solutions. Sys-tem models incorporate organizational aspects.Analysts redesign workflows, business processesand organization, often radically, by developinginnovative systems models. During the 1990sinnovative systems models were created basedon BPR. Analysts were part of systems project

teams that redesigned organizations radically.They combined organization and systems mod-els to exploit the capabilities of IT.

5.3.2 Conceptual and logical skills

The precursor to innovative design is concept.Conceptual skills are important. Analysts needto be able to make abstractions from observedactual situations. Abstracting elements anddetails from an actual situation requires con-ceptual thinking. Systems models are anabstraction from actual problem situations.The notion of ‘system’ is itself an abstractionused to organize thinking on human problems.The radical redesign of organizations requiresan ability to conceptualize an alternativeorganization. Experienced analysts think con-ceptually about organization, work and IS andIT to develop systems models. Conceptualthinking requires an ability to make acuteobservations and draw abstractions that can bepractically applied.

Analysts require cognitive skills to frame andsolve problems in systemic terms. Effective prob-lem-solvers are people who can develop a goodconceptual understanding of the problem andthen begin to factor it into manageable sub-problems. The skill to analyse a problem system-atically and to use logical reasoning is importantfor analysts to develop. Abstract concepts de-rived from observations of how an organizationworks underpin systems models. Analysts need to be able to translate multifarious individualobservations into concepts to develop systemsmodels. ‘Business process’ is such a concept thatdescribes organizational work that crosses func-tional boundaries in an organization. For exam-ple, the production process begins with the salesoffice taking an order from a customer, passingit onto the production department to producethe goods, and production then passing it ontologistics to make the delivery.

120


Notation languages enable and supportlogical reasoning. Analysts need the skill to iden-tify, define and resolve business and organiza-tional problems in terms of a notation language.Many business and organizational problems are complex and intertwined. Notation lan-guages are used to define and resolve theseproblems. Analysts need to be able to use nota-tion languages to represent symbolically actualproblems.

5.3.3 Technical skills

Analysts’ work requires knowledge of and skillsin IT and IS modelling. Knowledge of IT isnecessary to be able to communicate with soft-ware programmers, database administratorsand computer network specialists. Analysts donot need to be able to write computer programsor configure systems and computer networks,but they need to understand IT in terms of the‘problem domain’ and how it can be used in it.An awareness of IT capabilities is essential.

Though not essential, an analyst who hasknowledge of computer programming willprobably develop efficient systems models.Systems modelling skills are required to developeffective and efficient systems models. Know-ledge of and the application of systems notationlanguages to business and organizational prob-lems are essential to develop systems models.Systems modelling notation languages consist oftechnical symbols to represent and manipulateactual problems.

5.3.4 Critical skills

Analysts need critical thinking skills becausemany applications of IT involve radical andfundamental change in organization and busi-ness processes. Analysts need to be able to ques-tion existing organization and work, andanalyse actual problems from the perspective of

proposing radically different alternative organ-ization. In Barnett’s (1997) terms, criticality isthe predisposition ‘that the object of attentioncan be other than it is’.

Investigative and innovative skills are under-pinned with critical thinking skills. Criticalthinking involves interpretation, analysis, evalu-ation, inference, explanation and self-regulation(see section 1.8.1). In a particular systems mod-elling situation, all these skills are required to first assess the current situation and then to generate alternatives to resolve problems. Toassess the current situation the observed data,facts, or perceptions have to be first interpretedand then analysed. Their credibility is then evaluated. From this position appropriate andrelevant inferences can be drawn. The explana-tion is the justified alternative or alternativesgenerated.

At a more complex level, critical thinkingskills are needed to design organization andsystems. BPR, eCommerce and eBusiness areexamples of radical business reorganizationwhere criticality is paramount. Existing formsof organization and business models need to bequestioned intelligently to produce alternativesthat make efficient and effective use of informa-tion and internet technologies.

Critical skills are needed to make decisionson what systems analysis instruments to use.Undertaking analysis of a particular problemdomain requires knowledge of instruments thatwill produce the required information to drawsystems models. Though an analyst alone willnot make these decisions, especially in a systemsproject team, an analyst needs to have theability to make judgements on the appropriate-ness of instruments in a given problem domain.

5.4 Role of the systems analyst

The analyst’s role is central in a system projectas shown in Figure 5.1. Analysts interact with

111

0

11

0111

0

0

11p

121


122


Project manager

Senior analyst

Senior designer

Database administrator

Systems analyst

Project sponsor

Business project manager

Senior business analyst

Stakeholders

Users

Chief programmer

Figure 5.1 Role of the systems analyst

the project sponsor, stakeholders and potentialusers of a new IS on the business side, and withthe project manager, senior analyst anddesigner, database administrator and chief pro-grammers on the technical side. They providesystems programmers and database designerswith systems models based on information gath-ered from business people. Analysts’ tasks are to:

• Analyse and investigate the existing system,whether manual or computerized, and deter-mine the requirements for a new IS.

• Make a judgement regarding the feasibilityof developing a computer-based system forthe application domain.

• Design a new IS: develop process models,data models or class models, and specifyprograms, hardware, data structures, andcontrol and maintenance procedures.

• Test and oversee the installation of a new IS.• Document a new IS and develop operating

procedures for it.

Software programmers depend on a specifi-cation of the required suite of programs for anew IS. Analysts provide a system specificationbased on investigation of the problem domain.Computer network specialists also need to betold how to configure computers and networksto provide an integrated organization-wide IS.They depend on analysts’ systems models toimplement the designs with internet or intranettechnology.

5.5 Systems analysis techniques

Systems analysis consists of examining theproblem domain by considering its constituentparts with systems analysis and design tech-niques and tools – instruments. These instru-ments function to gather information on theactual problem and to develop systems models.Some techniques are borrowed from other

forms of investigation, for example socialscience research, and others were developedspecifically for systems modelling. Many of therequirements gathering techniques are commonto structured and object-oriented systems ontol-ogy. They are summarized in Table 5.2. Othersystems modelling instruments, covered in laterchapters, differ between structured and object-oriented systems ontology.

5.5.1 Interview

Analysts design and conduct interviews withstakeholders and potential users. Analysts haveto identify relevant people to interview and seekpermission from managers. Interviews are gen-erally preferred over other techniques becauseanalysts can gain a deeper and thorough under-standing of the problem domain. The methodis used to gather general and detailed informa-tion on the current situation and requirementsfor a new IS.

The interviews have to be planned carefullyto ensure that useful information is gatheredand make efficient use of both analysts’ andinterviewee’s time. The analyst has to preparea set of questions and make decisions on howto record the replies to the questions. The ques-tions need to be carefully formulated to extractrequired information. Interviewees’ responsesmay be recorded as notes during an interviewor captured on a systems documentation form,the normal capture method for large systemprojects.

Analysts need to think through the questionsto ask at the interview. The set of questions willprobably be agreed with senior systems analyststo ensure that the relevant information is gath-ered to draw systems models. The kind of ques-tions posed will cover existing work, workflowsand business processes; data generated andused; information required and communicated;other business areas affected. More detailed

111

0

11

0111

0

0

11p

123


questions will focus on the specifics of theproblem, data and information needs.

The kind of questions asked will also dependon the type of interview used. Structured andsemi-structured interviews can be used. A struc-tured interview, also known as a close-endedinterview, is composed of questions that areasked systematically in turn and the responsesrecorded. Scaling is the most frequently usedform of close-ended questions. An exampleclose-ended question, using a Likert scale,where a circle or tick is placed by the respon-dent around the relevant item, is:

The granularity of the predetermined responseis determined by the problem being addressedand the analyst’s skill to extract the requiredinformation. Close-ended questions do not

allow respondents scope to offer their ownviews. They have to select an answer from theprovided list. For instance, in the above ques-tion, reports may be on time but not accurateor provide other information than required ata particular time, but respondents do not havethe scope to make this known to analysts. Close-ended questions are asked to enable quantifica-tion of responses and facilitate subsequentanalysis of the responses.

In a semi-structured interview, also known asopen-ended, some initial questions are designedto elicit responses on particular topics, and theanalyst uses the responses to ask one or more further relevant questions. So not all the questions have to be predetermined in a semi-structured interview. A semi-structured inter-view generates much data, often creative andrich in content, that needs to be analysed subse-quently. Responses are usually recorded onaudio to enable analysis. Analysis of gatheredinformation can be highly structured to addressspecific issues and problems. Both initial structured and semi-structured interviews maybe followed up with second interviews to gatherfurther information or corroborate existing

124


Table 5.2 Systems analysis techniques

Systems analysis techniques Description

Interview Analysts meet with individual people or groups in the problemdomain. Questions on roles, responsibilities and interaction are askedand responses recorded. Questions on information needs and uses ofexisting IS are posed and responses recorded.

Observation Analysts observe existing workflows and processes and make a recordof the events. Uses of existing IS are observed and recorded.

Questionnaire Predetermined sets of open-ended or close-ended questions are laidout on paper and circulated to people. Responses are quantified andtabulated to facilitate analysis.

Document analysis For manual systems, copies of manual documents are gathered togather information. For existing IS, systems project documents areretrieved from archives to study objectives, specifications, proceduresand reports.

How accurate is the information in themanagement report you receive?

Never Sometimes Always accurate accurate accurate

information. Examples of open-ended questionsare:

5.5.2 Observation

Observation is used when analysts want to seewhat is happening in the problem domain andrecord the information personally. Observationaffords analysts thinking space to form viewsbased on observed events. To prepare for obser-vation analysts need to identify the area of theproblem domain and the people they want toobserve. They need permission from appropri-ate business managers to observe people atwork. A form also needs to be prepared torecord observations systematically. The obser-vation form should be structured to enable systematic observation.

If systematic observation is not required,then shadowing can be used. Shadowing is usedto gather information in the problem domainas it happens. It differs from observationbecause in shadowing the analyst is in the back-ground. The analyst spends time with anemployee in the problem domain. The analystspends time sitting with the employee while theywork or follows the employee to meetings andother activities. The observation is recorded asnotes or on standard documents.

5.5.3 Questionnaire

Questionnaires provide an efficient means for reaching many people, which is not possi-ble with interviews or observation. The format,

circulation and analysis of a questionnaire ismore efficient than interviews. They are usedfor gathering structured information, where theinformation sought is known in advance.Questionnaires can be open-ended or closed-ended. Information from a large number ofpeople that needs to be quantified and tabu-lated is normally gathered by close-endedquestionnaire.

In a questionnaire, unlike a semi-structuredinterview, all the questions have to be prede-termined. Close-ended questionnaires are usedwhen the nature of the information is known.Senior analysts work with analysts to determinewhat information they need to understand and develop systems models of the problemdomain. Questions are formulated to elicit thatinformation from individuals or groups.

5.5.4 Document analysis

Examination of existing documents in the prob-lem domain is a logical starting point beforeother methods are used. If the problem domainhas no previous IS then existing manual docu-ments are analysed. The kind of documents analysts may search for and analyse include documents that record data, or pass betweenpeople and across departments, or are compiledfor managers. Where there is an existing IS, analysts will examine various systems docu-ments, including system specification, projectobjectives, reports, database and program specifications, and equipment used.

To understand the business problem andworkflows analysts identify and examine docu-ments used by people. Documents, though,cannot be the sole source of informationbecause they may be outdated. It is possible thatthe description of the system in the documentsmay not reflect the actual system and practice.Document analysis is normally supported withobservation.

111

0

11

0111

0

0

11p

125

What are the problems with the existingsystem?

What is the cause or causes of theseproblems?


Standard forms are available for systemsanalysis techniques in IS methodologies. InSSADM interviews and observation are used in the systems investigation phase to provideinsights into the problem domain, particularlythe problems experienced by people. Theseforms become part of the systems documenta-tion which itself becomes a source of informationfor project managers, software programmersand database administrators on a new IS.

5.6 Systems analysts andstakeholders

Stakeholders may make the difference betweenthe success and failure of a new IS. Not allstakeholders will have the same influence andpower. Analysts need to be aware of the influ-ential and powerful ones. These stakeholdersmay have important information required forthorough and complete information gatheringduring systems analysis. Examples are: thesponsor of the project, auditors and depart-ments such as accounts and finance. Potentialusers of a new IS are an example of influentialstakeholders. Analysts interact with stakehold-ers through systems analysis techniques detailedearlier to elicit system requirements.

5.6.1 Requirements elicitation

The purpose of systems analysis is to establishsystem requirements for a new IS. Analystsneed to interact with potential users and otherstakeholders to elicit system requirements. Theyuse analysis techniques like interviews andobservation. Analysts need to use diplomacyand tact with stakeholders and potential usersto ensure that various user groups are keptinformed and satisfied. Alienating a particularuser group will result in deficiencies in informa-tion gathering because the alienated group mayharbour vital information from analysts.

System requirements elicitation requiresanalysts to apply their skills in various areas.Diplomacy and tact are prime among them.The skilful use of systems analysis technique isanother. Central to both these is knowledge andunderstanding of organization and system, andhow they need to cohere to enable businessprocesses and objectives to be achieved.

5.7 Systems analysts and developers

Analysts are the main conduit for information toother project team members, whose interactionwith people in the problem domain is limited.Systems designers, software programmers anddatabase administrators rely on systems analyststo provide information and knowledge on theproblem domain. So they depend on systemsanalysts to provide information to enable sys-tems design and implementation.

Analysts are in a position to develop an over-all view of the problem domain and require-ments for a new IS. Their interaction withstakeholders and potential users gives theminsight. They discuss systems models, design,and implementation issues in detail with data-base administrators and software programmers.

Analysts communicate information to otherteam members in various systems documents,primarily the system specification. Other docu-ments include the feasibility study containingfunctional requirements of any existing system,organization charts, grid charts and records ofinterviews and questionnaire data collectedduring systems analysis. These documents willvary according to the IS development method-ology used or, in the absence of a methodology,according to the practices of the organization.

5.7.1 System specification

The system specification is a collection of ‘deliv-erables’ or documents that detail the systemsmodels for a new IS. It includes the system

126


architecture design, data dictionary, the userand system interface design, database and filespecifications, input and output definitions, andprogram design. Collectively these may be re-ferred to as systems models in terms of systemsontology.

Systems analysts develop systems models inthe analysis and design phases in structuredsystems ontology. They structure the data andinformation to be processed by a new IS. Thesesystem specification documents are communi-cated to software programmers and databaseadministrators. In object-oriented systems ontol-ogy the class systems model is developed duringanalysis and design. The systems models detailwhat a new IS will do and how it will do it.

The system specification is important forseveral reasons. It will provide details to soft-ware programmers on how the system shouldwork and database administrators will use it todesign records for database implementation. Itwill also be used to evaluate and judge thesystem once it is operational. The system spec-ification will become the benchmark for evalu-ating the accuracy and timeliness of informationan IS provides once ‘live’ or in operation.

5.8 Critical Framework and systemsanalysts

A skilled and experienced analyst will haveknowledge of IS development projects. Thisknowledge alone is not sufficient to act with crit-ical insight in new situations. Reliance on skillalone is impoverishing, but practice can beenhanced through critical thinking. Figure 5.2is the Critical Framework populated with criti-cal reflection on the concept of systems analyst.As the bottom layer shows, many questions con-cerning the four themes of criticality arise fromthe assumption of objective and rational humanbehaviour. Alternative instruments and con-ceptions of systems developers are possible.

5.8.1 Professionalism and knowledge

The development of a PCF is a significant stepin professionalism. A skilled analyst with a PCFis likely to be more effective and contributeintelligently to systems projects. Learning fromknowledge and practice to develop practicefurther is the major function of a PCF.Knowledge, skills and experiences of previousIS projects can be enhanced and honed byreflecting critically.

Analysts need to reflect critically on know-ledge, skills and experience they acquire fromformal education and practice. With criticalthinking analysts can think independently offormalism and draw on experience from prac-tice. The PCF components – ethics, assump-tions of reality, personal constructs, instruments,relations between components – can be drawnon to develop independence, which is animportant trait for recognizing human prob-lems and seeking resolution. A fictional anec-dote illustrates the richness of critical thinking:

This has been my experience in Washington when Ihad made money to give away. If I gave a contractto a designer and said, ‘The doorknob to my officedoesn’t have much imagination, much designcontent. Will you design me a new doorknob?’ Hewould say, ‘Yes,’ and after we establish a price hegoes away. A week later he comes back and says, ‘MrEberhard, I have been thinking about that doorknob.First we ought to ask ourselves whether a doorknobis the best way of opening and closing a door.’ I say,‘Fine, I believe in imagination, go to it.’ He comesback later and says, ‘You know, I have been think-ing about your problem, and the only reason youwant a doorknob is you presume you want a door toyour office. Are you sure that a door is the best wayof controlling egress, exist and privacy?’ ‘No, I’m notsure at all.’ ‘Well, I want to worry about thatproblem.’ He comes back a week later and says, ‘Theonly reason we have to worry about the apertureproblem is that you insist on having four walls

111

0

11

0111

0

0

11p

127


128


Apply formalmethods


(Messy world)

Need organizationknowledge too, people

possess knowledge

Systemsontology

SDLC formalism

Analyst as expert,technicality of

design decisions,assumes perfectknowledge and

its rational application,perfect communication,

analyst as modeller

Pragmaticresolution

???



Resolveproblems


Can stories/narrativestold by people be used?Can people make system

design decisions?


Can an analyst be partial?Who can be a system

developer?

Critical skills

Figure 5.2 Critical framework: systems analyst and the SDLC

around your office. Are you sure that is the best wayof organizing this space for the kind of work you doas a bureaucrat?’ I say, ‘No, I’m not sure at all.’ Well,this escalates until (and this has literally happened intwo contracts, although not exactly through thisprocess) our physical designer comes back with avery serious face. ‘Mr Eberhard, we have to decidewhether capitalistic democracy is the best way toorganize our country before I can possibly attackyour problem.’

The extent to which practitioners can rely onformalism in practice is a problem. Practitionersneed to develop a PCF based on learnt know-ledge and experience informed by critical think-ing to become more effective. The fictionalanecdote above illustrates that analysis of exist-ing ways of working needs to be deep enough to question implicit and explicit assumptions oforganization and work, yet it also needs to berealistic to address the pragmatic problem ofdeveloping an IS. The formalism of systemsdepicted in the Critical Framework (Chapter 3)leads to a form of extreme logical investigation and intervention in human activity and organ-izations that arguably looses realism, as in theabove anecdote. The Critical Framework’s othertwo components provide the necessary realisticperspectives.

To become effective systems analysts, ana-lysts should invoke the Critical Framework toquestion learnt and experienced knowledge. Itwill support critical thinking on systems ontol-ogy and enable it to be contrasted with real sit-uations to seek pragmatic resolution. Whetherthe requirement for analysts to be objective isvalid systemic ontological knowledge or whetherthings in the problem domain exist independentof analysts can be analytically evaluated. TheSDLC makes the assumption that analysts arean objective agent in IS development. What isobjectivity and whether analysts can be objec-

tive can be understood independently by inter-preting, analysing and evaluating the notion.

With reference to the Critical Framework,analysts can question whether it is possible tobe objective in social situations like organ-izations and develop an appropriate objectivitypersonal construct. Analysts should assess theissue of ‘ownership’ of the data and informationin the problem domain, as potential users oftenclaim ownership of work. Similarly, questionsabout practice can be analysed. For example,are analysts’ instruments effective or do theyproduce required information.

5.8.2 Knowledge and practice

Analysts should systematically identify otherareas of knowledge and practice and questionthem appropriately. These include:

• Application of systems analysis and designskill in real organizations and IS develop-ment contexts.

• Clarity and difficulties of communicationwith potential users, stakeholders and evenother team members.

• Acting as a change agent in a systems analy-sis and design role.

• Systems analyst as the authority or expert onsystems design decisions.

Analysts’ roles are determined by assump-tions made in IS methodologies. In an objectivemethodology like SSADM, the systems analystwill need to behave impartially and makesystems design decisions on the basis of evidencegathered from the problem domain. In an interpretive methodology like ETHICS orMultiview, the systems analyst will behave sub-jectively and make systems design decisions onthe basis of interpreting the application domain.These need to be evaluated.

111

0

11

0111

0

0

11p

129



Systems ontology questions can be raisedthrough the bottom layer of the CriticalFramework. Who should be regarded assystems developer? Who is best placed to makethe systems design decisions? Should IS devel-opment be top-down selection of projects orbottom-up issues raised in work situations? Istimeboxing an appropriate assumption to makeabout IS in the real world? The answers to thesequestions can be explored in structured andobject-oriented systems ontology.

The issue of a systems analyst as the author-ity on systems design decisions is illustrated inFigure 5.2. The SDLC assumes that only ISprofessionals should develop IS and that asystems analyst is an important intermediary inIS development. It assumes that systems ana-lysts, and other systems professionals, shouldmake systems design decisions. This assumptionis made in structured and object-orientedsystems ontology, and many other methodolo-gies. Deficiencies in the application of suchknowledge to human problems have led to the

notion of participative design, which rec-ognizes that people in the problem domain toocan and should make contributions to systemsdesign decisions.

The Critical Framework can be used to jux-tapose systems ontology with its actual imple-mentation in real situations, and to bring tosurface its assumptions that may contradictpractice. This knowledge can then be used todetermine pragmatic resolutions. For example,is the systems analyst intermediary necessary?As an intermediary the analyst has to com-municate with potential users, which raisesmany practical problems in IS development.For example, often there is confused communi-cation. Consequently, analysts make manyassumptions when making systems design deci-sions. It is not unreasonable to assert that manysystems design decisions are based on assump-tions made by analysts and designers ratherthan gathered requirements.

Critical thinking leads to questioning ofreceived knowledge. Table 5.3 shows, in columnone, example skills that a systems analyst

130


Table 5.3 Systems analyst skills

Acquired skills Practical limitations Possible pragmatic and techniques – in the real world resolutionsystems ontology of human problems

Objectivity Social interaction, human Diplomacy, power brokering.subjectivity (even ego).

People often mistrust analysts’ Involve people in design decisions intentions and become fearful to overcome users’ mistrust and of change that a new IS brings. fear of change.

Systems modelling Limits of technique or tool to Seek an independent review of techniques capture rich human and most appropriate technique or

organizational situations. tool.

Complexity of technique or tool. Reduce level of knowledge needed Real situations do not allow it to use the toolsto be used.

Technical Pace of change. Use simpler methods, tools and Availability of knowledge. techniques.

acquires through education and practice. Itshows, in column three, how these skills need tobe supplemented with skills analysts require tointeract with others in organizational settings.They also question methodological assumptionsmade in systems ontology.

Structured systems ontology assumes perfectknowledge. Figure 5.2 shows the assumption ofperfect knowledge. It applies to SDLC and structured systems ontology (and other method-ologies). Analysts should examine its validity in practice. The knowledge that an analystbrings to the problem domain is limited. Inactual situations it may not be possible to have allthe required knowledge of the problem domainbefore making systems design decisions. Thisresults in analysts and other team members making assumptions about the problem domain.As perfect knowledge and rationality are related,lack of perfect knowledge also questions ana-lysts’ ability to act in a rational manner in real situations.

Similarly, analysts’ role in software engineer-ing needs deeper reflection. Software engineersrely on analysts to specify what a new IS isrequired to do. The engineering metaphor may be intellectually challenged when explain-ing the role of systems analysts. Though theterm software engineering is common whendescribing the development of software, the per-son who investigates the problem domain iscalled a ‘systems analyst’. Analysis is a betterdescription of investigating requirements of anew IS, because it caters for human factors inIS development.

There is a real and fundamental problem indeveloping systems models. The real or ontol-ogy of a thing is understood through someone’sinterpretation of it (unless objectivism isaccepted). An analyst interprets the problemdomain. An interpreted systems model willseem incredulous to people in the problemdomain because their own interpretations vary

from analysts’. They are often critical of suchinterpreted systems models.

A systems investigation relies on analysts’interpretation. Adequacy of analysis depends onthe competencies, skills and experience of ana-lysts. It is possible that analysts may not inter-view the right people, those who are the mostpowerful and relevant stakeholders. Researchreveals analysts have interviewed the wrongpeople at the wrong times. They have posed thewrong questions resulting in wrong answers.Such practice results in bad feeling among pro-fessional developers and potential users andfurther weakens the assumption of rationalbehaviour and the engineering metaphor.

Systems models developed by analysts areinterpretations of real situations. They are notthe systems models that potential users wouldnecessarily build. Even among different analystsor groups of analysts modelling the sameproblem domain can result in different systemsmodels. Analysts emphasize certain aspects of a new IS and de-emphasize other aspects.Leading advocates of structured systems ontol-ogy argue that analysts do this to facilitate com-munication with potential users. These increasethe risk that analysts may inadvertently excludecritical features in their interpretations, anddevelop a system that has meaning for themrather than for ‘users’.

As interpretive modelling challenges theobjectivity assumption of structured and object-oriented systems ontology, it also weakens theassumption of logic in problem-solving. Studiesof highly skilled analysts reveal that they rely onhuman intuition to help them solve problems.Although analysts may be trained in formalmethods of systems analysis that emphasizerationality and logic, the actual practice ofsystems analysis draws on deep human charac-teristics like intuition and prior experience.Though analytical skills are important, systemsanalysts also need creativity skills. Transforming

111

0

11

0111

0

0

11p

131


organizations with IT is not a simple matter ofmechanistic thinking, it requires creativity andoriginality. Analysts’ role is potentially muchbroader than defined in the SDLC systemsontology or others.


The purpose of systems analysis is to describe anew IS through systems modelling. In develop-ing your PCF you should reflect critically on howyou would undertake systems analysis, in partic-ular reflect on how you would define your role.

5.9.1 Personal constructs for systemsanalysts

Activity A

Table 5.4 is a sample repertory grid for systemsanalysts. Reproduce the grid on a spread-

sheet and add further columns and their polaropposites that you consider relevant. To objec-tify personal constructs descriptive of systemsanalysts, complete the grid by following the details on how to use a repertory grid in section1.10.1.

5.9.2 Role of systems analysts andmethod of knowing

Questions

1 List the skills required by a systems analyst.What difficulties might an analyst experiencein practising them in an organization?

2 Critically discuss whether the systems analyst’srole as an intermediary is required in IS devel-opment.

3 Practising analysts may not be aware ofassumptions they make during systems mod-elling. Discuss whether objectivity can resultin factual systems modelling.

132


Table 5.4 Personal constructs for systems analysts

Pole 1 Pole 2

Rational Emergent

Articulated Hidden

Objective Subjective

Complete Incomplete

Ambiguous Unambiguous

Static Changeable

Perfect Imperfect

Expert Non-expert

Reason/logic Intuition

Sys

tem

s an

alys

tO

rgan

izat

ion

Em

ploy

ees

Pro

ject

tea

mIn

form

atio

n S

yste

mO

bjec

tivi

tyP

erfe

ct k

now

ledg

eS

yste

ms

mod

els

Pla

nsS

itua

tion

sS

ubje

ctiv

ity

Con

text

Pro

blem

sol

ving

Cre

ativ

ity

Rat

iona

leS

take

hold

ers

Pow

erR

equi

rem

ents

Que

stio

nnai

reO

bser

vati

onIn

terv

iew

ing

4 If the assertion that ‘users’ know the problemdomain better than analysts is true, evaluatethe effectiveness of system requirementanalysis techniques to gather requirements.

5.9.3 Rationality and logic in practice

Questions

1 Structured systems ontology requires ana-lysts to be rational and logical. What prob-lems can you identify with these assumptionsin practice?

2 What difficulties might arise in applyingsystems modelling notation languages inpractice? How would you resolve them prag-matically to develop systems models?

Activity A

A commercial company is not a clean white-board onto which a systems analyst can applylearnt skills. It consists of people, departments,global divisions and political and power rela-tionships among employees. These aspects of a company (organization) pose barriers foranalysts to apply their skills rationally and logically.

• Assume that an enterprise-wide system is tobe developed in your organization.

• Identify the kinds of problems you wouldencounter in practising rational and logicalsystems modelling.

• How would you overcome the difficulties?Think about innovative ways of interactingwith potential users to achieve your aims.

Activity B

A systems analyst has to operate in an environ-ment of diversity, fluidity and ambiguity, yetsystem project objectives have to be met.

• Identify departments or sections in yourorganization that have diverse needs andmake a list of them.

• Make a list of the changes that happen inyour organization.

• Taking particular departments or sections,make a list of things that are ambiguous.

• Discussion points: How would you cope withsuch an application domain? How wouldyou reduce diversity, fluidity, and ambigu-ity? Is it necessary to do so? Is it possible todo so?

5.9.4 Planned action and situated action

Questions

1 Discuss the quality of system requirementsgathered by a set of planned activities involv-ing interviewing and observations.

2 What kind of system requirements mightarise in actual situations compared toplanned elicitation events like interviewingor observation. Evaluate the effectiveness ofthe shadowing technique to capture suchrequirements.

Activity A

This activity will evaluate your PCF by categor-izing personal constructs into planned actionand situated action. Make two lists. One ofthings you would do to develop systems modelsthat are planned, label this list ‘planned action’.The other of things you think you would dowhen required (as opposed to planned), labelthis ‘situated action’.

If your PCF has only planned action, explainwhy you have not got situated action items. Ifyour PCF has a dominance of planned actionor situated action personal constructs explainwhy it is so. Compare your list of planned andsituated actions with a trusted peer. Discuss thedifferences.

111

0

11

0111

0

0

11p

133


5.9.5 Your analysis techniques and tools

Questions

1 Discuss the effectiveness of one systemrequirements elicitation technique of yourchoice.

2 Explain how you would decide to use par-ticular requirements elicitations techniques.

Activity A

Identify a peer or department member toconduct a systems analysis interview. Think

about how you would prepare to use the inter-view technique with the person identified.

• What information do you expect to get?• Prepare a set of questions to ask them,

and explain the reason for asking each question.

• Conduct the interview and record theresponses.

• Analyse the information to determine its use-fulness.

• What changes would you make if you wereto re-conduct the interview?

134



There are not many internet sources on systems analysts. An account by a working analyst is givenat http://www.itcareers.acs.org.au/people/shekar.htm/. You could also surf the internet search-ing for professional institutes of systems analysts to learn more about their work.

The Institute of Systems Analysts at http://www.iap.org.uk/ is a useful site for practise in systemsanalysis.

In the previous parts problems with systems ontology have been examined from the perspec-tive of the Critical Framework. Particular and overall criticisms of IS development have beendiscussed and PCF developed. Part III covers systems analysis. Systems analysis is a set ofanalysts’ activities to describe what a new IS will do. It results in systems models that describewhat the system will do and how its parts are related.

Techniques and tools – instruments – to develop systems models in structured and object-oriented systems ontology are covered. Analysts’ use instruments in the problem domain todetermine the data and functions of a new IS. Instruments are used to investigate, describeand model existing workflows and business processes and to develop systems models of alter-natives integrated with or supported by IS.

Instruments will first be introduced and then critically analysed. Instruments will beappraised from the perspective of the Critical Framework to engender critical thought andpractical relevance. Instruments are limited in the kind of knowledge that can be gatheredusing them because of ontological assumptions they make. They will be critically consideredto develop critical awareness.

The foundation of an IS is determining what it is required to do. This is termed ‘require-ments analysis’. In structured systems ontology a system is modelled in terms of data andprocess, and the logic of processes. Chapter 6 focuses on how the requirements for a new ISare determined. System requirements are determined by developing systems models of data andprocesses. Chapter 7 covers how structured data systems models are developed and Chapter 8examines how structured process systems models are developed.

Though structured data and process modelling are covered in two chapters they are logi-cally related. Data systems models are required to identify corporate data that may be usedin more than one process systems model. The aim of separating the two types of modelling isto reduce data redundancy in the system. Analysts using structured analysis have to focus onboth data and process systems models.

In object-oriented systems ontology a system is modelled in terms of classes and objects.Establishing system requirements and developing systems class models in object-oriented analy-sis and design is covered in Chapter 9. The class systems model consists of four components:problem domain class model, human interaction class model, data management class model,

111

0

11

0111

0

0

11p

135

Part III

Systems analysis

and system interaction class model. Together they compose an IS design. Object-oriented analy-sis focuses on the problem domain class model. The other three components are discussed inPart IV, Systems Design.

In terms of the Critical Framework, as well as having knowledge of instruments, analystsneed to be aware of their limitations and how they can be improved. PCF can be enhancedand improved by examining them critically, especially by considering the value they add tounderstanding particular systems analysis and design problems. In terms of criticality, the chap-ters in this part cover critical skills developed during praxis. The Critical Framework will beinvoked in each chapter to show how systems modelling instruments are based on systems ontol-ogy. The assumptions underpinning particular systems ontology will be examined to facilitatethe development of a PCF.

136

Part III Systems analysis......................................................................................................................

6.2 Introduction

What is system requirements analysis, how doesit relate to humans and technology, and howdoes it determine the outcomes of a system pro-ject, are all problematic issues in IS development.This problem is reflected in the title of the chap-ter and is critically discussed in the section on sys-tem requirements and the Critical Framework.

The initial stage in systems analysis is deter-mining what a new IS is required to do. It is themost critical feature of systems analysis anddesign and the most challenging for analysts. It

is erroneous to assume that the simple applica-tion of requirements analysis techniques, forinstance from SSADM, results in the requiredinformation.

The difficulties in determining what a systemshould do arise when analysis techniques areapplied in the problem domain – actual situa-tions. Analysts have to overcome many issuesand problems that stem from the human andorganizational activity. They need to com-municate with people and understand what the system should do in terms of human andorganization purpose and work.

111

0

11

0111

0

0

11p

137

Chapter 6

Requirements

The system to be (or not)



• Assess the effectiveness of techniques to determine system requirements.• Critically evaluate system requirements analysis in the context of humans and

organization.• Apply critical skills to knowledge and practice of system requirements analysis.

Techniques for requirements analysis in structured and objected oriented systems ontol-ogy will be examined. The problem of determining the requirements for a new IS iscommon to both. Developing knowledge of requirements analysis and applying learnt techniques to the problem domain are vital aspects of analysts’ work.

6.3 Application domains and systemrequirements

When a new IS is developed or an existing oneenhanced it is necessary to know what functionsit should perform. This is termed the systemrequirements. System requirements are elicitedfrom the application domain and are recordedformally to provide system specification docu-ments to software programmers. They use thedocumentation to design and code computerprograms.

Knowledge of what a new IS should do iscontained in system requirements documents.Documented system requirements featureprominently in a system project and differentmethodologies have varying formats for record-ing system requirements. In systemic terms,system requirements is a statement, consistingof various types of documents, of the servicesthat a new IS should provide. Though the term‘service’ is object-oriented terminology, it isappropriate here to communicate the servicenature of IT and its application.

Determining system requirements in sys-temic terms is the process of identifying thefunctions a new IS will perform, determiningthe data for the functions to process, and defin-ing the processes that the data will be putthrough to deliver required information. In anobject-oriented system, it is the process of iden-tifying classes, objects, data, operations andrelationships in a class model.

Analysts elicit system requirements from theapplication domain. They interact with peopleto develop knowledge of the work they do, thedocuments they use, and the data and informa-tion they need to do their work. For ISrestricted to departments or sections, analystsexamine workflows, the sequence of eventsrequired to complete particular tasks, to gatherinformation about work, data and information.For larger IS, system requirements focus on

organization-wide business processes andencompass investigation of divisions, depart-ments and sections of an organization.

Clients, project managers, analysts, softwareprogrammers and stakeholders use the require-ments document as a repository of informationon a new IS. They all use it as the basis forunderstanding what a new system is required to do and for negotiating what they want it to do. Analysts use it to design systems models.Software programmers use it, and the systemsmodels developed by analysts, to write therequired suites of software programs.

6.3.1 Formal definitions of systemrequirements

Professional bodies provide formal definitions of system requirements. The Institute forElectrical and Electronic Engineers (IEEE)Standard 610 defines requirements as:

1 A condition or capability needed by a userto solve a problem or achieve an objective.

2 A condition or capacity that must be met orpossessed by a system or system componentto satisfy a contract, standard, specificationor other formally imposed document.

3 A documented representation of a conditionor capability as in 1 or 3.

There are different types of system require-ments:

• general requirements• functional requirements• implementation requirements• usability requirements.

In the SDLC requirements analysis occursonce the feasibility study is completed and thedecision to proceed with a new IS is made bymanagement. If there are existing IS, it consists

138


of determining their requirements to ascertainwhether they are being met or not. This iscalled the ‘as-is’ system. The requirements fora new IS are then determined. This is called the‘to-be’ system.

6.3.2 Systems analysts

Systems analysts are central to the process ofdetermining system requirements. Establishingsystem requirements is a significant compo-nent of their work. They work with people who need the system to understand what is requiredand they communicate these requirements tosystems designers. System requirements docu-ments produced by analysts act as communica-tive devices between analysts and users, andanalysts and software programmers.

Analysts need to develop knowledge of theproblem domain to establish valid systemrequirements. They need to know what tasksare to be supported by a new IS and map work-flows or business processes. For applicationsthat span the whole organization, a team ofanalysts normally work together to develop anunderstanding of as-is and to-be businessprocesses. They work with business analystswho share information on new business modelsto be realized in systemic terms.

Analysts undertake systems analysis activitiesto elicit requirements. The order in which theyare done vary according to the elicitation tech-niques and methodology used. The people inthe problem domain have to be consulted tounderstand what they want the system to doand existing IS analysed to assess deficiencies.Requirements may have to be negotiatedbecause of different data and information stake-holder demands. Once the requirements areestablished they have to be documented andvalidated. The validation is used to ensure thatthe documented requirements are the ‘right’ones, and to ensure consistency and complete-

ness to prevent costly mistakes. The resultantrequirements form the system specification.

6.3.3 System types and requirements

The process of determining system require-ments varies according to the types of IS devel-oped. Though the aim is the same, the processvaries if a bespoke system is to be developed ora commercial package is to be installed. In allcases, the aim is to determine what a new IS isrequired to do and ensure that it satisfies busi-ness requirements. The different types of IS forwhich requirements are established are:

• bespoke IS;• Commercial-Off-The-Shelf Software

(COTS);• business process re-engineering;• eCommerce and eBusiness systems;• knowledge management systems.

Establishing system requirements for COTS ismore difficult than for bespoke IS becauseCOTS are pre-designed IS based on businessbest practices. COTS developers establish whatis best practice in a particular business applica-tion domain, for example customer relationshipmanagement or organizational knowledgemanagement. They then design IS accordingly.Organizations that buy COTS may not havethe same practices embedded in the purchasedCOTS. They will be confronted with the diffi-cult decision of changing existing practices tomeet the COTS system or to tailor the COTSto existing practices. Determining systemrequirements in either case is highly problem-atical. It needs to be done by skilled and expe-rienced analysts. Most organizations adopting aCOTS package change their existing practicesand tailor the COTS system.

The span for analysing system requirementswill vary according to the type of IS to be devel-oped. The span may be:

111

0

11

0111

0

0

11p

139

........................................................................................................................Chapter 6 Requirements

• The whole organization. For IS tosupport business processes, eCommerce,eBusiness, or knowledge management thewhole organization is the problem domain.Such IS often have a strategic purposealigned with business strategy.

• Department, section or group. Wherespecific IS for knowledge management orstock control is to be developed the span islimited to departments or sections.

• Particular business process. When a specific process like a customer relationshipmanagement system is to be supported thespan is limited to all the activities that arerelevant for customer relationship manage-ment, but include the whole organization.

6.3.4 People’s knowledge ofrequirements

Requirements elicitation techniques are de-signed to gather information from physical doc-uments in the organization and from people.The physical sources are relatively easier toidentify and manage. Sourcing informationfrom people though is problematic. There are avariety of reasons why people’s knowledge ofsystem requirements may be limited. These arebriefly stated here and dealt with critically laterin section 6.8.3:

• People may not know what they want –people lack prescience.

• People only know what is required in context– when they actually do a job.

• Peoples’ and organization’s requirementsmay change because of internal or externalfactors.

• People are unable to communicate require-ments in technical terms.

Systems ontology and methodologies makeassumptions about people. They assume that

people are capable of perfectly knowing how IS can support them. This issue poses signifi-cant problems for analysts and requirementsmanagement. Requirements management is asignificant problem in systems project manage-ment. The people issues and physical sources ofinformation need to be managed to ensure thatthe ‘right’ requirements are elicited.

6.4 Business and systemrequirements

It is important for a new IS to be aligned withbusiness needs. At a strategy level IT and ISplanning needs to be aligned with business strategy. Analysts have to determine systemrequirements at the business strategy andsystem levels.

Some methodologies stipulate requirementsanalysis at the business and system levels.Conducting requirements analysis at both levelsensures that IS are aligned with business needs.IS developed on the basis of system levelrequirements alone fail to meet business objec-tives and consequently fail to be used asdesigned.

In the Yourdon System Method, systemsanalysts have to conduct an enterprise require-ments analysis and a system requirementsanalysis. In the Information Engineeringmethodology, there is a specific stage of execu-tive requirements analysis. It enables executivesto state their business level requirements.Critical Success Factors are identified at boththe business and system levels. SSADM also hasbusiness and system levels requirements analy-sis, though the system level techniques arebetter developed because of the engineeringfocus of the methodology. In object-orientedanalysis the Kozar’s Requirements Model spansfrom abstract rationale for requirements todetailed requirements. The model relies on an

140


existing business model and business missionstatement. Techniques for determining systemrequirements in structured systems ontologyvary. They are simply listed here:

• documentation analysis• observation• interviews• questionnaire.

6.5 Object-oriented requirementstechniques and frameworks

Object-oriented system requirements tech-niques are common to all object-orientedmethodologies. Analysts can also make use ofthe structured techniques listed above. Theirspecific tasks are to:

• identify core objects;• define the object structures and associations

between objects;• define objects’ attributes;• define objects’ methods and services;• determine the messages or communication

between objects;• refine the class model.

These tasks are completed by a variety oftechniques including those listed for structuredanalysis. In addition, other techniques include:structured meetings, scenarios, prototyping,group brainstorming, voice and emails. Thesetechniques are used within frameworks forrequirements determination in object-orientedanalysis, which include:

• requirements determination subactivities;• PIECES framework;• Kozar’s Requirements Model;• object-oriented requirements modelling

activities.

6.6 Systems modelling tools

System requirements methods and techniquesare supported with tools. The tools are largelyautomated or software packages called CASEtools. They are used to automate diagrammingin structured and object-oriented analyses.Entity-relationship diagrams, data flow dia-grams, entity-relationship models, entity life his-tories, use case, and interaction diagrams canall be developed with CASE tools. The aim ofCASE tools is to improve software productiv-ity. Other objectives include:

• improve software quality;• shorten IS development process;• reduce costs;• generate program code from design;• support and automate systems project man-

agement.

CASE tools are divided into upper CASEtools and lower CASE tools. Upper CASE toolsare used to create integrated systems model dia-grams and to store information regarding thesystem components. Lower CASE tools aredesign-phase tools. They are used to createsystems model diagrams and generate codedirectly for database system functionality.Integrated-CASE or I-CASE tools contain bothupper CASE and lower CASE functionality. I-CASE tools are designed to support the entireSDLC process and RAD. As yet there are fewweb-based CASE tools available, and theirquality is still improving.

Analysts use CASE tools to communicaterequirements to users, software programmersand stakeholders. As communicative devicesCASE tools provide a standard form and objec-tified knowledge of requirement. They facilitatecommunication between IS project teammembers and between analysts and potentialusers of IS. Other benefits of CASE tools are

111

0

11

0111

0

0

11p

141


speed of development, ease of alteration of dia-grams, consistency and validity.

CASE provides a centralized source ofinformation on systems designs called the CASE repository or data dictionary. This con-tains screen and report designs and any amend-ments made. CASE tools are available forvarious approaches to systems analysis anddesign. The following subsections describeexamples for structured, object-oriented andagile programming.

6.6.1 SELECT

SELECT is an I-CASE tool. It can be used witha variety of methodologies and is available forstructured and object-oriented analyses, andXP. It is used in the Structured Analysis DesignImplementation (SADIE) methodology in theform of SELECT Yourdon CASE tool. SADIErequires much manual diagramming which can become tedious. SELECT is designed toautomate the process to achieve cost and timeefficiencies.

6.6.2 Database tools

The use of the data dictionary in database management systems has evolved. Theextended data dictionary is a systems repositoryrather than a simple data dictionary. As asystems repository it is considered to be a CASEtool for information on systems processes andprograms. Systems repositories are useful formanaging IS projects, in particular ensuringsystem integration.

CASE tools are used for indexes and cluster-ing in physical data models. The Erwin CASEtool has an index screen for database tables,which is used to generate code required to construct indexes in a Database ManagementSystem (DBMS). A DBMS is software for datastorage and its manipulation.

6.6.3 eXtreme programming

The SELECT Scope Manager is used in XP.It is used to minimize time, cost and develop-ment by managing the scope of software devel-opment. It is used to automate the Story andTask scope management in XP. It creates astructured log of the stories, ideas, documentsand analysis generated in XP. It also allows‘what-if ’ analysis.

6.6.4 Object-oriented case tools

CASE tools for object-oriented analysis coversystems analysis, design and implementation,and they extend to code generation and script-able HTML reports. They are used to developmodels of software and business systems, andare available for specific object-orientedmethodologies.

The Bridgepoint tool is designed to supportthe Shaler-Mellor Method of Object-OrientedAnalysis and Recursive Design. CRC (Class,Responsibility, Collaboration) CASE tools areused to create CRC cards and scenarios involv-ing object interactions, to define objects, and runinteractional scenarios to check systems designs.

SELECT Enterprise is used to design anddevelop complex object-oriented applicationsusing UML. The Enabler function frees design-ers from having to remember to save work asit is done automatically.

6.7 Alternative requirementstechniques

Structured and object-oriented system require-ments make difficult ontological assumptionsabout the problem domain. An example is theassumption that people know what they wantthe system to do. People are expected to becapable and willing to state system require-ments. In practice, these assumptions are prob-lematical. Alternative requirements elicitation

142


techniques like prototyping and eXtreme pro-gramming have been proposed to addressrequirements elicitation problems and otherproblems in requirements gathering.

The alternative techniques compress theSDLC. Quicker IS development is assumed tolead to lower costs. They shorten the time takento establish requirements or place less empha-sis on establishing requirements from peopleand other physical sources by providing thesystem product earlier. Involving people andproviding the system product earlier reducesreliance on peoples’ memory and knowledge ofrequirements, and enables them to see thedevelopment process and product.

6.7.1 Rapid application development

RAD is closely related to systems project man-agement. It shortens the software developmentprocess and reduces systems project manage-ment activities. It is used to develop small andenterprise-wide systems.

RAD has four phases: requirements plan-ning, user design, construction and cutover.CASE tools and prototyping are used in the userdesign and construction phases. Unlike theSDLC, or structured and object-oriented analy-ses, RAD requires the involvement of peopleworking in the problem domain. They becomeparticipants in the IS development process.Their participation is essential in the require-ments phase, design phase and the system-building phase. In the requirements planningphase both analysts and people conduct JointRequirements Planning ( JRP). During thedesign phase their participation is limited tonon-technical issues through the JAD technique.

RAD is closely linked to prototyping. Thepurpose of allowing people to participate is toprovide them with the required product early.As potential users they can assess the productearly and give comments for its further

enhancement. Unlike products resulting fromthe SDLC, the RAD process results in variousversions of the product to help potential userssee it, make comments and voice requirements.

6.7.2 Prototyping

It is difficult for people to visualize what asystem will do from a list of requirementscontained in a requirements document. In prototyping an original version of the proposedsystem is developed to explore and validatesystem requirements. A prototype of a new ISis built to understand and define the problemitself.

A prototype is used to demonstrate thesystem to users. People and analysts can learnmore about the business problem and what thesystem should do by using the prototype in theapplication domain. Most organizations findprototyping is worth the cost in learning aboutsystem requirements, especially for IS that arestrategically important.

Prototyping is used to understand systemrequirements iteratively. By using the prototypepeople can see the system as it is currentlyunderstood and use the experience to elaboratewhat the eventual system should do. Actualwork situations can be tested with the prototypeto determine whether it satisfies business needs.

In incremental prototyping or evolution-ary prototyping system requirements are estab-lished iteratively. As each version of the proto-type is assessed it provides clearer understand-ing of what is required. This information is used to develop the next version, and so on. In incremental prototyping the actual prototypeseventually becomes the implemented system.

A throwaway prototype is a single version ofthe proposed system. It is used for a specific pur-pose like determining requirements. A throw-away prototype is used to understand deepersystem requirements that cannot be easily

111

0

11

0111

0

0

11p

143


established by normal techniques. Most proto-types used for eliciting requirements are notused as eventual IS, they are ‘thrown away’ afterrequirements have been understood. Thoughsome may result in the eventual system.

6.7.3 Agile Software Development andeXtreme programming

Agile Software Development (ASD) is gainingcredibility in some problem domains, wherehighly structured and formalist methods do notwork. It can be traced to adaptive systemsdevelopment. ASD focuses on people and thesocial context rather than processes andmethods for software development.

It is a response to the problem of ‘analysisparalysis’ in structured and object-orientedsystems ontology. The phrase ‘analysis paraly-sis’ captures the problems in the actual appli-cation of objective systems ontology. In ASDsystem requirement is conducted incrementallyand iteratively in small work packages withusers and stakeholders. It focuses on the processof development rather than the software, andrather than focus on plans and detailed plannedaction, it plans for change.

XP has a similar focus on people rather thanprocesses. Whereas ASD focuses on people inthe problem domain, XP focuses on the systemsproject team too. It recognizes the socialcontext in which IS is developed, and attemptsto keep things simple to ease communication inthe project team and with customers, who areinvolved with the team on a daily basis. Theyalso make system decisions and changes. Thisclose involvement of ‘customers’ is thought tolead to a shared understanding of the system.

People write stories of their work experi-ences, which are used instead of requirementsdocuments. These stories are used to determinethe scope, content and estimates. The ‘stories’are very short, about three sentences, and are

used to estimate how long it would take toimplement relevant code.

Like ASD, XP focuses on small releases butits practices are based on metaphors that helpthe team to perceive the system being devel-oped in simple terms. Each story is allocated upto a three week estimate for implementation,where a story is estimated to take longer thanthree weeks it is simplified into more than onestory. In contrast, if a story is estimated to takeless than a week to implement, it is combinedwith other stories.

6.8 System requirements and theCritical Framework

The Critical Framework is useful to bring tosurface and assess critically assumptions onsystem requirements made in structured andobject oriented systems ontology. Figure 6.1 isthe Critical Framework populated with criticalreflection on system requirements. As thebottom layer shows, many questions concern-ing the four themes of criticality arise fromassumption made in structured and object-oriented analyses.

Analysts need to question what is meant by system requirements. The PCF can beenhanced by assessing the value and limitationsof the available tools and techniques. Structuredand object-oriented requirements analyses isbased on objective systems ontology. Theyassume that requirements exist as separate enti-ties in the application domain, whether in theminds of people or in physical documents in theorganization. A critical appreciation of systemrequirements needs to address:

• What are system requirements?• How do system requirements relate to

human and organized activity?• How does IT and IS relate to humans and

organization?

144


111

0

11

0111

0

0

11p

145

Apply formalmethods


(Messy world)

Contextual knowledge,people lackprescience –

cannot know allrequirements,

requirements change,limited capability ofrational accounts,

people attachmeanings and

interpret information

Systemsontology

SDLC formalism

Assumes people haveknowledge ofrequirements

and can rationallyelaborate them

Pragmaticresolution

???



Resolveproblems


Do requirements exist asentities?

Is it possible that peopleonly potentially knowwhat they require?


How can contextuallytied requirements be

abstracted?

Critical skills

Figure 6.1 Critical framework: people’s knowledge of system requirements in the real world


• Is requirements analysis a timebox event orcontinuous?

• Are requirements independent entities in theproblem domain or inherent in humans?

6.8.1 What systems analysis?

Analysis is difficult. It requires deliberate seg-mentation based on clear purpose of what isobserved. Analysing something obvious is evenmore difficult because the obvious becomes sonatural that it is difficult to differentiate it fromoneself, or even becomes ‘embodied’. Forexample, analyse how you ride a bicycle ordrive a car – they are embodied acts. Analysesleading to innovation, something new, forexample a new IS, is the most challenging. It isdifficult because it is not possible to draw on rel-evant previous experience or knowledge.

The complexity of analysing what a new ISshould do is caused by various factors. Analystshave to approach people to determine systemrequirements. The intentions of analysts andthe people they depend on to establish require-ments are not clear to each other. It is possiblethat people may withhold important informa-tion. Organizational context is another factorimpinging on establishing requirements. Itbecomes more difficult to establish systemrequirements in changing contexts comparedwith stable contexts. Stakeholders are a criticalfactor, as they will be vying for influence andeven control over what the system should do.Other factors to consider are actual work, work-flows and business processes. All these have tobe understood in context. Other issues aresummarized in Table 6.1.


The SDLC, prototyping and XP make differ-ent assumptions of the application domain andsuppose many characteristics that constitute

systems ontology. The SDLC works on thebasic premise of objectification of systemrequirements. In comparing the SDLC andprototyping it can be seen that prototypingallows for requirements to emerge. It does notassume requirements as entities existing in theapplication domain. In the SDLC once require-ments are established as entities a further erro-neous assumption is made that they are fixed.

XP is a radically different process for ‘learn-ing’ about the problem domain and systemrequirements. Its systems ontology is signifi-cantly different. It challenges the SDLC’sassumption that analysts are best placed toperform requirements analysis from their posi-tions of technical power. It assumes that require-ments need to be learnt rather than assumed toexist independently and elicited by analysts.Unlike the SDLC, XP makes use of humantechniques to learn what system requirementsare relevant. By using human stories and nar-ratives provided by people it makes IS develop-ment more accessible to people and reduces theburden on them to specify requirements.

The term requirements engineering is usedin structured systems ontology. There are somefundamental problems with the underlyingpremise of requirements engineering and theconsequent systems ontology. It assumes thatusers are capable of explicitly and unambigu-ously stating what they expect a new IS to do.When designing artefacts like bridges it is pos-sible to specify technical aspects and functions.Though even civil engineers sometimes have to learn from their mistakes, as the sway inLondon’s millennium bridge testifies. Thedesign of an IS is different because the com-puter system has to satisfy human needs, whichthemselves being based on human intent,purpose and usage are difficult to establish.They raise uncertainty that the engineeringmetaphor cannot adequately address.

146


111

0

11

0111

0

0

11p Tab

le 6

.1Is

sues

in

requ

irem

ents

ana

lysi

s

Issu

esS

yste

ms

onto

logy

Abs

trac

tion

Req

uire

men

ts a

s ab

stra

ctio

ns o

f th

e ap

plic

atio

n T

he S

DL

C a

nd s

truc

ture

d an

d ob

ject

-ori

ente

d an

alys

es b

ased

on

it

dom

ain.

How

can

con

text

ually

tie

d re

quir

emen

ts b

e ab

stra

cted

?as

sum

e re

quir

emen

ts a

s ab

stra

ctio

ns.

XP

and

AS

D r

elat

es d

irec

tly

to t

he c

onte

xt b

y re

lyin

g on

sto

ries

and

narr

ativ

es.

Obj

ecti

ficat

ion

Req

uire

men

ts a

s en

titi

es i

n th

e ap

plic

atio

n T

he S

DL

C a

nd s

truc

ture

d an

d ob

ject

-ori

ente

d an

alys

es b

ased

on

it

dom

ain.

Is

it p

ossi

ble

to e

licit

req

uire

men

ts f

rom

an

assu

me

requ

irem

ents

are

ent

itie

s in

the

app

licat

ion

dom

ain,

and

the

y ap

plic

atio

n do

mai

n? D

o th

ey e

xist

as

enti

ties

? C

an

can

be o

bjec

tifie

d. T

hey

assu

me

it i

s po

ssib

le t

o de

sign

not

atio

n re

quir

emen

ts b

e re

pres

ente

d an

d ar

e cu

rren

t no

tati

on

lang

uage

s to

mod

el o

bjec

tifie

d re

quir

emen

ts.

lang

uage

s ad

equa

te f

or r

epre

sent

ing

requ

irem

ents

?X

P a

nd A

SD

rec

ogni

ze t

he h

uman

bas

is o

f re

quir

emen

ts.

Spe

cific

atio

nR

equi

rem

ents

can

be

spec

ified

. D

o pe

ople

T

he S

DL

C a

nd s

truc

ture

d an

d ob

ject

-ori

ente

d an

alys

es b

ased

on

it

wor

king

in

the

appl

icat

ion

dom

ain

know

wha

t is

mea

nt b

y as

sum

e th

at p

eopl

e do

kno

w w

hat

they

req

uire

fro

m t

he s

yste

m –

‘r

equi

rem

ents

’ an

d do

the

y kn

oww

hat

they

req

uire

? C

an t

hey

repo

rts,

fre

quen

cy,

gran

ular

ity.

The

y as

sum

e th

at a

gree

d ag

ree

requ

irem

ents

am

ong

them

selv

es a

nd w

ith

othe

r sp

ecifi

cati

on i

s po

ssib

le.

stak

ehol

ders

? T

here

is

a lim

it t

o w

hat

an i

ndiv

idua

l or

gro

up,

Pro

toty

ping

, X

P a

nd A

SD

all

reco

gniz

e th

e in

crem

enta

l le

t al

one

orga

niza

tion

, ca

n sp

ecif

y ra

tion

ally

. B

eyon

d th

at

reve

lati

on o

f re

quir

emen

ts.

The

y do

not

dep

end

on a

tim

e-th

ings

bec

ome

appa

rent

in

the

doin

gac

t on

ly,

or ‘

embo

died

ba

sed

syst

em s

peci

ficat

ion

docu

men

t.kn

owle

dge’

or

situ

ated

act

ion.

Eng

inee

ring

Req

uire

men

ts a

s en

gine

erin

g. A

re r

equi

rem

ents

T

he S

DL

C a

nd s

truc

ture

d an

d ob

ject

-ori

ente

d an

alys

es b

ased

on

it

suffi

cien

tly

tang

ible

to

be e

ngin

eere

d? A

naly

sts

may

fra

gmen

t as

sum

e th

at p

rinc

iple

s of

art

efac

t en

gine

erin

g ca

n be

app

lied

to

requ

irem

ents

bec

ause

of

the

met

hods

the

y us

e (t

hey

shou

ld

requ

irem

ents

bec

ause

req

uire

men

ts l

ead

to a

phy

sica

l sy

stem

. de

velo

p in

tegr

ated

req

uire

men

ts).

Ana

lyst

s m

ay n

ot d

evel

op a

T

hey

assu

me

that

a c

ompl

ete

set

of r

equi

rem

ents

can

be

elic

ited

co

mpl

ete

set

of r

equi

rem

ents

. A

naly

sts

do n

ot a

sk d

etai

led

and

deta

iled

syst

em f

unct

iona

lity

spec

ified

.qu

esti

ons

to d

eter

min

e re

quir

emen

ts –

‘w

hat

info

rmat

ion

do

XP

and

AS

D a

band

on t

he e

ngin

eeri

ng m

etap

hor.

The

y gi

ve

you

need

fro

m t

he s

yste

m?’

is

too

gene

ral.

prim

acy

to p

eopl

e an

d in

tera

ctio

n ra

ther

tha

n ri

gour

and

met

hod.

Fix

edR

equi

rem

ents

as

reifi

ed o

bjec

ts.

How

can

req

uire

men

ts

The

SD

LC

and

str

uctu

red

and

obje

ct-o

rien

ted

anal

yses

bas

ed o

n it

ke

ep p

ace

wit

h bu

sine

ss o

bjec

tive

s an

d te

chno

logi

cal

assu

mes

tha

t on

ce i

dent

ified

req

uire

men

ts a

re fi

xed.

Rea

l hu

man

op

port

unit

y?pr

oble

ms

need

to

ackn

owle

dge

emer

ging

and

cha

ngin

g re

quir

emen

ts.

XP

and

AS

D r

ecog

nize

thi

s du

ring

dev

elop

men

t. E

volu

tion

ary

and

adap

tive

sys

tem

s en

able

fun

ctio

nal

chan

ges

post

-im

plem

enta

tion

.

The issues outlined in Table 6.1 are not anexhaustive list nor are the questions they raiselimited to those detailed. They need to befurther explored in terms of the CriticalFramework, and in particular in terms ofsystems ontology and organization ontology.

6.8.3 Systems ontology andorganization ontology

Analysts need to address how to incorporate the phenomenological characteristics of humaninteraction into the systems development pro-cess and the eventual IS developed. Pheno-menological aspects of human behaviour arenot accounted for by the SDLC, structured andobjected-oriented systems ontology. Assump-tions of rational human behaviour negate theinterpretation that humans place on informationand knowledge.

Notions of system requirements are rooted insystems ontology. The issues in Table 6.1 arisebecause methodologies assume and define thingsin the problem domain in particular ways. In thewider sense, the problem domain is the organ-ization for which assumptions and definitions aremade. The problem arises when these assump-tions and definitions, or organization ontology, is contrary to systems ontology. For example,assumptions about people in system require-ments gathering are problematic in practice.The assumption that people have the capabilityto communicate how IS can support them is oneexample that poses significant problems.

The main purpose of the SDLC and struc-tured analysis is to provide: (a) a complete setof system requirements; (b) system requirementsthat are unambiguous; and (c) no redundantdata in the system requirements and eventualsystems design. These three are the ‘elusivetrinity’ because no structured approach iscapable of delivering them in real situations –human problems. They assume not only that

system requirements can be identified, but alsothat once identified system requirements willremain constant until the end of the systemsdevelopment project.

Important questions on what a new IS isexpected to do or how system requirements canbe established become operational withincertain systems ontology, which may not reflectactuality. Figure 6.1 illustrates the basic contra-diction between systems ontology and the realworld (organization ontology). It shows thatassumptions made in systems ontology arecontrary to the actual experience of gatheringrequirements in the human problems.

This contradiction is reflected in commu-nicative problems between analysts and peopleand between analysts and other systems projectteam members. The achievement of systemproject objectives is based on assuming acommon understanding among team membersand stakeholders. The initial problem of com-municating among professional developers isovercome in the SDLC by developing stan-dards. The SDLC and structured and object-oriented systems ontology provide a consistencyof standards that enables professional develop-ers to communicate from a common, objectivebase. These standards make it easier to monitorand control a system project.

Defining appropriate systems ontology fororganizations is reflected in developments insystems modelling for databases. Table 6.2shows the different database model types thathave been used in IS. Their progressive devel-opment suggests a significant gap betweensystems ontology and organization ontology.Practitioners and researchers assume thatformal models are necessary. Until formal mod-elling can reflect real situations adequately thegap between systems ontology and organizationontology will persist.

Analysts need to be aware that there arecompeting modelling notations and analysis

148


techniques for translating business needs intosystem requirements. They reflect the develop-ing knowledge and practice in systems ontology,and the unsolved problem of understanding theproblem domain. It is recognized that systemsontology needs to reflect reality but it is con-strained by instrumental, technological andconceptual tools. System requirements gather-ing techniques assume that the resultant state-ment of requirements bear synergy with theproblem domain. Very large and expensive ISprojects have failed at the business level despitethis focus on business.

6.8.4 Methods of enquiry

SSM is rooted in academic interpretive actionresearch and it proffers to seek epistemologicalrelevance. It relates the work of systems analystsdirectly to systems analysis and the problemsanalysts encounter in investigating ‘humanactivity system’. It bases investigations of humanactivity systems on a ‘declared-in-advance epis-temological framework’. This is an ‘intellectualframework of ideas’. The framework forms thebasis for defining and expressing knowledge. Itmay be subsequently modified on the basis ofresearch findings.

111

0

11

0111

0

0

11p

149

Table 6.2 Database model types used in Information Systems

Model type Comments

Hierarchical Hierarchy is an ordered tree and intuitive. As a modelling notation it is rooted inmathematics, which does not reflect the richness of human intent andorganization goals and activities.

Network Network is composed of a record type and a set type. As a modelling language itis rooted in mathematics, which emphasizes the representation of rich human andorganizational context as logical relations.

Relational A relation is a construct to represent the associations among different entities andtheir attributes. As above, its mathematical roots require human andorganizational information to be represented as tables and relations between thetables.

Object-oriented A class is composed of object with similar attributes. Objects are related throughthe messages they pass to each other for particular services or operationsrequired. Interacting and collaborating objects form a system. Objects seemcapable of representing rich human contexts such as ‘aspects’ and ‘roles’.

Semantic Semantic databases can be based on the concept of ‘semantic net’. They havebecome popular because of XML, and make use of XML-algebra for formaldefinitions of data operations and transformations to prove completeness andcorrectness of design methods.

Post-relational Post-relational databases enable the convergence of object and SQL technology.An example is Matisse, which combines Object, XML and SQL technologieswithin a single database.

Deductive Deductive databases are an extension of relational databases. They supportcomplex data modelling not suitable for relational databases. A deductivedatabase consists of a database (facts), knowledgebase (rules) and an inferenceengine (the logic), which is used to derive information from the database usingthe knowledgebase. An example of an inference engine is Datalog, used to developa relational deductive database system.


Analysts similarly need to be aware of any‘intellectual framework of ideas’ and the role ofmethods of inquiry underpinning the systemsontology they adopt. Most commercial method-ologies do not venture into questions of episte-mology. When they do, the search is superficialto give academic credence. As systems analysistechniques purport to establish knowledge of sys-tem requirements it is pertinent to question thevalidity of these techniques. Analysts need toreflect on epistemic issues relating to determina-tion of system requirements. Knowledge of howto develop IS and knowledge of the IS to bedeveloped are questions of epistemology. Theyrequire critical study to assess practical validity.


6.9.1 Personal constructs for systemrequirements

Activity A

Table 6.3 is a sample repertory grid for systemrequirements. Reproduce the grid on a spread-

sheet and add further columns and their polar opposites that you consider relevant. To objectify system requirements personal con-structs, complete the grid by following thedetails on how to use a repertory grid in section1.10.1.

Analysts can use knowledge from practicalexperiences of requirements elicitation to probe the themes in the Critical Framework,which may lead to revising personal constructsand determine an appropriate pragmatic reso-lution to problems. They should begin theobjectification process by asking questionssimilar to:

• Why did I choose questionnaires to elicitrequirements?

• What evidence is there that questionnairesare successful?

• Can people relate to questionnaires or did itdistance them?

• How do questionnaires relate to my otherpersonal constructs about peoples’ know-ledge and their ability to communicate it?

150


Table 6.3 Personal constructs for system requirements

Pole 1 Pole 2

Planned Emergent

Articulated Hidden


Complete Incomplete

Ambiguous Unambiguous

Static Changeable

Perfect Imperfect

Abstract Context

Sys

tem

s an

alys

t

Org

aniz

atio

n

Em

ploy

ees

Req

uire

men

ts

Obs

erva

tion

Doc

umen

t an

alys

is

Inte

rvie

win

g

6.9.2 Problem domains and systemsontology

Questions

1 With reference to Activity A, discuss howontological knowledge of organization affectsthe design of instruments for systems analy-sis and design.

2 Critically compare the ontological basis ofrequirements gathering in SSADM andMultiview methodologies.

Activity A

In pairs, each person:

• Identify a problem domain familiar to you,a university department or company depart-ment.

• Record your knowledge of the domain interms of the assumptions you make of itsorganization, people, work and informa-tion required, and any other aspect youchoose.

• Compare your ontological knowledge of the department with a trusted peer.

• Would you revise your ontology? In eithercase, explain why.

6.9.3 IS types and requirements

Questions

1 How would you proceed to establish systemrequirements for a large multinational car manufacturing company wanting to buy a COTS supply chain managementpackage?

2 Describe the requirements gathering tech-niques you would use to establish systemrequirements for a medical doctor’s patients’records management. Justify your choices.

3 Comment on how you would overcome theproblem of changes made to the system afterfreezing the design. How would you ensurethat such changes do not remain undocu-mented features of an IS?

Activity A

• Describe the major functions for a studentrecord system and locate your description inappropriate systems ontology.

• Surf the net for a COTS student recordsystem.

• Assess whether the COTS system meets therequirements you identified.

• Critically evaluate the COTS systems ontol-ogy with your description.

6.9.4 Aligning IS and businessobjectives

IT/IS planning is intricately related to corpo-rate strategic planning. A company needs toplan its IT/IS development to meet businessobjectives.

Questions

1 How are IS projects selected in your organ-ization? In considering this question, thinkabout the following:Does the organization have a mission state-ment and a corporate strategic business plan(three years or one year)? How is the missionstatement and business plan used in IS plan-ning? Can you identify specific projects toexemplify?

2 What IT/IS planning activity are you awareof in your organization?What role do potential users of IS play inselecting IS projects?

111

0

11

0111

0

0

11p

151


3 Identify a formal IT/IS planning processthat includes users and critically discuss itsrelevance.Is IS project selection a ‘top-down’ (set bysenior management) or ‘bottom-up’ (deter-mined by operational employees) approachin your organization, or a combination of thetwo?What problems can you identify in theIS/IT planning process? Are important usersor stakeholders facilitated to take part in theplanning process, if so how?

6.9.5 Requirements techniques

Questions

1 Discuss the comparative merits of observa-tion, interviews and questionnaires forrequirements elicitation.

2 Describe in detail the situations in which youwould use each type.

3 Structured analysis aims to use a minimumnumber of tools to specify a system. Discussthe veracity of this position.

Activity A

Design interviews to establish requirements foran admission system or human resource man-agement system from:

• An admissions tutor in a university depart-ment or head of a human resource depart-ment.

• The admissions principle in the university’scentral department for admissions or thedirector of human resources in a company.

Activity B

• Surf the internet to find sites on RAD andXP.

• Critically compare RAD and XP to identifydifferences in systems ontology between thetwo for requirements gathering.

• What assumptions of the problem domaindoes RAD make that XP does not?

6.9.6 CASE tools

Activity A

Deciding which CASE tools to use poses prob-lems. Some advice is to be clear of the purposeand to keep the criteria simple.

• Develop criteria for selecting CASE tools forrequirements analysis.

• Search the internet to identify availableCASE tools for structured and object-oriented requirements analyses.

• Justify your choices for each approach.

6.9.7 Representations of reality

Questions

1 Discuss whether it is better to write softwareprograms directly from the problem domainas in ASD practice, or from systems modelsproduced by systems analysts as structuredand object-oriented analyses do.

2 Discuss how you think your PCF affects yourways of seeing a particular problem domain.Assess how the component and personalconstruct relationships affect requirementselicitation.

152


111

0

11

0111

0

0

11p

153


See www.agilelalliance.org and www.agilemanifesto.org/history.html for ASD perspective andphilosophy (accessed 25 March 2004).

See www.dsdm.org for details on adaptive systems development (accessed 25 March 2004).

See http://www.xprogramming.com/xpmag/whatisxp.htm for information on the philosophyand principles of XP. Also see http://www.jera.com/techinfo/xpfaq.html for a simple introductionto XP (accessed 25 March 2004).


Checkland, P. and Holwell, S. (1998) Information, Systems and Information Systems, Chichester: Wiley.


7.2 Introduction

A logical data model depicts data in theproblem domain that is considered of interestor important to business people. It providesanalysts and designers with knowledge and

understanding of relevant data to be processedand the processes for processing it in a new IS.Business data and processes in the operation andmanagement of the organization are used todevelop the data and process systems models. Itis also called an ‘infological’ data model because

154

Chapter 7

Structured data modelling



• Interpret the problem domain in terms of logical data models, entity types, attributesand relationships.

• Evaluate critically the entity-relationship modelling technique.• Assess the importance of logical data modelling for database design.• Describe the normalization process.• Develop simple E-R models.

Structured analysis focuses on transaction data in the problem domain. The structuredmodelling process allows for the redesign and integration of complex IS using data andprocess models. The term ‘logical’ means removed of physical characteristics. Logicaldata modelling is the process of logically describing the problem domain. Logical datamodelling separates design from systems implementation. They are used to develop logicaldata models. This separation of the logical modelling of the system from its implemen-tation will be discussed critically.

Structured systems analysis and design introduced the discipline of planning in dataand process models to IS development. The focus on data in the problem domain makesstructured analysis ‘data-centric’. Techniques and tools have been devised to interpretdata as pre-existing entities in the problem domain.

it is a data or information perspective separatedfrom physical implementation.

Structured analysis assumes that it is possi-ble to plan and develop complete logical datamodels for a new IS before it is implemented.It requires systems analysts to:

• Identify and define the problem domain –people, processes, documents.

• Develop ‘infological’ or logical data andprocess models.

• Convert the logical models into the physicaldesign for computer implementation.

Analysts’ task is to identify ‘things of inter-est’ in the problem domain and design datastructures suitable for computer processing.Logical data models are an initial diagrammaticpicture of a new IS. The purpose of logical datamodels is to determine what data is to beprocessed and decide how it is organized.

The process of data modelling makes use ofthe decomposition problem-solving strategy orthe top-down problem-solving. If the problemwere to be solved as a whole it would prove tobe too complex. In the decomposition strategy,a complex IS problem is taken and it is decom-posed into smaller parts. Breaking the problemdown into simpler, smaller problems enablesthe sub-problems to be solved independently ofeach other. The independent solutions are thencombined to provide an overall solution to theproblem. The modelling process is not expectedto produce the final system data models the firsttime. It relies on an iterative model-buildingprocess.

7.3 Transaction data

Organizations generate two types of transac-tions data. One, it results from transactionwithin an organization, for example hiring anemployee. Two, it also results from transactions

between an organization and its customers,business partners or government agency, forexample making a sale or buying raw materialsfrom a supplier. Transactions data covers prod-ucts or services, employees, customers, financeand the government. An organization will typ-ically generate hundreds of thousands or mil-lions of such transactions depending on its size.Not all transactions data is recorded.

Transaction data that is legally required orconsidered relevant for managing is recordedand processed to produce information andknowledge. The executive and management inan organization will be interested in analysesand summaries of the transaction data or otherspecial information to support decision-makingand management. Managers will need it to sup-port business operations management. Forexample, credit controllers need an analysis ofcustomers by their payment record to check thecredit worthiness of customers. The analysis ofunpaid invoices can be structured in descendingorder of overdue date. Identifying, collectingand processing such data for managementinformation is done in logical data modelling.

In structured systems ontology transactionsdata are regarded as independent items. Theyare part and parcel of a conceptual entityderived from data or processes in the actual sit-uation – problem domain. An entity is any‘thing of interest’ in the problem domain thatneeds to be represented in an IS. For example,in a customer relationship management system,‘customer’ is an entity and the ‘product’ or‘service’ bought by the customer are examplesof other entities. The selling of a product is datathat is related to the customer entity.

Understanding the business rules in anorganization identifies things or entities of inter-est. Operational issues in turn determine busi-ness rules. For example, in an internet bookclub, decisions have to be made on whether amember can place more than one order. The

111

0

11

0111

0

0

11p

155

....................................................................................................Chapter 7 Structured data modelling

policy decision becomes a business rule that can be used to identify entity types, relation-ships, and cardinality.

Logical data modelling is used to develop anintegrated picture of an organization’s data forcorporate databases and various IS that draw onthe databases. Most organizations store transac-tions data on computer databases to provide acentral store which various IS access to produceoperational and management information.Such database design requires an integratedapproach to enable the development of inte-grated IS that provide consistent information tomanagers. Failures in the integrity and consis-tency of information can result in poor man-agement decisions, which affect a company’sperformance.

7.3.1 Structured data and processsystems models

A model is an analytical conceptual tool. It doesnot capture the problem domain as it is but asan abstract representation of it. A systemsmodel is made using a formal notation and isnormally diagrammatic. The modelling nota-tion used is not the actual computer program-ming language used to write the eventualcomputer programs. In this respect structuredanalysis is computer-independent. It is separ-ated from the computer implementation of thesystem. The logical system data and processmodels have to be subsequently converted intocomputer design and code.

From analysts’ perspective, an importantfeature of systems models is that they are objec-tified representations of the problem domain.(Objectification is not the same as objectivity.)Objectification is the process of externalizingmental ideas or constructs for others to share.An early justification for the development ofstructured analysis was that objectified data andprocess models enable communication among

systems project professionals and betweensystems analysts and people.

In structured analysis logical data models aredesigned first and then the logical processmodels. They are developed to facilitate com-munication, check assumptions and under-standing, and test proposals. As the actualproblem domain cannot be comprehended andunderstood in its entirety, aspects of it are takenand represented in a model. Only details of theproblem domain that are of interest are mod-elled, other details are not modelled. Thepurpose of a model is to:

• develop knowledge and understanding;• enable communication;• analytically generate alternatives;• determine relationships between entities;• design implementable systems models.

Data and process models are developed togather knowledge and understanding of thetransaction data in a problem domain. Themodels are not to be understood as the actual

application domain. It is because the actualapplication domain is complex and difficult tocomprehend that models are developed. Themodels resulting from structured analysis areused to inform systems design.

The various data and process models developed provide three different perspectiveson a system. The perspectives are data, processand entity life. Together they provide anoverview of a new IS. They are related andenable checks to confirm consistency. Forexample, process and data stores in dataflowdiagrams in process modelling are related toentities in an E-R diagram in data modelling.An entity in data modelling is related to anentity life history model if its life history is mod-elled. A process is related to an entity life historyas events in it.

156


7.4 Logical data modelling

Techniques and tools for structured logical datamodelling have been developed to representdata in the problem domain as logical data mod-els. The techniques are supported with CASEtools. They prescribe systems analysis activitiesfor analysts and consist of the following:

• entity relationship diagrams;• logical database descriptions;• data dictionary for the project.

The term ‘logical’ refers to data and pro-cesses in the problem domain from which allimplementation dependent – physical – charac-teristics are removed. The term ‘structure’emphasizes the need to provide frameworks thatanalysts can use. The frameworks describe activ-ities, detail steps and stages, and define inputsand outputs required for systems modelling.

An analyst’s task is to develop entity-relationship diagrams (data models) using theentity-relationship modelling technique. Twosystems analysts may develop two completely different entity-relationship models of the sameproblem domain. The entity-relationship mod-elling technique is individually (subjectively)applied leading to individual (subjective) logicaldata models. Subjectivity is not considered to bea problem in structured logical data modelling.Experienced data modellers are regarded highlyfor their ability to determine relevant businessrules that lead to appropriate logical data models.

7.4.1 Entity-relationship modelling

Analysts develop entity-relationship diagramsor E-R models of transactions data in theproblem domain. E-R modelling serves to rep-resent things of interest to the organization(entities) and determines their relationships witheach other. A result of the E-R model is data

tables that enable analysts to define the neces-sary set of operations on the data to produceoperations and management information. In atypical E-R modelling process the analyst will:

• identify the problem domain, or relevantsections of the domain;

• identify things of interest in it;• identify and name entity types;• determine each entity type’s attributes;• determine the relationship types between

entities;• draw an entity diagram model;• normalize the entities and relationships.

E-R modelling is an iterative process. A final E-R model will be the result of several itera-tions, especially when developing the modelinto third normal form or higher.

Entity

An entity is anything in the application domainthat can be represented by name, attributes andrelationship. It is an abstraction of a thing in theproblem domain that generates data that isstored. An entity is important because it pro-vides information on actual data to be processedin a new IS. Entities are classes of concrete orabstract things in the problem domain. Theycan be physical things in the problem domainor ideas or concepts relevant to the operationand management of an organization.

Both technical modelling skill and knowledgeof the problem domain are required to identifyentity types. Data is generated and stored foreach occurrence of entity types in the problemdomain. Analysts examine transactions data toidentify relevant entities, which are shown incapital letters in descriptions of a system.Analysts decide whether a thing of interest in theproblem domain is an entity or an attribute, andthey give a name to the identified entity type.

111

0

11

0111

0

0

11p

157


Predicates are used to determine entity typesbecause they describe a problem domain. Forexample, as thousands of sales occur in acompany, an abstraction capable of recordingall the sales is required. Consider a sales trans-action description that an analyst might use toidentify relevant entity types:

In this description of a sales operation, trans-actions data on the sale of goods can beanalysed to identify various physical andabstract entity types. Entity types can be iden-tified from a text document in the problemdomain by underlining the nouns, as shown inthe box above. The sale or purchase is an entity.The sales assistant is an entity. The customerwho makes the purchase is an entity. The itempurchased and sales receipt are entities. Thesale price is an attribute of the sale entity witha value (cost) of £99.00.

The underlined entities can be named asentity types in capital letters: SALE, SALES_ASSISTANT, CUSTOMER, ITEM andSALES_RECEIPT. An entity type is a groupof similar objects in the problem domain, forexample CUSTOMER entity type.

The identification of entities and entity types is non-trivial. Consider the followingdescription of an employee:

The same person in the organization mayhave different roles. Freda is both an experiencedfinancial accountant and a senior manager.Analysts need to determine how best to organizeuseful information by skilfully identifying entitytypes for database design. They have to decidewhether to create separate entity types for these two roles of the individual in the organiza-tion, say FINANCIAL_ACCOUNTANT andSENIOR_MANAGER, or to create one entitytype, say FINANCIAL_ACCOUNTANT andadd an attribute for management skills – seniormanager. The latter is an efficient solution interms of normalization.

Relationship

Relationships between entities establish themeaning or semantics of the logical data model.Analysts identify the relationships between theentities. As entity types have no meaning ontheir own, they need to be expressed as rela-tions for business operations and managementinformation. Defining relationships is animportant feature of logical data modellingbecause it determines the eventual usefulness ofthe IS to people.

Relationships can be identified from facts in the problem domain. For example, it is a fact that the SALE and ITEM entity types arerelated to the CUSTOMER entity type, becausea sale occurs when a customer makes a pur-chase of an item. This fact is an example of abusiness rule. Business rules form a significantbasis for establishing relationships betweenentity types.

Managers rely on relevant relationships def-initions for operational and managementinformation. For example, a sales executiveinterested in generating more sales to make theorganization profitable will seek answers tocertain questions. They may ask questions such as: ‘Which item is selling more?’ ‘Which

158


A customer makes a purchase of a DVDunit. It costs £99.00. The sales assistantrecords the sale on the till, which generatesa sales receipt for the customer.

An employee Freda Ericsson is an experi-enced financial accountant. She works in the finance department. She is one of the senior managers of the financedepartment.

customers are buying the most?’ Information onthe former question will help to produce moreof the popular item. Information on the latterquestion will help to target customers who gen-erate the most income. Such information canonly be generated if appropriate relationshipsbetween entity types are determined.

The value of an IS occurs when it is able to provide valid, accurate and timely infor-mation to decision-makers. So the ‘right’ rela-tionships need to be modelled. Since logicaldata modelling is a subjective process, analystsrequire knowledge of the problem domain and its detailed operations to ensure that entity types are appropriately identified andrelated.

Attribute and keys

Analysts identify the properties or attributes ofentity types. Attributes are emboldened in adescription of the problem domain. The attrib-utes of the SALE entity type are: DATE,RECEIPT_NUMBER, ITEMS, CREDIT_CARD_NUMBER, AMOUNT, VAT. Attri-butes have values that provide details of partic-ular sales. Each sale made will have valuesrecorded for each attribute, even if the value iszero. For example, a customer may make a cashpurchase so there will be no value recorded inthe CREDIT_CARD_NUMBER attribute.Attributes appear in the data dictionary asprimitives.

As many sales will be made each sale needsto be identified by an attribute uniquely, this is called the RELATION KEY or KEYATTRIBUTE, shown as underlined. In theSALE entity type, the RECEIPT_NUMBER isthe key attribute. Its value or receipt numbercan be used to uniquely identify any particularsale, no other sale will have the same value forreceipt number.

An attribute key can consist of more than one attribute of an entity type. The attri-

butes of the CUSTOMER entity type may be: NAME, CUSTOMER NUMBER,ADDRESS, TELEPHONE_NUMBER. Thekey attribute for the CUSTOMER entity typeis the group of attributes CUSTOMER_NUMBER and NAME. The attribute NAMEcannot be the key attribute because there maybe two customers with the same name John Smith or Risha Patel. CUSTOMER_NUMBER and NAME can be used to identifyuniquely a customer.

Consider the following:In the above description of the hotel problem

domain, an analyst may identify GUEST,EMPLOYEE, ROOM and AGENT as entitytypes. The attributes of the GUEST entity typemay include: FIRST_NAME, FAMILY_NAME, ADDRESS, GUEST_NUMBER,REGISTRATION_DATE, and ROOM_NUMBER. The attributes identified ofEMPLOYEE may include: NAME,NATIONAL_INSURANCE_NUMBER,ADDRESS, SKILLS, SALARY, LINE_MANAGER. The key attribute for the GUEST is GUEST_NUMBER and for the EMPLOYEE it is the NATIONAL_INSURANCE_NUMBER.

Attributes have a value. Table 7.1 shows theattributes and values of the entity type GUEST.The entity and its attributes are a record of thefacts about the entity.

Entity types are defined in table types similarto Table 7.1, but without the value column.The key attribute normally appears first and theother attributes below it. If a key is composed

111

0

11

0111

0

0

11p

159

A hotel receives a guest from a bookingagent. The guest registers with the hotelclerk who takes the guest’s name andaddress, and records the length of stay andallocates a room.


of multiple attributes they are listed above theother attributes.

7.4.2 Types of relationships

The relationship in an E-R model is used torepresent an association between entity types. Arelationship between entity types is named. Inthe hotel example, the GUEST entity type isrelated to the ROOM entity type by the rela-tionship OCCUPIES, as shown in the E-Rdiagram in Figure 7.1. An E-R diagram is inter-preted by reading every relationship in bothdirections. A GUEST occupies a ROOM or aROOM is occupied by a GUEST. A GUESTmay occupy one ROOM.

The relationships between entity types varyin accordance with logical, social, organiza-tional and physical aspects of the problemdomain. Relationships are defined on the basisof the business rules established by analysts.Business rules are how the organization oper-ates based on its objectives, policies and proce-dures. In a hotel, rooms are for occupation byguests and earn a rent for the company.

The relationship types are called the cardi-nality of the relationship because a relationshipbetween entity types has a specific number.Cardinality defines the numeric relationshipbetween occurrences of the entities on eitherside of the relationship line, they are defined inTable 7.2. For example, in the E-R diagram in

Figure 7.1, the relationship between theGUEST and ROOM entity types is one-to-one(1:1) because a guest normally occupies oneroom. (It is possible for an individual guest tooccupy more than one room, say for examplewhen someone may book several rooms for a wedding function.) Another example of a one-to-one relationship is that one person isresponsible for a department’s budget.

Analysts have to determine the cardinality ofthe relationship between entity types. Theyneed to examine each entity type in turn tocheck how many entities occur. The informa-tion to determine the cardinality of the rela-tionship between entity types is found in thelogic of the problem domain or the businessrules established in conceptual data models. Inthe example from section 7.4.2, hotel occu-pancy determines how the identified entitytypes are related, as shown in Figure 7.1.

7.4.3 Normalization

Normalization is used to develop relational datastructures for relational database design.Normalization is a series of steps followed toobtain a database design that allows efficientstorage and access of data in a relational data-base. It is based on relational calculus and it istheoretically derived. Analysts need to be awareof normalization but do not necessarily need toexplain how it works.

160


Table 7.1 Entity type, attributes, values

Entity type Attributes Value

GUEST GUEST_number 007007

GUEST_first_name Risha

GUEST_family_name Patel

GUEST_address 1 Kensington Place

GUEST_registration_date 20/12/03

GUEST_room_number 234

Normalization is the process by which entitytables are simplified so that each item of datastored for an entity is in its simplest form. Thepurpose of normalization is to remove redun-dant data items from a set of entity type tablesto make database storage efficient. It is used toeliminate data redundancy by removing entityattributes that may be stored more than oncein relational tables. The normalization pro-

cess is based on functional dependencies andrelation keys or key attributes.

There are various forms of normalization.An entity type table in a relational databasesystem is in normal form if it satisfies certainconstraints as defined in Table 7.3.

Normalization is extended to 4NF and 5NF.In 4NF the check is for multivalued depen-dency. In 5NF the check is for multivalued

111

0

11

0111

0

0

11p

161

OCCUPIESGUEST ROOM

Figure 7.1 Naming entity type relationships

Table 7.2 Entity relationship types

Cardinality of relationship Description

One-to-one (1:1) The one-to-one cardinality is defined for entity types when oneoccurrence of the entity type is related to one other occurrence of adifferent entity type.

CUSTOMER transacts one SALE (1:1)

CUSTOMER has one INSURANCE POLICY (1:1)

EMPLOYEE has one NI_Number (1:1)

NI_Number has one EMPLOYEE (1:1)

One-to-many (1:m) The one-to-many cardinality is defined for entity types when oneoccurrence of the entity type is related to many occurrences of adifferent entity type.

SALE contains many ITEM (1:m)

CUSTOMER can buy many ITEM (1:m) (each item is bought by onecustomer).

DEPARTMENT has many EMPLOYEES (1:m)

DEPARTMENT has many EMPLOYEES (1:m) but each EMPLOYEEbelongs to one DEPARTMENT.

Many-to-many (m:n) The many-to-many cardinality is defined for entity types whenoccurrences of multiple entities in a entity type are related to multipleoccurrences of another entity type.

STUDENT can enrol on many MODULES (m:n)

PART can have many COLOURS (m:n)

EMPLOYEE can be on many PROJECTS (m:n)


redundancy. These higher orders of normaliza-tion ensure that relational data structurescontain the simplest and non-redundant datastructures.

In the CUSTOMER entity type, the attrib-utes name and address are functionally depen-dent on the key attribute customer number.There are no redundant data items for the CUS-TOMER entity type, as for each CUSTOMERthere is only one record of name and address.

The five rules of normalization stated insimple terms are:

1 Eliminate repeating groups. Make a separatetable for each set of related attributes, andgive each table a primary key.

2 Eliminate redundant data. If an attributedepends on only part of a multi-valued key,remove it to a separate table.

3 Eliminate columns not dependent on key. If attrib-utes do not contribute to a description of thekey, remove them to a separate table.

4 Isolate independent multiple relationships. No tablemay contain two or more l:m or m:n rela-tionships that are not directly related.

5 Isolate semantically related multiple relationships.There may be practical constraints oninformation that justify separating logicallyrelated many-to-many relationships.

7.4.4 Logical database design

The logical database model is a layer of designbetween people who use the data in a databaseand the physical database. People who use thedata are employees, managers, and executives.They each have different needs from the data– this is called their ‘logical view’ of the data.The physical database is the way that data isactually stored in a database on a computer.The term ‘physical’ refers to implementationdependent characteristics of data and process-ing. It describes how data is stored andprocessed on computer disks, tapes and paper.

The logical database model allows differentlogical views of the stored data in the database.For example, a credit controller needs informa-tion on payments made or outstanding and aproduction manager needs information onquantities and types of products ordered. The

162


Table 7.3 Relational data structure normalization

Normal form Comments

First normal form (1NF) No repeating groups of attributes and all attributes entered. Eliminaterepeating groups by putting each repeating group in a separate tableand connect it with a one-to-many relationship. Every piece ofinformation stored in each of the rows of the table should be atomicor indivisible.

Second normal form (2NF) If it is in 1NF and every entity attribute that is not part of the keydepends on the whole key. Second normal form eliminates functionaldependencies on a partial key by putting the attributes in a separatetable form those that are dependent on the whole key.

Third normal form (3NF) If it is in 2NF and each entity attribute not part of the key attributedepends on the key attribute. Third normal form eliminates functionaldependencies on non-key attributes by putting them in a separatetable. At this stage, all non-key fields are dependent on the key, thewhole key and nothing but the key.

logical database contains the overall structure ofthe database not the physical storage.

In the logical database, similar objects fromthe problem domain are collected into entitytypes and represented by their cardinality. E-Rmodels contribute to the system architecture de-sign of a logical database. They are used todevelop the logical views. The E-R models depict the database structure. They need to be converted to logical record structures, or the ‘logical database’ for the detailed physicaldatabase design.

The CUSTOMER entity type from section7.4.1 with its attributes is translated into a logical record structure, shown in Table 7.4.The logical record will store data or values on the customer’s NAME, FIRST_NAME, CUSTOMER_NUMBER, ADDRESS, ANDTELEPHONE_NUMBER. The same is donefor the SALE and ITEM entity types.

7.5 Documentation

The deliverables from system requirementsanalysis, data and process modelling activitiesare tangible products. Documentation is a deliv-erable from data and process modelling. Thedifferent kinds of documents produced inSSADM as an example are:

• diagrammatic reports• forms• matrices• narrative reports.

Documentation is easier with CASE tools,which produce higher quality documents thatcan be rapidly amended while preservingintegrity and consistency across diagrams. Thedeliverable from data modelling is a set of E-Rdiagrams and from process modelling a set ofcoherent, inter-related data flow diagrams.

7.5.1 Data dictionary

The data dictionary is a key element of a system project. It is a data resource for systemsanalysts and systems designers, and other teammembers. It contains information on the IS to be developed and other sources of informa-tion on it, and on existing systems. It containsall the required information to develop an IS,including data definitions and systems pro-grams, and databases information. As it con-tains information on the data used in the systemor other IS, its content is also called ‘meta-data’.Meta-data is data that describes or explainsother data.

A relational database design results in manyentity type tables that become difficult tomanage and access. The data dictionary storesinformation on these tables. It containsinformation on the logical data and processmodels, and collation of other system informa-tion. In terms of entity types it would containinformation on the CUSTOMER, SALE,ITEM entities from section 7.4.1. It containsinformation on the logical process models anddata definitions.

111

0

11

0111

0

0

11p

163

Table 7.4 Logical database records based on entity definitions

CUSTOMER_ FIRST_NAME CUSTOMER_ ADDRESS TELEPHONE_SURNAME NUMBER NUMBER

Romonavich George 001007 1 Chelsea Place 0208 5758 4890

Patel Risha 007007 1 Kensington Place 0208 3892 9240

Brown Andrew 006911 2 Tedlow Gardens 02789 881 998


7.6 Data modelling and the CriticalFramework


The systems ontology component of the CriticalFramework is the basis for uncovering andexamining premises in logical data modelling.It supposes certain systems ontology that ana-lysts need to appreciate and evaluate. Figure 7.2is the Critical Framework populated with criti-cal reflection on logical data modelling and the E-R notation. As the bottom layer shows, manyquestions concerning the four themes of criti-cality arise from the assumption of logical datamodelling.

To develop knowledge and practice, analystsusing structured logical data modelling requireparticular personal constructs. They need tounderstand the objectivist systems ontology ofstructured logical data modelling. Analysts needto consider ‘objectivity’ as a particular personalconstruct and its development in practice.Objectivity is the ability of a systems analyst tobe detached and impartial of the subject beinginvestigated, and to analyse the problemdomain with detachment and impartiality, freeof any bias.

Development of E-R diagrams is central instructured logical data modelling. E-R model-ling assumes an objective problem domainwhere data exist independently of analysts andpeople. Whether data entity types or data-centric view is a sufficient characterization ofthe problem domain is an issue for analysts toconsider in terms of critical skills for applyingstructured instruments.

Analysts job is to determine business rules,identify entity types, their attributes and rela-tionships. A critical issue is how this can beachieved. It is possible that two analysts maydevelop entirely different E-R diagrams con-taining different entity types, attributes andrelationships for the same problem domain.

Two different E-R diagrams on the sameproblem domain raise questions about the inde-pendent existence of entities and objective mod-elling. A team of analysts working togetherwould need to reach consensus. This meansthat in practice – the real human problems –subjective definitions have a significant role instructured analysis.

7.6.2 Real problem domains

Representations of reality are only as sophisti-cated as the notation language used. The E-Rnotation is based on a mathematical represen-tation of reality – relational calculus. It relies on a representative sample, the business rulesextracted from the facts in the problem domain,to define data structures. It is arguable whetherhuman activity in organizations can be repre-sented in mathematical terms and whether arepresentative sample is sufficient for IS in adynamic business environment. The UMLobject-oriented notation leads to an arguablybetter reflection of reality and human activity.Its development constitutes a transformatorycritique of ontological knowledge and practice.

Structured logical data analysis and systemsontology define human problems – organiza-tion and its human activity – in terms of entitytypes. It further assumes that three types ofobjects can represent the problem domain: (a)entity type, (b) relationship, and (c) attribute. As analysts have to learn to interpret theproblem domain in terms of these three objects,they need to consider whether they are suffi-cient to represent the complex social reality thatis human organization.

Structured data analysis assumes that systemsanalysts can create logical data models that canbe translated into systems implementation mod-els. Analysis in actual situations poses barriers foranalysts. A significant barrier is communicationwith people. E-R diagrams are intended to facil-itate communication but people do not generally

164


111

0

11

0111

0

0

11p

165

Apply formalmethods


(Messy world)

Business rules change,subjective meaning ofinformation for people

Systemsontology

Structured logicdata models

Things of interest,business rules,

objectivelogical models,

abstractdata entities,

relations,and cardinality

Pragmaticresolution

Develop a simpleprototype

???



Resolveproblems


Can people participate toidentify business rules?

Critical skills

How can the complexityof E-R models be

communicated simplyto people?


Is the data-centric viewsufficient?

Figure 7.2 Critical framework: systems ontology based on logical data modelling


understand them, and even analysts find non-trivial E-R diagrams difficult to interpret.

Analysts have to question business opera-tions and processes to seek out inefficiencies andimprove effectiveness. Representing theproblem domain as E-R models poses difficul-ties for improving organizational efficiency andeffectiveness. E-R models are not rich enoughto enable analysis of organization. Structuredlogical data modelling itself does not facilitatethis search for business performance improve-ments. Analysis should produce alternativebusiness process models that take advantage ofIT. Radically alternate uses of IT based on busi-ness process notations, rather than structurednotations, have been spurred by businessresearch, for example BPR, and business prac-tice, for example eCommerce. An example isthe Role Activity Diagram (RAD) notationwhich depicts roles, activities and relationhips.

7.6.3 The representative power ofnotations

The representative and communicative powerof notation languages is significant for systemsontology. Notation languages provide acommon language with which analysts cancommunicate with other systems project teammembers, users and stakeholders. Analysts’ useof E-R diagrams as communicative tools needpurposeful thought. It is easier for other ana-lysts, programmers and database administratorsto share the mutual and common understand-ing of E-R diagrams. It is not so transparent forpeople. They are not technically capable ofunderstanding the E-R notation and so cannotmake intelligible observations or comments.

There are limitations of notation languagesto represent the problem domain and functionas communicative tools. The E-R notation is notsufficiently rich to represent a problem domain.Its focus on data and data effectiveness is at the

expense of reflecting social and organizationalelements in a problem domain. The social andindividual dimension is now accepted know-ledge and practice of IS. These limitations haveled to other forms of IS development like XP.XP is an example of transformatory critique and refashioning of traditions originating withinthe practitioner community. It makes use of‘user stories’, which are used to establish systemrequirements and inform the IS development.

7.6.4 Analysts’ objectivity

During the 1990s the new IS models completelytransformed organization on the basis of BPRknowledge resulting in human resource cost sav-ings. The systems models analysts produce aimto achieve such business efficiency effectiveness,and improved productivity. Detachment andimpartiality is sometimes onerous on analystswho have to point out the problems with cur-rent IS and recommend cost savings or jobredundancies. Objective practice is questionablewhen analysts work closely with people.

To be objective analysts need to predeter-mine analysis activities. They need to makeplans of how a particular systems analysis will beundertaken. Despite the objectivity criteria, twosystems analysts may develop two completelydifferent E-R diagrams for the same problemdomain. Rather than being objective, the E-Rnotation is subjectively applied. Subjectivity isrecognized and permitted in alternative systemsontology, for example ASD or prototyping tosome extent. In prototyping systems models aredeveloped iteratively and in consultation withpeople. The emphasis on individuals rather thanformalism in ASD recognizes subjective views.

7.6.5 Corporate databases

The challenge in data modelling is to developrelevant data models and databases such that

166


they cater for past and future data requirements.Companies have tried to develop ‘enterprise-wide information architecture’, but mostly failedbecause of system integration problems, andincurred high costs. One persistent problem isthe localized or fragmented data stores neededfor various IS and the lack of integration.

In actual situations there is a constant needto update databases to reflect localized businesschange. Also, new data models are emergingthat lead to a transformatory critique of E-Rmodelling. For example, image and voice dataare now a significant element of organizationaldata too, requiring new data models combiningtraditional transaction data, image and sound.

The development of corporate databasesthrough data analysis is problematic and lessplausible with constant business change. Onesolution has been to consistently redefine data,but this is costly to do. Another is to optimizedata structures to deliver speed and flexibility,but this results in more time spent doing datamodelling, whereas the trend is to shorten ISdevelopment time.


7.7.1 Personal constructs for data,information and knowledge

Table 7.5 is a sample repertory grid for data,information, and knowledge. Reproduce thegrid on a spreadsheet and add further columnsand their polar opposites that you consider relevant. To objectify personal constructs indata, information and knowledge, complete thegrid by following the details on how to use a repertory grid in section 1.10.1.

7.7.2 Systems ontology and the problemdomain

Questions

1 Evaluate whether E-R modelling is a suffi-cient notation language to represent aproblem domain.

2 As an analyst, discuss whether you wouldwant to develop objective data models.

111

0

11

0111

0

0

11p

167

Table 7.5 Personal constructs for data, information and knowledge

Pole 1 Pole 2

Stable Fluid

Can capture Cannot capture

Can model Cannot model

Apply Cannot apply

Process Cannot process

Logical Physical

Fact Interpretation

Abstract Real

Dat

a

Info

rmat

ion

Kno

wle

dge

Bus

ines

s tr

ansa

ctio

n

Not

atio

n la

ngua

ge

Mod

el

Act

ual

Mea

ning


Provide analytical examples to illustrate yourposition.

3 Structured logical data modelling is based onthe premise that an optimal and efficientsolution can be obtained for a problem.Critically discuss.

Activity A

Analysts have to decide what ‘things of interest’to include in an E-R model. The choices madeaffect how the problem domain is conceived, orhow they define the real world. E-R models candistort the issues in the problem domain. For aproblem domain of your choice:

• Identify and justify entity types, attributesand relationships.

• In what ways do your choices limit repre-sentation of real human problems?

• What is the significance of the limitation ondecision-makers, who will eventually use theinformation produced, and the organiza-tion?

Activity B

Structured logical data modelling requires ana-lysts to:

1 Identify the relevant physical organization –people, transactions, documents – or theproblem domain.

2 Develop ‘infological’ or logical data models.3 Convert the logical models into the physical

design for computer implementation.

In a group:

• Identify a problem domain, say universitystudent records or supply chain managementin a company.

• Make a list of the physical things of interestin the problem domain.

• In ‘infological’ terms, explain why the thingsyou identified are of interest.

• Make a list of the entity types of interest, foreach entity type determine its attributes, andstate the cardinality of the relationshipsbetween entities.

• With a peer discuss whether ‘infological’ is arelevant personal construct for you.

7.7.3 Conceptual and logical datamodels

Questions

1 The notion of ‘model’ is a significant intel-lectual tool for framing, analysing andunderstanding actual human problems.Critically evaluate the role of modelling inIS development.

2 Evaluate the importance of abstract modelsin the process of IS development. (InvestigateASD as an alternative.)

Activity A

Before E-R diagrams can be developed, ana-lysts need to develop conceptual data modelsfrom the problem domain based on the ‘busi-ness rules’. Consider the following facts orthings of interest in the Human Resourcesdepartment problem domain: department, divisions, employees, function, roles and skills.

Some gathered information on the things ofinterest is:

An employee always has a job title.An employee always has zero or more skills.An employee always has one and only one role.

Sample Facts: Risha Patel is a software pro-grammer currently working in the IS depart-ment as a project manager. Brenda Jones is adatabase specialist currently working in the ISdepartment as a database administrator.

168


• Define the area of interest.• Define the things of interest.• Analyse the things of interest and identify the

corresponding tables.• Establish the relationships between the tables.

7.7.4 E-R models

Questions

1 In real human problems practice and theapplication of formalism like E-R notation todevelop IS is important. Discuss the valueformalism has for you as a systems analyst.

2 Explain why you would decide to representan object in the problem domain as one ormore entity types rather than as attributes ofan entity type.

Activity A

In pairs each person:

• Independently look at Figure 7.3 and writea description of the problem domain youthink the E-R model represents.

• What assumptions have you made in yourdescription?

• Compare your description and assumptionswith your peer.

• Discuss the problems subjectivity raises forinterpreting E-R data models.

Activity B

• Select an organization familiar to you.• What are the entity types of interest in it?• List the attributes of each entity type.• Underline the attribute in each entity type

that is its unique identifier.

7.7.5 Separation of systems design fromimplementation

Questions

1 Evaluate the benefits to structured systemsontology of computer-independent design.

2 What kind of problems might arise in trans-lating or transforming analysis models intoimplementations (design models)?

111

0

11

0111

0

0

11p

169

TEACHINGALLOCATIONLecturer Module

Research activity

Figure 7.3 Teaching allocation relationship


170



An excellent source for definitions relevant to data modelling is the following website:http://www.datamodel.org/DataModelDictionary.html. Also look at www.datamodel.org as itoffers a community of data modellers.

Surf http://www.databaseanswers.com/data_model. It provides free data models. You canexamine a variety of structured and object data models and the associated information on database design.


Schmidt, B. (1998) Data Modelling for Information Professionals, New York: Prentice Hall.

Reingruber, M. and Gregory, W. (1994) The Data Modelling Handbook: a Best-Practice Approach to Building

Quality Data Models, Winchester: Wiley.

8.2 Introduction

A logical process model depicts processes thattransform data into other data or information.Like logical data modelling, structured logicalprocess modelling is the development of non-implementation specific logical process models.The models are of the logical process requiredto complete business tasks or processes. Processmodelling is a descriptive act in which theorganization is interpreted in terms of processes.Descriptive process models ‘describe’ howprocesses are enacted in the problem domain.

Logical process modelling removes physicalreferences from the process description such aswho does what, using what medium, and wherein the process. If physical aspects were to be

modelled it would restrict systems design deci-sions later. The purpose of logical process mod-elling is to objectify or determine all thefunctions or data transformation required in thesystem. Process models are used as a commu-nicative device among the systems project teamand with people.

Processes are dynamic and reflect the natureof business organizations. A typical businessprocess in a manufacturing company is a salesorder process, for which transaction data is gen-erated. It involves a customer contacting thecompany to place an order. Sales make a recordof the details of the order, accounts generate aninvoice, production produce the goods, andtransportation ship the finished goods to thecustomer.

111

0

11

0111

0

0

11p

171

Chapter 8

Structured process modelling



• Interpret the problem domain in terms of processes and data flow diagrams.• Develop simple DFD diagrams with DFD notation and logic modelling techniques.• Analytically evaluate the role of process modelling in IS development.• Critically assess how well data flow diagrams describe a problem domain.

Process modelling is important in structured analysis. It determines how a new IS willfunction to produce required information. It draws on the E-R models from logical datamodelling to define system functions and data processing.

Logical, also called ‘infological’, processmodels provide a process perspective of a newIS. Processes can be defined in terms of whatthey produce. A sales order process results in asales order being generated, or a marketresearch process results in a marketing plan.Analysts refer to the series of actions requiredto generate a sales order or a market plan as‘logical business processes’ or processes. Theterm ‘process’ describes the series of actions thatpeople take to complete a task, like taking a cus-tomer order or producing a marketing plan.Taking an order for a sale requires a clerk totake details of the customer, number and typeof units required, and to pass them onto pro-duction. In efficiency terms, process modellingcovers actions taken to achieve an objectivesuch as customer relationship management, thesales process or a market research process.

8.3 Process modelling techniques

Process modelling techniques are formalism forrepresenting processes as systems processmodels. The developed process systems modelsdemarcate the things to be performed by thecomputer system from things that people domanually. They set the boundary betweenhuman activity and computer processing. Suchmodels describe what data transformation the system will do and how the data will betransformed.

The process modelling technique used in structured systems analysis is Data FlowDiagrams (DFDs). Another structured tech-nique is State Transition Diagrams. The DFDprovides a graphical representation of processesor functions in the problem domain that willcompose a new IS. It shows data transformationthrough processes that capture, manipulate,store and distribute data between componentswithin a system and between a system and itsenvironment.

8.4 Data flow diagrams

The DFD is used to depict the scope of a newIS, show the interaction of humans with thesystem, and the system with its environment.Analysts’ task is to identify the processes,develop process models and write documenta-tion to record the findings. DFD depict howdata is processed in system terms with initialinputs, and outputs from processes used asinputs for other processes. The DFD depicts:

• context• system boundary• processes• inputs• outputs• subsystems• interface.

A DFD depicts how logical data movearound in a system. It describes logical data atrest, moving, and being transformed orprocessed. There are four types of DFD:

• Current physical: description of the existingphysical system, if one exists.

• Current logical: description of the ‘info-logical’ existing system, if one exists.

• New logical: description of the new ‘info-logical’ system required.

• New physical: description of the new physi-cal system.

Usually all four types are developed by analysts.The current physical process model is devel-oped to gather information about the problemdomain. The current logical process model isdeveloped to separate the logical processes fromthe physical things they depend on to be accom-plished. These models can be analysed toexamine current processes and workflows. Thenew logical process models are developed to

172


depict system requirements, and they removeany inefficiency observed in current physicaland logical process models. The new physi-cal process models are developed to describeimplementation features.

8.4.1 DFD notation

There are many notations for drawing DFD.The one adopted here is shown in Figure 8.1.Definitions of the symbols are given in Table 8.1.

Analysts make some typical errors in drawingDFD. These are summarized as:

• connecting an external source directly to adata store;

• showing a process with no outputs;• showing a process with no inputs;• connecting a data store directly to another

data store.

Following the rules listed in Table 8.1 canprevent such modelling errors.

8.4.2 Levels, decomposition andbalanced DFD

Detailed DFDs are drawn at different levels ofgranularity using the decomposition or thedivide and conquer problem-solving strategy. Itenables a complete set of requirements to becaptured. Decomposition results in levels ofDFD that contain further detailed descriptionof the process and sub-processes. This methodis called functional decomposition or levelling.It is an iterative process consisting of breakingthe description or perspective of a system downinto finer and finer detail. Decomposition ofprocesses is performed until no further benefitis gained by further decomposing a DFD. Theresult is a set of hierarchically related DFD inwhich one process of a given DFD is explainedin greater detail in another DFD.

The extent of levelling depends on the levelof abstraction required. Skilled analysts are ableto decide which processes to decompose furtherand when to stop decomposing a particularprocess. The general rule is to stop when themost primitive activities of the process isreached. This is the lowest logical or elemen-tary level of the process, which cannot befurther decomposed.

Levelling begins with a Level 0 diagram. TheLevel 0 diagram, also called a context diagram,is a top level DFD. It shows the process node –process 0 – as a general representation of theentire system in terms of external entities. Theprocess node at Level 0 is a black box withinputs and outputs. The details of how it con-verts inputs into outputs are not known butbecome clearer when the process is decom-posed further. It depicts time, volume and fre-quency issues in the system, and shows coupling

111

0

11

0111

0

0

11p

173

................................................................................................Chapter 8 Structured process modelling

Process

Data store

Source/sink

Data flow

Figure 8.1 DFD notation

174


Table 8.1 Definitions of DFD symbol notations and DFD drawing rules

Symbol label Definition and drawing rules

Process A process is the work or actions performed on data so that they are transformed,stored or distributed within or outside of the system.

Every process is triggered by an event.

Every process uses or transforms data.

Rules

A process cannot only have outputs.

A process cannot only have inputs.

A process has a verb phrase label.

Data store A data store is data at rest.

Rules

Data cannot move directly from one data store to another data store. A process canonly move it.

Data cannot move directly from an outside source to a data store or move directlyfrom a data store to an outside source. It must be received by a process and placedinto a data store and placed into an outside source by a process.

Data cannot move directly into an outside sink from a data store. A process must putit there.

A data store has a noun phrase label.

Data flow A data flow is data moving from one process in a system to another. Also referred toas data that move together.

Rules

Data flow can only flow in one direction.

A fork indicates a copy of the same data flowing.

The same data coming together in a coming location is a join.

Data flow must be processed before returning to the same process it came from.

Data flow to a store means updating either through deletion or change.

Data flow from a store means retrieve or use.

A data flow has a noun phrase label.

Source/sink A source is the origin of data and a sink is the destination of data.

Rules

Data cannot move directly from a source to a sink. A process must put it there.

An object with only outputs is a source.

An object with only inputs is a sink.

A source or sink has a noun phrase label.

Source: Adapted from Celko, J. (1987) ‘I Data Flow Diagrams’, Computer Language 4 (January): 41–43.

and decoupling of entities. Entities are coupledwhen one entity is bonded with another. Theyare decoupled when the bond is weaker.Coupling is important during systems designwhen programs have to be designed and coded.Decoupled programs are easier to maintainwhen changes in the problem domain need tobe reflected in them.

When the Level 0 DFD is decomposed it isnecessary to conserve the inputs and outputs insubsequent sub-processes. Data flows present atone level should also be present in a subsequentdecomposed level. This is called balanced DFD.An unbalanced set of DFD result when inputsor outputs at one level are not reflected at afurther decomposed level. An example is whena process in the context diagram has one exter-nal source but at level 1 the same process hastwo external sources.

An example context diagram for a universityPC inventory system is shown in Figure 8.2. Itdepicts a business problem domain. It shows theoverall ‘system’, the system boundaries, exter-nal entities and inputs and outputs. Everythingwithin the boundary, Process 0, will be per-formed by a new IS and everything outside theboundary is the system’s environment – supplierand maintenance contractor. Demarcation ofthe boundary is the first decision for physicaldesign, because it shows what the computer willdo. The boundary may cut across processes

indicating that some processes will be comput-erized in part only. This is more explicit in theSSADM methodology.

Points at which humans interact with thecomputer system over the boundary become thehuman–computer interaction interfaces (userinterface), or system interfaces with other IS, orsources of data. Analysts establish a list of eventsin the system’s environment to which the systemneeds to respond. These events may numberinto the thousands for complex systems.

At Level 1 shown in Figure 8.3, the nodeprocess in Level 0 is decomposed into otherprocesses and each sub-process has its businessobjectives. Two processes are modelled calledClerk Logs Invoice and Accounts Pay Invoice.A data store is created called Invoice File. The arrows show the flow of data between theprocesses and between the processes and thedata store. Subsequent decomposition leads tofunctional primitives or the elementary level,which through process logic modelling, areconverted, through systems design, into pro-gramme code.

8.4.3 Entity life history

As a DFD is weak at identifying events or data,entity life history (ELH) diagrams are used toensure that the system has a response for all theinternal and external events. An event is any

111

0

11

0111

0

0

11p

175

University PCinventory system

Maintenancecontractor

Invoice

Supplier

Payment

0

Payment

Figure 8.2 DFD context diagram for a PC inventory system


occurrence in the entity’s life. For example, forthe entity type INVOICE, logging an invoiceand settling the invoice are events. It is the ‘lifehistory’ of the entity in the system, and can bedrawn for logical or physical entities. In struc-tured systems analysis, the life of an entity con-sists of three types of events sufficient torepresent the complexity of any life:

• sequence• selection• iteration.

Figure 8.4 shows the basic life of the invoiceentity with two nodes’ details shown to thirdlevel. Using SSADM notation it shows sequence,selections and iteration. It must have a ‘birth’,events that happen during its ‘life’, and a time ofits ‘death’. Selection is shown with a ‘0’ in thebox and iteration is shown with a ‘*’. For exam-ple, an invoice is received, processed and paid.The received invoice is logged as either for cash

payment on receipt or three month credit, so itis shown as a selection with a ‘0’. Processing aninvoice is iterative, so it is shown with a ‘*’.

ELH diagrams ensure that errors in theDFD are corrected before the system boundaryis fixed. Such diagrams can be complex withseveral levels of detail. They also show the timedimension of events. Analysts normally onlydevelop ELH for entities that are important orcomplicated.

The E-R model, DFD and ELH diagramsmust be balanced. They must reflect the samecontent and be logically consistent. Suchabstract data and process models enable ana-lysts to ‘walkthrough’ the systems design withpotential users to verify system requirements.

8.5 Process logic modellingtechniques

When a DFD is decomposed to its elementaryor primitive level, analysts have to describe its

176


Clerk logs invoiceMaintenance

contractor

Invoice

Supplier

Payment

1.1

Payment Dat

aS

tore

1

Invoice file

Invoice data

Accounts payinvoice

1.2

Figure 8.3 Level 1 DFD for PC inventory system

process logic. The action taken to transformtransaction data into business information istermed business logic. Process logic may bedescribed as the data-to-information trans-formation and decisions on data. It is not quitepseudocode or programming language specificbut sufficiently detailed to describe businesslogic. The term process logic describes the busi-ness actions taken on data, or what a processdoes and how it does it. Determining processlogic results in a model descriptive of how theprocess is controlled and the detailed actiontaken on data in it.

For example, in a customer order process,decomposition may result in a sub-process forcalculating discounts given. The discount policymay consist of giving percentage discountsdepending on the size of the order and distanceof delivery. So there will be various discountdecisions. Process logic modelling is used toprovide detailed descriptions of these discountdecision actions.

There are many notations for depictingprocess logic. They enable clear and unam-

biguous descriptions of activities on data in aprocess. As the techniques are not complemen-tary, analysts need to select an appropriate onefor describing the logic of elementary processes.The choice will depend on the complexity ofthe business logic in the process. The logicalmodels can be developed using a variety ofnotations:

• structured English• decision tables• decision trees• action diagrams• Nassi-Schneiderman diagrams• entity life cycles• flow charts.

Logic modelling involves representing theinternal structure and functionality of theprocesses depicted in the DFD. Like the DFD,logic diagrams require iterative refinement.Analysts share their work with people to seekfeedback for correctness checking. Process logicmodels serve to provide an unambiguous and

111

0

11

0111

0

0

11p

177

Log Process Pay

Invoice

Cash ondeliverypayment

3 monthcredit

Raisecheque

Checkamount

Checkservice

completed

*

00

Figure 8.4 Entity life history form


thorough explanation of the system’s specifi-cation. The deliverable from logic modellingare structured descriptions and diagrams of the logic of each DFD process. Logic modelsshow the temporal dimension of system – whensomething happens and how it happens.

8.5.1 Structured English

Structured English (SE) is a modified form ofEnglish used to specify process logic. SE isprogram-like structured English descriptions ofprocesses that use simple sentence constructionsand logical constructs. It is used to model thebusiness policies or rules in the problem domainand to refine models of business processes.Process logic can be refined with SE to a levelwhere all parties can understand unambigu-ously the process being described. This isregarded as a benefit for communication ofprocess logic modelling with SE.

SE uses action verbs like read, write andmove to describe action on data, and noun-phrases like stock-item or high-value-customerto describe entities. It uses four types of logicalconstructs: sequence, conditional statements,repetition, and case. Examples are shown forbusiness policies in Table 8.2.

The logical constructs used in SE are alsoused in structured programming, which makesSE suitable for process implementation, orprogram code. SE is not suitable for describingprocess logic with large number of variables inthe process. In such situations decision tablesare more appropriate.

8.5.2 Decision tables

A decision table is used where the businessprocess logic is more complex. A decision tableis based on a declarative format that is clear andsuitable for communication and program spec-ification. Decision tables are used for displaying

large amounts of complex data. A decision tablehas a condition stub, action stub and conditionrules, as shown in Figure 8.5 (a). A limited-entrydecision table with process logic is shown inFigure 8.5 (b).

In Figure 8.5 (b), the decision table shows aPC manufacturing company’s discount policy.The number of condition entries depends onthe number of conditions and the binary (Y orN) entries in decision tables. Since there arethree conditions and two possibilities for each,the number of columns required is 23 = 8.

Reading down the first condition entrycolumn, a customer with a sale of more than£20,000, who has been with the company formore than two years, and has a repeat sale isgiven the maximum discount of 10 per cent. Inthe eighth column a new customer with a saleof less than £20,000, who has not been withthe company for two years, and makes their firstsale is given no discount. Other columns showthe other permutations. During the iterativedevelopment of the table it is possible to reducethe number of columns similar to the functionaldecomposition in DFD.

Extended entry decision tables are usedwhen there is not a simple binary yes or nocondition entry. Some process logic requiresfurther differentiation. For example, the salecould be differentiated in three ways: < £5,000,≥ £5,000 but < £10,000, and ≥ 10,000. Theseconditions would be placed in the conditionentry stub and the condition would be the sizeof sale.

8.5.3 Decision trees

A decision tree graphically depicts a decision orchoice situation as a connected series of nodesand branches. It is good for displaying processlogic graphically but becomes cumbersome tofollow when the decisions are more complex.Analysts have to think of the process logic as

178


111

0

11

0111

0

0

11p

179

Table 8.2 Structured English

Sequence

DO

READ next stock-item

ADD new order from order-file to stock-file

UNTIL End-of-file

General Form

DO A

DO B

Conditional statement

BEGIN IF

IF stock-level is less then minimum-order-level

THEN GENERATE new order

ELSE DO nothing

END IF

General Form

If X is true

Then Do Y

ELSE Do Z

Repetition

READ Stock-File

WHILE NOT End-of-File DO

BEGIN IF

IF stock-level is less then minimum-order-level

THEN GENERATE new order

ELSE DO nothing

END IF

END WHILE

General Form

Do A While B is true

Case

READ Stock-level

CASE 1 (stock-level greater than minimum-order-level): Do nothing

CASE 2 (stock-level equals minimum-order-level): Do nothing

CASE 3 (stock-level is less then minimum-order-level): GENERATE new order

CASE 4 (no stock): ENTER emergency order

General Form

Case 1 A > 1,000 Do B

Case 2 A < 1,000 Do C

Case 3 A = 1,000 Do D


conditional alternatives with resultant actions.Figure 8.6 shows a schematic example decisiontree. A node is numbered and has two or morealternative paths. The action is the final policydecision reached along a particular branch.Probabilities can be attached along the paths toshow the likelihood of a particular outcome.

Decision trees are better communicativetools because people in the problem domaincan easily follow them. As they graphically showthe basic business logic, people can follow them

and verify them with analysts. An illustratedexample of a university examination board’scondonement policy with conditions andactions completed is shown in Figure 8.7.

8.5.4 Action diagrams

Action diagrams use a limited set of English todepict process logic. This set includes the struc-tured programming constructs sequence, con-dition, repetition, case and repeat . . . until,

180


Condition stub Condition entries

Action stub Action entries

(a)

(b) Condition stub Condition entries

Sale > £20,000 Y Y Y Y N N N N

Customer for > 2 years Y Y N N Y Y N N

Repeat sale Y N Y N Y N Y N

Action stub

Discount 0% X X X

Discount 3% X X

Discount 5% X

Discount 7% X

Discount 10% X

Figure 8.5 Decision tables

similar to SE. An action diagram is good forshowing simultaneously the detail and overviewof process logic. Figure 8.8 shows an insurancerisk calculation example using sequence only. Itis drawn using a bracket indicating control,which can be nested to show a hierarchicalstructure. The bracket envelops a set of actionsthat are performed in sequence.

Action diagrams can be complex, depend-ing on the business logic to be modelled andwhether database functions are modelled. When

111

0

11

0111

0

0

11p

181

Condition 1

Condition 2

Condition 2.1

Condition 2.2

Condition 1.2

Condition 1.1 Action 1

Action 4

Action 3

Action 2Logic A

0.25

0.25

0.25

0.75

0.75

0.75

Figure 8.6 Schematic decision tree

Mark >= 36and < 38

Mark >=38and <=39

Passed 1assignment

Passed 2assignments

Passed 2assignments

Passed 1assignment Do not

condone

Condone

Condone

CondoneCondonement

logic

Figure 8.7 Student module condonement logic

Risk Type 1A

Floodable planeDry and wet conditionsPrevious floodsHistory of subsidence

Figure 8.8 Action diagram


conditions, repetition, case and repeat are partof the decision logic, the diagrams can be longand nested and difficult to read and interpret.

8.6 SSADM technical products

Knowledge of SSADM technical products isuseful for an overview of IS development, cov-ering data, process and logic techniques. Theyare listed in Table 8.3 in sequence to reflect thephases of IS development. SSADM containsproject management, technical and qualityproducts. Among the technical products areapplication products. The application productscontain the systems analysis and design prod-ucts, or the system data and process models. E-R data modelling and DFD process modellingare SSADM systems analysis techniques.

SSADM complementary techniques includeQuality Assurance Review, Formal Document-ation, Project Control Methods, and CASEtools. The DFD notation used in SSADM isshown in Figure 8.9.

8.7 Process modelling and theCritical Framework

Structured systems ontology aims to provide ‘acommon value system’ for IS developers. Itassumes that knowledge and information is per-fectible. Analysts need to analytically evaluateand critically examine process modelling andlogic modelling and its structured systems ontol-ogy to develop personal constructs for PCF.The level of ontological questioning depends onhow nearer to the ‘truth’ analysts want to get.Some assumptions made by structured processmodelling and issues are examined here.

Figure 8.10 is the Critical Framework pop-ulated with critical reflection on structured andprocess modelling. It shows basic ontologicalassumptions in process modelling. Many ofthese are questionable because they are basedon rationality, plans and plan-based humanaction. As the bottom layer shows, many ques-tions concerning the four themes of criticalityarise from the assumption of objective processes

182


Table 8.3 SSADM technical products

SSADM techniques and models

Logical data models

Data flow diagrams

Requirements definition

Function definition

Specification prototyping

Relational data analysis

Entity/event modelling (entity life histories, effectcorrespondence diagrams)

Business and technical options

Dialogue design

Update and enquiry process models

Physical data design

Physical process specification

Physical design control

Source/sink

Data store

Process

Data flow

Figure 8.9 SSADM data flow diagram notation

111

0

11

0111

0

0

11p

183

Apply formalmethods


(Messy world)

Business rules change,subjective meaning ofinformation/data for

people, integral nature ofknowledge of work itself.

Whose models?Imperfect communication,

systems analystsinterpretation, bias, levelof skill, potential usershoarding information,

inability of potential usersto make intelligent and

informed comments

Systemsontology

Process

Assume that the processin the systems environment

can be capturedunambiguously and

perfectly, decompositionstrategy — divide andconquer a problem,

complete requirements,communications

channels will be open atall times, users will bewilling to cooperate asand when necessary,

problem domain is static,user, analysts and

developers possess anequality of knowledgeand therefore shared

understanding, knowledgeand information are

perfectible, allparticipating parties will

be objective

Pragmaticresolution

???



Resolveproblems


Assumes people (users)are a homogenousgroup — people asstakeholders havedifferent interests


The view that complete,unambigous,

non-redundant view ofdata can be provided in

structured models isdata/system centric.

Is reductionist knowledgeappropriate for systems

modelling?

Critical skills

Figure 8.10 Critical framework: systems ontology and process capture


and business logic. The critical observationarises from the basic assumption of rationalhuman action in structured systems ontology.

The ‘process’ concept has wider application.It is not restricted to structured systems ontology.Analysts should consider alternative processmodelling techniques including Oracle’s CASEdesigner tool, RAD and JAD. The notion ofprocess extends beyond structured systems ontol-ogy to cover a wider scope in systems analysis.Some prominent process description techniquesinclude: Petri-nets, Role Activity Diagrams(RADs), and IDEF0. There are four types ofprocess modelling techniques, though a parti-cular technique may reflect more than one category:

• functional• behavioural• organizational• informational.

Process description techniques have improvedthe scope for innovation using IT. Earlier appli-cations of computers were to automate existingtasks and procedures. IT combined with processknowledge now enables radically innovativeapplications, especially in BPR, eCommerceand knowledge management systems. Theseapplications have transformed organizationswith significant electronic infrastructure andinformational and knowledge content.

8.7.1 Reductionism

Descriptive structured data and process modelsare derived using reductionism as a problem-solving strategy, or functional decomposition.They simply focus on the required IS functionsmodelled on business data because they arethought to provide more stable design andreduced data redundancy. Reductionist modelsare abstractions that do not reflect complex

social, political and organizational reality. Theymarginalize critically important human factorsin IS.

Structured systems ontology is broken downinto three sequentially derived components.Structured systems analysis is done first andTransform Analysis is applied to it to derive thestructured systems design. Structured systemsontology assumes that systems design can bederived from systems analysis. To progress tothe design stage the Transform Analysis needsto be completed. This step is used to convertsystems analysis diagrams into systems designdiagrams. The conversion assumes that a seriesof rules can be applied to transform, forexample, DFD, into systems design diagrams.This is questionable since structured systemsanalysis is mostly logical with no implicationsfor physical software design.

Reductionism is the opposite of holism.Holism is the view that the whole exhibits prop-erties that are more than just the individualparts put together, allowing for emergent prop-erties of human action. Structured techniquesdo not adequately reflect the holism of theproblem domain because they decompose itinto parts such as data and processes. They donot reflect the holistic nature of interconnectedorganizational behaviour and its emergentproperties. SSM is designed to model suchemergent properties and is used in theMultiview methodology.

8.7.2 Representation

Structured systems ontology is composed ofdata and processes. It seeks to represent theproblem domain as objectified data and processmodels, but the actual situation is composed ofpeoples’ meanings, which are not representedin structured models. The relationship elementof E-R diagrams aims to add semantics to thedata, but it does so only in the context ofabstracted data entities.

184


Structured systems ontology requires ana-lysts’ to be objective and detached to representthe problem domain. Information arising fromsystems analysis, though, needs to be trans-formed into systems design decisions. Analystsmay emphasize some features of the problemdomain more than others, and even downplayothers to facilitate communication with people.New IS are constrained by subjective strategicbusiness input.

Structured systems ontology does notacknowledge that logical modelling requires a‘creative leap’ where analysts have to exerciseimagination. They have a ‘blank canvas’ whichthey have to fill with systems models. The cre-ative leap goes beyond simple objective anddetached modelling. Analysts’ intuition andjudgement, based on experience, are part of thecreative leap. They create something that doesnot yet exist.

A central issue is ‘freezing’ the representa-tion as systems models. Once the models aredeveloped and the system requirements‘agreed’, the modelling stops. In actuality thereis always some change required or emergentissues to be addressed in a system project.Stopping modelling in structured systems ontol-ogy has consequences because the actual situ-ation does not ‘stop’. Entities and relationshipsmay change and processes may become super-seded by managers’ decisions or competitors’actions. Business logic may change to maintaincompetitiveness or react to market conditions.

Critical observations of the logical data andprocess modelling techniques can be made too.The Critical Framework in Figure 8.11 depictsa sample. Structured analysis was developed toprovide a common value system, promoting auniform view of what is or is not desirable in a system using structured methods and tech-niques. Ironically, logical models can beunclear, fuzzy and confusing because, throughabstraction, they become too detached from the

problem domain. Advocates have argued thatthe term ‘essence’ is a better description thanmodels. Such semantic differentiation though issuperficial and it fails to address the limitedcapability of structured systems ontology to represent real situations.

There are limits to descriptive modellingtechniques. The representational capacity ofstructured English is limited when a companyhas several actions related to a particular set ofconditions. The resultant logic model is acomplex and cumbersome set of statements that can confuse even systems analysts, leavingpotential users with no scope to make intelligentand informed comment. The complexity ofmost business logic makes SE unsuitable formodelling process logic.

The DFD lacks information on how longdata takes to move from one process to anotherand it is unable to explain the direction of flow.The notation does not represent interrupts orsignals. It does not capture when IS need to besynchronized and coordinated to achieve tasks.Consequently, modelling techniques have beendevised to overcome some of the temporalproblems in the DFD. State-transition dia-grams, control process and control flows allenable the capture of interrupts and signals ina system and the depiction of synchronizationand coordinated behaviour to achieve goals.

A DFD can be unreasonably continuallydecomposed. The decision to stop decomposingDFD is taken by the analyst and this may leadto less overt requirements being overlooked.Too much time can be spent modelling thecurrent physical and current logical system,especially if a complex system with more than100 events is to be modelled. It can make theconsequent models cumbersome to decipher forboth analysts and people and it can be politi-cally dangerous and may cause the systemproject to be cancelled.

111

0

11

0111

0

0

11p

185


Advocates of the structured approach regardthe data dictionary as critical, without which theprocess models are a ‘rough sketch’. It is usedto show what data is processed and how it isprocessed. In practice the use of a data diction-ary among potential users and practitioners is limited and it is more likely to be used inconjunction with developed systems models toverify requirements.

Other issues in representation include:• The DFD has no explicit mechanism for

identifying reusable components to facilitatedesign by extension or reuse as in object-oriented IS development.

• Though Level 0 and Level 1 DFD identifyhuman–computer interaction interfaces,they provide no guidance on developing theuser-interface.

186


Apply formalmethods


(Messy world)

Business rules changeSubjective meaningof information/data

for people

Systemsontology

Structured logic

Business rulesconstitute systemic

algorithms, logicmodels can be

transformed intosystems design

Pragmaticresolution

???



Resolveproblems


Logic modellingtechniques do notcapture meaning


Is transformationanalysis adequate?

Critical skills

Figure 8.11 Critical framework: perfect and unambiguous logical modelling

• The setting of a system boundary is arbitrary,and may overlook real business performanceimprovement opportunities.

8.7.3 Repeatability

Structured, object-oriented and even ASDsystems ontology assumes the problem domainwill repeat itself once modelled and imple-mented in a new IS. The repeatability flawarises because of reliance on planned action andpassive models based on an assumed static realworld of human problems.

Structured methods assume that theproblem domain is repeatable. This assumptionis possible within structured systems ontologybecause of the allied assumption that theproblem domain is static. Structured systemsontology assumes that logical data and processmodels, once implemented, will repeat in theproblem domain in the form of a new IS.

The assumption that the problem domain ispredictable or repeatable has posed difficultiesfor researchers and practitioners. It is highlyquestionable in the context of modern changingorganization. The social and economic contextof organization mean that modelled entities,relationships, and processes may require chang-ing. New entities and relationships may need to be added and others amended or removed.Such change causes problems during the mod-elling process, and is certainly problematicalonce an IS is implemented.

8.7.4 Representative sample

Structured modelling assumes that a represen-tative sample can be produced and relied on tomake data and process models to represent theproblem domain. The E-R and DFD tech-niques assume that data and processes need tobe modelled once – the representative sample.

How this sample is determined and evaluateddepends on the decisions made by steering committees, project managers, senior analystsand senior designers. At local level the auton-omy of analysts influences it too, because theydecide what features of the problem domain toemphasize or avoid in systems models.

The representative sample results in static orpassive models. A passive model once devel-oped is detached or independent of the subject– the problem domain. Changes that happen inthe problem domain or emergent features arenot reflected in the developed models sub-sequently. So the models become outdated,resulting in the problem of legacy systems. Therepresentative sample assumption is related tothe repeatability assumption. It further assumesthat it is possible to develop knowledge ofinformation needs in advance of human activitythat has yet to happen.

The E-R and DFD diagrams separatesystems modelling activity from the actual phys-ical implementation of required functions.Separating analysis and design from its physicalimplementation is questionable because it leadsto passive models. Emerging approaches seek todevelop active models in which the systemsdesign and implementation are intertwined, forexample in ASD.

To overcome the problem of passive modelsresulting from the repeatability and repre-sentative sample problems, other process mod-elling approaches develop active models. Anactive model maintains the relationship with the subject – the problem domain – after it hasbeen created. This allows systems developers to keep developed IS in tune with the needs ofthe problem domain. Structured systems ontol-ogy does not include active systems models.Object oriented systems ontology is capable ofdeveloping active models through deferredclasses.

111

0

11

0111

0

0

11p

187


The power structures within an organiza-tion, and the problem domain, affect people’sinfluence on the models developed. Power andpolitics is not recognized in the structuredsystems ontology. The power structures areprominent during requirements determinationand modelling. Stakeholders and people withthe most power exert the most influence on themodels developed. Such power relations do notlead to a representative sample.

8.7.5 Shared understanding

Structured systems ontology assumes peopleand practitioners have shared understanding ofrequired new IS. A system project and its management relies on the same assumption.This assumption lacks validity from several perspectives and raises the pertinent issue ofownership of models depicted in Figure 8.12.Structured systems ontology gives ownership of systems models to developers. The technicalnature of the structured IS development processinherently means that only developers canunderstand the models.

Structured systems ontology assumption ofhomogeneity of people is erroneous. It isassumed people have a shared understanding ofthe problem domain, which analysts only needto elicit as data and process models. Researchreveals that system projects have stakeholderswith varying interest and power to influence anew IS development. Rather than a sharedunderstanding the problem domain is composedof social conflict and power relations betweenstakeholders, users and developers, which someresearchers argue results in a ‘winner and loser’.

The necessary shared understanding breaksdown when E-R and DFD techniques and logicmodelling are applied. Their focus is on func-tions and algorithms. The DFD does not con-sider relationships between data that is storedin many places in an actual organization. This

relationship between data sources and datasinks exists in one form physically and is inter-preted in another form by analysts in logicalmodels, creating differences in understandingbetween people and practitioners. Similarly, the DFD does not capture the temporal aspectsof physical data. The sequence in which data is captured, stored and processed in logicalmodels varies with actual situations, creatingfurther differences in understanding.

Logical data and process models are analysts’interpretation of the problem domain, raising aninherent problem with assumed shared under-standing. Structured systems ontology assumesthat systems analysts have no preconceptions or pre-resolved solutions to the current prob-lem. This is questionable. Analysts’ individual-ity, and even ego, plays a role in systems model-ling, especially during the ‘creative leap’ thatleads to new designs. This may cause analysts tomisrepresent a required IS. It may lead to biasedrequirements, biased towards technical needs,or the actual requirements not being capturedbecause they are not technically elegant orfeasible. This in turn can raise questions ofownership of IS. Related to this is that structuredsystems ontology assumes that systems analystsare best placed to develop systems models.

Other real world issues are depicted inFigure 8.12. One example is that structuredsystems ontology assumes people have thecapability to know what they require and arecapable of objectifying system requirements.Some researchers argue that potential userscannot know what they want and that, if theydo, then there is limit on communication withanalysts and objectification. The philosopherPolayni is known for formulating our limits oncommunication as the adage: ‘We know morethan we can tell.’ The ontological truth of thisadage has fundamental consequences for struc-tured methods that rely on explicit informationand knowledge for IS development.

188


111

0

11

0111

0

0

11p

189

Apply formalmethods


(Messy world)

Whose models?Knowledge and work

are integrated,imperfect

communication,systems analysts’

interpretation,bias, level of skill,

potential usershoarding information,inability of potential

users to makeintelligent and

informed comment

Systemsontology

Structured modelling

Assumes modelling isan expert activity,

and processes canbe captured

unambiguouslyand perfectly

Pragmaticresolution

???

Interpret formalisms inpracticeDevelop knowledge


Resolveproblems


Can model ownership betransferred to people?


Is modelling an expertactivity?

Critical skills

Figure 8.12 Critical framework: whose process models?


8.7.6 Communicative device

The shared understanding and diagrams arecommunicative devices based on engendering a‘common value system’. Structured systemsontology assumes that modelling techniquesresolve communicative difficulties between peo-ple and analysts and among developers. Thisassumption lacks practice evidence. Advocatesassume an equality of knowledge among devel-opers and people, enabling the latter to makeinformed comments on developed systemsmodels presented to them.

The effectiveness of these techniques as com-municative devices is not formally tested. Peoplelack technical knowledge to understand the E-R and DFD logical models. They do not haveequal technical expertise in interpreting com-plex logical models. Even analysts have to learnhow to develop the DFD and process logic. An inappropriate learning curve within systemprojects constraints will impede meaningfulcommunication.

Shortcomings in knowledge may compro-mise completeness, unambiguity and non-redundancy of developed models. Structuredmethods assume that people have disclosed allthe information required to develop a new IS.In actual situations, job security and resistanceto change are only two issues that question theassumption. Lack of understanding amongpeople means they feel they are acting on trust,which has consequences for confidence andfuture use of developed IS.

The usefulness of instruments is determinedby the context of the problem, purpose of useand objectives to be achieved. Analysts need todetermine the modelling objectives and choosean appropriate technique, because each tech-nique produces different outcomes. The out-comes depend on the constructs each techniqueprovides for representing and reasoning aboutthe problem domain, and whether analystsunderstand its features and can apply them.

8.7.7 Human intention

Structured systems ontology does not acknow-ledge diverse human intention. It assumes allthe parties concerned are interested in achiev-ing system project objectives. The real situationis composed of human purpose and intention,often unclear to even organizational decision-makers themselves. As Figure 8.13 shows, whencomplex business decisions need to be madepurpose and intention are not always clear inreal human problems.

Structured systems ontology does not recog-nize developers’ intention. Analysts have pre-conceived ideas, either implicit or explicit, andmake assumptions about the problem domain.These cover organization, the type of ISrequired, the design problem, and what isexpected of them. They also behave politicallyto achieve their aims.

Structured systems ontology assumes peoplehave a clear understanding of system require-ments. The scope of large IS projects is difficultto set because of lack of clear understanding ofthe organizational problem and of what isrequired to resolve it. ‘Creeping requirements’,the realization of new requirements afterrequirements analysis is completed, has con-tributed to the failure of complex system pro-jects. The problem is compounded by theassumption of mutual intelligibility of theproblem and its resolution among people anddevelopers.

Acquiring explicit knowledge of systemrequirements is complicated by social conflict.Structured systems ontology assumes people will participate as and when necessary. Individ-uals, groups or stakeholders may deliberatelywithhold information because of internal con-flict or differences with developers. Structuredsystems ontology does not acknowledge socialfactors like human intention and conflict in ISdevelopment.

190


Developing representative models of humanintention is problematic but interpretiveapproaches are emerging. Agile or eXtremeProgramming makes use of stories from peopleto design algorithms. SSM seeks mutual under-standing through its root definition and richpicture techniques. The root definition is aconcise description of the system, which is thenmodelled to reflect multiple views and seekconsensus.


8.8.1 Personal constructs for processmodelling

Table 8.4 is a sample repertory grid for processmodelling. Reproduce the grid on a spreadsheetand add further columns and their polaropposites that you consider relevant. To objec-tify personal constructs in process modelling,

111

0

11

0111

0

0

11p

191

Apply formalmethods


(Messy world)

Complex multi-threadedbusiness decision

cannot be modelled,lack of technicalexpertise amongpotential users

Systemsontology

Structured modelling

Assumes that theprocesses in systems

environment canbe captured

unambiguouslyand perfectly

Pragmaticresolution

???



Resolveproblems


Can models capturemultiple people s

perspectives?


Can humanintention/purpose —phenomenology —be represented?

Critical skills

Figure 8.13 Critical framework: ambiguity and imperfection in the real world of human problems


complete the grid by following the details onhow to use a repertory grid in section 1.10.1.

8.8.2 Defining IS

Questions

1 Critically evaluate how DFD process modelsare defined and represent functionality.

2 Assess the validity of the claim that the DFDand process logic diagrams make communi-cation between systems analysts and peopleeasier.

3 What ethical conduct would you use whencommunicating with people in the problemdomain?

4 What would you do to improve the qualityof DFD diagrams produced to facilitate com-munication?

5 What innovative ways could you devise tointeract with people to elicit process require-ments?

6 What value does separation of systems analy-sis and implementation add? What is yourpersonal construct on the separation ofdevelopment activities?

7 Why spend time modelling a way ofworking, as required in current physical andcurrent logical modelling, which will bereplaced anyway?

Activity A

Think of an organization or section within it.Find examples of: processes, dataflow betweenprocesses, and data sources and sinks. Investi-gate other aspects or roles that should bereflected in a systems model. Discuss conse-quences of leaving them out of process models.

8.8.3 Systems and real world ontology

Question

1 Analyse whether reductionism is consistentwith the notion of systems.What assumptions of the problem do-main does reductionism make? Are theyappropriate?What part could reductionism play in your personal construct for establishingknowledge of a problem domain?

192


Table 8.4 Personal constructs for process modelling

Pole 1 Pole 2

Stable Fluid

Can capture Cannot capture

Can model Cannot model

Logical Physical

Mutually intelligible Individual or group intelligibility

Decomposition Whole

Act

ivit

y

Pro

cess

Flo

w

Bus

ines

s lo

gic

Ent

ity

Sys

tem

bou

ndar

y

Rep

rese

ntat

ive

sam

ple

Dat

a st

ore

2 Critically appraise the premise that processmodels and process logic can be rationallyobjectified.To what extent is human rationality capa-ble of capturing system requirements completely, unambiguously and with non-redundant data?

3 Discuss the ownership of logical data andprocess models. Though developed bysystems analysts, what can be done forpeople to perceive ownership?

4 To what extent does people’s lack of intelli-gibility of logical data and process modelsaffect the relevance and quality of a new IS?

Activity A

GobiDesert is a medium sized internet book-seller. It sells books over the internet and has itsUK book distribution centre in Slough nearHeathrow Airport. It wants to develop an IS toprovide information on creditors. It buys itsstock of books, stationery, computer equipmentand other operational needs from various sup-pliers. The accounts department responsible forpaying suppliers receives invoices and checksbalances owing. It then sends a cheque by post to the supplier or authorizes an electronictransfer of monies for the amount owning.

Using the above description and makingyour own assumptions, in two or more separategroups:

• Draw a Level 0 DFD for a new accountantspayable system.

• Mark the system boundary and identifywhere humans interact with the system.Make a separate record of these points ashuman–computer interfaces.

• Decompose the context DFD to Level 1,ensuring balanced DFD.

• Critically compare your solution with a peergroup and discuss your group’s reasoning.

What is the role of interpretation in processmodelling and what consequences does ithave for objective systems ontology?

8.8.4 Logical modelling

Questions

1 Evaluate the value of distinguishing betweenlogical and physical DFD.

2 Compare critically decisions tables anddecision trees for process logic modelling.

3 What criteria would you use to select logicmodelling techniques?

4 How can a visual tool improve structuredEnglish to reduce the complexity of theresultant models?

Activity A

A bank has to decide what level of reminder to send to a customer whose payment isoverdue – a legally worded letter, a reminderor no letter. Its business rules are: If the cus-tomer’s monthly payment is overdue by twomonths then send a reminder. If the monthlypayment is overdue by three months then send a legally worded letter and reduce thecredit worthiness rating of the customer. If the customer has made a payment recently then raise their credit rating. Introduce otherbusiness rules you require. Use a version of theDFD notation and structured English accessibleto you.

• Draw the Level 0 and 1 DFDs.• Write the process logic for one or more

processes in structured English. Use control,selection and iteration structures in the logicmodel.

• Discuss how you would communicate prac-tically your process logic diagrams to peoplein the problem domain.

111

0

11

0111

0

0

11p

193


8.8.5 Relating structured data, processmodelling and databases

Questions

Logical modelling removes all the physicaldetails from the problem domain.

1 Describe how E-R diagrams relate to DFDprocess modelling.

2 What information do E-R diagrams and thedata dictionary provide to develop a data-base?

194



Warboys, B., Kawelek, P., Robertson, I. and Greenwood, R. (1999) Business Information System, a

process approach, Maidenhead: McGrawHill.

9.2 Introduction

Object-oriented systems ontology originates in object-oriented programming. Softwaredevelopers’ drive to improve programming ledto the notion of object-orientation as a basis for writing programs. It enabled programmingefficiencies and intuitive programming.

Object-oriented systems ontology assumesthat reality, the problem domain, is composedof classes or objects and relationships betweenobjects. The collaborating relationships betweenobjects define an object-oriented system. Philo-sophically, conceptually and practically object-oriented systems analysis and design differs fromstructured systems ontology.

The purpose of object-oriented systems analy-sis and design is to find objects and relationships

in the problem domain and develop an objectmodel or class model representative of it. Theclass model is meant to define what the system isrequired to do in terms of fulfilling systemrequirements. The actual practice of object-oriented systems analysis and design is not strictlystipulated in terms of sequential analysis anddesign steps as in structured systems ontology.

Object orientation stems form ClassificationTheory. The theory explains how peopleclassify their everyday experiences. It assertsthat people use three methods for organizingexperiences:

• Experience is differentiated in terms ofobjects and their characteristics.

• An object is demarcated in terms of thewhole and its parts.

111

0

11

0111

0

0

11p

195

Chapter 9

Object modelling



• Analytically evaluate descriptions of problem domains in object-oriented terms.• Develop a simple class model using UML.• Explain how object-oriented modelling enables reuse of software.• Apply critical skills to object modelling.• Compare object-oriented analysis with structured analysis in terms of transformatory

critique.

• Groups of objects form a class and a class isdistinguished from other classes of objects.

People’s intuitive use of objects and classes toorganize personal experiences is considered anadvantage in object-orientation. It facilitatesunderstanding of object-orientation based onintuition and personal experiences. Object-oriented analysis and design draws on thisunderpinning and familiarity of cognitiveprocess that both analysts and people haveaccording to Classification Theory.

Object-oriented systems analysis and designsupports the development of object-oriented IS. The term object-oriented systems ontologydescribes IS development, project management,programming and systems. In systems analysisand design it encompasses requirements analy-sis, interrelationships between objects, operationspecification, design and implementation.

9.3 An object-oriented system

An object-oriented system is composed of inde-pendent, interrelated, collaborative objects. Ithas classes, objects, data and operations. Anobject-oriented system is described in terms ofbehavioural language. An object is said to be-have in a certain way and the whole systembehaves as intended. A system behaves as inter-related objects collaborating to provide servicesto other objects in the system and, if required,to other systems.

Analysts need to understand the notion ofobject behaviour because it is the basis for iden-tifying services provided by objects. A service issome information processing provided by anobject when requested by another object. Anobject is responsible for providing services. Itprocesses temporary data and permanent data.

In object-oriented systems ontology, analystsinvestigate the problem domain to find objects,patterns, responsibilities and scenarios. These

are then defined in terms of classes, objects,data and operations in a class model. A classmodel is an integrated model of data and oper-ations in which process flows, data and processare combined into one model to represent theproblem domain.

The physical implementation of an object-oriented system contains the data and methodsrequired to perform the system specification.Drawing on the integrated class model, thesystem is designed so that objects contain thedata required to complete the required informa-tion processing.

9.4 Patterns and thegeneralization–specializationpattern

The notion of patterns is central in object-oriented systems ontology. A pattern is a tem-plate that can be reused. Patterns are used toorganize and relate classes. A pattern is anabstraction of classes from the problem domaindepicting stereotypical class responsibilities andinteractions. It is repeatable within the sameproblem domain or across problem domains.The generalization–specialization (gen–spec) isone of several patterns in object orientation,others include:

• whole–part• participant–transaction• place–transaction• transaction–transaction line item• peer–peer.

The gen–spec template is shown in Figure9.1. It shows the inheritance relationship interms of classes. The figure shows a class (theparent) and class with objects (the child), thebranches, using Coad’s notation. A class isshown as a rectangle and a class with objects isshown as concentric rounded rectangles – withthe inner rectangle being the object.

196


The gen–spec is a hierarchical parent–childpattern used in object-oriented systems analysis.The purpose of creating a gen–spec, and otherpatterns, is to characterize or develop onto-logical knowledge of the problem domain. Thisontological knowledge is assumed to be validacross problem domains and over time. Conse-quently, patterns are reusable. Reusability is asignificant characteristic of object-oriented sys-tems ontology. Programming code developed onthe basis of patterns can be reused in other sys-tems and as components in component-basedsystems development.

Inheritance is used in object orientation tomanage complexity. In hierarchical termsinheritance is the principal that all lower-levelclasses inherit the attributes and services of thetop class. A lower class in a hierarchy caninherit attributes and services from a higherclass. Inheritance is based on the parent–childpattern that is one way, from the parent to thechild. The gen–spec pattern is an example.

A problem domain illustration of a gen–specpattern is shown in Figure 9.2. It shows how the

gen–spec template is used in the insuranceproblem domain to identify the parent (insur-ance policy) and the child (car insurance, houseinsurance and content insurance), and theinheritance relationship. The parent–childpattern is a common everyday relationship, butit is powerful in object-oriented systems ontol-ogy because it affords inheritance.

9.5 Classes and objects

An object-oriented system consists of classes andobjects. The problem domain is analysed todetermine relevant classes and objects capableof storing data and processing it. Modelling iscritical and strategic, especially in databasemodelling. Object and class modelling is rela-tively less well-developed though the UML is asignificant development in object-oriented mod-elling. Classes and objects in this section aredrawn using the UML notation (Coad’s nota-tion was used in the previous section to providecomparative contrast).

111

0

11

0111

0

0

11p

197

..................................................................................................................Chapter 9 Object modelling

Generalization GeneralizationGeneralization

attributesattributesattributes

servicesservicesservices

Generalization

attributes

services

...

Figure 9.1 Generalization–specialization pattern

9.5.1 Objects

An object-oriented system is a set of interactingand collaborating objects. An object is anabstraction of some thing of interest in theproblem domain for which information is keptand which interacts with other objects. Anobject can be anything tangible or conceptualthat is relevant to the problem domain. Examplephysical abstract objects are an insurance policyand customer. They are related because a cus-tomer draws out an insurance policy. Risk andpremium are examples of related conceptualabstract objects. The premium is high when therisk is high. An object contains the data and theoperations.

An object is drawn as a rectangle as shown inFigure 9.3. In programming terms, an object isreferred to as an instance of a class. An object hasthree sections: the name of the object and its classunderlined, its attributes, and its operations (ser-vices). In naming an object, the object name isfirst with capital letter, followed by an colon andthen the class name. So an object is distinguished

from a class by the objectName:className under-lined label. It is not necessary to show all threecomponents in a model. The rectangle notationcould cause confusion between a class, which issimilarly depicted, and an object, but this is nowthe accepted UML convention.

An example of the car policy object is shownin Figure 9.4. The attributes are listed but theoperations are not specified. Example opera-tions could be making a claim, changingaddress details or recording an accident andupdating accident history.

Attributes are qualities that describe anobject. For an object called insurancePolicy the attributes may be customerSurname,customerFirstName, policyNumber, risk andpremium. The attributes have data types. Forexample, customerFirstName is a string typeand policyNumber is an integer type. Each ofthese attributes has a value or state, which is itsdata. customerFirstName will have a value thatis the name of a customer, for example Rishaor Jackie. PolicyNumber will have a numeric

198


Contentsinsurance

House insuranceCar insurance

attributesattributesattributes

servicesservicesservices

Insurance policy

attributes

services

...

Figure 9.2 Gen–spec example for insurance policy

number like 457987. The actual values or dataare hidden in the object. Storing data and operations in an object is called encapsulation.

An example object from the insuranceproblem domain is an insurancePolicy shown inFigure 9.5. Its attributes are customerSurname,customerFirstName, policyNumber, premiumand maturityDate. Example operations arecalculatePremium or changeAddress. Analystsdetermine what data and operations to encap-sulate in an object during systems analysis. Aclass model is progressively developed in object-oriented systems analysis and design, changes toobject definitions can be made.

An object is responsible for services. Aservice is a set of instructions for performingaction on data. Services are also called opera-tions for logical specification of an object’sbehaviour during systems analysis and methodswhen the operation is implemented. Anexample operation for an insurance policy is theprocedure to calculate premium. It containsinformation necessary to carry out the proce-dure or operation. The operation is invoked bya request from the object itself or from otherobjects with a message.

During systems analysis analysts need todetermine which attributes of an object generate

persistent data. Persistent data is data that is initially input into a system or generated by it that needs to be stored. Information on persistent data is used to create a database con-taining such data so that it can be used by objectsor analytically queried in the database forinformation. In the insurancePolicy object all the attributes would probably be persistent data.Some applications or attributes may containtransient data. Such data is not required after the program has been executed and so does not need to be stored.

111

0

11

0111

0

0

11p

199

Car:insurancePolicy

attributes

operations

makemodelTypeyearmileageovernightParking

operations

Car:insurancePolicy

Figure 9.3 A diagrammatic representation ofan object

Figure 9.4 An example object for car insurance

customerSurname=PatelcustomerFirstName=RishapolicyNumber=457987premium=367maturityDate=01/04/2005

calculatePremiumchangeAddress

insurancePolicy

Figure 9.5 Insurance policy object


9.5.2 Classes

An object in a system is an instance of a class. Aclass is a classification of a set of abstractedobjects with common attributes. A particularclass is a specification of objects with the sameor common attributes. It is also called an objecttype, but object types do not contain any meth-ods. The term class is normally used to define agroup of similar objects. In object-oriented sys-tems analysis analysts’ task is to draw an abstractclass diagram of the problem domain.

The template for a class is shown in Figure9.6. It shows a solid rectangle with three sec-tions. The class name is in bold type in the toppart, the list of attributes is in the middle andthe list of operations is in the bottom section.

The set of home insurance policies offeredby a company can be categorized as insurance.Those with the same characteristics can belabelled a certain class, for example marineinsurance, house insurance or contents insur-ance. An example class for contents insuranceis shown in Figure 9.7.

Some example attributes of the ContentInsurance class are customer’s first name,surname, policy number, address and numberof the house insured. To preserve the descrip-tion found in the problem domain, attributesand services can be listed in the class as com-pressed words with a lower case for the firstword, no spaces, and a capital letter for each

subsequent word. So, customerFirstName,customerSurname or policyNumber are accept-able. Two or more nouns and adjectives andnouns can be compressed.

Classes can be either static or dynamic.Static classification does not allow an object tochange type. Dynamic classification allowsobjects to change type. Dynamic classificationis useful for problem domains where an objecttype needs to be changed. For example, in thecase of a class Professor it is possible that a pro-fessor in the problem domain becomes the headof department.

9.5.3 Polymorphic classes and objects

Polymorphism refers to objects behaving invarying ways in response to different messagesreceived. It is used in object systems ontologyto make subsystems independent and enablesthe de-coupling of subsystems to facilitatesystem extensibility.

A polymorphic class is designed to receive dif-ferent type messages from objects and producethe required result. So a polymorphic object canchange its behaviour to respond to the message

200


className

attributes

operations

ContentsInsurance

customerSurnamecustomerFirstNamepolicyNumberstreetNamehouseNumbertownpostcodepremiummaturityDate

calculatePremiumchangeAddress

Figure 9.6 Class template Figure 9.7 Home contents insurance policyclass

it receives. The object sending the message doesnot have to concern itself with the internal struc-ture, its operations, of the polymorphic object. Itcan simply send its service request and not needto know how the receiving object will respond.

In polymorphic object behaviour there isonly one instance of a class and one or moreattributes or operations are moved to subclassesso that they can be redefined differently. InFigure 9.8 a class with subclasses is shown. Theoperation calculateRiskType( ) is modelled inthe subclasses, rather than the main class,because in each subclass it can be polymor-phically redefined. Similarly, the attributeinsuranceType is modelled in the subclassesbecause it can be variously defined as requiredto describe different types of insurance policy.The effect of polymorphic objects is to receivea message and produce the required output.

Analysts have to investigate the problemdomain to find polymorphic objects. Poly-morphism is a challenge for practising analysts.They have to define classes and a class model

capable of polymorphic behaviour, usually thisis based on inheritance of behaviour from super-classes to subclasses. Its appropriate use duringsystems analysis should lead to an extensible IS,a much demanded feature in business IS.

9.5.4 Modelling operations logic

The operations in an object may be abstract or concrete. Abstract operations do not haveimplemented methods. Operations in an object-oriented system are simple structures becausecollaborating classes enable simplification. Thetotal operations in the system can be analysedin terms of specific object responsibilities ratherthan as some main system functionality. Opera-tions can be specified or modelled using:

• decisions tables• pre- and post-conditions• structured English• pseudo-code• activity diagrams.

111

0

11

0111

0

0

11p

201

Insurance

insuranceInstanceriskType

calculateRiskType

Fire

InsuranceType

calculateRiskType( ):numeric

Burglary

InsuranceType


General

InsuranceType


Figure 9.8 Polymorphic class and subclasses


The first two techniques are non-algorithmic.They cannot be easily translated into programcode. The second three techniques are algo-rithmic – they provide structures that can beused to design program and systems imple-mentation. The decision tables and structuredEnglish techniques are used structured systemsanalysis (see section 6.5).

9.5.5 Links and associations

When things in the problem domain arerelated, they can be modelled as an associa-tion between classes. An association betweenclasses is a generalization of a relationship. Forexample, an insurance policy is linked to aclient. It generalizes the specific links betweeninstances of objects in the real situation.

9.5.6 Multiplicity

Association multiplicity is used to describecardinal relationships between objects. Linksbetween objects need to reflect the problemdomain constraints of how objects can berelated. Multiplicity describes the number ofinstances of objects that can participate in anassociation. One client can have one or moreinsurance policies, for example. Associationmultiplicity contains information on such struc-tures in the actual situation – problem domain.Association multiplicity is determined by thebusiness rules in the problem domain.

In object-oriented systems analysis the datadictionary is a store for information on classes,objects, attributes, operations, links and associ-ations. The class model would normally containmuch of this information, but analysts gathermuch other information that may not bedepicted in the class model. Such informationis stored in the data dictionary. For example,the detail of how an operation would be carriedout is usually not shown in class diagram, butwould be stored in the data dictionary.

9.6 Responsibilities and scenarios

An object is attributed with responsibility in anobject-oriented system. Responsibility has threeaspects: attributes, relationships and services.What the object knows about itself is referredto as its attributes (see section 9.5.1). Who theobject knows in a problem domain is its rela-tionship. A problem domain will consist ofmany objects and a particular object will berelated to one or more of them. This is the rela-tionship the object has with other objects. Arelationship is a connection between an objectand other objects. For example, the customerobject is related to the insurancePolicy objectbecause a customer has an insurance policy.What the object does is its services. The servicesare provided to other objects.

A scenario is a time ordered set of interac-tions between objects designed to fulfil specificresponsibilities. For example, there are proce-dural steps in drawing a new insurance policyfor a customer that involves interaction be-tween the customer, insurancePolicy, risk andpremium objects at certain times. Modellingthis interaction is called a scenario.

9.6.1 Techniques for identifyingservices

Identifying the details of the services in a classis done with specialized techniques and someborrowed from structured systems analysis.Systems analysts make use of these techniquesduring systems analysis. (Decision trees anddecision tables are discussed in section 8.5.)They include:

• scenario• use case and use case scripts or descriptions• structured English• decision tables

202


• decision trees• state-transition diagrams.

Scenario is a specialized object-orientedtechnique for documenting and identifying aclass’s service details. A scenario depicts aninteraction between the system and a user as anordered sequence of actions. It is used in Coad’smethodology but use case and use case scriptsare a similar technique used in UML. A sce-nario describes a specific time-ordered sequenceof object interactions that fulfils a specific processing requirement in an IS. A scenarioview is quite complex for any particular objectinteractions.

Service scenarios are developed to describehow objects interact to complete a task. Forexample, the insurancePolicy object will send amessage to the Risk object to invoke thecalculateRisk service. The Risk object willprocess the result, calculated risk. The notationfor a UML use case diagram is given in Figure9.9 because it is more widely used than Coad’sservices scenario and an example is given inFigure 9.10.

The use case in Figure 9.10 shows a user goalof processing an insurance policy. It is a set ofscenarios tied together by the common usergoal. It shows a scenario consisting of: raise new

policy, update policy, calculate risk and make a claim. Each of these can be described furtherwith use case scripts. A use case diagram is asnapshot of one aspect of information require-ments. Many such use case diagrams are produced to describe a new IS.

A use case script or description can be usedto elaborate a set of interactions. An exampleuse case script for online purchase in aneCommerce system is shown in Figure 9.11. Itshows the primary scenario in steps 1 to 10.These are the necessary steps to complete aprocess. A use case may have one or morepaths. In the example, there are two alterna-tives. One for credit card authorization failureand the other for a previous customer who isoffered discounts and whose details are auto-matically displayed to facilitate the purchase.

A use case script is able to capture moredetail than a use case diagram. The use casescript in Figure 9.11 shows alternatives forexample. It could also show other information.The UML does not specify a standard scriptformat. So it is possible to check for any

111

0

11

0111

0

0

11p

203

Actor

Communicationassociation

Systemboundary

Use case

Insurance clerk

Make a claim

Figure 9.9 UML notation for use case diagram

Make a claim

Insurance clerk

Calculate risk

Update policy

Raise new policy

Figure 9.10 Use case example for processingan insurance policy


preconditions before the primary use case starts.For example, only members of a book club canmake purchases, so the system would check forstatus before allowing purchase to be made. Inthis regard use case scripts enable detaileddescriptions or modelling of actual situations.

Structured English or pseudocode is used instructured systems analysis. It is an action-oriented form of the English language. It is also used in object-oriented class modellingbecause it describes ‘what’ the object needs todo to complete a service request. Figure 9.12 shows part of the pseudocode for processing an insurance claim for a car accident.

204


Purchase online

Customer browses the online book catalogue and places one or more items in the shopping trolley

Customer selects purchase icon

System prompts for further purchases

System presents pricing information, including customer details information and shipping

Customer enters credit card details

System checks authorization

System authorizes purchase

System confirms sale

System prompts for further purchases or other service

System completes sale and sends confirming email

Alternative: Authorization failure

At step 5, system fails to authorize credit card.

Allow customer to re-enter credit card details three times

Alternative: Previous customer

2a System presents discount policy decision for customer with six months purchase history

4a System displays current customer information

4b Customer may accept or override displayed defaults

Return to primary scenario at step 5

Alternative: Other service

9a System presents CD department

9b Customer enters CD department

…..

Figure 9.11 Use case script for online purchase

Figure 9.12 Description of a service in structured English

For Each newclaim

Record accident details

Assess liability

If liability=other then contact other company

Else commence proceedings

Endif

issue claim form

End For Each

9.7 Unified Modelling Language

UML is a notation language for developingrobust industry standard software systems.Ironically, it is capable of modelling such com-plex system even though it is based on the ‘lessis more’ idea of coping with complexity. It doesnot contain a vast range of notation symbols butis capable of developing rich semantic models ofthe problem domain. It is used to develop classmodels for small, medium and large industrystandard software. With it analysts can specify,visualize and document models of systems.UML can be used to explore system ideas or tospecify a detailed design. It is a third generationobject-oriented modelling language based onthe MOF(tm) metamodel and has become theindustry standard. It extends notations used inBooch, OMT and Objectory methods. Anupgrade to UML 2.0 is in progress.

UML is intended to provide a single andcommon object-oriented modelling notationlanguage. It has 12 standard diagram types that

can be applied to a wide range of applicationdomains and database design. It is used tospecify, construct and document classes andobjects in the problem domain. Its standarddiagram types lead to well-designed softwarearchitecture. It can be used to design classmodels independent of specific hardware plat-form or specifically for a particular proprietaryplatform. The diagram types are categorizedinto static, dynamic, and organization andmanagement, as shown in Figure 9.13.

UML is still evolving. Many of the tech-niques do not have specific standards, forexample use case scripts, which can be inter-preted and used variously by analysts. Thevalue of UML for analysts in system projects isthat it is ‘methodology-independent’. It can beused to develop systems models regardless of themethodology being used. It can be used with amethodology but it is not a methodology itself.Structure is important in UML. It is used todeal with the complexity of designing largesystems and it enables code reuse.

111

0

11

0111

0

0

11p

205

Static application structure (four standard diagrams)

Class diagram

Object diagram

Component diagram

Deployment diagram

Dynamic object behaviour (five standard diagrams)

Use case diagram

Sequence diagram

Activity diagram

Collaboration diagram

Statechart diagram

Organization and management of application modules (three standard

diagrams)

Package diagram

Subis

Models

Figure 9.13 UML diagram types and diagrams


Formalism is based on the proposition thatnatural language is unsuitable for communi-cating system requirements or modelling.Natural language is imprecise and ambiguous.Proponents of notation languages claim that aclass model developed with UML diagramseases communication between analysts andpeople because it is specific and formal. Classescan be named in the language of users, ratherthan as abstract names. Some UML tools makeit possible to visualize defined classes, objectsand relationships. Visualization further makes iteasier to communicate with diagrams.

9.7.1 Components and reusability

Object-orientation facilitates the design and useof components. In some object-oriented ISdevelopment software components are reused.A component is a self-contained module of soft-ware code designed for reuse. Software com-ponents are assets and are normally developedfor enterprise applications, business processredesign and web services.

The practical advantage of developingreusable components is that though they are developed for a particular application orproblem domain, they can be stored in a lib-rary and reused in other applications thatrequire the same or similar functionality. TheObject Modelling Group (OMG) provides acentral source for developing a marketplace for re-usable components.

The concept of reusability is extended toreusable requirements and patterns like gen–spec. Analysts can make use of reusable require-ments and patterns, and contribute patterns toa system library. This results in reusable com-ponents that can be used in problem domainsfor which they were not intended, and makes itpossible to cut costs of a system project.

Methodologies exist in the commercial mar-ketplace to enable object-oriented componentanalysis and design. Use cases are used in a top-

down approach, but bottom-up approaches alsoare incorporated to allow existing IS and data-bases to be reflected in the class model. The aimis to create flexible component architecturesthat integrate with existing IS and draw onvaluable data in legacy systems.

Components are designed in terms of:

• the problem domain component;• the human interaction component;• the data management component.

Classes identified by analysts during systemsanalysis and systems design, and subsequentlycoded as Java classes, can be componentizedusing JavaBeans. JavaBeans is an architecturethat supports reusable components. JavaBeansare normally used for GUI interface classes.

Analysts’ can take advantage of reusabilitybecause of object and encapsulation. Whenincluding components not designed by the ana-lyst, analysts do not have to worry about how theservice request will be met. This is termed de-coupling, where the object is designed to work incontext but is not intertwined in it. Gen–specand other patterns can be reused because theyare decoupled.

Polymorphism is a critical feature of object-oriented systems ontology that enables reusabil-ity. An object is polymorphic if it can vary itsbehaviour according to the messages it receives.Systems analysts use polymorphism in object-oriented analysis by identifying and defining aclass and its subclasses that behave differentlydepending on the message received.

9.8 Object-oriented analysis and design

Object orientation has influenced systemsdesign, particularly database systems. Object-oriented analysis is based on the view that theproblem domain has objects that perform tasksand have attributes, and that the objects are

206


related to other objects in terms of operationsto enable tasks to be completed. An object-oriented system is a set of such objects that areinterrelated. For example, an insurance policyis taken out by a customer, brokered by aninsurance broker, underwritten by an under-writer and administered by an administrator.The parties are related and each party performsoperations for other parties.

The aim of Object-Oriented Analysis (OOA)is to identify detailed system requirements bydescribing the existing physical system anddetermine how a new IS will become part of it.Data definition involves identifying object, class,relationships and abstraction. Data manipula-tion involves determining methods and mes-sages. Data definition and data manipulationresult in the object or class model.

The problem domain is analysed in terms ofobjects, patterns, responsibilities and scenarios.Once the analyst identifies objects they arelikely to persist through to the design and imple-mentation or programming stage. The analyst’scritical role is to identify the objects and classesin the problem domain. Analysts undertake fiveactivities in Coad and Yourdon’s (1990) OOA:

• Identify classes and objects in the problemdomain.

• Identify structures or relationships betweenclasses and objects.

• Identify subjects or related objects.• Define attributes or the data elements of

objects.• Define services or how the object behaves.

OOA results in systems models of the struc-ture of objects and their behaviour. Objects can be identified from transcribed records ofinterviews or text documents by underliningnouns. For example, insurance policy, client orpremium are acceptable nouns or noun phrasesin an insurance company. The label given to anobject depends on the analyst’s preference andstyle, but it is important to preserve the termi-nology of the problem domain. Naming objectsand classes with terminology from the problemdomain makes it easier for people to understanda class model.

OOA is not strict planned action like struc-tured analysis. Analysts do not have to per-form the five activities in sequence. As elicitingrequirements depends on people OOA enablesanalysts to work with them. They are permittedto explore the problem domain and undertakeeach activity as and when appropriate informa-tion is found or revealed by people. The effortanalysts spend on each activity will depend on

111

0

11

0111

0

0

11p

207

Problem domain

The objects here will be those required to address the business problem.

Human interaction

The objects here will be those required to design the human–computer interaction, such as the

interface, windows and reports.

Data management

The objects here will be those required for the persistent storage of data, such as databases.

System interaction

The objects here will be those required to enable the present system to interact with other

systems.

Figure 9.14 Components of a class model


what information they discover, with someaspects of a class model more deeply exploredthan others. The iterative OOA process enablesanalysts to validate and continuously improve aclass model with information from people.

A class model is composed of major model components consisting of the problemdomain, human interaction, data managementand system interaction, shown in Figure 9.14.Analysts identify objects and their responsibili-ties for the components of a class model.

9.9 Java and object orientation

The Java programming language has becomeclosely associated with object-oriented systems.The origins of object orientation are inScandinavia and SMALLTALK is a popularobject-oriented language. Java though is con-sidered suitable for implementing distributedobject models. Object models can be imple-mented using any programming language,though there will be efficiency gains in someand costs in others. Java is designed for theobject-oriented systems environment. It iswidely used largely because of the success of theinternet and the world wide web.

Unlike other programming languages Javacan be many things to many people. It is anobject-oriented programming language, con-taining the syntax and semantics of a program-ming language. It uses the notions of a virtualmachine and byte code to enable it to be exe-cuted on different machines. Java is a pro-gramming environment too. It contains classesand libraries provided by the language.

Programmers use these classes by ‘extending’them to suit their processing requirements. Javais the de facto programming language of theweb. Other object-oriented languages can beused, but Java is the preferred language of mostcommercial software developers for the web.Java treats strings, arrays, windows and integers

as objects. For example, the string ‘Risha Patel’is an object of the class String.

9.10 Object modelling and theCritical Framework

Object-oriented systems ontology addresses twoproblems in structured systems ontology. Thecreation of separate data and process systemsmodels and multiple models in structuredsystems ontology causes validation problems.This is overcome with the one class modelcreated in object-oriented systems ontology.The encapsulation of data and operationswithin an object removes validation issues.

The other problem is determining the tran-sition from structured analysis to structureddesign. This arises because of the TransformAnalysis stage, which assumes that rules can beapplied to the systems analysis E-R and DFDdiagrams to convert them into systems designdiagrams. This is overcome in object-orientedsystems ontology with the one class modeldeveloped during analysis, and progressivelydeveloped to include design and programmingtasks. In OOA the integration between systemsanalysis and systems design is now complete, asit is possible to generate implementationprogram code from analysis diagrams.

9.10.1 One class model

Figure 9.15 is the Critical Framework populatedwith critical reflection on object-oriented sys-tems ontology. It questions the assumption thatreal situations can be accounted for by classes,objects, relationships and collaboration betweenobjects. One issue is the temporality of analysis,design and implementation. These activities areconcurrent in object systems ontology. Theanalysis class model is elaborated to includedesign and implementation features. The notionof analysis in object systems ontology is different

208


111

0

11

0111

0

0

11p

209

Apply formalmethods


(Messy world)

Information technology,people lack tangibleinsight of the new ISrequirements change

during development andpost-implementation,difficult to define the

problem domain,contextual issues,creative chasm for

developers

Systemsontology

Object-orientation

Classification theory,class, object,

attributes,services,

encapsulation,relationships,collaboration,inheritance,

polymorphism,reusable

Repeatable patterns,dynamic binding,non-separation

of analysis and designin the class model,

implementableanalysis

Pragmaticresolution

???


Develop knowledge


and tools

Resolveproblems


How can techniques andtools be deployed torespond to change?


Is classification theorysufficient to describe and

represent the problemdomain?

Can object-orientationcater for

phenomenologicalinformation?

Critical skills

Figure 9.15 Critical framework: object-orientation


from structured systems ontology because analy-sis contains design and implementation features.

Actual practice in industry though is differ-ent. Practitioners maintain a separation betweenanalysis and design despite the concurrencyfacility in object-oriented analysis and design. Intraditional IS development (see section 3.4) suchconcurrency was the norm, but the force of theSDLC and engineering metaphor has set itselfin practitioners’ minds. An additional factorreinforcing this separation is the systems projectmentality and work breakdown structures.

Compared to structured systems ontology, inobject systems ontology analysts interpret andrepresent the problem domain as classes andobjects. A transformatory critique is to questionthe validity of classification theory to describeand represent the problem domain. Forexample, is it possible to model human meaningattached to information? There are aspects ofobject technology such as deferred classes anddynamic binding that can be modelled to reflectchange in the problem domain. They cannotreflect the interpretive aspect of IS.

Reusability and patterns lead analysts to think of problem domains as consisting of stereo-typical and repeatable object behaviours. Re-peatability in object-oriented systems ontology is problematical because it could lead to apply-ing unsuitable patterns in particular problemdomains. The problem being that the ‘best avail-able’ pattern may be applied in situations whereit is inappropriate. In problem domains whererequirements are ambiguous, a reusable require-ment pattern may be applied for convenience.

9.10.2 Representation and problem-solving

Object modelling is considered to be essential,especially for large enterprise-wide applications.Proponents argue that modelling can contributeto the success of a system project, and improvethe quality of software produced. It supports

scalability, robustness, security and extend-ibility. Like structured systems ontology, object-oriented systems ontology proposes building aclass model before coding.

The basis of this modelling is the meta-modelfrom which UML is defined. A meta-model is amodel of the constructs in UML.The meta-model is defined using a metacircular inter-preter, which is a language, defined in terms ofitself. The meta-model is significant because itcontains ontological assumptions about reality.Its power to address problems and develop rep-resentative models of the problem domaindepend on the validity of these assumptions. Forexample, the assumption that experience is clas-sified in terms of classes and how one class differsfrom another is significant because it, in turn,assumes a certain level of ontological objectivity.

Techniques for gathering information todevelop class models need to be analyticallyevaluated to assess whether they are sufficientto identify objects, attributes, operations, asso-ciations and multiplicity. Sampling, question-naires, interviewing, reading or research, andobservation seem sufficient, but the quality ofinformation gathered with these techniques issometimes poor, resulting in class models thatare a poor representation of the real humanproblem situation. Poor quality informationcontributes to lack of analysts’ creativity.

The association definition and associationmultiplicity are generalizations. Analysts’ needto consider how they would determine suchgeneralizations with information obtained fromrequirements analysis. The available informa-tion is essentially limited to the time whenrequirements analysis is undertaken and to thepeople, and other sources, available at the time.In real business situations changes occur to howthings are related and the multiplicity of theirrelationship. An issue with structured andobject-oriented systems ontology is how suchchanges can be easily reflected in developed IS.

210


Problem-solving in object-oriented systemsontology is relatively easier compared to struc-tured analysis. Once classes are identified theytend to remain stable during analysis and design,though attributes, operations and relations maychange. This may be interpreted as validatingclassification theory’s power to represent theproblem domain. Similarly, the dynamic classi-fication of an object is useful in changing prob-lem domains. Object systems ontology in thisrespect reflects real human problems. Though itintroduces uncertainty in object-oriented sys-tems ontology because an object can be anythingand its features are not syntactically defined in anavailable notation language.

Structured methods and methods of othersystems ontology are derived from predicatecalculus, for example normalization in E-Rmodels. Object-oriented instruments are not asmathematically rigorous. They are intuitiverather than mathematically rigorous and theirpopularity attests to their relevance to practice.For example, unlike structured systems ontol-ogy where an entity is an abstraction of some-thing of interest, an object does not have to bean abstraction it can be concrete too. Theproblem exists because an object can have anynumber of features beyond the basic three fea-tures used in the UML notations: name, attrib-utes and operations. The move frommathematical rigour in object-oriented systemsontology is significant because it makes softwareintuitive rather than formulaic. Its logical pro-gression is evident in storycarding in ASD.

Analysts’ task is made challenging because ofencapsulation and polymorphism in object-oriented systems ontology. They not only haveto identify objects, attributes and operations, butalso ensure that polymorphic behaviour is facil-itated in a class model. Often, analysis of poly-morphic object behaviour is overlooked becausethe problem domain does not afford itself so

transparently to identifying polymorphic thingsof interest.

Structured and object-oriented process mod-elling techniques make an erroneous assump-tion of real situations. They assume that the realsituation requires to be modelled once in theform of systems models. In structured systemsanalysis data and process models are createdseparately but become frozen. In class models,data and operations are encapsulated withinobjects. The real situation though is dynamicand ‘frozen’ models can become obsolete whenthe system is delivered.

9.10.3 Incremental and iterativedevelopment

Pragmatically, object-oriented IS developmentis not planned but is architecture-driven, incre-mental and iterative. It can be described as sit-uated action rather than planned action. Theanalysis, design and implementation activitiesare not distinct phases but iterative activities. In some cases, this leads to an evolutionary IS development approach, where a system isdelivered in phases.

UML may be described as the situated useof modelling rather then planned. It is not amethodology, so it does not prescribe plannedaction, and it can be used with any object-oriented methodology. Its various diagrams canbe used in context, decided by analysts. Unlikethe systematic phases of data and process modelling in structured systems analysis, a classmodel is developed progressively in context.Object encapsulation ensures that data andoperations are contained and validated eachtime a process is added or amended.

This means that systems project manage-ment is not planned in the traditional sense used in structured systems ontology, but ratherproject constraints are readjusted each time aversion of a system is delivered. A problem arises when a project manager wants to apply

111

0

11

0111

0

0

11p

211


rigorously the work breakdown structure andenforce the PERT activities on a project. In suchcases the inherent flexibility of object systemsontology is lost. Practice reflects such inflexibil-ity because IS are developed as projects.

Analysts should allow flexibility in their PCF.Systems ontology, whether structured or object-oriented, is not mutually exclusive. New ideascan be used with existing methods and tech-niques if it is appropriate. For instance, rela-tional databases support object-orientation.The SQL3 database includes some object-orientation features. This suggests analysts anddesigners should not think only in ideal types –relational database or object-oriented data-base – but recognize that knowledge of systemsontology is progressive and can be inclusive.


9.11.1 Personal constructs for objectmodelling

Table 9.1 is a sample repertory grid for objectmodelling. Reproduce the grid on a spreadsheet

and add further columns and their polar oppo-sites that you consider relevant. To objectifypersonal constructs in object modelling, com-plete the grid by following the details on howto use a repertory grid in section 1.10.1.


Questions

1 Critically evaluate how appropriate object-oriented systems ontology is for representinga business organization’s activity and goals.

2 Comparatively evaluate logical data andprocess modelling in structured systemsanalysis with class modelling in object-oriented systems analysis.

3 What is the systemic value of encapsulatingdata and operations in objects?

4 ‘The purpose of creating a gen–spec is tomeet the needs of the problem domain, notneatness or elaborateness.’ Evaluate theeffectiveness of patterns in object-orientedsystems analysis for representing real humanproblem situations.

212


Table 9.1 Personal constructs for object modelling

Pole 1 Pole 2

Pattern No pattern

Method No method

Encapsulate Separate

Reusable Not reusable

Dynamic Stable

Grouped Ungrouped

Service Independent

Obj

ect

Att

ribu

tes

Cla

ss

Inte

ract

ion

Pat

tern

Com

mun

ity

Hie

rarc

hy

Ope

rati

ons

Inhe

rita

nce

Activity A

Comparing structured systems ontology withobject orientation, the latter recognizes thecreative role of systems analysts. In determiningdetailed system requirements, analysts identifythe objects and classes in the problem domain.

• Make a list of your creative attributes anddiscuss them with a trusted peer.

• Select an IS familiar to you and commenton its creative aspects.

• What does it do anew that is not in the pre-vious system or manual work?

• Comment on what difference the creativeelement of the system makes to the organ-ization’s performance?

Activity B

Investigate a situation in a problem domainwhere polymorphic behaviour would berequired. Think of a class to represent the situ-ation that should only have one instance, whereone or more operations and attributes are mod-elled to subclasses to produce polymorphicbehaviour. You will need:

1 a class2 subclasses3 generalization4 one or more attributes or operations that

need to be polymorphically redefined in sub-classes.

Once you have the required elements:

• Draw a class diagram.• Discuss critically whether polymorphic sys-

tems ontology reflects real human problems.• Identify requirements analysis techniques

you would use to find polymorphic classesand objects and analytically evaluate theireffectiveness to do so.

9.11.3 Planned action versus situatedaction

Questions

1 UML is not a methodology. How would youuse it in object-oriented systems analysis anddesign?

2 Evaluate the practicality of the iterativedevelopment of a class model in an ISproject. Base your evaluation on the themesof situated action and planned action.

Activity A

Object-oriented analysis may be described assituated action. Though sequence is important,unlike early versions of the SDLC, iteration isaccepted and essential in object-orientation andit is often linked with prototyping. A class modelis validated and continuously improved withclients. In two groups:

• Identify a problem domain for which an ISis required or one in which there is an exist-ing IS.

• Make a list of the advantages of object-oriented analysis applicable to the problemdomain.

• In a plenary compare your lists and discussthe similarities and differences.

9.11.4 Communicating with diagrams

Object-orientation diagrams are used as a toolto ease communication between systems ana-lysts and people in the problem domain.

Questions

1 Discuss the reasons why natural language isnot suitable for communicating systemrequirements?

111

0

11

0111

0

0

11p

213


2 Assess the effectiveness of the various UMLdiagrams to communicate system require-ments and systems models to people.

3 Critically evaluate the claim that objectsystems ontology is intuitive and thereforeenables easier understanding of the classmodel by people.

214



The Object Management Group was set up ‘to create a component-based software marketplace’.It is a rich resource for object-oriented analysis, design and reusability: www.omg.org

A site for object-oriented tools is www.rational.com.


For a practical text on object-oriented analysis see: Bennett, S., McRobb, S. and Farmer, R. (1999)Object-Oriented System Analysis and Design – Using UML, London: McGraw Hill.

Coad, P. and Yourdon, E. (1990) Object-Oriented Analysis (2nd edn), Englewood Cliffs, NJ: YourdonPress, Prentice Hall.

Part IV covers systems design. Whereas systems analysis focuses on what the system will do,systems design focuses on how the system will do it. A design is a solution for a problem. Asalternative solutions can be generated, designers aim to generate a solution that is efficient,effective and achievable within monetary and time constraints. Quality standards are used toensure that the system design is robust and capable of fulfilling system requirements specification.

In structured systems ontology design is concerned with converting the logical designs fromsystems analysis into logical design and physical design for implementation. It normally beginsafter decisions on hardware and software platform have been made. Systems design involvesmaking decisions on system performance, computer files, data structures, processes, databasesand user interfaces. E-R models, DFD and data dictionary are used to inform these decisions.In object-oriented systems ontology, systems design is the refinement of class diagrams, orclass model, created during analysis, but does not necessarily cover actual implementation orphysical design. In both, the models resulting from the logical design describe how the partsof the system will work.

Chapter 11 covers user system interfaces design. In structured systems design this requiresconsidering what data input and output is required. In object-orientation, systems design leadsto the creation of the human interaction class model and, if required, the system interactionclass model to enable communication between systems.

Chapter 12 is on system and data design. In structured systems design, overall system levelperformance design decisions are made, and file or database design decided. In object-orientedsystems design, system level and detailed design decisions are made. Systems design is con-cerned with overall systems issues like performance. Detailed design is concerned with classdesign.

Both chapters cover critical skills in praxis. In considering how requirements will be met and how the system will be implemented, designers need to reflect on technical issues like improving system performance, reducing processing times and making efficient use of datastorage. The kinds of praxis questions concern, why is a particular hardware and softwareplatform better than another and how will the choice affect the business, is the data organ-ized efficiently to make use of limited storage, and what is the benefit of using platform-independent software.

111

0

11

0111

0

0

11p

215

Part IV

Systems design

10.2 Introduction

The focus of design is on how to achieve a goal,with the emphasis on the means or mech-anisms. In structured systems ontology systemsdesign succeeds systems analysis. Systems designis concerned with how system requirementsestablished during systems analysis will be trans-formed into an implemented system. Systemsdesign also extends to determining what com-puter hardware will be required to implementthe system specification. The transformation ofthe requirements specification focuses on deter-mining specific hardware and software plat-forms required to operationalize the new IS.

The system design involves the design ofinterfaces, programs, data storage (databases),construction, testing and implementation activ-ities. Detailed design documents are created

during systems design. Programmers’ workfrom the detailed design documents producedduring systems design to write and test softwareto realize the new IS. This chapter will coveronly the design activities.

10.3 Structured design

Interface design consists of designing interfacesbetween the system and people who will use itand where inter-system communication isneeded designing interfaces between the systemand other systems. The user interface is themedium through which people interact with anew IS. Programs that require data to completeprocesses need a user interface for the data tobe inputted and outputted. The main principleguiding user interface design is the ease withwhich people can interact with the new IS.

111

0

11

0111

0

0

11p

217

Chapter 10

Interface, input and output design



• Analyse and evaluate the process of refining the analysis class model for designpurpose.

• Evaluate the human interaction and system interaction components in object-orientedsystems design.

• Critically compare structured and object-oriented systems design.• Apply critical skills to practical interface, input and output design.

10.3.1 User interface design

User interface design is based on knowledge ofHuman–Computer Interaction (HCI). Modernuser interfaces now use Graphical User Inter-faces (GUI) rather than text commands. Oftena user model forms the basis of designing userinterfaces. A user model describes and predictshow people interact with a computer system.User models or aspects of it are used to decidewhat interaction methods, presentation formsand colours to use. They help designers todetermine appropriate screen layout, menus,form filling and interactivity.

The purpose of user interface design is tospecify how users will interact with the systemand how database actions will be triggered byuser actions. In SSADM such a model is calledthe User Object Actions. It is a logical modeldescriptive of user action. A user action is some-thing in the minds of users that can be carriedout on a user object. The GUI actions are theuser interface mechanisms used to implementthe User Object Actions. The User ObjectActions are logical and relate to the GUIactions that are physical.

Usability is a major design issue in userinterface design. It addresses the ease with which people can use the system through userinterfaces and how to improve interactivity,efficiency, effectiveness and reliability. Usabilityis concerned with enabling specific users toachieve specified goals with a system. Signifi-cantly, usability is concerned with peoples’ satis-faction with achieving goals.

Usability provides knowledge on how todesign the layout of interfaces, for example, useof colours, grouping related elements andsystem response times. For interactive systems,usability knowledge is used to decide the kindsand types of interface objects to use, forexample, function keys, radio buttons, form-filling. e-Tailing for example requires highly

interactive systems, in which direct manipula-tion devices, such as menu selection, are used.Usability issues for online user interfaces includeresponse times and the depth of navigationusers have to go through. Response times anddepth of navigation both need to be kept to aminimum in e-Tailing.

Designers consider the details of input dataand what user interface mechanism will beappropriate to enter it into the new IS. Thechoice of data entry methods will depend on thetimeliness and speed of data entry required.Data entry methods include manual entry,entry via user interfaces, Electronic DataInterchange (EDI), or networked direct entry.The latter two are used in system where a largevolume of data needs to be entered. User inter-face methods are used where a user can entermanageable volumes of data manually.

User interface interactivity is designed at twolevels, the primary window and secondarywindow. A primary window has a border orframe. It contains a title bar, toolbars, a statusbar, a menu bar and the content. Where thecontent extends beyond a screen, horizontaland vertical scroll bars are used. An exampleprimary window is a word processor’s window.A secondary window has no bars or frame func-tions. It can be a dialog box, a message box, atab folder or a drop-down list. An example sec-ondary window is a logon window. Some exam-ples of interactivity methods or activities are:toolbar button, double click and scrollingbutton.

In structured systems design, for instance inSSADM, the user interface design is part of therequirements phase, rather than the physicaldesign. User interface design during require-ments analysis helps to understand and gatherinformation for user requirements. The physi-cal user interface design in SSADM consists ofa window navigation model, window specifica-tion and help system specification. The design

218

Part IV Systems design........................................................................................................................

of windows can be based on window navigationmodels, which are themselves sometimes basedon a function navigation model.

Interactivity is important for business IS.Interaction models of different interaction stylesare used to improve interaction between peopleand a computer system. They are rooted inearly studies of ergonomics and informationscience and technology. Interaction modelsfocus on tasks that people want to achieve on asystem and the model user and system, both ofwhich are complex. They seek to understandthe interaction in terms of what a user wantsand what the system does, and help to identifyinteraction problems that can be avoidedthrough appropriate design decisions.

A popular interaction model is Norman’srational model, which is intuitive. In the modela person is thought to formulate a plan of actionwhich is executed at the computer systemthrough the user interface. During the executionand at its completion the person assesses theobtained results, and based on the results determine further action. In detail the model is:

• establishing the goal;• forming the intention;• specifying the action sequence;• executing the action;• perceiving the system state;• interpreting the system state;• evaluating the system state with respect to

the goals and intentions.

10.3.2 Data output or report design

An IS processes data, supports work and gener-ates management reports. The information gen-erated by the system is termed data output instructured systems ontology. Data output that isuseful for operational and management use foran organization is converted into managementreports. Managers and executives use manage-

ment reports to support decision-making, and tocontrol and monitor workflows and businessprocesses.

Designers in consultation with managersdetermine the format and presentation of suchreports. Reports can be daily, weekly, monthlyor even real-time on screen. The frequency andgranularity of the reports will depend on man-agers’ needs and are initially determined duringrequirements analysis.

10.4 Object-oriented design

The distinction between the analysis and designphases in structured systems ontology is notmade in object-oriented systems ontology. Inobject-oriented systems design, designers rely on the problem domain class systems modelcreated during systems analysis. Designerscreate additional classes for data inputs, outputsand associated processes. They make decisionson how data required for classes will be entered,how it will be displayed on screen for people orpresented as management reports. Standardsare used to produce basic user interface designslike screen or report layout.

Object-oriented user interfaces are normallydeveloped first as prototypes. The aim in usingprototypes is to gather requirements of what userinterfaces need to be capable of doing and thendesigning and evaluating it through the proto-type. Many prototype user interfaces are devel-oped using visual programming languages. Avisual programming language environmentenables user interfaces to be designed first tounderstand system requirements. Often this isthe practice adopted by systems designers.

10.4.1 Human interaction component

In an object-oriented system, user interfaces,input and output design usually consist ofwindows and reports objects. An interface class

111

0

11

0111

0

0

11p

219

......................................................................................Chapter 10 Interface, input and output design

is shown in Figure 10.1. It is drawn with theword ‘Interface’ in chevrons. Systems designersidentify and design these additional classes andobjects. Three types of windows are designed:

• logon and security• system set-up• business events.

Security design features are important. The log-on window is used to enable authorized people to access a new IS. Its design is critical to safe-guard sensitive data and information. The set-upwindows enable systems administrators to:

• Install and operationalize the system eitherin standalone mode or, more likely, as a net-worked system.

• Add or remove peripherals such as printerdrivers.

• Add or remove people authorized to use thesystem.

• Manage the system privileges given to par-ticular people.

• Create, maintain and remove persistentdata, for example client records.

The business events windows are the main userinterfaces to actual systems processing. For aninsurance example, a window is needed toenable a new policy insurance to be drafted ora management report to display all the policieswith a high or low risk. The business events

windows provide the main interaction with thesystem for business people. Consequently, theyneed to be designed with usability features.

Though management reports can be dis-played on screen, they are normally designed as objects. There may be many kinds of re-port objects depending on managers’ need for information, for example decision-making,monitoring and control needs. Systems design-ers identify the report objects and attributes, and design the responsibilities (operations) andscenarios. The report objects collaborate withthe problem domain objects identified duringsystems analysis to produce the required inform-ation. These interactions are the connectionsbetween the problem domain and human inter-action components of a class model.

10.5 Interface design and theCritical Framework

10.5.1 Interactivity

Business people interact with an IS through userinterfaces. Knowledge of interactivity is there-fore significant in systems ontology. Theoreticalknowledge on user interface design is based onthe broader research area of human–computerinteraction. The kind of questions addressed in human–computer interaction concern appro-priate ergonomic design and interaction

The social context is significant for IS.Interaction models like Norman’s model arebased on the assumption that people behaverationally and logically. Interaction with an IS,though, happens in a social and organizationalcontext, which affects both users and thesystem. Interaction models do not adequatelyconsider this context because they focus on tasksand assume rational systems ontology.

User interface design needs careful consider-ation to enable human–computer interaction.Figure 10.2 is the Critical Framework populated

220


<<Interface>>Insurance Claim

Figure 10.1 An interface class

with critical reflection on human–computerinteraction. As the bottom layer shows, manyquestions arise concerning the four themes ofcriticality. The systems ontology component

contains some examples of the theoretical andformal knowledge available to designers.

Assumptions need to be examined in the usermodels used to inform user interface design.

111

0

11

0111

0

0

11p

221


Apply formalmethods


(Messy world)

Time and place ofinformation provision,

granularity ofinformation,

systems navigationproblems

Systemsontology

Interface design

Human–machineinteraction,

user models,mental models,

ergonomics,intelligent agents

Pragmaticresolution

???


Can flexible interfacesbe designed?

Develop knowledge

Is a particular usermodel appropriate?

Determine a pragmaticresolution to problemswith formal methods,combine user modelswith intelligent agents

Resolveproblems


What contextualmetaphors can be used

to design interfaces?


Can interactionbe facilitated

or performed byintelligent agents?How can semantic

interfaces bedeveloped?

Critical skills

How can informationquality be improved?

Figure 10.2 Critical framework: human machine interaction systems ontology

Critical awareness is especially needed whenusing mental models. Mental models are madeof users mental activity when interacting with acomputer system. Designers need to ensure thatthe mental models they use are appropriate forthe type of user expected to use the system.

Usability engineering is based on specific useractions and not the wider social and organiza-tional context in which IS are used. It is basedon interpretations and shared understanding,which assumes meanings. The assumption isthat shared understanding will provide agreedgoals and metric with which to evaluate usabil-ity satisfaction. Such shared understanding isdifficult to realize in practice.

10.5.2 Mental models

The application of user or mental models in user interface design affects IS operation andusage. A person’s mental model is effectively the system – this is not considered in deployingmental models to design user interfaces and inter-activity. Mental models do not have the samelevel of detail as usability engineering modelsbecause a mental model is a users’ own inter-pretations of how a system works. Often peoplehave only a partial understanding of the fullcapabilities of a system, and the mental modelscan be unstable or subject to change over time.

Incorrect mental models lead to design error.A mental model can be internally inconsistentbecause a person does not calculate all thelogical consequences of an action. Some designsresult in lack of usage because people areunable to navigate through the various user andsystem interfaces. This is an undesirable resultfor companies making strategic investments in IS. So usability is a critical design issue.Pragmatic use of user and mental models is necessary to ensure the operational success of IS. When considering the pragmatic resolu-tion element of the critical framework systems

designers should be aware of information qual-ity arising form untested mental models.

10.5.3 Semantic information structuresand user interfaces

A weakness of both structured user interfacedesign and object-oriented human componentinteraction design is the lack of semantic andcontextual modelling. This is because ofassumptions on data and information in theirrespective systems ontology. Both structuredand object-oriented systems ontology lackssemantic information modelling.

Web technology makes use of semantic andcontextual mark-up languages to represent theproblem domain terminology in a system andits interfaces. XML is an example of a mark-uplanguage. It enables web application analysts touse the terminology of the problem domain andconstruct data structures to reflect it in theapplication and user interfaces. Such semanticuser interfaces improve the usability features ofa system and make it intuitive for people to useit. The semantic web is defined as an exten-sion of the current web in which information isgiven well-defined meaning, better enablingcomputers and people to work in cooperation(Berners-Lee et al., 2001).


10.6.1 Personal constructs forhuman–computer interaction

Table 10.1 is a sample repertory grid forhuman–computer interaction. Reproduce thegrid on a spreadsheet and add further columnsand their polar opposites that you considerrelevant. To objectify personal constructs, com-plete the grid by following the details on howto use a repertory grid in section 1.10.1.

222


10.6.2 User models

Questions

1 Define user model and mental model.2 Determine your criteria for selecting a user

model for user interface design.3 Critically evaluate whether user models add

value to user interface design.

10.6.3 Design process

Questions

1 Critically analyse the value of a separatesystems design phase in structured systemsontology.

2 Assess the value of the progressive develop-ment of a class model from analysis to designin object-oriented systems ontology.

10.6.4 Interactional devices

Label, button, choice, textfield are some exam-ples of user interface devices. For a highly inter-active system, like an ambulance dispatchsystem:

• What kind of interactional devices wouldyou use?

• Discuss critically how the interactivityafforded by your choice of devices relates to the human activity in the problemdomain.

• Assess whether structured or object-orientedsystems ontology is better for designinginteractivity.

10.6.5 Usability

Activity A

Either use the SSADM User Object Action usermodel in section 10.3.1 (you will need to sourceit) or using one familiar to you:

• Identify a system interface you use.• Evaluate the system interface with reference

to the identified user model.• What additional design features would you

add? What would you remove? Explain your reasons commenting on interactivity ifrelevant.

111

0

11

0111

0

0

11p

223


Table 10.1 Personal constructs for human–computer interaction

Pole 1 Pole 2

Visible Hidden

Function Aesthetic

Practical Impractical

Usable Unusable

Static Dynamic

Persistent data Transient data

Computer-based data/ Semantic data/information structures information structures

Inte

rfac

e

Dat

a in

put

Dat

a ou

tput

Dis

play

/pr

esen

tati

on

Use

r m

odel

s

Men

tal

mod

el

Inte

ract

iona

l de

vice

s

Inte

ract

ivit

y

224



See the notes of the OMG-MCC-DARPA Workshop on Compositional Software Architecturesat: http://www-db.stanford.edu/CHAIMS/Doc/Papers/commerce.html.


Tim Berners-Lee is the founder of the world wide web. He is now the Head of the World WideWeb Consortium (W3C). For his thoughts on the semantic web see: Berners-Lee, T., Hendler, J. and Lassila, O. (2001) ‘The Semantic Web’, Scientific American, May.

11.2 Introduction

In structured systems ontology, systems designinvolves logical and physical design of data cov-ering computer programs, data storage, net-works and change management. Computerprogram specifications are made and diagramscreated to define program algorithms. Systemsprograms require input data and generate out-put data. Output data may need to be stored, sodata storage decisions, whether to use computerfiles or databases need to be made. The choicedepends on the size of data and the purpose forits storage. In object-oriented systems ontology,a class systems model forms the basis of programand other system components design.

Analysts and designers are involved in theimplementation of a new IS as part of a changemanagement program. As well as making deci-sions on hardware, software and computer net-

works, they consider how to introduce thesystem to people and organization. Changemanagement is an important issue becauselarge systems have an impact on organization.Analysts especially are involved in managingsuch organizational change resulting from anew IS.

11.3 From logical to physical datadesign

In structured systems ontology, implementation-independent design is the logical data design orlogical data model built independently of phys-ical computers and software. Implementation-dependent design is the physical design orphysical data design of data as it is stored incomputers and software. Physical design is con-cerned with making decisions on the hardwareand software required to implement a new IS.

111

0

11

0111

0

0

11p

225

Chapter 11

Systems design



• Interpret the distinction between logical and physical systems design.• Detail the design activities at system level and describe detailed design.• Apply critical skills to data design.• Critically evaluate the role of the data management and system interaction

components in object-oriented systems ontology.

In structured design, physical data designinvolves converting E-R models into physicalformats as part of the Transform Analysis.Physical data design can either be in file formator a database. Where files are used, decisionson the type of files, access methods and theirorganization need to be made. Each logicalentity in the E-R model is translated into arecord type and each attribute is translated intoa data field. The application program managesthe relationships between entities with the keys.

Database storage is common in large com-panies because organizations are interested increating corporate information and knowledge.So decisions on the type of database to be usedneed to be made. Each entity in the E-R modelis translated into a table, and each attribute ofan entity is translated into a column of the table.Systems designers determine how the entities inthe new record types or tables format will bestored. Decisions are made on how to group theentities but relationships are initially kept toreflect the logical model.

The physical data model of the selected data-base is used to organize the data. The DBMSuses logical pointers to maintain the relation-ships between entities. If people do not usesome of the entity relationships once the systemis installed then database administrators canremove them in consultation with them toimprove system performance or reduce the costof storage. The implemented system is thentested to ensure it meets performance andsystem requirements.

In object-oriented design, the class systemsmodel created during systems analysis is refinedand the data management and system inter-action components designed. For the data management component, designers considerwhether to store persistent data in files or data-bases, decide between object and relationaldatabases, and model data management objectsin UML diagrams. The system interaction com-

ponent is needed if a new IS is to be networkedor if it has to share data with other systems.

11.4 Some fundamentals ofhardware and software platform

The term for computers and software combinedin an IS is platform. Designers develop optionson different platforms that can be used to imple-ment the logical models created during systemsanalysis. Sometimes there are no options toconsider because of investment in existing platforms.

Storing data is an important issue. Thequantity of storage required needs to be deter-mined. Analysts and designers consider theexisting storage requirements and project whatwill be required in the future. They would needto consider business growth issues like sales orvolume of employees to determine futurestorage needs. Storage for each entity or per-sistent object is determined by totalling thebytes required for fields or attributes, multiply-ing the total by the number of records neededand then dividing by the number of records.The actual implementation may be as data filesor a database.

The performance of the system is themeasure of its efficiency and effectiveness.Performance is important for safety-critical ISlike emergency services. It is also important for critical functions in IS like keeping recordsof important business transactions. The Taurusstock trading system at the London Stock Ex-change and the London Ambulance Service’sComputer Aided Despatch System (LASCAD)both failed because they failed to design for theactual processing demand when the systemswere made live.

Designers seek flexibility in the choice ofDBMS to cater for future needs. Software thatis hardware-independent is preferred to ensuremaintainability and prevent obsolescence. For

226


eCommerce systems the Java programming language is used because of its platform inde-pendence. Designers need to ensure that thefunctionality of the system is assured givenmonetary and time constraints. Data storage,processor usage, and access times need to beefficient. Having more data storage capacitythan is required will mean additional unneces-sary costs, but having insufficient storage spacecould affect the performance of the businessdetrimentally.

Where multiple databases are used, design-ers need to ensure data integrity is preservedacross databases. In one case, consultants usedtwo databases for a pharmaceuticals companybecause one database could not cope with thevolume of data. They did not check adequatelyfor data integrity across the two databases.Managers were unaware of this situation andused the data from both databases in opera-tional and strategic decisions. In time, thecompany had to file for bankruptcy.

11.5 Structured design

People are not involved in drawing up thedetailed systems design documents in structureddesign. The reason is the technical content ofthe design documents required for the design of data inputs, outputs, processes and data files or databases.

During systems analysis references to physi-cal entities in the problem domain are removedfrom the systems models. In the design phasedecisions about physical details of a new ISneed to be made. The data and process modelsand requirements specification produced duringsystems analysis is transformed into design doc-uments that detail file and record structures, fileaccess mechanisms, database design andstorage media. The E-R model is used to designthe database model and the logic models usedto inform program algorithms.

During the transition from analysis to design,inefficiencies in the problem domain may beaddressed. The logical modelling process mayreveal problems in the problem domain, partic-ularly physical aspects that can be addressed. Forexample, DFD systems models may show dupli-cate physical file storage, these can be removedin the logical DFD and consolidated in one store.

11.5.1 Detailed systems designdocuments

Systems design diagrams differ from those usedduring systems analysis. Structured designbased on the SDLC includes both the computer and manual aspect of a new IS. Various designdocuments are generated including those shownin Figure 11.1.

A structure chart is used to detail the con-nection between program modules in a system.It is compiled on the basis of the HIPO tech-nique (hierarchical input/process/output). Agiven process in a system, for instance preparean insurance policy, will require separateprogram modules to interact to exchange data.The structure chart depicts the various programmodules and the data flowing between them. Itprovides a hierarchical, clear and easy to under-stand picture of a new IS in terms of programsand data movements.

111

0

11

0111

0

0

11p

227

....................................................................................................................Chapter 11 Systems design

Figure 11.1 Structured systems design documents

Grid chart

System outline

Structure charts

Record specification

File specification

Flowcharts

Hardware specification

Stored database design

A grid chart is used to show the use of filesfor updating or reading data by each programin the system. Each program is listed in acolumn and each data file is listed in separatecolumns alongside. Crosses are marked in therows for each program that makes use of a datafile, if files are used for data storage.

11.5.2 Systems design tools

There are commercial software tools avail-able to aid the systems design process. The aimof designers of structured and object-orientedsystems design tools is to make the designprocess efficient and effective. Systems designtools focus on enforcing certain practices,usually associated with a methodology like IE or notation language like E-R. They enforcestipulated design processes, whether structuredor object-oriented, program modularity anddocumentation. Their use produces better qual-ity design because they check for consistencyand integrity across different diagram types.

11.5.3 Program design

How the computer will process the data enteredinto the system is an important part of systemsdesign. The program algorithms convert thedata into the required data outputs for otherprograms or management reports. Flowchartsmay be used to design algorithms but theyenable any conceivable structure to be modelled– their flexibility is a disadvantage in some cases.Tools available for program design include:

• Editors to create and modify source codeand documentation.

• Static analysers to examine source code.• Dynamic analysers to examine running pro-

grammes.• Language sensitive editors to create syntac-

tically correct source code.

Many systems designers prefer the Nassi-Schneiderman chart because it is precise indescribing algorithms produced by a team ofsoftware developers normally associated with a system project. The Nassi-Schneidermanchart or box diagrams, illustrated in Figure 11.2are used to represent procedural constructs con-sistent with structured concepts. They help toensure correct program design in terms of:

• Functional design: well-defined and visuallypresented definitions of scope of repetition orif-then-else functions.

• Prevent arbitrary transfer of control.• Easily determine the scope of local and

global data.• Easily represent recursion.

Structured program design makes use ofmodularity. A module is a program that focuseson one function in the system. A computerprogram consists of lines of code, or algorithm,written in a particular programming languageto process data to provide particular outputs. Agood program has high internal cohesion andlow coupling. Cohesion is a measure of thestrength of relations of subroutines within aprogram and coupling measures the strength ofbonds between programs. Structured designrationalizes input and output with processingthrough structured programming. Architectureefficiency is improved through cohesion andcoupling resulting in modules of program code.

11.5.4 File design

A file design specification will define the filemedium. The decisions to be made are whetherit will be sequential or random access, the filesize and back-up procedures. The grid chartshows the programs in the system and whichfiles they access to read data or update records.Flow charts are used to depict procedures and

228


the control of the flow through proceduresrequired to complete a computer run.

11.6 Database design

Database design is separated into logical andphysical design to enable data indepen-dence. Data independence is desirable becausechanges in business needs can be enabled bychanging the logical database design and nothaving to redesign the physical computer files.Conversely, this separation enables database

administrators to change the physical databasedesign with no impact on the logical design andusers. They may need to do so to improve theefficiency of the database.

People are not involved in database design,to them the DBMS is a black box. The DBMSprovides physical data independence. As it isnot possible to predict the volume of actualqueries of the database, estimates are generatedand used to anticipate usage patterns.

The structure of the data defined duringsystems analysis determines the data model of

111

0

11

0111

0

0

11p

229

repetition

if-then-else

F TCondition

else part then part

Sequence

First task

Next task

Next + 1 task

loop condition

do-while part

loop condition

repeat-until part

Selection

Case condition

casepart

casepart

Value Value Value Value

casepart

casepart

Figure 11.2 Nassi-Schneiderman diagrams


the database and the data models from systemsanalysis are used to design the logical database.The logical record structure and how therecords will be accessed is derived from the E-R model. Each set of E-R diagrams can beconverted into a logical record type. Logicalrecord structures are defined at the system leveland include the primary keys of records. Forexample, for a relational database model theconceptual database is determined by convert-ing the E-R model into a relational model. Anentity is represented as a relation. A relation-ship is represented as a relation too with theprimary keys of the entities in the relationship.

11.7 Object-oriented systems design

The focus in object-oriented design is on thearchitecture of the new IS, quality and standardsissues. Systems designers create additional classesfor files or database storage. Unlike structuredsystems design, in object-oriented systems designa class model is not transformed but refined. Inthis sense there is no separation between systemsanalysis and systems design in object-orientedsystems ontology. The class systems modelproduced during systems analysis is enhancedwith more detail but remains essentially thesame model, though different diagrams are used to produce the logical design or imple-mentation. So it is possible for people to be stillinvolved during design.

Detailed systems design decisions are con-cerned with designing components that com-pose the system architecture. During systemsdesign the classes are refined and the classesform the basis of program algorithm designs.Like object-oriented analysis, the focus of design is on classes, reuse and assigning respon-sibilities to classes – a continuation of class modelling.

Designers take advantage of reusable com-ponents. Software development has a tendency

to address recurring coding problems. Designpatterns are used to reduce the repetitive reso-lution of the same problem. They provideencapsulated functionality and data in classesthat can be reused. Designers do not need tocreate new design for classes if they already existor can be bought commercially. Categories ofdesign patterns available are creational, struc-tural and behavioural. Patterns that can bebought commercially are termed components.

11.7.1 Additional design diagrams

During design additional diagrams are gener-ated including collaboration diagrams, statetransition diagrams, package diagrams anddeployment diagrams. Systems designers con-tinue modelling the system by selecting theappropriate diagrams.

Collaboration diagrams are used to modeldifferent objects interacting to exchange datafor a specific process, as shown in Figure 11.3.Collaboration modelling is central in systemsdesign, comparable to use case during systemsanalysis. Use cases are realized through depict-ing the necessary collaborations. Collaborationsdiagrams depict associations between objects.Collaboration in UML consists of objects inter-acting to achieve a specific purpose and can beused to show a particular operation or a wholeuse case. As they do not depict temporality,sequential numbering is used, and when itera-tion is required the numbers are nested.Branching can be similarly represented.

A package is a way to organize classes intologically related groups. It can be used forclasses identified during systems analysis andsystems design. Figure 11.4 shows a packagediagram for a database. Class A and Class Bcan be for two different database connec-tions. For example ODBMS (Open DatabaseManagement System) and CORBA (CommonObject Request Architecture).

230


Packages are useful for testing systemsdesigns. Unit testing can be done on the basisof packages. This makes it easier to manage alarge testing programme.

11.7.2 Data management component

The data management component is concernedwith how to store and manage such stable, or

persistent data. Database designers identify datastorage classes, usually based on an abstractsuperclass, and determine the collaborationrequired with business classes (identified duringsystems analysis) to determine storing andretrieving of objects.

Organizations have both transient data andstable data. An IS may produce both types. Anexample of transient data for an insurance

111

0

11

0111

0

0

11p

231

:customerDialogueinterface

:assessLiability contactOthersCompany

commenceLegalProceedings

:recordAccidentDetails

newClaim ( ) 1: getClaimForm ( )

2: recordAccident ( )

3: assessLiability ( )

4: getCompanyDetails ( )

4.1: getLegalForm ( )

Figure 11.3 Collaboration diagram for insurance claim

Dependency

Package Name

Class A

Class BPackage Name

Figure 11.4 Package diagram


company may be a quotation for a policy thatthe inquirer does not draw out. As transientdata is not needed beyond its immediatepurpose it is not stored. Some data, though, areregarded as valuable and stable. They need topersist in the system. An example is the detailsof a new policy written for a client.

Designers determine whether to store persis-tent data in files or databases. The choice ismade on the basis of how the stored data willbe used. File storage is used if the data is forone application only but it is inappropriate fordeveloping corporate information and know-ledge, because file stores would multiply witheach application created, and data integritychecks would become problematical. Multiplefile stores could not easily facilitate newinformation requirements arising from changesto business needs or markets and cannotsupport online data query.

When the data is used for corporate informa-tion needs it is normally stored in a database. Anobject-oriented database contains class objectsand their interrelationships based on a classmodel. A database is used to store data that need to persist and enable sharing of persistentdata between objects, applications and systems.Systems designers decide between object andrelational databases, and model data manage-ment objects in UML diagrams. A design classmodel is created to depict normalized relationswith multiplicity.

A database can be accessed by many appli-cations and deal with multiple and changingqueries or interrogation of the data. It facilitatesdata sharing through the external schema – theview of data in an application, and conceptualschema – logical model of data. The key toachieving such flexibility in managing the datais the DBMS. A DBMS is used to organize andmanage the physical data separately from appli-cations that use it. The conceptual schemaachieves this separation, with the external

schema being the application programs’ view ofthe data and the internal schema being thephysical storage of data in files and indexes.

11.7.3 System interaction component

The system interaction component needs to bedesigned if a new IS is required to interact withother systems. The new IS may take data asinput from another system or provide data as output to a different system. The communi-cation systems are modelled with deploymentdiagrams. A deployment diagram shows twosystems communicating with each other asnodes and the protocol and network used forlinking as communication associations.

An example is shown in Figure 11.5. It showsthe PC client, which is called a node, with aninsurance policy system and another compo-nent for database connectivity. Components arethe various functional units in a system. The PCis networked to a mainframe machine whichhas the policy database installed on it, whichbecomes active when it is called from the PCclient.

For example, client-server architecture iscommonly used in new IS. It consists of PCs,called the client, used by people, and the serverthat contains the required software. Designersmake decisions on what process to allocate tothe different server machines available and howthe different machines will communicate. Thisis done using UML physical deployment dia-grams. A deployment diagram is used to showthe physical relationships between hardwareand software components in physical systemsdesign.

11.8 Change management

The success of a new IS depends on people’sperception of it and whether they use it. The

232


introduction of a new IS will require reorgani-zation of people’s job roles, responsibilities andbusiness processes. Organizational changemanagement is concerned with managing thepeople issues that arise from such change.

Although not strictly a systems analysis anddesign issue, change management is nowaccepted as being critical for the success of anew IS and for realizing its planned benefits.Work packages in system projects may includeanalysts working in a change managementteam. People are the essence of change man-agement. The expected benefits from a new ISwill only be derived if people accept it.

Analysts and designers are involved in train-ing and educating people about a new IS as partof a change management program. Systemsanalysts work closely with business analysts todefine new job roles and responsibilities orchanges to existing ones. A key involvementarea for analysts is managing people’s expecta-tions of a new IS. Analysts’ early contact withpeople during systems analysis can form thebasis of managing such expectations, and ana-lysts are usually in a business team set-up tomanage the change.

11.8.1 Change management theory

Change management theory is concerned withhow change can be successfully realized inorganizations. The issues it addresses includeidentifying who the relevant people are, howthey are motivated, their understanding of the change and identifying and managing resistance.

People perceive any organizational changeincluding a new IS which affects them with somereservation. They do not commit fully because of fear. The change may remove their currentstatus or even their jobs. Change managementtheorists seek to understand how organizationalchange can be managed by understanding therole of people in change.

One model of change management is KurtLewins’ (1958) ‘unfreezing, moving and refreez-ing’. It begins by giving people a reason forchange and enabling them to think for them-selves why it is necessary, the ‘unfreezing’.Senior managers, once they have decided that anew IS is required, need to communicate thereasons to people. Keeping people uninformedof the need will result in anxiety and fear, andeven result in losing key people. The ‘moving’

111

0

11

0111

0

0

11p

233

PC Clientsun.jdbc

InsurancePolicySystem

<<JDBC>> Mainframe

Policy:Database

Figure 11.5 Deployment diagram


step is to inform people of the chosen change andprepare them to become party to it. This step ismore difficult than the first because it requirespeople to make the change themselves. Theircommitment to the new order needs to be strongbecause problems may arise that may deflectthem. Peoples’ involvement and commitment is particularly required during requirementsanalysis. The final step is ‘refreezing’. It requiresenabling people to familiarize themselves to thechange. People’s training and best practices arereinforced, and any problems resolved.

11.9 Systems design and the CriticalFramework

Arguably, systems analysis is more importantthan systems design for understanding andspecifying system requirements. Systems designis nevertheless significant because it involves atransformation step in structured systems analy-sis, which is problematical. In object-orientedsystems ontology its significance is in how a classmodel continues to be progressively developed.


Figure 11.6 is the Critical Framework popu-lated with critical reflection on systems design.As the bottom layer shows, many questions con-cerning the four themes of criticality arise fromthe assumption of a data-centric or object-centric reality.

The notion of ‘stable data’ underpins struc-tured systems ontology. Data are consideredsufficiently stable to describe business activitiesin a problem domain. It is because they are con-sidered stable that they are stored in corporatedatabases. Decisions regarding file storage ortypes of databases, relational or object-oriented,depend on the IT/IS strategy of the organiz-ation. Where corporate data forms a significantpart of strategy then database storage will be

required. If unstructured data like image, voiceand graphics needs to be stored then an object-oriented database is more appropriate.

Structured systems ontology is a ‘functional’characterization of the problem domain, whichreinforces the input, process and output view ofan IS. It is arguably a ‘computerization’ per-spective, in the sense of a mechanistic character-ization of real human problems. Its focus on dataanalysis gives primacy to functions, data andprocesses as defining characteristics of a problemdomain. This mechanistic characterization ofthe problem domain leads to a separation of sys-tems analysis and systems design, because thelatter is closer to the machine itself and in whichthe real world human problem is reflected.

Structured systems ontology does not ques-tion this separation. Whether systems design caninform systems analysis is both a transformatorycritique and refashioning of traditions. Changesin practice, such as prototyping and user inter-face prototypes during requirements analysis,indicate that the separation is flawed. IS devel-opment benefits from intertwined systemsanalysis and design activities, rather than con-crete separation.

The structured systems ontology focus ondata, with ‘data analysis’ being a significantelement of database design, has consequenceson how an organization is modelled for ISdevelopment. A corporate database is regardedsufficient to describe or model the organization.The social element of organization is notaccounted for in such systems ontology. Also,importance of organizational knowledge and itsmanagement means that a corporate databaseis insufficient as a model of an organization.Organizations are now also building ‘know-ledge bases’, which are significant in theirattempts to manage organizational knowledge.

A database stores organizational data import-ant or critical to a business. Modelling an organ-ization as databases is problematical because the

234


modelling process needs to reflect human andorganizational needs. In pragmatic terms,because of costs a database is only composed ofdata models of organizational functions like per-sonnel or sales. In a process view of organizationit is composed of processual data models.

Systems analysts and systems designers needto decide whether their perspective of the datamodel from which a database is designed is objective or subjective. From an objec-tive perspective the data model is the organiza-tion. Such a personal construct will have

111

0

11

0111

0

0

11p

235

Apply formalmethods


(Messy world)

Information technology,implementation,business change

and growth

Systemsontology

Design

Formal solution,logical design,

physical design,mechanistic,coding from

logical design

Pragmaticresolution

???


Is a relational or objectdatabase relevant?

Develop knowledge

Structured andobject-oriented design,

program design,file design,

database design

Resolveproblems

Determine a pragmaticresolution to problemswith formal methods,

combine relational andobject database,consider costs


Can design informanalysis?


Is data hierachical,networked or relational?

Is encapsulation ofdata in an object

representative of theproblem domain?

Critical skills

What kind of heuristicsis needed to interpret

notion languagesin context?

Figure 11.6 Critical framework: ontology and systems design


consequences for corporate database design.From a subjective view the data model is oneinterpretation of an organization. It does notrepresent the whole organization for all time or the varied perspectives of its members.Database design from this perspective is likelyto be a truer reflection of real human problems.

Problems with Transform Analysis in struc-tured systems ontology are being overcome by emerging systems analysis and designapproaches like ASD and XP. They conceptu-alize systems development as continuous, thusnot having to make a transition from systemsanalysis to systems design.

The critical development of database tech-nology itself reflects the development in onto-logical knowledge of organizational data,information and knowledge. Various databaseconceptions are reflected in developments indatabase types: hierarchical, networked, rela-tional and now object-oriented databases.Database technology is significant in definingsystems ontology appropriate for organizations.

Each stage of development in database tech-nology permits richer representation of realhuman problems. Developments in databaseconceptions reflect both transformatory critiqueand reflexivity, depicted in Figure 11.6. Systemsdesign is significant for systems ontologybecause of the physical capabilities and limits ofavailable IT. Knowledge of program and data-base design determines how a system is definedand designed, and its design has an impact on the performance of the problem domain orthe organization. Analysts and designers needto bring their personal constructs on systemsdesign to the surface and reflect on knowledgeand practical validity.

11.9.2 Separation of analysis and design

In structured systems ontology there is a distinctseparation of systems analysis and systems design

phases. Earliest versions of the SDLC made sucha distinct separation, but have now accepted aspiral version of software development. It isarguable whether this separation reflects theproblem domain, systems ontology, organiza-tion ontology or even the actual work of practi-tioners. Many developers move between analysisand design, and organizations would rathermake IS development an operational issue thana distinct system project.

Though object-oriented analysis and designcaters for the non-separation of systems analy-sis and design, through its progressive develop-ment of a class model, on the whole, prac-titioners persist on completing systems analysisbefore undertaking systems design. The reasonis the timeboxing constraints of system projectmanagement and the discipline imposed byproject management. In essence, business con-straints prevent the fluid development of a classmodel.

The separation of analysis and design in struc-tured systems ontology raises practical prob-lems once a system is implemented. Often, it isnecessary to make amendments to the detailedanalysis and design documents because of chan-ges in requirements. Business requirements oftenchange during systems development, and occurbecause of market or competitor forces.

For both structured and object-orientedsystems ontology, another reason for change inrequirements is lack of information on what isrequired. During requirements analysis peoplein the problem domain are expected to providea detailed account of what they require. Theyare unable to do so in the set time for require-ments analysis or timebox period allocated in asystems management work breakdown package.

Requests for new requirements or changesto captured requirements arise as new informa-tion becomes available to people. Often thechanges are only reflected in the design

236


documentation but not the analysis documen-tation. The requirements specification becomesinconsistent with design documentation. This isa problem of separating analysis and design instructured analysis.

Earlier development in prototyping, RADand JAD reduced the distinction betweenanalysis and design. The recent move to ASDis a stronger statement for the non-separationof analysis and design activities.

11.9.3 Pragmatism

The pragmatic resolution of which database tochoose reveals a mixed approach rather thanadhering to a single type of database. Designersneed to reflect on how they make their choices.As Figure 11.6 shows, critical thinking leadsdesigners to make use of mixed databases con-taining relational and object-oriented elements.Such a choice is significant from a systemsontology perspective. It indicates that both models, rather than just the one, better describe the actual problem domain or real humanproblems.

Systems analysis, design and implementationdoes not have to be either structured or object-oriented. It can be a mixture in practice. It ispossible for practitioners to make use of struc-tured analysis and design but implement anobject-oriented system. It is also possible toimplement a systems design using the object-oriented approach in a combination of con-ventional and object-oriented programminglanguages.

Systems analysis, systems design and pro-gramming can each be done in different genresor practices for the same system. So it is possi-ble to do the systems analysis using structuredinstruments, systems design using object-oriented instruments, and programming in anobject-oriented language like Java. Other per-

mutations are also possible, but practice tendsto adhere to one underlying approach in a givensystem project.

In structured systems design, the technicalcontent of design documents prevents design-ers from involving people in designing. Toensure that the completed system is valid, it isvalidated with requirements specification, butnormally this is not done thoroughly. In con-trast, people remain involved in object-orientedsystems design. The problem domain classmodel is refined during design rather then sep-arately developed, so people can still beinvolved, though they will not comprehendtechnical program and database terminology.

IS as a field itself has recognized the impor-tance of change management through reflex-ivity and refashioning of traditions criticality.Methodologies and in-house expectations nowrequire analysts to be significant members of achange management team. Analysts need toappreciate that a new IS brings organizationalchange. Though it is important to manage care-fully the people aspect of the change, analystsmay not be the most appropriately skilledpeople to do so.


11.10.1 Personal constructs for systemsdesign

Activity A

Table 11.1 is a sample repertory grid forsystems design. Reproduce the grid on a spread-sheet and add further columns and their polaropposites that you consider relevant. To objec-tify personal constructs in systems design, com-plete the grid by following the details on howto use a repertory grid in section 1.10.1.

111

0

11

0111

0

0

11p

237


11.10.2 Logical data design

Questions

1 What is meant by ‘data independence’ andhow does logical data design during systemsanalysis contribute to achieving data inde-pendence?

2 How is the E-R data model used for logicaldata design?

3 How are logical data models used in defin-ing the conceptual schema in a DBMS?

4 Critically discuss the idea of the progressivedevelopment of a class model throughsystems analysis and systems design.

11.10.3 Physical data design

Questions

1 What is meant by ‘physical data design’ andwhat is the role of the DBMS internalschema?

2 What kinds of platform decisions need to bemade for physical data design?

3 What value do UML deployment diagramsadd to physical systems design?

11.10.4 Database design

Activity A

Databases are used to store corporate data anddevelop it as a corporate resource or informa-tion assets.

1 Identify a database in your organization.2 Enumerate the kinds of data it stores.3 Analytically evaluate the corporate informa-

tion value of the stored data. Is it used to addvalue to the organization? Is it used tocompete with other firms or differentiateyour organization from others?

11.10.5 Managing change

Activity A

• Find an example of a system project that hasfailed because of poor change management.For example, the London AmbulanceService’s Computer Aided Despatch System(LASCAD).

• Read any one version of LASCAD. You canuse either the official report on LASCADavailable at http://www.cs.ucl.ac.uk/staff/

238


Table 11.1 Personal constructs for systems design

Pole 1 Pole 2


Stable Fluid

Mechanical Organic

Explicit Tacit

Conceptual Actual

Dat

a m

odel

Info

rmat

ion

Kno

wle

dge

Dat

abas

es

Log

ical

des

ign

Phy

sica

l de

sign

Org

aniz

atio

n

A.Finkelstein/las/lascase0.9.pdf (accessed26 March 2004) or a personal view availableat www.lond.ambulance.freeuk.com/cad.html (accessed 26 March 2004).

• Analyse LASCAD in terms of Kurt Lewins’model of change management.

• Detail the activities you would initiate forLASCAD for each of Lewins’ model steps.

• Detail the methods you would use to con-vince people to accept the change.

111

0

11

0111

0

0

11p

239


Lewin, K. (1958) ‘Group Decision and Social Change’, in Swanson, E., Newcombe, E. and Harley,R. (eds) Readings in Social Psychology, New York: Rhinehart and Winston, pp. 459–473.

For an alternative object-oriented systems design see: Shlaer, S. and Mellor, S. (1992) Object

Lifecycles: Modelling the World in States, Englewood Cliffs, NJ: Prentice Hall.


Part V covers the broader issues in the development of knowledge and practice. The PCFsection in each previous chapter focused on reflection and critical thinking on a specific systemsanalysis and design topic. In this part, the question of how knowledge of systems analysis anddesign is acquired and accepted is covered and critically considered. Systems ontology is heavilyinfluenced by innovations in software programming. Radical changes in knowledge and prac-tice stem from new ideas, concepts and methods developed by practitioners in software. Thestructured, object-oriented, and agile concepts all originate in software programming.

Since its introduction in the 1960s, the engineering metaphor in software development hasdominated intellectualism and practice. Both structured and object-oriented systems ontologyfocuses on systems and systemic factors. Chapter 12 is on social action. It examines the non-systemic social, cultural and political factors in IS development. Systems analysis and designis undertaken in a political, organizational and cultural context. This questions the suitabilityof structured systems ontology because of its assumption about factual design knowledge, andto a lesser extent object-oriented systems ontology. Structured systems ontology has beenadapted subsequently to account for some of these criticisms.

Chapter 13 is a general critical reflection on the previous parts of the book. It is a discus-sion on the assumptions made of users, systems analysis, systems design and organization instructured and object-oriented systems ontology. The chapter is a consolidated critical reflectiondrawing together various strands of critical argument.

Chapter 14 introduces paradigm as a way of thinking and acting. IS development has pro-gressively resulted in paradigms of thinking and knowledge. IS developers unwittingly acceptcertain paradigms of knowledge and act upon it. No one paradigm is the solution to the problemof IS development. Each paradigm makes different assumptions of systems, instruments, IS,organization, people (‘users’), and systems analysis and design, which researchers and practi-tioners have subsequently challenged. Analysts need to be aware of paradigms and understandthat their actions are underpinned by explicit or implicit choices of paradigm.

In terms of the map of criticality presented in Figure 1.1, Chapter 13 covers refashioningof traditions and Chapters 14 and 15 cover transformatory critique. Developing theoreticaland conceptual knowledge can enhance a PCF, especially if it is critically evaluated. Suchknowledge can benefit the practice of systems analysis and design too if it is based on under-standing how knowledge is acquired, and how it is accepted as valid knowledge by a communityof practice such as systems analysts and IS developers.

111

0

11

0111

0

0

11p

241

Part V

Criticality, paradigms and IS development

12.2 Introduction

Stemming from the SDLC, structured andobject-oriented systems analysis and designfocus on systemic factors. They characterize ISdevelopment, and systems analysis and design,as a systemic problem that can be resolvedrationally and objectively. The set of assump-tions underpinning objective problem-solvingthough does not account for organizational andhuman factors. Research reveals how socialaction affect IS development. This chapterexamines such factors and considers how know-ledge of them can be used to improve know-ledge and practice.

In addressing the central problem of how todevelop IS, practitioners and researchers needto be aware of social theory and social action.The non-systemic factors are organizational,social, cultural and political, and they need to

be reflected in systems ontology. They aretermed social action here. This is essentiallyhuman action in a social context, its explana-tion and knowledge of social factors relevant forIS development. Knowledge of social action isimportant because it poses potential obstacles tosystems analysis, systems design and implemen-tation if it is not understood and accounted forin systems ontology. The relations betweentechnical factors, social action and IS are shownin Figure 12.1.

The figure depicts the relations betweentechnical factors, social factors and IS. It showsthat the relation between technology and socialaction is bi-directional. Technology affectssocial action and social action affects technol-ogy. Information Technology is a keen exampleof this bi-directional relationship. Both thesefactors determine the conceptualization andrealization of IS.

111

0

11

0111

0

0

11p

243

Chapter 12

Social action



• Apply refashioning of traditions criticality to systemic problem-solving strategies.• Analyse and assess the impact of social action on systems analysis and design,

generally on IS development.• Evaluate the effectiveness of using instruments in the context of social action.

12.3 Social theory and IS

Interpretive researchers have framed ISresearch questions in the context of socialtheory to understand and explain IS and ISdevelopment. For example, the structurationtheory of society in sociology has been used toexplain IS. Such accounts based on socialtheory add important critical considerations inconceptualizing and realizing IS. Other aca-demics have combined knowledge of technicaland social action in methodologies to improveeffectiveness.

The fundamental concept in interpretive ISresearch is the subjective construction of reality.It asserts that knowledge of reality is sociallyconstructed rather than being an objectiveentity. Its implication for structured and object-

oriented systems ontology is that systems modelscannot be construed as being objective. E-Rand class systems models become a matter ofsocial construction, rather than being objectiveor ‘correct’. ‘Data’, ‘process’, ‘class’, ‘object’and ‘relationships’, and other systems model-ling terminology, is not an objective fact. Theydo not exist independently of humans – both ISdevelopers, including systems analysts, andpeople in the problem domain. The subjectiveconstruction of reality means that people attachunique meanings to their actions and interpre-tations of others’ actions. IS developers need toaccount for these interpretations in systemsmodels. Accounting for social action affectswhat is represented in systems models and whodecides what to include or exclude.

244

Part V Criticality, paradigms and IS development................................................................................

Information System

Information TechnologyComputer system

Internet/webMobile technology

Programming languageSoftware

Social actionSocial context

Meaning/interpretationOrganization

CulturePolitics/powerStakeholders

Determines

Determines

Figure 12.1 Technical factors, social action and IS

12.3.1 Social and cultural factors

The ‘social life’ of information and knowledgeis significant. Each organization is socially and culturally unique. It forms the context forIS development. This context has an impact on methodologies and instruments used and onhow effective systems analysts and designers can be.

Interpretive and socio-technical systemsontology recognize social action. It seeks toaccount for the social, political and cultural fac-tors in IS development. Socio-technical ideasare incorporated in the ETHICS and Multiviewmethodologies, but have not had an impact onpractice. Now the activities of agile softwaredevelopers are beginning to make social actionthe focus of systems analysis and design.

Information and knowledge have proved tobe great levellers of status in organizations. If anew IS challenges the existing status of individ-uals or groups it will be heavily contested. Theymay become ‘passive’ during the developmentand withhold information. In some cases groupswhose high status is threatened by a new IS willobject and create political issue. They will con-flict with newly formed status groups privilegedby a new IS.

Other organizational issues include culture,values and ‘rites and rituals’. Research showsthat organizations have ‘value systems’ thatneed to be recognized by IS developers, whothemselves may have a different set of values.A particular issue is the culture of information,its value, sharing of it in business problems, andcapitalizing on it are significant issues in ISdevelopment. People may withhold certaininformation if they deem it politically powerfuland significant. Where the culture is one ofindividualism, competition and non-sharing ofinformation, systems design needs to reflect it inthe data and information provided. When theculture is team-based, consensual and coopera-tive, a different systems design is needed.

Another aspect is the behaviour of people in theproblem domain and norms shared by groupsthat may be contrary to those of other stake-holders or even IS developers. Information maybe heavily protected.

12.3.2 NIMSAD

There is recognition of normative values inadopting methodologies. The Normative Infor-mation Model-Based Systems Analysis andDesign (NIMSAD) originates in systems think-ing and addresses problem-solving in IS. It is an action research evaluation framework, which enables an understanding of subjectiveprocesses.

In the NIMSAD framework problem-solvingconsists of four elements:

• The problem situation and understanding itas a ‘situation of concern’.

• The problem-solver.• The problem-solving process.• Evaluation of the above three at three time

periods (t0, t1, t2).

It is used to evaluate methodologies-in-actionand contains four elements: methodology incontext, methodology user, methodology andevaluation. Each of these elements consists ofasking a set of questions and interpreting theanswers in terms of problem solving.

12.4 Organizational factors

The flow of information is an important defin-ing characteristic of organization. Informationflow ‘binds’ an organization. A new IS results indifferent information flows that may raise con-flicts of interest. Change management is criticalin recognizing different interests and findingstrategies for reconciliation of conflicting groupsof interests.

111

0

11

0111

0

0

11p

245

......................................................................................................................Chapter 12 Social action

Stakeholder analysis is used to understandwho or what group has an interest in a new IS,what potential conflicts of interest exist, andhow they should be managed. Systems projectmanagers use it to identify interested groups,assess their power of influence and developstrategies for managing stakeholder interestsand expectations. Analysts need to behavediplomatically with powerful but sensitive stakeholders.

Organizational change resulting from IT is central to the ETHICS methodology. It isparticularly oriented towards systems analysisand design that is sensitive to job roles and jobsatisfaction. Involving people or participation in the systems design decision-making process facilitates this sensitivity in ETHICS.

12.5 Political factors

The politics of information and knowledge is asignificant factor in IS development. Practi-tioners disregard politics because it questionsthe assumption of objective and rationalproblem resolution underpinning systems ontol-ogy. Structured and object-oriented systemsontology do not explicitly recognize politics insystems analysis and design. They encouragesystems analysts to interact with people free ofpolitical bias, and interpret the problem domainrationally and logically. Such objective systemsontology does not recognize politics.

Similarly, training courses, and often degreemodules on systems analysis and design, do notadequately consider the laden politics implicitin IS development. Consequently, analysts can become pawns in political struggles of orga-nizational stakeholders interested in develo-ping stronger political power through the development of particular IS.

Interpretive systems ontology can allow forpolitical factors. Though not entirely subjective,

socio-technical approaches acknowledge socialconflict. SSM, Multiview and ETHICS recog-nize conflict among stakeholders and differentworld-views of developers and people affectedby a new IS. SSM focuses on ‘human activitysystem’ and uses systems theory to propose holistic solutions to achieve predetermined purposes. It acknowledges the importance ofpeople and describes their differing perceptionsand conflicts in systems models.

Analysts developing inter-organizational IS,or networked organizations, in particular needto be aware of political factors. Such networkedIS involve multiple organizations vying forpolitical dominance. In the case of a manufac-turing organization and its suppliers, a power-ful manufacturer will be interested in dictatingterms to suppliers, and the proposed networkedsystems design will reflect the shift in power toit. Such systems change traditional businesspractices and have an impact on economictransaction costs and organization structure.

12.6 Social theory in the CriticalFramework

Some researchers argue that social action defiesrational explanation characteristic of structuredand object-oriented systems analysis and design.Systems ontology need not be devoid of socialaction though. It can account for social action.For example, socio-technical and interpretiveapproaches recognize varying social perspec-tives and political conflict among stakeholders.Analysts also need to account for social actionin personal constructs because IS developmenthappens in the context of social action. Analystsneed to develop appropriate social action per-sonal constructs and consider how they fit intoa PCF.

The assumption of rational human behav-iour made in structured systems ontology, andto a lesser degree in object-oriented systems

246


ontology, does not account for social action,particularly organizational politics. IS develop-ment is heavily influenced by political power.This puts the analysts’ task of deploying require-ments analysis techniques in a charged politicalcontext. Line managers will determine peopleavailable for interviews or observation. Theinformation interviewees volunteer will dependon their perceptions of a new IS and its affecton their jobs and status. All these decisions are social and politically motivated in an organizational context.

Figure 12.2 is the Critical Framework popu-lated with critical reflection on social action(non-systemic factors). As the bottom layershows, questions concerning the four themes ofcriticality arise. The question of adapting instru-ments to model social action is raised in the prag-matic component. Developments in ASD, basedon XP, can be interpreted as modelling socialaction. The AgileAlliance Manifesto restates thepractice of software development in comparisonto structured systems ontology as principles:

• Individuals and processes over processes andtools.

• Working software over comprehensive soft-ware.

• Customer collaboration over contract nego-tiation.

• Responding to change over following a plan.

Significantly, all the things sought in emergingsystems ontology are characteristic of the RealWorld Component of the Critical Framework.ASD is now incorporating them into agile sys-tems ontology. XP uses the stories people can tellof their experiences of the problem domain todevelop implementable models. The stories arecaptured as ‘storycard’ and stored in structureddatabases, subsequently are analysed to deter-mine requirements and functionality.

12.6.1 Mutuality and sharedunderstanding

A significant issue in systems ontology notaddressed in structured and object-oriented sys-tems ontology is mutuality and shared under-standing. Mutual IS development has onlyrecently been accepted through participative ISdevelopment or analysis and design that involves‘users’. Even more important is shared under-standing of IS development and a new IS itself.

Developers and ‘users’ do not have a sharedunderstanding of a new IS, it is even lackingamong users. They each approach its concep-tion, analysis, design and realization from verydifferent perspectives, and develop it in equallyvarying contexts. The developer and analyst actfrom a technically informed viewpoint and theuser from an organizational viewpoint, in whichIS are a means to an end – organizational goal,task achievement, workflow support or processimprovement.

Shared understanding depends on commu-nication and communicative methods that arenot sufficiently considered in systems ontology.The instruments used to conduct systems analy-sis and design originates in a technical context– programmers and analysts technical prob-lems. The instruments are used euphemisticallyto allay ‘users’ concerns, and even propoundedas enabling ‘communication’ and participationwith them. Practical use, though, reveals howuninformed or unintelligible users remain.Analysts need to explore alternatives that gen-uinely develop shared understanding of ISdevelopment and the IS itself.

12.6.2 Best practices and COTSsolutions

The design of software components andCommercial-Off-The-Shelf Software (COTS) isbased on best practices. When implemented ina company, business processes in it are altered

111

0

11

0111

0

0

11p

247


248


Apply formalmethods


(Messy world)

IS and IT, social conflict,power, struggle

Systemsontology

Social action

Politics,culture,

organization,interpretation,

meaning,individuals,

workingsoftware,

collaboration,change,

mutuality,shared understanding

Pragmaticresolution

Reflect in tools andtechniques

Interpret formalisms inpracticeDevelop knowledge


and tools

Resolveproblems


Can people be involvedmore?

How can socialorganization beincorporated?


Can social action beunderstood in terms of

systems ontology?How does social actionaffect system design?How can non-systemicfactors be reflected in

systems ontology?

Critical skills

Can techniques and toolsbe adapted to reflect

social action?

Figure 12.2 Critical framework: social action

to suit the information processing design basedon best practice. Solutions based on best prac-tices have resulted in the failure of companiesin which they were implemented.

A systems ontology that recognizes the socialand cultural uniqueness of organization wouldform the basis of questioning the use of bestpractices in systems models and COTS. Analystsare involved in deploying Enterprise ResourcePlanning (ERP) or Customer RelationshipManagement (CRM) COTS. Often, the prob-lem domain has to be changed to suit the COTSbeing implemented. This means that the organ-ization itself is changed. This is a highly ques-tionable practice, which can result in disruptionsand even cause poor performance.

The same observation can be applied to ISdeveloped using software components. As solu-tions components embody certain ‘problemdomain’, for which they were originally devel-oped. The attributes and operations in classesmay be too complex to change for the targetproblem domain. So the target problem domainis often changed to suit the componentized solution.

The same critique applies to methodologiesas planned action. Methodologies embody bestpractices for developing IS in a planned andsystematic manner. They are also underpinnedwith ontological assumptions about the‘problem domain’. Often these remain hiddento practitioners. Research reveals that method-ology use in organizations is low. When it isused it is adapted to suit the organization usingit or selectively applied alongside in-house prac-tices. When a methodology is deployed, analystsoften have to change their practices to applyunfamiliar instruments. They often becomeblasé as a result.

12.6.3 Deploying instruments

How knowledge of social action can be reflectedin systems ontology is a significant issue in IS

development. Figure 12.2 provides exemplarycritical questions. Transformatory critique issignificant because it can result in alternativeapproaches like ETHICS or XP that accountfor social action. XP focus on social action withthe ‘storycard’ technique to capture the socialaspect in systems design. It may be interpretedas situated action.

Non-systemic factors affect significantly thedeployment of instruments. The rational andobjective base of structured and object-orientedsystems ontology instruments mean they are not capable of acknowledging varying humanperspectives and political conflict characteristicof social action found in a problem domain.Instruments based on structured systems ontol-ogy particularly need to be adapted.

In terms of the pragmatic component of thecritical framework in Figure 12.2, analysts needto consider non-systemic factors when analysinga problem domain. This can be achieved byquestioning systems ontology that underplays ornegates politics, culture and organization. Alter-native systems ontology, for example ETHICSor ASD, can be analysed to evaluate how theyseek to reflect such factors in instruments andIS development.


12.7.1 Personal constructs for socialaction and organization

Activity A

Table 12.1 is a sample repertory grid for organ-ization and non-systemic factors in IS develop-ment. Reproduce the grid on a spreadsheet andadd further columns and their polar oppositesthat you consider relevant. To objectify per-sonal constructs in organization, complete thegrid by following the details on how to use arepertory grid in section 1.10.1.

111

0

11

0111

0

0

11p

249


12.7.2 Accounting for social action

Questions

1 Discuss what uses systems project managersand analysts can make of stakeholder analy-sis results to manage political issues in ISprojects.

2 Critically discuss whether situated actionaccounts better for social action than plannedaction.

3 The E-R, DFD, and class models lack socialcontext. Discuss how you would deploy themin actual situations to take account of socialaction.

4 Critically discuss structured and object-oriented systems ontology from the ontolog-ical perspective of social construction ofknowledge.

Activity A

Compare structured systems ontology withASD. Use the sources for ASD given in section12.7.4 and your own:

• Is ASD a methodology?• Is it appropriate to characterize ASD as sit-

uated action rather than planned action?Explain your position.

• How does ASD respond to change in systemrequirements?

• What instruments are used to cater for theagile manifesto claim of ‘Individuals andinteraction over processes and tools’?

• How does ASD cater for social action?

12.7.3 Political and cultural factors

Activity A

For this activity use the information you haveon LASCAD from Activity A in section 11.10.5and additional information you can collect.

• Identify three political factors that had animpact on LASCAD’s development.

• Discuss how each one affected systems analysis and design.

250


Table 12.1 Personal constructs for organization

Pole 1 Pole 2

Organized Unorganized

Planned Unplanned

Captured Not captured

Consensus Conflict

Context Abstract

Stable Fluid

Mechanical Social

Process Individual

Contract Customer

Negotiation Collaboration

Soc

ial

acti

on

Pol

itic

s

Cul

ture

Str

ateg

y

Inte

rnal

Cha

nge

Col

labo

rati

on

Ext

erna

l

• Analyse the impact of London AmbulanceService organization culture on LASCAD’sdevelopment.

• Discuss appropriate systems ontology formanaging the LASCAD project capable ofaccounting for social, political and culturalfactors.

111

0

11

0111

0

0

11p

251


Surf the Agile Alliance manifesto site at http://agilemanifesto.org/. Analyse how the SDLCsystems ontology is replaced with one that reflects social action.

Authoritative information on ASD is available at www.agilealliance.org.


Brown, J. S. and Duguid, P. (2002) The Social Life of Information, Boston, MA: Harvard BusinessSchool Press.

For an understanding of the philosophical basis of methodologies see: Fitzgerald, G. and Avison,D. (2003) Information System Development: Methodologies, Techniques and Tools (3rd edn), London:McGrawHill.


13.2 Introduction

The problem of IS development remains unre-solved and is continually being advanced byemerging understanding, knowledge and prac-tice. Structured analysis and design is the earli-est attempt to develop consistent knowledge ora shared ‘value system’, but its ontological basisof data and processes do not account for socialaction. Object-oriented analysis and design isthe most recent body of knowledge. Throughcertain UML diagrams it can develop classmodels that reflect ‘actors’ in the social context,but arguably not social action.

Structured systems ontology characterizes ISdevelopment as ‘engineering’ an artefact. The

complex elements of humans, organization andsocial context are considered subsidiary. Theseelements form the social context in which an ISis proposed, designed, built and used to achieveorganizational goals. Methodologies, tech-niques and tools, and professional IS develop-ers, including systems analysts, all have tooperate in this social context. Researchers andpractitioners are increasingly acknowledging itsimportance in software development andsystems analysis and design.

The various strands of criticality in previouschapters on systems thinking, systems analysts,requirements gathering, data and process model-ling, logical modelling, class models and systemsdesign all need consolidated critical reflection.

252

Chapter 13

Critical reflection



• Evaluate themes in systems ontology: engineering metaphor, organization,instruments, modelling and people.

• Evaluate the value of the concept of computer-independent design in systemsontology.

• Critically evaluate structured and object-oriented systems analysis and design andtheir respective ontological basis.

• Evaluate the relevance of planned action and situated action in systems ontology.• Apply transformatory critique to structured and object-oriented systems ontology.

Deeper critical analysis is developed in this chap-ter of the premises and assumptions of system,humans and organization made in structured andobject-oriented systems ontology to engendertransformatory critique. The critical coverage willencompass how the problem of IS development isdefined, conceptions of IS itself, adequacy ofinstruments for data, process, and logic model-ling, object modelling and systems design.

13.3 Defining the IS developmentproblem

Characterizing IS development is problematicfor researchers and practitioners. It needs toaccount for technological, systemic, human,organizational and social elements. There are no metrics to determine relative weights orimportance of these elements but satisfactorycharacterization of the problem needs to bebased on clear understanding of the significanceof each one. Research in IS, and recent practice,indicates that the human and social elementsneed to be central rather than peripheral.

Various methodologies and approaches,including emerging approaches, give varying,and often unequal, weight to one or a combina-tion of these elements. Structured and object-oriented systems ontology emphasize tech-nology. Structured systems ontology is con-cerned with the efficacy of using computers, so itemphasizes completeness of data, its unambigu-ity and non-redundancy to enable efficient com-puter processing. Object-oriented systemsontology emphasizes systemic relevance ofobjects, the services they provide, and how theycollaborate with other objects.

Through research and practice the other ele-ments are becoming recognized as significant.Socio-technical approaches provided theseminal focus on human and social elements,but maintained the supremacy of technicalknowledge. ASD gives primacy to individual,social and organizational elements and under-

plays technical and contractual knowledge andpractice.

The ontological basis of systems and systemsinteroperability is also being recognized, forexample in ontological definitions of domainknowledge. Ontology management tools aredesigned to enable sharing and reuse of onto-logical knowledge of the problem domain.Critical questions concerning how knowledge iselicited, constructed and formalized informresearch into systems ontology.

A significant problem for developing onto-logical system knowledge is the proposition thatsocial action, or human and social elements,defy rationalization. Nevertheless, since theyare constituents of IS, they need to be includedin systems ontology and IS development.Systems analysis and design in some form,whether planned or contextual, is a vitalelement of the problem. Whereas structuredand object-oriented systems ontology construethe problem in terms of technological problem-solving, underpinned with rationalism, ASDconstrues it as situated and contextual activity,underpinned with pragmatism. The emergingASD alliance recognizes all the elements of theproblem but shifts development activity tohuman and social elements.

Defining the process of IS development isproblematical too. The objective and rationalbasis of the SDLC defines it as a sequentialprocess, consisting of specification, design andimplementation. Even with later additions recog-nizing iteration and spiralling between phases,practitioners maintain a phased approach de-marcated into requirements analysis, systemsdesign and implementation. RAD and JADcompress the sequential process activities tospeed development. Prototyping iterates amongthe activities until a satisfactory product is devel-oped. The emerging ASD jettisons the plannedaction basis of the whole process and its activi-ties, and engages with individuals, seeks working

111

0

11

0111

0

0

11p

253

................................................................................................................Chapter 13 Critical reflection

software rather than technical efficiency, regardscollaboration as more important, and makes theenabling of change central in the developmentprocess.

Modelling is a significant issue in definingthe IS problem because it is the basis for devel-oping IS. As an IS consists of all the elementsenumerated above, the modelling process needsto cater for them comprehensively and in suffi-cient detail. The focus on data and processes instructured systems ontology neglects socialaction. Object-oriented systems ontology con-siders them peripherally. ASD is based on thesefactors. A subsidiary problem is the type ofmodels developed. The prevalent form is thepassive model type, which is abstracted anddetached from reality, rather than the activemodel type, which can be dynamically linked tosocial action or human activity. Class modelsthough are capable of dynamic binding.

13.3.1 Abstract forms and reality

Systems analysis and design is a process ofabstraction from actual, real human problemswith the resultant forms called systems models.A model is composed of pertinent elements,those judged to be relevant by modellers, withother details of the actual situation removed.Such models contain abstract forms. In struc-tured systems ontology the abstract forms areentities, attributes, relations, cardinality or theE-R model. In process models abstract formsare process and logic. In object-oriented systemsontology the abstract forms are classes, objects,attributes, operations, encapsulation, relation-ships, hierarchy, and polymorphism, or theclass model.

E-R and process models and class model aretechnical notations considered sufficient to rep-resent reality. The problem is not how to dupli-cate reality, which is not achievable, but itspertinent features need to be reflected in systemsmodels. The very need for an IS is rooted in

human and organizational activity, and remov-ing details during modelling raises critical ques-tions. What details should be removed and whyremove them are significant issues because theydetermine how effective a system will be inoperation. The corollary issues are what detailsshould be included and why. Systems modelsthat remove details pertinent to business needsresult in IS that tend to be underused or notused at all. Conversely, what new details shouldbe added to models to improve business per-formance is significant too because it affords the opportunity to create a new reality thatcould provide benefits. eBusiness, eCommerce,and networked organization are examples ofsuch transformations of organizational realitythrough radical modelling.

Who should decide what details to includeor remove is pertinent. Analysts and designersmake the decisions in structured and object-oriented systems ontology. In the earliest ver-sions of structured IS development, developerssolely decided definitions of the ‘problemdomain’ and the activities emphasizing conse-quent technical compliance of a new IS. Theresulting IS were heavily biased in IT.Subsequent approaches have introduced ‘par-ticipative development’ and ‘joint development’to include people, though people still lack skillsrequired to understand systems models andmake informed intelligent contribution.

The assumption that IS can be engineeredis central in the abstraction process. The SDLC,and methodologies based on it, support thepremise that an IS is an engineered product. In methodologies, the engineering analogy isapplied to define the problem, specify what is required, design the system and then implement

the design. This introduces an additional layerof abstraction in structured systems ontologyand modelling notations. This is the separationof design from the computer – computer-independent design. It is the distinction betweenthe logical and physical design in structured

254


systems ontology. The logical designs constitutethe abstract forms that in turn are convertedinto physical design – the actual computersystem.

Reality is systemless. The notion of systemitself is an abstract form, which is used as an‘organizing concept’, to organize ideas andthoughts about reality. It is a fundamentalelement in the definition of the problem of ISdevelopment and conceptions and definition ofIS itself. Human and organizational need forinformation is characterized as an ‘Informa-tion System’. Systems thinking is incorporatedinto the Multiview methodology. The systemabstract form is powerful because it is conciseand precise in providing techniques for includ-ing and removing details of reality in models.The sophistication of IT, the internet and theweb in turn lead to sophisticated interpretationsof systems in the world.

The process of abstraction is reflected furtherin systems project management. Project plansdefine in detail activities of a project team andresources required to produce an IS. Such a plan is an abstract form of organized humanactivity. Project managers’ monitoring and con-trolling activities are to ensure systematic devel-opment within finite resources detailed in theplan. Such plans have often failed in practicebecause the weight of the detail removed super-sedes the elements of reality kept in the plan. Thereal world mess is stronger than any plan, andplanning in the mess remains problematical.

Abstract forms fail to recognize social action– critical social and organizational factors. Amajor assumption underpinning E-R, processand class models, and plans, is that human andorganizational behaviour is objective and ratio-nal. Consequently, the abstract forms neglectsocial and political organizational behaviourand culture. In organizations that serve humans,the police or healthcare for example, there is an additional human factor that researchers inlabour have identified – emotion. Object-

oriented systems models have the potential todepict ‘aspects’ and ‘roles’ in organization.

13.4 Further development of theCritical Framework

The original Critical Framework presented inChapter 3 can itself be further developed withcritical questioning of systems ontology. Throughtransformatory critique systems ontology can beimproved to reflect human intention, purpose,mutuality, shared understanding and organiza-tion. Such critique can lead to the developmentof ontological knowledge of systems that inte-grates technology and social action.

The questions concern the value and validityof existing ontological knowledge and know-ledge yet to be acquired. For example, organ-ization theorists describe organizations ashaving a boundary, goals and activities. Systemsontology shares two of these descriptors, bound-ary and purpose (goals). It does not have activ-ities – which is present in SSM as ‘humanactivity system’. Other ontological issues in ISdevelopment include: the value of the SDLCand the structured and object-oriented systemsontology based on it, and the effectiveness ofconcepts, instruments, and models.

Figure 13.1 is an improved critical frameworkreflecting technology and social action perspec-tives. It is populated with paradigmatic criticalreflection. As the bottom layer shows, questionsconcerning systems ontology, real situations andpragmatic resolutions arise. Systems designershave emphasized system integration as a criticalissue, but the focus remains on systemic issues.More important is integrating IS and organiza-tion. This is one research direction taken inDeferred System’s Design (see section 15.6).

Paradigms and paradigmatic knowledge revolutions are significant for improving theCritical Framework. Paradigms of IS develop-ment reflect what knowledge is accepted asvaluable and valid by practitioners. The SDLC,

111

0

11

0111

0

0

11p

255


256


Apply formalmethods


(Messy world)

Information Technology,humans,

social action,political and cultural

factors,reality is systemless,

systems inthe world

Systemsontology

Technology andsocial action

Integrated model ofsystems andorganization,

human intention,purpose,change,

complexity,planning inthe mess

Pragmaticresolution

System and organizationintegration,

reduce the levelof abstraction,develop activesystem models


Develop Critical Knowledge

Paradigms andrevolutions, technical,

socio-technical,human-centred,

system-organization,ontology


and tools

Resolveproblems


How can individuals beincluded in development?Can stories and narratives

provided by people inthe organization be

used?


Is formal systemsmodelling sufficient

for describingand understanding

social action,intention and purpose?One system or multiple

perspectives andsystems?

How can organizationbe representedsystemically?

Is formalism consistentwith social action?

Critical skills

What kind of techniquesand tools are required todescribe social action?

Can techniques and toolsbe adapted to reflect

social action?

Figure 13.1 Improving the critical framework

and IS methodologies based on it, form a paradigm of objectivity and rationalism in ISdevelopment. The objective systems ontologyparadigm can be described as a ‘clean room’,where non-systemic factors are cleaned orremoved. The clean room makes it possible tospeak of a ‘problem domain’, ‘optimum solu-tion’, ‘an agreed system’, ‘logical’ and ‘physicaldesign’, and other such systemic and techno-logical terminology. This paradigm is criticallyquestioned by socio-technical and interpretiveIS development, and recently by ASD.

A fundamental assumption of the SDLC isthat a system, rather than different perspectivesof the system or even different IS, is to be pro-duced. The DBMS conceptual schema enablesvarious perspectives, but the underlying physi-cal system and conceptual schema are notrooted in social action. In the SDLC a systemagreed by all the parties concerned is to be pro-duced. Consequently, systems analysis andsystems design is for one physical system. Suchconceptualization leads to systems ontologiesthat assume a single system. This assumption ismisplaced for certain kinds of IS and fails to account for differences among stakeholdersin organizations. An exception is the Multi-view methodology, which develops multipleperspectives systems ontology.

The single system view prevailed because ofcontemporary technology during the develop-ment of structured systems ontology. Recentobject-oriented technology is capable of thealternative concept of multiple perspectives ona system. Aspect-oriented systems ontology rec-ognizes multiple perspectives. Objects are ver-satile and can be modelled to reflect ‘aspects’and ‘roles’, as well as behave polymorphically.

13.4.1 Organization, organizing andsystems in the world

The value and validity of ontological know-ledge of systems can be improved by developing

knowledge of how to develop IS that reflectorganizing and organization simultaneously.The terms ‘system’ and ‘problem domain’ areabstract forms that do not reflect the presentcontinuous tense that is organizing. Organ-izational theorists think of organizations associal units with goals, boundaries and activity.Some IS researchers argue that organizationsevolve and emerge. Such various explanationsof organization undermine the premise ofplanned action in IS development.

Neither structured nor object-oriented sys-tem ontology recognize emergent organization.Emergent organization is the recognition thatthings can happen in organization whichcannot be accounted for in predeterminedstrategies or plans. For example, a companytakeover is an emergent factor if it is unexpectedor at an operational level realization of a defec-tive product. Just as organizations have torespond to such emergence, systems too needto reflect them. Passive systems models areunable to cater for such emergent change.

An ‘Information System’ needs to fuseorganization, organizing and system. IS devel-opers emphasize the technological system, thehuman and organizational element is generallyperipheral. To improve systems ontology, thedistinctions between technological systems, ISdevelopment and business operations need tobe critically questioned. Thinking of IS devel-opment in terms of systems project managementreinforces such distinctions. Some researchersand practitioners argue that systems ontologywill better reflect organization and organizingwhen the activity of developing IS is conceptu-alized as being an everyday operational issuerather than ‘projectizing’ it. The developmentof active models reduces the distinctions andtends towards this view.

Adaptive and evolutionary IS aim to reflectorganizing, rather than organization. Systemsmodels for adaptive and evolutionary IS aredynamic, they are designed to reflect actual

111

0

11

0111

0

0

11p

257


situations dynamically. Object-oriented systemsontology can cater for such systems through itsdynamic binding of objects and deferred objects.

13.4.2 Human intention, purpose,change and complexity

Specifically, the critical framework can beenhanced to reflect social action, as shown inFigure 13.1. Systems ontology needs to accountfor human intention, purpose, meaning, changeand complexity. Systems analysis and design, aspractised in structured and object-orientedapproaches, does not sufficiently acknowledgesocial action, of which change and complexityhave an inordinate effect on IS development.

The assumption of a static problem domainis erroneous in systems ontology. In businessorganizations uncertainty can arise from theactions of markets and competitors or internalstrategic decisions, which can make the devel-opment of systems models, especially for strate-gic IS, problematical. The effectiveness ofinstruments is compromised by organizationalchange and complexity. Such instrumentsassume stability in real situations.

Similarly, the assumption of a static ISenvironment is erroneous. Uncertainty andcomplexity also arises when intended organiza-tion design is exposed to its environment. Theintended organization design, containingprocesses and structures designed to achievegoals, needs to be responsive to its environment.The system concept acknowledges the environ-ment, demarcated by the system boundary andfeedback. Systems ontology though, whetherstructured or object-oriented, is weak in sug-gesting concepts and actual mechanisms formanaging environmental effects, because itassumes a static systems environment.

Complexity also arises when formalism likeorganization design, systems designs or project

plans designed to achieve human purpose areapplied to actual situations. Applying formalismin practice is difficult because of human andorganizational factors, and the variancebetween what is depicted in the formalism andactual reality. System project plans tend to berevised because the actual situation differs fromthe projected required situation and systemsdesigns fail because they do not reflect businessrequirements.

A prime weakness of structured and object-oriented systems ontology is the lack of under-standing of human intention. They do not seekto develop knowledge of human intention. Thehuman element in IS though, presupposesintention. In strategic IS the intention is todevelop IS that are difficult to imitate by com-petitors, otherwise any competitive advantagegained would be lost. In decision supportsystems the human decision-maker is the sourceof intention, which is usually concerned withdecisions on allocating scarce resources orinvestments. Human intention is critical tosystems analysis and design when humans inter-pret information. Human intention is the mostpronounced and the most difficult to reflect insystems ontology.


13.5.1 Personal constructs forcriticality

Activity A

Table 13.1 is a sample repertory grid for criti-cality. Reproduce the grid on a spreadsheet and add further columns and their polar oppo-sites that you consider relevant. To objectifypersonal constructs in learning, complete thegrid by following the details on how to use arepertory grid in section 1.10.1.

258


Activity B

A PCF enables a person to develop a notion ofself and identity. Its constituents provide a basisfor self-expression and action in real situations.For example, an analyst convinced of the valueand validity of structured systems ontology willdeploy structured instruments believing thatthey will produce the required results. Such ananalyst would probably propound structuredanalysis and design and propose it to developIS. Drawing on the PCF you developed throughthe previous chapters:

• Improve your PCF by questioning the cor-rectness, value, and validity of your personalconstructs. Would you defend your personalsystems ontology? Would you put into prac-tice the methods, techniques and tools youaccept as valid and how would you do soprofessionally?

• What kind of emotion, commitment and pro-fessionalism does your PCF result in for you?

• Does your PCF provide you with a ‘socialidentity’ as an analyst?

• Would you call yourself a ‘structured’ or‘object-oriented’ analyst?

Questions

1 Assess the practical value of the systemconcept for IS development.

2 Discuss whether the activities involved in‘problem-solving’ are capable of accountingfor the human element in IS.

13.5.2 Developing systems ontology

Question

Discuss what you would do to improve struc-tured and object-oriented systems ontology interms of:

• How knowledge of systems is acquired.• How such system knowledge is formalized.

Consider the critical thinking skills enumeratedin section 1.8.1.

111

0

11

0111

0

0

11p

259

Table 13.1 Personal constructs for criticality

Pole 1 Pole 2

Question Fact

Reflect Internalize

Existing thing Alternative thing

Interpret Accept

Analyse Use

Evaluate Do not judge

Explain Ignore

Self-regulate Do not reflect

Tra

nsfo

rmat

ory

crit

ique

Ref

ashi

onin

g of

tra

diti

on

Refl

exiv

e cr

itic

alit

y

Cri

tica

l sk

ills

Soc

ially

co

nstr

ucte

d kn

owle

dge

Neg

ativ

e


13.5.3 Structured systems ontology andsocial action

Activity A

Table 13.2 contains descriptive statements ofstructured systems ontology. Reproduce it in aword processor. Enter your comments in thesecond column on how it can better reflect thesocial action.

From your readings, list other claims made by the advocates of structured systems ontology.Reflect on these claims. Are they valid claims?What does practising structured systems ontol-ogy reveal?

13.5.4 Object-oriented systems ontologyand social action

Activity A

Table 13.3 contains statements descriptive ofobject-oriented systems ontology. Reproduce itin a word processor and enter your commentsin the second column on how it can betterreflect social action.

From your readings list other claims madeby the advocates of object-orientation. Reflecton these claims. Are they valid claims? Whatdoes practising object-oriented systems ontologyreveal?

13.5.5 Analysis of systems ontology andreal human problems

Activity A

Table 13.4 lists many of the critical issues affect-ing structured and object-oriented systemsontology in the first column. The issues aredivided into practical, philosophical and socialaction. The issues concern how the problem ofdeveloping IS is defined. When completed thetable will be a comparison of the SDLC-based structured approach and object-orientationwith the real or messy world. The category ofcriticality is also added to enable you to respondin terms of how you would be critical of systemsontology and the messy world.

• Reproduce the table in a word processor andfill column two with appropriate descriptions

260


Table 13.2 Questioning structured systems

Statement Reflecting social action

A computer system (IS) can be engineered.

A computer-independent design is possible.

Objective knowledge about the problem domain (business area) is possible because things exist independently of humans.

Structured techniques make communication between analysts and users easier.

Data, process and logic modelling techniques can reflect the problem domain.

Entities describe things of interest in the problem domain.

The DFD notation language is sufficient for developing systems models of business processes.

111

0

11

0111

0

0

11p

261

Table 13.3 Questioning object-oriented systems

Statement Reflecting social action

A class is a set of objects with common characteristics in the problem domain.

An object is an abstraction from the problem domain, capable of encapsulating data and operations, processing information and collaborating with other objects.

Generalization is useful for building logical structures to represent similarity or differences between classes.

Objects communicate with each other by sending messages.

Message passing is enhanced by polymorphism.

Table 13.4 Comparative analysis of systems ontology with the messy world

Systems ontology

Structured and object-oriented Messy world of social systems analyses and design action (provide evidence)

PracticalPraxisMethods to achieve aimsThe role of projects in IS developmentKnowledge of the application

domain, characterization of the application domain

Capable of techniques and toolsCommunication between professional

developers and usersUnderstanding of data and informationFormalism, knowledge and theory

PhilosophicalPremises/assumptionOntologyEpistemology

Social actionResultant systemOrganizational politicsOrganizational cultureInformation

CriticalityPAC cyclePersonal Critical FrameworksCritical knowledge and practice

frameworkCritical thinkingCritical skillsReflexivity


of structured and object-oriented analyses inresponse to each item in the first column.

• Use lessons learnt from this textbook, casestudies or experiential knowledge to describethe real or messy world in column three. Youmay also enter a description of your personalconstruct.

• Compare the two columns you filled in termsof knowledge gaps and practice implications.

Question

Comparatively analyse the effectiveness ofstructured and object-oriented systems ontologyfor representing social action in IS.

262



See Cambridge University’s Department of Engineering page for succinct overview of SSM at:http://www-mmd.eng.cam.ac.uk/people/ahr/dstools/control/softsm.htm.


For a special issue dedicated to social computing see: ‘Communication of the ACM’, Social

Computing, 37(1) January 1994.

For systems thinking applied to human activity systems, which accounts for social action see:Checkland, P. B. (1981) Systems Thinking, System Practice, Chichester: Wiley.

14.2 Introduction

Knowledge of how to develop IS or what consti-tutes IS remains incomplete. An examination ofthe intellectual traditions in IS research andpractice reveal systems and ontological assump-tions underpinning them that have led to certainapproaches, some more successful than others.Structured and object-oriented systems ontologycontains assumptions and assertions that do notaccount adequately for actual IS development.This chapter is a deeper theoretical underpin-ning, taking a discursive, critical perspective ofsystems ontology, the SDLC, and systems analy-sis and design. It considers paradigms of systemsanalysis and design, and examines their assump-tions about technology, humans, social action,organizations, data, information and IS.

A critical analysis of the ontological basis ofIS is important for evaluating knowledge andpractice. IS paradigmatic knowledge determinespraxis. Analysts’ ways of thinking and actingdepend on theoretical and practical knowledgereflected in an implicit or explicit paradigm.The relationship between thinking and acting isunderstood through praxis, which is informedby knowledge that is internalized, accepted asvaluable and valid. Praxis assumes relations thatare hidden and assumed, and enacted automat-ically in actual situations. Through reflexivepraxis, based on the critical analysis of systemsontology, analysts can uncover implicit paradig-matic assumptions underpinning their actionsand evaluate their relevance to knowledge andpractice.

111

0

11

0111

0

0

11p

263

Chapter 14

Ways of thinking and acting



• Revisit previous critical perspectives in the context of paradigmatic understanding.• Assess the impact of IS paradigms on ontological knowledge and practice.• Analytically evaluate paradigms of IS development to inform practice.• Critically evaluate how IS paradigms affect praxis or thinking.• Apply transformatory critique to your knowledge and practice based on paradigmatic

knowledge and understanding.

14.3 Criticality throughparadigmatic analysis

An understanding of paradigms in IS is neces-sary for criticality and informing reflexive prac-tice. It is an aid to understanding whatconstitutes progress. Paradigms in particularcharacterize progress as ‘revolutions’ in know-ledge. Progress though can be towards cer-tainty, or even uncertainty. Paradigmaticanalysis can be used to understand the obsta-cles to progress, some of which are internal toa paradigm and others beyond it. Notions ofprogress have complexity as a central theme,where increasing knowledge eradicates the idea that something is simple.

A paradigm is a set of beliefs, assumptions,values and shared knowledge accepted by acommunity of practice. IS developers, includ-ing systems analysts, form such a community ofpractice. The community accept standards andmeasures of validity for knowledge, how it isacquired, evaluated, and applied. The para-digm focus is on what constitutes knowledge,what is legitimate to investigate, and whatmethods of investigation are valid.

Practitioners do not think about paradigmsor act contrary to an accepted explicit orimplicit paradigm. For them a paradigm is ‘rea-son in practice’. There are exemplary forms ofreasoning present in different systems analysisand design approaches and practice. Know-ledge and understanding gained from a partic-ular paradigm is accepted as valuable and valid,and held by an analyst to be correct. It is thisbelief in the correctness of knowledge, or certainways of reasoning and acting, that determineshow a particular IS development problem isthought through and what action is taken toresolve it. Alternative conceptualization of theproblem and its resolution is resisted because itis not part of the accepted paradigm.

Uncritical acceptance of knowledge and rotepractice stems from a lack of awareness of a

paradigm of knowledge and practice and a lackof awareness of alternative paradigms. Know-ledge and practice can be improved when ananalyst becomes conscious of an accepted para-digm and begins to question it in the context ofavailable alternatives. Paradigms can be utilizedto improve reflexivity and, through personalconstructs, can be validated empirically.

The value of paradigmatic analysis is inunderstanding how knowledge is acquired andaccepted as valid. It enables questioning of reason in practice or criticality and uncoversassumptions of knowledge. Paradigmatic analy-sis uncovers how knowledge is acquired. Suchknowledge is important for understandingepistemological knowledge – methods used toacquire and validate knowledge. It uncoversassumptions made of the physical and socialworld, which is relevant in developing ontolog-ical knowledge of systems. Significantly, para-digmatic analysis is valuable because it revealsthe knowledge base that informs and determineshow analysts act.

14.4 Paradigms of IS development

The discussion on paradigms of IS develop-ment is based on Hirschheim and Newman’s(1989) work, which draws on social theory toaccount for knowledge and practice in IS devel-opment. They describe four paradigms of ISdevelopment and cite exemplars.

Functionalism The systems analyst is des-ignated an ‘expert’ developer. IS developmentis conducted from without with accepted for-malism and ‘planned intervention’ using ‘ratio-nalistic’ tools and methods. People, hardware,software, organizational rules and objectiveentities constitute elements in defining IS.Structured systems analysis and design andInformation Engineering are classified in thefunctionalist paradigm. They assume know-ledge is objective and that the social world is

264


ordered. This is also true of object-orientation,though it is underpinned with classifica-tion theory, which assumes people order theirexperiences of the world.

Social relativism The systems analyst isdesignated a ‘catalyst or facilitator’. IS devel-opment is conducted to improve subjective andcultural understanding within the applicationarea. Evolutionary social change is recognizedin the IS development process. Subjectivemeanings, symbolic structures and metaphorsconstitute elements in defining IS. Exemplarsare enthnographic approaches and the FLO-RENCE project. Social relativist IS develop-ment assumes that knowledge is subjective andcan be ordered.

Radical structuralism The systemsanalyst is designated a ‘warrior’ for socialprogress and is partisan. IS development is con-ducted politically from without using ideologyto affect conscience and develop consciousness.The tools and methods are adapted to suit dif-ferent class interests. The same elements usedto define IS in the functionalist paradigm areused but objective entities are interpreted polit-ically to serve economic class interests. TradeUnion led approaches, UTOPIA and DEMOSprojects are exemplars. Radical structuralist IS development assumes that knowledge isobjective but is embedded in social conflict.

Neohumanism The systems analyst is des-ignated ‘emancipator’ or ‘social therapist’. ISdevelopment is conducted from within toimprove human understanding and bring to thesurface rationality underpinning human action.Its purpose is to emancipate suppressed inter-ests and to liberate people from natural andsocial constraints. The same elements used todefine IS in the functionalist paradigm are used,but objective entities are interpreted to develop‘technical knowledge interests’ to enable controlover nature and social situations. Language andits intersubjectivity is pertinent in defining IS.

Exemplars are critical social theory basedapproaches, SAMPO project. NeohumanisticIS development assumes that knowledge is subjective and stems from social conflict.

The focus of structured and object-orientedsystems ontology is on objective modelling.They operate with the premises of rational or economic human behaviour and do notaccount for social action. They focus not onindividuals and groups but technologicalsystems. So they can be classified as the func-tionalist paradigm.

Explanations of IS range from nomolog-ical to behavioural, to pattern-based. Object-oriented systems analysis and design is anexample of the latter. Another category of probabilistic-statistical is evident, where ISresearchers try to explain IS in terms of statis-tical probabilities. Probabilistic-statistical expla-nations, contrary to their proponents’ views, donot establish causal relationships characteristicof nomological explanations.

14.5 Paradigms, thinking andacting

Action is concerned with making a differenceto a situation for the benefit of the individual or others. Humans act in order to achievedesired aims. Analysts’ action is concerned withimproving organization performance throughsystems, and ultimately with applying theirexpertise to help an organization achieve itsaims. Their work makes a difference, oftensignificant, to the working lives of people.Crucially, it has an impact on the effectivenessand success of organizations.

It is possible to show how the assumptionsunderpinning a particular paradigm affect theactions of its adherents. Analysts educated andtrained in structured systems analysis and designunwittingly subscribe to the functionalist para-digm. Structured systems analysis and design

111

0

11

0111

0

0

11p

265

................................................................................................Chapter 14 Ways of thinking and acting

leads to prescribed action. A tenant of thefunctionalist paradigm is that an expert is bestplaced to make systems design decisions. Instructured systems ontology the IS developer –including the systems analyst – is the expert whomakes design decisions. This assumption domi-nates requirements analysis, systems modelling,and systems design, and certainly implementa-tion. The analyst usually makes policy decisionsthat affect processes and structures in organ-izations. The role of the expert analyst causesmisunderstandings and difficulties betweendevelopers and users. Analysts who identify withthe functionalist paradigm need to analyse whatcan be done to reduce friction.

Another tenant of the functionalist paradigmis objectivity of knowledge. This requiressystems analysts to be apolitical. Apoliticalbehaviour leads to neglecting the real politicalissues pertinent in IS projects, requirementsanalysis, modelling and systems design. Thefocus on data in structured systems analysisresults in systems designs that lack stakeholderchampions. In data-centric approaches an IS isregarded as a product of the data captured,stored and processed with computer algorithms.Its proponents claim it has better design stabil-ity and low data redundancy because rigorousmathematically based formalism is appliedobjectively.

In process-centric approaches an IS isregarded as a product of the processes it needsto support with the danger of limited design stability and propagation of data redundancy.

Action in object-oriented systems ontology isopen to interpretation, rather than prescribedas in structured systems ontology. Object-oriented systems analysis and design leads tointerpreted action. The UML is not a methodor methodology, as such it does not prescribeanalysts’ action. UML diagrams are deliberatelydesigned to be interpretable in context. Forexample, the basic features of an object used in

most systems models are name, attribute andoperations. An object can have any other features deemed appropriate for a problemdomain. This is possible in object-orientedsystems because of meta-models, which definenotation.

14.6 Primacy of method

Conceptions of IS development and method-ologies in the functionalist paradigm logically result in the primacy of method and instru-ments, usually underpinned with formalisminformed or derived from predicate calculus.Methods for acquiring knowledge of systems,methods for determining system requirements,methods for analysis and design, and imple-mentation are all developed because of the beliefin the value and validity of objective knowledgeand a reality separate and independent of ISdevelopers. The methodical perspective seeks todefine precisely activities involved in developingIS and to ensure compliance to those activities– standards.

The SDLC is an exemplar of the methodi-cal approach. The development process isdemarcated into distinct phases, with eachphase containing multiple activities. The out-comes of each phase and activity are the ‘deliverable’ that forms both an input intoanother activity and the simultaneous definitionof the resultant IS. Structured and object-oriented systems ontology emphasize this kind of methodical IS development.

The primacy of method is further enforcedas projects that control costs. The cost of devel-oping a system can be detailed in a systemsproject plan with distinct activities or workpackages stipulating human and financialresource requirements. An exemplar in softwaredevelopment is CMM, with its emphasis onplanned and repeatable systems developmentactivities. Practitioners, and some researchers,

266


have lately questioned the primacy of methodboth in IS development and projects.

14.7 Stories and narratives

Conceptions of IS development and method-ologies in social relative, radical structuralismand neohumanism paradigms lead to ‘sense-making’, meaning, stories and narratives, where method and process is secondary. Socialrelativism and neohumanism assert that realitydoes not exist separately from people, so ISdevelopment proceeds by ‘sense-making’ andsharing meanings among different groups. Inradical structuralism class conflict and partisanbehaviour are characteristic of the analyst.

ASD and XP make use of techniques to gen-erate stories from people about their experi-ences. The stories are written by ‘customers’and used to define the scope of a system project.The important difference from structured orobject-oriented systems ontology is that systemrequirements are sourced directly from theexperiences of people in the problem domainthrough their stories, written on a StoryCard.These StoryCards are kept throughout thedevelopment to keep the team focused on thecustomer’s requirements.

Interpretive research in IS also draws onsocial theory to develop understanding andknowledge of the application of IT and devel-opment of IS. Interpretive researchers build onthe ‘subjective construction’ of reality, sense-making, and meaning. Though the concept ofinterpretation is accepted in the IS researchcommunity, as yet there are few practicalinstruments available. An earlier examplethough is NIMSAD (Normative InformationModel-Based Systems Analysis and Design). Itis an evaluation framework for methodologiesbased on the social relative paradigm. It is usedto evaluate problem-solving in IS.

14.8 Paradigmatic criticalframeworks

The role of a Critical Framework is central infurther developing knowledge and practice.Criticality among researchers and practitionersleads to progress in knowledge. Similarly, aPCF that is static will become obsolete. Itshould be revised, amended and improved overtime as new knowledge and advances in systemsanalysis and design are made, and as personalunderstanding of systems ontology improves.

Figure 14.1 is the Critical Framework pop-ulated with paradigmatic critical reflection. Asthe bottom layer shows, many questions con-cerning how knowledge is acquired, acceptedand practised arise from entities presupposed toexist in reality.

Questions on when an assumption or ele-ment of a PCF should be introduced, amendedor shed can be addressed through paradigmaticanalysis. Paradigmatic critical frame-works can be of two types. A critical focus on what constitutes knowledge and how it isacquired within a paradigm is one type. Someresearchers and practitioners work within a par-adigm to improve knowledge and practice. Forexample, within the functionalist paradigmwhen an existing method or methodology isfound to be ineffective an alternative is devised.For instance, Information Engineering (IE) was designed to fill gaps in structured systemsanalysis and design.

A critical focus on what constitutes know-ledge and how to acquire it across paradigms isthe other type. Some researchers and practi-tioners work across paradigms. When the limitof a particular paradigm is reached an alterna-tive paradigm is explored, either to cross-fertilize or to step over into the alternative. Forinstance, Multiview is an example of cross-fertilization, as it is rooted in the functionalistparadigm but makes use of social relativism. It

111

0

11

0111

0

0

11p

267


seeks to cross-fertilize functionalist thinking inSTRADIS and IE with social relativist ideasfound in SSM and ETHICS.

Criticality within and across paradigms wascovered in Parts II, III and IV of this book. The

purpose of the critical framework presented inChapter 3, and revised in Chapter 12, was to afford within and across paradigmatic criti-cality. It is possible to map Barnett’s (1997)types of criticality to reflect within and across

268


Apply formalmethods


(Messy world)

Holism and continuityof social action,organization and

system interaction,temporality of events

Systemsontology

Paradigms

What constitutessystem

knowledge?How is knowledge

acquired?

Pragmaticresolution

???



Resolveproblems


Is it possible to utilizecross-paradigmatic

knowledge for practice?What critical thinking can

be applied within aparadigm to improve

practice?


Are there competingparadigms of system

knowledge?What criteria areneeded to select

a paradigm?Is the ontology of aparticular paradigm

appropriate?Can cross-paradigmatic

critique be applied toimprove a paradigm?

Critical skills

What assumptions haveI made?

Is it possible to borrowinstruments from otherparadigms to solve apractical problem?

Figure 14.1 Paradigmatic critical framework

paradigm criticality, as shown in Figure 14.2.The figure shows what types of criticality canbe used within a paradigm and what typesacross paradigms.

Elements of critical thinking discussed inSection 1.8.1 apply to both within and acrossparadigms. Interpretation, analysis, evaluation,inference, explanation and self-regulation areneeded to be critical of a paradigm and forthinking beyond a particular paradigm. Self-regulation is particularly pertinent for cross paradigmatic analysis because it enables ‘ques-tioning, confirming, validating or correctingeither one’s reasoning or one’s results’.


Knowledge that is not reflected upon and prac-tice that is not questioned becomes rote. Theformation of personal constructs should bebased on paradigmatic critical analysis. Personalconstructs contain assumption of reality madeby the owner. They need to be uncovered byunderstanding paradigms of practice.

14.9.1 Personal constructs for praxis

Table 14.1 is a sample repertory grid for praxis.Reproduce the grid on a spreadsheet and addfurther columns and their polar opposites thatyou consider relevant. To objectify personalconstructs in praxis, complete the grid byfollowing the details on how to use a repertorygrid in section 1.10.1.

14.9.2 Defining the problem of ISdevelopment

Activity A

Consider the four paradigms in section 14.4.Form into two groups, based on your readings,each group is to:

• Explore the functionalist basis of structuredand object-oriented systems ontology fordefining the problem of developing IS. Whatfunctionalist paradigm ideas do they use todefine IS and determine the IS developmentprocess?

111

0

11

0111

0

0

11p

269

Crit

ical

thi

nkin

g

Across paradigmWithin paradigm


Critical skills


Refashioning of traditionsReflexive criticality

Figure 14.2 Critical thinking and paradigms


• Evaluate the appropriateness of the solutionsproffered by each of the ontology.

• Appoint a raconteur in each group to relatethe discussion to the plenary.

• Groups to come together in plenary andexplain and discuss their respective views.

• Appoint a scribe to note groups’ commentson flip charts or white boards.

This activity should result in a rich discussionof individuals’ knowledge and the variance in itbetween individuals. This variance is importantbecause it allows individuals then to questiontheir personal knowledge relative to others.

Activity B

Making Your Paradigm Explicit practitioners oftenact on the basis of routine behaviour andimplicit assumptions. When asked to explaintheir behaviour they find it difficult to objectifythe knowledge they use to underpin theiractions. The PCF is a device to objectify the par-adigm or framework you use to develop prac-tice knowledge. Reflect on your own behaviourin relation to an interest or work experience.Identify and list the assumptions you made on:

• people;• your interest or work area;

• the instruments you used;• your expected results.

14.9.3 Thinking and acting thestructured way

Activity A

Hirschheim and Newman’s (1991) paper criti-cally appraises structured IS development.

• Source the paper and read it. (Full referenceis given in section 14.9.6.)

• The chapters on requirements analysis andprocess and logic modelling should be revis-ited after reading the paper.

• Take the authors’ arguments and applythem to the structured techniques stipu-lated for requirements determination, data,process and logic modelling.

• Analytically evaluate the flaws you detect inthe structured methods, techniques andtools.

• Discuss how representative structuredsystems models are of real situations. (Youmay want to re-read Chapter 12 on non-systemic factors.)

270


Table 14.1 Personal constructs for praxis

Pole 1 Pole 2

Fact Belief

Value-free Value

Experience Supposition

Objective Constructive

Assert Persuade

Expert People

Act

Thi

nk

Dec

ide

Con

cept

Fra

mew

ork

Val

id

Acq

uire

kn

owle

dge

Acc

ept

know

ledg

e

Que

stio

n kn

owle

dge

Par

adig

m

Questions

1 The role of the analyst as ‘expert’ causes mis-understandings and difficulties betweendevelopers and users. What can be donepragmatically to improve this situation?

2 Discuss whether an organization is an inde-pendent, objective fact and whether it can bemodelled as such.

3 Critically evaluate the relative contributionsof structured and object-oriented systemsontology to resolving the problem of ISdevelopment.

14.9.4 Thinking and acting in object-orientation

Activity A

Object-oriented systems ontology is based onclassification theory (see section 10.2). It assertsthat people use cognitive processes to organizethinking of their experiences. The three methodsused to organize thinking are:

• Differentiation of experience in terms ofobjects and their characteristics.

• Making distinctions between whole objectsand components parts.

• Formation of classes or groups of objects anddistinction between classes.

Recount some of your experiences and applythe above to them to determine objects, attrib-utes, wholes, parts and classes. What differencedoes it make to your knowledge to becomeaware of your cognitive processes?

Question

1 Critically evaluate the contribution of object-oriented analysis to resolving the problem ofIS development.

2 Critically assess whether the class model canbe a sufficient representation of real humanproblems.

111

0

11

0111

0

0

11p

271


For a philosophical basis of paradigmatic knowledge and the original ideas of Thomas Kuhn seethe essay by Pajares, F. at: http://www.emory.edu/EDUCATION/mfp/kuhnsyn.html.


For a complete discussion of the four paradigms of IS development see: Hirschheim, R. and Klein,H. (1989) ‘Four Paradigms of Information Systems Development’, Communications of the ACM, 32(10):1199–1215.

For an elaborate critical discussion of assumptions underpinning IS development based on thefunctionalist paradigm see: Hirschheim, R. and Newman, M. (1991) ‘Symbolism and InformationSystems Development: Myth, Metaphor and Magic’, Information Systems Research, 2(1): 29–62.

Hirschheim, R. and Newman, K. (1989) ‘Four Paradigms of Information System Development’,Communications of the ACM, 32(10): 1199–1215.

Estes, W. K. (1997) Classification and Cognition, Oxford Psychology Series, Oxford: Oxford UniversityPress.


Part VI examines emerging systems ontology knowledge and practice. It takes a future-ori-ented stance on systems ontology and systems analysis and design. The future perspective isimportant for two reasons. First, the act of developing an IS is itself future-oriented. It is acreative act. Most new IS are creations of new business processes or order in organizations.This is significant because new processes and order contribute to business performance andachievement of goals. The global classic example of new order is the web.

Second, the future of IS is important because of its impact on organizations and societyduring the 1990s. The acceptance of IS in organizations necessitates appropriate conceptual-ization of further developments in IT and IS. Unlike other technologies, for example analogue,the progress of digital technology and its application to develop IS shows no signs of slowing.

Chapter 15 is on new and emerging systems ontology and different perspectives on systemsanalysis and design arising from new software programming strategies and system concepts.These developments will determine future ontological knowledge of systems. Some perspectivesare emerging and others are established but are not the dominant form of practice. In termsof criticality, Chapter 15 covers transformatory critique. It focuses on making systems analysisand design inclusive. A more complete systems ontology needs to take account of system onto-logical knowledge that is marginal but which may be valuable in certain situations, or newapproaches that provide paradigmatic shifts, and reveal new features of systems ontology.

111

0

11

0111

0

0

11p

273

Part VI

The future of IS development

15.2 Introduction

This chapter will consider emerging and mar-ginal approaches to systems analysis and design.It covers methods that are marginal but whichmay be valuable in certain situations or newapproaches that provide paradigmatic shifts.These approaches provide an alternative con-ception that could benefit the IS developmentprocess and improve conceptions of IS. Forexample, emerging approaches like ASD andadaptive and evolutionary systems introducenew elements into systems ontology that requiredifferent systems analysis and design.

The future of systems analysis and design islikely to be non-SDLC, as emerging concep-tions of IS development reveal. The web itself,rather than applications for it, is an example.The internet is another example. These typesof systems and hardware enable radically dif-

ferent conceptions of IS, as evident in theeCommerce and web revolutions.

The fundamental challenging question foranalysts is: Who is an appropriate analyst? Forexamples, individuals determine the web IS asa whole rather than a team of designers. Itsanalysis and design is not undertaken, as wecurrently understand the practice, in structuredand object-oriented systems ontology.

15.3 Alternative and emergingthinking

The alternatives and emerging thinking can be conceptualized and analysed in terms ofamethodological IS development, situated actionand evolutionary development. An appropriateconception is amethodogical IS development.An amethodological orientation consists ofdoing development activities that are pertinent

111

0

11

0111

0

0

11p

275

Chapter 15

Making systems analysis and design inclusive



• Make the Critical Framework and PCF inclusive of emerging and marginal systems ontology knowledge and practice.

• Evaluate the usefulness of emerging and marginal systems analysis and design.• Apply reflexive criticality and transformatory critique to systems ontology.

in context. So, analysing system requirementscan be done at any time or design decisions can be taken before requirements analysis iscomplete. This is in contrast to the plannedaction of the SDLC and systems project man-agement. A prime characteristic of the alterna-tives is the re-conceptualization of thinking and acting on IS development. Much of the re-conceptualization has resemblances toSuchman’s (1994) work on interface design. She uses a navigation analogy contrasting thewestern and ‘Truckese’ navigator to distinguishbetween planning and then acting – plannedaction – and setting an objective and acting toachieve it – situated action. She states:

[T]he European navigator begins with a plan – acourse – which he has charted according to certainuniversal principles, and he carries out his voyage byrelating his every move to that plan. His effortthroughout his voyage is directed to remaining ‘on course’. If unexpected events occur, he must first alter the plan, then respond accordingly. The Truckese navigator begins with an objectiverather than a plan. He sets off toward the objec-tive and responds to conditions as they arise in anad hoc fashion. He utilises information provided by the wind, the waves, the tide and current, thefauna, the stars, the clouds, the sound of water on the side of the boat, and he steers accordingly.His effort is directed to doing whatever is necessaryto reach the objective. If asked, he can point to hisobjective at any moment, but he cannot describe his course.

(Preface)

Thinking and action in terms of situatedaction is a distinguishing feature of amethod-ological approaches that have jettisoned theSDLC, and in some cases, the functionalist par-adigm. The ‘plan’ of distinct systems analysis,design and implementation phases of the SDLCare merged and done continuously rather than

at discrete times. Examples of amethodologicalapproaches are Prototyping, RAD, JAD andASD. Those covered here in terms of futuredevelopments are component-based develop-ment, ASD and deferred system’s development.

15.4 Component-baseddevelopment

Rather than compress the phases of the SDLC,Component-Based Development (CBD) radi-cally eliminates it and the need for traditionalsystems project management. CBD is the ideathat software developers will write componentsfor functions, which will develop into a libraryof component software traded in a market. ISdevelopers can then buy the appropriate com-ponents and put them together to develop arequired system. CBD can be classified in thefunctionalist paradigm.

The SDLC is eliminated. CBD also reducesthe boundary between IS development assystem projects and the actual operations of theorganization. Since components can be pur-chased and ‘plugged’ together it is not neces-sary to temporally separate IS developmentfrom the actual operations of an organization.In this view, IS development can become abusiness operational issue rather than a specialsystem project. The required componentmarket though for CBD to be industrially viablehas yet to materialize. CBD is practiced onlywithin organizations that have developed theirown library of components.

Systems analysis and design in the context ofCBD would still involve requirements analysisto determine what the proposed system isrequired to do. The systems analysis and designactivities would be at high level to integratesystem components. There would be a need fora class model, consisting of packages diagrams,and other UML diagrams to determine overallsystem behaviour. Additional analysis and

276

Part VI The future of IS development..................................................................................................

design steps would be needed to configure thecomponents into the required functionality.

15.5 Agile software development

The agile systems ontology is radically different.Activities for systems analysis, design, imple-mentation and systems project management arestill required in it, but they are not sequentialor prescribed stringently. ASD is concernedwith giving primacy to individuals, collabora-tion and working software. It can probably bethought of as being social relativist paradigm.

The significant change compared to struc-tured and object-oriented systems ontology is toview people as collaborators in IS development.This is in contrast to acting on a contractualbasis with clients. Important stakeholders areidentified and, with business analysts, includedin the IS development team. The stakeholdersset the priority list of what functions to develop.

Analysis, design and implementation areconcurrent in ASD. Systems analysis is not aninitial discrete step. So analysis is done itera-tively as required and in small packages of work.Systems analysis and systems design are inter-twined and depend on each other, each beingdone when required. The outcomes of systemsanalysis do not have a direct relation withsystems design or implementation. The analysisdoes not have to map directly onto software.Implementation decisions are used to informsystems analysis.

A radical change in ASD is that process andmethods are secondary to individuals’ needs.Systems analysis and systems design activitiesare not done through stipulated and prescribedprocesses and methods – instruments are sec-ondary and devised as required. Importance isgiven to individuals rather than the efficientdeployment of methods.

System project management is radically dif-ferent too. The software development tasks are

broken down into small tasks. The tasks aredefined so that each one can be completed ina month or less. The priority for determiningwhich task is developed is set by stakeholdersand business analysts, rather than the projectmanager. This aspect of ASD can be regardedas making IS development into an operationalmatter. Analysis, design and implementationactivities are repeated monthly for each taskundertaken.

15.6 Deferred system’s design

Deferred system’s design (DSD) is still in theresearch and theoretical stages, with someactual application of the concept in commerce.It is a theme of research in a UK university andacknowledged in practice by systems analystsand project managers in UK local government.

Figure 15.1 is the Deferred-Specified IT/ISmatrix (Patel, 2003) adapted here in terms ofsystems analysis and design. The matrix is asynthesis of technological factors and socialaction. It depicts four systems ontologies in eachof the four quadrants, based on a four-dimen-sional analysis of technology and social action.The four dimensions are planning or rational-ism, emergence, deferred design decisions anddiffused management. When correlated thesefour dimensions result in four types of systemsontology: deferred systems, real systems,autonomous systems and specified systems. Thecorrelations can be interpreted for organ-izations too, as shown in the figure. The matrixthus matches semantically theoretical systemsontology and organization ontology for fourtypes of systems and organization.

The basic theoretical proposition of DSD isthat systems ontology needs to be a synthesis ofplanned action, emergent technical and socialfactors, and deferred action. The top left quadrant of the matrix depicts real situations where planning potential and capability is low,

111

0

11

0111

0

0

11p

277

......................................................................Chapter 15 Making systems analysis and design inclusive

emergent factors high, and therefore the needfor deferred action is high. In such situationssystems design needs to be deferred to peoplewho make use of the system in context. Theweb is an example of a deferred system. This isto be contrasted with Specified System’s (SSD)shown in the bottom right quadrant. It depictsreal situations where planning potential andcapability is high, emergent factors low, andtherefore little need for deferred action.Problem domains in structured and object-oriented ontology are assumed to be of thistype. (For details of the other two types ofsystems ontology and detailed explanation ofthe dimensions see Patel, 2003).

The deferred systems ontology in the matrixis based on an interpretation of social action asbeing simultaneously planned and emergent.Even the act of planning contains emergence(see section 15.8.5; Harris and Patel (2001)).This is in contrast to systems ontology thatassume plans only or emergency only. Recog-nizing the possibility of planned or rationalaction and emergent or deferred action inhuman activity affords the four types of systemsontology and organization ontology to be cor-related. Systems ontology above the grey linerecognize a fluid boundary, so they are termedopen systems. Those below the line have a rigidboundary, hence they are termed closed systems.

278


Low

High

High

Low

Specified systems

Specified organization

Deferred systems

Deferred organization

Formalism

(Strategy, planning, process)

High

Low

Deferred

action

(Deferred

design d

ecisions)

Open systemsE

mer

gen

ce

Taci

t, s

ocia

lizat

ion,

lack

of c

omp

lete

ness

Diffused management

Closed systems

LowHigh

Real systems

Real organization

Autonomoussystems

Autonomous organization

Figure 15.1 Deferred systems and organization

Source: Adapted from Patel, N. V. ‘The Logic of Deferring the Design Process’, in Patel, N. V. (ed.) AdaptiveEvolutionary Information Systems, Hershey, PA: Idea Group Publishing.

The deferred systems ontology has beenapplied to develop banking systems and inter-pret systems analysis and design for web appli-cations in British local government. In banking,a system was developed that enabled clerks tochange system functionality using the deferreddesign decision principle (right dimension).Clerks were given software tools to changesystem functions when required. This is signifi-cant for systems analysis because it removessystems design decisions from analysts andplaces them in the hands of people in the actualhuman context. People in the actual contextwho make systems design decisions are calledaction developers in the deferred systems ontol-ogy. Practising systems analysts interpret theirbrand of systems analysis deployed in the UKlocal government LEAP project as deferredsystems ontology. They have developed systemsanalysis techniques that place systems designdecisions in the hands of action developers.

15.7 An inclusive CriticalFramework

The functionalist paradigm assumes organiza-tion to be an objective fact, but this ignores thesocial action that is an organization. The func-tionalist formulation of the IS developmentproblem surgically removes sociological andpolitical aspects of organization and organizinghuman behaviour. It claims that objective,optimal and efficient instruments can be devi-sed, and economically used, to solve optimallythe objective formulation of the IS developmentproblem.

An inclusive Critical Framework meansunderstanding IT, social action and the appli-cation of IT to organization to develop IS. Itrequires an interdisciplinary approach thatincludes social theory and technology, and IS –in terms of the knowledge of how to apply IT.An organization is a social unit with goals, a

boundary and activity. As such, people withinit attach meanings to their actions, struggle forpower and resources, and develop cultures,norms and values.

Social theory can be used to enhance theCritical Framework and to re-conceptualizesystems analysis and design. The functionalistIS paradigm provides an initial but incompleteunderstanding of IS. Its premise of acting onlyon perfect knowledge is questionable. Even if it were possible, it would still not account forphenomenological aspects of organization andinformation.

In functionalist systems ontology analysts arerequired to capture facts objectively. Theelusive trinity of unambiguous, complete andnon-redundant data in structured systemsontology is achievable for some practitioners.They argue that the rational basis of structuredsystems ontology provides an initial under-standing that could be used to move ontohigher levels of understanding. The revisedinclusive Critical Framework in Figure 15.2depicts that the real world of human problemscontains non-systemic factors that lead to theopposite premise. There are no objective factsthat can be captured, only phenomenologicalinterpretations by humans of social action,including data, information and knowledge.

System project management itself is similarlyinterpretive. It does not have a unified valuesystem in practice. Project managers’ prioritiesfor effective, efficient and successful projectmanagement are different from stakeholdersneed to retain a stake in the development.Analysts’ concern with users is not shared bysoftware programmers’ need to write technicallyefficient and elegant software algorithms. Not only is the value system not unified it is highlyuncertain too. IS projects in practice have shifting objectives, resources and timescales.

Analysts need to develop appropriate sys-temic and social action personal constructs. An

111

0

11

0111

0

0

11p

279


280


Apply formalmethods


(Messy world)

Human behaviour isintentional and motivated

by personal and groupinterests

Conflict,political aspects,human hunches,

sociological aspects,bounded rationality,power relationships,

interpretationof situations,

imperfectcommunication,

hoarding informationand knowledge

Systemsontology

Inclusive

Social action,technology,

socio-technicalsystems,

agile systems,deferred systems,

reflective andaction developers,IS development as

business operations

Pragmaticresolution

???


Agile developmentDevelop knowledge


Resolveproblems


Does systems designneed to be separated

from organization design?Can IS development bemade part of business

operations?


Is social theoryapplicable to systemsontology and design?

Can phenomenologicalmeaning be systemically

represented?Can individuals be givenresponsibility for system

analysis and designdecisions?

Critical skills

Figure 15.2 Critical Framework: inclusive systems analysis and design

effective PCF is one that is inclusive and pro-gressive. Its continual development should bebased on critical systems ontology.


15.8.1 Personal constructs for future-orientation

Table 15.1 is a sample repertory grid for afuture-oriented view. Reproduce the grid on a spreadsheet and add further columns andtheir polar opposites that you consider relevant.To objectify personal constructs, complete thegrid by following the details on how to use arepertory grid in section 1.10.1.

15.8.2 Interpretive IS

Questions

1 Evaluate the potential contribution of socialtheory in the conceptualization, definitionand development of IS.

2 Critically discuss how stories and narrativesprovided by people can be used to determinesystem requirements.

15.8.3 Component-based ISdevelopment

Activity A

The promise of CBD is not realized. Examinethe role of systems analysis in CBD:

• Search the internet to identify CBD com-mercial and interest sites.

• Deduce the proposed role of systems analysis.• Is there a viable market for components?

15.8.4 Deferred systems ontology

Activity A

Identify an existing IS and examine:

• Its planned basis – what is it expected to do?• Emergence in its context that was not in the

original plan and which needs to be part ofits functionality.

• With reference to the second bullet point,what kinds of design decisions can bedeferred to people in the context?

111

0

11

0111

0

0

11p

281

Table 15.1 Personal constructs for future-orientation

Pole 1 Anticipate Experience IT IS Organic Plan Pole 2

Unpredictable Predict

Social Technological

Interpretive Objective

Revise Freeze

Pre-design Defer design

Story Fact

Critical Accept


282



For an example implementation of deferred classes see http://docs.eiffel.com/general/guided_tour/language/invitation-13.html.

See www.agilealliance.org and www.agilemanifesto.org/history.html for ASD perspective andphilosophy.

‘Only that programming is vital which finds its own elements in the people who use it.’ Forcomputer programmers working on the boundary of the future of computer programming seehttp://www.sgi.com/grafica/future/.


For chapters on deferred system’s design see: Patel, N. V. (ed.) (2003) Adaptive Evolutionary Information

Systems, Hershey, PA: Idea Publishing.

Harris, H. J. and Patel, N. V. (2001) ‘A Narrative Analysis of Information System Developmentin a Local Government Organization: Conversations Reflecting Deferred System’s Design’, ACMConference on Object-Oriented Programming, Systems, Languages, and Application, TampaBay, Florida.

Patel, N. V. (2004) ‘Deferred Systems: Deferring the Design Process and Systems’, Journal of Applied

System Studies, 5(1).

For a comprehensive view of CBS see: Szyperski, C. (1999) Component Software: Beyond Object-Oriented

Programming (1st edn), Perth, Scotland: Pearson Education.

For an application of DSD see: Stamoulis, D., Theotokis, D., Martakos, D. and Gyftodimos, G.(2003) ‘Ateleological Development of Design-Decisions-Independent Information Systems’, inPatel, N. V. (ed.) Adaptive Evolutionary Information Systems, Hershey, PA: Idea Group Publishing.

Algorithm A computer program algorithm is the sequence in which a computer is instructedto execute program code. Process logic models in structured systems ontology and operationsin objects in object-oriented systems ontology are used by systems designers to develop programalgorithms.

Application domain A term used in systems analysis to describe an organization or its parts forwhich a new IS is to be developed.

ASD Agile Software Development is a radically different perspective on software development.It is concerned with individuals and processes over processes and tools, working software overcomprehensive software, customer collaboration over contract negotiation, responding to change over following a plan. Its systems analysis and systems design activities are non-prescriptive, non-linear, and agile

BPR Business Process Re-engineering is the recognition of business activities in terms of criti-cal processes and their transformation to deliver improved operational efficiency and effec-tiveness. BPR is normally associated with the application of IT to achieve such performanceimprovements.

Business case A rationale for deciding to proceed with the development of a particular IS.Business model A set of business ideas related to achieve predetermined objectives, usually

in terms of profits, customer satisfaction, reduced costs, product or service differentiation, orother business measure.

CASE Computer-Aided Software Engineering are computerized tools to support thedevelopment of systems models during systems analysis and systems design. The advantages of using CASE tools are speed, accuracy and consistency in the development of systems models.

Client A person, group, department or organization for which an IS is to be developed.CMM Capability Maturity Model is a standard for developing high-quality software. The CMM

standard is set by Software Engineering Institute at the Carnegie Mellon University, who devel-oped it for the US Department of Defense to enable them to evaluate an organization’s abilityto produce software under contract.

Critical Framework The Critical Framework for Knowledge and Practice development is anintellectual tool for gathering, interpreting, analysing, evaluating and critiquing ontological

111

0

11

0111

0

0

11p

283

Glossary

knowledge of systems and its practical application. It serves to enable the development ofpersonal constructs for a PCF.

Critical systems ontology Critical systems ontology is the interpretation, analysis, evalua-tion, inference, explanation, questioning and critical study of system. It is the notion that currentontological knowledge of systems can be improved, and that it can be ‘other than it is’ to bepractically effective.

Critical thinking Critical thinking is a set of cognitive process required to develop criticalthinkers capable of self-regulation.

Criticality Barnett (1997) defines criticality as: ‘a human disposition of engagement where itis recognised that the object of attention could be other than it is’.

Data Data are elements of transactions or transactions arising from organized activity. In com-puting terms data are items inputted into a computer system and processed by it to produceother data or information.

Deliverable A diagram or document resulting from a method or phase of a methodology orthe SDLC. It is a concrete thing that can be used to define or develop an IS.

Engineering metaphor The engineering metaphor is used in software development. It is usedto define efficient and effective processes for developing software.

Epistemology Epistemology is theory of knowledge and how it is acquired. Usually it refersto the method by which knowledge is acquired. The epistemological methods can be objectiveor interpretive.

Estimation models An estimation model is used to plan the resources required in a systemproject. An estimation model provides rigour and exactness based on statistical analysis. Anexample is Function Point Analysis.

e-Tailing Online retailing is called e-Tailing.ETHICS The Ethical and Technical Implementation of Computer Systems. ETHICS is a

socio-technical methodology. It is the seminal methodology to consider the social factor in IS development.

Ethics Ethics is concerned with making judgements concerning right and wrong behaviour.Evidence-based reasoning Knowledge and practice that is supported with evidence is evi-

dence-based reasoning.Formalism Formalism in systems analysis and design is the notation and its structure used to

represent things of interest in a problem domain. It is used to develop formal systems models.Information Information is used by decision-makers to allocate, monitor and control resources

in an organization. Information in terms of computing is processed data.Interpretivism Interpretivism is an epistemology used in IS research. It is applied to under-

stand and develop knowledge of subjective and phenomenological aspects of IS. A person usingthis method is called an interpretivist or subjectivist. Interpretivism is based on phenomenol-ogy, the idea that detailed descriptions of human experience alone constitute knowledge.Phenomenology does not focus on explanations.

JAD Joint Application Development is the notion, methods, techniques and tools that enablepeople in the problem domain and professional IS developers to work together to develop an IS.

JSD Jackson System Development is the set of structured techniques proposed to develop IS.

284

Glossary..................................................................................................................................................

JSP Jackson Structured Programming is the set of structured techniques proposed to developsoftware programs.

Method A method is a set of activities designed to achieve a specific systems analysis or systemsdesign task.

Methodology A methodology consists of a prescriptive staged process for IS problem defini-tion and development with associated techniques and tools. The stages may be variously dividedin different methodologies, but they all contain systems analysis and systems design.

Notation language A notation language is a formal set of symbols with precise meanings torepresent things of interest in the problem domain. It is used in structured systems ontology todevelop models of the current and new IS. Modelling notations help to objectify the problemdomain and facilitate communication between analysts themselves, with clients and softwareprogrammers.

Object-oriented analysis Object-oriented analysis is the specific systems analysis and designtechnique proposed by Coad and Yourdon.

Objectification Something is objectified when it is recorded on physical media. Mental con-structs recorded on physical media are objectified. Objectification is used to develop a PCF.

Objectivism Objectivism is the doctrine that reality is objective or independent of the observerand that sense data directly correspond to it. A person who practices objectivism is called anobjectivist. Structured systems ontology, and to some extent, object-oriented systems ontology,is based on objectivism.

Ontology Ontology is concerned with the nature of being. It is the assumptions or presuppo-sitions in a theory to explain a phenomenon. The notion of ‘structure’ or ‘object’ in systemshas a set of ideas that describe systems based on certain assumptions.

Organization A sociological definition of organization is that it has a goal, boundary andhuman activity. It is composed of people and the work they do to achieve predetermined busi-ness aims.

Organizational knowledge Organizational knowledge are the experiences and actions ofindividuals and groups, or communities of practice, involved in achieving specific objectives.

OSS Open Source Software is a movement in software development that makes initial softwarecode open for the public, usually interested software programmers and organizations, to helpin its further development. Open source software is licensed by the Open Source Initiative(OSI) for commercial exploitation.

Paradigm A paradigm is a set of beliefs, assumptions, values, and shared knowledge acceptedby a community of practice. It forms a body of knowledge and informs practice.

Paradigmatic critical framework Paradigmatic critical frameworks can be of two types. Acritical focus on what constitutes knowledge and how it is acquired within a paradigm or acritical focus on what constitutes knowledge and how to acquire it across paradigms.

Participative Design See JAD.PCF Personal Critical Framework is an intellectual device for acquiring, interpreting, evaluat-

ing and inferring personal knowledge appropriate for action.Persistent data Data that continues to exist when the system is not live and needs to be stored

for further use.

111

0

11

0111

0

0

11p

285

..................................................................................................................................................Glossary

Personal construct Individuals experience reality and then develop constructions (personalconstructs) to help them anticipate it. Personal constructs are used to interpret and explain events.They are part of a personal construct system, which is a set of personal constructs and the relations between them that provides the unity in the experience of individuals.

Planned action Action that is predetermined with expected outcomes to achieve known objec-tives and enacted in actual situations to realize the expected outcomes.

Praxis Praxis is the art of acting in given conditions in order to change them.PRINCE Project Management In Changing Environments is a systems project management

method. It is devised to determine the scope, plan, monitor and control and IS development.Problem domain A systemic term to describe an actual situation for which an IT solution is

required.Problem-solving Problem-solving in systems analysis and design requires the application of

rationality, logic and formalism to a human area of concern to seek a resolution.Prototype An initial IS product used to determine system requirements by testing it in the

problem domain with users. Prototypes are developed using RAD.RAD Rapid Application Development is a process for rapidly developing software with users

participating.Reality The actual condition in which human action happens.Repertory grid A repertory grid is used to elicit, assign, and analyse knowledge in terms of

personal construct and can be used for self-help. It can be used to assess and evaluate personalexperiences and knowledge.

Scientific method An empirical epistemological method for acquiring, testing and verifyingempirical knowledge.

SDLC Systems Development Life Cycle is a method demarcating distinct phases of IS devel-opment activities.

Situated action Situated action depends on its material and social circumstances.Social action The activities of humans in a group oriented towards the achievement of objec-

tives.Socio-technical The combination of social and technical factors in an IS methodology.Software engineering The idea of applying engineering precision and discipline to software

development.SSM Soft Systems Methodology is a continuous learning cycle for people in situations of social

concern.Stakeholders Stakeholders are groups of people or a person who has a specific interest in a

system project because they are the sponsor of it, or will be affected by it, or will have to workwith a new IS.

Structured systems analysis Structured systems analysis is the practice of systems analysisbased on the discipline of formal structure and problem-solving in the process of conducting sys-tems analysis.

Structured systems design Structured systems design is the practice of systems design based on the discipline of formal structure and problem-solving in the process of conducting systemsanalysis.

286

Glossary..................................................................................................................................................

System A system is an abstract concept used to structure a problem and seek its resolution interms of a boundary, sub-elements, control and feedback.

Systems analyst A systems analyst is someone who investigates and makes systems models ofa problem domain.

Systems ontology Systems ontology is knowledge of what constitutes the nature of systems.The term systems ontology is used to describe knowledge and practice relating to computer-based IS.

Technique A specific intellectual device to achieve a concrete result used to develop an IS.Temporary data Data that exists only during the time the system is live or during run-time.Time boxing The demarcation of systems development and project management activities into

discrete time periods for completion.Tool An implement used as a medium for achieving a specific objective.UML Unified Modelling Language is a graphical notation for systems modelling used on its

own or as part of a method or methodology to express concepts for IS in object-oriented terms.Usability Usability is the consideration of efficient and effective means in user interfaces to

enable specific users to achieve specific tasks.User A label given by technically qualified IT professionals for people who use computer-based

IS. The term ‘user’ is also used by IS researchers and others.

111

0

11

0111

0

0

11p

287

..................................................................................................................................................Glossary

AgileAlliance Manifesto 247agile software development: act and think strategy

13; individuals 277; interpretivism 34; modellingsocial action 247; non-separation of analysis anddesign 187, 237; response to ‘analysis paralysis’144; situated action 8, 32; storycard 247, 249;subjectivity 166; systems project management 277

amethodological 275; situated action 276; TruckeseNavigator 276

application domain 53, 58; multifarious 87;predictable and repeatable 187; problem domain 21

best practice critique 247business analyst 68business case 95, 111business model 43

capability maturity model 107CASE 72change management 225, 233; theory 233classification theory: transformatory critique 210class model 195Component-Based Development 276computer program 228; cohesion 228; coupling

228; modules 228corporate database 156; fragmented data stores

166; organization 234Critical Framework: critique 46; epistemology 32;

example application 45; human problems 34;

inclusive 279; IS theory 55; organization theory31; ownership 11, 188; paradigmatic 267;pragmatic resolution 35; relating to PCF 44; self 37; social theory 243; subjective 36; systems ontology 33, 34; systems theory 67;theory 31

criticality: across paradigms 267; critical skills 19;critical thinker 19; critical thinking 18; critique29; definition 19; refashioning of traditions 19,31; reflexivity 19; self 19; transformatory critique19, 31, 33; within paradigm 267

critical systems ontology 8, 11; abstract forms 254; classification theory 196; communicativedevices 190; cultural factors 245; definition 3;interactivity 220; mutuality 247; NIMSAD 245; ontology 9; organizational factors 245;philosophy 33; political factors 246; reductionism 184; repeatability 187;representation 184; representative sample 164,187; shared understanding 188; structurationtheory 244

data 29, 43, 56; iterative modelling 155; logicaldata modelling techniques 157; mechanisticdefinition 83; modelling 155; processing 57

database: conceptual schema 232; external schema232; internal schema 232; interrogation 232;logical database model 162; logical views 162;model types 148; object-oriented 226; structuredsystems design 226, 229; technology development236; transient data 199

288

Index

data dictionary 72, 142, 163; object-oriented 202data entry 218data flow diagrams 172; balanced DFD 175;

coupling 175; decomposition 173; notation 173data output 219data transformation 172DBMS 142deferred system’s design 277; action developer 279;

application 279; deferred classes 187; Deferred-Specified IT/IS Matrix 277; emergentorganization 278; IS and organization integration255; organization ontology 278

Delphi method 104documentation 163; structured design 227

education 5, 48; training 5entity: association 160; attributes 159; cardinality

160; entity life history 175; entity types 157; key159; normalisation 160; relationship 158

epistemology: interpretivism 34; nomological 265;objectivism 10; phenomenology 34; positivism34; probabilistic-statistical 265; reductionism 34

E-R model 157

formalism 31; object-oriented systems analysis 206;structured systems analysis 65

grid chart 228

human action: action 265; assumptions 265;deferred action 277; developing knowledge ofplanned action 8; developing knowledge ofsituated action 8; intention 258; planned action32, 38; situated action 8, 32, 34, 39; systemstheory 39

human activity system 246human–computer interaction 220

information 29, 43, 56; business logic 177; humaninterpretation 258; information assets 56;mechanistic definition 83; problem domain 43

information system 46; defining the problem 253;failure 112; meaning 244, 265; social factors 243;systems thinking 41; types 96

instruments 12; non-systemic factors 249

interaction models 219internet 208

Java 208

knowledge: acquisition 33; conceptual 31, 55;criticality 18; deficiency 19; development 8, 31,55; empirical data 31; evaluation 31; formal 31;generalised 37, 38, 55, 59; knowledge assets 56;objective 34; ontological 34, 36; personal 18, 29,36, 48; positivist 10; practical 32, 35; progress264; redefining 19; revolutions 264; scientificmethod 8, 10, 32; social construction 244;subjectivism 10; validity 255

knowledge management 29, 43, 56

legacy systems 187logical data model 154logical model: definition 65

method: European Navigator 276methodology: category 74; engineering discipline

64; ETHICS 38; JAD 32; NIMSAD evaluationframework 245; purpose 74; SDLC 38, 59;SDLC versions 83; SSADM 38, 70; SSADMtechnical products 182

model 156; abstract representation 156; activemodels 187; conceptual data 160; definition see developer 254; passive 187; rigour 211

notation languages 65; communication 64;definition 62; meta model 266; object-oriented67, 70; power 166

object-orientation 195; classification theory 195;data types 198; de-coupling 206; generalisation202; message 199; object-oriented programming195; object technology 66; object type 200;operations 198; polymorphism 200; responsibility202; SMALLTALK 208

object-oriented systems analysis 206; Coad andYoudon 207

object-oriented systems analysis and design:association 202; class 197; class instrance 198;class model 67; encapsulation 199; inheritance

111

0

11

0111

0

0

11p

289

......................................................................................................................................................Index

197; integrated class model 78; methods 199;multiplicity 202; object 198; object attributes 198;scenario 203; scenario definition 202; service 199;use case 203; use case script 203

object-oriented systems design 219; additionaldesign diagrams 230; class model 219; datamanagement component 231; human interactioncomponent 220; refining class model 230; systeminteraction component 232

object-oriented systems ontology 28; IS 196; pattern196; reality 195

ontology management tools 253organization: effectiveness 41, 42, 166; efficiency

29, 41, 42, 172; organization ontology 148;organizing 257

PAC cycle 3paradigm: definition 264; explicit and implicit 264;

functionalism 264; IS paradigms 264; knowledge264; neohumanism 265; paradigmatic knowledge255; radical structuralism 265; social relativism265; social theory 264

persistent data 232personal construct theory 10; anticipate 11;

constructive alternativism 10; individual’sexperience 13; personal construct 10; personalconstruct system 10, 11, 24; personal constructtypes 11; Repertory Grid 11; Repertory Gridtechnique 21

personal critical framework 3, 6; anticipate 4;effectiveness 4; ethics 9; evidence-based 13;improving instruments 12; knowledge acquisition11; objectification 5; objectification for personaleffectiveness 4, 8; objectification problems 12;ownership 5; practice effectiveness 7; reality 31;self regulation 269

platform 226practice 7praxis: definition 286; deployment of knowledge 5;

hidden relations 263; practical 6problem domain 58; functional 234; static 258;

systemic problem 243problem-solving: Action Science 14; behaviourist

theory 68; decomposition 173; formal 68;General Problem Solver Model 68; Gestalt

theory 68; holism 43; interpretivism 34; logicalthinking 43; NIMSAD 245; object-oriented 211;productive 68; reductionism 34, 86; reproductive68; systemic 20; systems analysts 13; systemstheory 68; types 43

process: knowledge 184; wider concept 184process logic 177; business logic 177; modelling

techniques 177; pseudocode 177process model: logical process model 171; transform

data 171process modelling: Structured English 178;

techniques 172project manager: leadership models 99prototyping 78; define problem 143; merging

analysis and design 237; requirements elicitation143; strategies 78; subjectivity 166

rational: plan 8; think and act 13rationality see human actionreal-time 219Repertory Grid; visual focusing 22

social action 243; politics 247; social factors 37software: agile 11; algorithm 57; component 206;

open source software 34; reuse 67software engineering: analogy 82; analyst’s role 131;

Software Engineering Institute 102stable data 231, 234structured systems design 225; file design 228;

implementation-dependent 225; implementation-independent 225; Nassi-Schneiderman charts228; physical data design 226; program design228; transform analysis 208, 226

structured systems ontology 11, 28, 188; objectivereality 12; planned action 32; separation ofanalysis and design 236; structured systemsanalysis 56, 64, 103; transformatory critique 19

system: correct models 84; debates 46; emergentproperty 40; graphical models 69; modelling 62;object-oriented 66; physical model 65

system project: estimation 104; estimation models105; human factors 98; motivation theories 99;network dependencies 103; precedence network103; product breakdown structure 103; projectmanager 65; project network 103; quality

290

Index......................................................................................................................................................

definition 101; risk management 102; stakeholderdefinition 98; team 100; work breakdownstructure 103

system requirements 138; alternatives 142;application domain 58; ‘creeping requirements’190; definition 138; engineering 146; people’sknowledge 140; types 139

systems analysis 11, 31, 146; in object-orientedanalysis 67; practice 35

systems analyst 8, 9, 12, 28, 29, 33, 41, 61, 68;change management 237; cognitive skills 120;creativity 44; critical skills 121; interpretation188; knowledge of social factors 37; objective 79,166; personal critical framework 7; qualities 119;role 121; social identity 259; in structuredanalysis 66; work 32

systems design 217; structured design 217systems project management 93; business project

94; interpretive 279; software development seesoftware; stakeholders 88; timeboxing 236

system specification 138

systems theory 36, 39–40systems thinking 40, 42

techniques 122; interview 122; observation 125;operations 201; planned action 8; services 202

theory: definition 6theory and practice 7traditional systems analysis 63training 28transaction data 155

UML 70; contextual use 211; diagram types 205user interface 218; direct manipulation device

218; graphical 218; interactivity 218; mentalmodels 222; SSADM 218; usability 218; user model 218

world wide web 208

XP 142, 143; shared understanding 144; socialcontext 144; stories 144

111

0

11

0111

0

0

11p

291

......................................................................................................................................................Index