INFORMATION SYSTEM

DEVELOPMENT
OVERVIEW
 Session objectives

▪ Describe the motivation for a system development process in terms of

the Capability Maturity Model (CMM) for quality management.
▪ Differentiate between the system life cycle and a system development
methodology.
▪ Describe eight basic principles of system development.
▪ Define problems, opportunities, and directives—the triggers for systems
development projects.
▪ Describe the PIECES framework for categorizing problems, opportunities,
and directives.
▪ Describe the traditional, basic phases of system development. For each
phase, describe its purpose, inputs, and outputs.
▪ Describe cross life cycle activities that overlap all system development
phases.
▪ Describe four basic alternative “routes” through the basic phases of
system development. Describe how routes may be combined or
customized for differentAPT
projects.
2010 A System Analysis and Design
The Process of Systems Development

A system development process is a set of activities,

methods, best practices, deliverables, and automated
tools that stakeholders use to develop and maintain
information systems and software.
Stakeholders include system owners, system users,
system designers, system builders, system analysts, IT
vendors and consultants.

APT 2010 A System Analysis and Design

 Some definitions
▪ Business Process Management (BPM) - a methodology used by
organizations to continuously improve end-to-end business
processes.
▪ BPM Process
– Defining and mapping the steps in a business process.
– Creating ways to improve on the steps in the process that add value
– Finding ways to eliminate or consolidate steps in the process that do not
add value
– Creating and adjusting electronic workflows to match the improved
process maps.
▪ Business process automation (BPA) – technology components
used to complement or substitute manual process.

APT 2010 A System Analysis and Design

(Some definitions cont’d)
▪ Business process improvement (BPI) – creating new, re-designed processes to improve
the workflows, and/or utilizing new technologies enabling new process structures.
▪ Business process reengineering (BPR) – changing the fundamental way in which the
organization operate.
▪ System Request - The document that describes the business reasons for building a
system and the value that system is expected to provide. The project sponsor usually
completes this form as part of a formal system selection process within the
organization.
▪The business requirements of the project refer to the business capabilities that
the system will need to have.
▪The business value describes the benefits that the organization should expect
from the system.
APT 2010 A System Analysis and Design
 The CMM Process Management Model
The Capability Maturity Model (CMM) is a framework to assess the
maturity level of an organization’s information system development
and management processes and products. It consists of five levels
of maturity as measured by a set of guidelines called the key process
areas.
– Level 1—Initial: System development projects follow no prescribed process.
– Level 2—Repeatable: Project management processes and practices are established
to track project costs, schedules, and functionality.
– Level 3—Defined: A standard system development process (sometimes called a
“methodology”) is purchased or developed, and integrated throughout the
information systems/services unit of the organization.
– Level 4—Managed: Measurable goals for quality and productivity are established.
– Level 5—Optimizing: The standardized system development process is
continuously monitored and improved based on measures and data analysis
established in Level 4.
APT 2010 A System Analysis and Design
Capability Maturity Model (CMM)

RISK
Leve
l 5
OPTIMIZED

Leve
l 4
MANAGED

Leve
l 3
DEFINED

Leve
l 2
REPEATABLE

Leve
l 1
INITIAL
COMPETITIVENES
S
 Principles of System Development

▪ Get the owners and users involved.

▪ Use a problem-solving approach.
▪ Establish phases and activities.
▪ Establish standards.
▪ Justify systems as capital investments.
▪ Don’t be afraid to cancel or revise scope.
▪ Divide and conquer.
▪ Design systems for growth and change.

APT 2010 A System Analysis and Design

 Life Cycle versus Methodology

▪ A system life cycle divides the life of an information system

into two stages, systems development and systems
operation and support.

▪ A system development methodology is a very formal and

precise system development process that defines (as in
CMM Level 3) a set of activities, methods, best practices,
deliverables, and automated tools that system developers
and project managers are to use to develop and maintain
information systems and software.

APT 2010 A System Analysis and Design

A System Life Cycle
Conversion

LIFE CYCLE STAGE LIFE CYCLE STAGE

System Lifetim System

and
Operation
Development
e of a Support
usin
System g
System usin
Information
g Technology
Methodolog
Development
y

Obsolescence
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

APT 2010 A System Analysis and Design

(cont’d)
▪ The SDLC is composed of four fundamental phases:
• Planning
• Analysis
• Design
• Implementation
▪ Each of the phases is composed of steps, which rely on
techniques that produce deliverables (specific documents that
explain various elements of the system).

APT 2010 A System Analysis and Design

 Planning

▪ This phase is the fundamental process of

understanding why an information system should be
built, and determining how the project team will go
about building it.

APT 2010 A System Analysis and Design

 The planning phase has two steps:

1. During project initiation, the system’s business value to the organization is

identified (How will it lower costs or increase revenues?).
2. During project management, the project manager creates a work plan, staffs the
project, and puts techniques in place to help the project team control and direct
the project through the entire SDLC.

APT 2010 A System Analysis and Design

 Analysis

▪ The analysis phase answers the questions of who will use the system, what the
system will do, and where and when it will be used.
▪ During this phase the project team investigates any current system(s), identifies
improvement opportunities, and develops a concept for the new system.

APT 2010 A System Analysis and Design

 The analysis phase has three steps:

1. Analysis strategy: This is developed to guide the projects

team’s efforts. This includes a study of the current system
and its problems, and envisioning ways to design a new
system.
2. Requirements gathering: The analysis of this information
leads to the development of a concept for a new system.
This concept is used to build a set of analysis models.
3. System proposal: The proposal is presented to the project
sponsor and other key individuals who decide whether the
project should continue to move forward.
APT 2010 A System Analysis and Design
 Design

▪ The design phase decides how the system will

operate, in terms of the hardware, software, and
network infrastructure; the user interface, forms,
and reports that will be used; and the specific
programs, databases, and files that will be needed.

APT 2010 A System Analysis and Design

 The design phase has four steps:

1. Design Strategy: This clarifies whether the system will be

developed by the company or outside the company.
2. Architecture Design: This describes the hardware,
software, and network infrastructure that will be used.
3. Database and File Specifications: These documents
define what and where the data will be stored.
4. Program Design: Defines what programs need to be
written and what they will do.

APT 2010 A System Analysis and Design

 Implementation

▪ During the implementation phase, the system is either

developed or purchased (in the case of packaged software) and
installed.
▪ This phase is usually the longest and most expensive part of the
process.

APT 2010 A System Analysis and Design

 The implementation phase has three steps:

1. System Construction: The system is built and tested to make sure it performs
as designed.
2. Installation: The old system is turned off and the new one is turned on.
3. Support Plan: Includes a post-implementation review as well as a systematic
way for identifying changes needed for the system.

APT 2010 A System Analysis and Design

A systems Development Process:

▪ We examine a systems development process based on a hypothetical

methodology called FAST (Framework for the Application of Systems
Techniques) ( Whitten , 2007).
– Types of system projects and how they get started
– Basic FAST phases
– Alternative variations or ‘routes’ through the phases

▪ The past section introduced the four classic phases of the SDLC. The
FAST methodology employs eight phases to better define periodic
milestones and the deliverables.

APT 2010 A System Analysis and Design

A systems Development Process:

Project Identification and Initiation

System users and owners initiate most projects. The impetus

for most projects is some combination of problems,
opportunities and directives
▪ Problems are undesirable situations that prevent the
organization from fully achieving its purpose, goals, and/or
objectives.
▪ Opportunities are chances to improve the organization even in
the absence of specific problems.
▪ Directives are new requirements that are imposed by
management, government, or some external influence.

APT 2010 A System Analysis and Design

 The PIECES Problem-Solving Framework

James Wetherbe (1994) developed a useful

framework (PIECES) for classifying problems.
P the need to improve performance
I the need to improve information (and
data)
E the need to improve economics, control
costs, or increase profits
C the need to improve control or security
E the need to improve efficiency of people
and processes
S the need to improve service to customers, suppliers,
partners, employees, etc.
APT 2010 A System Analysis and Design
 The PIECES Problem-Solving Framework

The following checklist for problem, opportunity, and directive

identification uses Wetherbe's PIECES framework. Note that the
categories of PIECES are not mutually exclusive; some possible problems
show up in multiple lists. Also, the list of possible problems is not
exhaustive. The PIECES framework is equally suited to analyzing both
manual and computerized systems and applications.
PERFORMANCE Problems, Opportunities, and Directives
A. Throughput – the amount of work performed over some period of
time.
B. Response time – the average delay between a transaction or
request and a response to that transaction or request
INFORMATION (and Data) Problems, Opportunities, and Directives
A. Outputs
1. Lack of any information
2. Lack of necessary information
3. Lack of relevant information
4. Too much information – ``information overload''
5. Information that is not in a useful format
6. Information that is not accurate
7. Information that is difficult to produce
 The PIECES Problem-Solving Framework

INFORMATION (and Data) Problems, Opportunities, and Directives

B. Inputs
1. Data is not captured
2. Data is not captured in time to be useful
3. Data is not accurately captured -- contains errors
4. Data is difficult to capture
5. Data is captured redundantly -- same data captured more than once
6. Too much data is captured
7. Illegal data is captured
C. Stored Data
1. Data is stored redundantly in multiple files and/or databases
2. Stored data is not accurate (may be related to #1)
3. Data is not secure to accident or vandalism
4. Data is not well organized
5. Data is not flexible – not easy to meet new information needs from
stored data
6. Data is not accessible
 The PIECES Problem-Solving Framework

ECONOMICS Problems, Opportunities, and Directives

A. Costs
1. Costs are unknown
2. Costs are untraceable to source
3. Costs are too high
B. Profits
1. New markets can be explored
2. Current marketing can be improved
3. Orders can be increased

CONTROL (and Security) Problems, Opportunities, and Directives

A. Too little security or control
1. Input data is not adequately edited
2. Crimes are (or can be) committed against data
a. Fraud
b. Embezzlement
3. Ethics are breached on data or information – refers to data or
information letting to unauthorized people
4. Redundantly stored data is inconsistent in different files or
databases
 The PIECES Problem-Solving Framework

CONTROL (and Security) Problems, Opportunities, and Directives

A. Too little security or control (continued)
5. Data privacy regulations or guidelines are being (or can be)
violated
6. Processing errors are occurring (either by people, machines, or
software)
7. Decision-making errors are occurring
B. Too much security or control
1. Bureaucratic red tape slows the system
2. Controls inconvenience customers or employees
3. Excessive controls cause processing delays

EFFICIENCY Problems, Opportunities, and Directives

A. People, machines, or computers waste time
1. Data is redundantly input or copied
2. Data is redundantly processed
3. Information is redundantly generated
B. People, machines, or computers waste materials and supplies
C. Effort required for tasks is excessive
D. Materials required for tasks is excessive
 The PIECES Problem-Solving Framework

SERVICE Problems, Opportunities, and Directives

A. The system produces inaccurate results
B. The system produces inconsistent results
C. The system produces unreliable results
D. The system is not easy to learn
E. The system is not easy to use
F. The system is awkward to use
G. The system is inflexible to new or exceptional situations
H. The system is inflexible to change
I. The system is incompatible with other systems
J. The system is not coordinated with other systems
 Exercise 1

APT 2010 A System Analysis and Design

FAST System Development Phases
 Project Phases

▪ Preliminary investigation phase

🖫 Purpose:
🖰 The purpose of the survey phase is threefold.
• The survey phase answers the question, “Is this project worth
looking at?”
• The survey phase must define the scope of the project and the
perceived problems, opportunities, and directives that triggered
the project.
• The survey phase must establish the preliminary requirements
and constraints, project team and participants, the project
budget, and the project schedule.
▪ Ultimately, this phase concludes with a ‘go or no-go’ decision
from system ownersAPT 2010 A System Analysis and Design
 Project Phases:

Preliminary investigation cont.

🖰 A key deliverable for the survey phase is a project charter that presents the
findings, recommendations, and plans of the team to the executive sponsors.
• This might be a report or verbal presentation; possibly both.
– The report version is sometimes called an initial study report.
• The analyst's recommendation may prescribe:
– a ``quick fix,''
– an enhancement of the existing system and software
– a completely new information system.
• For the latter possibility, a statement of project scope and objectives is delivered to the problem
analysis phase.

APT 2010 A System Analysis and Design

 Project Phases

▪ Problem analysis phase- provides for a study and analysis of

the existing system – more thorough understanding of the
problems that triggered the project.
🖫 Deliverables
🖰 The findings of the study phase are reviewed with the
system owners as a business problem statement and
feasibility analysis (sometimes called a detailed study
report).
• The problem statement may take the form of a formal written report, an
updated feasibility assessment, or a formal presentation to management
and users.
• The problem statement should include system improvement
objectives. These objectives define the business criteria on which any
new system will be evaluated.
APT 2010 A System Analysis and Design
 Project Phases

–
▪ Requirements analysis phase defines and prioritizes the
business requirements. The analyst approaches the users to
find out what they need or want out of the new system. Errors
and omissions result in user dissatisfaction with the final
system and costly modifications.
🖰 The purpose of requirements analysis is to identify the
data, process, interface, and geographic requirements for
the users of a new system.
• Specify these requirements without expressing computer alternatives and
technology details; at this point, keep analysis at the business level
▪ The deliverable of this phase is a business requirements
statement .
– The requirements statement
APT 2010 becomes the and
A System Analysis trigger
Design for systems design.
 Project Phases

–
▪ Decision Analysis Phase given the business requirements
statement, there are usually numerous alternative ways to design
a new information system to fulfill those requirements. This phase
identifies candidate solutions, analyzes them for feasibility and
recommends a candidate system as the target solution to be
designed. This candidate is evaluated by the following criteria:
• Technical feasibility. Is the solution technically practical? Does our staff
have the technical expertise to design and build this solution?
• Operational feasibility. Will the solution fulfill the user's requirements? To
what degree? How will the solution change the user's work environment?
How do users feel about such a solution?
• Economic feasibility. Is the solution cost-effective (as defined earlier in the
chapter)?
• Schedule feasibility. Can the solution be designed and implemented within
an acceptable time period?
⮚ The key deliverable of the targeting
APT 2010 phase
A System is a formal
Analysis systems proposal to systems
and Design
owners.
 Project phases
Design phase – is concerned with technology based views of the
system’s data, processes and interfaces.
🖰 The purpose of the design phase is to transform the business
requirements from the definition phase into a set of technical
design blueprints for construction.
– A project is rarely cancelled after the design phase unless it is hopelessly
overbudget or behind schedule.
▪ Deliverables
🖰 The final deliverable is a technical set of design specifications.
• Design specifications can take several forms, but the most common approach is
modeling.
• General design models will depict:
– The structure of the database.
– The structure of the overall application.
– The overall ‘look
APTand
2010 feel’ ofAnalysis
A System the user interface.
and Design
 Project Phases

▪ Construction phase – The purpose of the construction phase is to build and test a
functional system that fulfills business and design requirements
▪ System components are built. The components are tested individually and then
linked and tested again to ensure that they hang together properly without causing
the system to crash.

🖫 Deliverables
🖰 The final deliverable of the construction phase is the functional system.

APT 2010 A System Analysis and Design

 Project phases

▪ Implementation phase – delivers the production system

into operation. The analyst must provide for a smooth
transition from the old to new system, and help users cope
with normal start-up problems. This phase also involves
training individuals that will use the final system and
developing documentation to aid system users.

APT 2010 A System Analysis and Design

 Project Phases

▪ Operation and support stage – Once the system is placed into

production, the analyst's role changes to systems support.
🖰 System support is the ongoing maintenance of a system
after it has been placed into operation. This includes
program maintenance and system improvements.
🖰 Systems support doesn't consist of phases so much as it does
ongoing activities. These activities include:
• Fixing software ‘bugs’.
• Recovering the system.
• Assisting users.
• Adapting the system to new requirements.

▪ Eventually, we expect the user feedback and problems to

indicate that it is timeAPT
to2010
start over
A System Analysisand reinvent the system.
and Design
Overlap of System Development Phases

200 200
ID Task Name 1 2
May Jun Jul Aug Sep Oct Nov Dec Jan
1 Project management
2 Preliminary investigation
3 Problem analysis
4 Requirements analysis
5 Decision analysis
6 Design
7 Construction
8 Implementation
9 Operations and support
 Cross Life Cycle Activities

Cross life cycle activities are activities that overlap many or all
phases of the methodology .
🖰 fact finding
🖰 documentation and presentation
🖰 estimation and measurement
🖰 feasibility analysis
🖰 project management
🖰 process management.

APT 2010 A System Analysis and Design

Sequential vs Iterative Development approach
▪ The sequential approach as depicted in the SDLC and FAST methodology requires
each phase be ‘completed’ one after the other until the information system is
finished. This approach is sometimes called the waterfall development approach
▪ An approach that is increasingly gaining popularity is the iterative development
approach, or incremental development process.
▪ This approach requires completing enough analysis, design and implementation
to develop a part of of the system and place it into operation, then perform
additional analysis, design and implementation to release the next version, and
this continues until all parts of the entire IS have been implemented
▪ This allows versions of useable IS to be delivered in regular and shorter time
frames as opposed to the time taken using the waterfall approach, which may
result in improved customer (system owner and user) satisfaction
APT 2010 A System Analysis and Design
The sequential or waterfall model

APT 2010 A System Analysis and Design

The iterative or incremental strategy

APT 2010 A System Analysis and Design

 Alternative Routes through a Methodology

▪ Model-Driven Development (MDD)

▪ Rapid Application Development (RAD)
▪ Commercial Off-the-Shelf Software (COTS)

or hybrids of the above

APT 2010 A System Analysis and Design

 Model-Driven Development Route

▪ Modeling is the act of drawing one or more graphical

representations (or pictures) of a system. Modeling is a
communication technique based upon the old saying, “a picture is
worth a thousand words.”
▪ Model-driven development techniques emphasize the drawing of
models to help visualize and analyze problems, define business
requirements, and design information systems.
Advantages?
Disadvantages?

APT 2010 A System Analysis and Design

Model-Driven Development (MDD)
Route
 Rapid Application Development Route

▪ Rapid application development (RAD) techniques emphasize

extensive user involvement in the rapid and evolutionary
construction of working prototypes of a system to accelerate the
system development process.

RAD is based on building prototypes that evolve into finished

systems (often using time boxing)
– A prototype is a smaller-scale, representative or working model of the
users’ requirements or a proposed design for an information system.
– A time box is a nonextendable period of time, usually 60-120 days, by
which a candidate system must be placed into operation.

APT 2010 A System Analysis and Design

 Rapid Application Development Route

RAD Basic ideas

▪ To more actively involve system users in the analysis, design and
construction activities
▪ To organize system development into a series of focused, intense
workshops jointly involving system owners, users, analysts,
designers and builders
▪ To accelerate the requirements analysis and design phases
through an iterative construction approach
▪ To reduce the amount of time until the users begin to see a
working system
Advantages?
Disadvantages? APT 2010 A System Analysis and Design
 Commercial Off-the-Shelf Software Route

▪ Commercial off-the-shelf (COTS) software is a software package

or solution that is purchased to support one or more business
functions and information systems.
Packaged software solutions must be carefully selected to fulfil
business needs. They are not only costly to purchase, but can also
be costly to implement. They might usually be customized for and
integrated into the business, or may require the redesign of
existing business processes to adapt to the software.

Advantages?
Disadvantages?
APT 2010 A System Analysis and Design
Automated Tools and Technology: Computer-Aided
Systems Engineering (CASE)

🖳 What is Computer-Aided Systems Engineering?

🖫 Computer-aided systems engineering (CASE) is the application
of information technology to systems development activities,
techniques, and methodologies. CASE tools are programs
(software) that automate or support one or more phases of a
systems development life cycle. The technology is intended to
accelerate the process of developing systems and to improve the
quality of the resulting systems.
🖫 CASE is not a methodology or an alternative to methodologies.
🖫 CASE is an enabling technology that supports a methodology’s
preferred strategies, techniques, and deliverables.

APT 2010 A System Analysis and Design

 Exercise 2

APT 2010 A System Analysis and Design