Transcript Database - McMaster University

Systems Development
Lifecycle (SDLC)
The Systems Development
Lifecycle (SDLC)

Systems development life cycle (SDLC)


Two main approaches to SDLC



Provides overall framework for managing
systems development process
Predictive approach – assumes project can
be planned out in advance
Adaptive approach – more flexible, assumes
project cannot be planned out in advance
All projects use some variation of SDLC
Choosing the Predictive vs.
Adaptive Approach to the SDLC
Adaptive vs. Predictive approach
for different types of IS






Transaction processing system
Customer relationship management
system
Business intelligence and decision
support system
Emergency response system
Mobile workforce support system
Healthcare system
Traditional Predictive
Approach to the SDLC





Project planning – initiate, ensure feasibility,
plan schedule, obtain approval for project
Analysis – understand business needs and
processing requirements
Design – define solution system based on
requirements and analysis decisions
Implementation – construct, test, train users,
and install new system
Support – keep system running and improve
Information System
Development Phases
“Waterfall” Approach to the
SDLC
Newer Adaptive Approaches to
the SDLC

Based on spiral model




Project cycles through development activities over and
over until project is complete
Prototype created by end of each cycle
Focuses on mitigating risk
Iteration – Work activities are repeated



Each iteration refines previous result
Approach assumes no one gets it right the first time
There are a series of mini projects for each iteration
The Spiral Life Cycle Model
Iteration of System
Development Activities
Activities of Each SDLC Phase





Predictive or adaptive approach use
SDLC
Activities of each “phase” are similar
Phases are not always sequential
Phases can overlap
Activities across phases can be done
within an iteration
Activities of Planning Phase of
SDLC





Define business problem and scope
Produce detailed project schedule
Confirm project feasibility
Staff the project (resource
management)
Launch project  official
announcement
Activities of Analysis Phase of
SDLC






Gather information to learn problem domain
Define system requirements
Build prototypes for discovery of
requirements
Prioritize requirements
Generate and evaluate alternatives
Review recommendations with
management
Activities of Design Phase of
SDLC

Design and integrate the network

Design the application architecture

Design the user interfaces

Design the system interfaces

Design and integrate the database

Prototype for design details

Design and integrate system controls
Activities of Implementation
Phase of SDLC

Construct software components

Verify and test

Convert data

Train users and document the system

Install the system
Activities of Support Phase of
SDLC

Maintain system


Enhance system



Small patches, repairs, and updates
Small upgrades or enhancements to
expand system capabilities
Larger enhancements may require
separate development project
Support users

Help desk and/or support team
System Analysis
The Activities of the Analysis
Phase
Activities of the Analysis Phase
and Their Key Questions
Fact finding





Who does it? Why? Who should?
What is done? Why? What should?
Where is it done? Why? Where
should?
When is it done? Why? When
should?
How is it done? Why? How should?
Zachman Framework for
Enterprise Architecture
Business Process
Reengineering




Questions basic assumptions for
doing business and seeks to find a
better way
Uses IT as BPR enabler
Systems analyst may discover
opportunities for process
improvement
Any project may include components
of BPR
System Requirements


New system capabilities and constraints
Functional requirements




Activities system must perform (use cases)
Based on procedures and business functions
Documented in analysis models
Nonfunctional requirements


Technical environment or performance
objectives
Usability, reliability, and security requirements
Stakeholders—The Source of
System Requirements


People with interest in successful
system implementation
Three primary groups of stakeholders

Users (use system)

Clients (pay for and own system)

Technical staff (ensure system operation)
Stakeholders Interested
in New System Development
Techniques for Information
Gathering

Original structured approach



Create model of existing system
Derive requirements from existing system
model
Current approach


Identify logical requirements for new
system
Balance the review of current business
functions with new system requirements
Information Gathering and Model
Building
Themes for InformationGathering Questions
Fact-Finding Methods







Review existing reports, forms, and procedure
descriptions
Interview and discuss processes with users
Observe and document business processes
Distribute and collect questionnaires
Conduct joint application design (JAD) sessions
Research vendor solutions
Requirement gathering though prototyping
Review Existing Reports, Forms,
and Procedure Descriptions


External industry-wide professional organizations
and trade publications
Existing business documents and procedure
descriptions within organization




Identify business rules, discrepancies, and
redundancies
Be cautious of outdated material
Obtain preliminary understanding of processes
Use as guidelines/visual cues to guide
interviews
Conduct Interviews and
Discussions with Users



Effective way to understand business
functions and rules
Time consuming and resource expensive
May require multiple sessions to




Meet all users
Understand all processing requirements
Can meet with individuals or groups of
users
List of detailed questions prepared
Preparation for Interview








Choose a setting with little distraction.
Explain the purpose of the interview.
Address terms of confidentiality.
Explain the format of the interview.
Indicate how long the interview usually takes.
Tell them how to get in touch with you later if
they want to.
Ask them if they have any questions before you
both get started with the interview.
Don't count on your memory to recall their
answers. Ask for permission to record the
interview or bring along someone to take notes.
Guidelines for Conducting an
Interview






Ask one question at a time.
Attempt to remain as neutral as
possible.
Encourage responses
Be careful about the appearance
when note taking.
Provide transition between major
topics
Don't lose control of the interview.
Distribute and Collect
Questionnaires





Limited and specific information from a
large number of stakeholders
Preliminary insight into business
Not well suited for gathering detailed
information
Closed-ended questions direct person
answering question
Open-ended questions encourage
discussion and elaboration
Observe and Document
Business Processes




Varies from office walkthroughs to
performing actual tasks
Not necessary to observe all processes
at same level of detail
May make users nervous, so use
common sense
Can document workflows with UML
activity diagrams
Research on vendor solutions


Many problems have been solved by
other companies
Positive contributions of vendor solutions




Frequently provide new ideas
May be state of the art
Cheaper and less risky
Danger

May purchase solution before understanding
problem
Joint Application Development


Joint Application Development (JAD) is
a popular fact-finding technique that
brings users into the development
process as active participants
JAD was developed by Chuck Morris of
IBM Raleigh and Tony Crawford of IBM
Toronto in the late 1970’s
Why JAD




People who actually do a job have the best
understanding of that job.
People who are trained in information technology
have the best understanding of the possibilities of
that technology.
Information systems and business processes rarely
exist in isolation. People working in these related
areas have valuable insight on the role of a system
within a larger community.
The best information systems are designed when all
of these groups work together on a project as equal
partners.
Conduct Joint Application
Design Sessions



Expedites investigation of system
requirements
Seeks to compress fact-finding,
modeling, policy formation, and
verification activities into shorter time
frame
Critical factor is to have all important
stakeholders present
Joint Application Design
Participants



Session leader trained in group dynamics
and JAD group facilitation
Knowledgeable business and system users
and policy makers
Technical staff representatives to handle




Computer and network configurations
Operating environments
Security issues
Project team members
Advantages and disadvantages
of JAD




JAD allows key users to participate effectively in
the requirements modeling process. They are
more likely to feel a sense of ownership in the
results, and support for the new system.
When properly used, JAD can result in a more
accurate statement of system requirements, a
better understanding of common goals, and a
stronger commitment to the success of the new
system.
JAD may seem more expensive and can be
cumbersome
A drawback of JAD is that it opens up a lot of
scope for inter-personal conflict.
Requirement gathering through
Prototyping

Preliminary working model of a larger,
more complex system component


Discovery, design, evolving prototypes
Prototype should be

Operative



Working model to provide “look and feel”
Focused to accomplish single objective
Quick

Built and modified rapidly with CASE tools
Advantages of prototyping







May provide the proof of concept necessary to attract
funding
Early visibility of the prototype gives users an idea of
what the final system looks like
Encourages active participation among users and
producer
Assists to identify any problems with the efficacy of
earlier design, requirements analysis and coding
activities
Helps to refine the potential risks associated with the
delivery of the system being developed
Various aspects can be tested and quicker feedback can
be got from the user
User interaction available in during development cycle of
prototype
Disadvantages of prototyping





It is important to realize that by their very
definition, prototypes will represent some
compromise from the final production design.
Producer might produce a system inadequate for
overall organization needs
User can get too involved whereas the program
can not be to a high standard
Structure of system can be damaged since many
changes could be made
Not suitable for large applications
Validating the Requirements


Make sure gathered information is
correct
Structured walkthrough



Effective means of implementing quality
control early in project
Verify and validate system requirements
Review of findings from investigation
and of models based on findings
Preliminary investigation report







Introduction
System request summery
Preliminary investigation findings
Recommendations
Time and cost estimates
Expected benefits
http://oc.course.com/sc/sad7e/forms/02%20
Preliminary%20Investigation%20Report.rtf
Assignment 1


Investigate the information services
provided by McMaster University OffCampus Resource Center (OCRC) and
identify possible improvement.
Visit OCRC web site
http://macoffcampus.mcmaster.ca/
Assignment 1



What is the objective of OCRC? Who
are the targeted users of OCRC?
What information services are provided
to student tenants?
What information services are provided
to landlords? (to explore the functions
you may need to register as a landlord)
Assignment 1



Interview a few students and landlords
who have used the system and find out
if they like the system or not and what
are their suggestions for improvement.
Visit other university student off-campus
housing services.
Provide your view on the possible
improvement of McMaster OCRC web
service.