您的位置:軟件測(cè)試 > 軟件項(xiàng)目管理 > 項(xiàng)目計(jì)劃 >
基于用例的工作量估計(jì)
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2013/5/10 14:54:36 ] 推薦標(biāo)簽:

     本文描述了基于用例進(jìn)行評(píng)估的一個(gè)框架。為了使描述更加具體,本文為框架的參數(shù)選擇了一些值,盡管這些值有待于論證,但它們并不總是錯(cuò)誤的。像往常一樣,隨著數(shù)據(jù)的搜集,這種估計(jì)應(yīng)該根據(jù)實(shí)際情況和重新估計(jì)的參數(shù)值進(jìn)行測(cè)試。這種框架對(duì)于不同種類(lèi)的系統(tǒng)考慮了用例層次、規(guī)模和復(fù)雜度等思想,并且不再采取細(xì)粒度的功能分解。為減輕計(jì)算的負(fù)擔(dān),對(duì)于諸如 Estimate Professional 這樣的工具,可以構(gòu)建一個(gè)前端,從而提供一種基于用例的規(guī)模輸入的不同的方法。

問(wèn)題
直觀上看起來(lái)似乎根據(jù)用例模型的特征,可以對(duì)開(kāi)發(fā)工作所需的規(guī)模和工作量進(jìn)行估計(jì)。畢竟,用例模型捕獲了功能性需求,那么難道不應(yīng)該有基于等價(jià)于功能點(diǎn)的用例嗎?這里存在許多困難:

    有許多不同的用例規(guī)格樣式和形式,很難定義一個(gè)度量標(biāo)準(zhǔn),例如,某人可能希望能夠度量用例的長(zhǎng)度;
    用例應(yīng)該代表外部參與者對(duì)于系統(tǒng)的觀點(diǎn),因此,500,000 sloc 系統(tǒng)的用例與 5,000 sloc 子系統(tǒng)的用例在完全不同的層次上(Cockburn 97 討論了層次和目標(biāo)的概念);
    用例可能在復(fù)雜性方面不同,編寫(xiě)時(shí)是顯式的,實(shí)現(xiàn)時(shí)又是隱式的。
    用例應(yīng)該從參與者的角度來(lái)描述行為,但是這可能相當(dāng)復(fù)雜,特別是當(dāng)系統(tǒng)具有狀態(tài)時(shí)(絕大多數(shù)情況是這樣的)。所以描述這種行為需要系統(tǒng)的模型(在實(shí)現(xiàn)它們之前)。當(dāng)試圖捕獲行為本質(zhì)時(shí),這將導(dǎo)致過(guò)多的功能分解層次和細(xì)節(jié)。

所以,為了能夠進(jìn)行評(píng)估,是否有必要實(shí)現(xiàn)一些種類(lèi)的用例呢?或許是對(duì)于直接根據(jù)用例進(jìn)行估計(jì)的期望過(guò)高,并且在功能點(diǎn)和用例點(diǎn)的概念之間直接劃等號(hào)對(duì)我們產(chǎn)生了誤導(dǎo)。功能點(diǎn)數(shù)量的計(jì)算無(wú)論如何都需要一個(gè)系統(tǒng)模型。從用例描述中派生的功能點(diǎn)需要達(dá)到與用例表達(dá)一致的層次,并且只有達(dá)到該層次時(shí),我們才能夠?qū)δ茳c(diǎn)的數(shù)量有信心。Fetcke 97 描述了一種從用例到功能點(diǎn)的映射,但是,用例的層次必須適當(dāng),這樣映射才能有效。其他的方法使用基于類(lèi)或基于對(duì)象的度量標(biāo)準(zhǔn)作為來(lái)源,PRICE Object Points 是一個(gè)這樣的例子(Minkiewicz 96)。

其他工作
在描述和形式化用例方面的工作相當(dāng)完備――Hurlbut 97 對(duì)此有很好的概括。而從用例中派生估計(jì)的度量標(biāo)準(zhǔn)卻寥寥無(wú)幾。Graham 95 和 Graham 98 中包含了對(duì)于用例相當(dāng)嚴(yán)格的批評(píng)(但是我并不完全理解為什么他認(rèn)為他的想法和用例是大相徑庭的),并且建議將"任務(wù)場(chǎng)景"作為克服用例問(wèn)題的方法――包括它們的變化的長(zhǎng)度和復(fù)雜度。Graham 的"原子任務(wù)場(chǎng)景"是"任務(wù)點(diǎn)"度量收集的基礎(chǔ)。原子任務(wù)場(chǎng)景存在的問(wèn)題是它處于低層:根據(jù) Graham的說(shuō)法,它理想的情況是作為一個(gè)單一的句子,并且如果僅僅使用本領(lǐng)域的術(shù)語(yǔ)那么不能更進(jìn)一步進(jìn)行分解。Graham 的"根任務(wù)"包含一個(gè)或者更多的原子任務(wù)場(chǎng)景,并且每一個(gè)根任務(wù)"在初始化計(jì)劃的類(lèi)中,與一個(gè)系統(tǒng)操作正好對(duì)應(yīng)" (Graham 98)。這些根任務(wù)在我看來(lái)似乎非常像低層用例,并且這些原子任務(wù)場(chǎng)景如同是這樣的用例中的步驟。然而,這種層次方面的問(wèn)題仍然沒(méi)有解決。

Karner(Karner 93)、Major(Major 98)、Armour,以及Catherwood(Armour 96)和 Thomson(Thomson 94)完成了其他方面的工作。Karner 的論文中指出了計(jì)算用例點(diǎn)的一種方法,但是該方法仍然假設(shè)這些用例是以一種通過(guò)類(lèi)可以實(shí)現(xiàn)的方式來(lái)表達(dá)的(例如,在一種更合適的細(xì)節(jié)層次上而不是子系統(tǒng)上)。

那么,我們應(yīng)該不使用用例來(lái)估計(jì)而依賴(lài)于所實(shí)現(xiàn)的分析和設(shè)計(jì)嗎?這個(gè)問(wèn)題妨礙了做出估計(jì)的能力,并且無(wú)法滿足已經(jīng)采取該技術(shù)的項(xiàng)目管理者的要求――需要盡早估計(jì)并且不得不使用其他方法。對(duì)于項(xiàng)目管理者來(lái)說(shuō),為了做項(xiàng)目規(guī)劃,好能夠盡早獲得評(píng)估,然后反復(fù)對(duì)其進(jìn)行精化,而不是拖延評(píng)估并且毫無(wú)頭緒地進(jìn)行工作。

本文中描述了一個(gè)框架,在該框架中可以使用任何層次的用例來(lái)形成工作量估計(jì)。為了展示這些觀點(diǎn),本文描述了一些簡(jiǎn)單的規(guī)范結(jié)構(gòu),這些結(jié)構(gòu)具有相關(guān)的一定實(shí)踐基礎(chǔ)上的維度和規(guī)模。本文中大多是大膽的(或者應(yīng)該說(shuō)缺乏根據(jù)的)推測(cè),因?yàn)槲覜](méi)有其他的方法來(lái)解決這個(gè)領(lǐng)域中缺少的工作和數(shù)據(jù)的問(wèn)題。本文引用了"互連系統(tǒng)構(gòu)成的系統(tǒng)"思想。

接下來(lái),我將暫時(shí)撇開(kāi)主題來(lái)介紹一些將我引入本文主題的一些背景想法。

避免功能分解嗎?
功能分解的思想對(duì)于軟件開(kāi)發(fā)領(lǐng)域中的許多人來(lái)說(shuō)像一個(gè)"詛咒"。我對(duì)功能分解的體驗(yàn)更是其中的極端(在一個(gè)很大的數(shù)據(jù)流圖中有 3000 個(gè)原始轉(zhuǎn)換,五層或者六層深,在除了基礎(chǔ)設(shè)施層外沒(méi)有使用任何構(gòu)架的思想的情況下完成),讓我感到異常悲觀。在該用例中存在的問(wèn)題不僅僅與功能分解思想有關(guān),還和下面這種想法有關(guān),即直到分解到功能的原始層次才描述一個(gè)進(jìn)程。在該層次上規(guī)格說(shuō)明的長(zhǎng)度應(yīng)該少于一頁(yè)。

所得到的結(jié)果難以理解――所需要的更高層次的行為如何從這些原始轉(zhuǎn)換中顯現(xiàn)出來(lái),這一點(diǎn)很難搞清楚。另外,功能結(jié)構(gòu)如何映射到物理結(jié)構(gòu)上來(lái)滿足性能和其他質(zhì)量方面的要求并不是特別明顯。這產(chǎn)生了一種自相矛盾情況,我們一直進(jìn)行分解直到達(dá)到了能夠"解決問(wèn)題"(原始層次)的那一層,但是,這些原始層是否能夠?qū)嶋H上協(xié)同工作以滿足更高層的目標(biāo)卻并不清楚或者可以被證明。沒(méi)有辦法以這種方式來(lái)考慮非功能性需求。從總體上講,構(gòu)架和基礎(chǔ)設(shè)施(通訊,操作系統(tǒng)等等)都應(yīng)該隨著分解而不斷演進(jìn),并且每一次分解都應(yīng)該對(duì)其它分解產(chǎn)生影響。

那么 Bauhaus 規(guī)則"形式服從功能"又如何呢? 有許多好的設(shè)計(jì)源自功能主義方法,但也不乏一些不良設(shè)計(jì)。例如,隨處可見(jiàn)的平屋頂結(jié)構(gòu)的使用。如果您只關(guān)心屋頂?shù)墓δ埽⑶覍⑵渫耆O(shè)計(jì)為居民所需的一個(gè)房蓋,那么至少在一些特定的領(lǐng)域中是不能夠令人滿意的 。這種屋頂很難防水,并且容易積雪。

現(xiàn)在這些問(wèn)題可以解決了,但是在一個(gè)更大的范圍內(nèi)而不是在您已經(jīng)選擇的不同設(shè)計(jì)中。盡管看上去有些過(guò)時(shí),但是形式還是應(yīng)該服從所有的功能和非功能性需求,以及后續(xù)的美學(xué)要求。架構(gòu)師面對(duì)的問(wèn)題經(jīng)常是非功能性需求經(jīng)常表達(dá)模糊,并且過(guò)多的依賴(lài)于架構(gòu)師的"事情應(yīng)該是這樣"的經(jīng)驗(yàn)。因此如果功能分解僅僅用來(lái)驅(qū)動(dòng)構(gòu)架(即分解產(chǎn)生了幾個(gè)向下的層次并且功能的原始層次與"模塊"一一匹配)和定義其接口,那么將一無(wú)是處。

像這樣的考慮使我確信,在完成構(gòu)架工作之前,將用例向下分解到標(biāo)準(zhǔn)化的水平(這可以通過(guò)類(lèi)的協(xié)作來(lái)實(shí)現(xiàn)),這沒(méi)有任何意義。對(duì)于一定規(guī)模的系統(tǒng)而言,這些分解確實(shí)必要,(參見(jiàn) Jacobson 97)但是分解的標(biāo)準(zhǔn)和實(shí)施過(guò)程至關(guān)重要――特別是當(dāng)功能分解不是足夠好的時(shí)候。

系統(tǒng)考慮
系統(tǒng)工程師完成功能分析、功能分解和功能分配工作(當(dāng)綜合一項(xiàng)設(shè)計(jì)時(shí)),但是功能并不是系統(tǒng)構(gòu)架的驅(qū)動(dòng)因素,一個(gè)專(zhuān)門(mén)的工程師團(tuán)隊(duì)能夠在評(píng)估不同的設(shè)計(jì)方面做出貢獻(xiàn)。IEEE Std 1220,系統(tǒng)工程過(guò)程的應(yīng)用和管理標(biāo)準(zhǔn)(Standard for Application and Management of the Systems Engineering Process)在 6.3 節(jié)中描述了功能分解的使用,功能分析(Functional Analysis)在 6.3.1 節(jié),功能分解(Functional Decomposition),和系統(tǒng)產(chǎn)品解決方案等綜合在 6.5 節(jié)中。6.5.1 節(jié)包含了一些特別有趣的內(nèi)容,分組(Group)功能和分配(Allocate)功能,6.5.2 節(jié)是物理解決方案的選擇(Physical Solution Alternatives)。在 6.3.1 節(jié)中指出,分解是用來(lái)清晰地理解系統(tǒng)必須完成哪些功能,并且一般情況下一層分解足夠了。

注意,功能分解的目的并不是為系統(tǒng)定型(由綜合工作來(lái)來(lái)完成定型),而是理解和溝通系統(tǒng)必須完成什么――功能模型是能夠完成這些的好的方式。在綜合中,子功能首先被分配給解決方案的結(jié)構(gòu),然后評(píng)估這個(gè)解決方案――必須考慮所有的需求。這種方法和多層功能分解之間的不同之處在于:在每一層都試圖描繪所要求的行為,并且在決定是否該行為在下一層需要被精化,以及分配到更低層的組件中之前,找到一種解決方案來(lái)實(shí)現(xiàn)它 。

從中可以得出一個(gè)結(jié)論是,在任何層次上使用數(shù)百個(gè)用例來(lái)描述行為是沒(méi)有必要的?赡芎苌倭康耐獠坑美ê拖嚓P(guān)場(chǎng)景)能夠恰當(dāng)?shù)馗采w所要描述的對(duì)象(系統(tǒng)、子系統(tǒng)、類(lèi))的行為。我應(yīng)該講一下我所說(shuō)的外部用例是指什么。舉一個(gè)由子系統(tǒng)組成的系統(tǒng)例子,這些子系統(tǒng)又由類(lèi)組成。描述系統(tǒng)及其參與者的用例,我稱(chēng)之為外部用例。子系統(tǒng)或許有它們自己的用例――它們對(duì)于系統(tǒng)來(lái)說(shuō)是內(nèi)部用例,但是對(duì)于子系統(tǒng)來(lái)說(shuō)是外部用例。終用來(lái)構(gòu)建一個(gè)龐大系統(tǒng)(大于 100 萬(wàn)行代碼)的外部用例和內(nèi)部用例的總數(shù),可能數(shù)以百計(jì),因?yàn)檫@樣規(guī)模的系統(tǒng)將包含其它系統(tǒng),或者至少包含子系統(tǒng)。

對(duì)結(jié)構(gòu)和規(guī)模的假定

用例的數(shù)量
在 IBM Rational 中,我們認(rèn)為用例的數(shù)量應(yīng)該很小(10-50 個(gè)),并且認(rèn)識(shí)到大量(超過(guò)100 個(gè))的用例表明可能需要進(jìn)行功能分解,在功能分解中用例對(duì)于參與者毫無(wú)價(jià)值。然而,在實(shí)際項(xiàng)目中我們?nèi)匀荒軌虬l(fā)現(xiàn)大量的用例,并不總是"糟糕的",至少在層次上是全面的。例如,在 Rational 內(nèi)部的電子郵件中,作者引用了一個(gè) Ericsson 例子:

    Ericsson,對(duì)大部分的新一代電話交換機(jī)的建模,估計(jì)要多于 600 個(gè)人年(多,3 到400 個(gè)開(kāi)發(fā)人員),200 個(gè)用例(使用不止一層用例,請(qǐng)參考"互連系統(tǒng)構(gòu)成的系統(tǒng)")對(duì)于一個(gè)超過(guò) 600 人年(這有多大呢?150萬(wàn)行 C++ 代碼嗎?)的系統(tǒng),恐怕用例分析會(huì)限于子系統(tǒng)上面的某一層上(也是說(shuō),如果一個(gè)人定義了一個(gè) 7000 到 10000 行代碼的子系統(tǒng)),否則用例的數(shù)量還會(huì)增加。

因此,我仍然強(qiáng)調(diào)這種觀點(diǎn)即少量的外部用例是適合的。為了匹配我曾經(jīng)建議的結(jié)構(gòu)和規(guī)格,我斷言 10 個(gè)外部用例,每個(gè)用例帶有 30 個(gè)相關(guān)場(chǎng)景 ,這對(duì)于描述行為是合適的 。如果實(shí)際中用例的數(shù)量超過(guò)了 10 個(gè),并且確實(shí)是外部用例,那么它們所描述的系統(tǒng)要比相應(yīng)的規(guī)范系統(tǒng)具有更大規(guī)模。在下文中我將提供一些支持理由來(lái)說(shuō)明這些數(shù)字是合理的。

結(jié)構(gòu)分層
建議的結(jié)構(gòu)分層如下:

4 - 多個(gè)系統(tǒng)組成的系統(tǒng)
3 - 系統(tǒng)
2 - 子系統(tǒng)組
1 - 子系統(tǒng)
0 - 類(lèi)

上一頁(yè)12345下一頁(yè)
軟件測(cè)試工具 | 聯(lián)系我們 | 投訴建議 | 誠(chéng)聘英才 | 申請(qǐng)使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權(quán)所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd