chapter 15 systems development i. systems development life cycle (sdlc)

1

Chapter 15 Systems Development

I. Systems Development Life Cycle (SDLC)Planning Analysis Design Implementation Support

How does the IS fit in firm’s plans?

InvestigationRequirements to functions Training Maintenance

Feasibility Evaluate alternatives Conversion User support

Requirementsdefinition Programming

Testing

2

1. Planning (Chapter 14)2. Analysis

• Initial investigation– Talk to users; is there a real problem?– Submit preliminary report

• Detailed investigation– Feasibility study

• Technical• Economic• Operational

– Requirements definition• What does the system need to do so it will fulfill its goals?• Collection of information from users

– Interviews– Questionnaires– Examination of documents– On-the-job observation

3

Economic Feasibility: Cost/Benefit Analysis

Figure 15.3 Estimated benefits and costs of an IS ($)

4

3. Design

Design Phase I

• Requirements Functions Components• Outputs Processing Inputs• Typical components

– Input files, procedures, output files, user dialog (GUI), interfaces

• Graphical tools used to model systems– Flowcharts– Data flow diagrams– Unified modeling language (UML)

5

Design Phase II

• Evaluate alternatives– If a LAN is required, then what shape, what media?– Select programming language

• Components: logical design versus physical design– Logical design includes specifications of input

(design view) and output files (report design)– Physical design involves specifications related to the

hardware components required of the system (e.g., 16 pcs with 4.8 GHz cpus and 80 GB hard drives, fiber optic cable with 8 mbps capacity)

6

Design Phase III

• Construction– This is where the programming is done– Modular construction; modular testing– Evidence of modules in Windows applications

• Systems Testing– Once modules are completed system is assembled– Systems testing where you purposely try to make the

system fail; often rushed or omitted– Role of business people

7

Examples of Designer Specifications

• OUTPUT– MEDIUM; CONTENT; TIMING

• INPUT– ORIGINS; FLOW; DATA ENTRY

• USER INTERFACE– SIMPLICITY; EFFICIENCY; LOGIC– FEEDBACK; ERRORS

• DATABASE DESIGN– LOGICAL DATA RELATIONS– VOLUME, SPEED REQUIREMENTS– FILE ORGANIZATION & DESIGN– RECORD SPECIFICATIONS

8

Examples of Designer Specifications

• PROCESSING– COMPUTATIONS– PROGRAM MODULES– REQUIRED REPORTS– TIMING OF OUTPUTS

• MANUAL PROCEDURES– WHAT ACTIVITIES– WHO PERFORMS THEM– WHO PERFORMS THEM– HOW– WHERE

9

4. Implementation

• Training– Possible methods (in class on site, Web, distance

learning, CD’s, in class off site), intranet– Coordination with conversion

• Conversion– Parallel Conversion– Phased Conversion– Cut over (Cold Turkey) Conversion– Pilot Conversion

10

Conversion Strategies

Figure 15.10 Strategies used to convert from one IS to another

11

5. Support• Maintenance

– Post-implementation debugging– System changes and additions

• Support– Assist users and ensure that the system is operated in

a satisfactory manner• Importance of good documentation in this phase

– Paper books/manuals– Electronic documents– Commentary within programs

• Longest of SDLC phases

12

Pros and Cons of SDLC• Pros

– Thorough analysis and design– Well-defined phases to track progress– Tangible outputs at the end of each phase– Works well if requirements are well understood– Only reasonable method in large complex systems

• Cons– Lengthy process– Requirements are frozen and difficult to change– Requires significant resources in time/people

13

II. Prototyping

• Systems developed using an iterative process– Purpose is to develop a working model as quickly as

possible, which can be revised– Requirements determined in an iterative manner– Significantly shortens systems development backlog– Can increase risk of incompatibility and other

unforeseen mishaps• Prototyping is often used in conjunction with SDLC

14

Prototyping

Figure 15.12 In prototyping, refinement of the system continues until users are satisfied.

15

Prototyping

Figure 15.13 When to prototype and when not to prototype

16

III. Agile Methods• These methods try to deliver a useful IS to the user as

quickly as possible without compromising features • In SDLC users are required to sign a contract agreeing on

system requirements. This freezes the requirements• Characteristics of agile methods

– Produce demo system in weeks– Get feedback from users– Design for simplicity so changes are quick and easy– Test constantly– Communicate with users informally and frequently– Encourage users to explain how they will use the system

17

IV. Systems Development Led by End Users

• Motivation– Agile methods got users more involved but they did

not lead projects: SDLU promotes the idea that better systems result when systems projects are lead by users

• Joint application development (JAD) an example of SDLU– Planning phase – determines requirements in a

workshop setting led by a user; top management presence; similar to analysis from SDLC

– Design phase – determines how the system will work in a workshop setting; outputs include data flow diagrams, design views of tables, screen designs, etc.; lots of prototyping is used

18

Why End User Development• Backlog of MIS project• Available powerful and easy to use software

tools• Suitable for small projects that involves user’s

expertise.• Suitable for projects that support one-time

decision-making.• Suitable for projects that can be completed by

using off-shelf software.

19

V. Systems Integration• Takes a look at the information needs of an entire

organization (or a major division)• Analysts integrate existing systems so that:

– Data can flow more easily among business units.– Users can access different types of data via a single

interface.• Examples of systems integration

– Linking existing systems to Web sites– Linking databases to Web sites– Linking systems between two or more organizations

20

VI. Ethical and Societal IssuesShould IS Professionals Be Certified?

• Malfunctioning ISs– Faulty systems may wreak havoc, causing

financial damage or even death– Should IS professionals be certified based on the

high investment and risk involved in their work?

21

Ethical and Societal IssuesShould IS Professionals Be Certified?

• Certification Pros– Protect potential employers– Protect clients of consultants– Fewer software-related failures

• Certification Cons– Difficult to measure software competence– May create a “closed shop:” decreased competition,

decreased incentive to improve skills