第二部分:啟動項目

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 基礎設施推動我們作快速的決定。