软件工程复习资料

1. 软件测试：是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

系统测试（system testing）：是将通过确认测试的软件，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据、人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

2. 加工规格说明方法：在对数据流图的分解中，位于层次树最低层的加工也称为基本加工或原子加工，

对于每一个基本加工都需要进一步说明，这称为加工规格说明。

加工规格说明的内容可以包括叙述性正文、数学方程、图表等，也可以使用决策表和决策树。

3. 项目管理甘特图（Gantt chart）与PERT图的区别？ P328

以水平线段表示子任务的工作阶段，线段的起点和终点分别对应着该项目子任务的开工时间和完成时间，线段的长度表示完成它所需的时间。

PERT: 以有向箭头作为边表示子任务，它是有名称（即子任务名）、有长度（即完成此项子任

务所需的时间）的向量；以有编号的圆圈作为结点，它应该是子任务向量的始发点或指向点。由若干条边和若干个结点构成了网状图，于是我们可以沿相互衔接的子任务形成的路径，进行路径长度的计算、比较和分析，从而实现项目工期的控制。

4. 软件设计的主要任务是什么？其结构图用途？ P56

设计模型的分析和评估，来确定这些模型是否能够满足需求。

其结构图是精确表达模块结构的图形表示图形表示工具，它作为软件设计文档的一部分，清楚地

反映出软件模块之间的层次调用关系和联系。它不仅严格地定义了各个模块的名字、功能和接口，而且还集中地反映了设计思想。

5. 软件需求分析阶段的主要任务？准确地回答“系统必须做什么？”这个问题，深入描述软件的功能和

性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。软件需求分析阶段的工作分为4个步骤，即获取需求、分析需求、定义需求和验证需求

6. 黑盒白盒测试概念？区别？测试方法？ P122

白盒测试是已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，

所有内部成分是否已经过检查。

区别：黑盒测试方法主要我为了发现：是否有不正确或遗漏了的功能？输入能否正确地接受？

能否输出正确的结果？是否有数据结构错误或外部信息访问错误？性能上是否能够满足要求？是否有初始化或终止错误？所以，用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，检查程序是否都能产生正确的输出。而白盒测试方法主要想对程序模块进行检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性等。 测试方法：黑盒测试是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构

和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。白盒测试是把测试对象看做一个打开的盒子或透明盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

7.

8. 黑盒测试有哪几种方法并且哪种方法最有效？ P131

①等价类划分 软件设计的主要任务是要解决如何做的问题，要在需求分析的基础上，建立各种模型，并通过对 甘特图：表示工作进度计划以及工作实际进度情况最为简明的图示方法，其中横坐标表示时间， 黑盒测试是已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

②边界值分析（最有效）

白盒测试有哪几种方法？逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例

的技术，它属于白盒测试。

由于覆盖测试的目标不同，逻辑覆盖又可分为语句覆盖、判定覆盖、判定—条件覆盖、条件组合覆盖及路

径覆盖（最有效）。

9. 软件测试的原则是什么？ P119

①． 应当把“尽早地和不断地进行软件合理的测试”作为软件开发者的座右铭。

②． 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

③． 程序员应避免检查知己的程序

④． 在设计测试用例时，应当包括合力的输入条件和不合理的输入条件。

⑤． 充分注意测试中的群集现象。

⑥． 严格执行计划，排除测试的随意解释。

⑦． 应当对每一个测试结果做全面检查。

⑧． 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

软件设计的原则：①分而治之和模块化 ②模块独立性③提高抽象层次④复用性设计⑤灵活性设计⑥预防性过期⑦可移植性设计⑧可测试性设计⑨防御性设计

10. 软件维护有哪几类？ P287

1.改正性维护 2.适应性维护 3.完善性维护 4.预防性维护

11. Goto语句的用途和在何种情况下适合？程序的复用，在什么情况下用合适？ P94

① 用非结构化的程序设计语言去实现结构化的构造

② 若不使用GOTO语句就会使程序功能模糊

③ 在某种可以改善而不是损坏程序可读性情况下。

复用是指同一实体不做修改或稍加修改就可以多次重复使用，将复用的思想用于软件开发称为软件复用。软件复用是提高软件质量及生产率的重要方法，软件复用已不再局限于软件代码的代码的复用，复用的范围已经扩展到软件开发的各个阶段，包括需求模型和规格说明、设计模型、文档、测试用例等复用。

12. 程序有哪三种控制结构？

1、顺序结构 2、选择结构 3、循环结构

13. 程序结构化有哪几种条件？

1、一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接

2、每个代码块只有一个入口和一个出口。

14. 软件测试和软件调试的目的？

基于不同的立场，存在着两种完全不同的测试目的。

①从用户的角度出发，普遍希望通过软件测试检验软件中隐藏的错误和缺陷，以考虑是否可以接

受该产品。

②从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已

正确地实现了用户的要求，确立人们对软件质量的信心。

调试的目的：为错误确切地定位，找到出错的根源，并且通过修改程序将其排除。

17. 软件需求分析阶段有哪些步骤？

获取需求、分析需求、定义需求和验证需求

18. 结构分析三种建模方式、定义和作用？

功能建模、数据建模和行为建模

功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。功能模型用数据流图来描述。

在结构化分析方法中，使用实体—关系建模技术来建立数据模型。这种技术是在较高的抽象层次（概念层）上对数据库结构进行建模的流行技术。

状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

19. 软件测试分为几个步骤，每个步骤要干什么？

单元测试、组装测试、确认测试和系统测试

单元测试（unit testing）又称模块测试，是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

组装测试（integrated testing）也叫做集成测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统，把模块组装为系统的方式有两种：一次性组装方式（big bang）和增值式组装方式。

确认测试（validation testing）又称有效性测试。它的任务是验证软件的有效性，即验证软件的功能和性能及其他特性是否与用户的要求一致。

系统测试（system testing）是将通过确认测试的软件，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据、人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据系统的需求分析说明书设计，并在实际使用环境下运行。

20. ?测试、?测试定义，区别？

?测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设臵状态下使用，开发者坐在用户旁边，随时记下错误情况和使用中的问题

?测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户。

与?测试不同的是，开发者通常不在测试现场，由用户记下遇到的所有问题。开发者在综合用户的报告之后进行修改，最后将软件产品交付给全体用户使用。?测试主要衡量产品的FLURPS，着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当?测试达到一定的可靠程度时，才能开始?测试。

21. CAD（Computer Aided Design）计算机辅助设计

CAI（Computer Aided Insruction）计算机辅助教学

CAM（Computer Aided Manufacturing）计算机辅助制造

CASE（Computer Aided Software Engineering）计算机辅助软件工程

22.、传统软件模型的概念

瀑布模型的特点：阶段间具有顺序性和依赖性。其中包含两重含义：

① 必须等前一阶段的工作完成之后，才能开始后一阶段的工作；

② 前一阶段的输出文档就是后一阶段的输入文档。瀑布模型只适用于项目开始时需求已确定的情况。 快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

增量模型也称为渐增模型，是Mills等于19xx年提出来的。

使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。

每个构件由多个相互作用的模块构成，并且能够完成特定的功能。

23、软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

主要表现为：软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难。

软件危机主要有以下一些典型表现:

? 对软件开发成本和进度的估计常常很不准确。

? 用户对“已完成的”软件系统不满意的现象经常发生。

? 软件产品的质量往往靠不住。

? 软件常常是不可维护的。

? 软件通常没有适当的文档资料。

? 软件成本在计算机系统总成本中所占的比例逐年上升。

? 软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入

的趋势。

24、软件工程：软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

25、cmm：能力成熟度模型，该模型按软件过程的不同成熟度划分了5个等级，1级被认为成熟度最低，5级则为成熟度最低

26、面向对象分析：（Object-Oriented Analysis，OOA）是软件生命周期的一个阶段，具有一般分析方法所共同具有的内容、目标及策略。然而，OOA强调运用面向对象方法来对问题域和系统责任进行分析与理解，定义描述问题域和系统责任所需要的对象，定义对象的属性、操作以及对象之间的关系，目标是建立一个符合问题域、满足用户功能需求的OOA模型。

27、UML中的一些图可以用于建立面向对象分析的行为模型。本节讲述其中的典型的顺序图、活动图和状态机图。

顺序图（Sequence Diagram）是一种详细表示对象之间以及对象与参与者实例之间交互的图，它由一组协作的对象（或参与者实例）以及它们之间可发送的消息组成，它强调消息之间的顺序。

活动图可用于对业务过程和操作的算法建模

 

第二篇：软件工程考点总结

第一章

1.软件是程序和所使程序正确运行所需的相关文档和配置信息.软件工程是一门工程学科，涉及软件生产的各个方面.软件过程是指制作软件产品的一组活动及其结果。

2.软件过程的4项基本活动有:软件描述：客户和工程师定义所要生产的软件以及对其操作的一些约束软件开发软件得以设计和编程实现软件有效性验证软件经过检查以保证它就是客户所需要的软件进化软件随不同的客户和变化的市场需求而修改.

3.软件工程人员的工作不仅仅是技术的应用，还要承担很多责任.保密：工程人员必须严格保守雇主或客户的机密，而不管是否签署了保密协议.工作能力 工程人员应实事求是地表述自己的工作能力，不应有意接受超出了自己能力的工作.知识产权工程人员应当知晓控制专利权、著作权等知识产权使用的地方法律，必须谨慎行事，确保雇主和客户的知识产权受到保护.计算机滥用 软件工程人员不应该用自己的技能滥用他人的计算机，滥用计算机有时对他人影响不大（如在雇主的计算机上玩游戏），但有时后果非常严重（传播病毒）.

第二章

1软件工程模型瀑布模型软件描述和开发，分成独立和不同的阶段.增量式开发描述、开发和有效性验证交错进行.面向复用的软件工程基于已存在的很多可复用的组件.

2.瀑布模型：1需求分析和定义，通过咨询系统用户建立系统的服务、约束和目标。2系统和软件设计系统设计过程通过建立系统的总体体系结构将需求分为硬件需求和软件需求。3实现和单元测试将软件设计实现为一组程序或程序单元，单元测试是检验每个单元是否符合其描述。4集成和系统测试集成单个的程序单元或一组程序，并对系统整体进行测试以确保其满足了软件需求。5运行和维护

3瀑布模型的问题1将项目分成不同阶段，难以应付不断变化的客户需求.2当需求十分明确，软件开发中只做有限修改时才适合使用该模型. 3很少有业务系统有稳定的需求。瀑布模型主要是用于大型系统工程项目，且软件项目是大型工程项目的一部分时尤为适用.

4增量式开发优点：1、降低了适应用户需求变更的成本2、容易得到用户及时的反馈3、为及时交付用于的系统提供了可能问题1过程不可见;2系统结构通常较差;3需要专业技能(如快速原型语言等).

5过程活动包括：软件描述、软件设计和实现、软件有效性验证及软件进化.

6软件描述（需求工程）软件描述或需求工程主要是理解并定义系统需要哪些服务以及找出开发和运行期间受到哪些约束.可行性研究：指明现有的软件硬件及能否实现用户对新系统的要求需求导出和分析：通过对现有系统分析、与潜在用户和购买者讨论、进行任务分析等导出系统需求的过程需求描述：把在分析活动中收集的信息以文档的形式确定下来。需求有效性验证：检查需求的现实性、一致性和完备性。

7软件设计和实现把系统描述转化为一个可运行的系统的过程。软件设计，实现软件的结构、系统的数据等描述。实现，把软件结构转化为可执行的程序。体系结构设计识别系统总体结构、基本组件、它们之间的关系以及它们是怎样分布。接口设计定义系统结构的借口组件设计针对每个系统组件设计它的运行方式数据库设计设计系统数据结构，以及如何在数据库中表示这些数据结构

8软件有效性验证也称检查和有效性验证，是为了表明系统符合其描述，满足了客户的需求. 包括检查和审查过程，还有系统测试.组件或单元测试由开发系统的人员对组成系统的组件进行测试系统测试集成组件形成完整的系统。并测试是否满足需求。接收测试系统在接受并运行之前的最后阶段测试

9软件进化软件本质是灵活的，可以改变的. 由于业务环境的不断变化，客户需求也随之发生变化，该软件支持的业务也必须不断更新和修改.

10.Rational统一过程来自于UML上的工作和相关的软件开发过程.开端建立一个业务案例细化增进对问题域的理解，建立系统的体系框架，给出项目计划、风险构造系统设计、编程和测试转换在其操作环境部署这一系统.过程工作流：业务建模；需求；分析和设计；实现；测试；部署；支持工作流：配置和变更管理；项目管理；环境RUP 好的实践：反复地开发软件；对管理需求；使用基于组件的体系结构；可视化模型软件；验证软件质量；控制对软件的变更

第三章

1.XP和敏捷方法的原则1增量式开发是通过系统的小的频繁开发的版本来支持的；2客户的参与是通过全时雇佣到开发团队的方式；3人（而不是过程）是通过结对编程、集体对系统代码的所有权、可以忍受的开发过程而无需超额的工作小时来运作的；4变更是通过经常性的系统版本来支持的；5通过持续的再分解来维护系统的简洁性。

2问题：1很难将兴趣保持在参与到开发的客户身上。2团队成员个人可能从性格上不太适应激烈的投入，这是敏捷方法的典型特征。3对变更做出优先级排序可能是极困难的，尤其是对那些有很多参与者的系统。4维护简洁性需要额外的工作。5许多机构很难向另一种工作模型转换。6随着其他迭代方法的发展，合同可能也是极限方法的一个问题。优点1极限编程将增量式开发推向极致。2极限编程将软件进行再分解（refactoring ），使得当新情节实现的时候软件总是容易理解和改变的。3.在创建程序特征之前开发自动测试。

3结对编程优点：1它支持共同拥有软件和共同对系统负责2它担当了非正式的复查过程3有助于支持重构

第四章

1需求工程过程包括可行性研究、需求导出和分析、需求描述、需求有效性验证及需求管理。 2功能需求对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。非功能需求对系统提供的服务或功能给出的约束。时间约束、开发过程的约束、标准等。 3功能需求描述系统所预期提供的功能或服务。取决于开发的软件类型、软件未来的用户以及开发的系统类型。理论上，系统的功能需求应该既全面又具有一致性。全面用户所需的所有服务都应该给出描述；一致性在对系统功能需求进行描述时，不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。

4非功能需求它们定义系统的属性和约束。非功能性需求比功能性需求更关键。产品需求这些需求定义或约束软件的行为。机构需求很广泛的系统需求，起源于客户所在的机构和开发者所在的机构中的政策和规定。外部需求包括所有来自于系统外部因素和开发过程的需求。 非功能性需求可能是很难精确描述的，并且不精确的需求可能也难以得到检验。系统目标用户的一般的要求，比如系统的易用性。可检验的非功能需求应用某些度量进行描述，它们可以客观的得到验证。

5需求导出和分析（4个活动）：1需求发现这是一个与系统的信息持有者交流从而收集他们的需求的过程。来自信息持有者和文档的领域需求是在这个活动中得以发现的。2需求分类与组织所收集的需求是无序的，需要对其重新组织和整理，将其分为相关的几个组。3需求优先排序和协商对需求进行优先权排序，并通过协商发现且解决这些冲突。4需求描述记录需求并将它作为螺旋下一个循环的输入，产生形式化和非形式化的需求文档。系统需求导出和分析是困难的：1信息持有者表述泛泛2需求工程师没有领域知识3不同的信息持有者需求不同4政治上的因素影响系统需求5经济和业务环境是动态的

6需求发现是一个收集准备建立的系统和正在使用的系统的信息，并从这些信息当中提取用户和系统需求的过程。信息源包括已有文件、系统信息持有者以及类似系统的相关内容。 7脚本（场景）是对交互实例片段的描述。一个场景可能包扩以下内容：1在场景的开始部分有一个系统状态描述；2一个关于标准事件流的描述；3一个关于哪儿会出错以及如何处

理错误的描述；4有关其他可能在同一时间进行的活动的信息；5在场景完成后系统状态的描述。

第五章

活动图，表示一个过程或数据处理中所涉及的活动用例图，表示一个系统和它所处的环境之间的交互。时序图，表示参与者系统之间以及系统各部分之间的交互类图，表示系统中对象类以及这些类之间的联系状态图，表示系统是如何响应内外部事件的。

第六章

1明确设计和文档化软件体系结构好处：1信息持有者之间的沟通体系结构可以作为不同的项目相关人员之间讨论的焦点2系统分析系统分析对体系结构的设计决策，对系统能否满足非功能需求具有很大的影响3大规模复用体系结构能在相似需求的系统之间互用，以支持大规模的软件复用。

2分层体系结构分层模型用来把系统组织成一系列的层次，每一层提供一组服务。

3容器体系结构系统所有数据在一个中央容器中管理，该容器可被所有系统组件访问组件通过容器交互。优点它是共享大量数据的一个高效方法；子系统不必关心数据是如何集中进行的这些活动；共享模型能通过容器模式而看得见。缺点子系统一定要与容器数据模型一致，不可避免地，每个专用的工具之间要做出妥协；数据进化变得很困难和昂贵；容器模型迫使所有的子系统使用相同的策略；很难将容器有效的分配到多台机器上。 4客户机/服务器体系结:优点数据的分布式最直接的; 可以更有效地使用网络系统，从而降低了对硬件的要求；很容易就添加一台新的服务器或更新现有的服务器。缺点没有共享数据模型，子系统以不同的方式组织它们的数据。数据交换效率就可能很低；每个服务器上出现冗余数据管理；没有中央寄存器的名字和服务，这可能很难找出哪个服务器和哪些服务可用。 5管道和过滤体系结优点：易于理解并支持变换的复用。缺点：通信变换间所传输的数据格式必须协商好。

第七章

1复用 1抽象层:不直接复用，运用软件设计中的成功抽象。2对象层：直接复用库中对象，代替自己编写代码3组件层：通常需要添加自己的代码对组件进行调成和扩展 4系统层：复用整个系统

2配置管理管理变更中软件系统的一般过程1版本管理对软件不同版本的追踪提供支持2系统集成提供支持帮助开发人员定义在创建每个系统版本时所用的组件版本 3问题追踪提供支持允许用户报告缺陷及其他问题，并允许开发人员谁在修复这些问题，以及何时完成修复。

第八章

1检验: “我们是否在正确地构造一个产品”。软件应该符合设计规格。有效性验证: "我们是否在构造一个正确的产品”。软件应该满足用户所需要的。

2商业软件测试3阶段：1开发测试2发布测试3用户测试

3开发测试：1.单元测试，对单独的程序单元活对象类进行测试（功能）。2组件测试，多个程序单元整合创建一个合成的组件（接口）3系统测试，一些或所有组件作为整体（交互）。 4选择单元测试案例：1划分测试，识别具有共同特征和以同样方法处理的一组数据。2基于准则测试，使用测试准则来选择测试案例。

5准则：用一个只有单个值的序列来测试软件；在不同的测试中使用不同规模的多个序列；导出一个测试，让序列的第一个、中间一个和最后一个元素得到测试；测试序列的长度为零。原则：选择能强制系统生成的所有错误信息输入；设计能够使系统的输入缓冲溢出的输入；重复相同的输入或一系列输入很多次；使产生无效的输出；迫使输出结果太大或者太小。 6组件测试：1参数接口数据从一个过程传到另外一个过程2共享内存接口内存块为过程或函数所共享3程序接口子系统封装一组程序，这些程序为其他子系统调用4消息传递接口子

系统通过传递消息请求其他子系统上的服务。接口错误3类：接口误用调用者组件在调用其他组件时因接口使用不当而发生接口错误。接口误解调用者组件误解了被调用组件的接口描述而产生错误，对呗调用组件进行了错误的假设。时序错误调用和被调用组件以不同的速度运行，中间过时的数据无法得到正确的处理.

7用户测试：α测试：软件用户和开发小组一起在开发小组一起在开发者的地点测试这个软件。β测试：该软件的版本是提供给用户让他们进行测验，并向开发者提供发现的文题。接受测试：客户测试系统决定他们是否愿意从系统开发者哪里接收系统并在客户环境中部署。接收测试六个阶段：1.定义接受准则（合同）2.计划接受测试 3导出接收测试 4.运行接受、测试 5协商测试结果 6 拒绝/接收系统

第九章

1软件进化：变更请示、影响分析、版本规划（缺陷修补、平台适应、系统增强）、变更实现、系统发布。变更实现：提议的变更、需求分析、需求更新、软件开发紧急修补过程：变更请求、分析源代码、修改源代码、移交修改的系统。

2软件维护：1、修补软件缺陷（纠正性）2、是软件适应不同操作系统（适应性） 3、增加或修改系统功能（完善性）

3投入后代价增加原因：1团队稳定性2糟糕的开发实践3人员技术水平4程序年龄和结构。

第25章

1配置管理包括：变更管理：包括跟踪来自客户和开发者的软件变更请求，计算做出这些变更的花费并估计其影响，决定是否变更，何时完成变更。版本管理：包括跟踪系统组件的多个版本，确保由不同开发者对组件做出的变更不会彼此干涉。系统构建：是一个组装程序组件，数据和库的过程，然后把这些组件编译连接成一个可以执行的系统。发布管理：包括准备对完发布的软件，持续跟踪已经发布以供客户使用的系统版本。

2配置项（软件配置项）：与配置管理控制下的软件项目有关的任何事物。配置项会存在多个不同的版本，每个配置项都有一个唯一的名字。

3变更管理确保系统的进展是一个可管理的过程。主要关心的是对提建议的变更的成本收益分析，保证变更值得做，并记录系统的哪些组件已经改变。变更请求考虑的因素：不做变更会引起的后果，变更的益处，变更影响的用户数，变更所需花费，产品发布循环。

4版本管理是跟踪软件组件或配置信息以及使用这些组件系统的不同版本的过程。版本管理系统通常提供一系列特征：版本和发布版本识别被管理版本提交给系统时给他们分配标识符存储管理为了减少存储空间，版本管理系统会提供存储管理工具变更历史记录记录并列出所有对系统或组件作出的变更独立开发确保由不同的开发者对组件做出的变更互不影响项目支持一个版本管理系统可能支持共享组件的几个项目的开发。