随着软件工程知识的普及，软件工程师都知道，要开发高质量的软件，必须改进软件生产的过程。目前，业界公认由CMU/SEI开发的软件能力成熟度模型SW-CMM是当前最好的软件过程，并且CMM已经成为事实上的软件过程工业标准。但是，CMM虽然提供了一个有力的软件过程改进框架，却只告诉我们"应该做什么"，而没有告诉我们"应该怎样做"，并未提供有关实现关键过程域所需要的具体知识和技能。为了弥补这个欠缺，Humphrey又主持开发了个体软件过程(Personal Software Process，PSP)。

　　在CMM1.1版本的18个关键过程域中有12个与PSP有关，据统计，软件项目开发成本的70%取决于软件开发人员个人的技能、经验和工作习惯。因此，一个单位的软件开发人员如能接受PSP培训，对该单位软件能力成熟度的升级是一个有力的保证。CMM侧重于软件企业中有关软件过程的宏观管理，面向软件开发单位，PSP则侧重于企业中有关软件过程的微观优化，面向软件开发人员。二者互相支持，互相补充，缺一不可。

　　按照PSP规程，改进软件过程的步骤首先需要明确质量目标，也就是软件将要在功能和性能上满足的要求和用户潜在的需求。接着就是度量产品质量，有了目标还不行，目标只是一个原则性的东西，还不便于实际操作和判断，因此，必须对目标进行分解和度量，使软件质量能够"测量"。然后就是理解当前过程，查找问题，并对过程进行调整。最后应用调整后的过程，度量实践结果，将结果与目标做比较，找出差距，分析原因，对软件过程进行持续改进。 

　　就象CMM为软件企业的能力提供一个阶梯式的进化框架一样，PSP为个体的能力也提供了一个阶梯式的进化框架，以循序渐进的方法介绍过程的概念，每一级别都包含了更低一级别中的所有元素，并增加了新的元素。这个进化框架是学习PSP过程基本概念的好方法，它赋予软件人员度量和分析工具，使其清楚地认识到自己的表现和潜力，从而可以提高自己的技能和水平。

一、个体度量过程PSP0和PSP0.1

　　PSP0的目的是建立个体过程基线，通过这一步，学会使用PSP的各种表格采集过程的有关数据，此时执行的是该软件开发单位的当前过程，通常包括计划、开发（包括设计、编码、编译和测试）以及后置处理三个阶段，并要作一些必要的试题，如测定软件开发时间，按照选定的缺陷类型标准、度量引入的缺陷个数和排除的缺陷个数等，用作为测量在PSP的过程中进步的基准。

　　PSP0.1增加了编码标准、程序规模度量和过程改善建议等三个关键过程域，其中过程改善建议表格用于随时记录过程中存在的问题、解决问题的措施以及改进过程的方法，以提高软件开发人员的质量意识和过程意识。

　　应该强调指出，在PSP0阶段必须理解和学会使用不合格进行规划和度量的技术。设计一个好的表格并不容易，需要在实践中积累经验，以准确地满足期望的需求，其中最重要的是要保持数据的一致性、有用性和简洁性。

二、个体规划过程PSP1和PSP1.1

　　PSP1的重点是个体计划，引入了基于估计的计划方法PROBE（PROxy Based Estimating），用自己的历史数据来预测新程序的大小和需要的开发时间，并使用线性回归方法计算估计参数，确定置信区间以评价预测的可信程度。PSP1.1增加了对任务和进度的规划。

　　在PSP1阶段应该学会编制项目开发计划，这不仅对承担大型软件的开发十分重要，即使是开发小型软件也必不可少。因为，只有对自己的能力有客观的评价，才能作出更加准确的计划，才能实事求是地接受和完成客户（顾客）委托的任务。

三、个体质量管理过程PSP2和PSP2.1

　　PSP2的重点是个体质量管理，根据程序的缺陷善建立检测表，按照检测表进行设计复查和代码复查（有时也称"代码走查"），以便及早发现缺陷，使修复缺陷的代价最小。随着个人经验和技术的积累，还应学会怎样改进检测表以适应自己的要求。PSP2.1则论述设计过程和设计模板，介绍设计方法，并提供了设计模板、但PSP并不强调选用什么设计方法，而强调设计完备性准则和设计验证技术。

　　实施PSP的一个重要目标就是学会在开发软件的早期实际地、客观地处理由于人们的疏忽所造成的程序缺陷问题。人们都期盼获得高质量的软件，但是只有高素质的软件开发人员并遵循合适的软件过程，才能开发出高质量的软件，因此，PSP2引入并着重强调设计复查和代码复查技术，一个合格的软件开发人员必须掌握这两项基本技术。

四、个体循环过程PSP3

　　PSP3的目标是把个体开发小程序所能达到的生产效率和生产质量，延伸到大型程序；其方法是采用螺旋式上升过程，即迭代增量式开发方法，首先把大型程序分解成小的模块，然后对每个模块按照PSP2.1所描述的过程进行开发，最后把这些模块逐步集成为完整的软件产品。

　　应用PSP3开发大型软件系统，必须采用增量式开发方法，并要求每一个增量都具有很高的质量。在这样的前提下，在新一轮开发循环中，可以采用回归测试的方法，集中力量考察新增加的这个（这些）增量是否符合要求。因此，要求在PSP2中进行严格的设计复查和代码复查，并在PSP2.1中努力遵循设计结束准则。

　　从对个体软件过程框架的概要描述中，可以清楚地看到，如何作好项目规划和如何保证产品质量，是任何软件开发过程中最基本的问题。

　　PSP可以帮助软件工程师在个人的基础上运用过程的原则，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控制和管理自己的工作方式，使自己日常工作的评估、计划和预测更加准确、更加有效，进而改进个人的工作表现，提高个人的工作质量和产量，积极而有效地参与高级管理人员和过程人员推动的组织范围的软件工程过程改进。

　　PSP软件工程规程为软件工程师提供了发展个人技能的结构化框架和必须掌握的方法。在软件行业，开发人员如果不经过PSP培训，就只能靠在开发中通过实践逐步掌握这些技能和方法，这不仅周期很长，要付出很大的代价，而且有越来越大的风险。 培训的方式有很多，既可以到专门的学校进修，也可以进行自学和参加培训班，例如：CMM网校中就有个体软件过程的课程。
 
五、个体软件过程PSP之过程改进

      PSP是一个需要逐步改进的过程。

      Watts S. Humphrey服兵役的时候，必须学会机枪射击。开始训练时用猎枪打泥鸽子，Watts的成绩非常差，并且努力训练还是没有提高。教官对Watts进行了一段观察后，建议他用左手射击。作为一个习惯右手的人，开始Watts很不习惯，但练了几次后，Watts的成绩几乎总是接近优秀。

     这个事例说明了几个问题。首先，要通过测量来诊断一个问题，通过了解Watts击中了几只鸽子和脱靶的情况，很容易看出必须对Watts做些调整。然后，必须客观的分析测量的数据，通过观察Watts的射击，教官就可以分析Watts射击的过程—上膛、就位、跟踪目标、瞄准，最后射击。教官的目的就是发现Watts哪些步骤存在问题，找到问题所在，于是建议目的就是发现用左手射击。

     最后，也是最重要的，就是自身的变化。过程改进是非常困难的，因为人们很多时候不愿意尝试新事物。他们传统的习惯看起来很自然，以至于不相信改变会有什么帮助。Watts总是使用右手，从来没有想过左手射击会是什么样子。但是自Watts采纳了教官的建议，他的成绩就提高了。

     定义测量方法不是件容易的事情，但它总是可能的。首先定义测量方法。规定了测量方法后，就必须收集和分析数据。如果需要作些改进，接下来就要分析工作过程，看看什么地方需要改进。最后要想真正的改进，必须切实做出改进。

     如果Watts不改进他的射击过程，它的成绩几年后都不会有什么变化，也不会成为一个优秀的枪手。仅仅进行测量并不会产生什么提高，仅仅靠努力也不会有什么提高。在很大程度上工作方式决定了所得到的结果。如果还是按照老办法工作，得到的结果还会是老样子。

     改进工作方式与Watts学习射击的步骤一样。它们并不复杂，如图1所示：

六、个体软件过程PSP之时间管理

1、时间管理的逻辑原理

     人们很可能像上星期那样安排这星期的时间。当然，随着工作的不同，也有很多例外的情况。

     为了制定切实可行的计划，必须对所用的时间进行跟踪。如果问上周的时间是怎么利用的，一般人都认为很容易所出每项工作花了多少时间，但是当看到实际的数据时，很可能感到十分惊讶：花在编程上的时间比估计的少得多，花在消遣的时间比预期的多得多；乐意做的事情做的特别快，用的时间也似乎特别少，令人头疼的事情占用的时间似乎比实际花费的时间多得多。要搞清楚时间都用在什么地方，必须对时间进行跟踪，保留一份准确的记录。

     为了检查时间估计和计划的准确性，必须把它们写成文档并在今后与实际情况进行比较。做计划是一种技能，学习制定好的计划，第一步就是要先做计划，然后把该计划写下来，以便今后与实际数据相比较。

     为了制定出更准确的计划，需要知道以前的计划中存在哪些错误，哪些地方可以进行改进。当按照计划进行工作时，记录下所花费的时间。通过比较文档化的计划和实际的结果，就可以发现计划中存在哪些错误以及如何改进做计划的过程。制定准确计划的关键就是要坚持制定计划，并把每个计划与实际结果相比较，然后就会知道如何才能制定出更好的计划。

     为了管理好时间，首先制定时间分配计划，然后按照计划去做。制作计划容易，但真正实施计划是困难的。特别开始的时候，按照计划进行工作可能比较困难，你可能会有很多借口，最常见的就是这份计划制作的不好。但只有按照计划去做，你才能知道它的优劣。

     按照计划进行工作有三点好处：第一，了解计划存在哪些问题，有助于更好的计划下一个项目。第二，按照好的计划完成工作。这看起来不重要，但是事实上软件工程中的许多错误都是由于考虑不周、粗心大意或是不注意的小细节而造成的，按照好的计划工作是避免这些错误的最好途径。另一个更加微妙的好处就是它实际上在改变你的工作方式，有了计划就不用浪费时间去考虑下一步要干什么，它会帮助你把精力集中在所中的事情上，很少分心，从而提高了工作效率。

2.了解时间的使用情况
       将主要活动分类。在开始分配时间时，你会发现大部分时间都用在相对很少的几个活动上。

       记录每项主要活动所花费的时间。坚持记录时间需要很强的自我约束能力，要想进行精确的记录，必须记录下每件主要工作开始和结束的时间。除非你知道自己实际上用了多少时间，否则就不可能管理好使用时间的方式。

       用标准的方法记录时间。必须使用标准的时间日志。因为需要采集的时间数据的数量增加得很快，如果不认真记录和存储这些数据，它们很可能丢失或变得混乱，这样很不利于查找或对它们进行解释。如果不打算对这些数据进行适当的整理、归纳，就根本不必要去收集数据。

       以分钟为测量单位。工程是在完成任务中不间断工作的时间一般都少于1小时，因此以小时为单位对工作时间进行测量不能提供用以计划和管理工作所需要的详细数据，而用分钟跟踪时间容易得多。一旦决定进行时间跟踪，用分钟作为测量单位将比用小时更恰当。

       处理中断时间。采用表2.1跟踪时间时，一个常见的问题就是中断。电话、聊天、偶尔的烦恼以及必要的休息打断的次数多得令人吃惊。中断的时间不是有效的工作时间，并且变化幅度很大，如果不对它进行测量，实际上就在时间记录中加入了一个随机数，也就很难使用时间数据来计划和管理时间了。事件日志中的数据能帮助你了解工作被打断的频率。多数中断不仅浪费时间，还会打断你的思路，导致效率降低和错误的产生，因此了解被打断的频率有助于提高工作的质量和效率。

       将时间数据保存在合适的地方。记录时间花费情况值得推荐的方法就是用工程记事本来记录时间以及其他的事情。对一个软件专业人员，工程记事本用途很多，可以记录时间日志、程序设计方案以及运算结果，可以作为你所遵循正确的工程实施方案的凭证，可以记录下脑子里面一闪而过的想法。推荐的方法是从工程记事本的第一页开始向后记录主要活动及其所花费的时间，最后一页开始向前记录时间日志。记录主要活动及其所花费的时间，最后一页开始向前记录时间日志。

       周活动总结表。通过采用时间日志收集时间数据后，你就能渐渐明白自己是如何支配时间的。但是时间日志中的数据过于详细，需要用一种更有用的表格来总结这些数据，周活动总结表能够很好的完成这个任务。当然我们关心的时间不会只有一周这么短，还需要一段时间内在各类任务上花费的平均时间、最大时间和最小时间。因此采用表2.2所示格式。周活动总结表中的数据可以帮助你了解时间都用在那些地方，还可以使用这些书对以后的几周进行计划。例如，有了这些数据就能判断出一个大的任务所需要的时间可能接近总结表中的最长时间，而一个简单的任务需要的时间可能接近最短时间。

       记录时间的提示。随时准备好工程记事本；当偶尔忘了记录开始时间、结束事件或中断时间，凭记忆尽早作出估计；及时总结记录的时间数据。

七、个体软件过程PSP之制订计划

1、如何制定阶段计划

       这里介绍两种计划：阶段计划和产品计划。阶段计划是关于这段时间内对时间的安排，产品计划是关于制作产品活动期间的时间安排。以读一本书为例来说明阶段计划和产品计划的区别。为了计划这项工作，首先估计出整个任务应花费多少时间。例如，你可能希望用20小时阅读全书20章的内容。对于这个任务来说，产品计划就是以20小时读完全部书为目标，阶段计划就是每周安排1小时读书这种方式。下图表示了业务领域中产品计划和阶段计划的关系。

   为了制定阶段计划，必须清楚时间的使用情况。根据上一章介绍的周活动总结表，我们就可以跟踪记录自己是如何支配时间的。在制订下一周的计划时，就可以参考最近的周活动总结表。根据以前各个任务花费的时间，就能判断出下一周将在这些任务上花费多少时间。制定这种计划最简单的方法就是假设将要使用的时间与过去平均使用的时间相同。一种较为精确的方法就是首先考虑下周将要做的工作内容，然后根据以前的最长和最短时间来估计出一个合适的时间。

2、如何制定产品计划

       当工程师在项目小组中工作时，就需要计划个人的工作。计划是按期完成承诺的任务的可靠基础，可以在工程师合作开发产品过程中协调他们的工作，可以帮助工程师了解项目的状态。做计划是软件工程师工作的一个重要部分，要成为一个有才干的工程师，就必须知道如何制订准确的计划，也需要知道如何将这些计划与实际结果相比较，从而学会制定更好的计划。

制定产品计划是可以通过事件加以提高的一种技能。从现在开始对每个产品制订计划，产品可以是一个可制定的程序、一个程序设计方案或是一个测试计划，并在以后的项目中继续这样做下去。

收集历史项目数据。对于工程人员，一个产品计划包含产品规模、工作时间和进度三方面的估计。最基本的产品计划只包括对任务或作业所需时间的估计。通过收集以前不同任务所用时间的数据，就能够估计将来类似的任务大概所需要的时间。表3.1是为了记录每个项目估计时间和实际时间而设计的作业编号日志，参考这些历史项目数据，我们可以方便、准确地作出估计。准确的估计是做好计划的关键。

     估算程序规模。产品计划的第一步是要估计产品的规模。对于程序来说，可以使用代码行测量方法估计新程序的规模。为了准确的估计，需要用到以前的规模数据，因此把以前的规模数据按照功能分类是有帮助的。首先查看新程序的需求，估计各类代码有多少行，然后与以前统计的数字进行比较，可以得出开发新程序需要多少时间完成。随着所积累的数据越来越多，作出的估计就会越来越准确。作业编号日志作为记录大量的历史的规模和效率数据提供了一种简便的方法，还可以使用表3.2记录不功能类型的程序历史数据，并按照规模排列。

     规模测量的方法很多，应该根据不同的对象使用不同的估计方法，即使对程序来说，代码行测量方法也不能覆盖所有的情况。没有任何方法可以保证估计的结果一定准确，作出好的规模估计的关键是要有大量的历史数据，要进行多次规模估计，并且要定期的将实际结果与估计值进行比较。

3、管理好时间
       可以按照如下步骤管理时间：

1.        分析自己使用时间的历史记录；

2.        制定时间安排表，决定如何使用时间；

3.        对照制定的安排表跟踪使用时间的方式；

4.        决定应该改变什么意思自己的行动达到所作安排的要求。

复查时间的分类情况。周活动总结表给出了每周用在各个活动上的平均时间、最大时间和最小时间。检查一下这些活动的分类，是否有些类别包含的范围过大了，而另一些有分得过细。时间管理的重点放在那些站用大部分时间的少数几项活动上。

作出时间安排。时间安排表是如何使用时间的计划，根据以前如何使用时间的数据，就可以作出计划，分配以后活动所需要的时间，如表3.3所示。

      找出更多的时间。管理好时间的关键是逐步对使用时间的方式进行反复平衡，因为时间每天24小时是固定的。如果希望以后在某些任务多用一些时间，除非能够在另外一些任务中少用一些时间，否则，这常常只是一个愿望而已。

       制定基本规则。我们在做许多事情是都是按照一定的规则去做的。为了对时间进行有效管理，也需要有规则可循。不同的是前些规则是别人制作的，而时间管理必须自己制定这些规则。实际上，时间管理的安排就是为管理自己的时间而制定的规则。时间管理的基本规则：已经决定如何使用时间，就必须切实的按照预定的方式去做；为了切实按照预定的安排去做，就必须有非常具体的计划。表3.4就是位置到每天活动制定的每天时间安排表。

       设定时间分配的优先级。有些时间是固定不点的，如每周例会，可以把这些时间称为固定时间。进行其他活动的时间就是可变动的时间，只要有时间就可以去做这些活动。可变时间又分成需要完成的任务和自行斟酌的任务。需要的活动如编程、读书，虽然是需要的活动，但它们的时间是可变动的，因为无论如何找出时间都可做这些事情，并且每周在这些活动上所用的时间是不同的。自行斟酌的活动就是要做的所有其他的事情：吃饭、睡觉、社交、观看电视及其其他的娱乐活动。

       当作出全面的时间安排时，固定时间的安排是没有什么问题，最常见的问题是分配可变动的时间。列出需要尽快做的事情，首先努力完成最重要的任务。重要的任务推此时，你会不自觉的为这些任务担心，立刻处理这些事情常常是更有效的，并且也将给人们带来一种完成任务的成就感。此外，记住一旦开始了一项令人生畏的任务，就很少会感到象你想象中的那么困难。

可以考虑从自行斟酌的活动中抽出那些额外的时间，但是这需要合理的安排，对个人是否真愿意按照这时间安排来执行。没有休息的时间会导致人们将管理好时间的想法推翻。做时间安排以及跟踪时间是重要的，但是时间安排一定要是自己实际愿意接受的。

       执行时间安排表。按照时间安排表工作的能力很大程度上取决于个人的自觉性，但是它还取决于要做的工作的数量和它们的优先次序。预料不到的时间是生活中很自然并且是很正常的一部分，特别是在软件工程中。危机常常会打破人们的计划，因此不得不作出调整。

在第一次使用时间安排表时，可能会感到它不是很有用，这是正常的，不要因为第一次没有起作用就放弃对时间安排的过程，而是要考虑所发生的事情，看看是否存在一些不可能再发生的反常时间、或者存在对有正常事件引起人而意外花费了很多时间？如果是紧急的情况，不必对时间安排做大的调整，下一周再试着用它，然后复查结果。如果一些经常发生的事情扰乱了安排，应考虑对安排进行改动，为以后类似事情提前做好准备。

       最后，按照时间安排表跟踪实施的性能，要继续收集时间数据。根据经验复查时间安排表，在根据需要和经验修改安排，要逐步的作出改变。在改变时间安排表时，要保存以前的版本。

       时间管理的目标。收集时间是为了帮助自己管理时间。如果收集的数据被证明是没有用的，就需要重新考虑自己收集时间数据的方法。但是，只有在已经实践了安排的时间之后再这样做。记事作了时间安排表，如果由于一些原因对时间安排变化很大，那么也应该收集更多的数据，知道自己明白当前是如何使用时间为止。

八、个体软件过程PSP之缺陷管理

1、什么是缺陷

      缺陷是指程序中存在的错误，例如语法错误、标点符号错误或者是一个不正确的程序语句，是任何影响程序完整而有效的满足用户要求的东西，是可以表示、描述和统计的客观事物。

       有人把缺陷称为Bug，这是不正确的。当成为Bug时，令人想到的是那些令人讨厌的小虫子，应该把它们拍死或者不予理睬。这会使一些重要的问题被视为琐碎小事，会养成一种错误的态度。缺陷并不像无足轻重的Bug，更像是定时炸弹。大家可能会觉得有些夸大其词，绝大部分细小的缺陷没有引起严重后果。然而不幸的是，很小一部分看起来无关紧要的缺陷却能引起严重问题。虽然现在缺陷对你来说还不是一个严重问题，但很快就会成为一个重要的问题。

       设计错误的复杂性和所导致的缺陷的影响没有之间关系，一些微小的编码错误却可能引起严重的系统问题。事实上，绝大多数软件缺陷都源于程序员的疏忽大意。

为了减小缺陷，就必须进行缺陷管理，研究已经引入的缺陷，确定引起这些缺陷的原因，并学会在将来如何避免重复同样的错误。

       缺陷分类。在分析缺陷时，将缺陷进行分类是有帮助的。通过缺陷分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷，这就是缺陷管理的关键。把精力集中到最容易引起问题的几类缺陷上，一旦这几类缺陷得到控制，在进一步找到新的容易引起问题的几类缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。

       不要急于把10种类型的每一类细分出若干子类，直到你已经搜集到大量程序的缺陷数据。那时，才能够看出哪里需要更详细以及补充什么样的信息才是最有用的。

       统计缺陷个数。采用缺陷记录日志，记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。人们很容易对缺陷辩解，但是要管理好缺陷，就必须收集有关缺陷的准确数据。如果原谅缺陷，那只会自欺欺人。如果你这样做的话，就别指望有所提高。

2、缺陷查找技术

      为什么要尽早发现缺陷。不要期望一个简单拼凑出来的满是缺陷的程序，经过修改可以成为一个合格的产品。一旦生产出一个有缺陷的程序，它将永远是有缺陷的。虽然你可以修复所有已知的问题，并且让它通过所有的测试，但它还是一个有许多不定的有缺陷的程序。如果工程师能宽容有缺陷的工作，他将生产出低质量的产品。“我们忙，以后在修补吧”，这样的态度不可能出产出优质产品。

      发现和修复缺陷的费用。在典型项目中，产品被分成很多小的模块，由不通的工程师负责开发。在模块设计、实现、编译后，工程师作初始的单元测试；单元测试后，多个模块组成一些大组件进行集成测试；经过各种级别的组件测试后，这些组件集成为产品进行产品设计；最后，将产品集成到系统中进行系统测试。随着系统的规模和复杂程度不同，单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同，但几乎所有规模的软件产品，都需要这个过程。

      研究证明，开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍。尽管缺陷的修复时间变化很大，但平均时间总是遵循这样的规律，而与缺陷的类型无关。

      发现和修复缺陷的方法。尽管没有办法不引入缺陷，但是在开发过程中尽早发现和修复缺陷还是可能的。有多种发现程序中的缺陷的方法，基本上都包括以下步骤：表示缺陷征兆；从征兆中推断出缺陷的位置；确定程序中的错误；决定如何修复缺陷；修复缺陷；验证这个修复是否已经解决了这个问题。

      有多种工具和辅助手段来帮助完成这些步骤，工程师最常用的工具是编译器，它能够表示出大部分语法缺陷。但是编译器最基本的任务是生成目标代码，并且可能会在源程序有缺陷的情况下生成代码。因此，不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。一般编译器仅提供了缺陷的征兆，你必须自己对问题定位，并确定是什么问题，通常很快能够做到这一点，但偶尔也需要较长的时间

      另外一种常用方法就是上面讲述的测试。测试的质量是由测试用例覆盖所有程序功能的程度决定的。测试可以用来验证程序几乎所有的功能，但有自己的缺点：同编译器一样只能满足缺陷派出的第一个步骤，你仍必须从缺陷征兆找出问题的根源，然后才能修复；随着项目规模的扩大，全面的测试会花费大量的时间，要进行完全测试几乎不可能的。

      最有效的发现和修复缺陷的方法是个人复查源程序清单。这种方法是负很难彻底清除程序中的缺陷，但事实证明，这是最快而且最有效的方法。

3、代码复查

      代码复查就是研究源代码，并从中发现错误。代码复查更有效的原因是：在复查时看到的是问题本身而不是征兆。从头到尾复查代码时，考虑的是程序应该做什么。因此，当看到某些地方不正确时，就可以看到可能的问题是什么，并立即去验证代码。复查的缺点是：非常耗时，而且很难恰当的进行；复查时一种技能，当然可以通过学习和实践来提高。

      代码复查的第一步是了解自己引入的缺陷的种类，这是收集缺陷数据的主要原因。因为在下一个程序中引入的缺陷种类一般会与前面的基本类似，只要采用同样的软件开发方法，情况会一直如此。另一方面来说，当你有了技能和经验或改变了过程，缺陷的类型和数目会随之变化。但是到了一定程度后，改进就变得非常困难了。这是，就必须研究缺陷，这可以帮助你找到更好的发现和修复缺陷的方法。

      如何进行代码复查。代码复查的目标是在软件过程中尽可能早和尽可能多的发现缺陷，缺陷发现时间越少越好。采用表4.3描述的一个有序的检查方法，在编译之前进行代码复查，是完成目标最好的方法。

      编译之前进行复查。有几个原因说明应在编译之前进行代码复查：不论编译前或编译后，进行完整的代码复查的时间大约相同；不论编译前或编译后，对检查语法有效性的效果是一样的；先做复查将节省大量编译时间，若不做代码复查，一般要花12％～15％的开发时间进行编译，一旦使用代码复查后，编译时间可以缩短至3％或更少；编译程序后，代码一般复查很难彻底的进行； 经验证明，在编译阶段有大量的缺陷时，一般在测试阶段也有许多缺陷。

      建立个人代码复查检查表。如果想发现和改正程序中的每一个缺陷，就必须遵照一个精确的规程。检查表可以确保遵循这个规程，它包括一系列程式的步骤。按照检查表去作时，就知道如何进行代码复查。

      如果能够正确使用检查表，还能知道每个步骤发现了多少缺陷。这样就能测量出复查过程的效率，并进一步改进检查表。检查表包括了个人的经验。通过不断的使用和改进个人检查表，就可以帮助你用较少的时间发现这些缺陷。表4.4是一个C++程序代码复查表的范例。

       定期更新检查表。随着时间的推移，检查表自然的要变大。但是，检查表的主要作用是帮助你把注意力集中在关键的方面。太大以后，你将失去重点。所以要定期复查缺陷数据，删除那些不能找到问题的表项。

       从个人检查表的方法可以认识到，每个工程师都有各自的特点，某个工程师的实践经验对别人不一定适用。因而要设计出适合自己的检查表，并定期的对它进行检查以保证检查表更有效。只要你在代码复查中还遗漏缺陷，就要不断寻找改进检查表的方法。

       进展是很缓慢的。最初，你发现缺陷的能力随着每次复查都有所提高。此后，提高将变得很困难。要坚持收集和分析缺陷数据，并坚持思考如何才能预防缺陷的产生或怎样更好的找到缺陷。只要坚持不断的做下去，就能在代码复查中不断进步，不断提高自己编写程序的质量。

      编码标准。编码标准是被广泛接受的、能够作为工作样板的编码实践集。良好的编码标准将有效地帮助您避免开发有潜在危险的代码，有助于预防缺陷。例如，可以在编码标准中列出那些应该避免使用的方法，规定号循环入口或在说明是初始化变量，避免不良的变量命名等。编码标准还能有效地统一和规范整体开发活动。当其他开发人员加入到项目中来时，他们能够很好地适应这一切。代码也将变得更规范更易维护。

      其他种类的代码复查。在软件组织中，一种常用的方法是同行评审，就是几个工程师彼此复查程序。组织良好的同行评审一般会发现程序中50％～70％的缺陷。互查虽然需要很多时间，但是可以有效发现缺陷，因为工程师往往难于发现自己的设计错误。他们创作这个设计，直到程序应该完整什么，即使概念有瑕疵、作了错误的设计或实现假定，他们往往很难发现。检查这可以帮助他们克服这些问题。对一个大的项目，最佳检查策略是，先做个人代码复查再进行编译，然后在任何测试前进时行同行检查。

      细心工作是有回报的。当工程师觉得对自己开发的程序附有质量责任时，他就不会依赖于编译器或其他工具来发现缺陷。全面的代码复查要花费时间，但是他们节省出来的时间比花费的时间多得多，并能够生产出更好的产品。

4、缺陷预测

      引入缺陷是人类的正常现象，所有的工程师都会引入缺陷。因此所有的工程师都应该了解自己引入缺陷的类型和数据。

      在开发过程中，总是可再进行一轮测试或代码复查，决定是否这样做的唯一方法就是分析缺陷数据。通过分析历史数据，可以估计出程序中缺陷的个数。通过把当前项目的数据和估计数据相比较，就能大概知道正在开发的程序的质量情况。这样就能决定是否需要增加一些缺陷排除步骤。

      缺陷率的预测。当开发一个新的程序时，可能会觉得很难估计你将引入多少缺陷，理由是缺陷的个数因程序的不同而不同。缺陷个数不稳定是有以下几个原因造成的。首先使经验问题，个人的技能是在不断提高的。开始编程序时，要面临着很多以前没有碰到过的问题。往往不能确定有些过程和函数是如何执行的，可能是语言的结构不清楚或者可能会遇到新的编译器或编程环境的问题。这些问题都会引起开发时间和缺陷路的波动。有了经验后，你将逐渐克服这些问题，犯的错误就减少了。这既减少缺陷的总数又减少缺陷数目的波动。缺陷的减少起初是由于经验的增加和对语言熟练程度的提高。经过这最初的提高后，就需要收集和分析缺陷数据来进一步改进了。

      缺陷路波动的第二个原因是个体过程不稳定。当开始学习写程序时你也同时开始学习使用新的过程和方法。你的过程将随着实际的经验不断的发展，这就会引起完成不同程序任务的时间和引入缺陷的数据的波动。

      最后，缺陷本身也是这种变化的原因，引入的缺陷越多，修复这些缺陷所花时间就越长。修复缺陷所花的时间越长，引入新的缺陷的几率也就会增加。因此缺陷的修改时间变动幅度很大。所以，很难对一个引入很多缺陷的过程进行预测。

      随着开发过程的改进，过程会逐步稳定下来。这种稳定将提高缺陷预测的准确性。试验证明，如果在代码复查方面花了足够的时间，你的过程会迅速稳定下来。一旦你的过程相当稳定，缺陷也将容易预测。

      根据对最近的程序跟踪每千行引入和排除的缺陷数，就可估计出在将来的程序中可能引入和排除的缺陷数。

　　那么PSP和TSP到底是什么?

　　人员成本占了软件开发成本的70%，软件工程师的技能与工作习惯很大程度上决定了软件开发的过程。而使用PSP的工程师有一个规范的和结构化的方法来开发软件。这些经受训的工程师的习惯是真正能被用到新的不断变化的技术上的。PSP指导工程师如何在工作一开始就管理好质量，分析每项工作的结果，如何运用来改善下一个项目的流程。当工程师知道如何运用跨领域和方法论的方式来度量并管理他们自己的工作时，他们就能够成功地沟通、学习新技能、获取新技术以及参与到高绩效的团队中。PSP 是要引进TSP的组织的先决条件。

　　团队软件过程(TSP)加上PSP帮助高绩效的工程师在一个团队中工作，来开发有质量保证的软件产品，生产安全的软件产品，改进组织中的过程管理。通过TSP，一个组织能够建立起自我管理的团队来计划追踪他们的工作、建立目标，并拥有自己的过程和计划。这些团队可以是纯粹的软件开发团队，也可以是集成产品的团队，规模可以从3到20个工程师不等。TSP 团队在广泛领域里可能运用XP, RUP或其它方法。TSP使具备PSP的工程人员组成的团队能够学习并取得成功。如果你的组织运用TSP，它会帮助您的组织建立一套成熟规范的工程实践，确保安全可靠的软件。

　　PSP、TSP在行业中的应用及效果

　　CMMI是领先的系统集成和软件组织用来评价和改进他们管理过程与能力的一种标准。在中国已经有许多组织通过或正在进行CMMI的咨询与评估。PSP/TSP的实施能促进过程改进所能带来的收益，同时也能加速企业通过CMMI的各级评估，更重要的是，PSP/TSP还能将改进的结果持续保持下去。

　　PSP不仅是SEI等国际知名大学或软件学院中学生的必修课程，同时在各行业中也有广泛的应用。全世界有越来越多的企业实施了PSP/TSP来增强企业的竞争力，其中软件企业有Microsoft，Quarksoft， BAAN，Intuit，Advanced Information Services，Teradyne等，还有诸如集成电路，系统集成等行业的公司，如:ABB, Honeywell ，Motorola，Allied Signal，Boeing，XEROX等。

　　PSP、TSP的实施，为这些组织在软件质量，成本控制等方面带来的显著的成效。微软，作为全球最大的软件供应商，最近有一个项目试运行了SEI个人软件过程(PSP)和团队软件过程(TSP)，使一个软件开发团队改变行为、改进过程、从而交付更好的软件。

　　TSP塑造团队。在使用TSP之前，该团队有10个开发人员，他们对项目、工作、甚至彼此之间都没有信心。该团队成员的工作只是彼此独立的进行，而不是作为一个团队来进行的，没有协作。在TSP项目实施了4天后，这组人成为了一个真正的团队。

　　TSP 降低缺陷，改进质量，节省成本。在TSP培训中，微软开发人员的单体测试缺陷从超过25个缺陷/千行代码显著降低到7个缺陷/千行代码。微软的团队，如其他的软件开发团队一样，耗费40-60%的整体开发时间在测试上，因为他们用这些时间来发现并解决产品的缺陷。但是，由于微软的TSP试运行团队花时间在早期的缺陷移除活动上，如个人评审和团队检查，他们的测试只用了整个项目工作量的11.5%。最终，该试运行项目组按时将产品交付给了测试，并且是高质量的。这使得项目节省了35% 的成本。

　　PSP、TSP与CMMI模型的紧密结合将成为必然趋势

　　正如CMM/CMMI的创始人Watts humphrey所说的，未来对于软件工程团队交付产品的质量、及时性和成本控制的要求越来越高，无法达到这些要求的企业及个人都将被淘汰。鉴于PSP、TSP目前为止在各大企业的实施效果，PSP、TSP与CMMI模型的紧密结合将成为必然趋势。

　　作为开发人员，通过PSP的培训课程，能够学到软件过程管理和项目管理方面最先进的技能和最佳实践管理，从而提高他们的项目质量，改进预估和计划能力，同时减少产品缺陷。通过PSP培训的个人还能够获得SEI授权的PSP培训证书，这无疑也是提升工程师个人职业发展空间和价值的极好机会。

　　作为开发团队，TSP的实施能够在较短时间内建立高绩效的团队，能够确保团队开发产品的质量、安全性，更好地计划并控制项目时间与成本，从而改进组织的过程管理。

　　从整个企业角度来看，所有经验证明PSP、TSP能加速CMMI在企业范围内的实施，同时也是维持改进的需要。在众多世界知名企业开始实施PSP、TSP的情况下，中国的软件组织要提高自身的国际竞争力，PSP，TSP是必经之路，不仅帮助提升了企业的对外形象和国际认知度，为能为企业带来更大的竞争优势。

　　循序咨询帮助企业构建高绩效团队

　　循序咨询在运用CMM、CMMI模型帮助客户通过过程改进最终实现其商业目标方面已经拥有了多年的成功经验，并已拥有众多长期客户，包括上海宝信软件、博科软件、西安交大博通、中远资讯、SONY 电子、联合汽车电子、安满能、PFU、铂金中国、新致软件、南京日恒、浙大网新中研等一批知名国际和国内软件开发及集成企业。在多年成功经验的基础上，发现将SEI的PSP、TSP理念引入中国，并结合CMMI可全方位并快速的帮助企业建立高绩效的团队。从而使组织自管理层到基层员工步调一致，加快企业实现其商业战略目标。

　　循序除了拥有SEI授权的CMMI主任评估师以外，还有唯一常驻中国的SEI授权PSP/TSP讲师及咨询顾问。如果您的企业已经通过了CMMCMMI评估，将帮您的改进结果维持得更长久;如果您的企业正在进行过程改进如CMM/CMMI项目，PSP/TSP无疑将促进您在改进过程中获得的收益;如果你正打算开始进行过程改进，那从PSPTSP开始，将大大提高您改进的速度和效率。

Abstract

This paper describes the practical application of the Personal Software Process (PSP) in supporting the implementation of the Capability Maturity Model (CMM). The CMM is a process maturity framework designed to improve an organization’s process capability [Paulk 1993]. The PSP is a proven technique to improve the individual engineer’s performance and productivity [Humphrey 1995]. The benefits of using the bottom-up PSP methodologies to supplement CMM Level 2 Key Process Areas (KPAs) are described.

Content

1.0 Overview of the Capability Maturity Model(CMM)

2.0 Overview of the Personal Software Process(PSP)

3.0 Supplementing the CMM with the PSP

4.0 A PSP based Software Project Planning Process

5.0 A PSP based Software Project Tracking and Oversight Process

6.0 Benefits of the PSP-CMM approach

7.0 Conclusions

Appendix A: References

1.0 Overview of the Capability Maturity Model(CMM)

After two decades of unfulfilled promises about productivity and quality gains from applying new software methodologies and technologies, industry and government organizations are realizing that their fundamental problem is the inability to manage the software process [DoD 1987]. In 1987, the Software Engineering Institute (SEI) designed an organization assessment model that later developed into the Capability Maturity Model (CMM) [Paulk 1993].

The CMM is a framework that characterizes an evolutionary process improvement path toward a more mature organization. An organization can use the CMM to determine their current state of software process maturity and then to establish priorities for improvement. An organization's current state of maturity can be categorized as Initial, Repeatable, Defined, Managed, or Optimizing.

Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few process are defined and success depends on individual effort

Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier success on projects with similar applications.

Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organizations. All projects use an approved, tailored version of the organization's standard process for developing and maintaining software.

Managed: Detailed measures of software process and product quality are collected. Both software process and products are quantitatively understood and controlled.

Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies [Humphrey 1995].

The following chart graphically displays the relationships between each of the CMM maturity levels and also shows the Key Process Areas (KPA) associated with each level:

The CMM defines five maturity levels and each level is composed of several key process areas. Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capabilities [Humphrey 1995]. The following are descriptions of each KPA’s purpose as defined in the CMM [Paulk 1993]:

The purpose of Requirements Management is to establish a common understanding between the customer and the software project of the customer’s requirements to be addressed.

The purpose of Software Project Planing is to establish reasonable plans for performing the software engineering and for managing the software product.

The purpose of Software Tracking and Oversight is to provide adequate visibility into actual progress so that the managers can take effective actions when the software project’s performance deviates significantly from the software plan.

The purpose of Software Subcontract Management is to select qualified software subcontractors and manage them effectively.

The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and the products being built.

The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project through out the project’s software life cycle.

The purpose of Organization Process Focus is to establish the organizational responsibilities for software process activities that improve the organization’s overall software process capability.

The purpose of Organization Process Definition is to develop and maintain a usable set of software process assets that improve process performance across the projects and provide the basis for cumulative, long-term benefits to the organization.

The purpose of Training Program is to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently.

The purpose of Integrated Software Management is to integrate the software engineering and management activities into a coherent, defined software process that is tailored from the organization’s standard software process and related process assets, which are described in the Organization Process Definition.

The purpose of Software Product Engineering is to consistently perform a well defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.

The purpose of Intergroup Coordination is to establish a means for the software engineering group to participate activity with the other engineering groups so the project is better able to satisfy the customer’s needs effectively and efficiently.

The purpose of Peer Reviews is to remove defects from the software work products early and efficiently.

The purpose of Quantitative Process Management is to control the process performance of the software project quantitatively.

The purpose of Software Quality Management is to develop a quantitative understanding of the quality of the project’s software products and achieve specific quality goals.

The purpose of Defect Prevention is to identify the cause of defects and prevent them from recurring.

The purpose of Technology Change Management is to identify beneficial new technologies (i.e., tools, methods, and processes) and transfer them to the organization in an orderly manner.

The purpose of Process Change Management is to improve continually the software processes used in the organization with the intent of improving quality, increasing productivity, and decreasing the cycle time for product development.

The CMM represents a substantial gain in the understanding of software engineering processes and lays the ground work to help organizations develop their own processes that will continually improve over time. Its objectives, goals, and activities are designed to institutionalize organizational structure and policies. However, it does not address what tools, techniques, and methodologies an engineer should use in order to implement and ultimately satisfy the policies. The CMM does lay the ground work for personal methodologies by providing an organizational structure but it does not directly address the requirements of the individuals. This personal gap between the CMM and the individual software engineers will continue to exist until organizations can:

• Identify Key Process Areas that can be performed by the individual
• Define a subset of the CMM that will be useful to a small development team

2.0 Overview of the Personal Software Process(PSP)

The Software Engineering Institute has developed a Personal Software Process [Humphrey 1995] that addresses the gap that exists between the Capability Maturity Model and the individual.

The PSP has a process evolution framework similar to the CMM. The PSP partially addresses 12 of the 18 KPAs defined in the CMM. The following figure shows the CMM along with its key process areas and those areas that are partially addressed in the PSP have been noted with an asterisk.

In order to develop high quality software, each individual component that is integrated into the overall product must also be of high quality. The overall strategy of the PSP is to make sure all the individual components are of high quality. The PSP accomplishes this by providing a defined personal process framework that the software engineer can use to:

• Develop a plan for every project / component
• Record their development time
• Track their defects
• Retain their data in project summary reports
• Use their data to plan future projects / components
• Analyze their data to evolve their processes
• To improve their performance

2.1 PSP0: The Baseline Process

This is the initial stage the personal software process. Its fundamental objective is to document the engineer’s personal process as it exist today. This baseline will provide a consistent basis for measuring progress. Additionally, it provides a defined structure on which to improve. The only modification that the engineer does to his own process at this level is to record measures of performance. The PSP guides this data gathering by providing standard forms and templates. This initial phase is very similar to the CMM initial level of maturity. This reemphasizes that fact that the PSP and CMM approach Software Process Improvement in a similar way, but from different perspectives (Top-Down or Bottom-Up).

2.2 PSP1: The Personal Planning Process

PSP1 supplements the Baseline Process by the addition of software planning activities. These activities are geared toward elucidating the relationship between the size of programs and the amount of time that is needed to develop them. This is accomplished by developing a plan and estimating the resources required. After the completion of the project, the plan’s estimated metrics are compared to actual metrics that were gathered over the project’s life span. The comparison of this statistical data allows the engineer to gain insight into his own software process. This knowledge allows them to produce more accurate estimates. Additionally, it allows them to begin to manage their personal software process and improve those areas that will result in the largest gains.

2.3 PSP2: The Personal Quality Management Process

An early PSP objective is to help engineers to deal realistically and objectively with the defects they inject. These defects are usually syntax or simple semantic errors that even the most seasoned software engineer will commit. The amount of time that is required to track down and fix these errors can become extreme in very large and complex projects. PSP2 ,the Personal Quality Management Process, addresses this critical issue through defect management. Defect data collection started in PSP0, The Baseline Process. With this information engineers construct and use checklists for design and code review. This allows the software engineer to focus on those personal areas that are causing problems. With the checklist they can effectively review design and code while modifying the checklist as their own Personal Software Process improves.

2.4 PSP3: The Cyclic Personal Process

The Cyclic Personal Process is the final level in the PSP. Its purpose is to scale up the PSP2, the Personal Quality Management Process, for use on large scale projects. One of the fundamental problem solving approaches in science is Divide and Conquer. This refers to taking a complex problem and subdividing it into smaller more manageable pieces. This is the fundamental concept that is behind PSP3. The following figure illustrates this:

The strength of this approach is that each sub-module is designed as a full PSP 2 project. Fundamentally, the PSP was designed to aid in the development of high quality software. If each module is designed to meet this requirement, then integration of each individual component into the overall product will also satisfy the requirement.

3.0 Supplementing the CMM with the PSP

The CMM is a framework that characterizes an evolutionary process improvement path toward a more mature organization. The CMM is comprised of five maturity levels, each containing several KPAs. All KPAs in the CMM have the following features:

The CMM is intended to be a high-level description of very complex software processes and thus should be viewed as a guideline and its goals should be considered as key criteria. An organization is considered to have reached a certain maturity level if it can demonstrate that it satisfies all of the goals for all KPAs at that level. The SPI must be designed to institutionalize the organizational policies of the CMM and at the same time give the engineers the tools, techniques and methodologies needed to implement the policies.

It is a fact, that a Software team is made up of individuals, and they are the ones that actually get the work done. It is at this lower level of abstraction that the benefits of software engineering practices will be most productive. The day-to-day operation of an organization rest on the shoulders of the individuals who construct, build, and implement the company's future. The CMM lays the ground work for personal methodologies, but it does not directly address the requirements of the individuals. This Personal Gap can be mitigated if the SPI is supplemented with the PSP.

One of the fundamental difficulties in designing a SPI initiative using the CMM, is that the model describes what to build but not how to build it. For example, the CMM can be thought of as a blueprint for a house. It tells the construction worker where the load bearing walls, support beams, and trusses should be placed in order to construct a stable house. The problem is that the carpenter may not know how to build a truss or what constitutes a state of the art of truss.

The following demonstrates this difficulty in implementing the CMM KPA of Software Project Planning:

The above describes many aspects of what makes up a good Software Project Planning process. With this description an organization would be hard pressed to implement an effective project planning process. There exists issues that are not covered in the CMM that could severely impact the overall effectiveness of the SPI initiative like the following:

• What can we estimate besides schedule?
• Is the size of the software produce related to the effort needed to build it?
• How do we generate estimates from previous experience?
• What should be included in a project’s development plan?
• What constitutes a "good" project plan?
• How do we measure the status of the software planing activities?
• Why do we need to measure anything?

The Software Engineering Institute developed the PSP [Humphrey 1995] to addresses these and other important issues that exist in the Capability Maturity Model. The PSP is a bottom-up approach to Software Engineering which focus on the individual software engineer, their personal practices, and how they relate to an organization wide Software Process Improvement plan. In the context of the house building example, the PSP describes what issues are involved in building a truss and offers directional support in its construction.

The underlying philosophy is that the CMM is a top-down approach to improving an organization’s ability to engineer software. If an organization trains its software engineers and project managers in the PSP, using A Discipline for Software Engineering [Humphrey 1995] as the training textbook, then the organization as a whole will have a better understanding of the key issues in implementing many of the CMM related initiatives.

4.0 A PSP Based Software Project Planning Process

A Software Project Plan documents estimates for the work to be performed, the necessary commitments, and defines a plan to perform the work. One of the most important factors in satisfying the Key Process Area of Software Project Planning, is that the process of constructing, documenting, and maintaining the Software Project Plan must be in compliance with the Capability Maturity Model. The PSP can help form a subset of these software processes in a highly integrated manner. The following chart graphically displays the relationship between the PSP and the CMM based Software Project Planning processes:

The Preliminary Design Phase is undertaken after the Software Requirements Specification (SRS) is completed. In this phase the software development team constructs a high level design which can include Entity Relationship Diagrams (ERD), Data Flow Diagrams (DFD), and Data Dictionaries. After the high level design is completed, inspected, and baselined, the project manager divides the design into individual components that are suitable for an individual PSP trained engineers to work on. These components are then given to the PSP engineer who use their own defined personal process to estimate size, time, and effort required for implementation of the component. After all components have been estimated in this faction, the information is passed back to the project manager. The Software Project Plan is developed by integrating the individual estimates for all of the components of the high level design.

5.0 A PSP Based Software Project Tracking and Oversight Process

The Key Process Area of Software Project Tracking and Oversight focus on management’s ability to determine project status. In order to provide adequate visibility into the process of developing software, actual results and performances must be tracked against the Software Project Plan. When the actual results and the plan significantly differ, correction action should be taken. One way to perform this type of detailed tracking is with earned value project scheduling.

Earned value (EV) tracking is a mechanism to evaluate the progress of a project [Boehm 1981]. EV works by establishing a value for each task in the software project plan. This value represents the percent of effort required to complete the task relative to the overall project effort. The EV tracking mechanism provides a common value scale for each task regardless of the type of work involved. As each task is completed, the project will be awarded that task’s earned value and when the project reached 100% earned value, then all of the planned tasks are completed.

The following chart graphically displays the relationship between the PSP and the CMM based Software Project Tracking and Oversight processes:

As mentioned earlier in this paper (section 3.0), The Software Project Plan is developed by integrating the individual estimated for all of the components of the high level design. In the Critical Design / Code / Test phase, each of these components is implemented by engineers performing full PSP 2.1 cycles on the components. Each engineer tracks to completion each of the implementation tasks with earned value. This low level earned value is then passed back to the project level via weekly or monthly project status update meetings.

Project level earned value can be constructed in one of two ways depending on the granularity of tracking that is required by the project: Component Level earned value or Engineer Level earned value.

Component Level earned value

The project can track component level earned value by defining an earned value task to be the completion of a PSP 2.1 Cycle. Once the engineer has completed the implementing of a component (When the engineers earned value is 100%) then the project is awarded the earned value associated with the component.

Engineer Level earned value

The project can track the engineering level earned value by defining an earned value task to be the completion one of the PSP phases of the PSP 2.1 cycle (Planning, Design, Implementation, Testing, Postmortem). Once the engineer has completed a PSP phase, the project is awarded the earned value associated with the phase.

This type of low level earned value tracking can greatly increase the visibility into the process of developing software. This type of an approach allows the project to track earned value not only at the project level but also at the individual engineer level. The complexity of defining a software process to calculate earned value is masked by the PSP since the process is already defined for the engineering level.

6.0 Benefits of the PSP-CMM approach

The focus of this paper is on the organizational benefits of using the PSP to supplement the CMM Level 2 Key Process Areas. This support can be divided into to sections: Engineer Level Support and Project Level Support. Even though an examination of Engineer Level Support is beyond the scope of this paper, the following is a brief summary of results from an excellent technical report on the PSP’s impact on individual engineers [Hayes 1997]:

• Effort estimates improved by a factor of 1.75
• Size estimates improved by a factor of 2.5
• Product quality, the percent of defects found before compile, increased by 50%

6.1 Project Level Support: Case Study

In 1992, Advanced Information Services Inc. (AIS) realized the need for a paradigm shift in the way that they developed software. AIS is an independent software contracting organization with offices in Peoria and Northbrook, Illinois and a subsidiary in Madras, India. AIS has successfully adopted and institutionalized the CMM and PSP into their defined software process, which has been internationally acknowledged by their selection as a finalist for the 1997 IEEE Computer Society Award for Software Process Improvement.

The effect of an organizational CMM - PSP software process improvement effort is visible in the following chart. The implementation of the CMM provided measurable improvements in AIS’s ability to provide "Faster, Better, Cheaper" software. The inclusion of the PSP further refined the fidelity of the AIS Defined Process and has been successful in sustaining continual improvement.

This chart show the Schedule predictability, as measured by the number of months late, of developmental projects at AIS. The x-axis represents the start data of each of the projects that are plotted. The chart is divided into 3 sections:

• 1988-1992. This represents the time period when AIS did not have a defined software process.
• 1992-1995. This represents the time period when AIS utilized CMM based software process.
• 1995-1997. The represents the time current time period as AIS follows CMM based software process that include the PSP.

There is obviously a dramatic improvement in schedule predictability that is associated with the introduction of the CMM based software process. The inclusion of the PSP does not have a large impact of the schedule predictability. The major benefit gained from the introduction of the PSP is evident in the following effort predictability chart:

This chart show the Effort predictability, as measured by the percent of effort deviation of developmental projects at AIS. The x-axis represents the start data of each of the projects that are plotted. The chart is divided into the same 3 sections as the Schedule Predictability chart. The benefits of supplementing CMM based software process with the PSP are clearly evident in the "PSP-CMM Process" section of the effort predictability chart.

The CMM based process had an impact of the Schedule Predictability but did not have the same impact of the Effort Predictability. The reason for this is that the CMM gave the organization the ability to determine the status of the projects and determine if the schedule was slipping. Thus, if a problem was detected then more hours were "donated" to the project in an attempt to maintain the schedule.

It was not until the PSP was introduced that the Effort Deviation experienced a marked reduction. The PSP equipped the individual engineers with the tools and techniques to needed meet their effort estimates. The combination of the CMM and the PSP seems to be an effective way to manage the software process.

7.0 Conclusions

The PSP and CMM are mutually supportive. The CMM provides the orderly support environment engineers need to do superior work, and the PSP equips engineers to do high quality work and participate in organization process improvement [Iyer 1996].

The underlying philosophy is that the CMM is a top-down approach to improving an organization’s ability to engineer software. The PSP is the bottom-up approach that enables the engineers to improve the quality of their software. The combination of these macro and micro methodologies can empowered organization to improve profitability of development projects by meeting cost estimate and schedule commitments with reasonable consistency.

Appendix A: References

[AIS]

Advanced Information Services. 1605 Candletree Dr. Suit 114. Peroria IL USA 61614

[Boehm 1981]

Boehm, B. (1981). Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc.

[DoD 1987]

Report of the Defense Science Board Task Force on Military Software, Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September 1997

[Hayes 1997]

Hayes, W (1997), The Personal Software Process (PSP): An empirical study of the impact of PSP on Individual Engineers. Technical Report, CMU/SEI-1997-97-TR-001, Software Engineering Institute, Carnage Melon University, Pittsburgh, PA.

[Humphrey 1995]

Humphrey, W.S (1997), A Discipline for Software Engineering. Addison Wesley, Reading, M.A

[Iyer 1996]

Iyer, S. (1996), PSP and The Capability Maturity Model. Technical Report, Software Engineering Institute, Carnage Melon University, Pittsburgh, PA.

[Paulk 1993]

Paulk, M.C., Bill Curtis, M. B. Chrisis (1993), "Capability Maturity Model for Software Version 1.1," Technical Report, CMU/SEI-93-TR-24, Software Engineering Institute, Carnage Melon University, Pittsburgh, PA.

　　基于组织对关键过程域的支持，CMM定义了软件过程成熟度的五个级别。级别1（初始级）描述了不成熟，或者说是未定义的过程的组织。级别2（可重复级），级别3（已定义级），级别4（已管理级）和级别5（优化级）分别描述了软件过程成熟度级别递增的组织。和这些级别相关的KPA是：

　　级别2：需求管理，软件项目计划，软件项目跟踪和监控，软件子合同管理，软件质量保证，软件配置管理。

　　级别3：组织级过程焦点，组织级过程定义，培训大纲，集成软件管理，软件产品工程，组间协调，同行评审。

　　级别4：定量过程管理，软件质量管理

　　 级别5：缺陷预防，技术更新管理，过程更改管理

　　 多数组织的基本目标是达到成熟度3级。评估组织当前的成熟度级别的手段之一是软件能力评估（SCE）。SCE通过评估软件过程（一般以方针陈述的形式）和项目实践来确定该组织是否言行一致。组织的过程体现了"如实记录所做的工作"，项目实施（对该过程的特定剪裁和解释）应该证明"说到做到"。

CMMI 综述

　　 软件成熟度模型（CMM v1.0）最早是软件工程学院开发的，并特别提出软件过程成熟度。1990年，该模型首次发布，在许多领域被成功地采纳和使用。其他学科的CMM也相继开发，例如系统工程、人员、集成产品开发、软件采购等等。

　　CMMI被看做是把各种CMM集成为一个系列的模型中。CMMI的基础源模型包括：软件CMM 2.0版（草稿C）, EIA-731系统工程，以及IPD CMM (IPD) 0.98a版。CMMI也描述了5个不同的成熟度级别。

　　 1. 级别1（初始级）代表了以不可预测结果为特征的过程成熟度。过程包括了一些特别的方法、符号、工作和反应管理，成功主要取决于团队的技能。

　　 2. 级别2（已管理级）代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理、以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。

　　 3. 级别3（严格定义级）代表了以组织内改进项目执行为特征的过程成熟度。

　　强调级别2的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。附加的组织级过程域包括：
　　 需求开发：多利益相关者的需求发展。
　　 技术方案：展开的设计和质量工程。
　　 产品集成：持续集成、接口控制、变更控制。
　　 验证：保证产品正确建立的评估技术。
　　 确认：保证建立正确的产品的评估技术。
　　 风险管理：检测、优先级，相关问题和意外的解决方案。
　　 组织级培训：建立机制，培养更多熟练人员。
　　 组织级过程焦点：为项目过程定义建立组织级框架。
　　 决策分析和方案：系统的可选的评估。
　　 组织级过程定义：把过程看做组织的持久的发展的资产。
　　 集成项目管理：在项目内统一各个组和利益相关者。

　　4. 级别4（定量管理级）代表了以改进组织性能为特征的过程成熟度。3级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的。级别4附加的过程域包括：

　　组织级过程执行：为过程执行设定规范和基准。
　　 定量的项目管理：以统计质量控制方法为基础实施项目。

　　5. 级别5（优化级）代表了以可快速进行重新配置的组织性能，和定量的、持续的过程改进为特征的过程成熟度。附加的级别5过程域包括：

　　因果分析和解决方案：主动避免错误和强化最佳实践。

　　组织级改革和实施：建立一个能够有机地适应和改进的学习组织。

CMM过时了吗？

　　一些CMM实践的问题也是传统瀑布方法和过度基于过程的管理的症状。CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系（即：先是需求活动，然后是设计活动，编码活动，单位测试活动，集成活动，以及系统接收测试）。这大概可以解释为什么许多组织对CMM的认识停留在瀑布思想上。

　　另外，叠代开发技术、软件产业最佳实践、和经济动机推动组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。

　　分析CMM 和 CMMI分别和瀑布模型以及叠代开发之间有什么联系，方法之一就是看每个模型的KPA是否为这两种不同的开发方法激发了合理的软件管理原理。首先，让我们来定义那些软件管理原理。过去10年间，我编译了两套原理：一套用于传统的瀑布方法，另一套用于现代的叠代方法。得承认的是，这"十大原理"没有科学基础，并且只提供了符合它们各自的管理方法的成功模版的粗略的描述。但是它们的确为我的观点提供了一个合适的框架：CMM和瀑布思想相联系，而CMMI和叠代思想联系得更紧密。

　　1. 设计之前冻结需求。这是需求第一过程的本质：项目组努力提供一个准确的需求定义，然后严格按照需求实施。需求变更会严重破坏编码和测试阶段，因此，项目组在其他设计和开发活动中投入主要力量之前，必需完整地、明确地指定需求。

　　2. 详细设计评审前避免编码。编码变更会严重破坏编码和测试阶段，在开始编码前，如果还有很多变更阻力，项目组必需保证整个设计是成熟和完整的。

　　3. 是使用更高指令编程语言。更高指令编程语言避免了一系列主要的错误根源（通过先进的数据录入、接口分离以及打包和编程结构），并允许软件方案可以使用更少的人工合成码进行编程。

　　4. 集成前要结束单元测试。虽然设计是自上向下的，测试过程是自下向上的：在交付进行集成测试之前，最小的单元先进行全面测试。这样的次序限制是为了在集成前多发现一些单元级别上的缺陷，否则它们将造成更多的问题和返工。

　　5. 维护所有产品可跟踪性。为了保证在每个阶段维护项目的完整性和一致性，要跟踪需求产品以及设计和测试产品。当提出变更或开发一线人员识别变更时，这提供了变更对评审的实际影响和潜在影响的完整视图。

　　6. 文档化并维护设计。没有文档化的设计就不是设计了。在以后的阶段，由于代码成为主要的工程产品，必须更新设计产品以保证一致性，并为变更决策提供基础。

　　7. 由一个独立小组评估质量。项目组应指定一个独立小组负责保证产品和过程的全面质量一致性，以维护一个有别于分析人员、设计人员和检测人员的独立的报告渠道。

　　8. 全面检查。通过检查详细设计和代码来发现错误，比通过测试发现错误要好得多。要确保检查覆盖所有需求、设计、代码和测试产品。

　　9. 在项目早期进行全面的精确的计划。对于识别关键路径、管理风险以及评估程序变更来说，一个完整的、精确的、细化的计划是必要的，它应该安排整个进度的详细活动和产品。

　　10. 严格控制源代码基线。一旦产品进入编码阶段，就必须用严格的配置管理维护测试过程的正式发布的基线控制，并把产品转换成适合发布的零缺陷状态。

现代（叠代）软件管理的十大原理

　　1. 首先注重结构过程。这要求在组织承诺全面开发的充足资源之前，平衡操作需求、对结构而言很重要的设计决策、以及生命周期计划。

　　2. 用叠代生命周期在早期防御风险。需要一个叠代过程来更好地理解问题，形成有效的方案和有效的计划，以保证平衡对待所有利益相关者目标。应在早期提出主要的风险以提高可预测性，避免为随后的问题和返工付出大的代价。

　　3. 强调基于构件的开发。为了减少人工合成源代码和习惯开发的数量，项目组必须在现存的结构框架内从代码行思想转移到基于构件的思想。构件是已经存在的代码行的附着部分，有已定义的接口和行为，存在于源代码中或可执行格式中。

　　4. 建立变更管理环境。叠代开发的动力学包括并发的工作流，因为不同的工作组都为共享产品工作。这需要客观控制的基线供所有项目成员参阅。

　　5. 用循环工程工具使变更更自由。循环工程提供了各种不同格式（如：需求说明书、设计模型、源代码和可执行代码）的自动工程和同步工程信息所必需的环境支持。如果不使用实质的自动操作，把叠代周期简化为可管理的，允许并鼓励变更的时间框架是很困难的。叠代过程中产品变更自由是必需的，因为它清除了工程组摩擦的一个主要来源。

　　6. 使用严格的、基于模型的设计符号。基于模型的方法（例如：UML）支持语意丰富的图形和文本的设计符号。相对于传统的人工评审和纸张文档的特定设计表现的检查，带严格符号和正式的、机器处理语言的可视模型允许更客观的评估。

　　7. 提供过程的客观质量控制的手段。过程和所有中间产品的生命周期评估必须紧密集成到产品中去，把从展开的工程产品中直接获得的、定义好的度量集成到所有活动和小组中去。

　　8. 使用中间产品的基于演示的评估。把目前的产品状态的产品（不论是早期原型，基线结构，还是β能力）转换成相关的使用案例的可执行演示，以促进集成转换更早发生，对设计权衡的更切实的理解，以及更早消除产品缺陷。

　　9. 发布细化的、展开的计划。在系统的操作语境中，软件管理过程的早期的持续的演示是至关重要的，也就是它的使用案例。每个项目的增加和演示都应该反应目前需求和结构的详细水平。使用案例是组织需求、定义叠代内容、评估实施和组织接收测试的重要机制。

　　10. 建立一个可升级的、可配置的过程。没有哪个过程是适合所有软件开发项目的。现实的说，一个过程框架必须是可配置的，适合大范围的应用软件。为保证经济级别和投资回报，组织必须灌输一个通用过程"精神"，这样所有项目都能集成一系列通用的最好实践，尤其是项目管理、独立于语境的工作流、检查点、度量和产品的最好实践。还应允许各个项目进行剪裁和指定，以便针对项目特定的语境优化过程实施。

　　CMM和两套管理原则的关系 表1识别出每套原则中各有哪些是直接由 CMM的KPA激发的。这些都是我的判断，结合了Rational公司许多同事的观点，但并没有科学依据。另外，请记住这些原则不仅基于CMM，还基于对默认实践的观察和组织级的惯性。

            CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。
            一、CMM的诞生
            信息时代，软件质量的重要性越来越为人们所认识。软件是产品、是装备、是工具，其质量使得顾客满意，是产品市场开拓、事业得以发展的关键。而软件工程领域在1992年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。
            软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。到了20世纪90年代中期，软件管理工程不善的问题仍然存在，大约只有10%的项目能够在预定的费用和进度下交付。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见，软件管理工程的意义至关重要。
           软件管理工程和其它工程管理相比有其特殊性。首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。其次，软件系统复杂程度也是超乎想象的。因为软件复杂和难以度量，软件管理工程的发展还很不成熟。
            软件管理工程的发展，在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代，到90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪，估计到2005年，可以实现真正的软件工业化生产，这个趋势应该引起软件企业界和有关部门的高度重视，及早采取措施，跟上世界软件发展的脚步。软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。
            软件过程改善是当前软件管理工程的核心问题。50多年来计算事业的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。软件管理工程走过了一条从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试到90年代中期以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心向着软件过程技术的成熟和面向对象技术、构件技术的发展为基础的真正软件工业化生产的道路。软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。软件工业已经或正在经历着"软件过程的成熟化"，并向"软件的工业化"渐进过渡。规范的软件过程是软件工业化的必要条件。
            软件过程研究的是如何将人员、技术和工具等组织起来，通过有效的管理手段，提高软件生产的效率，保证软件产品的质量。由此诞生了软件过程的三个流派：CMU-SEI的CMM/PSP/TSP；ISO 9000质量标准体系；ISO/IEC 15504（SPICE）。
    　　CMM/PSP/TSP即软件能力成熟度模型/ 个体软件过程/群组软件过程，是1987年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表的研究成果"承制方软件工程能力的评估方法"；ISO  9000质量标准体系是在70年代由欧洲首先采用的，其后在美国和世界其他地区也迅速地发展起来。目前，欧洲联合会积极促进软件质量的制度化，提出了如下ISO9000软件标准系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年国际标准化组织采纳了一项动议，开展调查研究，按照CMU-SEI的基本思路，产生的技术报告ISO/IEC 15504--信息技术软件过程评估
            目前，学术界和工业界公认美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首主持研究与开发的软件能力成熟度模型CMM是当前最好的软件过程，已成为业界事实上的软件过程的工业标准。
            二、CMM的发展
            1987年美国 Carnegie Mellon  大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表了CMM/PSP/TSP技术，为软件管理工程开辟了一条新的途经。
            CMM框架用5个不断进化的层次来评定软件生产的历史与现状：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。而在某个层次内部，也有成熟程度的区别。在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。因此，一个软件开发单位首先需要了解自己正处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还必须得到保持与发扬。
            软件产品质量在很大程度上取决于构筑软件时所使用的软件开发和维护过程的质量。软件过程是人员密集和设计密集的作业过程：若缺乏有素训练，就难以建立起支持实现成功是软件过程的基础，改进工作亦将难以取得成效。CMM描述的这个框架正是勾列出从无定规的混沌过程向训练有素的成熟过程演进的途径。

           CMM包括两部分"软件能力成熟度模型"和"能力成熟度模型的关键惯例"。"软件能力成熟度模型"主要是描述此模型的结构，并且给出该模型的基本构件的定义。"能力成熟度模型的关键惯例"详细描述了每个"关键过程方面"涉及的"关键惯例"。这里"关键过程方面"是指一组相关联的活动；每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域是指对达到相应软件成熟度等级的目标不起关键作用。归纳为：互相关联的若干软件实践活动和有关基础设施的一个集合。而"关键惯例"是指使关键过程方面得以有效实现和制度化的作用最大的基础设施和活动,对关键过程的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。关键实践一般只描述"做什么"而不强制规定"如何做"。各个关键惯例按每个关键过程方面的5个"公共特性"（对执行该过程的承诺，执行该过程的能力，该过程中要执行的活动，对该过程执行情况的度量和分析，及证实所执行的活动符合该过程）归类，逐一详细描述。当作到了某个关键过程的的全部关键惯例就认为实现了该关键过程，实现了某成熟度级及其以低级所含的全部关键过程就认为达到到了了该级。            　　 
           上面提到了CMM把软件开发组织的能力成熟度分为5个的等级。除了第1级外，其他每一级由几个关键过程方面组成。每一个关键过程方面都由上述5种公共特性予以表征。CMM给每个关键过程了一些具体目标。按每个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例，这个关键过程的各项目标就达到了，也就表明该关键过程实现了。这种成熟度分级的优点在于，这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后顺序。

能力等级	特点	关键过程
第一级 基本级	软件过程是混乱无序的,对过程几乎没有定义,成功依靠的是个人的才能和经验,管理方式属于反应式
第二级 重复级	建立了基本的项目管理来跟踪进度.费用和功能特征,制定了必要的项目管理,能够利用以前类似的项目应用取得成功	需求管理,项目计划,项目跟踪和监控,软件子合同管理,软件配置管理,软件质量保障
第三级 确定级	已经将软件管理和过程文档化,标准化,同时综合成该组织的标准软件过程,所有的软件开发都使用该标准软件过程	组织过程定义,组织过程焦点,培训大纲,软件集成管理,软件产品工程,组织协调,专家审评
第四级 管理级	收集软件过程和产品质量的详细度量,对软件过程和产品质量有定量的理解和控制	定量的软件过程管理和产品质量管理
第五级 优化级	软件过程的量化反馈和新的思想和技术促进过程的不断改进	缺陷预防,过程变更管理和技术变更管理

            对于CMM的作用归纳两个主要方面: 科学地评价软件开发单位的软件能力成熟等级; 帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发效率。

           由于CMM并未提供有关实现CMM关键过程域所需的具体知识和技能，因此，美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发了个体软件过程PSP（Personal software process）和群组软件过程TSP(Team Software Process)，形成CMM/PSP/TSP体系。
            PSP 个体软件过程（Personal Software Process）是由美国Carnegie Mellon大学软件工程研究所(CMU/SEI)的Watts s.Humphrey领导开发的，于1995年它的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。PSP是一种可用于控制、管理和改进个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。
            PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段，PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。PSP保障软件产品质量的一个重要途径是提高设计质量。
            PSP能够说明个体软件过程的原则；帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。
           TSP　群组软件过程TSP(Team Software Process)指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。
            TSP致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。

            CMM是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。企业只有开始CMM改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训,合理分配项目人员,并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。
            PSP能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从而有助于CMM目标的实现。
            TSP结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。
            总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。
            三、实施CMM的必要性
            软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
            软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。
            实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(RE：REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SR：SOFTWARE REUSE)。定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。

            四、CMM在中国的现状
           中国生产力促进协会、北航SEI、中科院研究SEI等科研机构已于近几年在北京、上海、广州和深圳等地先后举办过多次报告会和研讨会，组织过课程学习和应用实验，开展了软件过程方面的研究与开发工作，并发表了多篇的研究成果和学术论文，在软件质量保障平台支撑环境也取得了一定的成果。
           近两年来，CMM在我国获得了各界越来越多关注，业界有过多次关于CMM的讨论，2000年6月国务院颁发的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持和推动作用,第17条规定"对软件出口型企业CMM认证费用予以适当支持。"2000年中国村电脑节上还有CMM专题论坛，吸引了众多业内人士。鼎新、东大阿尔派、联想、方正、金蝶、用友、浪潮、创智、华为、东大阿尔派等大型集团或企业等都从1997---2000年起批企业都在进行研究、实验或实施预评估。其中鼎新公司从1997年着手进行CMM认证工作。1999年7月通过第三方认证机构的CMM2认证。东大阿尔派公司于2000年10月通过第三方认证机构的CMM2认证。2001年1月，联想软件经过英国路透集团的严格评估，顺利通过CMM2认证。2001年6月26日，沈阳东软软件股份有限公司（原沈阳东大阿尔派软件股份有限公司）正式通过了CMM3级认证，成为中国首家通过CMM3级的软件企业。
          总体上讲，国内对软件过程理论的讨论与实践正在展开，目标是使软件的质量管理和控制达到国际先进水平，中国的软件产业获得可持续发展的能力。专家分析，在未来两三年内，国内软件业势必将出现实施CMM的高潮。从这一趋势看，中国的软件企业已经开始走上标准化、规范化、国际化的发展道路，中国软件业已经面临一个整体突破的时代。
          但是我们应该看到目前国内对软件管理工程存在的最大问题是认识不足。管理实际上是一把手工程，需要高层管理人员的足够重视。而且软件过程的重大修改也必须由高层管理部门启动，这是软件过程改善能否进行到底的关键。此外，软件过程的改善还有待于全体有关人员的积极参与。
          除了要认识到过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。过程改善工作需要循序渐进，不能一蹴而就，需要持续改善，不能停滞不前；需要联系实际，不能照本宣科；需要适应变革，不能凝固不变。一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。
            五、CMM体系结构                  
            一个企业软件能力类似于一个人在一个特定领域的能力，是逐步获得和增长的。如果一个人在其领域的发展过程中能得到一个很好的指南，那么他或她就会不断达到一个个设定的目标，并变得成熟起来，否则可能会盲目发展，离自己的目标越来越远，甚至南辕北辙。一个企业的软件能力发展也同样需要一个良好的指南，SW-CMM正是这样一个指南，它以几十年产品质量概念和软件工业的经验及教训为基础，为企业软件能力不断走向成熟提供了有效的步骤和框架。
            框架                  
            SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级实际上是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过这个起点向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一个级别迈进。CMM体系不主张跨越级别的进化，因为从第二级起，每一个低的级别实现均是高的级别实现的基础。
            1.初始级
                 
            初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。
            2.可重复级
                 
            根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
            3.定义级
                 
            在第二级仅定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。
            4.管理级
                 
            第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。
            5.优化级
                 
            第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果一个企业达到了这一级，那么表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

            结构
                 
            除第一级外，SW-CMM的每一级是按完全相同的结构构成的。每一级包含了实现这一级目标的若干关键过程域(KPA)，每个KPA进一步包含若干关键实施活动(KP)，无论哪个KPA，它们的实施活动都统一按五个公共属性进行组织，即每一个KPA都包含五类KP。
            1.目标
                 
            每一个KPA都确定了一组目标。若这组目标在每一个项目都能实现，则说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求，则表明达到了这个级别所要求的能力。
            2.实施保证
                  实施保证是企业为了建立和实施相应KPA所必须采取的活动，这些活动主要包括制定企业范围的政策和高层管理的责任。
            3.实施能力
                 
            实施能力是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的执行活动。实施能力一般包括资源保证、人员培训等内容。
            4.执行活动
                 
            执行过程描述了执行KPA所需求的必要角色和步骤。在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪等。
            5.度量分析
                  度量分析描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。
            6.实施验证
                  实施验证是验证执行活动是否与所建立的过程一致。实施验证涉及到管理方面的评审和审计以及质量保证活动。
                 
            在实施CMM时，可以根据企业软件过程存在问题的不同程度确定实现KPA的次序，然后按所确定次序逐步建立、实施相应过程。在执行某一个KPA时，对其目标组也可采用逐步满足的方式。过程进化和逐步走向成熟是CMM体系的宗旨。
            六、CMM实施的思考
            　　上面重点介绍了CMM,但是提醒注意的是，并不是实施了CMM，软件项目的质量就能有所保障。CMM是一种资质认证，它可以证明一个软件企业对整个软件开发过程的控制能力。按照CMM的思想进行管理与通过CMM认证并不能划等号。CMM认证并不仅仅是在评估软件企业的生产能力，整个评估过程同时还在帮助企业完善已经按照CMM建立的科学工作流程，发现企业在软件质量、生产进度以及成本控制等方面可能存在的问题，并且及时予以纠正。认证的过程是纠正企业偏差的过程，一定不能把CMM认证当作一种考试、一种文凭，而是要看成一项有利于企业今后发展的投资，借此来改变中国软件业长久以来形成的积弊。

            　　实施CMM对软件企业的发展起着至关重要的作用，CMM过程本身就是对软件企业发展历程的一个完整而准确的描述，企业通过实施CMM，可以更好地规范软件生产和管理流程，使企业组织规范化。企业通过CMM不是为了满足其他公司的要求，而是为了让企业更好地发展，为企业进一步扩大规模打下坚实的基础。如果企业只是为了获得一纸证书而通过CMM，那么就已经本末倒置了，对企业的长久发展反而有害。试想如果企业的态度不够端正，即使通过CMM认证，企业又怎么能够保证它在以后的操作过程当中继续坚持CMM规范呢？CMM只是一个让企业更好发展的规范，不应该成为企业炒作自己的工具，企业需要的是优化自己的管理、提高产品的质量，而非一张CMM证书。

            　　CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的，而且CMM并未提供实现有关子过程域所需要的具体知识和技能。在国内要想取得过程改进成功，必须做好以下的几点:软件过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展;中层管理的积极支持;责任分明，过程改进小组的威望高;基层的支持与参与极端重要;利用定量的可观察数据，尽快使过程改进成果可见，从而激励参与者的兴趣;将实施CMM与实施PSP和TSP有机地结合起来;为企业的商业利益服务，并要求同时相符的企业文化变革。
            　　应该看到,过程改善工作必然具有一切过程所具有的固有特征，即需要循序渐进，不能一蹴而就需要持续改善，不能停滞不前；需要联系实际，不能照本宣读需要适应变革，不能凝固不变。将CMM／PSP／TSP引入软件企业最有效的途径首先要对单位主管和主要开发人员进行系统的培训。另外一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。培训包括最基本的软件工程和CMM培训知识；专业领域知识等方面的培训；软件过程方面的培训。不过强调一点，我们必须根据自身的实际制定可行的方案。不深入研究就照搬别的企业的模式是很难起到提高软件产品质量水平的真正目的的。
            　　CMM模型划分为5个级别，共计18个关键过程域，52个目标，300多个关键实践。每一个CMM等级的评估周期（从准备到完成）约需12-30个月。此期间应抽调企业中有管理能力、组织能力和软件开发能力的骨干人员,成立专门的CMM实施领导小组或专门的机构。同时设立软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。各个小组完成自己的任务同时协调其他小组的工作。然后制定和完善软件过程,
            按照CMM规范评估这个过程。CMM正式评估由CMU/SEI授权的主任评估师领导一个评审小组进行，评估过程包括员工培训、问卷调查和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等，评估结束时由主任评估师签字生效。此后最关键的就是根据评估结果改进软件过程,使CMM评估对于软件过程改进所应具有的作用得到最好的发挥。
            　　现在国内软件产业的发展可以说已经具有一定规模了，但除了北大方正、东大阿尔派、用友等大企业外，做软件工程项目更多的是一些规模在数十人左右的中小企业,
            目前处于CMM的初级阶段，没有基础和经验。也许有人会问，像这样一些人力物力资源匮乏的企业，如何进行软件开发项目的管理呢？我建议这些中小企业可以以CMM为框架，先从PSP做起，然后在些基础上逐渐过渡到TSP，以保证CMM/PSP/TSP确实在企业中生根开花。总之，我们必须从软件过程、过程工程的角度来看待CMM的发展，从经济学的观点来分析这个过程的价值。我相信在实施CMM/PSP/TSP的过程中，只要坚持改善软件工程的管理，并在实践中注意总结适合自身的经验，一定能取得很好的效果。

            Initial级，软件过程没有任何标准和规章，完全是手工作坊的方式，软件产品的质量具有不可预测性。            
            Repeatable级，软件制作已基本形成固定过程，并引入了简单的过程管理。软件企业可依据一定的标准重复利用类似的软件产品，以前的开发经验成为开发新产品能否成功的极为重要制约因素。 
            Defined级，软件产品开发和维护的基本过程被记录下来成为文档，软件工程和过程管理也紧密的结合起来，形成了"标准软件过程"。               
            Managed级，针对软件过程的每一个阶段都进行了监控、取样和定量分析，形成了一个关于软件制作和维护流程的数据库并不断更新，以保证软件过程保持较高的质量。               
            Optimizing级，整个软件开发机构的重心转移到优化软件过程。基于Managed级取得的关于软件过程的数据，软件开发机构进行成本收益综合分析，明确软件开发中出现的问题和错误，并找到方法杜绝错误的再次发生。