·验收准则: | 为使用户、顾客或其他授权的实体接收产品或产品部件所必须满足的准则。 |
·验收测试: | 为使用户、顾客或其他授权的实体决定是否接收产品或产品部件所实施的一种正式测试。 |
·获取: | 通过合同获得产品(物资和服务)的过程。 |
·获取策略: | 基于对供应源、获取方法、需求规格说明类型、合同或协议的类型,以及相关获取风险等的综合考
虑,为获取产品和服务而制定的特定途径。 |
·足够的: | 依据组织的业务目标用这个词来解释目标和实践。使用本标准时,必须解释各种实践,以使其在组
织中可行。当目标和实践中存在某些不是总需执行的活动时,就用该词来描述。 |
·分配需求: | 从高层的全部或部分功能和性能中提取作为较低层的体系结构元素或设计部件的需求。 |
·替代实践: | 一个用来替代本标准中的一个或多个共用实践或专用实践的实践,它与被替代实践具有等同的效
果,能达到与被替代模型实践相关的共用目标或专用目标。替代实践不必一对一地替代共用实践或专用
实践。 |
·评估: | 由一个受过培训的专业团队基于本标准对一个或多个过程所进行的检查,通过检查至少应确定被检
查过程的强项和弱项。 |
·评估发现: | 评估所获的结果,它标识评估范围内发现的最重要的问题、问题和待改进项等,评估发现是从已被
确证的客观证据中导出的结论。 |
·参评者: | 评估期间组织单元中参与提供信息的成员。 |
·评估判定: | 评估判定是由评估组对一个本标准的目标或过程域、一个过程域的能力等级或一个组织单元的成熟
度等级赋予的一个值。评估判定是按评估方法实施所定义的判定过程确定的。 |
·评估范围: | 评估边界的定义,包括关于组织的范围和本标准的范围,其中包含欲考察的过程。 |
·适当的: | 依据组织的业务目标用此词解释目标和实践。使用本标准时,必须解释各种实践,以使其在组织中
可行。当目标和实践中存在某些不是总需执行的活动时,就用这个词来描述。 |
·需要时: | 依据组织的业务目标用此词解释目标和实践。使用本标准时,必须解释各种实践,以使其在组织中
可行。当目标和实践中存在某些不是总需执行的活动时,就用这个词来描述。 |
·内部评估: | 为了过程改进的目的在组织内部进行的一种评估。
过程变异的可指定原因 assignable cause of process variation
在GJB 5 000A中,为了保证一致性,用“过程变异的特殊原因”替代“过程变异的可指定原因”,
两个词定义完全相同。 |
·审核: | 按特定准则(例如,需求),对一个或一组工作产品的一次客观检查。
基本测量项 base measure(参见“导出测量项”)
一个实体的独特属性或特征,以及对其量化的方法。 |
·基线: | 一组经正式评审同意的规格说明或工作产品,此后它们将作为进一步开发的基础,并且只有通过更
改控制过程才能修改它们。 |
·双向可追溯性: | 两个或更多个逻辑实体之间的一种关联关系,这种关系使得一个实体和与其关联的实体之间可以双
向辨别。 |
·能力评价: | 由受过培训的专业团队进行的一种评估,用作选择供方或按合同监督供方过程。 |
·能力成熟度模型: | 包含一个或多个学科的有效过程的各种重要元素的一种模型。它描述一条从随意的、不成熟的过程
向有纪律的、质量和有效性都已改进的成熟过程进化的改进途径。 |
·有能力的过程: | 一个能满足其规定的产品质量、服务质量、以及过程绩效目标的过程。 |
·原因分析: | 为确定缺陷的原因所作的缺陷分析。 |
·更改管: | 明智地使用一些手段实现一个产品或服务的更改或建议书的更改。 |
·军用软件研制能力成熟度模型框架: | 把CMM-MSD的各种部件组织起来的基本结构,包括现行CMM-MSD模型的公共元素、生成这
些模型的规则和方法、评估方法(包括相关的人工制品),以及培训材料等。框架使得CMM-MSD能纳
入新学科,将新学科与已有的学科集成在一起。
CMM-MSD模型 CMM-MSD Model(参见“CMM-MSD框架”和“CMM-MSD产品包”)
能从CMM-MSD框架生成的所有可能模型的集合中的一个模型。因为CMM-MSD框架能够根据
使用它的组织的要求生成不同的模型,因此存在多种CMM-MSD模型。 |
·CMM-MSD部件: | 构成一个CMM-MSD模型的任一主要结构元素。CMM-MSD模型的一些主要元素包括专用实践、
共用实践、专用目标、共用目标、过程域,以及成熟度等级。 |
·CMM--MSD产品包: | 围绕CMM-MSD概念开发的一组完整的产品。这些产品包括框架自身、模型、评估方法、评估材
料以及各类培训等。 |
·过程变异的共因: | 由于过程部件间的正常的和预期的交互作用而存在的过程变异。 |
·配置审核: | 为了验证一个配置项或构成基线的一组配置项是否符合规定的标准或需求所进行的一种审核。 |
·配置基线: | 在产品或产品部件的生存周期中一个特定时刻正式指定的配置信息。配置基线加上来自那些基线的
经批准的更改构成当前的配置信息。 |
·配置控制: | 配置管理的一个元素,它包括:在正式建立配置项的配置标识之后,对配置项的更改所作的评价、
协调、批准或不批准、以及实施。 |
·配置控制委员会: | 负责评价、批准或不批准建议的对配置项的更改,并确保批准的更改得以实施的一组人。配置控制
委员会也称“更改控制委员会”。 |
·配置标识: | 配置管理的一个元素,由下列步骤构成:为产品选择配置项、对它们赋以唯一的标识符、并在技术
文档中记录其功能特性和物理特性。 |
·配置项: | 工作产品的集合,欲对其实施配置管理,并在配置管理过程中当作单个实体处理。 |
·配置管理: | 对下列事项实施技术和管理的指导和监督的一个学科:
a) 标识并建档记录配置项的功能特性和物理特性;
b) 控制对这些特性的更改;
C) 记录并报告更改的处理过程和实现状态;
d) 验证与规定的需求的符合性。 |
·配置状态记实: | 配置管理的一个元素,包括记录并报告有效管理一个配置项所需的信息。这个信息包括一张经批准
的配置项标识列表、建议的配置项更改的状态、以及经批准的更改的实现状态。 |
·现货产品: | 可从商业卖主处买到的项目。 |
·顾客: | 负责验收产品或支付经费的一方(可以是个人、项目或组织)。顾客是在项目之外的,但没有必要是
组织外的。顾客可以是一个更高层的项目。顾客是利益相关方的一个子集。在使用该词的多数场合,前
述定义表示了顾客一词的含义,但在某些关联中,顾客一词的含义还包括其他利益相关方。 |
·顾客需求: | 以顾客能接受的方式,从产品的利益相关方的需要、期望、约束和接口中引出、加强和消除矛盾后
的结果。 |
·数据: | 记录的信息,不论其记录的形式和方法如何,它们包括能交流、存储和处理的各种技术资料、计算
机软件文档、财务信息、管理信息、事实的表示,以及任何天然资料。 |
·数据管理: | 一套有纪律的过程和系统,它们用来在整个数据生存周期中,为管理人员策划、获取并提供与数据
需求一致的业务和技术数据。 |
·缺陷密度: | 每单位规模的产品中的缺陷数目(例如,每1 000行代码中的问题报告数)。 |
·已定义过程: | 一个已管理的过程,它是按照组织的剪裁指南从组织的标准过程集中剪裁出来的,它有一个得到维
护的过程说明,并为组织的过程资产贡献工作产品、测量值和其他过程改进信息。 |
·导出测量项: | 从两个或多个基本测量项的数学函数得出的数据。 |
·导出需求: | 在顾客需求中没有明确陈述的需求,但是,它可从下列需求中推导出来:
a) 关联的需求(例如,适用的标准、法律、方针、公共实践和管理决策);
b) 一个产品部件的需求。
导出需求亦可在产品或系统的部件分析和设计期间提出来。 |
·设计评审: | 对一个设计所做的一种正式的、文档化的、全面且系统的考查。其目的是为了评价设计需求、该设
计满足这些需求的能力、识别出问题并建议解决方案。 |
·开发: | 在本标准中,不仅可以包括开发活动,而且也可包括维护活动。从本标准的最佳实践得到好处的项
目可以关注开发、维护,或两者都关注。 |
·开发计划: | 用于指导、实施和控制一个或多个产品的设计和开发的计划。 (参见“项目计划”)。 |
·入口准则: | 在一项工作能够成功地开始之前必须存在的状态。 |
·建立与维护: | 在GJB 5000A中,会遇到包含短语“建立与维护”的一些目标和实践。该短语包含了比其成份词
的组合更多的含义。它还包含了建档和采用的含义。例如,“为策划和实施组织过程焦点过程域建立与
维护组织方针”。意指不仅必须有方针,而且必须文档化,并且必须在整个组织中采用。 |
·出口准则: | 在一项工作能够成功地结束之前必须存在的状态。 |
·期望的CMM--MSD部件: | 一个CMM-MSD部件,它用来说明为满足一个必需的CMM-MSD部件可做些什么。模型用户可
以明确地实施期望的部件,或者实施与这些部件等价的替代实践。专用实践和共用实践都是期望的部件。 |
·正式评价过程: | 按所建立的准则评价备选方案的一种结构化途径,以确定处理问题的推荐解法。
框架 framework(参见“CMM-MSD框架”)。 |
·功能分析: | 对一个已定义功能的考察,以便识别出完成该功能所必需的全部子功能;标识功能关系和(内部的
和外部的)接口,并将这些记录在一个功能体系结构中;此外还要将上层的性能需求及其分配情况下传
给下层的子功能。 |
·功能体系结构: | 关于功能模块、它们的内部和外部(功能模块集合自身之外的)功能接口及外部物理接口、它们各自
的功能和性能需求,以及它们的设计约束等的层次式安排。 |
·功能配置审核: | 为了证实一个配置项的开发已经圆满完成,已经达到了在功能或分配的配置标识中指明的性能和功
能特性,并且它的运行和支持文档是完备且令人满意的而进行的一种审核。 (参见“配置审核”、“配置
管理”和“物理配置审核”)。 |
·共用目标: | 一种必需的部件,它描述实现一个过程域的过程制度化所必备的一些特性。 |
·共用实践: | 一种期望的部件,它对完成相关共用目标是重要的。与一个共用目标相关的共用实践描述可望导致
共用目标完成,并对那些与一个过程域相关过程的制度化有贡献的活动。 |
·共用实践详细说明: | 一个资料性的部件,它出现在一个共用实践之后,用来对共用实践该如何应用于过程域提供指导。 |
·目标: | 一种必需的部件,它可以是共用目标,也可是专用目标。 |
·更高层管理者: | 一个或几个对过程提供方针和全局指导,但并不对过程进行每日直接监控的人。这些人员在组织中
属于一个管理层,他们位于负责过程的人员的紧上层,可以是(但不一定是)高层管理者。 |
·资料性的CMM--MSD部件: | CMM-MSD的一些部件,他们用来帮助模型用户理解一个模型的必需部件和期望部件。这些部件
可以包括例子、详细解释、或其它帮助信息。子实践、注释、参考资料、 目标标题、实践标题、来源、
典型工作产品、共用实践详细说明等都是资料性CMM-MSD部件。 |
·制度化: | 作为企业文化的一部分,组织日常遵循的业务业务的一种根深蒂固方式。 |
·接口控制: | 在配置管理中实施下列功能的过程: (1)标识与由一个或多个组织提供的两个或更多个配置项间的
接口相关的全部功能特性和物理特性,并(2)确保对这些特性建议的更改在实施之前予以评价和批准。 |
·生存周期模型life: | 把一个产品或项目的生存周期分为若干阶段的划分模式。 |
·已管理过程: | 一个按照方针来策划和执行的已实施过程;为了产生受控的输出它有足够的资源来聘用技术人员;
它把利益相关方联合在一起;它受监督、控制和评审;并评价它与其过程说明的一致性。 |
·经理: | 在CMM-MSD产品包中,在经理的职权范围内提供技术和管理指导,并控制那些正在实施中的任
务或活动的一个人。经理的传统职能包括其职权范围内的策划、组织、指导和控制等工作。 |
·成熟度等级: | 一组预定过程域的过程改进程度,要求达到这组过程域中的所有目标。 |
·协议备忘录memorandum: | 在两方或多方间谅解或协议的约束性文件。也称“谅解备忘录”。 |
·自然范围: | 由过程绩效测量项反映的固有过程。采用诸如控制图、置信区间和预测区间等技术来确定变化到底
是由共因(即过程是可预测的或“稳定的”)还是由某些特殊原因引起的,这些特殊原因能够并且应该被
识别出来并加以消除。 |
·非开发项: | 在获取或开发过程中使用它之前就已开发好的供应项。这些项可能需稍作修改,以满足其当前的使
用要求。 |
·非技术性需求: | 合同条款、承诺、条件、以及影响产品或服务如何获取的一些其它事项。例子包括,要提交的产品、
所提交的现货产品(COTS)和非开发项(NDI)的数据、交付日期、以及具有出口准则的里程碑等。其它
非技术需求包括培训需求、关于场地的需求,以及部署计划等。 |
·目的: | 当其在CMM-MSD产品包中作为一个名词使用时, 目的(obj ective)一字以其日常一般意义代替目
标(goal)使用,因为字goal被留作引用称为专用目标和共用目标的CMM-MSD部件时使用。 |
·客观证据: | 客观证据的来源可以包括问卷、介绍、文档和访谈等。 |
·客观评价: | 由评审者对照准则评审活动和工作产品,以便最大限度地减少主观性和偏见。例如,由独立质量保
证职能部门对照需求、标准或规程所进行的一种审核。 |
·观察: | 一份书面记录,它表示评估组成员在评估数据采集活动期间对其看到或听到信息的理解。书面记录
可采用陈述的形式,也可用其它形式,只要信息的内容能被保留下来即可。 |
·运行场景: | 设想事件序列的描述,包括产品与其环境和用户的交互,以及产品部件之间的交互。运行场景用于
评价系统的需求和设计,并对系统进行验证和确认。 |
·优化过程: | 基于对固有的过程变异共因的理解进行改进的一种已定量管理过程。它通过增量的和创新的改进活
动关注过程绩效范围的持续改进。 |
·组织: | 一个管理结构,在其中人们共同把一个或多个项目作为一个总体进行管理,这些项目在一个高层管
理者和在相同方针的指导下运作。“组织”也可指在小组织中实施一种职能的个人,这种职能在一个大
组织中或许由一组人来实施。 |
·组织成熟度: | 一个组织已明确而一致地部署一组文档化、已管理、已测量、受控并持续改进的过程的程度。组织
成熟度可通过评估测量。 |
·组织方针: | 通常由高层管理者制定的指导原则,它们被组织用来影响和确定决策。 |
·组织的过程资产: | 与过程的说明、实施和改进有关的各种人工制品(例如,方针、测量数据、过程说明和过程实施支
撑工具等)。“过程资产”一词用来指明为了达到组织的业务目标而开发或获取的那些人工制品,它们表
示组织为提供期望的当前和将来业务价值所做的投资。 |
·组织的业务目标: | 由高层管理者设计制定的策略,其目的在于确保组织的继续存在、增强获利能力、扩大市场份额、
以及增加影响组织成功的其它因素等。 |
·组织的测量库: | 用来收集过程和工作产品的测量数据并使之可用的一个库,特别指与组织的标准过程集中过程相关
的测量数据。这个库包含或引用实际的测量数据,以及为了理解和分析测量数据所需的相关信息。 |
·组织的过程资产库: | 用来存储过程资产并使之可用的一个信息库,库中的过程资产对组织中定义、实施和管理过程的人
员是很有用的。这个库中包含的过程资产包括与过程相关的文档,例如,方针、已定义过程、检查单、
有关经验教训的文档、模板、标准过程、计划和培训材料等。 |
·组织的标准过程集: | 组织中一组用来指导各种活动的过程的定义。这些过程说明包含所有基本过程元素(及其间关系,
例如次序和接口等),它们必须被融入组织中各项目将实施的各种已定义过程。一个标准过程将使在整
个组织中能够实施一致的开发和维护活动,并对长期的稳定和改进是十分重要的。 |
·同行评审: | 为了识别并消除缺陷,在工作产品的开发期间由同行实施的评审。“同行评审”一词替代CMM-
MSD产品包中的“工作产品审查”。 |
·绩效参数: | 有效性测量项,以及用来指导和控制渐进式开发的其它关键测量项。 |
·已实施过程: | 为生产工作产品完成所需工作的过程。该过程域的专用目标得到满足。 |
·物理配置审核: | 为了验证一个配置项是否符合定义和描述它的技术文档所进行的一种审核。 |
·已计划过程: | 通过说明和计划两种方法进行文档化的过程。说明和计划应协调一致,而且计划应包括标准、需求、
目标、资源和任务分配等等。 |
·过程: | 可认为是实践实施的各种活动。为了使一个模型可用于过程改进和过程评估,这些活动可被映射到
本标准过程域中的一个或多个实践。
在共用目标和共用实践的陈述和说明中,词“过程”有特殊的用法,它是指实施该过程域的过程或
过程组。 |
·过程行动计划: | 根据评估结果产生的计划,它对评估发现的弱项的具体改进措施文档化。 |
·过程行动组: | 负责开发和实施组织的过程改进活动的组。 |
·过程和技术改进: | 对过程、过程技术或产品技术进行的增量的和创新的改进。 |
·过程体系结构: | 标准过程中的过程元素之间的顺序、接口、相互依赖以及其他关系。过程体系结构还描述过程元素
与外部过程(例如,合同管理)之间的接口、相互依赖和其他关系。 |
·过程域: | 领域中的一簇相关实践,当他们一起实施时,将达到对该领域的改进重要的一组目标。本标准的所
有过程域对连续表示和分级表示都是共同的。 |
·过程资产: | 组织认为对达到过程域的目标有用的任何东西。 |
·过程资产库: | 可供组织或项目使用的过程资产的集合。 |
·过程属性: | 过程能力的一种可测量特性,它适用于任何过程。 |
·过程能力: | 通过遵循一个过程所能获得的预期结果的范围。 |
·过程定义: | 确定和描述过程的活动,其结果是过程说明。 |
·过程说明: | 为达到给定目的所实施的一组活动的文档化表述。
过程说明提供过程主要部件的操作定义。该说明以完备、准确和可验证的方式规定过程的需求、设
计、行为或其它特性。它也可以包括确定是否满足这些规定的规程。过程说明可建立在活动层、项目层
或组织层上。 |
·过程元素: | 过程的基本单位。过程可用一些子过程或过程元素来定义。子过程可能进一步被分解成子过程或过
程元素.但过程元素不能再分解。
每个过程元素包含一组紧密相关的活动(例如,估计元素和同行评审元素)。过程元素可用一组欲完
成的模板、欲精炼的抽象、或欲修改或使用的说明来描绘。过程元素可能是一个活动或任务。 |
·过程: | 定义、维护和改进组织所用过程的组。 |
·过程改进: | 改进组织的过程的绩效和过程成熟度的活动。 |
·过程改进目标: | 为指导现有过程的改进工作而建立的一组目标特性。以一种特定的、可测量的方式,或者借助所得
产品的特性(例如,质量、性能、标准的符合性等),或者以执行该过程的方式(例如,消除冗余过程步、
过程步组合,以及改进周期时间等)来指导过程的改进(参见“组织的业务目标”和“定量目标”)。 |
·过程改进计划: | 基于对组织的过程和过程资产当前强项和弱项的透彻了解,为达到组织的过程改进目标的计划。 |
·过程测量: | 用于对过程及其产品进行测量的一组定义、方法和活动,以了解并说明此过程的特征。 |
·过程所有者: | 负责定义和维护过程的人(或团队)。在组织层,过程所有者是负责组织的标准过程集说明的人(或
团队);在项目层,过程所有者是负责项目的已定义过程说明的人(或团队)。所以,一个过程可以有多
个在不同责任层次上的所有者。 |
·过程绩效: | 执行过程所得实际结果的测量值。它包括过程测量值(例如,工作量、周期时间和消除缺陷的效率)
和产品测量值(例如,可靠性、缺陷密度和响应时间)两种。 |
·过程绩效基线: | 执行过程所得实际结果的文档化特征,用作将实际的过程绩效与期望的过程绩效进行比较的基准。 |
·过程绩效模型: | 过程及其工作产品的属性之间关系的一个说明,该模型根据过程绩效的历史数据开发而得,并用从
项目采集的过程和产品的测量值进行校准,它用于预测执行一个过程所能获得的结果。 |
·过程剪裁: | 为特定的目的编写、更改或调整一个过程说明。例如,为了适应项目的目标、约束和环境,项目从
组织的标准过程集剪裁出它的项目的已定义过程。 |
·产品: | 欲交付给顾客或最终用户的工作产品。产品的形式可因环境而异。 |
·产品基线: | 在配置管理中,在其生存期中开发、运行、维护,以及后勤支持期间初始批准的定义配置项的一个
技术数据包(包括,源码清单)(亦可参见“配置项”和“配置管理”)。 |
·产品部件: | 作为产品的更低层次部件的一种工作产品。产品部件被集成以生成产品。产品部件可有多个层次。 |
·产品部件需求: | 产品部件的完整规格说明,包括功能、性能、以及其他需求。 |
·产品线: | 一组产品,它满足所选市场或任务的特定需要,具有一组共同且受管理的特征。 |
·大纲/计划: | a) 一个项目;
b) 相关项目和支持这些项目的基础设施的集合,包括目标、方法、活动、计划和成功测量项。 |
·项目: | 受管理的相关资源的集合,它向顾客或最终用户交付一个或多个产品。项目有一个确定的开始(即
项目启动),并严格按照计划进行运作。计划要文档化,说明要交付或实现什么、要使用的资源和资金、
要做的工作以及做工作的进度等。一个项目可由若干项目组成。 |
·项目经理: | 负责计划、指导、控制、筹建和激励项目的人。项目经理负责使顾客满意。 |
·项目计划: | 为项目活动的实施和控制提供基础的一个计划,它处理对项目顾客的承诺。项目计划包括:估计工
作产品和任务的属性;确定所需资源;协商所作承诺;生成进度;标识和分析项目风险。为了制定项目
计划或许要反复进行这些活动。 |
·项目进展和绩效: | 实施项目计划时,项目所完成的工作量、成本、进度和技术性能等。 |
·项目启动: | 指定相关资源用于为顾客或最终用户开发或交付一个或多个产品的时刻。 |
·项目的已定义过程: | 从组织的标准过程集剪裁的、集成的和已定义的过程。 |
·原型: | 产品或产品部件的一个初始类型、形式或实例,它作为后续阶段的一个模型,或者作为产品最终完
成版本的一个模型。该模型可用于下述(和其他)目的:
a) 评估新的或不熟悉技术的可行性;
b) 评估或缓解技术风险;
c) 确认需求;
d) 演示关键特征;
e) 考核产品是否合格;
f) 考核过程是否合格;
g) 特征化性能或产品特征;
h) 阐明物理原则。 |
·质量和过程绩效目标: | 产品质量、服务质量和过程绩效的目标和需求。虽然过程绩效目标也包括质量,然而,为了强调质
量在本标准中的重要性,宁可使用“质量和过程绩效目标”一词,而不是仅仅“过程绩效目标”。 |
·质量保: | 为使管理者确信过程的已定义标准、实践、规程和方法已得到应用而设立的一套有计划的且系统化
的方法。 |
·质量控制: | 用于完成质量需求的操作技术或活动。 |
·已定量管理过程: | 用统计技术和其它定量技术来控制的一种已定义过程。产品质量、服务质量和过程绩效属性在整个
项目中都是可测量且受控的。 |
·参考模型: | 这是如次的模型,它是用作测量某个属性的一个基准。 |
·必需的CMM--MSD部件: | 在给定过程域中,对过程改进的完成十分重要的CMM-MSD部件。评估中,用这些部件确定过程
能力。专用目标和共用目标都是必需的的部件。 |
·需求分析: | 基于对顾客的需要、期望和约束,运行方案,对人员、产品和过程预定的使用环境,以及有效性测
量值的分析,确定产品特定的性能和功能特性。 |
·需求引出: | 采用诸如原型和结构化调查等系统技术,尽力将顾客和最终用户的需要识别出来并将其文档化。 |
·需求管理: | 对项目收到的或产生的所有需求的管理,所有需求包括技术的或非技术的需求,以及组织在该项目
上强索的需求。 |
·需求可追溯性: | 在需求与相关需求、实现和验证之间的可辨识的关联性。(参见“双向可追溯性”和“可追溯性”) |
·投资回报率: | 从输出(产品)所得的收入与生产成本之比,它确定组织是否从实施生产某物的行动中获得了好处。 |
·风险分析: | 对风险的评价、分类和排序。 |
·风险标识: | 找出在达到目标的过程中可能或现实风险的一种有组织的且彻底的途径。 |
·风险管理: | 一种有组织的分析过程,以标识可能导致伤害和损失的事情(标识风险),评估并量化已标识出的风
险,需要的话,开发并实现一个适当的途径来防止或处理那些可能导致重大伤害和损失的风险原因。 |
·风险管理策略: | 一种有组织的技术途径,以标识可能导致伤害和损失的事情(标识风险),评估并量化已标识出的风
险,需要的话,开发并实现一种适当的途径来防止或处理那些可能导致重大伤害和损失的风险原因。通
常,对项目和组织实施风险管理。 |
·根原因: | 一个缺陷的源,如果消除它,缺陷将会减轻或消除。 |
·高层管理者senior: | 组织中一个足够高层次的管理角色。担当该角色的人主要关注组织的长期生存力,而非短期的项目
和合同关注和压力。高层管理者有权指导资源的分配和再分配,以有效地支持组织的过程改进。高层管
理者可以是满足上述描述的任何一名管理者,包括组织的首脑。 |
·过程变异的特殊原因: | 是仅在某些瞬态情况下所特有的过程变异原因,不是过程固有的。 |
·招标: | 为选择供方(承制方)准备数据包的过程。 |
·专用目标: | 描述独特性质的一种必需的部件,这种特性是为满足相应过程域所必须存在的。 |
·专用实践: | 在达到相关专用目标的过程中被认为是重要的一种期望的部件。 |
·稳定的过程: | 过程”和“统计管理过程”)
所有过程变异的特殊原因都已消除并防止再现,仅剩下过程变异的共因的过程。 |
·分级表示: | 一种模型结构,其中当达到一组过程域的所有目标时就建立了一个相应的成熟度等级;并且各个等
级都为其后续(更高)等级奠定基础。 |
·利益相关方: | 受某任务结果影响,或者以某种方式对此任务结果负责的组或个人。利益相关方可包括:项目成员、
供方、顾客、最终用户,及其他。 |
·标准: | 本标准中使用“标准”作为名词时是指为了规定一致的开发方法而提出和使用的正式强制性要求(例
如,IS O/IEC标准、IEEE标准和组织标准)。关于“标准”的日常含意在本标准中不用术语“标准”来
表达,而用另一个具有同样含意的术语(例如,典型、传统、通常的、或惯例)。 |
·标准过程: | 在组织中指导建立公共过程的基本过程的操作定义。
标准过程用于描述可期望纳入任何已定义过程的一些基本过程元素,以及这些过程元素之间的关系
(例如,顺序和接口)。 |
·工作说明: | 为完成一个项目合同所需工作的说明。 |
·统计可预测性: | 用统计技术和其他定量技术进行控制的一个定量过程的绩效。 |
·统计过程控制: | 过程”)
基于统计的过程分析和过程绩效测量,它将识别出过程绩效变异的共因和特殊原因,并将过程绩效
保持在允许范围之内。 |
·统计技术: | 运用统计方法(例如,统计过程控制、置信区间和预测区间)的一种分析技术。 |
·统计管理过程: | 用一种基干统计的枯术讲行管理的过程,存其中对过程讲行分析,标识过程变异的特殊原因,并将绩效控制在妥善定义的界限之内。 |
·子实践: | 为解释和实现一个专用实践或共用实践提供指导的一种资料性模型部件。子实践或许在字面上看有
时好像是指令性的,但实际意思仅仅是提供一些或许对过程改进有用的想法。 |
·子过程: | 子过程也是一个过程,它是一个更大过程的一部分。一个子过程又可分解成一些子过程和/或过程
元素。 |
·支撑: | 用来确保一个产品能被其最终用户或顾客在运行中使用的一些过程。不论顾客或最终用户是否正在使用该产品,支撑过程都应确保进行维护工作,以使产品处于一种可运行状态。 |
·剪裁指南: | 使得项目、小组和组织的职能部门能够适当地调整标准过程为他们所用。组织的标准过程集的说明
是一般性的、通用的说明,可能不便直接用于实施一个过程。剪裁指南帮助那些要为项目建立已定义过
程的人。剪裁指南包括:
a) 选择一个标准过程;
b) 选择一个经批准的生存周期模型;
c) 剪裁所选的标准过程和生存周期模型以适合项目的需要。剪裁指南描述什么可以修改,什么不
可以修改,并标识出可供修改的候选过程部件。 |
·技术资料包: | 一个信息项的集合,如果这些信息适合产品和产品部件的类型,技术资料包可以包含下列诸项:
a) 产品体系结构说明;
b) 分配需求;
C) 产品部件说明;
d) 与产品有关的生存周期过程说明(如果不把它们描述为分开的产品部件的话);
e) 关键的产品特性;
f) 必需的物理特性和约束;
g) 接口需求;
h) 用于确保已满足需求的验证准则;
i) 贯串产品整个生存周期的使用条件(环境)、运行场景、操作的模式和状态、支持、培训、制造、
处置和验证等;
j) 决策和特征(例如需求、需求分配和设计选择)的理由。 |
·技术需求: | 要获取或开发的产品或服务的特性(属性)。 |
·测试规程: | 一个给定测试的建立、执行和结果评价的详细说明。 |
·可追溯性: | 两个或多个诸如需求、系统元素、验证或任务等逻辑实体之间的一种可辨别的关联。 |
·抉择研究: | 根据准则和系统分析对备选项的评价,以便选出达到确定目标的最佳备选项。 |
·培训: | 正式的和非正式的学习可选项,可以包括课堂培训、非正式的辅导、基于Web的培训、有指导的
自学、以及正式的在岗培训计划等。各种情况下的选择是基于培训需要与受训者水平间差距的评估确定
的。 |
·典型工作产品: | 一个资料性的模型部件,它提供专用实践的示例输出。把这些例子称为典型工作产品是因为常常存
在其他工作产品,它们也是有效的,但未被列出。 |
·确认: | 当要交付产品时,对该产品确能满足其预定使用要求的一种肯定。换句话说,“确认”确保“构造
了正确的东西”。 |
·验证: | 对工作产品满足指定需求的一种肯定。换句话说,“验证”确保“正确地构造了它”。 |
·工作分解结构: | 关于工作元素及其彼此关系,以及它们与最终产品间关系的一种安排。 |
·工作产品: | 过程的有用结果。这可以包括文件、文档、产品、服务、过程说明、规格说明以及发货清单等。工
作产品与产品部件之间的关键区别是一个工作产品不一定是产品的一部分。 |
·工作产品和任务属性: | 产品、服务和项目任务的特性,用来帮助估计项目工作。这些特性包括规模、复杂度和功能等项。
它们通常被用作导出其它项目和资源(例如,工作量、成本和进度)估计的输入。 |