A cross-departmental project schedule status and deliverable processability reconciliation system

Abstract

This invention discloses a cross-departmental project progress status and deliverables handleability consistency verification system. The system includes a status verification information acquisition module, a fragment location module, a drift judgment module, and a hit judgment module. The system acquires status verification information for project nodes, including the current deliverable, the anchor point of the preceding deliverable fragment referenced by the current deliverable, the original fragment characteristics, and the minimum handleable condition set for the target receiving department. When a version change is detected in the preceding deliverable to which the preceding deliverable fragment anchor point belongs, the system determines the current fragment based on the preceding deliverable fragment anchor point and generates the current fragment characteristics. The system determines the fragment drift result based on the original fragment characteristics and the current fragment characteristics. If no fragment drift occurs, a status maintenance result is generated. If fragment drift occurs, a status processing result for the project node is generated based on the hit relationship between the target fragment and the minimum handleable condition set, as well as the fragment drift result.

Description

Technical Field

[0001] This application relates to the fields of computer data processing and project collaborative management technology, and in particular to a method and system for verifying the consistency between cross-departmental project progress status and deliverables handleability. Background Technology

[0002] In cross-departmental project scenarios such as enterprise project management, R&D collaboration, engineering delivery, procurement collaboration, software launch, and contract review, different departments typically develop multiple project nodes and deliverables around the same project. For example, the product department develops a requirements specification, the testing department develops test cases based on the requirements specification, the design department develops design drawings, the procurement department develops a procurement list based on the design drawings, the business department develops the contract text, the legal department develops review opinions based on the contract text, and the operations department executes the launch operation based on the launch plan.

[0003] Existing cross-departmental project management systems typically display project progress through task nodes, manual confirmation, process approvals, or deliverable upload records. After submitting deliverables, project members can mark the corresponding project nodes as submitted, completed, or ready to proceed. The system can also perform a one-time verification of whether deliverables have been uploaded, whether approvals have been completed, and whether fields have been filled in before status migration.

[0004] Once a project node is marked as completed or ready to proceed, whether the current deliverable can still be processed by the target receiving department often depends on whether the content of the preceding deliverables referenced by the project node is still valid. However, the state of a project node is usually stored as a static result. Therefore, when the preceding deliverable undergoes a version change, judging the validity of the current deliverable's state solely based on the overall version change of the preceding deliverables can easily lead to two types of problems: One type is where irrelevant content in the preceding deliverables changes, causing all downstream deliverables to be unnecessarily reviewed; the other type is where critical segments in the preceding deliverables change, but the system, because it only records overall version references, fails to recognize the impact of these critical segment changes on the current deliverables' processability.

[0005] Furthermore, different target receiving departments often provide different feedback on the same deliverable. For the testing department, boundary rules, abnormal scenarios, and acceptance criteria may be necessary conditions; for the procurement department, material type, specifications, quantity, and supplier candidate codes may be necessary conditions; and for the legal department, the signing entity, payment terms, and liability for breach of contract may be necessary conditions.

[0006] Existing systems typically lack a state consistency verification mechanism that can combine changes in pre-deliverable fragments with the processing of the target receiving department. Summary of the Invention

[0007] This application provides a cross-departmental project progress status and deliverables handleability consistency verification system, which is used to identify the drift of the previous deliverable fragments referenced by the current deliverable in cross-departmental projects, and generate the status processing result of the project node based on whether the fragment drift hits the minimum handleable condition set of the target receiving department, thereby reducing status misuse, error flow and cross-departmental rework.

[0008] In a first aspect, this application provides a cross-departmental project progress status and deliverables handling consistency verification system; the system includes a status verification information acquisition module, a fragment positioning module, a drift judgment module, and a hit judgment module. The status verification information acquisition module is used to acquire the status verification information of the project node. The status verification information includes the current deliverable that is in the completed or advanceable state, the previous deliverable fragment anchor point referenced by the current deliverable, the original fragment features corresponding to the previous deliverable fragment anchor point, and the minimum processable condition set of the target receiving department. The segment localization module is used to determine the corresponding current segment in the pre-deliverable after the version change based on the pre-deliverable segment anchor point when a version change is detected in the pre-deliverable to which the pre-deliverable segment anchor point belongs, and to generate the current segment feature of the current segment. The drift determination module is used to determine the segment drift result based on the original segment features and the current segment features, and to determine the target segment when the segment drift result indicates that segment drift has occurred; The hit determination module is used to generate a state maintenance result when the fragment drift result indicates that no fragment drift has occurred, and to generate a state processing result for the project node when the fragment drift result indicates that fragment drift has occurred, based on the hit relationship between the target fragment and the minimum processable condition set and the fragment drift result. The status processing result includes at least one of the following: status maintained, prompt, pending review, automatic progress prohibited, and status abnormal.

[0009] In the above system, the consistency verification system does not only determine whether the current deliverable needs to be reviewed based on the overall version change of the preceding deliverable, but also determines the preceding deliverable fragment actually referenced by the current deliverable through the fragment positioning module, and determines whether the referenced fragment has drifted after the version change of the preceding deliverable through the drift judgment module, and then determines whether the drift hits the minimum processable condition set of the target receiving department through the hit judgment module. This approach avoids excessive review of all downstream deliverables due to overall version changes of preceding deliverables, and also prevents current deliverables from being incorrectly kept in a completed or progressable state after changes to referenced key segments, thereby improving consistency between cross-departmental project progress status and deliverable processability.

[0010] In one possible design, the state verification information acquisition module is used to determine the current deliverable corresponding to the project node when the project node changes from an incomplete state to a completed state or a progressable state; determine at least one preceding deliverable fragment referenced by the current deliverable, and generate a corresponding preceding deliverable fragment anchor point for each preceding deliverable fragment; generate the original fragment feature corresponding to the preceding deliverable fragment anchor point, and bind the current deliverable, the preceding deliverable fragment anchor point, the original fragment feature, and the minimum processable condition set as the state verification information; This design allows for the simultaneous solidification of the underlying prerequisites when a project node state is established, enabling the determination of whether the original state basis remains valid when subsequent deliverables change.

[0011] In one possible design, the pre-deliverable fragment anchor points include at least one of the following: chapter number, field identifier, table row and column coordinates, drawing area identifier, parameter number, interface field name, clause number, and reference text summary; This design can adapt to the segment positioning requirements of different types of deliverables. For example, document deliverables can use chapter numbers or clause numbers, table deliverables can use table row and column coordinates, drawing deliverables can use drawing area identifiers, and interface deliverables can use interface field names.

[0012] In one possible design, the fragment location module is used to perform anchor point matching in the pre-deliverables after version change based on the pre-deliverable fragment anchor points; if a corresponding anchor point is matched, the content corresponding to the corresponding anchor point is determined as the current fragment; if no corresponding anchor point is matched, similar fragment matching is performed in the pre-deliverables after version change based on the title, keywords, adjacent fragment content, or field identifiers corresponding to the original fragment features, and the current fragment is determined based on the matching results; if no similar fragments satisfy the matching conditions, the current fragment is determined to be missing, and the current fragment feature is set as a missing identifier; This design enables the identification of corresponding segments through contextual similarity matching even when changes in the version of the preceding deliverables lead to changes in the chapter number, table position, or clause position. When the corresponding segment cannot be located, it can also clearly determine that the segment is missing, reducing misjudgments caused by changes in position or structure.

[0013] In one possible design, the drift determination module is used to compare the original fragment features with the current fragment features to determine whether the current fragment has drifted relative to the original fragment corresponding to the anchor point of the preceding deliverable fragment; wherein, the fragment drift result includes at least one of no drift, position drift, content drift, fragment missing, fragment splitting, and fragment merging; This design allows for the differentiation of different change types of pre-deliverable fragments, enabling the system to generate differentiated state processing results based on different drift types.

[0014] In one possible design, the minimum set of processable conditions for the target receiving department is determined based on the target receiving department and the deliverable type of the current deliverable; the minimum set of processable conditions includes at least one condition item, each condition item including at least a condition identifier, a condition type, and a corresponding fragment anchor type; the condition item also includes at least one of the following: applicable deliverable type, whether to block, and status processing level; wherein, the condition type includes at least one of the following: necessary chapter, necessary field, necessary parameter, necessary clause, necessary attachment, and necessary approval item; This design enables target segments to be matched with the minimum set of processable conditions based on condition identifiers, condition types, or corresponding segment anchor types. This avoids coarse-grained judgments based solely on whether the deliverable has changed, and instead determines whether segment drift will affect processability based on the conditions actually necessary for the target receiving department to process the deliverable.

[0015] In one possible design, the hit determination module is used to determine the segment type, condition identifier, or pre-deliverable segment anchor point corresponding to the target segment; determine whether the segment type, condition identifier, or pre-deliverable segment anchor point corresponding to the target segment matches the condition items in the minimum processable condition set; if they match, it is determined that the target segment hits the minimum processable condition set, and the status processing result of the project node is generated based on the segment drift result; if they do not match, the current state of the project node is maintained or a prompt message is generated. This design limits changes to deliverables to the segments that truly affect the processing conditions of the target receiving department, thereby reducing excessive state verification caused by irrelevant changes.

[0016] In one possible design, the hit determination module is used to generate a state-maintaining result when the segment drift result is a positional drift and the content remains unchanged; to generate a result to be reviewed when the segment drift result is a content drift and the target segment hits the minimum processable condition set; and to generate a result to prohibit automatic advancement or a state abnormality result when the segment drift result is a missing segment, a split segment, or a merged segment and the target segment hits the minimum processable condition set. This design allows for the maintenance, review, prohibition of progress, or anomaly marking of project node states based on the degree of impact of fragment drift on the processing conditions of the target receiving department, avoiding the simple treatment of all changes as state failures.

[0017] In one possible design, the system further includes a rule incremental verification module. This module is used to, when a version change is detected in the processing rule corresponding to the target receiving department in the status verification information, obtain the rule incremental item corresponding to the rule version change; when the rule incremental item includes a new blocking item or a blocking level upgrade item, determine whether the new blocking item or the blocking level upgrade item matches the minimum processable condition set; if it matches the minimum processable condition set, perform a partial re-verification on the project node and update the status processing result based on the partial re-verification result; wherein, the partial re-verification is used to verify whether the current deliverable meets the condition item corresponding to the new blocking item or the blocking level upgrade item; This design eliminates the need for a full re-verification of all historical project nodes when the target receiving department processes rule changes. Instead, it determines the project nodes that need re-verification based on the hit relationship between the rule increment and the minimum set of processable conditions, thereby improving the efficiency and accuracy of status verification after rule changes.

[0018] In one possible design, the system further includes a record generation module for generating fragment-level reference drift records; The fragment-level reference drift record is used to associate the current deliverable, the previous deliverable fragment, the fragment drift result, and the status processing result. The fragment-level reference drift record is also used to record the hit status between the target fragment and the minimum processable condition set; This design allows for the recording of the basis for project node status processing results, facilitating subsequent status verification, deliverable traceability, and cross-departmental responsibility allocation.

[0019] In a second aspect, this application provides an electronic device including at least one processor and at least one memory, wherein the at least one memory stores computer program instructions, and when the electronic device is running, the at least one processor performs the functions performed by the consistency verification system described in the first aspect and its various embodiments.

[0020] Thirdly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a computer, causes the computer to perform the functions of the consistency verification system described in the first aspect and its various embodiments.

[0021] For the technical effects that can be achieved by the second and third aspects mentioned above, please refer to the description of the technical effects that can be achieved by the corresponding design scheme in the first aspect mentioned above. This application will not repeat them here. Attached Figure Description

[0022] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0023] Figure 1 A schematic diagram of the architecture of a cross-departmental project collaboration system provided in this application embodiment; Figure 2 A schematic diagram illustrating a current deliverable referencing a fragment of a previous deliverable, provided as an embodiment of this application; Figure 3 A flowchart illustrating a method for verifying the consistency between cross-departmental project progress status and deliverable handleability, as provided in an embodiment of this application. Figure 4 A schematic diagram illustrating a status verification information generation process provided in an embodiment of this application; Figure 5 A schematic diagram illustrating how to determine the current segment based on the anchor point of a preceding deliverable segment, as provided in this application embodiment; Figure 6 A schematic diagram illustrating the minimum processable condition set for a rule increment item, provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a consistency verification system provided in an embodiment of this application; Figure 8 This is a schematic diagram of a possible structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings; wherein, in the description of the embodiments of this application, the terms "first", "second", etc. are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features.

[0025] It should be understood that in the embodiments of this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural.

[0026] Figure 1A schematic diagram of the architecture of a cross-departmental project collaboration system provided in this application embodiment; Reference Figure 1 The system may include a project management platform, a deliverable management platform, a process approval platform, a consistency verification system, and multiple departmental terminals; The project management platform is used to manage project nodes, project progress status, and the flow relationships between nodes; The deliverables management platform is used to store deliverables such as requirements specifications, test cases, design drawings, purchase lists, contract texts, review comments, and deployment plans. The workflow approval platform is used to manage the approval status of deliverables; The consistency verification system is used to execute the cross-departmental project progress status and deliverables processability consistency verification method provided in the embodiments of this application.

[0027] The consistency verification system can be deployed independently or implemented as a functional module in a project management platform, deliverable management platform, or process approval platform. In some implementations, the consistency verification system can be implemented by a server; in other implementations, the consistency verification system can be implemented collaboratively by a server and front-end devices.

[0028] In the embodiments of this application, the current deliverable refers to the deliverable corresponding to the project node when the project node is in a completed or advanceable state; for example, when the test case design node is in a completed state, the test case can be used as the current deliverable; when the procurement preparation node is in an advanceable state, the procurement list can be used as the current deliverable; when the legal review node is in a completed state, the legal review opinion can be used as the current deliverable.

[0029] An upstream deliverable refers to the upstream deliverable upon which the current deliverable is based. For example, the upstream deliverable corresponding to a test case may be a requirements specification; the upstream deliverable corresponding to a purchase order may be design drawings; the upstream deliverable corresponding to a production process document may be a bill of materials; and the upstream deliverable corresponding to a legal review opinion may be a contract text.

[0030] refer to Figure 2 , Figure 5 An anchor point for a preceding deliverable fragment is used to locate a portion of the preceding deliverable that the current deliverable actually references; this portion of the deliverable can be a chapter, clause, field, table cell, drawing area, parameter item, or interface field, rather than the entire preceding deliverable.

[0031] Status verification information is used to characterize the status basis when the status of a project node is formed; status verification information can be stored in the form of data records, tokens, table entries or structured files; to avoid confusion in terminology, this application embodiment uniformly refers to it as status verification information.

[0032] In the embodiments of this application, the deliverables can all be parsed into at least one locatable segment, and each locatable segment can form a corresponding segment anchor point and segment feature. For example, the locatable fragments parsed from document deliverables can be chapters, clauses, or paragraphs; the locatable fragments parsed from table deliverables can be fields, row / column cells, or record fragments; the locatable fragments parsed from drawing deliverables can be drawing areas, annotation areas, or part number areas; and the locatable fragments parsed from interface deliverables can be interface fields, request parameters, or response parameters.

[0033] refer to Figure 6 In this application embodiment, consistency verification refers to the short name for consistency verification of project node status and deliverables handleability. Based on the above problems, this application embodiment provides a method for cross-departmental project progress status and deliverables handleability consistency verification, which can be executed by a consistency verification system.

[0034] Using this method, the consistency verification system can identify whether the previous deliverable fragment actually referenced by the current deliverable has drifted when the previous deliverable undergoes a version change, and further determine whether the drifted fragment hits the minimum processable condition set of the target receiving department, thereby generating various status processing results such as status maintenance, prompt, pending review, prohibition of automatic advancement, or status abnormality.

[0035] The following describes the method for verifying the consistency between cross-departmental project progress status and deliverables handleability provided in the embodiments of this application: Figure 3 A flowchart illustrating a method for verifying the consistency between cross-departmental project progress status and deliverable handleability, as provided in this application embodiment, is shown below. Figure 3 The method includes the following steps: S301: The consistency verification system obtains the status verification information of the project nodes; The status verification information includes the current deliverable in the completed or advanceable state, the anchor point of the preceding deliverable segment referenced by the current deliverable, the original segment characteristics corresponding to the anchor point of the preceding deliverable segment, and the minimum processable condition set of the target receiving department.

[0036] In some embodiments of this application, when a project node changes from an incomplete state to a completed state or a progressable state, the consistency verification system can determine the current deliverable corresponding to the project node; for example, when the testing department submits a test case and marks the test case design node as completed, the consistency verification system determines the test case as the current deliverable; when the procurement department generates a procurement list based on the design drawings and marks the procurement preparation node as progressable, the consistency verification system determines the procurement list as the current deliverable.

[0037] The consistency verification system can determine at least one preceding deliverable fragment referenced by the current deliverable based on reference identifiers, reference links, reference fields, manual selection results, document parsing results, or upstream and downstream deliverable relationships in the current deliverable; for example, the test case number in the test case can be associated with the requirement item in the requirement specification, the material item in the purchase list can be associated with the material specification table in the design drawings, and the review item in the legal review opinion can be associated with the clause number in the contract text.

[0038] The consistency verification system generates a corresponding preceding deliverable fragment anchor point for each preceding deliverable fragment and generates the original fragment feature corresponding to the preceding deliverable fragment anchor point. The original fragment feature is used to represent the content state of the referenced preceding fragment when the project node state is formed.

[0039] For document-type deliverables, the anchor point of the preceding deliverable fragment can be formed by the chapter number, chapter title, clause number, summary of the cited text, and context text with a preset word count before and after; for example, the anchor point of the fragment "Section 4.1 Permission Boundary Rules" in the requirements specification can include the chapter number "4.1", the title "Permission Boundary Rules", the first sentence summary of the chapter, and the title of the adjacent chapter.

[0040] For tabular deliverables, the anchor point of the preceding deliverable fragment can be formed by the table name, field name, row primary key, column name, and cell position. For example, a material model in the bill of materials can be located by the table name "Material Specification Table", the row primary key "Part Number P001", the column name "Material Model", and the table row and column coordinates.

[0041] For drawing-type deliverables, the anchor point of the preceding deliverable fragment can be formed by the drawing page number, layer identifier, area coordinates, part number, and annotation text. For example, a material specification area in a design drawing can be located by the drawing page number, the coordinates of the upper left corner of the area, the coordinates of the lower right corner of the area, the layer name, the part number, and the annotation text within the area. Thus, when the area coordinates change in the new version of the drawing but the part number and annotation parameters within the area remain the same, it can be determined as a positional drift. When the material model, size parameters, or quantity annotations within the area change, it can be determined as a content drift.

[0042] For interface-type deliverables, the anchor point of the preceding deliverable fragment can be formed by the interface name, request field name, response field name, field path, and field description; for example, the return code field in the interface documentation can be located by the interface name, response field name, and field path.

[0043] The original fragment features can be generated based on the type of the preceding deliverable fragment. When the fragment is plain text, the original fragment features can include the hash value of the normalized text, a set of keywords, or a text summary; when the fragment is a table field, the original fragment features can include a structured summary formed by the field name, field value, row primary key, and column name; when the fragment is a drawing area, the original fragment features can include area coordinates, annotation text within the area, part number, and parameter value; when the fragment is an interface field, the original fragment features can include the interface path, field name, field type, whether it is required, and field description.

[0044] refer to Figure 4 The consistency verification system can also determine the minimum set of processable conditions based on the target receiving department and the deliverable type of the current deliverable, and bind the current deliverable, the anchor point of the preceding deliverable segment, the original segment characteristics, and the minimum set of processable conditions into status verification information; the status verification information is used to characterize the preceding segment basis and department processing conditions on which the completed state or the advanceable state of the project node depends when the status is formed.

[0045] S302: When the consistency verification system detects a version change in the preceding deliverable to which the preceding deliverable fragment anchor point belongs, it determines the current fragment based on the preceding deliverable fragment anchor point; In this application embodiment, a version change of the pre-deliverable may include the pre-deliverable being modified, replaced, rolled back, re-uploaded, re-approved, or marked as a currently valid version change.

[0046] In some implementations, the consistency verification system can determine whether a pre-deliverable has undergone a version change based on the version number, file content hash, update time, approval number, current valid version identifier, or deliverable status identifier of the pre-deliverable; when any of the above identifiers changes relative to the corresponding identifier recorded in the status verification information, the consistency verification system determines that the pre-deliverable to which the pre-deliverable fragment anchor belongs has undergone a version change.

[0047] When a version change is detected in a preceding deliverable, the consistency verification system can obtain the set of status verification information corresponding to that preceding deliverable and determine the project node that references the preceding deliverable fragment from the set of status verification information.

[0048] In one optional implementation, the consistency verification system performs anchor point matching in the pre-deliverable fragments after the version change based on the anchor points of the pre-deliverable fragments. If a matching anchor point is found, the content corresponding to the anchor point is determined as the current fragment. For example, if the original fragment anchor point is Article 5.2 of the payment clause in the contract text, and Article 5.2 still exists in the new version of the contract text, the consistency verification system can determine Article 5.2 in the new version of the contract text as the current fragment.

[0049] In another optional implementation, if the consistency verification system does not match the corresponding anchor point, then similar fragments are matched in the pre-deliverables after the version change based on the title, keywords, adjacent fragment content or field identifiers corresponding to the original fragment features, and the current fragment is determined based on the matching results.

[0050] For example, if the requirements specification is updated from V2 to V3, and the original Section 4.1 "Permission Boundary Rules" is changed to Section 4.3, but because its title keywords, context titles or text summaries are similar to the original fragment, the consistency verification system can identify Section 4.3 in the new version as the current fragment through similar fragment matching.

[0051] In some implementations, the consistency verification system determines similar segments according to a preset priority. This preset priority includes: candidate segments with completely identical titles are prioritized over those with partially identical title keywords; candidate segments with identical field identifiers are prioritized over those with only keyword overlap; and candidate segments with identical titles for adjacent segments are prioritized over those with inconsistent titles for adjacent segments. When multiple candidate segments have the same priority, the candidate segment with the highest number of overlapping keywords in its cited text summary is determined as the current segment. If multiple candidate segments have the same number of overlapping keywords in their cited text summaries, the candidate segment whose relative order in the preceding deliverables is closest to the original segment is determined as the current segment; if a unique candidate segment still cannot be determined, the current segment is marked as awaiting manual confirmation.

[0052] The matching conditions include: the candidate fragments satisfying at least one of the following: the titles are completely identical, the field identifiers are identical, the titles of adjacent fragments are identical, or the number of overlapping keywords in the cited text summary reaches a preset number; when there are no candidate fragments satisfying any of the matching conditions, the consistency verification system determines that the current fragment is missing and sets the current fragment feature as a missing identifier.

[0053] For example, if the original fragment title is "Permission Boundary Rules", and there is no fragment with the same chapter number in the new version, but there is a fragment titled "User Permission Boundary Description", and its upstream and downstream titles are the same as the context of the original fragment, then the consistency verification system can identify this fragment as the current fragment.

[0054] S303: The consistency verification system determines the segment drift result based on the original segment characteristics and the current segment characteristics, and determines the target segment when the segment drift result indicates that segment drift has occurred; After the consistency verification system determines the current segment, it can generate the current segment feature corresponding to the current segment. The current segment feature can be generated in the same or corresponding way as the original segment feature. When the current segment is missing, the current segment feature can be set as a missing identifier.

[0055] The consistency verification system compares the features of the original segment with the features of the current segment to determine whether the current segment has drifted relative to the original segment; the segment drift result can include at least one of the following: no drift, position drift, content drift, segment missing, segment splitting, and segment merging; In some embodiments, if the current segment has the same anchor point as the original segment and the current segment features are the same as the original segment features, then the segment drift result is determined to be no drift; if the chapter number, table position, drawing area position or clause number of the current segment changes, but the current segment features are the same as the original segment features or meet the equivalent conditions, then the segment drift result is also determined to be position drift. For example, if the "permission boundary rules" in the requirements specification are moved from Section 4.1 to Section 4.3, but the text content remains unchanged, it is determined to be a position drift.

[0056] It should be noted that the current fragment features and the original fragment features must meet the same conditions, which may include: the text content remains consistent after removing spaces, punctuation, and numbering formats; the field values ​​of table fields are consistent but the row and column positions change; the part numbers and parameter values ​​in the drawing area are consistent but the area coordinates change; the field names, field types, and whether they are required are consistent in the interface fields but the position of the field descriptions changes.

[0057] Furthermore, if the current segment can be located, but the features of the current segment are different from those of the original segment, then the segment drift result is determined to be content drift. For example, if the "permission boundary rules" in the requirements specification are still located in section 4.1, but the "administrators can export all data" is changed to "administrators can only export data within the authorized scope", then it is determined to be content drift.

[0058] Furthermore, if the original anchor point corresponding fragment cannot be located in the pre-deliverable after the version change, and similar fragments cannot be matched, then the fragment drift result is determined to be fragment missing; if the original fragment is split into multiple fragments in the pre-deliverable after the version change, and the multiple fragments jointly cover the main content of the original fragment, then the fragment drift result is determined to be fragment splitting; the joint coverage of the main content of the original fragment can be that multiple current fragments contain all the condition identifiers in the original fragment, or contain the necessary fields, necessary parameters, or necessary clauses in the original fragment referenced by the minimum processable condition set; if the original fragment and other fragments are merged into one fragment in the pre-deliverable after the version change, then the fragment drift result is determined to be fragment merging.

[0059] Ultimately, when the fragment drift result is position drift, content drift, fragment missing, fragment split, or fragment merging, the consistency verification system can identify the drifted fragment as the target fragment. When the fragment drift result is no drift, the consistency verification system can generate a state-preserving result or not adjust the state of the project node.

[0060] S304: The consistency verification system generates the status processing result of the project node based on the fragment drift result and the hit relationship between the target fragment and the minimum processable condition set when fragment drift occurs. In this embodiment, the minimum processable condition set represents the minimum content conditions that the target receiving department must meet when processing the current deliverable. The minimum processable condition set can be determined based on the target receiving department and the deliverable type of the current deliverable.

[0061] The minimum set of manageable conditions can be pre-configured in the department processing rule table, or it can be automatically loaded according to the project template, deliverable type and target receiving department. The minimum set of manageable conditions includes at least one condition item, and each condition item includes at least a condition identifier, a condition type and a corresponding fragment anchor type. The condition item may also include at least one of the following: applicable deliverable type, whether to block and status processing level.

[0062] In order for the target fragment to be matched with the minimum set of processable conditions, the condition identifier is used to uniquely represent the processing conditions required by the target receiving department; the condition type is used to indicate whether the condition belongs to a chapter, field, parameter, clause, attachment or approval item; the corresponding fragment anchor type is used to indicate which type of pre-deliverable fragment anchor can be used to locate the condition item.

[0063] For example, when the current deliverable is a test case and the target receiving department is the testing department, the minimum set of processable conditions may include functional scenarios, exception scenarios, permission boundary rules, acceptance criteria, and interface return rules, etc., as specified in the requirements specification. When the current deliverable is a purchase list and the target receiving department is the purchasing department, the minimum set of processable conditions can include material type, specifications, quantity, supplier candidate code, and alternative material code from the design drawings, etc. When the current deliverable is a legal review opinion and the target receiving department is the legal department, the minimum set of conditions that can be processed may include the signing parties, payment terms, liability for breach of contract, authorization documents, and approval numbers in the contract text, etc. When the current deliverable is a deployment plan and the target receiving department is the operations and maintenance department, the minimum set of manageable conditions can include deployment steps, rollback plans, server lists, deployment windows, and responsible person information, etc.

[0064] The consistency verification system can determine the fragment type, condition identifier, or pre-deliverable fragment anchor point corresponding to the target fragment, and determine whether the fragment type, condition identifier, or pre-deliverable fragment anchor point corresponding to the target fragment matches the condition items in the minimum processable condition set. If a match is found, the target fragment is determined to have hit the minimum set of processable conditions; if no match is found, the target fragment is determined to have not hit the minimum set of processable conditions.

[0065] When the target fragment cannot be directly identified by a condition identifier, the consistency verification system can match the target fragment with the condition items in the minimum processable condition set based on the anchor type, anchor content, or fragment type of the preceding deliverable fragment.

[0066] For example, if the "page color description" in the requirements specification referenced by the test case changes, but this fragment does not belong to the minimum set of conditions that the testing department can handle, the consistency verification system can maintain the current state of the test case design node or generate a prompt message.

[0067] For example, if the "permission boundary rules" in the requirements specification shifts, and this segment belongs to the minimum set of conditions that the testing department can handle, the consistency verification system can generate a result to be reviewed based on the shift result of this segment.

[0068] In some embodiments, when the fragment drift result is no drift, the consistency verification system generates a state-preserving result; When the fragment drift result is a positional drift and the content remains unchanged, it means that the position of the referenced fragment in the new version of the preceding deliverable has changed, but the content has not changed substantially. The consistency verification system can generate a state preservation result. When the fragment drift result is content drift and the target fragment hits the minimum processable condition set, it means that the content of the referenced fragment has changed and this change may affect the target receiving department's processing of the current deliverable. The consistency verification system can generate a result to be reviewed. When the fragment drift result is a missing fragment, a split fragment, or a merged fragment, and the target fragment hits the minimum set of processable conditions, it indicates that the necessary fragment originally referenced by the current deliverable no longer exists or its structure has changed significantly. The consistency verification system can generate a result that prohibits automatic advancement or an abnormal state result.

[0069] In this way, the consistency verification system can differentiate the status of project nodes based on the degree of impact of fragment drift results, rather than simply treating all changes in the versions of previous deliverables as status anomalies.

[0070] S305: When the consistency verification system detects a version change in the processing rule corresponding to the target receiving department in the status verification information, it performs a local re-verification based on the rule increment item. In some embodiments of this application, the consistency verification system can also detect whether the processing rules corresponding to the target receiving department in the status verification information have changed in version; the processing rules of the target receiving department may include at least one of field rules, attachment rules, approval rules, format parsing rules, downstream system input rules, and manual review rules.

[0071] When the consistency verification system detects a version change in the processing rules corresponding to the target receiving department, it can obtain the rule increment item corresponding to the rule version change. Rule increments may include at least one of the following: new fields, new attachments, new approval conditions, new format requirements, upgrades to blocking levels, and changes to the scope of application.

[0072] The consistency verification system can determine whether rule increments include newly added blocking items or upgraded blocking level items. Newly added blocking items refer to rule items added in the new rule version that prohibit project nodes from entering the target process if not met; upgraded blocking level items refer to rule items that were prompts or supplements in the old rule version but have been upgraded to blocking items in the new rule version.

[0073] When a newly added blocking item or a blocking level upgrade item hits the minimum set of manageable conditions, the consistency verification system can perform a partial re-verification on the project node. Partial revalidation can be performed only on newly added blocking items or blocking level upgrade items that have been hit, without having to perform full revalidation on all fields, attachments and fragments of the current deliverable.

[0074] For example, after the purchasing department rules were updated from V1 to V2, a new "supplier candidate code" was added as a blocking item, and a new "alternative material code" was added as a prompt item. If the minimum set of processable conditions corresponding to a certain procurement list includes supplier candidate codes, the consistency verification system performs a partial re-verification on the project node where the procurement list is located.

[0075] If the procurement list already contains supplier candidate codes, the status remains unchanged; if it does not contain supplier candidate codes, a result to be supplemented is generated or automatic progress is disabled.

[0076] For example, after the testing department updated the rules from V2 to V3, the "Abnormal Scenario Description" was upgraded from a prompt item to a blocking item; The consistency verification system can retrieve project nodes whose target receiving department is the testing department and whose current deliverable is a test case or requirement confirmation material, and determine whether its minimum set of manageable conditions includes an exception scenario description; if so, it performs a local re-verification on the corresponding project node.

[0077] S306: The consistency check system generates fragment-level reference drift records; In this embodiment, after generating the state processing result, the consistency verification system can also generate a fragment-level reference drift record. The fragment-level reference drift record is used to store the basis for generating the project node state processing result.

[0078] Fragment-level reference drift records can include the identifier of the current deliverable, the identifier of the predecessor deliverable, the fragment anchor point of the predecessor deliverable, the original fragment characteristics, the current fragment characteristics, the fragment drift result, the hit result of the target fragment and the minimum détenable condition set, and the state processing result.

[0079] In some implementations, the fragment-level reference drift record may also include at least one of the following: project node identifier, target receiving department, original version of the preceding deliverable, current version of the preceding deliverable, drift detection time, rule version, result of performing partial re-verification, and operating entity.

[0080] By referencing drift records at the fragment level, the consistency verification system can provide a basis for status processing in subsequent project reviews, deliverable dispute resolution, cross-departmental responsibility confirmation, and audit tracing.

[0081] The following example of a software project illustrates the implementation of this application: The product department submits Requirements Specification V2, and the testing department writes test cases based on Requirements Specification V2 and marks the test case design node as completed. When the status of this node is formed, the consistency verification system records the anchor points of the requirements specification fragments referenced by the test cases, including Section 3.2 Abnormal Login Scenario, Section 4.1 Permission Boundary Rules and Section 5.3 Data Export Restrictions, and generates the original fragment features respectively.

[0082] Subsequently, the product department updated the requirements specification from Requirements Specification V2 to Requirements Specification V3. In Requirements Specification V3, the page color description in Section 2.1 changed, and the permission boundary rules in Section 4.1 changed. Since the test cases did not reference the page color description in Section 2.1, the consistency verification system did not adjust the test case design node status due to this change. However, because the test cases referenced the permission boundary rules in Section 4.1, and this section belonged to the minimum processable condition set of the testing department, the consistency verification system identified Section 4.1 as the target section and generated a review result based on the content drift result.

[0083] By using the above methods, the consistency verification system can avoid simply equating overall version changes of the requirements specification with the failure of all test cases, while also being able to identify the key changes that truly affect the workability of test cases.

[0084] The following example, a procurement project, illustrates this point: The design department submits design drawing V1, and the procurement department generates a procurement list based on design drawing V1 and marks the procurement preparation node as progressable. The consistency verification system records the anchor points of the design drawing fragments referenced in the procurement list, which include the material type, quantity and supplier candidate code in the material specification table.

[0085] Subsequently, the design drawings are updated from drawing V1 to drawing V2. If drawing V2 only modifies the cover format and the content of the material specification table remains unchanged, the consistency verification system will determine the fragment drift result as no drift or position drift and maintain the procurement preparation node status. If drawing V2 modifies the material model or quantity in the material specification table, the consistency verification system will determine that the target fragment hits the minimum processable condition set of the procurement department and generate a result that is pending review or prohibits automatic progress.

[0086] The following example illustrates this using a contract review project: The business department submits contract text V1, and the legal department forms a legal review opinion based on contract text V1 and marks the legal review node as completed. The consistency verification system records the contract segment anchors cited in the legal review opinion, including the signing parties, payment terms, and breach of contract liability terms.

[0087] Subsequently, the contract text is updated from Contract Text V1 to Contract Text V2; if Contract Text V2 modifies the payment terms, and the payment terms fall within the minimum set of conditions that the legal department can process, the consistency verification system generates a result pending review; if Contract Text V2 deletes the liability for breach of contract clauses, the consistency verification system generates an abnormal status result or a result prohibiting automatic progress.

[0088] The following example illustrates this using an operations and maintenance deployment project: The R&D department submits deployment plan V1, and the operations and maintenance department completes the deployment preparation verification based on deployment plan V1 and marks the deployment preparation node as ready to proceed. The consistency verification system records the deployment plan segment anchor points referenced in the deployment preparation verification table, including deployment steps, rollback plan, server list and deployment window.

[0089] Subsequently, the deployment plan was updated from Deployment Plan V1 to Deployment Plan V2. If Deployment Plan V2 only adjusted the document layout or the contact information of the responsible person, while the deployment steps, rollback plan, server list, and deployment window remained unchanged, the consistency verification system generated a status retention result. If Deployment Plan V2 modified the database rollback steps in the rollback plan, and the rollback plan belonged to the minimum manageable condition set of the operations and maintenance department, the consistency verification system generated a result pending review. If V2 deleted the server list, the consistency verification system generated a result prohibiting automatic advancement.

[0090] The following example illustrates this using a financial payment item: The project acceptance department submits acceptance report V1, and the finance department generates payment application materials based on acceptance report V1 and marks the payment application node as progressable; the consistency verification system records the anchor points of the acceptance report fragments referenced in the payment application materials, including the acceptance conclusion, payment node, project number, and amount confirmation fields.

[0091] Subsequently, the acceptance report is updated from Acceptance Report V1 to Acceptance Report V2. If Acceptance Report V2 only modifies the cover or table of contents, the consistency verification system maintains the payment application node status. If Acceptance Report V2 changes the acceptance conclusion from "passed" to "requires rectification and re-inspection", or modifies the amount confirmation field, the consistency verification system determines that the target fragment matches the minimum processable condition set of the finance department and generates an abnormal status result or prohibits automatic progress.

[0092] The above examples are only used to illustrate the implementation of the embodiments of this application and do not constitute a limitation on the scope of protection of this application; in practice, the current deliverables and the preceding deliverables may also be other cross-departmental deliverables such as engineering change orders, quality inspection reports, production process documents, budget approval forms, and supplier review materials.

[0093] It is understood that, in order to realize the function of the consistency verification system in the above embodiments, this application also provides a cross-departmental project progress status and deliverables processability consistency verification system, which includes hardware and / or software structures for performing various functions; those skilled in the art should readily realize that, in conjunction with the units and method steps of the various examples described in the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software.

[0094] Figure 7 This is a schematic diagram of a possible structure of a consistency verification system provided in an embodiment of this application, with reference to... Figure 7 The consistency verification system may include a status verification information acquisition module, a fragment positioning module, a drift judgment module, a hit judgment module, a rule incremental verification module, and a record generation module; The status verification information acquisition module is used to acquire the status verification information of project nodes. This status verification information includes the current deliverable, the anchor point of the previous deliverable fragment, the original fragment characteristics, and the minimum set of processable conditions for the target receiving department, etc. The fragment localization module is used to determine the corresponding current fragment in the pre-deliverable after the version change based on the pre-deliverable fragment anchor point when a version change is detected in the pre-deliverable fragment anchor point, and generate the current fragment feature of the current fragment; wherein, when the current fragment is missing, the current fragment feature is set to a missing identifier. The drift determination module is used to determine the segment drift result based on the original segment features and the current segment features, and to determine the target segment when the segment drift result indicates that segment drift has occurred. The hit determination module is used to generate a state preservation result when the fragment drift result indicates that no fragment drift has occurred, and to generate a state processing result for the project node when the fragment drift result indicates that fragment drift has occurred, based on the hit relationship between the target fragment and the minimum processable condition set and the fragment drift result. The rule incremental verification module is used to obtain the rule incremental item corresponding to the rule version change when a version change is detected in the status verification information corresponding to the target receiving department. When the rule incremental item includes a new blocking item or a blocking level upgrade item and hits the minimum processable condition set, a local re-verification is performed on the project node.

[0095] The record generation module is used to generate fragment-level reference drift records.

[0096] Figure 8 This is a schematic diagram of a possible structure of an electronic device provided in an embodiment of this application. The electronic device can be used to implement the function of the consistency verification system in the above embodiments, and thus can also achieve the beneficial effects of the above embodiments.

[0097] refer to Figure 8 The electronic device may include a processor, a memory, and a communication interface; the processor, the memory, and the communication interface are coupled to each other; optionally, the memory may be used to store instructions executed by the processor or to store input data required for the processor to run instructions or to store data generated after the processor runs instructions; the communication interface may be used to communicate with a project management platform, a deliverable management platform, a process approval platform, or a departmental terminal.

[0098] The processor can be used to implement the processing functions of the consistency verification system in the above embodiments; for example, the processor can be used to obtain state verification information, determine the current segment, generate the current segment features, determine the segment drift result, determine whether the target segment hits the minimum processable condition set and generate the state processing result.

[0099] The memory can be used to store state verification information, previous deliverable fragment anchor points, original fragment features, current fragment features, minimum processable condition set, rule increment items, and fragment-level reference drift records.

[0100] This application also provides a computer-readable storage medium storing a computer program that, when executed by a computer, causes the computer to perform the methods described in the embodiments of this application.

[0101] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, electronic devices, or computer program products; therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

Claims

1. A cross-departmental project progress status and deliverables handleability consistency verification system, characterized in that, It includes a status verification information acquisition module, a fragment location module, a drift judgment module, and a hit judgment module; The status verification information acquisition module is used to acquire the status verification information of the project node. The status verification information includes the current deliverable that is in the completed or advanceable state, the previous deliverable fragment anchor point referenced by the current deliverable, the original fragment features corresponding to the previous deliverable fragment anchor point, and the minimum processable condition set of the target receiving department. The segment localization module is used to determine the corresponding current segment in the pre-deliverable after the version change based on the pre-deliverable segment anchor point when a version change is detected in the pre-deliverable to which the pre-deliverable segment anchor point belongs, and to generate the current segment feature of the current segment. The drift determination module is used to determine the segment drift result based on the original segment features and the current segment features, and to determine the target segment when the segment drift result indicates that segment drift has occurred; The hit determination module is used to generate a state maintenance result when the fragment drift result indicates that no fragment drift has occurred, and to generate a state processing result for the project node when the fragment drift result indicates that fragment drift has occurred, based on the hit relationship between the target fragment and the minimum processable condition set and the fragment drift result. The status processing result includes at least one of the following: status maintained, prompt, pending review, automatic progress prohibited, and status abnormal.

2. The system as described in claim 1, characterized in that, The status verification information acquisition module is used for: When a project node changes from an incomplete state to a completed or progressable state, the current deliverable corresponding to that project node is determined. Identify at least one preceding deliverable fragment referenced by the current deliverable, and generate a corresponding preceding deliverable fragment anchor point for each preceding deliverable fragment; Generate the original fragment feature corresponding to the anchor point of the preceding deliverable fragment, and bind the current deliverable, the anchor point of the preceding deliverable fragment, the original fragment feature, and the minimum processable condition set as the state verification information.

3. The system as described in claim 2, characterized in that, The pre-deliverable segment anchor points include at least one of the following: chapter number, field identifier, table row and column coordinates, drawing area identifier, parameter number, interface field name, clause number, and reference text summary.

4. The system as described in claim 1, characterized in that, The fragment localization module is used for: Based on the anchor points of the aforementioned pre-deliverable fragments, anchor point matching is performed in the pre-deliverables after version changes; If a corresponding anchor point is matched, the content corresponding to the anchor point is determined as the current segment; If no corresponding anchor point is matched, then similar segments are matched in the pre-deliverables after the version change based on the title, keywords, adjacent segment content or field identifiers corresponding to the original segment features, and the current segment is determined based on the matching results; If no similar segment meets the matching criteria, the current segment is determined to be missing, and the feature of the current segment is set as a missing identifier.

5. The system as described in claim 4, characterized in that, The drift detection module is used for: The original fragment features are compared with the current fragment features to determine whether the current fragment has experienced fragment drift relative to the original fragment corresponding to the previous delivery fragment anchor point; The segment drift result includes at least one of the following: no drift, position drift, content drift, segment missing, segment split, and segment merging.

6. The system as described in claim 5, characterized in that, The minimum set of processable conditions for the target receiving department is determined based on the target receiving department and the deliverable type of the current deliverable; The minimum processable condition set includes at least one condition item, and each condition item includes at least a condition identifier, a condition type, and a corresponding fragment anchor point type. The condition item also includes at least one of the following: applicable delivery type, whether blocking, and status handling level; The condition type includes at least one of the following: necessary chapters, necessary fields, necessary parameters, necessary clauses, necessary attachments, and necessary approval items.

7. The system as described in claim 1, characterized in that, The hit determination module is used for: Determine the segment type, condition identifier, or pre-deliverable segment anchor point corresponding to the target segment; Determine whether the fragment type, condition identifier, or pre-deliverable fragment anchor point corresponding to the target fragment matches the condition items in the minimum processable condition set; If a match is found, the target fragment is determined to have hit the minimum processable condition set, and the status processing result of the project node is generated based on the fragment drift result. If there is a mismatch, the current state of the project node is maintained or a prompt message is generated.

8. The system as described in claim 7, characterized in that, The hit determination module is used for: When the fragment drift result is a positional drift and the content remains unchanged, a state preservation result is generated. When the fragment drift result is content drift and the target fragment hits the minimum processable condition set, a result to be reviewed is generated; When the fragment drift result is fragment missing, fragment split, or fragment merge, and the target fragment hits the minimum processable condition set, an automatic advancement prohibition result or an abnormal state result is generated.

9. The system as described in claim 8, characterized in that, The system also includes a rule incremental verification module; The rule increment verification module is used to obtain the rule increment item corresponding to the rule version change when it detects that the processing rule corresponding to the target receiving department in the status verification information has changed. When the rule increment includes a new blocking item or a blocking level upgrade item, determine whether the new blocking item or the blocking level upgrade item matches the minimum set of processable conditions. If the minimum processable condition set is met, then a local re-verification is performed on the project node, and the state processing result is updated based on the local re-verification result. The local re-verification is used to verify whether the current deliverable meets the conditions corresponding to the newly added blocking item or the blocking level upgrade item.

10. The system according to any one of claims 1 to 9, characterized in that, The system also includes a record generation module; The record generation module is used to generate fragment-level reference drift records; The fragment-level reference drift record is used to associate the current deliverable, the previous deliverable fragment, the fragment drift result, and the status processing result. The fragment-level reference drift record is also used to record the hit status between the target fragment and the minimum processable condition set.

Images