軟件項(xiàng)目進(jìn)度計(jì)劃估算探討

    對(duì)軟件項(xiàng)目做開發(fā)計(jì)劃也許是最不靠譜的一件事了，由于需求的變動(dòng)、開發(fā)人員的水平以及如人事變動(dòng)等不可預(yù)測(cè)的情況，導(dǎo)致項(xiàng)目的延期成為了家常便飯。而現(xiàn)在的項(xiàng)目管理人員往往是憑經(jīng)驗(yàn)來制作進(jìn)度計(jì)劃的，經(jīng)驗(yàn)的確很重要，也是項(xiàng)目進(jìn)度估算一個(gè)不可或缺的基礎(chǔ)條件，但僅僅憑經(jīng)驗(yàn)來做計(jì)劃也會(huì)產(chǎn)生以下的一些問題：

    1、對(duì)項(xiàng)目的理解不同，每個(gè)項(xiàng)目管理人員的開發(fā)經(jīng)歷與項(xiàng)目經(jīng)歷都是不同的，你有你的計(jì)劃方法，我有我的計(jì)劃方法，不同的人對(duì)同一項(xiàng)目做計(jì)劃時(shí)可能對(duì)于人員的安排與項(xiàng)目的完成日期的分歧會(huì)很大。所以如果碰到中途換人的情況，那軟件進(jìn)度計(jì)劃這個(gè)事就說不清楚了。

    2、漏掉必須完成的需求，如果項(xiàng)目管理人員每次都憑經(jīng)驗(yàn)來對(duì)項(xiàng)目做計(jì)劃，那么當(dāng)項(xiàng)目規(guī)模變得很大時(shí)，勢(shì)必會(huì)遺漏一些需求的細(xì)節(jié)，而這些致命的細(xì)節(jié)往往會(huì)在設(shè)計(jì)后期或開發(fā)后期才會(huì)知道，嚴(yán)重的可能導(dǎo)致整個(gè)軟件架構(gòu)重構(gòu)。

    3、沒有一套模型，項(xiàng)目管理人員僅憑經(jīng)驗(yàn)來做計(jì)劃是會(huì)缺少依據(jù)和可追溯性的，雖然對(duì)于每個(gè)任務(wù)時(shí)間的估算大部分情況是靠管理人員的經(jīng)驗(yàn)與開發(fā)人員的承諾，但任務(wù)之間的順序安排，任務(wù)之間的依賴關(guān)系，人員數(shù)量對(duì)項(xiàng)目開發(fā)效率的影響是需要一套方法來描述清楚的。而可追溯性則表現(xiàn)為為什么我要這么安排的層面上。

    為了解決上面的一些問題，我們需要引入一套模型（可以理解為一種思想）來完善我們的進(jìn)度計(jì)劃估算工作。這里，我以一個(gè)簡(jiǎn)單的B2C系統(tǒng)作背景，描述其中的一些主要模塊，與大家一起探討下如何為一個(gè)web軟件項(xiàng)目的開發(fā)做計(jì)劃。        

    首先，當(dāng)然是要明確我們需要做什么，也就是確定需求。我們的需求及用例是這樣的：

        用戶操作

            注冊(cè)：用戶注冊(cè)為網(wǎng)站會(huì)員。

            登錄：用戶登錄網(wǎng)站，登錄后能購買產(chǎn)品，查看相關(guān)用戶資料。

            加入購物車：用戶將產(chǎn)品加入購物車后可一起支付購買。

            購買（生成訂單，支付）：付款及生成訂單。

            查看/修改用戶資料：通過用戶資料頁面查看/修改用戶資料。

            查看購物車：看看準(zhǔn)備買的東西。

            查看訂單：看看已經(jīng)買過的東西。

用戶用例

    管理員操作

        產(chǎn)品

            操作產(chǎn)品（操作指增、刪、改操作）：添加、修改、刪除提供給用戶購買的產(chǎn)品。

            操作產(chǎn)品所屬廠商：添加、修改、刪除產(chǎn)品所屬的廠商。

            操作產(chǎn)品屬性：添加、修改、刪除產(chǎn)品的屬性。

            操作產(chǎn)品類別：添加、修改、刪除產(chǎn)品的類別。

        配件

            操作運(yùn)送方式：添加、修改、刪除提供的運(yùn)送方式，如是順豐還是UPS。

            操作國家地區(qū)：添加、修改、刪除國家/區(qū)域，網(wǎng)站國家區(qū)域不同，收稅也不同。

            操作語言：添加、修改、刪除網(wǎng)站支持的語言，如中文和英文顯示。

            操作稅：設(shè)置稅的類別，不同的產(chǎn)品可以附加不同的稅費(fèi)。

            操作系統(tǒng)設(shè)置，如設(shè)置商店名稱等：網(wǎng)站的全局設(shè)置。

            操作貨幣：設(shè)置用戶支付的幣種。

        用戶

            操作用戶：添加、刪除、修改用戶資料。

            操作用戶組：添加、刪除、修改用戶所屬的用戶組，不同用戶組的用戶在購買商品時(shí)享受的折扣不同。

        報(bào)表

            操作訂單報(bào)表：添加、刪除、修改、查詢用戶訂單。

管理員用例

    通過用例，我們可以提煉出業(yè)務(wù)對(duì)象：

        1 用戶

        2 用戶組

        3 產(chǎn)品

            3.1 產(chǎn)品分類

            3.2 廠商

            3.3 產(chǎn)品屬性

        4 訂單

        5 配件

            5.1 國家

            5.2 語言

            5.3 物流

            5.4 稅

            5.5 貨幣

            5.6 支付方式

    在確定業(yè)務(wù)對(duì)象后，我們需要知道每個(gè)對(duì)象的具體職責(zé)和用例的基本執(zhí)行流程，可以用活動(dòng)圖來達(dá)到這個(gè)目的。

    活動(dòng)圖顯示了核心用例購買商品的基本流程，從圖中可以發(fā)現(xiàn)，要完成購買用例，我們必須先建立“產(chǎn)品對(duì)象”，“物流對(duì)象”，“支付方式對(duì)象”，“交易對(duì)象”，“訂單對(duì)象”?！百徫镘噷?duì)象”由于是可選步驟，所以可以單獨(dú)建立。

    物流對(duì)象、交易對(duì)象、支付方式對(duì)象，是比較獨(dú)立的對(duì)象，沒有依賴。而要建立產(chǎn)品對(duì)象，購物車對(duì)象，訂單對(duì)象都是有先決條件的。下面我們來依次分析這幾個(gè)對(duì)象。分析的依據(jù)就是我們的用例圖。我們可以利用表格來表達(dá)我們的分析結(jié)果：

    從上表可知對(duì)象間的相互關(guān)系。那么，在開發(fā)過程中，我們將從簡(jiǎn)單對(duì)象，也就是沒有依賴項(xiàng)的對(duì)象開始設(shè)計(jì)，然后再來設(shè)計(jì)復(fù)雜對(duì)象。簡(jiǎn)單對(duì)象可以并行設(shè)計(jì)，也可依次設(shè)計(jì)，視具體人員決定。根據(jù)業(yè)務(wù)對(duì)象表，我們可推導(dǎo)出出版的關(guān)鍵路徑圖。如下圖所示：

點(diǎn)擊此處查看圖

    上圖初步的展示了開發(fā)步驟，在理想狀態(tài)下，獨(dú)立對(duì)象可以同步開發(fā)，依賴對(duì)象在前置對(duì)象開發(fā)完成后再開發(fā)。圖中的虛線箭頭表示隱性依賴，意思是在此期間并沒有實(shí)際的任務(wù)在做，而只是表達(dá)一種依賴關(guān)系，表明在進(jìn)行箭頭后任務(wù)之前，必須完成箭頭前的任務(wù)。但從圖中我們也發(fā)現(xiàn)了，還沒有計(jì)劃安排開始時(shí)間及完成時(shí)間，每個(gè)任務(wù)的持續(xù)時(shí)間也沒有計(jì)算出來。所以下面我們來開始估算每個(gè)任務(wù)的開發(fā)時(shí)間。

    對(duì)于任務(wù)時(shí)間的估算，有一種稱為功能點(diǎn)的估算方法。下面來詳細(xì)介紹下這個(gè)估算方法，請(qǐng)看下面的兩個(gè)公式：

        未調(diào)整的功能點(diǎn)數(shù) = a1 x Inp+ a2 x Out + a3 x Inq + a4 x Maf + a5 x Inf

        技術(shù)復(fù)雜性因子（TCF） = 軟件技術(shù)因素對(duì)軟件規(guī)模的綜合影響程度(DI) x 0.01 + 0.65

        DI = ΣFi

        1<=i<=14

        F最小取值為0（對(duì)軟件規(guī)模無影響）， 最大取值為5（對(duì)軟件規(guī)模有很大影響）

        功能點(diǎn)數(shù)（FP） = 未調(diào)整的功能點(diǎn)數(shù) x 技術(shù)復(fù)雜性因子

        Inp為輸入項(xiàng)數(shù)，指用戶向軟件輸入的項(xiàng)數(shù)，a1為它的系數(shù)。

        Out為輸出項(xiàng)數(shù)，指軟件向用戶輸出的項(xiàng)數(shù)，a2為它的系數(shù)

        Inq為查詢數(shù)，指軟件執(zhí)行數(shù)據(jù)查詢，如得到產(chǎn)品信息就是一個(gè)查詢，a3為它的系數(shù)。

        Maf為文件數(shù)目，a4為它的系數(shù)。

        Inf為機(jī)器可讀的接口數(shù)，如磁盤上數(shù)據(jù)文件的數(shù)量，a5為它的系數(shù)

        利用Albrecht & Gaffney 模型

        工作量 = -13.39 + 0.0545 x FP

        利用Maston, Barnett 和 Mellichamp模型

        工作量 = 585.7 + 15.12 x FP

        工作量單位為人/月

    從上面的公式可以看出，利用不同模型推算出來的工作量差別很大。實(shí)際上，沒有一種模型能精確的推算出所有的軟件項(xiàng)目工作量，多數(shù)只是根據(jù)若干應(yīng)用領(lǐng)域中有限個(gè)項(xiàng)目的經(jīng)驗(yàn)數(shù)據(jù)推導(dǎo)出來的。所以我們?cè)谟?jì)算時(shí)，完全無需照搬模型的算法，而是應(yīng)該吸收模型所代表的思想。所以，下面我們?cè)囍谜{(diào)整過的公式來計(jì)算下每個(gè)業(yè)務(wù)對(duì)象的功能點(diǎn)數(shù)以及工作量。

    在我們自己的計(jì)算中，打算去掉Maf與Inf這兩個(gè)參數(shù)。所以，未調(diào)整的功能點(diǎn)數(shù) = a1 x 填寫表單數(shù)+ a2 x 數(shù)據(jù)操作數(shù)。對(duì)于簡(jiǎn)單對(duì)象，a1取值4，a2取值5。對(duì)于復(fù)雜對(duì)象，a1取值8，a2取值10。a在這里代表一個(gè)人完成任務(wù)所需要的小時(shí)數(shù)。其中，訂單對(duì)象，產(chǎn)品對(duì)象為復(fù)雜對(duì)象，其它對(duì)象為簡(jiǎn)單對(duì)象，由于支付方式、運(yùn)送方式是涉及到對(duì)外API實(shí)現(xiàn)，購物車是不存在填寫表單與數(shù)據(jù)操作的，所以需要另算。在計(jì)算DI時(shí)，我們?nèi)∑骄鵉為1.5，代表技術(shù)因素對(duì)軟件規(guī)模影響不大。則技術(shù)復(fù)雜因子=14*1.5*0.01+0.65=0.86。

    填寫表單數(shù)對(duì)用戶或管理員填寫的表單進(jìn)行統(tǒng)計(jì)，如用戶注冊(cè)需要填寫一張表單，查詢需要填寫一張表單。管理員添加用戶需要填寫一張表單，修改用戶也需要填寫一張表單。

    詳細(xì)統(tǒng)計(jì)請(qǐng)看下表：

    由此算出，除開購物車，支付方式，運(yùn)送方式三個(gè)業(yè)務(wù)對(duì)象的開發(fā)，估計(jì)需要約416小時(shí)。按一天8小時(shí)計(jì)算，需52人/天，購物車的難度介于復(fù)雜對(duì)象與簡(jiǎn)單對(duì)象之間，可以取35。單個(gè)支付方式與運(yùn)送方式，因?yàn)榭赡苄枰獙?duì)外聯(lián)調(diào)，所以難度可能相當(dāng)于復(fù)雜對(duì)象，可以取50。所以如果該系統(tǒng)支持單個(gè)支付方式與運(yùn)送方式，則全部業(yè)務(wù)對(duì)象估算需要416+35+50+50=551小時(shí)≈69人/天

    理論上，參與開發(fā)的人數(shù)越多，則軟件開發(fā)速度越快。但事實(shí)上，隨著項(xiàng)目規(guī)模的擴(kuò)大，開發(fā)人員之間的通信開銷也為之增大，所以個(gè)人生產(chǎn)率將會(huì)下降，以至于開發(fā)時(shí)間與從事開發(fā)工作的人數(shù)并不成反比關(guān)系。如果在項(xiàng)目過程中有老員工的離職與新員工的加入等情況，則更會(huì)加劇項(xiàng)目的延遲。

    假設(shè)有P名開發(fā)人員，則項(xiàng)目組成員間的通信路徑的范圍在P~P2/2之間，因?yàn)槿绻?xiàng)目組每個(gè)成員都必須與其他成員溝通，那么通信路徑是P(P-1)/2，而如果項(xiàng)目組每個(gè)成員只需與一個(gè)同事溝通的話，那么通信路徑將是P-1。由此我們推導(dǎo)出項(xiàng)目總生產(chǎn)率的公式為

        Lsum = P(L-l(P-1)的r次方)

        L為單個(gè)成員理想生產(chǎn)率（不與任何其他成員通信時(shí)的生產(chǎn)率）

        l為每條通信路徑導(dǎo)致生產(chǎn)率減少量

        r為對(duì)通信路徑的度量，如每個(gè)成員都必須與其他所有成員通信，則r為1

    根據(jù)此公式計(jì)算，一般項(xiàng)目成員在3~5名的時(shí)候總生產(chǎn)率與成本將達(dá)到一個(gè)比較理想的狀態(tài)。由于在這個(gè)例子中的業(yè)務(wù)對(duì)象較少（當(dāng)然，在現(xiàn)實(shí)項(xiàng)目中，開發(fā)過程不僅僅只有業(yè)務(wù)對(duì)象，還有數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)、模板設(shè)計(jì)、環(huán)境部署等一系列的工作，而這些工作可能還需要與不同小組的同事溝通協(xié)調(diào)），所以我們假定項(xiàng)目組成員有3人進(jìn)行業(yè)務(wù)對(duì)象的開發(fā)。

    現(xiàn)在我們得到了總的工作量為69人/天，開發(fā)人數(shù)為3人，那么大概此項(xiàng)工作的全部時(shí)間為1個(gè)月。所以我們可以按1個(gè)月（22天）來安排工作了。根據(jù)工作量的估算，我們先為每個(gè)人安排工作，設(shè)員工為A, B和C則

        A負(fù)責(zé): 產(chǎn)品類別/24.08， 產(chǎn)品廠商/28.38，產(chǎn)品屬性/24.08，購物車/35，產(chǎn)品/56.76，語言/24.08 192.38

        B負(fù)責(zé): 支付方式/50，運(yùn)送方式/50，貨幣/24.08，國家/區(qū)域/48.16  172.24

        C負(fù)責(zé): 用戶/42.14，用戶組/24.08，稅/48.16，訂單/72.24  186.62

        按每個(gè)員工的職責(zé)來重新繪制網(wǎng)絡(luò)工程圖，如下所示：

點(diǎn)擊此處查看圖

    至此，我們確定了工程的關(guān)鍵路徑及具體每個(gè)任務(wù)的開始結(jié)束日期，而開發(fā)組成員的具體工作任務(wù)也分配好了。

    在實(shí)際的開發(fā)工程中，我們不僅要確認(rèn)每個(gè)業(yè)務(wù)對(duì)象的具體任務(wù)，還有如數(shù)據(jù)對(duì)象的確認(rèn)（從數(shù)據(jù)對(duì)象映射到數(shù)據(jù)結(jié)構(gòu)），環(huán)境的配置，單元測(cè)試等一系列的工作，這些工作都可以用網(wǎng)絡(luò)工程圖的形式來確認(rèn)相互的完成順序與完成時(shí)間，并且網(wǎng)絡(luò)工程圖還可以等價(jià)轉(zhuǎn)換為更加直觀的甘特圖來表示，從而對(duì)我們的項(xiàng)目的進(jìn)度計(jì)劃提供指導(dǎo)與依據(jù)。