第1章 軟件項目管理概述
什么是項目？
項目特點？
有明確的目標性、明確的時限性、資源成本的約束性、項目的不確定性、唯一性
軟件項目的特點？
軟件是邏輯實體，高度地抽象性；軟件沒有明顯地制造過程；軟件不存在磨損和老化，存在退化問題；軟件開發受外界因素的制約：計算機系統；手工訂制，通用組織仍不健全；軟件本身是復雜的；軟件成本高昂；軟件涉及很多社會因素
軟件項目日常運作活動與項目的區別？
項 目：唯一性、時限性、目標導向、變更管理、項目組織、項目經理負責； 日常運作：重復性、連續性、績效優先、線性管理、職能部門、部門經理負責
軟件管理生命周期與軟件工程生命周期區別?
軟件管理生命周期： 1．啟動 項目獲得授權正式被立項，並成立項目組，宣告項目開始。啟動是一種認可過程，用來正式認可一個新項目或新階段的存在。 2．計划 明確項目范圍，定義和評估項目目標，選擇實現項目目標的最佳策略，制定項目計划。 3．執行 調動資源，完成項目管理計划中確定的工作。 4．控制 監控和評估項目偏差，必要時采取糾正行動，以保證項目計划的執行，實現項目目標。 5．結束 軟件工程生命周期：問題定義、可行性與需求分析、系統設計、程序實現、測試確認、維護支持
項目管理知識體系（PMBOK）9個領域，以及4個核心領域？
四個核心：項目范圍、項目進度、項目成本、項目質量； 九大領域：項目集成管理、項目范圍管理、項目時間管理、項目成本管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理、項目采購管理
第2章 項目的啟動和准備
如何進行項目分析？
前期市場調研 項目調研：1、准備階段：了解用戶行業、資料准備、制訂調研計划。2、撰寫調研報告 需求分析：1、需求收集（功能、性能、安全性、其他），運行環境、人員素質；2、需求說明書（SRS）、規格說明書 需求管理：專人管理需求工程；細化需求；需求確認；嚴格需求變更；界面快速展示 需求分析報告
可行性分析報告包括哪些內容？
技術可行性：全面考慮系統開發過程所涉及的技術問題 盡可能采用成熟技術 慎重引入新技術（新版本） 着眼於具體的環境環境和開發人員 技術可行性評價 經濟可行性： 經濟可行性是指可以使用的資源（人力資源、自然資源、資金條件）可能性；並估算開發成本與費用，預測系統可取得的未來效益，明確是否值得可開發。 風險控制可行性： 定量分析 預期收益
然后甲方：提交建議書，乙方簽訂合同，成立項目研發團隊
項目章程是什么？
項目章程是確認項目存在的文件，包括對項目的確認、對項目經理的授權和項目目標的概述等。 項目要明確以下幾點：項目名稱、項目的重要性、項目目標項目、項目經理、主要項目干系人、項目總體進度安排、項目總體預算、各個職能部門應提供的配合、項目審批要求、本章程的批准
軟件需求/規格說明書的區別？
需求說明：通常是指以用戶語言描述的產品要求。 規格說明：用產品領域的語言描述的產品要求。
幾種常見的合同？
成本補償合同、固定總價/單價合同、功能計費點合同 項目經理的責任?開發計划、組織實施、項目控制
第4章 軟件項目需求管理
項目成功三要素
-
質量、時間、成本
項目范圍的定義
-
軟件項目范圍具體的說包括產品范圍和項目范圍兩方面，產品范圍是指產品、服務或者成果所具有的特性和功能；項目范圍是指為交付具有規定特性與功能的產品、服務或者成果而必須完成的工作。
軟件需求層次?
軟件需求可以分為功能需求和非功能需求，功能需求進一步分為三個層次，業務需求、用戶需求和功能需求，系統需求也是功能需求的一個來源；非功能需求進一步分為業務規則、質量屬性、性能屬性、對外接口、約束條件。
軟件需求獲取方法？
（1）問卷調查 （2）訪談 訪談有經驗的項目參與者、干系人和領域專家，有助於識別和定義項目可交付成果的特征和功能。 （3）引導式研討會 引導式研討會通過邀請主要的干系人一起參加會議，對產品需求進行集中討論與定義。 （4）頭腦風暴 又稱為智力激勵法、自由思考法或集思廣益會，是用來產生和收集對項目需求與產品需求的多種創意的一種技術。 （5）原型法：在獲取一組基本需求之后，快速地構造出一個能夠反映用戶需求的初始系統原型，它使干系人有機會體驗最終產品的模型，而不是只討論抽象的需求陳述。原型法符合漸進明細的理念，因為原型需要重復經過制作、試用、反饋、修改等過程。
需求規格說明書：
1.范圍 2.引用文檔 3.功能需求 4.數據需求 5.非功能需求 6.運行需求
需求管理
-
需求變更流程？ 1.提出變更 2.評估變更 3.決策變更 4.實施變更 5.驗證變更
-
需求跟蹤？ 需求跟蹤有兩種類型的跟蹤，前向跟蹤和后向跟蹤。 4種需求鏈: （1）客戶需求可以向前追溯到系統需求。 （2）可以從系統需求回溯到相應的客戶需求。 （3）從需求追溯到后續工作產品。 （4）從產品部件回溯到需求。 需求跟蹤矩陣內容包括需求代號R001、需求用例UC-28、設計實例Catalog、編碼實例Catalog.sort()、測試用例Search7
第5章 項目進度管理
PERT評審模型五個步驟
-
確定完成項目必須進行的每一項有意義的活動，完成每項活動都產生事件或結果。
-
確定活動完成的先后次序。
-
繪制活動流程從起點到終點的圖形，明確表示出每項活動及其它活動的關系，用圓圈表示事件，用箭頭線表示活動，結果得到一副箭頭線流程圖，稱之為PERT網絡。
-
估算每項活動的完成時間。
-
（1）專家判斷
-
（2）類比估算
-
（3）參數估算
-
（4）三點估算 首先需要估算出進度的3個估算值，然后使用這3種估算值來界定活動歷時的近似區間： 最可能時間（TM）：對所需進行的工作和相關時間進行比較現實的估算，所估算的活動歷時。 最樂觀時間（TO）：基於最好的情況，所估算的活動歷時。 最悲觀時間（TP）：基於最差的情況，所估算的活動歷時。 活動持續時間TE = (TO+4TM+TP)/6，標准差（TP-TO)/6，據此來界定活動歷時的近似區間， 例如，3周±2天
-
-
借助包含活動時間估計的網絡圖，制定出包括每項活動開始和結束日期的全部項目的只程計划。在關鍵路線上沒有松弛時問，沿關鍵路線的任何延遲都直接影響整個項目的完成期限。
項目進度編制的方法？
維持工期不變，資源平衡，使資源強度盡可能平衡 使工期最短,在滿足資源約束條件下 2.資源優化 資源優化（資源平衡和資源平滑）用於調整活動的開始和完成日期，以調整計划使用的資源，使其等於或少於可用的資源。 3．進度壓縮 進度壓縮技術是指在不縮減項目范圍的前提下，縮短或加快進度工期，以滿足進度制約因素、強制日期或其他進度目標。 【趕工】加班等； 【快速跟進】將正常情況下按順序進行的活動或階段改為至少是部分並行開展。例如，在大樓的建築圖紙尚未全部完成前就開始建地基。 線性關系方法 見課本 進度壓縮因子方法 見課本
第6章 項目的估算和成本管理
不同估算方法適合不同階段
-
這些估算方法不會考計算，不現實，要知道每個方法是做什么的
-
初期
-
類比 (自頂向下)估算法；類比法通常用來驗證參數法和自下而上法的結果
-
專家估算法
-
-
計划階段
-
自下而上估算法
-
費時費力
-
-
參數法估算法
-
比較簡單，自下向上法與參數法的估計精度相似
-
-
-
實施階段（包括變更發生）
-
自下而上估算法
-
參數法估算法
-
項目估算方法
-
Delphi專家估算法
-
組織者發給每位專家一份軟件系統的規格說明和一張記錄估算值的表格，請他們估算 專家詳細研究軟件規格說明后，對該軟件提出3個規模的估算值：最小ai、最可能的mi、最大bi 計算每位專家的Ei=(ai+4mi+bi)/6, 綜合結果后:E=E1+E2+…En/n（N:表示N 個專家） 某多媒體信息查詢系統—專家估算 專家1：1，8，9=〉（1+9+4 * 8 ）/6=7（萬元） 專家2： 4， 6 ， 8 =〉（4+8+4*6）/6=6 （萬元） 估算結果=（6+7）/2=6.5 （萬元）
-
-
自下而上估算法
-
三點估算法：對每項工作的工期給出三種預估值：最可能時間、最樂觀時間和最悲觀時間，然后加權平均，計算出其計划時間。 最可能時間Tm：根據以往的經驗，這項工作最有可能用多長時間完成。 最樂觀時間To：當一切條件都順利時該項工作所需時間。 最悲觀時間Tp：在最不利條件下，該項工作需要的時間。 那么計划時間Te的計算公式如下： Te=（To+4×Tm+Tp）/6 標准差=（Tp - To）/6
-
-
類比 (自頂向下)估算法
-
估算人員根據以往的完成類似項目所消耗的總成本（或工作量），來推算將要開發的軟件的總成本（或工作量），然后按比例將它分配到各個開發任務單元中。 使用情況：有類似的歷史項目數據、信息不足（要求不是非常精確)的時候、在合同期和市場招標時 等價代碼行=[(重新設計代碼百分比+重新編碼代碼百分比+重新測試代碼百分比)/3]*已有代碼行
-
-
參數估計法
-
COCOMO模型
-
基本COCOMO模型，是靜態單變量模型，它用一個已經估算出來的源代碼行數L為自變量的函數來計算軟件開發工作量； MM=a(KDSI)^b TDEV=cMM^d 其中，MM為開發工作量（度量單位為人月），TDEV為所需的開發時間（度量單位為月），DSI是項目的源代碼行估計值，不包括程序中的注釋和文檔，KDSI=1000DSI。 一個33.3 KLOC的軟件開發項目，屬於中等規模、半有機型的項目，采用基本COCOMO： a=3.0，b=1.12。 E = 3.0＊L ^1.12 = 3.0＊33.3 ^1.12 = 152 PM
-
中級COCOMO模型，是一個靜態多變量模型，它在用L作為自變量的函數來計算軟件開發工作量的基礎上，再使用成本因素來調整工作量的估算結果； MM=a(KDSI)^bEAF 一個33.3 KLOC的軟件開發項目，屬於中等規模、半有機型的項目，采用中等COCOMO模型 a=3.0，b=1.12。 乘法因子＝0.700.851……1.15=1.09 E = 3.0＊L ^1.12 = 3.0＊33.3 ^1.12 ＊ 1.09=166PM
-
詳細COCOMO模型，包括了中級COCOMO模型的所有特性，並結合成本因素對軟件開發過程中的每一個步驟的影響進行評估。
-
-
IBM估算模型
-
E = 5.2×L0.91 D = 4.1×L0.36 S = 0.54×E0.6 DOC = 49×L1.01 其中L是源代碼行數（以KLOC計），E是工作量（以PM計），D是項目持續時間（以月計），S是人員需要量（以人計），DOC是文檔數量（以頁計）。 如一個規模為10KDSI的嵌入型軟件，使用IBM模型進行計算： E = 5.2×100.91=42.27（人月） D = 4.1×100.36=9.84（月） S = 0.54×42.270.6=5.1（人）
-
-
估算工作量的方法
-
項目規模表示： LOC(Line of Code)源代碼程序長度的測量 FP(Function Point)用系統的功能數量來測量 開發工作量估算單位：人月、人天、人年
-
代碼行： 某軟件公司統計發現該公司每一萬行Java源代碼形成的源文件約為250KB。某項目的源文件大小為3.75MB，則可以估計出該項目源文件代碼行大約為15萬行，該項目累計投入工作量為240人月，每人月費用為10000元（包括人均工資、福利、辦公費用等），則該項目中單位LOC的價值為： （240×10000）/150000=16元/LOC 該項目的人月均編碼行數為： 150000/240=625LOC/人月
-
功能點
-
功能計數項：外部輸入EI、外部輸出EO、外部查詢EQ、外部文件EIF、內部文件ILF
-
FP =UFCTCF UFC：未調整功能點計數 TCF：技術復雜度因子 一般可以采用下面的公式計算出系統的未調整功能點數UFC：UFC=Σ各復雜度等級的信息域數量×加權值 技術復雜性因子TCF由以下公式計算： TCF=0.65+0.01(sum(Fi))： Fi:0-5,TCF:0.65-1.35，DI=sum(Fi):140-14*5
-
FP=UFCTCF UFC=301 TCF=0.65+0.01(143)=1.07 FP=301*1.07=322
-
實用軟件估算模型：
是一種自下而上和參數法的結合模型,步驟如下:
-
對任務進行分解:1,2,…,i…
-
估算每個任務的成本Ei： 先估算規模Qi，然后估算成本Ei= Qi *人力成本參數 唯一估計值：Qi=Avg PERT算法: Qi=(Max+4Avg+Min)/6 直接成本組成: 開發成本、管理成本、質量成本 例如：人力成本參數=2萬/人月，30人月規模的項目的直接成本是 60萬
-
直接成本=E1+E2+……+ Ei+……+ En
-
項目總估算成本= 直接成本+間接成本 估算成本=規模人力成本參數（1+間接成本系數） 成本系數=人力成本參數 （1+間接成本系數） 簡易算法：估算成本=規模*成本系數例如：成本系數= 3萬/人月
-
項目總報價=項目總估算成本+風險利潤 （利潤+風險基金+稅） 即：項目總報價=(a+b+c) %*項目總估算成本+項目總估算成本
第7章 軟件項目的質量管理
質量標准
-
ISO質量標准 ISO 8042：反應實體滿足明確的和隱含的需求的能力的特性的總和。 ISO 9126軟件質量模型中的6個質量特征定義如下： 1）功能性 2）可靠性 3）可用性 4）效率 5）可維護性 6）可移植性
-
CMM/CMMI的5個等級 (1)初始級(initial)。工作無序，項目進行過程中常放棄當初的計划。管理無章法，缺乏健全的管理制度。開發項目成效不穩定，項目成功主要依靠項目負責人的經驗和能力，他一但離去，工作秩序面目全非。 (2)可重復級(Repeatable)。管理制度化，建立了基本的管理制度和規程，管理工作有章可循。 初步實現標准化，開發工作比較好地按標准實施。 (3)已定義級(Defined)。開發過程，包括技術工作和管理工作，均已實現標准化、文檔化。建立了完善的培訓制度和專家評審制度，全部技術活動和管理活動均可控制，對項目進行中的過程、崗位和職責均有共同的理解 。 (4)已管理級(Managed)。運用度量方法和數據，可以對軟件產品和開發過程實施定量的分解和控制 (5)優化級(Optimizing)。可集中精力改進過程，采用新技術、新方法。擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。
-
Boehm模型
-
McCall模型
評審方法：
（1）同行評審（2）走查（3）會議審查（4）檢查表（5）場景分析
估算方法：
六西格碼方法 σ是一個統計學術語，用來衡量一個過程的質量。σ的量級為2至6，代表百萬個產品之中有多少個缺陷。 對於一般公司來說，能夠達到4σ就是一個不錯的成績了，這相當於每百萬個產品中有6000個缺陷(合格率為99.4%)。我們的奮斗目標是6 σ，相當於每百萬個產品中有3.4個缺陷，即合格率達到99.9997%。合格率越高，經濟效益自然越高。
質量保證3個策略：
1）以檢測為重。產品制成之后進行檢測，只能判斷產品質量，不能提高產品質量。 2）以過程管理為重。把質量保證工作的重點放在過程管理上，對開發過程中的每一道工序都要進行質量控制。 3）以產品開發為重。在產品的開發設計階段，采取強有力的措施來消滅由於設計原因而產生的質量隱患。
第8章 軟件項目風險管理
風險識別
-
常見的項目風險因素: 技術、安全、政策、溝通
風險評估
-
Boehm模型 ：1.技術與管理流程 2.計划和執行風險管理 3.管理項目風險特征庫 4.風險分析 5.處理風險 6.風險監控 7.評估風險管理流程
-
CRM模型： 要求在項目生命期的所有階段都關注風險識別和管理，將風險管理活動分為5個步驟：風險識別、分析、計划、跟蹤、控制；這是一個在項目開發過程中反復持續進行的活動序列
-
Riskit 模型 ： 提供風險的明確定義：損失的定義建立在期望的基礎上，即項目的實際結果沒有達到項目相關者對項目的期望的程度； 明確定義目標、限制和其它影響項目成功的因素 采用圖形化的工具 Riskit分析圖對風險建模，定性地記錄風險； 使用應用性損失的概念排列風險的損失； 不同相關者的觀點被明確建模。
風險處理：
規避。通過變更項目計划消除風險或風險的觸發條件，使目標免受影響。 轉移。不能消除風險，而是將項目風險的結果連同應對的權利轉移給第三方。 弱化。將風險時間的概率或結果降低到一個可以接受的程度，其中降低發生的概率更為有效。 接受。不改變項目計划，而考慮發生后如何應對
風險監控:
在項目實施過程中監督人們認真執行風險管理的組織和技術措施。
第9章 人力資源和溝通管理
團隊類型結構：
職能型： 優點：可以充分發揮職能部門的資源集中優勢；部門的專家可以同時為部門內不同項目使用；便於相互交流 , 相互支援；可以隨時增派人員；可以將項目和本部門的職能工作融為一體。 缺點：項目和部門利益發生沖突，職能部門更重視本部門的目標,會忽視項目目標；資源平衡會出現問題；權利分割不利於各個職能部門的交流和團結協作；行政隸屬關系使得項目經理沒有充分的權利。 項目型： 優點：項目經理對項目可以負全責；項目目標單一，可以以項目為中心,有利於項目順利進行；避免多重領導；組織結構簡單，交流簡單,快速。 缺點：資源不能共享；各個獨立的項目處於相對封閉狀態,不利於公司政策的貫徹；對項目組織的成員缺少一種事業上的連續性和安全感；項目組織之間處於分割狀態,缺少信息交流。 矩陣型可分為：弱矩陣型組織結構、平衡型矩陣組織結構和強矩陣型組織結構。 優點：專職的項目經理負責整個項目 , 以項目為中心；公司的多個項目可以共享各個職能部門的資源；即利於項目目標的實現,又利於公司目標方針的貫徹；項目成員的顧慮減少了。 缺點是：容易引起職能經理和項目經理權力的沖突；資源共享也能引起項目之間的沖突。
激勵理論
馬斯洛需要層次理論，從低到高：生理需要、安全需要、社交需要、尊重需要和自我實現
激勵方式：
物質激勵。包括工資、獎金和各種福利; 環境激勵。良好的工作環境和生活環境； 成就激勵。細分為組織激勵、榜樣激勵、榮譽激勵、績效激勵、目標激勵和理想激勵； 能力激勵。兩種方式：培訓激勵、工作激勵； 情感激勵。情感溝通和情感鼓勵。
溝通技術：
（1）會議溝通 成本較高，溝通的時間一般比較長，因此常用於解決較重大、較復雜的問題。幾種適用場景舉例 （2）Email溝通 成本低，方便快捷，小范圍溝通，有時間思考斟酌，等； （3）口頭溝通 是一種自然、親近的溝通技術。加深彼此之間的友誼、加速問題的解決。幾種應用場景：辦公距離近；存有誤會，采用Email無效等 （4）電話溝通 成本較低，距離遠無法當面溝通，問題相對簡單，采用Email無效等情況下適用。 （5）即時通訊 QQ/MSN/微信（群），快捷，方便，可以群討論，但是閑聊可能會影響工作。
團隊溝通方式：
-
正式溝通與非正式溝通 。正式溝通效果好，溝通信息具有權威性，但較刻板；非正式溝通形式不限，但難以控制。 2.上行溝通、下行溝通和平行溝通。上行溝通層層過濾，效率不佳；下行溝通可明確領導意圖，但易營造高高在上印象。平行溝通助於培養團隊友誼，但信息量大，易造成混亂。
-
單向溝通和雙向溝通 。單向溝通信息傳遞的速度快，但不能產生平等和參與感；雙向溝通信息准確性較高，有助於建立雙方的感情。
-
書面溝通和口頭溝通 。書面溝通可作為資料長期保存，反復查閱；口頭溝通比較靈活、速度快，雙方可以自由交換意見，且傳遞信息較為准確。 5.言語溝通和體語溝通。言語溝通利用語言、文字、圖畫、表格等形式進行；體語溝通利用動作、表情姿態等非語言方式進行，是項目溝通的主要組成部分。
第10章 項目驗收
老師課堂口述總結
-
資料的准備： 紙質：需求規格說明書、概要設計說明書、E-R圖、測試文檔、軟件需求規格說明書 電子資料：代碼、數據庫--數據字典 安裝部署環境的准備：軟件安裝說明、環境的搭建、mysql數據庫，tomcat啟動環境、微信小程序、APP提供平台的賬戶信息
-
驗收文檔的准備：功能點通過或沒通過的一個說明，對未通過或需要后期修改的功能點要說明完成整改的時間
-
項目的培訓：給最終用戶做技術培訓，日常的運行維護，如服務器日志的備份、數據的備份
-
后期維護：改正性維護、適應性維護、完善性維護、預防性維護。
-
最后，對內部來說，項目的總結，出現了哪些風險、怎么應對的，成本的估算，進度的估算，形成一個總結文檔
1.合同收尾：
合同收尾是項目管理人員與客戶對照合同一項項的核對，審核是否完成了合同所要求的內容，是否達到合同所提出的指標或條件，也就是通常所講的客戶驗收。 合同收尾是結束合同並結清賬目，包括解決所有尚未結束的事項。合同收尾需要對整個采購過程進行系統地審查，找出進行本項目其它產品或本組織內其它項目采購時值得借鑒的成功和失敗之處。
2.管理收尾：
管理收尾是對於項目組內部，把做好的項目文檔、代碼、與客戶交流的文件等歸檔保存，對項目中遇到的問題及解決方法、有效的創新技術進行及時地總結，對外宣稱項目結束，轉入維護期，把相關的產品說明及技術文檔轉到維護組。
3.項目驗收流程:
項目驗收是一個循序漸進的過程，要經歷准備驗收材料、提交申請、初審、復審，直到最后的驗收合格，完成移交工作。
4.軟件項目的驗收工作：
（1）軟件系統驗收: 已經配置好的系統環境；軟件產品，例如，軟件光盤介質等；項目成果規格說明書；系統使用手冊；項目的功能、性能技術規范；測試報告等。 （2）質量驗收：質量驗收主要是對軟件系統的功能、性能、用戶操作界面、可維護性等方面進行驗收 （3）資料驗收： 1)開發文檔：主要包括軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、可行性研究報告等。 2）管理文檔：主要有項目開發計划、測試計划、測試報告、開發進度月報、質量評估報告、重要會議紀要、變更記錄控制文檔、驗收審核表、項目開發總結等。 3）用戶文檔：用戶手冊、操作手冊、維護修改建議等。
5.項目的移交工作：
用戶培訓：用戶基本熟悉軟件系統的業務操作。 系統上線：工作包括硬件設施的搭建、網絡環境的搭建、操作系統的安裝和設置、數據庫的安裝和數據的准備、業務軟件系統的部署和配置。 后期維護：改正性維護、適應性維護、完善性維護、預防性維護。
6.項目總結包括技術方面和管理方面。
項目評價包括項目背景、項目實施過程評價、效果評價、結論和經驗教訓。