0有用+1

个人软件过程

播报讨论软件开发表格、指南和规程的结构化框架。PSP与具体的技术（程序设计语言、工具或者设计方法）相对独立，其原则能够应用到几乎任何的软件工程任务之中。PSP能够说明个体软件过程的原则；帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。

中文名: 个人软件过程
外文名: Personal Software Process

简称: PSP
作用: 确定过程的改变影响

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

PSP过程改进模型

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

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

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

CMM/TSP/PSP关系模型

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

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

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

个体规划过程PSP1和PSP1.1

PSP计划示意图

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网校中就有个体软件过程的课程。

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

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

改进工作方式与Watts学习射击的步骤一样。它们并不复杂

表2.1——了解时间的使用情况

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

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

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

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

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

测试计划，并在以后的项目中继续这样做下去。

表3.1——制定产品计划

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

表3.2——制定产品计划

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

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

时间管理的重点放在那些站用大部分时间的少数几项活动上。

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

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

表3.4——每天时间安排表

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

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

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

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

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

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

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

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

软件缺陷都源于程序员的疏忽大意。

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

表4.1——缺陷分类

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

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

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

单元测试；单元测试后，多个模块组成一些大组件进行集成测试；经过各种级别的组件测试后，这些组件集成为产品进行产品设计；最后，将产品集成到系统中进行系统测试。随着系统的规模和复杂程度不同，单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同，但几乎所有规模的软件产品，都需要这个过程。

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

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

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

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

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

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

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

表4.3——代码复查

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

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

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

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

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

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

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

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

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

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

成长任务编辑入门编辑规则本人编辑