HRMS(人力資源管理系統(tǒng))-從單機(jī)應(yīng)用到SaaS應(yīng)用-架構(gòu)分析(功能性、非功能性、關(guān)鍵約束)-下篇

一、開篇

上一篇《HRMS(人力資源管理系統(tǒng))-從單機(jī)應(yīng)用到SaaS應(yīng)用-架構(gòu)分析(功能性、非功能性、關(guān)鍵約束)-上篇》我們詳細(xì)分析了在架構(gòu)分析過程中我們需要注意的內(nèi)容，架構(gòu)過程的方法論及實踐經(jīng)驗，以更好的指導(dǎo)我們在具體架構(gòu)落地。

本篇主將具體結(jié)合HRMS系統(tǒng)進(jìn)行架構(gòu)概要分析，按照上篇的理論指導(dǎo)，開展具體的架構(gòu)分析過程實踐，通過分析找到關(guān)鍵功能、關(guān)鍵非功能性需求（關(guān)鍵質(zhì)量及約束）等。

在闡述具體的架構(gòu)工作方法之前，請大家先查看以下三方面的內(nèi)容：

1、HRMS系統(tǒng)的介紹？（涵蓋哪些功能？價值和作用是什么？行業(yè)什么情況？）

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

2、本章分析的內(nèi)容將圍繞4類企業(yè)代表的業(yè)務(wù)場景，（區(qū)分不同規(guī)模企業(yè)的關(guān)注點，規(guī)模將決定系統(tǒng)的設(shè)計方案）

本篇將圍繞4類企業(yè)代表來闡述不同規(guī)模企業(yè)對于HRMS的需求及應(yīng)用

A、100人以下的中小企業(yè)

B、500人以下的大中型企業(yè)

C、1000人以上的集團(tuán)化大企業(yè)

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

3、架構(gòu)師在設(shè)計該系統(tǒng)時的職責(zé)及具備的核心能力是什么？

請閱讀《系統(tǒng)架構(gòu)系列-開篇介紹》

一、架構(gòu)準(zhǔn)備階段主要做什么？

架構(gòu)準(zhǔn)備階段主要是圍繞系統(tǒng)的全方位的需求分析來開展相關(guān)準(zhǔn)備工作的，這里的需求涵蓋功能性及非功能性2大類需求，非功能性需求又涵蓋質(zhì)量屬性及約束兩項內(nèi)容，我們在實際的分析過程中需要重點考慮業(yè)務(wù)功能、質(zhì)量屬性及約束等內(nèi)容，具體可采取表格方式進(jìn)行梳理，借助科學(xué)的方法找出來哪些是關(guān)鍵功能、哪些是關(guān)鍵質(zhì)量需求、哪些是關(guān)鍵約束。

關(guān)鍵功能、關(guān)鍵質(zhì)量屬性及關(guān)鍵約束等內(nèi)容對于架構(gòu)設(shè)計的實際影響有哪些呢？在這里我們梳理成表格來呈現(xiàn)這樣大家有一個比較直觀的感受：

架構(gòu)是圍繞需求來開展的，在對需求綜合分析的過程中，我們將需求劃分為3個層次：

業(yè)務(wù)級需求：包含客戶或出資者要達(dá)到的業(yè)務(wù)目標(biāo)、預(yù)期投資、工期要求，以及要符合哪些標(biāo)準(zhǔn)、對哪些遺留系統(tǒng)進(jìn)行整合等約束條件；

用戶級需求：用戶使用系統(tǒng)來輔助完成哪些工作。對質(zhì)量要求如何。用戶群及所處的使用環(huán)境方面有何特殊要求。

開發(fā)級需求：開發(fā)人員需要實現(xiàn)什么。開發(fā)期間、維護(hù)期間有何質(zhì)量考慮。開發(fā)團(tuán)隊的哪些情況會反過來影響架構(gòu)。

對于此三類需求弄清楚之后，就可以形成一個初步的需求列表。

一方面為了滿足上述3類需求，同時還考慮到影響架構(gòu)設(shè)計3個維度方面的內(nèi)容，我們采取ADMEMS的需求類型及需求層次的二維矩陣表，來進(jìn)行結(jié)構(gòu)化的梳理，這樣更直觀也更清晰，我這里先將考慮的維度放在這，后面關(guān)于HRMS系統(tǒng)的需求分析的過程中我將按照該方法進(jìn)行整理：

我們了解了需求的層次、需求的類型，知道了他們對于架構(gòu)的影響，也熟悉了解了他們之間的關(guān)聯(lián)關(guān)系，那接下來對我們來說最重要的就是理清思路，如何把需求全方位的陳列出來，利用需求層次及需求分類羅列整理。HRMS系統(tǒng)非常的復(fù)雜，功能較多，應(yīng)用的場景及類型也比較繁多，所以最好的方式就是把需求列清晰：

通過需求的結(jié)構(gòu)化整理，需要從這些需求中找到關(guān)鍵功能、關(guān)鍵質(zhì)量及關(guān)鍵約束，并將關(guān)鍵質(zhì)量、關(guān)鍵約束轉(zhuǎn)化為衍生的設(shè)計需求：

1、確定業(yè)務(wù)功能

關(guān)鍵的業(yè)務(wù)功能包含如下四個方面：1.核心功能；2.必做功能；3.高風(fēng)險功能；4.獨特功能。

如何區(qū)別這四個方面，實際上是靠經(jīng)驗和感覺。它們之間實際上是有重疊部分的。

核心功能：業(yè)務(wù)層接口所反映的功能。如，HRMS系統(tǒng)中，前面說的8大業(yè)務(wù)內(nèi)容都屬于核心功能；

必做功能：必做功能實際上是以客戶為背景的，簡單來說就是愿景；

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

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

架構(gòu)師在設(shè)計階段要考慮到“關(guān)鍵功能”所占有的比例，沒有明確的標(biāo)準(zhǔn)，一般遵循：功能少的系統(tǒng)比例高一些，功能多的系統(tǒng)比例少一些。

2、梳理非功能性需求涵蓋質(zhì)量及約束需求，將這些質(zhì)量及約束背后的衍生需求梳理清晰：

關(guān)于質(zhì)量要求這塊的內(nèi)容涵蓋的范圍非常的廣泛，涵蓋：1.性能? 2. 安全性 3.持續(xù)可用性 4.可靠性 5.魯棒性 6.易用性 7.可測試性 8.可重用性 9.可維護(hù)性 10.可擴(kuò)展性 11.可移植性 12 可互操作性等。我們在做HRMS系統(tǒng)架構(gòu)設(shè)計時考慮的質(zhì)量屬性里面也不需要把每一個指標(biāo)都做上去。這些指標(biāo)之間是相互影響的。其影響關(guān)系如下（+表示促進(jìn)? －表示影響? 空白表示無明顯作用）：

當(dāng)出現(xiàn)多個質(zhì)量屬性出現(xiàn)互斥的時候，必須要權(quán)衡以哪個為主，那相應(yīng)的另外一個質(zhì)量屬性就會弱化。

在架構(gòu)設(shè)計中，對非功能性需求的重視程度，也會影響架構(gòu)設(shè)計的好與劣；但也要平衡過渡設(shè)計和適可而止的關(guān)系。

二、如何找出關(guān)鍵的功能性、非功能性需求、關(guān)鍵約束？

1、找到系統(tǒng)的關(guān)鍵功能（系統(tǒng)具體是做什么的？）

我們可以采取職責(zé)鏈模式來梳理關(guān)鍵功能：

模擬不同類型的用戶如何通過系統(tǒng)實現(xiàn)業(yè)務(wù)需求的過程，借助系統(tǒng)化的思維模擬跟蹤各環(huán)節(jié)，梳理清晰后即可得出清晰的職責(zé)鏈，這樣便可以找出各鏈上的關(guān)鍵功能點，這些關(guān)鍵點即是關(guān)鍵功能。借助職責(zé)鏈模式來梳理核心功能，確認(rèn)系統(tǒng)中存在必要功能、HRMS系統(tǒng)中的8大業(yè)務(wù)模塊，這里再強(qiáng)調(diào)下：

上面8項屬于核心功能。除此之外，還應(yīng)該會有流程管理、權(quán)限管理等功能，輔助及支撐系統(tǒng)運行的基礎(chǔ)功能。

2、確定關(guān)鍵質(zhì)量的5大原則（找出關(guān)鍵質(zhì)量屬性）

?分類合適+必要擴(kuò)充

針對質(zhì)量分類進(jìn)行細(xì)化及分解

?考慮多方涉眾

用戶不僅關(guān)注功能，同時也需要質(zhì)量，用戶關(guān)注的質(zhì)量可能包括易用性、性能、持續(xù)可用性、魯棒性等，客戶不一定是最終用戶，比如超市銷售系統(tǒng)的客戶是超市老板，但最終用戶可能是收銀員或上貨員，他們所關(guān)注的質(zhì)量屬性可能不一致。

?檢查性思維

隨時檢查各個質(zhì)量屬性，看看每一項是否確實算不上“關(guān)鍵質(zhì)量”，從而防止遺漏關(guān)鍵需求。

?識別矛盾+劃定優(yōu)先級

確定這些質(zhì)量屬性之間的矛盾關(guān)系，明確以哪些質(zhì)量屬性為主。

?嚴(yán)格程度符合領(lǐng)域與規(guī)模特點

嚴(yán)格程度符合領(lǐng)域與規(guī)模特點

關(guān)鍵質(zhì)量屬性個數(shù)根據(jù)項目、產(chǎn)品、平臺不同而不一樣

諸如：銀行項目（注重安全性、易用性）;互聯(lián)網(wǎng)服務(wù)項目（注重持續(xù)可用性、易用性、性能、可靠性等）

3、找出關(guān)鍵約束并將這些約束轉(zhuǎn)化為功能或質(zhì)量需求

首先，按照4類約束進(jìn)行羅列（盡可能全面）

其次、分析約束面向的功能、質(zhì)量方面的轉(zhuǎn)化

最后、確定這些約束轉(zhuǎn)化后的功能、質(zhì)量是否重要

4、?第1步：需求結(jié)構(gòu)化；?第2步：分析約束影響；?第3步：確定關(guān)鍵質(zhì)量；?第4步：確定關(guān)鍵功能

三、HRMS系統(tǒng)的關(guān)鍵功能、關(guān)鍵質(zhì)量指標(biāo)及約束

無論上一篇《HRMS(人力資源管理系統(tǒng))-從單機(jī)應(yīng)用到SaaS應(yīng)用-架構(gòu)分析(功能性、非功能性、關(guān)鍵約束)-上篇》介紹的，還是本篇前面介紹的內(nèi)容基本上都是理論偏多一些，當(dāng)然其中有一些具體的原則及操作方法，可能大家還不清楚具體的如何下手，如果真來一個項目，我該怎么循序漸進(jìn)、由淺入深呢？下面我們就以HRMS為例來簡單說明，我們來具體實際操作一下大家就會有比較清晰的認(rèn)識了，希望大家能夠掌握其中的精髓。需要多實踐和總結(jié)。

3.1、梳理出需求層次及需求類型（形成表格）

在前面我們描述了4類企業(yè)類別，在梳理需求前，我這邊根據(jù)實際情況將企業(yè)劃分為4類：

A、100人以下的中小企業(yè)

B、500人以下的大中型企業(yè)

C、1000人以上的集團(tuán)化大企業(yè)

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

我們可直觀看出上述按照企業(yè)的規(guī)模、人員數(shù)量來進(jìn)行的劃分，因為我們都知道在系統(tǒng)架構(gòu)設(shè)計時，一般來說規(guī)模及數(shù)量對于架構(gòu)的影響是決定性的，所以這里先基于這個維度來對企業(yè)分類。

前面我們羅列的HRMS系統(tǒng)的功能，我這里不在重復(fù)羅列，我認(rèn)為這8項是基礎(chǔ)業(yè)務(wù)級需求，上述的4類企業(yè)都需要提供這些功能。（具體請參考上面的HRMS系統(tǒng)功能圖）

同時為了區(qū)分不同規(guī)模、人員數(shù)量企業(yè)的差異性，我這邊又整理了幾方面的需求內(nèi)容，模擬甲方提出：

注意事項：（前面規(guī)模較小的公司個性化的功能，后面規(guī)模較大的企業(yè)默認(rèn)會有這些功能，所以很多內(nèi)容我沒有重復(fù)列出）

A、100人以下的中小企業(yè)（單個企業(yè)內(nèi)部使用）

不同的用戶看到的內(nèi)容不同、可以單獨管理各自內(nèi)部的事宜

業(yè)務(wù)審批流程，支持自定義

與郵件系統(tǒng)、OA、財務(wù)系統(tǒng)等集成

LInux環(huán)境、java語言、內(nèi)外網(wǎng)均可使用

需要提供app與pc端服務(wù)接入

數(shù)據(jù)統(tǒng)計及分析

B、500人以下的大中型企業(yè)（多個公司內(nèi)使用）

支持多分公司管理模式（不同分公司看到的模塊及數(shù)據(jù)不同，相互隔離，總部能看到）

各分公司主要是作為業(yè)務(wù)拓展，按照總部的管理流程及制度來執(zhí)行

功能優(yōu)化及升級，由總部統(tǒng)一規(guī)劃及實施，各地可以提需求

硬件及軟件環(huán)境由總部統(tǒng)一管理及維護(hù)

采取云端部署模式，部署前需各地提出相關(guān)需求

支持wap、微信等服務(wù)接入

大數(shù)據(jù)跟蹤（指導(dǎo)各部門的人力資源及管理優(yōu)化）

C、1000人以上的集團(tuán)化大企業(yè)（業(yè)務(wù)拆分模式的集團(tuán)化公司）

大集團(tuán)公司下設(shè)多個小集團(tuán)公司，各集團(tuán)公司的業(yè)務(wù)不同和垂直化分公司的管理模式不同，需要系統(tǒng)支持該類型的配置管理

信息流轉(zhuǎn)及上報的業(yè)務(wù)線需要跨多個公司及職級，業(yè)務(wù)線不能亂。

各集團(tuán)子公司自定義內(nèi)部的管理體系，總公司制定統(tǒng)一工作要求并給予指導(dǎo)

總公司及各子公司均有信息 中心，各自建設(shè)內(nèi)部的信息化，最終通過總公司信息 中心進(jìn)行統(tǒng)籌

科學(xué)決策及指導(dǎo)（人才戰(zhàn)略）

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

不同國家分公司的內(nèi)部管理系統(tǒng)的功能模塊不同

系統(tǒng)支持各地國家當(dāng)?shù)氐恼Z言

總部、分公司及下屬部門間的信息聯(lián)動及共享支持，可按層級設(shè)置匯報線及審批流

HRMS系統(tǒng)接入的第三方系統(tǒng)略有不同（OA、ERP等）,根據(jù)不同國家的公司情況，各公司統(tǒng)籌，對于總公司統(tǒng)籌的服務(wù)，各分公司按要求使用

企業(yè)指揮艙（內(nèi)部+外部）

A、開發(fā)期質(zhì)量

一般來說，甲方不會是專業(yè)的軟件公司，如果是默認(rèn)甲方會內(nèi)部自主提出相應(yīng)的需求提出具體的設(shè)計規(guī)劃方案，這其中便會考慮系統(tǒng)的質(zhì)量要求，對于開發(fā)過程中的質(zhì)量要求一般需要在架構(gòu)設(shè)計時主動考慮，提供相應(yīng)的問題來咨詢或為甲方提供專業(yè)的建議及咨詢。對于甲方確認(rèn)的內(nèi)容可重點關(guān)注，對于甲方?jīng)]有主動提出的，需要我們根據(jù)行業(yè)經(jīng)驗做好判斷來落實。

基于前面模擬提出的個性化的需求，我們來綜合梳理下開發(fā)期的質(zhì)量要求：

\

<=100人

<=500人

<=1000人

<=10000人

可擴(kuò)展性

暫時可不考慮

必備

必備

必備

可重用性

不是特別強(qiáng)烈（重用性方面主要是針對基礎(chǔ)組件方面需要考慮）

必備

必備

必備

可測試性

必備

必備

必備

必備

易理解性

必備

必備

必備

必備

可維護(hù)性

必備

必備

必備

必備

可移植性

暫時可不考慮

需考慮，但非必須

必備

必備

基于上面的分析，我們已基本確認(rèn)了不同規(guī)模的企業(yè)的HRMS系統(tǒng)需要考慮的質(zhì)量屬性略有不同。

B、運行期質(zhì)量

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

\

<=100人

<=500人

<=1000人

<=10000人

性能

100人，數(shù)據(jù)量較小，暫時可不考慮

500人使用時性能也不需要特別的考慮，業(yè)務(wù)量及數(shù)據(jù)量都不會太大

一般

高

安全性

內(nèi)網(wǎng)部署，非外網(wǎng)隔離，安全性級別（高）

較高

較高

較高

易用性

需考慮，要求較低

一般

一般

高

持續(xù)可用性

要求不高，上班期間使用

一般

較高

較高

可伸縮性

暫時可不考慮

暫時可不考慮

一般

高

互操作性

需考慮（但要求不高）

需考慮，涉及到多個子公司，需要考慮差異性的互操作性

一般

高

可靠性

高

高

較高

較高

魯棒性

需考慮（要求不高）

需考慮（一般）

較高

較高

相對于開發(fā)期的質(zhì)量屬性來說，運行期的質(zhì)量屬性更多、更復(fù)雜、更重要，所以我們需要特別重視。

基于前面列出的應(yīng)用需求，我們綜合4類企業(yè)的約束，形成統(tǒng)一的約束清單：

約束類型

具體說明

業(yè)務(wù)環(huán)境約束

上線時間：3個月

預(yù)算限制：性價比高

集成環(huán)境：公司內(nèi)部OA、郵件等系統(tǒng)與外部社保系統(tǒng)等連接

政策及法規(guī)：受制于人力資源管理相應(yīng)的辦法

使用環(huán)境約束

何階層用戶：員工、HR、高管等

年齡段和偏好：覆蓋22歲~65歲

多個國家：（多語言支持）

是否存在網(wǎng)絡(luò)較弱或延遲情況：會存在，所以需要考慮信息的臨時存儲及恢復(fù)

設(shè)備移動的情況下：需要提供移動端設(shè)備訪問

開發(fā)環(huán)境約束

技術(shù)水平：團(tuán)隊技術(shù)水平高,掌握java語言

城市分布：多個城市

磨合程度：一般

開發(fā)管理程度：較高

源代碼保密：高

網(wǎng)絡(luò)環(huán)境：良好

技術(shù)環(huán)境約束

技術(shù)平臺：Java、Linux

中間件：Spring cloud、Redis等

編程語言的流行度：主流

認(rèn)同度：高

優(yōu)缺點：應(yīng)用語言，性能問題需要考慮

上面我們系統(tǒng)化的梳理了系統(tǒng)的業(yè)務(wù)功能、質(zhì)量屬性及約束內(nèi)容，下面我們采取需求層次-需求類型二維矩陣來找出關(guān)鍵功能、關(guān)鍵質(zhì)量屬性及關(guān)鍵約束。

3.2、確定關(guān)鍵功能、關(guān)鍵質(zhì)量屬性及關(guān)鍵約束

在確定關(guān)鍵功能、質(zhì)量屬性及約束之前，我想再限定和說明個前提，以便大家更好的理解，我們需要開發(fā)一個SaaS版本的系統(tǒng)，全方位的支持上述4類企業(yè)的需求，過程中我們作為一個企業(yè)，需要考慮成本、商業(yè)模式、企業(yè)未來的戰(zhàn)略及盈利等方面的內(nèi)容。

所以基于這些約束及現(xiàn)狀，我們可以梳理得出以下的關(guān)鍵功能及質(zhì)量、約束的表格。作為后續(xù)我們做概要架構(gòu)的前提和基礎(chǔ)。

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

A、確定組織級的功能、質(zhì)量、約束等內(nèi)容

B、確定用戶級的功能、質(zhì)量、約束等內(nèi)容

C、確定開發(fā)級的質(zhì)量及約束等

D、將約束衍生為質(zhì)量屬性及功能、將質(zhì)量屬性衍生為功能

將關(guān)鍵約束衍生為功能：

根據(jù)功能提煉出非功能性需求：

E、形成統(tǒng)一的二維表（形成關(guān)鍵結(jié)果）

（如上表）

F、總結(jié)

通過上述的幾個環(huán)節(jié)，我們把不同類型的約束轉(zhuǎn)化為質(zhì)量屬性及功能需求，最終我們形成了最終的需求二維矩陣，這將為我們的架構(gòu)指明方向，后續(xù)我們再做架構(gòu)的設(shè)計及規(guī)劃的時候就能夠做到有的放矢，不會走錯方向。

項目管理 ProjectMan 架構(gòu)設(shè)計

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。