Modern Systems Analysis and Design, 9E, Joseph S.Valacich, Joey F.George
第Ⅰ部分 系统开发基础 1
第1章 系统开发环境 3
第2章 软件的来源 35
第3章 管理信息系统项目 63
第Ⅱ部分 计划 123
第4章 确定和选择系统开发项目 125
第5章 启动和计划系统开发项目 161
第Ⅲ部分 分析 211
第6章 确定系统需求 213
第7章 结构化系统过程需求 265
第8章 结构化系统数据需求 353
第IV部分 设计 433
第9章 数据库设计 435
第10章 表单和报表设计 495
第11章 界面和对话设计 531
第12章 分布式和互联网系统设计 583
第Ⅴ部分 实现 633
第13章 系统实现 635
第14章 信息系统维护 685
详细目录
第Ⅰ部分 系统开发基础
生命周期：
- 计划
- 项目确定和选择
- 项目启动和计划
- 分析
- 需求确定
- 需求结构化
- 设计
- 数据库
- 表单和报表
- 对话和界面
- 分布式和Internet系统
- 实现
- 编码
- 测试
- 安装
- 文档
- 培训
- 支持
- 维护
- 获取维护请求
- 将请求转变为更改
- 设计更改
- 实现更改
第1章 系统开发环境 3
导言 3
这三个要素——方法、 技术和工具一共同构成了系统分析与设计的组织方式。
现代化系统分析与设计的一种现代方法 6
信息系统开发与系统开发生命周期 8
系统开发过程的核心 15
传统的瀑布式SDLC 17
在传统的瀑布方法下，诸如分析与设计之类的模糊和无形的过程被赋予了确定的完成日期，而成功的衡量标准是是否满足这些日期。专注于里程碑最后期限，而不是从开发过程中获取并诠释反馈，会导致对分析与设计的关注太少。对截止日期的关注导致系统不符合用户需求并且需要大量维护，从而不必要地增加开发成本。
[!NOTE]
关注日期会急于求成。
敏捷方法 19
[!NOTE] 敏捷软件开发宣言
https://agilemanifesto.org/iso/zhchs/manifesto.html
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划也就是说，尽管右项有其价值，
我们更重视左项的价值。
极限编程 23
所有编码和测试都由两个人共同编写代码和开发测试来完成。贝克(Beck)说，结对编程不是一个人打字，另一个人看；相反，两个程序员在他们试图解决的问题上一起工作，交换信息和见解，并分享技能。与传统的编码实践相比，结对编程有4个优势: (1)开发人员之间更多(更好)的沟通: (2) 更高水平的生产力: (3) 更高质量的代码: (4) 对极限编程的其他实践的强化。
[!NOTE] 落地实践
一个功能分模块开发
Scrum 24
Scrum专为速度和多个功能性产品的发布而设计。主要单位是Sprint(冲刺)，通常运行两周到一个月。每个Sprint本身就是一个完整的项目。首先是一个 8小时的冲刺计划会议，会议关注两个问题：冲刺结束时需要交付什么，团队如何完成这项工作? Sprint目标(Sprintgoal)在Sprint期间为团队提供指导。
[!评论]
定目标
敏捷实践 25
面向对象的分析与设计 26
统一软件开发过程
(Rational Unified Process. RUP)
一种面向对象的系统开发方法。 RUP建立了开发的四个阶段初始、细化、构建和交付。每一阶段都用多个单独的迭代来组织。
在初始(inception)阶段，分析师定义范围，确定项目的可行性，了解用户需求，并准备软件开发计划。在细化(elaboration) 阶段，分析师详细描述用户需求并开发基线架构，细化阶段的大部分都是分析与设计活动。在构建（construction）阶段，软件被实际地编码和测试，井生成相应的文档。在交付 (transtion或称为“移交”)阶段，系统得到部署。
[!评论]
RUP工作内容
我们的系统开发方式 28
小结 31
关键术语 31
复习题 32
问题和练习 32
实战演练 33
参考资料 33
第2章 软件的来源 35
导言 35
系统采购 36
外包 36
外包(outsourcing)
将组织的部分或全部信息系统应用程序的开发和运营交给一家外部公司的做法。
软件来源 39
企业解决方案提供商 43
选择现成软件 48
如必须选择两个始终最重要的标准，则可能是供应商的生存能力(viability)和供应商的支持(support)。设人愿意和明天就可能无法继续营业的供应商打交道。同样，也没人愿意从以精糕的售后而闻名的供应商处获得软件授权。
[!NOTE]
个人应用也一样
验证所购软件的信息 51
重用 52
小结 57
关键术语 57
复习题 57
问题和练习 58
实战演练 58
参考资料 58
案例学习：软件的起源 60
第3章 管理信息系统项目 63
导言 63
松谷家具的背景 64
管理信息系统项目 66
启动项目 72
计划项目 76
执行项目 86
结束项目 90
项目计划的表示与日程安排 91
表示项目计划 94
使用PERT计算预计时间 94
为松谷家具构建甘特图和网络图 95
使用项目管理软件 100
建立项目开始日期 101
输入任务并分配任务关系 102
用不同的技术审查项目报告 103
小结 105
关键术语 106
复习题 107
问题和练习 107
实战演练 110
参考资料 111
案例学习：管理信息系统项目 122
第Ⅱ部分 计划
第4章 确定和选择系统开发项目 125
导言 125
确定并选择系统开发项目 126
确定并选择IS开发项目的过程 128
交付物和成果 134
企业和信息系统计划 135
企业战略计划 137
信息系统计划 140
电商应用：确定和选择系统开发项目 149
互联网基础 149
松谷家具网店 151
小结 152
关键术语 153
复习题 154
问题和练习 154
实战演练 155
参考资料 156
案例学习：确定和选择系统开发项目 159
第5章 启动和计划系统开发项目 161
导言 161
启动和计划系统开发项目 162
启动和计划开发项目的过程 163
交付物和成果 165
评估项目可行性 166
评估经济可行性 168
确定项目收益
有形收益(tangible benefit) 是指可以用钱来衡量并具有确定性的那些收益。有形收益的例子包括减少人员开支、降低交易成本或者提高利润率等。值得注意的是，并非所有有形收益都能轻易量化。例如，一个有形收益如果能使公司完成某项任务的时间减半，那么也许很难硬性地用省了多少钱来量化。
[!NOTE]
量化
无形收益(ntangible benefit)是那些不容易用钱或确定的方式来衡量的收益。无形收益可能为组织带来直接的好处，如提高员工的士气，或者具有更广泛的社会影响，如减少废物产生或资源消耗。在项目启动和计划期间，潜在的有形收益可能必须被视为无形的，因为在生命周期的这个阶段，你可能无法用金钱或确定的方式来量化它们。
金钱的时间价值
要计算三笔1500美元付款的净现值(Net Present Value, NPV), 只需将之前计算的现值相加(NPV = PV1+PV2+PV3 = 1363.65+1239 60+1126.95 = 3730.20)。换言之，在贴现事为10%的情况下，卖
方能接受3730.20美元(而不是4500美元! )的一次性付款，等同于三笔1500美元的分期付款。
评估技术可行性 179
评估其他影响可行性的因素 183
制定和审查基线项目计划 185
制定基线项目计划 186
审查基线项目计划 192
电商应用：启动和计划系统开发项目 198
为松谷家具网店启动和计划系统开发项目 198
小结 201
关键术语 201
复习题 202
问题和练习 203
实战演练 204
参考文献 205
案例学习：启动和计划系统开发项目 207
第Ⅲ部分 分析
第6章 确定系统需求 213
导言 213
执行需求确定 214
确定需求的过程 214
交付物和成果 216
确定需求的传统方法 217
访谈和倾听 218
小组访谈 223
直接观察用户 225
分析过程和其他文档 227
确定系统需求的现代方法 233
联合应用设计 234
确定需求期间使用原型设计 238
进化型原型 239
抛弃型原型 240
确定需求的激进方法 241
确定要重新设计的过程 243
颠覆性技术 244
用敏捷方法确定需求 245
持续的用户参与 245
以使用为中心的敏捷设计 247
极限编程中的规划游戏 248
电商应用：确定系统需求 251
确定松谷家具网店的系统需求 251
系统布局和导航特征 251
WebStore和网站管理系统的能力 252
客户和库存信息 253
小结 256
关键术语 257
复习题 257
问题和练习 258
实战演练 259
参考资料 260
案例学习：确定系统需求 262
第7章 结构化系统过程需求 265
导言 265
过程建模 266
为结构化分析建模系统的过程 266
交付物和成果 267
数据流绘图机制 268
定义和符号 268
开发DFD：一个例子 272
数据流绘图规则 275
DFD分解 278
平衡DFD 281
一个示例DFD 284
在分析过程中使用数据流绘图 287
DFD绘制指导原则 287
完整性
DFD完整性(DFD completeness)
当前建模的系统所需的全部组件是否都已包含并充分描述。
一致性
DFD一致性(DFD consistency)
一组嵌套的DFD中的某一层级所包含的信息在多大程度上也被包含在其他层级中。
时机
画这种DFD的时候，要假装所建模的系统从未启动过，也永远不会停止。
迭代开发
上手画的第一个DFD很少能完美捕捉到你要建模的系统。应考虑以迭代的方式一次又一次地绘制同一个图。每次尝试，你都更接近于以计模的系统或系统的某一方面。 迭代DFD开发的出发点在于，需求确定和需求结构化是SDLC分析阶段的相互作用(而不是顺序进行)的子阶段。
基元DFD
绘制DFD时，需要做的一个比较困难的决定是何时停止分解过程。最低层级的DFD称为基元DFD(primitive DFD)，即分无可分的DFD。一个规则是，一且达到最低的逻辑层次就停止绘制。
DFD作为分析工具使用 290
将DFD用于业务过程重组 291
用决策表建模逻辑 294
电商应用：使用数据流图进行过程建模 299
松谷家具网店的过程建模 299
小结 302
关键术语 302
复习题 303
问题和练习 304
实战演练 312
参考资料 312
案例学习：结构化系统过程需求 350
第8章 结构化系统数据需求 353
导言 353
数据建模最常见的格式是实体关系(entity relationship, E-R)图。面向对象的分析与设计方法则采用了一种类似的格式，称为“类图”
[!NOTE]
ER图适用结构化开发，类图适用面向对象
概念数据建模 355
基元级DFD上的数据存储的名称往往与E-R图中的数据实体的名称相对应，DFD上与数据流相关的数据元素必须由E-R图中的实体和关系的属性来说明。
[!NOTE]
数据流图与ER图的对应关系
数据流输入输出，模块设计，数据设计对应
概念数据建模过程 356
交付物和成果 358
收集概念数据建模所需的信息 360
E-R建模基础 362
实体 363
许多人刚开始学习画E-R图的时候，尤其是在已经知道如何画数
据流图的情况下，常犯的一个错误是将数据实体与源/汇混淆，或将系统输出或关系与数据流混淆。避免这种混淆的一个简单规则是:真正的数据实体会有许多可能的实例，每个实例都有一个区别性的特征，以及一个或多个其他描述性的数据。
属性 366
候选键和标识符 368
其他属性类型 369
关系 371
概念数据建模和E-R模型 373
关系度 373
关系中的基数 376
命名和定义关系 379
关联实体 380
使用E-R图进行概念数据建模的小结 383
表示超类型和子类型 383
业务规则 385
域 387
触发操作 388
预打包概念数据模型的角色：数据库模式 389
统一数据模型 390
行业专用数据模型 390
数据库模式和预打包数据模型的优点 391
电商应用：概念数据建模 392
松谷家具网店的概念数据建模 392
小结 398
关键术语 398
复习题 400
问题和练习 400
实战演练 404
参考资料 405
补充材料 8A 面向对象分析与设计：对象建模之类图 406
Hoosier Burger概念数据建模的例子 419
在实际的需求结构化步骤中，必须将所有数据类与数据存储相匹配:每个数据存储都代表一个类或一个E-R 图的某个子集， 而且每个数据类或实体都包含在一个或多个数据存储中。理想情况下，基元DFD上的每个数据存储都是一个单独的数据类或实体。
[!NOTE]
DFD的存储对应数据类就是数据
案例学习：结构化系统数据需求 429
第IV部分 设计
可在DFD中为一个过程使用一个或多个数据存储。E-R 图提供了更多的结构，但一个实体既可以非常详细，也可以相当聚合。设计数据库时，要以最基本的形式定义数据，称为规范化数据。规范化是一种经过了良好定义的方法，用于标识每个数据属性之间的关系，并规范地表示所有数据，使其在逻辑上无法再分解成更多细节。其目的是使数据设计摆脱不必要的异常现象，这些异常现象会使数据库容易出错和变得低效。
第9章 数据库设计 435
导言 435
开发逻辑数据库设计，以反映存在于信息系统的表单(硬拷贝和计算机显示)和报告中的实际数据需求。这就
是为什么数据库设计经常与信息系统的人机界面设计同时进行的原因。
[!NOTE]
数据库与界面数据联系
数据库设计 437
数据库设计过程 437
交付物和成果 439
关系数据库模型 443
结构良好的关系 444
规范化 445
规范化规则 445
函数依赖和主键 446
第二范式 447
第三范式 448
E-R图转换为关系 450
表示实体 450
表示关系 451
二元1:N和1:1关系 452
二元和更高度的M:N关系 453
一元关系 454
E-R图转换为关系的总结 456
关系合并 456
关系合并的例子 457
视图集成问题 457
同义词 457
同名异义词 458
非键之间的依赖 458
类/子类 459
Hoosier Burger的逻辑数据库设计 460
物理文件和数据库设计 463
设计字段 464
选择数据类型 464
控制数据完整性 467
设计物理表 469
排列表行 473
顺序文件组织 475
索引文件组织 475
哈希文件组织 478
文件组织小结 478
设计文件控制 479
Hoosier Burger的物理数据库设计 480
电商应用：设计数据库 482
为松谷家具网上商店设计数据库 482
小结 486
关键术语 487
复习题 488
问题和练习 489
实战演练 491
参考资料 492
案例学习：设计数据库 493
第10章 表单和报表设计 495
导言 495
设计表单和报表 496
所有表单和报表中的数据必须由应用程序的数据存储和E-R模型中的数据元素构成，或者必须从这些数据元素计算出来。(极少数情况下，数据直接从系统输人到系统输出，中途不存储到系统)。设计表单和报表时，经常会发现DFD和E-R图存在缺陷。本来就应该这样，这些图应随着设计的发展而更新。
表单(form)
一种业务文档， 包含一些预定义的数据，而且通常提供了一些地方供填写额外的数据。表单的实例通常基于一条数据库记录。
报表(report)
一种业务文档， 只包含预定义的数据是仅供查阅一种被动(非互动)文档。往往包含涉及多个不相关记录或事务处理的数据。
表单和报表设计过程 498
交付物和成果 502
格式化表单和报表 504
常规格式化准则 504
突出显示信息 507
对比有颜色和无颜色 509
显示文本 510
设计表格和列表 512
设计数字的显示时，必须确定是要使用表格还是图表。人们对该主题已经有了相当多的研究(参见Jarvenpaa & Dickson 1988关于表格和图表使用的非常具体的指南)。简单地说，研究表明，若用户的任务是从一个较大的数据集中找到一个单独的数据值，则表格较佳，而折线图更适合了解数据随时间而发生的变化。
[!NOTE] Title
表与图
表格和图表选择指南
表格用于:
请取单独的数据值。
图表用于，
快速比较数据。
了解随时间而变的趋势。
比较不同变量的点和模式。
预测要进行的活动。
以报告大量信息的形式获得相对简单的印象。
对比纸质和电子报表 517
可用性 518
可用性主要衡量的是以下三个方面的特性:
1.速度。你能高效地完成项任务吗?
2.精确性。系统是否提供了你所期望的?
3.满意度。你喜欢使用这个系统吗?
可用性的成功因素 518
衡量可用性 520
电商应用：为松谷家具网店设计表单和报表 520
常规准则 521
幸好，有许多优秀的资源可以让我们更多地了解如何设计有用的网站(Ash et al.2012. Cooper et al., 2014. Flanders & Peters, 2002; Johnson, 2007; Krug, 2014: Nielsen, 1999; Nielsen & Loranger, 2006 Shneiderman et al, 2016; https://www.nngroup.com/; http://www.webpagesthatsuck.com/。
为PVF设计窗体和报表 522
轻量级图形 522
表单和数据完整性规则 523
基于样式表的HTML 523
小结 524
关键术语 524
复习题 525
问题和练习 525
实战演练 527
参考资料 527
案例学习：窗体和报表设计 529
第11章 界面和对话设计 531
导言 531
设计界面和对话 532
界面和对话设计过程 532
交付物和成果 533
交付方法和设备 534
交互方法 534
要想进一步了解交互方法，可参考Jobnson (2007)，Seffah & Javahery (2003)，Shmeideman et al (2016)和Te'eni et al(2006)。我们讨论五种广泛使用的方法:命令语言、 菜单、 表单、对象和自然语言。
菜单交互：菜单是一个简单的选项列表:选择一个选项， 就调用一个特定的命令或激活另一个菜单。菜单已成为最泛使用的交互方法，因为用户只需要理解简单的指示物和路线选项就能高效地在系统中导航。
系统交互的硬件选择 543
设计界面 545
设计布局 546
结构化数据输入 550
控制输入数据 552
提供反馈 555
提供帮助 556
设计对话 560
设计对话序列 562
构建原型和评估可用性 565
在图形环境中设计界面和对话 566
图形界面设计问题 566
图形环境中的对话设计问题 569
电商应用：为松谷家具网店设计界面和对话 569
常规准则 570
为PVF设计界面和对话 571
带面包屑路径的菜单驱动导航 571
小结 574
关键术语 574
复习题 575
问题和练习 576
实战演练 576
参考资料 577
案例学习：界面和对话设计 579
第12章 分布式和互联网系统设计 583
导言 583
设计分布式和互联网系统 583
分布式和互联网系统设计过程 583
交付物和成果 585
设计LAN和客户端/服务器系统 586
为LAN设计系统 586
在基本LAN环境中(图12.3)，哪个工作站发出请求，哪个就负责处理数据。LAN中连接了一个或多个文件服务器。文件服务器(file server)负责管理文件操作，由连接到LAN的每台客户端计算机共享。可将每台文件服务器想象为每台客户端计算机的一个额外的硬盘。例如，你的计算机可能显示了逻辑盘符F:,但它实际是LAN中的某台文件服务器上的一个磁盘卷。
[!NOTE] Title
挂载
为客户端/服务器架构设计系统 589
为了改进基于LAN的系统，一种方式是改为使用客户端/服务器架构(Client/server architecture),即在客户端和服务器之间分配(不一定平均)应用程序的处理负担。通常，由客户端计算机负责管理用户界面(包括数据的表示)，而数据库服务器负责数据库存储和访问(包括对查询的处理)。
[!NOTE]
客户端请求数据，服务端返回处理好的结果。
可将中间件想象成水管。你在自己的房子里基本看不到水管，看到的是装满杯子的水(DiMaggio, 2008)。 与信息 系统交互时，你看当的是应用程序和数据。你清楚地意识到计算机或智能手机上使用的web界面，这类似于水。
[!NOTE]
中间件的概念
云计算 594
什么是云计算 595
管理云 601
面向服务的架构 606
服务必须遵循下面三个主要原则。
1可重用性。一个服务应该可以在许多不同的应用中使用。
2.互操作性。服务应与其他任何服务协同工作。
3.组件化，一项服务应该是简单和模块化的。
[!NOTE]
服务的意义
Web服务 607
设计互联网系统 609
互联网设计基础 609
站点一致性 611
站点管理相关设计问题 613
从不掉链 615
网站内容管理
CMS允许众多内容开发者和来源为网站提供更新的信息，他们无需了解关于HTML的任何知识。例如，人事经理可以写一份新职位描述，并用标准字处理软件(如Microsoft Word)将其发布到CMS服务器上。一且存储到CMS服务器上，招聘信息的文本就可以和标准模板合井，自动将其格式化为标准网页。格式化后，网站管理员可以审查和批准招聘信息，然后再发布到公开(内部网、互联网或外部网)的网站上。
[!NOTE]
内容更新技术
电商应用：为松谷家具网店设计分布式广告服务器 619
松谷家具网店的广告 620
设计广告组件 620
设计管理报表组件 621
小结 623
关键术语 624
复习题 625
问题和练习 626
实战演练 628
参考资料 628
案例学习：分布式和互联网系统设计 630
第Ⅴ部分 实现
第13章 系统实现 635
导言 635
系统实现 637
编码、测试和安装过程 638
要强调的是，虽然测试是在实现过程中进行的，但必须在项目的早期开始计划测试。计划涉及
确定需测试的内容和收集测试数据。这通常在分析阶段完成，因为测试需求与系统需求密切相关。
[!NOTE]
测试设计的时机
编码、测试和安装过程的交付物和成果 638
系统文档编制以及用户培训和支持的交付物和成果 640
软件应用程序测试 641
七种不同类型的测试 643
测试过程 646
关于信息系统的测试，下面有两件重要的事情需要记住。
1.测试的目的是确定系统满足要求。
2.测试必须先计划。
合并编码和测试 649
用户验收测试 650
最完整的验收测试包括alpha测试(用模拟但典型的数据来测试)、beta测试(在用户的真实工作环境中使用真实的数据来测试)以及由组织内部审计师或质保团队成员进行的系统审计。
安装 651
直接安装 652
并行安装 652
单一地点安装 653
分阶段安装 653
计划安装 654
编制系统文档 655
用户文档 657
用户培训和支持 660
培训信息系统用户 660
支持信息系统用户 663
系统实现中的组织问题 665
为什么实现有时会失败？ 665
安全问题 668
电商应用：松谷家具网店的系统实现和运作 671
为网店开发测试用例 671
bug跟踪和系统演进 673
网店的Alpha测试和Beta测试 674
安装网店 675
项目结束 675
小结 677
关键术语 678
复习题 679
问题和练习 679
实战演练 680
参考资料 681
案例学习：系统实现 683
第14章 信息系统维护 685
导言 685
维护信息系统 686
信息系统维护过程 686
交付物和成果 688
开展系统维护 689
维护类型 689
在所有类型的维护中，纠正性维护占所有维护活动的75%（Andews & Leventhal, 1993; Pressman, 2005）。
表14.1维护类型
| 类型 | 说明 |
|---|---|
| 纠正性 | 修复设计和编程错误。 |
| 适应性 | 修改系统以适应环境变化。 |
| 完善性 | 发展系统以解决新问题或利用新机会。 |
| 预防性 | 防范系统未来出问题。 |
维护成本 691
维护管理 693
控制维护请求
如何为维护请求排列优先级：
- 更改请求
- 类型？
- 纠正性：goto 下一步
- 其他
- 类型？
- 适应性/完善性：goto 下一步
- 增强
- 评估
- 需要：goto 下一步
- 不需要：中止请求并通知申请人。
- 评估
- 类型？
- 下一步：分类并排列优先级
- 从队列选择下个任务
配置管理
管理维护的最后一个方面是配置管理(configuration management),
它确保只对系统进行已授权的更改。一旦系统完成了实现和安装，用于构建系统的程序代码就代表了系统的基线模块(baseline module)。基线模块是系统最新版本的软件模块，其中每个模块都通过了组织的质
保过程和文档标准。系统管理员(system librarian)控制着基线源代码模块的签出和签入。