功能點分析方法例題

『壹』 求AGIL功能分析模式實例

FMEA的具體內容 失效模式和效果分析FMEA有三種類型，分別是系統FMEA、設計FMEA和工藝FMEA， 確定產品需要涉及的技術能夠出現的問題 包括下述各個方面： 需要設計的新系統、產品和工藝； 對現有設計和工藝的改進； 在新的應用中或新的環境下，對以前的設計和工藝的保留使用； 形成FMEA團隊。理想的FMEA團隊應包括設計、生產、組裝、質量控制、可靠性、服務、采購、測試 以及供貨方等所有有關方面的代表。 記錄FMEA的序號日期和更改內容 保持FMEA始終是一個根據實際情況變化的實時現場記錄，需要強調的是，FMEA文件必須包括創建和更新的日期。 創建工藝流程圖 工藝流程圖應按照事件的順序和技術流程的要求而制定，實施FMEA需要工藝流程圖，一般情況下工藝流程圖不要輕易變動。 列出所有可能的失效模式效果和原因 對於工藝流程中的每一項工藝，應確定可能發生的失效模式. 如就表面貼裝工藝(SMT)而言，涉及的問題可能包括，基於工程經驗的焊球控制、焊 膏控制、使用的阻焊劑 (soldermask)類型、元器件的焊盤圖形設計等。 對於每一種失效模式，應列出一種或多種可能的失效影響， 例如，焊球可能要影響到產品長期的可靠性，因此在可能的影響方面應該註明。 對於每一種失效模式，應列出一種或多種可能的失效原因. 例如，影響焊球的可能因素包括焊盤圖形設計、焊膏濕度過大以及焊膏量控制等。 現有的工藝控制手段是基於目前使用的檢測失效模式的方法，來避免一些根本的原因。 例如，現有的焊球工藝控制手段可能是自動光學檢測(AOI)，或者對焊膏記錄良好的控制過程。 對事件發生頻率嚴重程度和檢測等級進行排序 嚴重程度是評估可能的失效模式對於產品的影響，10為最嚴重，1為沒有影響； 事件發生的頻率要記錄特定的失效原因和機理多長時間發生一次以及發生的幾率。 如果為10，則表示幾乎肯定要發生，工藝能力為0.33或者ppm大於10000。 檢測等級是評估所提出的工藝控制檢測失效模式的幾率，列為10表 示不能檢測，1表示已經通過目前工藝控制的缺陷檢測。 計算風險優先數RPN(riskprioritynumber)。 RPN是事件發生的頻率、嚴重程度和檢測等級三者乘積，用來衡量可能的工藝缺陷，以便採取可能的預防措施減少關鍵的工藝變化，使工藝更加可靠。對於工藝的矯正首先應集中在那些最受關注和風險程度最高的環節。 RPN最壞的情況是1000，最好的情況是1，確定從何處著手的最好方式是利用RPN的pareto圖，篩選那些累積等級遠低於80%的項目。 推薦出負責的方案以及完成日期，這些推薦方案的最終目的是降低一個或多個等級。對一些嚴重問題要時常考慮拯救方案，如: 一個產品的失效模式影響具有風險等級9或10； 一個產品失效模式/原因事件發生以及嚴重程度很高； 一個產品具有很高的RPN值等等。 在所有的拯救措施確和實施後，允許有一個穩定時期，然後還應該對修訂的事件發生的頻率、嚴重程度和檢測等級進行重新考慮和排序。 [編輯本段]FMEA的應用 FMEA實際上意味著是事件發生之前的行為，並非事後補救。因此要想取得最佳的效果，應該在工藝失效模式在產品中出現之前完成。產品開發的5個階段包括：計劃和界定、設計和開發、工藝設計、預生產、大批量生產。 作為一家主要的EMS提供商，Flextronics International已經在生產工藝計劃和控制中使用了FMEA管理，在產品的早期引入FMEA管理對於生產高質量的產品，記錄並不斷改善工藝非常關鍵。對於該公司多數客戶，在完全確定設計和生產工藝後，產品即被轉移到生產中心，這其中所使用的即是FMEA管理模式。 [編輯本段]手持產品FMEA分析實例 失效模式和效果分析在該新產品介紹(NPI)發布會舉行之後，即可成立一個FMEA團隊，包括生產總監、工藝工程師、產品工程師、測試工程師、質量工程師、材料采購員以及項目經理，質量工程師領導該團隊。FMEA首次會議的目標是加強初始生產工藝MPI (Manufacturing Process Instruction)和測試工藝TPI(Test Process Instruction)中的質量控制點同時團隊也對產品有更深入的了解，一般首次會議期間和之後的主要任務包括： 1．工藝和生產工程師一步一步地介紹工藝流程圖，每

『貳』 function points是什麼

function ponits analysis FPA
功能點分析方法度量的是軟體的規模，它是主要從邏輯設計的角度出發，對提供給客戶的功能進行量化的方法。所涉及的基本概念如下：

1. 功能點是針對軟體的測量單位，類似於用來測量時間的小時、測量距離的英里、測量溫度的攝氏等。由於功能點是從功能觀點來度量一個系統，因此它獨立於技術。不管採用什麼樣的語言、開發方法或硬體平台，系統的功能點數維持不變。

2. 功能點分析（FPA）是一種將系統分解成較小的單元，以便能較好地理解和分析的方法。通常採用IFPUG 規則。

3. 功能點分析在概念層面上幫助定義兩類數據抽象：靜態數據和動態數據。動態數據是通過業務進行處理的數據；靜態數據是指存儲數據，其中由本應用維護的稱為內

部邏輯文件，由其他應用維護的稱為外部介面文件。

4. 功能點計算的類型：三類主要的軟體項目類型（開發、升級、維護）。

5. 功能點計算的步驟,基本過程：確定功能點計算的類型；確定應用邊界；識別和評價業務功能類型，確定其對未調整功能點計算所起的作用；確定調整因子值(VAF)； 計算調整後的功能點計算值。

『叄』 誰能教我點數字電路裡面組合邏輯電路的功能分析的方法

加，減，乘，操作鍵按下為0，不按為1，這是負邏輯。A B C 為輸入，Y1 Y2 為 輸出。
A 為 加 的操作按鍵，按下A=0，輸出 Y1=0，Y2=1
B 為 減 的操作按鍵，按下B=0，輸出 Y1=1，Y2=0
C 為 乘 的操作按鍵，按下C=0，輸出 Y1=1，Y2=1
真值表：
A B C Y1 Y2
0 1 1 0 1 A按下， Y1 Y2 =01
1 0 1 1 0 B按下, Y1 Y2 =10
1 1 0 1 1 C按下, Y1 Y2 =11

『肆』 [軟體測試題目]一次測試用例設計的完整的過程描述

黑盒測試（Black-box Testing，又稱為功能測試或數據驅動測試）是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。

採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。

黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程序所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他類型的錯誤。

黑盒測試試圖發現以下類型的錯誤：

1）功能錯誤或遺漏；
2）界面錯誤；
3）數據結構或外部資料庫訪問錯誤；
4）性能錯誤；
5）初始化和終止錯誤。

一、黑盒測試的測試用例設計方法

·等價類劃分方法
·邊界值分析方法
·錯誤推測方法
·因果圖方法
·判定表驅動分析方法
·正交實驗設計方法
·功能圖分析方法

等價類劃分:

是把所有可能的輸入數據,即程序的輸入域劃分成若幹部分（子集）,然後從每一個子集中選取少數具有代表性的數據作為測試用例.該方法是一種重要的,常用的黑盒測試用例設計方法.

1) 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若乾等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

有效等價類:是指對於程序的規格說明來說是合理的,有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能.

無效等價類:與有效等價類的定義恰巧相反.

設計測試用例時,要同時考慮這兩種等價類.因為,軟體不僅要能接收合理的數據,也要能經受意外的考驗.這樣的測試才能確保軟體具有更高的可靠性.

2）劃分等價類的方法:下面給出六條確定等價類的原則.

①在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類.

②在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的情況下,可確立一個有效等價類和一個無效等價類.

③在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類.

④在規定了輸入數據的一組值（假定n個）,並且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.

⑤在規定了輸入數據必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）.

⑥在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.

3）設計測試用例:在確立了等價類後,可建立等價類表,列出所有劃分出的等價類:

輸入條件 有效等價類 無效等價類

... ... ...

... ... ...

然後從劃分出的等價類中按以下三個原則設計測試用例:

①為每一個等價類規定一個唯一的編號.

②設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步.直到所有的有效等價類都被覆蓋為止.

③設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步.直到所有的無效等價類都被覆蓋為止.

邊界值分析法

邊界值分析方法是對等價類劃分方法的補充.

（1）邊界值分析方法的考慮:

長期的測試工作經驗告訴我們,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.

（2）基於邊界值分析方法選擇測試用例的原則:

1）如果輸入條件規定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數據.

2）如果輸入條件規定了值的個數,則用最大個數,最小個數,比最小個數少一,比最大個數多一的數作為測試數據.

3）根據規格說明的每個輸出條件,使用前面的原則1）.

4）根據規格說明的每個輸出條件,應用前面的原則2）.

5）如果程序的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最後一個元素作為測試用例.

6）如果程序中使用了一個內部數據結構,則應當選擇這個內部數據結構的邊界上的值作為測試用例.

7）分析規格說明,找出其它可能的邊界條件.

錯誤推測法

錯誤推測法: 基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）.

因果圖方法最終生成的就是判定表. 它適合於檢查程序輸入條件的各種組合情況.

利用因果圖生成測試用例的基本步驟:

(1) 分析軟體規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予一個標識符.

(2) 分析軟體規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關系. 根據這些關系,畫出因果圖.

(3) 由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.

(4) 把因果圖轉換為判定表.

(5) 把判定表的每一列拿出來作為依據,設計測試用例.

從因果圖生成的測試用例（局部,組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入數據數目的增加而線性地增加.

前面因果圖方法中已經用到了判定表.判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期,判定表就已被當作編寫程序的輔助工具了.由於它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確.

判定表通常由四個部分組成.

條件樁（Condition Stub）:列出了問題得所有條件.通常認為列出得條件的次序無關緊要.

動作樁（Action Stub）:列出了問題規定可能採取的操作.這些操作的排列順序沒有約束.

條件項（Condition Entry）:列出針對它左列條件的取值.在所有可能情況下的真假值.

動作項（Action Entry）:列出在條件項的各種取值情況下應該採取的動作.

規則:任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.

判定表的建立步驟:（根據軟體規格說明）

①確定規則的個數.假如有n個條件.每個條件有兩個取值（0,1）,故有 種規則.

②列出所有的條件樁和動作樁.

③填入條件項.

④填入動作項.等到初始判定表.

⑤簡化.合並相似規則（相同動作）.

B. Beizer 指出了適合使用判定表設計測試用例的條件:

①規格說明以判定表形式給出,或很容易轉換成判定表.

②條件的排列順序不會也不影響執行哪些操作.

③規則的排列順序不會也不影響執行哪些操作.

④每當某一規則的條件已經滿足,並確定要執行的操作後,不必檢驗別的規則.

⑤如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要.

黑盒測試的優點

1. 基本上不用人管著，如果程序停止運行了一般就是被測試程序crash了
2. 設計完測試例之後，下來的工作就是爽了，當然更苦悶的是確定crash原因

黑盒測試的缺點

1. 結果取決於測試例的設計，測試例的設計部分來勢來源於經驗，OUSPG的東西很值得借鑒
2. 沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來作
3. 就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

黑盒測試（功能測試）工具的選擇

那麼，如何高效地完成功能測試？選擇一款合適的功能測試工具並培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不採用任何功能測試工具，從事功能測試外包項目的軟體服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟體服務企業取代。

目前，用於功能測試的工具軟體有很多，針對不同架構軟體的工具也不斷推陳出新。這里重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。

WinRunner是一種用於檢驗應用程序能否如期運行的企業級軟體功能測試工具。通過自動捕獲、檢測和模擬用戶交互操作，WinRunner能識別出絕大多數軟體功能缺陷，從而確保那些跨越了多個功能點和資料庫的應用程序在發布時盡量不出現功能性故障。

WinRunner的特點在於: 與傳統的手工測試相比，它能快速、批量地完成功能點測試; 能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差; 此外，它還能重復執行相同動作，測試工作中最枯燥的部分可交由機器完成; 它支持程序風格的測試腳本，一個高素質的測試工程師能藉助它完成流程極為復雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用; 它針對於大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基於Windows平台的應用程序實施功能測試而言帶來了極大的便利。

WinRunner的工作流程大致可以分為以下六個步驟:

1．識別應用程序的GUI

在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別後，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大區別是後者對每個測試腳本產生一個GUI文件，它能自動建立、存儲、載入，推薦初學者選用這種模式。但是，這種模式不易於描述對象的改變，其效率比較低，因此對於一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。

2．建立測試腳本

在建立測試腳本時，一般先進行錄制，然後在錄制形成的腳本中手工加入需要的TSL（與C語言類似的測試腳本語言）。錄制腳本有兩種模式: Context Sensitive和Analog，選擇依據主要在於是否對滑鼠軌跡進行模擬，在需要回放時一般選用Analog。在錄制過程中這兩種模式可以通過F2鍵相互切換。

只要看看現代軟體的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點滑鼠就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟體的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

3．對測試腳本除錯(debug)

在WinRunner中有專門一個Debug Toolbar用於測試腳本除錯。可以使用step、pause、breakpoint等來控制和跟蹤測試腳本和查看各種變數值。

4．在新版應用程序執行測試腳本

當應用程序有新版本發布時，我們會對應用程序的各種功能包括新增功能進行測試，這時當然不可能再來重新錄制和編寫所有的測試腳本。我們可以使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工作。可以使用一個call命令來載入各測試腳本。還可在call命令中加各種TSL腳本來增加批量能力。

5．分析測試結果

分析測試結果在整個測試過程中最重要，通過分析可以發現應用程序的各種功能性缺陷。當運行完某個測試腳本後，會產生一個測試報告，從這個測試報告中我們能發現應用程序的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話框等。

6．回報缺陷（defect）

在分析完測試報告後，按照測試流程要回報應用程序的各種缺陷，然後將這些缺陷發給指定人，以便進行修改和維護。

常用的功能測試方法

功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下：
1. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，並且頁面之間切換正確。
2. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。
3. 檢查按鈕的功能是否正確：如update, cancel, delete, save等功能是否正確。
4. 字元串長度檢查: 輸入超出需求所說明的字元串長度的內容, 看系統是否檢查字元串長度,會不會出錯.
5. 字元類型檢查: 在應該輸入指定類型的內容的地方輸入其他類型的內容(如在應該輸入整型的地方輸入其他字元類型),看系統是否檢查字元類型,會否報錯.
6. 標點符號檢查: 輸入內容包括各種標點符號,特別是空格,各種引號,回車鍵.看系統處理是否正確.
7. 中文字元處理: 在可以輸入中文的系統輸入中文,看會否出現亂碼或出錯.
8. 檢查帶出信息的完整性: 在查看信息和update信息時,查看所填寫的信息是不是全部帶出.,帶出信息和添加的是否一致
9. 信息重復: 在一些需要命名,且名字應該唯一的信息輸入重復的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前後輸入空格,系統是否作出正確處理.
10. 檢查刪除功能:在一些可以一次刪除多個信息的地方,不選擇任何信息,按」delete」,看系統如何處理,會否出錯;然後選擇一個和多個信息,進行刪除,看是否正確處理.
11. 檢查添加和修改是否一致: 檢查添加和修改信息的要求是否一致,例如添加要求必填的項,修改也應該必填;添加規定為整型的項,修改也必須為整型.
12. 檢查修改重名:修改時把不能重名的項改為已存在的內容,看會否處理,報錯.同時,也要注意,會不會報和自己重名的錯.
13. 重復提交表單：一條已經成功提交的紀錄，back後再提交，看看系統是否做了處理。
14. 檢查多次使用back鍵的情況: 在有back的地方,back,回到原來頁面,再back,重復多次,看會否出錯.
15. search檢查: 在有search功能的地方輸入系統存在和不存在的內容,看search結果是否正確.如果可以輸入多個search條件,可以同時添加合理和不合理的條件,看系統處理是否正確.
16. 輸入信息位置: 注意在游標停留的地方輸入信息時,游標和所輸入的信息會否跳到別的地方.
17. 上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否能夠做到。
18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*
19. 快捷鍵檢查：是否支持常用快捷鍵，如Ctrl C Ctrl V Backspace等，對一些不允許輸入信息的欄位，如選人，選日期對快捷方式是否也做了限制。
20. 回車鍵檢查: 在輸入結束後直接按回車鍵,看系統處理如何,會否報錯.您好!歡迎共同討論！有時間逛逛IT實驗室,天天軟體測試網

『伍』 項目管理中 fp數 怎麼算的

功能點分析法(FPA：function point analysis)是在需求分析階段基於系統功能的一種規模估算方法，是基於應用軟體的外部、內部特性以及軟體性能的一種間接的規模測量。FPA法由IBM的工程師艾倫·艾爾布策(Allan Albrech)於20世紀70年代提出，隨後被國際功能點用戶協會(IFPUG：The International Function Point Users' Group)提出的IFPUG方法繼承，從系統的復雜性和系統的特性這兩個角度來度量系統的規模，其特徵是：「在外部式樣確定的情況下可以度量系統的規模」，「可以對從用戶角度把握的系統規模進行度量」。功能點可以用於「需求文檔」、「設計文檔」、「源代碼」、「測試用例」度量，根據具體方法和編程語言的不同，功能點可以轉換為代碼行。經由ISO組織已經有多種功能點估算方法成為國際標准，如：①加拿大人艾倫·艾布恩(Alain Abran)等人提出的全面功能點法(full function points)；②英國軟體度量協會(UKSMA：United Kingdom Software Metrics Association)提出的IFPUG 功能點法(IFPUG function points)；③英國軟體度量協會提出的Mark II FPA功能點法(Mark II function points)；④荷蘭功能點用戶協會(NEFPUG：Netherlands Function Point Users Group)提出的NESMA 功能點法，以及軟體度量共同協會(COSMIC：the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法，這些方法都屬於艾爾布策功能點方法的發展和細化。

功能點分析法的基本計數
功能點分析的基本計數就是依據標准計算出的系統(或模塊)中所含每一種元素的數目：①外部輸入數(EI：external input)：計算每個用戶輸入，它們向軟體提供面向應用的數據。輸入應該與查詢區分開來，分別計算。②外部輸出數(EO：external output)：計算每個用戶輸出，它們向軟體提供面向應用的信息。這里，輸出是指報表、屏幕、出錯信息，等等。一個報表中的單個數據項不單獨計算。③外部查詢數(EQ：external query)：一個查詢被定義為一次聯機輸入，它導致軟體以聯機輸出的方式產生實時的響應。每一個不同的查詢都要計算。④內部邏輯文件(ILF：internal logical file)：計算每個邏輯的主文件，如數據的一個邏輯組合，它可能是某個大型資料庫的一部分或是一個獨立的文件。⑤外部介面文件(EIF：external interface file)：計算所有機器可讀的介面，如磁帶或磁碟上的數據文件，利用這些介面可以將信息從一個系統傳送到另一個系統。

『陸』 調研問卷中多選題的分析方法探討

調研問卷中多選題的分析方法探討

使用調研問卷的定量研究中，為了更全面地了解研究內容、更廣泛地收集信息，經常會用到多選題，但由於多選題多指向性的特點，除了頻數表和交叉表（只能與單選題做交叉），較少用到其他的分析方法，損失了很多有用的信息。其實，如果調研時能善用多選題，並在分析時選取適當的方法，就能夠充分利用多選題包含的信息，得到更有價值的結論。

前兩篇文章分別談到調研問卷中帶有分類性質的多選題、帶有求和性質的多選題如何進行分析，本文將側重說一下帶有遞進邏輯的多選題如何進行深入分析。

帶有遞進邏輯的多選題

問卷調研中，常會通過多選題考察用戶在某個方面不同層次的情況，如對某個賣家產品各功能的使用情況（經常使用的功能）、使用的滿意情況（滿意的功能）、需要改進的情況（亟需改進的功能）等，題目與題目之間是同一個問題的不同層次，存在遞進的邏輯關系，即使用頻率高低與是否滿意、是否亟需等，三者之間分別存在邏輯關系。

此時，這種存在遞進邏輯的多選題，可以首先考察不同題目相同選項之間的相關性；其次，能夠衍生出新的題目，進行深入分析，挖掘表面背後的原因。

其實，這種帶有遞進邏輯的多選題，可以採用量表的形式進行考察，而量表題涉及到N級量表，相當於每個項目（選項）都是一個題目，具有遞進邏輯的項目之間，進行相關分析、衍生變數分析，更能深入挖掘用戶在某一方面的綜合情況。只是為了節約用戶的填答成本，常用多選題代替。

另外，衍生出的新題目，也是可以通過直接詢問的方式獲得的，但通常題目帶有遞進邏輯時，需要用戶深入全面思考，耗費的精力較大，也容易造成理解上的偏差，給研究結論帶來較大的非抽樣誤差。因此，通過多個簡單的題目，計算出帶有遞進邏輯的結果，更易行更有效。

帶有遞進邏輯的多選題一般具備以下幾個特徵：

1、題目與題目之間的遞進邏輯存在分析價值，如對某個賣家產品各功能的考察中，賣家對產品功能是否滿意與是否亟需改進之間的遞進關系，對於產品改進的方向、改進的優先順序等有較大的參考價值。如果是滿意但亟需改進，表明該功能可能需要創新；若不滿意但沒有亟需改進，則說明該功能的改進優先順序可以適當靠後。

2、相關題目之間的選項相同，選項若不對應，或部分對應，會造成遞進邏輯關系不緊密，容易引起結果出現偏差。
會有特殊情況，如某產品經常使用的功能選項，除主要功能外，還有一個互斥的選項「不常用以上功能」；亟需改進的功能選項，除主要功能外，也有一個互斥的選項「均不需要改進」。這類情況中，題目多出來的互斥選項只是為了解決題目設置為必選時，滿足某種特殊情況，主要功能仍然是一一對應的，不對應的互斥選項，後續不進入遞進關系的分析。

3、相關題目的選項盡可能覆蓋全面，選項盡量能夠覆蓋考察的主要細節點，以免用戶過多地選擇「其他」選項，削弱了分析遞進關系的可能性。

4、相關題目的選項個數最好超過3個，如果選項只有3個或更少，將多選題改為量表題，用戶的填答成本不太大，獲得的信息會更多，後續利用遞進關系進行分析時，可以更加深入。

5、相關題目設置限選時需考慮遞進邏輯，若同時限選，限選的個數最好相同；由於遞進關系通常是由弱到強，有時可以設置遞進關系較弱的題目不限選，較強的題目限選，如滿意的功能不限選，亟需改進的功能限選，可以分析遞進關系中的強度。但如果遞進關系較弱的題目限選，而遞進關系較強的題目不限選，則容易造成解讀上的偏差，帶來不必要的麻煩。

6、數據為0/1格式，即每個選項一個變數，選中為1，未選中為0，多選題轉換成此種格式，宜於做深入分析。

當調研問卷中設置了帶有遞進邏輯的多選題，就可以採用下文介紹的方法進行深入分析。

本文中的例子，採用年初時自主發起的《賣家旺鋪選擇研究》，研究中涉及兩套遞進關系的題目：
您目前已經在用的旺鋪功能有哪些？（可多選）
您目前最需要的旺鋪功能有哪些？（可多選，最多9項）
您目前使用旺鋪主要解決了哪些問題？（可多選）
您最希望通過旺鋪幫您解決哪些問題？（可多選，最多6項）

相關分析

本文的案例主要研究旺鋪，根據版本分析更有價值。以使用拓展版旺鋪的用戶為例，分別計算已經在用的功能和最需要的功能，再對每一個功能在用的和最需要的變數做相關分析，能夠得到如下結論（詳見下圖，數字略）：

1、已經在用的高比例，同時最需要的也是高比例的功能，對於拓展版旺鋪而言，是需要維持的功能。

2、需要維持的功能中，個性化店招、數據分析工具、寶貝30天銷售量累積顯示、自定義頁面布局等功能，在用的與最需要的之間存在顯著相關（圖中已星號標注，*代表顯著相關，**代表非常顯著相關），從一個側面表明，已經在用的用戶尤為需要這些功能；而其中沒有顯著相關的功能，則不能得出這樣的結論。

3、已經在用的比例不高，而最需要的比例較高的功能，對於拓展版旺鋪而言，是需要加強的功能。

4、需要加強的功能中，營銷工具組合、不限類型的旺鋪裝修模板等功能，在用的與最需要的之間存在顯著相關，從一個側面表明，已經在用的用戶對這兩個功能的期望較高，也特別需要這兩個功能。

5、另外，從具體數據上可以看出，雖然拓展版用戶已經在用高級發貨、進銷存管理、客戶關系管理等功能的比例不高，但最需要這三個功能的比例遠超過在用的比例，表明部分拓展版用戶對這三個功能的需求很旺盛。而這三個功能是旗艦版的功能，反映了這部分用戶應該選擇更高版本的旺鋪。

註：雖然高級版本的旺鋪中包含一些特有的功能，但這些功能附屬的工具可以單獨購買，所以，會出現使用低版本旺鋪的用戶，已經在用某些高版本的功能。情況相對復雜，分析時需要注意，下文雷同，不再贅述。

衍生變數分析

以使用扶植版旺鋪的用戶為例，因為「目前使用旺鋪解決了的問題」與「最希望通過旺鋪幫助解決的問題」存在遞進邏輯關系，可以衍生出兩個比較關鍵的變數，即已經解決了且希望解決的問題、尚未解決但希望解決的問題。

有了這兩個變數，可以更加深入地分析，希望解決的問題具體情況是怎樣的，最終分析結論如下（詳見下圖，數字略）：

1、提升店鋪的流量、增加店鋪的可信度、增加店鋪的專業程度等，是使用扶植版旺鋪的用戶非常關注的問題，不論目前是否解決，都非常希望通過旺鋪解決，表明這三方面是需要維持的利益點，也是宣傳扶植版旺鋪的重點。

2、裝修更便利、店鋪更美觀等，是目前解決了，但仍希望通過旺鋪解決的問題，表明這部分使用扶植版旺鋪的用戶，對裝修的便利性、裝修效果等更重視，希望能做到更好，可以對他們做相應的培訓，或直接向他們推薦裝修更靈活、呈現更多樣的高版本旺鋪。（之所以得到這樣的結論，主要是因為最希望通過旺鋪解決的問題是多選限選，可以根據以往研究經驗，假設需求強度不大，已經解決了，就不會再選了。）

3、提升寶貝的轉化率/成交量、增加寶貝的點擊率、增加買家在店鋪的停留時長等，是目前尚未解決，但希望能夠通過旺鋪解決的問題，表明這部分扶植版旺鋪的用戶比較直接、實際，非常看重流量和銷量，可以對他們做相應的指導，也可推薦引流量的工具或服務。

利用衍生變數深入分析

本研究中在詢問功能和解決的問題時，將多個版本的內容融合在一起，後續分析時，可以分析出目前使用某個版本的用戶，目前是否適合當前版本，如果不適合，如何引導他們使用更適合的版本；如果適合，是否已經用得足夠好，用得不好，如何幫助他們。這些疑問，可以利用衍生變數進行深入分析，從而得到答案。

以使用標准版旺鋪的用戶為例，首先要明確四個前提步驟：

Step1、由於功能和解決的問題是多個版本融合在一起，需要分清哪些功能是當前版本的，哪些是更高版本才有的，旺鋪的高版本兼具低版本的功能。

Step2、分析中需要結合旺鋪版本，衍生出一個變數，叫做「更適合的功能點」，即目前未使用，但最需要的功能，且這個功能又是更高版本的旺鋪功能；
還需要衍生出另一個變數，叫做「未用好的功能點」，即目前未使用，但最需要的功能，且這個功能是當前版本具備的旺鋪功能。

Step3、以往的定性調研表明，一個使用低版本旺鋪的用戶之所以選擇更高版本，往往是看上了高版本的其中一個功能，如寶貝30天銷量累積顯示。
本例在判斷部分使用當前版本的用戶，實際上適合更高版本旺鋪時，採用了保守的方式，找出前提2中排名前三位的「更適合的功能點」，取平均值，把它當做更適合高版本旺鋪的當前版本用戶的比例。主要基於假設，這些功能對他們相當重要，理想狀態下，後續他們會因為這些功能轉用高版本旺鋪。
同樣，適合但未用好當前版本的用戶，也採用了類似的方式計算比例，此不贅述。

Step4、若判定部分當前版本用戶適合更高版本旺鋪，還需要有促使他們轉換的利益點，這些利益點也可以由衍生變數得到，即目前使用旺鋪未解決但最希望通過旺鋪解決的問題。

也可以找出適合當前版本但未用好的比例，摸清哪些功能點他們沒有用好，能夠更有針對性地培訓，使其充分發揮旺鋪的功能。

小結

綜上所述，帶有遞進邏輯的多選題，分析的流程如下：

1、確定在設計問卷時，是否包含遞進邏輯的多選題，並確保題目的遞進關系存在解讀價值、應用價值；

2、根據題目的特點，衍生出新的變數；

3、根據衍生變數的統計量，深入分析樣本的相關情況；

4、可以根據其他關鍵變數（如旺鋪版本、星級等）對衍生變數做進一步分析，從而得出更深入的研究結論。

以上是小編為大家分享的關於調研問卷中多選題的分析方法探討的相關內容，更多信息可以關注環球青藤分享更多干貨

『柒』 功能點估演算法的規模估算

1. 識別功能點的類型。
2. 識別待估算應用程序的邊界和范圍。
3. 計算數據類型功能點所提供的未調整的功能點數量。
4. 計算人機交互功能所提供的未調整的功能點數量。
5. 確定調整因子。
6. 計算調整後的功能點數量。 通過對需求說明書的分析，我們可以使用「功能點」來對軟體產品所提供給用戶的功能加以度量。程序長度和復雜性都是對程序的事後分析，軟體功能性卻可在軟體開發的初期進行分析，這對我們預測項目規模，規劃項目時間表非常有幫助。
Albrecht的度量方式是先按需求描述對功能點計數，得到未調整功能點，再按系統涉及到的技術功能點對該數值進行修正。
按照軟體表示技術，一項需求可描述為若干外部輸入、外部輸出、外部請求、外部文件、內部文件的集合。對集合中每一子項進行計數，並按其復雜性指派相應的權重，可得未調整功能點UFC：
n
UFC = ∑ (項目i的權重*權重i)
i=1
任何需求的實現，總與一定的技術有關。Albrecht定義了14項技術特性，對應每一特性有一個從0到5的關聯值Fi（0說明此項技術特性與功能實現毫無關系，5說明此項技術特性是系統建立必不可少的組成部分）。一項需求的技術復雜性特性值TCF即由這些評分合成，公式如下：
14
TCF = 0.65 + 0.01 ∑ Fi
i=1
最後，功能點的度量值FP，為以上二者的乘積：
FP = UFC * TCF

『捌』 功能點估演算法的估算過程

估算的過程主要包括規模估算、規模調整、估算工作量、估算工期和確定預算。上一部分主要講解了估算規模和規模調整這兩部分。
根據調整後軟體規模，估算工作量，公式如下：AE=(PDR*S)*SWF*RDF
估算工期可根據工作量-工期模型計算，公式如下：D=1.277*(AE/HM 1 )0.404，當期望工期短於估算工期的下限時，應對項目需求進行分析並適當調整。通常，壓縮工期會增加項目工作量，及導致生產效率降低。
在獲得了工作量估算結果後，可採用以下公式估算項目預算：P=AE/HM 2 *F 2 +DNC
審批預算時應考慮以下因素：預算的合理性；可用於本項目的資金情況；概算或年初總預算額；其他預算項目可行性及投資收益率對比和平衡。（以上內容均摘自行標《軟體研發成本度量規范》）