27-术语与缩略语一览表

"序

号",术语中文,术语英文,定义,详细描述（可选，如举例）,责任人,备注

1,Beta版本,,经过研发中心内部测试通过的程序版本，可作为正式版本的备选版本，需要提供给各项目进行确认和评估。,,,

2,Beta测试,,由实施项目成员针对本项目反馈的问题进行确认，以及本项目主要业务流程确认的测试。,,,

3,CC圈复杂度,CyclomaticComplexity,一种代码复杂度的衡量标准，用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行路径条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误和高的圈复杂度有着很大关系。,"CC=D+1

D表示判定条件的数量，即程序中if、for、while语句以及and、or等操作符的数量。

WeightedMethodsPerClass1(WMPC1)类中每个方法圈复杂度的合计。

CommentRatio(CR注释比率)程序中注释行数与总行数的比率。

NumberOfMembers(NOM)类中属性和方法个数的合计。",,

4,Checkin,,,,,

5,Checkout,,,,,

6,QA（质量保证）,Qualityassurance,为了提供足够的信任表明实体能够满足质量要求，而在质量体系中实施并根据需要进行证实的全部有计划和有系统的活动。,,,

7,QA标准活动,,"QA的标准活动主要是：

1、工作产品检查

2、过程/流程审计

3、不符合项跟踪

4、项目指导与培训

5、QA记录与报告

6、过程改进并推广","1、工作产品检查：对照适用的标准和规程客观地评价工作产品的及时性、规范性、有效性；

2、过程/流程审计：对照适用的过程描述、标准和规程客观地评价所执行的过程或流程的及时性、规范性、有效性；

3、不符合项跟踪：识别不符合项并形成文件；跟踪并确保不符合项得到处理；

4、项目指导与培训：给项目组提供所需的规范的培训；

5、QA记录与报告：向项目工作人员和管理者反馈质量保证活动情况；

6、过程改进并推广：识别组织内最佳实践，提交EPG评审并推广；对采集数据进行度量分析，寻找改进点。",,

8,QA活动报告,,QA人员每月提交的关于本人的工作内容、花费的时间、发现的问题等，便于品质保证经理了解QA工作状况及效率。,,,

9,QA检查记录,,根据过程或主要产品的检查表（checklist）进行检查，在checklist中记录检查结果并存档。,,,

10,QA总结报告,,主要针对产品/项目状态跟踪表、主要工作产品跟踪表和质量保证活动报告进行分析、计算，按问题分类、按项目、按部门统计检查出来的各类问题发生的次数、耗费的工作量等，总结汇总成功的项目的成功经验和值得在公司推广的最佳实践，过程尽职调查的总结，每半年一次。,,,

11,StarTeamLabel,,,,,

12,StarTeamProject,,,,,

13,StarTeamView,,,,,

14,WBS,,即工作分解结构，WBS中的每一项都是一个工作包，包括我们需要做的内容/事项，所为最基本的项目要求。WBS是一个层次化的树状结构。,,,

15,版本,Version,版本是某一配置项的已标识了的实例（Instance）。也可以说，不可变的源对象经质量检查合格后所形成的新的相对稳定的格局（配置）称为软件版本。,,邵婧,

16,版本范围定义,,,,邵婧,

17,版本分支,,avariantdevelopmentpaththatdivergesfromtheprimarydevelopmentpath,,邵婧,

18,版本管理场景,,围绕版本管理场景，考虑相应的管理方法，并结合配置管理工具能够提供的工具（比如project、view、label等），考虑其构建体系和相应的管理策略。,,邵婧,

19,版本号,,产品的唯一标识，由一些数字和字母组成的后缀，用于对软件产品的版本进行标识,,邵婧,

20,版本合并,,theactivityof‘joining’modificationsperformedsimultaneouslytodifferentcopiesofthesamemodule,,邵婧,

21,版本控制,VersionControl,,,邵婧,

22,版本配置项,,包括程序清单、工具清单、用户文档、实施文档、更新说明等等。,,邵婧,

23,版本遗留问题,,,,,

24,变更,,对在配置库中存储并已经纳入基线的产品进行修改，即为变更。,,邵婧,

25,不符合项问题分类,,不符合项分类意在区分不同类型的不符合项便于统计分析，找出应进行改进的地方。,"目前公司将不符合项分为以下几类：

1、文档规范性：指采用不规范的文档模板或关键条目漏填。

2、文档及时性：根据项目计划约定的里程碑阶段提交相应文档产品，如延期两周以上或忘记提交入库即为不符合。

3、文档有效性：重要文档需要评审入库，并与实际情况相符，如果未经评审或在配置库中找不到评审证据，或者文档描述与实际情况有偏差而未进行变更，则视为文档有效性不符合。

4、过程规范性：项目应按照公司制定的过程规范执行项目各个过程，重要过程不应被忽略，如不一致便是不符合。

5、过程及时性：当特定情况下应及时采用适当的过程",,

26,测试报告,,,,,

27,测试环境,,,,,

28,测试用例,,,,,

29,产品实施方案,,针对实施和售后的技术解决方案，主要包括产品系统实施时应注意的事项，为什么要这样来实施，产品实施包含的内容。,,,

30,产品愿景,,,,,

31,产品咨询方案,,针对售前／需求调研，主要包括产品的特性／优势；针对业务的具体处理方法和解决方案，帮用户建立相应的规范制度。,,,

32,抽查计划,,由于品质保证人员无法跟踪所有项目的执行情况，每月制定抽查计划，选3-5个项目进行配置库的抽查，范围要覆盖研发中心所有的项目。,,,

33,初验,,,,,

34,代码评审,,把软件代码呈现给项目人员、管理人员、用户、客户或其他感兴趣的人员用于评论或批评的会议。,注：该术语定义引自[GB/T11457-2006]。,,

35,单元测试,,,,,

36,调研对象,,,,,

37,调研计划,,,,,

38,调研时间确认,,,,,

39,调研提纲/调查问卷,,,,,

40,度量,,系统、部件或进程占有给定的属性的程度的数量的测量。,,,

41,发版计划,,,,,

42,访问控制,,"按用户身份及其所归属的某预定义组来限制用户对某些信息项的访问,或限制对某些控制功能的使用。访问控制通常用于系统管理员控制用户对服务器、目录、文件等网络资源的访问。",,邵婧,

43,非功能性需求,,,,,

44,风险,,遭受损失的可能性。,,,

45,风险管理,,识别潜在的问题，以便策划处理风险的活动和在必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。,风险管理包括风险的识别、分析、优先级排序和控制。,,

46,干系人,,是受到某种负责产生输出的方式影响的群体或个人。干系人可能包括项目经理、供方、顾客以及其他人。术语“相关的干系人”用于指某个计划中要求执行某类活动或接收某类信息的群体和个人。,,,

47,更新说明,ReleaseNotes,说明当前程序版本所作调整的描述文档。分为程序修改更新说明和正式发本更新说明。,,邵婧,

48,工程规范,,指公司内部制定的针对项目的一些的规范，如编码规范、注释规范、界面规范等。,,,

49,工作产品,WorkProduct,是项目活动的执行过程所产生模板、文档、代码和样例，也称为交付件。,,,

50,工作产品检查,WorkProductCheck,使用相应工作产品的检查表（CHECKLIST），针对工作产品进行规范性检查。,,,

51,工作空间,,存在两类工作空间，一类是开发人员的私有空间，在私有空间中，开发人员可以相对独立地编写和测试自己的代码，而不受团队中其他开发人员工作的影响，即使其他人也在修改同样的文件；另一类工作空间是团队共享的集成空间，该空间用于集成所有开发人员的开发成果。,,邵婧,

52,工作量估计偏差,,,计算公式：（实际总工时-计划总工时）/计划总工时*100,,

53,公司项目状态视图,,公司所有项目状态的一览表，可以了解公司所有项目的大致情况及当前状态。由公司级的配置管理员进行维护更新，各部门经理和项目经理配合进行信息的收集。,,,

54,功能,Function,系统或部件的定义的目标或特征动作，例如，一系统有库存控制作为它的主要功能。,,,

55,功能点,FunctionPoint,,,,

56,功能模块,FunctionModule,,,,

57,功能模块图,,以层次结构画图说明系统划分为多少个功能模块，以及各功能模块之间的关系，系统都有一个总的目标，为了达到这个目标，必须要完成各子系统的功能，而各子系统功能的完成，又依赖于下面各项更具体功能的执行。,,,

58,功能评审,,,,,

59,功能清单,,,,,

60,功能性需求,,,,,

61,构建,,theprocessthroughwhichsoftwareworkproductsaretransformedintoanexecutableorusableformat,,邵婧,

62,构建脚本,,,,邵婧,

63,构建体系,,,,邵婧,

64,故事板,,,,,描述其用途，并举例说明

65,过程,,为满足项目生命周期过程中特定的管理或工程目标而进行的把输入转换为输出的一组彼此相关的活动，比如配置管理过程、项目计划过程、项目估算过程等。,,,

66,过程/流程审计,ProcessAudit,通过调查研究确定已制定的过程、指令、规格说明、代码和标准或其他的合同及特殊要求是否恰当的被遵守，以及其实现是否有效而进行的活动。,,,

67,过程裁剪,,通过对过程的过程元素的细节或其他不完备的规范进行提炼、调整和（或）补充的方法来生成过程描述的一种活动。在过程裁剪期间通常说明项目的特定业务需要。,,,

68,过程尽职调查,,不定期对项目和员工抽样，下发调查表，收集员工对组织定义的过程的认可度情况。了解员工在参与的项目中认为做得好的实践有哪些，做得不好的实践有哪些，公司标准研发流程有哪些过程需要改进。,,,

69,活动,,增加经验的度量标准。,是项目生命周期过程为完成项目而采取的行动，如编制开发进度表、制订配置管理计划、备份项目配置库等。,,

70,活动图,,活动图描述各种活动的顺序关系。,,,

71,基线,Baseline,项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于这个标准进行，并且只有经过授权后才能变更这个标准。,,邵婧,

72,集成,,就是把分开的代码和程序集中在一个产品包中,,邵婧,

73,集成测试,,,,,

74,技术方案,,针对招标书或者用户原始项目目标提供的，包括部署、系统架构、大粒度功能描述、主要技术解决要领、实施培训等内容的综合文档。,,,

75,技术规范书,,招标时由甲方提供的对项目的技术和业务方面要求。,,,

76,技术建议书,,投标时……,,,

77,架构,,,逻辑架构、物理架构、部署架构,,

78,检查表,Checklist,列举一些检查要点并记录检查结果的表格。用于对过程的审计或主要产品的检查。,,,

79,建模,,,需求建模、业务建模、数据建模,,

80,角色,,,,,

81,进度估计偏差,,,计算公式：（项目实际总周期-项目计划总周期）/项目计划总周期*100,,

82,进化型原型,,,在已经清楚地定义了需求的情况下，进化型原型为开发渐增式产品提供了坚实的构造基础。进化型原型是螺旋式软件开发生存周期模型的一部分（Boehm1988），也是一些面向对象软件开发过程的一部分（Kruchten1996）,,增加精细的描述，以及举例

83,开发规范,,开发前的约定，内容涵盖代码组织和风格、注解、命名、声明等，目的是使本项目能以标准的、规范的方式设计和编码。以增强代码的可维护性和可升级性，同时使自己养成了良好的编码风格。,,邵婧,

84,客户化开发,,,,,

85,类图,,描述所有类之间的关联、继承、依赖等关系,,,

86,里程碑,,,,,

87,录音笔,,需求访谈的工具,,,

88,内部版本,,编码阶段完成后，提交测试的版本,,邵婧,

89,抛弃型原型,,,当你遇到需求中的不确定性、二义性、不完整性或含糊性时，最合适的方法是建立抛弃式模型。你需要解决这些问题以减少在继续开发时存在的风险。原型可帮助用户和开发者想象如何实现需求和可以发现需求中的漏洞。它还可以使用户判断出这些需求是否可以完成必要的业务过程。,,增加精细的描述，以及举例

90,配置,Configuration,指在配置管理中，软件或硬件所具有的（即在技术文档中所陈述的或产品所实现的）那些功能特性和物理特性。,,邵婧,

91,配置标识,ConfigurationIdentification,,,邵婧,

92,配置管理,ConfigurationManagement,配置管理是对配置项在运用技术上和行政上的管理和监视的一门学科。对一个配置项的功能特性和物理特性进行标识并写成文档；对这些特性的更改进行控制；对更改处理过程和实施状态进行记录和报告；以及对是否符合规定需求进行验证。,,邵婧,

93,配置管理标准活动,,,,邵婧,

94,配置管理环境,,,,邵婧,

95,配置管理要素,,需要进行变更控制的要素，如人员、进度、主要配置项等。,,邵婧,

96,配置控制组/委员会,ConfigurationControlBoard,是对提出的配置项的变更负责进行评价、批准或不批准，并保证批准的变更的实现的权利机构（一组人）。,,邵婧,

97,配置审核,ConfigurationAuditing,"配置审核是软件配置管理的一个要素，它根据需求、标准或合同协议检验软件产品。

配置审核主要目的是以用户和开发团队均认可的衡量尺度（例如与用户签定的软件合同），通过功能审核及物理审核两种方式，对软件实施过程和软件功能的完整性、正确性进行检验审核。配置审核确保软件配置管理系统作用正确，保证测试过后的配置项功能满足需求。

",,邵婧,

98,配置项,ConfigurationItem,为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一单个实体来对待。,注：该术语定义引自[GB/T11457-2006],邵婧,

99,配置项安全级别,,配置项保密级别，对应不同级别约定不同的使用权限,,邵婧,

100,配置项依赖关系,,配置项的继承和引用关系,如，现有项目开发基于原有项目代码,邵婧,

101,配置状态统计,ConfigurationStatusAccounting,配置状态统计是软件配置管理的一个要素，由有效管理所需的记录和报告信息组成。这些信息包括经核准的配置标识表、需要变更的配置状态和实施经审核的变更状态。状态统计主要目的是在版本控制与过程管理的基础上，通过量化的数据和报表展现软件开发进度的状态。,,邵婧,

102,评审,,把工作产品或一组工作产品提交给项目个人、管理者、用户、客户或其他感兴趣的部门为了评论或批准的过程或会议。评审可以在项目前期发现产品问题并采取解决措施，遵循问题越早发现越早解决越经济的原则，可有效的降低后期发现问题并解决的成本。,,,

103,普通项目,,普通项目是指一项在特定的环境与要求下有待完成的任务，项目必须在一定的组织机构内，利用有限资源（人力、物力、财力等）在规定的时间内完成任务，且任务要满足一定性能、质量、数量、技术指标等要求。,"普通项目具有以下基本特性：

1、一次性；

2、独特性；

3、目标的确定性；

4、组织的临时性和开放性；

5、成果的不可挽回性。",,

104,缺陷分类,,按照缺陷的严重程度分为重大缺陷、待确认缺陷、一般缺陷。重大缺陷指在软件开发过程中的针对软件产品和开发过程的问题，这些问题已经影响用户的正常使用。待确认的缺陷指该缺陷需要测试人员进行重现和确认是否为缺陷。一般缺陷指在软件开发过程中的针对软件产品和开发过程的问题，这些问题已经影响或者可能影响软件产品的质量。,,,

105,缺陷密度（代码缺陷率）,DefectDensity,产品中标识出的缺陷数目除以产品成分的规模。,"计算公式：实际缺陷总数/代码行合计数（新增+修改）*1000

单位：个/千行",,

106,任务,,是项目活动的最小单元，是项目成员日常需要完成的具体工作事项。任务通常可被分配到具体人员、可被跟踪、可被度量。,,,

107,软件基线库,,是由主要配置项组成的，可以是逻辑上的概念，由label组成。,,邵婧,

108,软件开发库,SoftwareDevelopmentLibrary,指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。,,邵婧,

109,软件配置,SoftwareConfiguration,指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。,,邵婧,

110,上线,,,,,

111,申请立项部门,,,,,

112,申请立项人,,,,,

113,审计,Audit,"a)为评估工作产品或工作产品集是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立的检查。

b）通过调查研究确定已制定的过程、指令、规格说明、代码和标准或其它的合同及特殊要求是否恰当和被遵守，以及其实现是否有效而进行的活动。","注：该术语定义引自[GB/T11457-2006]。

",,

114,生产环境,,,,,

115,生产率（编码效率）,,生产率描述一个项目团队在一定时期内交付软件数量的能力。,"计算公式：标准代码行合计数（新增+修改）/实际总工时*176

单位：行/人月",,

116,生命周期模型,,一个框架，它含有从需求定义到使用终止，跨越整个生存期的系统开发、操作和维护中所需实施的过程、活动和任务。,,,

117,时序图,,描述一个完整的业务功能操作的处理流程，通过类之间的调用关系流程来体现程序的执行顺序,,,

118,试运行,,,,,

119,输出目录,,指经过构建产生的交付物存放路径,,邵婧,

120,特征,Feature,,,,

121,外部假设,,,,,

122,外部约束,,,,,

123,维护型项目,,,,,

124,文档编码,,用来区分项目中各类文档所进行的编码，该编码无须项目组自己修改。详情参见项目立项过程中《项目及文档编码规范》。,,,

125,问题,,指系统上线后，用户反馈的所有有关软件系统的问题，包括需求和缺陷。,,,

126,问题级别,,按照问题需要处理的紧迫程度分为非常重要、重要、一般。可以从用户的满意度和修改的影响范围两个方面来定义。非常重要优先级高，要求能在一周之内予以解决或者给出解决办法。重要优先级一般，要求能在两周之内予以解决。一般优先低，要求能在一个月之内解决。,,,

127,问题确认,,确认指问题流转各环节对问题的处理意见。确认结果可分为支持经过分析该需求有开发价值或确认修改该缺陷。不支持经过分析该问题无开发价值或实现困难。取消由于某种原因该问题撤销，不需要继续处理。,,,增加对流程具体环节详细描述

128,问题状态,,指问题所处的处理状态。分为待处理、处理中、验证中、确认通过、关闭等。,,,

129,系统测试,,,分为：性能测试、压力测试、疲劳测试、兼容性测试、配置测试、安全性测试、可用性测试,,

130,系统初始化,,,,,

131,项目/产品市场现状及潜力,,,,,

132,项目备忘录,,,,,

133,项目编号,,项目的唯一标识，项目编号规范请参考项目立项过程中《项目及文档编码规范》。,,,

134,项目大事记,,针对项目过程中间，值得记录的重要里程碑、人员重大调整、需求重大变更等，形成的序时簿，可以理解为一个项目台帐。,,,

135,项目范围,,项目范围管理即定义和确认项目工作内容，主要是指项目需求，包括功能需求、过程需求等，包括项目启动、范围定义、范围核实、范围变更控制。通常通过WBS体现出来。,,,

136,项目分类,,按照公司目前不同种类项目，将公司的项目划分为：新产品开发项目、普通开发项目、维护型项目、专题研究型项目。在立项时进行识别，并按照相应的过程规范进行实施，QA人员有所侧重的进行检查。,,,

137,项目负责人,,对整个项目的业务工作负全面责任的一种角色；或对建立软件系统或硬件/软件系统的项目进行指导、控制、管理和调整的人员。,,,

138,项目级别（项目过程成熟度级别）,,划分为两个级别：高成熟度项目、普通成熟度项目。,,,

139,项目技术可行性分析,,分析项目按照既定需求完成公司的技术支撑是否具备。,,,

140,项目来源,,项目的大概背景介绍。,,,

141,项目联络人,,因为商务或管理上的需要，负责公司层面的协调资源，监控项目进度，与用户/公司领导共同协调，通报项目重大事项的人，项目联络人不介入项目具体事物或介入项目具体事物很浅，不掌握项目关键信息。,,,

142,项目路线图,,项目根据公司的各类项目规范流程要求制定并可视具体情况进行裁剪，形成的该项目过程及产品的视图。,,,

143,项目目标,,通过这个项目要达到的目标是什么，比如队伍的锻炼或客户关系的提升，过程规范的掌握，市场占有率提升等，可以用一些量化的指标进行说明。,,,

144,项目需求概述,,简要的概括需求情况，区分目前已有的功能和需定制开发的功能。主要要将需要定制开发的功能以及性能、安全性等方面的需求描述清楚。,,,

145,项目意义,,项目顺利完成给其他项目或市场方面产生的积极影响。,,,

146,新产品开发项目,,新产品开发项目是指公司为满足预期的市场需求而在公司内部立项研发的软件项目。,"新产品开发项目具备如下特征：

没有确定的客户与合同

有明确的目标客户群

有明显的预期经济效益",,

147,需求变更率,,,计算公式：需求变更总数/需求总数*100,,

148,需求分类,,按照需求特性分为待讨论需求、特殊需求及一般需求。待讨论需求指该需求需要经过产品组人员进行讨论。特殊需求指该需求的特殊性，一般是工作量较大或是原需求上改动较大的需求。新需求目前产品功能无法满足的需求点，该需求具有一定的通用性，可以完善产品,,,

149,需求规格说明书,,侧重于功能模型，明确系统中需实现的功能以及功能与业务之间的联系,,,

150,需求说明书,,侧重于业务模型，明确系统中所需要实现的业务以及各种业务之间发生的应用场景，可以描述推荐的方法，比如功能