© 2005 Prentice Hall 2-1

Stumpf and TeagueObject-Oriented Systems Analysis and Design with

UML

.

Chapter 2The I nform ation System

Developm ent Process

© 2005 Prentice Hall 2-2

Learning Objectives

• Describe the overall structure of the Rational Unified Process for information system development.

• Name and explain the phases of the Rational Unified Process.

• Describe how its nine core disciplines contribute to the Rational Unified Process.

• Explain the difference between incremental and iterative system development and discuss why the system development process should be both incremental and iterative.

© 2005 Prentice Hall 2-3

Learning Objectives(continued)

• Identify the different types of users of information systems.

• Discuss the principal roles and responsibilities of the participants in the system development process.

• Appreciate the skills required of successful systems analysts and designers.

• Explain the important categories of system feasibility.

• Prepare an economic feasibility analysis as part of a business plan.

© 2005 Prentice Hall 2-4

This chapter presents a simplified version of the Rational Unified Process for information system development assuming a new, custom-made system.

The Unified Process consists of four phases – Initiation, Elaboration, Construction, and Transition.

Each phase comprises several iterations. Each iteration adds capability or refinement to the system.

Overview

© 2005 Prentice Hall 2-5

Overview(continued)

The development is carried out by specialists in nine core disciplines – Business Modeling, Requirements, Design, Implementation,Test, Deployment, Configuration and Change Management, Project Management, and Environment.

The Unified Process, like all generic descriptions of system development, must always be tailored to the circumstances of each specific project.

© 2005 Prentice Hall 2-6

Overview(continued)

There are two principal groups of participants in systems analysis – users and analysts.

In planning for system development, analysts must take into consideration the different interests of different types of users.

© 2005 Prentice Hall 2-7

Overview(continued)

Systems analysts are responsible primarily for understanding, modeling, and communicating the requirements for a new system. Successful systems analysts possess interpersonal and communication skills as well as analytical and technical skills.

© 2005 Prentice Hall 2-8

Overview(continued)

System designers are responsible for the technical quality of the system design. They must assure that the system is designed to satisfy all the requirements.

Programmers are responsible for construction of the system.

© 2005 Prentice Hall 2-9

Overview(continued)

Quality assurance staff monitor the development process and provide measurements and tests which are independent of the development team.

The business case for a proposed development project incorporates an analysis of the project’s feasibility – incorporating technical, resource, organizational, schedule, and economic perspectives.

© 2005 Prentice Hall 2-10

The Rational Unified Processfor Software Development

The Rational Unified Process is organized into four phases, nine core disciplines, and iterations within the phases.

FI GURE 2.1

© 2005 Prentice Hall 2-11

Phases of the Unified Process

1. Inception: Makes the business case

2. Elaboration: Defines the system architecture

3. Construction: Constructs the system

4. Transition: Integrates the system with the using environment

Each phase terminates in a milestone and results in the delivery of a defined set of work products or artifacts.

© 2005 Prentice Hall 2-12

Core Disciplinesof the Unified Process

1. Business Modeling: Re-envisions and re-engineers the organization

2. Requirements: Defines the user requirements

3. Design: Designs the system

4. Implementation: Writes the software

5. Test: Tests the system

© 2005 Prentice Hall 2-13

Core Disciplinesof the Unified Process (continued)

6. Deployment: Integrates the software into the using organization

7. Configuration and Change Management: Manages the artifacts of the evolving system

8. Project Management: Manages the development process

9. Environment: Supports the development process with processes and tools

© 2005 Prentice Hall 2-14

Typical Distribution of Resources

FI GURE 2.7

© 2005 Prentice Hall 2-15

Iterative and Incremental System Development

Iterative development allows a part of the system to be reworked.

It improves the product by revising any part of the design or implementation that is flawed.

Incremental development organizes the process as a series of builds.

It improves the process by dividing it into these phased builds.

© 2005 Prentice Hall 2-16

Timeboxing

Timeboxing forces a development phase or cycle into a limited period of time (a timebox).FI GURE 2.8

© 2005 Prentice Hall 2-17

Participants in Systems Analysis and Design

• Users• Analysts• Designers• Programmers• Quality Assurance Specialists

© 2005 Prentice Hall 2-18

Participants in Systems Analysis and Design

FI GURE 2.9

© 2005 Prentice Hall 2-19

Participants in Systems Analysis and Design (continued)

FI G URE 2.9 (continued)

© 2005 Prentice Hall 2-20

Types of Users

• System owner: A high-level manager and decision-maker for the business area supported by the system

• Responsible user: A lower-level manager with operational responsibility for the business functions supported by the system

• Hands-on user: A person who interacts directly with the system input and output devices

• Beneficial user: A person who has no direct contact with the automated system but provides input or receives output

© 2005 Prentice Hall 2-21

Responsibilities of Users

.

FI GURE 2.10

© 2005 Prentice Hall 2-22

Responsibilities of Analysts

FI GURE 2.11

© 2005 Prentice Hall 2-23

Responsibilities of Designers

FI GURE 2.12

© 2005 Prentice Hall 2-24

Responsibilities of Programmers

.

FI GURE 2.13

© 2005 Prentice Hall 2-25

Responsibilities of Quality Assurance Staff

FI GURE 2.14

© 2005 Prentice Hall 2-26

System Change

Information system change often introduces significant organizational change.

Analysts need to understand the interests

of each type of user and work with the users to plan for change.

The plan should incorporate appropriate incentives for each type of user.

© 2005 Prentice Hall 2-27

System Feasibility

The Initiation and Elaboration phases focus on whether a proposed system development project can or should be started and taken to completion.

Feasibility analysis makes explicit:• The constraints on the system – what conditions

must be satisfied for the system to be acceptable

A feasible system satisfies all the constraints.• The criteria for comparative analysis of

alternatives

© 2005 Prentice Hall 2-28

System Feasibility `(continued)

Analysis of the feasibility of a system addresses these questions:

• What benefits is the system expected to provide for its users and major stakeholders?

• What specific objectives is the system supposed to achieve?

• What are some promising alternatives for an architecture of the new system?

• What is it likely to cost to develop the new system?

© 2005 Prentice Hall 2-29

Categories of Feasibility

• Technical: Can the proposed system be built?

• Resource: Are the required resources available when they are needed?

• Organizational: Can the system work in the culture and power structure of the organization?

• Economic: Is the system a worthwhile investment?

• Schedule or temporal: Can the system be developed and deployed in time to meet the business needs of the organization?

© 2005 Prentice Hall 2-30

Economic Feasibility Analysis

Measures of economic feasibility:• Net present value: A measure over time

of the costs and benefits of the project. Their future values are discounted to account for the time value of money.

• Break-even point: The time at which all the costs of the system will have been recovered.

• Return on investment: The ratio of the net present value of the system to the net present value of the costs.

© 2005 Prentice Hall 2-31

Economic Feasibility Analysis

(continued)

Present Value Formula

PV = FV / (1 + i )n

wherePV is the present value of a cost or benefit

for time period n.FV is the future value of a cost or benefit

in time period n.i is the interest rate for discounting

future costs or benefits.1 / (1 + i ) n is the discount factor,

dependent only on i and n.

© 2005 Prentice Hall 2-32

Economic Feasibility Analysis (continued)

( 2.18 )

FI GURE 2.18

© 2005 Prentice Hall 2-33

Summary

Best practice in system development uses a process which is iterative and incremental, such as the Rational Unified Process.

The major participants in the process are: users, systems analysts, system designers, programmers, and quality assurance specialists.