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:

• Request by client/user
• Corporate/organizational requirement

 

Key Activities:

• Conduct preliminary investigation/feasibility study
• Determine scope of problem/project
• Identify constraints to systems development
• Identify resources required
• Set timelines, schedules, checkpoints, etc.
• Set project deliverable goals
• Develop high level specifications

Key Outputs:

• Decision to proceed
• Project plan
• Preliminary needs analysis report

 

(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:

• Gather business requirements
• Build trust and rapport with users
• Document the existing system
• Develop preliminary data and process models
• Verify requirements and current system/procedures with users

 

Key Outputs:

• Systems Requirements Documents
• Detailed Project Scope and Deliverables Reports
• Data and Process Models

 

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:

• Determine technical systems configuration
• Determine data structure
• Determine make or buy decision
• Prototype
• Set systems conversion plan

 

Key Outputs:

• Systems architecture report
• Systems conversion chart and plan
• Psuedocode
• Data structure diagrams
• Prototypes

 

D. CONSTRUCTION

   

 

Key Activities (if create in-house):

• Create the physical system
• Test the system
• Obtain hardware
• Create documentation and training materials

 

Key Outputs:

• Tested programs
• Databases
• Completed system
• Training materials

 

E. TESTING

   

 

UNIT TEST

• Testing of individual units or modules

 

INTEGRATIVE SYSTEMS TESTING

• Testing the entire system as one

 

DEBUGGING

• Correcting systems problems

F. DOCUMENTATION

   

 

Two basic types of documentation

Systems Documentation

• Information needed for the on-going maintenance and operation of the computer system
• Structured for the technical systems professional
• Examples: technical diagrams, flowcharts, database management structures, etc.

 

User documentation

• Easy to read (step by step) instructions for using the application system
• Structured for non-systems professional

 

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:

• Conduct cutover
• Train users/customers
• Manage change
• Obtain user sign off

 

Key Outputs:

• Satisfied users/customers
• Modification requests

 

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:

• Conduct on-going systems maintenance

 

Key Outputs:

• Change requests
• New systems proposals/requests