企业信息系统开发中的过程挖掘与一致性

International Journal of Information Management Data Insights 3（2023）100141企业信息管理系统开发过程一致性Elia Kouzari，Lazaros Sotiriadis，Ioannis Stamelos塞萨洛尼基亚里士多德大学，信息学院，塞萨洛尼基54124，希腊aRT i cL e i nf o保留字：进程挖掘软件事件日志企业信息系统企业系统开发a b sTR a cT本文研究了如何在企业信息系统开发中使用过程挖掘来检查过程一致性超越纯粹业务流程使用流程挖掘的概念以两个开源企业系统的bug关闭流程为例。提取的过程模型和结论用于绘制一些通用的指导方针，企业信息项目经理可以采用评估他们的系统开发过程的质量。在两个开源企业信息系统的Bugzilla数据库中使用Disco进行流程一致性检查。提取的模型基于项目文档进行评估，并与Bugzilla团队建议使用的bug关闭过程进行比较。调查结果显示，项目中遵循的流程与其文档中的流程非常相似，符合Bugzilla指南。然而，在特定情况下会出现一些变化。简要总结了应用过程挖掘技术进行信息系统开发管理的潜在效益。该实证研究扩展了先前在流程挖掘领域所做的工作，并强调了流程挖掘在企业信息系统开发中的重要性和必要性，以帮助规范和改进组织的内部流程，并作为外部合作者为组织开发软件的合规性证明。另外，本文还对目前许多企业软件开发公司采用内部源代码开发模式进行了分析。1. 介绍经过近20年的研究，流程挖掘已进入成熟阶段，该领域可以展示科学研究、平台、工具和算法的组合过程挖掘已广泛应用于医疗保健、保险、软件等各种领域和部门（Rojas等人，2016年，Partington等人，2015年，Delias等人， 2013年，DeWeerdt等人，2013年，Rubin等人，2014年，Mahendrawathi等人， 2018年）。随着对该领域的研究兴趣不断增长，可以在独立的基础上或通过旨在促进这一点的平台提供一系列流程挖掘算法。因此，在过去的几年里，已经发表了许多关于流程挖掘应用的研究论文和案例研究考虑到其工具和应用的成熟性，流程挖掘 也被项目经理使用，作为一种工具，在管理各种领域的项目时提供效率。尽管流程挖掘技术在企业中得到了广泛的认可，但在某些情况下，识别用于从流程挖掘任务中获得最大收益的正确工具仍然很困难。项目经理需要指导-关于在各种项目中正确应用过程挖掘的观点，以及关于可用工具的进一步教育，在每种情况下构成理想候选人的过程，以及成功结果所需的数据的数量和质量（Grisold等人，2020年）。此外，开发和实施决策模型以帮助管理人员做出决策至关重要（Deepu和Ravi，2021）。在Process Mining中发表的大多数研究都集中在过程发现上，这有助于最大限度地减少理解当前“原样”过程的成本然而，在过程一致性方面也产生了很多兴趣。Van der Aalst将流程发现描述为获取事件日志并生成流程图以解释日志中记录的行为的技术（Van der Aalst，2016）。另一方面，流程一致性是将现有流程模型与同一流程的事件日志进行比较的过程，以指示日志中记录的现实是否符合建议的模型，反之亦然。最近发表的一些研究文章展示了新的流程挖掘算法的发展，现有工具和算法在新领域的应用，以及流程挖掘在以下方面的应用：∗ 通讯作者。电子邮件地址：ekouzari@csd.auth.gr（E. Kouzari）。https://doi.org/10.1016/j.jjimei.2022.100141接收日期：2022年3月7日;接收日期：2022年11月19日;接受日期：2022年11月26日2667-0968/© 2022作者。由Elsevier Ltd.发布。这是一个CC BY-NC-ND许可证下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）目录可在ScienceDirect国际信息管理数据见解期刊主页：www.elsevier.com/locate/jjimeiE.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001412审计目的。沙佩拉-坎帕等（Chapela-Campa等人，2019），提出了一种从流程模型中检索频繁行为模式的算法。该算法通过识别具有最常见控制结构的模式来解决复杂过程模型中隐藏的人工信息问题。因此，科学家可以检查业务流程中实际发生的事情的证据，而不管预期发生什么。另一方面，上下文感知过程挖掘与机器学习技术相关，旨在通过在数据预处理中采用聚类技术来管理复杂事件日志来改进过程挖掘（Becker和Intoyoad，2017）。这种过程挖掘技术可以分析大数据集中提供的大量异构过程，以调查过程挖掘可以自动化的程度。流程挖掘技术作为一种新的工具已经开始出现，被企业信息管理人员用来有效地管理信息管理系统中的流程。据报道，项目管理与知识管理和社会传播相结合将成为未来几年学术研究的重要领域（Sharma等人，2021年）。协作和关系不是严格定义的和静态的，并且通常，这些中的变化干扰系统开发，导致不连续性（Smolander等人，2021年）。特别是对于软件开发过程，过程挖掘技术可以应用于通过提供系统中发生的事情的足迹来揭示实际过程，并为企业信息管理人员提供操纵软件开发并防止偏离商定程序所需的见解。流程挖掘的应用不仅仅局限于商业领域，商业软件，因为有数字开源系统广泛用于今天的企业。开源系统中的流程挖掘可以帮助标准化或改进核心活动，例如共享任务和关闭错误的方式（Kouzari和Stamelos，2013）。鉴于开源项目公开了大量与过程相关的数据，它们构成了发现和分析软件过程并得出与所遵循的软件开发过程相关的结论的绝佳机会。这些数据通常可以从邮件列表、讨论论坛、源代码库和二进制版本部分中提取（Jensen和Scacchi，2004）。开源社区发明和应用的实践、技术和工具通常也会在商业系统开发中找到自己的方式。必须强调的是，虽然开放源码软件的开发主要是基于在志愿者方面，在大型和成功的项目中，社区成员越来越重视系统质量和团队纪律。从这个意义上说，OSS和商业开发并没有区别，因此本研究的结果也可以转移到传统的系统开发中。此外，许多封闭代码开发团队在内部开发软件时采用应用内部源代码概念的公司包括SAP、Microsoft、HP和PayPal，而欧盟委员会本身的目标是使内部源代码成为其内部代码的主要开发模式。很明显，过程挖掘可以用于任何类型的企业软件，以阐明整个开发过程和现有工作方式的一致性，补充与OSS的开发和可持续性相关的其他类似研究（Liu et al.，2021年）。本文将过程挖掘方法应用于两个成熟的企业级开源软件系统（OTRS和Koha ILS）的缺陷关闭过程中，以实现过程一致性。选择这两个系统是因为它们的开源性质允许提供数据以及解决错误时应该遵循的过程的书面证据。这方面，连同其成熟性和稳健性，为提取指示性结论提供了两个重要案例。作者检查了项目的文档，并提取了被认为应该遵循的过程模型根据从每个项目的事件日志中提取的“原样”流程，此外，这些流程也与一般的Bugzilla指南进行了比较，用于错误报告和解决。得出的结论可用于启发信息管理领域面临的一些挑战。例如，其中一些涉及到遵守和效率之间的平衡， 以及存档或处理信息并在需要时采取行动的重要性。文章的其余部分结构如下：第二部分介绍了这项工作的背景，并提出了研究问题。第3节解释了所遵循的方法步骤，第4节介绍了研究结果。最后，第5节包含了讨论，结论和未来的工作。在整个论文中，作者提供了各种技术细节，以帮助其他研究人员复制我们的工作。2. 背景工作无可否认，数据驱动着所有领域的业务，数据驱动的决策至关重要。从各种信息系统中可用的数据集获得的可操作见解应增强个人和组织的判断力（Kushwaha等人，2021年）。流程挖掘可以帮助评估系统中底层数据的质量，确保信息系统日志将捕获组织内发生的整个操作范围。为了实现这一点，流程挖掘可以与其他技术一起应用，以促进源数据的质量分析。这些举措（Eschoual等人，2018），专注于对源数据进行丰富的分析，以进行质量检查，验证数据集的质量或通过检测质量问题来突出错误的参数。因此，流程挖掘可以促进跟踪连续工作流程的挑战性任务， 关于交换的数据对象（Hübscher等人， 2022年）。在Zerbino et al. （2018）作者研究了过程最小值的作用-作为一个专家系统引擎的在线信息系统审计。分析的深度，更容易的自动化，更少的侵入性的过程挖掘启用方法比现有的EX pert系统和工具的信息系统审计，只是这种方法的优点的一小部分。因此，作者发现了可能暗示法律和运营风险以及不可预测的工艺偏差的不符合项，这些偏差可能导致工艺总体改进。Mahendrawathi et al.（2017）还通过在业务流程层面对ERP实施进行实施后审查来研究流程一致性。作者使用Disco工具分析一家农药公司的采购过程，发现采购过程中的预期路径和异常路径。对所遵循流程的深入了解是有价值的，因为他们能够识别各种情况下执行时间的重大差异。在这种情况下，流程挖掘有助于突出应该重新解决的瓶颈，以便优化流程。Paszkiewicz（2013）作者专注于制造组织的产品管理过程，以展示其适用性一致性检查技术。Disco和ProM流程挖掘工具用于分析事件日志并评估生成的流程图。作者强调了自动化连接技术在评估组织运营方面的重要性，强调了快速和无需人为判断的工具的重要性。通过将管理层纳入自动化过程一致性分析的解释中，可以决定进一步的行动，例如员工培训活动、重新设计过程以消除差异等。随着研究和行业对一致性检查的兴趣转移，在最近的工作（Rajesh，2021）中，作者对流程挖掘的一致性检查技术进行了调查。由于今天的信息系统是过程感知的，并且能够记录系统的见解，因此可以获得正在实施的过程的清晰画面。然而，作者认为，大多数E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001413现有的一致性检查技术大多基于控制流，没有考虑质量参数、资源、时间和算法类型。通过使用上面列出的参数丰富流程挖掘结果的解释，一致性检查将提供更精确的报告，针对组织管理层提出的问题进行定制。企业软件应用程序被广大企业广泛使用。大多数组织实施专有系统，而其他组织则信任开源软件。企业开源软件与SAP、Microsoft或Oracle等大公司支持的非常强大的商业应用程序竞争。因此，OSS的过程质量对企业来说至关重要.一项基于ERP系统中流程挖掘的研究，使用从公 司 数 据 库 中 提 取 的 事 件 日 志 来 发 现 流 程 模 式 ，随 后 是（Mahendrawathi等人，2018年）。研究结果表明，预期的过程已经遵循，但似乎存在一些不稳定性。这些变化在组织的总体规划中可能具有重要意义，因此必须监控规划中的持续变化，以确保符合设定的KPI。Kouzari等人（ 2018）作者研究了bug关闭亲-使用其数据的现有开放源码企业系统的成功Bugzilla数据库，并根据社区文档和Bugzilla指南评估流程。尽快检测错误和其他软件缺陷对于软件项目至关重要，因为这可以降低项目的运营成本。采用可用的软件工具和方法来促进早期识别软件缺陷的过程是必不可少的（Tameswar等人，2022年）。在下文中，作者简要介绍了Bugzilla和Bugzilla bug跟踪过程，以及所研究的两个系统。最后提出了研究问题2.1. Bugzilla成千上万的软件项目转向Bugzilla，因为它是最知名的bug跟踪系统（Uplenchwar和Puri，2017）。Bugzilla是开源软件，成千上万的开源社区采用这种解决方案来促进软件错误的解决。开发团队通过报告在项目的Bugzilla数据库中发现的bug来利用Bugzilla的通信工具。对于每个报告的错误，从发现错误的场景开始，详细记录其历史记录，以及各种状态，标签，进行的讨论和针对其解决方案完成的步骤Bugzilla社区有丰富的关于bug跟踪解决方案的使用和软件bug处理的文档。图1突出显示了在生命周期中可能标记任何bug的各种状态。作为一个开源解决方案，Bugzilla鼓励社区 改变这个生命周期，以适应每个项目的需要。因此，基于Bugzilla进行bug跟踪的项目的bug处理过程可能会有很大的不同。通常，一旦数据库中报告了错误，其状态将设置为UNCONFIRMED。根据软件社区的指导方针，一旦几个社区成员验证了其有效性，此状态可能会更改为NEW。但是，如果允许在Bugzilla数据库中记录bug的用户修改bug的状态，则bug可能会启动其生命周期处于NEW状态。一个bug可以保持在状态NEW，等待有人来解决它，一旦用户/开发人员被分配来处理它，它就转换为ASSIGNED。一旦有了一个bug的解决方案，需要发送补丁以进行质量保证（QA）。如果QA测试通过，则bug被标记为已解决并已验证。在QA失败的场景中，bug被设置为REOPEN，然后可以被分配或在未来解决为了让bug结束它的生命周期，Fig. 1. Bugzilla中bug的生命周期12.2. 开放式跟踪售票系统OTRS2是一个服务管理套件，包括票务，工作流程自动化和通知服务。 它最初于2001年作为开源帮助台票务软件发布。虽然OTRS商业解决方案（商业版）于2015年发布，但OTRS社区版仍然是开源的，并通过以社区为中心的网站提供支持。该系统是用Perl/JavaScript编写的，使用GitHub作为存储库，并在GNU AGPL许可证下分发。OTRS也是多平台的，全球有17万家公司使用它，被翻译成38种语言。为了跟踪bug，OTRS维护自己的Bugzilla数据库。该项目表明，其业务解决方案提供了增强的功能，并优先于错误解决方案。然而，OTRS的项目社区致力于解决bug，以保持软件的社区版本功能和有用。OTRS严格遵循Bugzilla的bug解决指南。因此，没有额外的文件说明为此目的的项目定制流程。这使得关于OTRS的过程一致性检查非常有趣，因为结果预计符合官方Bugzilla指南和文档。第一次报告的用户必须将其状态设置为关闭。根据纳-对于bug和记录它的社区成员的权威，在同一个项目中可能存在不同的生命周期（Akbarinasaji等人，2017年）。1Bugzilla中bug的生命周期-来源：https://www.bugzilla.org/docs/2.18/html/lifecle.html。2https://otrs.comE.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）10014142.3. Koha综合图书馆系统Koha是一个基于Web的开源集成库系统（ILS），用Perl编写，并在GNU通用公共许可证下发布。 3Koha的实现基于各种操作系统中的MySQL数据库。Koha于2000年发布，从那时起，它就保持了一个活跃的开发人员社区。公共和私营部门的数百个组织已经实施了Koha，保证-走向全球接受（Kouzari和Stamelos，2018）。作为 ILS，Koha支持许多与图书馆相关的活动（Macan等人，该解决方案提供了一个可配置和自适应的用户界面，允许组织根据所遵循的程序和政策配置解决方案。Koha维护了一个Bugzilla数据库，社区在其中丰富了相关的wiki、论坛和博客，以便于处理和解决bug。社区鼓励 开发人员和所有成员浏览描述所遵循的程序的相关材料，以便在整个项目中保持有效的沟通。Koha错误遵循其自身的生命周期，正如社区相关文档中所述，鼓励开发人员在提交错误之前咨询错误解决指南。任何社区成员都可以在Bugzilla中报告bug。虽然社区不支持Bugzilla优先级字段，但他们正在使用严重性字段来表示bug的重要性。因此，一旦注册了bug，必须设置其严重性（例如正常）。在注册了一个bug之后，它被分配给一个开发人员。如果受让人没有采取任何行动，则错误可能会在将来重新分配。当一个受让人打算发起一个bug的解决方案时，受让人需要接受它并将它的状态从NEW更新为ASSIGNED。出于QA目的，为bug提交的补丁会导致将bug标记为PATCH-SENT。由于Koha维护着一个由数千名开发人员组成的活跃社区，因此发布经理负责验证提交的补丁的有效性如果QA成功，则bug被标记为PUSHED，并从ASSIGNED转换为已解决-已修复。2.4. 研究问题基于上述所有特征以及他们庞大而活跃的开发者和用户社区，Koha和 OTRS在当时被认为是本研究背景下的合适候选人。第2节中介绍的错误工作流程基于Koha和Bugzilla的官方页面中提供的文档，它明确指出OTRS遵循Bugzilla的bug解决指南。因此，通过在两个项目的错误解决过程中执行过程挖掘，Koha将遵守自己的错误解决过程，而OTRS将遵守Bugzilla指南。由于这两个项目至少部分是开源项目，它们的数据和代码可以通过项目社区使用的工具获得，从而允许流程挖掘。以及过程一致性检查。因此，本文研究的问题如下：这些项目的开发人员是否遵循项目页面中描述的错误解决流程？如果没有，实际过程是怎样的？RQ2：bug解决过程有哪些不同？每个项目最常见的过程差异是什么？通过调查这些研究问题，作者希望在一定程度上，开发人员遵循预先定义的企业信息开发过程。此外，我们的发现直接适用于内部源开发。3https://koha-community.org表1为流程挖掘定位、准备和清理数据方法阶段O笔源系统KohaOTRS查找相关数据19，311个错误8,000只虫子数据准备CSV文件，359，395记录CSV文件，77，011记录干净数据97372事件日志记录事件日志，22，895条记录3. 方法第2节中介绍的每个项目的Bugzilla页面可由任何注册用户免费访问。因此，所有列出的错误以及每个错误的历史记录都可供访问。Bugzilla的主页面展示了所有当前的bug及其当前状态.为了获得为解决一个bug，必须使用bug ID并访问特定页面，该页面以表格形式说明了到目前为止所采取的操作在这项研究中，作者遵循他们在工作中成功使用的方法（图2），作为在流程挖掘的数据清理和转换活动之后收集项目中列出的错误信息的初步步骤。表1列出了每个项目前三步提取的记录和事件数量，以生成用于流程挖掘的最终事件日志。3.1. 数据收集该方法的前三个步骤侧重于从两个项目中收集数据。根据文献中提出的流程采矿活动准则，首先，数据位于 Bugzilla项目的数据库。必须对提取的数据进行处理，以创建有效格式的事件日志，这是在所选流程挖掘工具中进行流程分析所需的。关于下面给出的步骤的更多细节可以在Kouzari et al. （2018年）。3.2. 查找相关数据Koha和OTRS Bugzilla数据库是两个项目的提取数据源。这两个数据集都是使用Bash脚本和Wget工具以HTML格式检索的。每个项目的所有提取文件最终都附加在每个项目的单个HTML文件中。3.3. 数据准备Html2text用于从收集的数据中删除任何格式化的文本。此外，为了准备流程挖掘所需的事件日志，通过进一步的脚本编写形成了csv文件3.4. 干净数据对于每条记录，存在以下列：Event_Id、Bug_Id、Bug_Description、User_Email、Action_datetime、Action_Type和Action_Data。尽管此结构包含用作事件日志的所有必需列（Van Der Aalst和Dustdar，2012），但必须对文件进行进一步清理，以保留这些数据这将揭示解决bug所遵循的过程。这是必要的，因为列Action_Type和Action_Data具有多维特性。更具体地说，虽然前5列的命名揭示了它们的作用，但Action_Type和Action_Data列用于保存最重要的信息。对于Action_Type列中提到的每个变量，在Action_Data列中使用了不同的值集。在分析了Action_Type列中的每个变量并考虑到E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001415图2. 本文所遵循的流程一致性检查方法。项目的页面和wiki，CSV文件被过滤以保存Action_Type列（状态、优先级、严重性和解决方案）的特定变量的记录。因此，这种类型的过滤有助于提取反映过程实例的过程模型和反映错误解决过程的维度。最终，第3阶段（清理数据）产生的两个csv文件被用作流程挖掘的事件日志。第4节介绍了与流程挖掘和流程一致性检查有关的其余步骤。4. 结果4.1. 过程挖掘对于流程挖掘活动，使用了Disco4流程挖掘工具。对于每个数据集，事件日志如下所示-把它放到迪斯科，相应地标记每一列，得到以下结 果 ：映 射 ： Case_ID （ Bug_Id ） 、 Resource （ User_Email ） 、Timestamp （ Action_Datetime ） 和 Activity （ Action_Type 和Action_Data）。Event_ID和Bug_Description被忽略，因为此时它们在检查错误解决过程中没有作用。在挖掘数据以调查结果后，查阅了Bug_description。最初，两个事件日志的流程挖掘导致了“意大利面条模型”。这样的模型代表了事件日志中所有状态的每一个可能的转换，类似于一个完整的图。因此，“意大利面条模型”隐藏了系统内遵循的主要流程以及其他有用信息，如最常见的流程差异、例外行为、最常见的活动等。为了集中分析遵循的流程，进行了进一步过滤在两个事件日志中，基于每个事件的区别特征。过滤将使过程图与项目文档中描述的过程图具有可比性，从而可以提取具体结论。事件日志中50%的最频繁活动被保留下来，从而提取出更清晰的流程模型，使作者能够专注于遵循的主要流程并促进分析。特别是对于Koha，执行的初始过滤显示了283个案例，其中错误生命周期的第一步是“状态/关闭”。研究人员发现，对于所有这些病例，Bugzilla数据库中仅存在一条记录。这些错误的解决历史不可用，因此过程模型将通过误导性的结果和转换进行检查和解释。连同已经使用的过滤，作者决定从事件日志中排除这283例病例。图图3和图4显示了初始过滤后OTRS和Koha（再生）的工艺模型。过程模型在下面进一步解释。图中的粗体流程步骤表示最常见的错误状态，粗体箭头表示这些流程步骤中最频繁的转换。因此，通过检查图表，可以识别每个系统遵循的最常见的过程路径。为清楚起见，在表2中列出了这些内容。表中提到的所有流程步骤都与Action_Type字段的值Status，与Action_Type字段的值Resolution关联的标签FiX4https：icon.com/disco/-Disco process mining software的官方页面。为了更好地说明所遵循的过程模型，在两个事件日志中进行了进一步的填充，以便关注与漏洞关闭过程直接相关的状态和解决方案维度。还应用了终点过滤器来保留已解决的错误以及遗漏和不完整的病例，因为这些病例不属于本研究的范围。结束事件的值被设置为固定的，生成的过程模型如图1和图2所示。5和6（分别为OTRS和Koha）。图与图3相比，OTRS的最终过程模型似乎略有修改。Status-NEW不是图5中流程模型的一部分，因为它对事件日志进行了过滤。这背后的原因在于进行研究时，因为大多数被识别为新的错误尚未完全解决，因此其生命周期不包括解决/修复状态。但是，仍然突出显示了漏洞解决所遵循的流程，并在以下章节中用于评估流程符合性。在Koha Fig. 图6呈现了与图4中呈现的过程非常相似的过程。然而，在bug解决过程的最后几个步骤中，似乎有一些变化。错误解决过程与删除283个案例之前的过程非常相似，这一事实表明Koha社区一直致力于解决错误的指导方针4.2. 过程一致性检查4.2.1. OTRSOTRS社区研究的文档没有包括任何关于Bugzilla指南之外的错误解决过程的进一步信息。在大多数情况下，产生的过程模型似乎遵循这些指导方针。一个bug的生命周期的清晰路径在两个图中呈现。3和5。据观察，未确认状态未被广泛使用，表明OTRS社区首选的错误初始标签是新的或已分配的。 必须注意的是，如果项目管理员启用了UNCONFIRMED选项，则该选项可能会表3列出了OTRS最常见的一些工艺差异。17.92%的bug被立即解决并关闭，这表明开发人员可以在不遵循项目指南的情况下立即解决bug。此外，3.68%的bug通过分配而不是标记为NEW开始其生命周期。1.32%的被标记为已解决的bug被重新打开，以便在关闭之前再次遵循bug解决过程4.2.2. Koha图4和6确认了解决bug的实际过程是Koha社区文档中提供的过程。因此，通过过程挖掘工具进行的过程一致性检查验证了项目博客和wiki中推荐的错误解决过程。然而，正如预期的那样，对于一些报告的错误，也有一些过程变化。表3其中一些。对于所研究的Koha事件日志，4.14%的流程实例表明错误仅被注册为已解决和已关闭。在这种情况下，可能会出现两种情况第一个是关于没有历史数据的旧错误第二种情况是社区成员首先发现了一个bug，修复了它，并立即报告它为Resolved。然而，它明确地E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001416图3.第三章。在过滤了50%的最频繁活动之后，为OTRS提取的过程模型。表2OTRS和Koha事件日志中遵循的最常见流程路径最常见的流程路径OTRS新>已分配>已解决>已解决/已修复>已关闭Koha需要签核>签核>通过QA>推至主文件>推至稳定>已解决>已解决/已修复>已关闭。在项目文档中指出对于其余的过程差异，可以考虑与所有过程差异类似的因素，或者从错误解决过程开始时错误未设置为NEEDS SIGNOFF，或者忽略几个过程步骤，直到错误设置为CLOSED。以下各节将根据所做的比较，进一步讨论所揭示的过程及其差异使用Bugzilla建议的过程解决方案。第5节还包括一些一般性的结论，增加价值的过程挖掘技术可以带来的管理过程中的信息管理系统的发展在一个组织。5. 讨论和今后的工作从Bugzilla数据库中为两个项目中的每一个项目创建的事件日志通常都显示了两个企业系统通信。E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001417图第四章 当从事件日志中删除前283个错误并对最频繁的活动进行50%过滤时，为Koha提取的过程模型。表3不符合每个项目过程指南的前5个最常见的过程差异过程差异频率项目：OTRS已解决->已解决/已修复->已关闭17.92%已解决->Resolution/WorksForMe ->已关闭8.86%已分配->已解决->解决/已固定->已关闭3.68%已解决->已修复->重新开放->已解决->解决/已修复->关闭1.32%已分配->新->已解决->解决/无效->已关闭0.67%项目：Koha已解决->已解决/已修复->已关闭4.14%补丁-发送->已解决->解决/已修复->关闭1.64%已分配->补丁-已发送->已解决->解决/已修复->关闭1.42%需要SignO验证->QA失败0.37%已分配->已解决->解决/已固定->已关闭0.32%机构在很大程度上遵循官方文档和项目页面中描述的错误解决过程。这回答了我们上面提出的研究问题RQ1。OTRS社区在65%以上的时间内尊重流程，KOHA社区在90%以上的时间内尊重流程。在这两个项目中，似乎有几种情况下这不是规则。该观察结果肯定地回答了研究问题RQ2，表3中提供了最显著的工艺变化。对于OTRS系统，没有关于bug解决的额外文档，但挖掘过程确实遵循Bugzilla指南。但是，也有过程变化，这些变化取决于错误状态。从过程挖掘分析来看，OTRS社区似乎不喜欢UNCONFIRMED状态，这表明开发人员可能更喜欢继续分配错误以更快地解决问题，并且/或者每个项目的指定开发人员在很短的时间内识别，归档和解决错误。Bugzilla建议OTRS遵循状态和解析字段的命名约定，而Koha的情况并非如此。从Koha事件日志中得到的过程模型表明，所使用的名称/标签中存在许多与Bugzilla建议的名称/标签不同的名称/标签。然而，在更仔细地查看流程模型之后，这两组标签之间的联系是显而易见的。Bugzilla的RESOLVED状态对应于Koha的NEEDS SIGNOFF，Bugzilla的VERIFIED状态对应于Koha的SIGNED OFF。Koha是一个非常活跃的项目，拥有数百名社区成员，社区内部遵循的流程不断发展，以更好地满足最终产品的需求。在这种情况下，引入了更多的步骤和标签作为过程的一部分，以确保在整个bug生命周期中的质量保证（PassedQA，FailedQA）。因此，更多的步骤和标签将导致生成更多的过程实例，这一点通过Koha事件日志中的过程差异数量与前一阶段相比E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001418图5. 为OTRS事件日志中结束于“解决/修复-状态/关闭”的所有错误提取的过程模型。出现OTRS的cess方差。众多的国家和道路， 一个bug可能会随之而来，一个bug可能会影响每个过程变量的频率， 与所研究的OTRS项目相比少得多5.1. 对实践的项目的独特状态和/或使用或不使用QA程序对错误的不同处理，以及使用声明为错误端点的不同状态，表明在开源企业软件开发团队中可以定制开发过程以满足项目的当前需求。这种现象可能会重复的情况下，敏捷或内部源代码开发的专有软件的信息管理。但是，遵循常规的、瀑布式开发范例的企业信息系统管理者，有着更严格的管理程序，可能希望确保不会偏离既定的过程。过程挖掘不仅可以用于缺陷解决过程，而且可以用于整个软件生命周期，以增强对软件开发的评估和监控。关系至关重要，以便将重点放在最常见的流程实例上。与此同时，这并不允许揭示所有异常行为。此外，本研究仅在两种情况下进行，并且仅考虑了一种错误管理工具。流程挖掘是通过使用一种特定的工具Disco来应用的。然而，数据是可用的，对例外情况的进一步分析对于发现解决错误的过程差异非常重要。5此外，本研究对于商业企业信息系统开发的复制和比较所提取的模型具有重要意义。由于当今信息系统中存在大量可用数据，因此可以通过应用流程挖掘技术来改进信息管理活动。事件日志捕获精确的后续过程实例，允许使用信息技术的企业控制整个软件开发过程中执行的操作。此外，流程挖掘一致性将使开发团队负责，确保所有保障措施和安全措施始终保持内部软件开发程序和外包开发。特别是对于本研究中存在一些预期的效度线索因为有几个过程实例还没有被调查。限制事件日志的大小并删除最频繁的活动，5 bit.ly/3tPXNLL-包含从Koha和OTRS提取的事件日志的共享文件夹。E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）1001419图第六章为Koha事件日志中结束于“解决/修复”的所有错误提取的过程模型。在外包过程中，企业信息管理人员可以要求以过程图或任何其他过程表示形式的书面证据，以证明所承诺的软件开发过程得到了遵循。5.2. 文学贡献这项研究有助于理解开源项目中采用的软件过程，并强调了E.库扎里湖我和索提里亚迪斯。斯塔梅洛斯International Journal of Information Management Data Insights 3（2023）10014110过程挖掘在企业信息系统开发中帮助标准化和改进组织的内部过程，并作为外部合作者为组织开发软件的合规性证明。第3节中介绍的方法可以复制到一组扩展的企业信息系统中，研究人员可以应用不同的过滤组合，以确保 调查结果的有效性。虽然这些发现可以用来指导未来的研究，但这项研究并不意味着一个普遍的结果适用于所有的企业系统开发项目。因此，有必要在更多的项目中进行类似的研究，以便得出更一般的结论。总体而言，企业信息系统开发中的过程挖掘有望引起实践者和学术界的必要关注。6. 结论本文研究了企业信息系统开发中的过程约束。 分析了从两个开源企业系统的缺陷库中提取的过程模型。提取的模型基于项目文档进行评估，并与Bugzilla团队建议使用的bug关闭过程相一致。这两个项目都遵循其文档中描述的程序，并且也符合Bugzilla指南。然而，存在几种变化。简要总结了应用过程挖掘技术进行信息系统开发管理的潜在效益。过程挖掘不仅可以突出企业信息系统开发团队遵循的现有过程中的问题，而且还可以使用OTRS和Koha等成熟项目作为基准以揭示可以在其他项目中进一步改进的流程方面。尽管在此类项目中预期会出现与预期过程的偏差，但调查此类偏差对软件质量和健壮性的影响非常重要。流程挖掘技术现在已经足够成熟，可以用于信息管理系统。特别是一致性检查方面，可以用来促进软件开发的监控。因此，过程挖掘技术可以潜在地指导在组织内建立有效的软件开发过程的战略目标竞争利益作者声明，他们没有已知的竞争性经济利益或个人关系，可能会影响本文报告的工作引用Rojas，E.，Munoz-Gama，J.，塞普尔韦达，M.，Capurro，D.（2016年）。医疗保健中的过程挖掘Journal of Biomedical Informatics，61，224帕丁顿，A.，Wynn，M. T.，Suriadi，S.，Ouyang，C.，&Karnon，J.（2015）.临床过 程 的 过 程 挖 掘 ： 对 四 家 澳 大 利 亚 医 院 的 比 较 分 析 ACM Transactions onManagement Information Systems，5（4），1Delias ， P. ， Doumpos ， M. ， Manolitzas ， P. ， Grigoroudis ， E. ， &Matsatsinis ， N.（2013年）。用稳健的方法划分医疗保健流程。在第26届欧洲运筹学会议（2015年11月）（pp. 1-6）。De Weerdt，J.，Schupp，A.，Vanderlook，A.， &贝森斯湾 （2013年）。 用于业务流 程 多 方 面 分 析 的 流 程 挖 掘 -- 一 个 金 融 服 务 组 织 的 案 例 研 究 。 Computers inIndustry，64（1），57弗吉尼亚州鲁宾，Mitsyuk，A.一、洛马佐瓦岛一、&van der Aalst，W. M. （2014年）。 过程挖掘也可以应用于软件！第八届ACM/IEEE经验软件工程与测量国际研讨会论文集（第57页）。ACM。Mahendrawathi， E. R.， 阿萨德， N.， 阿斯图蒂， H. M.， 库苏马瓦德尼， R.P.， &乌塔米河 A. （2018年）。