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

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

1、开篇

      上一篇《HRMS(人力资源管理系统)-从单机应用到SaaS应用-系统介绍》咱们已经详细的分析了HRMS系统具有的功能，而且从HRMS系统的概念、系统功能、HR行业管理现状及痛点、发展趋势及行业前景、行业内的服务提供商状况、HRMS系统的建设意义及价值等方面进行了系统化的分析梳理。我想你们已经对于HRMS系统的大致状况有了初步的了解，本篇将对HRMS系统的需求进行全方位的梳理（功能性需求、非功能性需求、系统约束等），这对于HRMS系统的架构设计来讲是核心关键，是架构可否成功的前提。这也是衡量一个架构师是否称职合格的关键。

       本篇主要想经过HRMS系统与你们分享下架构设计环节中很是重要的基础环节-架构准备-的关键工做内容，请你们务必该环节的工做内容，这是全部成功架构设计的前提，为可以系统的阐述清晰该领域的注意事项及工做方法，因此篇幅会较长，请你们细细看完，若是有阐述不清晰或遗漏的地方，还请你们指出。

      在阐述具体的架构工做方法以前，请你们先查看如下三方面的内容：

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

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

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

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

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

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

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

 

2、为何不少系统架构的设计会失败？

       在这10多年的工做经验中见过也参与了很多失败的架构项目，基本上总结下来发现了有不少种缘由可能致使架构设计失败，因此说一个系统的架构设计是一个系统化的工程，不是只进行模块设计或功能设计那么简单，须要不断学习和积累经验，站在巨人的肩膀上思考问题，让咱们少走弯路。成功和失败的经验都值得咱们去总结和思考，那么基于以前总结的内容，我梳理完能够概括为如下几个方面：

A、架构师不懂需求

B、非功能需求、关键约束、关键功能等没有找到

C、缺乏关键实践及方法论

D、未能验证架构的可行性并做出调整

2.一、架构师不懂需求

       技术是为业务服务的，请每一位架构师或系统的设计者谨记该理念，不知道你们有没有总结过目前出现的各种技术的特色，我发现每一次的技术更迭就是为了解决前一主流技术存在的不足或某些领域的缺陷而产生的，因此，咱们在选择一项技术或选型时，须要结合业务的实际状况灵活选择，必定要选择最好、最优的，考虑将来的变化、不肯定、扩展性等非功能性需求。让咱们的架构设计有必定的扩展性及健壮性。架构也是持续迭代的（请你们有空网上看看阿里巴巴、腾讯、百度、京东等互联网公司的架构迭代过程），非一蹴而就的。

2.二、遗漏或未找到非功能需求、关键约束、关键功能等

       在系统架构设计的过程当中最惧怕的就是遗漏关键功能或非功能性需求、系统约束等方面没有考虑，这将直接致使架构失败，前面作的全部的准备工做基本上都是白费了，每每在架构设计的过程当中一个点就会致使总体失败，咱们必须找到关键需求。这将须要一整套的方法论，咱们每每在分析功能、非功能性需求、系统约束时缺少方法论和梳理思路，这将会让咱们陷入一系列的迷茫中，就会出现抓不住重点内容。具体某个需求在不一样的行业领域、不一样的用户场景等每每重要性可能不一样，这就须要架构师必须进行充分的调研梳理。

2.三、缺乏关键实践及方法论

       咱们在实际的架构工做中每每不去学习和参考前人总结的工做经验，这样是阻碍我的成长和进步的，我认为99%的场景下咱们遇到的问题前人都遇到了，只是咱们没有遇到对的人，只要咱们找到对的人，只要这我的肯分享，必定会帮助咱们解决咱们遇到的问题的，再举个例子，若是咱们作互联网，那么技术问题能够试想下，咱们遇到的问题我想（BAT）都遇到了，因此咱们为啥不站在前人的肩膀上去思考问题呢？这让咱们可以有更多的时间去总结和思考解决问题的方式，全面提高咱们自身的能力。

       另外，千万不要认为本身设计的架构方案就是最好的，要不断的质疑架构的合理性及最优性，经得起你们的质疑及实际的考验，而且为确保架构的有效落地，须要持续的跟踪确认，确保方向不会出现误差。

2.四、未验证架构的可行性并做出调整

       总体的架构方案并无进行充分的评审及实践验真，俗话说实践是检验真理的惟一标准，这须要架构师在架构设计完成后准备各视图场景下的验证方案，确保总体架构的可行性，一旦在过程当中发现遗漏及风险及时干预并调整架构设计方案，若是已经进入到开发阶段，须要制定平滑的设计方案，尽量的规避工做量损失并保证系统功能的全面支撑。

另总结了一些软件架构设计过程当中存在的误区

●高开高走落不到实处

● 理想与现实须要折中

● 遗漏关键性约束与非功能需求

● 为虚无的将来埋单而过分设计

● 过早作出关键性决策

● 客户说啥就是啥成为传话筒

● 埋头干活儿缺少前瞻性

● 架构设计还要考虑系统可测性

● 架构设计不要企图一步到位

 

3、架构设计成功的关键方法

3.一、EA架构方法论体系

       对于企业或提供行业的产品及服务时，咱们须要一整套的系统化思惟去思考和设计业务流程。特别是业务愈来愈复杂及业务范围愈来愈广时，这就须要咱们有一整套的方法论去指导咱们去设计及规划系统，一个你们都明白的共同语言来分析和解决问题，这个共同语言就是EA所提供的。EA的真正意义是告诉你怎样去思考，怎样去沟通，怎样去作决策，以及怎样去控制项目。EA保证不一样层面的人看到一个更宏观的视图，从而避免“ 只见树木、不见森林”的无效工做。 EA是一个把战略、业务与IT进行有效匹配的方法论，从而使 IT真正为业务和战略服务，从而使战略可以有效执行。 EA就是现代企业的DNA，它是一个可以整合各类方法的机制 ，从而解决各类挑战和问题。

       上述图片中呈现了EA方法论的5类具体的实践，因为篇幅有限，我这里不挨个展开介绍概念及具体内容。若是想了解详情请你们自行搜索。

       能够说咱们在作一个复杂系统的设计及规划时，正确的方法论会知道咱们正确的作事，作正确的事，因此这对咱们每一个架构师来讲很是重要，请你们务必了解，固然对于EA理论的具体实践也有不少具体的方法实践模式，这里也能够概括为几类，后面咱们将详细阐述。

 

3.二、ADMEMS（Architecture Design Method has been Extended to Method System）

       ADMEMS是Architecture Design Method has been Extended to Method System的简称，是由CSAI顾问团架构设计专家组于2009年11月在第六届中国软件大会上公开发布的一个软件架构设计方法。做为方法体系，ADMEMS经过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工做内容。其中“3个阶段”是指预备架构阶段（PA阶段：把握需求特色，肯定架构驱动力）、概念架构阶段（CA阶段：根据重大需求，肯定概念架构）、细化架构阶段（RA阶段：细化架构设计，关注不一样视图），“1个贯穿环节”是指对非功能目标的考虑。

       PA阶段的任务是全面理解需求，从而把握需求特色，进而肯定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心；CA阶段必须考虑包括功能、质量、约束在内的全部方面的需求，ADMEMS方法有本身的概念架构设计步骤和作法；RA阶段的整体方法为5视图方法，涉及逻辑架构、物理架构、开发架构、运行架构和数据架构。

       后面咱们将主要参考该架构方法来落地实践HRMS系统的架构设计过程。

 

3.二、质疑驱动架构设计（始终抱着质疑的思想来思考架构设计方案）

架构师需始终保持质疑的意识来不断驱动整个架构设计的过程，这是一个架构设计成功的关键，经过质疑可引入更多的“质量属性”，同时结合“特殊功能场景”驱动后续架构设计，最终造成最优的架构设计方案。

以HRMS系统为例：

      上面咱们发如今架构设计的过程当中，咱们须要从多维度去思考架构设计考虑的内容及方式，咱们须要从不一样的方向去考虑架构过程当中出现的各种问题，经过质疑并不断解决质疑的方式来设计出最终的解决方案。咱们的终极目标是设计出一套先进有持续竞争力的HRMS系统，知足各种企业在经营过程当中对人力资源管理所需的各种需求（功能、质量属性、约束），架构师须要用挑毛病的方式来去评估当前的架构设计方案，直到挑不出毛病（架构师本身先质疑问题并解决了），这个架构基本就成型了。

 

3.三、多阶段/多视图

       业界软件架构设计的方法论不少，各有各自的应用场景和特色，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程：

       架构设计的过程和内容的不是固定不变的，现实中，好比售前提供解决方案中，不少时候须要架构师提供细化架构中才会深思的逻辑架构、物理架构等，这时候，架构师就须要有螺旋思惟和跳跃思惟的方式，就像武功中，招式是死的，人是活的，要学会灵活运用。

       3.3.一、架构设计过程（3个阶段）

A、Pre-architecture阶段：架构实践中最多见的最短板

最大误区：架构师是技术人员，没必要懂需求

实践要点：摒弃“需求列表”方式，创建二维需求观

思惟工具：二维矩阵（需求层次-需求方面矩阵）

B、Conceptual Arch阶段：大型系统成败关键

最大误区：概念架构=理想设计

实践要点：重大需求塑造概念架构

思惟工具：鲁棒图、目标-场景-决策表

C、Refined Arch阶段：团队大规模并行开发基础

最大误区：架构=模块 + 接口

实践要点：贴近实践的5视图法

思惟工具：包图、包-接口图、灰盒包图、序列图、目标-场景-决策表

 

         3.3.二、架构设计5视图

         5视图法分析的意义：

         ● 全面分析软件系统方方面面的问题
         ● 尽早地发现和排除项目风险与不肯定因素
         ● 从不一样角度去展示要设计的软件系统
         ● 为项目进行中不一样的干系人提供指导：
            -- 逻辑架构描述系统功能，并指导系统测试
            -- 开发架构规范软件的层次及代码风格
            -- 数据架构指导数据库的设计
            -- 运行架构定义了一些关键过程的设计
            -- 物理架构明确软件如何部署与实施

关于架构5视图的实践过程：

3.四、内置最佳实践(经验总结)

       在咱们在作系统架构时，咱们应该不断的学习、总结以前的经验，就像前面咱们讲到的架构的方法论、架构模式同样，咱们须要造成一套方法理论体系或者应用场景解决方案去指导咱们在后续的系统架构。少走弯路、找到最优的架构解决方案。

      总体来讲咱们能够概括在逻辑架构、业务建模、关键约束、非功能性需求（质量需求）等几方面的经验。

3.4.一、逻辑架构设计过程当中的10条经验

1) 划分子系统：分层的细化

2) 划分子系统：分区的引入

3) 划分子系统：机制的提取

4) 接口的定义：协做决定接口

5) 选用序列图：杜绝协做图

6) 包-接口图：从结构到待办的桥

7) 灰盒包图：描述关键子系统

8) 按部就班的螺旋思惟

9) 设计模式：包内结构

10) 设计模式：包间协做

       在实际的逻辑架构的设计过程当中，上面的10条经验会很是有价值，咱们仅需参考上面的原则来设计系统的逻辑架构，基本上架构成功的概率很大。再结合其余的4个架构视图便可获得最优的系统架构。

3.4.二、基于鲁棒图进行初步设计的10条经验（业务建模）

       ADMEMS方法概括了鲁棒图建模的10条经验要点,分别覆盖语法，思惟，技巧，注意事项等4个方面，建议后续你们在作具体的系统架构时可参考10条设计经验，少走弯路：

鲁棒图建模的10条经验:

1.遵照建模规则。

    经过如下4条语句，能够理解该图的本质：

         1.1 参与者只能与边界对象交谈。

         1.2 边界对象只能与控制对象和参与者交谈。

         1.3 实体对象也只能与控制对象交谈。

         1.4 控制对象既能与边界对象交谈，也能与控制对象交谈，但不能与参与者交谈。

2.简化建模语法

      ADMEMS方法推荐鲁棒图建模的语法。在实践中，简化的鲁棒图语法将有利于集中精力进行初步设计，而不是关注细节。

3.遵循3种元素的发现思路

用例=N个场景。每一个场景的实现都是一连串的职责进行协做的结果。因此，初步设计能够经过”研究用例执行的不一样场景，发现场景背后应该有哪些不一样的职责“

4.增量建模

         首先，识别最明显的职责。对，就是你本身认为最明显的那几个职责--不要认为设计和建模有严格的标准答案。

接下来，开始考虑职责间的关系，并发现新职责。继续一样的思惟方式。

5.只对关键功能（用例）画鲁棒图

    基于”关键需求决定架构“的理念，功能需求做为需求的一种类型，在设计架构时没必要针对每一个功能都画出鲁棒图。

6.每一个鲁棒图有2-5个控制对象

     既然是 初步设计，鲁棒图建模时，针对关键功能的每一个鲁棒图中得控制对象没必要太多太细，5个是常见的上限值。相反，若实现某功能的鲁棒图中只含一个控制对象，则是明显地”设计不足“--这个控制对象的名字必然和功能的名字相同，这意味着没有对职责进行真正的切分。

7.勿关注细节：

     初步设计不该该关注细节。例如，

     1.对每一个对象只标识对象名，都未识别其属性和方法。

      2.”活期帐户销户界面“，具体多是对话框，WEB界面，字符终端界面,但鲁棒图中没有关心这些细节问题。

      3.”客户资料“ 等实体对象需要持久化吗？不关心，更不关心用Table仍是用File或其余方式持久化。

      4.没有标识控制流的严格顺序。

8.勿过度关注UI，除非辅助或验证UI设计。

    过度关心UI，会陷入诸若有几个窗口，是否是有一个专门的结果显示页面等诸多细节之中，初步设计就无法作了。

   别忘记了，初步设计的目标是发现职责。初步设计无须展开架构设计细节，不然就背上了”包袱“，这是复杂系统架构设计起步时的大忌

3.4.三、约束的4大类型--转化成图片

A、业务环境的约束（客户或出资方）

上线时间？预算限制？集成需求？

业务领域？业务规则或业务限制？

法律法规或专利的限制？

更多……

B、使用环境的约束（系统用户）

何阶层用户？年龄段和偏好？多个国家？

是否存在网络较弱或延迟状况？设备移动的状况下？

更多……

C、构建环境的约束（开发者和维护人员）

技术水平，城市分布，磨合程度？

开发管理程度？源代码保密？网络环境？

更多……

D、技术环境的约束（技术选型）

技术平台、中间件、编程语言的流行度，认同度，优缺点？

技术发展趋势？

更多……

 

3.五、非功能及约束贯穿整个设计过程

       咱们知道在系统架构设计的过程当中，不能仅仅考虑功能实现，还须要持续考虑非功能性需求（质量）及约束内容，每每这些是系统架构成功的关键点，某些时候咱们每每由于忽略或遗漏这些内容而致使架构失败。

       如何设计才能使这个系统高性能呢？场景思惟是关键。也就是说，咱们要明确系统所处于的哪些真实具体的场景，对高性能这个大的笼统的目标最有意义：

        咱们能够采起-“目标-场景-决策”表来辅助咱们系统化的梳理非功能性需求内容：

         

         因而可知，经过"目标-场景-决策表"既能够帮助咱们引入新的设计（例如表中决策"HTML静态化"），也能够帮助咱们改进以前架构设计存在的问题及痛点，还能够再分析的过程当中帮咱们找到关键非功能需求，因此在后续的架构设计过程当中咱们须要善用该表。

 

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

1、架构分析阶段主要作什么？

一、分析业务需求和约束背后的衍生需求

二、发现遗漏需求

三、肯定关键功能

四、肯定关键质量

五、肯定关键约束

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

一、功能需求影响架构的基本原理：职责协做链

二、质量需求影响架构的基本原理：进一步质疑

三、分析约束影响架构的基本原理：直接制约、转化为功能或质量需求

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

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

一、结合HRMS系统的综合分析，最后得出结论？

二、肯定关键功能

三、肯定关键质量指标

四、肯定关键约束

4、架构分析阶段总结

一、架构师分析系统的第一步是什么？

二、找出关键点是二维表？

三、如何提高分析能力是关键（实践出真知）？

四、知识提高（除了BAT及大的互联网公司可能会遇到技术瓶颈，咱们如今基本上遇到的问题，你们都遇到了）

五、过犹不及（不要过分设计，能解决业务问题就是最好的，不要镜中花、水中月）

 

5、更多信息

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

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