没有合适的资源?快使用搜索试试~ 我知道了~
首页应对变革的世界:系统分析与设计
应对变革的世界:系统分析与设计
需积分: 9 0 下载量 6 浏览量
更新于2024-07-24
收藏 20.06MB PDF 举报
《变化中的系统分析与设计》是一本由John W. Satzinger(密苏里州立大学)、Robert B. Jackson(RBJ&Associates)和Stephen D. Burd(新墨西哥大学)合著的专业教材,旨在探讨信息技术时代下系统的分析与设计方法。随着全球化的推进,这本书第五版特别关注了澳大利亚、巴西、日本、韩国、墨西哥、新加坡、西班牙、英国、美国等多国的视角,反映了国际间的最佳实践和发展趋势。
在本书中,作者深入剖析了如何在快速变化的商业环境和技术革新中,适应并实施有效的系统分析和设计策略。主要内容可能包括但不限于以下几点:
1. **系统分析基础**:章节可能会介绍系统分析的基本概念,如识别业务需求、数据流图、数据字典的创建以及用户参与的重要性,确保理解组织的核心业务流程。
2. **变迁环境下的需求管理**:面对不断变化的需求,作者可能强调需求收集和优先级排序的方法,以及如何通过敏捷或迭代的方式进行需求管理,以保持灵活性。
3. **技术趋势与架构设计**:书中可能会涉及云计算、大数据、人工智能和物联网等新兴技术对系统设计的影响,以及如何选择和整合适当的技术栈来支持现代业务。
4. **跨文化合作与全球化影响**:考虑到全球市场的多样性,章节可能会讨论文化差异对系统设计的影响,以及如何设计具有适应性和可扩展性的解决方案。
5. **风险管理与质量控制**:随着项目环境的变化,如何有效地评估风险、制定应对策略,并确保设计满足性能、安全和法规要求,是本书可能讨论的重点。
6. **案例研究与实战演练**:书中会包含丰富的实际案例,展示了在不同行业和情境下进行系统分析和设计的具体步骤,帮助读者理解和应用理论知识。
7. **版权与电子资源**:最后的版权信息提醒读者,由于电子版权限制,某些内容可能被删减,但出版社保留随时根据后续权利规定调整的权利,鼓励读者访问官方网址获取最新版本和相关资源。
《变化中的系统分析与设计》是一本结合理论与实践,紧跟时代步伐,帮助IT专业人士提升分析和设计能力的权威参考书籍。对于那些希望在快速发展的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.
20
♦
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
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
26
♦
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
Copyright 2010 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part.
FEATURES
FEATURES
♦
xv
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
♦
39
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.
Lo
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
Copyright 2010 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part.
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.
36
APPROACHES TO SYSTEM
DEVELOPMENT
2
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
♦
37
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
Copyright 2010 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part.
FEATURES
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
Copyright 2010 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part.
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
♦
67
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
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.
Each chapter also includes ample review questions, problems and exercises to get
the student thinking critically, a collection of experiential exercises involving addi-
tional research or problem solving, end-of-chapter case studies that invite students
to practice completing analysis and design tasks appropriate to the chapter, and a list
of further resources and references.
1. What are the five phases of the traditional SDLC?
2. What characteristics of a project call for a predictive
approach to the SDLC? What characteristics of a project
call for an adaptive approach to the SDLC?
3. How is the SDLC based on the problem-solving approach
described in Chapter 1?
4. What is the objective of each phase of the SDLC? Describe
briefly.
5. How is iteration used across phases?
6. What is the difference between a model and a tool?
7. What is the difference between a technique and a
methodology?
8. Which of the two approaches to system development was
the earliest?
9. Which of the two approaches to system development is
the most recent?
10. Which of the traditional approaches focuses on overall
strategic systems planning?
11. Which of the traditional approaches is a more complete
methodology?
12. What are the three constructs used in structured
programming?
13. What graphical model is used with the structured design
technique?
14. What graphical model is used with the modern structured
analysis technique?
15. What model is the central focus of the information engi-
neering approach?
16. Explain what is meant by a waterfall life cycle model.
17. What concept suggests repeating activities over and over
until you achieve your objective?
18. What concept suggests completing part of the system and
putting it into operation before continuing with the rest of
the system?
19. What are some of the features of the Unified Process (UP)?
20. What are some of the features of Extreme
Programming (XP)?
21. What are some of the features of Scrum?
22. What are visual modeling tools? Why are they used?
THINKING CRITICALLY
1. Write a one-page paper that distinguishes among the fun-
damental purposes of the analysis phase, the design
phase, and the implementation phase.
2. Describe a system project that might have three subsys-
tems. Discuss how three iterations might be used for the
project.
3. Why might it make sense to teach analysis and design
phases and activities sequentially, like a waterfall, even
though in practice iterations are used in nearly all develop-
ment projects?
4. List some of the models that architects create to show dif-
ferent aspects of a house they are designing. Explain why
several models are needed.
5. What models might an automotive designer use to show
different aspects of a car?
6. Sketch the layout of your room at home. Now write a
description of the layout of your room. Are these both
models of your room? Which is more accurate? More
detailed? Easier to follow for someone unfamiliar with
your room?
7. Describe a “technique” you use to help you complete the
activity “Get to class on time.” What are some “tools” you
use with the technique?
8. Describe a “technique” you use to make sure you get
assignments done on time. What are some “tools” you use
with the technique?
9. What are some other techniques you use to help you com-
plete activities in your life?
10. There are at least two approaches to system development, a
variety of life cycles, and a long list of techniques and mod-
els that are used in some approaches but not in others.
Consider why this is so. Discuss these possible reasons, indi-
cating which are the most important: The field is so young;
the technology changes so fast; different organizations have
such different needs; there are so many different types of
systems; and people with widely different backgrounds are
developing systems.
REVIEW QUESTIONS
68
♦
PART 1 THE SYSTEMS ANALYST
C6696_FM_CTP.4c 2/8/08 4:14 PM Page xviii
Copyright 2010 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part.
剩余751页未读,继续阅读
点击了解资源详情
点击了解资源详情
点击了解资源详情
2018-12-18 上传
201 浏览量
2023-12-26 上传
点击了解资源详情
点击了解资源详情
点击了解资源详情
一只有爱的番茄
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功