在RUP中结合PSP

典型地说，软件开发项目成败的关键因素有三个：时间、成本和质量（图一）。然而当我们把它们当作箭一样射向目标时，却经常会因为种种原因而无法正中靶心。 

　　在瑞典，瑞典专利注册局有个著名的失败的软件项目，就是和很多软件公司合作，要实现一个基于Web的在线专利注册的解决方案。这个计划始于1998年，预算一千五百万美元，系统实际上在2000年9月交付，功能仍不完善，成本已达两千五百万。 



图1：软件开发项目成败的关键因素 
　　为什么这个项目会失败呢？关于这个话题有很多研究论文和书籍，可靠的说法是失败同时源于内部和外部因素。例如，外部因素可能是产品开发出来时，已经过于陈旧而且没什么价值了，也就是说，过时的技术导致产品难于使用（可用性很差）。另外可能的外部因素还包括项目核心人员的离职和客户变更需求说明等。对于软件开发者来说，这些因素是无法控制的。 

　　然而有个绝对可以控制的内部因素，就是软件开发过程。已定义的成熟的过程通常输出好的软件产品。而且随着系统越来越复杂和庞大，这样的过程会越来越重要。 

软件开发过程 
　　现在存在着大量的软件开发过程，如：能力成熟度模型（CMM），Rational统一开发过程（RUP），个人软件过程（PSP）和小组软件过程（TSP）等等。大多数方法关注（支持）的焦点仅仅是一个层次上的过程改进。例如，RUP和CMM在组织级的层次上提供软件开发支持，TSP提供团队级别的支持，PSP提供个人级别的支持。 

　　象RUP和TSP支持组织和团队级别的软件开发却不能适应组织中个体的软件过程。它们关注和致力于团队级别协同工作的活动却忽略了对个体的指导。导致的后果就是只能或多或少依靠个体自己去寻找监测、控制和改进其软件开发过程的方法。 

Rational统一开发过程 
　　RUP定义了一系列的过程元素，如角色、活动和产物，通过适当的组合，能帮助组织有效地管理软件项目。然而，过程本身并不提供神奇的超水平解决方案，只有角色－－实际存在的人－－才是项目的驱动力。没有人类的实践，世上任何过程或者工具都无法单独完成一个软件项目。归根结底，无论是项目按时完成还是发布高质量的系统，都很大程度上依赖于参胝吒鎏迦砑??痰闹柿俊? 

　　RUP提供的是帮助人们更出色地工作的知识基础。不同于PSP提供给软件工程师直接支持的使用途径，RUP规定的是各种各样的活动发生时，需要怎样做、做什么、何时做、由谁做以获得满意的成果的一个框架。换句话说，使用RUP的组织如果拥有合格的和有经验的人员能作的相当好，而且显然要比那些员工经验不足、能力不够也试行RUP的组织做得更好。为了节省时间和成本，对于那些员工经验不足的组织来说，尽快地改善员工技能是非常重要的。遗憾的是，RUP在如何解决员工能力这个问题上没有给出答案。 

　　相比之下，PSP则立足于员工能力的改进。PSP是软件工程师个体软件过程改进的指导框架，是宾夕法尼亚州-匹兹堡的软件工程学会成员Watts Humphrey1995年创立的。PSP提供了一些度量标准、操作步骤和模板帮助工程师改进个人的软件工程技巧。研究结果显示软件工程师应用PSP后软件过程有显著改进，在生产力、缺陷引入的数量、时间和规模的估算等方面也有明显改善。 

　　图二显示PSP过程的成熟度等级。PSP0是最基础的，使软件工程师能够建立基本的开发过程，而PSP3是最复杂的，提供大量有效的度量标准和模板。 



图2：PSP成熟度等级 
PSP如何支持RUP 
　　正如运用PSP所能获得的积极效果，我们可以认为RUP中类似的过程改进意识将帮助使用者改进他们自己的过程，从而提高组织整体的过程改进效果。假如你去研究并比较PSP和RUP，会很容易发现PSP具有可运用于RUP中的过程改进概念。 

　　在RUP中融合PSP的主要好处如下： 

任务和进度计划模板 RUP在一次迭代过程中对团队成员如何控制工作仅提供有限的支持，而RUP的一次迭代可能持续数周或数月。项目经理（或其它领导者）分配任务和职责给项目组成员，但在迭代中如何计划则取决于每个项目组成员自己。对此RUP未提供任何支持。相比之下，PSP提供了任务和进度计划模板用以监控项目的进展。利用这些工具，软件工程师能够追踪他们的进程，知道什么时候开始落后于进度，并且将其通报项目经理以采取相应的纠正措施。 
基于个体缺陷数据的检查表 RUP角色不执行基于个人缺陷数据的复查。他们只有从整个组织收集的最典型缺陷类型的检查表。由此导致的结果是软件工程师们查找的缺陷类型也许是他们从来不会引入的。相比之下，PSP具有基于个体缺陷数据的检查表，因此软件工程师查找的缺陷类型正是他们经常涉及的。 

记录过程改进想法以及帮助推动过程改进的模板 RUP不提供模板记录关于过程改进的想法，PSP却提供这样的模板让软件工程师象记录项目下一步要完成的任务一样记载这些想法。 

帮助改进过程的度量标准（方法） RUP不提供给软件工程师预先定义好的监控软件过程的度量标准（方法）。其实每个新项目开始前，度量标准（方法）必须定义并且解释给所有项目组成员。然而，该度量标准（方法）不能保证提供了软件工程师为监控其软件开发过程所希望的和需要的那类信息。在这种情况下，就要依靠软件工程师自己定义和运用适当的度量标准（方法）。相比之下，PSP拥有许多度量标准（方法），提供大量个体软件开发过程改进的信息。 

　　可惜的是，PSP的模型不能直接被RUP角色运用，它必须经过修改才能适合RUP环境。假如每个RUP项目都以同样的方式控制--即假如产物，活动，工作流，生命周期模型等等从来都不会变更--那么PSP模型只需修改一次就可以适用了。然而这是不可能的，因为每个项目都是唯一的，为了成功地完成都需要用特定的方式来管理。这意味着RUP的各建模元素--活动, 产物,及工作流--在每个即将实施的特定的项目中都必须修改和定义。 

RUP成员的PSP工具箱 

　　为了决定用PSP支持RUP的时机，我们给那些在整个过程中承担部分任务：设计，编码和测试活动的角色定义了“PSP工具箱”。该工具箱包含过程脚本、模板，以及RUP角色适用的度量标准（方法）（见图3），使他们能分析和控制自己的软件开发过程。 



图3：RUP成员的PSP过程改进基础工具箱 
　　我们给RUP定义的5种角色：实现者，集成者，测试设计者，测试者，以及设计者都设置了其独有的PSP工具箱。他们从事PSP相关的活动，而且他们应该作为运用PSP模型的主要的候选对象。尽管RUP中也有其他一些角色从事PSP相关的活动，但是在相对次要的层次上，比如处理并发事件的概要设计者，他们可以被当作局部设计人员。因此，定义PSP工具箱限制在以上提及的主要角色类别。但应该指出，RUP的每种角色都应该有一个自己的过程改进框架，特别地定义那些个别角色的需求和工作环境。然而，这是另外的话题，在此就不再深入讨论了。 

把PSP应用到RUP中 

　　到目前为止，我们为5个选定的角色定义PSP工具箱，而且PSP工具箱中的模型可以帮助他们监视和控制他们的软件开发过程。但是还有两件事没有做。第一，一种新的过程--在这里就是指PSP -- 要用适当的方式把它引入组织中。经验告诉我们表一中列举的一些概括性的指导方针对于过程的引入很有效。 


表1：把新过程引入组织中的指导方针 
方针 
说明 

包括合适的人员 
有决策权并且对新过程有兴趣的有能力的人应该包含其中。


文档化新规程 
决定谁什么时候做什么。当出现问题时这些文档可以用于参考。 


要求反馈 
在新过程引入时，相关责任人应该恳请别人提出批评和建议。使用新过程的人应该觉得他们能够对过程引入有关的重要决策产生影响。 


实施事后分析 
在引入的每个阶段，稍加停顿以评价前期的工作，不断地尝试改进新过程的适应性。 

　　第二，针对每个不同的项目，PSP工具箱中的模型应该作适当的调整。例如，要提前为软件开发项目定义度量规模的标准以便开发组成员估算产品规模、时间和工作量。但是，事先不可能知道应用过程中是否会有问题，以代码行和功能点这两种规模度量方法（标准）为例，方法（标准）的选择依赖于应用程序的类型或者开发过程中使用的工具。另外，如果使用代码行度量，还是不可能预先知道应该统计物理行数还是逻辑行数的问题，而用功能点度量就会存在选用哪些因素和权值的问题。正如这个小例子说明的，任何项目，实际使用PSP工具箱的人都应该对其中的内容进行调整。 

　　如表二所示，RUP提供了大量关于新项目RUP调整的指导方针供参考。 

表2：新项目RUP调整的指导方针
方针 
说明 

分析项目和组织 
分析即将开发的项目的类型、规模和组织方面的因素。 


定义项目的范围 
定义项目的作业流程；选择使用的工具。 


描述迭代计划 
确定整个迭代过程中的活动以及它们的次序。这个过程需要精确的定义。


改进项目过程 
每次迭代过程之后对RUP进行评估。 

　　为了使PSP和RUP完美地结合起来，同时针对这两个过程考虑表二中所列出的因素是很有意义的。这样，当你准备一个新项目时，就可以在相同的范围内同时考虑PSP和RUP，并且以相似的方式将它们文档化，从而轻松地把PSP结合到RUP之中。 


　　对于如何使PSP工具适合RUP过程，表2、3中的每个要素都提供了相应的指导。 

表3：使PSP工具适合RUP过程的指导方针
（斜体字表示PSP指导方针）
方针 
说明 

分析项目和组织 
分析即将开发的项目的类型。
选择适当的模版，模版应该适合应用软件的需求，对过程和组织的关键过程（要素）进行剪裁，
先在小的团队（小范围）执行和评价。不要在整个组织内强制执行PSP。

定义项目的范围 
定义项目的作业流程；选择使用的工具。
确定适当的度量标准。使用LOC代码行度量，所有的度量过程都基于这个标准。 

描述迭代规划 
确定整个迭代过程中的活动以及它们的次序。 这个过程需要精确的定义。 

改进项目过程 
每次迭代过程之后对RUP进行评估。 
评价PSP组合到RUP中的益处，关注成员之间的沟通，找出PSP的各种原理在什么时间和位置（迭代过程中）适用，循序渐进。

　　用PSP支持RUP的主要优势在表4中给出。但或许最重要的优势是PSP为个人特长的发挥提供驱动。PSP强调个人的承诺和优秀是对过程改进结果有重要影响的要素。软件工程师总是努力追求完美，这种作法使他们再也不会因所做的努力是否会得到尊重而耿耿于怀。在这种承诺方式下的员工总是比那些不关心工作成果只要薪水保持增长的人做得更好，因为PSP使人为个人的卓越而努力。 

表4：PSP支持RUP的主要优势
PSP支持RUP的主要优势 
说明 

减少工作成果缺陷的数量 
调查基于个人的缺陷数据。 

软件开发过程中的定量度量
通过模板和标准的支持为软件开发过程提供更好的控制。 

更多正确和精确的评价 
评价基于个人的过程数据。 

追求个人的卓越 
PSP使人努力改进工作程序。 

迭代过程中更好的规划和控制 
PSP提供短期的计划和控制，是RUP迭代趋于长时间段的理想补充。 

　最重要的要记得软件开发过程对所有层次的工作都提供支持：无论是对个人、对团队、还是对组织。定义过程的目的是为了确保工作能够具有相当高的质量而且提前完成。俗话说“一环薄弱,全局必垮。（链条的强度是由最薄弱的环节决定的）”。一个项目的成败依赖于所有相关的个体，而这些个体可以通过改进他们的工作流程对项目提供最大的支持。这就是PSP可以提升RUP之处。 

原文转自：http://www.ltesting.net