HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-下篇

1、開篇

      上一篇《HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇》咱們詳細分析了在架構分析過程當中咱們須要注意的內容，架構過程的方法論及實踐經驗，以更好的指導咱們在具體架構落地。

       本篇主將具體結合HRMS系統進行架構概要分析，按照上篇的理論指導，開展具體的架構分析過程實踐，經過分析找到關鍵功能、關鍵非功能性需求（關鍵質量及約束）等。

      在闡述具體的架構工做方法以前，請你們先查看如下三方面的內容：

     一、HRMS系統的介紹？（涵蓋哪些功能？價值和做用是什麼？行業什麼狀況？）

      請閱讀《HRMS(人力資源管理系統)-從單機應用到SaaS應用-系統介紹》

      二、本章分析的內容將圍繞4類企業表明的業務場景，（區分不一樣規模企業的關注點，規模將決定系統的設計方案）

      本篇將圍繞4類企業表明來闡述不一樣規模企業對於HRMS的需求及應用

•       A、100人如下的中小企業
•       B、500人如下的大中型企業
•       C、1000人以上的集團化大企業
•       D、全球類型的公司體系（幾萬人）

      三、架構師在設計該系統時的職責及具有的核心能力是什麼？

      請閱讀《系統架構系列-開篇介紹》

 

1、架構準備階段主要作什麼？

       架構準備階段主要是圍繞系統的全方位的需求分析來開展相關準備工做的，這裏的需求涵蓋功能性及非功能性2大類需求，非功能性需求又涵蓋質量屬性及約束兩項內容，咱們在實際的分析過程當中須要重點考慮業務功能、質量屬性及約束等內容，具體可採起表格方式進行梳理，藉助科學的方法找出來哪些是關鍵功能、哪些是關鍵質量需求、哪些是關鍵約束。

關鍵功能、關鍵質量屬性及關鍵約束等內容對於架構設計的實際影響有哪些呢？在這裏咱們梳理成表格來呈現這樣你們有一個比較直觀的感覺：

架構是圍繞需求來開展的，在對需求綜合分析的過程當中，咱們將需求劃分爲3個層次：

業務級需求：包含客戶或出資者要達到的業務目標、預期投資、工期要求，以及要符合哪些標準、對哪些遺留系統進行整合等約束條件；

用戶級需求：用戶使用系統來輔助完成哪些工做。對質量要求如何。用戶羣及所處的使用環境方面有何特殊要求。

開發級需求：開發人員須要實現什麼。開發期間、維護期間有何質量考慮。開發團隊的哪些狀況會反過來影響架構。

　　對於此三類需求弄清楚以後，就能夠造成一個初步的需求列表。

　　一方面爲了知足上述3類需求，同時還考慮到影響架構設計3個維度方面的內容，咱們採起ADMEMS的需求類型及需求層次的二維矩陣表，來進行結構化的梳理，這樣更直觀也更清晰，我這裏先將考慮的維度放在這，後面關於HRMS系統的需求分析的過程當中我將按照該方法進行整理：

咱們瞭解了需求的層次、需求的類型，知道了他們對於架構的影響，也熟悉瞭解了他們之間的關聯關係，那接下來對咱們來講最重要的就是理清思路，如何把需求全方位的陳列出來，利用需求層次及需求分類羅列整理。HRMS系統很是的複雜，功能較多，應用的場景及類型也比較繁多，因此最好的方式就是把需求列清晰：

經過需求的結構化整理，須要從這些需求中找到關鍵功能、關鍵質量及關鍵約束，並將關鍵質量、關鍵約束轉化爲衍生的設計需求：

一、肯定業務功能

關鍵的業務功能包含以下四個方面：1.核心功能；2.必作功能；3.高風險功能；4.獨特功能。

　　如何區別這四個方面，其實是靠經驗和感受。它們之間其實是有重疊部分的。

核心功能：業務層接口所反映的功能。如，HRMS系統中，前面說的8大業務內容都屬於核心功能；

必作功能：必作功能其實是以客戶爲背景的，簡單來講就是願景；

高風險功能：顧名思義，哪些功能操做可能會涉及到安全和隱私等問題；

獨特功能：實際是上訴三個功能的補集，看看還有哪些沒有覆蓋到的，卻又很關鍵的功能。

　　架構師在設計階段要考慮到「關鍵功能」所佔有的比例，沒有明確的標準，通常遵循：功能少的系統比例高一些，功能多的系統比例少一些。

二、梳理非功能性需求涵蓋質量及約束需求，將這些質量及約束背後的衍生需求梳理清晰：

關於質量要求這塊的內容涵蓋的範圍很是的普遍，涵蓋：1.性能  2. 安全性 3.持續可用性 4.可靠性 5.魯棒性 6.易用性 7.可測試性 8.可重用性 9.可維護性 10.可擴展性 11.可移植性 12 可互操做性等。咱們在作HRMS系統架構設計時考慮的質量屬性裏面也不須要把每個指標都作上去。這些指標之間是相互影響的。其影響關係以下（+表示促進  －表示影響  空白表示無明顯做用）：

當出現多個質量屬性出現互斥的時候，必需要權衡以哪一個爲主，那相應的另一個質量屬性就會弱化。

在架構設計中，對非功能性需求的重視程度，也會影響架構設計的好與劣；但也要平衡過渡設計和適可而止的關係。

2、如何找出關鍵的功能性、非功能性需求、關鍵約束？

 

一、找到系統的關鍵功能（系統具體是作什麼的？）

咱們能夠採起職責鏈模式來梳理關鍵功能：

模擬不一樣類型的用戶如何經過系統實現業務需求的過程，藉助系統化的思惟模擬跟蹤各環節，梳理清晰後便可得出清晰的職責鏈，這樣即可以找出各鏈上的關鍵功能點，這些關鍵點便是關鍵功能。藉助職責鏈模式來梳理核心功能，確認系統中存在必要功能、HRMS系統中的8大業務模塊，這裏再強調下：

上面8項屬於核心功能。除此以外，還應該會有流程管理、權限管理等功能，輔助及支撐系統運行的基礎功能。

二、肯定關鍵質量的5大原則（找出關鍵質量屬性）

• Ø分類合適+必要擴充

       針對質量分類進行細化及分解

• Ø考慮多方涉衆

       用戶不只關注功能，同時也須要質量，用戶關注的質量可能包括易用性、性能、持續可用性、魯棒性等，客戶不必定是最終用戶，好比超市銷售系統的客戶是超市老闆，但最終用戶多是收銀員或上貨員，他們所關注的質量屬性可能不一致。

• Ø檢查性思惟

       隨時檢查各個質量屬性，看看每一項是否確實算不上「關鍵質量」，從而防止遺漏關鍵需求。

•  
• Ø識別矛盾+劃定優先級

      

       肯定這些質量屬性之間的矛盾關係，明確以哪些質量屬性爲主。

• Ø嚴格程度符合領域與規模特色

       嚴格程度符合領域與規模特色

       關鍵質量屬性個數根據項目、產品、平臺不一樣而不同

       諸如：銀行項目（注重安全性、易用性）;互聯網服務項目（注重持續可用性、易用性、性能、可靠性等）

三、找出關鍵約束並將這些約束轉化爲功能或質量需求

首先，按照4類約束進行羅列（儘量全面）

其次、分析約束面向的功能、質量方面的轉化

最後、肯定這些約束轉化後的功能、質量是否重要

四、•第1步：需求結構化；•第2步：分析約束影響；•第3步：肯定關鍵質量；•第4步：肯定關鍵功能

3、HRMS系統的關鍵功能、關鍵質量指標及約束

不管上一篇《HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇》介紹的，仍是本篇前面介紹的內容基本上都是理論偏多一些，固然其中有一些具體的原則及操做方法，可能你們還不清楚具體的如何下手，若是真來一個項目，我該怎麼按部就班、由淺入深呢？下面咱們就以HRMS爲例來簡單說明，咱們來具體實際操做一下你們就會有比較清晰的認識了，但願你們可以掌握其中的精髓。須要多實踐和總結。

3.一、梳理出需求層次及需求類型（造成表格）

在前面咱們描述了4類企業類別，在梳理需求前，我這邊根據實際狀況將企業劃分爲4類：

•       A、100人如下的中小企業
•       B、500人如下的大中型企業
•       C、1000人以上的集團化大企業
•       D、全球類型的公司體系（幾萬人）

咱們可直觀看出上述按照企業的規模、人員數量來進行的劃分，由於咱們都知道在系統架構設計時，通常來講規模及數量對於架構的影響是決定性的，因此這裏先基於這個維度來對企業分類。

3.1.1 業務級需求

       前面咱們羅列的HRMS系統的功能，我這裏不在重複羅列，我認爲這8項是基礎業務級需求，上述的4類企業都須要提供這些功能。（具體請參考上面的HRMS系統功能圖）

       同時爲了區分不一樣規模、人員數量企業的差別性，我這邊又整理了幾方面的需求內容，模擬甲方提出：

       注意事項：（前面規模較小的公司個性化的功能，後面規模較大的企業默認會有這些功能，因此不少內容我沒有重複列出）

    A、100人如下的中小企業（單個企業內部使用）

• 不一樣的用戶看到的內容不一樣、能夠單獨管理各自內部的事宜
• 業務審批流程，支持自定義
• 與郵件系統、OA、財務系統等集成
• LInux環境、java語言、內外網都可使用
• 須要提供app與pc端服務接入
• 數據統計及分析
  

    B、500人如下的大中型企業（多個公司內使用）

• 支持多分公司管理模式（不一樣分公司看到的模塊及數據不一樣，相互隔離，總部能看到）
• 各分公司主要是做爲業務拓展，按照總部的管理流程及制度來執行
• 功能優化及升級，由總部統一規劃及實施，各地能夠提需求
• 硬件及軟件環境由總部統一管理及維護
• 採起雲端部署模式，部署前需各地提出相關需求
• 支持wap、微信等服務接入
• 大數據跟蹤（指導各部門的人力資源及管理優化）
  

     C、1000人以上的集團化大企業（業務拆分模式的集團化公司）

• 大集團公司下設多個小集團公司，各集團公司的業務不一樣和垂直化分公司的管理模式不一樣，須要系統支持該類型的配置管理
• 信息流轉及上報的業務線須要跨多個公司及職級，業務線不能亂。
• 各集團子公司自定義內部的管理體系，總公司制定統一工做要求並給予指導
• 總公司及各子公司均有信息中心，各自建設內部的信息化，最終經過總公司信息中心進行統籌
• 科學決策及指導（人才戰略）
  

     D、全球類型的公司體系（幾萬人）（跨國公司）

• 不一樣國家分公司的內部管理系統的功能模塊不一樣
• 系統支持各地國家當地的語言
• 總部、分公司及下屬部門間的信息聯動及共享支持，可按層級設置彙報線及審批流
• HRMS系統接入的第三方系統略有不一樣（OA、ERP等）,根據不一樣國家的公司狀況，各公司統籌，對於總公司統籌的服務，各分公司按要求使用
• 企業指揮艙（內部+外部）

 

3.1.2 質量屬性

A、開發期質量

       通常來講，甲方不會是專業的軟件公司，若是是默認甲方會內部自主提出相應的需求提出具體的設計規劃方案，這其中便會考慮系統的質量要求，對於開發過程當中的質量要求通常須要在架構設計時主動考慮，提供相應的問題來諮詢或爲甲方提供專業的建議及諮詢。對於甲方確認的內容可重點關注，對於甲方沒有主動提出的，須要咱們根據行業經驗作好判斷來落實。

基於前面模擬提出的個性化的需求，咱們來綜合梳理下開發期的質量要求：

\	<=100人	<=500人	<=1000人	<=10000人
可擴展性	暫時可不考慮	必備	必備	必備
可重用性	不是特別強烈（重用性方面主要是針對基礎組件方面須要考慮）	必備	必備	必備
可測試性	必備	必備	必備	必備
易理解性	必備	必備	必備	必備
可維護性	必備	必備	必備	必備
可移植性	暫時可不考慮	需考慮，但非必須	必備	必備

基於上面的分析，咱們已基本確認了不一樣規模的企業的HRMS系統須要考慮的質量屬性略有不一樣。

B、運行期質量

針對運行期的質量考慮，主要是基於用戶使用過程當中的各種場景來展開進行分析，提取出上述幾類質量屬性方面的要點：

\	<=100人	<=500人	<=1000人	<=10000人
性能	100人，數據量較小，暫時可不考慮	500人使用時性能也不須要特別的考慮，業務量及數據量都不會太大	通常	高
安全性	內網部署，非外網隔離，安全性級別（高）	較高	較高	較高
易用性	需考慮，要求較低	通常	通常	高
持續可用性	要求不高，上班期間使用	通常	較高	較高
可伸縮性	暫時可不考慮	暫時可不考慮	通常	高
互操做性	需考慮（但要求不高）	需考慮，涉及到多個子公司，須要考慮差別性的互操做性	通常	高
可靠性	高	高	較高	較高
魯棒性	需考慮（要求不高）	需考慮（通常）	較高	較高

相對於開發期的質量屬性來講，運行期的質量屬性更多、更復雜、更重要，因此咱們須要特別重視。

 

3.1.3 系統約束

基於前面列出的應用需求，咱們綜合4類企業的約束，造成統一的約束清單：

約束類型	具體說明
業務環境約束	上線時間：3個月 預算限制：性價比高 集成環境：公司內部OA、郵件等系統與外部社保系統等鏈接 政策及法規：受制於人力資源管理相應的辦法
使用環境約束	何階層用戶：員工、HR、高管等 年齡段和偏好：覆蓋22歲~65歲 多個國家：（多語言支持） 是否存在網絡較弱或延遲狀況：會存在，因此須要考慮信息的臨時存儲及恢復 設備移動的狀況下：須要提供移動端設備訪問
開發環境約束	技術水平：團隊技術水平高,掌握java語言 城市分佈：多個城市 磨合程度：通常 開發管理程度：較高 源代碼保密：高 網絡環境：良好
技術環境約束	技術平臺：Java、Linux 中間件：Spring cloud、Redis等 編程語言的流行度：主流 認同度：高 優缺點：應用語言，性能問題須要考慮

       上面咱們系統化的梳理了系統的業務功能、質量屬性及約束內容，下面咱們採起需求層次-需求類型二維矩陣來找出關鍵功能、關鍵質量屬性及關鍵約束。

3.二、肯定關鍵功能、關鍵質量屬性及關鍵約束

      在肯定關鍵功能、質量屬性及約束以前，我想再限定和說明個前提，以便你們更好的理解，咱們須要開發一個SaaS版本的系統，全方位的支持上述4類企業的需求，過程當中咱們做爲一個企業，須要考慮成本、商業模式、企業將來的戰略及盈利等方面的內容。

       因此基於這些約束及現狀，咱們能夠梳理得出如下的關鍵功能及質量、約束的表格。做爲後續咱們作概要架構的前提和基礎。

上表的具體的推演過程以下：

A、肯定組織級的功能、質量、約束等內容

B、肯定用戶級的功能、質量、約束等內容

C、肯定開發級的質量及約束等

D、將約束衍生爲質量屬性及功能、將質量屬性衍生爲功能

將關鍵約束衍生爲功能：

根據功能提煉出非功能性需求：

E、造成統一的二維表（造成關鍵結果）

（如上表）

F、總結

       經過上述的幾個環節，咱們把不一樣類型的約束轉化爲質量屬性及功能需求，最終咱們造成了最終的需求二維矩陣，這將爲咱們的架構指明方向，後續咱們再作架構的設計及規劃的時候就可以作到有的放矢，不會走錯方向。

 

4、更多信息

關於更多的系統架構方面的知識，我已創建了交流羣，相關資料會第一時間在羣裏分享，歡迎你們入羣互相學習交流：

微信羣：（掃碼入羣-名額有限）