上次講完了專案初始部分，包括立項、招投標、授權

在進入第二部分，專案計劃

前我們要先了解軟體的需求以及任務的分解

軟體需求管理

軟體需求定義：使用者對軟體功能和效能的要求

軟體需求管理過程：需求獲取、需求分析、需求規格編寫、需求驗證、需求變更

變更管理：確定需求變更控制過程、確立變更控制委員會（SCCB）、進行需求變更影響分析、跟蹤所有受需求變更影響的工作產品、建立需求基準版本和需求控制版本文件、維護需求變更的歷史記錄、跟蹤每項需求的狀態、衡量需求穩定性

軟體建模的基本方法：

原型方法：需求分析、原型開發、原型評價

結構化分析法 ：面向資料流的方法、自頂向下的分析方法、根據軟體內部資料傳遞、交換的關係進行分析的，包括的技術有資料流圖、資料字典、系統流程圖

面向物件的用例分析：基於面向物件的情景分析方法、從使用者角度出發考慮的功能需求、用例是系統向用戶提供一個有價值的結果的某項功能

uml需求檢視：用例檢視、順序圖、狀態圖、活動圖

功能列表法：將需求各功能以列表的形式列出，可以配合用例分析方法，對用例進行展開描述。

敏捷方法：對需求採用漸進明晰的方法進行描述

在敏捷方法中，使用者需求被描述成一個個story card，有以下基本格式：as  a <type of  user>，i want <some goal>,so that <some reason>

判斷一個user story 是否是一個好的story的標準

軟體專案任務分解

任務分解是專案管理的基礎

任務分解過程定義：將一個專案分解為更多的工作細目或子專案，使專案變得更小、更易管理、更易操作

WBS任務分解結構：wbs是對專案由粗到細的分解過程，面向交付成果的，wbs組織並定義了整個專案範圍

工作包是wbs最低層次的可交付成果

工作包應當由唯一主體負責

任務分解方法：

類比：有相同或相似的週期的專案，可採用類比的方法

模板參照：進行專案分解的時候，有些專案可以參照模板

自上而下：對專案整體有比較詳細的瞭解

自下而上：任務沒有非常詳細的邏輯關係，想到什麼寫什麼，然後按一定邏輯生成

任務分解步驟：

確認並分解專案的組成要素(WBS編號)
確定分解標準
確定分解是否詳細
確定專案交付成果（可以編制WBS字典）
驗證分解的正確性

檢驗分解結果的標準：

最底層的要素是否是實現目標的充分必要條件
最底層要素是否有重複的
每個要素是否清晰完整定義
最底層要素是否有定義清晰的責任人
是否可以進行成本估算和進度安排