專案+/計劃
< Project+
需求分析是專案中仔細定義專案需求的階段。需求是記錄的需求或對系統必須完成的任務的描述。它是標識專案產品所需屬性、功能、特性或質量的宣告。
專案的物質結果是其產品。產品可以是服務、事件或物質物體。它包括可交付成果的所有必要方面，包括培訓、文件等。需求側重於產品本身，而不是實現產品的途徑，將實施細節留待以後。那些側重於產品實現方式的需求被稱為有實現偏差。
需求說明書是對專案目標的詳細說明。它描述了產品的特性、功能和效能約束。它提供了接受產品的依據，或描述了為接受產品必須完成的任務。
以下是一些瞭解使用者需求的有用技術
- 原型設計
- 試點
- 用例建模
- 描述軟體產品與其環境之間的關係
- JAD（聯合應用設計）
- UML（統一建模語言）
- 面向物件軟體設計的管理工具
專案說明書和專案需求用於識別
- 專案對贊助人和使用者的高階價值
- 與專案範圍相比，需求中的差距
- 需求清單是否完整且有效，足以進入下一階段
- 所有系統輸入都已定義
- 所有系統輸出都已定義
- 需求已與贊助商和使用者進行驗證
- 已定義業務規則、特殊邏輯和計算
- 已識別並填補需求與範圍之間的差距
- 必要的輸入範圍
- 經過仔細評估，確保在專案範圍內
- 完整、準確和有效
- 業務
- 功能
- 技術
- 將需求追蹤到已記錄的需求
- 確保專案產品的描述正確完整
- 記錄物理和功能設計特性
- 專案計劃將包含範圍說明
- 專案的範圍通常在專案啟動階段定義，但隨著更多分析的進行，範圍可以根據需要進行調整
- 分層任務列表
- 將專案分解成多個工作單元
- 用於確定專案工作量
- 計劃、進度、預算的基礎
- 用於估計資源需求、活動持續時間和成本
- 建立甘特圖所需
- 將包含在專案計劃說明中
- 階段 = WBS 中的最高層級元素
- 工作包 = WBS 中的最低層級元素
- 每項工作由一人負責，儘管許多人可能參與該項工作
- 每個可交付成果應獲得正式批准
- 簽署授權應明確定義
- 表示為
- 樹形圖（或層次結構圖）
- 以提綱形式列出，詳細條目從屬上層條目。
- WBS 中包含進度和預算嗎？
- 可以是任何大小（專案是一個非常大的活動或任務）
- 有時這兩個術語是同義詞
- 有時這兩個術語用於表示 WBS 中特定層級的部分工作
- 例如，階段被分解成活動，活動被分解成任務
- 在每個活動或任務中定義
- 持續時間
- 成本
- 資源
- 可交付成果
- 具體
- 可衡量
- 可分配
- 現實
- 有時限
- WBS 中的最高層級元素
- 專案中活動的集合
- 透過提供重要的可交付成果來實現主要里程碑
- 例如，需求定義或產品設計文件
- 為了控制目的，專案被分解成一組階段
- 階段通常是專案在 WBS 中的最高級別分解。
- WBS 中進行專案會計的最低層級
- 通常持續一週左右，由個人或小型工作組執行
- "任務" 或 "工作單元" 或 "活動" = 都含糊不清
- 任務可以是高層級、中層級或低層級，即摘要任務、子任務
- 工作包是進行會計的最低層級 - 不含糊不清
- 儘可能縮短工作單元的持續時間
- 工作團隊應規模小
- 1.0 主要任務 1
- 1.1 子任務 1
- 1.2. 子任務 2
- 2.0 主要任務 2
- 3.0 主要任務 3
- 作為專案或專案任何部分的結果而產生的任何專案
- 專案可交付成果與階段性可交付成果不同
- 階段性可交付成果是專案內部活動的結果
- 可交付成果必須是有形的且可驗證的
- WBS 的每個元素（活動或任務）必須包含一個或多個可交付成果。
- 合同工
- 外包
- 主要提出開放式問題
- 制定面試問題
- 制定一個機制來對答覆進行評分
- 制定一份全面的職位說明
- 確定該職位所需的技能、知識和態度
- 積極主動、團隊合作的態度
- 目標導向、能幹的處事風格
- 熟悉系統和使用者文件
- 對專案任務實際持續時間影響最大
- 對估計的每單位人工成本影響最大
- 估算專案或階段的努力/成本/持續時間/風險
- 將專案作為一個整體看待
- 將專案與以前執行的類似專案進行比較
- 比較方法
- 類比估算
- 直接比較
- 引數估算
- 使用演算法
- 專家
- 從記憶中估算
- 估算專案或階段的努力/成本/持續時間/風險
- 在專案初期進行，以獲得一個初步估計
- 與自上而下方法大致相同。
- 估算專案或階段的努力/成本/持續時間
- 使用演算法
- 代表專案屬性的引數，用於計算
- 在自上而下估算中使用。
- 估算專案或階段的努力/成本/持續時間/風險
- 使用類似的專案或活動作為基礎進行估算
- 在自上而下估算中使用
- 估算專案或階段的努力/成本/持續時間
- 分解為活動、任務和子任務
- 估算每個任務和子任務的努力、持續時間和成本
- 將所有組成部分的估算結果彙總起來，以確定最終估算結果
- 透過自下而上方法確定持續時間需要
- 將排序和資源均衡作為計劃過程的一部分進行。
- 範圍
- 任務要求
- 資源可用性
- 資源費用
- 原始估算與實際結果的比較
- 估算每個工作單元的時間和資源
- 歷史資料
- 專家判斷
- 確定工作單元之間的依賴關係
- 均衡資源
- 為每個工作單元建立清單
- 理解工作單元之間的依賴關係
- FF、SS、FS、SF
- 可交付成果
- 專案任務
- 所需技能
- 可用技能
- 每個任務的時間和資源
- 專案的關鍵路徑
- 採取的行動
- 具有時間要求的任務
- 計劃過程的一部分
- 基於任務之間的依賴關係，將任務按順序或並行排列
- 排序結果形成一個任務網路。
- 強制性
- 工作性質所固有
- 通常涉及物理限制
- 硬邏輯
- 可選擇的
- 由專案管理團隊定義
- 軟邏輯
- 外部的
- 專案和非專案活動之間的關係
- 可交付成果或一組可交付成果可用的時間點
- 表示重大事件，例如階段的完成
- SMART 標準 = 具體、可衡量、可分配、現實、有時限
- 在甘特圖中用黑色菱形表示
- 在跟蹤甘特圖中，滑動的里程碑用白色菱形表示
- 一個事件：沒有持續時間或努力
- 必須由一個或多個任務提前
- 即使是專案的開始也由一組任務提前，可能隱含
- 專案網路中持續時間最長的路徑
- 決定專案最早完成時間的一系列活動
- 可能存在多個關鍵路徑
- 關鍵路徑可能會在專案期間發生變化。
- 任務在延遲專案結束日期之前可以滑動的可用時間量
- 它是任務的早開始日期和晚開始日期之間的差值。
- 活動開始與重疊活動開始之間的最短時間間隔
- 兩個任務之間的等待時間
- 條形圖，描述了活動和里程碑的進度表
- 活動列在圖表左側
- 時間線列在圖表頂部或底部
- 活動顯示為水平條
- 活動條的長度等同於活動的持續時間
- 可以標註依賴關係和其他與進度相關的的資訊。
- 用於描述任務順序和關係的圖形工具
- 網路圖的形式
- PERT 圖
- 關鍵路徑圖
- 箭頭圖
- 優先順序圖
- 使用以下方法的排程技術
- 依賴關係分析和關鍵路徑來確定專案的持續時間
- 鬆弛來確定任務的優先順序
- 任務持續時間計算為（樂觀估計 + 4x 最有可能估計 + 悲觀估計）/ 6）
- 專案時間線
- 確定以下日期（絕對日期或相對於開始日期）：
- 專案任務將開始和完成
- 將需要資源
- 將達到里程碑。
- 基於任務之間的依賴關係，將任務按順序或並行排列
- 排序結果形成一個任務網路。
- 確定每個工作單元的資源成本
- 確定何時需要這些資源
- 應獲得專案發起人的書面批准
- 確認客戶的預期成本
- 在建立詳細（自下而上）預算時進行驗證
- 需要預算和進度來制定
- 顯示每個工作單元的預算將在何時花費
- 預算現金流的依據
- PV（BCWS）和EV（BCWP）的依據（新術語？）
- 用於專案生命週期內發生的由於 - 通貨膨脹 - 導致的價格變化的資金？
- 在時間上分配成本估算
- 成本預算的四個輸入
- 成本估算
- WBS
- 專案進度
- 風險管理計劃
- 成本預算的一個輸出
- 成本基線
- 分時預算
- 成本基線
- 薪酬
- 福利
- 加班
- 等等
- 在客戶面前不應有任何爭論
- 顧問在現場時不應討論其他客戶
- 目的
- 傳送方
- 接收方
- 頻率
- 型別
- 方法
- 描述
- 主要系統功能
- 使用者參與需求
- 主要可交付成果計劃交付時間
- 為效能和可靠性建立操作定義
- 為專案績效提供質量保證措施
- 提供對專案績效/文件的獨立評估
- 單元測試
- 元件級別
- 整合測試
- 功能分組元件
- 系統測試
- 將整個系統作為一個實體
- 使用者驗收測試
- 應證明系統按規定的要求執行。
- 驗證
- alpha 測試
- 模擬環境和模擬資料
- 驗證
- beta 測試
- 真實環境和真實資料
- 審計測試
- 證明系統已準備好投入執行
- 確保標準和程式有效且得到遵守
- 在某些組織中，QA 用於指代質量控制功能
- 滿足標準
- 促進持續改進
- 確保交付成果符合驗收標準
- 包括測試和審查。
- 事件發生的可能性
- 通常，事件是負面的，例如專案失敗
- 事件也可能是正面的，例如任務提前完成
- 機會成本
- 技術風險
- 進度風險
- 計劃評審技術 (PERT)
- 蒙特卡洛
- 財務風險
- 接受
- 避免
- 減輕
- 評估已識別風險的可能性和影響
- 歷史資訊
- 產品和專案的性質
- 資訊收集
- 風險管理的一部分
- 規劃人員識別潛在風險並進行描述
- 風險通常以以下方面識別
- 症狀
- 原因
- 發生的機率
- 潛在影響
- 可以採取的行動，以解決風險事件的發生
- 應急計劃是風險應對的集合
- 在整個專案生命週期中應對風險事件的發生
- 採取糾正措施是風險應對控制的一個方面
- 風險管理的一部分
- 規劃人員識別並定義在風險發生時要採取的行動
- 這種風險可能是積極的或消極的
- 風險管理規劃
- 風險識別
- 定性風險分析
- 定量風險分析
- 風險應對規劃
- 風險監控和控制
- 其他檔案，例如 WBS 和 SOW，被輸入到專案計劃中
- 非常詳細，包含關於專案的所有資訊
- 一份活文件，因為其內容在專案生命週期內可能會發生變化
- 需要基線，所有變更都需要跟蹤
- 結束計劃階段
- 在計劃過程中請求利益相關者的意見
- 清晰地說明專案與公司目標的關係
- 專案範圍
- 專案定義
- 專案目標
- 專案範圍分析（包含和排除）
- 專案交付成果
- 專案假設
- 專案成功標準
- 專案需求
- 方法描述
- 專案方法
- 工作分解結構 (WBS)
- 專案估計
- 專案風險評估
- 專案資源（所需技能集等）
- (T) - 目錄
- (O) - 概述
- (S) - 贊助商
- (T) - 團隊成員
- (R)- 需求
- (S) - 計劃任務 (WBS)
- (E) - 預期資源
- (E) - 環境問題
- (B) - 業務需求
- (I) - 實施計劃
- (S) - 支援計劃
- (T) - 培訓計劃 - 九個知識領域，每個領域 = 報告，除了整合（啞巴 pmp）
- 整合
- 範圍
- 時間
- 成本
- 質量
- 人力資源
- 溝通
- 採購
- 風險
- 助記符：說唱歌手 Ice-T 尋求人力資源部門參加 CPR 課程
- Ice-T - IST - 整合、範圍、時間
- 尋求人力資源 - CQ HR - 成本、質量、人力資源
- CPR - 溝通、採購、風險
- 助記符：說唱歌手 Ice-T 尋求人力資源部門參加 CPR 課程
- 收集所有專案計劃要素
- 建立大綱或目錄
- 與主要利益相關者審查大綱
- 根據利益相關者的反饋調整計劃
- 編寫綜合專案計劃
- 獲得正式批准