軟件人力成本估算

軟件人力成本估算(一)一、選題目的和意義選題的目的：隨著軟件行業(yè)的逐漸成熟，人們越來越深刻地認(rèn)識到，必須充分理解技術(shù)、方法和有效的應(yīng)用人力資源。軟件估算尤其是成本估算是有效監(jiān)控軟件進(jìn)度的關(guān)鍵部分之一。軟件估算是在軟件開發(fā)和維護(hù)范疇內(nèi)定性、定量估算指標(biāo)的定義、收集、整理、分析和呈報。軟件成本估算顯示了人們對生產(chǎn)率和質(zhì)量深刻的認(rèn)識，是在軟件問題領(lǐng)域綜合應(yīng)用技巧、技術(shù)和方法而取得的成果。對軟件人力成本的估算就是基于項目的規(guī)模、工作量而對人力成本的估算過程。由于軟件本身的特性，很難收集項目的需求和估算。軟件作為概念在早期很難確定規(guī)模，但估算便是要在早期做出來并確定項目的整個過程。估算開始于對項目需求和項目所處的環(huán)境及所作的假設(shè)的理解。然后，軟件規(guī)模要以某種合適的方法進(jìn)行量化處理。得到產(chǎn)品規(guī)模后，工作量以及人力成本的估算便可相應(yīng)得出。選題的意義:通過寫軟件人力成本估算論文使我更加全面的了解和掌握關(guān)于有關(guān)軟件成本估算的知識，并對已有的估算方法提出一些改進(jìn)，并且希望通過這次的實踐來運(yùn)用所學(xué)知識，來培養(yǎng)我的動手能力和合作能力，故選擇軟件人力成本估算作為我的畢業(yè)課題。二、本選題在國內(nèi)外的研究現(xiàn)狀和發(fā)展趨勢有許多用于軟件成本估算的技術(shù)，從早期代碼行估算方法發(fā)展到以后的功能點(diǎn)度量方法。這期間有代表性的方法有MARKII、IBM模型、普特南模型、COCOMO模型等。本文主要對功能點(diǎn)度量方法作了介紹，并且針對功能點(diǎn)度量方法本身的缺陷提出了兩種改進(jìn)措施，一種是使用UML中的用例建模技術(shù)來解決需求的規(guī)范化問題；另一種是擴(kuò)展功能點(diǎn)。擴(kuò)展功能點(diǎn)從功能角度度量軟件的規(guī)模，獨(dú)立于開發(fā)所使用的語言。一旦獲得了用戶功能需求就可以用它來度量規(guī)模。最后本文通過比較幾種軟件成本估算方法的優(yōu)缺點(diǎn)，提出了一種新的軟件成本估算方法：將算法模型、專家小組法和類比估算法結(jié)合起來，互相取長補(bǔ)短，由層次分析法得到各種估算法的權(quán)重，再由權(quán)重合成法得到估算成本。從現(xiàn)在的需求形式來看，該課題的研究會日趨合理，這方面的研究會不斷完善，好的人力成本估算方法應(yīng)該能夠比較準(zhǔn)確的估計出軟件開發(fā)過程中的人力成本。由于估算本身的不確定性，決定了它不可能是百分之百準(zhǔn)確無誤的。但是，估算結(jié)果與實際開發(fā)使用的人力成本的接近程度可以作為判斷估算方法的優(yōu)劣的標(biāo)準(zhǔn)。三、課題設(shè)計方案［主要說明：研究(設(shè)計)的基本內(nèi)容、觀點(diǎn)及擬采取的研究途徑。］研究的基本內(nèi)容：人力成本估算的定義。軟件成本估算中的人力成本。軟件人力成本估算的概述。軟件人力成本估算的規(guī)劃、對象、策略與方法。(5)重要估算方法的描述。(6)對估算方法的改進(jìn)，新方法的提出?；居^點(diǎn)：軟件開發(fā)中的人力成本，是在軟件開發(fā)過程中為了開發(fā)出滿足客戶要求的產(chǎn)品必須為開發(fā)過程中使用的人力資源支付的那一部分資金，它在軟件開發(fā)成本中占相當(dāng)大的一部分。對于這一部分成本的估計也就是人力成本估計。這部分成本的估計，首先要估算出軟件的規(guī)模得出工作量然后根據(jù)當(dāng)前的開發(fā)人員的工資水平估計出人力資源成本。3.方法：理論研究與實踐相結(jié)合，把對這個問題的看法以及所應(yīng)該注意的問題進(jìn)行有效的闡述和分析，得出可行有效的結(jié)果。參考國內(nèi)外已經(jīng)取得的研究成果，認(rèn)真閱讀參考資料。四、計劃進(jìn)度安排[主要說明：起止時間及分階段的進(jìn)度要求。]階段開始時間結(jié)束時間進(jìn)度說明第一階段2006.1上旬2006.2下旬搜集資料，熟悉相關(guān)內(nèi)容，完成畢業(yè)設(shè)計開題報告。第二階段2006.3上旬2006.4下旬對該題目進(jìn)行綜合全面的分析，形成自己的觀點(diǎn)和想法，達(dá)到對該問題的全面了解和掌握。第三階段2006.5上旬2006.5下旬整合匯總，提交每階段都給出應(yīng)的文檔，最后整理提交。五、主要參考文獻(xiàn)[1]RogerS.Pressman,（美）軟件工程實踐者的研究方法.第五版.北京：機(jī)械工業(yè)出版社，2002.⑵SwapnaKishore,RajeshNaik.（?。┸浖枨笈c估算.第一版.北京：機(jī)械工業(yè)出版社，2004.FrederickP.Brooks,Jr.（美）人月神話.第三版.北京：清華大學(xué)出版社，2003.陳松喬，任勝兵，王國軍等.現(xiàn)代軟件工程.第一版.北京：清華大學(xué)出版社，2004.王強(qiáng)，曹漢平，賈素玲，木林森等.IT軟件項目管理.第一版.北京：清華大學(xué)出版社，2004.李幟，林立新，曹亞波等.功能點(diǎn)分析方法與實踐.第一版.北京：清華大學(xué)出版社，2005.指導(dǎo)教師意見及建議摘要：軟件估算，就是結(jié)合目前各種實際情況，提供項目中的軟件規(guī)模、工作量和人力成本的最可能合理的模型。本文主要對功能點(diǎn)度量方法作了介紹，并且針對功能點(diǎn)度量方法本身的缺陷提出了兩種改進(jìn)措施，一種是使用UML中的用例建模技術(shù)來解決需求的規(guī)范化問題；另一種是擴(kuò)展功能點(diǎn)。擴(kuò)展功能點(diǎn)從功能角度度量軟件的規(guī)模，獨(dú)立于開發(fā)所使用的語言。一旦獲得了用戶功能需求就可以用它來度量規(guī)模。最后本文通過比較幾種軟件成本估算方法的優(yōu)缺點(diǎn)，提出了一種新的軟件成本估算方法：將算法模型、專家小組法和類比估算法結(jié)合起來，互相取長補(bǔ)短，由層次分析法得到各種估算法的權(quán)重，再由權(quán)重合成法得到估算成本。關(guān)鍵詞：功能點(diǎn)，擴(kuò)展功能點(diǎn)，用例，用例模型，事務(wù)，用戶功能需求，基本功能塊1引言隨著軟件行業(yè)的逐漸成熟和軟件工程概念的日益深入人心，人們越來越深刻地認(rèn)識到軟件度量的重要性。軟件度量是在軟件開發(fā)和維護(hù)范疇內(nèi)定性、定量度量指標(biāo)的定義、收集、整理、分析和呈報。軟件度量體系顯示了人們對生產(chǎn)率和質(zhì)量深刻的認(rèn)識，是在軟件問題領(lǐng)域，綜合應(yīng)用技巧、技術(shù)和方法而取得的成果。軟件度量的根本目的是通過量化的分析與總結(jié)，幫助我們提高生產(chǎn)率，提高產(chǎn)品質(zhì)量，降低成本和產(chǎn)品研發(fā)周期。從國際上度量活動的典范來看，度量活動給組織和項目所帶來的收益遠(yuǎn)遠(yuǎn)大于度量活動所耗費(fèi)的成本。常用軟件度量包括規(guī)模度量、成本度量、工作量度量、進(jìn)度度量、生產(chǎn)率度量、風(fēng)險度量等，其中對規(guī)模的度量和估算是所有度量活動的基礎(chǔ)，其結(jié)果可作為其它度量的一個主要輸入，因此在軟件度量活動中具有重要地位。其中的人力成本的估計也需要有以上的度量作為前提數(shù)據(jù)。隨著經(jīng)濟(jì)的不斷發(fā)展，現(xiàn)代經(jīng)濟(jì)的經(jīng)濟(jì)結(jié)構(gòu)由以生產(chǎn)型為主向科技服務(wù)型為主的轉(zhuǎn)變已經(jīng)成為一種趨勢。這一轉(zhuǎn)變使得人力資源在企業(yè)生產(chǎn)經(jīng)營和國家經(jīng)濟(jì)發(fā)展中所起的作用變得更為關(guān)鍵。加之國際競爭的日漸激烈亦使得人們對人力資源更加重視起來。人力資源是指在一定區(qū)域內(nèi)的人口總體所具有的勞動能力的總和，是存在于人的自然生命機(jī)體中的一種國民經(jīng)濟(jì)資源。而企業(yè)為獲得人力資源和優(yōu)秀的人才，就需要很多的投資，這種投資在企業(yè)中就體現(xiàn)為人力資源成本。當(dāng)前，科學(xué)技術(shù)突飛猛進(jìn)，信息革命和網(wǎng)絡(luò)經(jīng)濟(jì)使市場呈現(xiàn)全球化趨勢，企業(yè)間的競爭日趨激烈，人才便成為不可或缺的驅(qū)敵制勝的法寶之一。從而，人才、人力資源、人力資源成本、人力資本被提到了新的議程。在過去相當(dāng)一段歷史時期，中國企業(yè)的快速成長和發(fā)展，主要依靠“人海戰(zhàn)術(shù)”和資源的大量投入。而中國經(jīng)濟(jì)發(fā)展到今天，隨著各行業(yè)的平均利潤率越來越低，競爭越來越白熱化，市場空白越來越少。在這種條件下，過去的粗放式人海戰(zhàn)術(shù)由于其管理成本居高不下已經(jīng)走到了盡頭。所以如何從粗放式的人海戰(zhàn)術(shù)到精兵強(qiáng)將就成了一個重要的問題。因為，軟件人力成本估算要以對軟件的規(guī)模估算為基礎(chǔ)，即需要先估算出軟件的規(guī)?；蛘哒f需要先估算出開發(fā)軟件所需要的工作量才能對軟件人力成本做一個估算。因此，我們進(jìn)行軟件人力成本估算就是要在先估算出軟件規(guī)模的基礎(chǔ)上得出對軟件的人力成本的估算。2認(rèn)識軟件估算雖然估算是一門科學(xué)，更是一門藝術(shù)，這個重要的活動不能以隨意的方式來進(jìn)行，因為估算是所有其他項目計劃活動的基礎(chǔ)，而項目計劃又提供了通往成功的軟件工程的道路圖，所以，沒有它我們就會搭錯車。RogerS.Pressman《軟件工程實踐者的研究方法》軟件不同于常見的生活用品。開發(fā)軟件主要用人們的腦子，不需要開工廠，無需原材料，也不需要放到百貨商店的柜臺上銷售。一般地，開發(fā)成本和維護(hù)成本是軟件的主要成本構(gòu)成。除了軟硬件基礎(chǔ)設(shè)施的成本外，人力資源成本占了開發(fā)成本的主要比例。人力資源成本等于雇員的工資乘以工作時間，所以企業(yè)招聘員工的理想狀態(tài)是：以最低的工資招聘恰好滿足工作需要的人。另外，設(shè)法提高工作效率以減少總的開發(fā)時間，從而降低人力資源成本。2.1估算前的規(guī)劃當(dāng)我們的辦公室內(nèi)堆滿了雜亂無章的文件時，恐怕無法知道對于我們真正有用的文件在哪里，當(dāng)我們的軟件項目中收集了各種需求、意見、問題時，我們也很難從中估算出整個項目的規(guī)模、工作量以及成本。因此，在估算之前我們首先要對眾多信息進(jìn)行整理、歸類、分析，從而得到一個條理清晰的項目計劃，在這個計劃提供的框架內(nèi)，才可能開始正確的估算。精心的規(guī)劃是任何一個軟件開發(fā)項目成功與否的關(guān)鍵，有了規(guī)劃就有如成竹在胸，之后無論風(fēng)云變幻，都有應(yīng)對如流的方法。當(dāng)然只有正確的規(guī)劃，才能給軟件開發(fā)指引正確的方向。軟件項目規(guī)劃的重點(diǎn)是對人員角色、任務(wù)進(jìn)度、經(jīng)費(fèi)、設(shè)備資源、工作成果等等做出合適的安排，制定出一些計劃（包括高層的和細(xì)節(jié)的），使大家按照計劃行事，最終順利地達(dá)到預(yù)定的目標(biāo)。2.1.1規(guī)劃的第一步：確定軟件范圍確定軟件范圍，就是確定目標(biāo)軟件的數(shù)據(jù)和控制、功能、性能、約束、接口以及可靠性。這項工作和需求分析是很類似的，如果之前已經(jīng)達(dá)成需求分析規(guī)約，那么可以直接從《需求分析說明書》中把有用的部分拿來使用。如果還沒有開始需求分析，關(guān)于確定軟件范圍的方法方面，我們可以采用許多需求分析技術(shù)（如需求誘導(dǎo)），從客戶那里得到一個具體的軟件范圍。當(dāng)然如果是一次全新的軟件邊界探索，就應(yīng)當(dāng)考慮軟件本身可行性問題，包括團(tuán)隊是否具備在技術(shù)、財務(wù)、時間、資源上有可靠的保障，軟件本身在市場上是否有可靠的競爭優(yōu)勢，等等。獲得軟件范圍，最直接最可靠的來源就是用戶對軟件的需求描述。2.1.2規(guī)劃的第二步：確定工作所需資源軟件工作所需資源包括：工作環(huán)境（軟硬件環(huán)境、辦公室環(huán)境）、可復(fù)用軟件資源（構(gòu)件、中間件）、人力資源（包括各種不同角色的人員：分析師、設(shè)計師、測試師、程序員、項目經(jīng)理……）。這三種資源的組成比例，可以看作一個金字塔的模式，最上面是人力資源、其次是可復(fù)用軟件資源、最下面是工作環(huán)境。最上面的是組成比例最小的，最下面的是組成比例最大的部分。（1）人力資源一個項目到底需要多少種職務(wù)的人員構(gòu)成、多少數(shù)量的人員總量，才能成為最有創(chuàng)造力的團(tuán)隊呢？這恐怕是最讓項目經(jīng)理頭疼的事情了。任何一個軟件工程，都必須在確定軟件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任務(wù)。在這之前，不能盲目地進(jìn)行人力擴(kuò)充，而且絕對不能為了給公司抬高門面，盲目招收高學(xué)歷。（2）可復(fù)用軟件資源這是一個容易在計劃階段被忽視的重要資源，很多人總是進(jìn)入編碼階段才發(fā)現(xiàn)可復(fù)用資源的價值和存在。經(jīng)過長期的項目積累或是購買，公司的軟件資源庫中或許已經(jīng)積累了大量的可復(fù)用資源，但在當(dāng)前任務(wù)中，只能選擇有價值的資源。（3）環(huán)境資源“工欲善其事，必先利其器”，要得到高效的開發(fā)過程，就必須向工作人員提供良好的軟硬件環(huán)境，包括開發(fā)工具、開發(fā)設(shè)備、工作環(huán)境、管理制度。一般管理人員都會購買可以滿足需要的軟件開發(fā)工具和硬件平臺，但是工作環(huán)境和管理制度往往被忽視。站在人員的角度看，向工作人員提供更輕松自在、安靜舒適的辦公環(huán)境的公司，員工往往比整天在狹小隔間中工作的公司員工產(chǎn)生更高的工作效率。而那些擁有靈活人性化的管理制度的公司，比整天加班的公司更能留住高技術(shù)的人才。所以如何在有限資金中，規(guī)劃一個合理的環(huán)境是很重要的事情。2.2估算的對象目前為止，一個較為準(zhǔn)確的軟件項目估算的定義是：在給定公差范圍內(nèi)，對于要開發(fā)的軟件規(guī)模的預(yù)測，以及對開發(fā)軟件所需的工作量、成本和日歷事件的預(yù)測。這個概念指出了一個事實，即估算是一種大約的估計，是將誤差限定在一定范圍內(nèi)的估計。估算主要包括以下幾個重要內(nèi)容：（1）規(guī)模估算軟件估算首先要將整個工程的規(guī)模估算出來，才能進(jìn)行下面的其他估算。規(guī)模，就是一個工程可量化的結(jié)果，是用具體數(shù)字來體現(xiàn)項目的描述。規(guī)模估算的信息來源是清晰、有界限的用戶需求。（2）工作量估算這是對開發(fā)軟件所需的工作時間的估算，它和進(jìn)度估算一起決定了開發(fā)團(tuán)隊的規(guī)模和構(gòu)建。通常以人時、人天、人月、人年的單位來衡量，這些不同單位之間可以進(jìn)行合理的轉(zhuǎn)換。（3）進(jìn)度估算進(jìn)度時項目自始至終之間的一個時間段。進(jìn)度以不同階段的里程碑作為標(biāo)志。進(jìn)度估算是針對以階段為單位的估算，而不是對每一個細(xì)小任務(wù)都加以估算，對任務(wù)的適當(dāng)分解很重要，分解得越細(xì)反而會不準(zhǔn)確。因為任何一個軟件工程，在各個方面都有與生俱來的不確定性。（4）成本估算包括人力、物質(zhì)、有形的、無形的支出成本估算，其中以人力成本為主要部分。比較容易被忽視的是學(xué)習(xí)成本、軟件培訓(xùn)成本、人員變動風(fēng)險成本、開發(fā)延期成本等，一些潛在成本消耗。2.3估算的策略在軟件估算的眾多方法中，存在著“自頂向下”和“自底向上”等幾種不同的策略，這幾種策略的出發(fā)點(diǎn)不同，適應(yīng)于不同的場合使用。自頂向下、自底向上和差別估算法。自頂向下的方法是對整個項目的總開發(fā)時間和總工作量做出估算，然后把它們按階段、步驟和工作單元進(jìn)行分配；自底向上的方法是分別估算每個工作單元所需的開發(fā)時間，然后匯總得出總的工作量和開發(fā)時間；差別估算是將開發(fā)項目與一個或多個已完成的類似項目進(jìn)行比較，找出與某個類似項目的若干不同之處，并估算每個不同之處對成本的影響，導(dǎo)出開發(fā)項目的總成本。2.3.1自頂向下的策略這是一種站在客戶的角度來看問題的策略。它總是以客戶的要求為最高目標(biāo)，任何估算結(jié)果都必須符合這個目標(biāo)。其工作方法是，由項目經(jīng)理為主的一個核心小組根據(jù)客戶的要求，確定一個時間期限，然后根據(jù)這個期限，將任務(wù)分解，將開發(fā)工作進(jìn)行對號入座，以獲得一個估算結(jié)果。當(dāng)然由于這完全是從客戶要求出發(fā)的策略，而由于軟件工程是一個綜合項目，幾乎沒有哪個項目能完全保質(zhì)保量按照預(yù)定工期完工，那么這樣一個策略就缺少了許多客觀性。但是由于這樣完成的估算比較容易被客戶，甚至被項目經(jīng)理所接受，在許多公司我們看到這樣一個并不科學(xué)的策略仍然被堅定地執(zhí)行著。2.3.2自底向上的策略與自頂向下的策略完全相反，自底向上的策略是一種從技術(shù)、人性的角度出發(fā)看問題的策略。在這樣一個策略指引下，將項目充分討論得到一個合理的任務(wù)分解。再將每個任務(wù)依照任務(wù)的難易程度與項目成員的特點(diǎn)、興趣、特長進(jìn)行分配，并按要求進(jìn)行估算。最后將估算加起來就是項目的估算值。顯然自底向上的這種策略具有較為客觀的特點(diǎn)，但是它的缺點(diǎn)就是這樣一來項目工期就和客戶的要求不一致了。而且由于其帶來的不確定性，許多項目經(jīng)理也不會采用這種方法。2.4估算的方法顯然估算是建立在客觀實際上，對未來盡可能合理的一種預(yù)測。那么估算本身的不確定性，決定了它不可能是百分之百準(zhǔn)確無誤的。在項目剛開始時，人們對產(chǎn)品需求、技術(shù)、市場預(yù)期、人員素質(zhì)等因素的了解還遠(yuǎn)遠(yuǎn)不夠，在這種情況下人們很難做出準(zhǔn)確的估計。但是依據(jù)某種方法進(jìn)行估計顯然比瞎猜好得多。軟件規(guī)模度量和估算的根本目的是通過量化的分析與總結(jié)，提高軟件項目的生產(chǎn)率、提高產(chǎn)品質(zhì)量、降低成本和產(chǎn)品研發(fā)周期，盡可能的減少因錯誤估算給企業(yè)帶來的損失。軟件項目的規(guī)模估算和度量歷來是比較復(fù)雜的事，因為軟件本身的復(fù)雜性、歷史經(jīng)驗的缺乏、估算工具缺乏以及一些人為錯誤，導(dǎo)致軟件項目的規(guī)模估算往往和實際情況相差甚遠(yuǎn)。估算錯誤已被列入軟件項目失敗的四大原因之一。因此對軟件項目如何進(jìn)行準(zhǔn)確的規(guī)模評估研究是一個重要而迫切的問題。良好的規(guī)模度量方法應(yīng)該滿足以下幾點(diǎn)準(zhǔn)則：1）規(guī)模度量的有效性與程序開發(fā)所要求的時間緊密相關(guān)。2）規(guī)模度量必須精密，但不一定精確。3）應(yīng)該能夠自動計量。4）應(yīng)該能夠反映各種影響開發(fā)成本的環(huán)境狀況。5）在規(guī)模度量和計數(shù)中能夠反映新建、復(fù)用、刪除、修改的代碼以及它們的組合。6）度量必須在整個開發(fā)過程中隨時能夠應(yīng)用。7）應(yīng)對于各種類型的產(chǎn)品元素都能應(yīng)用。常見的一些元素類型包括程序源代碼、文檔、報告、菜單、文件等等，但這一點(diǎn)要求非常難以實現(xiàn)。估算方法有很多，大致分為基于分解的技術(shù)和基于經(jīng)驗?zāi)Ｐ蛢纱箢?。基于分解的技術(shù)的方法包括功能點(diǎn)估算法、LOC估算法、MARKII等；基于經(jīng)驗?zāi)Ｐ偷姆椒ò↖BM模型、普特南模型、COCOMO模型等。分解技術(shù)：當(dāng)一個待解決的問題過于復(fù)雜時，可以進(jìn)一步將其分解，直到分解后的問題容易解決為止。然后分別解決這些分解后的問題，通過綜合其解答得到原有問題的解答。這是處理復(fù)雜問題的最自然的方法。FP功能點(diǎn)估算法功能點(diǎn)估算法是一種在需求分析階段基于系統(tǒng)功能的一種規(guī)模估計方法。通過研究初始應(yīng)用需求來確定各種輸入、輸出、計算和數(shù)據(jù)庫需求的數(shù)量和特性。這種方法的計算公式是：功能點(diǎn)=信息處理規(guī)模X技術(shù)復(fù)雜度。信息處理規(guī)模包括各種輸入、輸出、查詢、內(nèi)部邏輯文件數(shù)、外部接口文件數(shù)等等；技術(shù)復(fù)雜度包括性能復(fù)雜度、配置項目復(fù)雜度、數(shù)據(jù)通信復(fù)雜度、分布式處理復(fù)雜度、在線更新復(fù)雜度等等。LOC估算法這是一種從技術(shù)的角度來估算的方法總稱，其中又包含許多方法。這類方法以代碼（LOC）作為軟件工作量的估算單位，在早期的系統(tǒng)開發(fā)中較為廣泛使用。LOC是指所有的可執(zhí)行的源代碼行數(shù)，包括可交付的語句、數(shù)據(jù)定義、數(shù)據(jù)類型聲明、等價聲明、輸入/輸出格式聲明等。一代碼行（1LOC）的價值和人月均代碼行數(shù)可以體現(xiàn)一個軟件生產(chǎn)組織的生產(chǎn)能力，開發(fā)組織可以根據(jù)對歷史項目的審計來核算組織的單行代碼價值。基于LOC的估算，既有優(yōu)點(diǎn)也有缺點(diǎn)。優(yōu)點(diǎn)在于方便計算、容易監(jiān)控、能反映程序員的思維能力；缺點(diǎn)在于代碼行數(shù)的含糊不清，不能正確反映一項工作的難易程度以及代碼的效率。因此在傳統(tǒng)的LOC方法進(jìn)行了許多改進(jìn)。其中不斷被使用，且不斷演化的方法包括以下：PERT功能點(diǎn)估算法：PERT對各個項目活動的完成時間按三種不同情況估計：一個產(chǎn)品的期望規(guī)模，一個最低可能估計，一個最高可能估計。用這三個估計用來得到一個產(chǎn)品期望規(guī)模和標(biāo)準(zhǔn)偏差的Pert統(tǒng)計估計，Pert估計可得到代碼行的期望值和標(biāo)準(zhǔn)偏差SD。類比估算法：類比法適合評估一些與歷史項目在應(yīng)用領(lǐng)域、環(huán)境和復(fù)雜度的相似的項目，通過新項目與歷史項目的比較得到規(guī)模估計。類比法估計結(jié)果的精確度取決于歷史項目數(shù)據(jù)的完整性和準(zhǔn)確度，因此，用好類比法的前提條件之一是組織建立起較好的項目評價與分析機(jī)制，從而使對歷史項目的數(shù)據(jù)分析是可信賴的。Delphi估算法：Delphi法是一種專家評估技術(shù)，在沒有歷史數(shù)據(jù)的情況下，這種方式適用于評定過去與將來，新技術(shù)與特定程序之間的差別。對于需要預(yù)測和深度分析的領(lǐng)域，依賴于專家的技術(shù)指導(dǎo)，可以獲得較為客觀的估算。通過專家們的互相討論，還可以博取眾長。系統(tǒng)分解：將系統(tǒng)分成若干個易于用LOC估算的部分，將其各個估算結(jié)果累加就是LOC的總規(guī)模。其中關(guān)鍵是建立起SBS（系統(tǒng)分解結(jié)構(gòu)），它描述了系統(tǒng)的不同組件。SBS還被使用在其他重要的地方，如系統(tǒng)設(shè)計、系統(tǒng)分析等。在進(jìn)行分解的時候，可以采用自由討論的形式，可以獲得更合理的SBS構(gòu)成。LOC和FP是兩個不同的估算技術(shù)。但兩者有許多共同特性。項目計劃人員首先給出一個有界的軟件范圍的敘述，再由此敘述把軟件分解成一些小的可分別獨(dú)立進(jìn)行估算的子功能。然后對每一個子功能估算其LOC或FP（即估算變量）。接著，把生產(chǎn)率度量（如LOC/PM或FP/PM）用做特定的估算變量，導(dǎo)出子功能的成本或工作量。將子功能的估算進(jìn)行綜合后就能得到整個項目的總估算。LOC或FP估算技術(shù)對于分解所需要的詳細(xì)程度是不同的。當(dāng)用LOC作為估算變量時，功能分解是絕對必要的且需要達(dá)到很詳細(xì)的程度。而估算功能點(diǎn)所需要的數(shù)據(jù)是宏觀的量，當(dāng)把FP當(dāng)作估算變量時所需要的分程度不很詳細(xì)。應(yīng)注意，LOC可直接估算，而FP要通過估計輸入、輸出、數(shù)據(jù)文件、查詢和外部接口的數(shù)目間接地確定。項目計劃人員可對每一個分解的功能提出一個有代表性的估算值范圍。利用歷史數(shù)據(jù)或憑實際經(jīng)驗，對每個功能分別按最佳的、可能的、悲觀的三種情況給出LOC或FP估計值，記作a、m、b。當(dāng)這些值的范圍被確定之后，也就隱含地指明了估計值的不確定程度，然后計算LOC或FP的期望值E。E=（a+4m+b）/6（加權(quán)平均）一旦確定了估算變量的期望值，就可以用作LOC或FP的生產(chǎn)率數(shù)據(jù)。工作量估算是估算任何工程開發(fā)項目成本的最普遍使用的技術(shù)。每一個項目任務(wù)的解決都需要花費(fèi)若干人日、人月或人年，每一個工作量單位都對應(yīng)于一定的貨幣成本，從而可以由此做出成本估算。類似于LOC或FP技術(shù)，工作量估算開始于從軟件項目范圍抽出軟件功能，接著給出為實現(xiàn)每一功能所必須執(zhí)行的一系列軟件工程任務(wù)，包括需求分析、設(shè)計、編碼和測試。最后，計算每一個功能及軟件項目的工作量和成本。將工作量估算與LOC估算得到的結(jié)果進(jìn)行比較，如果結(jié)果一致則估算是可靠的，否則有必要做進(jìn)一步的檢查與分析。IBM模型估算法該模型是Watson和Felix在1977年發(fā)布的，是基于IBM聯(lián)合系統(tǒng)分布負(fù)責(zé)的60個項目的總結(jié)而得到的模型。該模型是一個靜態(tài)模型，而參考數(shù)據(jù)只有60多個項目，因此有很大的局限性。1977年，Watson和Felix總結(jié)了IBM的60個項目數(shù)據(jù)，提出了如下的估算公式：E=5.2XL0.91，L是源代碼行數(shù)（以KLOC計），E是工作量（以PM計）D=4.1XL0.36=2.4XE0.35，D是項目持續(xù)時間（以月計）S=0.54XE0.6，S是人員需要量（以人計）DOC=49XL1.01，DOC是文檔數(shù)量（以頁計）COCOMO估算法Boehm在其經(jīng)典著作“軟件工程經(jīng)濟(jì)學(xué)”（softwareengineeringeconomics）中，介紹了一種軟件估算模型的層次體系，稱為COCOMO（構(gòu)造性成本模型，ConstructiveCostModel），它代表了軟件估算的一個綜合經(jīng)驗?zāi)Ｐ?。它是一種精確的、易于使用的成本估算方法，它分為基本COCOMO模型和中級COCOMO模型兩種類型?；綜OCOMO模型是一個靜態(tài)單變量模型，它用一個已估算出來的源代碼行數(shù)（LOC）為自變量的經(jīng)驗函數(shù)來計算軟件開發(fā)工作量。中間COCOMO模型則在用LOC為自變量的函數(shù)計算軟件開發(fā)工作量的基礎(chǔ)上，再用涉及產(chǎn)品、硬件、人員、項目等方面屬性的影響因素來調(diào)整工作量的估算。更詳細(xì)的COCOMO模型除了包括中間COCOMO模型的所有特性外，還考慮了在需求分析、軟件設(shè)計等每一步的影響。COCOMO模型是適用于三種類型的軟件項目：（1）組織模式一一較小的、簡單的軟件項目，有良好應(yīng)用經(jīng)驗的小型項目組，針對一組不是很嚴(yán)格的需求開展工作（如，為一個熱傳輸系統(tǒng)開發(fā)的熱分析程序）;（2）半分離模式一一中等的軟件項目（在規(guī)模和復(fù)雜性上），具有不同經(jīng)驗水平的項目組必須滿足嚴(yán)格的及不嚴(yán)格的需求（如，一個事務(wù)處理系統(tǒng)，對于終端硬件和數(shù)據(jù)庫軟件有確定需求）；（3）嵌入模式一一必須在一組嚴(yán)格的硬件、軟件及操作約束下開發(fā)的軟件項目（如，飛機(jī)的航空控制系統(tǒng)）。軟件方程式估算法軟件方程式是一個多變量模型，它假設(shè)在軟件開發(fā)項目的整個生命周期中的一個特定的工作量分布。該模型是從4000多個當(dāng)代的軟件項目中收集的生產(chǎn)率數(shù)據(jù)中導(dǎo)出的公式。初期的方程式較為復(fù)雜，通過，Putnam和Myers的努力又提出一組簡化的方程式。當(dāng)然這種方法也是基于長期的參考數(shù)據(jù)的積累而得到的。WBS估算法這是一種基于WBS（工作任務(wù)分解）的方法，即先把項目任務(wù)進(jìn)行合理的細(xì)分，分到可以確認(rèn)的程度，如某種材料、某種設(shè)備、某一活動單元等。然后估算每個WBS要素的費(fèi)用。采用這一方法的前提條件或先決步驟是：對項目需求做出一個完整的限定。制定完成任務(wù)所必需的邏輯步驟。編制WBS表。項目需求的完整限定應(yīng)包括工作報告書、規(guī)格書以及總進(jìn)度表。工作報告書是指實施項目所需的各項工作的敘述性說明，它應(yīng)確認(rèn)必須達(dá)到的目標(biāo)。如果有資金等限制，該信息也應(yīng)包括在內(nèi)。規(guī)格書是對工時、設(shè)備以及材料標(biāo)價的根據(jù)。它應(yīng)該能使項目人員和用戶了解工時、設(shè)備以及材料估價的依據(jù)?？傔M(jìn)度表應(yīng)明確項目實施的主要階段和分界點(diǎn)，其中應(yīng)包括長期定貨、原型試驗、設(shè)計評審會議以及其他任何關(guān)鍵的決策點(diǎn)。如果可能，用來指導(dǎo)成本估算的總進(jìn)度表應(yīng)含有項目開始和結(jié)束的日歷時間。除了以上介紹的幾種方法外，還有一些其他的方法：類比估算、推測估算、Standard-component估算法、普特南估算法等。類推估算法是比較科學(xué)的一種傳統(tǒng)估算方法，它適合評估一些與歷史項目在應(yīng)用領(lǐng)域、環(huán)境和復(fù)雜度的相似的項目，通過新項目與歷史項目的比較得到規(guī)模估計。類推估算法估計結(jié)果的精確度取決于歷史項目數(shù)據(jù)的完整性和準(zhǔn)確度，因此，用好類推估算法的前提條件之一是組織建立起較好的項目后評價與分析機(jī)制，使得對歷史項目的數(shù)據(jù)分析是可信賴的。這種方法的基本步驟是：整理出項目功能列表和實現(xiàn)每個功能的代碼行；標(biāo)識出每個功能列表與歷史項目的相同點(diǎn)和不同點(diǎn)，特別要注意歷史項目做得不夠的地方;通過步驟1和2得出各個功能的估計值；產(chǎn)生規(guī)模估計。當(dāng)然不同的方法適用于不同的具體環(huán)境，有些方法雖然很好但并不一定適合當(dāng)前的任務(wù)。只有量體裁衣，具體問題具體分析，才能得到盡量合理的估算。3重點(diǎn)方法詳述及功能點(diǎn)擴(kuò)展改進(jìn)方法以上是對軟件估算的綜述，以下我們重點(diǎn)討論功能點(diǎn)估算方法，并針對其缺點(diǎn)提出兩種改進(jìn)措施，在最后還會結(jié)合算法模型法、專家小組法和類比估算法提出一種新的度量策略。規(guī)模是軟件的一個重要屬性，是成本估計和生產(chǎn)率分析的重要參數(shù)，對于軟件開發(fā)和軟件項目管理而言，在開發(fā)的早期進(jìn)行規(guī)模估計的要求都很迫切。但這時有關(guān)軟件的信息還很少，沒有編碼可供度量，因此出現(xiàn)了試圖從功能角度度量規(guī)模的功能點(diǎn)FP(functionpoints)0但是，功能點(diǎn)固有的缺陷與不足限制了它的使用。在此提出的擴(kuò)展功能點(diǎn)EFP(extendedFP)從根本上解決了功能點(diǎn)方法的缺陷。在此將系統(tǒng)地討論擴(kuò)展功能點(diǎn)模型，這是對功能點(diǎn)方法的第一種改進(jìn)策略。3.1功能點(diǎn)Albrecht于1979年提出了功能點(diǎn)，以求在開發(fā)的早期度量軟件的規(guī)模，而后又于1983年改進(jìn)了功能點(diǎn)，使的功能點(diǎn)由5個功能分量和一批調(diào)整因子組成。這5個功能分量分別是外部輸入￡【、外部輸出EO、外部接口文件EIF、內(nèi)部邏輯文件ILF和查詢EQ。5個功能分量的加權(quán)累加就是未調(diào)整的功能點(diǎn)，再應(yīng)用14個調(diào)整因子可得到調(diào)整的功能點(diǎn)。本文討論的功能點(diǎn)就是1983年Albrecht改進(jìn)的功能點(diǎn)。1986年，SPR改進(jìn)功能點(diǎn)后得到特征點(diǎn)(featurepoints)，使其適用于非信息處理領(lǐng)域。1994年，波音公司提出了3維功能點(diǎn)---3DFP，即所謂的三維是指數(shù)據(jù)、功能處理和控制。3.2功能點(diǎn)存在的問題雖然功能點(diǎn)已取得了廣泛的應(yīng)用，但細(xì)心的研究會發(fā)現(xiàn)它存在如下一些問題：功能點(diǎn)的應(yīng)用領(lǐng)域具有一定的局限性。功能點(diǎn)主要是針對信息處理系統(tǒng)而設(shè)計的，因此其應(yīng)用領(lǐng)域有很大的局限性。功能點(diǎn)度量元素不完整，或者說度量元素的概念間存在重疊。功能點(diǎn)定義系統(tǒng)的用戶輸入為維護(hù)ILF的EI和不維護(hù)ILF的輸入（簡記為UI）兩類。功能點(diǎn)明確指出要計算EI,但并沒有明確指出要計算UI,只是在計算EQ時提到。這說明可能根本不計算UI，使得功能點(diǎn)度量元素在概念上不完整；也可能是在計算EQ的同時計算了UI，這說明UI是EQ的一個組成部分，因此，功能點(diǎn)元素概念間有重疊。（3）功能點(diǎn)中ILF和EIF的定義不清晰，不便于實際操作。什么是文件？什么是數(shù)據(jù)的邏輯組？這使得ILF和EIF的定義模糊。（4）實際上往往無法得知某一個外部輸入是否出自于另一個系統(tǒng)的內(nèi)部邏輯文件。功能點(diǎn)定義EIF必須同時又是另一個應(yīng)用系統(tǒng)的ILF，而實際上這往往無法驗證。（5）查詢被定義為一個處理，卻被描述為一個事務(wù)。功能點(diǎn)把外部查詢定義為一個映射（I,O）對，也就是一個功能處理，可實際查詢時卻被描述為事務(wù)。擴(kuò)展功能點(diǎn)EFP擴(kuò)展功能點(diǎn)EFP從功能點(diǎn)角度度量軟件的規(guī)模，獨(dú)立于開發(fā)所使用的語言，一旦獲得了用戶功能需求FUR（functionaluserrequirements），就可以用它來度量規(guī)模。下面先討論功能規(guī)模度量的特征，然后分析EFP的問題域模型，并從問題域模型中獲得EFP的基本功能塊BFC（basefunctionalcomponent）類型，同時給出各個BFC類型的定義和度量方法，最后介紹EFP計算模型。3.4功能規(guī)模度量ISO/IEC14143是有關(guān)功能規(guī)模度量FSM（functionalsizemeasurement）的標(biāo)準(zhǔn)，它用于評價某種規(guī)模度量方法是否為FSM方法，該標(biāo)準(zhǔn)要求一個FSM方法滿足：基于用戶功能需求FUR度量軟件的規(guī)模；一旦得到了FUR，就可以應(yīng)用它來度量規(guī)模；通過對BFC的評價可以得到軟件的功能規(guī)模。BFC是FSM方法基于用戶功能需求FUR定義的基本單元，它具有以下特征：-只描述FUR；-不描述任何有關(guān)技術(shù)需求的信息；-不描述任何有關(guān)質(zhì)量需求的信息；-任何一個BFC都可以被識別為一個BFC類型，并且只能識別為一個類型。3.5EFP問題域模型FSM方法從功能角度來度量軟件的規(guī)模，因此，EFP的問題域就是軟件的用戶功能。軟件對于用戶就是一個黑盒，而用戶關(guān)心的是軟件需要用戶提供哪些輸入，同時能為用戶返回哪些輸出，軟件就是一個把用戶輸入轉(zhuǎn)換成用戶輸出的機(jī)構(gòu)，其中用戶輸入和用戶輸出都是由用戶定義的，因此轉(zhuǎn)換功能也是由用戶定義的。有些用戶輸入對于用戶具有特殊的意義，用戶希望軟件能夠?qū)⑦@些數(shù)據(jù)保存起來，以便更好地實現(xiàn)用戶提出的功能。這些數(shù)據(jù)，我們可稱為用戶數(shù)據(jù)實體，雖然保存在軟件的內(nèi)部，但卻是由用戶提供的，因而由用戶維護(hù)和使用。由于用戶數(shù)據(jù)實體直接與用戶輸入、用戶輸出和用戶功能相關(guān)，因此它對于軟件規(guī)模的影響將不能被忽略。這樣，我們最終得到EFP問題域的4個元素---用戶輸入、用戶輸出、用戶功能和用戶數(shù)據(jù)實體。為了有效的識別用戶和軟件之間的關(guān)系，我們?yōu)檐浖x一個概念邊界。由此，用戶輸入就是穿過邊界去往軟件的輸入，用戶輸出就是穿過邊界去往用戶的軟件輸出。同理，根據(jù)計算機(jī)科學(xué)理論，用戶功能就是用戶輸入到用戶輸出的映射，為便于后面的討論，我們將用戶輸入和用戶輸出更名為外部輸入和外部輸出，所謂“外部”是相對于這個概念邊界而言的。這樣，我們就得到了如圖1和式（1）所示的EFP問題域模型。4第二種改進(jìn)方法以上是擴(kuò)展功能點(diǎn)方法對功能點(diǎn)度量法的改進(jìn)，下面再介紹一種針對中國軟件企業(yè)普遍存在需求規(guī)格說明書不規(guī)范、實施功能點(diǎn)分析非常困難的實際情況，在此提出了一種改進(jìn)方法，使用UML技術(shù)中的用例來生成規(guī)范的需求規(guī)格說明書，利用用例進(jìn)行功能點(diǎn)分析。用例模型是對用戶功能需求規(guī)范化的描述。通過全面定義用例模型，可以把用戶對系統(tǒng)的功能需求，用比較規(guī)范的形式準(zhǔn)確地表達(dá)出來。功能點(diǎn)可以認(rèn)為是系統(tǒng)用例，系統(tǒng)用例模型是從業(yè)務(wù)用例模型和業(yè)務(wù)對象模型中提取出來的。業(yè)務(wù)對象模型提供對每個業(yè)務(wù)用例的實現(xiàn)，每個業(yè)務(wù)用例是一個業(yè)務(wù)的需求，解決一個業(yè)務(wù)問題或提供一個業(yè)務(wù)機(jī)遇。功能點(diǎn)的完整性實際上就是保證用戶確認(rèn)的業(yè)務(wù)問題得到解決，業(yè)務(wù)機(jī)遇得到獲取的滿足程度。需求規(guī)格說明書應(yīng)該列出所有的系統(tǒng)用例，如果這些系統(tǒng)用例達(dá)到了上述要求，這個用例列表就是要“提煉”的功能點(diǎn)列表。4.1先介紹功能點(diǎn)的優(yōu)缺點(diǎn)使用功能點(diǎn)分析具有以下優(yōu)點(diǎn)：1）規(guī)模可在項目初期確定；2）可作為度量生產(chǎn)率改進(jìn)的基準(zhǔn)；3）獨(dú)立于開發(fā)工具和環(huán)境，因而可用于衡量各種工具和環(huán)境下的生產(chǎn)率；4）提供各個項目間一致的規(guī)模度量方法。其缺點(diǎn)是：1）FPA的使用在RET和GSC的估算上是主觀的，因其主觀性使估算結(jié)果因人而異。2）FPA假設(shè)全部是部分的和，也就是說，分解系統(tǒng)的功能性，分別估算，然后用他們的和來反映整個系統(tǒng)。但事實并非如此，這也是任何分解法的弊端。一個復(fù)雜的系統(tǒng)采用的分析方法應(yīng)比其各部分的和復(fù)雜得多，因為需要考慮各部分的集成。3）對復(fù)雜度重視不夠。程序處理邏輯可能包含復(fù)雜的算法和計算，這可能耗費(fèi)大量工作量而且隱含復(fù)雜度。該方法極其重視用戶所見所得，而用戶接觸不到的邏輯處理的復(fù)雜度和所需工作量都被低估了，因為他們對用戶來講是不可見的。4）FPA只把復(fù)雜度粗略的分成三種類型（簡單、一般、復(fù)雜），這種描述過于簡單，也丟失一些細(xì)節(jié)。雖然粗略分類使這種方法簡單易用，但很不準(zhǔn)確，因為忽略了同一類型的較高端和較低端之間的差別。5）這種方法在區(qū)分簡單、一般、復(fù)雜類型的界線是極不妥當(dāng)?shù)?，只要增加一個條目就能使整個系統(tǒng)的估算值變化很多。另一方面，它也很難擴(kuò)展，因為對于無論多細(xì)的類別其最高復(fù)雜度的權(quán)重都是一樣的（所有分類的最高等級都是公開的）。6）功能點(diǎn)不是實際的規(guī)模度量，它是在簡化系統(tǒng)基礎(chǔ)上的靜態(tài)度量，它取決于分類的定義以及這些定義如何解釋，這也是確定功能點(diǎn)計算的定義和解釋。與代碼行方法相比，功能點(diǎn)度量最大的優(yōu)勢就是可以在項目的早期進(jìn)行規(guī)模度量和估算。理論上，只要有了詳盡的需求規(guī)格說明書，就能夠準(zhǔn)確地估算出項目的規(guī)模。但是在實踐中我們發(fā)現(xiàn)，在需求階段進(jìn)行功能點(diǎn)度量存在很大困難，主要包括以下幾個方面1）需求規(guī)格說明書不規(guī)范。在國內(nèi)許多軟件企業(yè)中，軟件開發(fā)過程中的需求分析往往被當(dāng)作一個可有可無的步驟而不受重視，甚至許多項目根本就不做需求分析，直接進(jìn)入設(shè)計階段。同時，絕大多數(shù)的開發(fā)人員都沒有受過與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的教育。另外，也很難找到好的需求可以借鑒學(xué)習(xí)。盡管大多數(shù)的開發(fā)都采用了典型場景的方法，但它極少用有效的形式歸檔。造成有許多項目根本沒有需求說明書，有的項目為了應(yīng)付客戶的要求，采取軟件開發(fā)完畢后補(bǔ)寫需求說明書的手段。雖然有些企業(yè)比較重視軟件工程，在設(shè)計之前形成了需求說明書，但內(nèi)容極不規(guī)范，這就給項目的規(guī)模度量和估算帶來極大困難，也嚴(yán)重影響后續(xù)的成本和工作量度量，極易造成項目失控。2）功能分解隨意性較大。由于沒有統(tǒng)一的規(guī)定和約束，在進(jìn)行功能點(diǎn)度量時如何進(jìn)行功能分解，成為制約功能點(diǎn)度量的準(zhǔn)確性和客觀性的一個主要方面。對同一個項目，不同的度量人員往往會得出相差甚遠(yuǎn)的不同結(jié)果。主要原因就在于功能分解的完整性和不重復(fù)性很難把握，如何從需求分析說明書中準(zhǔn)確提煉出系統(tǒng)的全部功能，并且保證在計算時沒有重復(fù)計算，在實際操作中存在很大困難。4.2下面介紹一種利用UML建模技術(shù)對功能點(diǎn)度量模型的改進(jìn)方法針對以上問題，提出一種改進(jìn)方法，即使用UML中的用例建模技術(shù)來解決功能需求的規(guī)范化問題，這樣，功能點(diǎn)可以認(rèn)為是系統(tǒng)用例，需求規(guī)格說明書中建立的用例列表就是要“提煉”的功能點(diǎn)列表。通過用例進(jìn)行功能點(diǎn)分析是因為二者有內(nèi)在的聯(lián)系，功能點(diǎn)是從需求的角度度量軟件規(guī)模，而用例是捕獲需求的方法。功能點(diǎn)和用例都試圖實現(xiàn)與軟件的具體實現(xiàn)技術(shù)的無關(guān)性，用例可以驗證提交的設(shè)計是否包含了所有的需求，用例的另一個優(yōu)點(diǎn)是用例可以在生命周期的早期定義需求。如果用例很早就產(chǎn)生出來，然后進(jìn)行功能點(diǎn)度量，對項目的估算和度量值就會精確得多。功能點(diǎn)分析將系統(tǒng)分解成更小的部件，以便用戶、開發(fā)人員、項目經(jīng)理能夠更好地理解系統(tǒng)功能。用例同樣采用了分解的方法，而且用例方法也是從用戶實際使用系統(tǒng)的角度捕獲需求，與系統(tǒng)如何實現(xiàn)這些功能無關(guān)。這就意味著通過用例形成的需求文檔可以用于功能點(diǎn)分析(規(guī)模度量)。使用用例方法，可以在項目生命周期的早期準(zhǔn)確度量規(guī)模，從而就能更好地估算和度量進(jìn)度以及成本。另外，如果用例保持更新，功能點(diǎn)分析也保持更新，那么對項目進(jìn)行的估算和度量也就可以容易地進(jìn)行更新并對變更進(jìn)行說明。Meli曾經(jīng)提出，用例己經(jīng)變成一個捕獲用戶需求的一般方法，因為用例是從用戶的角度描述功能，他們應(yīng)該很容易轉(zhuǎn)換成功能點(diǎn)。但他沒有給出具體的方法，而且對什么樣的用例可以用于功能點(diǎn)分析也沒有涉及。本文詳細(xì)闡述用例如何形成需求，并且提出了只有系統(tǒng)用例才適合用于功能點(diǎn)分析的觀點(diǎn)。4.2.1UML簡介：UML是統(tǒng)一建模語言的縮寫，是三位最優(yōu)秀的面向?qū)ο蠓椒▽W(xué)的創(chuàng)始人Rumbaugh,Booch和Jacobson合作成果的結(jié)晶。UML在己有的三大面向?qū)ο蠓椒▽W(xué)的基礎(chǔ)上，抽象出表示它們的模型語言，并吸取了其它面向?qū)ο箝_發(fā)方法和近30年軟件工程的成果。1997年11月被批準(zhǔn)成為面向?qū)ο箝_發(fā)的行業(yè)標(biāo)準(zhǔn)語言。到目前為止，UML已獲得了工業(yè)界、科技界和應(yīng)用界的廣泛支持，成為可視化建模語言事實上的工業(yè)標(biāo)準(zhǔn)。UML是一種通用的可視化建模語言，它支持面向?qū)ο蟮姆治鲈O(shè)計和從需求分析開始的軟件開發(fā)的全過程。UML的概念及模型可以分成以下幾類：靜態(tài)結(jié)構(gòu)UML的靜態(tài)結(jié)構(gòu)描述了系統(tǒng)中的結(jié)構(gòu)成員及其相互關(guān)系。系統(tǒng)的結(jié)構(gòu)成員即類元，包括類、用例、構(gòu)件和節(jié)點(diǎn)，為研究系統(tǒng)動態(tài)行為奠定了基礎(chǔ)。靜態(tài)視圖包括類圖、用例圖、構(gòu)件圖和部署圖。動態(tài)行為動態(tài)行為描述了系統(tǒng)隨時間變化的行為。動態(tài)行為又分為兩種:一種是一個孤立對象的工作流程及狀態(tài)的變化，對應(yīng)的視圖分別為活動圖和狀態(tài)機(jī)圖；另一種是一系列相關(guān)對象之間交互作用時的通信，交互視圖包括順序圖和協(xié)作圖。模型組織管理模型組織管理說明了模型的分層組織結(jié)構(gòu)。包是模型的基本組織管理單元，用于存儲、訪問控制、配置管理及構(gòu)造包含可重用的模型單元庫。模型的組織管理用類圖來實現(xiàn)，但又跨越了其它視圖并根據(jù)系統(tǒng)開發(fā)和配置組織這些視圖。包之間的依賴關(guān)系是對包的組成部分之間的依賴關(guān)系的歸納，系統(tǒng)整個架構(gòu)可以在包之間施加依賴關(guān)系。因此，包的內(nèi)容必須符合包的依賴關(guān)系和有關(guān)的架構(gòu)要求。(4)擴(kuò)展機(jī)制UML還包括多種具有擴(kuò)展能力的組件，這些組件的擴(kuò)展能力有限但很有用。這些組件包括約束、構(gòu)造型和標(biāo)記值，它們適用于所有的視圖元素。4.2.2用例(UseCase)用例模型(Usecasemodel)長期以來，在傳統(tǒng)的軟件開發(fā)和面向?qū)ο箝_發(fā)中，人們根據(jù)典型的使用情景來了解需求。但是，這些使用情景是非正式的，雖然經(jīng)常使用，卻難以建立正式文檔。用例模型由IvarJacobson在開發(fā)AXE系統(tǒng)中首先使用，并加入由他所倡導(dǎo)的DOSE和Objectory方法中。用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注。自1994年IvarJacobson的著作出版后，面向?qū)ο箢I(lǐng)域己廣泛接納了用例這一概念，并認(rèn)為它是第二代面向?qū)ο蠹夹g(shù)的標(biāo)志。用例模型抽述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表明了開發(fā)者和用戶對需求規(guī)格達(dá)成的共識。首先，它描述了待開發(fā)系統(tǒng)的功能需求；其次，它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來理解系統(tǒng)；第三，它驅(qū)動了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn)，而且被用于驗證和檢測所開發(fā)的系統(tǒng)，從而影響到開發(fā)工作的各個階段和UML的各個模型。在UML中，一個用例模型由若干個用例圖描述，用例圖主要元素是用例和執(zhí)行者。用例(usecase)從本質(zhì)上講，一個用例是用戶與計算機(jī)之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創(chuàng)建一個索引”便是兩個典型的用例。在UML中，用例被定義成系統(tǒng)執(zhí)行的一系列動作，動作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到。概括地說，用例有以下特點(diǎn)：八、、.?用例捕獲某些用戶可見的需求，實現(xiàn)一個具體的用戶目標(biāo)。?用例由執(zhí)行者激活，并提供確切的值給執(zhí)行者。?用例可大可小，但它必須是對一個具體的用戶目標(biāo)實現(xiàn)的完整描述。⑶執(zhí)行者(Actor)執(zhí)行者是指用戶在系統(tǒng)中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多營銷人員，但就該系統(tǒng)而言，他們均起著同一種作用，扮演著相同的角色，所以用一個執(zhí)行者表示。一個用戶也可以扮演多種角色執(zhí)行者)。例如，一個高級營銷人員既可以是貿(mào)易經(jīng)理，也可以是普通的營銷人員；一個營銷人員也可以是售貨員。在處理執(zhí)行者時，應(yīng)考慮其作用，而不是人或工作名稱，這一點(diǎn)是很重要的。不帶箭頭的線段將執(zhí)行者與用例連接到一起，表示兩者之間交換信息，稱之為通信聯(lián)系。執(zhí)行者觸發(fā)用例，并與用例進(jìn)行信息交換。單個執(zhí)行者可與多個用例聯(lián)系；反過來，一個用例可與多個執(zhí)行者聯(lián)系。對同一個用例而言，不同執(zhí)行者有著不同的作用，他們可以從用例中取值，也可以參與到用例中。需要注意的是，盡管執(zhí)行者在用例圖中是用類似人的圖形來表示的，但執(zhí)行者未必是人。例如，執(zhí)行者也可以是一個外界系統(tǒng)，該外界系統(tǒng)可能需要從當(dāng)前系統(tǒng)中獲取信息，與當(dāng)前系統(tǒng)有進(jìn)行交互。通過實踐，我們發(fā)現(xiàn)執(zhí)行者對提供用例是非常有用的。面對一個大系統(tǒng)，要列出用例清單常常是十分困難。這時可先列出執(zhí)行者清單，再對每個執(zhí)行者列出它的用例，問題就會變得容易很多。(4)使用和擴(kuò)展(UseandExtend)還有另外兩種類型的連接，用以表示用例之間的使用和擴(kuò)展關(guān)系。使用和擴(kuò)展是兩種不同形式的繼承關(guān)系。當(dāng)一個用例與另一個用例相似，但所做的動作多一些，就可以用到擴(kuò)展關(guān)系。例如基本的用例是“進(jìn)行交易”。交易中可能一切都進(jìn)行得很順利，但也可能存在擾亂順利進(jìn)行交易的因素。其中之一便是超出某些邊界值的情況。例如，貿(mào)易組織會對某個特定客戶規(guī)定最大貿(mào)易量，這時不能執(zhí)行給定用例提供的常規(guī)動作，而要做些改動。我們可在“泊7交易”用例中做改動。但是，這將把該用例與一大堆特殊的判斷和邏輯混雜在一起，使正常的流程晦澀不堪。將常規(guī)的動作放在“進(jìn)行交易”用例中，而將非常規(guī)的動作放置于“超越邊界的交易”用例中，這便是擴(kuò)展關(guān)系的實質(zhì)。當(dāng)有一大塊相似的動作存在于幾個用例，又不想重復(fù)描述該動作時，就可以用到使用關(guān)系。例如，現(xiàn)實中風(fēng)險分析和交易估價都需要評價貿(mào)易，為此可單獨(dú)定義一個用例，即“評價貿(mào)易”，而“風(fēng)險分析”和“交易估價”用例將使用它。請注意擴(kuò)展與使用之間的相似點(diǎn)和不同點(diǎn)。它們兩個都意味著從幾個用例中抽取那些公共的行為并放入一個單獨(dú)用例中，而這個用例被其他幾個用例使用或擴(kuò)展。但使用和擴(kuò)展的目的是不同的。4.2.3實現(xiàn)步驟：用例捕獲用戶需求（1）捕獲執(zhí)行者利用UML的技術(shù)進(jìn)行功能需求分析時，第一步要做的是確定系統(tǒng)有哪些執(zhí)行者。獲取用例首先要找出系統(tǒng)的執(zhí)行者，這可以通過用戶對開發(fā)方所提的一些問題的答案來確定。以下問題可供參考：.誰將要提供、使用或修改信息？.誰將用到這些功能？.誰對某些需求感興趣？.系統(tǒng)將交付哪個部門使用？.誰將負(fù)責(zé)對系統(tǒng)的支持和維護(hù)？.哪些是系統(tǒng)的外部資源？.要與系統(tǒng)進(jìn)行交互的其它系統(tǒng)有哪些？（2）捕獲用例執(zhí)行者確定后，下一步的工作是捕獲用例。同樣，開發(fā)方也是通過提出問題的方法來獲取用例。不同的是，這一次的問題主要由執(zhí)行者來回答。主要的問題如下：.執(zhí)行者要求系統(tǒng)提供哪些功能（執(zhí)行者需要做什么）？.執(zhí)行者需要讀、產(chǎn)生、刪除、修改或存儲哪些信息、？.執(zhí)行者要通知系統(tǒng)突發(fā)的、外部的事件有哪些？.系統(tǒng)要通知執(zhí)行者的事件有哪些？.執(zhí)行者是否要負(fù)責(zé)系統(tǒng)的啟動和關(guān)閉？還有一些不針對具體執(zhí)行者問題（即針對整個系統(tǒng)的問題）。.系統(tǒng)需要何種輸入/輸出?輸入從何處來?輸出到何處？.當(dāng)前運(yùn)行系統(tǒng)（也許是一些手工操作而不是計算機(jī)系統(tǒng)）的主要問題？.已定義的用例集是否已包括系統(tǒng)的所有功能?需要注意的是：最后兩個問題并不是指沒有執(zhí)行者也可以有用例，只是獲取用例時尚不知道執(zhí)行者是什么。一個用例必須至少與一個執(zhí)行者關(guān)聯(lián)。還需要注意的是，不同的設(shè)計者對用例的利用程度也不同。重要的是：在捕獲用例時，心中一直所想的應(yīng)該是系統(tǒng)要做什么，而不是系統(tǒng)應(yīng)該怎么做。2、建立用例模型用例模型是使用UML進(jìn)行功能需求分析的最終結(jié)果，是以用例圖的方式來顯示的。用例模型表示了系統(tǒng)與外界環(huán)境的交互及系統(tǒng)的主要功能。在這個階段，為了畫出用例圖，可以考慮開發(fā)界面原型以定義邊界。在用例圖中，除了標(biāo)志執(zhí)行者與用例之間的聯(lián)系外，還要標(biāo)志用例之間的關(guān)系。3、利用用例建立需求規(guī)格說明書用例模型有兩種基本風(fēng)格：業(yè)務(wù)用例模型和系統(tǒng)用例模型。業(yè)務(wù)用例模型，通常稱為基本或抽象用例模型，對行為需求的與技術(shù)無關(guān)的視圖建模。而系統(tǒng)用例模型，也稱為具體用例模型或詳細(xì)用例模型，為行為需求的分析建模，詳細(xì)描述用戶將如何使用系統(tǒng)，同時它還提及系統(tǒng)用戶接口方面的問題。在建立需求規(guī)格說明書的過程中，用例模型要經(jīng)過由基本模型向系統(tǒng)模型的轉(zhuǎn)換，它是分步驟、分層次的，大致過程如下表7:表7需求細(xì)化級別步驟需求業(yè)務(wù)需求最初很低級別的用例界面規(guī)格說明書引入界面綁定時的級別更多細(xì)節(jié)更多級別上的用例完整的詳細(xì)規(guī)格說明書用例的最終級別由表中可以看出，在建立需求規(guī)格說明書的過程中，用例的粒度級別是逐漸細(xì)化的。也就是說，首先編寫業(yè)務(wù)用例作為所需的構(gòu)思工作的一部分，然后在分析期間，將它們發(fā)展成系統(tǒng)用例。4、系統(tǒng)用例還是業(yè)務(wù)用例？下面對系統(tǒng)用例和業(yè)務(wù)用例進(jìn)行對比分析。二者有以下一些區(qū)別：系統(tǒng)用例嵌入了很多細(xì)節(jié)。系統(tǒng)用例提及屏幕和報告。因為業(yè)務(wù)規(guī)則反映系統(tǒng)必須實現(xiàn)的域的基本特征，所以兩種版本都引用業(yè)務(wù)規(guī)則定義。系統(tǒng)用例的步驟比業(yè)務(wù)用例的步驟多。實際上，每個用例步驟應(yīng)該只反映一個步驟。這樣做有幾個優(yōu)點(diǎn)：用例更容易測試，因為每條語句都更加容易理解和驗證；用例更加容易編寫，因為當(dāng)語句只做一件事時更容易簡單描述。用例步驟以主動語態(tài)、而不是以被動語態(tài)編寫。兩個版本都以類似“用例結(jié)束”或“在某些情況下用例結(jié)束”的步驟結(jié)束，以表示己經(jīng)完全定義了操作過程的邏輯。通過以上的區(qū)別可以看出，如果以業(yè)務(wù)用例進(jìn)行功能點(diǎn)分析，就可能丟失一些細(xì)節(jié)。因此，根據(jù)業(yè)務(wù)用例進(jìn)行功能點(diǎn)分析無法保證功能點(diǎn)分析的功能完整性。另外，使用業(yè)務(wù)用例還會因為級別太低導(dǎo)致無法確定各種事務(wù)（EI,E0,EQ）或文件（ILF,EIF）的DET,RET或FTR數(shù)，從而無法確定功能復(fù)雜度，導(dǎo)致功能點(diǎn)分析無法進(jìn)行。系統(tǒng)用例既提供了比業(yè)務(wù)用例更多的細(xì)節(jié)，又因為它將系統(tǒng)當(dāng)作黑盒，不描述任何內(nèi)部結(jié)構(gòu)，并且只使用問題域的語言，因此需求分析所得到的系統(tǒng)用例列表可以看作功能點(diǎn)分析中的事務(wù)功能列表，此時用系統(tǒng)用例來進(jìn)行功能點(diǎn)的分析是比較合適的。5、利用用例確定系統(tǒng)功能點(diǎn)數(shù)得到以系統(tǒng)用例形式的表達(dá)的需求規(guī)格說明書以后，就可以利用用例確定系統(tǒng)的功能點(diǎn)數(shù)了以下僅介紹引進(jìn)用例概念后不同的部分。（1）確定應(yīng)用程序邊界：用例方法和功能點(diǎn)分析方法的第一個步驟都是確定系統(tǒng)邊界。邊界代表系統(tǒng)及其執(zhí)行者之間的接口，邊界可能是一個用戶界面，也可能是對其它系統(tǒng)的一次調(diào)用。這二種方法對系統(tǒng)邊界的定義非常相似，功能點(diǎn)方法將邊界定義為所度量軟件和用戶之間的界限。功能點(diǎn)方法中使用了“用戶”這個術(shù)語，而在用例方法中則使用了“執(zhí)行者”，二者實際上是等同的。（2）確定事務(wù)和文件：IFPUG功能點(diǎn)定義了五種主要部件（事務(wù)和文件），以下是在采用用例方法后對這些定義的修訂：1）事務(wù):事務(wù)由一個或多個事件流進(jìn)行定義。一個用例可能有一個或多個事務(wù)。一個系統(tǒng)用例對應(yīng)一個事務(wù)。輔助場景有助于澄清事務(wù)。事務(wù)包括外部輸入、外部輸出和外部查詢。外部輸入(EI)：是數(shù)據(jù)從外向內(nèi)跨越邊界流動的一個基本處理。數(shù)據(jù)來自系統(tǒng)執(zhí)行者，執(zhí)行者能夠增加、改變、刪除內(nèi)部邏輯文件ILF)中的信息。數(shù)據(jù)既可以是控制信息，也可以是數(shù)據(jù)信息。如果數(shù)據(jù)是控制信息，那么就不必維護(hù)一個ILF的外部輸出(EO)：是派生數(shù)據(jù)從內(nèi)向外跨越邊界流動的一個基本處理。數(shù)據(jù)傳送給系統(tǒng)執(zhí)行者，執(zhí)行者能夠更新內(nèi)部邏輯文件(LF)。數(shù)據(jù)創(chuàng)建發(fā)送給其它執(zhí)行者的報表或輸出文件。這些報表和文件利用一個或多個ILF和EIF中包含的信息進(jìn)行創(chuàng)建。外部查詢(EQ)：是既具有輸入部件，又具有輸出部件的一個基本處理，執(zhí)行者能夠從一個或多個ILF和EIF中檢索數(shù)據(jù)。輸入處理不會更新和維護(hù)任何FTR(ILF或EIF)，輸出處理則不包含派生數(shù)據(jù)。2)文件：內(nèi)部邏輯文件(ILF)：用戶可識別確認(rèn)的一組邏輯上相關(guān)的數(shù)據(jù)，全部駐留在應(yīng)用程序邊界內(nèi)部，通過外部輸入進(jìn)行維護(hù)。外部接口文件(EIF):用戶可識別確認(rèn)的一組邏輯上相關(guān)的數(shù)據(jù)，只能用于外部引用，數(shù)據(jù)全部駐留在應(yīng)用程序邊界外部，通過另一個應(yīng)用程序的外部輸入進(jìn)行維護(hù)。外部接口文件是另一個應(yīng)用程序的內(nèi)部邏輯文件。EIF和工LF的主要區(qū)別是EIF由另一個應(yīng)用程序進(jìn)行維護(hù)。6、用例進(jìn)行功能點(diǎn)估算的實例下面以一個簡單的實例對上述步驟進(jìn)行一下演示：員工查詢系統(tǒng)功能描述：員工查詢系統(tǒng)是一個用于從員工信息數(shù)據(jù)庫中請求查詢信息的應(yīng)用程序，它也允許用戶變更員工信息數(shù)據(jù)庫中的信息。普通用戶可以查詢員工信息數(shù)據(jù)庫并可以修改自己的信息。系統(tǒng)管理員可以查詢、修改、添加或者刪除員工記錄。員工信息包括基本信息、職位信息以及部門信息，其中基本信息包括工號、姓名、電話、E-mail、身份證號碼、傳真，職位信息包括職位編碼、職位名稱，部門信息包括部門編碼、部門名稱、辦公地點(diǎn)。捕獲執(zhí)行者本系統(tǒng)比較簡單，執(zhí)行者只有普通用戶和系統(tǒng)管理員二種。捕獲用例用例包括：查詢記錄、修改記錄、添加記錄、刪除記錄，其中修改、添加和刪除記錄時都需要進(jìn)行身份驗證，所以還有一個身份驗證用例。建立用例模型用例模型包括用例圖和用例描述，用例圖由執(zhí)行者(Actor)、用例(UseCase)、系統(tǒng)邊界、箭頭組成，用畫圖的方法來完成。用例描述用來詳細(xì)描述用例圖中每個用例，用文本文檔來完成。為了畫出用例圖，首先開發(fā)界面原型以定義邊界和劃分功能點(diǎn)要素。我們來定義程序的主窗口:主窗口用于數(shù)據(jù)錄入和數(shù)據(jù)檢索，包括菜單條、員工信息、職位信息、部門信息、員工清單列表框等。我們可以看出，系統(tǒng)至少包含3個ILF，分別對應(yīng)基本信息(員工文件)、職位信息(職位文件)和部門信息(部門文件)。(5)確定未調(diào)整事務(wù)功能點(diǎn)本例有5個事務(wù)，分別對應(yīng)用例圖中的5個用例，即查詢記錄(EQ)，修改記錄(EI)，添加記錄(EI)、刪除記錄(EI)、安全驗證(EQ)。查詢記錄(EQ)包含11個DET(工號、姓名、電話、E-mail、身份證號碼、傳真、職位編碼、職位名稱、部門編碼、部門名稱、辦公地點(diǎn)，3個FTR(員工文件、職位文件、部門文件)，復(fù)雜度為中。修改記錄(EI)包含9個DET(工號、姓名、電話、E-mail、身份證號碼、傳真、職位編碼、部門編碼、提示信息)，4個FTR(員工文件、職位文件、部門文件、安全文件)，復(fù)雜度為高。添加記錄(EI)包含9個DET(工號、姓名、電話、E-mail、身份證號碼、傳真、職位編碼、部門編碼、提示信息)，4個FTR(員工文件、職位文件、部門文件、安全文件，復(fù)雜度為高。刪除記錄EI)包含3個DET(工號、確認(rèn)信息、提示信息），2個FTR（員工文件、安全文件），復(fù)雜度為低。安全驗證（EQ）包含6個DET（員工號、安全級別、用戶名、密碼、驗證次數(shù)、提示信息、），1個FTR（安全文件），復(fù)雜度為低。未調(diào)整數(shù)據(jù)功能點(diǎn)為:3+4+4+3+1=15（6）確定未調(diào)整功能點(diǎn)數(shù)為:38+15=53（7）確定值調(diào)整因子:為簡便起見，本例取VAF=1（8）確定調(diào)整后的功能點(diǎn)數(shù)為:53X1=53用例模型是對用戶功能需求規(guī)范化的描述。通過全面定義用例模型，可以把用戶對系統(tǒng)的功能需求，用比較規(guī)范的