FAQS Chinese

常見問題

2016年3月更新

請通過Facebook和LinkedIn和我們聯繫,歡迎您在朋友圈分享我們的資訊。

IFPUG網站,請收藏供以後參考
IFPUG Facebook主頁,請點擊「Like」
IFPUG Twitter,瞭解白皮書的最新版本和其他新聞。
IFPUG LinkedIn,請點擊「Follow」

如果要建議其他的常見問題或編輯本頁中的問題,請點擊 聯繫我們並在資訊主題中包含 「IFPUG FAQ」字樣。
IFPUG FAQ PAGE 的頂部

IFPUG會員和非會員均可以從網站下載相關的文檔,您可以註冊成為IFPUG會員,也可延續您的會員資格。

1.功能點是什麼?SNAP是什麼? 功能點和SNAP之間有何區別?
2.功能點適用于所有人嗎?
3.為什麼要進行度量?
4.IFPUG會員資格有什麼用?
5.如何向開發人員和專案經理們說明功能點分析的重要性?
6.協助工具點估算的工具有哪些?
7.如何向使用者說明功能點分析的重要性?
8.什麼是功能點基線?
9.為什麼不用程式碼?
10.程式碼轉換為功能點怎麼樣?
11.我們需要提升,應該從哪兒開始呢?
12.想要提升生產率,需要收集哪些資訊?
13.CIO需要瞭解功能點嗎?
14.CIO需要瞭解敏捷開發和功能點嗎?
15.想要提升估算能力,需要收集哪些資訊?
16.想要提升品質,需要收集哪些資訊?
17.我們需要認證的CFPS顧問嗎?
18.功能點顧問需要具備什麼能力?
19.在哪裡找功能點顧問呢?
20.在哪裡可以瞭解到功能點相關的更多資訊?
IFPUG
常見問題
頁面

1.1功能點是什麼?
功能點是用來表示軟體規模的一種國際標準度量單元。 IFPUG功能規模度量方法(IFPUG CPM4.3.1)基於軟體的邏輯設計和功能需求對軟體提供給使用者的功能進行了量化。 量化結果資料被稱為功能點。 鑒於此,功能點計數的目標為:

功能點還有許多其他用途,如在許多IT公司把功能點作為度量生產率和品質標杆時用到的規模單位(如每FP...... )。 想要瞭解IFPUG FP方法的更多內容以及度量非功能需求的軟體非功能評估過程(SNAP),請點擊以下連結:

1.2 SNAP是什麼

SNAP是「Software Non-functional Assessment Process」的縮寫,它是一種補充功能點的軟體度量方法。 SNAP方法可以對非功能需求的規模進行度量。 SNAP絲毫不會替代功能點的用途,相反,它應該與功能點一起應用。 SNAP方法是IFPUG在軟體規模度量方面持續改進的工作結果。

1.3功能點和SNAP之間有何區別?

簡單地說,功能點度量軟體應用中資料流程以及資料存儲的規模,所以功能點度量功能性的使用者需求。 SNAP度量軟體功能的其他方面——例如資料配置、演算法、決策樹、資料驗證以及諸如更換logo功能點等,非功能目前總共包含14個類型的功能。 使用者功能性需求簡稱為「FUR」,使用者非功能性需求簡稱為「NFR」。 度量功能性需求的方法參見CPM手冊,度量非功能性需求的方法參見APM手冊,兩者均可以從IFPUG的官方網站購買和下載。

1.4 如何應用功能點和SNAP點來確定軟體的總體規模?

軟體的總體規模由功能點度量結果和SNAP度量結果共同組成。 例如,某個軟體應用的規模可以表述為800個功能點和300個SNAP點。 因為兩者不同,所以不能簡單將其相加,例如不能說該軟體應用規模為1100點,但可以將其表述為類似800 300i這樣的形式。

功能點和SNAP點都與軟體發展工作量密切相關。 開發軟體新產品或者升級已有軟體所需的工作量是完成功能點所需的工作量(功能點數量乘以單位功能點所需工作量)和完成SNAP點的工作量(SANP點數量乘以單位SNAP點所需工作量)之和。

1.5應用SNAP的必要性有多強?

應用SNAP的必要性主要取決於軟體應用的類型。 許多軟體發展人員和軟體發展團隊認為他們所付出的許多工作量並不能從功能點數量上得到客觀反映,例如針對那些演算法比較集中的應用,或者存在大量資料校驗的應用,或者是人機工程要求較高的應用(例如對頁面配置或者logo應用方面有較多的要求和考慮)。 針對上述的應用特點,應用SNAP方法可以較好地克服單獨應用功能點方法所存在的不足。 SNAP方法對於軟體發展人員而言是一種更公平、更受歡迎的度量方法。 應用SNAP方法可以更好地預測新開發專案和升級專案所需的成本和進度。

1.6如何向軟體發展人員和專案經理說明SNAP的重要性?

軟體發展人員在滿足非功能性需求方面花費了大量的工作量,但這些工作量卻無法在功能點產出方面得到體現,軟體發展人員將會直接感受到引入SNAP方法對工作量評價帶來的好處。

如果同時應用軟體功能點方法和SNAP方法,專案經理就可以更合理地設置專案的預算,他們可以向專案的出資人說明在軟體中包含了更多的軟體資產——除了可以用功能點衡量的功能資產,還包括應用SNAP方法衡量的非功能資產。

1.7估算軟體專案工作量最準確的方法是什麼?

根據Capers Jones(2012),用人工方式度量功能點的誤差大約為10%,如果綜合度量功能點和SNAP點,則其誤差大約為5%,下面是應用各種方法度量誤差的類表資訊。

1.8 應用SNAP方法的好處是什麼?

同時度量軟體功能規模和軟體非功能規模對IT組織而言,會帶來多方面的好處。 它可以為軟體專案的開發過程和軟體應用的維護過程提供更好的洞察力,包括如下各種用途:

  • 提供軟體規模和軟體工作量的相關關係,因為軟體發展人員的任務往往既包含滿足功能需求,也包含滿足非功能性需求
  • 可以提高估算軟體專案工作量和交付時間的準確程度
  • 軟體發展人員投入在非功能方面的工作量會得到充分認可
  • 軟體使用者可以更好地瞭解軟體應用為組織帶來的好處
  • 客戶可以更好(以及量化)地認識到投入資金的回報價值
  • 關於軟體發展生產率的解釋將更合理,關於每功能點所需花費的工作量變動將得到更全面的分析
  • 對那些只具備非功能需求的專案也可以度量規模
  • 軟體專案之間的KPI差異情形將得到更好的解釋

1.9 SNAP的應用現狀如何?

目前SNAP在美國、亞洲以及歐洲的應用還處於起步階段,應用SNAP方法的公司為數不多。

1.10如何學習SNAP?

您可以從IFPUG的官網免費獲得SNAP評估手冊(APM)。 除此之外,IFPUG網站也列出了提供SNAP認證課程的公司清單 (http://www.ifpug.org/certification/training-materials-certification/)

返回
IFPUG
常見問題
頁面

2.功能點適用于所有人嗎?
這個問題沒有確定答案,要看你是否需要知道你所在的軟體發展專案中開發或升級的軟體的大小,或者你是否需要知道軟體組合中軟體系統的大小。 功能點度量能和其他度量指標一起説明你快速瞭解專案和應用的如下資訊:

  • 什麼專案生產率更高;
  • 什麼專案提供更高品質的軟體產品或應用;
  • 什麼專案估算更準確;
  • 什麼專案需要過程改進方法;
  • 什麼專案偏離了預算和成本基線;
  • 什麼專案的專案績效低(或高);

如果在你的IT職責中遇到了以上問題,那麼功能點分析對你很適用!

返回

IFPUG
常見問題
頁面

3.為什麼要進行度量? 世界前25%的公司(來源於ISBSG)都用軟體度量來管理他們的IT以及軟體發展,原因如下:

  • 不能度量就無法管理;
  • 識別專案和軟體應用的問題並採取糾正措施 一般來說,大的IT專案45%會超出預算,7%會延期,56%會達不到預期價值。 軟體專案在成本和進度方面都面臨高風險,以上結論由麥肯錫和牛津大學2012年10月聯合得出。
  • 比較不同供應商對RFP(招標檔)的投標報價;
  • 度量可對專案目前狀態進行評估,有助於對軟體發展過程的瞭解和改進。(參見Guidelines to Software Measurement – Release 1.1, pg.2-4, 3-7 – 3-8;)
  • 有助於確定公司軟體發展的最佳實踐
  • 度量交付軟體的品質,對提供高品質軟體的開發團隊給予經濟鼓勵。
  • 基於功能點和SNAP的度量提供了一種和客戶溝通軟體需求規模的途徑,並且基於功能點資料很容易計算出生產率、品質和估算精度。
  • 你的許多競爭對手可能已經有這些觀念了。

返回

IFPUG
常見問題
頁面

4.1 IFPUG會員資格有什麼用?
本網站及其他許多資訊對會員和非會員都是免費的,但成為IFPUG會員有如下好處:

  • 提供和世界上不同公司的專家現場或網路溝通的機會,這些專家都有度量經驗或在做度量相關的工作;
  • 對ISBSG標杆資料(用於精益六西格瑪)及其他產品享受折扣價;
  • 提供加入功能點標準委員會的機會;
  • 每年的知識分享會可以提供:
    • 認識度量領域人士的機會;
    • 通過會議之前的研討會可以得到學習和繼續教育優惠的教育機會;
    • 提供培訓和認證測試的途徑,可以獲得全球公認的認證資格,包括:
      • CFPS:認證功能點專家(最早且獲得最廣泛認可的功能規模度量資格);
      • CFPP:認證功能點從業者(從事功能點度量的專業人士但不一定是專家);
      • CSP:認證SNAP從業者(世界範圍內唯一的測試軟體非功能需求度量知識的資格);
    • 有接受行業專家和經驗豐富的從業者在度量領域成功(包括失敗)經驗的機會。
  • 專業出版物:
    • Metric Views(半年刊)- 有印刷版和電子版,內容包括軟體度量文章、IFPUG新聞、委員會更新以及軟體度量界的最新進展資訊等;
  • 享受IFPUG產品的大幅折扣,包括:
    • ISO標準和IFPUG計數實踐手冊(CPM),包括接近300頁的計數規則、方法及實例;
    • FP Case Studies,提供了如何把CPM規則應用到軟體需求度量中的功能點計數實例;
    • 管理報告指南,提供成功應用功能點交付管理結果的有用建議;
    • 白皮書及其他IFPUG出版物,介紹FP如何應用在新技術(CS結構、網路等)、應用(如資料倉儲)和方法論(如敏捷開發)中。
  • 訪問IFPUG網站的會員頁,你可以在那裡找到會員之間交流軟體度量相關技術的帖子(你也可以向IFPUG社區提出問題,以獲得想要的答案),
  • 要想獲得最新版的CPM、SNAP或其他文檔,請進入我們的線上商城,你可以在商城把商品添加到購物車並結算。

請訪問線上商城

4.2 IFPUG服務需要付費嗎?
IFPUG會員享受參加會議、研討會和購買著作的折扣,並能訪問網站中的會員內容。 另外,我們鼓勵所有IFPUG會員都加入IFPUG社區,並歡迎加入我們的各個委員會。 其他服務目前都免費。
4.3 如何向高層經理推銷功能點(以及軟體度量)?

首先要對使用功能點分析的好處了然于胸(功能點是獨立于軟體發展所使用的工具、技術、技能和方法而度量的軟體規模),然後瞭解使用基於功能點的軟體度量所帶來的的投資回報率。

接著需要研究可得的行業資料(對那些沒有收集歷史功能點資料的公司更有用),例如ISBSG資料。
國際軟體標杆標準組(ISBSG)的標杆資料是世界範圍內的軟體發展專案資料,這些資料可有效用於專案估算、專案比較分析,以及評估你所在公司的專案績效(生產率和品質)。 IFPUG會員享受所有ISBSG產品折扣。

返回

IFPUG
常見問題
頁面

5.如何向開發人員和專案經理們說明功能點分析的重要性?
功能點分析 (FPA) 可以讓你的專案計劃更準確並有助於管理範圍蔓延。 另外,由於使用功能點分析及歷史資料使估算更準確,開發人員更容易完成給定時間內分配的任務。

返回

IFPUG
常見問題
頁面

6.協助工具點估算的工具有哪些?

新軟體開發專案可使用宇宙, 早期功能點估算可用ISBSG比較估算工具。

返回

IFPUG
常見問題
頁面

7.如何向使用者說明功能點分析的重要性?
功能點分析基於功能使用者需求(「按照業務過程和程式軟體需要完成的功能」)評估軟體的功能規模。 因此,FPA從使用者視角來看待軟體並基於軟體中五種標準的、使用者可識別的元件來確定功能點數:兩種存儲資料實體的類型(內部邏輯檔和外部介面檔)和三種業務處理過程類型(外部輸入、外部輸出和外部查詢)。 FP結果(業務過程和功能元件規模清單)用使用者可理解的術語描述。 FP計數提供了軟體發展人員和使用者之間溝通的通用語言。 FP計數過程本身也有助於發現遺漏的需求,並能提供對軟體產品規模客觀準確的估算,因此也有利於使用者更好地進行預算控制。

返回

IFPUG
常見問題
頁面

8.1 什麼是功能點基線?

  • 應用功能點基線是系統提供給使用者的當前功能的規模。
  • 公司或組織的總基線就是所有單個系統基線計數之和。

8.2 我需要功能點基線嗎?

這取決於你想用功能點基線做什麼。 如果你的目標是為了替換軟體應用而評估其規模,那麼瞭解當前應用有多大將有助於估算重置成本。 如果你的目標是能夠準確評估一年中通過軟體升級修改或增加了多少軟體功能,那麼你可能需要有功能點基線。

  • 如果你的目標是提升專案品質、生產率或估算精度,那麼你可能不需要功能點基線,而需要度量軟體發展或升級的規模。
  • 如果你的目標是在專案組合或應用集中比較支援和維護成本(每FP成本),那麼你需要知道那些應用的功能點基線以及每個專案的基線。

返回

IFPUG
常見問題
頁面

9.為什麼不用程式碼(計算生產率或品質時作為軟體規模的度量單位)?

這個問題在公司考慮用FP還是程式碼(SLOC)作為軟體規模度量單位時經常會遇到。 FP具有獨立于技術和實現的優點,而程式碼有以下缺點:

  • 使用程式碼傾向于鼓勵臃腫的設計而不是簡潔的設計(例如:「義大利麵條式」代碼不會像好的編碼設計那樣高產且實現相同的功能需要程式碼更少。 當用程式碼表示時,程式碼多並不一定意味著生產率高)。
  • 沒有針對程式碼的行業標準(ISO或其他)(例如:有人提倡數非注釋命令列,但這種做法並沒有得到廣泛接受)。
  • 程式碼並不能跨平臺、語言或組織而標準化使用(因為不同程式設計語言和程式設計習慣下,實現相同功能程式碼數也會不同)。
  • 某些第四代語言(4GL)甚至不能用程式碼度量。
  • 基於程式碼的生產率很容易引起歧義–參見刺山柑鐘斯 生產率悖論

返回

IFPUG
常見問題
頁面

10.轉換(使用基於程式設計語言的轉換表把SLOC轉換成FP)怎麼樣?

  • 轉換是基於程式碼的,因此會陷入和使用程式碼相同的困境。
  • 它可以用在未來不需要做多少修改的遺留系統中。
  • 如果不考慮準確度的話,轉換還是有用的。

返回

IFPUG
常見問題
頁面

11.1 我們需要提升,應該從哪兒開始呢?

  • 首先需要確定哪方面需要提升。GQM (目標,問題,度量)過程有助於解決這個問題。 其他免費資料(可下載)可以從實用的軟體和系統測量 (強調) 網站 獲取。 一旦確定了目標,FP規模作為生產率和資產收益率的分母,可能會成為需要收集的重要資料。
  • 提升目標一旦確定,也就明確了應該從哪兒開始提升(例如:品質、生產率或估算精度等)。
  • 加入IFPUG並和其他會員通過內部論壇交流基於功能點的軟體過程改進和度量成功經驗。

11.2 如果僅自己和500名開發人員,我該怎麼開始呢?
確定你的開發團隊目前最關鍵的問題。 針對最關鍵問題開始度量過程(使用GQM過程),並及時溝通度量結果以獲得支援和認同。 專家建議首先在小範圍內開始度量程式,度量結果獲得認同後再在整個公司內推廣。 這樣,你可以確保度量目標的正確,度量程式的正確,並在大範圍推廣度量前獲得一些成功經驗。

11.3 如果生產率很重要,我應該度量什麼生產率-新開發專案、維護等等?
同樣,這取決於你的度量目標。 根據GQM方法,你可以使用帕累托法則(80/20法則)來確定問題所在以及首先進行生產率度量的目的地區域。 例如:如果在軟體支援/維護方面人手不足以及存在挑戰,那麼支援率(如每1000FP所需的支援人員數量)可用來客觀證明是否人手不足。

返回

IFPUG
常見問題
頁面

12.1想要提升軟體發展生產率,需要收集哪些資訊?

  • 生產率可以用不同的比率來表示,其中包括功能點。 可參考the Guide to Management Reporting(IFPUG出版)或the ISBSG Practical Project Estimating(ISBSG產品)。

12.2為了進行FP計數,我需要做什麼?

IFPUG CPM(當前版本4.3.1)中說明了FP計數時需收集的文檔。 第一步需要確定計數目的和範圍,以及計數類型,即開發專案、升級專案還是應用的功能點計數。 注意軟體的每部分都具有獨立的應用邊界(詳細請參考CPM),都應該分別進行FP計數。

為了進行功能點計數,需要瞭解軟體的如下資訊(功能使用者需求):

  • 使用者可定義的輸出,這些輸出穿過應用邊界且是基本過程的處理結果(如:報表格式、介面顯示、輸出檔案等)。
  • 使用者可定義的輸入,這些輸入穿過應用邊界並且觸發基本過程的執行(如:介面輸入、檔輸入、批量檔輸入等)。
  • 由應用維護的使用者可定義的資料存儲(如:檔、表定義、資料庫或實體定義)。
  • 應用僅訪問引用的使用者可定義的資料存儲(如:檔、表定義)。
  • 穿過應用邊界的使用者可定義的查詢(如報表格式、介面顯示等)。
  • FP計數過程在IFPUG CPM中有詳細的說明。
  • 支援率=應用功能點/支援應用的工作小時
  • 升級率=專案中升級的功能點/專案工作小時
  • 交付率=交付的軟體應用的功能點/日曆時間
  • 關於功能點分析的更多資訊,請參考IFPUG CPM。
  • 為了提高交付率的敏捷軟體發展方法

返回

IFPUG
常見問題
頁面

13.CIO需要瞭解軟體規模(FP和SNAP)嗎?

對於高級管理人員來說,IT組合管理非常重要。 軟體規模有助於評估IT專案的投資回報,還可以用來對不同實施方案進行成本-效益分析比較。 功能點、SNAP點可以和其他度量指標(專案工作量、缺陷等)結合使用,用來監控趨勢和進行標杆比對分析。

返回

IFPUG
常見問題
頁面

14.CIO需要瞭解敏捷開發和功能點嗎?
使用任何度量方法比較或評估不同類型的專案或合同時,最需要考慮的是一致性。 針對敏捷專案,開發人員常常拒絕使用FP(認為敏捷專案不能用FP度量)或接受FP(認為用FP度量敏捷專案能比瀑布型專案得到更多的FP)。 這兩種認識都是錯誤的! FP表示基於功能使用者需求的軟體交付部分的規模,這些功能是完整的和連續的業務過程。(參見文章 計數 FP 敏捷反覆運算專案 。)

FP是一種評估固定總價合同的有效方法,也可以用來在軟體發展專案的招標過程中比較競標者的RFPs(例如:若兩家競標者的FP報價差別很大,則說明其中一個供應商可能沒有完全理解待開發軟體的功能需求)。

在外包和軟體發展行業中,IBM和CGI都使用FP(且擁有認證功能點專家團隊)評審提交的建議書。

不同的合同類型都能從使用功能點估算中受益,有些國家(包括義大利、巴西、韓國、芬蘭)逐漸要求建議書中使用功能點估算,並且在軟體合同中使用功能點報價(每FP成本)。

返回

IFPUG
常見問題
頁面

15.想要通過使用FP提升估算過程,需要收集哪些資訊?
軟體估算本身是一個完整的過程,但是使用功能點作為輸入進行專案估算的前提至少包括以下資訊:

  • 開發類型;(新開發或升級)
  • 平臺;(硬體和架構)
  • 語言;(程式設計語言或級別)
  • 團隊經驗;
  • 技術;(開發方法)
  • 外部約束;
  • 範圍蔓延

為了做好估算,使估算可靠,無論你是使用公司內部的評估方法,使用ISBSG的歷史交付率,還是使用專業套裝軟體,你都需要瞭解相似專案的交付率。 市場上有一些有助於提高估算準確度的套裝軟體。

返回

IFPUG
常見問題
頁面

16.想要提升品質,需要收集哪些資訊?

  • 品質對不同的人含義不同。 確定你所在組織對品質的定義。 可以從ISO 9126的軟體系統品質屬性以及GQM過程獲得説明。
  • 品質度量的例子有:
    • 缺陷密度-缺陷數量/功能點規模
    • 缺陷交付率-上線第一個月發現的缺陷數量。

返回

IFPUG
常見問題
頁面

17.我們需要認證的CFPS顧問嗎?
這個問題需要每個公司自己來回答。 需要考慮的有:

  • 我們需要在幾個月中得到完整的功能點基線嗎? 如果答案是肯定的,那麼最好有幾個認證顧問來幫你。 當功能點基線完成後,你可能需要一個或多個認證的功能點計數人員來自己維護這個基線。
  • 我們只想開始功能點計數並估算「大專案」。 如果是這樣,你可以派幾個員工參加IFPUG研討會或年會從而接受培訓。 經過培訓,他們可以執行功能點度量並開始收集資料。 你可能也需要一名或多名認證員工來審計功能點度量結果。
  • 你可能只能從老闆那裡得到我們需要開始度量的指示,而沒有更詳細的資訊。 如果這樣,你可以引進顧問,執行GQM會議來確定度量從哪裡開始。 你也可以派幾個員工參加IFPUG研討會或年會從而接受培訓。
  • 你處在一個大型公司,老闆想立刻開始度量所有資訊。 如果這樣,你可能需要一個顧問來:
    • 執行GQM會議;
    • 培訓幾個員工進行功能點計數。
    • 你也可能需要指定幾人為工作量協調員,幾人執行功能點計數並收集資料。 協調員應該為認證功能點人員,因為他們會對功能點計數進行審計,並且當出現問題時做出判斷。

返回

IFPUG
常見問題
頁面

18.1功能點顧問需要具備什麼能力?

  • 有功能點計數專業知識的人。
  • 應為IFPUG認證功能點專家(CFPS),使用SNAP時,應為CSP。
  • 應在和你相近的行業中具有功能點計數經驗。
  • 好的人際關係技能以及和你公司文化相容。
  • 具有把功能點應用到度量程式中的度量專業知識。

18.2如何確認顧問的IFPUG認證資格?

在IFPUG網站的「Public Certification Search」進行查詢。

返回

IFPUG
常見問題
頁面

19.1在哪裡找功能點顧問呢?
查看供應商清單清單中有屬於IFPUG會員的所有供應商。

19.2還有誰能當顧問?
IFPUG有世界各國的的許多會員。 會員來自各個行業,包括但不限於:

  • 航太航空
  • 銀行
  • 金融
  • 通信
  • 保險
  • 製造
  • 公用事業
  • 零售業
  • 政府
  • 電腦系統開發

IFPUG會員最大的好處之一是能訪問IFPUG會員網路(通過討論群組或郵件),那裡有會員成功經驗,包括基於FP的度量以及過程改進程式。

返回

IFPUG
常見問題
頁面

20.在哪裡可以瞭解到功能點相關的更多資訊?
參考我們的文獻/資料庫進一步瞭解功能點分析的內容。

請通過Facebook和LinkedIn和我們聯繫,歡迎您在朋友圈分享我們的資訊。

IFPUG網站,請收藏供以後參考
IFPUG Facebook主頁,請點擊「Like」
IFPUG Twitter,瞭解白皮書的最新版本和其他新聞。
IFPUG LinkedIn,請點擊「Follow」

如果要建議其他的常見問題或編輯本頁中的問題,請點擊 聯繫我們並在資訊主題中包含 「IFPUG FAQ」字樣。

會員和非會員可以從線上商城下載文檔,也可以在商城續訂或購買IFPUG會員資格。
返回