Download Building Information Systems

Systems Development
Infsy 570
Dr. Ocker
What we Mean by Software Quality
Software Quality
Effectiveness
Usability
Efficiency
Reliability
Maintainability
Understand Modifiability
ability
Testability
Techniques for Information Gathering
in Systems Analysis
Information
Gathering
Techniques
Asking
the Users
Deriving from an
Existing System
Interviewing
Questionnaires
Group DecisionMaking
Processes
Data Analysis
Document
Analysis
Observation
Participation
Deriving from
Experimenting
the Analysis of
with the System
the Business Area
under Dev.
Business
Systems Planning
Critical Success
Factors
Decision Analysis
“Throwaway”
Prototyping
Evolutionary
Development
Systems Development Methods

Systems development - refers to all the
activities that go into producing an
information systems solution to an
organizational problem or opportunity
Various methods for building
information systems




I. traditional - systems development
life cycle
II. prototyping
III. application software packages
IV. outsourcing
I. systems development life
cycle (SDLC)




oldest method for building systems
assumes that system has a life cycle
with a beginning, middle, and end
structured type of problem solving with
distinct stages, activities, and
deliverables
each stage consists of activities which
must be completed before next stage
begins
Systems Development Life Cycle
Tasks
Systems
Analysis
Development Stages
Feasibility
Study
Requirements
Analysis
Requirements Specifications
Logical
Design
Systems
Design
Programming
(Construction)
Installation
(System
Operation
and
Maintenance)
Deliverables
Recommendation to Proceed and
System Proposal or
Recommendation to Abandon
Conceptual Design
or Programs and Databases
Physical
Design
Coding and
Testing
Conversion
Postimplementation Review
Detailed Design of System
Modules and Databases
Specification of System
Hardware and Software
Accepted System with
Complete Documentation
Installed Operational System
Recom. for Enhancement of the
System and of the Dev. Method
Recom. for Org. Adjustment
Systems Analysis




Determine what the system will do (as
opposed to how )
2 stages
1. Feasibility study (preliminary
investigation)
2. Requirements Analysis
Feasibility Study



Objective is to establish whether the
proposed system is feasible/desirable
before resources are committed
systems analyst perform a preliminary
investigation of the business
problem/opportunity
takes about 5-10% of project’s
resources (time & money)
Feasibility Study Tasks




Define problem/opportunity
establish overall objectives of system
identify users of system
establish scope of system
Outcome of Feasibility Study

Recommendation to proceed or to
abandon the project
Requirements Analysis


Objective is to produce the
requirements specifications for the
system
details about what the system will do
Requirements Analysis
establishes




Outputs of system
inputs to system
processing steps needed to transform
inputs into outputs
files and databases needed to store
data
Requirements Analysis
establishes



The volumes of data to be handled
numbers of users
file and database capacities
Information gathering techniques




1. Ask users
2. Derive from existing system
3. Derive from analysis of business
area
4. Experimenting (i.e., prototype)
Systems Design


details how the system will meet the
requirements as determined by the
systems analysis
like a blueprint for a house - details all
the specifications that give the system
its form and structure
Systems Design

Must look at:
– Hardware & Software
– Program & Modules
– Specifications of the modules
– Design the Data base
– Design the USER interface
– Develop the system procedures
Systems Design



2 types of design
logical
physical
Logical Design



A more macro level design
conceptual
activities include
– devising alternative solutions to problem
and choosing an alternative
– user interface design
– logical/conceptual design of database
Physical Design

Objective is
– to produce a complete specification of all
system modules and of interfaces between
them
– to perform the physical design of the
database
Physical Design

When the physical design is complete, the
following aspects will be specified:
– system outputs (e.g., report layouts, screen
designs)
– system inputs
– user interface
– platforms (HW, SW)
– program design
– detailed test plan
– database
– conversion plan
Programming

programming and documenting code
Testing

System pieces and later, the entire
system, are run for purpose of finding
errors
Conversion

Plan to move from old system to new
system
– parallel - old and new systems run together
– direct - turn off old, turn on new
– phased - convert new system in
increments by function
– pilot - introduce system to one
organizational area before proceeding to
the remainder of the org.
Post-implementation Review

evaluating system after it is in
production (i.e. after installed and in use
for awhile)

post-implementation audit
– Did we do what we said we would do?
Cyclical nature of SDLC

when an analyst finishes one phase and
proceeds to the next, the discovery of a
problem may force the analyst to go
back to the previous phase
Limitations of SDLC


appropriate for building large
transaction processing and
management information systems
where requirements are highly
structured and well-defined
also used for complex technical
systems (e.g. air traffic control) where
formal and rigorous requirements are
needed, along with tight controls
Drawbacks

1. resource intensive - takes lots of
time to gather detailed information and
prepare volumes of specifications
Drawbacks

2. approach is inflexible and inhibits
change – to make changes/ correct errors - repeat
appropriate life cycle activities, but must
generate more documents - substantially
increase development time and costs
– encouraged to freeze system specifications
early in development process - so changes
not encouraged
Drawbacks

3. approach not suited for decision
making applications

decision making tends to be
unstructured;
requirements change/uncertain so
difficult to specify requirements

II. Prototyping

building an experimental system rapidly
and inexpensively for users to evaluate

working version of an IS or part of the
system
preliminary model

Prototyping





iterative process of development
build preliminary design
try it out
refine it
try it out etc.
Prototyping





prototyping much more iterative than
SDLC
promotes design changes
less formal approach than SDLC
quickly generate working model of
system
no detailed specifications
Steps in prototyping





1. identify users’ basic requirements
designer works with user only long
enough to capture
basic needs
2. develop working prototype
designer creates prototype quickly
Steps in prototyping




3. use prototype
user works with prototype to determine
how well it
meets his/her needs
user suggests improvements
Steps in prototyping



4. revise and enhance prototype
designer refines prototype based on
users’ input
repeat steps 3-4 until user satisfied
Prototyping

Approved prototype becomes basis for
final specifications of the system

more rapid, iterative and informal than
SDLC
Advantages of prototyping

useful when uncertainty about
information requirements or design
solutions

e.g. requirements for decision-oriented
systems can be vague -- difficult to
specify
Advantages of prototyping

good for design of user interface (part of
system that end-users interact with)

encourages user involvement
throughout systems development
Disadvantages of Prototyping

should not substitute for careful
requirements analysis

better suited for smaller applications
III. Application software
packages



develop a system by purchasing an
application software package
application software package - set of
prewritten, precoded application
software programs that are
commercially available
packages available for common
functions such as payroll, accounts
receivable, inventory control, etc.
Choose packages when

1. functions common to many
companies

2. information systems resources for inhouse development in short supply

3. developing desktop applications for
end-users
Advantages of packages

buying completed, working system

require less internal resources upgrades received from software
supplier

reduce bottlenecks in systems
development
Disadvantages of Packages

can lack sophistication

lack of integration of several functions

may require customization - modify
package to meet specific needs
IV. Outsourcing



hire external organization to build and/or
operate systems
can outsource all or some of systems
function
advantages and disadvantages
Advantages of Outsourcing




economy - less costly
service quality - may get better service
than from internal development
predictability - outsourcing contract with
fixed price
flexibility - growth without making major
changes in IT infrastructure
Advantages of Outsourcing



making fixed costs variable - pay only
for amount of services used rather than
for maintaining internal system
freeing human resources for other
projects
freeing financial capital - can sell
technology to vendor
Disadvantages of Outsourcing




loss of control over IS function
vulnerability of strategic information trade secrets, proprietary information
dependency on viability of vender - i.e.
financial, quality of services provided
loss of knowledge and expertise