您的位置:标准吧 > 标准下载 > SJ 11234 20011 软件过程能力评估模型5

SJ 11234 20011 软件过程能力评估模型5

时间:2012-5-28 14:42:50 作者:标准吧 来源:SJ 阅读:1809次
SJ 11234 20011 软件过程能力评估模型5

                                                软件过程能力评估模型

    关于运用结构式决策方法来评估替代方案(用于缓解风险)的更多的信息,参见“决策分析决定”过程方面。

特定目标

SG 1  准备风险管理   

    进行风险管理准备。

SG 2识别和分析风险

    识别并分析风险,以确定其相对重要性。

SG 3缓解风险

  处理风险并且在适当时缓解风险,以减小对实现目标的不利影响.

通用目标

GG 1实现特定目标

    该过程通过把可识别的输入工作产品转换成可识别的输出工作产品,

特定目标并且使之能够实现。

GG 2制度化为受管理过程

以支持实现该过程方面的

    把该过程作为受管理过程加以制度化.

GG 3制度化为已定义过程

  把该过程作为已定义过程加以制度化.

GQ 4制度化为定量管理过程

  把设过程作为定量管理过程加以制度化.

GG 5制度化为持续优化过程

  把该过程作为持续优化过程加以制度化,

    与目标对应的特定惯例

    SG l准鲁风险管理

    进行风险管理准鲁,

SG2.识别和分析风险

识别并分析风险,以确定其相对重要性。

SG3.缓解风险

处理的是在运用和控制风险管理大纲时使用的具体措施、资源和管理方法。风险管理策略包括对风险来源、风险分类方案以及风险的评价、界定和控制参数等的策划。

    SP l.卜1确定风险来源和分类

    确定各种风脸的来源,并对其加以分类。

    了解风险来源,为系统性地检查不断变化的情况打下基础,以便揭示那些将对项目实现其目标的能力造成不利影响的环境。风险来源存在于项目的内部和外部,随着项目的推进,还可能发现新的风险来源。建立风险分类,实质上是提供一种机制,以便收集和归纳各种风险以及确保这些风险得到适当的推敲和引起管理者的关注——这些风险是否将对项目目标的实现产生更严重的后果。

    典型工作产品

    1.  风险(内部和外部)来源一览表。

    2.  风险分类一单表。

    子惯例

    1.  确定风险来源。

    一些重要的风险来源如下:

    ●  需求不确定;

    ●  设计过分灵活:

    ●  测试和评估不充分:

    ●  技术可用性不充分:

    ●  缺乏可生产性:

    ●  重要活动重叠;

    ●  开发者能力欠缺:

    ●  成本和资金有问题:

    ●  监督不够:

    ●  进度的估计或安排不切合实际;

    ●  缺乏足够的人力资源:

    ●  存在安全问题。

    如果不经过充分策划就接受那些单一的、有限的和日趋萎缩的供应来源,往往就会收纳许多外部风险来源。早期识别内部和外部风险来源能够通过实施比较简单的风险缓解方案在项目的早期排除风险或降低风险以后发生的机会。

    2.  确定风险分类。

风险分类既支持分门别类地了解风险来源,又为评价每个风险建立通用的层次(类别)。分类包含风险来源(例如,技术、环境、设计等)和风险的影响(例如,成本、进性能等)。

可以运用风险分类框架按照通用的风险类别、元素和属性收集和归类风险。

SP l.2-1定义风险参数

  对用于分析和归类风险的参数和用于风险管理工作的参数加以定义.

    用于风险的评价、归类和排序的参数包括风险判断和严重性级别划分准则、分类阈值(或控制点)以及定义这些阈值的适用范围的界限。风险管理工作的控制参数包括风险的控制级别、对实施风险缓解计划和接受缓解结果给予批准的级别、风险复评间隔时间以及用于风险定型的准则.

  典型工作产品

  1.  风险评估、分类和排序准则。

  2.  风险管理要求(控制和批准级别、复评估间隔时间等)。

  子惯例

    2.  规定每类风险的阈值

    可以针对每类风险建立阈值(或控制点),以便确定风险的可接受度或不可接受度、风险先后顺序、或管理行动的触发点。例如,把产品成本超过目标成本的10%定为项目的目标阈值。然后可以针对每个已识别的风险进一步细化阈值,以便建立主动实施风险监督的监督点或确定缓解计划实施标志。

    3.  把界限规定在风险阈值的适用范围上或某个风险类别中。

    究竟哪些风险可以进行定量或定性评估,限制很少。规定界限(或边界条件)可能有助于了解风险管理工作范围和避免过度的资源开销。界限可以包括从某类风险中排除某个风险,例如在环境风险类中不考虑某种自然现象可能带来的风险。规定边界时也可以排除任何不常发生的状态,例如,在产品的预期生存周期里发生概率低于10%的任何事件.

SP 1,3-1制订风险管理策略

  建立并维护风险管理的策略和方法.

    综合性的风险管理策略涉及的内容有(例如):

  ●  用于界定风险管理工作量的范围:

  ●  用于风险识别、风险分析、风险缓解、风险监督和通报的方法和工具:

  ●  项目特有的风险来源:

  ●  风险的归类、界定和定型:

  ●  关于已识别的风险的阈值、参数和用于确定是否采取措施的判据:

  ●  所要使用的风险缓解技术,例如原型法、模拟、替代设计或渐进式开发:

  ●  责任,例如控制或批准级别;

  ●  用于监督风险状态的风险度量项目的定义:

  ●  风险监督或重新评估的时间间隔.

    风险管理策略应着眼予共同的成功前景;这个前景描述所希望的以交付的产品、成本和适用性等为标志的项目的未来成果。风险管理策略往往在项目风险管理计划中得到反映,并且应该与相关的共利益者一起审查,以促成关于风险策略的承诺和理解。

    典型工作产品

    1.项目风险管理计划。

S0 2识别和分析风险

  识别风r并对其进行分析,以确定它们的相对重要性.

  风险的程度影响到为对付风险而分配的资源和确定何时需要哪一级管理者关注。

SP 2.1-1识别风险

  识别风险并形成文件.

    对那些可能对工作或工作计划造成不利影响的潜在的问题、危害、威胁、脆弱性等等的识别是强有力的成功风险管理的基础.在对风险进行分析和管理之前,必须对风险采用易于理解的方式加以标识和描述。把风险形成简明扼要的文件,其中包括背景、条件和风险发生后的后果。

    风险识别应遵循有组织的通盘考虑的思路,以便找出在实现目标的过程中的异常的或符合常规的风险。为了有效进行风险识别,不应该不顾其重要性而试图处理每一个可能事件。运用风险管理策略中拟订的风险类别和参数,结合所识别的风险来源,可以提供风险识别的类目并且使风险识别成为恰当的整体性工作。所识别的风险将是启动风险管理活动基线。风险览表应定期审查,以便重新检查可能的风险来源和调整条件,从而进一步发现以前没有注意到的或者是在拟订风险管理策略时还不存在的风险桌源和风险。

    风险识别活动侧重于风险的识别,而不是追究过失.管理者不应该把风险识别活动的结果用于评价个人的表现。

    风险识别的方法一般包括:

  ●  检查项目的工作分解结构的每个元素,以发现风险:

  ●  运用风险分类学进行风险评价:

  ●  向相应的主题领域的专家征求意见;

  ●  审查类似的产品的风险管理工作;

  ●  查找有关的经验教训的文件或数据库;

  ●  检查设计规范和协定的要求,

  典型工作产品

  1.  已识别的风险的一览表,包括背景、条件和风险发生后的后果.

  子惯例

  1.  识别与产品生存周期各个阶段的成本、进度和性能相关联的风险.

    应该在产品生存周期的所有各个阶段检查成本、进度和性能方面的风险,确定其对项

    目目标实现的影响程度。可能有一些风险不在本项目的目标范围之内,但是对顾客来说很重要。例如,在开发成本、产品采购成本、产品备份(或替换)成本以及产品处置成本等方面的风险对产品开发期间的设计有影响,而顾客不可能提供现场产品支持成本方面的要求。应该把此类风险通知顾客,只不过不需要主动管理这些风险。应该研究在项目和组织    一级作出这类决策的机制,并且在适当的时候,特别是对于那些影响产品确认的风险运用这些机制。

    在开发成本方面的风险,除了上述的成本风险外,还可能包括那些与资金提供水平、

    资金投入估计和预算分配等有关的风险。

    开发进度风险可能包括与策划活动、关键事件和里程碑有关的风险.

    性能风险可能包括与下列范畴有关的风险:

    ●  需求:

    ●  分析和设计:

    ●  新技术的应用:

    ●  规模;

    ●  功能性能和运行;

   ●  性能维护属性。

有些风险不是“纯”成本、进度或性能一类的。

这些不“纯”的风险的例子有:

●非本组织管理或技术原因引起的风险;

●供货来源萎缩

●技术周期时间不确定性

●竞争因素

2.审查可能影响项目的环境元素。

容易被遗漏的项目的风险包括那些凭空认为不在本项目范围内的风险,即,尽管本项目不必过问其是否发生但是可能需要缓解其影响的那些风险,例如自然灾害、通信故障等。

3.作为风险识别活动的一个部分,对工作分解结构的所有元素进行审查,以便有助于确保工作的所有各个方面都得到考虑。

4.  作为风险识别活动的一个部分,对项目计划的所有元素进行审查,以便有助于确保项目的所有各个方面都得到考虑。

    关于识别项目风险的更多的信息,参见“项目策划”过程方面。

    5.  把风险的背景、条件和潜在的后果形成文件。

    风险说明一般采用标准格式,其中包括风险背景、条件和风险发生后的后果。风险背景给出一些易于理解风险的补充信息.在书写风险背景时,要考虑风险的有关的时间关系、围绕风险的环境或条件以及任何尚存疑问之点或不确定之处。

    6.  确定与每个风险相关联的受影响方。

SP 2.2-1  对风险进行评价、分类和排列优先顺序

  运用风类别和参数对每个风险进行评价和分类,并确定其相对优先顺序.

     有必要划分风险的等级,以便表明每个风险的相对重要性,进而用以确定要求相应的管理者在什么时候予以关注.根据风险的内在关系把风险加以汇总并且就同一个汇集层次考虑处理意见往往总是很有用的.如果某个风险汇集层次是由较低层次的风险汇集而成的,必须注意保证那些重要的较低层次的风险不至于被忽略。

    使用诸如可能性(概率)和后果(影响)之类参数对风险加以量化,同时也可以补充其他参数。一般采用这些参数的等级划分值的组合来确定风险处理的总的优先顺序。

    有时把进行风险评价、分类和排优先顺序的活动统称为风险评估或风险分析。

典型工作产品

1.  带有每个风险的等级参数划分值的风险一览表,

子惯倒

1.  运用规定的风险参数对所识别的风险进行评价。

对每个风险进行评价并且根据规定的风险评价参数对其赋值;这些参数包括可能性(概率)、后果(严重性或影响)以及时间框架(预计风险可能发生的时间)。可以把所赋予的各个参数值综合成能够用于排列风险处理的优先顺序的补充度量项目(例如风险显露度一一风险可能性和后果的组合值)。通常用三到五个参数值作为标注尺度来标明风险的可能性和后果的等级。可能性(例如)可以按遥远、不大可能、可能、很可能、几乎肯定等划分等级。  

量化后果的例子有:

●低

●中

●高

●可以忽略的

●处于边缘的

●重大的

●至关重要要

●灾难性的。

 

    概率往往用于量化可能性。后果一般涉及成本、进度、环境影响或人力因素(例如工作小时和伤害严重性)。

    这类评价往往比较困难而且很费时间。在评估风险时和为了使划分的风险等级令人信服可能需要专家或采用群决策技术。此外,划分的等级可能需要随着项目的推进而重新评价。

2.  根据规定的风险类别对风险进行分类和分组。

  把风险按规定的风险类别归类,便于按风险的来源、类目或项目组成部分了解风险.可以把相关的或类似的风险归纳成一组,以便有效地处理风险。为此,要清楚相关风险之间的因果关系。

3.  为缓解风险而排列出风险的优先顺序。

  根据风险的参数值确定每个风险的相对优先顺序。在确定风险的优先顺序时要使用明确的判断准则,排列优先顺序是为了把资源用于缓解对项目影响最大的风险。

    SG 3缓解风险

    对付风险并且在适当时缓解风险,从而降低对实现项目目标的不利影响。

    对付风险的步骤包括提出风险处理意见、监督风险和在超出规定阈值时执行风险处理活动。

    针对所选择的风险拟订并实施缓解风险的方案,主动降低风险发生时的潜在影响。这类方案可能包括用于处理所选风险万一发生时的影响的应急方案,这与缓解风险的意图无关。用于启动风险处理活动的判据、阈值和参数由风险管理策略规定。

    SP 3.1-1拟订风险缓解方案

    按照风险管理策略的规定,针对那些对项目来说最重要的风险拟订风险缓解方案。风险缓解方案要为所识别的风险确定水平和阈值——超过此水平或闽值,风险将变得不可接受并将启动风险处理活动。风险缓解方案往往只针对所选择的高后续影响的风险拟订:对其他风编制风险缓解方案的关键是拟订几种替代行动方案、规定工作区和撤退位置以及每个关键风险的一个推荐的行动方案。每个风险缓解方案都要包括用以避免、降低和控制该风险发生的可能性的技术和方法,以及用以降低和控制该风险发生时招致的危害程度的技术和方法(有时称为应急方案)。一旦所规定的阈值被超过,就要部署这些缓解方案,以便使受影响的工作回归到可接受的风险水平上。风险管理策略规定的判据、阈值和参数用于

    确定在什么时候需要采取风险处理行动。

    处理风险的意见一般包括若干替代方案,例如:

    ●  风险避免——在仍然满足顾客需求的情况下修改或降低要求:

    ●  风险控制——采取主动行动尽量减少风险:

    ●  风险转移——重新分配设计要求,以降低风险:

    ●  风险监视——监视风险并且针对所分配的风险参数定期重新评价风险:

    通常,特别是对于“高”风险,应该有一种以上的风险处理方法。

    在许多情况下,对风险采取接受或监视方式。风险接受通常是在判断该风险属于不值得正式缓解的低风险或者是找不到减小该风险的可行方法的情况下采用。如果某个风险被接受,那么.应该把这个决定的理由形成文件。如果存在客观规定的、经过验证和形成文件的性能阈值、时间或风险显露度(可能性和后果的组合值);这些值将启动风险缓解方案或在必要时启动应急方案。

    应该把项目技术论证、模型、模拟和原型设计作为风险缓解策划的组成部分尽早给予充分考虑。

    典型工作产品

    1.  已识别风险的处理意见(文件)。

    2.  风险缓解计划。

    3.  负责跟踪和处理每个风险的责任人一览表。

    子惯例   

    I.  确定风险水平和阈值;它们指出风险在什么情况下将变得不可接受并且将启动风险处理行动。

    用风险模型派生得出的风险水平是一种组合衡量尺度,它反映目标实现不确定度和目标失败的后果。

为了了解风险,对于那些界定预计性能或可接受性能的风险水平和阈值(或控制点) 需要清楚地理解并作出规定。风险的恰当分类对于确保适当的风险严重性轻重性轻重急顺序和相应的管理者响应是十分重要的,可能有多个值(控制点)用于启动不同级别的管理者响应。

    2.  确定负责处理每个风险的人或组。

    3.  确定实施风险缓解方案的成本,效益比。

    应该对照资源开销,检查风险缓解活动的效益。象其他任何设计活动一样,可能需要拟订几种替代方案,然后选择最适宜的方案予以实施。往往是风险重,效益小;不过重大风险因其后果难以被接受而必须予以缓解。

    4.  拟订本项目的总体缓解方案,用以指导为每个风险精心编制实施方案。

    可能拿不出完备的成套风险缓解方案。应该权衡分析,以便为各个缓解方案的实施排列优先顺序。

    5.  针对所选择的关键风险万一其影响成为事实的情况拟订应急方案。为了在风险发生而成为难题之前主动减轻其可能的影响,可能制订风险缓解方法并在必要时、以实施有些风险可能是不可避免的,将会成为影响项目的难题,因此可能需要针对关键风险制订应急方案,指出当该风险发生时项目可以采取的处置行动。规定处理风险的预备方案的目的在于把风险“管”起来,以便减轻风险(缓解)或响应风险(应急处置)。

    有时把风险缓解方案和应急方案统称为风险处理方案或风险行动方案。

    SP 3.2-1  实施风险缓解方案

    定期监督每个风险的状态并且在适当时实施风险缓解方案,

    为了在项目整个工作期间有效地控制和管理风险,需要遵循预先制订的计划定期监督风险和风险处理行动的状态和结果。风险管理策略规定检查风险状态的时间间隔。这一行动可能发现新的风险或新的风险处理意见——要求重新策划和评估;无论哪种情况出现,

    都应该把该风险的可接受的阈值与之相比较,以便确定是否需要实施缓解方案。

典型工作产品

1.经过更新的风险状态表

    2.  风险可能性、后果、等级和阈值的新的评估结果。

    3.  新的风险处理意见清单。

    4.  新的风险处理行动清单。

    5.  风险缓解方案,

    子惯例

    1.  监督风险状态。

    启动风险缓解方案之后,仍然要对风险加以监督。应该采用实施周期监督的机制。

    2.  提供跟踪方法,用以从开始到结束对风险处理行动进行跟踪。

    关于对各项行动进行跟踪的更多的信息,参见“项s监督和控制”过程方面。

    3.  当所监督的风险超过规定的阈值时,调用所选择的风险处理意见。

    风险处理只在判断出风险处于“高”或“中”等的情况下才执行,这种作法十分普遍。

    给定风险的处理策略可以包含一些处理技术和处理方法,用于避免、减轻和控制风险的可能性或风险(预期的事件或状态)发生时的危害程度。在这样的背景下,风险处理既包含风险缓解方案又包含风险应急方案.

    开发风险处理技术.用于避免、减轻和控制风险发生时给项目目标带来的不利影响,使其达到可接受的程度.要为风险处理措施配备适当的资源并且在计划和进度基线中予以安排。这种重新策划工作需要考虑对各个相关的工作或活动的影响

    关于修订项野计划的更多的信息,参见“项目监督和控制嚣过程方法。

    4.  针对每个风险处理方案或活动制订进度,其中包括开始日期和预计完成日期。

    5.  为每个方案作出资源承诺,以保证风险处理策略的成功执行,

    收集关于风险处理活动的性能度量项目。

目标对应的通用惯例

GG 1实现特定目标

  该过程通过把可识别的入工作产品转换成可识别的输出工作产品支持实现此过程方面的特定目标并且使之能够实现.

  GP l.1确定工作范圈

    针对“风险管理”过程,确定所要执行的工作的范圈和所要产生的工作产晶的范N,并且把这些信息传达给将要执行该工作的人.

  GP l.2执行基本惯例

    执行“风险管理”过程的基本惯例,以开发工作产品和提供服务,以便实现该过程方面的特定目标.

G6 2制度化为受管理过程

  把该过程作为受管理过程加以制度化.

  GiP 2.1建立组织方针

    为策划和执行“风除管理”过程,制订并维护组织方针.

    详细说明:

    这个方针要确定组织的如期望:制订风险管理策略并且识别、分析和缓解风险.

  GP 2.2制订该过程的计划

    为执行此“风险管理”过程,制订并维护需求、目标和计划.

    详细说明:

    这些需求、目标和计划在用于风险管理的计划中描述。风险管理计划不同于这个过程方面的特定惯例中描述的风险管理策略。风险管理策略处理的是风险来源、分类、参数以及管理者控制和报告要求;风险管理计划处理的是对所有风险管理活动的高层策划。

  GP 2.3提供资源

    为了执行所策划的过程、开发工作产品和提供“风险管理”过程的服务,提供足够的资料.

    详细说明:

在执行“风险管理”过程方面的各项活动中使用的工具的例子包括:

●风险管理数据库;

●风险缓解工具;

●原型设计工具:

●建模和仿真。

GIP 2.4分配责任

  为执行该过程、开发工作产品和提供“风险管理”过程的服务,分配责任和权限.

CtP 2.5培训人员

    必要时,对执行或支持“风睑管理”过程的人员进行培训,

    详细说明:

培训专题的例子有:

●风险管理概念和实践(例如,风险识别、评价、监督、缓解);

●风险缓解用的度量项目选择。

GP 2.6管理配置项目

  把“风险配置”过程的指定的工作产品置于配置蕾理的适当层次.

 详细说明:

置于配置管理之下的工作产品的例子有:

●风险管理策略

●所识别的风险

●风险缓解方案

 

GP 2.7确定相关的共利益奢并使之介入

  按计划确定“风险管理”过程的相关的共利益者并使之介入.

  详细说明

需要共利益者介入的活动的例子有:

●建立自由、开放的讨论风险的合作环境:

●审查风险管理策略和风险管理计划:

●参加风险识别、分析和缓解活动;

●通报和报告风险管理状态。

GP 2.8监督和控制该过程

  对照计划监督和控制“风险管理”过程,并且采取适当的纠正措施.

  详细说明:

在监督和控制“风险管理”过程方面的各项活动中使用的度量项目的例子有:

●所识别、管理、跟踪和控制的风险的数目;

●风险显露度(可能性和后果的组合值)和被评估的每个风险的风险显露度的变更情况以及管理储备的总百分比;

●风险管理计划的变更活动情况(例如过程、进度、资金投入);

●未预计到的风险的发生情况:

●风险分类易变性:

●所估计的风险缓解工作量和影响与实际的风险缓解工作量和影响的比较.

GP 2.9客观地评价遵循情况

  对照适用的要求、目标和标准,客观评价“风险管理”过程以及该过程的工作产品和服务的遵循情况,并且处理不符合项.


被审查的活动的例子有:

●制订和维护风险管理策略

●识别和分析风险

●缓解风险

被审查的确工作产品的例子有

●风险管理策略

●风险缓解方案。

 

  SP 2.10高屡管理者审查状态

    高层管理者审查“风除管理”过程的活动、状态和结果,并解决问题。

    详细说明

    应该在适当的管理层次采用定期方式和事件驱动方式对项目风险状态进行审查,以便了解潜在的风险显露度和采取适当的纠正措施.一般,这种审查涉及最关键的风险、关键风险参数(例如这些风险的可能性和后果)以及风险缓解工作的状态等的概要。

GG 3制度化为已定义过程

  把该过程作为已定义过程加以制度化.

  GP 3.1建立已定义过程

    建立并维护一个已定义的“风除管理”过程的描述.

  OP 3.2收集改进信息

    收集那些派生于“风险管理”过程的策划和执行的工作产品、度量项目和改进信息,用以支持本组织的过程和过程财富的进一步使用和改进.

GG 4制度化为定量管理过程

    把该过程作为定量管理的过程加以制度化.

    GP 4.1建立质量目标

    根据顾客需求和组织业务目标,为“风险管理”过程的质量和过程性能建立定量目标并予以维护。

    使“风险管理”过程的上个或几个子过程的性能稳定下来,进而确定该过程在实现所规定的定量目标和过程性能目标方面的能力.

GG 5制度化为持续优化过程

  把该过程作为持缜优化过程加以制度化.

  OP 5.1  确保不断的过程改进

    确保“风险管理”过程不断得以改进,以适应本组织的有关的总体业务目标.

    GP 5.2解决问题的共性原因

    识别并解决“风睑管理”过程中的缺陷和其他问题的根本原因.

6.3.6定量项目管理   

    “定量项目管理”的目的在于对项目已定义过程实施定量管理,以便使项目实现所确定的质量和过程性能目标。

    “定量项目管理”过程方面涉及以下内容:

    ●  建立和维护项目的质量和过程性能目标;

●  根据过程性能基线和,或模型中有关稳定性和能力的历史数据识别适合的子过程,用以组成项目已定义过程;

    ●  在项目已定义过程选择将对其实施统计管理的子过程:

    ●  选择将用于子过程统计管理的度量项目和分析技术;

    ●  运用所选择的度量项目和分析技术,建立并维护对子过程的统计过程控制:

    ●  确定所选择的予过程是否能满足其质量和过程性能目标,、并且在必要时采取纠正措施;

    ●  确定项目已定义过程是否能满足项目目标,并且在适当时采取纠正措施;

    ●  把统计管理数据和质量管理数据纳入组织的度量数据库,

    上述过程性能目标、度量项目以及基线是在整个“组织过程性能一过程中开发的;而执行“定量项目管理一过程所得的结果(度量项目定义、度量数据等)是“组织过程性能一中谈到的组织财富的一个组成部分.

    在实施这个过程方面之前,组织应建立起标准过程集合和相关的过程财富(例如组织的度量数据库和过程财富库),以供每个项目在建立各自的已定义过程时使用。项目已定义过程选择和剪

裁自组织的标准过程集合,是一个子过程集合;这些子过程构成一个统一、连贯的项目生存周期.

    组织的度量数据库和过程财富库的信息有骑予合成璎肄的已定义过程,以便于实现项目目标。

    在这个过程方面里,短语“质量和过程性能目标”覆盖了关于产品质量、服务质量和过程性能的目标和要求。通常,“过程性能目标一也含有对产品质量的要求;之所以使用“质量和过程性能目标”而不使用“过程性能目标一,是为了强调产品质量的重要性。

    过程性能是过程所达到的实际过程结果的度量,用过程度量项目(例如工作量、周期时间和缺陷消除率)和产品度量项旧(例如可靠性、缺陷密度和响应时间)来表征其特征.

    予过程是已定义过程的组成部分(部件).例如,软件组织的一个典塑的开发过程可以用诸如需求开发、设计、建造、测试和同行审查之类子过程予以定义.必要时,这子过程本身还可以进一步分解为更精细的过程描述。

    定量管理的一个要素是具备可信的估计,即,能够预计项目可能满足其质量和过程性能目标的程度。要根据所确定的对可预计性能的需要选择子过程,并对所选择的子过程进行统计管理.

    定量管理的另一个要素是,了解过程性能中的各种变量的性质和变化程度并且及时认识到项目的实际性能可能达不到项目的质量和过程性能目标.这种认识是采取纠正措施的基础.

    统计管理涉及到统计思想和对各种统计技术的正确运用,例如,运行图、控制图、置信度间隔、预报间隔以及假设测试等.利用采集自统计管理的数据进行定量管理将有助于项目预测它是

否能达到它的质量和过程性能目标,和在适当时采取纠正措施.

这个过程方面适用于管理产品,不过,其中的概念也适合对其他小组和功能的管理.

其他小组和功能的例子有:

●质量保证过程定义和改进,

●工作量报告

●顾客投诉处理

●问题跟踪和报告

 

    在这个过程方面里,术语“产品”指产品或服务或同时指二者,视情况而定.

    有关的过程方面

    关于监督和控制项目进展,性能的更多的信息,参见材项目监督和控制”过程方面。

    关子建立可度量的目标,定义度量项g和进行分析,获得和分析度量项目,以及提供标结果等更多的信息,参见“测量和分析”过程方面。

      关于组织质量和过程性能目标、过程性能分析、过程性能基线以及过程性能模型的更多的信息,参见“组织过程性能挣过程方面。

    关于组织过程财富、(包括组织度量数据库)豹更多的信息,参见“组织过程定义”过程方面。

    关于如何识别缺陷和其她题的原因和如何采取预防这些问题和缺陷再次发生移正措施的更多的信息,参见“原因分析和决定”过程方面。

    关于为支持组织质量和过程性能目标两选择和部署改进的更多豹信息,参见甜组织革新和部署,过程方面。

特定目标

SQ 1定量管理项目

    运用质量和过程性能目标对项目进行定量管理.

SG 2统计管理子过程性能

    对项目已定义过程中的所选择的子过程的性能实施统计管理。

通用目标

GG 1实现特定目标

    该过程通过把可识别的输入工作产品转换成可识别的输出工作产品,以支持实现该过程方面的

特定目标并且使之能够实现.

GG 2制度化为受管理过程

    把该过程作为受管理过程加以制度化.

GG3制度化为已定义过程

  把该过程作为已定义过程加以制度化.

Ga 4制度化为定量管理过程

  把该过程作为定量管理过程加以制度化.

GG 5制度化为持续优化过程

  把该过程作为持续优化过程加以制度化.

与目标对应的特定惯例

SG 1定量管理项目

  运用质量和过程性能目标对项目进行定量管理.

SP 1.1-1拟订项目目标

  拟订并维护项目的质量和过程性能目标.

    这个特定惯例一般是在项目策划的初期执行。

    要注意,与这个过程方面的第一个目标对应的前三个特定惯例可能要同时处理。在拟订项目的质量和过程性能目标的同时,考虑组织的标准过程集合中将有哪些元素包含在项目已定义过程里,往往非常有用。此外,为了实现这些目标,识别有哪些子过程需要进行统计管理也很重要。在项目的质量和性能目标与所估计的项目已定义过程的性能之间的平衡一般要经过多次反复才能确定,起初是设定项目性能目标;然后确定项目已定义过程的预期性能。如果项目的质量和过程性能目标与估计的项目已定义过程性能之间存在差异,需要在相关的共利益者之间进行协商,消除这种差异。

  典型工作产品

  1.  文件化的项目的质量和过程性能目标。

  子惯例

  1.  审查本组织的质量和过程性能目标。

    进行这种审查的目的是确保该项目了解所处的更为广泛的业务背景。项目的质量和过程性能目标将缶这些覆盖面更广的组织目标的背景下拟订。

    关于组织的质量和过程性能目标的更多的信息,参见“组织过程性能”过程方面。

2.         确定顾客、最终用户及其他共利益者的质量和过程性能需要及优先顺序。

可能要针对其确定需要和俦顺序的质量和过程性能属性的例子有:

●功能

●可靠性

●开发周期

●可预测性

●时限

 

3.  确定如何度量过程性能。

    考虑本组织建立的度量项目是否足以用于评估本项目在满足顾客、最终用户和其他共利益者的需求方面的进展。可能需要补充一些别的度量项目。

    关于定义度“项目”的更多的信息,参见“测量和分析”过程方面。

4.  对项目的可度量的质量和过程性能目标作出规定并形成文件。

    在规定项目的目标和形成文件时,涉及以下活动:

●  把组织的质量和过程性能目标纳入项目目标范畴:

●  把目标以及它们的度量方法形成文件。这些目标应该能反映顾客、最终用户及其他共利益者的质量和过程性能需要和优先顺序。

质量目标的例子有:

●关键资源利用率;

●有关的产品中的缺陷数和严重程度;

●顾客对所提供的服务的投诉数量和严重性。

 

5.  适当时.针对生存周期每个阶段派生出临时目标,以便监督实现项目目标的进展。

预计过程结果的方法的一个例子是:运用过程性能模型,使用在产品验证活动(例如同行

审查)中发现的缺陷临时度量数据预计将交付的产品中潜藏的缺陷。

过程性能目标例子了有:

●通过产品验证活动(例如同行审查和测试)消除的缺陷的百分比;

●缺陷查率

●产品音乐会(或服务启动)后第一年里发现严重担缺陷的数量和密度;

●开发周期

●返工时间百分比

 

6.  解决项目质量和过程性能目标之间的矛盾(例如一个目标的实现将损害另一个目标)。

    解决矛盾的活动包括:

●  为各个目标设定相对优先顺序;

●  从长远业务战略和近期需要出发考虑替代目标;

●  邀请顾客、最终用户、高级经理、项目经理和其他共利益者一起讨论折中方案:

●  必要时,修改目标,以反映解决矛盾的结果。

7.  对项目的质量和过程性能目标从其来源处起建立溯源性。

 

目标的来源的例子有:

●需求:

●组织的质量和过程性能目标:

●顾客的质量和过程性能目标;

●业务目标;

●与顺胥和躇E顾客讨论所得结果:

●市场调查研究的结果。

确定和跟踪这些需要和俦顺序的方法的一个例子是“质量功能展开”法。

 

8.  提出并协商对供方的质量和过程性能目标要求。

    关于建立和维护供方协定的更多的信息,参见“供方协定管理”过程方面。

9.  必要时,修改项目的质量和过程性能目标。

1. 2-1  合成已定义过程

根据历史上的稳定性和能力数据选择用以组成项目已定义过程的过程和过程元素。关于建立和维护项目定义过程的更多的信息,参见“集成项目管理”过程方萄。

    关于组织的过程财富库(可能包含知的必要能力的某个新豹子过程或过程元素)的

更多的信息,参见“集成项目管理”过程方面。

    关于组织的过程性能基线和过程性能模型的更多的信息,参觅“组织过程性能”过程

方面。

    子过程可以从组织的标准过程集合中的过程元素和组织的过程财富库中的过程资源里

选择。

典型工作产品

1.  用于确定可能纳入项目已定义过程的候选予过程的准则.

2.  可能纳入项目已定义过程的候选子过程。

3.  将纳入项臣已定义过程的子过程。

4.  已识别出的在缺乏过程性能历史数据的情况下选择子过程可能带来的风险。

子惯例

1.  建立用于确定候选子过程的准则。

    可以根据以下条件来确定候选子过程:

●  质量和过程性能目标:

●  产品线标准:

●  生存周期模型:

●  顾客需求;

●  法律和法规。

2.  对那些取自组织的过程财富的、打算对其实施统计管理的子过程,确定其是否适合于统计管理。

  一个子过程,如果它有以下历史,它就比较适合于统计管理:

●  在以前的可比较的事例中它的性能是稳定的:

●  过程性能数据与本项目的质量和过程性能目标适应。

  历史数据主要从组织的过程性能基线获得。不过,这些数据不一定适合所有的子过程.

3.  分析子过程的相互作用,以便了解子过程以及所度量的子过程属性之间的关系。

SJ 11234-2001(1) 软件过程能力评估模型_5

    识别风险——可能没有能满足质量和过程性能目标要求的子过程可用(即,子过程不具备适用的能力或还不知道子过程的能力)。当所选择的子过程没有充分的过程性能数据时就可能有这种风险。

    一个子过程,即使它没有被选择出来接受统计管理,历史数据和过程性能模型也可能表明该子过程不具备满足质量和过程性能目标的能力。

    关于风险识和分析的更多的信息,参见“风险管理”过程方厦。

SP l.3-1  选择将予以管理钩子过程

  选择项目已定义过程中的将对其实施统计管理的子过程.

  典型工作产品

  1.  将按统计管理方式处理的质量和过程性能目标。

  2.  用于选择将实施统计管理的子过程的准则。

  3.  将实施统计管理的子过程。

  4.  所选择的子过程的应予以度量和控制的过程和产品属性。

  予惯例

  1.  确定项目的质量和过程性能目标中有哪些要实施统计管理。

  2.  选择那些将对所确定的质量和过程性能目标的实现起主要作用的子过程和对可预计的性能来说很重要的子过程。

对有些子过程不可能实施统计管理(例如正在进行检验性试点的新的子过程和技术).

对有些子过程实施统计管理可能不经济。

用于选择子过程的准则的例子有:

●顾客对质置和过程性能的需求:

●顾客提出的质量和过程性能目标:

●本组织拟订的质量和过程性能目标;

●子过程在其他项目上的稳定性能;

●法律和法规。

1.         针对所选择的子过程,确定将要予以度量和控制的产品和过程属性。

产品和过程属性的例子有:

●缺陷密度;

●周期

●测试覆盖率

 

SP l.4-1管理项目性能

  对项目进行监督,以确定项目的质量和过程性能目标是否得到满足,并且在适当时采取纠正措施。

    关于分析和使用度量项目的更多的信息,参见“测量和分析”过程方面。

    为确定目标是否得到满足需要进行比较,这种比较的前提是,对所选择的项目已定义过程的子过程要进行统计管理并且它们的过程能力是已知的。

    典型工作产品

    1.  对实现项目的质量和过程性能目标的估计(预计)。

    2.  在实现项目的质量和过程性能目标方面的风险文件。

    3.  为处理在实现项目目标中的不足之处所需的措施文件.

    予惯例

    1.  定期审查每个子过程的性能和将实施统计管理的每个子过程的能力,以便对实现项目的质量和过程性能目标的进展进行评估。

    每个所选子过程的过程能力要结合与这个子过程有关的质量和过程性能目标予以确定。这些目标派生于该项目的质量和过程性能目标,对于该项目而畜,它们是一个整体。

    2.  对照生存周期每个阶段的临时目标定期审查实际结果,以评估实现该项目的质量和过程性能目标的进展.

    3.  对供方实现其质量和过程性能目标的结果进行跟踪。

    4.  用所获得的关键属性的度量数据校准过程性能模型,运用这些经过校准的模型估计实现项目的质量和过程性能目标的进展。用过程性能模型估计那些只能在生存周期的未来阶段上度量的目标实现的进展情况.例如,利用同行审查中确定的缺陷临时度量数据运用过程性能模型预测将要交付的产品中的潜藏缺陷。

    过程性能模型校准的基础是以前子惯例所得的结果。

    关于过程性辘模型的更多的信息,参见“组织过程性能”过程方面。

1.         识别并管理有关实现项目质量和过程性能目标的风险.

这类风险的来源的例子有:

●组织的度量数据库中没有足够的关于稳定性和能力的数据;

●子过程没有足够的性能或能力;

●供方没有实现其质量和过程性能目标;

●对供方能力缺乏了解;

●用于预测未来性能的本组织的过程性能模型的准确度不够;

●预测的过程性能(估计的进展)有欠缺;

 

与所识别出的不跳有关的其他风险。

关于识别和管理风险的更多的信息,参见“风险管理”过程方面。

6.确定为处理在实现项目的质量和过程性能目标中的不跳所需采取的措施并将其形成文件。

这些措施是为了策划和部署适当的活动、资源和进度,以便把项目尽可能拉回到现实其目标的轨道上。

    关于公共度量项目的更多豹信息,参见“组织过程定义”过程方面。

2.  确定补充的度量项目;为了覆盖所选子过程的关键的产品和过程属性,可能需要这些度量项目。

补充的度量项目的例子有:

●  (当组织的标准工作产品和作业属性度量项目是规模时.)由顾客要求的工作产品和作业属性(例如复杂程度);

●由管理部门规定的缺陷类别;

●仅用于处理本项目的唯一性问题和关注事宜的度量项目。

    在某些情况下,有些度量项目可能是面向研究的,要把它们明显标识出来。

3.  确定适合用于统计管理的度量项目。

    选择统计管理度量项目的关键准则包括:

●  可控制(例如,是否能通过改变子过程的实施来改变被度量的值?):

●  性能指针(例如,相对于所关注的目标,子过程执行的良好程度是否可以用该度量项目予以指示。

子过程度量项目的例子有:

●需求易变性

●对度量的策划参数值(例如,规模、成本和进度)的估计率;

●同行审查的覆盖率和效率

●测试覆盖率和效率

●培训效果(例如,已完成的计划的培训的百分数和测试得分);

●可靠性

●生存周期不同阶段中发现的缺陷的百分数。

●生存周期不同阶段超出的工作量的百分数。

4.  规定度量项目的操作定义,度量项目的采集点,以及如何确认这些度量项目。

5.  分析所确定的度量项目与项目目标和派生目标的关系:就所选择的每个子过程的每个被度量属性而言,所确定的度量项目说明要予以遵循的具体目标度量项目或范围。

6.  为支持度量数据的采集、派生和分析而配备组织支持环境。

    配备组织支持环境的基础是:

●  组织的标准过程集合的描述;

●  项目已定义过程的描述;

●  组织支持环境的能力。

    关于建立和维护组织支持环境的更多的信息,参见“组织过程定义”过程方夏。

7.  确定预期用于对所选子过程实施统计管理的适当的统计分析技术。

    “一个尺码不能适应所有的脚。”统计分析技术亦如此。某种度量统计技术不一定正好适合所论的度量项目,更重要的是,如何利用度量数据以及现实情况是否能保证这种技术适用。选择是否合适,可能需要随时进行调查研究。

    统计分析技术的例子在下一个特定惯例中给出。

2.         必要时,修改度量项目和重新选择统计分析技术。

3.          运用所选择的度量项目和分析技术掌握所选择的予过程的变化情况并予以维护.关于采集、分析和使用度量数据,以及验证所采集的度量数据是否有效的更多的信息。 参受“测量和分析”过程方面。

    通过采集和分析过程和产品度量数据来达到对子过程的变化情况的了解,从而识别变化的特殊原因和设法实现预测的性能。

    变化的特殊原因是一种非同寻常的环境,它使过程性能发生预料不到的变化。诸如某个局部条件、按照某种非预期的方式执行过程的某个人或一小群人等等都可能成为某种短暂的环境。这些特殊原因也称为“可认定的原因”,因为可以对它们进行识别、分析和处理,以防止今后再出类似问题。

    典型工作产品   

    1.  所收集的并经过验证的度量数据,包括特殊变化原因。

    2.  所选子过程的每个被度量属性的过程性能的正常范围。

3.  与所选子过程的每个被度量属性的过程性能的正常范围比较的过程性能。

  子惯例

    1.  为拥有适合的历史性能数据的子过程建立试探性的正常范围。

    一个属性的正常范围是这个属性发生正常变化的范围。所有的过程,每当它们实施时.都会在过程和产品度量项目方面呈现出某些变化。问题是.这种变化究竟是由于该过碍的标称性能中的其性变化原因还是由于某些可以或者说应该能识别和消除的特殊原因所致。

在最初启动某个子过程时,有时可以从这个子过程或可比较的子过程的以前的事例中得到一些适合的数据,用以建立试探性的正常范围。这些数据一般包含在组织在组织的试题数据库里。随着这个子过程的实施,可以从自身实践中采集特有的数据,用于更新和替代试控性正常范围。不过,如果这个子过程是经过实质性的剪裁得来的,或者现行条件与它以前的事例有着本质上的区别,那么,组织度量数据库里的数据可能就没有用。 

  在某些情况下,可能没有可比较的历史数据(例如,进入新的应用领域时,或对子过程作出重大变更时)。在这种情况下,必须从这个子过程运行中迟早取得过程数据,建立试探性正常范围。然后必须随着子过程的实施对这些试探性正常范围

加以精炼和更新

用于确定历史数据是否可比较的准则的例子有:

●产品线

●应用领域

●工作产品和作业属性(例如产品规模)

●项目的规模

    关予组织过程性能基线的更多的信息,参见“组织过程性能”过程方面.

    2.  随着子过程的实施收集所选择的度量项目的数据。

3.  针对每个被度量的属性计算过程性能的正常范围。

计算正常范围的场合的例子有:

●控制图

●置信度区间(针对分布参数)

●预计区间(针对未来结果)

 

 

4.  识别特殊变化原因。

 

用控制图搜寻特殊变化原因的一个判断准则例子是:数据点落在控制边界(即控制阈值30)以外。

 

特殊变化原因判断准则的基础是统计理论和经验,此外,还取决于经济方面的原因。判据越多,特殊原因越可能被识别,不过,所涉及的开销和无效的告警也会随之增加。

分析特殊变化原因,确定为什么出现导常现象。

用于分析特殊变化原因的技术的例子有:

●因果图(鱼骨图)

●试验法

●控制图(适用于子过程输入或低层子过程);

●分组法(根据对如何实施子过程才便于隔离特殊原因的了解,把同样的数据分隔成更小的组,然后进行分析)。

  有些异常现象可能只是分布的极端值,而不是问题。实施子过程的犬通常是最有能力分析和理解特殊变化原因的人。

6.  识别出特殊变化原因后,适当时,采取纠正措施。

    消除特殊变化原因不会改变相应的子过程。纠正措施处理的是实施这个子过程时所使用的方法中的差错。

7.  必要时,针对所选择的子过程的每个被度量的属性重新计算正常范围。

    对正常范围重新计算的基础是度量结果;它们表明这个子过程发生了非预期的变化,或出现了随意决策。

可能需要重新计算过程性能正常范围的例子有:

●个子过程的改进越来越多

●为这个子过程部署了新工具;

●部署了新的予过程;

●采集到的度量数据表明这个子过程已经发生了永久性漂移或永久性变化。

SP 2.3-1  监督所选择的-子过程的性能

  监督所选择的子过程的性能,以确定它们的能力是否满足其质量和过程性能目标.并且在必要时采取纠正措施。

    这个特定惯例的目的在于:

●从统计意义上确定子过程预期的过程行为;

●估计该过程满足其质量和过程性能目标的可能性;

●根据对该过程的性能数据的统计分析结果采取纠正措施。

    纠正措施可能包含对受到影响的目标重新进行协商,确定并实施替代的子过程,或者选择较低层次的子过程,进行度量,以便得到更具体的性能数据。任何一个或全部纠正措施,其目的都是帮助项目使用能力更强的过程。

    关于识鄹程解决特殊的过程变化原因的更多的信息,参见“组织过程性能”过程方面。

有能力的过程是稳定的过程,可以指望它能在将来满足甚至超过质量和过程性能目标要求。把所选择的子过程的能力与它的质量和过程性能目标相比较的.一个先决条件是,这个子过程的性能是稳定的,并且,就其被度量的属性而言是可以预计的。

    针对已经确定了(派生)目标的子过程和被度量的属性进行过程能力分析。并不是要对所有实簏统计管理的子过程或被度量的属性进行有关过程能力的分析。

    最初在确定子过程是否有能力时,历史数据可能还不够用。曾经估计过的子过程性能的正常范围也有可能飘离了质量和过程性能目标。不论是哪种情况,对子过程的统计控制都意味着对能力以及稳定性实施监督。

    典型工作产品

    l.  与确定的(派生)目标相比较,所选子过程的过程性能的正常范围。这个范围是用来与该子过程的规定目标(或派生目标)进行比较的。

2.  每个子过程的过程能力

    3.  为处理子过程过程能力中的不足所需采取的措施。

子惯例

1.  把质量和过程性能目标与被度量的属性的正常范围相比较。

  这种比较为子过程的每个被度量的属性给出过程能力评价。可以用图形显示这些比较结果,即所估计的正常范围与目标或过程能力的关系图。

2.  监督质量和过程性能目标和子过程过程能力随时间的变化情况。

3.  识别子过程能力的不足之处并形成文件。

4.  确定为处理子过程能力不足问题所需采取的措施并形成文件。

当所选择的子过程的性能满足不了其目标时所能采取的措施的例子有:

●改变质量和过程性能目标,以便使它们落在子过程的过程能力范围之内:

●改进现行子过程的实施,减少其可变性(减少可变性可以使正常范围处于目标范围内,而不必移动-正常范围的中位值):

●采用那些可能满足目标的新的过程元素和子过程以及技术并进行相应的风险管理:

●针对每个子过程的过程能力中的不足确定风险和风险缓解策略。

  5.  跟踪所确定的措施,直到结束。

SP 2.4-1  记录统计管理数据

  把统计和质量管理数据纳入组织的度量数据库.

    关于管理和存储数据、组织项目定义以及度量结果的更多的信息,参见“测量和分析” 过程方面。

    关于组织的度量数据库的更多的信息,参见“组织过程定义”过程方面。

    典型工作产品

    1.  记录在组织的度量数据库中的统计和质量管理数据。 

目标对应的通用惯例

GG 1实现特定目标

    该过程通过把可识别的输入工作产品转换成可识别的输出工作产品支持实现此过程方面的特定目标并且使之能够实现.

    GP l.1确定工作范围

    针对“定量项目管理”过程,确定所要执行的工作的范围和所要产生的工作产品的范围,并且把这些信息传达给将要执行该工作的人。

    GP l.2执行基本惯例

    执行“定量项目管理”这个过程方面的基本惯例,以开发工作产品和提供服务,以便实现该过程方面的特定目标。

GG 2制度化为受管理过程

  把该过程作为受管理过程加以制度化.

  GP 2.1建立组织方针

    为策划和执行“定量项目管理”过程,制订并维护组织方针。

    详细说明:

    这个方针要确定组织的如下期望:运用质量和过程性能目标对项目进行管理,对项目已定义过程中的所选择的子过程实施统计管理。

  GP 2.2制订该过程的计期

   行此已定量项目管理挣过程,制订并维护需求、目标和计划。

    GP 2.3提供资源

    为了执行所策划的过程、开发工作产品和提供“定量项目管理”过程的服务,提供足够的资源。

详细说明:可能需要统计学和统计过程控制方面的专家来确定用于对所选择的子过程实现统计管理的技术,而其他人员则运用有关工具和技术具体执行统计管理,在分析和解释从统计管理中获得和度量数据时,可能也需要统计学专家。

在执行“定量项目管理”过程方面的各项活动中使用的工具的例子包括:

●系统动态模型;

●测试覆盖率自动分析工具

●过程和质量统计控制包

●统计分析包

 

2.4分配责任

    GP 2.5执行该过程、开发工作产品和提供。定“项目管理”过程的服务,分配责任和权限.

GP 2.5培训人员

  必要时,对执行或支持“定量项目管理”过程的人员进行培训。

   详细说明;

培训专题的例子有:

●过程建模和分析;

●过程度量项目选择、定义、数据采集和确认。

2.8管理配置项

把“定量项目管理”过程的指定的工作产品置于配置管理的适当屡次.

详细说明:

置于配置管理之下的工作产品的例子有:

●将要包含在项目已定义过程中的子过程:

●度量项目操作定义、在子过程中度量数据的采集点以及如何确认度量数据;

●所采集和验证的度量数据,包括变化的特殊原因。

   GP 2.7确定相关的共利益者并使之介入

  按计划“定鼻定量项目管理”过程的相关的共利益者并使之介入。

  详细说明:

需要共利益者介入的活动的例子有:

●建立项目目标;

●解决项目质量和过程性能目标之间的问题

●评估所选择的子过程的性能

●识别并管理在达到项目的质量和过程目标的过程中的风险

●采取纠正措施

 

2.8监督和控制该过程

对于“计划监督和控制”定量项目管理矗过程,并且采取适当的纠正措施.

详细说明:

在监督和控制“定量项目管理”过程方面的各项活动中使用的度量项目的例子有:

●子过程的统计管理概貌(例如,策划纳入统计管理的子过程的数量、正在进行统计管理的子过程数量、统计意义上稳定的子过程的数量):

●所识别的特殊变化原因的数量。

  

GP 2.9客观地评价情况

  对照适用的要求、目标和标准,客观评价“定量项目管理”过程以及该过程的工作产品和服务的遵循情况,并且处理不符合项.

  详细说明:

被审查的活动的例子有:

●用质量和过程性能目标对项目进行定量管理:

●对项目已定义过程中所选择的子过程进行统计管理.

被审查的工作产品的例子有:

●项目已定义过程中包含的子过程

●度量项目的操作定义

●所采集并经过验证的特殊变化原因中的度量数据。

 

GP2.10高层管理者审查状态

    高屡管理者审查“定量项目管理”过程的活动、状态和结果,并解决问题.

GG 3制度化为已定义过程把该过程作为已定义过程加以制度化。

    GP 3.1建立已定义过程

    建立并维护一个已定义的“定量项目管理,,过程的描述.

    GP 3.2收集改进信息

    收集那些派生于“定量项目管理”过程的策划和执行的工作产品、度量项目和改进信息,用以支持本组织的过程和过程财富的进一步使用和改进。

GG 4制度化为定量管理过程

    把该过程作为定量管理的过程加以制度化.

    GP 4.1建立质量目标

    根据顾客需求和组织业务目标,为“定量项目管理”过程的质量和过程性能建立定量目标并予以维护。

    GP 4.2使子过程性能稳定

    使“定量项目管理”过程的一个或几个子过程的性能稳定下来,进而确定该过程在实现所规定的定量目标和过程性能目标方面的能力。

GG 5制度化为持续优化过程

  把该过程作为持续优化过程加以制度化。

  GP 5.1  确保不断的过程改进

    确保膏定量项目管理”过程不断得以改进,以适应本组织的有关的总体业务目标。

  GP 5,2解决问题的共性原因

    识别并解决“定量项目管理”过程中的缺陷和其他问题的根本原因.

6.4工程化类过程

    工程化类过程方面覆盖的是那些在整个软件工程共享的开发和维护惯例。本模型为工程化类程设定的6个过程方面彼此间有着内在关联关系。这些关联关系来源于产品的开发过程,而不是因为这些过程方面隶属于软件工程类。

    在本模型中,工程化类的6个过程方面是:需求开发“需求管理”技术解决:产品集成“验证”确认。 这些工程化类过程方面把各个软件工程过程综合成一个面向产品的过程改进场景。对产品开发过程的改进是以业务目标为其目标,而不是只针对软件工程本身。这种综合软件工程过程的方式将有效地避免本组织的管理中孤立对待的“烟囱”倾向。这些工程化类过程方面适用于工程开发领域中任何产品或服务(例如软件产品、服务或过程)的开发    图8是各个工程化类过程方面之间交互作用的概念性视图。

SJ 11234-2001(1) 软件过程能力评估模型_5

图8工程化类过程方面交互作用关系   

    产品或服务的开发始于顾客的需要、期望和限制条件。“需求开发”过程识别顾客的需要并且把这些需要转换成产品需求集合。对这个产品需求集合进行分析,产生一个高层次概念解决方案。  进一步往下层分解(有时可能有几层)直到确定特定产品构件为止。然后把这些需求分配给产品构件,作为产品构件需求的组成部分。派生出有助于定义产品的其他需求并分配给产品构件。就开发者而言,产品和产品构件的这些需求清楚地说明理解和使用哪些产品的性能、设计特征、验证要求等等。

    把顾客需要转换成产品需求的工作涉及到基本的功能体系结构的进一步演变。这种基本的功能体系结构把产品需求赋予各个功能实体。这种体系结构演变始于对功能分解的需要,以描述出有待开发的产品而告结束。

    “需求开发”过程方面还为“技术解决”过程方面提供需求,在“技术解决”过程里,使各项需求覆盖产品体系结构、产品构件设计和产品构件本身(例如编码)。这种信息被传递给。产品集成”过程'在“产品集成”过程里,把各个产品构件加以组合,并且保证各个产品构件的界面满足“需求开发”过程提出的要求。

    “需求管理”过程方面维护各项需求。它描述关于获得和控制需求变更的各个惯例,描述那些用于确保其他有关的计划和数据保持现行有效的惯例。“需求管理”过程方面还给出对顾客需求、产品需求和产品构件需求的溯源性。

    “需求管理”过程方面确保对需求的变更能反映到项目计划、活动和工作产品上。这种变更循影响到所有其他的工程化类过程方面,因此,需求管理是一个动态的和经常性的事件递归链。

建立和维护“需求管理”过程是受控的、有纪律的工程设计过程的基础。

    “技术解决”过程方面开发产品构件技术数据包并且实现产品构件,供“产品集成,,过程使用。期望对提出的各种解决方案进行检查,以便按照规定的准则选择出最佳的设计方案。对于不同的产品来说,这些准则可能有很大区别,具体准则取决于产品类型、操作环境、性能要求、支持要求以及成本或交付进度要求。在选择最终解决方案的过程中,将使用“决策分析和决定。过程方面中的一些惯例。为了在设计期间和在最终完成产品构造之前实施设计验证和同行审查,“技术解决”过程依赖于“验证”过程方面里的一些惯例。

    “验证”过程方面确保所选择的工作产品满足规定的需求。在“验证”过程中要拟订验证策略,以确保充分验证。这种验证策略应该密切结合“技术解决力过程和“产品集成”过程。通常,这种验证过程是一个逐步提升的过程,从产品构件验证开始,到整个组装完成的产品的验证结束。

    “验证”过程方面还涉及同行审查。同行审查是一种减少产品开发和维护中的缺陷的验证方法,同行审查有助于了解正在开发和维护的产品和产品构件。

    “确认”过程方面是对照顾客的需要对产品进行确认。可以在操作环境或模拟的操作环境中进行确认。这个过程方面的一个最重要的元素是与顾客一起协调确认要求和确认策略。

    “确认”过程方面的范围包括对产品、产品构件和过程的确认。产品、产品构件或过程往往要求重新验证和重新确认,因此与其他工程化类过程方面的关系很密切。在确认中发现的问题通常要在“需求管理”或“技术解决”过程里解决。

“产品集成”过程方面确定的惯例涉及到生成最佳集成策略、集成产品构件和向顾客交付产品。在实施“产品集成”过程时,“产品集成”过程既要运用“验证”过程方面的惯例又要运用“确认”过程方面的惯例。“验证”过程是在产品集成之前验证产品构件之间的接口和接口需求。这是“产品集成’”过程方面中的一个基本事件。当产品在操作环境中集成时,要运用“确认”过程方面的惯例。

    “产品集成一过程方面涉及必要的测试,以便确保恰当的功能性能和可接受的物理属性。对产品进行验收测试之后才包装、发运.所编写的这些工程化类过程方面被都支持过程在整个产品体系结构中的递归;但是没有为递归过程的应用安排特定惯例.各个惯例的编写方式是“期望”过程在产品体系结构中应用。模型给出一套通用程度很高的期望惯例,适用于任何产品细节层次,而不是分别开列出“使某某过程能实施递归一的惯例,因此使用起来更方便。这种一般性有很多优点。例如,可以把工程化类过程方面运用予某种具有若干产品构件层次的产品,处理每个层次的产品构件,因此,可一用同一个模型来评估某个很大的项目的各种不同的分段.

6.4.1需求管理

    “需求管理”的目的在于管理对项目的产品和产品构件的需求并且识别这些需求与项目计划和项目工作产品的不一致之处。

  术语“需求”指的是由项目接受的或项目产生的产品和产品构件需求,包括由组织征集的对项目的需求。这种需求既有技术性的,也有非技术性的。“需求管理”过程方面中的惯例是经过批准的现行需求的来源;项目类过程方面的所有惯例按这些需求行动。

  项目采取适当的步骤以确保达成一致的需求受到管理,从而支持项目的策划和执行。当某个项目从某个批准的需求提供者处接收需求后,要与需求提供者一起审查这些需求,以便在把这些需求纳入项目计划之前解决误解问题或防止误解。在需求提供者与需求接收者之间达成一致之后,也就从项目的各个参加者那里得到了对这些需求的承诺:项目参加者必须开展各个项目活动和实现各项需求。随着项目的推进,项目经理将对这些需求进行调整,并且识别出存在于计划和工作产品与这些需求之间的不一致之处。

  对需求的管理是要捕捉需求变更和变更的理由,并且维持对原有需求和所有产品和产品构件需求的双向跟踪。

“需求管理”过程与“需求开发”和“技术解决”过程密切合作;“需求开发”涉及到把共利益者的需要转换成产品需求和决定如何在各个产品构件之间安排或分配需求。,需求管理”过程方面里的各个惯例应该与“需求开发”和“技术解决”过程方面里的惯例同时实施。

有关的过程方面

 关于把共利益者器要转换成产品需求.和决定如何在各个产品构件闯安排或分配需求的更多,信息,参见“需求开发”过程方面。

    关于把需求转换威技术解决方案的更多的信息,参见“技术解决”过程方面。

    关于项耳计划如何随着需求的变更而反映修改的需求的更多的信息,参见“项目策划”过程方面。

    关于针对这些需求建立配置管理文件基线和控制其变更的更多的信息,参见材配置管理”过程方面。

    关于对以这些需求为基础的各项活动和工作产品的跟踪和控制的更多的信息,参见“项目监督和控制”过程方面。

特定目标

GP 1管理需求

  对需求进行管理并设别出需求与项目计划和工作产品之间的不一致之处.

通用目标

GG1实现特定目标

    谈过程通过可识别的输入工作产品转换成可识别的输出工作产品,以支持该过程方面的特定目标并且使之能实现制度化为受管理过程。

    把该过程作为受管理过程加以制度化.

GG 3制度化为已定义过程

    把该过程作为已定义过程加以制度化.

GG 4制度化为定量管理过程

  把该过程作为定量管理过程加以制度化.

GG 5翻度化为持续优化过程

  把该过程作为持续优化过程加以制度化.

与目标对应的特定惯例

SG1管理需求

    对于求进行管理并识别与项目计划和工作产品之间的不一致之处.

    这个特定目标针对总的项目生存周期为项目提供经过批准的现行需求,管理所有对这些需求的变更,确保从两个方向把握这些需求与受到它们影响的其他实体之间的关系,并且识别这些需求与项目计划和工作产品之间的不一致。发现不一致之后,将产生相应的纠正措施。这些需求可能是总的产品需求的一个子集,也可能就是总的产品需求.

  关于确定这些需求的灵活性的更多的信息,参见过程方面。

  关于确保需求反映顾客的需要和期望的更多的信息,参见“需求开发”过程方面。

  SP  1. 1-1求得对需求的理解

    设法理解需求提供者提出的这些需求的含义.

    随着项目的成熟和各项需求的派生,所有各项活动或工程学科都要接受相应的需求。

    为了避免这些需求的漫无边际地外延或者“遗漏”,要建立-些准则,用以指明接收需求的适当的渠道或正式来源。接收需求的活动应该是与需求提供者一起对需求进行分析的活动,以确保对需求的含义达成共识。分析和对话的结果是达成一致的需求。

    典型工作产品

    1.  区别适合的需求提供者的准则。

    2.  确定是否理解了需求的准则。

    3.  对照准则进行分析所得的结果。

    4.  达成一致的需求。

    子惯例

    1.  制订用于识别适合的需求提供者的准则。

    2.  制订用于接收需求的目标准则。


这些准则的确例子有:

●需求的说明清楚、恰当;

●需求的说明完备;

●需求之间彼此一致;

●需求不重复;

●适宜于实现

●可以验证(例如,可以测试)

●可以跟踪

3.分析需求,以保证满足所制订的准则

    4.  与需求提供者达成共识,以便项目的各个参加者能够对它们作出承诺。

SP l.2-2求得对需求的承诺

    从各个项目参加者处求得对需求的承诺,

    关于监督所傲的承诺的更多的信惠,参见“项目监督和控制”过程方面。

    即使某个惯例以前达到了与需求提供者对需求的共识,但是现在实施这个惯例的时候还是要在那些必须进行各项为实现这些需求所需的活动的人员之间达成一致和作出承诺。在整个项目推进中,特别是在“需要开发”和“友幕确切”过程方面的各项活动进行中,需求可能会演变。随着需求的演变,要求在所有相关的共利益者之间对已批准的现行需求和项目.计划、活动及工作产品中的后续变更作出承诺。

    子惯例

    1.  评估各项需求对现行承诺的影响。

    当需求发生变更或提出了新的需求时,要评价它们对项目各个参加者的影响。

  2.记录承诺。

SP l.3-1管理需求变更

  随着各项需求在项目推进期间发生演变的同时,对需求的变更进行管理.

    关于维护和控制需求基线以及使需求和需求变更的数据为项目可用的更多的信息,参见“配目管理”过程方面。

    在项目推进期间,需求会由于各种各样原因而发生变更。随着需求的变更和工作的推进,将会产生一些附加的需求,因此必然要对现行的需求作出相应的变更.有效地管理这些需求和需求变更相当重要。有必要了解每个需求的来源并且把作出变更的理由形成文件.不过,项目经理可能希望跟踪相应的需求变化度量数据,以便判断是否需要新的控制或对已有的控制作出调整。

  典型工作产品

  1.需求状态:

  2.  需求数据库;

  3.  需求决策数据库。

  子惯例

  1.  收集赋予项目的或者由项目产生的所有的需求或需求变更.

  2.  维护需求变更的历史数据及变更理由。

维护变更的历史数据有助于跟踪需求的变化情况。

   3.  从相关的共利益者的角度出发评价需求变更的影响。

    4.  使需求和需求的变更数据可供项目使用。

SP l.4-2维护对需求的双向溯源性

    维护需求与项目计划和工作产品之间的双向溯源性.

    这个特定惯例的目的在于维护对每个产品分解层的双向溯源性。如果需求管理得好,就可以建立起双向溯源性:一个是从来源需求到比它的层次低的需求的溯源性,另一个是从比它层次低的需求到它的来源需求的溯源性。这种双向溯源性有助于确定是否所有来源需求都已经完全得到处理,是否所有的低层需求都可以溯源到有效的来源。需求的溯源性还可以覆盖与其他实体的关系,例如与产品、设计文件的变更、测试计划、验证、确认以及工作任务等的关系。溯源性应该覆盖横向和纵向(例如界面两边)的关系。在评估需求变更对项目计划、活动以及工作产品的影响时,尤其需要溯源性。

    典型工作产品

    1.  需求溯源性度量项目目。

    2.  需求跟踪系统。

    子惯例

    1.  维护对需求的溯源性,以确保抓得住低层(派生)需求的来源。

    2.  维护某个需求与它的各个派生需求的需求溯源性,以及从需求分配到功能、目标、人和过程的需求溯源性。

    3.  维护需求的从功能到功能的横向溯源性和跨接口的纵向溯源性。

    4.  生成需求溯源性度量项目目。

SP l.5-1识别项目工作与需求之间的不一致

  识别项目计划和工作产品与需求之间的不一致之处.

    关于监督和控制项目计划工作产品需求是否一致的更多的信息,参见“项目监督和控制”过程方面。

    虽然通过这项活动产生的一些工作产品将成为经过更新的项目计划、活动和工作产品,但是,这些工作产品是“项目策划”过程的产品,而不是“需求管理”的。这个特定惯例旨在发现需求与项目计划和工作产品之间的不一致,并且启动纠正措施。

    子惯例

    1.  审查项目计划、活动和工作产品,看其是否与需求和需求变更一致。

    2.  识别不一致的来源和理由。

    3.  识别由于对需求基线的变更而导致的对项目计划、活动和工作产品必需作出的变更。

    4.  启动纠正措施。

与目标对应的通用惯例

GG 1  实现特定目标

  该过程通过把可识别的输入工作产品转换成可识别的输出工作产品支持实现此过程方面的特定目标并且使之能够实现。

  GP l,1确定工作范围

    针对“需求管理”过程,确定所要执行的工作的范围和所要产生的工作产品的范围,并且把这些信息传达给将要执行该工作的人.

  GP l.2执行基本惯例

    执行“需求管理”这个过程方面的基本惯例,以开发工作产品和提供服务,以便实现该过程方面的特定目标.

GG 2制度化为受管理过程

    把该过程作为受管理过程加以制度化。

    GP 2.1建立组织方针

    为策划和执行“需求管理”过程,制订并维护组织方针.

    详细说明:

    这个方针要确定组织的如下期望:对需求进行管理并且识别需求与项目计划和工作产品之间的不一致之处。

    GP 2.2策划该过程

    为执行“需求管理”过程,制订并维护需求、目标和计划。

    详细说明:

    这些需求、目标和计划一般是按“项目策划”过程方面所述在项目计划中描述。

    GP 2.3提供资源

    为了执行所镶划的过程、开发工作产品和提供“需求管理”过程的服务,提供足够的资源。

详细说明:

用于执行“需求管理”过程方面的活动的工具的例子有:●需求跟踪工具;

●源性工具

 

GP 2.4分配责任

  为执行该过程、开发工作产品和提供“需求管理”过程的服务,分配责任和权限.

GP 2.5培训人员

    必要时,对执行或支持“需求管理”过程的人员进行培训。

详细说明:

培训专题的例子有:

●应用于领域

●需求定义、分析、审查和管理

●需求管理工具;

●配置管理

●协商和解决矛盾

GP 2.6管理配置项

    把“需求管理”过程的指定的工作产品置于配置管理的适当层次.

详细说明:

置于配置管理之下的工作产品的例子有:

●需求

●需求溯源性度量项目

 

1809
国家标准下载

下载说明:
1.请先分享,再下载
2.直接单击下载地址,不要使用“目标另存为”
3.压缩文件请先解压
4.PDF文件,请用PDF专用软件打开查看
5.如果资料不能下载,请联系本站
最新评论
发表评论
大名:
联络: QQ 或者 邮箱
内容:不能超过250字,需审核,请自觉遵守互联网相关政策法规。

验证码: 6465