CN114331110A - 一种项目管理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请涉及软件开发技术领域，尤其涉及一种项目管理方法、装置、设备及存储介质。方法包括：接收项目创建指令；根据项目创建指令创建项目；项目包括至少两个处理环节，每个处理环节包括至少一个操作文档；接收文档处理指令；根据文档处理指令对操作文档进行处理；接收关联关系建立指令；根据关联关系建立指令建立操作文档之间的关联关系；根据关联关系确定项目的管理路径。该项目管理方法，通过建立项目，并对项目开发流程进行监控，建立起操作文档之间的关联关系，实现了项目开发流程的双向可追溯，提升软件开发效率，同时提高产品的稳定性。

Description

一种项目管理方法、装置、设备及存储介质

技术领域

本申请涉及软件开发技术领域，尤其涉及一种项目管理方法、装置、设备及存储介质。

背景技术

随着汽车行业的发展，汽车电子系统的功能也越来越复杂、多样化，但是随之而来的，汽车电子系统中各电子电器发生故障或者失效等问题也愈发频繁，这使得当前消费者对于汽车的安全性能也更加关注。规范汽车软件的研发流程和管理流程，能够使得电子、电气产品的安全功能在安全生命周期内满足汽车安全完整性等级的要求，以及电子系统的安全功能在各种严酷条件下依然保持正常运动，从而确保驾乘人员以及路人的安全。

目前，现有的软件需求管理模式分两种，一种是以一条需求一个任务的形式下发到相关方去实现并上传测试用例、测试结果，另外一种是将传统Word需求条目化分解到章节，这也是一种条目化需求和测试用例的方式。这两种方式中，需求、架构设计和测试用例是一个个独立的系统，由于底层架构不一致，没有办法进行联动。需求和测试用例之间都是单向可追溯的，无法做到双向追溯，也无法做到上下游变化联动通知。此外，汽车软件开发的流程主要依靠人为的管控，开发流程无法进行追溯。而且开发过程中的文档，例如需求、架构设计、测试用例、测试结果各自独立，是一个个信息孤岛，不能够双向可追溯，需要人为的去监督维护，导致管理效率低且容易出错，进而可能会导致开发出的产品功能缺失，性能不稳定。

发明内容

本发明提供一种项目管理方法、装置、设备及存储介质，对软件开发的流程进行管控，以实现软件开发流程的双向可追溯。

为解决上述技术问题，第一方面，本申请实施例公开了一种项目管理方法，方法包括：

接收项目创建指令；

根据项目创建指令创建项目；项目包括至少两个处理环节，每个处理环节包括至少一个操作文档；

接收文档处理指令；

根据文档处理指令对操作文档进行处理；

接收关联关系建立指令；

根据关联关系建立指令建立操作文档之间的关联关系；

根据关联关系确定项目的管理路径。

进一步的，根据项目创建指令创建项目，包括：

根据项目创建指令确定项目模板；

根据项目模板实例化处理环节中的操作文档。

进一步的，根据文档处理指令对操作文档进行处理，包括：

根据文档处理指令将操作文档划分为多个章节；

将章节解构为多个条目。

进一步的，处理环节包括需求设计环节和测试规范环节；需求设计环节中的操作文档包括多个需求设计类文档；测试规范环节中的操作文档包括多个测试规范类文档；

根据关联关系建立指令建立操作文档之间的关联关系，包括：

根据关联关系建立指令获取多个需求设计类文档的第一类文档标识和多个测试规范类文档的第二类文档标识；第一类文档标识用于标识每个需求设计类文档；第二类文档标识用于标识每个测试规范类文档；

根据项目模板和第一类文档标识建立多个需求设计类文档之间的纵向关联关系；

根据项目模板和第二类文档标识建立多个测试规范类文档之间的纵向关联关系。

进一步的，根据关联关系建立指令建立操作文档之间的关联关系，还包括：

根据项目模板、第一类文档标识和第二类文档标识建立每个需求设计类文档与其中一个测试规范类文档的横向关联关系。

进一步的，每个需求设计类文档包括多个需求设计类条目；每个测试规范类文档包括多个测试规范类条目；

根据关联关系建立指令建立操作文档之间的关联关系，还包括：

根据关联关系建立指令建立每个需求设计类条目与至少一个测试规范类条目之间的关联关系。

进一步的，多个需求设计类文档中存在第一需求设计类文档和第二需求设计类文档；第一需求设计类文档包括多个第一需求设计类条目；第二需求设计类文档包括多个第二需求设计类条目；多个测试规范类文档中存在第一测试规范类文档和第二测试规范类文档；第一测试规范类文档包括多个第一测试规范类条目；第二测试规范类文档包括多个第二测试规范类条目；

根据关联关系建立指令建立操作文档之间的关联关系，还包括：

根据关联关系建立指令建立每个第一需求设计类条目与至少一个第二需求设计类条目之间的关联关系；

根据关联关系建立指令建立每个第一测试规范类条目与至少一个第二测试规范类条目之间的关联关系。

进一步的，根据关联关系确定项目的管理路径之后，还包括：

接收条目变更指令；

根据管理路径发送条目变更通知。

进一步的，根据关联关系确定项目的管理路径之后，还包括：

接收文档导出指令；

根据文档导出指令导出项目的报告文档。

第二方面，本申请实施例公开了一种项目管理装置，装置包括：

项目创建指令接收模块，用于接收项目创建指令；

项目创建模块，用于根据项目创建指令创建项目；项目包括至少两个处理环节，每个处理环节包括至少一个操作文档；

文档处理指令接收模块，用于接收文档处理指令；

操作文档处理模块，用于根据文档处理指令对操作文档进行处理；

关联关系建立指令接收模块，用于接收关联关系建立指令；

关联关系建立模块，用于根据关联关系建立指令建立操作文档之间的关联关系；

管理路径确定模块，用于根据关联关系确定项目的管理路径。

在一些可选的实施方式中，项目创建模块包括：

项目模板确定单元，用于根据项目创建指令确定项目模板；

操作文档实例化单元，用于根据项目模板实例化处理环节中的操作文档。

在一些可选的实施方式中，操作文档处理模块包括：

章节划分单元，用于根据文档处理指令将操作文档划分为多个章节；

章节解构单元，用于将章节解构为多个条目。

在一些可选的实施方式中，处理环节包括需求设计环节和测试规范环节；需求设计环节中的操作文档包括多个需求设计类文档；测试规范环节中的操作文档包括多个测试规范类文档；

关联关系建立模块包括：

文档标识获取单元，用于根据关联关系建立指令获取多个需求设计类文档的第一类文档标识和多个测试规范类文档的第二类文档标识；第一类文档标识用于标识每个需求设计类文档；第二类文档标识用于标识每个测试规范类文档；

纵向关联关系建立单元，用于根据项目模板和第一类文档标识建立多个需求设计类文档之间的纵向关联关系；

纵向关联关系建立单元，还用于根据项目模板和第二类文档标识建立多个测试规范类文档之间的纵向关联关系。

在一些可选的实施方式中，根据关联关系建立指令建立操作文档之间的关联关系，还包括：

横向关联关系建立单元，用于根据项目模板、第一类文档标识和第二类文档标识建立每个需求设计类文档与其中一个测试规范类文档的横向关联关系。

在一些可选的实施方式中，每个需求设计类文档包括多个需求设计类条目；每个测试规范类文档包括多个测试规范类条目；

关联关系建立模块还包括：

第一条目关联关系建立单元，用于根据关联关系建立指令建立每个需求设计类条目与至少一个测试规范类条目之间的关联关系。

在一些可选的实施方式中，多个需求设计类文档中存在第一需求设计类文档和第二需求设计类文档；第一需求设计类文档包括多个第一需求设计类条目；第二需求设计类文档包括多个第二需求设计类条目；多个测试规范类文档中存在第一测试规范类文档和第二测试规范类文档；第一测试规范类文档包括多个第一测试规范类条目；第二测试规范类文档包括多个第二测试规范类条目；

关联关系建立模块还包括：

第二条目关联关系建立单元，用于根据关联关系建立指令建立每个第一需求设计类条目与至少一个第二需求设计类条目之间的关联关系；

第三条目关联关系建立单元，用于根据关联关系建立指令建立每个第一测试规范类条目与至少一个第二测试规范类条目之间的关联关系。

在一些可选的实施方式中，该装置还包括：

条目变更指令接收模块，用于接收条目变更指令；

条目变更通知发送模块，用于根据管理路径发送条目变更通知。

在一些可选的实施方式中，该装置还包括：

文档导出指令接收模块，用于接收文档导出指令；

文档导出模块，用于根据文档导出指令导出项目的报告文档。

第三方面，本申请实施例公开了一种电子设备，设备包括处理器和存储器，存储器中存储有至少一条指令或至少一段程序，至少一条指令或至少一段程序由处理器加载并执行如上所述的项目管理方法。

第四方面，本申请实施例公开了一种计算机可读存储介质，存储介质中存储有至少一条指令或至少一段程序，至少一条指令或至少一段程序由处理器加载并执行以实现如上所述的项目管理方法。

本申请实施例提供的项目管理方法、装置、设备及存储介质，具有如下技术效果：

该项目管理方法，通过建立项目，并对项目开发流程进行监控，建立起操作文档之间的关联关系，实现了项目开发流程的双向可追溯，提升软件开发效率，同时提高产品的稳定性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本申请实施例提供的一种应用环境的示意图；

图2是本申请实施例提供的一种项目管理系统的架构示意图；

图3是本申请实施例提供的一种项目管理方法的流程示意图；

图4是本申请实施例提供的一种项目模板框架示意图；

图5是本申请实施例提供的一种需求条目关联关系的逻辑示意图；

图6是本申请实施例提供的一种条目变更影响传递逻辑示意图；

图7是本申请实施例提供的一种系统需求文档与系统合格性测试规范文档对应关系示意图；

图8是本申请实施例提供的一种测试用例报告文档在流程管理节点显示的界面图；

图9是本申请实施例提供的另一种测试用例报告文档在流程管理节点显示的界面图；

图10是本申请实施例提供的又一种测试用例报告文档在流程管理节点显示的界面图；

图11是本申请实施例提供的一种项目管理装置的结构示意图；

图12是本申请实施例提供的一种项目管理方法的服务器的硬件结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前，在汽车软件开发过程中，往往是用表格文档，如Excel文档对需求，架构、测试用例、测试结果进行编号管理。这样的做法效率低下，上下横纵深度都不够，既不能保证逐条结构化客户的每条需求，也无法做到每条需求都有代码开发和测试用例覆盖。无法做到保证100％的检测测试覆盖率，造成功能的丢失，需求的丢失，测试的丢失，从而无法保证所交付的汽车软件质量，对于汽车安全来说是极大的隐患。此外，最新的汽车功能安全标准对测试用例覆盖率要求越来越高，这就需要一套设计精妙的软件管理系统去实现以上流程，以保证需求、架构设计、测试用例、测试结果双向可追溯。

请参阅图1，图1是本申请实施例提供的一种应用环境的示意图，包括服务器101和至少一个流程管理节点103。

本申请实施例中，服务器101中搭载有项目管理系统，该项目管理系统用于管理软件开发流程，实现需求、架构设计、测试用例、测试结果的双向可追溯。可选的，服务器101可以包括是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

在一个可选的实施方式中，图2是本申请实施例提供的一种项目管理系统的架构示意图，如图2所示，该系统包括需求管理子系统和测试管理子系统。其中，需求管理子系统用于管理需求类相关开发流程。测试管理子系统用于管理测试类相关开发流程。

在一个可选的实施方式中，需求管理子系统可以包括：

利益相关方需求模块：用于将利益相关方的需求文档划分为不同章节，并将不同的章节划分为多条独立相关方需求条目。

系统需求模块：用于将利益相关方的需求转换为系统需求，然后将系统需求划分为不同章节，并将不同章节的系统需求划分为多条独立系统需求条目。

系统架构模块：用于根据系统需求设计系统架构，然后将系统架构划分为不同章节，并将不同章节划分为多条系统架构设计条目。

软件需求模块：用于根据系统架构确定软件需求，然后将软件需求划分为不同章节，并将不同章节的软件需求划分为多条独立软件需求条目。

软件架构模块：用于根据软件需求设计软件架构，然后将软件架构划分为不同章节，并将不同章节划分为多条软件架构设计条目。

软件详细设计模块：用于根据软件架构进行详细软件设计，然后将详细软件设计划分成不同章节，并将不同章节划分为多条软件详细设计条目。

在一个可选的实施方式中，测试管理子系统可以包括：

单元测试规范模块：对不同章节的详细软件进行测试以验证是否完成设计的不同章节的详细软件，生成单元测试结果，并将单元测试结果与相应的详细软件设计条目相对应。

软件集成测试规范模块：对软件架构进行测试以验证是否完成设计的软件架构，生成测试结果，并将测试结果与软件架构设计条目相对应。

软件合格性测试规范模块：对软件进行整体测试以验证是否满足全部软件需求，生成测试结果，并将测试结果与软件需求条目相对应。

系统集成测试规范模块：对系统架构进行测试以验证是否完成设计的系统架构，生成测试结果，并将测试结果与系统架构设计条目相对应。

系统合格性测试规范模块：对系统进行整体测试以验证是否满足全部系统需求，生成测试结果，并将测试结果与系统需求条目相对应。

本申请实施例中，流程管理节点103可以是一个，也可以是多个。流程管理节点103为项目管理系统的客户端，用于对软件开发过程中的流程进行处理。流程管理节点103可以包括但不限于智能手机、台式计算机、平板电脑、笔记本电脑、智能音箱、数字助理、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、智能可穿戴设备等类型的电子设备。也可以为运行于上述电子设备的软体，例如网页、应用程序、小程序等。可选的，电子设备上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux、windows、Unix等。

在一个可选的实施方式中，流程管理节点103对流程进行的处理可以包括在项目管理系统中下发指令、发布通知、上传操作文档等。流程管理节点103可以包括项目经理节点、文档责任人节点、章节责任人节点、条目责任人节点等。不同的流程管理节点103可以具有不同的处理权限。例如，项目经理节点可以创建项目，实例化项目各个处理环节的操作文档以及操作文档内部模板化章节结构，制定各个操作文档的责任人等。文档责任人节点编辑所维护的操作文档的内容，查看操作文档的预览，查看操作文档的报表等。章节责任人节点可以维护所负责章节的信息，查看章节的预览，查看章节的报表等。条目责任人节点执行所负责的条目，执行测试用例，查看条目的预览，查看条目的报表等。

本申请实施例中，服务器101与流程管理节点103可以通过有线链路连接，也可以通过无线链路连接。

以下介绍本申请一种项目管理方法的具体实施例，图3是本申请实施例提供的一种项目管理方法的流程示意图，本说明书提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图3所示，该方法可以包括：

S301：接收项目创建指令。

本申请实施例中，在一个项目开始研发之前，可以在项目管理系统中创建项目，进而实现对项目的整个生命周期进行管理。具体的，项目管理人员可以通过流程管理节点向服务器发送项目创建指令，可选的，该流程管理节点可以是项目经理节点。相应的，服务器接收到项目创建指令，然后根据项目创建指令进行处理。

S303：根据项目创建指令创建项目。

本申请实施例中，服务器接收到项目创建指令后会在项目管理系统中创建一个项目。对于任何一个项目而言，项目的完成包括多个处理环节，例如需求处理环节、测试环节等，而对于每个处理环节来说，都可能会产生多个操作文档。因此服务器在项目管理系统中所创建的项目包括至少两个处理环节，每个处理环节包括至少一个操作文档。在一个可选的实施方式中，根据项目创建指令创建项目的具体流程可以包括：服务器首先根据项目创建指令确定项目模板，项目模板将项目划分为多个处理环节，项目模板中包含每个处理环节中的操作文档的模板。此外，项目模板中还包含有不同操作文档之间的内在联系。服务器确定项目模板后，按照项目模板实例化每个处理环节中的操作文档。

在一些可选的实施方式中，，项目管理系统中预置有多个项目模板。流程管理节点在发送项目创建指令时，根据项目的实际需要在项目管理系统中选择预置的项目模板，然后向服务器发送项目创建指令。项目创建指令中携带了该项目模板的标识信息，服务器接收到项目创建指令之后，通过解析项目创建指令获取到项目模板的标识信息，然后根据项目模板的标识信息确定流程管理节点所选择的项目模板，进而根据项目模板实例化项目各个处理环节中各个类型的操作文档，以及实例化各个操作文档内部模板化的章节结构，完成项目创建。可选的，服务器根据项目模板实例化操作文档的操作可以是：对于任意处理环节来说，服务器通过接收流程管理节点所上传的针对该处理环节中的上传文档，然后服务器将该上传文档与项目模板中该处理环节中的操作文档进行匹配，从而完成该处理环节中的操作文档实例化。可选的，服务器根据项目模板实例化操作文档的操作还可以是：在项目模板确定后，在流程管理节点中显示不同处理环节中的操作文档结构，流程管理节点按照操作文档的结构对每个操作文档进行完善后，服务器将流程管理节点所完善的内容进行保存，从而完成操作文档实例化。需要说明的是，针对不同处理环节中的操作文档可以根据项目进度进行实例化。例如，在项目的初始阶段，可以先对需求设计类的操作文档进行实例化，而测试规范类的操作文档可以先建立操作文档的模板，然后在项目进行到测试阶段时，再按照操作文档的模板进行逐条实例化。

在另一些可选的实施方式中，流程管理节点在发送项目创建指令时，也可以根据项目的实际需要在项目管理系统中自行创建项目模板，然后向服务器发送项目创建指令。项目创建指令中携带了该项目模板具体信息，如多个处理环节、不同类型的操作文档模板等，服务器接收到项目创建指令之后，通过解析项目创建指令获取到项目模板的详细信息，然后根据该项目模板的详细信息创建项目。在一些实施例中，在项目创建之后还可以通过接收流程管理节点所发送的协作流程管理节点指定指令，服务器根据该协作流程管理节点指定指令创建多个具有不同权限的协作流程管理节点。作为一种示例，在项目模板实例化之后，项目经理节点可以指定多个操作文档，如需求文档、设计文档、测试文档的文档责任人节点。

本申请实施例中，项目管理人员可以根据客户需求的不同以及项目业务类型的不同，创建不同复杂程度的关联关系和模板。例如，如果项目本身敏捷类迭代开发类，对双向追溯不高的，可以有针对性的建立关联关系，并保持成项目模板。项目管理系统还可将该项目模板保存，作为预置项目模板进而可以实现大面积快速创建多个相同的业务模型。

S305：接收文档处理指令。

本申请实施例中，项目创建完成后，随着项目的完成进度，需要完善编辑各个处理环节的操作文档，以实现对项目进程的全方位监控。具体的，项目管理人员可以通过流程管理节点向服务器发送文档处理指令，可选的，该流程管理节点可以是文档责任人节点。相应的，服务器接收到文档处理指令，然后根据文档处理指令进行处理。

S307：根据文档处理指令对操作文档进行处理。

本申请实施例中，服务器接收到文档处理指令后，会在项目管理系统中已创建的项目中对相应的操作文档进行处理。具体的，不同的流程管理节点具有不同的处理权限，对于文档责任人节点来说，只能处理其所管理的操作文档。可选的，文档责任人节点在对其所管理的操作文档进行处理时，所发送的文档处理指令只能对相应的操作文档进行处理。在一些实施例中，对于管理多个操作文档的文档责任人节点或者具有更高处理权限的流程管理节点，如项目经理节点来说，其所发送的文档处理指令携带有待处理操作文档的标识信息，服务器在接收到该文档处理指令后根据待处理操作文档的标识信息确定出相应的操作文档，然后在对该操作文档进行处理。

本申请实施例中，图4是本申请实施例提供的一种项目模板框架示意图，如图4所示，项目可以分为需求设计环节和测试规范环节。需求设计环节可以包括利益相关方需求处理环节、系统需求处理环节、系统架构处理环节、软件需求处理环节、软件架构处理环节、软件详细设计处理环节。测试规范环节可以包括单元测试规范处理环节、软件集成测试规范处理环节、软件合格性测试规范处理环节、系统集成测试规范处理环节、系统合格性测试规范处理环节等，每个处理环节均对应有一个至多个操作文档。当服务器接收到文档处理指令后，对相应的操作文档进行处理。在一个可选的实施方式中，处理环节为需求设计环节。需求设计环节中的操作文档包括需求设计类文档。根据文档处理指令对操作文档进行处理可以是：服务器根据文档处理指令将需求设计类文档划分为多个章节，然后将章节解构为多个条目。作为一种示例，管理利益相关方需求文档的文档责任人节点向服务器发送文档处理指令，服务器接收到该文档处理指令后对该文档处理指令进行解析，确定要进行处理的操作文档为利益相关方需求文档，然后将利益相关方需求文档进行章节划分，划分为多个的章节。对于任意一个章节来说，服务器将该章节进一步的解构，最终得到多条不可分割的需求条目。通过上述方法，实现了需求设计的上下游可追溯，而且保证了隐私权限的保护。

需要说明的是，本申请实施例中对操作文档的处理不仅限上述示例，本领域技术人员在不付出创造性劳动的前提下还可以根据上述示例得到对其他需求设计环节的操作文档和测试规范环节的操作文档的处理方法。

S309：接收关联关系建立指令。

本申请实施例中，根据项目的完成进度，在各个处理环节的操作文档完成条目化之后，需要建立各个操作文档之间、条目之间的关联关系，以便于追溯。具体的，项目管理人员可以通过流程管理节点向服务器发送关联关系建立指令，可选的，该流程管理节点可以是文档责任人节点，也可以是章节责任人节点或条目责任人节点。相应的，服务器接收到关联关系建立指令，然后根据关联关系建立指令进行建立各个操作文档之间、条目之间的关联关系。

S311：根据关联关系建立指令建立操作文档之间的关联关系。

本申请实施例中，服务器接收到关联关系建立指令后，对各个处理环节中操作文档之间以及操作文档中的各个条目之间建立关联关系。如图4所示，服务器根据关联关系建立指令建立操作文档之间的横向关联关系和纵向关联关系。

作为一种可选的实施方式，项目中的处理环节包括需求设计环节和测试规范环节。其中，需求设计环节中的操作文档包括多个需求设计类文档，测试规范环节中的操作文档包括多个测试规范类文档。服务器接收到关联关系建立指令后，会根据关联关系建立指令获取需求设计环节中操作文档的第一类文档标识，以及测试规范环节中操作文档的第二类文档标识。第一类文档标识用于标识每个需求设计类文档，第二类文档标识用于标识每个测试规范类文档。换句话来说，第一类文档标识包括多个标识，每个标识能够标识一个需求设计类文档。同理，第二类文档标识也包括多个标识，每个标识能够标识一个测试规范类文档。然后服务器根据项目模板和第一类文档标识建立多个需求设计类文档之间的纵向关联关系。以及根据项目模板和第二类文档标识建立多个测试规范类文档之间的纵向关联关系。具体来说，多个需求设计类文档包括利益相关方需求文档、系统需求文档、系统架构文档、软件需求文档、软件架构文档、软件详细设计文档；第二类包括单元测试规范文档、软件集成测试规范文档、软件合格性测试规范文档、系统集成测试规范文档、系统合格性测试规范文档。服务器根据项目模板和第一类文档标识，依次建立利益相关方需求文档与系统需求文档之间的关联关系、系统需求文档与系统架构文档之间的关联关系、系统架构文档与软件需求文档之间的关联关系、软件需求文档与软件架构文档之间的关联关系、软件架构文档与软件详细设计文档之间的关联关系同样的，服务器根据项目模板和第二类文档标识，依次建立单元测试规范文档与软件集成测试规范文档之间的关联关系、软件集成测试规范文档与软件合格性测试规范文档之间的关联关系、软件合格性测试规范文档与系统集成测试规范文档之间的关联关系、系统集成测试规范文档与系统合格性测试规范文档之间的关联关系。也就是说，操作文档之间的纵向关联关系可以是利益相关方需求文档与系统需求文档之间的关联关系，或者是系统需求文档与系统架构文档之间的关联关系，或者是系统架构文档与软件需求文档之间的关联关系，或者是软件需求文档与软件架构文档之间的关联关系，或者是软件架构文档与软件详细设计文档之间的关联关系。操作文档之间的纵向关联关系还可以是单元测试规范文档与软件集成测试规范文档之间的关联关系，软件集成测试规范文档与软件合格性测试规范文档之间的关联关系，软件合格性测试规范文档与系统集成测试规范文档之间的关联关系，系统集成测试规范文档与系统合格性测试规范文档之间的关联关系。

作为另一种可选的实施方式，服务器还可以根据项目模板、第一类文档标识和第二类文档标识建立每个需求设计类文档与其中一个测试规范类文档的横向关联关系。具体的，服务器根据项目模板、第一类文档标识和第二类文档标识，依次建立系统需求文档与系统合格性测试规范文档之间的关联关系、系统架构文档与系统集成测试规范文档之间的关联关系、软件需求文档与软件合格性测试规范文档之间的关联关系、软件架构文档与软件集成测试规范文档之间的关联关系、软件详细设计文档与单元测试规范文档之间的关联关系。也就是说，操作文档之间的横向关联关系可以是系统需求文档与系统合格性测试规范文档之间的关联关系，或者是系统架构文档与系统集成测试规范文档之间的关联关系，或者是软件需求文档与软件合格性测试规范文档之间的关联关系，或者是软件架构文档与软件集成测试规范文档之间的关联关系，或者是软件详细设计文档与单元测试规范文档之间的关联关系。

本申请实施例中，服务器接收到关联关系建立指令后，除了建立各个处理环节中操作文档之间的关联关系外，还会建立不同操作文档中的各个条目之间的关联关系。

作为一种可选的实施方式，每个需求设计类文档包括多个需求设计类条目。每个测试规范类文档包括多个测试规范类条目。服务器接收到关联关系建立指令后，服务器根据关联关系建立指令建立每个需求设计类条目与至少一个测试规范类条目之间的关联关系。

作为另一种可选的实施方式，多个需求设计类文档中存在第一需求设计类文档和第二需求设计类文档；第一需求设计类文档包括多个第一需求设计类条目；第二需求设计类文档包括多个第二需求设计类条目；多个测试规范类文档中存在第一测试规范类文档和第二测试规范类文档；第一测试规范类文档包括多个第一测试规范类条目；第二测试规范类文档包括多个第二测试规范类条目。服务器根据关联关系建立指令建立每个第一需求设计类条目与至少一个第二需求设计类条目之间的关联关系。服务器根据关联关系建立指令建立每个第一测试规范类条目与至少一个第二测试规范类条目之间的关联关系。

需要说明的是，服务器根据关联关系建立指令建立建立条目之间的关联关系可以包括向上关联关系、向下关联关系、衍生关联关系、源自关联关系等。向上关联关系表示该条目关联上游操作文档的条目，具体的，该条目可以关联上游操作文档中的某个有效的需求条目或者设计条目或者测试用例。向下关联关系表示该条目关联下游操作文档的条目，具体的，该条目可以关联下游操作文档中的某个有效的需求条目或者设计条目或者测试用例。衍生关联关系或源自关联表示该条目关联本操作文档内的其他条目，具体的，该条目可以关联该条目所在操作文档中的某个有效的需求条目或者设计条目或者测试用例。

作为一种可选的实施方式，图5是本申请实施例提供的一种需求条目关联关系的逻辑示意图，如图5所示，服务器根据关联关系建立指令条目之间的关联关系时，可以对条目进行分类打标签。例如，可对需求进行分类、打标签，标签可以包括系统需求、软件需求等，也可以是描述类条目、功能需求条目、非功能需求条目等逐级分解到一条条可编辑的条目，根据管理条目属性、变更版本、基线建立这些条目之间的关联关系，条目之间的关联关系可以是一对一，也可以是一对多，或者是多对多。条目之间建立关联关系可以实现条目之间的双向可追溯。具体的，条目包括系统需求条目和软件需求条目。根据关联关系建立指令建立操作文档之间的关联关系的具体处理可以是：服务器根据关联关系建立指令建立系统需求条目与软件需求条目之间的关联关系。

S313：根据关联关系确定项目的管理路径。

本申请实施例中，服务器在建立起各个处理环节中操作文档之间以及操作文档中的各个条目之间建立关联关系之后，可根据关联关系确定每个操作文档、每个条目的管理路径。各个流程管理节点如项目经理节点、各文档责任人节点、各条目责任人节点可根据操作文档之间的管理路径和条目之间的管理路径对项目的各个处理环节进行管理。

本申请实施例中，在软件开发过程中可能会出现某个条目变更的情况，服务器可根据操作文档之间的管理路径和条目之间的管理路径发布条目变更通知，以实现上下游变化联动通知。作为一种可选的实施方式，根据关联关系确定项目的管理路径之后还包括：服务器接收流程管理节点发送的条目变更指令，然后服务器根据管理路径发送条目变更通知。具体的，当某个条目需要变更时，该条目的流程管理节点，即条目责任人节点向服务器发送条目变更指令。条目的变更可以是条目修订：将拟制中的条目状态推动到拟制中。或者是条目验证：将已发布的条目状态推动到已验证。或者是条目作废：将已验证的条目状态变更为已作废。或者是变更条目责任人节点：变更条目的责任人节点。或者是条目修改：“拟制中”的条目的条目责任人可以在列表画面，直接修改条目名称、条目内容。对于条目其他内容修改需进入到条目详情中进行修改。服务器在接收到该条目变更指令后，向与该条目具有关联关系条目的流程管理节点发送条目变更通知，从而能够实现快速传递条目变更影响，避免不必要的资源浪费，提高项目研发效率。一个条目关联多个条目是，条目变更通知会发送至全所有关联条目的条目责任人节点。作为一种示例，图6是本申请实施例提供的一种条目变更影响传递逻辑示意图，如图6所示，A01条目与B01条目具有关联关系，当A01条目需要发生变更时，A01条目的流程管理节点即A01条目责任人节点发送条目变更指令将拟制中的条目状态推动到拟制中，然后将拟制中的条目状态推动到已发布。服务器接收到条目变更指令后根据A01条目的关联关系通知B01条目的B01条目责任人节点。B01条目责任人节点根据条目变更通知确定对B01条目的处理方案。具体的，B01条目责任人节点可以接收条目变更通知并调整B01条目，也可以是只是接收条目变更通知并不对B01条目进行调整，还可以是退回条目变更通知，即不接受条目变更通知并向服务器发送B01条目的维护诉求。如此循环一次至多次，直至所有的关联条目的条目责任人节点均接收接收条目变更通知且并不对自身所维护的条目进行调整时，该条目可完成变更。

在一些实施例中，当操作文档和条目的管理路径确定之后，还可以通过上传测试用例建立测试用例与需求条目之间的追溯关系。服务器可检查每条测试用例是否都有对应的需求，同理每条需求是否都有测试用例覆盖。服务器可以建立需求设计类文档与测试规范文档之间的关联关系。对于文档条目之间可以建立多对多的关联关系，以实现条目之间的双向可追溯。作为一种可选的实施方式，根据关联关系确定项目的管理路径之后还包括：服务器接收流程管理节点发送的测试用例上传指令，然后根据测试用例上传指令上传与每个条目对应的测试用例。具体的，图7是本申请实施例提供的一种系统需求文档与系统合格性测试规范文档对应关系示意图，如图7所示，服务器接收流程管理节点发送的测试用例上传指令，可选的，该流程节点可以是条目责任人节点。可选的，该条目责任人节点可以是需求设计类文档的条目责任人节点，也可以是测试规范类文档的条目责任人节点。然后服务器向流程管理节点反馈测试用例上传界面，流程管理节点在该界面上上传与条目责任人节点所维护的条目所对应的测试用例。在一些实施例中，流程管理节点向服务器所发送的测试用例上传指令中携带了测试用例信息，服务器在接收到测试用例上传指令后通过解析测试用例上传指令获取到测试用例。

需要说明的是，如果上传测试用例的流程管理节点是需求设计类文档的条目责任人节点，则服务器直接建立该测试用例与条目责任人节点所维护的的需求测试类条目之间的关联关系。如果上传测试用例的流程管理节点是测试规范类文档的条目责任人节点，则服务器通过该测试用例对该条目责任人节点所维护的的测试规范类条目进行实例化，由于每个测试规范类条目与需求设计类条目之间建立有关联关系，从而实现了测试用例对需求的覆盖。

本申请实施例中，上传测试用例之后还包括上传测试结果的步骤。具体的，服务器接收流程管理节点发送的测试结果上传指令，可选的，该流程节点可以是条目责任人节点。可选的，该条目责任人节点可以是需求设计类文档的条目责任人节点，也可以是测试规范类文档的条目责任人节点。然后服务器向流程管理节点反馈测试结果上传界面，流程管理节点在该界面上上传与条目责任人节点所维护的条目所对应的测试结果。在一些实施例中，流程管理节点向服务器所发送的测试结果上传指令中携带了测试结果信息，服务器在接收到测试结果上传指令后通过解析测试结果上传指令获取到测试结果。在一些实施例中，所上传的测试用例中也可以包含有该测试用例的测试结果，从而使需求、测试用例、测试结果之间建立起关联关系，实现需求、测试用例、测试结果之间的双向可追溯。

在一些可选的实施方式中，服务器还可以根据流程管理节点所发送的文档导出指令导出项目处理流程中的报告文档。具体的，服务器接收流程管理节点发送的文档导出指令，然后服务器根据文档导出指令导出项目中的结构化数据的报告文档。报告文档可以是条目文档，如需求条目文档、设计条目文档等，也可以是关联关系文档，也可以是条目变更动态文档，也可以是测试类文档，如测试用例文档、测试结果文档等，还可以是测试用例报告文档等。文档导出指令中携带有所要导出报告文档的类型标识，当服务器接收到文档导出指令后，对文档导出指令进行解析获取到所要导出报告文档的类型标识，进而生成相应的报告文档，然后发送至请求报告文档的流程管理节点。需要说明的是，对于不同的流程管理节点来说，根据其处理权限的不同可以请求导出不同的报告文档。例如，文档责任人节点可以请求导出其所维护的条目文档、关联关系文档、测试用例报告文档等。条目责任人节点可以请求导出与其所维护的条目的关联关系文档等。

本申请实施例中，当流程管理节点向服务器请求报告文档时，服务器可以向流程管理节点返回文档形式的报告，包括但不仅限于Word文档、TXT文档、PDF文档、图片文档等形式的报告。在一些实施例中，当流程管理节点向服务器请求报告文档时，服务器还可以向流程管理节点返回网页形式的报告。作为一种示例，流程管理节点向服务器发送文档导出指令请求测试用例报告文档，服务器接收到文档导出指令后生成网页形式的测试用例报告文档。可选的，该网页形式的测试用例报告文档中可以包括测试用例完成情况信息。即测试用例报告文档中包含了测试用例完成情况统计。图8是本申请实施例提供的一种测试用例报告文档在流程管理节点显示的界面图，如图8所示，该界面中通过以饼状图的形式展示了当前测试文档中测试用例的完成情况。测试用例的完成情况可以以百分比的形式表示，也可以以具体的完成数量和未完成数量来进行表示。可选的，测试用例的完成情况以百分比的形式表示，流程管理节点通过点击饼状图相应部分可以查看对应的测试用例清单。可选的，该网页形式的测试用例报告文档中还可以包括测试用例通过情况信息。即测试用例报告文档中包含了测试用例通过情况统计。图9是本申请实施例提供的另一种测试用例报告文档在流程管理节点显示的界面图，如图9所示，该界面中通过以饼状图的形式展示了当前测试文档中测试用例的测试通过情况。测试用例的测试通过情况可以以百分比的形式表示，也可以以具体的通过数量和未通过数量来进行表示。可选的，测试用例的通过情况以百分比的形式表示，流程管理节点通过点击饼状图相应部分可以查看对应的测试用例清单。可选的，该网页形式的测试用例报告文档中还可以包括测试用例覆盖率信息。即测试用例报告文档中包含了测试用例与需求的关联情况统计。图10是本申请实施例提供的又一种测试用例报告文档在流程管理节点显示的界面图，如图10所示，该界面中通过以饼状图的形式展示了当前测试文档中的测试用例与需求的关联情况。测试用例与需求的关联情况可以以百分比的形式表示，也可以以具体的关联数量和未关联数量来进行表示。可选的，测试用例与需求的关联情况以百分比的形式表示，流程管理节点通过点击饼状图相应部分可以查看对应的测试用例清单。

本申请实施例所述的项目管理方法，通过建立关联关系确定项目中各个操作文档以及条目的管理路劲，实现需求、架构设计、测试用例、测试结果上下游联动，上游产生变更下游马上会收到通知，保证成千上万条需求的软件可以做到实时上下游联动一致性。通过双向可追溯、变更引起的上下游联动协同，提升需求与交付的一致性，提升软件整体交付质量，满意度，提升软件开发效率，变更管理效率。此外，还可以生成需求测试用例矩阵，可检测测试用例对测试需求的覆盖率。

本申请实施例还提供了一种项目管理装置，图11是本申请实施例提供的一种项目管理装置的结构示意图，如图11所示，该装置包括：

项目创建指令接收模块1101，用于接收项目创建指令。

项目创建模块1103，用于根据项目创建指令创建项目。项目包括至少两个处理环节，每个处理环节包括至少一个操作文档。

文档处理指令接收模块1105，用于接收文档处理指令。

操作文档处理模块1107，用于根据文档处理指令对操作文档进行处理。

关联关系建立指令接收模块1109，用于接收关联关系建立指令。

关联关系建立模块1111，用于根据关联关系建立指令建立操作文档之间的关联关系。

管理路径确定模块1113，用于根据关联关系确定项目的管理路径。

在一些可选的实施方式中，项目创建模块包括：

项目模板确定单元，用于根据项目创建指令确定项目模板。

操作文档实例化单元，用于根据项目模板实例化处理环节中的操作文档。

在一些可选的实施方式中，操作文档处理模块包括：

章节划分单元，用于根据文档处理指令将操作文档划分为多个章节。

章节解构单元，用于将章节解构为多个条目。

在一些可选的实施方式中，处理环节包括需求设计环节和测试规范环节；需求设计环节中的操作文档包括多个需求设计类文档；测试规范环节中的操作文档包括多个测试规范类文档；

关联关系建立模块包括：

文档标识获取单元，用于根据关联关系建立指令获取多个需求设计类文档的第一类文档标识和多个测试规范类文档的第二类文档标识；第一类文档标识用于标识每个需求设计类文档；第二类文档标识用于标识每个测试规范类文档；

纵向关联关系建立单元，用于根据项目模板和第一类文档标识建立多个需求设计类文档之间的纵向关联关系；

纵向关联关系建立单元，还用于根据项目模板和第二类文档标识建立多个测试规范类文档之间的纵向关联关系。

在一些可选的实施方式中，根据关联关系建立指令建立操作文档之间的关联关系，还包括：

横向关联关系建立单元，用于根据项目模板、第一类文档标识和第二类文档标识建立每个需求设计类文档与其中一个测试规范类文档的横向关联关系。

在一些可选的实施方式中，多个需求设计类文档包括利益相关方需求文档、系统需求文档、系统架构文档、软件需求文档、软件架构文档、软件详细设计文档；第二类包括单元测试规范文档、软件集成测试规范文档、软件合格性测试规范文档、系统集成测试规范文档、系统合格性测试规范文档；

纵向关联关系建立单元包括：

第一关联关系建立子单元，用于根据项目模板和第一类文档标识，依次建立利益相关方需求文档与系统需求文档之间的关联关系、系统需求文档与系统架构文档之间的关联关系、系统架构文档与软件需求文档之间的关联关系、软件需求文档与软件架构文档之间的关联关系、软件架构文档与软件详细设计文档之间的关联关系；

纵向关联关系建立单元还包括：

第二关联关系建立子单元，用于根据项目模板和第二类文档标识，依次建立单元测试规范文档与软件集成测试规范文档之间的关联关系、软件集成测试规范文档与软件合格性测试规范文档之间的关联关系、软件合格性测试规范文档与系统集成测试规范文档之间的关联关系、系统集成测试规范文档与系统合格性测试规范文档之间的关联关系。

在一些可选的实施方式中，横向关联关系建立单元包括：

第三关联关系建立子单元，用于根据项目模板、第一类文档标识和第二类文档标识，依次建立系统需求文档与系统合格性测试规范文档之间的关联关系、系统架构文档与系统集成测试规范文档之间的关联关系、软件需求文档与软件合格性测试规范文档之间的关联关系、软件架构文档与软件集成测试规范文档之间的关联关系、软件详细设计文档与单元测试规范文档之间的关联关系。

在一些可选的实施方式中，每个需求设计类文档包括多个需求设计类条目；每个测试规范类文档包括多个测试规范类条目；

关联关系建立模块还包括：

第一条目关联关系建立单元，用于根据关联关系建立指令建立每个需求设计类条目与至少一个测试规范类条目之间的关联关系。

在一些可选的实施方式中，多个需求设计类文档中存在第一需求设计类文档和第二需求设计类文档；第一需求设计类文档包括多个第一需求设计类条目；第二需求设计类文档包括多个第二需求设计类条目；多个测试规范类文档中存在第一测试规范类文档和第二测试规范类文档；第一测试规范类文档包括多个第一测试规范类条目；第二测试规范类文档包括多个第二测试规范类条目；

关联关系建立模块还包括：

第二条目关联关系建立单元，用于根据关联关系建立指令建立每个第一需求设计类条目与至少一个第二需求设计类条目之间的关联关系；

第三条目关联关系建立单元，用于根据关联关系建立指令建立每个第一测试规范类条目与至少一个第二测试规范类条目之间的关联关系。

需求关联关系建立单元，用于根据关联关系建立指令建立系统需求条目与软件需求条目之间的关联关系。

在一些可选的实施方式中，该装置还包括：

条目变更指令接收模块，用于接收条目变更指令。

条目变更通知发送模块，用于根据管理路径发送条目变更通知。

在一些可选的实施方式中，该装置还包括：

文档导出指令接收模块，用于接收文档导出指令。

文档导出模块，用于根据文档导出指令导出项目的报告文档。

本申请实施例中的装置与方法实施例基于同样地申请构思。

本申请实施例还提供了一种电子设备，设备包括处理器和存储器，存储器中存储有至少一条指令或至少一段程序，至少一条指令或至少一段程序由处理器加载并执行如上所述的项目管理方法。

本申请实施例所提供的方法实施例可以在计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图12是本申请实施例提供的一种项目管理方法的服务器的硬件结构框图。如图12所示，该服务器1200可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，CPU)1210(处理器1210可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1230，一个或一个以上存储应用程序1223或数据1222的存储介质1220(例如一个或一个以上海量存储设备)。其中，存储器1230和存储介质1220可以是短暂存储或持久存储。存储在存储介质1220的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1210可以设置为与存储介质1220通信，在服务器1200上执行存储介质1220中的一系列指令操作。服务器1200还可以包括一个或一个以上电源1260，一个或一个以上有线或无线网络接口1250，一个或一个以上输入输出接口1240，和/或，一个或一个以上操作系统1221，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

输入输出接口1240可以用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器1200的通信供应商提供的无线网络。在一个实例中，输入输出接口1240包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，输入输出接口1240可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

本领域普通技术人员可以理解，图12所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器1200还可包括比图12中所示更多或者更少的组件，或者具有与图12所示不同的配置。

本申请实施例还提供了一种计算机可读存储介质，存储介质中存储有至少一条指令或至少一段程序，至少一条指令或至少一段程序由处理器加载并执行以实现如上所述的项目管理方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种项目管理方法，其特征在于，所述方法包括：

接收项目创建指令；

根据所述项目创建指令创建项目；所述项目包括至少两个处理环节，每个所述处理环节包括至少一个操作文档；

接收文档处理指令；

根据所述文档处理指令对所述操作文档进行处理；

接收关联关系建立指令；

根据所述关联关系建立指令建立所述操作文档之间的关联关系；

根据所述关联关系确定所述项目的管理路径。

2.根据权利要求1所述的项目管理方法，其特征在于，所述根据所述项目创建指令创建项目，包括：

根据所述项目创建指令确定项目模板；

根据所述项目模板实例化所述处理环节中的所述操作文档。

3.根据权利要求2所述的项目管理方法，其特征在于，所述根据所述文档处理指令对所述操作文档进行处理，包括：

根据所述文档处理指令将所述操作文档划分为多个章节；

将所述章节解构为多个条目。

4.根据权利要求3所述的项目管理方法，其特征在于，所述处理环节包括需求设计环节和测试规范环节；所述需求设计环节中的所述操作文档包括多个需求设计类文档；所述测试规范环节中的所述操作文档包括多个测试规范类文档；

所述根据所述关联关系建立指令建立所述操作文档之间的关联关系，包括：

根据所述关联关系建立指令获取多个所述需求设计类文档的第一类文档标识和多个所述测试规范类文档的第二类文档标识；所述第一类文档标识用于标识每个所述需求设计类文档；所述第二类文档标识用于标识每个所述测试规范类文档；

根据所述项目模板和所述第一类文档标识建立多个所述需求设计类文档之间的纵向关联关系；

根据所述项目模板和所述第二类文档标识建立多个所述测试规范类文档之间的纵向关联关系。

5.根据权利要求4所述的项目管理方法，其特征在于，所述根据所述关联关系建立指令建立所述操作文档之间的关联关系，还包括：

根据所述项目模板、所述第一类文档标识和所述第二类文档标识建立每个所述需求设计类文档与其中一个所述测试规范类文档的横向关联关系。

6.根据权利要求4所述的项目管理方法，其特征在于，每个所述需求设计类文档包括多个需求设计类条目；每个所述测试规范类文档包括多个测试规范类条目；

所述根据所述关联关系建立指令建立所述操作文档之间的关联关系，还包括：

根据所述关联关系建立指令建立每个所述需求设计类条目与至少一个测试规范类条目之间的关联关系。

7.根据权利要求4所述的项目管理方法，其特征在于，多个所述需求设计类文档中存在第一需求设计类文档和第二需求设计类文档；所述第一需求设计类文档包括多个第一需求设计类条目；所述第二需求设计类文档包括多个第二需求设计类条目；多个所述测试规范类文档中存在第一测试规范类文档和第二测试规范类文档；所述第一测试规范类文档包括多个第一测试规范类条目；所述第二测试规范类文档包括多个第二测试规范类条目；

所述根据所述关联关系建立指令建立所述操作文档之间的关联关系，还包括：

根据所述关联关系建立指令建立每个所述第一需求设计类条目与至少一个所述第二需求设计类条目之间的关联关系；

根据所述关联关系建立指令建立每个所述第一测试规范类条目与至少一个所述第二测试规范类条目之间的关联关系。

8.根据权利要求3或7所述的项目管理方法，其特征在于，所述根据所述关联关系确定所述项目的管理路径之后，还包括：

接收条目变更指令；

根据所述管理路径发送条目变更通知。

9.根据权利要求8所述的项目管理方法，其特征在于，所述根据所述关联关系确定所述项目的管理路径之后，还包括：

接收文档导出指令；

根据所述文档导出指令导出所述项目的报告文档。

10.一种项目管理装置，其特征在于，所述装置包括：

项目创建指令接收模块，用于接收项目创建指令；

项目创建模块，用于根据所述项目创建指令创建项目；所述项目包括至少两个处理环节，每个所述处理环节包括至少一个操作文档；

文档处理指令接收模块，用于接收文档处理指令；

操作文档处理模块，用于根据所述文档处理指令对所述操作文档进行处理；

关联关系建立指令接收模块，用于接收关联关系建立指令；

关联关系建立模块，用于根据所述关联关系建立指令建立所述操作文档之间的关联关系；

管理路径确定模块，用于根据所述关联关系确定所述项目的管理路径。

11.一种电子设备，其特征在于，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行如权利要求1-9任一所述的项目管理方法。

12.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如权利要求1-9任一所述的项目管理方法。

Images