CMMI中英文术语对照表
- 格式：pdf
- 大小：474.46 KB
- 文档页数：14
CMMI中英文术语对照表A-D E-L M-R S-ZAability to perform执行的能力: （参见公共特性/common feature）acceptance criteria接受标准：为让用户、客户或其他授权组织接受，一个系统或组件所必须满足的条件。
[IEEE-STD-610] acceptance testing接受性测试：用来决定系统是否达到接受标准的正规测试，从而能够使客户决定是否接受系统。
[IEEE-STD-610]acting phase行动阶段：（参见IDEAL 方法）action item行动项目：（1）列表中分配给个人或组进行处理的一个单元。
（2）已被接受的一项行动提议。
action proposal行动提议：文档化的修改过程或过程相关项的建议，用以防止缺陷预防活动中发现的缺陷再发生。
（参见软件过程改进提议/software process improvement proposal）activities performed执行的活动：（参见公共特性/common features）activity活动：为达到某些目标而执行的一个步骤或一项功能，可能是脑力的也可能是体力的。
包括管理和技术人员为执行项目或组织工作任务而进行的所有活动。
（比照任务/task）Allocated requirements分配的需求：参见系统分配至软件的需求/system requirements allocated to softwareappraisal评审：是一个广泛意义上的词，可以是软件过程评估（process assessment），也可以是软件能力的评价（capability evaluation）。
assessment评估：在CMM中，一般指内部的过程评估。
audit审核：对一个或一套工作产品的独立的检查，用以确定是否符合规格说明、标准、合同协议或其他的准则。
[IEEE-STD-610]Bbaseline基线：经过正式审查并被一致认可的规格说明或产品，作为进一步开发基础，只有通过正式变更控制程序才能改变。
[IEEE-STD-610]baseline configuration management基线配置管理：建立经过正式评审和认同的基线，并将其作为进一步开发工作的基础。
一些软件工作产品，如软件设计和代码应按计划建立基线，并使用严格的变更控制过程进行管理。
这些基线使得与客户的交互在稳定及可控的状态下进行。
（参见基线管理/baseline management）benchmark基准：进行度量或比较的标准。
bidder投标者：个人、合作伙伴、公司或联合组织提交了意向书，就成为了获取设计、开发、及/或制造一个或多个产品合同的候选者。
Ccapability maturity model能力成熟度模型：软件组织通过定义、执行、度量、控制、改进软件过程而不断提高，能力成熟度模型就是提高过程不同阶段的描述。
通过帮助确认当前过程能力，帮助确定那些对于软件质量和过程改进最迫切的问题，这个模型对于如何选择过程改进战略提供了指导。
causal analysis诱因分析：分析缺陷来确定导致缺陷的根本原因。
causal analysis meeting诱因分析会：完成一项具体任务后所进行的会议，用来分析在完成任务期间发现的缺陷。
commitment承诺：根据需要建立的、可见的且相关各方应遵守的协定。
commitment to perform执行的承诺：参见公共特性/common featurescommon cause（of a defect）缺陷的一般原因：导致缺陷的来自系统或过程本身的原因。
一般原因影响过程的每个结果和过程中的每个人。
（对照特殊原因/special cause）common features公共特性：是CMM关键过程域中内容的分类。
公共特性是表明一个关键过程域的制度化和实施是否有效、可重复和持续的属性。
公共特性包括执行的承诺、执行的能力、执行的活动、度量和分析和执行的验证· commitment to perform 执行的承诺为保证过程得以建立和持久的，一个组织所必须采取的行动。
执行的承诺一般将包括建立组织政策和领导责任。
· ability to perform 执行的能力为有效执行软件过程，项目和组织所必须具备的一些前提条件。
执行的能力一般包括资源、组织结构和培训。
· activities performed 进行的活动对执行一个关键过程域所必须的活动、角色和规程的描述。
进行的活动一般包括建立计划和规程、执行和跟踪工作以及在必要时采取更正措施。
· measurement and analysis 度量与分析对用以确定过程相关状态所必须进行的基本度量做法的描述。
这些度量用来控制和改进过程。
度量与分析一般包括可以进行的度量的例子。
· verifying implementation 验证实施为确保活动与已建立过程保持一致所采取的步骤。
验证一般包括管理者和软件质量保证组所进行的监察和审查。
configuration配置：在配置管理中，技术文档中描述的或软件产品中实现的软件或硬件的功能和物理特性。
[IEEE-STD-610]configuration control配置控制：配置管理的一个要素，包括评审、协调、批准或不批准以及正式建立配置标识后对配置项的更改。
[IEEE-STD-610]configuration identification配置标识：配置管理的一个要素，包括为一个系统选择配置项并在技术文档中记录它们的功能和物理特性。
[IEEE-STD-610]configuration item配置项：为配置管理指定的软件、硬件或包括两者的一个集合，在配置管理过程中作为一个独立实体。
configuration management配置管理：是使用技术及行政指导和监督的一个规范，用以确定和记录一个配置项的功能和物理特性，控制对这些特性的修改，记录并报告变更处理及执行的状态，并验证其与特定要求的符合性。
[IEEE-STD-610]configuration management library system配置管理库系统：访问软件基线库内容的工具和规程。
configuration unit配置单元：配置项或组件的最底层实体，可以放入配置管理库系统，也可以从中提取。
consistency一致性：统一、标准化以及不与系统或组件中其它部分相矛盾的程度。
[IEEE-STD-610] contingency factor或有因素：对规模、费用或进度计划的调整（增加），以处理可能发生的对这些项的低的估算，导致过低估算的原因有不完整的规格说明、对应用领域的估算缺乏经验等等。
contract terms and conditions合同条款与条件：合同中描述的法律、财务及行政管理方面的内容。
critical computer resource关键计算机资源：可能带来项目风险的计算机资源，因为对这些资源的需求会超出可用的数量。
如运行机的内存、开发机的磁盘空间。
critical path关键路径：必须按计划完成以使整个项目不脱离计划的一系列相互关联的任务。
customer客户：负责接受产品及有权支付开发组织的个人或组织。
Ddefect缺陷：系统或系统组件中导致系统或系统组件不能按要求功能执行缺陷。
如果在系统运行时遇到缺陷将导致系统失效。
defect density缺陷密度：产品中缺陷数除以产品的规模（以该产品标准度量尺度表示）defect prevention缺陷预防：识别缺陷或潜在缺陷以及防止它们进入产品的各种活动。
defect root cause缺陷根本诱因：导致缺陷出现的根本原因（比如过程的不完善）。
defined level已定义级：参见成熟度等级/maturity level。
defined software process定义软件过程: 参见项目定义软件过程/project’s defined so ftware process。
dependency item相关项目: 是指一个组或个人提供给第二个组或个人的一个产品、活动、信息等，从而使第二个组能够执行已计划的任务。
developmental configuration management开发性配置管理：应用技术和行政指令来指定和控制软件和相关技术文档，这些文档定义了开发过程中软件工作产品的配置内容状态。
开发性配置管理是由开发人员直接控制的。
开发性配置管理下的各项不是基线，但在开发过程的某些时间点上，它们可以基线化并放在基线配置管理下。
deviation偏差：与适当的惯例、计划、标准、程序的明显的偏离。
Diagnosing phase诊断阶段：参见IDEAL方法/IDEAL approach。
documented procedure文档化的规程：参见规程/procedure。
E A-D E-L M-R S-Zeffective process有效的过程：有效的过程应具备以下特点：已执行的、成文的、必须遵循的、对使用者进行培训的、被度量的、能够改进的。
end user最终用户：是指系统在其运行环境中部署后，为了预期的目的而使用系统的组或个人。
end user representatives最终用户代表：选定的最终用户的一部分,它们代表所有最终用户。
engineering group工程组：代表一个工程规范的一组人（包括管理人员和技术人员）。
工程规范的例子有：系统工程、硬件工程、系统测试、软件工程、软件配置管理以及软件质量保证。
established phase建立阶段：参见IDEAL方法。
evaluation评价：参见软件能力评价/software capability evaluation。
event-driven review/activity事件驱动审查/活动：因项目内发生了某事而进行的一次审查或其它活动（如，正式审查或生命周期某阶段的完成）。
（比照定期审查/活动periodic review/activity）Ffindings发现结果：一次评估(assessment)、评价(evaluation))、审查(audit)或检查(review)在调查范围内所发现的最重要的事情、问题或机遇。
first-line software manager一线软件经理：对由软件工程师和其他相关人员组成的组织单元（如一个部门或项目组）的人员配置和活动负有直接管理活责任（包括技术指导、管理人员和薪资）的经理。
formal review正式评审：把一个产品展示给最终用户、客户或其他相关方，以获取他们的认可和听取他们的意见。
