HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性非功能性关键约束)-下篇

Posted 2021-01-08 hegezhou_hot

一、开篇

      上一篇《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》我们详细分析了在架构分析过程中我们需要注意的内容，架构过程的方法论及实践经验，以更好的指导我们在具体架构落地。

       本篇主将具体结合HRMS系统进行架构概要分析，按照上篇的理论指导，开展具体的架构分析过程实践，通过分析找到关键功能、关键非功能性需求（关键质量及约束）等。

      在阐述具体的架构工作方法之前，请大家先查看以下三方面的内容：

     1、HRMS系统的介绍？（涵盖哪些功能？价值和作用是什么？行业什么情况？）

      请阅读《HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍》

      2、本章分析的内容将围绕4类企业代表的业务场景，（区分不同规模企业的关注点，规模将决定系统的设计方案）

      本篇将围绕4类企业代表来阐述不同规模企业对于HRMS的需求及应用

•       A、100人以下的中小企业
•       B、500人以下的大中型企业
•       C、1000人以上的集团化大企业
•       D、全球类型的公司体系（几万人）

      3、架构师在设计该系统时的职责及具备的核心能力是什么？

      请阅读《系统架构系列-开篇介绍》

 

一、架构准备阶段主要做什么？

       架构准备阶段主要是围绕系统的全方位的需求分析来开展相关准备工作的，这里的需求涵盖功能性及非功能性2大类需求，非功能性需求又涵盖质量属性及约束两项内容，我们在实际的分析过程中需要重点考虑业务功能、质量属性及约束等内容，具体可采取表格方式进行梳理，借助科学的方法找出来哪些是关键功能、哪些是关键质量需求、哪些是关键约束。

关键功能、关键质量属性及关键约束等内容对于架构设计的实际影响有哪些呢？在这里我们梳理成表格来呈现这样大家有一个比较直观的感受：

架构是围绕需求来开展的，在对需求综合分析的过程中，我们将需求划分为3个层次：

业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件；

用户级需求：用户使用系统来辅助完成哪些工作。对质量要求如何。用户群及所处的使用环境方面有何特殊要求。

开发级需求：开发人员需要实现什么。开发期间、维护期间有何质量考虑。开发团队的哪些情况会反过来影响架构。

　　对于此三类需求弄清楚之后，就可以形成一个初步的需求列表。

　　一方面为了满足上述3类需求，同时还考虑到影响架构设计3个维度方面的内容，我们采取ADMEMS的需求类型及需求层次的二维矩阵表，来进行结构化的梳理，这样更直观也更清晰，我这里先将考虑的维度放在这，后面关于HRMS系统的需求分析的过程中我将按照该方法进行整理：

我们了解了需求的层次、需求的类型，知道了他们对于架构的影响，也熟悉了解了他们之间的关联关系，那接下来对我们来说最重要的就是理清思路，如何把需求全方位的陈列出来，利用需求层次及需求分类罗列整理。HRMS系统非常的复杂，功能较多，应用的场景及类型也比较繁多，所以最好的方式就是把需求列清晰：

通过需求的结构化整理，需要从这些需求中找到关键功能、关键质量及关键约束，并将关键质量、关键约束转化为衍生的设计需求：

1、确定业务功能

关键的业务功能包含如下四个方面：1.核心功能；2.必做功能；3.高风险功能；4.独特功能。

　　如何区别这四个方面，实际上是靠经验和感觉。它们之间实际上是有重叠部分的。

核心功能：业务层接口所反映的功能。如，HRMS系统中，前面说的8大业务内容都属于核心功能；

必做功能：必做功能实际上是以客户为背景的，简单来说就是愿景；

高风险功能：顾名思义，哪些功能操作可能会涉及到安全和隐私等问题；

独特功能：实际是上诉三个功能的补集，看看还有哪些没有覆盖到的，却又很关键的功能。

　　架构师在设计阶段要考虑到“关键功能”所占有的比例，没有明确的标准，一般遵循：功能少的系统比例高一些，功能多的系统比例少一些。

2、梳理非功能性需求涵盖质量及约束需求，将这些质量及约束背后的衍生需求梳理清晰：

关于质量要求这块的内容涵盖的范围非常的广泛，涵盖：1.性能  2. 安全性 3.持续可用性 4.可靠性 5.鲁棒性 6.易用性 7.可测试性 8.可重用性 9.可维护性 10.可扩展性 11.可移植性 12 可互操作性等。我们在做HRMS系统架构设计时考虑的质量属性里面也不需要把每一个指标都做上去。这些指标之间是相互影响的。其影响关系如下（+表示促进  －表示影响  空白表示无明显作用）：

当出现多个质量属性出现互斥的时候，必须要权衡以哪个为主，那相应的另外一个质量属性就会弱化。

在架构设计中，对非功能性需求的重视程度，也会影响架构设计的好与劣；但也要平衡过渡设计和适可而止的关系。

二、如何找出关键的功能性、非功能性需求、关键约束？

 

1、找到系统的关键功能（系统具体是做什么的？）

我们可以采取职责链模式来梳理关键功能：

模拟不同类型的用户如何通过系统实现业务需求的过程，借助系统化的思维模拟跟踪各环节，梳理清晰后即可得出清晰的职责链，这样便可以找出各链上的关键功能点，这些关键点即是关键功能。借助职责链模式来梳理核心功能，确认系统中存在必要功能、HRMS系统中的8大业务模块，这里再强调下：

上面8项属于核心功能。除此之外，还应该会有流程管理、权限管理等功能，辅助及支撑系统运行的基础功能。

2、确定关键质量的5大原则（找出关键质量属性）

• ?分类合适+必要扩充

       针对质量分类进行细化及分解

• ?考虑多方涉众

       用户不仅关注功能，同时也需要质量，用户关注的质量可能包括易用性、性能、持续可用性、鲁棒性等，客户不一定是最终用户，比如超市销售系统的客户是超市老板，但最终用户可能是收银员或上货员，他们所关注的质量属性可能不一致。

• ?检查性思维

       随时检查各个质量属性，看看每一项是否确实算不上“关键质量”，从而防止遗漏关键需求。

•  
• ?识别矛盾+划定优先级

      

       确定这些质量属性之间的矛盾关系，明确以哪些质量属性为主。

• ?严格程度符合领域与规模特点

       严格程度符合领域与规模特点

       关键质量属性个数根据项目、产品、平台不同而不一样

       诸如：银行项目（注重安全性、易用性）;互联网服务项目（注重持续可用性、易用性、性能、可靠性等）

3、找出关键约束并将这些约束转化为功能或质量需求

首先，按照4类约束进行罗列（尽可能全面）

其次、分析约束面向的功能、质量方面的转化

最后、确定这些约束转化后的功能、质量是否重要

4、?第1步：需求结构化；?第2步：分析约束影响；?第3步：确定关键质量；?第4步：确定关键功能

三、HRMS系统的关键功能、关键质量指标及约束

无论上一篇《HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性、非功能性、关键约束)-上篇》介绍的，还是本篇前面介绍的内容基本上都是理论偏多一些，当然其中有一些具体的原则及操作方法，可能大家还不清楚具体的如何下手，如果真来一个项目，我该怎么循序渐进、由浅入深呢？下面我们就以HRMS为例来简单说明，我们来具体实际操作一下大家就会有比较清晰的认识了，希望大家能够掌握其中的精髓。需要多实践和总结。

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

在前面我们描述了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.2、确定关键功能、关键质量属性及关键约束

      在确定关键功能、质量属性及约束之前，我想再限定和说明个前提，以便大家更好的理解，我们需要开发一个SaaS版本的系统，全方位的支持上述4类企业的需求，过程中我们作为一个企业，需要考虑成本、商业模式、企业未来的战略及盈利等方面的内容。

       所以基于这些约束及现状，我们可以梳理得出以下的关键功能及质量、约束的表格。作为后续我们做概要架构的前提和基础。

上表的具体的推演过程如下：

A、确定组织级的功能、质量、约束等内容

B、确定用户级的功能、质量、约束等内容

C、确定开发级的质量及约束等

D、将约束衍生为质量属性及功能、将质量属性衍生为功能

将关键约束衍生为功能：

根据功能提炼出非功能性需求：

E、形成统一的二维表（形成关键结果）

（如上表）

F、总结

       通过上述的几个环节，我们把不同类型的约束转化为质量属性及功能需求，最终我们形成了最终的需求二维矩阵，这将为我们的架构指明方向，后续我们再做架构的设计及规划的时候就能够做到有的放矢，不会走错方向。

 

四、更多信息

关于更多的系统架构方面的知识，我已建立了交流群，相关资料会第一时间在群里分享，欢迎大家入群互相学习交流：

微信群：（扫码入群-名额有限）