2. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
Systems development life cycle (SDLC) – a highly
structured approach for development of new
customized software applications
Page 385
3. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
The SDLC Project Team
• Usually temporary
• Includes personnel from IS and business units
• Has a project manager
– Traditionally from IS
– Can be from business unit
– May be one from each
– Responsible for success of project – delivering quality
system on time and within budget
Page 393
4. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
The SDLC Project Team
• Includes systems analysts
– Have critical roles
– Work closely with business managers and end users
– Have problem-solving skills, knowledge of IT capabilities, strong
business understanding
• Has a business sponsor and a champion
Page 394
5. Managing Change
• The ability to manage change is
critical to the success of systems
development.
– The new or modified systems created
during systems development will
inevitably cause change.
– Managing change requires the ability to
recognize existing or potential
problems.
6. Significant Quote
There is nothing more difficult to plan, more
doubtful of success, nor more dangerous to manage
than the creation of a new information system. For
the initiator has the enmity of all who would profit
from the preservation of the old system and merely
luke warm defenders in those who would gain
from the new one.
7. Establishing Objectives for
Systems Development
• Systems development objectives
should be supportive of, and aligned
with, organizational goals.
• There are four kinds of objectives
that should be considered:
– Performance objectives.
– Cost objectives.
– Control objectives.
– Complexity objectives.
8. Systems Development
Methodologies
• A key factor in completing a
successful systems development
project is to adopt a methodology.
• A methodology is a way of doing
things.
9. Systems Development
Methodologies
• A systems development methodology
is an assortment of rules and standards
that govern the approach taken to all
tasks associated with systems
development.
• In structured systems development the
systems development tasks are broken
down into small, easily managed parts.
10. Systems Development
Methodologies
• Top-down design means the entire
system can be viewed as a layered
set of descriptions, each of which
could be decomposed, or “peeled
back,” to reveal more detailed
specifications for smaller parts of the
system.
11. Structured Walkthrough
• A structured walkthrough is a planned
and pre-announced review of the
progress of a particular project
deliverable--a specific project outcome, a
structure chart, or a human procedure.
• The walkthrough helps team members
review and evaluate the program of
components of a structured project.
12. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
The SDLC Steps
ws
al revie
rm
nsi ve fo p
is exte jor ste
teristic ach ma
ch arac nd of e
Key ed at e
ir
requ
Figure 10.1 The Systems Development Page 386
Life Cycle
13. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
The SDLC Steps
t
e spen
-front tim later
sive up hanges
exten nsive c
ro ach: id expe
LC app to avo
o f SD irements
ark u
Hallm ining req
rm
dete
Figure 10.2 Cost Breakdown for $1 Million Page 386
SDLC Project
14. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
The SDLC Steps
SDLC:
– Most often requires a lot of documentation
– Outputs from one step inputs to next
– Often referred to as the “waterfall” model
Page 386
15. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
Definition Phase – Feasibility Analysis
• Types of feasibility – economic, operational, and
technical
• Deliverable – 10-20 page document:
– Executive overview and recommendations
– Description of what system would do and how it would
operate
– Analysis of costs and benefits
– Development plan
Page 387-388
16. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
Definition Phase – Requirements Definition
• Focuses on logical design: processes, data flows, and data
interrelationships – not specific physical implementation
• Deliverable – system requirements document:
– Detailed descriptions of inputs and outputs, processes used
to convert input data to outputs
– Formal diagrams and output layouts
– Revised cost/benefit analysis
– Revised plan for remainder of project
Page 388
17. Significant Quote
Brook’s Law:
Adding manpower to a late software project makes
it later!
(Frederick P Brooks Jr.)
Hofstadter's Law: It always takes longer than you
think, even when you take Hofstadter's Law into
account.
(Douglas Hofstadter)
18. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
Construction Phase ism
of
han ss
r mec nt proce
• System Design sa majo lopme
ti on i ing deve
• enta n dur
System Building um
Doc unicatio
m
• com
System Testing
Figure 10.3 Characteristics Page 389
of High Quality Systems
21. Implementation Phase – Maintenance
Figure 10.5 Percent of Development Page 392
Resources Devoted to Maintenance
22. Implementation Phase – Maintenance
Figure 10.6 The Widening Gap Between Page 392
Organization’s Needs and System’s Performance
23. Significant Quote
Bove’s Theorem:
The remaining work to finish in order to reach
your goal increases as the deadline approaches.
Walking on water and developing software from
a specification are easy if both are frozen.
(Edward V Berard)
24. SYSTEMS DEVELOPMENT
LIFE CYCLE METHODOLOGY
SDLC Advantages and Disadvantages
Figure 10.8 Advantages and Disadvantages Page 395
of Traditional SDLC Approach
25. Significant Quote
Deadline Dan’s Demon:
Every task takes twice as long as you think it will
take. If you double the time you think it will take,
it will actually take four times as long.
Meskimens Law
There is never time to do it right, but there is
always time to do it over
26. Causes of Maintenance
• Some major causes of program
maintenance are:
– New requests from stakeholders,
users, and managers.
– Bugs or errors in the program.
– Technical and hardware problems.
– Corporate mergers and acquisitions.
– Governmental regulations.
27. Significant Quote
Nixons Law
The man who can smile when things go
wrong has thought of someone to blame.
Flon's axiom
There does not now, nor will there ever, exist
a programming language in which it is the
least bit hard to write bad programs.
(Lawrence Flon)
29. Operational and Rapid
Prototyping
• An operational prototype is a prototype
that works.
• A partially operational prototype has
some components that are operational.
• A rapid prototype allows system
stakeholders and users to see a mockup
of the subsystem much faster, which
enables earlier changes.
30. PROTOTYPING
METHODOLOGY
• Prototyping approach:
– Takes advantage of availability of fourth generation
procedural languages and relational database
management systems
– Enables creation of system (or part of system) more
quickly, then revise after users have tried it
– Is a type of evolutionary development process
Page 396
31. PROTOTYPING
METHODOLOGY
• Prototyping examples:
– Input and output screens developed for users to test as part of
requirements definition
– “First-of-a-series” – a completely operational prototype used as a pilot
– “Selected features” – only some essential features included in prototype,
more added later
– Prototyping used as a complete alternative to traditional SDLC
methodology
Page 396
32. PROTOTYPING
METHODOLOGY
• Prototyping used as a complete alternative to
traditional SDLC methodology:
– Good when requirements hard to define
– Good when system needed quickly
– Impractical for large, complex applications
Page 396
34. PROTOTYPING
METHODOLOGY
Prototyping Advantages and Disadvantages
• Advantages:
– Only basic requirements needed at front end
– Used to develop systems that radically change how work is done, so users can
evaluate
– Allows firms to explore use of new technology
– Working system available for testing more quickly
– Less strong top-down commitment needed at front end
– Costs and benefits can be derived after experience with initial prototype
– Initial user acceptance likely higher
Page 398-399
35. PROTOTYPING
METHODOLOGY
Prototyping Advantages and Disadvantages
• Disadvantages:
– End prototype often lacks security and control
features
– May not undergo as rigorous testing
– Final documentation may be less complete
– More difficult to manage user expectations
Page 399
38. NEWER APPROACHES
Rapid Application Development (RAD)
• Hybrid methodology –
aspects of SDLC and
prototyping
• Goal is to produce a
system in less than a
year
Figure 10.12 Four-Step RAD Cycle Page 400
39. NEWER APPROACHES
Rapid Application Development (RAD)
Joint application design (JAD) – a technique in
which a team of users and IS specialists engage in
an intense and structured process in order to
minimize the total time required for gathering
information from multiple participants
Page 400-401
40. NEWER APPROACHES
Rapid Application Development (RAD)
Joint application design (JAD) – a technique in
which a team of users and IS specialists engage in
an intense and structured process in order to
minimize the total time required for gathering
information from multiple participants
Computer-aided software engineering (CASE) –
any software tool used to automate one or more
steps of a software development methodology
Page 400-401
41. NEWER APPROACHES
Rapid Application Development (RAD)
(Adapted from Valacich, George, and Hoffer, 2001)
Figure 10.13 Types of CASE Tools Page 401
43. NEWER APPROACHES
Agile Software Development Discipline
• Alternative methodology for smaller projects
• Based on four key values:
– Simplicity
– Communication
– Feedback
– Courage
• One type: Extreme Programming (XP)
– Programmers write code in pairs
– Use simple design and frequent testing
Page 402
44. THE MAKE-OR-BUY DECISION
• Decision should be made jointly by business managers
and IS professionals
• Advantages of purchasing:
– Cost savings
– Faster speed of implementation
• Disadvantages of purchasing:
– Seldom exactly fits a company’s needs
– Often forces trade-offs
Page 406
48. PURCHASING METHODOLOGY
Develop and Distribute the RFP
Request for proposal (RFP) – a formal document
sent to potential vendors inviting them to submit a
proposal describing their software package and
how it would meet the company’s needs
Page 409
49. PURCHASING METHODOLOGY
Evaluate Vendor Responses to RFP and Choose Package
• Evaluation steps:
– Review vendors’ responses from RFPs
– Request demonstrations of leading packages
– Request references from users of software packages in other companies
– Assess how well package capabilities satisfy company’s needs
– Understand extent of any additional development efforts or costs to tailor software
– Make decision
Page 410-411
51. PURCHASING METHODOLOGY
Construction Phase
• If no software package modifications required:
– Skip system design and building steps
– Move directly to system testing
– Develop any necessary process changes
• If software package is modified:
– Consider contracting with vendor or a third party for changes versus modifying
in-house
– Determine if changes are required to other existing company systems
Page 413
52. PURCHASING METHODOLOGY
Project Team for Purchasing Packages
– Business managers and users
– IS professionals
– Project manager – usually a business manager
– Software vendor personnel
– Sometimes includes a third-party implementation partner
– Purchasing specialists
– Attorneys
Page 414-415
53. PURCHASING METHODOLOGY
Purchasing Advantages and Disadvantages
Figure 11.7 Advantages and Disadvantages Page 416
of Purchasing Packaged Software
54. NEW PURCHASING OPTION:
APPLICATION SERVICE
PROVIDERS (ASPs)
• New trend beginning 2000s
• Purchasing option: purchaser elects to use a “hosted” application rather than to purchase
the software application and host it on its own equipment
• ASP is an ongoing service provider
• Company pays third party (ASP) for delivering the software functionality over the Internet to
company employees and sometimes business partners
Page 418
55. NEW PURCHASING OPTION:
APPLICATION SERVICE
PROVIDERS (ASPs)
• Some advantages:
– Cost savings and faster speed of implementation
– Usually involves monthly fees rather than large infrastructure investment
• Disadvantages:
– Dependence on an external vendor for both software and ongoing operations
– Good assessment of required service levels even more critical
Page 418-419
56. Potential Problems for
Systems Development
• Solving the wrong problem.
• Poor problem definition and
analysis.
• Poor communication.
• A project that is too ambitious.
• A lack of top management support.
• A lack of management and user
involvement.
57. Potential Problems for
Systems Development
• Failure to use a standard systems
development approach.
• Inadequate or improper systems
design.
• Poor testing and implementation.
• A lack of concern for maintenance.
58. Success Factors in
Systems Development
• Clearly defined organizational goals.
• A sharp focus on, and clear understanding of, the most
important business problems or opportunities.
• Clearly defined systems development objectives.
• Support of top-level managers. Involvement of users at all
stages.
• Use of a proven systems development method.
• Creating or aligning incremental systems benefits with
normal user work activities so as to provide incentives for
effective system interaction.
• Managing change.
• A simple and straightforward design.
• Good training programs for all involved.
59. Global Sourcing
• The process of deciding where in
the world a firm’s activities will be
performed and who will perform the
activities.
– Fundamentally any activities that does
not require direct customer contact,
extensive local knowledge, or complex
interactions can be sourced anywhere
62. Definition of Outsourcing
• IS outsourcing is the commissioning of part or all
of the IS activities an organization needs, and/or
transferring the associated human and other IS
resources, to one or more external IS suppliers
• IS Offshoring is the commissioning of part or all
of the IS activities an organization needs to one
or more other countries
• IS Insourcing is the sourcing of a business
function within the firm (e.g., Kingland Systems)
63. IS Outsourcing
• Four Types of Outsourcing
Relationships:
Support
Reliance
Alignment
Alliance
64. Outsourcing Grid
Extent of Substitution by Vendors
High
Reliance Alliance
Support Alignment
Low
Low High
Strategic Impact of IS Applications
65. Outsourcing Decision
Variables
• Relationships
• Division Among Suppliers and
Contracts
• Management Structure
• Operational Structure
• Internal Organization of Outsourcing
Coordination
66. Horizontal and Vertical
Integration
• Diversification - • Specialization -
increasing the reducing the number
number of products of products and
and services services
• Differentiation - • Integration -
aka ‘disintegration’ - performing a larger
decreasing the number of phases in
number of the production chain
subsequent phases in
the production chain
67. Backward Vertical
Disintegration
• Car manufacturer purchasing pre-
assembled engines instead of
purchasing and assembling the
component parts themselves
• Decreasing the number of phases a
firm performs by commissioning
another entity within the production
chain to perform those functions
