軟件項目管理背誦總結

將老師所發ppt的知識點整理，方便查閱與背誦。

1. 概述

1.1 什么是項目？

答：

1. 項目是為了創造一個唯一的產品或提供一個唯一的服務（目標性）而進行的臨時性的努力；
2. 是以一套獨特而相互聯系的任務為前提，有效利用資源（資源約束性），在一定時間內滿足一系列特定目標的多項相關工作的總稱。

1.2 項目有那些特征？

答：

1. 目標性
2. 臨時性
3. 獨特性
4. 資源約束性
5. 不確定性

1.3 項目于日常工作有什么區別？

答：

1. 時限：項目是一次性的，日常運作是重復進行的
2. 追求：項目是以目標為導向的，日常運作是通過效率和有效性體現的
3. 組織：項目是通過與項目經理及其團隊工作完成的，而日常運作是職能式的線性管理
4. 管理：項目存在大量的變更管理，而日常運作基本保持持續的連貫性的

1.4 如何衡量一個項目是否成功？

答：

1. 衡量項目是否成功，應該看該項目是否在工程允許范圍內按照成本預算和進度計劃，生產出客戶滿意的產品
2. 四要素
   1. 項目范圍
   2. 成本
   3. 進度
   4. 客戶滿意度

1.5 軟件項目還有什么特征？

答：

1. 抽象性
2. 復雜性
3. 經驗在軟件項目中起很大作用
4. 變更是軟件項目中常見現象
5. 項目的獨特性和臨時性決定項目是漸進明細的
6. 目前，軟件項目的開發較其他領域的項目缺少規范
7. 軟件項目四要素
   1. 過程，結果，所需資源，委托人。

1.6 什么是項目管理？

答：

指在項目活動中運用專門的知識、技能、工具和方法，使項目能夠實現或超過項目干系人的需要和期望

1. 知識領域劃分：項目范圍，進度，成本，質量，人力資源，溝通，風險，變更管理
2. 項目干系人：指參與項目和受項目活動影響的人，包括項目發起人、項目組、 協助人員、客戶、使用者、供應商，甚至是項目的反對者。

1.7 項目管理的內容可以從幾個方面劃分？

答：

1. 管理職能角度

2. 項目管理包括項目計劃、組織、人事 安排、控制、協調等方面的內容

3. 項目獲得的全過程角度

   1. 項目管理包括項目決策、項目規劃與設計、項目的招投標、項目實施、項目終結與后評價等 方面的內容

4. 項目投入資源要素角度

   1. 項目管理包括項目資金財務 管理、項目人事勞動管理、項目材料設備管理、項目技術管理、項目信息管理、項目合同管理等方面的內容

5. 項目目標和約束角度

   1. 項目管理包括項目進度管理、 項目成本管理、項目質量管理等方面的內容

1.8 項目管理具有什么特征？

答：

1. 創造性
   1. 項目的一次性特點，決定了每實施一個項目都要具有創新性。
2. 項目管理是一項復雜的工作，具有較強的不確定性
   1. 項目一般由多個部分組成，工作跨越多個組織、多個學科、多個 行業，可供參考的經驗很少甚至沒有
3. 項目管理需要專門的組織和團隊
   1. 項目管理通常要跨越部門的界限，在工作中將會遇到許多不同部 門的人員
4. 項目經理的作用非常重要
   1. 項目經理要在有限的資源和時間的約束下，運用系統的觀點、科 學合理的方法對與項目相關的所有工作進行有效的管理，因此項 目經理對項目的成敗起著非常重要的作用。

1.9 軟件項目管理有什么特征？

答：

1. 軟件是純知識產品，其開發進度和質量很難估計和度量，生 產效率也難以預測和保障。需求在開始難以明確，與過早簽 訂合同是矛盾的
2. 周期長，復雜度高，變數多
3. 軟件需要滿足一群人的期望，其對項目的關注點不同，利益 也不同
4. 軟件項目管理的目的是讓軟件項目能在控制之下，以預定成本，按質完成

1.10 項目管理的十個知識領域與五個標準化過程組是什么？

答：

十個知識領域：

1. 項目集成管理 (project integration management)
2. 項目范圍管理 (project scope management)
3. 項目進度管理 (project schedule management)
4. 項目成本管理 (project cost management)
5. 項目質量管理 (project quality management)
6. 項目資源管理 (project resource management)
7. 項目溝通管理 (project communication management)
8. 項目風險管理 (project risk management)
9. 項目采購管理 (project procurement management)
10. 項目干系人管理 (project stakeholder management)

五個標準化過程：也稱項目管理生命周期的5個階段。

1. 啟動過程組
2. 計劃過程組
3. 控制過程組
4. 執行過程組
5. 收尾過程組

1.11軟件過程是什么？

答:

1. 軟件項目的開發過程主要有系統調研、需求分析、概要設計、詳細 設計、編碼、測試、實施與維護等.
2. 軟件過程包括：流程、技術、產品、活動間關系、角色、工具等， 是軟件開發過程的各個方面因素的有機結合

1.12 過程管理是什么？

答：

1. 從做過的項目中總結出的一些完善的過程，稱為最佳實踐
2. 軟件過程管理就是對最佳實踐進行有效積累，形成可重復的過程， 使最佳實踐可以在機構內共享
3. 其目的是要讓過程能夠被共享、重用，并得到持續改進
4. 過程管理的內容包括過程定義和過程改進
   1. 過程定義：對最佳實踐進行總結，形成一套穩定的可重復的軟件過程
   2. 過程改進：根據實踐中對過程的使用情況，進行優化

1.13 過程管理與項目管理有什么關系？

答：

1. 項目管理用于保證項目的成功
2. 孤傲從管理用于管理最佳實踐
3. 這兩者不是相互孤立的，而是有機地緊密地結合的
4. 過程管理的成果即軟件過程可以在項目管理中輔助于項目管理工作。

1.14 什么是敏捷項目開發？

答：

1. 敏捷軟件開發(agile software development) ：是一個靈活的開發方法，用于在一個動態的環境中向干系人快速交付產品
2. 主要特點是關注持續地交付價值，通過迭代和快速的用戶反饋管理不確定性和應對變更
3. 4條價值觀：
   1. 個體和交互勝過過程和工具 (individual and interaction over process and tool)
   2. 可以工作的軟件勝過面面俱到的文檔 (working software over comprehensive documentation)
   3. 客戶合作勝過合同談判 (customer collaboration over contract negotiation)
   4. 響應變化勝過遵循計劃 (responding to change over following a plan)
4. 12個敏捷原則
   1. ① 最先要做的是通過盡早地、持續地交付有價值的軟件來使客戶滿意。 CFAIR
   2. ② 即使到了開發的后期，也歡迎改變需求。敏捷過程利用適應變化來為客戶創造競 爭優勢。
   3. ③ 經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時 間間隔越短越好。
   4. ④ 在整個項目開發期間，業務人員和開發人員盡可能地在一起工作。
   5. ⑤ 圍繞被激勵起來的個體組成團隊來構建項目，給他們提供所需的環境與支持，并且信任他們能夠完成工作。
   6. ⑥ 在團隊內部及團隊之間，最有效果并且最有效率的傳遞信息的方式就是面對面的 交流。
   7. ⑦ 可以工作的軟件是首要的進度度量標準。
   8. ⑧ 敏捷過程提倡平穩的開發。發起人、開發者和用戶應該能夠保持一個長期的、恒 定的開發速度。
   9. ⑨ 不斷地關注優秀的技能和好的設計會增強敏捷的能力。
   10. ⑩ 簡單——使未完成的工作最大化的藝術，是根本的。
   11. ? 最好的架構、需求和設計出自于自組織的團隊。
   12. ? 每隔一定的時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地調 整自己的行為。

2. 項目初始

2.1 如何確立一個項目？

答：

1. 項目評估
2. 項目立項
3. 項目授權
4. 確定生存期模型

2.2 什么是項目評估？如何項目評估？

答：

1. 真正啟動一個項目之前，需要對項目進行評估，主要從戰略、操作性、計劃、技術、社會可行性、市場可行性、經 濟可行性等方面進行評估
2. 成本效益分析方法是評價項目經濟效益的主要方法，它是將系統開發和運行所需要的成本與得到的效益進行比較，如果成本高于收益則表明項目虧損，如果成本小于效益則表明項目值得投資

2.3 請解釋成本效益分析方法中名詞。

答：

1. 現金流預測：是描述何時支出費用、何時有收益的過程

2. 凈利潤：是在項目的整個生命周期中總成本和總收入之差

3. 投資回報期：是達到收支平衡或者償還初始投入所花費的時間

4. 投資回報率：（會計回報率）用于比較凈收益率與需要的投入，常見的最簡 單的公式是 投資回報率=(平均年利潤/總投資)x 100%

5. 凈現值：是一種項目評價技術，考慮了項目的收益率和要產生的現金流的時限，它是基于這樣的觀點：今天收到100元要比明年收到的100元更好

6. 內部回報率：指可以直接與利潤比較的百分比回報。如果借貸的資本少于 10%，或者如果資本不投入到回報大于10%的其他地方，則具有10%的內部回報率的項目是值得做的

2.4 如何進行Make or Buy決策？

答：

對比因素	自制的理由	購買的理由
成本因素	自制成本低	購買成本低
技術能力	可以采用自制的技巧	不會自制
工作量管理	工作量可控	工作量小
戰略價值	可以獲得知識產權	購買更有益
風險與學習	學習新的技能	轉移風險
資源條件	有可用的開發人員	有很好的供貨商
項目重點	核心項目工作	項目可以將注意力放在其他工作上

2.5 項目的立項需要完成什么工作？

答：

1. 明確項目的目標、時間表、項目使用的資源和經費，而且得到執行該項目的項目經理和項目發起人的認可。這個階段稱為立項階段。
2. 立項是要解決做什么的問題，需要確定開發的項目，關注點是效益和利潤。項目立項報告的核心內容是確定立項前期需要投入多少， 能否盈利，什么時候能夠盈利，能否持久的盈利， 等等

2.6 合同項目立項的流程是怎么樣的？

答：

合同項目立項是指企業與外部客戶通過簽訂商業合同來啟動的項目。整體流程分為三個主要階段：

1. 甲方主導階段：招標書定義 → 供方選擇
2. 乙方響應階段：項目分析 → 提交建議書
3. 雙方合作階段：合同簽署 → 項目啟動

項目啟動準備：

• GAP期：合同簽訂后的緩沖準備期，用于團隊組建和資源調配
• Kick off：召開項目啟動會，標志項目正式開始
• Service Delivery：進入正式的服務交付階段

2.7 內部項目立項的流程是怎么樣的？

對比維度	合同項目	內部項目
約束機制	商業合同	內部協議
流程復雜度	復雜（招標、談判、法務）	簡化（重點在協調）
風險類型	商業風險、合規風險	管理風險、協調風險
管理重點	盈利性、合規性	協作性、效率性
簽署過程	正式合同簽署	內部協議確認

關鍵差異總結：

• 內部項目無需復雜的招投標流程
• 協議主要用于明確分工，而非商業保障
• 更注重部門間溝通協調和資源整合效率

2.8 什么是項目授權？要做什么？

答：

1. 對項目進行授權和初始化，以便確認相關的人知曉這個項目

2. 形式：文檔化輸出，主要是項目章程

2.9 什么是項目章程？

答：

1. 確認項目存在的文件，包括對項目的確認、對項目經理的授權和項目目標的概述等。
2. 項目章程類似項目的授權書，相當于對項目的正式授權，表明項目可以有效地開始了。項目章程授權項目，建立了項目經理的責任心 、發起人的主人翁意識及項目團隊的團隊意識。

2.10 項目經理有什么責任？

答：

1. 開發計劃 項目經理的首要任務就是開發計劃。完善合理的計劃對于項目的成功至關重要。項目經理 要在對 所有的合同、需求等熟知、掌握的基礎上，明確項目目標，并就該.目標與項目客戶達成一致，同 時告知項目團隊成員，然后為實現項目目標制訂基本的實施計劃（成本、進度、產品 質量）
2. 組織實施 項目經理組織實施項目主要體現在兩個方面：第一，設計項目團隊的組織結構圖，對各職位的工 作內容進行描述，并安排合適的人選，組織項目開發；第二，對于大型項目，項目經理 應該決定 哪些任務由項目團隊完成，哪些由承包商完成
3. 項目控制 在項目實施過程中，項目經理要時時監視項目的運行，根據項目實際進展情況調控項目， 必要的 時候，調整各項計劃方案，積極預防，防止意外的發生；及時解決出現的問題，同時預測可能的 風險和問題，保證項目在預定的時間、資金、資源下順利完成。
4. 項目組織的領導者，管理者，決策者，分析者，計劃者，控制者，組織者，評價者，協調者

2.11 軟件項目生存期模型有什么基本特征？

答：

1. 描述了開發的主要階段
2. 定義了每一個階段要完成的主要過程和活動
3. 規范了每一個階段的輸入和輸出

2.12 有哪些常用的生存期模型？給出它們的簡單介紹和特點

答：

模型名稱	簡單介紹	主要特點	適用范圍
瀑布模型 (Waterfall)	按照需求分析、系統設計、編碼、測試、維護的順序逐步進行，每個階段完成后才進入下一階段	? 線性順序執行，階段間有明確里程碑 ? 每個階段都有詳細文檔輸出 ? 前一階段完成后才能進入下一階段 ? 結構清晰，管理簡單	? ?優先選擇：前期需求明確且穩定的項目 ? 技術成熟、風險較低的項目 ? 編碼人員經驗較少的團隊 ? 多個獨立功能開發（功能內遵循瀑布）
V模型 (V-shaped)	瀑布模型的改進版，強調測試與開發階段的對應關系，是改進型瀑布模型的典型代表	? 開發階段與測試階段一一對應 ? 強調早期測試計劃和驗證 ? 左臂開發過程，右臂測試過程 ? 重視質量保證和缺陷預防	? 前期需求明確的高質量要求項目 ? 安全關鍵型系統 ? 對質量要求極高的系統 ? 作為瀑布模型的改進選擇
快速原型模型 (Rapid Prototyping)	通過快速構建系統原型幫助用戶理解需求，在用戶反饋基礎上不斷完善系統	? 快速構建可運行的原型 ? 用戶早期參與，頻繁反饋 ? 迭代式開發和改進 ? 降低需求理解風險	? 🔧必須使用：用戶無信息系統使用經驗，需求分析人員技能不足 ? 需求不明確或易變的項目 ? 用戶界面要求高的系統 ? 可與增量、迭代綜合使用
增量模型 (Incremental)	將軟件分解為多個增量，每個增量都包含完整的開發周期，逐步交付可用的軟件產品	? 分批次交付功能 ? 每個增量都是完整的子系統 ? 用戶可以早期獲得部分功能 ? 降低項目整體風險	? 💰資金限制：資金和成本無法一次到位 ? 📈需求不穩定：優先采用增量迭代模型 ? 軟件產品分多個版本發布 ? ??注意：全新系統需總體設計完成后開始
螺旋式模型 (Spiral)	結合瀑布和原型模型優點，通過風險驅動的迭代開發過程，每個迭代都包含風險分析	? 風險驅動的開發過程 ? 四象限：確定目標、風險分析、開發測試、規劃下輪 ? 適應性強，可處理需求變化 ? 強調風險管理	? 🔥高不確定性：不確定性因素很多，很多東西前面無法計劃 ? 高風險、大型復雜項目 ? 創新性技術項目 ? 需要有經驗的開發團隊
快速應用開發 (RAD)	強調快速開發和交付，通過并行開發、重用組件和用戶參與來縮短開發周期	? 開發周期短（60-90天） ? 大量使用現有組件和工具 ? 用戶深度參與開發過程 ? 并行開發多個模塊	? 時間緊迫的業務應用系統 ? 有豐富組件庫的項目 ? 用戶需求相對穩定的項目 ? 需要快速交付價值的項目
漸近式階段模型	通過多個階段逐步接近最終目標，每個階段都有明確的交付物和評估標準	? 階段性目標明確 ? 逐步逼近最終目標 ? 每階段都有里程碑檢查 ? 可根據評估結果調整方向	? 探索性項目，目標逐步明確 ? 需要階段性評估和調整的長期項目 ? 研究開發類項目 ? 目標不夠明確的項目
敏捷型模型 (Agile)	強調個體和互動、工作軟件、客戶合作和響應變化，通過短迭代周期快速交付價值	? 短迭代周期（1-4周） ? 持續交付可工作軟件 ? 客戶深度參與和反饋 ? 擁抱變化，快速響應 ? 團隊自組織和協作	? 需求變化頻繁的創新項目 ? 客戶可頻繁參與的項目 ? ?不建議：編碼人員經驗較少時 ? 小到中型團隊項目 ? 可與原型模型綜合使用

🔄 模型組合使用規則：

• 增量、迭代和原型可以綜合使用
• 每一次增量或迭代都必須有明確的交付準則
• 對于全新系統的開發必須在總體設計完成后再開始增量或并行

👥 團隊經驗考慮：

• 編碼人員經驗較少：建議采用瀑布模型，避免敏捷或迭代等復雜模型
• 有經驗團隊：可選擇螺旋、敏捷等復雜模型

🎯 并行開發策略：

• 多個獨立功能開發：可在需求階段分功能并行，但每個功能內都應遵循瀑布模型

3.項目范圍計劃——需求管理

3.1 什么是軟件需求？

答：

1. 軟件需求是指用戶對軟件的功能和性能的要求。
2. 軟件需求三個層次
   • 業務需求：組織機構或客戶對系統，產品高層次的目標要求，由管理人員或市場分析人員確定
   • 用戶需求：用戶通過使用本軟件產品必須完成的任務，用戶協助提供
   • 功能需求：開發人員必須實現的軟件功能
3. 軟件需求規格
   • 描述了軟件系統應具有的外部行為，即系統展現給用戶的行為和執行的操作

4. 需求類型:
   • 功能需求：系統必須執行的功能
   • 非功能需求：對實際使用環境所做的要求，如性能要求，可靠性 ，安全性
     • 非功能需求比功能需求要求更嚴格，更不易滿足

3.2 什么是需求工程？有什么作用？

答：

1. 80年代中期，形成了軟件工程的子領域——需求工程
2. 需求工程：指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的一門學科。
3. 作用：保證軟件需求以一種技術形式描述一個產品應具有的功能，性能和性質
4. 5個獨立過程：獲取，分析，規格，驗證，變更

3.3 什么是需求獲取？

答：

1. 需求獲取是指通過與用戶的交流，對現有系統的觀察及對任務進行 分析，從而開發、捕獲和修訂用戶的需求。
2. 主要任務：和用戶方的領導層，業務層人員的訪談式溝通
3. 目的：從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構，業務流程，硬件環境，軟件環境，現有運行系統等具體情況和客觀的信息，建立起良好的溝通渠道和方式。

3.4 需求獲取有哪些活動？

答：

1. 了解客戶方的所有用戶類型及潛在的類型，然后根據他們的要求來確定系統的整體目標和系統的工作范圍。
2. 進行需求調查，對用戶進行訪談和調研。
3. 需求分析人員對收集到的用戶需求做進一步的分析和整理
4. 需求分析人員將調研的用戶需求以適當的方式呈交給用戶方和開發方的相關人員。大家共同確認需求。

3.5 需求獲取需要注意什么？

1. 識別真正的客戶
2. 正確理解客戶的需求
3. 具備較強的忍耐力和清晰的思維
4. 說服和教育客戶
5. 需求獲取階段一般需要建立需求分析小組，進行充分交流，互相學習，同時要實地考察訪談，收集相關資料，進行語言交流，必要時可以采用圖形、表格等工具。

3.6 什么是需求分析？

答：

1. 需求分析又稱為需求建模

2. 需求分析是為最終用戶所看到的系統建立一個概念模型，是對需求的抽象描述，并盡可能多地捕獲現實世界的語義。

3. 應有足夠的重視，并分配充足的時間和人力，要讓有經驗的系統分 析員負責，切忌讓項目新手或程序員負責

4. 需求分析的結果是提供需求分析模型，它是產品的原型樣本，使最 終產品更接近于解決需求，提高了用戶對產品的滿意度，從而使產 品成為真正優質合格的產品

3.7 需求分析有哪些活動？

答：

1. 以圖形表示的方式描述系統的整體結構，包括系統的邊界與接口。
2. 通過原型、頁面流或其他方式向用戶提供可視化的界面，用戶可以對需求做出自己的評價。
3. 以模型描述系統的功能項、數據實體、外部實體、實體之間的關系 、實體之間的狀態轉換等方面的內容。
4. 需求分析的基本策略是采用頭腦風暴、專家評審、焦點會議組等方式 進行具體的流程細化、數據項的確認
5. 必要時可以提供原型系統和明確的業務流程報告、數據項表，并能清 晰地向用戶描述系統的業務流設計目標
6. 用戶方可以通過審查業務流程報告、數據項表及操作開發方提供的原 型系統來提出反饋意見，并對可接受的報告、文檔簽字確認。
7. 在項目需求分析階段，對問題的描述要足夠細致
   • 應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準

3.8 什么是需求規格編寫？

答：

1. 軟件需求規格的編制是為了使用戶和軟件開發者雙方對該軟件的初 始規定有一個共同的理解，使之成為整個開發工作的基礎
2. 需求分析完成的標志是提交一份完整的軟件需求規格說明書 (SRS)
3. 需求規格說明書為客戶和開發者之間建立一個約定，準確地陳述了要交付給客戶什么。
   • 軟件需求規格說明書的格式可以根據項目的具體情況采用不同的格式，沒有統一的標準

3.9 什么是需求驗證？

答：

1. 定義：需求規格提交后，開發人員需要與客戶對需求分析的結果進行驗證， 以需求規格說明書為輸入。
2. 目的：以求需求規格中定義的需求必須正確、準確地反映用戶的意圖
3. 作用：驗證需求的正確性及其質量能大大減少項目后期的返工現象

3.10 需求驗證要保證什么性質？

答：

? 正確性，一致性，完整性，可行性，必要性，可檢驗性，可跟蹤性，最后的簽字

3.11 為什么要有需求變更管理？

答：

1. 需求變更是軟件項目一個突出的特點，也是軟件項目最為普遍的一個特點
2. 需求變更是導致項目失敗的主要原因之一。
3. 需求變更成本可以占項目總成本的40％

3.12 需求變更管理要完成什么工作？

答：

1. **建立需求基線。**需求基線是需求變更的依據。此后每次變更并 經過評審后，都要重新確定新的需求基線
2. **確定需求變更控制過程。**制定變更控制流程，并形成文檔
3. 建立變更控制委員會 (SCCB)或相關職能的類似組織 。負責裁定接受哪些變更
4. **進行需求變更影響分析。**需求變更先申請然后評估
5. **跟蹤所有受需求變更影響的工作產品。**軟件計劃、產品、活動 都要進行相應的變更，以和更新的需求保持一致
6. 跟蹤每項需求的狀態，衡量需求穩定性

3.13 請舉例需求變更流程

答：

1. 根據變更輸入，按照變更控制系統規定的審批程序執行，通過嚴格審查變更申請后，決定項目變更是否應得到批準或拒絕。

3.14 有哪些傳統需求分析方法？

答：

1. 原型分析方法
2. 基于數據流的建模方法（結構化分析的主要方法）
3. 基于UML需求建模方法
4. 功能列表法

3.14注 什么是結構化的分析方法？

答：

結構化分析方法的定義（SA,Structured Analysis）

1. 20世紀70年發展起來的
2. 是一種自頂向下逐步求精的分析方法
3. 根據軟件內部數據傳遞、變換的關系進行分析的
4. 結構化分析方法是很多其他方法的基礎

3.14.1 原型分析方法

答：

1. 原型分析方法是通過不斷評價原型來確定需求的方法
2. 在需求分析階段，通過不斷優化這個原型來最終確定項目需求
3. 實踐中可以采用原型建模工具建模，如 Axure 等快速原型設計工 具
4. 與用戶很容易交流。

3.14.2 數據流建模的方法

答：

1. 將現實世界描繪為數據在信息系統中的流動，以及在數據流動過程中數據向信息的轉化
2. 數據流圖 (DFD) 、數據字典 (DD) 、實體聯系圖 (ERD) 、 系統流程圖等都是數據流分析技術
3. 數據流圖DFD，是一種描述軟件系統邏輯模型的圖形符號，使用4 種基本元素來描述系統的行為，即過程、實體、數據流和數據存儲

3.14.3 基于UML建模的方法

答：

1. 一種面向對象的分析方法。從用戶角度看需求，將功能需求描述為 一些用例（use case）
   • 一個用例就是系統向用戶提供一個有價值的結果的某項功能。用例捕捉的是功能性需求。
   • 所有用例結合起來就構成了“用例模型”，描述系統的全部功能
2. 方法主要通過UML的用例視圖、順序視圖、活動視圖等表達需求模型
   • 一個系統往往可以從不同的角度進行觀察，從一個角度觀 察到的系統，就構成系統的一個視圖（view）
3. 分析流程：
   • 識別出系統的Actor
   • 描述主要的Use case
   • 實現用例視圖（Use case Diagram）
   • 實現順序視圖（Sequence Diagram）
   • 實現活動視圖（Activity Diagram）
   • 狀態視圖（State Diagram）等

3.14.4 功能列表法

答：

1. 功能列表（feature list）方法是對項目的功能需求進行詳細說明的一種方法。
2. 是基于功能特性及其層次關系來描述需求的方法。

需求類別（功能/性能）	名稱/標識	描述
特性Feature A	A.1
	…
	A.n
特性Feature B	B.1
	…
	B.n
特性Feature C	C.1
	…

3.14.5 敏捷項目需求分析有哪幾個關鍵要素？

答：

1. 產品待辦事項列表
   • 細化產品待辦事項列表
2. 用戶故事

• 用戶故事模板
• 評價用戶故事
• 用戶故事迭代優先級

3.14.5注0 敏捷項目需求分析的背景

答：

1. 需求不斷變化、風險大或不確定性高的項目，其范圍逐漸明確
2. 敏捷思維認為，對于需求可以“漸進明細”，以便應對變化.
3. 敏捷方法將需求列入未完項，不斷構建和審查原型，并通過發布多個版本來明確需求。

3.14.5注1 什么是產品代辦事項列表？

答：

1. 產品待辦事項列表是一個敏捷團隊管理開發過程的核心，所有的活動和交付物都圍繞它來進行。
2. 產品待辦事項列表可以幫助我們對將要做的事情有一個整體的認識，以及可以知道我們現在的狀態。
3. 通過產品待辦事項列表梳理活動，即將被實現的產品待辦事項會得到澄清，變得明確，粒度也拆得更小。

3.14.5注2 如何細化產品代辦事項列表？

答：

1. 每個迭代中，獲得細化的待辦事項列表（產品待辦事項列表 ?Sprint訂單）

   Sprint訂單是指：

   • 從產品待辦事項列表（Product Backlog）中選擇出來的

   • 在當前Sprint迭代中需要完成的

   • 具體的、細化的任務清單

2. 細化的過程就是編寫用戶故事的過程，即每個迭代的需求是通過用戶故事描述的。

3. 細化會議上，產品負責人有很多方法處理待辦事項列表的細化準備 與會議，其中包括

   • 鼓勵團隊在開發人員、測試人員、業務分析人員和產品負責人三方面開展合作，一起討論和撰寫故事。
   • 把整個故事的概念呈現給團隊。團隊進行討論，并根據需要將其細化為許多故事。
   • 與團隊一起尋找各種方法探索和撰寫故事，確保所有的故事都足夠小，以便團隊能源源不斷地交付完成的工作

3.14.5注3 什么是用戶故事模板？

答：

1. 用戶故事按照一定的語法形式進行表示，不使用技術語言來描述， 只是以客戶能夠明白的、簡短的形式表達。
2. 需求包括功能性需求和非功能性需求，用戶故事可以描述功能性需求，也可以描述非功能需求。

3.14.5注6 如何評價一個用戶故事？

答：

用戶故事INVEST的特點

• I，independent，代表獨立的

• N，negotiable，代表可協商的

• V，valuable，代表對用戶或客戶有價值的*

• E，estimable，代表可估計的

• S，small，代表小的

• T，testable，代表可測試的

3.14.5注7 用戶故事有哪些優先級？

答：

迭代開發是基于用戶故事優先級進行的，因此需要對用戶故事的優 先級進行排序。用戶故事的排序遵守一定的規則，如MoSCoW方法

• Must Have：必須做的/必須要有的；
• Should Have：應該做的/應該有的；
• Could Have：可以做的/可以有的
• Won’t Have：不要做的/不能有的

4. 項目范圍計劃——任務分解

4.1 什么是任務分解？

答：

1. 將一個項目分解為更多的工作 細目或者子項目，使項目變得更 小、更易管理、更易操作
2. 任務分 解結果：WBS（Work Breakdown Structure:任務分解結構）

4.2 什么是WBS？

答：

1. WBS是把所有項目工作逐層分解到較小的、便于管理的要素（可交付成果）。
   • WBS 的組成元素有助于項目干系人檢查最終的產品
2. WBS是用來確定項目范圍的，必須包括項目的所有工作。
   • WBS 是管理項目范圍的基礎，詳細描述了項目所要完成的工作
3. 沒有包含在WBS中的工作就不是項目范圍內的工作，都不要做。如果要做，必須通過范圍控制過程。
4. WBS的編制需要**“全員參與”，項目經理主要發揮“整合者”**的作用。
5. WBS的最底層組織部分是工作包（Work Package）。
   • WBS 的最低層元素是能夠被評估的，可以安排進度的和被追蹤的
6. 在WBS中可以單獨列出一個**“項目管理”**分支，包括項目管理相關工作。

4.3 WBS有什么作用？

答：

1. 明確和準確說明項目范圍
2. 工作分解結構定義項目邊界，明確需要做的工作
3. 確定所需要的技術和人力資源，明確人員職責
4. 進行時間，成本和資源估算，提高估算的準確性
5. 確定工作內容和工作順序，并根據實踐情況進行調節和控制
6. 估計項目整體和全過程費用
7. 有助于防止需求蔓延

4.4 有幾種WBS分解的形式？

1. 提綱式WBS也稱為清單式WBS

   • 最常用，項目管理軟件中常使用 適用于大型項目
   

2. 組織結構圖式WBS也稱為圖表式WBS

   • 優點：直觀結構清晰
   • 缺點：不易修改
   • 不適用：大型項目
   

4.5 工作分解有哪些層次？

答：

1. 項目群：叫大項目，也可以叫工程項目
2. 項目
3. 任務：完成項目必須進行的工作
4. 活動：完成任務需要做什么。
5. 工作包：活動的構成單元，它體現了活動是如何做的。
6. 工作單元：一般的WBS中，不需要分解到具體動作層。

4.6 如何理解工作包（work package）？

答：

1. 工作包（Work Package），是WBS中最底層的項目可交付成果，工作包可以再細分為具體動作。

2. 項目經理通常只負責到工作包的層次，負責該工作包的團隊成員負責把工作包細分為實際工作。

3. 個工作包必須由一個人或者一個部門來負責，而不能由兩個或兩個以上的人或部門來負責。

4. 工作包單元的周期應該是最短周期/

5. 應明確本工作包與其他工作包之間的關系

   • 能夠對工作包進行進度安排，成本估算，監視和控制

   • 要求: 邏輯上不可再分，<80h，易于估算，明確責任人

   • 一個人兩周能干完的工作或將一個 人80小時能干完的工作稱為一個工作包

4.7 WBS的編碼有什么用？

答：

1. 為了簡化信息交流過程，常利用編碼技術對WBS進行信息轉換。
2. 通常對每一層的每項任務需要按照來編號。

4.8 什么是WBS字典？

答：

1. WBS字典，是在制定WBS過程中生成，并與WBS配合使用的說明性文件
2. WBS具體工作要素的闡述通常收集在WBS字典(WBS dictionary) 中，同時也包括一些其他信息的闡述

4.9 有哪些任務分解的方法？

答：

1. 模板參照
   • 許多應用領域都有標準或半標準的wbs，它們可以當做模板參考使用
2. 類別方法
   • 許多項目有相同或相似周期和因此形成的相同或相似的工作細目要 求，可以采用類似項目的WBS作為參考
3. 自上而下
   • 自頂向下方法從一般到特殊的方向進行
   • 自頂向下方法需要有更多的邏輯和結構，它也是創建WBS的最好方法
   • 如果WBS開發人員對項目比較熟悉或者對項目大局有把握，可以使用自頂向下方法
4. 自下而上
   • 自底向上是從特殊向一般方向進行的。
   • 如果對于項目人員來說，這個項目是一個嶄新的項目，可以采用自底向上方法開發WBS。

4.10 任務分解的基本步驟是怎么樣的？

答：

1. 確定分解標準
   • 按照生存期階段或產品組成分解
   • 不能同時使用兩種標準進行分解
2. 確認并分解項目的組成要素。
3. 確定分解是否詳細
4. 確定項目交付成果（可以編制WBS字典）
5. 驗證分解的正確性（建立一套編號系統）
   • 必要和充分性檢查
   • 完整和模糊性檢查
   • 可計劃和控制性檢查（分配工期、預算、資源和責任人）

4.11 工作分解中需要注意哪些問題？

答：

1. 不要把工作分解結構變成物品清單
   • 分解出的工作包應是一項項的行動，而不能僅僅用名詞來表達。
2. 不要考慮活動之間的先后順序
   • 工作分解結構的目的是清楚地界定實現項目目標所需執行的具體活動，并不關心 究竟先做那個、后做那個。活動之間的先后順序等到確定關鍵路徑時再考慮。
3. 不要試圖去做畫蛇添足的事
   • 如果你以小時為單位來分解工作，而又無法把工作控制到這個程度，那你不妨將 工作分解到以天或周為單位就打住，否則，既浪費了時間，又辦不成事情
4. 項目分解的原則
   • 在各層次上保持項目內容的完整性，不能遺漏工作單元。
   • 一個項目單元只能從屬于某一個上層單元，不能交叉。
   • 項目單元應能區分不同的責任人和不同的工作內容。
   • 項目結構分解應能方便工期、成本、質量等的控制。
   • 詳細程度適中。

4.12 什么是項目可交付結果與里程碑事件？

答：

1. 通過WBS分解出項目的工作任務后，還要進一步將每項任務的交付結果，即把項目的中間結果定義出來，目的是使項目組明白完成 WBS的任務后輸出的產品是什么。
2. 在項目的一系列可交付結果中，可能會有一些事件的開始或結束對項目目標的有效實現至關重要，這些事件稱之為里程碑事件
   • 里程碑事件必須是項目可交付結果完整的中間產品，對這一事件的描述必須精確，必須被所有項目參與人所準確理解
   • 里程碑事件的完成可度量

4.13 工作分解有哪些困難？該如何解決？

答：

1. 對于不是很大的項目很有效，而對于耗時長成本大的項目則分解成本太高。
2. 工作包的成本有時候難以確定的，新技術的應用會改變項目的進度和預算。
3. 在工作分解結構的技術層，各種活動直接相關性非常復雜，難以用圖表表達。

為解決上述困難，可以為項目預留一部分資源（包括時間、進度、 資源）給不確定因素。

4.14 工作分解有哪些建議？

答：

1. 工作分解結構必須面向可交付成果的
2. 工作分解結構必須符合項目的范圍
3. 工作分解結構的底層應該支持計劃和控制
4. 工作分解結構中的元素必須有人負責，而且只由一個人負責，盡管實際上可能需要多個人參與
5. 工作分解結構的指導，每個級別的工作分解結構把上一級的一個 元素分為4-7個新的元素，同一級的元素的大小應該相似
6. 工作分解結構并非是一成不變的

4.15 如何展開敏捷項目的任務分解？

答：

1. 在敏捷開發過程中，通過用戶故事來將需求具體化成可以進行迭代開發的一個個現實的可見的開發任務。
2. 用戶故事是站在用戶的角度所描述的故事，是用戶所能看懂的故事 ，是對需求的細化和切分
3. 敏捷項目的分解過程，就是將史詩故事（Epic）分解成用戶故事。

• Epic–>Feature–>user Story–>Task

4. 敏捷分解檢驗,分解完成了用戶故事之后，應該給出接收標準, 它可以作為用戶測試用戶故事的依據.
   • 這個接收標準一般寫在故事卡片的后面，以確保這個用戶故事是可理解的，而且可以方便團隊討論這個用戶故事的業務價值。
5. 敏捷項目任務分解可以是對backlog列表進行細化的過程

5. 項目成本計劃——成本估算

5.1 什么是成本估算？有什么作用？

答：

成本管理是確保項目在預算范圍之內的管理過程，包括成本估算、成本預算、成本控制等過程。

1. 成本估算是對完成項目所需費用的估計和計劃
   • 估算不是很準確，有誤差
   • 項目經驗數據非常重要
   • 不要太迷信某些數學模型
2. 重要性和意義

• 軟件成本估算是成本管理的核心
• 成本估算貫穿于軟件的生存期。
• 成本估算是項目計劃中的一個重要組成部分要實行成本控制，首先要進行成本估算
• 軟件成本估算，一直是軟件工程和軟件項目管理中最具挑戰、最為重要的問題

5.2 成本分為哪幾類？有哪些成本？

答：

1. 直接成本
   • 指與項目有直接關系的成本費用，是與項目直接對應的，包括人員的工資、材料費用、外包外購成本等，包括開發成本、管理成本、質量成本等。
   • 人的勞動的消耗所需要的代價是軟件產品的主要成本，即開發成本 。
2. 間接成本
   • （如房租、水電、員工福利、稅收等） 不能歸屬于一個具體的項目 ，是企業的運營成本，可以分攤到各個項目中

5.4 什么是軟件項目規模？

答：

1. 軟件項目規模即工作量
   • 是從軟件項目范圍中抽出的軟件功能，然后確定每個軟件功能所必須執行的一系列軟件工程任務。
   • 是成本的主要因素，是成本估算的基礎
2. 軟件成本估算是預測開發一個軟件系統所需要的總工作量的過程。
3. 軟件項目成本，指軟件開發過程中所花費的工作量及相應的代價。
   • LOC (Lines of Code) 代碼行 源代碼長度的測量
   • FP (Function Point) 功能點 用系統的功能數量來測量
   • 人月 ，人天 ，人年

5.5 有哪些影響軟件項目成本的因素？

答：

1. 耗用資源的數量和價格
   • 中間產品和服務、市場人力資源、硬件、軟件的價格也對成 本產生直接的影響。價格對項目預算的估計影響很大。
2. 項目工期
   • 項目的費用由直接費用和間接費用組成，一般工期和直接費用成反比，和間接費用成正比
   • 縮短工期需要更多的、技術水平更高的人員，直接成本費用就會增加。
3. 項目質量
   • 質量總成本由質量故障成本和質量保證成本組成。
   • 質量故障成本指為了排除產品質量原因所產生的故障， 保證產品重新恢復功能的費用。
   • 質量保證成本為了保證和提高產品質量而采取的技術 措施所消耗的費用。
4. 項目管理水平

• 高的管理水平可以提高預算的準確度，加強對項目預算的執行和監 管，對工期的控制嚴格限制在計劃許可的范圍之內，對設計方案和 項目計劃更改造成的成本增加、減少和工期的變更，可以較為有效 地控制，減少風險的損失等。

---

5.6 成本估算的過程是怎么樣的？給出成本估算的方法。

答：

1. 估算輸入
   • 項目需求 ，工作分解結構WBS ，資源計劃 ，資源單位價格，進度計劃 ，歷史信息
2. 估算處理
   • 代碼行估算法、功能點估算法、用例點估算法、類比 (自頂向下) 估算法、自下而上估算法、參數估算法、專家估算法
3. 估算輸出
   • 估算通常以貨幣單位表達，如元、法郎、美元等，這個估算便是成 本估算的結果；也可用人月、人天 或人小時這樣的單位，這個估算結果便是項目規模估算的結果。有時用復合單位。
   • 成本估算是一個不斷優化的過程。
   • 估算說明 ①工作范圍的描述 ②說明估算的基礎和依據

5.6.1 代碼行估算法。

答：

1. 是一種面向規模的度量，從軟件程序量的角度定義項目規模。

• 與具體的編程語言有關

• 分解足夠詳細

• 有一定的經驗數據（類比和經驗方法）

2. LOC(Lines of Code) 代碼行，通常采用非注釋的源代碼行。

   • 可計算每千行代碼(KLOC)的錯誤數，缺陷數，成本，文檔頁數。

3. 簡單易行但代碼行數依賴選擇的硬件和軟件，因此并不被認為是軟件度量的最優方法。

5.6.2 功能點估算法（FP）

答：

1. 功能點分析中，系統分為5個組件：

   • 外部輸入、外部輸出、外部查詢、外部接口文件（因為這些組件的每一個都處理文件 ，因此被稱為事務）
   • 內部邏輯文件 （構成邏輯信息的存儲地）

2. 它是一種按照統一方式測定軟件功能的方法，最后的結果是一個數 。

   • 這個結果數可以用來估計代碼行數，成本和工期。
   • 與實現的語言和技術沒有關系。
   • 用系統的功能數量來測量其規模。
   • 通過評估、加權、量化得出功能點。

3. 功能點公式 FP =UFC*TCF

   • UFC：未調整功能點計數
   • TCF：技術復雜度因子

4. 功能點作為度量軟件規模的方法已經被越來越廣泛地接受

5.6.2.1 功能點估算中的系統組件（FP）

答

1. 外部輸入（EI）

   • 外部輸入是最終用戶或其他程序用來增加、刪除或改變程序數據的屏幕（screen）、表單 （form）、對話框（dialog）或控制信號 （control signal）等

2. 外部輸出（EO）

   • 外部輸出是程序生成供最終用戶或其他程序使用的屏幕、報表（ report）、圖表（graph） 或控制信號等。
   • 例如，報表和出錯信息 等。

3. 外部查詢（EQ）：

   • 外部査詢是輸入/輸出組合，其中一個輸入引出一個即時的簡單輸出。
   • 外部查詢是一個輸入引出一個即時的簡單輸出。沒有處理過程。

4. 外部接口文件 （EIF）

   • 外部接口文件是受其他程序控制的文件，是用戶可以識別的一組邏輯相關數據，這組數據只能被引用。
   • 數據完全存在于應用的外部，并且由另一個應用維護。外部接口文件是另外一個應用的內部邏輯文件。

5. 內部邏輯文件（ILF）

   • 內部邏輯文件是用戶可確認的、在應用程序內部維護的、邏輯上相關聯的最終用戶數據或控制信息，如一個平面文件，或者關系數據庫中的一個表。
   • 完全存在于應用的邊界之內，并且通過外部輸入維護，是邏輯主文件的數目。

5.6.2.2 給出功能點估算法的步驟

答：

1. 確定應用必須包含的功能

2. 對于于每一項功能，根據5項系統組件得到5類功能點數目

3. 在估算中對5類功能計數項中的每一類功能計數項按其復雜性的不同分為簡單（低）、一般（中）和復雜（高）3個級別。確定復雜度權重因素，對功能點進行加權得到未調整的功能點數量，得到該產品的未調整功能點計數（UFC）

項目	簡單（低）	一般（中）	復雜（高）
外部輸入	×3	×4	×6
外部輸出	×4	×5	×7
外部查詢	×3	×4	×6
外部接口文件	×5	×7	×10
內部邏輯文件	×7	×10	×15

4. 計算項目中14個技術復雜度因子（TCF）。取值范圍是0~5：TCF=0.65+0.01×∑Fi

5. 計算調整功能點：FP = 功能點總數UFC×調整系數TCF

5.6.3 簡述用例點估算法的計算流程

答：

完整計算流程總結：

1. UAW = Σ(角色數量 × 角色權重)（1-3）
2. UUCW = Σ(用例數量 × 用例權重)
3. UUCP = UAW + UUCW
4. TCF = 0.6 + (0.01 × Σ(Ti × Wi))（0-5分）
5. EF = 1.4 + (-0.03 × Σ(Ei × Wi))（0-5分）
6. UCP = UUCP × TCF × EF
7. 工作量 = UCP × 生產率因子

---

1. 計算未調整的角色權值 (UAW)

• 公式： UAW = Σ(角色數量 × 對應權重)
• 角色權重分類：
  • 簡單角色：權重 = 1（通過API交互）
  • 一般角色：權重 = 2（通過協議交互，如TCP/IP、FTP、HTTP等）
  • 復雜角色：權重 = 3（通過圖形用戶界面交互）

2. 計算未調整的用例權值 (UUCW)

   • 公式： UUCW = Σ(用例數量 × 對應權重)
   • 用例權重分類：
     • 簡單用例：權重 = 5（≤3個事務）
     • 一般用例：權重 = 10（4-7個事務）
     • 復雜用例：權重 = 15（≥8個事務）

3. 計算未調整的用例點 (UUCP)

   • 公式：* UUCP = UAW + UUCW

4. 計算技術復雜度因子 (TCF) 和環境因子 (EF)

   • 技術復雜度因子 (TCF)

     • 公式： TCF = 0.6 + (0.01 × TFactor）

     • 其中：TFactor = Σ(Ti × Wi)

       • Ti：第i個技術因子的評分值（0-5分）
       • Wi：第i個技術因子的權重

     • 環境因子 (EF)

       • 公式： EF = 1.4 + (-0.03 × EFactor)

       • 其中：EFactor = Σ(Ei × Wi)

         • Ei：第i個環境因子的評分值（0-5分）

         • Wi：第i個環境因子的權重

5. 計算調整的用例點 (UCP)

   • 公式： UCP = UUCP × TCF × EF

6. 計算工作量 (Man-hours)

   • 公式： 工作量 = UCP × 生產率因子

• 生產率因子確定：

  • 項目簡單：每用例點 = 20人時

  • 項目一般：每用例點 = 28人時

  • 項目復雜：每用例點 = 36人時

5.6.4 類比估算法

答：

1. 是一種自上而下的估算形式

2. 估算人員根據以往的完成類似項目所消耗的總成本（或工作量）， 來推算將要開發的軟件的總成本（或工作量），然后按比例將它分配到各個開發任務單元中

3. 自上而下的估算，又稱類比估算，通常在項目的初期或信息不足時進行，此時只確定了初步的工作分解結構，分解層次少，估算精度較差。

4. 類比估算中，需要評價不同項目間的相似程度。

   • 不加權的歐氏距離
   • 加權的歐氏距離

$$
distance(P_i, P_j) = \sqrt{\frac{\sum_{k=1}^{n} \delta(P_{ik}, P_{jk})}{n}}

\delta(P_{ik}, P_{jk}) = \begin{cases}
\left(\frac{|P_{ik} - P_{jk}|}{\max_k - \min_k}\right)^2, & k \text{是連續的} \
0, & k \text{是分散的且} P_{ik} = P_{jk} \
1, & k \text{是分散的且} P_{ik} \neq P_{jk}
\end{cases}
$$

5. 由于相似度計算比較麻煩，類比估算基本上采用主觀推斷 ，很少采用相似度計算方法。

5.6. 5 自下而上估算法

答：

1. 通常是在項目開始以后，或者WBS已經確定的項目，需要進行準確估算的時候釆用。

   • 優點：準確度較好

   • 缺點：需要花費一定的時間 ，估算本身也需要成本支持 ， 可能發生虛報現象

5.6.6 三點估算法

答：

1. 考慮項目的不確定性與風險
   • 3種估算值：最可能成本（CM）、最樂觀成本（CO）、最悲觀成本（CP）
   • 三角分布：預期成本CE=(CO+CM+CP)/3
   • 貝塔分布：預期成本CE=(CO+4CM+CP)/6

5.6.7 介紹下參數估算法

答：

1. 也稱為算法模型或經驗導出模型，是一種使用項目特性參數建立數學模型來估算成本的方法，是通過大量的項目數據進行數學分析導出的模型，是一種統計技術

2. 找到軟件工作量的各種成本影響因子，并判定它對工作量所產生影響的程度是可加的、乘數的還是****指數的，以期得到最佳的模型算法表達形式

   • 當某個因子只影響系統的局部時，一般認為它是可加的
   • 當某個因子對整個系統具有全局性的影響時，則認為它是乘數的或指數的

3. 模型分類：

   • 基于回歸分析的模型
     • 靜態單變量模型
     • 動態多變量模型
   • 基于神經網絡的模型

4. 使用條件

   • 具有良好的項目數據為基礎
   • 存在成熟的項目估算模型

5. 特點

   • 比較簡單,而且也比較準確
   • 如果模型選擇不當或者數據不準,也會導致偏差

5.6.7.1 什么是靜態單變量模型？

答：

靜態單變量模型 的整體公式: E=a+b*S^C

• E:以人月表示的工作量

• a,b,c:經驗導出的系數

• S:主要的輸入參數(通常是LOC,FP等)

5.6.7.2 下COCOMO 81 模型

答：

1. COCOMO 81（Constructive Cost Model 1981）是Barry Boehm在1981年提出的軟件成本估算模型，是最著名的軟件工作量估算模型之一。

2. 模型等級:COCOMO 81有3個等級的模型，級別越高，模型的參數約束越多：

   • 基本COCOMO - 相關信息極少情況下使用
   • 中等COCOMO - 需求確定之后使用
   • 高級COCOMO - 設計完成后使用

3. 項目模式（類型）:COCOMO 81根據項目特征將軟件項目分為三種模式：

   • 有機模式（Organic） - 小型項目，團隊經驗豐富，需求相對穩定

   • 嵌入式模式（Embedded） - 復雜的硬件/軟件系統，嚴格約束條件

   • 半有機模式（Semidetached） - 介于有機和嵌入式之間的中等規模項目

4. 核心公式

$$PM=A\times S^E\times \prod _{i=1}^n(E{M}_i)$$

$$\text{Effort}=a\times {\text{KLOC}}^b\times F$$

$$\text{其中：}\begin{array}{rl}& \text{PM/Effort：項目工作量（人月）}\\ & \text{A/a：規模因子常數}\\ & \text{S/KLOC：軟件規模（千行代碼）}\\ & \text{E/b：規模指數}\\ & {\text{EM}}_i\text{：第}i\text{個工作量乘數因子}\\ & \text{F：調整因子}\end{array}\text{\hspace{1em}?}$$

5. 參數取值：

   • 調整因子F的取值：取決于建模等級以及目標模式。由專家決定。基于數據庫的項目要求

   • 參數值（a、b），取決于建模等級以及目標模式，通過歷史數據統計得出，用于準確估算軟件開發工作量。

5.6.8 下專家估算法

答：

1. 專家估算法是由一些被認為是該任務專家的人來進行的
2. 一個專家可能會有偏見，最好由多位專家進行估算，取得多個估算值，最后得出綜合的估算值 ，因此引入Delphi專家估算法
   • 每位專家根據軟件系統規格說明書進行估算**（保證專家不見面）**
   • 協調員整理專家估算，給出平均期望值（三角分布/貝塔分布）
   • 在此基礎上各位專家進行再次估算
   • 以上過程可重復多次，直到專家評估值之差達到要

5.7 什么是項目成本預算？

答：

1. 成本預算是將項目的總成本按照項目的進度分攤到各個工作單元中去
2. 成本預算的目的是產生成本基線，作為度量項目成本性能的基礎

5.8 什么是成本基線？

答：

1. 成本基線是每個時間階段內的成本.
2. 是項目管理者度量或監控項目的依據。

6. 項目進度計劃

6.1 什么是進度？進度計劃為什么重要？

答：

1. 進度是對執行的活動和里程碑制定的工作計劃日期表
2. 重要性：
   • 按時完成項目是項目經理最大的挑戰
   • 時間是項目規劃中靈活性最小的因素
   • 進度問題是項目沖突的主要原因

6.2 如何制定出進度計劃？

答：

1. 根據WBS分解出主要的任務（活動）；
   • 任務是對WBS工作包的進一步細分。
2. 確立任務（活動）之間的關聯關系；
3. 然后估計每個任務（活動）需要的資源、時間；
4. 最后編制出項目的進度計劃。

6.3 任務之間的關系有哪幾種？如何確定關系？

答：

1. 前置活動（任務）—〉后置活動（任務）

2. 確定任務（活動）之間關聯關系的依據：

   • 硬邏輯關系 （強制性依賴關系）：客觀的不可違背的
   • 軟邏輯關系 ：人為的，主觀的
   • 外部依賴關系：項目活動與非項目活動之間

6.4 進度管理有哪幾種圖示方法？

答：

1. 網絡圖 network diagramming
   • 節點法/單代號網絡圖 PDM （Precedence Diagramming Method）
   • 箭線法/雙代號網絡圖 ADM （Arrow Diagramming Method）
2. 甘特圖 Gantt
   • 棒狀甘特圖
   • 三角形甘特圖
3. 里程碑圖
4. 資源圖
5. 燃盡圖/燃起圖

6.5 介紹進度管理幾種圖示方法。

答：

6.5.1 網絡圖

網絡圖是活動排序的一個輸出，展示項目中各個活動以及活動之間的邏輯關系

1. PDM：

   

2. ADM

6.5.2 甘特圖

顯示基本的任務信息，可以查看任務的工期、開始時間和結束時間以及資源的信息。只有時標，沒有活動的邏輯關系

6.5.3 里程碑圖

6.5 4 資源圖

6.5.5 燃盡圖/燃起圖

在項目完成之前，燃盡圖是對待完成的工作的可視化表示，燃起圖是對已完成的工作的可視化表示。

對比維度	燃盡圖（Burn Down Chart）	燃起圖（Burn Up Chart）
展示內容	僅展示從項目開始到終點的剩余工作量的減少	展示完成工作量以及項目總工作量的時間變化
圖形特征	理想情況下是向下的曲線，隨著剩余工作完成，燒盡至零	通過兩條線（完成工作量線和總工作量線）展示進度與目標
目標明確性	目標相對隱含，主要關注剩余工作量	目標非常明確，總工作量線清晰顯示項目目標
范圍變化處理	不直接顯示范圍變化，如果增加任務，剩余工作量會突然增加，可能使讀者難以理解原因	能夠清晰表現項目范圍變化，總工作量線會隨著變更而調整
范圍變更影響	范圍發生變化時需要重新繪制圖表	項目范圍變化時，總工作量線會上升或下降，直觀反映范圍變動
工作量增加顯示	不直接顯示工作量的增加	通過總工作量線的變化直觀顯示工作量增減

6.6 介紹幾種任務歷時估計的方法

答：

1. 定額估算法：適合規模較小的項目。

   • T=Q/(R*S）T活動歷時，Q任務規模，R人力數量，S工作效率

2. 經驗導出模型

   • D=a*E^b,D:進度(以月單位) E:工作量(以人月單位) a:2-4之間 b:1/3左右

3. PERT(工程評估評審技術)

4. 專家判斷法

5. 類比估計法

6. 基于承諾的進度估計

7. Jones的一階估算準則

   • 基于估算項目功能點,從冪次表中選擇合適的冪次將功能點升冪
   • ，一個商業軟件的功能點FP=350，若一個平均水平的軟件公司來承擔，粗略的進度估算為 350^0.43=12月

8. 預留分析

9. 敏捷歷時估算

6.6.1 PERT技術

答：于1958年，為適應大型工程的需要，并取得不錯效果

1. 利用網絡順序圖的邏輯關系和加權算法估算任務歷時
2. 它是基于對某項任務的樂觀，悲觀以及最可能的概率時間估計

$$\begin{gathered} 貝塔分布方差近似值PERT歷時=(O+4m+P)/6（貝塔分布） \\ 貝塔分布方差近似值：{\sigma }^2={\left(\frac{P?O}{6}\right)}^2 \end{gathered}$$

活動項	O,M,P	PERT估計值	δ	δ2
A	2,3,6	3.33	4/6	16/36
B	4,6,8	6	4/6	16/36
C	3,4,6	4.17	3/6	9/36
估計項目總歷時	—	13.5	1.07	41/36

$$\begin{gathered} E=E_A+E_B+E_C \\ {\delta }^2={\delta }_A^2+{\delta }_B^2+{\delta }_C^2 \\ \delta =\sqrt{{\delta }_A^2+{\delta }_B^2+{\delta }_C^2} \end{gathered}$$

6.6.2 預留分析

答：

1. 在進行持續時間估算時，需考慮應急儲備(有時稱為“進度儲備”), 以應對進度方面的不確定性。

2. 應急儲備是包含在進度基準中的一段持續時間，用來應對已經接受 的已識別風險。應急儲備可取活動持續時間估算值的**某一百分比( 如10%～15%)**或某一固定的時間段。

3. 預留的應急儲備應該是將每一項任務的預留時間累加在一起放在關鍵路徑末端，而不要增加每一項任務時間，即把應急儲備從各個活動中剝離出來并匯總

6.6.3 敏捷歷時估算

答：

1. 在敏捷項目中，團隊的估算最多限于未來幾周時間。
2. 敏捷歷時估算可以分為：開發速度穩定前和開發速度穩定后兩種

• 開發速度穩定前，可以采用決策技術，如舉手表決。
• 開發速度穩定后：
  * 團隊通過觀察歷史表現來更準確地規劃下階段的能力，可能需要4 ～8個迭代才能達到穩定的速度。

6.7 什么是任務進度計劃編制？有什么基本方法？

答：

1. 進度計劃編制是決定項目開始和結束日期的活動
   • 主要目的：是控制和節約項目的時間，保證項目在規定的時間內能夠完成
   • 最終目標：建立一個現實的項目進度計劃，為監控項目的進度進展提供一個基礎。
2. 基本方法有
   • 關鍵路徑法 CPM Critical Path Method 正推法/逆推法
   • 時間壓縮法 應急法/平行作業法
   • 資源優化 資源平衡方法/資源平滑
   • 敏捷項目進度編排

6.7.1 如何使用關鍵路徑法？

答：

1. 計算每一個活動的單一的、確定的最早和最遲開始和完成日期；

2. 計算網絡圖中最長的路徑。以便確定項目完成時間估計。

6.7.1.1項目進度管理時間參數對照表

中文名稱	英文名稱	簡稱	定義/說明
最早開始時間	Early Start	ES	任務最早可以開始的時間
最晚開始時間	Late Start	LS	任務最晚必須開始的時間（不影響項目完成）
最早完成時間	Early Finish	EF	任務最早可以完成的時間
最晚完成時間	Late Finish	LF	任務最晚必須完成的時間（不影響項目完成）
超前	Lead	—	兩個任務的邏輯關系所允許的提前后置任務的時間
滯后	Lag	—	兩個任務的邏輯關系所允許的推遲后置任務的時間
浮動	Float	—	任務的機動性，在不影響項目完成情況下可推遲的時間量
自由浮動	Free Float	FF	在不影響后置任務最早開始時間，本任務可延遲的時間
總浮動	Total Float	TF	在不影響項目最早完成時間，本任務可延遲的時間

$$
FF = ES_{\text{后置任務}} - EF - \text{lag}\

TF = LS - ES \quad \text{或} \quad TF = LF - EF
$$

• 關鍵路徑上的任務總浮動為0
• 自由浮動≤總浮動，任務的自由浮動永遠不會超過其總浮動
• Lead/Lag主要用于調整任務間的邏輯關系時間依賴

6.7.2 介紹下時間壓縮法

答：

1. 時間壓縮法是在不改變項目范圍的前提下縮短項目工期的方法，是一種數學分析方法
2. 分為：
   • 應急法——趕工（crash）
     • 時間成本平衡方法（進度壓縮單位成本方）
     • 進度壓縮因子方法
   • 平行作業法——快速跟進（Fast Tracking）

6.7.2.1 介紹下時間成本平衡方法（進度壓縮單位成本方法)

答：

時間成本平衡方法是項目管理中通過增加成本來壓縮項目進度的技術，核心是找到成本增加與時間節省之間的最優平衡點。

6.7.2.1.1基本假設

序號	假設條件
1	每個任務存在正常進度和可壓縮進度、正常成本和可壓縮成本
2	通過增加資源，每個任務的歷時可以從正常進度壓縮到可壓縮進度
3	每個任務無法在低于可壓縮進度內完成
4	有足夠需要的資源可以利用
5	在"正常"與"可壓縮"之間，進度壓縮與成本增長成正比

$$\text{單位壓縮成本}=\frac{\text{可壓縮成本}?\text{正常成本}}{\text{正常進度}?\text{可壓縮進度}}$$

參數類型	時間	成本
正常情況	正常進度（較長）	正常成本（較低）
壓縮情況	可壓縮進度（較短）	可壓縮成本（較高）

決策原則

• 成本效益最大化：選擇單位壓縮成本最低的活動進行壓縮

• 關鍵路徑優先：只有關鍵路徑上的活動壓縮才能縮短項目總工期

• 資源約束考慮：在資源允許范圍內進行壓縮

6.7.2.2 簡要介紹下進度壓縮因子法

答：

1. 通過計算進度壓縮因子來估算壓縮進度后的工作量增加，實現時間與成本的量化權衡。

$$\begin{gathered} \text{進度壓縮因子}=\frac{\text{壓縮進度}}{\text{正常進度}} \\ \text{壓縮后工作量}=\frac{\text{正常工作量}}{\text{進度壓縮因子}} \end{gathered}$$

典型結果

• 進度縮短17% → 工作量增加21%
• 體現了進度壓縮的非線性成本增長特性

安全限制

• 進度壓縮因子 ≥ 0.75
• 最多壓縮25%進度
• 超出此范圍項目風險急劇增加

6.7.2.3 對比一下時間壓縮方法中的應急法和平行作業

對比維度	應急法（趕工法）	平行作業法（快速跟進法）
基本原理	通過增加資源，以最小成本代價壓縮進度工期	將正常情況下按順序進行的活動改為至少部分并行開展
邏輯關系	不改變活動間的邏輯關系	可改變活動間的邏輯關系
實施方式	增加資源投入（人力、設備、資金等）	并行開展某些活動，使用提前量
適用條件	? 位于關鍵路徑上的活動 ? 通過增加資源就能縮短持續時間的活動	? 原本按順序進行的活動或階段 ? 可以部分并行開展的工作
主要風險	? 可能導致風險或成本增加 ? 并非總是切實可行	? 常導致返工 ? 增加項目風險 ? 增加質量風險
成本影響	直接增加資源成本，但以最小成本為目標	可能增加項目成本（返工、協調、質量問題）
協調復雜度	相對簡單，主要是資源管理	增加相關活動間的協調工作
技術可行性	取決于活動特性，有些活動無法通過增加資源縮短	需要仔細分析活動依賴關系的可調整性
典型應用	增加加班時間、增加工作人員、使用更快設備	設計與采購并行、測試與開發重疊

選擇建議

• 優先考慮應急法：當關鍵路徑活動可通過增加資源縮短且成本可控時
• 謹慎使用平行作業法：當應急法不可行且能承受返工和質量風險時
• 組合使用：在復雜項目中可能需要兩種方法配合使用

6.7.3 資源平滑方法。

資源平衡法是一種資源優化技術，通過調整活動的開始日期和完成日期，使計劃使用的資源等于或少于可用資源，在資源需求與資源供給之間取得平衡。

主要目標	具體說明
形成平穩連續的資源需求	避免資源需求的劇烈波動
最有效利用資源	提高資源使用效率
最小化資源閑置時間	減少資源浪費
避免超出資源能力	防止資源過度分配

1. 適用場景

   • 需要進行資源平衡的情況：

     • 共享資源或關鍵資源只在特定時間可用

     • 資源數量有限

     • 資源被過度分配（同一資源在同一時段被分配至兩個或多個活動）

2. 實施方法

   • 根據資源制約因素對開始日期和完成日期進行調整，通過調整任務時間來協調資源沖突。

3. 重要特點

   • 對項目的影響：

     • 資源平衡往往導致關鍵路徑改變
     • 可在資源有約束的條件下制定可行的進度計劃

   • 資源優化方法分類

     • 資源平衡：調整時間以匹配可用資源

     • 資源平滑：在不改變關鍵路徑的前提下優化資源使用

   • 核心價值

     • 在項目編排中進行資源的優化配置，保證資源最優化、最有效，實現可執行的項目進度計劃。
       | 并行開展某些活動，使用提前量 |
       | 適用條件 | ? 位于關鍵路徑上的活動
       ? 通過增加資源就能縮短持續時間的活動 | ? 原本按順序進行的活動或階段
       ? 可以部分并行開展的工作 |
       | 主要風險 | ? 可能導致風險或成本增加
       ? 并非總是切實可行 | ? 常導致返工
       ? 增加項目風險
       ? 增加質量風險 |
       | 成本影響 | 直接增加資源成本，但以最小成本為目標 | 可能增加項目成本（返工、協調、質量問題） |
       | 協調復雜度 | 相對簡單，主要是資源管理 | 增加相關活動間的協調工作 |
       | 技術可行性 | 取決于活動特性，有些活動無法通過增加資源縮短 | 需要仔細分析活動依賴關系的可調整性 |
       | 典型應用 | 增加加班時間、增加工作人員、使用更快設備 | 設計與采購并行、測試與開發重疊 |

選擇建議

• 優先考慮應急法：當關鍵路徑活動可通過增加資源縮短且成本可控時
• 謹慎使用平行作業法：當應急法不可行且能承受返工和質量風險時
• 組合使用：在復雜項目中可能需要兩種方法配合使用

6.7.3 資源平滑方法。

資源平衡法是一種資源優化技術，通過調整活動的開始日期和完成日期，使計劃使用的資源等于或少于可用資源，在資源需求與資源供給之間取得平衡。

主要目標	具體說明
形成平穩連續的資源需求	避免資源需求的劇烈波動
最有效利用資源	提高資源使用效率
最小化資源閑置時間	減少資源浪費
避免超出資源能力	防止資源過度分配

1. 適用場景

   • 需要進行資源平衡的情況：

     • 共享資源或關鍵資源只在特定時間可用

     • 資源數量有限

     • 資源被過度分配（同一資源在同一時段被分配至兩個或多個活動）

2. 實施方法

   • 根據資源制約因素對開始日期和完成日期進行調整，通過調整任務時間來協調資源沖突。

3. 重要特點

   • 對項目的影響：

     • 資源平衡往往導致關鍵路徑改變
     • 可在資源有約束的條件下制定可行的進度計劃

   • 資源優化方法分類

     • 資源平衡：調整時間以匹配可用資源

     • 資源平滑：在不改變關鍵路徑的前提下優化資源使用

   • 核心價值

     • 在項目編排中進行資源的優化配置，保證資源最優化、最有效，實現可執行的項目進度計劃。