前期準備 - 三思而後行

1. 前期準備的重要性

準備工作的中心目標是降低風險儘可能早的將主要的風險清除掉，以使專案能平穩進行。軟體開發最常見的風險就是糟糕的需求分析和糟糕的專案計劃，因此準備工作就傾向於集中改進需求分析和羨慕計劃。

準備不周全的誘因：

專業程式元不清楚準備工作的重要性，或者不具備去做前期準備活動的專業技能，或是因為不能抵抗“儘快開始編碼”的慾望，或是管理者們對那些“花時間進行構建活動的前期準備的程式設計師”的冷漠。

發現錯誤的時間要儘可能接近引入該錯誤的時間。

2. 辨明所從事的軟體的型別

商業系統	使命攸關的系統	性命攸關的嵌入式系統
典型應用	Internet站點 Intranet站點 庫存管理 遊戲 管理資訊系統(MIS) 工資系統	嵌入式軟體 遊戲 Internet站點 盒裝軟體 軟體工具 Web services	航空軟體 嵌入式軟體 醫療裝置 作業系統 盒裝軟體
生命週期模型	敏捷開發（極限程式設計、 Scrum、time-box 開發等等） 漸進原型（prototyping）	分階段交付 漸進交付 螺旋型開發	分階段交付 螺旋型開發 漸進交付
計劃與管理	增量式專案計劃 隨需測試與QA計劃 非正式的變更控制	基本的預先計劃 基本的測試計劃 隨需QA計劃 正式的變更控制	充分的預先計劃 充分的測試計劃 充分的QA計劃 嚴格的變更控制
需求	非形式化的需求規格	半形式化的需求規格 隨需的需求評審	形式化的需求規格 形式化的需求檢查
設計	設計與編碼是結合的	架構設計 非形式化的詳細設計 隨需的設計評審	架構設計 形式化的架構檢查 形式化的詳細設計 形式化的詳細設計檢查
構建	結對程式設計或獨立編碼 非正式的check-in手續 或沒有check-in手續	結對程式設計或獨立編碼 非正式的check-in手續 隨需程式碼評審	結對程式設計或獨立編碼 正式的check-in手續 正式的程式碼檢查
測試與QA	開發者測試自己的程式碼 測試先行開發 很少或沒有測試（由單獨的測試小組來做）	開發者測試自己的程式碼 測試先行開發 單獨的測試小組	開發者測試自己的程式碼 測試先行開發 單獨的測試小組 單獨的QA小組
部署	非正式的部署過程	正式的部署過程	正式的部署過程

選擇更加序列化的方法的原因：

需求相當穩定

設計直截了當，而且理解透徹

開發團隊對於這一領域非常熟悉

專案的風險很小

“長期可預測性” 很重要

後期改變需求、設計和編碼的代價可能比較昂貴

選擇更加迭代的方法的原因：

需求並沒有被理解的很透徹，或者出於其它理由認為它是不穩定的

設計很複雜，或者有挑戰性，或者兩者兼具

開發團隊對於這一應用領域不熟悉

專案包含許多風險

“長期可預測性”不重要

後期改變需求、設計和編碼的程式碼很可能較低

3. 問題定義的先決條件

開始構建之前，首先要滿足一項先決條件是，對這個系統要解決的問題做出清楚的陳述。這有時稱為“產品設想/product vision”、“人物陳述/mission statement” 或者“產品定義/product definition”，“問題定義/problem definition”。

問題定義應該用客戶的語言來書寫，而且應該從客戶的角度來描述問題。

4. 需求的先決條件

要求一套明確的需求，明確的需求有助於確保是使用者駕馭系統的功能。有助於避免爭論。有助於減少開始編碼後系統變更的情況。

衡量需求做得如何：

針對功能需求

是否詳細定義了系統的全部輸入，包括其來源、精度、取值範圍、出現頻率等？

是否詳細定義了系統的全部輸出，包括目的地、精度、取值範圍、出現頻率、格式等？

是否詳細定義了所有輸出格式（Web頁面、報表，等等）？

是否詳細定義了所有硬體及軟體的外部介面？

是否詳細定義了全部外部通訊介面，包括握手協議、糾錯協議、通訊協議等？

是否列出了使用者想要做的全部事情？

是否詳細定義了每個任務所用的資料，以及每個任務得到的資料？

針對非功能需求（質量需求）

是否為全部必要的操作，從使用者的視角，詳細描述了期望響應時間？

是否詳細描述了其他與計時有關的考慮，例如處理時間、資料傳輸率、系統吞吐量？

是否詳細定義了安全級別？

是否詳細定義了可靠性，包括軟體失靈的後果、發生故障時需要保護的至關重要的資訊、錯誤檢測與恢復的策略等？

是否詳細定義了機器記憶體和剩餘磁碟空間的最小值？

是否詳細定義了系統的可維護性，包括適應特定功能的變更、操作環境的變更、與其他軟體的介面的變更能力？

是否包含對“成功”的定義？“失敗”的定義呢？

需求的質量

需求使用使用者的語言書寫的嗎？使用者也這麼認為嗎？

每條需求都不與其他需求衝突嗎？

是否詳細定義了相互競爭的特性之間的權衡——例如，健壯性與正確性之間的權衡？

是否避免在需求中規定設計（方案）？

需求是否在詳細程度上保持相當一致的水平？有些需求應該更詳細地描述嗎？有些需求應該更粗略地描述嗎？

需求是否足夠清晰，即使轉交給一個獨立的小組去構建，他們也能理解嗎？開發者也這麼想嗎？

每個條款都與待解決的問題及其解決方案相關嗎？能從每個條款上溯到他在問題與中對應的根源嗎？

是否每條需求都是可測試的？是否可能進行獨立的測試，以檢驗滿不滿足各項需求？

是否詳細描述了所有可能的對需求的改動，包括各項改動的可能性？

需求的完備性

對於在開始開發之前無法獲得的資訊，是否詳細描述了資訊不完全的區域？

需求的完備度是否能達到這種程度：如果產品滿足所有需求，那麼它就是可接受的？

你對全部需求都感到很舒服嗎？你是否已經去掉了那些不可能實現的需求——那些只是為了安撫客戶和老闆的東西？

衡量架構做得如何：

針對個架構主題

程式的整體組織結構是否清晰？是否包含一個良好的架構全域性觀（及其理由）？

是否明確定義了主要的構造塊（包括每個構造塊的職責範圍及其他構造塊的介面）？

是否明顯涵蓋了“需求”中列出的所有功能（每個功能對應的構造塊不太多也不太少）？

是否描述並論證了那些最關鍵的類？

是否描述並論證了資料設計？

是否詳細定義了資料庫的組織結構和內容？

是否指出了所用的關鍵的業務規則，並描述其對系統的影響？

是否描述了使用者介面設計的策略？

是否將使用者介面模組化，使介面的變更不會影響程式其餘部分？

是否描述並論證了處理I/O的策略？

是否估算了稀缺資源（如現程、資料庫連線、控制代碼、網路頻寬等）的使用量，是否描

述並論證了資源管理的策略？

是否描述了架構的安全需求？

架構是否為每個類、每個子系統、或每個功能域（functionality area）提出空間與時間預算？

架構是否描述瞭如何達到可伸縮性？

架構是否關注互操作性？

是否描述了國際化/本地化的策略？

是否提供了一套內聚的錯誤處理策略？

是否規定了容錯的辦法（如果需要）？

是否證實了系統各個部分的技術可行性？

是否詳細描述了過度工程的方法？

是否包含了必要的“買 vs. 造”的決策？

架構是否描述瞭如何加工被複用的程式碼，使之符合其他架構目標？

是否將架構設計得能夠適應很可能出現的變更？

架構的總體質量

架構是否解決了全部需求？

有沒有哪個部分是“過度設計”或“欠設計”？

整個架構是否在概念上協調一致？

頂層設計是否獨立於用作實現它的機器和語言？

是否說明了所有主要的決策的動機？