中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：UML最大特點是面向對象，與java相同，如果產品經理可以掌握UML方法，會事半功倍，減少交流成本，提高團隊效率。這篇文章從一個相關案例的UML建模準備工作出發，從獲取需求，到需求分析，再到系統分析，最后是系統設計，客觀詳細地將整個流程展開進行了敘述，推薦想要了解UML的童鞋進行閱讀。

UML是統一建模語言，它不是系統設計的方法，而是系統建模的標準?，F在無論是B端還是C端的互聯網產品都是基于java所開發而成的，java的最大特點是面向對象，UML最大的特點也是面向對象。如果產品經理掌握了UML方法，無疑可以加強團隊效率，減少交流成本。本篇文章適合有一定uml基礎的同學閱讀。

本篇文章將直接從一個關于“高職院校提前批報名系統”的建設實踐出發，從準備工作→獲取需求→需求分析→系統分析→系統設計完整流程展開敘述，其中每個模塊都參雜了我對B端產品經理業務的思考。

關于整個UML建模流程圖和如下：

一、準備工作

1. 了解業務概況，整理業務目標

在這個階段，我們的視野應當聚焦在業務中，因為B端產品的核心歸納就是“產品即服務”。在我們獲取到企業的業務需求時，我們不應當直接開始思考如何將需求實現，而是去其更上一層思考其整個業務的執行流程，思考原來的業務是否可以進行優化，我們不應只是解決企業需求的系統實現，更應該思考其業務如何優化。系統只是業務執行的效能工具，系統在業務中何時出現，何時使用才能讓企業的需求得到滿足，這才達到我們的目的。

（1）相關講解

業務概況：當你要為一個企業建設一個系統以解決其相關業務需求時，你需要去了解該業務的整個大體的流程和該業務的現運行現狀，總結出其該需求下所涉及的業務范圍。

注意??：業務范圍是我們確定業務目標的出發點，對于B端的業務一般比較復雜，所以業務可能是多角度和多模塊的，我們要將業務進行分類，劃分出大致的一個業務范圍。

業務目標：一般在去為企業解決業務需求和建立系統時，企業都會提出一些層次比較高的期望，再結合你對整個業務的了解，你可以整理出該企業此業務的業務目標。

注意??：業務目標是我們定義業務邊界的出發點，所以業務目標最好是根據整理出來的業務范圍進行。

提示?：最初確定的業務目標一定不是最準確的，在你后續調研涉眾需求、定義業務邊界、發現主角的過程中一定要帶著業務目標去思考，要前后保持一致，業務目標不是定死的，要給每個業務范圍定義一個目標，這是個反復修改的過程，包括后續的業務邊界定義、發現主角的過程都會隨之發生修改，這是一個正常的事，因為這是決定了系統的最終建設成果。

（2）實踐示例

業務概況：

① 業務流程概覽

在提前招生錄取流程中，學生完成報名工作需要經歷以下流程：根據已公布的提前批招生計劃進行選報招生錄取院校、進行繳費、申請素質特長、打印準考證、參加考試、入圍資格查詢、成績查詢、擬錄取查詢等一系列活動。

相應地，參與提前招考的高職院校需要完成：提前批考生信息初審（對報名考生的基本信息與考試院的數據進行對接）、考生報考資格篩選、考務編排、繳費收取、成績錄入、擬錄取計算、擬錄取結果發布等一系列活動。

② 現存業務問題

• 沒有標準統一化的報考系統導致部分院校線上資源利用率差，工作冗余度高，出現一個業務多個系統來完成的情況。
• 線上線下的業務執行結合度不高，也將導致業務完成效率低，增加工作人員和報考學生的負擔。
• 當前大部分高職院校所采用的招生管理系統沒有涉及到整個招考和報考流程，只局限于解決部分工作，沒有完全實現業務的數字化轉型。
• 對于系統建設主要面向PC端，未能面向移動端，不符合當下移動化操作趨勢。

③ 業務范圍分類

綜合學生報考完成工作和高職院校招生完成工作的流程，提前招生管理業務主要有：考生報考業務、考務管理業務、財務管理業務、信息管理業務等。系統應當面向學生和院校建立不同的管理終端，在各終端中需要完成各類業務，實現線上線下的業務配合，優化報考中的各個流程。

業務目標：

• 優化學生報考流程，提供考生一體化自助服務，方便考生報考，降低考生報考院校的業務復雜度。
• 優化高職院校業務處理流程，實現業務數字化覆蓋，減輕人為工作量和物理資源浪費。
• 實現財務管理電子化和繳費一站化，提高學生繳費便捷度和減少財務部門的工作復雜度。
• 實現學生信息管理、教務管理、考生結果管理統一化，規范數據庫輸入與輸出流程，提供分權限數據限調用機制。

2. 做好涉眾分析，獲取系統期望

這個階段，是為了理清、列舉所有與要建設的業務系統（B端產品）相關的一切人和事。大多數時候，我們做用戶需求調研時，直接向系統的直接使用者進行調研，對于B端產品來說是不正確的。我們要到更上一層次去分析，分析業務的利益相關者，分析系統使用者背后所代表的部門或者上級，統計一切利益相關者的期望。因為我們做的東西不僅要讓使用者滿意，更要讓使用者的領導滿意，因為不同的人對系統的視角不同，我們調查系統需求時，要站在更高的視角去分析業務的需求，最后得到的系統才能讓B端用戶滿意。

注意??：此處我們沒有直接說明為“需求”，而是“期望”，是因為，此處我們探討的是更高層次的需求，這大多是非功能性需求，以這樣的需求點出發，才能使系統建設的大方向不會出現錯誤。不會為了滿足而滿足，導致業務最終的執行未得到效率的提升。

（1）相關講解

涉眾分析：涉眾指的是系統的使用者和與業務系統有利益關系的人和事。涉眾分析就是理清所做的系統的使用者和利益涉及者。這步和調查用戶群和用戶需求是一致的。

發現涉眾步驟：列舉涉眾、說明涉眾在業務或者系統中所負責的事件、調查所列舉涉眾對業務優化或者系統建設的期望

（2）實踐示例

涉眾概要：

用戶概要：

二、獲取需求

在準備工作中，我們已經歸納出了業務的范圍，對業務的模塊有了大致的劃分。根據業務范圍的劃分，我們確定了每個業務范圍相應的業務目標。已知：業務范圍、業務目標、業務涉眾，我們就可以借此進一步探討用戶的詳細需求。

1. 定義業務邊界，回望業務目標

定義邊界其實是進一步明確業務范圍，明確該業務范圍所含的業務主角和業務工人。此處強調根據業務去劃分范圍。這里我們常常會理所當然地將系統模塊和業務邊界混淆。這是不正確的，因為系統實現的時候會出現業務范圍的交叉，也有的業務不會在系統中體現。另外一個錯誤點就是以企業現有的業務模塊進行劃分，因為業務模塊之間存在許多交互，即會產生依賴關系，我們要根據我們所調查的業務范圍的業務目標進行劃分，一個目標對應一個業務邊界。

（1）相關講解

定義邊界：根據一個業務目標對應一個業務邊界的法則，確定該業務邊界中所包含的涉眾，并在涉眾中確定誰為業務工人，誰為業務主角。

提示?：

確定業務邊界：即進一步確定業務范圍，確定該業務所對應的系統是為哪些涉眾服務的。

確定業務主角（業務主角是參與者的版型）：

• 是否有對該業務進行信息提供、信息修改或信息調用
• 是否主動發起這個業務（即在邊界中是否有其業務用例），這是其期望依據

確定業務工人（業務工人不屬于參與者）：

• 在此業務中的動作是否為被動發生
• 不是業務執行的發起者，而是業務執行的一部分

（2）實踐示例

根據第四個業務目標“實現學生信息管理、教務管理、考生結果管理統一化，規范數據庫輸入與輸出流程，提供分權限數據限調用機制?！笨芍?，該業務目標是為教務處和各院系服務，我們定以一個命名為“考務管理處理業務邊界”。

該邊界條件下，招就處、教務處、各院系都可以提出對考務相關業務處理優化的期望，所以作為該業務的業務主角位于邊界之外。

2. 發現業務主角，確定業務工人

前后一致原則，我們在此處已經確定了誰是業務主角，誰是業務工人。但是我們之前對于業務主角的描述是站在業務邊界的視角，在此我們是以業務部門進行說明，我們要站在業務主角的視角對其進行進一步說明。

（1）相關講解

業務主角：此處的業務主角是具體的與系統直接進行交互的工作人員（或者事物），之前提到的業務主角是在邊界的視角，所以是整個部門對邊界的期望。此處是系統的直接使用者，代理了其它利益相關的涉眾權力。我們應當從邊界出發，分析每個邊界的業務主角。

提問?：為什么要進一步確定業務主角？

因為一個業務邊界代表了一個業務目標，而一個業務目標代表的是該業務的業務主角的需求，我們應該圍繞該需求進行后續系統的建設，我們甚至可以忽略業務工人的需求和期望，忽略那些和業務目標無關的期望。這樣才能保證系統滿足最本質的需求，不至于為了多余的需求導致系統混亂。

提問?：為什么不直接說是系統參與者，要搞個業務主角？

因為還沒到我們分析系統用例，進行系統建模的時候。站在B端產品經理的角度，我們最終的目的就是建設系統，我們的業務調研，需求調研也是大部分圍繞系統建設展開。但是，正是因為如此，雖然我們現在“三句離不開系統”，但是此處用業務主角是要強調我們是在對業務進行分析，業務的優化和效率提升，才是我們建設系統的最終目的。此處的好處，即是提高我們深層次探討業務的意識。

（2）實踐示例

考務管理業務邊界：

1. 教務處涉眾主角分析教務處主要負責通過系統錄入考生信息并進行考務編排，教務處的主要工作人員是教務處工作人員，負責考務編排、生成準考證等，行使了考官管理處理業務的職能，因此各院系工作人員是“考務管理業務邊界”的業務主角。
2. 各院系涉眾主角分析各院系主要負責考試相關安排。其中各院系工作人員通過計算機系統進行考試面試順序、考場安排等，負責考務內部管理的職能，因此各院系工作人員是“考務管理業務邊界”的業務主角。
3. 招就處涉眾主角分析

招就處工作人員主要會在考務現場進行考生現場確認的工作，會通過考務管理系統查看考生的考試信息，因此招就處工作人員是“考務管理業務邊界”的業務主角。

3. 獲取業務用例，建立業務模型

我們從邊界出發，分析了業務主角。那獲取業務用例時，就可以從業務主角出發，去分析業務用例。

（1）相關講解

業務用例：在確定業務范圍時，我們已經分析了該業務的業務執行流程。此時，我們要從業務主角出發，調查他們的業務用例，即他們所做的事情?？梢詮膷徫皇謨?，業務流程指南、職務說明中獲得。確定業務用例，即是確定業務主角的業務需求。業務用例是一個完整的存在，它包含了業務主角對系統的期望，業務主角在業務中要完成的業務，完成對應業務的目的以及期望的結果。

業務模型：應該包含：

• 業務用例視圖：是對業務用例的羅列
• 業務用例場景：活動圖描述、時序圖描述、協作圖描述
• 業務用例規約：對業務用例的名稱、執行者、執行條件、執行過程、執行結果、業務規則進行文字描述
• 業務用例實現視圖：一個業務用例可有多個實現方式，在此用實現視圖進行列舉
• 業務用例實現場景：根據業務用例場景進行進一步繪制，重點在于“實現”

（2）實踐示例

①業務用例視圖

②業務用例場景

4.? 找到復雜問題，建立領域模型

領域模型就是發現業務某一領域中的復雜問題，分析這個問題，解決這個問題。建立領域模型就是為了將業務中復雜的問題解釋清楚。

（1）相關講解

領域模型：包含提出領域問題、分析領域問題、建立領域模型、檢驗領域模型

（2）實踐示例

①提出領域問題

②分析領域問題

③建立領域模型

5. 獲取非功能性需求，制定業務規則

（1）相關講解

業務規則包含：

• 全局規則：對于系統大部分業務或系統設計都起到約束作用的那些規則
• 交互規則：交互規則產生于用例場景中，用例場景是由活動圖、交互圖等來描述，交互規則就是描述交互過程中的限制性條件，規定了滿足什么條件后業務將如何反應
• 內稟規則：指業務對象本身具備的，并且不因為外部的交互而變化的規則。通常用來描述對象封裝的屬性

非功能性需求：非業務范圍內的需求，通常指安全性、事務性、穩定性、流暢性、美觀性相關需求。

三、需求分析

獲取需求部分，我們從發現業務主角→發現業務用例→業務用例建?！I域建?！鷺I務規則和非功能性需求?；緦⑿枨笫崂硗戤叄孟窆ぷ饕呀浗Y束了，但是在uml中遠不止此。因為雖然需求已經羅列，但是如果我們不進一步解釋那些業務是重點和難點，到設計人員手中難免會出現信息失真的情況，為減少多余的交流，我們需要進一步解釋需求的重點和難點。

1. 關鍵概念分析，建立概念模型

概念模式是圍繞關鍵業務來建立的。

（1）相關講解

①概念模型建立

過程包含：

• 獲取概念用例：首先要梳理出業務主線，然后用業務主線的用例中挑選出關鍵或復雜的用例作為概念用例進行進一步分析。
• 分析概念用例：分析概念用例和業務用例建模過程相同，我們通過繪制概念用例的場景圖找出關鍵的對象，然后為這些關鍵的對象繪制協作圖說明對象之間的關系和交互場景。
• 建立概念模型：概念模型從抽象的系統對象視角來解釋業務主線如何在計算機中運行，我們要用這些關鍵對象實現業務主線。一般采用MVC模式進行建立。

②實踐示例

2.? 建立業務架構，搭建整體框架

搭建業務架構和面向過程的結構化設計方法區別？

• 面向過程的結構化設計：按照業務模塊進行系統模塊的劃分，得到子系統和模塊
• 業務架構設計：從業務模型、概念模型中“抽取”業務構件進行組合，得到業務構件

（1）相關講解

之前已經建立了業務用例模型、領域模型和概念模型，業務用例模型為我們解釋了業務的細節，領域模型幫助我們為業務的若干問題提出了解決方案，概念模型提供了業務骨架的實現和軟件架構的實踐。業務架構從這三者出發，進行構建。

四、系統分析

很多人疑惑，產品經理為什么要做系統分析，我對產品代碼實現又不太了解。正是因為產品經理不去向技術部門提出需求的系統實現要求，直接把需求丟給技術部門，這將導致技術部門設計好產品后不符合產品經理的預期而反復修改，從而導致程序員不斷加班。所以產品經理做好系統要求后再讓技術部門進行開發，將會大大提高工作效率，降低溝通成本和修改成本。

1. 確定系統用例，分析系統用例

普遍的理解是系統用例是從業務用例中細化而來。從用例的含義來看，業務用例描述業務，而系統用例描述系統，即它們的目的截然不同。實際上，從業務用例到系統用例，更適當的說法是抽象關系，或者說是映射關系?？梢哉f是從業務用例中抽象出系統用例，也可以說把業務用例映射到系統用例。

即從業務用例中抽取出系統需要實現的用例。

2. 分析系統組成，建立組件模型

這一步我相信技術部門負責架構的童鞋應該會比產品經理更熟悉組件化開發，所以這一步可以省略。

五、系統設計

一般有產品經理崗位的公司，從需求到設計即是從產品到技術，所以這里不再講解系統的設計方法，因為技術和框架的不斷更新與變化，技術部門更懂得選用什么框架進行搭建。

所以：交給技術部門吧?

參考資料：

【1】譚云杰.《大象——Think in UML》.北京：水利水電出版社.2016

本文由 @未來村村長 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議