第1章軟件功能點度量方法概述

第1章軟件功能點度量方法概述本章介紹軟件項目開發(fā)與維護所面臨的典型問題，指出解決這些問題的基本途徑是軟件項目的定量評價分析。在比較了各種軟件定量評價方法的基礎上建議采用功能點方法作為軟件定量評價的基礎方法。本章進一步介紹目前被ISO標準采納的5種功能點標準，依次是MarkII功能點標準、COSMIC功能點標準、NESMA功能點標準、FISMA功能點標準以及IFPUG功能點標準。本章還對5種功能點標準的不同之處進行了比對分析并給出了建議。1.1軟件困境軟件在我們生活和工作中的重要性正與日俱增。試想，沒有銀行軟件系統(tǒng)和證券軟件平臺的應用，龐大復雜的銀行業(yè)務便不能有效地開展，證券業(yè)務也只能局限于現(xiàn)場交易，因而不能發(fā)揮其應有的金融職能；沒有網絡管理軟件系統(tǒng)的應用，快捷的電話聯(lián)系方式也是不可想象的；除了目前已經廣泛應用的固定電話和移動電話業(yè)務之外，更有如雨后春筍般出現(xiàn)的各種數據服務，例如寬帶上網、GPS定位導航等，而這些應用無一例外地依賴于各種軟件系統(tǒng)。軟件應用對于很多行業(yè)的發(fā)展變革甚至起決定的作用，例如基于網絡的傳媒信息更多地取代了傳統(tǒng)的紙質媒體，人們的閱讀習慣因而發(fā)生了有史以來最重要的變化。由此可見，軟件無論在我們的生活還是工作中已經變得不可或缺。軟件以其快捷、高效、經濟等諸多優(yōu)勢幾乎滲透到各個行業(yè)中，正是軟件的普及應用塑造了信息時代的主要特征。因為軟件應用的互通互聯(lián)，因特網時代之前的“信息孤島”正日益消亡，伴隨著世界范圍內各種經濟、科技和教育等方面的信息共享，“地球村”的預言正成為現(xiàn)實。具有諷刺意味的是，軟件在促進信息共享、信息透明的同時，自身卻存在典型的“燈下黑”現(xiàn)象。與傳統(tǒng)的建筑等行業(yè)相比較，軟件系統(tǒng)的建設與開發(fā)充滿了各種不確定性。用戶業(yè)務需求不明確、工期和費用設置的盲目性、開發(fā)團隊不穩(wěn)定、人員的工作經驗和技術水平參差不齊、“作坊式”開發(fā)模式等諸多因素使得軟件開發(fā)往往達不到預期的目的。軟件開發(fā)與建設對客戶來說更多地呈現(xiàn)為“黑盒子”特征。實際開發(fā)出的軟件系統(tǒng)往往差強人意，用戶在使用中抱怨不斷，不能真正滿足客戶的要求。具體表現(xiàn)為所提交的軟件系統(tǒng)功能與用戶期望的需求差異過大、工期嚴重拖延、費用超支明顯、質量問題層出不窮等現(xiàn)象。導致出現(xiàn)以上問題的原因紛繁復雜，但究其主要原因，則是因為軟件系統(tǒng)的建設與開發(fā)的過程中管理不善所致。大量的實踐表明有效的軟件項目管理是改善和提高軟件系統(tǒng)建設與開發(fā)效率的主要途徑。要對軟件項目進行有效的管理，首先得了解軟件項目的特點。與傳統(tǒng)行業(yè)相比較，軟件項目具備以下三個重要特點。（1）前期業(yè)務需求不清，導致項目執(zhí)行過程中需求頻繁變更。對于大部分軟件項目，開發(fā)團隊在啟動軟件需求分析之前都無法獲取明確的需求。例如對于一個電子政務項目而言，前期可能只會給出該項目的定位，例如“通過將現(xiàn)有手工業(yè)務轉變?yōu)檐浖蔚碾娮恿鞴ぷ鞣绞剑嵘ぷ餍?，并對現(xiàn)有的業(yè)務模式進行合理優(yōu)化”?？墒侨绾螌@樣籠統(tǒng)的項目要求進行細化，并將其轉變?yōu)橄鄳能浖枨笠?guī)格，軟件開發(fā)團隊還面臨著各種挑戰(zhàn)。首先是獲取單一部門內的業(yè)務流程，現(xiàn)有的業(yè)務流程可能本身就存在不合理或者沖突的情形，需要需求分析人員與業(yè)務人員進一步討論才能確定。如果涉及到部門之間的業(yè)務流程，其困難程度還會進一步加大，因為不同部門的人員都傾向于站在自己的立場來考慮問題，所以部門之間的業(yè)務流程確定往往還需要領導的強力參與。伴隨著組織業(yè)務流程的調整，通常意味著部門和人員的重新定位，有時甚至影響相關人員的切身利益，此時的需求分析將會面臨更大的阻力。除了來自業(yè)務部門本身的挑戰(zhàn)外，業(yè)務人員與技術人員的溝通也存在明顯的障礙，即客戶與技術開發(fā)方對業(yè)務需求的理解不一致?？蛻舴降臉I(yè)務人員通常認為自己對業(yè)務需求的表述清楚無誤，而開發(fā)方卻覺得業(yè)務人員語焉不詳，并沒有將業(yè)務的來龍去脈交待清楚。不少項目在各方對于需求的理解還未達成一致的情況下就開始項目，結果項目是邊做邊改，等到項目臨近結束時，需求已“面目全非”，與雙方前期確定的需求相差甚遠。試想，一棟大樓或一座大橋在還未確定功能或結構的前提下就開始動工，然后在施工的過程中再根據用戶的要求不斷變更，將會出現(xiàn)什么樣的結果？結果很可怕，所以沒人做這樣的嘗試。但軟件項目不然，環(huán)顧我們身邊的軟件項目，有多少項目真正能夠做到“謀定而后動”呢？正是軟件需求的脆弱性和易變性導致了軟件項目的失控。（2）項目目標失控，明顯超出客戶心理預期。所有的軟件項目在初期都會設置相應的管理目標，包括項目所要實現(xiàn)的功能、項目工期、項目預算以及項目的質量目標等。可是在項目開發(fā)的過程中卻發(fā)現(xiàn)這些目標無異于“海市蜃樓”，可望而不可及。大部分軟件項目或多或少地表現(xiàn)出下列特征：要么是“種瓜得豆”，要求的功能大幅縮水；要么是項目工期嚴重滯后，影響客戶業(yè)務的正常運行；或者項目嚴重超支，軟件開發(fā)商雖然投入了額外的人力物力，但客戶并不領情；更有甚者，雖然軟件系統(tǒng)勉強按時上線，但后續(xù)的質量問題卻層出不窮，“摁下葫蘆浮起瓢”，永遠有解決不完的問題。既然上述問題是目前軟件項目所面臨的共性問題，那么單一地將其歸屬為軟件開發(fā)商的責任似乎有失公允。設想這樣的場景：如果對一個小學班級進行數學測驗，孩子們最后的平均成績?yōu)?分（考試采用百分制）。30分的平均成績說明什么呢？首先孩子們的數學知識學得不夠好，怎么才考30分呢？其次，數學測驗題目有問題，為孩子們設置了過高的目標要求（學生家長往往更傾向于這種結論）。對軟件項目而言，也存在類似的現(xiàn)象。所以在抱怨軟件開發(fā)商工作績效的同時，客戶似乎也應該進行自我反省，客戶要求的目標合理嗎？我國現(xiàn)在大部分的軟件項目均采用招投標的方式來選擇供應商，再加上在國內的軟件行業(yè)中普遍存在“買方市場”的特點，許多軟件開發(fā)商都存在“先拿到合同再說”這樣的心理，故而往往對于客戶所提的各種要求都滿口應承，即使認為客戶設置的項目目標不合理，也往往忍氣吞聲、委曲求全①也有一些軟件開發(fā)組織與客戶簽署合同之前，對于客戶單方面設定的目標會提出不同的建議，例如更為合理的工期、成本與質量目標等，但這些建議對于客戶往往缺乏足夠的說服力。因為大多數軟件開發(fā)組織并沒有一個明確的、量化的過程可以向客戶表明自己所建議目標的客觀性、合理性，代之以“根據我們的經驗”、“參照我們以前的項目”等說法，因而缺乏說服力，最終只能接受客戶方設置的項目目標。但軟件項目最終的結果卻讓客戶追悔莫及，油然而生“早知如今，何必當初”的感嘆。所以如何為客戶設定合理的項目目標至關重要。（3）軟件項目的成功過度依賴個人，缺乏來自組織的過程保證。成熟與不成熟的軟件開發(fā)組織相比較，其最大差異在于兩者的可預期性。不成熟的軟件開發(fā)組織往往傾向于過度承諾，而實際開發(fā)過程中卻經常面臨捉襟見肘的困境：要么是工期嚴重滯后，要么是成本超支，工期若能勉強得到保證，通常即意味著質量風險。而高成熟度組織所做出的承諾通?？梢缘玫秸鎸嵉膬冬F(xiàn)。在不成熟的軟件開發(fā)組織內，更多地采用“游擊隊”、“個人英雄主義”的開發(fā)模式，在項目中甚至沒有采用相應的軟件配置管理平臺，更沒有進行軟件項目計劃與跟蹤、軟件項目質量評價等相應的管理措施。這種“作坊式”的開發(fā)模式導致軟件開發(fā)的最終結果主要取決于個人因素，而組織對軟件項目的管理與控制則力不從心，只能寄希望于員工在工作中一直表現(xiàn)出認真、負責、任勞任怨的態(tài)度。如果出現(xiàn)項目經理或項目組成員離職等情形，對軟件開發(fā)的影響通常是致命的，新加入的人員不得不從頭再將前任的工作完成一遍。軟件開發(fā)是一項群體的智力活動，軟件開發(fā)過程是否高效、開發(fā)團隊工作是否工作在同一基礎之上、個人的工作成果能否完全融合到項目中等因素對于成功的軟件開發(fā)至關重要，而要保證軟件團隊工作的有效性，來自軟件開發(fā)組織的過程管理則必不可少。適用于軟件開發(fā)的典型過程管理模型包括ISO9000模型、CMMI模型和RUP模型等，而在這些模型中無一例外地強調了過程度量的重要性。正是通過過程度量，我們才能評價當前工作的好與壞、正常還是異常、是否需要采取糾正措施或補救措施等?！叭速F有自知之明”被許多人奉為人生的圭臬，可是許多軟件開發(fā)組織卻缺乏“自知之明”，項目組的產出如何？組織的開發(fā)績效如何？對開發(fā)過程中生成的需求或技術文檔質量狀況是否滿意？對類似的問題許多組織往往會采用“還行”、“不錯”、“我們有信心”等模棱兩可的說法來搪塞，因為組織根本就沒有數據。基于以上分析，目前軟件項目管理所面臨的困境可以歸結為三個“說不清”：需求說①作為某些人的處世哲學，這種態(tài)度無可厚非。但用于軟件項目目標的設置則弊端叢生，因為不負責任的承諾常常會害人又害己。不清；目標說不清；過程說不清。要做什么不清楚，做到什么程度不清楚，中間過程也說不清，這樣的項目做出的軟件可想而知會是什么結果。說不清首先和軟件本身的特點相關，從客觀角度分析可能包含兩方面的原因：首先，軟件不同于其他的有形產品，很多時候難以去想象最終的產品究竟是什么樣子；其次，軟件的開發(fā)過程主要表現(xiàn)為人們的智力活動，表現(xiàn)為建立模型、編寫文檔和代碼調試等可見性較低的活動形式。所以上述兩類原因導致人們對軟件不容易“說清楚”。除了客觀方面的原因外，可能也有來自人員本身的主觀原因。現(xiàn)在各行各業(yè)都在倡導“定量化”的管理模式，對于軟件行業(yè)也應該引入定量管理的理念，可為什么在國內的軟件開發(fā)組織中真正采用定量管理模式的組織卻少之又少呢？第一，可能是由于思維慣性?！拔覀円恢倍际沁@么跟著感覺走，也沒出啥大問題嘛”，不愿意主動提升和優(yōu)化現(xiàn)有的軟件開發(fā)過程。第二，和我們的傳統(tǒng)文化有關。如果采用定量管理的辦法使得大家的工作都透明化，是否組織中的每個人都喜歡看到這樣的結果？中國的傳統(tǒng)文化強調中庸，強調“水至清則無魚”，你把賬算那么清楚，犯得著嗎？所以我們看到在各個國家審計部門都不是一個受歡迎的部門，他們總是拿著數據報告要別人解釋自己的行為或結果。在軟件項目中采用定量評價的方式雖不至于產生類似經濟領域的“審計風暴”，但迫使人們在事后要關注自己的行為，有時甚至還需要為自己的行為進行解釋。在潛意識里，人們希望自己在工作中的束縛和來自外部的檢查盡可能的少。因而在軟件開發(fā)組織中引入定量管理評價機制通常是不受歡迎的，甚至會遭到抵制。因為存在這樣那樣的原因，所以我們國家的軟件開發(fā)現(xiàn)狀在最近5年、甚至最近10年并沒有發(fā)生明顯的變化①雖然我們的軟件行業(yè)表現(xiàn)得朝氣蓬勃，但我們的沉淀和積累仍然不足。如果我們對現(xiàn)狀不滿，那就必須做出改變。如何改變？在軟件開發(fā)過程中引入定量管理評價方法則是必不可少的一個主要步驟，而定量評價方法的基礎則是軟件項目規(guī)模的評價。如果能夠在軟件項目管理過程中引入基于功能點度量方法的規(guī)模評估，則有助于我們做到“需求說清楚”、“目標說清楚”和“過程說清楚”。1.2軟件規(guī)模評價方法為什么說軟件規(guī)模評價是軟件量化管理的基礎？在實際的軟件開發(fā)項目中我們好像更關注工期、成本和質量。軟件規(guī)模、工期、成本以及質量之間存在什么樣的關系以及如何對這些關系進行定量表述是軟件項目量化管理的主要內容。在介紹這些依賴關系之前，有必要首先建立“和諧項目管理”理念。對一個軟件項目而言，在項目中會設置4個最主要的目標，即項目范圍、項目時間、項目成本以及項目質量。它們4者之間相互影響、相①甚至于軟件開發(fā)組織中的人員平均年齡也是如此，10年前的軟件開發(fā)組織人員平均年齡大概為二十六七歲，10年后的平均年齡依然如此。

圖1.1軟件項目管理三角形互依賴，如圖1.1圖1.1軟件項目管理三角形也許有些讀者還記得若干年前我們國家的一句政治口號：“多快好省地建設社會主義”，這種提法的出發(fā)點是好的，但忽視了經濟建設的內在規(guī)律，最終導致了“大躍進”的局面，對中國經濟的健康發(fā)展造成很大的傷害。即使在我們大力倡導科學發(fā)展觀的今天，仍然有不少客戶和領導希望軟件項目完成的功能越多越好、工期越快越好、成本越低越好、質量越高越好，豈不是“多快好省”模式在軟件行業(yè)的完全翻版？我們應該從錯誤的做法中汲取經驗和教訓，而不是重蹈覆轍。我們現(xiàn)在的社會和經濟發(fā)展強調“和諧”理念，對于軟件項目管理也要遵循“和諧”的管理模式。概言之，即要完成的軟件功能有多少，就應該設置多長的工期，就應該設定多少預算，就應該設置相應的質量目標，而不是一味求快貪多，置客觀事務的內在聯(lián)系于不顧。正如其他傳統(tǒng)行業(yè)的定量評價機制一樣，項目的工期、成本和質量目標的設置主要取決于項目所要完成的工作內容①例如修建鐵路的成本與工期主要取決于道路的長度；辦公大樓的建設費用與工期則主要取決于建筑面積。所以要在軟件項目管理過程中引入量化評價機制，對于軟件規(guī)模本身的評價則是首要任務。只有確定了軟件規(guī)模，才能得到其他的項目管理目標；只有預先設定了項目目標，定量管理才有執(zhí)行的依據。根據軟件行業(yè)的實踐，目前評價軟件規(guī)模的方法可以區(qū)分為兩種評價方法：非標準評價方法和標準評價法。非標準評價方法具有操作簡單、容易實施等特點，但不容易在項目干系人之間達成一致，往往會引起較多的分歧；標準評價法則較好地克服了非標準評價方法的不足，但因為其操作相對繁瑣，很多情形下甚至需要外部咨詢機構的輔導，因而在實際應用中也受到一定程度的限制。1.2.1非標準評價方法與軟件規(guī)模標準評價方法相比，非標準評價方法更多采用約定俗成的方式，評價方法有較強的主觀性，因而難以保證評估結果的一致性。但因為這些評價方式簡便易行，因而在我國軟件行業(yè)中仍然占據主導地位。典型的非標準評價方法包括軟件源代碼行評價法、對象點評價法、需求數量評價法、用例數評價法以及文檔頁碼評價法等。軟件源代碼行評價法在所有的軟件項目規(guī)模評價方法中，軟件源代碼行方法在我國的軟件行業(yè)中仍然占據①軟件項目的工期、成本和質量目標主要取決于項目的工作內容，但同時還要受其他很多因素的影響，例如需求是否清晰、軟件技術是否成熟、開發(fā)人員的工作經驗和工作能力、開發(fā)團隊的人員規(guī)模等許多因素。對這一話題感興趣的讀者可以通過網絡途徑參閱筆者的博士論文一一《IT行業(yè)經濟與管理指標測度與預報模型的實證研究》。統(tǒng)治地位。顧名思義，軟件源代碼行法就是以完成的軟件源代碼的數量表示軟件項目所完成的功能的多少。源代碼行方法最大的特點即是簡單，直接數出代碼行的數量即可。不同的項目源代碼行數量不同，小項目可能只有幾千行代碼，而那些規(guī)模巨大的項目動輒會超過百萬行。但應用代碼行作為評價軟件項目規(guī)模的方法，其缺點也是顯而易見的。首先，代碼行從技術而非業(yè)務角度度量軟件規(guī)模。對于沒有足夠技術背景的客戶或其他項目外部干系人來說，代碼行不具備說服力，他們總是傾向猜測技術人員使用了過多的代碼來實現(xiàn)軟件功能。其次，代碼行度量不及時。度量軟件項目規(guī)模的主要目的往往要在前期確定項目的工期、費用等關鍵指標，但在項目前期只有籠統(tǒng)的業(yè)務需求，只有當項目完成后才能得到真正的代碼行數量。項目前期或項目執(zhí)行過程中估算出的代碼行數量沒有足夠的說服力，不同人員估算得到的代碼行數量也許會有50%的偏差。第三，缺乏代碼行度量標準。一行代碼是多長？注釋語句算不算？跨行的語句算一行還是多行？在行業(yè)中并沒有一致的規(guī)定。即使IEEE和SEI嘗試過頒布了一些代碼行度量標準，但并沒有得到廣泛的接受。最后，不同語言編寫的代碼行可比較性差。如何比較匯編語言、C語言或者Java語言編寫的語句呢？如果使用多語言開發(fā)的程序，又該如何度量代碼行的數量呢？雖然軟件代碼行方法目前在我國的軟件行業(yè)中仍然是一種普遍的規(guī)模估算方法，但因為其一致性不容易得到保證，越來越多的軟件開發(fā)組織傾向于采用標準評價方法(功能點標準)來衡量軟件項目的規(guī)模。2.對象點評價法對象點(ObjectPoin)評價法屬于BarryBohem所提出的COCOMOII模型的組成部分，主要適用于基于組件或可視化開發(fā)環(huán)境的項目，同時也適用于原型項目。對象點評價法基于加權的概念將軟件項目的工作內容轉換為相應的對象點數量，它包含最基本的三個對象點類型：屏幕、報表和組件①屏幕對應的復雜度加權表如表1.1所示。表1.1對象點評價法的屏幕計算表屏幕計算表引用數據表的個數包含的視圖個數總數＜4總數＜8總數＞8(<2Server:<3Client)(廠3Server;F5Client)(>3Server:>5Client)<3簡單簡單平均3—7簡單平均困難>8平均困難困難如果一個屏幕包含了5個視圖，且訪問了5個數據表，其中兩個是Server端的數據表，而另外三個是客戶端的數據表，則該屏幕對應的復雜度為平均。①組件的概念在第三代開發(fā)語言面世后才出現(xiàn)，其實組件就是對象。C++Builder中叫組件，Delphi中叫部件，而在VisualBASIC中叫控件。與傳統(tǒng)的代碼編寫通過定義函數實現(xiàn)功能不同，組件預定義了自己的屬性和方法，使用者只需對這些方法進行相應的定制即可實現(xiàn)期望的功能。

報表對應的復雜度加權表如表1.2所示。表1.2報表的復雜度加權表報表計算表報表的節(jié)數總數＜4引用數據表的個數總數＜8總數＞8(<2Server;<3Client)(2?3Server;3?5Client)(>3Server;>5Client)0,1簡單簡單平均2,3簡單平均困難4+平均困難困難如果一個報表包含三個節(jié)，訪問一個服務器端的數據表，對應的復雜度為簡單。對象點評價法中并沒有對組件設置相應的復雜度加權表，所有的組件默認其復雜度為平均。確定了屏幕、報表以及組件的復雜度，然后再根據對象點權重表將其轉換為統(tǒng)一的對象點，如表1.3所示。表1?3對象點權重轉換表對象點權重表對象類型復雜度權重簡單平均困難屏幕123報表258三代語言組件101010如果一個軟件開發(fā)項目要完成10個平均復雜度的屏幕、8個平均程度和3個困難程度的報表以及2個三代語言組件，則該項目的對象點規(guī)模即為（10X2+8X5+3X8+2X10）=104?；趯ο簏c的生產率對應表（如表1.4所示），即可推算完成該項目所需要的工作量。假定項目組的生產率為平均水平，則對應的工作量為8人月（103/13=8）。表1.4基于對象點的生產率對應表OP對應的生產率開發(fā)人員的能力及開發(fā)環(huán)境的效率生產率（NOP/人月）很低4低7平均13高25很高50對象點評價法的評價方法一致，但其對對象點類型的劃分并無詳細的規(guī)定，所以在操作中容易引起歧義，例如不同人員對視圖的理解可能就存在歧義。3.其他非標準評價法除了上面的兩種方法外，實際工作中還會使用到需求數量評價法、用例數評價法以及文檔頁碼評價法等方法。需求數量以項目需要完成的需求數量作為規(guī)模衡量的方法，但對于需求的粒度卻從來就沒有統(tǒng)一的規(guī)定，包括經常所提的模塊數量、功能模塊數量也屬于需求數量衡量的范疇，它們共同的缺陷都在于缺乏統(tǒng)一的標準，甚至不如代碼行方法的一致性。用例（UseCase）是基于UML方法的一種定義軟件需求的方式。用例是軟件工程或系統(tǒng)工程中對系統(tǒng)如何反映外界請求的描述，每個用例提供了一個或多個場景，該場景說明了系統(tǒng)如何同最終用戶或其他系統(tǒng)交互，從而獲得一個明確的業(yè)務目標。通過用例描述的方式可以將軟件系統(tǒng)所實現(xiàn)的功能進行抽象和總結，軟件系統(tǒng)要實現(xiàn)的功能則表現(xiàn)為一組用例，所以可通過用例數量來描述軟件項目的規(guī)模。相對籠統(tǒng)的“需求”“功能”等說法，用例具有較好的一致性。UML語言對用例規(guī)范建立了用例模板，例如典型的用例應該包含如下內容：用例名、迭代、綜述、前置條件、觸發(fā)器、基本事件流、備選路徑、后置條件、業(yè)務規(guī)則、說明、作者和日期等。如果能采用用例作為軟件規(guī)模的衡量手段也不失為一種可取的方式。但用例也存在粒度不一致的缺點，不同的用例可能相差很大。對一個銀行應用軟件來說，描述用戶管理的用例和住房貸款的用例可能會有很大的差別，從而缺乏橫向比對的意義。除此之外，用例對于客戶往往缺乏說服力，盡管UML的倡導者聲稱用例是客戶和技術人員溝通需求的最佳方式，但客戶對用例描述的需求多數還是采用敬而遠之的態(tài)度。采用文檔頁碼評價法的優(yōu)點和不足也是顯而易見的，頁碼最容易統(tǒng)計，但人們的書寫習慣、邏輯表達能力、圖形與文字的比例、甚至紙張的大小等因素都使得頁碼評價法很難成為合適的軟件規(guī)模評價方法。非標準評價法以其方便理解、易于操作的特點在實際工作中得到廣泛應用，盡管存在不同程度的不一致缺陷，但聊勝于無。無論如何，非標準評價法對于軟件規(guī)模給出了一個明確的、用數字表示的數值，從而使得在此基礎上討論項目的工期、費用和質量目標等量化管理目標成為可能。如果要盡可能減少項目干系人對于軟件規(guī)模評價結果理解的歧義，則需要采用軟件規(guī)模的標準評價方法一一功能點方法。1.2.2標準評價方法上述各種非標準評價方法雖然在實際工作中也有著普遍的應用，但更多地局限于軟件開發(fā)團隊內部。如果要在業(yè)務部門與開發(fā)部門、甲方與乙方等外部組織約定軟件開發(fā)的工期或費用等關鍵項目目標，則首先需要對軟件項目規(guī)模進行標準、一致的評價與估算。目前的軟件規(guī)模標準評價方法都同屬一類方法，即功能點方法。用功能點衡量軟件項目規(guī)模類似于用平方米衡量房間的面積，或者用千克衡量體重，所以如果使用功能點方法衡量軟件項目規(guī)模，則不同的人員對同一項目的軟件功能可以得到一致的結果，從而克服軟件規(guī)模非標準評價方法的不足。從美國人AllanJ.Albrecht在20世紀70年代末提出功能點方法以來，功能點在軟件行業(yè)的應用與實踐已超過30年，在Albrecht的功能點模型基礎之上，經過進一步應用與發(fā)展，功能點標準演進為一個總標準(ISO14143)與5個子標準(Markll標準、COSMIC標準、NESMA標準、FISMA標準以及IFPUG標準)。1.3功能點標準作為評價軟件規(guī)模的標準方法，功能點度量方法(FunctionPointAnalysis)已經被納入ISO14143標準系列。就功能點方法的發(fā)展歷程分析，目前被納入ISO14143的5種實際操作方法都源自于AllanJ.Albrecht所提出的功能點分析思想。當然，各種標準之間又存在一定的差異和共性。為了保證這些功能點操作方法的一致性和客觀性，ISO組織委托ISO/IECJTC1(信息技術)的SC7(軟件與系統(tǒng)工程)委員會制定了ISO14143標準。ISO14143標準本身又包含了6個子標準，各子標準的作用如下：ISO14143-1：概念定義(DefinitionofConcepts)，對標準中所采用的術語給出解釋。ISO14143-2：一致性評價(ConformityEvaluation)，給出如何檢驗功能點操作標準是否符合ISO14143標準的評價過程。ISO14143-3:驗證(Verification)，在需要時對功能點操作標準進行驗證。ISO14143-4:參考模型(ReferenceModel)，給出功能度量方法模型以及需要度量的內容。ISO14143-5：應用領域確定(DeterminationofFunctionalDomains)，確定功能點操作標準適用的應用領域。ISO14143-6：使用指南(GuidelineforUse)，對功能點標準的應用提出建議和指導。ISO14143給出了度量功能模型的標準，但在度量具體的軟件功能時，使用者還應該考慮所度量的軟件應用領域，從而選取合適的功能點度量方法所以從這個角度分析，ISO14143是關于功能點度量標準的標準。在實際的軟件規(guī)模度量實踐中，目前符合ISO14143標準的功能點操作方法有5種，依次是MarkII標準、COSMIC標準、NESMA標準、FISMA標準以及IFPUG標準。下面各節(jié)對這些操作標準的主要特點和操作方法進行簡要說明。1.4MarkII功能點標準1991年，英國人CharlesSymons在自己的《SoftwareSizingandEstimating:MkIIFunctionPointAnalysis》一書中介紹了MarkII功能點的操作方法。Symnos先生在為畢馬威咨詢公司工作期間提出了MarkII功能點操作方法，在該操作方法的基礎之上形成了MarkII功能點標準，該標準提出后被英國政府所采納，目前該標準由英國軟件行業(yè)協(xié)會維護①。MarkII功能點標準目前主要在英國應用此外在印度等國家也有一定的應用正如Symons先生自己所言②，該功能點標準受到Albreht先生的功能點操作方法啟發(fā)，不過采用了不同的加權方式來定義功能點標準。除了功能點的操作方法外，該標準還包含了功能點的應用建議，例如如何基于MarkII功能點標準來計算項目的生產率和工作量等內容。1.4.1MarkII功能規(guī)模度量規(guī)則為了保證MarkII功能點標準的一致性，該標準采用了基于規(guī)則的度量方式。MarkII的度量規(guī)則共有6條，分述如下：規(guī)則1邊界（1）MarkII功能點標準用于度量應用系統(tǒng)的用戶所要求功能的規(guī)模。（2）由邊界所包含的應用或部分應用必須是邏輯一致的功能，包含一個或多個完整的事務邏輯類型。規(guī)則2功能規(guī)模與邏輯事務（1）應用系統(tǒng)的功能規(guī)模是邏輯事務的規(guī)模之和，每個邏輯事務的輸入和輸出部分穿越應用邊界。（2）邏輯事務是最低級別的完整過程，它包含三個組成部分：進入邊界的輸入、邊界內和存儲數據相關的處理以及離開邊界的輸出。（3）邏輯事務由用戶關心的獨特的事件觸發(fā)，當事務完成時，應用系統(tǒng)處于邏輯完整的狀態(tài)③。邏輯事務也可以由用戶從應用系統(tǒng)獲取信息的需求觸發(fā)，此時應用系統(tǒng)為未修改狀態(tài)。（4）在度量應用的功能規(guī)模時，一個邏輯事務即使在應用系統(tǒng)出現(xiàn)多次也只能度量一次。（5）對修改的應用系統(tǒng)規(guī)模度量時，將增加的、修改的和刪除的邏輯事務規(guī)模相加。這意味著當邏輯事務的輸入、處理和輸出三部分出現(xiàn)增加、修改和刪除時，將其視為事務的修改情形。規(guī)則3邏輯事務的處理類型（1）邏輯事務的處理類型根據對存儲數據的操作確定，例如包含新增、刪除、修改和查詢。英國軟件行業(yè)協(xié)會網站為，讀者可以訪問該網站并下載MarkII功能點標準。Symons先生不但作為MarkII功能點標準的創(chuàng)始人，最近他又作為COSMIC功能點標準的度量委員會成員，積極倡導COSMIC功能點標準的推廣與應用。筆者曾在2007年與Symons先生在羅馬有一面之緣，Symons先生是一位睿智和藹的長者，對于功能點標準在軟件行業(yè)的應用多有真知灼見。Self-consistentstate邏輯完整的狀態(tài)，說明事務功能巳經完成，不存在只有輸入或者只有輸出的狀態(tài)。（2）處理部分的規(guī)模取決于邏輯事務所引用的主要實體類型以及系統(tǒng)實體類型。（3）對所有非主要實體類型的訪問均視為對系統(tǒng)實體類型的訪問。（4）在一個應用邊界內只能存在一個系統(tǒng)實體①邏輯事務類型的處理過程最多只能對其引用一次。規(guī)則4邏輯事務的輸入和輸出（1）邏輯事務輸入與輸出規(guī)模根據穿越應用系統(tǒng)邊界的數據元素類型確定。（2）數據元素類型是邏輯事務類型中特定的處理信息，它不可分割，是穿越應用系統(tǒng)邊界的輸入或輸出數據流的一部分。規(guī)則5邏輯事務規(guī)模（1）邏輯事務規(guī)模為輸入、處理和輸出三個組成部分的加權和。（2）該標準設定的加權方式為:輸入加權為0.58（每個輸入的數據元素類型、處理加權為1.66（每個引用的實體類型）、輸出加權為0.26（每個輸出的數據元素類型）。規(guī)則6MarkII功能計數結果根據該功能點計數標準所獲得的結果應包含對應的標準版本號，例如“600MarkII功能點（V1.3）”或“MarkII功能點=600（V1.3）”。1.4.2MarkII功能規(guī)模度量步驟MarkII功能點標準不但定義了詳細的功能點技術規(guī)則，還規(guī)定了在度量軟件規(guī)模中應遵循的完整步驟，根據這些步驟要求可以得到應用系統(tǒng)的MarkII功能規(guī)模。MarkII功能規(guī)模度量包含11個步驟，步驟1?6規(guī)定了MarkII的計數過程；步驟7和步驟8用于確定開發(fā)或維護應用系統(tǒng)所需的工作量、工期等關鍵的項目管理指標；步驟9?11則進一步考慮了技術復雜系數。MarkII功能點度量步驟如圖1.2所示。圖1.2MarkII功能點度量步驟①MarkII方法中對于數據類型的定義，其含義為應用內部所有非主要實體類型數據的集合，即代碼數據的集合。應用內無論存在多少個代碼數據文件，都將其視為一個系統(tǒng)實體。功能點度量應該基于應用系統(tǒng)的用戶角度來進行，對于那些系統(tǒng)所提供的，但用戶卻不需要的功能在功能點計數時不予考慮。功能點度量本身也需要花費一定的投入，根據MarkII功能點標準的特點，功能點度量所花費的工作量為項目總工作量的0.2%?0.4%。下面簡述MarkII功能點度量的各個步驟。步驟1：確定計數目的與計數類型。首先應該識別計數的客戶是誰。例如，是為了衡量開發(fā)團隊的工作產出，還是希望了解特定用戶所擁有的功能數量？另外考慮不同的因素有助于確定計數目的和計數類型，例如項目是否包含開發(fā)、修改、維護或支持各個階段，項目的起始與截止時間等。步驟2：確定計數邊界。該步驟與步驟1密切相關。確定邊界將有助于識別計數過程中應包含的邏輯事務以及識別相應的接口。步驟3：識別邏輯事務。邏輯事務是應用系統(tǒng)所支持的最底層過程，其識別方式參見規(guī)則2。步驟4：實體類型識別與分類。識別實體類型時最好能夠得到相應的實體關系數據模型。但因為只需要主要的實體類型（PrimaryEntityTypes），所以并不需要完全符合第三范式的數據庫模型。步驟5：輸入、過程與輸出計數。對每個邏輯事務計數時，度量輸入數據元素類型（Ni）的數量、引用的數據實體類型的數量（Ne）以及輸出的數據元素類型的數量（No）。步驟6：計算功能規(guī)模。功能規(guī)模（功能點指數，F(xiàn)unctionPointIndex）是所有事務功能的加權和，其計算公式如下：FPI=WxSN+WxZN+WxSN（公式1.1）其中的加權系數取值依次為W=0.58；6We=1.66；^=0.26。步驟7：確定工作量。16°根據項目的特點確定項目的總工作量和開發(fā)工期，參見MarkII功能點標準第7章。步驟8：計算生產率與其他績效系數。生產率的計算公式為：生產率=FPI/工作量；交付率的計算公式可以表示為：交付率=FPI/工期。參見MarkII功能點標準第8章。步驟9：影響度評分。使用技術復雜度特征來評估影響程度，參見MarkII功能點標準附錄1。步驟10：計算技術復雜度調整系數。計算技術復雜度調整系數，參見MarkII功能點標準附錄1。步驟11：計算調整后的功能規(guī)模。根據步驟10計算得到的技術復雜度調整系數計算調整后的功能規(guī)模該功能規(guī)模也可替代步驟6所計算的FPI，在此基礎上，再根據步驟7和步驟8進行計算，估算項目的工作量、工期和其他績效系數。1.4.3MarkII功能規(guī)模度量應用MarkII功能點標準可廣泛地應用于以下方面：（1）撰寫應用系統(tǒng)的需求規(guī)格或功能規(guī)格。（2）應用于為客戶定制的應用系統(tǒng)（例如ERP、CRM系統(tǒng)的實施）、批處理應用或實時應用系統(tǒng)。（3）度量項目級別或組織級別的項目績效（例如生產率、交付率和缺陷率等）。（4）比較組織內外部的IT工作績效。（5）比較應用系統(tǒng)的質量和可靠性。（6）比較不同平臺上歸一化之后的開發(fā)成本、維護成本或支持成本。（7）估算項目所需的資源、工期和成本。（8）分析新項目的成本和業(yè)務方面的風險。（9）輔助項目前期的需求識別。（10）控制項目的“需求潛變”①。（11）為人員分派工作提供依據。（12）確定應用資產規(guī)模。（13）為那些缺乏功能定義文檔的遺留系統(tǒng)提供相應的功能說明。（14）確定應用系統(tǒng)的重置費用。1.5COSMIC功能點標準COSMIC（COmmonSoftwareMeasurementInternationalConsortium，通用軟件度量國際聯(lián)盟）功能點的前身來源于1997年所提出的FFP（FullFunctionPoint，全面功能點）功能點標準，后來FFP組織又與COSMIC組織共同合作于1999年提出了COSMIC功能點標準，該標準歷經修訂，目前的最新版本為該組織于2009年所提出的3.0.1版本，該標準也于2003年被ISO組織接納成為國際標準。COSMIC組織提出該功能點標準的初衷在于克服IFPUG所維護的功能點標準的不足，COSMIC功能點標準對于實時類軟件、嵌入式軟件有更好的適用性，同時對典型的MIS系統(tǒng)也具有良好的適用性②。需求潛變（ScopeCreep）描述因為項目前期需求定義不明確，在項目后期需求不斷蔓延和擴展所對應的情形。COSMIC組織所聲稱的IFPUG功能點標準的不足并沒有得到業(yè)界的認同，IFPUG功能點在實時類軟件和嵌入式軟件的應用并不存在障礙。對于實時類軟件和嵌入式軟件的工作量評判和工期判定不應只考慮項目的功能規(guī)模，還應結合項目的其他特征，例如行業(yè)類型、技術類型和開發(fā)平臺等因素。許多人潛意識地認為既然定義了功能點，那么不同行業(yè)、不同技術路線的軟件項目都應該具備相同的生產率、交付率和缺陷率等，這種觀點就如要求每平方米的房子造價都相同那樣經不住推敲。

1.5.1COSMIC功能規(guī)模度量過程與MarkII功能點標準相似，COSMIC將度量軟件功能點的過程劃分為4個階段，依次是度量規(guī)劃階段、映射階段、度量階段和報告階段，如圖1.3所示。軟件關畦模W度吊階段陂度成軟件的功能用戶需求誦用軟件模型度域目的,被度球件每…部分的范圍函用軟件椎型盼式的川戶期E軟件關畦模W度吊階段陂度成軟件的功能用戶需求誦用軟件模型度域目的,被度球件每…部分的范圍函用軟件椎型盼式的川戶期E需求以的軟件功能規(guī)模度Ed現(xiàn)劃階股報告折段映射階段圖1.3COSMIC功能點度量的4個階段相對于其他功能點標準，COSMIC功能點標準聲稱可以更好地度量實時項目和嵌入式項目的軟件功能規(guī)模，因為這些類型的應用通常和用戶的交互較少，更多的功能通過內部過程實現(xiàn)，所以在功能點計數時應該考慮這些內部操作的功能①因而就引入了一個重要的概念——“層（Layer）”。圖1.4給出典型的MIS類項目和嵌入式項目的物理分層模型。圖1.4MIS類項目的物理分層模型①在COSMIC模型中引入Layer的概念固然可以反映內部過程的復雜性，但Layer的劃分更傾向于從技術實現(xiàn)的角度進行劃分，所以“功能點標準對用戶透明”這一基本特征可能就會受到負面的影響。圖1.4的MIS類項目可分為軟件層和硬件層，其中軟件層又包含應用層、中間件層、數據庫管理層和操作系統(tǒng)層；而硬件則是單獨的一層。圖1.5數據庫管理層和操作系統(tǒng)層；而硬件則是單獨的一層。圖1.5嵌入式項目的物理分層模型EIndicatesEIndicates富messagelhatkkilledasanEx記datainoveffiefil.—icnas虻否aboudary乙nd禎rteeivedasEntrychM[tiovemenl嵌入式項目也分為軟件層和硬件層見圖1.5。其中軟件分為嵌入式應用層和操作系統(tǒng)層，硬件則為單獨的一層。根據MarkII功能點標準或基于IFPUG的功能點標準，用戶與應用系統(tǒng)通過邊界進行交互。而根據COSMIC功能點標準，用戶不但通過邊界與應用系統(tǒng)交互，應用系統(tǒng)內的各個層之間也進行數據的交互，可以將一個層視為另一個層的用戶，如圖1.6所示。Hie

appliicatioa

layer圖1.6用戶與層以及層與層之間的數據交互示意圖1.5.2COSMIC功能規(guī)模度量規(guī)則確定了應用系統(tǒng)的邊界以及應用系統(tǒng)的物理分層后，COSMIC將所有的軟件功能區(qū)分為4種類型，即進入（Entry）、離開（Exit）、讀（Read）和寫（Write）4種功能類型。對于4種功能類型的識別，COSMIC也基于規(guī)則約束。下面簡述對各個功能的識別規(guī)則。進入功能描述從功能用戶穿過邊界轉移一個數據組到功能過程的功能。識別進入功能應遵循以下6條識別規(guī)則：（1）一個進入功能從功能用戶穿過邊界轉移一個關注對象的單個數據組到應用的功能過程。如果一個功能過程的輸入由一個以上的數據組組成，那么要對輸入中的每一個數據組識別為一個進入功能。（2）進入功能不會穿過邊界輸出數據或讀寫數據。（3）一個觸發(fā)進入功能的數據組可能只包含一個數據屬性，此屬性簡單通知軟件“一個事件已經發(fā)生”。更常見地，觸發(fā)進入的數據組可能有幾個數據屬性。（4）作為觸發(fā)事件的時鐘處于被度量軟件之外。觸發(fā)事件的發(fā)生是由硬件周期性觸發(fā)還是由被度量軟件邊界外的其他軟件觸發(fā)沒有區(qū)別。（5）除非需要特定的功能過程，否則從系統(tǒng)時鐘獲取時間不會引起一個進入功能。（6）如果一個進入功能轉移的數據組由n個數據屬性組成，而另一個進入功能轉移的數據組由描述同一關注對象的此n個數據屬性的子集組成，那么應該只識別出一個進入功能，其數據組包括n個數據屬性。離開功能描述一個從功能過程穿過邊界轉移一個數據組到功能用戶的數據移動。離開功能與進入功能移動數據的方向正好相反。識別離開功能應遵循以下4條規(guī)則：（1）一個離開功能從功能過程穿過邊界轉移一個關注對象的單個數據組到功能用戶。如果一個功能過程的輸出由一個以上的數據組組成，那么要對輸出中的每一個數據組識別一個離開功能。（2）離開功能不會穿過邊界輸入數據或讀、寫數據。（3）軟件產生或輸出的不含用戶數據的所有消息（如出錯信息）被認為是一個關注對象（錯誤指示）的一個屬性的值。因此含有此功能的每個功能過程中的所有此類消息的輸出識別為一個離開功能。（4）如果一個離開功能轉移的數據組由n個數據屬性組成，而另一個離開功能轉移的數據組由描述同一關注對象的此n個數據屬性的子集組成，那么應該只識別出一個離開功能，其數據組包括n個數據屬性。讀功能描述從固定存儲轉移一個數據組到功能過程的數據移動。判斷是否為讀功能遵循以下3條規(guī)則：（1）一個讀功能從固定存儲轉移描述一個關注對象的單個數據組到功能過程。如果一個功能過程需要從固定存儲中提取一個以上的數據組，那么要對提取的每一個數據組都識別為一個讀功能。（2）讀功能不會穿過邊界接收或輸出數據，也不會寫數據。（3）在一個功能過程中，如果常量或變量的數據移動或處理只能由程序員進行，或者是計算的中間結果，或者功能過程存儲的數據是軟件實現(xiàn)的需要，而不是功能用戶需求，則不能算做讀數據移動。寫功能描述從功能過程轉移一個數據組到固定存儲的數據移動，寫功能的操作方向與

讀功能的數據操作方向相反。寫功能的識別應遵循以下3條規(guī)則：（1）一個寫功能從功能過程轉移描述一個關注對象的單個數據組到固定存儲。如果一個功能過程需要轉移一個以上的數據組到固定存儲，那么要對轉移到固定存儲的每一個數據組識別一個寫。（2）寫功能不會穿過邊界接收或輸出數據，也不會讀數據。（3）從固定存儲中刪除一個數據組的需求算做一個單獨的寫數據移動。1.5.3COSMIC功能規(guī)模計算根據COSMIC規(guī)則識別了描述數據移動的4種功能之后，將4種功能的數量相加，即得到軟件應用相應的COSMIC功能規(guī)模，如公式1.2所述。功能規(guī)模=功能規(guī)模=工輸入,.+工離開,.+工讀^+X寫（公式1.2）i=1i=1i=1i=1根據COSMIC功能點標準，用戶還可以在使用該標準的同時對其規(guī)則進行適當的擴充，經擴充后的功能規(guī)模可表述為如下形式。（公式1.3）功能規(guī)模=xCFP（v.y）+zLocalFP（公式1.3）其中，x表示CFP的數量；CFP表示為一個COSMIC標準功能點；v.y表示COSMIC標準的版本；z表示擴充的FP數量；LocalFP表示擴充或本地化的功能點。1.6NESMA功能點標準前文已經述及5種功能點操作標準有較強的相似性，其他4種標準均有意識地借鑒和使用了IFPUG的功能點標準。但其中NESMA標準對IFPUG功能點的借鑒尤為徹底，例如功能點標準的度量過程與術語完全一致。說的夸張一些，就是將英文版本的IFPUG功能點標準翻譯為荷蘭語標準而已，例如IFPUG的CPM4.2英文標準與NESMA的CPM2.2荷蘭語標準幾乎完全相同。NESMA為荷蘭軟件度量協(xié)會的簡稱（NEtherlandSoftwareMeasurementAssociation），NESMA功能點標準主要在荷蘭本國采用，在荷蘭之外的國家?guī)缀鯖]有用戶。功能點標準在荷蘭的應用還是較為普遍的，筆者曾于2005年秋季前往荷蘭參加功能點應用方面的學術交流活動，參與會議的代表大概有七八十人之多（其中國際代表約為20人），可見功能點應用在該國的普及狀況。要知道荷蘭的總人口也就1600萬左右，比北京市現(xiàn)在的常住人口數量還差400萬呢。當然，NESMA功能點標準與IFPUG并不完全相同，它們之間還存在些許差異，具體表現(xiàn)在外部查詢與外部輸出的識別差異、外部查詢的復雜度確定、隱含查詢處理和代碼表處理等方面。1.外部查詢（EQ）與外部輸出（EO）根據IFPUG的功能點標準，EQ與EO的主要目的都是“向應用邊界外的用戶呈現(xiàn)信息”，不同之處在于EQ不能包含任何額外的處理邏輯（包括計算、生成衍生數據、更新內部邏輯文件和更改系統(tǒng)行為），否則即是EO。對于NESMA功能點標準而言，對于那些包含特定的選擇功能的EQ視為EO（例如包含“顯示所有客戶”選項的EQ在IFPUG功能點標準中仍被視為EQ，而在NESMA標準中卻當作EO）。盡管如此，這種差異并不會引起功能點度量結果方面的明顯不同。EQ的復雜度判定根據NESMA標準，EQ復雜度的判定要根據兩方面的復雜度比較結果而定，即根據外部輸入（EI）的規(guī)則判定EQ輸入端的復雜度，然后再根據EO的規(guī)則判定EQ輸出端的復雜度，兩者相比較后取復雜度較高的值作為EQ最終的復雜度。IFPUG的EQ判斷規(guī)則與EI和EO的判斷規(guī)則相似，根據EQ的數據元素類型和文件引用類型確定其復雜度。因為EI、EO、EQ本身的復雜度非常接近，所以EQ即使采用不同的判定規(guī)則，對最終的功能點度量結果影響也是微乎其微。隱含查詢判定隱含查詢是指當需要修改或刪除數據時，首先需要展示數據，該功能即稱為隱含查詢。根據NESMA標準，對該情形并不會做特別的考慮。而在IFPUG功能點標準中規(guī)定當該隱含查詢功能已經在其他地方出現(xiàn)過，判斷修改功能或刪除功能時不考慮該隱含查詢功能所對應的數據元素類型和文件引用類型，否則需要考慮隱含查詢對應的功能點數量。對于隱含查詢的不同判定方式也不會引起兩種標準度量結果的明顯不同。代碼表處理通常所說的實體概念由主要數據（業(yè)務對象）和次要數據（支持數據）組成。對于描述業(yè)務對象的主要數據，NESMA功能點標準和IFPUG功能點標準都遵循IFPUG功能點標準所設定的規(guī)則。兩種標準對于次要數據的處理則有差異，NESMA將次要數據視為數據功能，并識別出相應的事務功能。例如，包含商品代碼商品描述字段的表即為典型的代碼表。IFPUG則認為次要數據的代碼表并不是基于業(yè)務角度考慮，完全屬于技術實現(xiàn)范疇的內容，因而進行功能點度量時既不考慮對應的數據功能，也不考慮與代碼數據關聯(lián)的事務功能。如果NESMA功能點操作標準和IFPUG操作標準在前面三種情形中的差異可以忽略的話，兩者在代碼表方面的差異可能會較為明顯。例如在NESMA功能點操作標準中一個代碼表的數據功能可能為7個功能點①，對應的事務功能可能只包含創(chuàng)建和查詢兩個事務功能，因而對應的功能點數均為3個功能點②，所以是否將一個次要數據代碼表作為功能點度量范疇的內容，可能意味著13個功能點的差異。盡管NESMA功能點標準與IFPUG功能點標準之間存在一定的差異，但與其他的功能點標準相比較（MarkII功能點標準、COSMIC功能點標準和FISMA功能點標準），NESMA功能點標準仍然與IFPUG功能點標準保持了最好的一致性。次要數據代碼一般只有兩個數據元素類型，因而復雜度為簡單，根據功能點復雜度轉換表，該數據功能為簡單時對應7個功能點。因次要數據代碼表一般只包含兩個數據元素類型，所以對應的事務功