新書推薦：
《
新安医学古籍整理发掘研究
》
售價：HK$
107.8
《
如何提出一个好问题（全新升级版）
》
售價：HK$
120.9
《
索恩丛书·风雨山河：清季变局中的人物与社会
》
售價：HK$
75.9
《
外太空巨型星座管控的迫切需求
》
售價：HK$
74.8
《
“Z行动”苏联空军志愿队研究（套装全2册）
》
售價：HK$
361.9
《
清华大学藏战国竹简校释（柒）：《楚居》诸篇
》
售價：HK$
132.0
《
任伯年册页精选
》
售價：HK$
330.0
《
国之大道G219自驾攻略图——314国道喀什至红其拉甫口岸、独库公路
》
售價：HK$
52.8
|
| 編輯推薦： |
|
由ACM会士、《编译原理》（龙书）合著者撰写，既覆盖软件工程全生命周期的核心原理，又结合真实行业案例与团队协作实践。教材不仅讲解开发技术，更深入阐释背后的工程逻辑，帮助学生和从业者快速衔接课堂理论与工业界真实开发需求。配套练习与延伸阅读，为自主学习与教学应用提供完备支撑。
|
| 內容簡介： |
|
本书结合作者在学术与实践中的经验，阐述了软件工程的核心。全书共10章，覆盖开发全生命周期。对于设有团队项目的课程，本书提供实用建议与模板，帮助实现课堂概念与学生项目需求的有机结合。学生将通过采用敏捷方法、需求挖掘、模块化系统设计、高效测试方法选择及进度追踪度量指标运用，深入了解工业界的软件开发流程。本书不仅讲解”如何实施”，更阐释”实施原因”，帮助学生为行业实践的改进做好储备。各章节深入探讨了诸多核心主题：如何精准获取用户真实需求，如何清晰分解架构并攻克软件系统固有的复杂性，测试覆盖率为何对检测代码中不可避免的缺陷至关重要等。本书适合作为软件工程专业的教科书，也适合软件从业者及相关技术人员参考。
|
| 關於作者： |
拉维·塞西（Ravi Sethi），美国亚利桑那大学计算机科学系荣休教授，ACM会士，曾担任Avaya实验室和贝尔实验室的高级管理职位。他合著了计算机科学经典教材《编译原理（原书第2版）》（又称“龙书”）。
王林章，南京大学计算机科学与技术系教授、博士生导师，南京大学计算机软件新技术国家重点实验室主任助理，主要研究方向为软件工程、新型软件测试方法、模型驱动软件测试与验证、自动化软件测试工具；目前面向本科生、研究生讲授软件工程、软件体系结构、软件测试等课程，积极推行课程改革。
|
| 目錄：
|
译者序
前言
第1章 绪论 1
1.1 什么是软件工程 1
1.1.1 软件工程的定义 1
1.1.2 两家公司的故事 2
1.2 需求挑战 4
1.2.1 识别客户和需求 4
1.2.2 应对需求变更 5
1.3 软件本质上具有复杂性 5
1.3.1 复杂性的来源 5
1.3.2 架构：应对程序复杂性 6
1.4 缺陷是不可避免的 8
1.4.1 修复缺陷以避免运行故障 8
1.4.2 测试简介 9
1.4.3 黑盒测试和白盒测试 9
1.5 平衡约束：一个铁三角模型 10
1.6 社会责任 10
1.6.1 案例研究：大众汽车排放
丑闻 11
1.6.2 ACM守则 11
1.6.3 案例研究：Therac-25
事故 12
1.6.4 软件项目的教训 12
1.7 结论 13
延伸阅读 14
练习 14
第2章 软件过程 17
2.1 过程与价值观指导的开发 17
2.1.1 什么是软件过程 17
2.1.2 两种开发文化：计划型与
成长型 18
2.1.3 角色模型：UNIX文化与敏捷
价值观 19
2.1.4 选择过程模型 21
2.2 团队协作的架构：Scrum
框架 22
2.2.1 Scrum概述 23
2.2.2 Scrum角色 24
2.2.3 Scrum事件 24
2.2.4 Scrum工件 26
2.2.5 小结 26
2.3 敏捷开发：极限编程 26
2.3.1 倾听：用户故事 27
2.3.2 测试：开发的核心 28
2.3.3 何时进行设计 29
2.3.4 Scrum + XP混合方法 30
2.3.5 小结 31
2.4 瀑布模型的局限性 31
2.4.1 大爆炸集成和测试的
风险 32
2.4.2 瀑布过程软件修改成本
曲线 32
2.4.3 瀑布模型风险管理 33
2.4.4 小结 35
2.5 设计和测试的层次：V模型 35
2.5.1 V模型概述 35
2.5.2 测试的层次：从单元测试
到验收测试 36
2.5.3 小结 36
2.6 额外的项目风险 36
2.6.1 粗略风险评估 37
2.6.2 Netscape Navigator 3.0：
一个成功的迭代项目 38
2.6.3 Netscape Communicator 4.0：
一个问题重重的项目 38
2.7 降低风险：螺旋模型 39
2.7.1 螺旋模型概述 39
2.7.2 小结 41
2.8 结论 41
延伸阅读 43
练习 43
第3章 用户需求 45
3.1 什么是需求 45
3.1.1 基本需求周期 45
3.1.2 案例研究：需求挑战 46
3.1.3 需求的种类 47
3.2 开发需求和软件 48
3.2.1 敏捷方法验证工作软件 49
3.2.2 案例研究：敏捷开发强调
需求 49
3.2.3 计划驱动方法验证规范 50
3.3 征询用户需求 51
3.3.1 用户需求分类 51
3.3.2 访问用户需求 52
3.3.3 案例研究：Intuit的“以用户
幸福为设计核心” 53
3.4 撰写需求：故事和功能 54
3.4.1 如何撰写有效的用户
故事 54
3.4.2 系统功能的指南 57
3.4.3 用户故事的视角 57
3.5 编写用户体验场景 58
3.5.1 用户体验场景指南 58
3.5.2 案例研究：一个医疗
场景 59
3.6 澄清用户目标 60
3.6.1 目标的属性 60
3.6.2 提出澄清问题 61
3.6.3 将目标组织成层次结构 63
3.6.4 互促与冲突的目标 64
3.7 识别安全攻击 66
3.7.1 攻击树：像攻击者一样
思考 66
3.7.2 发现可能的攻击 66
3.8 结论 68
延伸阅读 69
练习 69
第4章 需求分析 71
4.1 清单法 71
4.2 相对估算：迭代计划 73
4.2.1 锚定会让决策产生偏差 73
4.2.2 敏捷故事点 74
4.2.3 工作速率 75
4.3 结构化小组共识估算 76
4.3.1 宽带Delphi与计划扑克 76
4.3.2 原始的Delphi方法 77
4.4 平衡优先级 78
4.4.1 MoSCoW优先级排序 78
4.4.2 平衡价值和成本 79
4.4.3 平衡价值、成本与风险 79
4.5 客户满意因素与不满因素 80
4.5.1 Kano分析 81
4.5.2 功能分类 81
4.5.3 功能吸引力的生命周期 83
4.5.4 充足度的级别 83
4.6 计划驱动的估算模型 84
4.6.1 大小与工作量怎样相关 84
4.6.2 Cocomo系列估算模型 85
4.7 结论 86
延伸阅读 87
练习 87
第5章 用例 89
5.1 用例中的元素 89
5.1.1 使用参与者与目标概述一个
系统 89
5.1.2 流程和基本流程 90
5.2 备选流程：条件行为 91
5.2.1 特定的备选流程 92
5.2.2 扩展点 93
5.2.3 有界的备选流程 94
5.3 编写用例 94
5.3.1 用例模板 95
5.3.2 从参与者意图到系统
交互 95
5.3.3 如何构建用例 96
5.4 用例图 97
5.5 用例之间的关系 98
5.5.1 子流程 98
5.5.2 用例的包含 98
5.5.3 用例的扩展 98
5.6 结论 99
延伸阅读 100
练习 100
第6章 设计与架构 101
6.1 架构的角色 101
6.1.1 什么是架构 101
6.1.2 设计包含架构 102
6.1.3 什么是好的软件架构 102
6.2 设计模块化系统 103
6.2.1 模块化原则 103
6.2.2 耦合和内聚 105
6.2.3 模块设计指南 106
6.3 类图 106
6.3.1 表示一个类 107
6.3.2 类之间的关系 109
6.4 架构视图 111
6.4.1 4+1视图分组 111
6.4.2 结构与视图 114
6.5 描述系统架构 115
6.5.1 架构描述大纲 115
6.5.2 通信应用程序的系统
概述 116
6.5.3 开发视图：模块层次
结构 117
6.6 结论 118
延伸阅读 119
练习 119
第7章 架构模式 122
7.1 软件分层 122
7.1.1 分层模式 123
7.1.2 设计权衡 124
7.2 三个构建模块 126
7.2.1 共享数据模式 126
7.2.2 观察者和订阅者 127
7.3 用户界面：模型-视图-
控制器 128
7.3.1 设计决策 128
7.3.2 基本的模型-视图-控制器
模式 130
7.3.3 保持视图简洁 131
7.4 数据流架构 131
7.4.1 数据流流水线 132
7.4.2 数据流网络 134
7.4.3 无界流 135
7.4.4 大规模数据流 136
7.5 连接客户端与服务器 136
7.5.1 客户端-服务器模式 137
7.5.2 部署测试服务器 138
7.5.3 代理模式 139
7.6 产品系列和产品线 139
7.6.1 共性和差异 140
7.6.2 软件架构和产品线 140
7.6.3 产品线工程经济学 141
7.7 结论 141
延伸阅读 141
练习 141
第8章 静态检测 144
8.1 架构审查 144
8.1.1 架构审查的指导原则 144
8.1.2 发现性审查、深度挖掘审查和
回顾性审查 145
8.2 进行软件检查 146
8.2.1 传统检查的阶段 146
8.2.2 案例研究：利用数据确保
有效性 148
8.2.3 组织检查 149
8.3 代码审查：检查意图和建立
信任 150
8.3.1 投入的专家审查员 150
8.3.2 审查在几小时内完成 150
8.4 自动化静态分析 151
8.4.1 各类静态检查器 152
8.4.2 假阳性和假阴性 154
8.5 结论 154
延伸阅读 155
练习 156
第9章 测试 157
9.1 测试概述 157
9.1.1 测试中的问题 158
9.1.2 测试选择 159
9.1.3 测试充分性：何时停止
测试 159
9.1.4 测试预言：评估对测试的
响应 160
9.2 测试的层级 161
9.2.1 单元测试 161
9.2.2 集成测试 162
9.2.3 功能测试、系统测试和验收
测试 164
9.2.4 案例研究：尽早并频繁地
进行测试 164
9.3 代码覆盖Ⅰ：白盒测试 165
9.3.1 控制流图 165
9.3.2 控制流覆盖标准 167
9.4 输入覆盖Ⅰ：黑盒测试 169
9.4.1 等价类覆盖 169
9.4.2 边界值覆盖 171
9.5 代码覆盖Ⅱ： MC/DC 171
9.5.1 条件覆盖和判定覆盖是
独立的 172
9.5.2 MC/DC测试对 172
9.6 输入覆盖Ⅱ：组合测试 175
9.7 结论 178
延伸阅读 179
练习 179
第10章 质量度量指标 181
10.1 有效的度量指标 181
10.1.1 量化属性的度量指标 181
10.1.2 选择有效的度量指标 182
10.1.3 目标导向度量 184
10.2 软件质量 184
10.2.1 软件质量的多种形式 185
10.2.2 客户支持度量 186
10.3 数据集可视化 187
10.3.1 数据集 187
10.3.2 度量标准 188
10.3.3 柱状图：按类别展示
数据 189
10.3.4 甘特图：进度可视化
工具 190
10.4 产品质量：度量缺陷 191
10.4.1 缺陷的严重性 191
10.4.2 缺陷移除效率 192
10.4.3 客户发现的缺陷 193
10.4.4 CFD度量安装量而非
质量 193
10.5 运营质量提升：案例研究 194
10.5.1 如何提升软件质量 194
10.5.2 客户质量度量指标（Customer Quality Metric， CQM） 195
10.5.3 子目标：产品和过程
改进 196
10.5.4 度量过程改进 197
10.6 数据离散度：箱线图和
直方图 197
10.6.1 中位数和四分位数 197
10.6.2 箱线图通过四分位数总结
数据 199
10.6.3 数据分布的直方图 200
10.7 数据离散：统计 201
10.7.1 均值方差 201
10.7.2 离散概率分布 203
10.7.3 连续分布 203
10.7.4 正态分布 204
10.7.5 学生t分布 204
10.8 置信区间 205
10.8.1 置信区间的定义 205
10.8.2 总体标准差已知的情况 206
10.8.3 总体标准差未知的情况 207
10.9 简单线性回归 208
10.9.1 简单情况：回归线通过
原点 209
10.9.2 普通最小二乘法拟合 210
10.10 结论 211
延伸阅读 213
练习 213
附录 团队项目 214
参考文献 225
|
| 內容試閱：
|
本书的内容选取围绕以下问题展开：软件工程师究竟需要了解关于该学科的哪些知识，才能在今天具备生产力，并能在未来发挥作用？在新应用、新技术和新开发方法的推动下，这门学科在不断发展。种种迹象表明，在软件工程师的职业生涯中，这种发展还将继续。IEEE-ACM软件工程课程指南强调了持续学习的重要性：
因为在学生的职业生涯中，所学到的很多东西都会发生变化，而且只有一小部分可以在大学里学到，所以学生养成不断扩展知识的习惯至关重要。
因此，本书侧重于基本原则和最佳实践。重点不仅在于什么方法有效，还在于为什么有效。书中尽可能包括了实际案例和研究案例，还列举了一些经典的例子，以供参考。
原则是永恒的，而实践则随着对其背后假设的重新审视而不断发展。书中的原则与软件的内在属性和人性密切相关：软件是复杂的，需求是变化的，缺陷是不可避免的，团队是需要协调的。多年来，关于如何处理这些内在属性的假设一直备受考验。测试必须紧跟在编码之后进行吗？然而测试驱动开发给出了不同的答案。随着软件代码库的不断发展，开发与维护之间的界限变得模糊。所有的假设都必须接受质疑，从而适应持续部署的步伐。不变的是，设计和架构是管理复杂性的关键，迭代式敏捷方法能适应需求变化，验证和检验能减少缺陷，对结构和灵活性的良好平衡能激励团队并提高绩效。
内容组织与覆盖范围
本书适用于软件工程初级或高级入门课程。学生应具备足够的编程技能以参与团队项目，但不要求学生有任何团队经验。
ACM-IEEE指导方针强烈建议在软件工程课程中加入一个重要项目。首先，系统工程方法是针对复杂和大规模的问题而设计的。通过重要项目，学生可以体验到工程概念和方法的好处。其次，用户和团队为这门学科带来了人性化的一面。比如，与真实客户合作完成一个适合四人团队完成的项目，可以让学生体验团队合作的乐趣。附录探讨了开设兼具概念和项目的双轨课程会遇到的挑战。另请参阅以下段落中的简要概述。
本书可以分为以下几个部分：入门、构建内容、设计与架构、软件质量和度量指标。
入门：第1、2章。第1章介绍了在本书其余部分中探讨的关键主题：需求分析、软件架构和测试。本章还有一节涉及社会责任和职业操守。
第2章涉及过程，即团队活动的协调。团队文化和价值观指导着过程规则未涵盖的活动。过程模型往往专注于特定的活动，其余的则由团队来完成：Scrum专注于计划和审查活动，极限编程（XP）专注于开发实践，V模型专注于测试，螺旋模型专注于降低风险。本章将讨论团队如何将这些过程模型中的最佳实践结合到项目中。
构建内容：第3~5章。需求开发是迭代式的，既有敏捷方法，也有计划驱动方法。不同之处在于，敏捷方法更倾向于通过工作软件来验证构建什么，而计划驱动方法则倾向于验证具体文档。第3章涉及对用户通过言语、行动和情感表达的愿望和目标的征询（发现）。
用户口头表述可能与其实际行为和感受存在差异。为了帮助用户明确目标，本章介绍了三类问题，旨在确定用户动机、解决方案选项和目标量化。用户需求可以记录为用户故事、系统功能或用户体验场景。与需求相关的目标细化技术也适用于安全（如攻击树）和度量（如指标）。
第4章中的需求优先级排序技术包括MoSCoW（must-should-could-won’t，必须-应该-可以-不会）、价值-成本平衡、价值-成本-风险评估和Kano分析。Kano分析不仅基于客户的满意度，还考虑客户的不满意度。本章还包括敏捷方法中基于故事点的估算技术和计划驱动方法中基于Cocomo正式模型的估算技术。锚定会使估算出现偏差，在个人和小组估算过程中都要避免这种现象。
第5章介绍用例。若采用增量开发方法，用例分析可轻量化，从用户目标开始，逐步构建基础流程，最终根据实际需求补充替代流程。
设计与架构：第6~7章。架构是设计的一个子集，因此以下内容也适用于设计。软件架构（第6章）是管理软件复杂性的关键。模块化系统由类等单元构建而成，因此本章介绍了UML（统一建模语言）类图，并包含了设计模块化系统的指南。关于系统架构，该章介绍了视图以及如何用关键视图来描述系统。
模式（pattern）是对重复出现的问题的一种解决方案。第7章包括以下架构模式：分层、共享数据、观察者、发布-订阅、模型-视图-控制器（MVC）、客户端-服务器以及代理（broker）。客户端-服务器架构使新软件能够部署到生产系统中：负载均衡器将部分传入流量引导到试用中的新软件，直到新软件准备好投入生产。为了实现持续部署，需要具备将新软件添加到生产系统的能力。
软件质量：第8~10章。将审查（架构和代码）、静态分析和测试结合起来，在缺陷检测方面比任何一种技术本身都要有效得多。第8章讨论审查和静态分析。本章重点聚焦静态和编译时分析技术。
第9章探讨了测试，通过在特定的测试输入上运行代码来进行测试。如果测试集符合所需的覆盖标准，就可以认为测试集足够好。关于代码覆盖率，本章包括语句、分支（决策）和MC/DC覆盖。在输入域覆盖方面，本章涵盖了等价类划分和组合测试。
质量主题一直延续到第10章，本章将衡量标准和测量方法应用于质量评估和改进。本章介绍了六种质量形式：功能性、过程性、产品性、运营性、美学性和客户满意度。运营性是指系统在客户现场安装后的质量。
度量指标：第10章。本章的另一个长标题是“度量和测量针对软件质量的设计与应用”。本章主要分为三部分。第一部分介绍度量过程、有用的度量指标的设计，以及数据集的图形显示。第二部分涉及产品和运营质量度量。第三部分介绍统计技术。箱线图、直方图、方差和标准差描述了数据集中数值的离散性。最后是关于置信区间和简单线性回归的数学知识。
团队项目：附录。在一个包含概念和项目两个方向的课程中，主要的挑战在于这两个方向的目标有所不同；例如，概念方向通常涵盖多个过程模型，而项目方向只包含一个过程。一般来说，这两个方向都有自己的进度：概念方向需要耗费数周时间来讲解过程、需求、设计和测试的内容、原因和方法，而在项目的首次迭代期间，需要尽早了解关于这些主题的一些知识。
附录中讨论了一种混合方法，这种方法在团队组建和项目启动之初就将各方向统一起来。一旦学生有足够的能力开始他们的项目，就可以放松各个方向之间的耦合，这样每个方向就可以按照自己的节奏进行。
致谢
我对软件的启蒙始于Harry Huskey递给我一整盒打孔卡片，卡片上是HH-1编译器的汇编代码，HH-1是他设计的类ALGOL语言。这些代码是唯一可用的语言规范和编译器说明文档。然后，Harry让我自由发挥，看看我能做些什么，然后他就出国远行了。就这样，我开始了我的暑期工作！这份工作发生在我在坎普尔理工学院读本科的第一年结束时。当时，我所有的编程经验仅限于为IBM 1620编写一些简短的FORTRAN和汇编程序。我花了一个暑假的时间跟踪代码并进行窥孔优化。现在回想起来，如果我当时能明确Harry的要求，在每次修改后都进行测试，并询问他对系统架构的看法等，都将会对工作带来帮助。
时间快进十几年，我来到了新泽西州的贝尔实验室，有幸加入了Doug McIlroy所在的计算机科学研究中心。在该中心，UNIX操作系统即将首次从一台机器移植到另一台机器。作为用户，我开始欣赏UNIX工具文化、快速迭代以及通过用户反馈不断改进工具。Steve Johnson曾感慨过“用户无法以他的方式看待问题”，并补充说“但他们总是对的！”
我还了解到交换业务部门在构建99.999%可靠性的电话交换机时所面临的挑战：每个电话呼叫都由两端的并发过程处理。他们现有的方法是使用瀑布式过程的各种变体，有数千人参与其中。他们通过冻结需求以及严格的持续验证和检验来管理瀑布式方法的风险。
2000年，Avaya作为一家独立公司被剥离出来，我随之前往建立Avaya实验室研究中心。研究人员中有一半来自贝尔实验室，其中包括David Weiss。David建立了软件技术研究部门，并成立了一个名为 Avaya 资源中心（ARC）的小组，作为连接业务部门研发团队的桥梁。这个部门和ARC的使命是“改善Avaya的软件状况并了解它”。在David退休后，我有机会直接与ARC的Randy Hackbarth和John Palframan以及研究部门的Audris Mockus和Jenny Li合作。他们就是10.5节所描述质量提升工作的核心人员。我非常感谢他们对软件的介绍和见解。
2014年我加入亚利桑那大学时，David慷慨地分享了他在爱荷华州立大学开设的软件工程课程的资料。在亚利桑那大学，我要感谢Todd Proebsting和David Lowenthal让我有机会教授高年级和研究生水平的软件工程课程。
对于本书，我特别感谢Jon Bentley、Audris Mockus和Joann Ordille提供的见解、鼓励和评论。也感谢参与软件工程课程的众多学生。剑桥大学出版社的团队非常细致，我要感谢编辑Emily Watton和Lauren Cowles。Emily不断提出的建议极大地改进了这本书。最后，我最要感谢的是Dianne和Alexandra。当我无法再完成图表制作时，Alexandra接手了这一任务。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
暢銷書架
