ISEM2005

Management Information
Systems
Building Information Systems
Outline of the Lesson

• Understand the concept of development of Information

System.
• Describe the steps involved in the system development
life cycle.
• Understand the difference between the classic and the
agile approach in the system development life cycle.
• How to decide which SDLC approach should be used
in an IS development project?

2
Image you are asked to create a new
model of car

3
How can we avoid this
problem?

4
What you need to
think of?

• Why are you building

it?
• How it should be built
to achieve its
purpose?
Planning
• The cost to build it?
• ..

5
 Analysis
• What is the customer looking for?
What you • Kind of features?
need to think
• How to operate?
of?
• ….

6
 Design
What you need • Design the blueprint of the car
to think of? • functions, interior, exterior
• Components to be used in the car
• ….
7
What you
need to
Building
think of? and Testing

8
 Maintenance
What you need to think of?

9
Building your
Information
System
Information
System (IS) is
used to support
Operation
Management
and Decision
Making in an
organization.

10
Different type of Information System

• Decisions Support System

• Transaction Processing System
• Management Information System

11
Why initiates an Information System
Development Project?
• Automation
• Increases efficiency
• Replaces manual tasks
• Business process redesign
• Analyze, simplify, and redesign business processes
• Reorganize workflow, combine steps, eliminate
repetition
• Paradigm shifts
• Define new business model
• Change nature of organization
12
Example - Business Process
Redesign
Steps in Business Process Redesign
1. Identify processes for change
2. Analyze existing processes
3. Design the new process
4. Implement the new process
5. Continuous measurement

13
Business Process for Purchasing a
Book from a Physical Bookstore

14
Redesigned Process for Purchasing a
Book Online

15
What is Information System
Development Process
• The information system development process
involves with many different activities.
• Activities are grouped into phases, collectively
called the system development life cycle.
• There are different types of system development
life cycle methodologies used such as:
• Waterfall
• Agile

16
Information System Development

• A system development life cycle defines different stages

that are necessary to bring a project from its initial idea
all the way to deployment and later maintenance.
• Planning
• Analysis
• Design
• Development
• Testing
• Implementation (Deployment)
• Maintenance
17
Planning Phase
• Start with a planning phase
• Define the problem and scope of an existing system
and determine objective of the new system

18
Planning Phase
• Why is the information system being developed?
• Is this a new system, or is it an upgrade or extension of an
existing system?
• Who are the system’s current and future users?
• What does it need to be completed and when?
• How to get the funding and resources to make it happens?
At the end:
• A clear view of what the problem is and how the information
system will solve the problem
• Project Manager create a Project Plan

Source: https:/ /www.youtube.com/watch?v=shNOYFlmBOU

19
Who/What are involved in the Planning
Phase
• Task force with both internal and external users
• Project sponsor and Project Manager
• Feasibility Study
• Technical
• Operational
• Schedule (time and resources)
• Cost vs Benefit
• Tangible and intangible
• Opportunity cost

20
Analysis Phase

• Analysis of problem and generate alternatives for solving it

• Interview users who initiated the requests
• Study how current system works
• Determine users’ wants, needs and requirements
• Interviews, surveys and observations
• Determine what new system should do (process analysis) and
what data is needed for this process (data analysis)

At the end:
Business Analysts produce document with all requirements

21
Design Phase
The design phase consists of two major activities
• Designing the IT Infrastructure
• Identify the technical specifications
• Solicit vendor proposals
• Test and evaluate vendor proposals
• Make a decision
• Describes all the details (specifications) that will deliver
functions identified during analysis phase
• E.g. user interaction (UI) interface, data models, entity relationship
diagrams (ERDs)
At the end:
The Architect/Solution designer produces the design documents
• Conceptual design, logical design and the physical design
22
Design Phase

• Role of end users in Design Phase

• User information requirements drive system building
• Insufficient user involvement in design effort is major cause of
system failure

• Prototyping
• Building experimental system rapidly and inexpensively for
end users to evaluate
• Preliminary version of information system
• Approved prototype serves as template for final system

23
 Design Phase
System Specification

Category Specifications

Output Medium, Content, Timing

Input Origins, Flow, Data entry
User Interface Simplicity, Efficiency, Logic, Feedback, Errors
Database Design Logical data model, Volume and speed requirements, File
organization and design, Record specifications
Processing Computations, Program modules, Required reports, Timing of
outputs
Manual Procedures What activities, Who performs them, When, How, Where
Controls Input controls (characters, limit, reasonableness), Processing
controls (consistency, record counts), Output controls (totals,
samples of output), Procedural controls (passwords, special forms)

24
 Design Phase
System Specification
Category Specifications

Security Access controls, Catastrophe plans, Audit trails

Documentation Operations documentation, Systems documents, User
documentation
Conversion Transfer files, Initiate new procedures, Select testing method
Cut over to new system
Training Select training techniques, Develop training modules, Identify
training facilities
Organizational Changes Task redesign, Job redesign, Process design, Organization structure
design, Reporting relationships

25
RFP and bids

• Request for Proposal (RFP)

• A written document with detail specifications that is used to
request bids for equipment, services, and supplies from
vendors.
• Require tremendous time involved in preparing, writing and
evaluation proposals

• Why RFP:
• All vendors get the same information and requirements so
bids can be evaluated more fairly

26
Development Phase

System specifications from design stage are

translated into a real system
• Development of the IT infrastructure
• Procure hardware and software
• Configure the system components

• Development of of database and application code

• Database design
• Programming and coding
• Database administrator, UI developers, backend developers, etc.

27
Insourcing and Outsourcing

• Insourcing: an
organization’s own team
develop the system
internally.
• Outsourcing: organization
hires an external vendor or
consultant who specializes
in providing development
services

28
Testing Phase

Ensure the system produces right results

• Developing a Test plan by the testing team
• Writing a series of test cases
• Execution of test cases
• Unit testing: Tests each program in system separately
• System testing: Test functioning of system as a whole
• User Acceptance testing: verify that the system works
for the users. UAT are executed against test scenarios
defined/agreed by the users.
29
Deployment (Implementation) Phase

• When the system is ready to be deployed for production

use, designers have several options:
• Parallel Conversion
• Old system and new system run continuous for a short period of time
• Phased-in/Phased-out
• As each module of new system is converted, the corresponding part of
the old system is retired
• Direct cut-over
• Old system is stopped, and new system is implemented
• Pilot
• Introduce system to a limited area of an organization (a department, a
division, etc.)

30
Maintenance Phase

• Assess how the system is

working and takes step to
keep the system up and
running
• If objective not met, take
corrective action

• Maintenance can lead to

starting the cycle over at
the planning phase.

31
Maintenance Phase

Maintenance is unavoidable
• correct errors (bugs)
• meet new requirements, or
• improve processing efficiency
• 20 percent debugging
• 20 percent changes to hardware, software, data, reporting
• 60 percent of work: user enhancements, improving
documentation, recoding for greater processing efficiency

32
 System Development Life Cycle (Waterfall
Approach)

DEVELO P M E N T

Source: https:/ /plan.io/blog/software-development-process/

33
 Milestones and Tasks

Division of
Labor

34
Sample

35
 System Analysis and Design Report

• Management Summary
• Current Environment
• Requirement Specification
• System Specification
• Technical System Option

https://www.ogcio.gov.hk/en/our_work/infrastructure/methodology/system_development/effective_guide.html

36
Management Summary

• The main objectives of this project are to:

• streamline the operation of the current library system.
• enhance the system architecture and the interoperability
…
• Background
• In the Government, library management functions are
mostly practised in manual ways with the aid of various
computer systems. For those libraries that implemented
individual systems to streamline their workflow, the
systems are typically used for keeping record….

37
Current System Description

The current system allows Users to borrow books, who must first
manually search if there are any available stocks. The User then must
display their library card to a Librarian, who will then issue the book…
38
 Current Business Process (Borrow Book)

Problems and issues:

• User must be able to
display their Library
Member Card to
Librarian before
having the book
issued to them.
• Current system does
not support e-book

39
Proposed System
The proposed IT system will enable Users to sign into the library system
using their mobile application, and where they can search for their desired
book and immediately see if there is any stock available. If the book is
available and not reserved, and the User has no outstanding fines, the
librarian will issue the book to the User…

Use Case Diagram:

• “I need to login into the
Library Booking System.”
• “I need to check and
update the database by
adding a book”
• “I need to provide
feedback such as
comments or rating for
the book”
40
Future Business Process
BP-001 Borrow book

41
System Specification – Function Definition

42
User Experience Design

43
Prototype

44
Key Takeaway about Waterfall Approach

• Structured process for developing high quality information

systems within a project scope
• Phased approach
• Divided the project into formal stages and next stage cannot start before
the previous stage finishes
• Formal division of labour
• End-users may only need to be involved heavily in the early initial
planning/analysis phases and at the delivery phase.
• Project team members (e.g. business analysts, testers) only need to be
available for their specific project phases.
• Strong focus on documentation
• Who it’s for: Teams with rigid structures and documentation needs.
• Who it’s not for: Testing a new product, need user feedback mid-
stream
45
Limitation of Waterfall approach in Information
System Development
• The process of “plan, design, build, test, deliver,” works
okay for making cars but may not be good for creating
information systems in today’s dynamic business
environment

46
Waterfall development approach

Waterfall approach is not effective in situations such

as:
• Lack of detailed requirements from users at the beginning
of the project
• Input-output process cannot be identified completely
• Users’ requirements keep changing

• Problem is ad hoc

Any other Approach in

SDLC?
47
Agile Development Approach
• Responding to change over following a plan
• Focus on producing a working product instead of
comprehensive documentation
• Customer communication, collaboration and feedback
during the entire course of development
• The product development is divided into small parts
• reduce risks and respond to required changes quickly
• Different Agile frameworks:
• Scrum, eXtreme Programming (XP), Kanban, etc.

48
Four central tenets

49
What is Scrum

• Scrum is an Agile framework

• helps teams to effectively address the moving target and
uncertainties

• Scrum uses incremental, iterative sequences of work

that are commonly referred to as “sprints.”
• A sprint is a set period of time during which specific work has
to be completed and made ready for review.

• Each sprint is required to deliver a potentially shippable product

increment.

50
 Roles in Scrum
Product Owner: key roles in Scrum, responsible for
maximizing the business value delivered by the
team (ROI)
• Establish and communicate the product
vision to the team
• Monitor the project against its ROI goals
Make decisions about when to create an
official release
ScrumMaster: responsible for facilitating the Scrum
process and ensuring the team is delivering value
• assure that the team is fully functional and
productive
• remove any obstacles
• organize the Scrum ceremonies.
The team: responsible for turning the product
backlog items into increments of value in each
sprint
• cross-functional, 7 – 9 members
• Programmers, designers, testers, architect
• collaborative, committed, self organizing 51
Product Backlog

• A prioritized features list for the products to be developed

• containing short descriptions of all functionality desired in the
product.
• Maintained by the Produce Owner
• Features are expressed in the form of user stories
• As a < type of user >, I want < some goal > so that < some
reason >.
• As a user, I can indicate folders not to backup so that my backup
drive isn't filled up with things I don't need saved.
• As a shopper, I can review the items in my shopping cart before
checking out so that I can see what I've already selected.

52
Scrum
Process
• A product owner makes a
prioritized wish list known as a
product backlog.
• The scrum team takes one
small piece of the top of the wish
list called a sprint backlog and
plans to implement it.
• The team completes their sprint
backlog task in a sprint (a 2-4
weeks period). They assess
progress in a meeting called
a daily scrum.
• The ScrumMaster keeps the
team focused on the goal.
• At the sprint’s end, the work is
ready to ship or show.
• The team closes the sprint with
a review, then starts a new
sprint.
53
Agile Scrum Framework

54
Source: http:/ /exploreselenium.com/others/agile-process-and-terminology/
 • Bill meets with a customer to discuss her company’s
Scrum uses needs. Those needs (say, X, Y and Z) are the product
incremental, backlog. Bill chooses the most important task (X) to work
on in the next two weeks.
iterative work • His team meets in a daily scrum to target work for the day
sequences ahead and address roadblocks.

called sprints • At the end of the sprint, Bill delivers the work (X), reviews
the backlog (Y & Z)), and sets the goal for the next sprint.
• The cycle repeats until the software is complete. 55
The Four Scrum Events (Ceremonies)

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Create UI (4 hrs) What did I complete Show & Tell What worked well?
Code (6 hrs) yesterday? What could be
Unit Test (2 hrs) What am I working on improved?
UAT (2 hrs. today? What will we commit to
What is slowing me the next Sprint
down?

56
 • The three roles:
• Product Owner
• Scrum Master and
Agile • Scrum Team Member

Scrum • The Product Backlog

• Sprints Backlog
Framework • The four scrum ceremonies:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
57
Key takeaways about Sprint in Scrum

• Begin with sprint planning to outline goals in

the sprint
• Push out smaller features at a time
• Business needs can change sprint goals
• The end of a sprint results in a new and
functional iteration of the product

58
Omakase Style
59
Minimal Viable Product (MVP)

Basic Navigation Entertainment Exterior

Facilities Facilities Finishing

MVP simply means: the most minimally featured thing

you can build that will address the opportunity well
enough for most of your target customers and validate
your market and product.
60
Changing requirement in the middle of sprint

61
 Difference between traditional and agile system
development methodology
Characteristics Agile approach Traditional approach

Organizational structure Iterative Linear

Scale of projects Small and medium scale Large-scale

Clearly defined before

User requirements Interactive input
implementation
Involvement of clients High Low
Evolutionary delivery
Development model Life cycle (Full Product)
(MVP)
Customers get involved
Customers are involved
early in the project but
Customer involvement from the time work is
not once the execution
being performed
has started
Source: https://www.proofhub.com/articles/traditional-vs-agile-project-management
62
Waterfall vs Agile

Gaming Application Healthcare Application

Small Updates Quality vs Speed
Get them out fast It has to work

63