E effective process 有效的过程：有效的过程应具备以下特点：已执行的、成文的、必须遵循的、对使用者进行培训的、被度量的、能够改进的。 end user 最终用户：是指系统在其运行环境中部署后， 为了预期的目的而使用系统的组或个人。 end user representatives 最终用户代表：选定的最终用户的一部分,它们代表所有最终用户。 engineering group 工程组：代表一个工程规范的一组人（包括管理人员和技术人员）。工程规范的例子有：系统工程、硬件工程、系统测试、软件工程、软件配置管理以及软件质量保证。 established phase 建立阶段：参见 IDEAL方法。 evaluation 评价：参见软件能力评价/software capability evaluation。 event-driven review/activity 事件驱动审查/活动：因项目内发生了某事而进行的一次审查或其它活动（如，正式审查或生命周期某阶段的完成）。（比照定期审查/活动 periodic review/activity） F findings 发现结果：一次评估(assessment)、评价(evaluation))、审查(audit)或检查(review)在调查范围内所发现的最重要的事情、问题或机遇。 first-line software manager 一线软件经理：对由软件工程师和其他相关人员组成的组织单元（如一个部门或项目组）的人员配置和活动负有直接管理活责任（包括技术指导、管理人员和薪资）的经理。 formal review 正式评审：把一个产品展示给最终用户、客户或其他相关方，以获取他们的认可和听取他们的意见。正式评审也可能是一次对项目过程中管理和技术活动的一次评审。 function 功能：为达到一组目的或结果，由个人或工具所进行的一组相关的行动，这些行动是特定分配给他们的或是出于职责。 G goals 目标：一个关键过程域中所有关键实践的总结，用来确定是否一个组织或项目已经有效地实施了这个关键过程域。目标表明了每个关键过程域的范围、边界和意图。 group 组：为一组任务或活动负责的部门、经理和个人的集合。组可以由许多组成方式，可以是一个兼职的个人，也可以是来自不同部门的几个兼职人员，或者一些全职的人员。 H host computer 宿主机（开发机）：用来开发软件的计算机。（比照 目标机/target computer） I IDEAL approach IDEAL 方法：SEI描述软件过程改进周期的方法，基于以下几个方面：启动过程改进、分析软件过程、建立改进过程的机制、采取行动执行改进、总结并在组织范围内进一步提高。IDEAL 方法的5个阶段为： · 启动阶段：这是第一个阶段，在这个阶段组织支持和软件过程改进基础设施得以定义并开始建立。 · 诊断阶段：第二个阶段，这个阶段通过评估建立了组织的软件过程成熟度基线，同时组织得到一套改进的建议。 · 建立阶段：第三个阶段，软件过程改进基础设施得以建立，包括过程行动组的建立、软件过程改进战略和策略计划的定义。 · 行动阶段：第四个阶段，改进得以具体实施。 · 总结提高阶段：最后一个阶段，对软件过程改进教训进行分析，然后对软件过程改进过程做相应修改。重新确定支持并为下个改进周期设立新的目标。 infrastructure 基础设施：支撑一个组织或系统的框架结构，包括支持其运行的组织结构、政策、标准、培训、设施及工具。 initial level 初始级：（参见成熟度等级/maturity level） initiating phase 启动阶段：（参见 IDEAL 方法/IDEAL approach） institutionalization 制度化：建立支持方法、做法及规程的基础设施和文化，从而使这些方法、做法和规程成为日常工作的方式,即使那些定义它们的人员离开也不受影响。 integrated software management 集成软件管理：基于组织标准软件过程和相关过程资产，统一并集成软案工程和管理活动，使其成为一个紧凑一致的定义软件过程。 integration 集成：（参见软件集成/software integration） K key practices 关键实践：对关键过程域进行有效实施和制度化起关键作用的基础设施和活动。 key process area 关键过程域：一组相关的活动，当这些活动都被执行时，将实现一组被认为对建立过程能力重要的一组目标。关键过程域被定义在某一成熟度等级。它们是SEI定义的对于帮助确定一个组织的软件过程能力的关键组成要素，它们还将帮助理解达到更高成熟度等级所需的改进工作。第二等级的关键过程域有需求管理、软件项目计划、软件项目跟踪与监督、软件分包合同管理、软件质量保证和软件配置管理。第三等级的关键过程域包括组织过程中心、组织过程定义、培训方案、集成软件管理、软件产品工程、组间协调和统计互查。第四等级的关键过程域包括定量过程管理和软件质量管理。第五等级的关键过程域包括缺陷预防、技术变更管理和过程变更管理。 L leveraging phase 总结提高阶段：（参见 IDEAL 方法/ IDEAL approach） life cycle 生存周期：（参见软件生存周期/software life cycle） M maintenance 维护：软件系统交付后修改系统或部件以改正缺陷、改善性能或其它属性、或适应新的环境的过程。[IEEE-STD-610] managed and controlled 管理和控制：有些软件工作产品不是基线的一部分，因此没有纳入配置管理，但为使项目以规范的方式进行必须对其进行控制，“管理和控制”就是确认和定义这些工作产品的过程。它要求在一个给定时间（过去和现在）的某个正在使用的工作产品的版本是可知的（即版本控制），工作产品的修改以受控的方式进行（即变更控制）。 managed level 已管理级：（参见成熟度等级/maturity level） manager 经理：为在经理责任范围内工作的人员提供技术和行政指导和控制的角色。经理的一些传统职责有在责任范围内的计划、资源调配、组织、指导和控制工作。 maturity level 成熟度等级：妥善定义的为实现成熟的软件过程渐进的平台。SEI的能力成熟度模型的5个等级是： · 初始级 软件过程是反应型的，有时甚至是混乱的。很少有定义的过程，成功依赖于个人的努力。 · 可重复级 基本的项目管理过程得以建立，来跟踪费用、进度和功能性。有必要的过程规范，以重复以前的类似应用领域项目的成功。 · 已定义级 管理和技术的软件过程得以记录于文档、标准化并集成为组织的标准软件过程。所有的项目使用批准的和裁剪的组织标准软件过程版本来开发和维护软件。 · 已管理级 软件过程和产品质量的详细度量数据得以收集。软件过程和产品都得到量化的理解和控制。 · 持续优化级 在过程和试用的新观点和新技术的量化反馈基础上进行持续的过程改进。 maturity questionnaire 成熟度问卷：（参见软件过程成熟度问卷/software process maturity questionnaire） measure 度量单位：度量的单位（如源代码行数或设计文档的页数）。 measurement 度量：某物的维数、容量、质量、数量等。（如300行源代码，设计说明书有7页等。） method 方法：建立取得期望结果或完成一项任务的准确且可重复方式的一套完整的规则和准则。 methodology 方法论：是方法、规程和标准的集合，定义了开发一个产品所需工程方法的集成和综合。 milestone 里程碑：按进度安排好的一个有人为之负责并用来度量进度的事件。 N nontechnical requirement 非技术性需求：影响和决定软件项目管理活动的协议、条件及/或合同条款。 O operational software 操作软件：一个系统交付用户并在指定环境中部署之后，在系统中使用和操作的软件。 optimizing level 持续优化级：（参见成熟度模型/maturity level） organization 组织：公司中的一个单元，或把许多项目作为一个整体来管理的其它实体。一个组织内的所有项目具有共同的高层经理和共同的政策。 organization’s measurement program 组织度量方案：处理组织度量需求相关元素的集合，包括定义组织范围的度量、收集组织度量数据的方法和做法、分析组织度量数据的方法和做法、组织的度量目标。 organization’s software process assets 组织软件过程资产：是一个实体的收集，由组织维护，项目在开发、裁剪、维护和执行它们的软件过程时使用。典型的软件过程资产包括： · 组织标准软件过程 · 批准使用的软件生存周期描述 · 裁剪组织标准软件过程的指导和准则 · 组织软件过程数据库 · 软件过程相关文档库 组织认为对执行过程定义和维护活动任何有用的实体都可以包含在过程资产中。 organization’s software process database 组织软件过程数据库：收集并提供软件过程数据和软件工作产品数据的数据库，尤其针对那些与组织标准软件过程有关的数据。数据库包含或指针指向实际度量数据和为理解度量数据所需的相关信息，并对其合理性和可应用性进行评估。过程和工作产品数据的例子有，软件规模、工作量、费用的估算，软件规模、工作量、费用的实际数据；生产率数据；同级互查覆盖率和效率；软件代码中发现缺陷的数量和严重程度。 organization’s standard software process 组织标准软件过程：指导在组织内的所有项目中建立公共软件过程的具有可操作性定义的基本过程。它描述了每个软件项目合成到项目定义软件过程的基本过程元素。它也描述了这些软件过程元素间的关系（如，顺序和接口）。 orientation 定向培训：对那些监督和联系负责执行一项议题的人员的人所作的关于这项议题的概论介绍。（对照培训/train） P Pareto analysis Pareto 分析：按缺陷的严重程度排序来分析缺陷。Pareto 分析是基于以19世纪经济学家Vilfredo Pareto命名的一个原理，即大多数的影响来自于相对很少的原因，80%的后果是由20%的可能原因造成的。 peer review 同级互查：为发现缺陷及进行改进而由作者的同事按照定义的规程对软件工作产品进行检查。 peer review leader 同级互查领导者：接受过指定培训并有资格计划、组织和领导同级互查的个人。 periodic review/activity 定期审查/活动：按指定的有规律的时间间隔进行的一项审查或活动。（参照 事件驱动审查/活动 / event-driven review/activity ） policy政策：指导性原则，一般由高层管理者建立，组织或项目将根据这个原则考虑和作出决定。 prime contractor 主承包商：管理分承包商来设计、开发和/或制造一个或多个产品的个人、合作伙伴、公司或协会组织。 procedure 规程：为完成一项既定任务而进行的一系列活动的书面描述。[IEEE-STD-610] process 过程：为某一目的而进行的一系列步骤，例如，软件开发过程。相对于规程(procedure)，过程更强调做什么而不是怎么做。[IEEE-STD-610] process capability 过程能力：遵循某一过程而能够取得的预期结果的范围。（参照过程绩效/process performance） process capability baseline 过程能力基线：在特定环境中，执行某一具体过程通常得到的预期结果范围的书面描述。过程能力基线一般在组织一级建立。（参照过程绩效基线/process performance baseline） process database 过程数据库：（参见组织软件过程数据库/ organization’s software process database） process description 过程描述：一个过程主要部件的操作性定义，是对一个过程需求、设计、行为或其它特征的完全、准确及可验证的文档描述。通常还包括确定这些项是否满足的规程。过程描述可能出现在任务、项目或组织级。 process development 过程开发：定义和描述过程的活动。通常包括计划、架构、设计、执行和验证。 process measurement 过程度量：用来进行过程度量的一套定义、方法及活动，以及为了理解及弄清过程特征而进行的度量的结果。 process performance 过程绩效：对遵循某一过程而取得的实际结果的度量值。（参照过程能力/process capability） process performance baseline 过程绩效基线：对遵循一个过程而会取得的实际结果的书面描述，在比照实际过程绩效与期望过程绩效时用作基准。过程绩效基线通常在项目级建立，初始过程绩效基线通常来自于过程能力基线。（参照过程能力基线/process capability baseline） process tailoring 过程裁剪：通过详细描述、改编、完善过程要素细节或其他不完整过程描述，从而建立一个过程描述的活动。通过过程裁剪，一个项目的具体商业需求通常得以确定。 profile 对照图：计划或预期同实际情况的比照，通常会采用图形的形式，典型的例子就是针对时间的比照。 project 项目：需要共同努力来于开发和/或维护某个特定产品的一项事业。产品可能是硬件、软件及其它部件。项目一般有其自己的资金、成本核算以及交付的日程。 project’s defined software process 项目定义软件过程：是项目使用的具有可操作定义的软件过程。项目定义软件过程容易理解并充分体现项目特征，通过软件标准、规程、工具和方法来描述。项目定义软件过程是通过裁剪组织标准软件过程得到的，以使其符合项目的具体特征。（参见组织标准软件过程/organization’s standard software process，有效过程/effective process，妥善定过程/well-defined process） project manager 项目经理：对整个项目负有完全责任的角色，是指导、控制、管理、调节建造软件或软硬件系统的个人。项目经理是最终对客户负责的人。 project software manager 项目软件经理：对项目所有软件活动负全责的角色，项目软件经理控制项目的所有软件资源。项目经理将与项目软件经理确定软件承诺。 Q quality 质量：（1）一个系统、部件或过程满足指定的需求的程度。（2）一个系统、部件或过程满足客户或用户需要或期望的程度。[IEEE-STD-610] quality assurance 质量保证：（参见软件质量保证/software quality assurance） quantitative control 量化控制：分析一个软件过程、识别造成软件过程绩效偏差的特殊诱因、使软件过程绩效回到定义范围的基于量化或统计的技术。 R repeatable level 可重复级：（参见 成熟度模型/maturity level） required training 要求的培训：由组织规定的为履行某角色所要求的培训。 risk 风险：可能造成损失的事物。 risk management 风险管理：是一种问题分析的方法，通过利用风险概率来权衡风险以得到对所有可能风险的准确理解。风险管理包括风险识别、分析、确定优先级和控制。 risk management plan 风险管理计划：描述项目中要执行的风险管理活动的各种计划的总称。 role 角色：已定义的责任的一个集合单位，可以由一个或多个人承担。 S A-D E-L M-R S-Z senior management 高层管理者: 组织中足够高层次的管理角色，主要关注组织的长期活力，而不是短期的项目或合同方面所涉及的问题、压力等。一般来说，工程的高层管理者将对多个项目负责。 software architecture 软件架构（软件体系结构）：软件或模块的组织结构。[IEEE-STD-610] software baseline audit 软件基线审核：对软件基线库中的结构、内容和设施进行检查，以验证是否这些基线与描述基线的文档一致。 software baseline library 软件基线库：存储的配置项和相关记录的内容。 software build 构建软件：软件系统或部件的一个可运行版本，包括了最终提供的软件系统或部件能力的一个特定子集。[IEEE-STD-610] software 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-610] software manager 软件经理：对软件开发和/或维护有直接责任的项目中的或组织层的任何经理。 software plans 软件计划：正式或非正式的一组计划，用来描述软件开发和/或维护活动如何开展。计划的一些例子有：软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划、过程改进计划。 software process 软件过程：人们用来开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手册）的活动、方法、做法和变革的集合。 software process assessment 软件过程评估：由接受过培训的一组软件专业人员所进行的评估，用以确定一个组织的当前软件过程状态，确定组织面临的软件过程相关问题的优先级，并获得对于进行软件过程改进的组织一级的支持。 software process assets 软件过程资产：（参见组织软件过程资产/organization’s software process assets） software process capability 软件过程能力：（参见过程能力/process capability） software process description 软件过程描述：项目定义软件过程（project’s defined software process ）或组织标准软件过程（organization’s 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-610] software work product 软件工作产品：定义、维护或应用一个软件过程的工作结果。通常包括过程描述、计划、步骤、计算机程序以及相关文档，这些物件有些是要提交给客户或最终用户的，有些不需要。（参照软件产品/software product） special cause(of a defect) （缺陷的）特殊诱因：由于暂时的特殊环境而导致缺陷的诱因，这些诱因并不是过程所固有的。特殊诱因导致过程绩效随机的变化（噪音）。（参照一般诱因/common cause） staff 职员：一些个人，包括任务领导者。这些任务领导者对完成一项分配的功能负责（如，软件开发或软件配置管理），但他们不是经理。 stage 阶段：可管理规模的一部分软件工作，代表了项目所执行相关任务的一个有意义和可度量的集合。一个阶段通常被看作软件生存周期的细分，结束时并在下一阶段正式开始前通常举行一次正式评审。 standard 标准：采用并必须执行的强行标准，以为软件开发规定一个规范统一的方法。 standard software process 标准软件过程：（参照组织标准软件过程/ organization’s standard software process） statement of work 工作综述：由客户提供的为完成项目所需的所有工作的描述。 subcontract manager 转包（分包）合同经理：是主承包商组织中的一个经理，他直接管理一个或多个转包（分包）合同的执行和控制。 subcontractor 分包商：与一个组织（如，主承包商）签订合同的个人、合作伙伴、公司或协会组织，来设计、开发和/或制造一种或多种产品。 system 系统：为完成一个特定的功能或功能集合而组织在一起的一些部件。[IEEE-STD-610] system engineering group 系统工程组：系统工程组是这样一组人（包括管理者和技术人员），他们负责确定系统需求；将系统需求分配给软件、硬件或其他部分；指定硬件、软件和其他部分的接口；监控这些部分的设计与开发已确保与需求规格一致。 system requirement 系统需求：一个系统或系统部件所必须达到的条件或拥有的能力，以满足用户为解决问题所需的条件和能力。 system requirements allocated to software 系统分配至软件的需求：将由系统的软件部件实现的系统需求的子集。分配的需求是软件开发计划的主要输入。软件需求分析详细阐述和精炼分配的需求并产生软件需求文档。 T tailor 裁剪：修改过程、标准或规程以更好地符合过程或产品的需求。 target computer 目标机（运行机）：运行交付的软件的计算机。（比照宿主机/host computer） task 任务：（1）被看作一个基本工作单元的一系列指令。（2）是指软件过程中一个妥善定义的单元，是管理者了解项目状态的一个可见的检查点。任务有进入标准（前提条件）和结束标准（推出条件）。（比照活动/activity） task kick-off meeting 任务动员会：在一项任务或一个工程开始时召开的会议，为了让所有参与这项任务的人做好准备以更有效地完成任务。 task leader 任务领导者：完成某一特定任务的技术小组的领导者，他对技术负责并对小组成员提供技术指导。 team 小组：为组织或项目执行一个妥善定义的功能的一组人，他们通常来自不同但相关的组。小组的成员可能是还有其它主要工作的兼职人员。 testability 可测试性：（1）一个系统或组件便于建立测试标准和便于进行测试以确定是否满足这些标准的程度。（2）一份需求描述得允许建立测试标准和允许测试以确定是否达到这些标准的程度。[IEEE-STD-610] technical requirements 技术需求：描述软件必须做什么和操作限制的需求。如功能、性能、接口以及质量需求。 technology 技术：对科学和/或工程学的应用，以实现某些特定结果。 total quality management 全面质量管理：应用量化的方法和人力资源来改进提供给组织的材料与服务、组织内的所有的过程以及满足客户当前和未来需要的程度。 traceability 可跟踪性：能够在开发过程中的两个或多个产品间建立关系的程度，尤其针对那些有前后继承关系和主从关系的产品。[IEEE-STD-610] train 培训：通过专门的指导和练习而达到熟练的程度。 training group 培训组：对一个组织的培训安排和协调负责的一组人（包括经理和普通员工）。这组人通常准备和进行大多数的培训课程，并协调其他培训设施的使用。 training program 培训方案:用来满足组织培训需求的一套相关元素。包括组织的培训计划、培训材料、培训的开发、培训活动、培训设施、培训的评价以及培训记录的维护。 training vaiver 免培训：书面批准某人免除一特定角色所要求的培训。之所以可以免培训，是因为已客观地确定他已具备担负角色所需的技能。 U unit 单元：（1）在设计一个计算机软件组件时，指定的一个分开独立测试的元素。（2）计算机程序中，逻辑上可分开的部分。（3）不再分拆成其它组件的一个软件组件。[IEEE-STD-610] user 用户：（参见最终用户/end user） V validation 检验：在开发过程中或结束时评价软件,确定是否符合指定的需求。[IEEE-STD-610] verification 验证：评价软件，来确定特定开发阶段的产品是否满足阶段开始时要求的条件。[IEEE-STD-610] verifying implementation 检验实施：参见公共特性/common features W waiver 免培训：参见 免培训/training waiver。 well-defined process 妥善定义的过程：一个妥善定义的过程应具备以下特性：准备标准、输入、进行工作所依据的标准和程序、验证机制（如同级互查）、输出、结束标准。(参见 有效的过程/effective process)
转载于:https://www.cnblogs.com/liyejun/archive/2010/05/17/1737135.html
相关资源：CMMI术语定义表（专业）