The document provides an overview of system development life cycles and related concepts. It discusses the phases of the system development cycle including planning, analysis, design, implementation, and support. It also describes key roles like the systems analyst and project team. Common methodologies like waterfall and agile approaches are introduced.

1. INTRODUCTION TO SYSTEM
DEVELOPMENT LIFE CYCLES

2. 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

3. WHAT ARE THE PHASES OF THE SYSTEM
DEVELOPMENT CYCLE?
Phase 1. Planning
Phase 2. Analysis
Phase 3. Design
Phase 4. Implementation
Phase 5. Support
 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
 Acquire hardware
and software, if
necessary
 Develop details of
system
 Develop programs, if necessary
 Install and test new system
 Train users
 Convert to new system
 Conduct post-implementation
system review
 Identify errors and enhancements
 Monitor system performance

4. WHO PARTICIPATES IN THE SDLC?

5. WHAT IS A SYSTEMS ANALYST?
Responsible for designing
and developing
information system
Liaison between users
and IT professionals

6. WHAT IS THE PROJECT TEAM?
Consists of users, systems analyst, and other IT professionals
Formed to work on project from beginning to end
Project leader—one member of the team who
manages and controls project budget and schedule

7. WHAT IS FEASIBILITY?
Measure of
how suitable
system
development
will be to the
company
Operational
feasibility
Schedule
feasibility
Four feasibility
tests:
Technical
feasibility
Economic
feasibility
(also called
cost/benefit
feasibility)

8. WHAT IS DOCUMENTATION?
Includes reports, diagrams,
programs, and other deliverables
Collection and summarization
of data and information

9. WHY CREATE (OR MODIFY) AN
INFORMATION SYSTEM?
Competition can
lead to change
To improve
existing system
Outside group may
mandate change
To correct problem
in existing system

10. WHAT IS A REQUEST FOR SYSTEM
SERVICES?
 Formal request for
new or modified
information system
 Also called
project request

11. 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
Allocate
resources
Form project
development
team for each
approved
project
Prioritize
project requests

12. ANALYSIS PHASE
Conduct preliminary
investigation, also
called feasibility
study
Perform detailed
analysis

13. 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

14. DETAILED ANALYSIS
Sometimes called logical design
2. Determine user’s wants, needs,
and requirements
3. Recommend solution
1. Study how current system
works

15. SYSTEM PROPOSAL
Presented to
steering
committee,
which decides
how system will
be developed
Assesses
feasibility
of each
alternative
solution
Recommends
the most
feasible
solution for
the project

16. IDENTIFY POSSIBLE SOLUTIONS
Buy packaged software—prewritten
software available for purchase
Outsource—have outside source
develop software
Write own custom software—software
developed at user’s request
Vertical market
software—designed
for particular industry
Horizontal market
software—meets
needs of many
companies

17. DESIGN PHASE
Acquire hardware and software
Develop all details of new or
modified information system

18. Visit vendors’ stores
ACQUISITION
What is needed to acquire new hardware and software?
 Identify all hardware and software requirements of new
or modified system
Surf Web
Read print and online
trade journals,
newspapers, and
magazines
Talk with other
systems analysts

19. HOW TO TEST SOFTWARE PRODUCTS?
 References from vendor
 Talk to current users of product
 Product demonstrations
 Trial version of software
 Benchmark test measures performance

20. DETAILED DESIGN
Includes several activities
Database
design
Input and
output design
Program
design
Detailed design specifications for components in proposed solution

21. PROTOTYPING TOOLS/METHODS:
MOCKUP
 Sample of input or output that contains actual data

22. PROTOTYPING TOOLS/METHODS:
PROTOTYPE
Working model of
proposed system
Beginning a prototype
too early may lead to
problems

23. PROTOTYPING TOOLS/METHODS:
CASE
 CASE (Computer-Aided Software Engineering) tools
support activities of the SDLC

24. Convert to new system
IMPLEMENTATION PHASE
 Purpose is to construct, or build, new or modified
system and then deliver it to users
Train users
Install and test new system
Develop programs

25. TESTING
Three kinds of tests performed by system developers:
Verifies application
works with other
applications
Systems test
Integration Test
Unit Test
Verifies each
individual program
works by itself
Verifies all programs
in application work
together

26. TRAINING
 Showing users exactly how they will use new
hardware and software in system

27. SUPPORT PHASE
Conduct post-implementation system review—meeting to find out if
information system is performing according to expectations
Identify errors
Identify enhancements
Monitor system performance
 Providing ongoing assistance after the system is
implemented

28. 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

29. 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

30.  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
PROBLEMS & OPPORTUNITIES

31. 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

32.  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 SELECTION

33. 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

34.  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%
PROJECT OBJECTIVES

35. 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?

36.  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

37.  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.
FEASIBILITY ANALYSIS

38. 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

39.  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

40.  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
PLANNING VIA THE SDLC

41. WATERFALL MODEL

42. 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.

43. 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

44. 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)

45. 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.

46. 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

47. AGILE MANIFESTO

48. 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)

49. 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

50. XP PRACTICES (1-6)
1. Planning game – determine scope of the next release
by combining business priorities and technical
estimates
2. Small releases – put a simple system into production,
then release new versions in very short cycle
3. Metaphor – all development is guided by a simple
shared story of how the whole system works
4. Simple design – system is designed as simply as
possible (extra complexity removed as soon as found)
5. Testing – programmers continuously write unit tests;
customers write tests for features
6. Refactoring – programmers continuously restructure
the system without changing its behavior to remove
duplication and simplify

51. XP Practices (7 – 12)
7. Pair-programming -- all production code is written with
two programmers at one machine
8. Collective ownership – anyone can change any code
anywhere in the system at any time.
9. Continuous integration – integrate and build the
system many times a day – every time a task is
completed.
10. 40-hour week – work no more than 40 hours a week
as a rule
11. On-site customer – a user is on the team and available
full-time to answer questions
12. Coding standards – programmers write all code in
accordance with rules emphasizing communication
through the code

52. 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)

53. 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.