在软件系统环境中控制软件维护处理的方法和计算机系统

技术领域

本发明分别涉及在软件系统环境(software system landscape)中控制软件维护处理的方法和计算机系统。

背景技术

复杂的软件如申请人的SAP R/3 4.5版(SAP)需要定制(即选择预先确定的功能)和修改(即功能的添加或修正)，以及其它维护如程序和数据更新，参照2004年由A.Schneider-Neureither(Ed.)著作、SAP出版社出版的ISBN为1-59229-026-4的“SAP System Landscape Optimization”以及2004年德国波恩第四次再版的由Metzger和Rhrs著作、Galileo出版股份有限公司出版的ISBN为3-934358-42-X的“SAP R/3 nderungs-und Transportmanagement”。

为了避免由于所述维护而中断正运行软件的生产系统，这种复杂的软件可以以单独的逻辑系统的形式进行实施，这些单独的逻辑系统合起来形成系统环境。参照图1，上述SAP软件的典型实施例例如可以包括用于定制和开发工作的开发系统101，用于使用代表性的测试数据测试功能性的质量保证系统102，用于培训新用户的培训系统103，以及几个生产系统104，例如每个生产系统用于不同的工厂以用于实际的生产使用。可以根据具体要求定义其它或附加的用户和系统。

逻辑系统大部分是相同的、功能自主地并且可以运行在单个计算机上。例如，因为质量保证系统102提供所有的功能、它的当前数据以及另外的特殊测试数据，所以它类似于生产系统104。因此，可以在质量保证系统102中彻底地测试新的定制设置或修改，而不危害生产系统104。同样地，由于培训系统103提供某些功能和特殊测试数据，所以它也类似于生产系统104。因此，虽然无需干扰生产系统104，但是使用培训系统103的新用户可以习惯于所述功能以及观察他的操作效果。

通常，软件维护首先在像开发系统101和质量保证系统102之类的系统即非生产的系统中实现。一旦维护被认可，它们就可以被传输到生产系统104。系统环境100中的系统101、…、104之间的软件维护的这种传输使用传输管理系统来实施。所述传输管理系统逻辑上与逻辑系统101、…、104进行连接并且经过逻辑传播路径105来传输所述软件维护。维护例如可以在开发系统101中被许可以用于输出。然后把它转发到质量保证系统102的输入缓冲器中。操作员手动地许可到质量保证系统102的输入。一旦所述维护被输入到质量保证系统102，就可以把它转发到培训系统103和生产系统104的输入缓冲器中，其中它将随着操作员的手动许可被输入。

这种系统环境的维护是一项复杂的任务。它需要产生用于软件维护的传输请求，并且由经授权的各个系统的操作员批准输入传输请求到各自的系统。这就需要分析系统环境的布局，每个维护所通过的系统环境路径，在每个系统中定义各自的系统的可变性选项的项目状态转换，在每个维护中定义维护属性的属性等等。基于这些分析执行维护及其它任务的输入。

另外，必须考虑用于维护的时间帧。典型地，当维护变得可用时，它们不是被单独地传输到生产系统，而是在预定的时期内连同其它维护一起被绑定地传输到生产系统。然而，传输给非生产系统的系统，例如测试系统，可以在预定的时期以外实施。此外，为了确保在软件故障的情况下保证连续的功能性，紧急修复(hot fix)之类的某些维护需要立即进行传输。

因此，操作员通过大量分离的软件组件帮助进行维护，所述软件组件在中央控制系统中执行，或者在彼此连接以用于数据传输的不同的控制系统中执行。

SMI项目，即SAP的实施方案管理器(Solution Manager forImplementation)(SMI)的电子文件，定义了维护系统环境所需要的部分。例如，在2004年Galileo出版社出版的、由Gerhard Oswald著作的ISBN为3898425746的“SAP Service and Support”中给出的SAP的SMI的描述。在这部分中，传输请求实际采取的路径由系统环境的可用传播路径来确定，考虑到例如传输请求的属性如维护类型、目标系统和项目数据、以及例如每个系统中的状态转换如项目基础上的可变性选项等等。

调度管理器(Schedule Manager)，例如在“Barbara Doerr：Fast Close-Geschwindigkeit und Transparenz im Abschluss，in Karlheinz Küting，NobertPfitzer，Claus-Peter Weber(Hrsg.)：Herausforderungen und Chancen durchweltweite Rechnungslegungsstandards-Kapitalmarktorientierte Rechnungslegungund integrierte Unternehmenssteuerung，Schffer-Poeschel，Stuttgart，2004，ISBN 3791023446”中所描述的，定义了任务列表，在中央系统中执行所述任务列表以在所实施的系统中控制软件维护处理。所述任务列表包括诸如产生、许可以及输入传输请求之类的任务。操作员手动地实施任务列表的任务。

例如在www.itil.org或在2004年由Gerhard Oswald著作、Galileo出版社出版的ISBN为3898425746的“SAP Service und Support”中描述的，可以提供维护台(Service Desk)以产生更改请求，例如请求像紧急修复之类的紧急纠正、请求常规纠正、请求开发工作等等。然后，更改请求在软件系统中是电子可用的。存在一个许可步骤，其中更改管理器或顾问委员会(advisoryboard)决定是否应该实施或者不实施所述更改。基于被许可的更改请求，可以由开发者以及IT维护工程师执行调度管理器的任务。特别地，对于这些用户角色由维护台提供工作流程收件箱以及用户接口。

项目管理系统(Project Management System)如SAP的cProjects，例如在2004年由SAP出版社出版的、由Gerd Hartmann、Ulrich Schmidt著作的ISBN为3-89842-372-7的“mySAP Product Lifecycle Management”中描述的，可以提供用于寄存关于规划的软件维护的数据以及关于软件维护处理状态的数据。基于这些数据，可以产生用于企业管理控制的过程组织、处理流程、处理概述、帐单数据等等。

像SMI、调度管理器、维护台、项目管理系统等等的每一软件组件都依赖于另一个组件的数据，以及更进一步的数据处理，或相反更改至少一个其他组件所依赖的数据。例如，响应于维护台中产生的传输请求，调度管理器为该请求产生任务列表。这个任务列表取决于传输请求的细节以及关于SMI项目的细节。项目管理系统依赖于调度管理器的任务列表。每当完成了任务列表中的一个任务，例如当传输请求输入到具体的软件系统中时，必须更新所述任务列表并且必须通知项目管理系统。此外，不同任务列表的任务之间可能存在依赖性，例如，软件维护是否必须以特定顺序执行。如果执行了紧急软件维护，那么任务以及任务列表将发生更改。

因此，存在大量使用软件组件的操作员所必须考虑的依赖性。

鉴于SAP R/3实施可以包括许多系统并且在状态更改期间每月需要数以千计的维护这一事实，因为存在发生错误的风险，所以，操作员用于分析和考虑依赖性所需的时间变得相当长。

发明内容

因此，根据权利要求1和9的前序部分，本发明待解决的一个目标就是分别提供一种用于在软件系统环境中控制软件维护处理的方法以及计算机系统，其减少了软件维护的复杂性和操作员犯错误的风险。

这个目标是通过权利要求1和9的特征得到解决的。

因此，提供一种用于在具有多个逻辑系统的软件系统环境中控制软件维护处理的方法和一种计算机系统，而状态控制器协调软件维护组件并且基于软件维护处理的状态和基于包括所允许和/或禁止的操作的状态定义来允许和拒绝操作。因此，状态控制器提供了一种用于辅助软件维护处理的软件组件的集中协调，以便大大减少软件维护的复杂性。操作员发生失误的风险也大大降低，这是因为在这个阶段状态控制器阻止了一些操作，其中这些操作可能干扰维护处理的顺序执行。

本发明的更进一步的实施例可以从以下描述以及权利要求中加以推断。

附图说明

图1示出现有技术的系统环境。

图2示出计算机系统。

图3示出软件维护周期。

图4示出软件维护周期的状态。