第二部分:啟動項目

Steven Franklin
軟件設計師和過程專家
2004 年 3 月

這個有多篇文章組成的系列講述了如何逐漸的應用 Rational 統一過程（RUP）和其他的 Rational 工具，本文中樣例項目的詳細計劃被圍繞著管理需求和風險而討論。

第二部分快照

第 2 部分展示的工具和技術： Rational 統一過程 (RUP) — 支持項目計劃的制定 RUP Microsoft Word 模板 — 草擬項目遠景文檔 Rational RequisitePro v2001A — 用于需求數據庫 Rational ClearQuest v2001A — 用于風險管理 將被創建或者更新的產物： RequisitePro 數據庫 — 被創建用來存儲來自于客戶的工作描述（SOW）的需求；之后需求會轉化成直接面向分析工作的更為詳細的系統需求規格說明書。 ClearQuest 風險數據庫 — （通過修改 ClearQuest 計劃）被創建以跟蹤項目風險

從開始進行計劃或者計劃失敗
在一個軟件項目中，獲得一個良好的開始是十分關鍵的。你不僅會希望你的早期勞動確定整個項目的基調，而且你也希望快速的識別出系統中的高風險和挑戰的部分。大概一半以上的項目的命運在項目的第一個月就已經注定了，決定的因素包括：

• 不夠良好的客戶關系
• 不充足的預算
• 糟糕的管理（包括不夠好的管理能力、風險的優先級劃分和糟糕的項目范圍管理）
• 過于依賴銀彈
• 工程技能和經驗的缺乏
• 不切實際的時間進度

Rational 統一過程（RUP）通過改進團隊的效率和指導提升團隊的成熟性可以盡量的減少導致項目失敗的因素。良好的數據可以影響項目的管理者對項目的管理，更好的工具可以支持工程團隊，更好的過程能夠幫助軟件產品以一種可預見的方式發展。本系列的第2部分將把重點放在我們能應用的一些早期策略上以獲得一些在我們的樣例項目中搖擺不定的事情。

Note that project management involves some activities that aren't currently addressed in the RUP. I highly recommend the book 請注意項目管理包括一些目前在 RUP 中沒有包含的活動。我強烈推薦這本書 快速開發: 馴服瘋狂的軟件進度 它可以作為在開發項目中減少風險因素的進一步的參考資料。

細化第1階段時間進度
我們希望盡快啟動軟件工程，但是首先我們必須在一系列的日程安排問題上得到來自于客戶的同意。我們拿來了 我們已經創建的第1階段的時間進度 （在4個月的時間點以一個演示結束）并和客戶更加緊密的審查時間進度。客戶提出了以下的問題，所有的問題都是正當的并且一些討論：

• “使用迭代開發，工程團隊將如何知道需要多少次的迭代才能實現我們目標呢？”
• ”在分析和架構的必要條件被達到前開始設計架構和設計對我們來說是不舒服的。“
• “在4個月的時候我們將得到具有什么功能的系統演示呢？”
• “你們將使用什么工具來創建系統呢？我們希望開始采購和培訓過程。”

這就是我們看到的客戶的主要的關心點，并且我們對每一項作出了回答：

• 擔心項目螺旋式的不斷進展卻沒有清晰的交付產品 因為 ASDI 是一家十分遵循有循序的 ISO 標準的公司，因此他們傾向于在早期制定按照從一個到另一個的順序的具體的時間底線。我們指出迭代可以減少風險并避免一次產生所有產物的與生俱來的問題。雖然迭代的次數可能會在項目過程中有所變化，但客戶可以比僅僅一個單一的迭代更好的觀測項目的進展。雖然一個單一的迭代看起來是更加簡單的，但我們需要多個迭代以更加成本有效的創建系統。在早期的迭代中有 ASDI 的參與將使他們獲得更多的好處，這使客戶有機會對開發系統的輸入提供他們自己的看法。
• 擔心遺漏的需求和不充分的分析。 這里再一次提到，ASDI ISO 背景使他們更愿意相信分析應該在任何的設計開始之前被執行和文檔化。我們向他們強調了 RUP 具有允許任務交迭執行的好處；也就是說，不同階段的任務可以并行的被執行。比如，詳細設計可以包括原型的創建和其他一些代碼開發以驗證設計的假設，減少性能風險等等。瀑布式的開發過程有很少的靈活性，并且不會為你提供高風險的很多早期警告。
• 擔心項目進展的跟蹤。 ASDI 中已經開始有對使用迭代開發方法的擔心的聲音了，并且他們需要看到能夠在項目中產成系統演示的具體進展的保證。在這一點上我們不能告訴他們演示被限定成什么樣子。這需要經過一個或兩個月當我們對更多的理解了系統的關鍵的和高風險的領域時才能被確定。我們向他們解釋說至少系統演示應該展示一些已經降低了我們已識別的主要風險的體系架構的深層次的部分。我們也預期系統演示可以顯示整個系統的工作流、可用性問題和組件之間的交互性的問題。
• 擔心我們選擇的工具他們將來無法提供或支持。 這對于 ASDI 來說是十分重要的，因為他們計劃在項目結束后自己承擔維護系統的責任。他們不想看到過早的使用令人興奮的但有風險的技術。在工具選擇方面我們需要針對客戶的技術需求、維護計劃和其他的需要作一些早期的探索工作。 OTS 評估（包括我們所推薦的）將給 ASDI 一個時機來審查我們對工具和技術選擇的標準和理由。在這一點上，ASDI 仍然對自己的執行條件沒有信心，他們目前有很少的 IT 基礎設施推動我們作快速的決定。

綜上所述，我們并不覺得我們時間進度計劃是過分自信的，并且我們有信心在客戶的成本期望之內完成任務。關于我們能夠滿足時間進度的能力來自于我們的團隊結構，在項目團隊中我們與 ASDI 一起對項目進行審查。如表1所示，我們計劃了包括一些兼職角色的人員。例如，我們有單獨的一個 QA 人員在我們的項目中，這個人同時也在其她項目中扮演角色；在我們的項目中顯示她作為一個20％的角色，這就以為著在我們的項目中她一周工作一天：

角色 時間承諾 項目管理 項目經理 50% 財務支持 15% 質量保證 10% 項目工程 項目工程師 50% 工程支持 (包括配置管理、系統管理等) 兼職 支持和審查團隊(定期的審查和咨詢) 兼職 (從項目內和項目外雇用的人員) 組長/高級分析師 全職 高級開發人員 全職 普通開發人員 全職 數據庫架構師 25%

Table 1:團隊結構

總的來看，我們計劃需要450個人天的工作量來創建這四個月之久的系統演示。在項目的進展過程中，我們將知道是否我們需要增加時間或者提前完成，我們也將通知 ASDI 項目的情況。在展示系統演示的時候，我們也要對深入的設計審查做好充分的準備，并且能過向客戶展示對項目第2階段的估計。如果 ASDI 對我們在第1階段的概念檢驗(POC)的工作表示滿意，他們將與我們啟動項目的第2階段的工作來開發產品化的系統。

雖然我們還在創建了ASDI 的第1階段的演示，但 ASDI 非常高興的看到了我們所作的工作將是進一步開發產品化系統的良好輸入。至少他們已經接近可需求的審查、屏幕的模式、OTS 評估、架構審查、兩個實際的版本和一個系統演示。

管理風險
從一開始就跟蹤風險是極其重要的。在之前的項目中，我們使用 Microsoft Excel 來管理風險，這次我們決定使用 Rational ClearQuest 以簡化風險的輸入、管理和報告。 ClearQuest 不是一個便宜的工具，而且它對風險管理不是獨一無二的成本有效的工具。然而，它同時還可以集中的管理我們的集成和測試方面的問題。此外，我們計劃在 Lookoff 的其他項目中共同承擔這個成本。

使用 ClearQuest Designer 可以非常方便的設計新的數據結構和表單。比如，創建一個風險錄入表單就類似與已經在 ClearQuest Designer 中顯示的缺陷表單，我們可以根據缺陷跟蹤計劃（DefectTracking schema）來新的計劃（schema），也可以刪除一些不必要的條目和重命名其他的條目，類似的更新相應的表單，刪除或者重命名必要的提示和域。

這里是你如何能夠自己進行試驗：假設你已經安裝了 ClearQuest 并具有管理員的權限，你應該可以很容易的找到 ClearQuest Designer 應用程序。從文件菜單中，選擇 創建計劃（New Schema ），并且選擇一個已存在的你想修改的計劃（Schema）。我們選擇修改缺陷跟蹤計劃（DefectTracking schema）。一旦你給你的新計劃（schema）一個名字，你將被提示創建一個與這個計劃（schema）相關聯的數據庫。除非你制定一個特殊的方法，否則你將以 Microsoft Access 數據庫的形式創建這個數據庫。當被要求將這個新建的數據庫與一個計劃（Schema）關聯時，選擇你剛剛創建并命名的計劃（Schema）。然后你可以檢查編輯和修改的表單和數據類型以符合你的要求。比如，你可以展開記錄類型和目錄樹的表單節點來查看存在的 Defect_Base_Submit 表單。這些表單可以被重命名，一些域可以被刪除、添加等等。更多創建和修改 ClearQuest 表單的信息，請參考 ClearQuest 文檔。

我可以很快的在我們的桌面將我們項目的風險輸入到 ClearQuest 中。整個團隊的所有成員都可以訪問風險數據庫，并且可以輸入他們觀察到的風險。雖然只有項目經理(PM)和項目工程師(PE)應該具有權限關閉風險，但是給團隊的每一個成員提出風險的權限是沒什么不對的。項目經理首先會希望查看對于客戶可見的風險，因為其中的某些風險也許不是相關聯的或者是可以很快被解決的。例如，圖1顯示了一個被用來輸入我們討論過的項目早期遇到的風險的表單。

圖 1: ClearQuest 風險輸入表單

對于項目的開始我發現并輸入和一共17個風險。這并不是一個非常大的數字，其中的一些風險（比如有挑戰的時間進度計劃）直到項目的最后時期都會存在。

圖2顯示了我們所查詢的項目風險的一個部分的列表的 ClearQuest 界面。風險被列在最上方，并且嚴格的按照順序排列。通過點擊列表中的風險項可以得到更加詳細的單個風險的信息。

Figure 2: ClearQuest 風險報告

跟蹤進展
管理需要工具來跟蹤項目的進展。在項目的早期階段，我們不能依賴任何象缺陷、變更請求和測試結果來衡量項目的成功。相反，我們必須根據工作分解結構(WBS)項和我們的進展來估計實際完成的比例。

好的工作分解結構(WBS) 對于跟蹤項目進展是十分重要的。第1部分中的干特圖 描述了我們第1階段的工作任務包 。為了使我們可以精練出有用的矩陣，這些工作任務包必須被清晰的定義并也適當的規劃每個工作任務包的大小。我們典型的為這些工作任務包分配10到40天的工作工作量。

此外，ClearQuest 也可以幫助我們跟蹤那些系統中可變的部分—在這些可變的部分中，變更請求卻是極其的偏高。在一些之前的項目中，我們發現在細化階段出現的過多的變更請求通常是下列方面中的一項或者多項的征兆：不夠充分的分析、難相處的客戶、脆弱的工程團隊、不良的過程執行或者復雜的再工程。如果在系統的某些方面出現了一點這些癥狀，就需要管理人員和組長對這些部分有額外的注意。

管理客戶期望
有時減少與客戶開會和接觸開起來是很容易的；然而，實際上是你的項目團隊成員中最重要的成員之一，并且客戶應該被從始至終的包括在整個項目中。這不僅僅可以產生更好的分析和改進每個迭代所獲得的結果，而且可以通過讓客戶看到進化中的產品和理解面臨的挑戰更好的管理客戶的期望。尤其是當客戶對技術不是非常精通時，他們對最終產品的期望肯能會很大程度的超出現實的成本、時間進度和可行性。

我們懷疑真正的項目優先級和動機并沒有反映客戶的工作現狀，我們還需要理解客戶關心的主要優先級和期望。為了實現之一點，我們起草了一份概要的遠景文檔來幫助諒解更多的客戶期望。（由于時間的限制，我們將業務遠景和項目遠景合并成了一個文檔。）不論是工作現狀（SOW）還是遠景文檔都要與客戶一起進行多次的修訂。

遠景文檔是基于在幾個由 RUP 安裝包提供的 Microsoft Word 模板其中的一個創建的。我們將這些模板安裝在 Word 指定的地方（通過 工具 > 選項 > 文件位置）。如圖3所示，我們為每個模板生成了預覽（通過打開每個 .dot 模板文件，選擇文件 > 屬性 > 總結，檢查 “保存預覽畫面” ，保存文件）并對模板的標題重命名 *.dot 文件以使他們更容易瀏覽。

圖 3: 瀏覽 RUP Microsoft Word 模板

管理需求
需求對于系統來說不是微不足道的。同樣，因為 ASDI 有很少的 IT 基礎設施，因此系統需求向詳細的軟件需求的轉換就需要充足的時間和勞動的付出。Rational RequisitePro 可以非常好的幫助我們完成這個任務，它允許我們在整個項目中管理我們的需求和跟蹤項目范圍的變化。

客戶已經開始的工作現狀（SOW）可以作為我們的系統需求基線。在許多的情況下，我們按照 RUP 中描述的從業務建模和需求分析開始。這應該包括業務用例的集合、補充的系統規范和業務對象模型。但是對于我們來說從客戶的工作現狀開始來滿足他們的期望并建立在他們的工作之上是十分重要的。我們將按照的工作現狀生成了一個叫作軟件需求說明書 (SRS) 的 RUP 產物，并且把它作為需求的基礎集合，根據它我們可以跟蹤我們后來的分析和建模產物。

RequisitePro 的能力可以非常容易的幫助我們從客戶的工作狀態（SOW）插入需求。我們創建需求的規則要與我們“子彈”的樣式相配，或者與任何或所有的關鍵字 "must"、 "will" 和 "should" 相配。其他可以幫助我們建立需求層次的訣竅包括在相同的級別上獲取需求塊，在需求塊創建標簽下對適當的父需求設置缺省值，然后讓創建工具完成接下來的工作。（起先我們使用需求塊創建時沒有設置父需求，所以我們必須返回到每一個需求并對每一個需求設置父需求 — 對于成百上千的需求來說這是單調乏味的工作。）

圖4顯示了來自于客戶服務子系統需求的一頁（一共大約40頁）。就象你看到的一樣，RequisitePro 的界面被緊密的集成到了 Word 應用程序中，因此你可以同時使用 Microsoft Word 和 RequisitePro 的特性。

圖 4: Rational RequisitePro 界面

我們與客戶緊密的溝通什么樣的信息是被需要的，但是我們讓他們在需求文檔上作了大量的工作。這被證明是一個非常有效的方式；我們能夠向他們的團隊傳授過程的技能，而他們能夠給我們的團隊他們學科的專家意見。我們趨向于非常細節的投入到一些領域中，而在其他的一些領域只是在非常高的層面上。在一些情況下這是非常合理的，但是在另一些情況下他們卻對系統的一個特定的領域過分的狂熱。通過對文檔的審查，我們可以指導 ASDI 寫出適當并足夠詳細的需求集合。因為我們正在處理的是 Word 文檔，因此規格上的互操作是容易的，當我們對這個文檔感到滿意時，我們就可以在文檔上運行 RequisitePro 。

同樣在這個時候我們關注系統的 非功能 需求，這就意味著這些需求不會被系統的功能規格說明描述。這些非功能需求包括關注人的因素的可用性需求（比如學習和使用的舒適性）和可靠性需求等等。

總結
在項目的這個點上，我們運作著一個很小的團隊。制定計劃和獲得資源是我們首要的任務。直到我們知道了我們應該朝什么方向努力并知道如何可以實現目標，我們的團隊才會越來越有斗志。對于我們來說首先最重要的是我們必須完成客戶的工作狀態（SRS），它規定了項目的基本系統和軟件需求。

計劃未來
我們希望盡快的組成工程團隊，但是我們接下來的任務需要一個高級的分析師以使 RUP 的初始階段更有進展。首先，被顯示在我們的工作狀態（SOW）中的需求本質上是一系列被分解的規格說明，這些規格說明不能引導清晰的工作分解，或者甚至不能會產生許多架構的線索。我們一直認為以平白的文字表示的需求不會帶來以統一建模語言（UML）表達的需求帶來同樣的好處，因此我們計劃將我們的需求轉化成用例（在 Rational Rose 中使用 UML）。

同樣，我們需要一種正式的方式來管理客戶的變更請求、客戶所關心的地方和客戶的反饋。雖然之前我們沒有使用 ClearQuest 的 Web 界面，但是它看起來像是一個完美的工具使開發團隊和客戶保持同步。建立 ClearQuest Web 對我們來說是下一周或第二周最高優先級的事情。

主要風險
我們的風險沒有明顯的變化：我們必須繼續把精力放在建立有效的客戶關系和快速的使項目沿著正確的方向前進。我么們現在有一個問題數據庫，因此我們可以關閉這個風險了；然而，直到我們建立了 ClearQuest 的 Web 界面，客戶才可以對項目的風險和他們可以支持我們的領域看得更加清楚。（后來當我們關閉這個風險時，我們不能提供時間或者基礎設施來建立 ClearQuest，但是一個大的項目將很明確的會從 ClearQuest 中受益。）

客戶很高興我們的進展如期完成，一部分是因為我們的工作產物對他們來說不是感覺不相關的。當我們繼續的移到 RUP 的產物時我們必須通過大量的指導來維護客戶的舒適感覺并溫和的進入新的概念：用例、業務對象等等。

我們覺得我們的時間進度是切合實際的并且設計是良好的除了有非常小的意外。這就意味著資源必須盡快的到位，并且審查返回必須是及時的。我們也必須從一開始就關注高級別的風險，因為我們不能讓他們在晚些時候遛進項目的第1階段。

資源

• 快速開發: 馴服瘋狂的軟件時間進度 作者 Steve McConnell (Microsoft 出版, 1996)

轉載于:https://www.cnblogs.com/laoxingxuzhou/archive/2004/11/20/5172988.html

總結

以上是生活随笔為你收集整理的应用Rational 工具简化基于J2EE的项目（二）启动项目的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。