基本信息
- 商品名:正版新书 软件工程 第4版 修订版 软件工程领域公认的经典名著 国际上众多名校采用的软件工程课程的
- ISBN:9787115498076
- 定价:89.00
- 出版社:人民邮电出版社
- 作者:[美],莎丽·劳伦斯·弗里格(Shari,Lawrence,Pfleeger)[加],乔安妮·M.阿特利(Joanne,
参考信息(以实物为准)
- 出版时间:2019-02-01
- 印刷时间:
- 版次:3
- 印次:1
- 包装:平装
- 开本:16开
- 用纸:胶版纸
- 页数:550
- 字数:
编辑推荐
1.软件工程课程的经典教材,国际上众多名校均采用本书。
□.配有专门的配套网站,包含教学PPT和习题答案等丰富的教学资源。
本书是软件工程领域公认的经典名著,也是业界常引用的主要文献之一,被国内外众多名校广泛采用。与其他软件工程著作不同,本书注重从实践出发选择和安排素材,同时又从理论上进行了全面深入的探讨。对诸如复用、风险管理和质量工程、测度和度量等理论性比较强的主题,没有专设章节,而是融合在相关的各种软件工程活动中讲述。
本书理论阐述循序渐进,善于揭示各知识点之间的内在联系,并通过大量实例和工程实践深化和丰富理论知识;选材与时俱进,反映了业界动态,尤其是建模和敏捷方法方面的重要进展。两个贯穿全书的研究案例——信息系统案例和实时系统案例,以及书中的学期项目,引导读者很好地将概念有机地应用到实际项目中去。
内容简介
本书是软件工程领域的经典著作,国际上众多名校均采用本书作为教材。全书共分为14章,分3个部分介绍主要内容。□□部分解释为什么软件工程知识对实践者和研究者同样重要,还讨论了理解过程模型问题的必要性以及敏捷方法和精细地进行项目计划的必要性;第二部分论述开发和维护的主要步骤;第三部分主要讲述软件评估和改进。
本书适合作为计算机相关专业软件工程课程的本科教材,也适用于介绍软件工程的概念与实践的研究生课程,期望进一步学习该领域相关知识的专业人员也可以阅读本书。
目录
□ □章 软件工程概述 1
1.1 什么是软件工程 1
1.1.1 问题求解 □
1.1.□ 软件工程师的角色是什么 3
1.□ 软件工程取得了哪些进展 4
1.3 什么是好的软件 6
1.3.1 产品的质量 7
1.3.□ 过程的质量 8
1.3.3 商业环境背景下的质量 8
1.4 软件工程涉及的人员 10
1.5 系统的方法 11
1.5.1 系统的要素 11
1.5.□ 相互联系的系□ □3
1.6 工程的方法 14
1.6.1 盖房子 15
1.6.□ 构建系□ □6
1.7 开发团队的成员 17
1.8 软件工程发生了多大的□化 19
1.8.1 □化的本质 19
1.8.□ 软件工程的Wasserman规范 □0
1.9 信息系统的例子 □5
1.10 实时系统的例子 □6
1.11 本章对单个开发人员的意义 □7
1.1□ 本章对开发团队的意义 □8
1.13 本章对研究人员的意义 □8
1.14 学期项目 □8
1.15 主要参考文献 □9
1.16 练习 30
第 □章 过程和生命周期的建模 3□
□.1 过程的含义 3□
□.□ 软件过程模型 34
□.□.1 瀑布模型 34
□.□.□ V模型 37
□.□.3 原型化模型 37
□.□.4 可操作规格说明 38
□.□.5 可转换模型 38
□.□.6 阶段化开发:增量和迭代 39
□.□.7 螺旋模型 40
□.□.8 敏捷方法 41
□.3 过程建模工具和技术 44
□.3.1 静态建模:Lai表示法 45
□.3.□ 动态建模:系统动力学 47
□.4 实际的过程建模 49
□.4.1 Marvel的案例研究 49
□.4.□ 过程建模工具和技术应该具有的特性 51
□.5 信息系统的例子 51
□.6 实时系统的例子 53
□.7 本章对单个开发人员的意义 54
□.8 本章对开发团队的意义 54
□.9 本章对研究人员的意义 54
□.10 学期项目 54
□.11 主要参考文献 56
□.1□ 练习 57
第3章 计划和管理项目 58
3.1 跟踪项目进展 58
3.1.1 工作分解和活动图 60
3.1.□ 估算完成时间 61
3.1.3 跟踪进展的工具 65
3.□ 项目人员 67
3.□.1 人员角色和特性 67
3.□.□ 工作风格 70
3.□.3 项目组织 71
3.3 工作量估算 73
3.3.1 专家判断 75
3.3.□ 算法方法 77
3.3.3 机器学习方法 81
3.3.4 找出适合具体情形的模型 83
3.4 风险管理 84
3.4.1 什么是风险 84
3.4.□ 风险管理活动 85
3.5 项目计划 87
3.6 过程模型和项目管理 88
3.6.1 注册管理 88
3.6.□ 责任建模 90
3.6.3 紧密结合里程碑 9□
3.7 信息系统的例子 94
3.8 实时系统的例子 95
3.9 本章对单个开发人员的意义 96
3.10 本章对开发团队的意义 96
3.11 本章对研究人员的意义 96
3.1□ 学期项目 96
3.13 主要参考文献 97
3.14 练习 97
第4章 获取需求 100
4.1 需求过程 101
4.□ 需求引发 10□
4.3 需求的类型 105
4.3.1 解决冲突 107
4.3.□ 两种需求文档 108
4.4 需求的特性 109
4.5 建模表示法 110
4.5.1 实体-联系图 111
4.5.□ 例子:UML类图 11□
4.5.3 事件踪迹 114
4.5.4 例子:消息时序图 114
4.5.5 状态机 115
4.5.6 例子:UML状态图 116
4.5.7 例子:Petri网 119
4.5.8 数据流图 1□1
4.5.9 例子:用例 1□□
4.5.10 函数和关系 1□3
4.5.11 例子:判定表 1□4
4.5.1□ 例子:Parnas表 1□4
4.5.13 逻辑 1□5
4.5.14 例子:对象约束语言(OCL) 1□6
4.5.15 例子:Z 1□7
4.5.16 代数规格说明 1□9
4.5.17 例子:SDL数据 130
4.6 需求和规格说明语言 13□
4.6.1 统一建模语言(UML) 13□
4.6.□ 规格说明和描述语言(SDL) 133
4.6.3 软件成本降低(SCR) 133
4.6.4 需求表示法的其他特征 134
4.7 原型化需求 134
4.8 需求文档 135
4.8.1 需求定义 136
4.8.□ 需求规格说明 137
4.8.3 过程管理和需求的可跟踪性 138
4.9 确认和验证 138
4.9.1 需求确认 139
4.9.□ 验证 141
4.10 测量需求 14□
4.11 选择规格说明技术 143
4.1□ 信息系统的例子 145
4.13 实时系统的例子 147
4.14 本章对单个开发人员的意义 149
4.15 本章对开发团队的意义 149
4.16 本章对研究人员的意义 149
4.17 学期项目 150
4.17.1 前提和假设 150
4.17.□ 功能的高层描述 150
4.17.3 功能需求 150
4.17.4 数据约束 151
4.17.5 设计和接口约束 15□
4.17.6 质量需求 15□
4.18 主要参考文献 15□
4.19 练习 153
第5章 设计体系结构 156
5.1 设计过程 156
5.1.1 设计是一种创造性过程 157
5.1.□ 设计过程模型 160
5.□ 体系结构建模 161
5.3 分解和视图 16□
5.4 体系结构风格和策略 165
5.4.1 管道和过滤器 165
5.4.□ 客户—服务器 166
5.4.3 对等网络 167
5.4.4 发布—订阅 168
5.4.5 信息库 168
5.4.6 分层 169
5.4.7 组合体系结构风格 170
5.5 满足质量属性 171
5.5.1 可修改性 171
5.5.□ 性能 173
5.5.3 安全性 174
5.5.4 可靠性 175
5.5.5 健壮性 177
5.5.6 易使用性 178
5.5.7 商业目标 178
5.6 协作设计 179
5.7 体系结构的评估和改进 180
5.7.1 测量设计质量 181
5.7.□ 故障树分析 181
5.7.3 安全性分析 183
5.7.4 权衡分析 184
5.7.5 成本效益分析 188
5.7.6 原型化 190
5.8 文档化软件体系结构 191
5.8.1 视图间的映射 193
5.8.□ 文档化设计合理性 193
5.9 体系结构设计评审 193
5.9.1 确认 194
5.9.□ 验证 194
5.10 软件产品线 195
5.10.1 战略范围 197
5.10.□ 产品线体系结构的优势 197
5.10.3 产品线的演化 198
5.11 信息系统的例子 198
5.1□ 实时系统的例子 □00
5.13 本章对单个开发人员的意义 □01
5.14 本章对开发团队的意义 □01
5.15 本章对研究人员的意义 □0□
5.16 学期项目 □0□
5.17 主要参考文献 □03
5.18 练习 □03
第6章 设计模块 □05
6.1 设计方法 □05
6.□ 设计原则 □07
6.□.1 模块化 □07
6.□.□ 接口 □1□
6.□.3 信息隐藏 □13
6.□.4 增量式开发 □14
6.□.5 抽象 □15
6.□.6 通用性 □16
6.3 面向对象的设计 □18
6.3.1 术语 □18
6.3.□ 继承与对象组合 □□1
6.3.3 可替换性 □□□
6.3.4 德米特法则 □□3
6.3.5 依赖倒置 □□4
6.4 在UML中体现面向对象设计 □□5
6.4.1 过程中的UML □□5
6.4.□ UML类图 □□7
6.4.3 其他UML图 □3□
6.5 面向对象设计模式 □40
6.5.1 模板方法模式 □41
6.5.□ 工厂方法模式 □41
6.5.3 策略模式 □4□
6.5.4 装饰者模式 □4□
6.5.5 观察者模式 □44
6.5.6 组合模式 □44
6.5.7 访问者模式 □45
6.6 设计中其他方面的考虑 □47
6.6.1 数据管理 □47
6.6.□ 异常处理 □47
6.6.3 用户界面设计 □49
6.6.4 框架 □50
6.7 面向对象度量 □50
6.7.1 面向对象系统规模的度量 □51
6.7.□ 面向对象系统设计质量的度量 □5□
6.7.3 在何处进行面向对象测量 □58
6.8 设计文档 □59
6.9 信息系统的例子 □61
6.10 实时系统的例子 □6□
6.11 本章对单个开发人员的意义 □63
6.1□ 本章对开发团队的意义 □63
6.13 本章对研究人员的意义 □63
6.14 学期项目 □63
6.15 主要参考文献 □64
6.16 练习 □64
第7章 编写程序 □67
7.1 编程标准和过程 □67
7.1.1 对单个开发人员的标准 □68
7.1.□ 对其他开发人员的标准 □68
7.1.3 设计和实现的匹配 □69
7.□ 编程的指导原则 □69
7.□.1 控制结构 □69
7.□.□ 算法 □70
7.□.3 数据结构 □71
7.□.4 通用性指导原则 □73
7.3 文档 □76
7.3.1 内部文档 □76
7.3.□ 外部文档 □79
7.4 编程过程 □80
7.4.1 将编程作为问题求解 □80
7.4.□ 极限编程 □81
7.4.3 结对编程 □81
7.4.4 编程向何处去 □8□
7.5 信息系统的例子 □8□
7.6 实时系统的例子 □83
7.7 本章对单个开发人员的意义 □84
7.8 本章对开发团队的意义 □84
7.9 本章对研究人员的意义 □84
7.10 学期项目 □85
7.11 主要参考文献 □85
7.1□ 练习 □85
第8章 测试程序 □87
8.1 软件故障和失效 □87
8.1.1 故障的类型 □88
8.1.□ 正交缺陷分类 □89
8.□ 测试的相关问题 □91
8.□.1 测试的组织 □91
8.□.□ 对测试的态度 □9□
8.□.3 谁执行测试 □93
8.□.4 测试对象的视图 □93
8.3 单元测试 □95
8.3.1 检查代码 □95
8.3.□ 证明代码正确性 □97
8.3.3 测试程序构件 301
8.3.4 技术比较 304
8.4 集成测试 305
8.4.1 自底向上集成 305
8.4.□ 自顶向下集成 306
8.4.3 一次性集成 308
8.4.4 三明治集成 308
8.4.5 集成策略的比较 309
8.5 测试面向对象系统 311
8.5.1 代码测试 311
8.5.□ 面向对象测试和传统测试之间的区别 311
8.6 测试计划 313
8.6.1 计划的目的 313
8.6.□ 计划的内容 313
8.7 自动测试工具 314
8.7.1 代码分析工具 314
8.7.□ 测试执行工具 315
8.7.3 测试用例生成器 316
8.8 什么时候停止测试 316
8.8.1 故障播种 317
8.8.□ 软件中的可信度 318
8.8.3 其他的停止测试的标准 319
8.8.4 识别易出故障的代码 319
8.9 信息系统的例子 3□0
8.10 实时系统的例子 3□1
8.11 本章对单个开发人员的意义 3□1
8.1□ 本章对开发团队的意义 3□□
8.13 本章对研究人员的意义 3□□
8.14 学期项目 3□□
8.15 主要参考文献 3□□
8.16 练习 3□3
第9章 测试系统 3□5
9.1 系统测试的原则 3□5
9.1.1 软件故障根源 3□5
9.1.□ 系统测试过程 3□7
9.1.3 配置管理 3□9
9.1.4 测试小组 333
9.□ 功能测试 334
9.□.1 目的与职责 334
9.□.□ 因果图 335
9.3 性能测试 338
9.3.1 目的和职责 338
9.3.□ 性能测试的类型 338
9.4 可靠性、可用性以及可维护性 339
9.4.1 定义 339
9.4.□ 失效数据 340
9.4.3 测量可靠性、可用性和可维护性 341
9.4.4 可靠性稳定性和可靠性增长 34□
9.4.5 可靠性预测 343
9.4.6 操作环境的重要性 345
9.5 验收测试 346
9.5.1 目的和职责 346
9.5.□ 验收测试的种类 346
9.5.3 验收测试的结果 347
9.6 安装测试 348
9.7 自动化系统测试 348
9.8 测试文档 349
9.8.1 测试计划 349
9.8.□ 测试规格说明和评估 351
9.8.3 测试描述 353
9.8.4 测试分析报告 355
9.8.5 问题报告表 355
9.9 测试安全攸关的系统 357
9.9.1 设计多样性 358
9.9.□ 软件安全性案例 359
9.9.3 净室方法 361
9.10 信息系统的例子 364
9.11 实时系统的例子 366
9.1□ 本章对单个开发人员的意义 367
9.13 本章对开发团队的意义 367
9.14 本章对研究人员的意义 367
9.15 学期项目 367
9.16 主要参考文献 368
9.17 练习 368
□ □0章 交付系统 37□
10.1 培训 37□
10.1.1 培训的种类 373
10.1.□ 培训助手 374
10.1.3 培训的指导原则 375
10.□ 文档 375
10.□.1 文档的种类 375
10.□.□ 用户帮助和疑难解答 379
10.3 信息系统的例子 380
10.4 实时系统的例子 381
10.5 本章对单个开发人员的意义 381
10.6 本章对开发团队的意义 381
10.7 本章对研究人员的意义 38□
10.8 学期项目 38□
10.9 主要参考文献 38□
10.10 练习 38□
□ □1章 维护系统 384
11.1 □化的系统 384
11.1.1 系统的类型 384
11.1.□ 在系统生命周期过程中发生的□化 387
11.1.3 系统生命周期跨度 388
11.□ 维护的本质 389
11.3 维护问题 39□
11.3.1 人员问题 39□
11.3.□ 技术问题 393
11.3.3 必要的妥协 394
11.3.4 维护成本 395
11.4 测量维护特性 397
11.4.1 可维护性的外部视图 398
11.4.□ 影响可维护性的内部属性 398
11.4.3 其他的产品测量 400
11.5 维护技术和工具 401
11.5.1 配置管理 401
11.5.□ 影响分析 403
11.5.3 自动化维护工具 406
11.6 软件再生 407
11.6.1 文档重构 408
11.6.□ 重组 409
11.6.3 逆向工程 410
11.6.4 再工程 410
11.6.5 软件再生的前景 411
11.7 信息系统的例子 41□
11.8 实时系统的例子 41□
11.9 本章对单个开发人员的意义 413
11.10 本章对开发团队的意义 413
11.11 本章对研究人员的意义 414
11.1□ 学期项目 414
11.13 主要参考文献 414
11.14 练习 414
□ □□章 评估产品、过程和资源 416
1□.1 评估的方法 416
1□.1.1 特征分析 416
1□.1.□ 调查 417
1□.1.3 案例研究 417
1□.1.4 正式试验 418
1□.1.5 准备评估 418
1□.□ 选择评估技术 419
1□.□.1 关键选择因素 4□0
1□.□.□ 相信什么 4□0
1□.3 评价与预测 4□3
1□.3.1 确认预测系统 4□3
1□.3.□ 确认测量 4□5
1□.3.3 对确认的紧迫需求 4□5
1□.4 评估产品 4□6
1□.4.1 产品质量模型 4□6
1□.4.□ 建立基线和设定目标 430
1□.4.3 软件可复用性 431
1□.5 评估过程 437
1□.5.1 事后分析 437
1□.5.□ 过程成熟度模型 441
1□.6 评估资源 448
1□.6.1 人员成熟度模型 448
1□.6.□ 投资回报 450
1□.7 信息系统的例子 451
1□.8 实时系统的例子 45□
1□.9 本章对单个开发人员的意义 45□
1□.10 本章对开发团队的意义 45□
1□.11 本章对研究人员的意义 453
1□.1□ 学期项目 453
1□.13 主要参考文献 453
1□.14 练习 454
□ □3章 改进预测、产品、过程和资源 455
13.1 改进预测 455
13.1.1 预测的精确性 455
13.1.□ 处理偏误:u曲线 456
13.1.3 处理噪声:prequential似然度 458
13.1.4 重新校准预测 459
13.□ 改进产品 46□
13.□.1 审查 46□
13.□.□ 复用 464
13.3 改进过程 465
13.3.1 过程和能力成熟度 465
13.3.□ 维护 467
13.3.3 净室方法 468
13.4 改进资源 470
13.4.1 工作环境 470
13.4.□ 成本和进度的权衡 471
13.5 总体改进指导原则 47□
13.6 信息系统的例子 473
13.7 实时系统的例子 473
13.8 本章对单个开发人员的意义 473
13.9 本章对开发团队的意义 474
13.10 本章对研究人员的意义 474
13.11 学期项目 474
13.1□ 主要参考文献 475
13.13 练习 475
□ □4章 软件工程的未来 476
14.1 已经取得的进展 476
14.1.1 Wasserman的获得成熟度的措施 476
14.1.□ 当前要做的工作 478
14.□ 技术转移 478
14.□.1 现在我们怎样做出技术转移的决策 479
14.□.□ 在技术决策中使用证据 479
14.□.3 支持技术决策的证据 480
14.□.4 对证据的进一步讨论 481
14.□.5 技术转移的新模型 483
14.□.6 改进技术转移的下一步 483
14.3 软件工程中的决策 484
14.3.1 大量的决策 484
14.3.□ 群体决策 486
14.3.3 我们实际上如何决策 486
14.3.4 群体实际上如何决策 488
14.3.5 一个适度的观察研究 489
14.3.6 获得的经验教训 49□
14.4 软件工程的职业化:执照发放、认证和伦理 49□
14.4.1 将重点放在人员上 493
14.4.□ 软件工程教育 493
14.4.3 软件工程知识体系 495
14.4.4 给软件工程师颁发执照 496
14.4.5 认证 500
14.4.6 伦理守则 50□
14.4.7 职业发展 503
14.4.8 研究和实践的进一步发展 504
14.5 学期项目 505
14.6 主要参考文献 505
14.7 练习 505
参考文献注解 507
索引 536
作者简介
Shari Lawrence Pfleeger 世界范围内享有盛誉的软件工程学者,在软件开发领域有着数十年的丰富经验,主要从事软件工程和信息技术的教学、咨询和研究。现任美国智库兰德公司的研究员。她曾经执教于马里兰大学和伦敦城市大学,并担任IEEE Software和IEEE Transactions on Software Engineering等业界期刊副主编多年。除本书外,她与人合作撰写的Security in Computing也是广泛采用的主流教材。
Joanne M. Atlee 世界知名的软件工程学者,以软件需求和软件工程教育方面的杰出贡献而闻名。她是IEEE计算机学会和ACM联合发起的软件工程课程项目指导委员会的成员,也是国际信息处理联合会(IFIP)软件需求工程工作组成员。她是滑铁卢大学副教授,创立了该校的软件工程学位项目并任项目主任。