一种基于Scrum架构与本体技术的SPL管理方法及系统
文献发布时间：2024-04-18 19:52:40
技术领域
本发明属于软件开发领域，具体涉及一种基于Scrum架构与本体技术的SPL管理方法及系统。
背景技术
随着信息技术的飞速发展，大量运行信息系统软件的产品已经深入应用到社会的各个行业。由于用户群体差异化需求日益增多，导致制造商需面对产品线分支众多的挑战。传统的软件开发模式已无法满足制造商缩短产品线开发周期的需求。加强产品线软件资源复用是提升产品开发速率并解决这一难题的合理方法。目前，软件资源复用主要包括：需求复用、构件复用与建模复用等。目前，敏捷软件开发(Agile Software Development，ASD)和软件产品线(Software Product Line，SPL)在加快软件产品开发的应用中加强了对软件资源的复用，在软件行业已体现出巨大的好处。
SPL是一种基于实践或计划驱动的软件开发方法，SPL工程能够在软件行业中大规模生产一系列相关产品。SPL包含两个主要开发过程：领域工程(Domain Engineering，DE)和应用工程(Application Engineering，AE)。DE关注问题域，定义SPL产品的共性和可变性来建立特征并描述需求，用于开发和管理可复用核心资源；AE关注资源复用，并利用可变性开发软件产品。尽管SPL能快速开发高质量、复杂的软件,但是在业务需求经常变更的情况下，SPL常常由于协调成本过高，开发过程与发布周期缓慢，造成软件产品无法跟上市场需求。因此，本发明引入了敏捷开发框架Scrum。Scrum是规划和指导项目流程的迭代框架，其特点是：短迭代开发周期、反思和内省周期、协作决策、快速反馈以及代码更改持续集成到开发中的系统。在Scrum开发流程中，使用迭代和增量方法灵活快速地开发软件产品，能够有效解决SPL在开发过程中的问题。
但是在敏捷软件项目中，由于文档不是优先事项，故缺乏统一的需求描述规范，造成协调成本过高，需求不便管理。因此，大量研究探讨了在Scrum框架中实现SPL的可行性及益处，即协同解决另一方的弱点，实现其共同目标：构建和管理同一领域资源，开发系列软件产品，促进软件资源的复用。但是在Scrum框架中实现SPL的软件开发方法仍然存在高协调成本问题。软件开发是一个复杂的过程，每个软件产品都是所有相关人员以不同方式标记或存储的知识表示，导致开发者、客户等多方在关于产品需求的沟通过程中经常出现理解偏差。
发明内容
为了解决这个问题，本发明引入了本体；本体在计算机科学中常被用作形式上捕捉概念化和关系的描述，能够降低开发者、客户等多方在软件开发过程中由于沟通不当产生的高协调成本问题。本发明提出了一种基于Scrum架构与本体技术的SPL管理方法，该方法包括：
S1：构建SPL管理系统，并对系统进行初始化；
S2：管理者获取用户故事，采用本体模型对用户故事进行匹配，生成需求特征，并将需求特征添加到需求特征待办事项列表中；
S3：获取需求特征本体的构件唯一标识和构件名称，并根据构件唯一标识和构件名称在信息库搜索匹配，若无匹配项，则创建新构件，并将新构件添加到产品待办事项列表中；若搜索到匹配项，则将检索到的结果按匹配度排序，并生成需求匹配列表；
S4：将需求匹配列表的每个构件的匹配度与设置的匹配阈值进行对比，若匹配度小于匹配阈值，则将需求特征本体添加到产品待办事项列表中，否则通过匹配本体搜索构件库，若找到该构件对应代码构件，将需求特征本体与其相似代码构件添加到SPL待办事项列表中，若未找到对应代码构件，则在需求匹配列表中剔除该项；
S5：重复步骤S3～步骤S4，直到当前需求特征待办事项列表清空后，Scrum专家召集所有人员开展Sprint计划会议，得到Sprint目标和Sprint待办事项列表；
S6：DE使用产品待办事项列表开发可变资源和产品线架构，并添加到信息库中；
S7：AE使用SPL待办事项列表迭代开发新产品。
优选的，采用本体模型和本体规则对用户故事进行匹配的过程包括：对用户数据进行预处理，该预处理包括对数据进行清洗和补全处理；采用本体规则对预处理后的数据提取本体片段；其中本体规则包括概念规则、数据类型属性规则、对象属性规则、层次关系规则、公理规则以及实例规则，概念规则用于提取预处理后的用户故事的概念特征，数据类型属性规则用于提取用户故事的数据类型属性，对象属性规则用于用户故事的对象属性，层次关系规则用于提取用户故事的层次关系特征，公理规则用于提取用户故事的公理特征，实例规则用于提取用户故事的实例；根据本体模型中的概念对本体片段中的概念进行匹配，将所有相同概率的本体片段进行集合，生成需求特征。
优选的，管理者为一个Scrum角色，负责管理待办事项列表及其优先顺序，跟踪产品开发。
优选的，Scrum专家为Scrum角色，负责辅助项目团队实现基于Scrum、SPL及本体的敏捷产品线开发管理过程。
优选的，Sprint计划会议为一个由Scrum专家和开发团队参与的会议，用于规划在当前Sprint中要实现的功能。
一种基于Scrum架构与本体技术的SPL管理系统，包括：系统管理模块、需求管理模块和产品开发模块；
所述系统管理模块用于对用户账户、操作权限和数据权限进行管理，在项目启动时录入团队人员信息，并为团队人员分配相应角色及相关角色权限，包括用户管理、角色管理、菜单管理、小组管理功能；
所述需求管理模块用于对复用需求的系统化管理；即产品负责人使用特性表单对用户故事进行获取，借助需求工作流、需求分析、和需求可追溯性的管理，进行产品需求的提炼、条目化、优先级排序；
所述产品开发模块用于管理产品开发过程的工作阶段，实现任务管理、构件上传、迭代开发、产品交付功能。
本发明的有益效果：
本发明提出了一种基于Scrum架构与本体技术的SPL管理方法，以Scrum架构及SPL的概念和技术为中心，侧重于需求分析阶段；提出使用本体定义良好的统一需求描述规范，减少大型前期设计，提高软件资源可复用性和定制性，使软件开发更加灵活和适应变化；采用本体技术，减少了软件开发者、客户等多方在沟通时产生的理解偏差。
附图说明
图1为本发明的一种基于Scrum架构与本体技术的SPL管理方法概述图；
图2为本发明的DE开发子流程概述图；
图3为本发明的AE开发子流程概述图；
图4为本发明实施例中基于Scrum架构与本体技术的SPL管理系统架构图；
图5为本发明实施例中IMC-O本体的关键概念示意图；
图6为本发明实施例中IMC-O本体实例；
图7为本发明的本体模型和本体规则对用户故事进行匹配的流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
一种基于Scrum架构与本体技术的SPL管理方法，该方法包括：
S1：构建SPL管理系统，对系统进行初始化；
S2：管理者获取用户故事，采用本体模型对用户故事进行匹配，生成需求特征，并将需求特征添加到需求特征待办事项列表中；
S3：获取需求特征本体的构件唯一标识和构件名称，并根据构件唯一标识和构件名称在信息库搜索匹配，若无匹配项，则创建新构件，并将新构件添加到产品待办事项列表中；若搜索到匹配项，则将检索到的结果按匹配度排序，并生成需求匹配列表；
S4：将需求匹配列表的每个构件的匹配度与设置的匹配阈值进行对比，若匹配度小于匹配阈值，则将需求特征本体添加到产品待办事项列表中，否则通过匹配本体搜索构件库，若找到该构件对应代码构件，将需求特征本体与其相似代码构件添加到SPL待办事项列表中，若未找到对应代码构件，则在需求匹配列表中剔除该项；
S5：重复步骤S3～步骤S4，直到当前需求特征待办事项列表清空后，Scrum专家召集所有人员开展Sprint计划会议，得到Sprint目标和Sprint待办事项列表；
S6：DE使用产品待办事项列表开发可变资源和产品线架构，并添加到信息库中；
S7：AE使用SPL待办事项列表迭代开发新产品。
一种基于Scrum架构与本体技术的SPL管理方法的具体实施方式，如图1所示，首先，基于Scrum架构与本体技术的SPL管理方法通过本体建立统一需求描述规范，消除敏捷团队之间高协调成本问题；其次，通过重构产品线的现有构件来创建新的变体，实现动态管理需求的变化，提高产品质量；最后，保留了源自敏捷方法中以客户为中心的敏捷交付方法，解决了软件开发周期长，发布过程慢的问题。该方法的开发过程为：产品负责人获取用户故事并进行需求分析，通过工具选择或构建相应需求来反馈用户故事；产品负责人列举出一个产品待办事项列表与一个SPL待办事项列表，用于累计新需求和可变需求；Scrum专家召集项目团队所有成员，展开Sprint计划会，在该会议上确定本次Sprint的迭代任务；DE和AE两个开发阶段迭代开发软件资源及产出产品；一次Sprint执行完成后，Scrum专家召集所有人员开展评审与回顾会议。
如图2所示，在领取了Sprint待办事项列表中的任务后，领域团队将进行为期4周的迭代开发。领域团队将构建工作产品线架构和开发新资源。工作产品线架构使用SPL的工作产品逐步开发，它只包括当前需要的功能。工作产品线架构将具有可变通用组件，可变功能的实现交由应用团队负责。随着新资源添加到信息库中，工作产品线架构将在进一步的迭代中更新，使系统能够与不断变化的需求同步。如果领域团队收到应用团队的请求，可以扩展产品线架构。在此阶段开发的新资源将作为可复用核心资源添加到信息库中，以便在其他项目中复用。在DE阶段，工作产品线架构和新资源将在每个Sprint中进行增量合并。
如图3所示，在领取了Sprint待办事项列表中的任务后，AE将同DE一同进入为期四周的迭代开发。理想情况下，工作产品线内的软件资源可以涵盖所有需求，但在大多数实际情况下，需要进一步开发。这一额外发展发生在这一阶段。因此，这是实际开发的阶段。应用团队将通过可复用资源来构建单个或特定的产品。这涉及特定产品所需变体的选择和应用。可复用资源可能已经存在，它们将按原样重新使用或调整后使用。除此之外，应用团队还可以请求领域团队扩展产品线。如果领域团队接受该请求，则产品特定需求将按照应用团队的请求开发为新资源。AE阶段的结果是：产品增量。
采用本体模型对用户故事进行匹配的过程包括：对用户数据进行预处理，该预处理包括对数据进行清洗和补全处理；采用本体模型对预处理后的数据提取本体片段；其中本体模型包括概念规则、数据类型属性规则、对象属性规则、层次关系规则、公理规则以及实例规则，概念规则用于提取预处理后的用户故事的概念特征，数据类型属性规则用于提取用户故事的数据类型属性，对象属性规则用于用户故事的对象属性，层次关系规则用于提取用户故事的层次关系特征，公理规则用于提取用户故事的公理特征，实例规则用于提取用户故事的实例；根据本体模型中的概念对本体片段中的概念进行匹配，将所有相同概率的本体片段进行集合，生成需求特征。
具体的，采用本体模型对预处理后的数据提取本体片段的过程包括：
步骤1：对预处理后的数据进行自顶向下的标签对查询，并创建实例；具体包括：在预处理后的数据里自顶向下的查询标签对，在通过本体生成器创建相应的实例。例如通过
步骤2：获取标签对所对应的数据；并筛选出对象属性标签，根据对象属性标签获取对象属性，将对象属性添加到概念实例中。
例如标签对所对应的数据包括
步骤3：重复步骤2中的查询查询，当查询到
步骤4：重复步骤2的查询，当查旬到
步骤5：重复步骤2的查询，查询数据类型属性的属性值Memory serviceinterface，创建实例Memory service interface，指定类型为operatingInformation。
步骤6：当所有标签对查询完成后，生成一个本体片段。
在本实施例中，计算匹配度的过程包括：从需求匹配列表中随机选取两个构件的实体；从两个实体中选取两个相对应的节点，采用基于距离的Jaccard系数计算两个节点的匹配度；计算所有节点匹配度的均值，将该均值作为两个构件的匹配度。计算两个节点的匹配度的公式为：
其中，K表示匹配值，v
两个构件的匹配度的计算公式为：
其中，
一种基于Scrum架构与本体技术的SPL管理系统，如图4所示，该系统包括：系统管理模块、需求管理模块和产品开发模块；其中，系统管理模块对用户账户、操作权限和数据权限等进行管理，如为系统用户分配角色及相关权限，主要功能包括用户管理、角色管理、菜单管理与小组管理；需求管理模块实现需求资源信息的发布、存储和管理，并对需求进行任务发布、迭代规划与任务分配；产品开发模块管理产品开发过程的工作阶段，具体包括构件上传、任务管理、迭代开发、产品交付；此外，还涉及对开发过程的进度跟踪，主要包括Sprint会议、进度燃尽图等功能。
如图5所示，参考大量已有模型来建立仪表核心芯片(InstrumentMicrocontroller Chip，IMC)领域本体模型IMC-O并说明其概念。定义领域本体是为了消除软件需求在概念和术语上的分歧，实现其共识知识，并在多个利益相关者之间共享和复用。IMC-O模型主要描述了IMC软件构件的非功能性属性，IMC-O可以用于衍生更精细的仪表软件构件本体。
如图6所示，方框表示一个实例，可以包含属性，边表示描述两个实例关系的对象属性，多个实例可以构成一个仪表设备本体实例。图6(a)为仪表设备实例，主要有设备Id实例、软件构件实例。设备Id实例的属性包括：标识体系与Id编码。图6(b)为软件构件实例，主要有服务操作类实例、服务类实例。服务操作类实例有服务对象信息实例，服务对象信息实例的属性包括外设功能描述、服务约束信息等。服务类实例有功能信息实例、制作信息实例、运行信息实例、构件粒度实例及构件类型实例；功能信息实例有功能描述实例，功能描述实例的属性包括：通信协议、外设驱动、功能模块；制作信息实例有构件信息实例，制作信息实例的属性包括：构件名称、构件版本、开发语言及构件提供商，构件信息实例的属性包括：标识体系与Id编码；运行信息实例的属性包括：硬件环境、软件环境。
如图7所示，本体模型和本体规则对用户故事进行匹配的过程包括：以用户故事作为输入。首先，预处理用户故事，再使用映射规则提取不同的本体片段。映射规则分为六个部分：概念、数据类型属性、对象属性、层次关系、公理和实例。这些规则分析用户故事，并将用户故事转换为相应的本体片段。最后，按本体模型中的概念对本体片段中的概念进行匹配，收集拥有相同概念的本体片段来生成特征需求本体。
以上所举实施例，对本发明的目的、技术方案和优点进行了进一步的详细说明，所应理解的是，以上所举实施例仅为本发明的优选实施方式而已，并不用以限制本发明，凡在本发明的精神和原则之内对本发明所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。