• <sup id="mk476"></sup>
    <dl id="mk476"></dl>
  • <progress id="mk476"><tr id="mk476"></tr></progress>
    <div id="mk476"><tr id="mk476"></tr></div>
    <sup id="mk476"><ins id="mk476"></ins></sup>
  • <progress id="mk476"></progress>
    <div id="mk476"></div>
    <div id="mk476"><tr id="mk476"></tr></div>
  • <div id="mk476"></div>
    <dl id="mk476"><s id="mk476"></s></dl><dl id="mk476"></dl><div id="mk476"></div>
  • <div id="mk476"></div>
    <dl id="mk476"><ins id="mk476"></ins></dl>

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

    一、開篇

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

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

          在闡述具體的架構工作方法之前,請大家先查看以下三方面的內容:

         1、HRMS系統的介紹?(涵蓋哪些功能?價值和作用是什么?行業什么情況?)

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

          2、本章分析的內容將圍繞4類企業代表的業務場景,(區分不同規模企業的關注點,規模將決定系統的設計方案)

          本篇將圍繞4類企業代表來闡述不同規模企業對于HRMS的需求及應用

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

          3、架構師在設計該系統時的職責及具備的核心能力是什么?

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

     

    一、架構準備階段主要做什么?

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

    image

    關鍵功能、關鍵質量屬性及關鍵約束等內容對于架構設計的實際影響有哪些呢?在這里我們梳理成表格來呈現這樣大家有一個比較直觀的感受:

    image

    架構是圍繞需求來開展的,在對需求綜合分析的過程中,我們將需求劃分為3個層次:

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

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

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

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

      一方面為了滿足上述3類需求,同時還考慮到影響架構設計3個維度方面的內容,我們采取ADMEMS的需求類型及需求層次的二維矩陣表,來進行結構化的梳理,這樣更直觀也更清晰,我這里先將考慮的維度放在這,后面關于HRMS系統的需求分析的過程中我將按照該方法進行整理

    image

    我們了解了需求的層次、需求的類型,知道了他們對于架構的影響,也熟悉了解了他們之間的關聯關系,那接下來對我們來說最重要的就是理清思路,如何把需求全方位的陳列出來,利用需求層次及需求分類羅列整理。HRMS系統非常的復雜,功能較多,應用的場景及類型也比較繁多,所以最好的方式就是把需求列清晰:

    image

    通過需求的結構化整理,需要從這些需求中找到關鍵功能、關鍵質量及關鍵約束,并將關鍵質量、關鍵約束轉化為衍生的設計需求:

    image

    1、確定業務功能

    關鍵的業務功能包含如下四個方面:1.核心功能;2.必做功能;3.高風險功能;4.獨特功能。

      如何區別這四個方面,實際上是靠經驗和感覺。它們之間實際上是有重疊部分的。

    核心功能:業務層接口所反映的功能。如,HRMS系統中,前面說的8大業務內容都屬于核心功能;

    必做功能:必做功能實際上是以客戶為背景的,簡單來說就是愿景;

    高風險功能:顧名思義,哪些功能操作可能會涉及到安全和隱私等問題;

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

      架構師在設計階段要考慮到“關鍵功能”所占有的比例,沒有明確的標準,一般遵循:功能少的系統比例高一些,功能多的系統比例少一些。

    2、梳理非功能性需求涵蓋質量及約束需求,將這些質量及約束背后的衍生需求梳理清晰:

    image

    關于質量要求這塊的內容涵蓋的范圍非常的廣泛,涵蓋:1.性能  2. 安全性 3.持續可用性 4.可靠性 5.魯棒性 6.易用性 7.可測試性 8.可重用性 9.可維護性 10.可擴展性 11.可移植性 12 可互操作性等。我們在做HRMS系統架構設計時考慮的質量屬性里面也不需要把每一個指標都做上去。這些指標之間是相互影響的。其影響關系如下(+表示促進  -表示影響  空白表示無明顯作用):

    image

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

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

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

     

    image

    1、找到系統的關鍵功能(系統具體是做什么的?)

    我們可以采取職責鏈模式來梳理關鍵功能:

    image

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

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

    2、確定關鍵質量的5大原則(找出關鍵質量屬性)

    image

    • ?分類合適+必要擴充

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

    image

    • ?考慮多方涉眾

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

    • ?檢查性思維

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

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

           image

           確定這些質量屬性之間的矛盾關系,明確以哪些質量屬性為主。

    • ?嚴格程度符合領域與規模特點

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

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

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

    3、找出關鍵約束并將這些約束轉化為功能或質量需求

    image

    首先,按照4類約束進行羅列(盡可能全面)

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

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

    4、?第1步:需求結構化;?第2步:分析約束影響;?第3步:確定關鍵質量;?第4步:確定關鍵功能

    image

    三、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、開發期質量

    image

           一般來說,甲方不會是專業的軟件公司,如果是默認甲方會內部自主提出相應的需求提出具體的設計規劃方案,這其中便會考慮系統的質量要求,對于開發過程中的質量要求一般需要在架構設計時主動考慮,提供相應的問題來咨詢或為甲方提供專業的建議及咨詢。對于甲方確認的內容可重點關注,對于甲方沒有主動提出的,需要我們根據行業經驗做好判斷來落實。

    基于前面模擬提出的個性化的需求,我們來綜合梳理下開發期的質量要求:

    \

    <=100人

    <=500人

    <=1000人

    <=10000人

    可擴展性

    暫時可不考慮

    必備

    必備

    必備

    可重用性

    不是特別強烈(重用性方面主要是針對基礎組件方面需要考慮)

    必備

    必備

    必備

    可測試性

    必備

    必備

    必備

    必備

    易理解性

    必備

    必備

    必備

    必備

    可維護性

    必備

    必備

    必備

    必備

    可移植性

    暫時可不考慮

    需考慮,但非必須

    必備

    必備

    基于上面的分析,我們已基本確認了不同規模的企業的HRMS系統需要考慮的質量屬性略有不同。

    B、運行期質量

    image

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

    \

    <=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類企業的需求,過程中我們作為一個企業,需要考慮成本、商業模式、企業未來的戰略及盈利等方面的內容

           所以基于這些約束及現狀,我們可以梳理得出以下的關鍵功能及質量、約束的表格。作為后續我們做概要架構的前提和基礎。

    image

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

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

    image

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

    image

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

    image

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

    image

    將關鍵約束衍生為功能:

    image

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

    image

    E、形成統一的二維表(形成關鍵結果)

    (如上表)

    F、總結

           通過上述的幾個環節,我們把不同類型的約束轉化為質量屬性及功能需求,最終我們形成了最終的需求二維矩陣,這將為我們的架構指明方向,后續我們再做架構的設計及規劃的時候就能夠做到有的放矢,不會走錯方向。

     

    四、更多信息

    關于更多的系統架構方面的知識,我已建立了交流群,相關資料會第一時間在群里分享,歡迎大家入群互相學習交流:

    微信群:(掃碼入群-名額有限)

    1537187479(1)

    posted @ 2018-09-22 23:16 何戈洲 閱讀(...) 評論(...) 編輯 收藏
    江苏11选5软件