IMS1805 Systems Analysis Topic 3: Doing analysis (cont from last week)

2 Recap of last week The importance of understanding the purpose of analysis Some important purposes: Organisational; Technological; Development team The purposes behind process models (FDD/DFD) and data models (E-R diagrams)

3 Agenda Aim: To develop further your understanding of the main purposes for which IS analysis is done To understand the reasons behind the evolution of analytical techniques in IS To identify the purpose of object-oriented techniques and soft system techniques in IS

A reminder of the evolution of analytical techniques in IS Flowcharts (from programming logic and sequence) Process-oriented techniques (a logical extension/variation of flowcharts to focus on data movements) Data-oriented techniques (from database technology) Object-oriented techniques – combining data and process ‘Soft systems’ techniques – people aspects of systems

5 The intellectual rationale for O-O The real world consists mainly of objects (some physical, some conceptual) Objects combine the features of process and data modelling: Like entities, they have attributes and relationships with other objects Like processes, they are capable of performing actions which change themselves or other objects People naturally think of things as objects, so it is good to model things as objects

6 Is this true? Do we always see things as objects? In terms of analysis, are we always better- off combining data and process aspects, or are we better-off separating them? The VCR example: Attributes: Brand, model, size, colour, etc Processes: Play, Fast forward, rewind, record, etc When does analysis based on objects help with your understanding of a situation?

7 The technological rationale for O-O O-O programming languages (VB.Net, Java, etc) are based around creating and manipulating program objects (windows, boxes, etc) which have attributes and can perform processes O-O programming tries to use these objects to save development effort by enabling re- use (like using Lego blocks) O-O Analysis links well with implementation in O-O programming languages

8 The intellectual rationale for soft systems Many real world systems depend as much on people as on technology Good systems should take account of the attitudes and motivations of the people who interact with them A system developer’s understanding of a system is incomplete unless it includes an understanding of the people involved in a system

9 Is this true? How important are people to information systems? Can/should people be required to conform to the technology of a system, rather than the other way around? Shouldn’t IS analysts get on with technology and information-related aspects of systems, and leave the people side to sociologists, etc?

10 Why discuss this now? The change from process-oriented and data-oriented methods was linked with major changes in the nature and purpose of IS Your overall understanding of systems analysis is dependent on your ability to understand how/why these changes occurred We will look at it more carefully later, but it is worth noting here to highlight the contrast with previous methods (This topic is highly examinable!)

11 2(d) (Continuation of Monday) The basics of object-oriented (O-O) models Object classes – categories of objects Objects – instances of a particular class Object attributes – information about an object Object states – specification of particular values which the attributes of an object can take Object behaviours – specifications of what an object can do Methods – specific actions which an object can perform to implement its behaviour

12 Why draw an O-O model (organisational purpose)? Identify objects which are used widely across many different parts of an organisation Identify how different parts of an organisation use a given object (or class of objects) in different ways Better understand the overlaps and conflicts in how particular objects and object classes are used across an organisation

13 Why draw an O-O model (technological purpose)? Encapsulation: by combining data and process into objects we simplify the relationships between them – each object can be treated as a ‘black box’ which performs certain functions without the developer having to know how Inheritance: hierarchies of objects (superclasses and subclasses) in which lower classes inherit the characteristics of more general classes Re-use: When an object is created, it can be a copied and modified version of another object of the same type

14 Why draw an O-O model (team purpose)? Different parts of a development teams can work separately on the creation of the objects required by the system Objects can be shared and re-used by team members to make the development process more efficient Teams build “libraries” of objects to facilitate sharing of expertise

15 2(e): The basics of soft systems models Stakeholders – people who are involved with the system Interactions/relationships which these stakeholders have with the system and with one another Descriptions of the key aspects of the way the interactions affect the way the system works (or should work)

16 Why draw a soft systems model (organisational purpose)? Organisations are groups of people working together to provide service to other individuals/groups of people. All these people have different orientations/attitudes towards a system Understanding the stakeholders within the system is crucial to understanding the overall purpose of a system and its effects on the people in an organisation

17 Why draw a soft systems model (technological purpose)? As a non-technological method, soft systems models do not directly serve technological purposes, but still help to define limits for technology: Technology is a tool to serve people, not an end in itself; soft systems models help highlight the impacts of technology on people Technology has limited capacity to achieve human ends; soft systems models help to highlight these limitations

18 Why draw a soft systems model (team purpose)? Soft systems models help development teams identify the Development teams are themselves stakeholders in the development process. What are their orientations towards a systems and how do they affect the way the team operates?