在RUP中结合PSP

来源:百度文库 编辑:神马文学网 时间:2020/08/04 04:23:00
典型地说,软件开发项目成败的关键因素有三个:时间、成本和质量(图一)。然而当我们把它们当作箭一样射向目标时,却经常会因为种种原因而无法正中靶心。
在瑞典,瑞典专利注册局有个著名的失败的软件项目,就是和很多软件公司合作,要实现一个基于Web的在线专利注册的解决方案。这个计划始于1998年,预算一千五百万美元,系统实际上在2000年9月交付,功能仍不完善,成本已达两千五百万。
为什么这个项目会失败呢?关于这个话题有很多研究论文和书籍,可靠的说法是失败同时源于内部和外部因素。例如,外部因素可能是产品开发出来时,已经过于陈旧而且没什么价值了,也就是说,过时的技术导致产品难于使用(可用性很差)。另外可能的外部因素还包括项目核心人员的离职和客户变更需求说明等。对于软件开发者来说,这些因素是无法控制的。
然而有个绝对可以控制的内部因素,就是软件开发过程。已定义的成熟的过程通常输出好的软件产品。而且随着系统越来越复杂和庞大,这样的过程会越来越重要。
现在存在着大量的软件开发过程,如:能力成熟度模型(CMM),Rational统一开发过程(RUP),个人软件过程(PSP)和小组软件过程(TSP)等等。大多数方法关注(支持)的焦点仅仅是一个层次上的过程改进。例如,RUP和CMM在组织级的层次上提供软件开发支持,TSP提供团队级别的支持,PSP提供个人级别的支持。
象RUP和TSP支持组织和团队级别的软件开发却不能适应组织中个体的软件过程。它们关注和致力于团队级别协同工作的活动却忽略了对个体的指导。导致的后果就是只能或多或少依靠个体自己去寻找监测、控制和改进其软件开发过程的方法。
RUP定义了一系列的过程元素,如角色、活动和产物,通过适当的组合,能帮助组织有效地管理软件项目。然而,过程本身并不提供神奇的超水平解决方案,只有角色--实际存在的人--才是项目的驱动力。没有人类的实践,世上任何过程或者工具都无法单独完成一个软件项目。归根结底,无论是项目按时完成还是发布高质量的系统,都很大程度上依赖于参胝吒鎏迦砑痰闹柿俊?
RUP提供的是帮助人们更出色地工作的知识基础。不同于PSP提供给软件工程师直接支持的使用途径,RUP规定的是各种各样的活动发生时,需要怎样做、做什么、何时做、由谁做以获得满意的成果的一个框架。换句话说,使用RUP的组织如果拥有合格的和有经验的人员能作的相当好,而且显然要比那些员工经验不足、能力不够也试行RUP的组织做得更好。为了节省时间和成本,对于那些员工经验不足的组织来说,尽快地改善员工技能是非常重要的。遗憾的是,RUP在如何解决员工能力这个问题上没有给出答案。
相比之下,PSP则立足于员工能力的改进。PSP是软件工程师个体软件过程改进的指导框架,是宾夕法尼亚州-匹兹堡的软件工程学会成员Watts Humphrey1995年创立的。PSP提供了一些度量标准、操作步骤和模板帮助工程师改进个人的软件工程技巧。研究结果显示软件工程师应用PSP后软件过程有显著改进,在生产力、缺陷引入的数量、时间和规模的估算等方面也有明显改善。
图二显示PSP过程的成熟度等级。PSP0是最基础的,使软件工程师能够建立基本的开发过程,而PSP3是最复杂的,提供大量有效的度量标准和模板。
正如运用PSP所能获得的积极效果,我们可以认为RUP中类似的过程改进意识将帮助使用者改进他们自己的过程,从而提高组织整体的过程改进效果。假如你去研究并比较PSP和RUP,会很容易发现PSP具有可运用于RUP中的过程改进概念。
任务和进度计划模板 RUP在一次迭代过程中对团队成员如何控制工作仅提供有限的支持,而RUP的一次迭代可能持续数周或数月。项目经理(或其它领导者)分配任务和职责给项目组成员,但在迭代中如何计划则取决于每个项目组成员自己。对此RUP未提供任何支持。相比之下,PSP提供了任务和进度计划模板用以监控项目的进展。利用这些工具,软件工程师能够追踪他们的进程,知道什么时候开始落后于进度,并且将其通报项目经理以采取相应的纠正措施。
基于个体缺陷数据的检查表 RUP角色不执行基于个人缺陷数据的复查。他们只有从整个组织收集的最典型缺陷类型的检查表。由此导致的结果是软件工程师们查找的缺陷类型也许是他们从来不会引入的。相比之下,PSP具有基于个体缺陷数据的检查表,因此软件工程师查找的缺陷类型正是他们经常涉及的。
记录过程改进想法以及帮助推动过程改进的模板 RUP不提供模板记录关于过程改进的想法,PSP却提供这样的模板让软件工程师象记录项目下一步要完成的任务一样记载这些想法。
帮助改进过程的度量标准(方法) RUP不提供给软件工程师预先定义好的监控软件过程的度量标准(方法)。其实每个新项目开始前,度量标准(方法)必须定义并且解释给所有项目组成员。然而,该度量标准(方法)不能保证提供了软件工程师为监控其软件开发过程所希望的和需要的那类信息。在这种情况下,就要依靠软件工程师自己定义和运用适当的度量标准(方法)。相比之下,PSP拥有许多度量标准(方法),提供大量个体软件开发过程改进的信息。
可惜的是,PSP的模型不能直接被RUP角色运用,它必须经过修改才能适合RUP环境。假如每个RUP项目都以同样的方式控制--即假如产物,活动,工作流,生命周期模型等等从来都不会变更--那么PSP模型只需修改一次就可以适用了。然而这是不可能的,因为每个项目都是唯一的,为了成功地完成都需要用特定的方式来管理。这意味着RUP的各建模元素--活动, 产物,及工作流--在每个即将实施的特定的项目中都必须修改和定义。
为了决定用PSP支持RUP的时机,我们给那些在整个过程中承担部分任务:设计,编码和测试活动的角色定义了“PSP工具箱”。该工具箱包含过程脚本、模板,以及RUP角色适用的度量标准(方法)(见图3),使他们能分析和控制自己的软件开发过程。
我们给RUP定义的5种角色:实现者,集成者,测试设计者,测试者,以及设计者都设置了其独有的PSP工具箱。他们从事PSP相关的活动,而且他们应该作为运用PSP模型的主要的候选对象。尽管RUP中也有其他一些角色从事PSP相关的活动,但是在相对次要的层次上,比如处理并发事件的概要设计者,他们可以被当作局部设计人员。因此,定义PSP工具箱限制在以上提及的主要角色类别。但应该指出,RUP的每种角色都应该有一个自己的过程改进框架,特别地定义那些个别角色的需求和工作环境。然而,这是另外的话题,在此就不再深入讨论了。
到目前为止,我们为5个选定的角色定义PSP工具箱,而且PSP工具箱中的模型可以帮助他们监视和控制他们的软件开发过程。但是还有两件事没有做。第一,一种新的过程--在这里就是指PSP -- 要用适当的方式把它引入组织中。经验告诉我们表一中列举的一些概括性的指导方针对于过程的引入很有效。
在RUP中结合PSP
Incorporating the Personal Software Process into the Rational Unified Process
作者 Harald Svensson(Sweden)
审校 伏英娜
译者 伏英娜 iasc jun_liuvc_6
[本文从AKA网站转载]
译者注:RUP—Rational统一开发过程
PSP—个体软件过程
Typically, there are three main factors important to the success of a software development project: time, cost, and quality (Figure 1). When we toss these three "darts," however, we often miss the bull‘s-eye, for a number of reasons.
典型地说,软件开发项目成败的关键因素有三个:时间、成本和质量(图一)。然而当我们把它们当作箭一样射向目标时,却经常会因为种种原因而无法正中靶心。
In Sweden, one notable failure was a software project at the Swedish Patent and Registration Office, which contracted a large software development firm to implement a Web solution for companies to register themselves online with the Patent and Registration Office. The planned release was to be 1998 at an approximate cost of $15 million. But the system was actually delivered in September 2000, still incomplete, at a cost of $25 million.
在瑞典,瑞典专利注册局有个著名的失败的软件项目,就是和很多软件公司合作,要实现一个基于Web的在线专利注册的解决方案。这个计划始于1998年,预算一千五百万美元,系统实际上在2000年9月交付,功能仍不完善,成本已达两千五百万。

Figure 1: Important Factors in Software Development Projects
图1:软件开发项目成败的关键因素
Why do projects fail? There have been many books and research articles on the subject, but it is safe to say that failure stems from both external and internal factors. An external factor, for example, might be that the product is already "old" and useless by the time it is developed; that is, it is based on out-of-date technology that makes the product cumbersome to use. Other possible external factors include key personnel leaving the project or customers changing the requirements specifications. These are all factors that you, as a software developer, cannot control.
为什么这个项目会失败呢?关于这个话题有很多研究论文和书籍,可靠的说法是失败同时源于内部和外部因素。例如,外部因素可能是产品开发出来时,已经过于陈旧而且没什么价值了,也就是说,过时的技术导致产品难于使用(可用性很差)。另外可能的外部因素还包括项目核心人员的离职和客户变更需求说明等。对于软件开发者来说,这些因素是无法控制的。
One factor that you can control, however, is an internal one: the software development process. A defined and mature process usually results in good products. Furthermore, using such a process becomes more and more important as systems continue to grow in complexity and size.
然而有个绝对可以控制的内部因素,就是软件开发过程。已定义的成熟的过程通常输出好的软件产品。而且随着系统越来越复杂和庞大,这样的过程会越来越重要。
Software Development Processes
软件开发过程
Today, there are a number of software development processes: the Capability Maturity Model (CMM), the Rational Unified Process (RUP?), the Personal Software Process (PSP), and the Team Software Process (TSP), to name a few. Most of these processes focus on just one dimension regarding support for process improvement. The RUP and CMM, for example, provide support for software development at an organizational level; the TSP provides support at a team level; and the PSP provides it at an individual level.
现在存在着大量的软件开发过程,如:能力成熟度模型(CMM),Rational统一开发过程(RUP),个人软件过程(PSP)和小组软件过程(TSP)等等。大多数方法关注(支持)的焦点仅仅是一个层次上的过程改进。例如,RUP和CMM在组织级的层次上提供软件开发支持,TSP提供团队级别的支持,PSP提供个人级别的支持。
Processes like the RUP and the TSP support teams and organizations to develop software but do not support the software processes of the individuals in the organizations. The focus and effort of coordinating work activities at a team level leaves out guidelines for the workers. As a consequence, it is more or less up to the individual worker to find ways to monitor, control, and improve his own personal software development process.
象RUP和TSP支持组织和团队级别的软件开发却不能适应组织中个体的软件过程。它们关注和致力于团队级别协同工作的活动却忽略了对个体的指导。导致的后果就是只能或多或少依靠个体自己去寻找监测、控制和改进其软件开发过程的方法。
The Rational Unified Process (RUP)
Rational统一开发过程
The RUP defines process elements such as workers, activities, and artifacts that, when combined properly, will help an organization conduct a software project efficiently. The process itself, however, does not provide any magical solutions. It is the workers -- actual human beings -- who are the driving force of the project. Without human participants, no process or tool in the world could alone finish a software project. The end results -- whether the project finished on time and whether the released system was of high quality -- depend to a great extent on the quality of participants‘ individual software processes.
RUP定义了一系列的过程元素,如角色、活动和产物,通过适当的组合,能帮助组织有效地管理软件项目。然而,过程本身并不提供神奇的超水平解决方案,只有角色--实际存在的人--才是项目的驱动力。没有人类的实践,世上任何过程或者工具都无法单独完成一个软件项目。归根结底,无论是项目按时完成还是发布高质量的系统,都很大程度上依赖于参胝吒鎏迦砑痰闹柿俊?
The RUP provides a knowledge base of information that helps workers do a better job. It differs from the approach used in the PSP, however, which provides the software engineer with more explicit support. Instead, the RUP provides a framework for how, what, when, and by whom various activities should take place in order to get a satisfying result. In other words, an organization using RUP will do well if it has competent and experienced people -- and will certainly do better than an organization with incompetent and inexperienced employees that attempts to use the RUP. It is always important for organizations with inexperienced people to quickly improve their employees‘ skills in order to save time and money. The RUP does not provide an answer to this issue of employee competence.
RUP提供的是帮助人们更出色地工作的知识基础。不同于PSP提供给软件工程师直接支持的使用途径,RUP规定的是各种各样的活动发生时,需要怎样做、做什么、何时做、由谁做以获得满意的成果的一个框架。换句话说,使用RUP的组织如果拥有合格的和有经验的人员能作的相当好,而且显然要比那些员工经验不足、能力不够也试行RUP的组织做得更好。为了节省时间和成本,对于那些员工经验不足的组织来说,尽快地改善员工技能是非常重要的。遗憾的是,RUP在如何解决员工能力这个问题上没有给出答案。
The Personal Software Process (PSP)
个体软件过程
The PSP, in contrast, does address this employee improvement issue. The PSP is a framework for software process improvement for the individual software engineer. Watts Humphrey at the Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania, developed it in 1995. The PSP provides metrics, process-steps, and templates that help an engineer improve her software engineering skills. Research results indicate significant process improvements among software engineers applying the PSP. Factors like productivity, number of injected defects, and time and size estimations tend to improve when the PSP is applied.
相比之下,PSP则立足于员工能力的改进。PSP是软件工程师个体软件过程改进的指导框架,是宾夕法尼亚州-匹兹堡的软件工程学会成员Watts Humphrey1995年创立的。PSP提供了一些度量标准、操作步骤和模板帮助工程师改进个人的软件工程技巧。研究结果显示软件工程师应用PSP后软件过程有显著改进,在生产力、缺陷引入的数量、时间和规模的估算等方面也有明显改善。
Figure 2 shows the PSP‘s process maturity levels. PSP0 is the most basic level, enabling the software engineer to establish a ground floor development process, whereas PSP3 is the most complex, with a number of metrics and templates available to the software engineer.
图二显示PSP过程的成熟度等级。PSP0是最基础的,使软件工程师能够建立基本的开发过程,而PSP3是最复杂的,提供大量有效的度量标准和模板。

Figure 2: The PSP‘s Process Maturity Levels
图2:PSP成熟度等级
How the PSP Can Support the RUP
PSP如何支持RUP
In light of these positive results from applying the PSP, we might assume that similar process improvement awareness in the RUP would help workers improve their own processes, thereby enhancing the results of an organization as a whole. If you study and compare the PSP with the RUP, it becomes obvious that the PSP has process improvement concepts that can be applied in the RUP.
正如运用PSP所能获得的积极效果,我们可以认为RUP中类似的过程改进意识将帮助使用者改进他们自己的过程,从而提高组织整体的过程改进效果。假如你去研究并比较PSP和RUP,会很容易发现PSP具有可运用于RUP中的过程改进概念。
The main advantages of incorporating the PSP into the RUP are as follows:
在RUP中融合PSP的主要好处如下:
Task and schedule planning template. The RUP provides limited support to team members on how to manage work within an iteration. In the RUP, iterations can last for weeks or months. The project manager (or other lead) assigns tasks and responsibilities to project participants. It is up to the individual worker, however, to plan his work during the iteration. The RUP does not provide any support for this. The PSP, in contrast, provides task and schedule planning templates to monitor project progress. With these tools, software engineers can track their progress and know when they are slipping behind schedule. They can then inform the project manager about this status so that appropriate corrective actions can be taken.
任务和进度计划模板 RUP在一次迭代过程中对团队成员如何控制工作仅提供有限的支持,而RUP的一次迭代可能持续数周或数月。项目经理(或其它领导者)分配任务和职责给项目组成员,但在迭代中如何计划则取决于每个项目组成员自己。对此RUP未提供任何支持。相比之下,PSP提供了任务和进度计划模板用以监控项目的进展。利用这些工具,软件工程师能够追踪他们的进程,知道什么时候开始落后于进度,并且将其通报项目经理以采取相应的纠正措施。
Checklists based on personal defect data. The workers in the RUP do not perform reviews based on personal defect data. Rather, they have checklists based on the most typical defect types collected in the organization. As a consequence, software engineers could be looking for defect types they never inject. The PSP, on the other hand, has checklists that are based on personal defect data. So software engineers will be looking for defect types they usually inject.
基于个体缺陷数据的检查表 RUP角色不执行基于个人缺陷数据的复查。他们只有从整个组织收集的最典型缺陷类型的检查表。由此导致的结果是软件工程师们查找的缺陷类型也许是他们从来不会引入的。相比之下,PSP具有基于个体缺陷数据的检查表,因此软件工程师查找的缺陷类型正是他们经常涉及的。
Templates to record ideas for, and help move toward, process improvement.
The RUP does not provide templates for writing down ideas for process improvement, but the PSP does provides templates for software engineers to record ideas as well as tasks to perform later on in the project.
记录过程改进想法以及帮助推动过程改进的模板 RUP不提供模板记录关于过程改进的想法,PSP却提供这样的模板让软件工程师象记录项目下一步要完成的任务一样记载这些想法。
Metrics to help improve process. The RUP does not provide predefined metrics that software engineers can use to monitor and control their software processes. Before each new project, metrics must be defined and explained to all project participants. There is no guarantee, however, that the defined metrics offer the kind of information a software engineer wants or needs in order to monitor his software development process. In these cases, it is up to the software engineer to define and apply appropriate metrics. The PSP, in contrast, has a number of metrics that provide information on improving the personal software development process.
帮助改进过程的度量标准(方法) RUP不提供给软件工程师预先定义好的监控软件过程的度量标准(方法)。其实每个新项目开始前,度量标准(方法)必须定义并且解释给所有项目组成员。然而,该度量标准(方法)不能保证提供了软件工程师为监控其软件开发过程所希望的和需要的那类信息。在这种情况下,就要依靠软件工程师自己定义和运用适当的度量标准(方法)。相比之下,PSP拥有许多度量标准(方法),提供大量个体软件开发过程改进的信息。
Unfortunately, the PSP material cannot be applied directly by workers using RUP; it must be modified so that it suits the RUP context. If every RUP project were conducted in the same manner -- that is, if all artifacts, activities, workflows, lifecycle models, and so on, never changed -- then the PSP material would only need to be adapted once. This is not the case, however. Every project is unique and needs to be conducted in a particular way in order to be successful. This means that the RUP material -- activities, artifacts, and workflows -- must be modified and defined for the particular project at hand.
可惜的是,PSP的模型不能直接被RUP角色运用,它必须经过修改才能适合RUP环境。假如每个RUP项目都以同样的方式控制--即假如产物,活动,工作流,生命周期模型等等从来都不会变更--那么PSP模型只需修改一次就可以适用了。然而这是不可能的,因为每个项目都是唯一的,为了成功地完成都需要用特定的方式来管理。这意味着RUP的各建模元素--活动, 产物,及工作流--在每个即将实施的特定的项目中都必须修改和定义。
PSP Toolboxes for RUP Personnel
RUP成员的PSP工具箱
To address the opportunity to support the RUP with the PSP, we defined "PSP Toolboxes" for workers whose tasks are part of both processes: those who do design, code, and test activities. The toolboxes contain process scripts, templates, and metrics (see Figure 3) for workers using the RUP to apply, enabling them to analyze and control their software development processes.
为了决定用PSP支持RUP的时机,我们给那些在整个过程中承担部分任务:设计,编码和测试活动的角色定义了“PSP工具箱”。该工具箱包含过程脚本、模板,以及RUP角色适用的度量标准(方法)(见图3),使他们能分析和控制自己的软件开发过程。

Figure 3: A PSP Toolbox with Process Improvement Elements for Workers Using the RUP
图3:RUP成员的PSP过程改进基础工具箱
We designed unique PSP Toolboxes for each of five workers defined in the RUP: Implementer, Integrator, Test Designer, Tester, and Designer. They all work in PSP-related activities and, furthermore, they were perceived as the main candidates for applying the PSP material. There are other workers in the RUP who also work with PSP activities, but to a lesser degree. For example, the Capsule Designer deals with concurrency issues, and can be viewed as a narrower version of the Designer. As a consequence, the work was restricted to defining PSP Toolboxes for the main worker categories mentioned above. It should be noted, however, that every worker in RUP ought to have a process improvement framework of his own, specially defined for that individual worker‘s needs and work environment. As the saying goes, however, that is another story; we will not address that issue here.
我们给RUP定义的5种角色:实现者,集成者,测试设计者,测试者,以及设计者都设置了其独有的PSP工具箱。他们从事PSP相关的活动,而且他们应该作为运用PSP模型的主要的候选对象。尽管RUP中也有其他一些角色从事PSP相关的活动,但是在相对次要的层次上,比如处理并发事件的概要设计者,他们可以被当作局部设计人员。因此,定义PSP工具箱限制在以上提及的主要角色类别。但应该指出,RUP的每种角色都应该有一个自己的过程改进框架,特别地定义那些个别角色的需求和工作环境。然而,这是另外的话题,在此就不再深入讨论了。
Incorporating the PSP into the RUP
把PSP应用到RUP中
So far so good. We have defined PSP Toolboxes for five chosen workers, and the material in those Toolboxes helps the workers monitor and control their software development processes. Two things, however, are still missing. First, a new process -- in this case the PSP -- should be introduced into an organization in a proper way. Experience tells us that the general guidelines presented in Table 1 are effective for process introductions.
到目前为止,我们为5个选定的角色定义PSP工具箱,而且PSP工具箱中的模型可以帮助他们监视和控制他们的软件开发过程。但是还有两件事没有做。第一,一种新的过程--在这里就是指PSP -- 要用适当的方式把它引入组织中。经验告诉我们表一中列举的一些概括性的指导方针对于过程的引入很有效。
Table 1: Guidelines for Introducing a New Process into an Organization
Guideline
Comments
Involve the right people
Competent people with decision power and interest in the new process should be involved.
Document new routines
Decide who will do what and when. The documents can be used as references if questions arise.
Demand feedback
Responsible people should solicit critiques and suggestions as the new process is introduced. The people applying the new process should feel that they can affect important decisions related to the introduction.
Conduct post-mortem analyses
At each stage of the introduction, stop and evaluate. Continuously try to improve the adaptation of the new process.
表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的各种原理在什么时间和位置(迭代过程中)适用,循序渐进。
在RUP中过程工程师负责改造RUP使之适合一个新的项目,就是说定义一个开发案例的模式。而RUP的其他成员在过程中应用PSP工具,和过程工程师一同工作,以这种方式使PSP原理适用于开发案例的模式。
用PSP支持RUP的主要优势在表4中给出。但或许最重要的优势是PSP为个人特长的发挥提供驱动。PSP强调个人的承诺和优秀是对过程改进结果有重要影响的要素。软件工程师总是努力追求完美,这种作法使他们再也不会因所做的努力是否会得到尊重而耿耿于怀。在这种承诺方式下的员工总是比那些不关心工作成果只要薪水保持增长的人做得更好,因为PSP使人为个人的卓越而努力。
表4:PSP支持RUP的主要优势
PSP支持RUP的主要优势
说明
减少工作成果缺陷的数量
调查基于个人的缺陷数据。
软件开发过程中的定量度量
通过模板和标准的支持为软件开发过程提供更好的控制。
更多正确和精确的评价
评价基于个人的过程数据。
追求个人的卓越
PSP使人努力改进工作程序。
迭代过程中更好的规划和控制
PSP提供短期的计划和控制,是RUP迭代趋于长时间段的理想补充。
最重要的要记得软件开发过程对所有层次的工作都提供支持:无论是对个人、对团队、还是对组织。定义过程的目的是为了确保工作能够具有相当高的质量而且提前完成。俗话说“一环薄弱,全局必垮。(链条的强度是由最薄弱的环节决定的)”。一个项目的成败依赖于所有相关的个体,而这些个体可以通过改进他们的工作流程对项目提供最大的支持。这就是PSP可以提升RUP之处。
_xyz