CN1547700A - 分发软件所用的集成管理系统和方法 - Google Patents

Abstract

一种软件提交过程包括以下子过程：配置管理和版本控制、改变和问题管理、连编、打包以及分发和安装。该过程由一个集成管理系统实施，它包括一个配置管理子系统、一个改变和问题管理子系统、一个连编子系统、一个打包子系统、一个分发子系统以及一个跟踪子系统。这些子系统经过了整合，以便在软件的整个生命周期中进行管理，从开发直至安装在生产中。跟踪子系统沿着该过程的所有步骤，从其它子系统对提交状态有关的信息进行获取和汇总。

Description

分发软件所用的集成管理系统和方法

技术领域

一般说来，本发明涉及软件提交领域，尤其是涉及一种集成的系统和一种方法，全面管理一种从头到尾的软件提交过程，它适于沿着一种软件产品的整个生命周期进行管理，从开发直至安装在生产中。

背景技术

目前大多数公司的商务过程都在很大程度上由一大批软件应用程序进行支持。

由于商务过程需要不断地发展以适应新的商务需求，所以支持公司商务过程所用的软件系统和应用程序，其组件必须频繁地改变，必须动态地发展，以便满足新的需求。

在这种变化的、动态的环境中，不仅是在软件应用程序的开发领域中，而且也在任何公司的许多不同的领域、活动和商务过程中，软件提交过程都起到了一种关键的作用。

结果，软件提交管理已经发展成企业系统管理之内的一门软件工程学科，它专注于控制软件的发展以及实施软件系统的改变。

软件提交管理的主要目的，是使新的软件应用程序能够在不同的环境(比如测试、培训、生产环境)中正确地安装，以及能够控制对已经安装的软件应用程序进行的改变和调整。实际上，软件提交使得以下行为能够实现：部署(即安装和运行)新释放的或新版本的软件应用程序，分发和安装若干调整和补丁以便消除现有应用程序中遇到的错误和问题，以及从一个管理中心来改变软件系统的配置。软件提交也使得在系统崩溃后，无须抵达现场而能够再次安装和再次配置系统。

在实践中，软件提交的任务复杂、细致而且耗时，其范围能够从分发单一的文件直至更换整个软件系统。

安装过程中出错或者与已经安装的软件不兼容的可能性，与软件系统进行改变的程度成正比。由于软件提交允许同时对众多的系统进行改变，确保这些改变不会对这些系统产生负面的冲击极为重要；否则，它们可能会导致大量的用户中断，甚至商业损失。

一般说来，软件提交的过程包括几种行为。这些行为包括例如识别将要提交之软件产品的多种组件(如源代码模块、二进制和可执行文件、配置文件、界面、数据模型、数据结构、实体、过程比如安装和配置脚本、文档比如用户指南等等)，管理软件产品中不同释放或版本的组件；对于要向其提交软件产品的软件系统，识别其组成要素之间的依赖关系；产生在目标系统中即目标环境和平台中运行软件产品所需的数据项；创建软件包，其中包含着在目标平台中安装软件产品所需的文件、数据、脚本和实用程序；向目标系统分发软件包；以及在目标系统中安装所分发的软件包。

对于以上概述的完整提交过程，为了实施其特定的部分或者说子过程，已经提出了几种不同的方法。本文在下面会报告已知方法的某些实例。

Davis等人的、标题为“Automatic software installation onheterogeneous networked client computer systems”的5,742,829号美国专利提供了一种方法，用于在多机种的客户计算机系统中自动安装软件。

Collins三世等人的、标题为“System for software distribution ina digital computer network”的5,845,090号美国专利公开了在一个网络中分发软件和数据的一个过程，把软件和数据结合起来(程序和数据在一起通称方法)，放入称为数据包的若干单一实体中，然后使用特定的技术，把数据包从一台计算机传送到另一台计算机。这份文档中公开的过程涵盖的子过程用于传输分发数据包(安装程序和数据)、采集数据包(采集数据所用的方法)以及命令数据包(系统管理任务所用的方法)。

Glowny的、标题为“System and method for remote softwareconfiguration and distribution”的5,805,897号美国专利涉及一种系统和方法，用于远程软件安装和维护。

Neal的、标题为“Method for distributing software over networklinks via electronic mail”的6,192,518号美国专利公开了一种方法、装置和制成品，用于通过一个网络由电子邮件来分发一个软件应用程序。

Holmes的、标题为“Reliable and repeatable process forspecifying，developing，distributing and monitoring a software systemin a dynamic environment”的6,226,784号美国专利介绍了一种通用的过程，用于项目管理。该过程局限于仅仅在实验室环境中在软件的开发期间管理软件的生命周期。

以上提名的美国专利，其全部内容在此引用作为参考。

作为现有技术中已经介绍之若干系统和方法的另一个实例，1999年9月IBM公司国际技术支持机构印发的、标题为“TheSoftware Distribution Process”的出版物SG24.5504.00，介绍了软件分发和安装的若干子过程。每一个步骤都进行了详细介绍，讲解了如何以及何时实施。不过，软件提交过程作为一个整体涉及的任何其它子过程均未涵盖。

大多数已知的方法都局限于仅仅涵盖了完整软件提交过程中具体的子过程，比如分发子过程和/或无人值守安装子过程。其它的已知方法局限于涵盖软件项目管理的特定需求，而且不能应用于在商业环境中，沿着软件产品从开发直至生产的整个生命周期实施软件提交过程。

作为现有技术中系统和方法的实际实施结果，大多数公司的信息技术(IT)机构已经安装了多种单独的、多机种的、隔离的子系统，以便实施整个软件提交过程中的特定子过程。例如，一个特定的配置管理系统(或应用程序)可能用于控制代码的不同版本，一个与它无关的系统(或应用程序)用于管理改变，另一个系统用于跟踪软件产品中的问题及其解决结果，再一个单独的工具向不同的环境分发软件产品。

由于缺乏从头到尾的软件提交过程，或者利用隔离的、独立的系统来实施该过程，频繁地造成了产生低质量的软件产品、推迟提交计划、成本超支或者不能满足客户的需求。

本申请人已经看到，当前的方法本质上不能包含软件应用程序不同组件的变化、它们之间的依赖关系、运行它们的多种平台、它们的多种版本以及它们在不同的环境(比如开发、连编、单元测试、功能测试、集成测试、回归测试、系统测试和生产)中的发展。因此，需要有一种从头到尾的软件提交过程，它能够沿着软件系统的整个生命周期进行管理，从开发直至安装在生产中。

为了成功地满足这种需求，构成从头到尾的完整软件提交过程的多种行为，既不应当相互独立，也不应当相互隔离。相反，它们如果不是全部都应当相互联系，大多数也应当相互联系。同样，从头到尾的软件提交过程应当覆盖一种新软件产品(如一种新的应用程序)的完整生命周期，把它作为一个整体来管理，在整个过程中从头到尾都要保持其完整性。另外，软件提交过程必须考虑到，组成软件产品的若干部分虽然不同，但是相互有联系，而且它们也与同一系统或其它目标系统上运行的其它组件和软件产品有关。

因此，还是需要有一个涵盖以上给出的全部需求的全局解决方案，还是需要有一种基于集成管理系统的从头到尾的软件提交过程，它覆盖着一个软件产品的整个生命周期，把它作为一个整体来管理并且保持其完整性，同时考虑到软件产品是由不同的相互联系的部分组成的。

发明内容

本发明致力于解决上述问题。

确切地说，本发明的一个目的是改善当前软件产品提交所用的系统和方法，覆盖应当满足的主要需求。

按照本发明的第一方面，提出了一种集成的数据处理系统，用于管理在一个网络环境中把软件产品提交到目标软件产品执行单元的提交过程，而目标单元可以属于该网络环境之内的一个软件产品测试环境、一个软件产品用户培训环境或者一个生产环境。集成的数据处理系统包括：一个中心储存库，用于存放至少一种软件产品的软件组件；一个第一子系统，用于在中心储存库之内识别将要提交之软件产品的软件组件；一个第二子系统，用于根据第一子系统识别的软件组件，创建至少一个软件产品数据包；以及一个第三子系统，用于向目标软件产品执行单元分发第二子系统创建的至少一个软件产品数据包。

对于第二子系统分配给这至少一个软件产品数据包的角色，按照其标志确定要向其分发软件产品数据包的执行目标单元。

在一个优选实施例中，集成的数据处理系统包括一个软件包分发储存库，用于存放第二子系统根据已识别的软件组件创建的至少一个软件产品数据包，它将要由第三子系统分发。

第一子系统也管理着中心储存库中的一个存储器，其中存放着要提交之软件产品的软件组件。

优选情况下，集成的数据处理系统进一步包括一个第四子系统，用于在要提交之软件产品的已识别软件组件之间，执行软件代码组件的一个连编过程。第四子系统在中心储存库中存放着连编过程的结果。

在一个优选实施例中，集成的数据处理系统进一步包括一个第五子系统和一个第六子系统，前者用于管理对已经提交的软件产品施加改变和/或调整的一个过程，后者用于记录在软件产品的提交期间，集成数据处理系统的其它子系统提供的信息。

本发明的另一个方面是一种方法，用于在一个网络环境中把软件产品提交到目标软件产品执行单元。该方法包括以下步骤：

在中心储存库中存放这至少一种软件产品的软件组件；

在中心储存库中存放的软件组件中，识别要提交之软件产品的软件组件；

根据已识别的软件组件，创建至少一个可分发的软件产品数据包；

向目标软件产品执行单元发软件产品数据包，并在该处安装软件产品数据包。

附图简要说明

参考附图，通过本发明一个优选实施例(仅仅是作为非限制性的实例而提供)的以下详细说明，本发明的特性和优点将会显而易见，其中：

图1是一个普通公司信息基础设施的简图；

图2是一幅框图，展示了依据本发明一个优选实施例的软件提交集成管理系统；

图3是一幅流程图，示意性地显示了依据本发明一个优选实施例的一种方法中的主要步骤，用于利用图2的集成管理系统实施从头到尾的提交过程；

图4示意性地显示了集成管理系统实施之软件提交过程的若干子过程与图2中集成管理系统的跟踪子系统之间的信息交换。

具体实施方式

本发明提供了一种集成管理系统和一种方法，用于在具有信息基础设施的一个普通公司之内，实施一种完整的、从头到尾的软件提交过程。

图1中示意性地展示了一个普通公司的信息基础设施。该基础设施由引用号101整体标识，包括不同性质的多个平台103，比如个人计算机、工作站、服务器等，利用一个网络105联网，例如一个局域网(LAN)、一个广域网(WAN)或其组合，或者任何其它种类的网络。平台103可以属于许多不同的环境，比如测试软件产品的测试环境TEST，培训软件产品的预期终端用户使用软件产品的培训环境TRAIN，软件产品以其在公司的日常商务管理中预期使用而运行的生产环境PROD。

该公司也具有一个信息技术(IT)机构IT_ORG，它具有管理公司的信息基础设施的功能。该IT机构通常包括几个团队，比如一个软件产品开发团队DEV，负责开发新的软件产品，或者已有软件产品的新释放或新版本；一个软件产品连编团队BUILD，负责从软件代码开始的连编过程，连编在一种目标环境中运行一个软件产品所需的所有数据项；一个软件包创建团队PACK，负责创建软件包，它们要分发到指定环境中的目标平台103；以及一个软件包分发团队DISTR，负责把软件产品分发和安装到指定环境中的指定目标平台上。多种团队的成员在平台107上操作，它与集成服务器109联网，再连接到公司网络105。

依据本发明，一个恰当的和完整的从头到尾的软件提交过程可能包括以下子过程：配置管理和版本控制、改变和问题管理、连编、打包、分发和安装。

配置管理和版本控制子过程使得软件产品的组件能够识别，比如源代码模块、二进制和可执行文件、配置文件、界面、数据模型、数据结构、实体、过程(安装和配置脚本)以及文档。这个子过程也在开发生命周期中管理着软件产品组件的不同释放和版本，并且对它们的发展保持跟踪。对于可能要向其提交软件产品之目标软件系统的要素(比如平台、操作系统、中间件、网络因素等)，这个子过程也使得它们之间可能的依赖性能够标识，而且能够把所有这些要素集中起来，把它们作为一个整体来管理。因此，这个子过程在任何时间都能够确定一个目标软件系统在特定环境和阶段中的状态。

改变和问题管理子过程使得为了增强代码而实施的改变和为了解决遇到的问题而开发的调整能够受到控制。由于开发团队为了实施一种改变或者改正一个错误而产生或修改的软件组件应当受到标识和控制，所以这个子过程的操作可以与配置管理和版本控制子过程完全整合。

连编子过程产生在特定目标系统中(如在特定的目标环境和平台中)运行软件产品所需的数据项。这个子过程的成功实施需要配置管理和版本控制子过程的正确实施。为了达到这个目的，连编子过程应当知晓什么需要改变，在何处找到在连编过程中要使用的要素，以及应当切换到什么过程以便成功地生产新版本的软件产品。

打包子过程以可安装的格式产生软件包，包含着所需的文件、数据、脚本以及支持安装子过程需要的实用程序。为了确保安装子过程正确无误，需要(尽管不是强求)安装是无人值守的(即无须终端用户的干预)。为了达到这个目的，产生的软件包也应当包含必要的响应文件，上面可以正确地记录着安装子过程期间请求的参数值、选项或可能的回答。

分发子过程使打包子过程中产生的软件包可立即安装到目标系统。

最后，安装子过程把分发的软件包安装在目标系统中，即在对应的环境(如测试、生产、培训等)中的指定目标平台上。这个子过程也创建若干日志文件，记载着软件包的安装结果中施加在目标系统上的改变。安装子过程也可以告知分发管理团队一个成功的和正确的安装已经完成，如果安装失败就触发一个动作。

依据本发明一个优选实施例的集成管理系统包括多个不同的子系统，实施不同的子过程，它们组成了软件提交过程。

确切地说，依据本发明一个优选实施例的集成管理系统包括一个配置管理子系统，实施配置管理和版本控制子过程；一个改变和问题管理子系统，实施改变和问题管理子过程；一个连编子系统，实施连编子过程，一个打包子系统，实施打包子过程，以及一个分发子系统，实施分发和安装子过程。

每个子系统执行软件提交过程中的一个或多个特定的子过程。这些子系统不是相互隔离的，而是相互整合及关联的，以便沿着一种软件产品的整个生命周期进行管理，从开发直至安装在生产中。

此外，依据本发明一个优选实施例的集成管理系统还包括一个跟踪子系统，与其它子系统整合及互动。沿着软件提交过程的不同阶段，跟踪子系统从其它子系统获取和汇总软件提交状态有关的信息。跟踪子系统可以记录该过程的若干阶段以及在这些阶段之内探测到的结果。同时，对于IT机构之内不同团队的成员，跟踪子系统也按照他们在这样一种机构之内的角色和责任，使他们保持知晓软件提交过程。

图2是一幅示意框图，展示了依据本发明一个优选实施例的从头到尾的软件提交集成管理系统。该集成管理系统由引用号201整体标识，构成它的子系统示意性地表示为功能区块。确切地说，配置管理子系统由区块203(CMss)标识，连编子系统由区块205(Bss)标识，打包子系统由区块207(Pss)标识，分发子系统由区块209(Dss)标识，改变和问题管理子系统由区块211(C&PMss)标识。此外，跟踪子系统由区块213(Tss)标识。

由公司IT机构的开发团队DEV交互操作的配置管理子系统203，具有一个相关联的安全中心储存库(CR)215，而且与连编子系统205、打包子系统207以及改变和问题管理子系统211互动。打包子系统207又与分发子系统209互动。在本发明的一个优选实施例中，分发子系统209具有一个相关联的软件分发储存库(DR)217。打包子系统207能够访问软件分发储存库217。

为了随后的安装，分发子系统209能够把软件产品分发到指定环境的指定目标平台103，例如生产环境PROD和测试环境TEST。

改变和问题管理子系统211从已经安装了软件产品的不同环境的目标平台接收反馈。

在对已安装软件产品的的问题进行改变或调整阶段，IT机构的开发团队DEV对改变和问题管理子系统211进行交互操作。改变和问题管理子系统通知开发团队，一种已安装的软件产品需要一种改变或者一种调整。

配置管理子系统203、连编子系统205、打包子系统207、分发子系统209以及改变和问题管理子系统211都可以与跟踪子系统213互动。

在图2中，子系统、储存库、目标环境与开发团队之间的功能互动，示意性地表示为简单的线条。

按照一个项目的需求，为了实施和相互整合上述子系统，以形成集成的管理系统，可以使用现有的软件产品和工具，也可以使用为此目的而专门开发的其它软件组件。

现在将更详细地介绍不同子系统的特定功能。

一般说来，配置管理子系统203实施软件提交过程中的配置管理和版本控制子过程。确切地说，这个子系统执行识别、组织和控制一个软件产品的若干组件的任务，比如源代码模块、连编脚本(即make程序的描述文件)、二进制和可执行文件、界面、数据模型、数据结构、实体、配置文件、安装脚本和响应文件、配置脚本以及文档编制组件，例如提交信息、连编指南、操作指南和用户指南。

例如，软件产品的以上组件可以由开发团队开发，或者从一个软件卖方购买，并且可以由开发团队向配置管理子系统203提供。

配置管理子系统203把软件组件存放在相关联的安全中心储存库215中。

此外，配置管理子系统203在软件组件的整个开发生命周期中，控制和管理着软件组件的版本，并且对它们的发展保持跟踪，能够随时确定一种特定环境中代码的状态或版本。

不仅如此，对于构成软件产品的软件组件，配置管理子系统203还能够记录它们之间的依赖关系，而且能够把它们集中起来，所以可以把它们作为一个整体来管理。

因此，配置管理子系统203不仅确保了软件产品的完整性，而且确保了整个系统的完整性。所有这些功能降低了复杂程度，而且节省了实施时间，改善了软件生产过程的质量和生产率，简化了过去软件版本的可重用性。

改变和问题管理子系统211实施软件提交过程的改变和问题管理子过程。确切地说，这个子系统执行以下功能：

对软件产品的改变方案和改正错误的解决方案进行控制；

支持改变和问题管理子过程的若干步骤，这些步骤包括例如探测在测试、培训或生产的任一种环境中已经安装之软件产品中的问题，批准一种改变，证实输出，实施改变或纠正错误等；

对改变和问题保持跟踪，确保改变和问题管理子过程成功地实现以及改变经过适当授权；

评估改变和问题的冲击，因此能够作出判断、节省成本、精力和时间；

根据子系统之内记录和管理的类似错误，促进问题确定过程；

识别哪些代码要素是应用程序问题的根源，或者说哪些代码要素必须修改以实施改变；以及

连编已经作出之改变和调整与在软件产品的新版本中解决之问题的联系，使得它们在多种版本和环境中脱离特定的软件要素。

为了完成一种正确的问题和改变管理，需要一种稳健的和适当的配置管理，也需要一种有效的版本控制。为了达到这个目的，改变和问题管理子系统211可以与配置管理子系统203全面整合。全面整合意味着终端用户能够确定中心储存库215中要改变之软件组件的版本和释放以及其它特征。配置管理子系统203与改变和问题管理子系统211可以视为一个单一的子系统，实施配置、版本控制以及改变和问题管理的功能。

连编子系统205实施软件提交过程的连编子过程。确切地说，这个子系统具有以下功能：确保中心储存库215中存放的源代码正确地连编，以及产生在目标系统中运行软件产品所需的二进制文件。这个子系统也能够识别产生二进制文件所用之源代码的版本。

更详细地说，在配置管理子系统203的控制下，连编子系统205自动地从中心储存库215中提取所需的源代码组件，并且连编脚本和任何其它要素，以用于连编软件产品。然后，这个子系统把这些组件传递到适当的连编系统。根据源代码的类型，连编子系统205启动适当的连编脚本、连编系统和目标执行平台和环境，以获得软件的对应版本。

随后，子系统205自动地把已经产生的二进制文件存放在中心储存库215中，以便对产生它们的源代码保持跟踪。

如果软件系统不是由IT机构自行开发，而是从一个软件卖方购买的，在大多数情况下二进制文件是专门提交的，而不是要产生的。在这种情况下，就不必执行连编子过程。公司IT机构的开发团队把软件卖方提供的二进制文件供应给配置管理子系统，它把它们与软件产品的其它组件一起，存放在中心储存库215中。

打包子系统207实施软件提交过程的打包子过程，并且产生软件产品的数据包，使它们能够向指定环境的目标平台分发和安装。更具体地说，打包子系统207产生压缩的软件包，用于分发。这些软件包包含着软件产品的二进制文件(或者是在连编子过程中产生的，或者是由软件卖方提供的)，以及所需的所有其它文件，比如配置文件、初始化文件、在目标平台上进行无人值守安装所需的响应文件或者终端用户的文档。在配置管理子系统203的控制下，这些文件由打包子系统自动地从中心储存库215中提取，配置管理子系统203在中心储存库215中存放的组件中，识别构成软件产品的组件。软件包的内容取决于应用程序代码和目标执行平台(硬件、操作系统、中间件)的类型，而打包子过程和软件包的格式可以与软件包的内容无关。

然后，根据IT机构的打包团队提供的以及跟踪子系统中记录的信息，打包子系统207为产生的软件包分配一个角色，它必须符合该软件产品最终将要安装的目标系统。例如，一个目标系统角色可以是Windows NT SQL服务器，MQ Series客户，SAP NT服务器，等等。

优选情况下，打包子系统207把产生的软件包存放在软件分发子系统209的软件分发储存库217中。多亏如此，使用跟踪子系统213提供的信息，在每个平台上软件产品的每一个组件都很容易识别，因此就能够从软件分发储存库217中，获得包含着这些组件中每一个之正确版本的对应可安装软件包。此外，由于软件包存放在软件分发子系统209的软件分发储存库217中，软件应用程序的每个版本可以仅仅连编和打包一次，随后再修改，也能够确保最终的安装是相同的，与目标环境(比如单元测试环境、功能测试环境、集成测试环境、回归测试环境、系统测试环境或生产)无关。

软件分发子系统209实施软件提交过程的分发和安装子过程，并且在指定环境的正确目标平台上执行软件包的分发和安装。可以存放在软件分发储存库217中的将要分发的软件包，包含着软件产品的二进制文件及所需的任何其它文件，比如配置文件、初始化文件和无人值守安装所需的响应文件，所以，一旦软件包的安装已经初始化之后，或者由集成管理系统请求，或者由一个目标平台强制，不需要用户干预，因此确保了安装过程的正确性。

软件包的分发和安装可以按照任何一种常规的分发方式来进行，比如直接存取分发、流式分发、改道分发、级联分发、网络服务器出版分发或者通过电子邮件发送来分发。所有这些方式，虽然相互有别，但是都使用或者是一种“拉”分发技术，或者是一种“推”分发技术，或者兼而有之(“推-拉”分发方式)。在拉分发技术中，软件包的分发是由试图在一个目标平台上安装软件包的终端用户触发的。在推分发技术中，分发是由软件分发子系统209启动的，它强制软件包从软件分发储存库217下传至目标平台。在推-拉分发技术中，软件包的分发是由推拉技术的一种组合来进行的。取决于不同的情况，这些技术中的任何一种都可以实施和应用。

如果按照项目的指示，软件包的安装已经授权，跟踪子系统213就可以通知测试团队、终端用户或者所涉及的任何专业人员。

分发子系统209按照打包子系统207为其分配的角色，分发软件包。

严格说来，跟踪子系统213无须实施软件提交过程的任何特定子过程。更确切地说，在一个普通软件产品沿着其整个生命周期的提交过程中，这个子系统对于其它子系统收集的提交过程状态有关的信息进行汇编。跟踪子系统213可以连编已执行的每一个过程步骤、每一个细节以及集成管理系统探测到的每一个事件。例如，作为一种信息工具，这个子系统提供了不同的软件产品提交以及软件级别、连编结果、分发或安装结果和提交状态有关的信息。

在本发明的一个优选实施例中，跟踪子系统213包括一个电子邮件(e-mail)工具，当某些指定事件发生时，例如提交的状态有转换时，它就以电子邮件消息的形式，向提交过程中涉及的专业人员自动提交通知。电子邮件消息形式的自动通知使这些团队的成员及时知晓提交的状态；确切地说，这个子系统使负责分发的团队知晓软件包的提交。

以上概述的集成管理系统实现了一种从头到尾的软件提交方式，它包括以下步骤：

在配置管理子系统203的控制下，由IT机构的一个团队(如配置管理团队)加载中心储存库215中源代码的若干片段，在跟踪子系统213中记录软件产品的若干版本，包括相关的细节，比如版本号、平台、语言、开发团队等等；

在配置管理子系统203之内管理源代码，它分配版本号，存放代码，控制伴随的文档，等等；

如果软件卖方未提供，就利用连编子系统205并且在配置管理子系统203的控制下，从中心储存库215中存放的源代码，连编二进制文件；

在配置管理子系统203的控制下，在中心储存库215中加载已产生的二进制文件和软件产品的其它组件，比如配置和安装脚本；

在配置管理子系统203的控制下，从中心储存库215中提取二进制文件、文档和配置和安装脚本，并且利用打包子系统207，产生将要分发的一个软件包；

把产生的软件包发送到分发子系统209，以便把软件包分发到指定目标环境中的指定目标平台；

在分发子系统209的控制下，在指定环境的目标平台上分发和安装软件包；以及

在本过程期间更新跟踪子系统，记录本过程中的步骤和结果。

此外，本方法能够在改变和问题管理子系统211的控制下，管理已经提交之软件产品的软件改变和调整。

现在参考图3，它利用一幅简化的流程图，显示了依据本发明之方法的一个优选实施例，用于利用前面介绍的集成软件提交系统实施从头到尾的提交过程。

现在将要介绍之方法的示范性实施例涉及以下情况：一个新的软件产品完全由公司IT机构的开发团队自行开发。不过，依据本发明的方法适于实施的从头到尾的整个软件提交过程，与软件产品是自行开发还是由软件卖方提供无关。在后一种情况下，就不必执行本方法的某些步骤(涉及连编过程的若干步骤)。

一旦公司IT机构的开发团队决定开发一个新的软件产品，或者为了改正一个错误或作出某些改变而开发已有软件产品的一个新释放或新版本，本方法就开始了。

首先，开发团队在跟踪子系统213中记录已开发软件产品的相关细节(301框)。记录的信息可能包括例如软件产品的名称、释放/版本号、开发团队领导的姓名、目标执行平台的名称、语言代码、产品文档参考资料、已经改正的问题、已经实施的改变，诸如此类。

然后，在配置管理子系统203的控制下，开发团队把连编和运行软件产品所需的软件产品组件加载到中心储存库215中(303框)。这些要素包括例如源代码模块、连编脚本(即make程序的描述文件)、连编文档、界面、数据模型、数据结构、实体、配置脚本或文件、安装脚本以及无人值守安装和文档编制所用的响应文件，比如举例来说提交信息(应用程序、数据、改正的问题、施加的改变等等)、连编指南、管理指南、操作指南和用户指南。

正如305框所表示的，配置管理子系统203控制着中心储存库215中存放的软件产品组件及其版本。为了达到这个目的，开发团队在跟踪子系统213中记录了配置管理子系统203进行控制所用的信息，包括其中包含源代码之储存库组件的名称。

一旦开发阶段完成了，开发团队就使用跟踪子系统，向IT机构中负责提交软件的功能部门报告软件产品的可用性(307框)。

然后，连编团队检验已产生的连编脚本和文档正确无误(309框)。如果在这项检验期间，遇到了已产生的连编脚本和/或文档中的错误，连编团队就把这个事件记录在跟踪子系统213中，它通知开发团队需要改正这些错误。开发团队改正了这些错误之后，要重复前面的步骤，至少对于已经改变的软件组件是如此。

然后就连编软件产品，以便产生使软件产品恰当运行所需的二进制文件。正如311框所表示的，这些二进制文件是在配置管理子系统203的控制下，由连编子系统205从中心储存库215中存放的源代码产生的。

然后连编子系统205就把前一步骤中产生的二进制文件存放在中心储存库215中(313框)。

作为下一个步骤(315框)，连编团队在跟踪子系统213中，记录309框、311框和313框中步骤的执行所涉及的信息或结果(是否可应用)(如完成时成功或失败、相关的结果、缺失所需的文档等等)。跟踪子系统213在需要时会向连编团队的成员发送自动通知，例如以电子邮件消息的形式。

至此，软件应用程序已经连编。打包团队利用打包子系统207，产生对应的可安装软件包(317框)。在配置管理和版本控制子系统203的控制下，打包子系统207从中心储存库215中，提取在一个指定的目标平台上部署(即安装和运行)该软件产品所需的软件组件。这些组件可能包括以下数据项：如二进制和可执行文件、安装脚本(如果需要的话)、无人值守安装所用的响应文件、配置脚本(如果需要的话)、配置文档(如果需要的话)、终端用户文档(即用户指南)、管理和操作文档以及在指定的环境中指定的目标平台上部署该软件产品可能需要的其它软件产品组件。

由于连编子过程期间产生的每一个要素都应当包括在软件包中，所以连编子系统205的输出存放在配置管理子系统203的中心储存库215中，并且供应给打包子系统207作为一个输入。一般说来，每个软件包都应当整装的，但是取决于应用程序和安装需求的特定设计，每个要安装的软件产品也可以有不止一个软件包。

一旦软件包已经产生，它就可以用于分发。所以，产生的软件包即可供应给软件分发子系统209。为了达到这个目的，打包子系统207把软件包存放在分发子系统209的软件分发储存库217中(319框)，使其分发能够进行。

然后，打包团队把317框和319框中步骤有关的信息和结果记录在跟踪子系统213中(321框)。需要时后者向该团队的成员发送和分配自动通知。

分发和安装团队使用分发子系统209，在目标环境的目标平台上分发和安装软件包(323框)。分发和安装团队也把这个步骤有关的信息或结果记录在跟踪子系统213中，需要时它向该团队的成员发送自动通知。优选情况下，按照公司IT机构的策略，在目标环境中安装应用程序软件包可能要受到一个管理团队的批准。

正如325框所表示的，已安装软件产品的增强以及解决应用程序错误所需的调整，是由改变和问题管理子系统211管理，它可以与配置管理子系统203完全整合。软件改变和问题改正应当遵循IT机构规定的手续。与应用程序改变和错误有关的信息，记录在改变和问题管理子系统211中。如果是一项改变，这项改变的申请者执行这项任务，如果是一个错误，由发现它的机构记录这个事件。

对一个已安装的软件产品提交一个代码版本以实施一项改变或改正一个错误，其过程和方法基本上与任何其它提交的项目相同。实际上，一旦一个新代码版本的开发开始了，它就记录在跟踪子系统213中。同样，在配置管理子系统203中一项改变或一个错误的标识符也应当记录为提交信息的一部分。

如果一个软件产品不是由公司IT机构自行开发的，而是由一个软件卖方提供的，那么从卖方收到软件时就开始软件提交过程。负责软件提交过程的人员得到通知，他在跟踪子系统213中记载这次提交。在这种情况下，由于仅仅应当提交可安装格式的二进制文件，在配置管理子系统之内既不应当存放也不应当管理源代码，所以就跳过连编子过程。

图4是一幅示意图，显示了软件提交过程的主要步骤如何提供提交状态有关的信息——在跟踪子系统213中记录的信息。跟踪子系统213作为集成提交过程产生之信息以及跟踪提交状态的中心点。在这些步骤中记录的信息汇总如下。

对于一个软件产品的一个新释放或新版本，或者一个现有的软件产品的一项调整或一项改变，当开发(411框)开始时，开发团队在跟踪子系统213中记录相关的细节，如产品名称、版本号、开发团队标识符、目标执行平台、语言代码、软件产品文档参考资料、配置管理子系统203有关的信息(包含着源代码的中心储存库组件的名称)、改正的问题或实施的改变。如果该软件产品不是自行开发，而是从一个软件卖方购买，如上所述，通常仅仅应当提交二进制文件；即使在这种情况下，供应的软件也应当遵循提交流程，负责软件提交过程的功能部门应当把卖方提交的信息记录在跟踪子系统213中。

当开发阶段结束时，就连编(413框)了应用程序以产生运行它所需的二进制文件。然后，负责连编代码的连编团队(或者开发团队本身，如果IT机构中没有这种责任划分的话)就在跟踪子系统213中，记录该过程的这个步骤有关的信息。要记录之信息的种类实例为：配置管理子系统信息，比如包含着源代码(从它产生对应的二进制文件)的中心储存库215组件的名称、包含着已产生的二进制文件之中心储存库215组件的名称、包含着连编脚本和文档(由开发团队提供)之中心储存库215组件的名称、依赖关系或前提条件(版本间的、代码集版本的等)有关的信息；连编日期和连编结果(如果有的话)。

一旦软件产品已经连编，就由打包子系统207产生(415框)对应的可安装软件包。然后，负责软件打包的打包团队就在跟踪子系统213中，记录这个步骤有关的信息。要记录之信息的种类实例为：配置管理子系统信息，比如包含着能够安装所需脚本和响应文件的软件分发储存库217组件的名称、以及包含着应用程序软件包的软件分发储存库217组件的名称；软件包名称；目标执行平台的角色；打包日期；以及打包结果(如果可应用的话)。

一旦软件包已经产生，它就能够用于分发(417框)。然后，打包团队就在跟踪子系统213中，记录软件包的新状态(软件包已为分发准备就绪)。

当请求分发软件包(可能是批准之后)时，为了分发和安装(419框)，软件包必须按照其角色或功能，分配给正确的目标系统。软件分发子系统209把软件包提交到目标平台，负责分发和安装软件包的分发团队在跟踪子系统中，记录已安装软件包的新状态(已安装状态)。

依据本发明的从头到尾的软件提交集成管理系统和方法，最显著和最优越的特性如下。

一个软件产品的整个生命周期作为一个单一的过程来管理，而不是像现有技术中那样作为一组不相关的、独立的过程来管理。

本发明的集成管理软件系统是一种独特的和全局的管理系统，它支持整个软件提交过程。集成管理系统的子系统相互整合，它们中的每一个都实施软件提交过程中的一个特定子过程。

依据本发明的集成管理系统与特定实施方案中采用的平台、操作系统、储存库或数据库无关。此外，集成管理系统确保了软件系统的完整性及其准确性能，跟踪和控制着不同软件组件和文档之间的依赖关系，因此避免了冗余并且确保了全部组件能够联在一起按照需要而工作。

新的软件产品或者已有软件产品的新释放或版本，比如对已安装之应用程序的调整或修改，在配置管理子系统的控制下，从中心储存库连编。

产生和分发可安装的软件包时，独立于软件包的内容和目标系统，而且能够由一个无人值守过程来安装。

优越之处在于，新的软件版本(完全的或增补的)可以连编和打包一次，并存放在分发子系统的软件分发储存库中，使得在不同环境中能够重复使用安装软件包。

此外，集成管理系统使得无人值守安装时能够自动提取软件包，坚持了正确的软件包按照其角色安装在正确的目标系统中，使得在任何时间对于任何特定环境和阶段都能够检索软件系统的全部状态信息。

不仅如此，集成管理系统确保了在不同的平台上，同一软件的不同版本或级别能够同步，而且在不同环境(即开发、连编、单元测试、集成测试、回归测试、系统测试、生产)中并行运行的并发应用程序之间能够同步，这些环境往往是由专业人员在远程位置拥有和管理的。

本系统也可以允许保持软件状态的审核踪迹。

必须强调，任何商业、公司或IT机构，面对一个管理系统支持的软件提交过程的实施问题时，都可以应用本文介绍的软件提交过程，以及为了实施它而公开的系统和方法。实际上，在本发明中介绍的系统的需求和主要特性是通用的，独立于特定的实施例。

也必须理解，按照一个给定机构或公司的特定需求，可以采用其它的实施例，可以作出结构改变而不脱离本发明的范围，正如附带的权利要求书的规定。

Claims (11)

1.一种集成的数据处理系统，用于管理在一个网络环境中把软件产品提交到目标软件产品执行单元的提交过程，包括：

一个中心储存库，用于存放至少一种软件产品的软件组件；

一个第一子系统，用于在中心储存库之内识别将要提交的软件产品的软件组件；

一个第二子系统，用于根据由第一子系统识别的所识别的软件组件，创建至少一个软件产品包；以及

一个第三子系统，用于向目标软件产品执行单元分发第二子系统创建的至少一个软件产品数据包。

2.根据权利要求1的集成数据处理系统，进一步包括一个软件包分发储存库，用于存放第二子系统根据已识别的软件组件创建的至少一个软件产品数据包。

3.根据权利要求1的集成数据处理系统，其特征在于，第三子系统按照第二子系统分配给这至少一个软件产品数据包的至少一个角色，把这至少一个软件产品数据包分发到目标软件产品执行单元，这些单元属于至少一个环境。

4.根据权利要求1的集成数据处理系统，其特征在于，第一子系统管理着中心储存库中的一个存储器，其中存放着要提交的软件产品的软件组件。

5.根据权利要求1的集成数据处理系统，进一步包括一个第四子系统，用于在要提交的软件产品的所识别软件组件之间，执行软件代码组件的一个连编过程，第四子系统在中心储存库中存放着连编过程的结果。

6.根据权利要求1的集成数据处理系统，进一步包括一个第五子系统，用于管理对已经提交的软件产品施加改变的一个过程。

7.根据权利要求1的集成数据处理系统，进一步包括一个第六子系统，用于记录在软件产品的提交期间，集成数据处理系统的第一至第五子系统中至少一个提供的信息。

8.一种方法，用于在一个网络环境中把软件产品提交到目标软件产品执行单元，包括以下步骤：

在中心储存库中存放至少一种软件产品的软件组件；

在中心储存库中存放的软件组件中，识别要提交的软件产品的软件组件；

创建至少一个软件产品数据包，它包括至少一个已识别的软件组件；

向目标软件产品执行单元分发软件产品数据包，并在该处安装软件产品数据包。

9.根据权利要求8的方法，其特征在于，创建至少一个软件产品数据包的步骤，包括把一种角色标志分配给至少一个软件产品数据包，该角色标志用于标识将要向其分发软件产品的目标软件产品执行单元，以及按照角色标志分发这至少一个软件产品数据包。

10.根据权利要求8的方法，进一步包括在软件分发储存库中存放至少一个软件产品数据包的步骤。

11.根据权利要求10的方法，进一步包括一个步骤：对中心储存库中存储的将要提交的软件产品的已识别源代码组件进行连编，并且把连编结果存放在中心储存库中。

Images