710: foundations of information systems chapter 8: information systems development

710: Foundations of Information Systems

Chapter 8: Information Systems Development

2 © Jakob Iversen, 2003

Spectacular Software

• Baggage handling at Denver International– Delayed the opening of the airport for months

causing billions of dollars in lost revenue

• Space Shuttle– Runs on 5 computers from the 1970s. Modified

for every mission. Last error recorded 10 years ago.

• Ariane 5– Exploded because software was reused in new

context

• Linux/Apache/Mozilla (and other open source products)– Developed by people who never see each other


Characteristics of Software

• Software is developed – not produced

• Software doesn’t wear out (but still requires maintenance)

• Most software is developed for specific purposes – not based on standardized components

• Changes/mistakescan be costly

110

100

Definition Development Maintenance

Price of changes


Wait a minute…

• I’m not going into IT, why should I care about how systems are developed? This is never going to be my job!– True, but most projects involve users and

business managers need to understand the process.

– You may be a customer of a project– Most businesses depend on their IS for

survival (remember strategic systems?)– You will likely be involved in at least one

systems development project in your career (grab the chance if you get it).


Participants in Systems Development


The Information Systems Planning Process

• Purpose: Look at the entire company before deciding on specific systems to be developed

• Overall strategy determines what types of systems are developed


Steps in IS Planning


Classical Approach: The Waterfall Model • Advantages

– Easy to understand– Easy to start using– Known from other

disciplines– Can be used for controlling – Curbs featuritis (scope

creep)

• Disadvantages– Highly inflexible– No iteration possible– No changes to

requirements– Results come late– More effort in some phases

Systems Investigation

Analysis / Req. Spec.

Design

Generate Code

Test

Maintenance


Systems Development Life Cycle


Phase: Systems Investigation

• Purpose: Determine probability of success of proposed system’s development project

• Feasibility Analysis


Phase: Systems Analysis

• Purpose: Examine the business context, and define the problem.

• Major activity: – Collect data about current system(s),

desired new system• Deliverable: Systems Requirements

– What is the system supposed to do?• Problem: Communication between

users and developers


Sources of Data


Request for Proposal (RFP)

• One of the most important documents generated during systems development.

• Results in a formal bid that is used to determine who gets a contract for new or modified systems.

• Specifies required resources in detail.


Phase: Testing

• Purpose: Making sure the system does what it is intended to do (adheres to specification)

• Not just done at the end!

• Test specification is ideally developed with req. spec. (V-model)


Phase: Systems Design

• Analysis: WHAT will the system do?

• Design: HOW will it do it?

• Deliverable: Design Specification– Final documentation

before programming starts

• Issue: Control Scope creep (featuritis/gold plating)

• Elements of Design– Interface design

• What does it look like? Standards?

– Data design• How are the data

structured?– Process design

• What does it do? Rules?

– Object design• How are objects

defined and structured?

– Physical design• Which hardware?


Phase: Programming

• Purpose: Use programming language to code the design specification

• Typically the most resource-demanding phase (but not the most critical in terms of project success)

• Deliverable: A running system


Implementing New Systems

Strategy Description Time Req.

Cost Risk

Direct conversion

Old system replaced overnight

Minimal Low High

Pilot start-up

New system used in a few parts of organization

Moderate

Moderate

Moderate

Phased implemen-tation

Components of system introduced one at a time

High Moderate to high

Low

Parallel implemen-tation

Old and new system used simultaneously for some time

High High Low


Start-Up Options(implementation)


Maintaining and Reviewing Systems

• Maintenance– Improvements,

modifications, corrections, updates, etc.

– New needs may come up

– New uses of existing systems

– Most of the cost is in this phase!

• Post Implementation Review– Some months after

system delivery– What was learned

from the effort?– Involves both

customers and developers

– Facilitates learning from experiences

– Is often ‘forgotten’


Analyze Design Code Test Increment 11



Incremental Model

• Total system is developed in increments• First increment: Basic functions implemented

– 80/20 rule: 80% of needs covered in 20% of functionality• Change requests are pooled and implemented in later increments• A large system can be developed by fewer people (over longer time)• This model is used for most consumer software (PC software)• Can be more expensive than waterfall model (but may give better

results)

NOTE: Not included in the book!


Prototyping, JAD, RAD

Build/ReviseModel

Listen to Customer

CustomerTests Model

• Characteristics– Involves customers/users– Build-and-discard– Iterative

• Advantages– System meets needs– Handles uncertainty– Short turn-around time

• Disadvantages– Prototype looks finished:

customer won’t wait– Quick-and dirty

development forgotten along the way


Extreme Programming (XP)• Take good software

engineering practices and take them to the extreme

• Becoming a very popular method

• Focuses on delivering results very quickly

• An example of an ”agile methodology”

• Learn more– www.xprogramming.org– www.extremeprogrammi

ng.org

• Peer review is good– Extreme: Pair

programming• Customer involvement is

good– Extreme: Customer is

part of team• Communication is good

– Extreme: Everybody in the same room

– Very little written documentation

• Fast results are good– Release system every 2-

4 weeks• Testing is good

– Extreme: Test before writing the code


Capability Maturity Model for Software (CMM)

• Becoming very popular for software process improvement (SPI)

• Takes a long time (5-10 yrs to L5)

• Pervades all aspects of SW-development


The Make-or-buy decision

• Do-it-yourself– Meets all needs, but expensive and

possibly low quality• Buy packaged software

– Cheap, but may not meet all needs– Usually high quality

• Customize packages – Problems when upgrading– Possibly low quality of customizations


Outsourcing of SW development

• Hiring a consultant or software house• Advantages

– Better expertise, Fines for delays, Clear division of responsibility, Larger projects can be handled

• Problems– Difficult communications, Problems stay hidden,

More expensive, Loss of expertise/knowledge,

• Can also be international (e.g. India)– Raises a host of new issues– Companies getting more experienced with this– A very hot topic as IT jobs are lost in the US


Outsourcing of IT Operations

• Focus on core competencies– “Do what you do best, outsource the rest”

• Common for large companies to outsource IT operations– Often billions of dollars over 10+ years

• Major players– EDS, IBM, AT&T, CSC

• Advantages– No need to worry about day-to-day operations

of network, PCs etc.

• Disadvantages– Difficult to get out of contract


Next Week

• Lecture– Chapter 9

• Group Presentations– Team 7 and 8

• Student Opinion Surveys• Exam

– Blackboard– Friday – Sunday – Two hours available– Multiple choice and short answer questions

710: foundations of information systems chapter 8: information systems development

Documents

jakob iversen

specific systems

types of systems

reflective systems development

systems investigation

software doesnt

s late

code test maintenance