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、更多信息

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

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