rel="file-list" href="file:///c:/docume%7e1/etrust/locals%7e1/temp/msoclip1/03/clip_filelist.xml">乙個人的小型**專案當然不需要和擁有
300人，
1000
萬美金的容錯作業系統專案使用同樣的計畫流程。一般來說，參加人員越多，越複雜的專案所需要的計畫就越複雜。但是，即使是乙個人的專案也會從良好的計畫中受益。計畫可以使你有機會檢查你的決策，暴露你的假設以及明確你和公司之間的協議等等。計畫可以使你發現許多愚蠢的決定，因為在計畫中，你需要考慮很多重要的問題，而且在計畫階段，你也有時間去考慮其他可選擇的方案。就像穆罕默德林肯說的那樣，「如果我需要
6個小時去砍一棵樹的話，那麼我就需要
4個小時去磨我的斧頭」。這句話意味著精心的準備可以減少你許多的工作量。
專案計畫回答了兩個問題。第乙個是我們需要做什麼，也可以稱之為需求分析，另外乙個問題是我們怎樣做，也可稱之為設計或者詳細說明。需求可以看作是乙個被詳細書寫的文件，通過它可以保證專案朝著正確的方向發展（例如，準備豐盛的一餐就要保證便宜，好吃並且營養豐富）。好的需求應該容易理解，並且很少產生歧義。雖然實現需求可能有很多種方法，但是當某一部分工作完成的時候，你要確認這一部分的需求是否真的被滿足了。式樣書也可以簡化那些滿足需求的計畫。
上圖中的
3個活動，包括需求收集，設計
/說明以及實現都是很值得研究的問題，在這方面也有許多值得閱讀的書籍。在接下來的章節，我將從專案的角度來闡述前兩個活動，而實現則在第14和
15章來討論。
3.1.1
不同型別的專案
關於需求分析和設計的工作，有幾個標準可以參照。我會用
3個不同的例子來闡述這些標準：
（1）超人。在最簡單的專案裡面，所有的工作都由乙個人來完成。**，市場以及商業計畫，乙個人完成所有的事情，當然專案的獎金也屬於這個超人的。
（2）小的團隊。客戶雇用5到
10個程式設計師和乙個專案經理來完成**的建設或者應用程式的構造。他們之間是一種契約關係。一旦合同結束，他們之間的這種契約關係也就結束了，除非他們又籤了乙個新的合同。
（3）大團隊。乙個被公司雇用的超過一百人的團隊，他們的工作可能是開發乙個新產品，或者為公眾提供相關的服務。
這三種型別的專案在團隊大小，組織結構以及契約關係都存在著很大的不同，這些不同點決定了其管理方法的不同。因此，當你的專案和這幾個例子都不同的時候，那麼你的專案會成為一種很重要的參考。
3.1.2
你的公司如何影響你的計畫
通過以上三種型別的專案，我們可以驗證一下專案計畫最基本的原則。在任何乙個專案裡面，都有一些專案成員必須了解的問題。你可能不太喜歡這些問題的答案，但是你和你的團隊必須清楚的了解它們是什麼。許多專案計畫的失敗都是由於在這些基本問題上沒有達成一致或者根本忽視了這些問題。
（1）誰負責需求
有些人需要定義需求並且使這些需求能夠得到承認（客戶或者
vip）。在超人的例子裡面，這很簡單，他可以做完所有的事情，當然也包括需求定義。而在乙個小的團隊中，客戶會對需求甚至設計都進行嚴格的控制。最後輪到大團隊了，這種情況下，公司內部可能會有專門的組織或者部門來完成這項工作，在這樣的團隊中，有些人可能專注於上層的需求（這是一輛運動型的卡車），而另外一些人會關注底層的需求（它的速度應該達到
20英里
/加侖，並且應該是四輪驅動的）。
（2）誰負責設計
和需求類似，有些人會負責設計的工作。設計和需求不同的地方在於，針對一種需求你可能有幾種不同的設計。設計和需求相同的地方在於設計的過程中，你也需要和幾個不同的組織或者部門進行溝通協商。可能會有乙個人或者乙個小組來負責推進設計的過程，而另外一些人則負責對第一組人的工作進行指導和反饋。但是要注意設計的技能包羅永珍，所以往往負責設計的人並不一定具有這方面的天分。
（3）誰負責技術
技術責任者被定義為那些確定專案所要使用的工程方法的人，包括程式語言，開發工具以及技術架構。許多關於技術的決定會影響到需求，設計和預算。設計和技術之間存在著很微妙的差別：用什麼去實現一件事情往往和怎麼去實現這件事情密不可分。在某些公司裡面，負責技術的人往往也負責需求和設計。而在另外一些公司，負責技術的人是乙個輔助的角色。當然最理想的狀態是，各個角色之間是平等的合作關係。
（4）誰負責預算
向乙個專案新增或者刪除資源可以和其他的角色分開。例如，在團隊比較小的情況下，雖然團隊可以決定需求和設計，但是他們想要更多的預算的話，就需要和客戶商量確定。
（5）需求和設計多久被檢查一次，以及如果確定檢查之後的修改
這個問題的答案主要依賴於前面的問題。參與需求，設計和預算的人越多，我們就需要耗費更多的精力來使這些相關者保持一致。按照慣例，你擁有的權力越小，那麼你就需要花費更多的時間檢查和確認你的決策，當然這其中也包括如果修正的你需求和設計。
雖然我定義了幾種不同的角色，但是乙個人也可能同時擔當其中的乙個或者多個角色。但是，大多數情況下，這些角色會分配給那些小組的領導者。當然如果這些角色分配的越複雜，你就需要更多的努力來使你的計畫行之有效。在第
16章，我會闡述如何處理過多的角色分工的情況。但是目前，你只需要認識到計畫需要包含這麼多的角色就可以了。
3.1.3
一般的計畫支付
想要獲得準確的需求，你必須把它們記錄下來。雖然有許多方法可以完成這件事情，但是在這裡我不會指定特定的方法。最重要的是捕獲正確的資訊，正確的人員可以輕鬆地討論它，以及明確的分工。如果你記錄的需求能夠完成這些要求，那很好。如果不行的話，那就需要考慮其他的方法來記錄你的需求了。
作為參考，我會提及一些普遍使用的記錄需求和計畫的方法。一般情況下，為了表達同一種意思，不同的公司可能會使用不同的詞語，如果你能掌握其中的本質含義的話，那麼這些將不會成為你的障礙。有時候，你會發現一些不太正式的需求文件，譬如「這個地方，你去問弗雷德好了」之類的話。而另外一些人可能會把這些需求分割成許許多多的部分。
（1）市場需求文件（
mrd）
這是由商業或者市場小組作出的分析文件。目的是為了捕獲商機以及專案如何實現這些商機。在一些公司，這些文件是決策者身邊的乙份參考文件。而在另外一些公司，這些文件是專案定義的核心，專案的所有事情都是圍繞這些資料來完成的。
mrds
為專案內容的定義提供了幫助。
（2）目標/
範圍文件
目標文件就是把乙個專案的內容包裝成乙個單一的整體。如果有
mrd的話，那麼目標文件將會延續
mrd中的內容。目標文件定義了專案的目標，專案的意義，以及專案的高階特性，需求以及期限（見第四章）。目標文件直接定義了專案的內容。
（3）式樣書
這些文件定義了專案可能帶來的成果。好的式樣書是按照需求做出來的。通過反覆的設計，也就是通過不斷的修改和改進那些需求來完成式樣書。當你的式樣書提供乙個可行的計畫來滿足專案需求的話，那麼你的式樣書可以說已經完成了。式樣書可以說繼承了目標文件，它定義如果做乙個專案。
（4）wbs
當乙個式樣書定義了工作的細節的時候，那麼
wbs則定義了如何完成這些工作細節的問題，諸如先做什麼工作，誰去做，如果去跟蹤那些細小的工作。
wbs可以非常簡單，同時也可能非常複雜，這主要決定於專案需求。（第
7章和第
13章）會給出一些
wbs的型別。
wbs從乙個團隊的角度定義了如果實現乙個專案。
二，軟體計畫
上邊這幅圖表示軟體計畫的幾大項,下邊我逐個為大家做一下詳細的講述 一,問題定義 1,定義的內容 問題的背景,開發系統的現狀,開發的條件與理由,總體要求,問題的性質,型別轉換,目標,開發條件,環境要求等 2,定義的步驟 需要系統分析員到問題現場，1，聽取使用者對系統的要求 2，調查開發的背景理由 3，...
軟體測試計畫
1.測試計畫是什麼？是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源 時間 風險 測試範圍和預算等方面的綜合分析和規劃，保證有效的實時軟體測試。2.為什麼要制定測試計畫？1 對專案執行過程過程中的風險進行分析，並制定相關的應對策略 2 把知識和經驗轉化為執行任務的具體方法 3 促進團隊間關...
軟體測試計畫
xx公司 2020 01 01 文件管理 合理地管理主文件，確保文件版本的及時更新，同時保持備份文件和源文件的一致性。版本管理 本版本修訂日期 2019 08 12 生效日期 2019 08 12 版本 生效日期 變更內容 編制人 v1.0 2020 01 01 初稿編寫完成 xx 範圍標識 本條應...