INTRODUCTION TO SYSTEM
DEVELOPMENT LIFE CYCLES
WHAT IS AN INFORMATION SYSTEM
(IS)?
Hardware, software, data,
people, and procedures that
work together to produce
quality information
System—Set of components
that interact to achieve
common goal
Businesses use many types of
systems
WHAT ARE THE PHASES OF THE SYSTEM
DEVELOPMENT CYCLE?
Phase 2. Analysis

Phase 1. Planning




Review project requests
Prioritize project
requests
Allocate resources
Identify project
development team

Conduct preliminary investigation
Perform detailed analysis activities:
Study current system
Determine user requirements
Recommend solution
Phase 5. Support



Conduct post-implementation
system review
Identify errors and enhancements
Monitor system performance
Phase 3. Design


Phase 4. Implementation




Develop programs, if necessary
Install and test new system
Train users
Convert to new system
Acquire hardware
and software, if
necessary
Develop details of
system
WHO PARTICIPATES IN THE SDLC?
WHAT IS A SYSTEMS ANALYST?
Responsible for designing
and developing
information system
Liaison between users
and IT professionals
WHAT IS THE PROJECT TEAM?
Formed to work on project from beginning to end
Consists of users, systems analyst, and other IT professionals
Project leader—one member of the team who
manages and controls project budget and schedule
WHAT IS FEASIBILITY?
Operational
feasibility
Measure of
how suitable
system
development
will be to the
company
Four feasibility
tests:
Schedule
feasibility
Economic
feasibility
(also called
cost/benefit
feasibility)
Technical
feasibility
WHAT IS DOCUMENTATION?
Collection and summarization
of data and information
Includes reports, diagrams,
programs, and other deliverables
WHY CREATE (OR MODIFY) AN
INFORMATION SYSTEM?
To correct problem
in existing system
To improve
existing system
Outside group may
mandate change
Competition can
lead to change
WHAT IS A REQUEST FOR
SYSTEM SERVICES?

Formal request for
new or modified
information system

Also called
project request
PLANNING PHASE
Begins when steering committee receives project request
Steering
committee—
decision-making
body for the
company
Function of committee:
Review and
approve project
requests
Prioritize
project requests
Allocate
resources
Form project
development
team for each
approved
project
ANALYSIS PHASE
Conduct preliminary
investigation, also
called feasibility
study
Perform detailed
analysis
PRELIMINARY INVESTIGATION

Determine exact nature of problem or improvement
and whether it is worth pursuing

Findings are presented in feasibility report, also known as a feasibility study
DETAILED ANALYSIS
1. Study how current system
works
2. Determine user’s wants, needs,
and requirements
3. Recommend solution
Sometimes called logical design
SYSTEM PROPOSAL
Assesses
feasibility
of each
alternative
solution
Recommends
the most
feasible
solution for
the project
Presented to
steering
committee,
which decides
how system will
be developed
IDENTIFY POSSIBLE SOLUTIONS
Buy packaged software—prewritten
software available for purchase
Write own custom software—software
developed at user’s request
Outsource—have outside source
develop software
Horizontal market
software—meets
needs of many
companies
Vertical market
software—designed
for particular industry
DESIGN PHASE
Acquire hardware and software
Develop all details of new or
modified information system
ACQUISITION
What is needed to acquire new hardware and software?

Identify all hardware and software requirements of new
or modified system
Talk with other
systems analysts
Surf Web
Visit vendors’ stores
Read print and online
trade journals,
newspapers, and
magazines
HOW TO TEST SOFTWARE PRODUCTS?





References from vendor
Talk to current users of product
Product demonstrations
Trial version of software
Benchmark test measures performance
DETAILED DESIGN
Detailed design specifications for components in proposed solution
Includes several activities
Database
design
Input and
output design
Program
design
PROTOTYPING TOOLS/METHODS:
MOCKUP

Sample of input or output that contains actual data
PROTOTYPING TOOLS/METHODS:
PROTOTYPE
Working model of
proposed system
Beginning a prototype
too early may lead to
problems
PROTOTYPING TOOLS/METHODS:
CASE

CASE (Computer-Aided Software Engineering) tools
support activities of the SDLC
IMPLEMENTATION PHASE

Purpose is to construct, or build, new or modified
system and then deliver it to users
Convert to new system
Train users
Install and test new system
Develop programs
TESTING
Three kinds of tests performed by system developers:
Unit Test
Systems test
Verifies each
individual program
works by itself
Verifies all programs
in application work
together
Integration Test
Verifies application
works with other
applications
TRAINING

Showing users exactly how they will use new
hardware and software in system
SUPPORT PHASE

Providing ongoing assistance after the system is
implemented
Conduct post-implementation system review—meeting to find out if
information system is performing according to expectations
Identify errors
Identify enhancements
Monitor system performance
FEASIBILITY
Every organization which performs system
development, or has it done for them, needs a
way to choose which projects are worth
the effort
 Feasibility study is a common approach to make
such decisions thoughtfully
 Basis for feasibility study is generally the
problems and opportunities analysis

PROBLEMS & OPPORTUNITIES

We can look for problems and opportunities in
many parts of our organization, and the existing
systems which are supported
Track maintenance costs for existing systems
 Measure existing processes to determine their cost,
and compare to industry standards
 Monitor availability of support for existing
system components
 Look for signs of unhappy employees

PROBLEMS & OPPORTUNITIES
Check quality of work products (outputs)
 Listen to customers, vendors, and suppliers


Both complaints and suggestions
Measure customer satisfaction
 Monitor competitor’s offerings and plans
 Monitor changes in technology which could help
 Don’t forget obvious measures of success, like sales,
profit, or number of contracts awarded

PROJECT SELECTION
Selection of projects is based on many factors –
cost, urgency, the systems
affected, etc.
 From the organization’s perspective, choosing
projects is kind of like shopping


There’s generally a limited amount of funds
and people available to work on the possible projects,
and management needs to choose which projects to
support
PROJECT SELECTION

There are five typical requirements for a project
to be supported





Management support for the project
Appropriate timing of commitment to the project
Relevance to helping meet organizational goals
Project must be practical and feasible
Project must be worthwhile compared to other
possible expenditures

Are we getting enough ‘bang for our buck?’
PROJECT OBJECTIVES

Based on the problems and opportunities
identified for a project, we can set objectives for
the project


These not only help the feasibility study which
follows, but set goals against which we can later test
the system
Objectives should not only address the type of
improvement sought, but set a desired level of
improvement
PROJECT OBJECTIVES

Examples of objectives might include






Improve customer satisfaction 10% within 1 year
Reduce the response time for customer complaints by
15%
Get a new feature to market before competitors
Reduce error rate for data entry from 2% to 0.5%
Improve sales to new customers by 5%
Reduce voluntary employee turnover by 10%
FEASIBILITY ANALYSIS

Feasibility consists of several types we want to
assess for each candidate project

Technical feasibility
Can the project be done with existing technology?
 Are people available to use the technologies needed?


Economic feasibility
How much does the system cost to develop? Maintain? How
long will it be usable?
 Some add schedule feasibility – how long will it take
to create the system?

FEASIBILITY ANALYSIS

Operational feasibility
What impact will the new system have on how we do
business? Will there be changes to where or how processes
are performed?
 Will there be changes to employee skills needed? Changes
to employee training?
 Are existing users amenable to a new system?


These types of feasibility can be measured for
each project, and compared to determine which is
most feasible
FEASIBILITY ANALYSIS
Like voting or buying a car, feasibility analysis is
rarely completely logical or quantifiable
 Many other issues can also affect it

Political climate
 State of the US and/or global economy
 Preferences of the decision makers – favored vendors,
technologies, types of projects, etc.

PLANNING ACTIVITIES
To help structure development activities, we use
a life cycle model to identify the major sets of
activities, called life cycle phases
 There are many kinds of life cycle models

The Waterfall model is the oldest, and uses phases
like Requirements Analysis, High Level Design, Low
Level Design, Coding, and Testing
 The Rational Unified Process has Inception,
Elaboration, Construction, and Transition phases

PLANNING VIA THE SDLC
Each life cycle phase is broken down into more
and more specific activities, until
the time needed for each activity can be reliably
estimated
 Then the tasks are put into a Gantt chart or Pert
chart to show when they occur relative
to each other


Tasks might occur sequentially, have to start
or end together, or wait for some other tasks
to be completed
PLANNING VIA THE SDLC

Tasks for a project often include the acts of creating
specific documents or work products, approving
things or making decisions; such as
‘Prepare system test plan’
 ‘Approve system release’
 ‘Conduct user satisfaction survey’
 ‘Approve system requirements specification’


So the life cycle model provides guidance on the
types of activities needed, but the tasks provide
authority for people to do them
WATERFALL MODEL
FEATURES OF A WATERFALL MODEL
A waterfall model is easy to follow.
 It can be implemented for any size project.
 Every stage has to be done separately at the right time
so you cannot jump stages.
 Documentation is produced at every stage of a
waterfall model allowing people to understand what
has been done.
 Testing is done at every stage.

ADVANTAGES OF A WATERFALL MODEL
Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost
or schedule

DISADVANTAGES OF A WATERFALL MODEL
All requirements must be known up front
 Deliverables created for each phase are considered
frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system
(until it may be too late)

WHEN TO USE THE WATERFALL MODEL
Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.

AGILE SDLCS
Speed up or bypass one or more life cycle phases
 Usually less formal and reduced scope
 Used for time-critical applications
 Used in organizations that employ disciplined
methods

AGILE MANIFESTO
SOME AGILE METHODS
 Adaptive
Software Development (ASD)
 Feature Driven Development (FDD)
 Crystal Clear
 Dynamic Software Development Method
(DSDM)
 Rapid Application Development (RAD)
 Scrum
 Extreme Programming (XP)
 Rational Unify Process (RUP)
EXTREME PROGRAMMING - XP
For small-to-medium-sized teams developing
software with vague or rapidly changing
requirements
Coding is the key activity throughout a software
project
 Communication among teammates is done with
code
 Life cycle and behavior of complex objects defined
in test cases – again in code
XP PRACTICES (1-6)
1.
2.
3.
4.
5.
6.
Planning game – determine scope of the next release
by combining business priorities and technical
estimates
Small releases – put a simple system into
production, then release new versions in very short
cycle
Metaphor – all development is guided by a simple
shared story of how the whole system works
Simple design – system is designed as simply as
possible (extra complexity removed as soon as found)
Testing – programmers continuously write unit
tests; customers write tests for features
Refactoring – programmers continuously restructure
the system without changing its behavior to remove
duplication and simplify
XP Practices (7 – 12)
7.
8.
9.
10.
11.
12.
Pair-programming -- all production code is written
with two programmers at one machine
Collective ownership – anyone can change any code
anywhere in the system at any time.
Continuous integration – integrate and build the
system many times a day – every time a task is
completed.
40-hour week – work no more than 40 hours a week
as a rule
On-site customer – a user is on the team and
available full-time to answer questions
Coding standards – programmers write all code in
accordance with rules emphasizing communication
through the code
XP is “extreme” because
Commonsense practices taken to extreme levels







If code reviews are good, review code all the time (pair
programming)
If testing is good, everybody will test all the time
If simplicity is good, keep the system in the simplest design that
supports its current functionality. (simplest thing that works)
If design is good, everybody will design daily (refactoring)
If architecture is important, everybody will work at defining and
refining the architecture (metaphor)
If integration testing is important, build and integrate test
several times a day (continuous integration)
If short iterations are good, make iterations really, really short
(hours rather than weeks)
SUMMARY
This has been a (very) quick tour through the life
cycle of a system.
 You will have to do—to some extent—all of these
activities for your project.
