Back to CIS 120 Home Page

SYSTEMS DEVELOPMENT LIFE CYCLE

The following is a fairly extensive outline of the System Development Life Cycle. A search of the Internet will show several variations on the SDLC with fewer or more steps to the process. The SDLC relates to the Building a Program steps described in a briefer fashion in the text.

 

PLANNING

(FEASIBILITY STUDY)

ANALYSIS

DESIGN

CONSTRUCTION

TESTING

DOCUMENTATION

IMPLEMENTATION

USE/MAINTENANCE

System Development Life Cycle - A process by which systems analysts, software engineers, programmers, and end users build information systems.

The core of the SDLC (analysis-design-implementation) is based on the standard approach to problem solving. First, you need to figure out or define what the problem is (analysis), then you need to figure out a good approach for solving it (design), and finally you need to go ahead and do it (implementation).The number of actual steps will vary depending on which texts and sources you consult.The steps listed above are one example that addresses most of the concerns of the SDLC.

The SDLC comes in two basic flavors. The waterfall or linear approach implies that you do each step in sequence. This is the way most older systems were developed. The major problem is that it assumes you can do all the analysis and get everything right without doing any design or implementation. On complex systems this just isnít possible. The fountain or iterative approach implies that you do some analysis, then some design, and then some implementation. Based on what you learn, you cycle back (loop) through and do more analysis, etc. This supports human learning a lot better. It is the approach we recommend for most projects today.

A. PLANNING

   

 

Trigger:

 

Key Activities:

Key Outputs:

 

(FEASIBILITY STUDY)

   

A brief look at the following factors:

        Technical (is hardware and software available to do what is needed?)

        Economic return (can the expense be justified by potential financial returns?)

        Non-economic return (can expense be justified in ways that cannot be measured financially?)

        Legal and ethical (will the system operate within boundaries?)

        Operational (will the system receive support from the people who operate it and make it work?)

        Schedule (is it possible to satisfy development time constraints?)

†††††††††††††††††††††† As specified in McLeod, 1998, p. 192

B. ANALYSIS

   

 

Key Activities:

 

Key Outputs:

 

ANALYSIS: INFORMATION GATHERING TECHNIQUES

 

What information?

        Overview of business area mission and goals

        Tasks done

        Activities done in completion of tasks

        Flow of information through application area

        Uses of reports (Who generates them? How are they used?)

        Current system documentation

        Existing company procedure manuals

        User wish list

        Work samples

        ETC.

 

Who do I get information from? (Subject Area Experts)

        Key workers in the job

        Knowledgeable supervisors

        Existing systems maintenance and analysis staff

        ETC.

How?

        Direct observation

        Interviews (individual and groups, structured and unstructured)

        Questionares/surveys

        Activity logs/work diaries

        ETC.

 

C. DESIGN

   

 

Key Activities:

 

Key Outputs:

 

D. CONSTRUCTION

   

 

Key Activities (if create in-house):

 

Key Outputs:

 

E. TESTING

   

 

UNIT TEST

 

INTEGRATIVE SYSTEMS TESTING

 

DEBUGGING

F. DOCUMENTATION

   

 

Two basic types of documentation

Systems Documentation

 

User documentation

 

WHY IS DOCUMENTATION IMPORTANT?

Systems Documentation

        Maintenance staff must learn system

o       The original systems developers are usually not the systems maintenance staff (they move to other new development projects)

        To ensure continuity of systems development after original developers leave the company

        To facilitate the incorporation of new aspects into the system (e.g., adding to the original models) by systems development staff

 

User Documentation

        To reduce the number of problem telephone calls that the developer receives from customers

        To minimize the amount of the new system training needed

 

G. IMPLEMENTATION
   

 

Key Activities:

 

Key Outputs:

 

ACTUAL CONVERSION/CUTOVER

 

††††††††††† Changing from old to new system

 

††††††††††† TYPES OF CUTOVER STRATEGIES

††††††††††† PILOT

        Smaller trial system

        Subset of the entire system

        If successful, rest of system is typically cutover

 

 

IMMEDIATE

        Convert everything on one day

        Works best for small systems

 

PHASED

        New system is incorporated one section at a time

 

PARALLEL

        Old system is maintained concurrently with new system

        Time consuming and expensive

        Greatest security against failure

††††††††††††††††††††††††††††† -based on McLeod (1999)

 

††††††††††† USER TRAINING

        Schedule as close to new systems introduction (implementation) as possible

        Train people about what they need to know (donít bore them with unnecessary information)

o       May differ for each job

        Which type of training?

o       Classroom vs. on the job vs. individual vs. computer aided, etc.

 

User acceptance/sign-off

ORGANIZATIONAL CHANGE

MANAGING ORGANIZATIONAL CHANGE

        Resistance to change

        Increase in stress reactions

        Avoidance of the new system

 

MINIMIZING NEGATIVE CHANGE REACTIONS

        Invoice users in the development process early (to increase feelings of personal involvement and commitment)

        Provide ample time for training

        For introductory period, ask management to disband productivity performance measures associated with computing (the new system)

        Provide support to resistant users

        Provide well written, easy to understand documentation

        Be honest with the users as to what the system can and cannot do

        ETC.

 

G. USE/MAINTENANCE

   

 

Key Activities:

 

Key Outputs:

 

A graphic representation of the System Development Life Cycle


Back to CIS 120 Home Page