UKAI 2063

Accounting
Information Systems II
Lecture 2
System Development Strategy

2-1
 Lecture 2 Outline

• The business case for information systems

projects
• Feasibility study
• An overview of systems development
methodologies, techniques and tools
• Structured approach to systems development:
systems development life cycle (SDLC) and
structured systems analysis and design method
(SSADM)
2-2
 The Business Case for
Information Systems Projects

2-3
Introduction

• The term business case refers to the reasons, or justification, for a

proposal
• A strong business case suggests that the company should pursue the
alternative, above other options, because it would be in the firm’s
best interest to do so
• Systems development typically starts with a systems request,
followed by a preliminary investigation, which includes a feasibility
study

2-4
Strategic Planning – A Framework for IT
Systems Development
• Strategic Planning Overview
• SWOT analysis
• Porter’s Five Forces

2-5
2-6
Strategic Planning – A Framework for IT
Systems Development
• From Strategic Plans to Business
Results
• Mission statement
• Stakeholders
• Goals
• Objectives

2-7
2-8
Strategic Planning – A Framework for IT
Systems Development
• The Future
• If you could look into the future, here is what you might see: new industries,
products, and services emerging from amazing advances in information
technology, customers who expect world-class IT support, a surge in Internet-
based commerce, and a global business environment that is dynamic and
incredibly challenging

2-9
2 - 10
What Is a Business Case?

• Should be comprehensive, yet

easy to understand
• Should describe the project
clearly, provide the justification
to proceed, and estimate the
project’s financial impact

2 - 11
Business Case’s Questions
• - why are we doing this project?
• What is the project about?
• How does this solution address
key business issues?
• How much will it cost and how
long will it take?
• What alternatives exist?
• Will we suffer a productivity loss
during the transition?
• What is the return on
investment and payback
period?
• What are the risks of doing the
project and not doing the
project?
• How will we measure success?
2 - 12
Information Systems Projects

• Main Reasons for Systems Projects/Request

2 - 13
Information Systems Projects

• Factors that Affect Systems Projects

2 - 14
Overview of Feasibility

• A systems request must pass

several tests, called a feasibility
study, to see whether it is
worthwhile to proceed further

2 - 15
Overview of Feasibility

• Operational Feasibility
• Depends on several vital issues
• Technical Feasibility
• Economic Feasibility
• Total cost of ownership (TCO)
• Tangible benefits
• Intangible benefits
• Schedule Feasibility

2 - 16
Evaluating Feasibility

• The first step in evaluating feasibility is to identify and weed out

systems requests that are not feasible
• Even if the request is feasible, it might not be necessary
• Feasibility analysis is an ongoing task that must be performed
throughout the systems development process

2 - 17
Setting Priorities

• Factors that Affect Priority

• Will the proposed system reduce costs? Where? When? How? How much?
• Will the system increase revenue for the company? Where? When? How?
How much?

2 - 18
Setting Priorities

• Factors that Affect Priority

• Will the systems project result in more information or produce better results?
How? Are the results measurable?
• Will the system serve customers better?
• Will the system serve the organization better?

2 - 19
Setting Priorities

• Factors that Affect Priority

• Can the project be implemented in a reasonable time period? How long will
the results last?
• Are the necessary financial, human, and technical resources available?
• Whenever possible, the analyst should evaluate a proposed project based on
tangible costs and benefits that represent actual (or approximate) dollar
values

2 - 20
Setting Priorities

• Discretionary and Nondiscretionary Projects

• Projects where management has a choice in implementing them are called
discretionary projects
• Projects where no choice exists are called nondiscretionary projects

2 - 21
Preliminary Investigation Overview

• Preliminary investigation
• Interaction with Managers and Users
• Let people know about the investigation and explain your role
• Employee attitudes and reactions are important and must be considered
• Be careful in your use of the word problem
• Question users about additional capability they would like to have

2 - 22
Preliminary Investigation Overview

• Planning the Preliminary Investigation

• During a preliminary investigation, a systems analyst typically follows a series
of steps
• The exact procedure depends on the nature of the request, the size of the
project, and the degree of urgency

2 - 23
 Preliminary Investigation Overview
• Step 1: Understand the Problem or Opportunity
• Step 2: Define the Project Scope and Constraints
• Step 3: Perform Fact-Finding
• Step 4: Analyze Project Usability, Cost, Benefit, and
Schedule Data
• Step 5: Evaluate Feasibility
• Step 6: Present Results and Recommendations to
Management

2 - 24
 Overview of systems
development methodologies,
techniques and tools

2 - 25
 Some reasons why systems
development failed
■A lack of ownership of and commitment to the system
from users, as a result of the low level of involvement.
■Do not satisfy business requirements or requirements
could have been mis-understood.
■Business requirements could have changed between
inception and delivery.
■Inadequate analysis and design tools and techniques
could have been used.
■Cause extensive maintenance requirements and thus
an increase in the applications backlog.
■Or more likely a combination of these problems.
2 - 26
To improve systems success

Business managers should:

Align the interests of system developers and the

managers who must implement information
systems.

Initiate serious review of the proposed system

design concept and plans for achieving system use
and value.

Make thorough system investment decisions by

measuring and managing systemSource:
use and value.
Markus and Keil (1994)

2 - 27
To improve systems success

Systems specialists should:

Accept responsibility for system use, not just

systems.

Focus on the system design concept in addition to

user requirements and, wherever possible, propose
multiple design concepts.

Employ user-participation strategies as a way to get

a good design concept.
Source: Markus and Keil (1994)

2 - 28
Systems methodology
A systems development methodology is a recommended
means to achieve the development, or part of the
development, of information systems based on a set of
rationales and an underlying philosophy that supports,
justifies and makes coherent such as recommendation for a
particular context.

The recommended means usually includes the

identification of phases, procedures, tasks, rules,
techniques, guidelines, documentation and tools. They
might also include recommendations concerning the
management and organization of the approach and the
identification and training of the participants.
Source: Avison and Fitzgerald (2003)
2 - 29
 Examples of systems methodology
JSD Extreme programming (XP)
JAD (good software practices p20)
SSADM OOAD
IE RUP
SSM CASE
Multiview ( several Spiral
competing methodologies) Waterfall
RAD ETHICS (Social Technical
DSDM systems development P20)
OMT

XP – http://www.extremeprogramming.org
DSDM - http://www.dsdm.org

2 - 30
Systems technique

• Specific techniques the systems analysis and design

teams follow to ensure the outputs are clear,
accurate and complete, e.g. DFD, ERD, and rich
picture.
• A technique is a way of doing a particular activity in
the information systems development process, and
any particular methodology may recommend
techniques to carry out many of these activities.
• Each technique may involve the use of one or more
tools.

2 - 31
Examples of systems technique

Rich pictures Structured walkthroughs

Root definitions Object orientation
Conceptual models UML
Entity modelling PERT charts
Relational modelling Gantt charts
Normalization Joint application development
Dataflow diagramming (JAD)
Entity life History

2 - 32
Systems tool

• Tools are normally software to help the

development of an information system, e.g. CASE,
Systems Architect, Ms- Project

• These tools might enable some development task to

be done automatically or semi-automatically.

2 - 33
Examples of systems tool

• Project management: MS Project

• Web site development: Dreamweaver
• Drawing: Microsoft Visio
• Database management system: Microsoft Access,
MySQL, DBMS

2 - 34
How systems methodology helps?

• To record accurately the requirements for an

information systems and to reduce the chances of
mis-understanding the requirements.
• To provide a systematic method of development so
that progress can be effectively monitored.
• To introduce best practice techniques to the
analysis and design process.

2 - 35
How systems methodology helps?

• To produce an information system within an

appropriate time limit and at an acceptable cost.
• To produce a system which is well documented and
easy to maintain.
• To provide an indication of any changes that need to
be made as early as possible in the development
process.
• To provide a system that is liked by those people
affected by that system.

2 - 36
Features of systems methodology

• A methodology can range from being a fully-

fledged product detailing every stage and task to be
undertaken to being a vague outline of the basic
principles in a short pamphlet.
• A methodology can cover widely differing areas of
the development process, from high-level strategic
and organizational problem solving to the details of
implementing a small computer system.

2 - 37
Features of systems methodology
• A methodology can range from being designed to be
applicable to specific types of problem in certain types
of environment or industry to an all-encompassing
general-purpose methodology.
• A methodology may be potentially usable by anybody
or only by highly trained specialists or be designed for
users to develop their own applications.
• A methodology may require an army of people to
perform all the specific tasks or it may not even have
any specified tasks.
• A methodology may or may not include tools and
toolsets.

2 - 38
So many methodologies, which is the best?

• There is no benefit to be gained from attempting to

find, in isolation, a “best” methodology.

• There should be a search for an appropriate

methodology in the context of the problems being
addressed, the applications and the organization
and its culture.

2 - 39
What context? You might ask…

____|_______________|_______________|_____
Structured Unstructured
“We have 20 bank branches in Kuala Lumpur; all
branches combined there are 5,000 deposits made
on each working day. We keep details about each
deposit, e.g. customer A/C number, amount deposit,
and so on.”

“We need a new web portal to allow

customers to buy groceries online.”
2 - 40
 Five different classes of situation
and appropriate approaches
Situation Systems development Approaches
1 Well-structured A traditional SDLC approach
problem situations might be regarded as
with a well- appropriate in this class of
defined problem situation
and clear
requirements
2 As above but with Data, process modelling, or a
unclear prototyping approach are
requirements suggested as appropriated here
Source: Avison and Taylor (1996)
2 - 41
 Five different classes of situation
and appropriate approaches
Situation Systems development
Approaches
3 Unstructured A soft systems approach
problem situation would be appropriate in this
with unclear situation.
objectives.
4 High user-iteration A people-focused approach,
systems. for example, ETHICS would
be appropriate here.
5 Very unclear A contingency approach, such
situation. as Multiview, is suggested.
Source: Avison and Taylor (1996)
2 - 42
Systems Development
Life Cycle

2 - 43
 Systems Development Life Cycle (SDLC)

• The traditional SDLC is one of the earliest

methodologies to systems development.
• It was developed by Royce in 1970.
• The SDLC consists of phases that are an organised way
of progressing through the IS development, using
specific techniques and tools.

2 - 44
Systems Development Life Cycle (SDLC)

• A waterfall model: outputs from one phase feed

into next phase.
• The SDLC phases and their activities should be
tailored for each specific IS development.
• A large number of SDLC models exist, however all
contain minor variations to break up the basic cycle
of IS development (Conceptual Framework), i.e.
analysis, design, development and implementation.

2 - 45
Conceptual Framework of SDLC
Stages

Analysis

Implementation Design

Development

2 - 46
Other View of SDLC Stages

2 - 47
Other View of SDLC Stages

2 - 48
 In this unit, we will follow the one by Shelley
& Cashman (2010)
• Phases of the SDLC

• System Planning
• Systems Analysis
• Systems Design
• Systems Implementation
• Systems Support & Security

2 - 49
SDLC Stages

2 - 50
 Phases of SDLC
• Systems Planning
• Systems planning phase
• Systems request – begins the process & describes problems
or desired changes
• Purpose of this phase is to perform a preliminary
investigation
• Key part of preliminary investigation is a feasibility study

• Output:
• Feasibility report containing problem definition and
objective summaries from which management can make a
decision on whether to proceed with the proposed project

2 - 51
Phases of SDLC
• Systems Analysis
• To understand how users accomplish their work when
interacting with a computer; and begin to know how to
make the new system more useful and usable.
• To understand how the business functions and have
complete information on the people, goals, data and
procedure involved
• Learn the who, what, where, when, how, and why of the
current system
• Fact finding techniques includes:
• Interviewing
• Sampling and investigating hard data
• Questionnaires
• Observe the decision maker’s behavior and environment

• Output:
• Deliverable is the System requirements document

2 - 52
 Phases of SDLC
• Systems Design
• Create physical model
• Design user interface, identify necessary outputs, inputs,
and processes
• Design internal/ external controls
• Determine application architecture

• Output:
• System design specification

2 - 53
 Phases of SDLC
• Systems Implementation
• New system is constructed
• Programs written, tested, and documented, and the systems
is installed
• Converting to new system
• User training

• Output:
• Complete functioning system

2 - 54
 Phases of SDLC
• Systems Support & Security
• Maintenance, enhancement and protecting the system
occurs at this phase
• Maximise return on the IT investment
• A well-designed system must be secure, reliable,
maintainable, and scalable

• Output:
• Operational information systems

2 - 55
A Structured Systems
Analysis and Design
Method (SSADM)

2 - 56
 Structured Systems Analysis and
Design Method (SSADM)
• Originally developed by the UK consultant Learmonth and
Burchett Management Systems (LBMS) and Central
Computing and Telecommunications Agency (CCTA)** to
standardise development process in the government
departments.
• SSADM has gone through a number of changes since its
original publication with the last version being issued in
1996 as 'SSADM 4+ version 4.3‘.
• By the mid-1990s SSADM was the most widely-used
application development methodology in Europe, with
over 5,000 certified practitioners.

** As from 1st April 2001, CCTA became an integral part of

the Office of Government Commerce (www.ogc.gov.uk) 2 - 57
Areas covered by SSADM

• Analysis of the current business procedures and

organization to see how a new system will best fit
into them.
• Analysis of any system (automated or manual) that
covers the same or similar functions to those for
the new system to ascertain how they work and
what could be done to improve them.
• Analysis and design of the data requirements for
the new system including any ad-hoc reporting
required from it.

2 - 58
Areas covered by SSADM

• Analysis and design of the processing required to

enable the data to be captured, manipulated,
stored and then reported on.
• Analysis and design of the interface required to
support the user when working with the new
system.
• First-cut design for the database of the new system
and the physical processes required to access the
data.

2 - 59
SSADM Structure
Feasibility Study

Requirements Analysis

Requirements Specification

Logical System
Specification

Physical Design
2 - 60
• SSADM adopts the waterfall model of systems
development, where each stage has to be
completed and signed off before subsequent stages
can begin.
• SSADM 4+ has seven stages within a five-module
framework, each with its own set of plans,
timescales, controls, and monitoring procedures.
• SSADM does not cover the implementation and
maintenance stages, treating them as installation-
specific.

2 - 61
Major Tools of SSADM

• Logical Data Modelling

• Data Flow Modelling
• Entity /Event Modelling

2 - 62
2 - 63
2 - 64
2 - 65
 Acknowledgements
This PowerPoint presentation contains
materials complied from various sources.
Credits are hereby given to their respective
owners. Please refer to the reading list for
details.

Reminder
The lecture slides serve only as a quick
learning guide. Students are required to refer
to the main textbook for detailed elaboration.

2 - 66