软件工程基础知识
软件工程
软件开发生命周期：
软件定义时期：包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标，具体可分成问题定义、可行性研究、需求分析等。软件开发时期：就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。软件运行和维护：就是把软件产品移交给用户使用。
软件系统的文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关系这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面。
- P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
- D(Do)——软件开发。开发出满足规格说明的软件。
- C(Check)——软件确认。确认开发的软件能够满足用户的需求。
- A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。
软件系统工具通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。
软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具等。
软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
软件设计包括四个既独立又相互联系的活动，即数据设计、架构(体系结构)设计、人机界面(接口)设计和过程设计，这四个活动完成以后就得到了全面的软件设计模型。
需求工程
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明分为需求开发和需求管理两大过程。
业务需求：反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- 功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
- 非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
- 设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。
常见的需求获取法包括：
- 用户访谈：1对1-3,有代表性的用户。其形式包括结构化和非结构化两种。
- 问卷调查：用户多，无法一一访谈。
采样：从种群中系统地选出有代表性的样本集的过程。样本数量=0.25*(可信度因子/错误率)2情节串联板：一系列图片，通过这些图片来讲故事。联合需求计划(JRP):通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。需求记录技术：任务卡片、场景说明、用户故事、Volere白卡。
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
需求分析的任务:
- 绘制系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求建立模型
- 创建数据字典
- 使用QFD(质量功能部署)
结构化的需求分析的结构化特点：自顶向下，逐步分解，面向数据。
结构化的需求分析的三大模型：功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典。
数据流图DFD基本图形元素：外部实体、加工、数据存储、数据流。
-
数据流：由一组固定成分的数据组成，表示数据的流向。在DFD中，数据流的流向可以有以下几种：从一个加工流向另一个加工；从加工流向数据存储(写);从数据存储流向加工(读);从外部实体流向加工(输入);从加工流向外部实体(输出)。 -
加工：描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。数据流图中常见的三种错误如图所示：加工3.1.2有输入但是没有输出，称之为“黑洞”。加工3.1.3有输出但没有输入。称之为“奇迹”。加工3.1.1中输入不足以产生输出，我们称之为“灰洞”。这有几种可能的原因：一个错误的命名过程；错误命名的输入或输出；不完全的事实。灰洞是最常见的错误，也是最使人为难的错误。一旦数据流图交给了程序员，到一个加工的输入数据流必须足以产生输出数据流。 -
数据存储：用来存储数据。在软件系统中还常常要把某些信息保存下来以供以后使用。 -
外部实体(外部主体):是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。
数据字典DD: 数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。
数据字典有以下4类条目：数据流、数据项、数据存储和基本加工。加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和判定树3种。
软件需求规格说明书SRS：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。
需求定义方法:
- 严格定义也称为
预先定义，需求的严格定义建立在以下的基本假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。 - 原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了克该服困难的一个手段。特点：
需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。
需求验证也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SAS进行评审和测试，包括两个步骤：
需求评审：正式评审和非正式评审。需求测试：设计概念测试用例。
需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。
定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。
需求变更和风险：主要关心需求变更过程中的需求风险管理，带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。
变更控制委员会CCB：也称为配置控制委员会，其任务时对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。
需求跟踪：双向跟踪，两个层次。正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格(需求跟踪矩阵)来表示：若原始需求和用例有对应，则在对应栏打对号，若某行都没有对号，表明原始需求未实现，正向跟踪发现问题；若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向跟踪发现问题。
系统设计
程序流程图(ProgramFlowDiagram,PFD)用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。
IPO图也是流程描述工具，用来描述构成软件系统的每个模块的输入、输出和数据加工。
N-S图容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。
问题分析图(PAD)是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。
业务流程重组BPR，BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计，从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。
业务流程管理BPM，BPM是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。
BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造，而是根据现有流程的具体情况，对流程进行规范化的设计流程管理包含三个层面：规范流程、优化流程和再造流程
系统设计主要目的：为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。
系统设计方法：结构化设计方法，面向对象设计方法。
系统设计的主要内容：概要设计、详细设计。
概要设计基本任务：又称为系统总体结构设计，是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
详细设计的基本任务：模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。
系统设计基本原理:
抽象化；自顶而下，逐步求精；信息隐蔽；模块独立(高内聚，低耦合)。
系统设计原则:
- 保持模块的大小适中；
- 尽可能减少调用的深度；
- 多扇入，少扇出；
- 单入口，单出口；
- 模块的作用域应该在模块之内；
- 功能应该是可预测的。
在软件开发中，模块内聚程度从低到高可分为以下几种类型：
| 内聚类型 | 说明 |
|---|---|
偶然内聚 | 模块内各部分之间没有有意义的联系，代码只是因为偶然的原因组合在一起。 |
逻辑内聚 | 模块完成几种逻辑上相关的功能，通过参数确定执行哪一个功能。 |
时间内聚 | 模块内的各部分是因为要在同一时间段执行而组合在一起。 |
过程内聚 | 模块内的处理元素相关，且必须以特定的次序执行。 |
通信内聚 | 模块内的各部分都操作在同一个数据结构上，或者各处理使用相同的输入数据或产生相同的输出数据。 |
顺序内聚 | 模块内的处理元素和同一个功能密切相关，且前一个处理元素的输出是后一个处理元素的输入。 |
功能内聚 | 模块内所有元素共同完成一个单一的功能，模块具有明确的、单一的职责。 |
在软件开发中，模块耦合程度从低到高可分为以下几种类型：
| 耦合类型 | 说明 |
|---|---|
非直接耦合 | 模块之间无直接联系，完全独立，通过主程序间接关联。 |
数据耦合 | 模块间通过参数传递简单数据(如单个变量)，依赖程度低。 |
标记耦合 | 模块间传递数据结构(如数组、对象)，依赖程度高于数据耦合。 |
控制耦合 | 模块间传递控制信息(如标志位)，接收方需根据控制逻辑调整行为。 |
外部耦合 | 模块依赖外部系统(如文件、数据库)或平台特定功能，耦合度较高。 |
公共耦合 | 多个模块共享全局数据(如全局变量、共享内存)，一处修改影响多处。 |
内容耦合 | 模块直接访问另一模块的内部代码或数据(如修改全局变量、跳转指令)，耦合度最高。 |
注：设计时应尽量追求低耦合(如数据耦合)，避免高耦合(如内容耦合)。
系统结构图(SC)又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。
详细设计的表示工具有图形工具、表格工具和语言工具。其中图形工具有业务流图、程序流程图、PAD图、NS流程图。
程序流程图又称为程序框图，是使用最广泛然的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，菱形表示一个逻辑条件，箭头表示控制流向。其优点是：结构清晰，易于理解，易于修改。缺点是：只能描述执行过程而不能描述有关的数据。
NS流程图，也称为盒图，是一种强制使用结构化构造的图示工具，也称为方框图。其具有以下特点：功能域明确、不可能任意转移控制、很容易确定局部和全局数据的作用域、很容易表示嵌套关系及模板的层次关系。
PAD图是一种改进的图形描述方式，可以用来取代程序流程图，相比程序流程图更直观，结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的图示，并允许递归使用。
人机界面设计的三大原则：置于用户控制之下、减少用户的记忆负担、保持界面的一致性。
置于用户的控制之下:
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式；
- 提供灵活的交互；
- 允许用户交互可以被中断和取消；
- 当技能级别增加时可以使交互流水化并允许定制交互；
- 使用户隔离内部技术细节；
- 设计应允许用户和出现在屏幕上的对象直接交互。
减少用户的记忆负担:
- 减少对短期记忆的要求；
- 建立有意义的缺省；
- 定义直觉性的捷径；
- 界面的视觉布局应该基于真实世界的隐喻；
- 以不断进展的方式揭示信息。
保持界面的一致性:
- 允许用户将当前任务放入有意义的语境;
- 在应用系列内保持一致性;
- 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要去改变它。
测试基础知识
测试原则:
应尽早并不断的进行测试；
测试工作应该避免由元开发软件的人或小组承担；
在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果；
既包含有效、合理的测试用例，也包含不合理、失效的用例；
检验程序是否做了该做的事，且是否做了不该做的事；
严格按照测试计划进行；
妥善保存测试计划和测试用例；
测试用例可以重复使用或追加测试。
测试过程中程序执行状态：动态测试、静态测试。
具体实现算法细节和系统内部结构的相关情况为根据可分黑盒测试、白盒测试和灰盒测试。
程序执行方式：人工测试、自动化测试(自动化执行测试脚本)。
动态测试,程序运行时测试，分为:
黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
灰盒测试法：即既有黑盒，也有白盒。
静态测试,程序静止时，即对代码进行人工审查，分为:桌前检查：程序员检查自己编写的程序，在程序编译后，单元测试前。代码审查：由若干个程序员和测试人员组成评审小组，通过召开程序评审会来进行审查。代码走查：也是采用开会来对代码进行审查，但并非简单的检查代码，而是由测试人员提供测试用例，让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑。
单元测试：也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类(统称为模块),测试依据是软件详细设计说明书。
集成测试：目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。
确认测试：主要用于验证软件的功能、性能、和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型：
内部确认测试：主要由软件开发组织内部按照SRS进行测试。
Alpha测试：用户在开发环境下进行测试。
Beta测试：用户在实际使用环境下进行测试，通过改测试后，产品才能交付用户。
验收测试：针对SRS,在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。
系统测试：测试对象是完整的、集成的计算机系统、；测试的目的是在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法；性能测试主要指标有响应时间、吞吐量、并发用户数和资源利用率等。
配置项测试：测试对象是软件配置项，测试目的是检验软件配置项与SRS的一致性。测试的依据是SRS。在此之间，应确认被测软件配置项已通过单元测试和集成测试。
回归测试：测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
其他测试:
AB测试。是为Web或App界面或流程制作两个或多个版本，在同一时间维度，分别让组成成分相同(相似)的访客群组(目标人群)随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。Web测试。是软件测试的一部分，是针对Web应用的一类测试。由于Web应用与用户直接相关，又通常需要承受长时间的大量操作，因此Web项目的功能和性能都必须经过可靠的验证。链接测试。链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。链接测试可分为3个方面。首先，测试所有链接是否按指示那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面。表单测试。当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让用户收到信息。
W模型：W模型是对V模型的一个重要改进，充分体现了尽早开展测试的原则，并将V模型中以发现缺陷为目标上升为保证软件质量为目标。
W模型实际上是两个V的叠加，一个v描述开发过程，另外一个v描述测试过程。但测试的起始时机不再是编码结束之后，而是从需求分析时开始，且与开发的每一个阶段活动同步进行。
H模型：改进了W和V模型高度依赖于开发的瀑布模型的缺陷，H模型把测试活动从软件开发过程中独立出来，在软件过程的任何一个时间点上，只要测试条件满足即开展测试。测试的流程与其他流程是并行的。H模型比W模型更好的地方是能够兼顾测试的效率和灵活性，适合于各种规模及类型的软件项目。
敏捷测试模型：敏捷测试源于敏捷开发。敏捷测试是敏捷开发的组成部分，需要与开发流程良好融合，敏捷测试在整个敏捷开发过程中，需要与项目的其他人员甚至用户保持紧密协作，时刻关注需求变化并实施测试，以体现测试的时效性和适应性，这对测试人员有比较高的能力要求。
黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：
等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150,边界值为0,150,-1,151四个。错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。
白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，
覆盖级别从低至高分为下面几种：
- 语句覆盖SC:逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。
- 判定覆盖DC:逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。
- 条件覆盖CC:针对每一个判断条件内的每一个独立条件都要执行一遍真和假。
- 条件判定组合覆盖CDC:同时满足判定覆盖和条件覆盖。
测试是发现错误，调试是找出错误的代码和原因。
调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测试。
调试的方法:
蛮力法：又称为穷举法或枚举法，穷举出所有可能的方法一一尝试。回溯法：又称为试探法，按选优条件向前搜索，以达到目标，当发现原先选择并不优或达不到目标，就退回一步重新选择，这种走不通就退回再走的技术为回溯法。演绎法：是由一般到特殊的推理方法，与“归纳法”相反，从一般性的前提出发。得出具体陈述或个别结论的过程。归纳法：是由特殊到一般的推理方法，从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。
软件度量中软件的两种属性：外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标。内部属性指软件产品本身的的属性，如可靠性等，只能间接测量。
McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m,节点数为n,则此有向图的环路复杂度为m-n+2。注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边(连线)就是一条有向边，每一条语句(语句框)就是一个顶点。此外，推荐使用另一种简单的计算公式：环路复杂度=判定节点个数+1。
系统运行与维护
遗留系统：是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有以下特点：
- 系统虽然完成企业中许多重要的业务管理工作，但仍然不能完全满足要求。一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。
- 系统在
性能上已经落后，采用的技术已经过时。例如，多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。 - 通常是大型的软件系统，已经融入企业的
业务运作和决策管理机制之中，维护工作十分困难。 - 没有使用现代信息系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解。
系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划：
直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本。并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。
数据转换与迁移：将数据从旧数据库迁移到新数据库中。要在新系统中尽可能的保存旧系统中合理的数据结构，才能降低迁移的难度。也有三种方法：系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。
系统的可维护性：可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下：
易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。易改变性。软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。稳定性。软件产品避免由于软件修改而造成意外结果的能力。易测试性。软件产品使已修改软件能被确认的能力。维护性的依从性。软件产品遵循与维护性相关的标准或约定的能力。
净室软件工程
净室软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。
在净室软件工程背后的哲学是：通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。
净室软件工程(CSE)的理论基础：主要是函数理论和抽样理论。
净室软件工程应用技术手段：
- 统计过程控制下的增量式开发。
- 基于函数的规范与设计。
- 正确性验证。CSE的核心。
- 统计测试和软件认证。
净室软件工程在使用过程的一些缺点：
- CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。
- CSE开发小组不进行传统的模块测试，这是不现实的。
- CSE也会带有传统软件工程的一些弊端。
基于构建的软件工程
基于构件的软件工程(CBSE)：是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于己有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低软件开发的费用。
用于CBSE的构件应该具备以下特征：
可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。
构件模型：定义了构件实现、文档化以及开发的标准，其包含的模型要素为：
接口。构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。使用信息。为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。部署。构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。
构件模型提供了一组被构件使用的通用服务，这种服务包括以下两种。
平台服务，允许构件在分布式环境下通信和互操作。支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务。中间件实现共性的构件服务，并提供这些服务的接口。
CBSE过程：是支持基于构件组装的软件开发过程，过程中的6个主要活动：系统需求概览、识别候选构件、根据发现的构件修改需求、体系结构设计、构件定制与适配、组装构件创建系统。
CBSE过程与传统软件开发过程不同点：
- CBSE早期需要完整的需求，以便尽可能多地识别出可复用的构件。
- 在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。
- 在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
- 开发就是将己经找到的构件集成在一起的组装过程。
构件组装：是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。
常见的组装构件有以下3种组装方式。
顺序组装。通过按顺序调用己经存在的构件，可以用两个已经存在的构件来创造一个新的构件。如上一个构件输出作为下一个构件的输入。层次组装。这种情况发生在一个构件直接调用自另一个构件所提供的服务时。被调用的构件为调用的构件提供所需的服务。二者之间接口匹配兼容。叠加组装。这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构件合并了原构件的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口，而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或者构件是服务的情况。
构件组装的三种不兼容问题(通过编写适配器解决):
参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。操作不兼容。提供接口和请求接口的操作名不同。操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。
