用-改进过程

2.4.2　用SSE-CMM改进过程

1.改进过程

首先是分析组织环境，组织在第一次定义过程时经常忽视许多内部的过程或产品和/或中间的过程或产品。不过，对于一个组织在第一次定义安全工程过程时并不需要考虑所有的可能性。一个组织应通过适当的精确性来将当前的过程状态确定为基线。基线建立的过程最好在六个月到一年之间，随着时间该过程可以得到改进。

组织必须有一个稳定的基线用以决定未来的变化是否包括过程的改进，对于不实际实现的过程改进是没有意义的。在基线过程中包含当前的“延迟”和“队列”是有用的，在随后的过程改进中，这些是缩短周期的良好开端。

安全工程组织可以由工程师职责作为着眼点来定义过程。这可能包括与系统工程、软件工程、硬件工程及其他科目的接口。

设计符合组织商务要求过程的第一步是，理解当过程实现时需考虑的商务、产品、和组织环境。在使用SSE-CMM设计过程以前，需要回答的问题是安全工程如何在组织中实施？使用什么样的生命期作为过程框架？如何设立组织中的机构来支持项目？如何控制支持功能（如由项目或由组织）？织中谁是管理者，谁是实施者？过程对组织的成功起着怎样的关键性作用？

显然，理解SSE-CMM被应用的文化和商务环境，是成功进行过程设计的关键。

然后是增加角色和结构信息，图2-11说明了设计一个可实行和可支持的过程，需要对SSE-CMM过程区和公共属性的添加因素。为了创建完善的、将来可合理改进的组织层面过程，需要考虑组织机构的环境因素。这些因素包括角色定义、组织结构、安全工程工作产品以及在SSE-CMM通用实施和基本实施指南下定义的生命期。

图2-11　成功的过程设计因素

过程是为了一个指定的目标而执行的一个步骤序列。它是任务、支持工具、涉及产品和某些最终结果（如产品、系统）更新的有关人员组成的系统。由于认识到过程是产品成本、进度和质量的决定性因素之一（其他决定因素为人员和技术），因此各种各样的工程组织开始关注改进它们生产产品过程的途径。

（1）过程能力涉及一个组织的潜在能力

它是一个组织能达到的能力范围。过程性能是项目实际结果的测量，但对于一个特定的项目测量结果有可能落入或不落入到这个范围内。以下是W.Edwards Deming《走出危机》一书的例子论点：“在一个制造工厂，一个经理观察到一个产品生产线的问题。他知道生产线上的人员制造了大量有缺陷的零件。他的第一个做法可以是请求工人更快更努力的工作。但他另一个选择是收集数据并绘制次品比例图。图表显示每天的次品数量及变化是可预知的。”这表明一个系统是处于统计过程的控制中。也就是说，一个特定的范围定义了能力，而且变化的限度是可预知的。存在一种稳定生产有缺陷产品的系统。这个例子表明一个处于统计过程控制的系统并不意味着次品的消失。然而，它意味着以差不多同样的方式重复工作会产生差不多同样的结果。一个重要观点是需要建立一个过程的统计控制以确定在哪方面可以进行对缺陷的改进。许多组织已经使用各种CMM作为帮助他们实现统计过程控制的指南。

（2）过程成熟性表明一个特定过程被清晰定义、管理、测量、控制的程度及有效性

过程成熟性意味着能力增长潜力，并表明一个组织过程的丰富以及在整个组织应用的一致性。Deming与日本人的工作是将统计过程控制的概念应用到工业上。在《刻画软件过程：一个成熟性框架》一书中，Watts Humphrey描述了一个软件过程成熟性框架，此框架解释了如何将Deming的工作成果应用到软件开发过程中。Humphrey认为“虽然有一些重要差异，这些适用于汽车，照相机，手表及钢铁业的概念也同样适用于软件。一个在统计控制下的软件开发过程将在预期成本、进度及质量范围内，产生出期望的结果。”Humphrey把统计过程控制的概念应用到软件过程，他描绘了过程成熟性的级别，这些级别指导组织以小的、渐增的步骤来改进他们的过程能力。这些级别构成了对SEI（软件工程研究所）CMM的基础。CMM是一个框架，它用于将一个工程组织从一个特定的，组织不善、效率不高的状态，进化成高度结构化的且高效的状态。使用这样一种模型是一个组织将他们的活动制约于统计过程控制下的手段，其目的在于提高他们的过程能力。通过使用软件的CMM，许多软件组织都在成本、生产力、进度以及质量上显示了良好的结果。SSE-CMM的开发也是基于这样的期望，即在安全工程中使用统计过程控制概念以促进在预期的成本、进度及质量范围内开发出安全系统和可信产品。

2.期望结果

基于对软件与其他行业的对比，过程和产品的改进的一些结果是可预见的。具体分析如下：

（1）改进可预见性

随着组织的成熟，第一个可期待的改进是可预见性。随着能力的提高，项目目标与实际结果之间的差异将会减少。例如，处于1级的组织通常会很大程度地延误他们项目原始计划的交付日期，而当组织处于较高能力级别时，它应能够以较高的精确度预见项目成本和进度的结果。

（2）改进可控制性

随着组织的成熟，第二个可期待的改进是可控制性。随着过程能力的提高，增加的结果将被用于建立更准确地修订目标。对不同的修正活动的评估可基于当前过程经验和其他项目过程结果，以便选择最好的控制测量应用。因此，具有高能力级别的组织将在可接受的范围内，更有效的控制性能。

（3）改进过程有效性

随着组织的成熟，第三个可期待的改进是过程有效性。目标结果随着组织成熟性的提高而改进。随着组织逐渐成熟，产品开发成本降低，开发时间缩短，生产率和质量提高。低级组织，由于有大量的为纠正错误而重做的工作，因此开发时间会变长。相反，较高成熟级别的组织，通过增加过程的有效性和减少昂贵的重复工作，可缩短整个开发时间。

3.常见误解

下面列举的是一些常见的对使用CMM模型的错误观点。

（1）CMM定义了工程过程

一个通常的错误概念是CMM只定义了一个特殊的过程。而实际上CMM对于组织机构而言是一个如何定义过程，如何随着时间不断改进所定义的过程的指南。无论执行什么特殊的过程都可使用这个指南。对于过程定义、过程管理监控及组织机构的过程改进，CMM给出了什么活动是必须执行的，而不是精确地指定这些特定的活动应如何执行。

面向特定科目CMM（如SSE-CMM），要求执行某些基本的过程活动。这些基本的过程活动是科目中一个部分，但这些模型并不精确地指定这些工程活动应如何执行。

CMM内在基本哲学是让工程组织开发、改进对它们最有效的工程过程。这基于的是一种能力，即在整个组织内定义、文档化、管理和标准化这些工程过程。这个哲学并不注重于任何特定的开发生命期、组织结构或工程技术。

（2）CMM是手册或培训指南

CMM目的在于为组织机构改进他们所执行的特定过程能力（如安全工程）提供一个指南，而不是用来帮助个人改进他们特定的工程技巧的手册或培训指南。CMM的目标是通过采纳CMM中描述的思想和使用CMM中定义的技术指南，来达到组织机构对工程过程的定义和改进。

（3）SSE-CMM是产品评价的替代

用CMM来评价组织级别来代替产品的评估或系统认证是不太可能的。但是，CMM模型无疑能够采取由第三方对CMM评价认为脆弱的方面进行分析。在统计过程控制下的过程并不意味着没有缺陷，而是缺陷是可预见的。因此，抽取一些产品作为样本进行分析仍是必要的。

任何期望通过使用SSE-CMM而获益，都是基于使用软件SEE-CMM经验的理解。为了能使得SSE-CMM起到评价与认证的作用，安全工程业界需要就安全工程中成熟性的含义达成共识。如同软件的SEI CMM，当SSE-CMM在业界继续使用时，评价与认证需不断地研究。

（4）需要太多的文档

当阅读一种CMM时，很容易被过多的隐含过程及计划所淹没。CMM模型包括要求对过程和步骤的文档化，并要求保证执行文档化的过程和步骤。CMM模型要求一些过程，计划以及其他类型的文档，但它并没有明确要求文档的数量或文档的类型。一个简单的安全计划可能适合许多过程区的需要。CMM模型仅仅指明必须文档化的信息类型。

4.获得安全保证

SSE-CMM设计用于衡量和帮助提高一个安全工程组织的能力，但是否可用于提高该组织所开发的系统或产品的安全保证呢？

（1）SSE-CMM项目保证目标

SSE-CMM项目的目标中的三个相对于顾客要求而言特别重要：

●为将顾客安全要求转化为安全工程提供可测量并可改进的方法，以有效地生产出满足顾客要求的产品。

●为不需要正式安全保证的顾客提供了一个可选择的方法。正式安全保证一般通过全面的评价、认证和认可活动来实现。

●为顾客获得其安全要求被充分满足的信心提供一个标准。

对顾客的安全功能和安全保证要求的精确记录、理解、并转化为系统的安全和安全保证需求至关重要。一旦生产出最终产品，用户必须能够检验其是否反映和满足了他们的要求。SSE-CMM特别包括实现这些目标的过程。

（2）过程证据的角色

不成熟的组织可能会生产出高安全保证的产品；一个非常成熟的组织可能由于市场不支持高成本的高安全保证产品而决定生产低安全保证的产品。

无法依据广泛多样的关于产品或系统，满足顾客的安全要求的声明和证据而为安全工程提供保证。组织的SSE-CMM表示产品或系统的生命期遵循特定的过程。这种“过程证据”可被用于证明产品的可信度。

某些类型的证据较另一些证据可更清晰地建立它们支持的声明。与其他类型的证据相比较时，过程证据常常作为支持性的和间接的角色。但是，过程证据可用作为广泛和多样论据，因而其重要性不可低估。进一步说，一些传统形式的证据和这些证据支持的声明之间的关系，也并非如其所说的那样有力，关键在于为产品和系统建立一个综合的论据体系，以确信为什么这些产品和系统是充分可信的。

至少，成熟组织更可能在同等时间和资金的条件下，可生产出适当安全保证程度的产品。成熟组织也更可能更早地识别安全问题，因而避免在发现问题后的实际解决方案不切实际时，牺牲安全保证要求，将安全需求同其他需求一样看待可使作为组织过程整体部分来执行的可能性大大增加。