計畫驅動開發是一種軟體開發的方法論，其主要特徵為：軟體開發過程中，前一階段的輸出作為規劃隨後過程活動的基礎。
基本介紹
- 中文名：計畫驅動開發
- 外文名：Plan driven development
步驟,對比,概述,具體對比,
步驟
計畫驅動開發起源於系統工程和質量規範，建立系統工程的原則，協調大量需要精確協同工作的組件。通過從需求到已完成的代碼等一系列代表物來推動軟體開發的過程，計畫驅動開發非常精確地依賴於明確的步驟。
計畫驅動開發方法論中的典型代表是瀑布模型，其將軟體開發周期劃分成若干個階段：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼與單元測試、綜合測試、軟體維護。各階段的工作自上而下，按照從抽象到具體的順序進行。每個階段都必須完成規定的文檔，只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果。這一過程就好像奔流不息的瀑布，水流從上游向下游流動，從概念直到最終產品。
計畫驅動開發的關鍵是過程的定義和管理，和過程改進聯繫在一起，強勢在於標準化所帶來的可比較性和可重複性。過程需要進行定義、標準化並需要逐步改進以提供控制、管理其操作所需的數據。定義過程執行的方法，和工作產品形式化的方法，對過程的實施者進行良好的培訓。需要管理層的支持、組織化的基礎設施以及良好的環境。
對比
概述
從以下特徵中比較敏捷軟體開發和計畫驅動開發之間的不同：
1、套用：項目的主要目標、項目環境和套用環境；
2、管理：客戶關係、計畫和控制，以及項目溝通；
3、技術：需求定義、開發和測試的方法；
4、人員：客戶特徵、開發人員的特徵，以及組織的文化。
具體對比
1.套用
(1)主要目標：敏捷軟體開發的目標是快速交付價值和回響變更，在快速變更的環境中，反應式的態度具有優勢，但有一些風險。計畫驅動開發的目標是可預見性、穩定性和高可靠性，提前行動的態度對於穩定的環境非常有效，認證需要有計畫和規格說明；
(2)規模：敏捷軟體開發最適合規模比較小的項目，事實證明，敏捷項目的規模難以擴大。傳統的嚴格性對大型項目更有效，對於大型、複雜的項目來說，計畫驅動開發是必需的；
2.管理
(1)客戶關係：敏捷軟體開發提倡專職的、在一起工作的客戶，重中之重是客戶代表和用戶之間的接口，敏捷開發者通過可以工作的軟體來建立客戶信任。計畫驅動開發依賴於契約和規格說明，重中之重是開發者和客戶之間的接口，計畫驅動開發者使用已形成的過程成熟度來建立客戶信任；
(2)計畫和控制：敏捷者把計畫看作一種達到目標的手段，敏捷軟體開發是“計畫行為驅動”而非“計畫驅動”。計畫驅動開發用計畫來進行溝通和協調。兩種方法都使用過去的經驗來使計畫變得準確；
(3)項目溝通：敏捷軟體開發依賴於隱式知識，依賴於頻繁的、人和人之間的溝通，依賴於隱式知識是有風險的，隱式知識的規模難以擴大。計畫驅動開發依賴於顯示的、文檔化知識。敏捷軟體開發和計畫驅動開發中都同時使用了這兩種知識。敏捷軟體開發在需要時會編寫文檔。計畫驅動開發則通常是去掉一些不必要的內容，一旦指定，再去除文檔就很難了，會遭遇“裁剪”綜合症。
3.技術
(1)需求：敏捷軟體開發把非正式的、由用戶指定優先權的素材作為需求。計畫驅動開發偏愛明確的、形式化的需求，計畫驅動開發中沒有廣泛使用優先權這一概念。計畫驅動開發可以更好地處理非功能需求(比如：可靠性、吞吐量、滿足實時限制和可伸縮性)；
(2)開發：敏捷軟體開發提倡簡單設計，簡單設計依賴於低成本的改寫和快速變更，但無法保證低成本的改寫，低成本的改寫無法伸展，簡單設計意味著你不會需要它的(You are’t going to need it)。計畫驅動開發提倡使用架構來預測變更，在快速變更的環境中，架構會造成一些資源的浪費；
(3)測試：敏捷軟體開發在編碼之前開發測試，然後增量地測試。計畫驅動開發測試的是規格說明。
4.人員
(1)客戶：敏捷軟體開發非常強調專職的、工作在一起的客戶代表，成功依賴於客戶代表必須易於協作、有代表性、有授權、盡責和在行(collaborative，representative，authorized，committed，knowledgeable，CRACK)。而計畫驅動開發則依賴於大量預先的，客戶和開發者之間的契約計畫和規格說明方面的工作，也需要CRACK型的客戶，但可以不是專職的，計畫驅動開發中最大的客戶挑戰是不要讓項目控制落入過度官僚(他們認為遵守契約比取得項目成果更重要)的契約管理者手中；
(2)開發人員：敏捷開發者需要具備更多的技能。不管是敏捷團隊還是計畫驅動團隊，都應該儘快識別出也許具有一些技術能力，但是不能或者不願意，合作或者遵循公共的方法的人員，讓他們從事一些非決策性質的工作。通過培訓能夠完成程式性的方法步驟(例如，對簡單的方法進行編碼，進行簡單的重構，遵循編碼規範和CM規程，運行測試)的人員，經過相當多的指導，可以在計畫驅動環境中很好地工作。而通過培訓能夠完成任意的方法步驟(例如，把素材分解成適合增量開發的大小，組合使用模式，進行複雜的重構，進行一些複雜的商品成品集成)的人員，經過一些指導，可以很好地在敏捷團隊中工作。能夠對方法進行裁剪以適應有先例可循的新情況的人員，可以很好地管理一個小型、有先例可循的敏捷或者計畫驅動項目。但對於大型或無先例可循的項目，需要能夠對方法進行修訂(違背其規則)以適應無先例可循的新情況的人員；
(3)文化：敏捷者喜歡更多的自由度，計畫驅動者需要清晰的過程和角色。一旦一種文化已被良好地建立，改變就會非常困難和耗時，文化的慣性是集成敏捷軟體開發和計畫驅動開發時面臨的最大挑戰。
