Transcript Monday lecture - Information Management and Systems

IMS1805
Systems Analysis
Topic 3: Doing analysis (cont
from last week)
www.monash.edu.au
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)
www.monash.edu.au
2
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
www.monash.edu.au
3
1. 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
www.monash.edu.au
4
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
www.monash.edu.au
5
Is this true?
• Do we always see things as objects?
• In terms of analysis, are we always betteroff 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?
www.monash.edu.au
6
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 reuse (like using Lego blocks)
• O-O Analysis links well with implementation
in O-O programming languages
www.monash.edu.au
7
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
www.monash.edu.au
8
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?
www.monash.edu.au
9
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!)
www.monash.edu.au
10
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
www.monash.edu.au
11
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
www.monash.edu.au
12
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
www.monash.edu.au
13
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
www.monash.edu.au
14
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)
www.monash.edu.au
15
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
www.monash.edu.au
16
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
www.monash.edu.au
17
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?
www.monash.edu.au
18