Information Systems Project Management—David Olson
6-1
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-2
Chapter 6: System Development
Analyzing & designing systems
Prototyping
IS project types
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
State of the Industry
6-3
• There are many good ideas for
implementing computer systems in business
• Bringing in a project:
on time
within budget
as specified
is very difficult
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Software Development
Alternatives
•
•
•
•
•
•
Code-and-Fix : laissez faire
Waterfall
: sequential
Prototyping
Spiral Model
Rapid Prototyping
others
© McGraw-Hill/Irwin 2004
6-4
Information Systems Project Management—David Olson
Waterfall Model
•
•
•
•
•
•
•
•
System feasibility
Boehm (1988)
Software plans & requirements
Product design
Detailed design
Code
Integration
Implementation
Operations & Management
© McGraw-Hill/Irwin 2004
6-5
Information Systems Project Management—David Olson
Prototyping
• Develop system on a small scale
• let user try the system
• User identifies needed improvement
especially good if benefits hard to identify
(“better decision making”)
also appropriate to compare alternatives
© McGraw-Hill/Irwin 2004
6-6
Information Systems Project Management—David Olson
Spiral Model
Boehm (1990)
• Iterative prototypes
– risk analysis
– prototype
– progress
•
•
•
•
Operations concept
Software requirements
Software product design
Detailed design, code
Requirements plan
Req’ts validation
verification
implement
© McGraw-Hill/Irwin 2004
6-7
Information Systems Project Management—David Olson
Risks and Responses
• Personnel
6-8
best talent training
team building
• Budget & schedule multiple estimates
design to budget
requirements scrubbing
• Wrong functions user surveys, prototype
• User interface
prototyping, scenarios
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Risks and Responses
•
•
•
•
Excessive features
Many changes
External problems
Real-time perform
• Technical limits
6-9
requirements scrubbing
high change threshhold
benchmarking
simulation, benchmark
prototyping
cost/benefit
prototyping
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Rapid Prototyping
Feedback from users
• Problem Analysis
• Requirements Description
• Requirements Specification
• Design/Implement Prototype
• Evaluate Prototype
• Formal Specifications
© McGraw-Hill/Irwin 2004
6-10
Information Systems Project Management—David Olson
Other Systems
Development Options
• Component Assembly Projects:
typically object oriented modules
• Rapid Application Development:
compress life cycle
Computer Aided Software Engineering
Joint Application Development
© McGraw-Hill/Irwin 2004
6-11
Information Systems Project Management—David Olson
6-12
Software Development Standards
• ISO 9000
– European set of standards
– Focus on process rather than product
• Capability Maturity Model
– From Software Engineering Institute (CarnegieMellon University)
– Levels of different competencies
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-13
Effect of CMM Level
McConnell [1993]
Level
Time
(months)
40
Quality
(def/k)
9.0
LOC/hr
1
Cost
($mill)
33
2
15
32
3.0
3
3
7
25
1.0
5
4
3
19
0.3
8
5
1
16
0.1
12
© McGraw-Hill/Irwin 2004
1
Information Systems Project Management—David Olson
6-14
IS PROJECT TYPES
project management
characteristics of different
IS projects
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-15
IS Projects
• programming more automated
– CASE tools, code generators, 4GL,
systems re-engineering tools, OOL
• focus therefore on
– systems design
– development
– implementation
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-16
IS Project Types
• maintenance
• conversion
• new systems development
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-17
Maintenance Projects
by far the most common
• duration
• training
• categories
– fixing errors
– minor enhancements
– major enhancements
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-18
Duration of Maintenance Projects
• Impact on Organization’s Master Plan
biggest factor
– if significant contribution to revenue, more
likely to have established maintenance team
– can contribute as revenue source (royalties) or
as a production tool
– if less revenue impact, MORE LIKELY TO
HAVE PROJECT TEAM for maintenance
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-19
Training & Maintenance Projects
• some companies use maintenance as a
training ground
• exposure to maintenance can make an
organization’s operations much clearer
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-20
FIXING ERRORS
• clear objective - complexity depends on
– nature of the system, error, personnel
• BEST CASE:
– small system, easily traced
– can assign to someone familiar with it
• WORST CASE:
– nobody familiar with system
– very large & complex system
– system evolved from earlier versions
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-21
MINOR ENHANCEMENTS
•
•
•
•
•
adding, modifying, deleting data or reports
a degree of original design
constrained by original design
usually not under critical conditions
therefore, more likely to examine alternative
approaches
• more likely assigned to those with design
capabilities, knowledge of the organization
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-22
MAJOR ENHANCEMENTS
• design & implementation scope high
• wide-scale modification of existing
module, or development of new module
• can be a collection of minor
enhancements with some common
characteristic
• need experienced personnel
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-23
MAJOR ENHANCEMENTS
• EASIEST IF
–
–
–
–
personnel know system
clear connection to a corporate goal
straightforward processes
CASE tool used to develop
• DIFFICULT WHEN
– new personnel
– hard to assess criticality of system
– no design & implementation standards
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-24
CONVERSION PROJECTS
• change an existing system
(not necessarily computerized)
– manual to computer-based
– one computer platform to another
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Convert Manual to
Automated
• closest to pure design & development
• major pitfalls
– improper specification
– failure to accommodate changes
• need knowledge of existing system,
desired system, how to make transition
© McGraw-Hill/Irwin 2004
6-25
Information Systems Project Management—David Olson
Conversion Change
Management
• need senior management support
• need to convince affected employees
that the change will lead to better
working environment
• JOB REDEFINITION
• MAY DISPLACE EMPLOYEES - need
retraining
© McGraw-Hill/Irwin 2004
6-26
Information Systems Project Management—David Olson
6-27
Convert to New Technologies
• from one computer system to another
• NEW JOB DESCRIPTIONS
– example - text only to text & image
keyboard only to scanning, working with objects
• DATA RETRIEVAL changes
• Conversion to new or emerging
technologies much more involved
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-28
Convert to New Technologies
• SIMPLEST
–
–
–
–
new hardware similar to old
new operating system similar to old
existing applications modular
vendor supplied routines for conversion
• WORST
– major change: single task to multi-task
– line-oriented to icon-oriented
– keyboard to mouse
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-29
Language-Based Conversions
• translate from one language to another
• most from 3GL (COBOL) to 4GL
• need experts in both old & new
languages
– impact on data & code structure
– take full advantage of 4GL
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-30
Non-procedural Conversions
• instead of sequential control,
statements written as rules fired when
all conditions satisfied
• object-oriented approaches
– objects control processing
• need expertise in old & new languages
• more code reuse in object-oriented
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-31
Hardware-based Conversions
• causes
– convert to new platform for marketing purposes
– bring in-house a formerly time-shared system
– purchase new computing platform
• most effort in converting low-level input
& output processing routines
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-32
Hardware-based Conversions
• same vendor - little problem
–
–
–
–
IBM 32 bit words with 8 bit bytes
CDC 60 bit words with 6 bit bytes
code (even in same language) won’t run same
vendors may supply different codes
• BEST CASE - vendor specific I/O localized in
routines supplied by vendor
• USUALLY some adjustments required
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-33
New Systems Development
each type of system has different project
management characteristics
• transaction processing
• management control
• decision support systems
• group support systems
• executive information systems
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-34
Transaction Processing
• high volumes of quantitative data,
variety of input sources
• drive standard reports, basis for other
systems
• complexity arises from volume
– may involve complex calculations
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-35
Management Control
more specialized than transaction
processing
•
•
•
•
monitor manpower allocations
monitor project progress
monitor production levels
monitor sales
compare expected with actual
if variance too great, trigger action
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-36
Decision Support Systems
•
•
•
•
explore decision alternatives
data from a variety of sources
may include models
Project Team needs expertise in models
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-37
Group Support Systems
• allow multiple decision makers to work
on decision problem
• PROCESS oriented (communicate)
– can be different time, place
• Features
– anonymity
– brainstorming
– consensus building
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-38
Executive Support Systems
•
•
•
•
•
•
access to data of all types
much more subjective data, long range
INTERFACE critical
drill-down data tools
trend analysis - graphics & statistics
exception reports
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-39
Recap
• IS project management can involve a wide
variety of tasks
• Need to be able to get technical expertise as
well as experience with old systems
• Apply systems approach
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Reengineering Projects
6-40
Kralovec (1998)
• USAA: high-density storage (optical)
• Picture Tel System: video conferencing to save
travel
• Cellular Automated Transmission System:
portable communications - trucks to HQ, laptops
for generating paper
• United Parcel Service: pen-based computing
(DIAD)
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Babson College
6-41
Kesner (1998)
• reengineered business processes - 3 year
project
• improve records, advising, placement, fieldlearning
• Data warehousing, reduced costs 20%
• internet access
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Systems Development
Approach
Life cycle
Criteria: cost, time, performance
• Specification
• Design
• Code
• Test
© McGraw-Hill/Irwin 2004
6-42
Information Systems Project Management—David Olson
Specification
6-43
• User identifies need
• Systems analyst plans solution
• Feasibility study: clear, concise statement of
the problem
• Statement of work: specification of what is
to be done
• MOST PROJECTS DIE IN THE
SPECIFICATION PHASE
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Design
6-44
• How software will meet requirements
• OPTIONS: make or buy
in-house or outsource
• Request for Proposal: specify for bidding
• OUTPUT: detailed list of user requirements
and system requirements
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Xerox
Halper (1994)
•
•
•
•
Early 1994 outsourced IS to EDS
had profit of $620 million on 14.6 billion
shed non-core business
reduced IS staff by 2,000
© McGraw-Hill/Irwin 2004
6-45
Information Systems Project Management—David Olson
Code
• If acquire, Selection of Builder
–
–
–
–
cost
feasibility
experience
reputation
• cost-benefit study
© McGraw-Hill/Irwin 2004
6-46
Information Systems Project Management—David Olson
Data Conversion
6-47
• Important in data warehousing, data mining
• Useful for decision support, executive
information systems
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
Testing
• User evaluates system performance
• transfer to user (installation)
• TRAINING
© McGraw-Hill/Irwin 2004
6-48
Information Systems Project Management—David Olson
6-49
Implementation
• Install and check system
• User Training key to success
– Especially for enterprise-wide systems
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
6-50
Summary
• System analysis & development has evolved a
great distance
• Many methodologies exist
– Unimportant which
– Helps a great deal to focus on one
• Standards can increase development productivity
• Many types of IS projects
• Development of a system a sequence of functional
tasks
© McGraw-Hill/Irwin 2004