本书是第一本全面讲述IEEE的软件工程知识体系标准涵盖的基本技巧的软工教材。标准专家Richard Schmidt解释了被大家所认可的用于开发政府或企业系统项目的传统软件工程实践。旨在应用系统工程的原理来推动更好的软件开发。
首次针对IEEE软件工程知识体系（SWEBOK）标准中基本技能进行广泛解读
应用系统工程的原理和原则推进更好的软件开发
激励软件团队进行广泛对话，并通过对话来构建软件工程关键原理和实践的集合
本书首次针对IEEE软件工程知识体系标准中一些基本技能进行广泛解读。软件工程标准方面的专家Richard Schmidt解释了为政府或公司开发项目时哪些传统的软件工程实践会获得认可。
软件工程教育往往缺乏标准，许多教育机构更多地关注软件产品的实现而不是设计，而设计实际上影响软件产品架构。许多加入产品开发大军的毕业生由于缺乏某些必要的技能，导致一些软件项目要么彻底失败，要么超出预算并且不能按期提交。
另外，软件工程师也应该理解系统工程和架构，即程序将要运行的硬件和外围设备是如何布局的。随着更多程序需要进行并行计算，这个问题将变得更加重要，所以需要充分理解处理器和硬件的并行处理能力。本书也会帮助软件开发人员和系统工程师深入分析他们具有的技能是如何相互支持与补充的。通过聚焦这些关键的知识点，软件工程师掌握了大量最好的实践知识，可以在任何企业或领域的软件产品开发中发挥作用。
主要特色
涵盖解决交叉学科软件知识领域和主题的软件工程实践。
提供建立健壮架构的最佳实践，从而有助于生成、集成和测试代码。
有助于准确地估计项目开发成本和进度，从而提高软件开发的成功率。
揭示如何将软件工程和系统工程关联起来，促进在项目环境中与其他的工程技术人员沟通。
本书从交叉学科的角度阐述软件开发。根据IEEE计算机学会软件工程知识体系，本书重点介绍如何集成各种软件开发方法和架构设计实践，这些方法和实践对于开发行之有效的软件产品至关重要。作者对于软件产品的开发采用了传统的软件工程实践。无论你是软件开发人员、系统工程师还是项目经理，本书都颇具参考价值。
理查德 F. 施密特
（Richard F. Schmidt）
IEEE系统管理工程组的主席，在航空航天部门具有30多年系统和软件开发经验。在美国空军系统司令部服务期间，他领导了一个联合服务工作组，该工作组负责进行DoD-STD-2167A（国防系统软件开发）的修订，以及DoD-STD-2168（国防系统的软件质量大纲）的制定。他还领导了一个IEEE工作组进行系统工程管理标准的制定，并负责IEEE 1220标准的发布，该标准用于软件工程过程的管理和应用。作为独立顾问，他为海军的RDA首席系统工程师办公室服务9年，并于2005年协同完成《海军SoS系统工程指南》。理查德目前是Vitech公司的市场总监，Vitech公司是CORE的提供商。他还为一些CASE工具商（包括Rational S/W公司和Ascent逻辑公司）工作。
“这是一项不寻常的工作，因为作者首先对软件工程领域一些定义好的并且被大家普通认可的概念发起挑战。作者发现两个共同的问题：其一是，在编码之前对如何进行软件整体设计缺乏理解；其二是，对相关的软件工程技术缺少一致的、科学的验证过程。”
—— 《Reference & Research Book News》
“一些经常在政府机构进进出出的大型项目经理会把课本作为圣杯看待，认为课本说的就是对的。第15章介绍验证和确认，而第16章讨论控制（即配置管理），这两章对他们来说是最有帮助的和最值得认真学习的。”
—— ComputingReviews.com
江 贺
大连理工大学教授、博士生导师，教育部新世纪优秀人才计划获得者。2014年中国计算机学会优秀博士学位论文奖（CCF优博）指导教师。《Applied Intelligence Journal》客座编辑、《Frontiers of Computer Science》 青年编委、中国计算机学会软件工程专委会、计算机应用专委会委员。主要研究领域：基于搜索的软件工程、软件仓库挖掘。在《中国科学》、IEEE 系列汇刊、 ECJ等期刊及ICSE、 GECCO 等国际会议上发表论文60余篇。
李必信
东南大学计算机科学与工程学院教授、博士生导师，中国计算机学会高级会员， 软件工程专委会委员、容错计算机专委会常务委员。国际期刊《IAAI Transactions on Software Engineering》、《International Journal of Theory and Practice Software Engineering》 （IJTPSE）和《Transactions on Computer Science and Technology》编委。 研究方向为软件建模、分析、测试与验证，演化系统的软件质量保证等。先后在《IEEE Transactions on Network and Service Management》《ACM Computing Surveys》等著名期刊和ICSE、FSE、ASE等重要国际会议上发表学术论文150余篇，出版专著3部，授权发明专利18项。
周 颖
东南大学计算机科学与工程学院讲师。主要研究方向为软件建模、分析与验证等。参与和主持国家级、省部级科研项目多项。参与编写和翻译专著多部。
本书旨在比较全面地介绍软件工程学科，展示软件工程原则与基于系统工程的软件实践。本书详细地解释了基本的软件工程体系理念，即强调使用严格规范的方法来设计软件产品。为达到此目的，第一部分讨论了在软件工程体系下的软件开发框架和项目构建。第二部分展示了6项技术惯例，它们传达了这样一种理念：利用计算技术，应用科学原则以及激活设计软件产品架构（即设计）的灵活性。第三部分讨论了软件工程团队在软件开发项目中扮演的角色，以便建立和控制软件产品架构。典型软件开发项目的每个阶段都会讨论的重点是软件工程团队如何与其他技术和项目相关的团体协作来影响架构设计和软件产品实现。这几部分阐明了与软件工程所用的严格方法相关的实践、原则、任务和工件。
本书的基础概念基于系统工程实践来达到表1确定的目标。这些目标通过应用一系列来源于系统工程学科中50多年来成功应用于开发复杂系统的原则和实践来实现。它强调完整软件架构的建立，这使得产品的每个元素都要明确，以便制造、组装、集成和测试。将这些实践应用到软件工程领域，为解决表1中列出的那些挑战提供了基础。
表1 软件工程挑战与目标
软件工程挑战 目标
在编码之前必须先做设计 在提高成本效率和进度准确性前弄清楚正在构建什么
减少产品在设计细节和精度上的复杂性
成本管理、进度安排和风险控制
交付软件技术数据包 完整的设计图表和软件实现（构建）的说明文档
分配设计配置元素间的需求 软件组件和单元间的需求分解与分配
需求可追踪性
集成产品和过程开发（IPPD） 产品维护性能的并行设计与开发
生命周期成本控制
准备软件集成策略 架构设计活动中计划的软件组件集成开发
高效的软件实现规划
控制软件复杂性 降低软件维护/支持成本
高效、用户友好的交互
使变更同化 涉众/用户满意度
产品竞争力
权衡分析 成本管理和进度控制
设计优化
产品演变/增量发布的稳定性
项目成功率的增强
预先计划的产品提升 将某些功能延迟发布来保证产品按时交付
软件分析与设计的当前实践基于计算机编程语言和这些语言处理数据使用的逻辑概念。这驱动了诸如面向对象设计的软件设计方法，它并不是用来处理先进软件产品的复杂性的。通过适应系统工程实践，本书建立了严格的软件工程原则和实践，从而提供了一种全面的方法来设计软件产品。这些软件工程实践必须清晰说明以保证它们对软件开发的重要性和适用性是确定的。将这些实践应用于一个软件开发过程演练中，以便可以控制、修正和管理贯穿整个软件开发项目上下文的软件架构。本书的内容与软件工程知识体系（SWEBOK）的主要过程领域（如表2所示）相对应。与SWEBOK的对应说明了本书中的主题是如何根据SWEBOK中主题进行安排和关联的。然而，SWEBOK是基于现在的软件开发实践，严格从技术上来讲，它并不包括系统工程实践。
表2 SWEBOK关键过程领域
关键过程领域 本书范围
关键过程领域 本书范围
软件需求知识领域 第一部分：第3章
第二部分：第7章、第9章
第三部分：第17章
软件设计知识领域 第一部分：第3章、第6章
第二部分：第10～14章
第三部分：第18章
软件构造知识领域 第三部分：第19章
软件测试知识领域 第三部分：第19章、第20章
软件维护知识领域 第一部分：第5章
第三部分：第17～20章
软件配置管理知识领域 第二部分：第9章、第16章
第三部分：第20章，提到配置审核（FCA/PCA）
软件工程管理知识领域 第一部分：第4章
第二部分：第9章、第16章（提到项目和技术规划，提到工作包）
第三部分，提到项目和技术方案，提到工作包
软件工程过程知识领域 第二部分
第三部分
软件工程方法知识领域 第二部分：第13章（提到软件设计综合实践面向对象的方法）、第14章（提到建模和原型）
软件质量知识领域 第三部分，在测试和评估子部分确定软件质量保证任务
本书内容
接下来会简要介绍书中各章的内容。这三部分将本书内容分成三个连贯的主题，希望读者能增加他们对原则（第一部分）、实践（第二部分）以及软件工程的应用（第三部分）的认识和理解。通过将系统工程实践应用到软件工程领域，本书旨在提供一种创新的、规范的、技术上具有挑战性的方法来开发软件产品。
第一部分：软件工程基础
这一部分讨论的是软件工程相关的基本原则以及这些原则在软件开发场景中的执行。这些基本的原则、实践和理论用于将软件工程建立成一个专业学科。通过讨论软件产品特点和软件开发策略来强调软件开发项目面对的挑战。作为一个组织实体，软件工程弥补了存在于技术专家和项目管理专家之间的外观和感觉上的显著不同。因此，这一部分陈述了软件工程实践与项目管理责任和其他软件开发角色的集成。
第1章概述了软件工程概念、原则和实践，它是解决设计、开发复杂软件产品面临的挑战所必需的。通过调查软件工程实践和工具来确定它们与项目管理机制的关系。
第2章讨论了那些描述软件产品如何定义、设计和实现的软件开发活动的进度。本章通过一系列被项目里程碑和评审分离的连续开发阶段，来追踪典型的软件开发工作，还陈述了软件技术与项目管理控制领域的关系。
第3章确定了软件架构的组成，包括以下几个方面：软件产品、计算环境和那些能满足产品维护的开发后的过程。它涉及架构设计表示、模型和文档对技术和项目相关机制和必要性，以保证软件开发工程对在预算内按期交付是必不可少的。需要讨论建立软件需求规格的技术，功能和物理架构要与软件开发阶段一致。本章讨论了软件产品架构如何为软件实现（编程设计、编码、集成和测试）提供结构化基础以及产品生命周期支持。
第4章使读者了解那些导致软件开发变得复杂并且难以理解的软件产品特征。它解决了软件产品复杂性挑战，并且将这些与那些已被证明有利于成功完成软件开发工作的项目构建和实践相关联。其中的真知灼见将帮助减少项目的障碍、变动、作废和失败。
第5章提出了IPPD理论和它对于项目范围的影响以及开发后过程的考虑。它试图证明需要严密构思和结构化的软件架构来确保可以延长产品的使用寿命，这是由于在开发过程中软件工程关注了生命周期问题。同时检查软件开发后过程的工程可以发现，早期的架构决策可以影响生命周期和拥有成本。
第6章检查了导致“设计”实践变得非常规并且更加难以理解的软件底层特点。作为挑战传统工程审查的设计和构建材料，讨论软件特征。本章提出了管理软件产品设计的软件工程原则。最后，本章介绍了软件设计歧义来计划一项允许对软件产品进行设计的决议。
第二部分：软件工程实践
这部分确定了6个有助于专业化软件工程的实践： 1）软件需求分析， 2）功能分析与分配， 3）软件设计综合， 4）软件分析， 5）软件验证和确认， 6）软件控制。每个实践都由一定数量的任务来表示，每个软件工程的专业人员都应该理解。这些实践建立了一套清晰的任务，集中于设计和细化软件产品架构。
第7章提出了一种方法来开发源自涉众需求和期望，以及有助于决定软件开发工作范围的软件需求规约。软件规约驱使软件架构的定义，但不应该推断出任何架构设计方案。软件需求作为派生软件功能和物理架构的起点。架构设计是由表示功能架构和配置物理架而完成的。架构中的每个元素都必须能在软件规约中指定和追踪。要检查软件需求、软件工程任务，以及项目和技术计划之间的关系。
第8章确定了必须选择性地应用特定任务来建立软件产品和开发后的过程规约。这种实践涉及软件架构中低级功能和结构元素之间性能限额的分配。这种实践从征求涉众需求和期望的工作开始，以建立软件产品需求基线结束。
第9章讨论了以积极主动的方式控制软件架构的重要性，这有利于对已提议的变更进行评估。通过考虑软件需求管理工具和实践以使软件工程团队可以实际考核变更对软件架构的影响和项目资源的自由度来适应一项期望的变更。意图是使开发团队有能力机智地回应得到授权的变更，并且在不扰乱项目范围、计划和成功结束的进度情况下将改进融合到软件架构。
第10章讨论了功能架构的本质以及它如何将明确的需求分解为连续的功能元素。每个功能元素在不断改进的方法中是明确的，这些改进会在识别出未完成的功能并且保证它们能实现时告终。功能架构提供了有逻辑性的、连贯的软件产品行为表示法，以回应那些计算环境内出现的刺激、事件和状况。
第11章确定了为确保得到完整、一致和可追踪的功能架构而必须考虑的具体任务。通过分析理解业务和软件产品行为，方式包括检查、分解、分类和指定那些来源于需求规约的顶级功能。在功能间分配性能需求来确立低级功能元素有效性和性能的度量标准。
第12章描述了安排和确定软件产品物理架构的目的和策略。该物理架构确定了软件单元设计、编码和测试的基本构建快。制定软件集成策略来确定产品结构并规定软件单元和组件如何增量地组合、集成和测试，进而形成完整的软件产品。
第13章确定了必须考虑的特定任务，以确保生成完整、一致并且可追踪的物理架构。为了从纯粹的产品功能表示向物理架构过渡，设计综合是一个经过验证的系统工程实践。它涉及 “制造或者购买”的权衡，这对应于软件“实现或再利用”决策。
第14章确定了必须执行的特定任务，进行设计备选方案的权衡分析和风险评估。进行架构设计决策必须在抑制应用复杂性和软件生命周期成本上有足够的洞察力。与进行权衡分析和风险评估相关的任务可以为理解架构设计决策的本质提供基础，并且对软件开发工作产生影响。
第15章确定了必须执行的特定任务，以确保软件架构元素保持一致，并且与授权的变更提议和请求一致。必须执行验证任务以确保软件实现、测试和评估工作与软件架构规约以及设计文档是同步的。
第16章确定了选择性应用的特定任务，以确保软件产品架构反映了当前设计思想并包含授权的变更提议、请求和设计决策。需求追踪必须嵌入到软件架构中去，并且与文档关联，这样技术团队才能迅速并且有效地响应变更控制委员会的决策。此外，将授权的变更提议和请求反映在项目和技术计划、进度、预算以及工作包描述中是十分必要的。
第三部分：软件工程应用阶段
这部分讨论了在软件开发项目中，分配给技术组织的角色和职责。强调技术组织在软件工程集成产品团队（IPT）中的参与。
第17章确定了由软件工程IPT生成的软件需求规约的方式。将参与的组织代表的贡献确定为软件产品的需求，并且建立了开发后的过程。
第18章确定了在概要和详细架构阶段定义的软件功能和物理架构的方式。这些阶段关注IPPD方法来促进软件实现、测试和开发后的过程必要的基础设施的建立，以推动项目目标的实现。
第19章确定了软件实现组织要执行的任务，以编程方式来设计、编码和测试软件单元，并且进行软件集成和测试。在这个阶段同时实现开发后的过程，来支持验收测试和部署准备评审。
第20章确定了在软件产品验收测试过程中软件测试和评估组织要执行的任务。参与的组织代表的职责在于监督验收测试、应对测试失败，并且回应由验收测试导致的软件问题报告。此外，开发后的过程必须有资格确认它们已经做好准备来支持软件产品发布、培训和维护业务。
计算机\软件工程
首本针对IEEE软件工程知识体系（SWEBOK）标准中基本技能的广泛解读。
应用系统工程的原理和原则推进更好的软件开发。
激励软件团队进行广泛对话，并通过对话来构建软件工程关键原理和实践的集合。
本书是首本针对IEEE软件工程知识体系（SWEBOK）标准中一些基本技能的广泛解读。软件工程标准方面的专家Richard Schmidt解释了为政府或公司开发项目时哪些传统的软件工程实践获得认可。
软件工程教育往往缺乏标准，许多教育机构更多的关注软件产品的实现而不是设计，而设计实际上影响软件产品架构。许多加入产品开发大军的毕业生由于缺乏某些必要的技能，导致一些软件项目要么彻底失败，要么超出预算并导致提交时间延误。
另外，软件工程师也应该理解系统工程和架构，即程序将要运行的硬件和外围设备是如何布局的。这个问题随着更多程序需要进行并行计算时将变得更加重要，所以需要充分理解处理器和硬件的并行处理能力。本书也会帮助软件开发人员和系统工程师深入分析他们具有的技能是如何相互支持和补充的。通过聚焦这些关键的知识点，软件工程师掌握了一组最好的实践知识，可以在任何企业或领域的软件产品开发中发挥作用。
主要特色：
•涵盖解决交叉学科软件知识领域和主题的软件工程实践。
•提供建立健壮架构的最佳实践，从而有助于生成、集成和测试代码。
•有助于准确地估计项目开发成本和进度，从而提高软件开发的成功率。
•揭示如何将软件工程和系统工程关联起来，促进在项目环境中与其他的工程技术人员沟通。
本书从交叉学科的角度阐述软件开发。根据IEEE计算机学会软件工程知识体系（SWEBOK），本书重点介绍如何集成各种软件开发方法和架构设计实践，这些方法和实践对于开发行之有效的软件产品至关重要。作者对于软件产品的开发采用了传统的软件工程实践。无论你是软件开发人员、系统工程师还是项目经理，本书都颇具参考价值。
江贺 李必信 周颖 等译：暂无简介
自从1968年提出“软件工程”这一术语以来，研究软件工程的专家、学者们陆续提出了100多条关于软件工程的准则或信条。然而，软件工程项目失败、进度落后、预算超支等问题仍屡见不鲜。部分原因是目前的教育更关注于编程以及模块级的设计，而缺乏对软件架构设计的理解。没有一个完整的设计概念，编码就会很低效，进而造成软件产品生命周期中的设计基础不稳定。软件行业项目成功率不理想正是作者Richard F. Schmidt出版并推广本书的动机所在，他希望借此对未来的软件工程师有所启发。
Richard F. Schmidt在航空航天系统工程和软件工程方面拥有30多年的研发经验。他曾参与防御系统软件开发的美国国防部标准2167A（DoD-STD-2167A）的修订和防御系统软件质量保证的美国国防部标准2168（DoD-STD-2168）的制定。Richard还负责了IEEE 1220标准（系统工程过程的应用和管理）的发布。本书阐述了那些开发政府或企业系统项目的公认的软件工程实践。本书介绍的是跨学科的软件开发方法。本书的内容与IEEE计算机协会的软件工程知识体系（SWEBOK）相对应，重点是整合各种软件开发方法和对开发有效且高效的软件产品必不可少的架构化设计实践。
全书分为三个部分，共20章。第一部分主要介绍软件工程基础，包括软件开发框架、软件架构、项目环境和软件集成以及软件设计的阻碍；第二部分侧重于软件工程实践，这涉及软件需求分析、需求管理、功能架构制定、功能分析与分配实践、物理架构配置、软件设计综合实践、软件分析实践、软件验证和确认实践、软件控制实践等；第三部分重点分析软件工程应用的各个阶段，从软件需求定义到软件验收测试。
希望广大读者可以通过本书对架构驱动的软件开发方式多一些了解，对软件工程过程多一些思考。受译者水平所限，书中如有错漏和不当，欢迎大家指正讨论。
江贺
出版者的话
译者序
作者序
前言
第一部分 软件工程基础
第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.1 IPPD在软件中的应用 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
