304.軟件項目管理--範圍計劃

1、軟件需求管理過程

核心三計劃:性能

範圍計劃\進度計劃\成本計劃(成本基準,進度基準)測試

軟件需求編碼

需求是指用戶對軟件的功能和性能的要求,就是用戶但願軟件能作什麼事情,完成什麼樣的功能,達到什麼性能。設計

軟件需求的層次3d

項目失敗的緣由分析blog

軟件需求管理的過程開發

需求獲取文檔

需求分析(功能數據行爲模型,建模)產品

編寫需求規格模板

需求驗證

需求工程基本任務

需求獲取

1568938796768

基線:經過評審的需求

需求分析定義

需求分析是爲最終用戶所看到的系統創建一個概念模型,是對需求的抽象描述。

需求分析模型

需求規格

  • 需求分析工做完成的一個基本標誌是造成了一份完整的、規範的需求規格說明書
  • 需求規格說明書的編制是爲了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解,使之成爲整個開發工做的基礎。

軟件需求規格說明的原則

  • 從現實中分離功能,即描述要「作什麼」而不是「怎樣實現」
  • 採用必定的規格說明語言
  • 若是被開發軟件只是一個大系統中的一個元素,那麼整個大系統也包括在規格說明的描述之中
  • 規格說明應該包括系統運行環境
  • 規格說明應該是一個認識模型
  • 規格說明應該允許不完備性並容許擴充

規格文檔參考

  1. 引言
  2. 系統定義
  3. 應用環境
  4. 功能規格
  5. 性能需求
  6. 產品提交
  7. 實現約束
  8. 質量描述
  9. 其它
  10. 簽字認證

需求驗證

  • 需求是正確的嗎?
  • 需求是一致的嗎?
  • 需求是徹底的嗎?
  • 需求是實際可行的嗎?
  • 需求是必要的嗎?
  • 需求是可檢驗的嗎?
  • 需求是可跟蹤的嗎?
  • 最後的簽字

需求總在變化

需求變動管理

  1. 肯定需求變動控制過程
  2. 創建變動控制委員會(SCCB)
  3. 進行需求變動影響分析
  4. 跟蹤全部受需求變動影響的工做產品
  5. 創建需求基準版本和需求控制版本文檔
  6. 維護需求變動的歷史記錄
  7. 跟蹤每項需求的狀態
  8. 衡量需求穩定性

需求變動管理

管理和控制需求基線的過程

需求變動控制系統 

一個正式的文檔,說明如何控制需求變動  

創建變動審批系統

2、任務分解定義

WBS (Work Breakdown Structure)

任務分解的過程 將一個項目分解爲更多的工做細目或者子項目,使項目變得更小、更易管理、更易操做。

任務分解的結果 WBS(任務分解結構)。

WBS 面向可交付成果的。

Work packages(工做包) WBS的最低層次的可交付成果

WBS實例

PMI defines WBS

是面向可交付成果的對項目元素的分組,它組織並定義了整個項目範圍.不在WBS中包括的工做就不是該項目的工做

它是一個分級的樹型結構,是對項目由粗到細的分解過程。工做結構每細分一個層次表示對項目元素更細緻的描述

PMI defines Work packages

WBS的最低層次的可交付成果

工做包應當由惟一主體負責

這一交付成果能夠分配給另一位項目經理進行計劃和執行,或者經過子項目的方式完成

3、任務分解的類型

類型

  • 清單
  • 圖表

圖表類型

清單類型

1.變化計數器

​ 1.1          比較兩個版本的程序

​ 1.1.1     預處理

​ 1.1.2     文件比較

​ 1.1.3     結果處理

​ 1.2          找出修改後的程序中增長和刪除的代碼行

​ 1.2.1     找出增長的代碼行

​ 1.2.2     找出刪除的代碼行

​ 1.3          統計修改後的程序中增長和刪除的代碼行數

​ 1.3.1     統計增長代碼行數

​ 1.3.2     統計刪除代碼行數

​ 1.4          統計總的代碼行數

​ 1.5          設定標記以指示修改的次數

​ 1.6          在程序的頭部增長修改紀錄

4、任務分解的方法

任務分解過程

分解方法

  • 類比:參照相似項目的WBS
  • 模版:經過一個通用模板,對其進行增刪
  • 自上而下
  • 自下而上

WBS模板舉例

分解方法-自上而下

分解方法-自下而上

任務結構分解(WBS)步驟

確認並分解項目的組成要素

肯定分解標準

肯定分解是否詳細

肯定項目交付成果

驗證分解的正確性(創建編號)

WBS編號系統

WBS與OBS(組織分解結構)

分解標準

  • 生存期
  • 功能組成

分解標準應統一

學生管理

  • 按照生命期分解

    • 規劃需求設計編碼測試提交
  • 按照產品組成分解
    • 1.1        招生管理
    • 1.2         分班管理
    • 1.3         學生檔案管理
    • 1.4         學生成績管理
  • 不能同時使用兩種標準進行分解
    • 招生管理  分班管理  學生檔案管理 學生成績管理 規劃 需求 設計 編碼 測試 提交

檢驗分解結果的標準

  • WBS分解的規模和數量因項目而異、因項目經理而異
  • 收集與項目相關的全部信息
  • 參看一下相似的項目的WBS,與相關人員討論
  • 能夠參照模板最低層是可控的和可管理的,可是避免沒必要要的過細,最好不要超過7層,
  • 軟件項目推薦分解到40小時的任務
  • 注:80/8規則
  • 每一個Work package必須有一個提交物
  • 定義任務完成的標準
  • 每一個WBS必須有利於責任分配
  • 能夠準備WBS的字典
  • 最後與相關人員進行評審

WBS字典內容

相關文章
相關標籤/搜索