您好,登錄后才能下訂單哦!
對軟件項目做開發計劃也許是最不靠譜的一件事了,由于需求的變動、開發人員的水平以及如人事變動等不可預測的情況,導致項目的延期成為了家常便飯。而現在的項目管理人員往往是憑經驗來制作進度計劃的,經驗的確很重要,也是項目進度估算一個不可或缺的基礎條件,但僅僅憑經驗來做計劃也會產生以下的一些問題:
1、對項目的理解不同,每個項目管理人員的開發經歷與項目經歷都是不同的,你有你的計劃方法,我有我的計劃方法,不同的人對同一項目做計劃時可能對于人員的安排與項目的完成日期的分歧會很大。所以如果碰到中途換人的情況,那軟件進度計劃這個事就說不清楚了。
2、漏掉必須完成的需求,如果項目管理人員每次都憑經驗來對項目做計劃,那么當項目規模變得很大時,勢必會遺漏一些需求的細節,而這些致命的細節往往會在設計后期或開發后期才會知道,嚴重的可能導致整個軟件架構重構。
3、沒有一套模型,項目管理人員僅憑經驗來做計劃是會缺少依據和可追溯性的,雖然對于每個任務時間的估算大部分情況是靠管理人員的經驗與開發人員的承諾,但任務之間的順序安排,任務之間的依賴關系,人員數量對項目開發效率的影響是需要一套方法來描述清楚的。而可追溯性則表現為為什么我要這么安排的層面上。
為了解決上面的一些問題,我們需要引入一套模型(可以理解為一種思想)來完善我們的進度計劃估算工作。這里,我以一個簡單的B2C系統作背景,描述其中的一些主要模塊,與大家一起探討下如何為一個web軟件項目的開發做計劃。
首先,當然是要明確我們需要做什么,也就是確定需求。我們的需求及用例是這樣的:
用戶操作
注冊:用戶注冊為網站會員。
登錄:用戶登錄網站,登錄后能購買產品,查看相關用戶資料。
加入購物車:用戶將產品加入購物車后可一起支付購買。
購買(生成訂單,支付):付款及生成訂單。
查看/修改用戶資料:通過用戶資料頁面查看/修改用戶資料。
查看購物車:看看準備買的東西。
查看訂單:看看已經買過的東西。
用戶用例
管理員操作
產品
操作產品(操作指增、刪、改操作):添加、修改、刪除提供給用戶購買的產品。
操作產品所屬廠商:添加、修改、刪除產品所屬的廠商。
操作產品屬性:添加、修改、刪除產品的屬性。
操作產品類別:添加、修改、刪除產品的類別。
配件
操作運送方式:添加、修改、刪除提供的運送方式,如是順豐還是UPS。
操作國家地區:添加、修改、刪除國家/區域,網站國家區域不同,收稅也不同。
操作語言:添加、修改、刪除網站支持的語言,如中文和英文顯示。
操作稅:設置稅的類別,不同的產品可以附加不同的稅費。
操作系統設置,如設置商店名稱等:網站的全局設置。
操作貨幣:設置用戶支付的幣種。
用戶
操作用戶:添加、刪除、修改用戶資料。
操作用戶組:添加、刪除、修改用戶所屬的用戶組,不同用戶組的用戶在購買商品時享受的折扣不同。
報表
操作訂單報表:添加、刪除、修改、查詢用戶訂單。
管理員用例
通過用例,我們可以提煉出業務對象:
1 用戶
2 用戶組
3 產品
3.1 產品分類
3.2 廠商
3.3 產品屬性
4 訂單
5 配件
5.1 國家
5.2 語言
5.3 物流
5.4 稅
5.5 貨幣
5.6 支付方式
在確定業務對象后,我們需要知道每個對象的具體職責和用例的基本執行流程,可以用活動圖來達到這個目的。
活動圖顯示了核心用例購買商品的基本流程,從圖中可以發現,要完成購買用例,我們必須先建立“產品對象”,“物流對象”,“支付方式對象”,“交易對象”,“訂單對象”。“購物車對象”由于是可選步驟,所以可以單獨建立。
物流對象、交易對象、支付方式對象,是比較獨立的對象,沒有依賴。而要建立產品對象,購物車對象,訂單對象都是有先決條件的。下面我們來依次分析這幾個對象。分析的依據就是我們的用例圖。我們可以利用表格來表達我們的分析結果:
從上表可知對象間的相互關系。那么,在開發過程中,我們將從簡單對象,也就是沒有依賴項的對象開始設計,然后再來設計復雜對象。簡單對象可以并行設計,也可依次設計,視具體人員決定。根據業務對象表,我們可推導出出版的關鍵路徑圖。如下圖所示:
點擊此處查看圖
上圖初步的展示了開發步驟,在理想狀態下,獨立對象可以同步開發,依賴對象在前置對象開發完成后再開發。圖中的虛線箭頭表示隱性依賴,意思是在此期間并沒有實際的任務在做,而只是表達一種依賴關系,表明在進行箭頭后任務之前,必須完成箭頭前的任務。但從圖中我們也發現了,還沒有計劃安排開始時間及完成時間,每個任務的持續時間也沒有計算出來。所以下面我們來開始估算每個任務的開發時間。
對于任務時間的估算,有一種稱為功能點的估算方法。下面來詳細介紹下這個估算方法,請看下面的兩個公式:
未調整的功能點數 = a1 x Inp+ a2 x Out + a3 x Inq + a4 x Maf + a5 x Inf
技術復雜性因子(TCF) = 軟件技術因素對軟件規模的綜合影響程度(DI) x 0.01 + 0.65
DI = ΣFi
1<=i<=14
F最小取值為0(對軟件規模無影響), 最大取值為5(對軟件規模有很大影響)
功能點數(FP) = 未調整的功能點數 x 技術復雜性因子
Inp為輸入項數,指用戶向軟件輸入的項數,a1為它的系數。
Out為輸出項數,指軟件向用戶輸出的項數,a2為它的系數
Inq為查詢數,指軟件執行數據查詢,如得到產品信息就是一個查詢,a3為它的系數。
Maf為文件數目,a4為它的系數。
Inf為機器可讀的接口數,如磁盤上數據文件的數量,a5為它的系數
利用Albrecht & Gaffney 模型
工作量 = -13.39 + 0.0545 x FP
利用Maston, Barnett 和 Mellichamp模型
工作量 = 585.7 + 15.12 x FP
工作量單位為人/月
從上面的公式可以看出,利用不同模型推算出來的工作量差別很大。實際上,沒有一種模型能精確的推算出所有的軟件項目工作量,多數只是根據若干應用領域中有限個項目的經驗數據推導出來的。所以我們在計算時,完全無需照搬模型的算法,而是應該吸收模型所代表的思想。所以,下面我們試著用調整過的公式來計算下每個業務對象的功能點數以及工作量。
在我們自己的計算中,打算去掉Maf與Inf這兩個參數。所以,未調整的功能點數 = a1 x 填寫表單數+ a2 x 數據操作數。對于簡單對象,a1取值4,a2取值5。對于復雜對象,a1取值8,a2取值10。a在這里代表一個人完成任務所需要的小時數。其中,訂單對象,產品對象為復雜對象,其它對象為簡單對象,由于支付方式、運送方式是涉及到對外API實現,購物車是不存在填寫表單與數據操作的,所以需要另算。在計算DI時,我們取平均F為1.5,代表技術因素對軟件規模影響不大。則技術復雜因子=14*1.5*0.01+0.65=0.86。
填寫表單數對用戶或管理員填寫的表單進行統計,如用戶注冊需要填寫一張表單,查詢需要填寫一張表單。管理員添加用戶需要填寫一張表單,修改用戶也需要填寫一張表單。
詳細統計請看下表:
由此算出,除開購物車,支付方式,運送方式三個業務對象的開發,估計需要約416小時。按一天8小時計算,需52人/天,購物車的難度介于復雜對象與簡單對象之間,可以取35。單個支付方式與運送方式,因為可能需要對外聯調,所以難度可能相當于復雜對象,可以取50。所以如果該系統支持單個支付方式與運送方式,則全部業務對象估算需要416+35+50+50=551小時≈69人/天
理論上,參與開發的人數越多,則軟件開發速度越快。但事實上,隨著項目規模的擴大,開發人員之間的通信開銷也為之增大,所以個人生產率將會下降,以至于開發時間與從事開發工作的人數并不成反比關系。如果在項目過程中有老員工的離職與新員工的加入等情況,則更會加劇項目的延遲。
假設有P名開發人員,則項目組成員間的通信路徑的范圍在P~P2/2之間,因為如果項目組每個成員都必須與其他成員溝通,那么通信路徑是P(P-1)/2,而如果項目組每個成員只需與一個同事溝通的話,那么通信路徑將是P-1。由此我們推導出項目總生產率的公式為
Lsum = P(L-l(P-1)的r次方)
L為單個成員理想生產率(不與任何其他成員通信時的生產率)
l為每條通信路徑導致生產率減少量
r為對通信路徑的度量,如每個成員都必須與其他所有成員通信,則r為1
根據此公式計算,一般項目成員在3~5名的時候總生產率與成本將達到一個比較理想的狀態。由于在這個例子中的業務對象較少(當然,在現實項目中,開發過程不僅僅只有業務對象,還有數據結構設計、模板設計、環境部署等一系列的工作,而這些工作可能還需要與不同小組的同事溝通協調),所以我們假定項目組成員有3人進行業務對象的開發。
現在我們得到了總的工作量為69人/天,開發人數為3人,那么大概此項工作的全部時間為1個月。所以我們可以按1個月(22天)來安排工作了。根據工作量的估算,我們先為每個人安排工作,設員工為A, B和C則
A負責: 產品類別/24.08, 產品廠商/28.38,產品屬性/24.08,購物車/35,產品/56.76,語言/24.08 192.38
B負責: 支付方式/50,運送方式/50,貨幣/24.08,國家/區域/48.16 172.24
C負責: 用戶/42.14,用戶組/24.08,稅/48.16,訂單/72.24 186.62
按每個員工的職責來重新繪制網絡工程圖,如下所示:
點擊此處查看圖
至此,我們確定了工程的關鍵路徑及具體每個任務的開始結束日期,而開發組成員的具體工作任務也分配好了。
在實際的開發工程中,我們不僅要確認每個業務對象的具體任務,還有如數據對象的確認(從數據對象映射到數據結構),環境的配置,單元測試等一系列的工作,這些工作都可以用網絡工程圖的形式來確認相互的完成順序與完成時間,并且網絡工程圖還可以等價轉換為更加直觀的甘特圖來表示,從而對我們的項目的進度計劃提供指導與依據。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。