軟件項目管理實用教程（非官方答案，存在錯誤）第一章1.名詞解釋項目項目是未完成某項獨特的產品、服務或成果等特定目標所作的一次性任務。項目群項目群是為了實現某一戰略目標而以協同方式管理的一組項目。子項目子項目是項目的一個階段或一個部分，可被相對獨立地進行管理，也可以外包給外部單位或者組織內的其他職能單位。軟件項目管理軟件項目管理是項目管理中的一個特殊領域，它是以軟件項目為對象的系統管理方式，它運用相關的知識、技術和工具，對軟件項目周期中的各階段工作進行計劃、組織、指導和控制，以實現項目目標。2.問答題下列哪些活動不是項目探索火星生命跡象向部門經理進行月工作匯報開發新版的操作系統每天的衛生保潔組織一次校園歌唱比賽一次集體婚禮軟件產品具有哪些特點？軟件項目有哪些特點？軟件的特點：復雜性，不一致性，可變性，不可見性。軟件項目的特點：知識密集型，技術含量高；涉及多個專業領域，多種技術綜合應用；項目范圍和目標的靈活性；風險大，收益大；客戶化程度高；過程管理的重要性。為什么說學習軟件項目管理是非常重要的？軟件項目管理對于軟件項目的成功是至關重要的。因為軟件項目涉及大量的人員活動，有進度和資金限制，并會遇到各種變化、風險和矛盾，必須有良好的管理才能成功。對高軟件開發人員的專業素質是必不可少的。適應團隊開發，理解項目計劃并勝任管理工作。理解軟件項目在進度、成本、質量、人員等方面的計劃和相應的措施，從而更有效地工作并為企業創造價值。你認為在一個軟件項目中，為保證軟件項目的成功，主要應注意哪些方面的管理？軟件項目合同管理，軟件項目進度管理，軟件項目成本管理，軟件項目風險管理，軟件項目人員管理，軟件質量管理，軟件配置管理軟件項目的生命周期通常可分為哪幾個階段？各階段需完成哪些任務？1.項目啟動階段發現項目機會，識別客戶需求，在此基礎上定義項目目標和初始范圍；落實項目的初步財務和人力資源，選定項目經理并授權開始項目。2.項目規劃階段為實現目標而定制行動方案，針對項目的范圍、進度、成本、質量、風險、人力資源等方面進行規劃，形成項目管理計劃文件。3.項目執行階段管理人員要指導項目組成員完成項目管理計劃中所確定的工作，從而滿足客戶的需求。在該階段的末尾通常需要對項目產品或服務進行驗收。在這一階段還要不斷監控項目的執行過程，測量項目的實際進程和質量指標是否與計劃一致。如果測量結果表明出現偏差，要立即采取糾正措施，以使項目恢復到正常軌道，或者更正計劃的不合理之處。4.項目收尾階段進行項目移交和總結工作，確認所有的項目可交付物都已移交給客戶，所有的費用都已清算。對項目承擔者來說，要對項目進行總結，得到對本組織的改進有所收益的經驗教訓。項目組需要調查客戶的滿意度，收集客戶和項目團隊的建議，從而能夠改進以后的項目性能。軟件項目管理為什么要堅持具體問題具體分析的原則？軟件項目管理的知識體系與數學、物理等學科不同，它不存在“公理系統”，其理論體系不是由公式和定律組成，而是有經驗性的原則和方法組成，其解決問題的主要方式也不是套用定律進行推理，而是針對具體項目情況對原則和方法靈活運用。不存在任何情況都適用的方法，要堅持具體問題具體分析。軟件項目管理的系統方法具有哪些特征？對各組成部分之間的關系進行評價將各組成部分集成和匹配到一個統一的整體中將所有活動整合到一個有意義的系統化的動態過程中尋找解決問題的最佳方案和策略保證解決問題時的客觀性

第二章問答題一般從哪幾個方面評價一個軟件項目的可行性？明確項目規模和目標。研究正在運行的系統。建立新系統的邏輯模型。導出和評價各種解決的方案。推薦可行方案編寫可行性研究報告在軟件項目中使用開源軟件有哪些好處？應注意哪些方面的風險？好處：（1）節省成本，提高開發效率。（2）開放和自由（3）公開透明（4）提供良好的學習平臺風險：（1）開源軟件存在質量風險（2）開源軟件不提供技術支持和服務承諾，可能會給開源軟件的使用和維護造成困難（3）使用開源軟件存在法律風險合同項目的投標書一般包含哪些方面的內容？商務標部分：（1）投標函和法定代表人授權委托書（2）投標報價詳細預算（3）投標方資質證明材料技術標部分：（1）系統需求分析（2）系統解決方案（3）項目進度安排（4）培訓、售后服務和技術支持（5）項目實施風險分析（6）項目驗收工作計劃項目合同通常包含哪些方面的內容？（1）權利與義務（2）供應的商品與服務（3）技術成果的歸屬（4）項目的質量要求（5）項目的各種期限（6）保密約定（7）驗收標準和方法（8）價格和付款方法（9）違約處理方法（10）解決爭議的方法（11）客戶承諾通用產品項目在產品構思階段應主要考慮哪些問題？待開發產品的主要功能；待開發產品的技術方案；Make-or-Buy分析；開發計劃；市場營銷計劃。通用產品項目的立項審批過程一般包含哪些步驟？（1）評審準備（2）舉行評審會議（3）評估（4）評審會議和決議（5）機構領導終審《項目計劃》通常要對項目的哪些方面進行規劃？（1）項目目標與范圍（2）項目的過程模型與技術方法（3）人力資源計劃（4）軟硬件資源計劃（5）財務計劃（6）進度計劃線性、迭代型、敏捷型過程模型分別具有什么特征？分別適用于什么類型的項目？線性模型（瀑布模型）：要求在項目初期就明確需求和解決方案，制定明確的計劃，然后嚴格按照計劃執行。不適合需求頻繁交換的項目。迭代模型：每個項目階段（稱為迭代）執行一系列重復性的開發活動（分析、設計、編碼、測試等），每次迭代結束時，將完成一個或一組可交付成果，用戶和其他項目干系人應對這些交付成果進行評估和反饋。適合：項目需求不斷變化；項目的規模大、復雜性高，需要通過增量交付來得到反饋意見和經驗教訓，以減小項目的風險。敏捷型（適應型或變更驅動型）：包含迭代概念，迭代很快，通常2~4周迭代一次，而且每次迭代所需的時間和資源大致固定。強調用戶持續參與。適用：項目需求快速變化，能夠以有利于用戶的方式把項目可交付成果分解為一系列增量改進。單選題；以下有關開源軟件的陳述，哪個是錯誤的？開源軟件的代碼是公開的，有利于保證安全性。開源軟件是免費的，使用開源軟件有利于降低成本。開源軟件是良好的學習平臺。開源軟件通常不受著作權保護。投標者只向一些經過篩選合格的供應商發出投標邀請，這種投標方式是公開投標非公開投標受限制的招標已商定的投標過程在一個軟件項目簽署合同或通過立項評審后，負責籌備和啟動項目的角色是軟件架構師項目經理企業領導用戶代表以下哪個不是敏捷型過程模型的特征？迭代很快，通常2~4周完成一個迭代。強調用戶的持續參與。要求在項目初期就獲得完整而明確的用戶需求。每次迭代所需的時間和資源是大致固定的。名詞解釋凈利潤整個生命周期中總成本和總收益之差。投資回報率比較凈收益與投資額，從而能夠用來衡量投資效益的大小。投資回報率=（平均年利潤/總投資）*100%軟件外包企業為了專注核心競爭力業務和降低軟件項目成本，將軟件項目的全部或部分工作承包給提供外包服務的企業完成。Make-or-Buy分析指確定產品中的哪些部分應當自行研發，哪些部分需要采購或外包開發。

第三章問答題范圍管理在項目中的作用是什么？保證項目只做必須做的事，避免范圍蔓延和做無用功，同時也避免不清晰的需求所導致的嚴重的系統缺陷。軟件項目的需求一般包括哪些類別？1.界面需求2.功能需求3.性能需求4.質量需求5.資源使用需求6.軟件成本消耗與開發進度需求7.異常處理要求獲取需求的常用方法有哪些？1.訪談2.討論會3.觀察用戶工作流程4.問卷調查5.快速原型法軟件需求規格說明書一般包括哪些內容？1.功能特征描述2.系統接口描述3.質量特征描述項目范圍說明書一般包括哪些內容？1.產品范圍描述2.驗收標準3.可交付成果4.項目的除外責任5.制約因素6.假設條件創建WBS時所用的類比法具有什么特點？適用于什么情況？類比法就是參考類似的已完成的項目的WBS和項目經驗，根據當前項目特點做必要的調整，從而得到當前項目的WBS。適用情況：有較完整的歷史數據支持，軟件組織經常性在某一行業或產品中重復多個項目，則項目過程的重合度高，容易參考歷史數據，適合用類比法。創建WBS時所用的自底向上歸納法具有什么特點？適用于什么情況？自底向上歸納是一個通過對細粒度工作的逐層歸納以得到整個項目WBS的方法。適用情況：不熟悉的項目，沒有歷史數據或經驗豐富的專家的項目。判斷題快速原型法使得用戶可以體驗最終產品，而不是僅限于討論抽象的需求描述。√在軟件項目中，產品范圍就是項目范圍。×在創建WBS時，如果沒有項目歷史數據，且找不到經驗豐富的專家時，適合用類比法。×在創建WBS時，項目工作分解得越細越好。×范圍控制要通過變更控制系統和配置管理系統來完成。√名詞解釋WBS工作結構分解（WorkBreakdownStructure，WBS）是對項目團隊為實現項目目標、創建可交付成果而需實施的全部工作范圍的層級分解。范圍蔓延未經控制的產品或項目范圍的擴大（未對時間、成本和資源做相對應調整）被稱為范圍蔓延。

第四章問答題軟件項目活動之間有哪幾種依賴關系，請結合具體的例子說明。強制性依賴關系。例如只有在編碼完成后，才能進行構建和測試。選擇性依賴關系。選擇性依賴關系的確定帶有主觀性。什么是項目活動的最早和最遲開始時間、最早和最遲結束時間？什么是項目活動的總浮動時間和自由浮動時間？最早開始時間（EarlyStart，ES）：指一個活動最早可以開始的時間。最早結束時間（EarlyFinish，EF）：指一個活動最早可以完成的時間。最遲開始時間（LateStart，LS）：在不影響項目完工時間的情況下，一項活動最晚必須開始執行的時間。最遲結束時間（LateFinish，LF）：在不影響項目工期的情況下，該活動最晚必須完成的時間。總浮動時間（TotalFloat，TF）：一個活動在不影響項目最早完成時間的情況下可以延遲的時間量。TF=LS-ES或TF=LF-EF自由浮動時間（FreeFloat，FF）：一個活動在不影響其所有后置活動的最早開始時間的情況下，可以延遲的時間量。FF=min（TI）。TI=后置活動的ES-本活動的EF-Lag（滯后）關鍵鏈法在哪些方面對關鍵路徑進行了改進？關鍵路徑法是在不考慮任何資源限制的情況下，在給定活動持續時間和邏輯關系的條件下，分析項目的關鍵路徑，而關鍵鏈法考慮了資源限制對項目活動邏輯關系及關鍵路徑的影響。關鍵鏈法引入了緩沖和緩沖管理來應對項目的不確定性。關鍵鏈法考慮了人的心理行為因素和工作習慣，因為人是項目實施的主題，是項目最關鍵的資源。在制定項目進度計劃的過程中，資源優化的目的是什么？資源優化就是根據資源供需情況，來調整進度計劃。選擇題對某個項目活動的持續時間進行三點估算，的到其最樂觀時間為8天，最悲觀時間為24天，最可能時間為10天，則該活動的持續時間期望值是（B）。10天 B.12天 C.14天 D.16天快速跟進是指（A）。A．采用并行執行任務，加速項目進度B．用一個任務取代另一個任務C．如果有可能，減少任務數量D．減輕項目風險趕工一個項目時，你應該關注（C）。盡量可能多的活動非關鍵活動加速執行關鍵路徑上的活動通過成本最低化加速執行活動分析題根據下表的活動歷時和活動關系畫出前導圖和箭線圖，指出關鍵活動及關鍵路徑。活動活動歷時前序活動A7B3C6AD3AE3DFF2BG3CH2GE前導圖：箭線圖：作為項目經理，你需要給一個軟件項目做進度計劃，經過任務分解后得到任務A、B、C、D、E、F、G，下圖是這個項目的PDM網絡圖。通過歷時估計已經算出每個任務的工期，現已標識在PDM網絡圖上。假設項目的最早開工日期是第0天，請計算每個任務的最早開始時間、最遲開始時間、最早結束時間、最遲結束時間，同時確定關鍵路徑，并計算項目工期和活動F的總浮動時間。

第五章問答題什么是軟件項目的規模、工作量和成本？它們一般用什么度量單位來度量？軟件項目規模一般是指所開發軟件的規模大小，通常可以簡單地用軟件的代碼行數來表示，也可以通過軟件功能的多少來衡量。軟件項目工作量是指為了提供軟件的功能而必須完成的軟件工程任務量，其度量單位為人月、人天、人年等。軟件項目成本時指完成軟件項目所付出的代價，即待開發軟件項目所需要的資金，通常用貨幣單位（如美元，人名幣等）衡量。軟件項目的成本一般由哪些部分構成？設備、軟硬件購置成本 2.人工成本（軟件開發、系統集成費用） 3.維護成本 4.培訓費 5.業務費、差旅費 6.管理及服務費 7.其他費用使用代碼行和功能點度量軟件規模各有什么優缺點？代碼行：優點：用代碼行數來表示軟件項目的規模簡單易行、自然、直觀。缺點：項目初期很難較為精準地估算出最終系統的代碼行數；代碼行數通常依賴于程序程序設計語言功能和表達能力，采用不同的開發語言，代碼行數不同。功能點：優點：軟件系統的功能與實現該軟件系統的語言和技術無關，一般項目初期就可獲得功能點數目，可以較好的克服代碼行的軟件項目規模表示方法的不足。缺點：沒有直接涉及算法的復雜度，不適合算法比較復雜的軟件項目系統；計算功能點的數據不好采集。項目成本估算的依據是什么？工作分解結構、資源需求、資源單價、計劃進度和歷史信息。簡述項目成本的類比估算方法及其缺點。類比估算就是通過把當前項目與以往一個或多個項目比較來進行成本估算。缺點：需要有類似的項目和類似的開發經驗。簡述項目成本的自底向上估算方法及其特點。自底向上估算方法首先通過對單個工作包或活動的成本進行最具體、細致的估算，然后把這些細節性的成本向上匯總到更高的層次。什么是成本預算？它與成本估算有什么關系？成本預算是一項制定項目成本控制標準的項目管理工作。成本估算的目的是估計項目的總成本和誤差范圍，而成本預算是將項目的總成本分配到各項工作上。成本估算的輸出結果是成本預算的基礎與依據，而成本預算則是將項目批準的成本估算進行分攤。單選題以下哪一項不是項目成本類比估算方法的特點？（B）通過把當前項目與以往一個或多個項目比較來進行成本估算。利用歷史數據之間的統計關系，通過建立數學模型來進行成本估算。該方法成本較低，耗時較少。該方法適合在項目詳細信息不足時（例如項目初期）使用。在基本COCOMO模型中，用一個以（A）為自變量的函數來計算軟件開發工作量。A千代碼行數 B功能點數 C對象數 D頁面數在（C）模型中，采用了“階段敏感工作權數”對成本比估算進行調整。A基本COCOMO B中間COCOMO C詳細COCOMO D嵌入式COCOMO計算題項目原來預計2012年10月10日完成10萬元的工作，但是到該日期時只完成了其中8.5萬元的工作，而為了完成這些工作實際花費了9萬元。請用掙值分析法計算在2012年10月10日項目的成本偏差、進度偏差、成本效能指數和進度效能指數各是多少？BCWS：預算成本 ACWP：實際成本 BCWP：掙值（已完成工作預算成本）成本偏差:CV=BCWP-ACWP=8.5-9=-0.5進度偏差：SV=BCWP-BCWS=8.5-10=-1.5成本效能指數：CPI=BCWP/ACWP=8.5/9=0.944進度效能指數：SPI=BCWP/BCWS=8.5/10=0.85

第六章問答題什么是軟件質量、質量屬性、質量要素？軟件質量就是軟件與用戶需求相一致的程度，它是軟件的一個綜合特征，用一系列質量屬性來表示。對于一個具體的軟件項目，哪些用戶最關心的，對軟件整體質量影響最大的質量屬性稱為質量要素。全面軟件質量管理包括哪些部分？各部分作用是什么？全面軟件質量管理采取一系列的措施來保證軟件質量：通過制定質量管理計劃來規劃軟件項目中的各種質量管理活動，通過技術評審和軟件測試發現軟件缺陷，通過過程檢查保證軟件過程和產品符合既定的規范，通過缺陷跟蹤保證發現的缺陷和問題被正確記錄、跟蹤和處理，通過軟件過程改進來提高軟件組織整體的技術水平和規范化水平。什么是缺陷跟蹤？簡述一個典型的缺陷跟蹤流程。缺陷跟蹤是值從缺陷被發現開始到被改正為止的整個跟蹤流程。請解釋軟件過程和軟件過程改進的含義。軟件過程是指開發和維護軟件產品的活動、技術、實踐的集合。軟件過程改進是指根據實踐中對軟件過程的適用情況，對軟件過程中的偏差和不足之處進行不斷優化。CMMI的過程成熟度分為哪幾個等級？每個等級有哪些特征？初始級（CMMI1）：軟件過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決于個人努力。已管理級（CMMI2）：建立了基本的項目管理過程和跟蹤費用、進度和軟件的功能特性。已定義級（CMMI3）：已將軟件管理和工程兩方面的過程文檔化、標準化，并綜合成該組織的標準軟件過程。量化管理級（CMMI4）：分析軟件過程和產品質量的詳細度量數據，對軟件過程和產品都有定量的理解與控制。優化管理級（CMMI5）：過程的量化反饋和先進的新思想、新技術促使過程持續不斷改進。PSP將個人能力分為哪幾個等級？每個等級有哪些特征？個人過程基線：PSP0是過程基線，目的是為了在個人的工作中引入表格和腳本，以便工程師按照測量和報告格式記錄軟件過程。個人計劃過程：PSP1是個人計劃過程，在PSP0的基礎上增加了計劃步驟。個人質量管理：PSP2強調提高質量，引入了缺陷管理，包含了代碼審查和設計審查。循環質量過程：PSP3將個人軟件過程的應用拓展到大規模程序開發當中。軟件組織實施TSP需要哪些條件？需要有高層主管和各級經理的支持，已取得必要的資源。整個軟件開發小組至少在CMMI的第二級。全體軟件開發人員必須經過PSP的培訓，并有按TSP工作的愿望和熱情。開發小組成員應在2~20個人之間。請解釋缺陷密度、平均失效時間、平均修復時間的含義。缺陷密度指單位規模的軟件所包含的缺陷的數量。平均失效時間指軟件在失效前正常工作的平均統計時間，它常用來度量軟件的可靠性。平均修復時間指軟件失效后，使其恢復正常工作所需要的平均統計時間。用來度量可維護性。軟件缺陷的原因分析過程包含哪些步驟？簡述每個步驟所執行的任務。軟件缺陷原因分析過程一般包括選擇缺陷數據、分析缺陷數據、識別公共原因并提出改進措施。選擇題軟件在異常情況下能夠正常運行的能力稱為軟件的（B）。A正確性B健壯性C性能D可靠性與其他軟件系統相互交換信息的能力稱為軟件的（C）。A易用性B可擴展性C兼容性D缺陷跟蹤（A）是通過執行軟件來發現缺陷。A軟件測試B技術評審C過程檢查D缺陷跟蹤配置管理是CMMI的（A）上的關鍵過程域。A已管理級B已定義級C量化管理級D優化管理級判斷題軟件項目質量管理的目的就是使所有的質量屬性都達到最好（×）技術評審可以在軟件項目的任何階段執行，一次可以盡早發現和消除缺陷（√）工作過程和工作結果通過了過程檢查，就能保證軟件質量。（×）CMMI既說明了軟件過程改進應“做什么”，也說明了“怎么做”。（×）軟件組織要達到CMMI的某個成熟度級別，必須滿足該級別及其以下級別上所有關鍵過程域的要求。（√）

第七章單項選擇題軟件配置管理最核心的內容是（A）A版本控制B配置審核C集成管理D配置狀態統計關于軟件產品的版本編號方法，以下描述錯誤的是（C）數字順序型版本編號由若干數字組成，數字之間用“.”分隔。屬性版本編號可以包含更多的有關軟件產品的信息。在數字順序型版本編號中，當某一級版本號改變時，其下一級版本號保持不變。屬性版本編號適合在軟件組織內部使用。關于基線配置項，正確的描述是（B）是不可以變化的配置項基線是經過正式審批的配置項，是后續工作的基礎對大部分基線的變更，不需要執行嚴格的變更控制流程基線發生變更時，必須修改需求下列關于配置控制委員會（CCB）職責的描述，錯誤的是（C）A對變更進行評估B拒接或批準變更C執行缺陷跟蹤D審批軟件項目配置管理計劃問答題闡述配置庫的檢入檢出機制及其作用。配置庫的檢入檢出機制是版本控制的基線。作用是防止文件修改相互沖突和覆蓋的問題。版本控制系統是怎樣防止不同的人對同一文件所作的修改相互覆蓋的？配置庫的檢入檢出機制。什么是分支？為什么要使用分支？分支可以形象地看作是配置項演化圖中的一條獨立路徑。作用1.開發者需要創建軟件的不同用途版本。2.在軟件開發過程中，有時需要創建一個相對獨立的開發環境。什么是系統集成？系統集成的一般步驟有哪些？系統集成就是把軟件產品的各個組成部分組合在一起，使產品作為一個整體是可以運行的。確保開發人員都提交了本次將要集成的代碼。凍結或標識將要集成的源代碼。取出要集成的源代碼。編譯、鏈接和打開安裝包。安裝并粗略測試。標志和存儲集成結果。通知相關人員本次集成完成。什么是持續集成？持續集成能帶來什么好處？持續集成是指以很高的頻率進行系統集成工作。好處是能盡快地發現和糾正配置庫里源代碼的問題。在開發人員更新自己的工作空間時，有直接工作流和間接工作流兩種方式，請解釋它們的含義。間接工作流：不更新到配置庫中的最新內容，而是更新到最近一次集成產生的基線。直接工作流：更新到配置庫中的最新內容。在哪些情況下使用多層集成？大型項目開發人員眾多，源代碼也龐大復雜。簡述嚴格的變更管理流程。什么是配置審計？它有什么作用？配置審計的目的是驗證配置項符合特定的標準或要求。通常在軟件開發每個階段結束后，或產品發行之前，都要進行配置審計，它是正時技術復審的一種補充。在組織級，一般要做哪些軟件配置管理工作？對軟件配置管理工具和環境進行設置和維護，負責與工具相關的培訓和咨詢，制定軟件配置管理的流程、規范和方法并監督它們的執行，對它們進行調整和改進，還有可能與具體的軟件項目中對標準流程規范的剪裁和配置管理計劃的制定。

第八章問答題什么是軟件項目團隊？它有什么特點？軟件項目團隊是由軟件項目的不同干系人所組成的，具有共同目標、緊密協作的集體。特點：1.臨時性2.團隊成員的不穩定性3.年輕化程度較高4.是高度集中的知識型團隊5.成員的業績不易量化考核什么是軟件項目團隊管理？它包括哪些主要內容？軟件項目團隊管理就是采用科學的方法，對項目組織結構和項目全體參與人員進行管理。主要內容：1.項目組織的規劃2.團隊人員獲取3.團隊建設4.團隊日常工作管理5.溝通管理6.項目干系人管理。項目型組織結構有哪些優點和缺點？優點：項目經理對項目可以全權負責，可以根據項目需要靈活調動項目組織的內部資源或外部資源。缺點：當一個公司有多個項目時，每個項目有自己一套獨立的班子，這將導致類似項目的重復努力和規模經濟的喪失。人員配置管理計劃一般包括哪些內容？1.項目團隊組建的相關問題2.時間表3.成員遣散安排4.培訓需求5.表彰和獎勵6.合規性。通常采用哪幾種方法獲取項目團隊人員？1.預分派2.談判3.招募項目中解決沖突的方式主要有哪幾種？1.問題解決2.妥協3.求同存異4.撤退5.強迫項目溝通管理計劃一般包括哪些內容？1.項目干系人的溝通需求2.溝通方式3.人員聯系方式4.工作匯報方式5.溝通時間安排6.溝通計劃維護人單項選擇題以下有關軟件項目團隊角色的說法，哪個是錯誤的？（C）不同角色之間是一種相互配合、相互制約的關系。項目經理是整個項目團隊的核心角色，對項目的成敗起著關鍵作用。不同角色之間的關系主要是上下級的匯報關系。應通過不同的角色設置，形成一個檢查和平衡機制。以下有關職能型組織結構的敘述，錯誤的是（D）項目成員主要受他所在的職能部門的經理管轄。以職能部門作為承擔項目任務的主體，可以充分發揮職能部門的專業優勢和資源集中優勢。可以減少因項目的臨時性給項目成員帶來的事業上的不安全感。有利于完全以項目目標作為工作驅動動力和導向。最早由IBM采用的“主程序員小組”屬于（A）小組結構。A控制集中型B明珠分散型C控制分散型D矩陣型以下敘述中哪一個不是虛擬團隊的特點？（D）可以組建在同一組織工作，但工作地點十分分散的團隊。可以納入在家辦公的員工。成員之間的交流受到一定限制。易于按工時計算成員的工作量。名詞解釋虛擬團隊。虛擬團隊時指擁有共同目標，但是工作地點分散，在工作過程中很少或完全不面對面交流的一組人員。項目干系人項目干系人是指能夠影響項目或受項目影響的全部個人、群體或組織。團隊意識團隊意識就是團隊成員為了團隊的整體利益和目標相互合作、共同努力的意愿和作風。

第九章問答題什么是風險？風險具有那些屬性？風險是遭受損失的一種可能性。屬性：1.風險事件2.風險發生的原因3.風險發生的概率4.風險的影響5.風險發生的頻率6.與其他風險相比較的重要程度7.風險防范策略和應對策略8.風險責任人軟件項目風險管理計劃一般有哪些主要內容？1.風險規劃2.風險識別3.風險評估4.風險應對5.風險監控怎樣用核對表法識別項目風險？核對表將軟件項目可能發生的許多潛在風險列于一張表上，供風險識別人員進行檢查核對，用來判別某項目是否存在表中所列或類似的風險。什么是項目風險的定性和定量評估？定性評估是確定風險發生的概率和發生后產生的影響程度，并按照風險的潛在危險性大小對其進行優先級排序。定量風險評估是針對哪些對項目有潛在重大影響而排序在前的風險進行量化分析，從而為風險應對和項目管理決策提供依據。你所在的軟件組織內，許多人跟不上新技術的發展，因此將新技術引入組織可以視為一個風險。試針對該風險指定風險應對策略。風險回避：發現新技術風險太大時，放棄新技術。轉移風險：將不熟悉的技術外包。風險預留：預留一段時間和一筆資金，當技術風險發生，需要采取措施補救時，才能動用改資金和時間。風險監控的目的是什么？風險監控的目的時監控項目風險的狀況，如：風險是否已經發生、任然存在還是已經消失，風險決策的結果是否與預期的相同，識別新的風險，并發現細化和改進風險管理計劃的機會，把信息反饋給有關決策者。案例分析題請閱讀以下案例并回答問題。 某大型公司的行業業務運營網路管理系統的開發項目受到該公司領導層的高度重視，委派本公司的業務支撐部負責完成該項目，委任張工為項目經理。 在編制早期項目計劃書時，市場部李工不斷提出新的需求，而張工“來者不拒”，不停地更改項目計劃。另外，在工程的機房設備平面設計中，張工組織人員進行自行設計，將大部分機架式的小型機集中擺放在一片較小的區域內。 系統正式完全割接上線前，舊系統仍然需保持運行。保證系統穩定運行是項目團隊的第一要務，在系統割接期間，確保7天×24小時的業務連續平穩運行。 問題：該工程中有哪些風險？應采取怎樣的應對策略？

頻繁的需求變更必然會影響信息工程項目的三大目標（進度、成本、質量）。因此引導客戶需求對項目經理來說就非常關鍵，引導得好，項目的開發就會比較順利，相反，就會給項目帶來很多負面影響。

在該項目中，項目經理張工對市場部李工不斷提出的新需求采取了“來者不拒”的態度，這是不恰當的，因為這會使項目計劃不斷變動，導致項目范圍無法確定，工期和成本不可控制，團隊成員工作目標也不明確，因此出現了非常嚴重的需求風險。

為了應對這一風險，張工應該與李工積極地溝通和談判，使他明白工程的重要意義，并承諾工程不是交鑰匙項目，可為系統升級和擴容留有擴展接口，將來新的需求能夠通過后續工程逐步實現，從而使需求趨于穩定。

在工程的機房設備平面設計中，將大部分機架式的小型機集中擺放在一片較小區域內，從表面上看，提高了機房平面空間的使用率，但是由于未充分考慮到設備散熱因素，容易造成該區域

機器過熱而宕機。因此團隊的機房設計技術經驗不足給項目帶來了系統運行不穩定的風險。

可采取風險轉移策略來應對這一風險。張工可聘請具有通信設計資質的專家來負責機房設備平面設計，從機房空調、電源、布線、承重、消防等各個方面進行詳細的勘察和設計，從而保證設備運行的可靠性，實現工程設計風險的良性轉移。

在系統割接期間，新舊系統要順利交接，這給系統業務的7天×24小時連續平穩運行帶來了風險，

因此項目組必須制定詳盡可行的系統割接方案、新舊系統并運行方案和故障應急處理方案。

第十章問答題項目收尾過程包含哪些主要活動？對每個活動進行簡單解釋。范圍確認：項目結束前，重新審核工作成果，檢驗項目的各項工作范圍是否完成，或者完成到何種程度。質量驗收：質量驗收是控制項目產品最終質量的重要手段，依據質量計劃和相關的質量標準進行驗收，不合格不予接收。費用決算：是指對項目開始到項目結束全過程所支付的全部費用進行核算，編制項目決算表的過程。合同終結：整理并存檔各種合同文件。項目資料檢查和歸檔：檢查項目過程中的所有文件是否齊全，然后進行歸檔。項目后評價：是指對已完成的項目(或規劃)的目的、執行過程、效益、作用和影響所進行的系統的、客觀的分析，通過分析評價找出成功失敗的原因，總結經驗教訓，為新項目的決策和提高完善投資決策管理水平提出建議。一般通過哪些要素判斷一個項目是否成功？1.項目必須通過正式驗收2.須進行認真的財務核算，客戶的應付項目款要結清，項目組的開發實施費用要盤結清楚，保證利潤、資金落實到位3.對項目的經驗進行總結4.與客戶保持良好的關系。什么時項目清算？簡述項目清算的步驟。項目清算是非正常的項目終止過程。步驟一：組成項目清算小組，主要由投資方召集項目團隊、工程監理等相關人員。

步驟二：項目清算小組對項目進行的現狀及已完成的部分，依據合同逐條進行檢查。對項目已經進行的、并且符合合同要求的，免除相關部門和人員責任；對項目中不符合合同目標的，并有可能造成項目失敗的工作，依合同條款進行責任確認，同時就損失估算、索賠方案等事宜進行協商。

步驟三：找出造成項目非正常終止的所有原因，總結經驗。

步驟四：明確責任，確定損失，協商索賠方案，形成項目清算報告，合同各方在清算報告上簽證，使之生效。

步驟五：協商不成則按合同的約定提起仲裁，或直接向項目所在地的人民法院提起訴訟。為什么要進行項目后評價？項目后評價的主要內容有哪些？項目后評價就是在項目完成后，對項目進行分析，評價項目的得失，總結經驗教訓。主要內容：項目的技術經濟評價、項目的社會效益評價、項目數據總結和項目問題總結。實施項目后評價包括哪些步驟？步驟一：成立后評價小組、制定評價計劃。

步驟二：設計調查方案、聘請有關專家。

步驟三：閱讀文件、收集資料。

步驟四：開展調查、了解情況。

步驟五：分析資料、形成報告。

步驟六：提交后評價報告、反饋信息。

單項選擇題下面哪一個不是項目收尾過程的活動？（C）A范圍確認B質量確認C風險評估D費用決算在項目非正常終止的情況下，應進行（D）A項目移交B用戶培訓C風險識別D項目清算下面哪一項不是項目后評價過程中執行的活動（B）A項目的技術經濟評價B掙值分析C項目的社會效益評價D項目問題總結下面哪一項不是項目后評價的目的？（D）A確定項目目標是否達到B評價項目規劃是否合理有效C總結項目的經驗教訓D確定項目中成功和失敗決策的責任人XXXX項目系統測試總結報告XXXX年XX月XX日引言編寫目的編寫該測試總結報告主要有以下幾個目的通過對測試結果的分析，得到對軟件質量的評價分析測試的過程，產品，資源，信息，為以后制定測試計劃提供參考評估測試測試執行和測試計劃是否符合分析系統存在的缺陷，為修復和預防bug提供建議背景用戶群主要讀者：XX項目管理人員，XX項目測試經理 其他讀者：XX項目相關人員。定義嚴重bug：出現以下缺陷，測試定義為嚴重bug系統無響應，處于死機狀態，需要其他人工修復系統才可復原。點擊某個菜單后出現“Thepagecannotbedisplayed”或者返回異常錯誤。進行某個操作（增加、修改、刪除等）后，出現“Thepagecannotbedisplayed”或者返回異常錯誤當對必填字段進行校驗時，未輸入必輸字段，出現“Thepagecannotbedisplayed”或者返回異常錯誤系統定義不能重復的字段輸入重復數據后，出現“Thepagecannotbedisplayed”或者返回異常錯誤測試對象略測試階段系統測試參考資料《XX需求和設計說明書》 《XX數據字典》《XX后臺管理系統測試計劃》《XX后臺管理系統測試用例》《XX項目計劃》測試概要XX后臺管理系統測試從2007年7月2日開始到2007年8月10日結束，共持續39天，測試功能點174個，執行2385個測試用例，平均每個功能點執行測試用例13.7個，測試共發現427個bug，其中嚴重級別的bug68個，無效bug44個，平均每個測試功能點2.2個bug。XX總共發布11個測試版本，其中B1—B5為計劃內迭代開發版本（針對項目計劃的基線標識），B6－B8為回歸測試版本。計劃內測試版本，B1—B4測試進度依照項目計劃時間準時完成測試并提交報告，其中B4版本推遲一天發布版本，測試通過增加一個人日，準時完成測試。B5版本推遲發布2天，測試增加2個人日，準時完成測試。B6－B11為計劃外回歸測試版本，測試增加5個工作人日的資源，準時完成測試。XX測試通過Bugzilla缺陷管理工具進行缺陷跟蹤管理，B1—B4測試階段都有詳細的bug分析表和階段測試報告。進度安排版本/時間計劃開始時間實際開始時間計劃完成時間實際完成時間加班增加資源B12007.7.22007.7.22007.7.52007.7.5否否B22007.7.162007.7.162007.7.192007.7.19否否B32007.7.232007.7.232007.7.252007.7.24否2個人日B42007.7.282007.7.292007.7.312007.7.311個人1天1個人2天2個人日B52007.8.12007.8.22007.8.62007.8.3否2個人日B62007.8.42007.8.42個人1天2個人日B72007.8.52007.8.51個人1天1個人日B8B92007.8.92007.8.92007.8.102007.8.10否2個人日B10合計1個人6天11個人日測試執行此次測試嚴格按照項目計劃和測試計劃執行，按時完成了測試計劃規定的測試對象的測試。針對測試計劃規定的測試策略，在測試執行中都有體現，在測試執行過程中，依據測試計劃和測試用例，對系統進行了完整的測試測試用例功能性系統實現的主要功能，包括查詢，添加，修改，刪除。系統實現的次要功能，包括為用戶分配酒店，為用戶分配權限，渠道酒店綁定，渠道RATE綁定，權限控制菜單按鈕。需求規定的輸入輸出字段，以及需求規定的輸入限制易用性操作按鈕提示信息正確性，一致性，可理解性限制條件提示信息正確性，一致性，可理解性必填項標識輸入方式可理解性中文界面下數據語言與界面語言的一致性測試環境軟硬件環境硬件環境應用服務器數據庫服務器客戶端硬件配置CPU：Intel(R)Celeron(R)CPU2.40GHzstepping01Memory：1048256kHD：ST380817AS80GSATACPU：Intel(R)Celeron(R)CPU2.40GHzstepping01Memory：1048256kHD：ST380817AS80GSATACPU：Intel(R)Celeron(R)CPU2.40GHzstepping01Memory：1048256kHD：ST380817AS80GSATA軟件配置OS：CentOS4.2JDK1.5.0_06Apache2.2.0Tomcat5.5.15OS：CentOS4.2MySQL5.0.17LinuxWindow2000Professional（SP2）IE6.0.2900.2180.xpsp_sp2網絡環境10MLAN10MLAN10MLAN網絡拓撲測試結果Bug趨勢圖此次黑盒測試總共發布10個版本，V1.0.1-V1.0.5為計劃內迭代開發版本（針對項目計劃的基線標識），V1.1.1-V1.2.2為進行的回歸測試版本，所有版本一共發現bug1306個。bug版本趨勢圖如下圖所示：由Bug的版本分布圖可以看出，V1.0.1-V1.0.5版本質量非常不穩定，bug數量最高達到189個，V1.0.1作為第一個版本bug數量為58個。在版本V1.0.3驗證了前面發現的所有bug的基礎上遺留bug數量在123個質量表現也不夠穩定，在V1.1.1新增了批量制證、數據恢復、數據備份、數據清除等功能所以bug數目驟增為232個。隨著版本的迭代在版本V1.2.2bug數量逐漸將為0。Bug優先級分布測試發現的bug主要集中在未完善功能級別major，屬于一般性的功能缺陷，但是測試的時候，出現了163個涉及到程序崩潰、程序啟動不了、不能完成正常制證、不能完成正常印刷等嚴重級別的bug，出現嚴重級別的bug主要表現在以下幾個方面：系統的主要功能沒有實現本地數據庫數據量比較大的時候出現程序崩潰死機系統主要功能邏輯混亂導致意外bug后臺進程在程序關閉后沒有相應停止導致程序不能啟動WebAPI接口調用錯誤導致核心功能不可實現問題類型分布系統的問題類型主要分布于測試過程和維護過程發現影響系統運行的缺陷bug和對現有系統功能的改進improvement。Bug占所有問題類型的百分比為：97%，improvement占所有問題類型的百分比為：3%。圖上結果說明系統在需求采集、程序設計工作過程中考慮十分全面極少存在功能設計遺漏問題。Bug模塊分布圖由上圖可以看出，bug主要分布模塊是CerDesk印刷端（405個）和CerDesk制證端（534個）兩個工作臺，占到了全部bug的2/3以上。而CerWeb服務器端（260個）的bug分布相對來說比較少占總體百分比為7%。CerDesk運維端（107個）的bug量最少主要原因是功能比較簡單。最近提交缺陷圖由上圖可以看出，在統計的十個周bug提交和解決狀況比較理想，當前提交的bug都能夠在很快的時間得到修復，并且隨著版本的穩定解決bug數量為全部解決新增bug數量逐漸降為0，整個過程屬于正常的軟件版本迭代過程。Bug狀態分布由bug狀態圖可以看出，打開的bug有0個，重新打開的bug有0個。已解決bug有2個，主要是版本V1.2.2中提交的界面易用性bug，而其他的1304個都是已驗證修復并關閉的bug。系統整體的遺留bug數量達到測試結束標準。測試結論功能性系統正確實現了通過數據字典管理基礎數據的功能，實現了數據內容的多語言功能，實現了中英文界面。實現了基礎數據管理，酒店集團管理，酒店基礎信息管理，渠道管理，代理管理，用戶管理的查詢，添加，修改，刪除的功能，系統還實現了將權限控制細化到菜單按鈕的功能。系統在實現用戶管理下的權限管理功能時，存在重大的缺陷，權限控制不嚴密，權限設計有遺漏。易用性現有系統實現了如下易用性：查詢，添加，刪除，修改操作相關提示信息的一致性，可理解性輸入限制的正確性輸入限制提示信息的正確性，可理解性，一致性現有系統存在如下易用性缺陷：界面排版不美觀輸入，輸出字段的可理解性差輸入缺少解釋性說明中英文對應的正確性中英文混排可靠性現有系統的可靠性控制不夠嚴密，很多控制是通過頁面控制實現的，如果頁面控制失效，可以向數據庫插入數據，引發錯誤。現有系統的容錯性不高，如果系統出現錯誤，返回錯誤類型為找不到頁面錯誤，無法回復到出錯前的狀態兼容性現有系統支持window下的IE瀏覽器和傲游瀏覽器，支持linux系統下的IE瀏覽器和火狐瀏覽器。現有系統未進行其他兼容性測試安全性現有系統控制了以下安全性問題：把某一個登錄后的頁面保存下來，不能單獨對其進行操作不進行登錄直接輸入某一頁面的Url能否打開頁面并進行操作不應該允許。現有系統未控制以下安全性問題：用戶名和密碼應對大小寫敏感登陸錯誤次數限制分析摘要覆蓋率此次測試，所有測試用例都是在中文界面下執行，未在英文界面下執行，測試不包括英文界面下的測試，也不包括正對英文翻譯的測試。此次測試，部分頁面需求描述無明確的定義，對輸入限制無詳細定義，無明確的測試依據，在測試過程中，測試是根據輸入字段含義，測試人員理解，以及和項目經理，開發人員溝通獲得測試依據，無法保證測試依據的正確性和完整性，因此，沒有進行完整的，正確的無效數據的測試，測試覆蓋率不夠，無法保證測試的有效性和正確性下面為此次測試測試用例覆蓋率分析圖：遺留缺陷的影響1．缺陷描述：酒店娛樂項添加頁面，“距離”字段無單位，建議增加單位缺陷影響：距離字段無單位說明，無衡量標準，用戶易用性不好推遲原因：需求定義無單位定義，統一在升級版本中解決2．缺陷描述：酒店基礎信息管理模塊，默認語言設置不一致。用中文查詢酒店，進入酒店基礎信息模塊后，如下模塊，語言顯示為“請選擇”列表頁面添加頁面取消政策停留政策擔保政策機場參照點會議室詳情打包促銷服務Rate而其他模塊語言顯示“中文語言”缺陷影響：相同功能模塊默認語言設置不一致，一致性不好推遲原因：默認語言設置，目前無統一標準，升級版本中統一3．缺陷描述：tomcat日志有亂碼，日志無項目名稱，查看不方便缺陷影響：其他項目日志都有項目名稱，日志無項目名稱，查看不方便推遲原因：目前的日志為了調試方便，顯示了很多其它信息，在項目正式發布時會統一處理的。4．缺陷描述：取消政策管理要么，取消時間“天/小時”缺少單位補充字段缺陷影響：該處因為是兩個不同的單位時間，需要有另外一個單位補充字段補充所所填寫內容的單位推遲原因：該缺陷單位補充字段本來存在，翻譯不夠準確，不能理解為補充單位的字段，需要等翻譯完畢后再確認。5．缺陷描述：數據字