UKAI 2063 Lecture 2 Outline

Accounting
• The business case for information systems projects
Information Systems II • Feasibility study
• An overview of systems development
Lecture 2 methodologies, techniques and tools
• Structured approach to systems development:
System Development Strategy
systems development life cycle (SDLC) and
structured systems analysis and design method
(SSADM)

2-2

Introduction
The Business Case for • The term business case refers to the reasons, or
Information Systems •
justification, for a proposal
A strong business case suggests that the
Projects 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

1
 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? Business Case’s Questions

 Should be  - why are we doing this
comprehensive, yet easy project?
to understand  What is the project
 Should describe the about?
project clearly, provide  How does this solution
the justification to address key business
proceed, and estimate issues?
the project’s financial  How much will it cost
impact and how long will it take?
 What alternatives exist?
2 - 11
 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

2
 Information Systems Projects Information Systems Projects
 Main Reasons for Systems Projects/Request  Factors that Affect Systems Projects

2 - 13 2 - 14

Overview of Feasibility Overview of Feasibility

 A systems request must  Operational Feasibility
pass several tests, called a  Depends on several vital issues
feasibility study, to see
 Technical Feasibility
whether it is worthwhile
to proceed further  Economic Feasibility
 Total cost of ownership (TCO)
 Tangible benefits
 Intangible benefits

 Schedule Feasibility

2 - 15 2 - 16

Evaluating Feasibility Setting Priorities

 The first step in evaluating feasibility is to  Factors that Affect Priority
identify and weed out systems requests that are  Will the proposed system reduce costs? Where?
not feasible When? How? How much?
 Even if the request is feasible, it might not be  Will the system increase revenue for the company?

necessary Where? When? How? How much?

 Feasibility analysis is an ongoing task that must

be performed throughout the systems
development process

2 - 17 2 - 18

3
 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?
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 - 19 2 - 20

Preliminary Investigation
Setting Priorities
Overview
 Discretionary and Nondiscretionary Projects  Preliminary investigation
 Projects where management has a choice in  Interaction with Managers and Users
implementing them are called discretionary projects  Let people know about the investigation and explain
 Projects where no choice exists are called your role
nondiscretionary projects  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 - 21 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
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 - 23 2 - 24

4
 Some reasons why systems
Overview of systems development failed
A lack of ownership of and commitment to the system
development ■
from users, as a result of the low level of involvement.
methodologies, ■ Do not satisfy business requirements or requirements
could have been mis-understood.
techniques and tools ■ 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 To improve systems success

Business managers should: Systems specialists should:

 Align the interests of system developers and the  Accept responsibility for system use, not just systems.
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 system use and value.
Source: Markus and Keil (1994)
 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 - 27 2 - 28

Examples of systems
Systems methodology
methodology
A systems development methodology is a recommended JSD Extreme programming (XP)
means to achieve the development, or part of the JAD (good software practices p20)
development, of information systems based on a set of SSADM OOAD
rationales and an underlying philosophy that supports, IE RUP
justifies and makes coherent such as recommendation for a SSM CASE
particular context. Multiview ( several competing Spiral
methodologies) Waterfall
The recommended means usually includes the identification of RAD ETHICS (Social Technical

phases, procedures, tasks, rules, techniques, guidelines, DSDM systems development P20)
OMT
documentation and tools. They might also include
recommendations concerning the management and XP – http://www.extremeprogramming.org
organization of the approach and the identification and DSDM - http://www.dsdm.org
training of the participants.
Source: Avison and Fitzgerald (2003) 2 - 29 2 - 30

5
 Examples of systems technique
Systems technique
 Specific techniques the systems analysis and design
teams follow to ensure the outputs are clear, accurate Rich pictures Structured walkthroughs
and complete, e.g. DFD, ERD, and rich picture. Root definitions Object orientation
Conceptual models UML
 A technique is a way of doing a particular activity in the
Entity modelling PERT charts
information systems development process, and any Relational modelling Gantt charts
particular methodology may recommend techniques to Normalization Joint application development
carry out many of these activities. Dataflow diagramming (JAD)
 Each technique may involve the use of one or more Entity life History

tools.

2 - 31 2 - 32

Systems tool Examples of systems tool

 Tools are normally software to help the development of  Project management: MS Project
an information system, e.g. CASE, Systems Architect,  Web site development: Dreamweaver
Ms- Project  Drawing: Microsoft Visio
 Database management system: Microsoft Access,
 These tools might enable some development task to be MySQL, DBMS
done automatically or semi-automatically.

2 - 33 2 - 34

How systems methodology helps? How systems methodology helps?

 To record accurately the requirements for an  To produce an information system within 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.
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 - 35 2 - 36

6
 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 What context? You might ask…

the best?
 There is no benefit to be gained from attempting to ____|_______________|_______________|_____
find, in isolation, a “best” methodology. Structured Unstructured

 There should be a search for an appropriate “We have 20 bank branches in Kuala Lumpur; all
methodology in the context of the problems being branches combined there are 5,000 deposits made on each
addressed, the applications and the organization and its working day. We keep details about each deposit, e.g.
culture. customer A/C number, amount deposit, and so on.”

“We need a new web portal to allow customers to

buy groceries online.”
2 - 39 2 - 40

Five different classes of situation

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

7
 Systems Development Life Cycle
(SDLC)
Systems Development  The traditional SDLC is one of the earliest
methodologies to systems development.
Life Cycle  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 Conceptual Framework of SDLC

(SDLC) Stages
 A waterfall model: outputs from one phase feed into
next phase. Analysis
 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 Implementation Design
IS development (Conceptual Framework), i.e. analysis,
design, development and implementation.

Development

2 - 45 2 - 46

Other View of SDLC Stages Other View of SDLC Stages

2 - 47 2 - 48

8
 In this unit, we will follow the one by Shelley SDLC Stages
& Cashman (2010)

 Phases of the SDLC

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

2 - 49 2 - 50

Phases of SDLC
Phases of SDLC
 Systems Analysis
 Systems Planning  To understand how users accomplish their work when
interacting with a computer; and begin to know how to make
 Systems planning phase the new system more useful and usable.
 Systems request – begins the process & describes problems  To understand how the business functions and have
or desired changes complete information on the people, goals, data and
 Purpose of this phase is to perform a preliminary procedure involved
investigation  Learn the who, what, where, when, how, and why of the
current system
 Key part of preliminary investigation is a feasibility study  Fact finding techniques includes:
 Interviewing
 Sampling and investigating hard data
 Output:  Questionnaires

 Feasibility report containing problem definition and objective  Observe the decision maker’s behavior and environment

summaries from which management can make a decision on  Output:

whether to proceed with the proposed project  Deliverable is the System requirements document
2 - 51 2 - 52

Phases of SDLC Phases of SDLC

 Systems Design  Systems Implementation
 Create physical model  New system is constructed
 Design user interface, identify necessary outputs, inputs, and  Programs written, tested, and documented, and the systems is
processes installed
 Design internal/ external controls  Converting to new system
 Determine application architecture  User training

 Output:  Output:
 System design specification  Complete functioning system

2 - 53 2 - 54

9
 Phases of SDLC
 Systems Support & Security
 Maintenance, enhancement and protecting the system occurs A Structured Systems
at this phase
 Maximise return on the IT investment Analysis and Design
 A well-designed system must be secure, reliable, maintainable,
and scalable Method (SSADM)

 Output:
 Operational information systems

2 - 55

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)
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 - 57 2 - 58

SSADM Structure
Areas covered by SSADM Feasibility Study

 Analysis and design of the processing required to

enable the data to be captured, manipulated, stored and Requirements Analysis
then reported on.
 Analysis and design of the interface required to support
the user when working with the new system. Requirements Specification

 First-cut design for the database of the new system and

the physical processes required to access the data.
Logical System
Specification

Physical Design
2 - 59 2 - 60

10
 Major Tools of SSADM
 SSADM adopts the waterfall model of systems  Logical Data Modelling
development, where each stage has to be completed
 Data Flow Modelling
and signed off before subsequent stages can begin.
 SSADM 4+ has seven stages within a five-module  Entity /Event Modelling
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 2 - 62

2 - 63 2 - 64

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 - 65 2 - 66

11