軟件開發質量的雙保險(2)——業務設計驗證與業務用例
編輯導語:在上篇文章《軟件質量的雙保險(1)——設計驗證與軟件測試》中,作者談到判斷軟件設計的結果是正確的,要用到“設計驗證”的方法,包括“業務設計驗證”和“應用設計驗證”兩個部分,本篇文章中,作者繼續分析了設計系統的驗證用例。
對需求工程師來說,編寫一次完整、完美的業務用例所帶來的能力提升,可匹敵多次設計同類系統的收獲,因為帶有業務場景的用例整合了架構、功能、數據、管理等多層面的內容,且由于用例是用數據、規則的細粒度寫成的,如驗證結果沒有問題則為系統上線成功提供了保證。
如果寫不出自己設計系統的驗證用例,說明他對系統是否能夠成功運行是沒有把握的。有用例幫助檢驗結果,不但能減少設計和編程錯誤,還能在設計階段就掌握上線后的細節和效果、提升客戶滿意度,同時詳細完整的用例還可以用作上線培訓資料。
一、定義
1. 業務設計驗證
通過編寫一套業務數據用以模擬某個業務處理場景的全過程,用這套數據將系統中要驗證的對象串聯起來,用以驗證業務設計的整體架構、業務流程、界面字段、數據關系、計算公式、管控規則等內容是否正確,確保系統中的業務邏輯、數據邏輯是正確的,業務設計驗證的主要工作是編寫業務用例。
2. 業務用例
是針對業務設計階段成果的驗證依據,業務用例將專業知識、業務設計部分(業務與管理)的成果,通過業務場景將流程、功能、數據、規則等串聯在一起,用以驗證業務邏輯、數據邏輯是否正確、功能是否可以滿足設計的要求。
- 用例構成:業務用例是由三個部分構成的,用例場景、數據結構圖、數據推演表;
- 編寫期間:業務用例是在業務設計期間編寫的,在業務設計完成時進行驗證。
3. 作用
業務用例的粒度包含了從架構(粗)-數據(細),因此可以精確地驗證如下的內容(不限于此)。圖1 表示了在軟件工程框架上編寫的業務用例的位置,業務驗證的作用如下:
圖1 軟件工程框架上業務用例的位置
1)支持驗證業務設計結果
- 確認業務架構的合理性、業務優化的效果;
- 檢查業務邏輯、數據邏輯的正確性,找出隱性的邏輯錯誤;
- 通過數據推演,找到業務流程設計上的“斷點”、或是“多余點”等。
2)支持應用用例的編制
作為后面應用設計用例的“業務數據來源”,與應用設計成果(界面、控件)等共同組合,形成應用用例。
3)支持測試用例的編制
由于業務用例含有精確的“業務數據”,可以為測試工程師編寫測試用例提供數據、規則等來源,同時也可以幫助測試工程師更好地理解系統的業務背景、業務邏輯。
4)支持上線培訓
業務用例的數據、規則等由于模擬的是實際業務場景,上線培訓時用戶可以直接按照業務用例中的數據進行練習,加快學習和理解的系統的速度。
5)使用對象、使用場合
- 業務設計師進行內部討論、驗證;
- 與客戶的相關部門、崗位進行溝通、確認;
- 向后續設計、驗證提供邏輯、數據的支持等。
6)對軟件客戶價值的檢驗
軟件客戶價值來源于業務設計和應用設計,其中業務設計產生的業務價值包括:
- 經過業務設計后,企業的各類過程清晰(業務流程),如:合同流程、采購流程等;
- 企業的各類規則標準化(字典),如:客商、材料、采購、支付等;
- 各類需求調研時的客戶痛點的解決方案等。
二、業務用例內容
編寫業務用例是業務設計驗證的主要工作。一個完整的業務用例由三個部分構成:用例場景、數據結構圖和數據推演表,其中:
- 用例場景:用以確定需要驗證的對象、目的;
- 數據結構圖:利用架構圖來表達用例場景的數據流轉過程;
- 數據推演表:利用數據結構圖,詳細數據、規則來推演驗證用例場景描述的過程。
1. 用例場景
一個系統的業務設計完成后,需要對那些部分進行驗證是根據需求工程師(或業務專家)的判斷來決定的,通常判斷是否需要驗證的條件如下(僅做參考):
- 業務場景、業務邏輯非常復雜的部分;
- 業務計算的邏輯復雜、數據來源復雜、且需要多重計算;
- 待開發的軟件是新產品、或涉及到新的業務;
- 軟件涉及到多人協同、多系統協同等的場景;
- 客戶對某個業務場景非常關心、且需求工程師把握也不大的情況等。
大型的、復雜系統可能要編寫多個,甚至十幾個業務用例。每個業務用例的對象、目的都不同,它們的驗證結果合起來就給出了該系統的業務設計成果是否滿足要求。
下面給出具體的用例提綱(作為后續設計用例場景),用例的數據關系參見圖2。
- 題目:工程項目的成本過程管理;
- 目的:一是驗證成本發生過程的邏輯的正確性、二是成本過程的可控性;
- 價值:充分展示“信息化環境”下的成本管理方式、帶來的價值(傳統方式做不到)。
根據上述提綱,用例場景具體數據設定如下,其中,企業為兩級組織(公司、項目部):
- 場景的起始數據①=合同總額=1100萬元;
- 目標數據④公司預留利潤額=100萬、目標數據②項目部預留利潤額=50萬;
- 預算總額分為4條線支出,即:材料線、設備線、勞務線和經費線;
- 結果數據①公司實得利潤額=80萬(減)、結果數據②項目組實得利潤額=-20萬(虧)。
這個用例場景給出了“成本管理”的關鍵環節(節點數據),有了這個關鍵節點的指引,第二步做出“數據結構圖”(驗證用的框架)、第三步寫出“數據推演表(驗證用的內容)”
2. 數據結構圖
用例場景不但要用文字描述,還需要用一個可以表達場景的數據結構圖,這個圖可以給出:場景開始的目標數據、場景結束的結果數據、以及表達從目標數據→結果數據的變化過程的結構圖。
圖2 數據結構圖
1)結構圖
數據結構圖,是以功能的結果數據為節點、以數據間的關系為連接形成的圖形,給出了從目標數據→結果數據的變化過程這個結構圖中同時體現了“業務邏輯”和“數據邏輯”。
- 形式:采用流程與分解兩種模型的混合體,來源于流程圖的流向和和數據的分解結構;
- 來源:結構圖的內容來源為用例場景;
- 節點:節點標注的是“功能名稱+數據”,這個“數據”是該功能的處理結果,節點不一定都來自于流程,也可以是“數據庫名稱+數據”;
- 關系:節點之間的關系是數據關系,前后之間是計算關系。
2)節點
根據用例的題目、場景來確定涉及到的哪些業務設計的成果,節點要素可能是一個功能(活動、字典)、或是一個數據庫,設計數據結構圖需要將所有參與場景的要素找出來,然后用數據關系把它們關聯起來。
由于本課題是“成本管理”,所以節點一定都是來自于與成本管理有關的功能(或數據庫)。圖21-7為本用例的數據結構圖,解讀如下:
- 合同總額①=1100萬,①=②+③+④=950+50+100;
- 目標1:公司預留利潤額④=100萬,結果1:公司獲得利潤額⑧=80萬(減少);
- 目標2:預算總額②=950萬, 結果2:成本結算額⑤=1020萬(超標);
- 項目部預算超額⑥:⑥=②-⑤=950–1020=-70萬,預算超額70萬;
- 項目部實際利潤⑦:⑦=③-⑥=50–70=-20萬,項目部實際利潤額為-20萬;
- 公司為項目部承擔了20萬的虧損額,因此,公司實際利潤額⑧=④+(-20)=100-20= 80萬(公司實際利潤額為80萬,減少了20萬)。
另外,要注意數據結構圖的節點設置原則:
- 節點上的數據一定是該功能內部處理完成、且與成本管理相關的數據;
- 節點上的數據必須是“數字型”(需要進行計算),而不能是“文字型”;
- 節點上只標注計算的結果,而不要計算的過程數據(留在后面的數據推演表中表達);
- 節點的粒度都要一致,包括:數據類型、數據的單位。
3. 數據推演表
有了數據結構圖,目標和結果數據后,下面用一個數據推演表,將數據結構圖中的從“目標數據”→“結果數據”的數據變化過程用完整地列出來,數據推演表涉及到的主要內容可以分為三個部分:
- 用例場景的要求,比如:項目部的預算要虧損,最終項目部利潤為負值;
- 場景中每個節點內部的數據計算方法、公式;
- 用例目的中規定的管理規則要求,如:成本過程的可控性。
數據推演表是對數據結構圖上每個節點的內部數據進行詳細地表達,每個數據推演表的最終合計值填寫到數據結構圖的相應節點上,以數據結構圖上“預算總額 = 950萬”為例,預算總額見表1。
表1 預算總額表(數據推演表) 注:表中的紅字為“父”節點。
每個節點對應一張類似上述的數據推演表,這個數據推演表里記錄的就是功能中數據和數據的計算過程。
雖然數據推演表編制時的工作量很大,但正是有了詳實的數據對后面的測試、以及系統上線培訓都起了很大的幫助,因為不返工或是減少了返工總的周期可以大幅度地縮短,提升了一次上線的成功率。
反過來也可以說明,如果復雜系統的數據不進行預先的紙上推演,怎么保證軟件開發完成后可以準確的運行呢?憑什么說設計是正確無誤的呢?
三、業務設計驗證過程
驗證過程在編寫業務場景、繪制數據結構圖的時候就開始了:
- 繪制數據結構圖的依據是對應的業務流程圖,繪制數據結構圖時可以確認業務邏輯;
- 數據結構圖上的每個節點都對應著一個具體的業務功能;
- 每個功能又對應著一個或一組原型界面;
- 每個原型界面上的數據對應著一個或一組數據推演表;
- 每個數據推演表中的數據在填寫時都必須給出清晰的數據來源;
- 確認數據推演表中的所有數據及相關計算公式、管控規則,可以確認數據邏輯。
按照這樣的方法推演下來,基本上就可以確認業務設計的結果是否正確了。
本文由 @李鴻君 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自?Unsplash,基于 CC0 協議
- 目前還沒評論,等你發揮!