编辑推荐
《软件工程:架构驱动的软件开发》适合作为高等院校软件工程及相关课程的教材，也可作为软件开发人员和软件技术人员的参考书。
作者简介
作者：（美国）理查德 F.施密特（Richard F.Schmidt） 译者：江贺 李必信 周颖
目录
出版者的话
译者序
作者序
前言
第一部分软件工程基础
第1章软件工程简介5
1.1明确软件需求6
1.2软件架构7
1.3集成产品和过程开发8
1.4集成产品团队8
1.5工作分解结构10
1.6软件分解结构10
1.7规约树和文档树11
1.8集成总体方案和进度安排11
1.9评审与审核12
1.10配置管理和变更控制13
1.11权衡分析15
1.12风险管理16
1.13建模与仿真16
第2章通用软件开发框架19
2.1软件分解结构19
2.2软件开发过程21
2.2.1需求定义阶段22
2.2.2概要架构定义阶段22
2.2.3关键架构定义阶段23
2.2.4软件单元编码和测试阶段24
2.2.5软件组件的集成和测试阶段24
2.2.6产品测试阶段24
2.2.7验收测试阶段25
2.3总结26
第3章软件架构27
3.1涉众需求的关系和依赖性29
3.2软件需求基线的关系和依赖性30
3.3计算环境的关系和依赖性30
3.4测试和评估的关系及依赖性30
3.5功能架构的关系和依赖性31
3.6物理架构的关系和依赖性31
3.7开发后的过程的关系和依赖性32
3.8软件架构的动机32
第4章理解软件项目环境35
4.1集成产品团队38
4.2软件架构39
4.3复杂性控制机制40
4.3.1工作分解结构40
4.3.2产品分解结构41
4.3.3规约树42
4.3.4文档树42
4.3.5软件产品基线42
4.3.6需求可追踪性准则42
4.3.7权衡分析43
4.3.8软件复杂性度量44
4.4软件术语注册表46
4.5软件集成策略47
4.6项目和技术方案47
4.6.1技术组织规划48
4.6.2项目规划48
第5章软件集成产品和过程开发50
5.1IPPD在软件中的应用51
5.1.1客户至上52
5.1.2产品和进程的并行开发53
5.1.3早期的和连续的生命周期规划54
5.1.4最大化承包商独特方法的优化和使用灵活性54
5.1.5鼓励鲁棒设计，提高过程能力？55
5.1.6事件驱动进度55
5.1.7多部门团队协作55
5.1.8授权55
5.1.9无缝管理工具56
5.1.10风险的主动识别和管理56
5.2软件工程和开发56
第6章软件设计阻碍58
6.1作为原材料的软件59
6.2软件技术的变革61
6.2.1软件开发方法和标准63
6.2.2敏捷宣言66
6.3架构驱动的软件开发67
第二部分软件工程实践
第7章理解软件需求76
7.1第1步：征求渉众需求与期望78
7.2第2步：需求分析与规约79
7.2.1平衡和化解渉众需求的冲突80
7.2.2维护项目的范围81
7.2.3有经验的软件人员的参与82
7.3第3步：任务定义与安排82
7.4第4步：资源的确定、估算和分配83
7.5第5步：建立组织工作包83
7.6第6步：技术规划83
7.7第7步：项目规划83
7.8探索渉众的需求84
第8章软件需求分析实践86
8.1项目分析任务86
8.1.1分析项目目的和目标86
8.1.2确定开发成功标准87
8.1.3征求渉众需求和期望88
8.1.4对渉众需求按优先级排序89
8.2业务分析任务89
8.2.1确定业务概念89
8.2.2确定业务场景89
8.2.3确定计算环境特征90
8.2.4确定外部接口91
8.3产品分析任务91
8.3.1确定业务模式91
8.3.2确定功能行为91
8.3.3确定资源利用率需求93
8.3.4确定数据处理条件逻辑93
8.3.5确定数据持久性需求93
8.3.6确定数据安全性需求93
8.3.7确定数据存储事务93
8.3.8确定性能度量94
8.4维护分析任务94
8.4.1确定开发后的过程业务概念94
8.4.2确定开发后的过程业务场景94
8.4.3确定开发后的过程特征94
8.4.4确定架构的指导方针和原则95
8.5项目评估任务95
8.5.1评估需求敏感性95
8.5.2确定软件测试策略96
8.5.3评估已提议的变更96
8.5.4评估项目可行性97
8.6建立需求基线97
第9章软件需求管理98
9.1接受变更98
9.1.1时间是一种宝贵资源98
9.1.2变更影响分析99
9.1.3调整项目里程碑101
9.2明确需求102
9.3需求分解和分配103
9.3.1功能分析104
9.3.2性能分配104
9.3.3结构化单元综合104
9.3.4结构化组件综合105
9.4需求可追踪性105
9.4.1变更控制105
9.4.2配置审核106
第10章制定功能架构107
10.1功能架构的动机107
10.2功能架构本体论108
10.2.1功能组件109
10.2.2功能单元109
10.2.3数据项109
10.2.4功能接口109
10.2.5外部接口109
10.2.6控制结构110
10.2.7资源110
10.2.8数据存储110
10.3构想功能架构110
10.4记录功能架构112
10.4.1功能层次112
10.4.2行为模型112
10.4.3功能时限113
10.4.4资源利用率概述113
10.4.5功能规约113
10.4.6需求分配表114
第11章功能分析与分配实践115
11.1评估功能复杂性115
11.2行为分析117
11.2.1识别功能场景117
11.2.2识别功能序列118
11.2.3识别数据流118
11.2.4识别控制行为119
11.2.5识别数据处理过程119
11.2.6识别资源先决条件120
11.2.7识别失效条件120
11.2.8识别系统监控过程121
11.2.9识别数据保留能力需求122
11.2.10识别数据安全过程122
11.2.11识别数据持久性与保留功能122
11.3性能分配122
11.3.1分配性能预算123
11.3.2分配资源预算123
11.4架构评估123
11.4.1评估需求满足124
11.4.2评估软件性能124
11.4.3评估架构复杂性124
11.4.4评估优化机会124
11.5建立功能架构124
第12章物理架构配置125
12.1结构设计解决方案126
12.1.1定义结构单元127
12.1.2准备结构单元规约128
12.1.3建立软件集成策略129
12.1.4指定工程组套129
12.1.5准备软件技术数据包129
12.2结构设计考量130
12.2.1结构设计指导原则130
12.2.2使用建模与仿真132
12.2.3行为分析132
12.2.4结构权衡分析133
12.2.5软件产品性能评估134
12.2.6软件原型136
第13章软件设计综合实践138
13.1设计概念化139
13.1.1建立软件架构设计指导原则140
13.1.2识别抽象结构组件141
13.1.3识别抽象用户接口机制141
13.2设计解决方案142
13.2.1识别基本结构元素142
13.2.2识别集成组件143
13.2.3评估软件重用机会143
13.3设计相关性144
13.3.1建立性能基准144
13.3.2识别结构设计缺点145
13.3.3评估架构候选方案146
13.3.4评估软件实现挑战146
13.3.5评估软件维护挑战146
13.3.6评估架构完整性147
13.4设计表现147
13.4.1建立结构设计配置147
13.4.2说明结构配置元素148
13.4.3识别工程组套148
13.5准备软件技术数据包148
第14章软件分析实践150
14.1定义权衡研究151
14.1.1建立权衡研究领域151
14.1.2确定候选方案152
14.1.3建立成功标准152
14.2建立权衡研究环境153
14.2.1汇集实验机制153
14.2.2汇集数据收集和分析机制153
14.2.3建立权衡研究过程154
14.3执行分析154
14.3.1评估需求候选方案155
14.3.2评估功能候选方案155
14.3.3评估结构候选方案155
14.4评估项目影响156
14.4.1评估开发影响156
14.4.2评估项目影响156
14.4.3确定项目执行策略156
14.5评估权衡研究结果156
14.5.1为架构候选方案排序157
14.5.2确定优先行动路径157
14.5.3将权衡研究的决策文档化157
14.5.4优化执行策略158
第15章软件验证和确认实践159
15.1定义V&V策略160
15.1.1建立V&V范围160
15.1.2建立V&V方法162
15.1.3建立V&V过程162
15.2验证软件架构163
15.2.1验证需求基线163
15.2.2验证功能架构163
15.2.3验证物理架构163
15.2.4验证软件实现163
15.3确认物理架构163
15.3.1确认结构配置163
15.3.2确认集成软件配置163
15.4记录V&V结果164
第16章软件控制实践165
16.1配置管理166
16.1.1识别架构元素166
16.1.2维护架构状态166
16.2处理工程变更包167
16.2.1记录工程变更请求和提议167
16.2.2准备变更评估包167
16.3变更评估168
16.3.1评估变更技术优点168
16.3.2评估架构影响169
16.3.3评估技术工作包影响169
16.3.4评估技术方案影响169
16.4变更同化170
16.4.1发布变更通知包170
16.4.2审核架构变更进展170
16.4.3评估项目现状170
16.5软件库控制170
16.5.1维护工程工件库171
16.5.2维护变更历史库171
16.5.3维护技术风险库171
第三部分软件工程应用的阶段
第17章软件需求定义176
17.1软件需求定义的产品176
17.2软件工程集成产品团队（软件需求定义阶段）178
17.3软件实现（软件需求定义阶段）180
17.4计算环境准备（软件需求定义阶段）180
17.5开发后的过程实现（软件需求定义阶段）180
17.6软件测试和评估（软件需求定义阶段）181
17.7评审、里程碑和基线（软件需求定义阶段）182
第18章软件架构定义184
18.1概要架构定义185
18.1.1概要架构定义的产品185
18.1.2软件工程集成产品团队（概要架构定义阶段）186
18.1.3软件实现（概要架构定义阶段）187
18.1.4计算环境准备（概要架构定义阶段）187
18.1.5开发后的过程准备（概要架构定义阶段）187
18.1.6软件测试和评估（概要架构定义阶段）188
18.1.7评审与里程碑（概要架构定义阶段）189
18.2详细架构定义189
18.2.1详细架构定义的产品190
18.2.2软件工程集成产品团队（详细架构定义阶段）191
18.2.3软件实现（详细架构定义阶段）192
18.2.4计算环境准备（详细架构定义阶段）192
18.2.5开发后的过程准备（详细架构定义阶段）192
18.2.6软件测试和评估（详细架构定义阶段）193
18.2.7评审与里程碑（详细架构定义阶段）193
18.2.8建立分配基线194
第19章软件实现195
19.1软件实现的产品196
19.2软件工程任务（软件实现阶段）197
19.3软件实现任务（软件实现阶段）197
19.4计算环境任务（软件实现阶段）199
19.5开发后的过程任务（软件实现阶段）199
19.6软件测试和评估任务（软件实现阶段）199
19.7评审与里程碑（软件实现阶段）200
第20章软件验收测试202
20.1软件验收测试的产品203
20.2软件工程（软件验收测试阶段）203
20.3软件实现组织（软件验收测试阶段）204
20.4计算环境实现组织（软件验收测试阶段）204
20.5开发后的过程组织（软件验收测试阶段）204
20.6软件测试和评估（软件验收测试阶段）205
20.7评审与里程碑（软件验收测试阶段）205
20.8建立软件产品基线206
索引207
序言
作者序Software Engineering: Architecture-Driven Software Development本书提出了几个颇有争议的话题。这些争议性的话题涵盖了“软件工程”的范围，并且是作者出版本书的动机核心。如果软件工程学科很好地建立起来，并且被证明取得了成功的结果，那么就不再需要出版和推广本书了。然而，并非如此。在过去20年中，软件行业项目的成功率都徘徊在30%左右。这些项目的失败都可以和两个几乎在软件开发项目或方法中随处可见的主要问题联系在一起。第一个问题涉及对于什么是软件产品设计以及如何开发一个完整的设计描述几乎完全的误解。第二个问题涉及缺乏一套可用于为软件工程学科建立合适范围的软件工程原则和实践的标准。
本书提供了一套全面、集成并且紧密耦合的实践。然而，这些内容背离了当下流行的 “最佳实践”，因为它们缺乏设计软件的完美方法。其中的一些观点可能有些批判性；当提出一个方法去修复缺陷系统时，批评是不可避免的。这样做的目的是通过建立一套重要的软件工程原则和实践来鼓励软件社区进行广泛交流。
我希望读者能够保留自己关于软件工程中主流概念的观点。不要让这些有争议的话题分散你的注意力。本书为软件产品的设计提供了一个严谨的、严格的方法。全体软件社区是时候采取行动来提升惨淡的业绩了。我希望这本书能让未来几代专业软件工程师受益。
--理查德·F·施密特（Richard F. Schmidt）
文摘
版权页：
随着产品配置被不断细化，产品和WBS势必会被扩展，从而为修改技术计划、进度安排和关键里程碑成果标准提供基础。
成本和进度目标迫使项目向着其最终成果发展。外部力量，例如客户和涉众的需求和期望、计算技术、竞争和市场条件，都会从确立方案开始就对项目施加压力使其不断发展。
这些断言表明，项目管理和软件工程实践应该以这样一种方式建立，即控制好这些截然相反的力量。开发项目目标驱动的本质是关注以及时并且保证成本效益的方式开发和交付软件产品。这授权了一种设想的策略来隔离项目与变更来源。市场的本质表明，软件开发项目必须认识到开发环境中不断变化的条件将会最终决定软件产品的可接受程度和成败。企业对项目的投资在于提供人员、设施、工具和设备，以及项目实施所必要的资源。由于他们的投资，企业希望了解该软件产品的利润，或者希望通过其可靠的软件开发组织提高其在行业中的知名度。
为了妥善处理变更的动态作用，核心软件工程理论必须支持一种技术性方法来促进以下原则：
1）变更是不可避免的！必须要能区分哪些变更是有利的，可以采纳；而哪些变更应该拒绝或者推迟，直到未来出现其他版本的产品并适用。
2）被采纳的变更必须要能以最小的返工量或进度中断数被纳入计划、预算和产品配置中。
3）每种变更都代表一次返工，除非这种变更是一个全新的需求，不需要与软件架构中任何其他的元素进行交互。然而，即使这个变更是独立的，也需要项目方案和进度表更新来将修正的工作范围纳入工作包中。
4）变更会影响涉及试图操作的软件产品或计算环境的软件架构。应该进行变更分析来理解某个变更引起的感知影响，以支持某个项目决定采用该变更。取决于软件开发工作的状态，涉及纳入变更的返工量将会发生显著的变化。在某些情况下，某种变更可能需要将已完成的工作重新进行。变更的范围可以通过评估受影响的软件架构中元素和接口的数量来确定。这将提供一种作为已有设计和必须返工的工作量的指示。规约树和文档树的评审将会支持变更影响决定。
5）在采纳变更之前，必须清楚工作包调整的范围以确保项目成本和进度目标仍然可以达到。软件工程IPT必须能确保提议中变更的影响能彻底明确地支持采取该变更的成本效益分析。
6）变更影响分析应该足够详细，以便于能够被软件架构、技术方案和进度表所纳入，并且不给项目的成功引入额外的风险。
对项目变更的期望可能来源于外部，比如客户、竞争或者计算技术的进步，又或者来源于技术团队对于软件架构方案的一种更深刻的理解。这些从内部提出的变更请求提供了一些可以改进解决方案或确定必要的修改方案来解决现有架构缺陷的机会。这些源于架构缺陷的变更应该主导技术变更控制委员会的关注方向，因此这些调整必须要在现有的技术范围内执行。
《软件工程:架构驱动的软件开发》适合作为高等院校软件工程及相关课程的教材，也可作为软件开发人员和软件技术人员的参考书。
作者简介
作者：（美国）理查德 F.施密特（Richard F.Schmidt） 译者：江贺 李必信 周颖
目录
出版者的话
译者序
作者序
前言
第一部分软件工程基础
第1章软件工程简介5
1.1明确软件需求6
1.2软件架构7
1.3集成产品和过程开发8
1.4集成产品团队8
1.5工作分解结构10
1.6软件分解结构10
1.7规约树和文档树11
1.8集成总体方案和进度安排11
1.9评审与审核12
1.10配置管理和变更控制13
1.11权衡分析15
1.12风险管理16
1.13建模与仿真16
第2章通用软件开发框架19
2.1软件分解结构19
2.2软件开发过程21
2.2.1需求定义阶段22
2.2.2概要架构定义阶段22
2.2.3关键架构定义阶段23
2.2.4软件单元编码和测试阶段24
2.2.5软件组件的集成和测试阶段24
2.2.6产品测试阶段24
2.2.7验收测试阶段25
2.3总结26
第3章软件架构27
3.1涉众需求的关系和依赖性29
3.2软件需求基线的关系和依赖性30
3.3计算环境的关系和依赖性30
3.4测试和评估的关系及依赖性30
3.5功能架构的关系和依赖性31
3.6物理架构的关系和依赖性31
3.7开发后的过程的关系和依赖性32
3.8软件架构的动机32
第4章理解软件项目环境35
4.1集成产品团队38
4.2软件架构39
4.3复杂性控制机制40
4.3.1工作分解结构40
4.3.2产品分解结构41
4.3.3规约树42
4.3.4文档树42
4.3.5软件产品基线42
4.3.6需求可追踪性准则42
4.3.7权衡分析43
4.3.8软件复杂性度量44
4.4软件术语注册表46
4.5软件集成策略47
4.6项目和技术方案47
4.6.1技术组织规划48
4.6.2项目规划48
第5章软件集成产品和过程开发50
5.1IPPD在软件中的应用51
5.1.1客户至上52
5.1.2产品和进程的并行开发53
5.1.3早期的和连续的生命周期规划54
5.1.4最大化承包商独特方法的优化和使用灵活性54
5.1.5鼓励鲁棒设计，提高过程能力？55
5.1.6事件驱动进度55
5.1.7多部门团队协作55
5.1.8授权55
5.1.9无缝管理工具56
5.1.10风险的主动识别和管理56
5.2软件工程和开发56
第6章软件设计阻碍58
6.1作为原材料的软件59
6.2软件技术的变革61
6.2.1软件开发方法和标准63
6.2.2敏捷宣言66
6.3架构驱动的软件开发67
第二部分软件工程实践
第7章理解软件需求76
7.1第1步：征求渉众需求与期望78
7.2第2步：需求分析与规约79
7.2.1平衡和化解渉众需求的冲突80
7.2.2维护项目的范围81
7.2.3有经验的软件人员的参与82
7.3第3步：任务定义与安排82
7.4第4步：资源的确定、估算和分配83
7.5第5步：建立组织工作包83
7.6第6步：技术规划83
7.7第7步：项目规划83
7.8探索渉众的需求84
第8章软件需求分析实践86
8.1项目分析任务86
8.1.1分析项目目的和目标86
8.1.2确定开发成功标准87
8.1.3征求渉众需求和期望88
8.1.4对渉众需求按优先级排序89
8.2业务分析任务89
8.2.1确定业务概念89
8.2.2确定业务场景89
8.2.3确定计算环境特征90
8.2.4确定外部接口91
8.3产品分析任务91
8.3.1确定业务模式91
8.3.2确定功能行为91
8.3.3确定资源利用率需求93
8.3.4确定数据处理条件逻辑93
8.3.5确定数据持久性需求93
8.3.6确定数据安全性需求93
8.3.7确定数据存储事务93
8.3.8确定性能度量94
8.4维护分析任务94
8.4.1确定开发后的过程业务概念94
8.4.2确定开发后的过程业务场景94
8.4.3确定开发后的过程特征94
8.4.4确定架构的指导方针和原则95
8.5项目评估任务95
8.5.1评估需求敏感性95
8.5.2确定软件测试策略96
8.5.3评估已提议的变更96
8.5.4评估项目可行性97
8.6建立需求基线97
第9章软件需求管理98
9.1接受变更98
9.1.1时间是一种宝贵资源98
9.1.2变更影响分析99
9.1.3调整项目里程碑101
9.2明确需求102
9.3需求分解和分配103
9.3.1功能分析104
9.3.2性能分配104
9.3.3结构化单元综合104
9.3.4结构化组件综合105
9.4需求可追踪性105
9.4.1变更控制105
9.4.2配置审核106
第10章制定功能架构107
10.1功能架构的动机107
10.2功能架构本体论108
10.2.1功能组件109
10.2.2功能单元109
10.2.3数据项109
10.2.4功能接口109
10.2.5外部接口109
10.2.6控制结构110
10.2.7资源110
10.2.8数据存储110
10.3构想功能架构110
10.4记录功能架构112
10.4.1功能层次112
10.4.2行为模型112
10.4.3功能时限113
10.4.4资源利用率概述113
10.4.5功能规约113
10.4.6需求分配表114
第11章功能分析与分配实践115
11.1评估功能复杂性115
11.2行为分析117
11.2.1识别功能场景117
11.2.2识别功能序列118
11.2.3识别数据流118
11.2.4识别控制行为119
11.2.5识别数据处理过程119
11.2.6识别资源先决条件120
11.2.7识别失效条件120
11.2.8识别系统监控过程121
11.2.9识别数据保留能力需求122
11.2.10识别数据安全过程122
11.2.11识别数据持久性与保留功能122
11.3性能分配122
11.3.1分配性能预算123
11.3.2分配资源预算123
11.4架构评估123
11.4.1评估需求满足124
11.4.2评估软件性能124
11.4.3评估架构复杂性124
11.4.4评估优化机会124
11.5建立功能架构124
第12章物理架构配置125
12.1结构设计解决方案126
12.1.1定义结构单元127
12.1.2准备结构单元规约128
12.1.3建立软件集成策略129
12.1.4指定工程组套129
12.1.5准备软件技术数据包129
12.2结构设计考量130
12.2.1结构设计指导原则130
12.2.2使用建模与仿真132
12.2.3行为分析132
12.2.4结构权衡分析133
12.2.5软件产品性能评估134
12.2.6软件原型136
第13章软件设计综合实践138
13.1设计概念化139
13.1.1建立软件架构设计指导原则140
13.1.2识别抽象结构组件141
13.1.3识别抽象用户接口机制141
13.2设计解决方案142
13.2.1识别基本结构元素142
13.2.2识别集成组件143
13.2.3评估软件重用机会143
13.3设计相关性144
13.3.1建立性能基准144
13.3.2识别结构设计缺点145
13.3.3评估架构候选方案146
13.3.4评估软件实现挑战146
13.3.5评估软件维护挑战146
13.3.6评估架构完整性147
13.4设计表现147
13.4.1建立结构设计配置147
13.4.2说明结构配置元素148
13.4.3识别工程组套148
13.5准备软件技术数据包148
第14章软件分析实践150
14.1定义权衡研究151
14.1.1建立权衡研究领域151
14.1.2确定候选方案152
14.1.3建立成功标准152
14.2建立权衡研究环境153
14.2.1汇集实验机制153
14.2.2汇集数据收集和分析机制153
14.2.3建立权衡研究过程154
14.3执行分析154
14.3.1评估需求候选方案155
14.3.2评估功能候选方案155
14.3.3评估结构候选方案155
14.4评估项目影响156
14.4.1评估开发影响156
14.4.2评估项目影响156
14.4.3确定项目执行策略156
14.5评估权衡研究结果156
14.5.1为架构候选方案排序157
14.5.2确定优先行动路径157
14.5.3将权衡研究的决策文档化157
14.5.4优化执行策略158
第15章软件验证和确认实践159
15.1定义V&V策略160
15.1.1建立V&V范围160
15.1.2建立V&V方法162
15.1.3建立V&V过程162
15.2验证软件架构163
15.2.1验证需求基线163
15.2.2验证功能架构163
15.2.3验证物理架构163
15.2.4验证软件实现163
15.3确认物理架构163
15.3.1确认结构配置163
15.3.2确认集成软件配置163
15.4记录V&V结果164
第16章软件控制实践165
16.1配置管理166
16.1.1识别架构元素166
16.1.2维护架构状态166
16.2处理工程变更包167
16.2.1记录工程变更请求和提议167
16.2.2准备变更评估包167
16.3变更评估168
16.3.1评估变更技术优点168
16.3.2评估架构影响169
16.3.3评估技术工作包影响169
16.3.4评估技术方案影响169
16.4变更同化170
16.4.1发布变更通知包170
16.4.2审核架构变更进展170
16.4.3评估项目现状170
16.5软件库控制170
16.5.1维护工程工件库171
16.5.2维护变更历史库171
16.5.3维护技术风险库171
第三部分软件工程应用的阶段
第17章软件需求定义176
17.1软件需求定义的产品176
17.2软件工程集成产品团队（软件需求定义阶段）178
17.3软件实现（软件需求定义阶段）180
17.4计算环境准备（软件需求定义阶段）180
17.5开发后的过程实现（软件需求定义阶段）180
17.6软件测试和评估（软件需求定义阶段）181
17.7评审、里程碑和基线（软件需求定义阶段）182
第18章软件架构定义184
18.1概要架构定义185
18.1.1概要架构定义的产品185
18.1.2软件工程集成产品团队（概要架构定义阶段）186
18.1.3软件实现（概要架构定义阶段）187
18.1.4计算环境准备（概要架构定义阶段）187
18.1.5开发后的过程准备（概要架构定义阶段）187
18.1.6软件测试和评估（概要架构定义阶段）188
18.1.7评审与里程碑（概要架构定义阶段）189
18.2详细架构定义189
18.2.1详细架构定义的产品190
18.2.2软件工程集成产品团队（详细架构定义阶段）191
18.2.3软件实现（详细架构定义阶段）192
18.2.4计算环境准备（详细架构定义阶段）192
18.2.5开发后的过程准备（详细架构定义阶段）192
18.2.6软件测试和评估（详细架构定义阶段）193
18.2.7评审与里程碑（详细架构定义阶段）193
18.2.8建立分配基线194
第19章软件实现195
19.1软件实现的产品196
19.2软件工程任务（软件实现阶段）197
19.3软件实现任务（软件实现阶段）197
19.4计算环境任务（软件实现阶段）199
19.5开发后的过程任务（软件实现阶段）199
19.6软件测试和评估任务（软件实现阶段）199
19.7评审与里程碑（软件实现阶段）200
第20章软件验收测试202
20.1软件验收测试的产品203
20.2软件工程（软件验收测试阶段）203
20.3软件实现组织（软件验收测试阶段）204
20.4计算环境实现组织（软件验收测试阶段）204
20.5开发后的过程组织（软件验收测试阶段）204
20.6软件测试和评估（软件验收测试阶段）205
20.7评审与里程碑（软件验收测试阶段）205
20.8建立软件产品基线206
索引207
序言
作者序Software Engineering: Architecture-Driven Software Development本书提出了几个颇有争议的话题。这些争议性的话题涵盖了“软件工程”的范围，并且是作者出版本书的动机核心。如果软件工程学科很好地建立起来，并且被证明取得了成功的结果，那么就不再需要出版和推广本书了。然而，并非如此。在过去20年中，软件行业项目的成功率都徘徊在30%左右。这些项目的失败都可以和两个几乎在软件开发项目或方法中随处可见的主要问题联系在一起。第一个问题涉及对于什么是软件产品设计以及如何开发一个完整的设计描述几乎完全的误解。第二个问题涉及缺乏一套可用于为软件工程学科建立合适范围的软件工程原则和实践的标准。
本书提供了一套全面、集成并且紧密耦合的实践。然而，这些内容背离了当下流行的 “最佳实践”，因为它们缺乏设计软件的完美方法。其中的一些观点可能有些批判性；当提出一个方法去修复缺陷系统时，批评是不可避免的。这样做的目的是通过建立一套重要的软件工程原则和实践来鼓励软件社区进行广泛交流。
我希望读者能够保留自己关于软件工程中主流概念的观点。不要让这些有争议的话题分散你的注意力。本书为软件产品的设计提供了一个严谨的、严格的方法。全体软件社区是时候采取行动来提升惨淡的业绩了。我希望这本书能让未来几代专业软件工程师受益。
--理查德·F·施密特（Richard F. Schmidt）
文摘
版权页：
随着产品配置被不断细化，产品和WBS势必会被扩展，从而为修改技术计划、进度安排和关键里程碑成果标准提供基础。
成本和进度目标迫使项目向着其最终成果发展。外部力量，例如客户和涉众的需求和期望、计算技术、竞争和市场条件，都会从确立方案开始就对项目施加压力使其不断发展。
这些断言表明，项目管理和软件工程实践应该以这样一种方式建立，即控制好这些截然相反的力量。开发项目目标驱动的本质是关注以及时并且保证成本效益的方式开发和交付软件产品。这授权了一种设想的策略来隔离项目与变更来源。市场的本质表明，软件开发项目必须认识到开发环境中不断变化的条件将会最终决定软件产品的可接受程度和成败。企业对项目的投资在于提供人员、设施、工具和设备，以及项目实施所必要的资源。由于他们的投资，企业希望了解该软件产品的利润，或者希望通过其可靠的软件开发组织提高其在行业中的知名度。
为了妥善处理变更的动态作用，核心软件工程理论必须支持一种技术性方法来促进以下原则：
1）变更是不可避免的！必须要能区分哪些变更是有利的，可以采纳；而哪些变更应该拒绝或者推迟，直到未来出现其他版本的产品并适用。
2）被采纳的变更必须要能以最小的返工量或进度中断数被纳入计划、预算和产品配置中。
3）每种变更都代表一次返工，除非这种变更是一个全新的需求，不需要与软件架构中任何其他的元素进行交互。然而，即使这个变更是独立的，也需要项目方案和进度表更新来将修正的工作范围纳入工作包中。
4）变更会影响涉及试图操作的软件产品或计算环境的软件架构。应该进行变更分析来理解某个变更引起的感知影响，以支持某个项目决定采用该变更。取决于软件开发工作的状态，涉及纳入变更的返工量将会发生显著的变化。在某些情况下，某种变更可能需要将已完成的工作重新进行。变更的范围可以通过评估受影响的软件架构中元素和接口的数量来确定。这将提供一种作为已有设计和必须返工的工作量的指示。规约树和文档树的评审将会支持变更影响决定。
5）在采纳变更之前，必须清楚工作包调整的范围以确保项目成本和进度目标仍然可以达到。软件工程IPT必须能确保提议中变更的影响能彻底明确地支持采取该变更的成本效益分析。
6）变更影响分析应该足够详细，以便于能够被软件架构、技术方案和进度表所纳入，并且不给项目的成功引入额外的风险。
对项目变更的期望可能来源于外部，比如客户、竞争或者计算技术的进步，又或者来源于技术团队对于软件架构方案的一种更深刻的理解。这些从内部提出的变更请求提供了一些可以改进解决方案或确定必要的修改方案来解决现有架构缺陷的机会。这些源于架构缺陷的变更应该主导技术变更控制委员会的关注方向，因此这些调整必须要在现有的技术范围内执行。
| ISBN | 9787111533146,7111533143 |
|---|---|
| 出版社 | 机械工业出版社 |
| 作者 | 理查德 F.密特 (Richard F.Schmidt) |
| 尺寸 | 16 |