在RUP中結合PSP
Incorporating the Personal Software Process into the Rational Unified Process
作者 Harald Svensson(Sweden)
審校 伏英娜
譯者 伏英娜 iasc jun_liu vc_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：把新過程引入組織中的指導方針
方針
說明
包括合適的人員
有決策權并且對新過程有興趣的有能力的人應該包含其中。
文檔化新規程
決定誰什么時候做什么。當出現問題時這些文檔可以用于參考。
要求反饋
在新過程引入時，相關責任人應該懇請別人提出批評和建議。使用新過程的人應該覺得他們能夠對過程引入有關的重要決策產生影響。
實施事后分析
在引入的每個階段，稍加停頓以評價前期的工作，不斷地嘗試改進新過程的適應性。
Second, the material in the PSP Toolboxes needs to be adapted and adjusted for each individual project. For instance, size metrics should be defined for software development projects, so that team members can measure the size of the products and estimate time and effort. It is impossible to know beforehand, however, whether the worker in question will apply, for example, Lines Of Code (LOC) or Function Points (FP), to name just two size metrics. The choice of metric may depend on the type of application developed or the tool used in the development effort. In addition, it is also impossible to know beforehand if the worker in question will count physical or logical lines if LOC is used, or what kinds of factors and weights he or she will choose if FP is used. As this small example illustrates, for any project, the people actually using the PSP Toolboxes should be the ones who adapt the contents in those toolboxes.
第二，針對每個不同的項目，PSP工具箱中的模型應該作適當的調整。例如，要提前為軟件開發項目定義度量規模的標準以便開發組成員估算產品規模、時間和工作量。但是，事先不可能知道應用過程中是否會有問題，以代碼行和功能點這兩種規模度量方法（標準）為例，方法（標準）的選擇依賴于應用程序的類型或者開發過程中使用的工具。另外，如果使用代碼行度量，還是不可能預先知道應該統計物理行數還是邏輯行數的問題，而用功能點度量就會存在選用哪些因素和權值的問題。正如這個小例子說明的，任何項目，實際使用PSP工具箱的人都應該對其中的內容進行調整。
As Table 2 shows, the RUP does provide a number of guidelines to consider when adapting the RUP to a new project.
如表二所示，RUP提供了大量關于新項目RUP調整的指導方針供參考。
Table 2: RUP Guidelines to Consider When Adapting the RUP for a New Project
RUP Guideline
Comments
Analyze project and organization
Analyze the type of application to be developed, size of the project, and organizational factors.
Define scope of project
Define the workflows to be used in the project; decide which tools will be used.
Describe iteration plans
Decide activities and their order of application in the iterations. The process should be defined thoroughly.
Update the project's processes
Evaluate the RUP after each iteration.
表2：新項目RUP調整的指導方針
方針
說明
分析項目和組織
分析即將開發的項目的類型、規模和組織方面的因素。
定義項目的范圍
定義項目的作業流程；選擇使用的工具。
描述迭代計劃
確定整個迭代過程中的活動以及它們的次序。這個過程需要精確的定義。
改進項目過程
每次迭代過程之后對RUP進行評估。
In order to adapt the PSP to fit nicely with the RUP, it makes sense to consider the factors listed in Table 2 for both processes. That way, when you prepare for a new project, both the PSP and the RUP will be reviewed in the same areas and documented in a similar way, thereby easing the incorporation of the PSP into the RUP.
為了使PSP和RUP完美地結合起來，同時針對這兩個過程考慮表二中所列出的因素是很有意義的。這樣，當你準備一個新項目時，就可以在相同的范圍內同時考慮PSP和RUP，并且以相似的方式將它們文檔化，從而輕松地把PSP結合到RUP之中。
For each of the factors listed in Table 2, Table 3 shows corresponding guidelines for adapting the PSP Toolboxes to the RUP.
對于如何使PSP工具適合RUP過程，表2、3中的每個要素都提供了相應的指導。
Table 3: Guidelines for Adapting PSP Toolboxes to the RUP
(PSP guidelines in italics)
Guideline
Comments
Analyze project and organization
Analyze the type of application to be developed.
Choose appropriate templates. The templates should match the needs of the application, size of the project, and organizational factors.
Start implementation with a small group and evaluate. Do not force the PSP on the organization.
Define scope of project
Define the workflows to be used in the project; decide which tools will be used.
Decide on an appropriate size metric. The PSP uses LOC, and many metrics are based on that assumption.
Describe iteration plans
Decide activities and their order of application in the iterations. The process should be defined thoroughly.
Update the project's processes
Evaluate the RUP after each iteration.
Evaluate how well the PSP is incorporated into the RUP; look at communication among workers, when and where to apply various PSP elements, and so forth.
表3：使PSP工具適合RUP過程的指導方針
（斜體字表示PSP指導方針）
方針
說明
分析項目和組織
分析即將開發的項目的類型。
選擇適當的模版，模版應該適合應用軟件的需求，對過程和組織的關鍵過程（要素）進行剪裁，
先在小的團隊（小范圍）執行和評價。不要在整個組織內強制執行PSP。
定義項目的范圍
定義項目的作業流程；選擇使用的工具。
確定適當的度量標準。使用LOC代碼行度量，所有的度量過程都基于這個標準。
描述迭代規劃
確定整個迭代過程中的活動以及它們的次序。 這個過程需要精確的定義。
改進項目過程
每次迭代過程之后對RUP進行評估。
評價PSP組合到RUP中的益處，關注成員之間的溝通，找出PSP的各種原理在什么時間和位置（迭代過程中）適用，循序漸進。
The Process Engineer is the worker in RUP responsible for adapting the RUP to a new project, that is, to define a development case. The workers in RUP that will apply the PSP-toolboxes should thus work with the Process Engineer so that the PSP-elements will be adapted to the development case.
在RUP中過程工程師負責改造RUP使之適合一個新的項目，就是說定義一個開發案例的模式。而RUP的其他成員在過程中應用PSP工具，和過程工程師一同工作，以這種方式使PSP原理適用于開發案例的模式。
Advantages of Using the PSP with the RUP
在RUP中運用PSP的優勢
The main advantages of supporting the RUP with the PSP are presented in Table 4. Maybe the most important advantage that the PSP provides is the drive for personal excellence. The PSP stresses that personal commitment and excellence are factors that have a major impact on process improvement results. Software engineers should always strive to do the best they can. That way, they will never be disappointed with respect to their efforts. Employees with this kind of commitment always outperform those who do not care about their work results, as long as the paychecks keep coming. The PSP helps people strive for personal excellence.
用PSP支持RUP的主要優勢在表4中給出。但或許最重要的優勢是PSP為個人特長的發揮提供驅動。PSP強調個人的承諾和優秀是對過程改進結果有重要影響的要素。軟件工程師總是努力追求完美，這種作法使他們再也不會因所做的努力是否會得到尊重而耿耿于懷。在這種承諾方式下的員工總是比那些不關心工作成果只要薪水保持增長的人做得更好，因為PSP使人為個人的卓越而努力。
Table 4: The Main Advantages of Supporting the RUP with the PSP
Advantages of supporting the RUP with the PSP
Comments
Reduced number of defects in work products
Reviews are based on personal defect data.
Quantitative measures for the software development process
Support through templates and metrics provides better control of the software development process.
More accurate and precise estimates
Estimates are based on personal process data.
Striving for personal excellence
The PSP helps people strive for improvement in their work routines.
Better planning and control in the iterations
The PSP provides control and planning for short time periods, an ideal complement to the RUP's iterations, which tend to have longer timeframes.
表4：PSP支持RUP的主要優勢
PSP支持RUP的主要優勢
說明
減少工作成果缺陷的數量
調查基于個人的缺陷數據。
軟件開發過程中的定量度量
通過模板和標準的支持為軟件開發過程提供更好的控制。
更多正確和精確的評價
評價基于個人的過程數據。
追求個人的卓越
PSP使人努力改進工作程序。
迭代過程中更好的規劃和控制
PSP提供短期的計劃和控制，是RUP迭代趨于長時間段的理想補充。
It is important to remember that the software development process should provide support for all levels of work: for individuals as well as teams and organizations. The purpose of having defined processes is to ensure that the work ahead can be performed with a reasonably high degree of quality. "A chain is only as strong as its weakest link," as the saying goes. A project depends on the individuals involved in it, and these individuals, therefore, should have maximum support for improving their work routines. This is where the PSP can enhance the RUP.
最重要的要記得軟件開發過程對所有層次的工作都提供支持：無論是對個人、對團隊、還是對組織。定義過程的目的是為了確保工作能夠具有相當高的質量而且提前完成。俗話說“一環薄弱,全局必垮。（鏈條的強度是由最薄弱的環節決定的）”。一個項目的成敗依賴于所有相關的個體，而這些個體可以通過改進他們的工作流程對項目提供最大的支持。這就是PSP可以提升RUP之處。
--------------------------------------------------------------------------------
1參考文獻:
Hayes, W. and Over, J.W. "The Personal Software Process (PSP): An Empirical Study of the Impact of the PSP on Individual Engineers." Technical Report, CMU/SEI-97-TR-001, ESC-TR-97-001, Software Engineering Institute, December 1997.
Humphrey, W. A Discipline for Software Engineering. Addison-Wesley Publishing Company. 1997.
Stavros, K. M. and Avratoglou , Dr C. "Personal Software Process Implementation in a Production Environment." EuroSPI98, Gothenburgh, Sweden, 1998.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
