CMMI中英文术语对照表.doc

CMMI中英文术语对照表1 标准名词术语1 AT Assessment Team 评审小组2 ATM Assessment Team Member 评审小组成员3 BA Baseline Assessment 基线评审4 CAR Causal Analysis and Resolution 原因分析与决策5 CBA CMM-Based Appraisal 基于CMM的评价6 CBA-IPI CMM-Based Appraisal for Internal Process Improvement 为内部过程改进而进 行的基于CMM的评价（通常 称为CMM评审）7 CC Configuration Controller 配置管理员8 CF Common Feature 公共特性9 CFPS Certified Function Point Specialist 注册功能点专家10 CI Configuration Item 配置项11 CM Configuration Management 配置管理12 CMM Capability Maturity Model 能力成熟度模型13 CMMI Capability Maturity Model Integration 能力成熟度集成模型14 COTS Commerce off the shelf 商业现货供应15 DAR Decision Analysis and Resolution 决策分析与制定16 DBD Database Design 数据库设计17 DD Detailed Design 详细设计18 DP Data Provider 数据提供者19 DR Derived Requirement 派生需求20 EPG Engineering Process Group 工程过程小组21 FP Function Point 功能点22 FPA Function Point Analysis 功能点分析23 FR Functional Requirement 功能性需求24 GA Gap Analysis 差距分析25 ID Interface Design 接口设计26 IFPUG International Function Point Users Group 国际功能点用户组织27 IPM Integrated Project Management 集成项目管理28 IR Interface Requirement 接口需求29 KPA Key Process Area 关键过程域30 KR Key Requirements 关键需求31 LA Lead Assessor 主任评审员32 MA Measurement and Analysis 测量与分析33 MAT Metrics Advisory Team 度量咨询组34 MCA Metrics Coordinator and Analyst 度量专员35 ML matreraty library 度量数据库36 NFR Non-functional Requirement 非功能性需求37 OC Operational Concept 操作概念38 OID Organizational Innovation and Deployment 组织革新与部署39 OPD Organizational Process definition 组织过程定义40 OPF Organizational Process focus 组织过程焦点41 OPL Organizational Process Assets 组织过程财富42 OPP Organaizational Process Perormance 组织过程性能43 OSSP Organizations Set of Standard Process 组织标准过程集合44 OT Organizational Training 组织级培训45 PA Process Areas 过程域46 PAT Process Action Team 过程行动小组47 PB Process Assets Library 过程财富库48 PD Preliminary Design 概要设计49 PDSP Project Defined Standard Processes 项目定义标准过程50 PI Produce Integration 产品集成51 PLC Product Life Cycle 产品生命周期52 PMC Project Monitoring and Control 项目监控53 PP Project Planning 项目策划54 PPQA Process and Product Quality Assurance 过程与产品质量保证55 PPR Price Performance Ratio 性能价格比56 QA Software Quality Assurance 软件质量保证57 QA Quality Assurance 质量保证58 QAP Software Quality Assurance Plan 质量保证计划59 QPM Quantitative Project Management 量化项目管理60 RD Requirements Development 需求开发61 RM/ReqM Requirements Management 需求管理62 RSKM Risk Management 风险管理63 RTM Requirement Traceability Matrix 需求跟踪矩阵64 SAM Supplier Agreement Management. 供应协议管理65 SC Steering Committee 指导委员会66 SCAMPI Standard CMMI Assessment Method for Process Improvement 过程改进CMMI标准评审方法67 SCCB Software Configuration Control Board 软件配置管理控制委员会68 SCM Software Configuration Management 软件配置管理69 SDP Software Development Plan 软件开发计划70 SEI Software Engineering Institute (美国)软件工程学院71 SEPG Software Engineering Process Group 软件工程过程组72 SPI Software Process Improvement 软件过程改进73 SPP Software Project Planning 软件项目策划74 SPTO Software Project Tracking and Oversight 软件项目跟踪与监控75 SR System Requirements 系统需求76 SRS Software Requirement Specification 软件需求规格77 SSM Software Subcontract Management 软件分包管理78 SSR Software System Requirement 软件系统需求79 TS Technical Solution 技术解决方案80 UC Use Case 用例81 UID User Interface Design 用户界面设计82 VAL Validation 确认83 VER Verification 验证84 WBS Work Breakdown Structure 工作分解结构85 WP Work Products 工作产品86 Pre-assessment 预评审87 Baseline 基线88 Quality Attribute 质量属性89 Scenario 场景2 以字母检索单词Aability to perform执行的能力: （参见 公共特性/common feature）acceptance criteria 接受标准：为让用户、客户或其他授权组织接受，一个系统或组件所必须满足的条件。IEEE-STD-610acceptance testing 接受性测试：用来决定系统是否达到接受标准的正规测试，从而能够使客户决定是否接受系统。IEEE-STD-610acting 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-610Bbaseline 基线：经过正式审查并被一致认可的规格说明或产品，作为进一步开发基础，只有通过正式变更控制程序才能改变。IEEE-STD-610baseline configuration management基线配置管理：建立经过正式评审和认同的基线，并将其作为进一步开发工作的基础。一些软件工作产品，如软件设计和代码应按计划建立基线，并使用严格的变更控制过程进行管理。这些基线使得与客户的交互在稳定及可控的状态下进行。（参见基线管理/baseline management）benchmark基准：进行度量或比较的标准。bidder投标者 ：个人、合作伙伴、公司或联合组织提交了意向书，就成为了获取设计、开发、及/或制造一个或多个产品合同的候选者。Ccapability maturity model能力成熟度模型：软件组织通过定义、执行、度量、控制、改进软件过程而不断提高，能力成熟度模型就是提高过程不同阶段的描述。通过帮助确认当前过程能力，帮助确定那些对于软件质量和过程改进最迫切的问题，这个模型对于如何选择过程改进战略提供了指导。causal analysis诱因分析：分析缺陷来确定导致缺陷的根本原因。causal analysis meeting诱因分析会：完成一项具体任务后所进行的会议，用来分析在完成任务期间发现的缺陷。commitment 承诺：根据需要建立的、可见的且相关各方应遵守的协定。 commitment to perform 执行的承诺：参见 公共特性/common features common 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-610configuration control配置控制：配置管理的一个要素，包括评审、协调、批准或不批准以及正式建立配置标识后对配置项的更改。IEEE-STD-610configuration identification配置标识：配置管理的一个要素，包括为一个系统选择配置项并在技术文档中记录它们的功能和物理特性。IEEE-STD-610configuration item配置项：为配置管理指定的软件、硬件或包括两者的一个集合，在配置管理过程中作为一个独立实体。configuration management配置管理：是使用技术及行政指导和监督的一个规范，用以确定和记录一个配置项的功能和物理特性，控制对这些特性的修改，记录并报告变更处理及执行的状态，并验证其与特定要求的符合性。IEEE-STD-610configuration management library system配置管理库系统：访问软件基线库内容的工具和规程。configuration unit配置单元：配置项或组件的最底层实体，可以放入配置管理库系统，也可以从中提取。consistency一致性：统一、标准化以及不与系统或组件中其它部分相矛盾的程度。IEEE-STD-610contingency 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定义软件过程: 参见 项目定义软件过程/projects defined software process。dependency item相关项目: 是指一个组或个人提供给第二个组或个人的一个产品、活动、信息等，从而使第二个组能够执行已计划的任务。developmental configuration management开发性配置管理：应用技术和行政指令来指定和控制软件和相关技术文档，这些文档定义了开发过程中软件工作产品的配置内容状态。开发性配置管理是由开发人员直接控制的。开发性配置管理下的各项不是基线，但在开发过程的某些时间点上，它们可以基线化并放在基线配置管理下。deviation偏差：与适当的惯例、计划、标准、程序的明显的偏离。Diagnosing phase诊断阶段：参见 IDEAL方法/IDEAL approach。documented procedure文档化的规程：参见规程/procedure。Eeffective 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正式评审：把一个产品展示给最终用户、客户或其他相关方，以获取他们的认可和听取他们的意见。正式评审也可能是一次对项目过程中管理和技术活动的一次评审。function功能：为达到一组目的或结果，由个人或工具所进行的一组相关的行动，这些行动是特定分配给他们的或是出于职责。Ggoals目标：一个关键过程域中所有关键实践的总结，用来确定是否一个组织或项目已经有效地实施了这个关键过程域。目标表明了每个关键过程域的范围、边界和意图。group组：为一组任务或活动负责的部门、经理和个人的集合。组可以由许多组成方式，可以是一个兼职的个人，也可以是来自不同部门的几个兼职人员，或者一些全职的人员。Hhost computer宿主机（开发机）：用来开发软件的计算机。（比照 目标机/target computer）IIDEAL approachIDEAL 方法：SEI描述软件过程改进周期的方法，基于以下几个方面：启动过程改进、分析软件过程、建立改进过程的机制、采取行动执行改进、总结并在组织范围内进一步提高。IDEAL 方法的5个阶段为： 启动阶段：这是第一个阶段，在这个阶段组织支持和软件过程改进基础设施得以定义并开始建立。 诊断阶段：第二个阶段，这个阶段通过评估建立了组织的软件过程成熟度基线，同时组织得到一套改进的建议。 建立阶段：第三个阶段，软件过程改进基础设施得以建立，包括过程行动组的建立、软件过程改进战略和策略计划的定义。 行动阶段：第四个阶段，改进得以具体实施。 总结提高阶段：最后一个阶段，对软件过程改进教训进行分析，然后对软件过程改进过程做相应修改。重新确定支持并为下个改进周期设立新的目标。infrastructure基础设施：支撑一个组织或系统的框架结构，包括支持其运行的组织结构、政策、标准、培训、设施及工具。initial level初始级：（参见成熟度等级/maturity level）initiating phase启动阶段：（参见 IDEAL 方法/IDEAL approach）institutionalization制度化：建立支持方法、做法及规程的基础设施和文化，从而使这些方法、做法和规程成为日常工作的方式,即使那些定义它们的人员离开也不受影响。integrated software management集成软件管理：基于组织标准软件过程和相关过程资产，统一并集成软案工程和管理活动，使其成为一个紧凑一致的定义软件过程。integration集成：（参见软件集成/software integration）Kkey practices关键实践：对关键过程域进行有效实施和制度化起关键作用的基础设施和活动。key process area关键过程域：一组相关的活动，当这些活动都被执行时，将实现一组被认为对建立过程能力重要的一组目标。关键过程域被定义在某一成熟度等级。它们是SEI定义的对于帮助确定一个组织的软件过程能力的关键组成要素，它们还将帮助理解达到更高成熟度等级所需的改进工作。第二等级的关键过程域有需求管理、软件项目计划、软件项目跟踪与监督、软件分包合同管理、软件质量保证和软件配置管理。第三等级的关键过程域包括组织过程中心、组织过程定义、培训方案、集成软件管理、软件产品工程、组间协调和统计互查。第四等级的关键过程域包括定量过程管理和软件质量管理。第五等级的关键过程域包括缺陷预防、技术变更管理和过程变更管理。Lleveraging phase总结提高阶段：（参见 IDEAL 方法/ IDEAL approach） life cycle生存周期：（参见软件生存周期/software life cycle）Mmaintenance维护：软件系统交付后修改系统或部件以改正缺陷、改善性能或其它属性、或适应新的环境的过程。IEEE-STD-610managed and controlled管理和控制：有些软件工作产品不是基线的一部分，因此没有纳入配置管理，但为使项目以规范的方式进行必须对其进行控制，“管理和控制”就是确认和定义这些工作产品的过程。它要求在一个给定时间（过去和现在）的某个正在使用的工作产品的版本是可知的（即版本控制），工作产品的修改以受控的方式进行（即变更控制）。managed level已管理级：（参见成熟度等级/maturity level）manager经理：为在经理责任范围内工作的人员提供技术和行政指导和控制的角色。经理的一些传统职责有在责任范围内的计划、资源调配、组织、指导和控制工作。maturity level成熟度等级：妥善定义的为实现成熟的软件过程渐进的平台。SEI的能力成熟度模型的5个等级是： 初始级 软件过程是反应型的，有时甚至是混乱的。很少有定义的过程，成功依赖于个人的努力。 可重复级 基本的项目管理过程得以建立，来跟踪费用、进度和功能性。有必要的过程规范，以重复以前的类似应用领域项目的成功。 已定义级 管理和技术的软件过程得以记录于文档、标准化并集成为组织的标准软件过程。所有的项目使用批准的和裁剪的组织标准软件过程版本来开发和维护软件。 已管理级 软件过程和产品质量的详细度量数据得以收集。软件过程和产品都得到量化的理解和控制。 持续优化级 在过程和试用的新观点和新技术的量化反馈基础上进行持续的过程改进。maturity questionnaire成熟度问卷：（参见软件过程成熟度问卷/software process maturity questionnaire）measure度量单位：度量的单位（如源代码行数或设计文档的页数）。measurement 度量：某物的维数、容量、质量、数量等。（如300行源代码，设计说明书有7页等。）method方法：建立取得期望结果或完成一项任务的准确且可重复方式的一套完整的规则和准则。methodology方法论：是方法、规程和标准的集合，定义了开发一个产品所需工程方法的集成和综合。milestone里程碑：按进度安排好的一个有人为之负责并用来度量进度的事件。Nnontechnical requirement非技术性需求：影响和决定软件项目管理活动的协议、条件及/或合同条款。Ooperational software操作软件：一个系统交付用户并在指定环境中部署之后，在系统中使用和操作的软件。optimizing level 持续优化级：（参见成熟度模型/maturity level）organization组织：公司中的一个单元，或把许多项目作为一个整体来管理的其它实体。一个组织内的所有项目具有共同的高层经理和共同的政策。organizations measurement program组织度量方案：处理组织度量需求相关元素的集合，包括定义组织范围的度量、收集组织度量数据的方法和做法、分析组织度量数据的方法和做法、组织的度量目标。organizations software process assets组织软件过程资产：是一个实体的收集，由组织维护，项目在开发、裁剪、维护和执行它们的软件过程时使用。典型的软件过程资产包括： 组织标准软件过程 批准使用的软件生存周期描述 裁剪组织标准软件过程的指导和准则 组织软件过程数据库 软件过程相关文档库组织认为对执行过程定义和维护活动任何有用的实体都可以包含在过程资产中。organizations software process database组织软件过程数据库：收集并提供软件过程数据和软件工作产品数据的数据库，尤其针对那些与组织标准软件过程有关的数据。数据库包含或指针指向实际度量数据和为理解度量数据所需的相关信息，并对其合理性和可应用性进行评估。过程和工作产品数据的例子有，软件规模、工作量、费用的估算，软件规模、工作量、费用的实际数据；生产率数据；同级互查覆盖率和效率；软件代码中发现缺陷的数量和严重程度。organizations standard software process组织标准软件过程：指导在组织内的所有项目中建立公共软件过程的具有可操作性定义的基本过程。它描述了每个软件项目合成到项目定义软件过程的基本过程元素。它也描述了这些软件过程元素间的关系（如，顺序和接口）。orientation定向培训：对那些监督和联系负责执行一项议题的人员的人所作的关于这项议题的概论介绍。（对照培训/train）PPareto analysisPareto 分析：按缺陷的严重程度排序来分析缺陷。Pareto 分析是基于以19世纪经济学家Vilfredo Pareto命名的一个原理，即大多数的影响来自于相对很少的原因，80%的后果是由20%的可能原因造成的。peer review同级互查：为发现缺陷及进行改进而由作者的同事按照定义的规程对软件工作产品进行检查。peer review leader同级互查领导者：接受过指定培训并有资格计划、组织和领导同级互查的个人。periodic review/activity定期审查/活动：按指定的有规律的时间间隔进行的一项审查或活动。（参照 事件驱动审查/活动 / event-driven review/activity）policy政策：指导性原则，一般由高层管理者建立，组织或项目将根据这个原则考虑和作出决定。prime contractor主承包商：管理分承包商来设计、开发和/或制造一个或多个产品的个人、合作伙伴、公司或协会组织。procedure规程：为完成一项既定任务而进行的一系列活动的书面描述。IEEE-STD-610process过程：为某一目的而进行的一系列步骤，例如，软件开发过程。相对于规程(procedure)，过程更强调做什么而不是怎么做。IEEE-STD-610process capability过程能力：遵循某一过程而能够取得的预期结果的范围。（参照过程绩效/process performance）process capability baseline过程能力基线：在特定环境中，执行某一具体过程通常得到的预期结果范围的书面描述。过程能力基线一般在组织一级建立。（参照过程绩效基线/process performance baseline）process database过程数据库：（参见组织软件过程数据库/ organizations software process database）process description过程描述：一个过程主要部件的操作性定义，是对一个过程需求、设计、行为或其它特征的完全、准确及可验证的文档描述。通常还包括确定这些项是否满足的规程。过程描述可能出现在任务、项目或组织级。process development过程开发：定义和描述过程的活动。通常包括计划、架构、设计、执行和验证。process measurement过程度量：用来进行过程度量的一套定义、方法及活动，以及为了理解及弄清过程特征而进行的度量的结果。process performance过程绩效：对遵循某一过程而取得的实际结果的度量值。（参照过程能力/process capability）process performance baseline过程绩效基线：对遵循一个过程而会取得的实际结果的书面描述，在比照实际过程绩效与期望过程绩效时用作基准。过程绩效基线通常在项目级建立，初始过程绩效基线通常来自于过程能力基线。（参照过程能力基线/process capability baseline）process tailoring过程裁剪：通过详细描述、改编、完善过程要素细节或其他不完整过程描述，从而建立一个过程描述的活动。通过过程裁剪，一个项目的具体商业需求通常得以确定。profile 对照图：计划或预期同实际情况的比照，通常会采用图形的形式，典型的例子就是针对时间的比照。project项目：需要共同努力来于开发和/或维护某个特定产品的一项事业。产品可能是硬件、软件及其它部件。项目一般有其自己的资金、成本核算以及交付的日程。projects defined software process项目定义软件过程：是项目使用的具有可操作定义的软件过程。项目定义软件过程容易理解并充分体现项目特征，通过软件标准、规程、工具和方法来描述。项目定义软件过程是通过裁剪组织标准软件过程得到的，以使其符合项目的具体特征。（参见组织标准软件过程/organizations standard software process，有效过程/effective process，妥善定过程/well-defined process）project manager项目经理：对整个项目负有完全责任的角色，是指导、控制、管理、调节建造软件或软硬件系统的个人。项目经理是最终对客户负责的人。project software manager项目软件经理：对项目所有软件活动负全责的角色，项目软件经理控制项目的所有软件资源。项目经理将与项目软件经理确定软件承诺。Qquality质量：（1）一个系统、部件或过程满足指定的需求的程度。（2）一个系统、部件或过程满足客户或用户需要或期望的程度。IEEE-STD-610quality assurance质量保证：（参见软件质量保证/software quality assurance）quantitative control量化控制：分析一个软件过程、识别造成软件过程绩效偏差的特殊诱因、使软件过程绩效回到定义范围的基于量化或统计的技术。Rrepeatable level可重复级：（参见 成熟度模型/maturity level）required training要求的培训：由组织规定的为履行某角色所要求的培训。risk风险：可能造成损失的事物。risk management风险管理：是一种问题分析的方法，通过利用风险概率来权衡风险以得到对所有可能风险的准确理解。风险管理包括风险识别、分析、确定优先级和控制。risk management plan风险管理计划：描述项目中要执行的风险管理活动的各种计划的总称。role角色：已定义的责任的一个集合单位，可以由一个或多个人承担。SA-D E-L M-R S-Zsenior management 高层管理者: 组织中足够高层次的管理角色，主要关注组织的长期活力，而不是短期的项目或合同方面所涉及的问题、压力等。一般来说，工程的高层管理者将对多个项目负责。software architecture软件架构（软件体系结构）：软件或模块的组织结构。IEEE-STD-610software baseline audit软件基线审核：对软件基线库中的结构、内容和设施进行检查，以验证是否这些基线与描述基线的文档一致。software baseline library软件基线库：存储的配置项和相关记录的内容。software build构建软件：软件系统或部件的一个可运行版本，包括了最终提供的软件系统或部件能力的一个特定子集。IEEE-STD-610software capability evaluation软件能力评价：由接受过培训的专业团队进行的评审，来确定那些合格的软件承包商，或对正在进行的软件工作过程进行监控。software configuration control board软件配置控制委员会：负责评价和批准/否决对配置项修改提议，确保批准的修改得以执行的组。software development plan软件开发计划：描述软件项目活动的一组计划，它支配着软件工程组项目活动的管理。这里的定义不受限于任何其他特定计划标准所描述的范围，如DOD-STD-2167A 和 IEEE-STD-1058，它们可能使用相同叫法。software engineering group软件工程组：负责某一项目软件开发和维护活动（即需求分析、设计、编码和测试）的一组人（包括经理和技术人员）。执行软件相关活动的组（如软件质量保证组、软件配置管理组和软件工程过程组）不包括在内。software engineering process group软件工程过程组：促进组织使用的软件过程定义、维护和改进工作的一组专家。在关键实践中，这个组通常被描述为“负责组织软件过程活动的组”。software engineering staff软件工程人员：指软件技术人员（如分析员、程序员和工程师），包括执行软件开发和维护的软件任务的领导者，但他们不是经理。software integration软件集成：把选取的软件部件集成的过程，以提供最终交付的软件系统能力的全部或特定子集。software life cycle软件生命周期：一个软件产品从开始构思到不再可用的持续时间。典型的软件生命周期包括概念阶段、需求阶段、设计阶段、执行阶段、测试阶段、安装、校验、操作和维护阶段，有时还会有退出阶段。IEEE-STD-610software manager软件经理：对软件开发和/或维护有直接责任的项目中的或组织层的任何经理。software plans软件计划：正式或非正式的一组计划，用来描述软件开发和/或维护活动如何开展。计划的一些例子有：软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划、过程改进计划。software process软件过程：人们用来开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手册）的活动、方法、做法和变革的集合。software process assessment软件过程评估：由接受过培训的一组软件专业人员所进行的评估，用以确定一个组织的当前软件过程状态，确定组织面临的软件过程相关问题的优先级，并获得对于进行软件过程改进的组织一级的支持。software process assets软件过程资产：（参见组织软件过程资产/organizations software process assets）software process capability软件过程能力：（参见过程能力/process capability）software process description软件过程描述：项目定义软件过程（projects defined software process ）或组织标准软件过程（organizations standard software process）中一个主要软件过程部件的可操作的描述。它以完全的、准确的、可验证的方式记录了一个软件过程的需求、设计、行为或其它特性。（参见过程描述/process description）software process element软件过程元素：一个软件过程描述的构成元素。每一个过程元素涵盖了一套妥善定义的、有边界的、紧密联系的任务（如，软件估算元素、软件设计元素、编码元素、同级互查元素）。过程元素的描述可以是待填充内容的模板、需完善的片段、进一步细化的抽象元素或者是可以直接或修改后使用的完整描述。software process improvement plan软件过程改进计划：根据软件过程评审的建议制定的一个计划，计划中确定了将采取的改进软件过程的具体做法，还描述了执行这些做法的计划。有时也叫做行动计划。software process improvement proposal软件过程改进提议：改变过程或过程相关条目的书面建议，以改进软件过程能力和过程绩效。（参见行动提议/action proposal）software process maturity软件过程成熟度：一特定过程明确定义、管理、度量、控制和有效的程度。成熟度意味着能力成长的潜力，表明组织软件过程的丰富性和在组织内各项目中应用的一致性。software process maturity questionnaire软件过程成熟度问卷：关于软件过程的一套问题，它们是CMM每个关键过程域中关键实践的例子。成熟度问卷被用作评估一个组织或项目可靠地执行一个软件过程的能力的出发点。software process performance软件过程绩效：（参见过程绩效/process performance）software process-related documentation软件过程相关文档：是一些文档和文档片段的例子，当未来项目裁剪组织标准软件过程时，这些例子会有用。软件过程相关文档的一些例子有，项目定义软件过程、标准、规程、软件开发计划、度量计划以及过程培训材料。software product软件产品：一整套或一套中的个别项的交付给客户或最终用户的计算机程序、规程以及相关文档和数据。IEEE-STD-610 (参见 软件工作产品/software work product )software project软件项目：是需要共同努力的一项事业。致力于分析、说明、设计、开发、测试和/或维护一个系统的软件部件以及相关文档。一个软件项目可以是建造一个硬件/软件系统的一部分。software quality assurance软件质量保证：（1）为一个软件工作产品与已建立技术需求一致提供足够的信心，而对所有必要活动所建立的一个系统的、有计划的模式。（2）为软件工作产品的开发和/或维护过程的评估所设计的一整套活动。software quality goal软件质量目标：为一个软件工作产品定义的量化的质量目标。software quality management软件质量管理：为软件产品定义质量目标、建立实现这些目标的计划、监控并调整软件计划、软件工作产品、活动以及质量目标，以满足客户和最终用户的需要与愿望。software-related group软件相关组：代表一个软件工程规范的一组人（包括管理者和技术人员），他们支持但不直接对进行软件开发和维护负责。软件工程规范的例子有软件质量保证、软件配置管理。software requirement软件需求：为解决软件用户一个问题或达到一个目标，软件必须满足的条件或达到的能力。 IEEE-STD-610software work product软件工作产品：定义、维护或应用一个软件过程的工作结果。通常包括过程描述、计划、步骤、计算机程序以及相关文档，这些物件有些是要提交给客户或最终用户的，有些不需要。（参照软件产品/software product）special cause(of a defect)（缺陷的）特