「软件项目管理」软件项目范围计划——需求管理与任务分解
軟件項目范圍計劃——需求管理與任務分解
- 序言
- 一、軟件需求定義及層次
- 1、定義
- 2、層次
- 二、軟件需求管理過程
- 1、管理過程
- 2、需求獲取
- 3、需求分析
- 4、需求規格編寫
- 5、需求驗證
- 6、需求變更
- (1)需求變更管理的主要工作
- (2)需求變更控制流程
- 三、軟件需求分析方法
- 1、原型分析方法
- 2、結構化分析法(基于數據流建模)
- (1)定義
- (2)結構化分析方法的技術
- 3、面向對象的用例分析法(基于UML建模)
- (1)定義
- (2)UML需求視圖
- 4、功能列表
- (1)圖例
- (2)基于功能列表的實例
- 5、敏捷分析法
- 四、任務分解
- 1、任務分解定義
- (1)定義
- (2)WBS和工作包
- (3)WBS和工作包的區別
- 2、任務分解形式
- (1)圖表形式的WBS(組織結構圖式)
- (2)提綱式
- 3、任務分解過程
- (1)五大步驟
- (2)分解標準
- (3)分解標準舉例闡述
- (4)WBS字典
- 4、任務分解方法
- (1)模板參照
- (2)類比
- (3)自頂向下
- (4)自底向上
- 5、任務分解結果
- (1)檢驗分解結果標準
- (2)WBS任務分解建議
- 五、結束語
- 🛵專欄直通車
序言
在需求管理中,我們總會遇到各種各樣的問題。比如:①需求的隱含錯誤;②客戶不斷增加需求、變更需求;③……。往往這些需求就是導致我們項目失敗的根本原因?!?/p>
那接下來,我們先用一張圖來對項目失敗的原因進行分析。具體如下圖:
基于以上的原因分析,自然地,我們也就知道了軟件需求在軟件項目管理中不可撼動的地位。
那么在接下來的文章中,就來了解下軟件需求各方面的內容。
叮,開始學習吧~👏
一、軟件需求定義及層次
1、定義
指用戶對 軟件功能和性能 的要求。(用戶希望軟件能做什么事情,完成什么樣的功能,達到什么樣的性能)
2、層次
軟件需求的層次有以下三個方面的內容:
業務需求→用戶需求→功能需求
二、軟件需求管理過程
1、管理過程
軟件需求管理過程包含兩個方面的內容,分別是需求開發和需求管理。
需求開發的路徑是:需求獲取→需求分析→需求規格編寫→需求驗證;而需求管理指的是:需求變更。
下面我們將對以上這幾個概念進行一一解析。
2、需求獲取
首先我們要先分析用戶的要求,分析完成之后,那么我們就要去獲取這個用戶的要求,并讓軟件去實現它。隨之,軟件就得到了軟件需求。如下圖所示:
3、需求分析
需求分析是為最終用戶所看到的系統建立一個概念模型,是對需求的抽象描述。 如下圖所示:
4、需求規格編寫
需求分析工作完成的一個基本標志是形成了一份完整的、規范的需求規格說明書。
5、需求驗證
在確定了需求之后,我們需要進行以下驗證:
- 需求是正確的嗎?
- 需求是一致的嗎?
- 需求是完全的嗎?
- 需求是實際可行的嗎?
- 需求是必要的嗎?
- 需求是可檢驗的嗎?
- 需求是可跟蹤的嗎?
- 最后的簽字
6、需求變更
在軟件的某些周期,我們總會遇到需求變更的問題。那對于需求變更來說,主要需要了解以下內容。
(1)需求變更管理的主要工作
需求變更管理的主要工作有:
- 建立需求基線
- 確定需求變更控制過程
- 建立變更控制委員會 (SCCB)
- 進行需求變更影響分析
- 跟蹤所有受需求變更影響的工作產品
- 建立需求基準版本和需求控制版本文檔
- 維護需求變更的歷史記錄
- 跟蹤每項需求的狀態
- 衡量需求穩定性
(2)需求變更控制流程
需求變更的控制流程如下圖所示:
三、軟件需求分析方法
1、原型分析方法
原型分析方法需要經過三個步驟,分別是需求分析→原型方法→原型評價。如下圖所示:
2、結構化分析法(基于數據流建模)
(1)定義
- 20世紀70年發展起來的面向數據流的方法
- 是一種自頂向下逐步求精的分析方法
- 根據軟件內部數據傳遞、變換的關系進行分析的
(2)結構化分析方法的技術
- 數據流圖 (DFD)
- 數據字典 (DD)
- E-R 圖
- 系統流程圖
3、面向對象的用例分析法(基于UML建模)
(1)定義
- 基于面向對象的情景分析方法
- 從用戶角度出發考慮的功能需求
- 用例是系統向用戶提供一個有價值的結果的某項功能
(2)UML需求視圖
- 用例視圖 - Use case Diagram
- 順序圖 - Sequence Diagram
- 狀態圖 - State Diagram
- 活動圖 - Activity Diagram
4、功能列表
(1)圖例
功能列表法的圖例如下所示:
(2)基于功能列表的實例
現在,我們來看一個基于功能列表的實例。如下圖所示:
5、敏捷分析法
敏捷分析法包含以下三個部分,分別是:
-
用戶故事模板
As a<type of user>, I want<some goal>, So that<some reason>.用戶故事常常寫在卡片上,然后將其部署到墻上,便于討論。
-
評價用戶故事
-
用戶故事迭代優先級
第一組: ①must have;②should have;③could 第二組: have/want to have
四、任務分解
1、任務分解定義
(1)定義
- 任務分解指的是將一個項目分解為更多的工作細目或者子項目,使項目變得更小、更易管理、更易操作。
(2)WBS和工作包
- WBS ,即 Work Breakdown Structure ,表示任務分解結構。WBS 是任務分解的結果。
- 工作包,是 WBS 最低層次的可交付結果,是 WBS 的最小元素。
(3)WBS和工作包的區別
WBS 和工作包的區別如下:
- WBS 是對項目由粗到細的分解過程;
- WBS 是面向交互結果的;
- 同時,WBS 組織定義了整個項目范圍;
- 而工作包是 WBS 中最低層次的可交付成果(如下圖所示);
- 且工作包應當由唯一主體負責。
2、任務分解形式
任務分解主要有兩種形式,分別為:
- 圖表形式(組織機構圖式)
- 提綱式
(1)圖表形式的WBS(組織結構圖式)
如下圖所示:
(2)提綱式
類似于下方這樣:
1 變化計數器1.1 比較兩個版本的程序1.1.11.1.21.1.31.2 找出修改后的程序中增加和刪除的代碼行1.2.11.2.21.3 統計修改后的程序中增加和刪除的代碼行數1.3.11.3.23、任務分解過程
(1)五大步驟
任務分解的過程要經過三個過程,輸入→分解→ WBS 。有以下步驟:
-
確認并分解項目的主要組成要素
-
確認分解標準
-
確認分解是否詳細
-
確認項目交付成果(可以編寫 WBS 字典 )
-
驗證分解正確性
(2)分解標準
任務分解的過程有兩大標準,分別是:
- 分解標準應統一;
- 不能同時使用兩種標準進行分解。
(3)分解標準舉例闡述
第一種: 分解標準應統一
第二種: 不能同時使用兩種標準進行分解
(4)WBS字典
WBS 字典如下圖所示:
4、任務分解方法
任務分解有4種方法,分別是:
- 模板參照
- 類比
- 自頂向下
- 自底向上
(1)模板參照
如下圖所示:
(2)類比
- 有些項目在某種程度上具有相似性;
- 可以采用類似的 WBS 作為參考。
(3)自頂向下
如下圖所示:
(4)自底向上
如下圖所示:
5、任務分解結果
(1)檢驗分解結果標準
- 最底層要素是否是實現目標的充分必要條件;
- 最底層要素是否有重復的;
- 每個要素是否清晰完整定義;
- 最底層要素是否有定義清晰的責任人;
- 是否可以進行成本估算和進度安排。
(2)WBS任務分解建議
- 最低層是可控的和可管理的,但是不必要過細;
- 每個Work package 必須有一個提交物;
- 定義任務完成的標準;
- 有利于責任分配;
- 推薦任務分解到40小時以內。
五、結束語
上述文章中,我們講解了軟件項目范圍計劃中的需求管理和任務分解,從多個方面去剖析軟件需求分析。
到這里,本文的講解就結束啦!希望對大家有幫助~
🛵專欄直通車
軟件項目管理👉https://juejin.cn/column/7024826582841688077
總結
以上是生活随笔為你收集整理的「软件项目管理」软件项目范围计划——需求管理与任务分解的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 数领科技|主流BIM软件及公司介绍
- 下一篇: GBase8s