1. CHAPTER 10 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT

2. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
Systems development life cycle (SDLC) – a highly structured approach for development of new customized software applications
© Pearson Prentice-Hall Chapter
Page 385

3. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
The SDLC Steps
Key characteristic is extensive formal reviews
required at end of each major step
© Pearson Prentice-Hall Chapter
Figure The Systems Development
Life Cycle
Page 386

4. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
The SDLC Steps
Hallmark of SDLC approach: extensive up-front time spent
determining requirements to avoid expensive changes later
© Pearson Prentice-Hall Chapter
Figure Cost Breakdown for $1 Million
SDLC Project
Page 386

5. 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
© Pearson Prentice-Hall Chapter
Page 386

6. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
Definition Phase – Feasibility Analysis
Types of feasibility – economic, operational, and technical
Deliverable – page document:
Executive overview and recommendations
Description of what system would do and how it would operate
Analysis of costs and benefits
Development plan
© Pearson Prentice-Hall Chapter
Page

7. 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
© Pearson Prentice-Hall Chapter
Page 388

8. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
Construction Phase
System Design
System Building
System Testing
Documentation is a major mechanism of
communication during development process
© Pearson Prentice-Hall Chapter
Figure Characteristics
of High Quality Systems
Page 389

9. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
Implementation Phase
Installation
Operations
Maintenance
© Pearson Prentice-Hall Chapter
Page 390

10. Implementation Phase – Installation
Parallel Strategy
Parallel Strategy
Parallel Strategy
Parallel Strategy
© Pearson Prentice-Hall Chapter
Figure Implementation Strategies
Page 391

11. Implementation Phase – Maintenance
© Pearson Prentice-Hall Chapter
Figure Percent of Development
Resources Devoted to Maintenance
Page 392

12. Implementation Phase – Maintenance
© Pearson Prentice-Hall Chapter
Figure The Widening Gap Between
Organization’s Needs and System’s Performance
Page 392

13. 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
© Pearson Prentice-Hall Chapter
Page 393

14. 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
© Pearson Prentice-Hall Chapter
Page 394

15. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
Managing an SDLC Project
Characteristics critical for success:
Manageable project size
Accurate requirements definition
Executive sponsorship
© Pearson Prentice-Hall Chapter
Page 394

16. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
Managing an SDLC Project
(Adapted from Boehm, 1976)
© Pearson Prentice-Hall Chapter
Figure Costs of Error Correction
by SDLC Step
Page 395

17. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
SDLC Advantages and Disadvantages
© Pearson Prentice-Hall Chapter
Figure Advantages and Disadvantages
of Traditional SDLC Approach
Page 395

18. 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
© Pearson Prentice-Hall Chapter
Page 396

19. 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
© Pearson Prentice-Hall Chapter
Page 396

20. 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
© Pearson Prentice-Hall Chapter
Page 396

21. The Prototyping Steps Page 397 Figure 10.9 The Prototyping Life Cycle
© Pearson Prentice-Hall Chapter
Figure The Prototyping Life Cycle
Page 397

22. PROTOTYPING METHODOLOGY
The Prototyping Project Team
Representatives from IS and user management necessary
Need team members who can quickly build systems using advanced tools
Requires dedicated business user roles
© Pearson Prentice-Hall Chapter
Page 398

23. 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
© Pearson Prentice-Hall Chapter
Page

24. 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
© Pearson Prentice-Hall Chapter
Page 399

25. PROTOTYPING METHODOLOGY
Prototyping within an SDLC Process
© Pearson Prentice-Hall Chapter
Figure SDLC with Prototyping
to Define Requirements
Page 399

26. PROTOTYPING METHODOLOGY
Prototyping within an SDLC Process
© Pearson Prentice-Hall Chapter
Figure Prototyping/Piloting Replaces
SDLC Definition Phase
Page 399

27. NEWER APPROACHES Rapid Application Development (RAD)
Hybrid methodology – aspects of SDLC and prototyping
Goal is to produce a system in less than a year
© Pearson Prentice-Hall Chapter
Figure Four-Step RAD Cycle
Page 400

28. 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
© Pearson Prentice-Hall Chapter
Page

29. 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
© Pearson Prentice-Hall Chapter
Page

30. NEWER APPROACHES Rapid Application Development (RAD) Page 401
(Adapted from Valacich, George, and Hoffer, 2001)
© Pearson Prentice-Hall Chapter
Figure Types of CASE Tools
Page 401

31. NEWER APPROACHES Rapid Application Development (RAD) Page 402
© Pearson Prentice-Hall Chapter
Figure RAD Advantages
and Disadvantages
Page 402

32. NEWER APPROACHES Alternative methodology for smaller projects
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
© Pearson Prentice-Hall Chapter
Page 402

33. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF
Advantages:
Helps keep software development costs down
Uses technical expertise not available in-house
Can often complete projects more quickly
Off-site outsourcing:
Onshore – within same country or region
Offshore – not within same country or region
© Pearson Prentice-Hall Chapter
Page 402

34. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF
Offshore alternative good option when:
System requirements well-defined and remain stable
Time is of essence and 7x24 hour availability of resources a good idea
Cost of project important
© Pearson Prentice-Hall Chapter
Page 402

35. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF
Guidelines for managing offsite outsourcer:
Manage expectations, not staff
Take explicit actions to integrate the offsite workers
Communicate frequently
Abandoning informal ways may result in increased rigor
© Pearson Prentice-Hall Chapter
Page