基于用户组织角色权限和资源的五要素

刺骨的言语ヽ痛彻心扉 2022-07-12 03:38 111阅读 0赞

**一、简 介**

在进行本单位办公自动化系统需求分析时创建了基于用户、组织的部门结构、实际工作角色、权限种类、资源树的五要素全排列需求分析方法，并进行了软件的功能需求分析，以及授权本身的管理，该方法是对五个关键要素的重新抽象；我把它命名为五要素全排列需求分析方法，该方法可以较好地避免需求分析时考虑不周全，较多地避免问题隐藏于目标软件中。

**二、背景情况**

目前烟草行业面临我国加入WTO后国外烟草巨头的冲击，宏观方面，行业内正在以惊人的速度进行全国范围内的机构调整，为此导致工业企业的合并重组步伐加大，企业内部的机构调整频度提高。同时，微观方面，由于是在一个变动的时期，企业内部员工，特别是管理人员的工作分工调整十分频繁，因此我们设计的软件系统与组织机构的无关性显得尤为重要，为了较为彻底地解决这个问题，近几年通过“业务流程重组” 实现了企业内部经营流程与组织机构设置低耦合的问题，在此基础上设计的软件系统的生命周期的到较好得延长，同时提高了软件的可用性。这种方法理论上通是在部分企业实践中起到了较好的效果，但是在很多企业因为经营紧迫性等方面的问题，没有时间来进行彻底的业务流程重组，进而许多项目匆匆上马，最后导致项目失败，然后更多企业看到其它企业的失败后干脆进入长期等待。能不能让设计的系统与企业的组织机构，与业务流程耦合度尽可能减少，进而提高软件项目的成功率呢？  
　　运用本文介绍的方法进行了单位的办公自动化系统的需求分析，并设计施了该系统，进行实践时系统采用了B/S体系结构，和J2EE平台，从而适用于多种[操作系统][Link 1]及多种[数据库][Link 2]系统。实施过程中经历了企业内部两次全厂性的组织结构调整，经历了一次与其它企业的合并，三次变革不仅没有造成系统停用，反而对三次变革起到了积极的作用，在三场变革中用该方法设计的软件具有的强劲生命力得到了充分体现。

**三、需求分析及其方法发展水平回顾**

需求分析阶段是信息系统开发最重要的阶段。客户需求分析的目的是软件产品的用户要求，用户需求包括显性的需求和隐性的需求，显性需求是指用户能明确地表达出来的需求，隐性需求是指用户不能明确表达出来的需求，这是因为用户不很明白软件系统的特点。虽然用户有时不知道他要的软件是什么样，但是用户知道什么样的软件不是他所要的，所以软件开发商或供应商应该为澄清他的隐含需求，并满足它。概括起来，需求分析有以下几个目的：  
　　1． 准确地理解和描述客户提出的对软件系统的显性需求，并设法满足之；  
　　2． 挖掘客户对软件系统的隐性需求，并主动满足之；  
　　3． 为软件系统的客户化调整提供依据。  
　　需求分析的任务：  
　　1. 调查研究：了解系统需求、访问用户、考察现场；  
　　2. 确定需求：功能需求、性能需求、可靠性需求、系统费用需求、安全和保密需求等；  
　　3. 描述需求：已经确定的需求应该得到清晰、准确的描述，以便建立起软件开发商或供应商与用户间的沟通平台，通常都要在客户需求调查与分析后用《客户需求规格说明书》的形式将客户的需求描述出来；  
　　需求分析审核：作为需求分析的确认手段，在需求分析的最后对功能的正确性、完整性、系统性和清晰性给予评估。一般是检查所确定的各项需求是否恰当，是否有相矛盾的情况，或是有多余重复的地方。  
　　需求分析阶段首先是了解和澄清用户的需求，然后严格地定义被开发的软件系统的需求规格说明书。一个组织进行信息系统更新或者重新建立一个信息系统的时候，系统需求分析奠定了整个项目的基础。组织要保证信息系统项目的成功，准确的把握系统需求分析是关键的第一步。系统需求分析是一连串的处理过程。要一套有组织的方法来收集信息，找出使用者的需求。经过提炼，将需求（资料的、功能的以及行为需求）模式化，最后得出一份需求报告。在这一过程中，系统开发者扮演的角色就是利用高度的沟通技巧、采取各种不同的形式，将潜在的需求发掘出来，将可能被误解的或是模糊不清的信息加以澄清。  
　　常用的软件需求分析方法有面向数据流的结构化分析方法、面向[数据结构][Link 3]的Jackson方法、面向对象的方法、原型法、已有文档表格和文件抽样法，访问组织站点法，观察工作环境法，问卷调查法，面谈法， JRP(Joint Requirements Planning)法等。  
　　这里仅列举常用的需求分析方法，不再详细介绍。

**四、五要素全排列需求分析方法主要解决的问题**

设计一个较大型的软件常常会碰到这样的问题：系统中的数据授权和功能的授权往往与应用该软件的组织机构设置不尽相同，如果在软件中将这些授权与组织机构设置成紧耦合关系，经常造成因为组织机构频繁调整导致软件不能推广运行，或者因为使用了某系统让决策者变得更加难下决心去变更经营管理的流程。  
　　其它方面，如：权限管理方面存在的难题；受组织结构调整影响软件猝死（停用）；现实中部分管理权限没有规律或交叉授权；不能方便地实现权限管理的集中方式和分散方式切换；个别部门的撤销使资源失去使用者造成信息丢失等。为了解决这些问题，很多人做出了研究和实践，例如基于角色的模型，基于分组的模型等，均没有较好得解决这些问题。  
　　从五个经过抽象的要素：用户、组织、角色、权限、资源入手进行系统需求调研，经过实践证明还是比较成功的；角色、权限和资源三个要素不会有大的变动，人员和机构两个要素的变动随时发生，如何避免发生因为这两个要素的变动给系统造成的停用危机是本方法要解决的问题，同时上述其它方面的问题也得到较好地改善。

**五、五要素全排列需求分析方法介绍**

核心思想：使用该方法在需求分析阶段将用户和组织两个与系统紧耦合的要素解耦，使系统针对的资源与资源在系统中的流转过程（权限）在目标系统中高度内聚，最终设计出能够承受更大限度人员机构变动的系统，同时有效防止用户隐含需求不被发现。  
　　方法简述：因为人员在系统中总是扮演某种角色的，同时业务逻辑希望面对的是系统中的角色，而非扮演角色的具体的人或组织，因此调研初期引入角色这一关键要素，调研过程中用这一要素尽可能叠代用户和组织两个要素，从而来削弱或解调耦合关系，使得用户和组织通过角色与系统之间保持一种松散的关系。  
　　本方法分如下步骤：  
　　1．识别主要要素  
　　本方法的核心是用户、部门、角色、权限、资源五个基本要素，分别用U、D、R、P、M （User,Department，Role，Permission， Material）表示。首先要识别这些要素，亦即首先解决“有什么”的问题，可以通过向客户代表询问，象做判断题一样的方式对下列条目确认，然后帮助用户列举出五要素尽可能多的一些实例，最后帮助用户加以抽象，确定目标系统的五个基本要素的内容。  
　　1). 用户U  
　　a.系统管理员：负责分配由软件开发人员开发的权限的管理权限给权限管理员。  
　　b. 权限管理员：负责将分配给自己的管理权限分配给管理员。  
　　c. 管理员：使用权限管理员分给自己的权限将该权限对应的资源授权普通用户使用。  
　　d. 普通用户：在自己拥有的权限范围内使用相应的资源。  
　　e. 软件开发人员：按照已有的资源，开发相应的权限模块，包括分配权限的管理权限给权限管理员；权限管理员　　分配权限给管理员；管理员分配资源使用权给普通用户等权限模块。  
　　f.每个用户都隶属于一个部门，是一个或多个角色的成员。  
　　g. 用户对资源的权限表现为拥有一个权限记录的集合，每个记录表示了用户对某范围资源的操作。此权限集合是　　由系统管理员、权限管理员或者管理员在行使权限时产生、修改或删除，由用户拥有。  
　　2).部门D  
　　a. 部门在组织内是树形结构。  
　　b. 有且只有一个根部门，根部门就是使用该软件系统的组织。  
　　c. 每个部门都有名称、上级部门（根部门除外）、上级主管、部门负责人（可以是多个）、一定的成员，一般会　　有仅隶属于本部门的资源。  
　　e. 部门可以有多个子部门，子部门还可以有多个子部门。  
　　3).角色R  
　　a. 每个角色有一个固定的名称。  
　　b. 每个角色至少有一个用户。  
　　c. 每个角色至少对一种资源有某种权限。  
　　d.每个用户分类\[1).a至1).f\]是一个角色。  
　　e. 角色常常对应了一个权限集合。用户可以通过加入角色，成为角色的成员，进而拥有权限集合。  
　　4).权限P  
　　a. 每个权限有一个名称，有一个具体的意义，可以表示出谁（角色|部门|具体用户）对什么资源可以进行哪些操　　作。  
　　b. 每个权限可以在至少一个资源上使用。  
　　c. 每个权限可以授给某个部门的某个角色，不可以授给单独的一个部门或一个角色，一般不直接授给某一个用户　　。如果需要授给单独的一个部门或一个角色某个权限，可以使用“授给根部门的某个角色”，或“授给某个部门的　　所有角色”的方式实现。  
　　d. 授权时不指定具体的资源，则此授权是权限管理员授权给管理员  
　　e. 授权时指定具体的资源，则此授权是管理员授权给普通用户。  
　　f. 授权可以拟向执行，即收回授权。  
　　g. 权限记录。  
　　　1.权限记录一般是正向权限，这样可以降低权限记录的复杂性。  
　　　2.权限记录中确定了资源范围，用户如果拥有该权限记录，则有对该权限记录指定范围内的所有资源的权限,同　　　时包括对资源进行哪些操作。  
　　　3.权限记录能判断包含关系，即一个权限记录是否包含另外一个。  
　　　4.为了组织好权限记录，建议采用权限集合的形式。  
　　h. 权限有不同的类型，依据资源类型的种类，权限可以是数据权限，也可以是功能权限，特别地，对数据的管理　　权限是一种功能权限，数据权限包括：读、写、添加、删除等，功能权限主要指是否可以使用某功能。  
　　5). 资源m  
　　a. 资源包括数据资源和功能资源。  
　　b. 资源使用树状管理，不同的资源在不同的树上，资源在系统中以森林的形式存在  
　　　(在这里引入树丛的概念，管理方式相似的树称为树丛，森林可以由很多树丛构成，也可以由一个树丛构成)。  
　　c. 每种资源对应有一个或多个权限。  
　　e. 在资源树上某一节点授权可以指定是对该节点还是对该节点下的所有分枝。  
　　2．按照5)识别出的每个树丛，按下面的方法进行全排列，分析步骤1中识别出的各要素之间的关系，形成一个列表。  
　　如果说第一个阶段解决"有什么"的问题，那么第二个阶段解决"做什么"的问题。  
　　要素之间的直接和间接关系全排列共有P51\+P52\+P53\+P54=205种,每种排列对应未来软件中的一个可能存在的功能模块或用户界面，这些排列表示的意义通过其它的需求分析方法调研，有些用户是可以能明确地表达出来的，例如P51 \+P52表示的是如下表的25类功能需求，如下表：

表1　p51\+p52表示的功能需求

<table> 
 <tbody> 
  <tr> 
   <th>&nbsp;</th> 
   <th> 
    <div>
      U 
    </div> </th> 
   <th> 
    <div>
      D 
    </div> </th> 
   <th> 
    <div>
      R 
    </div> </th> 
   <th> 
    <div>
      P 
    </div> </th> 
   <th> 
    <div>
      M 
    </div> </th> 
  </tr> 
  <tr> 
   <td> 
    <div>
      U 
    </div> </td> 
   <td> 
    <div>
      用户管理需求分析 
    </div> </td> 
   <td> 
    <div>
      用户与隶属部门 
    </div> </td> 
   <td> 
    <div>
      用户拥有的角色 
    </div> </td> 
   <td> 
    <div>
      用户拥有的权限 
    </div> </td> 
   <td> 
    <div>
      用户可使用的资源 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div>
      D 
    </div> </td> 
   <td> 
    <div>
      部门拥有的用户 
    </div> </td> 
   <td> 
    <div>
      部门管理需求分析 
    </div> </td> 
   <td> 
    <div>
      部门中有那些角色 
    </div> </td> 
   <td> 
    <div>
      部门拥有的权限 
    </div> </td> 
   <td> 
    <div>
      某部门拥有的资源 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div>
      R 
    </div> </td> 
   <td> 
    <div>
      角色成员 
    </div> </td> 
   <td> 
    <div>
      某角色的部门分布 
    </div> </td> 
   <td> 
    <div>
      角色管理需求分析 
    </div> </td> 
   <td> 
    <div>
      某角色拥有的权限 
    </div> </td> 
   <td> 
    <div>
      某角色拥有的资源 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div>
      P 
    </div> </td> 
   <td> 
    <div>
      某权限的管理者 
    </div> </td> 
   <td> 
    <div>
      有某权限的部门 
    </div> </td> 
   <td> 
    <div>
      拥有某权限的角色 
    </div> </td> 
   <td> 
    <div>
      权限管理需求分析 
    </div> </td> 
   <td> 
    <div>
      某权限针对的资源 
    </div> </td> 
  </tr> 
  <tr> 
   <td> 
    <div>
      M 
    </div> </td> 
   <td> 
    <div>
      资源拥有者 
    </div> </td> 
   <td> 
    <div>
      拥有资源的部门 
    </div> </td> 
   <td> 
    <div>
      拥有资源的角色 
    </div> </td> 
   <td> 
    <div>
      资源的权限 
    </div> </td> 
   <td> 
    <div>
      资源管理 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

表中的内容多数用户是可以提出来的，这些排列在具体的系统中对应不同的功能及界面。然而P53，P54表示的是什么需求？在对用户进行调研时用户多数是不能明确提出来的，这一部分往往就是用户的隐含需求，因为其它的需求分析方法多数是挖掘式的，所以很难保证用户这些隐含需求能被调研出来，而本方法是先排列出来这些或许存在的功能，再进行调研，请用户判断是否需要，因此是不容易被忽略的。  
　　例如：1. (d,p,m)的排列表示“以某部门拥有所有权限对应的所有资源的列表的形式的操作”一类的功能模块，而(p,d,m)的排列则表示：对某权限分布在的部门拥有的相关资源进行操作” 2. (d,r,p,m)的排列表示的是“某部门的某角色拥有的权限对应那些资源”一类的功能模块，而(m,p,r,d)表示的是“某资源的某权限在某角色中对应那些部门”一类的功能模块。  
　　事实上，如果把每种排列全部列出是没有必要的，分析某类有共性的排列对应的现实意义如果不存在，可以用剪枝法直接忽略，进而降低调研的规模，但是使用剪枝法时一定要防止误剪。  
　　3. 进行叠代解耦  
　　将步骤2产生的结果中包含部门的项尽可能使用该部门中的相应角色代换，将有关用户的项尽可能使用该用户所属的某一角色代换，最终使得包含部门或包含用户的项尽可能少，实际上最后包含部门的项仅剩下有关该部门的属性项，最后包含用户的项只剩下该用户的属性项，这一步起到了将用户和组织两个与系统紧耦合的要素解耦的作用。  
　　4. 转换成自然语言征求用户意见  
　　将步骤3形成的列表转换成容易理解的自然语言与客户沟通，让客户选择是否需要该功能，如果用户需要，请用户描述并记录。这一步骤起到了主动挖掘客户对软件系统的隐性需求作用。  
　　5. 形成需求分析报告  
　　根据步骤4用户确认后的列表，编制出清晰、准确的描述，最终建立起软件开发商或供应商与用户间的一致意见，用《客户需求规格说明书》的形式将客户的需求描述出来。  
　　6. 进行需求评审

**六、结 论**

1． 使用本方法解决了标题四中的主要问题，其它方面的问题得到了明显改善。  
　　2． 本方法适合多种信息工程的需求分析，特别适合致力于某一领域信息系统开发的软件公司。采用此方法，开发同类项目越多，需求分析工作的效率越高。  
　　3． 本方法最后形成的是一个高度灵活的权限模型，这样的模型可以适用于非常多的系统，同样适合其它大型软件工程。  
　　4． 在需求分析过程中，由于充分考虑到系统的设计与现实之间的联系，因此与其它需求分析方法向比，提高了对需求分析人员的要求。在实际工作中，一般由资深的软件分析和设计人员进行。  
　　5． 由于需求分析工作本身的难度和重要性，此方法同样要求用户单位和需求分析人员对需求分析所有工作内容，引起足够重视；科学安排需求分析工作步骤，某些步骤可以同时进行；所有工作步骤不得应付或疏忽。

**七、需要进一步研究的问题**

1．在一些系统中，除“对什么资源”进行“什么操作”之外，需要很多地使用工作流程，本能否适合有很多工作流程的系统需要进一步研究。  
　　2. 是否可以将用户、组织、角色三个要素作为一个要素，与权限、资源合在一起按照上述方法，形成三要素全排列法进行需求分析更有意义，尚需进一步研究。  
　　 3．使用本方法设计的系统会出现授权链的问题，而且链的层次深度不易控制，需要使用其它方法防止。  
　　 4．在使用本方法进行实践过程中，发现该方法可以设计出相应的权限管理模型相当灵活，包括数据授权和功能授权等，应该进一步研究。  
　　 5．除使用剪枝法外，如果能够有其它方法更有效降低全排列的规模，尚需探讨。

**八、参考资料**

1． 冯玉琳 赵保华 软件工程（第二版）；  
　　　2． 郑人杰、殷人昆、陶永雷等《实用软件工程》（第二版）；  
　　　3． Roger S.Pressman 《软件工程：实践者的研究方法》（第5版）；  
　　　4． 卢琳生 管理信息系统需求调研分析指南 www.51cmm.com （软件工程专家网）；  
　　　5． 唐晓辉 编译 系统需求分析方法－JRP法 www.ie56.com (浙江工业大学)。

[Link 1]: http://lib.csdn.net/base/operatingsystem
[Link 2]: http://lib.csdn.net/base/mysql
[Link 3]: http://lib.csdn.net/base/datastructure