軟件項目管理整理

1、軟件項目管理RoadMap項目初始-項目計劃-項目執(zhí)行控制-項目結(jié)束第一篇 軟件項目初始第一章 軟件項目初始過程軟件項目啟動1、 項目立項明確項目的目標、時間表、項目使用的資源和經(jīng)費，而且得到執(zhí)行該項目的項目經(jīng)理和項目發(fā)起人的認可Make or buy 決策：P18合同項目：甲方合同環(huán)境：招標書定義(采購需求定義)、供方選擇、合同簽署1） 招標書定義：需求申請-需求定義-商務(wù)條件確定-驗收標準確定-資料匯集-采購需求認可-編寫招標文件-招標文件 P192） 乙方選擇：招標文件-招標-收集供方的建議書-評定供方-最終供方確定-最終供方名單-建議書 P213） 合同簽署：合同草案-談判日程確定-合

2、同草案提交-合同條款協(xié)商-合同簽署文本確定-合同簽署文本審閱-合同簽署-合同簽署文件-任務(wù)書下達-任務(wù)書任務(wù)書任務(wù)書 P22乙方合同環(huán)境：項目分析、提交建議書、合同簽署1） 項目分析任務(wù)書/招標書-需求管理者確定-需求分析-需求分析評審-項目規(guī)模估算-項目風險分析-項目初步實施規(guī)劃-初步實施規(guī)劃評審需求分析報告/項目初步計劃 P232） 提交建議書需求分析報告/項目計劃-技術(shù)能力要求確定-人力資源要求確定-實現(xiàn)環(huán)境要求確定-資金。管理要求確定-企業(yè)能力判定-評估結(jié)果評審-能力評估結(jié)果-需求成熟度評估-用戶支持保證評估-用戶資金保證評估-可行性分析-項目決策-編寫項目建議書-參加競標-項目投標書

3、 P233） 合同簽署合同草案-談判日程確定-合同草案提交-合同條款協(xié)商-合同簽署文本確定-合同簽署文本審閱-合同簽署-合同簽署文件-任務(wù)書下達-任務(wù)書任務(wù)書任務(wù)書 內(nèi)部項目企業(yè)內(nèi)部項目實施的核心是確定任務(wù)范圍和相關(guān)各方進行有效地配合。這將通過相關(guān)各方之間的協(xié)議來調(diào)整。因此，在內(nèi)部項目實施中，僅僅在合同簽署過程中定義了一個協(xié)議簽署過程。此處協(xié)議可視作為“合同”，但無特別的商業(yè)約束。其它方面可參考甲乙方的過程。2、 授權(quán)項目項目章程：確認項目存在的文件，包括對項目的確認、對項目經(jīng)理的授權(quán)和項目目標的概述等。項目經(jīng)理角色：項目組織的領(lǐng)導(dǎo)者、項目組織的管理者、項目組織的決策者、項目組織的分析者、項目

4、組織的計劃者、項目組織的控制者、項目組織的組織者、項目組織的評價者、項目組織的協(xié)調(diào)者項目經(jīng)理的責任：開發(fā)計劃、組織實施、項目控制3、 初始項目分析一個初始的項目范圍說明，相當于確定初始的項目需求說明書，對項目需求進行初步的描述，將來編寫需求規(guī)格說明書的時候，可以在此基礎(chǔ)上進行詳細的描述。4、 生存期模型常用生存期模型：1） 瀑布WaterfallWaterFall model適合的項目：在項目開始前,項目的需求很明確在項目開始前,解決方案也很明確類似的項目如：公司的財務(wù)系統(tǒng)、庫存管理系統(tǒng)、短期項目2） V模型V-shaped V模型適合的項目：在項目開始前,項目的需求很明確在項目開始前,解決方

5、案也很明確對系統(tǒng)的性能安全很嚴格的項目類似的項目如：航天飛機等、公司的財務(wù)系統(tǒng)3） 原型Prototyping4）增量Incremental5）螺旋式Spiral6）快速應(yīng)用開發(fā)RAD7）漸近式階段最常用的漸進式階段模型綜合了增量模型和螺旋式模型的一個實用模型漸進式前進、階段式提交階段性完成規(guī)劃：漸進式階段模型的特點：q 階段式提交一個可運行的產(chǎn)品q 關(guān)鍵的功能更早出現(xiàn)q 早期預(yù)警問題，避免軟件缺陷不知不覺的增長q 減少報告負擔q 階段性完成可以降低估計失誤q 階段性完成均衡了彈性與效率 漸進式階段模型適合的項目：q 可以適合任何規(guī)模的項目，主要是中型或大型項目q 希望隨時看到未來的項目 8）

6、Code and fix選擇生存期的步驟q 熟悉各種生存期模型q 評審、分析項目的特性q 選擇適合項目的生存期模型q 標識生存期模型與項目不一致地方,并進行裁減第二篇 軟件項目計劃沒有計劃的情況 有計劃的情況： 計劃的重要性：PMI：項目成功的三大要素（法寶）：計劃、計劃、計劃計劃是通向項目成功的路線圖進度計劃是最重要的計劃編制進度計劃的三步曲：q 任務(wù)分解（WBS）-范圍基準q 成本估算q 資源、進度安排后面兩個是成本基準，進度基準RoadMap第二章 軟件項目范圍計劃1、 軟件需求管理過程軟件需求：需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達到什

7、么性能。軟件需求的層次：項目失敗的原因分析：軟件需求管理的過程：需求工程基本任務(wù)：需求獲?。盒枨蠓治龆x：需求分析是為最終用戶所看到的系統(tǒng)建立一個概念模型，是對需求的抽象描述。 需求分析模型：需求規(guī)格：q 需求分析工作完成的一個基本標志是形成了一份完整的、規(guī)范的需求規(guī)格說明書q 需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎(chǔ)。軟件需求規(guī)格說明的原則：q 從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)”q 采用一定的規(guī)格說明語言q 如果被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中q 規(guī)格說明應(yīng)

8、該包括系統(tǒng)運行環(huán)境q 規(guī)格說明應(yīng)該是一個認識模型q 規(guī)格說明應(yīng)該容許不完備性并允許擴充需求驗證：需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實際可行的嗎？需求是必要的嗎？需求是可檢驗的嗎？需求是可跟蹤的嗎？最后的簽字需求變更管理：1. 確定需求變更控制過程2. 建立變更控制委員會(SCCB)3. 進行需求變更影響分析4. 跟蹤所有受需求變更影響的工作產(chǎn)品5. 建立需求基準版本和需求控制版本文檔6. 維護需求變更的歷史記錄7. 跟蹤每項需求的狀態(tài)8. 衡量需求穩(wěn)定性9. 管理和控制需求基線的過程10. 需求變更控制系統(tǒng)一個正式的文檔，說明如何控制需求變更建立變更審批系統(tǒng) 2、 需求建模

9、的基本方法原型方法結(jié)構(gòu)化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌?、 任務(wù)分解過程輸入-分解-WBSWBS (Work Breakdown Structure)q 任務(wù)分解的過程將一個項目分解為更多的工作細目或者子項目，使項目變得更小、更易管理、更易操作。q 任務(wù)分解的結(jié)果WBS（任務(wù)分解結(jié)構(gòu)）。 q WBS面向可交付成果的。q Work packages（工作包）WBS的最低層次的可交付成果WBS實例PMI defines WBS:q 是面向可交付成果的對項目元素的分組,它組織并定義了整個項目范圍.不在WBS中包括的工作就不是該項目的工作q 它是一個分級的樹型結(jié)構(gòu)，是對項目由粗到細的分解過程

10、。工作結(jié)構(gòu)每細分一個層次表示對項目元素更細致的描述q WBS的最低層次的可交付成果q 工作包應(yīng)當由唯一一個部門或承包商負責q 這一交付成果可以分配給另外一位項目經(jīng)理進行計劃和執(zhí)行,或者通過子項目的方式完成工作包可進一步分解為子項目的WBS或各個活動WBS類型: 清單、圖表清單類型： 1. 變化計數(shù)器1.1   比較兩個版本的程序1.1.1   預(yù)處理1.1.2   文件比較1.1.3   結(jié)果處理1.2    找出修

11、改后的程序中增加和刪除的代碼行1.2.1  找出增加的代碼行1.2.2   找出刪除的代碼行1.3     統(tǒng)計修改后的程序中增加和刪除的代碼行數(shù)1.3.1    統(tǒng)計增加代碼行數(shù)1.3.2    統(tǒng)計刪除代碼行數(shù)1.4       統(tǒng)計總的代碼行數(shù) 1.5      設(shè)定標記以指示修改的

12、次數(shù)1.6    在程序的頭部增加修改紀錄任務(wù)分解步驟：1. 確認并分解項目的組成要素2. 確定分解標準3. 確定分解是否詳細4. 確定項目交付成果5. 驗證分解的正確性(建立編號)WBS編號系統(tǒng)：分解標準：生存期功能組成項目的組織單位。分解標準應(yīng)統(tǒng)一：學(xué)生管理q 按照生命期分解q 規(guī)劃q 需求q 設(shè)計q 編碼q 測試q 提交q 按照產(chǎn)品組成分解q 1.1        招生管理q 1.2       &#

13、160; 分班管理q 1.3         學(xué)生檔案管理q 1.4         學(xué)生成績管理 q 不能同時使用兩種標準進行分解q 招生管理q  分班管理q  學(xué)生檔案管理q 學(xué)生成績管理 q 規(guī)劃q 需求q 設(shè)計q 編碼q 測試q 提交4、 任務(wù)分解方法任務(wù)分解方法：p 模版p 類比p 自上而下p 自下而上5、 任務(wù)分解檢驗檢驗分解結(jié)果的標準：最底層的要素是否是實現(xiàn)目標的充分必要條

14、件最底層要素是否有重復(fù)的每個要素是否清晰完整定義最底層要素是否有定義清晰的責任人,是否可以進行成本估算和進度安排WBS的指南：q WBS分解的規(guī)模和數(shù)量因項目而異、因項目經(jīng)理而異q 收集與項目相關(guān)的所有信息q 參看一下類似的項目的WBS,與相關(guān)人員討論q 可以參照模板q 最低層是可控的和可管理的，但是避免不必要的過細，最好不要超過7層，q 軟件項目推薦分解到40小時的任務(wù)q 每個Work package必須有一個提交物q 定義任務(wù)完成的標準q 每個WBS必須有利于責任分配q 可以準備WBS的字典q 最后與相關(guān)人員進行評審WBS字典內(nèi)容：WBS意義：q 提供了項目范圍基線,是范圍變更的重要輸入q

15、 為評估和分配任務(wù)提供具體的工作包q 進行估算和編制項目進度的基礎(chǔ)q 對整個項目成功的集成和控制起到非常重要的作用網(wǎng)管系統(tǒng)（圖表）分解實例：你是某項目的項目經(jīng)理,這個項目是為用戶創(chuàng)建一個新的郵件服務(wù)器以及在所有100個工作站上部署相應(yīng)的郵件客戶端（要滿足用戶的期望）。其中，2個服務(wù)器需要重新購置，而客戶端的機器已經(jīng)存在。請?zhí)峤蝗蝿?wù)分解結(jié)果WBS第三章 軟件項目進度計劃承上啟下：q 編制進度計劃的三步曲q 項目分解q 項目規(guī)模估算q 資源、進度安排1、 進度管理的基本概念及過程進度是對執(zhí)行的活動和里程碑制定的工作計劃日期表進度管理是為了確保項目按期完成所需要的過程.進度管理的重要性q 按時完成項

16、目是項目經(jīng)理最大的挑戰(zhàn)之一q 時間是項目規(guī)劃中靈活性最小的因素q 進度問題是項目沖突的主要原因，尤其在項目的后期。軟件項目進度(時間)管理過程q 活動定義（Activity definition）q 活動排序（Activity sequencing）q 活動歷時估計（Activity duration estimating）q 制定進度計劃（Schedule development）q 進度控制（Schedule control）-項目跟蹤活動定義：確定為完成項目的各個交付成果所必須進行的諸項具體活動 項目活動排序：1）項目各項活動之間存在相互聯(lián)系與相互依賴關(guān)系, 2）根據(jù)這些關(guān)系進行適當?shù)捻樞虬才徘爸没顒樱ㄈ蝿?wù)）-后置活動（任務(wù)）任務(wù)(活動)之間的關(guān)系：任務(wù)(活動)之間排序的依據(jù)：q 強制性依賴關(guān)系q 軟邏輯關(guān)系q 外部依賴關(guān)系q 里程碑You must determine dependencies