适应变革的系统分析与设计：第5版概要

需积分: 9 190 浏览量更新于2024-07-17 收藏 20.09MB PDF 举报

《变化中的世界中的系统分析与设计》第五版是一本由John W. Satzinger（密苏里州立大学）、Robert B. Jackson（RBJ与合作伙伴）和Stephen D. Burd（新墨西哥大学）合著的专业IT教材。该书针对快速变化的全球环境，深入探讨了系统分析与设计的关键概念和技术。本书适应当今全球化背景下，信息技术的快速发展，强调适应性、创新和跨文化交流在信息系统开发过程中的重要性。章节内容可能涵盖了以下知识点： 1. **系统分析基础**：介绍了系统分析的基本原理，包括识别问题、收集需求、确定系统边界、数据流图（DFD）和业务流程图的使用，以及如何进行可行性研究和效益分析。 2. **环境影响与战略规划**：讨论了外部环境因素（如技术、经济、社会和政治）对系统设计的影响，并讲解如何将这些因素融入战略规划中，确保系统的长期适应性和竞争优势。 3. **用户参与与需求管理**：强调了用户在系统开发过程中的中心地位，讲述了如何通过访谈、原型法和用户故事来有效获取和管理需求，以满足多样化和动态的用户需求。 4. **系统设计原则**：介绍模块化、层次结构、数据独立性和封装等设计原则，以及如何运用UML（统一建模语言）和其他工具进行可视化设计。 5. **技术选型与架构设计**：分析了不同技术栈的选择策略，包括云计算、大数据、人工智能和物联网等新兴技术，以及如何设计灵活、可扩展的系统架构。 6. **项目管理与实施**：探讨了项目管理的最佳实践，包括敏捷方法、风险管理、质量保证和变更控制，以及如何确保设计的顺利实施和交付。 7. **全球化视角**：考虑到全球市场的多样性，书中可能会涉及文化差异、语言和法律问题对系统设计的影响，以及如何创建适应多语种和跨文化的解决方案。 8. **版权和电子资源**：提到了版权注意事项，强调了电子版本的使用限制以及获取最新信息、更新和替代格式的方法。《变化中的世界中的系统分析与设计》第五版不仅提供了理论知识，还鼓励读者在实际工作中灵活应用，应对不断变化的商业和技术环境。这是一本对于IT专业人士、系统分析师和设计师，以及任何希望在数字化时代成功的企业管理者来说，不可或缺的参考书籍。

FEATURES

xiv

♦

FEATURES

Systems Analysis and Design in a Changing World, Fifth Edition, was written and developed with

both instructor and student needs in mind. Here is just a sample of the unique and exciting

features that help bring the field of systems analysis and design to life.

The text uses an integrated case study of

moderate complexity—Rocky Mountain

Outfitters (RMO)—to illustrate key

concepts and techniques.

♦

PART 1 THE SYSTEMS ANALYST

John and Liz had considered making a major commitment to business-to-consumer

(B2C) e-commerce in the early 2000s. They worried about the risk of sudden and potentially

explosive growth, but felt that they had to develop an online ordering system to remain com-

petitive. At the time, in-house staff was not trained in Web technologies, so John and Liz

decided to outsource development and operation of the Web site.

By 2007, they realized that the Web-based ordering system was substantially underper-

forming against the competition for many reasons, including the following:

• Slow and cumbersome updates to online content

• Poor coordination with in-house customer service functions

• Poor coordination between Web-based ordering and supply chain management functions

• Poor technical support and other support by the site operator

• Deteriorating relations with RMO management

In late 2006, RMO performed a detailed market analysis that showed alarming trends,

including the following:

• RMO sales growth was slower than the industry average, resulting in decreasing market

share.

• The average age of customers ordering by phone and mail was increasing, and was much

higher than the industry average age of all customers.

• Compared to competitors, RMO’s Web-based sales were a much smaller percentage of

total sales, and the average order amount was lower than the industry average.

The analysis painted a disturbing picture of declining performance. Continued strong

sales to older customers via traditional channels were offset by weak sales to younger cus-

tomers via the Web. RMO was failing to attract and retain the customers who represented the

bulk of present and future business.

2010 CATALOG

Figure 1-9

Current RMO catalog

cover (Fall 2010)

THE CUSTOMER SUPPORT SYSTEM

The RMO system development project described in this text is the customer support system

(CSS). Rocky Mountain Outfitters has always prided itself on its customer orientation. One of

the core competencies of RMO has been its ability to develop and maintain customer loyalty.

John Blankens knew and understood customer relationship management principles long before

the phrase came into common use. His pride in that knowledge has been shaken by recent sales

performance and customer complaints. He’s determined to right the ship and reenergize RMO’s

customer-oriented focus with a significant infusion of effort, technology, and money.

The application architecture plan detailed some specific objectives for the customer sup-

port system. The system should include all functions associated with providing products for

the customer, from order entry to arrival of the shipment, such as:

• Customer inquiries/catalog requests

• Order entry

• Order tracking

• Shipping

• Back ordering

• Returns

• Sales analysis

♦

PART 1 THE SYSTEMS ANALYST

Supply

Chain

Management

(SCM)

Customer

Support

System

(CSS)

Strategic

Information

Management

System

(SIMS)

Retail Store

System

(RSS)

Accounting/

Finance

System

2009–2010:

Project under way. Consultant-assisted new development to

integrate seamlessly product development, product

acquisition, manufacturing, and inventory management in

anticipation of rapid sales growth.

2010–2011:

Project beginning now. New development to implement an order-

processing and fulfillment system that seamlessly integrates

with the supply chain management system to support the three

order-processing requirements: mail order, phone order, and

direct customer access via the Web.

2011:

Package solution that can extract and analyze

supply chain and customer support information

for strategic and operational decision making and

control.

2011:

Package solution that can integrate with

customer support system.

2012:

Package intranet solution.

Human

Resource

System

2013:

Package intranet solution.

New distributed

database

integrating

corporate data

Figure 1-13

The timetable for

RMO’s application

architecture plan

An overview of the strategic

systems plan for RMO is

presented in Chapter 1 to place

the project in context. The

planned system architecture

provides for rich examples—a

client/server Windows-based

component, as well as a Web-

based, e-commerce component

with direct customer

interaction via the Internet.

The new customer support system (CSS) is the system

development project used throughout the text for examples

and explanations. It is strategically important to RMO, and

the company must integrate the new system with legacy

systems and other planned systems.

C6696_FM_CTP.4c 2/8/08 4:14 PM Page xiv

FEATURES

♦

CHAPTER 3 The Analyst as a Project Manager

♦

109

RECAP OF PROJECT PLANNING FOR RMO

Barbara and Steve spent the entire month of February putting together the schedule and plans

for the CSS. Even though Barbara was the project manager, she and Steve worked together as

peers. As a team, they could brainstorm and double-check each other’s work. They had

worked together before and had an excellent relationship—one based on mutual respect and

trust. They could be candid and knew how to work through disagreements as well as how to

come to consensus on important issues. Barbara also knew that the work Steve produced was

always well thought out and very professionally done. He was a skilled systems analyst and

would help make sure that the work done in the planning phase was solid.

The success of the overall project depended heavily on the planning Barbara and Steve did

during this phase. The foundation for all other project activities is established during project

planning. As Barbara planned for the kickoff meeting to launch the project officially, she

reviewed the areas of project management to make sure that she had addressed all of the crit-

ical issues.

For project scope management, she developed a list of business benefits, a list of system

capabilities, and a context diagram. At this point in the project, the scope definition was still

very general. She would make sure the project’s scope was precisely defined during the infor-

mation-gathering activities of the analysis phase.

She and Steve had developed a detailed work breakdown structure and entered the infor-

mation into Microsoft Project. The schedule was very detailed for the analysis phase, but less

so for the design and implementation phases. She would add those details as decisions were

made about the implementation approach. She thought that her approach to project time

management had been established, and she would have the tools necessary to track the

schedule as the project progressed.

The costs and potential benefits had been estimated and used to develop an NPV estimate.

She would redo the NPV when she redid the schedule at the end of the analysis phase to

ensure that the costs and schedule were within the allowed budget. The other part of cost

management was to monitor the costs during the life of the project. Microsoft Project would

help her track the costs of each task.

Steve had done a lot of the work to identify and assess risks during the feasibility analysis.

Barbara knew that they would both continue to look for risks and assess potential problems

during the project. She asked Steve to take time each week to assess the risks and update the

list of the highest risks for the project. She felt confident that she would not be blindsided by

some unexpected problem.

For project communication and project quality, Barbara established procedures for the

project. She set up a central database to post the project’s status, decisions, and working doc-

uments to make sure that all the team members were kept well informed. She established a

routine and format for weekly status reports from the team leaders and a status report to the

oversight committee. An example of one of her status report memos to the oversight commit-

tee is shown. These status reports all follow a standard format. In addition to the formal sta-

tus memos, she would also write more informal memos to John MacMurty. For project

quality, internal procedures required that team members and RMO users review all work

products. Other quality procedures, such as the test plan, would be established as the project

progressed.

Details about the RMO case

are integrated directly into

each chapter to make a

point or to illustrate a

concept—just-in-time

examples—rather than

isolating the case study in

separate sections of

the chapters.

Project management aspects

of the case are reinforced

throughout by use of RMO

memos describing the status

of the project in every chapter.

The same system project is

used to illustrate traditional

and object-oriented models

and solutions, so both

approaches can be understood

and directly compared.

110

♦

PART 1 THE SYSTEMS ANALYST

She and Steve had identified the other people they would like to have on the team. John

had been especially helpful in finding solid analysts who were available or who would be

available soon. In fact, Barbara had already interviewed all of the members who were coming

on board. Recognizing the importance of having a team whose members could work together,

she had scheduled several days for the team members to get to know each other, to refine

their internal working procedures, and to teach them about the tools and techniques that

would be used on the project.

All in all, it had been a very hectic but productive month. A lot of work had been done,

and a solid foundation had been established for a successful project.

CHAPTER 2 Approaches to System Development

♦

most of this textbook—we will focus on the initial development project and not on the sup-

port projects. In other words, our primary concern is with getting the system developed and

deployed the very first time.

In today’s diverse development environment, many different approaches to developing

systems are used, and they are based on different SDLCs. As you might suppose, some

approaches have been used for a long time and have varying rates of success. In the ever-

changing world of information technology, new and unique approaches to building systems

have emerged, which also have varying success rates. Although it is difficult to find a single,

comprehensive classification system that encompasses all of the approaches, one useful tech-

nique is to categorize SDLC approaches according to whether they are more predictive or

adaptive. These two classifications represent the end points of a continuum from completely

predictive to completely adaptive (see Figure 2-1).

Recognize that any specific project you work on will have some predictive

and some adaptive elements.

BEST PRACTICE

The choice of SDLC varies depending on the project

Predictive

SDLC

Adaptive

SDLC

Requirements well understood

and well defined.

w technical risk.

Requirements and needs

uncertain.

High technical risk.

Figure 2-1

Predictive versus

adaptive approaches to

the SDLC

A predictive approach to the SDLC is an approach that assumes that the development

project can be planned and organized in advance and that the new information system can

be developed according to the plan. Predictive SDLCs are useful for building systems that are

well understood and defined. For example, a company may want to convert its old, main-

frame inventory system to a newer networked client/server system. In this type of project, the

staff already understands the requirements very well, and no new processes need to be added.

So, the project can typically be planned carefully, and the system can be built according to the

specifications.

At the other end of the scale, an adaptive approach to the SDLC is used when the exact

requirements of a system or the users’ needs are not well understood. In this situation, the

project cannot be planned completely in advance. Some requirements of the system may yet

need to be determined, after some preliminary development work. Developers should still be

able to build the solution, but they must be flexible and adapt the project as it progresses.

In practice, any project could have—and most do have—both predictive and adaptive ele-

ments. That is why Figure 2-1 shows the characteristics as end points on a sliding scale—not

as two mutually exclusive categories. The predictive approaches are more traditional and were

invented from the 1970s to the 1990s. Many of the newer, adaptive approaches have evolved

along with the object-oriented approach and were created during the 1990s and into the

twenty-first century. Let’s first look at some of the more predictive approaches and then exam-

ine some of the newer adaptive approaches.

THE TRADITIONAL PREDICTIVE APPROACHES TO THE SDLC

The development of a new information system requires several different, but related, activities.

In predictive approaches, we first have a group of activities that plan, organize, and schedule

the project, usually called project planning activities. These activities map out the overall

predictive

approach

an SDLC approach that

assumes the

development project can

be planned and organized

in advance and that the

new information system

can be developed

according to the plan

adaptive

approach

an SDLC approach that is

more flexible, assuming

that the project cannot be

planned out completely in

advance but must be

modified as it progresses

The text describes both

predictive and adaptive

approaches to the SDLC,

and recommends iterative

development for many

projects.

Each chapter includes

several Best Practice

features that highlight

the latest thinking on

techniques and tools.

C6696_FM_CTP.4c 2/8/08 4:14 PM Page xv

FEATURES

xvi

♦

FEATURES

As Monica reviewed Stewart’s record, she found that he had

done an excellent job as a team leader on his last project. His last

assignment was as a combination team leader/systems analyst on a

four-person team. He had been involved in systems analysis, design,

and programming, and he also managed the work of the other three

team members. He had assisted in the development of the project

schedule and had been able to keep his team right on schedule. It

also appeared that the quality of his team’s work was as good as, if

not better than, other teams on the project. She wondered what

advice she should give him to help him advance his career. She was

also wondering if now was the time to give him his own project.

1. Do you think the decision by CLT to build its own project

managers from the existing employee base is a good one?

What advice would you give to CLT to make sure that it

has strong project management skills in the company?

2. What kind of criteria would you develop for Monica to use

to measure whether Stewart (or any other potential project

manager) is ready for project management responsibility?

3. How would you structure the job for new project man-

agers to ensure, or at least increase the possibility of, a

high level of success?

4. If you were Monica, what kind of advice would you give to

Stewart about managing his career and attaining his

immediate goal to become a project manager?

RETHINKING ROCKY MOUNTAIN OUTFITTERS

The chapter identified six areas of project feasibility

that need to be evaluated for any new project.

However, as indicated, each of these areas of feasi-

bility can also be considered an evaluation of the

potential risks of the project. Based on your under-

standing of Rocky Mountain Outfitters, both from this chapter and

the information provided in Chapter 1, build a table that summa-

rizes the risks faced by RMO for this new project. Include four

columns titled (1) Project risk, (2) Type of risk, (3) Probability of risk,

and (4) Steps to alleviate risk.

Identify as many risks to the project as you can. Type of risk

means the category or area of the project feasibility that is at risk. It

might help you think about risks in the different categories, for

example (1) risk management, (2) economic, (3) organizational and

cultural, (4) technological, (5) schedule, and (6) resources. The chap-

ter provided a few examples of risk in each of these areas. However,

many other risks can cause project failures. Think as broadly as pos-

sible and expand the list of potential risks in each area.

Obviously, other kinds of risks are associated with a project of

the magnitude of the customer support system. You might want to

consider some risks external to the company, such as economic,

marketplace, legal, environment, and so forth. Other types of inter-

nal risks might also be associated with components that are pur-

chased or outsourced, such as development tools, learning curves,

poor quality of purchased components, and failure of vendors.

A common risk management technique is to build a table and iden-

tify the top 10 risks to the project. Contingency plans can then be built

for the top 10 risks. Periodically, the project management team reevalu-

ates the risk list to determine the current top 10 risks. After you build the

table, identify which risks you would classify as the top 10 risks.

FOCUSING ON RELIABLE PHARMACEUTICAL SERVICE

Chapter 2 discussed Reliable Pharmaceutical

Service’s Web-based application to connect its

client nursing homes directly with a new pre-

scription and billing system. You considered both the risks of a

sequential, waterfall approach to the SDLC and the risks of an itera-

tive and incremental approach to the SDLC for its development.

1. Now consider the way the project was probably initiated.

To what extent is the project the result of (a) an opportu-

nity, (b) a problem, or (c) a directive?

2. Many of the system users (such as employees at health-care

facilities) are not Reliable employees. What risks of project

failure are associated with the mixed user community? What

would you, as a project manager, do to minimize those risks?

3. What are some of the tangible benefits to the project? What

are some of the intangible benefits? What are some of the tan-

gible and intangible costs? How would you handle the project’s

benefits and costs that will accrue to the health-care facilities—

would you include tangible benefits and costs to the nursing

homes in the cost/benefit analyses? Why or why not?

4. Overall, do you think the approach taken to the project

(sequential waterfall versus iterative and incremental)

would make a difference in the tangible and intangible

costs and benefits? Discuss.

5. Overall, do you think the approach taken to the project

would make a difference in minimizing the risks of project

failure? Discuss.

114

♦

PART 1 THE SYSTEMS ANALYST

FURTHER RESOURCES

Scott W. Ambler, Agile Modeling: Effective Practices for XP and

the RUP. John Wiley and Sons, 2004.

Jim Highsmith, Agile Project Management: Creating Innovative

Products. John Wiley and Sons, 2004.

Gopal K. Kapur, Project Management for Information,

Technology, Business, and Certification. Prentice-Hall, 2005.

Jack R. Meredith and Samuel J. Mantel Jr., Project

Management: A Managerial Approach (6th ed.). John Wiley and

Sons, Inc., 2004.

Joseph Phillips, IT Project Management: On Track from Start to

Finish. McGraw-Hill, 2002.

Project Management Institute, A Guide to the Project Management

Body of Knowledge, 3rd edition. Project Management Institute, 2004.

Walker Royce, Software Project Management: A Unified

Framework. Addison-Wesley, 1998.

Kathy Schwalbe, Information Technology Project Management,

Fifth Edition. Course Technology, 2008.

Every chapter follows up

on the RMO case details

by adding an end-of-

chapter case study named

Rethinking Rocky

Mountain Outfitters.

Each case extends an

example in the chapter or

poses additional ques-

tions to consider about

the RMO system project.

APPROACHES TO SYSTEM

DEVELOPMENT

LEARNING OBJECTIVES

After reading this chapter, you should be able to:

■ Explain the purpose and various phases of the traditional systems

development life cycle (SDLC)

■ Explain when to use an adaptive approach to the SDLC in place of the more

predictive traditional SDLC

■ Explain the differences between a model, a tool, a technique, and a

methodology

■ Describe the two overall approaches used to develop information systems:

the traditional approach and the object-oriented approach

■ Describe the key features of current trends in system development: the

Unified Process (UP), Extreme Programming (XP), and Scrum

■ Explain how automated tools are used in system development

CHAPTER

CHAPTER OUTLINE

The Systems Development Life Cycle

Activities of Each SDLC Phase

Methodologies, Models, Tools, and Techniques

Two Approaches to System Development

Current Trends in Development

Tools to Support System Development

CHAPTER 2 Approaches to System Development

♦

Kim, Mary, and Bob, graduating seniors, were discussing their recent interview visits to differ-

ent companies that recruited computer information system (CIS) majors on their campus. All

agreed that they had learned a lot by visiting the companies, but they also all felt somewhat

overwhelmed at first.

“At first I wasn’t sure I knew what they were talking about,” Kim cautiously volunteered.

During her on-campus interview, Kim had impressed Ajax Corporation with her knowledge of

data modeling. When she visited the Ajax home office data center for the second interview, the

interviewers spent quite a lot of time describing the company’s system development methodology.

“A few people said to forget everything I learned in school,” continued Kim. Ajax

Corporation had purchased a complete development methodology called IM One from a

small consulting firm. Most employees agreed it works fairly well. The people who had

worked for Ajax for quite a while thought IM One was unique, and they were very proud of it.

They had invested a lot of time and money learning and adapting to it.

“Well, that got my attention when they said forget what I learned in school,” noted Kim,

“but then they started telling me about their SDLC, about iterations, about business events,

about data flow diagrams, and about entity-relationship diagrams, and things like that.” Kim

had recognized that many of the key concepts in the IM One methodology were fairly stan-

dard models and techniques from the structured approach to system development.

“I know what you mean,” said Mary, a very talented programmer who knew just about

every new programming language available. “Consolidated Concepts went on and on about

things like OMG and UML and UP and some people named Booch, Rumbaugh, and

Jacobson. But then it turned out that they were using the object-oriented approach to develop

systems, and they liked the fact that I knew Java and VB .NET. No problem once I got past all

of the terminology they used. They said they’d send me out for training on Rational Software

Architect, a visual modeling tool for the object-oriented approach.”

Bob had a different story. “A few people said analysis and design were no longer a big

deal. I’m thinking, ‘Knowing that would have saved me some time in school.’” Bob had vis-

ited Pinnacle Manufacturing, which had a small system development group supporting man-

ufacturing and inventory control. “They said they try to just jump in and get to the code as

soon as possible. Little documentation. Not much of a project plan. Then they showed me

some books on their desks, and it looked like they had been doing a lot of reading about

analysis and design. I could see they were using Extreme Programming and agile modeling

techniques and focusing only on best practices needed for their small projects. It turns out

they just organize their work differently by looking at risk and writing user stories while

building prototypes. I recognized some sketches of class diagrams and sequence diagrams on

the boss’s whiteboard, so I felt fairly comfortable.”

Kim, Mary, and Bob all agreed that there was much to learn in these work environments

but also that many different terms and points of view are used to describe the same key con-

cepts and techniques they learned in school. They were all glad they focused on the funda-

mentals in their CIS classes and that they had been exposed to a variety of approaches to

system development.

OVERVIEW

As the experiences of Kim, Mary, and Bob demonstrate, there are many ways to develop an

information system, and doing so is very complex. Project managers rely on a variety of aids

to help them with every step of the process. The systems development life cycle (SDLC) intro-

duced in this chapter provides an overall framework for managing the process of system

DEVELOPMENT APPROACHES AT AJAX CORPORATION,

CONSOLIDATED CONCEPTS, AND PINNACLE MANUFACTURING

This edition also

includes the

Focusing

on Reliable

Pharmaceutical

Service case study,

which is included

at the end of every

chapter to provide

additional experience

with problem-solving

techniques and issues

addressed in the

chapter. Reliable is a

smaller company than

RMO, and the strategic

information system

plan and specific

system development

project provide a

different perspective to

analysis and design.

Each chapter includes an

opening case study, states

clear learning objectives,

and introduces the chapter

outline.

C6696_FM_CTP.4c 2/8/08 4:14 PM Page xvi

FEATURES

♦

xvii

CHAPTER 6 The Traditional Approach to Requirements

♦

213

Order-entry subsystem

Look up item availability

Create new order

Update order

Produce order summary reports

Produce transaction summary reports

Order fulfillment subsystem

Look up order status

Record order fulfillment

Record back order

Create order return

Produce fulfillment summary report

Customer maintenance subsystem

Provide catalog information

Produce prospective customer activity reports

Update customer account

Distribute promotional package

Create customer charge adjustment

Produce customer adjustment reports

Catalog maintenance subsystem

Update catalog

Create special product promotion

Create new catalog

Produce catalog activity reports

Figure 6-10

RMO subsystems and

use cases for each

subsystem

Order-entry

subsystem

Accounting

Credit

info

Transaction

Management

Bank

Shipping

Customer

Credit

bureau

Order confirmation

Order change

Item availability inquiry

Order details

Order change details

Transaction

summary report

Order summary reports

Order

Item availability response

Change confirmation

Figure 6-11

A context diagram for the

RMO order-entry

subsystem

246

♦

PART 2 SYSTEMS ANALYSIS ACTIVITIES

Figure 7-6 also shows that Look up item availability can be part of an «includes» relation-

ship. So, an analyst can define two types of «includes» use cases: one that is a common inter-

nal subroutine, such as Validate customer account, and is not directly referenced by an external

actor, and one that is directly referenced by external actors. Look up item availability is an exam-

ple of the latter.

Update order

Produce

order summary

report

Produce

transaction

summary

report

Management

Customer

Shipping

Clerk

Look up order

status

Create order

return

Record back

order

Record order

fulfillment

Produce

order fulfillment

report

Customer

Provide

catalog

information

Maintain

customer account

information

Distribute

promotional

package

Create

customer charge

adjustment

Clerk

Marketing

Management

Produce

customer

adjustment

report

Order-entry subsystem

Customer

Look up item

availability

Order clerk

Create new

order

Order fulfillment subsystem

Customer maintenance subsystem

Catalog maintenance subsystem

Create new

catalog

Produce

catalog activity

report

Update

catalog

Merchandising

Create special

promotion

Maintain

product

information

Figure 7-5

A use case diagram of

the customer support

system organized by

subsystem

Each chapter includes extensive figures

and illustrations designed to clarify and

summarize key points and to provide

examples of models and other deliverables

produced by an analyst. Color coding is

used to differentiate traditional models

(diagrams with blue backgrounds), object-

oriented models (diagrams with light tan

backgrounds), and models used with

both approaches (diagrams with yellow

backgrounds).

Margin definitions of key terms are placed in the

text when the term is first used.

CHAPTER 7 The Object-Oriented Approach to Requirements

♦

253

entering input data and receiving output data. The idea is the same with both diagrams; the

level of detail is different.

The box labeled :Sy

stem

is an object that represents the entire automated system. In SSDs

and all interaction diagrams, analysts use object notation instead of class notation. Object

notation indicates that the box refers to an individual object and not the class of all similar

objects. The notation is simply a rectangle with the name of the object underlined. The colon

before the underlined class name is a frequently used, but optional, part of the object nota-

tion. In an interaction diagram, the messages are sent and received by individual objects, not

by a class. In an SSD, the only object included is one representing the entire system.

Underneath the actor and the :Sy

stem are vertical dashed lines called lifelines. A lifeline,

or object lifeline, is simply the extension of that object, either actor or object, throughout the

duration of the SSD. The arrows between the lifelines represent the messages that are sent or

received by the actor or the system. Each arrow has an origin and a destination. The origin of

the message is the actor or object that sends it, as indicated by the lifeline at the arrow’s tail.

Similarly, the destination actor or object of a message is indicated by the lifeline that is

touched by the arrowhead. The purpose of lifelines is to indicate the sequence of the mes-

sages sent and received by the actor and object. The sequence of messages is read from top to

bottom in the diagram.

A message is labeled to describe both the message’s purpose and any input data being

sent. The syntax of the message label has several options; the simplest forms are shown in

Figure 7-10. Remember that the arrows are used to represent both a message and input data.

But what is meant by the term message here? In a sequence diagram, a message is considered

to be an action that is invoked on the destination object, much like a command. Notice in

Figure 7-10 that the input message is called inquireOnItem. The clerk is sending a request, or

a message to the system, to find an item. The input data that is sent with the message is con-

tained within the parentheses, and in this case it is data to identify the particular item. The

syntax is simply the name of the message followed by the input parameters in parentheses.

This form of syntax is attached to a solid arrow.

inquireOnItem (catalogID, prodID, size)

item information

Clerk

:System

The object lifeline; shows

the “sequence”

top to bottom

Optional note to explain

something in a diagram

A returned value

The actor

interacting with

the system

An object

(underlined)

representing the

automated system

An input message

item information:

description, price, quantity

of messages,

Figure 7-10

Sample system sequence

diagram (SSD)

The returned value has a slightly different format and meaning. Notice the arrow is a dashed

arrow. A dashed arrow is used to indicate a response or an answer and, as shown in the figure, it

immediately follows the initiating message. The format of the label is also different. Because it

is a response, only the data that is sent on the response is noted. There is no message requesting

lifeline, or object

lifeline

the vertical line under an

object on a sequence

diagram to show the

passage of time for the

object

C6696_FM_CTP.4c 2/8/08 4:14 PM Page xvii

FEATURES

xviii

♦

FEATURES

SUMMARY

System development projects are organized around the systems development life cycle (SDLC), and phases of

the SDLC include activities that must be completed for any system development project. The traditional SDLC

phases are project planning, analysis, design, implementation, and support. Some SDLCs are based on a more

predictive approach to the project, and other SDLCs are based on a more adaptive approach. System develop-

ers learn the SDLC phases and activities sequentially, based on the waterfall model; in practice, however, the

phases overlap and projects contain many iterations of analysis, design, and implementation activities.

You can develop an information system in lots of ways. All development projects use the SDLC to manage

the project, plus models, techniques, and tools that make up a system development methodology. A system

development methodology provides guidelines to follow for completing every activity in the SDLC, and many

different methodologies are in use. Most methodologies are based on one of two approaches to information

systems development: the traditional approach or the object-oriented approach.

Some current trends in system development include the Unified Process (UP), Extreme Programming (XP),

and Scrum. These methodologies provide innovative insights into best practices in system development and

are becoming influential.

Visual modeling tools are special tools designed to help analysts complete development tasks, including

modeling and generating program statements directly from the models.

KEY TERMS

adaptive approach, p. 39

analysis activities, p. 45

application, p. 47

class diagram, p. 60

data flow diagram (DFD), p. 56

design activities, p. 46

entity-relationship diagram (ERD), p. 57

help desk, p. 49

implementation activities, p. 47

incremental development, p. 44

information engineering, p. 58

integrated development environment (IDE), p.51

iteration, p. 43

model, p. 50

object, p. 59

object-oriented analysis (OOA), p. 60

object-oriented approach, p. 59

object-oriented design (OOD), p. 60

object-oriented programming (OOP), p. 60

phases, p. 40

predictive approach, p. 39

problem domain, p. 46

project, p. 38

project planning, p. 45

prototype, p. 42

repository, p. 64

spiral model, p. 42

structure chart, p. 55

structured analysis, p. 56

structured approach, p. 53

structured design, p. 55

structured program, p. 53

support activities, p. 48

system development methodology, p. 49

systems development life cycle (SDLC), p. 38

technique, p. 51

tool, p. 51

top-down programming, p. 54

Unified Process (UP), p. 61

visual modeling tools, p. 51

waterfall model, p. 40

CHAPTER 2 Approaches to System Development

♦

End-of-chapter

material includes a

detailed summary,

and an indexed list

of key terms.

EXPERIENTIAL EXERCISES

1. Using Microsoft Project, build a project schedule based on the

following scenario. Print the Gantt chart. If required by your

teacher, also print the Network Diagram (i.e., a PERT chart).

In the table to the right is a list of tasks a student can per-

form to have an international experience by attending a

university abroad. You can build schedules for several ver-

sions of this set of tasks. For the first version, assume that

all predecessor tasks must finish before the succeeding

task can begin (the simplest version). For a second version,

identify several tasks that can begin a few days before the

end of the predecessor task. For a third version, modify the

second version so that some tasks can begin a few days

after the beginning of a predecessor task. Also, insert a

few overview tasks such as Application tasks, Preparation

tasks, Travel tasks, and Arrival tasks. Be sure to state your

assumptions for each version.

2. Build a project plan to show your progress through college.

Include the course prerequisite information. If you have

access to Microsoft Project or another tool, enter the infor-

mation in the project management tool.

3. Using information from your organizational behavior classes

or other sources, write a one-page paper on what kinds of

team-building and training activities might be appropriate

as the project team is expanded for the analysis phase.

4. Ask a systems analyst about the SDLC that his or her com-

pany uses. If possible, ask the analyst to show you a copy

of the project schedule. To what extent is iterative develop-

ment used?

5. Ask a project manager for his or her opinion on each of the

eight project management knowledge areas.

6. Go to the CompTIA Web site (www.compTIA.org) and find

the requirements for the project manager exam (CompTIA

Project+). Write a one-page summary of the expertise and

knowledge required to pass the exam.

Task ID Description Duration (days) Predecessor

1 Obtain forms 1 None

from the international

exchange office

2 Fill out and send 3 1

in the foreign

university application

3 Receive approval 21 2

from the foreign

university

4 Apply for scholarship 3 2

5 Receive notice of 30 4

approval for

scholarship

6 Arrange financing 5 3, 5

7 Arrange for housing 25 6

in dormitory

8 Obtain a passport 35 6

and the required visa

9 Send in preregistration 2 8

forms to the university

10 Make travel 1 7, 9

arrangements

11 Determine clothing 10 10

requirements and

go shopping

12 Pack and make final 3 11

arrangements to leave

13 Travel 1 12

14 Move into the 1 13

dormitory

15 Finalize registration 2 14

for classes and other

university paperwork

16 Begin classes 1 15

CUSTOM LOAD TRUCKING

It was time for Stewart Stockton’s annual performance review. As

Monica Gibbons, an assistant vice president of information systems,

prepared for the interview, she reviewed Stewart’s assignments over

the last year and his performance. Stewart was one of the “up and

coming” systems analysts in the company, and she wanted to be

sure to give him solid advice on how to advance his career. She

knew, for example, that he had a strong desire to become a project

manager and accept increasing levels of responsibility. His desire

was certainly in agreement with the needs of the company.

Custom Load Trucking (CLT) is a nationwide trucking firm that

specializes in the rapid movement of high-technology equipment.

With the rapid growth of the communications and computer indus-

tries, CLT was feeling more and more pressure from its clients to be

able to move its loads more rapidly and precisely. Several new infor-

mation systems were planned that would enable CLT to schedule and

track shipments and trucks almost to the minute. However, trucking

was not necessarily a high-interest industry for information systems

experts. With the shortage in the job market, CLT had decided not to

try to hire project managers for these new projects but to build strong

project managers from within the organization.

CASE STUDIES

CHAPTER 3 The Analyst as a Project Manager

♦

113