項目進度管理——基于用例的工作量估計

申請免費試用、咨詢電話：400-8352-114

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

　　問題泛普軟件-建筑工程項目管理系統(tǒng)文章

　　直觀上看起來似乎根據(jù)用例模型的特征，可以對開發(fā)工作所需的規(guī)模和工作量進行估計。畢竟，用例模型捕獲了功能性需求，那么難道不應(yīng)該有基于等價于功能點的用例嗎?這里存在許多困難：項目經(jīng)理博客

　　有許多不同的用例規(guī)格樣式和形式，很難定義一個度量標(biāo)準(zhǔn)，例如，某人可能希望能夠度量用例的長度;泛普軟件-建筑工程項目管理系統(tǒng)

　　用例應(yīng)該代表外部參與者對于系統(tǒng)的觀點，因此，500,000 sloc 系統(tǒng)的用例就與 5,000 sloc 子系統(tǒng)的用例在完全不同的層次上(Cockburn 97 討論了層次和目標(biāo)的概念);泛普軟件-建筑工程項目管理系統(tǒng)文章

　　用例可能在復(fù)雜性方面不同，編寫時是顯式的，實現(xiàn)時又是隱式的。blog

　　用例應(yīng)該從參與者的角度來描述行為，但是這可能相當(dāng)復(fù)雜，特別是當(dāng)系統(tǒng)具有狀態(tài)時(絕大多數(shù)情況是這樣的)。所以描述這種行為需要系統(tǒng)的模型(在實現(xiàn)它們之前)。當(dāng)試圖捕獲行為本質(zhì)時，這將導(dǎo)致過多的功能分解層次和細(xì)節(jié)。泛普軟件-建筑工程項目管理系統(tǒng)

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

　　其他工作training

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

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

　　那么，我們應(yīng)該不使用用例來估計而依賴于所實現(xiàn)的分析和設(shè)計嗎?這個問題妨礙了做出估計的能力，并且無法滿足已經(jīng)采取該技術(shù)的項目管理者的要求――需要盡早估計并且不得不使用其他方法。對于項目管理者來說，為了做項目規(guī)劃，最好能夠盡早獲得評估，然后反復(fù)對其進行精化，而不是拖延評估并且毫無頭緒地進行工作。泛普軟件-建筑工程項目管理系統(tǒng)

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

　　接下來，我將暫時撇開主題來介紹一些將我引入本文主題的一些背景想法。泛普軟件-建筑工程項目管理系統(tǒng)

　　避免功能分解嗎?泛普軟件-建筑工程項目管理系統(tǒng)