軟體開發wbs
軟體項目計劃：
計劃：
業務計劃、資源計劃
PPL、WBS、配置管理計劃、風險管理計劃、測試策略和缺陷預防計劃
所有的評審文檔
需求：
SRS、STP
所有的評審文檔
概設：
HLD、ITP
所有的評審文檔
詳設：
LLD、UDP
所有的評審文檔
編碼：
代碼完成、單元測試報告完成
所有的評審文檔
集成測試：
集成測試報告完成
系統測試：
系統測試報告完成
㈡ 用IT項目管理的wbs軟體對一次外出野炊做一個相應的計劃，還有經費預算
IT項目管理的wbs軟體
Web項目管理軟體可以試下維普時代的，這家的項目管理軟體是基於網路的，B/S架構，功能齊全，適用性廣。
㈢ 建立WBS的原則
WBS的設置原則
WBS的分解應按照實際工作經驗和系統工作的方法、工程的特點、項目管理者的要求進行，其基本原則是：
1) 應在各層次上保證項目內容的完整性，不能遺漏任何必要的組成部分。
2) 一個項目單元只能從屬於某一上層單元，不能同時屬於兩個上層單元。
3) 項目單元應能區分不同的責任者和不同的工作內容，應有較高的整體性和獨立性。
4) 應考慮WBS與承包方式、合同結構的影響。
5) 能夠符合項目目標管理的要求，能方便的應用工期、質量、成本、合同、信息等手段。
6) WBS不要太多層次，以四至六層為宜。最低層次的工作包的單元成本不宜過大、工期不要太長。
可以看出，無論用什麼樣的軟體編寫計劃，WBS都是我們首先要考慮的問題。在P3E/C軟體里，專門設置了WBS的窗口，用於編制項目的WBS。反之，微軟公司的PROJECT軟體沒有設計這樣的窗口，而是在編輯任務（作業）的過程中，考慮設置任務（作業）的大綱。應該說，大綱比起WBS的功能還是有所遜色的。這一問題在PROJECT98就已經存在，但直到PROJECT2003也沒有得到解決；而P3就已經有了WBS，而在P3E/C里的WBS得到了很大加強，這反映了PRIM***ERA公司與微軟公司在對WBS作用的認識存在著差異，PRIM***ERA公司更加重視工程的規范化管理，而微軟公司更強調軟體的操作的方便。
WBS計劃
項目計劃是如何體現工作范圍的呢？常用的方式是通過工作分解的方式，將工作范圍細分為活動，然後對每項活動分配時間和資源，而活動結果的總和就是工作范圍，我們將這種分解的計劃稱為WBS（Work Breakdown Structure，工作分解）計劃。制定WBS計劃是制定項目計劃最主要的活動。
制訂WBS計劃主要分為以下三個步驟：
第一，分解工作任務。將一個總的工作范圍（軟體項目XXX）逐漸細分到合適的粒度，以便對任務計劃、執行和控制。對於軟體項目來說，分解工作任務不是一項單純的計劃活動，而是要根據項目的特點決定工作任務的分解結構。實際工作中更多地會考慮技術因素來確定工作分解結構的形式。
第二，定義活動依賴關系。確定了項目中要完成哪些活動以後，需要對這些活動之間的依賴關系做出定義。活動之間的依賴關系取決於實際工作的要求，不同活動之間的依賴關系決定了活動的優先順序及其重要性。活動依賴關系是確定項目關鍵路徑和活動浮動時間的必要條件，定義活動間依賴關系的目的是確定每一項活動所需的輸入、輸出關系。
第三，分配時間和資源。完成工作任務分解並定義了活動的依賴關系後，應該為每項活動分配相應的時間和資源。通常活動都會產生自己的交付物。為活動分配時間可以採用自下而上和自上而下兩種不同的方法。自下而上是先估計最小粒度的活動所需要的時間，項目所需的時間則取決於所有項目活動的關鍵路徑時間；自上而下則是確定完成項目所需要的總的時間，然後將時間分配給不同的活動。這兩種方法在實際中都有應用，對於客戶項目，很多情況下只能採取自上而下的方式，因為大多數項目都事先確定好了項目的交付時間。在軟體項目計劃中，資源分配主要指人員的分配，指定了時間資源以後，應該指定人力資源。一項工作任務是否能夠完成，所需要的時間和人員是兩個最主要的變數。在一定的范圍內，時間和人員是可以互換的。即增加人員會縮短工作時間；延長時間會降低對人員的需求量（但這種觀點的害處在於管理者往往會認為所有的活動都可以互換時間和人力資源）。如果已經確定了活動的完成時間，則指定相應的人員作為完成活動的責任人。
㈣ 軟體項目管理中wbs如何分解
分解是按照項目策劃對整個項目進行細分，分到最小單位為止，這個單位以可執行、可評估為標准。
對項目管理的分解就是：出項目可行性分析報告、制定項目計劃書、階段性會議、審核、驗證。
如某信息系統開發項目的一級分解包括：項目管理、需求調查、系統設計、製作和培訓。
㈤ 軟體項目管理作業：提交任務分解結果WBS
問題補充：對需要描述的部分給出WBS字典。
我也急需這個題的答案，高手速度來。