MIS 210 Information Systems I: SDLC Methodologies Project Initiation and Planning Requirements Analysis

MIS 210
Information Systems I
Lecture 2:
SDLC
Methodologies
Project Initiation and Planning
Requirements Analysis
Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Systems Development
Life Cycle
(SDLC)

Systems Development
What is a system?
A collection of related components that interact
to perform a task in order to accomplish a goal
Systems development (systems analysis and

design) is the process of creating systems,
developing them, and maintaining or enhancing
them.

Characteristics of Software
• Software is developed, not manufactured
• Software does not “wear out”

– although it can become obsolete

Today’s Software Development
Environment
• Failures
• Productivity gap
• Backlogs
• Maintenance bound

Alleviating the Problems in
Systems Development
Elimination of the causes of system failure lie in
1. the application of methodologies

2. modeling tools
3. techniques
4. project management techniques
to design and build IS that not only meet the needs of the
users, but also are delivered on time and within budget

Principles of Successful Systems Development
• Get the user involved
• Use a problem-solving approach
• Establish phases and activities
• Establish standards for development and documentation
• Justify systems as capital investments
• Don't be afraid to cancel or revise scope
• Divide and conquer
• Design systems for growth and change
• Proper planning and project management

Some Key Terms ...
• Systems development life cycle (SDLC): the life of a project, from
concept through implementation
• Methodology: a comprehensive and detailed version of an entire

SDLC
• Technique: an approach that applies specific tools and rules to

complete one or more phases of the methodology
• Modeling tools: specific tools used to apply techniques
• Project management techniques: tools used to help plan, schedule,

and control a project

Tools
• Software support that helps create models
or other project components
• From simple drawing programs to complex
CASE tools

Some Tools
• Project management applications
• Drawing/graphics applications
• Word processing/text editor
• Computer-aided system engineering (CASE) tools
• Integrated development environment (IDF)
• Database management applications
• Reverse-engineering tool
• Code generators

Techniques
• Collection of guidelines that help the analyst
complete a system development activity or task
• Step-by-step instructions
• General advice

Some Techniques
• Strategic planning
• Project management
• User interviewing
• Data-modeling
• Relational database design

Systems Development Lifecycle (SDLC)
• Three major activities

– Analysis: understanding business needs
– Design: conceptualizing computer-system
solution
– Implementation: construction, testing, and
installation
• Two additional phases
– Project planning
– Support
The SDLC
F
1. Planning
r a. Project identification and selection
o
n b. Project initiation and planning A
t
e 2. Analysis
n
d a. Determine system requirements (WHAT users need)
b. Modeling possible solutions (HOW to satisfy user needs)
B 3. Design D
a
c
a. logical design
k b. physical design
e
n 4. Implementation
d
5. Maintenance / support I

SDLC Concepts
• All projects use some variation of the SDLC

• SDLC is more than phases
– Principles of management
– Planning and control
– Organization and scheduling
– Problem solving

Major Attributes of the Life Cycle
• The project --
– Moves systematically through phases where
each phase has a standard set of outputs
– Produces project deliverables
– Uses deliverables in implementation
– Results in actual information system
– Uses gradual refinement

Project Phases
• Planning (Why build the system? How should
the team go about building it?)
• Analysis (Who uses system, what will it do,
where and when will the system be used?)
• Design (How will the system work?)
• Implementation (System delivery)

Planning
• Identifying business value

• Analyze feasibility
• Develop work plan
• Staff the project
• Control and direct project

Design
• Design selection
• Architecture design
• Interface design
• Data storage design
• Program design

Implementation
• Construction
– Program building
– Program and system testing
• Installation
– Conversion strategy
– Training plan
– Support plan

Support Phase
• Objective: Keep system running productively
following initial installation
– End-user support
• Help desks
• Training programs
– Maintaining and enhancing computer system
• Enhancements
• Upgrades
• Maintenance

Methodologies

Common Development Methodologies
and Techniques
 Code & fix model
 Structured development
 Prototyping
 Rapid application development
 Object-oriented development

Code and Fix It Model
• An early technique
• The developer, in the following order:
– codes
– thinks about requirements
– fixes the code
– continues this process until...

Structured Development
• Based on the principles of:
– modularization
– top-down decomposition
– process driven
• Structured programming
• Structured design
• Structured analysis

Project Identification Systems Development Life Cycle
and Selection
Waterfall Model
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance

Waterfall Model
• Problems
– dependent on documents, particularly in
completing the requirements and design phases
– tendency to hide poorly understood requirements
with elaborate specifications

Advantages of Structured Development
• Been used successfully for over 30 years

• Provides a clear framework that defines and
divides important activities
• Can be applied to both small and large projects
• Division of labor is easier to facilitate

Limitations of Structured Development
• Specification problems
– assumes that development is a sequential
process
• Changing requirements
– requirements specified at the beginning
– assumption that requirements will not change
• Conceptualization and visualization
– document led methodology
– volume of documentation can be huge
• Inaccuracy
– there is only downward trend
Prototyping
• Principle: a user can tell you better what they DON'T want
than what they DO want
• Expendable (throw-away) prototyping:
– discarded after use
– used to support the analysis and design phases
• Evolutionary prototyping:
– prototype evolves into the final system
– is it a methodology?

Advantages
• Speed
• Easier for end-users to learn
• System changes discovered earlier
• End-user involvement (ownership)
– increased user satisfaction
– increased user acceptance
• User-analyst communication
• Early problem detection
– reduced development time
– reduced maintenance

Disadvantages
• Poor documentation
• Hard to control/manage
• (Unrealistic) User expectations
– time for final system
– final system differences
• reduced analysis

Rapid Application Development
(RAD)
• Logistical approach to systems design
• Combines
– integrated CASE tools
– information engineering methodologies
– management techniques
• Speeds up Systems Development by as much as
20 times
• Critics consider it incomplete life cycle
Object-Oriented (OO) Development
• A fundamentally new way of thinking about

developing systems
• Object-oriented: means that we organize
software as a collection of discrete objects that
incorporate both data and behavior
• Object-oriented development: an approach
to systems development that proposes the use
of objects in the building of new systems and
the rebuilding of old ones

Advantages of OO
e
• Faster development
s
• Higher quality
• Easier maintenance
u
• Increased scalability
e
• Better information structure
• Increased adaptability
R
• Increased modeling power
• Supports complexity

Disadvantages of OO
• Maturity of technology
• Need for standards
• Lack of database technology
• Lack of reusable software
• Lack of metrics
• Speed of execution
• Availability of qualified personnel
• Cost of conversion


• Long-term information systems strategic plan (top-
down)
• Department managers or process managers (bottom-up)
• Response to outside forces

– Legislative changes
– Market forces
– Competition

Confirming Project Feasibility
• Economic
• Organizational and cultural
• Technological
• Schedule
• Resource

Intangibles in Economic Feasibility
• Costs and benefits cannot always be measured

• Examples
– Increased levels of service
– Survival
– Lost customers or sales

Organizational and Cultural Feasibility
• Each company has own culture
• New system must fit into culture
• Evaluate related issues for potential risks

Technological Feasibility
• Does system stretch state-of-the-art?
• Does expertise exist in-house for development?
• Does a third party need to be involved?

Schedule Feasibility
• Can project be completed on time?
• Risk of schedule slipping
• Assumptions and estimates

Resource Feasibility
• Team member availability
• Team skill levels
• Equipment
• Support staff
• Physical facilities

Developing Project Schedule
• Task: smallest piece of work
• Activity: group of tasks
• Phase: group of activities
• Schedule process
– List all tasks for each SDLC activity
– Estimate sizes of each task
– Determine task sequence
– Schedule tasks

Project Staffing
• Develop resource plan for the project
• Identify and request specific technical staff
• Identify and request specific user staff
• Organize the project team into work groups
• Conduct preliminary training and team building exercises

Launching Project
• Oversight committee is finalized and meets to give
go-ahead
• Formal announcement made
• Key question, “Are we ready to start?”

Focusing the Investigation
• Most system problems occur in complex

tasks that have high user impact
• Application complexity
• User impact

Requirements Analysis

Analysis
A. Determine system requirements

B. Structure requirements
– 1. Process modeling
– 2. Logic modeling
– 3. Data modeling
C. Select best alternative

Requirements Analysis Goals
• Fully describe the current system

– Study and analyze the current system (gather
and study facts)
• Determine the ideal information system
• Identify resource constraints
• Define and prioritize requirements
• Inspire user confidence/ownership

Study & Analyze Current System
• Gather information on what the system should
do from as many sources as possible
• Concentrate on WHAT is needed, not HOW to
do it
• “Don’t try to fix it unless you understand it”
• Major problem: analyst not understanding
user needs

-- Activities --
1. Learn about current system (gather facts)
2. Model current system
3. Analyze problems/opportunities (study facts)
4. Establish new system objectives

-- Output --
1. Complete statement of user environment
2. Models of current system
3. List of major problems/causes/effects
4. System objectives

Learn About Current System
(gather facts)
Gather information from:
– Current information system:
• a current IS may exist
– External sources:
• reviewing other IS outside the organization can
reveal practical ideas and techniques
– Internal sources:
• single most important source of facts is the user
• existing paper work or documents is also a good
source

Tactics
• Listen - don’t lecture
• Don’t pre-solve problem
• Compare stories
• Look for reluctant responses
• Observe your effects on system
• Avoid politics (head nodding)
• Expect hard, boring work

Fact-finding Methods
• Research and site visits
• Existing documentation
• Observation
• Questionnaires
• Interviews

Observation
• Not for long periods of time
– will change what your measuring
• Vary observation periods
• Take only minimal, preplanned notes
• Coordinate visit beforehand
• Beware of Selective Perception!!!

Questionnaires
-- Types --
• Open-ended (free format)
• Closed-ended (fixed format)

– multiple choice
– rating
– ranking
– single fact

Questionnaire Development
1. Determine what facts need to be collected

2. Determine whether free- or fixed-format is best. Usually, a
combination is used.
3. Write the questions. Examine them carefully. Make sure the
questions don't reflect your personal biases.
4. Test the questions on a small sample of respondents. Modify
those questions that respondents had problems with.
5. Duplicate and distribute the questionnaire.

Questionnaires - the Good and the Bad
Advantages
– Can be quickly answered.
– Cheap for gathering data from a large number of users.
– Allow users to maintain anonymity.
– Responses can be tabulated and analyzed quickly.
Disadvantages
– Number of respondents is often low.
– No guarantee that the user will answer all the questions.
– Inflexible - voluntary information is stifled.
– Elimination of body cues.
– No immediate opportunity to clarify an answer.
– Good questionnaires are difficult to prepare.

Interviews
• Types of Interviews
1. Unstructured
2. Structured
• Types of Questions
1. Open-ended
2. Closed-ended
• Focus of Questions
1. Decision analysis
2. Data analysis

How to Conduct an Interview
1. Select interviewees. Learn as much as you can about

interviewee.
2. Make an appointment - never 'drop by'
3. Limit the interview to between 1/2 hour and 1 hour
4. Clear it with the interviewee's supervisor
5. Conduct the interview in a private location
6. Prepare for the interview: provide an interview agenda
7. Conduct the interview: opening, body, conclusion
8. Follow-up

Interviewing Tips
• Watch the time
• Don’t look at watch
• No leading questions
• Listen
• No body language

More Interviewing Tips
• Make the user feel important
• Be courteous and professional
• Don’t take exhaustive notes
• Use structured questions
• Don’t ask users to remember details
• Avoid gang interviews

Interviews - the Good and the Bad
• Advantages
– Users are actively involved
– SA can probe for more feedback from user
– SA can reword questions for each interviewee
– Body cues
• Disadvantages
– Very time consuming, thus very costly
– Success of the interview is dependent on the SA's human
relations skills
– Interviewing may be impractical due to location of
interviewees

Overall Strategy for Fact Finding
1. Learn all you can from existing documents

2. If appropriate, observe the system in action
3. Conduct interviews
4. Use questionnaires to clear up things you don't
fully understand
5. Follow-up

Some Questions That Must be Answered
• What are the inputs to this system?
• What are the outputs of this system?
• What is the business process (i.e., how is data
processed)?
• Who are the direct end-users?
• How will the users feel about this system?
• Who developed the existing system?

Analyze Problems / Opportunities
(study facts)
• Study and analyze the "current" system
• Problem analysis is difficult.
– We often try to solve problems without analyzing them.
– We try to state the problem in terms of a solution.
• Use the PIECES framework to frame your investigation of
the problems, opportunities, and requirements
– Performance analysis
– Information and data analysis
– Economic analysis
– Control and security analysis
– Efficiency analysis
– Service analysis

Requirements Analysis Document
• Parts
– How analysis was conducted
• credibility
• restarts
– User requirements
– System constraints
– Realistic System Objectives
– Documentation

User Requirements
• User system objectives (unedited)
• Reports (type/frequency)
• User training needs
• Effect of system on various users
– Organization Chart

MIS 210 Information Systems I: SDLC Methodologies Project Initiation and Planning Requirements Analysis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MIS 210 Information Systems I: SDLC Methodologies Project Initiation and Planning Requirements Analysis

Uploaded by

Copyright:

Available Formats

MIS 210

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Systems development (systems analysis and

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Software is developed, not manufactured

• Software does not “wear out”

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Elimination of the causes of system failure lie in

1. the application of methodologies

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Methodology: a comprehensive and detailed version of an entire

• Technique: an approach that applies specific tools and rules to

• Modeling tools: specific tools used to apply techniques

• Project management techniques: tools used to help plan, schedule,

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Three major activities

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• All projects use some variation of the SDLC

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Identifying business value

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Been used successfully for over 30 years

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• A fundamentally new way of thinking about

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Department managers or process managers (bottom-up)

• Response to outside forces

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Costs and benefits cannot always be measured

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Each company has own culture

• New system must fit into culture

• Evaluate related issues for potential risks

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Does expertise exist in-house for development?

• Does a third party need to be involved?

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

• Risk of schedule slipping