CN101174208A - 一种软件生产线平台的实现方法 - Google Patents

Abstract

本发明提供一种构建基于Test Director、Harvest或Subversion软件生产线平台的方法，该方法是通过梳理软件研发过程中的信息标准、信息流向和信息依赖关系，制定出统一的缺陷、变更和配置管理使用规范(包括流程、表单、字段、角色、权限、规约等)，建立起统一质量度量和统计分析的基础，形成一套产品质量和过程质量度量模型，并提供配套的软件研发协同管理系统进行实现支持，将Test Director、Harvest或Subversion进行服务连通、规则映射和信息同步，以完成研发过程的需求管理、配置管理、变更管理、发布管理、项目管理、缺陷管理的多维度数据采集，形成全生命周期的软件企业资产库。

Description

一种软件生产线平台的实现方法

1、技术领域

本发明涉及计算机应用技术领域，具体地说是一种基于TestDirector和Harvest/subversion软件生产线平台的实现方法

2、技术背景

许多软件公司，因为管理需要，会采购各式各样的配置管理工具、需求管理工具和缺陷管理工具，但这些工具基本上都是各厂家基于自己不同的关注视角独立开发的，所以工具内的信息基本上是不断裂的、重复的、不一致的，给研发度量和管理带来很大的难度；当然，也有厂家提供成套产品，但目前来看，仍有很多的缺点，例如价格一般非常昂贵，虽然部分信息同步，但大部分数据仍然是分开存放的，很难建立全维度的分析模型。

我们认为，一个好的软件生产线平台，首先应该是有一套优秀的全生命周期、多视角的研发管理方法论，其次才是有一个与之配套的可以随需应变的信息系统作为辅助支撑，目前还未有一个优秀的全生命周期、多视角的用于研发和管理的软件生产线平台。

3、发明内容

本发明的目的是充分利用软件企业中常见的工具，提供一个能够充分利用现有的工具和企业资产，尽量减少重复性投资的软件生产线平台的实现方法。

目前，很多软件研发组织都使用TestDirector作为自己的缺陷管理工具，用Harvest或者subversion作为自己的配置、版本管理工具，根据以上因素的出发，我们提出了建立“基于TestDirector和Harvest/subversion的软件生产线平台”的实现方法。

本发明的方法是按以下方式实现的，通过梳理软件研发过程中的信息标准、信息流向和信息依赖关系，制定出统一的缺陷、变更和配置管理使用规范，建立统一质量度量和统计分析的基础，形成产品质量和过程质量度量模型，并提供配套的软件研发协同管理系统进行实现支持，将TestDirector、Harvest或Subversion进行服务连通、规则映射和信息同步，完成研发过程的需求管理、配置管理、变更管理、发布管理、项目管理、缺陷管理的多维度数据采集，形成全生命周期的软件企业资产库；

具体步骤如下：

1)产品质量和过程质量度量模型的主线是从需求管理开始，所有来自外部的客户反馈、客户咨询、客户发现的缺陷、客户提出的变更，连同内部的研发任务、新的需求特性统称为“变更任务请求”，单独为每个研发项目建立两个不同类型的信息库：任务请求库和缺陷库，变更任务请求被录入到TestDirector的任务请求库中，任务请求被批准通过后，通过指派人员负责更改状态、补充填写发布版本、预计发布时间、各阶段责任人的必要的信息后，软件生产线平台会根据设定的规约自动在配置管理工具中创建对应的任务包并建立任务包和任务请求之间的映射关系；

2)指派人员对任务包进行处理，根据需要将任务包转给需求、设计和实现人员，系统将任务包的处理时长、流转历史、设计的工件信息采集到软件生产线平台中，并根据设定，更新TestDirector任务请求库中对应的变更任务请求；

3)在需求、设计和实现人员完成对任务包的处理后，系统根据设定的集成规则自动从harvest或者subversion中提取所涉及的工件进行集成，通过持续集成确保产品的结构正确，减少后续环节的无用工；

4)集成通过的产品，根据测试计划自动发布到测试机中，整个集成和发布过程做到无人值守，在出现问题时给出详细的信息提示；

5)测试人员根据测试计划安排，对准备发布的版本进行测试，所有测试结果都被计入到TestDirector的缺陷库中，缺陷中的“版本”信息记录下任务包、发布版本和缺陷之间的关系；

6)某个发布版本达到设定的测试通过标准后，软件生产线平台会制作出产品包，统一分发到各个生产环境中，在分发过程中，如果出现依赖冲突则停止自动升级，记录升级错误留待人工处理；

7)设定是否需要支持任务包的远程确认，如果启动该设定项，远程项目实施团队对分发的任务包进行验证，并将验证结果和发现的缺陷、变更与之前的任务进行关联绑定，以进行新一轮的任务变更请求。

任务请求库、缺陷库或配置管理工具，都要建立对应的使用规范和信息标准，如流程、表单、字段、关联关系、字段属性和字段选项，以便以统一口径进行数据采集和统计分析，在上述工具中的原始设计问题不能统一的，需要建立映射关系。

在度量模型中建立起度量指标，例如顺延率、处理周期或信息不规范率，并完成自动的数据采集分析，定期出统计报告。

建立项目管理数据，记录项目预估数据，并自动采集项目中针对任务的实际数据，用数据进行度量。

对Harvest和svn进行服务抽象，确定信息接口，软件研发团队根据自身需要进行工具的切换。

配置管理使用规范包括：流程、表单、字段、角色、权限和规约。

工件是是指：源代码，配置文件、升级脚本和升级手册。

本发明的有益效果是可以显著提高项目管理的准确度，提高效率，降低运营成本。

本发明的软件生产平台，主要应用于软件开发组织中，属于企业信息资产库的组成部分，通过指定可实施的方法论和信息标准，结合配套的信息系统，完成软件研发企业的生产和管理。

具体实施方式：

本发明可以在任何使用TestDirector的软件开发组织中推广使用，如果该组织没有使用Harvest作为配置管理工具，可以使用开源的Subversion产品。

配套开发的信息系统，可以使用任何常见的数据库作为信息存储单元。

TestDirector、Harvest和subversion可以外提供一些基本的二次开发接口，而且，根据需要如果有取不到的信息，可以直接访问数据库。我们可以根据度量模型和生产线模型的信息标准，对这些工具进行二次包装，并且为了保证可伸缩性，将其暴露成WebService接口。

这样，TestDirector的任务请求库对外暴露管理变更任务请求的接口，Harvest暴露管理任务包的接口，TestDirecotr的缺陷库对外暴露缺陷接口。配套的信息系统针对这些接口进行服务连通、规则映射和信息同步，并可以结合邮件、即时消息进行消息通知。

建立一套可实施的全生命周期的软件生产线平台，该平台包括一个度量模型、一个产品线模型(包括流程、表单、字段等相对应的信息标准规范)和配套的信息系统。依赖于得到最广泛使用的缺陷管理工具TestDirector，在配置/版本管理工具方面，可以使用久负盛名的CAHarvest，也可以选择使用成熟的开源产品Subversion，这样会极大的增加该项发明的应用机会。其主要设计思路是将需求管理、配置管理、变更管理、发布管理、项目管理、缺陷管理的信息模型提取出来，并建立细化的信息规范和信息标准，在不影响工作或者无觉察的情况下，将各类研发角色的工作数据有效采集到软件生产线平台中，解决软件研发过程中缺乏数据采集和数据度量的“拍脑门”决策现状。具体实现步骤如下：

1)该信息模型的主线是从需求管理开始，对于一个研发团队而言，所有来自外部的客户反馈、客户咨询、客户发现的缺陷、客户提出的变更，连同内部的研发任务、新的需求特性都被称为“变更任务请求”。我们单独为每个研发项目建立两个不同类型的信息库：任务请求库和缺陷库，变更任务请求被录入到TestDirector的任务请求库中。任务请求被批准通过后，由专人负责更改状态、补充填写必要的信息(如发布版本、预计发布时间、各阶段的责任人等)，软件生产线平台会根据设定的规约自动在配置管理工具中创建对应的任务包，指派负责人，并建立任务包和任务请求之间的映射关系。

2)被指派的负责人对任务包进行处理时，会将涉及到的工件与任务包进行关联，处理完毕后，会根据需要将任务包转给其他角色的负责人，这时，系统会将任务包的处理时长、流转历史、设计的工件信息采集到软件生产线平台中，并根据设定的更新TestDirector任务请求库中对应的变更任务请求。

3)在需求、设计和实现人员完成对任务包的处理后，系统根据设定的集成规则自动从harvest或者subversion中提取所涉及的工件(源代码，配置文件、升级脚本、升级手册等)进行集成，通过持续集成确保产品的结构正确，减少后续环节的无用工。

4)集成通过的产品，会根据测试计划，自动发布到测试机中，整个集成和发布的过程尽量做到无人值守，在出现问题时，也会给出详细的信息提示。

5)测试人员根据测试计划安排，对某个准备发布的版本进行测试，测试的所有结果都被计入到TestDirector的缺陷库中，缺陷中的“版本”信息记录下任务包、发布版本和缺陷之间的关系。

6)某个发布版本达到设定的测试通过标准后，软件生产线平台会制作出产品包(升级包、补丁包或者完整包)，统一分发到各个生产环境中。各个产品包之间可能存在依赖关系，在分发过程中，如果出现依赖冲突，会停止自动升级，记录升级错误，并留待人工处理。

根据项目情况，设定是否需要支持任务包的远程确认，如果启动该设定项，那么远程项目实施团队会对分发的任务包进行验证，并将验证结果和发现的缺陷、变更等与之前的任务进行关联绑定，以进行新一轮的任务变更请求。

无论是任务请求库、缺陷库还是配置管理工具，都要建立对应的使用规范和信息标准(流程、表单、字段、关联关系、字段属性、字段选项等)，以便以统一口径进行数据采集和统计分析。在上述工具中应原始设计问题，不能统一的，需要建立映射关系。

在度量模型中建立起度量指标，例如，顺延率、处理周期、信息不规范率等，并完成自动的数据采集分析，定期出统计报告

补充说明的是：对Harvest和svn进行服务抽象，确定信息接口，软件研发团队可以根据自身需要进行工具的切换。

可以建立起项目管理数据，记录项目预估数据，并自动采集项目中针对任务的实际数据，用数据进行度量，项目决策的准确度提升、工作效率的提高和运营成本的下降将是显著可见的。

项目实施团队非常关心提出的需求变更的回复速度、处理质量；而核心研发团队非常关注的是产品包发到项目现场后，项目的发布周期和验证周期，因为很多变更任务请求虽然提出得很急，但真正发布到项目后，项目实施团队可能会压很长的时间才发布。这个时候，就需要用度量模型来采集变更任务周期的回复率，回复周期和处理周期、验证周期等，作为下次评估项目提出来的任务请求的处理优先级的依据。

Claims (7)

1.一种软件生产线平台的实现方法，其特征在于，通过梳理软件研发过程中的信息标准、信息流向和信息依赖关系，制定出统一的缺陷、变更和配置管理使用规范，建立统一质量度量和统计分析的基础，形成产品质量和过程质量度量模型，并提供配套的软件研发协同管理系统进行实现支持，将TestDirector、Harvest或Subversion进行服务连通、规则映射和信息同步，完成研发过程的需求管理、配置管理、变更管理、发布管理、项目管理、缺陷管理的多维度数据采集，形成全生命周期的软件企业资产库；

具体步骤如下：

1)产品质量和过程质量度量模型的主线是从需求管理开始，所有来自外部的客户反馈、客户咨询、客户发现的缺陷、客户提出的变更，连同内部的研发任务、新的需求特性统称为“变更任务请求”，单独为每个研发项目建立两个不同类型的信息库：任务请求库和缺陷库，变更任务请求被录入到TestDirector的任务请求库中，任务请求被批准通过后，通过指派人员负责更改状态、补充填写发布版本、预计发布时间、各阶段责任人的必要的信息后，软件生产线平台会根据设定的规约自动在配置管理工具中创建对应的任务包并建立任务包和任务请求之间的映射关系；

2)指派人员对任务包进行处理，根据需要将任务包转给需求、设计和实现人员，系统将任务包的处理时长、流转历史、设计的工件信息采集到软件生产线平台中，并根据设定，更新TestDirector任务请求库中对应的变更任务请求；

3)在需求、设计和实现人员完成对任务包的处理后，系统根据设定的集成规则自动从harvest或者subversion中提取所涉及的工件进行集成，通过持续集成确保产品的结构正确，减少后续环节的无用工；

4)集成通过的产品，根据测试计划自动发布到测试机中，整个集成和发布过程做到无人值守，在出现问题时给出详细的信息提示；

5)测试人员根据测试计划安排，对准备发布的版本进行测试，所有测试结果都被计入到TestDirector的缺陷库中，缺陷中的“版本”信息记录下任务包、发布版本和缺陷之间的关系；

6)某个发布版本达到设定的测试通过标准后，软件生产线平台会制作出产品包，统一分发到各个生产环境中，在分发过程中，如果出现依赖冲突则停止自动升级，记录升级错误留待人工处理；

7)设定是否需要支持任务包的远程确认，如果启动该设定项，远程项目实施团队对分发的任务包进行验证，并将验证结果和发现的缺陷、变更与之前的任务进行关联绑定，以进行新一轮的任务变更请求。

2.根据权利要求1所述的方法，其特征在于，任务请求库、缺陷库或配置管理工具，都要建立对应的使用规范和信息标准，如流程、表单、字段、关联关系、字段属性和字段选项，以便以统一口径进行数据采集和统计分析，在上述工具中的原始设计问题不能统一的，需要建立映射关系。

3.根据权利要求1所述的方法，其特征在于，在度量模型中建立起度量指标，例如顺延率、处理周期或信息不规范率，并完成自动的数据采集分析，定期出统计报告。

4.根据权利要求3所述的方法，其特征在于，建立项目管理数据，记录项目预估数据，并自动采集项目中针对任务的实际数据，用数据进行度量。

5.根据权利要求1所述的方法，其特征在于，对Harvest和svn进行服务抽象，确定信息接口，软件研发团队根据自身需要进行工具的切换。

6.根据权利要求1所述的方法，其特征在于，配置管理使用规范包括：流程、表单、字段、角色、权限和规约。

7.根据权利要求1所述的方法，其特征在于，工件是是指：源代码，配置文件、升级脚本和升级手册。