SDLC in Information Systems!:)

10 Mar

Hey guys…seeing as this is the official end date for this blogging business I decided that I would provide some final information on the stages of the SDLC!:):) So here it comes….

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

Reference: http://spot.pcc.edu/~rerdman/sysdevellifecycle.html

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: