軟件項目管理(學習筆記)

1.項目與項目管理

項目

1.項目：項目是一次性的、以目標爲導向的（目標明確）、通過項目經理及其團隊工作完成的、存在大量的變更管理。
2.項目的特點：

有明確的目標性
明確的時限性
資源成本的約束性
項目的不確定性
唯一性(一次性)
3.項目的定義：是爲了創造一個唯一的產品或提供一個唯一的服務而進行的臨時性的活動。

項目管理

1.項目管理通俗理解：假設要做一件事情，有一定的約束和目標要求，諸如時間、資金、人力等條件限制，那麼如何在這些約束條件有效地達到我們預想地目標，通過相關的理念、技術方法和工具進行管理的過程就是項目管理。
2.項目管理的定義：使項目能夠按照預定的成本、進度、質量順利完成讓所有干係人（相關的人）得到滿意，而對成本、人員、進度、質量、風險等進行分析和管理的活動。

2.項目管理框架

五大標準化過程組

1.啓動階段：項目的可行性分析、立項(~~確定可以做~~)、招投標、合同簽署
2.計劃階段：範圍定義、進度安排、資源計劃、成本估計、質量保證計劃、風險計劃、實施計劃等
3.實施及控制階段：項目實施、進度控制、費用控制、質量控制、變更控制等
4.結束階段：範圍確認、質量驗收、費用結算與審計、項目資料驗收、項目交接與清算、項目審計與評估、項目總結等

十大知識領域

1.項目整合管理
2.項目範圍管理
3.項目時間管理
4.項目成本管理
5.項目質量管理
6.項目人力資源管理
7.項目溝通管理
8.項目風險管理
9.項目採購管理
10.項目干係人管理

四十七個過程

3.項目啓動

項目類型：
1.合同項目：招投標(~~招標和投標~~)、合同談判、合同簽署，甲乙雙方有合同約束
2.內部項目：確定任務範圍和相關人員進行有效地配合，無合同約束
3.項目干係人分析：分析確定項目相關人員，包括：項目發起人、項目開發人員、測試人員、維護人員、客戶等

初始化項目分析

1.可行性項目分析：根據市場、技術、人員等各資源分析項目地可行性，對分析結果進行認證討論。
2.項目範圍分析：確定項目的功能模塊、邊界範圍等
3.項目干係人分析：分析確定項目相關人員，包括：項目發起人、項目開發人員、測試人員、維護人員、客戶等

生存期模型(常用)

1.瀑布模型：通過設計一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那麼最好“返回”上一個階段並進行適當的修改，項目開發進程從一個階段“流動”到下一個階段。

瀑布模型適合項目的需求很明確、解決方案也很明確的短期項目。
2.原型模型：原型模型即樣品模型，先借用已有系統作爲原型模型，通過“樣品”不斷改進，使得最後的產品就是用戶所需要的。
原型模型採用逐步求精的方法完善原型，使得原型能夠“快速”開發，避免了像瀑布模型一樣在冗長的開發過程種難以對用戶的反饋做出快速的響應。

原型模型適用於在項目開始前，項目的需求不明確的的項目。
3.增量模型：增量模型融合了瀑布模型的基本成分(重複應用)和原型實現的迭代特徵，該模型採用隨着日程時間的進展而交錯的線性序列，每一個線性序列產生軟件的一個可發佈的“增量”。當使用增量模型時，第1個增量往往是核心的產品，即第1個增量實現了基本的需求，但很多補充的特徵還沒有發佈。客戶對每一個增量的使用和評估都作爲下一個增量發佈的新特徵和功能，這個過程在每一個增量發佈後不斷重複，直到產生了最終的完善產品。

增量模型適用於在項目開始前，明確了需求的一部分，但是需求可能會發生變化、對於時常和用戶把握不是很準，需要逐步瞭解、對於有龐大和複雜功能的系統進行功能改進，就需要一步一步實施的項目。

項目立項

1.項目經理的角色：項目組織的領導者、管理者、決策者、分析者、計劃者、控制者、組織者、評價者、協調者。
2.項目經理的責任：項目計劃；組織實施；項目控制
3.項目立項(相關文檔)
---->項目章程：確認項目存在的文件，包括對項目的確認、對項目經理的授權和項目目標的概述等
---->項目立項申請報告：明確項目的目標、時間、項目使用的資源和經費，而且得到執行該項目經理和項目發起人的認可
---->召開項目立項會：通常由公司PMO(項目管理辦公室)組成立項會，對項目調研、範圍、項目經理等進行確定授權、評審，最後要有評審報告

4.項目計劃

項目計劃包括：範圍計劃、進度計劃、成本計劃、質量計劃、人力資源計劃、溝通計劃、風險計劃

項目計劃的重要性：

範圍計劃

項目範圍的管理是對項目應該包括什麼和不包括什麼進行相應的定義和控制。它包括用以保證項目能按要求的範圍完成所涉及的所有過程，包括：確定項目的需求、定義規劃項目的範圍、範圍管理的實施、範圍的變更控制管理以及範圍的合適。

WBS任務分解
WBS(工作分解結構)就是將一個項目按一定的原則分解，項目分解成任務，任務再分解成一項項的工作，再把每一項工作分配到每個人的日常活動種，直到分解不下去爲止
即：項目—>任務----->工作----->日常活動
工作分解結構以交付成果爲導向對項目要素進行的分組，它歸納和定義了項目的整個工作範圍，每下降一層代表對項目工作的更詳細定義。
WBS總是處於計劃過程的中心，也是制動進度計劃、資源需求、成本預算、風險管理計劃和採購計劃等的重要基礎。

工作包：WBS最底層的項目可交付成果稱爲工作包(~~不能再細分的任務~~)
工作包特定：
1.工作包可以分配給另一位項目經理進行計劃和執行
2.工作包可以通過項目的方式進一步分解爲子項目的WBS
3.工作包可以由唯一的一個部門或承包商負責。用於在組織之外分包時，稱爲委託包。
工作包的定義應考慮80小時或兩週法則，即任何工作包的完成時間應當不超過80小時。在每個80小時或少於80小時結束時，只報告該工作包是否完成。通過這種定期檢查的方法，可以控制項目的變化。
任務分解原則
1.將主題目標逐步細化分解，最底層的日常活動可直接分派到個人去完成
2.每個任務原則上要求分解到不能再細分爲止
3.日常活動要對應到人、時間和資金投入
任務分解標準
1.分解後的活動結構清晰，從樹根到樹葉一目瞭然，儘量避免盤根錯節
2.邏輯上形成一個大的活動，集成了所有的關鍵因素包含臨時的里程碑和監控點，所有活動全部定義清楚，要細化到人、時間和資金投入
WBS任務分解實例

進度計劃

進度是對執行的活動和里程碑指定的工作計劃日期表。
進度管理是爲了確保項目按期完成所需要的過程。
按時完成項目是項目經理最大的挑戰之一。
時間是項目規劃種靈活性最小的因素。(~~時間問題不可商量~~)
進度問題是項目衝突的主要原因，尤其子啊項目的後期。
1.進度計劃管理過程
---->活動定義：確定爲完成項目的各個交付成果所必須的諸項具體活動
---->活動排序：去欸的那個任務依賴、前置任務、里程碑(里程碑顯示項目進展種的重大工作完成)
---->活動歷時估計：每個任務的歷時估計、項目總歷時估計，可採用定額算法、經驗算法
---->任務資源估計：每個任務需要的資源類型和數量有一定的考慮，這些資源包括：人力資源、設備資源、其他資料資源
2.關鍵路徑：關鍵路徑是項目計劃中最長的路線。它決定了項目的總實耗時間。項目經理必須把注意力集中於優先等級最高得任務，確保它們準時完成，關鍵路徑上得任何活動得推遲將使整個項目推遲。向關鍵路徑要時間，向非關鍵路徑要資源。所以再進行項目操作的時候確定關鍵路徑並進行有效的管理是至關重要的。
3.里程碑：在進度時間表上設立一些重要的事件檢查點，這樣一來，就可以在項目執行過程中利用這些重要的時間檢查點來對項目的進度進行檢查和控制。這些重要的時間檢查點被稱作項目的里程碑。

成本計劃

1.資源計劃編制：確定項目需要的資源種類和數量
2.成本估算：編制一個爲完成項目各活動所需要的資源成本的近似估算
3.軟件項目規模：軟件項目規模即工作量，是從如軟件項目範圍中抽出的軟件功能，然後確定每個軟件功能所必須執行的一系列軟件工程任務。包括：軟件規劃，軟件管理，需求，設計，編碼，測試以及後期的維護等任務
4.規模的單位：
---->LOC(Loc of Code):源代碼程序長度的測量，單位K代碼行
---->FP(Function Point):用系統的功能數量來測量
---->人月(一人在一月完成的功能月)
---->人天
---->人年
5.軟件的規模和成本的關係：規模是成本的而主要因素，是成本估算的基礎
6.估算：算法不是很準確的，有誤差的；經驗(歷史)數據非常重要；不要太迷信數學模型
7.成本估算：直接估算(與具體項目相關的成本)；簡介成本(不能具體到某個項目中的成本，可以分攤到各個具體項目中的成本，例如培訓、房租水電、員工福利等)

質量計劃

1.質量的多種定義：

符合目的或者用途
用戶的感覺就是質量
符合顧客在其合理價格下對產品的要求
產品或者服務滿足明確和隱含需要能力的性能特性的總體
2.質量定義：質量是滿足要求的程度，包括符合規定的要求和滿足顧客的需求
3.軟件質量：軟件滿足明確說明或者隱含的需求的程度。如：
---->明確說明：查詢功能
---->隱含說明：查詢速度
4.質量的重要性：軟件危機的主要矛盾；低質量的軟件就像定時炸彈；低質量的產品增加成本；質量是生命也是信譽
5.質量管理過程：

6.質量保證：確定項目應達到的質量標準；決定如何滿足質量標準的計劃安排和方法；通過評價項目整體效績，建立對質量要求的新人；提供項目和產品可視化的管理報告
7.代碼質量活動
---->靜態分析：不實際運行程序，而是通過檢查和閱讀等手段來發現錯誤並評估代碼質量的軟件測試技術。也稱爲靜態測試技術。
---->動態測試：單元測試、集成測試、系統測試
---->缺陷追蹤：使用項目管理工具(如ClearQuest)跟蹤缺陷解決程度
8.需要有質量計劃文檔

人力資源計劃

1.組織結構的主要類型:職能型;項目型;矩陣型

職能型

優點：
1.可以充分發揮職能部門的資源集中優勢
2.部門的專家可以同時爲部門內不同項目使用
3.便於相互交流，相互支援
4.可以隨時增派人員
5.可以將項目和本部門的職能工作融爲一體
缺點：
1.項目和部門發生利益衝突，職能部門更重視本部門的目標、會忽視項目目標
2.資源平衡會出現問題
3.權力分隔不利於各個職能部門的交流和團結協作
4.行政隸屬關係使得項目經理沒有充足的權利

項目型

優點：
1.項目經理對項目可以負全責
2.項目目標單一，可以以項目爲中心，有利於項目順利進行
3.避免多重領導
4.組織結構簡單，交流簡單，快速
缺點：
1.資源不能共享
2.各個獨立的項目處於相對封閉狀態，不利於公司政策的貫徹
3.對項目組織的成員缺少一種事業上的連續性和安全感
4.項目組織之間處於分隔狀態，缺少信息交流

矩陣型

優點：
1.專職的項目經理負責整個項目，以項目爲中心
2.公司的多個項目可以共享各個職能部門的資源
3.即利於項目目標的實現，又利於公司目標方針的貫徹
4.項目成員的顧慮減少了
缺點：
1.容易引起職能經理和項目經理權力的衝突
2.資源共享也能引起項目之間的衝突
3.項目成員有多頭領導

2.人員管理計劃：人員管理計劃描述了項目團隊的組織結構，團隊成員及角色、成員加入到團隊和離開團隊的時間、人員培訓計劃等。作爲項目計劃一部分，詳細程度因項目而異。

溝通計劃

1.基本原則：及時性；準確性；完整性；可理解性
2.溝通方式：書面溝通和口頭溝通；語言溝通和非語言溝通(UML)；正式溝通和非正式溝通；單向溝通和雙向溝通；網絡溝通
3.溝通計劃編制：溝通需求分類；溝通的內容；溝通方法；溝通職責；溝通進度；溝通計劃維護

風險計劃

1.定義：損失發生的不確定性；對潛在，未來可能發生的損害的一種度量
2.風險的三要素：一個事件；事件發生的概率；事件的影響
3.風險類型
---->預測角度：已知風險；可預測風險；不可預測風險
---->範圍角度：項目風險；技術風險；商業風險
4.風險管理的四個過程：風險識別---->風險評估---->風險規劃----->風險控制----->風險識別
5.風險識別：
---->風險識別領域：產品規模；商業影響；客戶相關；過程定義；開發技術；開發環境；人員數目及經驗
---->識別方法(結合使用)：頭腦風暴法；情景分析法；面談法；風險條目檢查表
6.風險評估：確定風險發生概率的估計和評價，項目風險後果嚴重程度的估計和評價，項目風險影響範圍的分析和評價，以及對項目風險發生時間的估計和評價
7.風險規劃
---->風險概率值：沒有可能(0)；確定(1)
---->風險概率度量：高、中、低；極高、高、中、低、極低；不可能、不一定、可能和極可能等等
8.風險後果：風險影響項目目標的嚴重程度；從無影響到無窮大
---->風險後果度量：高、中、低；極高、高、中、低、極低；災難、嚴重、輕微、可忽略等等
8.風險控制：針對風險分析的結果，爲提高實現項目目標的機會，降低風險的負面影響而指定風險應對策略和應對措施的過程，即指定一定的行動和策略來對付、減少、以至於消滅風險事件
9.風險措施
---->迴避風險：對所有可能發生的風險儘可能的規避，採用主動放棄或者拒絕使用導致風險的方案。例如採用新技術
---->轉移風險：爲了避免承擔風險損失，有意識將損失或與損失有關的財務後果轉嫁出去的方法。例如出售、分包。
---->損失控制：損失預防、損失抑制
---->自留風險：由項目組織自己承擔風險事故所致損失的措施

5.項目實施與控制

項目實施與控制---->配置管理---->需求分析---->系統設計---->系統開發---->系統測試

項目實施與控制

1.項目實施與控制核心：產品規格/質量，進度，成本
2.項目跟蹤控制過程：

3.項目跟蹤控制程度：項目中可以接受出現偏差；注意力應放在緊急的必須要解決的問題上。
參與項目進展報告，周例會會議紀要。(控制項目進度)

配置管理

軟件項目中可能遇到如下問題：

找不到某個文件的歷史版本
開發人員使用錯誤的版本修改程序
開發人員未經授權修改代碼或文檔
人員流動，交接工作不徹底
已修復的Bug在新版本中出現
無法重新編譯某個歷史版本
因協同開發中，或者異地開發，版本變更混亂導致整個項目失敗
配置管理定義：記錄軟件產品的演化過程；確保軟件開發者在軟件生命週期中的各個階段都能得到精確的產品配置；最終保證軟件產品的完整性，一致性，追溯性，可控性
作用：版本管理、變更管理
配置項：軟件配置項是項目定義其受控於軟件配置管理的款項。(即管理內容)包括：系統規格說明書；軟件需求規格說明書；設計規格說明書；源代碼；測試規格說明書；
配置項版本：
工具：ClearCase、SVN、VSS、CVS等
配置管理委員會：配置項標識、跟蹤；配置管理環境建立；變更管理；配置狀態統計；配置管理計劃
軟件需求：需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什麼事情，完成什麼樣的功能，達到什麼性能。

軟件需求規格說明書:需求分析工作完成的一個基本標誌是形成了一份完整的、規範的需求規格說明書；需求規格說明書的編制是爲了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解，實質成爲整個軟件開發的基礎。
需求總在變化解決方案：確定需求變更控制過程；建立需求變更控制委員會(SCCB);進行需求變更你影響分析；跟蹤所有收需求變更影響的工作產品；建立需求基準版本和需求控制版本文檔；維護需求變更的歷史記錄；跟蹤每項需求的狀態；衡量需求穩定性

系統設計

系統設計包括概要設計和詳細設計

測試

測試包括：單元測試；集成測試；系統測試

6.項目結束

項目結束包括項目結束和系統維護兩方面
1.成功與失敗的標準：可交付成果如何；是否實現目標；是否達到項目業主的期望
2.制定結束要做的工作：
---->指定結束計劃(項目計劃的一部分，與客戶一同評審項目結束計劃，細化並實施項目結束計劃)
---->完成收尾工作：範圍確認，項目驗收，費用結算，合同終結
---->項目結束評審(內部評審)：是否實現項目目標，是否遵循項目進度，是否在預算成本內完成項目，項目進度過程中出現的問題以及解決措施是否合適，問題是否得到解決，從該項目的事件中可以得到哪些經驗和教訓
---->項目總結：總結成功的經驗和失敗的教訓；軟件項目歷程文件(將項目中的有用信息總結分類，放入信息庫，它是軟件項目記錄的資料)